readable xml, but thanks anyway job :)
This commit is contained in:
parent
a4b6a1c8ff
commit
c85ccd2efe
2 changed files with 238 additions and 195 deletions
|
|
@ -73,7 +73,7 @@ Table of Contents
|
||||||
8. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
8. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||||
9.1. Normative References . . . . . . . . . . . . . . . . . . 5
|
9.1. Normative References . . . . . . . . . . . . . . . . . . 5
|
||||||
9.2. Informative References . . . . . . . . . . . . . . . . . 5
|
9.2. Informative References . . . . . . . . . . . . . . . . . 6
|
||||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
|
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||||||
|
|
||||||
1. Introduction
|
1. Introduction
|
||||||
|
|
@ -139,7 +139,7 @@ Internet-Draft IPv6 is Classless July 2017
|
||||||
interface identifier of length other than the value defined in the
|
interface identifier of length other than the value defined in the
|
||||||
current documents. Thus, an implementation should not assume a
|
current documents. Thus, an implementation should not assume a
|
||||||
particular constant. Rather, it should expect any lengths of
|
particular constant. Rather, it should expect any lengths of
|
||||||
interface identifiers.
|
interface identifiers
|
||||||
|
|
||||||
As IPv6 usage has evolved and grown over in recent years, it has
|
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
|
||||||
|
|
@ -151,17 +151,17 @@ Internet-Draft IPv6 is Classless July 2017
|
||||||
subnets to downstream networks or devices from /48 down to /64 are
|
subnets to downstream networks or devices from /48 down to /64 are
|
||||||
based on design assumptions of how subnets are or should be
|
based on design assumptions of how subnets are or should be
|
||||||
allocated and populated within ipv4 networks.
|
allocated and populated within ipv4 networks.
|
||||||
|
|
||||||
Hierarchical allocation of fixed-length subnets requires
|
Hierarchical allocation of fixed-length subnets requires
|
||||||
coordination between lower / intermediate / upper network
|
coordination between lower / intermediate / upper network
|
||||||
elementss. It has implict assumption that policies and size
|
elementss. It has implict assumption that policies and size
|
||||||
allocation allowed the top of the hierarchy will accomodate
|
allocation allowed the top of the hierarchy will accomodate
|
||||||
present and future use cases with fixed lenth subnet allocation.
|
present and future use cases with fixed lenth subnet allocation.
|
||||||
|
|
||||||
Coordination with upstream networks across administrative domains
|
Coordination with upstream networks across administrative domains
|
||||||
for the allocation of fixed length subnets reveals topology and
|
for the allocation of fixed length subnets reveals topology and
|
||||||
intent that may be private in scope. Policies for hierarchical
|
intent that may be private in scope. Policies for hierarchical
|
||||||
allcation are applied top-down and amount to permission to build a
|
allcation are applied top-down and amount to permission to build a
|
||||||
particular topology (for example mobile device tethering, virtual
|
|
||||||
machine instantiation, containers and so on).
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -170,6 +170,9 @@ Bourbaki Expires January 19, 2018 [Page 3]
|
||||||
Internet-Draft IPv6 is Classless July 2017
|
Internet-Draft IPv6 is Classless July 2017
|
||||||
|
|
||||||
|
|
||||||
|
particular topology (for example mobile device tethering, virtual
|
||||||
|
machine instantiation, containers and so on).
|
||||||
|
|
||||||
4. Identifier and Subnet Length Statements
|
4. Identifier and Subnet Length Statements
|
||||||
|
|
||||||
IPv6 unicast interfaces may use any subnet length up to 128 except
|
IPv6 unicast interfaces may use any subnet length up to 128 except
|
||||||
|
|
@ -214,10 +217,7 @@ Internet-Draft IPv6 is Classless July 2017
|
||||||
[RFC7707] [RFC7721]. For some specific subnets, such as point to
|
[RFC7707] [RFC7721]. For some specific subnets, such as point to
|
||||||
point links, this may be less of an issue.
|
point links, this may be less of an issue.
|
||||||
|
|
||||||
On the other hand, we assume that a number of IPv6 implementations
|
|
||||||
fail to enforce limits on the size of some of the data structures
|
|
||||||
they employ for communicating with neighboring nodes, such as the
|
|
||||||
Neighbor Cache. In such cases, the use of smaller subnets forces an
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -226,6 +226,10 @@ Bourbaki Expires January 19, 2018 [Page 4]
|
||||||
Internet-Draft IPv6 is Classless July 2017
|
Internet-Draft IPv6 is Classless July 2017
|
||||||
|
|
||||||
|
|
||||||
|
On the other hand, we assume that a number of IPv6 implementations
|
||||||
|
fail to enforce limits on the size of some of the data structures
|
||||||
|
they employ for communicating with neighboring nodes, such as the
|
||||||
|
Neighbor Cache. In such cases, the use of smaller subnets forces an
|
||||||
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).
|
||||||
|
|
||||||
|
|
@ -238,12 +242,19 @@ Internet-Draft IPv6 is Classless July 2017
|
||||||
The authors of this document are as follows:
|
The authors of this document are as follows:
|
||||||
|
|
||||||
Randy Bush, Internet Initiative Japan
|
Randy Bush, Internet Initiative Japan
|
||||||
|
|
||||||
Brian Carpenter, University of Auckland
|
Brian Carpenter, University of Auckland
|
||||||
|
|
||||||
Fernando Gont, SI6 Networks / UTN-FRH
|
Fernando Gont, SI6 Networks / UTN-FRH
|
||||||
|
|
||||||
Nick Hilliard, INEX
|
Nick Hilliard, INEX
|
||||||
|
|
||||||
Joel Jaeggli, Fastly
|
Joel Jaeggli, Fastly
|
||||||
|
|
||||||
Geoff Huston, APNIC
|
Geoff Huston, APNIC
|
||||||
|
|
||||||
Chris Morrow, Google, Inc.
|
Chris Morrow, Google, Inc.
|
||||||
|
|
||||||
Job Snijders, NTT Communications
|
Job Snijders, NTT Communications
|
||||||
|
|
||||||
9. References
|
9. References
|
||||||
|
|
@ -264,17 +275,6 @@ Internet-Draft IPv6 is Classless July 2017
|
||||||
DOI 10.17487/RFC7217, April 2014,
|
DOI 10.17487/RFC7217, April 2014,
|
||||||
<http://www.rfc-editor.org/info/rfc7217>.
|
<http://www.rfc-editor.org/info/rfc7217>.
|
||||||
|
|
||||||
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
|
|
||||||
"Recommendation on Stable IPv6 Interface Identifiers",
|
|
||||||
RFC 8064, DOI 10.17487/RFC8064, February 2017,
|
|
||||||
<http://www.rfc-editor.org/info/rfc8064>.
|
|
||||||
|
|
||||||
9.2. Informative References
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Bourbaki Expires January 19, 2018 [Page 5]
|
Bourbaki Expires January 19, 2018 [Page 5]
|
||||||
|
|
@ -282,6 +282,13 @@ Bourbaki Expires January 19, 2018 [Page 5]
|
||||||
Internet-Draft IPv6 is Classless July 2017
|
Internet-Draft IPv6 is Classless July 2017
|
||||||
|
|
||||||
|
|
||||||
|
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
|
||||||
|
"Recommendation on Stable IPv6 Interface Identifiers",
|
||||||
|
RFC 8064, DOI 10.17487/RFC8064, February 2017,
|
||||||
|
<http://www.rfc-editor.org/info/rfc8064>.
|
||||||
|
|
||||||
|
9.2. Informative References
|
||||||
|
|
||||||
[I-D.hinden-6man-rfc2464bis]
|
[I-D.hinden-6man-rfc2464bis]
|
||||||
Crawford, M. and R. Hinden, "Transmission of IPv6 Packets
|
Crawford, M. and R. Hinden, "Transmission of IPv6 Packets
|
||||||
over Ethernet Networks", draft-hinden-6man-rfc2464bis-02
|
over Ethernet Networks", draft-hinden-6man-rfc2464bis-02
|
||||||
|
|
@ -324,13 +331,6 @@ Internet-Draft IPv6 is Classless July 2017
|
||||||
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
|
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
|
||||||
February 2014, <http://www.rfc-editor.org/info/rfc7136>.
|
February 2014, <http://www.rfc-editor.org/info/rfc7136>.
|
||||||
|
|
||||||
[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
|
|
||||||
Length Recommendation for Forwarding", BCP 198, RFC 7608,
|
|
||||||
DOI 10.17487/RFC7608, July 2015,
|
|
||||||
<http://www.rfc-editor.org/info/rfc7608>.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Bourbaki Expires January 19, 2018 [Page 6]
|
Bourbaki Expires January 19, 2018 [Page 6]
|
||||||
|
|
@ -338,6 +338,11 @@ Bourbaki Expires January 19, 2018 [Page 6]
|
||||||
Internet-Draft IPv6 is Classless July 2017
|
Internet-Draft IPv6 is Classless July 2017
|
||||||
|
|
||||||
|
|
||||||
|
[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
|
||||||
|
Length Recommendation for Forwarding", BCP 198, RFC 7608,
|
||||||
|
DOI 10.17487/RFC7608, July 2015,
|
||||||
|
<http://www.rfc-editor.org/info/rfc7608>.
|
||||||
|
|
||||||
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
|
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
|
||||||
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
|
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
|
||||||
<http://www.rfc-editor.org/info/rfc7707>.
|
<http://www.rfc-editor.org/info/rfc7707>.
|
||||||
|
|
@ -378,11 +383,6 @@ Author's Address
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -4,7 +4,7 @@
|
||||||
<?rfc compact="yes"?>
|
<?rfc compact="yes"?>
|
||||||
<?rfc inline="yes"?>
|
<?rfc inline="yes"?>
|
||||||
<?rfc sortrefs="yes"?>
|
<?rfc sortrefs="yes"?>
|
||||||
<?rfc subcompact="yes"?>
|
<?rfc subcompact="no"?>
|
||||||
<?rfc symrefs="yes"?>
|
<?rfc symrefs="yes"?>
|
||||||
<?rfc toc="yes"?>
|
<?rfc toc="yes"?>
|
||||||
<?rfc tocdepth="3"?>
|
<?rfc tocdepth="3"?>
|
||||||
|
|
@ -38,11 +38,11 @@
|
||||||
|
|
||||||
<abstract>
|
<abstract>
|
||||||
|
|
||||||
<t>
|
<t>Over the history of IPv6, various classful address models have
|
||||||
Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time.
|
been proposed, none of which has withstood the test of time. The
|
||||||
The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64.
|
last remnant of IPv6 classful addressing is a rigid network
|
||||||
This document removes the fixed position of that boundary for interface addressing.
|
interface identifier boundary at /64. This document removes the
|
||||||
</t>
|
fixed position of that boundary for interface addressing.</t>
|
||||||
|
|
||||||
</abstract>
|
</abstract>
|
||||||
|
|
||||||
|
|
@ -65,37 +65,50 @@
|
||||||
|
|
||||||
<section anchor="intro" title="Introduction">
|
<section anchor="intro" title="Introduction">
|
||||||
|
|
||||||
<t>
|
<t>Over the history of the IPv6 protocol, several classful
|
||||||
Over the history of the IPv6 protocol, several classful addressing models have been proposed.
|
addressing models have been proposed. The most notable example
|
||||||
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.
|
recommended Top-Level Aggregation (TLA) and Next-Level Aggregation
|
||||||
This document removes the fixed position of that boundary for interface addressing.
|
(NLA) Identifiers <xref target="RFC2450"/>, but was obsoleted by
|
||||||
</t>
|
<xref target="RFC3587"/>, leaving a single remnant of classful
|
||||||
|
addressing in IPv6: a rigid network interface identifier boundary at
|
||||||
|
/64. This document removes the fixed position of that boundary for
|
||||||
|
interface addressing.</t>
|
||||||
|
|
||||||
<t>
|
<t>Recent proposed changes to the IP Version 6 Addressing
|
||||||
Recent proposed changes to the IP Version 6 Addressing Architecture specification <xref target="RFC4291"/> have caused controversy.
|
Architecture specification <xref target="RFC4291"/> have caused
|
||||||
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.
|
controversy. While link prefixes of varied lengths, e.g. /127,
|
||||||
</t>
|
/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>
|
<t>This document also clarifies that IPv6 routing subnets may be of
|
||||||
This document also clarifies that IPv6 routing subnets may be of any length up to 128.
|
any length up to 128.</t>
|
||||||
</t>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section anchor="reading" title="Suggested Reading">
|
<section anchor="reading" title="Suggested Reading">
|
||||||
|
|
||||||
<t>
|
<t>It is assumed that the reader understands the history of classful
|
||||||
It is assumed that the reader understands the history of classful addressing in IPv4 and why it was abolished <xref target="RFC4632"/>.
|
addressing in IPv4 and why it was abolished <xref
|
||||||
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 assignment remain compelling.
|
target="RFC4632"/>. Of course, the acute need to conserve address
|
||||||
</t>
|
space that forced the adoption of classless addressing for IPv4 does
|
||||||
|
not apply to IPv6, but the arguments for operational flexibility in
|
||||||
|
address assignment remain compelling.</t>
|
||||||
|
|
||||||
<t>
|
<t>It is also assumed that the reader understands IPv6 <xref
|
||||||
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"/>, <xref target="RFC7608"/> an IPv6 Prefix Length Recommendation for Forwarding, and the IETF recommendation for the generation of stable Interface Identifiers <xref target="RFC8064"/>.
|
target="RFC2460"/>, the IP Version 6 Addressing Architecture <xref
|
||||||
</t>
|
target="RFC4291"/>, the proposed changes to RFC4291 <xref
|
||||||
|
target="I-D.ietf-6man-rfc4291bis"/> and RFC2464 <xref
|
||||||
|
target="I-D.hinden-6man-rfc2464bis"/>, <xref target="RFC7608"/> an
|
||||||
|
IPv6 Prefix Length Recommendation for Forwarding, and the IETF
|
||||||
|
recommendation for the generation of stable Interface Identifiers
|
||||||
|
<xref target="RFC8064"/>.</t>
|
||||||
|
|
||||||
<t>
|
<t><xref target="I-D.jinmei-6man-prefix-clarify"/> is also worth
|
||||||
<xref target="I-D.jinmei-6man-prefix-clarify"/> is also worth reading to clarify uses of varying prefix lengths on a single link.
|
reading to clarify uses of varying prefix lengths on a single
|
||||||
</t>
|
link.</t>
|
||||||
|
|
||||||
<!--
|
<!--
|
||||||
<t>NOTE: do we mean 4291bis (currently moribund) or 2464bis?</t>
|
<t>NOTE: do we mean 4291bis (currently moribund) or 2464bis?</t>
|
||||||
|
|
@ -114,52 +127,72 @@ rate is low enough.
|
||||||
|
|
||||||
<section anchor="Problem" title="Problem reinforced by classful addressing">
|
<section anchor="Problem" title="Problem reinforced by classful addressing">
|
||||||
|
|
||||||
<t>
|
<t>For host computers on local area networks, generation of interface
|
||||||
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"/>.
|
identifiers is no longer necessarily bound to layer 2 addresses
|
||||||
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:
|
(MACs) <xref target="RFC7217"/> <xref target="RFC8064"/>. Therefore
|
||||||
|
their length, previously fixed at 64 bits <xref target="RFC7136"/>,
|
||||||
<list>
|
is in fact a variably-sized parameter as explicitly acknowledged in
|
||||||
<t>
|
Section 5.5.3(d) of <xref target="RFC4862"/> which states:
|
||||||
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 become evident that it faces several scaling and coordination problems.
|
|
||||||
These problems are analogous to allocation and coordination problems that motivated IPv4 CIDR allocation and later abundant IPv4 PAT, they include:
|
|
||||||
|
|
||||||
<list>
|
<list>
|
||||||
|
|
||||||
<t>
|
<t>Note that a future revision of the address architecture <xref
|
||||||
Address allocation models for specific counts of fixed length subnets to downstream networks or devices from /48 down to /64 are based on design assumptions of how subnets are or should be allocated and populated within ipv4 networks.
|
target="RFC4291"/> and a future link-type-specific document, which
|
||||||
</t>
|
will still be consistent with each other, could potentially allow
|
||||||
<t>
|
for an interface identifier of length other than the value defined
|
||||||
Hierarchical allocation of fixed-length subnets requires coordination between lower / intermediate / upper network elementss.
|
in the current documents. Thus, an implementation should not
|
||||||
It has implict assumption that policies and size allocation allowed the top of the hierarchy will accomodate present and future use cases with fixed lenth subnet allocation.
|
assume a particular constant. Rather, it should expect any lengths
|
||||||
</t>
|
of interface identifiers</t>
|
||||||
<t>
|
|
||||||
Coordination with upstream networks across administrative domains for the allocation of fixed length subnets reveals topology and intent that may be private in scope.
|
|
||||||
Policies for hierarchical allcation are applied top-down and amount to permission to build a particular topology (for example mobile device tethering, virtual machine instantiation, containers and so on).
|
|
||||||
</t>
|
|
||||||
|
|
||||||
</list>
|
</list>
|
||||||
|
</t>
|
||||||
|
|
||||||
|
<t>As IPv6 usage has evolved and grown over in recent years, it has
|
||||||
|
become evident that it faces several scaling and coordination
|
||||||
|
problems. These problems are analogous to allocation and
|
||||||
|
coordination problems that motivated IPv4 CIDR allocation and later
|
||||||
|
abundant IPv4 PAT, they include:
|
||||||
|
|
||||||
|
<list>
|
||||||
|
|
||||||
|
<t>Address allocation models for specific counts of fixed length
|
||||||
|
subnets to downstream networks or devices from /48 down to /64
|
||||||
|
are based on design assumptions of how subnets are or should be
|
||||||
|
allocated and populated within ipv4 networks.</t>
|
||||||
|
|
||||||
|
<t>Hierarchical allocation of fixed-length subnets requires
|
||||||
|
coordination between lower / intermediate / upper network
|
||||||
|
elementss. It has implict assumption that policies and size
|
||||||
|
allocation allowed the top of the hierarchy will accomodate
|
||||||
|
present and future use cases with fixed lenth subnet
|
||||||
|
allocation.</t>
|
||||||
|
|
||||||
|
<t>Coordination with upstream networks across administrative
|
||||||
|
domains for the allocation of fixed length subnets reveals
|
||||||
|
topology and intent that may be private in scope. Policies for
|
||||||
|
hierarchical allcation are applied top-down and amount to
|
||||||
|
permission to build a particular topology (for example mobile
|
||||||
|
device tethering, virtual machine instantiation, containers and
|
||||||
|
so on).</t>
|
||||||
|
|
||||||
|
</list>
|
||||||
</t>
|
</t>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section anchor="statement" title="Identifier and Subnet Length Statements">
|
<section anchor="statement" title="Identifier and Subnet Length Statements">
|
||||||
|
|
||||||
<t>
|
<t>IPv6 unicast interfaces may use any subnet length up to 128
|
||||||
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"/>.
|
except for situations where an Internet Standard document may impose
|
||||||
</t>
|
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>
|
<t>Additionally, this document clarifies that a node or router MUST
|
||||||
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.
|
support routing of any valid network prefix length, even if SLAAC or
|
||||||
</t>
|
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>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
|
|
@ -181,50 +214,60 @@ rate is low enough.
|
||||||
|
|
||||||
<section anchor="notes" title="Recommendations">
|
<section anchor="notes" title="Recommendations">
|
||||||
|
|
||||||
<t>
|
<t>For historical reasons, when a prefix is needed on a link,
|
||||||
For historical reasons, when a prefix is needed on a link, barring other considerations, a /64 is recommended <xref target="RFC7136"/>.
|
barring other considerations, a /64 is recommended <xref
|
||||||
</t>
|
target="RFC7136"/>.</t>
|
||||||
|
|
||||||
<t>
|
<t>The length of the Interface Identifier in Stateless Address
|
||||||
The length of the Interface Identifier in Stateless Address Autoconfiguration <xref target="RFC4862"/> is a parameter; its length SHOULD be sufficient for effective randomization for privacy reasons.
|
Autoconfiguration <xref target="RFC4862"/> is a parameter; its
|
||||||
For example, a /48 might be sufficient.
|
length SHOULD be sufficient for effective randomization for privacy
|
||||||
But operationally we recommend, barring strong considerations to the contrary, using 64-bits for SLAAC in order not to discover bugs where 64 was hard-coded, and to favor portability of devices and operating systems.
|
reasons. For example, a /48 might be sufficient. But operationally
|
||||||
</t>
|
we recommend, barring strong considerations to the contrary, using
|
||||||
|
64-bits for SLAAC in order not to discover bugs where 64 was
|
||||||
|
hard-coded, and to favor portability of devices and operating
|
||||||
|
systems.</t>
|
||||||
|
|
||||||
<t>
|
<t>Nonetheless, there is no reason in theory why an IPv6 node should
|
||||||
Nonetheless, there is no reason in theory why an IPv6 node should not operate with different interface identfier lengths on different physical interfaces.
|
not operate with different interface identfier lengths on different
|
||||||
Thus, a correct implementation of SLAAC must in fact allow for any prefix length, with the value being a parameter per interface.
|
physical interfaces. Thus, a correct implementation of SLAAC must
|
||||||
For instance, the Interface Identifier length in the recommended (see <xref target="RFC8064"/>) algorithm for selecting stable interface identifiers <xref target="RFC7217"/> is a parameter, rather than a hardcoded value.
|
in fact allow for any prefix length, with the value being a
|
||||||
</t>
|
parameter per interface. For instance, the Interface Identifier
|
||||||
|
length in the recommended (see <xref target="RFC8064"/>) algorithm
|
||||||
|
for selecting stable interface identifiers <xref target="RFC7217"/>
|
||||||
|
is a parameter, rather than a hardcoded value.</t>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section anchor="security" title="Security Considerations">
|
<section anchor="security" title="Security Considerations">
|
||||||
|
|
||||||
<t>
|
<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
|
||||||
|
address scans <xref target="RFC7707"/> <xref target="RFC7721"/>.
|
||||||
|
For some specific subnets, such as point to point links, this may be
|
||||||
|
less of an issue.</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.
|
<t>On the other hand, we assume that a number of IPv6
|
||||||
Namely, the smaller the subnet size, the more feasible it becomes to perform IPv6 address scans <xref target="RFC7707"/> <xref target="RFC7721"/>.
|
implementations fail to enforce limits on the size of some of the
|
||||||
For some specific subnets, such as point to point links, this may be less of an issue.
|
data structures they employ for communicating with neighboring
|
||||||
</t>
|
nodes, such as the Neighbor Cache. In such cases, the use of
|
||||||
|
smaller subnets forces an operational limit on such data structures,
|
||||||
|
thus helping mitigate some pathological behaviors (such as Neighbor
|
||||||
|
Cache Exhaustion attacks).</t>
|
||||||
|
|
||||||
<t>
|
|
||||||
On the other hand, we assume that a number of IPv6 implementations fail to enforce limits on the size of some of the data structures they employ for communicating with neighboring nodes, such as the Neighbor Cache.
|
|
||||||
In such cases, the use of smaller subnets forces an operational limit on such data structures, thus helping mitigate some pathological behaviors (such as Neighbor Cache Exhaustion attacks).
|
|
||||||
</t>
|
|
||||||
<!-- [fgont] Still need to add references here... e.g. to Joel's RFC -->
|
<!-- [fgont] Still need to add references here... e.g. to Joel's RFC -->
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section anchor="iana" title="IANA Considerations">
|
<section anchor="iana" title="IANA Considerations">
|
||||||
<t>
|
|
||||||
This document has no IANA Considerations.
|
<t>This document has no IANA Considerations.</t>
|
||||||
</t>
|
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section anchor="authors" title="Authors">
|
<section anchor="authors" title="Authors">
|
||||||
<t>
|
<t>The authors of this document are as follows:
|
||||||
The authors of this document are as follows:
|
|
||||||
|
|
||||||
<list>
|
<list>
|
||||||
<t> Randy Bush, Internet Initiative Japan</t>
|
<t> Randy Bush, Internet Initiative Japan</t>
|
||||||
<t> Brian Carpenter, University of Auckland</t>
|
<t> Brian Carpenter, University of Auckland</t>
|
||||||
|
|
@ -238,6 +281,7 @@ rate is low enough.
|
||||||
</t>
|
</t>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
</middle>
|
</middle>
|
||||||
|
|
||||||
<back>
|
<back>
|
||||||
|
|
@ -264,7 +308,6 @@ rate is low enough.
|
||||||
<?rfc include="reference.I-D.hinden-6man-rfc2464bis"?>
|
<?rfc include="reference.I-D.hinden-6man-rfc2464bis"?>
|
||||||
<?rfc include="reference.I-D.jinmei-6man-prefix-clarify"?>
|
<?rfc include="reference.I-D.jinmei-6man-prefix-clarify"?>
|
||||||
</references>
|
</references>
|
||||||
|
|
||||||
</back>
|
</back>
|
||||||
|
|
||||||
</rfc>
|
</rfc>
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue