Options that contain options that contain options

[teemu.savolainen at nokia.com]

> > Do you think there is any way to support those in 4.2.0 other than by
> defining the data directly (e.g. as hex values)? I tried to define
> options that encapsulate other options, but couldn't manage to get that
> work..
> 
> I think so.  The brain-bending problem is that one option is a
> container for another option, but the DHCPv6 style is to use option
> code definitions from the DHCPv6 common space (and not to enumerate
> sub-option codes).
> 
> So these are DHCPv6 options that might exist in the 'dhc6' space, but
> to encapsulate them appropriately you need a unique space name to
> define the lower level options in, and then a new unique space under
> that.
> 
> It's a bit of work to enumerate all that.
> 
> The only wrinkle then is that these are options that have a fixed data
> block followed by encapsulated options.  Support for this format is in
> all versions of the server I think, but it is not very commonly used so
> I would be quite skeptical that it would work flawlessly. :(

I tried some time to play with namespaces etc, and also noticed mixing fixed data & options made it harder to figure out how the configuration file should be built.. especially as I couldn't find good examples nor I have long experience with DHCP server configuration..

To save time I ended up just passing the option content as a hex-string and writing a piece of code that decodes the option:-)

By the way, on the DHCPv6 client side I also had some trouble to find the data structure that stores the DHCPv6 server's/relay's link local address (that information is needed to add routes towards that address). I found the address at "packet->client_addr" field, which does not sound too descriptive for me:) But I assume it is because that field of the packet structure is usually only used by the DHCPv6 server?

Best regards,

Teemu