diff --git a/draft-nbourbaki-6man-classless-ipv6.xml b/draft-nbourbaki-6man-classless-ipv6.xml index 3358273..eaa2815 100644 --- a/draft-nbourbaki-6man-classless-ipv6.xml +++ b/draft-nbourbaki-6man-classless-ipv6.xml @@ -34,10 +34,11 @@ - Over the history of IPv6, there have been many classful address - models; TLA and NLA being outstanding examples. They have all been - shown to be mistakes. The last remaining is a magic boundary at - /64. This document removes that last bit of useless magic. + Over the history of IPv6, various classful address models have + been proposed, particularly 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 rigidity as far as routing is concerned. @@ -47,20 +48,40 @@
- Over the history of IPv6, there have been many classful address - models; TLA and NLA being outstanding examples. They have all been - shown to be mistakes. The last remaining is a magic boundary at - /64. This document removes that last bit of useless magic. + Over the history of IPv6, various classful address models have + been proposed, particularly Top-Level Aggregation (TLA) and + Next-Level Aggregation(NLA) Identifiers. They have all proved to be + mistakes. For example, TLA and NLA were obsoleted by . The last remnant is a rigid boundary at + /64. This document removes that rigidity as far as routing is + concerned.
+ + It is assumed that the reader understands the history of classful + addressing in IPv4 and why it was abolished . 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 assumed that the reader understands IPv6, It is also assumed that the reader understands IPv6, , IP Version 6 Addressing Architecture, see , and the proposed changes to , see . + + NOTE: do we mean 4291bis (currently moribund) or 2464bis? + + An important recent development in IPv6 is that for host + computers on local area networks, the way in which interface + identifiers are formed is no longer bound to layer 2 addresses (MAC + addresses) . We can therefore appreciate + that their length, previously fixed at 64 bits , is in fact a free parameter as stated in .
@@ -75,10 +96,11 @@ Some confusion has been caused by the IP Version 6 Addressing Architecture, , and the proposed changes in with respect to allowed - maximum prefix lengths and the minimum host part on a link. + maximum prefix lengths and the minimum host part (sometimes known as + interface identifier) on a link. - In the meantime, link prefixes of varied lengths, /127, /126, - /124, /120, ... /64 have been successfully deployed for many years. + Meanwhile, link prefixes of varied lengths, /127, /126, /124, + /120, ... /64 have been successfully deployed for many years. Having the formal specification be unclear risks potential mis-implementation by the naive, which could result in operational disasters. @@ -89,30 +111,44 @@ To state it simply, IPv6 unicast routing is based on prefixes of any valid length up to 128 except for links where an Internet - Standard such as Stateless Address Configuration , or Using 127-Bit IPv6 Prefixes on Inter-Router - Links is in use. - - + Standard such as, for example, Stateless Address AutoConfiguration + , or Using 127-Bit IPv6 Prefixes on + Inter-Router Links is in use. + +
For historical reasons, when a prefix is needed on a link, - barring other considerations, a /64 is traditional. + barring other considerations, a /64 is traditional . The length of the prefix identifier in Stateless Address - Configuration, is a parameter; its length - needs to be sufficient for effective randomization for privacy - reasons. For example, a /48 would be sufficient. But operationally - we recommend, barring strong considerations to the contrary, using - 64-bits for SLAAC in order not to discover where 64-bits was - hard-coded. + AutoConfiguration, is a parameter; its + length needs to be sufficient for effective randomization for + privacy reasons. For example, a /48 might be sufficient. But + operationally we recommend, barring strong considerations to the + contrary, using 64-bits for SLAAC in order not to discover bugs + where 64-bits was hard-coded, and to favor portability of devices + and operating systems. + + 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 fact allow for any length of prefix, with the value + being parameterised per interface. + + NOTE: should we comment on the fact that at least Linux and + Windows seem to assume that the default prefix is /64 in the + management CLI?
- This document has no known security impact. + This document has no known security impact, assuming that + user devices use an unpredictable interface identifier + for privacy.
@@ -130,7 +166,7 @@
The original draft was by Randy Bush, who was immediately aided - and abetted by Job Snijders, [ your name here ]. + and abetted by Brian Carpenter, Job Snijders, [ your name here ].
@@ -152,6 +188,11 @@ + + + + +