draft-ietf-dhc-option-guidelines-00.txt   draft-ietf-dhc-option-guidelines-01.txt 
Dynamic Host Configuration Working D. Hankins Dynamic Host Configuration Working D. Hankins
Group ISC Group ISC
Intended status: Informational Intended status: Informational
Expires: January 2, 2008 Expires: February 22, 2009
Guidelines for Creating New DHCP Options Guidelines for Creating New DHCP Options
draft-ietf-dhc-option-guidelines-00 draft-ietf-dhc-option-guidelines-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 January 2, 2008. This Internet-Draft will expire on February 22, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2007).
94063
Abstract Abstract
This document seeks to provide guidance to prospective DHCP Option This document seeks to provide guidance to prospective DHCP Option
authors, to help them in producing option formats that are easily authors, to help them in producing option formats that are easily
adoptable. 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 . . . . . . . . . . . . . . . . . . . . 4 4. Reusing Other Options . . . . . . . . . . . . . . . . . . . . 4
5. Conditional Formatting is Hard . . . . . . . . . . . . . . . . 7 5. Conditional Formatting is Hard . . . . . . . . . . . . . . . . 7
6. Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. New Formats . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. New Formats . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Clients Request their Options . . . . . . . . . . . . . . . . 9 9. Clients Request their Options . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Background on ISC DHCP . . . . . . . . . . . . . . . 11 Appendix A. Background on ISC DHCP . . . . . . . . . . . . . . . 11
Appendix A.1. Atomic DHCP . . . . . . . . . . . . . . . . . . . . 12 Appendix A.1. Atomic DHCP . . . . . . . . . . . . . . . . . . . . 12
12. Informative References . . . . . . . . . . . . . . . . . . . . 13 12. Informative References . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17
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 is wether the proposed protocol presents itself frequently considered is whether the proposed protocol presents
needless barriers to adoption by deployed software. itself needless barriers to adoption by deployed software.
DHCPv4 [1] and DHCPv6 [2] software implementors are not merely faced DHCPv4 [RFC2131] and DHCPv6 [RFC3315] software implementors are not
with the task of a given option's format on the wire. The option merely faced with the task of a given option's format on the wire.
must 'fit' into every stage of the system's process, which includes The option must 'fit' into every stage of the system's process, which
user interface considerations. As an aide to understanding the includes user interface considerations. As an aide to understanding
potential implementation challenges of any new DHCP Option, one the 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 in an Appendix. (Appendix A) has been included in an Appendix.
Another, and more frequently overlooked, aspect of rapid adoption is Another, and more frequently overlooked, aspect of rapid adoption is
wether or not the option would require operators to be intimately whether or not 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
simple FAQ for example), it inhibits adoption. simple FAQ for example), it inhibits adoption.
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 going to have a time, or aesthetically optimal, a given option is going to have a
rough time being adopted by deployed software if it requires code rough time being adopted by deployed software if it requires code
changes. A rougher time still, if it does not share its deployment changes. A rougher time still, if it does not share its deployment
skipping to change at page 4, line 5 skipping to change at page 4, line 5
domain name servers", "my hostname", or even "my shutdown domain name servers", "my hostname", or even "my shutdown
temperature" are candidates for being configured by DHCP. temperature" are candidates for being configured by DHCP.
The presence of such a knob isn't enough, however, because The presence of such a knob isn't enough, however, because
secondarily, DHCP also presents the extension of an administrative secondarily, DHCP also presents the extension of an administrative
domain - that of the systems operator of the network to which the domain - that of the systems operator of the network to which the
client is currently attached. Someone runs not only the local client is currently attached. Someone runs not only the local
switching network infrastructure that the client is directly (or switching network infrastructure that the client is directly (or
wirelessly) attached to, but the various methods of accessing the wirelessly) attached to, but the various methods of accessing the
external Internet via local assist services that network must also external Internet via local assist services that network must also
provide (such as domain name servers, or routers). This means taht provide (such as domain name servers, or routers). This means that
in addition to the existence of a configuration parameter, one must in addition to the existence of a configuration parameter, one must
also ask themselves if it is reasoanble for this parameter to be set also ask themselves if it is reasoanble for this parameter to be set
by the DHCP server operator. by the DHCP server operator.
Bear in mind that the client still reserves the right to over-ride or Bear in mind that the client still reserves the right to over-ride or
ignore values received via DHCP (eg due to having a manually ignore values received via DHCP (for example, due to having a
configured value by its operator), and that at least one main use manually configured value by its operator), and that at least one
case for DHCP is the corporate enterprise - so even if the local Net main use case for DHCP is the corporate enterprise - so even if the
Cafe is not a suitable source of this configuration, it is likely local Net Cafe is not a suitable source of this configuration, it is
that the client will at some point return to a network whose operator likely that the client will at some point return to a network whose
is also the system's rightful master. operator is also the system's rightful master.
3. General Principles 3. General Principles
The primary principle to follow in order to enhance an option's The primary principle to follow in order to enhance an option's
adoptability is certainly simplification. But more specifically, to adoptability is certainly simplification. But more specifically, to
create the option in such a way that it should not require any new or create the option in such a way that it should not require any new or
special case software to support. If old software currently deployed special case software to support. If old software currently deployed
and in the field can adopt the option through supplied configuration and in the field can adopt the option through supplied configuration
conveniences then it's fairly well assured that new software can conveniences then it's fairly well assured that new software can
easily formally adopt it. easily formally adopt it.
There are at least two classes of DHCP options. A bulk class of There are at least two classes of DHCP options. A bulk class of
options which are provided explicitly to carry data from one side of options which are provided explicitly to carry data from one side of
the DHCP exchange to the other (such as nameservers, domain names, or the DHCP exchange to the other (such as nameservers, domain names, or
time servers), and a protocol class of options which require special time servers), and a protocol class of options which require special
processing on the part of the DHCP software or are used during processing on the part of the DHCP software or are used during
special processing (such as the FQDN options ([3], [4]), DHCPv4 special processing (such as the FQDN options ([RFC4702], [RFC4704]),
message type option [5], link selection options ([6], [7]), and so DHCPv4 message type option [RFC2132], link selection options
forth). ([RFC3011], [RFC3527]), and so forth).
The guidelines laid out here should be understood to be relaxed for The guidelines laid out here should be understood to be relaxed for
the protocol class of options. Wherever special-case-code is already the protocol class of options. Wherever special-case-code is already
required to adopt the DHCP option, it is substantially more required to adopt the DHCP option, it is substantially more
reasonable to format the option in a less generic fashion, if there reasonable to format the option in a less generic fashion, if there
are measurable benefits to doing so. are measurable benefits to doing so.
4. Reusing Other Options 4. Reusing Other Options
In DHCPv4, there are now nearly one hundred and thirty options, at In DHCPv4, there are now nearly one hundred and thirty options, at
least as IETF standards, which might be used as an example. There is least as IETF standards, which might be used as an example. There is
also one handy document [5] containing many option definitions. also one handy document [RFC2132] containing many option definitions.
Although some may not like the way an old option that solves a Although some may not like the way an old option that solves a
similar problem was approached, and it may waste space or processing similar problem was approached, and it may waste space or processing
time or have ugly characteristics, it can usually be said that time or have ugly characteristics, it can usually be said that
duplicating that which has already been adopted has the greatest duplicating that which has already been adopted has the greatest
chance of being adopted quickly and easily. chance of being adopted quickly and easily.
So it is preferrable to consider the bulk of DHCP options already So it is preferrable to consider the bulk of DHCP options already
allocated, and consider which of those solve a similar problem. It allocated, and consider which of those solve a similar problem. It
may even be that an option that solves the problem already exists. may even be that an option that solves the problem already exists.
skipping to change at page 5, line 26 skipping to change at page 5, line 26
terms of exampling every option format ever devised...it is only a terms of exampling every option format ever devised...it is only a
list of option format fragments which are used in two or more list of option format fragments which are used in two or more
options. options.
Common Option Fragments Common Option Fragments
+---------------+-------+-------------------------------------------+ +---------------+-------+-------------------------------------------+
| Fragment | Size | Types of Uses | | Fragment | Size | Types of Uses |
+---------------+-------+-------------------------------------------+ +---------------+-------+-------------------------------------------+
| ipv4-address | 4 | Default gateway, requested address, | | ipv4-address | 4 | Default gateway, requested address, |
| | | subnet mask [5], addresses of servers | | | | subnet mask [RFC2132], addresses of |
| | | ([5], [8], [9], [10], [11], [12]), as a | | | | servers ([RFC2132], [RFC2241], [RFC2242], |
| | | component in a list of routes [13]. | | | | [RFC3495], [RFC3634], [RFC4174]), as a |
| ipv6-address | 16 | DHCPv6 server unicast address [2], | | | | component in a list of routes [RFC3442]. |
| | | addresses of servers ([14], [15], [16], | | ipv6-address | 16 | DHCPv6 server unicast address [RFC3315], |
| | | [17], [18]). | | | | addresses of servers ([RFC3319], |
| | | [RFC3646], [RFC3898], [RFC4075], |
| | | [RFC4280]). |
| 32-bit | 4 | Signed or unsigned varieties. Deprecated | | 32-bit | 4 | Signed or unsigned varieties. Deprecated |
| integer | | [19] use for timezone time offset [5]. | | integer | | [RFC4833] use for timezone time offset |
| | | Other uses for host configuration values | | | | [RFC2132]. Other uses for host |
| | | such as path mtu aging timeouts, arp | | | | configuration values such as path mtu |
| | | cache timeouts, tcp keepalive intervals | | | | aging timeouts, arp cache timeouts, tcp |
| | | [5]. Also used by the DHCPv4 protocol | | | | keepalive intervals [RFC2132]. Also used |
| | | for relative times, and times since | | | | by the DHCPv4 protocol for relative |
| | | epoch. | | | | 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 [5], or | | | | the DHCPv4 maximum message size |
| | | the elapsed time option [2] in DHCPv6. | | | | [RFC2132], or the elapsed time option |
| | | [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 [5]. Also used | | | | TTL, NetBIOS node type [RFC2132]. Also |
| | | for protocol features, such as the DHCPv4 | | | | used for protocol features, such as the |
| | | Option Overload (as flags), DHCP Message | | | | DHCPv4 Option Overload (as flags), DHCP |
| | | Type (as an enumeration) or DHCPv6 | | | | Message Type (as an enumeration) or |
| | | Preference [2]. | | | | 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 | | | | indicators. Since the size of this format |
| | | format cannot be determined (it is not | | | | cannot be determined (it is not NULL |
| | | NULL terminated), it consumes any | | | | terminated), it consumes any remaining |
| | | remaining space in the option. | | | | 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 [21] and DHCPv6 [15], but | | Format Domain | | in both DHCPv4 [RFC3397] and DHCPv6 |
| Name List | | also used in DHCPv6 for any host or | | Name List | | [RFC3646], but also used in DHCPv6 for |
| [20] | | domain name. A field formatted this way | | [RFC1035] | | any host or domain name. A field |
| | | may have a determinate length if the | | | | formatted this way may have a determinate |
| | | number of root labels is limited, but use | | | | length if the number of root labels is |
| | | of this format as being a determinate | | | | limited, but use of this format as being |
| | | length should be discouraged in DHCPv4, | | | | a determinate length should be |
| | | less so in DHCPv6. | | | | discouraged in DHCPv4, less so in DHCPv6. |
| 'suboption' | unlim | The Relay Agent Information Option [22], | | 'suboption' | unlim | The Relay Agent Information Option |
| encapsulation | | vendor options [5], Vendor Identified | | encapsulation | | [RFC3046], vendor options [RFC2132], |
| | | Vendor SubOptions ([23], [2]). Commonly | | | | Vendor Identified Vendor SubOptions |
| | | used for situations where the full format | | | | ([RFC3925], [RFC3315]). Commonly used for |
| | | cannot be known initially, such as where | | | | situations where the full format cannot |
| | | there seems to be some room for later | | | | be known initially, such as where there |
| | | protocol work to expand the amount of | | | | seems to be some room for later protocol |
| | | information carried, or where the full | | | | work to expand the amount of information |
| | | extent of data carried is defined in a | | | | carried, or where the full extent of data |
| | | private specification (such as with | | | | carried is defined in a private |
| | | vendor options). Encapsulations do not | | | | specification (such as with vendor |
| | | use 'PAD' and 'END' options in DHCPv4, | | | | options). Encapsulations do not use 'PAD' |
| | | and there are no such options in DHCPv6, | | | | and 'END' options in DHCPv4, and there |
| | | so this format also is of indeterminate | | | | are no such options in DHCPv6, so this |
| | | length. | | | | format also is of indeterminate length. |
+---------------+-------+-------------------------------------------+ +---------------+-------+-------------------------------------------+
Table 1 Table 1
One approach to manufacturing simple DHCP Options is to assemble the One approach to manufacturing simple DHCP Options is to assemble the
option out of whatever common fragments fit - possibly allowing one option out of whatever common fragments fit - possibly allowing one
or more fragments to repeat to fill the remaining space (if present) or more fragments to repeat to fill the remaining space (if present)
and so provide multiple values. Place all fixed size values at the and so provide multiple values. Place all fixed size values at the
start of the option, and any variable/indeterminate sized values at start of the option, and any variable/indeterminate sized values at
the tail end of the option. If there are more than one variable/ the tail end of the option. If there are more than one variable/
skipping to change at page 7, line 38 skipping to change at page 7, line 45
clients cannot predict what values the server will provide, they must clients cannot predict what values the server will provide, they must
request all formats...so in the case where the server is configured request all formats...so in the case where the server is configured
with all formats, DHCP option space is wasted on option contents that with all formats, DHCP option space is wasted on option contents that
are redundant. are redundant.
It also becomes unclear which types of values are mandatory, and how It also becomes unclear which types of values are mandatory, and how
configuring some of the options may influence the others. For configuring some of the options may influence the others. For
example, if an operator configures the URL only, should the server example, if an operator configures the URL only, should the server
synthesize a domain name and ip address? synthesize a domain name and ip address?
A single configuration parameter should have only one option to A single configuration value on a host is probably presented to the
configure it. So the best advice is to choose the one method that operator (or other software on the machine) in a single field or
best fulfills the requirements, be that for simplicity (such as with channel. If that channel has a natural format, then any alternative
an ip address), late binding (such as with DNS), or completeness formats merely make more work for intervening software in providing
(such as with a URL). conversions.
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),
late binding (such as with DNS), or completeness (such as with a
URL).
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, the last
recourse is to contrive a new format to fit. recourse is to contrive a new format to fit.
When doing so, it is not enough to gauge wether 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 considered. It is equally important to consider if the new format
might reasonably have any other uses, and if so, to create the option might reasonably have any other uses, and if so, to create the option
with the foreknowledge that it may later become a common fragment. with the foreknowledge that it may later become a common fragment.
One specific consideration to evaluate, is wether or not options of a One specific consideration to evaluate, is whether or not options of
similar format would need to have multiple or single values encoded a 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. Option Size 8. Option Size
DHCPv4 [1] options payload space is limited, as there are a number of DHCPv4 [RFC2131] options payload space is limited, as there are a
unaddressed deployment problems with DHCPv4 packet sizes. The end number of unaddressed deployment problems with DHCPv4 packet sizes.
result is that you should build your option to the assumption that The end result is that you should build your option to the assumption
the packet will be no larger than 576 bytes. This means that the that the packet will be no larger than 576 bytes. This means that
options payload space will be 312 bytes, which you will have to share the options payload space will be 312 bytes, which you will have to
with other options. This space can be extended by making use of share with other options. This space can be extended by making use
Option Overloading [5], which allows the use of the BOOTP FILE and of Option Overloading [RFC2132], which allows the use of the BOOTP
SNAME header fields for carrying DHCPv4 options (adding 192 bytes), FILE and SNAME header fields for carrying DHCPv4 options (adding 192
but these header fields will not be available for overloading if they bytes), but these header fields will not be available for overloading
have been configured to carry a value. if they have been configured to carry a value.
DHCPv6 [2] carries a much more relaxed restriction, as it appears DHCPv6 [RFC3315] carries a much more relaxed restriction, as it
ready and able to accept packet sizes up to 64KB, putting options appears ready and able to accept packet sizes up to 64KB, putting
payload space at very nearly the same number (there are very few, and options payload space at very nearly the same number (there are very
small, header fields). But it is still undesirable to produce few, and small, header fields). But it is still undesirable to
fragments, and it's still very possible that the client's MTU is not produce fragments, and it's still very possible that the client's MTU
very large (or that client software is not prepared to retain a 64KB is not very large (or that client software is not prepared to retain
buffer). So it is still best advice to design options to a ~500 byte a 64KB buffer). So it is still best advice to design options to a
payload limitation. ~500 byte payload limitation.
This is easily accomplished by preferring option formats which This is easily accomplished by preferring option formats which
contain the desired information in the smallest form factor, in the contain the desired information in the smallest form factor, in the
absence of other motivations. One example is to use a 4-octet IPv4 absence of other motivations. One example is to use a 4-octet IPv4
address rather than a fully qualified domain name. There may be address rather than a fully qualified domain name. There may be
motivations to use the fully qualified domain name anyway, such as motivations to use the fully qualified domain name anyway, such as
externally supplied load balancers, or other protocol features. externally supplied load balancers, or other protocol features.
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 number of optional parameters that must be identified, because of the number of optional parameters that must be identified,
or because it is expected that very large configurations are valid, or because it is expected that very large configurations are valid,
it may be preferrable to use a second stage configuration. Some it may be preferrable to use a second stage configuration. Some
examples of this are to provide TFTP server and pathnames, or a URL, examples of this are to provide TFTP server and pathnames, or a URL,
which the client will load and process externally to the DHCP which the client will load and process externally to the DHCP
protocol. protocol.
In the case where a DHCPv4 option may, or will, exceed 255 bytes in In the case where a DHCPv4 option may, or will, exceed 255 bytes in
length (and thus exceed the 'length' field's ability to contain it), length (and thus exceed the 'length' field's ability to contain it),
a DHCPv4 option will simply be fragmented into multiple options a DHCPv4 option 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 [1], concatenate them, in the order they appear as defined by RFC2131
prior to evaluating their contents. This is an important distinction [RFC2131], prior to evaluating their contents. This is an important
that is sometimes overlooked by authors - these multiple options do distinction that is sometimes overlooked by authors - these multiple
not represent multiple options formatted precisely as you have options do not represent multiple options formatted precisely as you
defined, but rather one option that has been split along any have defined, but rather one option that has been split along any
arbitrary point into multiple containers. When documenting an arbitrary point into multiple containers. When documenting an
example, then, try to make sure that the division point you select as example, then, try to make sure that the division point you select as
an example does not lie on a clean division of your option contents - an example does not lie on a clean division of your option contents -
place it at an offset so as to reinforce that these values must be place it at an offset so as to reinforce that these values must be
concatenated rather than processed individually. 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, unless of course the option is very likely to exceed 255 definitions, unless of course the option is very likely to exceed 255
bytes, or the documented example(s) are this big. bytes, or the documented example(s) are this big.
skipping to change at page 10, line 10 skipping to change at page 10, line 22
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
servers with hints as to values they desire, and servers MAY respond servers with hints as to values they desire, and servers MAY respond
with the option contents if they have been so configured. with the option contents if they have been so configured.
10. Security Considerations 10. Security Considerations
DHCP does have an Authentication mechanism ([24], [2], [25]), where DHCP does have an Authentication mechanism ([RFC3118], [RFC3315],
it is possible for DHCP software to discriminate between authentic [RFC4030]), where it is possible for DHCP software to discriminate
endpoints and men in the middle. between authentic endpoints and men in the middle.
However, at this date the mechanism is poorly deployed. It also does However, at this date the mechanism is poorly deployed. It also does
not provide end-to-end encryption. not provide end-to-end encryption.
So, while creating a new option, bear in mind that DHCP packet So, while creating a new option, bear in mind that DHCP packet
contents are always transmitted in the clear, and actual production contents are always transmitted in the clear, and actual production
use of the software will probably be vulnerable at least to men in use of the software will probably be vulnerable at least to men in
the middle attacks from within the network, even where the network the middle attacks from within the network, even where the network
itself is protected from external attacks by firewalls. itself is protected from external attacks by firewalls. In
particular, some DHCP message exchanges are transmitted to broadcast
or multicast addresses that are likely broadcast anyway.
If an option is of a specific fixed length, it is useful to remind If an option is of a specific fixed length, it is useful to remind
the implementer of the option data's full length. This is easily the implementer of the option data's full length. This is easily
done by declaring the specific value of the 'length' tag of the done by declaring the specific value of the 'length' tag of the
option. This helps to gently remind implementers to validate option option. This helps to gently remind implementers to validate option
length before digesting them into likewise fixed length regions of length before digesting them into likewise fixed length regions of
memory or stack. memory or stack.
If an option may be of variable size (such as having indeterminate If an option may be of variable size (such as having indeterminate
length fields, such as domain names or text strings), it is advisable length fields, such as domain names or text strings), it is advisable
skipping to change at page 11, line 32 skipping to change at page 11, line 42
The DHCP Server implementation is known to be in wide use by many The DHCP Server implementation is known to be in wide use by many
Unix-based servers, and comes pre-installed on most Linux Unix-based servers, and comes pre-installed on most Linux
distributions. distributions.
The ISC DHCP Software Suite has to allow: The ISC DHCP Software Suite has to allow:
o Administrators to configure arbitrary DHCP Option Wire Formats for o Administrators to configure arbitrary DHCP Option Wire Formats for
options that either were not published at the time the software options that either were not published at the time the software
released, or are of the System Administrator's invention (such as released, or are of the System Administrator's invention (such as
'Site-Local' [26] options), or finally were of Vendor design 'Site-Local' [RFC3942] options), or finally were of Vendor design
(Vendor Encapsulated Options [5] or similar). (Vendor Encapsulated Options [RFC2132] or similar).
o Pre-defined names and formats of options allocated by IANA and o Pre-defined names and formats of options allocated by IANA and
defined by the IETF Standards body. defined by the IETF Standards body.
o Applications deriving their configuration parameters from values o Applications deriving their configuration parameters from values
provided by these options to receive and understand their content. provided by these options to receive and understand their content.
Often, the binary format on the wire is not helpful or digestable Often, the binary format on the wire is not helpful or digestable
by, for example, 'ifconfig' or '/etc/resolv.conf'. by, for example, 'ifconfig' or '/etc/resolv.conf'.
So, one can imagine that this would require a number of software So, one can imagine that this would require a number of software
functions: functions:
1. To read operator-written configuration value into memory. 1. To read operator-written configuration value into memory.
2. To write the in-memory representation into protocol wire format. 2. To write the in-memory representation into protocol wire format.
skipping to change at page 13, line 34 skipping to change at page 13, line 47
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 };
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;
12. Informative References 12. Informative References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC1035] Mockapetris, P., "Domain names - implementation and
March 1997. specification", STD 13, RFC 1035, November 1987.
[2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
Carney, "Dynamic Host Configuration Protocol for IPv6 RFC 2131, March 1997.
(DHCPv6)", RFC 3315, July 2003.
[3] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Configuration Protocol (DHCP) Client Fully Qualified Domain Extensions", RFC 2132, March 1997.
Name (FQDN) Option", RFC 4702, October 2006.
[4] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 [RFC2241] Provan, D., "DHCP Options for Novell Directory Services",
(DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 2241, November 1997.
RFC 4704, October 2006.
[5] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2242] Droms, R. and K. Fong, "NetWare/IP Domain Name and
Extensions", RFC 2132, March 1997. Information", RFC 2242, November 1997.
[6] Waters, G., "The IPv4 Subnet Selection Option for DHCP", [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP",
RFC 3011, November 2000. RFC 3011, November 2000.
[7] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, "Link [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
Selection sub-option for the Relay Agent Information Option for RFC 3046, January 2001.
DHCPv4", RFC 3527, April 2003.
[8] Provan, D., "DHCP Options for Novell Directory Services", [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
RFC 2241, November 1997. Messages", RFC 3118, June 2001.
[9] Droms, R. and K. Fong, "NetWare/IP Domain Name and [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
Information", RFC 2242, November 1997. and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[10] Beser, B. and P. Duffy, "Dynamic Host Configuration Protocol [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
(DHCP) Option for CableLabs Client Configuration", RFC 3495, Protocol (DHCPv6) Options for Session Initiation Protocol
March 2003. (SIP) Servers", RFC 3319, July 2003.
[11] Luehrs, K., Woundy, R., Bevilacqua, J., and N. Davoust, "Key [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration
Distribution Center (KDC) Server Address Sub-option for the Protocol (DHCP) Domain Search Option", RFC 3397,
Dynamic Host Configuration Protocol (DHCP) CableLabs Client November 2002.
Configuration (CCC) Option", RFC 3634, December 2003.
[12] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic Host [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless
Configuration Protocol (DHCP) Option for the Internet Storage Static Route Option for Dynamic Host Configuration
Name Service", RFC 4174, September 2005. Protocol (DHCP) version 4", RFC 3442, December 2002.
[13] Lemon, T., Cheshire, S., and B. Volz, "The Classless Static [RFC3495] Beser, B. and P. Duffy, "Dynamic Host Configuration
Route Option for Dynamic Host Configuration Protocol (DHCP) Protocol (DHCP) Option for CableLabs Client
version 4", RFC 3442, December 2002. Configuration", RFC 3495, March 2003.
[14] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) "Link Selection sub-option for the Relay Agent Information
Servers", RFC 3319, July 2003. Option for DHCPv4", RFC 3527, April 2003.
[15] Droms, R., "DNS Configuration options for Dynamic Host [RFC3634] Luehrs, K., Woundy, R., Bevilacqua, J., and N. Davoust,
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, "Key Distribution Center (KDC) Server Address Sub-option
for the Dynamic Host Configuration Protocol (DHCP)
CableLabs Client Configuration (CCC) Option", RFC 3634,
December 2003. December 2003.
[16] Kalusivalingam, V., "Network Information Service (NIS) [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Options for Dynamic Host Configuration Protocol Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
for IPv6 (DHCPv6)", RFC 3898, October 2004. December 2003.
[17] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) [RFC3898] Kalusivalingam, V., "Network Information Service (NIS)
Configuration Option for DHCPv6", RFC 4075, May 2005. Configuration Options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
[18] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for
Configuration Protocol (DHCP) Options for Broadcast and Dynamic Host Configuration Protocol version 4 (DHCPv4)",
Multicast Control Servers", RFC 4280, November 2005. RFC 3925, October 2004.
[19] Lear, E. and P. Eggert, "Timezone Options for DHCP", RFC 4833, [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration
April 2007. Protocol version 4 (DHCPv4) Options", RFC 3942,
November 2004.
[20] Mockapetris, P., "Domain names - implementation and [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for
specification", STD 13, RFC 1035, November 1987. the Dynamic Host Configuration Protocol (DHCP) Relay Agent
Option", RFC 4030, March 2005.
[21] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
(DHCP) Domain Search Option", RFC 3397, November 2002. Configuration Option for DHCPv6", RFC 4075, May 2005.
[22] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, [RFC4174] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic
January 2001. Host Configuration Protocol (DHCP) Option for the Internet
Storage Name Service", RFC 4174, September 2005.
[23] Littlefield, J., "Vendor-Identifying Vendor Options for Dynamic [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host
Host Configuration Protocol version 4 (DHCPv4)", RFC 3925, Configuration Protocol (DHCP) Options for Broadcast and
October 2004. Multicast Control Servers", RFC 4280, November 2005.
[24] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
RFC 3118, June 2001. Configuration Protocol (DHCP) Client Fully Qualified
Domain Name (FQDN) Option", RFC 4702, October 2006.
[25] Stapp, M. and T. Lemon, "The Authentication Suboption for the [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
RFC 4030, March 2005. Option", RFC 4704, October 2006.
[26] Volz, B., "Reclassifying Dynamic Host Configuration Protocol [RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP",
version 4 (DHCPv4) Options", RFC 3942, November 2004. RFC 4833, April 2007.
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
Redwood City, CA Redwood City, CA 94063
US US
Phone: +1 650 423 1307 Phone: +1 650 423 1307
Email: David_Hankins@isc.org Email: David_Hankins@isc.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 16, line 44 skipping to change at line 716
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 57 change blocks. 
180 lines changed or deleted 189 lines changed or added

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