DHCP Explained

The main purpose of this post is to find
How devices automatically get their IP address — from discovery to release.
Let's start from here:
1. What Is DHCP?
Every device that connects to a network — whether it's your laptop, phone, printer, or smart TV — needs an IP address to communicate. Without one, it is invisible to the rest of the network. The question is: how does every device get that address without someone manually typing it in?

The answer is DHCP — Dynamic Host Configuration Protocol. DHCP is a network management protocol that automatically assigns IP addresses and other network configuration settings to client devices the moment they connect to a network. It is what makes "plug in and it just works" possible.

Before DHCP existed, network administrators had to manually configure every single device with an IP address, subnet mask, gateway, and DNS server. On a network with hundreds of devices, this was an enormous and error-prone task. DHCP eliminated that entirely.

What DHCP Configures
DHCP does more than just hand out IP addresses. A full DHCP lease delivers a complete network configuration package to the client:

-->DHCP uses a client-server model. The DHCP server owns a pool of available IP addresses (called a scope) and leases them out to clients on a temporary basis. The IP is not permanently owned — it is borrowed for a defined lease time.

Where DHCP Is Used
•Home routers — your home router runs a DHCP server that hands out IPs to every device on your Wi-Fi
•Enterprise networks — dedicated DHCP servers manage hundreds or thousands of devices per site
•ISP networks — DHCP assigns IPs to customer routers when they connect to the ISP
•Data centers and cloud — DHCP or its cloud equivalents provision virtual machine networking automatically
•Wi-Fi hotspots — coffee shops, airports, and hotels use DHCP to assign temporary IPs to guests

2. The DORA Process — How IP Addresses Are Allocated
When a client device boots up and needs an IP address, it goes through a four-message exchange with the DHCP server. Networking engineers call this the DORA process — an acronym for the four messages involved: Discover, Offer, Request, and Acknowledge.

Understanding why each message is a broadcast or a unicast — and why — is essential to deeply understanding DHCP.

Step 1 — DHCP Discover
When a client device first boots up or connects to a network, it has no IP address, no knowledge of the default gateway, and no idea where a DHCP server is. It is essentially blind to the network. The only thing it can do is shout — and that is exactly what it does.

The client broadcasts a DHCP Discover message to every device on the local subnet, hoping a DHCP server will hear it and respond.

Source MAC: Client's own hardware MAC address
Destination MAC: FF:FF:FF:FF:FF:FF (Ethernet broadcast — everyone receives it)
Source IP: 0.0.0.0 (client has no IP yet)
Destination IP: 255.255.255.255 (IP broadcast)

The use of 0.0.0.0 as the source IP is significant — it is the standard notation for "I have no IP address." The message essentially says: "I just joined this network. My hardware address is [MAC]. Is there a DHCP server out there?"

So Why Broadcast? The client does not know the IP address of the DHCP server — it may not even know if a DHCP server exists. A broadcast is the only way to reach every device on the subnet simultaneously. All devices receive the frame, but only DHCP servers process and respond to it.

Step 2 — DHCP Offer
Any DHCP server on the subnet that receives the Discover message responds with a DHCP Offer. This message is the server saying: "I heard you. I am available. Here is an IP address I am reserving for you, along with all the configuration you need."

The Offer contains a full proposed network configuration:
•The IP address being offered to the client
•Subnet mask
•Default gateway IP address
•DNS server IP address
•Lease duration (how long the client may keep this IP)
•The DHCP server's own IP address (so the client knows who made the offer)

