DHCP isn’t just about handing out IP addresses; it’s a complex dance of discovery, negotiation, and configuration that can fail in a surprising number of ways.
Let’s see what that dance looks like when things go wrong. Imagine a client boots up and needs an IP.
10:35:12.345678 Client MAC: 00:1A:2B:3C:4D:5E -> Broadcast (255.255.255.255) DHCP Discover
Options: (length 4)
Option 53, length 1: 1 (Discover)
Option 55, length 3: 1 (Subnet Mask), 3 (Router), 6 (DNS Server)
Option 255, length 0: End
10:35:12.567890 Server MAC: 00:01:02:03:04:05 -> Client MAC: 00:1A:2B:3C:4D:5E DHCP Offer
IP: 192.168.1.100
Server IP: 192.168.1.1
Lease Time: 86400 seconds
Options: (length 14)
Option 53, length 1: 2 (Offer)
Option 1, length 4: 255.255.255.0 (Subnet Mask)
Option 3, length 4: 192.168.1.1 (Router)
Option 6, length 8: 192.168.1.1, 8.8.8.8 (DNS Servers)
Option 255, length 0: End
10:35:13.123456 Client MAC: 00:1A:2B:3C:4D:5E -> Broadcast (255.255.255.255) DHCP Request
Requested IP: 192.168.1.100
Server IP: 192.168.1.1
Options: (length 4)
Option 53, length 1: 3 (Request)
Option 50, length 4: 192.168.1.100 (Requested IP Address)
Option 54, length 4: 192.168.1.1 (Server Identifier)
Option 255, length 0: End
10:35:13.345678 Server MAC: 00:01:02:03:04:05 -> Client MAC: 00:1A:2B:3C:4D:5E DHCP ACK
IP: 192.168.1.100
Server IP: 192.168.1.1
Lease Time: 86400 seconds
Options: (length 14)
Option 53, length 1: 5 (ACK)
Option 1, length 4: 255.255.255.0 (Subnet Mask)
Option 3, length 4: 192.168.1.1 (Router)
Option 6, length 8: 192.168.1.1, 8.8.8.8 (DNS Servers)
Option 255, length 0: End
This is the happy path: Discover, Offer, Request, ACK. The client broadcasts a Discover to find a DHCP server. A server responds with an Offer containing an IP address and lease details. The client broadcasts a Request for that specific IP, identifying the server it’s heard from. Finally, the server sends an ACK to confirm the lease.
The real magic of DHCP lies in its option fields. These are key-value pairs that carry critical information like subnet masks, router IPs, DNS server addresses, domain names, and even PXE boot parameters. A client can request specific options in its Discover packet (Option 55), and the server will try to fulfill them in its Offer and ACK.
The DHCP Discover is the initial broadcast from the client. It’s like shouting into the network, "Is there anyone out there who can give me an IP address?" The yiaddr field in the Offer and ACK packets is the IP address being offered or assigned to the client.
The DHCP Request is where things can get tricky. A client might request an IP it previously held, or it might be trying to renew its lease. The ciaddr field in a Request packet is the IP address the client already has (usually during renewal), while requested_addr (Option 50) is the IP it wants. If a client is booting for the first time, ciaddr will be 0.0.0.0.
The DHCP ACK is the final confirmation. It’s the server saying, "Okay, this IP is yours for this long, and here’s how to use it." If the client doesn’t receive an ACK after its Request, it will typically back off and try again.
The most surprising thing about DHCP is how often it fails not because the server is down, but because of subtle misconfigurations in network segmentation or option handling.
Consider this DHCP Offer packet captured on a client’s interface:
10:35:12.567890 Server MAC: 00:01:02:03:04:05 -> Client MAC: 00:1A:2B:3C:4D:5E DHCP Offer
IP: 192.168.1.100
Server IP: 192.168.1.1
Lease Time: 86400 seconds
Options: (length 14)
Option 53, length 1: 2 (Offer)
Option 1, length 4: 255.255.255.0 (Subnet Mask)
Option 3, length 4: 192.168.1.1 (Router)
Option 6, length 8: 192.168.1.1, 8.8.8.8 (DNS Servers)
Option 255, length 0: End
The client receives this Offer and then sends a Request. If the server doesn’t respond with an ACK, the client might keep retrying its Discover or Request. In Wireshark, you’d look for the DHCP Discover packets from the client and then see if any DHCP Offer packets are received. If offers are seen, but no ACK follows, the problem is likely on the server side or between the client and server that’s preventing the ACK from reaching the client. If no Offer packets are seen at all, the Discover packets aren’t reaching a DHCP server, or the server isn’t configured for that subnet.
This is why understanding the broadcast nature of Discover and Request is crucial. Unless a DHCP relay agent is configured, DHCP Discover and Request packets (which are broadcast on UDP port 67) won’t cross router boundaries. If your client is on a different subnet than your DHCP server, and you don’t have a relay agent, the Discover packet will simply die at the router.
The Server Identifier option (Option 54) in the Request packet is key. It tells the DHCP server which specific server the client wants to accept an offer from. This is vital in environments with multiple DHCP servers or when using DHCP relay agents.
When analyzing DHCP traffic in Wireshark, you’ll want to filter for bootp. This captures both DHCP and older BOOTP traffic. Common filters include:
bootp.type == 1forDiscoverbootp.type == 2forOfferbootp.type == 3forRequestbootp.type == 5forACKbootp.type == 6forNACK(Negative Acknowledge)
If you see DHCP NACK packets, it means the server rejected the client’s request, often because the IP address the client is trying to use is already in use or has been explicitly denied.
One subtle point is how the lease time (yiaddr’s lease duration) is handled. Clients will try to renew their lease when it’s halfway expired (T1 timer). If they can’t reach the original server, they might try broadcasting a DHCP Request for their current IP. If the original server is still unavailable, another server might offer an IP, leading to a potential IP conflict if not handled carefully.
The next thing you’ll run into is understanding how DHCP starvation attacks work and how to detect them by looking for an overwhelming flood of DHCP Discover packets from a single MAC address or a rapidly increasing number of unique MAC addresses requesting IPs.