SubnetLayerProtocols

The Messages You Rarely See

DECLINE, RELEASE and INFORM — and why none of them is acknowledged

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

Before this lesson — it builds directly on:
DORA answers one question: how does a machine with nothing get an address? It is the question everybody learns first, and it covers the common case completely. But it leaves three ordinary situations with no answer at all. What if the address does not actually work? The server offered it in good faith, but a server only knows about addresses it handed out. Somebody may have typed one into a printer by hand. The client needs a way to say "not that one". What if the machine is leaving? The lease has hours left. Waiting them out means an address sitting unused, and the pool is finite. What if the machine already has an address but not the rest? A server configured by hand still needs to know which resolver to use. It needs the settings without the lease. DECLINE, RELEASE and INFORM are those three answers. Each is a single message, and between them they are most of what you see in a DHCP capture that is not DORA.
Booking a hotel room. DORA is checking in. DECLINE is opening the door, finding somebody already in the room, and going straight back to reception. RELEASE is checking out early rather than letting the booking run to its end. INFORM is walking up to the desk and asking for the wifi password when you already have a room.
finding the room occupied
the ARP probe drawing a reply
telling reception which room it was
DECLINE carrying the address in requested-IP
reception marking that room out of service
the server refusing to offer it again
checking out early
RELEASE, freeing the address before the lease ends
asking only for the wifi password
INFORM — settings, no room, no bill

Where it breaks down: A hotel confirms your checkout and gives you a receipt. DHCP confirms none of these three. If your RELEASE is lost the server never learns you have gone, and the address stays yours on paper until the lease expires — which is exactly what happens every time a laptop is unplugged rather than shut down.

✗ Common misunderstanding: Once the ACK arrives the client has the address and the exchange is over.

Why that's wrong: The ACK is the server committing, not the client. A careful client checks the address really is free before it uses it, and it can still refuse — after the ACK — if somebody answers.

Correct model: The ACK ends the negotiation. Using the address is a separate decision the client makes afterwards, and DECLINE is how it says no at that point.

The packets prove it: This lesson's trace has a complete DHCPACK at 61 ms and a DHCPDECLINE for the same address at 64 ms, with an ARP exchange in between that explains the change of mind.

Watch these fields in the lab: dhcp.messageType · dhcp.requestedIp · dhcp.ciaddr

ARP probe
An ordinary ARP request sent for an unusual reason: not to learn a MAC address, but to find out whether anybody answers at all. Silence is the result the sender is hoping for.
Duplicate address
Two machines using the same IP address on one segment. Neither works reliably, because replies go to whichever one the sender's ARP cache happens to point at, and that can change.
ciaddr
The "client address" field. Empty means the client has nothing. Populated means it already holds an address and is telling you which one — which is what makes RELEASE and INFORM possible at all.
Advisory message
A message nothing acknowledges and nothing retries. The sender says it once and carries on. If it is lost, both sides simply fall back on their timers.

Watch these fields in the lab: dhcp.ciaddr

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

Why does the ARP probe carry a sender IP of 0.0.0.0 rather than the address being probed?

A laptop is unplugged without being shut down. What happens to its address?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.