AlgoInsight

Free lesson · Computer Networking

Dhcp Automatic Ip Assignment

Easy10 min readnetworkingcomputer-networkstcp-ip

The Bootstrap Problem

When a device joins a network for the first time - when you connect your laptop to a Wi-Fi network, plug an Ethernet cable into a new server, or launch a virtual machine in the cloud - it faces a fundamental chicken-and-egg problem. To communicate on the network, it needs an IP address, a subnet mask, a default gateway, and DNS server addresses. But to obtain this configuration, it needs to communicate on the network. How does a device that has no network configuration get its network configuration?

DHCP (Dynamic Host Configuration Protocol) solves this problem. It is a client-server protocol where a DHCP server on the network automatically assigns IP addresses and configuration parameters to devices that request them. When you connect to a Wi-Fi network and your laptop instantly gets an IP address, subnet mask, gateway, and DNS servers - that is DHCP at work.

DHCP is defined in RFC 2131 (updated by RFC 2132 for options) and operates on UDP ports 67 (server) and 68 (client). It uses UDP rather than TCP because the client does not have an IP address yet and cannot establish a TCP connection. DHCP uses broadcast at the Ethernet level because the client does not know the DHCP server's address - it broadcasts a request and waits for any DHCP server to respond.

Nearly every network you encounter uses DHCP for automatic configuration. Home routers run a built-in DHCP server. Enterprise networks run dedicated DHCP servers (often integrated with DNS and Active Directory). Cloud platforms use DHCP internally to assign addresses to virtual machines from VPC subnets. Understanding DHCP helps you debug network configuration issues and design infrastructure that bootstraps correctly.

The DORA Process

DHCP address assignment follows a four-message exchange, memorized by the acronym DORA:

Discover

The client broadcasts a DHCP Discover message to find available DHCP servers. Because the client has no IP address yet, the source IP is 0.0.0.0 and the destination IP is 255.255.255.255 (broadcast). The Ethernet frame's destination MAC is also FF:FF:FF:FF:FF:FF. Every device on the local network receives this broadcast, but only DHCP servers respond.

The Discover message includes the client's MAC address (so the server can uniquely identify it and track assignments) and optionally a list of requested configuration parameters (IP address, subnet mask, gateway, DNS servers, lease duration, domain name).

Offer

Each DHCP server that receives the Discover responds with a DHCP Offer - a proposed IP address and configuration. The offer includes:

If multiple DHCP servers exist on the network, the client may receive multiple offers. This provides essential redundancy - if one server is down or unreachable, the other can still assign addresses and keep devices connected.

Request

The client selects one offer (typically the first one received) and broadcasts a DHCP Request message accepting that offer. This message is broadcast (not unicast to the selected server) so that all DHCP servers on the network know which offer was accepted. Servers whose offers were not selected can return the proposed addresses to their available pool.

Acknowledge

The selected DHCP server responds with a DHCP Acknowledge message, confirming the assignment. At this point, the client configures its network interface with the assigned IP address, subnet mask, gateway, and DNS servers. The client is now fully configured and can communicate on the network.

sequenceDiagram
    participant C as Client<br/>(no IP yet)
    participant S as DHCP Server<br/>192.168.1.1

    C->>S: DHCP Discover (broadcast)<br/>Src: 0.0.0.0 → Dst: 255.255.255.255<br/>"I need an IP address!"

    S->>C: DHCP Offer (broadcast/unicast)<br/>"How about 192.168.1.42?<br/>Mask: 255.255.255.0<br/>Gateway: 192.168.1.1<br/>DNS: 8.8.8.8<br/>Lease: 24 hours"

    C->>S: DHCP Request (broadcast)<br/>"I'll take 192.168.1.42<br/>from server 192.168.1.1"

    S->>C: DHCP Acknowledge<br/>"Confirmed. 192.168.1.42 is yours<br/>for 24 hours."

    Note over C: Client configures interface:<br/>IP: 192.168.1.42<br/>Mask: 255.255.255.0<br/>Gateway: 192.168.1.1<br/>DNS: 8.8.8.8

This sequence diagram shows the four-step DHCP DORA process. The client, which has no IP address yet, broadcasts a DHCP Discover message asking for an address. The DHCP server at 192.168.1.1 responds with a DHCP Offer proposing IP 192.168.1.42 along with subnet mask, gateway, DNS, and a 24-hour lease. The client broadcasts a DHCP Request accepting the offer from this specific server. The server sends a DHCP Acknowledge confirming the assignment. The client then configures its network interface with the assigned parameters.

DHCP Leases

The IP address assigned by DHCP is not permanent - it is leased for a specific duration. Common lease durations range from 1 hour (for Wi-Fi networks at coffee shops where devices come and go frequently) to 8 hours (typical for enterprise networks) to 24 hours or more (common for home networks).

