In Module 2, you captured a DORA exchange and learned that the first 236 bytes of every DHCP message are fixed-format header fields (`op`, `xid`, `yiaddr`, `chaddr`, and so on). Everything after byte 236 is the **options field** — and that is where DHCP becomes truly powerful.
The header tells the client *which* IP address it is getting. The options tell it *everything else*: subnet mask, default gateway, DNS servers, lease duration, TFTP server for firmware downloads, VLAN assignments for IP phones, and hundreds of other parameters. When a Cisco IP phone boots and finds its call manager, it is DHCP options doing the work. When a lightweight access point discovers its wireless controller, DHCP options are the reason it knows where to look. When a relay agent stamps the circuit-ID of the switch port a client connected to, that stamp lives in a DHCP option.
In this module, you will learn how options are encoded at the byte level (TLV — Type-Length-Value), how to decode every major option in Wireshark's packet detail pane, how to configure options on Cisco IOS DHCP pools, and how to build Wireshark display filters that isolate specific option problems. By the end, you will be able to look at a hex dump of an options field and read it like English.
## 3.1 — Option Encoding: The TLV Structure (RFC 2132)
Every DHCP option (with two exceptions) is encoded as a **Type-Length-Value** triplet:
```
+------+--------+-------------------------+
| Type | Length | Value |
| 1 B | 1 B | Length bytes |
+------+--------+-------------------------+
```
- **Type** (1 byte): The option number (0–255). This identifies *what* the option is.
- **Length** (1 byte): The number of bytes in the Value field. Does **not** include the Type or Length bytes themselves.
- **Value** (variable): The option data, whose format depends on the Type.
Options are concatenated back-to-back in the options field with no padding or separators between them. The options field always begins with a 4-byte **magic cookie** (`0x63825363`) that tells the parser "what follows is DHCP options, not legacy BOOTP vendor data."
### The Two Exceptions
Two options break the TLV pattern because they carry no data:
| Option | Name | Encoding | Purpose |
|--------|------|----------|---------|
| **0** | Pad | Single byte `0x00` — no Length, no Value | Alignment padding |
| **255** | End | Single byte `0xFF` — no Length, no Value | Marks end of options field |
Every valid options field terminates with Option 255. Anything after it is ignored.
### Byte-Level Example
Here is a raw hex dump of three options as they appear on the wire:
1.**`35 01 01`** → Type 53 (`0x35`), Length 1, Value 1 (Discover)
2.**`0C 09 4C696E75782D504331`** → Type 12 (`0x0C`), Length 9, Value = ASCII `Linux-PC1`
3.**`FF`** → Type 255 (End)
In Wireshark, you never need to decode this manually — the dissector does it for you. But understanding the encoding is essential for two situations: debugging options that Wireshark cannot parse (vendor-specific blobs), and building custom options in Cisco IOS using hex strings.
> **Pro tip:** In Wireshark's packet bytes pane, click on any option in the detail pane and the corresponding hex bytes will be highlighted in the hex dump. This makes correlating parsed fields to raw bytes effortless.
---
## 3.2 — Key DHCP Options Reference
The table below summarizes the options you will encounter most often in enterprise environments. We will deep-dive into each one in the sections that follow.
| Option | Name | Length | Value Format | Wireshark Filter Field |
**In Wireshark:** Expand `Option: (1) Subnet Mask` in the packet detail pane. The value is displayed in dotted decimal notation. Wireshark automatically converts the 4 raw bytes.
**Wireshark filter:**
```
dhcp.option.subnet_mask == 255.255.255.0
```
**Common misconfiguration:** A DHCP pool with the wrong subnet mask (e.g., `/16` instead of `/24`) will let clients reach some hosts but not others. If a client cannot reach its default gateway, check this option first.
---
### Option 3 — Router (Default Gateway)
**RFC:** 2132, Section 3.5
**Purpose:** Provides one or more default gateway addresses. The client uses the first address as its primary gateway.
**Encoding:**
```
Type: 0x03 Length: 0x04 (one router) or 0x08 (two routers) Value: 4 bytes per address
Example: 03 04 0A 01 01 01 → 10.1.1.1
```
Multiple gateways are encoded as consecutive 4-byte addresses. The Length field will be a multiple of 4.
**Wireshark filter:**
```
dhcp.option.router == 10.1.1.1
```
**Real-world note:** Most enterprise networks supply a single gateway per subnet. If you see multiple routers in this option, the client uses the first one and may try subsequent addresses only if the primary fails (behavior is OS-dependent).
---
### Option 6 — Domain Name Server (DNS)
**RFC:** 2132, Section 3.8
**Purpose:** Lists one or more DNS server addresses the client should use for name resolution.
**Troubleshooting scenario:** Client gets an IP address but cannot resolve hostnames. Check Option 6 — if it is missing or points to an unreachable DNS server, name resolution fails even though Layer 3 connectivity is fine. This is one of the most common "I have an IP but can't reach anything" complaints.
---
### Option 43 — Vendor-Specific Information
**RFC:** 2132, Section 8.4
**Purpose:** Carries vendor-defined data as a block of **sub-options**. The interpretation of Option 43 depends entirely on the vendor identified in Option 60 (Vendor Class ID).
This is the option that makes lightweight access points discover their wireless LAN controller, and it is one of the most misunderstood options in enterprise networking.
**Encoding:**
```
Type: 0x2B (43) Length: varies Value: one or more sub-options in TLV format
Sub-option structure (nested TLV):
+----------+--------+-------------------+
| Sub-Type | Sub-Len| Sub-Value |
| 1 B | 1 B | Sub-Len bytes |
+----------+--------+-------------------+
```
**Example — Cisco Lightweight AP Controller Discovery:**
A Cisco lightweight AP sends Option 60 with the value `Cisco AP c3802` (identifying itself). The DHCP server responds with Option 43 containing a sub-option that provides the WLC (Wireless LAN Controller) IP address:
```
Sub-option format for Cisco WLC:
Type: 0xF1 (241) Length: 0x04 Value: WLC IP address
Full Option 43 hex: 2B 06 F1 04 0A 01 01 64
│ │ │ └──────────── 10.1.1.100 (WLC IP)
│ │ └── Sub-Length: 4
│ └── Sub-Type: 241 (0xF1)
└── Option 43, Length 6
```
**In Wireshark:** Option 43 is displayed as `Option: (43) Vendor-Specific Information`. If Wireshark does not recognize the vendor, it shows the value as a raw hex string. If the Vendor Class ID (Option 60) was present in the Discover, Wireshark may attempt to decode the sub-options — but this is not always reliable. Manual decoding using the hex pane is a critical skill.
**Wireshark filter:**
```
dhcp.option.vendor_specific
```
> **Real-world impact:** If Option 43 is missing or misconfigured, lightweight APs will fail to discover their controller and will not serve clients. This is one of the most common "AP stuck in discovery" issues.
---
### Option 51 — IP Address Lease Time
**RFC:** 2132, Section 9.2
**Purpose:** Specifies how long (in seconds) the client may use the assigned IP address.
**Wireshark display:** Wireshark helpfully converts this to human-readable format: `IP Address Lease Time: (7200s) 2 hours`.
**Wireshark filter:**
```
dhcp.option.ip_address_lease_time == 7200
```
**Design note:** Short leases (minutes) are appropriate for guest Wi-Fi or hotspot networks with high device turnover. Long leases (days/weeks) suit stable wired environments. If you see a lease time of `0xFFFFFFFF` (4,294,967,295 seconds), the lease is **infinite** — the address never expires.
---
### Option 53 — DHCP Message Type
**RFC:** 2132, Section 9.6
**Purpose:** Identifies the type of DHCP message. This is the single most important option in the protocol — without it, the receiver cannot determine what the message means.
**Encoding:**
```
Type: 0x35 (53) Length: 0x01 Value: single byte
Values:
1 = DHCP Discover
2 = DHCP Offer
3 = DHCP Request
4 = DHCP Decline
5 = DHCP ACK
6 = DHCP NAK
7 = DHCP Release
8 = DHCP Inform
```
**Wireshark filter (by message type value):**
```
dhcp.option.dhcp == 1 # Discover
dhcp.option.dhcp == 5 # ACK
dhcp.option.dhcp == 6 # NAK — always investigate these
```
You used this filter extensively in Module 2. By now, it should be second nature.
---
### Option 55 — Parameter Request List
**RFC:** 2132, Section 9.8
**Purpose:** Sent by the client in Discover and Request messages. Contains a list of option codes the client wants the server to provide. This tells the server which options the client cares about.
**Encoding:**
```
Type: 0x37 (55) Length: varies Value: one byte per requested option code
**In Wireshark:** Expand `Option: (55) Parameter Request List` to see each requested option code with its name.
**Wireshark filter:**
```
# Show packets where a specific option was requested
dhcp.option.request_list_item == 150
```
**Why this matters:** If a Cisco IP phone requests Option 150 (TFTP server) in its Parameter Request List but the DHCP server does not include it in the response, the phone will not receive its call manager address and will fail to register. Checking Option 55 in the Discover is the first step in diagnosing "the server didn't send what the client needed."
> **Diagnostic technique:** Compare the client's Parameter Request List (Option 55 in the Discover) to the options actually returned in the server's Offer/ACK. Any option the client requested but the server did not include is a potential configuration gap.
---
### Option 60 — Vendor Class Identifier
**RFC:** 2132, Section 9.13
**Purpose:** Sent by the client to identify its vendor and hardware/software type. The server uses this to determine which vendor-specific options (Option 43) to return.
**Real-world use:** In many enterprise environments, the DHCP server uses Option 60 to conditionally assign options. For example, a Cisco IOS DHCP server can match on the vendor class identifier and return Option 150 only to IP phones, not to laptops. This is the foundation of device-specific DHCP provisioning.
---
### Option 82 — Relay Agent Information
**RFC:** 3046
**Purpose:** Inserted by DHCP relay agents (typically switches or routers) to provide the server with information about *where* the client is physically connected. This option is **not** set by the client — it is injected by intermediate infrastructure.
**Encoding:**
```
Type: 0x52 (82) Length: varies Value: one or more sub-options
Common sub-options:
Sub-option 1 — Circuit ID: identifies the port/VLAN the client is on
Sub-option 2 — Remote ID: identifies the relay agent device (e.g., switch MAC or hostname)
```
**Byte-level example:**
```
52 12 ← Option 82, total length 18
01 06 00 04 00 01 00 06 ← Sub-option 1 (Circuit-ID): length 6, value = port info
02 08 00 06 00 01 AC 10 0A 01 ← Sub-option 2 (Remote-ID): length 8, value = switch identifier
```
**In Wireshark:** Expand `Option: (82) Agent Information Option` to see the parsed sub-options. Wireshark decodes both Circuit-ID and Remote-ID as hex values. The actual meaning of the bytes depends on the relay agent vendor:
| Cisco IOS | VLAN + module + port number | Switch MAC address |
| Cisco Catalyst | VLAN number + port ifIndex | Switch hostname or MAC |
| Aruba | Port label or AP name | Controller IP/name |
**Wireshark filters:**
```
dhcp.option.agent_information_option
dhcp.option.agent_information_option.circuit_id
dhcp.option.agent_information_option.remote_id
```
**Why this matters:** Option 82 allows the DHCP server to make assignment decisions based on the physical location of the client — for example, assigning a specific VLAN or IP range depending on which switch port the device is connected to. This is foundational for 802.1X deployments and ISP subscriber management. We will explore this in depth in Module 4 (DHCP Relay).
---
### Option 150 — TFTP Server Address
**RFC:** Cisco proprietary (not in RFC 2132, but widely implemented)
**Purpose:** Provides the IP address of a TFTP server for IP phone firmware and configuration file downloads. This is the primary mechanism by which Cisco IP phones discover their Cisco Unified Communications Manager (CUCM).
**Encoding:**
```
Type: 0x96 (150) Length: 0x04 (one server) or 0x08 (two servers) Value: 4 bytes per address
Example: 96 04 0A 01 01 64 → 10.1.1.100
```
**In Wireshark:** Look for `Option: (150) TFTP Server Address`. The value is one or more IP addresses.
**Wireshark filter:**
```
dhcp.option.tftp_server_address == 10.1.1.100
```
**IP phone boot sequence:**
1. Phone powers on and sends a DHCP Discover with Option 60 = `"Cisco Systems, Inc. IP Phone ..."` and Option 55 requesting Option 150.
2. DHCP server replies with Option 150 pointing to the CUCM TFTP service (e.g., `10.1.1.100`).
3. Phone downloads its configuration file (e.g., `SEP<MAC>.cnf.xml`) from the TFTP server.
4. Configuration file tells the phone which Call Manager to register with.
If Option 150 is missing, the phone has no way to find its configuration and will display "Registering..." indefinitely.
> **Option 150 vs. Option 66 (TFTP Server Name):** Option 66 provides a TFTP server as a hostname (ASCII string), while Option 150 provides it as one or more IP addresses. Cisco IP phones prefer Option 150 because it avoids DNS dependency during boot. Use Option 150 for Cisco phone deployments.
---
## 3.4 — Decoding Options in Wireshark's Packet Detail Pane
When you click on a DHCP packet in Wireshark, the middle pane shows the protocol tree. Here is how to navigate to options:
```
▼ Dynamic Host Configuration Protocol (ACK)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
...
▼ Option: (53) DHCP Message Type (ACK)
Length: 1
DHCP: ACK (5)
▼ Option: (51) IP Address Lease Time
Length: 4
IP Address Lease Time: (86400s) 1 day
▼ Option: (1) Subnet Mask
Length: 4
Subnet Mask: 255.255.255.0
▼ Option: (3) Router
Length: 4
Router: 10.1.1.1
▼ Option: (6) Domain Name Server
Length: 8
Domain Name Server: 10.1.1.10
Domain Name Server: 10.1.1.11
▼ Option: (150) TFTP Server Address
Length: 4
TFTP Server Address: 10.1.1.100
▼ Option: (43) Vendor-Specific Information
Length: 6
Value: f104c0a80164
► Option: (255) End
```
### Tips for Efficient Option Inspection
1.**Click an option → hex highlights:** Selecting any option in the detail pane highlights its corresponding bytes in the hex dump below. This is invaluable for Option 43 where you need to manually parse sub-options.
2.**Right-click → Apply as Column:** Right-click any option value and select "Apply as Column" to add it as a permanent column in the packet list. This lets you see option values at a glance across all packets without expanding each one.
3.**Right-click → Apply as Filter:** Right-click an option value to instantly create a display filter for that exact value. For example, right-clicking a Subnet Mask of `255.255.255.0` generates `dhcp.option.subnet_mask == 255.255.255.0`.
4.**Packet Bytes pane math:** For Option 43 sub-options, count bytes in the hex pane: start at the first byte after the Option 43 length byte, read Sub-Type (1 byte), Sub-Length (1 byte), then Sub-Length bytes of Sub-Value. Repeat until you have consumed the entire Option 43 value.
---
## 3.5 — Wireshark Display Filters for DHCP Options
### Filtering by Option Presence
These filters match packets that *contain* a specific option, regardless of value:
| 241 (0xF1) | 4×n | WLC management IP address(es). 4 bytes per address. |
For multiple WLCs, concatenate addresses:
```
F1 08 0A0A0A32 0A0A0A33 → 10.10.10.50, 10.10.10.51
```
> **Critical encoding note:** Cisco APs expect the sub-option type `0xF1` (241). Some administrators mistakenly use sub-option 1 or sub-option 102, which will not work. Always verify the correct sub-option number for your AP platform.
---
## 3.7 — CML Lab Topology: Testing DHCP Options
### Extended Lab Topology
Build on the Module 2 topology by adding a voice VLAN and simulated IP phone/AP:
```
┌─────────────────┐
│ Linux-Phone │
│ (simulates │
┌─────────────────┐ ┌──────────────┐ Gi0/2 │ Cisco IP phone)│
**Objective:** Configure DHCP relay on Switch-1 and observe Option 82 being inserted.
> **Note:** This lab is a preview of Module 4 concepts. If your topology does not yet support inter-VLAN routing, skip this lab and return to it after completing Module 4.
**Steps:**
1. On Switch-1, enable DHCP snooping and relay (ip helper-address):
```
configure terminal
ip dhcp snooping
ip dhcp snooping vlan 100
ip dhcp snooping information option
! This enables Option 82 insertion
interface Vlan100
ip helper-address 10.1.1.1
end
```
2. Start a capture on the DHCP server's interface (Gi0/0).
3. Trigger a DHCP request from Linux-Phone on VLAN 100.
4. In Wireshark, apply the filter: `dhcp.option.agent_information_option`
5. Expand `Option: (82) Agent Information Option` and examine:
- **Sub-option 1 (Circuit-ID):** What port/VLAN information is encoded?
- **Sub-option 2 (Remote-ID):** What switch identifier is present?
6. Note that Option 82 appears in the **relayed** Discover and Request (server-side capture), but NOT in the original client-side capture. The relay agent inserts it.
**Deliverable:** Screenshot showing Option 82 sub-options with Circuit-ID and Remote-ID decoded.
---
## Quick-Reference: Option Hex Codes
When reading raw hex in captures or building `option 43 hex` commands on Cisco IOS, this conversion table saves time:
| Option | Decimal | Hex | Common Name |
|--------|---------|-----|-------------|
| 1 | 1 | `0x01` | Subnet Mask |
| 3 | 3 | `0x03` | Router |
| 6 | 6 | `0x06` | DNS |
| 12 | 12 | `0x0C` | Host Name |
| 15 | 15 | `0x0F` | Domain Name |
| 43 | 43 | `0x2B` | Vendor-Specific |
| 50 | 50 | `0x32` | Requested IP |
| 51 | 51 | `0x33` | Lease Time |
| 53 | 53 | `0x35` | Message Type |
| 54 | 54 | `0x36` | Server Identifier |
| 55 | 55 | `0x37` | Parameter Request List |
| 60 | 60 | `0x3C` | Vendor Class ID |
| 61 | 61 | `0x3D` | Client Identifier |
| 66 | 66 | `0x42` | TFTP Server Name |
| 82 | 82 | `0x52` | Relay Agent Info |
| 150 | 150 | `0x96` | TFTP Server Address |
| 255 | 255 | `0xFF` | End |
---
## Module Summary
| Concept | Key Takeaway |
|---------|-------------|
| TLV encoding | Every option is Type (1 byte) + Length (1 byte) + Value (L bytes). Exception: Pad (0) and End (255). |
| Magic cookie | `0x63825363` marks the start of the options field. |
In **Module 4: DHCP Relay**, we take Option 82 from a preview to a deep dive. You will build a multi-subnet lab with relay agents, understand how `giaddr` changes the DHCP server's pool selection logic, see exactly how Option 82 sub-options are inserted and stripped, and troubleshoot the classic "relay is configured but clients aren't getting addresses" scenario.
