RFC 9663

Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6 Prefixes per Client in Large Broadcast Networks

📅 published October 2024, from ietf

RFC 9663: Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6 Prefixes per Client in Large Broadcast Networks 🎀

okay bestie, let's get the basics down first 💅

  • Publisher: Internet Engineering Task Force (IETF) 🌸
  • Request for Comments: 9663
  • Category: Informational 📚
  • ISSN: 2070-1721
  • Date: October 2024 🗓️
  • Authors: L. Colitti (Google, LLC); J. Linkova, Ed. (Google); X. Ma, Ed. (Google) 🫶

The title block doesn't list anything this RFC obsoletes or updates, so there's nothing to report there ✨

Abstract 🌈

So this doc looks at an IPv6 setup where individual nodes on big broadcast networks (think enterprise networks or public Wi-Fi) each get their own unique prefix through DHCPv6 Prefix Delegation (DHCPv6-PD), as specified in RFC 8415. It's giving unique prefix per device 🦋

Status of This Memo 📝

Not gonna lie, this one is not an Internet Standards Track spec. It's published just for informational purposes 🧚

This is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 for the deets 👑

Want the latest status, any errata, or a way to send feedback? Head to https://www.rfc-editor.org/info/rfc9663 💌

Copyright (c) 2024 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 (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please actually read these, because they spell out your rights and restrictions for this document 🙈 Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License ⚖️

Table of Contents 🗺️

   1.  Introduction
   2.  Requirements Language
   3.  Terminology
   4.  Design Principles
   5.  Applicability and Limitations
   6.  Routing and Addressing Considerations
     6.1.  Prefix Pool Allocation
     6.2.  First-Hop Router Requirements
     6.3.  Topologies with Multiple First-Hop Routers
     6.4.  On-Link Communication
   7.  DHCPv6-PD Server Considerations
   8.  Prefix Length Considerations
   9.  Client Mobility
   10. Antispoofing and SAVI Interaction
   11. Migration Strategies and Co-existence with SLAAC Using Prefixes
           from the PIO
   12. Benefits
   13. Privacy Considerations
   14. IANA Considerations
   15. Security Considerations
   16. References
     16.1.  Normative References
     16.2.  Informative References
   Appendix A.  Multiple Addresses Considerations
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

Okay so broadcast networks like enterprise or public Wi-Fi often cram tons of devices onto one shared link with a single on-link prefix. This doc describes a different model, where individual devices grab their prefixes from the network itself. It gives two big perks 💖

First, it's way more scalable 📈 IPv6 lets hosts have multiple addresses (unlike IPv4), and most deployments do this (see Appendix A for the tea). But more addresses means more scalability issues for the network infrastructure. Network devices have to keep track of all kinds of tables and hashes, like the Neighbor Cache on first-hop routers, Neighbor Discovery Proxy caches on Layer 2 devices, and so on. On Virtual eXtensible Local Area Network (VXLAN) networks [RFC7348], each address might be represented as a route. So if every client has 10 addresses instead of one, the network has to support 10 times more routes, and so on 😭 If an infrastructure device runs out of resources, it might drop some IPv6 addresses from its tables, even while the address owner is still using them to send traffic. That means traffic gets discarded and the customer experience gets degraded 💀 Giving every host one prefix means the network only keeps one entry per device, and the device can still use an arbitrary number of addresses. Main character energy for the network 👑

Second, this model lets devices extend the network 🌿 In IPv4, a device that connects to the network can give connectivity to subtended devices by using NAT. With DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC8415], a device can do something similar, but unlike IPv4 NAT, it can give its subtended devices full end-to-end connectivity. Iconic 🦋

Another method for deploying unique prefixes per device is documented in [RFC8273]. Also, the standard deployment model in cellular IPv6 networks [RFC6459] gives every device a unique prefix. Still, a unique prefix per device is really uncommon in enterprise-style networks, where nodes usually connect to broadcast segments like VLANs, and each link has a single on-link prefix assigned. This document takes a similar approach to [RFC8273], but allocates the prefix using DHCPv6-PD 🎀

Heads up: this doc focuses on how the network behaves. Host behavior is not defined in this document 🙈

2. Requirements Language 📏

Here's the tea on the key words. "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when, and only when, they show up in ALL CAPS like they do right here 💅

3. Terminology 📚

