How DHCP Assigns IP Addresses: The Complete 2026 Guide

Every second, millions of devices connect to networks around the world — and almost none of them require a human to manually type in an IP address. That seamless process happens because of DHCP, or the Dynamic Host Configuration Protocol. Yet most guides barely scratch the surface: they explain what DHCP is but skip how it actually works at each step, what gets sent, and what breaks when it fails.

This guide fixes that. You will learn exactly how DHCP assigns IP addresses — from the first broadcast your device sends to the moment it is fully online — plus how leases work, the three allocation methods available, and how to troubleshoot the most common DHCP problems.

What Is DHCP and Why Does It Exist?

DHCP (Dynamic Host Configuration Protocol) is a network management protocol that automatically assigns IP addresses and related configuration parameters to devices the moment they connect to a network. It runs at the application layer of the TCP/IP stack, using UDP port 67 on the server side and UDP port 68 on the client side.

Before DHCP existed, every network administrator had to manually set the IP address, subnet mask, default gateway, and DNS servers on every single device. On a network with 500 laptops, 200 phones, and dozens of printers, that meant hundreds of individual configurations — each prone to human error, typos, and duplicate addresses. DHCP eliminates that entire workflow by centralizing IP address management on a single server. The result is a plug-and-play experience: a device connects, receives everything it needs in under a second, and immediately starts communicating.

How DHCP Assigns IP Addresses: The DORA Process

DHCP assigns IP addresses through a four-step handshake between the client device and the DHCP server. This process is universally known by the acronym DORA — Discover, Offer, Request, Acknowledge. Each stage involves a specific type of message, a specific broadcast or unicast transmission, and a specific set of data being exchanged.

Here is the full breakdown:

Step 1 — DHCP Discover

When a device joins a network without an IP address, the DHCP client broadcasts a DHCPDISCOVER message across the entire local network. Because the device does not yet have an IP, it uses 0.0.0.0 as the source address and 255.255.255.255 as the destination — a broadcast that reaches every device on the subnet.

The discover message essentially asks: “Is there a DHCP server out there? I need an IP address.”

Key details in the Discover packet:

Field	Value
Source IP	0.0.0.0 (no IP yet)
Destination IP	255.255.255.255 (broadcast)
Source MAC	Client’s MAC address
Destination MAC	FF:FF:FF:FF:FF:FF (broadcast)
UDP Source Port	68
UDP Destination Port	67

The client’s MAC address is included so the DHCP server can identify and track the requesting device.

Step 2 — DHCP Offer

Any DHCP server on the network that receives the Discover message responds with a DHCPOFFER message. This offer contains:

• A proposed IP address for the client
• The subnet mask
• The lease duration
• The server’s own IP address
• DNS server addresses
• The default gateway

Because the client still has no IP at this stage, the Offer is typically broadcast at the network layer (destination 255.255.255.255) but sent as a unicast at the data link layer — directly to the client’s MAC address. This ensures the correct device receives the offer without confusion.

If multiple DHCP servers exist on the network, the client may receive multiple offers. It accepts the first one that arrives and ignores the rest.

Step 3 — DHCP Request

After selecting an offer, the client sends a DHCPREQUEST message — also broadcast across the network. This broadcast serves two purposes simultaneously:

1. It formally accepts the chosen server’s offer.
2. It notifies all other DHCP servers that their offers have been declined, allowing them to return those proposed addresses to their pools.

The Request message still uses 0.0.0.0 as the source IP, because the assignment is not yet confirmed. It includes the server identifier of the chosen DHCP server so every device on the network knows which server was selected.

Step 4 — DHCP Acknowledge

The selected DHCP server responds with a DHCPACK message — the final confirmation. This packet officially assigns the IP address to the client and includes the complete set of configuration parameters:

• Confirmed IP address
• Subnet mask
• Lease duration
• Default gateway
• DNS server addresses
• Any additional DHCP options configured by the administrator

Once the client receives the DHCPACK, it configures its network interface with the assigned settings and is fully operational on the network. The entire DORA process typically completes in under one second.

Quick Summary of DORA:

1. Discover — Client broadcasts: “I need an IP address”
2. Offer — Server responds: “Here is an available IP you can use”
3. Request — Client confirms: “I accept that IP address”
4. Acknowledge — Server confirms: “It is yours — here are all your settings”

What Information DHCP Assigns Beyond the IP Address

A common misconception is that DHCP only assigns an IP address. In reality, the DHCP server delivers a full package of network configuration parameters, known as DHCP options. The Internet Assigned Numbers Authority (IANA) defines hundreds of possible options. The most common ones are:

