DHCP and Automatic Address Configuration

Learning objective

Trace IPv4 DHCP from discovery through lease use, explain direct and relayed packet delivery, and identify the header evidence that supports each conclusion.

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.

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.

Interactive DHCP DORA journey

Choose a direct DHCP journey

Initial address allocationMultiple server offersRequested address rejectedNo server offer

Step 1 of 4: DHCPDISCOVER

UDP 68 → 67 · broadcast

Client: SELECTING · Server: LISTENING

DHCPDISCOVER advances the address-allocation exchange.

Evidence: 68 → 67; broadcast.

Ethernet

Source

02:00:00:00:00:10

Destination

ff:ff:ff:ff:ff:ff

IPv4

Source

0.0.0.0

Destination

255.255.255.255

UDP

Source port

68

Destination port

67

Delivery evidence

DHCP broadcast flag	set
IPv4 destination	255.255.255.255
Ethernet destination	ff:ff:ff:ff:ff:ff

BOOTP/DHCP

Field	Size	Value and meaning
op	8 bits	1 Purpose: Distinguishes a request from a reply. Here: This packet carries 1.
htype	8 bits	1 Purpose: Identifies the hardware address type. Here: This packet carries 1.
hlen	8 bits	6 Purpose: Gives the hardware address length. Here: This packet carries 6.
hops	8 bits	0 Purpose: Counts relay-agent forwarding hops. Here: This packet carries 0.
xid	32 bits	0x3903f326 Purpose: Correlates packets in one transaction. Here: This packet carries 0x3903f326.
secs	16 bits	0 Purpose: Reports elapsed acquisition time. Here: This packet carries 0.
flags	16 bits	32768 Purpose: Carries the DHCP broadcast-request bit. Here: The broadcast bit is set.
ciaddr	32 bits	0.0.0.0 Purpose: Carries a client address already valid for use. Here: This packet carries 0.0.0.0.
yiaddr	32 bits	0.0.0.0 Purpose: Carries the address offered or assigned to the client. Here: No client address is supplied in this field yet.
siaddr	32 bits	0.0.0.0 Purpose: Carries the next-server/bootstrap address when used. Here: This packet carries 0.0.0.0.
giaddr	32 bits	0.0.0.0 Purpose: Carries the first relay address for subnet selection. Here: No relay address is used on this leg.
chaddr	16 bytes	02:00:00:00:00:10 Purpose: Carries the client hardware-address field. Here: This packet carries 02:00:00:00:00:10.
sname	64 bytes	empty Purpose: Optionally carries a server host name. Here: This packet carries an empty value.
file	128 bytes	empty Purpose: Optionally carries a boot-file name. Here: This packet carries an empty value.
magic cookie	4 bytes	63:82:53:63 Purpose: Marks the following data as DHCP options. Here: This packet carries 63:82:53:63.

DHCP options

Code	Option	Length	Value	Meaning
53	DHCP Message Type	1	DISCOVER	The client is looking for DHCP servers.
61	Client Identifier	7	02:00:00:00:00:10	Keeps the client identity stable.
55	Parameter Request List	6	1,3,6,51,58,59	Requests mask, router, DNS, and lease timers.

PreviousPlayNextRestartPlayback speed 0.5×1×1.5×2×

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.

Interactive DHCP relay and helper-address journey

Choose a DHCP relay journey

Remote server through a relayMissing helper addressNo matching remote scopeUDP 67 blocked upstream

Client broadcast domain → Server subnet

Step 1 of 8: Client broadcasts Discover

UDP 68 → 67 · broadcast

Client: SELECTING · Server: PROCESSING

Client broadcasts Discover crosses the active DHCP path.

Evidence: 68 → 67; giaddr 0.0.0.0.

Ethernet

Source

02:00:00:00:00:10

Destination

ff:ff:ff:ff:ff:ff

IPv4

Source

0.0.0.0

Destination

255.255.255.255

UDP

Source port

68

Destination port

67

Delivery evidence

DHCP broadcast flag	set
IPv4 destination	255.255.255.255
Ethernet destination	ff:ff:ff:ff:ff:ff

BOOTP/DHCP

Field	Size	Value and meaning
op	8 bits	1 Purpose: Distinguishes a request from a reply. Here: This packet carries 1.
htype	8 bits	1 Purpose: Identifies the hardware address type. Here: This packet carries 1.
hlen	8 bits	6 Purpose: Gives the hardware address length. Here: This packet carries 6.
hops	8 bits	0 Purpose: Counts relay-agent forwarding hops. Here: This packet carries 0.
xid	32 bits	0x6d5a2b11 Purpose: Correlates packets in one transaction. Here: This packet carries 0x6d5a2b11.
secs	16 bits	0 Purpose: Reports elapsed acquisition time. Here: This packet carries 0.
flags	16 bits	32768 Purpose: Carries the DHCP broadcast-request bit. Here: The broadcast bit is set.
ciaddr	32 bits	0.0.0.0 Purpose: Carries a client address already valid for use. Here: This packet carries 0.0.0.0.
yiaddr	32 bits	0.0.0.0 Purpose: Carries the address offered or assigned to the client. Here: No client address is supplied in this field yet.
siaddr	32 bits	0.0.0.0 Purpose: Carries the next-server/bootstrap address when used. Here: This packet carries 0.0.0.0.
giaddr	32 bits	0.0.0.0 Purpose: Carries the first relay address for subnet selection. Here: No relay address is used on this leg.
chaddr	16 bytes	02:00:00:00:00:10 Purpose: Carries the client hardware-address field. Here: This packet carries 02:00:00:00:00:10.
sname	64 bytes	empty Purpose: Optionally carries a server host name. Here: This packet carries an empty value.
file	128 bytes	empty Purpose: Optionally carries a boot-file name. Here: This packet carries an empty value.
magic cookie	4 bytes	63:82:53:63 Purpose: Marks the following data as DHCP options. Here: This packet carries 63:82:53:63.

DHCP options

Code	Option	Length	Value	Meaning
53	DHCP Message Type	1	DISCOVER	Identifies this message as DISCOVER.
55	Parameter Request List	6	1,3,6,51,58,59	Requests core configuration.

PreviousPlayNextRestartPlayback speed 0.5×1×1.5×2×

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.