RFC 9762

Using Router Advertisements to Signal the Availability of DHCPv6 Prefix Delegation to Clients

📅 published June 2025, from ietf

RFC 9762: Using Router Advertisements to Signal the Availability of DHCPv6 Prefix Delegation to Clients ✨

Okay bestie, this one is from the IETF (Internet Engineering Task Force) 🌸 and it's a Standards Track doc, so it's a real spec people build against 💅. It came out in June 2025 (ISSN 2070-1721) and it's the official RFC number 9762 🎀. The authors are L. Colitti, J. Linkova, and X. Ma (Ed.), who is at Google, plus D. Lamparter, who is at NetDEF, Inc. 🧚 It updates RFC 4861 and RFC 4862, which means it tweaks how those two older rulebooks work.

Abstract

okay so this doc defines the P flag in the Prefix Information Option (PIO) of IPv6 Router Advertisements (RAs) 🦋. The point of the flag is to tell clients that the network would really like them to use the deployment model in [RFC9663], instead of grabbing individual addresses from the on-link prefix through Stateless Address Autoconfiguration (SLAAC) or DHCPv6 address assignment 💖.

It also updates [RFC4862] so that the Autonomous flag in a PIO gets ignored whenever the PIO has the P flag set 🙈. And it updates [RFC4861] to say that the P flag means the router supports DHCPv6 prefix delegation for clients ✨.

Status of This Memo

this is an Internet Standards Track document 🔥.

It comes from the IETF, and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🌈.

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9762 💜.

Copyright (c) 2025 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 they stand on the date this document was published. Please read those carefully, because they spell out your rights and restrictions for this document 📜. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Revised BSD License 🫶.

Table of Contents

   1.  Introduction
   2.  Requirements Language
   3.  Terminology
   4.  Rationale
   5.  P Flag Overview
   6.  Router Behavior
   7.  Client Behavior
     7.1.  Processing the P Flag
     7.2.  Using Delegated Prefix(es)
     7.3.  Absence of PIOs with the P Bit Set
     7.4.  On-Link Communication
     7.5.  Source Address Selection
   8.  Multihoming
   9.  Modifications to RFC-Mandated Behavior
     9.1.  Changes to RFC 4861
     9.2.  Changes to RFC 4862
   10. Security Considerations
   11. Privacy Considerations
   12. IANA Considerations
   13. References
     13.1.  Normative References
     13.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

[RFC9663] describes an IPv6 address assignment model where IPv6 devices get their own dedicated prefixes from the network through DHCPv6 prefix delegation (DHCPv6-PD) [RFC8415] 🦋. This is giving devices a huge IPv6 address space to make addresses for communication, to individually number virtual machines (VMs) or containers, or to extend the network out to downstream devices 💅. It's also great for scalability on big networks, since the infrastructure devices don't have to keep per-address state, like IPv6 neighbor cache, Source Address Validation Improvement (SAVI) [RFC7039] mappings, Virtual eXtensible Local Area Network (VXLAN) [RFC7348] routes, and so on 🌸.

BUT, on networks with fewer devices, this model might not be the right fit 🙈. Scaling to multiple individual IPv6 addresses per device just isn't as big a deal there. Also, lots of home networks offer prefix delegation but assume only a few specialized devices and/or applications will need delegated prefixes. So they don't allocate enough address space to give a prefix to every device that connects 😭. For example, say clients assume the [RFC9663] deployment model on a home network that only gets a /60 from the ISP, and each client takes a /64 prefix. Then the network runs out of prefixes after 15 devices have connected 💀.

So, to safely roll out support for the [RFC9663] deployment model on the client side, the network needs a way to signal to the client which address assignment method it prefers 🎀.

2. Requirements Language 📜

okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are the BCP 14 words in this document 💜. They get interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when, and only when, they show up in all capitals, exactly like shown here 🧚.

3. Terminology 🌈

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 might want addresses for its own use, or it might be a router that wants to extend the network to its physical or virtual subsystems, or both. It can be either a host or a router, as defined by [RFC8200] 💖.

