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