RFC 7421

Analysis of the 64-bit Boundary in IPv6 Addressing

📅 published January 2015, from ietf

RFC 7421 is a Standards-free, purely informational read, so I'm treating the whole thing as a group chat about why the IPv6 subnet boundary sits at /64. Part 1 covers the title block through Section 3's opener. More parts coming, so stay tuned. 🎀

Internet Engineering Task Force (IETF) · Request for Comments: 7421 · Category: Informational · ISSN: 2070-1721 · January 2015 💖

Authors: B. Carpenter, Ed. (Univ. of Auckland), T. Chown (Univ. of Southampton), F. Gont (SI6 Networks / UTN-FRH), S. Jiang (Huawei Technologies Co., Ltd), A. Petrescu (CEA, LIST), and A. Yourtchenko (Cisco). This one is informational, not a standard, and it doesn't obsolete or update any other RFC. ✨

Analysis of the 64-bit Boundary in IPv6 Addressing 🦋

Abstract 💜

okay so IPv6 unicast addresses split into a prefix (used for routing to a subnet) and an interface identifier (the bit that picks out a specific interface on that subnet). Right now the interface identifier is 64 bits almost everywhere, which leaves 64 bits for the subnet prefix. This doc explains why that fixed boundary is so good and digs into what would go wrong if it became a variable boundary. literally the whole vibe 🔥

Status of This Memo 🌸

This document is not an Internet Standards Track specification; it is published for informational purposes.

It's an IETF product, so it reflects consensus from the IETF community. It got public review and was approved by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details. 🧚

Current status, errata, and feedback info live at http://www.rfc-editor.org/info/rfc7421.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Read those carefully, because they spell out your rights and restrictions. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 💅

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Advantages of a Fixed Identifier Length . . . . . . . . . . .   4
3.  Arguments for Shorter Identifier Lengths  . . . . . . . . . .   5
  3.1.  Insufficient Address Space Delegated  . . . . . . . . . .   5
  3.2.  Hierarchical Addressing . . . . . . . . . . . . . . . . .   6
  3.3.  Audit Requirement . . . . . . . . . . . . . . . . . . . .   7
  3.4.  Concerns over ND Cache Exhaustion . . . . . . . . . . . .   7
4.  Effects of Varying the Interface Identifier Length  . . . . .   8
  4.1.  Interaction with IPv6 Specifications  . . . . . . . . . .   8
  4.2.  Possible Failure Modes  . . . . . . . . . . . . . . . . .  10
  4.3.  Experimental Observations . . . . . . . . . . . . . . . .  12
    4.3.1.  Survey of the processing of Neighbor Discovery
            Options with Prefixes Other than /64  . . . . . . . .  12
    4.3.2.  Other Observations  . . . . . . . . . . . . . . . . .  14
  4.4.  Implementation and Deployment Issues  . . . . . . . . . .  14
  4.5.  Privacy Issues  . . . . . . . . . . . . . . . . . . . . .  16
5.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
  6.2.  Informative References  . . . . . . . . . . . . . . . . .  21
Acknowledgements .  . . . . . . . . . . . . . . . . . . . . . . .  23
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

Part 1 wraps up the front matter. Section 1 next, bestie! 🧚

1. Introduction ✨

Okay so IPv6 didn't just double IPv4's address size to 64 bits to fix the shortage. The designers went bigger, to 128 bits, for flexibility and new possibilities. That's when the well-defined interface identifier (IID) showed up in the addressing model. The IPv6 addressing architecture [RFC4291] says a unicast address is n bits of subnet prefix followed by (128-n) bits of IID. The IID bits might only matter while you're deriving the IID, and once it's derived, the whole thing should be treated as an opaque value [RFC7136]. And since IPv6 routing is built on variable-length prefixes, there's no basic architectural rule that n has to be any particular value. All IPv6 routing protocols support prefixes of any length up to /128. 💖

The IID is a big deal for IPv6 stateless address autoconfiguration (SLAAC) [RFC4862]. Its length is a parameter in SLAAC, though, and it's set by a separate link-type specific document (see the definition of "interface identifier" in Section 2 of RFC 4862). SLAAC doesn't define that length or assume any particular one. DHCPv6 [RFC3315] doesn't put a prefix length in its address assignment either. 🦋

The /64 boundary came later. It showed up after the first IPv6 design, when people had been expecting /80. There were two reasons for /64. One was the original "8+8" proposal [ODELL], which eventually turned into the Identifier-Locator Network Protocol (ILNP) [RFC6741]. That needed a fixed split between the local and wide-area parts of the address. The other was the expectation that 64-bit Extended Unique Identifier (EUI-64) Media Access Control (MAC) addresses would replace 48-bit ones everywhere, plus the plan at the time that auto-configured addresses would normally come from interface identifiers derived from MAC addresses. 🎀

