How DHCP Works: The Full Exchange

Every device that connects to a network needs an IP address, a default gateway, and DNS server information. Manually configuring these on every device would be impractical. DHCP - the Dynamic Host Configuration Protocol - automates this process through a four-step exchange that takes milliseconds and happens every time you connect to a WiFi network.

Why DHCP Exists

Before DHCP, network administrators had two options: manually assign a static IP to every device, or use BOOTP (Bootstrap Protocol), which provided IP assignment but required a pre-configured table of MAC-to-IP mappings. Neither approach scales to a world where billions of devices move between networks daily.

DHCP, defined in RFC 2131, solves this by dynamically allocating IP addresses from a pool. A device can join any DHCP-enabled network and receive a complete network configuration automatically. When the device leaves, the address returns to the pool for reuse.

DHCP operates over UDP. Clients send from port 68, servers listen on port 67. UDP is used instead of TCP because the client does not have an IP address yet - it cannot participate in TCP's three-way handshake without one.

The DORA Process

DHCP uses a four-message exchange known as DORA: Discover, Offer, Request, Acknowledge.

Discover. The client broadcasts a DHCPDISCOVER message to the entire local network (destination 255.255.255.255). Since the client has no IP yet, the source address is 0.0.0.0. The message essentially says: "I need an IP address. Is there a DHCP server on this network?" The broadcast reaches every device on the subnet, but only DHCP servers respond.

Offer. Each DHCP server that receives the Discover message responds with a DHCPOFFER. The offer includes a proposed IP address, the subnet mask, the lease duration, and the server's own IP (so the client knows who made the offer). If multiple DHCP servers exist on the network, the client may receive multiple offers.

Request. The client selects one offer (typically the first to arrive) and broadcasts a DHCPREQUEST. This message is broadcast, not unicast, for an important reason: all DHCP servers on the network need to know which offer was accepted. The servers whose offers were rejected can return those addresses to their pools.

Acknowledge. The selected server responds with a DHCPACK, confirming the lease. This message includes the final IP address, subnet mask, default gateway, DNS servers, and lease duration. The client can now configure its network interface and begin communicating.

sequenceDiagram
    participant C as Client - no IP yet
    participant N as Network - broadcast
    participant S1 as DHCP Server 1
    participant S2 as DHCP Server 2
    C->>N: DHCPDISCOVER - broadcast from 0.0.0.0
    N->>S1: Discover received
    N->>S2: Discover received
    S1->>C: DHCPOFFER - 192.168.1.100 lease 3600s
    S2->>C: DHCPOFFER - 192.168.1.200 lease 7200s
    C->>C: Select first offer
    C->>N: DHCPREQUEST - broadcast - I want 192.168.1.100 from Server 1
    N->>S1: Request received
    N->>S2: Request received - not selected
    S2->>S2: Return 192.168.1.200 to pool
    S1->>C: DHCPACK - confirmed 192.168.1.100
    Note over C: Client configures interface

Figure 1 - The complete DORA exchange with two DHCP servers on the network

DHCP Options

DHCP messages carry options - tagged fields that provide configuration beyond the basic IP address. Each option has a numeric code, a length, and a value. The most important options are:

Option 1 - Subnet Mask. Defines the network boundary (e.g., 255.255.255.0 for a /24 network).

Option 3 - Default Gateway. The IP address of the router that handles traffic destined for other networks. This is one of the most security-critical options - if an attacker controls this, they control where all your traffic goes.

Option 6 - DNS Servers. A list of DNS server IP addresses. Like the gateway option, controlling DNS gives an attacker the ability to redirect name resolution.

Option 15 - Domain Name. The domain suffix for the network (e.g., corp.example.com), used to resolve short hostnames.

Option 51 - Lease Time. How long the client can use the assigned IP address, in seconds. Common values range from 3600 (1 hour) for guest networks to 86400 (24 hours) for corporate networks.

Option 53 - DHCP Message Type. Identifies the message as Discover (1), Offer (2), Request (3), Decline (4), ACK (5), NAK (6), or Release (7).

Option 61 - Client Identifier. Usually the client's MAC address, used by the server to identify the client across requests and renewals.

