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