What DHCP is
DHCP automates the delivery of IP addresses and other network parameters. In IPv4, RFC 2131 defines the core protocol and its lease-based client/server model.
The practical value is consistency. Instead of configuring every endpoint manually, an administrator can centrally define address pools, subnet masks, default gateways, DNS servers, domain information, and many additional options. This reduces typing errors and makes changes easier to roll out.
Addresses are normally leased for a period rather than assigned forever. That allows a pool to be reused efficiently in environments with mobile clients, temporary devices, or more endpoints than addresses that need to be active at the same time.
DORA
The common IPv4 startup flow is summarized as DORA: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK. The client begins without full network configuration, so broadcasts are important during the early stages.
A client sends DHCPDISCOVER to find available servers. One or more servers may reply with DHCPOFFER. The client selects an offer and sends DHCPREQUEST, and the chosen server confirms the lease with DHCPACK. DORA is a useful mnemonic, but DHCP includes additional messages for renewals, negative acknowledgments, releases, and other state transitions.
A packet capture is one of the fastest ways to diagnose DHCP. If Discover leaves the client but no Offer returns, the investigation is very different from a case where Offer arrives and the client never completes Request/Ack.
UDP ports
DHCPv4 uses UDP ports 67 and 68: servers listen on 67 and clients use 68. The protocol must work before the client has a normal unicast identity, which explains the use of broadcasts and special address fields.
Firewalls or ACLs between a relay and server must permit the required traffic. Remember that the endpoint broadcast itself does not traverse routers; the relay converts the local request into traffic that can reach the remote server.
When diagnosing, verify both directions. A request reaching the server is not enough if the response cannot return to the relay or client segment.
Leases
A lease gives a client permission to use an address for a defined period. Clients attempt to renew before expiry so they can usually keep the same address without repeating the full discovery process.
Lease duration is a design choice. Very short leases increase DHCP traffic and can create unnecessary churn; very long leases keep addresses reserved for clients that may have disappeared. Guest Wi-Fi, office desktops, labs, and infrastructure networks often justify different policies.
When a client cannot renew, it may try rebinding with any available server before the lease finally expires. Understanding this lifecycle helps explain why a DHCP outage can take time to affect already-configured hosts.
Scopes and options
A DHCP scope or pool represents the parameters for a subnet. At minimum it usually defines an address range and subnet information, but deployments commonly include default gateway, DNS servers, domain search information, NTP, PXE/boot options, and vendor-specific values.
The scope must match the client subnet identified by the local interface or relay information. A valid address from the wrong prefix is still a broken configuration. Exclusions are also important so statically assigned infrastructure addresses are not leased accidentally.
When troubleshooting “DHCP works but the network does not,” inspect the options. A wrong gateway or DNS server can make a successful lease appear to be a connectivity failure.
Reservations
A reservation maps a known client identifier or MAC-related identity to a predictable address while still using DHCP. It is useful when a device should remain centrally managed but applications, monitoring, or access policies expect a stable address.
Reservations are not a substitute for DNS or proper inventory. They should be documented, and the reserved address must not also be available for dynamic allocation.
For critical infrastructure, decide whether a reservation or static configuration better matches the operational requirement. The correct choice depends on what should happen if the DHCP service is unavailable.
DHCP relay
DHCP discovery starts as a local broadcast, and routers normally do not forward broadcasts between subnets. A DHCP relay receives the client request on the local VLAN and forwards it to a server elsewhere.
The relay includes information that lets the server identify the originating network and select the right scope. In enterprise designs, this allows a small number of centralized servers to serve many VLANs.
Relay troubleshooting should verify the client VLAN, relay address or helper configuration, reachability from relay to server, server scope, return path, and any policy that filters UDP 67/68. If several VLANs work and one does not, compare the working and failing relay contexts.
Exhaustion and conflicts
A pool can run out of usable addresses. Symptoms include new clients failing while existing leases continue to work. Monitor pool utilization and investigate stale leases, unexpectedly short lease times, or growth in endpoint count.
Address conflicts occur when the same IPv4 address is used by more than one host. Common causes include static addresses inside the dynamic pool, duplicate manual configuration, or badly coordinated DHCP servers.
Do not “fix” exhaustion by blindly widening a scope across another subnet boundary. Address planning, VLAN design, and DHCP scopes must agree.
169.254.0.0/16 and APIPA
When an IPv4 host cannot obtain normal configuration, some operating systems may self-assign a link-local address from 169.254.0.0/16. On Windows this is commonly associated with APIPA.
Seeing a 169.254.x.x address is a clue, not the root cause. It tells you the client does not currently have expected DHCP configuration and has selected a local-link fallback. Investigate the DHCP exchange rather than trying to route the link-local address across the network.
Two hosts on the same link may communicate using link-local addressing, but that does not replace a functioning enterprise address plan.
DHCPv6
IPv6 changes the configuration model. Hosts may use SLAAC, DHCPv6, or a combination depending on Router Advertisements and policy. DHCPv6 does not simply replace every function of IPv4 DHCP.
In particular, the default router is learned through IPv6 Neighbor Discovery and Router Advertisements, not delivered as an ordinary DHCPv6 default-gateway option. Stateful DHCPv6 can assign addresses, while stateless DHCPv6 can deliver additional information.
Troubleshooting IPv6 configuration therefore requires checking RA behavior as well as DHCPv6. Treat the two protocols as cooperating parts of the host configuration process.
Troubleshooting
Start on the client: confirm link, VLAN, current address, lease state, and whether a Discover/Solicit is actually sent. Then follow the request to the relay and server.
Check scope availability, exclusions, reservations, lease exhaustion, server logs, relay configuration, and bidirectional reachability. A packet capture on the client VLAN and another near the server can quickly show where the exchange disappears.
Finally validate the delivered options. A completed DORA sequence with an incorrect gateway or DNS server is still an operational failure.
References
RFC 2131 defines DHCP for IPv4, while RFC 2132 documents DHCP options. DHCPv6 is specified by RFC 8415. IPv4 link-local addressing is covered by RFC 3927.
Vendor documentation remains important for relay syntax, high-availability behavior, database replication, and platform-specific option handling.
How to continue
Continue with DNS to understand the service that often arrives as a DHCP option. Revisit IP addressing and routing if scope boundaries or relay paths are not yet intuitive.
When you can read a DHCP packet exchange, practice distinguishing a client-side problem, a relay problem, a server/pool problem, and a bad-option problem.
Operational example
A new office VLAN has working switching and its gateway responds, but endpoints receive 169.254.x.x addresses. A capture shows repeated DHCPDISCOVER with no DHCPOFFER. The DHCP server serves other VLANs correctly.
That evidence points toward the path between the new VLAN and DHCP infrastructure. Comparing configuration reveals that the Layer 3 interface for the new VLAN is missing the relay target. After adding it, Discover reaches the server, an address is selected from the correct scope, and the full DORA exchange completes.
The lesson is to prove each stage instead of restarting the server or changing the pool blindly. DHCP is easy to diagnose when the message sequence and network path are both visible.