DHCP Option	What It Does
IP Address	Unique address for the device on the local network
Subnet Mask	Defines the boundary of the local network segment
Default Gateway	The router’s IP — routes traffic to the internet or other subnets
DNS Servers	Translates domain names (e.g., google.com) into IP addresses
Lease Time	How long the device may use the assigned IP before renewal is required
Domain Name	The network’s domain (e.g., office.local)
NTP Server	Network Time Protocol server for clock synchronization

Therefore, when your laptop connects to Wi-Fi at a coffee shop and immediately loads a website, DHCP has quietly handed it an IP address, told it where the router is, given it DNS servers to resolve domain names, and set an expiry timer — all in under a second.

The Three DHCP Allocation Methods Explained

DHCP does not use a single approach for every network. Depending on how administrators configure the server, it can use one of three allocation methods:

Dynamic Allocation

This is the most common method. The DHCP server assigns an IP address from a defined pool for a limited period — the lease. When the lease expires, the address returns to the pool and may be assigned to a different device. Dynamic allocation works well for environments where devices frequently connect and disconnect, such as office Wi-Fi networks, hotel networks, and home routers.

Automatic Allocation

In this method, the DHCP server permanently assigns an address from its pool to the first device that requests it. However, unlike static assignment, no administrator manually maps each device to an address. Instead, the server simply never reclaims the address once assigned. This is less common today because dynamic allocation with long lease times achieves the same practical result with more flexibility.

Static (Manual) Allocation

Also called DHCP reservation or MAC address binding, this method ties a specific IP address to a specific device’s MAC address. Every time that device connects, it receives the exact same IP — even though the address technically comes through the DHCP process. Administrators use this for devices that need a predictable address, such as printers, NAS drives, security cameras, and network switches. It combines the convenience of DHCP with the consistency of a static IP.

How DHCP Leases Work (and Why They Expire)

The DHCP lease is one of the most important concepts in IP address management. When a DHCP server assigns an IP address, it does not grant ownership — it grants a temporary license to use that address for a defined period, typically between 24 hours and 7 days depending on the network’s configuration.

Why Leases Exist

Leases prevent IP address pool exhaustion. Without them, a DHCP server with 200 available addresses would run out quickly on a busy network where devices connect and disconnect constantly. With leases, addresses automatically return to the pool when a device disconnects and fails to renew.

The Lease Renewal Process

Clients do not wait until their lease expires before renewing. The renewal sequence works as follows:

1. At 50% of lease duration — The client sends a unicast DHCPREQUEST directly to the original DHCP server, asking to renew the same IP address.
2. At 87.5% of lease duration — If the first renewal attempt failed (for example, the original server is unreachable), the client broadcasts a renewal request to any available DHCP server.
3. At 100% (lease expiry) — If no renewal succeeds, the client must release the IP address and restart the full DORA process to obtain a new one.

During the renewal process, most users notice nothing — the IP address typically stays the same, and connectivity is uninterrupted.

What Happens When a Lease Expires Without Renewal

If a device fails to renew and the lease expires, it loses its IP address and network access. As a fallback, many operating systems assign an APIPA address in the 169.254.0.0/16 range, which signals that DHCP is unavailable. This is often why you see 169.254.x.x addresses when a network connection fails — it means the device could not reach a DHCP server.

DHCP Relay Agents: Crossing Subnets

A standard DHCP Discover message is a broadcast — and broadcasts do not cross routers. This means that, by default, a DHCP server can only serve devices on its own subnet. For larger networks with multiple subnets, this would require a separate DHCP server in every subnet. That is impractical.

The solution is a DHCP relay agent (also called an IP Helper). Here is how it works:

1. A client on Subnet B broadcasts a DHCP Discover message.
2. The relay agent on the local router intercepts the broadcast.
3. The relay agent converts the broadcast into a unicast packet and forwards it to the DHCP server on Subnet A.
4. The DHCP server processes the request and sends its Offer back to the relay agent.
5. The relay agent forwards the Offer to the requesting client.
6. The remaining DORA steps proceed through the relay agent.

Consequently, a single centralized DHCP server can manage IP allocation for an entire enterprise network spanning dozens of subnets — without duplicating infrastructure.

DHCP vs Static IP: When to Use Which

Both approaches have legitimate use cases. The right choice depends on the device’s role on the network.

Factor	Dynamic DHCP	Static IP
Configuration effort	Automatic — zero manual setup	Manual — must be configured on each device
IP consistency	Address may change	Address is fixed
Best for	Laptops, phones, IoT devices, guest devices	Servers, printers, cameras, routers, NAS
Risk of conflicts	Very low — server manages uniqueness	Higher if not tracked carefully
Scalability	Excellent	Poor at scale
Remote troubleshooting	Easier (centralized logs)	Requires knowing each device’s address

