TCP's Reaction to Soft Errors
RFC 5461
|
Document |
Type |
|
RFC - Informational
(February 2009; No errata)
|
|
Author |
|
Fernando Gont
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
|
Reviews |
|
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 5461 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Lars Eggert
|
|
Send notices to |
|
david.borman@windriver.com, weddy@grc.nasa.gov
|
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
Show full document text