| Internet-Draft | MultAddrr | September 2023 |
| Colitti, et al. | Expires 11 March 2024 | [Page] |
This document discusses the IPv6 deployment scenario when individual clients connected to broadcast networks (like WiFi hotspots or enterprise networks) are allocated unique prefixes via DHCP-PD.¶
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 11 March 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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.¶
Unlike IPv4, IPv6 allows (and often requires) hosts to have multiple addresses. 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 an IPv6-only network the device would need to have a dedicated 464XLAT address, which brings the total number of addresses to 4. If the network is multihomed and uses two different prefixes, or during graceful renumbering (when the old prefix is deprecated), or if an enterprise uses ULAs, the number of global addresses can easily double, bringing the total number of addresses to 7. Devices running containers/namespaces might need even more addresses per physical host. On one hand multiple addresses could be considered as a significant advantage of IPv6. On the other hand, however, they are sometimes seen as a drawback for the following reasons:¶
[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 do impose such limits, 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. 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.¶
It would be beneficial for IPv6 deployments to address the above mentioned scalability issues while still allowing devices to have multiple IPv6 addresses. One of the very promising approaches is allocating an unique IPv6 prefix per host ([RFC8273]). The same principle has been actively used in cellular IPv6 deployments ([RFC6459]). However it's very uncommon in enterprise-style networks, where nodes are usually connected to broadcast segments/VLANs and each segment has a single shared subnet assigned. This document expands the approach defined in [RFC8273] to allocate an unique IPv6 prefix per client using DHCPv6-PD.¶
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.¶
Node: a device that implements IP, [RFC4861].¶
Host: any node that is not a router, [RFC4861].¶
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 [RFC4861].¶
ND: Neighbor Discovery, [RFC4861].¶
SLAAC: IPv6 Stateless Address Autoconfiguration, [RFC4862].¶
DHCPv6-PD: DHCPv6 (xref target="RFC8415"/> mechanism to delegate IPv6 prefixes to clients.¶
Instead of all clients on a given segment forming addresses from the same shared prefix assigned to that segment:¶
DHCPv6 prefix delegation supports delegating prefixes of any size. However at the time of writing, the only prefix size that will allow the device to use SLAAC is 64 bits (see also [RFC7421]). As a result delegating a prefix suitable for forming addresses using 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]) In other words, it allows clients to extend the network arbitrarily, similarily to using NAT in IPv4 but with full support for end-to-end communication. Chosing longer prefixes would require the client and any connected system to use some other form of address assignment and therefore would drastically limit the applicability of the proposed solution. The extensive analysis provided in [RFC7421] is fully applicable to selecting the delegated prefix in the proposed deployment model.¶
Section 9.2 of [RFC7934] demonstrates that if a network uses 10.0.0.0/8 to address hosts, /40 would be sufficient to provide each client with /64. In multi-site networks the calculations might get more complex as each site 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 /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.¶
The design described in this document is targeted to large networks were the number of clients combined with multiple IPv6 addresses per client creates scalability issues. In such networks DHCPv6 servers are usually deployed as dedicated systems, so the first-hop routers act as DHCP relays. To delegate IPv6 prefixes to clients the first hop router needs to implement DHCPv6-PD relay functions and meet the requirements defined in [RFC8987].¶
In particular, if the same DHCPv6-PD pool is used for clients connected to multiple routers, dynamic routing protocols are required to propagate the routes to the allocated prefixes. Each relay needs to advertise the learned delegated leases as per requirement R-4 specified in Section 4.2 of [RFC8987].¶
Traditionally DHCPv6-PD is used in environments where a DHCPv6-PD client (a home CPE, for example) is connected to a single router which performs DHCPv6-PD relay functions. In the topology with redundant first-hop routers, all those routers need to snoop DHCPv6 traffic, install the delegated prefixes into its routing table and, if needed, advertise those prefixes to the network. That means that all relays the client is connected to must be able to snoop DHCPv6-PD traffic, in particular Reply messages sent by the server (as those messages contain the delegated prefix). Normally the client uses multicast to reach all servers or an individual server (see Section 14 of [RFC8415]). As per Section 18.4 of [RFC8415] the server is not supposed to accept unicast traffic when it is not explicitly configured to do, and unicast transmission is only allowed for some messages and only if the Server Unicast option ([RFC8415], Section 21.12) is used. Therefore, in the 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.dhcwg-dhc-rfc8415bis] deprecates the Server Unicast option exactly because it is not compatible with multiple relays topology). Therefore as long as the Server Unicast option is not used, all first-hop routers shall be able to install the route for the delegates prefix.¶
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:¶
To prevent routing loops caused by traffic to unused addresses from the delegated prefix the client MUST drop all packets to such addresses (see the requirement WPD-5 in Section 4.2 of [RFC7084]).¶
For security reasons, some networks do not allow communication between clients on the same link (or network segment), 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 subnet 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).¶
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:¶
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 segment 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 subnet 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.¶
It would be beneficial for the network to explicitly indicate its support of DHCPv6-PD for connected clients.¶
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.¶
The proposed solution provides the following benefits:¶
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 10), 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:¶
In smaller networks, such as home networks, with smaller address space and lower number of clients, SLAAC is a better and simpler option.¶
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:¶
This memo includes no request to IANA.¶
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 12.¶
Spoofing scenarios and prevention mechanisms are discussed in Section 8.¶
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.¶