]> 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

OPS Area v6ops Working Group IPv6 SLAAC /64 DHCP-PD This document discusses 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 thenetwork is multihomed and uses two different prefixes, or during graceful renumbering (when the old prefix is deprecated), of if an enterprise uses ULAs, the number of global addresses can easily double, brining the total number of addresses to 7. Devices running containers/namespaces would need even more addresses per physical host. on one hand this could be considered as a significant advantange of IPv6. On one hand, however, multiple addresses are seen as a drawback for the following reasons:

• Increased number of addresses introduces scalability issues on the network infrastructure. Network devices need 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 infrastrcuture 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.

RFC7934 discusses this aspect and explicitly states that IPv6 deployments SHOULD NOT limit number of IPv6 addresses a host can have. However it seems inevitable that some limits might need to be imposed by the network in attempt to protect the network resources and prevent DoS attacks (see draft-linkova-v6ops-ipmaclimi). Therefore it would be beneficial for IPv6 deployments to address the abovementioned issues while still allowing hosts to have multiple IPv6 addresses. One of the very promising approaches is allocating an unique /64 prefix per host ([RFC8273]). The same principle has been actively used in mobile IPv6 deployments. However it's very uncommon in enterprise-style networks. This document expands the approach defined in [RFC8273] 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 using 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 send 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 ifrastructure 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, containters etc.

Using /64 allows the host to assign addresses to virtual instances using SLAAC.

Migration Strategies and Co-existence with SLAAC There are scenarios when it might be undesirable for a host to request an unique prefix. As the main goal of this approach is to address scalability issues, the solution is aimed for large networks (enterprises, conference hotspots etc). 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. Therefore it's desirable for the network to indicate the support of the proposed mechanism. As it's a -00 draft, we do not have details for such mechanism yet, just a few rough ideas:

• A new RA (or, better, PIO flag) to indicate "don't use this PIO for SLAAC, ask for /64 via PD". Legacy devices would not recognize it and contibue to use that /64 for SLAAC.
• Some flags/options in DHCPv6 used like Option 108 in DHCPv4 - the client sends it and only accepts /64 if the server returns that option back. It would prevent /64 to be allocated for the clients in home networks, unless the CPE is explicitly configured to support this new mechanism.
• Some other crazy ideas?

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 global /64 prefix from the interface completely, reducing the attack surface for Neighbor Discovery attacks described in RFC6583.
• DHCP-PD logs and first-hop routers roting tables provide complete information on IPv6 to MAC mapping, which can be used for forensics and troiubleshooting. Such information is much less dynamic that 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 are easier to diagnoze and mitigate.

Applicability and Limitations What's unclear at this point (AI for Jen: sort this out):

• How to deal with multiple routers in active/active scernario? Need to test if they are capable of advertize DHCP-PD routes to its neighbors. What happens if the first-hop router fails and switchover occurs?
• Interaction with SAVI?
• [Do math for how many prefixes/addresses needed and if we are going to run out of addresses again ;)]

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 large number of requests with various DUIDs. However this is not a new issue as the same attach might be implemented in DHCPv4 or DHCPv6 for IA_NA requests.

References Normative References Informative References

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

Contributors