Multiple DUID types exist because the kind of globally unique identifier easy to generate varies widely across devices; some devices lack persistent storage and cannot use the time-based DUID-LLT, necessitating alternatives (DUID-EN for vendor-assigned identifiers, DUID-LL for devices needing no stored state).

ip

Prefix delegation (IA_PD) was deliberately designed to require no knowledge of the requesting router's internal topology on the part of the delegating router; only the client's identity is needed to select a prefix. This makes it suitable for ISP-to-subscriber delegation of prefixes that subscribers subnet internally.

ip

DHCPv4 and DHCPv6 are operationally distinct; the IETF consensus is that DHCPv4 (not DHCPv6) should be used when conveying IPv4 configuration information. For IPv6-only networks requiring IPv4 provisioning, RFC 7341 defines a transport mechanism to carry DHCPv4 messages encapsulated within DHCPv6.

ip

A client MUST include a Client Identifier option (carrying its DUID) in all messages. A client MUST NOT include a Server Identifier option when sending Solicit, Confirm, Rebind, or Information-request messages sent to the multicast address.

ip

A DHCP client that generates a DUID-LLT MUST provide an administrative interface that allows the existing DUID to be replaced with a newly generated DUID-LLT, to recover from the unlikely event of a collision.

ip

A Relay-forward message MUST include a Relay Message option encapsulating the client or nested relay message. Relay agents MUST increment the hop-count field before forwarding and MUST discard messages whose hop-count reaches or exceeds HOP_COUNT_LIMIT (8).

ip

Clients and servers MUST treat DUIDs as opaque values and MUST only compare DUIDs for equality. They MUST NOT restrict DUIDs to currently defined types, as additional types may be defined in the future.

ip

Clients MUST implement exponential backoff retransmission with randomization: RT = 2*RTprev + RAND*RTprev (approximately doubling with ±10% jitter), bounded by the message-specific MAX_RT. A client receiving no response within MAX_WAIT_TIME (60 s) MAY conclude no servers are available.

ip

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

ip

Domain names in DHCP MUST NOT be stored in compressed form as described in RFC 1035 Section 4.1.4; they must be encoded using the technique from RFC 1035 Section 3.1.

ip, dns

If a client uses a delegated prefix to configure addresses on itself or downstream nodes, the preferred and valid lifetimes of those addresses MUST NOT exceed the corresponding remaining lifetimes of the delegated prefix. This also applies to prefixes advertised for stateless address autoconfiguration.

ip

The DUID is a stable, globally unique identifier that enables tracking a client across links and over time. The IAID may also reveal device characteristics. Clients concerned about privacy should follow RFC 7844 (Anonymity Profiles for DHCP Clients), which permits the DUID to change to limit correlation.

ip, privacy

All time values for lifetimes, T1, and T2 are unsigned 32-bit integers expressed in seconds. The value 0xffffffff represents 'infinity'; a client with T1=0xffffffff never attempts to renew, and with T2=0xffffffff never attempts to rebind.

ip

DHCPv6 clients listen for messages on UDP port 546. Servers and relay agents listen on UDP port 547.

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

ip

DHCPv6 uses two reserved multicast addresses: 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.

ip, multicast

Identity Associations (IAs) are collections of leases assigned to a client, indexed by a client-chosen IAID. Three IA types are defined: IA_NA (non-temporary addresses), IA_TA (temporary addresses), and IA_PD (delegated prefixes). A server binding is indexed by the tuple <DUID, IA-type, IAID>.

ip

Key retransmission parameters: SOL_MAX_RT=3600 s, REQ_MAX_RT=30 s, REQ_MAX_RC=10, INF_MAX_RT=3600 s, REL_MAX_RC=4, HOP_COUNT_LIMIT=8, IRT_DEFAULT=86400 s, IRT_MINIMUM=600 s, MAX_WAIT_TIME=60 s.

ip

The DHCP Unique Identifier (DUID) identifies each DHCP participant and consists of a 2-octet type code followed by 1–128 octets of identifier. Four types are defined: DUID-LLT (1, link-layer plus time), DUID-EN (2, vendor enterprise number), DUID-LL (3, link-layer only), and DUID-UUID (4).

ip

Section 24 directs updates to the IANA DHCPv6 Parameters registry, covering message type codes (13 defined), option codes (25 defined in this document including IA_NA, IA_TA, IA_PD, Option Request, Rapid Commit, Authentication, etc.), status codes, and DUID types. Future assignments require IETF Review or Standards Action.

ip, registry

DHCPv6 is vulnerable to rogue server attacks (providing incorrect configuration) and denial-of-service attacks on a shared link. The Authentication option with the Reconfiguration Key Authentication Protocol (RKAP) provides client-server authentication; IPsec is recommended for securing communications between relay agents and servers.

ip, security

Address/prefix lifecycle: at T1 client sends Renew to the assigning server to extend lifetimes; at T2 (if Renew receives no reply) client sends Rebind to any available server. A server returning lifetimes of 0 signals inability to extend. If the valid lifetime expires without renewal, the client must cease using the address or prefix.

ip

Standard four-message exchange: client multicasts Solicit to ff02::1:2 → servers respond with Advertise → client selects server and sends Request → server responds with Reply containing confirmed addresses/prefixes/configuration. An accelerated two-message path is available if the client includes Rapid Commit in Solicit and the server honors it with an immediate Reply.

ip

DHCPv6 client/server messages have a fixed header with msg-type (1 octet) and transaction-id (3 octets), followed by a variable-length options field. All values are in network byte order; options are stored serially with no padding and no alignment beyond byte boundaries.

ip

DUID-EN format: 2-octet type field (value 2), 4-octet IANA Private Enterprise Number, followed by a variable-length vendor-assigned unique identifier.

ip

DUID-LLT format: 2-octet type field (value 1), 2-octet IANA hardware type, 4-octet time value (seconds since midnight UTC January 1, 2000, modulo 2^32), followed by a variable-length link-layer address.

ip

Relay-forward and Relay-reply messages share a common format: msg-type (1 octet), hop-count (1 octet), link-address (16 octets), peer-address (16 octets), followed by variable-length options.

ip