Understanding DHCPv4: A Complete Guide

Every device on a network needs a unique IP address to communicate. Static addressing — manually typing an IP into a router, server, or printer — works fine for devices that never move and never change. It falls apart fast for laptops, phones, and anything else that joins and leaves the network constantly. That’s the problem the Dynamic Host Configuration Protocol solves, and DHCPv4 is the version of it running under almost every IPv4 network you’ve ever connected to.

This guide covers how DHCPv4 assigns addresses, the four-message exchange that makes it work, how to configure a Cisco router as a DHCPv4 server, and the verification and troubleshooting commands that matter for both real networks and CCNA exam scenarios.

What Is DHCPv4?

DHCPv4 lets a centralized server hand out IPv4 addresses automatically instead of an administrator configuring each device by hand. Beyond the address itself, DHCPv4 can push out a full set of network parameters in the same exchange: subnet mask, default gateway, DNS server addresses, and domain name.

A dedicated DHCP server is the normal choice for larger networks, but it isn’t required. Cisco IOS includes a feature called Easy IP, which turns a router into a fully functional DHCPv4 server — a common setup in small offices and branch locations that don’t justify a dedicated server.

DHCP comes in two versions: DHCPv4 for IPv4 networks and DHCPv6 for IPv6 networks. They share a name and a general purpose, but the message types, addressing, and configuration are different enough that they’re treated as separate protocols in practice. This guide focuses on DHCPv4.

DHCPv4 Address Allocation Mechanisms

DHCPv4 supports three ways of handing out addresses:

• Manual allocation. The administrator pre-assigns a specific IP address to a specific device (usually identified by MAC address), and the DHCP server always hands that device the same address. Functionally similar to a static assignment, but still managed centrally through the DHCP server rather than configured on the device itself.
• Automatic allocation. The server assigns an address from a pool permanently — once a device gets an address this way, it keeps it indefinitely, with no lease expiration to renew.
• Dynamic allocation. The server assigns an address from a pool for a limited time — a lease. When the lease expires, the address returns to the pool for reuse, and the client has to request an address again (though it’s often reassigned the same one if it’s still available).

Dynamic allocation is by far the most common in practice. Administrators set the lease time based on how the network actually behaves — a coffee shop guest network might use a lease of a few hours, while an office LAN with mostly stationary desktops might use a week or more.

DHCPv4 Operation: The Four-Message Exchange

When a client boots up or joins a network, it has no valid IPv4 address yet, so it can’t address a request directly to a server. Instead, it runs through a four-step broadcast-based exchange commonly abbreviated DORA: Discover, Offer, Request, Acknowledge.

1. DHCP Discover (DHCPDISCOVER)

The client has no IP information at all, so it can’t send a unicast message to anything. It broadcasts a DHCPDISCOVER message using Layer 2 (FF:FF:FF:FF:FF:FF) and Layer 3 (255.255.255.255) broadcast addresses, essentially asking “is there a DHCPv4 server out there?” Every device on the local segment receives it, but only DHCPv4 servers respond.

2. DHCP Offer (DHCPOFFER)

A DHCPv4 server that receives the DHCPDISCOVER reserves an available address for that client and builds an ARP entry pairing the client’s MAC address with the offered IPv4 address. The server then replies with a unicast DHCPOFFER, sourced from the server’s own MAC address and addressed to the client’s MAC address — the client doesn’t have an IP yet, so this exchange happens at Layer 2.

If multiple DHCP servers exist on the network, more than one might respond with an offer. The client picks one — typically whichever offer arrives first.

3. DHCP Request (DHCPREQUEST)

The client broadcasts a DHCPREQUEST accepting the chosen offer. Broadcasting it (rather than unicasting it to the chosen server) does two things at once: it tells the selected server the client wants that address, and it implicitly tells any other servers that made an offer that their offer wasn’t accepted, so they can release the address they’d reserved back into their own pool.

The DHCPREQUEST message is reused later for lease renewal, with a different destination (see below).

4. DHCP Acknowledgment (DHCPACK)

