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