skip to content

Why can a DHCPv4 reservation keyed on a laptop's MAC address fail to match, and when should it be keyed on the client identifier instead?

level: seniorimportance: nice to knowfreq 12%

answer

  1. which identifier does the server use
  2. client identifier beats chaddr
  3. type 255: IAID plus DUID
  4. boot loader and OS differ
  5. what survives a reinstall

basics

~20 s

RFC 2131 makes the server identify a client by its client identifier option when one is sent, using the MAC in chaddr only otherwise; RFC 4361 clients send a DUID-based identifier, so a MAC reservation may not match.

solid answer

~50 s

A reservation binds an address to an identifier, and RFC 2131 says the server MUST use the `client identifier` option when the client sends one and fall back to `chaddr` only when it does not. RFC 4361 goes further: clients MUST send a stable identifier of type 255 carrying an IAID and a DUID, not one built only from the MAC. A server may still honour an administrator's MAC reservation (RFC 4361 explicitly allows it for fixed addresses), but whether it does is the server's choice. Other mismatches: a network-boot loader and the operating system present different identifiers and get two leases; a docking-station adapter moves the MAC to another machine; per-network MAC randomisation changes the MAC itself. Key on whatever the device actually presents and keeps: the MAC for printers and appliances, the client identifier for managed laptops whose DUID is stable.

go deeper

for a junior

Recall that a reservation matches an identifier, and a DHCPv4 client may identify itself by something other than its MAC address.

for a middle

Explain RFC 2131's rule that the client identifier wins over chaddr, and the RFC 4361 type 255 IAID-plus-DUID format.

for a senior

Diagnose reservations that miss after docks, network boots, randomised MACs or reinstalls, and key each device class on what it presents.

for a principal

Decide one identity policy for DHCPv4 and DHCPv6 across device classes, balancing hardware-bound and software-bound identifiers.

## What a reservation actually keys on A **reservation** binds one address to one client. The question is what "one client" means to the server. RFC 2131 answers it precisely: - If the client sends the **`client identifier` option** (option 61), the server **MUST** use it to identify the client. - If it does not, the server **MUST** use the hardware address in the **`chaddr`** field. The client identifier is an **opaque key**: the server compares bytes, it does not interpret them. RFC 2132 suggests it may be a hardware type followed by a hardware address (type 1 is Ethernet), or type 0 followed by something else, such as a domain name. So a client that sends option 61 as type 1 followed by its MAC is identified by *those seven bytes*, not by `chaddr`, even though the MAC is the same. ## What RFC 4361 changed RFC 4361 found the MAC a poor identity. It updates RFC 2131 so that clients: 1. **MUST** send a `client identifier` option. 2. **MUST NOT** use one based solely on a hard-wired link-layer address. 3. Use **type 255**, followed by a 32-bit **IAID** (identity association identifier, one per interface) and a **DUID** (DHCP unique identifier, now defined in RFC 9915 for DHCPv6), so the same host can present the same identity to DHCPv4 and DHCPv6. On the server side, RFC 4361 keeps the rule that the client identifier wins, with one deliberate exception: a server **MAY** use administrator-supplied `chaddr` and `htype` values to give a fixed address *even if the client sends a client identifier*. Whether a MAC reservation matches a client that sends option 61 is therefore up to the server's implementation. ## Five ways a MAC reservation misses | Situation | What the server sees | |---|---| | Client sends a DUID-based client identifier | A key that is not the reserved MAC | | Network-boot loader, then the operating system | Two identities and two leases (RFC 4361 section 4.2) | | Laptop on a docking station's adapter | The dock's MAC, which follows the dock to the next desk | | Wired and wireless at once | Two interfaces, two identities, two addresses | | MAC randomisation per network | A MAC that matches nothing on the server | RFC 2131 itself warns that using `chaddr` "may cause unexpected results, as that identifier may be associated with a hardware interface that could be moved to a new client". For the boot-loader case, RFC 4361 suggests boot loaders request short leases and send `DHCPRELEASE` before handing over, and that the boot stage and the operating system share one DUID. ## Where the client identifier can miss too - **Reinstalls.** A DUID-LLT, the type RFC 9915 recommends for general-purpose devices, includes the time it was generated and must be kept in stable storage. Wipe that storage and the next DUID differs, so a client-identifier reservation stops matching though the hardware is unchanged. - **Opaque bytes.** The reservation must reproduce the exact identifier, type byte included, so it is copied from a real lease, not typed from the MAC. ## Seeing which identifier a client really sent RFC 6842 updated RFC 2131's rule that a server must not echo the client identifier: when the client sends one, the server **MUST return it unaltered** in its `DHCPOFFER`, `DHCPACK` and `DHCPNAK`, and the client **MUST** silently discard a reply whose identifier does not match its own. That helps diagnosis: a capture of the exchange, or the server's lease record, shows the exact identifier bytes, type byte included, that a reservation has to match. ## Choosing the key 1. **Read the identifier from a lease** the device actually obtained, not from a label or an asset sheet. 2. **Printers, badge readers, appliances**: these usually send no option 61, or one built from the MAC, and keep their hardware for life, so key on the MAC. 3. **Managed laptops and servers with a stable DUID**: key on the client identifier, which survives a NIC or dock change. 4. **Dual-stack hosts**: the DHCPv6 side reserves by DUID anyway, so a DUID-based DHCPv4 identifier keeps one identity across both. On the 600-device floor, that means MAC reservations for the printers, client-identifier reservations for the few laptops that need fixed addresses, and a check after every operating-system rebuild.

  • A reserved workstation network-boots, then its operating system starts, and the scope shows two leases for it. What happened, and what reduces the damage?
    The boot loader identified itself by one identifier, often the MAC, and the operating system by another, often DUID-based, so the server saw two clients. RFC 4361 suggests boot loaders request short leases and send DHCPRELEASE before handing over, and that both stages use one DUID; a reservation on the identifier the operating system presents is the one that matters.
  • Why does RFC 4361 still let a server honour a MAC reservation when the client sends a client identifier?
    Because the administrator supplied the MAC. RFC 4361 allows a server to use administrator-configured chaddr and htype values for a fixed address even when a client identifier is present, reasoning that if it causes a problem the administrator can remove the entry. Whether a given server does so is its own choice.

saying these in an interview costs you the question

  • The server always identifies DHCPv4 clients by their MAC address in chaddr.
  • A client identifier of type 1 plus the MAC is the same key as chaddr.
  • Client-identifier reservations survive an operating-system reinstall unchanged.
  • RFC 4361 tells clients to put their bare MAC address in the client identifier.
  • A MAC reservation follows the laptop, whichever dock or adapter it uses.