Dhcp - Learning Module | OneNoughtOne

Loading content...

0/228

DHCP Messages

The Language of Dynamic Configuration

Every DHCP interaction—from initial address discovery to lease renewal to graceful shutdown—is conducted through a well-defined set of messages. These messages share a common structure inherited from BOOTP but extended with a flexible options mechanism that enables DHCP to deliver any configuration parameter imaginable.

Understanding DHCP messages at the packet level transforms debugging from guesswork to science. When a device fails to obtain an address, you can capture traffic and trace exactly where the process failed. When a server behaves unexpectedly, you can examine the options it's sending. When clients receive wrong configurations, you can identify the source.

This page dissects the DHCP message format, catalogs all message types and their specific purposes, and explores the options mechanism that makes DHCP extensible enough to serve modern enterprise networks.

What You Will Learn

By the end of this page, you will understand the complete DHCP packet structure, all eight message types and when each is used, and the options mechanism that enables DHCP to deliver configuration parameters beyond basic addressing. You'll be equipped to analyze DHCP packets with Wireshark or similar tools.

DHCP Packet Structure

DHCP messages are encapsulated in UDP datagrams, which in turn are encapsulated in IP packets. The DHCP message itself follows the BOOTP format with extensions for the options field.

Transport Layer:

Protocol: UDP (connectionless, no reliability guarantees)
Server Port: 67 (bootps)
Client Port: 68 (bootpc)
Why UDP?: Efficiency, broadcast support, stateless operation

The DHCP Message Format:

DHCP Message Fixed Fields
Field	Size	Description
op (opcode)	1 byte	1 = BOOTREQUEST (client to server), 2 = BOOTREPLY (server to client)
htype (hardware type)	1 byte	Hardware address type (1 = Ethernet)
hlen (hardware length)	1 byte	Length of hardware address (6 for Ethernet MAC)
hops	1 byte	Relay agent hop count; set to 0 by client
xid (transaction ID)	4 bytes	Random value correlating requests and responses
secs	2 bytes	Seconds elapsed since client began acquisition
flags	2 bytes	Broadcast flag (0x8000) if client requires broadcast response
ciaddr (client IP)	4 bytes	Client's current IP (only if client already has one)
yiaddr (your IP)	4 bytes	IP address assigned to client (server fills this)
siaddr (server IP)	4 bytes	IP of next server (TFTP boot server) or responding server
giaddr (gateway IP)	4 bytes	Relay agent IP (filled by relay, not client)
chaddr (client hardware)	16 bytes	Client's MAC address (padded to 16 bytes)
sname (server name)	64 bytes	Optional server hostname (or used for options overflow)
file (boot filename)	128 bytes	Boot file path (or used for options overflow)
options	Variable	DHCP options (begins with magic cookie 0x63825363)

Understanding Key Fields:

xid (Transaction ID): The xid is a random 32-bit value generated by the client for each new DORA transaction. All messages in the same exchange share this xid. Servers must copy the xid from the request into their response. This allows clients to:

Match responses to requests (especially important with multiple servers)
Ignore late responses from previous transactions
Correlate captured packets during troubleshooting

ciaddr (Client IP Address): This field's meaning depends on context:

DISCOVER: Always 0.0.0.0 (client has no address)
REQUEST (SELECTING): 0.0.0.0 (accepting offer, not yet configured)
REQUEST (RENEWING/REBINDING): Client's current address
RELEASE: Client's address being released

giaddr (Gateway IP Address): Filled by DHCP relay agents, not clients. When a relay forwards a broadcast to a remote server, it places its own IP in giaddr. The server uses this to:

Determine which scope to allocate from
Direct the response back through the relay

