Option Definition Requirements

This page lists requirements only. For proposed definition, see DhcpOptionDefinition.


The current version of the DHCP software allows options to be defined in the configuration file. The options are their either added to packets sent to the server, or are interpreted in packets received bit it. In the latter case, the server does nothing with them; instead, the data is made available for use in conditional processing in handling received packets (this conditional processing also being defined in the configuration file).

Although the DHCP 10 software will allow hooks in processing, where user-written code can be called duing the processing of a DHCP request, a number of users will either not have the programming skills required to write such code, or will only require simple additions to the option handling. In both cases, it will be useful to provide a way whereby user-specific options can be defined using an inbuilt configuration options with a minimum of programming.

The requirements for the option definition framework in BIND 10 DHCP are listed below. As noted, many requirements are common to both DHCP V4 and DHCP V6, but some are specific to one or the other.

DHCPv4 and DHCPv6

Option Definition Requirements

  • Must be able to define an option in the DHCP configuration
    • It must be possible to define an code associated with the option (code will at least warn and possibly report an error when trying to redefine existing IANA-defined options)
    • It must be possible to define a name to be associated with the option
    • It must be able to define the data type of the option
  • The data associated with an option can be one of
    • Empty (an empty option. Information is conveyed by presence or absence of an option). This format is specific to DHCPv6 (DHCPv4 does not allow 0 length options).
    • Boolean (single byte, 1 = true, 0 = false)
    • Integer (both signed and unsigned, 8, 16 or 32 bits wide)
    • IPv4 address
    • IPv6 address
    • Text string
    • domain name (encoded according to RFC3315, section 8)
    • Byte list
    • Record (ordered set of different data types concatenated together)
  • The multiplicity of data associated with an option is:
    • Single - a single value is associated with the option
    • Array - option comprises a single data type repeated over and over again:
      • Arrays of records are allowed
      • Arrays of text strings or arrays of byte lists are not allowed (as the protocol includes no way to define the length of string or list unless the option length field is used).
  • It must be possible to define vendor-specific options.
  • It must be possible to define options from multiple vendors that may conflict in name and code value (either with other vendor options or with system-defined options).
  • When specified in the configuration, it must be possible to use the option definition to create a stream of bytes that should be included in an outgoing packet.
  • It must be possible to use the option definition to extract named data values from an incoming packet - either from within a a configuration statement or from within a hook function.
  • It must be possible to convert option content into text representation for logging and further processing purposes.
  • It must be possible to specify that option conveys options (sub-options) of specific user-defined space.
  • It must be possible to set different contents for the option, depending on the subnet which client is attached to.

Under consideration

  • Enforce restriction that user can't override the format of standard standard options:
    • pros:
      • if the user overrides format of the critical standard option it may disrupt the operation of the server significantly,
    • cons:
      • if some new standard options are not yet implemented in the DHCP server, users may want to define them through config file. When new options are eventually implemented the existing definitions will invalidate due to this restriction while users may want to keep using it,
      • if the standard options implemented in the DHCP server are incomplete (e.g. list of conveyed sub-options is incomplete), users may want to extend it on their own discretion,
      • more complex configuration (either .spec file or configuration commands) due to the need to separate standard option space from custom options space.
  • Enforce restriction that user can't override content of the certain standard options (e.g. CLIENTID must be dynamically generated):
    • pros:
      • if the user overrides the data of the critical standard option in this way that DHCP server sends fixed values (e.g. fixed CLIENTID) it will disrupt its operation,
    • cons:
      • complexity of implementation (need to track which options can have their content overriden, which not),
      • relays, clients and servers would need to use different .spec files (e.g. it is valid for the client to set fixed CLIENTID but it is not valid for the server).
  • It must be possible to specify which options are always sent to the client and which are sent only when requested. This requirement seems to be beyond the scope of Option Definition so we might want to some other, more appropriate place.
Last modified 5 years ago Last modified on Oct 1, 2012, 10:56:43 AM