RFC 7934

Host Address Availability Recommendations

📅 published July 2016, from ietf

Host Address Availability Recommendations 🎀

RFC 7934 · BCP 204 · July 2016 💖

  • Authors: L. Colitti (Google), V. Cerf (Google), S. Cheshire (Apple Inc.), D. Schinazi (Apple Inc.) ✨
  • Category: Best Current Practice 🌸
  • ISSN: 2070-1721 🦋
  • Obsoletes / Updates: none listed in this document's header 🫶
Part 1 of 4. More parts are coming, so stay tuned 💅

Abstract

okay so this doc says networks should give general-purpose end hosts multiple global IPv6 addresses when they connect, and it explains why that's amazing and what options exist to make it happen 🫶✨

Status of This Memo

this one is a Best Current Practice 🌈

it's an IETF product 💅 (the IETF community agreed on it, it got public review, and the IESG approved it for publication). if you want more about BCPs, check Section 2 of RFC 7841 📖

for the current status, errata, or feedback, head to http://www.rfc-editor.org/info/rfc7934 🔗

© 2016 IETF Trust and the document authors, all rights reserved 🔒

this doc is under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stood on the publication date. read those carefully, they're your rights and restrictions 🧐

if you pull code components out of this doc, they have to include the Simplified BSD License text (Section 4.e of the Trust Legal Provisions), and they come with no warranty, per the Simplified BSD License 💜

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
2.  Common IPv6 Deployment Model  . . . . . . . . . . . . . . . .   3
3.  Benefits of Providing Multiple Addresses  . . . . . . . . . .   3
4.  Problems with Restricting the Number of Addresses per Host  .   4
5.  Overcoming Limits Using Network Address Translation . . . . .   5
6.  Options for Providing More Than One Address . . . . . . . . .   6
7.  Number of Addresses Required  . . . . . . . . . . . . . . . .   8
8.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   8
9.  Operational Considerations  . . . . . . . . . . . . . . . . .   9
  9.1.  Host Tracking . . . . . . . . . . . . . . . . . . . . . .   9
  9.2.  Address Space Management  . . . . . . . . . . . . . . . .  10
  9.3.  Addressing Link-Layer Scalability Issues via IP Routing .  10
10. Security Considerations . . . . . . . . . . . . . . . . . . .  11
11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
  11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
  11.2.  Informative References . . . . . . . . . . . . . . . . .  11
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1. Introduction ✨

okay so IPv6 is basically IPv4's glow-up 💖 in most ways it's super similar, and that similarity is exactly the problem. it's easy to think of IPv6 as "128-bit IPv4" and just copy every config and ops habit over to it 🙈 that's generally a good thing, because it makes the transition and dual-stack networks way easier to run 💅 but in some design and ops areas, it can drag along IPv4 habits that are limiting or just not right for IPv6, because the protocols are actually different 🌸

IP addressing of hosts is one of those areas, and it's substantially different 😭 unlike IPv4 addresses, IPv6 addresses are not a scarce resource. one single link gets over four billion times more address space than the whole IPv4 Internet [RFC7421] 🌈 so IPv6 networks aren't forced by address scarcity to give each host only one address. and giving hosts multiple addresses has a bunch of perks: app functionality and simplicity, privacy, and flexibility for future apps 🦋 another big one is getting Internet access without Network Address Translation (NAT) 👑 giving a host only one IPv6 address kills all of those perks 💀

this doc breaks down the benefits of multiple addresses per host, plus the problems you get without them 🔍 it recommends that networks give general-purpose end hosts multiple global addresses when they attach, and it lists the current options for doing that 🎀 it doesn't specify any changes to protocols or host behavior, just so you know 🫶

1.1. Requirements Language 📜

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119] 🧠 these are the official capital-letter words, so pay attention to them 👀

2. Common IPv6 Deployment Model 🌐

