idnits 2.17.1 draft-gont-tcpm-tcp-soft-errors-01.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 567. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 557. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 24, 2004) is 7114 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (ref. '2') (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-v6onbydefault (ref. '6') ** Obsolete normative reference: RFC 2463 (ref. '7') (Obsoleted by RFC 4443) -- Obsolete informational reference (is this intentional?): RFC 816 (ref. '8') (Obsoleted by RFC 7805) == Outdated reference: A later version (-05) exists of draft-gont-tcpm-icmp-attacks-01 Summary: 9 errors (**), 0 flaws (~~), 3 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 24, 2004 5 Expires: April 24, 2005 7 TCP's Reaction to Soft Errors 8 draft-gont-tcpm-tcp-soft-errors-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 24, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 This document discusses problems that may arise due to TCP's reaction 44 to soft errors. In particular, it discusses the problem of long 45 delays in connection establishment attempts that may arise in a 46 number of scenarios, including that in which dual stack nodes that 47 have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and 48 IPv6 environments. This document discusses this potential problem, 49 and proposes to change TCP's reaction to soft errors to work around 50 this problem. It does not try to specify whether IPv6 should be 51 enabled by default or not. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Error Handling in TCP . . . . . . . . . . . . . . . . . . . . 3 57 2.1 Reaction to Hard Errors . . . . . . . . . . . . . . . . . 4 58 2.2 Reaction to Soft Errors . . . . . . . . . . . . . . . . . 4 59 3. Problems arising from TCP's reaction to soft errors . . . . . 4 60 3.1 General Discussion . . . . . . . . . . . . . . . . . . . . 4 61 3.2 Problems that arise with Dual Stack IPv6 on by Default . . 5 62 4. Changing TCP's reaction to soft errors . . . . . . . . . . . . 6 63 5. Possible drawbacks . . . . . . . . . . . . . . . . . . . . . . 6 64 5.1 Non-deterministic transient network failures . . . . . . . 6 65 5.2 Deterministic transient network failures . . . . . . . . . 7 66 6. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 69 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 72 10.2 Informative References . . . . . . . . . . . . . . . . . . . 9 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 74 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 B. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . . . 12 79 Intellectual Property and Copyright Statements . . . . . . . . 13 81 1. Introduction 83 The handling of network failures can be separated into two different 84 actions: fault isolation and fault recovery. Fault isolation is the 85 actions that hosts and routers take to determine that there is some 86 network failure. Fault recovery, on the other hand, is the actions 87 that hosts and routers will perform to isolate and survive a network 88 failure.[8] 90 In the Internet architecture, the Internet Control Message Protocol 91 (ICMP) [1] is used to perform the fault isolation function, that is, 92 to report network error conditions to the hosts sending datagrams 93 over the network. 95 When a host is signalled of a network error, there is still the issue 96 of what to do to let communication survive, if possible, the network 97 failure. The fault recovery strategy may depend on the type of 98 network failure taking place, and the time the error condition is 99 detected. 101 This document analyzes the fault recovery policy of TCP [2], and the 102 problems that may arise due to TCP's policy of reaction to soft 103 errors. In particular, it analyzes the problems that may arise in 104 scenarios where dual stack nodes that have IPv6 enabled by default 105 are deployed in IPv4 or mixed IPv4 and IPv6 environments. 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [3]. 111 2. Error Handling in TCP 113 Network errors can be divided into soft and hard errors. Soft errors 114 are considered to be transient network failures, which will hopefully 115 be solved in the near term. Hard errors, on the other hand, are 116 considered to reflect permanent network conditions, which are 117 unlikely to be solved in the near future. 119 Therefore, it may make sense for the fault recovery action to be 120 different depending on the type of error being detected. 122 When there is a network failure that's not signalled to the sending 123 host, such as a gateway corrupting packets, TCP's fault recovery 124 action is to repeatedly retransmit the segment until either it gets 125 acknowledged, or the connection times out. In case the connection 126 times out before the segment is acknowledged, TCP won't be able to 127 provide more information than the timeout condition. 129 In case a host does receive an ICMP error message about a current TCP 130 connection, the IP layer will pass this message up to TCP to raise 131 awareness of the network failure. [4] 133 TCP's reaction will depend on the type of error being signalled. 135 2.1 Reaction to Hard Errors 137 When receiving a segment with the RST bit set, or an ICMP error 138 message indicating a hard error condition, TCP will simply abort the 139 corresponding connection, regardless of the state the connection is 140 in. 142 The "Requirements for Internet Hosts -- Communication Layers" RFC [4] 143 states, in section 4.2.3.9, that TCP SHOULD abort connections when 144 receiving ICMP error messages that indicate hard errors. This policy 145 is based on the premise that, as hard errors indicate network 146 conditions that won't change in the near term, it will not be 147 possible for TCP to recover from this type of network failure. 149 2.2 Reaction to Soft Errors 151 The "Requirements for Internet Hosts -- Communication Layers" RFC [4] 152 states, in section 4.2.3.9, that TCP MUST NOT abort connections when 153 receiving ICMP error messages that indicate soft errors. 155 If an ICMP error message is received that indicates a soft error, TCP 156 will just record this information [9], and repeatedly retransmit the 157 data until either they get acknowledged or the connection times out. 158 This policy is based on the premise that, as soft errors are 159 transient network failures that will hopefully be solved in the near 160 term, one of the retransmissions will succeed. 162 In case the connection timer expires, and an ICMP error message had 163 been received before the timeout, TCP will use this information to 164 provide the user with a more specific error message. [9] 166 This handling of soft errors exploits the valuable feature of the 167 Internet that for many network failures, the network can be 168 dynamically reconstructed without any disruption of the endpoints. 170 3. Problems arising from TCP's reaction to soft errors 172 3.1 General Discussion 174 Even though TCP's fault recovery strategy in the presence of soft 175 errors allows for TCP connections to survive transient network 176 failures, there are scenarios in which this policy may cause 177 undesirable effects. 179 For example, consider the case where an application on a local host 180 is trying to communicate with a destination whose name resolves to 181 several IP addresses. The application on the local host will try to 182 establish a connection with the destination host, cycling through the 183 list of IP addresses, until one succeeds [5]. Suppose that some (but 184 not all) of the addresses in the returned list are permanently 185 unreachable. If they are the first IP addresses in the list, the 186 application will usually try to use these addresses first. 188 As discussed in Section 2, this unreachability condition may or may 189 not be signalled to the sending host. If the local TCP is not 190 signalled of the error condition, it will repeatedly retransmit the 191 SYN segment, until the connection times out. If unreachability is 192 signalled by some intermediate router to the local TCP by means of an 193 ICMP error message, the local TCP will just record the error message 194 and will still repeatedly retransmit the SYN segment until the 195 connection timer expires. The "Requirements For Internet Hosts -- 196 Communication Layers" RFC [4] states that this timer MUST be large 197 enough to provide retransmission of the SYN segment for at least 3 198 minutes. This would mean that the application on the local host 199 would spend several minutes for each unreachable address it tries to 200 use for a connection attempt. These long delays in connection 201 establishment attempts would be inappropriate for interactive 202 applications such as the web. [10][11] 204 3.2 Problems that arise with Dual Stack IPv6 on by Default 206 A scenario in which this type of problem may occur is that where dual 207 stack nodes that have IPv6 enabled by default are deployed in IPv4 or 208 mixed IPv4 and IPv6 environments, and the IPv6 connectivity is 209 non-existent [6]. 211 As discussed in [6], there are two possible variants of this 212 scenario, which differ in whether the lack of connectivity is 213 signalled to the sending node, or not. 215 In cases where packets sent to a destination are silently dropped and 216 no ICMPv6 [7] errors are generated, there is very little that can be 217 done other than waiting for the existing connection timeout mechanism 218 in TCP, or an aplication timeout, to be triggered. 220 In cases where a node has no default routers and Neighbor 221 Unreachability Detection (NUD) fails for destinations assumed to be 222 on-link, or where firewalls or other systems that enforce scope 223 boundaries send ICMPv6 errors, the sending node will be signalled of 224 the unreachability problem. As discussed in Section 2.2, TCP 225 implementations will not abort connections when receiving ICMP error 226 messages that indicate soft errors. However, it would be desirable 227 for TCP implementations to use this information to avoid the long 228 delays in connection attempts described in Section 3.1. 230 4. Changing TCP's reaction to soft errors 232 As discussed in Section 1, it may make sense for the fault recovery 233 action to depend not only on the type of error being reported, but 234 also on the time the error is reported. For example, one could infer 235 that when an error arrives in response to opening a new connection, 236 it is probably caused by opening the connection improperly, rather 237 than by a transient network failure. [8] 239 This document proposes to change TCP's reaction to soft errors as a 240 workaround to the potential problems described in Section 3.1. 242 TCP SHOULD abort a connection in the SYN-SENT or the SYN-RECEIVED 243 state if it receives an ICMP "Destination Unreachable" message that 244 indicates a soft error about that connection. 246 The "Requirements for Internet Hosts -- Communication Layers" RFC [4] 247 states, in section 4.2.3.9., that the ICMP "Destination Unreachable" 248 messages that indicate soft errors are ICMP codes 0 (network 249 unreachable), 1 (host unreachable), and 5 (source route failed). 250 Even though ICMPv6 didn't exist when [4] was written, one could 251 extrapolate the concept of soft errors to ICMPv6 Type 1 Codes 0 (no 252 route to destination) and 3 (address unreachable). 254 This workaround has been implemented in the Linux kernel since 255 version 2.0.0 (released in 1996), and has therefore been tested in 256 real-world scenarios. 258 A system-wide toggle that allows system administrators to disable the 259 proposed fix MAY be provided. By default, this toggle SHOULD enable 260 the proposed fix. 262 Appendix A.1 discusses a more conservative approach than the one 263 introduced in this section. 265 5. Possible drawbacks 267 The following subsections discuss some of the possible drawbacks 268 arising from the use of the proposed fix. 270 5.1 Non-deterministic transient network failures 272 In case there's a transient network failure affecting all of the 273 addresses returned by the name-to-address translation function, all 274 destinations could be unreachable for some short period of time. In 275 such a scenario, the application could quickly cycle through all the 276 IP addresses in the list and return an error, when it could have let 277 TCP retry a destination a few seconds later when the transient 278 problem could have been mitigated. 280 However, it must be noted that non-interactive applications, such as 281 a Mail Transfer Agent (MTA), usually must implement application-layer 282 retry mechanisms, and thus are able to handle these scenarios 283 appropriately. 285 For interactive applications, the user would likely not be satisfied 286 with a connection attempt that succeeds only after several seconds, 287 anyway. [12] 289 5.2 Deterministic transient network failures 291 There are some scenarios in which transient network failures could be 292 deterministic. For example, consider the case in which upstream 293 network connectivity is triggered by network use. In this scenario, 294 the connection triggering the upstream connectivity would 295 deterministically receive ICMP Destination Unreachables while the 296 upstream connectivity is being activated, and thus would be aborted. 298 As discussed in Section 5.1, applications usually implement mechanims 299 to handle these scenarios appropriately. Also, connection attempts 300 are usually preceded by a UDP-based DNS name-to-address lookup. 301 Thus, unless the name-to-address mapping has been cached by a local 302 nameserver or resolver, it will be the DNS query that will trigger 303 the upstream network connectivity, and thus the corresponding 304 connection will not be aborted. 306 In any case, the system-wide toggle described in section Section 4 307 could be used in these specific scenarios to override the default 308 behaviour so that connections in the SYN-SENT or SYN-RECEIVED states 309 are not aborted upon receipt of ICMP error messages that indicate 310 "soft errors". 312 6. Future work 314 A Higher-Level API would be useful for isolating applications from 315 protocol details. The API could contain the intelligence required to 316 resolve the hostname, try each destination address, etc. One could 317 even argue that this document wouldn't have existed if application 318 programmers had been using a Higher-Level API. However, the time 319 frame in which this Higher Level API would kick in would be quite 320 different than that of the proposed work-around: such an API would 321 need to be designed, standardized, implemented, deployed, and 322 documented even before application programmers start (if ever) to use 323 it. Therefore, while it is an interesting long-term solution, it is 324 inappropriate for providing a short term fix. 326 7. Security Considerations 328 This document proposes to make TCP abort a connection in the SYN-SENT 329 or the SYN-RECEIVED states when it receives an ICMP "Destination 330 Unreachable" message that indicates a "soft error" about that 331 connection. While this could be used to reset valid connections, it 332 must be noted that this behaviour is specified only for connections 333 in the SYN-SENT or the SYN-RECEIVED states, and thus the window of 334 exposure is very short. Furthermore, in order for this type to 335 succeed, the attacker should be able to guess the four-tuple that 336 identifies the target TCP connection. A discussion on this issue can 337 be found in [13]. 339 In any case, it must be noted that the workaround proposed in this 340 document neither strengthens nor weakens TCP's resistance to attack. 341 An attacker wishing to reset valid connections could perform the 342 attack by sending any of the ICMP error messages that indicate "hard 343 errors", not only for connections in the SYN-SENT or the SYN-RECEIVED 344 states, but for connections in any state. 346 A discussion of the use of ICMP to perform a variety of attacks 347 against TCP, and some proposed counter-measures that eliminate or 348 greatly minimize the impact of these attacks can be found in [14]. 350 A discussion of the security issues arising from the use of ICMPv6 351 can be found in [7]. 353 8. Acknowledgements 355 The author wishes to thank Michael Kerrisk, Eddie Kohler, Mika 356 Liljeberg, Pasi Sarolahti, and Pekka Savola, for contributing many 357 valuable comments. 359 9. Contributors 361 Mika Liljeberg was the first to describe how their implementation 362 treated soft errors. Based on that, the solution discussed in 363 Section 4 was documented in [6] by Sebastien Roy, Alain Durand and 364 James Paugh. 366 10. References 367 10.1 Normative References 369 [1] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, 370 September 1981. 372 [2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 373 September 1981. 375 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 376 Levels", BCP 14, RFC 2119, March 1997. 378 [4] Braden, R., "Requirements for Internet Hosts - Communication 379 Layers", STD 3, RFC 1122, October 1989. 381 [5] Braden, R., "Requirements for Internet Hosts - Application and 382 Support", STD 3, RFC 1123, October 1989. 384 [6] Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack IPv6 385 on by Default", draft-ietf-v6ops-v6onbydefault-03 (work in 386 progress), July 2004. 388 [7] Conta, A. and S. Deering, "Internet Control Message Protocol 389 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 390 Specification", RFC 2463, December 1998. 392 10.2 Informative References 394 [8] Clark, D., "Fault isolation and recovery", RFC 816, July 1982. 396 [9] "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley , 397 1994. 399 [10] Shneiderman, B., "Response Time and Display Rate in Human 400 Performance with Computers", ACM Computing Surveys , 1984. 402 [11] Thadani, A., "Interactive User Productivity", IBM Systems 403 Journal No. 1, 1981. 405 [12] Guynes, J., "Impact of System Response Time on State Anxiety", 406 Communications of the ACM , 1988. 408 [13] Watson, P., "Slipping in the Window: TCP Reset Attacks", 2004 409 CanSecWest Conference , 2004. 411 [14] Gont, F., "ICMP attacks against TCP", 412 draft-gont-tcpm-icmp-attacks-01 (work in progress), September 413 2004. 415 [15] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: The 416 Implementation", Addison-Wesley , 1994. 418 Author's Address 420 Fernando Gont 421 Universidad Tecnologica Nacional 422 Evaristo Carriego 2644 423 Haedo, Provincia de Buenos Aires 1706 424 Argentina 426 Phone: +54 11 4650 8472 427 EMail: fernando@gont.com.ar 428 URI: http://www.gont.com.ar 430 Appendix A. Other possible solutions 432 A.1 A more conservative approach 434 A more conservative approach would be to abort a connection in the 435 SYN-SENT or SYN-RECEIVED states only after a ICMP Destination 436 Unreacheable has been received a specified number of times, and the 437 SYN segment has been retransmitted more than some specified number of 438 times. 440 Two new parameters would have to be introduced to TCP, to be used 441 only during the connection-establishment phase: MAXSYNREXMIT and 442 MAXSOFTERROR. MAXSYNREXMIT would speficy the number of times the SYN 443 segment would have to be retransmitted before a connection is 444 aborted. MAXSOFTERROR would specify the number of ICMP messages 445 indicating soft errors that would have to be received before a 446 connection is aborted. 448 Two additional variables would be introduced in implementations to 449 store additional state information during the 450 connection-establishment phase: "nsynrexmit" and "nsofterror". Both 451 would be initialized to zero. "nsynrexmit" would be incremented by 452 one every time the SYN segment is retransmitted. "nsofterror" would 453 be incremented by one every time an ICMP message that indicates a 454 soft error is received. 456 A connection in the SYN-SENT or SYN-RECEIVED states would be aborted 457 if nsynrexmit was greater than MAXSYNREXMIT and "nsofterror" was 458 simultaneously greater than MAXSOFTERROR. 460 This approach would give the network more time to solve the 461 connectivity problem. However, it should be noted that depending on 462 the values chosen for the MAXSYNREXMIT and MAXSOFTERROR parameters, 463 this approach could still lead to long delays in connection 464 establishment attempts. For example, BSD systems abort connections 465 in the SYN-SENT or the SYN-RECEIVED state when a second ICMP error is 466 received, and the SYN segment has been retransmitted more than three 467 times. They also set up a "connection-establishment timer" that 468 imposes an upper limit on the time the connection establishment 469 attempt has to succeed, which expires after 75 seconds [15]. Even 470 when this policy is better than the three-minutes timeout policy 471 specified in [4], it is still inappropriate for handling the 472 potential problems described in this document. This more 473 conservative approach has been implemented in BSD systems since, at 474 least, 1994 [15]. 476 A.2 Asynchronous Application Notification 478 In section 4.2.4.1, [4] states that there MUST be a mechanism for 479 reporting soft TCP error conditions to the application. Such a 480 mechanism (assuming one is implemented) could be used by applications 481 to cycle through the destination IP addresses. However, this 482 approach would increase application complexity, and would take a long 483 time to kick in, as it requires every existing applications to be 484 modified. Thus, it is inappropriate for providing a short term fix. 486 A.3 Issuing several connection requests in parallel 488 For those scenarios in which a domain name maps to several IP 489 addresses, several connection requests could be issued in parallel, 490 each one to a different destination IP address. The host would then 491 use the first connection attempt to succeed, eliminating the 492 potential delay in establishing a connection with the destination 493 host. However, this would mean that every attempt to connect to a 494 multihomed host would imply sending several SYN segments, making it 495 hard for network operators to distinguish valid connection attempts 496 from those performing Denial of Service (DoS) attacks. 498 An alternative approach would be as follows. A host would issue a 499 connection request to the first IP address in the list returned by 500 the name-to-address mapping function. If this connection request 501 doesn't succeed in some time, a connection request to the second IP 502 address in the list would be issued in parallel. If none of these 503 connection requests succeeds in some time, and there are still more 504 addresses left in the list, they would be tried in the same way. 505 While this approach would, in principle, avoid the problems of the 506 previous approach, it might be hard to define the time interval to 507 wait before issuing each parallel connection. A short time interval 508 would lead to the problems caused by the previous approach, while a 509 long time interval would likely still lead to long delays in 510 establishing a connection with the destination host. 512 In any case, it must be noted that both approachs have the same 513 drawbacks as the solution described in Appendix A.2: they would 514 increase application complexity, and would take too long to begin to 515 be used by applications. Thus, they would be inappropriate for 516 providing a short-term fix. 518 Appendix B. Changes from draft-gont-tcpm-tcp-soft-errors-00 520 o Added reference to the Linux implementation in Section 4 522 o Added Section 5 524 o Added Section 6 526 o Added Appendix A.1 528 o Moved section "Asynchronous Application Notification" to Appendix 529 A.2 531 o Added a Appendix A.3 533 o Miscellaneous editorial changes 535 Intellectual Property Statement 537 The IETF takes no position regarding the validity or scope of any 538 Intellectual Property Rights or other rights that might be claimed to 539 pertain to the implementation or use of the technology described in 540 this document or the extent to which any license under such rights 541 might or might not be available; nor does it represent that it has 542 made any independent effort to identify any such rights. Information 543 on the procedures with respect to rights in RFC documents can be 544 found in BCP 78 and BCP 79. 546 Copies of IPR disclosures made to the IETF Secretariat and any 547 assurances of licenses to be made available, or the result of an 548 attempt made to obtain a general license or permission for the use of 549 such proprietary rights by implementers or users of this 550 specification can be obtained from the IETF on-line IPR repository at 551 http://www.ietf.org/ipr. 553 The IETF invites any interested party to bring to its attention any 554 copyrights, patents or patent applications, or other proprietary 555 rights that may cover technology that may be required to implement 556 this standard. Please address the information to the IETF at 557 ietf-ipr@ietf.org. 559 Disclaimer of Validity 561 This document and the information contained herein are provided on an 562 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 563 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 564 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 565 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 566 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 567 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 569 Copyright Statement 571 Copyright (C) The Internet Society (2004). This document is subject 572 to the rights, licenses and restrictions contained in BCP 78, and 573 except as set forth therein, the authors retain all their rights. 575 Acknowledgment 577 Funding for the RFC Editor function is currently provided by the 578 Internet Society.