Let's define our vocab so we're on the same page 🧚

  • Node: a device that implements IPv6 [RFC8200] ✨
  • Host: any node that is not a router [RFC8200] 🌸
  • Client: a node that connects to a network and acquires addresses. The node may wish to obtain addresses for its own use, or it may be a router that wishes to extend the network to its physical or virtual subsystems, or both. It may be either a host or a router as defined by [RFC8200] 🦋
  • AP: (wireless) Access Point 📶
  • DHCPv6 IA_NA: Identity Association for Non-temporary Addresses (Section 21.4 of [RFC8415]) 💜
  • DHCPv6 IA_PD: Identity Association for Prefix Delegation (Section 21.21 of [RFC8415]) 🌈
  • DHCPv6-PD: DHCPv6 Prefix Delegation [RFC8415]; a mechanism to delegate IPv6 prefixes to clients 🎀
  • ND: Neighbor Discovery [RFC4861] 🫶
  • NUD: Neighbor Unreachability Detection [RFC4861] 💫
  • PIO: Prefix Information Option [RFC4862] ⭐
  • SLAAC: IPv6 Stateless Address Autoconfiguration [RFC4862] 🍓

4. Design Principles 🎀

Okay so instead of every client on a link building addresses from the same shared prefix assigned to that link, this deployment model works like this 💅

  • A device acts as a DHCPv6-PD client and asks for a prefix via DHCPv6-PD by sending an IA_PD request. 🌸
  • The server delegates a prefix to the client, and the delegated prefix gets installed into the first-hop router's routing table as a route pointing at the client's link-local address. The first-hop router can act as a DHCPv6 relay and snoop DHCPv6 Reply messages from an off-link DHCPv6 server, or it can act as a DHCPv6 server itself. Either way, it can install the route locally, and if the network runs a dynamic routing protocol, it can distribute the route or the entire prefix pool into that protocol. 🦋
  • For the router and all the other infrastructure devices, the delegated prefix is considered off-link, so traffic to that prefix doesn't trigger any ND packets. The only exception is the minimum ND needed to sustain Neighbor Unreachability Detection (NUD) for the client's link-local address. 🫶
  • The device can use the delegated prefix in various ways. For example, it can form addresses, as described in requirement WAA-7 of [RFC7084]. It can also extend the network, as described in [RFC7084] or [RFC7278]. ✨

An example scenario is shown in Figure 1. The prefix lengths in the example are /64 because that's the length SLAAC currently supports. The proposed deployment model doesn't otherwise require it, so no stress 🙈

+------------------------------------------------------------------+
|                          DHCPv6 Servers                          |
|     Pool 3fff:0:d::/48 for clients on 2001:db8:ff::/64 link      |
+------------+---------------------+----------------------------+--+
      ^      |                     |                    ^       |
      |      |                     |                    |       |
+-------+------+---------------------+--------------------+-------+---+
| DHCPv6|      |                IPv6 Network       DHCPv6 |       |   |
|Relay-Forward |                                   Relay-Forward  |   |
|      ^       v        Route for 3fff:0:d::/48          ^        v   |
|      |    DHCPv6           |            |              |     DHCPv6 |
|      |  Relay-Reply        |            |              | Relay-Reply|
|      |       |             |            |              |        |   |
+------+-------+--+----------+------------+------+-------+--------+---+
       |       |  |          |            |      |       |        |
       |       v  |          v            v      |       |        v
  +----+----------+---------------+    +---------+-------+------------+
  | First-hop router/DHCPv6 relay |    | First-hop Router/DHCPv6 relay|
  |  3fff:0:d:1::/64 -> fe80::aa  |    | 3fff:0:d:1::/64 -> fe80::aa  |
  |  3fff:0:d:2::/64 -> fe80::cc  |    | 3fff:0:d:2::/64 -> fe80::cc  |
  +------------+----------+-------+    +--------+----------------+----+
      ^        |          |   Shared IPv6 link  |        ^       |
      |        |          |   2001:db8:ff::/64  |        |       |
      |        |   -+-----+-----------+---------+-----+- |       |
      |        |    |                 |               |  |       |
      |        |    | +---------------+-------------+ | DHCPv6   |
   DHCPv6      |    | | Client B (no DHCPv6-PD)     | | Request  v
   Request     |    | |link-local address fe80::b   | |  ^     DHCPv6
      ^        |    | |global address 2001:db8:ff::b| |  |     Reply
      |        |    | +-----------------------------+ |  |       |
      |        v    |                                 |  |       v
      |      DHCPv6 |            +--------------------+--+----------+
      |      Reply  |            |        Client C                  |
      |        |    |            | link-local address fe80::cc      |
      |        |    |            | delegated prefix 3fff:0:d:2::/64 |
      |        |    |            +------------+-------------------+-+
      |        v    |                         |                   |
  +---+-------------+----------------------+  |            Router |
  |              Client A                  |  |     Advertisement |
  |    link-local address: fe80::aa        |  |    containing PIO v
  |   delegated prefix: 3fff:0:d:1::/64    |  |    3fff:0:d:2::/64
  | +----------------+ +----------------+  | -+---------+-----------
  | | virtual system | | virtual system |  |            |
  | | 3fff:0:d:1::de | | 3fff:0:d:1::ad |  |     +------+----------+
  | | 3fff:0:d:1::ca | | 3fff:0:d:1::fe |  |     | Tethered device |
  | +----------------+ +----------------+  |     | 3fff:0:d:2::66  |
  |                                        |     +-----------------+
  +----------------------------------------+