IPv6 is built to support multiple addresses per interface, including multiple global ones (see Section 2.1 of [RFC4291] and Section 5.9.4 of [RFC6434]) 💜 and honestly, plenty of general-purpose IPv6 hosts today already have three or more addresses per interface, and it's giving full collection 🧚 here's the lineup:

  • a link-local address 🔗
  • a stable address (for example, one using 64-bit Extended Unique Identifiers (EUI-64) or Opaque Interface Identifiers [RFC7217]) 🪨
  • one or more privacy addresses [RFC4941] 🕶️
  • and possibly one or more temporary or non-temporary addresses obtained using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] 📬

in most general-purpose IPv6 networks, hosts can configure extra IPv6 addresses from the link prefix(es) without explicitly asking the network first ✨ that includes all 3GPP networks ([RFC6459], Section 5.2), plus Ethernet and Wi-Fi networks using Stateless Address Autoconfiguration (SLAAC) [RFC4862] 🎉 no permission slip needed, bestie 🙌

Part 1 ends here. Part 2 picks up with Section 3 (Benefits of Providing Multiple Addresses) 🎀

5. Overcoming Limits Using Network Address Translation 🦋

okay so when the network caps how many addresses a host can have, hosts can mostly dodge that by using NAT 💅. that's literally why IPv4 NAT is everywhere, and the same trick could work in IPv6 by running NAT66 on the host.

Unfortunately, NAT has some well-known drawbacks 😭. It makes apps way more complicated because they have to do NAT traversal, and it makes building new apps harder. On phones it eats battery because it needs frequent keepalives, especially for UDP. UDP apps that need to work across most of the Internet have to send keepalives at least every 30 seconds [KA]. QUIC, for example, uses a 15-second keepalive [QUIC]. Other NAT drawbacks are well-known and documented in [RFC2993]. IPv4 NAT is basically unavoidable because IPv4 space is limited, but that excuse doesn't work for IPv6 🙈. The Internet Architecture Board (IAB) guidance is that deploying IPv6 NAT is not desirable [RFC5902].

The goal of overcoming the problems from Section 4 without turning off any features has pushed developers to build IPv6 NAT anyway. There are fully stateful address+port NAT66 implementations in client operating systems today. Linux, for example, has supported NAT66 since 2012 [L66]. At least one popular software hypervisor also implemented NAT66 to work around these issues [V66]. If networks keep handing out restricted numbers of addresses, NAT66 implementations are going to multiply 🌸.

That is not a good outcome 😬. Users get hit with application brittleness, which is not it. Network operators probably won't love it either, since they may end up with higher support costs. Even when a network only gives one IPv6 address per device because of its business model, there may be little extra revenue, because devices can share their IPv6 address with other devices. Operating system makers and app developers aren't happy about it either, because they'd have to build more complexity, which means longer development time and/or less time for other features 🫠.

Honestly, one of the biggest reasons to deploy IPv6, instead of just scaling the Internet with IPv4 and large-scale NAT44, is that it can give every host on the planet end-to-end connectivity. The only thing limiting that connectivity should be intentional security policies, not accidental technical limits ✨.

6. Options for Providing More Than One Address 🧚

