IPv6 is Classless

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 . The last remnant is a rigid boundary at /64. This document removes that rigidity as far as routing is concerned.

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 allocation remain compelling. It is also assumed that the reader understands IPv6 , the IP Version 6 Addressing Architecture , the proposed changes to RFC4291 , and the recent recommendations for the generation of stable Interface Identifiers . 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) . We can therefore appreciate that their length, previously fixed at 64 bits , is in fact a free parameter as stated in .

Some confusion has been caused by the IP Version 6 Addressing Architecture, , and the proposed changes in with respect to the minimum subnet size. 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.

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 , or Using 127-Bit IPv6 Prefixes on Inter-Router Links is in use.

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 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. 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 ) algorithm for selecting stable interface identifiers is a parameter, rather than a hardcoded value. 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?

Assumming 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 . However, that 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 essentially enforces 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 original draft was by Randy Bush, who was immediately aided and abetted by Brian Carpenter, Chris Morrow, Fernando Gont, Geoff Huston, Job Snijders, [ your name here ].

The authors wish to thank .