Figure 1: An Example Topology with Two First-Hop Routers

5. Applicability and Limitations 🍓

Delegating a unique prefix per client gives you all the perks of both SLAAC and DHCPv6 address allocation, but it costs more address space. ngl that's a real trade-off 😭 This design would seriously benefit some networks (see Section 12), where the extra cost of an additional service (such as DHCPv6 Prefix Delegation) and a bigger chunk of address space can easily be justified. Examples include but aren't limited to:

  • Large-scale networks where even three to five addresses per client might introduce scalability issues. 📈
  • Networks with a high number of virtual hosts, so physical devices require multiple addresses. 💻
  • Managed networks where extensive troubleshooting, device traffic logging, or forensics might be required. 🕵️‍♀️

In smaller networks, like home networks or small enterprises with a smaller address space and fewer clients, SLAAC is a simpler and often preferred option. Keep it easy, bestie 🧚

6. Routing and Addressing Considerations 🌈

6.1. Prefix Pool Allocation 💜

One simple deployment model is to assign a dedicated prefix pool to each link. The prefixes from each link's pool are only issued to requesting clients on that link. If clients move to another link, they'll get a prefix from the pool associated with the new link (see Section 9). 🦋

This is very similar to how address pools work when DHCP assigns individual addresses (e.g., DHCPv4 or DHCPv6 IA_NA), where each link has a dedicated pool of addresses and clients on the link pull addresses from it. In this model, the network can route the entire pool to the link's first-hop routers, and the routers don't need to advertise individual delegated prefixes into the network's dynamic routing protocol. Galaxy brain move 🧠✨

Other deployment models, such as prefix pools shared over multiple links or routers, are possible but aren't described in this document.

6.2. First-Hop Router Requirements 🔥

In large networks, DHCPv6 servers are usually centralized and reached via DHCPv6 relays co-located with the first-hop routers. To delegate IPv6 prefixes to clients, the first-hop routers need to implement DHCPv6 relay functions and meet the requirements defined in [RFC8987]. Specifically, per Section 4.2 of [RFC8987], the first-hop router MUST maintain a local routing table that contains all prefixes delegated to clients. That's the main character requirement 👑

With the first-hop routers doing DHCPv6 relay functions, the proposed design neither requires any subsequent relays in the path nor introduces any requirements (e.g., snooping) for those subsequent relays, if they're deployed. Nice and chill 🫶

To make sure routes to the delegated prefixes survive even if a relay is rebooted or replaced, the operator MUST ensure that all relays in the network infrastructure support DHCPv6 Bulk Leasequery as defined in [RFC5460]. Section 4.3 of [RFC8987] lists keeping active prefix delegations in persistent storage as an alternative to DHCPv6 Bulk Leasequery, but relying on persistent storage has these drawbacks 💀

  • In a network with multiple relays, network state can change significantly while the relay is rebooting (new prefixes might be delegated, or some prefixes might be expiring, etc.). ⏳
  • Persistent storage might not be preserved if the router is physically replaced. 📦

Another mechanism for first-hop routers to learn about delegated prefixes is Active Leasequery [RFC7653], though it's not yet widely supported. Not there yet, but we'll see 👀

6.3. Topologies with Multiple First-Hop Routers 🦋

In a topology with redundant first-hop routers, all the routers need to relay DHCPv6 traffic, install the delegated prefixes into their routing tables and, if needed, advertise those prefixes to the network. Redundancy checks out 💖

If the first-hop routers learn about delegated prefixes by snooping DHCPv6 Reply messages sent by the server, then all the first-hop routers must be able to snoop those messages. This works if the client multicasts the DHCPv6 messages it sends to the server. The server receives one copy of the client message through each first-hop relay and replies unicast to each of them, via the relay (or chain of relays) it got the message from. So every first-hop relay gets to snoop the replies. 👯‍♀️

