Using Router Advertisements to Signal the Availability of DHCPv6 Prefix Delegation to Clients
updates
Extracted elements (25)
The P flag expresses the network operator's preference that clients attempt DHCPv6-PD instead of individual address configuration. The actual delegated prefix will necessarily differ from the PIO prefix—the PIO prefix is only used to convey the signal, not for address assignment by the client.
The P flag is placed in the PIO (not as a standalone RA flag) for two reasons: (1) it must be available to the client before it decides to form SLAAC addresses, because forming SLAAC addresses and then switching to DHCPv6-PD is disruptive; (2) the preference is prefix-specific—a network might want DHCPv6-PD for global prefixes but SLAAC for ULA prefixes.
RFC 4861 Section 4.2 is updated so that the note about no DHCPv6 information being available now reads: 'If the M, O, or P (RFC 9762) flags are not set, this indicates that no information is available via DHCPv6.' The P flag is thus added as a third DHCPv6-signaling indicator.
RFC 4862 Section 5.5.3 is updated: when processing a PIO, link-local check comes first (moved to step a), then if the P flag is set and the node implements RFC 9762 it SHOULD treat the Autonomous flag as unset and use prefix delegation. The original Autonomous-flag-not-set early exit is now step c instead of step a.
Clients that do not support DHCPv6 prefix delegation MUST ignore the P flag. The P flag is also meaningless for link-local prefixes, and any PIO containing the link-local prefix MUST be ignored per RFC 4862 Section 5.5.3.
For each interface, the client MUST keep a list of every prefix received from a PIO with the P flag set that currently has a non-zero preferred lifetime. When a prefix's preferred lifetime becomes zero, it MUST be removed from the list.
For source address selection (RFC 6724), if the host creates addresses from a delegated prefix, it SHOULD treat those addresses as if assigned to the interface on which the prefix was received, placing them in the candidate set and associating them with the outgoing interface for Rule 5.
Hosts supporting the P flag SHOULD process ICMPv6 redirects unless configured otherwise. Without redirect processing, traffic between clients using delegated prefixes on the same link must traverse the default router, causing higher latency.
If the client has already received delegated prefix(es) from one or more servers, any time prefixes are added to or removed from the P-flag list, the client MUST consider this a change in configuration information per RFC 8415 Section 18.2.12, and MUST perform a REBIND unless the list is now empty. This handles network renumbering scenarios.
If the delegated prefix is too long to be used for SLAAC, the client MUST ignore it. If it is shorter than required, the client SHOULD accept it and allocate one or more longer prefixes suitable for SLAAC.
If the network desires to delegate prefixes to devices that support DHCPv6-PD but do not support the P flag, it SHOULD also set the M or O bits in the RA to 1, because some devices (e.g., CE routers per RFC 7084) might not initiate DHCPv6-PD if both M and O bits are zero.
In multi-prefix multihoming, the host SHOULD associate each delegated prefix with the link-local address of the DHCPv6 server or relay from which it received the REPLY packet. When multiple REPLYs carry the same prefix from distinct link-local addresses, the host SHOULD associate the prefix with all such addresses.
Routers SHOULD set the P flag to zero by default unless explicitly configured by the administrator, and MUST allow the P flag to be configured separately from the A flag. Enabling or disabling the P flag MUST NOT trigger automatic changes in the A flag value.
The absence of PIOs with the P bit set MUST NOT be processed to mean that DHCPv6-PD is absent. Nodes running DHCPv6-PD due to explicit configuration or by default (e.g., CE routers) MUST NOT disable DHCPv6-PD solely because no PIOs with the P bit are received.
The client MUST NOT send or forward packets with destination addresses within a delegated prefix to the interface that it obtained the prefix on, as this can cause a routing loop. Prevention methods include assigning the prefix to another interface or adding a high-metric discard route.
When a client requests a prefix via DHCPv6-PD, it MUST use the prefix length hint (RFC 8415 Section 18.2.4) to request a prefix short enough to form addresses via SLAAC.
When the client requests a prefix using DHCPv6-PD, it SHOULD NOT use SLAAC to obtain IPv6 addresses from PIOs with both P and A bits set. If all PIOs have the P bit set, the client SHOULD NOT request individual IPv6 addresses from DHCPv6 (i.e., SHOULD NOT include IA_NA options in Solicit messages).
When the length of the P-flag prefix list increases to one, the client SHOULD start requesting prefixes via DHCPv6 prefix delegation unless it is already doing so. When the list decreases to zero, the client SHOULD stop requesting or renewing prefixes via DHCPv6-PD if it has no other reason to do so.
If the DHCPv6 infrastructure assigns the same prefix to the same client across reconnections, an observer can identify clients based on the upper 64 bits of their address. Privacy implications are similar to DHCPv6 IA_NA assignment; countermeasures are discussed in RFC 9663 Section 13.
Implementing P flag support on a host will enable DHCPv6 when the host receives an RA with a PIO P=1, causing DHCPv6 packets (which may reveal the hostname) to be sent. This is not a new concern and is equivalent to networks that set the M flag.
The P flag (DHCPv6-PD Preferred Flag) is a 1-bit flag in the Prefix Information Option (PIO) of IPv6 Router Advertisements, located at bit position 3 (after the R flag). When set, it indicates the network prefers clients use DHCPv6 prefix delegation (RFC 9663) instead of SLAAC or individual DHCPv6 address assignment.
IANA allocated PIO Option Bit 3 as the 'P - DHCPv6-PD Preferred Flag' in the 'IPv6 Neighbor Discovery Prefix Information Option Flags' registry (RFC 8425). Reference: RFC 9762.
An attacker can force clients to oscillate between DHCPv6-PD and SLAAC by alternately sending PIOs with and without the P flag, causing repeated REBIND requests that increase load on DHCPv6 infrastructure. RFC 8415 Section 14.1 rate-limiting requirements partially mitigate this.
Without RA-Guard (RFC 6105), an attacker can send rogue RAs with PIO P=1, causing hosts to ignore the A flag and seek DHCPv6-PD. If no DHCPv6-PD infrastructure exists, hosts may receive no IPv6 addresses or experience delays falling back. Without DHCPv6-Shield (RFC 7610), an attacker could additionally run a rogue DHCPv6 server providing invalid prefixes.
The PIO with P flag is a 32-byte option: Type (8 bits), Length (8 bits), Prefix Length (8 bits), flags L|A|R|P|Rsvd1 (8 bits), Valid Lifetime (32 bits), Preferred Lifetime (32 bits), Reserved2 (32 bits), Prefix (128 bits). The P flag occupies bit 3 of the flags byte.