Lease Renewal

Clients do not wait until the lease expires to renew. At 50% of the lease duration (the T1 timer), the client sends a DHCP Request directly to the server that assigned the address, asking to renew. If the server acknowledges, the lease is extended for another full duration from the renewal time.

If renewal at T1 fails (server unreachable), the client tries again at 87.5% of the lease duration (the T2 timer), this time broadcasting the request in case a different DHCP server can extend the lease.

If the lease expires without successful renewal, the client must release the IP address and start the DORA process over from Discover. During this brief period, the device has no IP configuration and loses network connectivity - which is why lease expiration is generally avoided through timely renewal.

Why Leases Matter

Leases prevent address exhaustion in dynamic environments. Without leases, a device that disconnects from the network without explicitly releasing its address would hold that address forever, even though the device is gone. Leases ensure that addresses from departed devices eventually return to the available pool.

The lease duration is a tuning parameter with trade-offs. Short leases (1-4 hours) ensure addresses are reclaimed quickly but generate more DHCP traffic as devices renew frequently. Long leases (24+ hours) reduce DHCP traffic but risk address exhaustion if many devices join and leave the network within the lease period. Most network administrators choose a lease duration that is roughly 2-3 times the typical device connection duration.

DHCP Relay - Crossing Subnet Boundaries

DHCP Discover messages are broadcasts, and broadcasts do not cross router boundaries. This means a DHCP server on one subnet cannot directly serve clients on a different subnet - the Discover broadcast never reaches it.

