Lesson 10 of 12

DHCP

17 min read

DHCP — Dynamic Host Configuration Protocol

Every device on a network needs an IP (Internet Protocol) address to communicate. It also needs to know where to send traffic destined for other networks (the default gateway), and which server to ask for name lookups (the DNS, or Domain Name System, server). Configuring all of this manually on every device — a laptop, a phone, a smart TV, a printer — would be tedious at home and completely unworkable in an organization with thousands of devices. DHCP (Dynamic Host Configuration Protocol) solves this problem by automatically handing out network configuration to devices the moment they connect.

What DHCP Is and Why It Exists

DHCP is a network protocol that automatically assigns IP addresses and delivers network configuration parameters to devices when they join a network. A device that connects to a network sends a broadcast asking for an address. A DHCP server receives that request, selects an available address from its pool, and delivers it along with the other settings the device needs. The device configures itself and is immediately ready to communicate.

Before DHCP — and before its predecessor BOOTP (Bootstrap Protocol) — every device required manual configuration. A network administrator had to physically visit each machine (or use remote management tools) and type in an IP address, subnet mask, default gateway, and DNS server. Change the gateway? Update every machine. Add a server? Hope you have not already used that IP address somewhere else. At any meaningful scale, this was an administrative nightmare with a high error rate.

DHCP replaced that with automation. The protocol is defined in RFC (Request for Comments) 2131, published by the IETF (Internet Engineering Task Force) in 1997.

What DHCP Provides to a Client

When a DHCP server assigns an address to a device, it delivers a complete set of network configuration. The core items are:

IP address: The unique address assigned to this device on the local network for the duration of the lease.

Subnet mask: Tells the device which part of the IP address identifies the network and which part identifies the host. The subnet mask defines the network boundary — traffic destined for addresses within the mask stays on the local network; everything else is sent to the default gateway.

Default gateway: The IP address of the router. When your device wants to reach something outside the local network (any website, any server on the internet), it sends the traffic to the default gateway, which forwards it toward the destination.

DNS server(s): The address of one or more recursive DNS resolvers the device should use for name lookups. Without this, you would have an IP address but no ability to resolve domain names.

Lease duration: How long the IP address assignment is valid. After this period, the device must renew or release the address.

Beyond these core parameters, DHCP can deliver optional configuration through numbered option codes:

Option 42: NTP (Network Time Protocol) server address — tells devices where to synchronize their clocks
Option 15: Domain name suffix — allows short hostnames to be automatically expanded (so you can type "fileserver" instead of "fileserver.company.local")
Options 66 and 67: TFTP (Trivial File Transfer Protocol) server and boot filename — used in PXE (Preboot Execution Environment) setups where devices boot their operating system over the network rather than from a local drive

The DORA Process — Four Steps

The exchange between a DHCP client and a DHCP server follows a four-step handshake. These steps are commonly called DORA: Discover, Offer, Request, Acknowledge.

Step 1 — DHCP Discover

A newly connected device has no IP address. It cannot send unicast (addressed to a single destination) traffic because it has no address to put in the source field and does not know who the DHCP server is. Instead, it sends a broadcast — a message delivered to every device on the local network segment.

The Discover message says, in effect: "I need an IP address. Is there a DHCP server here? My MAC (Media Access Control) address is AA:BB:CC:DD:EE:FF."

Source IP: 0.0.0.0 (the device has no address yet)
Destination IP: 255.255.255.255 (the limited broadcast address — delivered to all devices on the local segment)
Source MAC: the client's real hardware address (used to identify the client when a response is sent back)
Transport: UDP (User Datagram Protocol), source port 68 (DHCP client), destination port 67 (DHCP server)

The Discover message also includes a transaction ID — a random number the client generates — that will be echoed back in all subsequent messages so the client can match responses to its original request.

Step 2 — DHCP Offer

One or more DHCP servers on the network receive the Discover broadcast. Each eligible server selects an available IP address from its pool and sends an Offer message back to the client.

The Offer says: "I am DHCP server 192.168.1.1. I can offer you IP address 192.168.1.100, valid for 86,400 seconds (24 hours). Your subnet mask is 255.255.255.0, your default gateway is 192.168.1.1, and your DNS servers are 8.8.8.8 and 8.8.4.4."

