draft-ietf-dhc-concat-05.txt   rfc3396.txt 
Network Working Group Ted Lemon
Internet Draft Nominum, Inc.
Obsoletes: draft-ietf-dhc-concat-05.txt Stuart Cheshire
Category: Standards Track Apple Computer, Inc.
September, 2002 Network Working Group T. Lemon
Expires March, 2003 Request for Comments: 3396 Nominum, Inc.
Updates: 2131 S. Cheshire
Category: Standards Track Apple Computer, Inc.
November 2002
Encoding Long Options in DHCPv4 Encoding Long Options
<draft-ietf-dhc-concat-05.txt> in the Dynamic Host Configuration Protocol (DHCPv4)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document specifies an Internet standards track protocol for the
of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering Copyright Notice
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Copyright (C) The Internet Society (2002). All Rights Reserved.
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at Abstract
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This document specifies the processing rules for Dynamic Host
http://www.ietf.org/shadow.html Configuration Protocol (DHCPv4) options that appear multiple times in
the same message. Multiple instances of the same option are
generated when an option exceeds 255 octets in size (the maximum size
of a single option) or when an option needs to be split apart in
order to take advantage of DHCP option overloading. When multiple
instances of the same option appear in the options, file and/or sname
fields in a DHCP packet, the contents of these options are
concatenated together to form a single option prior to processing.
Abstract 1. Introduction
This document specifies the processing rules for DHCPv4 options This document updates RFC 2131 [3] by clarifying the rules for option
that appear multiple times in the same message. Multiple concatenation specified in section 4.1. It is expected that the
instances of the same option are generated when an option exceeds reader will be familiar with this portion of RFC 2131. The text in
255 octets in size (the maximum size of a single option) or when section 4.1 that reads "Options may appear only once, unless
an option needs to be split apart in order to take advantage of otherwise specified in the options document." should be considered
DHCP option overloading. When multiple instances of the same as deleted.
option appear in the options, file and/or sname fields in a DHCP
packet, the contents of these options are concatenated together
to form a single option prior to processing.
Introduction The DHCP protocol [3] specifies objects called "options" that are
encoded in the DHCPv4 packet to pass information between 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.
This document updates RFC2131 [1] by clarifying the rules for However, in some cases it may be useful to send options that are
option concatenation specified in section 4.1. It is expected longer than 255 bytes. RFC 2131 [3] specifies that when more than
that the reader will be familiar with this portion of RFC2131. one option with a given type code appears in the DHCP packet, all
The text in section 4.1 that reads "Options may appear only such options should be concatenated together. It does not, however,
once, unless otherwise specified in the options document." specify the order in which this concatenation should occur.
should considered to be deleted.
The DHCP protocol [1] specifies objects called "options" that We specify here the ordering that MUST be used by DHCP protocol
are encoded in the DHCPv4 packet to pass information between agents when sending options with more than 255 bytes. This method
also MUST be used for splitting options that are shorter than 255
bytes, if for some reason the encoding agent needs to do so. DHCP
protocol agents MUST use this method whenever they receive a DHCP
packet containing more than one occurrence of a certain type of
option.
^L 2. Terminology
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 DHCP
longer than 255 bytes, however. RFC2131 [1] specifies that when Throughout this document, the acronym "DHCP" is used to refer to
more than one option with a given type code appears in the DHCP the Dynamic Host Configuration Protocol as specified in RFC 2131
packet, all such options should be concatenated together. It [3] and RFC 2132 [4].
does not, however, specify the order in which this concatenation
should occur.
We specify here the ordering that MUST be used by DHCP protocol DHCPv4
agents when sending options with more than 255 bytes. This We have used the term "DHCPv4" in the abstract for this document
method also MUST be used for splitting options that are shorter to distinguish between the DHCP protocol for IPv4 as defined in
than 255 bytes, if for some reason the encoding agent needs to do RFC 2131 and RFC 2132 and the DHCP protocol for IPv6, which, at
so. DHCP protocol agents MUST use this method whenever they the time that this document was written, was still under
receive a DHCP packet containing more than one of a certain type development.
of option.
Terminology DHCP protocol agents
This refers to any device on the network that sends or receives
DHCP packets - any DHCP client, server or relay agent. The nature
of these devices is not important to this specification.
DHCP Encoding agent
Throughout this document, the acronym "DHCP" is used to refer The DHCP protocol agent that is composing a DHCP packet to send.
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
This refers to any device on the network that sends or
receives DHCP packets - any DHCP client, server or relay
agent. The nature of these devices is not important to this
specification.
Encoding agent
The DHCP protocol agent that is composing a DHCP packet to
send.
Decoding agent
The DHCP protocol agent that is processing a DHCP packet it
has received.
Options
DHCP options are collections of data with type codes that
indicate how the options should be used. Options can specify
information that is required for the DHCP protocol,
IP stack configuration parameters for the client, information
allowing the client to rendezvous with DHCP servers, and so
on.
Option overload
The DHCP packet format is based on the BOOTP packet format
defined in RFC951 [4]. When used by DHCP protocol agents,
BOOTP packets have three fields that can contain options.
These are the optional parameters field, the sname field,
^L Decoding agent
and the filename field. The DHCP options specification [2] The DHCP protocol agent that is processing a DHCP packet it has
defines the DHCP Overload option, which specifies which of received.
these three fields is actually being used in any given DHCP
message to store DHCP options.
Requirements language Options
DHCP options are collections of data with type codes that indicate
how the options should be used. Options can specify information
that is required for the DHCP protocol, IP stack configuration
parameters for the client, information allowing the client to
rendezvous with DHCP servers, and so on.
In this document, the key words "MAY", "MUST, "MUST NOT", Option overload
"OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be The DHCP packet format is based on the BOOTP packet format defined
interpreted as described in RFC2119 [3]. in RFC 951 [1]. When used by DHCP protocol agents, BOOTP packets
have three fields that can contain options. These are the
optional parameters field, the sname field, and the filename
field. The DHCP options specification [4] defines the DHCP
Overload option, which specifies which of these three fields is
actually being used in any given DHCP message to store DHCP
options.
Applicability 3. Requirements Language
This specification applies when a DHCP agent is encoding a In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
packet containing options, and some of those options must be "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
broken into parts. This need can occur for two reasons. described in BCP 14, RFC 2119 [2].
First, it can occur because the value of an option that needs
to be sent is longer than 255 bytes. In this case, the
encoding agent MUST follow the algorithm specified here.
It can also occur because there is not sufficient space in
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
MUST either use this algorithm or not send the option at all.
This specification also applies in any case where a DHCP 4. Applicability
protocol agent has received a DHCP packet that contains more
than one instance of an option of a given type. In this
case, the agent MUST concatenate these separate instances of
the same option in the way that we specify here.
This option updates the Dynamic Host Configuration Protocol [1] This specification applies when a DHCP agent is encoding a packet
and DHCP Options and BOOTP vendor extensions [2] documents. containing options, where some of those options must be broken into
However, because many currently-deployed DHCP protocol agents parts. This need can occur for two reasons. First, it can occur
do not implement option concatenation, DHCP protocol agents because the value of an option that needs to be sent is longer than
should be careful not to transmit split options unless either 255 bytes. In this case, the encoding agent MUST follow the
it will not matter if the recipient cannot correctly reassemble algorithm specified here. It can also occur because there is not
the options, or it is certain that the recipient implements sufficient space in the current output buffer to store the option,
concatenation. 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
MUST either use this algorithm or not send the option at all.
Let us divide all DHCP options into two categories - those This specification also applies in any case where a DHCP protocol
that, by definition, require implementation of the mechanisms agent has received a DHCP packet that contains more than one instance
defined in this document, and those that do not. We will of an option of a given type. In this case, the agent MUST
refer to the former as concatenation-requiring options, and concatenate these separate instances of the same option in the way
the latter as non-concatenation-requiring options. In order that we specify here.
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 option updates the Dynamic Host Configuration Protocol [3] and
this document unless it has no choice, or it knows that its peer DHCP Options and BOOTP vendor extensions [4] documents. However,
can properly handle split options. A peer is assumed to properly 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.
^L Let us divide all DHCP options into two categories - those that, by
handle split options if it has provided or requested at least definition, require implementation of the mechanisms defined in this
one concatenation-requiring option. Alternatively, the document, and those that do not. We will refer to the former as
administrator of the agent generating the option can concatenation-requiring options, and the latter as non-
specifically configure the agent to assume that the recipient concatenation-requiring options. In order for an option to be a
can correctly concatenate options split as described in this concatenation-requiring option, the protocol specification that
document. defines that option must require implementation of option splitting
and option concatenation as described in this document, by
specifically referencing this document.
Some implementors may find it easiest to only split concatena- A DHCP protocol agent SHOULD NOT split an option as described in this
tion-requiring options, and never split non-concatenation- document unless it has no choice, or it knows that its peer can
requiring options. This is permissible. However, an implement- properly handle split options. A peer is assumed to properly handle
ation which supports any concatenation-requiring option MUST be split options if it has provided or requested at least one
capable of concatenating received options for both concatena- concatenation-requiring option. Alternatively, the administrator of
tion-requiring and non-concatenation-requiring options. the agent generating the option can specifically configure the agent
to assume that the recipient can correctly concatenate options split
as described in this document.
No restrictions apply to option concatenation when a DHCP agent Some implementors may find it easiest to only split concatenation-
receives a DHCP message. Any DHCP protocol agent that implements requiring options, and never split non-concatenation-requiring
the mechanisms described in this document can assume that when it options. This is permissible. However, an implementation which
receives two options of the same type, it should concatenate supports any concatenation-requiring option MUST be capable of
them. concatenating received options for both concatenation-requiring and
non-concatenation-requiring options.
The aggregate option buffer 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.
DHCP options can be stored in the DHCP packet in three separate 5. The Aggregate Option Buffer
portions of the packet. These are the optional parameters field,
the sname field, and the file field, as described in RFC2131 [1].
This complicates the description of the option splitting
mechanism because there are three separate fields into which
split options may be placed.
To further complicate matters, an option that doesn't fit into DHCP options can be stored in the DHCP packet in three separate
one field can't overlap the boundary into another field - the portions of the packet. These are the optional parameters field, the
encoding agent must instead break the option into two parts and sname field, and the file field, as described in RFC 2131 [3]. This
store one part in each buffer. complicates the description of the option splitting mechanism because
there are three separate fields into which split options may be
placed.
To simplify this discussion, we will talk about an aggregate To further complicate matters, an option that doesn't fit into one
option buffer, which will be the aggregate of the three buffers. field can't overlap the boundary into another field - the encoding
This is a logical aggregation - the buffers MUST appear in the agent must instead break the option into two parts and store one part
locations in the DHCP packet described in RFC2131 [1]. in each buffer.
The aggregate option buffer is made up of the optional parameters To simplify this discussion, we will talk about an aggregate option
field, the file field, and the sname field, in that order. buffer, which will be the aggregate of the three buffers. This is a
WARNING: This is not the physical ordering of these fields in the logical aggregation - the buffers MUST appear in the locations in the
DHCP packet. DHCP packet described in RFC 2131 [3].
Options MUST NOT be stored in the aggregate option buffer in such The aggregate option buffer is made up of the optional parameters
in such a way that they cross either boundary between the three field, the file field, and the sname field, in that order.
fields in the aggregate buffer.
The encoding agent is free to choose to use either or both of the WARNING: This is not the physical ordering of these fields in the
sname field and file field. If the encoding agent does not choose DHCP packet.
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 Options MUST NOT be stored in the aggregate option buffer in such a
way that they cross either boundary between the three fields in the
aggregate buffer.
Encoding agent behavior The encoding agent is free to choose to use either or both 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 agents decide to split options based on the reasons we 6. Encoding Agent Behavior
have described in the preceding section entitled "applicability."
Options can be split on any octet boundary. No split portion of Encoding agents decide to split options based on the reasons we have
an option that has been split can contain more than 255 octets. described in the preceding section entitled "applicability".
The split portions of the option MUST be stored in the aggregate
option buffer in sequential order - the first split portion MUST
be stored first in the aggregate option buffer, then the second
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 Options can be split on any octet boundary. No split portion of an
the physical ordering of the DHCP packet, if an option were split option that has been split can contain more than 255 octets. The
into three parts and each part went into one of the possible split portions of the option MUST be stored in the aggregate option
option fields, the first part would go into the optional buffer in sequential order - the first split portion MUST be stored
parameters field, the second part would go into the file field, first in the aggregate option buffer, then the second portion, and so
and the third part would go into the sname field. This on. The encoding agent MUST NOT attempt to specify any semantic
maintains consistency with section 4.1 of RFC2131 [1]. information based on how the option is split.
Each split portion of an option MUST be stored in the aggregate Note that because the aggregate option buffer does not represent the
option buffer as if it were a normal variable-length option as physical ordering of the DHCP packet, if an option were split into
described in RFC2132 [2]. The length fields of each split portion three parts and each part went into one of the possible option
of the option MUST add up to the total length of the option data. fields, the first part would go into the optional parameters field,
For any given option being split, the option code field in each the second part would go into the file field, and the third part
split portion MUST be the same. would go into the sname field. This maintains consistency with
section 4.1 of RFC 2131 [3].
Decoding agent behavior Each split portion of an option MUST be stored in the aggregate
option buffer as if it were a normal variable-length option as
described in RFC 2132 [4]. The length fields of each split portion
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 split
portion MUST be the same.
When a decoding agent is scanning an incoming DHCP packet's 7. Decoding Agent Behavior
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
described in the preceding section.
In the case that a decoding agent finds a split option, it MUST When a decoding agent is scanning an incoming DHCP packet's option
treat the contents of that option as a single option, and the buffer and finds two or more options with the same option code, it
contents MUST be reassembled in the order that was described above MUST consider them to be split portions of an option as described in
under encoding agent behavior. the preceding section.
The decoding agent should ensure that when the option's In the case that a decoding agent finds a split option, it MUST treat
value is used, any alignment issues that are particular to the the contents of that option as a single option, and the contents MUST
machine architecture on which the decoding agent is running are be reassembled in the order that was described above under encoding
accounted for - there is no requirement that the encoding agent agent behavior.
align the options in any particular way.
There is no semantic meaning to where an option is split - the The decoding agent should ensure that when the option's value is
encoding agent is free to split the option at any point, and the used, any alignment issues that are particular to the machine
decoding agent MUST reassemble the split option parts into a architecture on which the decoding agent is running are accounted for
single object, and MUST NOT treat each split portion of the option - there is no requirement that the encoding agent align the options
as a separate object. in any particular way.
^L 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
separate object.
Example 8. Example
Consider an option, Bootfile name (option code 67), with a value Consider an option, Bootfile name (option code 67), with a value of
of "/diskless/foo". Normally, this would be encoded as a single "/diskless/foo". Normally, this would be encoded as a single option,
option, as follows: 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
it into the option buffer, it could encode it as two separate into the option buffer, it could encode it as two separate options,
options, as follows, and store it in the aggregate option buffer as follows, and store it in the aggregate option buffer in the
in the following sequence: 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 9. Security Considerations
This document raises no new security issues. Potential exposures This document raises no new security issues. Potential exposures to
to attack in the DHCP protocol are discussed in section 7 of the attack in the DHCP protocol are discussed in section 7 of the DHCP
DHCP protocol specification [1] and in Authentication for DHCP protocol specification [3] and in Authentication for DHCP Messages
Messages [5]. [5].
Note that the authentication option itself can be split; in such Note that the authentication option itself can be split; in such
cases implementations must be careful when setting the authenti- cases implementations must be careful when setting the authentication
cation field to zero (prior to generation or verification of the field to zero (prior to generation or verification of the MAC) as it
MAC) as it may be split across multiple options. may be split across multiple options.
References 10. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 10.1. Normative References
Bucknell University, March 1997.
[2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell
University, March 1997.
[3] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, Harvard University, March 1997.
[4] Croft, W., Gilmore, J., "BOOTSTRAP PROTOCOL (BOOTP)", RFC951,
Stanford University, Sun Microsystems, September 1985.
[5] R. Droms, W. Arbaugh, "Authentication for DHCP Messages",
RFC3118, Cisco Systems, University of Maryland, June 2001.
^L [1] Croft, W. and J. Gilmore, "BOOTSTRAP PROTOCOL (BOOTP)", RFC 951,
September 1985.
Author Information [2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
Ted Lemon [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
Nominum, Inc. 1997.
2385 Bay Road
Redwood City, CA 94043
USA
email: mellon@nominum.com
Stuart Cheshire [4] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
Apple Computer, Inc. Extensions", RFC 2132, March 1997.
1 Infinite Loop
Cupertino
California 95014
USA
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
Expiration 10.2. Informative References
This document will expire on February 28, 2003. [5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC
3118, June 2001.
Full Copyright Statement 11. Intellectual Property Statement
Copyright (C) 2001-2002 The Internet Society. All Rights Reserved. The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
12. Authors' Addresses
Ted Lemon
Nominum, Inc.
2385 Bay Road
Redwood City, CA 94043
USA
EMail: mellon@nominum.com
Stuart Cheshire
Apple Computer, Inc.
1 Infinite Loop
Cupertino
California 95014
USA
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
13. Full Copyright Statement
Copyright (C) The Internet Society (2002). 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
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at line 381 skipping to change at page 9, line 32
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 69 change blocks. 
287 lines changed or deleted 288 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/