draft-ietf-dhc-concat-01.txt   draft-ietf-dhc-concat-02.txt 
Network Working Group Ted Lemon Network Working Group Ted Lemon
Internet Draft Nominum, Inc. Internet Draft Nominum, Inc.
Stuart Cheshire
Apple Computer, Inc.
New draft July, 2001 Obsoletes: draft-ietf-dhc-concat-01.txt October, 2001
Expires January, 2002 Expires April, 2002
Encoding Long DHCP Options Encoding Long DHCP Options
<draft-ietf-dhc-concat-01.txt> <draft-ietf-dhc-concat-02.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 in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at line 52 skipping to change at line 54
code, a one-byte length, and a buffer consisting of the number of code, a one-byte length, and a buffer consisting of the number of
bytes specified in the length, from zero to 255. bytes specified in the length, from zero to 255.
In some cases it may be useful to send DHCP options that are In some cases it may be useful to send DHCP 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 an ordering that can be used by DHCP protocol We specify here the ordering that MUST be used by DHCP protocol
agents when sending and receiving options with more than 255 agents when sending options with more than 255 bytes. This method
bytes. DHCP protocol agents MAY use the ordering described here also MUST be used for splitting options that are shorter than 255
to encode existing options if such options exceed 255 bytes in bytes, if for some reason the encoding agent needs to do so. This
length. The main purpose of this specification, however, is to method also MUST be used whenever a decoding agent receives a DHCP
provide a specification that new DHCP option drafts can packet containing more than one of a certain type of option.
reference.
Terminology Terminology
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
has received. has received.
Options Options
DHCP options are collections of data with type codes that DHCP options are collections of data with type codes that
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 rendesvous 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 [4]. When used by DHCP protocol agents, BOOTP defined in RFC951 [4]. When used by DHCP protocol agents,
packets have three fields that can contain options. These BOOTP packets have three fields that can contain options.
are the actual option buffer, the server name buffer, and the These are the optional parameters field, the sname field,
filename buffer. The DHCP options specification [2] defines and the filename field. The DHCP options specification [2]
the DHCP Overload option, which specifies which of these three defines the DHCP Overload option, which specifies which of
buffers is actually being used in any given DHCP message to these three fields is actually being used in any given DHCP
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 [3]. interpreted as described in RFC2119 [3].
Applicability Applicability
This specification applies in any case where a DHCP protocol This specification applies when a DHCP agent is encoding a packet
agent is encoding a packet containing options, and some of those containing options, and some of those options must be broken into
options must be broken into parts. This can occur either because parts. This need can occur for two reasons. First, it can occur
such an option is longer than 255 bytes, or because there is not because the value of an option that needs to be sent is longer than
sufficient space in the current output buffer to store the 255 bytes. In this case, the encoding agent MUST follow the algo-
option, but there is space for part of the option, and there is rithm specified here. It can also occur because there is not suff-
space in another output buffer for the rest. DHCP protocol icient space in the current output buffer to store the option, but
agents encoding an option in this case MAY use the algorithm there is space for part of the option, and there is space in another
specified here. output buffer for the rest. In this case, the encoding agent
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 protocol
agent has received a DHCP packet that contains more than one agent has received a DHCP packet that contains more than one
instance of an option of a given type. DHCP protocol agents instance of an option of a given type. In this case, the agent
that are decoding such options MAY follow the algorithm specified MUST concatenate these seperate instances of the same option in the
here. way that we specify here.
The rationale for making this optional is that existing
implementations have not been subject to a requirement to encode
or decode options in this way, and it is not our intention to
potentially cause existing implementations to be in violation of
this specification.
The aggregate option buffer The aggregate option buffer
This behaviour only applies in cases where this specification is
applicable, as previously defined in the Applicability section.
DHCP options can be stored in the DHCP packet in three seperate DHCP options can be stored in the DHCP packet in three seperate
portions of the packet. These are the optional parameters portions of the packet. These are the optional parameters field,
field, the sname field, and the file field, as described in [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 buffers into which mechanism because there are three seperate fields into which
split options may be stored. 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 buffer can't overlap the boundary into another buffer - 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
locations in the DHCP packet described in [1]. locations in the DHCP packet described in RFC2131 [1].
The aggregate option buffer is made up of the optional parameters The aggregate option buffer is made up of the optional parameters
field, the file field, and the sname field, in that order. field, the file field, and the sname field, in that order.
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
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
considered part of the aggregate option buffer in that case.
Encoding agent behaviour Encoding agent behaviour
Encoding agents MAY split options as described in this Encoding agents decide to split options based on the reasons we
specification. Encoding agents supporting options that require have described in the preceding section entitled "applicability."
this MUST split options as described here, if it is necessary to
do so in order to encode the entire contents of the option.
Options MAY 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. portion, and so on. The encoding agent MUST NOT attempt to
specify any semantic information based on how the option is
split.
Note that because the aggregate option buffer does not represent Note that because the aggregate option buffer does not represent
the physical ordering of the DHCP packet, if an option were split the physical ordering of the DHCP packet, if an option were split
into three parts and each part went into one of the possible into three parts and each part went into one of the possible
option fields, the first part would go into the optional option fields, the first part would go into the optional
parameters field, the second part would go into the file field, parameters field, the second part would go into the file field,
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 [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 in the same way that a full option would be stored option buffer as if it were a normal variable-length option as
- each portion contains a single byte option type code, and then described in RFC2132 [2]. The length fields of each split portion
a single byte indicating the length of the portion of the option of the option MUST add up to the total length of the option data.
payload being stored in that portion, and then the payload For any given option being split, the option code field in each
itself. The length byte MUST NOT include itself or the option split portion MUST be the same.
code. For any given option being split, the option code MUST be
the same.
Decoding agent behaviour Decoding agent behaviour
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 MAY consider them to be a split option as described code, it MUST consider them to be split portions of an option as
here. Decoding agents that support options that require the described in the preceding section.
behaviour described in this draft MUST consider such options to
be split.
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 ordered as described above under encoding agent contents MUST be reassembled in the order that was described above
behaviour. The decoding agent MUST ensure that when the under encoding agent behaviour.
option's value is used, any alignment issues that are particular
to the machine architecture on which the decoding agent is The decoding agent should ensure that when the option's
running are accounted for - there is no requirement that the value is used, any alignment issues that are particular to the
encoding agent align the options in any particular way. machine architecture on which the decoding agent is running are
accounted for - there is no requirement that the encoding agent
align the options in any particular way.
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
decoding agent MUST reassemble the split option parts into a
single object, and MUST NOT treat each split portion of the option
as a seperate object.
Example Example
Consider an option, option 224, with a value of "isc.org.". Consider an option, Bootfile name (option code 67), with a value
Normally, this would be encoded as a single option, as follows: of "/diskless/foo". Normally, this would be encoded as a single
option, as follows:
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 224 | 8 | 'i' | 's' | 'c' | '.' | 'o' | 'r' | 'g' | '.' | | 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 seperate
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:
+-----+-----+-----+-----+-----+-----+-----+ +----+---+---+---+---+---+---+---+---+
| 224 | 5 | 'i' | 's' | 'c' | '.' | 'o' | | 67 | 7 | / | d | i | s | k | l | e |
+-----+-----+-----+-----+-----+-----+-----+ +----+---+---+---+---+---+---+---+---+
+-----+-----+-----+-----+-----+ +----+---+---+---+---+---+---+---+
| 224 | 3 | 'r' | 'g' | '.' | | 67 | 6 | s | s | / | f | o | o |
+-----+-----+-----+-----+-----+ +----+---+---+---+---+---+---+---+
Security Considerations Security Considerations
DHCP currently provides no authentication or security mechanisms. This document raises no new security issues. Potential exposures
Potential exposures to attack are discussed in section 7 of the DHCP to attack in the DHCP protocol are discussed in section 7 of the
protocol specification [1]. The Classless Static Routes option can DHCP protocol specification RFC2131 [1].
be used to misdirect network traffic by providing incorrect IP
addresses for routers.
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] Mogul, J., Postel, J., "Internet Standard Subnetting [4] Croft, W., Gilmore, J., "BOOTSTRAP PROTOCOL (BOOTP)", RFC951,
Procedure", RFC950, Stanford University, USC/Information Stanford University, Sun Microsystems, September 1985.
Sciences Institute, August 1985.
Author Information Author Information
Ted Lemon Ted Lemon
Nominum, Inc. Nominum, Inc.
950 Charter Street 950 Charter Street
Redwood City, CA 94043 Redwood City, CA 94043
email: mellon@nominum.com USA
email: Ted.Lemon@nominum.com
Stuart Cheshire
Apple Computer, Inc.
1 Infinite Loop
Cupertino
California 95014
USA
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
Expiration Expiration
This document will expire on January 31, 2002. This document will expire on April 31, 2002.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). 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/