DHCPv6 Recommended IPv6 Address Option

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

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

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

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

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

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

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

10. References

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

Author's Address