there are a few ways to hand a host multiple IPv6 addresses:

  • Using Stateless Address Autoconfiguration (SLAAC) [RFC4862]. SLAAC lets hosts create global IPv6 addresses on demand by forming new addresses from the global prefix(es) assigned to the link. It's usually used on shared links, but it also works while giving each host a dedicated /64 prefix. For example, that's the case if the host is connected via a point-to-point link such as in 3GPP networks, on a network where each host has its own dedicated VLAN, or on a wireless network where every Media Access Control (MAC) address is placed in its own broadcast domain.
  • Using stateful DHCPv6 address assignment [RFC3315]. Most DHCPv6 clients only ask for one non-temporary address, but the protocol allows requesting multiple temporary and even multiple non-temporary addresses, and the server could choose to hand out multiple addresses. A client could also technically request additional addresses using a different DHCP Unique Identifier (DUID), though the DHCPv6 specification implies that this is not expected behavior ([RFC3315], Section 9). The DHCPv6 server decides whether to grant or reject the request based on information about the client, including its DUID, MAC address, and more. Given a typical MTU of 1500 bytes or smaller, the maximum number of IPv6 addresses that fit in a single DHCPv6 packet is approximately 30 📦.
  • DHCPv6 Prefix Delegation (PD) [RFC3633]. DHCPv6 PD lets the client request and be delegated a prefix, which it can then use to form other addresses on its own. If the prefix is shorter than /64, it can be split into multiple subnets that can be further delegated to downstream clients. If the prefix is a /64, it can be extended via L2 bridging, Neighbor Discovery (ND) proxying [RFC4389], or /64 sharing [RFC7278], but it can't be subdivided any further, since a prefix longer than /64 is outside the current IPv6 specifications [RFC7421]. The DHCPv6 Prefix Delegation specification [RFC3633] assumes the DHCPv6 client is a router, but DHCPv6 PD itself doesn't require the client to forward IPv6 packets that aren't addressed to it. So it doesn't require the client to be an IPv6 router as defined in the IPv6 specification [RFC2460]. Also, in many cases (like tethering or hosting virtual machines), hosts are already forwarding IPv6 packets and therefore operating as IPv6 routers as defined in the IPv6 specification [RFC2460] 🌈.

Here's the comparison table 👑:

+--------------------------+-------+-------------+--------+---------+
|                          | SLAAC |    DHCPv6   | DHCPv6 |  DHCPv4 |
|                          |       |   IA_NA /   |   PD   |         |
|                          |       |    IA_TA    |        |         |
+--------------------------+-------+-------------+--------+---------+
| Can extend network       |  No+  |      No     |  Yes   |   Yes   |
|                          |       |             |        | (NAT44) |
| Can number "unlimited"   |  Yes* |     Yes*    |   No   |    No   |
| endpoints                |       |             |        |         |
| Uses stateful, request-  |   No  |     Yes     |  Yes   |   Yes   |
| based assignment         |       |             |        |         |
| Is immune to Layer 3 on- |   No  |     Yes     |  Yes   |   Yes   |
| link resource exhaustion |       |             |        |         |
| attacks                  |       |             |        |         |
+--------------------------+-------+-------------+--------+---------+

[*] Subject to network limitations, e.g., ND cache entry size limits.
    [+] Except on certain networks, e.g., /64 sharing [RFC7278].

     Table 1: Comparison of Multiple Address Assignment Options

7. Number of Addresses Required 💖

if we list out the use cases from Section 3, we can estimate how many addresses are used in normal operations 🔢. In typical implementations, privacy addresses use up to 7 addresses, one per day ([RFC4941], Section 3.5). Current mobile devices sharing an uplink connection may typically support 8 downstream client devices, and each one needs one or more addresses. A client might also choose to run several virtual machines. Current implementations of 464XLAT require the use of a separate address, and some devices need another address for their baseband chip 📱. Even a host doing just a few of these things at the same time might need on the order of 20 addresses at once. Future applications designed to use an address per application, or even per resource, will need many more 🚀. Those won't work on networks that enforce a hard limit on the number of addresses given to hosts. So in general, it's not possible to estimate in advance how many addresses are required 🤷‍♀️.

8. Recommendations 🎀

to avoid the problems described above and keep the Internet able to support new applications that use more than one IPv6 address, it is RECOMMENDED that IPv6 network deployments provide multiple IPv6 addresses from each prefix to general-purpose hosts 💜. To support future use cases, it is NOT RECOMMENDED to impose a hard limit on the size of the address pool assigned to a host. Particularly, it is NOT RECOMMENDED to limit a host to only one IPv6 address per prefix.