Per Section 14 of [RFC8415], clients always use multicast unless the server uses the Server Unicast option to explicitly allow unicast communication ([RFC8415], Section 21.12). So in topologies with multiple first-hop routers, the DHCPv6 servers MUST be configured not to use the Server Unicast option. It should be noted that [RFC8415bis] deprecates the Server Unicast option precisely because it isn't compatible with topologies with multiple first-hop relays. Plot twist, it's deprecated for a reason 🙃

To recover from crashes or reboots, relays can use Bulk Leasequery or Active Leasequery to issue a QUERY_BY_RELAY_ID with the ID(s) of the other relay(s), as configured by the operator. Some vendors also offer vendor-specific mechanisms to sync state between DHCP relays, so check your gear 🔄

For security reasons, some networks block on-link device-to-device traffic at Layer 2 to stop clients on the same link from talking to each other. In that case, delegating a prefix to each client doesn't change traffic flows, since all traffic goes to the first-hop router anyway. Depending on the network security policy, the router may allow or drop the traffic. 🔒

If the network does allow peer-to-peer communication, the PIO for the on-link prefix is usually advertised with the L-bit set to 1 [RFC4861]. As a result, all addresses from that prefix count as on-link, and traffic to those destinations is sent directly (not via routers). If such a network delegates prefixes to clients (as described in this document), then each client will consider other client's destination addresses to be off-link, because those addresses come from the delegated prefixes and are no longer within the on-link prefix. 😵‍💫

When a client sends traffic to another client, packets are initially sent to the default router. The router responds with an ICMPv6 redirect message (Section 4.5 of [RFC4861]). If the client receives and accepts the redirect, traffic can then flow directly from device to device. Therefore, the administrator deploying the solution described in this document SHOULD ensure that the first-hop routers can send ICMPv6 redirects (the routers are configured to do so and the security policies permit those messages). Make sure the redirects can actually go out, or the whole vibe is off 🍓

7. DHCPv6-PD Server Considerations ✨

Okay so bestie, good news first: this document doesn't change DHCPv6 itself 💅 🎀 But for the whole solution to actually work, the DHCPv6-PD server has to be set up just right 🧚

  • The server MUST follow recommendations from [RFC8168] on processing prefix-length hints. 🌸
  • The server MUST provide a prefix short enough for the client to extend the network to at least one interface and allow nodes on that interface to obtain addresses via SLAAC. The server MAY provide more address space to clients that ask for it, either by delegating multiple such prefixes, or by delegating a single prefix of a shorter length. It should be noted that [RFC8168] allows the server to provide a prefix shorter than the prefix-length hint value received from the client. 💖
  • If the server receives the same Solicit message from the same client multiple times through multiple relays, it MUST reply to all of them with the same prefix(es). This ensures that all the relays will correctly configure routes to the delegated prefixes. 🦋
  • The server MUST NOT send the Server Unicast option to the client unless the network topology guarantees that no client is connected to a link with multiple relays (see Section 6.3). 🙈
  • In order to ensure uninterrupted connectivity when a first-hop router crashes or reboots, the server MUST support Bulk Leasequery or Active Leasequery. 👑

As most operators have some experience with IPv4, they can use a similar approach for choosing the pool size and the timers (such as T1 and T2 timers). Lowkey this is the familiar part 🫶 The following factors should be taken into account:

  • the expected maximum number of clients;
  • the average duration of client connections;
  • how mobile the clients are (a network where all clients are connected to a single wired VLAN might choose longer timers than a network where clients can switch between multiple wireless networks);
  • how often clients are expected to reconnect to the network (for example, a corporate authenticated Wi-Fi network might be using longer timers than an open public Wi-Fi). ✨

DHCPv6 servers that delegate prefixes can interface with Dynamic DNS infrastructure to automatically populate reverse DNS using wildcard records, similarly to what is described in Section 2.2 of [RFC8501]. Networks that also wish to populate forward DNS cannot do so automatically based only on DHCPv6 prefix delegation transactions, but they can do so in other ways, such as by supporting DHCPv6 address registration as described in [ADDR-NOTIFICATION]. 🌈

Some additional recommendations driven by security and privacy considerations are discussed in Section 15 and Section 13. 🔥

8. Prefix Length Considerations 🍓

Delegating a prefix of sufficient size to use SLAAC lets the client extend the network, giving limitless addresses to IPv6 nodes connected to it (e.g., virtual machines or tethered devices). That's because all IPv6 hosts are required to support SLAAC [RFC8504]. Even clients that support other forms of address assignment still need SLAAC for some functions, such as forming dedicated addresses for the use of 464XLAT (see Section 6.3 of [RFC6877]). Main character energy for SLAAC, no cap 💅

