Dynamic Host Configuration Protocol (DHCP)

When you connect a device to a network, something remarkable happens in milliseconds: without any human intervention, your device negotiates with a server it has never communicated with before, obtains a unique network address, and configures itself to participate in network communication.

This negotiation follows a precise four-message protocol known as DORA: Discover, Offer, Request, Acknowledge.

DORA represents one of the most elegant solutions in network protocol design—solving the bootstrap problem (how does a device without an address communicate to get an address?) while handling multiple servers, client preferences, and failure recovery gracefully.

Understanding DORA isn't just academic. Network engineers troubleshoot DHCP issues constantly—devices failing to get addresses, lease storms, slow network joins—and all these problems trace back to understanding what happens (or fails to happen) during the DORA exchange.

The DORA process enables a client without any IP configuration to obtain a valid address from a server. The four messages work as a two-phase commit: the first two messages (Discover/Offer) locate available servers and collect offers; the second two messages (Request/Acknowledge) finalize the selection and confirm the assignment.

Why Four Messages Instead of Two?

A simpler protocol might have the client broadcast a request and the server respond with an address. Two messages, done. But this simpler approach fails in real networks:

1. Multiple servers: What if multiple DHCP servers exist? The client needs to collect offers and choose one.
2. Server confirmation: The server needs confirmation that the client accepted its offer before committing the address.
3. Conflict detection: The client might detect the offered address is already in use and need to decline.
4. Third-party notification: Other servers need to know which offer was accepted so they can release their proposed addresses.

The four-message exchange handles all these scenarios elegantly.

The DHCP Discover message is the client's announcement that it needs network configuration. Since the client has no IP address, it cannot send unicast traffic—it must broadcast to reach any DHCP server on the local network.

The Bootstrap Problem:

DHCP Discover elegantly solves the network bootstrap problem:

• The client needs an IP address to communicate
• But it needs to communicate to get an IP address

The solution: broadcast at Layer 2. The client sends an Ethernet frame to the broadcast MAC address (FF:FF:FF:FF:FF:FF), containing a UDP packet from 0.0.0.0:68 to 255.255.255.255:67. Every device on the Layer 2 network receives this frame, and any DHCP server processes it.

Key DHCP Discover Options:

DHCP messages include an options field that carries additional parameters. Important Discover options include:

• Option 53 (Message Type): Value 1 (DHCP Discover)
• Option 50 (Requested IP): If the client previously had an address, it may request the same one
• Option 55 (Parameter Request List): List of options the client wants (DNS, gateway, etc.)
• Option 61 (Client Identifier): Alternative to MAC for client identification
• Option 12 (Hostname): Client's hostname for DNS registration
• Option 60 (Vendor Class Identifier): Identifies client type for vendor-specific options

Timing Considerations:

If no Offer is received within a timeout period (typically 1-4 seconds), the client retransmits the Discover. Retransmission uses exponential backoff with randomization to prevent synchronized broadcast storms when many clients start simultaneously (as might happen after a power restoration).

