Internet-Draft MultAddrr November 2022
Colitti & Linkova Expires 14 May 2023 [Page]
v6ops Working Group
Intended Status:
Best Current Practice
L. Colitti
Google, LLC
J. Linkova, Ed.

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


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.

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

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 14 May 2023.

Table of Contents

1. 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:

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.

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. Design Principles

Instead of all hosts on a given segment using the same /64 assigned to that segment:

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

4. 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:

5. Benefits

The proposed solution provides the following benefits:

6. Applicability and Limitations

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

7. IANA Considerations

This memo includes no request to IANA.

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

9. References

9.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, , <>.
Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix per Host", RFC 8273, DOI 10.17487/RFC8273, , <>.

9.2. Informative References


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


Authors' Addresses

Lorenzo Colitti
Google, LLC
Shibuya 3-21-3,
Jen Linkova (editor)
1 Darling Island Rd
Pyrmont NSW 2009