Network Working Group E. Nygren Internet-Draft Akamai Technologies Intended status: Standards Track 3 July 2025 Expires: 4 January 2026 DHCPv6 Recommended IPv6 Address Option draft-nygren-dhc-recommended-ipv6-address-00 Abstract This document defines a new DHCPv6 option for communicating one or more recommended /128 IPv6 address to hosts within an assigned prefix. The Recommended Address option allows DHCPv6 servers to suggest specific IPv6 addresses that hosts should additionally use when configuring addresses within the assigned prefix. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Dynamic Host Configuration Working Group mailing list (dhcwg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dhcwg/. Source for this draft and an issue tracker can be found at https://github.com/enygren/draft-nygren-dhc-recommended-ipv6-address. 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 4 January 2026. Nygren Expires 4 January 2026 [Page 1] Internet-Draft DHCPv6 Recommended Address July 2025 Copyright Notice Copyright (c) 2025 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Recommended Address Option . . . . . . . . . . . . . . . . . 3 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Option Usage . . . . . . . . . . . . . . . . . . . . . . 4 4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . 4 5. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . 4 6. Relationship to Prefix Exclude Option . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 6 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 Appendix B. Open Questions . . . . . . . . . . . . . . . . . . . 7 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 7 C.1. Prior to -00 . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction IA_PD within DHCPv6 [RFC8415] allows clients such as hosts to request IPv6 prefixes, typically for delegation to downstream networks or interfaces. In scenarios such as Unique Prefix Per Host [RFC8273] the host is given the entire prefix and is free to use addresses from it as it sees fit. Nygren Expires 4 January 2026 [Page 2] Internet-Draft DHCPv6 Recommended Address July 2025 This document defines the Recommended Address option, which can be included within OPTION_IAPREFIX options to suggest one or more specific IPv6 addresses that clients should configure when using the associated prefix. These do not preclude the client from using other addresses within the prefix, such as for temporary addressing. This is intended for use in managed environments such as datacenters and cloud providers where the operator is configuring a host that they wish to manage or direct clients to. By providing a recommended address, the operator can encourage the host to have a particular /128 address that can be used for management purposes or as a service endpoint. At the same time, the remainder of the prefix is available for the host to use as it sees fit, such as for containers. The Recommended Address option is only advisory and while clients MAY use these /128 addresses they are not required to do so. 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. Recommended Address Option The Recommended Address option provides a mechanism for DHCPv6 servers to suggest one or more specific IPv6 addresses within an assigned prefix that host clients should use on the their interface. 3.1. Option Format The format of the Recommended Address option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_RECADDR | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | recommended-address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: Nygren Expires 4 January 2026 [Page 3] Internet-Draft DHCPv6 Recommended Address July 2025 option-code: OPTION_RECADDR (TBD by IANA) option-len: 17 (length of the option data in octets) recommended-address: A 128-bit IPv6 address that the server recommends the client use 3.2. Option Usage The Recommended Address option MUST only appear as a sub-option within an OPTION_IAPREFIX option. Multiple Recommended Address options MAY be included within a single OPTION_IAPREFIX option to suggest that multiple addresses within the prefix should be assigned by the host to its interface. The recommended-address field MUST contain an IPv6 address that falls within the prefix specified by the enclosing OPTION_IAPREFIX option. Servers MUST NOT include Recommended Address options with addresses outside the associated prefix. 4. DHCPv6 Server Behavior DHCPv6 servers MAY include OPTION_RECADDR within OPTION_IAPREFIX options in ADVERTISE, REPLY, and RENEW responses. Servers SHOULD validate that any recommended addresses fall within the prefix bounds of the enclosing OPTION_IAPREFIX option before including them in responses. Servers SHOULD avoid providing recommended addresses that would fall within those assigned to EUI-64 SLAAC addresses. Servers MUST NOT require clients to use recommended addresses, although operators of some tightly managed environments may set expectations that accepting connections on recommended address is required for proper operational function. Operators MUST NOT assume that clients will use only recommended addresses as source addresses from within the prefix as clients remain free to use the entire delegated prefix for outbound connections. 5. DHCPv6 Client Behavior DHCPv6 clients MAY process Recommended Address options received within OPTION_IAPREFIX options. Clients that do not understand or support the Recommended Address option MUST ignore it, as per standard DHCPv6 option processing rules. Nygren Expires 4 January 2026 [Page 4] Internet-Draft DHCPv6 Recommended Address July 2025 Clients configured to accept Recommended Addresses SHOULD configure the Recommended Addresses on a local host interface such that local services are reachable on that address. Prior to using the address, clients MUST validate that recommended address(es) fall within the bounds of the associated prefix and any outside MUST be ignored. If a client had previously received a Recommended Address for a prefix but an subsequent advertisement for the same OPTION_IAPREFIX no longer contains it, the client SHOULD remove the address from its interface. Clients MAY also assign SLAAC addresses such as temporary addresses within the prefix. While clients MAY use Recommended Addresses as a preferred source address they are not required to do so. 6. Relationship to Prefix Exclude Option Unlike [RFC6603] which specifies a sub-prefix to exclude from the delegated prefix, Recommended Addresses propose one or more recommended addresses that the host client should use. Servers MUST NOT suggest a recommended address within a OPTION_PD_EXCLUDE prefix. To be removed prior to publication: An alternate proposal was to use IA_NA within an excluded prefix, but that was thought to be too messy. 7. Security Considerations The Recommended Address option is subject to the same authentication and security mechanisms as the base DHCPv6 protocol. Deployments requiring authentication SHOULD use DHCPv6 authentication mechanisms [RFC3315] or secure the DHCPv6 communication channel. Recommended Addresses may have less entropy (or otherwise be more predictable) than those assigned via other mechanisms such as [RFC4941] and as such may be easier for attackers to find while scanning IPv6 address space. 8. Privacy Considerations Recommended Addresses are primarily intended for use in managed environments such as data centers and cloud providers. This option extends upon DHCPv6 so has similar privacy properties to other modes of DHCPv6 such as IA_NA. See [RFC7824] for an extensive discussion of these properties. As Recommended Addresses are under Nygren Expires 4 January 2026 [Page 5] Internet-Draft DHCPv6 Recommended Address July 2025 server control and may have less entropy, they may be more predictable within the /64 than addresses under the clients control to select. Clients configured to use [RFC4941] Privacy Addresses or similar scheme may chose to prefer those as a default source address. 9. IANA Considerations This document requests IANA to assign a new DHCPv6 option code for the Recommended Address option from the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry. +=============+=======+===========================+===========+ | Option Name | Value | Description | Reference | +=============+=======+===========================+===========+ | Recommended | TBD | Recommended IPv6 address | This | | Address | | within an assigned prefix | document | +-------------+-------+---------------------------+-----------+ Table 1 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, November 2018, . 10.2. Informative References [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . Nygren Expires 4 January 2026 [Page 6] Internet-Draft DHCPv6 Recommended Address July 2025 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, . [RFC6603] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, DOI 10.17487/RFC6603, May 2012, . [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy Considerations for DHCPv6", RFC 7824, DOI 10.17487/RFC7824, May 2016, . [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, . Appendix A. Acknowledgements Thank you to Lorenzo Colitti and others for their feedback and suggestions on this document. Appendix B. Open Questions NOTE TO RFC EDITOR: to be removed before publication. Some open questions for discussions include: * Should we allow prefixes in-addition to /128 along with labels for those prefixes? For example to signal things like which ranges should be sub-delegated for use by Docker, etc? * What name should we use for this option? OPTION_RECADDR? OPTION_RECOMMENDED_ADDRESS? * When should we use "client" vs "host"? * Do we need more description of use-cases and purpose? Appendix C. Change History NOTE TO RFC EDITOR: to be removed before publication. Nygren Expires 4 January 2026 [Page 7] Internet-Draft DHCPv6 Recommended Address July 2025 C.1. Prior to -00 * Removed priority and made it very clear that this is in-addition to temporary addresses and does not require clients to use these as a source address. Author's Address Erik Nygren Akamai Technologies Email: erik+ietf@nygren.org Nygren Expires 4 January 2026 [Page 8]