Internet DRAFT - draft-palet-v6ops-p2p-from-customer-prefix
draft-palet-v6ops-p2p-from-customer-prefix
v6ops J. Palet Martinez
Internet-Draft The IPv6 Company
Intended status: Best Current Practice October 28, 2017
Expires: May 1, 2018
Using /64 from Customer Prefix for the Inter-Router Link
draft-palet-v6ops-p2p-from-customer-prefix-01
Abstract
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.
Status of This Memo
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 1, 2018.
Copyright Notice
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.
Palet Martinez Expires May 1, 2018 [Page 1]
Internet-Draft Point-to-Point from Customer Prefix October 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Rational for using /64 . . . . . . . . . . . . . . . . . . . 3
3. Numbering Interfaces . . . . . . . . . . . . . . . . . . . . 3
4. Routing Aggregation of the Point-to-Point Links . . . . . . . 3
5. DHCPv6 Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Router Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
10. Normative References . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
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).
Palet Martinez Expires May 1, 2018 [Page 2]
Internet-Draft Point-to-Point from Customer Prefix October 2017
2. Rational for using /64
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.
3. Numbering Interfaces
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].
4. Routing Aggregation of the Point-to-Point Links
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.
Palet Martinez Expires May 1, 2018 [Page 3]
Internet-Draft Point-to-Point from Customer Prefix October 2017
Let's see a practical example:
o A service provider uses the prefix 2001:db8::/32 and is using
2001:db8:aaaa::/48 for a given customer.
o Instead of allocating the point-to-point link from a different
addressing pool, it may use 2001:db8:aaaa::/64 (which is the first
/64 subnet from the 2001:db8:aaaa::/48) to number the link.
o This means that, in the case the non-EUI-64 approach is used, the
point-to-point link may be numbered as 2001:db8:aaaa::1/64 for the
provider side and 2001:db8:aaaa::2/64 for the customer side.
o Note that using the first /64 and interface identifiers 1 and 2 is
a very common practice. However other values may be chosen
according to each case specific needs.
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:
o Point-to-point link at provider side: 2001:db8:aaaa::1/48
o Point-to-point link at customer side: 2001:db8:aaaa::2/64
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
Palet Martinez Expires May 1, 2018 [Page 4]
Internet-Draft Point-to-Point from Customer Prefix October 2017
failures or interoperability issues have been reported.
5. DHCPv6 Considerations
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.
6. Router Considerations
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].
7. Security Considerations
This document does not have any new specific security considerations.
8. IANA Considerations
This document does not have any new specific IANA considerations.
9. Acknowledgements
The author would like to acknowledge the inputs of Mikael Abrahamsson
... Acknowledgement to co-authors, Cesar Olvera and Miguel Angel
Diaz, 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.
Palet Martinez Expires May 1, 2018 [Page 5]
Internet-Draft Point-to-Point from Customer Prefix October 2017
10. Normative References
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
DOI 10.17487/RFC3633, December 2003,
<https://www.rfc-editor.org/info/rfc3633>.
[RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", RFC 3769, DOI 10.17487/RFC3769, June 2004,
<https://www.rfc-editor.org/info/rfc3769>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011,
<https://www.rfc-editor.org/info/rfc6164>.
[RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O.
Troan, "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012,
<https://www.rfc-editor.org/info/rfc6603>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<https://www.rfc-editor.org/info/rfc7707>.
Author's Address
Jordi Palet Martinez
The IPv6 Company
Molino de la Navata, 75
La Navata - Galapagar, Madrid 28420
Spain
Email: jordi.palet@theipv6company.com
URI: http://www.theipv6company.com/
Palet Martinez Expires May 1, 2018 [Page 6]