Lease Lifecycle

A DHCP lease is not permanent. It has a defined duration, and the client must renew it before it expires or lose its IP address.

The renewal process uses two timers:

T1 (Renewal Timer) - 50% of lease time. When T1 expires, the client sends a unicast DHCPREQUEST directly to the server that issued the lease. If the server responds with a DHCPACK, the lease is renewed and the timers reset. If the server does not respond, the client tries again periodically.

T2 (Rebind Timer) - 87.5% of lease time. If the client has not successfully renewed by T2, it broadcasts a DHCPREQUEST to any available DHCP server. This handles the case where the original server has gone offline.

If neither renewal nor rebinding succeeds before the lease expires, the client must release its IP address and start the DORA process from scratch.

The client can also proactively release its lease by sending a DHCPRELEASE message. This is what happens when you disconnect from a WiFi network cleanly - your device tells the server to reclaim the address immediately rather than waiting for the lease to expire.

graph TD
    subgraph "DHCP Lease Timeline"
        A[Lease granted - T=0] --> B[Normal operation - using assigned IP]
        B --> C[T1 - 50% of lease - renewal attempt]
        C -->|Server responds| D[Lease renewed - timers reset]
        C -->|No response| E[Continue trying until T2]
        E --> F[T2 - 87.5% of lease - rebind attempt]
        F -->|Any server responds| D
        F -->|No response| G[Lease expires - IP released]
        G --> H[Start DORA again]
    end
    subgraph "Example - 1 hour lease"
        I[0 min - lease starts] --> J[30 min - T1 renewal]
        J --> K[52.5 min - T2 rebind]
        K --> L[60 min - lease expires]
    end

Figure 2 - DHCP lease lifecycle with T1 renewal and T2 rebind timers

Rogue DHCP Attacks

The DORA exchange has no authentication. Any device on the network can respond to a DHCPDISCOVER with a DHCPOFFER. This is by design - DHCP was created for convenience, not security - but it creates a serious vulnerability.

A rogue DHCP server is an unauthorized device that responds to DHCP Discover messages. If the rogue server's offer reaches the client before the legitimate server's offer, the client accepts the rogue configuration.

The attacker's rogue DHCP server can set:

• Default gateway to the attacker's IP - all traffic now routes through the attacker (man-in-the-middle)
• DNS servers to the attacker's DNS - the attacker controls name resolution and can redirect any domain to any IP
• A short lease time - forcing frequent renewals that the rogue server can respond to

This combination gives the attacker complete visibility into and control over the victim's network traffic. The victim sees nothing unusual - their device has an IP address, the internet works, pages load. But everything passes through the attacker first.

DHCP starvation is a related attack where the attacker floods the legitimate server with DHCPDISCOVER messages using spoofed MAC addresses, exhausting its address pool. Once the legitimate server has no addresses left, only the rogue server can respond to new clients.

Defenses - DHCP Snooping

DHCP snooping is a Layer 2 security feature on managed network switches. When enabled, the switch maintains a table of trusted DHCP servers (typically the ports where legitimate servers are connected). DHCP server messages (Offer, ACK) arriving on untrusted ports are dropped.

The switch also builds a binding table that maps MAC addresses to their assigned IP addresses and the port they are connected to. This table is used by other security features like Dynamic ARP Inspection (DAI) and IP Source Guard to prevent spoofing at multiple protocol layers.

On networks without managed switches - like most home and small office networks - DHCP snooping is not available. This is one reason why rogue DHCP attacks remain practical on flat, unmanaged networks.

DHCP and the BLEShark Nano

When the BLEShark Nano creates its own access point, it runs a DHCP server to assign IP addresses to connecting clients. The Nano's DHCP server assigns addresses from a small pool, sets itself as the default gateway, and configures its own DNS server - which is how the evil portal feature works. By controlling both the gateway and DNS, the Nano can intercept HTTP requests and serve its portal page to any connected device.

This is exactly the rogue DHCP scenario described above, but intentional and controlled. Understanding DHCP at this level is what separates someone who uses security tools from someone who understands why they work.