IPv6 is Classless
The Intertubes
42 Rue du Jour
Sophia-Antipolis
::1
FR
bourbaki@bogus.com
Internet
6man
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.
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 , but was obsoleted by
, 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.
Recent proposed changes to the IP Version 6 Addressing
Architecture specification 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.
This document also stresses that IPv6 routing subnets may be of
any length up to 128, see .
It is assumed that the reader understands the history of classful
addressing in IPv4 and why it was abolished . 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.
It is also assumed that the reader understands IPv6 , the IP Version 6 Addressing Architecture , the proposed changes to RFC4291 and RFC2464 , an
IPv6 Prefix Length Recommendation for Forwarding, and the IETF
recommendation for the generation of stable Interface Identifiers
.
is also worth
reading to clarify uses of varying prefix lengths on a single
link.
For host computers on local area networks, generation of interface
identifiers is no longer necessarily bound to layer 2 addresses
(MACs) . Therefore
their length, previously fixed at 64 bits ,
is in fact a variably-sized parameter as explicitly acknowledged in
Section 5.5.3(d) of which states:
Note that a future revision of the address architecture 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
As IPv6 use has evolved and grown, 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:
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.
Hierarchical allocation of fixed-length subnets requires
coordination between lower / intermediate / upper network
elements. It has implicit assumption that policies and size
allocation allowed at the top of the hierarchy will accommodate
present and future use cases with fixed length subnet
allocation.
Coordination with upstream networks across administrative
domains for the allocation of fixed length subnets reveals topology
and intent that may be private in scope, allowing the upstream
networks to restrict the topology that may be built. Policies for
hierarchical allocation 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).
In the case where a device is given a /64 (e.g. mobile phone
running SLAAC only, not DHCP), there is no protocol allowing them
to provide downstream routed layer 3 subnets, because all they have
is a /64. This applies more to nodes which do not have DHCPv6.
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) , or Using 127-Bit IPv6 Prefixes on
Inter-Router Links .
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.
For historical reasons, when a prefix is needed on a link,
barring other considerations, a /64 is recommended .
The length of the Interface Identifier in Stateless Address
Autoconfiguration is a parameter; its
length SHOULD be sufficient for effective randomization for privacy
reasons. For example, 48 bits 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.
Note that OpenBSD ships with SLAAC for lengths longer than
/64.
Nonetheless, there is no reason in theory why an IPv6 node should
not operate with different interface identifier 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 ) algorithm
for selecting stable interface identifiers
is a parameter, rather than a hard-coded value.
Assuming that nodes employ unpredictable interface identifiers
, 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 .
For some specific subnets, such as point to 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 operational limit on such data structures,
thus helping mitigate some pathological behaviors (such as Neighbor
Cache Exhaustion attacks).
This document has no IANA Considerations.
The authors of this document are as follows:
Randy Bush <randy@psg.com>, Internet Initiative Japan
Brian Carpenter <brian.e.carpenter@gmail.com>, University of Auckland
Fernando Gont <fgont@si6networks.com>, SI6 Networks / UTN-FRH
Nick Hilliard <nick@netability.ie>, INEX
Joel Jaeggli <joelja@bogus.com>, Fastly
Geoff Huston <gih@apnic.net>, APNIC
Chris Morrow <morrowc@ops-netman.net>, Google, Inc.
Job Snijders <job@net.net>, NTT Communications