So RFC 4291 describes a way to build IIDs from IEEE EUI-64 hardware addresses [IEEE802], and that method makes the IIDs 64 bits long. Lots of other IID methods also use 64 bits. The addressing architecture, as modified by [RFC7136], says:

For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. If derived from an IEEE MAC-layer address, they must be constructed in Modified EUI-64 format.

Basically, almost every IPv6 IID is 64 bits. The only documented exception is [RFC6164], which standardizes 127-bit prefixes for point-to-point links between routers (and a few other things) to dodge a loop problem called the ping-pong problem. 🔥

Outside that exception, and even though the routing architecture and SLAAC design seem to allow flexibility, using an IID shorter than 64 bits with a subnet prefix longer than 64 bits is outside the current IPv6 specs. So results may vary. 🙈

So why is the subnet prefix boundary locked at /64? This doc has two jobs. First, it explains why a fixed IID length is so good. Second, it analyzes in some detail what happens if you hypothetically vary the IID length. A fixed length caps the practical routing prefix at 64 bits, even though architecturally it could be any value up to /128, like a host route. No matter the IID length, longest match runs on the prefix and IID together. Mostly we're talking about a shorter IID, which would allow a longer subnet prefix. The doc doesn't propose changing the IID length at all. 💜

The next three sections cover the advantages of the fixed IID length, some arguments for shorter lengths, and what would happen if the length changed. 🌈

2. Advantages of a Fixed Identifier Length 🍓

As Section 1 mentioned, an IID of a given length is a required part of IPv6 SLAAC [RFC4862]. That length is normally the same for every node on a link running SLAAC. It's a parameter that gets set separately for each link-layer media type, but one fixed IID length for all link-layer media is the simplest option. It also fits the principles of Internet host configuration in [RFC5505]. 💅

An IID that's a decent length and clearly separate from the subnet prefix lets you limit how traceable a host is, by changing the identifier. Section 4.5 goes deeper on this. 🕵️

An IID of real length also guarantees there are always enough addresses in any subnet to add one or more real or virtual interfaces. There might be other limits, but IP addressing will never be the thing in your way. 👑

The addressing architecture [RFC4291] [RFC7136] sets the IID at 64 bits for all unicast addresses, and so for all media that support SLAAC. Fixing the IID at 64 bits also fixes the subnet prefix at 64 bits, no matter what aggregate prefix a site gets. Per [RFC6177], that aggregate should be /56 or shorter. This setup has some specific perks:

  • Everything is the same. Compared to IPv4, there's no more calculating leaf subnet sizes, no more juggling subnets, and fewer mistakes. Network design gets simpler and way more straightforward. This matters for every kind of network (enterprise, campus, small office, or home), and for every kind of operator, from pro to consumer. 🎀
  • Adding a subnet is easy. Just grab another /64 from the pool. No estimates, math, consideration, or judgement needed. 🧚
  • Router configurations are homogeneous and easier to understand. 🌸
  • Documentation is easier to write and easier to read, and training is easier too. 📚

The rest of this document covers arguments people have made against the fixed 64-bit IID and analyzes what a change would do. But the IETF consensus is that keeping the length fixed at 64 bits and the practical difficulty of changing it outweigh the arguments for change. 👑

3. Arguments for Shorter Identifier Lengths 🦋

This section describes arguments for scenarios where shorter IIDs, which means prefixes longer than /64, have been used or proposed. 💜

That's Part 1 done, bestie. Part 2 picks up with Section 3.1! 🫶

3.1. Insufficient Address Space Delegated

okay so bestie, what if a site just doesn't get a big enough prefix to give a /64 to every single one of its internal subnets? 😭 Then the site has two choices. It can decide it doesn't have enough address space to number all its network elements and be, at the very best, only partially operational. Or it can use internal prefixes longer than /64 so multiple subnets and the hosts inside them can still get addresses. 🧚

In that second case, the site might use a /80 per subnet, with hosts either manually configured or using DHCPv6 [RFC3315]. Very resourceful, very giving. 💅

People have suggested some places where an insufficient prefix might get delegated: home or small office networks, vehicles, building services, and transportation services (e.g., road signs). 🚗 It's worth noting that the homenet architecture text [RFC7368] says Customer Premises Equipment (CPE) should consider the lack of sufficient address space to be an error condition, rather than using prefixes longer than /64 internally. So CPE is like, no, we are NOT doing that internally. 🙅‍♀️

Another scenario that gets brought up is one where the Internet address registries actually start to run out of IPv6 prefix space, so operators can't give reasonable prefixes to users in line with [RFC6177] anymore. Some people say giving every user site (even the tiniest one) a /48 or /56 like [RFC6177] recommends is wasteful. Honestly? Not so. The currently released unicast address space, 2000::/3, holds 35 trillion /48 prefixes (2**45 = 35,184,372,088,832), and only a small fraction of those have been allocated. 🌈 Even with a conservative allocation efficiency, an HD-ratio of 0.94 [RFC4692], roughly 5 trillion /48 prefixes can still be allocated. With a relaxed HD-ratio of 0.89, it's still roughly one trillion /48 prefixes. And since only 2000::/3 is committed for unicast addressing right now, we still have approximately 85% of the address space in reserve. 🫶 So there's no objective risk of prefix depletion from giving /48 or /56 prefixes even to the smallest sites. The vibes are literally fine. ✨