DHCPv6-PD: DHCPv6 Prefix Delegation [RFC8415]. It's a mechanism for delegating IPv6 prefixes to clients 🎀.

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]) 🫶

ND: Neighbor Discovery [RFC4861] 🌸

On-link address: an address assigned to an interface on a specified link [RFC4861] 🦋

On-link prefix: a prefix assigned to a specified link 💅

Off-link: the opposite of "on-link" (see [RFC4861]) 🙈

PIO: Prefix Information Option [RFC4862] 🔥

RA: Router Advertisement [RFC4861] 👑

SLAAC: Stateless Address Autoconfiguration [RFC4862] 🍓

4. Rationale 💜

so the network admin might want to tell clients that asking for a prefix through DHCPv6-PD, and then using that prefix for address assignment (see [RFC9663]), is the better move. That's preferred over using individual addresses from the on-link prefix ✨. The info gets passed to the client through a P flag in the PIO. Here's why it's a PIO flag 🎀:

  • The info has to be in the RA, because the client needs it before it decides to form IPv6 addresses from the PIO prefix using SLAAC 😭. Otherwise, the client could use SLAAC to make addresses from the PIO and start using them, even when a unique per-client prefix is available via DHCPv6-PD. Forming addresses via SLAAC is suboptimal, because if the client later gets a prefix through DHCPv6-PD, it can either 1) use both the prefix and the SLAAC addresses, which cuts down on the scalability benefits of DHCPv6-PD, or 2) remove the SLAAC addresses, which would be disruptive for applications using them 💀.
  • The info is specific to the particular prefix being announced. For example, a network admin might want clients to assign global addresses from delegated prefixes, but form Unique Local IPv6 Unicast Addresses [RFC4193] from another PIO in the RA using SLAAC 🌈. Also, in a multihoming situation, one upstream network might choose to hand out prefixes via prefix delegation and another via PIOs 🦋.

Just so you know, setting the P flag in a PIO means the network operator prefers that clients try DHCPv6-PD instead of doing individual address configuration on that prefix 💖. For clients that honor this preference by requesting prefix delegation, the delegated prefix will necessarily be a different prefix from the one in the PIO 🧚.

5. P Flag Overview 🌸

The P flag (also called the DHCPv6-PD Preferred Flag) is a 1-bit PIO flag, and it sits after the R flag [RFC6275] 🎀. If a PIO has the P flag set, it means the network prefers that clients use prefix delegation instead of getting individual addresses through SLAAC or DHCPv6 address assignment 💅. That also implies the network has a DHCPv6 server that can make DHCPv6 prefix delegations to every device on the network, as described in [RFC9663] 👑.

Here's what the resulting PIO format looks like, in Figure 1 ✨:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |    Length     | Prefix Length |L|A|R|P| Rsvd1 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Valid Lifetime                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Preferred Lifetime                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           Reserved2                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                                                               +
  |                                                               |
  +                            Prefix                             +
  |                                                               |
  +                                                               +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1

The P flag doesn't depend on the M and O flags in the RA 🦋. But if the network wants to delegate prefixes to devices that support DHCPv6 prefix delegation and don't support the P flag, it SHOULD also set the M or O bits in the RA to 1 💖. That's because some devices, like Customer Edge (CE) routers [RFC7084], might not start DHCPv6 prefix delegation if both the M and O bits are set to zero 😭.

6. Router Behavior 👑

Routers SHOULD set the P flag to zero by default, unless the administrator explicitly configures it 🎀. They SHOULD also let the operator set the P flag value for any given prefix advertised in a PIO ✨. Routers MUST allow the P flag to be configured separately from the A flag 🫶. Specifically, turning the P flag on or off MUST NOT trigger automatic changes to the A flag value that the router sets 🔥.

7. Client Behavior 🌸

7.1. Processing the P Flag 🎀

okay so this whole spec is only for clients that actually do DHCPv6 prefix delegation (DHCPv6-PD) 💅. Clients that don't support DHCPv6-PD MUST ignore the P flag, no exceptions bestie 🙈. The P flag means nothing for link-local prefixes, so any PIO containing the link-local prefix MUST be ignored, just like Section 5.5.3 of [RFC4862] says ✨. Everything below assumes the prefixes are not link-local, so we're all on the same page 🦋.

