Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Extracted elements (30)
Multiple DUID types exist because no single format is universally easy to generate and globally unique across all device categories: general-purpose computers can use DUID-LLT; vendor-provisioned devices use DUID-EN; devices with permanently attached interfaces but no writable storage use DUID-LL; devices with firmware UUIDs use DUID-UUID.
The Server Unicast option was obsoleted because it was not widely implemented and introduced security risks by allowing clients to bypass relay agents, which can perform access control and logging. Multicast-only client transmission is now the required model.
This document obsoletes RFC 8415 and removes two features: the IA_TA option (temporary address assignment) and the Server Unicast option with UseMulticast status code, both of which were not widely implemented. Implementations upgrading from RFC 8415 that previously sent Server Unicast options may continue to receive unicast client messages during transition.
A client SHOULD generate a random, unpredictable transaction ID for each new message and MUST leave the transaction ID unchanged in retransmissions. Predictable transaction IDs increase vulnerability to off-path attacks.
A DHCPv6 client MUST limit the rate of DHCP messages it transmits or retransmits on a per-interface basis. A token-bucket approach is recommended; a suggested default is 20 messages per 20 seconds.
A server MUST NOT assign an address that is reserved for another purpose, including addresses using a reserved IPv6 Interface Identifier. By default, server implementations SHOULD NOT generate predictable addresses.
Clients and servers MUST treat DUIDs as opaque values and MUST only compare them for equality. Implementations MUST NOT restrict DUIDs to the types defined in this document, as additional DUID types may be defined in the future.
Clients and servers using DUID-LLT MUST store it in stable storage and MUST continue to use it even if the generating network interface is removed. Devices without stable storage MUST NOT use DUID-LLT.
Clients MUST listen for DHCP messages on UDP port 546; servers and relay agents MUST listen on UDP port 547. Clients MUST send to destination port 547; servers MUST send Relay-reply messages to port 547 and client messages to port 546.
Clients MUST send all messages to the All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2); servers SHOULD NOT accept unicast traffic from clients. The Server Unicast option and UseMulticast status code are obsoleted by this document.
Clients, relay agents, and servers MUST NOT discard messages containing unknown options; such options MUST be ignored as if not present. A client or server MUST discard any received DHCP message with an unknown message type.
If a delegated prefix or a prefix derived from it is advertised for SLAAC, the advertised preferred and valid lifetimes MUST NOT exceed the corresponding remaining lifetimes of the delegated prefix. A client MUST NOT issue a DHCP Release on a delegated prefix while any of the address space delegated from it remains outstanding.
The DNS message compression scheme (RFC 1035 Section 4.1.4) MUST NOT be used when encoding domain names in DHCPv6 options. All domain names are encoded using the technique in RFC 1035 Section 3.1.
The IAID for a given IA use MUST be consistent across restarts of the DHCP client, maintained either through non-volatile storage or a deterministic algorithm. The IAID MUST be unique among IAIDs for that IA type on the client.
When T1 and/or T2 are 0, the client MUST choose its own renew/rebind times but MUST NOT transmit immediately. If multiple IA options were received, the client SHOULD coordinate timers to handle all IAs in one exchange.
DUIDs are stable identifiers that can be used to track clients across networks and over time. Clients concerned about privacy may change their DUID as specified in RFC 7844. Parsing a DUID to extract a link-layer address is unreliable and inadvisable due to growing adoption of privacy measures.
An Identity Association (IA) groups addresses (IA_NA) or delegated prefixes (IA_PD) assigned to a client under an IAID. Each IA_NA must be associated with exactly one interface; IA_PD may be associated with the client, a set of interfaces, or a single interface.
DHCPv6 defines 13 message types: SOLICIT (1), ADVERTISE (2), REQUEST (3), CONFIRM (4), RENEW (5), REBIND (6), REPLY (7), RELEASE (8), DECLINE (9), RECONFIGURE (10), INFORMATION-REQUEST (11), RELAY-FORW (12), RELAY-REPL (13).
HOP_COUNT_LIMIT is set to 8, defining the maximum hop count in a Relay-forward message. A relay agent MUST NOT forward a Relay-forward message whose hop-count field is greater than or equal to HOP_COUNT_LIMIT.
The DHCP Unique Identifier (DUID) uniquely identifies each DHCPv6 client and server. Four types are defined: DUID-LLT (link-layer + time), DUID-EN (vendor enterprise number), DUID-LL (link-layer only), and DUID-UUID (128-bit UUID). The DUID body is 1–128 octets plus a 2-octet type prefix.
The Reconfigure Key Authentication Protocol (RKAP) allows servers to authenticate Reconfigure messages to clients using a key established during initial message exchange. Reconfigure messages MUST be authenticated; unauthenticated Reconfigure messages MUST be discarded.
This document updates the IANA DHCPv6 Parameters registries, including: message types (values 1–13 defined here), option codes (defined in Section 21 and referenced registries), status codes, and DUID types (1–4 currently defined). Additional values may be assigned by IANA.
DHCPv6 messages are unauthenticated by default, making clients and servers vulnerable to rogue servers, rogue relay agents, and denial-of-service attacks. The Reconfiguration Key Authentication Protocol (RKAP) provides authentication for Reconfigure messages; use of IPsec or other security mechanisms between relay agents and servers is recommended.
Servers should implement rate limiting and sanity checks to protect against resource exhaustion from clients that send large numbers of requests. Server administrators should configure policies to restrict which clients receive leases.
Client retransmission: RT = IRT + RAND*IRT for first transmission; RT = 2*RTprev + RAND*RTprev for subsequent. RT is capped at MRT. Exchange fails when MRC transmissions are reached or MRD seconds elapse; if both are 0, client retransmits indefinitely. RAND is uniform in [-0.1, +0.1].
All time values for lifetimes, T1, and T2 are unsigned 32-bit integers in seconds; the value 0xffffffff represents 'infinity'. Setting a valid lifetime to 0xffffffff implies permanent assignment.
Client/server messages share a fixed header: 1-octet msg-type, 3-octet transaction-id, followed by variable-length options in network byte order with no padding or alignment beyond byte boundaries.
DUID-EN (type 2) encodes: 2-octet type (2), 4-octet IANA Private Enterprise Number as unsigned 32-bit integer, followed by vendor-assigned unique identifier of variable length.
DUID-LLT (type 1) encodes: 2-octet type (1), 2-octet IANA hardware type, 4-octet time (seconds since 2000-01-01 UTC mod 2^32), then variable-length link-layer address in canonical form.
Relay agent messages (Relay-forward and Relay-reply) contain: 1-octet msg-type, 1-octet hop-count, 16-octet link-address, 16-octet peer-address, followed by variable-length options. The fixed header is 34 octets.