draft-ietf-dhc-concat-00.txt   draft-ietf-dhc-concat-01.txt 
Network Working Group Ted Lemon Network Working Group Ted Lemon
Internet Draft Nominum, Inc. Internet Draft Nominum, Inc.
New draft February, 2001 New draft July, 2001
Expires August, 2001 Expires January, 2002
Encoding Long DHCP Options Encoding Long DHCP Options
<draft-ietf-dhc-concat-00.txt> <draft-ietf-dhc-concat-01.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 159 skipping to change at line 159
Encoding agent behaviour Encoding agent behaviour
Encoding agents MAY split options as described in this Encoding agents MAY split options as described in this
specification. Encoding agents supporting options that require specification. Encoding agents supporting options that require
this MUST split options as described here, if it is necessary to this MUST split options as described here, if it is necessary to
do so in order to encode the entire contents of the option. 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 MAY 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 output The split portions of the option MUST be stored in the aggregate
buffer in sequential order - the first split portion MUST be option buffer in sequential order - the first split portion MUST
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.
Note that because the aggregate option buffer does not represent
the physical ordering of the DHCP packet, if an option were split
into three parts and each part went into one of the possible
option fields, the first part would go into the optional
parameters field, the second part would go into the file field,
and the third part would go into the sname field. This
maintains consistency with section 4.1 of [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 in the same way that a full option would be stored
- each portion contains a single byte option type code, and then - each portion contains a single byte option type code, and then
a single byte indicating the length of the portion of the option a single byte indicating the length of the portion of the option
payload being stored in that portion, and then the payload payload being stored in that portion, and then the payload
itself. The length byte MUST NOT include itself or the option itself. The length byte MUST NOT include itself or the option
code. For any given option being split, the option code MUST be code. For any given option being split, the option code MUST be
the same. the same.
Note that because the aggregate option buffer does not represent
the physical ordering of the DHCP packet, if an option were split
into three parts and each part went into one of the possible
option fields, the first part would go into the optional
parameters field, the second part would go into the file field,
and the third part would go into the sname field.
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 MAY consider them to be a split option as described
here. Decoding agents that support options that require the here. Decoding agents that support options that require the
behaviour described in this draft MUST consider such options to behaviour described in this draft MUST consider such options to
be split. 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 ordered as described above under encoding agent
behaviour. The decoding agent MUST ensure that when the behaviour. The decoding agent MUST ensure that when the
option's value is used, any alignment issues that are particular option's value is used, any alignment issues that are particular
to the machine architecture on which the decoding agent is to the machine architecture on which the decoding agent is
running are accounted for - there is no requirement that the running are accounted for - there is no requirement that the
encoding agent align the options in any particular way. encoding agent align the options in any particular way.
Example Example
Consider an option, option 224, with a value of "isc.org.". Normally, Consider an option, option 224, with a value of "isc.org.".
this would be encoded as a single option, as follows: Normally, this would be encoded as a single option, as follows:
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 224 | 8 | 'i' | 's' | 'c' | '.' | 'o' | 'r' | 'g' | '.' | | 224 | 8 | 'i' | 's' | 'c' | '.' | 'o' | 'r' | 'g' | '.' |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
If an encoding agent needed to split the option in order to fit it If an encoding agent needed to split the option in order to fit
into the option buffer, it could encode it as two seperate options, as it into the option buffer, it could encode it as two seperate
follows, and store it in the aggregate option buffer in the following options, as follows, and store it in the aggregate option buffer
sequence: in the following sequence:
+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+
| 224 | 5 | 'i' | 's' | 'c' | '.' | 'o' | | 224 | 5 | 'i' | 's' | 'c' | '.' | 'o' |
+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
| 224 | 3 | 'r' | 'g' | '.' | | 224 | 3 | 'r' | 'g' | '.' |
+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+
Security Considerations Security Considerations
skipping to change at line 251 skipping to change at line 252
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 email: mellon@nominum.com
Expiration Expiration
This document will expire on August 31, 2001. This document will expire on January 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/