Internet-Draft	MultAddrr	October 2023
Colitti, et al.	Expires 8 April 2024	[Page]

Workgroup:: v6ops Working Group
Internet-Draft:: draft-ietf-v6ops-dhcp-pd-per-device
Published:: 6 October 2023
Intended Status:: Informational
Expires:: 8 April 2024
Authors:: L. Colitti

Google, LLC

J. Linkova, Ed.

Google

X. Ma, Ed.

Google

Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large Broadcast Networks

Abstract

This document discusses an IPv6 deployment scenario when individual clients connected to large broadcast networks (such as enterprise networks or public Wi-Fi networks) are allocated unique prefixes via DHCPv6 Prefix Delegation (DHCPv6-PD).¶

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 8 April 2024.¶

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to 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 are provided without warranty as described in the Revised BSD License.¶

▲

1. Introduction

Often, large broadcast networks (such as enterprise or public Wi-Fi deployments) place many devices on a shared link with a single on-link prefix. This document describes an alternative deployment model where individual clients obtain prefixes from the network. This provides two important advantages.¶

First, it offers better scalability. Unlike IPv4, IPv6 allows (and often requires) hosts to have multiple addresses (see Section 16 for more details). However, increasing the number of addresses introduces scalability issues on the network infrastructure. Network devices need to maintain various types of tables/hashes (Neighbor Cache on first-hop routers, Neighbor Discovery Proxy caches on L2 devices etc). On VXLAN [RFC7348] networks each address might be represented as a route so 8 addresses instead of 1 requires the devices to support 8 times more routes, etc. If an infrastructure device resources are exhausted, the device might drop some IPv6 addresses from the corresponding tables, while the address owner might be still using the address to send traffic. This leads to traffic blackholing and degraded customer experience. Providing every host with one prefix allows the network to maintain only one entry per device, while still providing the device the ability to use arbitrary number of addresses.¶

Second, it provides the ability to extend the network. In IPv4, a device that connects to the network can provide connectivity to subtended devices by using NAT. With DHCPv6 PD, such a device can similarly extend the network, but unlike IPv4 NAT, it can provide its subtended devices with full end-to-end connectivity.¶

Another method of deploying unique prefixes per device is documented in [RFC8273]. Similarly, the standard deployment model in cellular IPv6 networks [RFC6459] provides a unique prefix to every device. However, providing a unique prefix per device is very uncommon in enterprise-style networks, where nodes are usually connected to broadcast segments/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.¶

2. Requirements Language

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 interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Terminology

Node: a device that implements IPv6, [RFC8200].¶

Host: any node that is not a router, [RFC8200].¶

Client: a node which connects to a network and acquires addresses. The node may wish to obtain addresses for its own use, or 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].¶

ND: Neighbor Discovery, [RFC4861].¶

SLAAC: IPv6 Stateless Address Autoconfiguration, [RFC4862].¶

DHCPv6-PD: DHCPv6 ([RFC8415]) mechanism to delegate IPv6 prefixes to clients.¶

4. Design Principles

Instead of all clients on a given link forming addresses from the same shared prefix assigned to that link:¶

A device acts as DHCP-PD client and requests a prefix via DHCPv6-PD by sending an IA_PD request.¶
The first-hop router acts as a DHCPv6 relay and sends the request to the DHCPv6-PD servers. In smaller networks it's entirely possible for the first-hop router to act as a DHCPv6-PD server and assign the prefix from a larger pool allocated for the given link or the whole site.¶
The allocated prefix is installed into the first-hop router routing table as a route pointing to the client's link-local address. That route can be redistributed into a dynamic routing protocol (if the network is running one). For the router and all other infrastructure devices that prefix is considered off-link, so traffic to that prefix does not trigger any ND packets.¶
The device can use the delegated prefix in various ways. For example, it can form addresses and use them to communicate with the network, as described in [RFC7084] requirement WAA-7. It can also extend the network, as described in [RFC7084] or [RFC7278].¶

5. Applicability and Limitations

Delegating a unique prefix per client provides all the benefits of both SLAAC and DHCPv6 address allocation, but at the cost of greater address space usage. This design would substantially benefit some networks (see Section 12), in which the addional cost of an additional service (DHCPv6 prefix delegation) and allocating a larger amount of address space can easily be justified. Examples of such networks include but are not limited to:¶

Large-scale networks where even 3-5 addresses per client might introduce scalability issues.¶
Networks with 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, such as home networks, with smaller address space and lower number of clients, SLAAC is a better and simpler option.¶

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 valid only on the link, and if clients move to another link they will obtain a prefix from the pool associated with the new link (see Section 9). This is very similar to how address pools are allocated when using DHCP to assign individual addresses (e.g., DHCPv4 or DHCPv6 IA_NA), where each link has a dedicated pool of addresses, and clients on the link obtain addresses from the pool.¶

