idnits 2.17.1 draft-eggert-tcpm-tcp-abort-timeout-option-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 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 495. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 511), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 9) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == 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 (July 12, 2004) is 7226 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) == Unused Reference: '15' is defined on line 444, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. '1') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '7') (Obsoleted by RFC 5944) == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-05 -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '12') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '13') (Obsoleted by RFC 4301) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor L. Eggert 3 Extensions (tcpm) NEC 4 Internet-Draft July 12, 2004 5 Expires: January 10, 2005 7 TCP Abort Timeout Option 8 draft-eggert-tcpm-tcp-abort-timeout-option-01 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. This document may not be modified, and derivative works of 16 it may not be created, except to publish it as an RFC and to 17 translate it into languages other than English. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 10, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 The TCP Abort Timeout Option allows conforming TCP implementations to 44 exchange requests for individual, per-connection abort timeouts. The 45 TCP abort timeout controls how long transmitted data may remain 46 unacknowledged before a connection is aborted. TCP implementations 47 typically use a single, system-wide timeout value. Using individual, 48 per-connection timeouts allows established TCP connections to survive 49 extended periods of disconnection. 51 1. Introduction 53 The Transmission Control Protocol (TCP) specification [1] includes a 54 "user timeout" that defines the maximum amount of time that 55 transmitted segments may remain unacknowledged before TCP will abort 56 the connection. If a disconnection lasts longer than the user 57 timeout, no acknowledgments are received for any transmission 58 attempt, including keep-alives [5], and the TCP connection will abort 59 when the user timeout occurs. 61 The TCP specification [1] does not constrain the permitted values for 62 user timeouts. Many TCP implementations default to user timeout 63 values of a few minutes [5]. Instead of a single user timeout, some 64 TCP implementations offer finer-grained mechanisms. For example, 65 Solaris supports different timeouts depending on whether a TCP 66 connection is in the SYN-SENT, SYN-RECEIVED, or ESTABLISHED state 67 [6]. (The host requirements RFC [2] mandates a timeout of at least 68 three minutes for the SYN-SENT case.) 70 System-wide user timeouts are a useful basic mechanism. However, the 71 ability to selectively choose individual user timeout values for 72 different connections can improve TCP operation in scenarios that are 73 currently not well supported. 75 Mobile hosts that change network attachment points based on current 76 location are one example. Such hosts, maybe using MobileIP [7] or 77 HIP [8], are only intermittently connected to the Internet. In 78 between connected periods, mobile hosts may experience periods of 79 disconnection during which no network service is available 80 [9][10][11]. Other factors that can cause disconnections are high 81 levels of transient congestion and link or routing failures inside 82 the network. 84 In scenarios similar to the ones described above, a host may not know 85 exactly when or for how long it will be disconnected from the 86 network, but it might expect such events due to past mobility 87 patterns and thus benefit from using longer abort timeouts. In other 88 scenarios, the length and time of a network disconnection may even be 89 predictable. For example, an orbiting node on a satellite 90 experiences disconnections due to line-of-sight blocking by other 91 planetary bodies. The disconnection times and durations of such a 92 host may be easily computable from orbital mechanics. 94 In these examples above, as well as other cases, established TCP 95 connections between two peers can abort when a disconnection exceeds 96 the system-wide default user timeout. This document specifies a new 97 TCP option - the Abort Timeout Option - that allows conforming hosts 98 to exchange per-connection abort timeout requests. This allows, for 99 example, mobile hosts to maintain TCP connections across disconnected 100 periods that are longer than their system's default user timeout. A 101 second use of the TCP Abort Timeout Option is exchange of 102 shorter-than-default abort timeouts. This can allow busy servers to 103 explicitly notify their clients that they will maintain the state 104 associated with established connections only across short periods of 105 disconnection. 107 TCP Abort Timeout Options allow hosts to both request specific abort 108 timeouts for new connections and to request changes to the effective 109 abort timeouts of established connections. The latter allows 110 connections to start with short timeouts and only request longer 111 timeouts when disconnection was imminent, and only for connections 112 considered important. The ability to request changes to abort 113 timeouts of established connections is also useful to raise the abort 114 timeout after in-band authentication has occurred. For example, 115 peers could request longer abort timeouts for the TCP connections 116 underlying two-way authenticated TLS connections [12] after their 117 authentication handshakes. 119 2. Conventions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [3]. 125 3. Specification 127 0 1 2 3 128 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Kind = X | Length = 4 |G| Abort Timeout | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 (One tick mark represents one bit.) 135 Figure 1: Format of the TCP Abort timeout Option 137 Figure 1 shows the format of the TCP Abort Timeout Option. It 138 contains these fields: 140 Kind (8 bits): 141 A TCP option number [1] to be assigned by IANA upon publication of 142 this document (see Section 5.) 144 Length (8 bits): 145 Length of the TCP option in octets [1]; its value MUST be 4. 147 Granularity (1 bit): 148 Granularity bit, indicating the granularity of the "Abort Timeout" 149 field. When set (G = 1), the time interval in the "Abort Timeout" 150 field MUST be interpreted as minutes. Otherwise (G = 0), the time 151 interval in the "Abort Timeout" field MUST be interpreted as 152 seconds. 154 Abort Timeout (15 bits): 155 Specifies the abort timeout suggestion for this connection. It 156 MUST be interpreted as a 15-bit unsigned integer. The granularity 157 of the timeout (minutes or seconds) depends on the "G" field. 159 3.1 Operation 161 Sending a TCP Abort Timeout Option signals to the receiving peer that 162 the sender will start to use the indicated abort timeout value 163 locally for the connection and is requesting that the receiving peer 164 should start to use a corresponding abort timeout for it. Section 165 3.2 discusses the effects of different timeout values. 167 When a host that supports the TCP Abort Timeout Option receives one, 168 it decides whether to change the connection's local abort timeout 169 accordingly. Generally, hosts SHOULD honor requests for changes to 170 the abort timeout, unless security concerns or external policies 171 indicate otherwise (see Section 4.) If so, hosts MAY ignore incoming 172 TCP Abort Timeout Options and MAY use a different abort timeout for 173 the connection. 175 A TCP Abort Timeout Option with a value of zero (i.e., "now") is 176 nonsensical and MUST NOT be sent. If received, it MUST be ignored. 177 Section 3.2 discusses potentially problematic effects of other abort 178 timeout durations. 180 Hosts SHOULD impose upper and lower limits on the abort timeouts they 181 use. Section 3.2 discusses abort timeout limits. 183 The abort timeout value included in a TCP Abort Timeout Option 184 specifies the requested abort timeout during a connection's 185 synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, 186 CLOSING, or LAST-ACK.) Connections in other states MUST use standard 187 timeout values [1][2]. 189 (NB: A future version of this document may extend per-connection 190 abort timeouts to the SYN-SENT and SYN-RECEIVED states in a way that 191 conforms to the required minimum timeouts.) 193 A TCP implementation that does not support the TCP Abort Timeout 194 Option SHOULD silently ignore it [2], thus ensuring interoperability. 196 It is important to note that TCP Abort Timeout Options do not change 197 the semantics of the TCP protocol. Hosts remain free to abort 198 connections at any time for any reason, whether or not they use 199 custom abort timeouts or have requested the peer to use them. 200 Connections may also terminate due to other reasons, such as stateful 201 firewalls that terminate connections after apparent periods of 202 idleness. 204 3.1.1 Operation during the SYN Handshake 206 A host that supports the TCP Abort Timeout Option and wishes to use 207 individual abort timeouts for a connection MUST include an 208 appropriate TCP Abort Timeout Option in its initial SYN segment. 210 A host that supports the TCP Abort Timeout Option MAY omit the TCP 211 Abort Timeout Option from the initial SYN if custom abort timeouts 212 are not required for a specific connection. It SHOULD omit the TCP 213 Abort Timeout Option from the initial SYN if there is evidence that 214 the peer does not support the TCP Abort Timeout Option, for example, 215 if a prior connection attempt including a TCP Abort Timeout Option 216 has failed. 218 If a host does not include a TCP Abort Timeout Option in its initial 219 SYN, it MUST NOT include it in any other segment either and MUST 220 ignore the contents of any received TCP Abort Timeout Option. 222 A host that supports the TCP Abort Timeout Option and receives a SYN 223 segment that includes one SHOULD respond with an appropriate TCP 224 Abort Timeout Option in its SYN-ACK segment. If an incoming SYN 225 segment does not include a TCP Abort Timeout Option, a host MUST NOT 226 include one in the SYN-ACK segment or any other segment either and it 227 MUST ignore the contents of any other received TCP Abort Timeout 228 Option. 230 3.1.2 Operation during the Synchronized States 232 During the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, 233 CLOSE-WAIT, CLOSING, or LAST-ACK) and unless both the SYN and SYN-ACK 234 of a connection contained TCP Abort Timeout Options, both hosts 235 participating in the connection MUST NOT send TCP Abort Timeout 236 Options in any other segment. Additionally, they both MUST ignore 237 the contents of any received TCP Abort Timeout Option. 239 Otherwise, whenever a host changes the local abort timeout of a 240 connection, it SHOULD include a TCP Abort Timeout Option indicating 241 the new abort timeout in its next segment to the peer. This allows 242 the peer to adapt its local abort timeout for the connection 243 accordingly. 245 3.2 Duration of the Abort Timeout 247 The TCP Abort Timeout Option allows host to exchange abort timeout 248 values from zero seconds to over 9 hours at a granularity of seconds 249 and from zero minutes to over 22 days at a granularity of minutes. 251 Very short abort timeout values can affect TCP transmissions over 252 high-delay paths. If the abort timeout occurs before an 253 acknowledgment for an outstanding segment arrives, possibly due to 254 packet loss, the connection aborts. Many TCP implementations default 255 to abort timeout values of a few minutes [5]. Although the TCP Abort 256 Timeout Option allows negotiation of short timeouts, applications 257 requesting them should consider these effects. 259 Long abort timeout values allow hosts to tolerate extended periods of 260 disconnection. However, they also require hosts to maintain the TCP 261 state associated with connections for long periods of time. Section 262 4 discusses the security implications of long timeout values. 264 To protect against these effects, implementations SHOULD impose 265 limits on the abort timeout values they accept and use. The 266 remainder of this section describes a RECOMMENDED scheme to limit 267 abort timeouts based on upper and lower limits. Under the 268 RECOMMENDED scheme to limit abort timeouts, each TCP SHOULD compute 269 the abort timeout (USER_TIMEOUT) for a connection according to this 270 formula: 272 USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT)) 274 Each field is to be interpreted as follows: 276 USER_TIMEOUT: 277 Resulting abort timeout value to be adopted by the local TCP for a 278 connection. 280 U_LIMIT: 281 Current upper limit imposed on the connection's abort timeout by 282 the local host. 284 L_LIMIT: 285 Current lower limit imposed on the connection's abort timeout by 286 the local host. 288 LOCAL_UTO: 289 Current local abort timeout of the specific connection. 291 REMOTE_UTO: 292 Last received abort timeout option the peer uses for the 293 connection, i.e., contents of the last-received TCP Abort Timeout 294 Option. 296 Enforcing a lower limit (L_LIMIT) protects against connection aborts 297 due to transient network conditions, including temporary congestion, 298 mobility hand-offs or routing instabilities. 300 An upper limit (U_LIMIT) can reduce the effect of resource exhaustion 301 attacks. Section 4 discusses the details of these attacks. 303 Note that these limits MAY be specified as system-wide constants or 304 at other granularities, such as on per-host, per-user or even 305 per-connection basis. Furthermore, these limits need not be static. 306 For example, they MAY be a function of system resource utilization or 307 attack status and could be dynamically adapted. 309 The Host Requirements RFC [2] does not impose any limits on the 310 length of the abort timeout. However, a time interval of at least 311 100 seconds is RECOMMENDED. Consequently, the lower limit (LLIMIT) 312 SHOULD be set to at least 100 seconds when following the RECOMMENDED 313 scheme described in this section. 315 4. Security Considerations 317 Lengthening abort timeouts has obvious security implications. 318 Flooding attacks cause denial of service by forcing servers to commit 319 resources for maintaining the state of throw-away connections. TCP 320 implementations do not become more vulnerable to simple SYN flooding 321 by implementing the TCP Abort Timeout Option, because abort timeouts 322 negotiated during the handshake only affect the synchronized states 323 (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK), 324 which simple SYN floods never reach. 326 However, when an attacker completes the three-way handshakes of its 327 throw-away connections it can amplify the effects of resource 328 exhaustion attacks, because the attacked server must maintain the 329 connection state associated with the throw-away connections for 330 longer durations. Because connection state is kept longer, 331 lower-frequency attack traffic, which may be more difficult to 332 detect, can already cause resource exhaustion. 334 Several approaches can help mitigate this issue. First, 335 implementations can require prior peer authentication, e.g., using 336 IPsec [13], before accepting long abort timeouts for the peer's 337 connections. Similarly, a host can only start to accept long abort 338 timeouts for an established connection after in-band authentication 339 has occurred, for example, after a TLS handshake across the 340 connection has succeeded [12]. Although these are arguably the most 341 complete solutions, they depend on external mechanisms to establish a 342 trust relationship. 344 A second alternative that does not depend on external mechanisms 345 would introduce a per-peer limit on the number of connections that 346 may use increased abort timeouts. Several variants of this approach 347 are possible, such as fixed limits or shortening accepted abort 348 timeouts with a rising number of connections. Although this 349 alternative does not eliminate resource exhaustion attacks from a 350 single peer, it can limit their effects. 352 Per-peer limits cannot protect against distributed denial of service 353 attacks, where multiple clients coordinate a resource exhaustion 354 attack that uses long abort timeouts. To protect against such 355 attacks, TCP implementations could reduce the duration of accepted 356 abort timeouts with increasing resource utilization. 358 TCP implementations under attack may be forced to shed load by 359 resetting established connections. Some load-shedding heuristics, 360 such as resetting connections with long idle times first, can 361 negatively affect service for intermittently connected, trusted peers 362 that have negotiated long abort timeouts. On the other hand, 363 resetting connections to untrusted peers that use long abort timeouts 364 may be effective. In general, using the peers' level of trust as a 365 parameter during the load-shedding decision process may be useful. 367 Finally, upper and lower limits on abort timeouts, discussed in 368 Section 3.2, can be an effective tool to limit the impact of these 369 sorts of attacks. 371 5. IANA Considerations 373 This section is to be interpreted according to [4]. 375 This document does not define any new namespaces. It uses an 8-bit 376 TCP option number maintained by IANA at 377 http://www.iana.org/assignments/tcp-parameters. 379 6. Acknowledgments 381 This revision of the document incorporates several ideas from 382 Fernando Gont's "Adaptive User Timeout" mechanism [14] that is based 383 on the -00 revision of this document. The two documents are 384 currently being merged, but a few issues remain to be resolved. In 385 the meantime, this revision documents the current state of the "abort 386 timeout" proposal. 388 The following people have improved this document through thoughtful 389 suggestions: Mark Allmann, Marcus Brunner, Wesley Eddy, Tom 390 Henderson, Joseph Ishac, Michael Kerrisk, Kostas Pentikousis, Juergen 391 Quittek, Stefan Schmid, Simon Schuetz, and Martin Stiemerling. 393 7. References 395 7.1 Normative References 397 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 398 September 1981. 400 [2] Braden, R., "Requirements for Internet Hosts - Communication 401 Layers", STD 3, RFC 1122, October 1989. 403 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 404 Levels", BCP 14, RFC 2119, March 1997. 406 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 407 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 409 7.2 Informative References 411 [5] "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley , 412 1994. 414 [6] Sun Microsystems, "Solaris Tunable Parameters Reference 415 Manual", Part No. 806-7009-10, 2002. 417 [7] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 418 2002. 420 [8] Moskowitz, R., "Host Identity Protocol Architecture", 421 draft-moskowitz-hip-arch-05 (work in progress), October 2003. 423 [9] Schuetz, S., "Network Support for Intermittently Connected 424 Mobile Nodes", M.S. Thesis, University of Mannheim, Germany, 425 June 2004. 427 [10] Schuetz, S., Eggert, L., Schmid, S. and M. Brunner, "Protocol 428 Enhancements for Intermittently Connected Hosts", under 429 submission (work in progress), July 2004. 431 [11] Ott, J. and D. Kutscher, "Drive-Thru Internet: IEEE 802.11b for 432 Automobile Users", Proc. INFOCOM 2004, March 2004. 434 [12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 435 2246, January 1999. 437 [13] Kent, S. and R. Atkinson, "Security Architecture for the 438 Internet Protocol", RFC 2401, November 1998. 440 [14] Gont, F., "TCP Adaptive User TimeOut (AUTO) Option", 441 draft-gont-tcpm-tcp-auto-option-00 (work in progress), May 442 2004. 444 [15] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 445 Explicit Congestion Notification (ECN) to IP", RFC 3168, 446 September 2001. 448 Author's Address 450 Lars Eggert 451 NEC Network Laboratories 452 Kurfuersten-Anlage 36 453 Heidelberg 69115 454 DE 456 Phone: +49 6221 90511 43 457 Fax: +49 6221 90511 55 458 EMail: lars.eggert@netlab.nec.de 459 URI: http://www.netlab.nec.de/ 461 Appendix A. Document Revision History 463 +-----------+-------------------------------------------------------+ 464 | Revision | Comments | 465 +-----------+-------------------------------------------------------+ 466 | 00 | Initial version. | 467 | 01 | Updated draft based on WG feedback. Also incorporated | 468 | | some ideas from Fernando Gont's "Adaptive User | 469 | | Timeout" proposal [14] that is based on the -00 | 470 | | revision of this document. | 471 +-----------+-------------------------------------------------------+ 473 Intellectual Property Statement 475 The IETF takes no position regarding the validity or scope of any 476 Intellectual Property Rights or other rights that might be claimed to 477 pertain to the implementation or use of the technology described in 478 this document or the extent to which any license under such rights 479 might or might not be available; nor does it represent that it has 480 made any independent effort to identify any such rights. Information 481 on the procedures with respect to rights in RFC documents can be 482 found in BCP 78 and BCP 79. 484 Copies of IPR disclosures made to the IETF Secretariat and any 485 assurances of licenses to be made available, or the result of an 486 attempt made to obtain a general license or permission for the use of 487 such proprietary rights by implementers or users of this 488 specification can be obtained from the IETF on-line IPR repository at 489 http://www.ietf.org/ipr. 491 The IETF invites any interested party to bring to its attention any 492 copyrights, patents or patent applications, or other proprietary 493 rights that may cover technology that may be required to implement 494 this standard. Please address the information to the IETF at 495 ietf-ipr@ietf.org. 497 Disclaimer of Validity 499 This document and the information contained herein are provided on an 500 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 501 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 502 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 503 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 504 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 505 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 507 Copyright Statement 509 Copyright (C) The Internet Society (2004). This document is subject 510 to the rights, licenses and restrictions contained in BCP 78, and 511 except as set forth therein, the authors retain all their rights. 513 Acknowledgment 515 Funding for the RFC Editor function is currently provided by the 516 Internet Society.