DHCP lease process

The DHCP article already named the four messages a device exchanges to get an address — Discover, Offer, Request, Acknowledge — and it said plainly that walking that exchange hop by hop, field by field, was a job for later in the course. This is later. The DNS resolution walk covered how a name turns into an address once a device already has one of its own; this group of articles covers the step that has to happen first, the one that gets a device onto the network at all.

Four short articles, one per message, follow this one — Discover, Offer, Request, Acknowledge — each taking apart what that specific packet contains and why. Before splitting into those, two things are worth settling here: the header format every one of those packets shares, and the fact that DORA is really a state machine with more than four states, not just four packets in a row.

One packet format, reused for every message

DHCP inherited its wire format from BOOTP, its 1985 predecessor, and never changed it — every Discover, Offer, Request, and Acknowledge is the same fixed-length header followed by a variable options section, with only the field values and the options themselves differing between message types. Knowing this layout once means the next four articles can point at specific fields instead of re-describing the packet shape each time.

That last point is worth sitting with for a second: nothing in the fixed header itself says what kind of message a packet is. op only distinguishes client-to-server from server-to-client, one bit's worth of information split four ways. The message type lives entirely in an option, tucked into the same variable section that carries the subnet mask and the DNS servers.

More states than four messages suggests

DORA describes the common case — a device with no address at all, starting from nothing. RFC 2131 actually defines eight client states, and the extra ones matter as soon as a device already has a lease it remembers:

stateDiagram-v2
    [*] --> INIT
    INIT --> SELECTING: broadcast DHCPDISCOVER
    SELECTING --> REQUESTING: DHCPOFFER chosen, broadcast DHCPREQUEST
    REQUESTING --> BOUND: DHCPACK received
    REQUESTING --> INIT: DHCPNAK received, or no answer
    INIT --> INIT_REBOOT: client remembers a previous lease
    INIT_REBOOT --> REBOOTING: broadcast DHCPREQUEST for the remembered address
    REBOOTING --> BOUND: DHCPACK received
    REBOOTING --> INIT: DHCPNAK received, or no answer
    BOUND --> RENEWING: T1 timer expires
    RENEWING --> BOUND: DHCPACK received
    RENEWING --> REBINDING: T2 timer expires with no answer
    REBINDING --> BOUND: DHCPACK received
    REBINDING --> INIT: lease expires with no answer

INIT-REBOOT is the practical one to know about: a laptop that suspends overnight and wakes up still connected to the same network doesn't throw away the address it had before. It skips Discover and Offer entirely, jumps straight to a broadcast Request naming the address it remembers, and either gets it confirmed with an Acknowledge or gets told, with a Not-Acknowledge, that the address is no longer valid — at which point it falls all the way back to INIT and runs full DORA from scratch. The Acknowledge article picks this scenario up in more detail once the ordinary DORA path has been covered.

RENEWING and REBINDING are the states behind the T1 and T2 timers the DHCP article's lease section already introduced — this sub-module doesn't re-explain what those timers are, only what the packets that fire when they expire actually look like on the wire, which the Request article covers directly.

With the shared header and the fuller state picture in place, the next article starts where every fresh lease starts: a client with no address at all, broadcasting into the dark to find out if anyone's listening.

Sources

• IETF, RFC 2131 – Dynamic Host Configuration Protocol
• IETF, RFC 951 – Bootstrap Protocol (BOOTP)