Imagine a world where every device connecting to a network required manual IP address configuration. Network administrators would spend their days assigning IP addresses, subnet masks, default gateways, and DNS servers to thousands of devices—laptops, phones, printers, IoT devices, guest devices, and more. The administrative burden would be crushing, and human error would cause constant connectivity issues.

Dynamic Host Configuration Protocol (DHCP) solves this problem elegantly. When you connect your laptop to a WiFi network and instantly receive an IP address, DHCP is working behind the scenes. This protocol runs over UDP, making it one of the most critical UDP-based services in modern networking.

Before diving into DHCP's technical details, let's understand the problem it solves and why its design choices are necessary.

The Configuration Challenge:

To communicate on an IP network, a host needs at minimum:

• IP Address: Unique identifier on the network
• Subnet Mask: Defines network/host portions
• Default Gateway: Router for reaching other networks
• DNS Servers: For name resolution

Optionally, a host may also need:

• Domain name suffix
• WINS servers (legacy Windows)
• NTP servers (time synchronization)
• Boot filename (diskless workstations)
• Vendor-specific options

The Bootstrap Paradox:

Here's the fundamental challenge that makes DHCP interesting from a protocol design perspective:

How can a host request an IP address when it doesn't have an IP address yet?

This is the bootstrap problem. The client needs to communicate with a server, but it has no network identity. This constraint drives DHCP's reliance on UDP broadcasts and its specific design choices.

DHCP doesn't merely prefer UDP—it requires UDP. Unlike DNS, where UDP is an optimization choice, DHCP physically cannot use TCP. Let's understand why.

The TCP Impossibility:

TCP requires both endpoints to have valid IP addresses before establishing a connection. The three-way handshake (SYN, SYN-ACK, ACK) assumes both parties can address each other. But a DHCP client:

1. Has no IP address (that's what it's trying to get)
2. Doesn't know the server's IP address (must use broadcast)
3. Cannot receive unicast packets (has no address to unicast to)

TCP fundamentally cannot work in this scenario.

DHCP Port Numbers:

Why different ports?

Unlike most protocols where the server has a well-known port and the client uses an ephemeral port, DHCP uses fixed ports for both. This is because:

1. Broadcast responses: The server's OFFER is broadcast; clients filter by their MAC address and port 68
2. Relay agents: DHCP relays listen on port 67 and must distinguish client traffic from server traffic
3. Firewall rules: Fixed ports enable simple, predictable firewall configuration

DHCP uses a fixed-format message with variable-length options, derived from the BOOTP format. Understanding this format is essential for debugging DHCP issues.

Message Structure:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            xid (4)                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           secs (2)            |           flags (2)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          ciaddr (4)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          yiaddr (4)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          siaddr (4)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          giaddr (4)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          chaddr (16)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          sname (64)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          file (128)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          options (variable)                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The DHCP Magic Cookie:

DHCP options begin with a 4-byte magic cookie: 99.130.83.99 (or 0x63825363). This value distinguishes DHCP messages from BOOTP messages and marks the start of the options field.

Option Format:

+-------+-------+-------+-------+-------+
| Code  |  Len  | Data bytes...         |
+-------+-------+-------+-------+-------+
   1       1         Len bytes

Each option is TLV (Type-Length-Value) encoded, allowing extensibility while maintaining backward compatibility.

DHCP options carry the actual configuration parameters. Over 200 options are defined, but a small subset handles most use cases.

Critical DHCP Options:

Message Type Option (53) Values:

Option 55: The Shopping List:

When a client sends a DISCOVER or REQUEST, it includes Option 55—a list of option codes it wants the server to provide. This allows clients to request only the parameters they need, and servers to tailor responses accordingly.

DHCP address allocation follows a four-message exchange known as DORA: Discover, Offer, Request, Acknowledge. This process is designed to handle multiple servers, prevent IP conflicts, and work across broadcast domains.

Why Four Messages?

The DORA process seems redundant—why not just DISCOVER → ASSIGN? The four-step process solves critical problems:

1. Multiple Servers: DISCOVER is broadcast; multiple servers may respond with OFFERs
2. Client Choice: REQUEST lets client select among offers
3. Conflict Prevention: Server reserves address only after client commits
4. Confirmation: ACK confirms assignment after potential conflicts are resolved

Detailed DORA Steps:

Step 1: DISCOVER (Client → Broadcast)

• Source IP: 0.0.0.0 (no address yet)
• Destination IP: 255.255.255.255 (broadcast)
• Source Port: 68 (DHCP client)
• Destination Port: 67 (DHCP server)
• Contains: Client MAC (chaddr), Transaction ID (xid), Parameter Request List (Option 55)

Step 2: OFFER (Server → Client)

