DHCP DORA Process & Common DHCP Options: Router, DNS and TFTP

Every device that joins an enterprise local area network requires a unique IP address, subnet mask, default gateway, and DNS resolver to participate in IP communications. While manual static configuration is mandatory for servers, core routers, and perimeter appliances, dynamic client provisioning across hundreds or thousands of endpoints relies on the Dynamic Host Configuration Protocol (DHCP, RFC 2131).

DHCP operates on top of the User Datagram Protocol (UDP), utilizing UDP port 67 for destination servers and UDP port 68 for destination clients. Understanding the exact message mechanics of the four-step handshake, lease renewal state machines, and configuration options is essential for diagnosing network admission and provisioning failures.

The DORA Four-Step Transaction Flow

When a client interface initializes or links up without a static IP, it executes the standardized four-message DORA handshake to obtain a valid IP lease:

The transaction details carry critical operational nuances:

• DHCPDISCOVER: Because the client possesses no IP address, its source is set to 0.0.0.0 and destination is the limited broadcast address 255.255.255.255. Routers discard this broadcast by default unless a DHCP Relay Agent (such as Cisco ip helper-address) is configured on the local switch virtual interface (SVI).
• DHCPOFFER: The server reserves an available IP from its pool and transmits configuration parameters. In multi-server environments, the client may receive multiple DHCPOFFER packets from different servers.
• DHCPREQUEST (Broadcast Selection): Even though the client has selected an offer from a specific server, it broadcasts the DHCPREQUEST packet containing the chosen server's IP in Option 54. This informs the selected server to commit the lease, while simultaneously signaling all other DHCP servers that their offers were declined so they can return the unselected addresses to their available pools.
• DHCPACK vs DHCPNAK: The selected server commits the lease to its database and sends a DHCPACK. If the requested IP address became unavailable in the interim or belongs to an invalid subnet, the server transmits a DHCPNAK, forcing the client to restart the DORA cycle.

Lease Timers: T1, T2, and Expiration State Machine

DHCP leases are temporary allocations governed by three deterministic timer milestones calculated from the lease duration (Option 51):

1. T1 (Renewal Timer, 50% of Lease Duration): When the lease reaches 50% of its lifetime (e.g., 4 days on an 8-day lease), the client attempts to renew directly with the issuing DHCP server. The client transmits a unicast DHCPREQUEST directly to the server's IP address. If the server is operational, it responds with a unicast DHCPACK, resetting the lease timer back to 100%.
2. T2 (Rebinding Timer, 87.5% of Lease Duration): If the issuing server is unreachable (down for maintenance or decommissioned) and T1 expires without acknowledgment, the client continues using the assigned IP until reaching 87.5% of the lease duration (e.g., 7 days on an 8-day lease). At T2, the client transitions to the Rebinding state: it transmits a broadcast DHCPREQUEST (255.255.255.255) across the subnet, asking any reachable DHCP server on the network to extend its existing lease.
3. Lease Expiration (100%): If no server acknowledges the request before the lease duration reaches 0, the client immediately drops the IP address, unbinds its routing table entries, and falls back to Automatic Private IP Addressing (APIPA, 169.254.0.0/16) or restarts the DORA cycle from scratch.

Common Enterprise DHCP Scope Options

Beyond assigning an IP and subnet mask, DHCP conveys crucial network infrastructure metadata through standardized numerical option fields (RFC 2132):

Verification and Troubleshooting Commands

To inspect active DHCP lease negotiation and verify assigned scope parameters on administrative hosts:

On Windows hosts via PowerShell:

# Inspect current DHCP lease parameters and lease expiration timestamp
Get-NetIPAddress -AddressFamily IPv4 -InterfaceAlias "Ethernet*" | Format-Table IPAddress, InterfaceAlias, PrefixLength

# Query detailed DHCP configuration and assigned lease lifetime via WMI
Get-CimInstance -ClassName Win32_NetworkAdapterConfiguration | Where-Object { $_.DHCPEnabled } | Select-Object Description, DHCPServer, DHCPLeaseObtained, DHCPLeaseExpires

# Release and renew active IPv4 lease
ipconfig /release
ipconfig /renew

On Linux systems utilizing iproute2 and journalctl:

# Inspect assigned address and interface link state
ip -4 addr show dev eth0

# Follow systemd-networkd or NetworkManager DHCP client transactions in real-time
journalctl -u NetworkManager -g "dhcp4" --no-pager -n 25

# Force lease renewal using dhclient
sudo dhclient -r eth0 && sudo dhclient eth0

To isolate DHCP packet loss, run Wireshark or tcpdump filtering for UDP ports 67 and 68:

# Capture raw DORA packets on interface eth0
sudo tcpdump -i eth0 -n -vvv "udp port 67 or udp port 68"

Verify that the xid (Transaction ID) remains identical across the DISCOVER, OFFER, and REQUEST phases, proving that the client and server are tracking the same discrete dialogue.