You join a Wi-Fi network. Within a few seconds your device has an IP address, knows the default gateway, knows which DNS servers to use, and you’re browsing. The protocol that makes this happen — every time, on every network — is DHCP (Dynamic Host Configuration Protocol).
This post explains DHCP at a practical level: the four-step handshake, what gets configured (more than just IPs), lease semantics, and the production patterns for DHCP in corporate networks and cloud environments.
The Core Idea
When a device joins a network, it doesn’t have an IP yet. It can’t make TCP connections. It can’t even ask a DNS server anything. But it needs an IP from somewhere.
DHCP solves this with broadcasts at the link layer. The device shouts on the local network “I need an IP!” A DHCP server (somewhere on the network) hears the shout and replies with configuration.
The flow has a memorable name: DORA.
The DORA Handshake
1. DISCOVER
The client broadcasts a DHCP Discover message:
From: 0.0.0.0 (client has no IP yet)
To: 255.255.255.255 (broadcast)
"Any DHCP server out there?"2. OFFER
DHCP server(s) on the network respond with an Offer:
From: <DHCP server IP>
To: <client MAC>
"How about 192.168.1.42 for an hour? Default gateway 192.168.1.1, DNS 8.8.8.8, lease 3600 seconds."There may be multiple servers; the client typically picks the first or the best.
3. REQUEST
The client formally requests the offered configuration:
From: 0.0.0.0
To: 255.255.255.255 (still broadcast)
"I'll take 192.168.1.42 from server X."The broadcast lets other DHCP servers know their offers were declined.
4. ACK (Acknowledge)
The chosen server confirms:
From: <DHCP server>
To: <client>
"Confirmed: 192.168.1.42 is yours for 3600 seconds."The client now has an IP and can communicate.
Total time: typically 1-3 seconds on a healthy network. Slow DHCP is often the cause of “this Wi-Fi takes forever to connect.”
What DHCP Configures
The IP address is just the start. A typical DHCP response includes:
- IP address for the client.
- Subnet mask — what network the client is on.
- Default gateway — router for off-network traffic.
- DNS server(s) — where to send DNS queries.
- Lease duration — how long this assignment is valid.
- NTP server(s) (sometimes) — for time sync.
- Domain suffix (sometimes) —
example.comsoprinterresolves toprinter.example.com. - Vendor-specific options — TFTP server for PXE boot, captive portal URL, etc.
For home networks, this is “give me an IP and tell me where to find the internet.” For corporate networks, it’s “give me an IP, point me at internal DNS, tell me the proxy server, configure my VPN.”
Lease Semantics
DHCP leases are time-bound. The client has the IP for the lease duration, then must renew or get a new IP.
Renewal pattern
- At 50% of lease time (typical 30 min for an hour lease): client tries to renew by contacting the original server directly (no broadcast).
- At 87.5% of lease time (~52 min): client broadcasts a renewal request to any DHCP server.
- At 100% (lease expires): client has no IP; restart the DORA process.
In practice, on a working network with the same DHCP server, the renewal is fast and transparent. The client doesn’t notice.
Lease duration trade-offs
- Short leases (1-2 hours) — Faster reclaim of dead clients. More renewal traffic.
- Long leases (24+ hours) — Less traffic. Slower reclaim of unused IPs.
Corporate networks often use 8-24 hour leases. Home routers default to ~1 day. Mobile/guest networks may use shorter leases (hours) for higher churn.
Static vs Dynamic Assignment
Pure dynamic
DHCP server has a pool; clients get whatever IP is available. Different IPs across connections.
Reservation / fixed
DHCP server is configured to always give a specific MAC address the same IP. Looks dynamic but functionally static. Common for servers, printers, IoT.
Static (not DHCP)
Client is configured manually with an IP. DHCP isn’t involved. Common for servers in datacenters; less common elsewhere.
For most production environments, DHCP reservations are better than truly static — you get the same IP every time, but you can also change the assignment centrally.
Where DHCP Servers Live
Home networks
The router. Your ISP-provided router or aftermarket box (Asus, eero, Ubiquiti) runs DHCP. Trivial to configure.
Small offices
A central DHCP server, often Windows Server’s DHCP role or a dedicated appliance (Mikrotik, Cisco ISR).
Enterprise
Dedicated DHCP infrastructure, often clustered for HA. ISC DHCP, Microsoft DHCP, or commercial IPAM products (Infoblox, BlueCat).
Cloud
Cloud providers handle DHCP transparently. You see “DHCP-assigned IP” but never configure a DHCP server. AWS, GCP, Azure manage it for you.
Container networks
Inside Kubernetes/Docker, DHCP is usually absent. Pods get IPs from the CNI plugin (Calico, Flannel) via different mechanisms.
DHCP Relay
DHCP uses broadcasts, which by default don’t cross router boundaries. For a single DHCP server to serve multiple subnets, you need DHCP relay (also called “ip helper-address” on Cisco gear).
The relay sits on each subnet and forwards DHCP broadcasts to the central server (via unicast). Responses come back through the relay.
Client (subnet A) → Broadcast → Relay → Unicast → DHCP Server (subnet B)
← ←For corporate networks with dozens of subnets and one DHCP server, relays are essential.
DHCP for IPv6: DHCPv6 and SLAAC
IPv6 has two address-assignment paths:
SLAAC (Stateless Address Autoconfiguration)
The router advertises a /64 prefix; clients construct their own addresses by combining the prefix with a host identifier. No DHCP server needed for the IP itself.
DHCPv6
For IPv6 environments that need centralized control. Similar protocol; uses UDP port 547 (server) and 546 (client) instead of IPv4’s 67/68.
Most consumer IPv6 deployments use SLAAC. Many enterprises use a mix:
- SLAAC for addresses.
- DHCPv6 stateless for DNS and other config options.
- DHCPv6 stateful when centralized address tracking is required.
For more on IPv6 networking, see IPv6 deployment guide.
Common DHCP Issues
DHCP exhaustion
The DHCP pool runs out of addresses. New clients can’t connect. Causes:
- Lease duration too long; old leases never freed.
- Network has more devices than the pool’s CIDR allows.
- A misbehaving device is requesting many IPs (MAC randomization gone wrong).
Fix: lengthen the subnet’s CIDR (more addresses) or shorten lease time.
Rogue DHCP servers
A device on your network starts answering DHCP requests with wrong information. New clients get bad IPs. Often caused by:
- A consumer router plugged into the corporate network with DHCP enabled.
- Malware deliberately running a rogue server.
Mitigation: DHCP Snooping on managed switches — only specific switch ports are allowed to answer DHCP.
Address conflicts
Two devices end up with the same IP. Can happen with stale leases, static IPs colliding with DHCP pool, or rogue servers. Modern DHCP servers do a ping check before assigning to detect conflicts.
MAC randomization
Modern phones and laptops use random MAC addresses by default for privacy. Each connection might use a different MAC. From the DHCP server’s view, you look like a new device every time. Implications:
- DHCP reservations don’t stick.
- “Device count” estimates are inflated.
- Access controls based on MAC are unreliable.
Most consumer routers handle this fine. Enterprise networks sometimes disable MAC randomization at the OS level (with policy) for managed devices.
Security Considerations
DHCP wasn’t designed for security. By default, anyone on the network can:
- Run a rogue DHCP server.
- Capture DHCP traffic (which reveals MAC addresses and hostnames).
- Send fake DHCP responses (man-in-the-middle).
Mitigations:
- DHCP Snooping — Restrict which switch ports can serve DHCP.
- Authenticated DHCP — Use 802.1X for network access; only authorized devices can complete DHCP.
- DHCP over VPN — For remote workers, run DHCP through the VPN tunnel.
For corporate environments, treat DHCP as part of the broader network access control story, not a standalone secure protocol.
Application Layer: When DHCP Matters
For application developers, DHCP is invisible most of the time. The OS handles it. Your code sees the resulting IP.
Where it might matter:
Dynamic IPs in logs
Users’ IPs change over time. Log entries from yesterday may reference IPs that are now assigned to different devices. Don’t treat IPs as long-term identifiers.
Geolocation drift
ISPs reassign DHCP-assigned IPs periodically. A user’s IP today might geolocate slightly differently than yesterday. See IP geolocation accuracy.
Behind-NAT identification
Inside a corporate NAT, every internal IP is DHCP-assigned. Identifying users by internal IP isn’t reliable across days.
TL;DR
- DHCP dynamically assigns IPs and network config.
- DORA flow: Discover, Offer, Request, Acknowledge.
- Configures more than IP: subnet, gateway, DNS, lease, etc.
- Leases are time-bound with built-in renewal.
- DHCP Relay forwards across routed boundaries.
- IPv6 uses SLAAC (auto-config) and/or DHCPv6.
- MAC randomization changes how reservations work.
- DHCP isn’t secure by design — use snooping, 802.1X, VPN tunnels.
DHCP is one of those protocols that’s been running quietly for 30 years. Most developers will never touch it directly. Understanding the basics helps when networks misbehave and clarifies why an IP isn’t a stable identifier for a user or device. For related private-network topics, see private IP ranges RFC 1918; for the NAT layer that often sits between DHCP-assigned hosts and the public internet, NAT and CGNAT.