At the time of writing, the only prefix size that will allow devices to use SLAAC is 64 bits. Also, as noted in [RFC7421], using an interface identifier (IID) shorter than 64 bits and a subnet prefix longer than 64 bits is outside the current IPv6 specifications. Choosing longer prefixes would require the client and any connected system to use other address assignment mechanisms. That would limit the applicability of the proposed solution, since many hosts don't support other mechanisms yet 🥺

For the same reasons, a prefix length of /64 or shorter is required to extend the network as described in [RFC7084] (see requirement L-2), and a prefix length of /64 is required to provide global connectivity for stub networks as per [SNAC-SIMPLE]. 🎀

Assigning a prefix of sufficient size to support SLAAC is possible on large networks. In general, any network that numbers clients from an IPv4 prefix of length X (e.g., X=/18, X=/24) would require an IPv6 prefix of length X+32 (e.g., X=/40, X=/56) to provide a /64 prefix to every device. As an example, Section 9.2 of [RFC7934] suggests that even a very large network that assigns every single one of the 16 million IPv4 addresses in 10.0.0.0/8 would only need an IPv6 /40. A /40 prefix is a small amount of address space: there are 32 times more /40s in the current IPv6 unicast range 2000::/3 than there are IPv4 addresses. Existing sites that currently use a /48 prefix cannot support more than 64k clients in this model without renumbering, though many networks of such size have Local Internet Registry (LIR) status and can justify bigger address blocks. 🌸

Note that assigning a prefix of sufficient size to support SLAAC does not require that subtended nodes use SLAAC. They can use other address assignment mechanisms as well. 🧚

9. Client Mobility 🦋

As per Section 18.2.12 of [RFC8415], when the client moves to a new link, it MUST initiate a Rebind/Reply message exchange. So when the client moves between network attachment points, it refreshes its delegated prefix the same way it refreshes addresses assigned (via SLAAC or DHCPv6 IA_NA) from a shared on-link prefix. Bestie, it's giving consistency 💖

  • When a client moves between different attachment points on the same link (e.g., roams between two APs while connected to the same wireless network or moves between two switchports belonging to the same VLAN), the delegated prefix does not change, and the first-hop routers have a route for the prefix with the nexthop set to the client link-local address on that link. As per requirement S-2 in Section 4.3 of [RFC8987], the DHCPv6-relays (the first-hop routers) MUST retain the route for the delegating prefix until the route is released or removed due to expiring DHCP timers. Therefore, if the client reconnects to the same link, the prefix doesn't change. ✨
  • When a client moves to a different link, the DHCPv6 server provides the client with a new prefix, so the behavior is consistent with SLAAC or DHCPv6-assigned addresses, which are also different on the new link. 🌈

In theory, DHCPv6 servers can delegate the same prefix to the same client even if the client changes attachment points. However, while keeping the same prefix while roaming between links might give the client some benefits, it is not feasible without changing DHCPv6 relay behavior. After the client moves to a new link, the DHCPv6 relays would retain the route pointing to the client's link-local address on the old link for the duration of DHCPv6 timers (see requirement S-2, Section 4.3 of [RFC8987]). As a result, the first-hop routers would have two routes for the same prefix pointing to different links, causing connectivity issues for the client. Not me having two routes fighting over one prefix 💀

It should be noted that addressing clients from a shared on-link prefix also does not let clients keep addresses while roaming between links, so the proposed solution is not different in that regard. On top of that, different links often have different security policies applied (for example, corporate internal networks versus guest networks), so clients on different links need to use different prefixes. 🔥

10. Antispoofing and SAVI Interaction 🛡️

Enabling unicast Reverse Path Forwarding (uRPF) [RFC3704] on the first-hop router interfaces towards clients provides the first layer of defense against spoofing. A spoofed packet sent by a malicious client would be dropped by the router unless the spoofed address belongs to a prefix delegated to another client on the same interface. So the malicious client can only spoof addresses already delegated to another client on the same link, or another client's link-local address. Tiny window, iykyk 👑

Source Address Validation Improvement (SAVI) [RFC7039] provides more reliable protection against address spoofing. Administrators deploying the proposed solution on SAVI-enabled infrastructure SHOULD ensure that SAVI perimeter devices support DHCPv6-PD snooping to create the correct binding for the delegated prefixes (see [RFC7513]). Using FCFS SAVI [RFC6620] to protect link-local addresses and create SAVI bindings for DHCPv6-PD assigned prefixes would prevent spoofing. ✨

