draft-ietf-dhc-option-guidelines-05.txt   draft-ietf-dhc-option-guidelines-06.txt 
Dynamic Host Configuration Working D. Hankins Dynamic Host Configuration Working D. Hankins
Group ISC Group ISC
Internet-Draft February 24, 2009 Internet-Draft March 5, 2010
Intended status: Informational Intended status: Informational
Expires: August 28, 2009 Expires: September 6, 2010
Guidelines for Creating New DHCP Options Guidelines for Creating New DHCP Options
draft-ietf-dhc-option-guidelines-05 draft-ietf-dhc-option-guidelines-06
Abstract
This document seeks to provide guidance to prospective DHCP Option
authors, to help them in producing option formats that are easily
adoptable.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2009. This Internet-Draft will expire on September 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Abstract the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document seeks to provide guidance to prospective DHCP Option
authors, to help them in producing option formats that are easily
adoptable.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. When to Use DHCP . . . . . . . . . . . . . . . . . . . . . . . 3 2. When to Use DHCP . . . . . . . . . . . . . . . . . . . . . . . 3
3. General Principles . . . . . . . . . . . . . . . . . . . . . . 4 3. General Principles . . . . . . . . . . . . . . . . . . . . . . 4
4. Reusing Other Options . . . . . . . . . . . . . . . . . . . . 5 4. Reusing Other Options . . . . . . . . . . . . . . . . . . . . 5
5. Conditional Formatting is Hard . . . . . . . . . . . . . . . . 7 5. Conditional Formatting is Hard . . . . . . . . . . . . . . . . 7
6. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 7
7. New Formats . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. New Formats . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. The Dangers of Sub Options . . . . . . . . . . . . . . . . . . 8 8. The Dangers of Sub Options . . . . . . . . . . . . . . . . . . 8
9. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Clients Request their Options . . . . . . . . . . . . . . . . 11 10. Clients Request their Options . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. Informative References . . . . . . . . . . . . . . . . . . . . 12 13. Informative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Background on ISC DHCP . . . . . . . . . . . . . . . 15 Appendix A. Background on ISC DHCP . . . . . . . . . . . . . . . 15
A.1. Atomic DHCP . . . . . . . . . . . . . . . . . . . . . . . 16 A.1. Atomic DHCP . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Most protocol developers ask themselves if a protocol will work, or Most protocol developers ask themselves if a protocol will work, or
work efficiently. These are important questions, but another less work efficiently. These are important questions, but another less
frequently considered question is whether the proposed protocol frequently considered question is whether the proposed protocol
presents itself needless barriers to adoption by deployed software. presents itself needless barriers to adoption by deployed software.
DHCPv4 [RFC2131] and DHCPv6 [RFC3315] software implementors are not DHCPv4 [RFC2131] and DHCPv6 [RFC3315] software implementors are not
merely faced with the task of a given option's format on the wire. merely faced with the task of a given option's format on the wire.
The option must "fit" into every stage of the system's process, which The option must "fit" into every stage of the system's process, from
includes user interface considerations. To help understand the the user interface where configuration is entered to the machine
interfaces where configuration is consumed. To help understand the
potential implementation challenges of any new DHCP Option, one potential implementation challenges of any new DHCP Option, one
implementation's approach to tackling DHCP Option formats implementation's approach to tackling DHCP Option formats
(Appendix A) has been included as an Appendix. (Appendix A) has been included as an Appendix.
Another more frequently overlooked aspect of rapid adoption is the Another more frequently overlooked aspect of rapid adoption is the
question: Would the option would require operators to be intimately question: Would the option would require operators to be intimately
familiar with the option's internal format in order to make use of familiar with the option's internal format in order to make use of
it? Most DHCP software provides a facility for "unknown options" at it? Most DHCP software provides a facility for "unknown options" at
the time of publication to be configured by hand by an operator. But the time of publication to be configured by hand by an operator. But
if doing so requires extensive reading (more than can be covered in a if doing so requires extensive reading (more than can be covered in a
skipping to change at page 3, line 38 skipping to change at page 3, line 39
So although a given solution would work, and might even be space, So although a given solution would work, and might even be space,
time, or aesthetically optimal, a given option is presented with a time, or aesthetically optimal, a given option is presented with a
series of ever-worsening challenges to be adopted; series of ever-worsening challenges to be adopted;
o If it doesn't fit neatly into existing config files. o If it doesn't fit neatly into existing config files.
o If it requries new source code changes to be adopted, and hence o If it requries new source code changes to be adopted, and hence
upgrades of deployed software. upgrades of deployed software.
o If it does not share its deployment fate in a general manner with o If it does not share its deployment fate in a general manner with
other options, creating a pressing need for code changes, or other options, standing alone in requiring code changes, or
reworking configuration file syntaxes. reworking configuration file syntaxes.
There are many things DHCP option authors can do to form DHCP Options There are many things DHCP option authors can do to form DHCP Options
to stay off this list entirely, or failing that, to make software to stay off this list entirely, or failing that, to make software
implementors lives easier and improve its chances for widespread implementors lives easier and improve its chances for widespread
adoption. adoption.
2. When to Use DHCP 2. When to Use DHCP
Principally, DHCP carries configuration parameters for its clients. Principally, DHCP carries configuration parameters for its clients.
skipping to change at page 4, line 14 skipping to change at page 4, line 15
The presence of such a knob isn't enough, because DHCP also presents The presence of such a knob isn't enough, because DHCP also presents
the extension of an administrative domain - the operator of the the extension of an administrative domain - the operator of the
network to which the client is currently attached. Someone runs not network to which the client is currently attached. Someone runs not
only the local switching network infrastructure that the client is only the local switching network infrastructure that the client is
directly (or wirelessly) attached to, but the various methods of directly (or wirelessly) attached to, but the various methods of
accessing the external Internet via local assist services that accessing the external Internet via local assist services that
network must also provide (such as domain name servers, or routers). network must also provide (such as domain name servers, or routers).
This means that in addition to the existence of a configuration This means that in addition to the existence of a configuration
parameter, one must also ask themselves if it is reasonable for this parameter, one must also ask themselves if it is reasonable for this
parameter to be set by some DHCP server operators, which roughly parameter to be set by the directly attached network's
translates to the local network administrator. administrators.
Bear in mind that the client still reserves the right to ignore Bear in mind that the client still reserves the right to ignore
values received via DHCP (for example, due to having a value manually values received via DHCP (for example, due to having a value manually
configured by its own operator), and that at least one main use case configured by its own operator), and that at least one main use case
for DHCP is the corporate enterprise. So even if the local Net for DHCP is the corporate enterprise. So even if the local Net
Cafe's operator is not a likely source of the candidate Cafe's operator is not a likely source of the candidate
configuration, there may be other DHCP servers in a client's lifetime configuration, there may be other DHCP servers in a client's lifetime
which are. which are.
3. General Principles 3. General Principles
skipping to change at page 5, line 36 skipping to change at page 5, line 36
+---------------+-------+-------------------------------------------+ +---------------+-------+-------------------------------------------+
| ipv4-address | 4 | Default gateway, requested address, | | ipv4-address | 4 | Default gateway, requested address, |
| | | subnet mask [RFC2132], addresses of | | | | subnet mask [RFC2132], addresses of |
| | | servers ([RFC2132], [RFC2241], [RFC2242], | | | | servers ([RFC2132], [RFC2241], [RFC2242], |
| | | [RFC3495], [RFC3634], [RFC4174]), as a | | | | [RFC3495], [RFC3634], [RFC4174]), as a |
| | | component in a list of routes [RFC3442]. | | | | component in a list of routes [RFC3442]. |
| ipv6-address | 16 | DHCPv6 server unicast address [RFC3315], | | ipv6-address | 16 | DHCPv6 server unicast address [RFC3315], |
| | | addresses of servers ([RFC3319], | | | | addresses of servers ([RFC3319], |
| | | [RFC3646], [RFC3898], [RFC4075], | | | | [RFC3646], [RFC3898], [RFC4075], |
| | | [RFC4280]). | | | | [RFC4280]). |
| 32-bit | 4 | Signed or unsigned varieties. Used for | | 32-bit | 4 | Signed or unsigned varieties. Used for |
| integer | | timezone time offset [RFC2132] | | integer | | timezone time offset [RFC2132] |
| | | (deprecated by [RFC4833]). Other uses for | | | | (deprecated by [RFC4833]). Other uses |
| | | host configuration values such as path | | | | for host configuration values such as |
| | | MTU aging timeouts, ARP cache timeouts, | | | | path MTU aging timeouts, ARP cache |
| | | TCP keepalive intervals [RFC2132]. Also | | | | timeouts, TCP keepalive intervals |
| | | used by the DHCPv4 protocol for relative | | | | [RFC2132]. Also used by the DHCPv4 |
| | | times, and times since epoch. | | | | protocol for relative times, and times |
| | | since epoch. |
| 16-bit | 2 | Client configuration parameters, such as | | 16-bit | 2 | Client configuration parameters, such as |
| integer | | MTU, maximum datagram reassembly limits, | | integer | | MTU, maximum datagram reassembly limits, |
| | | the DHCPv4 maximum message size | | | | the DHCPv4 maximum message size |
| | | [RFC2132], or the elapsed time option | | | | [RFC2132], or the elapsed time option |
| | | [RFC3315] in DHCPv6. | | | | [RFC3315] in DHCPv6. |
| 8-bit integer | 1 | Used for host configuration parameters, | | 8-bit integer | 1 | Used for host configuration parameters, |
| | | such as the default IP TTL, default TCP | | | | such as the default IP TTL, default TCP |
| | | TTL, NetBIOS node type [RFC2132]. Also | | | | TTL, NetBIOS node type [RFC2132]. Also |
| | | used for protocol features, such as the | | | | used for protocol features, such as the |
| | | DHCPv4 Option Overload (as flags), DHCP | | | | DHCPv4 Option Overload (as flags), DHCP |
| | | Message Type (as an enumeration) or | | | | Message Type (as an enumeration) or |
| | | DHCPv6 Preference [RFC3315]. | | | | DHCPv6 Preference [RFC3315]. |
| NVT-ASCII | unlim | This is the kitchen sink of common | | NVT-ASCII | unlim | This is the kitchen sink of common |
| Text | | fragments. Common uses are for filenames | | Text | | fragments. Common uses are for filenames |
| | | (such as TFTP paths), host or domain | | | | (such as TFTP paths), host or domain |
| | | names (but this should be discouraged), | | | | names (but this should be discouraged), |
| | | or protocol features such as textual | | | | or protocol features such as textual |
| | | messages such as verbose error | | | | messages such as verbose error |
| | | indicators. Since the size of this format | | | | indicators. Since the size of this |
| | | cannot be determined (it is not NULL | | | | format cannot be determined (it is not |
| | | terminated), it consumes any remaining | | | | NULL terminated), it consumes any |
| | | space in the option. | | | | remaining space in the option. |
| DNS Wire | unlim | Presently used for 'domain search' lists | | DNS Wire | unlim | Presently used for 'domain search' lists |
| Format Domain | | in both DHCPv4 [RFC3397] and DHCPv6 | | Format Domain | | in both DHCPv4 [RFC3397] and DHCPv6 |
| Name List | | [RFC3646], but also used in DHCPv6 for | | Name List | | [RFC3646], but also used in DHCPv6 for |
| [RFC1035] | | any host or domain name. A field | | [RFC1035] | | any host or domain name. A field |
| | | formatted this way may have a determinate | | | | formatted this way may have a determinate |
| | | length if the number of root labels is | | | | length if the number of root labels is |
| | | limited, but use of this format as being | | | | limited, but use of this format as being |
| | | a determinate length should be | | | | a determinate length should be |
| | | discouraged in DHCPv4, less so in DHCPv6. | | | | discouraged in DHCPv4, less so in DHCPv6. |
| 'suboption' | unlim | The Relay Agent Information Option | | 'suboption' | unlim | The Relay Agent Information Option |
| encapsulation | | [RFC3046], vendor options [RFC2132], | | encapsulation | | [RFC3046], vendor options [RFC2132], |
| | | Vendor Identified Vendor SubOptions | | | | Vendor Identified Vendor SubOptions |
| | | ([RFC3925], [RFC3315]). Commonly used for | | | | ([RFC3925], [RFC3315]). Commonly used |
| | | situations where the full format cannot | | | | for situations where the full format |
| | | be known initially, such as where there | | | | cannot be known initially, such as where |
| | | seems to be some room for later protocol | | | | there seems to be some room for later |
| | | work to expand the amount of information | | | | protocol work to expand the amount of |
| | | carried, or where the full extent of data | | | | information carried, or where the full |
| | | carried is defined in a private | | | | extent of data carried is defined in a |
| | | specification (such as with vendor | | | | private specification (such as with |
| | | options). Encapsulations do not use 'PAD' | | | | vendor options). Encapsulations do not |
| | | and 'END' options in DHCPv4, and there | | | | use 'PAD' and 'END' options in DHCPv4, |
| | | are no such options in DHCPv6, so this | | | | and there are no such options in DHCPv6, |
| | | format also is of indeterminate length. | | | | so this format also is of indeterminate |
| | | length. |
+---------------+-------+-------------------------------------------+ +---------------+-------+-------------------------------------------+
Table 1: Common Option Fragments Table 1: Common Option Fragments
The easiest approach to manufacturing trivially deployable DHCP The easiest approach to manufacturing trivially deployable DHCP
Options is to assemble the option out of whatever common fragments Options is to assemble the option out of whatever common fragments
fit - possibly allowing a group of fragments to repeat to fill the fit - possibly allowing a group of fragments to repeat to fill the
remaining space (if present) and so provide multiple values. Place remaining space (if present) and so provide multiple values. Place
all fixed size values at the start of the option, and any variable/ all fixed size values at the start of the option, and any variable/
indeterminate sized values at the tail end of the option. indeterminate sized values at the tail end of the option.
This estimates that implementations will be able to reuse code paths This estimates that implementations will be able to reuse code paths
designed to support the other options. designed to support the other options.
5. Conditional Formatting is Hard 5. Conditional Formatting is Hard
Placing a byte at the start of the option which informs the software Placing a byte at the start of the option which informs the software
how to process the remaining bytes of the option may appear simple to how to process the remaining bytes of the option may appear simple to
the casual observer. But the only conditional formatting methods the casual observer. But the only conditional formatting methods
that are in widepsread use today are 'protocol' class options. So that are in widespread use today are 'protocol' class options. So
conditional formatting requires new code to be written, as well as conditional formatting requires new code to be written, as well as
introduces an implementation problem; as it requires that all introduces an implementation problem; as it requires that all
speakers implement all current and future conditional formats. speakers implement all current and future conditional formats.
Conditional formatting is absolutely not recommended, except in cases Conditional formatting is absolutely not recommended, except in cases
where the DHCP option has already been deployed, and all but one where the DHCP option has already been deployed, and all but one
conditional format is deprecated. conditional format is deprecated.
6. Avoid Aliasing 6. Avoid Aliasing
skipping to change at page 8, line 11 skipping to change at page 8, line 12
operator (or other software on the machine) in a single field or operator (or other software on the machine) in a single field or
channel. If that channel has a natural format, then any alternative channel. If that channel has a natural format, then any alternative
formats merely make more work for intervening software in providing formats merely make more work for intervening software in providing
conversions. conversions.
So the best advice is to choose the one method that best fulfills the So the best advice is to choose the one method that best fulfills the
requirements, be that for simplicity (such as with an IP address and requirements, be that for simplicity (such as with an IP address and
port pair), late binding (such as with DNS), or completeness (such as port pair), late binding (such as with DNS), or completeness (such as
with a URL). with a URL).
On the specific subject of desiring to configure a value using a
Fully Qualified Domain Name instead of a binary IP address, note that
most DHCP server implementations will happily accept a Domain Name
entered by the administrator, and use DNS resolution to render binary
IP addresses in DHCP replies to clients. Consequently, consider the
extra packet overhead incurred on the client's end to perform DNS
resolution itself. The client may be operating on a battery and
packet transmission is a non-trivial use of power, and the extra RTT
delays the client must endure before the service is configured are at
least two factors to consider in making a decision on format.
7. New Formats 7. New Formats
If the Option simply will not fit into any existing work, the last If the option simply will not fit into any existing work by using
recourse is to create a new format to fit. fragments, the last recourse is to create a new format to fit.
When doing so, it is not enough to gauge whether or not the option When doing so, it is not enough to gauge whether or not the option
format will work in the context of the option presently being format will work in the context of the option presently being
considered. It is equally important to consider if the new format's considered. It is equally important to consider if the new format's
fragments might reasonably have any other uses, and if so, to create fragments might reasonably have any other uses, and if so, to create
the option with the foreknowledge that its parts may later become a the option with the foreknowledge that its parts may later become a
common fragment. common fragment.
One specific consideration to evaluate, is whether or not options of One specific consideration to evaluate is whether or not options of a
a similar format would need to have multiple or single values encoded similar format would need to have multiple or single values encoded
(whatever differs from the current option), and how that might be (whatever differs from the current option), and how that might be
accomplished in a similar format. accomplished in a similar format.
8. The Dangers of Sub Options 8. The Dangers of Sub Options
Some DHCP options, such as the DHCPv4 Relay Agent Information Option Some DHCP options, such as the DHCPv4 Relay Agent Information Option
[RFC3046] are defined to contain a series of DHCP options, possibly [RFC3046] are defined to contain a series of DHCP options, possibly
using code tags specific to that option (but not in some limited using code tags specific to that option (but not in some limited
"protocol feature" cases in DHCPv6 [RFC3315]). These are commonly "protocol feature" cases in DHCPv6 [RFC3315]). These are commonly
referred to as Encapsulated Option Spaces or more simply, Sub referred to as Encapsulated Option Spaces or more simply, Sub
Options. Options.
Sub options seem very attractive, because they allow the encoding of Sub options seem very attractive, because they allow the encoding of
multiple variable length fields within the single "parent" option. multiple variable length fields within the single "parent" option.
However, DHCP software will only include these options on an "all or However, DHCP software will only include these options on an "all or
nothing" basis, there is no well deployed mechanism for "Sub Option nothing" basis, there is no well deployed mechanism for "Sub Option
Parameter Request Lists", and the software will not include the Parameter Request Lists" (although some defined sub-option spaces,
entire option if there is not sufficient space for only the last sub- such as for DOCSIS, do describe sub-option scoped PRL analogues), and
option to fit in the DHCP packet. the software will not include the entire option if there is not
sufficient space.
Consequently, it is not advisable to group options that may not be Consequently, it is not advisable to group options that may not be
requested at the same time by the same client under an encapsulated requested at the same time by the same client under an encapsulated
space. space.
Another attraction sub options present is ease of extending the Another attraction sub options present is ease of extending the
configuration value for later, related configuration. This must be configuration value for later, related configuration. This must be
weighed against the cost associated with asking IANA to maintain the weighed against the cost associated with asking IANA to maintain the
space's internally assigned option codes. Generally, the cost to space's internally assigned option codes. Generally, the cost to
IANA is greater, as it is unlikely that most options will be later IANA is greater, as it is unlikely that options will be later
extended. extended.
The use of sub-options is not a solution to aliasing problems. Sub- The use of sub-options is not a solution to aliasing problems. Sub-
options that contain multiple configuration values that alias the options that contain multiple configuration values that alias the
same configuration element actually makes matters worse. The only same configuration element actually makes matters worse. The only
solution to aliasing problems is to select a single option format, or solution to aliasing problems is to select a single option format, or
where that is literally impossible, to use multiple DHCP options. In where that is literally impossible, to use multiple DHCP options. In
this way, clients may place only the options they support on their this way, clients may place only the options they support on their
parameter request list, in the order they support them. Later parameter request list, in the order they support them. Later
protocol maintenance may incorporate a means to select a single DHCP protocol maintenance may incorporate a means to select a single DHCP
option code out of a list of aliased options. option code out of a list of aliased options, so do not concern
yourself with packet space issues arising from receiving all the
aliases.
Additionaly, DHCPv4 option concatenation (described in detail below) Additionally, DHCPv4 option concatenation (Section 9) has not been
has not been defined in any DHCPv4 sub-options space. Currently defined in any DHCPv4 sub-options space. Currently there is some
there is some DHCP software which does concatenate multiple DHCP DHCP software which does concatenate multiple DHCP options present in
options present in a sub-option space. There is also software that a sub-option space. There is also software that treats multiple DHCP
treats multiple DHCP option codes present in a sub-option as option codes present in a sub-option as individual single options.
individual single options. So there is no reliably predictable So there is no reliably predictable default behaviour.
default behaviour.
Because no sub-options space has yet been defined that includes the Because no sub-options space has yet been defined that includes the
possibility of having more than one instance of an option of the same possibility of having more than one instance of an option of the same
code, any attempt to do so is discouraged. code, any attempt to do so is discouraged.
9. Option Size 9. Option Size
DHCPv4 [RFC2131] options payload space is limited, as there are a DHCPv4 [RFC2131] options payload space is limited, as there are a
number of unaddressed deployment problems with DHCPv4 packet sizes. number of unaddressed deployment problems with DHCPv4 packet sizes.
The end result is that you should build your option to the assumption The end result is that you should build your option to the assumption
skipping to change at page 9, line 48 skipping to change at page 10, line 15
the options payload space will be 312 bytes, which you will have to the options payload space will be 312 bytes, which you will have to
share with other options. This space can be extended by making use share with other options. This space can be extended by making use
of Option Overloading [RFC2132], which allows the use of the BOOTP of Option Overloading [RFC2132], which allows the use of the BOOTP
FILE and SNAME header fields for carrying DHCPv4 options (adding 192 FILE and SNAME header fields for carrying DHCPv4 options (adding 192
bytes), but these header fields will not be available for overloading bytes), but these header fields will not be available for overloading
if they have been configured to carry a value. if they have been configured to carry a value.
DHCPv6 [RFC3315] is much better off. First, through its use of link- DHCPv6 [RFC3315] is much better off. First, through its use of link-
local addresses, it steps aside many of the deployment problems that local addresses, it steps aside many of the deployment problems that
plague DHCPv4, and looks a great deal more like any other UDP based plague DHCPv4, and looks a great deal more like any other UDP based
application; oblivious to packet sizes up to 64KB. Second, RFC3315 application; oblivious to packet sizes up to 64KB. Second, RFC 3315
explicitly refers readers to RFC2460 Section 5, which describes an explicitly refers readers to RFC 2460 Section 5, which describes an
MTU of 1280 octets and a minimum fragment reassembly of 1500 octets. MTU of 1280 octets and a minimum fragment reassembly of 1500 octets.
It's much more feasible to suggest that DHCPv6 is capable of having It's much more feasible to suggest that DHCPv6 is capable of having
larger options deployed over it, and at least no common upper limit larger options deployed over it, and at least no common upper limit
is yet known to have been encoded by its implementors. It is is yet known to have been encoded by its implementors. It is
impossible to describe any fixed limit that cleanly divides those too impossible to describe any fixed limit that cleanly divides those too
big from the workable. big from the workable.
So in either protocol, it is advantageous to prefer option formats So in either protocol, it is advantageous to prefer option formats
which contain the desired information in the smallest form factor which contain the desired information in the smallest form factor
that solves the requirements. One example is to use a 4-octet IPv4 that solves the requirements. One example is to use a 4-octet IPv4
address rather than a fully qualified domain name, because many DHCP address rather than a fully qualified domain name, because many DHCP
skipping to change at page 10, line 24 skipping to change at page 10, line 37
address rather than a fully qualified domain name, because many DHCP address rather than a fully qualified domain name, because many DHCP
servers will perform DNS resolution on configured FQDN's (so the DNS servers will perform DNS resolution on configured FQDN's (so the DNS
recursive lookup is performed anyway). There may be motivations to recursive lookup is performed anyway). There may be motivations to
use the fully qualified domain name anyway, such as if the intended use the fully qualified domain name anyway, such as if the intended
RRSET is not an address, or if the client must refresh the name more RRSET is not an address, or if the client must refresh the name more
frequently than common lease renewal periods. frequently than common lease renewal periods.
When it is not possible to compress the configuration contents either When it is not possible to compress the configuration contents either
because of the simple size of the parameters, or because it is because of the simple size of the parameters, or because it is
expected that very large configurations are valid, it may be expected that very large configurations are valid, it may be
preferrable to use a second stage configuration. Some examples of preferable to use a second stage configuration. Some examples of
this are to provide TFTP server and pathnames, or a URL, which the this are to provide TFTP server and pathnames, or a URL, which the
client will load and process externally to the DHCP protocol. client will load and process externally to the DHCP protocol.
The DHCPv4 code and length tags are each a single byte. As the The DHCPv4 code and length tags are each a single byte. As the
length field describes the length of the DHCP option's contents (not length field describes the length of the DHCP option's contents (not
including the code and length bytes), any option whose contents' including the code and length bytes), any option whose contents'
length exceeds 255 bytes can not be contained in a single option. length exceeds 255 bytes can not be contained in a single option.
These 'long options' will simply be fragmented into multiple options These 'long options' will simply be fragmented into multiple options
within the packet. DHCP software processing these fragments will within the packet. DHCP software processing these fragments will
concatenate them, in the order they appear as defined by RFC2131 concatenate them, in the order they appear as defined by [RFC2131],
[RFC2131], prior to evaluating their contents. This is an important prior to evaluating their contents. This is an important distinction
distinction that is sometimes overlooked by authors - these multiple that is sometimes overlooked by authors - these multiple options are
options are not individually formatted precisely as you have defined, not individually formatted to convey one unit of information
but rather one option that has been split along any arbitrary point precisely as you have defined, but rather one option that has been
into multiple containers. When documenting an example, then, try to split along any arbitrary octet boundary into multiple containers.
make sure that the division point you select as an example does not When documenting an example, then, try to make sure that the division
lie on a clean division of your option contents - place it at an point you select as an example does not lie on a clean division of
offset so as to reinforce that these values must be concatenated your option contents - place it at an offset so as to reinforce that
rather than processed individually. these values must be concatenated rather than processed individually.
DHCPv4 option fragments are a basic protocol feature, so there DHCPv4 option fragments are a basic protocol feature, so there
usually is no reason to mention this feature in new option usually is no reason to mention this feature in new option
definitions, and no requirement for every option definition to be definitions, and no requirement for every option definition to be
presented as a series of fragments. It is only recommended to presented as a series of fragments. It is only recommended to
reinforce the existence of DHCP option fragmentation when the reinforce the existence of DHCP option fragmentation when the
potential for large options is likely. In this case, try to choose a potential for large options is likely. In this case, try to choose a
large example data value. large example data value.
Note that option fragmentation is also a very common side-effect of Note that option fragmentation is also a very common side-effect of
running out of options space, and moving to overloaded FILE or SNAME running out of options space, and moving to overloaded FILE or SNAME
fields. Although the option may be considerably shorter than 255 fields. Although the option may be considerably shorter than 255
bytes, if it does not fit in the remaining space then software may bytes, if it does not fit in the remaining space then software may
consume all remaining options space with one option fragment, and consume all remaining options space with one option fragment, and
place the remainder in an overloaded field. place the remainder in an overloaded field.
Primarily it is important to remember that DHCPv4 differs from DHCPv6
on this point: DHCPv4 can only convey one option of a given option
code at any time - additional options (or sub options) of the same
code will be concatenated together and processed at once. DHCPv6
does allow multiple instances of a given option, and they are treated
as distinct values following the defined format, however this feature
is generally preferred to be restricted to protocol class features
(such as the IA_* series of options); it is better to define your
option as an array if it is possible.
So remember that it is out of the question to define a case for
multiple instances of your option in DHCPv4, and it is recommended to
clarify (with normative language) if any DHCPv6 option may appear
once or multiple times.
10. Clients Request their Options 10. Clients Request their Options
The DHCPv4 Parameter Request List [RFC2132], and the DHCPv6 Option The DHCPv4 Parameter Request List [RFC2132], and the DHCPv6 Option
Request Option (OPTION_ORO) [RFC3315], are both options that serve Request Option (OPTION_ORO) [RFC3315], are both options that serve
two purposes - to inform the server what option(s) the client two purposes - to inform the server what options the client supports
supports and is willing to digest, and in what order of priority the and is willing to digest, and in what order of priority the client
client places those option contents (in the event that they will not places those option contents (in the event that they will not fit in
fit in the packet, later options are to be dropped). the packet, later options are to be dropped).
It doesn't make sense for some options to appear on this parameter It doesn't make sense for some options to appear on this Parameter
request list, such as those formed by elements of the protocol's Request List, such as those formed by elements of the protocol's
internal workings, or are formed on either end by DHCP-level software internal workings, or are formed on either end by DHCP-level software
engaged in some exchange of information. When in any form of doubt, engaged in some exchange of information. When in any form of doubt,
assume that any new option must be present on the relevant option assume that any new option must be present on the relevant option
request list if the client desires it. request list if the client desires it.
It is a frequent mistake of option draft authors, then, to create It is a frequent mistake of option draft authors, then, to create
text that implies that a server will simply provide the new option, text that implies that a server will simply provide the new option,
and clients will digest it. Generally, it's best to also specify and clients will digest it. Generally, it's best to also specify
that clients MUST place the new option code on the relevant list that clients MUST place the new option code on the relevant list
option, clients MAY include the new option in their packets to option, clients MAY include the new option in their packets to
skipping to change at page 16, line 30 skipping to change at page 17, line 10
This is still an intractable number of functions per each DHCP This is still an intractable number of functions per each DHCP
option, even without the entire DHCP option space populated. So, we option, even without the entire DHCP option space populated. So, we
need a way to reduce this to small orders. need a way to reduce this to small orders.
A.1. Atomic DHCP A.1. Atomic DHCP
To accomplish these goals, a common "Format String" is used to To accomplish these goals, a common "Format String" is used to
describe, in abstract, all of the above. Each byte in this format describe, in abstract, all of the above. Each byte in this format
string represents a "DHCP Atom". We chain these 'atoms' together, string represents a "DHCP Atom". We chain these 'atoms' together,
forming a sort of molecular structure for a particular DHCP Option. forming a sort of molecular structure for a particular DHCP option's
defined format.
The Configuration Syntax allows the user to construct such a format The Configuration Syntax allows the user to construct such a format
string without having to understand how the Atom is encoded on the string without having to understand how the Atom is encoded on the
wire, and how it is configured or presented. wire, and how it is configured or presented.
You can reasonably imagine that the various common formats of DHCP You can reasonably imagine that the various common formats of DHCP
options described above (Table 1) each have an Atom associated with options described above (Table 1) each have an Atom associated with
it. There are special use Atoms, such as one to repeat the previous it. There are special use Atoms, such as one to repeat the previous
Atoms indefinitely (for example, for options with multiple IPv4 Atoms indefinitely (for example, for options with multiple IPv4
addresses one after the other), and one which makes the previous Atom addresses one after the other), and one which makes the previous Atom
optional. optional.
As the software encounters a format string, it processes each Atom As the software encounters a format string, it processes each Atom
individually to read, formulate in memory, or write to output the individually to read from configuration into wire format, and also to
various option contents. validate and convert wire format into output format (which with some
small exclusions is identical to the configuration format).
The format strings themselves are either hard coded by the software The format strings themselves are either hard coded by the software
in a table of option definitions, or are compiled at runtime through in a table of option definitions, or are compiled at runtime through
configuration syntax generated by the operator. configuration syntax generated by the operator.
option <space>.<option> code <number> = <definition>; option <space>.<option> code <number> = <definition>;
The <space> refers to the option space, which may be the DHCPv4 The <space> refers to the option space, which may be the DHCPv4
option space, the DHCPv6 option space, or any suboption space such as option space, the DHCPv6 option space, or any suboption space such as
the DHCPv4 Relay Agent Information suboptions or similar. the DHCPv4 Relay Agent Information suboptions or similar.
skipping to change at page 17, line 30 skipping to change at page 18, line 14
option dhcp.path-mtu-plateau-table code 25 = option dhcp.path-mtu-plateau-table code 25 =
array of unsigned integer 16; array of unsigned integer 16;
option dhcp.static-routes code 33 = array of { ip-address, option dhcp.static-routes code 33 = array of { ip-address,
ip-address }; ip-address };
Once the options' syntax configuration is out of the way, values to Once the options' syntax configuration is out of the way, values to
be carried in the options may be configured. These acts are be carried in the options may be configured. These acts are
distinct; the previous configuration only prepares the parser system distinct; the previous configuration only prepares the parser system
to accept the configuration below. The below configuration actually to accept the configuration below. The below configuration actually
supplies a value to be transmitted on the wire. supplies a value to be transmitted on the wire, relying on the above
format definition.
option dhcp.path-mtu-plataeu-table 4352, 1500, 576; option dhcp.path-mtu-plataeu-table 4352, 1500, 576;
option dhcp.static-routes 10.10.10.10 10.10.10.9, option dhcp.static-routes 10.10.10.10 10.10.10.9,
10.10.10.11 10.10.10.9; 10.10.10.11 10.10.10.9;
Author's Address Author's Address
David W. Hankins David W. Hankins
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
950 Charter Street 950 Charter Street
 End of changes. 36 change blocks. 
89 lines changed or deleted 125 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/