Because explicit requests for address space come with drawbacks (see Section 4), it is RECOMMENDED that the network let the host use new addresses without needing explicit requests 🙌. This can be done either by letting the host form new addresses autonomously (e.g., via SLAAC) or by giving the host a dedicated /64 prefix. The prefix MAY be provided using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.

Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide multiple addresses when the host connects (e.g., the approximately 30 addresses that fit into a single packet) would accommodate current clients. But it sets a limit on the number of addresses available to hosts when they attach, and that limits the development of future applications 🥺.

9. Operational Considerations ✨

Okay so this part is where the document gets into the really juicy stuff: who gets tracked, how much address space everyone gets, and why having a dedicated /64 per host is so iconic. 🦋 Let's go!

9. Operational Considerations

9.1. Host Tracking 🕵️‍♀️

Some network operators -- often operators of networks that provide services to third parties, like university campus networks -- are required to track which IP addresses are assigned to which hosts on their network. ✨ Keeping persistent logs that map user IP addresses and timestamps to hardware identifiers such as MAC addresses may be used to attribute liability for copyright infringement or other illegal activity. Yikes, but that's the reality, bestie. 💀

It is worth noting that this requirement can be met without using DHCPv6 address assignment. 🌸 For example, it is possible to maintain these mappings by monitoring the IPv6 neighbor table: routers typically allow periodic dumps of the Neighbor Cache via the Simple Network Management Protocol (SNMP) or other means, and many can be configured to log every change to the Neighbor Cache. Using SLAAC with a dedicated /64 prefix for each host simplifies tracking, as it does not require logging every address formed by the host, but only the prefix assigned to the host when it attaches to the network. 🧚 Similarly, providing address space using DHCPv6 PD has the same tracking properties as DHCPv6 address assignment, but allows the network to provide unrestricted address space. It's giving "best of both worlds" energy 👑

Many large enterprise networks are fully dual stack and implement address monitoring without using or supporting DHCPv6. The authors are directly aware of several networks that operate in this way, including the Universities of Loughborough, Minnesota, Reading, Southampton, and Wisconsin, and Imperial College London, in addition to the enterprise networks of the authors' employers. 🎓🍓

It should also be noted that using DHCPv6 address assignment does not ensure that the network can reliably track the IPv6 addresses used by hosts. 🙈 On any shared network without Layer 2 (L2) edge port security, hosts are able to choose their own addresses regardless of what address provisioning methodology the network operator believes is in use. The only way to restrict the addresses used by hosts is to use L2 security mechanisms that enforce that particular IPv6 addresses are used by particular link-layer addresses (for example, Source Address Validation Improvement (SAVI) [RFC7039]). If those mechanisms are available, it is possible to use them to provide tracking; this form of tracking is more secure and reliable than server logs because it operates independently of how addresses are allocated. 🔐 Finally, tracking address information via DHCPv6 server logs is likely to become decreasingly viable due to ongoing efforts to improve the privacy of DHCPv6 and MAC address randomization [RFC7844]. Privacy glow-up incoming 🌈

9.2. Address Space Management 🏡

In IPv4, all but the world's largest networks can be addressed using private space [RFC1918], with each host receiving one IPv4 address. Many networks can be numbered in 192.168.0.0/16, which has roughly 65 thousand addresses. In IPv6, that is equivalent to a /48, with each host receiving a /64 prefix. Under current Regional Internet Registry (RIR) policies, a /48 is easy to obtain for an enterprise network. Networks that need a bigger block of private space use 10.0.0.0/8, which has roughly 16 million addresses. In IPv6, that is equivalent to a /40, with each host receiving a /64 prefix. Enterprises of such size can easily obtain a /40 under current RIR policies. 💖

In the above cases, aggregation and routing can be equivalent to IPv4: if a network aggregates per-host IPv4 addresses into prefixes of length /32 - n, it can aggregate per-host /64 prefixes into the same number of prefixes of length /64 - n. Math that actually slaps 🧮✨

Currently, residential users typically receive one IPv4 address and a /48, /56, or /60 IPv6 prefix. While such networks do not provide enough space to assign a /64 per host, such networks almost universally use SLAAC, and thus do not pose any particular limit to the number of addresses hosts can use. 🏠

