How DHCP Works: Dynamic Host Configuration Protocol Explained

Every device on a network needs an IP address, a subnet mask, a default gateway, and DNS server addresses before it can communicate. Configuring these settings manually on every laptop, phone, printer, and IoT sensor in an enterprise with thousands of devices would be an operational nightmare. The Dynamic Host Configuration Protocol (DHCP) solves this by automatically assigning network configuration to devices the moment they connect, turning what would be hours of manual work into a process that completes in milliseconds.

DHCP is defined in RFC 2131 (for IPv4) and operates as a client-server protocol over UDP. The client broadcasts a request on the local network, a DHCP server responds with an available IP address and associated configuration, and the client adopts those settings for a limited period called a lease. When the lease expires, the client must renew it or obtain a new address. This lease-based model allows a pool of IP addresses to be shared efficiently among devices that come and go, which is essential in environments from coffee shops to data centers.

The DORA Process: How a Device Gets an Address

The core of DHCP is a four-message exchange known as DORA: Discover, Offer, Request, Acknowledge. This handshake occurs every time a device connects to a network and needs an IP address.

Step 1: DHCP Discover

When a client device boots up or connects to a network without an IP address, it sends a DHCPDISCOVER message. Since the client has no IP address yet, this message is sent as a broadcast: the source IP is 0.0.0.0 and the destination is 255.255.255.255. The message is transmitted via UDP from source port 68 (the DHCP client port) to destination port 67 (the DHCP server port).

The Discover message contains a transaction ID (a random 32-bit number the client generates to match replies to its request), the client's MAC address (hardware address), and optionally a list of requested DHCP options indicating what configuration parameters the client wants. It may also include a requested IP address option if the client previously held a lease and wants the same address again.

Every device on the broadcast domain receives this packet, but only DHCP servers process it.

Step 2: DHCP Offer

Each DHCP server that receives the Discover message and has available addresses responds with a DHCPOFFER. The Offer contains a proposed IP address for the client, the subnet mask, the lease duration, and the server's own IP address as the server identifier. It also typically includes default gateway and DNS server addresses.

The server selects an IP address from its configured pool, checking that the address is not already in use. Many servers perform a ping check (ICMP echo request) to the candidate address before offering it, adding a small delay but preventing conflicts. The server marks the address as tentatively reserved until the transaction completes or times out.

If multiple DHCP servers exist on the network (which is recommended for redundancy), the client may receive multiple Offers. The client typically accepts the first Offer that arrives.

Step 3: DHCP Request

The client selects one of the Offers and broadcasts a DHCPREQUEST message indicating which server's offer it has accepted. This message is broadcast (not unicast) so that all DHCP servers on the network see it. Servers whose offers were not accepted can then release their tentatively reserved addresses back into the pool.

The DHCPREQUEST includes the server identifier option (the IP address of the chosen server) and the requested IP address option (the address the client wants). The transaction ID matches the original Discover, allowing servers to correlate the messages.

Step 4: DHCP Acknowledge

The selected server responds with a DHCPACK (acknowledge) message, confirming the address assignment and providing the full set of configuration parameters. Once the client receives the ACK, it configures its network interface with the assigned address and begins communicating on the network.

If the server determines that the requested address is no longer available (perhaps it was assigned to another client in the interim), it sends a DHCPNAK (negative acknowledge) instead. The client must then restart the DORA process from the Discover step.

The entire DORA process typically completes in under 10 milliseconds on a local network. The use of broadcasts means DHCP is inherently confined to a single Layer 2 broadcast domain, which is why DHCP relay agents are needed for networks where the server is on a different subnet (covered below).

DHCP Lease Lifecycle

A DHCP lease is not permanent. The server grants the client use of an IP address for a specific duration, after which the address can be reclaimed and assigned to another device. This lease model is what makes DHCP dynamic and what makes it practical for networks where devices constantly join and leave.

Lease Duration

The lease time is configured on the server and can range from minutes to days. Typical settings depend on the environment:

