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

Merge branch 'master' of github.com:randyqx/classless6

Browse source
This commit is contained in:
Randy Bush 2017-07-17 14:36:24 +02:00
commit 4899a00638
1 changed files with 20 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -121,26 +121,27 @@ backward compatibility. (*)
rate is low enough. rate is low enough.
--> -->
<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>
<section anchor="Problem" title="Problem reinforced by classful addressing"> <section anchor="Problem" title="Problem reinforced by classful addressing">
<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>
<t>As IPv6 usage has evolved and grown over in recent years, it has <t>As IPv6 usage has evolved and grown over in recent years, it has
become evident that it faces several scaling and coordination become evident that it faces several scaling and coordination
problems. These problems are analogous to allocation and coordination problems. These problems are analogous to allocation and coordination
@ -165,7 +166,7 @@ rate is low enough.
</section> </section>
<section anchor="statement" title="Identifier and Subnet Length Statements"> <section anchor="statement" title="Identifier and Subnet Length Statements">
<t>IPv6 unicast interfaces may use any subnet length up to 128 except <t>IPv6 unicast interfaces may use any subnet length up to 128 except
for situations where an Internet Standard document may impose a for situations where an Internet Standard document may impose a
particular length, for example Stateless Address Autoconfiguration particular length, for example Stateless Address Autoconfiguration
@ -178,6 +179,8 @@ rate is low enough.
differentiate at a different granularity than is used by any such differentiate at a different granularity than is used by any such
automated link local address configuration tools.</t> automated link local address configuration tools.</t>
</section>
<!-- [fgont] I think these section is mixing up to things: <!-- [fgont] I think these section is mixing up to things:
* Routing: Nodes must *always* support rotuing on any valid length, even * Routing: Nodes must *always* support rotuing on any valid length, even