Some infrastructure devices do not implement SAVI as defined in [RFC7039]. Instead, they perform other forms of address tracking and snooping for security or performance improvement purposes (e.g., ND proxy). This is very common behavior for wireless devices (such as access points and controllers). Administrators SHOULD ensure that such devices are able to snoop DHCPv6-PD packets so the traffic from the delegated prefixes is not dropped. 🫶

It should be noted that using DHCPv6-PD makes it harder for an attacker to select the spoofed source address. When all clients are using the same shared link to form addresses, the attacker might learn addresses used by other clients by listening to multicast Neighbor Solicitations and Neighbor Advertisements. In DHCPv6-PD environments, however, the attacker can only learn about other clients' global addresses by listening to multicast DHCPv6 messages. Those aren't sent very often, and the client may not even receive them, because they go to multicast groups specific to DHCPv6 servers and relays. Honestly a huge win for privacy 🦋🌈

11. Migration Strategies and Co-existence with SLAAC Using Prefixes from the PIO ✨

Okay so bestie, this is where we talk about how networks can literally make the switch without breaking everyone's stuff 🦋. It would be super beneficial for the network to explicitly say "hey, I support DHCPv6-PD for connected clients" 💅.

11.1. Why Clients Need to Know 🎀

  • In small networks (like home networks), the number of clients isn't very high, but the number of available prefixes becomes a limiting factor 🏠. If every phone or laptop in a home network requested its own unique prefix for SLAAC, the home network might run out of prefixes if the prefix the CPE got from its ISP is too long 💀. For example, if an ISP delegates a /60, the CPE can only delegate fifteen /64 prefixes to clients. So while the enterprise admin might want all phones to request a prefix, it would be highly undesirable for the same phone to do that when it connects to a home network 🙈.
  • When the network supports both a unique prefix per client AND a PIO with A=1 as address assignment methods, it's highly desirable for the client NOT to use the PIO prefix to form global addresses 🫶. Instead, it should only use the prefix delegated via DHCPv6-PD ✨. Starting both SLAAC (using the PIO prefix) and DHCPv6-PD, and then deprecating the SLAAC addresses after getting a delegated prefix, would be very disruptive for apps 😭. If the client kept using addresses formed from the PIO prefix, it would not only undermine the benefits of the proposed solution (see Section 12), it would also add complexity and unpredictability to source address selection 🌀. So the client needs to know which address assignment method to use, and whether or not to use the prefix in the PIO, if the network provides the PIO with the 'A' flag set 👑.
  • The deployment model in this document does NOT require the network to signal support of DHCPv6-PD 🌸. For example, devices acting as compatible routers [RFC7084] will still be able to receive prefixes via DHCPv6-PD even without that signal. Also, some clients may decide to start DHCPv6-PD and acquire prefixes if they detect that the network isn't providing addresses via SLAAC 🧚. To fully get the benefits described in this section, [PIO-PFLAG] defines a new PIO flag that signals DHCPv6-PD is the preferred method for getting prefixes 💜.

12. Benefits 🌈

The proposed solution gives you the following perks 👑:

  • Network device resources (e.g., memory) need to scale to the number of devices, NOT the number of IPv6 addresses 🧠. The first-hop routers have a single route per device pointing to the device's link-local address. This can potentially save hardware costs! For example, if hardware like wireless LAN controllers can only support a specific number of client addresses, or in VXLAN deployments where each client address eats one routing table entry, this is a big win 💖.
  • The cost of having multiple addresses is offloaded to the clients 🎁. Hosts are free to create and use as many addresses as they need, without adding any extra costs onto the network 🦋.
  • If all clients on the link support this mode of operation and can generate addresses from the delegated prefixes, there's no reason to advertise a common prefix for that link in the PIO with the 'A' flag set 🙌. So it's possible to remove the global shared prefix from that link AND the router interface completely, meaning no global addresses are on-link for the link at all 🫧. This reduces the attack surface for Neighbor Discovery attacks described in [RFC6583] 🛡️.
  • DHCPv6-PD logs and routing tables from first-hop routers give you complete IPv6-to-MAC mapping info, which is iconic for forensics and troubleshooting 🔍. This info is way less dynamic than the ND cache, so it's much easier for an operator to collect and process 📋.
  • A dedicated prefix per client lets the network admin create security policies per device (like ACLs), even if the client is using temporary addresses 🔐. This helps mitigate one of the issues described in [IPv6-ADDRESS] 💅.
  • Fate sharing: all global addresses used by a given client are routed as a single prefix 🧦. Either they ALL work or NONE of them work, which makes failures easier to diagnose and fix 🩹.
  • Lower level of multicast traffic: fewer Neighbor Discovery [RFC4861] multicast packets, since routers only need to resolve the clients' link-local addresses 📉. Also, there's no Duplicate Address Detection (DAD) traffic except for the clients' link-local addresses 🌷.
  • Ability to extend the network transparently 🌐. If the network delegates a prefix of sufficient size to support SLAAC, the client can provide connectivity to other hosts, kind of like IPv4 NAT (e.g., by acting as an IPv6 Customer Edge (CE) router as described in [RFC7084]) 🎀.