• Corporate offices — 8 to 24 hours. Devices are present during working hours and leave at night, so addresses are recycled daily.
• Home networks — 24 hours to 7 days. Devices tend to be consistent, so longer leases reduce renewal traffic.
• Public Wi-Fi / guest networks — 1 to 4 hours. Short leases ensure addresses are reclaimed quickly when visitors leave.
• Conference / event networks — 15 to 60 minutes. Very high device turnover requires aggressive recycling.

Renewal (T1 Timer)

When a client has used 50% of its lease time (the T1 timer), it begins attempting to renew the lease. Unlike the initial DORA sequence, renewal uses unicast: the client sends a DHCPREQUEST directly to the server that granted the lease. If the server is available and the address is still valid, it responds with a DHCPACK containing a fresh lease duration. This is the normal, quiet maintenance path that keeps most clients on the same address indefinitely.

For example, with a 24-hour lease, the client begins renewal attempts at the 12-hour mark. If the first attempt fails, it retries periodically. The client does not wait until the lease expires to begin renewal, which provides a large window to handle transient server unavailability.

Rebinding (T2 Timer)

If the client fails to reach its original server by the time 87.5% of the lease has elapsed (the T2 timer), it enters the rebinding state. Now the client broadcasts its DHCPREQUEST so that any DHCP server on the network can respond. This is a failover mechanism: if the original server has gone down, a backup server can take over the lease.

With a 24-hour lease, T1 fires at 12 hours and T2 at 21 hours. If no server responds to rebinding attempts and the lease expires entirely, the client must release the IP address, take its interface down, and restart the DORA process from scratch.

Lease Release and Decline

When a client shuts down gracefully (e.g., dhclient -r on Linux or an orderly OS shutdown), it sends a DHCPRELEASE message to the server, returning the address to the pool immediately. This is a courtesy that improves address utilization, but it is not required or guaranteed. If a device loses power or disconnects abruptly, the server simply waits for the lease to expire before reclaiming the address.

A client may also send a DHCPDECLINE message if it performs an ARP check on its newly assigned address and discovers that another device is already using it. This signals an address conflict to the server, which marks the address as unavailable for investigation.

DHCP Options: More Than Just an IP Address

DHCP does not merely assign IP addresses. The protocol defines a rich set of options (originally called vendor extensions in RFC 1497, later expanded in RFC 2132) that allow the server to push a complete network configuration to clients. Each option is identified by a numeric code and carries a specific type of configuration data.

Essential Options

• Option 1: Subnet Mask — Tells the client the subnet mask for the assigned address (e.g., 255.255.255.0 for a /24). Without this, the client cannot determine which addresses are local vs. which require routing.
• Option 3: Router (Default Gateway) — The IP address of the default gateway. All traffic destined outside the local subnet is sent here. This is how devices know where to send packets bound for the broader internet, where BGP takes over routing at the network edge.
• Option 6: DNS Servers — A list of DNS resolver addresses. Most home routers provide their own address here, acting as a DNS forwarder; enterprise networks may point to internal DNS infrastructure.
• Option 51: Lease Time — The duration in seconds for which the address assignment is valid.
• Option 54: Server Identifier — The IP address of the DHCP server, used by the client in its DHCPREQUEST to indicate which server's offer it is accepting.

Extended Options

• Option 12: Hostname — The client can send its hostname to the server, which may use it for dynamic DNS registration.
• Option 15: Domain Name — The DNS domain name the client should use for name resolution (e.g., corp.example.com), allowing short hostnames to be resolved within the local domain.
• Option 42: NTP Servers — Addresses of Network Time Protocol servers for clock synchronization. Accurate time is critical for Kerberos authentication, TLS certificate validation, and log correlation.
• Option 43: Vendor-Specific Information — A catch-all for vendor-defined data. Cisco IP phones, for example, use this to learn the address of their call manager.
• Option 66: TFTP Server Name — Used for PXE booting, telling diskless workstations where to download their boot image.
• Option 67: Boot File Name — The filename of the boot image on the TFTP server, completing the PXE boot chain.
• Option 119: Domain Search List — A list of DNS search domains, allowing users to type short names that get resolved by trying each domain suffix in order.
• Option 121: Classless Static Routes — Pushes specific routes to the client, enabling more complex routing than a simple default gateway. This option uses CIDR notation and supersedes the older Option 33.
• Option 252: WPAD (Web Proxy Auto-Discovery) — Provides a URL for proxy auto-configuration, commonly used in enterprise networks to direct web traffic through proxy servers.

