Thoughts on DHCP Option definition design

[Stephen Morris]

On 21/09/12 12:24, Marcin Siodelski wrote:

> Requirement: Give the ability to define custom option formats to 
> DHCP administrators without a need to write the code - One of the 
> possible ways to go would be to use BIND10 Configuration Manager 
> data structure to hold options definition. : I like the simplicity 
> of this solution so I would like to preserve it in the design
> being created.

Agreed.


> Requirement: Limit the number of different configuration files for 
> the same thing.

I'm not clear what you mean here.  There will be a .spec file defining
the parameters for the server, but won't the the data go into the
standard BIND 10 configuration database?

I would see the .spec file as defining two areas in the database:

* an "options" area that lists all the standard parameters and allows
the user to set them.
* a "user_options" area that is initially empty.

The syntax for adding and setting the parameters in the two areas
would be different, but that reflects the fact that "options" are
pre-defined
but "user_options" are not, e.g.

config set Dhcp4/options/subnet_mask "255.255.255.0"
config set Dhcp4/options/dns_server "192.0.2.1 192.0.2.2"

config set Dhcp4/user_options[0]/name "user1"
config set Dhcp4/user_options[0]/code 249
config set Dhcp4/user_options[0]/value "42"

Only known options can be added to the "options" area, whereas
anything can be added to the "user_options" area. (I _think_ this can
be done with the current spec file format, but it would be worth-while
checking.)


> Requirement: User can't override the format of the standard option.
> Thus, standard options format should not be defined in the .spec
> file and if somebody tries to define the new option format whith
> the code of CLIENTID option server should reject it. This means
> that server has to store the standard option codes and names and
> validate new options being defined against it.

I agree with the requirements, but I'm not clear about the solution.
If anyone modifies the system-defined "spec" files, then all bets are
off - they should not expect the software to work.  So if it makes
sense to put information there, we should do so.

We might want to extend the isc-sysinfo program - used for generating
information to accompany a bug report - to calculate and print the SHA
digests of all the .spec files.  That way we can see if they've been
tampered with.


> Requirement: Only some standard options may have their content set 
> by the user. - Many standard options have their content set in 
> flight (based on information coming from DHCP client). CLIENTID 
> value is based on "who the client is" so setting the arbitrary 
> value does not make sense. Attempt to set CLIENTID through the
> spec file should result in failure. Thus, server has to carry the 
> information which of the standard options can be overriden and 
> which not. Hardcoding it in the function with switch() statement
> or number of ifs should be sufficient.

If we use the "dual area" approach above, this would seem to reduce to
the problem of not allowing the user to define standard options in the
user area.  Perhaps the parsing could prohibit the use of option
numbers reserved to standard options from appearing there?


> Requirement: Custom options value should be always set. - Data 
> carried by custom options are somewhat transparent to the server 
> and server has no way to set them on his own discretion. For this 
> reason, if user defined the new option he MUST set its value too. 
> If it doesn't than server should report an error. In fact it
> should be prohibited to add new option without setting its data.

This restriction could be enforced by the option parsing.


> Once option is added the data can be modified but not removed.

Any change to the configuration database should cause the verification
and parsing code to run again - the data removal should be able to be
detected at that point.


> Requirement: Some options must be always sent to the user, some 
> not. - In many cases, DHCP client asks for specific options (using 
> ORO) in some cases server should always send the specific options 
> even if not asked. We need to have a flag in the data structure 
> that would inform the server that option is to be always sent. By 
> default this flag could be set to false.

OK - good idea.  This matches up with

http://bind10.isc.org/wiki/DhcpCompatibility


> Requirement: Use the same data structure to create new options and
>  configure new and standard options.

The syntax of the specification is likely to be different (see above),
but once the information is read into memory, there appears to be no
reason why they can't be represented in the same way.


> I did not yet consider "Options encapsulation" yet but as far as I 
> know it doesn't yet work really well in DHCP4. Should this be 
> discussed here?

Do the simple things first, else we'll get stuck in "analysis paralysis".


> Lastly, I haven't made any attempts to specify CfgMgr commands to 
> modify the data and in fact I don't thing there is any sense to do 
> this until we define the final data structure in CfgMgr.

OK.

Stephen