3.2. Hierarchical Addressing

Some operators have argued that more prefix bits are needed so a campus or corporate network can use an aggregated hierarchical addressing scheme. 🤔 But here's the thing: if a campus or enterprise gets a /48 prefix (or shorter), that already gives 16 bits for hierarchical allocation. Plus, flat IGP routing is widely and successfully used inside pretty big networks, with hundreds of routers and thousands of end systems. 💖 So there's no objective need for extra prefix bits to support hierarchy and aggregation within enterprises. Not me hunting for a problem that doesn't exist. 💀

3.3. Audit Requirement

Some network operators want to know and audit the nodes that are active on their network, especially the ones allowed to communicate off-link or off-site. 🔍 They might also want to limit the total number of active addresses and sessions that can come from one particular host, LAN, or site. The goal is to prevent potential resource-depletion attacks, or other problems, from spreading beyond a certain scope of control. 🛡️

It has been argued that this kind of control would be easier if only long network prefixes with relatively small numbers of possible hosts per network were used, since that would reduce the discovery problem. But these sites usually operate with DHCPv6, which means all legitimate hosts are automatically known to the DHCPv6 servers. That's enough for audit purposes, bestie! 🎀 If they want, those hosts can be limited to a small range of IID values without changing the /64 subnet length. And any hosts that accidentally get addresses via SLAAC can be audited through Neighbor Discovery (ND) logs. 📋

3.4. Concerns over ND Cache Exhaustion

A site might be worried that it's open to ND cache exhaustion attacks [RFC3756]. This is where an attacker sends a huge number of messages in rapid succession to a series of (most likely inactive) host addresses within one specific subnet. 😈 The attack tries to fill a router's ND cache with ND requests that are still pending completion, which ends up denying correct operation to the active devices on the network. Scary, not cute. 💀

One potential way to mitigate this would be to use a /120 prefix. That limits the number of addresses in the subnet to something similar to an IPv4 /24 prefix, which shouldn't cause any ND cache exhaustion concerns. 🧁 But the prefix does need to be quite long for this to be valid. The number of theoretically possible ND cache slots on the segment needs to be the same order of magnitude as the actual number of hosts. So small increases from the /64 prefix length don't make a noticeable difference. Even 2^32 potential entries, a factor of two billion decrease compared to 2^64, is still more than enough to exhaust the memory on current routers. 😱 Also, since most link-layer mappings make SLAAC assume a 64-bit network boundary, hosts would likely need to use DHCPv6 or be manually configured with addresses in this approach. 🙈

It's worth noting that several other mitigations for the ND cache attack are described in [RFC6583]. Limiting the size of the cache and the number of incomplete entries allowed would also defeat the attack. ✅ And for the specific case of a point-to-point link between routers, this attack is indeed mitigated by a /127 prefix [RFC6164]. Tiny prefix, big security energy. 🔒

4. Effects of Varying the Interface Identifier Length

okay this section is the big one, bestie. 🧠 It analyzes the impact and effects of changing the length of an IPv6 unicast IID by shrinking it to less than 64 bits. Let's see who's affected. 👀

4.1. Interaction with IPv6 Specifications

The precise 64-bit length of the IID gets mentioned in tons of RFCs describing different parts of IPv6. 📚 It isn't straightforward to tell which cases actually have normative impact or affect interoperability. So this section tries to find the specifications that contain an explicit reference to the 64-bit length. Regardless of implementation issues, every one of those RFCs would need to be updated if the 64-bit rule ever changed, even for tiny updates. That's considerable time and effort, honestly a whole mood. 😩

First and foremost, the RFCs describing the architectural aspects of IPv6 addressing explicitly state, refer to, and repeat this apparently immutable value. That includes Addressing Architecture [RFC4291], IPv6 Address Assignment to End Sites [RFC6177], Reserved IIDs [RFC5453], and ILNP Node Identifiers [RFC6741]. Customer edge routers impose /64 for their interfaces [RFC7084]. And The IPv6 Subnet Model [RFC5942] points out that assuming a /64 prefix length is a potential implementation error. 🙃

Then there are the numerous IPv6-over-foo documents that make mandatory statements about the 64-bit length of the IID used during Stateless Autoconfiguration. 🔧 These include [RFC2464] (Ethernet), [RFC2467] (Fiber Distributed Data Interface (FDDI)), [RFC2470] (Token Ring), [RFC2492] (ATM), [RFC2497] (ARCnet), [RFC2590] (Frame Relay), [RFC3146] (IEEE 1394), [RFC4338] (Fibre Channel), [RFC4944] (IEEE 802.15.4), [RFC5072] (PPP), [RFC5121], [RFC5692] (IEEE 802.16), [RFC2529] (6over4), [RFC5214] (Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)), [AERO-TRANS] (Asymmetric Extended Route Optimization (AERO)), [BLUETOOTH-LE] (BLUETOOTH Low Energy), [IPv6-TRANS] (IPv6 over MS/TP), and [IPv6-G9959] (IPv6 packets over ITU-T G.9959). That's a LOT of cross-referencing, bestie. 🥴

