draft-ietf-tcpm-tcp-uto-03.txt   draft-ietf-tcpm-tcp-uto-04.txt 
TCP Maintenance and Minor L. Eggert TCP Maintenance and Minor L. Eggert
Extensions (tcpm) NEC Extensions (tcpm) NEC
Internet-Draft F. Gont Internet-Draft F. Gont
Expires: January 20, 2007 UTN/FRH Intended status: Standards Track UTN/FRH
July 19, 2006 Expires: April 25, 2007 October 22, 2006
TCP User Timeout Option TCP User Timeout Option
draft-ietf-tcpm-tcp-uto-03 draft-ietf-tcpm-tcp-uto-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 20, 2007. This Internet-Draft will expire on April 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies a new TCP option - the TCP User Timeout This document specifies a new TCP option - the TCP User Timeout
Option - that allows a TCP to advertise its current user timeout for Option - that allows a TCP to advertise its current user timeout for
a connection. Thus, the remote TCP may modify its local user timeout a connection. Thus, the remote TCP may modify its local user timeout
skipping to change at page 2, line 16 skipping to change at page 2, line 16
clients that they will maintain the connection state only across clients that they will maintain the connection state only across
short periods of disconnection. short periods of disconnection.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6 3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6
3.2. Reliability Considerations . . . . . . . . . . . . . . . . 8 3.2. Reliability Considerations . . . . . . . . . . . . . . . . 8
3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Special Option Values . . . . . . . . . . . . . . . . . . 9 3.4. Special Option Values . . . . . . . . . . . . . . . . . . 9
4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 9 4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10
4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A. Alternative solutions . . . . . . . . . . . . . . . . 13 Appendix A. Alternative solutions . . . . . . . . . . . . . . . . 14
Appendix B. Document Revision History . . . . . . . . . . . . . . 14 Appendix B. Document Revision History . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
The Transmission Control Protocol (TCP) specification The Transmission Control Protocol (TCP) specification
[RFC0793]defines a local, per-connection "user timeout" parameter [RFC0793]defines a local, per-connection "user timeout" parameter
that specifies the maximum amount of time that transmitted data may that specifies the maximum amount of time that transmitted data may
remain unacknowledged before TCP will forcefully close the remain unacknowledged before TCP will forcefully close the
corresponding connection. Applications can set and change this corresponding connection. Applications can set and change this
parameter with OPEN and SEND calls. If a network disconnection lasts parameter with OPEN and SEND calls. If a network disconnection lasts
longer than the user timeout, no acknowledgments will be received for longer than the user timeout, no acknowledgments will be received for
skipping to change at page 5, line 18 skipping to change at page 5, line 18
Note that an exchange of TCP User Timeout Options between peers is Note that an exchange of TCP User Timeout Options between peers is
not a binding negotiation. Transmission of a TCP User Timeout Option not a binding negotiation. Transmission of a TCP User Timeout Option
is an advisory suggestion that the peer consider adapting its local is an advisory suggestion that the peer consider adapting its local
user timeout. Hosts remain free to adopt a different user timeout, user timeout. Hosts remain free to adopt a different user timeout,
or to forcefully close or abort connections at any time for any or to forcefully close or abort connections at any time for any
reason, whether or not they use custom user timeouts or have reason, whether or not they use custom user timeouts or have
suggested the peer to use them. suggested the peer to use them.
A host that supports the TCP User Timeout Option SHOULD include one A host that supports the TCP User Timeout Option SHOULD include one
in each packet that carries a SYN flag, but need not. [MEDINA] has in each packet that carries a SYN flag. The presence of this option
shown that unknown options are correctly handled by the vast majority is not a negotiation of the capability, but simply an advisory
of modern TCP stacks. It is thus not necessary to require message specifying the currently preferred user timeout value. This
negotiation of the use of the TCP User Timeout Option during the allows TCP to adopt a user timeout with knowledge of that used by the
three-way handshake of a connection. However, including a TCP User peer TCP from the very beginning of the data transfer phase.
Timeout Option in each segment that has the SYN flag set will result Additionally, a TCP that supports the User Timeout Option and has
in TCP being able to adopt a user timeout with knowledge of that used sent a SYN segment as a result of an active OPEN SHOULD include an
by the peer TCP, since the beginning of the data transfer phase. UTO in the first packet that does not have the SYN flag set. This
helps to minimize the amount of state information a TCP must keep for
connections in non-synchronized states, and is particularly useful
when mechanisms such as "SYN cookies" [I-D.ietf-tcpm-syn-flood] are
implemented, allowing a newly-established TCP connection to benefit
from the information advertised by the UTO option, even if the UTO
contained in the initial SYN segment was not recorded.
A host that supports the TCP User Timeout Option SHOULD include it in A host that supports the TCP User Timeout Option SHOULD include it in
the next possible segment to its peer whenever it starts using a new the next possible segment to its peer whenever it starts using a new
user timeout for the connection. This allows the peer to adapt its user timeout for the connection. This allows the peer to adapt its
local user timeout for the connection accordingly. local user timeout for the connection accordingly.
When a host that supports the TCP User Timeout Option receives one, When a host that supports the TCP User Timeout Option receives one,
it will use the received value to compute the local user timeout for it will use the received value to compute the local user timeout for
the connection. Generally, hosts should honor requests for changes the connection. Generally, hosts should honor requests for changes
to the user timeout (see Section 3.1), unless security concerns, to the user timeout (see Section 3.1), unless security concerns,
skipping to change at page 7, line 35 skipping to change at page 7, line 41
This means that, provided they are within the upper and lower limits, This means that, provided they are within the upper and lower limits,
the maximum of the two announced values will be adopted for the user the maximum of the two announced values will be adopted for the user
timeout of the connection. The rationale is that choosing the timeout of the connection. The rationale is that choosing the
maximum of the two values will let the connection survive longer maximum of the two values will let the connection survive longer
periods of disconnection. If the TCP that announced the lower of the periods of disconnection. If the TCP that announced the lower of the
two user timeout values did so in order to reduce the amount of TCP two user timeout values did so in order to reduce the amount of TCP
state information that must be kept on the host, it can, state information that must be kept on the host, it can,
nevertheless, close or abort the connection whenever it wants. nevertheless, close or abort the connection whenever it wants.
It must be noted that the two endpoints of the connection will not It must be noted that the two endpoints of the connection will not
necesarilly adopt the same user timeout. necessarily adopt the same user timeout.
Enforcing a lower limit (L_LIMIT) prevents connections from closing Enforcing a lower limit (L_LIMIT) prevents connections from closing
due to transient network conditions, including temporary congestion, due to transient network conditions, including temporary congestion,
mobility hand-offs and routing instabilities. mobility hand-offs and routing instabilities.
An upper limit (U_LIMIT) can reduce the effect of resource exhaustion An upper limit (U_LIMIT) can reduce the effect of resource exhaustion
attacks. Section 5discusses the details of these attacks. attacks. Section 5discusses the details of these attacks.
Note that these limits MAY be specified as system-wide constants or Note that these limits MAY be specified as system-wide constants or
at other granularities, such as on per-host, per-user or even per- at other granularities, such as on per-host, per-user or even per-
connection basis. Furthermore, these limits need not be static. For connection basis. Furthermore, these limits need not be static. For
example, they MAY be a function of system resource utilization or example, they MAY be a function of system resource utilization or
attack status and could be dynamically adapted. attack status and could be dynamically adapted.
The Host Requirements RFC [RFC1122] does not impose any limits on the The Host Requirements RFC [RFC1122] does not impose any limits on the
length of the user timeout. However, a time interval of at least 100 length of the user timeout. However, a time interval of at least 100
seconds is RECOMMENDED. Consequently, the lower limit (L_LIMIT) seconds is RECOMMENDED. Consequently, the lower limit (L_LIMIT)
SHOULD be set to at least 100 seconds when following the RECOMMENDED SHOULD be set to at least 100 seconds when following the RECOMMENDED
scheme described in this section. Adopting a user timeout smaller scheme described in this section. Adopting a user timeout smaller
than the current retransmission timeout (RTO) for the connection than the current retransmission timeout (RTO) for the connection
would likely cause the connection to be aborted unnecesarily. would likely cause the connection to be aborted unnecessarily.
Therefore, the lower limit (L_LIMIT) MUST be larger than the current Therefore, the lower limit (L_LIMIT) MUST be larger than the current
retransmission timeout (RTO) for the connection. retransmission timeout (RTO) for the connection.
3.2. Reliability Considerations 3.2. Reliability Considerations
The TCP User Timeout Option is an advisory TCP option that does not The TCP User Timeout Option is an advisory TCP option that does not
change processing of subsequent segments. Unlike other TCP options, change processing of subsequent segments. Unlike other TCP options,
it need not be exchanged reliably. Consequently, the specification it need not be exchanged reliably. Consequently, the specification
in this section does not define a reliability handshake for TCP User in this section does not define a reliability handshake for TCP User
Timeout Option exchanges. When a segment that carries a TCP User Timeout Option exchanges. When a segment that carries a TCP User
skipping to change at page 9, line 51 skipping to change at page 10, line 27
use. TCP implementations MUST NOT send it and MUST ignore it upon use. TCP implementations MUST NOT send it and MUST ignore it upon
reception. reception.
4. Interoperability Issues 4. Interoperability Issues
This section discusses interoperability issues related to introducing This section discusses interoperability issues related to introducing
the TCP User Timeout Option. the TCP User Timeout Option.
4.1. Middleboxes 4.1. Middleboxes
The large number of middleboxes (firewalls, proxies, protocol A TCP implementation that does not support the TCP User Timeout
scrubbers, etc.) currently present in the Internet pose some Option MUST silently ignore it [RFC1122], thus ensuring
difficulty for deploying new TCP options. Some firewalls may block interoperability. In a study of the effects of middleboxes on
segments that carry unknown options, preventing connection transport protocols, Medina et al. have shown that unknown TCP
establishment when the SYN or SYN-ACK segment contain a TCP User options are correctly handled by the vast majority of modern TCP
Timeout Option. Some recent results, however, indicate that for new stacks [MEDINA]. In this study, 3% of connections failed when an
TCP options, this may not be a significant threat, with only 0.2% of unknown TCP option appeared in the middle of a connection. Because
web requests failing when carrying an unknown option [MEDINA]. these failures violate existing requirements to ignore unknown
options, they do not warrant taking special measures to handle these
cases. In particular, we do not define a separate mechanism to
negotiate support of the TCP User Timeout Option on the three-way
handshake.
Stateful firewalls usually reset connections after a period of Stateful firewalls usually reset connections after a period of
inactivity. If such a firewall exists along the path between two inactivity. If such a firewall exists along the path between two
peers, it may close or abort connections regardless of the use of the peers, it may close or abort connections regardless of the use of the
TCP User Timeout Option. In the future, such firewalls may learn to TCP User Timeout Option. In the future, such firewalls may learn to
parse the TCP User Timeout Option and modify their behavior or the parse the TCP User Timeout Option and modify their behavior or the
option accordingly. option accordingly.
4.2. TCP Keep-Alives 4.2. TCP Keep-Alives
skipping to change at page 12, line 8 skipping to change at page 12, line 36
This section is to be interpreted according to [RFC2434]. This section is to be interpreted according to [RFC2434].
This document does not define any new namespaces. It uses an 8-bit This document does not define any new namespaces. It uses an 8-bit
TCP option number maintained by IANA at TCP option number maintained by IANA at
http://www.iana.org/assignments/tcp-parameters. http://www.iana.org/assignments/tcp-parameters.
7. Acknowledgments 7. Acknowledgments
The following people have improved this document through thoughtful The following people have improved this document through thoughtful
suggestions: Mark Allman, David Borman, Bob Braden, Marcus Brunner, suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden,
Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted Faber, Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted
Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris, Phil Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris,
Karn, Michael Kerrisk, Dan Krejsa, Kostas Pentikousis, Juergen Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid Mahdavi, Kostas
Quittek, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard and Pentikousis, Juergen Quittek, Joe Touch, Stefan Schmid, Simon
Martin Stiemerling. Schuetz, Tim Shepard and Martin Stiemerling.
Lars Eggert is partly funded by Ambient Networks, a research project Lars Eggert is partly funded by Ambient Networks, a research project
supported by the European Commission under its Sixth Framework supported by the European Commission under its Sixth Framework
Program. The views and conclusions contained herein are those of the Program. The views and conclusions contained herein are those of the
authors and should not be interpreted as necessarily representing the authors and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of official policies or endorsements, either expressed or implied, of
the Ambient Networks project or the European Commission. the Ambient Networks project or the European Commission.
8. References 8. References
skipping to change at page 12, line 45 skipping to change at page 13, line 28
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
8.2. Informative References 8.2. Informative References
[I-D.eddy-tcp-mobility] [I-D.eddy-tcp-mobility]
Eddy, W., "Mobility Support For TCP", Eddy, W., "Mobility Support For TCP",
draft-eddy-tcp-mobility-00 (work in progress), April 2004. draft-eddy-tcp-mobility-00 (work in progress), April 2004.
[I-D.ietf-tcpm-syn-flood]
Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", draft-ietf-tcpm-syn-flood-00 (work in
progress), July 2006.
[MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring [MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring
Interactions Between Transport Protocols and Middleboxes", Interactions Between Transport Protocols and
Proc. 4th ACM SIGCOMM/USENIX Conference on Internet Middleboxes", Proc. 4th ACM SIGCOMM/USENIX Conference on
Measurement , October 2004. Internet Measurement , October 2004.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
skipping to change at page 14, line 10 skipping to change at page 15, line 4
connections. connections.
The proposed TCP User Timeout Option, on the other hand, allows hosts The proposed TCP User Timeout Option, on the other hand, allows hosts
to selectively manage the user timeouts of individual connections, to selectively manage the user timeouts of individual connections,
reducing the amount of state they must maintain across disconnected reducing the amount of state they must maintain across disconnected
periods. periods.
Appendix B. Document Revision History Appendix B. Document Revision History
To be removed upon publication To be removed upon publication
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| Revision | Comments | | Revision | Comments |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| 04 | Clarified the results obtained by Medina et al. Added |
| | text to suggest inclusion of the UTO in the first |
| | non-SYN segment by the TCP that sent a SYN in response |
| | to an active OPEN. |
| 03 | Corrected use of RFC2119 terminology. Clarified how | | 03 | Corrected use of RFC2119 terminology. Clarified how |
| | use of the TCP UTO is triggered. Clarified reason for | | | use of the TCP UTO is triggered. Clarified reason for |
| | sending a UTO in the SYN and SYN/ACK segments. | | | sending a UTO in the SYN and SYN/ACK segments. |
| | Removed discussion of the SO_SNDTIMEO and SO_RCVTIMEO | | | Removed discussion of the SO_SNDTIMEO and SO_RCVTIMEO |
| | options. Removed text that suggested that a UTO | | | options. Removed text that suggested that a UTO |
| | should be sent upon receipt of an UTO from the remote | | | should be sent upon receipt of an UTO from the remote |
| | peer. Required minimum value for the lower limit of | | | peer. Required minimum value for the lower limit of |
| | the user timeout. Moved alternative solutions to | | | the user timeout. Moved alternative solutions to |
| | appendix. Miscellaneous editorial changes. | | | appendix. Miscellaneous editorial changes. |
| 02 | Corrected terminology by replacing terms like | | 02 | Corrected terminology by replacing terms like |
skipping to change at page 16, line 5 skipping to change at page 17, line 5
Fernando Gont Fernando Gont
Universidad Tecnologica Nacional Universidad Tecnologica Nacional
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fernando@gont.com.ar Email: fernando@gont.com.ar
URI: http://www.gont.com.ar/ URI: http://www.gont.com.ar/
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 16, line 29 skipping to change at page 17, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 21 change blocks. 
59 lines changed or deleted 77 lines changed or added

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