Using DHCP-PD to Allocate /64 per Host in Broadcast Networks

Using DHCP-PD to Allocate /64 per Host in Broadcast Networks Google, LLC

Shibuya 3-21-3 Japan lorenzo@google.com

Google

1 Darling Island Rd Pyrmont NSW 2009 AU furry13@gmail.com furry@google.com

Google

Shibuya 3-21-3 Japan xiaom@google.com

OPS Area v6ops Working Group IPv6 SLAAC /64 DHCP-PD This document discusses the IPv6 deployment scenario when individual hosts connected to broadcast networks (like WiFi hotspots or enterprise networks) are allocated /64 subnets via DHCP-PD.

Introduction 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 stable global address and one privacy 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 would 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:

Increased 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 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.
An operator might need to know all addresses used by a given device in the past for forensics or troubleshooting purposes.
If an infrastructure device resources are exhausted, the device might drop some IPv6 addresses from the corresponding tables. The host, however, might be still using the address to send traffic. This leads to traffic blackholing and degraded customer experience.

discusses this aspect and explicitly states that IPv6 deployments SHOULD NOT limit the number of IPv6 addresses a host can have. However it seems inevitable that some limits might need to be imposed by the network in an attempt to protect the network resources and prevent DoS attacks (see ). Therefore it would be beneficial for IPv6 deployments to address the above mentioned issues while still allowing hosts to have multiple IPv6 addresses. One of the very promising approaches is allocating an unique /64 prefix per host (). The same principle has been actively used in mobile IPv6 deployments. However it's very uncommon in enterprise-style networks, where nodes are usually connected to broadcast segments/VLANs and each segment has a single /64 subnet assigned. This document expands the approach defined in to allocate an unique IPv6 /64 prefix per host using DHCP-PD.

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 when, and only when, they appear in all capitals, as shown here.

Design Principles Instead of all hosts on a given segment forming addresses from the same /64 assigned to that segment:

A host acts as DHCP-PD client and requests /64 via DHCPv6-PD by sending IA_PD.
The first-hop router acts as a DHCPv6-PD 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 /64 from a larger pool allocated for the given segment or the whole site.
The allocated /64 is installed into the first-hop router routing table as a route pointing to the client's link-local address. For the router and all other infrastructure devices that prefix is considered off-link, so no traffic to that prefix does not trigger any ND packets.
The host uses /64 to allocate addresses to its interfaces, containers etc.

Address Space Management demonstrates that if a network uses 10.0.0.0/8 to address hosts, /40 would be sufficient to provide each host 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 hosts). In that case such an enterprise would need /29 (48 - 6 - 13) to provide /64 to its devices. 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. Using /64 and not smaller subnet/longer prefix is required so the host can assign addresses using SLAAC.

Routing Considerations

First-Hop Routers Requirements 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 hosts the first hop router needs to implement DHCPv6-PD relay functions and meet the requirements defined in . 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 advertize the learned delegated leases as per requirement R-4 specified in .

Topologies with Multiple First-Hop Routers 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, advertize those prefixes to the network. That means that all relays the host 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 ). As per 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 () 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 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.

Preventing Routing Loops To prevent routing loops caused by traffic to unused addresses from the delegated /64, the client MUST drop all packets to such addresses (see the requirement WPD-5 in .

DHCPv6-PD Server Considerations The following requirements are applicable to the DHCPv6-PD server delegating prefixes to endhosts:

The server MUST follow recommendations on processing prefix-length hints. Specifically, the server MUST NOT delegate prefixes longer than /64 if the client sets the prefix-length field of the IA_PD option to 64. This is required so the host can use SLAAC to assign addresses from the delegated /64 to its interfaces or virtual instances. The client MAY ignore any delegated prefixes longer that /64.
Do not send the Server Unicast option to the client unless the network topology guarantees that no client is connected to a segment with multiple relays (see ).

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 segment or another host link-local address. Source Address Validation Improvement (SAVI, ) 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 ). Using FCFS SAVI () for protecting link-local addresses and creating SAVI bindings for DHCPv6-PD assigned prefixes would prevent spoofing.

Migration Strategies and Co-existence with SLAAC It would be beneficial for the network to explicitly indicate its support of DHCPv6-PD for hosts.

In small networks (e.g. home ones), where the number of devices is not too high, the number of available /64 becomes a limiting factor. If every phone or laptop in a home network would request an unique /64, the home network might run out of /64s, 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 devices to request /64). So while the enterprise network administrator might want all phones in the network to request /64, it would be highly undesirable for the same phone to request /64 when connecting to a home network.
When the network supports both /64 per host and SLAAC as address assignment methods, it's highly desirable for the host NOT to use SLAAC and only use the prefix delegated via DHCPv6-PD. Starting both SLAAC and DHCPv6-PD and deprecating SLAAC addresses after receiving a delegated prefix would be very disruptive for applications. If the host continues to use SLAAC addresses it would not only undermine the benefits of the proposed solution (see ), but would also introduce complexity and unpredictability in the source address selection. Therefore the host needs to know what address assignment method to use and whether to use SLAAC or not, if the network provides the PIO with A flag set.

To allow the network to signal DHCPv6-PD support a new PIO flag is proposed (link to the 6man draft will be added here after this draft is adopted).

Benefits The proposed solution provides the following benefits:

The network needs to scale to the number of devices, not the number of IPv6 addresses. The first-hop routers have a single /64 route per host pointing to the host's link-local address.
If all devices support this mode of operation, it is possible to remove the global /64 prefix from the interface completely, reducing the attack surface for Neighbor Discovery attacks described in .
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.
The cost of having multiple addresses is offloaded to the endpoint. Devices are free to create and use as many addresses as they need.
Fate sharing: all global addresses used by a given device are routed as a single /64. Either all of them work or not, which makes the failures easier to diagnoze and mitigate.

Applicability and Limitations The solution described in this document shouldn't be seen as an attempt to deprecate SLAAC. Delegating /64 provides an alternative for SLAAC rather than replacing it, so network administrators and OS developers have a choice. This design would substantially benefit some networks (see ), so running an additional service and allocation larger amount of address space is well justified. Examples of such networks include but are not limited to:

Large-scale networks where even 3-5 addresses per client might intorduce scalability issues.
Networks with high number of virtual hosts, so physical enpoints require multiple addresses.
Managed networks where extensive troubleshooting, host traffic logging or forensics might be required.

Smaller networks (like home ones) with smaller address space and lower number of clients, SLAAC might be a better and simpler option.

Privacy Considerations Eventually, if/when the vast majority of endpoints support the proposed mechanism, an eavesdropper/information collector might be able to correlate the prefix to the device. To mitigate the threat the host might implement a mechanism similar to SLAAC privacy extensions () but for delegated prefixes:

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

IANA Considerations This memo includes no request to IANA.

Security Considerations A malicious or just misbehaving host might exhaust the DHCP-PD pool by sending a large number of requests with various DUIDs. However this is not a new issue as the same attack might be implemented in DHCPv4 or DHCPv6 for IA_NA requests. A malicious host 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 host introduces privacy concerns. The proposed mitigation is discussed in . Spoofing scenarios and prevention mechanisms are discussed in .

References Normative References Informative References

Acknowledgements Thanks to Erik Kline, Pascal Thubert and Timothy Winters for the discussions, the input and all contribution.

Contributors