[Kea-users] VIVSO and use with client classification

[Francis Dupont]

Jason Guy writes:

> I am not entirely sure why the ONIE documentation shows the IANA and ONIE
> suboptions,

=> the IANA block is a round around for an ISC DHCP bug and is fully
useless for Kea.

> but this is a "real-world" use-case

=> so in fact this is not...

> although I don't know if they are in the same packet.

=> they are (DHCPv6 but not DHCPv4 uses multiple options, one per
vendor, and as it is used by DHCPv4-over-DHCPv6 it is correctly handled
by the code (but not by configs because they are a bit too specialized
for cable labs :-)).

> When you say that "full support of multiple
> vendors", do you mean in the same packet, or in the config?

=> same packet again. When you receive a VIVSO only the first vendor
block is unpacked. If you try to send one (by config or using current
code) only the first vendor block is handled.

> I suppose this is easy enough to do in a hook though.

=> not so easy because the OptionVendor class was not designed to
handle multiple vendors.

> I suppose that makes sense since the substring matching is done in hex.
> Since the client classification I am working with, needs to return a VIVSO
> option
> with additional suboptions populated by the classifier, then defining the
> schema in an option-def is necessary, right?

=> it is not necessary: an unknown (sub)option is considered as being
binary and can be specified only by its code. Not very convenient but
still working.

> > => almost this but hex uses hexadecimal so you have to translate "powerpc"
> > in 0x706f7765727063
> 
> I read in the docs that a substring match with the .hex is compared as
> ASCII to the right operand.

=> you are right.

> I figured there would be an ordering feature... For now it is good to know
> the classes are ordered lexicographically.

=> the ticket fixing this is in the review queue.

> > "option-data": [
> > >    {
> > >        "code": 125,
> > >        "csv-format": true,
> > >        "data": "42623,0",
> >
> > => I don't believe this data works (at least it didn't when I created
> > a ticket to fix it some years ago :-).

=> according to what I read from the code the ",0" is simply ignored.

> This raises an interesting question in general. If I wanted to use vendor
> options from multiple vendor enterprise-ids (not in the same packet), this
> may not work?

=> with the "not in the same packet" it should be possible to find
a way to have different option-data entries and to control which one
will be used.

> Would this be the proper syntax to define/support multiple VIVSO options?

=> there is none for the same option-data. For different option-data
entries it is like other options.

> > >    {
> > >        "code": 0,
> >
> > => if it does not bug it should!
> >
> 
> Hmm...the configuration was accepted. I can look in the logs, hopefully it
> was gracefully handled and ignored.

=> I have to see how code 0 is handled. It is forbiden in most of spaces
but not in VIVSO suboptions according to the standard.

Thanks

Francis Dupont <fdupont at isc.org>