doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc5405.txt b/doc/rfc/rfc5405.txt
new file mode 100644
index 0000000..78fe2f2
--- /dev/null
+++ b/doc/rfc/rfc5405.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                                          L. Eggert
+Request for Comments: 5405                                         Nokia
+BCP: 145                                                    G. Fairhurst
+Category: Best Current Practice                   University of Aberdeen
+                                                           November 2008
+
+
+         Unicast UDP Usage Guidelines for Application Designers
+
+Status of This Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2008 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents (http://trustee.ietf.org/
+   license-info) in effect on the date of publication of this document.
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   The User Datagram Protocol (UDP) provides a minimal message-passing
+   transport that has no inherent congestion control mechanisms.
+   Because congestion control is critical to the stable operation of the
+   Internet, applications and upper-layer 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.  This document provides guidelines on the use of
+   UDP for the designers of unicast applications and upper-layer
+   protocols.  Congestion control guidelines are a primary focus, but
+   the document also provides guidance on other topics, including
+   message sizes, reliability, checksums, and middlebox traversal.
+
+
+
+
+
+
+
+
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                  [Page 1]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.  UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . .  5
+     3.1.  Congestion Control Guidelines  . . . . . . . . . . . . . .  6
+     3.2.  Message Size Guidelines  . . . . . . . . . . . . . . . . . 11
+     3.3.  Reliability Guidelines . . . . . . . . . . . . . . . . . . 12
+     3.4.  Checksum Guidelines  . . . . . . . . . . . . . . . . . . . 13
+     3.5.  Middlebox Traversal Guidelines . . . . . . . . . . . . . . 15
+     3.6.  Programming Guidelines . . . . . . . . . . . . . . . . . . 17
+     3.7.  ICMP Guidelines  . . . . . . . . . . . . . . . . . . . . . 18
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
+   5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 23
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                  [Page 2]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+1.  Introduction
+
+   The User Datagram Protocol (UDP) [RFC0768] provides a minimal,
+   unreliable, best-effort, message-passing transport to applications
+   and upper-layer protocols (both simply called "applications" in the
+   remainder of this document).  Compared to other transport protocols,
+   UDP and its UDP-Lite variant [RFC3828] are unique in that they do not
+   establish end-to-end connections between communicating end systems.
+   UDP communication consequently does not incur connection
+   establishment and teardown overheads, and there is minimal associated
+   end system state.  Because of these characteristics, UDP can offer a
+   very efficient communication transport to some applications.
+
+   A second unique characteristic of UDP is that it provides no inherent
+   congestion control mechanisms.  On many platforms, applications can
+   send UDP datagrams at the line rate of the link interface, which is
+   often much greater than the available path capacity, and doing so
+   contributes to congestion along the path.  [RFC2914] 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:
+
+   1.  The prevention of congestion collapse, i.e., a state where an
+       increase in network load results in a decrease in useful work
+       done by the network.
+
+   2.  The establishment of a degree of fairness, i.e., allowing
+       multiple flows to share the capacity of a path reasonably
+       equitably.
+
+   Because UDP itself provides no congestion control mechanisms, it is
+   up to the applications that use UDP for Internet communication to
+   employ suitable mechanisms to prevent congestion collapse and
+   establish a degree of fairness.  [RFC2309] discusses the dangers of
+   congestion-unresponsive flows and states that "all UDP-based
+   streaming applications should incorporate effective congestion
+   avoidance mechanisms".  This is an important requirement, even for
+   applications that do not use UDP for streaming.  In addition,
+   congestion-controlled transmission is of benefit to an application
+   itself, because it can reduce self-induced packet loss, minimize
+   retransmissions, and hence reduce delays.  Congestion control is
+   essential even at relatively slow transmission rates.  For example,
+   an application that generates five 1500-byte UDP datagrams in one
+   second can already exceed the capacity of a 56 Kb/s path.  For
+   applications that can operate at higher, potentially unbounded data
+   rates, congestion control becomes vital to prevent congestion
+   collapse and establish some degree of fairness.  Section 3 describes
+   a number of simple guidelines for the designers of such applications.
+
+
+
+Eggert & Fairhurst       Best Current Practice                  [Page 3]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   A UDP datagram is carried in a single IP packet and is hence limited
+   to a maximum payload of 65,507 bytes for IPv4 and 65,527 bytes for
+   IPv6.  The transmission of large IP packets usually requires IP
+   fragmentation.  Fragmentation decreases communication reliability and
+   efficiency and should be avoided.  IPv6 allows the option of
+   transmitting large packets ("jumbograms") without fragmentation when
+   all link layers along the path support this [RFC2675].  Some of the
+   guidelines in Section 3 describe how applications should determine
+   appropriate message sizes.  Other sections of this document provide
+   guidance on reliability, checksums, and middlebox traversal.
+
+   This document provides guidelines and recommendations.  Although most
+   unicast 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 the application designers document the rationale for their
+   design choice in the technical specification of their application or
+   protocol.
+
+   This document provides guidelines to designers of applications that
+   use UDP for unicast transmission, which is the most common case.
+   Specialized classes of applications use UDP for IP multicast
+   [RFC1112], broadcast [RFC0919], or anycast [RFC1546] transmissions.
+   The design of such specialized applications requires expertise that
+   goes beyond the simple, unicast-specific guidelines given in this
+   document.  Multicast and broadcast senders may transmit to multiple
+   receivers across potentially very heterogeneous paths at the same
+   time, which significantly complicates congestion control, flow
+   control, and reliability mechanisms.  The IETF has defined a reliable
+   multicast framework [RFC3048] and several building blocks to aid the
+   designers of multicast applications, such as [RFC3738] or [RFC4654].
+   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.  It is not
+   intended that the guidelines in this document apply to multicast,
+   broadcast, or anycast applications that use UDP.
+
+   Finally, although this document specifically refers to unicast
+   applications that use 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 or control applications
+   that choose to run directly over IP by registering their own IP
+   protocol number with IANA.  This document may provide useful
+   background reading to the designers of such applications and
+   protocols.
+
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                  [Page 4]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+3.  UDP Usage Guidelines
+
+   Internet paths can have widely varying characteristics, including
+   transmission delays, available bandwidths, congestion levels,
+   reordering probabilities, supported message sizes, or loss rates.
+   Furthermore, the same Internet path can have very different
+   conditions over time.  Consequently, applications that may be used on
+   the Internet MUST NOT make assumptions about specific path
+   characteristics.  They MUST instead use mechanisms that let them
+   operate safely under very different path conditions.  Typically, this
+   requires conservatively probing the current conditions of the
+   Internet path they communicate over to establish a transmission
+   behavior that it can sustain and that is reasonably fair to other
+   traffic sharing the path.
+
+   These mechanisms are difficult to implement correctly.  For most
+   applications, the use of one of the existing IETF transport protocols
+   is the simplest method of acquiring the required mechanisms.
+   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 [RFC0793], Stream Control Transmission Protocol
+   (SCTP) [RFC4960], and SCTP Partial Reliability Extension (SCTP-PR)
+   [RFC3758], or Datagram Congestion Control Protocol (DCCP) [RFC4340]
+   with its different congestion control types
+   [RFC4341][RFC4342][CCID4].
+
+   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
+   [RFC0896] can be disabled, improving communication latency at the
+   expense of more frequent -- but still congestion-controlled -- packet
+   transmissions.  Another example is the TCP SYN cookie mechanism
+   [RFC4987], which is available on many platforms.  TCP with SYN
+   cookies does not require a server to maintain per-connection state
+   until the connection is established.  TCP also requires the end that
+   closes a connection to maintain the TIME-WAIT state that prevents
+   delayed segments from one connection instance from interfering with a
+
+
+
+Eggert & Fairhurst       Best Current Practice                  [Page 5]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   later one.  Applications that are aware of and designed for this
+   behavior can shift maintenance of the TIME-WAIT state to conserve
+   resources by controlling which end closes a TCP connection [FABER].
+   Finally, TCP's built-in capacity-probing and awareness of the maximum
+   transmission unit supported by the path (PMTU) results in efficient
+   data transmission that quickly compensates for the initial connection
+   setup delay, in the case of transfers that exchange more than a few
+   segments.
+
+3.1.  Congestion Control Guidelines
+
+   If an application or upper-layer protocol chooses not to use a
+   congestion-controlled transport protocol, it SHOULD control the rate
+   at which it sends UDP datagrams to a destination host, in order to
+   fulfill the requirements of [RFC2914].  It is important to stress
+   that an application SHOULD perform congestion control over all UDP
+   traffic it sends to a destination, independently from how it
+   generates this traffic.  For example, an application that forks
+   multiple worker processes or otherwise uses multiple sockets to
+   generate UDP datagrams SHOULD perform congestion control over the
+   aggregate traffic.
+
+   Several approaches to perform congestion control are discussed in the
+   remainder of this section.  Not all approaches discussed below are
+   appropriate for all UDP-transmitting applications.  Section 3.1.1
+   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, in order to determine a sending rate that the path at its
+   current load can support.  Other applications only exchange a few UDP
+   datagrams with a destination.  Section 3.1.2 discusses congestion
+   control options for such "low data-volume" applications.  Because
+   they typically do not transmit enough data to iteratively sample the
+   path to determine a safe sending rate, they need to employ different
+   kinds of congestion control mechanisms.  Section 3.1.3 discusses
+   congestion control considerations when UDP is used as a tunneling
+   protocol.
+
+   It is important to note that congestion control should not be viewed
+   as an add-on to a finished application.  Many of the mechanisms
+   discussed in the guidelines below require application support to
+   operate correctly.  Application designers need to consider congestion
+   control throughout the design of their application, similar to how
+   they consider security aspects throughout the design process.
+
+   In the past, the IETF has also investigated integrated congestion
+   control mechanisms that act on the traffic aggregate between two
+   hosts, i.e., a framework such as the Congestion Manager [RFC3124],
+
+
+
+Eggert & Fairhurst       Best Current Practice                  [Page 6]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   where active sessions may share current congestion information in a
+   way that is independent of the transport protocol.  Such mechanisms
+   have currently failed to see deployment, but would otherwise simplify
+   the design of congestion control mechanisms for UDP sessions, so that
+   they fulfill the requirements in [RFC2914].
+
+3.1.1.  Bulk Transfer Applications
+
+   Applications that perform bulk transmission of data to a peer over
+   UDP, i.e., applications that exchange more than a small number of UDP
+   datagrams per RTT, SHOULD implement TCP-Friendly Rate Control (TFRC)
+   [RFC5348], window-based, TCP-like congestion control, or otherwise
+   ensure that the application complies with the congestion control
+   principles.
+
+   TFRC has been designed to provide both congestion control and
+   fairness in a way that is compatible with the IETF's other transport
+   protocols.  If an application implements TFRC, it need not follow the
+   remaining guidelines in Section 3.1.1, because TFRC already addresses
+   them, but SHOULD still follow the remaining guidelines in the
+   subsequent subsections of Section 3.
+
+   Bulk transfer applications that choose not to implement TFRC or TCP-
+   like windowing SHOULD implement a congestion control scheme that
+   results in bandwidth use that competes fairly with TCP within an
+   order of magnitude.  Section 2 of [RFC3551] suggests that
+   applications SHOULD monitor the packet loss rate to ensure that it is
+   within acceptable parameters.  Packet loss is considered acceptable
+   if a TCP flow across the same network path under the same network
+   conditions would achieve an average throughput, measured on a
+   reasonable timescale, that is not less than that of the UDP flow.
+   The comparison to TCP cannot be specified exactly, but is intended as
+   an "order-of-magnitude" comparison in timescale and throughput.
+
+   Finally, some bulk transfer applications may choose not to implement
+   any congestion control mechanism and instead rely on transmitting
+   across reserved path capacity.  This might be an acceptable choice
+   for a subset of restricted networking environments, but is by no
+   means a safe practice for operation in the Internet.  When the UDP
+   traffic of such applications leaks out on 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.
+
+
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                  [Page 7]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+3.1.2.  Low Data-Volume Applications
+
+   When applications that at any time exchange only a small number of
+   UDP datagrams with a destination implement TFRC or one of the other
+   congestion control schemes in Section 3.1.1, the network sees little
+   benefit, because those mechanisms perform congestion control in a way
+   that is only effective for longer transmissions.
+
+   Applications that at any time exchange only a small number of 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 [RFC1536], an application SHOULD maintain an
+   estimate of the RTT for any destination with which it communicates.
+   Applications SHOULD implement the algorithm specified in [RFC2988] to
+   compute a smoothed RTT (SRTT) estimate.  They SHOULD also detect
+   packet loss and exponentially back-off their retransmission timer
+   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 uses an initial value of 3 seconds [RFC2988],
+   which is also RECOMMENDED as an initial value for UDP applications.
+   SIP [RFC3261] and GIST [GIST] 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
+   [RFC2988] yields timeout values after a series of losses that are
+   much longer than the initial value.
+
+   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 [RFC2988], which is
+   also RECOMMENDED as an initial value for UDP applications.  SIP
+   [RFC3261] and GIST [GIST] 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.
+
+   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 [RFC2988], and shorter values are
+   likely problematic in many cases.  Note that the sending rate in this
+
+
+
+Eggert & Fairhurst       Best Current Practice                  [Page 8]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   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 events, and the application therefore cannot
+   perform exponential back-off to reduce load.
+
+   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.
+
+3.1.3.  UDP Tunnels
+
+   One increasingly popular use of UDP is as a tunneling protocol, 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.
+
+   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.
+
+   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.
+
+   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
+
+
+
+Eggert & Fairhurst       Best Current Practice                  [Page 9]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   IP-based traffic should already interact appropriately with other
+   traffic sharing the path, and specific congestion control mechanisms
+   for the tunnel are not necessary.
+
+   However, if the IP traffic in the tunnel is known to not be
+   congestion-controlled, additional measures are RECOMMENDED in order
+   to limit the impact of the tunneled traffic on other traffic sharing
+   the path.
+
+   The following guidelines define these possible cases in more detail:
+
+   1.  A tunnel generates UDP traffic at a volume that corresponds to
+       the volume of payload traffic, and the payload traffic is IP-
+       based and congestion-controlled.
+
+       This is arguably the most common case for Internet tunnels.  In
+       this case, the UDP tunnel SHOULD NOT employ its own congestion
+       control mechanism, because congestion losses of tunneled traffic
+       will already trigger an appropriate congestion response at the
+       original senders of the tunneled traffic.
+
+       Note that this guideline is built on the assumption that most IP-
+       based communication is congestion-controlled.  If a UDP tunnel is
+       used for IP-based traffic that is known to not be congestion-
+       controlled, the next set of guidelines applies.
+
+   2.  A tunnel generates UDP traffic at a volume that corresponds to
+       the volume of payload traffic, and the payload traffic is not
+       known to be IP-based, or is known to be IP-based but not
+       congestion-controlled.
+
+       This can be the case, for example, when some link-layer protocols
+       are encapsulated within UDP (but not all link-layer protocols;
+       some are congestion-controlled).  Because it is not known that
+       congestion losses of tunneled non-IP traffic will trigger an
+       appropriate congestion response at the senders, the UDP tunnel
+       SHOULD employ an appropriate congestion control mechanism.
+       Because tunnels are usually bulk-transfer applications as far as
+       the intermediate routers are concerned, the guidelines in
+       Section 3.1.1 apply.
+
+   3.  A tunnel generates UDP traffic at a volume that does not
+       correspond to the volume of payload traffic, independent of
+       whether the payload traffic is IP-based or congestion-controlled.
+
+       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
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 10]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+       Correction is used, or are otherwise constrained 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.
+
+   Designing a tunneling mechanism requires significantly more expertise
+   than needed for many other UDP applications, because tunnels
+   virtualize lower-layer components of the Internet, and the
+   virtualized components need to correctly interact with the
+   infrastructure at that layer.  This document only touches upon the
+   congestion control considerations for implementing UDP tunnels; a
+   discussion of other required tunneling behavior is out of scope.
+
+3.2.  Message Size Guidelines
+
+   IP fragmentation lowers the efficiency and reliability of Internet
+   communication.  The loss of a single fragment results in the loss of
+   an entire fragmented packet, because even if all other fragments are
+   received correctly, the original packet cannot be reassembled and
+   delivered.  This fundamental issue with fragmentation exists for both
+   IPv4 and IPv6.  In addition, some network address translators (NATs)
+   and firewalls drop IP fragments.  The network address translation
+   performed by a NAT only operates on complete IP packets, and some
+   firewall policies also require inspection of complete IP packets.
+   Even with these being the case, some NATs and firewalls simply do not
+   implement the necessary reassembly functionality, and instead choose
+   to drop all fragments.  Finally, [RFC4963] documents other issues
+   specific to IPv4 fragmentation.
+
+   Due to these issues, an application SHOULD NOT send UDP datagrams
+   that result in IP packets that exceed the 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 [RFC1191][RFC1981][RFC4821] to determine whether the
+   path to a destination will support its desired message size without
+   fragmentation.
+
+   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 [RFC1122]).  For IPv4, EMTU_S is the smaller of 576 bytes and the
+   first-hop MTU [RFC1122].  For IPv6, EMTU_S is 1280 bytes [RFC2460].
+   The effective PMTU for a directly connected destination (with no
+   routers on the path) is the configured interface MTU, which could be
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 11]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   less than the maximum link payload size.  Transmission of minimum-
+   sized UDP datagrams is inefficient over paths that support a larger
+   PMTU, which is a second reason to implement PMTU discovery.
+
+   To determine an appropriate UDP payload size, applications MUST
+   subtract the size of the IP header (which includes any IPv4 optional
+   headers or IPv6 extension headers) as well as the length of the UDP
+   header (8 bytes) from the PMTU size.  This size, known as the MMS_S,
+   can be obtained from the TCP/IP stack [RFC1122].
+
+   Applications that do not send messages that exceed the effective PMTU
+   of IPv4 or IPv6 need not implement any of the above mechanisms.  Note
+   that the presence of tunnels can cause an additional reduction of the
+   effective PMTU, so implementing PMTU discovery may be beneficial.
+
+   Applications that fragment an application-layer message into multiple
+   UDP datagrams SHOULD perform this fragmentation so that each datagram
+   can be received independently, and be independently retransmitted in
+   the case where an application implements its own reliability
+   mechanisms.
+
+3.3.  Reliability Guidelines
+
+   Application designers are generally aware that UDP does not provide
+   any reliability, e.g., it does not retransmit any lost packets.
+   Often, this is a main reason to consider UDP as a transport.
+   Applications that do require reliable message delivery MUST implement
+   an appropriate mechanism themselves.
+
+   UDP also does not protect against datagram duplication, i.e., an
+   application may receive multiple copies of the same UDP datagram.
+   Application designers SHOULD verify that their application handles
+   datagram duplication gracefully, and may consequently need to
+   implement mechanisms to detect duplicates.  Even if UDP datagram
+   reception triggers idempotent operations, applications may want to
+   suppress duplicate datagrams to reduce load.
+
+   In addition, the Internet can significantly delay some packets with
+   respect to others, e.g., due to routing transients, intermittent
+   connectivity, or mobility.  This can cause reordering, where UDP
+   datagrams arrive at the receiver in an order different from the
+   transmission order.  Applications that require ordered delivery MUST
+   reestablish datagram ordering themselves.
+
+   Finally, it is important to note that delay spikes can be very large.
+   This can cause reordered packets to arrive many seconds after they
+   were sent.  [RFC0793] defines the maximum delay a TCP segment should
+   experience -- the Maximum Segment Lifetime (MSL) -- as 2 minutes.  No
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 12]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   other RFC defines an MSL for other transport protocols or IP itself.
+   This document clarifies that the MSL value to be used for UDP SHOULD
+   be the same 2 minutes as for TCP.  Applications SHOULD be robust to
+   the reception of delayed or duplicate packets that are received
+   within this 2-minute interval.
+
+   An application that requires reliable and ordered message delivery
+   SHOULD choose an IETF standard transport protocol that provides these
+   features.  If this is not possible, it will need to implement a set
+   of appropriate mechanisms itself.
+
+3.4.  Checksum Guidelines
+
+   The UDP header includes an optional, 16-bit one's complement checksum
+   that provides an integrity check.  This results in a relatively weak
+   protection in terms of coding theory [RFC3819], and application
+   developers SHOULD implement additional checks where data integrity is
+   important, e.g., through a Cyclic Redundancy Check (CRC) included
+   with the data to verify the integrity of an entire object/file sent
+   over the UDP service.
+
+   The UDP checksum provides a statistical guarantee that the payload
+   was not corrupted in transit.  It also allows the receiver to verify
+   that it was the intended destination of the packet, because it covers
+   the IP addresses, port numbers, and protocol number, and it verifies
+   that the packet is not truncated or padded, because it covers the
+   size field.  It therefore protects an application against receiving
+   corrupted payload data in place of, or in addition to, the data that
+   was sent.  This check is not strong from a coding or cryptographic
+   perspective, and is not designed to detect physical-layer errors or
+   malicious modification of the datagram [RFC3819].
+
+   Applications SHOULD enable UDP checksums, although [RFC0768] permits
+   the option to disable their use.  Applications that choose to disable
+   UDP checksums when transmitting over IPv4 therefore 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.  The use
+   of the UDP checksum is REQUIRED when applications transmit UDP over
+   IPv6 [RFC2460].
+
+3.4.1.  UDP-Lite
+
+   A special class of applications can derive benefit from having
+   partially-damaged payloads delivered, rather than discarded, when
+   using paths that include error-prone links.  Such applications can
+   tolerate payload corruption and MAY choose to use the Lightweight
+   User Datagram Protocol (UDP-Lite) [RFC3828] variant of UDP instead of
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 13]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   basic UDP.  Applications that choose to use UDP-Lite instead of UDP
+   should still follow the congestion control and other guidelines
+   described for use with UDP in Section 3.
+
+   UDP-Lite changes the semantics of the UDP "payload length" field to
+   that of a "checksum coverage length" field.  Otherwise, UDP-Lite is
+   semantically identical to UDP.  The interface of UDP-Lite differs
+   from that of UDP by the addition of a single (socket) option that
+   communicates a checksum coverage length value: 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.
+
+   The sending application SHOULD select the minimum checksum coverage
+   to include all sensitive protocol headers.  For example, applications
+   that use the Real-Time Protocol (RTP) [RFC3550] will likely want to
+   protect the RTP header against corruption.  Applications, where
+   appropriate, MUST also introduce their own appropriate validity
+   checks for protocol information carried in the insensitive part of
+   the UDP-Lite payload (e.g., internal CRCs).
+
+   The receiver must set a minimum coverage threshold for incoming
+   packets that is not smaller than the smallest coverage used by the
+   sender [RFC3828].  The receiver SHOULD select a threshold that is
+   sufficiently large to block packets with an inappropriately short
+   coverage field.  This may be a fixed value, or may be negotiated by
+   an application.  UDP-Lite does not provide mechanisms to negotiate
+   the checksum coverage between the sender and receiver.
+
+   Applications may still experience packet loss, rather than
+   corruption, when using UDP-Lite.  The enhancements offered by UDP-
+   Lite rely upon a link being able to intercept the UDP-Lite header to
+   correctly identify the partial coverage required.  When tunnels
+   and/or encryption are used, this can result in UDP-Lite datagrams
+   being treated the same as UDP datagrams, i.e., result in packet loss.
+   Use of IP fragmentation can also prevent special treatment for UDP-
+   Lite datagrams, and this is another reason why applications SHOULD
+   avoid IP fragmentation (Section 3.2).
+
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 14]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+3.5.  Middlebox Traversal Guidelines
+
+   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 traffic
+   and create and destroy per-flow state accordingly.  For a
+   connectionless protocol such as UDP, this approach is not possible.
+   Consequently, middleboxes may create per-flow state when they see a
+   packet that indicates a new flow, and destroy the state after some
+   period of time during which no packets belonging to the same flow
+   have arrived.
+
+   Depending on the specific function that the middlebox performs, this
+   behavior can introduce a time-dependency that restricts the kinds of
+   UDP traffic exchanges that will be successful across the middlebox.
+   For example, NATs and firewalls typically define the partial path on
+   one side of them to be interior to the domain they serve, whereas the
+   partial path on their other side is defined to be exterior to that
+   domain.  Per-flow state is typically created when the first packet
+   crosses from the interior to the exterior, and while the state is
+   present, NATs and firewalls will forward return traffic.  Return
+   traffic that arrives after the per-flow state has timed out is
+   dropped, as is other traffic that arrives from the exterior.
+
+   Many applications that use UDP for communication operate across
+   middleboxes without needing to employ additional mechanisms.  One
+   example is the Domain Name System (DNS), which has a strict request-
+   response communication pattern that typically completes within
+   seconds.
+
+   Other applications may experience communication failures when
+   middleboxes destroy the per-flow state associated with an application
+   session during periods when the application does not exchange any UDP
+   traffic.  Applications SHOULD be able to gracefully handle such
+   communication failures and implement mechanisms to re-establish
+   application-layer sessions and state.
+
+   For some applications, such as media transmissions, this re-
+   synchronization is highly undesirable, because it can cause user-
+   perceivable playback artifacts.  Such specialized applications MAY
+   send periodic keep-alive messages to attempt to refresh middlebox
+   state.  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.
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 15]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   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 [RFC4787].  However, empirical
+   evidence suggests that a significant fraction of currently deployed
+   middleboxes unfortunately use shorter timeouts.  The timeout of 15
+   seconds originates with the Interactive Connectivity Establishment
+   (ICE) protocol [ICE].  When applications are deployed in more
+   controlled network environments, the deployers 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 Middlebox
+   Communications (MIDCOM) [RFC3303], Next Steps in Signaling (NSIS)
+   [NSLP], or Universal Plug and Play (UPnP) [UPnP].  It is RECOMMENDED
+   that applications apply slight random variations ("jitter") to the
+   timing of keep-alive transmissions, to reduce the potential for
+   persistent synchronization between keep-alive transmissions from
+   different hosts.
+
+   Sending keep-alives is not a substitute for implementing robust
+   connection handling.  Like all UDP datagrams, keep-alives can be
+   delayed or dropped, causing middlebox state to time out.  In
+   addition, the congestion control guidelines in Section 3.1 cover all
+   UDP transmissions by an application, including the transmission of
+   middlebox keep-alives.  Congestion control may thus lead to delays or
+   temporary suspension of keep-alive transmission.
+
+   Keep-alive messages are NOT RECOMMENDED for general use.  They are
+   unnecessary for many applications and may consume significant
+   resources.  For example, on battery-powered devices, if an
+   application needs to maintain connectivity for long periods with
+   little traffic, the frequency at which keep-alives are sent can
+   become the determining factor that governs power consumption,
+   depending on the underlying network technology.  Because many
+   middleboxes are designed to require keep-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 [ICE], does succeed less often with TCP than with UDP.  The
+   tradeoffs between different transport protocols -- especially when it
+   comes to middlebox traversal -- deserve careful analysis.
+
+
+
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 16]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+3.6.  Programming Guidelines
+
+   The de facto standard application programming interface (API) for
+   TCP/IP applications is the "sockets" interface [POSIX].  Some
+   platforms also offer applications the ability to directly assemble
+   and transmit IP packets through "raw sockets" or similar facilities.
+   This is a second, more cumbersome method of using UDP.  The
+   guidelines in this document cover all such methods through which an
+   application may use UDP.  Because the sockets API is by far the most
+   common method, the remainder of this section discusses it in more
+   detail.
+
+   Although the sockets API was developed for UNIX in the early 1980s, a
+   wide variety of non-UNIX operating systems also implement this.  The
+   sockets API supports both IPv4 and IPv6 [RFC3493].  The UDP sockets
+   API differs from that for TCP in several key ways.  Because
+   application programmers are typically more familiar with the TCP
+   sockets API, the remainder of this section discusses these
+   differences.  [STEVENS] provides usage examples of the UDP sockets
+   API.
+
+   UDP datagrams may be directly sent and received, without any
+   connection setup.  Using the sockets API, applications can receive
+   packets from more than one IP source address on a single UDP socket.
+   Some servers use this to exchange data with more than one remote host
+   through a single UDP socket at the same time.  Many applications need
+   to ensure that they receive packets from a particular source address;
+   these applications MUST implement corresponding checks at the
+   application layer or explicitly request that the operating system
+   filter the received packets.
+
+   If a client/server application executes on a host with more than one
+   IP interface, the application SHOULD send any UDP responses with an
+   IP source address that matches the IP destination address of the UDP
+   datagram that carried the request (see [RFC1122], Section 4.1.3.5).
+   Many middleboxes expect this transmission behavior and drop replies
+   that are sent from a different IP address, as explained in
+   Section 3.5.
+
+   A UDP receiver can receive a valid UDP datagram with a zero-length
+   payload.  Note that this is different from a return value of zero
+   from a read() socket call, which for TCP indicates the end of the
+   connection.
+
+   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
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 17]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   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 [RFC1122].
+
+   UDP provides no flow-control.  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 on 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.
+
+   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 in this case.  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.
+
+   The Internet can provide service differentiation to applications
+   based on IP-layer packet markings [RFC2475].  This facility can be
+   used for UDP traffic.  Different operating systems provide different
+   interfaces for marking packets to applications.  Differentiated
+   services require support from the network, and application deployers
+   need to discuss the provisioning of this functionality with their
+   network operator.
+
+3.7.  ICMP Guidelines
+
+   Applications can utilize information about ICMP error messages that
+   the UDP layer passes up for a variety of purposes [RFC1122].
+   Applications SHOULD validate that the information in the ICMP message
+   payload, e.g., a reported error condition, corresponds to a UDP
+   datagram that the application actually sent.  Note that not all APIs
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 18]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   have the necessary functions to support this validation, and some
+   APIs already perform this validation internally before passing ICMP
+   information to the application.
+
+   Any application response to ICMP error messages SHOULD be robust to
+   temporary routing failures, i.e., transient ICMP "unreachable"
+   messages should not normally cause a communication abort.
+   Applications SHOULD appropriately process ICMP messages generated in
+   response to transmitted traffic.  A correct response often 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.
+
+4.  Security Considerations
+
+   UDP does not provide communications security.  Applications that need
+   to protect their communications against eavesdropping, tampering, or
+   message forgery SHOULD employ end-to-end security services provided
+   by other IETF protocols.  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 be spoofed.
+
+   One option of securing UDP communications is with IPsec [RFC4301],
+   which can provide authentication for flows of IP packets through the
+   Authentication Header (AH) [RFC4302] and encryption and/or
+   authentication through the Encapsulating Security Payload (ESP)
+   [RFC4303].  Applications use the Internet Key Exchange (IKE)
+   [RFC4306] 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.
+
+   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 of securing UDP
+   communications is through Datagram Transport Layer Security (DTLS)
+   [RFC4347].  DTLS provides communication privacy by encrypting UDP
+   payloads.  It does not protect the UDP headers.  Applications can
+   implement DTLS without relying on support from the operating system.
+
+
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 19]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   Many other options for authenticating or encrypting UDP payloads
+   exist.  For example, the GSS-API security framework [RFC2743] or
+   Cryptographic Message Syntax (CMS) [RFC3852] could be used to protect
+   UDP payloads.  The IETF standard for securing RTP [RFC3550]
+   communication sessions over UDP is the Secure Real-time Transport
+   Protocol (SRTP) [RFC3711].  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
+   [RFC3852], S/MIME [RFC3851] or OpenPGP [RFC4880] could be used.  In
+   addition, there are many non-IETF protocols in this area.
+
+   Like congestion control mechanisms, security mechanisms are difficult
+   to design and implement correctly.  It is hence RECOMMENDED that
+   applications employ well-known standard security mechanisms such as
+   DTLS or IPsec, rather than inventing their own.
+
+   The Generalized TTL Security Mechanism (GTSM) [RFC5082] may be used
+   with UDP applications (especially when the intended endpoint is on
+   the same link as the sender).  This is a lightweight mechanism that
+   allows a receiver to filter unwanted packets.
+
+   In terms of congestion control, [RFC2309] and [RFC2914] discuss the
+   dangers of congestion-unresponsive flows to the Internet.  This
+   document provides guidelines to designers of UDP-based applications
+   to congestion-control their transmissions, and does not raise any
+   additional security concerns.
+
+5.  Summary
+
+   This section summarizes the guidelines made in Sections 3 and 4 in a
+   tabular format (Table 1) for easy referencing.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 20]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   +---------------------------------------------------------+---------+
+   | Recommendation                                          | Section |
+   +---------------------------------------------------------+---------+
+   | MUST tolerate a wide range of Internet path conditions  | 3       |
+   | SHOULD use a full-featured transport (TCP, SCTP, DCCP)  |         |
+   |                                                         |         |
+   | SHOULD control rate of transmission                     | 3.1     |
+   | SHOULD perform congestion control over all traffic      |         |
+   |                                                         |         |
+   | for bulk transfers,                                     | 3.1.1   |
+   | SHOULD consider implementing TFRC                       |         |
+   | else, SHOULD in other ways use bandwidth similar to TCP |         |
+   |                                                         |         |
+   | for non-bulk transfers,                                 | 3.1.2   |
+   | SHOULD measure RTT and transmit max. 1 datagram/RTT     |         |
+   | else, SHOULD send at most 1 datagram every 3 seconds    |         |
+   | SHOULD back-off retransmission timers following loss    |         |
+   |                                                         |         |
+   | for tunnels carrying IP Traffic,                        | 3.1.3   |
+   | SHOULD NOT perform congestion control                   |         |
+   |                                                         |         |
+   | for non-IP tunnels or rate not determined by traffic,   | 3.1.3   |
+   | SHOULD perform congestion control                       |         |
+   |                                                         |         |
+   | SHOULD NOT send datagrams that exceed the PMTU, i.e.,   | 3.2     |
+   | SHOULD discover PMTU or send datagrams < minimum PMTU   |         |
+   |                                                         |         |
+   | SHOULD handle datagram loss, duplication, reordering    | 3.3     |
+   | SHOULD be robust to delivery delays up to 2 minutes     |         |
+   |                                                         |         |
+   | SHOULD enable IPv4 UDP checksum                         | 3.4     |
+   | MUST enable IPv6 UDP checksum                           |         |
+   | else, MAY use UDP-Lite with suitable checksum coverage  | 3.4.1   |
+   |                                                         |         |
+   | SHOULD NOT always send middlebox keep-alives            | 3.5     |
+   | MAY use keep-alives when needed (min. interval 15 sec)  |         |
+   |                                                         |         |
+   | MUST check IP source address                            | 3.6     |
+   | and, for client/server applications                     |         |
+   | SHOULD send responses from src address matching request |         |
+   |                                                         |         |
+   | SHOULD use standard IETF security protocols when needed | 4       |
+   +---------------------------------------------------------+---------+
+
+                    Table 1: Summary of recommendations
+
+
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 21]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+6.  Acknowledgments
+
+   Thanks to Paul Aitken, Mark Allman, Francois Audet, Iljitsch van
+   Beijnum, Stewart Bryant, Remi Denis-Courmont, Lisa Dusseault, Wesley
+   Eddy, Pasi Eronen, Sally Floyd, Robert Hancock, Jeffrey Hutzelman,
+   Cullen Jennings, Tero Kivinen, Peter Koch, Jukka Manner, Philip
+   Matthews, Joerg Ott, Colin Perkins, Tom Petch, Carlos Pignataro, Pasi
+   Sarolahti, Pascal Thubert, Joe Touch, Dave Ward, and Magnus
+   Westerlund for their comments on this document.
+
+   The middlebox traversal guidelines in Section 3.5 incorporate ideas
+   from Section 5 of [BEHAVE-APP] by Bryan Ford, Pyda Srisuresh, and Dan
+   Kegel.
+
+   Lars Eggert is partly funded by [TRILOGY], a research project
+   supported by the European Commission under its Seventh Framework
+   Program.  Gorry Fairhurst was partly funded by the EC SatNEx project.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC0768]     Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+                 August 1980.
+
+   [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
+                 RFC 793, September 1981.
+
+   [RFC1122]     Braden, R., "Requirements for Internet Hosts -
+                 Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [RFC1191]     Mogul, J. and S. Deering, "Path MTU discovery",
+                 RFC 1191, November 1990.
+
+   [RFC1981]     McCann, J., Deering, S., and J. Mogul, "Path MTU
+                 Discovery for IP version 6", RFC 1981, August 1996.
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2460]     Deering, S. and R. Hinden, "Internet Protocol, Version
+                 6 (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC2914]     Floyd, S., "Congestion Control Principles", BCP 41,
+                 RFC 2914, September 2000.
+
+   [RFC2988]     Paxson, V. and M. Allman, "Computing TCP's
+                 Retransmission Timer", RFC 2988, November 2000.
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 22]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   [RFC3828]     Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.,
+                 and G. Fairhurst, "The Lightweight User Datagram
+                 Protocol (UDP-Lite)", RFC 3828, July 2004.
+
+   [RFC4787]     Audet, F. and C. Jennings, "Network Address Translation
+                 (NAT) Behavioral Requirements for Unicast UDP",
+                 BCP 127, RFC 4787, January 2007.
+
+   [RFC4821]     Mathis, M. and J. Heffner, "Packetization Layer Path
+                 MTU Discovery", RFC 4821, March 2007.
+
+   [RFC5348]     Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
+                 Friendly Rate Control (TFRC): Protocol Specification",
+                 RFC 5348, September 2008.
+
+7.2.  Informative References
+
+   [BEHAVE-APP]  Ford, B., "Application Design Guidelines for Traversal
+                 through Network Address Translators", Work in Progress,
+                 March 2007.
+
+   [CCID4]       Floyd, S. and E. Kohler, "Profile for Datagram
+                 Congestion Control Protocol (DCCP) Congestion ID 4:
+                 TCP-Friendly Rate Control for Small Packets (TFRC-SP)",
+                 Work in Progress, February 2008.
+
+   [FABER]       Faber, T., Touch, J., and W. Yue, "The TIME-WAIT State
+                 in TCP and Its Effect on Busy Servers", Proc. IEEE
+                 Infocom, March 1999.
+
+   [GIST]        Schulzrinne, H. and R. Hancock, "GIST: General Internet
+                 Signalling Transport", Work in Progress, July 2008.
+
+   [ICE]         Rosenberg, J., "Interactive Connectivity Establishment
+                 (ICE): A Protocol for Network Address Translator (NAT)
+                 Traversal for Offer/Answer Protocols", Work
+                 in Progress, October 2007.
+
+   [NSLP]        Stiemerling, M., Tschofenig, H., Aoun, C., and E.
+                 Davies, "NAT/Firewall NSIS Signaling Layer Protocol
+                 (NSLP)", Work in Progress, September 2008.
+
+   [POSIX]       IEEE Std. 1003.1-2001, "Standard for Information
+                 Technology - Portable Operating System Interface
+                 (POSIX)", Open Group Technical Standard: Base
+                 Specifications Issue 6, ISO/IEC 9945:2002,
+                 December 2001.
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 23]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   [RFC0896]     Nagle, J., "Congestion control in IP/TCP
+                 internetworks", RFC 896, January 1984.
+
+   [RFC0919]     Mogul, J., "Broadcasting Internet Datagrams", STD 5,
+                 RFC 919, October 1984.
+
+   [RFC1112]     Deering, S., "Host extensions for IP multicasting",
+                 STD 5, RFC 1112, August 1989.
+
+   [RFC1536]     Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
+                 Miller, "Common DNS Implementation Errors and Suggested
+                 Fixes", RFC 1536, October 1993.
+
+   [RFC1546]     Partridge, C., Mendez, T., and W. Milliken, "Host
+                 Anycasting Service", RFC 1546, November 1993.
+
+   [RFC2309]     Braden, B., Clark, D., Crowcroft, J., Davie, B.,
+                 Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
+                 Minshall, G., Partridge, C., Peterson, L.,
+                 Ramakrishnan, K., Shenker, S., Wroclawski, J., and L.
+                 Zhang, "Recommendations on Queue Management and
+                 Congestion Avoidance in the Internet", RFC 2309,
+                 April 1998.
+
+   [RFC2475]     Blake, S., Black, D., Carlson, M., Davies, E., Wang,
+                 Z., and W. Weiss, "An Architecture for Differentiated
+                 Services", RFC 2475, December 1998.
+
+   [RFC2675]     Borman, D., Deering, S., and R. Hinden, "IPv6
+                 Jumbograms", RFC 2675, August 1999.
+
+   [RFC2743]     Linn, J., "Generic Security Service Application Program
+                 Interface Version 2, Update 1", RFC 2743, January 2000.
+
+   [RFC3048]     Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
+                 Floyd, S., and M. Luby, "Reliable Multicast Transport
+                 Building Blocks for One-to-Many Bulk-Data Transfer",
+                 RFC 3048, January 2001.
+
+   [RFC3124]     Balakrishnan, H. and S. Seshan, "The Congestion
+                 Manager", RFC 3124, June 2001.
+
+   [RFC3261]     Rosenberg, J., Schulzrinne, H., Camarillo, G.,
+                 Johnston, A., Peterson, J., Sparks, R., Handley, M.,
+                 and E. Schooler, "SIP: Session Initiation Protocol",
+                 RFC 3261, June 2002.
+
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 24]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   [RFC3303]     Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
+                 and A. Rayhan, "Middlebox communication architecture
+                 and framework", RFC 3303, August 2002.
+
+   [RFC3493]     Gilligan, R., Thomson, S., Bound, J., McCann, J., and
+                 W. Stevens, "Basic Socket Interface Extensions for
+                 IPv6", RFC 3493, February 2003.
+
+   [RFC3550]     Schulzrinne, H., Casner, S., Frederick, R., and V.
+                 Jacobson, "RTP: A Transport Protocol for Real-Time
+                 Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC3551]     Schulzrinne, H. and S. Casner, "RTP Profile for Audio
+                 and Video Conferences with Minimal Control", STD 65,
+                 RFC 3551, July 2003.
+
+   [RFC3711]     Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
+                 K. Norrman, "The Secure Real-time Transport Protocol
+                 (SRTP)", RFC 3711, March 2004.
+
+   [RFC3738]     Luby, M. and V. Goyal, "Wave and Equation Based Rate
+                 Control (WEBRC) Building Block", RFC 3738, April 2004.
+
+   [RFC3758]     Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
+                 Conrad, "Stream Control Transmission Protocol (SCTP)
+                 Partial Reliability Extension", RFC 3758, May 2004.
+
+   [RFC3819]     Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
+                 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and
+                 L. Wood, "Advice for Internet Subnetwork Designers",
+                 BCP 89, RFC 3819, July 2004.
+
+   [RFC3851]     Ramsdell, B., "Secure/Multipurpose Internet Mail
+                 Extensions (S/MIME) Version 3.1 Message Specification",
+                 RFC 3851, July 2004.
+
+   [RFC3852]     Housley, R., "Cryptographic Message Syntax (CMS)",
+                 RFC 3852, July 2004.
+
+   [RFC4301]     Kent, S. and K. Seo, "Security Architecture for the
+                 Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4302]     Kent, S., "IP Authentication Header", RFC 4302,
+                 December 2005.
+
+   [RFC4303]     Kent, S., "IP Encapsulating Security Payload (ESP)",
+                 RFC 4303, December 2005.
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 25]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   [RFC4306]     Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
+                 RFC 4306, December 2005.
+
+   [RFC4340]     Kohler, E., Handley, M., and S. Floyd, "Datagram
+                 Congestion Control Protocol (DCCP)", RFC 4340,
+                 March 2006.
+
+   [RFC4341]     Floyd, S. and E. Kohler, "Profile for Datagram
+                 Congestion Control Protocol (DCCP) Congestion Control
+                 ID 2: TCP-like Congestion Control", RFC 4341,
+                 March 2006.
+
+   [RFC4342]     Floyd, S., Kohler, E., and J. Padhye, "Profile for
+                 Datagram Congestion Control Protocol (DCCP) Congestion
+                 Control ID 3: TCP-Friendly Rate Control (TFRC)",
+                 RFC 4342, March 2006.
+
+   [RFC4347]     Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+                 Security", RFC 4347, April 2006.
+
+   [RFC4654]     Widmer, J. and M. Handley, "TCP-Friendly Multicast
+                 Congestion Control (TFMCC): Protocol Specification",
+                 RFC 4654, August 2006.
+
+   [RFC4880]     Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and
+                 R. Thayer, "OpenPGP Message Format", RFC 4880,
+                 November 2007.
+
+   [RFC4960]     Stewart, R., "Stream Control Transmission Protocol",
+                 RFC 4960, September 2007.
+
+   [RFC4963]     Heffner, J., Mathis, M., and B. Chandler, "IPv4
+                 Reassembly Errors at High Data Rates", RFC 4963,
+                 July 2007.
+
+   [RFC4987]     Eddy, W., "TCP SYN Flooding Attacks and Common
+                 Mitigations", RFC 4987, August 2007.
+
+   [RFC5082]     Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
+                 Pignataro, "The Generalized TTL Security Mechanism
+                 (GTSM)", RFC 5082, October 2007.
+
+   [STEVENS]     Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network
+                 Programming, The sockets Networking API", Addison-
+                 Wesley, 2004.
+
+   [TRILOGY]     "Trilogy Project", <http://www.trilogy-project.org>.
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 26]
+
+RFC 5405              Unicast UDP Usage Guidelines         November 2008
+
+
+   [UPnP]        UPnP Forum, "Internet Gateway Device (IGD) Standardized
+                 Device Control Protocol V 1.0", November 2001.
+
+Authors' Addresses
+
+   Lars Eggert
+   Nokia Research Center
+   P.O. Box 407
+   Nokia Group  00045
+   Finland
+
+   Phone: +358 50 48 24461
+   EMail: lars.eggert@nokia.com
+   URI:   http://people.nokia.net/~lars/
+
+
+   Godred Fairhurst
+   University of Aberdeen
+   Department of Engineering
+   Fraser Noble Building
+   Aberdeen  AB24 3UE
+   Scotland
+
+   EMail: gorry@erg.abdn.ac.uk
+   URI:   http://www.erg.abdn.ac.uk/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eggert & Fairhurst       Best Current Practice                 [Page 27]
+