idnits 2.17.1 draft-eggert-tsvwg-udp-guidelines-02.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 498. 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 : ---------------------------------------------------------------------------- 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 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 4, 2007) is 6230 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 3448 (Obsoleted by RFC 5348) == Outdated reference: A later version (-01) exists of draft-floyd-dccp-ccid4-00 == Outdated reference: A later version (-05) exists of draft-heffner-frag-harmful-04 == Outdated reference: A later version (-06) exists of draft-ietf-dccp-rfc3448bis-01 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-13 == Outdated reference: A later version (-05) exists of draft-ietf-tcpm-syn-flood-02 -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group L. Eggert 3 Internet-Draft Nokia 4 Intended status: Best Current April 4, 2007 5 Practice 6 Expires: October 6, 2007 8 UDP Usage Guidelines for Application Designers 9 draft-eggert-tsvwg-udp-guidelines-02 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. 17 This document may not be modified, and derivative works of it may not 18 be created, except to publish it as an RFC and to translate it into 19 languages other than English. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on October 6, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 The User Datagram Protocol (UDP) provides a minimal, message-passing 46 transport that has no inherent congestion control mechanisms. 47 Because congestion control is critical to the stable operation of the 48 Internet, applications and upper-layer protocols that choose to use 49 UDP as an Internet transport must employ mechanisms to prevent 50 congestion collapse and establish some degree of fairness with 51 concurrent traffic. This document provides guidelines on the use of 52 UDP for the designers of such applications and upper-layer protocols 53 that cover congestion-control and other topics, including message 54 sizes and reliability. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 5 62 3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 7 63 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 7 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 Intellectual Property and Copyright Statements . . . . . . . . . . 12 73 1. Introduction 75 The User Datagram Protocol (UDP) [RFC0768] provides a minimal, 76 unreliable, message-passing transport to applications and upper-layer 77 protocols (both simply called "applications" in the remainder of this 78 document). Compared to other transport protocols, UDP is unique in 79 that it does not establish end-to-end connections between 80 communicating end systems. UDP communication consequently does not 81 incur connection establishment and teardown overheads and there is no 82 associated end system state. Because of these characteristics, UDP 83 can offer a very efficient communication transport to some 84 applications. 86 A second unique characteristic of UDP is that it provides no inherent 87 congestion control mechanisms. [RFC2914] describes the best current 88 practice for congestion control in the Internet. It identifies two 89 major reasons why congestion control mechanisms are critical for the 90 stable operation of the Internet: 92 1. The prevention of congestion collapse, i.e., a state where an 93 increase in network load results in a decrease in useful work 94 done by the network. 96 2. The establishment of a degree of fairness, i.e., allowing 97 multiple flows to share the capacity of a path reasonably 98 equitably. 100 Because UDP itself provides no congestion control mechanisms, it is 101 up to the applications that use UDP for Internet communication to 102 employ suitable mechanisms to prevent congestion collapse and 103 establish a degree of fairness. [RFC2309] discusses the dangers of 104 congestion-unresponsive flows and states that "all UDP-based 105 streaming applications should incorporate effective congestion 106 avoidance mechanisms." This is an important requirement, even for 107 applications that do not use UDP for streaming. For example, an 108 application that generates five 1500-byte UDP packets in one second 109 can already exceed the capacity of a 56 Kb/s path. For applications 110 that can operate at higher, potentially unbounded data rates, 111 congestion control becomes vital. Section 3 describes a number of 112 simple guidelines for the designers of such applications. 114 A UDP message is carried in a single IP packet and is hence limited 115 to a maximum payload of 65,487 bytes. The transmission of large IP 116 packets frequently requires IP fragmentation, which decreases 117 communication reliability and efficiency and should be avoided 118 [I-D.heffner-frag-harmful]. Some of the guidelines in Section 3 119 describe how applications should determine appropriate message sizes. 121 This document provides guidelines to designers of applications that 122 use UDP for unicast transmission. A special class of applications 123 uses UDP for IP multicast transmissions. Congestion control, flow 124 control or reliability for multicast transmissions is more difficult 125 to establish than for unicast transmissions, because a single sender 126 may transmit to multiple receivers across potentially very 127 heterogeneous paths at the same time. Designing multicast 128 applications requires expertise that goes beyond the simple 129 guidelines given in this document. The IETF has defined a reliable 130 multicast framework [RFC3048] and several building blocks to aid the 131 designers of multicast applications, such as [RFC3738] or [RFC4654]. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in BCP 14, RFC 2119 138 [RFC2119]. 140 3. UDP Usage Guidelines 142 The RECOMMENDED alternative to the UDP usage guidelines described in 143 this section is the use of a transport protocol that is congestion- 144 controlled, such as TCP [RFC0793], SCTP [RFC2960] or DCCP [RFC4340] 145 with its different congestion control types 146 [RFC4341][RFC4342][I-D.floyd-dccp-ccid4]. Congestion control 147 mechanisms are difficult to implement correctly, and for most 148 applications, the use of one of the existing, congestion-controlled 149 protocols is the simplest method of satisfying [RFC2914]. The same 150 is true for message size determination and reliability mechanisms. 152 If used correctly, congestion-controlled transport protocols are not 153 as "heavyweight" as often claimed. For example, TCP with SYN cookies 154 [I-D.ietf-tcpm-syn-flood], which are available on many platforms, 155 does not require a server to maintain per-connection state until the 156 connection is established. TCP also requires the end that closes a 157 connection to maintain the TIME-WAIT state that prevents delayed 158 segments from one connection instance to interfere with a later one. 159 Applications that are aware of this behavior can shift maintenance of 160 the TIME-WAIT state to conserve resources. Finally, TCP's built-in 161 capacity-probing and PMTU awareness results in efficient data 162 transmission that quickly compensates for the initial connection 163 setup delay, for transfers that exchange more than a few packets. 165 3.1. Congestion Control Guidelines 167 If an application or upper-layer protocol chooses not to use a 168 congestion-controlled transport protocol, it SHOULD control the rate 169 at which it sends UDP messages to a destination host. It is 170 important to stress that an application SHOULD perform congestion 171 control over all UDP traffic it sends to a destination, independent 172 of how it generates this traffic. For example, an application that 173 forks multiple worker processes or otherwise uses multiple sockets to 174 generate UDP messages SHOULD perform congestion control over the 175 aggregate traffic. The remainder of this section discusses several 176 approaches for this purpose. 178 It is important to note that congestion control should not be viewed 179 as an add-on to a finished application. Many of the mechanisms 180 discussed in the guidelines below require application support to 181 operate correctly. Application designers need to consider congestion 182 control throughout the design of their application, similar to how 183 they consider security aspects throughout the design process. 185 3.1.1. Bulk Transfer Applications 187 Applications that perform bulk transmission of data to a peer over 188 UDP SHOULD consider implementing TCP-Friendly Rate Control (TFRC) 189 [RFC3448], window-based, TCP-like congestion control, or otherwise 190 ensure that the application complies with the congestion control 191 principles. 193 TFRC has been designed to provide both congestion control and 194 fairness in a way that is compatible with the IETF's other transport 195 protocols. TFRC is currently being updated 196 [I-D.ietf-dccp-rfc3448bis], and application designers SHOULD always 197 evaluate whether the latest published specification fits their needs. 198 If an application implements TFRC, it need not follow the remaining 199 guidelines in Section 3.1, but SHOULD still follow the guidelines on 200 message sizes in Section 3.2 and reliability in Section 3.2. 202 Bulk transfer applications that choose not to implement TFRC or TCP- 203 like windowing SHOULD implement a congestion control scheme that 204 results in bandwidth use that competes fairly with TCP within an 205 order of magnitude. [RFC3551] suggests that applications SHOULD 206 monitor the packet loss rate to ensure that it is within acceptable 207 parameters. Packet loss is considered acceptable if a TCP flow 208 across the same network path under the same network conditions would 209 achieve an average throughput, measured on a reasonable timescale, 210 that is not less than that of the UDP flow. The comparison to TCP 211 cannot be specified exactly, but is intended as an "order-of- 212 magnitude" comparison in timescale and throughput. 214 Finally, some bulk transfer applications chose not to implement any 215 congestion control mechanism and instead rely on transmitting across 216 reserved path capacity. This might be an acceptable choice for a 217 subset of restricted networking environments, but is by no means a 218 safe practice for operation in the Internet. When the UDP traffic of 219 such applications leaks out on unprovisioned paths, results are 220 detrimental. 222 3.1.2. Low Data-Volume Applications 224 Applications that exchange only a small number of messages with a 225 destination at any time may not benefit from implementing TFRC or one 226 of the other congestion control schemes in Section 3.1.1. Such 227 applications SHOULD still control their transmission behavior by not 228 sending more than one UDP message per round-trip time (RTT) to a 229 destination. Similar to the recommendation in [RFC1536], an 230 application SHOULD maintain an estimate of the RTT for any 231 destination it communicates with. Applications SHOULD implement the 232 algorithm specified in [RFC2988] to compute a smoothed RTT (SRTT) 233 estimate. A lost response from the peer SHOULD be treated as a very 234 large RTT sample, instead of being ignored, in order to cause a 235 sufficiently large (exponential) back-off. When implementing this 236 scheme, applications need to choose a sensible initial value for the 237 RTT. This value SHOULD generally be as conservative as possible for 238 the given application. For example, SIP [RFC3261] and GIST 239 [I-D.ietf-nsis-ntlp] use an initial value of 500 ms, and shorter 240 values are likely problematic in many cases. 242 Some applications cannot maintain a reliable RTT estimate for a 243 destination. The first case is applications that exchange too few 244 messages with a peer to establish a statistically accurate RTT 245 estimate. Such applications MAY use a fixed transmission interval 246 that is exponentially backed-off during loss. For example, SIP 247 [RFC3261] and GIST [I-D.ietf-nsis-ntlp] use an interval of 500 ms, 248 and shorter values are likely problematic in many cases. 250 A second class of applications cannot maintain an RTT estimate for a 251 destination, because the destination does not send return traffic. 252 Such applications SHOULD NOT send more than one UDP message every 3 253 seconds. The 3-second interval was chosen based on TCP's 254 retransmission timeout when the RTT is unknown [RFC2988], and shorter 255 values are likely problematic in many cases. Note that this interval 256 must be more conservative than above, because the lack of return 257 traffic prevents the detection of packet loss, i.e., congestion 258 events, and the application therefore cannot perform exponential 259 back-off to reduce load. 261 Applications that communicate bidirectionally SHOULD employ 262 congestion control for both directions of the communication. For 263 example, for a client-server, request-response-style application, 264 clients SHOULD congestion control their request transmission to a 265 server, and the server SHOULD congestion control its responses to the 266 clients. Congestion in the forward and reverse direction is 267 uncorrelated and an application SHOULD independently detect and 268 respond to congestion along both directions. 270 3.2. Message Size Guidelines 272 Because IP fragmentation lowers the efficiency and reliability of 273 Internet communication [I-D.heffner-frag-harmful], an application 274 SHOULD NOT send UDP messages that result in IP packets that exceed 275 the MTU of the path to the destination. Consequently, an application 276 SHOULD either use the path MTU information provided by the IP layer 277 or implement path MTU discovery itself [RFC1191][RFC1981][RFC4821] to 278 determine whether the path to a destination will support its desired 279 message size without fragmentation. 281 Applications that choose not to do so SHOULD NOT send UDP messages 282 that exceed the minimum PMTU. The minimum PMTU depends on the IP 283 version used for transmission, and is the lesser of 576 bytes and the 284 first-hop MTU for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460]. 285 To determine an appropriate UDP payload size, applications must 286 subtract IP header and option lengths as well as the length of the 287 UDP header from the PMTU size. Transmission of minimum-sized 288 messages is inefficient over paths that support a larger PMTU, which 289 is a second reason to implement PMTU discovery. 291 Applications that do not send messages that exceed the minimum PMTU 292 of IPv4 or IPv6 need not implement any of the above mechanisms. 294 3.3. Reliability Guidelines 296 Application designers are generally aware that UDP does not provide 297 any reliability. Often, this is a main reason to consider UDP as a 298 transport. Applications that do require reliable message delivery 299 SHOULD implement an appropriate mechanism themselves. 301 UDP also does not protect against message duplication, i.e., an 302 application may receive multiple copies of the same message. 303 Application designers SHOULD consider whether their application 304 handles message duplication gracefully, and may need to implement 305 mechanisms to detect duplicates. Even if message reception triggers 306 idempotent operations, applications may want to suppress duplicate 307 messages to reduce load. 309 Finally, UDP messages may be reordered in the network and arrive at 310 the receiver in an order different from the send order. Applications 311 that require ordered delivery SHOULD reestablish message ordering 312 themselves. 314 4. Security Considerations 316 [RFC2309] and [RFC2914] discuss the dangers of congestion- 317 unresponsive flows to the Internet. This document provides 318 guidelines to designers of UDP-based applications to congestion- 319 control to their transmissions. As such, it does not raise any 320 additional security concerns. 322 5. IANA Considerations 324 This document raises no IANA considerations. 326 6. Acknowledgments 328 Thanks to Mark Allman, Gorry Fairhurst, Sally Floyd, Joerg Ott, Colin 329 Perkins, Pasi Sarolahti and Magnus Westerlund for their comments on 330 this document. 332 7. References 334 7.1. Normative References 336 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 337 August 1980. 339 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 340 RFC 793, September 1981. 342 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 343 November 1990. 345 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 346 for IP version 6", RFC 1981, August 1996. 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 352 RFC 2914, September 2000. 354 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 355 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 356 Zhang, L., and V. Paxson, "Stream Control Transmission 357 Protocol", RFC 2960, October 2000. 359 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 360 Timer", RFC 2988, November 2000. 362 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 363 Friendly Rate Control (TFRC): Protocol Specification", 364 RFC 3448, January 2003. 366 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 367 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 369 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 370 Discovery", RFC 4821, March 2007. 372 7.2. Informative References 374 [I-D.floyd-dccp-ccid4] 375 Floyd, S. and E. Kohler, "Profile for Datagram Congestion 376 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly 377 Rate Control for Small Packets (TFRC-SP)", 378 draft-floyd-dccp-ccid4-00 (work in progress), 379 November 2006. 381 [I-D.heffner-frag-harmful] 382 Heffner, J., "IPv4 Reassembly Errors at High Data Rates", 383 draft-heffner-frag-harmful-04 (work in progress), 384 January 2007. 386 [I-D.ietf-dccp-rfc3448bis] 387 Handley, M., "TCP Friendly Rate Control (TFRC): Protocol 388 Specification", draft-ietf-dccp-rfc3448bis-01 (work in 389 progress), March 2007. 391 [I-D.ietf-nsis-ntlp] 392 Schulzrinne, H. and R. Hancock, "GIST: General Internet 393 Signalling Transport", draft-ietf-nsis-ntlp-13 (work in 394 progress), April 2007. 396 [I-D.ietf-tcpm-syn-flood] 397 Eddy, W., "TCP SYN Flooding Attacks and Common 398 Mitigations", draft-ietf-tcpm-syn-flood-02 (work in 399 progress), March 2007. 401 [RFC1122] Braden, R., "Requirements for Internet Hosts - 402 Communication Layers", STD 3, RFC 1122, October 1989. 404 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 405 Miller, "Common DNS Implementation Errors and Suggested 406 Fixes", RFC 1536, October 1993. 408 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 409 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 410 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 411 S., Wroclawski, J., and L. Zhang, "Recommendations on 412 Queue Management and Congestion Avoidance in the 413 Internet", RFC 2309, April 1998. 415 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 416 (IPv6) Specification", RFC 2460, December 1998. 418 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 419 Floyd, S., and M. Luby, "Reliable Multicast Transport 420 Building Blocks for One-to-Many Bulk-Data Transfer", 421 RFC 3048, January 2001. 423 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 424 A., Peterson, J., Sparks, R., Handley, M., and E. 425 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 426 June 2002. 428 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 429 Video Conferences with Minimal Control", STD 65, RFC 3551, 430 July 2003. 432 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 433 Control (WEBRC) Building Block", RFC 3738, April 2004. 435 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 436 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 437 Congestion Control", RFC 4341, March 2006. 439 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 440 Datagram Congestion Control Protocol (DCCP) Congestion 441 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 442 March 2006. 444 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 445 Congestion Control (TFMCC): Protocol Specification", 446 RFC 4654, August 2006. 448 Author's Address 450 Lars Eggert 451 Nokia Research Center 452 P.O. Box 407 453 Nokia Group 00045 454 Finland 456 Phone: +358 50 48 24461 457 Email: lars.eggert@nokia.com 458 URI: http://research.nokia.com/people/lars_eggert/ 460 Full Copyright Statement 462 Copyright (C) The IETF Trust (2007). 464 This document is subject to the rights, licenses and restrictions 465 contained in BCP 78, and except as set forth therein, the authors 466 retain all their rights. 468 This document and the information contained herein are provided on an 469 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 470 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 471 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 472 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 473 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 474 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 476 Intellectual Property 478 The IETF takes no position regarding the validity or scope of any 479 Intellectual Property Rights or other rights that might be claimed to 480 pertain to the implementation or use of the technology described in 481 this document or the extent to which any license under such rights 482 might or might not be available; nor does it represent that it has 483 made any independent effort to identify any such rights. Information 484 on the procedures with respect to rights in RFC documents can be 485 found in BCP 78 and BCP 79. 487 Copies of IPR disclosures made to the IETF Secretariat and any 488 assurances of licenses to be made available, or the result of an 489 attempt made to obtain a general license or permission for the use of 490 such proprietary rights by implementers or users of this 491 specification can be obtained from the IETF on-line IPR repository at 492 http://www.ietf.org/ipr. 494 The IETF invites any interested party to bring to its attention any 495 copyrights, patents or patent applications, or other proprietary 496 rights that may cover technology that may be required to implement 497 this standard. Please address the information to the IETF at 498 ietf-ipr@ietf.org. 500 Acknowledgment 502 Funding for the RFC Editor function is provided by the IETF 503 Administrative Support Activity (IASA).