For each interface, the client MUST keep a list of every prefix that came in from a PIO with the P flag set and that currently has a non-zero preferred lifetime 📝. This list controls a few behaviors:

  • When a prefix's preferred lifetime hits zero, either because it expired or because the client got a PIO for that prefix with a zero preferred lifetime, the prefix MUST be removed from the list 💀.
  • When the list grows to one entry, the client SHOULD start requesting prefixes via DHCPv6 prefix delegation, unless it's already doing that 🚀.
  • When the list shrinks back to zero, the client SHOULD stop requesting or renewing prefixes via DHCPv6 prefix delegation if it has no other reason to keep going 🛑. Any prefixes it already got through DHCPv6 keep their lifetimes, no changes there 🫶.
  • If the client has already received delegated prefix(es) from one or more servers, then every time prefix(es) get added to or removed from the list, the client MUST consider this to be a change in configuration information, as described in Section 18.2.12 of [RFC8415]. In that case, the client MUST perform a REBIND, unless the list is now empty. This is on top of the REBINDs it does in the other cases that section requires. A REBIND lets the client grab new prefixes when it needs them, like when the network is being renumbered 🌈, and it refreshes the state for the delegated prefix(es) too ✨.

When a client requests a prefix via DHCPv6-PD, it MUST use the prefix length hint (Section 18.2.4 of [RFC8415]) to ask for a prefix that's short enough to form addresses via SLAAC 🍓.

To get the scalability perks of DHCPv6-PD, the client SHOULD prefer forming addresses from the delegated prefix instead of using individual addresses in the on-link prefix(es) 🧚. So when the client requests a prefix using DHCPv6-PD, it SHOULD NOT use SLAAC to get IPv6 addresses from PIOs with the P and A bits set 🙅. Similarly, if all PIOs the client processes have the P bit set, it SHOULD NOT request individual IPv6 addresses from DHCPv6, i.e., it SHOULD NOT include any IA_NA options in Solicit messages [RFC8415] 💜. The client MAY continue to use addresses that are already configured 👑.

If the client doesn't get any prefixes via DHCPv6-PD that work for SLAAC, it MAY choose to disable further processing of the P flag on that interface 🥺. That lets it fall back to other address assignment mechanisms, like forming addresses via SLAAC (if the PIO has the A flag set to 1) and/or requesting individual addresses via DHCPv6 💅.

7.2. Using Delegated Prefix(es) 🌸

If the delegated prefix is too long for SLAAC, the client MUST ignore it, because Section 7 of [RFC9663] requires the network to provide a SLAAC-suitable prefix to clients 🙅‍♀️. If the prefix is shorter than SLAAC needs, the client SHOULD accept it, allocate one or more longer prefixes that work for SLAAC, and use those as described below ✨.

For every accepted prefix:

  • The client MAY form as many IPv6 addresses from the prefix as it chooses 🦋.
  • The client MAY use the prefix to provide IPv6 addresses to internal components like VMs or containers 🐳.
  • The client MAY use the prefix to let devices directly connected to it get IPv6 addresses. For example, the client MAY route traffic for that prefix to an interface and send an RA containing a PIO for the prefix on that interface. That interface MUST NOT be the interface the prefix is obtained from. If the client advertises the prefix on an interface and it has formed addresses from the prefix, then it MUST act as though the addresses were assigned to that interface for the purposes of Neighbor Discovery and Duplicate Address Detection 🧠.

The client MUST NOT send or forward packets with destination addresses within a delegated prefix to the interface it got the prefix on, since that can cause a routing loop 🔁🚫. This problem won't happen if the client has assigned the prefix to another interface 🫶. Another way the client can dodge it is to add a high-metric discard route for the delegated prefix to its routing table 🗑️.

7.3. Absence of PIOs with the P Bit Set 🫥

