DHCP Configuration

DORA: How DHCP Actually Works

DORA is the core workflow behind DHCP. If you understand DORA, you can troubleshoot “DHCP isn’t working” with a real mental model instead of guessing.

After this page, you should be able to:

  • Describe each DORA step and what it accomplishes
  • Map common DHCP failures to the specific step that is failing
  • Verify the DHCP client state using Windows commands and basic packet capture

Big Picture: What Happens When a Device Joins a Network

When a device boots or connects to a network, it usually does not have an IP address yet. Without an IP address and basic network settings, it can’t reliably communicate beyond “shouting” on the local network.

DHCP clients typically start with 0.0.0.0 as their source IP and use broadcasts (like 255.255.255.255) because they don’t know where the DHCP server is yet.

The important concept here is the broadcast domain: a boundary where broadcast traffic is heard by all devices on the same local network segment (usually a VLAN). Broadcasts generally do not cross routers. That one fact explains a huge percentage of DHCP issues.

D = Discover

The client begins by broadcasting a DHCPDISCOVER message: “Is there a DHCP server on this network that can configure me?”

High-level addressing (typical):

  • Source: 0.0.0.0:68 (client, UDP 68)
  • Destination: 255.255.255.255:67 (server, UDP 67)

It must be broadcast because the client doesn’t know the DHCP server’s IP address yet. The server identifies the requester using the client’s MAC address and/or a client identifier.

O = Offer

A DHCP server responds with a DHCPOFFER: “Here’s a configuration I’m willing to lease to you.”

An offer commonly includes:

  • Proposed IP address
  • Lease time
  • Subnet mask
  • Default gateway
  • DNS servers (and sometimes DNS suffix/search domain)
  • Other options (NTP, domain name, PXE settings, etc.)

Multiple DHCP servers can respond with offers. That’s normal in networks with redundancy. The client will choose one.

Real-world note: rogue DHCP

If an unauthorized (“rogue”) DHCP server sends offers, clients may accept bad configuration (wrong gateway, wrong DNS) and the network will look broken. This is a common incident pattern in offices and labs.

R = Request

The client chooses an offer and broadcasts a DHCPREQUEST: “I want to use this offered configuration.”

This is often broadcast so that other DHCP servers also hear itand can withdraw their offers. The request includes the selected server’s identity (commonly the Server Identifier option), which makes the choice explicit.

This “I choose you” step helps prevent IP conflicts by ensuring only one server commits the lease for that client, and other servers stop offering the same address.

A = Acknowledge

The selected DHCP server replies with DHCPACK, confirming the lease. At this point the client has permission to use the IP address and options provided.

DHCPNAK (brief but important)

A DHCPNAK means the server refuses the requested lease. Common causes:

  • Client is on the wrong subnet/VLAN for that scope
  • Client has a stale lease that no longer matches the scope
  • Address is no longer valid/available

After a DHCPACK, the client configures the interface and typically performs an ARP check (or gratuitous ARP behavior depending on OS) to detect conflicts. Once configured, the network becomes usable—assuming the options are correct.

Visual Mental Model (Text Diagram)

Client (no IP yet)                                  DHCP Server
0.0.0.0:68                                          UDP 67
     |                                                   |
     |  D: DHCPDISCOVER  (broadcast to 255.255.255.255)  |
     |-------------------------------------------------->|
     |                                                   |
     |  O: DHCPOFFER     (offer proposed IP + options)   |
     |<--------------------------------------------------|
     |                                                   |
     |  R: DHCPREQUEST   (broadcast: "I choose you")    |
     |-------------------------------------------------->|
     |                                                   |
     |  A: DHCPACK       (lease confirmed)               |
     |<--------------------------------------------------|
     |                                                   |
     |  Client configures IP/mask/gateway/DNS            |
     v                                                   v

The Ports & Addresses You Actually Need to Know

  • UDP 67: DHCP server listens here
  • UDP 68: DHCP client listens here
  • Broadcast vs unicast: early messages often use broadcasts because the client has no IP and doesn’t know the server yet
  • Why switches/routers matter: broadcasts stay inside a broadcast domain (usually a VLAN). If the DHCP server is not in that VLAN, you need a DHCP relay / helper on the router/L3 boundary.

Why DORA Breaks (Most Common Failure Points)

Client can’t broadcast to server (different VLAN/subnet, no relay)

What you observe: Discover packets, no Offer.

What it usually means: Broadcasts aren’t reaching a DHCP server; relay missing/misconfigured.

No DHCP server reachable / server down

What you observe: No Offer, no Ack, clients fall back to APIPA (169.254.x.x) or “limited connectivity.”

What it usually means: Server service down, network path broken, or wrong VLAN.

Scope exhausted

What you observe: DHCP server reachable but no offers (or repeated NAKs/declines).

What it usually means: No free addresses left; lease duration too long; old leases not being reclaimed.

DHCP server not authorized (Windows/AD environments)

What you observe: Server appears “configured” but clients never receive offers.

What it usually means: In AD-backed setups, DHCP may refuse to serve until authorized.

Wrong VLAN / wrong subnet mask / wrong gateway option

What you observe: Client gets an IP, but can’t reach anything meaningful (no internet, can’t reach servers).

What it usually means: DORA succeeded, but the options are wrong; the network looks broken.

Firewall blocking UDP 67/68

What you observe: Partial DORA (Discover but no Offer) or Offer/Request but no Ack.

What it usually means: A security rule is blocking DHCP on the client, server, or intermediate device.

Rogue DHCP server handing out bad options

What you observe: Clients get IPs, but DNS/gateway settings are wrong; intermittent weirdness.

What it usually means: Another DHCP server is responding; clients sometimes choose it.

Client stuck with old lease

What you observe: Client has an IP that “used to work” but now can’t communicate; renew fails or NAKs.

What it usually means: Lease doesn’t match the current network; client needs release/renew or network reset.

Hands-on: Verify DORA on a Client (Commands only)

Check current configuration:

ipconfig /all

What matters: IPv4 address, subnet mask, default gateway, DNS servers, and whether DHCP is enabled.

Force a new lease:

ipconfig /release
ipconfig /renew

If renew hangs or fails, you can usually map it to a missing Offer/Ack.

Optional (PowerShell):

Get-NetIPConfiguration

Useful for quickly seeing interface details (IP, gateway, DNS) in one view.

Where to look for DHCP client logs (Windows)

Event Viewer → Applications and Services Logs → Microsoft → Windows → DHCP-Client → Operational

Hands-on: Capture DORA in Wireshark (Optional but valuable)

Packet capture turns “I think DHCP is broken” into “I know which step is failing.” This is optional, but it’s one of the fastest ways to build troubleshooting confidence.

Wireshark display filter:

dhcp or bootp
  • If you see Discover but no Offer, focus on VLAN/relay/server reachability.
  • If you see Offer but no Ack, focus on firewalls or server-side policy.
  • If you see the full sequence but networking still fails, focus on the options (gateway/DNS/mask).

Key Takeaways

  • DORA is broadcast-driven initially because the client starts with no usable IP context.
  • The client starts with 0.0.0.0 and uses broadcasts to find a DHCP server.
  • Request is the “I choose you” message so other servers back off.
  • DHCP options are as important as the IP (mask/gateway/DNS can make the network look broken).
  • Most DHCP issues map to a specific DORA step—find the step, then troubleshoot that layer.