Right, so you’ve got a network. It has computers. Those computers need IP addresses. You could hand them out manually like a party host assigning seats, but that’s a thankless chore destined for typos and conflicts. The solution? DHCP, the Dynamic Host Configuration Protocol, or as I like to call it, the “please, just give me an address and leave me alone” protocol. It’s the silent, mostly reliable concierge of your network, handing out not just IPs, but also gateways, DNS servers, and other crucial bits of info. Let’s pull back the curtain.

How a Client Gets an Address: The Four-Packet Dance

When your machine boots up and shouts “I’m alive!” into the Ethernet void, it doesn’t just get handed an IP. It engages in a very formal, slightly pedantic four-step conversation known as DORA. It’s not a complicated dance, but you need to know the steps.

  • Discover: Your client, with no IP, sends a broadcast packet (to 255.255.255.255) yelling, “Is there a DHCP server out there? I need a lease!” It’s basically the network equivalent of waving your arms in a crowded room.
  • Offer: A DHCP server hears the cry and responds with a broadcast packet (because the client still doesn’t have an IP to reply to) saying, “I’ve got one! Here’s an IP I propose for you, along with some other settings.” If there are multiple servers, the client gets multiple offers and usually just picks the first one. Not exactly sophisticated, but it works.
  • Request: The client doesn’t just accept the first offer. It broadcasts again (are you sensing a theme here?) to formally request the offered address. This is crucial. It tells all other DHCP servers that might have made offers, “Thanks, but I’m going with this guy.” This prevents multiple servers from thinking they’ve leased the same address.
  • Acknowledgement: The chosen server finalizes the deal with a final broadcast packet, acknowledging the request and officially granting the lease. Now, and only now, does the client configure its interface with the new IP.

Yes, it’s four packets where two might seem to do the job. The redundancy is there to prevent the absolute chaos of duplicate IP addresses. Trust me, you want this dance.

Where the Lease is Written: The Client’s Lease File

The server has a database of leases, but the client also keeps a local copy of its current lease. This is your first line of defense when something goes weird. On Linux systems, this is typically stored in /var/lib/dhcp/dhclient.leases or sometimes /var/lib/dhclient/dhclient.leases. On modern systems, you might need dhclient installed to even see it.

This file is a historical log. Every lease the client has ever obtained is appended here. When dhclient starts, it reads this file to remember its last known good lease and will often try to re-use that address, which is polite. Let’s look at a real example.

# First, find your interface name
ip a

# Then, check its lease (interface is typically 'eth0' or 'ens18')
sudo cat /var/lib/dhcp/dhclient.leases

The output isn’t meant to be pretty; it’s meant to be parsed by machines. A block for a lease looks something like this:

lease {
  interface "eth0";
  fixed-address 192.168.1.42;
  option subnet-mask 255.255.255.0;
  option routers 192.168.1.1;
  option domain-name-servers 8.8.8.8, 1.1.1.1;
  option dhcp-lease-time 86400;
  option dhcp-server-identifier 192.168.1.10;
  renew 4 2024/10/24 01:12:15;
  rebind 5 2024/10/24 10:12:15;
  expire 5 2024/10/24 13:12:15;
}

See those renew, rebind, and expire times? That’s the client’s calendar for this lease. It doesn’t just wait for the lease to die. At the renew time (halfway through the lease), it politely asks the original server for an extension. If that fails (maybe the server is down), it enters a rebinding state at the 87.5% mark and starts broadcasting to any DHCP server for help. If it hits the expire time with no renewal, it ditches the IP and starts the whole DORA process over from scratch. This is brilliant design, allowing for server outages without immediately kicking every client off the network.

The Pitfalls: Where This All Goes Wrong

This isn’t a perfect system. The designers made some choices… let’s call them “interesting.”

  1. Silent Failures: The most common issue. Your client can’t get an address. Is the DHCP server down? Is the client’s DHCP client service (dhclient) not running? Is there a rogue server on the network (a “rogue DHCP” attack) handing out bad offers? The logs are your friend. Run sudo dhclient -v eth0 to get a verbose, real-time view of the four-packet dance and see where it fails.
  2. Stale Leases: The server’s idea of what’s leased and the client’s can get out of sync. A client might abandon an address improperly (a hard reboot instead of a graceful release), but the server will still think the IP is leased until the timeout expires. This is why lease times are configurable. A long lease (days) is stable for fixed machines. A short lease (minutes/hours) is better for mobile devices coming and going on a WiFi network, preventing the pool from being exhausted by ghosts.
  3. The Belligerent Client: Sometimes dhclient gets clingy and holds onto an old lease it should have dropped. The fix? Be the bigger, smarter entity and force it to let go. This one-liner is a classic for a reason:
# Release the current lease, then try to get a new one.
sudo dhclient -r eth0 && sudo dhclient -v eth0

The protocol is old, and it shows in its broadcast-heavy nature, which doesn’t always play nicely across modern VLANs and routers without helpers. But for all its quirks, it works, and it works at a scale that would make manually assigning addresses an impossible nightmare. It’s one of those things you hope you never have to think about, but when it breaks, you’ll be profoundly grateful you know how it actually works.