dhcp_packet_layout.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
DHCP Packet Memory Layout (RFC 2131)
=====================================
 
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  op (1 byte)  |  htype (1)    |  hlen (1)     |  hops (1)     |  Bytes 0-3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       xid (4 bytes)                           |  Bytes 4-7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        secs (2 bytes)         |        flags (2 bytes)        |  Bytes 8-11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       ciaddr (4 bytes)                        |  Bytes 12-15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       yiaddr (4 bytes)                        |  Bytes 16-19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       siaddr (4 bytes)                        |  Bytes 20-23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       giaddr (4 bytes)                        |  Bytes 24-27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       chaddr (16 bytes)                       |  Bytes 28-43
|           (client MAC padded with zeros)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       sname (64 bytes)                        |  Bytes 44-107
|           (optional server hostname)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       file (128 bytes)                        |  Bytes 108-235
|           (boot filename or options overflow)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Magic Cookie (4 bytes): 0x63 0x82 0x53 0x63 (99.130.83.99)   |  Bytes 236-239
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       options (variable)                      |  Bytes 240+
|           (TLV format, ends with option 255)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Minimum DHCP message size: 300 bytes (per RFC 2131)
Typical message size: 300-576 bytes
Maximum message size: 576 bytes default, can negotiate higher

DHCP Message Types

DHCP defines eight message types, each serving a specific purpose in the protocol's operation. The message type is specified in Option 53 within the options field. Understanding when each message type is used is essential for troubleshooting.

The Eight DHCP Message Types:

DHCP Message Types (RFC 2131)
Type	Value	Direction	Purpose
DHCPDISCOVER	1	Client → Server	Client broadcasts to locate DHCP servers
DHCPOFFER	2	Server → Client	Server offers an IP address and configuration
DHCPREQUEST	3	Client → Server	Client requests offered address or renews lease
DHCPDECLINE	4	Client → Server	Client rejects address (detected conflict)
DHCPACK	5	Server → Client	Server confirms address assignment
DHCPNAK	6	Server → Client	Server denies request (invalid or changed)
DHCPRELEASE	7	Client → Server	Client voluntarily releases address
DHCPINFORM	8	Client → Server	Client requests configuration only (already has IP)

DHCPDISCOVER (Type 1):

The first message in the DORA process, broadcast by a client seeking an IP address.

Client Behavior:

Broadcast to 255.255.255.255 (MAC FF:FF:FF:FF:FF:FF)
Source IP: 0.0.0.0 (no address yet)
xid: Random 32-bit value
chaddr: Client's MAC address
May include Option 50 (Requested IP) if client has a preferred address
Option 55 (Parameter Request List) specifies desired configuration options

Timing:

Initial timeout: typically 1-4 seconds
Retransmit with exponential backoff (2, 4, 8, 16... seconds)
Random jitter added to prevent broadcast storms

DHCPOFFER (Type 2):

Server's response to DISCOVER, proposing an address.

Server Behavior:

