idnits 2.17.1 draft-ietf-tcpm-tcp-soft-errors-02.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 on line 583. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 601. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 607. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (October 9, 2006) is 6408 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-00 -- Obsolete informational reference (is this intentional?): RFC 816 (Obsoleted by RFC 7805) Summary: 5 errors (**), 0 flaws (~~), 2 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 October 9, 2006 5 Intended status: Informational 6 Expires: April 12, 2007 8 TCP's Reaction to Soft Errors 9 draft-ietf-tcpm-tcp-soft-errors-02.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 April 12, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document discusses the problem of long delays between connection 43 establishment attempts that may arise in a number of scenarios, 44 including one in which dual stack nodes that have IPv6 enabled by 45 default are deployed in IPv4 or mixed IPv4 and IPv6 environments. 46 Additionally, this document describes a modification to TCP's 47 reaction to soft errors that has been implemented in a variety of 48 TCP/IP stacks to help overcome this problem. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Error Handling in TCP . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Reaction to ICMP error messages that indicate hard 55 errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2. Reaction to ICMP error messages that indicate soft 57 errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Problems that may arise from TCP's reaction to soft errors . . 5 59 3.1. General Discussion . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Problems that may arise with Dual Stack IPv6 on by 61 Default . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. A workaround for long delays between 63 connection-establishment attempts . . . . . . . . . . . . . . 6 64 5. Possible drawbacks . . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. Non-deterministic transient network failures . . . . . . . 7 66 5.2. Deterministic transient network failures . . . . . . . . . 7 67 6. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 70 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 74 Appendix A. Other possible solutions . . . . . . . . . . . . . . 10 75 A.1. A more conservative approach . . . . . . . . . . . . . . . 10 76 A.2. Asynchronous Application Notification . . . . . . . . . . 11 77 A.3. Issuing several connection requests in parallel . . . . . 11 78 Appendix B. Change log (to be removed before publication of 79 the document as an RFC) . . . . . . . . . . . . . . . 12 80 B.1. Changes from draft-ietf-tcpm-tcp-soft-errors-01 . . . . . 12 81 B.2. Changes from draft-ietf-tcpm-tcp-soft-errors-00 . . . . . 12 82 B.3. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 12 83 B.4. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 12 84 B.5. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . 12 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 Intellectual Property and Copyright Statements . . . . . . . . . . 14 88 1. Introduction 90 The handling of network failures can be separated into two different 91 actions: fault isolation and fault recovery. Fault isolation 92 consists of the actions that hosts and routers take to determine that 93 there is a network failure. Fault recovery, on the other hand, 94 consists of the actions that hosts and routers perform to survive a 95 network failure.[RFC0816] 97 In the Internet architecture, the Internet Control Message Protocol 98 (ICMP) [RFC0792] is used to perform the fault isolation function, 99 that is, to report network error conditions to the hosts sending 100 datagrams over the network. 102 When a host is signalled of a network error, there is still the issue 103 of what to do to let communication survive, if possible, the network 104 failure. The fault recovery strategy may depend on the type of 105 network failure taking place, and the time the error condition is 106 detected. 108 This document analyzes the fault recovery strategy of TCP [RFC0793], 109 and the problems that may arise due to TCP's policy of reaction to 110 soft errors. Among others, it analyzes the problems that may arise 111 in scenarios where dual stack nodes that have IPv6 enabled by default 112 are deployed in IPv4 or mixed IPv4 and IPv6 environments. 114 Additionally, it documents a modification to TCP's policy of reaction 115 to ICMP messages indicating "soft errors", that has been implemented 116 in a variety of TCP/IP stacks to help overcome the problems discussed 117 in this document. 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 2. Error Handling in TCP 125 Network errors can be divided into soft and hard errors. Soft errors 126 are considered to be transient network failures, which are likely to 127 be solved in the near term. Hard errors, on the other hand, are 128 considered to reflect permanent network error conditions, which are 129 unlikely to be solved in the near future. 131 Therefore, it may make sense for the fault recovery action to be 132 different depending on the type of error being detected. 134 When there is a network failure that's not signalled to the sending 135 host, such as a gateway corrupting packets, TCP's fault recovery 136 action is to repeatedly retransmit the segment until either it gets 137 acknowledged, or the connection times out. In case the connection 138 times out before the segment is acknowledged, TCP won't be able to 139 provide more information than the timeout condition. 141 In case a host does receive an ICMP error message referring to an 142 ongoing TCP connection, the IP layer will pass this message up to 143 corresponding TCP instance to raise awareness of the network failure. 144 [RFC1122] 146 TCP's reaction to ICMP messages will depend on the type of error 147 being signalled. 149 2.1. Reaction to ICMP error messages that indicate hard errors 151 When receiving an ICMP error message that indicates a hard error 152 condition, TCP will simply abort the corresponding connection, 153 regardless of the state the connection is in. 155 The "Requirements for Internet Hosts -- Communication Layers" RFC 156 [RFC1122] states, in section 4.2.3.9, that TCP SHOULD abort 157 connections when receiving ICMP error messages that indicate hard 158 errors. This policy is based on the premise that, as hard errors 159 indicate network error conditions that won't change in the near term, 160 it will not be possible for TCP to recover from this type of network 161 failure. 163 2.2. Reaction to ICMP error messages that indicate soft errors 165 If an ICMP error message is received that indicates a soft error, TCP 166 will just record this information [Stevens], and repeatedly 167 retransmit the data until either they get acknowledged or the 168 connection times out. 170 The "Requirements for Internet Hosts -- Communication Layers" RFC 171 [RFC1122] states, in section 4.2.3.9, that TCP MUST NOT abort 172 connections when receiving ICMP error messages that indicate soft 173 errors. This policy is based on the premise that, as soft errors are 174 transient network failures that will hopefully be solved in the near 175 term, one of the retransmissions will succeed. 177 In case the connection timer expires, and an ICMP error message has 178 been received before the timeout, TCP will use this information to 179 provide the user with a more specific error message. [Stevens] 181 This handling of soft errors exploits the valuable feature of the 182 Internet that for many network failures, the network can be 183 dynamically reconstructed without any disruption of the endpoints. 185 3. Problems that may arise from TCP's reaction to soft errors 187 3.1. General Discussion 189 Even though TCP's fault recovery strategy in the presence of soft 190 errors allows for TCP connections to survive transient network 191 failures, there are scenarios in which this policy may cause 192 undesirable effects. 194 For example, consider the case in which an application on a local 195 host is trying to communicate with a destination whose name resolves 196 to several IP addresses. The application on the local host will try 197 to establish a connection with the destination host, cycling through 198 the list of IP addresses, until one succeeds [RFC1123]. Suppose that 199 some (but not all) of the addresses in the returned list are 200 permanently unreachable. If they are the first IP addresses in the 201 list, the application will usually try to use these addresses first. 203 As discussed in Section 2, this unreachability condition may or may 204 not be signalled to the sending host. If the local TCP is not 205 signalled concerning the error condition, there is very little that 206 can be done other than repeatedly retransmit the SYN segment, and 207 wait for the existing timeout mechanism in TCP, or an application 208 timeout, to be triggered. However, even if unreachability is 209 signalled by some intermediate router to the local TCP by means of an 210 ICMP error message, the local TCP will record the error message and 211 will still repeatedly retransmit the SYN segment until the connection 212 timer expires. The "Requirements For Internet Hosts -- Communication 213 Layers" RFC [RFC1122] states that this timer MUST be large enough to 214 provide retransmission of the SYN segment for at least 3 minutes. 215 This would mean that the application on the local host would spend 216 several minutes for each unreachable address it uses for trying to 217 establish a TCP connection. These long delays between connection 218 establishment attempts would be inappropriate for interactive 219 applications such as the web. [Shneiderman] [Thadani] 221 3.2. Problems that may arise with Dual Stack IPv6 on by Default 223 Another scenario in which this type of problem may occur is that 224 where dual stack nodes that have IPv6 enabled by default are deployed 225 in IPv4 or mixed IPv4 and IPv6 environments, and the IPv6 226 connectivity is non-existent [I-D.ietf-v6ops-v6onbydefault]. 228 As discussed in [I-D.ietf-v6ops-v6onbydefault], there are two 229 possible variants of this scenario, which differ in whether the lack 230 of connectivity is signalled to the sending node, or not. 232 In cases where packets sent to a destination are silently dropped and 233 no ICMPv6 [RFC4443] errors are generated, there is very little that 234 can be done other than waiting for the existing connection timeout 235 mechanism in TCP, or an application timeout, to be triggered. 237 In cases where a node has no default routers and Neighbor 238 Unreachability Detection (NUD) fails for destinations assumed to be 239 on-link, or where firewalls or other systems that enforce scope 240 boundaries send ICMPv6 errors, the sending node will be signalled of 241 the unreachability problem. However, as discussed in Section 2.2, 242 TCP implementations will not abort connections when receiving ICMP 243 error messages that indicate soft errors. 245 4. A workaround for long delays between connection-establishment 246 attempts 248 As discussed in Section 1, it may make sense for the fault recovery 249 action to depend not only on the type of error being reported, but 250 also on the state of the connection against which the error is 251 reported. For example, one could infer that when an error arrives in 252 response to opening a new connection, it is probably caused by 253 opening the connection improperly, rather than by a transient network 254 failure. [RFC0816] 256 A variety of TCP/IP stacks have modified TCP's reaction to soft 257 errors, to make it abort a connection in the SYN-SENT or the SYN- 258 RECEIVED state if it receives an ICMP "Destination Unreachable" 259 message that indicates a soft error about that connection. 261 The "Requirements for Internet Hosts -- Communication Layers" RFC 262 [RFC1122] states, in section 4.2.3.9., that the ICMP "Destination 263 Unreachable" messages that indicate soft errors are ICMP codes 0 264 (network unreachable), 1 (host unreachable), and 5 (source route 265 failed). Even though ICMPv6 didn't exist when [RFC1122] was written, 266 one could extrapolate the concept of soft errors to ICMPv6 Type 1 267 Codes 0 (no route to destination) and 3 (address unreachable). 269 It must be noted that this behaviour violates section 4.2.3.9 of 270 [RFC1122], since it states that as these Unreachable messages 271 indicate soft error conditions, TCP MUST NOT abort the corresponding 272 connection. 274 This workaround has been implemented, for example, in the Linux 275 kernel since version 2.0.0 (released in 1996) [Linux]. Appendix A.1 276 discusses a more conservative approach than the one introduced in 277 this section. 279 5. Possible drawbacks 281 The following subsections discuss some of the possible drawbacks 282 arising from the use of the modification to TCP's reaction to soft 283 errors described in Section 4. 285 5.1. Non-deterministic transient network failures 287 In case there's a transient network failure affecting all of the 288 addresses returned by the name-to-address translation function, all 289 destinations could be unreachable for some short period of time. In 290 such a scenario, the application could quickly cycle through all the 291 IP addresses in the list and return an error, when it could have let 292 TCP retry a destination a few seconds later, when the transient 293 problem could have disappeared. 295 However, it must be noted that non-interactive applications, such as 296 a Mail Transfer Agent (MTA), usually must implement application-layer 297 retry mechanisms, and thus are able to handle these scenarios 298 appropriately. For interactive applications, the user would likely 299 not be satisfied with a connection attempt that succeeds only after 300 several seconds, anyway. [Guynes] 302 5.2. Deterministic transient network failures 304 There are some scenarios in which transient network failures could be 305 deterministic. For example, consider the case in which upstream 306 network connectivity is triggered by network use. That is, network 307 connectivity is instantiated only on an "as needed" basis. In this 308 scenario, the connection triggering the upstream connectivity would 309 deterministically receive ICMP Destination Unreachables while the 310 upstream connectivity is being activated, and thus would be aborted. 312 As discussed in Section 5.1, applications usually implement 313 mechanisms to handle these scenarios appropriately. Also, connection 314 attempts are usually preceded by a UDP-based DNS name-to-address 315 lookup. Thus, unless the name-to-address mapping has been cached by 316 a local nameserver or resolver, it will be the DNS query that will 317 trigger the upstream network connectivity, and thus the corresponding 318 connection will not be aborted. 320 6. Future work 322 A Higher-Level API would be useful for isolating applications from 323 protocol details. The API could contain the intelligence required to 324 resolve the hostname, try each destination address, etc. One could 325 even argue that this document wouldn't have existed if application 326 programmers had been using a Higher-Level API. However, such an API 327 would need to be designed, standardized, implemented, deployed, and 328 documented even before application programmers start (if ever) to use 329 it. 331 7. Security Considerations 333 This document describes a modification to TCP's reaction to soft 334 errors that has been implemented in a variety of TCP/IP stacks. This 335 modification makes TCP abort a connection in the SYN-SENT or the SYN- 336 RECEIVED states when it receives an ICMP "Destination Unreachable" 337 message that indicates a "soft error" about that connection. While 338 this modification could be exploited to reset valid connections, it 339 must be noted that this behaviour is meant only for connections in 340 the SYN-SENT or the SYN-RECEIVED states, and thus the window of 341 exposure is very short. 343 In any case, it must be noted that the workaround discussed in this 344 document neither strengthens nor weakens TCP's resistance to attack. 345 An attacker wishing to reset ongoing TCP connections could perform 346 the attack by sending any of the ICMP error messages that indicate 347 "hard errors", not only for connections in the SYN-SENT or the SYN- 348 RECEIVED states, but for connections in any state. 350 A discussion of the use of ICMP to perform a variety of attacks 351 against TCP, and a number of counter-measures that eliminate or 352 greatly minimize the impact of these attacks can be found in 353 [I-D.ietf-tcpm-icmp-attacks]. 355 A discussion of the security issues arising from the use of ICMPv6 356 can be found in [RFC4443]. 358 8. Acknowledgements 360 The author wishes to thank Ron Bonica, Sally Floyd, Guillermo Gont, 361 Michael Kerrisk, Eddie Kohler, Mika Liljeberg, Pasi Sarolahti, Pekka 362 Savola, and Joe Touch, for contributing many valuable comments on 363 earlier versions of this document. 365 9. Contributors 367 Mika Liljeberg was the first to describe how their implementation 368 treated soft errors. Based on that, the solution discussed in 369 Section 4 was documented in [I-D.ietf-v6ops-v6onbydefault] by 370 Sebastien Roy, Alain Durand and James Paugh. 372 10. References 374 10.1. Normative References 376 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 377 RFC 792, September 1981. 379 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 380 RFC 793, September 1981. 382 [RFC1122] Braden, R., "Requirements for Internet Hosts - 383 Communication Layers", STD 3, RFC 1122, October 1989. 385 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 386 and Support", STD 3, RFC 1123, October 1989. 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, March 1997. 391 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 392 Message Protocol (ICMPv6) for the Internet Protocol 393 Version 6 (IPv6) Specification", RFC 4443, March 2006. 395 10.2. Informative References 397 [Guynes] Guynes, J., "Impact of System Response Time on State 398 Anxiety", Communications of the ACM , 1988. 400 [I-D.ietf-tcpm-icmp-attacks] 401 Gont, F., "ICMP attacks against TCP", 402 draft-ietf-tcpm-icmp-attacks-00 (work in progress), 403 February 2006. 405 [I-D.ietf-v6ops-v6onbydefault] 406 Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack 407 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 408 (work in progress), July 2004. 410 [Linux] The Linux Project, "http://www.kernel.org". 412 [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, 413 July 1982. 415 [Shneiderman] 416 Shneiderman, B., "Response Time and Display Rate in Human 417 Performance with Computers", ACM Computing Surveys , 1984. 419 [Stevens] "TCP/IP Illustrated, Volume 1: The Protocols", Addison- 420 Wesley , 1994. 422 [Stevens2] 423 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 424 The Implementation", Addison-Wesley , 1994. 426 [Thadani] Thadani, A., "Interactive User Productivity", IBM Systems 427 Journal No. 1, 1981. 429 Appendix A. Other possible solutions 431 A.1. A more conservative approach 433 A more conservative approach would be to abort a connection in the 434 SYN-SENT or SYN-RECEIVED states only after an ICMP Destination 435 Unreachable has been received a specified number of times, and the 436 SYN segment has been retransmitted more than some specified number of 437 times. 439 Two new parameters would have to be introduced to TCP, to be used 440 only during the connection-establishment phase: MAXSYNREXMIT and 441 MAXSOFTERROR. MAXSYNREXMIT would specify the number of times the SYN 442 segment would have to be retransmitted before a connection is 443 aborted. MAXSOFTERROR would specify the number of ICMP messages 444 indicating soft errors that would have to be received before a 445 connection is aborted. 447 Two additional variables would need to be introduced to store 448 additional state information during the connection-establishment 449 phase: "nsynrexmit" and "nsofterror". Both would be initialized to 450 zero. "nsynrexmit" would be incremented by one every time the SYN 451 segment is retransmitted. "nsofterror" would be incremented by one 452 every time an ICMP message that indicates a soft error is received. 454 A connection in the SYN-SENT or SYN-RECEIVED states would be aborted 455 if nsynrexmit was greater than MAXSYNREXMIT and "nsofterror" was 456 simultaneously greater than MAXSOFTERROR. 458 This approach would give the network more time to solve the 459 connectivity problem. However, it should be noted that depending on 460 the values chosen for the MAXSYNREXMIT and MAXSOFTERROR parameters, 461 this approach could still lead to long delays between connection 462 establishment attempts, thus not solving the problem. For example, 463 BSD systems abort connections in the SYN-SENT or the SYN-RECEIVED 464 state when a second ICMP error is received, and the SYN segment has 465 been retransmitted more than three times. They also set up a 466 "connection-establishment timer" that imposes an upper limit on the 467 time the connection establishment attempt has to succeed, which 468 expires after 75 seconds [Stevens2]. Even when this policy may be 469 better than the three-minutes timeout policy specified in [RFC1122], 470 it may still be inappropriate for handling the potential problems 471 described in this document. This more conservative approach has been 472 implemented in BSD systems since, at least, 1994 [Stevens2]. 474 A.2. Asynchronous Application Notification 476 In section 4.2.4.1, [RFC1122] states that there MUST be a mechanism 477 for reporting soft TCP error conditions to the application. Such a 478 mechanism (assuming one is implemented) could be used by applications 479 to cycle through the destination IP addresses. However, this 480 approach would increase application complexity, and would take a long 481 time to kick in, as it would require all existing applications to be 482 modified. 484 A.3. Issuing several connection requests in parallel 486 For those scenarios in which a domain name maps to several IP 487 addresses, several connection requests could be issued in parallel, 488 each one to a different destination IP address. The host would then 489 use the first connection attempt to succeed, eliminating the 490 potential delay in establishing a connection with the destination 491 host. However, this would mean that every attempt to connect to a 492 multihomed host would imply sending several SYN segments, making it 493 hard for network operators to distinguish valid connection attempts 494 from those performing Denial of Service (DoS) attacks. 496 An alternative approach would be as follows. A host would issue a 497 connection request to the first IP address in the list returned by 498 the name-to-address mapping function. If this connection request 499 didn't succeed in some time, a connection request to the second IP 500 address in the list would be issued in parallel. If none of these 501 connection requests succeeded in some time, and there were still more 502 addresses left in the list, they would be tried in the same way. 503 While this approach would, in principle, avoid the problems of the 504 previous approach, it might be hard to define the time interval to 505 wait before issuing each parallel connection request. A short time 506 interval would lead to the problems caused by the previous approach, 507 while a long time interval would likely still lead to long delays in 508 establishing a connection with the destination host. 510 In any case, it must be noted that both approaches have the same 511 drawbacks as the solution described in Appendix A.2: they would 512 increase application complexity, and would take too long to begin to 513 be used by applications. 515 Appendix B. Change log (to be removed before publication of the 516 document as an RFC) 518 B.1. Changes from draft-ietf-tcpm-tcp-soft-errors-01 520 o Addressed feedback posted by Sally Floyd (remove sentence in 521 Section 2.1 regarding processing of RST segments) 523 B.2. Changes from draft-ietf-tcpm-tcp-soft-errors-00 525 o Miscellaneous editorial changes 527 B.3. Changes from draft-gont-tcpm-tcp-soft-errors-02 529 o Draft resubmitted as draft-ietf. 531 o Miscellaneous editorial changes 533 B.4. Changes from draft-gont-tcpm-tcp-soft-errors-01 535 o Changed wording to describe the mechanism, rather than proposing 536 it 538 o Miscellaneous editorial changes 540 B.5. Changes from draft-gont-tcpm-tcp-soft-errors-00 542 o Added reference to the Linux implementation in Section 4 544 o Added Section 5 546 o Added Section 6 548 o Added Appendix A.1 550 o Moved section "Asynchronous Application Notification" to 551 Appendix A.2 553 o Added a Appendix A.3 555 o Miscellaneous editorial changes 557 Author's Address 559 Fernando Gont 560 Universidad Tecnologica Nacional/Facultad Regional Haedo 561 Evaristo Carriego 2644 562 Haedo, Provincia de Buenos Aires 1706 563 Argentina 565 Phone: +54 11 4650 8472 566 Email: fernando@gont.com.ar 567 URI: http://www.gont.com.ar 569 Full Copyright Statement 571 Copyright (C) The Internet Society (2006). 573 This document is subject to the rights, licenses and restrictions 574 contained in BCP 78, and except as set forth therein, the authors 575 retain all their rights. 577 This document and the information contained herein are provided on an 578 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 579 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 580 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 581 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 582 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 583 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 585 Intellectual Property 587 The IETF takes no position regarding the validity or scope of any 588 Intellectual Property Rights or other rights that might be claimed to 589 pertain to the implementation or use of the technology described in 590 this document or the extent to which any license under such rights 591 might or might not be available; nor does it represent that it has 592 made any independent effort to identify any such rights. Information 593 on the procedures with respect to rights in RFC documents can be 594 found in BCP 78 and BCP 79. 596 Copies of IPR disclosures made to the IETF Secretariat and any 597 assurances of licenses to be made available, or the result of an 598 attempt made to obtain a general license or permission for the use of 599 such proprietary rights by implementers or users of this 600 specification can be obtained from the IETF on-line IPR repository at 601 http://www.ietf.org/ipr. 603 The IETF invites any interested party to bring to its attention any 604 copyrights, patents or patent applications, or other proprietary 605 rights that may cover technology that may be required to implement 606 this standard. Please address the information to the IETF at 607 ietf-ipr@ietf.org. 609 Acknowledgment 611 Funding for the RFC Editor function is provided by the IETF 612 Administrative Support Activity (IASA).