rfc9663v1.txt   rfc9663.txt 
Internet Engineering Task Force (IETF) L. Colitti Internet Engineering Task Force (IETF) L. Colitti
Request for Comments: 9663 Google, LLC Request for Comments: 9663 Google, LLC
Category: Informational J. Linkova, Ed. Category: Informational J. Linkova, Ed.
ISSN: 2070-1721 X. Ma, Ed. ISSN: 2070-1721 X. Ma, Ed.
Google Google
September 2024 October 2024
Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6 Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6
Prefixes per Client in Large Broadcast Networks Prefixes per Client in Large Broadcast Networks
Abstract Abstract
This document discusses an IPv6 deployment scenario when individual This document discusses an IPv6 deployment scenario when individual
nodes connected to large broadcast networks (such as enterprise nodes connected to large broadcast networks (such as enterprise
networks or public Wi-Fi networks) are allocated unique prefixes via networks or public Wi-Fi networks) are allocated unique prefixes via
DHCPv6 Prefix Delegation (DHCPv6-PD), as specified in RFC 8415. DHCPv6 Prefix Delegation (DHCPv6-PD), as specified in RFC 8415.
skipping to change at line 92 skipping to change at line 92
deployments place many devices on a shared link with a single on-link deployments place many devices on a shared link with a single on-link
prefix. This document describes an alternative deployment model prefix. This document describes an alternative deployment model
where individual devices obtain prefixes from the network. This where individual devices obtain prefixes from the network. This
provides two important advantages. provides two important advantages.
First, it offers better scalability. Unlike IPv4, IPv6 allows hosts First, it offers better scalability. Unlike IPv4, IPv6 allows hosts
to have multiple addresses, and this is the case in most deployments to have multiple addresses, and this is the case in most deployments
(see Appendix A for more details). However, increasing the number of (see Appendix A for more details). However, increasing the number of
addresses introduces scalability issues on the network addresses introduces scalability issues on the network
infrastructure. Network devices need to maintain various types of infrastructure. Network devices need to maintain various types of
tables/hashes (Neighbor Cache on first-hop routers, Neighbor tables and hashes (Neighbor Cache on first-hop routers, Neighbor
Discovery Proxy caches on Layer 2 devices, etc.). On Virtual Discovery Proxy caches on Layer 2 devices etc.). On Virtual
eXtensible Local Area Network (VXLAN) networks [RFC7348], each eXtensible Local Area Network (VXLAN) networks [RFC7348], each
address might be represented as a route so eight addresses instead of address might be represented as a route. This means, for example,
one requires the devices to support eight times more routes, etc. If that if every client has 10 addresses instead of one, the network
an infrastructure device's resources are exhausted, the device might must support 10 times more routes, etc. If an infrastructure
drop some IPv6 addresses from the corresponding tables, while the device's resources are exhausted, the device might drop some IPv6
address owner might still be using the address to send traffic. This addresses from the corresponding tables, while the address owner
leads to traffic blackholing and a degraded customer experience. might still be using the address to send traffic. This leads to
traffic being discarded and a degraded customer experience.
Providing every host with one prefix allows the network to maintain Providing every host with one prefix allows the network to maintain
only one entry per device, while still providing the device the only one entry per device, while still providing the device the
ability to use an arbitrary number of addresses. ability to use an arbitrary number of addresses.
Second, this deployment model provides the ability to extend the Second, this deployment model provides the ability to extend the
network. In IPv4, a device that connects to the network can provide network. In IPv4, a device that connects to the network can provide
connectivity to subtended devices by using NAT. With DHCPv6 Prefix connectivity to subtended devices by using NAT. With DHCPv6 Prefix
Delegation (DHCPv6-PD) [RFC8415], such a device can similarly extend Delegation (DHCPv6-PD) [RFC8415], such a device can similarly extend
the network, but unlike IPv4 NAT, it can provide its subtended the network, but unlike IPv4 NAT, it can provide its subtended
devices with full end-to-end connectivity. devices with full end-to-end connectivity.
Another method of deploying unique prefixes per device is documented Another method of deploying unique prefixes per device is documented
in [RFC8273]. Similarly, the standard deployment model in cellular in [RFC8273]. Similarly, the standard deployment model in cellular
IPv6 networks [RFC6459] provides a unique prefix to every device. IPv6 networks [RFC6459] provides a unique prefix to every device.
However, providing a unique prefix per device is very uncommon in However, providing a unique prefix per device is very uncommon in
enterprise-style networks, where nodes are usually connected to enterprise-style networks, where nodes are usually connected to
broadcast segments/VLANs and each link has a single on-link prefix broadcast segments such as VLANs and each link has a single on-link
assigned. This document takes a similar approach to [RFC8273], but prefix assigned. This document takes a similar approach to
allocates the prefix using DHCPv6-PD. [RFC8273], but allocates the prefix using DHCPv6-PD.
This document focuses on the behavior of the network. Host behavior This document focuses on the behavior of the network. Host behavior
is not defined in this document. is not defined in this document.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
skipping to change at line 144 skipping to change at line 145
Node: a device that implements IPv6 [RFC8200] Node: a device that implements IPv6 [RFC8200]
Host: any node that is not a router [RFC8200] Host: any node that is not a router [RFC8200]
Client: a node that connects to a network and acquires addresses. 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 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 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 virtual subsystems, or both. It may be either a host or a router
as defined by [RFC8200]. 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] ND: Neighbor Discovery [RFC4861]
NUD: Neighbor Unreachability Detection [RFC4861] NUD: Neighbor Unreachability Detection [RFC4861]
PIO: Prefix Information Option [RFC4862] PIO: Prefix Information Option [RFC4862]
SLAAC: IPv6 Stateless Address Autoconfiguration [RFC4862] SLAAC: IPv6 Stateless Address Autoconfiguration [RFC4862]
DHCPv6-PD: DHCPv6 Prefix Delegation [RFC8415]; a mechanism to
delegate IPv6 prefixes to clients.
4. Design Principles 4. Design Principles
Instead of all clients on a given link forming addresses from the Instead of all clients on a given link forming addresses from the
same shared prefix assigned to that link: same shared prefix assigned to that link, this deployment model
operates as described below:
* A device acts as a DHCPv6-PD client and requests a prefix via * A device acts as a DHCPv6-PD client and requests a prefix via
DHCPv6-PD by sending an IA_PD request. DHCPv6-PD by sending an IA_PD request.
* The server delegates a prefix to the client and the delegated * The server delegates a prefix to the client and the delegated
prefix is installed into the routing table of the first-hop router prefix is installed into the routing table of the first-hop router
as a route pointing to the client's link-local address. The as a route pointing to the client's link-local address. The
first-hop router can act as a DHCPv6 relay and snoop DHCPv6 Reply 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 messages from an off-link DHCPv6 server, or it can act as a DHCPv6
server itself. In both cases, it can install the route locally, server itself. In both cases, it can install the route locally,
skipping to change at line 188 skipping to change at line 198
* The device can use the delegated prefix in various ways. For * The device can use the delegated prefix in various ways. For
example, it can form addresses, as described in requirement WAA-7 example, it can form addresses, as described in requirement WAA-7
of [RFC7084]. It can also extend the network, as described in of [RFC7084]. It can also extend the network, as described in
[RFC7084] or [RFC7278]. [RFC7084] or [RFC7278].
An example scenario is shown in Figure 1. Note that the prefix An example scenario is shown in Figure 1. Note that the prefix
lengths used in the example are /64 because that is the prefix length lengths used in the example are /64 because that is the prefix length
currently supported by SLAAC and is not otherwise required by the currently supported by SLAAC and is not otherwise required by the
proposed deployment model. proposed deployment model.
+-----------------------------------------------------------------------------+ +------------------------------------------------------------------+
| DHCPv6 Servers | | DHCPv6 Servers |
| Pool 2001:db8:ddd0::/48 for clients on 2001:db8:c001::/64 link | | Pool 3fff:0:d::/48 for clients on 2001:db8:ff::/64 link |
+---------------+-------------------------+-----------------------------+-----+ +------------+---------------------+----------------------------+--+
^ | | ^ | ^ | | ^ |
| | | | | | | | | |
+-------+------+-------------------------+----------------------+------+-----+ +-------+------+---------------------+--------------------+-------+---+
|DHCPv6 | | IPv6 Network DHCPv6 | | | | DHCPv6| | IPv6 Network DHCPv6 | | |
|Relay-Forward | Relay-Forward | | |Relay-Forward | Relay-Forward | |
| ^ v Route for 2001:db8:ddd0::/48 ^ v | | ^ v Route for 3fff:0:d::/48 ^ v |
| | DHCPv6 | | | DHCPv6 | | | DHCPv6 | | | DHCPv6 |
| | Relay-Reply | | | Relay-Reply| | | Relay-Reply | | | Relay-Reply|
| | | | | | | | | | | | | | | |
+-----+-------+-------+-----+--------------------+-----+-------+-------+-----+ +------+-------+--+----------+------------+------+-------+--------+---+
| | | | | | | | | | | | | | | |
| v | v v | | v | v | v v | | v
+----+---------------+--------------+ +--------------+-------+-------------+ +----+----------+---------------+ +---------+-------+------------+
| First-hop router/DHCPv6 relay | | First-hop Router/DHCPv6 relay | | First-hop router/DHCPv6 relay | | First-hop Router/DHCPv6 relay|
| 2001:db8:ddd0:1::/64 -> fe80::aaaa| | 2001:db8:ddd0:1::/64 -> fe80::aaaa | | 3fff:0:d:1::/64 -> fe80::aa | | 3fff:0:d:1::/64 -> fe80::aa |
| 2001:db8:ddd0:2::/64 -> fe80::cccc| | 2001:db8:ddd0:2::/64 -> fe80::ccc | | 3fff:0:d:2::/64 -> fe80::cc | | 3fff:0:d:2::/64 -> fe80::cc |
+-----------+------------+----------+ +---------+--------------------+-----+ +------------+----------+-------+ +--------+----------------+----+
^ | | Shared IPv6 link, | ^ | ^ | | Shared IPv6 link | ^ |
| | | 2001:db8:c001::/64 | | | | | | 2001:db8:ff::/64 | | |
| | --+-------+-----------+-----------+------+--- | | | | -+-----+-----------+---------+-----+- | |
| | | | | | | | | | | | | |
| | | +----------------+--------------+ | DHCPv6 | | | | +---------------+-------------+ | DHCPv6 |
DHCPv6 | | |Legacy (no DHCPv6-PD) client B | | Request v DHCPv6 | | | Client B (no DHCPv6-PD) | | Request v
Request | | |link-local address fe80::bbbb | | ^ DHCPv6 Request | | |link-local address fe80::b | | ^ DHCPv6
^ | | |global address 2001:db8:c001::b| | | Reply ^ | | |global address 2001:db8:ff::b| | | Reply
| | | +-------------------------------+ | | | | | | +-----------------------------+ | | |
| v | | | v | v | | | v
| DHCPv6 | +-------------------+-----+------------+ | DHCPv6 | +--------------------+--+----------+
| Reply | | Client C | | Reply | | Client C |
| | | | link-local address fe80::cccc | | | | | link-local address fe80::cc |
| | | | delegated prefix 2001:db8:ddd0:2::/64| | | | | delegated prefix 3fff:0:d:2::/64 |
| | | +--------------+-+---------------------+ | | | +------------+-------------------+-+
| | | | | | v | | |
+----+-------+----+-----------------------------+ | | Router Advertisement +---+-------------+----------------------+ | Router |
| Client A | | | containing PIO | Client A | | Advertisement |
| link-local address: fe80::aaaa | | v 2001:db8:ddd0:2::/64 | link-local address: fe80::aa | | containing PIO v
| delegated prefix: 2001:db8:ddd0:1::/64 | | | delegated prefix: 3fff:0:d:1::/64 | | 3fff:0:d:2::/64
| +---------------------+ +------------------+ | -+-----------+--------- | +----------------+ +----------------+ | -+---------+-----------
| | virtual system | | virtual system | | | | | virtual system | | virtual system | | |
| | 2001:db8:ddd0:1::f00| |2001:db8:ddd0:1::2| | +---------+-----------+ | | 3fff:0:d:1::de | | 3fff:0:d:1::ad | | +------+----------+
| | 2001:db8:ddd0:1::caf| |2001:db8:ddd0:1::a| | | Tethered device | | | 3fff:0:d:1::ca | | 3fff:0:d:1::fe | | | Tethered device |
| +---------------------+ +------------------+ | |2001:db8:ddd0:2::6666| | +----------------+ +----------------+ | | 3fff:0:d:2::66 |
| | +---------------------+ | | +-----------------+
+-----------------------------------------------+ +----------------------------------------+
Figure 1: An Example Topology with Two First-Hop Routers Figure 1: An Example Topology with Two First-Hop Routers
5. Applicability and Limitations 5. Applicability and Limitations
Delegating a unique prefix per client provides all the benefits of Delegating a unique prefix per client provides all the benefits of
both SLAAC and DHCPv6 address allocation, but at the cost of greater both SLAAC and DHCPv6 address allocation, but at the cost of greater
address-space usage. This design would substantially benefit some address-space usage. This design would substantially benefit some
networks (see Section 12) in which the additional cost of an networks (see Section 12) in which the additional cost of an
additional service (such as DHCPv6 Prefix Delegation) and allocation additional service (such as DHCPv6 Prefix Delegation) and allocation
of a larger amount of address space can easily be justified. of a larger amount of address space can easily be justified.
Examples of such networks include but are not limited to: Examples of such networks include but are not limited to:
skipping to change at line 308 skipping to change at line 318
To ensure that routes to the delegated prefixes are preserved even if To ensure that routes to the delegated prefixes are preserved even if
a relay is rebooted or replaced, the operator MUST ensure that all a relay is rebooted or replaced, the operator MUST ensure that all
relays in the network infrastructure support DHCPv6 Bulk Leasequery relays in the network infrastructure support DHCPv6 Bulk Leasequery
as defined in [RFC5460]. While Section 4.3 of [RFC8987] lists as defined in [RFC5460]. While Section 4.3 of [RFC8987] lists
keeping active prefix delegations in persistent storage as an keeping active prefix delegations in persistent storage as an
alternative to DHCPv6 Bulk Leasequery, relying on persistent storage alternative to DHCPv6 Bulk Leasequery, relying on persistent storage
has the following drawbacks: has the following drawbacks:
* In a network with multiple relays, network state can change * In a network with multiple relays, network state can change
significantly while the relay is rebooting (new prefixes significantly while the relay is rebooting (new prefixes might be
delegated, some prefixes expiring, etc.). delegated or some prefixes might be expiring, etc).
* Persistent storage might not be preserved if the router is * Persistent storage might not be preserved if the router is
physically replaced. physically replaced.
Another mechanism for first-hop routers to obtain information about Another mechanism for first-hop routers to obtain information about
delegated prefixes is by using Active Leasequery [RFC7653], though delegated prefixes is by using Active Leasequery [RFC7653], though
this is not yet widely supported. this is not yet widely supported.
6.3. Topologies with Multiple First-Hop Routers 6.3. Topologies with Multiple First-Hop Routers
skipping to change at line 408 skipping to change at line 418
* The server MUST NOT send the Server Unicast option to the client * The server MUST NOT send the Server Unicast option to the client
unless the network topology guarantees that no client is connected unless the network topology guarantees that no client is connected
to a link with multiple relays (see Section 6.3). to a link with multiple relays (see Section 6.3).
* In order to ensure uninterrupted connectivity when a first-hop * In order to ensure uninterrupted connectivity when a first-hop
router crashes or reboots, the server MUST support Bulk Leasequery router crashes or reboots, the server MUST support Bulk Leasequery
or Active Leasequery. or Active Leasequery.
As most operators have some experience with IPv4, they can use a As most operators have some experience with IPv4, they can use a
similar approach for choosing the pool size and the timers (such as similar approach for choosing the pool size and the timers (such as
T1/T2 timers). In particular, the following factors shall be taken T1 and T2 timers). In particular, the following factors should be
into account: taken into account:
* the expected maximum number of clients; * the expected maximum number of clients;
* the average duration of a client connection; * the average duration of client connections;
* the mobility of the clients (for example, a network where all * how mobile the clients are (a network where all clients are
clients are connected to a single wired VLAN might choose longer connected to a single wired VLAN might choose longer timers than a
timers than a network where clients can switch between multiple network where clients can switch between multiple wireless
wireless SSIDs); networks);
* the expected level of recurring clients (for example, a corporate * how often clients are expected to reconnect to the network (for
authenticated Wi-Fi network might be using longer timers than an example, a corporate authenticated Wi-Fi network might be using
open public Wi-Fi). longer timers than an open public Wi-Fi).
DHCPv6 servers that delegate prefixes can interface with Dynamic DNS DHCPv6 servers that delegate prefixes can interface with Dynamic DNS
infrastructure to automatically populate reverse DNS, similarly to infrastructure to automatically populate reverse DNS using wildcard
what is described in Section 2.5.2 of [RFC8501]. Networks that also records, similarly to what is described in Section 2.2 of [RFC8501].
wish to populate forward DNS cannot do so automatically based only on Networks that also wish to populate forward DNS cannot do so
DHCPv6 prefix delegation transactions, but they can do so in other automatically based only on DHCPv6 prefix delegation transactions,
ways, such as by supporting DHCPv6 address registration as described but they can do so in other ways, such as by supporting DHCPv6
in [ADDR-NOTIFICATION]. address registration as described in [ADDR-NOTIFICATION].
Some additional recommendations driven by security and privacy Some additional recommendations driven by security and privacy
considerations are discussed in Section 15 and Section 13. considerations are discussed in Section 15 and Section 13.
8. Prefix Length Considerations 8. Prefix Length Considerations
Delegating a prefix of sufficient size to use SLAAC allows the client Delegating a prefix of sufficient size to use SLAAC allows the client
to extend the network, providing limitless addresses to IPv6 nodes to extend the network, providing limitless addresses to IPv6 nodes
connected to it (e.g., virtual machines or tethered devices), because connected to it (e.g., virtual machines or tethered devices), because
all IPv6 hosts are required to support SLAAC [RFC8504]. all IPv6 hosts are required to support SLAAC [RFC8504].
skipping to change at line 486 skipping to change at line 496
address assignment mechanisms as well. address assignment mechanisms as well.
9. Client Mobility 9. Client Mobility
As per Section 18.2.12 of [RFC8415], when the client moves to a new As per Section 18.2.12 of [RFC8415], when the client moves to a new
link, it MUST initiate a Rebind/Reply message exchange. Therefore, link, it MUST initiate a Rebind/Reply message exchange. Therefore,
when the client moves between network attachment points, it would when the client moves between network attachment points, it would
refresh its delegated prefix the same way it refreshes addresses refresh its delegated prefix the same way it refreshes addresses
assigned (via SLAAC or DHCPv6 IA_NA) from a shared on-link prefix: assigned (via SLAAC or DHCPv6 IA_NA) from a shared on-link prefix:
* When a client moves between different attachment points on the * When a client moves from between different attachment points on
same link (e.g., roams between two APs while connected to the same the same link (e.g., roams between two APs while connected to the
SSID or moves between two switch ports belonging to the same same wireless network or moves between two switchports belonging
VLAN), the delegated prefix does not change, and the first-hop to the same VLAN), the delegated prefix does not change, and the
routers have a route for the prefix with the nexthop set to the first-hop routers have a route for the prefix with the nexthop set
client link-local address on that link. As per requirement S-2 in to the client link-local address on that link. As per requirement
Section 4.3 of [RFC8987], the DHCPv6-relays (the first-hop 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 routers) MUST retain the route for the delegating prefix until the
route is released or removed due to expiring DHCP timers. route is released or removed due to expiring DHCP timers.
Therefore, if the client reconnects to the same link, the prefix Therefore, if the client reconnects to the same link, the prefix
doesn't change. doesn't change.
* When a client moves to a different link, the DHCPv6 server * When a client moves to a different link, the DHCPv6 server
provides the client with a new prefix, so the behavior is provides the client with a new prefix, so the behavior is
consistent with SLAAC or DHCPv6-assigned addresses, which are also consistent with SLAAC or DHCPv6-assigned addresses, which are also
different on the new link. different on the new link.
skipping to change at line 530 skipping to change at line 540
versus guest networks), hence clients on different links need to use versus guest networks), hence clients on different links need to use
different prefixes. different prefixes.
10. Antispoofing and SAVI Interaction 10. Antispoofing and SAVI Interaction
Enabling unicast Reverse Path Forwarding (uRPF) [RFC3704] on the Enabling unicast Reverse Path Forwarding (uRPF) [RFC3704] on the
first-hop router interfaces towards clients provides the first layer first-hop router interfaces towards clients provides the first layer
of defense against spoofing. A spoofed packet sent by a malicious of defense against spoofing. A spoofed packet sent by a malicious
client would be dropped by the router unless the spoofed address client would be dropped by the router unless the spoofed address
belongs to a prefix delegated to another client on the same belongs to a prefix delegated to another client on the same
interface. Therefore, the malicious client can only spoof addresses interface. Therefore the malicious client can only spoof addresses
already delegated to another client on the same link or another already delegated to another client on the same link or another
client link-local address. client's link-local address.
Source Address Validation Improvement (SAVI) [RFC7039] provides more Source Address Validation Improvement (SAVI) [RFC7039] provides more
reliable protection against address spoofing. Administrators reliable protection against address spoofing. Administrators
deploying the proposed solution on SAVI-enabled infrastructure SHOULD deploying the proposed solution on SAVI-enabled infrastructure SHOULD
ensure that SAVI perimeter devices support DHCPv6-PD snooping to ensure that SAVI perimeter devices support DHCPv6-PD snooping to
create the correct binding for the delegated prefixes (see create the correct binding for the delegated prefixes (see
[RFC7513]). Using FCFS SAVI [RFC6620] to protect link-local [RFC7513]). Using FCFS SAVI [RFC6620] to protect link-local
addresses and create SAVI bindings for DHCPv6-PD assigned prefixes addresses and create SAVI bindings for DHCPv6-PD assigned prefixes
would prevent spoofing. would prevent spoofing.
skipping to change at line 573 skipping to change at line 583
from the PIO from the PIO
It would be beneficial for the network to explicitly indicate its It would be beneficial for the network to explicitly indicate its
support of DHCPv6-PD for connected clients. support of DHCPv6-PD for connected clients.
* In small networks (e.g., home networks), where the number of * In small networks (e.g., home networks), where the number of
clients is not too high, the number of available prefixes becomes clients is not too high, the number of available prefixes becomes
a limiting factor. If every phone or laptop in a home network a limiting factor. If every phone or laptop in a home network
were to request a unique prefix suitable for SLAAC, the home were to request a unique prefix suitable for SLAAC, the home
network might run out of prefixes, if the prefix allocated to the network might run out of prefixes, if the prefix allocated to the
Customer Premises Equipment (CPE) by its ISP is too small (e.g., Customer Premises Equipment (CPE) by its ISP is too long. For
if an ISP delegates a /60, it would only be able to delegate 15 example, if an ISP delegates a /60, the CPE would only be able to
/64 prefixes to clients). So while the enterprise network delegate fifteen /64 prefixes to clients. So while the enterprise
administrator might want all phones in the network to request a network administrator might want all phones in the network to
prefix, it would be highly undesirable for the same phone to request a prefix, it would be highly undesirable for the same
request a prefix when connecting to a home network. phone to request a prefix when connecting to a home network.
* When the network supports both a unique prefix per client and a * When the network supports both a unique prefix per client and a
PIO with A=1 as address assignment methods, it's highly desirable 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 for the client NOT to use the PIO prefix to form global addresses
and instead only use the prefix delegated via DHCPv6-PD. Starting and instead only use the prefix delegated via DHCPv6-PD. Starting
both SLAAC using the PIO prefix and DHCPv6-PD and deprecating that both SLAAC using the PIO prefix and DHCPv6-PD, and then
SLAAC addresses after receiving a delegated prefix would be very deprecating the SLAAC addresses after receiving a delegated prefix
disruptive for applications. If the client continues to use would be very disruptive for applications. If the client
addresses formed from the PIO prefix, it would not only undermine continues to use addresses formed from the PIO prefix, it would
the benefits of the proposed solution (see Section 12), but it not only undermine the benefits of the proposed solution (see
would also introduce complexity and unpredictability in the source Section 12), but it would also introduce complexity and
address selection. Therefore, the client needs to know what unpredictability in the source address selection. Therefore, the
address assignment method to use and whether or not to use the client needs to know what address assignment method to use and
prefix in the PIO, if the network provides the PIO with the 'A' whether or not to use the prefix in the PIO, if the network
flag set. provides the PIO with the 'A' flag set.
The deployment model described in this document does not require the The deployment model described in this document does not require the
network to signal support of DHCPv6-PD: for example, devices acting network to signal support of DHCPv6-PD: for example, devices acting
as compatible routers [RFC7084] will be able to receive prefixes via as compatible routers [RFC7084] will be able to receive prefixes via
DHCPv6-PD even without such signaling. Also, some clients may decide DHCPv6-PD even without such signaling. Also, some clients may decide
to start DHCPv6-PD and acquire prefixes if they detect that the to start DHCPv6-PD and acquire prefixes if they detect that the
network does not provide addresses via SLAAC. To fully achieve the network does not provide addresses via SLAAC. To fully achieve the
benefits described in this section, [PIO-PFLAG] defines a new PIO benefits described in this section, [PIO-PFLAG] defines a new PIO
flag to signal that DHCPv6-PD is the preferred method of obtaining flag to signal that DHCPv6-PD is the preferred method of obtaining
prefixes. prefixes.
skipping to change at line 631 skipping to change at line 641
* If all clients connected to the given link support this mode of * If all clients connected to the given link support this mode of
operation and can generate addresses from the delegated prefixes, operation and can generate addresses from the delegated prefixes,
there is no reason to advertise a common prefix assigned to that there is no reason to advertise a common prefix assigned to that
link in the PIO with the 'A' flag set. Therefore, it is possible link in the PIO with the 'A' flag set. Therefore, it is possible
to remove the global shared prefix from that link and the router to remove the global shared prefix from that link and the router
interface completely, so no global addresses are on-link for the interface completely, so no global addresses are on-link for the
link. This would lead to reducing the attack surface for Neighbor link. This would lead to reducing the attack surface for Neighbor
Discovery attacks described in [RFC6583]. Discovery attacks described in [RFC6583].
* DHCPv6-PD logs and routing tables for first-hop routers provide * DHCPv6-PD logs and routing tables obtained from first-hop routers
complete information on IPv6 to MAC mapping, which can be used for provide complete information on IPv6 to MAC mapping, which can be
forensics and troubleshooting. Such information is much less used for forensics and troubleshooting. Such information is much
dynamic than the ND cache; therefore, it's much easier for an less dynamic than the ND cache; therefore, it's much easier for an
operator to collect and process it. operator to collect and process it.
* A dedicated prefix per client allows the network administrator to * A dedicated prefix per client allows the network administrator to
create security policies per device (such as ACLs) even if the create security policies per device (such as ACLs) even if the
client is using temporary addresses. This mitigates one of the client is using temporary addresses. This mitigates one of the
issues described in [IPv6-ADDRESS]. issues described in [IPv6-ADDRESS].
* Fate sharing: all global addresses used by a given client are * Fate sharing: all global addresses used by a given client are
routed as a single prefix. Either all of them work or not, which routed as a single prefix. Either all of them work or none of
makes failures easier to diagnose and mitigate. them work, which makes failures easier to diagnose and mitigate.
* Lower level of multicast traffic: less Neighbor Discovery * Lower level of multicast traffic: less Neighbor Discovery
[RFC4861] multicast packets, as the routers need to resolve only [RFC4861] multicast packets, as the routers need to resolve only
the clients' link-local addresses. Also, there is no Duplicate the clients' link-local addresses. Also, there is no Duplicate
Address Detection (DAD) traffic except for the clients' link-local Address Detection (DAD) traffic except for the clients' link-local
addresses. addresses.
* Ability to extend the network transparently. If the network * Ability to extend the network transparently. If the network
delegates to the client a prefix of sufficient size to support delegates to the client a prefix of sufficient size to support
SLAAC, the client can provide connectivity to other hosts, as is SLAAC, the client can provide connectivity to other hosts, as is
skipping to change at line 809 skipping to change at line 819
[IPv6-ADDRESS] [IPv6-ADDRESS]
Gont, F. and G. Gont, "Implications of IPv6 Addressing on Gont, F. and G. Gont, "Implications of IPv6 Addressing on
Security Operations", Work in Progress, Internet-Draft, Security Operations", Work in Progress, Internet-Draft,
draft-ietf-opsec-ipv6-addressing-00, 2 June 2023, draft-ietf-opsec-ipv6-addressing-00, 2 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsec- <https://datatracker.ietf.org/doc/html/draft-ietf-opsec-
ipv6-addressing-00>. ipv6-addressing-00>.
[PIO-PFLAG] [PIO-PFLAG]
Colitti, L., Linkova, J., Ma, X., and D. Lamparter, Colitti, L., Linkova, J., Ma, X., and D. Lamparter,
"Signalling DHCPv6 Prefix per Client Availability to "Signaling DHCPv6 Prefix per Client Availability to
Hosts", Work in Progress, Internet-Draft, draft-ietf-6man- Hosts", Work in Progress, Internet-Draft, draft-ietf-6man-
pio-pflag-09, 15 August 2024, pio-pflag-10, 30 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man- <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
pio-pflag-09>. pio-pflag-10>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>. 2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
skipping to change at line 920 skipping to change at line 930
assigned to its interface. At the very least, a host can be expected assigned to its interface. At the very least, a host can be expected
to have one link-local address, one temporary address, and, in most to have one link-local address, one temporary address, and, in most
cases, one stable global address. On a network providing NAT64 cases, one stable global address. On a network providing NAT64
service, an IPv6-only host running the 464XLAT customer-side service, an IPv6-only host running the 464XLAT customer-side
translator (CLAT) [RFC6877] would use a dedicated 464XLAT address, translator (CLAT) [RFC6877] would use a dedicated 464XLAT address,
configured via SLAAC (see Section 6.3 of [RFC6877]), which brings the configured via SLAAC (see Section 6.3 of [RFC6877]), which brings the
total number of addresses to four. Other common scenarios where the total number of addresses to four. Other common scenarios where the
number of addresses per host interface might increase significantly number of addresses per host interface might increase significantly
include but are not limited to: include but are not limited to:
* Devices running containers/namespaces: each container/namespace * Devices running containers or namespaces: each container or
would have multiple addresses as described above. As a result, a namespace would have multiple addresses as described above. As a
device running just a few containers in a bridge mode can easily result, a device running just a few containers in a bridge mode
have 20 or more IPv6 addresses on the given link. can easily have 20 or more IPv6 addresses on the given link.
* Networks assigning multiple prefixes to a given link: these * Networks assigning multiple prefixes to a given link: multihomed
include multihomed networks, networks using ULA [RFC4193] and non- networks, networks using Unique Local IPv6 Unicast Addresses (ULA,
ULA prefixes together, or networks performing a graceful [RFC4193]) and non-ULA prefixes together, or networks performing a
renumbering from one prefix to another. graceful renumbering from one prefix to another.
[RFC7934] discusses this aspect and explicitly states that IPv6 [RFC7934] discusses this aspect and explicitly states that IPv6
deployments SHOULD NOT limit the number of IPv6 addresses a host can deployments SHOULD NOT limit the number of IPv6 addresses a host can
have. However, it has been observed that networks often do limit the have. However, it has been observed that networks often do limit the
number of on-link addresses per device, likely in an attempt to number of on-link addresses per device, likely in an attempt to
protect network resources and prevent DoS attacks. protect network resources and prevent DoS attacks.
The most common scenario of network-imposed limitations is ND proxy. The most common scenario of network-imposed limitations is ND proxy.
Many enterprise-scale wireless solutions implement ND proxy to reduce Many enterprise-scale wireless solutions implement ND proxy to reduce
the amount of broadcast and multicast downstream (AP to clients) the amount of broadcast and multicast downstream (AP to clients)
 End of changes. 27 change blocks. 
125 lines changed or deleted 135 lines changed or added

This html diff was produced by rfcdiff 1.48.