randy/draft-classless6
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

merge geoff's changes

Browse source
This commit is contained in:
Randy Bush 2017-05-09 19:29:41 +02:00
parent b192deaefd
commit 9765faf9e1
2 changed files with 78 additions and 78 deletions
Download patch file Download diff file Expand all files Collapse all files

132
draft-nbourbaki-6man-classless-ipv6.txt
View file

@ -14,11 +14,11 @@ Expires: November 10, 2017
Abstract Abstract
Over the history of IPv6, various classful address models have been Over the history of IPv6, various classful address models have been
proposed, maybe the most notable being Top-Level Aggregation (TLA) proposed, with the most notable being Top-Level Aggregation (TLA) and
and Next-Level Aggregation (NLA) Identifiers. They have all proved Next-Level Aggregation (NLA) Identifiers. They have all proved to be
to be mistakes. The last remnant is a rigid boundary at /64. This mistakes. The last remnant of classful addressing is a rigid network
document removes that boundary as far as routing and addressing are / interface identifier boundary at /64. This document removes that
concerned. boundary as far as routing and addressing are concerned.
Status of This Memo Status of This Memo
@ -65,56 +65,27 @@ Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. A simple Statement . . . . . . . . . . . . . . . . . . . . . 3
4. A simple Statement . . . . . . . . . . . . . . . . . . . . . 3 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 9.1. Normative References . . . . . . . . . . . . . . . . . . 4
10.1. Normative References . . . . . . . . . . . . . . . . . . 4 9.2. Informative References . . . . . . . . . . . . . . . . . 5
10.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
Over the history of IPv6, various classful address models have been Over the history of IPv6, various classful address models have been
proposed, maybe the most notable being Top-Level Aggregation (TLA) proposed, with the most notable being Top-Level Aggregation (TLA) and
and Next-Level Aggregation (NLA) Identifiers; see, for example, Next-Level Aggregation (NLA) Identifiers; see, for example,
[RFC2450]. They have all proved to be mistakes. For example, TLA [RFC2450]. They have all proved to be mistakes. For example, TLA
and NLA were obsoleted by [RFC3587]. The last remnant is a rigid and NLA were obsoleted by [RFC3587]. The last remnant of classful
boundary at /64. This document removes that boundary as far as addressing is a rigid network / interface identifier boundary at /64.
routing and addressing are concerned. 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
Some confusion has been caused by the IP Version 6 Addressing Some confusion has been caused by the IP Version 6 Addressing
Architecture, [RFC4291], and the proposed changes in 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 formal specification be unclear risks potential mis-implementation by
the naive, which could result in operational disasters. 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 To state it simply, IPv6 unicast subnetting is based on prefixes of
any valid length up to 128 except for links where an Internet any valid length up to 128 except for links where an Internet
Standard such as, for example, Stateless Address AutoConfiguration Standard such as, for example, Stateless Address AutoConfiguration
[RFC4862], or Using 127-Bit IPv6 Prefixes on Inter-Router Links (SLAAC) [RFC4862], or Using 127-Bit IPv6 Prefixes on Inter-Router
[RFC6164] is in use. Links [RFC6164] is in use.
Nodes must always support rotuing on any valid length, even if SLAAC Nodes must always support routing on any valid network prefix length,
or other standards are in use because routing could choose to even if SLAAC or other standards are in use, because routing could
differentiate at a different granularity. 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 For historical reasons, when a prefix is needed on a link, barring
other considerations, a /64 is recommended [RFC7136]. 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 None the less, there is no reason in theory why an IPv6 node should
not operate with different interface identfier lengths on different 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 fact allow for any prefix length, with the value being a parameter
per interface. For instance, the Interface Identifier length in the per interface. For instance, the Interface Identifier length in the
recommended (see [RFC8064]) algorithm for selecting stable interface 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] Bourbaki Expires November 10, 2017 [Page 3]
Internet-Draft IPv6 is Classless May 2017 Internet-Draft IPv6 is Classless May 2017
6. Security Considerations 5. Security Considerations
Assumming that nodes employ unpredictable interface identifiers Assumming that nodes employ unpredictable interface identifiers
[RFC7721], the subnet size may have an impact on some security and [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 operational limit on such data structures, thus helping mitigate some
pathological behaviors (such as Neighbor Cache Exhaustion attacks). pathological behaviors (such as Neighbor Cache Exhaustion attacks).
7. IANA Considerations 6. IANA Considerations
This document has no IANA Considerations. This document has no IANA Considerations.
8. Authors 7. Authors
The original draft was by Randy Bush, who was immediately aided and The original draft was by Randy Bush, who was immediately aided and
abetted by Brian Carpenter, Chris Morrow, Fernando Gont, Geoff abetted by Brian Carpenter, Chris Morrow, Fernando Gont, Geoff
Huston, Job Snijders, [ your name here ]. Huston, Job Snijders, [ your name here ].
9. Acknowledgments 8. Acknowledgments
The authors wish to thank . 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", [RFC2450] Hinden, R., "Proposed TLA and NLA Assignment Rules",
RFC 2450, December 1998. RFC 2450, December 1998.
@ -231,7 +231,7 @@ Internet-Draft IPv6 is Classless May 2017
RFC 8064, DOI 10.17487/RFC8064, February 2017, RFC 8064, DOI 10.17487/RFC8064, February 2017,
<http://www.rfc-editor.org/info/rfc8064>. <http://www.rfc-editor.org/info/rfc8064>.
10.2. Informative References 9.2. Informative References
[I-D.hinden-6man-rfc4291bis] [I-D.hinden-6man-rfc4291bis]
Hinden, B. and S. Deering, "IP Version 6 Addressing Hinden, B. and S. Deering, "IP Version 6 Addressing

24
draft-nbourbaki-6man-classless-ipv6.xml
View file

@ -122,7 +122,8 @@ rate is low enough.
formed was no longer bound to layer 2 addresses (MACs) <xref formed was no longer bound to layer 2 addresses (MACs) <xref
target="RFC7217"/> <xref target="RFC8064"/>. Therefore their target="RFC7217"/> <xref target="RFC8064"/>. Therefore their
length, previously fixed at 64 bits <xref target="RFC7136"/>, is in length, previously fixed at 64 bits <xref target="RFC7136"/>, is in
fact a variably-sized parameter as stated in <xref target="RFC4862"/>.</t> fact a variably-sized parameter as stated in <xref
target="RFC4862"/>.</t>
</section> </section>
@ -131,14 +132,15 @@ rate is low enough.
<t>To state it simply, IPv6 unicast subnetting is based on prefixes <t>To state it simply, IPv6 unicast subnetting is based on prefixes
of any valid length up to 128 except for links where an Internet of any valid length up to 128 except for links where an Internet
Standard such as, for example, Stateless Address AutoConfiguration (SLAAC) Standard such as, for example, Stateless Address AutoConfiguration
<xref target="RFC4862"/>, or Using 127-Bit IPv6 Prefixes on (SLAAC) <xref target="RFC4862"/>, or Using 127-Bit IPv6 Prefixes on
Inter-Router Links <xref target="RFC6164"/> is in use.</t> Inter-Router Links <xref target="RFC6164"/> is in use.</t>
<t>Nodes must always support routing on any valid network prefix length, even if <t>Nodes must always support routing on any valid network prefix
SLAAC or other standards are in use, because routing could choose to length, even if SLAAC or other standards are in use, because routing
differentiate at a different granularity than is used by any such automated link local could choose to differentiate at a different granularity than is
address configuration tools.</t> used by any such automated link local address configuration
tools.</t>
<!-- [fgont] I think these section is mixing up to things: <!-- [fgont] I think these section is mixing up to things:
@ -153,9 +155,7 @@ rate is low enough.
should be able to employ any subnet size that they should be able to employ any subnet size that they
please, except when slaac is in use (for backwards please, except when slaac is in use (for backwards
compatibility) or e.g. when /127 (or the like) prefixes compatibility) or e.g. when /127 (or the like) prefixes
are employed for point to point links. are employed for point to point links. --> </section>
-->
</section>
<section anchor="notes" title="Recommendations"> <section anchor="notes" title="Recommendations">
@ -190,8 +190,8 @@ rate is low enough.
security and privacy properties of a network. Namely, the smaller security and privacy properties of a network. Namely, the smaller
the subnet size, the more feasible it becomes to perform IPv6 the subnet size, the more feasible it becomes to perform IPv6
address scans <xref target="RFC7707"/> <xref target="RFC7721"/>. address scans <xref target="RFC7707"/> <xref target="RFC7721"/>.
For some specific subnets, such as point to point links, this may For some specific subnets, such as point to point links, this may be
be less of an issue.</t> less of an issue.</t>
<t>On the other hand, we assume that a number of IPv6 <t>On the other hand, we assume that a number of IPv6
implementations fail to enforce limits on the size of some of the implementations fail to enforce limits on the size of some of the