Understanding DHCP Option 82

The DHCP Information option (Option 82) is commonly used in metro or large enterprise deployments to provide additional information on “physical attachment” of the client. Option 82 is supposed to be used in distributed DHCP server/relay environment, where relays insert additional information to identify the client’s point of attachment.

As you know, DHCP relay is supposed to insert the “giaddr” field in the relayed DHCP packets, so that DHCP server may identify the pool to be used for the request. The choice of the pool is made based on the “giaddr” field or the incoming interface, if the “giaddr” is missing or zero . Option 82 serves as refinement to the request, allowing the DHCP server to select a “sub-range” in the pool. (Notice that by default Cisco IOS devices reject packets with zero “giaddr” and by default Cisco Catalyst switches use “giaddr” of zero when configured for DHCP snooping!)
The formatting of Option 82 field is as follows. The option starts with 0×52 (82 decimal) followed by the total option length. The option is structured in sub-options, formatted in the same way: . The list of options is terminated with option 0xFF so you can easily spot Option 82 in a packet dump.

<Option 82>  ::= 0x52 | LEN | <sub-option1> | <sub-option2> |.. | 0xFF |
<sub-option> ::= <option-id> <length> <contents>

RFC 3046 defines just a couple of sub-options, namely the “remote-id” (option ID 0×2) and the “circuit-id” (ID 0×01). Those two are supposed to identify the remote device and the port where the DHCP request was received. However, many vendors prefer using their own extensions to Option 82, based on its flexible format. This freedom of choice leads to some serious consequences with respect to IOS devices configuration. We are now going to discuss this a bit later. For now, keep in mind that IOS devices use sub-option 0×6 instead of 0×1 for circuit identification (at least the more recent IOS releases). The formatting of the sub-options is also vendor and software version dependent!
In Cisco IOS devices, you configure information-option based address allocation using the concept of DHCP class. A given class specifies the range of Option 82 values and could be associated with a range of addresses in DHCP pool. Before you can use classes, make sure the command ip dhcp use class is enabled in router’s configuration (the default). After this, you may create a class as follows:

ip dhcp class TEST
  relay agent information
     relay-information hex 020c01020304*

Notice the use of “*” globbin pattern to match any string of characters after the initial substriting. This type of formatting specifies the value of DHCP Option 82 in “raw” format – that is, no structure is specified in the option. The value used in the class is everything that follows the initial “0×52 ” tuple in Option 82 – that is, the list of all sub-options, including their initial ID/Length tuples. The terminating option 0xFF is not included in the relay-information field. Due to the flexibility of Option 82 formats, Cisco IOS only allows you using the “raw” formatting, without any referencing to the sub-options and their values. In addition to the globbing character “*” you may also use inverse wildcard mask as follows:

relay-information hex  bitmask 0000000FF

where the bitmask follows the same syntax as an access-list wildcard, with “1” meaning “don’t care”. Notice that the relay-information value is formatted in hex and should contain even number of character. The bitmask should match the relay-information length.
Next, after you have the class configured, you may associate it with a DHCP pool. Remember that the pool address range should match the “giaddr” IP address found in the relayed packet:

ip dhcp pool POOL
  network 204.12.1.0 255.255.255.0
  class TEST
     address range 204.12.1.100 204.12.1.100

Notice how the range is assigned to the class associated with the DHCP pool. Now the question that people usually ask is: “If IOS uses raw formatting for Option 82, how do I find the value used by the remote relay?”. Cisco documentation refers you back to the “vendors” specifications for the use of Option 82. What if you just configured a server and a relay and want to learn the value of DHCP Option 82 used?
1) Make sure remote device is configured for insertion of Option 82. For an IOS router, you may want to have a configuration similar to the following:

ip dhcp relay information option
!
interface Fa 0/0
 ip helper-address 10.0.0.1
 ip dhcp relay information option subscriber-id TEST

The above configuration sets the value of the subscriber-ID (even though it’s NOT sub-option 0×2, but rather sub-option 0×6). Notice that by default, the information option is not being inserted by IOS routers. Furthermore, the syntax is different for IOS switches and may vary from model to model. By default, when you enable DHCP snooping in a 3550/3560 switch, the switch will be inserting the information option but will set “giaddr” to zero. To handle this in an IOS router, use the command ip dhcp relay information trust-all to accept packets with zero “giaddr”.
2) Configure a DHCP pool matching the remote “giaddr” IP address value. Create a DHCP class with a relay-information value that should never be met in real life. For example set the value to “00000000*” which should never match any sub-option. Associate this class with the pool and configure a sub-range as usual.
3) Enable the following debug in the server: debug ip dhcp server class which tracks the class-based allocation. When an incoming packet contains a DHCP Option 82 that does not match any class, the output similar to the following will appear:

DHCPD: Class 'TEST' matched by default
DHCPD: Searching for a match to 'relay-information
020c020a0000cc0c010200000000060454455354' in class TEST

revealing the actual value of Option 82 in the packet. In the output above, there ate two sub-options: 0×2 with the length of 0xc and 0×6 with the length of 0×4. Using this debugging output you may quickly learn the value of Option 82 used by the remote relay, without referring to any low-level debugging commands.