DHCPv6 Recommended IPv6 Address Option
draft-nygren-dhc-recommended-ipv6-address-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Erik Nygren | ||
| Last updated | 2025-07-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nygren-dhc-recommended-ipv6-address-01
Network Working Group E. Nygren
Internet-Draft Akamai Technologies
Intended status: Standards Track 4 July 2025
Expires: 5 January 2026
DHCPv6 Recommended IPv6 Address Option
draft-nygren-dhc-recommended-ipv6-address-01
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 5 January 2026.
Nygren Expires 5 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 . . . . . . . . . . . . . . . . . . . 5
5.1. Address Lifetime and Removal . . . . . . . . . . . . . . 5
6. Relationship to Prefix Exclude Option . . . . . . . . . . . . 5
7. Use-Cases and Suitability . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8
Appendix B. Open Questions . . . . . . . . . . . . . . . . . . . 8
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 8
C.1. Changes in -01 . . . . . . . . . . . . . . . . . . . . . 9
C.2. Prior to -00 . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
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 5 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. For
example, this allows the customer of a cloud provider to get a full
/64 for use by a host while also allowing the customer to configure a
specific /128 within that /64 that they can use for managing the
host.
The Recommended Address(es) continue to be here are for use by the
host, differentiating this from PD_EXCLUDE specified in [RFC6603].
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:
Nygren Expires 5 January 2026 [Page 3]
Internet-Draft DHCPv6 Recommended Address July 2025
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:
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
Nygren Expires 5 January 2026 [Page 4]
Internet-Draft DHCPv6 Recommended Address July 2025
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.
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.
5.1. Address Lifetime and Removal
The lifetime of the Recommended Addresses are associated with that of
the containing OPTION_IAPREFIX and its associated lease. Clients
SHOULD set the valid lifetime and preferred lifetime ([RFC4862]) for
Recommended Addresses to the remaining lifetime of the DHCPv6 lease
associated with the OPTION_IAPREFIX.
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 deprecate the address from
its interface, such as by setting the preferred-lifetime of the
address to 0 but leave the valid-lifetime as the remaining lifetime
of the associated DHCPv6 lease.
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.
Nygren Expires 5 January 2026 [Page 5]
Internet-Draft DHCPv6 Recommended Address July 2025
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. Use-Cases and Suitability
Cases where an operator may choose to deploy as an alternative to
using IA_NA:
* Client hosts only support IA_PD and not IA_NA but the operator
wishes to continue to have at least one known /128 address on the
host.
* Client hosts that support IA_PD (such as IPv6 CE routers) and
which also need an address on which they can be managed.
The alternatives for having both a IA_PD /64 and an IA_NA /128 for a
client host is to use either a larger /63 prefix (with half of it
only being used sparselyu for the /128) or to allocate the /64 and
/128 from disjoint space. This latter scenario increases FIB count.
Both of these alternatives require clients to support both IA_PD and
IA_NA.
8. 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.
9. 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.
Nygren Expires 5 January 2026 [Page 6]
Internet-Draft DHCPv6 Recommended Address July 2025
10. 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
11. References
11.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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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,
<https://www.rfc-editor.org/rfc/rfc8415>.
11.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, <https://www.rfc-editor.org/rfc/rfc3315>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/rfc/rfc4862>.
Nygren Expires 5 January 2026 [Page 7]
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,
<https://www.rfc-editor.org/rfc/rfc4941>.
[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,
<https://www.rfc-editor.org/rfc/rfc6603>.
[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
Considerations for DHCPv6", RFC 7824,
DOI 10.17487/RFC7824, May 2016,
<https://www.rfc-editor.org/rfc/rfc7824>.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/rfc/rfc8273>.
Appendix A. Acknowledgements
Thank you to Lorenzo Colitti, Kasper Dupont, 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 5 January 2026 [Page 8]
Internet-Draft DHCPv6 Recommended Address July 2025
C.1. Changes in -01
* Clarify handling of removal, as well as provide recommendations
for address lifetime.
* Add use-cases and suitability. Increase clarity on the use-cases
for hosts as well as the alternative.
C.2. 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 5 January 2026 [Page 9]