The P bit is purely a positive signal 💖. It says DHCPv6 prefix delegation is available and the network prefers that nodes use it, even if they have no other reason to run a prefix delegation client. The absence of any PIOs with the P bit doesn't signal the opposite, and it MUST NOT be processed to mean DHCPv6-PD is absent 🙅. Specifically, nodes that run DHCPv6-PD because of explicit configuration or by default (e.g., to extend the network) MUST NOT disable DHCPv6-PD just because no PIOs have the P bit set 🙃. A super common example of this is CE routers, as described in [RFC7084] 🏠.

When the network delegates unique prefixes to clients, each client will consider other clients' destination addresses to be off-link. That's because those addresses come from the delegated prefixes and aren't inside any on-link prefix 🧭. When a client sends traffic to another client, the packets go to the default router first 🚏. The router may respond with an ICMPv6 redirect message (Section 4.5 of [RFC4861]). If the client receives and accepts the redirect, traffic can flow directly device to device 🏃‍♀️💨. So hosts supporting the P flag SHOULD process redirects unless they're configured otherwise 💅. Hosts that don't process ICMPv6 redirects, and routers that don't act on them, may experience higher latency while talking to prefixes delegated to other clients on the same link 🐢.

7.5. Source Address Selection 🎯

For the purpose of source address selection [RFC6724], if the host creates any addresses from a delegated prefix, it SHOULD treat those addresses as if they were assigned to the interface the prefix was received on 🧩. This includes putting them in the candidate set and associating them with the outgoing interface when implementing Rule 5 of the source address selection algorithm [RFC6724] 💅.

8. Multihoming 🏠

In multi-prefix multihoming, the host generally needs to associate the prefix with the router that advertised it (for example, see Rule 5.5 in [RFC6724]) 👑. If the host supports Rule 5.5, then it SHOULD associate each prefix with the link-local address of the DHCPv6 server or relay that it got the REPLY packet from 🫶. When it receives multiple REPLYs carrying the same prefix from distinct link-local addresses, it SHOULD associate that prefix with all of these addresses 💜. This can commonly happen in networks with redundant routers and DHCPv6 servers or relays 🌈.

9. Modifications to RFC-Mandated Behavior 🛠️

9.1. Changes to RFC 4861

This document makes the following changes to Section 4.2 of [RFC4861]:

OLD TEXT:

|  Note: If neither M nor O flags are set, this indicates that no
|  information is available via DHCPv6.

NEW TEXT:

|  Note: If the M, O, or P (RFC 9762) flags are not set, this
|  indicates that no information is available via DHCPv6.

9.2. Changes to RFC 4862

This document makes the following changes to Section 5.5.3 of [RFC4862]:

OLD TEXT:

|  For each Prefix-Information option in the Router Advertisement:
|
|  a)  If the Autonomous flag is not set, silently ignore the Prefix
|      Information option.
|
|  b)  If the prefix is the link-local prefix, silently ignore the
|      Prefix Information option.
|
|  c)  If the preferred lifetime is greater than the valid lifetime,
|      silently ignore the Prefix Information option.  A node MAY
|      wish to log a system management error in this case.
|
|  d)  If the prefix advertised is not equal to the prefix of an
|      address configured by stateless autoconfiguration already in
|      the list of addresses associated with the interface (where
|      "equal" means the two prefix lengths are the same and the
|      first prefix-length bits of the prefixes are identical), and
|      if the Valid Lifetime is not 0, form an address (and add it to
|      the list) by combining the advertised prefix with an interface
|      identifier of the link as follows:

NEW TEXT:

|  For each Prefix Information Option in the Router Advertisement:
|
|  a)  If the prefix is the link-local prefix, silently ignore the
|      Prefix Information Option.
|
|  b)  If the P flag is set and the node implements RFC 9762, it
|      SHOULD treat the Autonomous flag as if it was unset and use
|      prefix delegation to obtain addresses as described in RFC
|      9762.
|
|  c)  If the Autonomous flag is not set, silently ignore the Prefix
|      Information Option.
|
|  d)  If the preferred lifetime is greater than the valid lifetime,
|      silently ignore the Prefix Information Option.  A node MAY
|      wish to log a system management error in this case.
|
|  e)  If the prefix advertised is not equal to the prefix of an
|      address configured by stateless autoconfiguration already in
|      the list of addresses associated with the interface (where
|      "equal" means the two prefix lengths are the same and the
|      first prefix-length bits of the prefixes are identical) and if
|      the Valid Lifetime is not 0, form an address (and add it to
|      the list) by combining the advertised prefix with an interface
|      identifier of the link as follows:

