draft-ietf-dhc-option-guidelines-06.txt   draft-ietf-dhc-option-guidelines-07.txt 
Dynamic Host Configuration Working D. Hankins Dynamic Host Configuration Working D. Hankins
Group ISC Group Google
Internet-Draft March 5, 2010 Internet-Draft October 1, 2011
Intended status: Informational Intended status: Informational
Expires: September 6, 2010 Expires: April 3, 2012
Guidelines for Creating New DHCP Options Guidelines for Creating New DHCP Options
draft-ietf-dhc-option-guidelines-06 draft-ietf-dhc-option-guidelines-07
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 This Internet-Draft will expire on April 3, 2012.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. When to Use DHCP . . . . . . . . . . . . . . . . . . . . . . . 3 2. When to Use DHCP . . . . . . . . . . . . . . . . . . . . . . . 3
3. General Principles . . . . . . . . . . . . . . . . . . . . . . 4 3. General Principles . . . . . . . . . . . . . . . . . . . . . . 4
4. Reusing Other Options . . . . . . . . . . . . . . . . . . . . 5 4. Reusing Other Options . . . . . . . . . . . . . . . . . . . . 5
5. Conditional Formatting is Hard . . . . . . . . . . . . . . . . 7 5. Avoid Conditional Formatting . . . . . . . . . . . . . . . . . 7
6. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 7
7. New Formats . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Considerations for Creating New Formats . . . . . . . . . . . 8
8. The Dangers of Sub Options . . . . . . . . . . . . . . . . . . 8 8. The Dangers of Sub Options . . . . . . . . . . . . . . . . . . 8
9. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Clients Request their Options . . . . . . . . . . . . . . . . 11 10. Clients Request their Options . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. Informative References . . . . . . . . . . . . . . . . . . . . 13 13. Informative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Background on ISC DHCP . . . . . . . . . . . . . . . 15 Appendix A. Background on ISC DHCP . . . . . . . . . . . . . . . 15
A.1. Atomic DHCP . . . . . . . . . . . . . . . . . . . . . . . 17 A.1. Atomic DHCP . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 3, line 39 skipping to change at page 3, line 39
So although a given solution would work, and might even be space, So although a given solution would work, and might even be space,
time, or aesthetically optimal, a given option is presented with a time, or aesthetically optimal, a given option is presented with a
series of ever-worsening challenges to be adopted; series of ever-worsening challenges to be adopted;
o If it doesn't fit neatly into existing config files. o If it doesn't fit neatly into existing config files.
o If it requries new source code changes to be adopted, and hence o If it requries new source code changes to be adopted, and hence
upgrades of deployed software. upgrades of deployed software.
o If it does not share its deployment fate in a general manner with o If it does not share its deployment fate in a general manner with
other options, standing alone in requiring code changes, or other options, standing alone in requiring code changes or
reworking configuration file syntaxes. reworking configuration file syntaxes.
There are many things DHCP option authors can do to form DHCP Options There are many things DHCP option authors can do to form DHCP Options
to stay off this list entirely, or failing that, to make software to stay off this list entirely, or failing that, to make software
implementors lives easier and improve its chances for widespread implementors lives easier and improve its chances for widespread
adoption. adoption.
2. When to Use DHCP 2. When to Use DHCP
Principally, DHCP carries configuration parameters for its clients. Principally, DHCP carries configuration parameters for its clients.
skipping to change at page 4, line 43 skipping to change at page 4, line 43
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 ([RFC4702], [RFC4704]), special processing (such as the FQDN options ([RFC4702], [RFC4704]),
DHCPv4 message type option [RFC2132], link selection options DHCPv4 message type option [RFC2132], link selection options
([RFC3011], [RFC3527]), and so forth). ([RFC3011], [RFC3527]), and so forth; these options carry data that
is the result of a routine in some DHCP software).
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
skipping to change at page 5, line 36 skipping to change at page 5, line 36
+---------------+-------+-------------------------------------------+ +---------------+-------+-------------------------------------------+
| ipv4-address | 4 | Default gateway, requested address, | | ipv4-address | 4 | Default gateway, requested address, |
| | | subnet mask [RFC2132], addresses of | | | | subnet mask [RFC2132], addresses of |
| | | servers ([RFC2132], [RFC2241], [RFC2242], | | | | servers ([RFC2132], [RFC2241], [RFC2242], |
| | | [RFC3495], [RFC3634], [RFC4174]), as a | | | | [RFC3495], [RFC3634], [RFC4174]), as a |
| | | component in a list of routes [RFC3442]. | | | | component in a list of routes [RFC3442]. |
| ipv6-address | 16 | DHCPv6 server unicast address [RFC3315], | | ipv6-address | 16 | DHCPv6 server unicast address [RFC3315], |
| | | addresses of servers ([RFC3319], | | | | addresses of servers ([RFC3319], |
| | | [RFC3646], [RFC3898], [RFC4075], | | | | [RFC3646], [RFC3898], [RFC4075], |
| | | [RFC4280]). | | | | [RFC4280]). |
| 32-bit | 4 | Signed or unsigned varieties. Used for | | 32-bit | 4 | Signed or unsigned varieties. Used for |
| integer | | timezone time offset [RFC2132] | | integer | | timezone time offset [RFC2132] |
| | | (deprecated by [RFC4833]). Other uses | | | | (deprecated by [RFC4833]). Other uses for |
| | | for host configuration values such as | | | | host configuration values such as path |
| | | path MTU aging timeouts, ARP cache | | | | MTU aging timeouts, ARP cache timeouts, |
| | | timeouts, TCP keepalive intervals | | | | TCP keepalive intervals [RFC2132]. Also |
| | | [RFC2132]. Also used by the DHCPv4 | | | | used by the DHCPv4 protocol for relative |
| | | protocol for relative times, and times | | | | times, and times since epoch. |
| | | since epoch. |
| 16-bit | 2 | Client configuration parameters, such as | | 16-bit | 2 | Client configuration parameters, such as |
| integer | | MTU, maximum datagram reassembly limits, | | integer | | MTU, maximum datagram reassembly limits, |
| | | the DHCPv4 maximum message size | | | | the DHCPv4 maximum message size |
| | | [RFC2132], or the elapsed time option | | | | [RFC2132], or the elapsed time option |
| | | [RFC3315] in DHCPv6. | | | | [RFC3315] in DHCPv6. |
| 8-bit integer | 1 | Used for host configuration parameters, | | 8-bit integer | 1 | Used for host configuration parameters, |
| | | such as the default IP TTL, default TCP | | | | such as the default IP TTL, default TCP |
| | | TTL, NetBIOS node type [RFC2132]. Also | | | | TTL, NetBIOS node type [RFC2132]. Also |
| | | used for protocol features, such as the | | | | used for protocol features, such as the |
| | | DHCPv4 Option Overload (as flags), DHCP | | | | DHCPv4 Option Overload (as flags), DHCP |
| | | Message Type (as an enumeration) or | | | | Message Type (as an enumeration) or |
| | | DHCPv6 Preference [RFC3315]. | | | | DHCPv6 Preference [RFC3315]. |
| NVT-ASCII | unlim | This is the kitchen sink of common | | NVT-ASCII | unlim | This is the kitchen sink of common |
| Text | | fragments. Common uses are for filenames | | Text | | fragments. Common uses are for filenames |
| | | (such as TFTP paths), host or domain | | | | (such as TFTP paths), host or domain |
| | | names (but this should be discouraged), | | | | names (but this should be discouraged), |
| | | or protocol features such as textual | | | | or protocol features such as textual |
| | | messages such as verbose error | | | | messages such as verbose error |
| | | indicators. Since the size of this | | | | 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 [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 | | | | ([RFC3925], [RFC3315]). Commonly used for |
| | | for situations where the full format | | | | situations where the full format cannot |
| | | cannot be known initially, such as where | | | | be known initially, such as where there |
| | | there seems to be some room for later | | | | seems to be some room for later protocol |
| | | protocol work to expand the amount of | | | | work to expand the amount of information |
| | | information carried, or where the full | | | | carried, or where the full extent of data |
| | | extent of data carried is defined in a | | | | carried is defined in a private |
| | | private specification (such as with | | | | specification (such as with vendor |
| | | vendor options). Encapsulations do not | | | | options). Encapsulations do not use 'PAD' |
| | | use 'PAD' and 'END' options in DHCPv4, | | | | and 'END' options in DHCPv4, and there |
| | | and there are no such options in DHCPv6, | | | | are no such options in DHCPv6, so this |
| | | so this format also is of indeterminate | | | | format also is of indeterminate length. |
| | | length. |
+---------------+-------+-------------------------------------------+ +---------------+-------+-------------------------------------------+
Table 1: Common Option Fragments Table 1: Common Option Fragments
The easiest approach to manufacturing trivially deployable DHCP The easiest approach to manufacturing trivially deployable DHCP
Options is to assemble the option out of whatever common fragments Options is to assemble the option out of whatever common fragments
fit - possibly allowing a group of fragments to repeat to fill the fit - possibly allowing a group of fragments to repeat to fill the
remaining space (if present) and so provide multiple values. Place remaining space (if present) and so provide multiple values. Place
all fixed size values at the start of the option, and any variable/ all fixed size values at the start of the option, and any variable/
indeterminate sized values at the tail end of the option. indeterminate sized value at the tail end of the option.
This estimates that implementations will be able to reuse code paths This estimates that implementations will be able to reuse code paths
designed to support the other options. designed to support the other options.
5. Conditional Formatting is Hard 5. Avoid Conditional Formatting
Placing a byte at the start of the option which informs the software Placing a octet 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 octets of the option may appear simple
the casual observer. But the only conditional formatting methods to the casual observer. But the only conditional formatting methods
that are in widespread use today are 'protocol' class options. So that are in widespread use today are 'protocol' class options. So
conditional formatting requires new code to be written, as well as conditional formatting requires new code to be written, as well as
introduces an implementation problem; as it requires that all introduces an implementation problem; as it requires that all
speakers implement all current and future conditional formats. speakers implement all current and future conditional formats.
Conditional formatting is absolutely not recommended, except in cases Conditional formatting is absolutely not recommended, except in cases
where the DHCP option has already been deployed, and all but one where the DHCP option has already been deployed experimentally, and
conditional format is deprecated. all but one conditional format is deprecated.
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 8, line 23 skipping to change at page 8, line 22
Fully Qualified Domain Name instead of a binary IP address, note that Fully Qualified Domain Name instead of a binary IP address, note that
most DHCP server implementations will happily accept a Domain Name most DHCP server implementations will happily accept a Domain Name
entered by the administrator, and use DNS resolution to render binary entered by the administrator, and use DNS resolution to render binary
IP addresses in DHCP replies to clients. Consequently, consider the IP addresses in DHCP replies to clients. Consequently, consider the
extra packet overhead incurred on the client's end to perform DNS extra packet overhead incurred on the client's end to perform DNS
resolution itself. The client may be operating on a battery and resolution itself. The client may be operating on a battery and
packet transmission is a non-trivial use of power, and the extra RTT packet transmission is a non-trivial use of power, and the extra RTT
delays the client must endure before the service is configured are at delays the client must endure before the service is configured are at
least two factors to consider in making a decision on format. least two factors to consider in making a decision on format.
7. New Formats 7. Considerations for Creating New Formats
If the option simply will not fit into any existing work by using If the option simply will not fit into any existing work by using
fragments, the last recourse is to create a new format to fit. fragments, the last recourse is to create a new format to fit.
When doing so, it is not enough to gauge whether or not the option When doing so, it is not enough to gauge whether or not the option
format will work in the context of the option presently being format will work in the context of the option presently being
considered. It is equally important to consider if the new format's considered. It is equally important to consider if the new format's
fragments might reasonably have any other uses, and if so, to create fragments might reasonably have any other uses, and if so, to create
the option with the foreknowledge that its parts may later become a the option with the foreknowledge that its parts may later become a
common fragment. common fragment.
skipping to change at page 10, line 4 skipping to change at page 9, line 51
Because no sub-options space has yet been defined that includes the Because no sub-options space has yet been defined that includes the
possibility of having more than one instance of an option of the same possibility of having more than one instance of an option of the same
code, any attempt to do so is discouraged. code, any attempt to do so is discouraged.
9. Option Size 9. Option Size
DHCPv4 [RFC2131] options payload space is limited, as there are a DHCPv4 [RFC2131] options payload space is limited, as there are a
number of unaddressed deployment problems with DHCPv4 packet sizes. number of unaddressed deployment problems with DHCPv4 packet sizes.
The end result is that you should build your option to the assumption The end result is that you should build your option to the assumption
that the packet will be no larger than 576 bytes. This means that that the packet will be no larger than 576 octets. This means that
the options payload space will be 312 bytes, which you will have to the options payload space will be 312 octets, 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 octets), but these header fields will not be available for
if they have been configured to carry a value. overloading if they have been configured to carry a value.
DHCPv6 [RFC3315] is much better off. First, through its use of link- DHCPv6 [RFC3315] is much better off. First, through its use of link-
local addresses, it steps aside many of the deployment problems that local addresses, it steps aside many of the deployment problems that
plague DHCPv4, and looks a great deal more like any other UDP based plague DHCPv4, and looks a great deal more like any other UDP based
application; oblivious to packet sizes up to 64KB. Second, RFC 3315 application; oblivious to packet sizes up to 64KB. Second, RFC 3315
explicitly refers readers to RFC 2460 Section 5, which describes an explicitly refers readers to RFC 2460 Section 5, which describes an
MTU of 1280 octets and a minimum fragment reassembly of 1500 octets. MTU of 1280 octets and a minimum fragment reassembly of 1500 octets.
It's much more feasible to suggest that DHCPv6 is capable of having It's much more feasible to suggest that DHCPv6 is capable of having
larger options deployed over it, and at least no common upper limit larger options deployed over it, and at least no common upper limit
is yet known to have been encoded by its implementors. It is is yet known to have been encoded by its implementors. It is
skipping to change at page 10, line 41 skipping to change at page 10, line 40
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
preferable to use a second stage configuration. Some examples of preferable to use a second stage configuration. Some examples of
this are to provide TFTP server and pathnames, or a URL, which the this are to provide TFTP server and pathnames, or a URL, which the
client will load and process externally to the DHCP protocol. client will load and process externally to the DHCP protocol.
The DHCPv4 code and length tags are each a single byte. As the The DHCPv4 code and length tags are each a single octet. As the
length field describes the length of the DHCP option's contents (not length field describes the length of the DHCP option's contents (not
including the code and length bytes), any option whose contents' including the code and length octets), any option whose contents'
length exceeds 255 bytes can not be contained in a single option. length exceeds 255 octets can not be contained in a single option.
These 'long options' will simply be fragmented into multiple options These 'long options' will simply be fragmented into multiple options
within the packet. DHCP software processing these fragments will within the packet. DHCP software processing these fragments will
concatenate them, in the order they appear as defined by [RFC2131], concatenate them, in the order they appear as defined by [RFC2131],
prior to evaluating their contents. This is an important distinction prior to evaluating their contents. This is an important distinction
that is sometimes overlooked by authors - these multiple options are that is sometimes overlooked by authors - these multiple options are
not individually formatted to convey one unit of information not individually formatted to convey one unit of information
precisely as you have defined, but rather one option that has been precisely as you have defined, but rather one option that has been
split along any arbitrary octet boundary into multiple containers. split along any arbitrary octet boundary into multiple containers.
When documenting an example, then, try to make sure that the division When documenting an example, then, try to make sure that the division
point you select as an example does not lie on a clean division of point you select as an example does not lie on a clean division of
your option contents - place it at an offset so as to reinforce that your option contents - place it at an offset so as to reinforce that
these values must be concatenated rather than processed individually. these values must be concatenated rather than processed individually.
DHCPv4 option fragments are a basic protocol feature, so there DHCPv4 option fragments are a basic protocol feature, so there
usually is no reason to mention this feature in new option usually is no reason to mention this feature in new option
definitions, and no requirement for every option definition to be definitions, and no requirement for every option definition to be
presented as a series of fragments. It is only recommended to presented as a series of fragments. It is only recommended to
reinforce the existence of DHCP option fragmentation when the reinforce the existence of DHCP option fragmentation when the
skipping to change at page 11, line 21 skipping to change at page 11, line 21
usually is no reason to mention this feature in new option usually is no reason to mention this feature in new option
definitions, and no requirement for every option definition to be definitions, and no requirement for every option definition to be
presented as a series of fragments. It is only recommended to presented as a series of fragments. It is only recommended to
reinforce the existence of DHCP option fragmentation when the reinforce the existence of DHCP option fragmentation when the
potential for large options is likely. In this case, try to choose a potential for large options is likely. In this case, try to choose a
large example data value. large example data value.
Note that option fragmentation is also a very common side-effect of Note that option fragmentation is also a very common side-effect of
running out of options space, and moving to overloaded FILE or SNAME running out of options space, and moving to overloaded FILE or SNAME
fields. Although the option may be considerably shorter than 255 fields. Although the option may be considerably shorter than 255
bytes, if it does not fit in the remaining space then software may octets, if it does not fit in the remaining space then software may
consume all remaining options space with one option fragment, and consume all remaining options space with one option fragment, and
place the remainder in an overloaded field. place the remainder in an overloaded field.
Primarily it is important to remember that DHCPv4 differs from DHCPv6 Primarily it is important to remember that DHCPv4 differs from DHCPv6
on this point: DHCPv4 can only convey one option of a given option on this point: DHCPv4 can only convey one option of a given option
code at any time - additional options (or sub options) of the same code at any time - additional options (or possibly sub options, which
code will be concatenated together and processed at once. DHCPv6 do not have concisely defined semantics) of the same code will be
does allow multiple instances of a given option, and they are treated concatenated together and processed at once. DHCPv6 does allow
as distinct values following the defined format, however this feature multiple instances of a given option, and they are treated as
is generally preferred to be restricted to protocol class features distinct values following the defined format, however this feature is
(such as the IA_* series of options); it is better to define your generally preferred to be restricted to protocol class features (such
option as an array if it is possible. as the IA_* series of options); it is better to define your option as
an array if it is possible.
So remember that it is out of the question to define a case for So remember that it is out of the question to define a case for
multiple instances of your option in DHCPv4, and it is recommended to multiple instances of your option in DHCPv4, and it is recommended to
clarify (with normative language) if any DHCPv6 option may appear clarify (with normative language) if any DHCPv6 option may appear
once or multiple times. once or multiple times.
10. Clients Request their Options 10. Clients Request their Options
The DHCPv4 Parameter Request List [RFC2132], and the DHCPv6 Option The DHCPv4 Parameter Request List [RFC2132], and the DHCPv6 Option
Request Option (OPTION_ORO) [RFC3315], are both options that serve Request Option (OPTION_ORO) [RFC3315], are both options that serve
skipping to change at page 17, line 8 skipping to change at page 17, line 8
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.
A.1. Atomic DHCP A.1. Atomic DHCP
To accomplish these goals, a common "Format String" is used to To accomplish these goals, a common "Format String" is used to
describe, in abstract, all of the above. Each byte in this format describe, in abstract, all of the above. Each octet 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's forming a sort of molecular structure for a particular DHCP option's
defined format. defined format.
The Configuration Syntax allows the user to construct such a format The Configuration Syntax allows the user to construct such a format
string without having to understand how the Atom is encoded on the string without having to understand how the Atom is encoded on the
wire, and how it is configured or presented. wire, and how it is configured or presented.
You can reasonably imagine that the various common formats of DHCP You can reasonably imagine that the various common formats of DHCP
options described above (Table 1) each have an Atom associated with options described above (Table 1) each have an Atom associated with
skipping to change at page 18, line 24 skipping to change at page 18, line 24
supplies a value to be transmitted on the wire, relying on the above supplies a value to be transmitted on the wire, relying on the above
format definition. format definition.
option dhcp.path-mtu-plataeu-table 4352, 1500, 576; option dhcp.path-mtu-plataeu-table 4352, 1500, 576;
option dhcp.static-routes 10.10.10.10 10.10.10.9, option dhcp.static-routes 10.10.10.10 10.10.10.9,
10.10.10.11 10.10.10.9; 10.10.10.11 10.10.10.9;
Author's Address Author's Address
David W. Hankins David W. Hankins
Internet Systems Consortium, Inc. Google, Inc.
950 Charter Street 1600 Amphitheatre Parkway
Redwood City, CA 94063 Mountain View, CA 94043
US USA
Phone: +1 650 423 1307 Email: dhankins@google.com
Email: David_Hankins@isc.org
 End of changes. 34 change blocks. 
77 lines changed or deleted 72 lines changed or added

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