DHCP explained: how a device gets its IP address

Imagine you walk into a huge party and nobody knows who you are. You shout out to the room: "Can someone give me a name badge?" A friendly person at a table hears you, looks at their list of spare badges, and shouts back: "Here, take number 47!" You shout "I'll take number 47!", they confirm "It's yours!", and now everyone at the party knows you as number 47.

That's exactly what happens when your phone or laptop joins a network. The device shouts (broadcasts) "Does anyone hand out addresses?", the DHCP server replies with a spare one, the device claims it, and the server confirms. Four shouts — done. Your device now has an address so it can talk to everyone else.

The address isn't yours forever, though — it's more like borrowing a library book. After a while (the lease time) you have to ask to keep it, or the server lends it to someone else.

Every device on an IP network needs at least four pieces of information before it can communicate: an IP address, a subnet mask, a default gateway, and one or more DNS server addresses. Before DHCP, a network administrator had to configure all of that by hand on every machine — laptops, printers, phones, servers. On a network of a few hundred devices that's a full-time job. On a network with thousands of devices joining and leaving throughout the day, it's impossible.

DHCP is defined in RFC 2131 (IPv4) and works by having a central server maintain a pool (range) of available IP addresses and hand them out on demand. Each assignment is called a lease — a temporary loan of an address for a defined period.

The conversation between a new device (client) and the server follows four steps, nicknamed DORA:

1. DISCOVER — the client broadcasts "Is there a DHCP server out there?" (it has no IP yet, so it can't address anyone directly).
2. OFFER — the server responds with a proposed IP address and configuration.
3. REQUEST — the client broadcasts "I'd like that address please" (broadcast again, in case multiple servers offered).
4. ACK — the server confirms "It's yours for the next N hours/days".

Let's walk through each DORA packet in detail, then look at what a lease actually contains and what happens when it needs renewing.

A few important details about those packets:

• DISCOVER is sent from 0.0.0.0 to 255.255.255.255 — the client has no source address yet.
• OFFER includes a proposed IP address, lease duration, and server identifier. Multiple servers may each send an offer; the client picks one (usually the first received).
• REQUEST is still a broadcast — this tells any server whose offer was not chosen to release the address they were holding.
• ACK commits the lease. The server notes in its database that the address is taken until the lease expires.

A lease is much more than just an IP address. Here is what a typical DHCP ACK delivers:

DHCP defines over 100 option codes. Routers, vendors, and even network-boot systems use custom options to deliver extra configuration.

Lease renewal follows two timers built into the ACK:

• T1 (renewal): at roughly 50 % of the lease time the client sends a unicast DHCPREQUEST directly to the server that issued the lease. If the server responds with an ACK, the lease is extended.
• T2 (rebinding): if T1 renewal fails (the original server is unreachable), at ~87.5 % the client broadcasts a DHCPREQUEST to any available DHCP server asking for a rebind.
• Expiry: if no server responds before the lease expires, the client releases the address and starts the full DORA sequence again.

DHCP relay agents (also called IP helpers) solve the obvious problem that DHCP DISCOVER is a broadcast — and routers do not forward broadcasts between subnets. Without a relay agent, you would need a DHCP server on every single subnet.

A relay agent is a small piece of software running on the router (or layer-3 switch) at the edge of each subnet. When it receives a broadcast DISCOVER on a local interface, it inserts the client subnet's address into the giaddr (gateway IP address) field and unicasts the packet to the central DHCP server. The server uses giaddr to know which pool to allocate from, and the reply goes back via the relay agent to the client.

Once you understand how DHCP works mechanically, the next step is understanding where it can go wrong — and how to defend it.

Rogue DHCP servers are the most common attack. Because the client takes the first OFFER it receives, an attacker who can plug in a device (or run a VM) and respond faster than the legitimate server can hand out a malicious gateway and DNS server. Every client that accepts the rogue lease is now sending traffic through the attacker — a textbook man-in-the-middle attack.

DHCP starvation is a denial-of-service variant: an attacker floods the server with DISCOVER packets, each with a spoofed, unique MAC address. The server allocates an address for every request until the pool is exhausted. Legitimate clients then get no address and cannot join the network.

DHCP snooping is the primary mitigation, implemented at the switch layer. You designate one or more switch ports as trusted (uplinks to the real DHCP server or relay agent) and all other ports as untrusted. The switch inspects DHCP traffic and:

• Drops any DHCP OFFER or ACK arriving on an untrusted port (killing rogue server responses).
• Builds a snooping binding table mapping MAC address to IP address to VLAN to port.
• Enforces rate limits on DISCOVER packets from untrusted ports (mitigating starvation).
• Feeds the binding table to Dynamic ARP Inspection (DAI) and IP Source Guard for additional protection.

DHCP reservations (sometimes called static assignments or fixed-address) let you pin a specific IP address to a specific MAC address within the DHCP server itself. The device still goes through DORA — it gets the benefits of central management and DNS registration — but always receives the same address. This is preferable to truly static configuration on the device for servers and printers, because the address is tracked in one place.

DHCPv6 and SLAAC — IPv6 takes a different approach. Stateless Address Autoconfiguration (SLAAC) allows a device to construct its own global address by combining the /64 network prefix (advertised by the router via ICMPv6 Router Advertisements) with a host portion derived from its MAC address (EUI-64) or a random stable value (RFC 7217). No server needed.

DHCPv6 (RFC 3315 / RFC 8415) does exist and can provide a stateful assignment much like DHCPv4, but critically: DHCPv6 does not carry the default gateway — that still comes from Router Advertisements. Organisations often run both: SLAAC or DHCPv6 for the address, RAs for the gateway, and DHCPv6 options for DNS.

PXE (Preboot Execution Environment) network boot uses DHCP to bootstrap diskless machines. The DHCP server returns two extra options in its ACK:

• Option 66 / next-server (siaddr): the IP address of the TFTP server holding the boot image.
• Option 67 / filename: the path to the bootloader (e.g. pxelinux.0) on that TFTP server.

The network card firmware reads these options, downloads the bootloader over TFTP, and hands off control — all before any operating system is loaded. Kubernetes cluster provisioning, OS imaging, and diskless thin-client environments all rely on this mechanism.

Packet format internals. A DHCP message is carried over UDP: the client sends from port 68 to port 67 (server). On the wire, DHCP reuses the older BOOTP packet format — the first 236 bytes are fixed fields (transaction ID xid, client MAC chaddr, giaddr, etc.) followed by a 4-byte magic cookie (0x63825363) and then variable-length options. The xid (a random 32-bit transaction ID) is critical: it lets the client correlate OFFERs and ACKs with its own DISCOVER and REQUEST, even in a broadcast environment where many transactions may be in flight simultaneously.

Option 82 (Relay Agent Information). When a relay agent forwards a DISCOVER to the server, it can insert Option 82, which encodes sub-options identifying exactly which physical port and VLAN the client arrived on. The DHCP server can use this to assign addresses from pool-per-port policies, and the binding table becomes more granular. Option 82 also makes starvation harder — forged MACs don't get past port-level policy.

Duplicate Address Detection (DAD). After receiving an ACK, a careful client sends an ARP probe (ARP request for the offered IP with sender IP = 0.0.0.0). If anything responds, the client declines the lease with a DHCPDECLINE and the server marks that address as in conflict. On IPv6, DAD is built into the spec and uses Neighbour Solicitation before committing any address — SLAAC or DHCPv6.

Lease database and split-scope HA. Enterprise DHCP servers (ISC Kea, Microsoft DHCP, Cisco) support high availability via failover protocols. Two servers share a pool: one is primary, one secondary. They replicate the binding database over a dedicated connection. On primary failure, the secondary waits for the Maximum Client Lead Time (MCLT) before assuming full control, to avoid issuing addresses the primary already allocated but hasn't replicated yet. Getting MCLT and load-balance percentages wrong is a common cause of duplicate-IP incidents during failover.

Pool exhaustion and sizing. A lease time that's too long means churning clients (laptops docking and undocking, conference phones) hold leases long after they've left. A lease time that's too short floods the server with renewals and risks brief disruption if the server is momentarily overloaded. Common rule of thumb: lease time about 2x the typical time between client disconnects. For a corporate LAN with nightly logoffs, 8–24 hours is typical; for a coffee-shop hotspot where devices turn over every hour, 1–2 hours is more appropriate.

Security — rogue server detection. Beyond DHCP snooping, some organisations run rogue DHCP detection tools (e.g., dhtest, passive monitoring of OFFER packets on a mirror port) to alert when an unexpected server responds. On Windows domains, authorisation via Active Directory adds a second layer: a Windows DHCP server that detects it is not authorised in AD will shut itself down.

DHCPv6 prefix delegation (PD). In home and ISP contexts, a customer router uses DHCPv6 with the IA_PD option to request a whole /48 or /56 prefix from the upstream ISP. The router then subdivides and delegates /64s to its internal interfaces via SLAAC RAs. This is how residential IPv6 connectivity works — the CPE router is simultaneously a DHCPv6 client (upstream) and a SLAAC RA server (downstream).

Troubleshooting checklist. When a device fails to get an address:

• Is the DHCP server running? Check systemctl status isc-dhcp-server / kea-dhcp4.
• Is the relay agent configured? Run show ip interface on the router; verify ip helper-address points to the right server.
• Is the pool exhausted? Check show dhcp lease or server logs for "no addresses available".
• Is DHCP snooping blocking something? Verify the uplink is marked trusted and check show ip dhcp snooping statistics.
• Is a rogue server responding first? Capture with tcpdump -i eth0 port 67 or port 68 and inspect source MACs on OFFER packets.
• Is the firewall between relay agent and server allowing UDP 67/68?