How DHCP Uses MAC Addresses, and Static Reservations in Practice

When DHCP leases an IP address to a client it needs an identifier to tell clients apart, so that a renewal returns the same address. In nearly every implementation that identifier is the client's MAC address. Following that chain explains a lot of otherwise puzzling allocation behaviour.

The four-step exchange

Acquiring an address takes four messages, commonly called DORA:

1. Discover. The client broadcasts a request carrying its MAC address in the hardware address field.
2. Offer. The server checks whether an address is reserved for that MAC. If so it offers the reservation, otherwise it picks a free address from the pool.
3. Request. The client broadcasts which offer it accepts.
4. Ack. The server confirms and writes a lease record, keyed on the MAC address.

Step two is the crucial one. The server recognises a MAC, not a device. Replace the network adapter and you are a new client with a new address. Move a disk into a different machine and the address changes too, as long as the adapter differs.

Configuring a static reservation

Implementations use different names for the same idea: this MAC always gets this IP.

ISC dhcpd:

host printer-01 {
    hardware ethernet 00:1b:a9:12:34:56;
    fixed-address 192.168.1.50;
}

dnsmasq is terser:

dhcp-host=00:1b:a9:12:34:56,192.168.1.50,printer-01

Home router interfaces usually call it address reservation or static DHCP, and just ask for a MAC and the desired IP.

Two traps are easy to fall into. First, keep reserved addresses outside the dynamic pool, or the server may already have leased one to someone else and you get a conflict. Second, after changing a binding the client has to re-acquire, because nothing changes until the old lease expires:

sudo dhclient -r eth0 && sudo dhclient eth0

The client identifier overrides the MAC

This is a frequent troubleshooting trap. DHCP lets a client send Option 61, the Client Identifier. When a client sends it, most servers match the lease on that option rather than on the MAC. The result is a reservation configured by MAC that simply never takes effect.

Windows and some Linux distributions send a client identifier by default. Either configure the reservation against the identifier, or disable the option on the client. dnsmasq can be told to ignore it outright:

dhcp-ignore-clid

What address randomisation changes

Once a phone enables WiFi private addressing it uses a different random MAC per SSID, and static reservations stop matching. Worse, some platforms rotate periodically, so one device keeps consuming fresh pool entries and a small pool can be exhausted.

The pragmatic split is this: devices that need fixed addresses, such as printers, cameras, servers and network gear, do not randomise anyway, so keep their reservations. Give up fixed addresses for personal mobile devices and rely on DNS names, or ask users to disable private addressing for that network. Background is in MAC address randomisation.

DHCP snooping, a security win along the way

A switch running DHCP snooping observes the whole allocation exchange and builds a trusted table of which MAC on which port holds which IP. That table is the foundation for Dynamic ARP Inspection and also blocks rogue DHCP servers. If your access switches support it, it is a high-value configuration.

When diagnosing allocation problems, taking a MAC from the lease table to the lookup page often identifies what kind of device is asking for an address.