Skip to content

Portal | Level: L1: Foundations | Topics: DHCP & IP Address Management, TCP/IP, DNS | Domain: Networking

DHCP & IP Address Management - Primer

Why This Matters

Every device on your network needs an IP address. In a small environment, you might assign them by hand. In anything larger — a datacenter, a campus, a cloud VPC with hundreds of instances — manual assignment breaks down. DHCP automates the assignment. IPAM (IP Address Management) tracks the inventory. Together, they are the plumbing that makes networks actually function.

When DHCP breaks, nothing works. Servers cannot boot, workstations cannot join the network, PXE provisioning fails, and your phone rings. If you manage infrastructure, you need to understand how DHCP works at a protocol level, not just "it gives out IPs."

Name origin: DHCP stands for Dynamic Host Configuration Protocol, defined in RFC 2131 (March 1997) by Ralph Droms of Bucknell University. DHCP evolved from BOOTP (Bootstrap Protocol, RFC 951, 1985), adding dynamic address allocation and lease management. The key innovation over BOOTP was that addresses are leased temporarily rather than permanently assigned — allowing address reuse when devices leave the network. BOOTP is still referenced in DHCP packet formats: the DHCP message structure inherits BOOTP's field layout.

Remember: DORA is the mnemonic for the four-step DHCP handshake: Discover, Offer, Request, Acknowledge. All four use UDP (ports 67 server, 68 client). The client broadcasts because it has no IP yet. The REQUEST is also broadcast so other DHCP servers know which offer was accepted and can release their reserved addresses.

The DORA Process

DHCP uses a four-step handshake called DORA. All four messages use UDP. The client starts with no IP address, so it relies on broadcast.

Client                              Server
(no IP)                             (e.g., 10.0.0.1)
   │                                   │
   │──── DISCOVER (broadcast) ────────▶│  "Anyone have an IP for me?"
   │     src: 0.0.0.0:68               │
   │     dst: 255.255.255.255:67       │
   │                                   │
   │◀──── OFFER ──────────────────────│  "Here, try 10.0.0.50"
   │      src: 10.0.0.1:67            │
   │      dst: 255.255.255.255:68     │
   │      (or unicast to client MAC)   │
   │                                   │
   │──── REQUEST (broadcast) ─────────▶│  "I accept 10.0.0.50"
   │     src: 0.0.0.0:68               │  (broadcast so other
   │     dst: 255.255.255.255:67       │   servers know to retract)
   │                                   │
   │◀──── ACK ────────────────────────│  "Confirmed. It's yours
   │      src: 10.0.0.1:67            │   for 86400 seconds."
   │      dst: 255.255.255.255:68     │
   │                                   │
   │  Client configures interface      │
   │  10.0.0.50/24, gw 10.0.0.1       │

Why is REQUEST broadcast? Because there might be multiple DHCP servers. The REQUEST tells all of them which offer was accepted so the others can release their reserved addresses.

Lease Renewal

The client does not wait for the lease to expire. It starts renewing at 50% (T1) and rebinding at 87.5% (T2):

Lease: 86400s (24 hours)
├── T1 (50%):  43200s — Unicast RENEW to original server
├── T2 (87.5%): 75600s — Broadcast REBIND to any server
└── Expiry:     86400s — Release IP, start DORA again

DHCP Options

The DHCP server sends more than just an IP address. Options configure the entire network stack:

Option Code What It Configures
Subnet Mask 1 Network mask (255.255.255.0)
Router 3 Default gateway
DNS Servers 6 Name resolution
Domain Name 15 Search domain
Broadcast 28 Broadcast address
NTP Servers 42 Time synchronization
Lease Time 51 How long the lease is valid
DHCP Server ID 54 Which server issued the lease
Renewal (T1) 58 When to start unicast renewal
Rebinding (T2) 59 When to start broadcast renewal
TFTP Server 66 PXE boot server
Bootfile Name 67 PXE boot file

Options 66 and 67 are critical for PXE provisioning. If you run bare-metal automation, these are how new servers find their boot images.

Relay Agents

DHCP uses broadcast. Broadcasts do not cross routers. So how does a client on VLAN 100 reach a DHCP server on VLAN 1?

Relay agents.

VLAN 100 (10.1.0.0/24)          Router (Relay Agent)         VLAN 1 (10.0.0.0/24)
┌────────┐                      ┌────────────────┐           ┌────────────┐
│ Client │──broadcast──────────▶│ Relay Agent    │──unicast──▶│ DHCP Server│
│        │  DISCOVER            │                │  DISCOVER  │            │
│        │                      │ Adds giaddr:   │  + giaddr  │            │
│        │                      │ 10.1.0.1       │            │            │
│        │◀─────────────────────│◀───────────────│────────────│ OFFER      │
│        │  OFFER               │                │            │            │
└────────┘                      └────────────────┘           └────────────┘

The relay agent: 1. Receives the broadcast DISCOVER 2. Sets the giaddr (gateway IP address) field to its own IP on that subnet 3. Forwards as unicast to the DHCP server 4. The server uses giaddr to determine which scope/pool to allocate from 5. The server sends the reply to the relay, which forwards to the client

Router Configuration Example

! Cisco IOS
interface Vlan100
  ip address 10.1.0.1 255.255.255.0
  ip helper-address 10.0.0.10     ! DHCP server IP
  ip helper-address 10.0.0.11     ! Redundant DHCP server

! Linux (using dhcrelay)
dhcrelay -i eth1 10.0.0.10 10.0.0.11

ip helper-address on Cisco forwards not just DHCP but also TFTP, DNS, TACACS, and other UDP services. If you only want DHCP, use ip forward-protocol.

