diff options
Diffstat (limited to 'doc/rfc/rfc8085.txt')
| -rw-r--r-- | doc/rfc/rfc8085.txt | 3083 |
1 files changed, 3083 insertions, 0 deletions
diff --git a/doc/rfc/rfc8085.txt b/doc/rfc/rfc8085.txt new file mode 100644 index 0000000..23a2d32 --- /dev/null +++ b/doc/rfc/rfc8085.txt @@ -0,0 +1,3083 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Eggert +Request for Comments: 8085 NetApp +BCP: 145 G. Fairhurst +Obsoletes: 5405 University of Aberdeen +Category: Best Current Practice G. Shepherd +ISSN: 2070-1721 Cisco Systems + March 2017 + + + UDP Usage Guidelines + +Abstract + + The User Datagram Protocol (UDP) provides a minimal message-passing + transport that has no inherent congestion control mechanisms. This + document provides guidelines on the use of UDP for the designers of + applications, tunnels, and other protocols that use UDP. Congestion + control guidelines are a primary focus, but the document also + provides guidance on other topics, including message sizes, + reliability, checksums, middlebox traversal, the use of Explicit + Congestion Notification (ECN), Differentiated Services Code Points + (DSCPs), and ports. + + Because congestion control is critical to the stable operation of the + Internet, applications and other protocols that choose to use UDP as + an Internet transport must employ mechanisms to prevent congestion + collapse and to establish some degree of fairness with concurrent + traffic. They may also need to implement additional mechanisms, + depending on how they use UDP. + + Some guidance is also applicable to the design of other protocols + (e.g., protocols layered directly on IP or via IP-based tunnels), + especially when these protocols do not themselves provide congestion + control. + + This document obsoletes RFC 5405 and adds guidelines for multicast + UDP usage. + + + + + + + + + + + + + + +Eggert, et al. Best Current Practice [Page 1] + +RFC 8085 UDP Usage Guidelines March 2017 + + +Status of This Memo + + This memo documents an Internet Best Current Practice. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + BCPs is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8085. + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + +Eggert, et al. Best Current Practice [Page 2] + +RFC 8085 UDP Usage Guidelines March 2017 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................5 + 3. UDP Usage Guidelines ............................................5 + 3.1. Congestion Control Guidelines ..............................6 + 3.2. Message Size Guidelines ...................................19 + 3.3. Reliability Guidelines ....................................21 + 3.4. Checksum Guidelines .......................................22 + 3.5. Middlebox Traversal Guidelines ............................25 + 3.6. Limited Applicability and Controlled Environments .........27 + 4. Multicast UDP Usage Guidelines .................................28 + 4.1. Multicast Congestion Control Guidelines ...................30 + 4.2. Message Size Guidelines for Multicast .....................32 + 5. Programming Guidelines .........................................32 + 5.1. Using UDP Ports ...........................................34 + 5.2. ICMP Guidelines ...........................................37 + 6. Security Considerations ........................................38 + 7. Summary ........................................................40 + 8. References .....................................................42 + 8.1. Normative References ......................................42 + 8.2. Informative References ....................................43 + Appendix A. .......................................................53 + Acknowledgments ...................................................55 + Authors' Addresses ................................................55 + +1. Introduction + + The User Datagram Protocol (UDP) [RFC768] provides a minimal, + unreliable, best-effort, message-passing transport to applications + and other protocols (such as tunnels) that wish to operate over IP. + Both are simply called "applications" in the remainder of this + document. + + Compared to other transport protocols, UDP and its UDP-Lite variant + [RFC3828] are unique in that they do not establish end-to-end + connections between communicating end systems. UDP communication + consequently does not incur connection establishment and teardown + overheads, and there is minimal associated end-system state. Because + of these characteristics, UDP can offer a very efficient + communication transport to some applications. + + A second unique characteristic of UDP is that it provides no inherent + congestion control mechanisms. On many platforms, applications can + send UDP datagrams at the line rate of the platform's link interface, + which is often much greater than the available end-to-end path + capacity, and doing so contributes to congestion along the path. + [RFC2914] describes the best current practice for congestion control + + + +Eggert, et al. Best Current Practice [Page 3] + +RFC 8085 UDP Usage Guidelines March 2017 + + + in the Internet. It identifies two major reasons why congestion + control mechanisms are critical for the stable operation of the + Internet: + + 1. The prevention of congestion collapse, i.e., a state where an + increase in network load results in a decrease in useful work + done by the network. + + 2. The establishment of a degree of fairness, i.e., allowing + multiple flows to share the capacity of a path reasonably + equitably. + + Because UDP itself provides no congestion control mechanisms, it is + up to the applications that use UDP for Internet communication to + employ suitable mechanisms to prevent congestion collapse and + establish a degree of fairness. [RFC2309] discusses the dangers of + congestion-unresponsive flows and states that "all UDP-based + streaming applications should incorporate effective congestion + avoidance mechanisms." [RFC7567] reaffirms this statement. This is + an important requirement, even for applications that do not use UDP + for streaming. In addition, congestion-controlled transmission is of + benefit to an application itself, because it can reduce self-induced + packet loss, minimize retransmissions, and hence reduce delays. + Congestion control is essential even at relatively slow transmission + rates. For example, an application that generates five 1500-byte UDP + datagrams in one second can already exceed the capacity of a 56 Kb/s + path. For applications that can operate at higher, potentially + unbounded data rates, congestion control becomes vital to prevent + congestion collapse and establish some degree of fairness. Section 3 + describes a number of simple guidelines for the designers of such + applications. + + A UDP datagram is carried in a single IP packet and is hence limited + to a maximum payload of 65,507 bytes for IPv4 and 65,527 bytes for + IPv6. The transmission of large IP packets usually requires IP + fragmentation. Fragmentation decreases communication reliability and + efficiency and should be avoided. IPv6 allows the option of + transmitting large packets ("jumbograms") without fragmentation when + all link layers along the path support this [RFC2675]. Some of the + guidelines in Section 3 describe how applications should determine + appropriate message sizes. Other sections of this document provide + guidance on reliability, checksums, middlebox traversal and use of + multicast. + + This document provides guidelines and recommendations. Although most + UDP applications are expected to follow these guidelines, there do + exist valid reasons why a specific application may decide not to + follow a given guideline. In such cases, it is RECOMMENDED that + + + +Eggert, et al. Best Current Practice [Page 4] + +RFC 8085 UDP Usage Guidelines March 2017 + + + application designers cite the respective section(s) of this document + in the technical specification of their application or protocol and + explain their rationale for their design choice. + + [RFC5405] was scoped to provide guidelines for unicast applications + only, whereas this document also provides guidelines for UDP flows + that use IP anycast, multicast, broadcast, and applications that use + UDP tunnels to support IP flows. + + Finally, although this document specifically refers to usage of UDP, + the spirit of some of its guidelines also applies to other message- + passing applications and protocols (specifically on the topics of + congestion control, message sizes, and reliability). Examples + include signaling, tunnel or control applications that choose to run + directly over IP by registering their own IP protocol number with + IANA. This document is expected to provide useful background reading + to the designers of such applications and protocols. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +3. UDP Usage Guidelines + + Internet paths can have widely varying characteristics, including + transmission delays, available bandwidths, congestion levels, + reordering probabilities, supported message sizes, or loss rates. + Furthermore, the same Internet path can have very different + conditions over time. Consequently, applications that may be used on + the Internet MUST NOT make assumptions about specific path + characteristics. They MUST instead use mechanisms that let them + operate safely under very different path conditions. Typically, this + requires conservatively probing the current conditions of the + Internet path they communicate over to establish a transmission + behavior that it can sustain and that is reasonably fair to other + traffic sharing the path. + + These mechanisms are difficult to implement correctly. For most + applications, the use of one of the existing IETF transport protocols + is the simplest method of acquiring the required mechanisms. Doing + so also avoids issues that protocols using a new IP protocol number + face when being deployed over the Internet, where middleboxes that + only support TCP and UDP are sometimes present. Consequently, the + RECOMMENDED alternative to the UDP usage described in the remainder + of this section is the use of an IETF transport protocol such as TCP + + + +Eggert, et al. Best Current Practice [Page 5] + +RFC 8085 UDP Usage Guidelines March 2017 + + + [RFC793], Stream Control Transmission Protocol (SCTP) [RFC4960], and + SCTP Partial Reliability Extension (SCTP-PR) [RFC3758], or Datagram + Congestion Control Protocol (DCCP) [RFC4340] with its different + congestion control types [RFC4341][RFC4342][RFC5622], or transport + protocols specified by the IETF in the future. (UDP-encapsulated + SCTP [RFC6951] and DCCP [RFC6773] can offer support for traversing + firewalls and other middleboxes where the native protocols are not + supported.) + + If used correctly, these more fully featured transport protocols are + not as "heavyweight" as often claimed. For example, the TCP + algorithms have been continuously improved over decades, and they + have reached a level of efficiency and correctness that custom + application-layer mechanisms will struggle to easily duplicate. In + addition, many TCP implementations allow connections to be tuned by + an application to its purposes. For example, TCP's "Nagle" algorithm + [RFC1122] can be disabled, improving communication latency at the + expense of more frequent -- but still congestion controlled -- packet + transmissions. Another example is the TCP SYN cookie mechanism + [RFC4987], which is available on many platforms. TCP with SYN + cookies does not require a server to maintain per-connection state + until the connection is established. TCP also requires the end that + closes a connection to maintain the TIME-WAIT state that prevents + delayed segments from one connection instance from interfering with a + later one. Applications that are aware of and designed for this + behavior can shift maintenance of the TIME-WAIT state to conserve + resources by controlling which end closes a TCP connection [FABER]. + Finally, TCP's built-in capacity-probing and awareness of the maximum + transmission unit supported by the path (PMTU) results in efficient + data transmission that quickly compensates for the initial connection + setup delay, in the case of transfers that exchange more than a few + segments. + +3.1. Congestion Control Guidelines + + If an application or protocol chooses not to use a congestion- + controlled transport protocol, it SHOULD control the rate at which it + sends UDP datagrams to a destination host, in order to fulfill the + requirements of [RFC2914]. It is important to stress that an + application SHOULD perform congestion control over all UDP traffic it + sends to a destination, independently from how it generates this + traffic. For example, an application that forks multiple worker + processes or otherwise uses multiple sockets to generate UDP + datagrams SHOULD perform congestion control over the aggregate + traffic. + + + + + + +Eggert, et al. Best Current Practice [Page 6] + +RFC 8085 UDP Usage Guidelines March 2017 + + + Several approaches to perform congestion control are discussed in the + remainder of this section. This section describes generic topics + with an intended emphasis on unicast and anycast [RFC1546] usage. + Not all approaches discussed below are appropriate for all UDP- + transmitting applications. Section 3.1.2 discusses congestion + control options for applications that perform bulk transfers over + UDP. Such applications can employ schemes that sample the path over + several subsequent round-trips during which data is exchanged to + determine a sending rate that the path at its current load can + support. Other applications only exchange a few UDP datagrams with a + destination. Section 3.1.3 discusses congestion control options for + such "low data-volume" applications. Because they typically do not + transmit enough data to iteratively sample the path to determine a + safe sending rate, they need to employ different kinds of congestion + control mechanisms. Section 3.1.11 discusses congestion control + considerations when UDP is used as a tunneling protocol. Section 4 + provides additional recommendations for broadcast and multicast + usage. + + It is important to note that congestion control should not be viewed + as an add-on to a finished application. Many of the mechanisms + discussed in the guidelines below require application support to + operate correctly. Application designers need to consider congestion + control throughout the design of their application, similar to how + they consider security aspects throughout the design process. + + In the past, the IETF has also investigated integrated congestion + control mechanisms that act on the traffic aggregate between two + hosts, i.e., a framework such as the Congestion Manager [RFC3124], + where active sessions may share current congestion information in a + way that is independent of the transport protocol. Such mechanisms + have currently failed to see deployment, but would otherwise simplify + the design of congestion control mechanisms for UDP sessions, so that + they fulfill the requirements in [RFC2914]. + +3.1.1. Protocol Timer Guidelines + + Understanding the latency between communicating endpoints is usually + a crucial part of effective congestion control implementations for + protocols and applications. Latency estimation can be used in a + number of protocol functions, such as calculating a congestion- + controlled transmission rate, triggering retransmission, and + detecting packet loss. Additional protocol functions, for example, + determining an interval for probing a path, determining an interval + between keep-alive messages, determining an interval for measuring + the quality of experience, or determining if a remote endpoint has + + + + + +Eggert, et al. Best Current Practice [Page 7] + +RFC 8085 UDP Usage Guidelines March 2017 + + + responded to a request to perform an action, typically operate over + longer timescales than congestion control and therefore are not + covered in this section. + + The general recommendation in this document is that applications + SHOULD leverage existing congestion control techniques and the + latency estimators specified therein (see next subsection). The + following guidelines are provided for applications that need to + design their own latency estimation mechanisms. + + The guidelines are framed in terms of "latency" and not "round-trip + time" because some situations require characterizing only the + network-based latency (e.g., TCP-Friendly Rate Control (TFRC) + [RFC5348]), while other cases necessitate inclusion of the time + required by the remote endpoint to provide feedback (e.g., developing + an understanding of when to retransmit a message). + + The latency between endpoints is generally a dynamic property. + Therefore, estimates SHOULD represent some sort of averaging of + multiple recent measurement samples to account for variance. + Leveraging an Exponentially Weighted Moving Average (EWMA) has proven + useful for this purpose (e.g., in TCP [RFC6298] and TFRC [RFC5348]). + + Independent latency estimates SHOULD be maintained for each + destination with which an endpoint communicates. + + Latency samples MUST NOT be derived from ambiguous transactions. The + canonical example is in a protocol that retransmits data, but + subsequently cannot determine which copy is being acknowledged. This + ambiguity makes correct computation of the latency problematic. See + the discussion of Karn's algorithm in [RFC6298]. This requirement + ensures a sender establishes a sound estimate of the latency without + relying on misleading measurements. + + When a latency estimate is used to arm a timer that provides loss + detection -- with or without retransmission -- expiry of the timer + MUST be interpreted as an indication of congestion in the network, + causing the sending rate to be adapted to a safe conservative rate + (e.g., TCP collapses the congestion window to one segment [RFC5681]). + + Some applications require an initial latency estimate before the + latency between endpoints can be empirically sampled. For instance, + when arming a retransmission timer, an initial value is needed to + protect the messages sent before the endpoints sample the latency. + This initial latency estimate SHOULD generally be as conservative + (large) as possible for the given application. For instance, in the + absence of any knowledge about the latency of a path, TCP requires + the initial Retransmission Timeout (RTO) to be set to no less than 1 + + + +Eggert, et al. Best Current Practice [Page 8] + +RFC 8085 UDP Usage Guidelines March 2017 + + + second [RFC6298]. UDP applications SHOULD similarly use an initial + latency estimate of 1 second. Values shorter than 1 second can be + problematic (see the data analysis in the appendix of [RFC6298]). + +3.1.2. Bulk-Transfer Applications + + Applications that perform bulk transmission of data to a peer over + UDP, i.e., applications that exchange more than a few UDP datagrams + per RTT, SHOULD implement TFRC [RFC5348], window-based TCP-like + congestion control, or otherwise ensure that the application complies + with the congestion control principles. + + TFRC has been designed to provide both congestion control and + fairness in a way that is compatible with the IETF's other transport + protocols. If an application implements TFRC, it need not follow the + remaining guidelines in Section 3.1.2, because TFRC already addresses + them, but it SHOULD still follow the remaining guidelines in the + subsequent subsections of Section 3. + + Bulk-transfer applications that choose not to implement TFRC or TCP- + like windowing SHOULD implement a congestion control scheme that + results in bandwidth (capacity) use that competes fairly with TCP + within an order of magnitude. + + Section 2 of [RFC3551] suggests that applications SHOULD monitor the + packet-loss rate to ensure that it is within acceptable parameters. + Packet loss is considered acceptable if a TCP flow across the same + network path under the same network conditions would achieve an + average throughput, measured on a reasonable timescale, that is not + less than that of the UDP flow. The comparison to TCP cannot be + specified exactly, but is intended as an "order-of-magnitude" + comparison in timescale and throughput. The recommendations for + managing timers specified in Section 3.1.1 also apply. + + Finally, some bulk-transfer applications may choose not to implement + any congestion control mechanism and instead rely on transmitting + across reserved path capacity (see Section 3.1.9). This might be an + acceptable choice for a subset of restricted networking environments, + but is by no means a safe practice for operation over the wider + Internet. When the UDP traffic of such applications leaks out into + unprovisioned Internet paths, it can significantly degrade the + performance of other traffic sharing the path and even result in + congestion collapse. Applications that support an uncontrolled or + unadaptive transmission behavior SHOULD NOT do so by default and + SHOULD instead require users to explicitly enable this mode of + operation, and they SHOULD verify that sufficient path capacity has + been reserved for them. + + + + +Eggert, et al. Best Current Practice [Page 9] + +RFC 8085 UDP Usage Guidelines March 2017 + + +3.1.3. Low Data-Volume Applications + + When applications that at any time exchange only a few UDP datagrams + with a destination implement TFRC or one of the other congestion + control schemes in Section 3.1.2, the network sees little benefit, + because those mechanisms perform congestion control in a way that is + only effective for longer transmissions. + + Applications that at any time exchange only a few UDP datagrams with + a destination SHOULD still control their transmission behavior by not + sending on average more than one UDP datagram per RTT to a + destination. Similar to the recommendation in [RFC1536], an + application SHOULD maintain an estimate of the RTT for any + destination with which it communicates using the methods specified in + Section 3.1.1. + + Some applications cannot maintain a reliable RTT estimate for a + destination. These applications do not need to or are unable to use + protocol timers to measure the RTT (Section 3.1.1). Two cases can be + identified: + + 1. The first case is that of applications that exchange too few UDP + datagrams with a peer to establish a statistically accurate RTT + estimate but that can monitor the reliability of transmission + (Section 3.3). Such applications MAY use a predetermined + transmission interval that is exponentially backed off when + packets are deemed lost. TCP specifies an initial value of 1 + second [RFC6298], which is also RECOMMENDED as an initial value + for UDP applications. Some low data-volume applications, e.g., + SIP [RFC3261] and General Internet Signaling Transport (GIST) + [RFC5971] use an interval of 500 ms, and shorter values are + likely problematic in many cases. As in the previous case, note + that the initial timeout is not the maximum possible timeout, see + Section 3.1.1. + + 2. A second case of applications cannot maintain an RTT estimate for + a destination, because the destination does not send return + traffic. Such applications SHOULD NOT send more than one UDP + datagram every 3 seconds and SHOULD use an even less aggressive + rate when possible. Shorter values are likely problematic in + many cases. Note that the sending rate in this case must be more + conservative than in the previous cases, because the lack of + return traffic prevents the detection of packet loss, i.e., + congestion, and the application therefore cannot perform + exponential back off to reduce load. + + + + + + +Eggert, et al. Best Current Practice [Page 10] + +RFC 8085 UDP Usage Guidelines March 2017 + + +3.1.4. Applications Supporting Bidirectional Communications + + Applications that communicate bidirectionally SHOULD employ + congestion control for both directions of the communication. For + example, for a client-server, request-response-style application, + clients SHOULD congestion-control their request transmission to a + server, and the server SHOULD congestion-control its responses to the + clients. Congestion in the forward and reverse directions is + uncorrelated, and an application SHOULD either independently detect + and respond to congestion along both directions or limit new and + retransmitted requests based on acknowledged responses across the + entire round-trip path. + +3.1.5. Implications of RTT and Loss Measurements on Congestion Control + + Transports such as TCP, SCTP, and DCCP provide timely detection of + congestion that results in an immediate reduction of their maximum + sending rate when congestion is experienced. This reaction is + typically completed 1-2 RTTs after loss/congestion is encountered. + Applications using UDP SHOULD implement a congestion control scheme + that provides a prompt reaction to signals indicating congestion + (e.g., by reducing the rate within the next RTT following a + congestion signal). + + The operation of a UDP congestion control algorithm can be very + different from the way TCP operates. This includes congestion + controls that respond on timescales that fit applications that cannot + usefully work within the "change rate every RTT" model of TCP. + Applications that experience a low or varying RTT are particularly + vulnerable to sampling errors (e.g., due to measurement noise or + timer accuracy). This suggests the need to average loss/congestion + and RTT measurements over a longer interval; however, this also can + contribute additional delay in detecting congestion. Some + applications may not react by reducing their sending rate immediately + for various reasons, including the following: RTT and loss + measurements are only made periodically (e.g., using RTCP), + additional time is required to filter information, or the application + is only able to change its sending rate at predetermined interval + (e.g., some video codecs). + + When designing a congestion control algorithm, the designer therefore + needs to consider the total time taken to reduce the load following a + lack of feedback or a congestion event. An application where the + most recent RTT measurement is smaller than the actual RTT or the + measured loss rate is smaller than the current rate, can result in + over estimating the available capacity. Such over-estimation can + + + + + +Eggert, et al. Best Current Practice [Page 11] + +RFC 8085 UDP Usage Guidelines March 2017 + + + result in a sending rate that creates congestion to the application + or other flows sharing the path capacity, and can contribute to + congestion collapse -- both of these need to be avoided. + + A congestion control designed for UDP SHOULD respond as quickly as + possible when it experiences congestion, and it SHOULD take into + account both the loss rate and the response time when choosing a new + rate. The implemented congestion control scheme SHOULD result in + bandwidth (capacity) use that is comparable to that of TCP within an + order of magnitude, so that it does not starve other flows sharing a + common bottleneck. + +3.1.6. Burst Mitigation and Pacing + + UDP applications SHOULD provide mechanisms to regulate the bursts of + transmission that the application may send to the network. Many TCP + and SCTP implementations provide mechanisms that prevent a sender + from generating long bursts at line-rate, since these are known to + induce early loss to applications sharing a common network + bottleneck. The use of pacing with TCP [ALLMAN] has also been shown + to improve the coexistence of TCP flows with other flows. The need + to avoid excessive transmission bursts is also noted in + specifications for applications (e.g., [RFC7143]). + + Even low data-volume UDP flows may benefit from packet pacing, e.g., + an application that sends three copies of a packet to improve + robustness to loss is RECOMMENDED to pace out those three packets + over several RTTs, to reduce the probability that all three packets + will be lost due to the same congestion event (or other event, such + as burst corruption). + +3.1.7. Explicit Congestion Notification + + Internet applications can use Explicit Congestion Notification (ECN) + [RFC3168] to gain benefits for the services they support [RFC8087]. + + Internet transports, such as TCP, provide a set of mechanisms that + are needed to utilize ECN. ECN operates by setting an ECN-capable + codepoint (ECT(0) or ECT(1)) in the IP header of packets that are + sent. This indicates to ECN-capable network devices (routers and + other devices) that they may mark (set the congestion experienced, + Congestion Experience (CE) codepoint) rather than drop the IP packet + as a signal of incipient congestion. + + UDP applications can also benefit from enabling ECN, providing that + the API supports ECN and that they implement the required protocol + mechanisms to support ECN. + + + + +Eggert, et al. Best Current Practice [Page 12] + +RFC 8085 UDP Usage Guidelines March 2017 + + + The set of mechanisms required for an application to use ECN over UDP + are: + + o A sender MUST provide a method to determine (e.g., negotiate) that + the corresponding application is able to provide ECN feedback + using a compatible ECN method. + + o A receiver that enables the use of ECN for a UDP port MUST check + the ECN field at the receiver for each UDP datagram that it + receives on this port. + + o The receiving application needs to provide feedback of congestion + information to the sending application. This MUST report the + presence of datagrams received with a CE-mark by providing a + mechanism to feed this congestion information back to the sending + application. The feedback MAY also report the presence of ECT(1) + and ECT(0)/Not-ECT packets [RFC7560]. ([RFC3168] and [RFC7560] + specify methods for TCP.) + + o An application sending ECN-capable datagrams MUST provide an + appropriate congestion reaction when it receives feedback + indicating that congestion has been experienced. This ought to + result in reduction of the sending rate by the UDP congestion + control method (see Section 3.1) that is not less than the + reaction of TCP under equivalent conditions. + + o A sender SHOULD detect network paths that do not support the ECN + field correctly. When detected, they need to either + conservatively react to congestion or even fall back to not using + ECN [RFC8087]. This method needs to be robust to changes within + the network path that may occur over the lifetime of a session. + + o A sender is encouraged to provide a mechanism to detect and react + appropriately to misbehaving receivers that fail to report + CE-marked packets [RFC8087]. + + [RFC6679] provides guidance and an example of this support, by + describing a method to allow ECN to be used for UDP-based + applications using the Real-Time Protocol (RTP). Applications that + cannot provide this set of mechanisms, but wish to gain the benefits + of using ECN, are encouraged to use a transport protocol that already + supports ECN (such as TCP). + +3.1.8. Differentiated Services Model + + An application using UDP can use the differentiated services + (DiffServ) Quality of Service (QoS) framework. To enable + differentiated services processing, a UDP sender sets the + + + +Eggert, et al. Best Current Practice [Page 13] + +RFC 8085 UDP Usage Guidelines March 2017 + + + Differentiated Services Code Point (DSCP) field [RFC2475] in packets + sent to the network. Normally, a UDP source/destination port pair + will set a single DSCP value for all packets belonging to a flow, but + multiple DSCPs can be used as described later in this section. A + DSCP may be chosen from a small set of fixed values (the class + selector code points), or from a set of recommended values defined in + the Per Hop Behavior (PHB) specifications, or from values that have + purely local meanings to a specific network that supports DiffServ. + In general, packets may be forwarded across multiple networks between + source and destination. + + In setting a non-default DSCP value, an application must be aware + that DSCP markings may be changed or removed between the traffic + source and destination. This has implications on the design of + applications that use DSCPs. Specifically, applications SHOULD be + designed not to rely on implementation of a specific network + treatment; they need instead to implement congestion control methods + to determine if their current sending rate is inducing congestion in + the network. + + [RFC7657] describes the implications of using DSCPs and provides + recommendations on using multiple DSCPs within a single network five- + tuple (source and destination addresses, source and destination + ports, and the transport protocol used, in this case, UDP or + UDP-Lite), and particularly the expected impact on transport protocol + interactions, with congestion control or reliability functionality + (e.g., retransmission, reordering). Use of multiple DSCPs can result + in reordering by increasing the set of network forwarding resources + used by a sender. It can also increase exposure to resource + depletion or failure. + +3.1.9. QoS, Pre-Provisioned, or Reserved Capacity + + The IETF usually specifies protocols for use within the Best Effort + General Internet. Sometimes it is relevant to specify protocols with + a different applicability. An application using UDP can use the + integrated services QoS framework. This framework is usually made + available within controlled environments (e.g., within a single + administrative domain or bilaterally agreed connection between + domains). Applications intended for the Internet SHOULD NOT assume + that QoS mechanisms are supported by the networks they use, and + therefore need to provide congestion control, error recovery, etc., + in case the actual network path does not provide provisioned service. + + Some UDP applications are only expected to be deployed over network + paths that use pre-provisioned capacity or capacity reserved using + dynamic provisioning, e.g., through the Resource Reservation Protocol + (RSVP). Multicast applications are also used with pre-provisioned + + + +Eggert, et al. Best Current Practice [Page 14] + +RFC 8085 UDP Usage Guidelines March 2017 + + + capacity (e.g., IPTV deployments within access networks). These + applications MAY choose not to implement any congestion control + mechanism and instead rely on transmitting only on paths where the + capacity is provisioned and reserved for this use. This might be an + acceptable choice for a subset of restricted networking environments, + but is by no means a safe practice for operation over the wider + Internet. Applications that choose this option SHOULD carefully and + in detail describe the provisioning and management procedures that + result in the desired containment. + + Applications that support an uncontrolled or unadaptive transmission + behavior SHOULD NOT do so by default and SHOULD instead require users + to explicitly enable this mode of operation. + + Applications designed for use within a controlled environment (see + Section 3.6) may be able to exploit network management functions to + detect whether they are causing congestion, and react accordingly. + If the traffic of such applications leaks out into unprovisioned + Internet paths, it can significantly degrade the performance of other + traffic sharing the path and even result in congestion collapse. + Protocols designed for such networks SHOULD provide mechanisms at the + network edge to prevent leakage of traffic into unprovisioned + Internet paths (e.g., [RFC7510]). To protect other applications + sharing the same path, applications SHOULD also deploy an appropriate + circuit breaker, as described in Section 3.1.10. + + An IETF specification targeting a controlled environment is expected + to provide an applicability statement that restricts the application + to the controlled environment (see Section 3.6). + +3.1.10. Circuit Breaker Mechanisms + + A transport circuit breaker is an automatic mechanism that is used to + estimate the congestion caused by a flow, and to terminate (or + significantly reduce the rate of) the flow when excessive congestion + is detected [RFC8084]. This is a safety measure to prevent + congestion collapse (starvation of resources available to other + flows), essential for an Internet that is heterogeneous and for + traffic that is hard to predict in advance. + + A circuit breaker is intended as a protection mechanism of last + resort. Under normal circumstances, a circuit breaker should not be + triggered; it is designed to protect things when there is severe + overload. The goal is usually to limit the maximum transmission rate + that reflects the available capacity of a network path. Circuit + breakers can operate on individual UDP flows or traffic aggregates, + e.g., traffic sent using a network tunnel. + + + + +Eggert, et al. Best Current Practice [Page 15] + +RFC 8085 UDP Usage Guidelines March 2017 + + + [RFC8084] provides guidance and examples on the use of circuit + breakers. The use of a circuit breaker in RTP is specified in + [RFC8083]. + + Applications used in the general Internet SHOULD implement a + transport circuit breaker if they do not implement congestion control + or operate a low data-volume service (see Section 3.6). All + applications MAY implement a transport circuit breaker [RFC8084] and + are encouraged to consider implementing at least a slow-acting + transport circuit breaker to provide a protection of last resort for + their network traffic. + +3.1.11. UDP Tunnels + + One increasingly popular use of UDP is as a tunneling protocol + [INT-TUNNELS], where a tunnel endpoint encapsulates the packets of + another protocol inside UDP datagrams and transmits them to another + tunnel endpoint, which decapsulates the UDP datagrams and forwards + the original packets contained in the payload. One example of such a + protocol is Teredo [RFC4380]. Tunnels establish virtual links that + appear to directly connect locations that are distant in the physical + Internet topology and can be used to create virtual (private) + networks. Using UDP as a tunneling protocol is attractive when the + payload protocol is not supported by middleboxes that may exist along + the path, because many middleboxes support transmission using UDP. + + Well-implemented tunnels are generally invisible to the endpoints + that happen to transmit over a path that includes tunneled links. On + the other hand, to the routers along the path of a UDP tunnel, i.e., + the routers between the two tunnel endpoints, the traffic that a UDP + tunnel generates is a regular UDP flow, and the encapsulator and + decapsulator appear as regular UDP-sending and UDP-receiving + applications. Because other flows can share the path with one or + more UDP tunnels, congestion control needs to be considered. + + Two factors determine whether a UDP tunnel needs to employ specific + congestion control mechanisms: first, whether the payload traffic is + IP-based; and second, whether the tunneling scheme generates UDP + traffic at a volume that corresponds to the volume of payload traffic + carried within the tunnel. + + IP-based unicast traffic is generally assumed to be congestion + controlled, i.e., it is assumed that the transport protocols + generating IP-based unicast traffic at the sender already employ + mechanisms that are sufficient to address congestion on the path. + Consequently, a tunnel carrying IP-based unicast traffic should + + + + + +Eggert, et al. Best Current Practice [Page 16] + +RFC 8085 UDP Usage Guidelines March 2017 + + + already interact appropriately with other traffic sharing the path, + and specific congestion control mechanisms for the tunnel are not + necessary. + + However, if the IP traffic in the tunnel is known not to be + congestion controlled, additional measures are RECOMMENDED to limit + the impact of the tunneled traffic on other traffic sharing the path. + For the specific case of a tunnel that carries IP multicast traffic, + see Section 4.1. + + The following guidelines define these possible cases in more detail: + + 1. A tunnel generates UDP traffic at a volume that corresponds to + the volume of payload traffic, and the payload traffic is IP + based and congestion controlled. + + This is arguably the most common case for Internet tunnels. In + this case, the UDP tunnel SHOULD NOT employ its own congestion + control mechanism, because congestion losses of tunneled traffic + will already trigger an appropriate congestion response at the + original senders of the tunneled traffic. A circuit breaker + mechanism may provide benefit by controlling the envelope of the + aggregated traffic. + + Note that this guideline is built on the assumption that most + IP-based communication is congestion controlled. If a UDP tunnel + is used for IP-based traffic that is known to not be congestion + controlled, the next set of guidelines applies. + + 2. A tunnel generates UDP traffic at a volume that corresponds to + the volume of payload traffic, and the payload traffic is not + known to be IP based, or is known to be IP based but not + congestion controlled. + + This can be the case, for example, when some link-layer protocols + are encapsulated within UDP (but not all link-layer protocols; + some are congestion controlled). Because it is not known that + congestion losses of tunneled non-IP traffic will trigger an + appropriate congestion response at the senders, the UDP tunnel + SHOULD employ an appropriate congestion control mechanism or + circuit breaker mechanism designed for the traffic it carries. + Because tunnels are usually bulk-transfer applications as far as + the intermediate routers are concerned, the guidelines in + Section 3.1.2 apply. + + 3. A tunnel generates UDP traffic at a volume that does not + correspond to the volume of payload traffic, independent of + whether the payload traffic is IP based or congestion controlled. + + + +Eggert, et al. Best Current Practice [Page 17] + +RFC 8085 UDP Usage Guidelines March 2017 + + + Examples of this class include UDP tunnels that send at a + constant rate, increase their transmission rates under loss, for + example, due to increasing redundancy when Forward Error + Correction is used, or are otherwise unconstrained in their + transmission behavior. These specialized uses of UDP for + tunneling go beyond the scope of the general guidelines given in + this document. The implementer of such specialized tunnels + SHOULD carefully consider congestion control in the design of + their tunneling mechanism and SHOULD consider use of a circuit + breaker mechanism. + + The type of encapsulated payload might be identified by a UDP port; + identified by an Ethernet Type or IP protocol number. A tunnel + SHOULD provide mechanisms to restrict the types of flows that may be + carried by the tunnel. For instance, a UDP tunnel designed to carry + IP needs to filter out non-IP traffic at the ingress. This is + particularly important when a generic tunnel encapsulation is used + (e.g., one that encapsulates using an EtherType value). Such tunnels + SHOULD provide a mechanism to restrict the types of traffic that are + allowed to be encapsulated for a given deployment (see + [INT-TUNNELS]). + + Designing a tunneling mechanism requires significantly more expertise + than needed for many other UDP applications, because tunnels are + usually intended to be transparent to the endpoints transmitting over + them, so they need to correctly emulate the behavior of an IP link + [INT-TUNNELS], for example: + + o Requirements for tunnels that carry or encapsulate using ECN code + points [RFC6040]. + + o Usage of the IP DSCP field by tunnel endpoints [RFC2983]. + + o Encapsulation considerations in the design of tunnels [ENCAP]. + + o Usage of ICMP messages [INT-TUNNELS]. + + o Handling of fragmentation and packet size for tunnels + [INT-TUNNELS]. + + o Source port usage for tunnels designed to support equal cost + multipath (ECMP) routing (see Section 5.1.1). + + o Guidance on the need to protect headers [INT-TUNNELS] and the use + of checksums for IPv6 tunnels (see Section 3.4.1). + + o Support for operations and maintenance [INT-TUNNELS]. + + + + +Eggert, et al. Best Current Practice [Page 18] + +RFC 8085 UDP Usage Guidelines March 2017 + + + At the same time, the tunneled traffic is application traffic like + any other from the perspective of the networks the tunnel transmits + over. This document only touches upon the congestion control + considerations for implementing UDP tunnels; a discussion of other + required tunneling behavior is out of scope. + +3.2. Message Size Guidelines + + IP fragmentation lowers the efficiency and reliability of Internet + communication. The loss of a single fragment results in the loss of + an entire fragmented packet, because even if all other fragments are + received correctly, the original packet cannot be reassembled and + delivered. This fundamental issue with fragmentation exists for both + IPv4 and IPv6. + + In addition, some network address translators (NATs) and firewalls + drop IP fragments. The network address translation performed by a + NAT only operates on complete IP packets, and some firewall policies + also require inspection of complete IP packets. Even with these + being the case, some NATs and firewalls simply do not implement the + necessary reassembly functionality; instead, they choose to drop all + fragments. Finally, [RFC4963] documents other issues specific to + IPv4 fragmentation. + + Due to these issues, an application SHOULD NOT send UDP datagrams + that result in IP packets that exceed the Maximum Transmission Unit + (MTU) along the path to the destination. Consequently, an + application SHOULD either use the path MTU information provided by + the IP layer or implement Path MTU Discovery (PMTUD) itself [RFC1191] + [RFC1981] [RFC4821] to determine whether the path to a destination + will support its desired message size without fragmentation. + + However, the ICMP messages that enable path MTU discovery are being + increasingly filtered by middleboxes (including Firewalls) [RFC4890]. + When the path includes a tunnel, some devices acting as a tunnel + ingress discard ICMP messages that originate from network devices + over which the tunnel passes, preventing these from reaching the UDP + endpoint. + + Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not + rely upon network support for ICMP messages and is therefore + considered more robust than standard PMTUD. It is not susceptible to + "black holing" of ICMP messages. To operate, PLPMTUD requires + changes to the way the transport is used: both to transmit probe + packets and to account for the loss or success of these probes. This + not only updates the PMTU algorithm, it also impacts loss recovery, + congestion control, etc. These updated mechanisms can be implemented + + + + +Eggert, et al. Best Current Practice [Page 19] + +RFC 8085 UDP Usage Guidelines March 2017 + + + within a connection-oriented transport (e.g., TCP, SCTP, DCCP), but + they are not a part of UDP; this type of feedback is not typically + present for unidirectional applications. + + Therefore, PLPMTUD places additional design requirements on a UDP + application that wishes to use this method. This is especially true + for UDP tunnels, because the overhead of sending probe packets needs + to be accounted for and may require adding a congestion control + mechanism to the tunnel (see Section 3.1.11) as well as complicating + the data path at a tunnel decapsulator. + + Applications that do not follow the recommendation to do PMTU/PLPMTUD + discovery SHOULD still avoid sending UDP datagrams that would result + in IP packets that exceed the path MTU. Because the actual path MTU + is unknown, such applications SHOULD fall back to sending messages + that are shorter than the default effective MTU for sending (EMTU_S + in [RFC1122]). For IPv4, EMTU_S is the smaller of 576 bytes and the + first-hop MTU [RFC1122]. For IPv6, EMTU_S is 1280 bytes [RFC2460]. + The effective PMTU for a directly connected destination (with no + routers on the path) is the configured interface MTU, which could be + less than the maximum link payload size. Transmission of minimum- + sized UDP datagrams is inefficient over paths that support a larger + PMTU, which is a second reason to implement PMTU discovery. + + To determine an appropriate UDP payload size, applications MUST + subtract the size of the IP header (which includes any IPv4 optional + headers or IPv6 extension headers) as well as the length of the UDP + header (8 bytes) from the PMTU size. This size, known as the Maximum + Segment Size (MSS), can be obtained from the TCP/IP stack [RFC1122]. + + Applications that do not send messages that exceed the effective PMTU + of IPv4 or IPv6 need not implement any of the above mechanisms. Note + that the presence of tunnels can cause an additional reduction of the + effective PMTU [INT-TUNNELS], so implementing PMTU discovery may be + beneficial. + + Applications that fragment an application-layer message into multiple + UDP datagrams SHOULD perform this fragmentation so that each datagram + can be received independently, and be independently retransmitted in + the case where an application implements its own reliability + mechanisms. + + + + + + + + + + +Eggert, et al. Best Current Practice [Page 20] + +RFC 8085 UDP Usage Guidelines March 2017 + + +3.3. Reliability Guidelines + + Application designers are generally aware that UDP does not provide + any reliability, e.g., it does not retransmit any lost packets. + Often, this is a main reason to consider UDP as a transport protocol. + Applications that do require reliable message delivery MUST implement + an appropriate mechanism themselves. + + UDP also does not protect against datagram duplication, i.e., an + application may receive multiple copies of the same UDP datagram, + with some duplicates arriving potentially much later than the first. + Application designers SHOULD handle such datagram duplication + gracefully, and they may consequently need to implement mechanisms to + detect duplicates. Even if UDP datagram reception triggers only + idempotent operations, applications may want to suppress duplicate + datagrams to reduce load. + + Applications that require ordered delivery MUST reestablish datagram + ordering themselves. The Internet can significantly delay some + packets with respect to others, e.g., due to routing transients, + intermittent connectivity, or mobility. This can cause reordering, + where UDP datagrams arrive at the receiver in an order different from + the transmission order. + + Applications that use multiple transport ports need to be robust to + reordering between sessions. Load-balancing techniques within the + network, such as Equal Cost Multipath (ECMP) forwarding can also + result in a lack of ordering between different transport sessions, + even between the same two network endpoints. + + It is important to note that the time by which packets are reordered + or after which duplicates can still arrive can be very large. Even + more importantly, there is no well-defined upper boundary here. + [RFC793] defines the maximum delay a TCP segment should experience -- + the Maximum Segment Lifetime (MSL) -- as 2 minutes. No other RFC + defines an MSL for other transport protocols or IP itself. The MSL + value defined for TCP is conservative enough that it SHOULD be used + by other protocols, including UDP. Therefore, applications SHOULD be + robust to the reception of delayed or duplicate packets that are + received within this 2-minute interval. + + Retransmission of lost packets or messages is a common reliability + mechanism. Such retransmissions can increase network load in + response to congestion, worsening that congestion. Any application + that uses retransmission is responsible for congestion control of its + retransmissions (as well as the application's original traffic); + hence, it is subject to the Congestion Control guidelines in + + + + +Eggert, et al. Best Current Practice [Page 21] + +RFC 8085 UDP Usage Guidelines March 2017 + + + Section 3.1. Guidance on the appropriate measurement of RTT in + Section 3.1.1 also applies for timers used for retransmission packet- + loss detection. + + Instead of implementing these relatively complex reliability + mechanisms by itself, an application that requires reliable and + ordered message delivery SHOULD whenever possible choose an IETF + standard transport protocol that provides these features. + +3.4. Checksum Guidelines + + The UDP header includes an optional, 16-bit one's complement checksum + that provides an integrity check. These checks are not strong from a + coding or cryptographic perspective and are not designed to detect + physical-layer errors or malicious modification of the datagram + [RFC3819]. Application developers SHOULD implement additional checks + where data integrity is important, e.g., through a Cyclic Redundancy + Check (CRC) or keyed or non-keyed cryptographic hash included with + the data to verify the integrity of an entire object/file sent over + the UDP service. + + The UDP checksum provides a statistical guarantee that the payload + was not corrupted in transit. It also allows the receiver to verify + that it was the intended destination of the packet, because it covers + the IP addresses, port numbers, and protocol number, and it verifies + that the packet is not truncated or padded, because it covers the + size field. Therefore, it protects an application against receiving + corrupted payload data in place of, or in addition to, the data that + was sent. More description of the set of checks performed using the + checksum field is provided in Section 3.1 of [RFC6396]. + + Applications SHOULD enable UDP checksums [RFC1122]. For IPv4, + [RFC768] permits an option to disable their use, by setting a zero + checksum value. An application is permitted to optionally discard + UDP datagrams with a zero checksum [RFC1122]. + + When UDP is used over IPv6, the UDP checksum is relied upon to + protect both the IPv6 and UDP headers from corruption (because IPv6 + lacks a checksum) and MUST be used as specified in [RFC2460]. Under + specific conditions, a UDP application is allowed to use a zero UDP + zero-checksum mode with a tunnel protocol (see Section 3.4.1). + + Applications that choose to disable UDP checksums MUST NOT make + assumptions regarding the correctness of received data and MUST + behave correctly when a UDP datagram is received that was originally + sent to a different destination or is otherwise corrupted. + + + + + +Eggert, et al. Best Current Practice [Page 22] + +RFC 8085 UDP Usage Guidelines March 2017 + + +3.4.1. IPv6 Zero UDP Checksum + + [RFC6935] defines a method that enables use of a zero UDP zero- + checksum mode with a tunnel protocol, providing that the method + satisfies the requirements in [RFC6936]. The application MUST + implement mechanisms and/or usage restrictions when enabling this + mode. This includes defining the scope for usage and measures to + prevent leakage of traffic to other UDP applications (see Appendix A + and Section 3.6). These additional design requirements for using a + zero IPv6 UDP checksum are not present for IPv4, since the IPv4 + header validates information that is not protected in an IPv6 packet. + Key requirements are: + + o Use of the UDP checksum with IPv6 MUST be the default + configuration for all implementations [RFC6935]. The receiving + endpoint MUST only allow the use of UDP zero-checksum mode for + IPv6 on a UDP destination port that is specifically enabled. + + o An application that supports a checksum different than that in + [RFC2460] MUST comply with all implementation requirements + specified in Section 4 of [RFC6936] and with the usage + requirements specified in Section 5 of [RFC6936]. + + o A UDP application MUST check that the source and destination IPv6 + addresses are valid for any packets with a UDP zero-checksum and + MUST discard any packet for which this check fails. To protect + from misdelivery, new encapsulation designs SHOULD include an + integrity check at the transport layer that includes at least the + IPv6 header, the UDP header and the shim header for the + encapsulation, if any [RFC6936]. + + o One way to help satisfy the requirements of [RFC6936] may be to + limit the usage of such tunnels, e.g., to constrain traffic to an + operator network, as discussed in Section 3.6. The encapsulation + defined for MPLS in UDP [RFC7510] chooses this approach. + + As in IPv4, IPv6 applications that choose to disable UDP checksums + MUST NOT make assumptions regarding the correctness of received data + and MUST behave correctly when a UDP datagram is received that was + originally sent to a different destination or is otherwise corrupted. + + IPv6 datagrams with a zero UDP checksum will not be passed by any + middlebox that validates the checksum based on [RFC2460] or that + updates the UDP checksum field, such as NATs or firewalls. Changing + this behavior would require such middleboxes to be updated to + correctly handle datagrams with zero UDP checksums. To ensure end- + to-end robustness, applications that may be deployed in the general + Internet MUST provide a mechanism to safely fall back to using a + + + +Eggert, et al. Best Current Practice [Page 23] + +RFC 8085 UDP Usage Guidelines March 2017 + + + checksum when a path change occurs that redirects a zero UDP checksum + flow over a path that includes a middlebox that discards IPv6 + datagrams with a zero UDP checksum. + +3.4.2. UDP-Lite + + A special class of applications can derive benefit from having + partially damaged payloads delivered, rather than discarded, when + using paths that include error-prone links. Such applications can + tolerate payload corruption and MAY choose to use the Lightweight + User Datagram Protocol (UDP-Lite) [RFC3828] variant of UDP instead of + basic UDP. Applications that choose to use UDP-Lite instead of UDP + should still follow the congestion control and other guidelines + described for use with UDP in Section 3. + + UDP-Lite changes the semantics of the UDP "payload length" field to + that of a "checksum coverage length" field. Otherwise, UDP-Lite is + semantically identical to UDP. The interface of UDP-Lite differs + from that of UDP by the addition of a single (socket) option that + communicates the checksum coverage length: at the sender, this + specifies the intended checksum coverage, with the remaining + unprotected part of the payload called the "error-insensitive part". + By default, the UDP-Lite checksum coverage extends across the entire + datagram. If required, an application may dynamically modify this + length value, e.g., to offer greater protection to some messages. + UDP-Lite always verifies that a packet was delivered to the intended + destination, i.e., always verifies the header fields. Errors in the + insensitive part will not cause a UDP datagram to be discarded by the + destination. Therefore, applications using UDP-Lite MUST NOT make + assumptions regarding the correctness of the data received in the + insensitive part of the UDP-Lite payload. + + A UDP-Lite sender SHOULD select the minimum checksum coverage to + include all sensitive payload information. For example, applications + that use the Real-Time Protocol (RTP) [RFC3550] will likely want to + protect the RTP header against corruption. Applications, where + appropriate, MUST also introduce their own appropriate validity + checks for protocol information carried in the insensitive part of + the UDP-Lite payload (e.g., internal CRCs). + + A UDP-Lite receiver MUST set a minimum coverage threshold for + incoming packets that is not smaller than the smallest coverage used + by the sender [RFC3828]. The receiver SHOULD select a threshold that + is sufficiently large to block packets with an inappropriately short + coverage field. This may be a fixed value, or it may be negotiated + by an application. UDP-Lite does not provide mechanisms to negotiate + the checksum coverage between the sender and receiver. Therefore, + this needs to be performed by the application. + + + +Eggert, et al. Best Current Practice [Page 24] + +RFC 8085 UDP Usage Guidelines March 2017 + + + Applications can still experience packet loss when using UDP-Lite. + The enhancements offered by UDP-Lite rely upon a link being able to + intercept the UDP-Lite header to correctly identify the partial + coverage required. When tunnels and/or encryption are used, this can + result in UDP-Lite datagrams being treated the same as UDP datagrams, + i.e., result in packet loss. Use of IP fragmentation can also + prevent special treatment for UDP-Lite datagrams, and this is another + reason why applications SHOULD avoid IP fragmentation (Section 3.2). + + UDP-Lite is supported in some endpoint protocol stacks. Current + support for middlebox traversal using UDP-Lite is poor, because UDP- + Lite uses a different IPv4 protocol number or IPv6 "next header" + value than that used for UDP; therefore, few middleboxes are + currently able to interpret UDP-Lite and take appropriate actions + when forwarding the packet. This makes UDP-Lite less suited for + applications needing general Internet support, until such time as + UDP-Lite has achieved better support in middleboxes. + +3.5. Middlebox Traversal Guidelines + + NATs and firewalls are examples of intermediary devices + ("middleboxes") that can exist along an end-to-end path. A middlebox + typically performs a function that requires it to maintain per-flow + state. For connection-oriented protocols, such as TCP, middleboxes + snoop and parse the connection-management information, and create and + destroy per-flow state accordingly. For a connectionless protocol + such as UDP, this approach is not possible. Consequently, + middleboxes can create per-flow state when they see a packet that -- + according to some local criteria -- indicates a new flow, and destroy + the state after some time during which no packets belonging to the + same flow have arrived. + + Depending on the specific function that the middlebox performs, this + behavior can introduce a time-dependency that restricts the kinds of + UDP traffic exchanges that will be successful across the middlebox. + For example, NATs and firewalls typically define the partial path on + one side of them to be interior to the domain they serve, whereas the + partial path on their other side is defined to be exterior to that + domain. Per-flow state is typically created when the first packet + crosses from the interior to the exterior, and while the state is + present, NATs and firewalls will forward return traffic. Return + traffic that arrives after the per-flow state has timed out is + dropped, as is other traffic that arrives from the exterior. + + + + + + + + +Eggert, et al. Best Current Practice [Page 25] + +RFC 8085 UDP Usage Guidelines March 2017 + + + Many applications that use UDP for communication operate across + middleboxes without needing to employ additional mechanisms. One + example is the Domain Name System (DNS), which has a strict request- + response communication pattern that typically completes within + seconds. + + Other applications may experience communication failures when + middleboxes destroy the per-flow state associated with an application + session during periods when the application does not exchange any UDP + traffic. Applications SHOULD be able to gracefully handle such + communication failures and implement mechanisms to re-establish + application-layer sessions and state. + + For some applications, such as media transmissions, this + re-synchronization is highly undesirable, because it can cause user- + perceivable playback artifacts. Such specialized applications MAY + send periodic keep-alive messages to attempt to refresh middlebox + state (e.g., [RFC7675]). It is important to note that keep-alive + messages are not recommended for general use -- they are unnecessary + for many applications and can consume significant amounts of system + and network resources. + + An application that needs to employ keep-alive messages to deliver + useful service over UDP in the presence of middleboxes SHOULD NOT + transmit them more frequently than once every 15 seconds and SHOULD + use longer intervals when possible. No common timeout has been + specified for per-flow UDP state for arbitrary middleboxes. NATs + require a state timeout of 2 minutes or longer [RFC4787]. However, + empirical evidence suggests that a significant fraction of currently + deployed middleboxes unfortunately use shorter timeouts. The timeout + of 15 seconds originates with the Interactive Connectivity + Establishment (ICE) protocol [RFC5245]. When an application is + deployed in a controlled environment, the deployer SHOULD investigate + whether the target environment allows applications to use longer + intervals, or whether it offers mechanisms to explicitly control + middlebox state timeout durations, for example, using the Port + Control Protocol (PCP) [RFC6887], Middlebox Communications (MIDCOM) + [RFC3303], Next Steps in Signaling (NSIS) [RFC5973], or Universal + Plug and Play (UPnP) [UPnP]. It is RECOMMENDED that applications + apply slight random variations ("jitter") to the timing of keep-alive + transmissions, to reduce the potential for persistent synchronization + between keep-alive transmissions from different hosts [RFC7675]. + + + + + + + + + +Eggert, et al. Best Current Practice [Page 26] + +RFC 8085 UDP Usage Guidelines March 2017 + + + Sending keep-alive messages is not a substitute for implementing a + mechanism to recover from broken sessions. Like all UDP datagrams, + keep-alive messages can be delayed or dropped, causing middlebox + state to time out. In addition, the congestion control guidelines in + Section 3.1 cover all UDP transmissions by an application, including + the transmission of middlebox keep-alive messages. Congestion + control may thus lead to delays or temporary suspension of keep-alive + transmission. + + Keep-alive messages are NOT RECOMMENDED for general use. They are + unnecessary for many applications and may consume significant + resources. For example, on battery-powered devices, if an + application needs to maintain connectivity for long periods with + little traffic, the frequency at which keep-alive messages are sent + can become the determining factor that governs power consumption, + depending on the underlying network technology. + + Because many middleboxes are designed to require keep-alive messages + for TCP connections at a frequency that is much lower than that + needed for UDP, this difference alone can often be sufficient to + prefer TCP over UDP for these deployments. On the other hand, there + is anecdotal evidence that suggests that direct communication through + middleboxes, e.g., by using ICE [RFC5245], does succeed less often + with TCP than with UDP. The trade-offs between different transport + protocols -- especially when it comes to middlebox traversal -- + deserve careful analysis. + + UDP applications that could be deployed in the Internet need to be + designed understanding that there are many variants of middlebox + behavior, and although UDP is connectionless, middleboxes often + maintain state for each UDP flow. Using multiple UDP flows can + consume available state space and also can lead to changes in the way + the middlebox handles subsequent packets (either to protect its + internal resources, or to prevent perceived misuse). The probability + of path failure can increase when applications use multiple UDP flows + in parallel (see Section 5.1.2 for recommendations on usage of + multiple ports). + +3.6. Limited Applicability and Controlled Environments + + Two different types of applicability have been identified for the + specification of IETF applications that utilize UDP: + + General Internet. By default, IETF specifications target deployment + on the general Internet. Experience has shown that successful + protocols developed in one specific context or for a particular + application tend to become used in a wider range of contexts. For + example, a protocol with an initial deployment within a local area + + + +Eggert, et al. Best Current Practice [Page 27] + +RFC 8085 UDP Usage Guidelines March 2017 + + + network may subsequently be used over a virtual network that + traverses the Internet, or in the Internet in general. + Applications designed for general Internet use may experience a + range of network device behaviors and, in particular, should + consider whether applications need to operate over paths that may + include middleboxes. + + Controlled Environment. A protocol/encapsulation/tunnel could be + designed to be used only within a controlled environment. For + example, an application designed for use by a network operator + might only be deployed within the network of that single network + operator or on networks of an adjacent set of cooperating network + operators. The application traffic may then be managed to avoid + congestion, rather than relying on built-in mechanisms, which are + required when operating over the general Internet. Applications + that target a limited applicability use case may be able to take + advantage of specific hardware (e.g., carrier-grade equipment) or + underlying protocol features of the subnetwork over which they are + used. + + Specifications addressing a limited applicability use case or a + controlled environment SHOULD identify how, in their restricted + deployment, a level of safety is provided that is equivalent to that + of a protocol designed for operation over the general Internet (e.g., + a design based on extensive experience with deployments of particular + methods that provide features that cannot be expected in general + Internet equipment and the robustness of the design of MPLS to + corruption of headers both helped justify use of an alternate UDP + integrity check [RFC7510]). + + An IETF specification targeting a controlled environment is expected + to provide an applicability statement that restricts the application + traffic to the controlled environment, and it would be expected to + describe how methods can be provided to discourage or prevent escape + of corrupted packets from the environment (for example, Section 5 of + [RFC7510]). + +4. Multicast UDP Usage Guidelines + + This section complements Section 3 by providing additional guidelines + that are applicable to multicast and broadcast usage of UDP. + + Multicast and broadcast transmission [RFC1112] usually employ the UDP + transport protocol, although they may be used with other transport + protocols (e.g., UDP-Lite). + + + + + + +Eggert, et al. Best Current Practice [Page 28] + +RFC 8085 UDP Usage Guidelines March 2017 + + + There are currently two models of multicast delivery: the Any-Source + Multicast (ASM) model as defined in [RFC1112] and the Source-Specific + Multicast (SSM) model as defined in [RFC4607]. ASM group members + will receive all data sent to the group by any source, while SSM + constrains the distribution tree to only one single source. + + Specialized classes of applications also use UDP for IP multicast or + broadcast [RFC919]. The design of such specialized applications + requires expertise that goes beyond simple, unicast-specific + guidelines, since these senders may transmit to potentially very many + receivers across potentially very heterogeneous paths at the same + time, which significantly complicates congestion control, flow + control, and reliability mechanisms. + + This section provides guidance on multicast and broadcast UDP usage. + Use of broadcast by an application is normally constrained by routers + to the local subnetwork. However, use of tunneling techniques and + proxies can and does result in some broadcast traffic traversing + Internet paths. These guidelines therefore also apply to broadcast + traffic. + + The IETF has defined a reliable multicast framework [RFC3048] and + several building blocks to aid the designers of multicast + applications, such as [RFC3738] or [RFC4654]. + + Senders to anycast destinations must be aware that successive + messages sent to the same anycast IP address may be delivered to + different anycast nodes, i.e., arrive at different locations in the + topology. + + Most UDP tunnels that carry IP multicast traffic use a tunnel + encapsulation with a unicast destination address, such as Automatic + Multicast Tunneling [RFC7450]. These MUST follow the same + requirements as a tunnel carrying unicast data (see Section 3.1.11). + There are deployment cases and solutions where the outer header of a + UDP tunnel contains a multicast destination address, such as + [RFC6513]. These cases are primarily deployed in controlled + environments over reserved capacity, often operating within a single + administrative domain, or between two domains over a bilaterally + agreed upon path with reserved capacity, and so congestion control is + OPTIONAL, but circuit breaker techniques are still RECOMMENDED in + order to restore some degree of service should the offered load + exceed the reserved capacity (e.g., due to misconfiguration). + + + + + + + + +Eggert, et al. Best Current Practice [Page 29] + +RFC 8085 UDP Usage Guidelines March 2017 + + +4.1. Multicast Congestion Control Guidelines + + Unicast congestion-controlled transport mechanisms are often not + applicable to multicast distribution services, or simply do not scale + to large multicast trees, since they require bidirectional + communication and adapt the sending rate to accommodate the network + conditions to a single receiver. In contrast, multicast distribution + trees may fan out to massive numbers of receivers, which limits the + scalability of an in-band return channel to control the sending rate, + and the one-to-many nature of multicast distribution trees prevents + adapting the rate to the requirements of an individual receiver. For + this reason, generating TCP-compatible aggregate flow rates for + Internet multicast data, either native or tunneled, is the + responsibility of the application implementing the congestion + control. + + Applications using multicast SHOULD provide appropriate congestion + control. Multicast congestion control needs to be designed using + mechanisms that are robust to the potential heterogeneity of both the + multicast distribution tree and the receivers belonging to a group. + Heterogeneity may manifest itself in some receivers experiencing more + loss that others, higher delay, and/or less ability to respond to + network conditions. Congestion control is particularly important for + any multicast session where all or part of the multicast distribution + tree spans an access network (e.g., a home gateway). Two styles of + congestion control have been defined in the RFC Series: + + o Feedback-based congestion control, in which the sender receives + multicast or unicast UDP messages from the receivers allowing it + to assess the level of congestion and then adjust the sender + rate(s) (e.g., [RFC5740],[RFC4654]). Multicast methods may + operate on longer timescales than for unicast (e.g., due to the + higher group RTT of a heterogeneous group). A control method + could decide not to reduce the rate of the entire multicast group + in response to a control message received from a single receiver + (e.g., a sender could set a minimum rate and decide to request a + congested receiver to leave the multicast group and could also + decide to distribute content to these congested receivers at a + lower rate using unicast congestion control). + + o Receiver-driven congestion control, which does not require a + receiver to send explicit UDP control messages for congestion + control (e.g., [RFC3738], [RFC5775]). Instead, the sender + distributes the data across multiple IP multicast groups (e.g., + using a set of {S,G} channels). Each receiver determines its own + level of congestion and controls its reception rate using only + multicast join/leave messages sent in the network control plane. + This method scales to arbitrary large groups of receivers. + + + +Eggert, et al. Best Current Practice [Page 30] + +RFC 8085 UDP Usage Guidelines March 2017 + + + Any multicast-enabled receiver may attempt to join and receive + traffic from any group. This may imply the need for rate limits on + individual receivers or the aggregate multicast service. Note, at + the transport layer, there is no way to prevent a join message + propagating to the next-hop router. + + Some classes of multicast applications support applications that can + monitor the user-level quality of the transfer at the receiver. + Applications that can detect a significant reduction in user quality + SHOULD regard this as a congestion signal (e.g., to leave a group + using layered multicast encoding); if not, they SHOULD use this + signal to provide a circuit breaker to terminate the flow by leaving + the multicast group. + +4.1.1. Bulk-Transfer Multicast Applications + + Applications that perform bulk transmission of data over a multicast + distribution tree, i.e., applications that exchange more than a few + UDP datagrams per RTT, SHOULD implement a method for congestion + control. The currently RECOMMENDED IETF methods are as follows: + Asynchronous Layered Coding (ALC) [RFC5775], TCP-Friendly Multicast + Congestion Control (TFMCC) [RFC4654], Wave and Equation Based Rate + Control (WEBRC) [RFC3738], NACK-Oriented Reliable Multicast (NORM) + transport protocol [RFC5740], File Delivery over Unidirectional + Transport (FLUTE) [RFC6726], Real Time Protocol/Control Protocol + (RTP/RTCP) [RFC3550]. + + An application can alternatively implement another congestion control + scheme following the guidelines of [RFC2887] and utilizing the + framework of [RFC3048]. Bulk-transfer applications that choose not + to implement [RFC4654], [RFC5775], [RFC3738], [RFC5740], [RFC6726], + or [RFC3550] SHOULD implement a congestion control scheme that + results in bandwidth use that competes fairly with TCP within an + order of magnitude. + + Section 2 of [RFC3551] states that multimedia applications SHOULD + monitor the packet-loss rate to ensure that it is within acceptable + parameters. Packet loss is considered acceptable if a TCP flow + across the same network path under the same network conditions would + achieve an average throughput, measured on a reasonable timescale, + that is not less than that of the UDP flow. The comparison to TCP + cannot be specified exactly, but is intended as an "order-of- + magnitude" comparison in timescale and throughput. + +4.1.2. Low Data-Volume Multicast Applications + + All the recommendations in Section 3.1.3 are also applicable to low + data-volume multicast applications. + + + +Eggert, et al. Best Current Practice [Page 31] + +RFC 8085 UDP Usage Guidelines March 2017 + + +4.2. Message Size Guidelines for Multicast + + A multicast application SHOULD NOT send UDP datagrams that result in + IP packets that exceed the effective MTU as described in Section 3 of + [RFC6807]. Consequently, an application SHOULD either use the + effective MTU information provided by the "Population Count + Extensions to Protocol Independent Multicast (PIM)" [RFC6807] or + implement path MTU discovery itself (see Section 3.2) to determine + whether the path to each destination will support its desired message + size without fragmentation. + +5. Programming Guidelines + + The de facto standard application programming interface (API) for + TCP/IP applications is the "sockets" interface [POSIX]. Some + platforms also offer applications the ability to directly assemble + and transmit IP packets through "raw sockets" or similar facilities. + This is a second, more cumbersome method of using UDP. The + guidelines in this document cover all such methods through which an + application may use UDP. Because the sockets API is by far the most + common method, the remainder of this section discusses it in more + detail. + + Although the sockets API was developed for UNIX in the early 1980s, a + wide variety of non-UNIX operating systems also implement it. The + sockets API supports both IPv4 and IPv6 [RFC3493]. The UDP sockets + API differs from that for TCP in several key ways. Because + application programmers are typically more familiar with the TCP + sockets API, this section discusses these differences. [STEVENS] + provides usage examples of the UDP sockets API. + + UDP datagrams may be directly sent and received, without any + connection setup. Using the sockets API, applications can receive + packets from more than one IP source address on a single UDP socket. + Some servers use this to exchange data with more than one remote host + through a single UDP socket at the same time. Many applications need + to ensure that they receive packets from a particular source address; + these applications MUST implement corresponding checks at the + application layer or explicitly request that the operating system + filter the received packets. + + Many operating systems also allow a UDP socket to be connected, i.e., + to bind a UDP socket to a specific pair of addresses and ports. This + is similar to the corresponding TCP sockets API functionality. + However, for UDP, this is only a local operation that serves to + simplify the local send/receive functions and to filter the traffic + for the specified addresses and ports. Binding a UDP socket does not + establish a connection -- UDP does not notify the remote end when a + + + +Eggert, et al. Best Current Practice [Page 32] + +RFC 8085 UDP Usage Guidelines March 2017 + + + local UDP socket is bound. Binding a socket also allows configuring + options that affect the UDP or IP layers, for example, use of the UDP + checksum or the IP Timestamp option. On some stacks, a bound socket + also allows an application to be notified when ICMP error messages + are received for its transmissions [RFC1122]. + + If a client/server application executes on a host with more than one + IP interface, the application SHOULD send any UDP responses with an + IP source address that matches the IP destination address of the UDP + datagram that carried the request (see [RFC1122], Section 4.1.3.5). + Many middleboxes expect this transmission behavior and drop replies + that are sent from a different IP address, as explained in + Section 3.5. + + A UDP receiver can receive a valid UDP datagram with a zero-length + payload. Note that this is different from a return value of zero + from a read() socket call, which for TCP indicates the end of the + connection. + + UDP provides no flow-control, i.e., the sender at any given time does + not know whether the receiver is able to handle incoming + transmissions. This is another reason why UDP-based applications + need to be robust in the presence of packet loss. This loss can also + occur within the sending host, when an application sends data faster + than the line rate of the outbound network interface. It can also + occur at the destination, where receive calls fail to return all the + data that was sent when the application issues them too infrequently + (i.e., such that the receive buffer overflows). Robust flow control + mechanisms are difficult to implement, which is why applications that + need this functionality SHOULD consider using a full-featured + transport protocol such as TCP. + + When an application closes a TCP, SCTP, or DCCP socket, the transport + protocol on the receiving host is required to maintain TIME-WAIT + state. This prevents delayed packets from the closed connection + instance from being mistakenly associated with a later connection + instance that happens to reuse the same IP address and port pairs. + The UDP protocol does not implement such a mechanism. Therefore, + UDP-based applications need to be robust to reordering and delay. + One application may close a socket or terminate, followed in time by + another application receiving on the same port. This later + application may then receive packets intended for the first + application that were delayed in the network. + + + + + + + + +Eggert, et al. Best Current Practice [Page 33] + +RFC 8085 UDP Usage Guidelines March 2017 + + +5.1. Using UDP Ports + + The rules and procedures for the management of the "Service Name and + Transport Protocol Port Number Registry" are specified in [RFC6335]. + Recommendations for use of UDP ports are provided in [RFC7605]. + + A UDP sender SHOULD NOT use a source port value of zero. A source + port number that cannot be easily determined from the address or + payload type provides protection at the receiver from data injection + attacks by off-path devices. A UDP receiver SHOULD NOT bind to port + zero. + + Applications SHOULD implement receiver port and address checks at the + application layer or explicitly request that the operating system + filter the received packets to prevent receiving packets with an + arbitrary port. This measure is designed to provide additional + protection from data injection attacks from an off-path source (where + the port values may not be known). + + Applications SHOULD provide a check that protects from off-path data + injection, avoiding an application receiving packets that were + created by an unauthorized third party. TCP stacks commonly use a + randomized source port to provide this protection [RFC6056]; UDP + applications should follow the same technique. Middleboxes and end + systems often make assumptions about the system ports or user ports; + hence, it is recommended to use randomized ports in the Dynamic and/ + or Private Port range. Setting a "randomized" source port also + provides greater assurance that reported ICMP errors originate from + network systems on the path used by a particular flow. Some UDP + applications choose to use a predetermined value for the source port + (including some multicast applications), these applications need to + therefore employ a different technique. Protection from off-path + data attacks can also be provided by randomizing the initial value of + another protocol field within the datagram payload, and checking the + validity of this field at the receiver (e.g., RTP has random initial + sequence number and random media timestamp offsets [RFC3550]). + + When using multicast, IP routers perform a reverse-path forwarding + (RPF) check for each multicast packet. This provides protection from + off-path data injection, restricting opportunities to forge a + packet's source address. When a receiver joins a multicast group and + filters based on the source address the filter verifies the sender's + IP address. This is always the case when using an SSM {S,G} channel. + + + + + + + + +Eggert, et al. Best Current Practice [Page 34] + +RFC 8085 UDP Usage Guidelines March 2017 + + +5.1.1. Usage of UDP for Source Port Entropy and the IPv6 Flow Label + + Some applications use the UDP datagram header as a source of entropy + for network devices that implement ECMP [RFC6438]. A UDP tunnel + application targeting this usage encapsulates an inner packet using + UDP, where the UDP source port value forms a part of the entropy that + can be used to balance forwarding of network traffic by the devices + that use ECMP. A sending tunnel endpoint selects a source port value + in the UDP datagram header that is computed from the inner flow + information (e.g., the encapsulated packet headers). To provide + sufficient entropy, the sending tunnel endpoint maps the encapsulated + traffic to one of a range of UDP source values. The value SHOULD be + within the ephemeral port range, i.e., 49152 to 65535, where the high + order two bits of the port are set to one. The available source port + entropy of 14 bits (using the ephemeral port range) plus the outer IP + addresses seems sufficient for entropy for most ECMP applications + [ENCAP]. + + To avoid reordering within an IP flow, the same UDP source port value + SHOULD be used for all packets assigned to an encapsulated flow + (e.g., using a hash of the relevant headers). The entropy mapping + for a flow MAY change over the lifetime of the encapsulated flow + [ENCAP]. For instance, this could be changed as a Denial of Service + (DOS) mitigation, or as a means to effect routing through the ECMP + network. However, the source port selected for a flow SHOULD NOT + change more than once in every thirty seconds (e.g., as in + [RFC8086]). + + The use of the source port field for entropy has several side effects + that need to be considered, including: + + o It can increase the probability of misdelivery of corrupted + packets, which increases the need for checksum computation or an + equivalent mechanism to protect other UDP applications from + misdelivery errors Section 3.4. + + o It is expected to reduce the probability of successful middlebox + traversal Section 3.5. This use of the source port field will + often not be suitable for applications targeting deployment in the + general Internet. + + o It can prevent the field being usable to protect from off-path + attacks (described in Section 5.1). Designers therefore need to + consider other mechanisms to provide equivalent protection (e.g., + to restrict use to a controlled environment [RFC7510] + Section 3.6). + + + + + +Eggert, et al. Best Current Practice [Page 35] + +RFC 8085 UDP Usage Guidelines March 2017 + + + The UDP source port number field has also been leveraged to produce + entropy with IPv6. However, in the case of IPv6, the "flow label" + [RFC6437] may also alternatively be used to provide entropy for load + balancing [RFC6438]. This use of the flow label for load balancing + is consistent with the definition of the field, although further + clarity was needed to ensure the field can be consistently used for + this purpose. Therefore, an updated IPv6 flow label [RFC6437] and + ECMP routing [RFC6438] usage was specified. + + To ensure future opportunities to use the flow label, UDP + applications SHOULD set the flow label field, even when an entropy + value is also set in the source port field (e.g., An IPv6 tunnel + endpoint could copy the source port flow entropy value to the IPv6 + flow label field [RFC8086]). Router vendors are encouraged to start + using the IPv6 flow label as a part of the flow hash, providing + support for IP-level ECMP without requiring use of UDP. The end-to- + end use of flow labels for load balancing is a long-term solution. + Even if the usage of the flow label has been clarified, there will be + a transition time before a significant proportion of endpoints start + to assign a good quality flow label to the flows that they originate. + The use of load balancing using the transport header fields will + likely continue until widespread deployment is finally achieved. + +5.1.2. Applications Using Multiple UDP Ports + + A single application may exchange several types of data. In some + cases, this may require multiple UDP flows (e.g., multiple sets of + flows, identified by different five-tuples). [RFC6335] recommends + application developers not to apply to IANA to be assigned multiple + well-known ports (user or system). It does not discuss the + implications of using multiple flows with the same well-known port or + pairs of dynamic ports (e.g., identified by a service name or + signaling protocol). + + Use of multiple flows can affect the network in several ways: + + o Starting a series of successive connections can increase the + number of state bindings in middleboxes (e.g., NAPT or Firewall) + along the network path. UDP-based middlebox traversal usually + relies on timeouts to remove old state, since middleboxes are + unaware when a particular flow ceases to be used by an + application. + + o Using several flows at the same time may result in seeing + different network characteristics for each flow. It cannot be + assumed both follow the same path (e.g., when ECMP is used, + traffic is intentionally hashed onto different parallel paths + based on the port numbers). + + + +Eggert, et al. Best Current Practice [Page 36] + +RFC 8085 UDP Usage Guidelines March 2017 + + + o Using several flows can also increase the occupancy of a binding + or lookup table in a middlebox (e.g., NAPT or Firewall), which may + cause the device to change the way it manages the flow state. + + o Further, using excessive numbers of flows can degrade the ability + of a unicast congestion control to react to congestion events, + unless the congestion state is shared between all flows in a + session. A receiver-driven multicast congestion control requires + the sending application to distribute its data over a set of IP + multicast groups, each receiver is therefore expected to receive + data from a modest number of simultaneously active UDP ports. + + Therefore, applications MUST NOT assume consistent behavior of + middleboxes when multiple UDP flows are used; many devices respond + differently as the number of used ports increases. Using multiple + flows with different QoS requirements requires applications to verify + that the expected performance is achieved using each individual flow + (five-tuple), see Section 3.1.9. + +5.2. ICMP Guidelines + + Applications can utilize information about ICMP error messages that + the UDP layer passes up for a variety of purposes [RFC1122]. + Applications SHOULD appropriately validate the payload of ICMP + messages to ensure these are received in response to transmitted + traffic (i.e., a reported error condition that corresponds to a UDP + datagram actually sent by the application). This requires context, + such as local state about communication instances to each + destination, that although readily available in connection-oriented + transport protocols is not always maintained by UDP-based + applications. Note that not all platforms have the necessary APIs to + support this validation, and some platforms already perform this + validation internally before passing ICMP information to the + application. + + Any application response to ICMP error messages SHOULD be robust to + temporary routing failures (sometimes called "soft errors"), e.g., + transient ICMP "unreachable" messages ought to not normally cause a + communication abort. + + ICMP messages are being increasingly filtered by middleboxes. A UDP + application therefore SHOULD NOT rely on their delivery for correct + and safe operation. + + + + + + + + +Eggert, et al. Best Current Practice [Page 37] + +RFC 8085 UDP Usage Guidelines March 2017 + + +6. Security Considerations + + UDP does not provide communications security. Applications that need + to protect their communications against eavesdropping, tampering, or + message forgery SHOULD employ end-to-end security services provided + by other IETF protocols. + + UDP applications SHOULD provide protection from off-path data + injection attacks using a randomized source port or equivalent + technique (see Section 5.1). + + Applications that respond to short requests with potentially large + responses are a potential vector for amplification attacks, and + SHOULD take steps to minimize their potential for being abused as + part of a DoS attack. That could mean authenticating the sender + before responding; noting that the source IP address of a request is + not a useful authenticator, because it can easily be spoofed. Or it + may mean otherwise limiting the cases where short unauthenticated + requests produce large responses. Applications MAY also want to + offer ways to limit the number of requests they respond to in a time + interval, in order to cap the bandwidth they consume. + + One option for securing UDP communications is with IPsec [RFC4301], + which can provide authentication for flows of IP packets through the + Authentication Header (AH) [RFC4302] and encryption and/or + authentication through the Encapsulating Security Payload (ESP) + [RFC4303]. Applications use the Internet Key Exchange (IKE) + [RFC7296] to configure IPsec for their sessions. Depending on how + IPsec is configured for a flow, it can authenticate or encrypt the + UDP headers as well as UDP payloads. If an application only requires + authentication, ESP with no encryption but with authentication is + often a better option than AH, because ESP can operate across + middleboxes. An application that uses IPsec requires the support of + an operating system that implements the IPsec protocol suite, and the + network path must permit IKE and IPsec traffic. This may become more + common with IPv6 deployments [RFC6092]. + + Although it is possible to use IPsec to secure UDP communications, + not all operating systems support IPsec or allow applications to + easily configure it for their flows. A second option for securing + UDP communications is through Datagram Transport Layer Security + (DTLS) [RFC6347][RFC7525]. DTLS provides communication privacy by + encrypting UDP payloads. It does not protect the UDP headers. + Applications can implement DTLS without relying on support from the + operating system. + + + + + + +Eggert, et al. Best Current Practice [Page 38] + +RFC 8085 UDP Usage Guidelines March 2017 + + + Many other options for authenticating or encrypting UDP payloads + exist. For example, the GSS-API security framework [RFC2743] or + Cryptographic Message Syntax (CMS) [RFC5652] could be used to protect + UDP payloads. There exist a number of security options for RTP + [RFC3550] over UDP, especially to accomplish key-management, see + [RFC7201]. These options covers many usages, including point-to- + point, centralized group communication as well as multicast. In some + applications, a better solution is to protect larger stand-alone + objects, such as files or messages, instead of individual UDP + payloads. In these situations, CMS [RFC5652], S/MIME [RFC5751] or + OpenPGP [RFC4880] could be used. In addition, there are many + non-IETF protocols in this area. + + Like congestion control mechanisms, security mechanisms are difficult + to design and implement correctly. It is hence RECOMMENDED that + applications employ well-known standard security mechanisms such as + DTLS or IPsec, rather than inventing their own. + + The Generalized TTL Security Mechanism (GTSM) [RFC5082] may be used + with UDP applications when the intended endpoint is on the same link + as the sender. This lightweight mechanism allows a receiver to + filter unwanted packets. + + In terms of congestion control, [RFC2309] and [RFC2914] discuss the + dangers of congestion-unresponsive flows to the Internet. [RFC8084] + describes methods that can be used to set a performance envelope that + can assist in preventing congestion collapse in the absence of + congestion control or when the congestion control fails to react to + congestion events. This document provides guidelines to designers of + UDP-based applications to congestion-control their transmissions, and + does not raise any additional security concerns. + + Some network operators have experienced surges of UDP attack traffic + that are multiple orders of magnitude above the baseline traffic rate + for UDP. This can motivate operators to limit the data rate or + packet rate of UDP traffic. This may in turn limit the throughput + that an application can achieve using UDP and could also result in + higher packet loss for UDP traffic that would not be experienced if + other transport protocols had been used. + + A UDP application with a long-lived association between the sender + and receiver, ought to be designed so that the sender periodically + checks that the receiver still wants ("consents") to receive traffic + and need to be designed to stop if there is no explicit confirmation + of this [RFC7675]. Applications that require communications in two + directions to implement protocol functions (such as reliability or + + + + + +Eggert, et al. Best Current Practice [Page 39] + +RFC 8085 UDP Usage Guidelines March 2017 + + + congestion control) will need to independently check both directions + of communication, and may have to exchange keep-alive messages to + traverse middleboxes (see Section 3.5). + +7. Summary + + This section summarizes the key guidelines made in Sections 3 - 6 in + a tabular format (Table 1) for easy referencing. + + +---------------------------------------------------------+---------+ + | Recommendation | Section | + +---------------------------------------------------------+---------+ + | MUST tolerate a wide range of Internet path conditions | 3 | + | SHOULD use a full-featured transport (e.g., TCP) | | + | | | + | SHOULD control rate of transmission | 3.1 | + | SHOULD perform congestion control over all traffic | | + | | | + | for bulk transfers, | 3.1.2 | + | SHOULD consider implementing TFRC | | + | else, SHOULD in other ways use bandwidth similar to TCP | | + | | | + | for non-bulk transfers, | 3.1.3 | + | SHOULD measure RTT and transmit max. 1 datagram/RTT | 3.1.1 | + | else, SHOULD send at most 1 datagram every 3 seconds | | + | SHOULD back-off retransmission timers following loss | | + | | | + | SHOULD provide mechanisms to regulate the bursts of | 3.1.6 | + | transmission | | + | | | + | MAY implement ECN; a specific set of application | 3.1.7 | + | mechanisms are REQUIRED if ECN is used. | | + | | | + | for DiffServ, SHOULD NOT rely on implementation of PHBs | 3.1.8 | + | | | + | for QoS-enabled paths, MAY choose not to use CC | 3.1.9 | + | | | + | SHOULD NOT rely solely on QoS for their capacity | 3.1.10 | + | non-CC controlled flows SHOULD implement a transport | | + | circuit breaker | | + | MAY implement a circuit breaker for other applications | | + | | | + | for tunnels carrying IP traffic, | 3.1.11 | + | SHOULD NOT perform congestion control | | + | MUST correctly process the IP ECN field | | + | | | + + + + + +Eggert, et al. Best Current Practice [Page 40] + +RFC 8085 UDP Usage Guidelines March 2017 + + + | for non-IP tunnels or rate not determined by traffic, | | + | SHOULD perform CC or use circuit breaker | 3.1.11 | + | SHOULD restrict types of traffic transported by the | | + | tunnel | | + | | | + | SHOULD NOT send datagrams that exceed the PMTU, i.e., | 3.2 | + | SHOULD discover PMTU or send datagrams < minimum PMTU; | | + | Specific application mechanisms are REQUIRED if PLPMTUD | | + | is used. | | + | | | + | SHOULD handle datagram loss, duplication, reordering | 3.3 | + | SHOULD be robust to delivery delays up to 2 minutes | | + | | | + | SHOULD enable IPv4 UDP checksum | 3.4 | + | SHOULD enable IPv6 UDP checksum; Specific application | 3.4.1 | + | mechanisms are REQUIRED if a zero IPv6 UDP checksum is | | + | used. | | + | | | + | SHOULD provide protection from off-path attacks | 5.1 | + | else, MAY use UDP-Lite with suitable checksum coverage | 3.4.2 | + | | | + | SHOULD NOT always send middlebox keep-alive messages | 3.5 | + | MAY use keep-alives when needed (min. interval 15 sec) | | + | | | + | Applications specified for use in limited use (or | 3.6 | + | controlled environments) SHOULD identify equivalent | | + | mechanisms and describe their use case. | | + | | | + | Bulk-multicast apps SHOULD implement congestion control | 4.1.1 | + | | | + | Low volume multicast apps SHOULD implement congestion | 4.1.2 | + | control | | + | | | + | Multicast apps SHOULD use a safe PMTU | 4.2 | + | | | + | SHOULD avoid using multiple ports | 5.1.2 | + | MUST check received IP source address | | + | | | + | SHOULD validate payload in ICMP messages | 5.2 | + | | | + | SHOULD use a randomized source port or equivalent | 6 | + | technique, and, for client/server applications, SHOULD | | + | send responses from source address matching request | | + | 5.1 | | + | SHOULD use standard IETF security protocols when needed | 6 | + +---------------------------------------------------------+---------+ + + Table 1: Summary of Recommendations + + + +Eggert, et al. Best Current Practice [Page 41] + +RFC 8085 UDP Usage Guidelines March 2017 + + +8. References + +8.1. Normative References + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + DOI 10.17487/RFC0768, August 1980, + <http://www.rfc-editor.org/info/rfc768>. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, DOI 10.17487/RFC0793, September 1981, + <http://www.rfc-editor.org/info/rfc793>. + + [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, + DOI 10.17487/RFC1122, October 1989, + <http://www.rfc-editor.org/info/rfc1122>. + + [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, + DOI 10.17487/RFC1191, November 1990, + <http://www.rfc-editor.org/info/rfc1191>. + + [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery + for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August + 1996, <http://www.rfc-editor.org/info/rfc1981>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, <http://www.rfc-editor.org/info/rfc2460>. + + [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, + RFC 2914, DOI 10.17487/RFC2914, September 2000, + <http://www.rfc-editor.org/info/rfc2914>. + + [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., + and G. Fairhurst, Ed., "The Lightweight User Datagram + Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July + 2004, <http://www.rfc-editor.org/info/rfc3828>. + + [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address + Translation (NAT) Behavioral Requirements for Unicast + UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January + 2007, <http://www.rfc-editor.org/info/rfc4787>. + + + + +Eggert, et al. Best Current Practice [Page 42] + +RFC 8085 UDP Usage Guidelines March 2017 + + + [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU + Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, + <http://www.rfc-editor.org/info/rfc4821>. + + [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP + Friendly Rate Control (TFRC): Protocol Specification", + RFC 5348, DOI 10.17487/RFC5348, September 2008, + <http://www.rfc-editor.org/info/rfc5348>. + + [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines + for Application Designers", BCP 145, RFC 5405, + DOI 10.17487/RFC5405, November 2008, + <http://www.rfc-editor.org/info/rfc5405>. + + [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion + Notification", RFC 6040, DOI 10.17487/RFC6040, November + 2010, <http://www.rfc-editor.org/info/rfc6040>. + + [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, + "Computing TCP's Retransmission Timer", RFC 6298, + DOI 10.17487/RFC6298, June 2011, + <http://www.rfc-editor.org/info/rfc6298>. + + [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", + BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, + <http://www.rfc-editor.org/info/rfc8084>. + +8.2. Informative References + + [ALLMAN] Allman, M. and E. Blanton, "Notes on burst mitigation for + transport protocols", March 2005. + + [BEHAVE-APP] + Ford, B., "Application Design Guidelines for Traversal + through Network Address Translators", Work in Progress, + draft-ford-behave-app-05, March 2007. + + [ENCAP] Nordmark, E., Ed., Tian, A., Gross, J., Hudson, J., + Kreeger, L., Garg, P., Thaler, P., and T. Herbert, + "Encapsulation Considerations", Work in Progress, + draft-ietf-rtgwg-dt-encap-02, October 2016. + + [FABER] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT State in + TCP and Its Effect on Busy Servers", Proc. IEEE Infocom, + March 1999. + + + + + + +Eggert, et al. Best Current Practice [Page 43] + +RFC 8085 UDP Usage Guidelines March 2017 + + + [INT-TUNNELS] + Touch, J. and W. Townsley, "IP Tunnels in the Internet + Architecture", Work in Progress, + draft-ietf-intarea-tunnels-03, July 2016. + + [POSIX] IEEE Std. 1003.1-2001, , "Standard for Information + Technology - Portable Operating System Interface (POSIX)", + Open Group Technical Standard: Base Specifications Issue + 6, ISO/IEC 9945:2002, December 2001. + + [RFC919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, + RFC 919, DOI 10.17487/RFC0919, October 1984, + <http://www.rfc-editor.org/info/rfc919>. + + [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, + RFC 1112, DOI 10.17487/RFC1112, August 1989, + <http://www.rfc-editor.org/info/rfc1112>. + + [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. + Miller, "Common DNS Implementation Errors and Suggested + Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993, + <http://www.rfc-editor.org/info/rfc1536>. + + [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host + Anycasting Service", RFC 1546, DOI 10.17487/RFC1546, + November 1993, <http://www.rfc-editor.org/info/rfc1546>. + + [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, + S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., + Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, + S., Wroclawski, J., and L. Zhang, "Recommendations on + Queue Management and Congestion Avoidance in the + Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, + <http://www.rfc-editor.org/info/rfc2309>. + + [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., + and W. Weiss, "An Architecture for Differentiated + Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, + <http://www.rfc-editor.org/info/rfc2475>. + + [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", + RFC 2675, DOI 10.17487/RFC2675, August 1999, + <http://www.rfc-editor.org/info/rfc2675>. + + [RFC2743] Linn, J., "Generic Security Service Application Program + Interface Version 2, Update 1", RFC 2743, + DOI 10.17487/RFC2743, January 2000, + <http://www.rfc-editor.org/info/rfc2743>. + + + +Eggert, et al. Best Current Practice [Page 44] + +RFC 8085 UDP Usage Guidelines March 2017 + + + [RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R., + Vicisano, L., and M. Luby, "The Reliable Multicast Design + Space for Bulk Data Transfer", RFC 2887, + DOI 10.17487/RFC2887, August 2000, + <http://www.rfc-editor.org/info/rfc2887>. + + [RFC2983] Black, D., "Differentiated Services and Tunnels", + RFC 2983, DOI 10.17487/RFC2983, October 2000, + <http://www.rfc-editor.org/info/rfc2983>. + + [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., + Floyd, S., and M. Luby, "Reliable Multicast Transport + Building Blocks for One-to-Many Bulk-Data Transfer", + RFC 3048, DOI 10.17487/RFC3048, January 2001, + <http://www.rfc-editor.org/info/rfc3048>. + + [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", + RFC 3124, DOI 10.17487/RFC3124, June 2001, + <http://www.rfc-editor.org/info/rfc3124>. + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition + of Explicit Congestion Notification (ECN) to IP", + RFC 3168, DOI 10.17487/RFC3168, September 2001, + <http://www.rfc-editor.org/info/rfc3168>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <http://www.rfc-editor.org/info/rfc3261>. + + [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and + A. Rayhan, "Middlebox communication architecture and + framework", RFC 3303, DOI 10.17487/RFC3303, August 2002, + <http://www.rfc-editor.org/info/rfc3303>. + + [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. + Stevens, "Basic Socket Interface Extensions for IPv6", + RFC 3493, DOI 10.17487/RFC3493, February 2003, + <http://www.rfc-editor.org/info/rfc3493>. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, <http://www.rfc-editor.org/info/rfc3550>. + + + + + + +Eggert, et al. Best Current Practice [Page 45] + +RFC 8085 UDP Usage Guidelines March 2017 + + + [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and + Video Conferences with Minimal Control", STD 65, RFC 3551, + DOI 10.17487/RFC3551, July 2003, + <http://www.rfc-editor.org/info/rfc3551>. + + [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate + Control (WEBRC) Building Block", RFC 3738, + DOI 10.17487/RFC3738, April 2004, + <http://www.rfc-editor.org/info/rfc3738>. + + [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. + Conrad, "Stream Control Transmission Protocol (SCTP) + Partial Reliability Extension", RFC 3758, + DOI 10.17487/RFC3758, May 2004, + <http://www.rfc-editor.org/info/rfc3758>. + + [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., + Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. + Wood, "Advice for Internet Subnetwork Designers", BCP 89, + RFC 3819, DOI 10.17487/RFC3819, July 2004, + <http://www.rfc-editor.org/info/rfc3819>. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, + December 2005, <http://www.rfc-editor.org/info/rfc4301>. + + [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, + DOI 10.17487/RFC4302, December 2005, + <http://www.rfc-editor.org/info/rfc4302>. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, DOI 10.17487/RFC4303, December 2005, + <http://www.rfc-editor.org/info/rfc4303>. + + [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram + Congestion Control Protocol (DCCP)", RFC 4340, + DOI 10.17487/RFC4340, March 2006, + <http://www.rfc-editor.org/info/rfc4340>. + + [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion + Control Protocol (DCCP) Congestion Control ID 2: TCP-like + Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March + 2006, <http://www.rfc-editor.org/info/rfc4341>. + + + + + + + + +Eggert, et al. Best Current Practice [Page 46] + +RFC 8085 UDP Usage Guidelines March 2017 + + + [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for + Datagram Congestion Control Protocol (DCCP) Congestion + Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, + DOI 10.17487/RFC4342, March 2006, + <http://www.rfc-editor.org/info/rfc4342>. + + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through + Network Address Translations (NATs)", RFC 4380, + DOI 10.17487/RFC4380, February 2006, + <http://www.rfc-editor.org/info/rfc4380>. + + [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for + IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, + <http://www.rfc-editor.org/info/rfc4607>. + + [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast + Congestion Control (TFMCC): Protocol Specification", + RFC 4654, DOI 10.17487/RFC4654, August 2006, + <http://www.rfc-editor.org/info/rfc4654>. + + [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. + Thayer, "OpenPGP Message Format", RFC 4880, + DOI 10.17487/RFC4880, November 2007, + <http://www.rfc-editor.org/info/rfc4880>. + + [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering + ICMPv6 Messages in Firewalls", RFC 4890, + DOI 10.17487/RFC4890, May 2007, + <http://www.rfc-editor.org/info/rfc4890>. + + [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", + RFC 4960, DOI 10.17487/RFC4960, September 2007, + <http://www.rfc-editor.org/info/rfc4960>. + + [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly + Errors at High Data Rates", RFC 4963, + DOI 10.17487/RFC4963, July 2007, + <http://www.rfc-editor.org/info/rfc4963>. + + [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common + Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, + <http://www.rfc-editor.org/info/rfc4987>. + + [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. + Pignataro, "The Generalized TTL Security Mechanism + (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, + <http://www.rfc-editor.org/info/rfc5082>. + + + + +Eggert, et al. Best Current Practice [Page 47] + +RFC 8085 UDP Usage Guidelines March 2017 + + + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment + (ICE): A Protocol for Network Address Translator (NAT) + Traversal for Offer/Answer Protocols", RFC 5245, + DOI 10.17487/RFC5245, April 2010, + <http://www.rfc-editor.org/info/rfc5245>. + + [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion + Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate + Control for Small Packets (TFRC-SP)", RFC 5622, + DOI 10.17487/RFC5622, August 2009, + <http://www.rfc-editor.org/info/rfc5622>. + + [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, + RFC 5652, DOI 10.17487/RFC5652, September 2009, + <http://www.rfc-editor.org/info/rfc5652>. + + [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion + Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, + <http://www.rfc-editor.org/info/rfc5681>. + + [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, + "NACK-Oriented Reliable Multicast (NORM) Transport + Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009, + <http://www.rfc-editor.org/info/rfc5740>. + + [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet + Mail Extensions (S/MIME) Version 3.2 Message + Specification", RFC 5751, DOI 10.17487/RFC5751, January + 2010, <http://www.rfc-editor.org/info/rfc5751>. + + [RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous + Layered Coding (ALC) Protocol Instantiation", RFC 5775, + DOI 10.17487/RFC5775, April 2010, + <http://www.rfc-editor.org/info/rfc5775>. + + [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet + Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, + October 2010, <http://www.rfc-editor.org/info/rfc5971>. + + [RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, + "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", + RFC 5973, DOI 10.17487/RFC5973, October 2010, + <http://www.rfc-editor.org/info/rfc5973>. + + [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- + Protocol Port Randomization", BCP 156, RFC 6056, + DOI 10.17487/RFC6056, January 2011, + <http://www.rfc-editor.org/info/rfc6056>. + + + +Eggert, et al. Best Current Practice [Page 48] + +RFC 8085 UDP Usage Guidelines March 2017 + + + [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security + Capabilities in Customer Premises Equipment (CPE) for + Providing Residential IPv6 Internet Service", RFC 6092, + DOI 10.17487/RFC6092, January 2011, + <http://www.rfc-editor.org/info/rfc6092>. + + [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. + Cheshire, "Internet Assigned Numbers Authority (IANA) + Procedures for the Management of the Service Name and + Transport Protocol Port Number Registry", BCP 165, + RFC 6335, DOI 10.17487/RFC6335, August 2011, + <http://www.rfc-editor.org/info/rfc6335>. + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, <http://www.rfc-editor.org/info/rfc6347>. + + [RFC6396] Blunk, L., Karir, M., and C. Labovitz, "Multi-Threaded + Routing Toolkit (MRT) Routing Information Export Format", + RFC 6396, DOI 10.17487/RFC6396, October 2011, + <http://www.rfc-editor.org/info/rfc6396>. + + [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, + "IPv6 Flow Label Specification", RFC 6437, + DOI 10.17487/RFC6437, November 2011, + <http://www.rfc-editor.org/info/rfc6437>. + + [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label + for Equal Cost Multipath Routing and Link Aggregation in + Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, + <http://www.rfc-editor.org/info/rfc6438>. + + [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ + BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February + 2012, <http://www.rfc-editor.org/info/rfc6513>. + + [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., + and K. Carlberg, "Explicit Congestion Notification (ECN) + for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August + 2012, <http://www.rfc-editor.org/info/rfc6679>. + + [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, + "FLUTE - File Delivery over Unidirectional Transport", + RFC 6726, DOI 10.17487/RFC6726, November 2012, + <http://www.rfc-editor.org/info/rfc6726>. + + + + + + +Eggert, et al. Best Current Practice [Page 49] + +RFC 8085 UDP Usage Guidelines March 2017 + + + [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A + Datagram Congestion Control Protocol UDP Encapsulation for + NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November + 2012, <http://www.rfc-editor.org/info/rfc6773>. + + [RFC6807] Farinacci, D., Shepherd, G., Venaas, S., and Y. Cai, + "Population Count Extensions to Protocol Independent + Multicast (PIM)", RFC 6807, DOI 10.17487/RFC6807, December + 2012, <http://www.rfc-editor.org/info/rfc6807>. + + [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and + P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, + DOI 10.17487/RFC6887, April 2013, + <http://www.rfc-editor.org/info/rfc6887>. + + [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and + UDP Checksums for Tunneled Packets", RFC 6935, + DOI 10.17487/RFC6935, April 2013, + <http://www.rfc-editor.org/info/rfc6935>. + + [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement + for the Use of IPv6 UDP Datagrams with Zero Checksums", + RFC 6936, DOI 10.17487/RFC6936, April 2013, + <http://www.rfc-editor.org/info/rfc6936>. + + [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream + Control Transmission Protocol (SCTP) Packets for End-Host + to End-Host Communication", RFC 6951, + DOI 10.17487/RFC6951, May 2013, + <http://www.rfc-editor.org/info/rfc6951>. + + [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, + "Internet Small Computer System Interface (iSCSI) Protocol + (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April + 2014, <http://www.rfc-editor.org/info/rfc7143>. + + [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP + Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, + <http://www.rfc-editor.org/info/rfc7201>. + + [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. + Kivinen, "Internet Key Exchange Protocol Version 2 + (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October + 2014, <http://www.rfc-editor.org/info/rfc7296>. + + [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, + DOI 10.17487/RFC7450, February 2015, + <http://www.rfc-editor.org/info/rfc7450>. + + + +Eggert, et al. Best Current Practice [Page 50] + +RFC 8085 UDP Usage Guidelines March 2017 + + + [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, + "Encapsulating MPLS in UDP", RFC 7510, + DOI 10.17487/RFC7510, April 2015, + <http://www.rfc-editor.org/info/rfc7510>. + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May + 2015, <http://www.rfc-editor.org/info/rfc7525>. + + [RFC7560] Kuehlewind, M., Ed., Scheffenegger, R., and B. Briscoe, + "Problem Statement and Requirements for Increased Accuracy + in Explicit Congestion Notification (ECN) Feedback", + RFC 7560, DOI 10.17487/RFC7560, August 2015, + <http://www.rfc-editor.org/info/rfc7560>. + + [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF + Recommendations Regarding Active Queue Management", + BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, + <http://www.rfc-editor.org/info/rfc7567>. + + [RFC7605] Touch, J., "Recommendations on Using Assigned Transport + Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, + August 2015, <http://www.rfc-editor.org/info/rfc7605>. + + [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services + (Diffserv) and Real-Time Communication", RFC 7657, + DOI 10.17487/RFC7657, November 2015, + <http://www.rfc-editor.org/info/rfc7657>. + + [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. + Thomson, "Session Traversal Utilities for NAT (STUN) Usage + for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, + October 2015, <http://www.rfc-editor.org/info/rfc7675>. + + [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: + Circuit Breakers for Unicast RTP Sessions", RFC 8083, + DOI 10.17487/RFC8083, March 2017, + <http://www.rfc-editor.org/info/rfc8083>. + + [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- + in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, + March 2017, <http://www.rfc-editor.org/info/rfc8086>. + + + + + + + +Eggert, et al. Best Current Practice [Page 51] + +RFC 8085 UDP Usage Guidelines March 2017 + + + [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using + Explicit Congestion Notification (ECN)", RFC 8087, + DOI 10.17487/RFC8087, March 2017, + <http://www.rfc-editor.org/info/rfc8087>. + + [STEVENS] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network + Programming, The sockets Networking API", Addison-Wesley, + 2004. + + [UPnP] UPnP Forum, , "Internet Gateway Device (IGD) Standardized + Device Control Protocol V 1.0", November 2001. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eggert, et al. Best Current Practice [Page 52] + +RFC 8085 UDP Usage Guidelines March 2017 + + +Appendix A. Case Study of the Use of IPv6 UDP Zero-Checksum Mode + + This appendix provides a brief review of MPLS-in-UDP as an example of + a UDP Tunnel Encapsulation that defines a UDP encapsulation. The + purpose of the appendix is to provide a concrete example of which + mechanisms were required in order to safely use UDP zero-checksum + mode for MPLS-in-UDP tunnels over IPv6. By default, UDP requires a + checksum for use with IPv6. An option has been specified that + permits a zero IPv6 UDP checksum when used in specific environments, + specified in [RFC7510], and defines a set of operational constraints + for use of this mode. These are summarized below: + + A UDP tunnel or encapsulation using a zero-checksum mode with IPv6 + must only be deployed within a single network (with a single network + operator) or networks of an adjacent set of cooperating network + operators where traffic is managed to avoid congestion, rather than + over the Internet where congestion control is required. MPLS-in-UDP + has been specified for networks under single administrative control + (such as within a single operator's network) where it is known + (perhaps through knowledge of equipment types and lower-layer checks) + that packet corruption is exceptionally unlikely and where the + operator is willing to take the risk of undetected packet corruption. + + The tunnel encapsulator SHOULD use different IPv6 addresses for each + UDP tunnel that uses the UDP zero-checksum mode, regardless of the + decapsulator, to strengthen the decapsulator's check of the IPv6 + source address (i.e., the same IPv6 source address SHOULD NOT be used + with more than one IPv6 destination address, independent of whether + that destination address is a unicast or multicast address). Use of + MPLS-in-UDP may be extended to networks within a set of closely + cooperating network administrations (such as network operators who + have agreed to work together to jointly provide specific services) + [RFC7510]. + + The requirement for MPLS-in-UDP endpoints to check the source IPv6 + address in addition to the destination IPv6 address, plus the strong + recommendation against reuse of source IPv6 addresses among MPLS-in- + UDP tunnels collectively provide some mitigation for the absence of + UDP checksum coverage of the IPv6 header. In addition, the MPLS data + plane only forwards packets with valid labels (i.e., labels that have + been distributed by the tunnel egress Label Switched Router, LSR), + providing some additional opportunity to detect MPLS-in-UDP packet + misdelivery when the misdelivered packet contains a label that is not + valid for forwarding at the receiving LSR. The expected result for + IPv6 UDP zero-checksum mode for MPLS-in-UDP is that corruption of the + destination IPv6 address will usually cause packet discard, as + offsetting corruptions to the source IPv6 and/or MPLS top label are + unlikely. + + + +Eggert, et al. Best Current Practice [Page 53] + +RFC 8085 UDP Usage Guidelines March 2017 + + + Additional assurance is provided by the restrictions in the above + exceptions that limit usage of IPv6 UDP zero-checksum mode to well- + managed networks for which MPLS packet corruption has not been a + problem in practice. Hence, MPLS-in-UDP is suitable for transmission + over lower layers in well-managed networks that are allowed by the + exceptions stated above and the rate of corruption of the inner IP + packet on such networks is not expected to increase by comparison to + MPLS traffic that is not encapsulated in UDP. For these reasons, + MPLS-in-UDP does not provide an additional integrity check when UDP + zero-checksum mode is used with IPv6, and this design is in + accordance with requirements 2, 3, and 5 specified in Section 5 of + [RFC6936]. + + The MPLS-in-UDP encapsulation does not provide a mechanism to safely + fall back to using a checksum when a path change occurs that + redirects a tunnel over a path that includes a middlebox that + discards IPv6 datagrams with a zero UDP checksum. In this case, the + MPLS-in-UDP tunnel will be black-holed by that middlebox. + Recommended changes to allow firewalls, NATs and other middleboxes to + support use of an IPv6 zero UDP checksum are described in Section 5 + of [RFC6936]. MPLS does not accumulate incorrect state as a + consequence of label-stack corruption. A corrupt MPLS label results + in either packet discard or forwarding (and forgetting) of the packet + without accumulation of MPLS protocol state. Active monitoring of + MPLS-in-UDP traffic for errors is REQUIRED because the occurrence of + errors will result in some accumulation of error information outside + the MPLS protocol for operational and management purposes. This + design is in accordance with requirement 4 specified in Section 5 of + [RFC6936]. In addition, IPv6 traffic with a zero UDP checksum MUST + be actively monitored for errors by the network operator. + + Operators SHOULD also deploy packet filters to prevent IPv6 packets + with a zero UDP checksum from escaping from the network due to + misconfiguration or packet errors. In addition, IPv6 traffic with a + zero UDP checksum MUST be actively monitored for errors by the + network operator. + + + + + + + + + + + + + + + +Eggert, et al. Best Current Practice [Page 54] + +RFC 8085 UDP Usage Guidelines March 2017 + + +Acknowledgments + + The middlebox traversal guidelines in Section 3.5 incorporate ideas + from Section 5 of [BEHAVE-APP] by Bryan Ford, Pyda Srisuresh, and Dan + Kegel. The protocol timer guidelines in Section 3.1.1 were largely + contributed by Mark Allman. + + G. Fairhurst received funding from the European Union's Horizon 2020 + research and innovation program 2014-2018 under grant agreement No. + 644334 (NEAT). Lars Eggert has received funding from the European + Union's Horizon 2020 research and innovation program 2014-2018 under + grant agreement No. 644866 (SSICLOPS). This document reflects only + the authors' views and the European Commission is not responsible for + any use that may be made of the information it contains. + +Authors' Addresses + + Lars Eggert + NetApp + Sonnenallee 1 + Kirchheim 85551 + Germany + + Phone: +49 151 120 55791 + Email: lars@netapp.com + URI: https://eggert.org/ + + + Godred Fairhurst + University of Aberdeen + Department of Engineering + Fraser Noble Building + Aberdeen AB24 3UE + Scotland + + Email: gorry@erg.abdn.ac.uk + URI: http://www.erg.abdn.ac.uk/ + + + Greg Shepherd + Cisco Systems + Tasman Drive + San Jose + United States of America + + Email: gjshep@gmail.com + + + + + +Eggert, et al. Best Current Practice [Page 55] + |