2026
DHCP: Automatic IP Address Assignment
Every device on a network needs an IP address before it can communicate. DHCP assigns one automatically through a four-message handshake, along with a gateway, DNS servers and a lease timer. Here is what that process actually looks like.
Most devices on a network get their IP address without anyone touching a config file. A phone connects to Wi-Fi. A server boots in a rack. A laptop wakes up on a network it has never visited before. Each one ends up with a working address, a gateway to route through and a DNS server to query. DHCP handles all of that.
The protocol has been around since 1993 and it tends to stay invisible until it breaks. When it does break, the symptoms are not always obvious. Devices cannot reach the internet. Names stop resolving. Traffic routes somewhere unexpected. Most of these can trace back to something going wrong during the few seconds a device spent getting its address.
The problem it solves
Before DHCP, assigning addresses meant sitting down with each machine and entering values by hand. IP address, subnet mask, default gateway, DNS server. Every device needed its own entry. Every time a device moved to a different network, the process had to repeat.
That approach works when the network is small. Once the device count grows, the bookkeeping gets out of hand fast. Addresses conflict. Records go stale. Someone brings in a new machine and picks an address that is already taken. DHCP replaces all of that manual work with a protocol that handles assignment automatically, from a server that tracks what is already in use.
The same server can manage hundreds of addresses across an office floor, a data centre rack or a high-churn guest Wi-Fi network. The devices do not need to know anything about the address range. They ask. The server decides. The address arrives.
The DORA handshake
DHCP uses a four-message exchange to assign an address to a new device. The messages are Discover, Offer, Request and Acknowledge. Together they form the acronym DORA.
DORA handshake
Client → broadcast: Discover
↓ "I need an address. Is anyone listening?"
Server → client: Offer
↓ "Here is 192.168.1.42 with a 24-hour lease"
Client → broadcast: Request
↓ "I accept the offer from 192.168.1.1"
Server → client: Acknowledge
↓ "Confirmed. The address is yours until the lease expires."
The Discover goes out as a broadcast because the client has no address yet. It cannot send a directed packet. The source is 0.0.0.0 and the destination is 255.255.255.255. Every device on the segment receives it but only DHCP servers respond.
The Request is also a broadcast, even though the client already received an Offer. The reason is that multiple DHCP servers might be on the same segment. The broadcast tells all of them which one was chosen. Servers that were not selected can release the addresses they were holding in reserve.
Once the Acknowledge arrives, the client configures its network interface with the assigned address and options. At that point it has everything it needs to communicate on the network.
Lease times
Every address assigned by DHCP comes with a lease. The lease is a timer. When it expires, the client must either renew the address through a fresh exchange with the server or give it up.
Renewal timeline
50% markClient sends a renewal Request directly to the server that issued the lease.87.5% markIf the original server did not respond, the client broadcasts a renewal to any available server.ExpiryLease ends. The client must restart the full DORA process to get a new address.Short leases mean the server reclaims unused addresses quickly. That matters in environments where devices come and go throughout the day. The trade-off is more frequent DHCP traffic. Long leases reduce traffic but leave addresses tied to devices that left hours ago. The right value depends on how the network is used.
An eight-hour lease works well for a typical office network. Devices that stay connected all day will renew before expiry. Devices that leave at end of day will have their addresses reclaimed overnight. Guest Wi-Fi networks with high turnover often use shorter windows, sometimes as little as one hour.
DHCP options
An IP address is the minimum. DHCP typically delivers more alongside it. Additional configuration values travel in numbered option fields. The client can request specific options it wants. The server decides which ones to include in the response.
Subnet Mask
Tells the client which portion of the IP address identifies the network and which part identifies the host.
Router
The default gateway. Traffic destined for addresses outside the local subnet gets sent here first.
DNS Servers
One or more addresses of DNS resolvers the client should use for name lookups.
Domain Name
The domain suffix appended to unqualified hostnames during resolution.
Lease Time
How long the assigned address is valid, measured in seconds. The client must renew before this timer runs out.
TFTP Server
Used during PXE boot to tell a device where to download its initial boot image from.
Boot Filename
The path to the boot file on the TFTP server. Used alongside option 66 for network booting.
Options beyond the basics are how DHCP becomes more than just address assignment. PXE booting a server fleet, pointing devices at internal DNS resolvers, pushing domain search suffixes: these all travel through option fields rather than requiring separate configuration on each device.
Static reservations
DHCP does not mean everything gets a random address on each connection. Servers, printers and network infrastructure often need predictable addresses that stay the same across reboots. DHCP handles this with reservations.
A reservation maps a MAC address to a specific IP. When the device connects and sends a Discover, the server recognises the MAC address and offers the reserved IP every time. The device gets the convenience of DHCP without the unpredictability of dynamic assignment.
Reservation in ISC DHCP config
host print-server {
hardware ethernet aa:bb:cc:dd:ee:ff;
fixed-address 192.168.1.20;
}
Reservations also prevent a specific kind of conflict. If a static address gets assigned to a device outside of DHCP entirely, there is a risk the server hands that same address to something else. Reservations inside the pool let the server keep track and avoid offering addresses that are spoken for.
DHCP relay
A Discover is a broadcast. Broadcasts do not cross router boundaries. That creates a problem on networks with multiple subnets. Without a workaround, each subnet would need its own dedicated DHCP server.
With a relay agent
Client (subnet A) → broadcast: Discover
↓ relay agent on the router intercepts the broadcast
Relay → unicast → DHCP server (subnet B)
↓ server replies to relay with an Offer
Relay → client: Offer
↓ client completes DORA without knowing the server is remote
A relay agent is a small piece of software running on a router. When it receives a broadcast Discover, it forwards the packet as a unicast to a centralised DHCP server elsewhere on the network. The relay fills in the gateway IP field in the forwarded packet so the server knows which address pool to draw from.
This makes it practical to run a single DHCP server for an entire network. Large environments with many subnets centralise address management this way rather than running separate servers on every segment.
Inspecting DHCP from the command line
Most operating systems give you a way to see what the DHCP server actually sent. This is useful when something looks wrong with an address assignment or when you want to confirm which server is responding.
Linux: request a new lease with verbose output
$ sudo dhclient -v eth0
DHCPDISCOVER on eth0 to 255.255.255.255 port 67
DHCPOFFER of 192.168.1.45 from 192.168.1.1
DHCPREQUEST for 192.168.1.45 on eth0 to 255.255.255.255 port 67
DHCPACK of 192.168.1.45 from 192.168.1.1
bound to 192.168.1.45 -- renewal in 43200 seconds.
The output shows the full DORA exchange. The renewal time at the bottom is half the lease duration in seconds, which matches the 50% renewal trigger described in the RFC.
macOS: inspect the last DHCP packet received
$ ipconfig getpacket en0
op = BOOTREPLY
yiaddr = 192.168.1.45
server_identifier (ip): 192.168.1.1
lease_time (uint32): 0x15180
router (ip_mult): { 192.168.1.1 }
domain_name_server (ip_mult): { 1.1.1.1, 8.8.8.8 }
This shows the exact options the server sent along with the address. The server_identifier field is the IP of the DHCP server that responded. If a device is getting wrong gateway details, this is the fastest way to confirm whether a rogue server is the cause.
Common failure points
DHCP failures tend to look like something else at first. A device that cannot browse the web might have no address. An address that looks fine might have come from the wrong server. Placing the failure in the right part of the process is usually the fastest path to a fix.
Pool exhaustion
The DHCP server has no addresses left to offer. New devices send Discover messages but receive no response. The fix is either expanding the address range or shortening the lease time so addresses from departed devices get reclaimed faster.
Rogue DHCP server
A device on the network is running a DHCP server it should not be. Clients get addresses from it instead of the legitimate server. The gateway, DNS and lease options they receive may all be wrong. This is a common misconfiguration when someone brings in a home router and plugs it into an existing network without disabling its built-in DHCP service.
APIPA address (169.254.x.x)
When a client sends a Discover and gets no Offer back, it assigns itself a link-local address in the 169.254.0.0/16 range after a timeout. This is the operating system taking a fallback path, not a sign of a working network. A device stuck on a 169.254 address failed to reach any DHCP server.
Address conflict
Two devices end up with the same IP. This happens when a static address gets assigned to a device without checking whether it falls inside the DHCP pool. The server has no way to know that address is already taken. Keeping static assignments outside the pool range prevents this entirely.
Stale lease after server rebuild
A client holds a valid-looking lease but the server that issued it no longer exists. The client tries to renew at the halfway point, gets no response and keeps using the address until expiry. Whether the address still works depends on whether the new server happens to assign the same one.
Worth understanding
DHCP runs underneath every network that has more than a handful of devices. Most of the time it requires no attention at all. When something does go wrong, knowing the four-message handshake makes it much faster to figure out where the process stopped.
A packet capture on a failing device will show you whether the Discover went out and whether an Offer came back. Each missing step narrows the problem to a specific layer. No Offer means no server heard the request. No Acknowledge after a Request usually points to a server-side issue with that specific address.
The options are worth knowing beyond the defaults. A misconfigured gateway option breaks routing. Wrong DNS options break name resolution. A rogue server sending its own options can redirect traffic to the wrong places entirely. DHCP carries more than just addresses, which means it can cause more than just address problems when something goes wrong.