idnits 2.17.1 draft-ietf-tcpm-tcp-soft-errors-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 565. 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 162: '... TCP SHOULD abort connections when r...' RFC 2119 keyword, line 177: '... TCP MUST NOT abort connections when...' RFC 2119 keyword, line 221: '... [RFC1122] states that this timer MUST be large enough to provide...' RFC 2119 keyword, line 273: '...nditions and TCP MUST NOT abort the co...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2, 2007) is 6234 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Guynes' is defined on line 423, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-icmp-attacks-01 -- Obsolete informational reference (is this intentional?): RFC 816 (Obsoleted by RFC 7805) Summary: 4 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 April 2, 2007 5 Intended status: Informational 6 Expires: October 4, 2007 8 TCP's Reaction to Soft Errors 9 draft-ietf-tcpm-tcp-soft-errors-05.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 October 4, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes a non-standard, but widely implemented, 43 modification to TCP's handling of ICMP soft error messages received 44 in any of the non-synchronized states, that rejects connections 45 experiencing those errors immediately. This behavior reduces the 46 likelihood of long delays between connection establishment attempts 47 that may arise in a number of scenarios, including one in which dual 48 stack nodes that have IPv6 enabled by default are deployed in IPv4 or 49 mixed IPv4 and IPv6 environments. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Error Handling in TCP . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Reaction to ICMP error messages that indicate hard 56 errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Reaction to ICMP error messages that indicate soft 58 errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Problems that may arise from TCP's reaction to soft errors . . 5 60 3.1. General Discussion . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Problems that may arise with Dual Stack IPv6 on by 62 Default . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. A workaround for long delays between 64 connection-establishment attempts . . . . . . . . . . . . . . 6 65 5. A more conservative approach . . . . . . . . . . . . . . . . . 7 66 6. Possible drawbacks . . . . . . . . . . . . . . . . . . . . . . 8 67 6.1. Non-deterministic transient network failures . . . . . . . 8 68 6.2. Deterministic transient network failures . . . . . . . . . 8 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 71 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 75 Appendix A. Change log (to be removed before publication of 76 the document as an RFC) . . . . . . . . . . . . . . . 10 77 A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-04 . . . . . 10 78 A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-03 . . . . . 11 79 A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-02 . . . . . 11 80 A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-01 . . . . . 11 81 A.5. Changes from draft-ietf-tcpm-tcp-soft-errors-00 . . . . . 11 82 A.6. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 11 83 A.7. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 11 84 A.8. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . 11 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 Intellectual Property and Copyright Statements . . . . . . . . . . 13 88 1. Introduction 90 The handling of network failures can be separated into two different 91 actions: fault isolation and fault recovery. Fault isolation 92 consists of the actions that hosts and routers take to determine that 93 there is a network failure. Fault recovery, on the other hand, 94 consists of the actions that hosts and routers perform in an attempt 95 to survive a network failure [RFC0816]. 97 In the Internet architecture, the Internet Control Message Protocol 98 (ICMP) [RFC0792] is one fault isolation technique to report network 99 error conditions to the hosts sending datagrams over the network. 101 When a host is notified of a network error its network stack will 102 attempt to continue communications, if possible, in the presence of 103 the network failure. The fault recovery strategy may depend on the 104 type of network failure taking place, and the time the error 105 condition is detected. 107 This document analyzes the fault recovery strategy of TCP [RFC0793], 108 and the problems that may arise due to TCP's reaction to ICMP soft 109 errors. Among others, it analyzes the problems that may arise in 110 scenarios where dual stack nodes that have IPv6 enabled by default 111 are deployed in IPv4 or mixed IPv4 and IPv6 environments. 113 Additionally, we document a modification to TCP's reaction to ICMP 114 messages indicating soft errors during connection startup, that has 115 been implemented in a variety of TCP/IP stacks to help overcome the 116 problems outlined below. We stress that this modification runs 117 contrary to the standard behavior and this document unambiguously 118 does not change the standard reaction. 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 network error conditions that are unlikely to 126 be solved in the near future. 128 The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9., that 129 the ICMP messages that indicate soft errors are ICMP "Destination 130 Unreachable" codes 0 (network unreachable), 1 (host unreachable), and 131 5 (source route failed), ICMP "Time Exceeded" codes 0 (time to live 132 exceeded in transit) and 1 (fragment reassembly time exceeded), and 133 ICMP "Parameter Problem". Even though ICMPv6 didn't exist when 134 [RFC1122] was written, one could extrapolate the concept of soft 135 errors to ICMPv6 "Destination Unreachable" codes 0 (no route to 136 destination) and 3 (address unreachable), ICMPv6 "Time Exceeded" 137 codes 0 (Hop limit exceeded in transit) and 1 (Fragment reassembly 138 time exceeded), and ICMPv6 "Parameter Problem" codes 0 (Erroneous 139 header field encountered), 1 (Unrecognized Next Header type 140 encountered) and 2 (Unrecognized IPv6 option encountered). 142 When there is a network failure that's not signaled to the sending 143 host, such as a gateway corrupting packets, TCP's fault recovery 144 action is to repeatedly retransmit the segment until either it gets 145 acknowledged, or the connection times out. 147 In the case that a host does receive an ICMP error message referring 148 to an ongoing TCP connection, the IP layer will pass this message up 149 to corresponding TCP instance to raise awareness of the network 150 failure [RFC1122]. 152 TCP's reaction to ICMP messages will depend on the type of error 153 being signaled. 155 2.1. Reaction to ICMP error messages that indicate hard errors 157 When receiving an ICMP error message that indicates a hard error 158 condition, TCP will simply abort the corresponding connection, 159 regardless of the connection state. 161 The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that 162 TCP SHOULD abort connections when receiving ICMP error messages that 163 indicate hard errors. This policy is based on the premise that, as 164 hard errors indicate network error conditions that won't change in 165 the near term, it will not be possible for TCP to usefully recover 166 from this type of network failure. 168 2.2. Reaction to ICMP error messages that indicate soft errors 170 If an ICMP error message is received that indicates a soft error, TCP 171 will repeatedly retransmit the segment until it either gets 172 acknowledged or the connection times out. In addition, the TCP 173 sender may record the information for possible later use [Stevens] 174 (pp. 317-319). 176 The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that 177 TCP MUST NOT abort connections when receiving ICMP error messages 178 that indicate soft errors. This policy is based on the premise that, 179 as soft errors are transient network failures that will hopefully be 180 solved in the near term, one of the retransmissions will succeed. 182 When the connection timer expires, and an ICMP soft error message has 183 been received before the timeout, TCP can use this information to 184 provide the user with a more specific error message [Stevens] (pp. 185 317-319). 187 This reaction to soft errors exploits the valuable feature of the 188 Internet that for many network failures, the network can be 189 dynamically reconstructed without any disruption of the endpoints. 191 3. Problems that may arise from TCP's reaction to soft errors 193 3.1. General Discussion 195 Even though TCP's fault recovery strategy in the presence of soft 196 errors allows for TCP connections to survive transient network 197 failures, there are scenarios in which this policy may cause 198 undesirable effects. 200 For example, consider a scenario in which an application on a local 201 host is trying to communicate with a destination whose name resolves 202 to several IP addresses. The application on the local host will try 203 to establish a connection with the destination host, cycling through 204 the list of IP addresses, until one succeeds [RFC1123]. Suppose that 205 some (but not all) of the addresses in the returned list are 206 permanently unreachable. If such a permanently unreachable address 207 is the first in the list, the application will likely try to use the 208 permanently unreachable address first and block waiting for a timeout 209 before trying alternate addresses. 211 As discussed in Section 2, this unreachability condition may or may 212 not be signaled to the sending host. If the local TCP is not 213 signaled concerning the error condition, there is very little that 214 can be done other than repeatedly retransmit the SYN segment, and 215 wait for the existing timeout mechanism in TCP, or an application 216 timeout, to be triggered. However, even if unreachability is 217 signaled by some intermediate router to the local TCP by means of an 218 ICMP soft error message, the local TCP will still repeatedly 219 retransmit the SYN segment until the connection timer expires (in the 220 hopes that the error is transient). The Host Requirements RFC 221 [RFC1122] states that this timer MUST be large enough to provide 222 retransmission of the SYN segment for at least 3 minutes. This would 223 mean that the application on the local host would spend several 224 minutes for each unreachable address it uses for trying to establish 225 a TCP connection. These long delays between connection establishment 226 attempts would be inappropriate for many interactive applications 227 such as the web. ([Shneiderman] and [Thadani] offer some insight 228 into the interactive systems). This highlights that there is no one 229 definition of a "transient error" and that the level of persistence 230 in the face of failure represents a tradeoff. 232 3.2. Problems that may arise with Dual Stack IPv6 on by Default 234 A particular scenario in which the above sketched type of problem may 235 occur regularly is that where dual stack nodes that have IPv6 enabled 236 by default are deployed in IPv4 or mixed IPv4 and IPv6 environments, 237 and the IPv6 connectivity is non-existent 238 [I-D.ietf-v6ops-v6onbydefault]. 240 As discussed in [I-D.ietf-v6ops-v6onbydefault], there are two 241 possible variants of this scenario, which differ in whether the lack 242 of connectivity is signaled to the sending node, or not. 244 In those scenarios in which packets sent to a destination are 245 silently dropped and no ICMPv6 [RFC4443] errors are generated, there 246 is little that can be done other than waiting for the existing 247 connection timeout mechanism in TCP, or an application timeout, to be 248 triggered. 250 In scenarios where a node has no default routers and Neighbor 251 Unreachability Detection (NUD) fails for destinations assumed to be 252 on-link, or where firewalls or other systems that enforce scope 253 boundaries send ICMPv6 errors, the sending node will be signaled of 254 the unreachability problem. However, as discussed in Section 2.2, 255 standard TCP implementations will not abort connections when 256 receiving ICMP error messages that indicate soft errors. 258 4. A workaround for long delays between connection-establishment 259 attempts 261 As discussed in Section 1, it may make sense for the fault recovery 262 action to depend not only on the type of error being reported, but 263 also on the state of the connection against which the error is 264 reported. For example, one could infer that when an error arrives in 265 response to opening a new connection, it is probably caused by 266 opening the connection improperly, rather than by a transient network 267 failure [RFC0816]. 269 A number of TCP implementations have modified their reaction to soft 270 errors, to treat the errors as hard errors in the SYN-SENT or SYN- 271 RECEIVED states. However, this change violates section 4.2.3.9 of 272 [RFC1122], which states that these Unreachable messages indicate soft 273 error conditions and TCP MUST NOT abort the corresponding connection. 275 This workaround has been implemented, for example, in the Linux 276 kernel since version 2.0.0 (released in 1996) [Linux]. Section 5 277 discusses a more conservative approach than that sketched above that 278 is implemented in FreeBSD. 280 We note that the TCPM WG could not arrive at consensus on allowing 281 the above described behavior as part of the standard. Therefore, 282 treating soft errors as hard errors during connection establishment, 283 while widespread, is not part of standard TCP behavior and this 284 document does not change that state of affairs. 286 5. A more conservative approach 288 A more conservative approach than simply treating soft errors as hard 289 errors as described above would be to abort a connection in the SYN- 290 SENT or SYN-RECEIVED states only after an ICMP Destination 291 Unreachable has been received a specified number of times, and the 292 SYN segment has been retransmitted more than some specified number of 293 times. 295 Two new parameters would have to be introduced to TCP, to be used 296 only during the connection-establishment phase: MAXSYNREXMIT and 297 MAXSOFTERROR. MAXSYNREXMIT would specify the number of times the SYN 298 segment would have to be retransmitted before a connection is 299 aborted. MAXSOFTERROR would specify the number of ICMP messages 300 indicating soft errors that would have to be received before a 301 connection is aborted. 303 Two additional state variables would need to be introduced to store 304 additional state information during the connection-establishment 305 phase: "nsynrexmit" and "nsofterror". Both would be initialized to 306 zero when a connection attempt is initiated, with "nsynrexmit" being 307 incremented by one every time the SYN segment is retransmitted and 308 "nsofterror" being incremented by one every time an ICMP message that 309 indicates a soft error is received. 311 A connection in the SYN-SENT or SYN-RECEIVED states would be aborted 312 if "nsynrexmit" was greater than MAXSYNREXMIT and "nsofterror" was 313 simultaneously greater than MAXSOFTERROR. 315 This approach would give the network more time to solve the 316 connectivity problem than simply aborting a connection attempt upon 317 reception of the first soft error. However, it should be noted that 318 depending on the values chosen for the MAXSYNREXMIT and MAXSOFTERROR 319 parameters, this approach could still lead to long delays between 320 connection establishment attempts, thus not solving the problem. For 321 example, BSD systems abort connections in the SYN-SENT or the SYN- 322 RECEIVED state when a second ICMP error is received, and the SYN 323 segment has been retransmitted more than three times. They also set 324 up a "connection-establishment timer" that imposes an upper limit on 325 the time the connection establishment attempt has to succeed, which 326 expires after 75 seconds [Stevens2] (pp. 828-829). Even when this 327 policy may be better than the three-minutes timeout policy specified 328 in [RFC1122], it may still be inappropriate for handling the 329 potential problems described in this document. This more 330 conservative approach has been implemented in BSD systems since, at 331 least, 1994 [Stevens2]. 333 We also note that the approach given in this section is a generalized 334 version of the approach sketched in the previous section. In 335 particular, with MAXSOFTERROR set to 1 and MAXSYNREXMIT set to zero 336 the schemes are identical. 338 6. Possible drawbacks 340 The following subsections discuss some of the possible drawbacks 341 arising from the use of the non-standard modifications to TCP's 342 reaction to soft errors described in Section 4 and Section 5. 344 6.1. Non-deterministic transient network failures 346 In scenarios where a transient network failure affects all of the 347 addresses returned by the name-to-address translation function, all 348 destinations could be unreachable for some short period of time. In 349 such a scenario, the application could quickly cycle through all the 350 IP addresses in the list and return an error, when it could have let 351 TCP retry a destination a few seconds later, when the transient 352 problem could have disappeared. 354 6.2. Deterministic transient network failures 356 There are some scenarios in which transient network failures could be 357 deterministic. For example, consider a scenario in which upstream 358 network connectivity is triggered by network use. That is, network 359 connectivity is instantiated only on an "as needed" basis. In this 360 scenario, the connection triggering the upstream connectivity could 361 deterministically receive ICMP Destination Unreachables while the 362 upstream connectivity is being activated, and thus would be aborted. 364 7. Security Considerations 366 This document describes a non-standard modification to TCP's reaction 367 to soft errors that has been implemented in a variety of TCP 368 implementations. This modification makes TCP abort a connection in 369 the SYN-SENT or the SYN-RECEIVED states when it receives an ICMP 370 "Destination Unreachable" message that indicates a soft error. 371 Therefore, the modification could be exploited to reset valid 372 connections during the connection-establishment phase. 374 The non-standard workaround described in this document makes TCP more 375 vulnerable to attack---even if only slightly. However, we note that 376 an attacker wishing to reset ongoing TCP connections could send any 377 of the ICMP hard error messages in any connection state. 379 A discussion of the use of ICMP to perform a variety of attacks 380 against TCP, and a number of counter-measures that minimize the 381 impact of these attacks can be found in [I-D.ietf-tcpm-icmp-attacks]. 383 A discussion of the security issues arising from the use of ICMPv6 384 can be found in [RFC4443]. 386 8. Acknowledgements 388 The author wishes to thank Mark Allman, Ron Bonica, Ted Faber, Gorry 389 Fairhurst, Sally Floyd, Guillermo Gont, Michael Kerrisk, Eddie 390 Kohler, Mika Liljeberg, Carlos Pignataro, Pasi Sarolahti, Pekka 391 Savola, and Joe Touch, for contributing many valuable comments on 392 earlier versions of this document. 394 9. Contributors 396 Mika Liljeberg was the first to describe how their implementation 397 treated soft errors. Based on that, the solution discussed in 398 Section 4 was documented in [I-D.ietf-v6ops-v6onbydefault] by 399 Sebastien Roy, Alain Durand and James Paugh. 401 10. References 403 10.1. Normative References 405 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 406 RFC 792, September 1981. 408 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 409 RFC 793, September 1981. 411 [RFC1122] Braden, R., "Requirements for Internet Hosts - 412 Communication Layers", STD 3, RFC 1122, October 1989. 414 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 415 and Support", STD 3, RFC 1123, October 1989. 417 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 418 Message Protocol (ICMPv6) for the Internet Protocol 419 Version 6 (IPv6) Specification", RFC 4443, March 2006. 421 10.2. Informative References 423 [Guynes] Guynes, J., "Impact of System Response Time on State 424 Anxiety", Communications of the ACM , 1988. 426 [I-D.ietf-tcpm-icmp-attacks] 427 Gont, F., "ICMP attacks against TCP", 428 draft-ietf-tcpm-icmp-attacks-01 (work in progress), 429 October 2006. 431 [I-D.ietf-v6ops-v6onbydefault] 432 Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack 433 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 434 (work in progress), July 2004. 436 [Linux] The Linux Project, "http://www.kernel.org". 438 [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, 439 July 1982. 441 [Shneiderman] 442 Shneiderman, B., "Response Time and Display Rate in Human 443 Performance with Computers", ACM Computing Surveys , 1984. 445 [Stevens] Stevens, W., "TCP/IP Illustrated, Volume 1: The 446 Protocols", Addison-Wesley , 1994. 448 [Stevens2] 449 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 450 The Implementation", Addison-Wesley , 1994. 452 [Thadani] Thadani, A., "Interactive User Productivity", IBM Systems 453 Journal No. 1, 1981. 455 Appendix A. Change log (to be removed before publication of the 456 document as an RFC) 458 A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-04 459 o Addresses feedback sent by Carlos Pignataro (adds missing error 460 codes in Section 2, and fixes a number of typos/writeos). 462 A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-03 464 o Addresses feedback sent by Ted Faber and Gorry Fairhurst 465 (miscellaneous editorial changes). 467 A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-02 469 o Moved appendix on FreeBSD's approach to the body of the draft. 471 o Removed rest of the appendix, as suggested by Ron Bonica and Mark 472 Allman. 474 o Reworded some parts of the document to make the text more neutral. 476 o Miscellaneous editorial changes. 478 A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-01 480 o Addressed feedback posted by Sally Floyd (remove sentence in 481 Section 2.1 regarding processing of RST segments) 483 A.5. Changes from draft-ietf-tcpm-tcp-soft-errors-00 485 o Miscellaneous editorial changes 487 A.6. Changes from draft-gont-tcpm-tcp-soft-errors-02 489 o Draft resubmitted as draft-ietf. 491 o Miscellaneous editorial changes 493 A.7. Changes from draft-gont-tcpm-tcp-soft-errors-01 495 o Changed wording to describe the mechanism, rather than proposing 496 it 498 o Miscellaneous editorial changes 500 A.8. Changes from draft-gont-tcpm-tcp-soft-errors-00 502 o Added reference to the Linux implementation in Section 4 504 o Added Section 6 505 o Added section on Higher-Level API 507 o Added Section 5 509 o Moved section "Asynchronous Application Notification" to Appendix 511 o Added section on parallel connection requests 513 o Miscellaneous editorial changes 515 Author's Address 517 Fernando Gont 518 Universidad Tecnologica Nacional / Facultad Regional Haedo 519 Evaristo Carriego 2644 520 Haedo, Provincia de Buenos Aires 1706 521 Argentina 523 Phone: +54 11 4650 8472 524 Email: fernando@gont.com.ar 525 URI: http://www.gont.com.ar 527 Full Copyright Statement 529 Copyright (C) The IETF Trust (2007). 531 This document is subject to the rights, licenses and restrictions 532 contained in BCP 78, and except as set forth therein, the authors 533 retain all their rights. 535 This document and the information contained herein are provided on an 536 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 537 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 538 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 539 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 540 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 541 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 543 Intellectual Property 545 The IETF takes no position regarding the validity or scope of any 546 Intellectual Property Rights or other rights that might be claimed to 547 pertain to the implementation or use of the technology described in 548 this document or the extent to which any license under such rights 549 might or might not be available; nor does it represent that it has 550 made any independent effort to identify any such rights. Information 551 on the procedures with respect to rights in RFC documents can be 552 found in BCP 78 and BCP 79. 554 Copies of IPR disclosures made to the IETF Secretariat and any 555 assurances of licenses to be made available, or the result of an 556 attempt made to obtain a general license or permission for the use of 557 such proprietary rights by implementers or users of this 558 specification can be obtained from the IETF on-line IPR repository at 559 http://www.ietf.org/ipr. 561 The IETF invites any interested party to bring to its attention any 562 copyrights, patents or patent applications, or other proprietary 563 rights that may cover technology that may be required to implement 564 this standard. Please address the information to the IETF at 565 ietf-ipr@ietf.org. 567 Acknowledgment 569 Funding for the RFC Editor function is provided by the IETF 570 Administrative Support Activity (IASA).