Unlike IPv4 where addresses came at a premium, in all of these networks there is enough IPv6 address space to supply clients with multiple IPv6 addresses. Address abundance, bestie 🌈💜

The number of IPv6 addresses on a link has a direct impact on networking infrastructure nodes (routers, switches) and other nodes on the link. Setting aside exhaustion attacks via L2 address spoofing, every (L2, IP) address pair impacts networking hardware requirements in terms of memory, Multicast Listener Discovery (MLD) snooping, solicited node multicast groups, etc. Many of these costs are incurred by neighboring hosts. 😮‍💨

Hosts on such networks that create unreasonable numbers of addresses risk impairing network connectivity for themselves and other hosts on the network, and in extreme cases (e.g., hundreds or thousands of addresses) may even find their network access restricted by denial-of-service protection mechanisms. 🚫 Not me making a thousand addresses and then wondering why the Wi-Fi is cooked 💀

We expect these scaling limitations to change over time as hardware and applications evolve. However, switching to a dedicated /64 prefix per host can resolve these scaling limitations. If the prefix is provided via DHCPv6 PD, or if the prefix can be used by only one link-layer address (e.g., if the link layer uniquely identifies or authenticates hosts based on MAC addresses), then there will be only one routing entry and one ND cache entry per host on the network. Furthermore, if the host is aware that the prefix is dedicated (e.g., if it was provided via DHCPv6 PD and not SLAAC), it is possible for the host to assign IPv6 addresses from this prefix to an internal virtual interface such as a loopback interface. This obviates the need to perform Neighbor Discovery and Duplicate Address Detection on the network interface for these addresses, reducing network traffic. Less chatter, more slay 🤫✨

Thus, assigning a dedicated /64 prefix per host is operationally prudent. Clearly, however, it requires more IPv6 address space than using shared links, so the benefits provided must be weighed with the operational overhead of address space management. ⚖️💅

10. Security Considerations 🔐

⚠️ Serious security business ahead, so pay attention, bestie 😭

As mentioned in Section 9.3, on shared networks using SLAAC, it is possible for hosts to attempt to exhaust network resources and possibly deny service to other hosts by creating unreasonable numbers (e.g., hundreds or thousands) of addresses. Networks that provide access to untrusted hosts can mitigate this threat by providing a dedicated /64 prefix per host. It is also possible to mitigate the threat by limiting the number of ND cache entries that can be created for a particular host, but care must be taken to ensure that the network does not prevent the legitimate use of multiple IP addresses by non-malicious hosts. 🛡️

Security issues related to host tracking are discussed in Section 9.1. 👀

11. References 📚

11.1. Normative References

11.2. Informative References 📚

these are the bonus reads. nothing here is required to get the protocol working, but they're the receipts behind the ideas 🧚

Acknowledgements 🫶

big thank-you bestie moment!! The authors want to shout out Tore Anderson, Brian Carpenter, David Farmer, Wesley George, Geoff Huston, Erik Kline, Victor Kuarsingh, Shucheng (Will) Liu, Shin Miyakawa, Dieter Siegmund, Mark Smith, Sander Steffann, Fred Templin, and James Woodyatt for their input and contributions. the people who made this possible 💜✨

Authors' Addresses 🎀

Meet the authors! Here's where to find each of them 💌

Lorenzo Colitti
Google
Roppongi 6-10-1
Minato, Tokyo  106-6126
Japan

Email: lorenzo@google.com


Vint Cerf
Google
1875 Explorer Street
10th Floor
Reston, VA  20190
United States of America

Email: vint@google.com


Stuart Cheshire
Apple Inc.
1 Infinite Loop
Cupertino, CA  95014
United States of America

Email: cheshire@apple.com


David Schinazi
Apple Inc.
1 Infinite Loop
Cupertino, CA  95014
United States of America

Email: dschinazi@apple.com
📦 where this page comes from