DHCP relay (also called a DHCP relay agent or IP helper) solves this. A router configured as a DHCP relay listens for DHCP broadcasts on its interfaces and forwards them as unicast packets to a central DHCP server on a different subnet. The server processes the request (knowing which subnet the client is on from the relay agent's information) and sends the response back through the relay.

This allows a single centralized DHCP server to serve devices across dozens of subnets - important in enterprise networks where deploying a separate DHCP server per subnet would be operationally burdensome and create a management nightmare with configuration scattered across many servers. Centralized DHCP also simplifies monitoring, logging, and IP address management (IPAM) - administrators can see all address assignments across the entire network from a single console.

In cloud environments, DHCP relay is handled internally by the cloud provider's networking infrastructure. When you create a subnet in a VPC, the cloud provider's virtual router automatically relays DHCP traffic between instances in that subnet and the internal DHCP server. You never need to configure DHCP relay in the cloud - but understanding how it works helps you troubleshoot situations where DHCP is not functioning as expected in on-premises or hybrid environments.

In Cisco routers, DHCP relay is configured with the ip helper-address command on each interface that needs relay. In Linux, dhcrelay provides the same functionality.

Static IP vs DHCP - When to Use Each

DHCP is appropriate for the vast majority of devices: workstations, laptops, phones, IoT devices, and any device that does not need a predictable, permanent address. DHCP simplifies network management by eliminating manual IP configuration and automatically reclaiming unused addresses.

Static IP addresses are appropriate for devices that need a consistent, predictable address: servers (your database should not change IP addresses), routers and switches (infrastructure devices need known addresses for management), printers (so users can always find them), and DNS servers (the addresses that devices use to find the DHCP server should not themselves depend on DHCP).

Many networks use a hybrid approach: DHCP for general devices with a range of the subnet reserved for static assignments. For example, in 192.168.1.0/24, addresses .1 through .50 might be reserved for static assignment (routers, servers, printers), and addresses .51 through .254 are in the DHCP pool for dynamic assignment. DHCP servers also support reservations - assigning a specific IP to a specific MAC address through DHCP, combining the automation of DHCP with the predictability of static assignment.

graph TD
    subgraph Network["Subnet 192.168.1.0/24 - Address Allocation"]
        direction TB
        STATIC["Static Range<br/>.1 – .50<br/>Routers, servers,<br/>printers, infrastructure"]
        DHCP["DHCP Pool<br/>.51 – .254<br/>Laptops, phones,<br/>tablets, guests"]
        RESERVED["Reserved Addresses<br/>.0 (network)<br/>.255 (broadcast)"]
    end

    style STATIC fill:#4f46e5,stroke:#4338ca,color:#fff
    style DHCP fill:#7c3aed,stroke:#6d28d9,color:#fff
    style RESERVED fill:#a78bfa,stroke:#8b5cf6,color:#fff

This diagram shows how a /24 subnet's address space is typically divided. The static range from .1 to .50 is reserved for infrastructure like routers, servers, and printers that need predictable addresses. The DHCP pool from .51 to .254 is dynamically assigned to laptops, phones, tablets, and guest devices. Addresses .0 (network) and .255 (broadcast) are reserved by the protocol and cannot be assigned to any device.

Additional DHCP Messages

Beyond the four DORA messages, DHCP defines several additional message types:

DHCP Release: Sent by a client when it no longer needs the assigned address - for example, when a device disconnects from the network gracefully. The server immediately returns the address to the available pool. Not all devices send Release messages when disconnecting (particularly mobile devices that simply walk out of range), which is why leases have timeouts.

DHCP Decline: Sent by a client if it detects that the offered address is already in use (through ARP probing). The client sends a Decline to tell the server that the address is conflicting, and the server marks it as unavailable and offers a different address.

DHCP Inform: Sent by a client that already has an IP address (configured statically) but needs other configuration parameters like DNS servers. The server responds with the requested parameters without assigning a new IP address. This is useful in environments where IP addresses are assigned statically but DNS and other settings should be managed centrally.

DHCP NAK (Negative Acknowledge): Sent by the server if the client requests an address that is no longer valid - for example, if the client moved to a different subnet and is requesting the address from its old subnet. The NAK tells the client to restart the DORA process from scratch.

DHCP Security Concerns

DHCP has no built-in authentication. Any device on the network can send DHCP messages, and clients trust whatever DHCP server responds first. This creates two main attack vectors:

Rogue DHCP server: An attacker deploys a DHCP server that responds to Discover messages faster than the legitimate server. The rogue server assigns addresses with a malicious default gateway (pointing to the attacker's machine) or malicious DNS servers (pointing to the attacker's DNS that redirects domains to phishing sites). This enables man-in-the-middle attacks that are difficult to detect.

DHCP starvation: An attacker floods the DHCP server with Discover messages using random MAC addresses, exhausting the available address pool. Legitimate devices can no longer obtain addresses and lose network connectivity.

Mitigations include DHCP snooping (a switch feature that allows DHCP responses only from trusted ports), 802.1X port-based authentication (preventing unauthorized devices from joining the network), and rate limiting on DHCP messages to prevent starvation attacks.

DHCP in the Cloud

Cloud platforms use DHCP internally even though you rarely interact with it directly:

AWS: When you launch an EC2 instance in a subnet, AWS's internal DHCP server assigns an IP from the subnet's CIDR range. You can configure DHCP options sets in a VPC to specify custom DNS servers and domain names. The instance receives its private IP, subnet mask, default gateway, and DNS configuration through DHCP - the same DORA process described above, running inside the virtualized network.

Kubernetes: Pods receive IP addresses through a CNI (Container Network Interface) plugin, which may use DHCP-like assignment from the node's allocated pod CIDR range. The exact mechanism varies by CNI plugin, but the fundamental problem - assigning addresses to newly created network interfaces - is the same.

Interview: DHCP itself is rarely a direct interview topic, but understanding automatic configuration matters:

"How does an instance get its IP address when it launches?" - Through DHCP from the cloud provider's internal DHCP server, assigned from the subnet's CIDR range.

"What happens if the DHCP server is down?" - Devices that already have leases continue functioning until their leases expire. New devices cannot join the network (they get 169.254.x.x link-local addresses). This is why enterprise networks deploy redundant DHCP servers.

"Why does my application work on some machines but not others?" - DHCP assigns DNS servers, and different DHCP servers may assign different DNS servers. If one DNS server is misconfigured or unreachable, devices that received that DNS configuration will fail to resolve hostnames while other devices work fine.

What Comes Next

The final topic in this module covers ICMP and the Ping Command - the diagnostic protocol that lets you test network connectivity, measure round-trip latency, and trace the path packets take through the network. ICMP tools like ping and traceroute are the first things a network engineer reaches for when diagnosing connectivity problems.

Exercise: Starter: View your current DHCP lease information. On Mac, go to System Preferences → Network → Advanced → TCP/IP. On Linux, run cat /var/lib/dhcp/dhclient.leases or journalctl -u NetworkManager | grep DHCP. On Windows, run ipconfig /all and look for "Lease Obtained" and "Lease Expires." How long is your current lease? When does it expire?

Intermediate: Release and renew your DHCP lease. On Mac/Linux: sudo dhclient -r && sudo dhclient. On Windows: ipconfig /release && ipconfig /renew. Watch what happens - you will briefly lose network connectivity during the release and regain it after the renew completes the DORA process. Did you get the same IP address back, or a different one? Most DHCP servers try to reassign the same address to the same MAC if the lease has not been given to another device.

Advanced: Research DHCP snooping - a switch-level security feature that prevents rogue DHCP servers on the network. Without DHCP snooping, anyone can plug a device into the network that responds to DHCP Discover messages with malicious offers (pointing to a fake gateway or DNS server for man-in-the-middle attacks). How does DHCP snooping work? What is the relationship between DHCP snooping and Dynamic ARP Inspection (DAI)?

Back to Computer Networking