< draft-palet-v6ops-p2p-links-02.txt   draft-palet-v6ops-p2p-links-03.txt >
v6ops J. Palet Martinez v6ops J. Palet Martinez
Internet-Draft The IPv6 Company Internet-Draft The IPv6 Company
Intended status: Informational May 29, 2018 Intended status: Informational July 4, 2019
Expires: November 30, 2018 Expires: January 5, 2020
IPv6 Point-to-Point Links IPv6 Point-to-Point Links
draft-palet-v6ops-p2p-links-02 draft-palet-v6ops-p2p-links-03
Abstract Abstract
This document describes different alternatives for configuring IPv6 This document describes different alternatives for configuring IPv6
point-to-point links, considering the prefix size, numbering choices point-to-point links, considering the prefix size, numbering choices
and prefix pool to be used. and prefix pool to be used.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 30, 2018. This Internet-Draft will expire on January 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 42 skipping to change at page 2, line 42
1. Introduction 1. Introduction
There are different alternatives for numbering IPv6 point-to-point There are different alternatives for numbering IPv6 point-to-point
links, and from an operational perspective, there may have different links, and from an operational perspective, there may have different
advantages or disadvantages that need to be taken in consideration advantages or disadvantages that need to be taken in consideration
under the scope of each specific network architecture design. under the scope of each specific network architecture design.
[RFC6164] describes using /127 prefixes for inter-router point-to- [RFC6164] describes using /127 prefixes for inter-router point-to-
point links, using two different address pools, one for numbering the point links, using two different address pools, one for numbering the
point-to-point links and another one for delegating the prefixes at point-to-point links and another one for delegating the prefixes at
the end of the point-to-point link. However this doesn't exclude the end of the point-to-point link. However, this doesn't exclude
other choices. other choices.
This document describes alternative approaches, for the prefix size, This document describes alternative approaches, for the prefix size,
the numbering of the link and the prefix pool. the numbering of the link and the prefix pool.
The proposed approaches are suitable for those point-to-point links The proposed approaches are suitable for those point-to-point links
connecting ISP to customers, but not limited to those cases, and in connecting ISP to customers, but not limited to those cases, and in
fact, all them are being used by a relevant number of networks fact, all them are being used by a relevant number of networks
worldwide, in several different scenarios (service providers, worldwide, in several different scenarios (service providers,
enterprise networks, etc.). enterprise networks, etc.).
skipping to change at page 3, line 50 skipping to change at page 3, line 50
monitoring equipment, managed bridges). monitoring equipment, managed bridges).
It has been raised also the issue of some hardware having limitations It has been raised also the issue of some hardware having limitations
in using prefixes longer then /64, for example using extra hardware in using prefixes longer then /64, for example using extra hardware
resources. resources.
[RFC6164] describes possible issues when using /64 for the point-to- [RFC6164] describes possible issues when using /64 for the point-to-
point links, however, it also states that they can be mitigated by point links, however, it also states that they can be mitigated by
other means, and indeed, considering the publication date of that other means, and indeed, considering the publication date of that
document, those issues should not be any longer a concern. The fact document, those issues should not be any longer a concern. The fact
is that many operators wordwide, today use /64 without any concerns, is that many operators worldwide, today use /64 without any concerns,
as vendors have taken the necessary code updates. as vendors have taken the necessary code updates.
Consequently, we shall conclude that it is a valid approach to use Consequently, we shall conclude that it is a valid approach to use
/64 prefixes for the point-to-point links. /64 prefixes for the point-to-point links.
3.2. Rationale for using /127 3.2. Rationale for using /127
[RFC6164] already do a complete review of reasons why /127 is a good [RFC6164] already do a complete review of reasons why /127 is a good
approach vs other options. However, it needs to be considered that approach vs other options. However, it needs to be considered that
it was published a number of years ago, and most of the hardware it was published a number of years ago, and most of the hardware
skipping to change at page 4, line 52 skipping to change at page 4, line 52
considered when numbering a point-to-point link. considered when numbering a point-to-point link.
It has been reported that certain hardware may consume resources when It has been reported that certain hardware may consume resources when
using numbered links. This is a very specific situation that may using numbered links. This is a very specific situation that may
need to be consider on a case by case basis. need to be consider on a case by case basis.
4.1. GUA (Global Unicast Addresses) 4.1. GUA (Global Unicast Addresses)
Using GUA is the most common approach. It provides full Using GUA is the most common approach. It provides full
functionality for both and end-points of the point-to-point links and functionality for both and end-points of the point-to-point links and
consequently, facilitates troubleshooting . consequently, facilitates troubleshooting.
4.2. ULA (Unique Local Addresses) 4.2. ULA (Unique Local Addresses)
Some networks use ULAs for numbering the point-to-point links. This Some networks use ULAs for numbering the point-to-point links. This
approach may cause numerous problems and therefore is strongly approach may cause numerous problems and therefore is strongly
discouraged. For example, if the CE needs to send an ICMPv6 message discouraged. For example, if the CE needs to send an ICMPv6 message
to a host outside that network (to the Internet), the packet with ULA to a host outside that network (to the Internet), the packet with ULA
source address will not get thru and PMTUD will break, which in turn source address will not get thru and PMTUD will break, which in turn
will completely break that IPv6 connection when the MTU is not the will completely break that IPv6 connection when the MTU is not the
same for all the path. same for all the path.
skipping to change at page 6, line 10 skipping to change at page 6, line 10
not be able to complete the DHCPv6-PD in unnumbered links. not be able to complete the DHCPv6-PD in unnumbered links.
The considerations indicated in the previous section, regarding not The considerations indicated in the previous section, regarding not
using ULA as source address of ICMPv6 messages, and instead ensuring using ULA as source address of ICMPv6 messages, and instead ensuring
there is at least one GUA configured for that, also apply if link- there is at least one GUA configured for that, also apply if link-
locals are used for the point-to-point link. locals are used for the point-to-point link.
5. Prefix Pool Choices 5. Prefix Pool Choices
The logic choice seems to use a dedicated pool of IPv6 addresses, as The logic choice seems to use a dedicated pool of IPv6 addresses, as
this is the way we are "used to" with IPv4. Actually this is done this is the way we are "used to" with IPv4. Actually, this is done
often by means of different IPv6 pools at every PoP in a service often by means of different IPv6 pools at every PoP in a service
provider network. provider network.
A possible benefit of using a dedicated IPv6 pool, is that allows A possible benefit of using a dedicated IPv6 pool, is that allows
applying security policies without harming the customers. This is applying security policies without harming the customers. This is
only true if customers always have a CE at their end of the WAN link. only true if customers always have a CE at their end of the WAN link.
However, the fact that the default IPv6 link size is /64 and commonly However, the fact that the default IPv6 link size is /64 and commonly
multiple /64's are assigned to a single customer, provides an multiple /64's are assigned to a single customer, provides an
interesting alternative approach for combining "best practices" interesting alternative approach for combining "best practices"
skipping to change at page 6, line 33 skipping to change at page 6, line 33
The following section depicts this alternative. The following section depicts this alternative.
6. /64 from Customer Prefix for point-to-point links 6. /64 from Customer Prefix for point-to-point links
Using a /64 from the customer prefix, in addition to the advantages Using a /64 from the customer prefix, in addition to the advantages
already indicated when using /64, simplifies the addressing plan. already indicated when using /64, simplifies the addressing plan.
The use of /64 also facilitates an easier way for routing the shorter The use of /64 also facilitates an easier way for routing the shorter
aggregated prefix into the point-to-point link. Consequently it aggregated prefix into the point-to-point link. Consequently it
simplifies the "view" of a more unified addressing plan, providing an simplifies the "view" of a more unified addressing plan, providing an
easier path for following up any issue when operating IPv6 networks, easier path for following up any issue when operating IPv6 networks
and typically will have a great impact in saving expensive hardware and typically, will have a great impact in saving expensive hardware
resources (lower usage of TCAM, typically by half). resources (lower usage of TCAM, typically by half).
This mechanism would not work in broadcast layer two media that rely This mechanism would not work in broadcast layer two media that rely
on ND (as it will try ND for all the addresses within the shorter on ND (as it will try ND for all the addresses within the shorter
prefix being delegated thru the point-to-point link). prefix being delegated thru the point-to-point link).
6.1. Numbering Interfaces 6.1. Numbering Interfaces
Often, in point-to-point links, hardware tokens are not available, or Often, in point-to-point links, hardware tokens are not available, or
there is the need to keep certain bits (u, g) cleared, so the links there is the need to keep certain bits (u, g) cleared, so the links
skipping to change at page 8, line 45 skipping to change at page 8, line 45
approach described in this document. approach described in this document.
6.4. Router Considerations 6.4. Router Considerations
This approach is being used by operators in both, residential/SOHO This approach is being used by operators in both, residential/SOHO
and enterprise networks, so the routers at the customer end for those and enterprise networks, so the routers at the customer end for those
networks MUST support [RFC6603] if DHCPv6-PD is used. networks MUST support [RFC6603] if DHCPv6-PD is used.
In the case of Customer Edge Routers there is a specific requirement In the case of Customer Edge Routers there is a specific requirement
([RFC7084]) WPD-8 (Prefix delegation Requirements), marked as SHOULD ([RFC7084]) WPD-8 (Prefix delegation Requirements), marked as SHOULD
for [RFC6603]. However, in an scenario where the approach described for [RFC6603]. However, in a scenario where the approach described
in this document is followed, together with DHCPv6-PD, the CE Router in this document is followed, together with DHCPv6-PD, the CE Router
MUST support [RFC6603]. MUST support [RFC6603].
7. Security Considerations 7. Security Considerations
This document does not have any new specific security considerations. This document does not have any new specific security considerations.
8. IANA Considerations 8. IANA Considerations
This document does not have any new specific IANA considerations. This document does not have any new specific IANA considerations.
9. Acknowledgements 9. Acknowledgements
The author would like to acknowledge the inputs of Mikael The author would like to acknowledge the inputs of Mikael
Abrahamsson, Brian Carpenter and ... Abrahamsson, Brian Carpenter and TBD.
Acknowledge is also due to my co-authors of RIPE-690 (Best Current Acknowledge is also due to my co-authors of RIPE-690 (Best Current
Operational Practice for Operators: IPv6 prefix assignment for end- Operational Practice for Operators: IPv6 prefix assignment for end-
users - persistent vs non-persistent, and what size to choose, users - persistent vs non-persistent, and what size to choose,
https://www.ripe.net/publications/docs/ripe-690) and global https://www.ripe.net/publications/docs/ripe-690) and global
community, which provided valuable inputs which have been key for community, which provided valuable inputs which have been key for
this document. this document.
Acknowledgement to co-authors, Cesar Olvera and Miguel Angel Diaz, of Acknowledgement to co-authors, Cesar Olvera and Miguel Angel Diaz, of
a previous related document (draft-palet-v6ops-point2point, 2006), as a previous related document (draft-palet-v6ops-point2point, 2006), as
 End of changes. 11 change blocks. 
13 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/