To a lesser extent, the address configuration RFCs may in some ways assume the 64-bit length of an IID too (e.g, RFC 4862 for the link-local addresses, DHCPv6 for the potentially assigned EUI-64-based IP addresses, and Optimistic Duplicate Address Detection [RFC4429] that computes 64-bit-based collision probabilities). 🧮

The Multicast Listener Discovery Version 1 (MLDv1) [RFC2710] and MLDv2 [RFC3810] protocols mandate that all queries be sent with a link-local source address. The exception is MLD messages sent using the unspecified address when the link-local address is tentative [RFC3590]. When RFC 2710 was published, the IPv6 addressing architecture specified link-local addresses with 64-bit interface identifiers. MLDv2 explicitly specifies the use of the fe80::/64 link-local prefix, and it bases the querier election algorithm on the link-local subnet prefix of length /64. 🗳️

The "IPv6 Flow Label Specification" [RFC6437] gives an example of a 20-bit hash function generation. That example relies on splitting an IPv6 address into two equally sized, 64-bit-length parts. 🪓

The basic transition mechanisms [RFC4213] refer to IIDs of length 64 for link-local addresses. Other transition mechanisms, like Teredo [RFC4380], assume IIDs of length 64 too. You'll find similar assumptions in 6to4 [RFC3056] and 6rd [RFC5969]. Translation-based transition mechanisms such as NAT64 and NPTv6 have some dependency on prefix length, which is discussed below. 🔄

The proposed method [RFC7278] of extending an assigned /64 prefix from a smartphone's cellular interface to its WiFi link relies on the prefix length, and implicitly on the length of the IID, being valued at 64. 📱

The Cryptographically Generated Addresses (CGA) and Hash-Based Addresses (HBA) specifications rely on the 64-bit identifier length (see below). The Privacy extensions [RFC4941] do too, and so do some examples in "Internet Key Exchange Version 2 (IKEv2)" [RFC7296]. 🔐

464XLAT [RFC6877] explicitly mentions acquiring /64 prefixes. However, it also discusses using the interface address on the device as the end point for the traffic, which could potentially remove this dependency. 💫

[RFC2526] reserves a number of subnet anycast addresses by reserving some anycast IIDs. An anycast IID reserved this way cannot be less than 7 bits long. That means a subnet prefix length longer than /121 isn't possible, and a subnet of exactly /121 would be useless since all its identifiers are reserved. It also means that half of a /120 is reserved for anycast. 🙃 This could be fixed in the way described for /127 in [RFC6164], which means avoiding the use of anycast within a /120 subnet. Note that support for "on-link anycast" is a standard IPv6 neighbor discovery capability [RFC4861] [RFC7094], so applications and their developers would expect it to be available. 👩‍💻

The Mobile IP home network models [RFC4887] rely heavily on the /64 subnet length and assume a 64-bit IID. 🏠

While preparing this document, it was noted that many other IPv6 specifications refer to mandatory alignment on 64-bit boundaries, 64-bit data structures, 64-bit counters in MIBs, 64-bit sequence numbers and cookies in security, and so on. 🗂️ Finally, the number "64" may be considered "magic" in some RFCs, like the 64k limits in DNS and the Base64 encodings in MIME. ✨ None of this has any influence on the length of the IID, but it might confuse a careless reader. So read carefully, bestie! 🫶

4.2. Possible Failure Modes 💅

okay bestie, this section is all about where things could literally break if we use prefixes other than /64 🙈 we can expect operational failures here, so let's go through each spot fr fr.

  • Router implementations 🛣️: Router implementors might interpret IETF specifications such as [RFC6164] and [RFC7136] as indicating that prefixes between /65 and /126 (inclusive) for unicast packets on-the-wire are invalid and that operational practices that utilize prefix lengths in this range may fail on some devices, as discussed in Section 4.3.2.
  • Multicast 📣: [RFC3306] defines a method for generating IPv6 multicast group addresses based on unicast prefixes. This method assumes a longest prefix of 64 bits. If a longer prefix is used, there is no way to generate a specific multicast group address using this method. In such cases, the administrator would need to use an "artificial" prefix from within their allocation (a /64 or shorter) from which to generate the group address. This prefix would not correspond to a real subnet.

