idnits 2.17.1 draft-ietf-tsvwg-udp-guidelines-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 932. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 950. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 956. 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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (September 19, 2007) is 6063 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) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) == Outdated reference: A later version (-06) exists of draft-ietf-dccp-rfc3448bis-02 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-18 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-15 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-14 == Outdated reference: A later version (-05) exists of draft-wing-behave-nat-control-stun-usage-03 -- Obsolete informational reference (is this intentional?): RFC 896 (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 12 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: March 22, 2008 September 19, 2007 8 UDP Usage Guidelines for Application Designers 9 draft-ietf-tsvwg-udp-guidelines-03 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 March 22, 2008. 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 Congestion control guidelines are a primary focus, but the document 51 also provides guidance on other topics, including message sizes, 52 reliability, checksums and middlebox traversal. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 5 60 3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 8 61 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 9 62 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 9 63 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 11 64 3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 12 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 73 Intellectual Property and Copyright Statements . . . . . . . . . . 21 75 1. Introduction 77 The User Datagram Protocol (UDP) [RFC0768] provides a minimal, 78 unreliable, best-effort, message-passing transport to applications 79 and upper-layer protocols (both simply called "applications" in the 80 remainder of this document). Compared to other transport protocols, 81 UDP and its UDP-Lite variant [RFC3828] are unique in that they do not 82 establish end-to-end connections between communicating end systems. 83 UDP communication consequently does not incur connection 84 establishment and teardown overheads and there is no associated end 85 system state. Because of these characteristics, UDP can offer a very 86 efficient communication transport to some applications. 88 A second unique characteristic of UDP is that it provides no inherent 89 congestion control mechanisms. On many platforms, applications can 90 send UDP messages at the line rate of the link interface, which is 91 often much greater than the available path capacity, and doing so 92 contributes to congestion along the path. [RFC2914] describes the 93 best current practice for congestion control in the Internet. It 94 identifies two major reasons why congestion control mechanisms are 95 critical for the stable operation of the Internet: 97 1. The prevention of congestion collapse, i.e., a state where an 98 increase in network load results in a decrease in useful work 99 done by the network. 101 2. The establishment of a degree of fairness, i.e., allowing 102 multiple flows to share the capacity of a path reasonably 103 equitably. 105 Because UDP itself provides no congestion control mechanisms, it is 106 up to the applications that use UDP for Internet communication to 107 employ suitable mechanisms to prevent congestion collapse and 108 establish a degree of fairness. [RFC2309] discusses the dangers of 109 congestion-unresponsive flows and states that "all UDP-based 110 streaming applications should incorporate effective congestion 111 avoidance mechanisms." This is an important requirement, even for 112 applications that do not use UDP for streaming. For example, an 113 application that generates five 1500-byte UDP messages in one second 114 can already exceed the capacity of a 56 Kb/s path. For applications 115 that can operate at higher, potentially unbounded data rates, 116 congestion control becomes vital to prevent congestion collapse and 117 establish some degree of fairness. Section 3 describes a number of 118 simple guidelines for the designers of such applications. 120 A UDP message is carried in a single IP packet and is hence limited 121 to a maximum payload of 65,487 bytes. The transmission of large IP 122 packets usually requires IP fragmentation, which decreases 123 communication reliability and efficiency and should be avoided. One 124 reason for this decrease in reliability is that many NATs and 125 firewalls do not forward IP fragments; other reasons are documented 126 in [RFC4963]. Some of the guidelines in Section 3 describe how 127 applications should determine appropriate message sizes. 129 This document provides guidelines to designers of applications that 130 use UDP for unicast transmission. A special class of applications 131 uses UDP for IP multicast transmissions. Congestion control, flow 132 control or reliability for multicast transmissions is more difficult 133 to establish than for unicast transmissions, because a single sender 134 may transmit to multiple receivers across potentially very 135 heterogeneous paths at the same time. Designing multicast 136 applications requires expertise that goes beyond the simple 137 guidelines given in this document. The IETF has defined a reliable 138 multicast framework [RFC3048] and several building blocks to aid the 139 designers of multicast applications, such as [RFC3738] or [RFC4654]. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in BCP 14, RFC 2119 146 [RFC2119]. 148 3. UDP Usage Guidelines 150 Internet paths can have widely varying characteristics, including 151 transmission delays, available bandwidths, congestion levels, 152 reordering probabilities, supported message sizes or loss rates. 153 Furthermore, the same Internet path can have very different 154 conditions over time. Consequently, applications that may be used on 155 the Internet MUST NOT make assumptions about specific path 156 characteristics. They MUST instead use mechanisms that let them 157 operate safely under very different path conditions. Typically, this 158 requires conservatively probing the Internet path to establish a 159 transmission behavior that it can sustain and that is reasonably fair 160 to other traffic sharing the path. 162 These mechanisms are difficult to implement correctly. For most 163 applications, the use of one of the existing IETF transport protocols 164 is the simplest method of acquiring the required mechanisms. 165 Consequently, the RECOMMENDED alternative to the UDP usage described 166 in the remainder of this section is the use of an IETF transport 167 protocol such as TCP [RFC0793], SCTP [RFC2960] or DCCP [RFC4340] with 168 its different congestion control types 170 [RFC4341][RFC4342][I-D.floyd-dccp-ccid4]. 172 If used correctly, these more fully-featured transport protocols are 173 not as "heavyweight" as often claimed. For example, TCP's "Nagle" 174 algorithm [RFC0896] can be disabled, improving communication latency 175 at the expense of more frequent - but still congestion-controlled - 176 packet transmissions. Another example is the TCP SYN Cookie 177 mechanism [RFC4987], which is available on many platforms. TCP with 178 SYN Cookies does not require a server to maintain per-connection 179 state until the connection is established. TCP also requires the end 180 that closes a connection to maintain the TIME-WAIT state that 181 prevents delayed segments from one connection instance to interfere 182 with a later one. Applications that are aware of and designed for 183 this behavior can shift maintenance of the TIME-WAIT state to 184 conserve resources by controlling which end closes a TCP connection 185 [FABER]. Finally, TCP's built-in capacity-probing and awareness of 186 the maximum transmission unit supported by the path (PMTU) results in 187 efficient data transmission that quickly compensates for the initial 188 connection setup delay, for transfers that exchange more than a few 189 messages. 191 3.1. Congestion Control Guidelines 193 If an application or upper-layer protocol chooses not to use a 194 congestion-controlled transport protocol, it SHOULD control the rate 195 at which it sends UDP messages to a destination host, in order to 196 fulfill the requirements of [RFC2914]. It is important to stress 197 that an application SHOULD perform congestion control over all UDP 198 traffic it sends to a destination, independently from how it 199 generates this traffic. For example, an application that forks 200 multiple worker processes or otherwise uses multiple sockets to 201 generate UDP messages SHOULD perform congestion control over the 202 aggregate traffic. 204 The remainder of this section discusses several approaches for this 205 purpose. Not all approaches discussed below are appropriate for all 206 UDP-transmitting applications. Section 3.1.1 discusses congestion 207 control options for applications that perform bulk transfers over 208 UDP. Such applications can employ schemes that sample the path over 209 several subsequent RTTs during which data is exchanged, in order to 210 determine a sending rate that the path at its current load can 211 support. Other applications only exchange a few UDP messages with a 212 destination. Section 3.1.2 discusses congestion control options for 213 such "low data-volume" applications. Because they typically do not 214 transmit enough data to iteratively sample the path to determine a 215 safe sending rate, they need to employ different kinds of congestion 216 control mechanisms. 218 It is important to note that congestion control should not be viewed 219 as an add-on to a finished application. Many of the mechanisms 220 discussed in the guidelines below require application support to 221 operate correctly. Application designers need to consider congestion 222 control throughout the design of their application, similar to how 223 they consider security aspects throughout the design process. 225 Finally, in the past, the IETF has investigated integrated congestion 226 control mechanisms that act on the traffic aggregate between two 227 hosts, i.e., across all communication sessions active at a given time 228 independent of specific transport protocols, such as the Congestion 229 Manager [RFC3124]. Such mechanisms have failed to see deployment, 230 but would otherwise also fulfill the congestion control requirements 231 in [RFC2914], because they provide congestion control for UDP 232 sessions. 234 3.1.1. Bulk Transfer Applications 236 Applications that perform bulk transmission of data to a peer over 237 UDP, i.e., applications that exchange more than a small number of 238 messages per RTT, SHOULD implement TCP-Friendly Rate Control (TFRC) 239 [RFC3448], window-based, TCP-like congestion control, or otherwise 240 ensure that the application complies with the congestion control 241 principles. 243 TFRC has been designed to provide both congestion control and 244 fairness in a way that is compatible with the IETF's other transport 245 protocols. TFRC is currently being updated 246 [I-D.ietf-dccp-rfc3448bis], and application designers SHOULD always 247 evaluate whether the latest published specification fits their needs. 248 If an application implements TFRC, it need not follow the remaining 249 guidelines in Section 3.1, because TFRC already addresses them, but 250 SHOULD still follow the remaining guidelines in the subsequent 251 subsections of Section 3. 253 Bulk transfer applications that choose not to implement TFRC or TCP- 254 like windowing SHOULD implement a congestion control scheme that 255 results in bandwidth use that competes fairly with TCP within an 256 order of magnitude. [RFC3551] suggests that applications SHOULD 257 monitor the packet loss rate to ensure that it is within acceptable 258 parameters. Packet loss is considered acceptable if a TCP flow 259 across the same network path under the same network conditions would 260 achieve an average throughput, measured on a reasonable timescale, 261 that is not less than that of the UDP flow. The comparison to TCP 262 cannot be specified exactly, but is intended as an "order-of- 263 magnitude" comparison in timescale and throughput. 265 Finally, some bulk transfer applications chose not to implement any 266 congestion control mechanism and instead rely on transmitting across 267 reserved path capacity. This might be an acceptable choice for a 268 subset of restricted networking environments, but is by no means a 269 safe practice for operation in the Internet. When the UDP traffic of 270 such applications leaks out on unprovisioned Internet paths, if can 271 significantly degrade the performance of other traffic sharing the 272 path and even result in congestion collapse. Applications that 273 support an uncontrolled or unadaptive transmission behavior SHOULD 274 NOT do so by default and SHOULD instead require users to explicitly 275 enable this mode of operation. 277 3.1.2. Low Data-Volume Applications 279 When applications that exchange only a small number of messages with 280 a destination at any time implement TFRC or one of the other 281 congestion control schemes in Section 3.1.1, the network sees little 282 benefit, because those mechanisms perform congestion control in a way 283 that is only effective for longer transmissions. 285 Applications that exchange only a small number of messages with a 286 destination at any time SHOULD still control their transmission 287 behavior by not sending more than one UDP message per round-trip time 288 (RTT) to a destination. Similar to the recommendation in [RFC1536], 289 an application SHOULD maintain an estimate of the RTT for any 290 destination with which it communicates. Applications SHOULD 291 implement the algorithm specified in [RFC2988] to compute a smoothed 292 RTT (SRTT) estimate. A lost response from the peer SHOULD be treated 293 as a very large RTT sample, instead of being ignored, in order to 294 cause a sufficiently large (exponential) back-off. When implementing 295 this scheme, applications need to choose a sensible initial value for 296 the RTT. This value SHOULD generally be as conservative as possible 297 for the given application. TCP uses an initial value of 3 seconds 298 [RFC2988], which is also RECOMMENDED as an initial value for UDP 299 applications. SIP [RFC3261] and GIST [I-D.ietf-nsis-ntlp] use an 300 initial value of 500 ms, and initial timeouts that are shorter than 301 this are likely problematic in many cases. It is also important to 302 note that the initial timeout is not the maximum possible timeout - 303 the RECOMMENDED algorithm in [RFC2988] yields timeout values after a 304 series of losses that are much longer than the initial value. 306 Some applications cannot maintain a reliable RTT estimate for a 307 destination. The first case is applications that exchange too few 308 messages with a peer to establish a statistically accurate RTT 309 estimate. Such applications MAY use a fixed transmission interval 310 that is exponentially backed-off during loss. TCP uses an initial 311 value of 3 seconds [RFC2988], which is also RECOMMENDED as an initial 312 value for UDP applications. SIP [RFC3261] and GIST 313 [I-D.ietf-nsis-ntlp] use an interval of 500 ms, and shorter values 314 are likely problematic in many cases. As in the previous case, note 315 that the initial timeout is not the maximum possible timeout. 317 A second class of applications cannot maintain an RTT estimate for a 318 destination, because the destination does not send return traffic. 319 Such applications SHOULD NOT send more than one UDP message every 3 320 seconds, and SHOULD use an even less aggressive rate when possible. 321 The 3-second interval was chosen based on TCP's retransmission 322 timeout when the RTT is unknown [RFC2988], and shorter values are 323 likely problematic in many cases. Note that the initial timeout 324 interval must be more conservative than in the two previous cases, 325 because the lack of return traffic prevents the detection of packet 326 loss, i.e., congestion events, and the application therefore cannot 327 perform exponential back-off to reduce load. 329 Applications that communicate bidirectionally SHOULD employ 330 congestion control for both directions of the communication. For 331 example, for a client-server, request-response-style application, 332 clients SHOULD congestion control their request transmission to a 333 server, and the server SHOULD congestion-control its responses to the 334 clients. Congestion in the forward and reverse direction is 335 uncorrelated and an application SHOULD independently detect and 336 respond to congestion along both directions. 338 3.2. Message Size Guidelines 340 Because IP fragmentation lowers the efficiency and reliability of 341 Internet communication [RFC4963], an application SHOULD NOT send UDP 342 messages that result in IP packets that exceed the MTU of the path to 343 the destination. Consequently, an application SHOULD either use the 344 path MTU information provided by the IP layer or implement path MTU 345 discovery itself [RFC1191][RFC1981][RFC4821] to determine whether the 346 path to a destination will support its desired message size without 347 fragmentation. 349 Applications that choose to not adapt their transmit message size 350 SHOULD NOT send UDP messages that exceed the minimum PMTU. The 351 minimum PMTU depends on the IP version used for transmission, and is 352 the lesser of 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 353 1280 bytes for IPv6 [RFC2460]. To determine an appropriate UDP 354 payload size, applications must subtract IP header and option lengths 355 as well as the length of the UDP header from the PMTU size. 356 Transmission of minimum-sized messages is inefficient over paths that 357 support a larger PMTU, which is a second reason to implement PMTU 358 discovery. 360 Applications that do not send messages that exceed the minimum PMTU 361 of IPv4 or IPv6 need not implement any of the above mechanisms. Note 362 that the presence of tunnels can cause fragmentation even when 363 applications send messages that do not exceed the minimum PMTU, so 364 implementing PMTU discovery will still be beneficial in some cases. 366 3.3. Reliability Guidelines 368 Application designers are generally aware that UDP does not provide 369 any reliability. Often, this is a main reason to consider UDP as a 370 transport. Applications that do require reliable message delivery 371 SHOULD implement an appropriate mechanism themselves. 373 UDP also does not protect against message duplication, i.e., an 374 application may receive multiple copies of the same message. 375 Application designers SHOULD verify that their application handles 376 message duplication gracefully, and may consequently need to 377 implement mechanisms to detect duplicates. Even if message reception 378 triggers idempotent operations, applications may want to suppress 379 duplicate messages to reduce load. 381 Finally, the Internet can significantly delay some packets with 382 respect to others, e.g., due to routing transients, intermittent 383 connectivity, or mobility. This can cause message reordering, where 384 UDP messages arrive at the receiver in an order different from the 385 transmission order. Applications that require ordered delivery 386 SHOULD reestablish message ordering themselves. Furthermore, it is 387 important to note that delay spikes can be very large. This can 388 cause reordered packets to arrive many seconds after they were sent. 389 The Internet protocol suite defines the Maximum Segment Lifetime 390 (MSL) as 2 minutes [RFC0793]. This is the maximum delay a packet 391 should experience. Applications SHOULD be robust to the reception of 392 delayed or duplicate packets that are received within this two minute 393 interval. 395 3.4. Checksum Guidelines 397 The UDP header includes an optional, 16-bit ones' complement checksum 398 that provides an integrity check. The UDP checksum provides 399 assurance that the payload was not corrupted in transit. It also 400 verifies that the packet was delivered to the intended destination, 401 because it covers the IP addresses, port numbers and protocol number, 402 and it verifies that the packet is not truncated or padded, because 403 it covers the size field. It therefore protects an application 404 against receiving corrupted payload data in place of, or in addition 405 to, the data that was sent. 407 Applications SHOULD enable UDP checksums, although [RFC0793] permits 408 the option to disable their use. Applications that choose to disable 409 UDP checksums when transmitting over IPv4 therefore MUST NOT make 410 assumptions regarding the correctness of received data and MUST 411 behave correctly when a message is received that was originally sent 412 to a different destination or is otherwise corrupted. The use of the 413 UDP checksum is MANDATORY when applications transmit UDP over IPv6 414 [RFC2460] and applications consequently MUST NOT disable their use. 415 (The IPv6 header does not have a separate checksum field to protect 416 the IP addressing information.) 418 The UDP checksum provides relatively weak protection from a coding 419 point of view [RFC3819] and, where data integrity is important, 420 application developers SHOULD provide additional checks, e.g., 421 through a Cyclic Redundancy Check (CRC) included with the data to 422 verify the integrity of an entire object/file sent over UDP service. 424 3.4.1. UDP-Lite 426 A special class of applications can derive benefit from having 427 partially damaged payloads delivered, rather than discarded, when 428 using paths that include error-prone links. Such applications can 429 tolerate payload corruption and MAY choose to use the Lightweight 430 User Datagram Protocol (UDP-Lite) [RFC3828] variant of UDP instead of 431 basic UDP. Applications that choose to use UDP-Lite instead of UDP 432 MUST still follow the congestion control and other guidelines 433 described for use with UDP in Section 3.1. 435 UDP-Lite changes the semantics of the UDP "payload length" field to 436 that of a "checksum coverage length" field. Otherwise, UDP-Lite is 437 semantically identical to UDP. The interface of UDP-Lite differs 438 from that of UDP by the addition of a single (socket) option that 439 communicates a checksum coverage length value: at the sender, this 440 specifies the intended checksum coverage, with the remaining 441 unprotected part of the payload called the "error insensitive part". 442 If required, an application may dynamically modify this length value, 443 e.g., to offer greater protection to some messages. UDP-Lite always 444 verifies that a packet was delivered to the intended destination, 445 i.e., always verifies the header fields. Errors in the insensitive 446 part will not cause a UDP message to be discarded by the destination. 447 Applications using UDP-Lite therefore MUST NOT make assumptions 448 regarding the correctness of the data received in the insensitive 449 part of the UDP-Lite payload. 451 The sending application SHOULD select the minimum checksum coverage 452 to include all sensitive protocol headers. For example, applications 453 that use the Real-Time Protocol (RTP) [RFC3550] will likely want to 454 protect the RTP header against corruption. Applications, where 455 appropriate, MUST also introduce their own appropriate validity 456 checks for protocol information carried in the insensitive part of 457 the UDP-Lite payload (e.g., internal CRCs). 459 The receiver MUST set a minimum coverage threshold for incoming 460 packets that is not smaller than the smallest coverage used by the 461 sender. This may be a fixed value, or may be negotiated by an 462 application. UDP-Lite does not provide mechanisms to negotiate the 463 checksum coverage between the sender and receiver. 465 Applications may still experience packet loss, rather than 466 corruption, when using UDP-Lite. The enhancements offered by UDP- 467 Lite rely upon a link being able to intercept the UDP-Lite header to 468 correctly identify the partial-coverage required. When tunnels 469 and/or encryption are used, this can result in UDP-Lite messages 470 being treated the same as UDP messages, i.e., result in packet loss. 471 Use of IP fragmentation can also prevent special treatment for UDP- 472 Lite messages, and is another reason why applications SHOULD avoid IP 473 fragmentation Section 3.2. 475 3.5. Middlebox Traversal Guidelines 477 Network address translators (NATs) and firewalls are examples of 478 intermediary devices ("middleboxes") that can exist along an end-to- 479 end path. A middlebox typically performs a function that requires it 480 to maintain per-flow state. For connection-oriented protocols, such 481 as TCP, middleboxes snoop and parse the connection-management traffic 482 and create and destroy per-flow state accordingly. For a 483 connectionless protocol such as UDP, this approach is not possible. 484 Consequently, middleboxes may create per-flow state when they see a 485 packet that indicates a new flow, and destroy the state after some 486 period of time during which no packets belonging to the same flow 487 have arrived. 489 Depending on the specific function that the middlebox performs, this 490 behavior can introduce a time-dependency that restricts the kinds of 491 UDP traffic exchanges that will be successful across the middlebox. 492 For example, NATs and firewalls typically define the partial path on 493 one side of them to be interior to the domain they serve, whereas the 494 partial path on their other side is defined to be exterior to that 495 domain. Per-flow state is typically created when the first packet 496 crosses from the interior to the exterior, and while the state is 497 present, NATs and firewalls will forward return traffic. Return 498 traffic arriving after the per-flow state has timed out is dropped, 499 as is other traffic arriving from the exterior. 501 Many applications that use UDP for communication operate across 502 middleboxes without needing to employ additional mechanisms. One 503 example is the DNS, which has a strict request-response communication 504 pattern that typically completes within seconds. 506 Other applications may experience communication failures when 507 middleboxes destroy the per-flow state associated with an application 508 session during periods when the application does not exchange any UDP 509 traffic. Applications SHOULD be able to gracefully handle such 510 communication failures and implement mechanisms to re-establish their 511 UDP sessions. 513 For some applications, such as media transmissions, this re- 514 synchronization is highly undesirable, because it can cause user- 515 perceivable playback artifacts. Such specialized applications MAY 516 send periodic keep-alive messages to attempt to refresh middlebox 517 state. It is important to note that keep-alive messages are NOT 518 RECOMMENDED for general use - they are unnecessary for many 519 applications and can consume significant amounts of system and 520 network resources. 522 An application that needs to employ keep-alives to deliver useful 523 service in the presence of middleboxes SHOULD NOT transmit them more 524 frequently than once every 15 seconds and SHOULD use longer intervals 525 when possible. No common timeout has been specified for per-flow UDP 526 state for arbitrary middleboxes. For NATs, [RFC4787] requires a 527 state timeout of 2 minutes or longer. However, empirical evidence 528 suggests that a significant fraction of the deployed middleboxes 529 unfortunately uses shorter timeouts. The timeout of 15 seconds 530 originates with the Interactive Connectivity Establishment (ICE) 531 protocol [I-D.ietf-mmusic-ice]. Applications that operate in more 532 controlled network environments SHOULD investigate whether the 533 environment they operate in allows them to use longer intervals, or 534 whether it offers mechanisms to explicitly control middlebox state 535 timeout durations, for example, using MIDCOM [RFC3303], NSIS 536 [I-D.ietf-nsis-nslp-natfw], STUN 537 [I-D.wing-behave-nat-control-stun-usage] or UPnP [UPNP]. 539 It is important to note that sending keep-alives is not a substitute 540 for implementing robust connection handling. Like all UDP messages, 541 keep-alives can be delayed or dropped, causing middlebox state to 542 time out. In addition, the congestion control guidelines in 543 Section 3.1 cover all UDP transmissions by an application, including 544 the transmission of middlebox keep-alives. Congestion control may 545 thus lead to delays or temporary suspension of keep-alive 546 transmission. 548 3.6. Programming Guidelines 550 The de facto standard application programming interface (API) for 551 TCP/IP applications is the "sockets" interface [POSIX]. Although 552 this API was developed for UNIX in the early 1980s, a wide variety of 553 non-UNIX operating systems also implements it. The sockets API 554 supports both IPv4 and IPv6 [RFC3493]. The UDP sockets API differs 555 from that for TCP in several key ways. Because application 556 programmers are typically more familiar with the TCP sockets API, the 557 remainder of this section discusses these differences. [STEVENS] 558 provides usage examples of the UDP sockets API. 560 UDP messages may be directly sent and received, without any 561 connection setup. Using the sockets API, applications can receive 562 packets from more than one IP source address on a single UDP socket. 563 Some servers use this to exchange data with more than one remote host 564 through a single UDP socket at the same time. When applications need 565 to ensure that they receive packets from a particular source address, 566 they MUST implement corresponding checks at the application layer or 567 explicitly request that the operating system filter the received 568 packets. 570 Many operating systems also allow a UDP socket to be connected, i.e., 571 allow to bind a UDP socket to a specific pair of addresses and ports. 572 This is similar to the corresponding TCP sockets API functionality. 573 However, for UDP, this is only a local operation that serves to 574 simplify the local send/receive functions and to filter the traffic 575 for the specified addresses and ports. Binding a UDP socket does not 576 establish a connection - UDP does not notify the remote end when a 577 local UDP socket is bound. 579 UDP provides no flow-control. This is another reason why UDP-based 580 applications need to be robust in the presence of packet loss. This 581 loss can also occur within the sending host, when an application 582 sends data faster than the line rate of the outbound network 583 interface. It can also occur on the destination, where receive calls 584 fail to return data when the application issues them too frequently 585 (i.e., when no new data has arrived) or not frequently enough (i.e., 586 such that the receive buffer overflows). Robust flow control 587 mechanisms are difficult to implement, which is why applications that 588 need this functionality SHOULD consider using a full-featured 589 transport protocol. 591 When an application closes a TCP, SCTP or DCCP socket, the transport 592 protocol on the receiving host is required to maintain TIME-WAIT 593 state. This prevents delayed packets from the closed connection 594 instance from being mistakenly associated with a later connection 595 instance that happens to reuse the same IP address and port pairs. 596 The UDP protocol does not implement such a mechanism. Therefore, 597 UDP-based applications need to robust to this case. One application 598 may close a socket or terminate, followed in time by another 599 application receiving on the same port. This later application may 600 then receive packets intended for the first application that were 601 delayed in the network. 603 4. Security Considerations 605 UDP does not provide communications security. Applications that need 606 to protect their communications against eavesdropping, tampering, or 607 message forgery SHOULD employ end-to-end security services provided 608 by other IETF protocols. 610 One option of securing UDP communications is with IPsec [RFC4301], 611 which provides authentication [RFC4302] and encryption [RFC4303] for 612 flows of IP packets. Applications use the Internet Key Exchange 613 (IKE) [RFC4306] to configure IPsec for their sessions. Depending on 614 how IPsec is configured for a flow, it can authenticate or encrypt 615 the UDP headers as well as UDP payloads. In order to be able to use 616 IPsec, an application must execute on an operating system that 617 implements the IPsec protocol suite. 619 Not all operating systems support IPsec. A second option of securing 620 UDP communications is through Datagram Transport Layer Security 621 (DTLS) [RFC4347]. DTLS provides communication privacy by encrypting 622 UDP payloads. It does not protect the UDP headers. Applications can 623 implement DTLS without relying on support from the operating system. 625 Many other options of authenticating or encrypting UDP payloads 626 exist, including other IETF standards, such as S/MIME [RFC3851] or 627 PGP [RFC2440], as well as many non-IETF protocols. Like congestion 628 control mechanisms, security mechanisms are difficult to design and 629 implement correctly. It is hence RECOMMENDED that applications 630 employ well-known standard security mechanisms such as IPsec or DTLS, 631 rather than inventing their own. 633 In terms of congestion control, [RFC2309] and [RFC2914] discuss the 634 dangers of congestion-unresponsive flows to the Internet. This 635 document provides guidelines to designers of UDP-based applications 636 to congestion-control their transmissions. As such, it does not 637 raise any additional security concerns. 639 5. Summary 641 This section summarizes the guidelines made in Section 3 and 642 Section 4 in a tabular format in Table 1 for easy referencing. 644 +---------+---------------------------------------------------------+ 645 | Section | Recommendation | 646 +---------+---------------------------------------------------------+ 647 | 3 | MUST accommodate wide range of Internet path conditions | 648 | | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | 649 | | | 650 | 3.1 | SHOULD control rate of transmission | 651 | | SHOULD perform congestion control over all traffic | 652 | | | 653 | 3.1.1 | for bulk transfers, | 654 | | SHOULD consider implementing TFRC | 655 | | else, SHOULD otherwise use bandwidth similar to TCP | 656 | | | 657 | 3.1.2 | for non-bulk transfers, | 658 | | SHOULD measure RTT and transmit 1 message/RTT | 659 | | else, SHOULD send at most 1 message every 3 seconds | 660 | | | 661 | 3.2 | SHOULD NOT send messages that exceed the PMTU, i.e., | 662 | | SHOULD discover PMTU or send messages < minimum PMTU | 663 | | | 664 | 3.3 | SHOULD handle message loss, duplication, reordering | 665 | | | 666 | 3.4 | SHOULD enable UDP checksum | 667 | 3.4.1 | else, MAY use UDP-Lite with suitable checksum coverage | 668 | | | 669 | 3.5 | SHOULD NOT always send middlebox keep-alives | 670 | | MAY use keep-alives when needed (min. interval 15 sec) | 671 | | | 672 | 3.6 | MUST check IP source address | 673 | | | 674 | 4 | SHOULD use standard IETF security protocols when needed | 675 +---------+---------------------------------------------------------+ 677 Table 1: Summary of recommendations. 679 6. IANA Considerations 681 This document raises no IANA considerations. 683 7. Acknowledgments 685 Thanks to Paul Aitken, Mark Allman, Wesley Eddy, Sally Floyd, Philip 686 Matthews, Joerg Ott, Colin Perkins, Pasi Sarolahti, Joe Touch and 687 Magnus Westerlund for their comments on this document. 689 The middlebox traversal guidelines in Section 3.5 incorporate ideas 690 from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda Srisuresh 691 and Dan Kegel. 693 8. References 695 8.1. Normative References 697 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 698 August 1980. 700 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 701 RFC 793, September 1981. 703 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 704 November 1990. 706 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 707 for IP version 6", RFC 1981, August 1996. 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, March 1997. 712 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 713 RFC 2914, September 2000. 715 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 716 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 717 Zhang, L., and V. Paxson, "Stream Control Transmission 718 Protocol", RFC 2960, October 2000. 720 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 721 Timer", RFC 2988, November 2000. 723 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 724 Friendly Rate Control (TFRC): Protocol Specification", 725 RFC 3448, January 2003. 727 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 728 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 729 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 730 RFC 3819, July 2004. 732 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 733 G. Fairhurst, "The Lightweight User Datagram Protocol 734 (UDP-Lite)", RFC 3828, July 2004. 736 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 737 Internet Protocol", RFC 4301, December 2005. 739 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 740 December 2005. 742 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 743 RFC 4303, December 2005. 745 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 746 RFC 4306, December 2005. 748 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 749 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 751 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 752 Security", RFC 4347, April 2006. 754 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 755 Discovery", RFC 4821, March 2007. 757 8.2. Informative References 759 [FABER] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT State in 760 TCP and Its Effect on Busy Servers", Proc. IEEE Infocom, 761 March 1999. 763 [I-D.floyd-dccp-ccid4] 764 Floyd, S. and E. Kohler, "Profile for Datagram Congestion 765 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly 766 Rate Control for Small Packets (TFRC-SP)", 767 draft-floyd-dccp-ccid4-01 (work in progress), July 2007. 769 [I-D.ford-behave-app] 770 Ford, B., "Application Design Guidelines for Traversal 771 through Network Address Translators", 772 draft-ford-behave-app-05 (work in progress), March 2007. 774 [I-D.ietf-dccp-rfc3448bis] 775 Handley, M., "TCP Friendly Rate Control (TFRC): Protocol 776 Specification", draft-ietf-dccp-rfc3448bis-02 (work in 777 progress), July 2007. 779 [I-D.ietf-mmusic-ice] 780 Rosenberg, J., "Interactive Connectivity Establishment 781 (ICE): A Protocol for Network Address Translator (NAT) 782 Traversal for Offer/Answer Protocols", 783 draft-ietf-mmusic-ice-18 (work in progress), 784 September 2007. 786 [I-D.ietf-nsis-nslp-natfw] 787 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 788 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in 789 progress), July 2007. 791 [I-D.ietf-nsis-ntlp] 792 Schulzrinne, H. and R. Hancock, "GIST: General Internet 793 Signalling Transport", draft-ietf-nsis-ntlp-14 (work in 794 progress), July 2007. 796 [I-D.wing-behave-nat-control-stun-usage] 797 Wing, D., "Discovering, Querying, and Controlling 798 Firewalls and NATs using STUN", 799 draft-wing-behave-nat-control-stun-usage-03 (work in 800 progress), July 2007. 802 [POSIX] IEEE Std. 1003.1-2001, "Standard for Information 803 Technology - Portable Operating System Interface (POSIX)", 804 Open Group Technical Standard: Base Specifications Issue 805 6, ISO/IEC 9945:2002, December 2001. 807 [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", 808 RFC 896, January 1984. 810 [RFC1122] Braden, R., "Requirements for Internet Hosts - 811 Communication Layers", STD 3, RFC 1122, October 1989. 813 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 814 Miller, "Common DNS Implementation Errors and Suggested 815 Fixes", RFC 1536, October 1993. 817 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 818 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 819 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 820 S., Wroclawski, J., and L. Zhang, "Recommendations on 821 Queue Management and Congestion Avoidance in the 822 Internet", RFC 2309, April 1998. 824 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 825 "OpenPGP Message Format", RFC 2440, November 1998. 827 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 828 (IPv6) Specification", RFC 2460, December 1998. 830 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 831 Floyd, S., and M. Luby, "Reliable Multicast Transport 832 Building Blocks for One-to-Many Bulk-Data Transfer", 833 RFC 3048, January 2001. 835 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 836 RFC 3124, June 2001. 838 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 839 A., Peterson, J., Sparks, R., Handley, M., and E. 840 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 841 June 2002. 843 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 844 A. Rayhan, "Middlebox communication architecture and 845 framework", RFC 3303, August 2002. 847 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 848 Stevens, "Basic Socket Interface Extensions for IPv6", 849 RFC 3493, February 2003. 851 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 852 Jacobson, "RTP: A Transport Protocol for Real-Time 853 Applications", STD 64, RFC 3550, July 2003. 855 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 856 Video Conferences with Minimal Control", STD 65, RFC 3551, 857 July 2003. 859 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 860 Control (WEBRC) Building Block", RFC 3738, April 2004. 862 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 863 Extensions (S/MIME) Version 3.1 Message Specification", 864 RFC 3851, July 2004. 866 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 867 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 868 Congestion Control", RFC 4341, March 2006. 870 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 871 Datagram Congestion Control Protocol (DCCP) Congestion 872 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 873 March 2006. 875 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 876 Congestion Control (TFMCC): Protocol Specification", 877 RFC 4654, August 2006. 879 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 880 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 881 RFC 4787, January 2007. 883 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 884 Errors at High Data Rates", RFC 4963, July 2007. 886 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 887 Mitigations", RFC 4987, August 2007. 889 [STEVENS] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network 890 Programming, The sockets Networking API", Addison-Wesley, 891 2004. 893 [UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized 894 Device Control Protocol V 1.0", November 2001. 896 Authors' Addresses 898 Lars Eggert 899 Nokia Research Center 900 P.O. Box 407 901 Nokia Group 00045 902 Finland 904 Phone: +358 50 48 24461 905 Email: lars.eggert@nokia.com 906 URI: http://research.nokia.com/people/lars_eggert/ 908 Godred Fairhurst 909 University of Aberdeen 910 Department of Engineering 911 Fraser Noble Building 912 Aberdeen AB24 3UE 913 Scotland 915 Email: gorry@erg.abdn.ac.uk 916 URI: http://www.erg.abdn.ac.uk/ 918 Full Copyright Statement 920 Copyright (C) The IETF Trust (2007). 922 This document is subject to the rights, licenses and restrictions 923 contained in BCP 78, and except as set forth therein, the authors 924 retain all their rights. 926 This document and the information contained herein are provided on an 927 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 928 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 929 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 930 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 931 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 932 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 934 Intellectual Property 936 The IETF takes no position regarding the validity or scope of any 937 Intellectual Property Rights or other rights that might be claimed to 938 pertain to the implementation or use of the technology described in 939 this document or the extent to which any license under such rights 940 might or might not be available; nor does it represent that it has 941 made any independent effort to identify any such rights. Information 942 on the procedures with respect to rights in RFC documents can be 943 found in BCP 78 and BCP 79. 945 Copies of IPR disclosures made to the IETF Secretariat and any 946 assurances of licenses to be made available, or the result of an 947 attempt made to obtain a general license or permission for the use of 948 such proprietary rights by implementers or users of this 949 specification can be obtained from the IETF on-line IPR repository at 950 http://www.ietf.org/ipr. 952 The IETF invites any interested party to bring to its attention any 953 copyrights, patents or patent applications, or other proprietary 954 rights that may cover technology that may be required to implement 955 this standard. Please address the information to the IETF at 956 ietf-ipr@ietf.org. 958 Acknowledgment 960 Funding for the RFC Editor function is provided by the IETF 961 Administrative Support Activity (IASA).