draft-ietf-dhc-option-guidelines-01.txt   draft-ietf-dhc-option-guidelines-02.txt 
Dynamic Host Configuration Working D. Hankins Dynamic Host Configuration Working D. Hankins
Group ISC Group ISC
Intended status: Informational Intended status: Informational
Expires: February 22, 2009 Expires: March 12, 2009
Guidelines for Creating New DHCP Options Guidelines for Creating New DHCP Options
draft-ietf-dhc-option-guidelines-01 draft-ietf-dhc-option-guidelines-02
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 February 22, 2009. This Internet-Draft will expire on March 12, 2009.
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. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 7
7. New Formats . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. New Formats . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Clients Request their Options . . . . . . . . . . . . . . . . 9 9. Clients Request their Options . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . 13
12. Informative References . . . . . . . . . . . . . . . . . . . . 13 12. Informative References . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17 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 whether the proposed protocol presents frequently considered is whether the proposed protocol presents
itself needless barriers to adoption by deployed software. 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
skipping to change at page 6, line 17 skipping to change at page 6, line 17
| | | 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 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 26 skipping to change at page 7, line 27
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 there are no such conditional formatting
methods in existence today, so it must therefore require new, special methods in existence today, so it must therefore require new, special
case code, be written for this purpose. case code, be written for this purpose.
Wherever possible, used fixed length buffers to carry the information Wherever possible, used fixed length buffers to carry the information
desired. Obviously, this becomes less possible as the fixed length desired. Obviously, this becomes less possible as the fixed length
buffer approaches large sizes, at least in DHCPv4, where DHCP packet buffer approaches large sizes, at least in DHCPv4, where DHCP packet
space is limited. space is limited.
6. Aliasing 6. Avoid Aliasing
Providing multiple different formats of the same configuration Options are said to be aliases of each other if they provide input to
information, such as an IP address, name, or URL, which are all the same configuration parameter. A commonly proposed example is to
intended to provide the same location information, is undesirable. 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
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
the work of the software involved, requiring support for not merely the work of the software involved, requiring support for not merely
one format, but support to produce and digest all three. Since one format, but support to produce and digest all three. Since
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
skipping to change at page 8, line 39 skipping to change at page 8, line 42
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
if they have been configured to carry a value. if they have been configured to carry a value.
DHCPv6 [RFC3315] carries a much more relaxed restriction, as it DHCPv6 [RFC3315] is much better off. First, through its use of link-
appears ready and able to accept packet sizes up to 64KB, putting local addresses, it steps aside many of the deployment problems that
options payload space at very nearly the same number (there are very plague DHCPv4, and looks a great deal more like any other UDP based
few, and small, header fields). But it is still undesirable to application; oblivious to packet sizes up to 64KB. Second, RFC3315
produce fragments, and it's still very possible that the client's MTU explicitly refers readers to RFC2460 Section 5, which describes an
is not very large (or that client software is not prepared to retain MTU of 1280 octets and a minimum fragment reassembly of 1500 octets.
a 64KB buffer). So it is still best advice to design options to a It's much more feasible to suggest that DHCPv6 is capable of having
~500 byte payload limitation. larger options deployed over it, and at least no common upper limit
is yet known to have been encoded by its implementors. It is
impossible to describe any fixed limit that cleanly divides those too
big from the workable.
This is easily accomplished by preferring option formats which So in either protocol, it is advantageous to prefer option formats
contain the desired information in the smallest form factor, in the which contain the desired information in the smallest form factor
absence of other motivations. 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. There may be address rather than a fully qualified domain name, because many DHCP
motivations to use the fully qualified domain name anyway, such as servers will perform DNS resolution on configured FQDN's (so the DNS
externally supplied load balancers, or other protocol features. recursive lookup is performed anyway). There may be motivations to
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
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 number of optional parameters that must be identified, because of the simple size of the parameters, or because it is
or because it is expected that very large configurations are valid, expected that very large configurations are valid, it may be
it may be preferrable to use a second stage configuration. Some preferrable to use a second stage configuration. Some examples of
examples of this are to provide TFTP server and pathnames, or a URL, this are to provide TFTP server and pathnames, or a URL, which the
which the client will load and process externally to the DHCP 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 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 do not represent multiple options formatted precisely as you
have defined, but rather one option that has been split along any have defined, but rather one option that has been split along any
skipping to change at page 9, line 45 skipping to change at page 10, line 7
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 9. Clients Request their Options
In both DHCP protocols, there exists as part of the protocol The DHCPv4 Parameter Request List [RFC2132], and the DHCPv6 Option
definition an option whose purpose is twofold - to inform the server Request Option (OPTION_ORO) [RFC3315], are both optoins that serve
what option(s) the client supports and is willing to digest, and in two purposes - to inform the server what option(s) the client
what order of priority the client places those option contents (in supports and is willing to digest, and in what order of priority the
the event that they will not fit in the packet, later options are to client places those option contents (in the event that they will not
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 are formed by elements of the protocol's request list, such as those are 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
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
definition require special ordering of options either in the relevant
request option, or in the order of packets returned on the server's
reply. Although the request option does display a preferred
priority, which implies an order, a server may shuffle options around
in a DHCPv4 packet in order to make them fit, and server software may
sort DHCPv6 options into strange orders. There is not one universal
approach.
10. Security Considerations 10. 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 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.
 End of changes. 15 change blocks. 
55 lines changed or deleted 72 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/