idnits 2.17.1 draft-ietf-tsvwg-udp-guidelines-10.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 1214. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1225. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1232. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1238. 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 (August 22, 2008) is 5718 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-16 -- 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: February 23, 2009 University of Aberdeen 6 August 22, 2008 8 Unicast UDP Usage Guidelines for Application Designers 9 draft-ietf-tsvwg-udp-guidelines-10 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 February 23, 2009. 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 . . . . . . . . . . . . . . 15 60 3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 17 61 3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 18 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 63 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 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., a framework such as the Congestion Manager [RFC3124], 260 where active sessions may share current congestion information in a 261 way that is independent of the transport protocol. Such mechanisms 262 have failed to see deployment, but would otherwise simplify the 263 design of congestion control mechanisms for UDP sessions, so that 264 they fulfill the requirements in [RFC2914]. 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.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. Section 2 of [RFC3551] suggests that 289 applications SHOULD monitor the packet loss rate to ensure that it is 290 within acceptable parameters. Packet loss is considered acceptable 291 if a TCP flow across the same network path under the same network 292 conditions would achieve an average throughput, measured on a 293 reasonable timescale, that is not less than that of the UDP flow. 294 The comparison to TCP cannot be specified exactly, but is intended as 295 an "order-of-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 either independently detect 369 and respond to congestion along both directions, or limit new and 370 retransmitted requests based on acknowledged responses across the 371 entire round trip path. 373 3.1.3. UDP Tunnels 375 One increasingly popular use of UDP is as a tunneling protocol, where 376 a tunnel endpoint encapsulates the packets of another protocol inside 377 UDP datagrams and transmits them to another tunnel endpoint, which 378 decapsulates the UDP datagrams and forwards the original packets 379 contained in the payload. Tunnels establish virtual links that 380 appear to directly connect locations that are distant in the physical 381 Internet topology, and can be used to create virtual (private) 382 networks. Using UDP as a tunneling protocol is attractive when the 383 payload protocol is not supported by middleboxes that may exist along 384 the path, because many middleboxes support UDP transmissions. 386 Well-implemented tunnels are generally invisible to the endpoints 387 that happen to transmit over a path that includes tunneled links. On 388 the other hand, to the routers along the path of a UDP tunnel, i.e., 389 the routers between the two tunnel endpoints, the traffic that a UDP 390 tunnel generates is a regular UDP flow, and the encapsulator and 391 decapsulator appear as regular UDP-sending and -receiving 392 applications. Because other flows can share the path with one or 393 more UDP tunnels, congestion control needs to be considered. 395 Two factors determine whether a UDP tunnel needs to employ specific 396 congestion control mechanisms. First, whether the tunneling scheme 397 generates UDP traffic at a volume that corresponds to the volume of 398 payload traffic carried within the tunnel. Second, whether the 399 payload traffic is IP-based. 401 IP-based traffic is generally assumed to be congestion-controlled, 402 i.e., it is assumed that the transport protocols generating IP-based 403 traffic at the sender already employ mechanisms that are sufficient 404 to address congestion on the path. Consequently, a tunnel carrying 405 IP-based traffic should already interact appropriately with other 406 traffic sharing the path, and specific congestion control mechanism 407 for the tunnel are not necessary. 409 However, if the IP traffic in the tunnel is known to not be 410 congestion-controlled, additional measures are RECOMMENDED in order 411 to limit the impact of the tunneled traffic on other traffic sharing 412 the path. 414 The following guidelines define these possible cases in more detail: 416 1. A tunnel generates UDP traffic at a volume that corresponds to 417 the volume of payload traffic, and the payload traffic is IP- 418 based and congestion-controlled. 420 This is arguably the most common case for Internet tunnels. In 421 this case, the UDP tunnel SHOULD NOT employ its own congestion 422 control mechanism, because congestion losses of tunneled traffic 423 will already trigger an appropriate congestion response at the 424 original senders of the tunneled traffic. 426 Note that this guideline is built on the assumption that most IP- 427 based communication is congestion-controlled. If a UDP tunnel is 428 used for IP-based traffic that is known to not be congestion- 429 controlled, the next set of guidelines applies: 431 2. A tunnel generates UDP traffic at a volume that corresponds to 432 the volume of payload traffic, and the payload traffic is not 433 known to be IP-based, or is known to be IP-based but not 434 congestion-controlled. 436 This can be the case, for example, when some link-layer protocols 437 are encapsulated within UDP (but not all link-layer protocols; 438 some are congestion-controlled.) Because it is not known that 439 congestion losses of tunneled non-IP traffic will trigger an 440 appropriate congestion response at the senders, the UDP tunnel 441 SHOULD employ an appropriate congestion control mechanism. 442 Because tunnels are usually bulk-transfer applications as far as 443 the intermediate routers are concerned, the guidelines in 444 Section 3.1.1 apply. 446 3. A tunnel generates UDP traffic at a volume that does not 447 correspond to the volume of payload traffic, independent of 448 whether the payload traffic is IP-based or congestion-controlled. 450 Examples of this class include UDP tunnels that send at a 451 constant rate, increase their transmission rates under loss, for 452 example, due to increasing redundancy when forward-error- 453 correction is used, or are otherwise constrained in their 454 transmission behavior. These specialized uses of UDP for 455 tunneling go beyond the scope of the general guidelines given in 456 this document. The implementer of such specialized tunnels 457 SHOULD carefully consider congestion control in the design of 458 their tunneling mechanism. 460 Designing a tunneling mechanism requires significantly more expertise 461 than needed for many other UDP applications, because tunnels 462 virtualize lower-layer components of the Internet, and the 463 virtualized components need to correctly interact with the 464 infrastructure at that layer. This document only touches upon the 465 congestion control considerations for implementing UDP tunnels; a 466 discussion of other required tunneling behavior is out of scope. 468 3.2. Message Size Guidelines 470 IP fragmentation lowers the efficiency and reliability of Internet 471 communication. The loss of a single fragment results in the loss of 472 an entire fragmented packet, because even if all other fragments are 473 received correctly, the original packet cannot be reassembled and 474 delivered. This fundamental issue with fragmentation exists for both 475 IPv4 and IPv6. In addition, some NATs and firewalls drop IP 476 fragments. The network address translation performed by a NAT only 477 operates on complete IP packets, and some firewall policies also 478 require inspection of complete IP packets. Even with these being the 479 case, some NATs and firewalls simply do not implement the necessary 480 reassembly functionality, and instead choose to drop all fragments. 481 Finally, [RFC4963] documents other issues specific to IPv4 482 fragmentation. 484 Due to these issues, an application SHOULD NOT send UDP datagrams 485 that result in IP packets that exceed the MTU of the path to the 486 destination. Consequently, an application SHOULD either use the path 487 MTU information provided by the IP layer or implement path MTU 488 discovery itself [RFC1191][RFC1981][RFC4821] to determine whether the 489 path to a destination will support its desired message size without 490 fragmentation. 492 Applications that do not follow this recommendation to do PMTU 493 discovery SHOULD still avoid sending UDP datagrams that would result 494 in IP packets that exceed the path MTU. Because the actual path MTU 495 is unknown, such applications SHOULD fall back to sending messages 496 that are shorter that the default effective MTU for sending (EMTU_S 497 in [RFC1122]). For IPv4, EMTU_S is the smaller of 576 bytes and the 498 first-hop MTU [RFC1122]. For IPv6, EMTU_S is 1280 bytes [RFC2460]. 499 The effective PMTU for a directly connected destination (with no 500 routers on the path) is the configured interface MTU, which could be 501 less than the maximum link payload size. Transmission of minimum- 502 sized UDP datagrams is inefficient over paths that support a larger 503 PMTU, which is a second reason to implement PMTU discovery. 505 To determine an appropriate UDP payload size, applications MUST 506 subtract the size of the IP header (which includes any IPv4 optional 507 headers or IPv6 extension headers) as well as the length of the UDP 508 header (8 bytes) from the PMTU size. This size, known as the MMS_S, 509 can be obtained from the TCP/IP stack [RFC1122]. 511 Applications that do not send messages that exceed the effective PMTU 512 of IPv4 or IPv6 need not implement any of the above mechanisms. Note 513 that the presence of tunnels can cause an additional reduction of the 514 effective PMTU, so implementing PMTU discovery will still be 515 beneficial in some cases. 517 Applications that fragment an application-layer message into multiple 518 UDP datagrams SHOULD perform this fragmentation so that each datagram 519 can be received independently, and be independently retransmitted in 520 the case where an application implements its own reliability 521 mechanisms. 523 3.3. Reliability Guidelines 525 Application designers are generally aware that UDP does not provide 526 any reliability, e.g., it does not retransmit any lost packets. 527 Often, this is a main reason to consider UDP as a transport. 528 Applications that do require reliable message delivery MUST implement 529 an appropriate mechanism themselves. 531 UDP also does not protect against datagram duplication, i.e., an 532 application may receive multiple copies of the same UDP datagram. 533 Application designers SHOULD verify that their application handles 534 datagram duplication gracefully, and may consequently need to 535 implement mechanisms to detect duplicates. Even if UDP datagram 536 reception triggers idempotent operations, applications may want to 537 suppress duplicate datagrams to reduce load. 539 In addition, the Internet can significantly delay some packets with 540 respect to others, e.g., due to routing transients, intermittent 541 connectivity, or mobility. This can cause reordering, where UDP 542 datagrams arrive at the receiver in an order different from the 543 transmission order. Applications that require ordered delivery MUST 544 reestablish datagram ordering themselves. 546 Finally, it is important to note that delay spikes can be very large. 547 This can cause reordered packets to arrive many seconds after they 548 were sent. [RFC0793] defines the the maximum delay a TCP segment 549 should experience - the Maximum Segment Lifetime (MSL) - as 2 550 minutes. No other RFC defines an MSL for other transport protocols 551 or IP itself. This document clarifies that the MSL value to be used 552 for UDP SHOULD be the same 2 minutes as for TCP. Applications SHOULD 553 be robust to the reception of delayed or duplicate packets that are 554 received within this 2-minute interval. 556 An application that requires reliable and ordered message delivery 557 SHOULD choose an IETF standard transport protocol that provides these 558 features. If this is not possible, it will need to implement a set 559 of appropriate mechanisms itself. 561 3.4. Checksum Guidelines 563 The UDP header includes an optional, 16-bit ones-complement checksum 564 that provides an integrity check. This results in a relatively weak 565 protection from in terms of coding theory [RFC3819] and application 566 developers SHOULD implement additional checks where data integrity is 567 important, e.g., through a Cyclic Redundancy Check (CRC) included 568 with the data to verify the integrity of an entire object/file sent 569 over UDP service. 571 The UDP checksum provides a statistical guarantee that the payload 572 was not corrupted in transit. It also allows the receiver to verify 573 that it was the intended destination of the packet, because it covers 574 the IP addresses, port numbers and protocol number, and it verifies 575 that the packet is not truncated or padded, because it covers the 576 size field. It therefore protects an application against receiving 577 corrupted payload data in place of, or in addition to, the data that 578 was sent. This check is not strong from a coding or cryptographic 579 perspective, and is not designed to detect physical-layer errors or 580 malicious modification of the datagram [RFC3819]. 582 Applications SHOULD enable UDP checksums, although [RFC0768] permits 583 the option to disable their use. Applications that choose to disable 584 UDP checksums when transmitting over IPv4 therefore MUST NOT make 585 assumptions regarding the correctness of received data and MUST 586 behave correctly when a UDP datagram is received that was originally 587 sent to a different destination or is otherwise corrupted. The use 588 of the UDP checksum is REQUIRED when applications transmit UDP over 589 IPv6 [RFC2460]. 591 3.4.1. UDP-Lite 593 A special class of applications can derive benefit from having 594 partially damaged payloads delivered, rather than discarded, when 595 using paths that include error-prone links. Such applications can 596 tolerate payload corruption and MAY choose to use the Lightweight 597 User Datagram Protocol (UDP-Lite) [RFC3828] variant of UDP instead of 598 basic UDP. Applications that choose to use UDP-Lite instead of UDP 599 should still follow the congestion control and other guidelines 600 described for use with UDP in Section 3. 602 UDP-Lite changes the semantics of the UDP "payload length" field to 603 that of a "checksum coverage length" field. Otherwise, UDP-Lite is 604 semantically identical to UDP. The interface of UDP-Lite differs 605 from that of UDP by the addition of a single (socket) option that 606 communicates a checksum coverage length value: at the sender, this 607 specifies the intended checksum coverage, with the remaining 608 unprotected part of the payload called the "error insensitive part". 609 By default, the UDP-Lite checksum coverage extends across the entire 610 datagram. If required, an application may dynamically modify this 611 length value, e.g., to offer greater protection to some messages. 612 UDP-Lite always verifies that a packet was delivered to the intended 613 destination, i.e., always verifies the header fields. Errors in the 614 insensitive part will not cause a UDP datagram to be discarded by the 615 destination. Applications using UDP-Lite therefore MUST NOT make 616 assumptions regarding the correctness of the data received in the 617 insensitive part of the UDP-Lite payload. 619 The sending application SHOULD select the minimum checksum coverage 620 to include all sensitive protocol headers. For example, applications 621 that use the Real-Time Protocol (RTP) [RFC3550] will likely want to 622 protect the RTP header against corruption. Applications, where 623 appropriate, MUST also introduce their own appropriate validity 624 checks for protocol information carried in the insensitive part of 625 the UDP-Lite payload (e.g., internal CRCs). 627 The receiver must set a minimum coverage threshold for incoming 628 packets that is not smaller than the smallest coverage used by the 629 sender [RFC3828]. The receiver SHOULD select a threshold that is 630 sufficiently large to block packets with an inappropriately short 631 coverage field. This may be a fixed value, or may be negotiated by 632 an application. UDP-Lite does not provide mechanisms to negotiate 633 the checksum coverage between the sender and receiver. 635 Applications may still experience packet loss, rather than 636 corruption, when using UDP-Lite. The enhancements offered by UDP- 637 Lite rely upon a link being able to intercept the UDP-Lite header to 638 correctly identify the partial coverage required. When tunnels 639 and/or encryption are used, this can result in UDP-Lite datagrams 640 being treated the same as UDP datagrams, i.e., result in packet loss. 641 Use of IP fragmentation can also prevent special treatment for UDP- 642 Lite datagrams, and is another reason why applications SHOULD avoid 643 IP fragmentation (Section 3.2). 645 3.5. Middlebox Traversal Guidelines 647 Network address translators (NATs) and firewalls are examples of 648 intermediary devices ("middleboxes") that can exist along an end-to- 649 end path. A middlebox typically performs a function that requires it 650 to maintain per-flow state. For connection-oriented protocols, such 651 as TCP, middleboxes snoop and parse the connection-management traffic 652 and create and destroy per-flow state accordingly. For a 653 connectionless protocol such as UDP, this approach is not possible. 654 Consequently, middleboxes may create per-flow state when they see a 655 packet that indicates a new flow, and destroy the state after some 656 period of time during which no packets belonging to the same flow 657 have arrived. 659 Depending on the specific function that the middlebox performs, this 660 behavior can introduce a time-dependency that restricts the kinds of 661 UDP traffic exchanges that will be successful across the middlebox. 662 For example, NATs and firewalls typically define the partial path on 663 one side of them to be interior to the domain they serve, whereas the 664 partial path on their other side is defined to be exterior to that 665 domain. Per-flow state is typically created when the first packet 666 crosses from the interior to the exterior, and while the state is 667 present, NATs and firewalls will forward return traffic. Return 668 traffic arriving after the per-flow state has timed out is dropped, 669 as is other traffic arriving from the exterior. 671 Many applications that use UDP for communication operate across 672 middleboxes without needing to employ additional mechanisms. One 673 example is the Domain Name System (DNS), which has a strict request- 674 response communication pattern that typically completes within 675 seconds. 677 Other applications may experience communication failures when 678 middleboxes destroy the per-flow state associated with an application 679 session during periods when the application does not exchange any UDP 680 traffic. Applications SHOULD be able to gracefully handle such 681 communication failures and implement mechanisms to re-establish 682 application-layer sessions and state. 684 For some applications, such as media transmissions, this re- 685 synchronization is highly undesirable, because it can cause user- 686 perceivable playback artifacts. Such specialized applications MAY 687 send periodic keep-alive messages to attempt to refresh middlebox 688 state. It is important to note that keep-alive messages are NOT 689 RECOMMENDED for general use - they are unnecessary for many 690 applications and can consume significant amounts of system and 691 network resources. 693 An application that needs to employ keep-alives to deliver useful 694 service over UDP in the presence of middleboxes SHOULD NOT transmit 695 them more frequently than once every 15 seconds and SHOULD use longer 696 intervals when possible. No common timeout has been specified for 697 per-flow UDP state for arbitrary middleboxes. For NATs, [RFC4787] 698 requires a state timeout of 2 minutes or longer. However, empirical 699 evidence suggests that a significant fraction of the deployed 700 middleboxes unfortunately uses shorter timeouts. The timeout of 15 701 seconds originates with the Interactive Connectivity Establishment 702 (ICE) protocol [I-D.ietf-mmusic-ice]. When applications are deployed 703 in more controlled network environments, the deployers SHOULD 704 investigate whether the target environment allows applications to use 705 longer intervals, or whether it offers mechanisms to explicitly 706 control middlebox state timeout durations, for example, using MIDCOM 707 [RFC3303], NSIS [I-D.ietf-nsis-nslp-natfw] or UPnP [UPNP]. It is 708 RECOMMENDED that applications apply slight random variations 709 ("jitter") to the timing of keep-alive transmissions, in order to 710 reduce the potential for persistent synchronization between keep- 711 alive transmissions from different hosts. 713 Sending keep-alives is not a substitute for implementing robust 714 connection handling. Like all UDP datagrams, keep-alives can be 715 delayed or dropped, causing middlebox state to time out. In 716 addition, the congestion control guidelines in Section 3.1 cover all 717 UDP transmissions by an application, including the transmission of 718 middlebox keep-alives. Congestion control may thus lead to delays or 719 temporary suspension of keep-alive transmission. 721 Keep-alive messages are NOT RECOMMENDED for general use. They are 722 unnecessary for many applications and can consume significant amounts 723 of system and network resources. For example, on battery-powered 724 devices, if an application needs to maintain connectivity for long 725 periods with little traffic, the frequency at which keep-alives are 726 sent can become the determining factor that governs power 727 consumption, depending on the underlying network technology. Because 728 many middleboxes are designed to require keep-alives for TCP 729 connections at a frequency that is much lower than that needed for 730 UDP, this difference alone can often be sufficient to prefer TCP over 731 UDP for these deployments. On the other hand, there is anecdotal 732 evidence that suggests that direct communication through middleboxes, 733 e.g., by using ICE [I-D.ietf-mmusic-ice], does succeed less often 734 with TCP than with UDP. The tradeoffs between different transport 735 protocols - especially when it comes to middlebox traversal - deserve 736 careful analysis. 738 3.6. Programming Guidelines 740 The de facto standard application programming interface (API) for 741 TCP/IP applications is the "sockets" interface [POSIX]. Although 742 this API was developed for UNIX in the early 1980s, a wide variety of 743 non-UNIX operating systems also implements it. The sockets API 744 supports both IPv4 and IPv6 [RFC3493]. The UDP sockets API differs 745 from that for TCP in several key ways. Because application 746 programmers are typically more familiar with the TCP sockets API, the 747 remainder of this section discusses these differences. [STEVENS] 748 provides usage examples of the UDP sockets API. 750 UDP datagrams may be directly sent and received, without any 751 connection setup. Using the sockets API, applications can receive 752 packets from more than one IP source address on a single UDP socket. 753 Some servers use this to exchange data with more than one remote host 754 through a single UDP socket at the same time. When applications need 755 to ensure that they receive packets from a particular source address, 756 they MUST implement corresponding checks at the application layer or 757 explicitly request that the operating system filter the received 758 packets. 760 If a client/server application executes on a host with more than one 761 IP interface, the application SHOULD send any UDP responses with an 762 IP source address that matches the IP destination address of the UDP 763 datagram that carried the request (see [RFC1122], Section 4.1.3.5). 764 Many middleboxes expect this transmission behavior and drop replies 765 that are sent from a different IP address, as explained in 766 Section 3.5. 768 A UDP receiver can receive a valid UDP datagram with a zero-length 769 payload. Note that this is different from a return value of zero 770 from a read() socket call, which for TCP indicates the end of the 771 connection. 773 Many operating systems also allow a UDP socket to be connected, i.e., 774 to bind a UDP socket to a specific pair of addresses and ports. This 775 is similar to the corresponding TCP sockets API functionality. 776 However, for UDP, this is only a local operation that serves to 777 simplify the local send/receive functions and to filter the traffic 778 for the specified addresses and ports. Binding a UDP socket does not 779 establish a connection - UDP does not notify the remote end when a 780 local UDP socket is bound. Binding a socket also allows configuring 781 options that affect the UDP or IP layers, for example, use of the UDP 782 checksum or the IP Time Stamp Option. On some stacks, a bound socket 783 also allows an application to be notified when ICMP error messages 784 are received for its transmissions [RFC1122]. 786 UDP provides no flow-control. This is another reason why UDP-based 787 applications need to be robust in the presence of packet loss. This 788 loss can also occur within the sending host, when an application 789 sends data faster than the line rate of the outbound network 790 interface. It can also occur on the destination, where receive calls 791 fail to return all the data that was sent when the application issues 792 them too infrequently (i.e., such that the receive buffer overflows). 793 Robust flow control mechanisms are difficult to implement, which is 794 why applications that need this functionality SHOULD consider using a 795 full-featured transport protocol. 797 When an application closes a TCP, SCTP or DCCP socket, the transport 798 protocol on the receiving host is required to maintain TIME-WAIT 799 state. This prevents delayed packets from the closed connection 800 instance from being mistakenly associated with a later connection 801 instance that happens to reuse the same IP address and port pairs. 802 The UDP protocol does not implement such a mechanism. Therefore, 803 UDP-based applications need to be robust in this case. One 804 application may close a socket or terminate, followed in time by 805 another application receiving on the same port. This later 806 application may then receive packets intended for the first 807 application that were delayed in the network. 809 3.7. ICMP Guidelines 811 Applications can utilize information about ICMP error messages that 812 the UDP layer passes up for a variety of purposes [RFC1122]. 813 Applications SHOULD validate that the information in the ICMP message 814 payload, e.g., a reported error condition, corresponds to a UDP 815 datagram that the application actually sent. Note that not all APIs 816 have the necessary functions to support this validation, and some 817 APIs already perform this validation internally before passing ICMP 818 information to the application. 820 Any application response to ICMP error messages SHOULD be robust to 821 temporary routing failures, i.e., transient ICMP "unreachable" 822 messages should not normally cause a communication abort. 823 Applications SHOULD appropriately process ICMP messages generated in 824 response to transmitted traffic. A correct response often requires 825 context, such as local state about communication instances to each 826 destination, that although readily available in connection-oriented 827 transport protocols is not always maintained by UDP-based 828 applications. 830 4. Security Considerations 832 UDP does not provide communications security. Applications that need 833 to protect their communications against eavesdropping, tampering, or 834 message forgery SHOULD employ end-to-end security services provided 835 by other IETF protocols. Applications that respond to short requests 836 with potentially large responses are vulnerable to amplification 837 attacks, and SHOULD authenticate the sender before responding. The 838 source IP address of a request is not a useful authenticator, because 839 it can be spoofed. 841 One option of securing UDP communications is with IPsec [RFC4301], 842 which can provide authentication for flows of IP packets through the 843 Authentication Header (AH) [RFC4302] and encryption and/or 844 authentication through the Encapsulating Security Payload (ESP) 845 [RFC4303]. Applications use the Internet Key Exchange (IKE) 846 [RFC4306] to configure IPsec for their sessions. Depending on how 847 IPsec is configured for a flow, it can authenticate or encrypt the 848 UDP headers as well as UDP payloads. If an application only requires 849 authentication, ESP with no encryption but with authentication is 850 often a better option than AH, because ESP can operate across 851 middleboxes. In order to be able to use IPsec, an application must 852 execute on an operating system that implements the IPsec protocol 853 suite. 855 Although it is possible to use IPsec to secure UDP communications, 856 not all operating systems support IPsec or allow applications to 857 easily configure it for their flows. A second option of securing UDP 858 communications is through Datagram Transport Layer Security (DTLS) 859 [RFC4347]. DTLS provides communication privacy by encrypting UDP 860 payloads. It does not protect the UDP headers. Applications can 861 implement DTLS without relying on support from the operating system. 863 Many other options for authenticating or encrypting UDP payloads 864 exist. For example, the GSS-API security framework [RFC2743] or 865 Cryptographic Message Syntax (CMS) [RFC3852] could be used to protect 866 UDP payloads. The IETF standard for securing RTP [RFC3550] realtime 867 communication sessions over UDP is SRTP [RFC3711]. In some 868 applications, a better solution is to protect larger standalone 869 objects, such as files or messages, instead of individual UDP 870 payloads. In these situations, CMS [RFC3852], S/MIME [RFC3851] or 871 OpenPGP [RFC4880] could be used. In addition, there are many non- 872 IETF protocols in this area. 874 Like congestion control mechanisms, security mechanisms are difficult 875 to design and implement correctly. It is hence RECOMMENDED that 876 applications employ well-known standard security mechanisms such as 877 DTLS or IPsec, rather than inventing their own. 879 In terms of congestion control, [RFC2309] and [RFC2914] discuss the 880 dangers of congestion-unresponsive flows to the Internet. This 881 document provides guidelines to designers of UDP-based applications 882 to congestion-control their transmissions, and does not raise any 883 additional security concerns. 885 5. Summary 887 This section summarizes the guidelines made in Section 3 and 888 Section 4 in a tabular format in Table 1 for easy referencing. 890 +---------------------------------------------------------+---------+ 891 | Recommendation | Section | 892 +---------------------------------------------------------+---------+ 893 | MUST tolerate wide range of Internet path conditions | 3 | 894 | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | | 895 | | | 896 | SHOULD control rate of transmission | 3.1 | 897 | SHOULD perform congestion control over all traffic | | 898 | | | 899 | for bulk transfers, | 3.1.1 | 900 | SHOULD consider implementing TFRC | | 901 | else, SHOULD otherwise use bandwidth similar to TCP | | 902 | | | 903 | for non-bulk transfers, | 3.1.2 | 904 | SHOULD measure RTT and transmit max. 1 datagram/RTT | | 905 | else, SHOULD send at most 1 datagram every 3 seconds | | 906 | | | 907 | SHOULD NOT send datagrams that exceed the PMTU, i.e., | 3.2 | 908 | SHOULD discover PMTU or send datagrams < minimum PMTU | | 909 | | | 910 | SHOULD handle datagram loss, duplication, reordering | 3.3 | 911 | SHOULD be robust to delivery delays up to 2 minutes | | 912 | | | 913 | SHOULD enable UDP checksum | 3.4 | 914 | else, MAY use UDP-Lite with suitable checksum coverage | 3.4.1 | 915 | | | 916 | SHOULD NOT always send middlebox keep-alives | 3.5 | 917 | MAY use keep-alives when needed (min. interval 15 sec) | | 918 | | | 919 | MUST check IP source address | 3.6 | 920 | and, for client/server applications | | 921 | SHOULD send responses from src address matching request | | 922 | | | 923 | SHOULD use standard IETF security protocols when needed | 4 | 924 +---------------------------------------------------------+---------+ 926 Table 1: Summary of recommendations. 928 6. IANA Considerations 930 This document raises no IANA considerations. 932 (Note to the RFC Editor: Please remove this section upon 933 publication.) 935 7. Acknowledgments 937 Thanks to Paul Aitken, Mark Allman, Francois Audet, Iljitsch van 938 Beijnum, Stewart Bryant, Remi Denis-Courmont, Wesley Eddy, Pasi 939 Eronen, Sally Floyd, Robert Hancock, Jeffrey Hutzelman, Cullen 940 Jennings, Tero Kivinen, Peter Koch, Jukka Manner, Philip Matthews, 941 Joerg Ott, Colin Perkins, Tom Petch, Carlos Pignataro, Pasi 942 Sarolahti, Pascal Thubert, Joe Touch and Magnus Westerlund for their 943 comments on this document. 945 The middlebox traversal guidelines in Section 3.5 incorporate ideas 946 from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda Srisuresh 947 and Dan Kegel. 949 Lars Eggert is partly funded by [TRILOGY], a research project 950 supported by the European Commission under its Seventh Framework 951 Program. 953 8. References 955 8.1. Normative References 957 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 958 August 1980. 960 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 961 RFC 793, September 1981. 963 [RFC1122] Braden, R., "Requirements for Internet Hosts - 964 Communication Layers", STD 3, RFC 1122, October 1989. 966 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 967 November 1990. 969 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 970 for IP version 6", RFC 1981, August 1996. 972 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 973 Requirement Levels", BCP 14, RFC 2119, March 1997. 975 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 976 (IPv6) Specification", RFC 2460, December 1998. 978 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 979 RFC 2914, September 2000. 981 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 982 Timer", RFC 2988, November 2000. 984 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 985 Friendly Rate Control (TFRC): Protocol Specification", 986 RFC 3448, January 2003. 988 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 989 G. Fairhurst, "The Lightweight User Datagram Protocol 990 (UDP-Lite)", RFC 3828, July 2004. 992 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 993 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 994 RFC 4787, January 2007. 996 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 997 Discovery", RFC 4821, March 2007. 999 8.2. Informative References 1001 [FABER] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT State in 1002 TCP and Its Effect on Busy Servers", Proc. IEEE Infocom, 1003 March 1999. 1005 [I-D.ford-behave-app] 1006 Ford, B., "Application Design Guidelines for Traversal 1007 through Network Address Translators", 1008 draft-ford-behave-app-05 (work in progress), March 2007. 1010 [I-D.ietf-dccp-ccid4] 1011 Floyd, S. and E. Kohler, "Profile for Datagram Congestion 1012 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly 1013 Rate Control for Small Packets (TFRC-SP)", 1014 draft-ietf-dccp-ccid4-02 (work in progress), 1015 February 2008. 1017 [I-D.ietf-dccp-rfc3448bis] 1018 Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 1019 Friendly Rate Control (TFRC): Protocol Specification", 1020 draft-ietf-dccp-rfc3448bis-06 (work in progress), 1021 April 2008. 1023 [I-D.ietf-mmusic-ice] 1024 Rosenberg, J., "Interactive Connectivity Establishment 1025 (ICE): A Protocol for Network Address Translator (NAT) 1026 Traversal for Offer/Answer Protocols", 1027 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1029 [I-D.ietf-nsis-nslp-natfw] 1030 Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 1031 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 1032 draft-ietf-nsis-nslp-natfw-18 (work in progress), 1033 February 2008. 1035 [I-D.ietf-nsis-ntlp] 1036 Schulzrinne, H. and R. Hancock, "GIST: General Internet 1037 Signalling Transport", draft-ietf-nsis-ntlp-16 (work in 1038 progress), July 2008. 1040 [POSIX] IEEE Std. 1003.1-2001, "Standard for Information 1041 Technology - Portable Operating System Interface (POSIX)", 1042 Open Group Technical Standard: Base Specifications Issue 1043 6, ISO/IEC 9945:2002, December 2001. 1045 [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", 1046 RFC 896, January 1984. 1048 [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, 1049 RFC 919, October 1984. 1051 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1052 RFC 1112, August 1989. 1054 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 1055 Miller, "Common DNS Implementation Errors and Suggested 1056 Fixes", RFC 1536, October 1993. 1058 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 1059 Anycasting Service", RFC 1546, November 1993. 1061 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 1062 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 1063 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 1064 S., Wroclawski, J., and L. Zhang, "Recommendations on 1065 Queue Management and Congestion Avoidance in the 1066 Internet", RFC 2309, April 1998. 1068 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1069 RFC 2675, August 1999. 1071 [RFC2743] Linn, J., "Generic Security Service Application Program 1072 Interface Version 2, Update 1", RFC 2743, January 2000. 1074 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 1075 Floyd, S., and M. Luby, "Reliable Multicast Transport 1076 Building Blocks for One-to-Many Bulk-Data Transfer", 1077 RFC 3048, January 2001. 1079 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 1080 RFC 3124, June 2001. 1082 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1083 A., Peterson, J., Sparks, R., Handley, M., and E. 1084 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1085 June 2002. 1087 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 1088 A. Rayhan, "Middlebox communication architecture and 1089 framework", RFC 3303, August 2002. 1091 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1092 Stevens, "Basic Socket Interface Extensions for IPv6", 1093 RFC 3493, February 2003. 1095 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1096 Jacobson, "RTP: A Transport Protocol for Real-Time 1097 Applications", STD 64, RFC 3550, July 2003. 1099 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1100 Video Conferences with Minimal Control", STD 65, RFC 3551, 1101 July 2003. 1103 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1104 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1105 RFC 3711, March 2004. 1107 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 1108 Control (WEBRC) Building Block", RFC 3738, April 2004. 1110 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 1111 Conrad, "Stream Control Transmission Protocol (SCTP) 1112 Partial Reliability Extension", RFC 3758, May 2004. 1114 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1115 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1116 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1117 RFC 3819, July 2004. 1119 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1120 Extensions (S/MIME) Version 3.1 Message Specification", 1121 RFC 3851, July 2004. 1123 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1124 RFC 3852, July 2004. 1126 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1127 Internet Protocol", RFC 4301, December 2005. 1129 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1130 December 2005. 1132 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1133 RFC 4303, December 2005. 1135 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1136 RFC 4306, December 2005. 1138 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1139 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1141 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 1142 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 1143 Congestion Control", RFC 4341, March 2006. 1145 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 1146 Datagram Congestion Control Protocol (DCCP) Congestion 1147 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 1148 March 2006. 1150 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1151 Security", RFC 4347, April 2006. 1153 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 1154 Congestion Control (TFMCC): Protocol Specification", 1155 RFC 4654, August 2006. 1157 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1158 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1160 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1161 RFC 4960, September 2007. 1163 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1164 Errors at High Data Rates", RFC 4963, July 2007. 1166 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1167 Mitigations", RFC 4987, August 2007. 1169 [STEVENS] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network 1170 Programming, The sockets Networking API", Addison-Wesley, 1171 2004. 1173 [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. 1175 [UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized 1176 Device Control Protocol V 1.0", November 2001. 1178 Authors' Addresses 1180 Lars Eggert 1181 Nokia Research Center 1182 P.O. Box 407 1183 Nokia Group 00045 1184 Finland 1186 Phone: +358 50 48 24461 1187 Email: lars.eggert@nokia.com 1188 URI: http://people.nokia.net/~lars/ 1190 Godred Fairhurst 1191 University of Aberdeen 1192 Department of Engineering 1193 Fraser Noble Building 1194 Aberdeen AB24 3UE 1195 Scotland 1197 Email: gorry@erg.abdn.ac.uk 1198 URI: http://www.erg.abdn.ac.uk/ 1200 Full Copyright Statement 1202 Copyright (C) The IETF Trust (2008). 1204 This document is subject to the rights, licenses and restrictions 1205 contained in BCP 78, and except as set forth therein, the authors 1206 retain all their rights. 1208 This document and the information contained herein are provided on an 1209 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1210 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1211 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1212 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1213 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1214 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1216 Intellectual Property 1218 The IETF takes no position regarding the validity or scope of any 1219 Intellectual Property Rights or other rights that might be claimed to 1220 pertain to the implementation or use of the technology described in 1221 this document or the extent to which any license under such rights 1222 might or might not be available; nor does it represent that it has 1223 made any independent effort to identify any such rights. Information 1224 on the procedures with respect to rights in RFC documents can be 1225 found in BCP 78 and BCP 79. 1227 Copies of IPR disclosures made to the IETF Secretariat and any 1228 assurances of licenses to be made available, or the result of an 1229 attempt made to obtain a general license or permission for the use of 1230 such proprietary rights by implementers or users of this 1231 specification can be obtained from the IETF on-line IPR repository at 1232 http://www.ietf.org/ipr. 1234 The IETF invites any interested party to bring to its attention any 1235 copyrights, patents or patent applications, or other proprietary 1236 rights that may cover technology that may be required to implement 1237 this standard. Please address the information to the IETF at 1238 ietf-ipr@ietf.org.