Because the client still has no IP address, this response is also broadcast (or sent to the client's MAC address at the link layer) — the server cannot unicast to an IP address that has not been officially assigned yet.

The Offer contains the full proposed configuration: IP address, subnet mask, lease duration, gateway, DNS servers, and any other configured options.

Step 3 — DHCP Request

If multiple DHCP servers sent Offers, the client receives them all. The client typically accepts the first Offer it receives. It then broadcasts a Request message: "I would like to accept the offer from server 192.168.1.1 for the address 192.168.1.100."

The Request is deliberately sent as a broadcast rather than a unicast message to the chosen server. This serves an important purpose: any other DHCP servers that made competing offers see the Request, learn that their offer was not accepted, and can return the address they had tentatively reserved to their available pool.

The Request includes the IP address of the chosen server (in the DHCP Server Identifier option) so servers that are not chosen know their offer was declined.

Step 4 — DHCP Acknowledge

The chosen DHCP server receives the Request and sends an Acknowledge (sometimes written ACK) message to confirm the assignment.

The Acknowledge says: "Confirmed. The address 192.168.1.100 is yours for the next 86,400 seconds. Here is your complete configuration."

Upon receiving the Acknowledge, the client configures its network interface with the assigned IP address, subnet mask, default gateway, and DNS servers. The device is now fully connected and can communicate on the network and beyond.

In some situations, a server sends a DHCP NAK (Negative Acknowledge) instead — for example, if the client is requesting a specific address that is no longer available, or if the client appears to be on a different network than expected. A NAK tells the client to start the DORA process over.

DHCP Leases

An IP address assigned by DHCP is not permanent — it is a lease, a time-limited assignment. The DHCP server records which address has been leased to which MAC address and for how long. The client is responsible for renewing the lease before it expires.

At 50% of the lease duration: The client attempts to renew directly with the same DHCP server that issued the lease, using a unicast Request message. If the server is available, it sends an Acknowledge with a fresh full-length lease.

At 87.5% of the lease duration: If the client has not successfully renewed (perhaps because the original DHCP server was unreachable), it broadcasts a renewal request to any available DHCP server on the segment. Any server that can offer a renewal may respond.

At 100% (lease expired): If all renewal attempts have failed, the client must stop using the address immediately — using an address whose lease has expired can cause conflicts with another device that may have been assigned the same address. The client starts the full DORA process over from scratch.

This tiered renewal system means that brief DHCP server outages typically go unnoticed — clients simply renew when the server comes back, long before their leases expire.

Viewing and Managing Your DHCP Lease

On Windows, you can inspect your current DHCP configuration, including the DHCP server address, when the lease was obtained, and when it expires:

ipconfig /all

To release the current lease and obtain a new one:

ipconfig /release
ipconfig /renew

On Linux, to view the current address assignment:

ip addr show

To force a DHCP renewal on Linux (replace eth0 with your interface name):

dhclient -v eth0

DHCP Reservations (Static DHCP)

A DHCP reservation — sometimes called a static DHCP assignment — tells the DHCP server to always give a specific IP address to a specific device, identified by its MAC address.

This is useful for devices that need a predictable, consistent address — servers, network printers, IP cameras, network-attached storage devices — while still using DHCP rather than requiring manual configuration on the device itself. The device goes through the normal DORA process, but the server recognizes its MAC address and offers the reserved IP address every time.

The advantage over purely static configuration is that all the network settings (including gateway and DNS) are still centrally managed on the DHCP server. If the gateway address changes, you update it in one place.

DHCP Scope and Address Pool

The DHCP server is configured with a scope — the range of IP addresses it is permitted to lease. For example, a scope might be defined as 192.168.1.100 to 192.168.1.200. The server will only assign addresses within this range to DHCP clients.

This leaves the rest of the subnet — for example, 192.168.1.1 through 192.168.1.99 and 192.168.1.201 through 192.168.1.254 — available for static assignment to infrastructure devices like routers, switches, servers, and printers. Because those addresses fall outside the DHCP scope, the DHCP server will never hand them out, eliminating the risk of IP address conflicts between statically configured devices and DHCP clients.

When all addresses in the scope are leased, the DHCP server cannot offer new addresses until existing leases expire or are released. A pool that is consistently full is a sign that the scope is too small or the lease duration is too long for the number of devices connecting.

DHCP Options

DHCP delivers configuration beyond the basic IP address through a system of numbered option codes. The client requests the options it wants in its Discover and Request messages; the server includes the corresponding values in its Offer and Acknowledge messages.

Key option codes:

Option 1: Subnet mask
Option 3: Default gateway (sometimes called the router option)
Option 6: DNS (Domain Name System) server addresses (up to multiple servers, tried in order)
Option 15: Domain name — the default search domain appended to unqualified hostnames
Option 42: NTP (Network Time Protocol) server — for clock synchronization
Option 51: Lease time in seconds
Option 66: TFTP (Trivial File Transfer Protocol) server hostname or IP — used in PXE (Preboot Execution Environment) boot scenarios
Option 67: Boot file name — the path to the file the PXE client should download and execute to boot

In enterprise environments, DHCP options are often used to deliver specialized configuration — pointing VoIP (Voice over Internet Protocol) phones to the call manager server, directing network boot clients to the correct deployment server, or configuring domain membership parameters.

Security Threats Involving DHCP

DHCP was designed for convenience, not security. The DORA process is unauthenticated — any device on the network can answer a Discover with an Offer. This creates serious attack opportunities.

Rogue DHCP Server

In a rogue DHCP server attack, an attacker connects an unauthorized device to the network and runs DHCP server software on it. When legitimate devices send DHCP Discover messages, the rogue server races the legitimate server to respond first. If it wins the race (or if the legitimate server is slow or unreachable), the victim client accepts the rogue server's Offer.

The attacker can configure the rogue server to deliver malicious network settings:

Rogue default gateway: The attacker sets their device's IP as the default gateway. All of the victim's outbound traffic flows through the attacker's machine, which can read, modify, and selectively forward it. This is a man-in-the-middle (MITM) position on the network.
Rogue DNS server: The attacker sets their device's IP as the DNS server. Every name lookup the victim performs is answered by the attacker, who can return forged responses — sending the victim to attacker-controlled servers for any domain.

Together, these two capabilities give the attacker nearly complete visibility and control over the victim's network traffic. The victim typically notices nothing — the device connects normally, the internet appears to work, and there are no error messages.

A rogue DHCP server is trivial to set up on an unsecured network. A laptop running standard server software is sufficient.

DHCP Starvation

In a DHCP starvation attack, the attacker floods the network with DHCP Discover messages, each using a different spoofed MAC address as the source. The DHCP server receives thousands of requests for addresses, each appearing to come from a different device, and allocates an address for each one. Within seconds or minutes, the address pool is exhausted.

Now when a legitimate device connects and sends a Discover, the DHCP server has no addresses left to offer. The device cannot obtain an IP address and cannot connect to the network. This is a denial of service attack against network access.

DHCP starvation is often used as a precursor to deploying a rogue DHCP server. With the legitimate DHCP server unable to respond (pool exhausted), the attacker's rogue server can fill the void, and devices that retry their Discover messages after the starvation will receive addresses from the attacker.

DHCP Snooping (Defense)

DHCP snooping is a security feature available on managed network switches that defends against rogue DHCP servers. The network administrator configures specific switch ports as trusted — these are the ports connected to legitimate DHCP servers or to uplinks toward DHCP servers. All other ports are untrusted by default.

When DHCP snooping is enabled:

DHCP Offer and Acknowledge messages arriving on untrusted ports are dropped silently. A rogue DHCP server plugged into a user-facing port cannot deliver addresses to clients.
DHCP Discover and Request messages (from clients) are permitted on untrusted ports.
The switch builds a DHCP snooping binding table that maps each leased IP address to the MAC address of the client that received it, the port the client is connected to, and the lease duration.

This binding table is then used by other security features:

Dynamic ARP (Address Resolution Protocol) Inspection (DAI): Validates ARP packets against the binding table. If an ARP response claims that IP address 192.168.1.100 belongs to a MAC address that does not match the binding table entry, the packet is dropped. This prevents ARP spoofing and ARP poisoning attacks.
IP Source Guard: Validates the source IP of packets leaving a port against the binding table. If a device tries to send traffic with an IP address it was not assigned, the packets are dropped.

Together, DHCP snooping and its dependent features provide a layered defense against several classes of network layer attacks.

DHCP in IPv6

IPv6 (Internet Protocol version 6) introduces a new approach to address configuration alongside the DHCPv6 protocol.

DHCPv6: The IPv6 equivalent of DHCP. It works similarly to DHCP for IPv4 but is adapted for IPv6 addressing. DHCPv6 can deliver full address configuration including IPv6 address, prefix length, DNS servers, and domain names.

SLAAC (Stateless Address Autoconfiguration): A mechanism unique to IPv6 that allows a device to configure its own IPv6 address without a DHCP server. Routers on the network periodically broadcast RA (Router Advertisement) messages that contain the network prefix (the network portion of the IPv6 address). The device combines this prefix with a host-unique identifier — derived either from the device's MAC address (using a process called EUI-64) or a randomly generated value (RFC 7217 Stable Privacy Addresses) — to form a complete, globally unique IPv6 address.

SLAAC significantly reduces infrastructure requirements — devices can self-configure even with no DHCP server present. However, SLAAC alone does not provide DNS server information; the DNS resolver address is typically delivered by a separate mechanism called RDNSS (Recursive DNS Server option in Router Advertisements, defined in RFC 8106) or by DHCPv6 operating alongside SLAAC.

In practice, many IPv6 networks use a combination: SLAAC for address assignment and a minimal DHCPv6 deployment (called stateless DHCPv6) for delivering DNS and domain name information.

The Bottom Line

DHCP automates IP address assignment and network configuration using a four-step DORA exchange: Discover (client broadcasts a request), Offer (server proposes an address and settings), Request (client formally accepts), Acknowledge (server confirms the lease). Every assignment is a lease with a defined expiration, and clients renew at 50% and 87.5% of the lease duration. DHCP delivers not just an IP address but also the subnet mask, default gateway, DNS servers, and optional extras like NTP servers and PXE boot parameters. DHCP reservations tie specific IP addresses to specific MAC addresses for devices that need consistent addressing. The protocol's unauthenticated design makes it vulnerable to rogue DHCP servers and starvation attacks; DHCP snooping on managed switches is the primary defense. IPv6 adds SLAAC as an alternative to DHCPv6, allowing devices to self-configure their addresses from router-advertised network prefixes.

Check Your Understanding

Walk through the DORA process in your own words. What is the source IP address in the initial Discover message, and why?
A DHCP scope for a network is configured as 10.0.0.50 to 10.0.0.150. A network printer is assigned the static IP address 10.0.0.10 on the same subnet. Could the DHCP server accidentally assign 10.0.0.10 to another device? Why or why not?

Something to Think About

An attacker on your network segment sets up a rogue DHCP server and delivers their own machine's IP as the default gateway to connected clients. From the attacker's position, what would they be able to do with the traffic flowing through their machine? What would the victim user likely notice, if anything?
DHCP snooping designates switch ports as trusted or untrusted. If a network administrator forgets to configure DHCP snooping on a newly installed switch, what specific attack does that omission enable, and how quickly could an attacker exploit it once they have physical or logical access to a connected port?

References

Official Specification. RFC 2131 — "Dynamic Host Configuration Protocol". IETF, 1997. — The primary DHCP specification defining the DORA process, lease mechanics, server and client behavior, and the role of broadcast in unauthenticated address assignment.
Official Specification. RFC 2132 — "DHCP Options and BOOTP Vendor Extensions". IETF, 1997. — Defines all standard DHCP option codes, including the subnet mask (option 1), default gateway (option 3), DNS servers (option 6), NTP server (option 42), and TFTP boot options (options 66 and 67).
Official Specification. RFC 4862 — "IPv6 Stateless Address Autoconfiguration". IETF. — Defines SLAAC, the IPv6 mechanism that allows devices to derive a globally unique address from a router-advertised prefix combined with a host-unique identifier, without requiring a DHCP server.
Official Guidance. NIST SP 800-119 — "Guidelines for the Secure Deployment of IPv6". NIST. — Covers DHCP and SLAAC security considerations in IPv6 deployments, including rogue DHCP server threats, rogue router advertisement threats, and recommended mitigations for each.
Real-World Context. CISA — "Advisory AA22-011A: Understanding and Mitigating Russian State-Sponsored Cyber Threats". CISA. — Documents network-level lateral movement and man-in-the-middle techniques — including gateway and DNS manipulation — that represent the end goal of a successful rogue DHCP attack against a network segment.