rfc9762v2.txt   rfc9762.txt 
Internet Engineering Task Force (IETF) L. Colitti Internet Engineering Task Force (IETF) L. Colitti
Request for Comments: 9762 J. Linkova Request for Comments: 9762 J. Linkova
Updates: 4861, 4862 X. Ma, Ed. Updates: 4861, 4862 X. Ma, Ed.
Category: Standards Track Google Category: Standards Track Google
ISSN: 2070-1721 D. Lamparter ISSN: 2070-1721 D. Lamparter
NetDEF, Inc. NetDEF, Inc.
April 2025 June 2025
Using Router Advertisements to Signal the Availability of DHCPv6 Prefix Using Router Advertisements to Signal the Availability of DHCPv6 Prefix
Delegation to Clients Delegation to Clients
Abstract Abstract
This document defines the P flag in the Prefix Information Option This document defines the P flag in the Prefix Information Option
(PIO) of IPv6 Router Advertisements (RAs). The flag is used to (PIO) of IPv6 Router Advertisements (RAs). The flag is used to
indicate that the network prefers that clients use the deployment indicate that the network prefers that clients use the deployment
model in RFC 9663 instead of using individual addresses in the on- model in RFC 9663 instead of using individual addresses in the on-
skipping to change at line 275 skipping to change at line 275
* When the length of the list increases to one, the client SHOULD * When the length of the list increases to one, the client SHOULD
start requesting prefixes via DHCPv6 prefix delegation unless it start requesting prefixes via DHCPv6 prefix delegation unless it
is already doing so. is already doing so.
* When the length of the list decreases to zero, the client SHOULD * When the length of the list decreases to zero, the client SHOULD
stop requesting or renewing prefixes via DHCPv6 prefix delegation stop requesting or renewing prefixes via DHCPv6 prefix delegation
if it has no other reason to do so. The lifetimes of any prefixes if it has no other reason to do so. The lifetimes of any prefixes
already obtained via DHCPv6 are unaffected. already obtained via DHCPv6 are unaffected.
* If the client has already received delegated prefix(es) from one * If the client has already received delegated prefix(es) from one
or more servers, then any time a prefix is added to or removed or more servers, then any time one or more prefix(es) are added to
from the list, the client MUST consider this to be a change in or removed from the list, the client MUST consider this to be a
configuration information as described in Section 18.2.12 of change in configuration information as described in
[RFC8415]. In that case, the client MUST perform a REBIND, unless Section 18.2.12 of [RFC8415]. In that case, the client MUST
the list is now empty. This is in addition to performing a REBIND perform a REBIND, unless the list is now empty. This is in
in the other cases required by that section. Issuing a REBIND addition to performing a REBIND in the other cases required by
allows the client to obtain new prefixes if necessary, for that section. Issuing a REBIND allows the client to obtain new
example, when the network is being renumbered. It also refreshes prefixes if necessary, for example, when the network is being
the state related to the delegated prefix(es). renumbered. It also refreshes the state related to the delegated
prefix(es).
When a client requests a prefix via DHCPv6-PD, it MUST use the prefix When a client requests a prefix via DHCPv6-PD, it MUST use the prefix
length hint (Section 18.2.4 of [RFC8415]) to request a prefix that is length hint (Section 18.2.4 of [RFC8415]) to request a prefix that is
short enough to form addresses via SLAAC. short enough to form addresses via SLAAC.
In order to achieve the scalability benefits of using DHCPv6-PD, the In order to achieve the scalability benefits of using DHCPv6-PD, the
client SHOULD prefer to form addresses from the delegated prefix client SHOULD prefer to form addresses from the delegated prefix
instead of using individual addresses in the on-link prefix(es). instead of using individual addresses in the on-link prefix(es).
Therefore, when the client requests a prefix using DHCPv6-PD, the Therefore, when the client requests a prefix using DHCPv6-PD, the
client SHOULD NOT use SLAAC to obtain IPv6 addresses from PIOs with client SHOULD NOT use SLAAC to obtain IPv6 addresses from PIOs with
skipping to change at line 326 skipping to change at line 327
For every accepted prefix: For every accepted prefix:
* The client MAY form as many IPv6 addresses from the prefix as it * The client MAY form as many IPv6 addresses from the prefix as it
chooses. chooses.
* The client MAY use the prefix to provide IPv6 addresses to * The client MAY use the prefix to provide IPv6 addresses to
internal components such as VMs or containers. internal components such as VMs or containers.
* The client MAY use the prefix to allow devices directly connected * The client MAY use the prefix to allow devices directly connected
to it to obtain IPv6 addresses. For example, the client MAY route to it to obtain IPv6 addresses. For example, the client MAY route
traffic for that prefix to the interface and send a RA containing traffic for that prefix to an interface and send an RA containing
a PIO for the prefix on the interface. That interface MUST NOT be a PIO for the prefix on that interface. That interface MUST NOT
the interface the prefix is obtained from. If the client be the interface the prefix is obtained from. If the client
advertises the prefix on an interface and it has formed addresses advertises the prefix on an interface and it has formed addresses
from the prefix, then it MUST act as though the addresses were from the prefix, then it MUST act as though the addresses were
assigned to that interface for the purposes of Neighbor Discovery assigned to that interface for the purposes of Neighbor Discovery
and Duplicate Address Detection. and Duplicate Address Detection.
The client MUST NOT send or forward packets with destination The client MUST NOT send or forward packets with destination
addresses within a delegated prefix to the interface that it obtained addresses within a delegated prefix to the interface that it obtained
the prefix on, as this can cause a routing loop. This problem will the prefix on, as this can cause a routing loop. This problem will
not occur if the client has assigned the prefix to another interface. not occur if the client has assigned the prefix to another interface.
Another way the client can prevent this problem is to add to its Another way the client can prevent this problem is to add to its
skipping to change at line 357 skipping to change at line 358
carry any kind of signal to the opposite and MUST NOT be processed to carry any kind of signal to the opposite and MUST NOT be processed to
mean that DHCPv6-PD is absent. In particular, nodes that run mean that DHCPv6-PD is absent. In particular, nodes that run
DHCPv6-PD due to explicit configuration or by default (e.g., to DHCPv6-PD due to explicit configuration or by default (e.g., to
extend the network) MUST NOT disable DHCPv6-PD on the absence of PIOs extend the network) MUST NOT disable DHCPv6-PD on the absence of PIOs
with the P bit set. A very common example of this are CE routers as with the P bit set. A very common example of this are CE routers as
described by [RFC7084]. described by [RFC7084].
7.4. On-Link Communication 7.4. On-Link Communication
When the network delegates unique prefixes to clients, each client When the network delegates unique prefixes to clients, each client
will consider other client's destination addresses to be off-link, will consider other clients' destination addresses to be off-link,
because those addresses are from the delegated prefixes and are not because those addresses are from the delegated prefixes and are not
within any on-link prefix. When a client sends traffic to another within any on-link prefix. When a client sends traffic to another
client, packets will initially be sent to the default router. The client, packets will initially be sent to the default router. The
router may respond with an ICMPv6 redirect message (Section 4.5 of router may respond with an ICMPv6 redirect message (Section 4.5 of
[RFC4861]). If the client receives and accepts the redirect, then [RFC4861]). If the client receives and accepts the redirect, then
traffic can flow directly from device to device. Therefore, hosts traffic can flow directly from device to device. Therefore, hosts
supporting the P flag SHOULD process redirects unless configured supporting the P flag SHOULD process redirects unless configured
otherwise. Hosts that do not process ICMPv6 redirects, and routers otherwise. Hosts that do not process ICMPv6 redirects, and routers
that do not act on ICMPv6 redirects, may experience higher latency that do not act on ICMPv6 redirects, may experience higher latency
while communicating to prefixes delegated to other clients on the while communicating to prefixes delegated to other clients on the
skipping to change at line 440 skipping to change at line 441
| "equal" means the two prefix lengths are the same and the | "equal" means the two prefix lengths are the same and the
| first prefix-length bits of the prefixes are identical), and | first prefix-length bits of the prefixes are identical), and
| if the Valid Lifetime is not 0, form an address (and add it to | if the Valid Lifetime is not 0, form an address (and add it to
| the list) by combining the advertised prefix with an interface | the list) by combining the advertised prefix with an interface
| identifier of the link as follows: | identifier of the link as follows:
NEW TEXT: NEW TEXT:
| For each Prefix Information Option in the Router Advertisement: | For each Prefix Information Option in the Router Advertisement:
| |
| a) If the P flag is set and the node implements RFC 9762, it | 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 | SHOULD treat the Autonomous flag as if it was unset and use
| prefix delegation to obtain addresses as described in RFC | prefix delegation to obtain addresses as described in RFC
| 9762. | 9762.
| |
| b) If the Autonomous flag is not set, silently ignore the Prefix | c) If the Autonomous flag is not set, silently ignore the Prefix
| Information Option. | Information Option.
| |
| c) If the prefix is the link-local prefix, silently ignore the
| Prefix Information Option.
|
| d) If the preferred lifetime is greater than the valid lifetime, | d) If the preferred lifetime is greater than the valid lifetime,
| silently ignore the Prefix Information Option. A node MAY | silently ignore the Prefix Information Option. A node MAY
| wish to log a system management error in this case. | wish to log a system management error in this case.
| |
| e) If the prefix advertised is not equal to the prefix of an | e) If the prefix advertised is not equal to the prefix of an
| address configured by stateless autoconfiguration already in | address configured by stateless autoconfiguration already in
| the list of addresses associated with the interface (where | the list of addresses associated with the interface (where
| "equal" means the two prefix lengths are the same and the | "equal" means the two prefix lengths are the same and the
| first prefix-length bits of the prefixes are identical) and if | 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 Valid Lifetime is not 0, form an address (and add it to
skipping to change at line 487 skipping to change at line 488
configuration information. configuration information.
The attacker might force hosts to oscillate between DHCPv6-PD and The attacker might force hosts to oscillate between DHCPv6-PD and
PIO-based SLAAC by sending the same set of PIOs with and then without PIO-based SLAAC by sending the same set of PIOs with and then without
the P flag set. That would cause the clients to issue REBIND the P flag set. That would cause the clients to issue REBIND
requests, increasing the load on the DHCP infrastructure. However, requests, increasing the load on the DHCP infrastructure. However,
Section 14.1 of [RFC8415] requires that DHCPv6-PD clients rate-limit Section 14.1 of [RFC8415] requires that DHCPv6-PD clients rate-limit
transmitted DHCPv6 messages. transmitted DHCPv6 messages.
It should be noted that if the network allows rogue RAs to be sent, It should be noted that if the network allows rogue RAs to be sent,
the attacker would be able to disrupt hosts connectivity anyway, so the attacker would be able to disrupt hosts' connectivity anyway, so
this document doesn't introduce any fundamentally new security this document doesn't introduce any fundamentally new security
considerations. considerations.
Security considerations inherent to the PD-per-device model are Security considerations inherent to the PD-per-device model are
documented in Section 15 of [RFC9663]. documented in Section 15 of [RFC9663].
11. Privacy Considerations 11. Privacy Considerations
The privacy implications of implementing the P flag and using The privacy implications of implementing the P flag and using
DHCPv6-PD to assign prefixes to hosts are similar to the privacy DHCPv6-PD to assign prefixes to hosts are similar to the privacy
implications of using DHCPv6 for assigning individual addresses. If implications of using DHCPv6 to assign individual addresses. If the
the DHCPv6 infrastructure assigns the same prefix to the same client, DHCPv6 infrastructure assigns the same prefix to the same client,
then an observer might be able to identify clients based on the then an observer might be able to identify clients based on the
highest 64 bits of the client's address. Those implications and highest 64 bits of the client's address. Those implications and
recommended countermeasures are discussed in Section 13 of [RFC9663]. recommended countermeasures are discussed in Section 13 of [RFC9663].
Implementing the P flag support on a host and receiving side enables Implementing the P flag support on a host and receiving will enable
DHCPv6 on that host. Sending DHCPv6 packets may reveal some minor DHCPv6 on that host if the host receives 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. additional information about the host, most prominently the hostname.
This is not a new concern and would apply for any network that uses This is not a new concern and would apply for any network that uses
DHCPv6 and sets the M flag in RAs. DHCPv6 and sets the M flag in RAs.
No privacy considerations result from supporting the P flag on the No privacy considerations result from supporting the P flag on the
sender side. sender side.
12. IANA Considerations 12. IANA Considerations
IANA has made the following allocation in the "IPv6 Neighbor IANA has made the following allocation in the "IPv6 Neighbor
skipping to change at line 618 skipping to change at line 620
DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique
IPv6 Prefixes per Client in Large Broadcast Networks", IPv6 Prefixes per Client in Large Broadcast Networks",
RFC 9663, DOI 10.17487/RFC9663, October 2024, RFC 9663, DOI 10.17487/RFC9663, October 2024,
<https://www.rfc-editor.org/info/rfc9663>. <https://www.rfc-editor.org/info/rfc9663>.
Acknowledgements Acknowledgements
Thanks to Nick Buraglio, Brian Carpenter, Tim Chown, David Farmer, Thanks to Nick Buraglio, Brian Carpenter, Tim Chown, David Farmer,
Fernando Gont, Susan Hares, Mahesh Jethanandani, Suresh Krishnan, Ted Fernando Gont, Susan Hares, Mahesh Jethanandani, Suresh Krishnan, Ted
Lemon, Andrew McGregor, Tomek Mrugalski, Erik Nordmark, Michael Lemon, Andrew McGregor, Tomek Mrugalski, Erik Nordmark, Michael
Richardson, John Scudder, Ole Trøan, Dirk Von Hugo, Éric Vyncke and Richardson, Patrick Rohr, John Scudder, Ole Trøan, Dirk Von Hugo,
Timothy Winters for the discussions, reviews, input, and Éric Vyncke and Timothy Winters for the discussions, reviews, input,
contributions. and contributions.
Authors' Addresses Authors' Addresses
Lorenzo Colitti Lorenzo Colitti
Google Google
Shibuya 3-21-3, Shibuya 3-21-3,
Japan Japan
Email: lorenzo@google.com Email: lorenzo@google.com
Jen Linkova Jen Linkova
 End of changes. 11 change blocks. 
27 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.48.