draft-ietf-tcpm-tcp-soft-errors-01.txt   draft-ietf-tcpm-tcp-soft-errors-02.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: February 9, 2007 Expires: April 12, 2007
TCP's Reaction to Soft Errors TCP's Reaction to Soft Errors
draft-ietf-tcpm-tcp-soft-errors-01.txt draft-ietf-tcpm-tcp-soft-errors-02.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 February 9, 2007. This Internet-Draft will expire on April 12, 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 one 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, this document describes a modification to TCP's Additionally, this document describes a modification to TCP's
reaction to soft errors that has been implemented in a variety of reaction to soft errors that has been implemented in a variety of
TCP/IP stacks to 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 ICMP error messages that indicate hard
2.2. Reaction to Soft Errors . . . . . . . . . . . . . . . . . 4 errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Reaction to ICMP error messages that indicate 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
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-ietf-tcpm-tcp-soft-errors-00 . . . . . 12 B.1. Changes from draft-ietf-tcpm-tcp-soft-errors-01 . . . . . 12
B.2. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 12 B.2. Changes from draft-ietf-tcpm-tcp-soft-errors-00 . . . . . 12
B.3. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 12 B.3. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 12
B.4. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . 12 B.4. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 12
B.5. 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 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 to survive a consists of the actions that hosts and routers perform to survive a
skipping to change at page 4, line 18 skipping to change at page 4, line 18
provide more information than the timeout condition. provide more information than the timeout condition.
In case a host does receive an ICMP error message referring to an In case a host does receive an ICMP error message referring to an
ongoing TCP connection, the IP layer will pass this message up to ongoing TCP connection, the IP layer will pass this message up to
corresponding TCP instance to raise awareness of the network failure. corresponding TCP instance to raise awareness of the network failure.
[RFC1122] [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 signalled. being signalled.
2.1. Reaction to Hard Errors 2.1. Reaction to ICMP error messages that indicate hard errors
When receiving a segment with the RST bit set, or an ICMP error When receiving an ICMP error message that indicates a hard error
message indicating a hard error condition, TCP will simply abort the condition, TCP will simply abort the corresponding connection,
corresponding connection, regardless of the state the connection is regardless of the state the connection is in.
in.
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 TCP SHOULD abort [RFC1122] states, in section 4.2.3.9, that TCP SHOULD abort
connections when receiving ICMP error messages that indicate hard connections when receiving ICMP error messages that indicate hard
errors. This policy is based on the premise that, as hard errors errors. This policy is based on the premise that, as hard errors
indicate network error conditions that won't change in the near term, indicate network error conditions that won't change in the near term,
it will not be possible for TCP to recover from this type of network it will not be possible for TCP to recover from this type of network
failure. failure.
2.2. Reaction to 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 just record this information [Stevens], and repeatedly will just record this information [Stevens], and repeatedly
retransmit the data until either they get acknowledged or the retransmit the data until either they get acknowledged or the
connection times out. connection times out.
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 TCP MUST NOT abort [RFC1122] states, in section 4.2.3.9, that TCP MUST NOT abort
connections when receiving ICMP error messages that indicate soft connections when receiving ICMP error messages that indicate soft
errors. This policy is based on the premise that, as soft errors are errors. This policy is based on the premise that, as soft errors are
skipping to change at page 8, line 45 skipping to change at page 8, line 41
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.ietf-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 [RFC4443]. can be found in [RFC4443].
8. Acknowledgements 8. Acknowledgements
The author wishes to thank Ron Bonica, Guillermo Gont, Michael The author wishes to thank Ron Bonica, Sally Floyd, Guillermo Gont,
Kerrisk, Eddie Kohler, Mika Liljeberg, Pasi Sarolahti, Pekka Savola, Michael Kerrisk, Eddie Kohler, Mika Liljeberg, Pasi Sarolahti, Pekka
and Joe Touch, for contributing many valuable comments. Savola, and Joe Touch, for contributing many valuable comments on
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 12, line 15 skipping to change at page 12, line 13
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-ietf-tcpm-tcp-soft-errors-00 B.1. Changes from draft-ietf-tcpm-tcp-soft-errors-01
o Addressed feedback posted by Sally Floyd (remove sentence in
Section 2.1 regarding processing of RST segments)
B.2. Changes from draft-ietf-tcpm-tcp-soft-errors-00
o Miscellaneous editorial changes o Miscellaneous editorial changes
B.2. Changes from draft-gont-tcpm-tcp-soft-errors-02 B.3. 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.3. Changes from draft-gont-tcpm-tcp-soft-errors-01 B.4. 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.4. Changes from draft-gont-tcpm-tcp-soft-errors-00 B.5. 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
 End of changes. 15 change blocks. 
24 lines changed or deleted 32 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/