draft-ietf-tcpm-tcpmss-05.txt   rfc6691.txt 
Network Working Group Network Working Group Internet Engineering Task Force (IETF) D. Borman
Internet-Draft D. Borman Request for Comments: 6691 Quantum Corporation
Updates: 879, 2385 Quantum Corporation Updates: 879, 2385 July 2012
Intended Status: Informational June 7, 2012 Category: Informational
File: draft-ietf-tcpm-tcpmss-05.txt ISSN: 2070-1721
TCP Options and MSS TCP Options and Maximum Segment Size (MSS)
Abstract Abstract
This memo discusses what value to use with the TCP Maximum Segment This memo discusses what value to use with the TCP Maximum Segment
Size (MSS) option, and updates RFC 879 and RFC 2385. Size (MSS) option, and updates RFC 879 and RFC 2385.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. Internet-Drafts are working
documents of the Internet Engineering 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 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
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on December 7, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6691.
Copyright Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
1. Introduction This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
There has been some confusion as to what value should be filled in 1. Introduction
the TCP MSS option when using IP and TCP options. RFC 879 [RFC879]
stated:
The MSS counts only data octets in the segment, it does not There has been some confusion as to what value to use with the TCP
count the TCP header or the IP header. MSS option when using IP and TCP options. RFC 879 [RFC879] states:
which is unclear about what to do about IP and TCP options, since The MSS counts only data octets in the segment, it does not count
they are part of the headers. RFC 1122 [RFC1122] clarified the MSS the TCP header or the IP header.
option, which is discussed in Appendix A, but there still seems to be
some confusion.
1.1 Terminology This statement is unclear about what to do about IP and TCP options,
since they are part of the headers. RFC 1122 [RFC1122] clarified the
MSS option, which is discussed in Appendix A, but there still seems
to be some confusion.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 1.1. Terminology
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119
[RFC2119].
2. The Short Statement The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. The Short Statement
When calculating the value to put in the TCP MSS option, the MTU When calculating the value to put in the TCP MSS option, the MTU
value SHOULD be decreased by only the size of the fixed IP and TCP value SHOULD be decreased by only the size of the fixed IP and TCP
headers, and SHOULD NOT be decreased to account for any possible IP headers and SHOULD NOT be decreased to account for any possible IP or
or TCP options; conversely, the sender MUST reduce the TCP data TCP options; conversely, the sender MUST reduce the TCP data length
length to account for any IP or TCP options that it is including in to account for any IP or TCP options that it is including in the
the packets that it sends. The rest of this document just expounds packets that it sends. The rest of this document just expounds on
on that statement, and the goal is to avoid IP level fragmentation of that statement, and the goal is to avoid IP-level fragmentation of
TCP packets. TCP packets.
The size of the fixed TCP header is 20 bytes [RFC793], the size of The size of the fixed TCP header is 20 bytes [RFC793], the size of
the fixed IPv4 header is 20 bytes [RFC791], and the size of the fixed the fixed IPv4 header is 20 bytes [RFC791], and the size of the fixed
IPv6 header is 40 bytes [RFC2460]. The determination of what MTU IPv6 header is 40 bytes [RFC2460]. The determination of what MTU
value should be used, especially in the case of multi-homed hosts, is value should be used, especially in the case of multi-homed hosts, is
beyond the scope of this document. beyond the scope of this document.
3. MSS in other RFCs 3. MSS in Other RFCs
3.1 RFC 879 3.1. RFC 879
RFC 879 [RFC879] discusses the MSS option and other topics. In RFC 879 [RFC879] discusses the MSS option and other topics. In the
the introduction, it states: Introduction, it states:
"THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS
MINUS FORTY." FORTY.
and in section 13, it states: In Section 13, it states:
"The definition of the MSS option can be stated: The definition of the MSS option can be stated:
The maximum number of data octets that may be received by The maximum number of data octets that may be received by the
the sender of this TCP option in TCP segments with no TCP sender of this TCP option in TCP segments with no TCP header
header options transmitted in IP datagrams with no IP header options transmitted in IP datagrams with no IP header options.
options."
These are both correct. However, in the next paragraph in section These are both correct. However, in the next paragraph -- in
14, it then confuses this by stating that the consequence is: Section 14 -- it then confuses this by stating that the consequence
is:
"When TCP is used in a situation when either the IP or TCP When TCP is used in a situation when either the IP or TCP headers
headers are not minimum and yet the maximum IP datagram that are not minimum and yet the maximum IP datagram that can be
can be received remains 576 octets then the TCP Maximum Segment received remains 576 octets then the TCP Maximum Segment Size
Size option must be used to reduce the limit on data octets option must be used to reduce the limit on data octets allowed in
allowed in a TCP segment." a TCP segment.
For example, if the IP Security option (11 octets) were in For example, if the IP Security option (11 octets) were in use
use and the IP maximum datagram size remained at 576 octets, and the IP maximum datagram size remained at 576 octets, then
then the TCP should send the MSS with a value of 525 the TCP should send the MSS with a value of 525 (536-11).
(536-11)."
That is incorrect. The simpler and more correct statement would That is incorrect. The simpler and more correct statement would be:
be:
When TCP is used in a situation where either the IP or TCP When TCP is used in a situation where either the IP or TCP headers
headers are not minimum, the sender must reduce the amount of are not minimum, the sender must reduce the amount of TCP data in
TCP data in any given packet by number of octets used by the IP any given packet by the number of octets used by the IP and TCP
and TCP options. options.
3.2 RFC 2385 3.2. RFC 2385
RFC 2385 [RFC2385] incorrectly states in section 4.3: RFC 2385 [RFC2385] incorrectly states, in Section 4.3:
"As with other options that are added to every segment, the As with other options that are added to every segment, the size of
size of the MD5 option must be factored into the MSS offered to the MD5 option must be factored into the MSS offered to the other
the other side during connection negotiation. Specifically, side during connection negotiation. Specifically, the size of the
the size of the header to subtract from the MTU (whether it is header to subtract from the MTU (whether it is the MTU of the
the MTU of the outgoing interface or IP's minimal MTU of 576 outgoing interface or IP's minimal MTU of 576 bytes) is now at
bytes) is now at least 18 bytes larger." least 18 bytes larger.
This is incorrect, the value for the MSS option is only adjusted This is incorrect. The value for the MSS option is only adjusted by
by the fixed IP and TCP headers. the fixed IP and TCP headers.
4. Clarification from the TCP Large Windows mailing list 4. Clarification from the TCP Large Windows Mailing List
The initial clarification was sent to the TCP Large Windows mailing The initial clarification was sent to the TCP Large Windows mailing
list in 1993 [Borman93]; this section is based on that message. list in 1993 [Borman93]; this section is based on that message.
The MSS value to be sent in an MSS option should be equal to the The MSS value to be sent in an MSS option should be equal to the
effective MTU minus the fixed IP and TCP headers. By ignoring both effective MTU minus the fixed IP and TCP headers. By ignoring both
IP and TCP options when calculating the value for the MSS option, if IP and TCP options when calculating the value for the MSS option, if
there are any IP or TCP options to be sent in a packet, then the there are any IP or TCP options to be sent in a packet, then the
sender must decrease the size of the TCP data accordingly. The sender must decrease the size of the TCP data accordingly. The
reason for this can be seen in the following table: reason for this can be seen in the following table:
+--------------------+--------------------+ +--------------------+--------------------+
| MSS is adjusted | MSS isn't adjusted | | MSS is adjusted | MSS isn't adjusted |
| to include options | to include options | | to include options | to include options |
+--------------------+--------------------+--------------------+ +--------------------+--------------------+--------------------+
| Sender adjusts | Packets are too | Packets are the | | Sender adjusts | Packets are too | Packets are the |
| packet length | short | correct length | | packet length | short | correct length |
| for options | | | | for options | | |
+--------------------+--------------------+--------------------+ +--------------------+--------------------+--------------------+
| Sender doesn't | Packets are the | Packets are too | | Sender doesn't | Packets are the | Packets are too |
| adjust packet | correct length | long | | adjust packet | correct length | long |
| length for options | | | | length for options | | |
+--------------------+--------------------+--------------------+ +--------------------+--------------------+--------------------+
The goal is to not send IP datagrams that have to be fragmented, and The goal is to not send IP datagrams that have to be fragmented, and
packets sent with the constraints in the lower right of this grid packets sent with the constraints in the lower right of this grid
will cause IP fragmentation. Since the sender doesn't know if the will cause IP fragmentation. Since the sender doesn't know if the
received MSS option was adjusted to include options, the only way to received MSS option was adjusted to include options, the only way to
guarantee that the packets are not too long is for the data sender to guarantee that the packets are not too long is for the data sender to
decrease the TCP data length by the size of the IP and TCP options. decrease the TCP data length by the size of the IP and TCP options.
It follows then, that since the sender will be adjusting the TCP data It follows, then, that since the sender will be adjusting the TCP
length when sending IP and TCP options, there is no need to include data length when sending IP and TCP options, there is no need to
the IP and TCP option lengths in the MSS value. include the IP and TCP option lengths in the MSS value.
Another argument against including IP or TCP options in the Another argument against including IP or TCP options in the
determination of the MSS value is that the MSS is a fixed value, and determination of the MSS value is that the MSS is a fixed value, and
by their very nature the length of IP and TCP options are variable, by their very nature the lengths of IP and TCP options are variable,
so the MSS value can never accurately reflect all possible IP and TCP so the MSS value can never accurately reflect all possible IP and TCP
option combinations, the only one that knows for sure how many IP and option combinations. The only one that knows for sure how many IP
TCP options are in any given packet is the sender, hence the sender and TCP options are in any given packet is the sender; hence, the
should be doing the adjustment to the TCP data length to account for sender should be doing the adjustment to the TCP data length to
any IP and TCP options. account for any IP and TCP options.
5. Additional considerations 5. Additional Considerations
5.1 Path MTU Discovery 5.1. Path MTU Discovery
The TCP MSS option specifies an upper bound for the size of The TCP MSS option specifies an upper bound for the size of packets
packets that can be received. Hence setting the value in the MSS that can be received. Hence, setting the value in the MSS option too
option too small can impact the ability for Path MTU discovery to small can impact the ability for Path MTU Discovery to find a larger
find a larger Path MTU. For more information on Path MTU path MTU. For more information on Path MTU Discovery, see:
Discovery, see:
RFC 1191 "Path MTU Discovery" [RFC1191] o "Path MTU Discovery" [RFC1191]
RFC 2923 "TCP Problems with Path MTU Discovery" [RFC2923]
RFC 4821 "Packetization Layer Path MTU Discovery" [RFC4821]
5.2 Interfaces with Variable MSS values o "TCP Problems with Path MTU Discovery" [RFC2923]
The effective MTU can sometimes vary, as when used with variable o "Packetization Layer Path MTU Discovery" [RFC4821]
compression, e.g., ROHC [RFC5795]. It is tempting for TCP to want
to advertise the largest possible MSS, to support the most
efficient use of compressed payloads. Unfortunately, some
compression schemes occasionally need to transmit full headers
(and thus smaller payloads) to resynchronize state at their
endpoint compressor/decompressors. If the largest MTU is used to
calculate the value to advertise in the MSS option, TCP
retransmission may interfere with compressor resynchronization.
As a result, when the effective MTU of an interface varies, TCP 5.2. Interfaces with Variable MSS Values
SHOULD use the smallest effective MTU of the interface to
calculate the value to advertise in the MSS option.
5.3 IPv6 Jumbograms The effective MTU can sometimes vary, as when used with variable
compression, e.g., RObust Header Compression (ROHC) [RFC5795]. It is
tempting for TCP to want to advertise the largest possible MSS, to
support the most efficient use of compressed payloads.
Unfortunately, some compression schemes occasionally need to transmit
full headers (and thus smaller payloads) to resynchronize state at
their endpoint compressors/decompressors. If the largest MTU is used
to calculate the value to advertise in the MSS option, TCP
retransmission may interfere with compressor resynchronization.
In order to support TCP over IPv6 Jumbograms, implementations need As a result, when the effective MTU of an interface varies, TCP
to be able to send TCP segments larger than 64K. RFC 2675 SHOULD use the smallest effective MTU of the interface to calculate
[RFC2675] defines that a value of 65,535 is to be treated as the value to advertise in the MSS option.
infinity, and Path MTU Discovery [RFC1981] is used to determine
the actual MSS.
5.4 Avoiding fragmentation 5.3. IPv6 Jumbograms
Packets that are too long will either be fragmented or dropped. In order to support TCP over IPv6 jumbograms, implementations need to
If packets are fragmented, intermediary firewalls or middle boxes be able to send TCP segments larger than 64K. RFC 2675 [RFC2675]
may drop the fragmented packets. In either case, when packets are defines that a value of 65,535 is to be treated as infinity, and Path
dropped the connection can fail; hence it is best to avoid MTU Discovery [RFC1981] is used to determine the actual MSS.
generating fragments.
6. Security Considerations 5.4. Avoiding Fragmentation
This document clarifies how to determine what value should be used Packets that are too long will either be fragmented or dropped. If
for the MSS option, and does not introduce any new security concerns. packets are fragmented, intermediary firewalls or middle boxes may
drop the fragmented packets. In either case, when packets are
dropped, the connection can fail; hence, it is best to avoid
generating fragments.
7. IANA Considerations 6. Security Considerations
This document has no actions for IANA. This document clarifies how to determine what value should be used
for the MSS option and does not introduce any new security concerns.
8. References 7. References
Normative References 7.1. Normative References
[RFC791] Postel, J., "Internet Protocol," RFC 791, September 1981. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC793] Postel, J., "Transmission Control Protocol," RFC 793, [RFC793] Postel, J., "Transmission Control Protocol", STD 7,
September 1981. RFC 793, September 1981.
[RFC879] Postel, J., "The TCP Maximum Segment Size and Related [RFC879] Postel, J., "The TCP Maximum Segment Size and Related
Topics", RFC 879, ISI, November 1983. Topics", RFC 879, November 1983.
[RFC1122] Braden, R., editor, "Requirements for Internet Hosts -- [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", RFC 1122, October, 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
(IPv6) Specification", RFC 2460, December, 1998. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2675] Borman, D., Deering, S., Hinden, R., "IPv6 Jumbograms", [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
RFC 2675, August, 1999. (IPv6) Specification", RFC 2460, December 1998.
Informative References [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6
Jumbograms", RFC 2675, August 1999.
[Borman93] Borman, D., "TCP MSS & Timestamps", Message to the 7.2. Informative References
tcplw mailing list, Jan 7, 1993.
[RFC1191] Mogul, J.C., Deering, S.E., "Path MTU discovery" RFC [Borman93] Borman, D., "TCP MSS & Timestamps", Message to the tcplw
1191, November 1990. mailing list, January 7, 1993.
[RFC1981] McCann, J., Deering, S. and Mogul, J.,, "Path MTU [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
Discovery for IP Version 6", RFC 1981, August 1986. November 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
Requirement Levels", RFC 2119, March 1997. Discovery for IP version 6", RFC 1981, August 1996.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1988. MD5 Signature Option", RFC 2385, August 1998.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
2923, September 2000. RFC 2923, September 2000.
[RFC4821] Mathis, M., Heffner, J., "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, March 2007.
[RFC5795] Sandlund, K., Gelletier, G. and Jonsson, L-E., "The [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The
RObust Header Compression (ROHC) Framework", RFC 5795, March 2010. RObust Header Compression (ROHC) Framework", RFC 5795,
March 2010.
Appendix A: Details from RFC 793 and RFC 1122 Appendix A. Details from RFC 793 and RFC 1122
RFC 793 [RFC793] defines the MSS option: RFC 793 [RFC793] defines the MSS option as follows:
Maximum Segment Size Option Data: 16 bits Maximum Segment Size Option Data: 16 bits
If this option is present, then it communicates the maximum
receive segment size at the TCP which sends this segment.
This field must only be sent in the initial connection request
(i.e., in segments with the SYN control bit set). If this
option is not used, any segment size is allowed.
RFC 1122 [RFC1122] provides additional clarification in section If this option is present, then it communicates the maximum
4.2.2.6, pages 85-86. First, it changes the default behavior when receive segment size at the TCP which sends this segment. This
the MSS option is not present: field must only be sent in the initial connection request
(i.e., in segments with the SYN control bit set). If this
option is not used, any segment size is allowed.
If an MSS option is not received at connection setup, TCP RFC 1122 [RFC1122] provides additional clarification in
MUST assume a default send MSS of 536 (576-40) [TCP:4]. Section 4.2.2.6, on pages 85-86. First, it changes the default
behavior when the MSS option is not present:
Then it clarifies how to determine the value to use in the MSS If an MSS option is not received at connection setup, TCP MUST
assume a default send MSS of 536 (576-40) [TCP:4].
Then, it clarifies how to determine the value to use in the MSS
option: option:
The MSS value to be sent in an MSS option must be less than The MSS value to be sent in an MSS option must be less than or
or equal to: equal to:
MMS_R - 20 MMS_R - 20
where MMS_R is the maximum size for a transport-layer where MMS_R is the maximum size for a transport-layer message that
message that can be received (and reassembled). TCP obtains can be received (and reassembled). TCP obtains MMS_R and MMS_S
MMS_R and MMS_S from the IP layer; see the generic call from the IP layer; see the generic call GET_MAXSIZES in
GET_MAXSIZES in Section 3.4. Section 3.4.
What is implied, but not explicitly stated, is that the 20 is the What is implied in RFC 1122, but not explicitly stated, is that the
size of the fixed TCP header. The definition of MMS_R is found in 20 is the size of the fixed TCP header. The definition of MMS_R is
section 3.3.2 on page 57: found in Section 3.3.2, on page 57:
MMS_R is given by: MMS_R is given by:
MMS_R = EMTU_R - 20 MMS_R = EMTU_R - 20
since 20 is the minimum size of an IP header. since 20 is the minimum size of an IP header.
and on page 56, also section 3.3.2: and on page 56 (also Section 3.3.2):
We designate the largest datagram size that can be reassembled We designate the largest datagram size that can be reassembled by
by EMTU_R ("Effective MTU to receive"); this is sometimes EMTU_R ("Effective MTU to receive"); this is sometimes called the
called the "reassembly buffer size". EMTU_R MUST be greater "reassembly buffer size". EMTU_R MUST be greater than or equal to
than or equal to 576, SHOULD be either configurable or 576, SHOULD be either configurable or indefinite, and SHOULD be
indefinite, and SHOULD be greater than or equal to the MTU of greater than or equal to the MTU of the connected network(s).
the connected network(s).
What should be noted here is that EMTU_R is the largest datagram size What should be noted here is that EMTU_R is the largest datagram size
that can be reassembled, not the largest datagram size that can be that can be reassembled, not the largest datagram size that can be
received without fragmentation. Taking this literally, since most received without fragmentation. Taking this literally, since most
modern TCP/IP implementations can reassemble a full 64K IP packet, modern TCP/IP implementations can reassemble a full 64K IP packet,
implementations should be using 65535 - 20 - 20, or 65495 for the MSS implementations should be using 65535 - 20 - 20, or 65495, for the
option. But there is more to it than that, in RFC 1122 on page 86 it MSS option. But there is more to it than that. RFC 1122 also
also states: states, on page 86:
The choice of TCP segment size has a strong effect on The choice of TCP segment size has a strong effect on performance.
performance. Larger segments increase throughput by Larger segments increase throughput by amortizing header size and
amortizing header size and per-datagram processing per-datagram processing overhead over more data bytes; however, if
overhead over more data bytes; however, if the packet the packet is so large that it causes IP fragmentation, efficiency
is so large that it causes IP fragmentation, efficiency drops sharply if any fragments are lost [IP:9].
drops sharply if any fragments are lost [IP:9].
Since it is guaranteed that any IP datagram that is larger than the Since it is guaranteed that any IP datagram that is larger than the
MTU of the connected network will have to be fragmented to be MTU of the connected network will have to be fragmented to be
received, implementations ignore the "greater than or" part of received, implementations ignore the "greater than or" part of
"SHOULD be greater than or equal to the MTU of the connected "SHOULD be greater than or equal to the MTU of the connected
network(s)". Thus, the MSS value to be sent in an MSS option must be network(s)". Thus, the MSS value to be sent in an MSS option must be
less than or equal to: less than or equal to:
EMTU_R - FixedIPhdrsize - FixedTCPhdrsize EMTU_R - FixedIPhdrsize - FixedTCPhdrsize
where FixedTCPhdrsize is 20, and FixedIPhdrsize is 20 for IPv4 and 40 where FixedTCPhdrsize is 20, and FixedIPhdrsize is 20 for IPv4 and 40
for IPv6. for IPv6.
Authors' Addresses Author's Address
David Borman David Borman
Quantum Corporation Quantum Corporation
Mendota Heights, MN 55120 Mendota Heights, MN 55120
Email: david.borman@quantum.com
Full Copyright Statement
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal EMail: david.borman@quantum.com
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
 End of changes. 88 change blocks. 
230 lines changed or deleted 218 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/