Internet DRAFT - draft-dhankins-atomic-dhcp
draft-dhankins-atomic-dhcp
Dynamic Host Configuration Working D. Hankins
Group ISC
Internet-Draft September 2006
Expires: March 5, 2007
DHCP Option Processing, Explained
draft-dhankins-atomic-dhcp-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 5, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
94063
Abstract
Most protocol developers ask themselves if a protocol will work, or
work efficiently. These are important questions, but another less
frequently considered is wether the proposed protocol changes present
themselves barriers to adoption by deployed software (more
importantly, needlessly so).
This document seeks to provide information on the challenges to DHCP
Hankins Expires March 5, 2007 [Page 1]
Internet-Draft Atomic DHCP September 2006
Option software implementers, and in doing so to provide guidance to
prospective DHCP Option authors to help them produce options that are
easily adoptable.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. About ISC DHCP . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Atomic DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Bring in the Atoms . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Integers . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. IP Addresses . . . . . . . . . . . . . . . . . . . . . 7
3.1.4. Text and Strings . . . . . . . . . . . . . . . . . . . 8
3.1.5. Encapsulation . . . . . . . . . . . . . . . . . . . . 9
3.1.6. Domain Names . . . . . . . . . . . . . . . . . . . . . 12
3.1.7. Making Arrays . . . . . . . . . . . . . . . . . . . . 13
3.2. Molecular Assembly . . . . . . . . . . . . . . . . . . . . 14
3.2.1. Configuring Format Strings . . . . . . . . . . . . . . 14
3.2.2. Illegal Combinations . . . . . . . . . . . . . . . . . 15
3.2.3. Legal Combinations . . . . . . . . . . . . . . . . . . 15
4. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Conditional Formatting is Hard . . . . . . . . . . . . . . 16
4.2. Its Probably Been Done . . . . . . . . . . . . . . . . . . 16
4.3. Keep It Simple, Stupid . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Hankins Expires March 5, 2007 [Page 2]
Internet-Draft Atomic DHCP September 2006
1. Introduction
DHCP [1] Software Implementors are not merely faced with the task of
encoding and decoding DHCP Options [2] within DHCP Packets. They
must also mediate between the Systems Administrators and Option
Consumers (from users to applications) to formulate and present the
Option.
Additionally, many Software Implementors are pressed for time, the
chief component that decides how many new features can be put into
software releases.
There are many things you, the reader, can do to form your DHCP
Options to make Software Implementors lives easier, and improve the
chances that your Option is formally adopted in deployed software
after it has been assigned an Option Code.
In this document, the author intends to describe one Software
Implementation, and how it has chosen to cope with the complexity of
DHCP [1] Option Encoding, Configuration, and Consumption.
In doing this, it is hoped that the reader will gain a better
understanding of the challenges that might be faced by an Implementor
in adopting the Options they plan to introduce.
2. About ISC DHCP
The ISC DHCP software package was written by Ted Lemon. Since then,
it has been taken under the wing of Internet Systems Consortium, Inc.
("ISC") where it has been maintained in the public interest by
contributors and ISC employees.
It includes a DHCP Server, Relay, and Client implementation, with a
common library of DHCP protocol handling procedures.
The DHCP Client may be found on some Linux distributions, and FreeBSD
5 and earlier. Variations ("Forks") of older versions of the client
may be found on several BSDs, including FreeBSD 6 and later.
The DHCP Server implementation is the only one known to be in wide
use by most Unix-based servers, and comes pre-installed on most Linux
distributions.
The Relay Agent implementation is not known to be in wide use, and
even if it were, it makes no special handling of DHCP Options and so
is not really a topic of this document.
Hankins Expires March 5, 2007 [Page 3]
Internet-Draft Atomic DHCP September 2006
3. Atomic DHCP
The ISC DHCP Software Suite has to allow:
o Administrators to configure arbitrary DHCP Option Wire Formats for
options that either were not published at the time the software
released, or are of the System Administrator's invention (such as
'Site-Local' [3] options), or finally were of Vendor design
(Vendor Encapsulated Options [2] or similar).
o Pre-defined names and formats of options allocated by IANA and
defined by the IETF Standards body.
o Applications deriving their configuration parameters from values
provided by these options to receive and understand their content.
Often, the binary format on the wire is not helpful or digestable
by, for example, 'ifconfig' or '/etc/resolv.conf'.
To accomplish these goals, a common "Format String" is used to
describe, in abstract, all of the above. Each byte in this format
string is described in this document as a "DHCP Atom". You chain
these 'atoms' together, forming a sort of molecular structure for a
particular DHCP Option.
Configuration Syntax language allows the user to construct such a
format string without having to understand the meaning of each Atom,
and determines both how the Atom is encoded on the wire, and how it
is configured or presented.
As these Atoms are chained together to produce a single complex
option format, the configuration and presentation of those options
becomes defined by the sum of its parts.
We will describe the 'Atoms' from this point of view - how they might
be configured, as from scratch, and used on an ISC DHCP Server or
Client.
3.1. Bring in the Atoms
The following is a list of all of the Atoms that ISC DHCP has
implemented as of this date, some in pre-release software. The
author of any new option however should refer to the library of
previously allocated DHCP options, per IETF RFCs, as a more accurate
and up-to-date picture.
We are going to describe the atoms from the point of view of a
configuration file author, then individually how they will appear on
the wire, and in values passed to applications or displayed to users.
Hankins Expires March 5, 2007 [Page 4]
Internet-Draft Atomic DHCP September 2006
In brief, all option codes are described with the following generic
language:
option [new_name] code [new_code] = [definition] ;
Where [new_name] and [new_code] describe, respectively, how the
option will be labeled in the config file, and how the option will be
labeled in the DHCP wire format (the DHCP Option Code). This means
that later in configuration, the administrator may configure:
option [new_name] [values] ;
Where the format and number of [values] are determined by the
[definition] applied above. As an example then, an administrator
might configure:
option wpad code 252 = text ;
option wpad "http://my.example.com/my.wpad.file";
Site-Local Warning
Option Code 252 is within the 'Site-Local' [3] Option Space, and is
unsuitable for use as a fixed option in released software. It is
suitable only for allocation by Systems Administrators. It is
provided here solely as an example of common Administrative use of
this option space.
3.1.1. Boolean
Boolean values are simple true/false conditions. This fits with
several well known DHCP Options [2] which were intended to designate
wether a given behaviour should be engaged in, or not.
This format is configured with the [value] text "boolean".
For example, a commonly known DHCP Option [2] may be configured thus:
option ip-forwarding code 19 = boolean;
Such manual configuration for this option however is not necessary,
as it is encoded in a common table internally by default:
{ "ip-forwarding", "f", &dhcp_universe, 19 },
The second field of this table, "f", is this option's Format String.
'f' is the single-byte atom used to describe boolean values, but you
Hankins Expires March 5, 2007 [Page 5]
Internet-Draft Atomic DHCP September 2006
might also see 'F', which is a special-case boolean value that is
implied to always be true (regardless of value). Actual uses for 'F'
are not known outside of the kludges for which it was necessary to
create internally to software, and so there is no configuration
language to specify one.
On the wire, a boolean is encoded as a single octet. A value of 0 is
encoded to impart a false condition, a value of 1 is encoded to
impart a truth condition.
In configuration language, boolean values are encoded in ASCII using
the strings "true", "false", "enable", or "disable". For example:
option ip-forwarding disable;
When presented, only the ASCII strings "true" or "false" are used.
It should be stressed that although ISC DHCP encodes values of 0 and
1 to indicate false and truth, any non-zero value read from a DHCP
Option will be taken to indicate truth (the least significant bit is
not the only bit checked).
3.1.2. Integers
One of the easiest values to encode in an option are fixed length
binary integers in network byte order. So long as by fixed-length
you mean 8, 16, or 32 bits in length. Both 'unsigned' and 'signed'
(two's compliment) values are possible, and an author should note
which is intended (or else leave this open to site-local defaults or
interpretation).
These formats are configured with the [value] text:
[unsigned/signed] integer [8/16/32]
For example, some commonly known DHCP Options [2] may be configured
thus:
option time-offset code 2 = signed integer 32;
option default-ip-ttl code 23 = unsigned integer 8;
option interface-mtu code 26 = unsigned integer 16;
option arp-cache-timeout code 36 = unsigned integer 32;
But obviously such manual configuration is not necessary; these are
provided internally by default in a common table:
Hankins Expires March 5, 2007 [Page 6]
Internet-Draft Atomic DHCP September 2006
{ "time-offset", "l", &dhcp_universe, 2 },
{ "default-ip-ttl", "B", &dhcp_universe, 23 },
{ "interface-mtu", "S", &dhcp_universe, 26 },
{ "arp-cache-timeout", "L", &dhcp_universe, 35 },
Note the 'l', 'B', 'S', and 'L' values. These are 'format strings',
and are the software's internal language to describe an option's
Atomic structure. The actual full spectrum of single-byte Atoms is
'b', 'B', 's', 'S', 'l' and 'L'. Each of these describing the signed
and unsigned variants of 1, 2, and 4-octet integers.
On the wire, each of these integers is encoded in binary in least
significant order ("network byte order"). Signed integers are
encoded in twos-compliment.
Regardless of their bit width or sign type, all of these options are
configured and displayed similarly in ASCII strings.
Administrators may configure values for these integer options using
any decimal notation. Octal, hexadecimal, and base-10 are presently
supported, and might appear as so:
option time-offset -480; # base-10 decimal
option default-ip-ttl 0x7F; # hexadecimal
option interface-mtu 1500; # base-10 decimal
option arp-cache-timeout 0666; # octal
Once the option atom is received by a DHCP process and formatted to
be presented, it is always presented in base-10 decimal, as an ASCII
string, similarly to the above two base-10 examples. Wether the
value is signed or unsigned determines the range of positive and
negative values that might be produced.
3.1.3. IP Addresses
Where would DHCP be without IP Addresses?
An IPv4 address can be configured with the [value] text "ip-address".
For IPv6 addresses, it is "ip6-address".
For example, some commonly known DHCP Options [2] and DHCPv4 Options
[4] may be configured thus:
option dhcp.subnet-mask code 1 = ip-address;
option dhcp6.unicast code 12 = ip6-address;
But such manual configuration is not necessary, of course, because
Hankins Expires March 5, 2007 [Page 7]
Internet-Draft Atomic DHCP September 2006
the options' format are encoded in a common table internally to the
software by default:
{ "subnet-mask", "I", &dhcp_universe, 1 },
{ "unicast", "6", &dhcpv6_universe, 12, 1 },
The single-byte atom 'I' is used internally to describe an IPv4
address, and '6' for IPv6 addresses.
On the wire, the value is a 4-octet binary representation of an IPv4
address, or a 16-octet binary representation of an IPv6 address.
Although configuration via hexadecimal, octal, or even decimal is
permisslbe, the most common and appropriate configuration language
for IPv4 addresses is "dotted quads." ASCII strings of four base-10
decimal numbers separated by ASCII '.' symbols.
IPv6 uses a similar mechanism involving colons segregating 16-bit
fields, and a mechanism to encode repeating zeroes.
For example:
option dhcp.subnet-mask 255.255.255.0;
option dhcp6.unicast fe80::1;
Similarly, both address atoms are presented to applications in the
same format - as text strings encoded as above.
3.1.4. Text and Strings
Although 'text' and 'strings' are generally interchangeable words,
they have been overloaded to indicate specific formatting intents.
Text, then, is defined to mean an NVT-ASCII string. That is, a
number of ASCII "printable" 1-octet characters, and no zero ("NULL")
terminating octet.
Meanwhile, 'string' characterizes a chain of octets that may
represent an ASCII 'printable' string ("text"), but possibly may not,
and would be better served by being described as an opaque field of
octets.
Text and String formats are configured with the [value] texts of
"text" and "string" respectively.
For example, some commonly known DHCP Options [2] may be configured
thus:
Hankins Expires March 5, 2007 [Page 8]
Internet-Draft Atomic DHCP September 2006
option host-name code 12 = text;
option dhcp-client-identifier code 61 = string;
But of course, neither of these manual configurations are necessary,
as these options formats are encoded in a common table internally to
the software by default:
{ "host-name", "t", &dhcp_universe, 12 },
{ "dhcp-client-identifier", "X", &dhcp_universe, 61 },
Note the 't' and 'X' bytes, which form these options Format Strings.
Note also that the 'X' format is the default format for all presently
unknown, undocumented or unused option codes.
Either text or string values can be configured using quoted ASCII
strings, or hexadecimal chains of octets. For example, the above two
options may be configured thus:
option host-name "kaboom";
option dhcp-client-identifier 01:00:80:fc:55:4d:13;
When presented, 'text' values are always emitted as printable ASCII
strings. 'string' values are examined first. If they include only
printable ASCII characters, they are provided as such. If they
include any non-printable characters, they are provided in ASCII as
hexadecimal chains of octets, identical to how the client-identifier
option was configured above.
It should be mentioned that 'text' types are subject to additional
processing. RFC2131 [1] explicitly instructs implementations to
strip trailing NULL values from NVT-ASCII strings in the event they
are encountered...and so these values will be removed when the option
is processed from the packet. Also, some specific client
implementations that are known to misbehave when not presented with
NULL terminations on text values are catered to. When this
limitation is detected (generally by sensing that the client supplied
its host-name with null termination), all text options output to the
client are null terminated.
Note that both of these formats are of indeterminable length (they
both lack any form of termination). As such they may only appear
last on a chain of Atoms, as any next atom would be impossible to
sense the start of.
3.1.5. Encapsulation
Sometimes also called 'Sub-Options', encapsulated options are any
condition where DHCP-mimicing option formats are placed inside DHCP
Hankins Expires March 5, 2007 [Page 9]
Internet-Draft Atomic DHCP September 2006
Option contents.
To support such Encapsulation, the server must first present an
alternative 'site option space', the device that maps the
Encapsulated option codes into sub-option names.
The [value] text for an Encapsulated option is:
encapsulate "[option-space-name]"
But this is an incomplete description of how to configure
encapsulated options. So, here is an example of a Vendor
Encapsulated Option [2]:
option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-oport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option PXE.discovery-control code 6 = unsigned integer 8;
option PXE.discovery-mcast-addr code 7 = unsigned integer 8;
class "pxeclients" {
match if substring(option vendor-class-identifier, 0,
9) = "PXEClient";
vendor-option-space PXE;
}
# Alternatively:
#option vendor-encaps code 43 = encapsulate PXE;
In the above example, manual configuration is necessary, because it
is impossible (and possibly improper) for the internal tables to
document all possible Vendor-Specific interpretations of option code
43, Vendor Encapsulated Options.
Multiple Vendor-Encapsulated spaces may be supported by utilizing the
vendor-option-space configuration directive. This automatically
aliases the configured option space into the option 43 encapsulation,
as exampled above, if there is some good reason to think the client
will use it. Obviously, only one option space is used to form option
contents on the wire.
For other options (or to not support multiple vendor option spaces),
an option code may be explicitly defined to consume a specific option
space.
Hankins Expires March 5, 2007 [Page 10]
Internet-Draft Atomic DHCP September 2006
In other examples, however, manual configuration is not necessary,
because they've been described by an RFC and have a standard format.
So they can be included in the software's default internal tables,
for example:
{ "nwip-suboptions", "Enwip.", &dhcp_universe, 63 },
The 'E' byte indicates the format of the option is encapsulated
options. The following bytes up to the '.' byte indicate the name of
the option space to be used for encapsulation. How this option space
is configured to have a name that is meaningful is unimportant, but
within that option space the NWIP Sub Options [5] may be defined:
{ "nsq-broadcast", "f", &nwip_universe, 5 },
{ "preferred-dss", "IA", &nwip_universe, 6 },
{ "nearest-nwip-server", "IA", &nwip_universe, 7 },
{ "autoretries", "B", &nwip_universe, 8 },
{ "autoretry-secs", "B", &nwip_universe, 9 },
{ "nwip-1-1", "f", &nwip_universe, 10 },
{ "primary-dss", "I", &nwip_universe, 11 },
On the wire, an encapsulated option itself contains DHCP-like sub-
options. That is, single code bytes, single length bytes, followed
by that number of octets. The meaning and format of those octets
depends upon the definition in the encapsulated option space.
One doesn't normally configure an encapsulated option...rather one
configures the encapsulated option space, in the format specific to
each option in that space. But if one did, one would use a colon-
separated hexadecimal string. Examples:
option PXE.mtftp-ip 0.0.0.0;
# Alternatively.
#option vendor-encapsulated-options 01:04:00:00:00;
option nwip.nsq-broadcast true;
option nwip.nearest-nwip-server 10.0.0.1;
# Alternatively.
#option nwip-suboptions 05:01:01:07:04:0A:00:00:01;
One also doesn't normally present an encapsulated option...rather one
consumes the individual option from its option space, and so that
option is presented depending upon its specific format. But if you
did, likewise to configuring, it would be presented as a colon-
separated hexadecimal string.
Hankins Expires March 5, 2007 [Page 11]
Internet-Draft Atomic DHCP September 2006
For each suboption, you can look at presentation examples elsewhere
in this document. For whole-option consumption however, it would
look (identically as above) like so:
01:04:00:00:00:00
05:01:01:07:04:0A:00:00:01
3.1.6. Domain Names
DNS Domain Names are commonly transported in both DHCPv4 and DHCPv6
for many different purposes, and in a variety of formats. They are
also configured by the user and require DHCP software to perform DNS
requests.
Most DHCPv4 options are encoded using the 't' atom, as simple text
strings. One DHCpv4 option, the Domain Search List [6] option,
encodes a list of domain names in RFC1035 [7] "compressed" format
(compression pointers are relative to the start of the individual
optoin's contents).
Meanwhile, DHCPv6 [4] clearly illustrates that while RFC1035 [7]
format for domain names is to be used, compression pointers are not
to be utilized.
In the interests of reusing code and simplicity overall, these are
both combined into the 'D' atom. The presence or lack of compression
is illustrated by the 'c' flag to this atom.
When the compression flag is present, the software will produce
fields on-the-wire that contain compression pointers. Without this
flag, they simply list domain names one after the other. Both with
and without the flag, any compression pointers found within fields
found on the wire will be evaluated against the contents of the
option in question.
Both formats might be configured using the following syntax:
# DHCPv4 domain-search option.
option dhcp.domain-search code 119 = domain-list compressed;
# DHCPv6 sip-servers dns names option.
option dhcp6.sip-servers-names code 21 = domain-list;
And are configured by default within sources as:
{ "domain-search", "Dc", &dhcp_universe, 119, 1 },
Hankins Expires March 5, 2007 [Page 12]
Internet-Draft Atomic DHCP September 2006
{ "sip-servers-names", "D", &dhcpv6_universe, 21, 1 },
Administrators configure these values as a quoted list of strings:
option dhcp.domain-search "apple.com", "eng two.apple.com";
option dhcp6.sip-servers-names "sip1.example.com",
"sip2.example.com";
On the wire, they will appear as RFC1035 [7] formatted strings of
labels, including root labels. The "Dc" option will appear with
compression pointers as applicable.
In taking these option off the wire, it depends upon their intended
use in how they will appear.
If the option is intended to be stored in a machine-readable location
where configuration state can be cached (the 'dhclient.leases' file),
they are represented the same way as they are configured above, and
are octally escaped as necessary for software configuration language.
If the option is going to be emitted to another application, or
written into eg /etc/resolv.conf, then the option is flattened into a
text string, separated by spaces, and each label is decimal-escaped
as neccessary:
apple.com. eng\032two.apple.com.
sip1.example.com. sip2.example.com.
Note the doamin-search example that contains a space in one label.
3.1.7. Making Arrays
Once you have constructed an option that contains one configuration
value:
# Contains source and destination addresses.
option strawman.strawgirl code 5 = ip-address, ip-address;
You might want to allow more than one such value be configured. To
do this, we make an array out of the existing configuration atoms,
essentially allowing it to repeat itself.
Any atom that is already of indeterminate length (such as 't', 'x',
or 'D' atoms) is illegal in arrays.
To turn our example into an array, we simply change the syntax
slightly, depending on what you're after:
Hankins Expires March 5, 2007 [Page 13]
Internet-Draft Atomic DHCP September 2006
# A list of source/dest addresses.
option srawman.strawgirl code 5 =
array of ip-address, ip-address;
# One source address and a list of dest addresses.
option srawman.strawgirl code 5 =
ip-address, array-of ip-address;
Here we see that the first option requires that any legal value be a
multiple of two addresses. Each discrete configuration item is one
pair of addresses. In the second example, we see that the option
must only be a multiple of four in length, and contain at least two
addresses.
Arrays are entered into configuration language using commas to
delineate between fields, as exampled above. On the wire, each
individual atom of each type, whatever it be, is concatenated to
produce the wire format.
The presentation format to the user again depends on each individual
atom's presentation, and is merely concatenated together with spaces
and/or commas inbetween.
3.2. Molecular Assembly
3.2.1. Configuring Format Strings
Think carefully about the data you need to impart between DHCP
speaking systems (be it between servers or clients or relays). Put
all of the fixed-length values at the top. Put all the variable-
length values at the end.
If there are more than one variable-length value, you may either
choose to switch to an Encapsulated-Options scheme (recommended) or
you may also choose to encode the new variable length values with
length bytes (note that this essentially is what Encapsulated options
do).
Are any of the fields within your option of variable format? That
is, must you digest the option contents in order to understand the
rest of the option? Again, this is another excellent candidate for
Encapsulated Options schemes. Sure, from a protocol standpoint it
works to encode the format of the option within the option, it is not
impossible to decode or encode this. But, since your encoding-du-
jour has probably not been done before, it's unlikely that any
implementation will have the tools already developed. Special-case
code must then be created.
Hankins Expires March 5, 2007 [Page 14]
Internet-Draft Atomic DHCP September 2006
Now, look at the option you have created, and the order in which the
data fields appear. Is it reasonable to ask a systems administrator
to type imaginable values for each field, as though into a
configuration file or similar means? At some end in the DHCP
equation, it must be typed into configuration by a human, and it must
be digested by the application you have in mind.
3.2.2. Illegal Combinations
The basic rule of thumb for an illegal combination is that only one
undefined size Atom is allowed, at the end of the option. That is to
say, the format string "dt" would be illegal, because there is no way
to distinguish when the 'd' Atom stops and where the 't' Atom starts.
Likewise, 'tA' would be illegal because it's not possible to create
an array of Atoms whose size themself is undefined.
3.2.3. Legal Combinations
The single most compilcated format string deployed in the server
today is "fto". A perfectly legal syntax, because it does not
combine multiple variable length Atoms, but rather makes a single
variable length Atom's presence optional.
The FQDN Option, as an example, is substantially more complicated,
but needfully so. In order to support this option, a DHCP server
must itself be advanced enough to support Dynamic DNS. It is a
machine-generated, machine-consumed option. It is unreasonable to
ask a human to configure the flags fields and contents of the option.
So, the FQDN Option, as an example, has been implemented with a form
of virtual Encapsulation. That is, it is treated like an
Encapsulated option in the way user configuration interacts with it,
but special-case functions assemble the saved option caches into an
FQDN-Option-Formatted field when the time comes.
But, if you were going to configure it with Atoms, it would be done
something like "BBBd".
Think on that. If your DHCP Option substantially more complicated
than this? If so, needfully so? Wether or not your option can be
quickly and easily configured using the Atomic syntax I've introduced
here determines not only your chances of having your option included
in future software releases, but also wether or not your option will
be usable immediately on the DHCP Servers deployed in the field
today. That is, DHCP Servers running today's software, which only
allows a Systems Administrator to configure the Atoms outlined here.
That means if your option doesn't fit, they're going to wind up
Hankins Expires March 5, 2007 [Page 15]
Internet-Draft Atomic DHCP September 2006
configuring your option by hand in hex! Is that a barrier to the
adoption of your option?
4. Lessons Learned
4.1. Conditional Formatting is Hard
Options that include values that determine conditionally how the rest
of the option contents are to be interpreted are hard to implement:
they are always special cases that must be engineered for
individually.
4.2. Its Probably Been Done
Before creating your option, take some time to review the bulk of the
DHCP options contained in RFC2132 [2] and later works, and look for
any similarities to what you're trying to accomplish.
Redoing what's been done in a contrived or better way is admirable,
but is unlikely to get your option implemented quickly. Emulating
what's already been done advances your chances that implementors can
simply reuse code.
4.3. Keep It Simple, Stupid
Even if that means ignoring the above advice. It may be that the
option is only going to be processed by machines, which when
implemented are going to have to understand its specific format
anyway. In such a case, seek implementation simplicity.
5. Security Considerations
Do not split DHCP Atoms. Leading scientists have measured the amount
of energy it takes to form a single DHCP Atom as approaching infinite
(at least, it is not measurable by any science we possess today).
The entirety of this energy would be released at once in the event a
DHCP Atom was split. It would be bad.
6. Acknowledgements
The implementation described herein was written by Ted Lemon in
cooperation with Nominum, Inc. Without this contribution to the
public benefit, neither the implementation nor this document would be
possible.
Hankins Expires March 5, 2007 [Page 16]
Internet-Draft Atomic DHCP September 2006
7. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[3] Volz, B., "Reclassifying Dynamic Host Configuration Protocol
version 4 (DHCPv4) Options", RFC 3942, November 2004.
[4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003.
[5] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
RFC 2242, November 1997.
[6] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol
(DHCP) Domain Search Option", RFC 3397, November 2002.
[7] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
Hankins Expires March 5, 2007 [Page 17]
Internet-Draft Atomic DHCP September 2006
Author's Address
David W. Hankins
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA
US
Phone: +1 650 423 1307
Email: David_Hankins@isc.org
Hankins Expires March 5, 2007 [Page 18]
Internet-Draft Atomic DHCP September 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hankins Expires March 5, 2007 [Page 19]