Source MAC: DHCP Server MAC
Destination MAC: FF:FF:FF:FF:FF:FF (broadcast — client still has no IP)
Source IP: 192.168.1.254 (DHCP server's IP)
Destination IP: 255.255.255.255 (broadcast — client can't receive unicast yet)

At this point the server internally reserves the offered IP address, temporarily removing it from its available pool. This prevents the same IP from being offered to another client while this negotiation is in progress.

--> What If There Are Multiple DHCP Servers?
In some networks, more than one DHCP server may exist for redundancy. All of them receive the Discover broadcast and may each send a separate Offer. The client receives multiple Offers and simply picks one — usually the first to arrive. The selection is handled in the next step.

Step 3 — DHCP Request
After receiving one or more Offer messages, the client selects a DHCP server and formally requests the offered configuration. It broadcasts a DHCP Request message to the entire subnet.

This message serves two purposes simultaneously:

1. It tells the chosen DHCP server: "I accept your offer. Please confirm this configuration for me."
2. It tells all other DHCP servers (the ones whose offers were not selected): "I chose a different server. You can release the IP address you had reserved for me."

Source MAC: Client's MAC address
Destination MAC: FF:FF:FF:FF:FF:FF (broadcast — informing ALL servers)
Source IP: 0.0.0.0 (still no IP until Ack is received)
Destination IP: 255.255.255.255 (broadcast)

Key field: DHCP Server Identifier (Option 54) = IP of chosen server

The DHCP Server Identifier field (Option 54) is what tells every server which one was selected. The chosen server reads this field, sees its own IP, and knows it should proceed. Every other server reads the field, sees a different IP, and releases its reserved address back to its pool.

Why Is the Request Still a Broadcast?
Even though the client now knows the chosen server's IP, it must still broadcast — because non-selected servers also need to receive this message so they can free up their reserved IPs. A unicast to only the chosen server would leave the other servers holding reserved addresses indefinitely.

Step 4 — DHCP Acknowledge (ACK)
The selected DHCP server receives the Request message, confirms that the DHCP Server Identifier matches its own IP, and responds with a DHCP Acknowledge (ACK) message. This is the server's final confirmation: "The IP is yours. Your lease starts now."

The ACK contains the same configuration data as the Offer — IP address, subnet mask, gateway, DNS, and lease time — but now it is official. Upon receiving the ACK, the client configures its network interface using this data and becomes a fully functional member of the network.

Source MAC: DHCP Server MAC
Destination MAC: FF:FF:FF:FF:FF:FF (broadcast — client still has no confirmed IP)
Source IP: 192.168.1.254 (DHCP server)
Destination IP: 255.255.255.255 (broadcast)

After the client processes the ACK, it performs one final check — an ARP (Address Resolution Protocol) probe — to make sure no other device on the network is already using the assigned IP. If a conflict is detected, the client sends a DHCP Decline message and the process starts over.

What Is a DHCP NAK?
If the DHCP server receives a Request but something is wrong — the requested IP is no longer available, or the client's lease has already expired — it sends a DHCP NAK (Negative Acknowledge) instead of an ACK. The client must then restart the DORA process from the beginning.

3. IP Address Renewal — Keeping Your Lease
Why Leases Expire
DHCP does not permanently assign IP addresses — it leases them. This is by design. Temporary leases allow the DHCP server to reclaim IP addresses from devices that have left the network without formally releasing them, keeping the address pool healthy and preventing exhaustion.

Imagine a hotel with 100 rooms. If guests could check in forever and never check out, the hotel would eventually have no rooms to offer new guests. DHCP lease times work the same way — they ensure addresses cycle back into the pool.

The Renewal Timeline
The DHCP lease renewal process follows a predictable timer schedule that every network engineer should know:

For example, with a 24-hour (86,400 second) lease: T1 fires at 12 hours, T2 at ~21 hours. If the client successfully renews at T1, the full lease duration resets and the cycle starts again.

The Renewal Exchange
When T1 fires, the client sends a DHCP Request directly to its DHCP server to renew the lease. This is one of the key differences from the initial allocation — renewal uses unicast, not broadcast.

Client ──── DHCP Request (Unicast) ──────────→ Server
Destination IP: 192.168.1.254 (server's IP — now known)
Client IP: 192.168.1.105 (the IP being renewed)

Client ←─── DHCP Ack (Unicast) ───────────── Server
Destination IP: 192.168.1.105 (client's IP — now known)

Because both the client and server already know each other's IP addresses from the original lease, there is no need for broadcasts. The renewal is a clean, direct two-message exchange: Request and Ack. The client includes its current IP in the "Client IP Address (ciaddr)" field, and notably does NOT include Option 50 (Requested IP) or Option 54 (Server Identifier) — these are only used in initial allocation.

Broadcast vs. Unicast Comparison: Initial allocation uses broadcast because the client has no IP and does not know the server's address. Renewal uses unicast because both sides now know each other. This is an important distinction for exam questions and troubleshooting.

What Happens If Renewal Fails?
If T1 fires and the DHCP server does not respond (perhaps it is down for maintenance), the client does not immediately panic. It keeps using the current IP and waits until T2.

At T2 (87.5% of lease), the client escalates — it broadcasts a DHCP Request to any DHCP server on the network, hoping a backup or secondary server can renew the lease. If that also fails and the lease fully expires, the client stops using the IP entirely and falls back to the full DORA process.

During this fallback window, Windows devices will often assign themselves an APIPA address (169.254.x.x) — a self-assigned link-local address that allows basic local communication but provides no internet access. Seeing a 169.254.x.x address is a reliable indicator that DHCP has failed.

4. IP Address Release — Returning the Lease
What Is a DHCP Release?
When a device gracefully disconnects from the network — whether you shut down your computer cleanly, disconnect from Wi-Fi, or run the ipconfig /release command on Windows — it should inform the DHCP server that it no longer needs its IP address. It does this by sending a DHCP Release message.

The Release is a unicast message sent directly to the DHCP server:

Client ──── DHCP Release (Unicast) ─────────→ Server
Destination MAC: DHCP Server MAC
Destination IP: 192.168.1.254 (DHCP server)
Client IP field: 192.168.1.105 (the IP being returned)

Upon receiving the Release, the DHCP server marks that IP address as available again in its pool, ready to be offered to the next client that needs it. The releasing client immediately loses network access — it no longer has a valid IP, gateway, or DNS server.

Graceful vs. Abrupt Disconnection
DHCP Release only happens during a graceful shutdown. If a device loses power suddenly, crashes, or is simply removed from the network without warning, it cannot send a Release message. In this case:

•The DHCP server keeps the IP listed as leased until the lease timer expires
•No other device can be assigned that IP during this time
•Once the lease expires, the server reclaims the IP and returns it to the pool

This is why DHCP lease times matter. A very long lease time (say, 7 days) means an IP can be "stuck" for a week after a device disappears. A shorter lease time means faster reclamation, but more frequent renewal traffic on the network.

-->ipconfig /release and /renew On Windows, you can manually trigger these processes. 'ipconfig /release' sends a DHCP Release and removes the IP configuration. 'ipconfig /renew' then starts a new DORA process to get a fresh IP. This is a common first step when troubleshooting "no internet" issues on Windows.

5. Broadcast vs. Unicast — The Full Picture
One of the most important concepts in DHCP is understanding why each message is either a broadcast or unicast. Here is the complete summary:

6. DHCP Relay — What About Multiple Subnets?
There is an important limitation to standard DHCP: the Discover and Offer messages are broadcasts, and routers do not forward broadcasts between subnets by default. This means a single DHCP server on one subnet cannot normally serve clients on other subnets.

In a real enterprise network with dozens of subnets, you cannot deploy a DHCP server on every single subnet — that would be an administrative nightmare. The solution is a DHCP Relay Agent.

How DHCP Relay Works
A DHCP Relay Agent (also called an IP Helper) is software running on a router or Layer 3 switch that intercepts local DHCP broadcasts and forwards them as unicast messages to a centralized DHCP server on a different subnet. The server replies to the relay agent, which then forwards the response back to the client.

Client (VLAN 10)
|
| broadcasts DHCP Discover
↓
Router (Relay Agent) DHCP Server (VLAN 1)
| ──── unicast DHCP Discover ──────→ |
| ←─── unicast DHCP Offer ──────────-|
|
| broadcasts DHCP Offer back to client
↓
Client receives Offer and continues DORA normally

On Cisco routers, the DHCP relay is configured with the 'ip helper-address' command on the client-facing interface, pointing to the DHCP server's IP. This is one of the most commonly configured features in enterprise networking.

-->Real-World Implication: When troubleshooting DHCP failures in enterprise environments, always check the relay agent configuration first. A misconfigured or missing 'ip helper-address' is one of the most common reasons clients on a subnet cannot get an IP address despite a healthy DHCP server.

7. DHCP Security Risks
Because DHCP operates on trust — clients accept configuration from whoever responds first — it is vulnerable to several attack types that every network engineer should understand.

DHCP Snooping is a Layer 2 security feature available on managed switches. It designates specific ports as "trusted" (connected to the real DHCP server) and "untrusted" (connected to clients). DHCP Offer and Ack messages from untrusted ports are dropped, preventing rogue servers from poisoning client configurations.

8. Complete DHCP Flow — From Boot to Internet
Putting it all together, here is the full sequence from a device powering on to it having internet access:

3.Device boots up — no IP address, no network configuration
4.Client broadcasts DHCP Discover — looking for any DHCP server on the subnet
5.DHCP server receives Discover — reserves an IP from its pool, sends a Broadcast Offer
6.Client receives Offer — selects the server, broadcasts a DHCP Request
7.All DHCP servers receive the Request — unchosen servers release their reserved IPs; chosen server sends ACK
8.Client receives Ack — performs ARP conflict check, then configures the network interface
9.Client is now online — uses the IP address, subnet mask, gateway, and DNS from the lease
10.At 50% of lease time — client unicasts a Renewal Request to extend the lease
11.Server responds with Renewal Ack — lease timer resets, process repeats at T1 again
12.When done — client sends DHCP Release (unicast) and loses network access

Key Takeaways
•DHCP automates network configuration — IP address, subnet mask, gateway, DNS, and lease time are all delivered automatically
•The four-step DORA process (Discover → Offer → Request → Ack) is the foundation of every IP allocation
•Initial allocation uses broadcast throughout because the client has no IP and doesn't yet know the server's address
•Renewal uses unicast because both sides already know each other's addresses from the original lease
•Lease times are intentional — they let the server reclaim IPs from devices that leave without releasing them
•T1 (50%) triggers renewal; T2 (87.5%) is the fallback if T1 fails; expiry resets the whole process
•DHCP Release is optional but courteous — abrupt disconnections leave addresses tied up until the lease expires
•DHCP Relay Agents (ip helper-address) allow a single DHCP server to serve clients across multiple subnets
•DHCP Snooping on managed switches prevents rogue DHCP servers from hijacking client configurations
•A 169.254.x.x address on a client almost always means DHCP failed — the client fell back to APIPA self-assignment
==>Remember the DORA acronym: Discover → Offer → Request → Acknowledge. Every DHCP allocation follows this exact sequence, every time, on every network in the world.