The flexibility of DHCP options means that a single protocol can bootstrap an entire device's network stack in one exchange — IP address, routing, name resolution, time sync, boot files, and proxy configuration, all without any manual setup.

DHCP Relay Agents

DHCP relies on broadcast messages, which by definition do not cross router boundaries. In a network with multiple subnets, this creates a problem: do you need a DHCP server on every subnet? The answer is no, thanks to DHCP relay agents (also called IP helpers).

A relay agent is a function configured on a router or Layer 3 switch at the boundary of each subnet. When the relay agent hears a DHCP broadcast from a client on its local subnet, it rewrites the packet and forwards it as a unicast message to a central DHCP server on a different subnet. Critically, the relay agent inserts its own interface IP address into the giaddr (gateway IP address) field of the DHCP message. This tells the remote server which subnet the client is on, so the server can allocate an address from the correct pool.

In a typical enterprise, a single pair of DHCP servers (primary and failover) serves dozens or hundreds of subnets, each with a relay agent on the local router. The server maintains separate address pools for each subnet, identified by the giaddr value in incoming requests. This centralized model simplifies management enormously: address pools, lease times, and options are configured in one place rather than on a server in every wiring closet.

On Cisco routers, the relay function is enabled with the ip helper-address interface command. On Linux, the ISC DHCP relay daemon (dhcrelay) serves the same purpose. Most enterprise switches and routers support DHCP relaying as a standard feature.

Static vs. Dynamic Allocation

DHCP supports three allocation strategies, and most deployments use a combination:

Dynamic Allocation

This is the default mode. The server maintains a pool of available addresses and assigns them to clients on a first-come, first-served basis. When a lease expires and is not renewed, the address returns to the pool. This is ideal for end-user devices like laptops and phones that come and go.

Automatic Allocation

The server permanently assigns an address to a client, effectively creating an infinite lease. The address is recorded and the same client always gets the same address, but the assignment still happens via DHCP rather than manual configuration. This is useful when you want the benefits of centralized management without address churn.

Static (Reserved) Allocation

The administrator creates a mapping between a client's MAC address and a specific IP address in the server configuration. When the client with that MAC address requests an address, it always receives the designated one. This is commonly used for servers, printers, network-attached storage, and other infrastructure devices that need a predictable IP address for DNS records or firewall rules, but where you still want the device to receive its full configuration (gateway, DNS, NTP) from DHCP rather than maintaining it locally.