Other deployment models, such as prefix pools shared over multiple links or routers, are possible, but not 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]. In particular, per Section 4.2 of [RFC8987], the first-hop router must maintain a local routing table that contains all prefixes delegated to clients.¶

When using a dedicated prefix pool for each link, the network can route the entire pool to the link's first-hop routers, and the routers do not need to advertise individual delegated prefixes into the network's dynamic routing protocol.¶

With the first-hop routers performing DHCPv6 relay functions, the proposed design neither requires any subsequent relays in the path nor introduce any requirements to such relays, if they are deployed.¶

To ensure that routes to the delegated prefixes are preserved 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]. While Section 4.3 of [RFC8987] lists keeping active prefix delegations in persistent storage as an alternative to DHCPv6 Bulk Leasequery, relying on persistent storage has the following drawbacks:¶

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

Another mechanism for first-hop routers to obtain information about delegated prefixes is by using Active Leasequery [RFC7653], though this is not yet widely supported.¶

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.¶

If the first-hop routers obtain information about delegated prefixes by snooping DHCPv6 Reply messages sent by the server, then all the first-hop routers must be able to snoop these messages. This is possible if the client multicasts the DHCPv6 messages it sends to the server. The server will receive one copy of the client message through each first-hop relay, and will reply unicast to each of them via the relay (or chain of relays) from which it received the message. Thus, all first-hop relays will be able to snoop the replies. Per Section 14 of [RFC8415], clients always use multicast unless the server explicitly allows it using the Server Unicast option ([RFC8415], Section 21.12). Therefore, 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 [I-D.ietf-dhc-rfc8415bis] deprecates the Server Unicast option precisely because it is not compatible with topologies with multiple first-hop relays.¶

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. Additionally, some vendors provide vendor-specific mechanisms to synchronize state between DHCP relays.¶

6.4. On-link Communication

For security reasons, some networks do not allow communication between clients on the same link, by dropping device-to-device traffic at layer 2. In this case, delegating a prefix to each client doesn't affect traffic flows, as all traffic is sent to the first-hop router anyway. The router may allow or drop the traffic depending the network security policy.¶

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 are considered onlink, 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 they are no longer within the on-link prefix, but are within the delegated prefixes. When a client sends traffic to another client, packets will initially be sent to the default router. The router will respond with an ICMPv6 redirect message (Section 4.5 of [RFC4861]). If the client receives and accepts the redirect, then traffic can 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).¶

7. DHCPv6-PD Server Considerations

Thsi document doesn't introduce any changes to DHCPv6 protocol in general and DHCPv6 server behaviour in particular. However, for the proposed solution to work correctly, the DHCPv6-PD server needs to be configured as follows:¶

The server MUST follow [RFC8168] recommendations 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.¶
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.¶

8. Prefix Length Considerations

DHCPv6 prefix delegation supports delegating prefixes of any size. However, at the time of writing the only prefix size that will allow devices to use SLAAC is 64 bits (see also [RFC7421]). Delegating a prefix of sufficient size to use SLAAC allows the client to provide limitless addresses to IPv6 nodes connected to it (e.g., virtual machines, tethered devices), because all IPv6 hosts are required to support SLAAC [RFC8504]. It is also required to extend the network using [RFC7084] (see requirement L-2). Choosing longer prefixes would require the client and any connected system to use some other form of address assignment, which many hosts do not support, and therefore limits the applicability of the proposed solution. Additionally, even clients that support other forms of address assignment require SLAAC for some functions, such as forming dedicates addresses for the use of 464xlat.¶

Assigning a prefix of sufficient size to support SLAAC is possible on large networks. Section 9.2 of [RFC7934] suggests that even very large networks that require the use of the full RFC1918 range 10.0.0.0/8 to address hosts, an IPv6 /40 is sufficient to provide each client with /64. In multi-site networks the calculations might get more complex, as each site's IPv6 prefix needs to be larger enough to be globally routable and accepted by eBGP peers, for example /48. Let's consider an enterprise network which has 8000 sites (~2^13). Imagine that site has up to 64 (2^6) different network types and each network requires its own /48. So each network can provide /64 to 65K clients (an equivalent of using a /16 IPv4 subnet to address clients). In that case such an enterprise would need /29 (48 - 6 - 13) to provide /64 to each client. Networks of such size usually have multiple allocations from RIRs so /29 sounds reasonable. In real life there are very few networks of that scale and a single /32 would be sufficient for most deployments.¶

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. Therefore when the client moves between network attachment points it would refresh its delegated prefix the same way it refreshes addresses assigned (via SLAAC or DHCPv6 IA_NA) from the shared onlink prefix:¶

