One document matched: draft-ietf-tsvwg-rfc5405bis-07.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0768 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml">
<!ENTITY RFC0793 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC0896 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0896.xml">
<!ENTITY RFC0919 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0919.xml">
<!ENTITY RFC1112 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1112.xml">
<!ENTITY RFC1122 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY RFC1191 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1191.xml">
<!ENTITY RFC1536 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1536.xml">
<!ENTITY RFC1546 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1546.xml">
<!ENTITY RFC1981 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1981.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2309 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2309.xml">
<!ENTITY RFC2460 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC2475 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2475.xml">
<!ENTITY RFC2675 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2675.xml">
<!ENTITY RFC2743 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2743.xml">
<!ENTITY RFC2887 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2887.xml">
<!ENTITY RFC2914 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2914.xml">
<!ENTITY RFC3048 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3048.xml">
<!ENTITY RFC3124 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3124.xml">
<!ENTITY RFC3168 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY RFC3261 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3303 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3303.xml">
<!ENTITY RFC3493 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3493.xml">
<!ENTITY RFC3550 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC3551 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY RFC7201 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7201.xml">
<!ENTITY RFC3738 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3738.xml">
<!ENTITY RFC3758 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3758.xml">
<!ENTITY RFC3819 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3819.xml">
<!ENTITY RFC3828 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3828.xml">
<!ENTITY RFC4301 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC4302 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml">
<!ENTITY RFC4303 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC4340 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml">
<!ENTITY RFC4341 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4341.xml">
<!ENTITY RFC4342 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4342.xml">
<!ENTITY RFC4607 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4607.xml">
<!ENTITY RFC4654 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4654.xml">
<!ENTITY RFC4787 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC4821 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4821.xml">
<!ENTITY RFC4880 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4880.xml">
<!ENTITY RFC4960 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC4963 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4963.xml">
<!ENTITY RFC4987 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4987.xml">
<!ENTITY RFC5082 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml">
<!ENTITY RFC5245 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY RFC5348 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5348.xml">
<!ENTITY RFC5405 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5405.xml">
<!ENTITY RFC5622 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5622.xml">
<!ENTITY RFC5652 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml">
<!ENTITY RFC5740 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5740.xml">
<!ENTITY RFC5751 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5751.xml">
<!ENTITY RFC5775 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5775.xml">
<!ENTITY RFC5885 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5885.xml">
<!ENTITY RFC5971 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5971.xml">
<!ENTITY RFC5973 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5973.xml">
<!ENTITY RFC7296 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml">
<!ENTITY RFC6298 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6298.xml">
<!ENTITY RFC6335 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6335.xml">
<!ENTITY RFC6347 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC6395 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6395.xml">
<!ENTITY RFC6396 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6396.xml">
<!ENTITY RFC6437 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6437.xml">
<!ENTITY RFC6438 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6438.xml">
<!ENTITY RFC6513 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml">
<!ENTITY RFC6679 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6679.xml">
<!ENTITY RFC6726 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6726.xml">
<!ENTITY RFC6807 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6807.xml">
<!ENTITY RFC6887 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6887.xml">
<!ENTITY RFC6936 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6936.xml">
<!ENTITY RFC6056 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6056.xml">
<!ENTITY RFC6935 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6935.xml">
<!ENTITY RFC7143 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7143.xml">
<!ENTITY RFC7510 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7510.xml">
<!ENTITY RFC7605 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7605.xml">
<!ENTITY RFC7560 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7560.xml">
<!ENTITY RFC6040 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6040.xml">
<!ENTITY RFC7675 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7675.xml">
<!ENTITY I-D.ford-behave-app SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ford-behave-app.xml">
<!ENTITY I-D.ietf-avtcore-rtp-circuit-breakers SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-rtp-circuit-breakers.xml">
<!ENTITY I-D.ietf-tsvwg-circuit-breaker SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-circuit-breaker.xml">
<!ENTITY I-D.ietf-dart-dscp-rtp SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dart-dscp-rtp.xml">
<!ENTITY I-D.ietf-aqm-ecn-benefits SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-aqm-ecn-benefits.xml">
<!ENTITY I-D.ietf-rtgwg-dt-encap SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-dt-encap.xml">
<!ENTITY I-D.ietf-intarea-tunnels SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-intarea-tunnels.xml">
]>
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc tocompact="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes" ?>
<?rfc compact='yes'?>
<rfc category="bcp" docName="draft-ietf-tsvwg-rfc5405bis-07"
ipr="trust200902" number="" obsoletes="5405">
<front>
<title abbrev="UDP Usage Guidelines">UDP Usage Guidelines</title>
<author fullname="Lars Eggert" initials="L." surname="Eggert">
<organization>NetApp</organization>
<address>
<postal>
<street>Sonnenallee 1</street>
<city>Kirchheim</city>
<code>85551</code>
<country>Germany</country>
</postal>
<phone>+49 151 120 55791</phone>
<email>lars@netapp.com</email>
<uri>https://eggert.org/</uri>
</address>
</author>
<author fullname="Godred Fairhurst" initials="G." surname="Fairhurst">
<organization>University of Aberdeen</organization>
<address>
<postal>
<street>Department of Engineering</street>
<street>Fraser Noble Building</street>
<city>Aberdeen</city>
<code>AB24 3UE</code>
<country>Scotland</country>
</postal>
<email>gorry@erg.abdn.ac.uk</email>
<uri>http://www.erg.abdn.ac.uk/</uri>
</address>
</author>
<author fullname="Greg Shepherd" initials="G." surname="Shepherd">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Tasman Drive</street>
<city>San Jose</city>
<code></code>
<country>USA</country>
</postal>
<email>gjshep@gmail.com</email>
<uri></uri>
</address>
</author>
<date />
<area>Transport Area</area>
<workgroup>Transport Area Working Group</workgroup>
<keyword>UDP</keyword>
<keyword>guidelines</keyword>
<abstract>
<t>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 ECN, DSCPs, and ports.</t>
<t>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.</t>
<t>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.</t>
<t>If published as an RFC, this document will obsolete RFC5405.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The User Datagram Protocol (UDP) <xref target="RFC0768"></xref>
provides a minimal, unreliable, best-effort, message-passing transport
to applications and other protocols (such as tunnels) that desire to
operate over UDP. Both simply called "applications" in the remainder of
this document.</t>
<t>Compared to other transport protocols, UDP and its UDP-Lite variant
<xref target="RFC3828"></xref> 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.</t>
<t>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. <xref
target="RFC2914"></xref> describes the best current practice for
congestion control in the Internet. It identifies two major reasons why
congestion control mechanisms are critical for the stable operation of
the Internet: <list style="numbers">
<t>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.</t>
<t>The establishment of a degree of fairness, i.e., allowing
multiple flows to share the capacity of a path reasonably
equitably.</t>
</list></t>
<t>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. <xref target="RFC2309"></xref> discusses the dangers
of congestion-unresponsive flows and states that "all UDP-based
streaming applications should incorporate effective congestion avoidance
mechanisms." 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. <xref
target="udpuni"></xref> describes a number of simple guidelines for the
designers of such applications.</t>
<t>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 <xref target="RFC2675"></xref>. Some of the guidelines in
<xref target="udpuni"></xref> describe how applications should determine
appropriate message sizes. Other sections of this document provide
guidance on reliability, checksums, middlebox traversal and use of
multicast.</t>
<t>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 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.</t>
<t><xref target="RFC5405"></xref> 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.</t>
<t>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.</t>
</section>
<section anchor="term" title="Terminology">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
<section anchor="udpuni" title=" UDP Usage Guidelines">
<t>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.</t>
<t>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 not rare. 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 <xref target="RFC0793"></xref>,
Stream Control Transmission Protocol (SCTP) <xref
target="RFC4960"></xref>, and SCTP Partial Reliability Extension
(SCTP-PR) <xref target="RFC3758"></xref>, or Datagram Congestion Control
Protocol (DCCP) <xref target="RFC4340"></xref> with its different
congestion control types <xref target="RFC4341"></xref><xref
target="RFC4342"></xref><xref target="RFC5622"></xref>.</t>
<t>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 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 <xref target="RFC0896"></xref> 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 <xref
target="RFC4987"></xref>, 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 <xref
target="FABER"></xref>. 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.</t>
<section anchor="unicc" title="Congestion Control Guidelines">
<t>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 <xref target="RFC2914"></xref>. 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.</t>
<t>Several approaches to perform congestion control are discussed in
the remainder of this section. The section describes generic topics
with an intended emphasis on unicast and anycast <xref
target="RFC1546"></xref> usage. Not all approaches discussed below are
appropriate for all UDP-transmitting applications. <xref
target="unibt"></xref> discusses congestion control options for
applications that perform bulk transfers over UDP. Such applications
can employ schemes that sample the path over several subsequent RTTs
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. <xref target="unildr"></xref>
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. <xref
target="tun"></xref> discusses congestion control considerations when
UDP is used as a tunneling protocol. <xref target="udpmcast"></xref>
provides additional recommendations for broadcast and multicast
usage.</t>
<t>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.</t>
<t>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 <xref
target="RFC3124"></xref>, 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 <xref
target="RFC2914"></xref>.</t>
<section anchor="unibt" title="Bulk Transfer Applications">
<t>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 TCP-Friendly Rate Control (TFRC)
<xref target="RFC5348"></xref>, window-based TCP-like congestion
control, or otherwise ensure that the application complies with the
congestion control principles.</t>
<t>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 <xref target="unibt"></xref>, because TFRC
already addresses them, but SHOULD still follow the remaining
guidelines in the subsequent subsections of <xref
target="udpuni"></xref>.</t>
<t>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.</t>
<t>Section 2 of <xref target="RFC3551"></xref> 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.</t>
<t>Finally, some bulk transfer applications may choose not to
implement any congestion control mechanism and instead rely on
transmitting across reserved path capacity (see <xref
target="QoS"></xref>). 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.</t>
</section>
<section anchor="unildr" title="Low Data-Volume Applications">
<t>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 <xref target="unibt"></xref>, the
network sees little benefit, because those mechanisms perform
congestion control in a way that is only effective for longer
transmissions.</t>
<t>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 round-trip
time (RTT) to a destination. Similar to the recommendation in <xref
target="RFC1536"></xref>, an application SHOULD maintain an estimate
of the RTT for any destination with which it communicates.
Applications SHOULD implement the algorithm specified in <xref
target="RFC6298"></xref> to compute a smoothed RTT (SRTT) estimate.
They SHOULD also detect packet loss and exponentially back their
retransmission timer off when a loss event occurs. When implementing
this scheme, applications need to choose a sensible initial value
for the RTT. This value SHOULD generally be as conservative as
possible for the given application. TCP specifies an initial value
of 3 seconds <xref target="RFC6298"></xref>, which is also
RECOMMENDED as an initial value for UDP applications. SIP <xref
target="RFC3261"></xref> and GIST <xref target="RFC5971"></xref> use
an initial value of 500 ms, and initial timeouts that are shorter
than this are likely problematic in many cases. It is also important
to note that the initial timeout is not the maximum possible timeout
-- the RECOMMENDED algorithm in <xref target="RFC6298"></xref>
yields timeout values after a series of losses that are much longer
than the initial value.</t>
<t>Some applications cannot maintain a reliable RTT estimate for a
destination. The first case is that of applications that exchange
too few UDP datagrams with a peer to establish a statistically
accurate RTT estimate. Such applications MAY use a predetermined
transmission interval that is exponentially backed-off when packets
are lost. TCP uses an initial value of 3 seconds <xref
target="RFC6298"></xref>, which is also RECOMMENDED as an initial
value for UDP applications. SIP <xref target="RFC3261"></xref> and
GIST <xref target="RFC5971"></xref> 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.</t>
<t>A second class 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. The 3-second interval was chosen based on TCP's
retransmission timeout when the RTT is unknown <xref
target="RFC6298"></xref>, and shorter values are likely problematic
in many cases. Note that the sending rate in this case must be more
conservative than in the two 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.</t>
<t>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 direction 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.</t>
</section>
<section anchor="RTT-CC"
title="Implications of RTT and Loss Measurements on Congestion Control">
<t>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).</t>
<t>The operation of a UDP Congestion Control algorithm can be very
different to 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: 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).</t>
<t>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 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.</t>
<t>A congestion control designed for UDP SHOULD respond as quickly
as possible when it experiences congestion, and 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.</t>
</section>
<section anchor="uniburst" title="Burst Mitigation and Pacing">
<t>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 <xref target="ALLMAN"></xref>
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., <xref
target="RFC7143"></xref>).</t>
<t>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).</t>
</section>
<section anchor="ECN" title="Explicit Congestion Notification">
<t>Internet applications can use Explicit Congestion Notification
(ECN) <xref target="RFC3168"></xref> to gain benefits for the
services they support <xref
target="I-D.ietf-aqm-ecn-benefits"></xref>.</t>
<t>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, CE codepoint), rather than drop the IP packet as a
signal of incipient congestion.</t>
<t>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.</t>
<t>The requirements for UDP-based tunnels to support ECN are
described in <xref target="tun"></xref>.</t>
<t>The set of mechanisms requires for an application to use ECN over
UDP are:</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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 <xref
target="RFC7560"></xref>. (<xref target="RFC3168"> </xref> and
<xref target="RFC7560"></xref> specify methods for TCP.)</t>
<t>An application sending ECN-capable datagrams MUST provide an
appropriate congestion reaction when it receives feedback
indicating that congestion has been experienced. This must
result in reduction of the sending rate by the UDP congestion
control method <xref target="unicc"></xref> that is not less
than the reaction of TCP under equivalent conditions.</t>
<t>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 <xref target="I-D.ietf-aqm-ecn-benefits"></xref>. This
method needs to be robust to changes within the network path
that may occur over the lifetime of a session.</t>
<t>A sender is encouraged to provide a mechanism to detect and
react appropriately to misbehaving receivers that fail to report
CE-marked packets <xref
target="I-D.ietf-aqm-ecn-benefits"></xref>.</t>
</list></t>
<t><xref target="RFC6679"></xref> provides guidance 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).</t>
</section>
<section anchor="unids" title="Differentiated Services Model">
<t>An application using UDP can use the differentiated services QoS
framework. To enable differentiated services processing, a UDP
sender sets the Differentiated Services Code Point (DSCP) field
<xref target="RFC2475"></xref> 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 the between source and
destination.</t>
<t>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 to not 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.</t>
<t><xref target="I-D.ietf-dart-dscp-rtp"></xref> 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.</t>
</section>
<section anchor="QoS" title="QoS, Preprovisioned or Reserved Capacity">
<t>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.</t>
<t>Some UDP applications are only expected to be deployed over
network paths that use preprovisioned capacity or capacity reserved
using dynamic provisioning, e.g., through the Resource Reservation
Protocol (RSVP). Multicast applications are also used with
preprovisioned 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 chose this
option SHOULD carefully and in detail describe the provisioning and
management procedures that result in the desired containment.</t>
<t>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.</t>
<t>Applications designed for use within a controlled network
environment (see section <xref target="applicability"></xref> ) 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.,
<xref target="RFC7510"></xref>) To protect other applications
sharing the same path, applications SHOULD also deploy an
appropriate circuit breaker, as described in <xref
target="cb"></xref>.</t>
</section>
<section anchor="cb" title="Circuit Breaker Mechanisms">
<t>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 <xref
target="I-D.ietf-tsvwg-circuit-breaker"></xref>. 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.</t>
<t>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.</t>
<t><xref target="I-D.ietf-tsvwg-circuit-breaker"></xref> provides
guidance and examples on the use of circuit breakers. The use of a
circuit breaker in RTP is specified in <xref
target="I-D.ietf-avtcore-rtp-circuit-breakers"></xref>.</t>
<t>Applications used in the general Internet SHOULD implement a
transport circuit breaker if they do not implement congestion
control or operate a low volume data service (see <xref
target="applicability"></xref>). All applications MAY implement a
transport circuit breaker <xref
target="I-D.ietf-tsvwg-circuit-breaker"></xref> 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.</t>
</section>
<section anchor="tun" title="UDP Tunnels">
<t>One increasingly popular use of UDP is as a tunneling protocol
<xref target="I-D.ietf-intarea-tunnels"></xref>, 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. 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.</t>
<t>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 -receiving
applications. Because other flows can share the path with one or
more UDP tunnels, congestion control needs to be considered.</t>
<t>Two factors determine whether a UDP tunnel needs to employ
specific congestion control mechanisms -- first, whether the payload
traffic is IP-based; second, whether the tunneling scheme generates
UDP traffic at a volume that corresponds to the volume of payload
traffic carried within the tunnel.</t>
<t>IP-based traffic is generally assumed to be
congestion-controlled, i.e., it is assumed that the transport
protocols generating IP-based traffic at the sender already employ
mechanisms that are sufficient to address congestion on the path.
Consequently, a tunnel carrying IP-based traffic should already
interact appropriately with other traffic sharing the path, and
specific congestion control mechanisms for the tunnel are not
necessary.</t>
<t>However, if the IP traffic in the tunnel is known to not be
congestion-controlled, additional measures are RECOMMENDED to limit
the impact of the tunneled traffic on other traffic sharing the
path.</t>
<t>The following guidelines define these possible cases in more
detail:</t>
<t><list style="numbers">
<t>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.<vspace blankLines="1" />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.<vspace blankLines="1" />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.</t>
<t>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.<vspace blankLines="1" />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 <xref
target="unibt"></xref> apply.</t>
<t>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.<vspace blankLines="1" />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.</t>
</list></t>
<t>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 <xref
target="I-D.ietf-intarea-tunnels"></xref>).</t>
<t>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 <xref
target="I-D.ietf-intarea-tunnels"></xref>, e.g., handling
fragmentation and packet size, treatment of DSCP values, generating
and responding to ICMP messages, indication of payload type and
layering of tunnels, protection of headers, support for operations
and maintenance, etc. </t>
<t>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.</t>
<t><list style="symbols">
<t>Tunnels that carry or encapsulate using ECN code points MUST
follow the requirements specified in <xref
target="RFC6040"></xref>.</t>
<t><xref target="I-D.ietf-rtgwg-dt-encap"></xref> describes
encapsulation considerations in the design of tunnels.</t>
<t>Fragmentation requirements for all types of tunnel and the
requirements for MTU support are described in <xref
target="I-D.ietf-intarea-tunnels"></xref>.</t>
</list></t>
</section>
</section>
<section anchor="unimsg" title="Message Size Guidelines">
<t>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.</t>
<t>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, and instead choose to drop all fragments.
Finally, <xref target="RFC4963"></xref> documents other issues
specific to IPv4 fragmentation.</t>
<t>Due to these issues, an application SHOULD NOT send UDP datagrams
that result in IP packets that exceed the MTU of 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 itself <xref target="RFC1191"></xref><xref
target="RFC1981"></xref><xref target="RFC4821"></xref> 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) fail to forward ICMP messages. 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 reaching the UDP endpoint.</t>
<t>Packetization Layer Path MTU Discovery (PLPMTUD) <xref
target="RFC4821"></xref> does not rely upon network support for ICMP
messages and is therefore considered more robust than standard PMTUD.
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 updates not only the PMTU algorithm, it also
impacts loss recovery, congestion control, etc. These updated
mechanisms can be implemented within a connection-oriented transport
(e.g., TCP, SCTP, DCCP), but are not a part of UDP. PLPMTUD therefore
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
<xref target="tun"></xref>) as well as complicating the data path at a
tunnel decapsulator.</t>
<t>Applications that do not follow this recommendation to do PMTU
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
<xref target="RFC1122"></xref>). For IPv4, EMTU_S is the smaller of
576 bytes and the first-hop MTU <xref target="RFC1122"></xref>. For
IPv6, EMTU_S is 1280 bytes <xref target="RFC2460"></xref>. 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.</t>
<t>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 MSS, can
be obtained from the TCP/IP stack <xref target="RFC1122"></xref>.</t>
<t>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 <xref target="I-D.ietf-intarea-tunnels"></xref>, so
implementing PMTU discovery may be beneficial.</t>
<t>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.</t>
</section>
<section anchor="unirel" title="Reliability Guidelines">
<t>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.</t>
<t>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 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.</t>
<t>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.</t>
<t>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.</t>
<t>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. <xref target="RFC0793"></xref> 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.</t>
<t>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.</t>
</section>
<section anchor="unichk" title="Checksum Guidelines">
<t>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
<xref target="RFC3819"></xref>. 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.</t>
<t>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. It therefore 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 <xref
target="RFC6396"></xref>.</t>
<t>Applications SHOULD enable UDP checksums. For IPv4, <xref
target="RFC0768"></xref> permits an option to disable their use.</t>
<t>When UDP is used over IPv6, the UDP checksum is relied upon to
protect both the IPv6 and UDP headers from corruption, and MUST be
used as specified in <xref target="RFC2460"></xref>. <xref
target="RFC6935"></xref> 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 <xref target="RFC6936"></xref>.
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 <xref target="UDP-MPLS"></xref>). 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:</t>
<t><list style="symbols">
<t>Use of the UDP checksum with IPv6 MUST be the default
configuration for all implementations <xref
target="RFC6935"></xref>. The receiving endpoint MUST only allow
the use of UDP zero-checksum mode for IPv6 on a UDP destination
port that is specifically enabled.</t>
<t>An application that support a checksum different to that in
<xref target="RFC2460"></xref> MUST comply with all implementation
requirements specified in Section 4 of <xref
target="RFC6936"></xref> and with the usage requirements specified
in Section 5 of <xref target="RFC6936"></xref>.</t>
<t>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 <xref target="RFC6936"></xref>. </t>
<t>One way to help satisfy the requirements of <xref
target="RFC6936"></xref> may be to limit the usage (e.g., to
constrain traffic to an operator network <xref
target="applicability"></xref>, as in <xref
target="RFC7510"></xref>).</t>
</list></t>
<t>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.</t>
<t>IPv6 datagrams with a zero UDP checksum will not be passed by any
middlebox that validates the checksum based on <xref
target="RFC2460"></xref> 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 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.</t>
<section anchor="udplite" title="UDP-Lite">
<t>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) <xref target="RFC3828"></xref>
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 <xref
target="udpuni"></xref>.</t>
<t>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. Applications using UDP-Lite therefore MUST NOT make
assumptions regarding the correctness of the data received in the
insensitive part of the UDP-Lite payload.</t>
<t>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) <xref target="RFC3550"></xref>
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).</t>
<t>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 <xref target="RFC3828"></xref>. 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 may be negotiated by an application. UDP-Lite does not provide
mechanisms to negotiate the checksum coverage between the sender and
receiver. This therefore needs to be performed by the
application.</t>
<t>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 (<xref target="unimsg"></xref>).</t>
<t>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.</t>
</section>
</section>
<section anchor="nat" title="Middlebox Traversal Guidelines">
<t>Network address translators (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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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., <xref target="RFC7675"></xref>). 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.</t>
<t>An application that needs to employ keep-alives 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 <xref target="RFC4787"></xref>.
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 <xref target="RFC5245"></xref>. When an
application is deployed in a controlled network 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) <xref target="RFC6887"></xref>,
Middlebox Communications (MIDCOM) <xref target="RFC3303"></xref>, Next
Steps in Signaling (NSIS) <xref target="RFC5973"></xref>, or Universal
Plug and Play (UPnP) <xref target="UPnP"></xref>. 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 <xref target="RFC7675"></xref>.</t>
<t>Sending keep-alives is not a substitute for implementing a
mechanism to recover from broken sessions. Like all UDP datagrams,
keep-alives can be delayed or dropped, causing middlebox state to time
out. In addition, the congestion control guidelines in <xref
target="unicc"></xref> cover all UDP transmissions by an application,
including the transmission of middlebox keep-alives. Congestion
control may thus lead to delays or temporary suspension of keep-alive
transmission.</t>
<t>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-alives are sent can become the determining
factor that governs power consumption, depending on the underlying
network technology.</t>
<t>Because many middleboxes are designed to require keep-alives 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 <xref target="RFC5245"></xref>, 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.</t>
<t>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 <xref target="multi-flow"></xref> for recommendations on
usage of multiple ports).</t>
</section>
<section anchor="applicability"
title="Limited Applicability and Controlled Environments">
<t>Two different types of applicability have been identified for the
specification of IETF applications that utilize UDP:</t>
<t><list style="hanging">
<t hangText="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 tends to become used in a wider range of
contexts. For example, a protocol with an initial deployment
within a local area 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.</t>
<t hangText="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. 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.</t>
</list>Specifications addressing a limited applicability use case
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 <xref target="RFC7510"></xref>.)
Mechanisms also need to specify how to prevent this type of application
traffic from escaping to the public Internet.</t>
</section>
</section>
<section anchor="udpmcast" title="Multicast UDP Usage Guidelines">
<t>This section complements <xref target="udpuni"></xref> by providing
additional guidelines that are applicable to multicast and broadcast
usage of UDP.</t>
<t>Multicast and broadcast transmission <xref target="RFC1112"> </xref>
usually employ the UDP transport protocol, although they may be used
with other transport protocols (e.g., UDP-Lite).</t>
<t>There are currently two models of multicast delivery: the Any-Source
Multicast (ASM) model as defined in <xref target="RFC1112"></xref> and
the Source-Specific Multicast (SSM) model as defined in <xref
target="RFC4607"></xref>. 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.</t>
<t>Specialized classes of applications also use UDP for IP multicast or
broadcast <xref target="RFC0919"></xref>. 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.</t>
<t>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.</t>
<t>The IETF has defined a reliable multicast framework <xref
target="RFC3048"></xref> and several building blocks to aid the
designers of multicast applications, such as <xref
target="RFC3738"></xref> or <xref target="RFC4654"></xref>.</t>
<t>Anycast senders 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.</t>
<t>Most UDP tunnels that carry IP multicast traffic use a tunnel
encapsulation with a unicast destination address. These MUST follow the
same requirements as a tunnel carrying unicast data (see <xref
target="tun"></xref>). There are deployment cases and solutions where
the outer header of a UDP tunnel contains a multicast destination
address, such as <xref target="RFC6513"></xref>. These cases are
primarily deployed in controlled environments over reserved capacity,
often operating within a single administrative domain, or between two
domains over a bi-laterally 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).</t>
<section title="Multicast Congestion Control Guidelines">
<t>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 bi-directional
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.</t>
<t>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 were 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:<list
style="symbols">
<t>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., <xref target="RFC5740"></xref>,<xref
target="RFC4654"></xref>). 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).</t>
<t>Receiver-driven congestion control, which does not require a
receiver to send explicit UDP control messages for congestion
control (e.g., <xref target="RFC3738"></xref>, <xref
target="RFC5775"></xref>). 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.</t>
</list>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 there is no way at the transport layer to prevent a join message
propagating to the next-hop router.</t>
<t>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) or, if not, SHOULD use this signal
to provide a circuit breaker to terminate the flow by leaving the
multicast group.</t>
<section anchor="mcast-bulk"
title="Bulk Transfer Multicast Applications">
<t>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:
Asynchronous Layered Coding (ALC) <xref target="RFC5775"></xref>,
TCP-Friendly Multicast Congestion Control (TFMCC) <xref
target="RFC4654"></xref>, Wave and Equation Based Rate Control
(WEBRC) <xref target="RFC3738"></xref>, NACK-Oriented Reliable
Multicast (NORM) transport protocol <xref target="RFC5740"></xref>,
File Delivery over Unidirectional Transport (FLUTE) <xref
target="RFC6726"></xref>, Real Time Protocol/Control Protocol
(RTP/RTCP) <xref target="RFC3550"></xref>.</t>
<t>An application can alternatively implement another congestion
control schemes following the guidelines of <xref
target="RFC2887"></xref> and utilizing the framework of <xref
target="RFC3048"></xref>. Bulk transfer applications that choose not
to implement <xref target="RFC4654"></xref>, <xref
target="RFC5775"></xref>, <xref target="RFC3738"></xref>, <xref
target="RFC5740"></xref>, <xref target="RFC6726"></xref>, or <xref
target="RFC3550"></xref> SHOULD implement a congestion control
scheme that results in bandwidth use that competes fairly with TCP
within an order of magnitude.</t>
<t>Section 2 of <xref target="RFC3551"></xref> 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.</t>
</section>
<section anchor="Mcast-low"
title="Low Data-Volume Multicast Applications">
<t>All the recommendations in <xref target="unildr"></xref> are also
applicable to low data-volume multicast applications.</t>
</section>
</section>
<section anchor="MPMTU" title="Message Size Guidelines for Multicast">
<t>A multicast application SHOULD NOT send UDP datagrams that result
in IP packets that exceed the effective MTU as described in section 3
of <xref target="RFC6807"> </xref>. Consequently, an application
SHOULD either use the effective MTU information provided by the
Population Count Extensions to Protocol Independent Multicast <xref
target="RFC6807"></xref> or implement path MTU discovery itself (see
<xref target="unimsg"></xref>) to determine whether the path to each
destination will support its desired message size without
fragmentation.</t>
</section>
</section>
<section anchor="prog" title="Programming Guidelines">
<t>The de facto standard application programming interface (API) for
TCP/IP applications is the "sockets" interface <xref
target="POSIX"></xref>. 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.</t>
<t>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 <xref target="RFC3493"></xref>.
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. <xref
target="STEVENS"></xref> provides usage examples of the UDP sockets
API.</t>
<t>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.</t>
<t>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 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 <xref target="RFC1122"></xref>.</t>
<t>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 <xref target="RFC1122"></xref>,
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
<xref target="nat"></xref>.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<section anchor="ports" title="Using UDP Ports">
<t>The rules procedures for the management of the Service Name and
Transport Protocol Port Number Registry are specified in <xref
target="RFC6335"></xref>. Recommendations for use of UDP ports are
provided in <xref target="RFC7605"></xref>.</t>
<t>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.</t>
<t>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). </t>
<t>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 <xref
target="RFC6056"></xref>; 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 <xref target="RFC3550"></xref>).</t>
<t>When using multicast, IP routers perform a reverse-path forwarding
(RPF) check for each multicast packet. This provides protection from
off-path data injection. 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 a SSM {S,G}
channel.</t>
<t>The UDP source port number field has been used as a basis to design
load-balancing solutions for IPv4. This approach has also been
leveraged for IPv6 <xref target="RFC6438"></xref>, but for IPv6 the
"flow label" <xref target="RFC6437"></xref> may also be used as
entropy for load balancing. 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 <xref
target="RFC6437"></xref> and ECMP routing <xref
target="RFC6438"></xref> usage were specified. Router vendors are
encouraged to start using the 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.</t>
<section anchor="multi-flow"
title="Applications using Multiple UDP Ports">
<t>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). <xref
target="RFC6335"></xref> recommends application developers not to
apply to IANA to be assigned multiple well-known ports (user or
system). This 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).</t>
<t>Use of multiple flows can affect the network in several ways:</t>
<t><list style="symbols">
<t>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.</t>
<t>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).</t>
<t>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.</t>
<t>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.</t>
</list>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 <xref target="QoS"></xref>.</t>
</section>
</section>
<section anchor="icmp" title="ICMP Guidelines">
<t>Applications can utilize information about ICMP error messages that
the UDP layer passes up for a variety of purposes <xref
target="RFC1122"></xref>. 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.</t>
<t>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.</t>
<t>As mentioned above, ICMP messages are being increasingly filtered
by middleboxes. A UDP application therefore SHOULD NOT rely on their
delivery for correct and safe operation.</t>
</section>
</section>
<section anchor="seccons" title="Security Considerations">
<t>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.</t>
<t>UDP applications SHOULD provide protection from off-path data
injection attacks using a randomized source port or equivalent technique
(see <xref target="ports"></xref>).</t>
<t>Applications that respond to short requests with potentially large
responses are vulnerable to amplification attacks, and SHOULD
authenticate the sender before responding. The source IP address of a
request is not a useful authenticator, because it can easily be
spoofed.</t>
<t>One option for securing UDP communications is with IPsec <xref
target="RFC4301"></xref>, which can provide authentication for flows of
IP packets through the Authentication Header (AH) <xref
target="RFC4302"></xref> and encryption and/or authentication through
the Encapsulating Security Payload (ESP) <xref target="RFC4303"></xref>.
Applications use the Internet Key Exchange (IKE) <xref
target="RFC7296"></xref> 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.</t>
<t>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) <xref
target="RFC6347"></xref>. 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.</t>
<t>Many other options for authenticating or encrypting UDP payloads
exist. For example, the GSS-API security framework <xref
target="RFC2743"></xref> or Cryptographic Message Syntax (CMS) <xref
target="RFC5652"></xref> could be used to protect UDP payloads. There
exist a number of security options for RTP <xref
target="RFC3550"></xref> over UDP, especially to accomplish
key-management, see <xref target="RFC7201"></xref>. 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 <xref
target="RFC5652"></xref>, S/MIME <xref target="RFC5751"></xref> or
OpenPGP <xref target="RFC4880"></xref> could be used. In addition, there
are many non-IETF protocols in this area.</t>
<t>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.</t>
<t>The Generalized TTL Security Mechanism (GTSM) <xref
target="RFC5082"></xref> 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.</t>
<t>In terms of congestion control, <xref target="RFC2309"></xref> and
<xref target="RFC2914"></xref> discuss the dangers of
congestion-unresponsive flows to the Internet. <xref
target="I-D.ietf-tsvwg-circuit-breaker"></xref> 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.</t>
<t>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.</t>
<t>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
<xref target="RFC7675"></xref>. Applications that require communications
in two directions to implement protocol functions (such as reliability
or congestion control) will need to independently check both directions
of communication, and may have to exchange keep-alive packets to
traverse middleboxes (see <xref target="nat"></xref>).</t>
</section>
<section title="Summary">
<!-- XXX to be updated prior to publication XXX
-->
<t>This section summarizes the guidelines made in Sections <xref
format="counter" target="udpuni"></xref> and <xref format="counter"
target="seccons"></xref> in a tabular format (<xref
target="sumtable"></xref>) for easy referencing.</t>
<texttable anchor="sumtable" title="Summary of recommendations">
<ttcol>Recommendation</ttcol>
<ttcol>Section</ttcol>
<c>MUST tolerate a wide range of Internet path conditions</c>
<c><xref format="counter" target="udpuni"></xref></c>
<c>SHOULD use a full-featured transport (TCP, SCTP, DCCP)</c>
<c></c>
<c></c>
<c></c>
<c>SHOULD control rate of transmission</c>
<c><xref format="counter" target="unicc"></xref></c>
<c>SHOULD perform congestion control over all traffic</c>
<c></c>
<c></c>
<c></c>
<c>for bulk transfers,</c>
<c><xref format="counter" target="unibt"></xref></c>
<c>SHOULD consider implementing TFRC</c>
<c></c>
<c>else, SHOULD in other ways use bandwidth similar to TCP</c>
<c></c>
<c></c>
<c></c>
<c>for non-bulk transfers,</c>
<c><xref format="counter" target="unildr"></xref></c>
<c>SHOULD measure RTT and transmit max. 1 datagram/RTT</c>
<c></c>
<c>else, SHOULD send at most 1 datagram every 3 seconds</c>
<c></c>
<c>SHOULD back-off retransmission timers following loss</c>
<c></c>
<c></c>
<c></c>
<c>SHOULD provide mechanisms to regulate the bursts of
transmission</c>
<c><xref format="counter" target="uniburst"></xref></c>
<c></c>
<c></c>
<c>MAY implement ECN; a specific set of application mechanisms are
REQUIRED if ECN is used.</c>
<c><xref format="counter" target="ECN"></xref></c>
<c></c>
<c></c>
<c>for DiffServ, SHOULD NOT rely on implementation of PHBs</c>
<c><xref format="counter" target="unids"></xref></c>
<c></c>
<c></c>
<c>for QoS-enabled paths, MAY choose not to use CC</c>
<c><xref format="counter" target="QoS"></xref></c>
<c></c>
<c></c>
<c>SHOULD NOT rely solely on QoS for their capacity</c>
<c><xref format="counter" target="cb"></xref></c>
<c>non-CC controlled flows SHOULD implement a transport circuit
breaker</c>
<c></c>
<c>MAY implement a circuit breaker for other applications</c>
<c></c>
<c></c>
<c></c>
<c>for tunnels carrying IP Traffic,</c>
<c><xref format="counter" target="tun"></xref></c>
<c>SHOULD NOT perform congestion control</c>
<c></c>
<c>MUST correctly process the IP ECN field</c>
<c></c>
<c></c>
<c></c>
<c>for non-IP tunnels or rate not determined by traffic,</c>
<c></c>
<c>SHOULD perform CC or use circuit breaker</c>
<c><xref format="counter" target="tun"></xref></c>
<c>SHOULD restrict types of traffic transported by the tunnel</c>
<c></c>
<c></c>
<c></c>
<c>SHOULD NOT send datagrams that exceed the PMTU, i.e.,</c>
<c><xref format="counter" target="unimsg"></xref></c>
<c>SHOULD discover PMTU or send datagrams < minimum PMTU; Specific
application mechanisms are REQUIRED if PLPMTUD is used.</c>
<c></c>
<c></c>
<c></c>
<c>SHOULD handle datagram loss, duplication, reordering</c>
<c><xref format="counter" target="unirel"></xref></c>
<c>SHOULD be robust to delivery delays up to 2 minutes</c>
<c></c>
<c></c>
<c></c>
<c>SHOULD enable IPv4 UDP checksum</c>
<c><xref format="counter" target="unichk"></xref></c>
<c>SHOULD enable IPv6 UDP checksum; Specific application mechanisms
are REQUIRED if a zero IPv6 UDP checksum is used.</c>
<c></c>
<c></c>
<c></c>
<c>SHOULD provide protection from off-path attacks</c>
<c><xref format="counter" target="ports"></xref></c>
<c>else, MAY use UDP-Lite with suitable checksum coverage</c>
<c><xref format="counter" target="udplite"></xref></c>
<c></c>
<c></c>
<c>SHOULD NOT always send middlebox keep-alives</c>
<c><xref format="counter" target="nat"></xref></c>
<c>MAY use keep-alives when needed (min. interval 15 sec)</c>
<c></c>
<c></c>
<c></c>
<c>Bulk multicast apps SHOULD implement congestion control</c>
<c><xref format="counter" target="mcast-bulk"></xref></c>
<c></c>
<c></c>
<c>Low volume multicast apps SHOULD implement congestion control</c>
<c><xref format="counter" target="Mcast-low"></xref></c>
<c></c>
<c></c>
<c>Multicast apps SHOULD use a safe PMTU</c>
<c><xref format="counter" target="MPMTU"></xref></c>
<c></c>
<c></c>
<c>SHOULD avoid using multiple ports</c>
<c><xref format="counter" target="ports"></xref></c>
<c>MUST check received IP source address</c>
<c></c>
<c></c>
<c></c>
<c>SHOULD use a randomized source port or equivalent technique, and,
for client/server applications, SHOULD send responses from source
address matching request</c>
<c><xref format="counter" target="icmp"></xref></c>
<c></c>
<c></c>
<c>SHOULD validate payload in ICMP messages</c>
<c><xref format="counter" target="icmp"></xref></c>
<c></c>
<c></c>
<c>SHOULD use standard IETF security protocols when needed</c>
<c><xref format="counter" target="seccons"></xref></c>
</texttable>
<t></t>
</section>
<section title="IANA Considerations">
<t>Note to RFC-Editor: please remove this entire section prior to
publication.</t>
<t>This document raises no IANA considerations.</t>
</section>
<section anchor="ack" title="Acknowledgments">
<t>The middlebox traversal guidelines in <xref target="nat"></xref>
incorporate ideas from Section 5 of <xref
target="I-D.ford-behave-app"></xref> by Bryan Ford, Pyda Srisuresh, and
Dan Kegel. 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.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC0768;
&RFC0793;
&RFC1122;
&RFC1191;
&RFC1981;
&RFC2119;
&RFC2460;
&RFC2914;
&RFC3828;
&RFC4787;
&RFC4821;
&RFC5348;
&RFC5405;
&RFC6040;
&RFC6298;
&I-D.ietf-tsvwg-circuit-breaker;
</references>
<references title="Informative References">
&RFC0896;
&RFC0919;
&RFC1112;
&RFC1536;
&RFC1546;
&RFC2309;
&RFC2475;
&RFC2675;
&RFC2743;
&RFC2887;
&RFC3048;
&RFC3124;
&RFC3168;
&RFC3261;
&RFC3303;
&RFC3493;
&RFC3550;
&RFC3551;
&RFC7201;
&RFC3738;
&RFC3758;
&RFC3819;
&RFC4301;
&RFC4302;
&RFC4303;
&RFC4340;
&RFC4341;
&RFC4342;
&RFC4607;
&RFC4654;
&RFC4880;
&RFC4960;
&RFC4963;
&RFC4987;
&RFC5082;
&RFC5245;
&RFC5622;
&RFC5652;
&RFC5740;
&RFC5751;
&RFC5775;
<!--&RFC5885;-->
&RFC5971;
&RFC5973;
&RFC7296;
&RFC6335;
&RFC6347;
<!-- &RFC6395; -->
&RFC6396;
&RFC6437;
&RFC6438;
&RFC6513;
&RFC6679;
&RFC6726;
&RFC6807;
&RFC6056;
&RFC6887;
&RFC6936;
&RFC6935;
&I-D.ietf-aqm-ecn-benefits;
&I-D.ford-behave-app;
&RFC7605;
&I-D.ietf-avtcore-rtp-circuit-breakers;
&RFC7143;
&RFC7510;
&I-D.ietf-dart-dscp-rtp;
&I-D.ietf-rtgwg-dt-encap;
&RFC7560;
&RFC7675;
&I-D.ietf-intarea-tunnels;
<reference anchor="POSIX">
<front>
<title>Standard for Information Technology - Portable Operating
System Interface (POSIX)</title>
<author initials="" surname="IEEE Std. 1003.1-2001">
<organization></organization>
</author>
<date month="December" year="2001" />
</front>
<seriesInfo name="Open Group Technical Standard: Base Specifications"
value="Issue 6, ISO/IEC 9945:2002" />
</reference>
<reference anchor="ALLMAN">
<front>
<title>Notes on burst mitigation for transport protocols</title>
<author initials="M" surname="Allman"></author>
<author initials="E" surname="Blanton"></author>
<date month="March" year="2005" />
</front>
</reference>
<reference anchor="STEVENS">
<front>
<title>UNIX Network Programming, The sockets Networking API</title>
<author initials="W. R." surname="Stevens">
<organization></organization>
</author>
<author initials="B." surname="Fenner">
<organization></organization>
</author>
<author initials="A. M." surname="Rudoff">
<organization></organization>
</author>
<date month="Addison-Wesley," year="2004" />
</front>
</reference>
<reference anchor="UPnP">
<front>
<title>Internet Gateway Device (IGD) Standardized Device Control
Protocol V 1.0</title>
<author surname="UPnP Forum">
<organization></organization>
</author>
<date month="November" year="2001" />
</front>
</reference>
<reference anchor="FABER">
<front>
<title>The TIME-WAIT State in TCP and Its Effect on Busy
Servers</title>
<author initials="T." surname="Faber">
<organization></organization>
</author>
<author initials="J." surname="Touch">
<organization></organization>
</author>
<author initials="W." surname="Yue">
<organization></organization>
</author>
<date month="March" year="1999" />
</front>
<seriesInfo name="Proc." value="IEEE Infocom" />
</reference>
</references>
<section anchor="UDP-MPLS"
title="Case Study of the Use of IPv6 UDP Zero-Checksum Mode">
<t>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.</t>
<t>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 <xref target="RFC7510"></xref>, and
defines a set of operational constraints for use of this mode. These are
summarized below:</t>
<t>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 co-operating 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.</t>
<t>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) <xref
target="RFC7510"></xref>.</t>
<t>MPLS-in-UDP endpoints must 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.</t>
<t>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 <xref
target="RFC6936"></xref>.</t>
<t>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 <xref target="RFC6936"></xref>.
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 as 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 <xref target="RFC6936"></xref>. In addition,
IPv6 traffic with a zero UDP checksum MUST be actively monitored for
errors by the network operator.</t>
<t>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.</t>
</section>
<section title="Revision Notes">
<t>Note to RFC-Editor: please remove this entire section prior to
publication.</t>
<t>Changes in draft-ietf-tsvwg-rfc5405bis-07:</t>
<t>This update introduces new text in the following sections:</t>
<t><list style="symbols">
<t>Addressed David Black's review during WG LC.</t>
</list></t>
<t>Changes in draft-ietf-tsvwg-rfc5405bis-06:</t>
<t>This update introduces new text in the following sections:</t>
<t><list style="symbols">
<t>Multicast Congestion Control Guidelines (Section rewritten by
Greg and Gorry to differentiate sender-driven and receiver-driven
CC)</t>
<t>Using UDP Ports (Added a short para on RPF checks protecting from
off-path attacks)</t>
<t>Applications using Multiple UDP Ports (Added text on layered
multicast)</t>
</list></t>
<t>Changes in draft-ietf-tsvwg-rfc5405bis-05:</t>
<t><list style="symbols">
<t>Amended text in section discussing RTT for CC (feedback from
Colin)</t>
</list></t>
<t>Changes in draft-ietf-tsvwg-rfc5405bis-04:</t>
<t><list style="symbols">
<t>Added text on consent freshness (STUN) - (From Colin)</t>
<t>Reworked text on ECN (From David)</t>
<t>Reworked text on RTT with CC (with help from Mirja)</t>
<t>Added references to <xref target="RFC7675"></xref>, <xref
target="I-D.ietf-rtgwg-dt-encap"></xref>, <xref
target="I-D.ietf-intarea-tunnels"></xref> and <xref
target="RFC7510"></xref></t>
</list></t>
<t>Changes in draft-ietf-tsvwg-rfc5405bis-03:</t>
<t><list style="symbols">
<t>Mention crypto hash in addition to CRC for integrity protection.
(From Magnus.)</t>
<t>Mention PCP. (From Magnus.)</t>
<t>More accurate text on secure RTP (From Magnus.)</t>
<t>Reordered abstract to reflect .bis focus (Gorry)</t>
<t>Added a section on ECN, with actual ECN requirements (Gorry, help
from Mirja)</t>
<t>Added section on Implications of RTT on Congestion Control
(Gorry)</t>
<t>Added note that this refers to other protocols over IP (E
Nordmark, rtg encaps guidance)</t>
<t>Added reordering text between sessions (consistent with use of
ECMP, rtg encaps guidance)</t>
<t>Reworked text on off-path data protection (port usage)</t>
<t>Updated summary table</t>
</list></t>
<t>Changes in draft-ietf-tsvwg-rfc5405bis-02:</t>
<t><list style="symbols">
<t>Added note that guidance may be applicable beyond UDP to abstract
(from Erik Nordmark).</t>
<t>Small editorial changes to fix English nits.</t>
<t>Added a circuit may provide benefit to CC tunnels by controlling
envelope.</t>
<t>Added tunnels should ingress-filter by packet type (from Erik
Nordmark).</t>
<t>Added tunnels should perform IETF ECN processing when supporting
ECN.</t>
<t>Multicast apps may employ CC or a circuit breaker.</t>
<t>Added programming guidance on off-path attacks (with C.
Perkins).</t>
<t>Added reference to ECN benefits.</t>
</list></t>
<t>Changes in draft-ietf-tsvwg-rfc5405bis-01:</t>
<t><list style="symbols">
<t>Added text on DSCP-usage.</t>
<t>More guidance on use of the checksum, including an example of how
MPLS/UDP allowed support of a zero IPv6 UDP Checksum in some
cases.</t>
<t>Added description of diffuse usage.</t>
<t>Clarified usage of the source port field.</t>
</list></t>
<t>draft-eggert-tsvwg-rfc5405bis-01 was adopted by the TSVWG and
resubmitted as draft-ietf-tsvwg-rfc5405bis-00. There were no technical
changes.</t>
<t>Changes in draft-eggert-tsvwg-rfc5405bis-01:</t>
<t><list style="symbols">
<t>Added Greg Shepherd as a co-author, based on the multicast
guidelines that originated with him.</t>
</list></t>
<t>Changes in draft-eggert-tsvwg-rfc5405bis-00 (relative to
RFC5405):</t>
<t><list style="symbols">
<t>The words "application designers" were removed from the draft
title and the wording of the abstract was clarified abstract.</t>
<t>New text to clarify various issues and set new recommendations
not previously included in RFC 5405. These include new
recommendations for multicast, the use of checksums with IPv6, ECMP,
recommendations on port usage, use of ECN, use of DiffServ, circuit
breakers (initial text), etc.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:21:45 |