LFCE 41 🐧 DHCP Server — Concepts
The Dynamic Host Configuration Protocol is the mechanism that assigns IP addresses and related configuration to devices automatically. Without it, every device on a network would require manual configuration of its address, subnet mask, default gateway, and DNS servers. DHCP centralizes this assignment, making it possible to add devices, move them between subnets, and reclaim addresses when devices leave, without touching each device individually. For the LFCE candidate, DHCP is a core network service that appears alongside DNS in the networking objectives, and understanding its operation is prerequisite to configuring any of the DHCP server implementations available on Linux.
This chapter covers the protocol concepts: the DORA exchange that assigns a lease, the lease lifecycle that renews and eventually expires it, the DHCP options that carry configuration beyond the address, and the relay mechanism that allows a single server to serve multiple subnets. The next chapters cover the specific server software—ISC DHCP, Kea, and dnsmasq—but the protocol behavior is the same regardless of which implementation serves it.
Key point: DHCP uses the DORA exchange—Discover, Offer, Request, Acknowledge—to assign a lease. The client broadcasts a Discover, the server responds with an Offer, the client broadcasts a Request for the offered address, and the server confirms with an Acknowledge. All communication uses UDP ports 67 (server) and 68 (client). The lease has a duration, and the client must renew it before it expires or lose the address.
Why DHCP exists
The manual-configuration problem.
Every device that connects to an IP network needs an address, a subnet mask, a gateway, and at least one DNS server. Manual configuration works for a handful of servers, but it does not scale to laptops, phones, printers, and guest devices that join and leave the network unpredictably. DHCP automates the assignment. The server holds a pool of addresses, assigns one to each client that requests it, and reclaims it when the lease expires or the client releases it. The client receives not just an address but the full set of options it needs to communicate .
The mobility problem.
A laptop that moves between the office, a conference room, and a home network cannot keep a static address, because the subnet changes. DHCP allows the device to receive a new address appropriate to its current location. The server knows which subnet the request arrived on—either because it is directly connected to that subnet or because a relay agent forwarded the request with information about the source subnet—and assigns an address from the correct pool . This is why a single DHCP server can serve multiple subnets without manual intervention on the client side.
The configuration-distribution problem.
An IP address alone is insufficient for network communication. The client also needs a default gateway to reach other subnets, DNS servers to resolve names, and often NTP servers, a domain name, or a TFTP server for PXE boot. DHCP options carry these parameters. A single DHCP exchange delivers the entire configuration, and the client applies it without user interaction . This is what makes “plug in the cable and it works” possible.
a. The DORA exchange and lease assignment
The DHCP client-server interaction follows a fixed sequence known by the acronym DORA: Discover, Offer, Request, Acknowledge. The exchange is broadcast-based because the client does not yet have an IP address and does not know the server’s address.
# The DORA exchange in sequence
# 1. DHCPDISCOVER: client broadcasts to 255.255.255.255:67
# "Is there a DHCP server on this network?"
# 2. DHCPOFFER: server responds with an offered address and options
# "I can offer 192.168.1.100/24 with gateway 192.168.1.1"
# 3. DHCPREQUEST: client broadcasts to 255.255.255.255:67
# "I accept the offer from this server for 192.168.1.100"
# 4. DHCPACK: server confirms the lease
# "The address 192.168.1.100 is yours for 86400 seconds"The Discover is broadcast because the client has no address and no knowledge of any server. The Offer is typically broadcast as well, though some implementations can unicast it if the client sets the broadcast flag. The Request is broadcast so that any other DHCP servers that made offers learn that their offers were declined. The Acknowledge is the final confirmation that binds the lease .
The server maintains a lease database that records which address is assigned to which client (identified by MAC address or client identifier) and when the lease expires. The address is not available for reassignment until the lease expires or the client releases it. This prevents two clients from receiving the same address .
b. The lease lifecycle: renewal and rebinding
A DHCP lease has a duration, typically configured by the server. The client must renew the lease before it expires, or it loses the right to use the address. The renewal process has two stages: unicast renewal at 50% of the lease time, and broadcast rebinding at 87.5% .
# Lease lifecycle with a 24-hour lease (86400 seconds)
# T=0: DHCPACK received; lease is active
# T=12h: T1 timer fires (50% of lease)
# Client sends unicast DHCPREQUEST to the original server
# Server responds with DHCPACK, extending the lease
# T=21h: T2 timer fires (87.5% of lease)
# If the unicast renewal failed, client broadcasts DHCPREQUEST
# Any DHCP server on the network may respond
# T=24h: Lease expires
# If no renewal succeeded, client must stop using the address
# and begin a new DORA exchangeThe T1 timer is the renewal time, set to 50% of the lease duration by default. The client sends a unicast Request to the server that granted the lease. If the server responds with an Acknowledge, the lease is extended and the timers reset. If the server does not respond, the client waits until the T2 timer, which is 87.5% of the lease duration, and then broadcasts a Request to any available server. This rebinding stage allows a different server to take over the lease if the original is unreachable .
The lease duration is a trade-off. A short lease (hours) allows addresses to be reclaimed quickly when devices leave, which is important in networks with many transient devices. A long lease (days or weeks) reduces DHCP traffic and keeps addresses stable for devices that stay connected. The server configuration determines the duration, and the client can request a specific duration, though the server may override it .
c. DHCP options and relay agents
DHCP options are numbered fields in the DHCP packet that carry configuration parameters beyond the IP address. The client requests the options it needs in the Discover message, and the server includes them in the Offer and Acknowledge. Standard options include the subnet mask (option 1), router (option 3), DNS servers (option 6), domain name (option 15), and broadcast address (option 28) . Vendor-specific options, such as option 43 for PROFINET devices, allow manufacturers to distribute device-specific configuration through the same exchange.
# Common DHCP options and their numbers
# Option 1: Subnet Mask
# Option 3: Router (default gateway)
# Option 6: Domain Name Server
# Option 15: Domain Name
# Option 28: Broadcast Address
# Option 42: NTP Servers
# Option 43: Vendor Specific Information
# Option 60: Vendor Class Identifier
# Option 82: Relay Agent InformationA relay agent is required when the DHCP client and server are on different subnets. The client broadcasts its Discover, but routers do not forward broadcasts by default. A relay agent, configured on the router or a Linux host, receives the broadcast and forwards it as a unicast packet to the DHCP server, including information about the subnet where the request originated. The server uses that information to select the correct address pool and sends the response back through the relay agent . Option 82 carries additional relay information, such as the circuit ID or remote ID, which the server can use to assign addresses based on the physical port or the relay agent’s identity.
Complete Example Session
# ============================================
# PART 1: INSPECT A DHCP CLIENT'S LEASE
# ============================================
# On a client system, the lease information is stored by the DHCP client
cat /var/lib/dhcp/dhclient.leases
# Output includes the assigned address, lease duration, and options
# ============================================
# PART 2: CAPTURE THE DORA EXCHANGE
# ============================================
# Use tcpdump to observe the four packets
sudo tcpdump -i eth0 -n port 67 or port 68
# Output shows DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK
# ============================================
# PART 3: RELEASE AND RENEW A LEASE
# ============================================
# Release the current lease
sudo dhclient -r eth0
# Request a new lease (triggers DORA)
sudo dhclient eth0
# ============================================
# PART 4: EXAMINE THE CLIENT CONFIGURATION
# ============================================
ip addr show eth0
ip route show
cat /etc/resolv.conf
# All of these were populated from the DHCP options
# ============================================
# PART 5: SIMULATE A RELAY AGENT CONFIGURATION
# ============================================
# On a router between subnets, the relay forwards DHCP requests
# The interface facing the clients listens for broadcasts
# The interface facing the server sends unicasts
# On the relay host:
# Enable IP forwarding
sysctl -w net.ipv4.ip_forward=1
# The relay agent (dhcrelay) is configured with the server address
# and the interface facing the clients
# dhcrelay -i eth1 192.168.1.10
# ============================================
# PART 6: VERIFY OPTION DELIVERY
# ============================================
# The lease file shows the options the client received
grep -E "option (routers|domain-name-servers|subnet-mask)" /var/lib/dhcp/dhclient.leases
# Output shows the gateway, DNS servers, and subnet mask
# ============================================
# PART 7: CHECK LEASE TIMING
# ============================================
# The lease file includes the renewal and rebind times
grep -E "renew|rebind|expire" /var/lib/dhcp/dhclient.leases
# renew: T1 (50% of lease)
# rebind: T2 (87.5% of lease)
# expire: end of leaseThe seven parts demonstrate the protocol from the client’s perspective: inspecting the lease, capturing the DORA exchange, releasing and renewing, examining the resulting configuration, simulating a relay agent, verifying option delivery, and checking lease timing. The critical observation is in Part 2: the four packets of the DORA exchange are visible on the wire, and the client’s configuration is populated entirely from the options in the Acknowledge.
Quick Reference
The DORA Exchange
| Step | Message | Direction | Purpose |
|---|---|---|---|
| 1 | DHCPDISCOVER | Client → Broadcast | Find available servers |
| 2 | DHCPOFFER | Server → Client | Propose an address and options |
| 3 | DHCPREQUEST | Client → Broadcast | Accept an offer |
| 4 | DHCPACK | Server → Client | Confirm the lease |
Lease Timers
| Timer | Percentage | Action |
|---|---|---|
| T1 (renewal) | 50% of lease | Unicast Request to original server |
| T2 (rebinding) | 87.5% of lease | Broadcast Request to any server |
| Expiry | 100% of lease | Stop using the address; new DORA |
Common DHCP Options
| Option | Name | Purpose |
|---|---|---|
| 1 | Subnet Mask | Network mask for the address |
| 3 | Router | Default gateway |
| 6 | Domain Name Server | DNS resolver addresses |
| 15 | Domain Name | DNS domain suffix |
| 28 | Broadcast Address | Subnet broadcast address |
| 42 | NTP Servers | Time synchronization |
| 43 | Vendor Specific | Manufacturer-specific parameters |
| 82 | Relay Agent Info | Circuit ID / Remote ID |
Ports and Protocol
| Component | Port | Protocol |
|---|---|---|
| DHCP Server | 67 | UDP |
| DHCP Client | 68 | UDP |
Best Practices
✅ Do This:
# Use a lease duration appropriate to the network
# Short for transient devices, long for stable infrastructure # ✅
# Configure the full option set: mask, gateway, DNS, domain
# Clients need all of these to communicate # ✅
# Use a relay agent when the server is on a different subnet
# The relay includes the source subnet information # ✅
# Monitor the DORA exchange with tcpdump when troubleshooting
tcpdump -i eth0 -n port 67 or port 68 # ✅
# Keep the lease database backed up
# The server needs it to avoid address conflicts # ✅❌ Don’t Do This:
# Assign overlapping address pools on the same subnet
# Two servers offering the same address causes conflicts # ❌
# Use a lease duration longer than the device's expected lifetime
# Addresses are wasted and the pool exhausts # ❌
# Forget the default gateway option
# Clients receive an address but cannot reach other subnets # ❌
# Assume broadcasts cross routers
# Without a relay agent, the server never sees the request # ❌
# Ignore the T1/T2 timers
# A client that cannot renew loses its address at expiry # ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Client receives no address | No DHCP server on the subnet and no relay | Configure a relay agent |
| Address conflict | Two servers assigning the same address | Separate pools or a single server |
| Client loses address after lease | Renewal failed and rebinding failed | Check server availability and network path |
| Client cannot reach internet | Gateway option not configured | Add option 3 to the server configuration |
| Relay not forwarding | ip_forward disabled on relay host | sysctl -w net.ipv4.ip_forward=1 |
| Pool exhausted | Lease duration too long for transient devices | Reduce lease time or expand the pool |
Real-World Examples
1. DORA exchange capture
tcpdump -i eth0 -n port 67 or port 682. Release and renew
dhclient -r eth0; dhclient eth03. Inspect lease file
cat /var/lib/dhcp/dhclient.leases4. Check lease timers
grep -E "renew|rebind|expire" /var/lib/dhcp/dhclient.leases5. Enable forwarding on a relay host
sysctl -w net.ipv4.ip_forward=16. Start a relay agent
dhcrelay -i eth1 192.168.1.107. Verify gateway option
grep "option routers" /var/lib/dhcp/dhclient.leases8. Verify DNS option
grep "option domain-name-servers" /var/lib/dhcp/dhclient.leases9. Check client address
ip addr show eth010. Check client route
ip route showVisual
The DORA Exchange
┌──────────────────────────────────────────────────────────────┐
│ DORA: FOUR BROADCAST/MULTICAST STEPS │
│ │
│ Client Server │
│ ┌─────────┐ ┌─────────┐ │
│ │ │─── DHCPDISCOVER ──────▶│ │ │
│ │ │ (broadcast) │ │ │
│ │ │◀── DHCPOFFER ──────────│ │ │
│ │ │ (offer + options) │ │ │
│ │ │─── DHCPREQUEST ───────▶│ │ │
│ │ │ (broadcast) │ │ │
│ │ │◀── DHCPACK ────────────│ │ │
│ │ │ (lease confirmed) │ │ │
│ └─────────┘ └─────────┘ │
│ │
│ All packets use UDP ports 67 (server) and 68 (client). │
│ The client has no address during Discover. │
└──────────────────────────────────────────────────────────────┘Lease Lifecycle
┌──────────────────────────────────────────────────────────────┐
│ RENEWAL AND REBINDING TIMERS │
│ │
│ Lease duration: 24 hours │
│ │
│ T=0 ─────────────────────────────────────────────── T=24h │
│ │ │
│ ├── T1 (50%) ── T=12h │
│ │ Client unicasts Request to original server │
│ │ If ACK: lease extended, timers reset │
│ │ │
│ ├── T2 (87.5%) ── T=21h │
│ │ If unicast failed, client broadcasts Request │
│ │ Any server may respond │
│ │ │
│ └── Expiry ── T=24h │
│ If no ACK, client stops using the address │
│ and begins a new DORA exchange │
└──────────────────────────────────────────────────────────────┘Relay Agent
┌──────────────────────────────────────────────────────────────┐
│ RELAY FORWARDS BROADCASTS ACROSS SUBNETS │
│ │
│ Subnet A (192.168.1.0/24) Subnet B (192.168.2.0/24) │
│ ┌─────────┐ ┌─────────┐ │
│ │ Client │─── Discover ──────▶│ Relay │ │
│ │ (no IP) │ (broadcast) │ Agent │ │
│ └─────────┘ └────┬────┘ │
│ │ │
│ │ Unicast to server │
│ │ with subnet info │
│ ▼ │
│ ┌─────────┐ │
│ │ DHCP │ │
│ │ Server │ │
│ └─────────┘ │
│ │
│ The relay includes the source subnet (Option 82). │
│ The server selects the pool for that subnet. │
└──────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Protocol | DHCP (Dynamic Host Configuration Protocol) |
| Exchange | DORA: Discover, Offer, Request, Acknowledge |
| Server port | UDP 67 |
| Client port | UDP 68 |
| Lease renewal | T1 at 50% (unicast) |
| Lease rebinding | T2 at 87.5% (broadcast) |
| Lease expiry | 100%; client stops using address |
| Address assignment | Pool managed by the server |
| Configuration delivery | DHCP options (mask, gateway, DNS, etc.) |
| Multi-subnet support | Relay agent (Option 82) |
Key takeaways:
- DHCP assigns leases, not permanent addresses. The client receives an address for a duration, and must renew it before expiry. The DORA exchange establishes the lease, and the T1/T2 timers govern its renewal .
- The DORA exchange is broadcast-based. The client has no address and does not know the server’s address, so it broadcasts the Discover. The Request is also broadcast so that other servers learn their offers were declined.
- The lease has a lifecycle. T1 (50%) is the unicast renewal. T2 (87.5%) is the broadcast rebinding. At expiry, the client must stop using the address and start a new DORA exchange .
- DHCP options deliver more than an address. The gateway (option 3), DNS servers (option 6), domain name (option 15), and other parameters are carried in the same exchange. Without them, the client has an address but cannot communicate beyond its subnet .
- Relay agents are required for multi-subnet deployments. Routers do not forward broadcasts. A relay agent receives the broadcast, forwards it as a unicast to the server with the source subnet information, and returns the response .
- The lease database prevents conflicts. The server records which address is assigned to which client and when it expires. An address is not reassigned until the lease is released or expired.
Remember: DHCP is the protocol that makes IP networks self-configuring. The DORA exchange assigns a lease. The T1 and T2 timers renew and rebind it. The options carry the configuration that the client needs to communicate. The relay agent extends the service across subnets. The lease duration is a trade-off between address reclamation and DHCP traffic. Understanding these concepts is prerequisite to configuring any DHCP server on Linux, because the server software—ISC DHCP, Kea, or dnsmasq—implements this protocol regardless of its configuration syntax.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!