10. Security Considerations 🔐

Okay bestie, this section is serious, so let's get into it 💅. The mechanism here relies on the information in the RA, which means it has the same security model as SLAAC 🫶. If the network doesn't do RA-Guard [RFC6105] 😬, an attacker could send RAs containing the PIO the network uses, set the P flag to 1, and force hosts to ignore the A flag. Without DHCPv6-PD infrastructure, hosts would either get no IPv6 addresses at all or, if they fall back to other IPv6 address assignment mechanisms like SLAAC and IA_NA, they'd wait ages to get addresses 💀. And if the network doesn't support DHCPv6-Shield [RFC7610], the attacker could also run a rogue DHCPv6 server and hand the host invalid prefixes or other invalid configuration info 🙈.

The attacker might also make hosts flip-flop between DHCPv6-PD and PIO-based SLAAC by sending the same set of PIOs with the P flag set, then without it 🌀. That would make the clients issue REBIND requests, which piles extra load onto the DHCP infrastructure. The good news is that Section 14.1 of [RFC8415] says DHCPv6-PD clients have to rate-limit the DHCPv6 messages they send ✨.

It's worth noting that if the network lets rogue RAs through, an attacker could disrupt hosts' connectivity anyway. So this document doesn't introduce any fundamentally new security considerations 🦋.

Security considerations inherent to the PD-per-device model are documented in Section 15 of [RFC9663] 📚.

11. Privacy Considerations 🧚

The privacy implications of implementing the P flag and using DHCPv6-PD to assign prefixes to hosts are pretty similar to the privacy implications of using DHCPv6 to assign individual addresses 👀. If the DHCPv6 infrastructure gives the same prefix to the same client, an observer might be able to identify clients based on the highest 64 bits of the client's address. Those implications and the recommended countermeasures are discussed in Section 13 of [RFC9663] 🌸.

Implementing P flag support on a host and receiving will enable DHCPv6 on that host if the host gets an RA containing a PIO with the P bit set. Sending DHCPv6 packets may reveal some minor additional information about the host, most prominently the hostname. This isn't a new concern, and it would apply to any network that uses DHCPv6 and sets the M flag in RAs 🫠.

No privacy considerations result from supporting the P flag on the sender side 💖.

12. IANA Considerations 🍓

IANA has made the following allocation in the "IPv6 Neighbor Discovery Prefix Information Option Flags" registry [RFC8425] 📝:

+================+==============================+===========+
| PIO Option Bit | Description                  | Reference |
+================+==============================+===========+
| 3              | P - DHCPv6-PD Preferred Flag | RFC 9762  |
+----------------+------------------------------+-----------+

                           Table 1

13. References 📖

13.1. Normative References

13.2. Informative References

Acknowledgements 🫶

Thanks to Nick Buraglio, Brian Carpenter, Tim Chown, David Farmer, Fernando Gont, Susan Hares, Mahesh Jethanandani, Suresh Krishnan, Ted Lemon, Andrew McGregor, Tomek Mrugalski, Erik Nordmark, Michael Richardson, Patrick Rohr, John Scudder, Ole Trøan, Dirk Von Hugo, Éric Vyncke and Timothy Winters for the discussions, reviews, input, and contributions 💜.

Authors' Addresses 🌈

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

Jen Linkova
Google
1 Darling Island Rd
Pyrmont NSW 2009
Australia
Email: furry13@gmail.com, furry@google.com

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

David 'equinox' Lamparter
NetDEF, Inc.
04229 Leipzig
Germany
Email: equinox@diac24.net, equinox@opensourcerouting.org
📦 where this page comes from