For most end-user devices, dynamic DHCP is the right choice because it requires no configuration, avoids conflicts, and handles roaming between subnets gracefully. However, any device that other devices need to reach reliably — like a file server, printer, or IP camera — should receive either a static IP or a DHCP reservation (static allocation through DHCP).

Common DHCP Problems and How to Fix Them

Problem 1: Device Gets a 169.254.x.x Address

Cause: The device could not reach a DHCP server. It fell back to APIPA (Automatic Private IP Addressing).

Fix:

1. Run ipconfig /release then ipconfig /renew (Windows) or sudo dhclient -r && sudo dhclient (Linux/Mac)
2. Check whether the DHCP server is running
3. Verify the network cable or Wi-Fi connection
4. Restart the router/DHCP server if needed

Problem 2: IP Address Conflict

Cause: Two devices have been assigned the same IP — either because a static IP was set manually within the DHCP pool, or because the pool is misconfigured.

Fix:

• Set static IPs outside the DHCP pool range (for example, if the pool is 192.168.1.100–200, assign static IPs in the 192.168.1.2–99 range)
• Use DHCP reservations instead of manual static IPs

Problem 3: DHCP Pool Exhaustion

Cause: All available IP addresses in the pool are currently leased, so new devices cannot obtain an address.

Fix:

• Increase the pool size if the subnet allows
• Shorten lease times to reclaim addresses faster from disconnected devices
• Move to a larger subnet (e.g., /24 instead of /26)
• Add a second DHCP server for failover and load sharing

Problem 4: DHCP Server Failure

Cause: The server running DHCP has gone offline. Clients with existing leases keep their addresses until expiry; new devices cannot connect.

Fix:

• Deploy a secondary DHCP server configured for failover — it shares lease data with the primary and takes over automatically
• On Windows Server, use the built-in DHCP Failover feature
• On Linux, use Kea DHCP with high-availability configuration

Problem 5: Rogue DHCP Server

Cause: An unauthorized device (e.g., a misconfigured router brought in by a user) starts responding to DHCP requests with incorrect or malicious configuration.

Fix:

• Enable DHCP snooping on managed switches — it blocks DHCP responses from untrusted ports
• Monitor your network for unauthorized DHCP servers using tools like Wireshark or SolarWinds IPAM

DHCP Security Risks and How to Mitigate Them

DHCP was designed for convenience, not security. As a result, several attack vectors target it:

DHCP Starvation Attack

An attacker floods the DHCP server with fake requests using spoofed MAC addresses, exhausting the IP address pool. Legitimate devices then cannot obtain addresses.

Mitigation: Enable DHCP snooping and rate-limiting on switches to cap the number of DHCP requests allowed per port.

Rogue DHCP Server Attack

An attacker sets up an unauthorized DHCP server that assigns their gateway IP to victims, redirecting all traffic through the attacker (a man-in-the-middle attack).

Mitigation: DHCP snooping designates only specific switch ports as trusted DHCP sources, blocking all others from sending DHCP offers.

DHCP Lease Spoofing

An attacker sends forged DHCPRELEASE messages to force legitimate clients off the network by releasing their leases.

Mitigation: Use Dynamic ARP Inspection (DAI) alongside DHCP snooping to validate ARP packets against the DHCP binding table.

DHCPv6: How IP Assignment Works on IPv6 Networks

IPv6 networks support DHCP through DHCPv6, but IPv6 also introduces a new alternative: SLAAC (Stateless Address Autoconfiguration).

DHCPv6

DHCPv6 works similarly to DHCPv4 but uses a different four-step process: Solicit → Advertise → Request → Reply. It runs over UDP ports 546 (client) and 547 (server). Administrators use DHCPv6 when they need centralized control over IPv6 address assignment and want to distribute DNS servers and other options.

SLAAC (Stateless Address Autoconfiguration)

SLAAC lets IPv6 devices generate their own address using the network prefix advertised by the router combined with the device’s MAC address or a randomly generated interface ID. No DHCP server is needed at all. However, SLAAC alone cannot distribute DNS server information — for that, DHCPv6 or Router Advertisement extensions (RFC 8106) are required.

Which to Use?

Most modern IPv6 deployments use a combination: SLAAC for address assignment and stateless DHCPv6 for distributing DNS servers. Environments requiring precise address tracking and assignment use stateful DHCPv6, which mirrors DHCPv4 behavior.

FAQ