Thoughts on DHCP Option Definition

[Tomek Mrugalski]

On 28.09.2012 13:45, Stephen Morris wrote:
> After discussing the option definition issue with Marcin today, I
> thought that I'd put down my thoughts on how it would work:

> All option definitions - both pre-defined ones and user/vendor-defined
> ones - would be in the configuration database.  The pre-defined
> options definition area would be populated from a .spec file, the
> other two areas would be empty.  Although pre-defined options could be
> defined in the code, it seems to me that defining everything in the
> .spec file would mean just one code path for all options.  It would
> also make it easier to add new pre-defined options - just update the
> .spec file.
That seems like a wrong place for it. Pre-defined options is not part of
the configuration. It is a configuration template. I really think it
should be in a separate place. If you put it in the wrong place, then
you get the sort of problems you are about to get into now (how to make
flexible configuration inflexible, see your next paragraph).

> However, the pre-defined option definitions should not be able to be
> altered by the user: I don't know whether this is possible with the
> current configuration system, I suspect not.
I also don't think there is one and I believe it should stay that way.

Also, I'd like to comment on Marcin's point about having the option
definition (the template) requires to provide values for it. That is not
acceptable and must be changed. For couple reasons:
1. not all options are blindly set for the server. DHCP is really a
two-way communication channel and client sometimes send it to the
server, not the other way around. See FQDN option for example. It can
work both ways: client sending its name OR server telling the client
what his name is. Both use cases are valid.
2. In a general case, user may want to define an option that his clients
will send up to server and server will do something with it, e.g. call
hooks. We to provide a way to define that this new option 123 is an
array of v6 addresses and pass it to hooks as such.
3. The problem of maintainability. Consider the following case. We
release Kea 1.0 gold with support for all 70 v6 options defined to this
date. It gets packaged by e.g. Debian. The next day new RFC is published
with option 71 that defines something obscure, like a voltage range for
robotic vacuum cleaners. Now the legion of maintainers for different
systems update some form of option template file and respind their
packages. Consider this a forward compatibility. That part is good. Now
if we force everyone to specify value for the option, everyone will
suddenly scratch their head trying to figure out what to put in that new
option.
3b. Or to put it in a simpler way: there's around 70 v6 options and well
over 100 options for v4. We can't expect users to provide values for all
of them.

> When reading the options, user option definitions would override
> vendor-option definitions, which would in turn override pre-defined
> option definitions (any overriding being marked by a warning message
> written to the log file).  At the end of the configuration process,
> the option definitions would be stored in some form of option
> interpreter object.
An approach that prints out warnings when used properly is flawed. We
talked about this with Marcin before. If the format user specifies is
covered by one of our option classes (integers list, addresses list,
fqdn etc), then we use it, because of their simplicity and
effectiveness. For stranger formats, there should be one custom class
that supports every possible combination, albeit at the cost of
increased complexity and lowered performance.

> The option definitions are the first part of the configuration to be
> processed.  During the rest of the configuration processing, when the
> setting of an option is encountered, the option name and its value is
> passed to the interpreter: the return value is a vector of bytes
> representing the wire format of the option.
I would very much prefer to avoid this, because it would throw away the
whole stack we wrote so far. Option definitions should return a pointer
to the Option factory instead. That will be used to parse incoming
options. Once value for known options are specified, those factories
should be used to instantiate objects, using aforementioned factories.
The returned Option object will then be used around, stuffed into server
responses, passed to hooks etc. Immediately producing on-wire format
would be much less useful and more difficult to work with.

> I suppose the main question are:
> 
> * Having the user being alter pre-defined option definitions -
> possibly unsuspectingly - may prove awkward.  If, for example, they
Agree. That should not be possible at all.

> change the definition of an option that holds a four-byte integer
> value to one that holds a two-byte value, then unless the code
> registered an overflow when setting it, the problem would not be
> discovered until the data were received at the client.
> 
> * Do we want to allow user and vendor-defined options to override
> pre-defined ones?
Why would you want to predefine vendor options if you can't possibly
know its format?

Tomek