idnits 2.17.1 draft-ietf-tcpm-tcp-soft-errors-03.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 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 551. 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.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (January 25, 2007) is 6294 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 408, but no explicit reference was found in the text == Unused Reference: 'Guynes' is defined on line 417, 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: 3 errors (**), 0 flaws (~~), 6 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 January 25, 2007 5 Intended status: Informational 6 Expires: July 29, 2007 8 TCP's Reaction to Soft Errors 9 draft-ietf-tcpm-tcp-soft-errors-03.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 July 29, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 non-standard, but widely 47 implemented modification to TCP's reaction to ICMP "soft errors" that 48 can help overcome this problem. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Error Handling in TCP . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Reaction to ICMP error messages that indicate hard 55 errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2. Reaction to ICMP error messages that indicate soft 57 errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Problems that may arise from TCP's reaction to soft errors . . 5 59 3.1. General Discussion . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Problems that may arise with Dual Stack IPv6 on by 61 Default . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. A workaround for long delays between 63 connection-establishment attempts . . . . . . . . . . . . . . 6 64 5. A more conservative approach . . . . . . . . . . . . . . . . . 7 65 6. Possible drawbacks . . . . . . . . . . . . . . . . . . . . . . 8 66 6.1. Non-deterministic transient network failures . . . . . . . 8 67 6.2. Deterministic transient network failures . . . . . . . . . 8 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 70 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 74 Appendix A. Change log (to be removed before publication of 75 the document as an RFC) . . . . . . . . . . . . . . . 10 76 A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-02 . . . . . 10 77 A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-01 . . . . . 11 78 A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-00 . . . . . 11 79 A.4. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 11 80 A.5. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 11 81 A.6. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . 11 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 Intellectual Property and Copyright Statements . . . . . . . . . . 13 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 in an attempt 92 to survive a network failure.[RFC0816] 94 In the Internet architecture, the Internet Control Message Protocol 95 (ICMP) [RFC0792] is one fault isolation technique to report network 96 error conditions to the hosts sending datagrams over the network. 98 When a host is signaled of a network error, there is still the issue 99 of what to do to let communication survive, if possible, the network 100 failure. The fault recovery strategy may depend on the type of 101 network failure taking place, and the time the error condition is 102 detected. 104 This document analyzes the fault recovery strategy of TCP [RFC0793], 105 and the problems that may arise due to TCP's reaction to ICMP soft 106 errors. Among others, it analyzes the problems that may arise in 107 scenarios where dual stack nodes that have IPv6 enabled by default 108 are deployed in IPv4 or mixed IPv4 and IPv6 environments. 110 Additionally, we document a modification to TCP's reaction to ICMP 111 messages indicating "soft errors" during connection startup, that has 112 been implemented in a variety of TCP/IP stacks to help overcome the 113 problems outlined below. We stress that this modification runs 114 contrary to the standard behavior and this document unambiguously 115 does not change the standard reaction. 117 2. Error Handling in TCP 119 Network errors can be divided into soft and hard errors. Soft errors 120 are considered to be transient network failures, which are likely to 121 be solved in the near term. Hard errors, on the other hand, are 122 considered to reflect network error conditions which are unlikely to 123 be solved in the near future. 125 The "Requirements for Internet Hosts -- Communication Layers" RFC 126 [RFC1122] states, in section 4.2.3.9., that the ICMP "Destination 127 Unreachable" messages that indicate soft errors are ICMP codes 0 128 (network unreachable), 1 (host unreachable), and 5 (source route 129 failed). Even though ICMPv6 didn't exist when [RFC1122] was written, 130 one could extrapolate the concept of soft errors to ICMPv6 Type 1 131 Codes 0 (no route to destination) and 3 (address unreachable). 133 When there is a network failure that's not signaled to the sending 134 host, such as a gateway corrupting packets, TCP's fault recovery 135 action is to repeatedly retransmit the segment until either it gets 136 acknowledged, or the connection times out. 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 signaled. 146 2.1. Reaction to ICMP error messages that indicate hard errors 148 When receiving an ICMP error message that indicates a hard error 149 condition, TCP will simply abort the corresponding connection, 150 regardless of the state the connection is in. 152 The "Requirements for Internet Hosts -- Communication Layers" RFC 153 [RFC1122] states, in section 4.2.3.9, that TCP SHOULD abort 154 connections when receiving ICMP error messages that indicate hard 155 errors. This policy is based on the premise that, as hard errors 156 indicate network error conditions that won't change in the near term, 157 it will not be possible for TCP to usefully recover from this type of 158 network failure. 160 2.2. Reaction to ICMP error messages that indicate soft errors 162 If an ICMP error message is received that indicates a soft error, TCP 163 will repeatedly retransmit the packet until it either gets 164 acknowledged or the connection times out. In addition, the TCP may 165 record the information for possible later use [Stevens]. 167 The "Requirements for Internet Hosts -- Communication Layers" RFC 168 [RFC1122] states, in section 4.2.3.9, that TCP MUST NOT abort 169 connections when receiving ICMP error messages that indicate soft 170 errors. This policy is based on the premise that, as soft errors are 171 transient network failures that will hopefully be solved in the near 172 term, one of the retransmissions will succeed. 174 In case the connection timer expires, and an ICMP soft error message 175 has been received before the timeout, TCP can use this information to 176 provide the user with a more specific error message. [Stevens] 178 This reaction to soft errors exploits the valuable feature of the 179 Internet that for many network failures, the network can be 180 dynamically reconstructed without any disruption of the endpoints. 182 3. Problems that may arise from TCP's reaction to soft errors 184 3.1. General Discussion 186 Even though TCP's fault recovery strategy in the presence of soft 187 errors allows for TCP connections to survive transient network 188 failures, there are scenarios in which this policy may cause 189 undesirable effects. 191 For example, consider the case in which an application on a local 192 host is trying to communicate with a destination whose name resolves 193 to several IP addresses. The application on the local host will try 194 to establish a connection with the destination host, cycling through 195 the list of IP addresses, until one succeeds [RFC1123]. Suppose that 196 some (but not all) of the addresses in the returned list are 197 permanently unreachable. If such a permanently unreachable address 198 is the first in the list, the application will likely try to use the 199 permanently unreachable address first and block waiting for a timeout 200 before trying alternate addresses. 202 As discussed in Section 2, this unreachability condition may or may 203 not be signaled to the sending host. If the local TCP is not 204 signaled concerning the error condition, there is very little that 205 can be done other than repeatedly retransmit the SYN segment, and 206 wait for the existing timeout mechanism in TCP, or an application 207 timeout, to be triggered. However, even if unreachability is 208 signaled by some intermediate router to the local TCP by means of an 209 ICMP soft error message, the local TCP will still repeatedly 210 retransmit the SYN segment until the connection timer expires (in the 211 hopes that the error is transient). The "Requirements For Internet 212 Hosts -- Communication Layers" RFC [RFC1122] states that this timer 213 MUST be large enough to provide retransmission of the SYN segment for 214 at least 3 minutes. This would mean that the application on the 215 local host would spend several minutes for each unreachable address 216 it uses for trying to establish a TCP connection. These long delays 217 between connection establishment attempts would be inappropriate for 218 many interactive applications such as the web. ([Shneiderman] and 219 [Thadani] offer some insight into the interactive systems.) This 220 highlights that there is no one definition of a "transient error" and 221 that the level of persistence in the face of failure represents a 222 tradeoff. 224 3.2. Problems that may arise with Dual Stack IPv6 on by Default 226 A particular scenario in which the above sketched type of problem may 227 occur regularly is that where dual stack nodes that have IPv6 enabled 228 by default are deployed in IPv4 or mixed IPv4 and IPv6 environments, 229 and the IPv6 connectivity is non-existent 231 [I-D.ietf-v6ops-v6onbydefault]. 233 As discussed in [I-D.ietf-v6ops-v6onbydefault], there are two 234 possible variants of this scenario, which differ in whether the lack 235 of connectivity is signaled to the sending node, or not. 237 In cases where packets sent to a destination are silently dropped and 238 no ICMPv6 [RFC4443] errors are generated, there is little that can be 239 done other than waiting for the existing connection timeout mechanism 240 in TCP, or an application timeout to be triggered. 242 In cases where a node has no default routers and Neighbor 243 Unreachability Detection (NUD) fails for destinations assumed to be 244 on-link, or where firewalls or other systems that enforce scope 245 boundaries send ICMPv6 errors, the sending node will be signaled of 246 the unreachability problem. However, as discussed in Section 2.2, 247 standard TCP implementations will not abort connections when 248 receiving ICMP error messages that indicate soft errors. 250 4. A workaround for long delays between connection-establishment 251 attempts 253 As discussed in Section 1, it may make sense for the fault recovery 254 action to depend not only on the type of error being reported, but 255 also on the state of the connection against which the error is 256 reported. For example, one could infer that when an error arrives in 257 response to opening a new connection, it is probably caused by 258 opening the connection improperly, rather than by a transient network 259 failure. [RFC0816] 261 A number of TCP implementations have modified their reaction to soft 262 errors, to treat the errors as hard errors in the SYN-SENT or SYN- 263 RECEIVED states. It must be noted that this change violates section 264 4.2.3.9 of [RFC1122], which states that these Unreachable messages 265 indicate soft error conditions and TCP MUST NOT abort the 266 corresponding connection. 268 This workaround has been implemented, for example, in the Linux 269 kernel since version 2.0.0 (released in 1996) [Linux]. Section 5 270 discusses a more conservative approach than that sketched above, that 271 is implemented in FreeBSD. 273 We note that the TCPM WG could not arrive at consensus on allowing 274 the above described behavior as part of the standard. Therefore, 275 treating soft errors as hard errors during connection establishment, 276 while widespread, is not part of standard TCP behavior and this 277 document does not change that state of affairs. 279 5. A more conservative approach 281 A more conservative approach than simply treating soft errors as hard 282 errors as described above would be to abort a connection in the SYN- 283 SENT or SYN-RECEIVED states only after an ICMP Destination 284 Unreachable has been received a specified number of times, and the 285 SYN segment has been retransmitted more than some specified number of 286 times. 288 Two new parameters would have to be introduced to TCP, to be used 289 only during the connection-establishment phase: MAXSYNREXMIT and 290 MAXSOFTERROR. MAXSYNREXMIT would specify the number of times the SYN 291 segment would have to be retransmitted before a connection is 292 aborted. MAXSOFTERROR would specify the number of ICMP messages 293 indicating soft errors that would have to be received before a 294 connection is aborted. 296 Two additional state variables would need to be introduced to store 297 additional state information during the connection-establishment 298 phase: "nsynrexmit" and "nsofterror". Both would be initialized to 299 zero when a connection attempt is initiated, with "nsynrexmit" being 300 incremented by one every time the SYN segment is retransmitted and 301 "nsofterror" being incremented by one every time an ICMP message that 302 indicates a soft error is received. 304 A connection in the SYN-SENT or SYN-RECEIVED states would be aborted 305 if nsynrexmit was greater than MAXSYNREXMIT and "nsofterror" was 306 simultaneously greater than MAXSOFTERROR. 308 This approach would give the network more time to solve the 309 connectivity problem than simply aborting a connection attempt upon 310 reception of the first soft error. However, it should be noted that 311 depending on the values chosen for the MAXSYNREXMIT and MAXSOFTERROR 312 parameters, this approach could still lead to long delays between 313 connection establishment attempts, thus not solving the problem. For 314 example, BSD systems abort connections in the SYN-SENT or the SYN- 315 RECEIVED state when a second ICMP error is received, and the SYN 316 segment has been retransmitted more than three times. They also set 317 up a "connection-establishment timer" that imposes an upper limit on 318 the time the connection establishment attempt has to succeed, which 319 expires after 75 seconds [Stevens2]. Even when this policy may be 320 better than the three-minutes timeout policy specified in [RFC1122], 321 it may still be inappropriate for handling the potential problems 322 described in this document. This more conservative approach has been 323 implemented in BSD systems since, at least, 1994 [Stevens2]. 325 We also note that the approach given in this section is a generalized 326 version of the approach sketched in the previous section. In 327 particular, with MAXSOFTERROR set to 1 and MAXSYNREXMIT set to zero 328 the schemes are identical. 330 6. Possible drawbacks 332 The following subsections discuss some of the possible drawbacks 333 arising from the use of the non-standard modifications to TCP's 334 reaction to soft errors described in Section 4 and Section 5. 336 6.1. Non-deterministic transient network failures 338 In case a transient network failure affects all of the addresses 339 returned by the name-to-address translation function, all 340 destinations could be unreachable for some short period of time. In 341 such a scenario, the application could quickly cycle through all the 342 IP addresses in the list and return an error, when it could have let 343 TCP retry a destination a few seconds later, when the transient 344 problem could have disappeared. 346 6.2. Deterministic transient network failures 348 There are some scenarios in which transient network failures could be 349 deterministic. For example, consider the case in which upstream 350 network connectivity is triggered by network use. That is, network 351 connectivity is instantiated only on an "as needed" basis. In this 352 scenario, the connection triggering the upstream connectivity would 353 deterministically receive ICMP Destination Unreachables while the 354 upstream connectivity is being activated, and thus would be aborted. 356 7. Security Considerations 358 This document describes a non-standard modification to TCP's reaction 359 to soft errors that has been implemented in a variety of TCP 360 implementations. This modification makes TCP abort a connection in 361 the SYN-SENT or the SYN-RECEIVED states when it receives an ICMP 362 "Destination Unreachable" message that indicates a "soft error". 363 Therefore, the modification could be exploited to reset valid 364 connections during the connection-establishment phase. 366 The non-standard workaround described in this document makes TCP more 367 vulnerable to attack---even if only slightly. However, we note that 368 an attacker wishing to reset ongoing TCP connections could send any 369 of the ICMP hard error messages in any connection state. 371 A discussion of the use of ICMP to perform a variety of attacks 372 against TCP, and a number of counter-measures that minimize the 373 impact of these attacks can be found in [I-D.ietf-tcpm-icmp-attacks]. 375 A discussion of the security issues arising from the use of ICMPv6 376 can be found in [RFC4443]. 378 8. Acknowledgements 380 The author wishes to thank Mark Allman, Ron Bonica, Sally Floyd, 381 Guillermo Gont, Michael Kerrisk, Eddie Kohler, Mika Liljeberg, Pasi 382 Sarolahti, Pekka Savola, and Joe Touch, for contributing many 383 valuable comments on earlier versions of this document. 385 9. Contributors 387 Mika Liljeberg was the first to describe how their implementation 388 treated soft errors. Based on that, the solution discussed in 389 Section 4 was documented in [I-D.ietf-v6ops-v6onbydefault] by 390 Sebastien Roy, Alain Durand and James Paugh. 392 10. References 394 10.1. Normative References 396 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 397 RFC 792, September 1981. 399 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 400 RFC 793, September 1981. 402 [RFC1122] Braden, R., "Requirements for Internet Hosts - 403 Communication Layers", STD 3, RFC 1122, October 1989. 405 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 406 and Support", STD 3, RFC 1123, October 1989. 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, March 1997. 411 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 412 Message Protocol (ICMPv6) for the Internet Protocol 413 Version 6 (IPv6) Specification", RFC 4443, March 2006. 415 10.2. Informative References 417 [Guynes] Guynes, J., "Impact of System Response Time on State 418 Anxiety", Communications of the ACM , 1988. 420 [I-D.ietf-tcpm-icmp-attacks] 421 Gont, F., "ICMP attacks against TCP", 422 draft-ietf-tcpm-icmp-attacks-01 (work in progress), 423 October 2006. 425 [I-D.ietf-v6ops-v6onbydefault] 426 Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack 427 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 428 (work in progress), July 2004. 430 [Linux] The Linux Project, "http://www.kernel.org". 432 [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, 433 July 1982. 435 [Shneiderman] 436 Shneiderman, B., "Response Time and Display Rate in Human 437 Performance with Computers", ACM Computing Surveys , 1984. 439 [Stevens] "TCP/IP Illustrated, Volume 1: The Protocols", Addison- 440 Wesley , 1994. 442 [Stevens2] 443 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 444 The Implementation", Addison-Wesley , 1994. 446 [Thadani] Thadani, A., "Interactive User Productivity", IBM Systems 447 Journal No. 1, 1981. 449 Appendix A. Change log (to be removed before publication of the 450 document as an RFC) 452 A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-02 454 o Moved appendix on FreeBSD's approach to the body of the draft. 456 o Removed rest of the appendix, as suggested by Ron Bonica and Mark 457 Allman. 459 o Reworded some parts of the document to make the text more neutral. 461 o Miscellaneous editorial changes. 463 A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-01 465 o Addressed feedback posted by Sally Floyd (remove sentence in 466 Section 2.1 regarding processing of RST segments) 468 A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-00 470 o Miscellaneous editorial changes 472 A.4. Changes from draft-gont-tcpm-tcp-soft-errors-02 474 o Draft resubmitted as draft-ietf. 476 o Miscellaneous editorial changes 478 A.5. Changes from draft-gont-tcpm-tcp-soft-errors-01 480 o Changed wording to describe the mechanism, rather than proposing 481 it 483 o Miscellaneous editorial changes 485 A.6. Changes from draft-gont-tcpm-tcp-soft-errors-00 487 o Added reference to the Linux implementation in Section 4 489 o Added Section 6 491 o Added section on Higher-Level API 493 o Added Section 5 495 o Moved section "Asynchronous Application Notification" to Appendix 497 o Added section on parallel connection requests 499 o Miscellaneous editorial changes 501 Author's Address 503 Fernando Gont 504 Universidad Tecnologica Nacional / Facultad Regional Haedo 505 Evaristo Carriego 2644 506 Haedo, Provincia de Buenos Aires 1706 507 Argentina 509 Phone: +54 11 4650 8472 510 Email: fernando@gont.com.ar 511 URI: http://www.gont.com.ar 513 Full Copyright Statement 515 Copyright (C) The IETF Trust (2007). 517 This document is subject to the rights, licenses and restrictions 518 contained in BCP 78, and except as set forth therein, the authors 519 retain all their rights. 521 This document and the information contained herein are provided on an 522 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 523 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 524 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 525 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 526 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 527 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 529 Intellectual Property 531 The IETF takes no position regarding the validity or scope of any 532 Intellectual Property Rights or other rights that might be claimed to 533 pertain to the implementation or use of the technology described in 534 this document or the extent to which any license under such rights 535 might or might not be available; nor does it represent that it has 536 made any independent effort to identify any such rights. Information 537 on the procedures with respect to rights in RFC documents can be 538 found in BCP 78 and BCP 79. 540 Copies of IPR disclosures made to the IETF Secretariat and any 541 assurances of licenses to be made available, or the result of an 542 attempt made to obtain a general license or permission for the use of 543 such proprietary rights by implementers or users of this 544 specification can be obtained from the IETF on-line IPR repository at 545 http://www.ietf.org/ipr. 547 The IETF invites any interested party to bring to its attention any 548 copyrights, patents or patent applications, or other proprietary 549 rights that may cover technology that may be required to implement 550 this standard. Please address the information to the IETF at 551 ietf-ipr@ietf.org. 553 Acknowledgment 555 Funding for the RFC Editor function is provided by the IETF 556 Administrative Support Activity (IASA).