Similarly, [RFC3956], which specifies the Embedded Rendezvous Point (RP)) allowing IPv6 multicast rendezvous point addresses to be embedded in the multicast group address, would also fail, as the scheme assumes a maximum prefix length of 64 bits.

  • CGA 🔐: The Cryptographically Generated Address format [RFC3972] is heavily based on a /64 interface identifier. [RFC3972] has defined a detailed algorithm showing how to generate a 64-bit interface identifier from a public key and a 64-bit subnet prefix. Changing the /64 boundary would certainly invalidate the current CGA definition. However, the CGA might benefit in a redefined version if more bits are used for interface identifiers (which means shorter prefix length). For now, 59 bits are used for cryptographic purposes. The more bits are available, the stronger CGA could be. Conversely, longer prefixes would weaken CGA.
  • NAT64 🔀: Both stateless NAT64 [RFC6052] and stateful NAT64 [RFC6146] are flexible for the prefix length. [RFC6052] has defined multiple address formats for NAT64. In Section 2 of "IPv4-Embedded IPv6 Address Prefix and Format" [RFC6052], the network-specific prefix could be one of /32, /40, /48, /56, /64, and /96. The remaining part of the IPv6 address is constructed by a 32-bit IPv4 address, an 8-bit u byte and a variable length suffix (there is no u byte and suffix in the case of the 96-bit Well-Known Prefix). NAT64 is therefore OK with a subnet boundary out to /96 but not longer.
  • NPTv6 🪞: IPv6-to-IPv6 Network Prefix Translation [RFC6296] is also bound to /64 boundary. NPTv6 maps a /64 prefix to another /64 prefix. When the NPTv6 Translator is configured with a /48 or shorter prefix, the 64-bit interface identifier is kept unmodified during translation. However, the /64 boundary might be changed as long as the "inside" and "outside" prefixes have the same length.
  • ILNP 🧩: Identifier-Locator Network Protocol (ILNP) [RFC6741] is designed around the /64 boundary, since it relies on locally unique 64-bit node identifiers (in the interface identifier field). While a redesign to use longer prefixes is not inconceivable, this would need major changes to the existing specification for the IPv6 version of ILNP.
  • Shim6 🫶: The Multihoming Shim Protocol for IPv6 (Shim6) [RFC5533] in its insecure form treats IPv6 addresses as opaque 128-bit objects. However, to secure the protocol against spoofing, it is essential to either use CGAs (see above) or HBAs [RFC5535]. Like CGAs, HBAs are generated using a procedure that assumes a 64-bit identifier. Therefore, in effect, secure shim6 is affected by the /64 boundary exactly like CGAs.
  • Duplicate address risk 🎲: If SLAAC was modified to work with shorter IIDs, the statistical risk of hosts choosing the same pseudo-random identifier [RFC7217] would increase correspondingly. The practical impact of this would range from slight to dramatic, depending on how much the IID length was reduced. In particular, a /120 prefix would imply an 8-bit IID and address collisions would be highly probable. 😭
  • The link-local prefix 🔗: While RFC 4862 is careful not to define any specific length of link-local prefix within fe80::/10, the addressing architecture [RFC4291] does define the link-local IID length to be 64 bits. If different hosts on a link used IIDs of different lengths to form a link-local address, there is potential for confusion and unpredictable results. Typically today the choice of 64 bits for the link-local IID length is hard-coded per interface, in accordance with the relevant IPv6-over-foo specification, and systems behave as if the link-local prefix was actually fe80::/64. There might be no way to change this except conceivably by manual configuration, which will be impossible if the host concerned has no local user interface.

It goes without saying that if prefixes longer than /64 are to be used, all hosts must be capable of generating IIDs shorter than 64 bits, in order to follow the auto-configuration procedure correctly [RFC4862]. 💀

4.3. Experimental Observations 🧪

4.3.1. Survey of the processing of Neighbor Discovery Options with Prefixes Other than /64 🔍

this section gives us a survey of how Neighbor Discovery options are processed when they include prefixes that are different than /64 👀

the behavior of nodes was assessed with respect to the following options:

  • PIO-A: Prefix Information Option (PIO) [RFC4861] with the A bit set.
  • PIO-L: Prefix Information Option (PIO) [RFC4861] with the L bit set.
  • PIO-AL: Prefix Information Option (PIO) [RFC4861] with both the A and L bits set.
  • RIO: Route Information Option (RIO) [RFC4191].