When a client moves from between different attachment points on the same link (e.g. roams between two APs while connected to the same SSID or moves between two switchports belonging to the same VLAN), the delegated prefix does not change, and the fist-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 (Section 4.3 of [RFC8987]), the DHCPv6-relays (the first-hop routers) MUST retain the route for the delegating prefixuntil 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 behaviour is consistent with SLAAC or DHCPv6-assigned addresses, which are also different on the new link.¶

While allowing the client to keep the same prefix while roaming between links might provide some benefits for the client, it is not feasible without protocol changes: 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. Therefore the first-hop routers would have two routes for the same prefix pointing to different link, causing conenctivity issues for the client.¶

It should be noted that addressing clients from a shared on-link prefix also does not allow clients to keep addresses while roaming between links, so the proposed solution is not different in that regard. In addition to that, quite often different links have different security policies applied (for example, corporate internal network vs guest network), hence clients on different links need to use different prefixes.¶

10. Antispoofing and SAVI Interaction

Enabling the unicast Reverse Path Forwarding (uRPF) on the first-hop router interfaces towards clients provides the first layer of defence agains spoofing. If the malicious client sends a spoofed packet it would be dropped by the router unless the spoofed address belongs to a prefix delegated to another client on the same interface. Therefore the malicious client can only spoof addresses already delegated to another client on the same link or another client link-local address.¶

Source Address Validation Improvement (SAVI, [RFC7039]) provides more reliable protection against address spoofing. Administrators deploying the proposed solution on the SAVI-enabled infastructure 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]) for protecting link-local addresses and creating SAVI bindings for DHCPv6-PD assigned prefixes would prevent spoofing.¶

