DHCP (Dynamic Host Configuration Protocol)

What it is (Definition)

DHCP is the protocol that automatically assigns IP configuration to hosts: an IP address, subnet mask (or prefix), default gateway, DNS servers, and other options. Without DHCP, every host would require manual configuration or a custom provisioning workflow. DHCP is one of the first protocols you troubleshoot when “a device can’t get online” on a managed network.

DHCP is designed for environments where clients may have no IP address yet. For that reason, early DHCP messages often use broadcast delivery and special addressing behavior until the client is configured. The protocol needs to work even when the client only knows its own MAC address and nothing else about the network.

In operational terms, DHCP defines “who owns which address, and for how long.” Misconfiguration here can lead to duplicates, wrong default gateways, or DNS problems that all surface as “internet is down” from the user’s point of view, even though L2/L3 connectivity might be fine.

Where it sits in the stack (Layer & usage)

L7 over UDP DHCP is an application-layer protocol carried over UDP.

• Transport: UDP; clients and servers use well-known ports (commonly 68 for clients, 67 for servers).
• Where used: Enterprise and home networks, Wi-Fi onboarding, VM networks, and IoT provisioning.
• Infrastructure: DHCP servers, relay agents (IP helpers), and security features like DHCP snooping.

DHCP behavior can differ between networks with direct server reachability and networks that require a relay agent across routed segments. In captures, the presence of a relay is often visible and explains why broadcasts appear to “cross” subnet boundaries even though routers normally stop L2 broadcasts.

Because DHCP runs early in the client’s lifecycle, failures here cascade: if DHCP does not complete, DNS, routing, and application protocols never get a chance to run. That is why many access-layer troubleshooting runbooks start with “check whether the client got a valid lease.”

Header overview (Fields at a glance)

DHCP messages are based on the BOOTP format, with fixed header fields plus a flexible options section. In practice, troubleshooting often revolves around message type (Discover/Offer/Request/Ack) and key options like requested IP, lease time, router, and DNS servers.

How it works (Typical flow)

The classic DHCP “DORA” sequence:

1. Discover: Client broadcasts asking for configuration.
2. Offer: Server offers an IP address and options.
3. Request: Client requests the offered address (or renews an existing lease).
4. Ack: Server acknowledges and the client configures the interface.

• Renewal: Clients typically renew before lease expiry; renewals may be unicast if the client already has an address.
• Rebind: If the original server is not reachable, the client may broadcast to any server that can extend the lease.
• Relay: If the server is not on the local subnet, a relay forwards DHCP messages and adds relay information (giaddr and options).

Operationally, it helps to think of DHCP in two phases: initial acquisition (full DORA, often broadcast-heavy) and steady-state lease maintenance (renewals and rebinding, often unicast). Problems in either phase can cause users to lose connectivity, but they show up differently in packet captures.

How it looks in Wireshark

Display filter example:

dhcp || bootp

What you typically see:

• Message type option showing Discover/Offer/Request/Ack for each packet.
• Transaction ID (xid) used to follow a single client’s DORA sequence.
• Assigned IP (yiaddr) and key options such as router, DNS servers, domain, and lease time.
• Relay information when an intermediate device is forwarding requests between segments.

Quick read tip: If a client never gets online, first confirm whether you see a full DORA. “Discover only” suggests L2 reachability, VLAN, or server/relay issues; “Offer but no Ack” suggests policy or conflict checks blocking later messages.

Common issues & troubleshooting hints

1) Client sends Discover but receives no Offer

Symptom

The device stays in “Obtaining IP address…” or self-assigns a fallback address (for example, an APIPA range). Users may connect to Wi-Fi but report “no internet” immediately.

Likely cause

DHCP server unreachable, relay misconfigured, VLAN mismatch, or filtering along the path. The Discover frames might be stuck on the access switch, in the wrong VRF, or blocked by DHCP snooping or ACLs.

How to confirm

Capture at the client and at an upstream point if possible. Verify that Discover leaves the client’s VLAN and check whether any Offer returns on the same segment. If relays are used, confirm that relayed packets actually reach the server and that replies are sent back to the correct relay address.

2) Offer received, but client never completes Request/Ack

Symptom

Offers appear in captures, but the lease is not established. The client may keep sending Discover or appear to “bounce” between different offers. From the user’s view, connectivity is intermittent or never stabilizes.

Likely cause

Client policy (for example, it requires specific options), address conflicts detected by the client, or security controls dropping Request/Ack messages. In multi-server environments, overlapping scopes or misaligned options can also cause unexpected behavior.

How to confirm

Follow the transaction ID for a single client. Check whether a Request is sent after the Offer and whether an Ack returns. Compare options in the Offer against what the client expects (for instance, required router/DNS options) and look for signs of duplicate address detection or ARP probing by the client.

3) Wrong gateway/DNS causing “internet is down” perception

Symptom

Clients successfully obtain an IP address but cannot reach the internet or resolve names. Pings to local devices may work, while external sites fail or name resolution times out.

Likely cause

Incorrect router or DNS options in the DHCP scope, stale configuration carried over from a previous design, or split network policy where some clients are intentionally isolated but not labeled clearly for operators.

How to confirm

Inspect the DHCP Ack in a capture and note the router and DNS options delivered to the client. Compare with known-good clients in the same environment. Then capture DNS attempts and default gateway probes (ARP, ICMP) to see whether they are targeting the correct devices and whether those devices respond.

Security notes (if relevant)

DHCP is a frequent target for rogue servers and spoofing. Networks often deploy DHCP snooping to ensure only trusted ports can send server messages, and to build a binding table used by other protections (like Dynamic ARP Inspection and IP source guard). For captures, unexpected Offers from non-authoritative devices are a strong indicator of a rogue DHCP server or misconfigured lab gear plugged into production.

On unprotected networks, a malicious DHCP server can hand out wrong default gateways or DNS servers and silently divert traffic. When analyzing suspicious connectivity, always confirm which device actually provided the lease, and whether its MAC address and switch port match your intended infrastructure design.

Related pages (internal links)

• Back to Dictionary Index
• Key fields (DHCP message type option, lease/router/DNS options — Soon)
• Related topics (DHCP DORA walkthrough, Rogue DHCP detection — Soon)