DHCP and Automatic Address Configuration

Why automatic configuration exists

An IPv4 host needs an address, prefix, gateway, and usually DNS information before it can communicate usefully. DHCP supplies those values as a time-limited lease, reducing manual errors while keeping assignment under network control.

Packet Format

This is the layout inside a DHCP message. Read from top to bottom: the fixed fields identify the transaction and carry address information; the options at the end supply the configuration details.

The address rows are separate fields, not four addresses every packet must use. For example, yiaddr is the address offered to the client, while giaddr identifies a relay when one forwards the request.

DHCP roles: client, server, scope, lease, and relay

The client requests configuration. The server selects values from a scope, a pool and policy for one subnet. A lease grants temporary use. A router or layer-3 switch acting as a relay (often configured with a helper address) carries client requests between broadcast domains; it does not replace the DHCP server.

UDP ports 67 and 68

On a direct client/server exchange, client requests use UDP 68 to UDP 67 and server replies use UDP 67 to UDP 68. Between a relay and server, both routed directions use UDP 67 to UDP 67. These port pairs identify roles; the IP and Ethernet destinations show whether the current leg is broadcast or unicast.

Broadcast and unicast rules

A client without an address normally broadcasts DHCPDISCOVER. Its DHCPREQUEST during initial selection also broadcasts so every offering server learns which offer was selected. DHCPOFFER and DHCPACK delivery depend on client state, the broadcast flag, and reachability. A relay receives the local broadcast, then sends a routed unicast to the server with giaddr populated; “DHCP is always broadcast” is therefore incorrect.

DHCP packet structure

The fixed BOOTP/DHCP header contains op, htype, hlen, hops, xid, secs, flags, ciaddr, yiaddr, siaddr, giaddr, chaddr, sname, file, and the magic cookie. DHCP options follow it. xid correlates one transaction; the high broadcast bit in flags requests broadcast delivery; yiaddr carries a proposed or assigned client address during initial allocation; giaddr lets a server select the remote client subnet. Options identify the message type, server, requested address, lease timers, mask, router, DNS servers, and other policy.

Interactive DHCP DORA journey

Trace Discover, Offer, Request, and ACK with synchronized client/server state, L2/L3 destinations, flags, addresses, transaction ID, and options. Compare multiple offers, NAK, and a no-offer failure.

Lease contents: address, prefix, gateway, DNS, and lease time

An ACK can supply the address in yiaddr, subnet mask, default router, DNS servers, lease duration, renewal time T1, and rebinding time T2. These are separate facts: receiving an address does not imply the correct prefix, gateway, or DNS. Values are server policy, not universal constants.

Lease lifecycle: allocation, T1 renewal, T2 rebinding, and expiry

After ACK the client is BOUND. At T1 it normally unicasts DHCPREQUEST to the original server while the address remains valid. If renewal fails, at T2 it enters REBINDING and broadcasts so another server may respond. A received ACK recalculates timers; a NAK invalidates the address immediately. At expiry, the client must stop using the address. DHCPDECLINE reports a detected conflict; DHCPRELEASE voluntarily returns a lease and has no required reply.

Interactive DHCP relay and helper-address journey

Follow every leg instead of treating relay as one arrow: client-to-relay UDP 68→67, relay-to-server UDP 67→67, server-to-relay UDP 67→67, and relay-to-client UDP 67→68. Inspect hops, giaddr, subnet selection, and optional Option 82 insertion/removal. The public failure shows what happens when the helper address is missing.

DHCP boundaries and DHCPv6/SLAAC

This lesson’s packet mechanics are IPv4 DHCP. IPv6 uses different DHCPv6 messages and ports, and hosts may instead or also use SLAAC from Router Advertisements. DHCPv6 can provide addresses or other configuration, including prefix delegation, but an IPv4 DORA capture should not be projected onto IPv6.

Common DHCP evidence and terminology

