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

Refactor abstract, intro and recommended reading.

Browse source 
- added quote from RFC4862 to remind readers that /64 is a parameter.

- one semantic change made, namely that routing subnets are already classless,
so this was removed from the intro.

- fix typo
This commit is contained in:
Nick Hilliard 2017-05-14 12:06:01 +01:00
parent 1a97a337ea
commit cb1a987e43
1 changed files with 42 additions and 39 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -34,13 +34,11 @@
<abstract> <abstract>
<t>Over the history of IPv6, various classful address models have <t>Over the history of IPv6, various classful address models have been
been proposed, with the most notable being Top-Level Aggregation proposed, none of which has withstood the test of time. The last
(TLA) and Next-Level Aggregation (NLA) Identifiers. They have all remnant of IPv6 classful addressing is a rigid network interface
proved to be mistakes. The last remnant of classful addressing is identifier boundary at /64. This document removes that boundary for
a rigid network / interface identifier boundary at /64. routing and interface addressing.</t>
This document removes that boundary as far as routing and addressing
are concerned.</t>
</abstract> </abstract>
@ -63,26 +61,22 @@
<section anchor="intro" title="Introduction"> <section anchor="intro" title="Introduction">
<t>Over the history of IPv6, various classful address models have <t>Over the history of the IPv6 protocol, several classful addressing
been proposed, with the most notable being Top-Level Aggregation models have been proposed. The most notable example recommended Top-Level
(TLA) and Next-Level Aggregation (NLA) Identifiers; see, for Aggregation (TLA) and Next-Level Aggregation (NLA) Identifiers <xref
example, <xref target="RFC2450"/>. They have all proved to be target="RFC2450"/>, but was obsoleted by <xref target="RFC3587"/>, leaving
mistakes. For example, TLA and NLA were obsoleted by <xref a single remnant of classful addressing in IPv6: a rigid network
target="RFC3587"/>. The last remnant of classful addressing is a interface identifier boundary at /64. This document removes that
rigid network / interface identifier boundary at /64. boundary for interface addressing.</t>
This document removes that boundary as far as routing and addressing
are concerned.</t>
<t>Some confusion has been caused by the IP Version 6 Addressing <t>Recent proposed changes to the IP Version 6 Addressing Architecture
Architecture, <xref target="RFC4291"/>, and the proposed changes in specification <xref target="RFC4291"/> have caused controversy.
<xref target="I-D.ietf-6man-rfc4291bis"/> with respect to the While link prefixes of varied lengths, e.g. /127, /126, /124,
minimum subnet size.</t> /120, ... /64 have been successfully deployed for many years, glaring
mismatches between a formal specification and long-standing field
<t>Meanwhile, link prefixes of varied lengths, /127, /126, /124, deployment practices are never wise, not least because of the strong
/120, ... /64 have been successfully deployed for many years. risk of mis-implementation, which can easily result in serious
Having the formal specification be unclear risks potential operational problems.</t>
mis-implementation by the naïve, which could result in operational
disasters.</t>
</section> </section>
@ -92,15 +86,15 @@
addressing in IPv4 and why it was abolished <xref addressing in IPv4 and why it was abolished <xref
target="RFC4632"/>. Of course, the acute need to conserve address target="RFC4632"/>. Of course, the acute need to conserve address
space that forced the adoption of classless addressing for IPv4 does space that forced the adoption of classless addressing for IPv4 does
not apply to IPv6; but the arguments for operational flexibility in not apply to IPv6, but the arguments for operational flexibility in
address allocation remain compelling.</t> address assignment remain compelling.</t>
<t>It is also assumed that the reader understands IPv6 <xref <t>It is also assumed that the reader understands IPv6 <xref
target="RFC2460"/>, the IP Version 6 Addressing Architecture <xref target="RFC2460"/>, the IP Version 6 Addressing Architecture <xref
target="RFC4291"/>, the proposed changes to RFC4291 <xref target="RFC4291"/>, the proposed changes to RFC4291 <xref
target="I-D.ietf-6man-rfc4291bis"/> and RFC2464 target="I-D.ietf-6man-rfc4291bis"/> and RFC2464
<xref target="I-D.hinden-6man-rfc2464bis"/>, and the recent <xref target="I-D.hinden-6man-rfc2464bis"/>, and the IETF
recommendations for the generation of stable Interface Identifiers recommendation for the generation of stable Interface Identifiers
<xref target="RFC8064"/>.</t> <xref target="RFC8064"/>.</t>
<!-- <!--
@ -116,17 +110,26 @@ backward compatibility. (*)
rate is low enough. rate is low enough.
--> -->
<t>An important recent IPv6 development was that, for host computers <t>For host computers on local area networks, generation of interface
on local area networks, the way in which interface identifiers were identifiers is no longer necessarily bound to layer 2 addresses (MACs)
formed was no longer bound to layer 2 addresses (MACs) <xref <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 fact
length, previously fixed at 64 bits <xref target="RFC7136"/>, is in a variably-sized parameter as explicitly acknowledged in Section
fact a variably-sized parameter as stated in <xref 5.5.3(d) of <xref target="RFC4862"/> which states:
target="RFC4862"/>.</t>
<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>
<section anchor="simple" title="A simple Statement"> <section anchor="simple" title="A simple Statement">
<t>To state it simply, IPv6 unicast subnetting is based on prefixes <t>To state it simply, IPv6 unicast subnetting is based on prefixes
@ -187,7 +190,7 @@ rate is low enough.
<section anchor="security" title="Security Considerations"> <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 <xref target="RFC7721"/>, the subnet size may have an impact on some
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