From 9765faf9e1d3afdb5baa65fba49d7e1c5656473c Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Tue, 9 May 2017 19:29:41 +0200 Subject: [PATCH] merge geoff's changes --- draft-nbourbaki-6man-classless-ipv6.txt | 132 ++++++++++++------------ draft-nbourbaki-6man-classless-ipv6.xml | 24 ++--- 2 files changed, 78 insertions(+), 78 deletions(-) diff --git a/draft-nbourbaki-6man-classless-ipv6.txt b/draft-nbourbaki-6man-classless-ipv6.txt index 3282134..f85dbbd 100644 --- a/draft-nbourbaki-6man-classless-ipv6.txt +++ b/draft-nbourbaki-6man-classless-ipv6.txt @@ -14,11 +14,11 @@ Expires: November 10, 2017 Abstract Over the history of IPv6, various classful address models have been - proposed, maybe the most notable being Top-Level Aggregation (TLA) - and Next-Level Aggregation (NLA) Identifiers. They have all proved - to be mistakes. The last remnant is a rigid boundary at /64. This - document removes that boundary as far as routing and addressing are - concerned. + proposed, with the most notable being Top-Level Aggregation (TLA) and + Next-Level Aggregation (NLA) Identifiers. They have all proved to be + mistakes. The last remnant of classful addressing is a rigid network + / interface identifier boundary at /64. This document removes that + boundary as far as routing and addressing are concerned. Status of This Memo @@ -65,56 +65,27 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2 - 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 4. A simple Statement . . . . . . . . . . . . . . . . . . . . . 3 - 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 - 8. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 4 - 10.2. Informative References . . . . . . . . . . . . . . . . . 5 + 3. A simple Statement . . . . . . . . . . . . . . . . . . . . . 3 + 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 + 7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 + 9.2. Informative References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Over the history of IPv6, various classful address models have been - proposed, maybe the most notable being Top-Level Aggregation (TLA) - and Next-Level Aggregation (NLA) Identifiers; see, for example, + proposed, with the most notable being Top-Level Aggregation (TLA) and + Next-Level Aggregation (NLA) Identifiers; see, for example, [RFC2450]. They have all proved to be mistakes. For example, TLA - and NLA were obsoleted by [RFC3587]. The last remnant is a rigid - boundary at /64. This document removes that boundary as far as - routing and addressing are concerned. - -2. Suggested Reading - - It is assumed that the reader understands the history of classful - addressing in IPv4 and why it was abolished [RFC4632]. Of course, - the acute need to conserve address space that forced the adoption of - classless addressing for IPv4 does not apply to IPv6; but the - arguments for operational flexibility in address allocation remain - compelling. - - It is also assumed that the reader understands IPv6 [RFC2460], the IP - Version 6 Addressing Architecture [RFC4291], the proposed changes to - RFC4291 [I-D.hinden-6man-rfc4291bis], and the recent recommendations - for the generation of stable Interface Identifiers [RFC8064]. - - An important recent IPv6 development was that, for host computers on - local area networks, the way in which interface identifiers were - formed was no longer bound to layer 2 addresses (MACs) [RFC7217] - [RFC8064]. Therefore their length, previously fixed at 64 bits - [RFC7136], is in fact a free parameter as stated in [RFC4862]. - - - -Bourbaki Expires November 10, 2017 [Page 2] - -Internet-Draft IPv6 is Classless May 2017 - - -3. Background + and NLA were obsoleted by [RFC3587]. The last remnant of classful + addressing is a rigid network / interface identifier boundary at /64. + This document removes that boundary as far as routing and addressing + are concerned. Some confusion has been caused by the IP Version 6 Addressing Architecture, [RFC4291], and the proposed changes in @@ -125,19 +96,50 @@ Internet-Draft IPv6 is Classless May 2017 formal specification be unclear risks potential mis-implementation by the naive, which could result in operational disasters. -4. A simple Statement +2. Suggested Reading + + It is assumed that the reader understands the history of classful + addressing in IPv4 and why it was abolished [RFC4632]. Of course, + the acute need to conserve address space that forced the adoption of + classless addressing for IPv4 does not apply to IPv6; but the + arguments for operational flexibility in address allocation remain + compelling. + + + + + +Bourbaki Expires November 10, 2017 [Page 2] + +Internet-Draft IPv6 is Classless May 2017 + + + It is also assumed that the reader understands IPv6 [RFC2460], the IP + Version 6 Addressing Architecture [RFC4291], the proposed changes to + RFC4291 [I-D.hinden-6man-rfc4291bis], and the recent recommendations + for the generation of stable Interface Identifiers [RFC8064]. + + An important recent IPv6 development was that, for host computers on + local area networks, the way in which interface identifiers were + formed was no longer bound to layer 2 addresses (MACs) [RFC7217] + [RFC8064]. Therefore their length, previously fixed at 64 bits + [RFC7136], is in fact a variably-sized parameter as stated in + [RFC4862]. + +3. A simple Statement To state it simply, IPv6 unicast subnetting is based on prefixes of any valid length up to 128 except for links where an Internet Standard such as, for example, Stateless Address AutoConfiguration - [RFC4862], or Using 127-Bit IPv6 Prefixes on Inter-Router Links - [RFC6164] is in use. + (SLAAC) [RFC4862], or Using 127-Bit IPv6 Prefixes on Inter-Router + Links [RFC6164] is in use. - Nodes must always support rotuing on any valid length, even if SLAAC - or other standards are in use because routing could choose to - differentiate at a different granularity. + Nodes must always support routing on any valid network prefix length, + even if SLAAC or other standards are in use, because routing could + choose to differentiate at a different granularity than is used by + any such automated link local address configuration tools. -5. Recommendations +4. Recommendations For historical reasons, when a prefix is needed on a link, barring other considerations, a /64 is recommended [RFC7136]. @@ -152,7 +154,7 @@ Internet-Draft IPv6 is Classless May 2017 None the less, there is no reason in theory why an IPv6 node should not operate with different interface identfier lengths on different - physical interfaces. Thus a correct implementation of SLAAC must in + physical interfaces. Thus, a correct implementation of SLAAC must in fact allow for any prefix length, with the value being a parameter per interface. For instance, the Interface Identifier length in the recommended (see [RFC8064]) algorithm for selecting stable interface @@ -163,14 +165,12 @@ Internet-Draft IPv6 is Classless May 2017 - - Bourbaki Expires November 10, 2017 [Page 3] Internet-Draft IPv6 is Classless May 2017 -6. Security Considerations +5. Security Considerations Assumming that nodes employ unpredictable interface identifiers [RFC7721], the subnet size may have an impact on some security and @@ -186,23 +186,23 @@ Internet-Draft IPv6 is Classless May 2017 operational limit on such data structures, thus helping mitigate some pathological behaviors (such as Neighbor Cache Exhaustion attacks). -7. IANA Considerations +6. IANA Considerations This document has no IANA Considerations. -8. Authors +7. Authors The original draft was by Randy Bush, who was immediately aided and abetted by Brian Carpenter, Chris Morrow, Fernando Gont, Geoff Huston, Job Snijders, [ your name here ]. -9. Acknowledgments +8. Acknowledgments The authors wish to thank . -10. References +9. References -10.1. Normative References +9.1. Normative References [RFC2450] Hinden, R., "Proposed TLA and NLA Assignment Rules", RFC 2450, December 1998. @@ -231,7 +231,7 @@ Internet-Draft IPv6 is Classless May 2017 RFC 8064, DOI 10.17487/RFC8064, February 2017, . -10.2. Informative References +9.2. Informative References [I-D.hinden-6man-rfc4291bis] Hinden, B. and S. Deering, "IP Version 6 Addressing diff --git a/draft-nbourbaki-6man-classless-ipv6.xml b/draft-nbourbaki-6man-classless-ipv6.xml index b491d2e..2e21b36 100644 --- a/draft-nbourbaki-6man-classless-ipv6.xml +++ b/draft-nbourbaki-6man-classless-ipv6.xml @@ -122,7 +122,8 @@ rate is low enough. formed was no longer bound to layer 2 addresses (MACs) . Therefore their length, previously fixed at 64 bits , is in - fact a variably-sized parameter as stated in . + fact a variably-sized parameter as stated in . @@ -131,14 +132,15 @@ rate is low enough. To state it simply, IPv6 unicast subnetting is based on prefixes of any valid length up to 128 except for links where an Internet - Standard such as, for example, Stateless Address AutoConfiguration (SLAAC) - , or Using 127-Bit IPv6 Prefixes on + Standard such as, for example, Stateless Address AutoConfiguration + (SLAAC) , or Using 127-Bit IPv6 Prefixes on Inter-Router Links is in use. - Nodes must always support routing on any valid network prefix length, even if - SLAAC or other standards are in use, because routing could choose to - differentiate at a different granularity than is used by any such automated link local - address configuration tools. + Nodes must always support routing on any valid network prefix + length, even if SLAAC or other standards are in use, because routing + could choose to differentiate at a different granularity than is + used by any such automated link local address configuration + tools. - + are employed for point to point links. -->
@@ -190,8 +190,8 @@ rate is low enough. security and privacy properties of a network. Namely, the smaller the subnet size, the more feasible it becomes to perform IPv6 address scans . - For some specific subnets, such as point to point links, this may - be less of an issue. + For some specific subnets, such as point to point links, this may be + less of an issue. On the other hand, we assume that a number of IPv6 implementations fail to enforce limits on the size of some of the