draft-ietf-tcpm-tcp-soft-errors-00.txt   draft-ietf-tcpm-tcp-soft-errors-01.txt 
TCP Maintenance and Minor F. Gont TCP Maintenance and Minor F. Gont
Extensions (tcpm) UTN/FRH Extensions (tcpm) UTN/FRH
Expires: August 20, 2006 Intended status: Informational
Expires: February 9, 2007
TCP's Reaction to Soft Errors TCP's Reaction to Soft Errors
draft-ietf-tcpm-tcp-soft-errors-00.txt draft-ietf-tcpm-tcp-soft-errors-01.txt
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 34 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 August 20, 2006. This Internet-Draft will expire on February 9, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document discusses the problem of long delays between connection This document discusses the problem of long delays between connection
establishment attempts that may arise in a number of scenarios, establishment attempts that may arise in a number of scenarios,
including that in which dual stack nodes that have IPv6 enabled by including one in which dual stack nodes that have IPv6 enabled by
default are deployed in IPv4 or mixed IPv4 and IPv6 environments. default are deployed in IPv4 or mixed IPv4 and IPv6 environments.
Additionally, it describes a modification to TCP's reaction to soft Additionally, this document describes a modification to TCP's
errors that has been implemented in a variety of TCP/IP stacks to reaction to soft errors that has been implemented in a variety of
help overcome this problem. TCP/IP stacks to help overcome this problem.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Error Handling in TCP . . . . . . . . . . . . . . . . . . . . 3 2. Error Handling in TCP . . . . . . . . . . . . . . . . . . . . 3
2.1. Reaction to Hard Errors . . . . . . . . . . . . . . . . . 4 2.1. Reaction to Hard Errors . . . . . . . . . . . . . . . . . 4
2.2. Reaction to Soft Errors . . . . . . . . . . . . . . . . . 4 2.2. Reaction to Soft Errors . . . . . . . . . . . . . . . . . 4
3. Problems that may arise from TCP's reaction to soft errors . . 5 3. Problems that may arise from TCP's reaction to soft errors . . 5
3.1. General Discussion . . . . . . . . . . . . . . . . . . . . 5 3.1. General Discussion . . . . . . . . . . . . . . . . . . . . 5
3.2. Problems that may arise with Dual Stack IPv6 on by 3.2. Problems that may arise with Dual Stack IPv6 on by
Default . . . . . . . . . . . . . . . . . . . . . . . . . 5 Default . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. A workaround for long delays between 4. A workaround for long delays between
connection-establishment attempts . . . . . . . . . . . . . . 6 connection-establishment attempts . . . . . . . . . . . . . . 6
5. Possible drawbacks . . . . . . . . . . . . . . . . . . . . . . 7 5. Possible drawbacks . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Non-deterministic transient network failures . . . . . . . 7 5.1. Non-deterministic transient network failures . . . . . . . 7
5.2. Deterministic transient network failures . . . . . . . . . 7 5.2. Deterministic transient network failures . . . . . . . . . 7
6. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Other possible solutions . . . . . . . . . . . . . . 10 Appendix A. Other possible solutions . . . . . . . . . . . . . . 10
A.1. A more conservative approach . . . . . . . . . . . . . . . 10 A.1. A more conservative approach . . . . . . . . . . . . . . . 10
A.2. Asynchronous Application Notification . . . . . . . . . . 11 A.2. Asynchronous Application Notification . . . . . . . . . . 11
A.3. Issuing several connection requests in parallel . . . . . 11 A.3. Issuing several connection requests in parallel . . . . . 11
Appendix B. Change log (to be removed before publication of Appendix B. Change log (to be removed before publication of
the document as an RFC) . . . . . . . . . . . . . . . 12 the document as an RFC) . . . . . . . . . . . . . . . 12
B.1. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 12 B.1. Changes from draft-ietf-tcpm-tcp-soft-errors-00 . . . . . 12
B.2. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 12 B.2. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 12
B.3. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . 12 B.3. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 12
B.4. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Introduction 1. Introduction
The handling of network failures can be separated into two different The handling of network failures can be separated into two different
actions: fault isolation and fault recovery. Fault isolation is the actions: fault isolation and fault recovery. Fault isolation
actions that hosts and routers take to determine that there is some consists of the actions that hosts and routers take to determine that
network failure. Fault recovery, on the other hand, is the actions there is a network failure. Fault recovery, on the other hand,
that hosts and routers will perform to isolate and survive a network consists of the actions that hosts and routers perform to survive a
failure.[RFC0816] network failure.[RFC0816]
In the Internet architecture, the Internet Control Message Protocol In the Internet architecture, the Internet Control Message Protocol
(ICMP) [RFC0792] is used to perform the fault isolation function, (ICMP) [RFC0792] is used to perform the fault isolation function,
that is, to report network error conditions to the hosts sending that is, to report network error conditions to the hosts sending
datagrams over the network. datagrams over the network.
When a host is signalled of a network error, there is still the issue When a host is signalled of a network error, there is still the issue
of what to do to let communication survive, if possible, the network of what to do to let communication survive, if possible, the network
failure. The fault recovery strategy may depend on the type of failure. The fault recovery strategy may depend on the type of
network failure taking place, and the time the error condition is network failure taking place, and the time the error condition is
skipping to change at page 3, line 43 skipping to change at page 3, line 43
in a variety of TCP/IP stacks to help overcome the problems discussed in a variety of TCP/IP stacks to help overcome the problems discussed
in this document. in this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Error Handling in TCP 2. Error Handling in TCP
Network errors can be divided into soft and hard errors. Soft errors Network errors can be divided into soft and hard errors. Soft errors
are considered to be transient network failures, which will hopefully are considered to be transient network failures, which are likely to
be solved in the near term. Hard errors, on the other hand, are be solved in the near term. Hard errors, on the other hand, are
considered to reflect permanent network error conditions, which are considered to reflect permanent network error conditions, which are
unlikely to be solved in the near future. unlikely to be solved in the near future.
Therefore, it may make sense for the fault recovery action to be Therefore, it may make sense for the fault recovery action to be
different depending on the type of error being detected. different depending on the type of error being detected.
When there is a network failure that's not signalled to the sending When there is a network failure that's not signalled to the sending
host, such as a gateway corrupting packets, TCP's fault recovery host, such as a gateway corrupting packets, TCP's fault recovery
action is to repeatedly retransmit the segment until either it gets action is to repeatedly retransmit the segment until either it gets
skipping to change at page 5, line 27 skipping to change at page 5, line 27
host is trying to communicate with a destination whose name resolves host is trying to communicate with a destination whose name resolves
to several IP addresses. The application on the local host will try to several IP addresses. The application on the local host will try
to establish a connection with the destination host, cycling through to establish a connection with the destination host, cycling through
the list of IP addresses, until one succeeds [RFC1123]. Suppose that the list of IP addresses, until one succeeds [RFC1123]. Suppose that
some (but not all) of the addresses in the returned list are some (but not all) of the addresses in the returned list are
permanently unreachable. If they are the first IP addresses in the permanently unreachable. If they are the first IP addresses in the
list, the application will usually try to use these addresses first. list, the application will usually try to use these addresses first.
As discussed in Section 2, this unreachability condition may or may As discussed in Section 2, this unreachability condition may or may
not be signalled to the sending host. If the local TCP is not not be signalled to the sending host. If the local TCP is not
signalled of the error condition, there is very little that can be signalled concerning the error condition, there is very little that
done other than repeatedly retransmit the SYN segment, and wait for can be done other than repeatedly retransmit the SYN segment, and
the existing timeout mechanism in TCP, or an application timeout, to wait for the existing timeout mechanism in TCP, or an application
be triggered. However, even if unreachability is signalled by some timeout, to be triggered. However, even if unreachability is
intermediate router to the local TCP by means of an ICMP error signalled by some intermediate router to the local TCP by means of an
message, the local TCP will just record the error message and will ICMP error message, the local TCP will record the error message and
still repeatedly retransmit the SYN segment until the connection will still repeatedly retransmit the SYN segment until the connection
timer expires. The "Requirements For Internet Hosts -- Communication timer expires. The "Requirements For Internet Hosts -- Communication
Layers" RFC [RFC1122] states that this timer MUST be large enough to Layers" RFC [RFC1122] states that this timer MUST be large enough to
provide retransmission of the SYN segment for at least 3 minutes. provide retransmission of the SYN segment for at least 3 minutes.
This would mean that the application on the local host would spend This would mean that the application on the local host would spend
several minutes for each unreachable address it uses for trying to several minutes for each unreachable address it uses for trying to
establish a TCP connection. These long delays between connection establish a TCP connection. These long delays between connection
establishment attempts would be inappropriate for interactive establishment attempts would be inappropriate for interactive
applications such as the web. [Shneiderman] [Thadani] applications such as the web. [Shneiderman] [Thadani]
3.2. Problems that may arise with Dual Stack IPv6 on by Default 3.2. Problems that may arise with Dual Stack IPv6 on by Default
skipping to change at page 6, line 8 skipping to change at page 6, line 8
Another scenario in which this type of problem may occur is that Another scenario in which this type of problem may occur is that
where dual stack nodes that have IPv6 enabled by default are deployed where dual stack nodes that have IPv6 enabled by default are deployed
in IPv4 or mixed IPv4 and IPv6 environments, and the IPv6 in IPv4 or mixed IPv4 and IPv6 environments, and the IPv6
connectivity is non-existent [I-D.ietf-v6ops-v6onbydefault]. connectivity is non-existent [I-D.ietf-v6ops-v6onbydefault].
As discussed in [I-D.ietf-v6ops-v6onbydefault], there are two As discussed in [I-D.ietf-v6ops-v6onbydefault], there are two
possible variants of this scenario, which differ in whether the lack possible variants of this scenario, which differ in whether the lack
of connectivity is signalled to the sending node, or not. of connectivity is signalled to the sending node, or not.
In cases where packets sent to a destination are silently dropped and In cases where packets sent to a destination are silently dropped and
no ICMPv6 [RFC2463] errors are generated, there is very little that no ICMPv6 [RFC4443] errors are generated, there is very little that
can be done other than waiting for the existing connection timeout can be done other than waiting for the existing connection timeout
mechanism in TCP, or an application timeout, to be triggered. mechanism in TCP, or an application timeout, to be triggered.
In cases where a node has no default routers and Neighbor In cases where a node has no default routers and Neighbor
Unreachability Detection (NUD) fails for destinations assumed to be Unreachability Detection (NUD) fails for destinations assumed to be
on-link, or where firewalls or other systems that enforce scope on-link, or where firewalls or other systems that enforce scope
boundaries send ICMPv6 errors, the sending node will be signalled of boundaries send ICMPv6 errors, the sending node will be signalled of
the unreachability problem. However, as discussed in Section 2.2, the unreachability problem. However, as discussed in Section 2.2,
TCP implementations will not abort connections when receiving ICMP TCP implementations will not abort connections when receiving ICMP
error messages that indicate soft errors. error messages that indicate soft errors.
4. A workaround for long delays between connection-establishment 4. A workaround for long delays between connection-establishment
attempts attempts
As discussed in Section 1, it may make sense for the fault recovery As discussed in Section 1, it may make sense for the fault recovery
action to depend not only on the type of error being reported, but action to depend not only on the type of error being reported, but
also on the time the error is reported. For example, one could infer also on the state of the connection against which the error is
that when an error arrives in response to opening a new connection, reported. For example, one could infer that when an error arrives in
it is probably caused by opening the connection improperly, rather response to opening a new connection, it is probably caused by
than by a transient network failure. [RFC0816] opening the connection improperly, rather than by a transient network
failure. [RFC0816]
A variety of TCP/IP stacks have modified TCP's reaction to soft A variety of TCP/IP stacks have modified TCP's reaction to soft
errors, to make it abort a connection in the SYN-SENT or the SYN- errors, to make it abort a connection in the SYN-SENT or the SYN-
RECEIVED state if it receives an ICMP "Destination Unreachable" RECEIVED state if it receives an ICMP "Destination Unreachable"
message that indicates a soft error about that connection. message that indicates a soft error about that connection.
The "Requirements for Internet Hosts -- Communication Layers" RFC The "Requirements for Internet Hosts -- Communication Layers" RFC
[RFC1122] states, in section 4.2.3.9., that the ICMP "Destination [RFC1122] states, in section 4.2.3.9., that the ICMP "Destination
Unreachable" messages that indicate soft errors are ICMP codes 0 Unreachable" messages that indicate soft errors are ICMP codes 0
(network unreachable), 1 (host unreachable), and 5 (source route (network unreachable), 1 (host unreachable), and 5 (source route
skipping to change at page 7, line 33 skipping to change at page 7, line 34
a Mail Transfer Agent (MTA), usually must implement application-layer a Mail Transfer Agent (MTA), usually must implement application-layer
retry mechanisms, and thus are able to handle these scenarios retry mechanisms, and thus are able to handle these scenarios
appropriately. For interactive applications, the user would likely appropriately. For interactive applications, the user would likely
not be satisfied with a connection attempt that succeeds only after not be satisfied with a connection attempt that succeeds only after
several seconds, anyway. [Guynes] several seconds, anyway. [Guynes]
5.2. Deterministic transient network failures 5.2. Deterministic transient network failures
There are some scenarios in which transient network failures could be There are some scenarios in which transient network failures could be
deterministic. For example, consider the case in which upstream deterministic. For example, consider the case in which upstream
network connectivity is triggered by network use. In this scenario, network connectivity is triggered by network use. That is, network
the connection triggering the upstream connectivity would connectivity is instantiated only on an "as needed" basis. In this
scenario, the connection triggering the upstream connectivity would
deterministically receive ICMP Destination Unreachables while the deterministically receive ICMP Destination Unreachables while the
upstream connectivity is being activated, and thus would be aborted. upstream connectivity is being activated, and thus would be aborted.
As discussed in Section 5.1, applications usually implement As discussed in Section 5.1, applications usually implement
mechanisms to handle these scenarios appropriately. Also, connection mechanisms to handle these scenarios appropriately. Also, connection
attempts are usually preceded by a UDP-based DNS name-to-address attempts are usually preceded by a UDP-based DNS name-to-address
lookup. Thus, unless the name-to-address mapping has been cached by lookup. Thus, unless the name-to-address mapping has been cached by
a local nameserver or resolver, it will be the DNS query that will a local nameserver or resolver, it will be the DNS query that will
trigger the upstream network connectivity, and thus the corresponding trigger the upstream network connectivity, and thus the corresponding
connection will not be aborted. connection will not be aborted.
skipping to change at page 8, line 33 skipping to change at page 8, line 38
In any case, it must be noted that the workaround discussed in this In any case, it must be noted that the workaround discussed in this
document neither strengthens nor weakens TCP's resistance to attack. document neither strengthens nor weakens TCP's resistance to attack.
An attacker wishing to reset ongoing TCP connections could perform An attacker wishing to reset ongoing TCP connections could perform
the attack by sending any of the ICMP error messages that indicate the attack by sending any of the ICMP error messages that indicate
"hard errors", not only for connections in the SYN-SENT or the SYN- "hard errors", not only for connections in the SYN-SENT or the SYN-
RECEIVED states, but for connections in any state. RECEIVED states, but for connections in any state.
A discussion of the use of ICMP to perform a variety of attacks A discussion of the use of ICMP to perform a variety of attacks
against TCP, and a number of counter-measures that eliminate or against TCP, and a number of counter-measures that eliminate or
greatly minimize the impact of these attacks can be found in greatly minimize the impact of these attacks can be found in
[I-D.gont-tcpm-icmp-attacks]. [I-D.ietf-tcpm-icmp-attacks].
A discussion of the security issues arising from the use of ICMPv6 A discussion of the security issues arising from the use of ICMPv6
can be found in [RFC2463]. can be found in [RFC4443].
8. Acknowledgements 8. Acknowledgements
The author wishes to thank Michael Kerrisk, Eddie Kohler, Mika The author wishes to thank Ron Bonica, Guillermo Gont, Michael
Liljeberg, Pasi Sarolahti, Pekka Savola, and Joe Touch, for Kerrisk, Eddie Kohler, Mika Liljeberg, Pasi Sarolahti, Pekka Savola,
contributing many valuable comments. and Joe Touch, for contributing many valuable comments.
9. Contributors 9. Contributors
Mika Liljeberg was the first to describe how their implementation Mika Liljeberg was the first to describe how their implementation
treated soft errors. Based on that, the solution discussed in treated soft errors. Based on that, the solution discussed in
Section 4 was documented in [I-D.ietf-v6ops-v6onbydefault] by Section 4 was documented in [I-D.ietf-v6ops-v6onbydefault] by
Sebastien Roy, Alain Durand and James Paugh. Sebastien Roy, Alain Durand and James Paugh.
10. References 10. References
skipping to change at page 9, line 25 skipping to change at page 9, line 31
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2463] Conta, A. and S. Deering, "Internet Control Message [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Protocol (ICMPv6) for the Internet Protocol Version 6 Message Protocol (ICMPv6) for the Internet Protocol
(IPv6) Specification", RFC 2463, December 1998. Version 6 (IPv6) Specification", RFC 4443, March 2006.
10.2. Informative References 10.2. Informative References
[Guynes] Guynes, J., "Impact of System Response Time on State [Guynes] Guynes, J., "Impact of System Response Time on State
Anxiety", Communications of the ACM , 1988. Anxiety", Communications of the ACM , 1988.
[I-D.gont-tcpm-icmp-attacks] [I-D.ietf-tcpm-icmp-attacks]
Gont, F., "ICMP attacks against TCP", Gont, F., "ICMP attacks against TCP",
draft-gont-tcpm-icmp-attacks-05 (work in progress), draft-ietf-tcpm-icmp-attacks-00 (work in progress),
October 2005. February 2006.
[I-D.ietf-v6ops-v6onbydefault] [I-D.ietf-v6ops-v6onbydefault]
Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack
IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
(work in progress), July 2004. (work in progress), July 2004.
[Linux] The Linux Project, "http://www.kernel.org". [Linux] The Linux Project, "http://www.kernel.org".
[RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816,
July 1982. July 1982.
skipping to change at page 12, line 10 skipping to change at page 12, line 15
establishing a connection with the destination host. establishing a connection with the destination host.
In any case, it must be noted that both approaches have the same In any case, it must be noted that both approaches have the same
drawbacks as the solution described in Appendix A.2: they would drawbacks as the solution described in Appendix A.2: they would
increase application complexity, and would take too long to begin to increase application complexity, and would take too long to begin to
be used by applications. be used by applications.
Appendix B. Change log (to be removed before publication of the Appendix B. Change log (to be removed before publication of the
document as an RFC) document as an RFC)
B.1. Changes from draft-gont-tcpm-tcp-soft-errors-02 B.1. Changes from draft-ietf-tcpm-tcp-soft-errors-00
o Miscellaneous editorial changes
B.2. Changes from draft-gont-tcpm-tcp-soft-errors-02
o Draft resubmitted as draft-ietf. o Draft resubmitted as draft-ietf.
o Miscellaneous editorial changes o Miscellaneous editorial changes
B.2. Changes from draft-gont-tcpm-tcp-soft-errors-01 B.3. Changes from draft-gont-tcpm-tcp-soft-errors-01
o Changed wording to describe the mechanism, rather than proposing o Changed wording to describe the mechanism, rather than proposing
it it
o Miscellaneous editorial changes o Miscellaneous editorial changes
B.3. Changes from draft-gont-tcpm-tcp-soft-errors-00 B.4. Changes from draft-gont-tcpm-tcp-soft-errors-00
o Added reference to the Linux implementation in Section 4 o Added reference to the Linux implementation in Section 4
o Added Section 5 o Added Section 5
o Added Section 6 o Added Section 6
o Added Appendix A.1 o Added Appendix A.1
o Moved section "Asynchronous Application Notification" to o Moved section "Asynchronous Application Notification" to
Appendix A.2 Appendix A.2
o Added a Appendix A.3 o Added a Appendix A.3
o Miscellaneous editorial changes o Miscellaneous editorial changes
Author's Address Author's Address
Fernando Gont Fernando Gont
Universidad Tecnologica Nacional Universidad Tecnologica Nacional/Facultad Regional Haedo
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 14, line 29 skipping to change at page 14, 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. 27 change blocks. 
64 lines changed or deleted 72 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/