The Problem DHCP Option 82 Solves
A standard DHCP exchange tells the server two things about a requesting device: its MAC address and the IP of the relay agent that forwarded the request. That is enough for a small office. For an Internet Service Provider managing hundreds of thousands of subscribers across dense apartment buildings, it is not enough. The server knows that a device asked—but not where it is physically connected.
Without location context, an attacker in Apartment 12B could craft a DHCP request claiming the MAC address belonging to Apartment 4A's legitimate modem and steal that customer's IP assignment. DHCP Option 82, formally defined in RFC 3046, solves this by instructing the access-layer switch or DSLAM to embed physical port information directly inside every DHCP packet before forwarding it upstream.
How Option 82 Works: The Stamping Process
Option 82 is technically a container option called the Relay Agent Information Option. It is inserted by the relay agent—typically the access switch or the broadband remote access server (BRAS)—not by the end-user device. The end device never sees it. The insertion happens like this:
- The client sends a DHCP Discover or Request broadcast.
- The access switch intercepts the broadcast before relaying it. It inserts Option 82 into the DHCP packet, then unicasts the modified packet to the DHCP server.
- The DHCP server reads the Option 82 data, applies its policy (assign, drop, or redirect), and sends a reply.
- The relay agent strips Option 82 from the reply before delivering it to the client. The client never knows Option 82 existed.
The Sub-Options: Circuit ID and Remote ID
Option 82 is a container. Its two most important sub-options carry the actual location data:
Sub-Option 1: Circuit ID
This identifies the specific physical port on the access switch. A typical Circuit ID string looks like slot/module/port:vlan or a formatted string such as Gi1/0/14:100. In DSL deployments it might encode the DSLAM chassis, card, and port. The format is not standardized—each vendor and ISP defines their own encoding, which is why inter-vendor deployments sometimes require normalization at the DHCP server.
Sub-Option 2: Remote ID
This identifies the relay agent device itself, typically using its MAC address or a configured hostname string. In a multi-tier ISP network, the Remote ID distinguishes which DSLAM or aggregation switch forwarded the request when many relay agents point at the same DHCP server.
Architecture in an ISP Deployment
A simplified ISP deployment looks like this. Subscriber modems connect to a DSLAM or OLT. The DSLAM acts as the relay agent: it stamps Option 82 and forwards DHCP traffic to a central DHCP server in the network operations center. The DHCP server has a policy table that maps Circuit ID strings to specific IP pools or static reservations. Apartment 4A's port always gets an address from the pool assigned to that customer account. Apartment 12B's port gets an address from its own pool. Even if someone spoofs the MAC address, the Circuit ID stamped by the switch does not match the expected port for that MAC, and the DHCP server drops the request.
Option 82 Policy Modes
| Policy | Behavior | Typical Use Case |
|---|---|---|
| Keep | Server preserves existing Option 82 if already present | Cascaded relay environments |
| Replace | Relay overwrites any existing Option 82 with its own data | Ensuring only the local switch's data is trusted |
| Drop | Relay discards packets that already contain Option 82 | Preventing spoofed Option 82 from end devices |
Enterprise Use Cases Beyond ISPs
Option 82 is not exclusive to carriers. Large enterprise networks use it for several practical purposes:
- Port-based VLAN assignment: The DHCP server reads the Circuit ID to determine which VLAN an IP should come from, effectively automating VLAN membership based on physical port.
- Audit and forensics: DHCP lease logs that include Circuit ID let network teams trace exactly which physical port was active during a security incident, even if the MAC address was spoofed.
- Policy enforcement: Devices connecting from unauthorized ports (e.g., a wall jack in a lobby) can be assigned to a restricted guest VLAN automatically, without 802.1X configuration.
Common Misconceptions
Misconception 1: Option 82 Is Only for ISPs
Any managed switch that supports DHCP snooping and relay agent information can insert Option 82. Enterprise campus networks with Cisco, Juniper, or Aruba infrastructure commonly use it for automated IP policy enforcement at the access layer.
Misconception 2: The End Device Can Read or Modify Option 82
The end device never sees Option 82. The relay agent strips it from the server's reply before forwarding the packet to the client. An end device that attempts to include a fake Option 82 in its Discover message will either have it replaced or have the packet dropped, depending on the relay's policy.
Misconception 3: Option 82 Provides Full Authentication
Option 82 provides location context, not cryptographic authentication. The Circuit ID is a string the switch inserts based on port configuration—it can be misconfigured or, in less secure setups, trusted too broadly. It works best as one layer in a defense-in-depth strategy alongside DHCP snooping and 802.1X.
Misconception 4: Home Routers Support Option 82
Consumer routers act as DHCP servers, not relay agents, so there is no use case for them to insert Option 82. The feature lives in managed enterprise switches, DSLAMs, OLTs, and BRAS devices.
Pro Tips
- Normalize your Circuit ID format. Choose a consistent encoding scheme across all switches before deployment. A mix of formats from different switch generations creates matching headaches at the DHCP server.
- Enable the Drop policy on access ports. Configure your access switches to drop DHCP packets that already contain Option 82. This prevents a savvy attacker from crafting their own Option 82 sub-options to manipulate IP assignment.
- Log Circuit IDs in your DHCP server. ISC DHCP and Kea both support logging the full relay agent information. A timestamped record of which port received which lease is invaluable during incident response.
- Test with a DHCP packet capture. Use Wireshark with the filter
bootpand inspect the Relay Agent Information fields when troubleshooting Option 82 deployments. The decoded sub-options are visible in the protocol tree. - Coordinate with billing systems early. If you plan to use Circuit ID for automated customer provisioning, map the encoding format to your OSS/BSS before rollout. Post-deployment changes require touching every switch configuration.
- Combine with DHCP snooping. Option 82 alone does not prevent all rogue DHCP attacks. DHCP snooping on the same switch enforces that DHCP Offers can only arrive from trusted uplink ports, completing the security picture.
DHCP Option 82 transforms a simple IP assignment protocol into a location-aware policy engine. For any organization that needs to tie IP address assignments to a specific physical location—whether for security, billing, or automated provisioning—it remains the most practical tool available without requiring 802.1X infrastructure. Analyze your current IP assignment details here.