How DHCP Works: DORA, Leases, and Failure Modes

DHCP (Dynamic Host Configuration Protocol) is the mechanism by which a device on an IP network obtains its IP address, subnet mask, default gateway, DNS servers, and other configuration parameters automatically. Instead of a human or a network administrator manually entering these settings on every machine, the device asks a server for them, and the server hands out an address for a limited time. This page explains the protocol’s operation: the four-message exchange, the lease lifecycle, and the ways the process can fail.

The Four-Message Exchange: DORA

When a DHCP-enabled client starts up (or its lease expires), it has no IP address. It must find a server and request configuration. This happens in four messages, often abbreviated as DORA: Discover, Offer, Request, Acknowledge.

1. Discover (Client → Broadcast)

The client sends a DHCPDISCOVER message. Because the client does not yet have an IP address, the source IP is 0.0.0.0 and the destination is the broadcast address 255.255.255.255. The message also includes the client’s MAC address and a transaction ID (xid) that will be used to match replies to this request.

The client does not know where a DHCP server is, so the message is broadcast on the local network segment. If the client and server are on different subnets, a DHCP relay agent (often a router) forwards the broadcast to the server’s IP address.

2. Offer (Server → Client)

Every DHCP server that receives the Discover and has an available address responds with a DHCPOFFER. The offer includes the proposed IP address, the subnet mask, the lease duration, and often other options like the default gateway and DNS servers. The offer is sent as a broadcast (or unicast if the client’s IP is known) to the client’s MAC address.

The client may receive multiple offers if more than one server is present. The client’s behavior at this point is important: it will typically accept the first offer it receives, not the “best” one.

3. Request (Client → Broadcast)

The client sends a DHCPREQUEST message. This message is broadcast so that all servers hear it. The client includes the IP address of the server whose offer it accepted (in the ‘server identifier’ option) and the requested IP address. This serves two purposes: it tells the chosen server “I accept your offer,” and it tells any other servers “I declined your offer; you can put that address back in your pool.”

4. Acknowledge (Server → Client)

The chosen server responds with a DHCPACK, which includes the final configuration parameters and the lease duration. The client then configures its network interface with the offered IP address, subnet mask, gateway, DNS, and any other options. The server records the lease in its database, marking the address as in use until the lease expires.

If the server cannot fulfill the request (for example, the address was already taken), it may send a DHCPNAK, and the client must restart the process.

The Lease: Duration and Renewal

The IP address is not given to the client permanently. It is leased for a period defined by the server, typically from a few hours to several days. The lease exists so that addresses are not tied up indefinitely by devices that leave the network.

Renewal (T1)

When half of the lease time has elapsed (the T1 timer), the client attempts to renew its lease. It sends a DHCPREQUEST directly to the server that granted the lease (unicast, not broadcast). If the server responds with a DHCPACK, the lease is renewed, and the timers reset.

Rebinding (T2)

If the client does not receive a response to its renewal request by the time 87.5% of the lease has elapsed (the T2 timer), it begins the rebinding process. It broadcasts a DHCPREQUEST to any server. Any server that can offer a lease may respond. If a server responds, the lease is renewed. If no server responds by the time the lease expires, the client must stop using the IP address and restart the DORA process from Discover.

Why this matters

If a DHCP server is temporarily unreachable, a client can continue using its address for the remainder of the lease. This is why a short lease (e.g., 1 hour) is often used in networks where addresses change frequently, and a longer lease (e.g., 8 days) is used in stable networks. A short lease means clients will notice a server outage sooner, but it also means more renewal traffic.

Failure Modes and Their Consequences

Two DHCP Servers on the Same Network

If two servers are configured with overlapping address pools, both will respond to Discover messages. The client accepts the first offer it receives. This can lead to IP address conflicts if the servers’ databases are not synchronized. For example, Server A offers 192.168.1.10 to Client X, and Server B offers the same address to Client Y. When both clients try to use the address, packets will be misrouted or dropped. This is a common misconfiguration in networks where an administrator adds a second server without disabling the first.

How to avoid: Ensure that each server’s scope covers a distinct range of addresses. If you need redundancy, use a protocol that supports failover (e.g., DHCP failover in Windows Server) or split the scope into two non-overlapping ranges.

Exhausted Scope

A DHCP scope is the range of addresses a server is willing to lease. If all addresses in the scope are leased, the server cannot offer a new lease. When a client sends a Discover, the server either does not respond or sends a DHCPNAK. The client will keep retrying, but will never get an address. This often happens in networks that have grown beyond their original IP plan, or when devices with long leases (e.g., 8 days) are added faster than they are removed.

Symptoms: New devices cannot connect to the network; existing devices may work until their leases expire. The server’s event log will show “no addresses available” or similar.

How to confirm: Check the DHCP server’s scope statistics. In Windows, the DHCP console shows the number of addresses in use and available. If the available count is 0, the scope is exhausted.

What to do: Expand the scope (if there is room in the subnet), reduce the lease duration, or investigate why addresses are not being released (see below).

A Device Holding an Address It Should Have Released

A client is supposed to release its lease when it shuts down gracefully, but many devices do not. Laptops that are put to sleep instead of shut down, or that are abruptly disconnected, do not send a DHCPRELEASE. The server holds the lease until it expires. In a network with many such devices, the scope can become exhausted even though many of the addresses are not actually in use.

How to confirm: Check the DHCP server’s lease list. You will see many leases for devices that are not currently on the network. The lease expiration time will be in the future.

What to do: Reduce the lease duration so that stale leases expire sooner. Alternatively, you can manually delete stale leases, but this is a temporary fix. A better long-term solution is to ensure that devices are configured to release their leases on shutdown, but this is not always possible.

DHCPNAK and Conflicts

If a client requests an address that is already in use (for example, because the client’s lease expired but the address was reassigned), the server may send a DHCPNAK. The client then restarts the DORA process. This can happen if a client’s clock is wrong and it attempts to renew too early, or if the server’s database is out of sync.

What People Get Wrong About DHCP

A common mistake is to think that the DHCP server “assigns” an IP address permanently. In reality, it leases the address for a finite time. This misunderstanding leads to confusion when a device’s IP address changes unexpectedly, or when a device cannot get an address after a server outage. Another misconception is that the client always accepts the “best” offer. It does not; it accepts the first offer it receives. This is why having two servers with overlapping scopes is so problematic.

Another error is to assume that a device that is powered off has released its address. Many devices do not send a DHCPRELEASE on shutdown, so the server continues to hold the lease until it expires. This is a natural mistake because it seems logical that a device would “give back” its address when it leaves the network, but the protocol does not require it, and many operating systems do not do it.

Finally, some people think that DHCP is a Windows-only feature. It is not; it is an open standard (RFC 2131) implemented by all major operating systems and network devices.

Comparison of Failure Modes

Commands to Inspect DHCP

On a Windows client, you can see your current lease information with:

ipconfig /all

The output shows the DHCP-enabled status, the lease obtained and expiration times, and the DHCP server address.

To see the DHCP server’s lease database on a Windows Server, use the DHCP console (dhcpmgmt.msc) or the following PowerShell cmdlet:

Get-DhcpServerv4Lease -ScopeId 192.168.1.0

Replace the scope ID with your own. The output lists all leases, their IP addresses, client IDs, and expiration times.

On a Linux client, use:

ip addr show

or

cat /var/lib/dhcp/dhclient.leases

The latter shows the lease information stored by the DHCP client.

These commands help you see what the client and server believe about the lease, which is often the first step in diagnosing a DHCP problem.