draft-ietf-dhc-option-guidelines-03.txt   draft-ietf-dhc-option-guidelines-04.txt 
Dynamic Host Configuration Working D. Hankins Dynamic Host Configuration Working D. Hankins
Group ISC Group ISC
Intended status: Informational Intended status: Informational
Expires: April 17, 2009 Expires: August 21, 2009
Guidelines for Creating New DHCP Options Guidelines for Creating New DHCP Options
draft-ietf-dhc-option-guidelines-03 draft-ietf-dhc-option-guidelines-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 April 17, 2009. This Internet-Draft will expire on August 21, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
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 . . . . . . . . . . . . . . . . . . . . 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. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. The Dangers of Sub Options . . . . . . . . . . . . . . . . . . 8
9. Clients Request their Options . . . . . . . . . . . . . . . . 9 9. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Clients Request their Options . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
Appendix A. Background on ISC DHCP . . . . . . . . . . . . . . . 11 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
Appendix A.1. Atomic DHCP . . . . . . . . . . . . . . . . . . . . 13 13. Appendix A: Background on ISC DHCP . . . . . . . . . . . . . . 12
12. Informative References . . . . . . . . . . . . . . . . . . . . 14 13.1. Atomic DHCP . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 14. Informative References . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 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 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, which
includes user interface considerations. As an aide to understanding includes user interface considerations. To help understand the
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 in an Appendix. (Section 13) has been included as an Appendix.
Another, and more frequently overlooked, aspect of rapid adoption is Another more frequently overlooked aspect of rapid adoption is the
whether or not 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
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 presented with a
rough time being adopted by deployed software if it requires code series of ever-worsening challenges to be adopted;
changes. A rougher time still, if it does not share its deployment
fate in a general manner with other options of pressing need. o If it doesn't fit neatly into existing config files.
o If it requries new source code changes to be adopted, and hence
upgrades of deployed software.
o If it does not share its deployment fate in a general manner with
other options, creating a pressing need for code changes, or
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 make software implementors lives easier, and improve the chances to stay off this list entirely, or failing that, to make software
that the Option is formally adopted in deployed software after it has implementors lives easier and improve its chances for widespread
been assigned an Option Code. 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.
Any knob, dial, slider, or checkbox on the client system, such as "my Any knob, dial, slider, or checkbox on the client system, such as "my
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, because DHCP also presents
secondarily, DHCP also presents the extension of an administrative the extension of an administrative domain - the operator of the
domain - that of the systems operator of the network to which the network to which the client is currently attached. Someone runs not
client is currently attached. Someone runs not only the local only the local switching network infrastructure that the client is
switching network infrastructure that the client is directly (or directly (or wirelessly) attached to, but the various methods of
wirelessly) attached to, but the various methods of accessing the accessing the external Internet via local assist services that
external Internet via local assist services that network must also network must also provide (such as domain name servers, or routers).
provide (such as domain name servers, or routers). This means that This means that in addition to the existence of a configuration
in addition to the existence of a configuration parameter, one must parameter, one must also ask themselves if it is reasonable for this
also ask themselves if it is reasonable for this parameter to be set parameter to be set by some DHCP server operators, which roughly
by the DHCP server operator. translates to the local network administrator.
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 ignore
ignore values received via DHCP (for example, due to having a value values received via DHCP (for example, due to having a value manually
manually configured by its operator), and that at least one main use configured by its own operator), and that at least one main use case
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 is not a suitable source of this configuration, it is likely Cafe's operator is not a likely source of the candidate
that the client will at some point return to a network whose operator configuration, there may be other DHCP servers in a client's lifetime
is also the system's rightful master. which are.
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.
skipping to change at page 4, line 49 skipping to change at page 5, line 11
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 [RFC2132] 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 There is a tradeoff between the adoptability of previously defined
similar problem was approached, and it may waste space or processing option formats, and the advantages new or specialized formats can
time or have ugly characteristics, it can usually be said that provide. In the balance, it is usually preferrable to reuse
duplicating that which has already been adopted has the greatest previously used option formats.
chance of being adopted quickly and easily.
So it is preferrable to consider the bulk of DHCP options already
allocated, and consider which of those solve a similar problem. It
may even be that an option that solves the problem already exists.
But as there are so many options to choose from, this isn't entirely However, it isn't very practical to consider the bulk of DHCP options
practical. So, the following list of common option formats is already allocated, and consider which of those solve a similar
problem. So, the following list of common option format fragments is
provided as a shorthand. Please note that it is not complete in provided as a shorthand. Please note that it is not complete in
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.
+---------------+-------+-------------------------------------------+ +---------------+-------+-------------------------------------------+
| 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 [RFC2132], addresses of | | | | subnet mask [RFC2132], addresses of |
skipping to change at page 6, line 42 skipping to change at page 6, line 49
| | | carried is defined in a private | | | | carried is defined in a private |
| | | specification (such as with vendor | | | | specification (such as with vendor |
| | | options). Encapsulations do not use 'PAD' | | | | options). Encapsulations do not use 'PAD' |
| | | and 'END' options in DHCPv4, and there | | | | and 'END' options in DHCPv4, and there |
| | | are no such options in DHCPv6, so this | | | | are no such options in DHCPv6, so this |
| | | format also is of indeterminate length. | | | | format also is of indeterminate length. |
+---------------+-------+-------------------------------------------+ +---------------+-------+-------------------------------------------+
Table 1: Common Option Fragments Table 1: Common Option Fragments
One approach to manufacturing simple DHCP Options is to assemble the The easiest approach to manufacturing trivially deployable DHCP
option out of whatever common fragments fit - possibly allowing one Options is to assemble the option out of whatever common fragments
or more fragments to repeat to fill the remaining space (if present) fit - possibly allowing a group of fragments to repeat to fill the
and so provide multiple values. Place all fixed size values at the remaining space (if present) and so provide multiple values. Place
start of the option, and any variable/indeterminate sized values at all fixed size values at the start of the option, and any variable/
the tail end of the option. If there are more than one variable/ indeterminate sized values at the tail end of the option.
indeterminate length values, consider the use of multiple options or
suboptions.
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 there are no such conditional formatting the casual observer. But the only conditional formatting methods
methods in existence today, so it must therefore require new, special that are in widepsread use today are 'protocol' class options. So
case code, be written for this purpose. conditional formatting requires new code to be written, as well as
introduces an implementation problem; as it requires that all
speakers implement all current and future conditional formats.
Wherever possible, use fixed length buffers to carry the information Conditional formatting is absolutely not recommended, except in cases
desired. Obviously, this becomes less possible as the fixed length where the DHCP option has already been deployed, and all but one
buffer approaches large sizes, at least in DHCPv4, where DHCP packet conditional format is deprecated.
space is limited.
6. Avoid Aliasing 6. Avoid Aliasing
Options are said to be aliases of each other if they provide input to Options are said to be aliases of each other if they provide input to
the same configuration parameter. A commonly proposed example is to the same configuration parameter. A commonly proposed example is to
configure the location of some new service ("my foo server") using a configure the location of some new service ("my foo server") using a
binary IP address, a domain name field, and a URL. This kind of binary IP address, a domain name field, and a URL. This kind of
aliasing is undesirable, and is best avoided. aliasing is undesirable, and is best avoided.
In this case, where three different formats are supposed, it triples In this case, where three different formats are supposed, it triples
skipping to change at page 7, line 47 skipping to change at page 8, line 7
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 value on a host is probably presented to the A single configuration value on a host is probably presented to the
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), requirements, be that for simplicity (such as with an IP address and
late binding (such as with DNS), or completeness (such as with a port pair), late binding (such as with DNS), or completeness (such as
URL). 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 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 considered. It is equally important to consider if the new format's
might reasonably have any other uses, and if so, to create the option fragments might reasonably have any other uses, and if so, to create
with the foreknowledge that it may later become a common fragment. the option with the foreknowledge that its parts may later become a
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 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. The Dangers of Sub Options
Some DHCP options, such as the DHCPv4 Relay Agent Information Option
[RFC3046] are defined to contain a series of DHCP options, possibly
using code tags specific to that option (but not in some limited
"protocol feature" cases in DHCPv6 [RFC3315]). These are commonly
referred to as Encapsulated Option Spaces or more simply, Sub
Options.
Sub options seem very attractive, because they allow the encoding of
multiple variable length fields within the single "parent" option.
However, DHCP software will only include these options on an "all or
nothing" basis, there is no well deployed mechanism for "Sub Option
Parameter Request Lists", and the software will not include the
entire option if there is not sufficient space for only the last sub-
option to fit in the DHCP packet.
Consequently, it is not advisable to group options that may not be
requested at the same time by the same client under an encapsulated
space.
Another attraction sub options present is ease of extending the
configuration value for later, related configuration. This must be
weighed against the cost associated with asking IANA to maintain the
space's internally assigned option codes. Generally, the cost to
IANA is greater, as it is unlikely that most options will be later
extended.
The use of sub-options is not a solution to aliasing problems. Sub-
options that contain multiple configuration values that alias the
same configuration element actually makes matters worse. The only
solution to aliasing problems is to select a single option format, or
where that is literally impossible, to use multiple DHCP options. In
this way, clients may place only the options they support on their
parameter request list, in the order they support them. Later
protocol maintenance may incorporate a means to select a single DHCP
option code out of a list of aliased options.
Additionaly, DHCPv4 option concatenation (described in detail below)
has not been defined in any DHCPv4 sub-options space. Currently
there is some DHCP software which does concatenate multiple DHCP
options present in a sub-option space. There is also software that
treats multiple DHCP option codes present in a sub-option as
individual single options. So there is no reliably predictable
default behaviour.
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
code, any attempt to do so is discouraged.
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
that the packet will be no larger than 576 bytes. This means that that the packet will be no larger than 576 bytes. This means that
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
skipping to change at page 9, line 15 skipping to change at page 10, line 28
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 preferrable 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.
In the case where a DHCPv4 option may, or will, exceed 255 bytes in The DHCPv4 code and length tags are each a single byte. As the
length (and thus exceed the 'length' field's ability to contain it), length field describes the length of the DHCP option's contents (not
a DHCPv4 option will simply be fragmented into multiple options including the code and length bytes), any option whose contents'
length exceeds 255 bytes can not be contained in a single option.
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 [RFC2131], prior to evaluating their contents. This is an important
distinction that is sometimes overlooked by authors - these multiple distinction that is sometimes overlooked by authors - these multiple
options do not represent multiple options formatted precisely as you options are not individually formatted precisely as you have defined,
have defined, but rather one option that has been split along any but rather one option that has been split along any arbitrary point
arbitrary point into multiple containers. When documenting an into multiple containers. When documenting an example, then, try to
example, then, try to make sure that the division point you select as make sure that the division point you select as an example does not
an example does not lie on a clean division of your option contents - lie on a clean division of your option contents - place it at an
place it at an offset so as to reinforce that these values must be offset so as to reinforce that these values must be concatenated
concatenated rather than processed individually. 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, and no requirement for every option definition to be
bytes, or the documented example(s) are this big. presented as a series of fragments. It is only recommended to
reinforce the existence of DHCP option fragmentation when the
potential for large options is likely. In this case, try to choose a
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.
9. 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 option(s) the client
supports and is willing to digest, and in what order of priority the supports and is willing to digest, and in what order of priority the
client places those option contents (in the event that they will not client places those option contents (in the event that they will not
fit in the packet, later options are to be dropped). fit in 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
skipping to change at page 10, line 22 skipping to change at page 11, line 38
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).
Under only the most dire of circumstances should a new option Under only the most dire of circumstances should a new option
definition require special ordering of options either in the relevant definition require special ordering of options either in the relevant
request option, or in the order of packets returned on the server's request option, or in the order of options within the packet.
reply. Although the request option does display a preferred Although the request option does imply a priority, which might be
priority, which implies an order, a server may shuffle options around processed in order, a server may shuffle options around in a DHCPv4
in a DHCPv4 packet in order to make them fit, and server software may packet in order to make them fit, and server software may sort DHCPv6
sort DHCPv6 options into strange orders. There is not one universal options into strange orders. There is not one universal approach.
approach.
10. Security Considerations 11. Security Considerations
DHCP does have an Authentication mechanism ([RFC3118], [RFC3315], DHCP does have an Authentication mechanism ([RFC3118], [RFC3315],
[RFC4030]), where it is possible for DHCP software to discriminate [RFC4030]), where it is possible for DHCP software to discriminate
between authentic endpoints and man-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 man-in- use of the software will probably be vulnerable at least to man-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. In itself is protected from external attacks by firewalls. In
particular, some DHCP message exchanges are transmitted to broadcast particular, some DHCP message exchanges are transmitted to broadcast
skipping to change at page 11, line 25 skipping to change at page 12, line 41
address, or local broadcast address, and depending on the protocol address, or local broadcast address, and depending on the protocol
this may lead to undesirable results. A domain name field may be this may lead to undesirable results. A domain name field may be
filled with contrived contents that exceed the limitations placed filled with contrived contents that exceed the limitations placed
upon domain name formatting...as this value is possibly delivered to upon domain name formatting...as this value is possibly delivered to
"internal configuration" records of the system, it may be trusted, "internal configuration" records of the system, it may be trusted,
rather than validated. rather than validated.
So it behooves an option's definition to contain any validation So it behooves an option's definition to contain any validation
measures as can reasonably be made. measures as can reasonably be made.
11. IANA Considerations 12. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
Appendix A. Background on ISC DHCP 13. Appendix A: Background on ISC DHCP
The ISC DHCP software package was mostly written by Ted Lemon in The ISC DHCP software package was mostly written by Ted Lemon in
cooperation with Nominum, Inc. Since then, it has been given to cooperation with Nominum, Inc. Since then, it has been given to
Internet Systems Consortium, Inc. ("ISC") where it has been Internet Systems Consortium, Inc. ("ISC") where it has been
maintained in the public interest by contributors and ISC employees. maintained in the public interest by contributors and ISC employees.
It includes a DHCP Server, Relay, and Client implementation, with a It includes a DHCP Server, Relay, and Client implementation, with a
common library of DHCP protocol handling procedures. common library of DHCP protocol handling procedures.
The DHCP Client may be found on some Linux distributions, and FreeBSD The DHCP Client may be found on some Linux distributions, and FreeBSD
skipping to change at page 13, line 5 skipping to change at page 14, line 20
Another simple trick is to use the same (or very nearly the same) Another simple trick is to use the same (or very nearly the same)
format for persistent storage as is used to convey parameters to format for persistent storage as is used to convey parameters to
applications. This reduces the number of functions again from 3 to applications. This reduces the number of functions again from 3 to
2. 2.
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.
Appendix A.1. Atomic DHCP 13.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.
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.
skipping to change at page 14, line 14 skipping to change at page 15, line 32
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.
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 14. Informative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
skipping to change at page 17, line 4 skipping to change at line 767
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 94063 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
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 35 change blocks. 
108 lines changed or deleted 175 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/