DHCP: how a host gets an address

The DORA sequence, what a DHCP server hands out besides an IP, and how an address lease lives.

Why this matters

Almost every office machine, home laptop, and cloud VM gets its address over DHCP. When a server "suddenly changed its IP" or a new machine gets an address but can't reach the internet, you look for the cause in the DHCP lease: what address, gateway, and DNS the server handed out, and for how long. This lesson covers how the exchange works and where to look at that lease.

The four DORA steps

A host without an address can't just "ask the server": it doesn't know its own address yet, let alone the server's. So DHCP starts with broadcast requests. DHCP runs over UDP: the server listens on port 67, the client on port 68. The four-step exchange is called DORA:

client                          server
DISCOVER  (broadcast) ------->        "who's a DHCP server here? I need an address"
<-------  OFFER                      "I'm offering 192.168.1.42"
REQUEST   (broadcast) ------->        "I'll take 192.168.1.42"
<-------  ACK                        "it's yours, lease is 12 hours"

REQUEST goes out as a broadcast for a reason: there can be several DHCP servers on the network, and this way everyone sees whose offer the client accepted. The other servers understand their offer was declined and return the address to their pool.

Here's what the exchange looks like in the output of busybox's udhcpc client (you'll run it in the lab). REQUEST is called select there:

udhcpc: broadcasting discover
udhcpc: broadcasting select for 10.213.10.100, server 10.213.10.10
udhcpc: lease of 10.213.10.100 obtained from 10.213.10.10, lease time 1800

What else comes with the address

Along with the address, the ACK brings options that are enough for a complete network setup:

• the subnet mask;
• the default gateway;
• DNS servers;
• sometimes a search domain, NTP servers, and more.

On modern Linux, addresses are usually managed by systemd-networkd, and networkctl shows what was handed out:

$ networkctl status eth0
       Address: 192.168.1.42
       Gateway: 192.168.1.1
           DNS: 192.168.1.1

systemd-networkd stores the raw lease with all its options in /run/systemd/netif/leases/, the file is named after the interface index:

$ sudo cat /run/systemd/netif/leases/2
ADDRESS=192.168.1.42
ROUTER=192.168.1.1
DNS=192.168.1.1

On desktops, and anywhere NetworkManager runs the network, you look at the same thing through nmcli:

$ nmcli device show eth0

The old ISC dhclient client, with leases in /var/lib/dhcp/dhclient.leases, still shows up on legacy systems. ISC ended its maintenance in 2022; in Ubuntu 24.04 the default client became dhcpcd instead, and the isc-dhcp-client package only remains in the universe repository.

Lease

An address isn't handed out forever, it's leased for a set time. At half the lease time, the client asks the same server to renew it; once it gets an ACK, it keeps the same address. If that server stays silent, the client tries again, and at 7/8 of the lease time it starts asking any DHCP server by broadcast. When the lease expires and nobody answered, the client has to drop the address and start DORA over.

For example, with a 1-hour lease, renewal starts after 30 minutes, and the broadcast request to any server starts at 52 minutes 30 seconds.

This has practical consequences. A server usually pins an address to a MAC address, so a machine gets the same IP time after time. But for servers and network equipment, the address is either fixed on the DHCP server (a reservation) or set statically: a service that suddenly changed its IP is a classic late-night incident.

Manually requesting the address again under systemd-networkd:

$ sudo networkctl renew eth0
$ networkctl status eth0     # check what came back

Under NetworkManager, the same thing happens by bringing the connection back up (the name comes from nmcli con show):

$ sudo nmcli con up "Wired connection 1"

Common mistakes

• Fixing the client when the wrong gateway or DNS came over DHCP. A manual fix on the client survives until the next lease renewal, and every new machine gets the same thing. You need to fix the DHCP server's config instead.
• Setting a very short lease "just in case". Clients then renew the address every few minutes, and any one-minute DHCP server outage turns into machines without an address.
• Giving a server an address from the dynamic pool. While the lease keeps renewing, the address stays the same, but after a long downtime the machine may get a different one. Servers need a reservation or a static address outside the pool.
• Forgetting that a network can have two DHCP servers. A home router accidentally plugged into an office network answers DISCOVER right alongside the real server, and some machines end up with the wrong gateway.

What you'll need for the tasks

• docker exec <container> <command>: lab commands run inside the lab environment's containers, no sudo needed;
• udhcpc -i eth0 -f -q -n -s <script>: busybox's DHCP client, request an address once and exit; the script receives the options it got;
• docker logs <container>: the udhcpd DHCP server's log, with the OFFER and ACK it sent;
• cat, vi, sed -i: read and edit a config file inside the container;
• docker restart <container>: restart the server so it reads its config again;
• sections "The four DORA steps", "What else comes with the address", and "Lease".

The track closes with a quiz: check what stuck after the whole networking section.