[kea-dev] DHCPv4 vendor-encapsulated-options (43) option (solution)
fdupont at isc.org
Fri Sep 15 14:39:25 UTC 2017
First as the ISC DHCP solution shows a solution can be extended to
DHCPv4 options with codes 224 to 254 aka site options (255 is END),
cf RFC 3942. In dhcp4.h the DHCPOptionType enum finishes by:
// DHO_VSS = 221,
// 222-223 are removed/unassigned
// 224-254 are reserved for private use
DHO_END = 255
It is clear the unpacking of option 43 and similar must be deferred,
so we have to add a list of to-be-deferred codes.
When? For the option 43 it is when the incoming packet is classified,
automagically with the option 60 or by evaluating configured expressions.
So the unpacking should be postponed after the classification and
the definition to apply is given by classes with a default to
the current definition.
This fix the bug because when a raw value is expected it is enough to
add matching incoming messages to a matching class which defines
the vendor-encapsulated-options to binary so the default won't apply
On the sending side the simplest is to reuse the option definition from
the incoming message classes.
There are 2 details to define before closing/implementing this proposal:
- what syntax? IMHO the simplest is to reuse the option-def syntax
and most of the parser. Differences should be to restrict the code
and to store the definition in the client class.
- what to do when more than one matching classes define the option.
A (too?) simple solution is to get and use the first one.
Another solution is to raise a warning when other(s) match(es).
Note an error is not very suitable because it introduces too
easily unexpected failures. With a warning someone can improve
class evalution expressions to make them exclusive (and Kea has
no limit on class numbers so it can be painful but never unfeasible).
I have no other point to discuss but I can have missed some...
Francis Dupont <fdupont at isc.org>
More information about the kea-dev