It’s already been a few months since ISC announced the release of its latest and greatest version of DHCP (something I guess we could excuse you from missing, what with the wall-to-wall coverage that week of Olivia Newton-John headlining 45 shows in Las Vegas).
In any case, boy oh boy, is version 4.3 stacked to the binary rafters with new IPv6 goodness. Crediting progress in the standards, the ISC wizards have added additional DHCPv6 support. Some of the new features provide functional parity with ones already available in DHCPv4. All of them should be of keen interest to those operating (or planning to operate) DHCPv6 in production networks.
Let’s briefly review what’s new:
- Support for the use of classes
- Support for on_commit, on_expiry, and on_release statements
- Improved logging for address assignments
- Support for using DHCPv6 relay options in expressions
- Support for the new standardized DDNS Update Style
One of the more promising features for those running DHCPv6 in the wild is newly-added access to those DHCPv6 options added by relays.
Recall that unlike in DHCPv4 where options are inserted into a DHCP packet from the client by the relay, in DHCPv6 the DHCPv6 client packet is encapsulated and the options added to the encapsulated layer.
The previous version of ISC DHCP would helpfully decode those options for you, but then somewhat less helpfully not allow you to act on that info (somewhat like the third runner in a relay race deciding to hang on to the baton).
In Figure 1, the top half of the graphic shows us a typical path for a DHCPv6 request, originating with the client, passing through two relays then reaching the DHCP server. The bottom half of the graphic shows the original request with encoded options and each subsequent relay encapsulating the original request while adding its own options. Finally, the DHCPv6 server decapsulates the request and decodes the options present.
Figure 1 – DHCPv6 Request Relay and Server Option Decode
In version 4.3, you can now specify which of the decoded options you want and from which relay. The remote-id option syntax is the key to understanding how this feature works, displayed in Figure 2 (below).
Figure 2. Remote-ID Option Syntax
The standards specify the rudimentary option syntax, which consists of the enterprise ID followed by the remote ID in some format.
The resulting options added by the relay might consist of the vendor, the DUID of the relay (recommended to keep the information unique), the device type and finally the port or circuit number (often identifying the client).
Knowing how this info is presented allows for custom provisioning of DHCPv6 info for a particular client or client type or circuit ID. Classes can now be created based on DHCPv6 relay-provided options (rather than just client-provided options).
Up to 32 relays are supported — though if you have anywhere near 32 relays in your production environment you should probably seek professional help.
For more detail on this and additional DHCPv6 feature support, be sure to watch this video from ISC.
