rfc-8947

Link-Layer Address Assignment Mechanism for DHCPv6

B. Volz, T. Mrugalski, CJ. Bernardos
date2020-12 streamIETF areaint wgdhc statusPROPOSED STANDARD pages18 canonicalhttps://www.rfc-editor.org/rfc/rfc8947 doi10.17487/RFC8947
In certain environments, e.g., large-scale virtualization deployments, new devices are created in an automated manner. Such devices may have their link-layer addresses assigned in an automated fashion. With sufficient scale, the likelihood of a collision using random assignment without duplication detection is not acceptable. Therefore, an allocation mechanism is required. This document proposes an extension to DHCPv6 that allows a scalable approach to link-layer address assignments where preassigned link-layer address assignments (such as by a manufacturer) are not possible or are unnecessary.

Extracted elements (31)

design-rationale §5

Clients are expected to use the Rapid Commit option to reduce the exchange to two messages (Solicit/Reply) when possible, since in many deployment scenarios (e.g., large-scale virtualization) speed and efficiency of address assignment are important.

ip

design-rationale §1

DHCPv6 was chosen as the allocation mechanism because it can already allocate various resource types (addresses, prefixes, options) and has an existing infrastructure including server/client implementations, relay infrastructure, and supportive solutions like leasequery and failover.

ip, registry

design-rationale §6

The mechanism operates on address blocks rather than single addresses because a hypervisor may need thousands of addresses; listing each address individually (as done for IPv6 IA_NA/IA_PD) would not scale. A single address is represented as an address block of size 1.

ip

interoperability-note §8

A client operating in direct client mode that changes its link-layer address on an interface SHOULD follow Section 7.2.6 of RFC 4861 to promptly notify neighbors of the new address via Neighbor Discovery.

ip

interoperability-note §5

Confirm and Information-request messages are not used in link-layer address assignment. Decline is technically not needed except when a client must reject an assignment that would cross the 2^42-bit address boundary.

ip

interoperability-note §8

Servers that do not support the IA_LL option will ignore it and not return it in Advertise or Reply messages. Clients that send IA_LL options MUST treat a missing IA_LL in the server response as if the server returned NoAddrsAvail status for those IA_LL options.

ip

normative-requirement §8 MUST NOT

A client MUST NOT use resources returned in an Advertise message for anything other than selecting a server and composing the subsequent Request message; resources are only usable when returned in a Reply message.

ip

normative-requirement §10 MUST

A client MUST release an address block in its entirety; partial release of a block is not permitted. If the released address is the one the client is currently using, it MUST stop using it before sending the Release message.

ip

normative-requirement §7 MUST

A client MUST send an LLADDR option encapsulated in an IA_LL option, specifying link-layer-type and link-layer-len. For link-layer types 1 (Ethernet) and 6 (IEEE 802), the client sets link-layer-address to all zeroes if it has no hint, or to a specific address to request a particular block.

ip

normative-requirement §4.2 MUST NOT

A client operating in direct client mode that does not have a globally unique link-layer address on any of its interfaces MUST NOT use a link-layer-based DHCP Unique Identifier (DUID).

ip, security

normative-requirement §5 SHOULD

Clients implementing this mechanism SHOULD use the Rapid Commit option to obtain addresses with a two-message exchange when possible.

ip

normative-requirement §9 MUST

If a client needs additional addresses beyond an existing IA_LL (e.g., a hypervisor spawning more VMs), it MUST send an IA_LL option with a different IAID to create a new container rather than expanding an existing one.

ip

normative-requirement §11.1 MUST

If a client receives an IA_LL with T1 greater than T2 and both values are greater than 0, the client MUST discard the IA_LL option and process the rest of the message as though the server had not included it.

ip

normative-requirement §8 MUST

If the server is unable to provide any addresses for an IA_LL, it MUST return the IA_LL option containing a Status Code option with status NoAddrsAvail.

ip

normative-requirement §11.1 MUST

In messages from client to server, the T1 and T2 fields in the IA_LL option MUST be set to 0; the server MUST ignore any values in these fields from the client.

