DHCPREQUEST

DHCPREQUEST is the one DORA message that doesn't mean the same thing every time it's sent. A Discover only ever happens in INIT, and an Offer only ever comes from a server answering one. A Request, by contrast, is the message a client sends in three genuinely different situations — accepting a fresh offer, renewing an existing lease quietly in the background, and falling back to a broadcast when quiet renewal didn't work — and the packet looks different in each one.

The same message name, three different packets

The pattern underneath the table is straightforward once it's stated plainly: a client only needs to say what address it wants and which server it's talking to when there's ambiguity to resolve — multiple servers that might have made offers, or no established relationship yet. Once a lease is already bound to ciaddr, that address itself carries all the information a unicast Request needs; naming it again in an option would be redundant. And once the client is broadcasting again in REBINDING, precisely because the original server didn't answer, naming a specific Server-ID would defeat the point of asking anyone who's listening rather than just the one server that already went quiet.

SELECTING: confirming a choice, in public

When a client accepts an Offer, it broadcasts the Request rather than unicasting it directly to the chosen server — which looks odd at first, since the client already knows exactly which server it wants to talk to. The reason is the other servers on the segment, the ones whose Offers weren't picked. A broadcast Request naming a specific Server-ID lets every server that made an offer see the outcome: the one that was chosen sees its own ID and proceeds to Acknowledge; every other server sees a different server's ID and knows its own tentatively-reserved address is free again, without needing any separate message telling it so.

sudo tcpdump -i eth0 -n -v port 67 or port 68

12:00:01.312205 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:00:27:4e:66:a1, length 300, xid 0x3d1e2f8a, Flags [none]
      Client-Ethernet-Address 08:00:27:4e:66:a1
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Request
        Client-ID Option 61, length 7: ether 08:00:27:4e:66:a1
        Requested-IP Option 50, length 4: 192.168.1.42
        Server-ID Option 54, length 4: 192.168.1.1

The same xid, 0x3d1e2f8a, that opened this attempt back in the Discover article's capture is still here — one attempt, four packets, one transaction ID tying all of them together.

RENEWING and REBINDING: the same request the DHCP article already named

The DHCP article's lease section already explained what triggers T1 and T2 and what each one means for the client. What it didn't show is what the Request itself looks like at each point — and the difference is entirely in the header, not in any new option:

;; T1 fires, unicast Request straight to the leasing server
14:30:00.001 IP 192.168.1.42.68 > 192.168.1.1.67: BOOTP/DHCP, Request from 08:00:27:4e:66:a1, length 300, xid 0x88a2f01c

No Requested-IP and no Server-ID here — ciaddr already says 192.168.1.42, and the packet is addressed directly to 192.168.1.1, so nothing else needs to spell out which address or which server is involved. If this unicast Request gets an Acknowledge back, the lease is extended and the client returns to BOUND, T1 and T2 timers reset against the fresh lease.

When the leasing server has moved

A DHCP server that's been running at 192.168.1.1 for over a year gets migrated to new hardware during a maintenance window, coming back up at 192.168.1.5 instead, with DNS and documentation updated accordingly — but existing clients don't consult DNS to find their DHCP server, and don't know the address changed. A workstation's lease is still bound to the old address, and at T1 it does exactly what RENEWING requires: sends a unicast Request straight to 192.168.1.1.

14:30:00.001 IP 192.168.1.42.68 > 192.168.1.1.67: BOOTP/DHCP, Request from 08:00:27:4e:66:a1, length 300, xid 0x88a2f01c
;; connection timed out; no reply

Nothing is listening at 192.168.1.1 anymore, so the unicast Request simply goes nowhere — no error, no rejection, just silence. The workstation stays in RENEWING, retrying the same unicast Request against the same dead address, until T2 arrives at 87.5% of the lease. At that point it stops trying to reach that one server specifically and broadcasts instead:

14:47:00.001 IP 192.168.1.42.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:00:27:4e:66:a1, length 300, xid 0x88a2f01c
14:47:00.014 IP 192.168.1.5.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0x88a2f01c

The new server at 192.168.1.5 answers, because REBINDING's broadcast reaches every DHCP server on the segment, not just the one the client used to know about. This is precisely why REBINDING exists as a separate fallback rather than the client simply giving up after RENEWING fails: it recovers automatically from exactly this situation, at the cost of the roughly 37.5% of the lease's duration — from T1 to T2 — that RENEWING spent quietly failing before REBINDING's broadcast finally reached someone.

Practice exercises

1. A packet capture shows a Request with ciaddr set to 10.0.0.15 and no Requested-IP or Server-ID options, sent as a unicast packet. Which state produced this Request?
2. Explain, using the servers-that-weren't-chosen reasoning above, why a unicast Request in SELECTING state — addressed only to the winning server — would break the mechanism that frees up the other servers' tentative reservations.
3. In the server-migration scenario above, what would change if the DHCP server's IP address stayed the same but its hostname changed? Would RENEWING still fail?

Once a Request lands — whichever state produced it — the server has exactly two ways to respond, and only one of them actually finishes the job.

Sources

• IETF, RFC 2131 – Dynamic Host Configuration Protocol