idnits 2.17.1 draft-ietf-tsvwg-udp-guidelines-04.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 1083. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1094. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1101. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1107. 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 (November 19, 2007) is 5995 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-00 == Outdated reference: A later version (-06) exists of draft-ietf-dccp-rfc3448bis-02 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-15 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-14 -- 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: May 22, 2008 November 19, 2007 8 UDP Usage Guidelines for Application Designers 9 draft-ietf-tsvwg-udp-guidelines-04 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 May 22, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The User Datagram Protocol (UDP) provides a minimal, message-passing 43 transport that has no inherent congestion control mechanisms. 44 Because congestion control is critical to the stable operation of the 45 Internet, applications and upper-layer protocols that choose to use 46 UDP as an Internet transport must employ mechanisms to prevent 47 congestion collapse and establish some degree of fairness with 48 concurrent traffic. This document provides guidelines on the use of 49 UDP for the designers of such applications and upper-layer protocols. 50 Congestion control guidelines are a primary focus, but the document 51 also provides guidance on other topics, including message sizes, 52 reliability, checksums and middlebox traversal. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 5 60 3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 10 61 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 10 62 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 11 63 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 13 64 3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 14 65 3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 16 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 67 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 74 Intellectual Property and Copyright Statements . . . . . . . . . . 25 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,487 bytes for 123 IPv6. The transmission of large IP packets usually requires IP 124 fragmentation. At least for IPv4, fragmentation decreases 125 communication reliability and efficiency and should be avoided. One 126 reason for this decrease in reliability is that many NATs and 127 firewalls do not forward IPv4 fragments; other reasons are documented 128 in [RFC4963]. Some of the guidelines in Section 3 describe how 129 applications should determine 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. A lost response from the peer SHOULD be treated 295 as a very large RTT sample, instead of being ignored, in order to 296 cause a sufficiently large (exponential) back-off. When implementing 297 this scheme, applications need to choose a sensible initial value for 298 the RTT. This value SHOULD generally be as conservative as possible 299 for the given application. TCP uses an initial value of 3 seconds 300 [RFC2988], which is also RECOMMENDED as an initial value for UDP 301 applications. SIP [RFC3261] and GIST [I-D.ietf-nsis-ntlp] use an 302 initial value of 500 ms, and initial timeouts that are shorter than 303 this are likely problematic in many cases. It is also important to 304 note that the initial timeout is not the maximum possible timeout - 305 the RECOMMENDED algorithm in [RFC2988] yields timeout values after a 306 series of losses that are much longer 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. This results in these possible cases: 369 1. Tunnel generates UDP traffic at a volume that corresponds to the 370 volume of payload traffic, and the payload traffic is IP-based. 372 This is arguably the most common case for Internet tunnels. In 373 this case, the UDP tunnel SHOULD NOT employ its own congestion 374 control mechanism, because congestion losses of tunneled traffic 375 will already trigger an appropriate congestion response at the 376 original senders of the tunneled traffic. 378 Note that this guideline is built on the assumption that most IP- 379 based communication is congestion-controlled. If a UDP tunnel is 380 used for IP-based traffic that is known to not be congestion- 381 controlled, the next set of guidelines applies: 383 2. Tunnel generates UDP traffic at a volume that corresponds to the 384 volume of payload traffic, and the payload traffic is not known 385 to be IP-based (or is known to be IP-based, but not congestion- 386 controlled). 388 This is the case, for example, when link-layer protocols are 389 encapsulated within UDP. Because it is not known that congestion 390 losses of tunneled non-IP traffic will trigger an appropriate 391 congestion response at the senders, the UDP tunnel SHOULD employ 392 an appropriate congestion control mechanism. Because tunnels are 393 usually bulk-transfer applications as far as the intermediate 394 routers are concerned, the guidelines in Section 3.1.1 apply. 396 3. Tunnel generates UDP traffic at a volume that does not correspond 397 to the volume of payload traffic, independent of whether the 398 payload traffic is IP-based or not. 400 Examples of this class include UDP tunnels that send at a 401 constant rate, increase their transmission rates under loss, for 402 example, due to increasing redundancy when forward-error- 403 correction is used, or are otherwise constrained in their 404 transmission behavior. These specialized uses of UDP for 405 tunneling go beyond the scope of the general guidelines given in 406 this document. The implementer of such specialized tunnels 407 SHOULD carefully consider congestion control in the design of 408 their tunneling mechanism. 410 Designing tunneling mechanism requires significantly more expertise 411 than needed for many other UDP applications, because tunnels 412 virtualize lower-layer components of the Internet, and the 413 virtualized components need to correctly interact with the 414 infrastructure at that layer. This document only touches upon the 415 congestion control considerations for implementing UDP tunnels; a 416 discussion of other required tunneling behavior is out of scope. 418 3.2. Message Size Guidelines 420 Because IPv4 fragmentation lowers the efficiency and reliability of 421 Internet communication [RFC4963], an application SHOULD NOT send UDP 422 messages that result in IPv4 packets that exceed the MTU of the path 423 to the destination. Consequently, an application SHOULD either use 424 the path MTU information provided by the IP layer or implement path 425 MTU discovery itself [RFC1191][RFC1981][RFC4821] to determine whether 426 the path to a destination will support its desired message size 427 without fragmentation. 429 Applications that choose to not adapt their transmit message size 430 SHOULD NOT send UDP messages that would result in IP datagrams that 431 exceed the effective PMTU. In the absence of actual knowledge of the 432 minimum MTU along the path, the effective PMTU depends upon the IP 433 version used for transmission. It is the smaller of 576 bytes and 434 the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for IPv6 435 [RFC2460]. The effective PMTU for a directly connected destination 436 (with no routers on the path) is the configured interface MTU, which 437 could be less than the maximum link payload size. Transmission of 438 minimum-sized messages is inefficient over paths that support a 439 larger PMTU, which is a second reason to implement PMTU discovery. 441 To determine an appropriate UDP payload size, applications MUST 442 subtract the size of the IP header (which includes any IPv4 optional 443 headers or IPv6 extension headers) as well as the length of the UDP 444 header (8 bytes) from the PMTU size. This size, known as the MMS_S, 445 can be obtained from the TCP/IP stack [RFC1122]. 447 Applications that do not send messages that exceed the effective PMTU 448 of IPv4 or IPv6 need not implement any of the above mechanisms. Note 449 that the presence of tunnels can cause fragmentation even when 450 applications send messages that do not exceed the effective PMTU, so 451 implementing PMTU discovery will still be beneficial in some cases. 453 3.3. Reliability Guidelines 455 Application designers are generally aware that UDP does not provide 456 any reliability, e.g., it does not retransmit any lost packets. 457 Often, this is a main reason to consider UDP as a transport. 458 Applications that do require reliable message delivery MUST implement 459 an appropriate mechanism themselves. 461 UDP also does not protect against message duplication, i.e., an 462 application may receive multiple copies of the same message. 463 Application designers SHOULD verify that their application handles 464 message duplication gracefully, and may consequently need to 465 implement mechanisms to detect duplicates. Even if message reception 466 triggers idempotent operations, applications may want to suppress 467 duplicate messages to reduce load. 469 In addition, the Internet can significantly delay some packets with 470 respect to others, e.g., due to routing transients, intermittent 471 connectivity, or mobility. This can cause message reordering, where 472 UDP messages arrive at the receiver in an order different from the 473 transmission order. Applications that require ordered delivery MUST 474 reestablish message ordering themselves. 476 Finally, it is important to note that delay spikes can be very large. 477 This can cause reordered packets to arrive many seconds after they 478 were sent. The Internet protocol suite defines the Maximum Segment 479 Lifetime (MSL) for TCP segments as 2 minutes [RFC0793]; this value 480 applies to all IP datagrams, and hence also to UDP. The MSL is the 481 maximum delay a packet should experience. Applications SHOULD be 482 robust to the reception of delayed or duplicate packets that are 483 received within this two-minute interval. 485 Applications that require reliable and ordered message delivery 486 SHOULD choose an IETF standard transport protocol that provides these 487 features. If this is not possible, it will need to implement a set 488 of appropriate mechanisms itself. 490 3.4. Checksum Guidelines 492 The UDP header includes an optional, 16-bit ones-complement checksum 493 that provides an integrity check. This results in a relatively weak 494 protection from a coding point of view [RFC3819] and application 495 developers SHOULD implement additional checks where data integrity is 496 important, e.g., through a Cyclic Redundancy Check (CRC) included 497 with the data to verify the integrity of an entire object/file sent 498 over UDP service. 500 The UDP checksum provides assurance that the payload was not 501 corrupted in transit. It also allows the receiver to verify that it 502 was the intended destination of the packet, because it covers the IP 503 addresses, port numbers and protocol number, and it verifies that the 504 packet is not truncated or padded, because it covers the size field. 505 It therefore protects an application against receiving corrupted 506 payload data in place of, or in addition to, the data that was sent. 508 Applications SHOULD enable UDP checksums, although [RFC0768] permits 509 the option to disable their use. Applications that choose to disable 510 UDP checksums when transmitting over IPv4 therefore MUST NOT make 511 assumptions regarding the correctness of received data and MUST 512 behave correctly when a message is received that was originally sent 513 to a different destination or is otherwise corrupted. The use of the 514 UDP checksum is MANDATORY when applications transmit UDP over IPv6 515 [RFC2460]. 517 3.4.1. UDP-Lite 519 A special class of applications can derive benefit from having 520 partially damaged payloads delivered, rather than discarded, when 521 using paths that include error-prone links. Such applications can 522 tolerate payload corruption and MAY choose to use the Lightweight 523 User Datagram Protocol (UDP-Lite) [RFC3828] variant of UDP instead of 524 basic UDP. Applications that choose to use UDP-Lite instead of UDP 525 MUST still follow the congestion control and other guidelines 526 described for use with UDP in Section 3. 528 UDP-Lite changes the semantics of the UDP "payload length" field to 529 that of a "checksum coverage length" field. Otherwise, UDP-Lite is 530 semantically identical to UDP. The interface of UDP-Lite differs 531 from that of UDP by the addition of a single (socket) option that 532 communicates a checksum coverage length value: at the sender, this 533 specifies the intended checksum coverage, with the remaining 534 unprotected part of the payload called the "error insensitive part". 535 If required, an application may dynamically modify this length value, 536 e.g., to offer greater protection to some messages. UDP-Lite always 537 verifies that a packet was delivered to the intended destination, 538 i.e., always verifies the header fields. Errors in the insensitive 539 part will not cause a UDP message to be discarded by the destination. 540 Applications using UDP-Lite therefore MUST NOT make assumptions 541 regarding the correctness of the data received in the insensitive 542 part of the UDP-Lite payload. 544 The sending application SHOULD select the minimum checksum coverage 545 to include all sensitive protocol headers. For example, applications 546 that use the Real-Time Protocol (RTP) [RFC3550] will likely want to 547 protect the RTP header against corruption. Applications, where 548 appropriate, MUST also introduce their own appropriate validity 549 checks for protocol information carried in the insensitive part of 550 the UDP-Lite payload (e.g., internal CRCs). 552 The receiver MUST set a minimum coverage threshold for incoming 553 packets that is not smaller than the smallest coverage used by the 554 sender. This may be a fixed value, or may be negotiated by an 555 application. UDP-Lite does not provide mechanisms to negotiate the 556 checksum coverage between the sender and receiver. 558 Applications may still experience packet loss, rather than 559 corruption, when using UDP-Lite. The enhancements offered by UDP- 560 Lite rely upon a link being able to intercept the UDP-Lite header to 561 correctly identify the partial-coverage required. When tunnels 562 and/or encryption are used, this can result in UDP-Lite messages 563 being treated the same as UDP messages, i.e., result in packet loss. 564 Use of IP fragmentation can also prevent special treatment for UDP- 565 Lite messages, and is another reason why applications SHOULD avoid IP 566 fragmentation Section 3.2. 568 3.5. Middlebox Traversal Guidelines 570 Network address translators (NATs) and firewalls are examples of 571 intermediary devices ("middleboxes") that can exist along an end-to- 572 end path. A middlebox typically performs a function that requires it 573 to maintain per-flow state. For connection-oriented protocols, such 574 as TCP, middleboxes snoop and parse the connection-management traffic 575 and create and destroy per-flow state accordingly. For a 576 connectionless protocol such as UDP, this approach is not possible. 577 Consequently, middleboxes may create per-flow state when they see a 578 packet that indicates a new flow, and destroy the state after some 579 period of time during which no packets belonging to the same flow 580 have arrived. 582 Depending on the specific function that the middlebox performs, this 583 behavior can introduce a time-dependency that restricts the kinds of 584 UDP traffic exchanges that will be successful across the middlebox. 585 For example, NATs and firewalls typically define the partial path on 586 one side of them to be interior to the domain they serve, whereas the 587 partial path on their other side is defined to be exterior to that 588 domain. Per-flow state is typically created when the first packet 589 crosses from the interior to the exterior, and while the state is 590 present, NATs and firewalls will forward return traffic. Return 591 traffic arriving after the per-flow state has timed out is dropped, 592 as is other traffic arriving from the exterior. 594 Many applications that use UDP for communication operate across 595 middleboxes without needing to employ additional mechanisms. One 596 example is the DNS, which has a strict request-response communication 597 pattern that typically completes within seconds. 599 Other applications may experience communication failures when 600 middleboxes destroy the per-flow state associated with an application 601 session during periods when the application does not exchange any UDP 602 traffic. Applications SHOULD be able to gracefully handle such 603 communication failures and implement mechanisms to re-establish 604 application-layer sessions and state. 606 For some applications, such as media transmissions, this re- 607 synchronization is highly undesirable, because it can cause user- 608 perceivable playback artifacts. Such specialized applications MAY 609 send periodic keep-alive messages to attempt to refresh middlebox 610 state. It is important to note that keep-alive messages are NOT 611 RECOMMENDED for general use - they are unnecessary for many 612 applications and can consume significant amounts of system and 613 network resources. 615 An application that needs to employ keep-alives to deliver useful 616 service in the presence of middleboxes SHOULD NOT transmit them more 617 frequently than once every 15 seconds and SHOULD use longer intervals 618 when possible. No common timeout has been specified for per-flow UDP 619 state for arbitrary middleboxes. For NATs, [RFC4787] requires a 620 state timeout of 2 minutes or longer. However, empirical evidence 621 suggests that a significant fraction of the deployed middleboxes 622 unfortunately uses shorter timeouts. The timeout of 15 seconds 623 originates with the Interactive Connectivity Establishment (ICE) 624 protocol [I-D.ietf-mmusic-ice]. Applications that operate in more 625 controlled network environments SHOULD investigate whether the 626 environment they operate in allows them to use longer intervals, or 627 whether it offers mechanisms to explicitly control middlebox state 628 timeout durations, for example, using MIDCOM [RFC3303], NSIS 629 [I-D.ietf-nsis-nslp-natfw], STUN 630 [I-D.wing-behave-nat-control-stun-usage] or UPnP [UPNP]. 632 It is important to note that sending keep-alives is not a substitute 633 for implementing robust connection handling. Like all UDP messages, 634 keep-alives can be delayed or dropped, causing middlebox state to 635 time out. In addition, the congestion control guidelines in 636 Section 3.1 cover all UDP transmissions by an application, including 637 the transmission of middlebox keep-alives. Congestion control may 638 thus lead to delays or temporary suspension of keep-alive 639 transmission. 641 3.6. Programming Guidelines 643 The de facto standard application programming interface (API) for 644 TCP/IP applications is the "sockets" interface [POSIX]. Although 645 this API was developed for UNIX in the early 1980s, a wide variety of 646 non-UNIX operating systems also implements it. The sockets API 647 supports both IPv4 and IPv6 [RFC3493]. The UDP sockets API differs 648 from that for TCP in several key ways. Because application 649 programmers are typically more familiar with the TCP sockets API, the 650 remainder of this section discusses these differences. [STEVENS] 651 provides usage examples of the UDP sockets API. 653 UDP messages may be directly sent and received, without any 654 connection setup. Using the sockets API, applications can receive 655 packets from more than one IP source address on a single UDP socket. 656 Some servers use this to exchange data with more than one remote host 657 through a single UDP socket at the same time. When applications need 658 to ensure that they receive packets from a particular source address, 659 they MUST implement corresponding checks at the application layer or 660 explicitly request that the operating system filter the received 661 packets. 663 If a client/server application executes on a host with more than one 664 IP interface, the application MUST ensure that it sends any UDP 665 responses in reply to arriving UDP datagrams with an IP source 666 address that matches the IP destination address of the datagram that 667 carried the request. 669 A UDP receiver can receive a valid UDP datagram with a zero-length 670 payload. Note that this is different from a return value of zero 671 from a read() socket call, which for TCP indicates the end of the 672 connection. 674 Many operating systems also allow a UDP socket to be connected, i.e., 675 to bind a UDP socket to a specific pair of addresses and ports. This 676 is similar to the corresponding TCP sockets API functionality. 677 However, for UDP, this is only a local operation that serves to 678 simplify the local send/receive functions and to filter the traffic 679 for the specified addresses and ports. Binding a UDP socket does not 680 establish a connection - UDP does not notify the remote end when a 681 local UDP socket is bound. Binding a socket also allows configuring 682 options that affect the UDP or IP layers, for example, use of the UDP 683 checksum or IP source routing. On some stacks, a bound socket also 684 allows an application to be notified when ICMP error messages are 685 received for its transmissions [RFC1122]. 687 UDP provides no flow-control. This is another reason why UDP-based 688 applications need to be robust in the presence of packet loss. This 689 loss can also occur within the sending host, when an application 690 sends data faster than the line rate of the outbound network 691 interface. It can also occur on the destination, where receive calls 692 fail to return data when the application issues them too frequently 693 (i.e., when no new data has arrived) or not frequently enough (i.e., 694 such that the receive buffer overflows). Robust flow control 695 mechanisms are difficult to implement, which is why applications that 696 need this functionality SHOULD consider using a full-featured 697 transport protocol. 699 When an application closes a TCP, SCTP or DCCP socket, the transport 700 protocol on the receiving host is required to maintain TIME-WAIT 701 state. This prevents delayed packets from the closed connection 702 instance from being mistakenly associated with a later connection 703 instance that happens to reuse the same IP address and port pairs. 704 The UDP protocol does not implement such a mechanism. Therefore, 705 UDP-based applications need to robust to this case. One application 706 may close a socket or terminate, followed in time by another 707 application receiving on the same port. This later application may 708 then receive packets intended for the first application that were 709 delayed in the network. 711 3.7. ICMP Guidelines 713 Applications can utilize ICMP error messages that the UDP layer 714 passes up for a variety of purposes [RFC1122]. Applications SHOULD 715 validate the information in the ICMP message payload, e.g., that the 716 reported error corresponds to a UDP datagram that the application 717 actually sent. 719 Any application response to ICMP error messages SHOULD be robust to 720 temporary routing failures, i.e., transient ICMP "unreachable" 721 messages should not normally cause a communication abort. 722 Applications are RECOMMENDED to appropriately respond to ICMP 723 messages generated in response to transmitted traffic. A correct 724 response often requires context, such as local state about 725 communication instances to each destination, that although readily 726 available in connection-orientated transport protocols is not always 727 maintained by UDP-based applications. 729 4. Security Considerations 731 UDP does not provide communications security. Applications that need 732 to protect their communications against eavesdropping, tampering, or 733 message forgery SHOULD employ end-to-end security services provided 734 by other IETF protocols. 736 One option of securing UDP communications is with IPsec [RFC4301], 737 which can provide authentication for flows of IP packets through the 738 Authentication Header (AH) [RFC4302] and encryption and/or 739 authentication through the Encapsulating Security Payload (ESP) 740 [RFC4303]. Applications use the Internet Key Exchange (IKE) 741 [RFC4306] to configure IPsec for their sessions. Depending on how 742 IPsec is configured for a flow, it can authenticate or encrypt the 743 UDP headers as well as UDP payloads. If an application only requires 744 authentication, ESP with no encryption but with authentication is 745 often a better option than AH, because ESP can operate across 746 middleboxes. In order to be able to use IPsec, an application must 747 execute on an operating system that implements the IPsec protocol 748 suite. 750 Although it is possible to use IPsec to secure UDP communications, 751 not all operating systems support IPsec or allow applications to 752 easily configure it for their flows. A second option of securing UDP 753 communications is through Datagram Transport Layer Security (DTLS) 754 [RFC4347]. DTLS provides communication privacy by encrypting UDP 755 payloads. It does not protect the UDP headers. Applications can 756 implement DTLS without relying on support from the operating system. 758 Many other options of authenticating or encrypting UDP payloads 759 exist, including other IETF standards, such as S/MIME [RFC3851] or 760 PGP [RFC4880], security frameworks such as GSS-API [RFC1964], SASL 761 [RFC4422] and EAP [RFC3748], as well as many non-IETF protocols. Out 762 of these, S/MIME and PGP are likely to better suit less immediate and 763 less ephemeral communications than typically the case for UDP 764 applications, because they generally require public-key operations 765 for each message. 767 Like congestion control mechanisms, security mechanisms are difficult 768 to design and implement correctly. It is hence RECOMMENDED that 769 applications employ well-known standard security mechanisms such as 770 DTLS or IPsec, rather than inventing their own. 772 In terms of congestion control, [RFC2309] and [RFC2914] discuss the 773 dangers of congestion-unresponsive flows to the Internet. This 774 document provides guidelines to designers of UDP-based applications 775 to congestion-control their transmissions, and does not raise any 776 additional security concerns. 778 5. Summary 780 This section summarizes the guidelines made in Section 3 and 781 Section 4 in a tabular format in Table 1 for easy referencing. 783 +---------------------------------------------------------+---------+ 784 | Recommendation | Section | 785 +---------------------------------------------------------+---------+ 786 | MUST accommodate wide range of Internet path conditions | 3 | 787 | SHOULD use a full-featured transport (TCP, SCTP, DCCP) | | 788 | | | 789 | SHOULD control rate of transmission | 3.1 | 790 | SHOULD perform congestion control over all traffic | | 791 | | | 792 | for bulk transfers, | 3.1.1 | 793 | SHOULD consider implementing TFRC | | 794 | else, SHOULD otherwise use bandwidth similar to TCP | | 795 | | | 796 | for non-bulk transfers, | 3.1.2 | 797 | SHOULD measure RTT and transmit 1 message/RTT | | 798 | else, SHOULD send at most 1 message every 3 seconds | | 799 | | | 800 | SHOULD NOT send messages that exceed the PMTU, i.e., | 3.2 | 801 | SHOULD discover PMTU or send messages < minimum PMTU | | 802 | | | 803 | SHOULD handle message loss, duplication, reordering | 3.3 | 804 | | | 805 | SHOULD enable UDP checksum | 3.4 | 806 | else, MAY use UDP-Lite with suitable checksum coverage | 3.4.1 | 807 | | | 808 | SHOULD NOT always send middlebox keep-alives | 3.5 | 809 | MAY use keep-alives when needed (min. interval 15 sec) | | 810 | | | 811 | MUST check IP source address | 3.6 | 812 | | | 813 | SHOULD use standard IETF security protocols when needed | 4 | 814 +---------------------------------------------------------+---------+ 816 Table 1: Summary of recommendations. 818 6. IANA Considerations 820 This document raises no IANA considerations. 822 7. Acknowledgments 824 Thanks to Paul Aitken, Mark Allman, Francois Audet, Stewart Bryant, 825 Remi Denis-Courmont, Wesley Eddy, Sally Floyd, Jeffrey Hutzelman, 826 Tero Kivinen, Philip Matthews, Joerg Ott, Colin Perkins, Carlos 827 Pignataro, Pasi Sarolahti, Joe Touch and Magnus Westerlund for their 828 comments on this document. 830 The middlebox traversal guidelines in Section 3.5 incorporate ideas 831 from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda Srisuresh 832 and Dan Kegel. 834 8. References 836 8.1. Normative References 838 [POSIX] IEEE Std. 1003.1-2001, "Standard for Information 839 Technology - Portable Operating System Interface (POSIX)", 840 Open Group Technical Standard: Base Specifications Issue 841 6, ISO/IEC 9945:2002, December 2001. 843 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 844 August 1980. 846 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 847 RFC 793, September 1981. 849 [RFC1122] Braden, R., "Requirements for Internet Hosts - 850 Communication Layers", STD 3, RFC 1122, October 1989. 852 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 853 November 1990. 855 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 856 for IP version 6", RFC 1981, August 1996. 858 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 859 Requirement Levels", BCP 14, RFC 2119, March 1997. 861 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 862 (IPv6) Specification", RFC 2460, December 1998. 864 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 865 RFC 2914, September 2000. 867 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 868 Timer", RFC 2988, November 2000. 870 [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP 871 Friendly Rate Control (TFRC): Protocol Specification", 872 RFC 3448, January 2003. 874 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 875 G. Fairhurst, "The Lightweight User Datagram Protocol 876 (UDP-Lite)", RFC 3828, July 2004. 878 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 879 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 880 RFC 4787, January 2007. 882 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 883 Discovery", RFC 4821, March 2007. 885 8.2. Informative References 887 [FABER] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT State in 888 TCP and Its Effect on Busy Servers", Proc. IEEE Infocom, 889 March 1999. 891 [I-D.ford-behave-app] 892 Ford, B., "Application Design Guidelines for Traversal 893 through Network Address Translators", 894 draft-ford-behave-app-05 (work in progress), March 2007. 896 [I-D.ietf-dccp-ccid4] 897 Floyd, S. and E. Kohler, "Profile for Datagram Congestion 898 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly 899 Rate Control for Small Packets (TFRC-SP)", 900 draft-ietf-dccp-ccid4-00 (work in progress), October 2007. 902 [I-D.ietf-dccp-rfc3448bis] 903 Handley, M., "TCP Friendly Rate Control (TFRC): Protocol 904 Specification", draft-ietf-dccp-rfc3448bis-02 (work in 905 progress), July 2007. 907 [I-D.ietf-mmusic-ice] 908 Rosenberg, J., "Interactive Connectivity Establishment 909 (ICE): A Protocol for Network Address Translator (NAT) 910 Traversal for Offer/Answer Protocols", 911 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 913 [I-D.ietf-nsis-nslp-natfw] 914 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 915 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in 916 progress), July 2007. 918 [I-D.ietf-nsis-ntlp] 919 Schulzrinne, H. and R. Hancock, "GIST: General Internet 920 Signalling Transport", draft-ietf-nsis-ntlp-14 (work in 921 progress), July 2007. 923 [I-D.wing-behave-nat-control-stun-usage] 924 Wing, D., Rosenberg, J., and H. Tschofenig, "Discovering, 925 Querying, and Controlling Firewalls and NATs", 926 draft-wing-behave-nat-control-stun-usage-05 (work in 927 progress), October 2007. 929 [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", 930 RFC 896, January 1984. 932 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 933 Miller, "Common DNS Implementation Errors and Suggested 934 Fixes", RFC 1536, October 1993. 936 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 937 RFC 1964, June 1996. 939 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 940 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 941 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 942 S., Wroclawski, J., and L. Zhang, "Recommendations on 943 Queue Management and Congestion Avoidance in the 944 Internet", RFC 2309, April 1998. 946 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 947 Floyd, S., and M. Luby, "Reliable Multicast Transport 948 Building Blocks for One-to-Many Bulk-Data Transfer", 949 RFC 3048, January 2001. 951 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 952 RFC 3124, June 2001. 954 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 955 A., Peterson, J., Sparks, R., Handley, M., and E. 956 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 957 June 2002. 959 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 960 A. Rayhan, "Middlebox communication architecture and 961 framework", RFC 3303, August 2002. 963 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 964 Stevens, "Basic Socket Interface Extensions for IPv6", 965 RFC 3493, February 2003. 967 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 968 Jacobson, "RTP: A Transport Protocol for Real-Time 969 Applications", STD 64, RFC 3550, July 2003. 971 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 972 Video Conferences with Minimal Control", STD 65, RFC 3551, 973 July 2003. 975 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 976 Control (WEBRC) Building Block", RFC 3738, April 2004. 978 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 979 Levkowetz, "Extensible Authentication Protocol (EAP)", 980 RFC 3748, June 2004. 982 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 983 Conrad, "Stream Control Transmission Protocol (SCTP) 984 Partial Reliability Extension", RFC 3758, May 2004. 986 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 987 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 988 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 989 RFC 3819, July 2004. 991 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 992 Extensions (S/MIME) Version 3.1 Message Specification", 993 RFC 3851, July 2004. 995 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 996 Internet Protocol", RFC 4301, December 2005. 998 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 999 December 2005. 1001 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1002 RFC 4303, December 2005. 1004 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1005 RFC 4306, December 2005. 1007 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1008 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1010 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 1011 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 1012 Congestion Control", RFC 4341, March 2006. 1014 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 1015 Datagram Congestion Control Protocol (DCCP) Congestion 1016 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 1017 March 2006. 1019 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1020 Security", RFC 4347, April 2006. 1022 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1023 Security Layer (SASL)", RFC 4422, June 2006. 1025 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 1026 Congestion Control (TFMCC): Protocol Specification", 1027 RFC 4654, August 2006. 1029 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1030 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1032 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1033 RFC 4960, September 2007. 1035 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1036 Errors at High Data Rates", RFC 4963, July 2007. 1038 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1039 Mitigations", RFC 4987, August 2007. 1041 [STEVENS] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network 1042 Programming, The sockets Networking API", Addison-Wesley, 1043 2004. 1045 [UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized 1046 Device Control Protocol V 1.0", November 2001. 1048 Authors' Addresses 1050 Lars Eggert 1051 Nokia Research Center 1052 P.O. Box 407 1053 Nokia Group 00045 1054 Finland 1056 Phone: +358 50 48 24461 1057 Email: lars.eggert@nokia.com 1058 URI: http://research.nokia.com/people/lars_eggert/ 1059 Godred Fairhurst 1060 University of Aberdeen 1061 Department of Engineering 1062 Fraser Noble Building 1063 Aberdeen AB24 3UE 1064 Scotland 1066 Email: gorry@erg.abdn.ac.uk 1067 URI: http://www.erg.abdn.ac.uk/ 1069 Full Copyright Statement 1071 Copyright (C) The IETF Trust (2007). 1073 This document is subject to the rights, licenses and restrictions 1074 contained in BCP 78, and except as set forth therein, the authors 1075 retain all their rights. 1077 This document and the information contained herein are provided on an 1078 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1079 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1080 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1081 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1082 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1083 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1085 Intellectual Property 1087 The IETF takes no position regarding the validity or scope of any 1088 Intellectual Property Rights or other rights that might be claimed to 1089 pertain to the implementation or use of the technology described in 1090 this document or the extent to which any license under such rights 1091 might or might not be available; nor does it represent that it has 1092 made any independent effort to identify any such rights. Information 1093 on the procedures with respect to rights in RFC documents can be 1094 found in BCP 78 and BCP 79. 1096 Copies of IPR disclosures made to the IETF Secretariat and any 1097 assurances of licenses to be made available, or the result of an 1098 attempt made to obtain a general license or permission for the use of 1099 such proprietary rights by implementers or users of this 1100 specification can be obtained from the IETF on-line IPR repository at 1101 http://www.ietf.org/ipr. 1103 The IETF invites any interested party to bring to its attention any 1104 copyrights, patents or patent applications, or other proprietary 1105 rights that may cover technology that may be required to implement 1106 this standard. Please address the information to the IETF at 1107 ietf-ipr@ietf.org. 1109 Acknowledgment 1111 Funding for the RFC Editor function is provided by the IETF 1112 Administrative Support Activity (IASA).