What Is DHCP? The DORA Exchange and Leases Explained

The core exchange is four messages, commonly memorized as DORA. The client broadcasts a DHCPDISCOVER because it has no address yet and does not know where a server is. Any server on the segment replies with a DHCPOFFER proposing an address from its pool. The client broadcasts a DHCPREQUEST naming the offer it accepts — the broadcast tells any other servers that offered to withdraw their reservations — and the chosen server confirms with a DHCPACK carrying the address, lease time, and options. Only after the ACK does the client bind the address and begin using it.

Under the hood DHCP runs over UDP, with servers listening on port 67 and clients on port 68. Because the client starts with no IP address, the early messages are broadcast rather than routed. RFC 2131 also defines a client state machine — INIT, SELECTING, REQUESTING, BOUND, RENEWING, and REBINDING — plus an INIT-REBOOT path a device uses to reclaim an address it already knows after a reboot. A common misconception is that DHCP hands out MAC addresses; it does not. MAC addresses are burned into interface hardware at manufacture, and DHCP only reads them to identify a device.

A DHCP address is a lease, not a permanent grant. The lease duration lives in Option 51 (IP Address Lease Time), and there is no universal default — an administrator sets it per scope, trading address-pool efficiency against renewal chatter. A guest Wi-Fi network might lease for hours; a stable office segment might lease for days. The lease is what lets addresses be reclaimed and reused as devices come and go, which is the whole point of dynamic allocation over hand-numbering.

Renewal is timer-driven. At 50% of the lease (timer T1) the client quietly unicasts a DHCPREQUEST to the original server to extend its lease — the RENEWING state — and normally gets an ACK with no disruption. If that server is unreachable, at 87.5% of the lease (timer T2) the client enters REBINDING and broadcasts to any server that will answer. If the full lease expires with no response, the client must release the address and start a fresh DISCOVER, which is why a DHCP outage tends to surface gradually as leases age out rather than knocking everyone offline at once.

A scope is the range of addresses a server manages for one subnet, together with the settings handed out alongside them. Those settings are DHCP options, catalogued in RFC 2132. The two almost every network sets are Option 3 (Router), which supplies the default gateway, and Option 6 (Domain Name Server), which points clients at their resolvers — the same DNS role that turns names into addresses. Delivering these centrally means a gateway or resolver change is made once on the server, not re-typed on every device.

A reservation binds one address to a specific device's MAC inside a scope, so that device always receives the same predictable IP. This is not the same as a hardcoded static IP, though the two are often confused. A reservation is managed centrally and the device still pulls its full configuration — gateway, DNS, and other options — dynamically each lease cycle, so a server-side change reaches it automatically. A true static IP is set on the device itself, bypasses DHCP entirely, and will silently miss any option change made server-side. Choosing between dynamic assignment and fixed addressing for a given device is its own decision worth treating separately.

DHCP is a service, not a box, and treating "the router" as synonymous with DHCP is a common mental shortcut. On a small network the service typically runs on the consumer router or firewall. In larger environments it commonly runs as a dedicated role — a Windows Server DHCP role or a Linux daemon — or on an enterprise firewall or managed switch, chosen for centralized management and visibility across many subnets. Which platform hosts it is a deployment choice, entirely separate from the protocol itself.

Two operational concerns drive that choice. First, redundancy: Windows Server DHCP failover pairs exactly two servers per relationship in either Load Balance mode (a 50:50 split between two live servers) or Hot Standby (a secondary that stays idle until the primary is unreachable), and this remains supported in Windows Server 2025. Second, reach across subnets: because DISCOVER messages are broadcasts that do not cross a router, a DHCP relay agent on a router, firewall, or managed switch forwards them to a central server — stamping the client's subnet into the giaddr field — so one server can serve many segments without a server on every wire.

Because a client simply accepts the first valid offer it receives, any device that answers DISCOVER messages can hand out addresses — including a malicious or misconfigured one. A rogue DHCP server can point clients at an attacker-controlled gateway or DNS, setting up a man-in-the-middle position. Attackers often pair this with DHCP starvation, flooding the legitimate server with DISCOVER messages using spoofed MACs to drain its address pool, then stepping in to answer once real service is exhausted. Even without malice, an employee's home router plugged in backwards can start leasing addresses and break a segment.

The standard Layer-2 defense is DHCP snooping. The switch classifies ports as trusted (facing legitimate servers) or untrusted (facing clients) and discards server-sourced messages — OFFER, ACK, NAK — that arrive on untrusted ports, so a rogue server on a client port is silenced. Snooping builds a binding table of client MAC, leased IP, lease time, VLAN, and interface that also feeds Dynamic ARP Inspection and IP Source Guard. Snooping switches can add Option 82 (Relay Agent Information) carrying circuit and remote IDs; if the server is not configured to accept it, it may drop those requests, so the two ends must be set up together. For federal IPv6 rollouts, NIST SP 800-119 recommends fixed addressing or DHCPv6 with rogue detection over relying on SLAAC alone.