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:
We just had a discussion with Marcin and we agreed that it would be
useful to be a bit more specific, which options should be handled by the
option definition framework and which are handled by allocation engine
and as such not defined (or at least a user is not allowed to change
their value) in option definition framework.

The following list is for DHCPv6, but the same rules apply to DHCPv4:

Protocol options
These are options that require some logic behind them, i.e. the server
must understand its content and process or generate it. In other words,
they are essential to the protocol operation. They will be handled by
the allocation engine.
- client-id
- server-id
- IA_NA
- IA_TA
- IAOption
- ORO
- elapsed time
- relay message
- authentication message
- status code
- interface-id
- reconfigure message
- reconfigure accept
- IA_PD
- IAPrefix
- FQDN

Formats of those options should be hardcoded, not modifiable and its
content must not be directly settable by the user.

Options handled by Option definition framework:
For the following options only values can be specified, their format
must not be changeable. The following options can be handled by option
defintion framework, if only their values, but not their format can be
modified by the user. If that restriction is inconvenient or difficult
to implement, those can be considered protocol options as well.
- rapid commit
- server unicast
- preference

Option definition framework:
These are the "configuration" options. They don't influence how the
protocol works, they are just payload. These options are sent be the
server, when requested by clients. Option definition framework should
focus on those:
- user class*
- vendor-class*
- vendor-specific info option*
- dns servers
- domain name
- sip servers, domains
- NIS/NIS+ servers, domains
- NTP configuration
- DS-Lite configuration
- Most (all?) additional options defined in other RFCs
- Options defined in drafts that don't have option codes assigned yet*
- Any other option the user may come up with*

Option marked with * are the only options we should allow custom format
to be defined.

There's one complication with vendor-specific info. Server may be
configured to provide different vendor information depending on the
content of the option (e.g. Cisco hardware sends Cisco vendor-id and
requires Cisco specific value, Juniper may have other set of
vendor-specific options). If such a thing complicates option definition
too much, we can (and probably will) develop dedicated code to handle
vendor options.

Tomek