Internet-Draft MultAddrr February 2023
Colitti, et al. Expires 31 August 2023 [Page]
Workgroup:
v6ops Working Group
Internet-Draft:
draft-collink-v6ops-ent64pd
Published:
Intended Status:
Informational
Expires:
Authors:
L. Colitti
Google, LLC
J. Linkova, Ed.
Google
X. Ma, Ed.
Google

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

Abstract

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.

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 31 August 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 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 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 [I-D.linkova-v6ops-ipmaclimi]).

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 ([RFC8273]). 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 [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 forming addresses from the same /64 assigned to that segment:

4. Prefix Length Considerations

As per [RFC7421] /64 is the only prefix size that will allow the host to use SLAAC. As a result delegating a /64 prefix to the client allows the client to provide limitless addresses to IPv6 nodes connected to it (e.g., virtual machines, tethered devices), because all IPv6 nodes are required to support SLAAC. In other words, delegating /64 allows the hosts to extend the network arbitrarily, similarily to using NAT in IPv4. Chosing longer prefixes would require the host and any connected system to use some other form of address assignment and therefore would drastically limit applicability of the proposed solution.

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

5. Routing Considerations

5.1. 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 [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].

5.2. 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, advertise 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 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.

5.3. 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 Section 4.2 of [RFC7084].

6. DHCPv6-PD Server Considerations

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

7. 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, [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.

It should be noted that using DHCPv6-PD makes it harder for an attacker to select the spoofed source address. When all hosts are using the same /64 to form addresses, the attacker might learn addresses used by other hosts by listening to multicast Neighbor Solicitations and Neighbour Advertisements. In DHCPv6-PD environments, however, the attacker can only learn about other hosts global addresses by listening to multicast DHCPv6 messages, which are not transmitted so often.

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

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

9. Benefits

The proposed solution provides the following benefits:

10. 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 Section 9), 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:

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

11. 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 temporary extensions ([RFC8981]) but for delegated prefixes:

12. IANA Considerations

This memo includes no request to IANA.

13. 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 Section 11.

Spoofing scenarios and prevention mechanisms are discussed in Section 7.

14. References

14.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4941]
Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, , <https://www.rfc-editor.org/info/rfc4941>.
[RFC7084]
Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, , <https://www.rfc-editor.org/info/rfc7084>.
[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, , <https://www.rfc-editor.org/info/rfc6620>.
[RFC8168]
Li, T., Liu, C., and Y. Cui, "DHCPv6 Prefix-Length Hint Issues", RFC 8168, DOI 10.17487/RFC8168, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8987>.

14.2. Informative References

[RFC6583]
Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, DOI 10.17487/RFC6583, , <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, , <https://www.rfc-editor.org/info/rfc7039>.
[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, , <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, , <https://www.rfc-editor.org/info/rfc7513>.
[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, , <https://www.rfc-editor.org/info/rfc7348>.
[RFC7934]
Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, , <https://www.rfc-editor.org/info/rfc7934>.
[I-D.linkova-v6ops-ipmaclimi]
Linkova, J., "Minimizing Damage of Limiting Number of IPv6 Addresses per Host", Work in Progress, Internet-Draft, draft-linkova-v6ops-ipmaclimi-00, , <https://datatracker.ietf.org/doc/html/draft-linkova-v6ops-ipmaclimi-00>.
[I-D.dhcwg-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-dhcwg-dhc-rfc8415bis-00, , <https://datatracker.ietf.org/doc/html/draft-dhcwg-dhc-rfc8415bis-00>.

Acknowledgements

Thanks to Brian Carpenter, Gert Doering, Fernando Gont, Martin Hunek, Erik Kline, Pascal Thubert, Eduard Vasilenko, Timothy Winters for the discussions, the input and all contribution.

Contributors

Authors' Addresses

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