• Source IP: Server's IP (192.168.1.1)
• Destination IP: 255.255.255.255 (or unicast to yiaddr if supported)
• yiaddr: Proposed IP for client (192.168.1.100)
• Contains: Lease time, subnet mask, router, DNS servers, server identifier
• Server reserves address temporarily pending client response

Step 3: REQUEST (Client → Broadcast)

• Still broadcast (client doesn't have IP yet)
• Includes Server Identifier option (Option 54) to identify chosen server
• Includes Requested IP Address option (Option 50) to confirm desired IP
• Non-selected servers see this and release their reserved offers

Step 4: ACK (Server → Client)

• Confirms the lease binding
• Contains final configuration parameters
• After receiving ACK, client configures its network interface
• Client should perform duplicate address detection (ARP probe)

DHCP addresses are leased, not permanently assigned. This lease model enables efficient IP address utilization—addresses return to the pool when no longer needed. Understanding the lease lifecycle is crucial for troubleshooting connectivity issues.

Lease Timers:

The Lease State Machine:

                    ┌──────────────────────────────────────┐
                    │           DHCP Lease Timeline        │
                    └──────────────────────────────────────┘

    0%          50%                    87.5%              100%
    │────────────│──────────────────────│───────────────────│
    │            │                      │                   │
  Lease      Renewal               Rebinding           Expiration
  Start      (T1)                  (T2)                    
             ↓                      ↓                       ↓
         Try unicast            Broadcast              Lose IP
         to original            to any                 address
         server                 server

Renewal (at T1):

• Client sends REQUEST unicast to original server (ciaddr filled with current IP)
• If server responds with ACK, lease is extended
• If no response, retry with exponential backoff until T2

Rebinding (at T2):

• Original server unreachable; client sends REQUEST broadcast
• Any DHCP server can respond and extend the lease
• This provides fault tolerance if original server fails

Expiration:

• If T2 passes without successful renewal, client must stop using the IP
• Client returns to DISCOVER state
• Applications see this as network disconnection

DHCP broadcasts are limited to the local network segment—routers don't forward broadcasts. This creates a problem: would every subnet need its own DHCP server? DHCP Relay Agents solve this by forwarding DHCP messages across subnets.

The Problem:

Subnet A (10.1.1.0/24)           Subnet B (10.2.2.0/24)
     [Client]                         [DHCP Server]
         ↓                                  ↑
    DISCOVER                             How does
   (broadcast)                          this reach
         ↓                              the server?
    [Router]  ←── broadcasts don't cross ──→

The Solution: Relay Agent

The router can act as a DHCP Relay Agent, configured with the IP address of the DHCP server. When it receives a DHCP broadcast, it:

1. Converts it to a unicast packet addressed to the server
2. Fills in the Gateway IP Address (giaddr) field with its own interface IP
3. Forwards the packet to the server
4. The server uses giaddr to determine which pool to allocate from
5. Server responds to the relay agent, which broadcasts to the client

Key giaddr Behaviors:

Relay Agent Information Option (Option 82):

RFC 3046 introduced Option 82, allowing relays to insert additional information:

• Circuit ID: Identifies the circuit (VLAN, port) the request came from
• Remote ID: Identifies the remote access device (switch ID)

This enables per-port/per-VLAN policies and helps with security auditing.

DHCP's broadcast-based, unauthenticated nature makes it vulnerable to several attacks. Understanding these threats is essential for securing enterprise networks.

Core Vulnerabilities:

DHCP has no built-in authentication mechanism. Any device can:

• Send DHCP requests (legitimate or malicious)
• Send DHCP responses (rogue servers)
• Observe all DHCP traffic (broadcasts are visible to all)

DHCP Snooping: The Primary Defense

DHCP Snooping is a switch feature that:

1. Classifies ports as TRUSTED or UNTRUSTED

   • Trusted: Ports connected to legitimate DHCP servers or uplinks
   • Untrusted: Ports connected to clients

2. Blocks DHCP server messages on untrusted ports

   • OFFER, ACK, NAK from untrusted ports are dropped
   • Only trusted ports can send server messages

3. Builds a binding table

   • Records MAC ↔ IP mappings from observed DHCP transactions
   • Can be used by Dynamic ARP Inspection (DAI) and IP Source Guard

Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 10,20
Switch(config)# interface gi0/1
Switch(config-if)# ip dhcp snooping trust   (uplink to server)
Switch(config)# interface range gi0/2-48
Switch(config-if)# ip dhcp snooping limit rate 10  (client ports)

Understanding DHCP at a practical level requires hands-on experience with client commands and packet analysis.

Client Commands:

Common DHCP Problems and Solutions:

DHCP demonstrates another essential use case for UDP—one where UDP isn't just preferred but required. Let's consolidate the key insights:

DHCP vs. DNS: Two UDP Protocol Patterns:

Next up: We'll examine SNMP (Simple Network Management Protocol), which uses UDP for network monitoring and management—another domain where UDP's efficiency shines.