350 lines
12 KiB
XML
350 lines
12 KiB
XML
<?xml version="1.0"?>
|
|
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
|
|
<?rfc comments="yes"?>
|
|
<?rfc compact="yes"?>
|
|
<?rfc inline="yes"?>
|
|
<?rfc sortrefs="yes"?>
|
|
<?rfc subcompact="yes"?>
|
|
<?rfc symrefs="yes"?>
|
|
<?rfc toc="yes"?>
|
|
<?rfc tocdepth="3"?>
|
|
<?rfc tocindent="yes"?>
|
|
<?rfc tocompact="yes"?>
|
|
|
|
<rfc category="std" docName="draft-bourbaki-6man-classless-ipv6-00" ipr="trust200902" updates="4291">
|
|
|
|
<front>
|
|
<title>IPv6 is Classless</title>
|
|
|
|
<!--
|
|
<author fullname="Nicolas Bourbaki" initials="N." surname="Bourbaki">
|
|
<organization>The Intertubes</organization>
|
|
<address>
|
|
<postal>
|
|
<street>42 Rue du Jour</street>
|
|
<city>Sophia-Antipolis</city>
|
|
<region></region>
|
|
<code>::1</code>
|
|
<country>FR</country>
|
|
</postal>
|
|
<email>bourbaki@bogus.com</email>
|
|
</address>
|
|
</author>
|
|
-->
|
|
|
|
<author fullname="Randy Bush" initials="R.B." surname="Bush">
|
|
<organization>Internet Initiative Japan</organization>
|
|
<address>
|
|
<postal>
|
|
<street>5147 Crystal Springs</street>
|
|
<city>Bainbridge Island</city>
|
|
<region>Washington</region>
|
|
<code>98110</code>
|
|
<country>US</country>
|
|
</postal>
|
|
<email>randy@psg.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Brian Carpenter" initials="B. E." surname="Carpenter">
|
|
<organization abbrev="Univ. of Auckland"/>
|
|
<address>
|
|
<postal>
|
|
<street>Department of Computer Science</street>
|
|
<street>University of Auckland</street>
|
|
<street>PB 92019</street>
|
|
<city>Auckland</city>
|
|
<region/>
|
|
<code>1142</code>
|
|
<country>New Zealand</country>
|
|
</postal>
|
|
<email>brian.e.carpenter@gmail.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Fernando Gont" initials="F." surname="Gont">
|
|
<organization>SI6 Networks / UTN-FRH</organization>
|
|
<address>
|
|
<postal>
|
|
<street>Evaristo Carriego 2644</street>
|
|
<code>1706</code>
|
|
<city>Haedo</city>
|
|
<region>Provincia de Buenos Aires</region>
|
|
<country>Argentina</country>
|
|
</postal>
|
|
<phone>+54 11 4650 8472</phone>
|
|
<email>fgont@si6networks.com</email>
|
|
<uri>http://www.si6networks.com</uri>
|
|
</address>
|
|
</author>
|
|
|
|
<author initials="N" surname="Hilliard" fullname="Nick Hilliard">
|
|
<organization>INEX</organization>
|
|
<address>
|
|
<postal>
|
|
<street>4027 Kingswood Road</street>
|
|
<city>Dublin</city>
|
|
<code>24</code>
|
|
<country>Ireland</country>
|
|
</postal>
|
|
<email>nick@inex.ie</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Geoff Huston" initials="G" surname="Huston">
|
|
<organization abbrev="APNIC"/>
|
|
<address>
|
|
<email>gih@apnic.net</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Job Snijders" initials="J." surname="Snijders">
|
|
<organization abbrev="NTT">NTT Communications</organization>
|
|
<address>
|
|
<postal>
|
|
<street>Theodorus Majofskistraat 100</street>
|
|
<code>1065 SZ</code>
|
|
<city>Amsterdam</city>
|
|
<country>The Netherlands</country>
|
|
</postal>
|
|
<email>job@ntt.net</email>
|
|
</address>
|
|
</author>
|
|
|
|
<date month="May" year="2017"/>
|
|
|
|
<abstract>
|
|
|
|
<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 the fixed position of
|
|
that boundary for interface addressing.</t>
|
|
|
|
</abstract>
|
|
|
|
<!--
|
|
<note title="Requirements Language">
|
|
|
|
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
|
|
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
|
|
are to be interpreted as described in <xref target="RFC2119">RFC
|
|
2119</xref> only when they appear in all upper case. They may
|
|
also appear in lower or mixed case as English words, without
|
|
normative meaning.</t>
|
|
|
|
</note>
|
|
-->
|
|
|
|
</front>
|
|
|
|
<middle>
|
|
|
|
<section anchor="intro" title="Introduction">
|
|
|
|
<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 the fixed
|
|
position of that boundary for interface addressing.</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>This document also clarifies that IPv6 routing subnets may be of any
|
|
length up to 128.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="reading" title="Suggested Reading">
|
|
|
|
<t>It is assumed that the reader understands the history of classful
|
|
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 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 IETF
|
|
recommendation for the generation of stable Interface Identifiers
|
|
<xref target="RFC8064"/>.</t>
|
|
|
|
<!--
|
|
<t>NOTE: do we mean 4291bis (currently moribund) or 2464bis?</t>
|
|
|
|
[fgont] We do mean 4291bis. That say, RFC8064/RFC7217 already do part of
|
|
the job: they replace the algorithm of "embedding the MAC address in the
|
|
IPv6" with one that embeds random bits of an appropriate length. That
|
|
is, strictly speaking, we don't een need /64 for SLAAC, except for
|
|
backward compatibility. (*)
|
|
|
|
(*) as long as the local subnet is large enough and the IID collision
|
|
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 anchor="statement" title="Identifier and Subnet Length Statements">
|
|
|
|
<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>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:
|
|
|
|
* Routing: Nodes must *always* support rotuing on any valid length, even
|
|
if, say, SLAAC is in use. Even when SLAAC is used, I might
|
|
want to install a host-specific rule (a /128 rule), if I
|
|
please. And I think this point has never been contended
|
|
(except for vendors that go lazy/cheap and just don't want to
|
|
use mre than 64-bits in each FIB entry.
|
|
|
|
* Subnet size: This is what you're really referring to here. Nodes
|
|
should be able to employ any subnet size that they
|
|
please, except when slaac is in use (for backwards
|
|
compatibility) or e.g. when /127 (or the like) prefixes
|
|
are employed for point to point links.
|
|
-->
|
|
</section>
|
|
|
|
<section anchor="notes" title="Recommendations">
|
|
|
|
<t>For historical reasons, when a prefix is needed on a link,
|
|
barring other considerations, a /64 is recommended <xref
|
|
target="RFC7136"/>.</t>
|
|
|
|
<t>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. 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 was
|
|
hard-coded, and to favor portability of devices and operating
|
|
systems.</t>
|
|
|
|
<t>Nonetheless, 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 prefix length, with the value being
|
|
a 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 anchor="security" title="Security Considerations">
|
|
|
|
<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>
|
|
|
|
<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 -->
|
|
|
|
</section>
|
|
|
|
<section anchor="iana" title="IANA Considerations">
|
|
|
|
<t>This document has no IANA Considerations.</t>
|
|
|
|
<!--
|
|
<t>Note to RFC Editor: this section may be replaced on publication
|
|
as an RFC.</t>
|
|
-->
|
|
|
|
</section>
|
|
|
|
<section anchor="authors" title="Authors">
|
|
|
|
<t>The original sketch was by Randy Bush, who was immediately aided
|
|
and abetted by Brian Carpenter, Chris Morrow, Fernando Gont, Geoff
|
|
Huston, Job Snijders, and Nick Hilliard.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="acknowledgments" title="Acknowledgments">
|
|
|
|
<t>The authors wish to thank .</t>
|
|
|
|
</section>
|
|
|
|
</middle>
|
|
|
|
<back>
|
|
|
|
<references title="Normative References">
|
|
<!--
|
|
<?rfc include="reference.RFC.2119"?>
|
|
-->
|
|
<?rfc include="reference.RFC.2450"?>
|
|
<?rfc include="reference.RFC.2460"?>
|
|
<?rfc include="reference.RFC.4291"?>
|
|
<?rfc include="reference.RFC.7217"?>
|
|
<?rfc include="reference.RFC.8064"?>
|
|
</references>
|
|
|
|
<references title="Informative References">
|
|
<?rfc include="reference.RFC.4862"?>
|
|
<?rfc include="reference.RFC.6164"?>
|
|
<?rfc include="reference.RFC.3587"?>
|
|
<?rfc include="reference.RFC.4632"?>
|
|
<?rfc include="reference.RFC.7707"?>
|
|
<?rfc include="reference.RFC.7136"?>
|
|
<?rfc include="reference.RFC.7721"?>
|
|
<?rfc include="reference.I-D.ietf-6man-rfc4291bis"?>
|
|
<?rfc include="reference.I-D.hinden-6man-rfc2464bis"?>
|
|
</references>
|
|
|
|
</back>
|
|
|
|
</rfc>
|