The distinction matters operationally. A fully static configuration (hardcoded in the device's OS) means you must touch the device to change anything. A DHCP reservation gives you a fixed IP but centralized control over all other parameters. If you change DNS servers across your entire network, a DHCP reservation picks up the change automatically, while a fully static configuration requires manual updates on every device.

DHCP Server Redundancy and Failover

Because DHCP is critical infrastructure (devices cannot communicate without it), redundancy is essential in production environments. There are several approaches:

Split-Scope (Active-Active)

Two servers each manage a portion of the same address pool. A common split is 80/20: the primary server handles 80% of the pool and the secondary handles 20%. If either server fails, the other continues serving addresses from its portion. The downside is that the total pool is effectively smaller since each server only uses its allocated range.

DHCP Failover Protocol

Defined in RFC 3074 (draft), this protocol allows two servers to replicate lease state and coordinate address allocation. ISC DHCP and Microsoft DHCP Server both implement failover. The servers exchange heartbeats, and if one goes down, the other takes over the full pool. This is more complex to configure but provides true redundancy without wasting addresses.

High-Availability Clusters

In large-scale deployments, DHCP servers may run in clustered configurations with shared storage for the lease database. Kea DHCP (ISC's modern replacement for the legacy dhcpd) supports PostgreSQL and MySQL backends, enabling multiple server instances to share a centralized lease store.

DHCPv6 and IPv6 Address Configuration

The transition to IPv6 fundamentally changed how address assignment works, because IPv6 introduced a mechanism called SLAAC (Stateless Address Autoconfiguration) that can operate entirely without a DHCP server. Understanding when to use DHCPv6 vs. SLAAC (or both together) is essential for IPv6 network design.

SLAAC (Stateless Address Autoconfiguration)

With SLAAC (defined in RFC 4862), an IPv6 host generates its own address using two ingredients: the network prefix advertised by the local router via Router Advertisement (RA) messages, and a host portion derived from the device's MAC address (using the EUI-64 algorithm) or generated randomly (RFC 7217 stable privacy addresses). No server is involved — the host simply listens for RA messages, constructs its address, and performs Duplicate Address Detection (DAD) to ensure uniqueness.

SLAAC is elegant for address assignment, but it has a significant limitation: it provides no mechanism for delivering other configuration like DNS server addresses, NTP servers, or domain search lists. RFC 8106 (RDNSS) added DNS information to RA messages, but support is not universal, and other options remain unavailable. This is where DHCPv6 comes in.

Stateful DHCPv6

DHCPv6 (RFC 8415, which consolidated earlier RFCs 3315 and 3633) is a complete rewrite of the DHCP protocol for IPv6. It is not simply DHCPv4 with longer addresses. Key differences include:

• Uses multicast instead of broadcast — DHCPv6 clients send messages to the ff02::1:2 multicast address (all DHCP relay agents and servers) rather than the broadcast address. This is more efficient on large networks.
• DUID instead of MAC address — Clients and servers identify themselves using a DHCP Unique Identifier (DUID), which persists across interface changes (unlike MAC addresses, which are per-interface).
• Four-message exchange: SARR — The DHCPv6 equivalent of DORA is Solicit, Advertise, Request, Reply. The semantics are similar but the message names differ.
• Two-message exchange possible — For stateless configuration (options only, no address), a simple Solicit/Reply (with the Rapid Commit option) suffices.
• Prefix delegation (PD) — DHCPv6 can delegate entire prefixes to downstream routers, which is how ISPs assign /48 or /56 prefixes to customer routers that then subnet and distribute addresses internally.
• No gateway option — DHCPv6 does not assign a default gateway. The gateway is always learned from Router Advertisements. This is a deliberate design decision in IPv6: routing information comes from routers (RA), not from DHCP.

Stateless DHCPv6 (SLAAC + DHCPv6)

The most common IPv6 deployment combines SLAAC for address assignment with stateless DHCPv6 for options. The router sets the O flag (Other Configuration) in its RA messages, telling clients: "Generate your own address via SLAAC, but contact a DHCPv6 server for DNS and other options." This hybrid approach gives you the simplicity of SLAAC with the configuration richness of DHCP.

Alternatively, the router can set the M flag (Managed Address Configuration), telling clients to use DHCPv6 for both address assignment and options, effectively disabling SLAAC. This is common in enterprise environments where administrators want centralized control over address allocation.

DHCP Snooping and Security

DHCP's broadcast-based, unauthenticated design creates several security vulnerabilities that attackers can exploit on shared networks.

Rogue DHCP Server Attack

An attacker connects a device running a DHCP server to the network. When legitimate clients broadcast DHCPDISCOVER messages, the rogue server responds with its own Offer, potentially providing a malicious default gateway (pointing traffic through the attacker's machine for interception), poisoned DNS servers (redirecting domain lookups to attacker-controlled resolvers), or invalid configuration that causes denial of service.

Because clients typically accept the first Offer they receive, and the rogue server may respond faster than the legitimate one, this attack is surprisingly effective and difficult to detect without countermeasures.

DHCP Starvation Attack

An attacker sends thousands of DHCPDISCOVER messages, each with a different spoofed MAC address, exhausting the server's entire address pool. Legitimate clients that subsequently connect receive no address. This is a denial-of-service attack that can be amplified across relay agents.

DHCP Snooping

DHCP snooping is a Layer 2 security feature implemented on managed switches that acts as a firewall between untrusted clients and DHCP servers. When enabled, the switch classifies each port as either trusted or untrusted:

• Trusted ports — Uplinks to routers, servers, or other switches. DHCP server messages (Offer, ACK) are permitted from these ports.
• Untrusted ports — End-user access ports. The switch blocks any DHCP server messages (Offer, ACK, NAK) originating from these ports. Only client messages (Discover, Request, Release, Decline) are permitted.

DHCP snooping also builds a binding table that maps IP addresses to MAC addresses, port numbers, and VLAN IDs based on observed DHCP exchanges. This binding table becomes the foundation for other security features:

• Dynamic ARP Inspection (DAI) — Validates ARP packets against the snooping binding table, preventing ARP spoofing attacks.
• IP Source Guard — Filters IP traffic based on the binding table, preventing clients from using IP addresses they were not assigned via DHCP.

Together, these features create a chain of trust: DHCP snooping ensures only legitimate servers assign addresses, DAI ensures ARP mappings match DHCP assignments, and IP Source Guard ensures traffic comes from legitimately assigned addresses.

802.1X and DHCP

In high-security environments, 802.1X port-based authentication is deployed alongside DHCP. The switch does not permit any traffic (including DHCP) on a port until the connecting device authenticates via EAP (Extensible Authentication Protocol). Once authenticated, the port is placed in the appropriate VLAN, and only then does DHCP proceed. This ensures that only authorized devices receive network configuration.

DHCP Message Format

The DHCPv4 message is carried inside a UDP datagram and has a fixed-size header followed by a variable-length options field. The format inherits from the older BOOTP protocol (RFC 951), which DHCP extends and is backward-compatible with.

 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)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  magic cookie (4): 99.130.83.99                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     options (variable)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Key fields in the DHCP header:

• op — Operation code: 1 for client request (BOOTREQUEST), 2 for server reply (BOOTREPLY).
• htype / hlen — Hardware address type (1 for Ethernet) and length (6 bytes for MAC addresses).
• hops — Incremented by relay agents as the message crosses network boundaries. Servers can limit the maximum hop count to prevent forwarding loops.
• xid — Transaction ID, a random 32-bit number chosen by the client. All four DORA messages in a single transaction share the same xid.
• ciaddr — Client IP address. Set to 0.0.0.0 during initial allocation; set to the client's current IP during renewal.
• yiaddr — "Your" IP address. The server places the offered/assigned address here.
• siaddr — Next server IP, used in PXE/BOOTP boot scenarios to indicate the TFTP server.
• giaddr — Gateway (relay agent) IP address. This is the crucial field that tells the server which subnet the client belongs to when relay agents are involved.
• chaddr — Client hardware (MAC) address, used to identify the client.
• magic cookie — The four bytes 99.130.83.99 (hex 63.82.53.63) mark the beginning of the DHCP options field, distinguishing DHCP from plain BOOTP.

Common DHCP Implementations

Several DHCP server implementations are widely deployed, each with different strengths:

• ISC DHCP (dhcpd) — The historic standard on Unix/Linux systems, maintained by the Internet Systems Consortium. Configuration is file-based (dhcpd.conf) with a declarative syntax. While extremely stable and well-understood, ISC DHCP reached end-of-life in late 2022 and is no longer actively developed.
• ISC Kea — The modern replacement for ISC DHCP. Kea uses a JSON configuration file, supports database backends (MySQL, PostgreSQL, Cassandra) for lease storage, and provides a RESTful API for dynamic configuration. It supports both DHCPv4 and DHCPv6, including prefix delegation.
• Microsoft DHCP Server — Integrated into Windows Server, with a GUI management console and Active Directory integration. Supports failover, DHCP policies (conditional option assignment based on client attributes), and integrates with Microsoft DNS for dynamic DNS updates.
• dnsmasq — A lightweight DNS forwarder and DHCP server popular on embedded devices, home routers, and small networks. OpenWrt and many commercial consumer routers use dnsmasq. It combines DNS caching, DHCP, TFTP, and PXE boot in a single small binary.
• Infoblox / BlueCat / EfficientIP — Commercial DDI (DNS, DHCP, IPAM) platforms used in large enterprises. They provide centralized management, audit logging, and integration with network automation workflows.

DHCP and Network Troubleshooting

When a device cannot connect to the network, DHCP is one of the first things to check. Common symptoms and their causes include:

169.254.x.x Address (APIPA)

If a Windows or macOS device obtains an address in the 169.254.0.0/16 range, it means DHCP failed entirely. The device fell back to Automatic Private IP Addressing (APIPA), which assigns a link-local address usable only for communication within the immediate broadcast domain. This typically indicates no DHCP server is reachable — check that the server is running, the relay agent is configured, and there is Layer 2 connectivity between the client and the server or relay.

IP Address Conflicts

If two devices end up with the same IP address, the result is intermittent connectivity for both. This can happen when a device has a statically configured address that falls within the DHCP pool, or when a device retains an expired lease address while the server has reassigned it. Modern DHCP servers mitigate this by pinging candidate addresses before assignment and by using conflict detection mechanisms.

Wrong Subnet Configuration

If a client receives an address but cannot reach the gateway or other local devices, the subnet mask may be incorrect. A /16 mask on a /24 network (or vice versa) causes the client to misidentify which addresses are local vs. remote, breaking routing.

Debugging with Packet Captures

The most definitive troubleshooting method is capturing DHCP traffic with tools like tcpdump or Wireshark. Filter for UDP ports 67 and 68 to see the complete DORA exchange:

tcpdump -i eth0 -n port 67 or port 68

This shows whether the client is sending Discovers, whether the server is replying with Offers, and the exact options contained in each message. On Linux clients, you can also examine the DHCP client state with dhclient -v (verbose mode) or journalctl -u NetworkManager for systems using NetworkManager.

DHCP in Modern Networks

Despite being over 30 years old (DHCP's predecessor BOOTP dates to 1985, and DHCP itself was standardized in RFC 1531 in 1993), DHCP remains one of the most fundamental protocols in networking. It operates beneath the layer that most users or even application developers think about, but its absence is immediately felt when it breaks — no IP address means no connectivity, period.

Modern trends are evolving how DHCP is deployed:

• Cloud and container environments — In cloud platforms, the hypervisor or SDN controller assigns addresses through a metadata service rather than traditional DHCP. AWS, Azure, and GCP all provide DHCP servers within their virtual networks, but the implementation is tightly integrated with the cloud control plane. Container orchestrators like Kubernetes use CNI plugins that assign addresses from allocated prefixes without DHCP.
• Zero Trust networks — DHCP snooping and 802.1X are increasingly common as organizations move toward zero-trust architectures where every device must authenticate before receiving any network access.
• IPv6 transition — As IPv6 adoption grows, the choice between SLAAC, stateless DHCPv6, and stateful DHCPv6 becomes a key design decision. Many networks are converging on SLAAC with stateless DHCPv6 for options as the standard approach.
• Network automation — Modern DHCP servers like Kea provide APIs for dynamic pool management, enabling integration with IPAM systems and infrastructure-as-code workflows. Address pools, reservations, and options can be managed programmatically rather than through configuration files.

Understanding DHCP gives you insight into the very first thing that happens when any device joins a network. Before DNS can resolve a name, before BGP can route a packet to its destination, before TLS can encrypt a connection — the device must first get its address. That is what DHCP does, and it does it billions of times per day across every network on the planet.

Use our BGP Looking Glass to explore how traffic is routed once devices have their addresses — look up any IP address to see its BGP origin, AS path, and the prefix that covers it.