idnits 2.17.1 draft-ietf-tsvwg-udp-guidelines-08.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 1202. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1220. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1226. 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 (June 13, 2008) is 5789 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 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 3448 (Obsoleted by RFC 5348) == Outdated reference: A later version (-05) exists of draft-ietf-dccp-ccid4-02 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-18 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-15 -- 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 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 3852 (Obsoleted by RFC 5652) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 14 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: BCP G. Fairhurst 5 Expires: December 15, 2008 University of Aberdeen 6 June 13, 2008 8 Guidelines for Application Designers on Using Unicast UDP 9 draft-ietf-tsvwg-udp-guidelines-08 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 15, 2008. 36 Abstract 38 The User Datagram Protocol (UDP) provides a minimal, message-passing 39 transport that has no inherent congestion control mechanisms. 40 Because congestion control is critical to the stable operation of the 41 Internet, applications and upper-layer protocols that choose to use 42 UDP as an Internet transport must employ mechanisms to prevent 43 congestion collapse and establish some degree of fairness with 44 concurrent traffic. This document provides guidelines on the use of 45 UDP for the designers of unicast applications and upper-layer 46 protocols. Congestion control guidelines are a primary focus, but 47 the document also provides guidance on other topics, including 48 message sizes, reliability, checksums and middlebox traversal. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 5 55 3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 6 56 3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 11 57 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 12 58 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 13 59 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 14 60 3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 16 61 3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 18 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 63 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 70 Intellectual Property and Copyright Statements . . . . . . . . . . 27 72 1. Introduction 74 The User Datagram Protocol (UDP) [RFC0768] provides a minimal, 75 unreliable, best-effort, message-passing transport to applications 76 and upper-layer protocols (both simply called "applications" in the 77 remainder of this document). Compared to other transport protocols, 78 UDP and its UDP-Lite variant [RFC3828] are unique in that they do not 79 establish end-to-end connections between communicating end systems. 80 UDP communication consequently does not incur connection 81 establishment and teardown overheads and there is minimal associated 82 end system state. Because of these characteristics, UDP can offer a 83 very efficient communication transport to some applications. 85 A second unique characteristic of UDP is that it provides no inherent 86 congestion control mechanisms. On many platforms, applications can 87 send UDP datagrams at the line rate of the link interface, which is 88 often much greater than the available path capacity, and doing so 89 contributes to congestion along the path. [RFC2914] describes the 90 best current practice for congestion control in the Internet. It 91 identifies two major reasons why congestion control mechanisms are 92 critical for the stable operation of the Internet: 94 1. The prevention of congestion collapse, i.e., a state where an 95 increase in network load results in a decrease in useful work 96 done by the network. 98 2. The establishment of a degree of fairness, i.e., allowing 99 multiple flows to share the capacity of a path reasonably 100 equitably. 102 Because UDP itself provides no congestion control mechanisms, it is 103 up to the applications that use UDP for Internet communication to 104 employ suitable mechanisms to prevent congestion collapse and 105 establish a degree of fairness. [RFC2309] discusses the dangers of 106 congestion-unresponsive flows and states that "all UDP-based 107 streaming applications should incorporate effective congestion 108 avoidance mechanisms." This is an important requirement, even for 109 applications that do not use UDP for streaming. In addition, 110 congestion-controlled transmission is of benefit to an application 111 itself, because it can reduce self-induced packet loss, minimize 112 retransmissions and hence reduce delays. Congestion control is 113 essential even at relatively slow transmission rates. For example, 114 an application that generates five 1500-byte UDP datagrams in one 115 second can already exceed the capacity of a 56 Kb/s path. For 116 applications that can operate at higher, potentially unbounded data 117 rates, congestion control becomes vital to prevent congestion 118 collapse and establish some degree of fairness. Section 3 describes 119 a number of simple guidelines for the designers of such applications. 121 A UDP datagram is carried in a single IP packet and is hence limited 122 to a maximum payload of 65,507 bytes for IPv4 and 65,527 bytes for 123 IPv6. The transmission of large IP packets usually requires IP 124 fragmentation. Fragmentation decreases communication reliability and 125 efficiency and should be avoided. IPv6 allows the option of 126 transmitting large packets ("jumbograms") without fragmentation when 127 all link layers along the path support this [RFC2675]. Some of the 128 guidelines in Section 3 describe how applications should determine 129 appropriate message sizes. Other sections of this document provide 130 guidance on reliability, checksums and middlebox traversal. 132 This document provides guidelines and recommendations. Although most 133 unicast UDP applications are expected to follow these guidelines, 134 there do exist valid reasons why a specific application may decide 135 not to follow a given guideline. In such cases, it is RECOMMENDED 136 that the application designers document the rationale for their 137 design choice in the technical specification of their application or 138 protocol. 140 This document provides guidelines to designers of applications that 141 use UDP for unicast transmission, which is the most common case. 142 Specialized classes of applications use UDP for IP multicast 143 [RFC1112], broadcast [RFC0919], or anycast [RFC1546] transmissions. 144 The design of such specialized applications requires expertise that 145 goes beyond the simple, unicast-specific guidelines given in this 146 document. Multicast and broadcast senders may transmit to multiple 147 receivers across potentially very heterogeneous paths at the same 148 time, which significantly complicates congestion control, flow 149 control and reliability mechanisms. The IETF has defined a reliable 150 multicast framework [RFC3048] and several building blocks to aid the 151 designers of multicast applications, such as [RFC3738] or [RFC4654]. 152 Anycast senders must be aware that successive messages sent to the 153 same anycast IP address may be delivered to different anycast nodes, 154 i.e., arrive at different locations in the topology. It is not 155 intended that the guidelines in this document apply to multicast, 156 broadcast or anycast applications that use UDP. 158 Finally, although this document specifically refers to unicast 159 applications that use UDP, the spirit of some of its guidelines also 160 applies to other message-passing applications and protocols 161 (specifically on the topics of congestion control, message sizes and 162 reliability). Examples include signaling or control applications 163 that choose to run directly over IP by registering their own IP 164 protocol number with IANA. This document may provide useful 165 background reading to the designers of such applications and 166 protocols. 168 2. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in BCP 14, RFC 2119 173 [RFC2119]. 175 3. UDP Usage Guidelines 177 Internet paths can have widely varying characteristics, including 178 transmission delays, available bandwidths, congestion levels, 179 reordering probabilities, supported message sizes or loss rates. 180 Furthermore, the same Internet path can have very different 181 conditions over time. Consequently, applications that may be used on 182 the Internet MUST NOT make assumptions about specific path 183 characteristics. They MUST instead use mechanisms that let them 184 operate safely under very different path conditions. Typically, this 185 requires conservatively probing the current conditions of the 186 Internet path they communicate over to establish a transmission 187 behavior that it can sustain and that is reasonably fair to other 188 traffic sharing the path. 190 These mechanisms are difficult to implement correctly. For most 191 applications, the use of one of the existing IETF transport protocols 192 is the simplest method of acquiring the required mechanisms. 193 Consequently, the RECOMMENDED alternative to the UDP usage described 194 in the remainder of this section is the use of an IETF transport 195 protocol such as TCP [RFC0793], SCTP [RFC4960] and SCTP-PR [RFC3758], 196 or DCCP [RFC4340] with its different congestion control types 197 [RFC4341][RFC4342][I-D.ietf-dccp-ccid4]. 199 If used correctly, these more fully-featured transport protocols are 200 not as "heavyweight" as often claimed. For example, the TCP 201 algorithms have been continuously improved over decades, and have 202 reached a level of efficiency and correctness that custom 203 application-layer mechanisms will struggle to easily duplicate. In 204 addition, many TCP implementations allow connections to be tuned by 205 an application to its purposes. For example, TCP's "Nagle" algorithm 206 [RFC0896] can be disabled, improving communication latency at the 207 expense of more frequent - but still congestion-controlled - packet 208 transmissions. Another example is the TCP SYN Cookie mechanism 209 [RFC4987], which is available on many platforms. TCP with SYN 210 Cookies does not require a server to maintain per-connection state 211 until the connection is established. TCP also requires the end that 212 closes a connection to maintain the TIME-WAIT state that prevents 213 delayed segments from one connection instance to interfere with a 214 later one. Applications that are aware of and designed for this 215 behavior can shift maintenance of the TIME-WAIT state to conserve 216 resources by controlling which end closes a TCP connection [FABER]. 217 Finally, TCP's built-in capacity-probing and awareness of the maximum 218 transmission unit supported by the path (PMTU) results in efficient 219 data transmission that quickly compensates for the initial connection 220 setup delay, for transfers that exchange more than a few segments. 222 3.1. Congestion Control Guidelines 224 If an application or upper-layer protocol chooses not to use a 225 congestion-controlled transport protocol, it SHOULD control the rate 226 at which it sends UDP datagrams to a destination host, in order to 227 fulfill the requirements of [RFC2914]. It is important to stress 228 that an application SHOULD perform congestion control over all UDP 229 traffic it sends to a destination, independently from how it 230 generates this traffic. For example, an application that forks 231 multiple worker processes or otherwise uses multiple sockets to 232 generate UDP datagrams SHOULD perform congestion control over the 233 aggregate traffic. 235 The remainder of this section discusses several approaches for this 236 purpose. Not all approaches discussed below are appropriate for all 237 UDP-transmitting applications. Section 3.1.1 discusses congestion 238 control options for applications that perform bulk transfers over 239 UDP. Such applications can employ schemes that sample the path over 240 several subsequent RTTs during which data is exchanged, in order to 241 determine a sending rate that the path at its current load can 242 support. Other applications only exchange a few UDP datagrams with a 243 destination. Section 3.1.2 discusses congestion control options for 244 such "low data-volume" applications. Because they typically do not 245 transmit enough data to iteratively sample the path to determine a 246 safe sending rate, they need to employ different kinds of congestion 247 control mechanisms. Section 3.1.3 discusses congestion control 248 considerations when UDP is used as a tunneling protocol. 250 It is important to note that congestion control should not be viewed 251 as an add-on to a finished application. Many of the mechanisms 252 discussed in the guidelines below require application support to 253 operate correctly. Application designers need to consider congestion 254 control throughout the design of their application, similar to how 255 they consider security aspects throughout the design process. 257 In the past, the IETF has also investigated integrated congestion 258 control mechanisms that act on the traffic aggregate between two 259 hosts, i.e., across all communication sessions active at a given time 260 independent of specific transport protocols, such as the Congestion 261 Manager [RFC3124]. Such mechanisms have failed to see deployment, 262 but would otherwise also fulfill the congestion control requirements 263 in [RFC2914], because they provide congestion control for UDP 264 sessions. 266 3.1.1. Bulk Transfer Applications 268 Applications that perform bulk transmission of data to a peer over 269 UDP, i.e., applications that exchange more than a small number of UDP 270 datagrams per RTT, SHOULD implement TCP-Friendly Rate Control (TFRC) 271 [RFC3448], window-based, TCP-like congestion control, or otherwise 272 ensure that the application complies with the congestion control 273 principles. 275 TFRC has been designed to provide both congestion control and 276 fairness in a way that is compatible with the IETF's other transport 277 protocols. TFRC is currently being updated 278 [I-D.ietf-dccp-rfc3448bis], and application designers SHOULD always 279 evaluate whether the latest published specification fits their needs. 280 If an application implements TFRC, it need not follow the remaining 281 guidelines in Section 3.1, because TFRC already addresses them, but 282 SHOULD still follow the remaining guidelines in the subsequent 283 subsections of Section 3. 285 Bulk transfer applications that choose not to implement TFRC or TCP- 286 like windowing SHOULD implement a congestion control scheme that 287 results in bandwidth use that competes fairly with TCP within an 288 order of magnitude. [RFC3551] suggests that applications SHOULD 289 monitor the packet loss rate to ensure that it is within acceptable 290 parameters. Packet loss is considered acceptable if a TCP flow 291 across the same network path under the same network conditions would 292 achieve an average throughput, measured on a reasonable timescale, 293 that is not less than that of the UDP flow. The comparison to TCP 294 cannot be specified exactly, but is intended as an "order-of- 295 magnitude" comparison in timescale and throughput. 297 Finally, some bulk transfer applications may choose not to implement 298 any congestion control mechanism and instead rely on transmitting 299 across reserved path capacity. This might be an acceptable choice 300 for a subset of restricted networking environments, but is by no 301 means a safe practice for operation in the Internet. When the UDP 302 traffic of such applications leaks out on unprovisioned Internet 303 paths, it can significantly degrade the performance of other traffic 304 sharing the path and even result in congestion collapse. 305 Applications that support an uncontrolled or unadaptive transmission 306 behavior SHOULD NOT do so by default and SHOULD instead require users 307 to explicitly enable this mode of operation. 309 3.1.2. Low Data-Volume Applications 311 When applications that exchange only a small number of UDP datagrams 312 with a destination at any time implement TFRC or one of the other 313 congestion control schemes in Section 3.1.1, the network sees little 314 benefit, because those mechanisms perform congestion control in a way 315 that is only effective for longer transmissions. 317 Applications that exchange only a small number of UDP datagrams with 318 a destination at any time SHOULD still control their transmission 319 behavior by not sending on average more than one UDP datagram per 320 round-trip time (RTT) to a destination. Similar to the 321 recommendation in [RFC1536], an application SHOULD maintain an 322 estimate of the RTT for any destination with which it communicates. 323 Applications SHOULD implement the algorithm specified in [RFC2988] to 324 compute a smoothed RTT (SRTT) estimate. They SHOULD also detect 325 packet loss and exponentially back-off their retransmission timer 326 when a loss event occurs. When implementing this scheme, 327 applications need to choose a sensible initial value for the RTT. 328 This value SHOULD generally be as conservative as possible for the 329 given application. TCP uses an initial value of 3 seconds [RFC2988], 330 which is also RECOMMENDED as an initial value for UDP applications. 331 SIP [RFC3261] and GIST [I-D.ietf-nsis-ntlp] use an initial value of 332 500 ms, and initial timeouts that are shorter than this are likely 333 problematic in many cases. It is also important to note that the 334 initial timeout is not the maximum possible timeout - the RECOMMENDED 335 algorithm in [RFC2988] yields timeout values after a series of losses 336 that are much longer than the initial value. 338 Some applications cannot maintain a reliable RTT estimate for a 339 destination. The first case is that of applications that exchange 340 too few UDP datagrams with a peer to establish a statistically 341 accurate RTT estimate. Such applications MAY use a pre-determined 342 transmission interval that is exponentially backed-off when packets 343 are lost. TCP uses an initial value of 3 seconds [RFC2988], which is 344 also RECOMMENDED as an initial value for UDP applications. SIP 345 [RFC3261] and GIST [I-D.ietf-nsis-ntlp] use an interval of 500 ms, 346 and shorter values are likely problematic in many cases. As in the 347 previous case, note that the initial timeout is not the maximum 348 possible timeout. 350 A second class of applications cannot maintain an RTT estimate for a 351 destination, because the destination does not send return traffic. 352 Such applications SHOULD NOT send more than one UDP datagram every 3 353 seconds, and SHOULD use an even less aggressive rate when possible. 354 The 3-second interval was chosen based on TCP's retransmission 355 timeout when the RTT is unknown [RFC2988], and shorter values are 356 likely problematic in many cases. Note that the sending rate in this 357 case must be more conservative than in the two previous cases, 358 because the lack of return traffic prevents the detection of packet 359 loss, i.e., congestion events, and the application therefore cannot 360 perform exponential back-off to reduce load. 362 Applications that communicate bidirectionally SHOULD employ 363 congestion control for both directions of the communication. For 364 example, for a client-server, request-response-style application, 365 clients SHOULD congestion control their request transmission to a 366 server, and the server SHOULD congestion-control its responses to the 367 clients. Congestion in the forward and reverse direction is 368 uncorrelated and an application SHOULD independently detect and 369 respond to congestion along both directions. 371 3.1.3. UDP Tunnels 373 One increasingly popular use of UDP is as a tunneling protocol, where 374 a tunnel endpoint encapsulates the packets of another protocol inside 375 UDP datagrams and transmits them to another tunnel endpoint, which 376 decapsulates the UDP datagrams and forwards the original packets 377 contained in the payload. Tunnels establish virtual links that 378 appear to directly connect locations that are distant in the physical 379 Internet topology, and can be used to create virtual (private) 380 networks. Using UDP as a tunneling protocol is attractive when the 381 payload protocol is not supported by middleboxes that may exist along 382 the path, because many middleboxes support UDP transmissions. 384 Well-implemented tunnels are generally invisible to the endpoints 385 that happen to transmit over a path that includes tunneled links. On 386 the other hand, to the routers along the path of a UDP tunnel, i.e., 387 the routers between the two tunnel endpoints, the traffic that a UDP 388 tunnel generates is a regular UDP flow, and the encapsulator and 389 decapsulator appear as regular UDP-sending and -receiving 390 applications. Because other flows can share the path with one or 391 more UDP tunnels, congestion control needs to be considered. 393 Two factors determine whether a UDP tunnel needs to employ specific 394 congestion control mechanisms. First, whether the tunneling scheme 395 generates UDP traffic at a volume that corresponds to the volume of 396 payload traffic carried within the tunnel. Second, whether the 397 payload traffic is IP-based. 399 IP-based traffic is generally assumed to be congestion-controlled, 400 i.e., it is assumed that the transport protocols generating IP-based 401 traffic at the sender already employ mechanisms that are sufficient 402 to address congestion on the path. Consequently, a tunnel carrying 403 IP-based traffic should already interact appropriately with other 404 traffic sharing the path, and specific congestion control mechanism 405 for the tunnel are not necessary. 407 However, if the IP traffic in the tunnel is known to not be 408 congestion-controlled, additional measures are RECOMMENDED in order 409 to limit the impact of the tunneled traffic on other traffic sharing 410 the path. 412 The following guidelines define these possible cases in more detail: 414 1. A tunnel generates UDP traffic at a volume that corresponds to 415 the volume of payload traffic, and the payload traffic is IP- 416 based and hence assumed to be congestion-controlled. 418 This is arguably the most common case for Internet tunnels. In 419 this case, the UDP tunnel SHOULD NOT employ its own congestion 420 control mechanism, because congestion losses of tunneled traffic 421 will already trigger an appropriate congestion response at the 422 original senders of the tunneled traffic. 424 Note that this guideline is built on the assumption that most IP- 425 based communication is congestion-controlled. If a UDP tunnel is 426 used for IP-based traffic that is known to not be congestion- 427 controlled, the next set of guidelines applies: 429 2. A tunnel generates UDP traffic at a volume that corresponds to 430 the volume of payload traffic, and the payload traffic is not 431 known to be IP-based, or is known to be IP-based but not 432 congestion-controlled. 434 This can be the case, for example, when some link-layer protocols 435 are encapsulated within UDP (but not all link-layer protocols; 436 some are congestion-controlled.) Because it is not known that 437 congestion losses of tunneled non-IP traffic will trigger an 438 appropriate congestion response at the senders, the UDP tunnel 439 SHOULD employ an appropriate congestion control mechanism. 440 Because tunnels are usually bulk-transfer applications as far as 441 the intermediate routers are concerned, the guidelines in 442 Section 3.1.1 apply. 444 3. A tunnel generates UDP traffic at a volume that does not 445 correspond to the volume of payload traffic, independent of 446 whether the payload traffic is IP-based or congestion-controlled. 448 Examples of this class include UDP tunnels that send at a 449 constant rate, increase their transmission rates under loss, for 450 example, due to increasing redundancy when forward-error- 451 correction is used, or are otherwise constrained in their 452 transmission behavior. These specialized uses of UDP for 453 tunneling go beyond the scope of the general guidelines given in 454 this document. The implementer of such specialized tunnels 455 SHOULD carefully consider congestion control in the design of 456 their tunneling mechanism. 458 Designing a tunneling mechanism requires significantly more expertise 459 than needed for many other UDP applications, because tunnels 460 virtualize lower-layer components of the Internet, and the 461 virtualized components need to correctly interact with the 462 infrastructure at that layer. This document only touches upon the 463 congestion control considerations for implementing UDP tunnels; a 464 discussion of other required tunneling behavior is out of scope. 466 3.2. Message Size Guidelines 468 IP fragmentation lowers the efficiency and reliability of Internet 469 communication. The loss of a single fragment results in the loss of 470 an entire fragmented packet, because even if all other fragments are 471 received correctly, the original packet cannot be reassembled and 472 delivered. This fundamental issue with fragmentation exists for both 473 IPv4 and IPv6. In addition, some NATs and firewalls drop IP 474 fragments. The network address translation performed by a NAT only 475 operates on complete IP packets, and some firewall policies also 476 require inspection of complete IP packets. Even with these being the 477 case, some NATs and firewalls simply do not implement the necessary 478 reassembly functionality, and instead choose to drop all fragments. 479 Finally, [RFC4963] documents other issues specific to IPv4 480 fragmentation. 482 Due to these issues, an application SHOULD NOT send UDP datagrams 483 that result in IP packets that exceed the MTU of the path to the 484 destination. Consequently, an application SHOULD either use the path 485 MTU information provided by the IP layer or implement path MTU 486 discovery itself [RFC1191][RFC1981][RFC4821] to determine whether the 487 path to a destination will support its desired message size without 488 fragmentation. 490 Applications that do not follow this recommendation to do PMTU 491 discovery SHOULD still avoid sending UDP datagrams that would result 492 in IP packets that exceed the path MTU. Because the actual path MTU 493 is unknown, such applications SHOULD fall back to sending messages 494 that are shorter that the default effective MTU for sending (EMTU_S 495 in [RFC1122]). For IPv4, EMTU_S is the smaller of 576 bytes and the 496 first-hop MTU [RFC1122]. For IPv6, EMTU_S is 1280 bytes [RFC2460]. 497 The effective PMTU for a directly connected destination (with no 498 routers on the path) is the configured interface MTU, which could be 499 less than the maximum link payload size. Transmission of minimum- 500 sized UDP datagrams is inefficient over paths that support a larger 501 PMTU, which is a second reason to implement PMTU discovery. 503 To determine an appropriate UDP payload size, applications MUST 504 subtract the size of the IP header (which includes any IPv4 optional 505 headers or IPv6 extension headers) as well as the length of the UDP 506 header (8 bytes) from the PMTU size. This size, known as the MMS_S, 507 can be obtained from the TCP/IP stack [RFC1122]. 509 Applications that do not send messages that exceed the effective PMTU 510 of IPv4 or IPv6 need not implement any of the above mechanisms. Note 511 that the presence of tunnels can cause an additional reduction of the 512 effective PMTU, so implementing PMTU discovery will still be 513 beneficial in some cases. 515 Applications that fragment an application-layer message into multiple 516 UDP datagrams SHOULD perform this fragmentation so that each datagram 517 can be received independently, and be independently retransmitted in 518 the case where an application implements its own reliability 519 mechanisms. 521 3.3. Reliability Guidelines 523 Application designers are generally aware that UDP does not provide 524 any reliability, e.g., it does not retransmit any lost packets. 525 Often, this is a main reason to consider UDP as a transport. 526 Applications that do require reliable message delivery MUST implement 527 an appropriate mechanism themselves. 529 UDP also does not protect against datagram duplication, i.e., an 530 application may receive multiple copies of the same UDP datagram. 531 Application designers SHOULD verify that their application handles 532 datagram duplication gracefully, and may consequently need to 533 implement mechanisms to detect duplicates. Even if UDP datagram 534 reception triggers idempotent operations, applications may want to 535 suppress duplicate datagrams to reduce load. 537 In addition, the Internet can significantly delay some packets with 538 respect to others, e.g., due to routing transients, intermittent 539 connectivity, or mobility. This can cause reordering, where UDP 540 datagrams arrive at the receiver in an order different from the 541 transmission order. Applications that require ordered delivery MUST 542 reestablish datagram ordering themselves. 544 Finally, it is important to note that delay spikes can be very large. 545 This can cause reordered packets to arrive many seconds after they 546 were sent. [RFC0793] defines the the maximum delay a TCP segment 547 should experience - the Maximum Segment Lifetime (MSL) - as 2 548 minutes. No other RFC defines an MSL for other transport protocols 549 or IP itself. This document clarifies that the MSL value to be used 550 for UDP SHOULD be the same 2 minutes as for TCP. Applications SHOULD 551 be robust to the reception of delayed or duplicate packets that are 552 received within this 2-minute interval. 554 An application that requires reliable and ordered message delivery 555 SHOULD choose an IETF standard transport protocol that provides these 556 features. If this is not possible, it will need to implement a set 557 of appropriate mechanisms itself. 559 3.4. Checksum Guidelines 561 The UDP header includes an optional, 16-bit ones-complement checksum 562 that provides an integrity check. This results in a relatively weak 563 protection from a coding point of view [RFC3819] and application 564 developers SHOULD implement additional checks where data integrity is 565 important, e.g., through a Cyclic Redundancy Check (CRC) included 566 with the data to verify the integrity of an entire object/file sent 567 over UDP service. 569 The UDP checksum provides assurance that the payload was not 570 corrupted in transit. It also allows the receiver to verify that it 571 was the intended destination of the packet, because it covers the IP 572 addresses, port numbers and protocol number, and it verifies that the 573 packet is not truncated or padded, because it covers the size field. 574 It therefore protects an application against receiving corrupted 575 payload data in place of, or in addition to, the data that was sent. 577 Applications SHOULD enable UDP checksums, although [RFC0768] permits 578 the option to disable their use. Applications that choose to disable 579 UDP checksums when transmitting over IPv4 therefore MUST NOT make 580 assumptions regarding the correctness of received data and MUST 581 behave correctly when a UDP datagram is received that was originally 582 sent to a different destination or is otherwise corrupted. The use 583 of the UDP checksum is REQUIRED when applications transmit UDP over 584 IPv6 [RFC2460]. 586 3.4.1. UDP-Lite 588 A special class of applications can derive benefit from having 589 partially damaged payloads delivered, rather than discarded, when 590 using paths that include error-prone links. Such applications can 591 tolerate payload corruption and MAY choose to use the Lightweight 592 User Datagram Protocol (UDP-Lite) [RFC3828] variant of UDP instead of 593 basic UDP. Applications that choose to use UDP-Lite instead of UDP 594 should still follow the congestion control and other guidelines 595 described for use with UDP in Section 3. 597 UDP-Lite changes the semantics of the UDP "payload length" field to 598 that of a "checksum coverage length" field. Otherwise, UDP-Lite is 599 semantically identical to UDP. The interface of UDP-Lite differs 600 from that of UDP by the addition of a single (socket) option that 601 communicates a checksum coverage length value: at the sender, this 602 specifies the intended checksum coverage, with the remaining 603 unprotected part of the payload called the "error insensitive part". 604 If required, an application may dynamically modify this length value, 605 e.g., to offer greater protection to some messages. UDP-Lite always 606 verifies that a packet was delivered to the intended destination, 607 i.e., always verifies the header fields. Errors in the insensitive 608 part will not cause a UDP datagram to be discarded by the 609 destination. Applications using UDP-Lite therefore MUST NOT make 610 assumptions regarding the correctness of the data received in the 611 insensitive part of the UDP-Lite payload. 613 The sending application SHOULD select the minimum checksum coverage 614 to include all sensitive protocol headers. For example, applications 615 that use the Real-Time Protocol (RTP) [RFC3550] will likely want to 616 protect the RTP header against corruption. Applications, where 617 appropriate, MUST also introduce their own appropriate validity 618 checks for protocol information carried in the insensitive part of 619 the UDP-Lite payload (e.g., internal CRCs). 621 The receiver MUST set a minimum coverage threshold for incoming 622 packets that is not smaller than the smallest coverage used by the 623 sender. This may be a fixed value, or may be negotiated by an 624 application. UDP-Lite does not provide mechanisms to negotiate the 625 checksum coverage between the sender and receiver. 627 Applications may still experience packet loss, rather than 628 corruption, when using UDP-Lite. The enhancements offered by UDP- 629 Lite rely upon a link being able to intercept the UDP-Lite header to 630 correctly identify the partial coverage required. When tunnels 631 and/or encryption are used, this can result in UDP-Lite datagrams 632 being treated the same as UDP datagrams, i.e., result in packet loss. 633 Use of IP fragmentation can also prevent special treatment for UDP- 634 Lite datagrams, and is another reason why applications SHOULD avoid 635 IP fragmentation (Section 3.2). 637 3.5. Middlebox Traversal Guidelines 639 Network address translators (NATs) and firewalls are examples of 640 intermediary devices ("middleboxes") that can exist along an end-to- 641 end path. A middlebox typically performs a function that requires it 642 to maintain per-flow state. For connection-oriented protocols, such 643 as TCP, middleboxes snoop and parse the connection-management traffic 644 and create and destroy per-flow state accordingly. For a 645 connectionless protocol such as UDP, this approach is not possible. 646 Consequently, middleboxes may create per-flow state when they see a 647 packet that indicates a new flow, and destroy the state after some 648 period of time during which no packets belonging to the same flow 649 have arrived. 651 Depending on the specific function that the middlebox performs, this 652 behavior can introduce a time-dependency that restricts the kinds of 653 UDP traffic exchanges that will be successful across the middlebox. 654 For example, NATs and firewalls typically define the partial path on 655 one side of them to be interior to the domain they serve, whereas the 656 partial path on their other side is defined to be exterior to that 657 domain. Per-flow state is typically created when the first packet 658 crosses from the interior to the exterior, and while the state is 659 present, NATs and firewalls will forward return traffic. Return 660 traffic arriving after the per-flow state has timed out is dropped, 661 as is other traffic arriving from the exterior. 663 Many applications that use UDP for communication operate across 664 middleboxes without needing to employ additional mechanisms. One 665 example is the Domain Name System (DNS), which has a strict request- 666 response communication pattern that typically completes within 667 seconds. 669 Other applications may experience communication failures when 670 middleboxes destroy the per-flow state associated with an application 671 session during periods when the application does not exchange any UDP 672 traffic. Applications SHOULD be able to gracefully handle such 673 communication failures and implement mechanisms to re-establish 674 application-layer sessions and state. 676 For some applications, such as media transmissions, this re- 677 synchronization is highly undesirable, because it can cause user- 678 perceivable playback artifacts. Such specialized applications MAY 679 send periodic keep-alive messages to attempt to refresh middlebox 680 state. It is important to note that keep-alive messages are NOT 681 RECOMMENDED for general use - they are unnecessary for many 682 applications and can consume significant amounts of system and 683 network resources. 685 An application that needs to employ keep-alives to deliver useful 686 service over UDP in the presence of middleboxes SHOULD NOT transmit 687 them more frequently than once every 15 seconds and SHOULD use longer 688 intervals when possible. No common timeout has been specified for 689 per-flow UDP state for arbitrary middleboxes. For NATs, [RFC4787] 690 requires a state timeout of 2 minutes or longer. However, empirical 691 evidence suggests that a significant fraction of the deployed 692 middleboxes unfortunately uses shorter timeouts. The timeout of 15 693 seconds originates with the Interactive Connectivity Establishment 694 (ICE) protocol [I-D.ietf-mmusic-ice]. Applications that operate in 695 more controlled network environments SHOULD investigate whether the 696 environment they operate in allows them to use longer intervals, or 697 whether it offers mechanisms to explicitly control middlebox state 698 timeout durations, for example, using MIDCOM [RFC3303], NSIS 699 [I-D.ietf-nsis-nslp-natfw] or UPnP [UPNP]. It is RECOMMENDED that 700 applications apply slight random variations ("jitter") to the timing 701 of keep-alive transmissions, in order to reduce the potential for 702 persistent synchronization between keep-alive transmissions from 703 different hosts. 705 Sending keep-alives is not a substitute for implementing robust 706 connection handling. Like all UDP datagrams, keep-alives can be 707 delayed or dropped, causing middlebox state to time out. In 708 addition, the congestion control guidelines in Section 3.1 cover all 709 UDP transmissions by an application, including the transmission of 710 middlebox keep-alives. Congestion control may thus lead to delays or 711 temporary suspension of keep-alive transmission. 713 Keep-alive messages are NOT RECOMMENDED for general use. They are 714 unnecessary for many applications and can consume significant amounts 715 of system and network resources. For example, on battery-powered 716 devices, if an application needs to maintain connectivity for long 717 periods with little traffic, the frequency at which keep-alives are 718 sent can become the determining factor that governs power 719 consumption, depending on the underlying network technology. Because 720 many middleboxes are designed to require keep-alives for TCP 721 connections at a frequency that is much lower than that needed for 722 UDP, this difference alone can often be sufficient to prefer TCP over 723 UDP for these deployments. On the other hand, there is anecdotal 724 evidence that suggests that direct communication through middleboxes, 725 e.g., by using ICE [I-D.ietf-mmusic-ice], does succeed less often 726 with TCP than with UDP. The tradeoffs between different transport 727 protocols - especially when it comes to middlebox traversal - deserve 728 careful analysis. 730 3.6. Programming Guidelines 732 The de facto standard application programming interface (API) for 733 TCP/IP applications is the "sockets" interface [POSIX]. Although 734 this API was developed for UNIX in the early 1980s, a wide variety of 735 non-UNIX operating systems also implements it. The sockets API 736 supports both IPv4 and IPv6 [RFC3493]. The UDP sockets API differs 737 from that for TCP in several key ways. Because application 738 programmers are typically more familiar with the TCP sockets API, the 739 remainder of this section discusses these differences. [STEVENS] 740 provides usage examples of the UDP sockets API. 742 UDP datagrams may be directly sent and received, without any 743 connection setup. Using the sockets API, applications can receive 744 packets from more than one IP source address on a single UDP socket. 745 Some servers use this to exchange data with more than one remote host 746 through a single UDP socket at the same time. When applications need 747 to ensure that they receive packets from a particular source address, 748 they MUST implement corresponding checks at the application layer or 749 explicitly request that the operating system filter the received 750 packets. 752 If a client/server application executes on a host with more than one 753 IP interface, the application SHOULD send any UDP responses in reply 754 to arriving UDP datagrams with an IP source address that matches the 755 IP destination address of the datagram that carried the request (see 756 [RFC1122], Section 4.1.3.5). Many middleboxes expect this 757 transmission behavior and drop replies that are sent from a different 758 IP address, as explained in Section 3.5. 760 A UDP receiver can receive a valid UDP datagram with a zero-length 761 payload. Note that this is different from a return value of zero 762 from a read() socket call, which for TCP indicates the end of the 763 connection. 765 Many operating systems also allow a UDP socket to be connected, i.e., 766 to bind a UDP socket to a specific pair of addresses and ports. This 767 is similar to the corresponding TCP sockets API functionality. 768 However, for UDP, this is only a local operation that serves to 769 simplify the local send/receive functions and to filter the traffic 770 for the specified addresses and ports. Binding a UDP socket does not 771 establish a connection - UDP does not notify the remote end when a 772 local UDP socket is bound. Binding a socket also allows configuring 773 options that affect the UDP or IP layers, for example, use of the UDP 774 checksum or the IP Time Stamp Option. On some stacks, a bound socket 775 also allows an application to be notified when ICMP error messages 776 are received for its transmissions [RFC1122]. 778 UDP provides no flow-control. This is another reason why UDP-based 779 applications need to be robust in the presence of packet loss. This 780 loss can also occur within the sending host, when an application 781 sends data faster than the line rate of the outbound network 782 interface. It can also occur on the destination, where receive calls 783 fail to return all the data that was sent when the application issues 784 them too infrequently (i.e., such that the receive buffer overflows). 785 Robust flow control mechanisms are difficult to implement, which is 786 why applications that need this functionality SHOULD consider using a 787 full-featured transport protocol. 789 When an application closes a TCP, SCTP or DCCP socket, the transport 790 protocol on the receiving host is required to maintain TIME-WAIT 791 state. This prevents delayed packets from the closed connection 792 instance from being mistakenly associated with a later connection 793 instance that happens to reuse the same IP address and port pairs. 794 The UDP protocol does not implement such a mechanism. Therefore, 795 UDP-based applications need to be robust in this case. One 796 application may close a socket or terminate, followed in time by 797 another application receiving on the same port. This later 798 application may then receive packets intended for the first 799 application that were delayed in the network. 801 3.7. ICMP Guidelines 803 Applications can utilize information about ICMP error messages that 804 the UDP layer passes up for a variety of purposes [RFC1122]. 805 Applications SHOULD validate that the information in the ICMP message 806 payload, e.g., a reported error condition, corresponds to a UDP 807 datagram that the application actually sent. Note that not all APIs 808 have the necessary functions to support this validation, and some 809 APIs already perform this validation internally before passing ICMP 810 information to the application. 812 Any application response to ICMP error messages SHOULD be robust to 813 temporary routing failures, i.e., transient ICMP "unreachable" 814 messages should not normally cause a communication abort. 815 Applications SHOULD appropriately process ICMP messages generated in 816 response to transmitted traffic. A correct response often requires 817 context, such as local state about communication instances to each 818 destination, that although readily available in connection-oriented 819 transport protocols is not always maintained by UDP-based 820 applications. 822 4. Security Considerations 824 UDP does not provide communications security. Applications that need 825 to protect their communications against eavesdropping, tampering, or 826 message forgery SHOULD employ end-to-end security services provided 827 by other IETF protocols. 829 One option of securing UDP communications is with IPsec [RFC4301], 830 which can provide authentication for flows of IP packets through the 831 Authentication Header (AH) [RFC4302] and encryption and/or 832 authentication through the Encapsulating Security Payload (ESP) 833 [RFC4303]. Applications use the Internet Key Exchange (IKE) 834 [RFC4306] to configure IPsec for their sessions. Depending on how 835 IPsec is configured for a flow, it can authenticate or encrypt the 836 UDP headers as well as UDP payloads. If an application only requires 837 authentication, ESP with no encryption but with authentication is 838 often a better option than AH, because ESP can operate across 839 middleboxes. In order to be able to use IPsec, an application must 840 execute on an operating system that implements the IPsec protocol 841 suite. 843 Although it is possible to use IPsec to secure UDP communications, 844 not all operating systems support IPsec or allow applications to 845 easily configure it for their flows. A second option of securing UDP 846 communications is through Datagram Transport Layer Security (DTLS) 847 [RFC4347]. DTLS provides communication privacy by encrypting UDP 848 payloads. It does not protect the UDP headers. Applications can 849 implement DTLS without relying on support from the operating system. 851 Many other options for authenticating or encrypting UDP payloads 852 exist. For example, the GSS-API security framework [RFC2743] or 853 Cryptographic Message Syntax (CMS) [RFC3852] could be used to protect 854 UDP payloads. The IETF standard for securing RTP [RFC3550] realtime 855 communication sessions over UDP is SRTP [RFC3711]. In some 856 applications, a better solution is to protect larger standalone 857 objects, such as files or messages, instead of individual UDP 858 payloads. In these situations, CMS [RFC3852], S/MIME [RFC3851] or 859 OpenPGP [RFC4880] could be used. In addition, there are many non- 860 IETF protocols in this area. 862 Like congestion control mechanisms, security mechanisms are difficult 863 to design and implement correctly. It is hence RECOMMENDED that 864 applications employ well-known standard security mechanisms such as 865 DTLS or IPsec, rather than inventing their own. 867 In terms of congestion control, [RFC2309] and [RFC2914] discuss the 868 dangers of congestion-unresponsive flows to the Internet. This 869 document provides guidelines to designers of UDP-based applications 870 to congestion-control their transmissions, and does not raise any 871 additional security concerns. 873 5. Summary 875 This section summarizes the guidelines made in Section 3 and 876 Section 4 in a tabular format in Table 1 for easy referencing. 878 +---------------------------------------------------------+---------+ 879 | Recommendation | Section | 880 +---------------------------------------------------------+---------+ 881 | MUST tolerate wide range of Internet path conditions | 3 | 882 | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | | 883 | | | 884 | SHOULD control rate of transmission | 3.1 | 885 | SHOULD perform congestion control over all traffic | | 886 | | | 887 | for bulk transfers, | 3.1.1 | 888 | SHOULD consider implementing TFRC | | 889 | else, SHOULD otherwise use bandwidth similar to TCP | | 890 | | | 891 | for non-bulk transfers, | 3.1.2 | 892 | SHOULD measure RTT and transmit 1 datagram/RTT | | 893 | else, SHOULD send at most 1 datagram every 3 seconds | | 894 | | | 895 | SHOULD NOT send datagrams that exceed the PMTU, i.e., | 3.2 | 896 | SHOULD discover PMTU or send datagrams < minimum PMTU | | 897 | | | 898 | SHOULD handle datagram loss, duplication, reordering | 3.3 | 899 | SHOULD be robust to delivery delays up to 2 minutes | | 900 | | | 901 | SHOULD enable UDP checksum | 3.4 | 902 | else, MAY use UDP-Lite with suitable checksum coverage | 3.4.1 | 903 | | | 904 | SHOULD NOT always send middlebox keep-alives | 3.5 | 905 | MAY use keep-alives when needed (min. interval 15 sec) | | 906 | | | 907 | MUST check IP source address | 3.6 | 908 | and, for client/server applications | | 909 | SHOULD send responses from src address matching request | | 910 | | | 911 | SHOULD use standard IETF security protocols when needed | 4 | 912 +---------------------------------------------------------+---------+ 914 Table 1: Summary of recommendations. 916 6. IANA Considerations 918 This document raises no IANA considerations. 920 (Note to the RFC Editor: Please remove this section upon 921 publication.) 923 7. Acknowledgments 925 Thanks to Paul Aitken, Mark Allman, Francois Audet, Iljitsch van 926 Beijnum, Stewart Bryant, Remi Denis-Courmont, Wesley Eddy, Pasi 927 Eronen, Sally Floyd, Robert Hancock, Jeffrey Hutzelman, Cullen 928 Jennings, Tero Kivinen, Peter Koch, Jukka Manner, Philip Matthews, 929 Joerg Ott, Colin Perkins, Tom Petch, Carlos Pignataro, Pasi 930 Sarolahti, Pascal Thubert, Joe Touch and Magnus Westerlund for their 931 comments on this document. 933 The middlebox traversal guidelines in Section 3.5 incorporate ideas 934 from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda Srisuresh 935 and Dan Kegel. 937 Lars Eggert is partly funded by [TRILOGY], a research project 938 supported by the European Commission under its Seventh Framework 939 Program. 941 8. References 943 8.1. Normative References 945 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 946 August 1980. 948 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 949 RFC 793, September 1981. 951 [RFC1122] Braden, R., "Requirements for Internet Hosts - 952 Communication Layers", STD 3, RFC 1122, October 1989. 954 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 955 November 1990. 957 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 958 for IP version 6", RFC 1981, August 1996. 960 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 961 Requirement Levels", BCP 14, RFC 2119, March 1997. 963 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 964 (IPv6) Specification", RFC 2460, December 1998. 966 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 967 RFC 2914, September 2000. 969 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 970 Timer", RFC 2988, November 2000. 972 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 973 Friendly Rate Control (TFRC): Protocol Specification", 974 RFC 3448, January 2003. 976 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 977 G. Fairhurst, "The Lightweight User Datagram Protocol 978 (UDP-Lite)", RFC 3828, July 2004. 980 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 981 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 982 RFC 4787, January 2007. 984 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 985 Discovery", RFC 4821, March 2007. 987 8.2. Informative References 989 [FABER] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT State in 990 TCP and Its Effect on Busy Servers", Proc. IEEE Infocom, 991 March 1999. 993 [I-D.ford-behave-app] 994 Ford, B., "Application Design Guidelines for Traversal 995 through Network Address Translators", 996 draft-ford-behave-app-05 (work in progress), March 2007. 998 [I-D.ietf-dccp-ccid4] 999 Floyd, S. and E. Kohler, "Profile for Datagram Congestion 1000 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly 1001 Rate Control for Small Packets (TFRC-SP)", 1002 draft-ietf-dccp-ccid4-02 (work in progress), 1003 February 2008. 1005 [I-D.ietf-dccp-rfc3448bis] 1006 Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 1007 Friendly Rate Control (TFRC): Protocol Specification", 1008 draft-ietf-dccp-rfc3448bis-06 (work in progress), 1009 April 2008. 1011 [I-D.ietf-mmusic-ice] 1012 Rosenberg, J., "Interactive Connectivity Establishment 1013 (ICE): A Protocol for Network Address Translator (NAT) 1014 Traversal for Offer/Answer Protocols", 1015 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1017 [I-D.ietf-nsis-nslp-natfw] 1018 Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 1019 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 1020 draft-ietf-nsis-nslp-natfw-18 (work in progress), 1021 February 2008. 1023 [I-D.ietf-nsis-ntlp] 1024 Schulzrinne, H. and R. Hancock, "GIST: General Internet 1025 Signalling Transport", draft-ietf-nsis-ntlp-15 (work in 1026 progress), February 2008. 1028 [POSIX] IEEE Std. 1003.1-2001, "Standard for Information 1029 Technology - Portable Operating System Interface (POSIX)", 1030 Open Group Technical Standard: Base Specifications Issue 1031 6, ISO/IEC 9945:2002, December 2001. 1033 [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", 1034 RFC 896, January 1984. 1036 [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, 1037 RFC 919, October 1984. 1039 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1040 RFC 1112, August 1989. 1042 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 1043 Miller, "Common DNS Implementation Errors and Suggested 1044 Fixes", RFC 1536, October 1993. 1046 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 1047 Anycasting Service", RFC 1546, November 1993. 1049 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 1050 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 1051 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 1052 S., Wroclawski, J., and L. Zhang, "Recommendations on 1053 Queue Management and Congestion Avoidance in the 1054 Internet", RFC 2309, April 1998. 1056 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1057 RFC 2675, August 1999. 1059 [RFC2743] Linn, J., "Generic Security Service Application Program 1060 Interface Version 2, Update 1", RFC 2743, January 2000. 1062 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 1063 Floyd, S., and M. Luby, "Reliable Multicast Transport 1064 Building Blocks for One-to-Many Bulk-Data Transfer", 1065 RFC 3048, January 2001. 1067 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 1068 RFC 3124, June 2001. 1070 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1071 A., Peterson, J., Sparks, R., Handley, M., and E. 1072 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1073 June 2002. 1075 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 1076 A. Rayhan, "Middlebox communication architecture and 1077 framework", RFC 3303, August 2002. 1079 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1080 Stevens, "Basic Socket Interface Extensions for IPv6", 1081 RFC 3493, February 2003. 1083 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1084 Jacobson, "RTP: A Transport Protocol for Real-Time 1085 Applications", STD 64, RFC 3550, July 2003. 1087 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1088 Video Conferences with Minimal Control", STD 65, RFC 3551, 1089 July 2003. 1091 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1092 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1093 RFC 3711, March 2004. 1095 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 1096 Control (WEBRC) Building Block", RFC 3738, April 2004. 1098 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 1099 Conrad, "Stream Control Transmission Protocol (SCTP) 1100 Partial Reliability Extension", RFC 3758, May 2004. 1102 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1103 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1104 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1105 RFC 3819, July 2004. 1107 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1108 Extensions (S/MIME) Version 3.1 Message Specification", 1109 RFC 3851, July 2004. 1111 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1112 RFC 3852, July 2004. 1114 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1115 Internet Protocol", RFC 4301, December 2005. 1117 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1118 December 2005. 1120 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1121 RFC 4303, December 2005. 1123 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1124 RFC 4306, December 2005. 1126 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1127 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1129 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 1130 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 1131 Congestion Control", RFC 4341, March 2006. 1133 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 1134 Datagram Congestion Control Protocol (DCCP) Congestion 1135 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 1136 March 2006. 1138 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1139 Security", RFC 4347, April 2006. 1141 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 1142 Congestion Control (TFMCC): Protocol Specification", 1143 RFC 4654, August 2006. 1145 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1146 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1148 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1149 RFC 4960, September 2007. 1151 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1152 Errors at High Data Rates", RFC 4963, July 2007. 1154 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1155 Mitigations", RFC 4987, August 2007. 1157 [STEVENS] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network 1158 Programming, The sockets Networking API", Addison-Wesley, 1159 2004. 1161 [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. 1163 [UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized 1164 Device Control Protocol V 1.0", November 2001. 1166 Authors' Addresses 1168 Lars Eggert 1169 Nokia Research Center 1170 P.O. Box 407 1171 Nokia Group 00045 1172 Finland 1174 Phone: +358 50 48 24461 1175 Email: lars.eggert@nokia.com 1176 URI: http://research.nokia.com/people/lars_eggert/ 1178 Godred Fairhurst 1179 University of Aberdeen 1180 Department of Engineering 1181 Fraser Noble Building 1182 Aberdeen AB24 3UE 1183 Scotland 1185 Email: gorry@erg.abdn.ac.uk 1186 URI: http://www.erg.abdn.ac.uk/ 1188 Full Copyright Statement 1190 Copyright (C) The IETF Trust (2008). 1192 This document is subject to the rights, licenses and restrictions 1193 contained in BCP 78, and except as set forth therein, the authors 1194 retain all their rights. 1196 This document and the information contained herein are provided on an 1197 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1198 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1199 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1200 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1201 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1202 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1204 Intellectual Property 1206 The IETF takes no position regarding the validity or scope of any 1207 Intellectual Property Rights or other rights that might be claimed to 1208 pertain to the implementation or use of the technology described in 1209 this document or the extent to which any license under such rights 1210 might or might not be available; nor does it represent that it has 1211 made any independent effort to identify any such rights. Information 1212 on the procedures with respect to rights in RFC documents can be 1213 found in BCP 78 and BCP 79. 1215 Copies of IPR disclosures made to the IETF Secretariat and any 1216 assurances of licenses to be made available, or the result of an 1217 attempt made to obtain a general license or permission for the use of 1218 such proprietary rights by implementers or users of this 1219 specification can be obtained from the IETF on-line IPR repository at 1220 http://www.ietf.org/ipr. 1222 The IETF invites any interested party to bring to its attention any 1223 copyrights, patents or patent applications, or other proprietary 1224 rights that may cover technology that may be required to implement 1225 this standard. Please address the information to the IETF at 1226 ietf-ipr@ietf.org.