| v6ops | J. Palet Martinez |
| Internet-Draft | The IPv6 Company |
| Intended status: Best Current Practice | October 29, 2017 |
| Expires: May 2, 2018 |
Using /64 from Customer Prefix for the Inter-Router Link
draft-palet-v6ops-p2p-from-customer-prefix-01
This document describes the usage of a /64 from the customer prefix for numbering IPv6 point-to-point links in non-broadcast layer 2 media.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 2, 2018.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
There are different alternatives for numbering IPv6 point-to-point links, and from an operational perspective, they may have different advantages or disadvantages that need to be taken in consideration under the scope of each specific network architecture design.
[RFC6164] describes using /127 prefixes for inter-router point-to-point links, using two different address pools, one for numbering the 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 other choices.
This document describes an alternative the approach, using a /64 from the customer prefix, which ensure compliance with standards, and consequently facilitate interoperability, avoids possible future issues if more addresses are needed (e.g., managed bridges) and simplifies the addressing plan.
The use of /64 also facilitates an easier way for routing the shorter aggregated prefix into the point-to-point link. Consequently it simplifies the "view" of a more unified addressing plan, providing an easier path for following up any issue when operating IPv6 networks.
The proposed approach is suitable for those point-to-point links connecting ISP to Customers and enterprise networks, but not limited to those cases, and in fact, is being used by a relevant number of networks worldwide, in several different scenarios.
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 prefix being delegated thru the point-to-point link).
The IPv6 Addressing Architecture ([RFC4291]) specifies that all the Interface Identifiers for all the unicast addresses (except for 000/3) are required to be 64 bits long and to be constructed in Modified EUI-64 format.
The same document also mandates the usage of the predefined subnet-router anycast address, which has cleared to zero all the bits that do not form the subnet prefix.
[RFC6164] describes possible issues when using /64 for the point-to-point linkes, however, it also states that they can be mitigated by other means, and indeed, considering the publication date of that document, those issues should not be any longer considered. The fact is that many operators wordwide, today use /64 without any concerns, as vendors have taken the necessary code updates.
Consequently, we shall conclude that /64 it is a valid approach to use /64 prefixes for the point-to-point links.
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 can be manually numbered sequentially with most of the bits cleared to zero. This numbering makes as well easier to remember the interfaces, which typically will become numbered as 1 (with 63 leading zero bits) for the provider side and 2 (with 63 leading zero bits) for the customer side.
Using interface identifiers as 1 and 2 is not only a very simple approach, but also a very common practice. Other different choices can as well be used as required in each case.
On the other hand, using the EUI-64, makes it more difficult to remember and handle the interfaces, but provides an additional degree of protection against port (actually address) scanning as described at [RFC7707].
Following this approach and assuming that a shorter prefix is typically delegated to a customer, for example a /48, it is possible to simplify the routing aggregation of the point-to-point links. Towards this, the point-to-point link may be numbered using the first /64 of the /48 delegated to the customer.
Let's see a practical example:
In this way, as the same address pool is being used for both, the prefix and the point-to-point link, one of the advantages of this approach is to make very easy the recognition of the point-to-point link that belongs to a given customer prefix, or in the other way around, the recognition of the prefix that is linked by a given point-to-point link.
For example, making a trace-route to debug any issue to a given address in the provider network, will show a straight view, and it becomes unnecessary one extra step to check a database that correlate an address pool for the point-to-point links and the customer prefixes, as all they are the same.
Moreover, it is possible to use the shorter prefix as the provider side numbering for the point-to-point link and keep the /64 for the customer side. In our example, it will become:
This provides one additional advantage as in some platforms the configuration may be easier saving one step for the route of the delegated prefix (no need for two routes to be configured, one for the delegated prefix, one for the point-to-point link). It is possible because the longest-prefix-match rule.
The behavior of this type of configuration has been successfully deployed in different operator and enterprise networks, using commonly available implementations with different routing protocols, including RIP, BGP, IS-IS, OSPF, along static routing, and no failures or interoperability issues have been reported.
As stated in [RFC3633], "the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which is received the DHCP message from the delegating router", however the approach described in this document is still useful in other DHCPv6 scenarios or non-DHCPv6 scenarios.
Furthermore, [RFC3633] was updated by Prefix Exclude Option for DHCPv6-based Prefix Delegation ([RFC6603]), precisely to define a new DHCPv6 option, which covers the case described by this document.
Moreover, [RFC3769] has no explicit requirement that avoids the approach described in this document.
This approach is being used by operators in both, residential/SOHO and enterprise networks, so the routers at the customer end for those networks MUST support [RFC6603] if DHCPv6-PD is used.
In the case of Customer Edge Routers there is a specific requirement ([RFC7084]) WPD-8 (Prefix delegation Requirements), marked as SHOULD for [RFC6603]. However, in an scenario where the approach described in this document is followed, together with DHCPv6-PD, the CE Router MUST support [RFC6603].
This document does not have any new specific security considerations.
This document does not have any new specific IANA considerations.
The author would like to acknowledge the inputs of Mikael Abrahamsson ... Acknowledgement to co-authors, Cesar Olvera and Miguel Angel Díaz, of a previous related document (draft-palet-v6ops-point2point, 2006), as well as inputs for that version from Alain Durand, Chip Popoviciu, Daniel Roesen, Fred Baker, Gert Doering, Olaf Bonness, Ole Troan, Pekka Savola and Vincent Jardin, are also granted.