doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc5461.txt b/doc/rfc/rfc5461.txt
new file mode 100644
index 0000000..7df1864
--- /dev/null
+++ b/doc/rfc/rfc5461.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                            F. Gont
+Request for Comments: 5461                                       UTN/FRH
+Category: Informational                                    February 2009
+
+
+                     TCP's Reaction to Soft Errors
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 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
+   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.
+
+Abstract
+
+   This document describes a non-standard, but widely implemented,
+   modification to TCP's handling of ICMP soft error messages that
+   rejects pending connection-requests when those error messages are
+   received.  This behavior reduces the likelihood of long delays
+   between connection-establishment attempts that may arise in a number
+   of scenarios, including one in which dual-stack nodes that have IPv6
+   enabled by default are deployed in IPv4 or mixed IPv4 and IPv6
+   environments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont                         Informational                      [Page 1]
+
+RFC 5461             TCP's Reaction to Soft Errors         February 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Error Handling in TCP  . . . . . . . . . . . . . . . . . . . .  3
+     2.1.  Reaction to ICMP Error Messages That Indicate Hard
+           Errors . . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.2.  Reaction to ICMP Error Messages That Indicate Soft
+           Errors . . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.  Problems That May Arise from TCP's Reaction to Soft Errors . .  5
+     3.1.  General Discussion . . . . . . . . . . . . . . . . . . . .  5
+     3.2.  Problems That May Arise with Dual-Stack IPv6 on by
+           Default  . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   4.  Deployed Workarounds for Long Delays between
+       Connection-Establishment Attempts  . . . . . . . . . . . . . .  7
+     4.1.  Context-Sensitive ICMP/TCP Interaction . . . . . . . . . .  7
+     4.2.  Context-Sensitive ICMP/TCP Interaction with Repeated
+           Confirmation . . . . . . . . . . . . . . . . . . . . . . .  8
+   5.  Possible Drawbacks of Changing ICMP Semantics  . . . . . . . .  9
+     5.1.  Non-Deterministic Transient Network Failures . . . . . . .  9
+     5.2.  Deterministic Transient Network Failures . . . . . . . . . 10
+     5.3.  Non-Compliant Network Address Translators (NATs) . . . . . 10
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
+   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont                         Informational                      [Page 2]
+
+RFC 5461             TCP's Reaction to Soft Errors         February 2009
+
+
+1.  Introduction
+
+   The handling of network failures can be separated into two different
+   actions: fault isolation and fault recovery.  Fault isolation
+   consists of the actions that hosts and routers take to determine that
+   there is a network failure.  Fault recovery, on the other hand,
+   consists of the actions that hosts and routers perform in an attempt
+   to survive a network failure [RFC0816].
+
+   In the Internet architecture, the Internet Control Message Protocol
+   (ICMP) [RFC0792] is one fault isolation technique to report network
+   error conditions to the hosts sending datagrams over the network.
+
+   When a host is notified of a network error, its network stack will
+   attempt to continue communications, if possible, in the presence of
+   the network failure.  The fault recovery strategy may depend on the
+   type of network failure taking place and the time at which the error
+   condition is detected.
+
+   This document analyzes the problems that may arise due to TCP's fault
+   recovery reactions to ICMP soft errors.  It analyzes the problems
+   that may arise when a host tries to establish a TCP connection with a
+   multihomed host that has some unreachable addresses.  Additionally,
+   it analyzes the problems that may arise in the specific scenario
+   where dual-stack nodes that have IPv6 enabled by default are deployed
+   in IPv4 or mixed IPv4 and IPv6 environments.
+
+   Finally, we document a modification to TCP's reaction to ICMP
+   messages indicating soft errors during connection startup that has
+   been implemented in a variety of TCP/IP stacks to help overcome the
+   problems outlined below.  We stress that this modification runs
+   contrary to the standard behavior and this document unambiguously
+   does not change the standard reaction.
+
+   [Gont] describes alternative approaches for dealing with the problem
+   of long delays between connection-establishment attempts in TCP.
+
+   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.  Error Handling in TCP
+
+   Network errors can be divided into soft and hard errors.  Soft errors
+   are considered to be transient network failures that are likely to be
+   solved in the near term.  Hard errors, on the other hand, are
+   considered to reflect network error conditions that are unlikely to
+   be solved in the near future.
+
+
+
+Gont                         Informational                      [Page 3]
+
+RFC 5461             TCP's Reaction to Soft Errors         February 2009
+
+
+   The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that
+   the ICMP messages that indicate soft errors are ICMP "Destination
+   Unreachable" codes 0 (network unreachable), 1 (host unreachable), and
+   5 (source route failed); ICMP "Time Exceeded" codes 0 (time to live
+   exceeded in transit) and 1 (fragment reassembly time exceeded); and
+   ICMP "Parameter Problem".  Even though ICMPv6 did not exist when
+   [RFC1122] was written, one could extrapolate the concept of soft
+   errors to ICMPv6 "Destination Unreachable" codes 0 (no route to
+   destination) and 3 (address unreachable); ICMPv6 "Time Exceeded"
+   codes 0 (hop limit exceeded in transit) and 1 (fragment reassembly
+   time exceeded); and ICMPv6 "Parameter Problem" codes 0 (erroneous
+   header field encountered), 1 (unrecognized Next Header type
+   encountered), and 2 (unrecognized IPv6 option encountered) [RFC4443].
+
+   +----------------------------------+--------------------------------+
+   |               ICMP               |             ICMPv6             |
+   +----------------------------------+--------------------------------+
+   |  Destination Unreachable (codes  | Destination Unreachable (codes |
+   |           0, 1, and 5)           |            0 and 3)            |
+   +----------------------------------+--------------------------------+
+   |   Time Exceeded (codes 0 and 1)  |  Time Exceeded (codes 0 and 1) |
+   +----------------------------------+--------------------------------+
+   |         Parameter Problem        | Parameter Problem (codes 0, 1, |
+   |                                  |             and 2)             |
+   +----------------------------------+--------------------------------+
+
+        Table 1: Extrapolating the concept of soft errors to ICMPv6
+
+   When there is a network failure that is not signaled to the sending
+   host, such as a gateway corrupting packets, TCP's fault recovery
+   action is to repeatedly retransmit the corresponding data until
+   either they get acknowledged or the connection times out.
+
+   In the case that a host does receive an ICMP error message referring
+   to an ongoing TCP connection, the IP layer will pass this message up
+   to the corresponding TCP instance to raise awareness of the network
+   failure [RFC1122].  TCP's reaction to ICMP messages will depend on
+   the type of error being signaled.
+
+2.1.  Reaction to ICMP Error Messages That Indicate Hard Errors
+
+   When receiving an ICMP error message that indicates a hard error
+   condition, compliant TCP implementations will simply abort the
+   corresponding connection, regardless of the connection state.
+
+   The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that
+   TCP SHOULD abort connections when receiving ICMP error messages that
+   indicate hard errors.  This policy is based on the premise that, as
+
+
+
+Gont                         Informational                      [Page 4]
+
+RFC 5461             TCP's Reaction to Soft Errors         February 2009
+
+
+   hard errors indicate network error conditions that will not change in
+   the near term, it will not be possible for TCP to usefully recover
+   from this type of network failure.
+
+   It should be noted that virtually none of the current TCP
+   implementations follow the advice in [RFC1122], and they do not abort
+   the corresponding connection when an ICMP hard error is received for
+   a connection that is in any of the synchronized states
+   [ICMP-ATTACKS].
+
+2.2.  Reaction to ICMP Error Messages That Indicate Soft Errors
+
+   If an ICMP error message is received that indicates a soft error, TCP
+   will repeatedly retransmit the corresponding data until either they
+   get acknowledged or the connection times out.  In addition, the TCP
+   sender may record the information for possible later use (see
+   [Stevens], pp. 317-319).
+
+   The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that
+   TCP MUST NOT abort connections when receiving ICMP error messages
+   that indicate soft errors.  This policy is based on the premise that,
+   as soft errors are transient network failures that will hopefully be
+   solved in the near term, one of the retransmissions will succeed.
+
+   When the connection timer expires and an ICMP soft error message has
+   been received before the timeout, TCP can use this information to
+   provide the user with a more specific error message (see [Stevens],
+   pp. 317-319).
+
+   This reaction to soft errors exploits a valuable feature of the
+   Internet -- that, for many network failures, the network can be
+   dynamically reconstructed without any disruption of the endpoints.
+
+3.  Problems That May Arise from TCP's Reaction to Soft Errors
+
+3.1.  General Discussion
+
+   Even though TCP's fault recovery strategy in the presence of soft
+   errors allows for TCP connections to survive transient network
+   failures, there are scenarios in which this policy may cause
+   undesirable effects.
+
+   For example, consider a scenario in which an application on a local
+   host is trying to communicate with a destination whose name resolves
+   to several IP addresses.  The application on the local host will try
+   to establish a connection with the destination host, usually cycling
+   through the list of IP addresses until one succeeds [RFC1123].
+   Suppose that some (but not all) of the addresses in the returned list
+
+
+
+Gont                         Informational                      [Page 5]
+
+RFC 5461             TCP's Reaction to Soft Errors         February 2009
+
+
+   are permanently unreachable.  If such a permanently unreachable
+   address is the first in the list, the application will likely try to
+   use it first and block waiting for a timeout before trying an
+   alternate address.
+
+   As discussed in Section 2, this unreachability condition may or may
+   not be signaled to the sending host.  If the local TCP is not
+   signaled concerning the error condition, there is very little that
+   can be done other than to repeatedly retransmit the SYN segment and
+   wait for the existing timeout mechanism in TCP, or an application
+   timeout, to be triggered.  However, even if unreachability is
+   signaled by some intermediate router to the local TCP by means of an
+   ICMP soft error message, the local TCP will still repeatedly
+   retransmit the SYN segment until the connection timer expires (in the
+   hopes that the error is transient).  The Host Requirements RFC
+   [RFC1122] states that this timer MUST be large enough to provide
+   retransmission of the SYN segment for at least 3 minutes.  This would
+   mean that the application on the local host would spend several
+   minutes for each unreachable address with which it tries to establish
+   the TCP connection.  These long delays between connection-
+   establishment attempts would be inappropriate for many interactive
+   applications, such as the Web. [Shneiderman] and [Thadani] offer some
+   insight into interactive systems (e.g., how the response time affects
+   the usability of an application).  This highlights that there is no
+   one definition of a "transient error" and that the level of
+   persistence in the face of failure represents a tradeoff.
+
+   It is worth noting that while most applications try the addresses
+   returned by the name-to-address function in serial, this is certainly
+   not the only possible approach.  For example, applications could try
+   multiple addresses in parallel until one succeeds, possibly avoiding
+   the problem of long delays between connection-establishment attempts
+   described in this document [Gont].
+
+3.2.  Problems That May Arise with Dual-Stack IPv6 on by Default
+
+   A particular scenario in which the above type of problem may occur
+   regularly is that where dual-stack nodes that have IPv6 enabled by
+   default are deployed in IPv4 or mixed IPv4 and IPv6 environments and
+   the IPv6 connectivity is non-existent [RFC4943].
+
+   As discussed in [RFC4943], there are two possible variants of this
+   scenario, which differ in whether or not the lack of connectivity is
+   signaled to the sending node.
+
+
+
+
+
+
+
+Gont                         Informational                      [Page 6]
+
+RFC 5461             TCP's Reaction to Soft Errors         February 2009
+
+
+   In those scenarios in which packets sent to a destination are
+   silently dropped and no ICMPv6 [RFC4443] errors are generated, there
+   is little that can be done other than to wait for the existing
+   connection-timeout mechanism in TCP, or an application timeout, to be
+   triggered.
+
+   In scenarios where a legacy node has no default routers and Neighbor
+   Unreachability Detection (NUD) [RFC4861] fails for destinations
+   assumed to be on-link, or where firewalls or other systems that
+   enforce scope boundaries send ICMPv6 errors, the sending node will be
+   signaled of the unreachability problem.  However, as discussed in
+   Section 2.2, compliant TCP implementations will not abort connections
+   when receiving ICMP error messages that indicate soft errors.
+
+4.  Deployed Workarounds for Long Delays between Connection-
+    Establishment Attempts
+
+   The following subsections describe a number of workarounds for the
+   problem of long delays between connection-establishment attempts that
+   have been implemented in a variety of TCP/IP stacks.  We note that
+   treating soft errors as hard errors during connection establishment,
+   while widespread, is not part of standard TCP behavior and this
+   document does not change that state of affairs.  The consensus of the
+   TCPM WG (TCP Maintenance and Minor Extensions Working Group) was to
+   document this widespread implementation of nonstandard TCP behavior
+   but to not change the TCP standard.
+
+4.1.  Context-Sensitive ICMP/TCP Interaction
+
+   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
+   also on the state of the connection against which the error is
+   reported.  For example, one could infer that when an error arrives in
+   response to opening a new connection, it is probably caused by
+   opening the connection improperly, rather than by a transient network
+   failure [RFC0816].
+
+   A number of TCP implementations have modified their reaction to all
+   ICMP soft errors and treat them as hard errors when they are received
+   for connections in the SYN-SENT or SYN-RECEIVED states.  For example,
+   this workaround has been implemented in the Linux kernel since
+   version 2.0.0 (released in 1996) [Linux].  However, it should be
+   noted that this change violates section 4.2.3.9 of [RFC1122], which
+   states that these ICMP error messages indicate soft error conditions
+   and that, therefore, TCP MUST NOT abort the corresponding connection.
+
+
+
+
+
+
+Gont                         Informational                      [Page 7]
+
+RFC 5461             TCP's Reaction to Soft Errors         February 2009
+
+
+   [RFC3168] states that a host that receives a RST in response to the
+   transmission of an ECN (Explicit Congestion Notification)-setup SYN
+   packet MAY resend a SYN with the CWR (Congestion Window Reduced) and
+   ECE (ECN-Echo) bits cleared.  This is meant to deal with faulty
+   middle-boxes that reject connections when a SYN segment has the ECE
+   and CWR bits set.  Some faulty middle-boxes (e.g., firewalls) may
+   reject these connection requests with an ICMP soft error of type 3
+   (Destination Unreachable), code 0 (net unreachable) or 1 (host
+   unreachable), instead of a RST.  Therefore, a system that processes
+   ICMP soft error messages as hard errors when they are received for a
+   connection in any of the non-synchronized states could resend the SYN
+   segment with the ECE and CWR bits cleared when an ICMP "net
+   unreachable" (type 3, code 0) or "host unreachable" (type 3, code 1)
+   error message is received in response to a SYN segment that had these
+   bits set.
+
+   Section 4.2 discusses a more conservative approach than that sketched
+   above, which is implemented in FreeBSD.
+
+4.2.  Context-Sensitive ICMP/TCP Interaction with Repeated Confirmation
+
+   A more conservative approach than simply treating soft errors as hard
+   errors (as described above) would be to abort a connection in the
+   SYN-SENT or SYN-RECEIVED states only after an ICMP soft error has
+   been received a specified number of times and the SYN segment has
+   been retransmitted more than some specified number of times.
+
+   Two new parameters would have to be introduced to TCP, to be used
+   only during the connection-establishment phase: MAXSYNREXMIT and
+   MAXSOFTERROR.  MAXSYNREXMIT would specify the number of times the SYN
+   segment would have to be retransmitted before a connection is
+   aborted.  MAXSOFTERROR would specify the number of ICMP messages
+   indicating soft errors that would have to be received before a
+   connection is aborted.
+
+   Two additional state variables would need to be introduced to store
+   additional state information during the connection-establishment
+   phase: "nsynrexmit" and "nsofterror".  Both would be initialized to
+   zero when a connection attempt is initiated, with "nsynrexmit" being
+   incremented by one every time the SYN segment is retransmitted and
+   "nsofterror" being incremented by one every time an ICMP message that
+   indicates a soft error is received.
+
+   A connection in the SYN-SENT or SYN-RECEIVED states would be aborted
+   if "nsynrexmit" was greater than MAXSYNREXMIT and "nsofterror" was
+   simultaneously greater than MAXSOFTERROR.
+
+
+
+
+
+Gont                         Informational                      [Page 8]
+
+RFC 5461             TCP's Reaction to Soft Errors         February 2009
+
+
+   This approach would give the network more time to solve the
+   connectivity problem than does simply aborting a connection attempt
+   upon reception of the first soft error.  However, it should be noted
+   that, depending on the values chosen for the MAXSYNREXMIT and
+   MAXSOFTERROR parameters, this approach could still lead to long
+   delays between connection-establishment attempts, thus not solving
+   the problem.  For example, BSD systems abort connections in the SYN-
+   SENT or the SYN-RECEIVED state when a second ICMP error is received
+   and the SYN segment has been retransmitted more than three times.
+   They also set up a "connection-establishment timer" that imposes an
+   upper limit on the time the connection-establishment attempt has to
+   succeed, which expires after 75 seconds (see [Stevens2], pp. 828-
+   829).  Even when this policy may be better than the three-minute
+   timeout policy specified in [RFC1122], it may still be inappropriate
+   for handling the potential problems described in this document.  This
+   more conservative approach has been implemented in BSD systems for
+   more than ten years [Stevens2].
+
+   We also note that the approach given in this section is a generalized
+   version of the approach sketched in the previous section.  In
+   particular, with MAXSOFTERROR set to 1 and MAXSYNREXMIT set to zero,
+   the schemes are identical.
+
+5.  Possible Drawbacks of Changing ICMP Semantics
+
+   The following subsections discuss some possible drawbacks that could
+   arise from use of the non-standard modifications to TCP's reaction to
+   soft errors, which are described in Section 4.1 and Section 4.2.
+
+5.1.  Non-Deterministic Transient Network Failures
+
+   In scenarios where a transient network failure affects all of the
+   addresses returned by the name-to-address translation function, all
+   destinations could be unreachable for some short period of time.  For
+   example, a mobile system consisting of a cell and a repeater may pass
+   through a tunnel, leading to a loss of connectivity at the repeater,
+   with the repeater sending ICMP soft errors back to the cell.  Also, a
+   transient routing problem might lead some intervening router to drop
+   a SYN segment that was meaning to establish a TCP connection and send
+   an ICMP soft error back to the host.  Finally, a SYN segment carrying
+   data might get fragmented and some of the resulting fragments might
+   get lost, with the destination host timing out the reassembly process
+   and sending an ICMP soft error back to the sending host (although
+   this particular scenario is unlikely because, while [RFC0793] allows
+   SYN segments to carry data, in practice they do not).  In such
+   scenarios, the application could quickly cycle through all the IP
+   addresses in the list and return an error, when it could have let TCP
+
+
+
+
+Gont                         Informational                      [Page 9]
+
+RFC 5461             TCP's Reaction to Soft Errors         February 2009
+
+
+   retry a destination a few seconds later, when the transient problem
+   could have disappeared.  In this case, the modifications described
+   here make TCP less robust than a standards-compliant implementation.
+
+   Additionally, in many cases a domain name maps to a single IP
+   address.  In such a case, it might be better to try that address
+   persistently according to normal TCP rules, instead of just aborting
+   the pending connection upon receipt of an ICMP soft error.
+
+5.2.  Deterministic Transient Network Failures
+
+   There are some scenarios in which transient network failures could be
+   deterministic.  For example, consider a scenario in which upstream
+   network connectivity is triggered by network use.  That is, network
+   connectivity is instantiated only on an "as needed" basis.  In this
+   scenario, the connection triggering the upstream connectivity could
+   deterministically receive ICMP Destination Unreachables while the
+   upstream connectivity is being activated, and thus would be aborted.
+   Again, in this case, the modifications described here make TCP less
+   robust than a standards-compliant implementation.
+
+5.3.  Non-Compliant Network Address Translators (NATs)
+
+   Some NATs respond to an unsolicited inbound SYN segment with an ICMP
+   soft error message.  If the system sending the unsolicited SYN
+   segment implements the workaround described in this document, it will
+   abort the connection upon receipt of the ICMP error message, thus
+   probably preventing TCP's simultaneous open from succeeding through
+   the NAT.  However, it must be stressed that those NATs described in
+   this section are not BEHAVE-compliant and therefore should implement
+   REQ-4 of [RFC5382] instead.
+
+   In those scenarios in which such a non-BEHAVE-compliant NAT is
+   deployed, TCP simultaneous opens could fail.  While undesirable, this
+   is tolerable in many situations.  For instance, a number of host
+   implementations of TCP do not support TCP simultaneous opens
+   [Zuquete].
+
+6.  Security Considerations
+
+   This document describes a non-standard modification to TCP's reaction
+   to soft errors that has been implemented in a variety of TCP
+   implementations.  This modification makes TCP abort a connection in
+   the SYN-SENT or the SYN-RECEIVED states when it receives an ICMP
+   error message that indicates a soft error.  Therefore, the
+   modification could be exploited to reset valid connections during the
+   connection-establishment phase.
+
+
+
+
+Gont                         Informational                     [Page 10]
+
+RFC 5461             TCP's Reaction to Soft Errors         February 2009
+
+
+   The non-standard workaround described in this document makes TCP more
+   vulnerable to attack, even if only slightly.  However, we note that
+   an attacker wishing to reset ongoing TCP connections could send any
+   of the ICMP hard error messages in any connection state.
+
+   Generally, TCP backs off its retransmission timer each time it
+   retransmits the SYN segment for the same connection.  If a TCP
+   implements the modification described in this document, that is,
+   tries the next address in the list upon receipt of an ICMP error
+   message, it might end up injecting more packets into the network than
+   if it had simply retried the same address a number of times.
+   However, compliant TCP implementations might already incur this
+   behavior (e.g., as a result of cycling through the list of IP
+   addresses in response to RST segments) as there are currently no
+   recommendations on methods for limiting the rate at which SYN
+   segments are sent for connecting to a specific destination.
+
+   A discussion of the use of ICMP to perform a variety of attacks
+   against TCP, and a number of counter-measures that minimize the
+   impact of these attacks, can be found in [ICMP-ATTACKS].
+
+   A discussion of the security issues arising from the use of ICMPv6
+   can be found in [RFC4443].
+
+7.  Acknowledgements
+
+   The author wishes to thank Mark Allman, Jari Arkko, David Black, Ron
+   Bonica, Ted Faber, Gorry Fairhurst, Sally Floyd, Juan Fraschini,
+   Tomohiro Fujisaki, Guillermo Gont, Saikat Guha, Alfred Hoenes,
+   Michael Kerrisk, Eddie Kohler, Mika Liljeberg, Arifumi Matsumoto,
+   Sandy Murphy, Carlos Pignataro, Pasi Sarolahti, Pekka Savola, Pyda
+   Srisuresh, Jinmei Tatuya, and Joe Touch for contributing many
+   valuable comments on earlier versions of this document.
+
+   The author wishes to thank Secretaria de Extension Universitaria at
+   Universidad Tecnologica Nacional and Universidad Tecnologica
+   Nacional/Facultad Regional Haedo for their support in this work.
+
+   Finally, the author wishes to express deep and heartfelt gratitude to
+   Jorge Oscar Gont and Nelida Garcia for their precious motivation and
+   guidance.
+
+8.  Contributors
+
+   Mika Liljeberg was the first to describe how their implementation
+   treated soft errors.  Based on that, the solution discussed in
+   Section 4.1 was documented in [v6-ON] by Sebastien Roy, Alain Durand,
+   and James Paugh.
+
+
+
+Gont                         Informational                     [Page 11]
+
+RFC 5461             TCP's Reaction to Soft Errors         February 2009
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC0792]       Postel, J., "Internet Control Message Protocol",
+                   STD 5, RFC 792, September 1981.
+
+   [RFC0793]       Postel, J., "Transmission Control Protocol", STD 7,
+                   RFC 793, September 1981.
+
+   [RFC1122]       Braden, R., "Requirements for Internet Hosts -
+                   Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [RFC1123]       Braden, R., "Requirements for Internet Hosts -
+                   Application and Support", STD 3, RFC 1123,
+                   October 1989.
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3168]       Ramakrishnan, K., Floyd, S., and D. Black, "The
+                   Addition of Explicit Congestion Notification (ECN) to
+                   IP", RFC 3168, September 2001.
+
+   [RFC4443]       Conta, A., Deering, S., and M. Gupta, "Internet
+                   Control Message Protocol (ICMPv6) for the Internet
+                   Protocol Version 6 (IPv6) Specification", RFC 4443,
+                   March 2006.
+
+   [RFC4861]       Narten, T., Nordmark, E., Simpson, W., and H.
+                   Soliman, "Neighbor Discovery for IP version 6
+                   (IPv6)", RFC 4861, September 2007.
+
+9.2.  Informative References
+
+   [Gont]          Gont, F., "On the problem of long delays between
+                   connection-establishment attempts in TCP", Work
+                   in Progress, January 2009.
+
+   [ICMP-ATTACKS]  Gont, F., "ICMP attacks against TCP", Work
+                   in Progress, October 2008.
+
+   [Linux]         The Linux Project, "http://www.kernel.org".
+
+   [RFC0816]       Clark, D., "Fault isolation and recovery", RFC 816,
+                   July 1982.
+
+
+
+
+
+Gont                         Informational                     [Page 12]
+
+RFC 5461             TCP's Reaction to Soft Errors         February 2009
+
+
+   [RFC4943]       Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor
+                   Discovery On-Link Assumption Considered Harmful",
+                   RFC 4943, September 2007.
+
+   [RFC5382]       Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
+                   Srisuresh, "NAT Behavioral Requirements for TCP",
+                   BCP 142, RFC 5382, October 2008.
+
+   [Shneiderman]   Shneiderman, B., "Response Time and Display Rate in
+                   Human Performance with Computers", ACM
+                   Computing Surveys, 1984.
+
+   [Stevens]       Stevens, W., "TCP/IP Illustrated, Volume 1: The
+                   Protocols", Addison-Wesley, 1994.
+
+   [Stevens2]      Wright, G. and W. Stevens, "TCP/IP Illustrated,
+                   Volume 2: The Implementation", Addison-Wesley, 1994.
+
+   [Thadani]       Thadani, A., "Interactive User Productivity", IBM
+                   Systems Journal, No. 1, 1981.
+
+   [Zuquete]       Zuquete, A., "Improving the functionality of SYN
+                   cookies", 6th IFIP Communications and Multimedia
+                   Security Conference (CMS 2002), 2002.
+
+   [v6-ON]         Roy, S., Durand, A., and J. Paugh, "Issues with Dual
+                   Stack IPv6 on by Default", Work in Progress,
+                   July 2004.
+
+Author's Address
+
+   Fernando Gont
+   Universidad Tecnologica Nacional / Facultad Regional Haedo
+   Evaristo Carriego 2644
+   Haedo, Provincia de Buenos Aires  1706
+   Argentina
+
+   Phone: +54 11 4650 8472
+   EMail: fernando@gont.com.ar
+   URI:   http://www.gont.com.ar
+
+
+
+
+
+
+
+
+
+
+
+Gont                         Informational                     [Page 13]
+