DHCP messages utilize a fixed-format header followed by a variable-format options area.
Message Structure Overview All values in the message header and options are encoded in
network byte order. ; ; ;
Message Types This table lists the DHCPv6 message types.
Option Codes This table lists some of DHCPv6 Option codes. Full list can be for her IANA DHCPv6 Option Codes
DHCP Unique Identifier (DUID) option All devices participating in a DHCPv6 exchange, whether acting as a client or a server, must possess a single DHCP Unique Identifier (DUID) to establish a persistent identity within the network. This identifier is carried in the OPTION_CLIENTID (1) and OPTION_SERVERID (2) fields to ensure that transactions remain consistent even if hardware interfaces are swapped or addresses are reassigned. The DUID is designed to be permanent across reboots and reconfigurations, acting as the definitive anchor for the server’s binding database and the client’s server-selection logic.
DUID-LLT (Link-Layer Address Plus Time) DUID-LLT (Type 1) consists of: • DUID type (1) • Hardware type (IANA-assigned) • Time value (seconds since 00:00 UTC, 1 January 2000, modulo 2³²) •
link-layer address The time component reduces the likelihood of collisions if the same link-layer address is reused on another device. Devices using DUID-LLT must store the generated identifier in stable, non-volatile storage and continue using it even if the original network interface is removed. This type is recommended for general-purpose computing devices such as desktops, laptops, and printers, that provide writable persistent storage.
DUID-EN (Enterprise Number) DUID-EN (Type 2) is assigned by the device vendor and consists of: • DUID type (2) • Vendor’s IANA-assigned Private Enterprise Number • Vendor-defined unique identifier The identifier must be unique per device and stored in non-volatile storage. This type is commonly assigned during manufacturing or at first boot in virtualized environments.
DUID-LL (Link-Layer Address) DUID-LL (Type 3) consists of: • DUID type (3) • Hardware type •
link-layer address Unlike DUID-LLT, no time value is included. This type is intended for devices with a permanently attached network interface and no writable persistent storage. It should not be used if the permanence of the interface cannot be guaranteed.
DUID-UUID (Universally Unique Identifier) DUID-UUID (Type 4) uses a 128-bit UUID as its identifier. DUID-UUID consists of: • DUID type (4) •
Universally Unique Identifier Its usage and UUID selection rules are defined in RFC 6355. This type is suitable for devices that already store a UUID in firmware or platform configuration.
Option Request Option (ORO) The
Option Request Option (ORO), identified by OPTION_ORO (6), is the mechanism used by a DHCPv6 client to inform the server which configuration parameters it is interested in receiving. Rather than the server blindly pushing all available data, the client provides a list of option codes within the ORO to tailor the response to its specific needs. The Option Request Option is defined by IANA DHCPv6 Option Codes
Client Responsibility: The client MUST include an ORO in messages like Solicit, Request, Renew, and Rebind if it requires specific information (such as DNS recursive name servers or domain search lists).
Server Responsibility: The server uses the ORO as a guide. It should include the requested options in its response, provided those options are configured and appropriate for the client's link.
Common DHCPv6 Option Request Codes In a standard network deployment, a client typically includes the following option codes in its
OPTION_ORO (6) to ensure a functional IPv6 environment: == IETF standards ==