13. Privacy Considerations 🕵️‍♀️

Okay this part is important bestie 😤. If an eavesdropper or information collector knows that a given client is using the proposed mechanism, they may be able to track the client based on its prefix 👀. The privacy implications of this are equivalent to the privacy implications of networks using stateful DHCPv6 address assignment 🫠. In both cases the IPv6 addresses are determined by the server, either because the server assigns a full 128-bit address in a shared prefix, or because the server decides which prefix is delegated to the client 📦. Admins deploying the proposed mechanism can use similar methods to reduce the impact as the ones used today in networks that use stateful DHCPv6 address assignment 🔒.

Except for networks (such as datacenter networks) where hosts do not need temporary addresses [RFC8981], the network SHOULD do the following 💫:

  • Ensure that when a client requests a prefix, the prefix is randomly assigned and NOT allocated deterministically 🎲.
  • Use short prefix lifetimes (e.g., hours) so that when a client disconnects and reconnects, it gets a different prefix 🔄.
  • Allow the client to have more than one prefix at the same time 🫧. This lets the client rotate prefixes using a mechanism similar to temporary addresses, but operating on prefixes instead of individual addresses 🦋. In this case, the prefix's lifetime MUST be short enough to let the client use a reasonable rotation interval without using too much address space ⏳. For example, if every 24 hours the client asks for a new prefix and stops renewing the old one, and the Valid Lifetime of delegated prefixes is one hour, then the client will consume two prefixes for one hour out of every 24 hours. That means it will consume just under 1.05 prefixes on average 🧮.

14. IANA Considerations 📚

This document has no IANA actions 🌸.

15. Security Considerations 🚨

Okay this section is SERIOUS, bestie 😭.

A malicious (or just misbehaving) client might try to exhaust the DHCPv6-PD pool by sending a huge number of requests with differing DHCP Unique Identifiers (DUIDs) 💀. To stop a misbehaving client from denying service to other clients, the DHCPv6 server or relay MUST support limiting the number of prefixes delegated to a given client at any given time 🛑.

Networks can protect against malicious clients by authenticating devices using tokens that can't be spoofed (e.g., 802.1x authentication) and by limiting the number of link-local addresses or MAC addresses each client is allowed to use 🔐. Note that this isn't a new issue, since the same attack could be done using DHCPv4 or DHCPv6 IA_NA requests. In particular, while it's unlikely for clients to exhaust an IA_NA address pool, clients using IA_NA can exhaust other resources, like DHCPv6 and routing infrastructure resources such as server RAM, ND cache entries, Ternary Content-Addressable Memory (TCAM) entries, SAVI entries, etc. 🫠

A malicious client might request a prefix and then release it very quickly, causing routing convergence events on the relays 🌪️. The impact of this attack can be reduced if the network rate-limits the amount of broadcast and multicast messages from the client 🚦.

Delegating the same prefix to the same client introduces privacy concerns 🙈. The proposed mitigation is discussed in Section 13 💜.

Spoofing scenarios and prevention mechanisms are discussed in Section 10 🦋.

16. References 📖

16.1. Normative References 💌

16.2. Informative References ✨

okay bestie, these are the extra reads 📚 not required to implement anything, but they're the ones that explain the why behind the whole vibe 🧠💅

[ADDR-NOTIFICATION] Kumari, W., Krishnan, S., Asati, R., Colitti, L., Linkova, J., and S. Jiang, "Registering Self-generated IPv6 Addresses using DHCPv6", Work in Progress, Internet-Draft, draft-ietf-dhc-addr-notification-13, 16 May 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-dhc-addr-notification-13>.

[IPv6-ADDRESS] Gont, F. and G. Gont, "Implications of IPv6 Addressing on Security Operations", Work in Progress, Internet-Draft, draft-ietf-opsec-ipv6-addressing-00, 2 June 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-addressing-00>.

[PIO-PFLAG] Colitti, L., Linkova, J., Ma, X., and D. Lamparter, "Signaling DHCPv6 Prefix per Client Availability to Hosts", Work in Progress, Internet-Draft, draft-ietf-6man-pio-pflag-11, 4 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-6man-pio-pflag-11>.

