Clients transmit most messages to the well-known multicast address FF02::1:2 rather than a configured server address, so no pre-configuration of server addresses is required on clients. This zero-configuration discovery model is enabled by IPv6's mandatory multicast support.

ip, multicast

Multiple DUID types exist because no single globally-unique identifier suits all device classes: general-purpose hosts with writable storage use DUID-LLT for uniqueness; embedded devices with factory-assigned IDs use DUID-EN; devices with a permanent NIC but no writable storage use DUID-LL.

ip

DHCPv6 does not integrate with DHCPv4; the operational models are sufficiently different that integration is explicitly out of scope for RFC 3315. A separate extension document would be required if DHCPv6 were to carry IPv4 addresses or DHCPv4 configuration parameters.

ip

A client MUST leave the transaction ID unchanged in retransmissions of a message. The client SHOULD generate a random, hard-to-predict transaction ID for each new message to reduce vulnerability to spoofing by off-path attackers.

ip, security

A server MUST discard any Solicit, Confirm, Rebind, or Information-request message it receives with a unicast destination address, since these message types must be sent to the multicast address to be valid.

ip

A server MUST NOT assign an address that is reserved for another purpose — for example, a server MUST NOT assign reserved anycast addresses as defined in RFC 2526 from any subnet.

ip

Clients and servers MUST treat DUIDs as opaque values and MUST only compare DUIDs for equality; they MUST NOT interpret a DUID's internal structure, and MUST NOT restrict DUIDs to the types defined in this document since additional types may be defined in the future.

ip

Clients MUST discard any Reconfigure message that does not include a valid authentication option or that fails authentication validation. Reconfigure is the only DHCPv6 message type that mandates authentication.

ip, security

Devices using DUID-LLT MUST store the DUID-LLT in stable storage and MUST continue using it even if the network interface that generated it is removed. Devices without stable storage MUST NOT use DUID-LLT.

ip

Domain names carried in DHCP MUST NOT be stored in compressed form as described in RFC 1035 section 4.1.4; they must use the uncompressed wire encoding from RFC 1035 section 3.1 to ensure uniform decoding.

ip, dns

For any given use of an IA by a client, the IAID MUST be consistent across restarts of the DHCP client, maintained either by storing the IAID in non-volatile storage or by a deterministic algorithm that produces the same IAID given unchanged hardware configuration.

ip

When sending to All_DHCP_Relay_Agents_and_Servers, the client MUST use a link-local address assigned to the requesting interface as the IP source address. When sending unicast after receiving a Server Unicast option, the source MUST be an address suitable for the server to respond to.

ip

An Identity Association (IA) is a collection of addresses grouped under an IAID chosen by the client. IA_NA holds non-temporary addresses and IA_TA holds temporary addresses. Each IA must be associated with exactly one interface, and a binding is indexed by the tuple <DUID, IA-type, IAID>.

ip

DHCP clients listen on UDP port 546; servers and relay agents listen on UDP port 547. This replaces the broadcast-based port model of DHCPv4 with multicast delivery over these dedicated ports.

ip, udp

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), and RELAY-REPL (13). Types not listed are reserved for future use.

ip

Each DHCP client and server has exactly one DUID (DHCP Unique Identifier), which must be globally unique and stable over time. Three types are defined: DUID-LLT (link-layer plus time), DUID-EN (vendor enterprise number), and DUID-LL (link-layer only); max 128 octets excluding the 2-octet type code.

ip

The unsigned 32-bit integer value 0xffffffff represents 'infinity' for address lifetimes and the IA renewal timers T1 and T2, consistent with the convention established in RFC 2461. All time values in the protocol are unsigned integers.

ip

Two DHCP multicast addresses are defined: All_DHCP_Relay_Agents_and_Servers (FF02::1:2) is link-scoped for client-to-relay/server communication; All_DHCP_Servers (FF05::1:3) is site-scoped for relay-to-server communication when the relay does not know server unicast addresses.

ip, multicast

IANA maintains registries for DHCPv6 Status Codes and DUID types. Three DUID types are initially assigned: DUID-LLT (1), DUID-EN (2), DUID-LL (3). Status codes defined include Success (0), UnspecFail (1), NoAddrsAvail (2), NoBinding (3), NotOnLink (4), UseMulticast (5).

registry, ip

IANA maintains the DHCPv6 Option Codes registry. Options assigned in this document include: Client Identifier (1), Server Identifier (2), IA_NA (3), IA_TA (4), IA Address (5), Option Request (6), Preference (7), Elapsed Time (8), Relay Message (9), Authentication (11), Server Unicast (12), Status Code (13), Rapid Commit (14), User Class (15), Vendor Class (16), Vendor-specific Information (17), Interface-Id (18), Reconfigure Message (19), Reconfigure Accept (20).

registry, ip

IANA maintains the registry of DHCPv6 Message Types. This document assigns values 1–13 (SOLICIT through RELAY-REPL); all other values are reserved for future assignment.

registry, ip

DHCPv6 is vulnerable to attacks by rogue servers sending false configuration, clients exhausting address pools, and message replay. The Authentication option (section 22.11) provides integrity protection via the Delayed Authentication Protocol (HMAC-MD5 with a shared key) or the Reconfigure Key Authentication Protocol.

security, ip, crypto

Messages between relay agents and servers traverse potentially insecure infrastructure; they SHOULD be protected using IPsec with ESP in transport mode, providing both authentication and confidentiality. Shared authentication keys between relay agents and servers are recommended where IPsec is not feasible.

security, ip, ipsec

The Reconfigure Key Authentication Protocol uses a per-client key delivered by the server in a Reply message to authenticate subsequent Reconfigure messages via HMAC-MD5. This prevents unauthorized servers from triggering client reconfiguration, which is required since Reconfigure messages are unicast to the client.

security, ip, crypto

Client retransmission computes: initial RT = IRT + RAND*IRT; subsequent RT = 2*RTprev + RAND*RTprev, capped at MRT. RAND is uniform in [-0.1, +0.1]. Exchange fails when MRC retransmissions or MRD elapsed seconds are exceeded (whichever occurs first); if both are zero, retransmission continues indefinitely.

ip

Normal 4-message exchange: client SOLICITs to multicast, servers ADVERTISE; client chooses preferred server by preference value and sends REQUEST; server confirms with REPLY. A 2-message shortcut (SOLICIT with Rapid Commit → REPLY) is available when the server is configured for it and the client includes a Rapid Commit option.

ip

Client/server messages share a fixed header: msg-type (8 bits) identifying the message type, transaction-id (24 bits) for request/response correlation, followed by a variable-length options field. Options are serialized serially with no padding and no alignment beyond byte boundaries.

ip

DUID-EN encodes: type=2 (16 bits), IANA Private Enterprise Number (32 bits), and a vendor-assigned variable-length identifier unique to the device and assigned at manufacture. The generated DUID SHOULD be stored in non-erasable storage.

ip

DUID-LL encodes: type=3 (16 bits), hardware type (16 bits), and a variable-length link-layer address of a permanently attached interface. No time component is included; suitable for devices without writable non-volatile storage.

ip

DUID-LLT encodes: type=1 (16 bits), hardware type (16 bits), time in seconds since 2000-01-01 UTC modulo 2^32 (32 bits), and variable-length link-layer address in canonical form. Both time and hardware type are stored in network byte order.

ip

Relay agent messages contain: msg-type (8 bits), hop-count (8 bits), link-address (128 bits, used by server to identify the client's link), peer-address (128 bits, address of client or prior relay), and variable-length options. Both Relay-forward and Relay-reply share this format.

ip