ip

normative-requirement §11.2 MUST

In messages from client to server, the valid-lifetime field in the LLADDR option MUST be set to 0; the server MUST ignore any received value. The client MUST use the valid-lifetime returned by the server in a Reply.

ip

normative-requirement §12 SHOULD

Server administrators SHOULD follow IEEE 802 specifications regarding unicast address pools for assignment; only address space reserved for local use or authorized by the assignee may be used.

ip

normative-requirement §12 MUST NOT

Servers MUST NOT allow administrators to configure address pools that cross the 2^42-bit boundary (for 48-bit MAC addresses) to avoid issues with the special bits in the first octet. Clients MUST reject assignments where the assigned block would cross this boundary by declining the allocation.

ip

normative-requirement §11.2 MUST

The link-layer-type field in the LLADDR option MUST be a valid hardware type assigned by IANA as registered in the 'Hardware Types' registry.

ip, registry

normative-requirement §9 MUST NOT

Upon renewal, the server MUST NOT shrink or expand the address block. Once assigned with a non-zero valid lifetime, the block's size, starting address, and ending address MUST NOT change.

ip

privacy-consideration §15

In direct client mode, the assigned link-layer address is exposed to all link observers. Peers observing the DHCP exchange can correlate the client's DUID with the assigned address, enabling tracking. RFC 7844 anonymity profiles can mitigate this.

privacy, ip

privacy-consideration §15

Sequential address assignment by servers or hypervisors may leak information about the number and timing of device creations. Unlike IPv6 address/prefix delegation, this concern is generally link-local rather than Internet-wide.

privacy, ip

protocol-element §11.1

The IA_LL (Identity Association for Link-Layer Addresses) option (OPTION_IA_LL, code 138) is a container option used to carry an identity association for link-layer address allocation, including T1/T2 renewal timers and one or more LLADDR options.

ip, registry

protocol-element §11.2

The LLADDR (Link-Layer Addresses) option (OPTION_LLADDR, code 139) represents an address block within an IA_LL. It encodes the link-layer type, address length, starting address, and the number of additional consecutive addresses (extra-addresses) in the block.

ip, registry

registry §13

IANA assigned OPTION_IA_LL with option code 138 in the 'Option Codes' subregistry of the DHCPv6 registry. Client ORO: No; Singleton Option: No.

registry, ip

registry §13

IANA assigned OPTION_LLADDR with option code 139 in the 'Option Codes' subregistry of the DHCPv6 registry. Client ORO: No; Singleton Option: No.

registry, ip

security-consideration §14

DHCP lacks end-to-end encryption between clients and servers, making hijacking, tampering, and eavesdropping attacks possible. If not all devices on a link use this mechanism, address collisions may occur—this risk exists regardless of DHCP.

security, ip

security-consideration §14 SHOULD

Server implementations SHOULD configure limits on the maximum number of addresses allocatable to a single client (per request and in total) to prevent resource exhaustion, though a malicious client can still spoof multiple client identities to bypass such limits.

security, ip

state-machine §5

Address assignment lifecycle: (1) Client sends Solicit with IA_LL+LLADDR; (2) Server responds with Advertise (or Reply if Rapid Commit); (3) Client sends Request copying LLADDR from Advertise; (4) Server assigns and sends Reply; (5) Client uses addresses, renews at T1 via Renew, rebinds at T2 via Rebind, releases via Release when done.

ip

wire-format §11.1

The IA_LL option format: 2-octet option-code (138), 2-octet option-len (12 + IA_LL-options length), 4-octet IAID (unsigned integer), 4-octet T1 (seconds), 4-octet T2 (seconds), followed by variable-length IA_LL-options.

ip

wire-format §11.2

The LLADDR option format: 2-octet option-code (139), 2-octet option-len (12 + link-layer-len + LLaddr-options length), 2-octet link-layer-type (IANA hardware type), 2-octet link-layer-len, variable link-layer-address field, 4-octet extra-addresses (unsigned integer), 4-octet valid-lifetime (seconds), followed by LLaddr-options.

ip