Why does a DHCPv6 server identify clients by DUID rather than MAC address, and why can a reinstalled machine get a new address?
answer
- no hardware field in the header
- one identifier per device
- opaque, compare only
- link-layer address plus a timestamp
- binding keyed with the IAID
basics
~20 sDHCPv6 messages carry no hardware-address field; a client identifies itself with a DUID, a stable opaque identifier stored on the device. A reinstall usually wipes the stored DUID-LLT and generates a new one, so the server sees a new client.
solid answer
~50 sA DHCPv6 header is only a message type and a 3-octet transaction ID; there is no `chaddr` as in DHCPv4. Identity travels in the Client Identifier option as a **DUID** (DHCP Unique Identifier): one per device, stable, and treated by servers as opaque bytes compared only for equality. RFC 9915 defines DUID-LLT (link-layer address plus generation time), DUID-EN (enterprise number plus vendor ID) and DUID-LL (link-layer address only), and RFC 6355 adds DUID-UUID. Bindings are keyed by `<DUID, IA-type, IAID>`. A general-purpose computer normally uses DUID-LLT, kept in stable storage. A fresh operating-system install generates a new one with a new timestamp, so the same hardware presents a different DUID. The server then allocates a fresh address, and the old binding lingers until its valid lifetime runs out. For the MAC, rely on the Client Link-Layer Address option a first-hop relay adds, not on parsing the DUID.
go deeper
Recall that DHCPv6 identifies a client by a DUID in the Client Identifier option, not by its MAC address, and that each device has one DUID.
Explain the DUID types, why DUID-LLT includes a timestamp, and how the DUID combines with the IA type and IAID to key a server's binding.
Diagnose new addresses after reinstalls, duplicate identities from cloned images, and broken MAC-based reservations, and use the relay's Client Link-Layer Address option instead of parsing DUIDs.
Decide what your address-management records key on, DUID or relay-supplied link-layer address, given reinstalls, privacy features and image cloning.
## Identity without a hardware field In DHCPv4 the client's hardware address sits in a fixed header field (`chaddr`), and many servers key leases and reservations on it. A **DHCPv6** message has no such field. The client/server header defined in RFC 9915 §8 is a 1-octet `msg-type`, a 3-octet `transaction-id`, and then options. A client identifies itself with a **DUID** (DHCP Unique Identifier) carried in the **Client Identifier** option (option 1). A server identifies itself the same way, in the **Server Identifier** option (option 2). ## The rules RFC 9915 sets for a DUID - **One per device.** Each DHCP client and server has exactly one DUID, shared by all its interfaces. Interfaces are told apart by the IAID, described below. - **Opaque.** Clients and servers MUST compare DUIDs only for equality and SHOULD NOT interpret their contents in any other way. - **Stable.** A DUID SHOULD NOT change over time, even when the device's network hardware changes. - **Shape.** A 2-octet type code followed by 1 to 128 octets of identifier. The point is an identifier that outlives a replaced network card and does not depend on which interface the client happens to use. ## The four DUID types | Type | Name | Contents | Intended for | |---|---|---|---| | 1 | **DUID-LLT** | hardware type, a timestamp, one interface's link-layer address | general-purpose computers and devices with writable stable storage | | 2 | **DUID-EN** | the vendor's 4-octet Private Enterprise Number plus a vendor-assigned ID | devices whose maker assigns an ID at manufacture, or a VM image at creation or first boot | | 3 | **DUID-LL** | hardware type and a link-layer address | devices with a permanently attached interface and no writable stable storage | | 4 | **DUID-UUID** | a 128-bit UUID (RFC 6355) | devices with a UUID in their firmware | The DUID-LLT timestamp counts seconds since midnight UTC on 1 January 2000, modulo 2^32. Mixing a time into the identifier makes collisions unlikely even when a network card moves from one machine to another. RFC 9915 requires a client using DUID-LLT to keep it in stable storage, to go on using it even if the source interface is removed, and to offer an administrative way to replace it. ## The IAID: the other half of the key A server records a lease in a **binding** keyed by the tuple `<DUID, IA-type, IAID>`. The **IAID** (identity association identifier) is a 4-octet number the client chooses. It must be unique among the client's IAs of the same type and stay the same across client restarts. An address IA (`IA_NA`) belongs to exactly one interface, so a two-interface host uses two IAIDs under one DUID. An `IA_NA` with IAID 0 and an `IA_PD` with IAID 0 are separate, because each IA type has its own number space. ## Why a reinstalled machine gets a new address 1. On first install, a laptop generates a DUID-LLT from its Ethernet address and the current time and saves it to disk. 2. The server binds `2001:db8:10::25` to that DUID with `IA_NA`, IAID 0. 3. The disk is wiped and the operating system reinstalled. The stored DUID is gone, so the new install generates a fresh DUID-LLT from the same Ethernet address but a new timestamp. 4. The server sees a DUID it has never met, treats it as a new client, and assigns a different address. The old binding stays until its valid lifetime expires and holds an address nobody uses in the meantime. Dual-boot machines show the same effect, because each operating system may keep its own DUID. The reverse problem comes from virtual machines cloned from an image that already holds a DUID. They present one identity, and with the same IAID the server cannot tell them apart. RFC 9915 expects a virtual machine's DUID-EN to be assigned when its image is created or first booted, and requires each DUID-EN identifier to be unique to the device using it; a clone carrying its template's DUID breaks that rule. ## What this means for operators - **Reservations keyed to a DUID** survive a network-card swap but not a reinstall. Plan to update them, or key them on something the reinstall does not change. - **Do not parse a MAC out of a DUID.** RFC 9915 §11 calls that unreliable: the interface may have changed since the DUID was generated, and privacy measures increasingly vary the identifiers a client presents. The DUID type may not even contain a link-layer address. - **Ask the relay instead.** RFC 9915 says a first-hop relay agent SHOULD insert the **Client Link-Layer Address** option (option 79, RFC 6939), giving the server the MAC as the network saw it. - **Expect pool waste after mass reinstalls.** Each orphaned binding holds its address for the rest of its valid lifetime, so short lifetimes recover space sooner.
- What is the IAID, and why does a DHCPv6 server need it in addition to the DUID?The IAID is a 4-octet number the client chooses for each identity association. It is unique among the client's IAs of that type and stays the same across restarts. Because one DUID covers the whole device, the IAID lets one client hold separate address sets per interface, plus a prefix delegation. The server keys each binding by `<DUID, IA-type, IAID>`.
- What goes wrong when many virtual machines are cloned from an image that already contains a DUID?The clones present the same DUID, and usually the same IAID, so the server cannot tell them apart. It may hand them the same binding, and then duplicate address detection fails on all but one, which send Decline. RFC 9915 requires each DUID-EN identifier to be unique to the device using it, so clones need their own. A DUID-LLT client must offer an administrative way to generate a new one.
A DUID-LLT is like a membership card issued once and kept in your wallet: the club recognises the card, not your face. Lose the wallet in a reinstall and you are signed up again as a new member with a new card, though nothing about you has changed.
saying these in an interview costs you the question
- A DUID is just the client's MAC address written in a different format.
- A server can reliably read the client's MAC address out of any DUID.
- Each network interface on a host has its own DUID.
- A reinstalled host keeps its DHCPv6 address because its hardware did not change.
- DHCPv6 messages carry the client hardware address in a header field, as DHCPv4 does.