in the tables below, the following notation is used:

  • NOT-SUP: This option is not supported (i.e., it is ignored no matter the prefix length used).
  • LOCAL: The corresponding prefix is considered "on-link".
  • ROUTE: The corresponding route is added to the IPv6 routing table.
  • NOT-DEF: The default configuration is NOT-SUP, but there is an option to enable ROUTE.
  • IGNORE: The option is ignored as an error.
        +--------------------+--------+-------+--------+---------+
        |  Operating System  | PIO-A  | PIO-L | PIO-AL |   RIO   |
        +--------------------+--------+-------+--------+---------+
        |    FreeBSD 9.0     | IGNORE | LOCAL | LOCAL  | NOT-SUP |
        +--------------------+--------+-------+--------+---------+
        |   Linux 3.0.0-15   | IGNORE | LOCAL | LOCAL  | NOT-DEF |
        +--------------------+--------+-------+--------+---------+
        |   Linux-current    | IGNORE | LOCAL | LOCAL  | NOT-DEF |
        +--------------------+--------+-------+--------+---------+
        |     NetBSD 5.1     | IGNORE | LOCAL | LOCAL  | NOT-SUP |
        +--------------------+--------+-------+--------+---------+
        |  OpenBSD-current   | IGNORE | LOCAL | LOCAL  | NOT-SUP |
        +--------------------+--------+-------+--------+---------+
        |     Win XP SP2     | IGNORE | LOCAL | LOCAL  |  ROUTE  |
        +--------------------+--------+-------+--------+---------+
        | Win 7 Home Premium | IGNORE | LOCAL | LOCAL  |  ROUTE  |
        +--------------------+--------+-------+--------+---------+

Table 1: Processing of ND options with prefixes longer than /64

        +--------------------+--------+-------+--------+---------+
        |  Operating System  | PIO-A  | PIO-L | PIO-AL |   RIO   |
        +--------------------+--------+-------+--------+---------+
        |    FreeBSD 9.0     | IGNORE | LOCAL | LOCAL  | NOT-SUP |
        +--------------------+--------+-------+--------+---------+
        |   Linux 3.0.0-15   | IGNORE | LOCAL | LOCAL  | NOT-DEF |
        +--------------------+--------+-------+--------+---------+
        |   Linux-current    | IGNORE | LOCAL | LOCAL  | NOT-DEF |
        +--------------------+--------+-------+--------+---------+
        |     NetBSD 5.1     | IGNORE | LOCAL | LOCAL  | NOT-SUP |
        +--------------------+--------+-------+--------+---------+
        |  OpenBSD-current   | IGNORE | LOCAL | LOCAL  | NOT-SUP |
        +--------------------+--------+-------+--------+---------+
        |     Win XP SP2     | IGNORE | LOCAL | LOCAL  |  ROUTE  |
        +--------------------+--------+-------+--------+---------+
        | Win 7 Home Premium | IGNORE | LOCAL | LOCAL  |  ROUTE  |
        +--------------------+--------+-------+--------+---------+

Table 2: Processing of ND options with prefixes shorter than /64

the results can be summarized like this:

  • The "A" bit in the Prefix Information Options is honored only if the prefix length is 64. This is consistent with [RFC4862], at least for the case where the IID length is defined to be 64 bits in the corresponding link-type-specific document, which is the case for all currently published such documents. [RFC4862] defines the case where the sum of the advertised prefix length and the IID length does not equal 128 as an error condition.
  • The "L" bit in the Prefix Information Options is honored for any arbitrary prefix length (whether shorter or longer than /64).
  • Nodes that support the Route Information Option allow such routes to be specified with prefixes of any arbitrary length (whether shorter or longer than /64)

4.3.2. Other Observations ✨

participants in the V6OPS working group have indicated that some forwarding devices have been shown to work correctly with long prefixes such as /80 or /96. Indeed, it is to be expected that forwarding based on the longest prefix match will work for any prefix length, and no reports of this completely failing have been noted. Also, DHCPv6 is in widespread use without any dependency on the /64 boundary. Reportedly, there are deployments of /120 subnets configured using DHCPv6.

there have been definite reports that some routers have a performance drop-off or even resource exhaustion for prefixes longer than /64 due to design issues. In particular, some routing chip designs allocate much less space for longer prefixes than for prefixes up to /64 for the sake of savings in memory, power, and lookup latency. Some devices need special-case code to handle point-to-point links according to [RFC6164].

it has been reported that at least one type of switch has a content-addressable memory limited to 144 bits, which is indeed a typical value for commodity components [TCAM]. This means that packet filters or access control lists cannot be defined based on 128-bit addresses and two 16-bit port numbers; the longest prefix that could be used in such a filter is a /112. 🧠

4.4. Implementation and Deployment Issues

Okay bestie, from the very beginning IPv6 implementations and deployments just assumed the /64 subnet length 🎀, even though routing was totally fine with prefixes of any length 🤷‍♀️. As shown above, this got locked into lots of specifications (Section 4.1) and into important bits of implementations commonly used on local area networks (Section 4.3). Honestly, a programmer could easily fall into a comfy rule of thumb: subnet prefixes are always /64 and an IID is always 64 bits long 💅. Apart from the limited evidence in Section 4.3.1, we can't tell without code inspections or tests whether existing stacks can handle a flexible IID length or would need changes to do so 😭. An implementation of an IPv6-over-foo that specifies a 64 bit IID for foo links will obviously only support 64 ✅. But in a well designed stack, the IP layer itself treats that 64 as a parameter, so changing the IID length in the IPv6-over-foo code should be all that is necessary ✨.

