DHCP — Dynamic Host Configuration Protocol

DHCP's predecessor was BOOTP (Bootstrap Protocol, RFC 951, 1985), which could assign IP addresses to diskless workstations from a static table. BOOTP required manually configured MAC-to-IP mappings for every device — better than pure static configuration, but still not dynamic. DHCP extended BOOTP to add dynamic address pools, lease-based allocation, and a rich options framework.

Today, DHCP is invisible infrastructure. Every device you connect to any network — home Wi-Fi, corporate LAN, mobile data, coffee shop — receives its IP configuration via DHCP within seconds. The DORA exchange (Discover, Offer, Request, ACK) runs before the first application packet leaves the machine.

Message 1: DHCPDISCOVER (Client Broadcast)

The DISCOVER message is a UDP datagram with:

— Source IP: 0.0.0.0 (client has no address)

— Destination IP: 255.255.255.255 (limited broadcast)

— Source port: 68 (DHCP client port)

— Destination port: 67 (DHCP server port)

The DISCOVER payload is a BOOTP-derived message with the client's MAC address in the chaddr field and a random transaction ID (xid) used to match subsequent messages. The client includes Option 55 (Parameter Request List) asking for specific configuration: subnet mask, gateway, DNS, domain name, NTP, etc.

Message 2: DHCPOFFER (Server Response)

Each DHCP server that receives the DISCOVER responds with an OFFER. The server selects an available IP from its pool, temporarily reserves it, and sends the offer with:

— yiaddr: the offered IP address ("your IP address")

— Option 51: proposed lease time