Useful evidence includes message type, xid, client identifier or chaddr, requested address, server identifier, yiaddr, giaddr, flags, UDP ports, lease timers, and Option 82. Silence means no reply was observed; it does not by itself distinguish server absence, pool exhaustion, policy, relay configuration, filtering, or return-path failure.

Summary

DHCP is a stateful, lease-based configuration protocol. Read it one leg at a time: identify the message, ports, delivery mode, transaction, address fields, options, and current client state. Direct DORA uses client 68/server 67; a relay adds routed server-side 67-to-67 legs and giaddr evidence.

Inspect DHCP evidence

Capture with bootp or dhcp; narrow a transaction with bootp.xid == 0x1234abcd. For each packet record message type, source/destination MAC and IPv4 addresses, UDP ports, xid, secs, broadcast flag, ciaddr, yiaddr, siaddr, giaddr, server identifier, requested address, lease timers, and relay information. Compare the capture with server lease logs and relay counters rather than trusting one screen alone.

Guided direct-DORA diagnosis

Start with the last state transition actually observed. Repeated Discover with no offer narrows the failure to server reachability, server policy, address-pool exhaustion, filtering, or the return path; it does not prove the server is down. If an Offer arrives but no Request follows, investigate client selection and competing offers. A NAK is explicit rejection, while silence remains ambiguous.

Guided relay/helper-address diagnosis

Prove all four legs. A missing helper address prevents a local broadcast from becoming routed relay traffic. A helper on the wrong interface may never receive the client broadcast. If the scope does not match giaddr, the server cannot select the intended client subnet. Verify that giaddr, relay source, hop count, and any Option 82 identity agree with the topology.

Troubleshoot DHCP methodically

1. Confirm client link/VLAN membership and the expected IPv4 scope.
2. Capture the client broadcast and confirm UDP 68 to 67.
3. For a remote server, verify helper placement, giaddr, and both UDP 67-to-67 relay legs.
4. Check pool availability, exclusions, reservations, and policy for address-pool exhaustion.
5. Test ACL, firewall, or security controls for blocked UDP 67/68 in both directions.
6. Separate a missing helper address, helper on the wrong interface, and scope does not match giaddr with interface and server evidence.
7. Treat no offer as an observation, then locate the first missing leg.

Knowledge check and summary

Interactive DHCP lease state diagram

Follow the client from INIT through DORA and BOUND, then experiment with renewal, rebinding, release, expiry, NAK, and decline. Play each scenario to see the real DHCP message travel between client and server. A timer or unanswered request is shown without inventing a packet.

Advanced RFC-level packet checks

These are guided checks: submit an answer to reveal the governing rule, packet evidence, operational consequence, and primary source immediately.

Pro deep dive

DHCP snooping establishes trusted server-facing ports, rejects rogue-server replies on untrusted ports, and can build address bindings used by related protections. Its trust boundary must match the real relay and uplink topology.

Option 82 carries Relay Agent Information such as Circuit ID and Remote ID. Trace insertion by a trusted relay, echo by the server, and removal before client delivery. Treat untrusted Option 82 input as a policy and spoofing risk.

Model reservations, exclusions, policy options, and multiple-server behavior explicitly. Multiple offers are valid, but scope ownership and reconciliation must prevent conflicting allocations. Advanced capture analysis should correlate xid, secs, flags, identifiers, requested addresses, option lengths/order, lease timers, server logs, binding state, and relay transformations.

DHCP authentication exists but depends on deployment and key management; operational defenses still commonly include DHCP snooping, port trust, rate limits, and monitoring. DHCPv4 high availability and failover are vendor-specific or implementation-specific approaches, not an Internet-standard failover protocol established by the RFC below.

In the IPv6 boundary, DHCPv6 can be stateful, stateless, or coexist with SLAAC; it also supports prefix delegation. RFC 8156 defines DHCPv6 failover, not DHCPv4 failover.

Primary references: RFC 2131, RFC 2132, RFC 3046, RFC 3118, RFC 3442, RFC 6607, and RFC 8156.