draft-ietf-dhc-concat-04.txt   draft-ietf-dhc-concat-05.txt 
Network Working Group Ted Lemon Network Working Group Ted Lemon
Internet Draft Nominum, Inc. Internet Draft Nominum, Inc.
Obsoletes: draft-ietf-dhc-concat-03.txt Stuart Cheshire Obsoletes: draft-ietf-dhc-concat-05.txt Stuart Cheshire
Category: Standards Track Apple Computer, Inc. Category: Standards Track Apple Computer, Inc.
July, 2002 September, 2002
Expires January, 2003 Expires March, 2003
Encoding Long Options in DHCPv4 Encoding Long Options in DHCPv4
<draft-ietf-dhc-concat-04.txt> <draft-ietf-dhc-concat-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 3, line 25 skipping to change at page 3, line 25
interpreted as described in RFC2119 [3]. interpreted as described in RFC2119 [3].
Applicability Applicability
This specification applies when a DHCP agent is encoding a This specification applies when a DHCP agent is encoding a
packet containing options, and some of those options must be packet containing options, and some of those options must be
broken into parts. This need can occur for two reasons. broken into parts. This need can occur for two reasons.
First, it can occur because the value of an option that needs First, it can occur because the value of an option that needs
to be sent is longer than 255 bytes. In this case, the to be sent is longer than 255 bytes. In this case, the
encoding agent MUST follow the algorithm specified here. encoding agent MUST follow the algorithm specified here.
It can also occur because there is not suff- icient space in It can also occur because there is not sufficient space in
the current output buffer to store the option, but there is the current output buffer to store the option, but there is
space for part of the option, and there is space in another 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 This specification also applies in any case where a DHCP
protocol agent has received a DHCP packet that contains more protocol agent has received a DHCP packet that contains more
than one instance of an option of a given type. In this than one instance of an option of a given type. In this
case, the agent MUST concatenate these separate instances of case, the agent MUST concatenate these separate instances of
the same option in the way that we specify here. the same option in the way that we specify here.
skipping to change at page 3, line 57 skipping to change at page 3, line 57
that, by definition, require implementation of the mechanisms that, by definition, require implementation of the mechanisms
defined in this document, and those that do not. We will defined in this document, and those that do not. We will
refer to the former as concatenation-requiring options, and refer to the former as concatenation-requiring options, and
the latter as non-concatenation-requiring options. In order the latter as non-concatenation-requiring options. In order
for an option to be a concatenation-requiring option, the for an option to be a concatenation-requiring option, the
protocol specification that defines that option must require protocol specification that defines that option must require
implementation of option splitting and option concatenation implementation of option splitting and option concatenation
as described in this document, by specifically referencing as described in this document, by specifically referencing
this document. this document.
A DHCP protocol agent SHOULD NOT split an option as described A DHCP protocol agent SHOULD NOT split an option as described in
in this document unless at least one of these apply: this document unless it has no choice, or it knows that its peer
can properly handle split options. A peer is assumed to properly
^L ^L
- The option is a concatenation-requiring option. handle split options if it has provided or requested at least
- The message being generated is in response to a message one concatenation-requiring option. Alternatively, the
containing a concatenation-requiring option. administrator of the agent generating the option can
- The message being generated is in response to a message specifically configure the agent to assume that the recipient
that requests a concatenation-requiring option. can correctly concatenate options split as described in this
- The administrator of the agent generating the option has document.
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- Some implementors may find it easiest to only split concatena-
tion-requiring options, and never split non-concatenation- tion-requiring options, and never split non-concatenation-
requiring options. This is permissible. However, an implement- requiring options. This is permissible. However, an implement-
ation which supports any concatenation-requiring option MUST be ation which supports any concatenation-requiring option MUST be
capable of concatenating received options for both concatena- capable of concatenating received options for both concatena-
tion-requiring and non-concatenation-requiring options. tion-requiring and non-concatenation-requiring options.
No restrictions apply to option concatenation when a DHCP agent No restrictions apply to option concatenation when a DHCP agent
receives a DHCP message. Any DHCP protocol agent that implements receives a DHCP message. Any DHCP protocol agent that implements
skipping to change at page 5, line 4 skipping to change at page 4, line 57
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
considered part of the aggregate option buffer in that case.
^L ^L
considered part of the aggregate option buffer in that case.
Encoding agent behavior 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
skipping to change at line 354 skipping to change at line 352
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 December 31, 2002. This document will expire on February 28, 2003.
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.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/