]> Akamai Technologies

erik+ietf@nygren.org

Internet-Draft 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 Discussion of this document takes place on the Dynamic Host Configuration Working Group mailing list (dhcwg@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction IA_PD within DHCPv6 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 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. 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 . The Recommended Address option is only advisory and while clients MAY use these /128 addresses they are not required to do so.

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 when, and only when, they appear in all capitals, as shown here.

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.

Option Format The format of the Recommended Address option is: 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

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.

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.

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.

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

Relationship to Prefix Exclude Option Unlike 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.

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.

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 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 and as such may be easier for attackers to find while scanning IPv6 address space.

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 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 Privacy Addresses or similar scheme may chose to prefer those as a default source address.

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 Address	TBD	Recommended IPv6 address within an assigned prefix	This document

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550. Informative References This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6-based prefix delegation. The new mechanism updates RFC 3633. [STANDARDS-TRACK] DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts. This document describes the privacy issues associated with the use of DHCPv6 by Internet users. It is intended to be an analysis of the present situation and does not propose any solutions. This document outlines an approach utilizing existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of using a unique IPv6 prefix over a unique service-provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments. Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. [STANDARDS-TRACK] This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]

Acknowledgements Thank you to Lorenzo Colitti, Kasper Dupont, and others for their feedback and suggestions on this document.

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?

Change History NOTE TO RFC EDITOR: to be removed before publication.

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.

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.