229 lines
9 KiB
XML
229 lines
9 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">
|
|
|
|
<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>
|
|
|
|
<date month="April" year="2017"/>
|
|
|
|
<abstract>
|
|
|
|
<t>Over the history of IPv6, various classful address models have
|
|
been proposed, particularly Top-Level Aggregation (TLA) and
|
|
Next-Level Aggregation (NLA) Identifiers. They have all proved to be
|
|
mistakes. The last remnant is a rigid boundary at /64. This
|
|
document removes that rigidity as far as routing is concerned.</t>
|
|
|
|
</abstract>
|
|
|
|
</front>
|
|
|
|
<middle>
|
|
|
|
<section anchor="intro" title="Introduction">
|
|
|
|
<t>Over the history of IPv6, various classful address models have
|
|
been proposed, particularly Top-Level Aggregation (TLA) and
|
|
Next-Level Aggregation(NLA) Identifiers. They have all proved to be
|
|
mistakes. For example, TLA and NLA were obsoleted by <xref
|
|
target="RFC3587"/>. The last remnant is a rigid boundary at
|
|
/64. This document removes that rigidity as far as routing is
|
|
concerned.</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 allocation 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.hinden-6man-rfc4291bis"/>, and the recent recommendations 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>An important recent development in IPv6 is that for host
|
|
computers on local area networks, the way in which interface
|
|
identifiers are formed is no longer bound to layer 2 addresses (MAC
|
|
addresses) <xref target="RFC7217"/> <xref target="RFC8064"/>. We can therefore appreciate
|
|
that their length, previously fixed at 64 bits <xref
|
|
target="RFC7136"/>, is in fact a free parameter as stated in <xref
|
|
target="RFC4862"/>.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="background" title="Background">
|
|
|
|
<!--
|
|
<t>To quote Lorenzo Colitti in the working group meeting at IETF 98,
|
|
"Just because this is being elevated to full standard does not mean
|
|
it can not be changed tomorrow." Tomorrow is here.</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.hinden-6man-rfc4291bis"/> with respect to the minimum subnet size.</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 naive, which could result in operational
|
|
disasters.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="simple" title="A simple Statement">
|
|
|
|
<t>To state it simply, IPv6 unicast routing is based on prefixes of
|
|
any valid length up to 128 except for links where an Internet
|
|
Standard such as, for example, Stateless Address AutoConfiguration
|
|
<xref target="RFC4862"/>, or Using 127-Bit IPv6 Prefixes on
|
|
Inter-Router Links <xref target="RFC6164"/> is in use.</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 needs to 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-bits was hard-coded, and to favor portability of devices
|
|
and operating systems.</t>
|
|
|
|
<t>None the less, 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 length of prefix, with the value
|
|
being parameterised 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>
|
|
|
|
<t>NOTE: should we comment on the fact that at least Linux and
|
|
Windows seem to assume that the default prefix is /64 in the
|
|
management CLI?</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="security" title="Security Considerations">
|
|
|
|
<t>Assumming 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"/>.
|
|
However, that 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 essentially enforces 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 draft was by Randy Bush, who was immediately aided
|
|
and abetted by Brian Carpenter, Chris Morrow, Job Snijders, [ your
|
|
name here ].</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.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.hinden-6man-rfc4291bis"?>
|
|
</references>
|
|
|
|
</back>
|
|
|
|
</rfc>
|