Upon receiving a valid Discover, a DHCP server responds with an Offer message proposing an IP address and configuration parameters. The server selects an address from its available pool (or uses a reservation if one exists for the client's MAC address).

Address Selection Process:

1. Check for existing lease for this client (by MAC or client ID)
2. If client requested a specific address (Option 50), check if it's available
3. Select an address from the configured pool
4. Verify the address isn't in use (some servers ping before offering)
5. Reserve the address temporarily pending client acceptance

Offer Message Characteristics:

Broadcast vs Unicast Response:

The Offer can be sent as broadcast or unicast:

• Unicast: If the client's network stack can receive unicast before configuration (most modern systems), the server sends directly to the client's MAC address
• Broadcast: If the BROADCAST flag is set in the Discover, the server broadcasts the Offer so the client can receive it without an IP address configured

Server Competition:

When multiple DHCP servers exist, each responds independently with its own Offer. The client collects offers (typically waiting a short period for additional offers to arrive) and then selects one based on:

1. Previously used server (if reconnecting)
2. Server offering the client's preferred address
3. First offer received (common default behavior)
4. Administrative preferences (if client is configured)

The client's selection is communicated via the Request broadcast, ensuring all servers know the outcome.

After receiving one or more Offers, the client broadcasts a DHCP Request to accept a specific offer. This message serves multiple crucial purposes in the DORA process.

Why the Request is Essential:

1. Confirms selection: Tells the chosen server that its offer is accepted
2. Notifies other servers: All servers learn which offer was accepted (and not theirs)
3. Allows server validation: The server can reject the request if conditions changed
4. Creates binding: Server commits the address to the client until lease expiration
5. Enables renewal: The same message type is used for lease renewal

Request Message Contents:

The Request message includes critical information to identify both the accepted offer and the accepting client:

• Option 53 (Message Type): Value 3 (DHCP Request)
• Option 54 (Server Identifier): IP of the server whose offer is being accepted
• Option 50 (Requested IP Address): The specific IP address being requested
• chaddr: Client's MAC address for server identification
• xid: Same transaction ID from the Discover (for correlation)

Why Broadcast?

The DHCP Request is broadcast even though the client knows the server's address. This broadcast serves as an implicit DHCPDECLINE to all other servers: by including the Server Identifier of the accepted server, other servers know their offers were not selected and can release those addresses back to their pools.

Without this broadcast, rejected servers would hold addresses in a pending state until an offer timeout, reducing pool efficiency.

The DHCP Acknowledgment (ACK) is the final message of the DORA process, confirming that the requested address is now assigned to the client. Upon receiving the ACK, the client performs final validation and then configures its network interface.

ACK Message Contents:

The ACK includes all the configuration parameters the client needs:

• yiaddr: Confirmed client IP address
• Option 51 (Lease Time): Lease duration in seconds
• Option 58 (T1 - Renewal Time): When to start renewal (usually 50% of lease)
• Option 59 (T2 - Rebinding Time): When to start rebinding (usually 87.5% of lease)
• Option 1 (Subnet Mask): Network mask
• Option 3 (Router): Default gateway list
• Option 6 (DNS Servers): DNS server list
• Option 15 (Domain Name): DNS domain suffix
• Plus any additional options the client requested

Client Post-ACK Behavior:

After receiving the ACK, the client performs several validation and configuration steps:

1. Conflict Detection (ARP Probe):

   • Client sends ARP requests for the assigned address
   • If another device responds, the address is in use (conflict!)
   • Client sends DHCPDECLINE to server and restarts DORA

2. Interface Configuration:

   • Configures IP address on the network interface
   • Sets subnet mask and routes
   • Updates DNS resolver configuration
   • Starts lease timers (T1 for renewal, T2 for rebinding)

3. Lease Recording:

   • Stores lease information for INIT-REBOOT on restart
   • Records server identifier for renewal unicasts

4. Gratuitous ARP (Optional):

   • Broadcasts ARP announcement with new address
   • Updates ARP caches on local network
   • Helps clear stale entries from previous address holder

A DHCP lease is not a one-time assignment—it's a contract with a lifecycle. Understanding the lease timers is essential for designing reliable DHCP infrastructure and troubleshooting lease-related issues.

The Three Lease Timers:

Timer Calculation Example:

For a 24-hour (86400 second) lease:

The Renewal Optimization:

Renewal (at T1) attempts unicast to the original server because:

1. Reduced broadcast traffic: Unicast doesn't bother other network devices
2. Server affinity: The same server maintains lease continuity
3. Failure isolation: Operations continue if other servers are down
4. Bandwidth efficiency: Important for networks with many clients

Rebinding (at T2) uses broadcast because:

1. Original server unreachable: Unicast renewal failed
2. Any server can help: Redundant servers can take over
3. Prevent address loss: Last resort before lease expiration

The DORA process includes robust error handling mechanisms for various failure scenarios. Understanding these mechanisms is essential for troubleshooting.

DHCP Decline:

When a client receives an ACK but detects that the assigned address is already in use (via ARP probe), it sends a DHCPDECLINE message:

• Broadcast message indicating the offered address cannot be used
• Server marks the address as unavailable/conflicting in its pool
• Client restarts DORA process from Discover
• The conflicting address may remain marked unavailable until manual intervention or timeout

DHCP Release:

Clients can proactively release their address before lease expiration by sending a DHCPRELEASE:

• Unicast to the server that granted the lease
• Returns address to pool immediately
• Should be sent during graceful shutdown (e.g., ipconfig /release on Windows)
• Server deletes the lease record
• Note: Many clients don't send RELEASE on shutdown—they just disconnect

We've completed a deep examination of the DORA process—the fundamental message exchange that enables automatic network configuration. Let's consolidate the key takeaways:

What's Next:

With the DORA process understood, the next page explores DHCP message types and options in greater detail—the extensible mechanism that allows DHCP to deliver not just addresses but dozens of configuration parameters including DNS, NTP, TFTP boot servers, and vendor-specific options.