How a Machine Gets an Address

The bootstrapping problem, and the four messages that solve it

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

▸Explain why a client with no address must broadcast
▸Name the four DORA messages and what each commits to
▸Read a lease's options and say what would break if one were missing

Before this lesson — it builds directly on:

To send a packet you need an address. A machine that has just been plugged in does not have one. That is not a minor inconvenience — it is a genuine paradox, and DHCP's entire shape is the answer to it. The client sends from 0.0.0.0, meaning 'I have no address', to 255.255.255.255, meaning 'everybody on this wire'. It shouts because it cannot address anyone individually and has no return address to offer. Everything else about the protocol — why the reply is broadcast, why the acceptance is broadcast, why the client is identified by its MAC — follows from that one constraint.

Arriving in a room where you have no name yet. You cannot address anyone, and nobody can address you. So you shout to the whole room: "does anyone have a name I could use?" Several people may shout a name back. You shout again — "I am taking the one Sarah offered" — so that everyone else can withdraw theirs. Only after that can anyone speak to you directly.

shouting to the whole room: → broadcast to 255.255.255.255
having no name yet: → sending from source address 0.0.0.0
"does anyone have a name?": → DISCOVER
a name shouted back: → OFFER, carrying yiaddr
announcing whose name you took: → REQUEST, broadcast so other servers release theirs

Where it breaks down: In a room you would also be told where the exits are without asking. DHCP will happily give you a name and nothing else — an address with no gateway and no resolver is a complete, successful exchange, and the machine can then reach its own subnet and nothing beyond it.

✗ Common misunderstanding: The DHCP server sends the address directly to the client that asked.

Why that's wrong: It cannot. The client has no address, so there is nothing to unicast to — and no ARP entry can exist for an address it does not yet own.

Correct model: Everything before the ACK is broadcast, in both directions. That constraint is what shapes the entire protocol.

The packets prove it: The DISCOVER's source is 0.0.0.0 and its destination 255.255.255.255. So is the OFFER's destination, and the REQUEST's.

✗ Common misunderstanding: The DHCP REQUEST is sent to the chosen server, so it should be unicast.

Why that's wrong: It names the chosen server in an option, but it is broadcast — because the servers that were NOT chosen need to hear it and release the addresses they set aside.

Correct model: The REQUEST is addressed to everyone and about one server. Broadcasting it is how the losers find out.

The packets prove it: In the two-offer scenario the REQUEST's destination is 255.255.255.255 while its server-identifier option names one server.

Watch these fields in the lab: dhcp.ciaddr · dhcp.yiaddr

DISCOVER: 'Is there a DHCP server out there?' Broadcast from 0.0.0.0, identifying the client only by its MAC address.
OFFER: 'You could have this address, with this mask, gateway and resolver.' A proposal — nothing is reserved and nothing is written down.
REQUEST: 'I accept, from that server specifically.' Broadcast, so servers that were not chosen hear it and release the addresses they had set aside.
ACK: 'It is yours, for this long.' The only message that commits a lease. From here on the client can send ordinary unicast packets.
T1 and T2glossary: Renewal timers in the lease. At T1 (half) the client quietly renews with the granting server; at T2 (seven eighths) it broadcasts to any server, having given up on the first.

Watch these fields in the lab: dhcp.option[0] · dhcp.yiaddr

✓ 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 can the server not simply unicast the OFFER to the client that asked?

A machine has assigned itself 169.254.14.7. What happened?

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.