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