draft-ietf-dhc-concat-03.txt   draft-ietf-dhc-concat-04.txt 
Network Working Group Ted Lemon Network Working Group Ted Lemon
Internet Draft Nominum, Inc. Internet Draft Nominum, Inc.
Stuart Cheshire Obsoletes: draft-ietf-dhc-concat-03.txt Stuart Cheshire
Apple Computer, Inc. Category: Standards Track Apple Computer, Inc.
Obsoletes: draft-ietf-dhc-concat-02.txt April, 2002 July, 2002
Expires October, 2002 Expires January, 2003
Encoding Long DHCP Options Encoding Long Options in DHCPv4
<draft-ietf-dhc-concat-03.txt> <draft-ietf-dhc-concat-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of Section 10 of RFC2026.
This document is an Internet-Draft. Internet-Drafts are working Internet-Drafts are working documents of the Internet Engineering
documents of the Internet Engineering Task Force (IETF), its areas, Task Force (IETF), its areas, and its working groups. Note that
and its working groups. Note that other groups may also distribute other groups may also distribute working documents as
working documents as Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-
material or to cite them other than as "work in progress". Drafts as reference 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/1id-abstracts.html
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
Abstract Abstract
This document specifies the processing rules for DHCP options that This document specifies the processing rules for DHCPv4 options
appear multiple times in the same message. Multiple instances of that appear multiple times in the same message. Multiple
the same option are generated when an option exceeds 255 octets in instances of the same option are generated when an option exceeds
size (the maximum size of a single option) or when an option needs 255 octets in size (the maximum size of a single option) or when
to be split apart in order to take advantage of DHCP option an option needs to be split apart in order to take advantage of
overloading (Dynamic Host Configuration Protocol [1], Section 4.1. DHCP option overloading. When multiple instances of the same
When multiple instances of the same option appear in the options, option appear in the options, file and/or sname fields in a DHCP
file and/or sname fields in a DHCP packet, the contents of these packet, the contents of these options are concatenated together
options are concatenated together to form a single option prior to to form a single option prior to processing.
processing.
This draft specifies how DHCP options in a DHCP packet can be
aggregated so that DHCP protocol agents can send options that are
more than 255 bytes in length.
Introduction Introduction
The DHCP protocol [1] specifies objects called "options" that are This document updates RFC2131 [1] by clarifying the rules for
encoded in the DHCP packet to pass information between DHCP option concatenation specified in section 4.1. It is expected
protocol agents. These options are encoded as a one-byte type that the reader will be familiar with this portion of RFC2131.
code, a one-byte length, and a buffer consisting of the number of The text in section 4.1 that reads "Options may appear only
bytes specified in the length, from zero to 255. once, unless otherwise specified in the options document."
should considered to be deleted.
In some cases it may be useful to send DHCP options that are The DHCP protocol [1] specifies objects called "options" that
are encoded in the DHCPv4 packet to pass information between
^L
DHCP protocol agents. These options are encoded as a one-byte
type code, a one-byte length, and a buffer consisting of the
number of bytes specified in the length, from zero to 255.
In some cases it may be useful to send options that are
longer than 255 bytes, however. RFC2131 [1] specifies that when longer than 255 bytes, however. RFC2131 [1] specifies that when
more than one option with a given type code appears in the DHCP more than one option with a given type code appears in the DHCP
packet, all such options should be concatenated together. It packet, all such options should be concatenated together. It
does not, however, specify the order in which this concatenation does not, however, specify the order in which this concatenation
should occur. should occur.
We specify here the ordering that MUST be used by DHCP protocol We specify here the ordering that MUST be used by DHCP protocol
agents when sending options with more than 255 bytes. This method agents when sending options with more than 255 bytes. This
also MUST be used for splitting options that are shorter than 255 method also MUST be used for splitting options that are shorter
bytes, if for some reason the encoding agent needs to do so. This than 255 bytes, if for some reason the encoding agent needs to do
method also MUST be used whenever a decoding agent receives a DHCP so. DHCP protocol agents MUST use this method whenever they
packet containing more than one of a certain type of option. receive a DHCP packet containing more than one of a certain type
of option.
Terminology Terminology
DHCP
Throughout this document, the acronym "DHCP" is used to refer
to the Dynamic Host Configuration Protocol as specified in
RFC2131 [1] and RFC2132 [2].
DHCPv4
We have used the term "DHCPv4" in the abstract for this
document to distinguish between the DHCP protocol for IPv4 as
defined in RFC2131 and RFC2132 and the DHCP protocol for IPv6,
which, at the time that this document is being written, is
still under development.
DHCP protocol agents DHCP protocol agents
This refers to any device on the network that sends or This refers to any device on the network that sends or
receives DHCP packets - any DHCP client, server or relay receives DHCP packets - any DHCP client, server or relay
agent. The nature of these devices is not important to this agent. The nature of these devices is not important to this
specification. specification.
Encoding agent Encoding agent
The DHCP protocol agent that is composing a DHCP packet to The DHCP protocol agent that is composing a DHCP packet to
send. send.
Decoding agent Decoding agent
The DHCP protocol agent that is processing a DHCP packet it The DHCP protocol agent that is processing a DHCP packet it
skipping to change at line 97 skipping to change at page 3, line 4
indicate how the options should be used. Options can specify indicate how the options should be used. Options can specify
information that is required for the DHCP protocol, information that is required for the DHCP protocol,
IP stack configuration parameters for the client, information IP stack configuration parameters for the client, information
allowing the client to rendezvous with DHCP servers, and so allowing the client to rendezvous with DHCP servers, and so
on. on.
Option overload Option overload
The DHCP packet format is based on the BOOTP packet format The DHCP packet format is based on the BOOTP packet format
defined in RFC951 [4]. When used by DHCP protocol agents, defined in RFC951 [4]. When used by DHCP protocol agents,
BOOTP packets have three fields that can contain options. BOOTP packets have three fields that can contain options.
These are the optional parameters field, the sname field, These are the optional parameters field, the sname field,
^L
and the filename field. The DHCP options specification [2] and the filename field. The DHCP options specification [2]
defines the DHCP Overload option, which specifies which of defines the DHCP Overload option, which specifies which of
these three fields is actually being used in any given DHCP these three fields is actually being used in any given DHCP
message to store DHCP options. message to store DHCP options.
Requirements language Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", In this document, the key words "MAY", "MUST, "MUST NOT",
"OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in RFC2119 [3]. interpreted as described in RFC2119 [3].
Applicability Applicability
This specification applies when a DHCP agent is encoding a packet This specification applies when a DHCP agent is encoding a
containing options, and some of those options must be broken into packet containing options, and some of those options must be
parts. This need can occur for two reasons. First, it can occur broken into parts. This need can occur for two reasons.
because the value of an option that needs to be sent is longer than First, it can occur because the value of an option that needs
255 bytes. In this case, the encoding agent MUST follow the algo- to be sent is longer than 255 bytes. In this case, the
rithm specified here. It can also occur because there is not suff- encoding agent MUST follow the algorithm specified here.
icient space in the current output buffer to store the option, but It can also occur because there is not suff- icient space in
there is space for part of the option, and there is space in another the current output buffer to store the option, but there is
space for part of the option, and there is space in another
output buffer for the rest. In this case, the encoding agent output buffer for the rest. In this case, the encoding agent
MUST either use this algorithm or not send the option at all. MUST either use this algorithm or not send the option at all.
This specification also applies in any case where a DHCP protocol This specification also applies in any case where a DHCP
agent has received a DHCP packet that contains more than one protocol agent has received a DHCP packet that contains more
instance of an option of a given type. In this case, the agent than one instance of an option of a given type. In this
MUST concatenate these seperate instances of the same option in the case, the agent MUST concatenate these separate instances of
way that we specify here. the same option in the way that we specify here.
This option updates the Dynamic Host Configuration Protocol [1]
and DHCP Options and BOOTP vendor extensions [2] documents.
However, because many currently-deployed DHCP protocol agents
do not implement option concatenation, DHCP protocol agents
should be careful not to transmit split options unless either
it will not matter if the recipient cannot correctly reassemble
the options, or it is certain that the recipient implements
concatenation.
Let us divide all DHCP options into two categories - those
that, by definition, require implementation of the mechanisms
defined in this document, and those that do not. We will
refer to the former as concatenation-requiring options, and
the latter as non-concatenation-requiring options. In order
for an option to be a concatenation-requiring option, the
protocol specification that defines that option must require
implementation of option splitting and option concatenation
as described in this document, by specifically referencing
this document.
A DHCP protocol agent SHOULD NOT split an option as described
in this document unless at least one of these apply:
^L
- The option is a concatenation-requiring option.
- The message being generated is in response to a message
containing a concatenation-requiring option.
- The message being generated is in response to a message
that requests a concatenation-requiring option.
- The administrator of the agent generating the option has
specifically configured it to assume that the recipient
can correctly concatenate options split as described in
this document.
Some implementors may find it easiest to only split concatena-
tion-requiring options, and never split non-concatenation-
requiring options. This is permissible. However, an implement-
ation which supports any concatenation-requiring option MUST be
capable of concatenating received options for both concatena-
tion-requiring and non-concatenation-requiring options.
No restrictions apply to option concatenation when a DHCP agent
receives a DHCP message. Any DHCP protocol agent that implements
the mechanisms described in this document can assume that when it
receives two options of the same type, it should concatenate
them.
The aggregate option buffer The aggregate option buffer
DHCP options can be stored in the DHCP packet in three seperate DHCP options can be stored in the DHCP packet in three separate
portions of the packet. These are the optional parameters field, portions of the packet. These are the optional parameters field,
the sname field, and the file field, as described in RFC2131 [1]. the sname field, and the file field, as described in RFC2131 [1].
This complicates the description of the option splitting This complicates the description of the option splitting
mechanism because there are three seperate fields into which mechanism because there are three separate fields into which
split options may be placed. split options may be placed.
To further complicate matters, an option that doesn't fit into To further complicate matters, an option that doesn't fit into
one field can't overlap the boundary into another field - the one field can't overlap the boundary into another field - the
encoding agent must instead break the option into two parts and encoding agent must instead break the option into two parts and
store one part in each buffer. store one part in each buffer.
To simplify this discussion, we will talk about an aggregate To simplify this discussion, we will talk about an aggregate
option buffer, which will be the aggregate of the three buffers. option buffer, which will be the aggregate of the three buffers.
This is a logical aggregation - the buffers MUST appear in the This is a logical aggregation - the buffers MUST appear in the
skipping to change at line 158 skipping to change at page 5, line 4
WARNING: This is not the physical ordering of these fields in the WARNING: This is not the physical ordering of these fields in the
DHCP packet. DHCP packet.
Options MUST NOT be stored in the aggregate option buffer in such Options MUST NOT be stored in the aggregate option buffer in such
in such a way that they cross either boundary between the three in such a way that they cross either boundary between the three
fields in the aggregate buffer. fields in the aggregate buffer.
The encoding agent is free to choose to use either or both of the The encoding agent is free to choose to use either or both of the
sname field and file field. If the encoding agent does not choose sname field and file field. If the encoding agent does not choose
to use either or both of these two fields, then they MUST NOT be to use either or both of these two fields, then they MUST NOT be
^L
considered part of the aggregate option buffer in that case. considered part of the aggregate option buffer in that case.
Encoding agent behaviour Encoding agent behavior
Encoding agents decide to split options based on the reasons we Encoding agents decide to split options based on the reasons we
have described in the preceding section entitled "applicability." have described in the preceding section entitled "applicability."
Options can be split on any octet boundary. No split portion of Options can be split on any octet boundary. No split portion of
an option that has been split can contain more than 255 octets. an option that has been split can contain more than 255 octets.
The split portions of the option MUST be stored in the aggregate The split portions of the option MUST be stored in the aggregate
option buffer in sequential order - the first split portion MUST option buffer in sequential order - the first split portion MUST
be stored first in the aggregate option buffer, then the second be stored first in the aggregate option buffer, then the second
portion, and so on. The encoding agent MUST NOT attempt to portion, and so on. The encoding agent MUST NOT attempt to
skipping to change at line 189 skipping to change at page 5, line 37
and the third part would go into the sname field. This and the third part would go into the sname field. This
maintains consistency with section 4.1 of RFC2131 [1]. maintains consistency with section 4.1 of RFC2131 [1].
Each split portion of an option MUST be stored in the aggregate Each split portion of an option MUST be stored in the aggregate
option buffer as if it were a normal variable-length option as option buffer as if it were a normal variable-length option as
described in RFC2132 [2]. The length fields of each split portion described in RFC2132 [2]. The length fields of each split portion
of the option MUST add up to the total length of the option data. of the option MUST add up to the total length of the option data.
For any given option being split, the option code field in each For any given option being split, the option code field in each
split portion MUST be the same. split portion MUST be the same.
Decoding agent behaviour Decoding agent behavior
When a decoding agent is scanning an incoming DHCP packet's When a decoding agent is scanning an incoming DHCP packet's
option buffer and finds two or more options with the same option option buffer and finds two or more options with the same option
code, it MUST consider them to be split portions of an option as code, it MUST consider them to be split portions of an option as
described in the preceding section. described in the preceding section.
In the case that a decoding agent finds a split option, it MUST In the case that a decoding agent finds a split option, it MUST
treat the contents of that option as a single option, and the treat the contents of that option as a single option, and the
contents MUST be reassembled in the order that was described above contents MUST be reassembled in the order that was described above
under encoding agent behaviour. under encoding agent behavior.
The decoding agent should ensure that when the option's The decoding agent should ensure that when the option's
value is used, any alignment issues that are particular to the value is used, any alignment issues that are particular to the
machine architecture on which the decoding agent is running are machine architecture on which the decoding agent is running are
accounted for - there is no requirement that the encoding agent accounted for - there is no requirement that the encoding agent
align the options in any particular way. align the options in any particular way.
There is no semantic meaning to where an option is split - the There is no semantic meaning to where an option is split - the
encoding agent is free to split the option at any point, and the encoding agent is free to split the option at any point, and the
decoding agent MUST reassemble the split option parts into a decoding agent MUST reassemble the split option parts into a
single object, and MUST NOT treat each split portion of the option single object, and MUST NOT treat each split portion of the option
as a seperate object. as a separate object.
^L
Example Example
Consider an option, Bootfile name (option code 67), with a value Consider an option, Bootfile name (option code 67), with a value
of "/diskless/foo". Normally, this would be encoded as a single of "/diskless/foo". Normally, this would be encoded as a single
option, as follows: option, as follows:
+----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+ +----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 67 | 13 | / | d | i | s | k | l | e | s | s | / | f | o | o | | 67 | 13 | / | d | i | s | k | l | e | s | s | / | f | o | o |
+----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+ +----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+
If an encoding agent needed to split the option in order to fit If an encoding agent needed to split the option in order to fit
it into the option buffer, it could encode it as two seperate it into the option buffer, it could encode it as two separate
options, as follows, and store it in the aggregate option buffer options, as follows, and store it in the aggregate option buffer
in the following sequence: in the following sequence:
+----+---+---+---+---+---+---+---+---+ +----+---+---+---+---+---+---+---+---+
| 67 | 7 | / | d | i | s | k | l | e | | 67 | 7 | / | d | i | s | k | l | e |
+----+---+---+---+---+---+---+---+---+ +----+---+---+---+---+---+---+---+---+
+----+---+---+---+---+---+---+---+ +----+---+---+---+---+---+---+---+
| 67 | 6 | s | s | / | f | o | o | | 67 | 6 | s | s | / | f | o | o |
+----+---+---+---+---+---+---+---+ +----+---+---+---+---+---+---+---+
Security Considerations Security Considerations
This document raises no new security issues. Potential exposures This document raises no new security issues. Potential exposures
to attack in the DHCP protocol are discussed in section 7 of the to attack in the DHCP protocol are discussed in section 7 of the
DHCP protocol specification RFC2131 [1]. DHCP protocol specification [1] and in Authentication for DHCP
Messages [5].
Note that the authentication option itself can be split; in such
cases implementations must be careful when setting the authenti-
cation field to zero (prior to generation or verification of the
MAC) as it may be split across multiple options.
References References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
Bucknell University, March 1997. Bucknell University, March 1997.
[2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell
University, March 1997. University, March 1997.
[3] Bradner, S., "Key words for use in RFCs to indicate requirement [3] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, Harvard University, March 1997. levels", RFC 2119, Harvard University, March 1997.
[4] Croft, W., Gilmore, J., "BOOTSTRAP PROTOCOL (BOOTP)", RFC951, [4] Croft, W., Gilmore, J., "BOOTSTRAP PROTOCOL (BOOTP)", RFC951,
Stanford University, Sun Microsystems, September 1985. Stanford University, Sun Microsystems, September 1985.
[5] R. Droms, W. Arbaugh, "Authentication for DHCP Messages",
RFC3118, Cisco Systems, University of Maryland, June 2001.
^L
Author Information Author Information
Ted Lemon Ted Lemon
Nominum, Inc. Nominum, Inc.
2385 Bay Road 2385 Bay Road
Redwood City, CA 94043 Redwood City, CA 94043
USA USA
email: mellon@nominum.com email: mellon@nominum.com
skipping to change at line 274 skipping to change at line 354
Apple Computer, Inc. Apple Computer, Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino Cupertino
California 95014 California 95014
USA USA
Phone: +1 408 974 3207 Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org EMail: rfc@stuartcheshire.org
Expiration Expiration
This document will expire on October 31, 2002. This document will expire on December 31, 2002.
Full Copyright Statement Full Copyright Statement
Copyright (C) 2001-2002 The Internet Society. All Rights Reserved. Copyright (C) 2001-2002 The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/