When the server receives the DHCPREQUEST, it verifies the address isn’t already in use — typically with an ICMP ping to that address — before finalizing anything. If nothing responds, the server creates a proper ARP entry for the client’s lease and replies with a unicast DHCPACK. This message is essentially a repeat of the DHCPOFFER, with only the message type field changed.

When the client receives the DHCPACK, it records the configuration and performs its own ARP lookup for the assigned address as a final duplicate-check. If nothing answers that ARP request either, the client considers the address valid and starts using it.

Worked Example: Reading a DORA Exchange in a Packet Capture

Theory is easier to apply once you’ve seen what the four messages actually look like on the wire. Here’s a simplified capture of a client obtaining an address from 192.168.1.1, with the fields that matter most called out.

1. DHCPDISCOVER

Src: 0.0.0.0:68   Dst: 255.255.255.255:67
Src MAC: 00:1A:2B:3C:4D:5E   Dst MAC: FF:FF:FF:FF:FF:FF
DHCP Message Type: Discover

Notice the source address is 0.0.0.0 — the client genuinely has nothing yet, which is exactly why both the IP and MAC destinations are broadcast.

2. DHCPOFFER

Src: 192.168.1.1:67   Dst: 255.255.255.255:67 (or unicast, implementation-dependent)
Src MAC: (router)   Dst MAC: 00:1A:2B:3C:4D:5E
DHCP Message Type: Offer
Your (client) IP Address: 192.168.1.50
Lease Time: 604800 seconds (7 days)

The server has already reserved 192.168.1.50 for this specific MAC address at this point, even though the client hasn’t accepted anything yet.

3. DHCPREQUEST

Src: 0.0.0.0:68   Dst: 255.255.255.255:67
Requested IP Address: 192.168.1.50

Still broadcast, still from 0.0.0.0 — the client hasn’t started using the offered address yet, only requested it. This is the detail that trips people up: the client doesn’t switch to using its new address until after the DHCPACK confirms it.

4. DHCPACK

Src: 192.168.1.1:67   Dst: 255.255.255.255:67 (or unicast)
Your (client) IP Address: 192.168.1.50
Subnet Mask: 255.255.255.0
Router: 192.168.1.1
DNS Server: 8.8.8.8
Lease Time: 604800 seconds

Only after this message does the client actually configure 192.168.1.50 on its interface. If you’re troubleshooting a client that never seems to get an address, filtering a capture for UDP ports 67/68 and checking how far through this sequence it gets will usually show you exactly where it’s failing.

Configuring a Cisco Router as a DHCPv4 Server

This is the “Easy IP” setup mentioned earlier — no dedicated DHCP server required.

Router> enable
Router# configure terminal
Router(config)# ip dhcp excluded-address 192.168.1.1 192.168.1.10
Router(config)# ip dhcp pool LAN-POOL
Router(dhcp-config)# network 192.168.1.0 255.255.255.0
Router(dhcp-config)# default-router 192.168.1.1
Router(dhcp-config)# dns-server 8.8.8.8 8.8.4.4
Router(dhcp-config)# lease 7
Router(dhcp-config)# exit

• ip dhcp excluded-address must be configured before the pool, and reserves addresses the server should never hand out — typically the router’s own interface address and anything else assigned statically. Skip this step and the router will happily offer its own gateway address to a client.
• network defines the pool of addresses the server can lease from, using the subnet and mask.
• default-router sets the gateway address handed to clients.
• dns-server sets one or more DNS servers to hand out.
• lease sets the lease duration in days (optionally hours and minutes). If omitted, the Cisco IOS default lease is 1 day.

DHCP Relay for Multi-Subnet Networks

DHCP broadcasts don’t cross router boundaries by default, which is a problem when the DHCP server lives on a different subnet than the clients. The fix is a relay agent, configured on the client-side interface:

Router(config)# interface gigabitEthernet 0/1
Router(config-if)# ip helper-address 192.168.100.10

This forwards DHCP broadcasts (and several other UDP services) from that interface to the specified server as a unicast, letting one central DHCP server support multiple subnets without a local server on each one.

Verifying the DHCPv4 Server

Router# show ip dhcp binding
Router# show ip dhcp pool LAN-POOL
Router# show ip dhcp conflict
Router# debug ip dhcp server events

