draft-ietf-dhc-option-guidelines-02.txt   draft-ietf-dhc-option-guidelines-03.txt 
Dynamic Host Configuration Working D. Hankins Dynamic Host Configuration Working D. Hankins
Group ISC Group ISC
Intended status: Informational Intended status: Informational
Expires: March 12, 2009 Expires: April 17, 2009
Guidelines for Creating New DHCP Options Guidelines for Creating New DHCP Options
draft-ietf-dhc-option-guidelines-02 draft-ietf-dhc-option-guidelines-03
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 March 12, 2009. This Internet-Draft will expire on April 17, 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. Avoid 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 . . . . . . . . . . . . . . . . 10 9. Clients Request their Options . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Background on ISC DHCP . . . . . . . . . . . . . . . 11 Appendix A. Background on ISC DHCP . . . . . . . . . . . . . . . 11
Appendix A.1. Atomic DHCP . . . . . . . . . . . . . . . . . . . . 13 Appendix A.1. Atomic DHCP . . . . . . . . . . . . . . . . . . . . 13
12. Informative References . . . . . . . . . . . . . . . . . . . . 14 12. Informative References . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 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 question is whether the proposed protocol
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. As an aide to understanding
the potential implementation challenges of any new DHCP Option, one the potential implementation challenges of any new DHCP Option, one
implementation's approach to tackling DHCP Option formats implementation's approach to tackling DHCP Option formats
(Appendix A) has been included in an Appendix. (Appendix A) has been included in an Appendix.
Another, and more frequently overlooked, aspect of rapid adoption is Another, and more frequently overlooked, aspect of rapid adoption is
skipping to change at page 4, line 7 skipping to change at page 4, line 7
The presence of such a knob isn't enough, however, because The presence of such a knob isn't enough, however, because
secondarily, DHCP also presents the extension of an administrative secondarily, DHCP also presents the extension of an administrative
domain - that of the systems operator of the network to which the domain - that of the systems operator of the network to which the
client is currently attached. Someone runs not only the local client is currently attached. Someone runs not only the local
switching network infrastructure that the client is directly (or switching network infrastructure that the client is directly (or
wirelessly) attached to, but the various methods of accessing the wirelessly) attached to, but the various methods of accessing the
external Internet via local assist services that network must also external Internet via local assist services that network must also
provide (such as domain name servers, or routers). This means that provide (such as domain name servers, or routers). This means that
in addition to the existence of a configuration parameter, one must in addition to the existence of a configuration parameter, one must
also ask themselves if it is reasoanble for this parameter to be set also ask themselves if it is reasonable for this parameter to be set
by the DHCP server operator. by the DHCP server operator.
Bear in mind that the client still reserves the right to over-ride or Bear in mind that the client still reserves the right to over-ride or
ignore values received via DHCP (for example, due to having a ignore values received via DHCP (for example, due to having a value
manually configured value by its operator), and that at least one manually configured by its operator), and that at least one main use
main use case for DHCP is the corporate enterprise - so even if the case for DHCP is the corporate enterprise - so even if the local Net
local Net Cafe is not a suitable source of this configuration, it is Cafe is not a suitable source of this configuration, it is likely
likely that the client will at some point return to a network whose that the client will at some point return to a network whose operator
operator is also the system's rightful master. is also the system's rightful master.
3. General Principles 3. General Principles
The primary principle to follow in order to enhance an option's The primary principle to follow in order to enhance an option's
adoptability is certainly simplification. But more specifically, to adoptability is certainly simplification. But more specifically, to
create the option in such a way that it should not require any new or create the option in such a way that it should not require any new or
special case software to support. If old software currently deployed special case software to support. If old software currently deployed
and in the field can adopt the option through supplied configuration and in the field can adopt the option through supplied configuration
conveniences then it's fairly well assured that new software can conveniences then it's fairly well assured that new software can
easily formally adopt it. easily formally adopt it.
There are at least two classes of DHCP options. A bulk class of There are at least two classes of DHCP options: A bulk class of
options which are provided explicitly to carry data from one side of options which are provided explicitly to carry data from one side of
the DHCP exchange to the other (such as nameservers, domain names, or the DHCP exchange to the other (such as nameservers, domain names, or
time servers), and a protocol class of options which require special time servers), and a protocol class of options which require special
processing on the part of the DHCP software or are used during processing on the part of the DHCP software or are used during
special processing (such as the FQDN options ([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).
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
skipping to change at page 5, line 20 skipping to change at page 5, line 20
allocated, and consider which of those solve a similar problem. It allocated, and consider which of those solve a similar problem. It
may even be that an option that solves the problem already exists. may even be that an option that solves the problem already exists.
But as there are so many options to choose from, this isn't entirely But as there are so many options to choose from, this isn't entirely
practical. So, the following list of common option formats is practical. So, the following list of common option formats 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.
Common Option Fragments
+---------------+-------+-------------------------------------------+ +---------------+-------+-------------------------------------------+
| Fragment | Size | Types of Uses | | Fragment | Size | Types of Uses |
+---------------+-------+-------------------------------------------+ +---------------+-------+-------------------------------------------+
| ipv4-address | 4 | Default gateway, requested address, | | ipv4-address | 4 | Default gateway, requested address, |
| | | subnet mask [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. Deprecated | | 32-bit | 4 | Signed or unsigned varieties. Used for |
| integer | | [RFC4833] use for timezone time offset | | integer | | timezone time offset [RFC2132] |
| | | [RFC2132]. Other uses for host | | | | (deprecated by [RFC4833]). Other uses for |
| | | configuration values such as path mtu | | | | host configuration values such as path |
| | | aging timeouts, arp cache timeouts, tcp | | | | MTU aging timeouts, ARP cache timeouts, |
| | | keepalive intervals [RFC2132]. Also used | | | | TCP keepalive intervals [RFC2132]. Also |
| | | by the DHCPv4 protocol for relative | | | | used by the DHCPv4 protocol for relative |
| | | times, and times since epoch. | | | | times, and times since epoch. |
| 16-bit | 2 | Client configuration parameters, such as | | 16-bit | 2 | Client configuration parameters, such as |
| integer | | MTU, maximum datagram reassembly limits, | | integer | | MTU, maximum datagram reassembly limits, |
| | | the DHCPv4 maximum message size | | | | 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 Table 1: Common Option Fragments
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/
indeterminate length values, consider the use of multiple options or indeterminate length values, consider the use of multiple options or
suboptions. suboptions.
skipping to change at page 7, line 22 skipping to change at page 7, line 14
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 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, use 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. 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
skipping to change at page 7, line 46 skipping to change at page 7, line 38
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
configuring some of the options may influence the others. For configuring some of the options may influence the others. For
example, if an operator configures the URL only, should the server example, if an operator configures the URL only, should the server
synthesize a domain name and ip address? synthesize a domain name and IP address?
A single configuration 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),
late binding (such as with DNS), or completeness (such as with a late binding (such as with DNS), or completeness (such as with a
URL). URL).
7. New Formats 7. New Formats
If the Option simply will not fit into any existing work, the last If the Option simply will not fit into any existing work, the last
recourse is to contrive a new format to fit. recourse is to contrive a new format to fit.
When doing so, it is not enough to gauge 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
skipping to change at page 10, line 8 skipping to change at page 9, line 45
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
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 optoins 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 are formed by elements of the protocol's request list, such as those formed by elements of the protocol's
internal workings, or are formed on either end by DHCP-level software internal workings, or are formed on either end by DHCP-level software
engaged in some exchange of information. When in any form of doubt, engaged in some exchange of information. When in any form of doubt,
assume that any new option must be present on the relevant option assume that any new option must be present on the relevant option
request list if the client desires it. request list if the client desires it.
It is a frequent mistake of option draft authors, then, to create It is a frequent mistake of option draft authors, then, to create
text that implies that a server will simply provide the new option, text that implies that a server will simply provide the new option,
and clients will digest it. Generally, it's best to also specify and clients will digest it. Generally, it's best to also specify
that clients MUST place the new option code on the relevant list that clients MUST place the new option code on the relevant list
option, clients MAY include the new option in their packets to option, clients MAY include the new option in their packets to
skipping to change at page 10, line 42 skipping to change at page 10, line 33
reply. Although the request option does display a preferred reply. Although the request option does display a preferred
priority, which implies an order, a server may shuffle options around 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 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 sort DHCPv6 options into strange orders. There is not one universal
approach. 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 man-in-the-middle.
However, at this date the mechanism is poorly deployed. It also does However, at this date the mechanism is poorly deployed. It also does
not provide end-to-end encryption. not provide end-to-end encryption.
So, while creating a new option, bear in mind that DHCP packet So, while creating a new option, bear in mind that DHCP packet
contents are always transmitted in the clear, and actual production contents are always transmitted in the clear, and actual production
use of the software will probably be vulnerable at least to men in use of the software will probably be vulnerable at least to 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
or multicast addresses that are likely broadcast anyway. or multicast addresses that are likely broadcast anyway.
If an option is of a specific fixed length, it is useful to remind If an option is of a specific fixed length, it is useful to remind
the implementer of the option data's full length. This is easily the implementer of the option data's full length. This is easily
done by declaring the specific value of the 'length' tag of the done by declaring the specific value of the 'length' tag of the
option. This helps to gently remind implementers to validate option option. This helps to gently remind implementers to validate option
length before digesting them into likewise fixed length regions of length before digesting them into likewise fixed length regions of
memory or stack. memory or stack.
If an option may be of variable size (such as having indeterminate If an option may be of variable size (such as having indeterminate
length fields, such as domain names or text strings), it is advisable length fields, such as domain names or text strings), it is advisable
to explicitly remind the implementor to be aware of the potential for to explicitly remind the implementor to be aware of the potential for
long options. Either by defining a reasonable upper limit, or long options. Either define a reasonable upper limit (and suggest
explicitly reminding the implementor that an option may be validating it), or explicitly remind the implementor that an option
exceptionally long. may be exceptionally long (to be prepared to handle errors rather
than truncate values).
For some option contents, "insane values" may be used to breach For some option contents, "insane values" may be used to breach
security. An IP address field might be made to carry a loopback security. An IP address field might be made to carry a loopback
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.
skipping to change at page 12, line 41 skipping to change at page 12, line 32
3. To read the protocol wire format into memory. 3. To read the protocol wire format into memory.
4. To write the in-memory format to persistent storage (to cache 4. To write the in-memory format to persistent storage (to cache
across reboots for example). across reboots for example).
5. To write the in-memory format to a format that can be consumed by 5. To write the in-memory format to a format that can be consumed by
applications. applications.
If every option were formatted differently and uniquely, then we If every option were formatted differently and uniquely, then we
would have to write 6 functions for every option. As there is the would have to write 5 functions for every option. As there is the
potential for as many as 254 DHCPv4 options, or 65536 DHCPv6 options, potential for as many as 254 DHCPv4 options, or 65536 DHCPv6 options,
not to mention the various encapsulated spaces ("suboptions"), this not to mention the various encapsulated spaces ("suboptions"), this
is not scalable. is not scalable.
One simple trick is to make the in-memory format the same as the wire One simple trick is to make the in-memory format the same as the wire
format. This reduces the number of functions required from 5 to 4. format. This reduces the number of functions required from 5 to 3.
This is not always workable - sometimes an intermediary format is This is not always workable - sometimes an intermediate format is
required, but it is a good general case. required, but it is a good general case.
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 4 to applications. This reduces the number of functions again from 3 to
3. 2.
This is still an intractable number of functions per each DHCP This is still an intractable number of functions per each DHCP
option. So, we need a way to reduce this to small orders. option, even without the entire DHCP option space populated. So, we
need a way to reduce this to small orders.
Appendix A.1. Atomic DHCP Appendix A.1. Atomic DHCP
To accomplish these goals, a common "Format String" is used to To accomplish these goals, a common "Format String" is used to
describe, in abstract, all of the above. Each byte in this format describe, in abstract, all of the above. Each byte in this format
string represents a "DHCP Atom". We chain these 'atoms' together, string represents a "DHCP Atom". We chain these 'atoms' together,
forming a sort of molecular structure for a particular DHCP Option. forming a sort of molecular structure for a particular DHCP Option.
Configuration Syntax language allows the user to construct such a The Configuration Syntax allows the user to construct such a format
format string without having to understand how the Atom is encoded on string without having to understand how the Atom is encoded on the
the wire, and how it is configured or presented. wire, and how it is configured or presented.
You can reasonably imagine that the various common formats of DHCP You can reasonably imagine that the various common formats of DHCP
options described above (Table 1) each have an Atom associated with options described above (Table 1) each have an Atom associated with
it. There are special use Atoms, such as one to repeat the previous it. There are special use Atoms, such as one to repeat the previous
Atoms indefinitely (for example, for options with multiple IPv4 Atoms indefinitely (for example, for options with multiple IPv4
addresses one after the other), and one which makes the previous Atom addresses one after the other), and one which makes the previous Atom
optional. optional.
As the software encounters a format string, it processes each Atom As the software encounters a format string, it processes each Atom
individually to read, formulate in memory, or write to output the individually to read, formulate in memory, or write to output the
various option contents. various option contents.
The format strings themselves are either hard coded by the software The format strings themselves are either hard coded by the software
in a table of option definitions, or are compiled at runtime through in a table of option definitions, or are compiled at runtime through
configuration syntax generated by the operator. configuration syntax generated by the operator.
option [space].[option] code [number] = [definition]; option <space>.<option> code <number> = <definition>;
The "space" refers to the option space, which may be the DHCPv4 The <space> refers to the option space, which may be the DHCPv4
option space, the DHCPv6 option space, or any suboption space such as option space, the DHCPv6 option space, or any suboption space such as
the DHCPv4 Relay Agent Information suboptions or similar. the DHCPv4 Relay Agent Information suboptions or similar.
The "option" refers to the option's symbolic name within that space. The <option> refers to the option's symbolic name within that space.
The code number refers to the binary code assigned to this option. The code <number> refers to the binary code assigned to this option.
The definition is a complex statement that brings together DHCP The <definition> is a complex statement that brings together DHCP
Atoms, many of which are the aforementioned common formats, that Atoms, many of which are the aforementioned common formats, that
compose this option. For example, here are two predefined options, compose this option.
as they might have been configured for use by an operator if the
software did not already support them. Below is a sample configuration for two options, whose wire formats
are defined in [RFC2132]. The Path MTU Plateau Table option, and the
Static Routes option.
option dhcp.path-mtu-plateau-table code 25 = option dhcp.path-mtu-plateau-table code 25 =
array of unsigned integer 16; array of unsigned integer 16;
option dhcp.static-routes code 33 = array of { ip-address, option dhcp.static-routes code 33 = array of { ip-address,
ip-address }; ip-address };
Once the options' syntax configuration is out of the way, values to
be carried in the options may be configured. These acts are
distinct; the previous configuration only prepares the parser system
to accept the configuration below. The below configuration actually
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 12. 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.
 End of changes. 34 change blocks. 
70 lines changed or deleted 76 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/