yiaddr: Proposed IP address
Server reserves (but doesn't commit) this address
Includes lease time, subnet mask, gateway, DNS, etc.
Option 54 (Server Identifier) identifies the offering server
Can be unicast or broadcast depending on client's capability

Multiple Servers: If multiple servers are configured, each responds independently. Client collects offers and selects one.

DHCP Options Framework

DHCP's power comes from its extensible options mechanism. Options use a Type-Length-Value (TLV) format that allows the protocol to deliver virtually any configuration parameter while remaining backward compatible.

Options TLV Format:

+------+--------+----------------------+
| Type | Length | Value                |
| 1 byte| 1 byte | Length bytes          |
+------+--------+----------------------+

Special Options:

Option 0 (Pad): 1 byte, used for alignment
Option 255 (End): 1 byte, terminates options field

Magic Cookie: The options field must begin with the magic cookie: 99.130.83.99 (0x63825363). This distinguishes DHCP packets from BOOTP packets and validates the options field.

Options Categories:

Essential DHCP Options by Category
Option	Name	Description
IP Layer
1	Subnet Mask	Network mask (e.g., 255.255.255.0)
3	Router	Default gateway list (one or more IPs)
28	Broadcast Address	Subnet broadcast address
121	Classless Static Routes	Static routes in CIDR format
DNS/Naming
6	Domain Name Servers	DNS server list
15	Domain Name	DNS domain suffix
44	NetBIOS Name Servers	WINS server list (legacy)
Time Services
2	Time Offset	Offset from UTC in seconds
42	NTP Servers	Network Time Protocol servers
DHCP Specific
50	Requested IP Address	Client's preferred address
51	IP Address Lease Time	Lease duration in seconds
53	DHCP Message Type	Message type (1-8)
54	Server Identifier	DHCP server IP address
55	Parameter Request List	Options client is requesting
58	Renewal (T1) Time	Seconds until renewal
59	Rebinding (T2) Time	Seconds until rebinding
61	Client Identifier	Alternative client ID (not MAC)

Option 55: Parameter Request List

Option 55 is crucial for efficient DHCP operation. The client sends a list of option codes it wants (e.g., 1, 3, 6, 15 for mask, gateway, DNS, domain). The server includes only requested options in its response, reducing message size. Well-configured clients request only what they need.

Vendor-Specific and Extended Options

DHCP's options framework accommodates vendor-specific extensions and specialized use cases through dedicated option ranges and encapsulation mechanisms.

Vendor Class and Vendor-Specific Options:

Vendor Extension Mechanisms

•Option 60 (Vendor Class Identifier) — Client identifies itself by vendor/type (e.g., 'MSFT 5.0' for Windows, 'android-dhcp-12' for Android). Server uses this to apply vendor-specific policies.
•Option 43 (Vendor-Specific Information) — Binary data interpreted based on Option 60. Contains encapsulated sub-options specific to the vendor.
•Option 124 (V-I Vendor Class) — Enterprise-specific vendor class for more granular identification.
•Option 125 (V-I Vendor-Specific Information) — Vendor-specific data keyed by enterprise number.

PXE Boot Options:

Preboot Execution Environment (PXE) uses DHCP to provide boot information:

Option 66 (TFTP Server Name): Hostname of TFTP server for boot file
Option 67 (Bootfile Name): Path to network boot file
Option 93 (Client System Architecture): CPU architecture (x86, x64, ARM, EFI)
Option 94 (Client Network Interface Identifier): Network interface version

VoIP Phone Options:

IP phones often require specific configuration:

Option 150 (TFTP Server Address): Cisco-specific TFTP for phone configs
Option 66/67: Standard TFTP options for boot/config files
Option 43: Encapsulated options for specific vendors (Avaya, Polycom, etc.)

Modern Extensions:

Modern DHCP Option Extensions
Option	Name	Use Case
82	Relay Agent Information	Switch port identification for location/policy
119	Domain Search List	DNS search path (replaces Option 15)
121	Classless Static Routes	CIDR routes (replaces Option 33)
150	TFTP Server Address (Cisco)	IP phones and network devices
252	WPAD (Web Proxy Auto-Discovery)	Proxy configuration URL

Option 82: Relay Agent Information

Option 82 is inserted by switches/relay agents to identify the specific port and VLAN where the client is connected. This enables location-based addressing, security policies, and troubleshooting. Sub-options include Circuit ID (port) and Remote ID (switch identifier).

Message Size and Fragmentation

DHCP message size has implications for network compatibility and options capacity. Understanding size constraints is important for deploying complex configurations.

Historical Size Constraints:

Original BOOTP specified a minimum message size of 300 bytes. DHCP maintained this minimum for compatibility but also established limits:

Minimum: 300 bytes (required for all implementations)
Default Maximum: 576 bytes (minimum IP datagram size all hosts must accept)
Negotiated Maximum: Up to 64KB (via Option 57)

Options Field Capacity:

With the fixed fields consuming 236 bytes (including magic cookie), the default options capacity is:

Default (576 byte packet): 340 bytes for options
With sname/file overload: up to 532 bytes for options
Negotiated large packet: potentially kilobytes of options

Options Overload (Option 52):

When options exceed the options field capacity, DHCP can overload the sname (64 bytes) and file (128 bytes) fields:

Value 1: file field contains options
Value 2: sname field contains options
Value 3: Both fields contain options

This provides up to 192 additional bytes for options without requiring large packets.

Maximum Message Size Option (Option 57):

Clients can advertise their capability to receive larger messages:

Option 57: Maximum DHCP Message Size
  Length: 2 bytes
  Value: Maximum bytes client can accept (e.g., 1500)

Servers should respect this option but cannot exceed the network's MTU. For reliability across diverse paths, staying at or below 1500 bytes is recommended.

Fragmentation Risks

DHCP messages exceeding 576 bytes risk IP fragmentation, which can cause delivery issues: fragments may be blocked by firewalls, arrive out of order, or be lost. For critical deployments, keep messages under 576 bytes or verify path MTU. Complex configurations with many options should be tested thoroughly.

Broadcast and Unicast Behavior

DHCP uses a mix of broadcast and unicast communication depending on the message type and client state. Understanding this behavior is essential for network design and troubleshooting.

Why Broadcast?

DHCP must work before the client has any IP configuration. Broadcast (at Layer 2 and Layer 3) enables:

Client to reach servers without knowing their addresses
Servers to reach clients without IP configuration
Multiple servers to receive and respond to requests

The BROADCAST Flag:

The flags field (offset 10-11) contains a BROADCAST flag (bit 15):

Flag set (0x8000): Client requires broadcast responses
Flag clear (0x0000): Client can receive unicast before configuration

Why might a client need broadcast responses?

Some network stacks cannot receive unicast until IP is configured
Older IP implementations had this limitation
Modern systems typically don't set this flag

DHCP Message Transport Methods
Message	From	To	Transport
DISCOVER	Client (0.0.0.0)	Broadcast	Always broadcast
OFFER	Server	Client	Unicast to MAC, or broadcast if flag set
REQUEST (SELECTING)	Client	All servers	Always broadcast
REQUEST (RENEWING)	Client	Leasing server	Unicast
REQUEST (REBINDING)	Client	Any server	Broadcast
ACK/NAK	Server	Client	Unicast to MAC, or broadcast if flag set
RELEASE	Client	Server	Unicast
DECLINE	Client	Server	Unicast
INFORM	Client	Server	Unicast (client has IP)

Layer 2 Unicast Before IP Configuration:

How can a server unicast to a client that doesn't have an IP address configured?

The answer lies in Layer 2: the server unicasts the Ethernet frame directly to the client's MAC address (from the chaddr field). The IP layer uses:

Source: Server's IP address
Destination: The yiaddr (proposed client IP) or 255.255.255.255

The client's network stack receives the frame because it matches the MAC address, even without IP configuration. This is why the BROADCAST flag exists—not all implementations handle this correctly.

Relay Agent Considerations:

When DHCP messages traverse relay agents:

giaddr is set to the relay's IP on the client's subnet
Server sends response to relay's IP (unicast)
Relay forwards to client (usually as broadcast on local subnet)

Debugging Tip: Check giaddr

When analyzing DHCP traffic, the giaddr field reveals the message's path. If giaddr is 0.0.0.0, the client and server are on the same subnet. If giaddr is non-zero, a relay agent forwarded the message, and giaddr identifies which subnet the client is on.

Analyzing DHCP with Wireshark

Practical DHCP troubleshooting requires the ability to capture and analyze DHCP traffic. Wireshark (and similar tools) decode DHCP packets completely, revealing all fields and options.

Capture Filter for DHCP:

port 67 or port 68

Display Filter for DHCP:

dhcp                    -- All DHCP packets
dhcp.type == 1          -- DISCOVER only
dhcp.type == 5          -- ACK only
dhcp.option.dhcp == 3   -- REQUEST messages
bootp.ip.your == 192.168.1.100  -- Specific yiaddr

Key Fields to Examine:

Wireshark DHCP Analysis Checklist

•Transaction ID (xid) — Follow a complete DORA exchange by matching xid across packets
•Message Type (Option 53) — Identify the message type immediately
•Client MAC (chaddr) — Identify which device is communicating
•Your IP (yiaddr) — The offered/assigned address
•Server Identifier (Option 54) — Which server is responding
•Requested IP (Option 50) — What address the client prefers
•Lease Time (Option 51) — Lease duration in seconds
•Router (Option 3) — Default gateway assigned
•DNS Servers (Option 6) — Name servers assigned
•Gateway IP (giaddr) — Relay agent identification

Common Troubleshooting Scenarios:

No OFFER received:

Check if DISCOVER is being transmitted (client side)
Verify DISCOVER reaches server (server/relay capture)
Confirm server has available addresses in pool
Check for firewall blocking UDP 67/68

Wrong configuration received:

Examine OFFER and ACK for incorrect options
Verify server scope configuration
Check for rogue DHCP server (different Server Identifier)
Validate relay agent Option 82 if used for policy

Lease renewal failures:

Capture at renewal time (T1)
Verify unicast REQUEST reaches server
Check server still has the lease record
Confirm server responds with ACK (not NAK)

Slow DHCP performance:

Check for excessive retransmissions (secs field increasing)
Look for multiple DISCOVER before first OFFER (timeout issues)
Verify network path between client and server/relay

wireshark_dhcp_flow.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Example DORA Exchange in Wireshark Summary View
================================================
 
No. Time       Source          Dest            Protocol  Info
1   0.000000   0.0.0.0         255.255.255.255 DHCP     DISCOVER - Transaction ID 0xabcd1234
2   0.002341   192.168.1.1     192.168.1.100   DHCP     OFFER    - Transaction ID 0xabcd1234
3   0.003012   0.0.0.0         255.255.255.255 DHCP     REQUEST  - Transaction ID 0xabcd1234
4   0.004521   192.168.1.1     192.168.1.100   DHCP     ACK      - Transaction ID 0xabcd1234
 
Key Observations:
- All messages share xid 0xabcd1234 (same transaction)
- DISCOVER and REQUEST are broadcast (dst: 255.255.255.255)
- OFFER and ACK are unicast to assigned IP (192.168.1.100)
- Complete DORA in ~4.5ms (healthy network)
 
Timing Issues Example:
1   0.000000   0.0.0.0         255.255.255.255 DHCP     DISCOVER
2   4.002000   0.0.0.0         255.255.255.255 DHCP     DISCOVER (retransmit)
3   12.003000  0.0.0.0         255.255.255.255 DHCP     DISCOVER (retransmit)
4   12.015000  192.168.1.1     192.168.1.100   DHCP     OFFER
 
Problem: Server response delayed; client retransmitted twice
Root cause: Check server load, network path, relay configuration

Summary: DHCP Messages Mastered

We've comprehensively examined DHCP message structure, types, and the options framework. Let's consolidate the key takeaways:

Key Takeaways

•DHCP inherits BOOTP's packet format — Fixed fields (op, htype, hlen, hops, xid, etc.) plus variable options field enable compatibility and extensibility.
•Eight message types serve distinct purposes — DISCOVER/OFFER/REQUEST/ACK for normal operation; DECLINE/RELEASE/NAK for exceptions; INFORM for configuration-only requests.
•Options use TLV encoding — Type-Length-Value format allows adding new parameters without protocol changes. Magic cookie validates options presence.
•Option 53 identifies message type — Critical for parsing; every DHCP message must include this option.
•Vendor-specific options enable extensibility — Options 43, 60, 124, 125 accommodate device-specific configurations for phones, network devices, and custom applications.
•Message size affects delivery — Stay under 576 bytes for universal compatibility; use Option 57 to negotiate larger messages when needed.
•Broadcast vs unicast follows specific rules — DISCOVER and REQUEST (SELECTING/REBINDING) always broadcast; renewals and releases use unicast for efficiency.

What's Next:

With DHCP message structure understood, the next page explores lease management—how leases are stored, renewed, expired, and reclaimed. Proper lease management is essential for maintaining healthy address pools and preventing exhaustion.

Page Complete

You now possess the knowledge to analyze DHCP traffic at the packet level, identify message types and their purposes, and understand the options framework that makes DHCP extensible. This enables effective troubleshooting and informed DHCP infrastructure design.