DHCP Explained: How a Machine With No IP Address Gets One in Four Messages

Originally published at series.

This post is part of Protocol Lab, a free, hands-on series for learning networking protocols by building and breaking them in a container lab. All the lab material — topologies, configs, and scripts — lives in the repo:

Prerequisite: .

Running the Lab

The quick path, which deploys, verifies, and tears down for you:

./scripts/labctl.sh run dhcp-22

Or step through it manually:

1. Move into the working directory

cd protocol-lab/examples/dhcp-22

2. Deploy and start the DHCP server

sudo containerlab deploy -t dhcp-22.clab.yml

docker exec clab-dhcp-22-server sh -c ": > /tmp/udhcpd.leases; udhcpd -f /etc/udhcpd.conf &"

udhcpd.conf hands out 10.0.0.100–.200 and passes the router, DNS, and lease time as options.

3. Set up the capture and have the client get an address

docker exec -d clab-dhcp-22-client tcpdump -i eth1 -n "udp port 67 or udp port 68"

docker exec clab-dhcp-22-client udhcpc -i eth1 -q -f -n

docker exec clab-dhcp-22-client ip -4 addr show eth1

udhcpc's output should include a line like lease of 10.0.0.193 obtained from 10.0.0.1, and ip addr should show an address on eth1.

4. Read the DORA exchange in the capture

docker exec clab-dhcp-22-client tcpdump -n -vv -r /tmp/dhcp.pcap

0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP ... DHCP-Message: Discover

... > ...68: DHCP-Message: Offer

0.0.0.0.68 > 255.255.255.255.67: DHCP-Message: Request, Requested-IP 10.0.0.193

... > ...68: DHCP-Message: ACK

Expected Output

• 
  udhcpc: lease of 10.0.0.1xx obtained from 10.0.0.1.


• 
  ip addr show eth1: inet 10.0.0.1xx.


• The capture: all four messages — Discover → Offer → Request (with a Requested-IP) → ACK.

Why It Works

DHCP is a mechanism for handing an address — and the settings that go with it — to a host that doesn't have one. The hard part is the starting point: the client doesn't know the server, and doesn't have an address of its own.

• 
  Why broadcast. The client knows neither the server's IP nor its own. So it sends to 255.255.255.255 (broadcast) from source 0.0.0.0, reaching everyone on the link. Only the server responds.


• 
  The four DORA steps:
  
  
  
  
  • 
    Discover: "Is there a DHCP server?" Broadcast.
  
  
  • 
    Offer: The server proposes a candidate — "how about this address?" If there are multiple servers, multiple Offers can arrive.
  
  
  • 
    Request: The client asks for that address, including which server's Offer it accepts. This is also broadcast — so the servers that weren't chosen learn their offers were declined.
  
  
  • 
    Ack: The server finalizes it, attaching the lease time and options.
  
  
  
  


• 
  The lease. The address isn't bought outright — it's borrowed, with an expiry. Before the lease runs out, the client renews it. This lets addresses of departed hosts be reclaimed and reused, keeping a limited address space in circulation.


• 
  More than just an address. DHCP also delivers the subnet mask, default router, DNS server, lease time, and more as options (RFC 2132). That's why connecting via DHCP configures your gateway and DNS automatically.


• 
  Ports 67/68. The server uses 67, the client 68 — both UDP. Because the ports are fixed, the exchange works even before any IP is settled.

The key insight: starting from "I know neither my own address nor the server's," broadcast plus four messages is enough to borrow a complete address setup.

Common Pitfalls

• 
  Thinking the R in DORA comes from the server. The Request is sent by the client (requesting the offered address).


• 
  Thinking the Offer is final. The Ack is what finalizes it. An Offer is a candidate — with multiple servers, several may arrive.


• 
  Missing why broadcast is needed. The client knows neither its own IP nor the server's.


• 
  Assuming the address is permanent. A lease has an expiry. Fail to renew and you lose it.


• 
  Assuming DHCP only hands out an address. It also delivers the router, DNS, lease time, and other options.


• 
  Mixing up the ports. Server 67, client 68 — swap them and your capture filter won't match.

Cleanup

sudo containerlab destroy -t dhcp-22.clab.yml --cleanup

If you used labctl.sh run dhcp-22, the script runs destroy for you at the end.

Check Your Understanding

1. What are the four DORA messages? Who sends each one?


2. Why does a client with no address use broadcast? What is its source address?


3. What's the difference between an Offer and an Ack? Which one finalizes the address?


4. What is a lease, and why are addresses time-limited?


5. Besides an address, what does DHCP deliver? (Name three things.)


6. What are the DHCP server and client port numbers?

References

Verified Run Log (2026-07-07)

This lab has been confirmed reproducible on real hardware.

Environment:

• Ubuntu 26.04 LTS (kernel 7.0.0-27-generic, x86_64)


• Docker 29.1.3


• containerlab 0.77.0


• client / server: nicolaka/netshoot:latest (udhcpd 1.38.0 / udhcpc, with tcpdump)

Running PATH="/tmp/pl-shim:$PATH" ./scripts/labctl.sh run dhcp-22 performed deploy → verify → destroy, and verification.json returned "status": "verified".

The client obtains an address

$ docker exec clab-dhcp-22-client udhcpc -i eth1 -q -f -n

udhcpc: lease of 10.0.0.193 obtained from 10.0.0.1, lease time 3600



$ docker exec clab-dhcp-22-client ip -4 addr show eth1

    inet 10.0.0.193/24 ... scope global eth1

DORA is visible on the wire

$ docker exec clab-dhcp-22-client tcpdump -n -vv -r dhcp.pcap

0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request ... DHCP-Message: Discover

        ... > ...68: DHCP-Message: Offer

0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request ... DHCP-Message: Request

        Requested-IP: 10.0.0.193

        ... > ...68: DHCP-Message: ACK

Discover (source 0.0.0.0, destination broadcast 255.255.255.255:67) → Offer → Request (Requested-IP 10.0.0.193) → Ack. Starting with no address and no known server, broadcast plus four messages borrows a complete address setup — here including the router, DNS, and lease.

Cleanup

containerlab destroy -t dhcp-22.clab.yml --cleanup

That's DHCP: four messages — Discover, Offer, Request, Ack — that take a host from no address at all to a fully configured lease, with the gateway and DNS thrown in for free.

Explore the full Protocol Lab series here: github.com/pathvector-studio/protocol-lab. If these labs are useful to you, please ⭐ star the repo on GitHub — it genuinely helps others find the project.

Next up, we'll keep climbing the stack and look at what happens once a freshly configured host starts resolving names and moving packets.