Some infrastructure devices do not implement SAVI as defined in [RFC7039] but perform other forms of address tracking and snooping for security or performance improvement purposes (e.g. ND proxy). This is very common behaviour for wireless devices (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 Neighbour Advertisements. In DHCPv6-PD environments, however, the attacker can only learn about other clients global addresses by listening to multicast DHCPv6 messages, which are not transmitted so often, and may not be received by the client at all because they are sent to multicast groups that are specific to DHCPv6 servers and relays.¶

11. Migration Strategies and Co-existence with SLAAC Using Prefixes From PIO

It would be beneficial for the network to explicitly indicate its support of DHCPv6-PD for connected clients.¶

In small networks (e.g. home ones), where the number of clients is not too high, the number of available prefixes becomes a limiting factor. If every phone or laptop in a home network would request an unique prefix suitable for SLAAC, the home network might run out of prefixes, if the prefix allocated to the CPE by its ISP is too small (e.g. if an ISP allocates /60, it would only allow 16 clients to request /64). So while the enterprise network administrator might want all phones in the network to request a prefix, it would be highly undesirable for the same phone to request a prefix when connecting 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 and only use the prefix delegated via DHCPv6-PD. Starting both SLAAC using the PIO prefix and DHCPv6-PD and deprecating that SLAAC addresses after receiving a delegated prefix would be very disruptive for applications. If the client continues to use addresses formed from the PIO prefix it would not only undermine the benefits of the proposed solution (see Section 12), but would also introduce complexity and unpredictability in the source address selection. Therefore the client needs to know what address assignment method to use and whether to use the prefix in PIO or not, if the network provides the PIO with A flag set.¶

To allow the network to signal DHCPv6-PD support, [I-D.collink-6man-pio-pflag] defines a new PIO flag, indicating that DHCPv6-PD is preferred method of obtaining prefixes.¶

12. Benefits

The proposed solution provides the following benefits:¶

The network devices 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.¶
If all clients connected to the given link support this mode of operation and can generate addresses from the delegated prefixes, there is no reason to advertise a common prefix assigned to that link in PIO with 'A' flag set. Therefore it is possible to remove the global shared prefix from that link and the router interface completely, so no global addresses are on-link for the link. This would lead to reducing the attack surface for Neighbor Discovery attacks described in [RFC6583].¶
DHCP-PD logs and first-hop routers routing tables provide complete information on IPv6 to MAC mapping, which can be used for forensics and troubleshooting. Such information is much less dynamic than ND cache and therefore it's much easier for an operator to collect and process it.¶
A dedicated prefix per client allows the network administrator to create per-device security policies (ACLs) even if the client is using temporary addresses. This mitigates one of the issues described in [I-D.ietf-opsec-ipv6-addressing].¶
The cost of having multiple addresses is offloaded to the clients. Hosts are free to create and use as many addresses as they need.¶
Fate sharing: all global addresses used by a given client are routed as a single prefix. Either all of them work or not, which makes the failures easier to diagnoze and mitigate.¶
Lower level of multicast traffic: less Neighbor Discovery ([RFC4861]) multicast packets, as there are only clients link-local addresses the routers need to resolve. Also, no DAD traffic except for clients' link-local addresses.¶
Ability to extend the network transparently. If the client uses SLAAC, delegating a prefix allows the client to provide connectivity to other hosts, like as it is possible in IPv4 with NAT.¶

13. Privacy Considerations

Eventually, if/when the vast majority of clients support the proposed mechanism, an eavesdropper/information collector might be able to correlate the prefix to the client. To mitigate the threat the client might implement a mechanism similar to SLAAC temporary extensions ([RFC8981]) but for delegated prefixes:¶

The client requests another prefix.¶
Upon receiving the new prefix the client deprecates all addresses from the old one.¶
After some time (shall it be T2 from IA_PD for the original prefix?) the client sends RELEASE for the old prefix.¶

14. IANA Considerations

This memo includes no request to IANA.¶

15. Security Considerations

A malicious or just misbehaving client might exhaust the DHCP-PD pool by sending a large number of requests with various DUIDs. This is not a new issue as the same attack might be implemented in DHCPv4 or DHCPv6 for IA_NA requests. To prevent 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.¶

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

Delegating the same prefix for 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. Appendix: Multiple Addresses Considerations

While a typical IPv4 host normally has only one IPv4 address per interface, an IPv6 device almost always has multiple addresses 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 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 4. Other common scenarios where the number of addresses per host's interface might increase significantly, include but are not limited to:¶

Devices running containers/namespaces: each container/namespace would have muliple 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 ULA [RFC4193]and non-ULA prefixes together or network 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's been observed that networks often do limit the number of on-link addresses per device, likely in an attempt to protect the network resources and prevent DoS attacks.¶

The most common scenario of network-imposed limitations is Neighbor Discovery (ND) proxy. Many enterprise-scale wireless solutions implement ND proxy to reduce 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 a single MAC such a table can contain. When the limit is exceeded the behaviour is implementation-dependent. Some vendors just fail to install N+1 address to the table. Other 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 implict signal, with traffic being silently dropped.¶

17. References

17.1. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC4193]: Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.
[RFC7084]: Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <https://www.rfc-editor.org/info/rfc7084>.
[RFC5460]: Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, DOI 10.17487/RFC5460, February 2009, <https://www.rfc-editor.org/info/rfc5460>.
[RFC6620]: Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, DOI 10.17487/RFC6620, May 2012, <https://www.rfc-editor.org/info/rfc6620>.
[RFC6877]: Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <https://www.rfc-editor.org/info/rfc6877>.
[RFC8168]: Li, T., Liu, C., and Y. Cui, "DHCPv6 Prefix-Length Hint Issues", RFC 8168, DOI 10.17487/RFC8168, May 2017, <https://www.rfc-editor.org/info/rfc8168>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8273]: Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, <https://www.rfc-editor.org/info/rfc8273>.
[RFC8415]: Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8981]: Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, <https://www.rfc-editor.org/info/rfc8981>.
[RFC8987]: Farrer, I., Kottapalli, N., Hunek, M., and R. Patterson, "DHCPv6 Prefix Delegating Relay Requirements", RFC 8987, DOI 10.17487/RFC8987, February 2021, <https://www.rfc-editor.org/info/rfc8987>.

17.2. Informative References

[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>.
[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>.
[I-D.collink-6man-pio-pflag]: Colitti, L., Linkova, J., Ma, X., and D. Lamparter, "Signalling DHCPv6 Prefix Delegation Availability to Hosts", Work in Progress, Internet-Draft, draft-collink-6man-pio-pflag-01, 6 July 2023, <https://datatracker.ietf.org/doc/html/draft-collink-6man-pio-pflag-01>.
[I-D.ietf-dhc-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-02, 10 July 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-dhc-rfc8415bis-02>.
[I-D.ietf-opsec-ipv6-addressing]: 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>.

Acknowledgements

Thanks to Nick Buraglio, Brian Carpenter, Gert Doering, David Farmer, Fernando Gont, Nick Hilliard, Bob Hinden, Martin Hunek, Erik Kline, David Lamparter, Andrew McGregor, Tomek Mrugalski, Pascal Thubert, Ole Troan, Eduard Vasilenko, Timothy Winters, Chongfeng Xie for the discussions, their input and all contribution.¶