idnits 2.17.1 draft-ietf-tcpm-tcp-soft-errors-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 701. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 26, 2007) is 5959 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Guynes' is defined on line 522, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-08) exists of draft-ietf-behave-tcp-07 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-02 -- Obsolete informational reference (is this intentional?): RFC 816 (Obsoleted by RFC 7805) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor F. Gont 3 Extensions (tcpm) UTN/FRH 4 Internet-Draft December 26, 2007 5 Intended status: Informational 6 Expires: June 28, 2008 8 TCP's Reaction to Soft Errors 9 draft-ietf-tcpm-tcp-soft-errors-07.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 28, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes a non-standard, but widely implemented, 43 modification to TCP's handling of ICMP soft error messages, that 44 rejects pending connection-requests when those error messages are 45 received. This behavior reduces the likelihood of long delays 46 between connection establishment attempts that may arise in a number 47 of scenarios, including one in which dual stack nodes that have IPv6 48 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 49 environments. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Error Handling in TCP . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Reaction to ICMP error messages that indicate hard 56 errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Reaction to ICMP error messages that indicate soft 58 errors . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Problems that may arise from TCP's reaction to soft errors . . 5 60 3.1. General Discussion . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Problems that may arise with Dual Stack IPv6 on by 62 Default . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Deployed workarounds for long delays between 64 connection-establishment attempts . . . . . . . . . . . . . . 7 65 4.1. Context-sensitive ICMP/TCP interaction . . . . . . . . . . 7 66 4.2. Context-sensitive ICMP/TCP interaction with repeated 67 confirmation . . . . . . . . . . . . . . . . . . . . . . . 8 68 5. Possible drawbacks of changing ICMP semantics . . . . . . . . 9 69 5.1. Non-deterministic transient network failures . . . . . . . 9 70 5.2. Deterministic transient network failures . . . . . . . . . 9 71 5.3. Non-compliant Network Address Translators (NATs) . . . . . 10 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 74 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 78 Appendix A. Change log (to be removed before publication of 79 the document as an RFC) . . . . . . . . . . . . . . . 12 80 A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-06 . . . . . 13 81 A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-05 . . . . . 13 82 A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-04 . . . . . 13 83 A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-03 . . . . . 13 84 A.5. Changes from draft-ietf-tcpm-tcp-soft-errors-02 . . . . . 13 85 A.6. Changes from draft-ietf-tcpm-tcp-soft-errors-01 . . . . . 14 86 A.7. Changes from draft-ietf-tcpm-tcp-soft-errors-00 . . . . . 14 87 A.8. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 14 88 A.9. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 14 89 A.10. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . 14 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 Intellectual Property and Copyright Statements . . . . . . . . . . 16 93 1. Introduction 95 The handling of network failures can be separated into two different 96 actions: fault isolation and fault recovery. Fault isolation 97 consists of the actions that hosts and routers take to determine that 98 there is a network failure. Fault recovery, on the other hand, 99 consists of the actions that hosts and routers perform in an attempt 100 to survive a network failure [RFC0816]. 102 In the Internet architecture, the Internet Control Message Protocol 103 (ICMP) [RFC0792] is one fault isolation technique to report network 104 error conditions to the hosts sending datagrams over the network. 106 When a host is notified of a network error, its network stack will 107 attempt to continue communications, if possible, in the presence of 108 the network failure. The fault recovery strategy may depend on the 109 type of network failure taking place, and the time the error 110 condition is detected. 112 This document analyzes the fault recovery strategy of TCP [RFC0793], 113 and the problems that may arise due to TCP's reaction to ICMP soft 114 errors. It analyzes the problems that may arise when a host tries to 115 establish a TCP connection with a multihomed host for which some of 116 its addresses are unreachable. Additionally, it analyzes the 117 problems that may arise in the specific scenario where dual stack 118 nodes that have IPv6 enabled by default are deployed in IPv4 or mixed 119 IPv4 and IPv6 environments. 121 Finally, we document a modification to TCP's reaction to ICMP 122 messages indicating soft errors during connection startup, that has 123 been implemented in a variety of TCP/IP stacks to help overcome the 124 problems outlined below. We stress that this modification runs 125 contrary to the standard behavior and this document unambiguously 126 does not change the standard reaction. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 2. Error Handling in TCP 134 Network errors can be divided into soft and hard errors. Soft errors 135 are considered to be transient network failures, which are likely to 136 be solved in the near term. Hard errors, on the other hand, are 137 considered to reflect network error conditions that are unlikely to 138 be solved in the near future. 140 The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9., that 141 the ICMP messages that indicate soft errors are ICMP "Destination 142 Unreachable" codes 0 (network unreachable), 1 (host unreachable), and 143 5 (source route failed), ICMP "Time Exceeded" codes 0 (time to live 144 exceeded in transit) and 1 (fragment reassembly time exceeded), and 145 ICMP "Parameter Problem". Even though ICMPv6 did not exist when 146 [RFC1122] was written, one could extrapolate the concept of soft 147 errors to ICMPv6 "Destination Unreachable" codes 0 (no route to 148 destination) and 3 (address unreachable), ICMPv6 "Time Exceeded" 149 codes 0 (Hop limit exceeded in transit) and 1 (Fragment reassembly 150 time exceeded), and ICMPv6 "Parameter Problem" codes 0 (Erroneous 151 header field encountered), 1 (Unrecognized Next Header type 152 encountered) and 2 (Unrecognized IPv6 option encountered) [RFC4443]. 154 +----------------------------------+--------------------------------+ 155 | ICMP | ICMPv6 | 156 +----------------------------------+--------------------------------+ 157 | Destination Unreachable (codes | Destination Unreachable (codes | 158 | 0, 1, and 5) | 0 and 3) | 159 +----------------------------------+--------------------------------+ 160 | Time Exceeded (codes 0 and 1) | Time exceeded (codes 0 and 1) | 161 +----------------------------------+--------------------------------+ 162 | Parameter Problem | Parameter Problem (codes 0, 1, | 163 | | and 2) | 164 +----------------------------------+--------------------------------+ 166 Table 1: Extrapolating the concept of soft errors to ICMPv6 168 When there is a network failure that is not signaled to the sending 169 host, such as a gateway corrupting packets, TCP's fault recovery 170 action is to repeatedly retransmit the segment until either it gets 171 acknowledged, or the connection times out. 173 In the case that a host does receive an ICMP error message referring 174 to an ongoing TCP connection, the IP layer will pass this message up 175 to the corresponding TCP instance to raise awareness of the network 176 failure [RFC1122]. TCP's reaction to ICMP messages will depend on 177 the type of error being signaled. 179 2.1. Reaction to ICMP error messages that indicate hard errors 181 When receiving an ICMP error message that indicates a hard error 182 condition, TCP will simply abort the corresponding connection, 183 regardless of the connection state. 185 The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that 186 TCP SHOULD abort connections when receiving ICMP error messages that 187 indicate hard errors. This policy is based on the premise that, as 188 hard errors indicate network error conditions that will not change in 189 the near term, it will not be possible for TCP to usefully recover 190 from this type of network failure. 192 2.2. Reaction to ICMP error messages that indicate soft errors 194 If an ICMP error message is received that indicates a soft error, TCP 195 will repeatedly retransmit the segment until it either gets 196 acknowledged or the connection times out. In addition, the TCP 197 sender may record the information for possible later use [Stevens] 198 (pp. 317-319). 200 The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that 201 TCP MUST NOT abort connections when receiving ICMP error messages 202 that indicate soft errors. This policy is based on the premise that, 203 as soft errors are transient network failures that will hopefully be 204 solved in the near term, one of the retransmissions will succeed. 206 When the connection timer expires, and an ICMP soft error message has 207 been received before the timeout, TCP can use this information to 208 provide the user with a more specific error message [Stevens] (pp. 209 317-319). 211 This reaction to soft errors exploits the valuable feature of the 212 Internet that for many network failures, the network can be 213 dynamically reconstructed without any disruption of the endpoints. 215 3. Problems that may arise from TCP's reaction to soft errors 217 3.1. General Discussion 219 Even though TCP's fault recovery strategy in the presence of soft 220 errors allows for TCP connections to survive transient network 221 failures, there are scenarios in which this policy may cause 222 undesirable effects. 224 For example, consider a scenario in which an application on a local 225 host is trying to communicate with a destination whose name resolves 226 to several IP addresses. The application on the local host will try 227 to establish a connection with the destination host, usually cycling 228 through the list of IP addresses, until one succeeds [RFC1123]. 229 Suppose that some (but not all) of the addresses in the returned list 230 are permanently unreachable. If such a permanently unreachable 231 address is the first in the list, the application will likely try to 232 use the permanently unreachable address first and block waiting for a 233 timeout before trying an alternate address. 235 As discussed in Section 2, this unreachability condition may or may 236 not be signaled to the sending host. If the local TCP is not 237 signaled concerning the error condition, there is very little that 238 can be done other than repeatedly retransmit the SYN segment, and 239 wait for the existing timeout mechanism in TCP, or an application 240 timeout, to be triggered. However, even if unreachability is 241 signaled by some intermediate router to the local TCP by means of an 242 ICMP soft error message, the local TCP will still repeatedly 243 retransmit the SYN segment until the connection timer expires (in the 244 hopes that the error is transient). The Host Requirements RFC 245 [RFC1122] states that this timer MUST be large enough to provide 246 retransmission of the SYN segment for at least 3 minutes. This would 247 mean that the application on the local host would spend several 248 minutes for each unreachable address it uses for trying to establish 249 the TCP connection. These long delays between connection 250 establishment attempts would be inappropriate for many interactive 251 applications such as the web. [Shneiderman] and [Thadani] offer some 252 insight into interactive systems (e.g., how the response time affects 253 the usability of an application). This highlights that there is no 254 one definition of a "transient error" and that the level of 255 persistence in the face of failure represents a tradeoff. 257 It is worth noting that while most applications try the addresses 258 returned by the name-to-address function in serial, this is certainly 259 not the only possible approach. For example, applications could try 260 multiple addresses in parallel until one succeeds, possibly avoiding 261 the problem of long delays between connection establishment attempts 262 described in this document. 264 3.2. Problems that may arise with Dual Stack IPv6 on by Default 266 A particular scenario in which the above sketched type of problem may 267 occur regularly is that where dual stack nodes that have IPv6 enabled 268 by default are deployed in IPv4 or mixed IPv4 and IPv6 environments, 269 and the IPv6 connectivity is non-existent 270 [I-D.ietf-v6ops-v6onbydefault]. 272 As discussed in [I-D.ietf-v6ops-v6onbydefault], there are two 273 possible variants of this scenario, which differ in whether the lack 274 of connectivity is signaled to the sending node, or not. 276 In those scenarios in which packets sent to a destination are 277 silently dropped and no ICMPv6 [RFC4443] errors are generated, there 278 is little that can be done other than waiting for the existing 279 connection timeout mechanism in TCP, or an application timeout, to be 280 triggered. 282 In scenarios where a node has no default routers and Neighbor 283 Unreachability Detection (NUD) [RFC4861] fails for destinations 284 assumed to be on-link, or where firewalls or other systems that 285 enforce scope boundaries send ICMPv6 errors, the sending node will be 286 signaled of the unreachability problem. However, as discussed in 287 Section 2.2, standard TCP implementations will not abort connections 288 when receiving ICMP error messages that indicate soft errors. 290 4. Deployed workarounds for long delays between connection- 291 establishment attempts 293 The following subsections describe a number of workarounds for the 294 problem of long delays between connection-establishment attempts that 295 have been implemented in a variety of TCP/IP stacks. We note that 296 treating soft errors as hard errors during connection establishment, 297 while widespread, is not part of standard TCP behavior and this 298 document does not change that state of affairs. The TCPM WG 299 consensus was to document this widespread implementation of 300 nonstandard TCP behavior, but to not change the TCP standard. 302 4.1. Context-sensitive ICMP/TCP interaction 304 As discussed in Section 1, it may make sense for the fault recovery 305 action to depend not only on the type of error being reported, but 306 also on the state of the connection against which the error is 307 reported. For example, one could infer that when an error arrives in 308 response to opening a new connection, it is probably caused by 309 opening the connection improperly, rather than by a transient network 310 failure [RFC0816]. 312 A number of TCP implementations have modified their reaction to soft 313 errors, to treat the errors as hard errors in the SYN-SENT or SYN- 314 RECEIVED states. For example, this workaround has been implemented, 315 for example, in the Linux kernel since version 2.0.0 (released in 316 1996) [Linux]. However, it should be noted that this change violates 317 section 4.2.3.9 of [RFC1122], which states that these Unreachable 318 messages indicate soft error conditions and therefore TCP MUST NOT 319 abort the corresponding connection. 321 [RFC3168] states that a host that receives a RST in response to the 322 transmission of an ECN-setup SYN packet MAY resend a SYN with CWR and 323 ECE cleared. This is meant to deal with faulty middle-boxes that 324 reject connections when a SYN segment has the ECE and CWR bits set. 325 Given that this section describes a modification that processes ICMP 326 error messages as hard errors when they are received for a connection 327 in any of the non-synchronized states, systems implementing this 328 behavior could resend the SYN segment with the ECE and CWR bits 329 cleared when an ICMP error message is received in response to a SYN 330 segment that had these bits set. 332 Section 4.2 discusses a more conservative approach than that sketched 333 above, that is implemented in FreeBSD. 335 4.2. Context-sensitive ICMP/TCP interaction with repeated confirmation 337 A more conservative approach than simply treating soft errors as hard 338 errors as described above would be to abort a connection in the SYN- 339 SENT or SYN-RECEIVED states only after an ICMP Destination 340 Unreachable has been received a specified number of times, and the 341 SYN segment has been retransmitted more than some specified number of 342 times. 344 Two new parameters would have to be introduced to TCP, to be used 345 only during the connection-establishment phase: MAXSYNREXMIT and 346 MAXSOFTERROR. MAXSYNREXMIT would specify the number of times the SYN 347 segment would have to be retransmitted before a connection is 348 aborted. MAXSOFTERROR would specify the number of ICMP messages 349 indicating soft errors that would have to be received before a 350 connection is aborted. 352 Two additional state variables would need to be introduced to store 353 additional state information during the connection-establishment 354 phase: "nsynrexmit" and "nsofterror". Both would be initialized to 355 zero when a connection attempt is initiated, with "nsynrexmit" being 356 incremented by one every time the SYN segment is retransmitted and 357 "nsofterror" being incremented by one every time an ICMP message that 358 indicates a soft error is received. 360 A connection in the SYN-SENT or SYN-RECEIVED states would be aborted 361 if "nsynrexmit" was greater than MAXSYNREXMIT and "nsofterror" was 362 simultaneously greater than MAXSOFTERROR. 364 This approach would give the network more time to solve the 365 connectivity problem than simply aborting a connection attempt upon 366 reception of the first soft error. However, it should be noted that 367 depending on the values chosen for the MAXSYNREXMIT and MAXSOFTERROR 368 parameters, this approach could still lead to long delays between 369 connection establishment attempts, thus not solving the problem. For 370 example, BSD systems abort connections in the SYN-SENT or the SYN- 371 RECEIVED state when a second ICMP error is received, and the SYN 372 segment has been retransmitted more than three times. They also set 373 up a "connection-establishment timer" that imposes an upper limit on 374 the time the connection establishment attempt has to succeed, which 375 expires after 75 seconds [Stevens2] (pp. 828-829). Even when this 376 policy may be better than the three-minutes timeout policy specified 377 in [RFC1122], it may still be inappropriate for handling the 378 potential problems described in this document. This more 379 conservative approach has been implemented in BSD systems for more 380 than ten years [Stevens2]. 382 We also note that the approach given in this section is a generalized 383 version of the approach sketched in the previous section. In 384 particular, with MAXSOFTERROR set to 1 and MAXSYNREXMIT set to zero 385 the schemes are identical. 387 5. Possible drawbacks of changing ICMP semantics 389 The following subsections discuss some of the possible drawbacks 390 arising from the use of the non-standard modifications to TCP's 391 reaction to soft errors described in Section 4.1 and Section 4.2. 393 5.1. Non-deterministic transient network failures 395 In scenarios where a transient network failure affects all of the 396 addresses returned by the name-to-address translation function, all 397 destinations could be unreachable for some short period of time. For 398 example, a mobile system consisting of a cell and a repeater may pass 399 through a tunnel, leading to a loss of connectivity at the repeater, 400 with the repeater sending ICMP soft errors back to the cell. In such 401 scenarios, the application could quickly cycle through all the IP 402 addresses in the list and return an error, when it could have let TCP 403 retry a destination a few seconds later, when the transient problem 404 could have disappeared. In this case, the modifications described 405 here make TCP less robust than a standards-compliant implementation. 407 Additionally, in many cases a domain name maps to a single IP 408 address. In such a case, it might be better to try that address 409 persistently according to normal TCP rules, instead of just aborting 410 the pending connection upon receipt of an ICMP soft error. 412 5.2. Deterministic transient network failures 414 There are some scenarios in which transient network failures could be 415 deterministic. For example, consider a scenario in which upstream 416 network connectivity is triggered by network use. That is, network 417 connectivity is instantiated only on an "as needed" basis. In this 418 scenario, the connection triggering the upstream connectivity could 419 deterministically receive ICMP Destination Unreachables while the 420 upstream connectivity is being activated, and thus would be aborted. 421 Again, in this case, the modifications described here make TCP less 422 robust than a standards-compliant implementation. 424 5.3. Non-compliant Network Address Translators (NATs) 426 Some NATs respond to an unsolicited inbound SYN segment with an ICMP 427 soft error message. If the system sending the unsolicited SYN 428 segment implements the workaround described in this document, it will 429 abort the connection upon receipt of the ICMP error message, thus 430 probably preventing TCP's simultaneous open through the NAT from 431 succeeding. However, it must be stressed that those NATs described 432 in this section are not BEHAVE-compliant, and therefore should 433 implement REQ-4 of [I-D.ietf-behave-tcp] instead. 435 6. Security Considerations 437 This document describes a non-standard modification to TCP's reaction 438 to soft errors that has been implemented in a variety of TCP 439 implementations. This modification makes TCP abort a connection in 440 the SYN-SENT or the SYN-RECEIVED states when it receives an ICMP 441 "Destination Unreachable" message that indicates a soft error. 442 Therefore, the modification could be exploited to reset valid 443 connections during the connection-establishment phase. 445 The non-standard workaround described in this document makes TCP more 446 vulnerable to attack, even if only slightly. However, we note that 447 an attacker wishing to reset ongoing TCP connections could send any 448 of the ICMP hard error messages in any connection state. 450 Generally, TCP backs off its retransmission timer each time it 451 retransmits the SYN segment for the same connection. If a TCP 452 implements the modification described in this document, that is, 453 tries the next address in the list upon receipt of an ICMP error 454 message, it might end up injecting more packets into the network than 455 if it had simply retried the same address a number of times. 456 However, compliant TCP implementations might already incur into this 457 behaviour (e.g., as a result of cycling through the list of IP 458 addressses in response to RST segments) as there are currently no 459 recommendations on methods for limiting the rate at which SYN 460 segments are sent for connecting to a specific destination. 462 A discussion of the use of ICMP to perform a variety of attacks 463 against TCP, and a number of counter-measures that minimize the 464 impact of these attacks can be found in [I-D.ietf-tcpm-icmp-attacks]. 466 A discussion of the security issues arising from the use of ICMPv6 467 can be found in [RFC4443]. 469 7. Acknowledgements 471 The author wishes to thank Mark Allman, Ron Bonica, Ted Faber, Gorry 472 Fairhurst, Sally Floyd, Tomohiro Fujisaki, Guillermo Gont, Saikat 473 Guha, Alfred Hoenes, Michael Kerrisk, Eddie Kohler, Mika Liljeberg, 474 Arifumi Matsumoto, Carlos Pignataro, Pasi Sarolahti, Pekka Savola, 475 Pyda Srisuresh, and Joe Touch, for contributing many valuable 476 comments on earlier versions of this document. 478 The author wishes to express deep and heartfelt gratitude to Jorge 479 Oscar Gont and Nelida Garcia, for their precious motivation and 480 guidance. 482 8. Contributors 484 Mika Liljeberg was the first to describe how their implementation 485 treated soft errors. Based on that, the solution discussed in 486 Section 4.1 was documented in [I-D.ietf-v6ops-v6onbydefault] by 487 Sebastien Roy, Alain Durand and James Paugh. 489 9. References 491 9.1. Normative References 493 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 494 RFC 792, September 1981. 496 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 497 RFC 793, September 1981. 499 [RFC1122] Braden, R., "Requirements for Internet Hosts - 500 Communication Layers", STD 3, RFC 1122, October 1989. 502 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 503 and Support", STD 3, RFC 1123, October 1989. 505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 506 Requirement Levels", BCP 14, RFC 2119, March 1997. 508 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 509 of Explicit Congestion Notification (ECN) to IP", 510 RFC 3168, September 2001. 512 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 513 Message Protocol (ICMPv6) for the Internet Protocol 514 Version 6 (IPv6) Specification", RFC 4443, March 2006. 516 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 517 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 518 September 2007. 520 9.2. Informative References 522 [Guynes] Guynes, J., "Impact of System Response Time on State 523 Anxiety", Communications of the ACM , 1988. 525 [I-D.ietf-behave-tcp] 526 Guha, S., "NAT Behavioral Requirements for TCP", 527 draft-ietf-behave-tcp-07 (work in progress), April 2007. 529 [I-D.ietf-tcpm-icmp-attacks] 530 Gont, F., "ICMP attacks against TCP", 531 draft-ietf-tcpm-icmp-attacks-02 (work in progress), 532 May 2007. 534 [I-D.ietf-v6ops-v6onbydefault] 535 Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack 536 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 537 (work in progress), July 2004. 539 [Linux] The Linux Project, "http://www.kernel.org". 541 [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, 542 July 1982. 544 [Shneiderman] 545 Shneiderman, B., "Response Time and Display Rate in Human 546 Performance with Computers", ACM Computing Surveys , 1984. 548 [Stevens] Stevens, W., "TCP/IP Illustrated, Volume 1: The 549 Protocols", Addison-Wesley , 1994. 551 [Stevens2] 552 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 553 The Implementation", Addison-Wesley , 1994. 555 [Thadani] Thadani, A., "Interactive User Productivity", IBM Systems 556 Journal No. 1, 1981. 558 Appendix A. Change log (to be removed before publication of the 559 document as an RFC) 561 A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-06 563 o Added a paragraph (in Section 4.1) about the interaction of the 564 described modification with ECN-enabled connections 566 o Added a paragraph (in Section 6) about the possible scenario in 567 which a host injects SYN segments into the network at a high rate, 568 in response to ICMP soft errors. 570 o Miscellaneous editorial changes 572 A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-05 574 o Miscellaneous edits, clarifications, and reorganization of both 575 workarounds into a single top-level section, as suggested by Pasi 576 Sarolahti. 578 o Added note on non-compliant NATs, as suggested by Ted Faber and 579 Saikat Guha 581 o Miscellaneous edits suggested by Gorry Fairhurst 583 o Added a table to clarify how to extrapolate the concept of ICMPv4 584 "soft errors" to ICMPv6 (as suggested by Arifumi Matsumoto and 585 Gorry Fairhurst). 587 o Miscellaneous edits, clarification on alternative approach by 588 sending connection requests in parallel, example of mobile system 589 (for non-deterministic errors), and note on the possible impact of 590 the workarounds on TCP's robusteness (as suggested by Joe Touch) 592 A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-04 594 o Addresses feedback sent by Carlos Pignataro (adds missing error 595 codes in Section 2, and fixes a number of typos/writeos). 597 A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-03 599 o Addresses feedback sent by Ted Faber and Gorry Fairhurst 600 (miscellaneous editorial changes). 602 A.5. Changes from draft-ietf-tcpm-tcp-soft-errors-02 604 o Moved appendix on FreeBSD's approach to the body of the draft. 606 o Removed rest of the appendix, as suggested by Ron Bonica and Mark 607 Allman. 609 o Reworded some parts of the document to make the text more neutral. 611 o Miscellaneous editorial changes. 613 A.6. Changes from draft-ietf-tcpm-tcp-soft-errors-01 615 o Addressed feedback posted by Sally Floyd (remove sentence in 616 Section 2.1 regarding processing of RST segments) 618 A.7. Changes from draft-ietf-tcpm-tcp-soft-errors-00 620 o Miscellaneous editorial changes 622 A.8. Changes from draft-gont-tcpm-tcp-soft-errors-02 624 o Draft resubmitted as draft-ietf. 626 o Miscellaneous editorial changes 628 A.9. Changes from draft-gont-tcpm-tcp-soft-errors-01 630 o Changed wording to describe the mechanism, rather than proposing 631 it 633 o Miscellaneous editorial changes 635 A.10. Changes from draft-gont-tcpm-tcp-soft-errors-00 637 o Added reference to the Linux implementation in Section 4.1 639 o Added Section 5 641 o Added section on Higher-Level API 643 o Added Section 4.2 645 o Moved section "Asynchronous Application Notification" to Appendix 647 o Added section on parallel connection requests 649 o Miscellaneous editorial changes 651 Author's Address 653 Fernando Gont 654 Universidad Tecnologica Nacional / Facultad Regional Haedo 655 Evaristo Carriego 2644 656 Haedo, Provincia de Buenos Aires 1706 657 Argentina 659 Phone: +54 11 4650 8472 660 Email: fernando@gont.com.ar 661 URI: http://www.gont.com.ar 663 Full Copyright Statement 665 Copyright (C) The IETF Trust (2007). 667 This document is subject to the rights, licenses and restrictions 668 contained in BCP 78, and except as set forth therein, the authors 669 retain all their rights. 671 This document and the information contained herein are provided on an 672 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 673 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 674 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 675 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 676 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 677 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 679 Intellectual Property 681 The IETF takes no position regarding the validity or scope of any 682 Intellectual Property Rights or other rights that might be claimed to 683 pertain to the implementation or use of the technology described in 684 this document or the extent to which any license under such rights 685 might or might not be available; nor does it represent that it has 686 made any independent effort to identify any such rights. Information 687 on the procedures with respect to rights in RFC documents can be 688 found in BCP 78 and BCP 79. 690 Copies of IPR disclosures made to the IETF Secretariat and any 691 assurances of licenses to be made available, or the result of an 692 attempt made to obtain a general license or permission for the use of 693 such proprietary rights by implementers or users of this 694 specification can be obtained from the IETF on-line IPR repository at 695 http://www.ietf.org/ipr. 697 The IETF invites any interested party to bring to its attention any 698 copyrights, patents or patent applications, or other proprietary 699 rights that may cover technology that may be required to implement 700 this standard. Please address the information to the IETF at 701 ietf-ipr@ietf.org. 703 Acknowledgment 705 Funding for the RFC Editor function is provided by the IETF 706 Administrative Support Activity (IASA).