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

Merge pull request #5 from nickhilliard/master

Browse source 
refactor text
This commit is contained in:
Randy Bush 2017-05-15 02:27:15 +09:00 • committed by GitHub
commit 7ce39e3f1c
1 changed files with 62 additions and 57 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -11,7 +11,7 @@
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<rfc category="std" docName="draft-bourbaki-6man-classless-ipv6-00" ipr="trust200902">
<rfc category="std" docName="draft-bourbaki-6man-classless-ipv6-00" ipr="trust200902" updates="4291">
<front>
<title>IPv6 is Classless</title>
@ -34,13 +34,11 @@
<abstract>
<t>Over the history of IPv6, various classful address models have
been 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.</t>
<t>Over the history of IPv6, various classful address models have been
proposed, none of which has withstood the test of time. The last
remnant of IPv6 classful addressing is a rigid network interface
identifier boundary at /64. This document removes that boundary for
routing and interface addressing.</t>
</abstract>
@ -63,26 +61,25 @@
<section anchor="intro" title="Introduction">
<t>Over the history of IPv6, various classful address models have
been proposed, with the most notable being Top-Level Aggregation
(TLA) and Next-Level Aggregation (NLA) Identifiers; see, for
example, <xref target="RFC2450"/>. They have all proved to be
mistakes. For example, TLA and NLA were obsoleted by <xref
target="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.</t>
<t>Over the history of the IPv6 protocol, several classful addressing
models have been proposed. The most notable example recommended Top-Level
Aggregation (TLA) and Next-Level Aggregation (NLA) Identifiers <xref
target="RFC2450"/>, but was obsoleted by <xref target="RFC3587"/>, leaving
a single remnant of classful addressing in IPv6: a rigid network
interface identifier boundary at /64. This document removes that
boundary for interface addressing.</t>
<t>Some confusion has been caused by the IP Version 6 Addressing
Architecture, <xref target="RFC4291"/>, and the proposed changes in
<xref target="I-D.ietf-6man-rfc4291bis"/> with respect to the
minimum subnet size.</t>
<t>Recent proposed changes to the IP Version 6 Addressing Architecture
specification <xref target="RFC4291"/> have caused controversy.
While link prefixes of varied lengths, e.g. /127, /126, /124,
/120, ... /64 have been successfully deployed for many years, glaring
mismatches between a formal specification and long-standing field
deployment practices are never wise, not least because of the strong
risk of mis-implementation, which can easily result in serious
operational problems.</t>
<t>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 naïve, which could result in operational
disasters.</t>
<t>This document also clarifies that IPv6 routing subnets may be of any
length up to 128.</t>
</section>
@ -92,15 +89,15 @@
addressing in IPv4 and why it was abolished <xref
target="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.</t>
not apply to IPv6, but the arguments for operational flexibility in
address assignment remain compelling.</t>
<t>It is also assumed that the reader understands IPv6 <xref
target="RFC2460"/>, the IP Version 6 Addressing Architecture <xref
target="RFC4291"/>, the proposed changes to RFC4291 <xref
target="I-D.ietf-6man-rfc4291bis"/> and RFC2464
<xref target="I-D.hinden-6man-rfc2464bis"/>, and the recent
recommendations for the generation of stable Interface Identifiers
<xref target="I-D.hinden-6man-rfc2464bis"/>, and the IETF
recommendation for the generation of stable Interface Identifiers
<xref target="RFC8064"/>.</t>
<!--
@ -116,31 +113,39 @@ backward compatibility. (*)
rate is low enough.
-->
<t>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) <xref
target="RFC7217"/> <xref target="RFC8064"/>. Therefore their
length, previously fixed at 64 bits <xref target="RFC7136"/>, is in
fact a variably-sized parameter as stated in <xref
target="RFC4862"/>.</t>
<t>For host computers on local area networks, generation of interface
identifiers is no longer necessarily bound to layer 2 addresses (MACs)
<xref target="RFC7217"/> <xref target="RFC8064"/>. Therefore their
length, previously fixed at 64 bits <xref target="RFC7136"/>, is in fact
a variably-sized parameter as explicitly acknowledged in Section
5.5.3(d) of <xref target="RFC4862"/> which states:
<list><t>
Note that a future revision of the address architecture [RFC4291]
and a future link-type-specific document, which will still be
consistent with each other, could potentially allow for an
interface identifier of length other than the value defined in the
current documents. Thus, an implementation should not assume a
particular constant. Rather, it should expect any lengths of
interface identifiers.
</t></list>
</t>
</section>
<section anchor="statement" title="Identifier and Subnet Length Statements">
<section anchor="simple" title="A simple Statement">
<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
Standard that has nothing to do with routing may impose a
particular length. Examples are Stateless Address AutoConfiguration
<t>IPv6 unicast interfaces may use any subnet length up to 128 except
for situations where an Internet Standard document may impose a
particular length, for example Stateless Address Autoconfiguration
(SLAAC) <xref target="RFC4862"/>, or Using 127-Bit IPv6 Prefixes on
Inter-Router Links <xref target="RFC6164"/>.</t>
<t>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.</t>
<t>Additionally, this document clarifies that a node or router MUST
support routing of 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.</t>
<!-- [fgont] I think these section is mixing up to things:
@ -166,7 +171,7 @@ rate is low enough.
target="RFC7136"/>.</t>
<t>The length of the Interface Identifier in Stateless Address
AutoConfiguration <xref target="RFC4862"/> is a parameter; its
Autoconfiguration <xref target="RFC4862"/> is a parameter; its
length SHOULD 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
@ -187,7 +192,7 @@ rate is low enough.
<section anchor="security" title="Security Considerations">
<t>Assumming that nodes employ unpredictable interface identifiers
<t>Assuming that nodes employ unpredictable interface identifiers
<xref target="RFC7721"/>, the subnet size may have an impact on some
security and privacy properties of a network. Namely, the smaller
the subnet size, the more feasible it becomes to perform IPv6