The main practical consequence of the existing specifications is that deployments with longer subnet prefixes can't use SLAAC-configured addresses 🙃. They need either manually configured addresses or DHCPv6. To flip this around, if people wanted to allow auto-configured addresses with subnet prefixes longer than /64, every specification listed above as depending on /64 would have to be modified, with due regard to interoperability with unmodified stacks 🧐. In fact, [RFC7217] allows for this possibility. After that, modified stacks would have to be developed and deployed. Some stacks might have dependencies on the /64 boundary that aren't directly implied by the specifications, and any such hidden dependencies would also need to be found and removed 🕵️‍♀️.

At least one DHCPv6 client unconditionally installs a /64 prefix as on-link when it configures an interface with an address 👀. Some specific operating system vendors seem to change this default by tweaking a client-side script. This is in clear violation of the IPv6 subnet model [RFC5942] 🚨. The reason for this choice is that if there is no router on the link, hosts would fail to communicate with each other using the configured addresses, because the "on-link assumption" was removed in [RFC4861]. This isn't really about the magic number of 64. An implementation may sometimes pick an arbitrary prefix length because the on-link assumption is gone, and the value it chooses will most likely be 64 💖.

Typical IP Address Management (IPAM) tools treat /64 as the default subnet length, but they let users specify longer subnet prefixes if they want 🛠️. Clearly, all IPAM tools and network management systems would need to be checked in detail 🔍.

Finally, IPv6 is already deployed at many sites, with a large number of staff trained on the basis of the existing standards. It's supported by documentation and tools built on those standards too 📚. Numerous existing middlebox devices are also based on those standards 📦. All these people, documents, tools, and devices represent a huge investment, and a change to the /64 boundary would seriously impact every bit of it 😩🫶.

4.5. Privacy Issues

The length of the interface identifier has implications for privacy [ADDRESS-PRIVACY] 🦋. Whenever the value of the identifier is meant to be hard to guess, whether or not it's cryptographically generated, more bits are better, no cap 🔐. For example, if only 20 bits need to be guessed, then at most just over a million guesses are needed. That's well within the reach of a low-cost attack mechanism 💀. It's hard to say in general how many bits are enough to protect privacy, since that depends on the resources the attacker has. Still, it's clear that a privacy solution needs to resist an attack requiring billions rather than millions of guesses 🎯. Trillions would be even better, which suggests that at least 40 bits should be available 🧠. So we can argue that subnet prefixes longer than, say, /80 might raise privacy concerns by making the IID guessable 👀.

A prefix long enough to limit the number of addresses to something comparable to an IPv4 subnet, such as /120, would create exactly the same privacy situation as IPv4, except without NAT 🙈. In particular, a host would be forced to pick a new IID when roaming to a new network, to avoid collisions 🔄. As mentioned earlier, SLAAC will likely not be used on such a subnet 🙅‍♀️.

5. Security Considerations

Okay, this section is serious, so buckle up 😭🔥. Besides the privacy issues mentioned in Section 4.5, and the issues mentioned with CGAs and HBAs in Section 4.2, the length of the subnet prefix affects how well you can defend against scanning attacks [HOST-SCANNING] 🎯. If the attacker has discovered or guessed the prefix length, a longer prefix shrinks the space they need to scan. For example, with a /120 it's only 256 addresses 😬. On the other hand, if the attacker hasn't discovered the prefix length and assumes it's /64, routers can trivially discard attack packets that don't fall within an actual subnet 🛡️.

But wait, it gets messier 🌪️. Say an attacker finds one valid address "A" and assumes it's inside a long prefix like a /120. They then start a scanning attack by working "outwards" from A, trying A+1, A-1, A+2, A-2, and so on 🏃‍♀️. This attacker will easily find all hosts in any subnet with a long prefix, because those hosts will have addresses close to A. So we conclude that any prefix containing densely packed valid addresses is vulnerable to a scanning attack, and the attacker doesn't even need to guess the prefix length 💔. Therefore, to keep IPv6's advantage over IPv4 when it comes to resisting scanning attacks, it's important that subnet prefixes are short enough to allow sparse allocation of identifiers within each subnet ✨. The considerations are similar to those for privacy, so we can again argue that prefixes longer than, say, /80 might significantly increase vulnerability 🚩. Ironically, this argument is exactly the converse of the argument for longer prefixes to resist an ND cache attack, as described in Section 3.4 🙃.

Denial-of-service attacks related to Neighbor Discovery are discussed in Section 3.4 and in [RFC6583] 📢. One of the mitigations suggested by that document is "sizing subnets to reflect the number of addresses actually in use". But the document doesn't note that this greatly simplifies scanning attacks 😩. For further discussion of scanning attacks, see [HOST-SCANNING] 📖.

Note that, although it wasn't known at the time of writing, there might be other resource exhaustion attacks, similar in nature to the ND cache attack 🌋. We can't rule out that such attacks might be made worse by sparsely populated subnets such as a /64 🙀. It should also be noted that this analysis assumes a conventional deployment model, with a significant number of end-systems located in a single LAN broadcast domain. Other deployment models might lead to different conclusions 🌈.

