idnits 2.17.1 draft-ietf-tsvwg-rfc5405bis-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (October 14, 2016) is 2750 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-03 == Outdated reference: A later version (-02) exists of draft-ietf-rtgwg-dt-encap-01 -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 NetApp 4 Obsoletes: 5405 (if approved) G. Fairhurst 5 Intended status: Best Current Practice University of Aberdeen 6 Expires: April 17, 2017 G. Shepherd 7 Cisco Systems 8 October 14, 2016 10 UDP Usage Guidelines 11 draft-ietf-tsvwg-rfc5405bis-19 13 Abstract 15 The User Datagram Protocol (UDP) provides a minimal message-passing 16 transport that has no inherent congestion control mechanisms. This 17 document provides guidelines on the use of UDP for the designers of 18 applications, tunnels and other protocols that use UDP. Congestion 19 control guidelines are a primary focus, but the document also 20 provides guidance on other topics, including message sizes, 21 reliability, checksums, middlebox traversal, the use of ECN, DSCPs, 22 and ports. 24 Because congestion control is critical to the stable operation of the 25 Internet, applications and other protocols that choose to use UDP as 26 an Internet transport must employ mechanisms to prevent congestion 27 collapse and to establish some degree of fairness with concurrent 28 traffic. They may also need to implement additional mechanisms, 29 depending on how they use UDP. 31 Some guidance is also applicable to the design of other protocols 32 (e.g., protocols layered directly on IP or via IP-based tunnels), 33 especially when these protocols do not themselves provide congestion 34 control. 36 This document obsoletes RFC5405 and adds guidelines for multicast UDP 37 usage. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on April 17, 2017. 56 Copyright Notice 58 Copyright (c) 2016 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . 5 76 3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 6 77 3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 18 78 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . 20 79 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 21 80 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . 24 81 3.6. Limited Applicability and Controlled Environments . . . . 26 82 4. Multicast UDP Usage Guidelines . . . . . . . . . . . . . . . 27 83 4.1. Multicast Congestion Control Guidelines . . . . . . . . . 29 84 4.2. Message Size Guidelines for Multicast . . . . . . . . . . 31 85 5. Programming Guidelines . . . . . . . . . . . . . . . . . . . 31 86 5.1. Using UDP Ports . . . . . . . . . . . . . . . . . . . . . 33 87 5.2. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 36 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 89 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 91 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 41 94 10.2. Informative References . . . . . . . . . . . . . . . . . 43 95 Appendix A. Case Study of the Use of IPv6 UDP Zero-Checksum Mode 52 96 Appendix B. Revision Notes . . . . . . . . . . . . . . . . . . . 53 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 99 1. Introduction 101 The User Datagram Protocol (UDP) [RFC0768] provides a minimal, 102 unreliable, best-effort, message-passing transport to applications 103 and other protocols (such as tunnels) that desire to operate over IP. 104 Both are simply called "applications" in the remainder of this 105 document. 107 Compared to other transport protocols, UDP and its UDP-Lite variant 108 [RFC3828] are unique in that they do not establish end-to-end 109 connections between communicating end systems. UDP communication 110 consequently does not incur connection establishment and teardown 111 overheads, and there is minimal associated end system state. Because 112 of these characteristics, UDP can offer a very efficient 113 communication transport to some applications. 115 A second unique characteristic of UDP is that it provides no inherent 116 congestion control mechanisms. On many platforms, applications can 117 send UDP datagrams at the line rate of the platform's link interface, 118 which is often much greater than the available end-to-end path 119 capacity, and doing so contributes to congestion along the path. 120 [RFC2914] describes the best current practice for congestion control 121 in the Internet. It identifies two major reasons why congestion 122 control mechanisms are critical for the stable operation of the 123 Internet: 125 1. The prevention of congestion collapse, i.e., a state where an 126 increase in network load results in a decrease in useful work 127 done by the network. 129 2. The establishment of a degree of fairness, i.e., allowing 130 multiple flows to share the capacity of a path reasonably 131 equitably. 133 Because UDP itself provides no congestion control mechanisms, it is 134 up to the applications that use UDP for Internet communication to 135 employ suitable mechanisms to prevent congestion collapse and 136 establish a degree of fairness. [RFC2309] discusses the dangers of 137 congestion-unresponsive flows and states that "all UDP-based 138 streaming applications should incorporate effective congestion 139 avoidance mechanisms." [RFC7567] reaffirms this statement. This is 140 an important requirement, even for applications that do not use UDP 141 for streaming. In addition, congestion-controlled transmission is of 142 benefit to an application itself, because it can reduce self-induced 143 packet loss, minimize retransmissions, and hence reduce delays. 144 Congestion control is essential even at relatively slow transmission 145 rates. For example, an application that generates five 1500-byte UDP 146 datagrams in one second can already exceed the capacity of a 56 Kb/s 147 path. For applications that can operate at higher, potentially 148 unbounded data rates, congestion control becomes vital to prevent 149 congestion collapse and establish some degree of fairness. Section 3 150 describes a number of simple guidelines for the designers of such 151 applications. 153 A UDP datagram is carried in a single IP packet and is hence limited 154 to a maximum payload of 65,507 bytes for IPv4 and 65,527 bytes for 155 IPv6. The transmission of large IP packets usually requires IP 156 fragmentation. Fragmentation decreases communication reliability and 157 efficiency and should be avoided. IPv6 allows the option of 158 transmitting large packets ("jumbograms") without fragmentation when 159 all link layers along the path support this [RFC2675]. Some of the 160 guidelines in Section 3 describe how applications should determine 161 appropriate message sizes. Other sections of this document provide 162 guidance on reliability, checksums, middlebox traversal and use of 163 multicast. 165 This document provides guidelines and recommendations. Although most 166 UDP applications are expected to follow these guidelines, there do 167 exist valid reasons why a specific application may decide not to 168 follow a given guideline. In such cases, it is RECOMMENDED that 169 application designers cite the respective section(s) of this document 170 in the technical specification of their application or protocol and 171 explain their rationale for their design choice. 173 [RFC5405] was scoped to provide guidelines for unicast applications 174 only, whereas this document also provides guidelines for UDP flows 175 that use IP anycast, multicast, broadcast, and applications that use 176 UDP tunnels to support IP flows. 178 Finally, although this document specifically refers to usage of UDP, 179 the spirit of some of its guidelines also applies to other message- 180 passing applications and protocols (specifically on the topics of 181 congestion control, message sizes, and reliability). Examples 182 include signaling, tunnel, or control applications that choose to run 183 directly over IP by registering their own IP protocol number with 184 IANA. This document is expected to provide useful background reading 185 to the designers of such applications and protocols. 187 2. Terminology 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 191 "OPTIONAL" in this document are to be interpreted as described in 192 [RFC2119]. 194 3. UDP Usage Guidelines 196 Internet paths can have widely varying characteristics, including 197 transmission delays, available bandwidths, congestion levels, 198 reordering probabilities, supported message sizes, or loss rates. 199 Furthermore, the same Internet path can have very different 200 conditions over time. Consequently, applications that may be used on 201 the Internet MUST NOT make assumptions about specific path 202 characteristics. They MUST instead use mechanisms that let them 203 operate safely under very different path conditions. Typically, this 204 requires conservatively probing the current conditions of the 205 Internet path they communicate over to establish a transmission 206 behavior that it can sustain and that is reasonably fair to other 207 traffic sharing the path. 209 These mechanisms are difficult to implement correctly. For most 210 applications, the use of one of the existing IETF transport protocols 211 is the simplest method of acquiring the required mechanisms. Doing 212 so also avoids issues that protocols using a new IP protocol number 213 face when being deployed over the Internet, where middleboxes that 214 only support TCP and UDP are sometimes present. Consequently, the 215 RECOMMENDED alternative to the UDP usage described in the remainder 216 of this section is the use of an IETF transport protocol such as TCP 217 [RFC0793], Stream Control Transmission Protocol (SCTP) [RFC4960], and 218 SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram 219 Congestion Control Protocol (DCCP) [RFC4340] with its different 220 congestion control types [RFC4341][RFC4342][RFC5622], or transport 221 protocols specified by the IETF in the future. (UDP-encapsulated 222 SCTP [RFC6951] and DCCP [RFC6773] can offer support for traversing 223 firewalls and other middleboxes where the native protocols are not 224 supported.) 226 If used correctly, these more fully-featured transport protocols are 227 not as "heavyweight" as often claimed. For example, the TCP 228 algorithms have been continuously improved over decades, and have 229 reached a level of efficiency and correctness that custom 230 application-layer mechanisms will struggle to easily duplicate. In 231 addition, many TCP implementations allow connections to be tuned by 232 an application to its purposes. For example, TCP's "Nagle" algorithm 233 [RFC1122] can be disabled, improving communication latency at the 234 expense of more frequent -- but still congestion-controlled -- packet 235 transmissions. Another example is the TCP SYN cookie mechanism 236 [RFC4987], which is available on many platforms. TCP with SYN 237 cookies does not require a server to maintain per-connection state 238 until the connection is established. TCP also requires the end that 239 closes a connection to maintain the TIME-WAIT state that prevents 240 delayed segments from one connection instance from interfering with a 241 later one. Applications that are aware of and designed for this 242 behavior can shift maintenance of the TIME-WAIT state to conserve 243 resources by controlling which end closes a TCP connection [FABER]. 244 Finally, TCP's built-in capacity-probing and awareness of the maximum 245 transmission unit supported by the path (PMTU) results in efficient 246 data transmission that quickly compensates for the initial connection 247 setup delay, in the case of transfers that exchange more than a few 248 segments. 250 3.1. Congestion Control Guidelines 252 If an application or protocol chooses not to use a congestion- 253 controlled transport protocol, it SHOULD control the rate at which it 254 sends UDP datagrams to a destination host, in order to fulfill the 255 requirements of [RFC2914]. It is important to stress that an 256 application SHOULD perform congestion control over all UDP traffic it 257 sends to a destination, independently from how it generates this 258 traffic. For example, an application that forks multiple worker 259 processes or otherwise uses multiple sockets to generate UDP 260 datagrams SHOULD perform congestion control over the aggregate 261 traffic. 263 Several approaches to perform congestion control are discussed in the 264 remainder of this section. The section describes generic topics with 265 an intended emphasis on unicast and anycast [RFC1546] usage. Not all 266 approaches discussed below are appropriate for all UDP-transmitting 267 applications. Section 3.1.2 discusses congestion control options for 268 applications that perform bulk transfers over UDP. Such applications 269 can employ schemes that sample the path over several subsequent 270 round-trips during which data is exchanged to determine a sending 271 rate that the path at its current load can support. Other 272 applications only exchange a few UDP datagrams with a destination. 273 Section 3.1.3 discusses congestion control options for such "low 274 data-volume" applications. Because they typically do not transmit 275 enough data to iteratively sample the path to determine a safe 276 sending rate, they need to employ different kinds of congestion 277 control mechanisms. Section 3.1.11 discusses congestion control 278 considerations when UDP is used as a tunneling protocol. Section 4 279 provides additional recommendations for broadcast and multicast 280 usage. 282 It is important to note that congestion control should not be viewed 283 as an add-on to a finished application. Many of the mechanisms 284 discussed in the guidelines below require application support to 285 operate correctly. Application designers need to consider congestion 286 control throughout the design of their application, similar to how 287 they consider security aspects throughout the design process. 289 In the past, the IETF has also investigated integrated congestion 290 control mechanisms that act on the traffic aggregate between two 291 hosts, i.e., a framework such as the Congestion Manager [RFC3124], 292 where active sessions may share current congestion information in a 293 way that is independent of the transport protocol. Such mechanisms 294 have currently failed to see deployment, but would otherwise simplify 295 the design of congestion control mechanisms for UDP sessions, so that 296 they fulfill the requirements in [RFC2914]. 298 3.1.1. Protocol Timer Guidelines 300 Understanding the latency between communicating endpoints is usually 301 a crucial part of effective congestion control implementations for 302 protocols and applications. Latency estimation can be used in a 303 number of protocol functions, such as calculating a congestion- 304 controlled transmission rate, triggering retransmission, and 305 detecting packet loss. Additional protocol functions, for example, 306 determining an interval for probing a path, determining an interval 307 between keep-alive messages, determining an interval for measuring 308 the quality of experience, or determining if a remote endpoint has 309 responded to a request to perform an action typically operate over 310 longer timescales than congestion control and therefore are not 311 covered in this section. 313 The general recommendation in this document is that applications 314 SHOULD leverage existing congestion control techniques and the 315 latency estimators specified therein (see next subsection). The 316 following guidelines are provided for applications that need to 317 design their own latency estimation mechanisms. 319 The guidelines are framed in terms of "latency" and not "round-trip 320 time" because some situations require characterizing only the 321 network-based latency (e.g., TCP-Friendly Rate Control [RFC5348]), 322 while other cases necessitate inclusion of the time required by the 323 remote endpoint to provide feedback (e.g., developing an 324 understanding of when to retransmit a message). 326 The latency between endpoints is generally a dynamic property. 327 Therefore, estimates SHOULD represent some sort of averaging of 328 multiple recent measurement samples to account for variance. 329 Leveraging an Exponentially Weighted Moving Average (EWMA) has proven 330 useful for this purpose (e.g., in TCP [RFC6298] and TCP-Friendly Rate 331 Control (TFRC) [RFC5348]). 333 Independent latency estimates SHOULD be maintained for each 334 destination with which an endpoint communicates. 336 Latency samples MUST NOT be derived from ambiguous transactions. The 337 canonical example is in a protocol that retransmits data, but 338 subsequently cannot determine which copy is being acknowledged. This 339 ambiguity makes correct computation of the latency problematic. See 340 the discussion of Karn's algorithm in [RFC6298]. This requirement 341 ensures a sender establishes a sound estimate of the latency without 342 relying on mis-leading measurements. 344 When a latency estimate is used to arm a timer that provides loss 345 detection - with or without retransmission - expiry of the timer MUST 346 be interpreted as an indication of congestion in the network, causing 347 the sending rate to be adapted to a safe conservative rate (e.g., TCP 348 collapses the congestion window to one segment [RFC5681]). 350 Some applications require an initial latency estimate before the 351 latency between endpoints can be empirically sampled. For instance, 352 when arming a retransmission timer an initial value is needed to 353 protect the messages sent before the endpoints sample the latency. 354 This initial latency estimate SHOULD generally be as conservative 355 (large) as possible for the given application. For instance, in the 356 absence of any knowledge about the latency of a path, TCP requires 357 the initial Retransmission Timeout (RTO) to be set to no less than 1 358 second [RFC6298]. UDP applications SHOULD similarly use an initial 359 latency estimate of 1 second. Values shorter than 1 second can be 360 problematic (see the data analysis in the appendix of [RFC6298]). 362 3.1.2. Bulk Transfer Applications 364 Applications that perform bulk transmission of data to a peer over 365 UDP, i.e., applications that exchange more than a few UDP datagrams 366 per round-trip time (RTT), SHOULD implement TFRC [RFC5348], window- 367 based TCP-like congestion control, or otherwise ensure that the 368 application complies with the congestion control principles. 370 TFRC has been designed to provide both congestion control and 371 fairness in a way that is compatible with the IETF's other transport 372 protocols. If an application implements TFRC, it need not follow the 373 remaining guidelines in Section 3.1.2, because TFRC already addresses 374 them, but SHOULD still follow the remaining guidelines in the 375 subsequent subsections of Section 3. 377 Bulk transfer applications that choose not to implement TFRC or TCP- 378 like windowing SHOULD implement a congestion control scheme that 379 results in bandwidth (capacity) use that competes fairly with TCP 380 within an order of magnitude. 382 Section 2 of [RFC3551] suggests that applications SHOULD monitor the 383 packet loss rate to ensure that it is within acceptable parameters. 385 Packet loss is considered acceptable if a TCP flow across the same 386 network path under the same network conditions would achieve an 387 average throughput, measured on a reasonable timescale, that is not 388 less than that of the UDP flow. The comparison to TCP cannot be 389 specified exactly, but is intended as an "order-of-magnitude" 390 comparison in timescale and throughput. The recommendations for 391 managing timers specified in Section 3.1.1 also apply. 393 Finally, some bulk transfer applications may choose not to implement 394 any congestion control mechanism and instead rely on transmitting 395 across reserved path capacity (see Section 3.1.9). This might be an 396 acceptable choice for a subset of restricted networking environments, 397 but is by no means a safe practice for operation over the wider 398 Internet. When the UDP traffic of such applications leaks out into 399 unprovisioned Internet paths, it can significantly degrade the 400 performance of other traffic sharing the path and even result in 401 congestion collapse. Applications that support an uncontrolled or 402 unadaptive transmission behavior SHOULD NOT do so by default and 403 SHOULD instead require users to explicitly enable this mode of 404 operation, and they SHOULD verify that sufficient path capacity has 405 been reserved for them. 407 3.1.3. Low Data-Volume Applications 409 When applications that at any time exchange only a few UDP datagrams 410 with a destination implement TFRC or one of the other congestion 411 control schemes in Section 3.1.2, the network sees little benefit, 412 because those mechanisms perform congestion control in a way that is 413 only effective for longer transmissions. 415 Applications that at any time exchange only a few UDP datagrams with 416 a destination SHOULD still control their transmission behavior by not 417 sending on average more than one UDP datagram per RTT to a 418 destination. Similar to the recommendation in [RFC1536], an 419 application SHOULD maintain an estimate of the RTT for any 420 destination with which it communicates using the methods specified in 421 Section 3.1.1. 423 Some applications cannot maintain a reliable RTT estimate for a 424 destination. These applications do not need to or are unable to use 425 protocol timers to measure the RTT (Section 3.1.1). Two cases can be 426 identified: 428 1. The first case is that of applications that exchange too few UDP 429 datagrams with a peer to establish a statistically accurate RTT 430 estimate, but can monitor the reliability of transmission 431 (Section 3.3). Such applications MAY use a predetermined 432 transmission interval that is exponentially backed-off when 433 packets are found to be lost. TCP specifies an initial value of 434 1 second [RFC6298], which is also RECOMMENDED as an initial value 435 for UDP applications. Some low data-volume applications, e.g., 436 SIP [RFC3261] and GIST [RFC5971] use an interval of 500 ms, and 437 shorter values are likely problematic in many cases. As in the 438 previous case, note that the initial timeout is not the maximum 439 possible timeout, see Section 3.1.1. 441 2. A second case of applications cannot maintain an RTT estimate for 442 a destination, because the destination does not send return 443 traffic. Such applications SHOULD NOT send more than one UDP 444 datagram every 3 seconds, and SHOULD use an even less aggressive 445 rate when possible. Shorter values are likely problematic in 446 many cases. Note that the sending rate in this case must be more 447 conservative than in the previous cases, because the lack of 448 return traffic prevents the detection of packet loss, i.e., 449 congestion, and the application therefore cannot perform 450 exponential back-off to reduce load. 452 3.1.4. Applications supporting bidirectional communications 454 Applications that communicate bidirectionally SHOULD employ 455 congestion control for both directions of the communication. For 456 example, for a client-server, request-response-style application, 457 clients SHOULD congestion-control their request transmission to a 458 server, and the server SHOULD congestion-control its responses to the 459 clients. Congestion in the forward and reverse direction is 460 uncorrelated, and an application SHOULD either independently detect 461 and respond to congestion along both directions, or limit new and 462 retransmitted requests based on acknowledged responses across the 463 entire round-trip path. 465 3.1.5. Implications of RTT and Loss Measurements on Congestion Control 467 Transports such as TCP, SCTP and DCCP provide timely detection of 468 congestion that results in an immediate reduction of their maximum 469 sending rate when congestion is experienced. This reaction is 470 typically completed 1-2 RTTs after loss/congestion is encountered. 471 Applications using UDP SHOULD implement a congestion control scheme 472 that provides a prompt reaction to signals indicating congestion 473 (e.g., by reducing the rate within the next RTT following a 474 congestion signal). 476 The operation of a UDP congestion control algorithm can be very 477 different to the way TCP operates. This includes congestion controls 478 that respond on timescales that fit applications that cannot usefully 479 work within the "change rate every RTT" model of TCP. Applications 480 that experience a low or varying RTT are particularly vulnerable to 481 sampling errors (e.g., due to measurement noise, or timer accuracy). 482 This suggests the need to average loss/congestion and RTT 483 measurements over a longer interval, however this also can contribute 484 additional delay in detecting congestion. Some applications may not 485 react by reducing their sending rate immediately for various reasons, 486 including: RTT and loss measurements are only made periodically 487 (e.g., using RTCP), additional time is required to filter 488 information, or the application is only able to change its sending 489 rate at predetermined interval (e.g., some video codecs). 491 When designing a congestion control algorithm, the designer therefore 492 needs to consider the total time taken to reduce the load following a 493 lack of feedback or a congestion event. An application where the 494 most recent RTT measurement is smaller than the actual RTT or the 495 measured loss rate is smaller than the current rate, can result in 496 over estimating the available capacity. Such over estimation can 497 result in a sending rate that creates congestion to the application 498 or other flows sharing the path capacity, and can contribute to 499 congestion collapse - both of these need to be avoided. 501 A congestion control designed for UDP SHOULD respond as quickly as 502 possible when it experiences congestion, and SHOULD take into account 503 both the loss rate and the response time when choosing a new rate. 504 The implemented congestion control scheme SHOULD result in bandwidth 505 (capacity) use that is comparable to that of TCP within an order of 506 magnitude, so that it does not starve other flows sharing a common 507 bottleneck. 509 3.1.6. Burst Mitigation and Pacing 511 UDP applications SHOULD provide mechanisms to regulate the bursts of 512 transmission that the application may send to the network. Many TCP 513 and SCTP implementations provide mechanisms that prevent a sender 514 from generating long bursts at line-rate, since these are known to 515 induce early loss to applications sharing a common network 516 bottleneck. The use of pacing with TCP [ALLMAN] has also been shown 517 to improve the coexistence of TCP flows with other flows. The need 518 to avoid excessive transmission bursts is also noted in 519 specifications for applications (e.g., [RFC7143]). 521 Even low data-volume UDP flows may benefit from packet pacing, e.g., 522 an application that sends three copies of a packet to improve 523 robustness to loss is RECOMMENDED to pace out those three packets 524 over several RTTs, to reduce the probability that all three packets 525 will be lost due to the same congestion event (or other event, such 526 as burst corruption). 528 3.1.7. Explicit Congestion Notification 530 Internet applications can use Explicit Congestion Notification (ECN) 531 [RFC3168] to gain benefits for the services they support 532 [I-D.ietf-aqm-ecn-benefits]. 534 Internet transports, such as TCP, provide a set of mechanisms that 535 are needed to utilize ECN. ECN operates by setting an ECN-capable 536 codepoint (ECT(0) or ECT(1)) in the IP header of packets that are 537 sent. This indicates to ECN-capable network devices (routers, and 538 other devices) that they may mark (set the congestion experienced, CE 539 codepoint), rather than drop the IP packet as a signal of incipient 540 congestion. 542 UDP applications can also benefit from enabling ECN, providing that 543 the API supports ECN and that they implement the required protocol 544 mechanisms to support ECN. 546 The set of mechanisms required for an application to use ECN over UDP 547 are: 549 o A sender MUST provide a method to determine (e.g., negotiate) that 550 the corresponding application is able to provide ECN feedback 551 using a compatible ECN method. 553 o A receiver that enables the use of ECN for a UDP port MUST check 554 the ECN field at the receiver for each UDP datagram that it 555 receives on this port. 557 o The receiving application needs to provide feedback of congestion 558 information to the sending application. This MUST report the 559 presence of datagrams received with a CE-mark by providing a 560 mechanism to feed this congestion information back to the sending 561 application. The feedback MAY also report the presence of ECT(1) 562 and ECT(0)/Not-ECT packets [RFC7560]. ([RFC3168] and [RFC7560] 563 specify methods for TCP.) 565 o An application sending ECN-capable datagrams MUST provide an 566 appropriate congestion reaction when it receives feedback 567 indicating that congestion has been experienced. This ought to 568 result in reduction of the sending rate by the UDP congestion 569 control method (see Section 3.1) that is not less than the 570 reaction of TCP under equivalent conditions. 572 o A sender SHOULD detect network paths that do not support the ECN 573 field correctly. When detected they need to either conservatively 574 react to congestion or even fall back to not using ECN 575 [I-D.ietf-aqm-ecn-benefits]. This method needs to be robust to 576 changes within the network path that may occur over the lifetime 577 of a session. 579 o A sender is encouraged to provide a mechanism to detect and react 580 appropriately to misbehaving receivers that fail to report CE- 581 marked packets [I-D.ietf-aqm-ecn-benefits]. 583 [RFC6679] provides guidance and an example of this support, by 584 describing a method to allow ECN to be used for UDP-based 585 applications using the Real-Time Protocol (RTP). Applications that 586 cannot provide this set of mechanisms, but wish to gain the benefits 587 of using ECN, are encouraged to use a transport protocol that already 588 supports ECN (such as TCP). 590 3.1.8. Differentiated Services Model 592 An application using UDP can use the differentiated services 593 (DiffServ) Quality of Service (QoS) framework. To enable 594 differentiated services processing, a UDP sender sets the 595 Differentiated Services Code Point (DSCP) field [RFC2475] in packets 596 sent to the network. Normally, a UDP source/destination port pair 597 will set a single DSCP value for all packets belonging to a flow, but 598 multiple DSCPs can be used as described later in this section. A 599 DSCP may be chosen from a small set of fixed values (the class 600 selector code points), or from a set of recommended values defined in 601 the Per Hop Behavior (PHB) specifications, or from values that have 602 purely local meanings to a specific network that supports DiffServ. 603 In general, packets may be forwarded across multiple networks between 604 source and destination. 606 In setting a non-default DSCP value, an application must be aware 607 that DSCP markings may be changed or removed between the traffic 608 source and destination. This has implications on the design of 609 applications that use DSCPs. Specifically, applications SHOULD be 610 designed to not rely on implementation of a specific network 611 treatment, they need instead to implement congestion control methods 612 to determine if their current sending rate is inducing congestion in 613 the network. 615 [RFC7657] describes the implications of using DSCPs and provides 616 recommendations on using multiple DSCPs within a single network five- 617 tuple (source and destination addresses, source and destination 618 ports, and the transport protocol used, in this case, UDP or UDP- 619 Lite), and particularly the expected impact on transport protocol 620 interactions, with congestion control or reliability functionality 621 (e.g., retransmission, reordering). Use of multiple DSCPs can result 622 in reordering by increasing the set of network forwarding resources 623 used by a sender. It can also increase exposure to resource 624 depletion or failure. 626 3.1.9. QoS, Pre-Provisioned or Reserved Capacity 628 The IETF usually specifies protocols for use within the Best Effort 629 General Internet. Sometimes it is relevant to specify protocols with 630 a different applicability. An application using UDP can use the 631 integrated services QoS framework. This framework is usually made 632 available within controlled environments (e.g., within a single 633 administrative domain or bilaterally agreed connection between 634 domains). Applications intended for the Internet SHOULD NOT assume 635 that QoS mechanisms are supported by the networks they use, and 636 therefore need to provide congestion control, error recovery, etc. in 637 case the actual network path does not provide provisioned service. 639 Some UDP applications are only expected to be deployed over network 640 paths that use pre-provisioned capacity or capacity reserved using 641 dynamic provisioning, e.g., through the Resource Reservation Protocol 642 (RSVP). Multicast applications are also used with pre-provisioned 643 capacity (e.g., IPTV deployments within access networks). These 644 applications MAY choose not to implement any congestion control 645 mechanism and instead rely on transmitting only on paths where the 646 capacity is provisioned and reserved for this use. This might be an 647 acceptable choice for a subset of restricted networking environments, 648 but is by no means a safe practice for operation over the wider 649 Internet. Applications that choose this option SHOULD carefully and 650 in detail describe the provisioning and management procedures that 651 result in the desired containment. 653 Applications that support an uncontrolled or unadaptive transmission 654 behavior SHOULD NOT do so by default and SHOULD instead require users 655 to explicitly enable this mode of operation. 657 Applications designed for use within a controlled environment (see 658 Section 3.6) may be able to exploit network management functions to 659 detect whether they are causing congestion, and react accordingly. 660 If the traffic of such applications leaks out into unprovisioned 661 Internet paths, it can significantly degrade the performance of other 662 traffic sharing the path and even result in congestion collapse. 663 Protocols designed for such networks SHOULD provide mechanisms at the 664 network edge to prevent leakage of traffic into unprovisioned 665 Internet paths (e.g., [RFC7510]). To protect other applications 666 sharing the same path, applications SHOULD also deploy an appropriate 667 circuit breaker, as described in Section 3.1.10. 669 An IETF specification targeting a controlled environment is expected 670 to provide an applicability statement that restricts the application 671 to the controlled environment (see Section 3.6). 673 3.1.10. Circuit Breaker Mechanisms 675 A transport circuit breaker is an automatic mechanism that is used to 676 estimate the congestion caused by a flow, and to terminate (or 677 significantly reduce the rate of) the flow when excessive congestion 678 is detected [I-D.ietf-tsvwg-circuit-breaker]. This is a safety 679 measure to prevent congestion collapse (starvation of resources 680 available to other flows), essential for an Internet that is 681 heterogeneous and for traffic that is hard to predict in advance. 683 A circuit breaker is intended as a protection mechanism of last 684 resort. Under normal circumstances, a circuit breaker should not be 685 triggered; it is designed to protect things when there is severe 686 overload. The goal is usually to limit the maximum transmission rate 687 that reflects the available capacity of a network path. Circuit 688 breakers can operate on individual UDP flows or traffic aggregates, 689 e.g., traffic sent using a network tunnel. 691 [I-D.ietf-tsvwg-circuit-breaker] provides guidance and examples on 692 the use of circuit breakers. The use of a circuit breaker in RTP is 693 specified in [I-D.ietf-avtcore-rtp-circuit-breakers]. 695 Applications used in the general Internet SHOULD implement a 696 transport circuit breaker if they do not implement congestion control 697 or operate a low volume data service (see Section 3.6). All 698 applications MAY implement a transport circuit breaker 699 [I-D.ietf-tsvwg-circuit-breaker] and are encouraged to consider 700 implementing at least a slow-acting transport circuit breaker to 701 provide a protection of last resort for their network traffic. 703 3.1.11. UDP Tunnels 705 One increasingly popular use of UDP is as a tunneling protocol 706 [I-D.ietf-intarea-tunnels], where a tunnel endpoint encapsulates the 707 packets of another protocol inside UDP datagrams and transmits them 708 to another tunnel endpoint, which decapsulates the UDP datagrams and 709 forwards the original packets contained in the payload. One example 710 of such a protocol is Teredo [RFC4380]. Tunnels establish virtual 711 links that appear to directly connect locations that are distant in 712 the physical Internet topology and can be used to create virtual 713 (private) networks. Using UDP as a tunneling protocol is attractive 714 when the payload protocol is not supported by middleboxes that may 715 exist along the path, because many middleboxes support transmission 716 using UDP. 718 Well-implemented tunnels are generally invisible to the endpoints 719 that happen to transmit over a path that includes tunneled links. On 720 the other hand, to the routers along the path of a UDP tunnel, i.e., 721 the routers between the two tunnel endpoints, the traffic that a UDP 722 tunnel generates is a regular UDP flow, and the encapsulator and 723 decapsulator appear as regular UDP-sending and -receiving 724 applications. Because other flows can share the path with one or 725 more UDP tunnels, congestion control needs to be considered. 727 Two factors determine whether a UDP tunnel needs to employ specific 728 congestion control mechanisms -- first, whether the payload traffic 729 is IP-based; second, whether the tunneling scheme generates UDP 730 traffic at a volume that corresponds to the volume of payload traffic 731 carried within the tunnel. 733 IP-based unicast traffic is generally assumed to be congestion- 734 controlled, i.e., it is assumed that the transport protocols 735 generating IP-based unicast traffic at the sender already employ 736 mechanisms that are sufficient to address congestion on the path. 737 Consequently, a tunnel carrying IP-based unicast traffic should 738 already interact appropriately with other traffic sharing the path, 739 and specific congestion control mechanisms for the tunnel are not 740 necessary. 742 However, if the IP traffic in the tunnel is known to not be 743 congestion-controlled, additional measures are RECOMMENDED to limit 744 the impact of the tunneled traffic on other traffic sharing the path. 745 For the specific case of a tunnel that carries IP multicast traffic, 746 see Section 4.1. 748 The following guidelines define these possible cases in more detail: 750 1. A tunnel generates UDP traffic at a volume that corresponds to 751 the volume of payload traffic, and the payload traffic is IP- 752 based and congestion-controlled. 754 This is arguably the most common case for Internet tunnels. In 755 this case, the UDP tunnel SHOULD NOT employ its own congestion 756 control mechanism, because congestion losses of tunneled traffic 757 will already trigger an appropriate congestion response at the 758 original senders of the tunneled traffic. A circuit breaker 759 mechanism may provide benefit by controlling the envelope of the 760 aggregated traffic. 762 Note that this guideline is built on the assumption that most IP- 763 based communication is congestion-controlled. If a UDP tunnel is 764 used for IP-based traffic that is known to not be congestion- 765 controlled, the next set of guidelines applies. 767 2. A tunnel generates UDP traffic at a volume that corresponds to 768 the volume of payload traffic, and the payload traffic is not 769 known to be IP-based, or is known to be IP-based but not 770 congestion-controlled. 772 This can be the case, for example, when some link-layer protocols 773 are encapsulated within UDP (but not all link-layer protocols; 774 some are congestion-controlled). Because it is not known that 775 congestion losses of tunneled non-IP traffic will trigger an 776 appropriate congestion response at the senders, the UDP tunnel 777 SHOULD employ an appropriate congestion control mechanism or 778 circuit breaker mechanism designed for the traffic it carries. 779 Because tunnels are usually bulk-transfer applications as far as 780 the intermediate routers are concerned, the guidelines in 781 Section 3.1.2 apply. 783 3. A tunnel generates UDP traffic at a volume that does not 784 correspond to the volume of payload traffic, independent of 785 whether the payload traffic is IP-based or congestion-controlled. 787 Examples of this class include UDP tunnels that send at a 788 constant rate, increase their transmission rates under loss, for 789 example, due to increasing redundancy when Forward Error 790 Correction is used, or are otherwise unconstrained in their 791 transmission behavior. These specialized uses of UDP for 792 tunneling go beyond the scope of the general guidelines given in 793 this document. The implementer of such specialized tunnels 794 SHOULD carefully consider congestion control in the design of 795 their tunneling mechanism and SHOULD consider use of a circuit 796 breaker mechanism. 798 The type of encapsulated payload might be identified by a UDP port; 799 identified by an Ethernet Type or IP protocol number. A tunnel 800 SHOULD provide mechanisms to restrict the types of flows that may be 801 carried by the tunnel. For instance, a UDP tunnel designed to carry 802 IP needs to filter out non-IP traffic at the ingress. This is 803 particularly important when a generic tunnel encapsulation is used 804 (e.g., one that encapsulates using an EtherType value). Such tunnels 805 SHOULD provide a mechanism to restrict the types of traffic that are 806 allowed to be encapsulated for a given deployment (see 807 [I-D.ietf-intarea-tunnels]). 809 Designing a tunneling mechanism requires significantly more expertise 810 than needed for many other UDP applications, because tunnels are 811 usually intended to be transparent to the endpoints transmitting over 812 them, so they need to correctly emulate the behavior of an IP link 813 [I-D.ietf-intarea-tunnels], e.g.: 815 o Requirements for tunnels that carry or encapsulate using ECN code 816 points [RFC6040]. 818 o Usage of the IP DSCP field by tunnel endpoints [RFC2983]. 820 o Encapsulation considerations in the design of tunnels 821 [I-D.ietf-rtgwg-dt-encap]. 823 o Usage of ICMP messages [I-D.ietf-intarea-tunnels]. 825 o Handling of fragmentation and packet size for tunnels 826 [I-D.ietf-intarea-tunnels]. 828 o Source port usage for tunnels designed to support equal cost 829 multipath (ECMP) routing (see Section 5.1.1). 831 o Guidance on the need to protect headers [I-D.ietf-intarea-tunnels] 832 and the use of checksums for IPv6 tunnels (see Section 3.4.1). 834 o Support for operations and maintenance [I-D.ietf-intarea-tunnels]. 836 At the same time, the tunneled traffic is application traffic like 837 any other from the perspective of the networks the tunnel transmits 838 over. This document only touches upon the congestion control 839 considerations for implementing UDP tunnels; a discussion of other 840 required tunneling behavior is out of scope. 842 3.2. Message Size Guidelines 844 IP fragmentation lowers the efficiency and reliability of Internet 845 communication. The loss of a single fragment results in the loss of 846 an entire fragmented packet, because even if all other fragments are 847 received correctly, the original packet cannot be reassembled and 848 delivered. This fundamental issue with fragmentation exists for both 849 IPv4 and IPv6. 851 In addition, some network address translators (NATs) and firewalls 852 drop IP fragments. The network address translation performed by a 853 NAT only operates on complete IP packets, and some firewall policies 854 also require inspection of complete IP packets. Even with these 855 being the case, some NATs and firewalls simply do not implement the 856 necessary reassembly functionality, and instead choose to drop all 857 fragments. Finally, [RFC4963] documents other issues specific to 858 IPv4 fragmentation. 860 Due to these issues, an application SHOULD NOT send UDP datagrams 861 that result in IP packets that exceed the Maximum Transmission Unit 862 (MTU) along the path to the destination. Consequently, an 863 application SHOULD either use the path MTU information provided by 864 the IP layer or implement Path MTU Discovery (PMTUD) itself 865 [RFC1191][RFC1981][RFC4821] to determine whether the path to a 866 destination will support its desired message size without 867 fragmentation. However, the ICMP messages that enable path MTU 868 discovery are being increasingly filtered by middleboxes (including 869 Firewalls) [RFC4890]. When the path includes a tunnel, some devices 870 acting as a tunnel ingress discard ICMP messages that originate from 871 network devices over which the tunnel passes, preventing these 872 reaching the UDP endpoint. 874 Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not 875 rely upon network support for ICMP messages and is therefore 876 considered more robust than standard PMTUD. It is not susceptible to 877 "black holing" of ICMP message. To operate, PLPMTUD requires changes 878 to the way the transport is used, both to transmit probe packets, and 879 to account for the loss or success of these probes. This updates not 880 only the PMTU algorithm, it also impacts loss recovery, congestion 881 control, etc. These updated mechanisms can be implemented within a 882 connection-oriented transport (e.g., TCP, SCTP, DCCP), but are not a 883 part of UDP, but this type of feedback is not typically present for 884 unidirectional applications. 886 PLPMTUD therefore places additional design requirements on a UDP 887 application that wishes to use this method. This is especially true 888 for UDP tunnels, because the overhead of sending probe packets needs 889 to be accounted for and may require adding a congestion control 890 mechanism to the tunnel (see Section 3.1.11) as well as complicating 891 the data path at a tunnel decapsulator. 893 Applications that do not follow this recommendation to do PMTU/ 894 PLPMTUD discovery SHOULD still avoid sending UDP datagrams that would 895 result in IP packets that exceed the path MTU. Because the actual 896 path MTU is unknown, such applications SHOULD fall back to sending 897 messages that are shorter than the default effective MTU for sending 898 (EMTU_S in [RFC1122]). For IPv4, EMTU_S is the smaller of 576 bytes 899 and the first-hop MTU [RFC1122]. For IPv6, EMTU_S is 1280 bytes 900 [RFC2460]. The effective PMTU for a directly connected destination 901 (with no routers on the path) is the configured interface MTU, which 902 could be less than the maximum link payload size. Transmission of 903 minimum-sized UDP datagrams is inefficient over paths that support a 904 larger PMTU, which is a second reason to implement PMTU discovery. 906 To determine an appropriate UDP payload size, applications MUST 907 subtract the size of the IP header (which includes any IPv4 optional 908 headers or IPv6 extension headers) as well as the length of the UDP 909 header (8 bytes) from the PMTU size. This size, known as the Maximum 910 Segment Size (MSS), can be obtained from the TCP/IP stack [RFC1122]. 912 Applications that do not send messages that exceed the effective PMTU 913 of IPv4 or IPv6 need not implement any of the above mechanisms. Note 914 that the presence of tunnels can cause an additional reduction of the 915 effective PMTU [I-D.ietf-intarea-tunnels], so implementing PMTU 916 discovery may be beneficial. 918 Applications that fragment an application-layer message into multiple 919 UDP datagrams SHOULD perform this fragmentation so that each datagram 920 can be received independently, and be independently retransmitted in 921 the case where an application implements its own reliability 922 mechanisms. 924 3.3. Reliability Guidelines 926 Application designers are generally aware that UDP does not provide 927 any reliability, e.g., it does not retransmit any lost packets. 928 Often, this is a main reason to consider UDP as a transport protocol. 929 Applications that do require reliable message delivery MUST implement 930 an appropriate mechanism themselves. 932 UDP also does not protect against datagram duplication, i.e., an 933 application may receive multiple copies of the same UDP datagram, 934 with some duplicates arriving potentially much later than the first. 935 Application designers SHOULD handle such datagram duplication 936 gracefully, and may consequently need to implement mechanisms to 937 detect duplicates. Even if UDP datagram reception triggers only 938 idempotent operations, applications may want to suppress duplicate 939 datagrams to reduce load. 941 Applications that require ordered delivery MUST reestablish datagram 942 ordering themselves. The Internet can significantly delay some 943 packets with respect to others, e.g., due to routing transients, 944 intermittent connectivity, or mobility. This can cause reordering, 945 where UDP datagrams arrive at the receiver in an order different from 946 the transmission order. 948 Applications that use multiple transport ports need to be robust to 949 reordering between sessions. Load-balancing techniques within the 950 network, such as Equal Cost Multipath (ECMP) forwarding can also 951 result in a lack of ordering between different transport sessions, 952 even between the same two network endpoints. 954 It is important to note that the time by which packets are reordered 955 or after which duplicates can still arrive can be very large. Even 956 more importantly, there is no well-defined upper boundary here. 957 [RFC0793] defines the maximum delay a TCP segment should experience 958 -- the Maximum Segment Lifetime (MSL) -- as 2 minutes. No other RFC 959 defines an MSL for other transport protocols or IP itself. The MSL 960 value defined for TCP is conservative enough that it SHOULD be used 961 by other protocols, including UDP. Therefore, applications SHOULD be 962 robust to the reception of delayed or duplicate packets that are 963 received within this 2-minute interval. 965 Retransmission of lost packets or messages is a common reliability 966 mechanism. Such retransmissions can increase network load in 967 response to congestion, worsening that congestion. Any application 968 that uses retransmission is responsible for congestion control of its 969 retransmissions (as well as the application's original traffic), and 970 hence is subject to the Congestion Control guidelines in Section 3.1. 971 Guidance on the appropriate measurement of RTT in Section 3.1.1 also 972 applies for timers used for retransmission packet loss detection. 974 Instead of implementing these relatively complex reliability 975 mechanisms by itself, an application that requires reliable and 976 ordered message delivery SHOULD whenever possible choose an IETF 977 standard transport protocol that provides these features. 979 3.4. Checksum Guidelines 981 The UDP header includes an optional, 16-bit one's complement checksum 982 that provides an integrity check. These checks are not strong from a 983 coding or cryptographic perspective, and are not designed to detect 984 physical-layer errors or malicious modification of the datagram 985 [RFC3819]. Application developers SHOULD implement additional checks 986 where data integrity is important, e.g., through a Cyclic Redundancy 987 Check (CRC) or keyed or non-keyed cryptographic hash included with 988 the data to verify the integrity of an entire object/file sent over 989 the UDP service. 991 The UDP checksum provides a statistical guarantee that the payload 992 was not corrupted in transit. It also allows the receiver to verify 993 that it was the intended destination of the packet, because it covers 994 the IP addresses, port numbers, and protocol number, and it verifies 995 that the packet is not truncated or padded, because it covers the 996 size field. It therefore protects an application against receiving 997 corrupted payload data in place of, or in addition to, the data that 998 was sent. More description of the set of checks performed using the 999 checksum field is provided in Section 3.1 of [RFC6396]. 1001 Applications SHOULD enable UDP checksums [RFC1122]. For IPv4, 1002 [RFC0768] permits an option to disable their use, by setting a zero 1003 checksum value. An application is permitted to optionally discard 1004 UDP datagrams with a zero checksum [RFC1122]. 1006 When UDP is used over IPv6, the UDP checksum is relied upon to 1007 protect both the IPv6 and UDP headers from corruption (because IPv6 1008 lacks a checksum) and MUST be used as specified in [RFC2460]. Under 1009 specific conditions a UDP application is allowed to use a zero UDP 1010 zero-checksum mode with a tunnel protocol (see Section 3.4.1). 1012 Applications that choose to disable UDP checksums MUST NOT make 1013 assumptions regarding the correctness of received data and MUST 1014 behave correctly when a UDP datagram is received that was originally 1015 sent to a different destination or is otherwise corrupted. 1017 3.4.1. IPv6 Zero UDP Checksum 1019 [RFC6935] defines a method that enables use of a zero UDP zero- 1020 checksum mode with a tunnel protocol, providing that the method 1021 satisfies the requirements in [RFC6936]. The application MUST 1022 implement mechanisms and/or usage restrictions when enabling this 1023 mode. This includes defining the scope for usage and measures to 1024 prevent leakage of traffic to other UDP applications (see Appendix A 1025 Section 3.6). These additional design requirements for using a zero 1026 IPv6 UDP checksum are not present for IPv4, since the IPv4 header 1027 validates information that is not protected in an IPv6 packet. Key 1028 requirements are: 1030 o Use of the UDP checksum with IPv6 MUST be the default 1031 configuration for all implementations [RFC6935]. The receiving 1032 endpoint MUST only allow the use of UDP zero-checksum mode for 1033 IPv6 on a UDP destination port that is specifically enabled. 1035 o An application that support a checksum different to that in 1036 [RFC2460] MUST comply with all implementation requirements 1037 specified in Section 4 of [RFC6936] and with the usage 1038 requirements specified in Section 5 of [RFC6936]. 1040 o A UDP application MUST check that the source and destination IPv6 1041 addresses are valid for any packets with a UDP zero-checksum and 1042 MUST discard any packet for which this check fails. To protect 1043 from misdelivery, new encapsulation designs SHOULD include an 1044 integrity check at the transport layer that includes at least the 1045 IPv6 header, the UDP header and the shim header for the 1046 encapsulation, if any [RFC6936]. 1048 o One way to help satisfy the requirements of [RFC6936] may be to 1049 limit the usage of such tunnels, e.g., to constrain traffic to an 1050 operator network, as discussed in Section 3.6. The encapsulation 1051 defined for MPLS in UDP [RFC7510] chooses this approach. 1053 As in IPv4, IPv6 applications that choose to disable UDP checksums 1054 MUST NOT make assumptions regarding the correctness of received data 1055 and MUST behave correctly when a UDP datagram is received that was 1056 originally sent to a different destination or is otherwise corrupted. 1058 IPv6 datagrams with a zero UDP checksum will not be passed by any 1059 middlebox that validates the checksum based on [RFC2460] or that 1060 updates the UDP checksum field, such as NATs or firewalls. Changing 1061 this behavior would require such middleboxes to be updated to 1062 correctly handle datagrams with zero UDP checksums To ensure end-to- 1063 end robustness, applications that may be deployed in the general 1064 Internet MUST provide a mechanism to safely fall back to using a 1065 checksum when a path change occurs that redirects a zero UDP checksum 1066 flow over a path that includes a middlebox that discards IPv6 1067 datagrams with a zero UDP checksum. 1069 3.4.2. UDP-Lite 1071 A special class of applications can derive benefit from having 1072 partially-damaged payloads delivered, rather than discarded, when 1073 using paths that include error-prone links. Such applications can 1074 tolerate payload corruption and MAY choose to use the Lightweight 1075 User Datagram Protocol (UDP-Lite) [RFC3828] variant of UDP instead of 1076 basic UDP. Applications that choose to use UDP-Lite instead of UDP 1077 should still follow the congestion control and other guidelines 1078 described for use with UDP in Section 3. 1080 UDP-Lite changes the semantics of the UDP "payload length" field to 1081 that of a "checksum coverage length" field. Otherwise, UDP-Lite is 1082 semantically identical to UDP. The interface of UDP-Lite differs 1083 from that of UDP by the addition of a single (socket) option that 1084 communicates the checksum coverage length: at the sender, this 1085 specifies the intended checksum coverage, with the remaining 1086 unprotected part of the payload called the "error-insensitive part." 1087 By default, the UDP-Lite checksum coverage extends across the entire 1088 datagram. If required, an application may dynamically modify this 1089 length value, e.g., to offer greater protection to some messages. 1090 UDP-Lite always verifies that a packet was delivered to the intended 1091 destination, i.e., always verifies the header fields. Errors in the 1092 insensitive part will not cause a UDP datagram to be discarded by the 1093 destination. Applications using UDP-Lite therefore MUST NOT make 1094 assumptions regarding the correctness of the data received in the 1095 insensitive part of the UDP-Lite payload. 1097 A UDP-Lite sender SHOULD select the minimum checksum coverage to 1098 include all sensitive payload information. For example, applications 1099 that use the Real-Time Protocol (RTP) [RFC3550] will likely want to 1100 protect the RTP header against corruption. Applications, where 1101 appropriate, MUST also introduce their own appropriate validity 1102 checks for protocol information carried in the insensitive part of 1103 the UDP-Lite payload (e.g., internal CRCs). 1105 A UDP-Lite receiver MUST set a minimum coverage threshold for 1106 incoming packets that is not smaller than the smallest coverage used 1107 by the sender [RFC3828]. The receiver SHOULD select a threshold that 1108 is sufficiently large to block packets with an inappropriately short 1109 coverage field. This may be a fixed value, or may be negotiated by 1110 an application. UDP-Lite does not provide mechanisms to negotiate 1111 the checksum coverage between the sender and receiver. This 1112 therefore needs to be performed by the application. 1114 Applications can still experience packet loss when using UDP-Lite. 1115 The enhancements offered by UDP-Lite rely upon a link being able to 1116 intercept the UDP-Lite header to correctly identify the partial 1117 coverage required. When tunnels and/or encryption are used, this can 1118 result in UDP-Lite datagrams being treated the same as UDP datagrams, 1119 i.e., result in packet loss. Use of IP fragmentation can also 1120 prevent special treatment for UDP-Lite datagrams, and this is another 1121 reason why applications SHOULD avoid IP fragmentation (Section 3.2). 1123 UDP-Lite is supported in some endpoint protocol stacks. Current 1124 support for middlebox traversal using UDP-Lite is poor, because UDP- 1125 Lite uses a different IPv4 protocol number or IPv6 "next header" 1126 value than that used for UDP; therefore, few middleboxes are 1127 currently able to interpret UDP-Lite and take appropriate actions 1128 when forwarding the packet. This makes UDP-Lite less suited for 1129 applications needing general Internet support, until such time as 1130 UDP-Lite has achieved better support in middleboxes. 1132 3.5. Middlebox Traversal Guidelines 1134 Network address translators (NATs) and firewalls are examples of 1135 intermediary devices ("middleboxes") that can exist along an end-to- 1136 end path. A middlebox typically performs a function that requires it 1137 to maintain per-flow state. For connection-oriented protocols, such 1138 as TCP, middleboxes snoop and parse the connection-management 1139 information, and create and destroy per-flow state accordingly. For 1140 a connectionless protocol such as UDP, this approach is not possible. 1141 Consequently, middleboxes can create per-flow state when they see a 1142 packet that -- according to some local criteria -- indicates a new 1143 flow, and destroy the state after some time during which no packets 1144 belonging to the same flow have arrived. 1146 Depending on the specific function that the middlebox performs, this 1147 behavior can introduce a time-dependency that restricts the kinds of 1148 UDP traffic exchanges that will be successful across the middlebox. 1149 For example, NATs and firewalls typically define the partial path on 1150 one side of them to be interior to the domain they serve, whereas the 1151 partial path on their other side is defined to be exterior to that 1152 domain. Per-flow state is typically created when the first packet 1153 crosses from the interior to the exterior, and while the state is 1154 present, NATs and firewalls will forward return traffic. Return 1155 traffic that arrives after the per-flow state has timed out is 1156 dropped, as is other traffic that arrives from the exterior. 1158 Many applications that use UDP for communication operate across 1159 middleboxes without needing to employ additional mechanisms. One 1160 example is the Domain Name System (DNS), which has a strict request- 1161 response communication pattern that typically completes within 1162 seconds. 1164 Other applications may experience communication failures when 1165 middleboxes destroy the per-flow state associated with an application 1166 session during periods when the application does not exchange any UDP 1167 traffic. Applications SHOULD be able to gracefully handle such 1168 communication failures and implement mechanisms to re-establish 1169 application-layer sessions and state. 1171 For some applications, such as media transmissions, this re- 1172 synchronization is highly undesirable, because it can cause user- 1173 perceivable playback artifacts. Such specialized applications MAY 1174 send periodic keep-alive messages to attempt to refresh middlebox 1175 state (e.g., [RFC7675]). It is important to note that keep-alive 1176 messages are not recommended for general use -- they are unnecessary 1177 for many applications and can consume significant amounts of system 1178 and network resources. 1180 An application that needs to employ keep-alive messages to deliver 1181 useful service over UDP in the presence of middleboxes SHOULD NOT 1182 transmit them more frequently than once every 15 seconds and SHOULD 1183 use longer intervals when possible. No common timeout has been 1184 specified for per-flow UDP state for arbitrary middleboxes. NATs 1185 require a state timeout of 2 minutes or longer [RFC4787]. However, 1186 empirical evidence suggests that a significant fraction of currently 1187 deployed middleboxes unfortunately use shorter timeouts. The timeout 1188 of 15 seconds originates with the Interactive Connectivity 1189 Establishment (ICE) protocol [RFC5245]. When an application is 1190 deployed in a controlled environment, the deployer SHOULD investigate 1191 whether the target environment allows applications to use longer 1192 intervals, or whether it offers mechanisms to explicitly control 1193 middlebox state timeout durations, for example, using the Port 1194 Control Protocol (PCP) [RFC6887], Middlebox Communications (MIDCOM) 1195 [RFC3303], Next Steps in Signaling (NSIS) [RFC5973], or Universal 1196 Plug and Play (UPnP) [UPnP]. It is RECOMMENDED that applications 1197 apply slight random variations ("jitter") to the timing of keep-alive 1198 transmissions, to reduce the potential for persistent synchronization 1199 between keep-alive transmissions from different hosts [RFC7675]. 1201 Sending keep-alive messages is not a substitute for implementing a 1202 mechanism to recover from broken sessions. Like all UDP datagrams, 1203 keep-alive messages can be delayed or dropped, causing middlebox 1204 state to time out. In addition, the congestion control guidelines in 1205 Section 3.1 cover all UDP transmissions by an application, including 1206 the transmission of middlebox keep-alive messages. Congestion 1207 control may thus lead to delays or temporary suspension of keep-alive 1208 transmission. 1210 Keep-alive messages are NOT RECOMMENDED for general use. They are 1211 unnecessary for many applications and may consume significant 1212 resources. For example, on battery-powered devices, if an 1213 application needs to maintain connectivity for long periods with 1214 little traffic, the frequency at which keep-alive messages are sent 1215 can become the determining factor that governs power consumption, 1216 depending on the underlying network technology. 1218 Because many middleboxes are designed to require keep-alive messages 1219 for TCP connections at a frequency that is much lower than that 1220 needed for UDP, this difference alone can often be sufficient to 1221 prefer TCP over UDP for these deployments. On the other hand, there 1222 is anecdotal evidence that suggests that direct communication through 1223 middleboxes, e.g., by using ICE [RFC5245], does succeed less often 1224 with TCP than with UDP. The trade-offs between different transport 1225 protocols -- especially when it comes to middlebox traversal -- 1226 deserve careful analysis. 1228 UDP applications that could be deployed in the Internet need to be 1229 designed understanding that there are many variants of middlebox 1230 behavior, and although UDP is connectionless, middleboxes often 1231 maintain state for each UDP flow. Using multiple UDP flows can 1232 consume available state space and also can lead to changes in the way 1233 the middlebox handles subsequent packets (either to protect its 1234 internal resources, or to prevent perceived misuse). The probability 1235 of path failure can increase when applications use multiple UDP flows 1236 in parallel (see Section 5.1.2 for recommendations on usage of 1237 multiple ports). 1239 3.6. Limited Applicability and Controlled Environments 1241 Two different types of applicability have been identified for the 1242 specification of IETF applications that utilize UDP: 1244 General Internet. By default, IETF specifications target deployment 1245 on the general Internet. Experience has shown that successful 1246 protocols developed in one specific context or for a particular 1247 application tend to become used in a wider range of contexts. For 1248 example, a protocol with an initial deployment within a local area 1249 network may subsequently be used over a virtual network that 1250 traverses the Internet, or in the Internet in general. 1251 Applications designed for general Internet use may experience a 1252 range of network device behaviors, and in particular should 1253 consider whether applications need to operate over paths that may 1254 include middleboxes. 1256 Controlled Environment. A protocol/encapsulation/tunnel could be 1257 designed to be used only within a controlled environment. For 1258 example, an application designed for use by a network operator 1259 might only be deployed within the network of that single network 1260 operator or on networks of an adjacent set of cooperating network 1261 operators. The application traffic may then be managed to avoid 1262 congestion, rather than relying on built-in mechanisms, which are 1263 required when operating over the general Internet. Applications 1264 that target a limited applicability use case may be able to take 1265 advantage of specific hardware (e.g., carrier-grade equipment) or 1266 underlying protocol features of the subnetwork over which they are 1267 used. 1269 Specifications addressing a limited applicability use case or a 1270 controlled environment SHOULD identify how in their restricted 1271 deployment a level of safety is provided that is equivalent to that 1272 of a protocol designed for operation over the general Internet (e.g., 1273 a design based on extensive experience with deployments of particular 1274 methods that provide features that cannot be expected in general 1275 Internet equipment and the robustness of the design of MPLS to 1276 corruption of headers both helped justify use of an alternate UDP 1277 integrity check [RFC7510]). 1279 An IETF specification targeting a controlled environment is expected 1280 to provide an applicability statement that restricts the application 1281 traffic to the controlled environment, and would be expected to 1282 describe how methods can be provided to discourage or prevent escape 1283 of corrupted packets from the environment (for example, section 5 of 1284 [RFC7510]). 1286 4. Multicast UDP Usage Guidelines 1288 This section complements Section 3 by providing additional guidelines 1289 that are applicable to multicast and broadcast usage of UDP. 1291 Multicast and broadcast transmission [RFC1112] usually employ the UDP 1292 transport protocol, although they may be used with other transport 1293 protocols (e.g., UDP-Lite). 1295 There are currently two models of multicast delivery: the Any-Source 1296 Multicast (ASM) model as defined in [RFC1112] and the Source-Specific 1297 Multicast (SSM) model as defined in [RFC4607]. ASM group members 1298 will receive all data sent to the group by any source, while SSM 1299 constrains the distribution tree to only one single source. 1301 Specialized classes of applications also use UDP for IP multicast or 1302 broadcast [RFC0919]. The design of such specialized applications 1303 requires expertise that goes beyond simple, unicast-specific 1304 guidelines, since these senders may transmit to potentially very many 1305 receivers across potentially very heterogeneous paths at the same 1306 time, which significantly complicates congestion control, flow 1307 control, and reliability mechanisms. 1309 This section provides guidance on multicast and broadcast UDP usage. 1310 Use of broadcast by an application is normally constrained by routers 1311 to the local subnetwork. However, use of tunneling techniques and 1312 proxies can and does result in some broadcast traffic traversing 1313 Internet paths. These guidelines therefore also apply to broadcast 1314 traffic. 1316 The IETF has defined a reliable multicast framework [RFC3048] and 1317 several building blocks to aid the designers of multicast 1318 applications, such as [RFC3738] or [RFC4654]. 1320 Senders to anycast destinations must be aware that successive 1321 messages sent to the same anycast IP address may be delivered to 1322 different anycast nodes, i.e., arrive at different locations in the 1323 topology. 1325 Most UDP tunnels that carry IP multicast traffic use a tunnel 1326 encapsulation with a unicast destination address, such as Automatic 1327 Multicast Tunneling [RFC7450]. These MUST follow the same 1328 requirements as a tunnel carrying unicast data (see Section 3.1.11). 1329 There are deployment cases and solutions where the outer header of a 1330 UDP tunnel contains a multicast destination address, such as 1331 [RFC6513]. These cases are primarily deployed in controlled 1332 environments over reserved capacity, often operating within a single 1333 administrative domain, or between two domains over a bi-laterally 1334 agreed upon path with reserved capacity, and so congestion control is 1335 OPTIONAL, but circuit breaker techniques are still RECOMMENDED in 1336 order to restore some degree of service should the offered load 1337 exceed the reserved capacity (e.g., due to misconfiguration). 1339 4.1. Multicast Congestion Control Guidelines 1341 Unicast congestion-controlled transport mechanisms are often not 1342 applicable to multicast distribution services, or simply do not scale 1343 to large multicast trees, since they require bi-directional 1344 communication and adapt the sending rate to accommodate the network 1345 conditions to a single receiver. In contrast, multicast distribution 1346 trees may fan out to massive numbers of receivers, which limits the 1347 scalability of an in-band return channel to control the sending rate, 1348 and the one-to-many nature of multicast distribution trees prevents 1349 adapting the rate to the requirements of an individual receiver. For 1350 this reason, generating TCP-compatible aggregate flow rates for 1351 Internet multicast data, either native or tunneled, is the 1352 responsibility of the application implementing the congestion 1353 control. 1355 Applications using multicast SHOULD provide appropriate congestion 1356 control. Multicast congestion control needs to be designed using 1357 mechanisms that are robust to the potential heterogeneity of both the 1358 multicast distribution tree and the receivers belonging to a group. 1359 Heterogeneity may manifest itself in some receivers experiencing more 1360 loss that others, higher delay, and/or less ability to respond to 1361 network conditions. Congestion control is particularly important for 1362 any multicast session where all or part of the multicast distribution 1363 tree spans an access network (e.g., a home gateway). Two styles of 1364 congestion control have been defined in the RFC-series: 1366 o Feedback-based congestion control, in which the sender receives 1367 multicast or unicast UDP messages from the receivers allowing it 1368 to assess the level of congestion and then adjust the sender 1369 rate(s) (e.g., [RFC5740],[RFC4654]). Multicast methods may 1370 operate on longer timescales than for unicast (e.g., due to the 1371 higher group RTT of a heterogeneous group). A control method 1372 could decide not to reduce the rate of the entire multicast group 1373 in response to a control message received from a single receiver 1374 (e.g., a sender could set a minimum rate and decide to request a 1375 congested receiver to leave the multicast group and could also 1376 decide to distribute content to these congested receivers at a 1377 lower rate using unicast congestion control). 1379 o Receiver-driven congestion control, which does not require a 1380 receiver to send explicit UDP control messages for congestion 1381 control (e.g., [RFC3738], [RFC5775]). Instead, the sender 1382 distributes the data across multiple IP multicast groups (e.g., 1383 using a set of {S,G} channels). Each receiver determines its own 1384 level of congestion and controls its reception rate using only 1385 multicast join/leave messages sent in the network control plane. 1386 This method scales to arbitrary large groups of receivers. 1388 Any multicast-enabled receiver may attempt to join and receive 1389 traffic from any group. This may imply the need for rate limits on 1390 individual receivers or the aggregate multicast service. Note there 1391 is no way at the transport layer to prevent a join message 1392 propagating to the next-hop router. 1394 Some classes of multicast applications support applications that can 1395 monitor the user-level quality of the transfer at the receiver. 1396 Applications that can detect a significant reduction in user quality 1397 SHOULD regard this as a congestion signal (e.g., to leave a group 1398 using layered multicast encoding) or, if not, SHOULD use this signal 1399 to provide a circuit breaker to terminate the flow by leaving the 1400 multicast group. 1402 4.1.1. Bulk Transfer Multicast Applications 1404 Applications that perform bulk transmission of data over a multicast 1405 distribution tree, i.e., applications that exchange more than a few 1406 UDP datagrams per RTT, SHOULD implement a method for congestion 1407 control. The currently RECOMMENDED IETF methods are: Asynchronous 1408 Layered Coding (ALC) [RFC5775], TCP-Friendly Multicast Congestion 1409 Control (TFMCC) [RFC4654], Wave and Equation Based Rate Control 1410 (WEBRC) [RFC3738], NACK-Oriented Reliable Multicast (NORM) transport 1411 protocol [RFC5740], File Delivery over Unidirectional Transport 1412 (FLUTE) [RFC6726], Real Time Protocol/Control Protocol (RTP/RTCP) 1413 [RFC3550]. 1415 An application can alternatively implement another congestion control 1416 schemes following the guidelines of [RFC2887] and utilizing the 1417 framework of [RFC3048]. Bulk transfer applications that choose not 1418 to implement [RFC4654], [RFC5775], [RFC3738], [RFC5740], [RFC6726], 1419 or [RFC3550] SHOULD implement a congestion control scheme that 1420 results in bandwidth use that competes fairly with TCP within an 1421 order of magnitude. 1423 Section 2 of [RFC3551] states that multimedia applications SHOULD 1424 monitor the packet loss rate to ensure that it is within acceptable 1425 parameters. Packet loss is considered acceptable if a TCP flow 1426 across the same network path under the same network conditions would 1427 achieve an average throughput, measured on a reasonable timescale, 1428 that is not less than that of the UDP flow. The comparison to TCP 1429 cannot be specified exactly, but is intended as an "order-of- 1430 magnitude" comparison in timescale and throughput. 1432 4.1.2. Low Data-Volume Multicast Applications 1434 All the recommendations in Section 3.1.3 are also applicable to low 1435 data-volume multicast applications. 1437 4.2. Message Size Guidelines for Multicast 1439 A multicast application SHOULD NOT send UDP datagrams that result in 1440 IP packets that exceed the effective MTU as described in section 3 of 1441 [RFC6807]. Consequently, an application SHOULD either use the 1442 effective MTU information provided by the Population Count Extensions 1443 to Protocol Independent Multicast [RFC6807] or implement path MTU 1444 discovery itself (see Section 3.2) to determine whether the path to 1445 each destination will support its desired message size without 1446 fragmentation. 1448 5. Programming Guidelines 1450 The de facto standard application programming interface (API) for 1451 TCP/IP applications is the "sockets" interface [POSIX]. Some 1452 platforms also offer applications the ability to directly assemble 1453 and transmit IP packets through "raw sockets" or similar facilities. 1454 This is a second, more cumbersome method of using UDP. The 1455 guidelines in this document cover all such methods through which an 1456 application may use UDP. Because the sockets API is by far the most 1457 common method, the remainder of this section discusses it in more 1458 detail. 1460 Although the sockets API was developed for UNIX in the early 1980s, a 1461 wide variety of non-UNIX operating systems also implement it. The 1462 sockets API supports both IPv4 and IPv6 [RFC3493]. The UDP sockets 1463 API differs from that for TCP in several key ways. Because 1464 application programmers are typically more familiar with the TCP 1465 sockets API, this section discusses these differences. [STEVENS] 1466 provides usage examples of the UDP sockets API. 1468 UDP datagrams may be directly sent and received, without any 1469 connection setup. Using the sockets API, applications can receive 1470 packets from more than one IP source address on a single UDP socket. 1471 Some servers use this to exchange data with more than one remote host 1472 through a single UDP socket at the same time. Many applications need 1473 to ensure that they receive packets from a particular source address; 1474 these applications MUST implement corresponding checks at the 1475 application layer or explicitly request that the operating system 1476 filter the received packets. 1478 Many operating systems also allow a UDP socket to be connected, i.e., 1479 to bind a UDP socket to a specific pair of addresses and ports. This 1480 is similar to the corresponding TCP sockets API functionality. 1481 However, for UDP, this is only a local operation that serves to 1482 simplify the local send/receive functions and to filter the traffic 1483 for the specified addresses and ports. Binding a UDP socket does not 1484 establish a connection -- UDP does not notify the remote end when a 1485 local UDP socket is bound. Binding a socket also allows configuring 1486 options that affect the UDP or IP layers, for example, use of the UDP 1487 checksum or the IP Timestamp option. On some stacks, a bound socket 1488 also allows an application to be notified when ICMP error messages 1489 are received for its transmissions [RFC1122]. 1491 If a client/server application executes on a host with more than one 1492 IP interface, the application SHOULD send any UDP responses with an 1493 IP source address that matches the IP destination address of the UDP 1494 datagram that carried the request (see [RFC1122], Section 4.1.3.5). 1495 Many middleboxes expect this transmission behavior and drop replies 1496 that are sent from a different IP address, as explained in 1497 Section 3.5. 1499 A UDP receiver can receive a valid UDP datagram with a zero-length 1500 payload. Note that this is different from a return value of zero 1501 from a read() socket call, which for TCP indicates the end of the 1502 connection. 1504 UDP provides no flow-control, i.e., the sender at any given time does 1505 not know whether the receiver is able to handle incoming 1506 transmissions. This is another reason why UDP-based applications 1507 need to be robust in the presence of packet loss. This loss can also 1508 occur within the sending host, when an application sends data faster 1509 than the line rate of the outbound network interface. It can also 1510 occur at the destination, where receive calls fail to return all the 1511 data that was sent when the application issues them too infrequently 1512 (i.e., such that the receive buffer overflows). Robust flow control 1513 mechanisms are difficult to implement, which is why applications that 1514 need this functionality SHOULD consider using a full-featured 1515 transport protocol such as TCP. 1517 When an application closes a TCP, SCTP or DCCP socket, the transport 1518 protocol on the receiving host is required to maintain TIME-WAIT 1519 state. This prevents delayed packets from the closed connection 1520 instance from being mistakenly associated with a later connection 1521 instance that happens to reuse the same IP address and port pairs. 1522 The UDP protocol does not implement such a mechanism. Therefore, 1523 UDP-based applications need to be robust to reordering and delay. 1524 One application may close a socket or terminate, followed in time by 1525 another application receiving on the same port. This later 1526 application may then receive packets intended for the first 1527 application that were delayed in the network. 1529 5.1. Using UDP Ports 1531 The rules and procedures for the management of the Service Name and 1532 Transport Protocol Port Number Registry are specified in [RFC6335]. 1533 Recommendations for use of UDP ports are provided in [RFC7605]. 1535 A UDP sender SHOULD NOT use a source port value of zero. A source 1536 port number that cannot be easily determined from the address or 1537 payload type provides protection at the receiver from data injection 1538 attacks by off-path devices. A UDP receiver SHOULD NOT bind to port 1539 zero. 1541 Applications SHOULD implement receiver port and address checks at the 1542 application layer or explicitly request that the operating system 1543 filter the received packets to prevent receiving packets with an 1544 arbitrary port. This measure is designed to provide additional 1545 protection from data injection attacks from an off-path source (where 1546 the port values may not be known). 1548 Applications SHOULD provide a check that protects from off-path data 1549 injection, avoiding an application receiving packets that were 1550 created by an unauthorized third party. TCP stacks commonly use a 1551 randomized source port to provide this protection [RFC6056]; UDP 1552 applications should follow the same technique. Middleboxes and end 1553 systems often make assumptions about the system ports or user ports, 1554 hence it is recommended to use randomized ports in the Dynamic and/or 1555 Private Port range. Setting a "randomized" source port also provides 1556 greater assurance that reported ICMP errors originate from network 1557 systems on the path used by a particular flow. Some UDP applications 1558 choose to use a predetermined value for the source port (including 1559 some multicast applications), these applications need to therefore 1560 employ a different technique. Protection from off-path data attacks 1561 can also be provided by randomizing the initial value of another 1562 protocol field within the datagram payload, and checking the validity 1563 of this field at the receiver (e.g., RTP has random initial sequence 1564 number and random media timestamp offsets [RFC3550]). 1566 When using multicast, IP routers perform a reverse-path forwarding 1567 (RPF) check for each multicast packet. This provides protection from 1568 off-path data injection. When a receiver joins a multicast group and 1569 filters based on the source address the filter verifies the sender's 1570 IP address. This is always the case when using a SSM {S,G} channel. 1572 5.1.1. Usage of UDP for source port entropy and the IPv6 Flow Label 1574 Some applications use the UDP datagram header as a source of entropy 1575 for network devices that implement ECMP [RFC6438]. A UDP tunnel 1576 application targeting this usage, encapsulates an inner packet using 1577 UDP, where the UDP source port value forms a part of the entropy that 1578 can be used to balance forwarding of network traffic by the devices 1579 that use ECMP. A sending tunnel endpoint selects a source port value 1580 in the UDP datagram header that is computed from the inner flow 1581 information (e.g., the encapsulated packet headers). To provide 1582 sufficient entropy the sending tunnel endpoint maps the encapsulated 1583 traffic to one of a range of UDP source values. The value SHOULD be 1584 within the ephemeral port range, i.e., 49152 to 65535, where the high 1585 order two bits of the port are set to one. The available source port 1586 entropy of 14 bits (using the ephemeral port range) plus the outer IP 1587 addresses seems sufficient for entropy for most ECMP applications 1588 [I-D.ietf-rtgwg-dt-encap]. 1590 To avoid reordering within an IP flow, the same UDP source port value 1591 SHOULD be used for all packets assigned to an encapsulated flow 1592 (e.g., using a hash of the relevant headers). The entropy mapping 1593 for a flow MAY change over the lifetime of the encapsulated flow 1594 [I-D.ietf-rtgwg-dt-encap]. For instance, this could be changed as a 1595 Denial of Service (DOS) mitigation, or as a means to effect routing 1596 through the ECMP network. However, the source port selected for a 1597 flow SHOULD NOT change more than once in every thirty seconds (e.g., 1598 as in [I-D.ietf-tsvwg-gre-in-udp-encap]). 1600 The use of the source port field for entropy has several side-effects 1601 that need to be considered, including: 1603 o It can increase the probability of misdelivery of corrupted 1604 packets, which increases the need for checksum computation or an 1605 equivalent mechanism to protect other UDP applications from 1606 misdelivery errors Section 3.4. 1608 o It is expected to reduce the probability of successful middlebox 1609 traversal Section 3.5. This use of the source port field will 1610 often not be suitable for applications targeting deployment in the 1611 general Internet. 1613 o It can prevent the field being usable to protect from off-path 1614 attacks (described in Section 5.1). Designers therefore need to 1615 consider other mechanisms to provide equivalent protection (e.g., 1616 to restrict use to a controlled environment [RFC7510] 1617 Section 3.6). 1619 The UDP source port number field has also been leveraged to produce 1620 entropy with IPv6. However, in the case of IPv6, the "flow label" 1621 [RFC6437] may also alternatively be used as entropy for load 1622 balancing [RFC6438]. This use of the flow label for load balancing 1623 is consistent with the definition of the field, although further 1624 clarity was needed to ensure the field can be consistently used for 1625 this purpose. Therefore, an updated IPv6 flow label [RFC6437] and 1626 ECMP routing [RFC6438] usage was specified. 1628 To ensure future opportunities to use the flow label, UDP 1629 applications SHOULD set the flow label field, even when an entropy 1630 value is also set in the source port field (e.g., An IPv6 tunnel 1631 endpoint could copy the source port flow entropy value to the IPv6 1632 flow label field [I-D.ietf-tsvwg-gre-in-udp-encap]). Router vendors 1633 are encouraged to start using the IPv6 flow label as a part of the 1634 flow hash, providing support for IP-level ECMP without requiring use 1635 of UDP. The end-to-end use of flow labels for load balancing is a 1636 long-term solution. Even if the usage of the flow label has been 1637 clarified, there will be a transition time before a significant 1638 proportion of endpoints start to assign a good quality flow label to 1639 the flows that they originate. The use of load balancing using the 1640 transport header fields will likely continue until widespread 1641 deployment is finally achieved. 1643 5.1.2. Applications using Multiple UDP Ports 1645 A single application may exchange several types of data. In some 1646 cases, this may require multiple UDP flows (e.g., multiple sets of 1647 flows, identified by different five-tuples). [RFC6335] recommends 1648 application developers not to apply to IANA to be assigned multiple 1649 well-known ports (user or system). This does not discuss the 1650 implications of using multiple flows with the same well-known port or 1651 pairs of dynamic ports (e.g., identified by a service name or 1652 signaling protocol). 1654 Use of multiple flows can affect the network in several ways: 1656 o Starting a series of successive connections can increase the 1657 number of state bindings in middleboxes (e.g., NAPT or Firewall) 1658 along the network path. UDP-based middlebox traversal usually 1659 relies on timeouts to remove old state, since middleboxes are 1660 unaware when a particular flow ceases to be used by an 1661 application. 1663 o Using several flows at the same time may result in seeing 1664 different network characteristics for each flow. It cannot be 1665 assumed both follow the same path (e.g., when ECMP is used, 1666 traffic is intentionally hashed onto different parallel paths 1667 based on the port numbers). 1669 o Using several flows can also increase the occupancy of a binding 1670 or lookup table in a middlebox (e.g., NAPT or Firewall), which may 1671 cause the device to change the way it manages the flow state. 1673 o Further, using excessive numbers of flows can degrade the ability 1674 of a unicast congestion control to react to congestion events, 1675 unless the congestion state is shared between all flows in a 1676 session. A receiver-driven multicast congestion control requires 1677 the sending application to distribute its data over a set of IP 1678 multicast groups, each receiver is therefore expected to receive 1679 data from a modest number of simultaneously active UDP ports. 1681 Therefore, applications MUST NOT assume consistent behavior of 1682 middleboxes when multiple UDP flows are used; many devices respond 1683 differently as the number of used ports increases. Using multiple 1684 flows with different QoS requirements requires applications to verify 1685 that the expected performance is achieved using each individual flow 1686 (five-tuple), see Section 3.1.9. 1688 5.2. ICMP Guidelines 1690 Applications can utilize information about ICMP error messages that 1691 the UDP layer passes up for a variety of purposes [RFC1122]. 1692 Applications SHOULD appropriately validate the payload of ICMP 1693 messages to ensure these are received in response to transmitted 1694 traffic (i.e., a reported error condition that corresponds to a UDP 1695 datagram actually sent by the application). This requires context, 1696 such as local state about communication instances to each 1697 destination, that although readily available in connection-oriented 1698 transport protocols is not always maintained by UDP-based 1699 applications. Note that not all platforms have the necessary APIs to 1700 support this validation, and some platforms already perform this 1701 validation internally before passing ICMP information to the 1702 application. 1704 Any application response to ICMP error messages SHOULD be robust to 1705 temporary routing failures (sometimes called "soft errors"), e.g., 1706 transient ICMP "unreachable" messages ought to not normally cause a 1707 communication abort. 1709 ICMP messages are being increasingly filtered by middleboxes. A UDP 1710 application therefore SHOULD NOT rely on their delivery for correct 1711 and safe operation. 1713 6. Security Considerations 1715 UDP does not provide communications security. Applications that need 1716 to protect their communications against eavesdropping, tampering, or 1717 message forgery SHOULD employ end-to-end security services provided 1718 by other IETF protocols. 1720 UDP applications SHOULD provide protection from off-path data 1721 injection attacks using a randomized source port or equivalent 1722 technique (see Section 5.1). 1724 Applications that respond to short requests with potentially large 1725 responses are a potential vector for amplification attacks, and 1726 SHOULD take steps to minimize their potential for being abused as 1727 part of a DoS attack. That could mean authenticating the sender 1728 before responding; noting that the source IP address of a request is 1729 not a useful authenticator, because it can easily be spoofed. Or it 1730 may mean otherwise limiting the cases where short unauthenticated 1731 requests produce large responses. Applications MAY also want to 1732 offer ways to limit the number of requests they respond to in a time 1733 interval, in order to cap the bandwidth they consume. 1735 One option for securing UDP communications is with IPsec [RFC4301], 1736 which can provide authentication for flows of IP packets through the 1737 Authentication Header (AH) [RFC4302] and encryption and/or 1738 authentication through the Encapsulating Security Payload (ESP) 1739 [RFC4303]. Applications use the Internet Key Exchange (IKE) 1740 [RFC7296] to configure IPsec for their sessions. Depending on how 1741 IPsec is configured for a flow, it can authenticate or encrypt the 1742 UDP headers as well as UDP payloads. If an application only requires 1743 authentication, ESP with no encryption but with authentication is 1744 often a better option than AH, because ESP can operate across 1745 middleboxes. An application that uses IPsec requires the support of 1746 an operating system that implements the IPsec protocol suite, and the 1747 network path must permit IKE and IPsec traffic. This may become more 1748 common with IPv6 deployments [RFC6092]. 1750 Although it is possible to use IPsec to secure UDP communications, 1751 not all operating systems support IPsec or allow applications to 1752 easily configure it for their flows. A second option for securing 1753 UDP communications is through Datagram Transport Layer Security 1754 (DTLS) [RFC6347][RFC7525]. DTLS provides communication privacy by 1755 encrypting UDP payloads. It does not protect the UDP headers. 1756 Applications can implement DTLS without relying on support from the 1757 operating system. 1759 Many other options for authenticating or encrypting UDP payloads 1760 exist. For example, the GSS-API security framework [RFC2743] or 1761 Cryptographic Message Syntax (CMS) [RFC5652] could be used to protect 1762 UDP payloads. There exist a number of security options for RTP 1763 [RFC3550] over UDP, especially to accomplish key-management, see 1764 [RFC7201]. These options covers many usages, including point-to- 1765 point, centralized group communication as well as multicast. In some 1766 applications, a better solution is to protect larger stand-alone 1767 objects, such as files or messages, instead of individual UDP 1768 payloads. In these situations, CMS [RFC5652], S/MIME [RFC5751] or 1769 OpenPGP [RFC4880] could be used. In addition, there are many non- 1770 IETF protocols in this area. 1772 Like congestion control mechanisms, security mechanisms are difficult 1773 to design and implement correctly. It is hence RECOMMENDED that 1774 applications employ well-known standard security mechanisms such as 1775 DTLS or IPsec, rather than inventing their own. 1777 The Generalized TTL Security Mechanism (GTSM) [RFC5082] may be used 1778 with UDP applications when the intended endpoint is on the same link 1779 as the sender. This lightweight mechanism allows a receiver to 1780 filter unwanted packets. 1782 In terms of congestion control, [RFC2309] and [RFC2914] discuss the 1783 dangers of congestion-unresponsive flows to the Internet. 1784 [I-D.ietf-tsvwg-circuit-breaker] describes methods that can be used 1785 to set a performance envelope that can assist in preventing 1786 congestion collapse in the absence of congestion control or when the 1787 congestion control fails to react to congestion events. This 1788 document provides guidelines to designers of UDP-based applications 1789 to congestion-control their transmissions, and does not raise any 1790 additional security concerns. 1792 Some network operators have experienced surges of UDP attack traffic 1793 that are multiple orders of magnitude above the baseline traffic rate 1794 for UDP. This can motivate operators to limit the data rate or 1795 packet rate of UDP traffic. This may in turn limit the throughput 1796 that an application can achieve using UDP and could also result in 1797 higher packet loss for UDP traffic that would not be experienced if 1798 other transport protocols had been used. 1800 A UDP application with a long-lived association between the sender 1801 and receiver, ought to be designed so that the sender periodically 1802 checks that the receiver still wants ("consents") to receive traffic 1803 and need to be designed to stop if there is no explicit confirmation 1804 of this [RFC7675]. Applications that require communications in two 1805 directions to implement protocol functions (such as reliability or 1806 congestion control) will need to independently check both directions 1807 of communication, and may have to exchange keep-alive messages to 1808 traverse middleboxes (see Section 3.5). 1810 7. Summary 1812 This section summarizes the key guidelines made in Sections 3 - 6 in 1813 a tabular format (Table 1) for easy referencing. 1815 +---------------------------------------------------------+---------+ 1816 | Recommendation | Section | 1817 +---------------------------------------------------------+---------+ 1818 | MUST tolerate a wide range of Internet path conditions | 3 | 1819 | SHOULD use a full-featured transport (e.g., TCP) | | 1820 | | | 1821 | SHOULD control rate of transmission | 3.1 | 1822 | SHOULD perform congestion control over all traffic | | 1823 | | | 1824 | for bulk transfers, | 3.1.2 | 1825 | SHOULD consider implementing TFRC | | 1826 | else, SHOULD in other ways use bandwidth similar to TCP | | 1827 | | | 1828 | for non-bulk transfers, | 3.1.3 | 1829 | SHOULD measure RTT and transmit max. 1 datagram/RTT | 3.1.1 | 1830 | else, SHOULD send at most 1 datagram every 3 seconds | | 1831 | SHOULD back-off retransmission timers following loss | | 1832 | | | 1833 | SHOULD provide mechanisms to regulate the bursts of | 3.1.6 | 1834 | transmission | | 1835 | | | 1836 | MAY implement ECN; a specific set of application | 3.1.7 | 1837 | mechanisms are REQUIRED if ECN is used. | | 1838 | | | 1839 | for DiffServ, SHOULD NOT rely on implementation of PHBs | 3.1.8 | 1840 | | | 1841 | for QoS-enabled paths, MAY choose not to use CC | 3.1.9 | 1842 | | | 1843 | SHOULD NOT rely solely on QoS for their capacity | 3.1.10 | 1844 | non-CC controlled flows SHOULD implement a transport | | 1845 | circuit breaker | | 1846 | MAY implement a circuit breaker for other applications | | 1847 | | | 1848 | for tunnels carrying IP traffic, | 3.1.11 | 1849 | SHOULD NOT perform congestion control | | 1850 | MUST correctly process the IP ECN field | | 1851 | | | 1852 | for non-IP tunnels or rate not determined by traffic, | | 1853 | SHOULD perform CC or use circuit breaker | 3.1.11 | 1854 | SHOULD restrict types of traffic transported by the | | 1855 | tunnel | | 1856 | | | 1857 | SHOULD NOT send datagrams that exceed the PMTU, i.e., | 3.2 | 1858 | SHOULD discover PMTU or send datagrams < minimum PMTU; | | 1859 | Specific application mechanisms are REQUIRED if PLPMTUD | | 1860 | is used. | | 1861 | | | 1862 | SHOULD handle datagram loss, duplication, reordering | 3.3 | 1863 | SHOULD be robust to delivery delays up to 2 minutes | | 1864 | | | 1865 | SHOULD enable IPv4 UDP checksum | 3.4 | 1866 | SHOULD enable IPv6 UDP checksum; Specific application | 3.4.1 | 1867 | mechanisms are REQUIRED if a zero IPv6 UDP checksum is | | 1868 | used. | | 1869 | | | 1870 | SHOULD provide protection from off-path attacks | 5.1 | 1871 | else, MAY use UDP-Lite with suitable checksum coverage | 3.4.2 | 1872 | | | 1873 | SHOULD NOT always send middlebox keep-alive messages | 3.5 | 1874 | MAY use keep-alives when needed (min. interval 15 sec) | | 1875 | | | 1876 | Applications specified for use in limited use (or | 3.6 | 1877 | controlled environments) SHOULD identify equivalent | | 1878 | mechanisms and describe their use-case. | | 1879 | | | 1880 | Bulk multicast apps SHOULD implement congestion control | 4.1.1 | 1881 | | | 1882 | Low volume multicast apps SHOULD implement congestion | 4.1.2 | 1883 | control | | 1884 | | | 1885 | Multicast apps SHOULD use a safe PMTU | 4.2 | 1886 | | | 1887 | SHOULD avoid using multiple ports | 5.1.2 | 1888 | MUST check received IP source address | | 1889 | | | 1890 | SHOULD validate payload in ICMP messages | 5.2 | 1891 | | | 1892 | SHOULD use a randomized source port or equivalent | 6 | 1893 | technique, and, for client/server applications, SHOULD | | 1894 | send responses from source address matching request | | 1895 | | | 1896 | SHOULD use standard IETF security protocols when needed | 6 | 1897 +---------------------------------------------------------+---------+ 1899 Table 1: Summary of recommendations 1901 8. IANA Considerations 1903 Note to RFC-Editor: please remove this entire section prior to 1904 publication. 1906 This document raises no IANA considerations. 1908 9. Acknowledgments 1910 The middlebox traversal guidelines in Section 3.5 incorporate ideas 1911 from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda 1912 Srisuresh, and Dan Kegel. The protocol timer guidelines in 1913 Section 3.1.1 were largely contributed by Mark Allman. 1915 G. Fairhurst received funding from the European Union's Horizon 2020 1916 research and innovation program 2014-2018 under grant agreement No. 1917 644334 (NEAT). Lars Eggert has received funding from the European 1918 Union's Horizon 2020 research and innovation program 2014-2018 under 1919 grant agreement No. 644866 (SSICLOPS). This document reflects only 1920 the authors' views and the European Commission is not responsible for 1921 any use that may be made of the information it contains. 1923 10. References 1925 10.1. Normative References 1927 [I-D.ietf-tsvwg-circuit-breaker] 1928 Fairhurst, G., "Network Transport Circuit Breakers", 1929 draft-ietf-tsvwg-circuit-breaker-15 (work in progress), 1930 April 2016. 1932 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1933 DOI 10.17487/RFC0768, August 1980, 1934 . 1936 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1937 RFC 793, DOI 10.17487/RFC0793, September 1981, 1938 . 1940 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1941 Communication Layers", STD 3, RFC 1122, 1942 DOI 10.17487/RFC1122, October 1989, 1943 . 1945 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1946 DOI 10.17487/RFC1191, November 1990, 1947 . 1949 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1950 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1951 1996, . 1953 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1954 Requirement Levels", BCP 14, RFC 2119, 1955 DOI 10.17487/RFC2119, March 1997, 1956 . 1958 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1959 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1960 December 1998, . 1962 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 1963 RFC 2914, DOI 10.17487/RFC2914, September 2000, 1964 . 1966 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., 1967 and G. Fairhurst, Ed., "The Lightweight User Datagram 1968 Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 1969 2004, . 1971 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 1972 Translation (NAT) Behavioral Requirements for Unicast 1973 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 1974 2007, . 1976 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1977 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1978 . 1980 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 1981 Friendly Rate Control (TFRC): Protocol Specification", 1982 RFC 5348, DOI 10.17487/RFC5348, September 2008, 1983 . 1985 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1986 for Application Designers", BCP 145, RFC 5405, 1987 DOI 10.17487/RFC5405, November 2008, 1988 . 1990 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 1991 Notification", RFC 6040, DOI 10.17487/RFC6040, November 1992 2010, . 1994 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1995 "Computing TCP's Retransmission Timer", RFC 6298, 1996 DOI 10.17487/RFC6298, June 2011, 1997 . 1999 10.2. Informative References 2001 [ALLMAN] Allman, M. and E. Blanton, "Notes on burst mitigation for 2002 transport protocols", March 2005. 2004 [FABER] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT State in 2005 TCP and Its Effect on Busy Servers", Proc. IEEE Infocom, 2006 March 1999. 2008 [I-D.ford-behave-app] 2009 Ford, B., "Application Design Guidelines for Traversal 2010 through Network Address Translators", draft-ford-behave- 2011 app-05 (work in progress), March 2007. 2013 [I-D.ietf-aqm-ecn-benefits] 2014 Fairhurst, G. and M. Welzl, "The Benefits of using 2015 Explicit Congestion Notification (ECN)", draft-ietf-aqm- 2016 ecn-benefits-08 (work in progress), November 2015. 2018 [I-D.ietf-avtcore-rtp-circuit-breakers] 2019 Perkins, C. and V. Singh, "Multimedia Congestion Control: 2020 Circuit Breakers for Unicast RTP Sessions", draft-ietf- 2021 avtcore-rtp-circuit-breakers-18 (work in progress), August 2022 2016. 2024 [I-D.ietf-intarea-tunnels] 2025 Touch, J. and W. Townsley, "IP Tunnels in the Internet 2026 Architecture", draft-ietf-intarea-tunnels-03 (work in 2027 progress), July 2016. 2029 [I-D.ietf-rtgwg-dt-encap] 2030 Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger, 2031 L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation 2032 Considerations", draft-ietf-rtgwg-dt-encap-01 (work in 2033 progress), March 2016. 2035 [I-D.ietf-tsvwg-gre-in-udp-encap] 2036 Yong, L., Crabbe, E., Xu, X., and T. Herbert, "GRE-in-UDP 2037 Encapsulation", draft-ietf-tsvwg-gre-in-udp-encap-19 (work 2038 in progress), September 2016. 2040 [POSIX] IEEE Std. 1003.1-2001, , "Standard for Information 2041 Technology - Portable Operating System Interface (POSIX)", 2042 Open Group Technical Standard: Base Specifications Issue 2043 6, ISO/IEC 9945:2002, December 2001. 2045 [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, 2046 RFC 919, DOI 10.17487/RFC0919, October 1984, 2047 . 2049 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 2050 RFC 1112, DOI 10.17487/RFC1112, August 1989, 2051 . 2053 [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. 2054 Miller, "Common DNS Implementation Errors and Suggested 2055 Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993, 2056 . 2058 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 2059 Anycasting Service", RFC 1546, DOI 10.17487/RFC1546, 2060 November 1993, . 2062 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 2063 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 2064 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 2065 S., Wroclawski, J., and L. Zhang, "Recommendations on 2066 Queue Management and Congestion Avoidance in the 2067 Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, 2068 . 2070 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2071 and W. Weiss, "An Architecture for Differentiated 2072 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 2073 . 2075 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 2076 RFC 2675, DOI 10.17487/RFC2675, August 1999, 2077 . 2079 [RFC2743] Linn, J., "Generic Security Service Application Program 2080 Interface Version 2, Update 1", RFC 2743, 2081 DOI 10.17487/RFC2743, January 2000, 2082 . 2084 [RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R., 2085 Vicisano, L., and M. Luby, "The Reliable Multicast Design 2086 Space for Bulk Data Transfer", RFC 2887, 2087 DOI 10.17487/RFC2887, August 2000, 2088 . 2090 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2091 RFC 2983, DOI 10.17487/RFC2983, October 2000, 2092 . 2094 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 2095 Floyd, S., and M. Luby, "Reliable Multicast Transport 2096 Building Blocks for One-to-Many Bulk-Data Transfer", 2097 RFC 3048, DOI 10.17487/RFC3048, January 2001, 2098 . 2100 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 2101 RFC 3124, DOI 10.17487/RFC3124, June 2001, 2102 . 2104 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2105 of Explicit Congestion Notification (ECN) to IP", 2106 RFC 3168, DOI 10.17487/RFC3168, September 2001, 2107 . 2109 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2110 A., Peterson, J., Sparks, R., Handley, M., and E. 2111 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2112 DOI 10.17487/RFC3261, June 2002, 2113 . 2115 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 2116 A. Rayhan, "Middlebox communication architecture and 2117 framework", RFC 3303, DOI 10.17487/RFC3303, August 2002, 2118 . 2120 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 2121 Stevens, "Basic Socket Interface Extensions for IPv6", 2122 RFC 3493, DOI 10.17487/RFC3493, February 2003, 2123 . 2125 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2126 Jacobson, "RTP: A Transport Protocol for Real-Time 2127 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2128 July 2003, . 2130 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2131 Video Conferences with Minimal Control", STD 65, RFC 3551, 2132 DOI 10.17487/RFC3551, July 2003, 2133 . 2135 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate 2136 Control (WEBRC) Building Block", RFC 3738, 2137 DOI 10.17487/RFC3738, April 2004, 2138 . 2140 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 2141 Conrad, "Stream Control Transmission Protocol (SCTP) 2142 Partial Reliability Extension", RFC 3758, 2143 DOI 10.17487/RFC3758, May 2004, 2144 . 2146 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 2147 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2148 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2149 RFC 3819, DOI 10.17487/RFC3819, July 2004, 2150 . 2152 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2153 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2154 December 2005, . 2156 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2157 DOI 10.17487/RFC4302, December 2005, 2158 . 2160 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2161 RFC 4303, DOI 10.17487/RFC4303, December 2005, 2162 . 2164 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2165 Congestion Control Protocol (DCCP)", RFC 4340, 2166 DOI 10.17487/RFC4340, March 2006, 2167 . 2169 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 2170 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 2171 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 2172 2006, . 2174 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 2175 Datagram Congestion Control Protocol (DCCP) Congestion 2176 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 2177 DOI 10.17487/RFC4342, March 2006, 2178 . 2180 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 2181 Network Address Translations (NATs)", RFC 4380, 2182 DOI 10.17487/RFC4380, February 2006, 2183 . 2185 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 2186 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 2187 . 2189 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 2190 Congestion Control (TFMCC): Protocol Specification", 2191 RFC 4654, DOI 10.17487/RFC4654, August 2006, 2192 . 2194 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2195 Thayer, "OpenPGP Message Format", RFC 4880, 2196 DOI 10.17487/RFC4880, November 2007, 2197 . 2199 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 2200 ICMPv6 Messages in Firewalls", RFC 4890, 2201 DOI 10.17487/RFC4890, May 2007, 2202 . 2204 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2205 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2206 . 2208 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 2209 Errors at High Data Rates", RFC 4963, 2210 DOI 10.17487/RFC4963, July 2007, 2211 . 2213 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 2214 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 2215 . 2217 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 2218 Pignataro, "The Generalized TTL Security Mechanism 2219 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 2220 . 2222 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2223 (ICE): A Protocol for Network Address Translator (NAT) 2224 Traversal for Offer/Answer Protocols", RFC 5245, 2225 DOI 10.17487/RFC5245, April 2010, 2226 . 2228 [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 2229 Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate 2230 Control for Small Packets (TFRC-SP)", RFC 5622, 2231 DOI 10.17487/RFC5622, August 2009, 2232 . 2234 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2235 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2236 . 2238 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 2239 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 2240 . 2242 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 2243 "NACK-Oriented Reliable Multicast (NORM) Transport 2244 Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, 2245 . 2247 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 2248 Mail Extensions (S/MIME) Version 3.2 Message 2249 Specification", RFC 5751, DOI 10.17487/RFC5751, January 2250 2010, . 2252 [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous 2253 Layered Coding (ALC) Protocol Instantiation", RFC 5775, 2254 DOI 10.17487/RFC5775, April 2010, 2255 . 2257 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 2258 Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, 2259 October 2010, . 2261 [RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 2262 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 2263 RFC 5973, DOI 10.17487/RFC5973, October 2010, 2264 . 2266 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 2267 Protocol Port Randomization", BCP 156, RFC 6056, 2268 DOI 10.17487/RFC6056, January 2011, 2269 . 2271 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 2272 Capabilities in Customer Premises Equipment (CPE) for 2273 Providing Residential IPv6 Internet Service", RFC 6092, 2274 DOI 10.17487/RFC6092, January 2011, 2275 . 2277 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2278 Cheshire, "Internet Assigned Numbers Authority (IANA) 2279 Procedures for the Management of the Service Name and 2280 Transport Protocol Port Number Registry", BCP 165, 2281 RFC 6335, DOI 10.17487/RFC6335, August 2011, 2282 . 2284 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2285 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2286 January 2012, . 2288 [RFC6396] Blunk, L., Karir, M., and C. Labovitz, "Multi-Threaded 2289 Routing Toolkit (MRT) Routing Information Export Format", 2290 RFC 6396, DOI 10.17487/RFC6396, October 2011, 2291 . 2293 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2294 "IPv6 Flow Label Specification", RFC 6437, 2295 DOI 10.17487/RFC6437, November 2011, 2296 . 2298 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 2299 for Equal Cost Multipath Routing and Link Aggregation in 2300 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 2301 . 2303 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 2304 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2305 2012, . 2307 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 2308 and K. Carlberg, "Explicit Congestion Notification (ECN) 2309 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2310 2012, . 2312 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 2313 "FLUTE - File Delivery over Unidirectional Transport", 2314 RFC 6726, DOI 10.17487/RFC6726, November 2012, 2315 . 2317 [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A 2318 Datagram Congestion Control Protocol UDP Encapsulation for 2319 NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 2320 2012, . 2322 [RFC6807] Farinacci, D., Shepherd, G., Venaas, S., and Y. Cai, 2323 "Population Count Extensions to Protocol Independent 2324 Multicast (PIM)", RFC 6807, DOI 10.17487/RFC6807, December 2325 2012, . 2327 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 2328 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 2329 DOI 10.17487/RFC6887, April 2013, 2330 . 2332 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 2333 UDP Checksums for Tunneled Packets", RFC 6935, 2334 DOI 10.17487/RFC6935, April 2013, 2335 . 2337 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 2338 for the Use of IPv6 UDP Datagrams with Zero Checksums", 2339 RFC 6936, DOI 10.17487/RFC6936, April 2013, 2340 . 2342 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 2343 Control Transmission Protocol (SCTP) Packets for End-Host 2344 to End-Host Communication", RFC 6951, 2345 DOI 10.17487/RFC6951, May 2013, 2346 . 2348 [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, 2349 "Internet Small Computer System Interface (iSCSI) Protocol 2350 (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April 2351 2014, . 2353 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 2354 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 2355 . 2357 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2358 Kivinen, "Internet Key Exchange Protocol Version 2 2359 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2360 2014, . 2362 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 2363 DOI 10.17487/RFC7450, February 2015, 2364 . 2366 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 2367 "Encapsulating MPLS in UDP", RFC 7510, 2368 DOI 10.17487/RFC7510, April 2015, 2369 . 2371 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2372 "Recommendations for Secure Use of Transport Layer 2373 Security (TLS) and Datagram Transport Layer Security 2374 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2375 2015, . 2377 [RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, 2378 "Problem Statement and Requirements for Increased Accuracy 2379 in Explicit Congestion Notification (ECN) Feedback", 2380 RFC 7560, DOI 10.17487/RFC7560, August 2015, 2381 . 2383 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 2384 Recommendations Regarding Active Queue Management", 2385 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 2386 . 2388 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 2389 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 2390 August 2015, . 2392 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 2393 (Diffserv) and Real-Time Communication", RFC 7657, 2394 DOI 10.17487/RFC7657, November 2015, 2395 . 2397 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 2398 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 2399 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 2400 October 2015, . 2402 [STEVENS] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network 2403 Programming, The sockets Networking API", Addison-Wesley, 2404 2004. 2406 [UPnP] UPnP Forum, , "Internet Gateway Device (IGD) Standardized 2407 Device Control Protocol V 1.0", November 2001. 2409 Appendix A. Case Study of the Use of IPv6 UDP Zero-Checksum Mode 2411 This appendix provides a brief review of MPLS-in-UDP as an example of 2412 a UDP Tunnel Encapsulation that defines a UDP encapsulation. The 2413 purpose of the appendix is to provide a concrete example of which 2414 mechanisms were required in order to safely use UDP zero-checksum 2415 mode for MPLS-in-UDP tunnels over IPv6. 2417 By default, UDP requires a checksum for use with IPv6. An option has 2418 been specified that permits a zero IPv6 UDP checksum when used in 2419 specific environments, specified in [RFC7510], and defines a set of 2420 operational constraints for use of this mode. These are summarized 2421 below: 2423 A UDP tunnel or encapsulation using a zero-checksum mode with IPv6 2424 must only be deployed within a single network (with a single network 2425 operator) or networks of an adjacent set of co-operating network 2426 operators where traffic is managed to avoid congestion, rather than 2427 over the Internet where congestion control is required. MPLS-in-UDP 2428 has been specified for networks under single administrative control 2429 (such as within a single operator's network) where it is known 2430 (perhaps through knowledge of equipment types and lower layer checks) 2431 that packet corruption is exceptionally unlikely and where the 2432 operator is willing to take the risk of undetected packet corruption. 2434 The tunnel encapsulator SHOULD use different IPv6 addresses for each 2435 UDP tunnel that uses the UDP zero-checksum mode, regardless of the 2436 decapsulator, to strengthen the decapsulator's check of the IPv6 2437 source address (i.e., the same IPv6 source address SHOULD NOT be used 2438 with more than one IPv6 destination address, independent of whether 2439 that destination address is a unicast or multicast address). Use of 2440 MPLS-in-UDP may be extended to networks within a set of closely 2441 cooperating network administrations (such as network operators who 2442 have agreed to work together to jointly provide specific services) 2443 [RFC7510]. 2445 The requirement for MPLS-in-UDP endpoints to check the source IPv6 2446 address in addition to the destination IPv6 address, plus the strong 2447 recommendation against reuse of source IPv6 addresses among MPLS-in- 2448 UDP tunnels collectively provide some mitigation for the absence of 2449 UDP checksum coverage of the IPv6 header. In addition, the MPLS data 2450 plane only forwards packets with valid labels (i.e., labels that have 2451 been distributed by the tunnel egress Label Switched Router, LSR), 2452 providing some additional opportunity to detect MPLS-in-UDP packet 2453 misdelivery when the misdelivered packet contains a label that is not 2454 valid for forwarding at the receiving LSR. The expected result for 2455 IPv6 UDP zero-checksum mode for MPLS-in-UDP is that corruption of the 2456 destination IPv6 address will usually cause packet discard, as 2457 offsetting corruptions to the source IPv6 and/or MPLS top label are 2458 unlikely. 2460 Additional assurance is provided by the restrictions in the above 2461 exceptions that limit usage of IPv6 UDP zero-checksum mode to well- 2462 managed networks for which MPLS packet corruption has not been a 2463 problem in practice. Hence, MPLS-in-UDP is suitable for transmission 2464 over lower layers in well-managed networks that are allowed by the 2465 exceptions stated above and the rate of corruption of the inner IP 2466 packet on such networks is not expected to increase by comparison to 2467 MPLS traffic that is not encapsulated in UDP. For these reasons, 2468 MPLS-in-UDP does not provide an additional integrity check when UDP 2469 zero-checksum mode is used with IPv6, and this design is in 2470 accordance with requirements 2, 3 and 5 specified in Section 5 of 2471 [RFC6936]. 2473 The MPLS-in-UDP encapsulation does not provide a mechanism to safely 2474 fall back to using a checksum when a path change occurs that 2475 redirects a tunnel over a path that includes a middlebox that 2476 discards IPv6 datagrams with a zero UDP checksum. In this case, the 2477 MPLS-in-UDP tunnel will be black-holed by that middlebox. 2478 Recommended changes to allow firewalls, NATs and other middleboxes to 2479 support use of an IPv6 zero UDP checksum are described in Section 5 2480 of [RFC6936]. MPLS does not accumulate incorrect state as a 2481 consequence of label stack corruption. A corrupt MPLS label results 2482 in either packet discard or forwarding (and forgetting) of the packet 2483 without accumulation of MPLS protocol state. Active monitoring of 2484 MPLS-in-UDP traffic for errors is REQUIRED because the occurrence of 2485 errors will result in some accumulation of error information outside 2486 the MPLS protocol for operational and management purposes. This 2487 design is in accordance with requirement 4 specified in Section 5 of 2488 [RFC6936]. In addition, IPv6 traffic with a zero UDP checksum MUST 2489 be actively monitored for errors by the network operator. 2491 Operators SHOULD also deploy packet filters to prevent IPv6 packets 2492 with a zero UDP checksum from escaping from the network due to 2493 misconfiguration or packet errors. In addition, IPv6 traffic with a 2494 zero UDP checksum MUST be actively monitored for errors by the 2495 network operator. 2497 Appendix B. Revision Notes 2499 Note to RFC-Editor: please remove this entire section prior to 2500 publication. 2502 Changes in draft-ietf-tsvwg-rfc5405bis-19: 2504 o Addressed IESG review comments. 2506 Changes in draft-ietf-tsvwg-rfc5405bis-18: 2508 o Fix a nit. 2510 Changes in draft-ietf-tsvwg-rfc5405bis-17: 2512 o Incorporated text from Mark Allman for the section on "Protocol 2513 Timer Guidelines". 2515 Changes in draft-ietf-tsvwg-rfc5405bis-16: 2517 o Addressed suggestions by David Black. 2519 Changes in draft-ietf-tsvwg-rfc5405bis-15: 2521 o Addressed more suggestions by Takeshi Takahashi. 2523 Changes in draft-ietf-tsvwg-rfc5405bis-14: 2525 o Addressed SEC_DIR review by Takeshi Takahashi. 2527 o Addressed Gen-ART review by Paul Kyzivat. 2529 o Addressed OPS-DIR review by Tim Chown. 2531 o Addressed some of Mark Allman's comments regarding RTTs and RTOs. 2533 o Addressed some of Brian Trammell;s comments regarding new IETF 2534 transports. 2536 Changes in draft-ietf-tsvwg-rfc5405bis-13: 2538 o Minor corrections. 2540 o Changes recommended by Spencer Dawkins. 2542 o Placed the recommendations on timers within section 3.1 2544 o Updated the recommendations on reliability to also reference the 2545 recommendations on timers. 2547 Changes in draft-ietf-tsvwg-rfc5405bis-12: 2549 o Introduced a separate section on the usage of timers to avoid 2550 repeating similar guidance in multiple sections. 2552 o Updated RTT measurement text to align with revised min RTO 2553 recommendation for TCP. 2555 o Updated text based on draft-ietf-tcpm-rto-consider-03 and to now 2556 cite this draft. 2558 o Fixed inconsistency in term used for keep-alive messages (keep- 2559 alive packet, keep-alives). 2561 Changes in draft-ietf-tsvwg-rfc5405bis-11: 2563 o Address some issues that idnits found. 2565 Changes in draft-ietf-tsvwg-rfc5405bis-10: 2567 o Restored changes from -08 that -09 accidentally rolled back. 2569 Changes in draft-ietf-tsvwg-rfc5405bis-09: 2571 o Fix to cross reference in summary table. 2573 Changes in draft-ietf-tsvwg-rfc5405bis-08: 2575 This update introduces new text in the following sections: 2577 o The ID from RTGWG on encap Section 7 makes recommendations on 2578 entropy. Section 5.1 of the 5405bis draft had a single sentence 2579 on use of the UDP source port to inject entropy. Related work 2580 such as UDP-in-MPLS and GRE-in-UDP have also made recommendations 2581 on entropy usage. A new section has been added to address this. 2583 o Added reference to RFC2983 on DSCP with tunnels. 2585 o New text after comment from David Black on needing to improve the 2586 header protection text. 2588 o Replaced replace /controlled network environment/ with /controlled 2589 environment/ to be more consistent with other drafts. 2591 o Section 3.1.7 now explicitly refers to the applicability 2592 subsection describing controlled environments. 2594 o PLPMTUD section updated. 2596 o Reworded checksum text to place IPv6 UDP zero checksum text in a 2597 separate subsection (this became too long in the main section) 2599 o Updated summary table 2601 Changes in draft-ietf-tsvwg-rfc5405bis-07: 2603 This update introduces new text in the following sections: 2605 o Addressed David Black's review during WG LC. 2607 Changes in draft-ietf-tsvwg-rfc5405bis-06: 2609 This update introduces new text in the following sections: 2611 o Multicast Congestion Control Guidelines (Section rewritten by Greg 2612 and Gorry to differentiate sender-driven and receiver-driven CC) 2614 o Using UDP Ports (Added a short para on RPF checks protecting from 2615 off-path attacks) 2617 o Applications using Multiple UDP Ports (Added text on layered 2618 multicast) 2620 Changes in draft-ietf-tsvwg-rfc5405bis-05: 2622 o Amended text in section discussing RTT for CC (feedback from 2623 Colin) 2625 Changes in draft-ietf-tsvwg-rfc5405bis-04: 2627 o Added text on consent freshness (STUN) - (From Colin) 2629 o Reworked text on ECN (From David) 2631 o Reworked text on RTT with CC (with help from Mirja) 2633 o Added references to [RFC7675], [I-D.ietf-rtgwg-dt-encap], 2634 [I-D.ietf-intarea-tunnels] and [RFC7510] 2636 Changes in draft-ietf-tsvwg-rfc5405bis-03: 2638 o Mention crypto hash in addition to CRC for integrity protection. 2639 (From Magnus.) 2641 o Mention PCP. (From Magnus.) 2643 o More accurate text on secure RTP (From Magnus.) 2645 o Reordered abstract to reflect .bis focus (Gorry) 2647 o Added a section on ECN, with actual ECN requirements (Gorry, help 2648 from Mirja) 2650 o Added section on Implications of RTT on Congestion Control (Gorry) 2651 o Added note that this refers to other protocols over IP (E 2652 Nordmark, rtg encaps guidance) 2654 o Added reordering text between sessions (consistent with use of 2655 ECMP, rtg encaps guidance) 2657 o Reworked text on off-path data protection (port usage) 2659 o Updated summary table 2661 Changes in draft-ietf-tsvwg-rfc5405bis-02: 2663 o Added note that guidance may be applicable beyond UDP to abstract 2664 (from Erik Nordmark). 2666 o Small editorial changes to fix English nits. 2668 o Added a circuit may provide benefit to CC tunnels by controlling 2669 envelope. 2671 o Added tunnels should ingress-filter by packet type (from Erik 2672 Nordmark). 2674 o Added tunnels should perform IETF ECN processing when supporting 2675 ECN. 2677 o Multicast apps may employ CC or a circuit breaker. 2679 o Added programming guidance on off-path attacks (with C. Perkins). 2681 o Added reference to ECN benefits. 2683 Changes in draft-ietf-tsvwg-rfc5405bis-01: 2685 o Added text on DSCP-usage. 2687 o More guidance on use of the checksum, including an example of how 2688 MPLS/UDP allowed support of a zero IPv6 UDP Checksum in some 2689 cases. 2691 o Added description of diffuse usage. 2693 o Clarified usage of the source port field. 2695 draft-eggert-tsvwg-rfc5405bis-01 was adopted by the TSVWG and 2696 resubmitted as draft-ietf-tsvwg-rfc5405bis-00. There were no 2697 technical changes. 2699 Changes in draft-eggert-tsvwg-rfc5405bis-01: 2701 o Added Greg Shepherd as a co-author, based on the multicast 2702 guidelines that originated with him. 2704 Changes in draft-eggert-tsvwg-rfc5405bis-00 (relative to RFC5405): 2706 o The words "application designers" were removed from the draft 2707 title and the wording of the abstract was clarified abstract. 2709 o New text to clarify various issues and set new recommendations not 2710 previously included in RFC 5405. These include new 2711 recommendations for multicast, the use of checksums with IPv6, 2712 ECMP, recommendations on port usage, use of ECN, use of DiffServ, 2713 circuit breakers (initial text), etc. 2715 Authors' Addresses 2717 Lars Eggert 2718 NetApp 2719 Sonnenallee 1 2720 Kirchheim 85551 2721 Germany 2723 Phone: +49 151 120 55791 2724 EMail: lars@netapp.com 2725 URI: https://eggert.org/ 2727 Godred Fairhurst 2728 University of Aberdeen 2729 Department of Engineering 2730 Fraser Noble Building 2731 Aberdeen AB24 3UE 2732 Scotland 2734 EMail: gorry@erg.abdn.ac.uk 2735 URI: http://www.erg.abdn.ac.uk/ 2737 Greg Shepherd 2738 Cisco Systems 2739 Tasman Drive 2740 San Jose 2741 USA 2743 EMail: gjshep@gmail.com