— Option 54: server identifier (server's own IP)

— Options 1, 3, 6: subnet mask, gateway, DNS

The OFFER may still be broadcast (if the client's IP is not yet set) or unicast to the MAC address. Multiple servers may offer; the client accepts the first response by default.

Message 3: DHCPREQUEST (Client Broadcast)

The client broadcasts a REQUEST selecting one server's offer. Broadcasting is deliberate: all servers that sent offers hear the REQUEST. Servers not selected see their IP reservation released. The REQUEST includes Option 54 (Server Identifier) naming the chosen server and Option 50 (Requested IP Address) confirming the offered IP.

Message 4: DHCPACK (Server Confirmation)

The selected server sends an ACK confirming the lease. The client configures its interface: sets the IP, subnet mask, default route, and DNS servers. Starts the lease timers. The client may run ARP probing (sending gratuitous ARPs) to verify the assigned IP is not already in use.

DHCP leases have three time points that drive the lease state machine:

T1 — Renewal Time (Option 58)

At T1 (typically 50% of the lease duration), the client enters RENEWING state and unicasts a DHCPREQUEST directly to its DHCP server. This is an efficient unicast renewal — the server simply extends the lease. If the server responds with ACK, the lease resets to a fresh duration.

T2 — Rebind Time (Option 59)

At T2 (typically 87.5% of the lease), the client enters REBINDING state. The original server hasn't responded to renewals (it may be down). The client now broadcasts to any DHCP server. Any server can extend the lease — not necessarily the original one. This allows DHCP failover to transparently serve rebinding clients.

Lease Expiry

If no server responds by expiry, the client must stop using the IP. It returns to INIT state and starts DORA again. During INIT, the client has no valid IP — ongoing connections are broken. This is why DHCP servers should be redundant (DHCP failover) and lease times should be long enough to survive server maintenance windows.

Choosing Lease Times

Short leases (minutes to hours): good for environments with high device turnover (cafes, conferences, hotels), but increase server load and cause more DORA exchanges. If a server is down during T1/T2, clients lose connectivity faster.

Long leases (days to weeks): stable addresses, less protocol chatter, better for corporate desktops and servers. But address pool exhaustion risk if many devices disconnect without releasing.

DHCP RELEASE: clients should send a RELEASE message when they disconnect voluntarily (e.g., at shutdown or when the interface goes down). This immediately frees the address. However, servers must not depend on this — mobile devices often vanish without sending RELEASE.

DHCP options are Type-Length-Value (TLV) encoded fields appended to the base BOOTP packet. The magic cookie (0x63825363) at the start of the options field identifies the packet as DHCP. Options range from code 0 to 255; code 255 signals end of options. The base packet format (chaddr, siaddr, giaddr, etc.) comes from BOOTP; everything else is in options.

Option 82: DHCP Relay Agent Information

Option 82 is added by DHCP relay agents (routers that forward DHCP packets between VLANs). It contains sub-options identifying which switch port the client connected to. The DHCP server can use this to assign addresses from pool appropriate for that VLAN, log exact client location, or enforce security policies. This is critical in large networks where clients connect from many different VLANs but the DHCP server is centralized.

Option 121: Classless Static Routes

Option 121 (RFC 3442) pushes static routes to clients: a list of CIDR prefix + next-hop pairs. RFC 3442 mandates that if Option 121 is present, clients must use it and MUST ignore Option 3 (default gateway) for routing purposes. This allows DHCP to install specific routes for split tunnels, VPN routing, or steering traffic to specific next-hops.

A DHCP relay agent (also called a BOOTP relay or IP helper) is typically configured on a router or L3 switch. When a DHCP broadcast arrives on a VLAN interface, the relay agent:

1. Intercepts the DHCPDISCOVER broadcast on the client's subnet.

2. Sets the giaddr (gateway IP address) field in the DHCP packet to the relay agent's own interface IP.

3. Unicasts the modified packet to the configured DHCP server address.

4. When the server replies, the relay agent forwards the response back to the client (broadcast if ciaddr=0.0.0.0).

# Cisco IOS L3 interface configuration
interface Vlan10
  ip address 10.1.10.1 255.255.255.0
  ip helper-address 10.0.0.5    # Unicast DHCP to server at 10.0.0.5

interface Vlan20
  ip address 10.1.20.1 255.255.255.0
  ip helper-address 10.0.0.5

# The DHCP server sees giaddr=10.1.10.1 or 10.1.20.1
# and allocates from the matching scope/pool

The DHCP server uses giaddr to determine which subnet pool to allocate from. Configure a matching scope for each VLAN's subnet in the DHCP server. Without giaddr, the server would have no idea which network the client is on.

MAC-Based Reservations

DHCP reservations bind a specific MAC address to a specific IP. The IP is allocated from the DHCP pool, but it is always given to that MAC. Configuration varies by server:

# ISC DHCP (dhcpd.conf)
host printer-a3 {
  hardware ethernet AA:BB:CC:DD:EE:FF;
  fixed-address 192.168.1.50;
  option host-name "printer-a3";
}

# Windows DHCP Server PowerShell
Add-DhcpServerv4Reservation -ScopeId 192.168.1.0 -IPAddress 192.168.1.50   -ClientId "AA-BB-CC-DD-EE-FF" -Description "Printer A3"

# Dnsmasq
dhcp-host=AA:BB:CC:DD:EE:FF,192.168.1.50,printer-a3

Client Identifier vs. MAC Address

DHCP uses the client's hardware address (MAC, chaddr) for identification by default. But clients can also send a Client Identifier (Option 61) — typically a string. This allows servers to identify clients by something other than MAC, useful for VMs with changing MAC addresses or virtual interfaces.

Dynamic DNS Updates

Modern DHCP servers (ISC DHCP, Windows DHCP) can update DNS records when leases are assigned. When a client gets IP 192.168.1.100 with hostname "laptop42", the DHCP server updates the DNS zone to add an A record for laptop42.corp.example.com. This keeps DNS in sync with DHCP assignments — critical for environments where hosts need to be reachable by name.

Rogue DHCP Server Attack

Any device on a network can run a DHCP server — there is no authentication in the protocol. A rogue DHCP server can:

— Assign arbitrary DNS servers → DNS hijacking, phishing, MITM

— Assign the attacker as default gateway → full traffic intercept

— Assign wrong subnet masks → network communication failures

— Assign the same IP to multiple clients → address conflict denial-of-service

DHCP Snooping: The Defense

DHCP snooping is a Layer 2 switch feature that validates DHCP messages and limits which ports can send DHCP server responses:

Trusted ports: uplinks to routers, DHCP servers, and aggregation switches. DHCP OFFER and ACK are allowed through.

Untrusted ports: access ports connected to end users. DHCP OFFER and ACK are dropped — only DISCOVER and REQUEST (client messages) are permitted. DHCP server responses from these ports are blocked.

# Cisco IOS DHCP snooping
ip dhcp snooping
ip dhcp snooping vlan 10,20,30

interface GigabitEthernet0/1   # uplink to DHCP server
  ip dhcp snooping trust

interface GigabitEthernet0/2   # access port (end user)
  # untrusted by default
  ip dhcp snooping limit rate 15  # rate limit: 15 DHCP pkt/s per port

DHCP Snooping Binding Table

DHCP snooping maintains a binding table: MAC address → IP address → VLAN → switch port → lease time. This table is consumed by other security features:

— Dynamic ARP Inspection (DAI): validates that ARP replies map to binding table entries, preventing ARP spoofing.

— IP Source Guard (IPSG): drops packets from ports where the source IP doesn't match the binding table, preventing IP spoofing.

DHCP Starvation Attack

An attacker sends thousands of DHCPDISCOVER messages with spoofed MAC addresses, exhausting the DHCP pool. Legitimate clients cannot get addresses (DHCPNAK or no response). Defense: DHCP snooping rate limiting per port, 802.1X port authentication before allowing DHCP traffic.

PXE Boot DHCP Flow

1. Client broadcasts DISCOVER with Option 60 (Vendor Class Identifier) set to PXEClient:Arch:00000:UNDI:002001 (or similar, encoding architecture and network driver version).

2. DHCP server recognizes the PXE client and includes in the ACK:

— Option 66: TFTP server hostname (where to download the bootloader)

— Option 67: Boot filename (e.g., pxelinux.0 for BIOS, bootx64.efi for UEFI)

3. Client downloads the bootloader via TFTP (UDP port 69) from the specified server.

4. Bootloader may issue a second DHCP exchange (ProxyDHCP) for additional PXE-specific options.

5. Bootloader downloads OS image/kernel and boots.

DHCP and UEFI HTTP Boot

Modern UEFI systems support HTTP boot as an alternative to TFTP. DHCP delivers the boot URL via Option 67 as an HTTP/HTTPS URL (http://deploy.corp/grubx64.efi). The UEFI firmware fetches the bootloader via HTTP, enabling faster and more reliable delivery than TFTP (which uses unreliable UDP).

SLAAC vs. DHCPv6

SLAAC (Stateless Address Autoconfiguration, RFC 4862): router sends Router Advertisement (RA) with the /64 prefix. Host generates its interface ID using Modified EUI-64 (from MAC address) or a random stable address (RFC 7217). No server needed, no lease records, no central tracking. Address persists until RA stops.

DHCPv6 Stateful: like DHCPv4 — server maintains a lease database, assigns specific addresses from pools, records client MAC/DUID and assigned address. Enables per-host tracking and central address management.

DHCPv6 Stateless: the host uses SLAAC for its address but sends a DHCPv6 Information-Request to get other options (DNS, NTP, SIP servers) that SLAAC alone cannot provide.

The M and O Flags in Router Advertisements

Router Advertisements include two flags that tell hosts which method to use:

— M flag (Managed): if set, hosts should use DHCPv6 for addresses.

— O flag (Other): if set, hosts should use DHCPv6 for other configuration (DNS, etc.) even if using SLAAC for addresses.

M=0, O=0: pure SLAAC, no DHCPv6. M=0, O=1: SLAAC + stateless DHCPv6 for options. M=1, O=1: full stateful DHCPv6.

DHCPv6 Uses Multicast, Not Broadcast

IPv6 has no broadcast. DHCPv6 uses multicast: clients send to ff02::1:2 (All_DHCP_Relay_Agents_and_Servers, link-local multicast). Servers respond with unicast back to the client's link-local address. Relay agents forward using ff05::1:3 (site-scoped multicast) to reach servers across routers.

# DHCPv6 message types
SOLICIT (1)         → Like DISCOVER — client looks for servers
ADVERTISE (2)       ← Like OFFER — server responds
REQUEST (3)         → Client requests address from chosen server
REPLY (7)           ← Server confirms
RENEW (5)           → Client renews lease directly with server
REBIND (6)          → Client broadcasts to any server (T2 expired)
RELEASE (8)         → Client releases address
INFORMATION-REQUEST (11) → Stateless: only wants options, not address

ISC DHCP Failover Protocol

ISC DHCP implements a load-sharing/failover protocol (RFC 3074 / ISC proprietary for DHCPv4). Two servers — primary and secondary — share a pool and synchronize lease states over TCP. In normal operation, both servers actively allocate from their half of the pool. If one fails, the other takes over the full pool after a configured split timeout.

# Primary dhcpd.conf failover
failover peer "dhcp-failover" {
  primary;
  address 10.0.0.5;
  port 519;
  peer address 10.0.0.6;
  peer port 519;
  max-response-delay 30;
  max-unacked-updates 10;
  load balance max seconds 3;
  split 128;               # 50/50 split of addresses
  mclt 1800;               # Max Client Lead Time: 30 min
}

subnet 192.168.1.0 netmask 255.255.255.0 {
  pool {
    failover peer "dhcp-failover";
    range 192.168.1.100 192.168.1.200;
  }
  option routers 192.168.1.1;
}

Windows DHCP Failover

Windows Server 2012+ includes built-in DHCP failover configured via the DHCP Manager GUI or PowerShell. It supports hot standby (one active, one standby) and load balance (both active, 50/50 split by default). State replication is automatic.

# Windows PowerShell DHCP failover
Add-DhcpServerv4Failover   -ComputerName dhcp1.corp   -Name "DHCP-Failover"   -PartnerServer dhcp2.corp   -ScopeId 192.168.1.0   -LoadBalancePercent 50   -MaxClientLeadTime (New-TimeSpan -Hours 1)   -AutoStateTransition $true

AWS VPC DHCP

Every VPC has a DHCP options set that specifies: domain-name, domain-name-servers, ntp-servers, netbios-name-servers. The default options push AmazonProvidedDNS (VPC resolver at base VPC CIDR +2, e.g., 10.0.0.2). Custom options sets can override to point to private DNS resolvers. The DHCP server itself is the AWS-managed router; you cannot change it.

Kubernetes IPAM and CNI Plugins

Kubernetes pod networking uses a CNI (Container Network Interface) plugin to assign IPs. Some CNIs (Flannel, Calico, Cilium) use their own IPAM without DHCP; others (like Multus with Whereabouts) support DHCP delegation for specific pod NICs. The concepts remain the same: IP pool management, lease allocation, conflict avoidance — just implemented in software without the UDP protocol overhead.

Docker and DHCP

Docker's bridge network uses its own built-in DHCP-like system (implemented in libnetwork) to assign IPs to containers on the docker0 bridge. The macvlan driver allows containers to appear as physical hosts on the network and receive IPs from the upstream DHCP server — useful for containers that need to be reachable at a specific network address.

ISC DHCP (dhcpd.conf)

# /etc/dhcp/dhcpd.conf
default-lease-time 86400;      # 24 hours
max-lease-time 604800;         # 7 days maximum
authoritative;                 # This server is authoritative for these networks

option domain-name "corp.example.com";
option domain-name-servers 10.0.0.53, 10.0.0.54;
option ntp-servers 10.0.0.123;

# Production subnet
subnet 10.1.10.0 netmask 255.255.255.0 {
  range 10.1.10.50 10.1.10.200;
  option routers 10.1.10.1;
  option broadcast-address 10.1.10.255;
  # Classless static routes: 10.2.0.0/16 via 10.1.10.254
  option rfc3442-classless-static-routes 16, 10, 2, 10.1.10.254;
}

# Guest VLAN (shorter lease, no internal DNS)
subnet 10.1.99.0 netmask 255.255.255.0 {
  range 10.1.99.10 10.1.99.250;
  option routers 10.1.99.1;
  default-lease-time 3600;     # 1 hour for guest
  option domain-name-servers 8.8.8.8, 1.1.1.1;  # Public DNS only
}

# Static reservation
host fileserver {
  hardware ethernet DE:AD:BE:EF:00:01;
  fixed-address 10.1.10.20;
  option host-name "fileserver";
}

Dnsmasq (Lightweight, Common in Home/SMB)

# /etc/dnsmasq.conf
interface=eth0
dhcp-range=192.168.1.100,192.168.1.200,24h
dhcp-option=3,192.168.1.1          # default gateway
dhcp-option=6,8.8.8.8,8.8.4.4     # DNS servers
dhcp-option=42,192.168.1.1         # NTP server
dhcp-host=AA:BB:CC:DD:EE:FF,192.168.1.10,printer,infinite  # reservation