IPAM Concepts

IPAM is the discipline of tracking which IPs are assigned, available, and reserved. At small scale, a spreadsheet works. At datacenter scale, you need actual tooling.

IPAM Hierarchy

Organization
└── Address Space
    ├── Supernet: 10.0.0.0/8
    │   ├── Site: 10.1.0.0/16 (DC-East)
    │   │   ├── VLAN 100: 10.1.1.0/24 (Production)
    │   │   ├── VLAN 200: 10.1.2.0/24 (Management)
    │   │   └── VLAN 300: 10.1.3.0/24 (DMZ)
    │   └── Site: 10.2.0.0/16 (DC-West)
    │       ├── VLAN 100: 10.2.1.0/24 (Production)
    │       └── ...
    └── RFC 1918 Summary
        ├── 10.0.0.0/8     (Class A private)
        ├── 172.16.0.0/12  (Class B private)
        └── 192.168.0.0/16 (Class C private)

Static vs Dynamic Assignment

Type Use Case Method
Static Servers, printers, network devices Manual config or DHCP reservation
Dynamic Workstations, laptops, phones DHCP pool
Reserved Servers that need DHCP but stable IPs DHCP reservation (MAC-to-IP binding)

Best practice: use DHCP reservations instead of static IPs even for servers. This keeps all IP assignments in one system (the DHCP server) instead of splitting between DHCP and static configs on individual hosts.

Scope Design

A DHCP scope defines a range of addresses the server can hand out. Scope design directly affects capacity and manageability.

Scope: 10.1.1.0/24  (Production VLAN)
├── Network:       10.1.1.0
├── Broadcast:     10.1.1.255
├── Gateway:       10.1.1.1    (excluded from pool)
├── Exclusion:     10.1.1.1 - 10.1.1.10  (infrastructure)
├── Pool:          10.1.1.11 - 10.1.1.200 (dynamic)
├── Reservations:  10.1.1.201 - 10.1.1.250 (static via DHCP)
├── Available:     190 dynamic + 50 reserved
├── Lease Time:    8 hours (workstation VLAN)
└── Options:
    ├── Router: 10.1.1.1
    ├── DNS: 10.0.0.53, 10.0.0.54
    └── Domain: prod.example.com

Lease Time Guidelines

Environment Recommended Lease Why
Office (stable) 8-24 hours Devices stay connected all day
Guest WiFi 1-4 hours High turnover, reclaim fast
Conference room 2-4 hours Short sessions
Server VLAN 7-30 days Stability, fewer renewals
IoT/embedded 24+ hours Minimize chatty renewals
Lab/test 1-2 hours Frequent reprovisioning

Debug clue: When a host gets an IP from the wrong DHCP scope (e.g., a management IP on a user VLAN), check the relay agent's giaddr. The DHCP server uses giaddr to select the correct scope. If the relay is misconfigured (wrong interface IP, wrong helper-address), the server allocates from the wrong pool. On Cisco, debug ip dhcp server packet shows the giaddr in each request. This is the #1 cause of "devices get IPs but can't reach anything" — they are in the wrong subnet.

Gotcha: ISC DHCP (dhcpd) is officially end-of-life as of 2022. ISC Kea is its replacement, offering a REST API, database-backed lease storage (MySQL, PostgreSQL), and multi-threading. If you are deploying a new DHCP server, start with Kea. Existing dhcpd deployments still work but will receive no new features or security patches beyond critical fixes.

DHCP Failover

A single DHCP server is a single point of failure. Two approaches:

Split Scope (Simple)

Divide the pool between two servers. No communication required between them.

Server A: 10.1.1.11 - 10.1.1.130  (60%)
Server B: 10.1.1.131 - 10.1.1.200 (40%)

Downside: if Server A fails, 60% of the pool is unavailable until it returns.

Active Failover (ISC DHCP / Windows DHCP)

Both servers share state and can serve the full pool:

# ISC DHCP failover config (dhcpd.conf)
failover peer "dhcp-failover" {
  primary;
  address 10.0.0.10;
  port 647;
  peer address 10.0.0.11;
  peer port 647;
  max-response-delay 30;
  max-unacked-updates 10;
  load balance max seconds 3;
  mclt 3600;
  split 128;    # 50/50 split
}

subnet 10.1.1.0 netmask 255.255.255.0 {
  pool {
    failover peer "dhcp-failover";
    range 10.1.1.11 10.1.1.200;
  }
}

Common DHCP Server Software

Software Platform Notes
ISC DHCP (dhcpd) Linux/BSD Legacy, feature-rich, being replaced by Kea
ISC Kea Linux Modern replacement, REST API, database backend
Windows DHCP Windows Server GUI-managed, AD-integrated, failover built-in
dnsmasq Linux Lightweight, combined DNS+DHCP, good for small deployments
Infoblox Appliance Enterprise IPAM+DNS+DHCP, expensive
NetBox + plugin Linux Open-source IPAM (DHCP via integration)

Key Takeaways

  1. DORA is four UDP messages: Discover, Offer, Request, Acknowledge — all broadcast
  2. Relay agents bridge DHCP across VLANs using giaddr — without them, DHCP stops at the router
  3. DHCP options configure more than IP: gateway, DNS, NTP, PXE boot — get them right
  4. Lease times should match the environment: short for transient, long for stable
  5. Always have DHCP redundancy: split scope or active failover
  6. DHCP reservations > static IPs: one system of record beats two
  7. IPAM tooling is mandatory at scale: spreadsheets lie, tools audit

Wiki Navigation

Prerequisites

Related Content