6. References

6.1. Normative References

Okay bestie, here's the must-read pile 📚✨ Every one of these is normative, so the spec leans on them for real 🫶

Ooh, that's the whole normative pile 💜 The informative refs are coming up next 👀

6.2. Informative References 🦋

Okay so these are the "go read this if you want the full story" references 📚 Some are still works in progress, which just means they're drafts that haven't made it to RFC status yet 💅

[ADDRESS-PRIVACY] Cooper, A., Gont, F., and D. Thaler, "Privacy Considerations for IPv6 Address Generation Mechanisms", Work in Progress, draft-ietf-6man-ipv6-address-generation-privacy-02, October 2014.

[AERO-TRANS] Templin, F., "Transmission of IP Packets over AERO Links", Work in Progress, draft-templin-aerolink-46, October 2014.

[BLUETOOTH-LE] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets over BLUETOOTH Low Energy", Work in Progress, draft-ietf-6lowpan-btle-12, February 2013.

[HOST-SCANNING] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", Work in Progress, draft-ietf-opsec-ipv6-host-scanning-04, June 2014.

[IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE Std 802-2001 (R2007), 2007.

[IPv6-G9959] Brandt, A. and J. Buron, "Transmission of IPv6 packets over ITU-T G.9959 Networks", Work in Progress, draft-ietf-6lo-lowpanz-08, October 2014.

[IPv6-TRANS] Lynn, K., Ed., Martocci, J., Neilson, C., and S. Donaldson, "Transmission of IPv6 over MS/TP Networks", Work in Progress, draft-ietf-6lo-6lobac-00, July 2014.

[ODELL] O'Dell, M., "8+8 - An Alternate Addressing Architecture for IPv6", Work in Progress, draft-odell-8+8-00, October 1996.

[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999, <http://www.rfc-editor.org/info/rfc2629>.

[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004, <http://www.rfc-editor.org/info/rfc3756>.

[RFC4692] Huston, G., "Considerations on the IPv6 Host Density Metric", RFC 4692, October 2006, <http://www.rfc-editor.org/info/rfc4692>.

[RFC4887] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network Mobility Home Network Models", RFC 4887, July 2007, <http://www.rfc-editor.org/info/rfc4887>.

[RFC5505] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, "Principles of Internet Host Configuration", RFC 5505, May 2009, <http://www.rfc-editor.org/info/rfc5505>.

[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012, <http://rfc-editor.org/info/rfc6583>.

[RFC6741] Atkinson,, RJ., "Identifier-Locator Network Protocol (ILNP) Engineering Considerations", RFC 6741, November 2012, <http://www.rfc-editor.org/info/rfc6741>.

[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013, <http://www.rfc-editor.org/info/rfc6877>.

[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, January 2014, <http://www.rfc-editor.org/info/rfc7094>.

[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>.

[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link", RFC 7278, June 2014, <http://www.rfc-editor.org/info/rfc7278>.

[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC, 7368, October 2014.

[TCAM] Meiners, C., Liu, A., and E. Torng, "Algorithmic Approaches to Redesigning TCAM-Based Systems", ACM SIGMETRICS'08 467-468, 2008.

Acknowledgements 🫶

Okay, the whole vibe of this doc started with a seriously heated debate on the V6OPS working group mailing list, with at least 20 participants 🔥 Later on, valuable comments came in from Ran Atkinson, Fred Baker, Steven Blake, Lorenzo Colitti, David Farmer, Bill Fenner, Ray Hunter, Paraskevi Iliadou, Jen Linkova, Philip Matthews, Matthew Petach, Scott Schmit, Tatuya Jinmei, Fred Templin, Ole Troan, Stig Venaas, and numerous other participants in the 6MAN working group 💜 Mark Smith's extremely detailed review was especially helpful, and honestly, iconic behaviour 👑

This document was originally produced using the xml2rfc tool [RFC2629]. ✨

Authors' Addresses 💌

Here's where to find the people who wrote this, bestie 🦋

Brian Carpenter (editor)
Department of Computer Science
University of Auckland
PB 92019
Auckland  1142
New Zealand
EMail: brian.e.carpenter@gmail.com
Tim Chown
University of Southampton
Southampton, Hampshire  SO17 1BJ
United Kingdom
EMail: tjc@ecs.soton.ac.uk
Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires  1706
Argentina
EMail: fgont@si6networks.com
Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing  100095
P.R. China
EMail: jiangsheng@huawei.com
Alexandru Petrescu
CEA, LIST
CEA Saclay
Gif-sur-Yvette, Ile-de-France  91190
France
EMail: Alexandru.Petrescu@cea.fr
Andrew Yourtchenko
Cisco
7a de Kleetlaan
Diegem  1830
Belgium
EMail: ayourtch@cisco.com
📦 where this page comes from