[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <https://www.rfc-editor.org/info/rfc3704>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.

[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, January 2012, <https://www.rfc-editor.org/info/rfc6459>.

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

[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013, <https://www.rfc-editor.org/info/rfc7039>.

[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, DOI 10.17487/RFC7278, June 2014, <https://www.rfc-editor.org/info/rfc7278>.

[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.

[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/RFC7421, January 2015, <https://www.rfc-editor.org/info/rfc7421>.

[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, May 2015, <https://www.rfc-editor.org/info/rfc7513>.

[RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, October 2015, <https://www.rfc-editor.org/info/rfc7653>.

[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, July 2016, <https://www.rfc-editor.org/info/rfc7934>.

[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8415bis] Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in Progress, Internet-Draft, draft-ietf-dhc-rfc8415bis-05, 8 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-dhc-rfc8415bis-05>.

[RFC8501] Howard, L., "Reverse DNS in IPv6 for Internet Service Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018, <https://www.rfc-editor.org/info/rfc8501>.

[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, <https://www.rfc-editor.org/info/rfc8504>.

[SNAC-SIMPLE] Lemon, T. and J. Hui, "Automatically Connecting Stub Networks to Unmanaged Infrastructure", Work in Progress, Internet-Draft, draft-ietf-snac-simple-05, 8 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-snac-simple-05>.

Appendix A. Multiple Addresses Considerations 🦋

okay so while a typical IPv4 host usually has just one IPv4 address per interface, an IPv6 device almost always has a whole squad of addresses on its interface 🫶 at the very least, a host can be expected to have one link-local address, one temporary address, and, in most cases, one stable global address 🌸 on a network providing NAT64 service, an IPv6-only host running the 464XLAT customer-side translator (CLAT) [RFC6877] would use a dedicated 464XLAT address, configured via SLAAC (see Section 6.3 of [RFC6877]), which brings the total number of addresses to four 🔥 other common scenarios where the number of addresses per host interface might increase significantly include but are not limited to:

  • Devices running containers or namespaces: each container or namespace would have multiple addresses as described above. As a result, a device running just a few containers in a bridge mode can easily have 20 or more IPv6 addresses on the given link 🐳✨
  • Networks assigning multiple prefixes to a given link: multihomed networks, networks using Unique Local IPv6 Unicast Addresses (ULA, [RFC4193]) and non-ULA prefixes together, or networks performing a graceful renumbering from one prefix to another 🌈

[RFC7934] discusses this aspect and explicitly states that IPv6 deployments SHOULD NOT limit the number of IPv6 addresses a host can have 💅 however, it has been observed that networks often do limit the number of on-link addresses per device, likely in an attempt to protect network resources and prevent DoS attacks 🙈

The most common scenario of network-imposed limitations is ND proxy 👀 many enterprise-scale wireless solutions implement ND proxy to reduce the amount of broadcast and multicast downstream (AP to clients) traffic and provide SAVI functions 📡 to perform ND proxy, a device usually maintains a table containing IPv6 and MAC addresses of connected clients 🗂️ at least some implementations have hardcoded limits on how many IPv6 addresses per single MAC such a table can contain 😭 when the limit is exceeded, the behavior is implementation dependent. Some vendors just fail to install an N+1 address to the table. Others delete the oldest entry for this MAC and replace it with the new address. In any case, the affected addresses lose network connectivity without receiving any implicit signal, with traffic being silently dropped 💀 literally the worst kind of ghosting, periodt.

Acknowledgements 💜

Thanks to Harald Alvestrand, Nick Buraglio, Brian Carpenter, Tim Chown, Roman Danyliw, Gert Doering, David Farmer, Fernando Gont, Joel Halpern, Nick Hilliard, Bob Hinden, Martin Hunek, Erik Kline, Warren Kumari, David Lamparter, Andrew McGregor, Tomek Mrugalski, Alexandre Petrescu, Jurgen Schonwalder, Pascal Thubert, Ole Troan, Eric Vyncke, Eduard Vasilenko, Timothy Winters, Chongfeng Xie, and Peter Yee for the discussions, their input, and all contributions 🫶🎀 this whole doc is a group project and y'all are iconic 👑

Authors' Addresses 🧚

Lorenzo Colitti Google, LLC Shibuya 3-21-3, Japan Email: lorenzo@google.com

Jen Linkova (editor) Google 1 Darling Island Rd Pyrmont New South Wales 2009 Australia Email: furry13@gmail.com, furry@google.com

Xiao Ma (editor) Google Shibuya 3-21-3, Japan Email: xiaom@google.com

📦 where this page comes from