idnits 2.17.1 draft-ietf-tsvwg-udp-guidelines-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 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 659. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 666. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 672. 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 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 (June 11, 2007) is 6164 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 (-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-04 -- 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 (~~), 5 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 G. Fairhurst 5 Practice University of Aberdeen 6 Expires: December 13, 2007 June 11, 2007 8 UDP Usage Guidelines for Application Designers 9 draft-ietf-tsvwg-udp-guidelines-01 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 December 13, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The User Datagram Protocol (UDP) provides a minimal, message-passing 43 transport that has no inherent congestion control mechanisms. 44 Because congestion control is critical to the stable operation of the 45 Internet, applications and upper-layer protocols that choose to use 46 UDP as an Internet transport must employ mechanisms to prevent 47 congestion collapse and establish some degree of fairness with 48 concurrent traffic. This document provides guidelines on the use of 49 UDP for the designers of such applications and upper-layer protocols 50 that cover congestion-control and other topics, including message 51 sizes and reliability. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 5 59 3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 7 60 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 7 61 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 8 62 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 9 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 70 Intellectual Property and Copyright Statements . . . . . . . . . . 15 72 1. Introduction 74 The User Datagram Protocol (UDP) [RFC0768] provides a minimal, 75 unreliable, message-passing transport to applications and upper-layer 76 protocols (both simply called "applications" in the remainder of this 77 document). Compared to other transport protocols, UDP and its UDP- 78 Lite variant [RFC3828] are unique in that they do not establish end- 79 to-end connections between communicating end systems. UDP 80 communication consequently does not incur connection establishment 81 and teardown overheads and there is no associated end system state. 82 Because of these characteristics, UDP can offer a very efficient 83 communication transport to some applications. 85 A second unique characteristic of UDP is that it provides no inherent 86 congestion control mechanisms. [RFC2914] describes the best current 87 practice for congestion control in the Internet. It identifies two 88 major reasons why congestion control mechanisms are critical for the 89 stable operation of the Internet: 91 1. The prevention of congestion collapse, i.e., a state where an 92 increase in network load results in a decrease in useful work 93 done by the network. 95 2. The establishment of a degree of fairness, i.e., allowing 96 multiple flows to share the capacity of a path reasonably 97 equitably. 99 Because UDP itself provides no congestion control mechanisms, it is 100 up to the applications that use UDP for Internet communication to 101 employ suitable mechanisms to prevent congestion collapse and 102 establish a degree of fairness. [RFC2309] discusses the dangers of 103 congestion-unresponsive flows and states that "all UDP-based 104 streaming applications should incorporate effective congestion 105 avoidance mechanisms." This is an important requirement, even for 106 applications that do not use UDP for streaming. For example, an 107 application that generates five 1500-byte UDP packets in one second 108 can already exceed the capacity of a 56 Kb/s path. For applications 109 that can operate at higher, potentially unbounded data rates, 110 congestion control becomes vital to prevent congestion collapse and 111 establish some degree of fairness. 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. TCP uses an initial value of 3 seconds 239 [RFC2988], which is also RECOMMENDED as an initial value for UDP 240 applications. SIP [RFC3261] and GIST [I-D.ietf-nsis-ntlp] use an 241 initial value of 500 ms, and initial timeouts that are shorter than 242 this are likely problematic in many cases. It is also important to 243 note that the initial timeout is not the maximum possible timeout - 244 the RECOMMENDED algorithm in [RFC2988] yields timeout values after a 245 series of losses that are much longer than the initial value. 247 Some applications cannot maintain a reliable RTT estimate for a 248 destination. The first case is applications that exchange too few 249 messages with a peer to establish a statistically accurate RTT 250 estimate. Such applications MAY use a fixed transmission interval 251 that is exponentially backed-off during loss. TCP uses an initial 252 value of 3 seconds [RFC2988], which is also RECOMMENDED as an initial 253 value for UDP applications. SIP [RFC3261] and GIST 254 [I-D.ietf-nsis-ntlp] use an interval of 500 ms, and shorter values 255 are likely problematic in many cases. As in the previous case, note 256 that the initial timeout is not the maximum possible timeout. 258 A second class of applications cannot maintain an RTT estimate for a 259 destination, because the destination does not send return traffic. 260 Such applications SHOULD NOT send more than one UDP message every 3 261 seconds, and SHOULD consider if they can use an even less aggressive 262 rate when possible. The 3-second interval was chosen based on TCP's 263 retransmission timeout when the RTT is unknown [RFC2988], and shorter 264 values are likely problematic in many cases. Note that the initial 265 timeout interval must be more conservative than in the two previous 266 cases, because the lack of return traffic prevents the detection of 267 packet loss, i.e., congestion events, and the application therefore 268 cannot perform exponential back-off to reduce load. 270 Applications that communicate bidirectionally SHOULD employ 271 congestion control for both directions of the communication. For 272 example, for a client-server, request-response-style application, 273 clients SHOULD congestion control their request transmission to a 274 server, and the server SHOULD congestion control its responses to the 275 clients. Congestion in the forward and reverse direction is 276 uncorrelated and an application SHOULD independently detect and 277 respond to congestion along both directions. 279 3.2. Message Size Guidelines 281 Because IP fragmentation lowers the efficiency and reliability of 282 Internet communication [I-D.heffner-frag-harmful], an application 283 SHOULD NOT send UDP messages that result in IP packets that exceed 284 the MTU of the path to the destination. Consequently, an application 285 SHOULD either use the path MTU information provided by the IP layer 286 or implement path MTU discovery itself [RFC1191][RFC1981][RFC4821] to 287 determine whether the path to a destination will support its desired 288 message size without fragmentation. 290 Applications that choose not to do so SHOULD NOT send UDP messages 291 that exceed the minimum PMTU. The minimum PMTU depends on the IP 292 version used for transmission, and is the lesser of 576 bytes and the 293 first-hop MTU for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460]. 294 To determine an appropriate UDP payload size, applications must 295 subtract IP header and option lengths as well as the length of the 296 UDP header from the PMTU size. Transmission of minimum-sized 297 messages is inefficient over paths that support a larger PMTU, which 298 is a second reason to implement PMTU discovery. 300 Applications that do not send messages that exceed the minimum PMTU 301 of IPv4 or IPv6 need not implement any of the above mechanisms. 303 3.3. Reliability Guidelines 305 Application designers are generally aware that UDP does not provide 306 any reliability. Often, this is a main reason to consider UDP as a 307 transport. Applications that do require reliable message delivery 308 SHOULD implement an appropriate mechanism themselves. 310 UDP also does not protect against message duplication, i.e., an 311 application may receive multiple copies of the same message. 312 Application designers SHOULD consider whether their application 313 handles message duplication gracefully, and may need to implement 314 mechanisms to detect duplicates. Even if message reception triggers 315 idempotent operations, applications may want to suppress duplicate 316 messages to reduce load. 318 Finally, UDP messages may be reordered in the network and arrive at 319 the receiver in an order different from the send order. Applications 320 that require ordered delivery SHOULD reestablish message ordering 321 themselves. 323 3.4. Checksum Guidelines 325 The UDP header includes a 16-bit ones' complement checksum that 326 provides an integrity check. The UDP checksum provides assurance 327 that the payload was not corrupted in transit. It also verifies that 328 the datagram was delivered to the intended end point, because it 329 covers the IP addresses, port numbers and protocol number, and it 330 verifies that the datagram is not truncated or padded, because it 331 covers the size field. It therefore protects an application against 332 receiving corrupted payload data in place of, or in addition to, the 333 data that was sent. 335 Applications SHOULD enable UDP checksums, although [RFC0793] permits 336 the option to disable their use. Applications that choose to disable 337 UDP checksums when transmitting over IPv4 therefore MUST NOT make 338 assumptions regarding the correctness of received data and MUST 339 behave correctly when a packet is received that was originally sent 340 to a different end point or is otherwise corrupted. The use of the 341 UDP checksum is MANDATORY when applications transmit UDP over IPv6 342 [RFC2460] and applications consequently MUST NOT disable their use. 343 (The IPv6 header does not have a separate checksum field to protect 344 the IP addressing information.) 346 The UDP checksum provides relatively weak protection from a coding 347 point of view [RFC3819] and, where appropriate, applications 348 developers SHOULD provide additional checks, e.g., through a CRC 349 included with the data to verify the integrity of an entire object/ 350 file sent over UDP service. 352 3.4.1. UDP-Lite 354 A special class of applications derive benefit from having partially 355 damaged payloads delivered rather than discarded when using paths 356 that include error-prone links. Such applications can tolerate 357 payload corruption and MAY choose to use the Lightweight User 358 Datagram Protocol (UDP-Lite) [RFC3828] variant of UDP instead of 359 basic UDP. Applications that choose to use UDP-Lite instead of UDP 360 MUST still follow the congestion control and other guidelines 361 described for use with UDP in Section 3.1. 363 UDP-Lite changes the semantics of the UDP "payload length" field to 364 that of a "checksum coverage length" field. Otherwise, UDP-Lite is 365 semantically identical to UDP. The interface of UDP-Lite differs 366 from that of UDP by the addition of a single (socket) option that 367 communicates a checksum coverage length value: at the sender, this 368 specifies the intended datagram checksum coverage, with the remaining 369 unprotected part of the payload called the "error insensitive part". 370 If required, an application may dynamically modify this length value, 371 e.g., to offer greater protection to some packets. UDP-Lite always 372 verifies that a datagram was delivered to the intended end point, 373 i.e., always verifies the header fields. Errors in the insensitive 374 part will not cause a packet to be discarded by the receiving end 375 host. Applications using UDP-Lite therefore MUST NOT make 376 assumptions regarding the correctness of the data received in the 377 insensitive part of the UDP-Lite payload. 379 The sending application SHOULD select the minimum checksum coverage 380 to include all sensitive protocol headers (e.g., the RTP header), 381 and, where appropriate, MUST also introduce their own appropriate 382 validity checks for protocol information carried in the insensitive 383 part of the UDP-Lite payload (e.g., internal CRCs). 385 The receiver MUST set a minimum coverage threshold for incoming 386 datagrams that is not smaller than the smallest coverage used by the 387 sender. This may be a fixed value, or may be negotiated by an 388 application. UDP-Lite does not provide mechanisms to negotiate the 389 checksum coverage between the sender and receiver. 391 Applications may still experience packet loss, rather than 392 corruption, when using UDP-Lite. The enhancements offered by UDP- 393 Lite rely upon a link being able to intercept the UDP-Lite header to 394 correctly identify the partial-coverage required. When tunnels 395 and/or encryption are used, this can result in UDP-Lite packets being 396 treated the same as UDP packets, i.e., result in packet loss. Use of 397 IP fragmentation can also prevent special treatment for UDP-Lite 398 packets, and is another reason why applications SHOULD avoid IP 399 fragmentation Section 3.2. 401 3.5. Middlebox Traversal Guidelines 403 Network address translators (NATs) and firewalls are examples of 404 intermediary devices ("middleboxes") that can exist along an end-to- 405 end path. A middlebox typically perform a function that requires it 406 to maintain per-flow state. For connection-oriented protocols, such 407 as TCP, middleboxes snoop and parse the connection-management traffic 408 and create and destroy per-flow state accordingly. For a 409 connectionless protocol such as UDP, this approach is not possible. 410 Consequently, middleboxes may create per-flow state when they see a 411 packet that indicates a new flow, and destroy the state after some 412 period of time during which no packets belonging to the same flow 413 have arrived. 415 Depending on the specific function that the middlebox performs, this 416 behavior can introduce a time-dependency that restricts the kinds of 417 UDP traffic exchanges that will be successful across it. For 418 example, NATs and firewalls typically define the partial path on one 419 side of them to be interior to the domain they control, whereas the 420 partial path on their other side is defined to be exterior to that 421 domain. Per-flow state is typically created when the first packet 422 crosses from the interior to the exterior, and while the state is 423 present, NATs and firewalls will forward return traffic. Return 424 traffic arriving after the per-flow state has timed out is dropped, 425 as is other traffic arriving from the exterior. 427 Many applications use UDP for communication operate across 428 middleboxes without needing to employ additional mechanisms. One 429 example is the DNS, which has a strict request-response communication 430 pattern that typically completes within seconds. 432 Other applications may experience communication failures when 433 middleboxes destroy the per-flow state associated with an application 434 session during periods when the application does not exchange any UDP 435 traffic. Applications SHOULD be able to gracefully handle such 436 communication failures and implement mechanisms to re-establish their 437 UDP sessions. 439 Applications MAY in addition send periodic keep-alive messages to 440 attempt to refresh middlebox state. Unfortunately, no common timeout 441 has been specified for per-flow UDP state for arbitrary middleboxes. 442 For NATs, [RFC4787] requires a state timeout of 2 minutes or longer, 443 and it is likely that other types of middleboxes use timeouts of 444 similar timescales. Consequently, if applications choose to send 445 periodic keep-alives, they SHOULD NOT send them more frequently than 446 once every two minutes. 448 It is important to note that sending keep-alives is not a substitute 449 for implementing a robust connection handling. Like all UDP 450 messages, keep-alives can be delayed or dropped, causing middlebox 451 state to time out. In addition, the congestion control guidelines in 452 Section 3.1 cover all UDP transmissions by an application, including 453 the transmission of middlebox keep-alives. Congestion control may 454 thus lead to delays or temporary suspension of keep-alive 455 transmission. 457 4. Security Considerations 459 [RFC2309] and [RFC2914] discuss the dangers of congestion- 460 unresponsive flows to the Internet. This document provides 461 guidelines to designers of UDP-based applications to congestion- 462 control their transmissions. As such, it does not raise any 463 additional security concerns. 465 5. IANA Considerations 467 This document raises no IANA considerations. 469 6. Acknowledgments 471 Thanks to Mark Allman, Sally Floyd, Joerg Ott, Colin Perkins, Pasi 472 Sarolahti and Magnus Westerlund for their comments on this document. 474 The middlebox traversal guidelines in Section 3.5 incorporate ideas 475 from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda Srisuresh 476 and Dan Kegel. 478 7. References 480 7.1. Normative References 482 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 483 August 1980. 485 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 486 RFC 793, September 1981. 488 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 489 November 1990. 491 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 492 for IP version 6", RFC 1981, August 1996. 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, March 1997. 497 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 498 RFC 2914, September 2000. 500 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 501 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 502 Zhang, L., and V. Paxson, "Stream Control Transmission 503 Protocol", RFC 2960, October 2000. 505 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 506 Timer", RFC 2988, November 2000. 508 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 509 Friendly Rate Control (TFRC): Protocol Specification", 510 RFC 3448, January 2003. 512 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 513 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 514 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 515 RFC 3819, July 2004. 517 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 518 G. Fairhurst, "The Lightweight User Datagram Protocol 519 (UDP-Lite)", RFC 3828, July 2004. 521 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 522 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 524 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 525 Discovery", RFC 4821, March 2007. 527 7.2. Informative References 529 [I-D.floyd-dccp-ccid4] 530 Floyd, S. and E. Kohler, "Profile for Datagram Congestion 531 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly 532 Rate Control for Small Packets (TFRC-SP)", 533 draft-floyd-dccp-ccid4-00 (work in progress), 534 November 2006. 536 [I-D.ford-behave-app] 537 Ford, B., "Application Design Guidelines for Traversal 538 through Network Address Translators", 539 draft-ford-behave-app-05 (work in progress), March 2007. 541 [I-D.heffner-frag-harmful] 542 Heffner, J., "IPv4 Reassembly Errors at High Data Rates", 543 draft-heffner-frag-harmful-05 (work in progress), 544 May 2007. 546 [I-D.ietf-dccp-rfc3448bis] 547 Handley, M., "TCP Friendly Rate Control (TFRC): Protocol 548 Specification", draft-ietf-dccp-rfc3448bis-01 (work in 549 progress), March 2007. 551 [I-D.ietf-nsis-ntlp] 552 Schulzrinne, H. and R. Hancock, "GIST: General Internet 553 Signalling Transport", draft-ietf-nsis-ntlp-13 (work in 554 progress), April 2007. 556 [I-D.ietf-tcpm-syn-flood] 557 Eddy, W., "TCP SYN Flooding Attacks and Common 558 Mitigations", draft-ietf-tcpm-syn-flood-04 (work in 559 progress), May 2007. 561 [RFC1122] Braden, R., "Requirements for Internet Hosts - 562 Communication Layers", STD 3, RFC 1122, October 1989. 564 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 565 Miller, "Common DNS Implementation Errors and Suggested 566 Fixes", RFC 1536, October 1993. 568 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 569 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 570 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 571 S., Wroclawski, J., and L. Zhang, "Recommendations on 572 Queue Management and Congestion Avoidance in the 573 Internet", RFC 2309, April 1998. 575 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 576 (IPv6) Specification", RFC 2460, December 1998. 578 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 579 Floyd, S., and M. Luby, "Reliable Multicast Transport 580 Building Blocks for One-to-Many Bulk-Data Transfer", 581 RFC 3048, January 2001. 583 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 584 A., Peterson, J., Sparks, R., Handley, M., and E. 585 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 586 June 2002. 588 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 589 Video Conferences with Minimal Control", STD 65, RFC 3551, 590 July 2003. 592 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 593 Control (WEBRC) Building Block", RFC 3738, April 2004. 595 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 596 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 597 Congestion Control", RFC 4341, March 2006. 599 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 600 Datagram Congestion Control Protocol (DCCP) Congestion 601 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 602 March 2006. 604 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 605 Congestion Control (TFMCC): Protocol Specification", 606 RFC 4654, August 2006. 608 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 609 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 610 RFC 4787, January 2007. 612 Authors' Addresses 614 Lars Eggert 615 Nokia Research Center 616 P.O. Box 407 617 Nokia Group 00045 618 Finland 620 Phone: +358 50 48 24461 621 Email: lars.eggert@nokia.com 622 URI: http://research.nokia.com/people/lars_eggert/ 624 Godred Fairhurst 625 University of Aberdeen 626 Department of Engineering 627 Fraser Noble Building 628 Aberdeen AB24 3UE 629 Scotland 631 Email: gorry@erg.abdn.ac.uk 632 URI: http://www.erg.abdn.ac.uk/ 634 Full Copyright Statement 636 Copyright (C) The IETF Trust (2007). 638 This document is subject to the rights, licenses and restrictions 639 contained in BCP 78, and except as set forth therein, the authors 640 retain all their rights. 642 This document and the information contained herein are provided on an 643 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 644 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 645 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 646 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 647 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 648 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 650 Intellectual Property 652 The IETF takes no position regarding the validity or scope of any 653 Intellectual Property Rights or other rights that might be claimed to 654 pertain to the implementation or use of the technology described in 655 this document or the extent to which any license under such rights 656 might or might not be available; nor does it represent that it has 657 made any independent effort to identify any such rights. Information 658 on the procedures with respect to rights in RFC documents can be 659 found in BCP 78 and BCP 79. 661 Copies of IPR disclosures made to the IETF Secretariat and any 662 assurances of licenses to be made available, or the result of an 663 attempt made to obtain a general license or permission for the use of 664 such proprietary rights by implementers or users of this 665 specification can be obtained from the IETF on-line IPR repository at 666 http://www.ietf.org/ipr. 668 The IETF invites any interested party to bring to its attention any 669 copyrights, patents or patent applications, or other proprietary 670 rights that may cover technology that may be required to implement 671 this standard. Please address the information to the IETF at 672 ietf-ipr@ietf.org. 674 Acknowledgment 676 Funding for the RFC Editor function is provided by the IETF 677 Administrative Support Activity (IASA).