Internet-Draft IPv6 is Classless April 2024
Bourbaki Expires 3 October 2024 [Page]
Workgroup:
6man
Internet-Draft:
draft-bourbaki-6man-classless-ipv6-10
Updates:
4291 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Author:
N. Bourbaki
The Intertubes

IPv6 is Classless

Abstract

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 3 October 2024.

Table of Contents

1. Introduction

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 [RFC2450], but was obsoleted by [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.

Recent proposed changes to the IP Version 6 Addressing Architecture specification [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.

This document also stresses that IPv6 routing subnets may be of any length up to 128, see [RFC7608].

2. Suggested Reading

It is assumed that the reader understands the history of classful addressing in IPv4 and why it was abolished [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.

It is also assumed that the reader understands IPv6 [RFC2460], the IP Version 6 Addressing Architecture [RFC4291], the proposed changes to RFC4291 [I-D.ietf-6man-rfc4291bis] and RFC2464 [I-D.hinden-6man-rfc2464bis], [RFC7608] an IPv6 Prefix Length Recommendation for Forwarding, and the IETF recommendation for the generation of stable Interface Identifiers [RFC8064].

[I-D.jinmei-6man-prefix-clarify] is also worth reading to clarify uses of varying prefix lengths on a single link.

3. Problems Reinforced by Classful Addressing

For host computers on local area networks, generation of interface identifiers is no longer necessarily bound to layer 2 addresses (MACs) [RFC7217] [RFC8064]. Therefore their length, previously fixed at 64 bits [RFC7136], is in fact a variably-sized parameter as explicitly acknowledged in Section 5.5.3(d) of [RFC4862] which states:

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:

4. Identifier and Subnet Length Statements

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) [RFC4862], or Using 127-Bit IPv6 Prefixes on Inter-Router Links [RFC6164].

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.

5. Recommendations

For historical reasons, when a prefix is needed on a link, barring other considerations, a /64 is recommended [RFC7136].

The length of the Interface Identifier in Stateless Address Autoconfiguration [RFC4862] 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.

As most wireless operators give a single /64 to wireless clients, subnetting beyond /64 is a real world requirement, and its absence is an incentive to deploy network address translation for IPv6. In the long term this is a use case for supporting longer prefixes than /64, in order to avoid NAT.

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 [RFC8064]) algorithm for selecting stable interface identifiers [RFC7217] is a parameter, rather than a hard-coded value.

6. Security Considerations

Assuming that nodes employ unpredictable interface identifiers [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 [RFC7707] [RFC7721]. 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).

7. IANA Considerations

This document has no IANA Considerations.

8. Authors

The authors of this document are as follows:

9. References

9.1. Normative References

[RFC2460]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, , <https://www.rfc-editor.org/info/rfc2460>.
[RFC4291]
Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, , <https://www.rfc-editor.org/info/rfc4291>.
[RFC7217]
Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, , <https://www.rfc-editor.org/info/rfc7217>.
[RFC7608]
Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix Length Recommendation for Forwarding", BCP 198, RFC 7608, DOI 10.17487/RFC7608, , <https://www.rfc-editor.org/info/rfc7608>.
[RFC8064]
Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, , <https://www.rfc-editor.org/info/rfc8064>.

9.2. Informative References

[I-D.hinden-6man-rfc2464bis]
Crawford, M. and R. M. Hinden, "Transmission of IPv6 Packets over Ethernet Networks", Work in Progress, Internet-Draft, draft-hinden-6man-rfc2464bis-02, , <https://datatracker.ietf.org/doc/html/draft-hinden-6man-rfc2464bis-02>.
[I-D.ietf-6man-rfc4291bis]
Hinden, R. M. and S. E. Deering, "IP Version 6 Addressing Architecture", Work in Progress, Internet-Draft, draft-ietf-6man-rfc4291bis-09, , <https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc4291bis-09>.
[I-D.jinmei-6man-prefix-clarify]
Jinmei, T., "Clarifications on On-link and Subnet IPv6 Prefixes", Work in Progress, Internet-Draft, draft-jinmei-6man-prefix-clarify-00, , <https://datatracker.ietf.org/doc/html/draft-jinmei-6man-prefix-clarify-00>.
[RFC2450]
Hinden, R., "Proposed TLA and NLA Assignment Rule", RFC 2450, DOI 10.17487/RFC2450, , <https://www.rfc-editor.org/info/rfc2450>.
[RFC3587]
Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, , <https://www.rfc-editor.org/info/rfc3587>.
[RFC4632]
Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, , <https://www.rfc-editor.org/info/rfc4632>.
[RFC4862]
Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, , <https://www.rfc-editor.org/info/rfc4862>.
[RFC6164]
Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-Router Links", RFC 6164, DOI 10.17487/RFC6164, , <https://www.rfc-editor.org/info/rfc6164>.
[RFC7136]
Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, , <https://www.rfc-editor.org/info/rfc7136>.
[RFC7707]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, , <https://www.rfc-editor.org/info/rfc7707>.
[RFC7721]
Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, , <https://www.rfc-editor.org/info/rfc7721>.

Author's Address

Nicolas Bourbaki
The Intertubes
42 Rue du Jour
::1 Sophia-Antipolis
France