draft-ietf-tcpm-tcp-soft-errors-04.txt   draft-ietf-tcpm-tcp-soft-errors-05.txt 
TCP Maintenance and Minor F. Gont TCP Maintenance and Minor F. Gont
Extensions (tcpm) UTN/FRH Extensions (tcpm) UTN/FRH
Intended status: Informational Intended status: Informational
Expires: September 19, 2007 Expires: October 4, 2007
TCP's Reaction to Soft Errors TCP's Reaction to Soft Errors
draft-ietf-tcpm-tcp-soft-errors-04.txt draft-ietf-tcpm-tcp-soft-errors-05.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 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 September 19, 2007. This Internet-Draft will expire on October 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes a non-standard, but widely implemented, This document describes a non-standard, but widely implemented,
modification to TCP's handling of ICMP soft error messages that modification to TCP's handling of ICMP soft error messages received
rejects connections experiencing those errors immediately. This in any of the non-synchronized states, that rejects connections
behavior reduces the likelihood of long delays between connection experiencing those errors immediately. This behavior reduces the
establishment attempts that may arise in a number of scenarios, likelihood of long delays between connection establishment attempts
including one in which dual stack nodes that have IPv6 enabled by that may arise in a number of scenarios, including one in which dual
default are deployed in IPv4 or mixed IPv4 and IPv6 environments. stack nodes that have IPv6 enabled by default are deployed in IPv4 or
mixed IPv4 and IPv6 environments.
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 ICMP error messages that indicate hard 2.1. Reaction to ICMP error messages that indicate hard
errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4 errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Reaction to ICMP error messages that indicate soft 2.2. Reaction to ICMP error messages that indicate soft
errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. A workaround for long delays between 4. A workaround for long delays between
connection-establishment attempts . . . . . . . . . . . . . . 6 connection-establishment attempts . . . . . . . . . . . . . . 6
5. A more conservative approach . . . . . . . . . . . . . . . . . 7 5. A more conservative approach . . . . . . . . . . . . . . . . . 7
6. Possible drawbacks . . . . . . . . . . . . . . . . . . . . . . 8 6. Possible drawbacks . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Non-deterministic transient network failures . . . . . . . 8 6.1. Non-deterministic transient network failures . . . . . . . 8
6.2. Deterministic transient network failures . . . . . . . . . 8 6.2. Deterministic transient network failures . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . 10
Appendix A. Change log (to be removed before publication of Appendix A. Change log (to be removed before publication of
the document as an RFC) . . . . . . . . . . . . . . . 10 the document as an RFC) . . . . . . . . . . . . . . . 10
A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-03 . . . . . 10 A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-04 . . . . . 10
A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-02 . . . . . 10 A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-03 . . . . . 11
A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-01 . . . . . 11 A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-02 . . . . . 11
A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-00 . . . . . 11 A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-01 . . . . . 11
A.5. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 11 A.5. Changes from draft-ietf-tcpm-tcp-soft-errors-00 . . . . . 11
A.6. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 11 A.6. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 11
A.7. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . 11 A.7. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 A.8. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 13
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 actions: fault isolation and fault recovery. Fault isolation
consists of the actions that hosts and routers take to determine that consists of the actions that hosts and routers take to determine that
there is a network failure. Fault recovery, on the other hand, there is a network failure. Fault recovery, on the other hand,
consists of the actions that hosts and routers perform in an attempt consists of the actions that hosts and routers perform in an attempt
to survive a network failure [RFC0816]. to survive a network failure [RFC0816].
skipping to change at page 3, line 45 skipping to change at page 3, line 45
does not change the standard reaction. does not change the standard reaction.
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 are likely to 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 network error conditions that are unlikely to considered to reflect network error conditions that are unlikely to
be solved in the near future. be solved in the near future.
The Host Requirements RFC [RFC1122] states, in section 4.2.3.9., that The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9., that
the ICMP "Destination Unreachable" messages that indicate soft errors the ICMP messages that indicate soft errors are ICMP "Destination
are ICMP codes 0 (network unreachable), 1 (host unreachable), and 5 Unreachable" codes 0 (network unreachable), 1 (host unreachable), and
(source route failed). Even though ICMPv6 didn't exist when 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 didn't exist when
[RFC1122] was written, one could extrapolate the concept of soft [RFC1122] was written, one could extrapolate the concept of soft
errors to ICMPv6 Type 1 Codes 0 (no route to destination) and 3 errors to ICMPv6 "Destination Unreachable" codes 0 (no route to
(address unreachable). 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).
When there is a network failure that's not signaled to the sending When there is a network failure that's not signaled 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
acknowledged, or the connection times out. acknowledged, or the connection times out.
In the case that a host does receive an ICMP error message referring 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 an ongoing TCP connection, the IP layer will pass this message up
to corresponding TCP instance to raise awareness of the network to corresponding TCP instance to raise awareness of the network
failure [RFC1122]. failure [RFC1122].
TCP's reaction to ICMP messages will depend on the type of error TCP's reaction to ICMP messages will depend on the type of error
being signaled. being signaled.
2.1. Reaction to ICMP error messages that indicate hard errors 2.1. Reaction to ICMP error messages that indicate hard errors
When receiving an ICMP error message that indicates a hard error When receiving an ICMP error message that indicates a hard error
condition, TCP will simply abort the corresponding connection, condition, TCP will simply abort the corresponding connection,
regardless of the connection state. regardless of the connection state.
The Host Requirements RFC [RFC1122] states, in section 4.2.3.9, that The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that
TCP SHOULD abort connections when receiving ICMP error messages that TCP SHOULD abort connections when receiving ICMP error messages that
indicate hard errors. This policy is based on the premise that, as indicate hard errors. This policy is based on the premise that, as
hard errors indicate network error conditions that won't change in hard errors indicate network error conditions that won't change in
the near term, it will not be possible for TCP to usefully recover the near term, it will not be possible for TCP to usefully recover
from this type of network failure. from this type of network failure.
2.2. Reaction to ICMP error messages that indicate soft errors 2.2. Reaction to ICMP error messages that indicate soft errors
If an ICMP error message is received that indicates a soft error, TCP If an ICMP error message is received that indicates a soft error, TCP
will repeatedly retransmit the packet until it either gets will repeatedly retransmit the segment until it either gets
acknowledged or the connection times out. In addition, the TCP acknowledged or the connection times out. In addition, the TCP
sender may record the information for possible later use [Stevens] sender may record the information for possible later use [Stevens]
(pp. 317-319). (pp. 317-319).
The Host Requirements RFC [RFC1122] states, in section 4.2.3.9, that The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that
TCP MUST NOT abort connections when receiving ICMP error messages TCP MUST NOT abort connections when receiving ICMP error messages
that indicate soft errors. This policy is based on the premise that, that indicate soft errors. This policy is based on the premise that,
as soft errors are transient network failures that will hopefully be as soft errors are transient network failures that will hopefully be
solved in the near term, one of the retransmissions will succeed. solved in the near term, one of the retransmissions will succeed.
When the connection timer expires, and an ICMP soft error message has When the connection timer expires, and an ICMP soft error message has
been received before the timeout, TCP can use this information to been received before the timeout, TCP can use this information to
provide the user with a more specific error message [Stevens] (pp. provide the user with a more specific error message [Stevens] (pp.
317-319). 317-319).
skipping to change at page 5, line 42 skipping to change at page 5, line 49
ICMP soft error message, the local TCP will still repeatedly ICMP soft error message, the local TCP will still repeatedly
retransmit the SYN segment until the connection timer expires (in the retransmit the SYN segment until the connection timer expires (in the
hopes that the error is transient). The Host Requirements RFC hopes that the error is transient). The Host Requirements RFC
[RFC1122] states that this timer MUST be large enough to provide [RFC1122] states that this timer MUST be large enough to provide
retransmission of the SYN segment for at least 3 minutes. This would retransmission of the SYN segment for at least 3 minutes. This would
mean that the application on the local host would spend several mean that the application on the local host would spend several
minutes for each unreachable address it uses for trying to establish minutes for each unreachable address it uses for trying to establish
a TCP connection. These long delays between connection establishment a TCP connection. These long delays between connection establishment
attempts would be inappropriate for many interactive applications attempts would be inappropriate for many interactive applications
such as the web. ([Shneiderman] and [Thadani] offer some insight such as the web. ([Shneiderman] and [Thadani] offer some insight
into the interactive systems.) This highlights that there is no one into the interactive systems). This highlights that there is no one
definition of a "transient error" and that the level of persistence definition of a "transient error" and that the level of persistence
in the face of failure represents a tradeoff. in the face of failure represents a tradeoff.
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
A particular scenario in which the above sketched type of problem may A particular scenario in which the above sketched type of problem may
occur regularly is that where dual stack nodes that have IPv6 enabled occur regularly is that where dual stack nodes that have IPv6 enabled
by default are deployed in IPv4 or mixed IPv4 and IPv6 environments, by default are deployed in IPv4 or mixed IPv4 and IPv6 environments,
and the IPv6 connectivity is non-existent and the IPv6 connectivity is non-existent
[I-D.ietf-v6ops-v6onbydefault]. [I-D.ietf-v6ops-v6onbydefault].
skipping to change at page 8, line 30 skipping to change at page 8, line 40
IP addresses in the list and return an error, when it could have let IP addresses in the list and return an error, when it could have let
TCP retry a destination a few seconds later, when the transient TCP retry a destination a few seconds later, when the transient
problem could have disappeared. problem could have disappeared.
6.2. Deterministic transient network failures 6.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 a scenario in which upstream deterministic. For example, consider a scenario in which upstream
network connectivity is triggered by network use. That is, network network connectivity is triggered by network use. That is, network
connectivity is instantiated only on an "as needed" basis. In this connectivity is instantiated only on an "as needed" basis. In this
scenario, the connection triggering the upstream connectivity would scenario, the connection triggering the upstream connectivity could
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.
7. Security Considerations 7. Security Considerations
This document describes a non-standard modification to TCP's reaction This document describes a non-standard modification to TCP's reaction
to soft errors that has been implemented in a variety of TCP to soft errors that has been implemented in a variety of TCP
implementations. This modification makes TCP abort a connection in implementations. This modification makes TCP abort a connection in
the SYN-SENT or the SYN-RECEIVED states when it receives an ICMP the SYN-SENT or the SYN-RECEIVED states when it receives an ICMP
"Destination Unreachable" message that indicates a soft error. "Destination Unreachable" message that indicates a soft error.
skipping to change at page 9, line 14 skipping to change at page 9, line 24
against TCP, and a number of counter-measures that minimize the against TCP, and a number of counter-measures that minimize the
impact of these attacks can be found in [I-D.ietf-tcpm-icmp-attacks]. impact of these attacks can be found in [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 [RFC4443]. can be found in [RFC4443].
8. Acknowledgements 8. Acknowledgements
The author wishes to thank Mark Allman, Ron Bonica, Ted Faber, Gorry The author wishes to thank Mark Allman, Ron Bonica, Ted Faber, Gorry
Fairhurst, Sally Floyd, Guillermo Gont, Michael Kerrisk, Eddie Fairhurst, Sally Floyd, Guillermo Gont, Michael Kerrisk, Eddie
Kohler, Mika Liljeberg, Pasi Sarolahti, Pekka Savola, and Joe Touch, Kohler, Mika Liljeberg, Carlos Pignataro, Pasi Sarolahti, Pekka
for contributing many valuable comments on earlier versions of this Savola, and Joe Touch, for contributing many valuable comments on
document. earlier versions of this document.
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 10, line 37 skipping to change at page 10, line 47
[Stevens2] [Stevens2]
Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
The Implementation", Addison-Wesley , 1994. The Implementation", Addison-Wesley , 1994.
[Thadani] Thadani, A., "Interactive User Productivity", IBM Systems [Thadani] Thadani, A., "Interactive User Productivity", IBM Systems
Journal No. 1, 1981. Journal No. 1, 1981.
Appendix A. Change log (to be removed before publication of the Appendix A. Change log (to be removed before publication of the
document as an RFC) document as an RFC)
A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-03 A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-04
o Addresses feedback sent by Carlos Pignataro (adds missing error
codes in Section 2, and fixes a number of typos/writeos).
A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-03
o Addresses feedback sent by Ted Faber and Gorry Fairhurst o Addresses feedback sent by Ted Faber and Gorry Fairhurst
(miscellaneous editorial changes). (miscellaneous editorial changes).
A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-02 A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-02
o Moved appendix on FreeBSD's approach to the body of the draft. o Moved appendix on FreeBSD's approach to the body of the draft.
o Removed rest of the appendix, as suggested by Ron Bonica and Mark o Removed rest of the appendix, as suggested by Ron Bonica and Mark
Allman. Allman.
o Reworded some parts of the document to make the text more neutral. o Reworded some parts of the document to make the text more neutral.
o Miscellaneous editorial changes. o Miscellaneous editorial changes.
A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-01 A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-01
o Addressed feedback posted by Sally Floyd (remove sentence in o Addressed feedback posted by Sally Floyd (remove sentence in
Section 2.1 regarding processing of RST segments) Section 2.1 regarding processing of RST segments)
A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-00 A.5. Changes from draft-ietf-tcpm-tcp-soft-errors-00
o Miscellaneous editorial changes o Miscellaneous editorial changes
A.5. Changes from draft-gont-tcpm-tcp-soft-errors-02 A.6. 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
A.6. Changes from draft-gont-tcpm-tcp-soft-errors-01 A.7. 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
A.7. Changes from draft-gont-tcpm-tcp-soft-errors-00 A.8. 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 6 o Added Section 6
o Added section on Higher-Level API o Added section on Higher-Level API
o Added Section 5 o Added Section 5
o Moved section "Asynchronous Application Notification" to Appendix o Moved section "Asynchronous Application Notification" to Appendix
o Added section on parallel connection requests o Added section on parallel connection requests
o Miscellaneous editorial changes o Miscellaneous editorial changes
 End of changes. 23 change blocks. 
41 lines changed or deleted 52 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/