[kea-dev] Can DHCPv6 option content be changed at runtime, e.g. triggered by vendor class ?

[Tomek Mrugalski]

On 13.11.2015 14:31, normen.kowalewski at telekom.de wrote:
> I have been digging into what I could do in KEA based on variation of
> content in DHCPv6 Vendor Class option (16) as described in section
> 22.16 of RFC3315.
Hi Normen!

First of all, thanks a lot for looking at Kea!

> While DHCPv6 option (16) is obviously implemented [1],[2], I fail to
> understand the scope and extent by which triggering events and/or
> actions based on content based on this option is supported (or
> planned or already discussed and discarded to be supported).
There are couple ways in which vendor class option can be used today.
The third way will be available in the upcoming Kea 1.0, which is
expected by end of this year.

Let's go over them.

1. Current use of vendor-class option. We currently have a very simple
classification based on vendor-class that is useful in cable networks.
It checks whether the vendor-class contains "docsis3.0". If it has, then
the packet is assigned to a VENDOR_CLASS_docsis3.0. If it contains
"eRouter1.0", the packet is assigned to VENDOR_CLASS_eRouter1.0. If the
packet contains vendor-class option, but its content is neither of the
above, the first touple is converted to text and packet is assigned to a
class VENDOR_CLASS_(content of the first touple). Depending on how
complex your vendor-class is, you may or may not find the last case useful.

If you want to understand how that is done, see
Dhcpv6Srv::classifyPacket in src/bin/dhcp6/dhcp6_srv.cc:2781.

2. It is possible to restrict a client to a given subnet based on the
class it belongs to. See section 8.2.17
http://kea.isc.org/docs/kea-guide.html#dhcp6-client-classifier

3. It's also possible to both assign packet to a class and do something
based on the class in hooks. This is not hard, but requires some C++
knowledge. Here are some pointers.

To add a packet to a class, you can call pkt->addClass("foo"). A good
example how to extract that info from vendor-class is in the
Dhcpv6Srv::classifyPacket above. The best place to call it would be
pkt6_receive hook.

To do something based on the class, you can write something similar to:

if (pkt->inClass("foo")) {

    // Get rid of the option that may have been assigned.
    pkt->delOption(123);

    // Assign whatever option value is better.
    OptionPtr opt(new Option(Option::V6, ...)
    pkt->addOption(opt);
}

If you're willing to go that route, please remember that we have an
extensive documentation for hooks development:
http://git.kea.isc.org/~tester/kea/doxygen/df/d46/hooksdgDevelopersGuide.html
It's also very much ok to talk about it on kea-dev (or off the list if
you prefer that way).

4. We understand that the approaches mentioned above have significant
limitations. That's why we're working on client classification that
would allow achieving what you want to with just config file editing.
This is a work in progress that we're planning to release in the
upcoming 1.0. For now, we have requirements (what?) and the design
(how?). If you're interested, it would be great if you could read and
comment on them. The implementation is well in progress, but if you have
any comments or changes you'd like to see in Kea, we can definitely talk
about them.

http://kea.isc.org/wiki/ClientClassificationRequirements
http://kea.isc.org/wiki/ClientClassificationDesign

Feel free to comment on the list (or privately to either Marcin or myself).

> [1]
> https://ftp.isc.org/isc/kea/0.9-beta1/doc/kea-guide.html#dhcp6-client-classifier
While this particular piece of code was around for a while, so it
doesn't matter in this case, I'd like to point out that you're using
documentation for 0.9-beta1, which is very old. Unless you have very
good reasons for that, I strongly recommend using the latest release
version, which is Kea 0.9.2.

Hope that helps.
Tomek