• show ip dhcp binding lists active leases: client MAC address, assigned IP, and lease expiration.
• show ip dhcp pool shows pool utilization — total addresses, leased addresses, and pending offers.
• show ip dhcp conflict shows addresses the server detected as already in use (via the ICMP ping or ARP check described above) and therefore won’t offer.
• debug ip dhcp server events shows the DORA exchange happening in real time — useful for confirming whether a client’s requests are even reaching the router.

Lease Renewal

DHCP addresses aren’t leased forever. Before a lease expires, the client tries to renew it directly with the same server that issued it in the first place:

1. The client sends a unicast DHCPREQUEST straight to the DHCPv4 server that originally offered the address.
2. The server checks the lease is still valid and replies with a DHCPACK, extending the lease.

If the original server doesn’t respond within a set time, the client falls back to a broadcast DHCPREQUEST, asking any available DHCPv4 server to renew or reassign an address — this is the same broadcast/unicast fallback pattern used during the initial DORA exchange, just applied to renewal instead of first-time assignment.

Troubleshooting DHCPv4

Symptom	Likely Cause	Fix
Client gets a 169.254.x.x address (APIPA)	No DHCPDISCOVER response reached a server	Check the client is on the right VLAN/subnet, and confirm ip helper-address is configured if the server is remote
Client gets an address from the wrong pool	Multiple DHCP servers or pools overlapping on the same subnet	Check show ip dhcp pool on all servers and confirm exclusions don’t overlap with active leases
Router keeps offering its own IP or a statically assigned server’s IP	Missing or incomplete ip dhcp excluded-address	Add the exclusion before the pool, covering the router interface and any static hosts
DHCP broadcasts never reach a remote server	No relay agent configured, and DHCP server is on a different subnet	Add ip helper-address on the client-facing interface pointing to the server
show ip dhcp binding shows no active leases despite client complaints	DORA exchange isn’t completing	Run debug ip dhcp server events to see where the exchange stalls

FAQs

What is DHCPv4 and how does it work?

DHCPv4 automatically assigns IPv4 addresses and related network settings to devices. It uses a four-step exchange — Discover, Offer, Request, Acknowledge — to hand out a lease-based address without any manual configuration on the client side.

What are the different DHCPv4 address allocation methods?

Manual allocation always assigns the same pre-set address to a specific device. Automatic allocation assigns an address from a pool permanently, with no expiration. Dynamic allocation assigns an address from a pool for a limited lease period, which is by far the most common method in practice.

How does the DHCP lease renewal process work?

Before a lease expires, the client sends a unicast DHCPREQUEST directly to the server that originally issued the address. If that server doesn’t respond in time, the client falls back to a broadcast DHCPREQUEST to reach any available DHCPv4 server.

Can a Cisco router act as a DHCPv4 server?

Yes. Cisco IOS’s “Easy IP” feature lets a router provide full DHCPv4 services using ip dhcp pool, network, default-router, and dns-server commands — no dedicated DHCP server required, which is common in small offices and branch sites.

Why is DHCPv4 important for network management?

It removes the need to manually configure every device’s IP settings, keeps addressing consistent across an organization, and handles mobile or frequently changing devices — laptops, phones, guest devices — without an administrator touching each one individually.

Why does the DHCPREQUEST get broadcast instead of sent directly to the chosen server?

Because other DHCP servers may have also made offers. Broadcasting the DHCPREQUEST both confirms the accepted offer to the chosen server and implicitly tells every other server that offered an address that it wasn’t chosen, so they can release those reserved addresses back to their own pools.

What happens if the ICMP ping check during DHCPACK finds the address already in use?

The server does not complete the lease for that address — it’s marked as a conflict rather than handed out. This shows up in show ip dhcp conflict, and the server offers a different address instead.

Do DHCPv4 and DHCPv6 work the same way?

No. They share a name and a general purpose, but DHCPv6 uses a different message set, works alongside IPv6’s own stateless address autoconfiguration (SLAAC), and isn’t simply DHCPv4 translated for longer addresses. They’re configured and troubleshot separately.