draft-ietf-tsvwg-udp-guidelines-04.txt   draft-ietf-tsvwg-udp-guidelines-05.txt 
Transport Area Working Group L. Eggert Transport Area Working Group L. Eggert
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Best Current G. Fairhurst Intended status: Best Current G. Fairhurst
Practice University of Aberdeen Practice University of Aberdeen
Expires: May 22, 2008 November 19, 2007 Expires: August 8, 2008 February 5, 2008
UDP Usage Guidelines for Application Designers UDP Usage Guidelines for Application Designers
draft-ietf-tsvwg-udp-guidelines-04 draft-ietf-tsvwg-udp-guidelines-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 22, 2008. This Internet-Draft will expire on August 8, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The User Datagram Protocol (UDP) provides a minimal, message-passing The User Datagram Protocol (UDP) provides a minimal, message-passing
transport that has no inherent congestion control mechanisms. transport that has no inherent congestion control mechanisms.
Because congestion control is critical to the stable operation of the Because congestion control is critical to the stable operation of the
Internet, applications and upper-layer protocols that choose to use Internet, applications and upper-layer protocols that choose to use
UDP as an Internet transport must employ mechanisms to prevent UDP as an Internet transport must employ mechanisms to prevent
congestion collapse and establish some degree of fairness with congestion collapse and establish some degree of fairness with
concurrent traffic. This document provides guidelines on the use of concurrent traffic. This document provides guidelines on the use of
skipping to change at page 2, line 16 skipping to change at page 2, line 16
also provides guidance on other topics, including message sizes, also provides guidance on other topics, including message sizes,
reliability, checksums and middlebox traversal. reliability, checksums and middlebox traversal.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 4 3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 4
3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 5 3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 5
3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 10 3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 10
3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 10 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 11
3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 11 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 12
3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 13 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 13
3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 14 3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 15
3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 16 3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26
1. Introduction 1. Introduction
The User Datagram Protocol (UDP) [RFC0768] provides a minimal, The User Datagram Protocol (UDP) [RFC0768] provides a minimal,
unreliable, best-effort, message-passing transport to applications unreliable, best-effort, message-passing transport to applications
and upper-layer protocols (both simply called "applications" in the and upper-layer protocols (both simply called "applications" in the
remainder of this document). Compared to other transport protocols, remainder of this document). Compared to other transport protocols,
UDP and its UDP-Lite variant [RFC3828] are unique in that they do not UDP and its UDP-Lite variant [RFC3828] are unique in that they do not
establish end-to-end connections between communicating end systems. establish end-to-end connections between communicating end systems.
UDP communication consequently does not incur connection UDP communication consequently does not incur connection
skipping to change at page 3, line 51 skipping to change at page 3, line 51
avoidance mechanisms." This is an important requirement, even for avoidance mechanisms." This is an important requirement, even for
applications that do not use UDP for streaming. For example, an applications that do not use UDP for streaming. For example, an
application that generates five 1500-byte UDP messages in one second application that generates five 1500-byte UDP messages in one second
can already exceed the capacity of a 56 Kb/s path. For applications can already exceed the capacity of a 56 Kb/s path. For applications
that can operate at higher, potentially unbounded data rates, that can operate at higher, potentially unbounded data rates,
congestion control becomes vital to prevent congestion collapse and congestion control becomes vital to prevent congestion collapse and
establish some degree of fairness. Section 3 describes a number of establish some degree of fairness. Section 3 describes a number of
simple guidelines for the designers of such applications. simple guidelines for the designers of such applications.
A UDP message is carried in a single IP packet and is hence limited A UDP message is carried in a single IP packet and is hence limited
to a maximum payload of 65,507 bytes for IPv4 and 65,487 bytes for 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 IPv6. The transmission of large IP packets usually requires IP
fragmentation. At least for IPv4, fragmentation decreases fragmentation. Fragmentation decreases communication reliability and
communication reliability and efficiency and should be avoided. One efficiency and should be avoided. IPv6 allows the option of
reason for this decrease in reliability is that many NATs and transmitting large packets ("jumbograms") without fragmentation when
firewalls do not forward IPv4 fragments; other reasons are documented all link layers along the path support this [RFC2675]. Some of the
in [RFC4963]. Some of the guidelines in Section 3 describe how guidelines in Section 3 describe how applications should determine
applications should determine appropriate message sizes. appropriate message sizes.
This document provides guidelines to designers of applications that This document provides guidelines to designers of applications that
use UDP for unicast transmission. A special class of applications use UDP for unicast transmission. A special class of applications
uses UDP for IP multicast transmissions. Congestion control, flow uses UDP for IP multicast transmissions. Congestion control, flow
control or reliability for multicast transmissions is more difficult control or reliability for multicast transmissions is more difficult
to establish than for unicast transmissions, because a single sender to establish than for unicast transmissions, because a single sender
may transmit to multiple receivers across potentially very may transmit to multiple receivers across potentially very
heterogeneous paths at the same time. Designing multicast heterogeneous paths at the same time. Designing multicast
applications requires expertise that goes beyond the simple applications requires expertise that goes beyond the simple
guidelines given in this document. The IETF has defined a reliable guidelines given in this document. The IETF has defined a reliable
skipping to change at page 7, line 32 skipping to change at page 7, line 32
benefit, because those mechanisms perform congestion control in a way benefit, because those mechanisms perform congestion control in a way
that is only effective for longer transmissions. that is only effective for longer transmissions.
Applications that exchange only a small number of messages with a Applications that exchange only a small number of messages with a
destination at any time SHOULD still control their transmission destination at any time SHOULD still control their transmission
behavior by not sending more than one UDP message per round-trip time behavior by not sending more than one UDP message per round-trip time
(RTT) to a destination. Similar to the recommendation in [RFC1536], (RTT) to a destination. Similar to the recommendation in [RFC1536],
an application SHOULD maintain an estimate of the RTT for any an application SHOULD maintain an estimate of the RTT for any
destination with which it communicates. Applications SHOULD destination with which it communicates. Applications SHOULD
implement the algorithm specified in [RFC2988] to compute a smoothed implement the algorithm specified in [RFC2988] to compute a smoothed
RTT (SRTT) estimate. A lost response from the peer SHOULD be treated RTT (SRTT) estimate. They SHOULD also detect packet loss and
as a very large RTT sample, instead of being ignored, in order to exponentially back-off their retransmission timer when a loss event
cause a sufficiently large (exponential) back-off. When implementing occurs. When implementing this scheme, applications need to choose a
this scheme, applications need to choose a sensible initial value for sensible initial value for the RTT. This value SHOULD generally be
the RTT. This value SHOULD generally be as conservative as possible as conservative as possible for the given application. TCP uses an
for the given application. TCP uses an initial value of 3 seconds initial value of 3 seconds [RFC2988], which is also RECOMMENDED as an
[RFC2988], which is also RECOMMENDED as an initial value for UDP initial value for UDP applications. SIP [RFC3261] and GIST
applications. SIP [RFC3261] and GIST [I-D.ietf-nsis-ntlp] use an [I-D.ietf-nsis-ntlp] use an initial value of 500 ms, and initial
initial value of 500 ms, and initial timeouts that are shorter than timeouts that are shorter than this are likely problematic in many
this are likely problematic in many cases. It is also important to cases. It is also important to note that the initial timeout is not
note that the initial timeout is not the maximum possible timeout - the maximum possible timeout - the RECOMMENDED algorithm in [RFC2988]
the RECOMMENDED algorithm in [RFC2988] yields timeout values after a yields timeout values after a series of losses that are much longer
series of losses that are much longer than the initial value. than the initial value.
Some applications cannot maintain a reliable RTT estimate for a Some applications cannot maintain a reliable RTT estimate for a
destination. The first case is applications that exchange too few destination. The first case is applications that exchange too few
messages with a peer to establish a statistically accurate RTT messages with a peer to establish a statistically accurate RTT
estimate. Such applications MAY use a pre-determined transmission estimate. Such applications MAY use a pre-determined transmission
interval that is exponentially backed-off when packets are lost. TCP interval that is exponentially backed-off when packets are lost. TCP
uses an initial value of 3 seconds [RFC2988], which is also uses an initial value of 3 seconds [RFC2988], which is also
RECOMMENDED as an initial value for UDP applications. SIP [RFC3261] RECOMMENDED as an initial value for UDP applications. SIP [RFC3261]
and GIST [I-D.ietf-nsis-ntlp] use an interval of 500 ms, and shorter and GIST [I-D.ietf-nsis-ntlp] use an interval of 500 ms, and shorter
values are likely problematic in many cases. As in the previous values are likely problematic in many cases. As in the previous
skipping to change at page 9, line 9 skipping to change at page 9, line 9
the routers between the two tunnel endpoints, the traffic that a UDP the routers between the two tunnel endpoints, the traffic that a UDP
tunnel generates is a regular UDP flow, and the encapsulator and tunnel generates is a regular UDP flow, and the encapsulator and
decapsulator appear as regular UDP-sending and -receiving decapsulator appear as regular UDP-sending and -receiving
applications. Because other flows can share the path with one or applications. Because other flows can share the path with one or
more UDP tunnels, congestion control needs to be considered. more UDP tunnels, congestion control needs to be considered.
Two factors determine whether a UDP tunnel needs to employ specific Two factors determine whether a UDP tunnel needs to employ specific
congestion control mechanisms. First, whether the tunneling scheme congestion control mechanisms. First, whether the tunneling scheme
generates UDP traffic at a volume that corresponds to the volume of generates UDP traffic at a volume that corresponds to the volume of
payload traffic carried within the tunnel. Second, whether the payload traffic carried within the tunnel. Second, whether the
payload traffic is IP-based. This results in these possible cases: payload traffic is IP-based.
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 mechanism
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. Tunnel generates UDP traffic at a volume that corresponds to the 1. Tunnel generates UDP traffic at a volume that corresponds to the
volume of payload traffic, and the payload traffic is IP-based. volume of payload traffic, and the payload traffic is IP-based
and hence assumed to be congestion-controlled.
This is arguably the most common case for Internet tunnels. In This is arguably the most common case for Internet tunnels. In
this case, the UDP tunnel SHOULD NOT employ its own congestion this case, the UDP tunnel SHOULD NOT employ its own congestion
control mechanism, because congestion losses of tunneled traffic control mechanism, because congestion losses of tunneled traffic
will already trigger an appropriate congestion response at the will already trigger an appropriate congestion response at the
original senders of the tunneled traffic. original senders of the tunneled traffic.
Note that this guideline is built on the assumption that most IP- Note that this guideline is built on the assumption that most IP-
based communication is congestion-controlled. If a UDP tunnel is based communication is congestion-controlled. If a UDP tunnel is
used for IP-based traffic that is known to not be congestion- used for IP-based traffic that is known to not be congestion-
controlled, the next set of guidelines applies: controlled, the next set of guidelines applies:
2. Tunnel generates UDP traffic at a volume that corresponds to the 2. Tunnel generates UDP traffic at a volume that corresponds to the
volume of payload traffic, and the payload traffic is not known 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- to be IP-based or is known to be IP-based, but not congestion-
controlled). controlled.
This is the case, for example, when link-layer protocols are This can be case, for example, when some link-layer protocols are
encapsulated within UDP. Because it is not known that congestion encapsulated within UDP (but not all link-layer protocols; some
losses of tunneled non-IP traffic will trigger an appropriate are congestion-controlled.) Because it is not known that
congestion response at the senders, the UDP tunnel SHOULD employ congestion losses of tunneled non-IP traffic will trigger an
an appropriate congestion control mechanism. Because tunnels are appropriate congestion response at the senders, the UDP tunnel
usually bulk-transfer applications as far as the intermediate SHOULD employ an appropriate congestion control mechanism.
routers are concerned, the guidelines in Section 3.1.1 apply. Because tunnels are usually bulk-transfer applications as far as
the intermediate routers are concerned, the guidelines in
Section 3.1.1 apply.
3. Tunnel generates UDP traffic at a volume that does not correspond 3. Tunnel generates UDP traffic at a volume that does not correspond
to the volume of payload traffic, independent of whether the to the volume of payload traffic, independent of whether the
payload traffic is IP-based or not. payload traffic is IP-based or congestion-controlled.
Examples of this class include UDP tunnels that send at a Examples of this class include UDP tunnels that send at a
constant rate, increase their transmission rates under loss, for constant rate, increase their transmission rates under loss, for
example, due to increasing redundancy when forward-error- example, due to increasing redundancy when forward-error-
correction is used, or are otherwise constrained in their correction is used, or are otherwise constrained in their
transmission behavior. These specialized uses of UDP for transmission behavior. These specialized uses of UDP for
tunneling go beyond the scope of the general guidelines given in tunneling go beyond the scope of the general guidelines given in
this document. The implementer of such specialized tunnels this document. The implementer of such specialized tunnels
SHOULD carefully consider congestion control in the design of SHOULD carefully consider congestion control in the design of
their tunneling mechanism. their tunneling mechanism.
skipping to change at page 10, line 13 skipping to change at page 10, line 31
Designing tunneling mechanism requires significantly more expertise Designing tunneling mechanism requires significantly more expertise
than needed for many other UDP applications, because tunnels than needed for many other UDP applications, because tunnels
virtualize lower-layer components of the Internet, and the virtualize lower-layer components of the Internet, and the
virtualized components need to correctly interact with the virtualized components need to correctly interact with the
infrastructure at that layer. This document only touches upon the infrastructure at that layer. This document only touches upon the
congestion control considerations for implementing UDP tunnels; a congestion control considerations for implementing UDP tunnels; a
discussion of other required tunneling behavior is out of scope. discussion of other required tunneling behavior is out of scope.
3.2. Message Size Guidelines 3.2. Message Size Guidelines
Because IPv4 fragmentation lowers the efficiency and reliability of IP fragmentation lowers the efficiency and reliability of Internet
Internet communication [RFC4963], an application SHOULD NOT send UDP communication. The loss of a single fragment results in the loss of
messages that result in IPv4 packets that exceed the MTU of the path an entire fragmented packet, because even if all other fragments are
to the destination. Consequently, an application SHOULD either use received correctly, the original packet cannot be reassembled and
the path MTU information provided by the IP layer or implement path delivered. This fundamental issue with fragmentation exists for both
MTU discovery itself [RFC1191][RFC1981][RFC4821] to determine whether IPv4 and IPv6. In addition, some NATs and firewalls drop IP
the path to a destination will support its desired message size fragments. The network address translation performed by a NAT only
without fragmentation. 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 messages 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 choose to not adapt their transmit message size Applications that choose to not adapt their transmit message size
SHOULD NOT send UDP messages that would result in IP datagrams that SHOULD NOT send UDP messages that would result in IP datagrams that
exceed the effective PMTU. In the absence of actual knowledge of the exceed the effective PMTU. In the absence of actual knowledge of the
minimum MTU along the path, the effective PMTU depends upon the IP minimum MTU along the path, the effective PMTU depends upon the IP
version used for transmission. It is the smaller of 576 bytes and version used for transmission. It is the smaller of 576 bytes and
the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for IPv6 the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for IPv6
[RFC2460]. The effective PMTU for a directly connected destination [RFC2460]. The effective PMTU for a directly connected destination
(with no routers on the path) is the configured interface MTU, which (with no routers on the path) is the configured interface MTU, which
could be less than the maximum link payload size. Transmission of could be less than the maximum link payload size. Transmission of
skipping to change at page 11, line 22 skipping to change at page 12, line 4
duplicate messages to reduce load. duplicate messages to reduce load.
In addition, the Internet can significantly delay some packets with In addition, the Internet can significantly delay some packets with
respect to others, e.g., due to routing transients, intermittent respect to others, e.g., due to routing transients, intermittent
connectivity, or mobility. This can cause message reordering, where connectivity, or mobility. This can cause message reordering, where
UDP messages arrive at the receiver in an order different from the UDP messages arrive at the receiver in an order different from the
transmission order. Applications that require ordered delivery MUST transmission order. Applications that require ordered delivery MUST
reestablish message ordering themselves. reestablish message ordering themselves.
Finally, it is important to note that delay spikes can be very large. Finally, it is important to note that delay spikes can be very large.
This can cause reordered packets to arrive many seconds after they This can cause reordered packets to arrive many seconds after they
were sent. The Internet protocol suite defines the Maximum Segment were sent. [RFC0793] defines the the maximum delay a TCP segment
Lifetime (MSL) for TCP segments as 2 minutes [RFC0793]; this value should experience - the Maximum Segment Lifetime (MSL) - as 2
applies to all IP datagrams, and hence also to UDP. The MSL is the minutes. No other RFC defines an MSL for other transport protocols
maximum delay a packet should experience. Applications SHOULD be or IP itself. This document clarifies that the MSL value to be used
robust to the reception of delayed or duplicate packets that are for UDP SHOULD be the same 2 minutes as for TCP. Applications SHOULD
received within this two-minute interval. be robust to the reception of delayed or duplicate packets that are
received within this 2-minute interval.
Applications that require reliable and ordered message delivery Applications that require reliable and ordered message delivery
SHOULD choose an IETF standard transport protocol that provides these SHOULD choose an IETF standard transport protocol that provides these
features. If this is not possible, it will need to implement a set features. If this is not possible, it will need to implement a set
of appropriate mechanisms itself. of appropriate mechanisms itself.
3.4. Checksum Guidelines 3.4. Checksum Guidelines
The UDP header includes an optional, 16-bit ones-complement checksum The UDP header includes an optional, 16-bit ones-complement checksum
that provides an integrity check. This results in a relatively weak that provides an integrity check. This results in a relatively weak
skipping to change at page 15, line 16 skipping to change at page 15, line 48
connection setup. Using the sockets API, applications can receive connection setup. Using the sockets API, applications can receive
packets from more than one IP source address on a single UDP socket. 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 Some servers use this to exchange data with more than one remote host
through a single UDP socket at the same time. When applications need through a single UDP socket at the same time. When applications need
to ensure that they receive packets from a particular source address, to ensure that they receive packets from a particular source address,
they MUST implement corresponding checks at the application layer or they MUST implement corresponding checks at the application layer or
explicitly request that the operating system filter the received explicitly request that the operating system filter the received
packets. packets.
If a client/server application executes on a host with more than one If a client/server application executes on a host with more than one
IP interface, the application MUST ensure that it sends any UDP IP interface, the application SHOULD send any UDP responses in reply
responses in reply to arriving UDP datagrams with an IP source to arriving UDP datagrams with an IP source address that matches the
address that matches the IP destination address of the datagram that IP destination address of the datagram that carried the request.
carried the request. 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 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 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 from a read() socket call, which for TCP indicates the end of the
connection. connection.
Many operating systems also allow a UDP socket to be connected, i.e., 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 to bind a UDP socket to a specific pair of addresses and ports. This
is similar to the corresponding TCP sockets API functionality. is similar to the corresponding TCP sockets API functionality.
However, for UDP, this is only a local operation that serves to However, for UDP, this is only a local operation that serves to
skipping to change at page 16, line 16 skipping to change at page 17, line 7
instance that happens to reuse the same IP address and port pairs. instance that happens to reuse the same IP address and port pairs.
The UDP protocol does not implement such a mechanism. Therefore, The UDP protocol does not implement such a mechanism. Therefore,
UDP-based applications need to robust to this case. One application UDP-based applications need to robust to this case. One application
may close a socket or terminate, followed in time by another may close a socket or terminate, followed in time by another
application receiving on the same port. This later application may application receiving on the same port. This later application may
then receive packets intended for the first application that were then receive packets intended for the first application that were
delayed in the network. delayed in the network.
3.7. ICMP Guidelines 3.7. ICMP Guidelines
Applications can utilize ICMP error messages that the UDP layer Applications can utilize information about ICMP error messages that
passes up for a variety of purposes [RFC1122]. Applications SHOULD the UDP layer passes up for a variety of purposes [RFC1122].
validate the information in the ICMP message payload, e.g., that the Applications SHOULD validate that the information in the ICMP message
reported error corresponds to a UDP datagram that the application payload, e.g., a reported error condition, corresponds to a UDP
actually sent. datagram that the application actually sent. Note that not all APIs
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 Any application response to ICMP error messages SHOULD be robust to
temporary routing failures, i.e., transient ICMP "unreachable" temporary routing failures, i.e., transient ICMP "unreachable"
messages should not normally cause a communication abort. messages should not normally cause a communication abort.
Applications are RECOMMENDED to appropriately respond to ICMP Applications SHOULD appropriately respond to ICMP messages generated
messages generated in response to transmitted traffic. A correct in response to transmitted traffic. A correct response often
response often requires context, such as local state about requires context, such as local state about communication instances
communication instances to each destination, that although readily to each destination, that although readily available in connection-
available in connection-orientated transport protocols is not always oriented transport protocols is not always maintained by UDP-based
maintained by UDP-based applications. applications.
4. Security Considerations 4. Security Considerations
UDP does not provide communications security. Applications that need UDP does not provide communications security. Applications that need
to protect their communications against eavesdropping, tampering, or to protect their communications against eavesdropping, tampering, or
message forgery SHOULD employ end-to-end security services provided message forgery SHOULD employ end-to-end security services provided
by other IETF protocols. by other IETF protocols.
One option of securing UDP communications is with IPsec [RFC4301], One option of securing UDP communications is with IPsec [RFC4301],
which can provide authentication for flows of IP packets through the which can provide authentication for flows of IP packets through the
skipping to change at page 17, line 14 skipping to change at page 18, line 7
suite. suite.
Although it is possible to use IPsec to secure UDP communications, Although it is possible to use IPsec to secure UDP communications,
not all operating systems support IPsec or allow applications to not all operating systems support IPsec or allow applications to
easily configure it for their flows. A second option of securing UDP easily configure it for their flows. A second option of securing UDP
communications is through Datagram Transport Layer Security (DTLS) communications is through Datagram Transport Layer Security (DTLS)
[RFC4347]. DTLS provides communication privacy by encrypting UDP [RFC4347]. DTLS provides communication privacy by encrypting UDP
payloads. It does not protect the UDP headers. Applications can payloads. It does not protect the UDP headers. Applications can
implement DTLS without relying on support from the operating system. implement DTLS without relying on support from the operating system.
Many other options of authenticating or encrypting UDP payloads Many other options for authenticating or encrypting UDP payloads
exist, including other IETF standards, such as S/MIME [RFC3851] or exist. These include IETF security frameworks such as GSS-API GSS-
PGP [RFC4880], security frameworks such as GSS-API [RFC1964], SASL API [RFC2743], SASL [RFC4422] and EAP [RFC3748], which are designed
[RFC4422] and EAP [RFC3748], as well as many non-IETF protocols. Out to provide security services for network protocols. For some
of these, S/MIME and PGP are likely to better suit less immediate and applications, S/MIME [RFC3851] or PGP [RFC4880] might provide a
less ephemeral communications than typically the case for UDP better solution, because they provide protection for larger
applications, because they generally require public-key operations standalone objects such as files or messages. However, they
for each message. generally involve public-key operations on an entire object, which
can have performance implications. In addition, there are many non-
IETF protocols in this area.
Like congestion control mechanisms, security mechanisms are difficult Like congestion control mechanisms, security mechanisms are difficult
to design and implement correctly. It is hence RECOMMENDED that to design and implement correctly. It is hence RECOMMENDED that
applications employ well-known standard security mechanisms such as applications employ well-known standard security mechanisms such as
DTLS or IPsec, rather than inventing their own. DTLS or IPsec, rather than inventing their own.
In terms of congestion control, [RFC2309] and [RFC2914] discuss the In terms of congestion control, [RFC2309] and [RFC2914] discuss the
dangers of congestion-unresponsive flows to the Internet. This dangers of congestion-unresponsive flows to the Internet. This
document provides guidelines to designers of UDP-based applications document provides guidelines to designers of UDP-based applications
to congestion-control their transmissions, and does not raise any to congestion-control their transmissions, and does not raise any
skipping to change at page 18, line 26 skipping to change at page 19, line 26
| else, SHOULD otherwise use bandwidth similar to TCP | | | else, SHOULD otherwise use bandwidth similar to TCP | |
| | | | | |
| for non-bulk transfers, | 3.1.2 | | for non-bulk transfers, | 3.1.2 |
| SHOULD measure RTT and transmit 1 message/RTT | | | SHOULD measure RTT and transmit 1 message/RTT | |
| else, SHOULD send at most 1 message every 3 seconds | | | else, SHOULD send at most 1 message every 3 seconds | |
| | | | | |
| SHOULD NOT send messages that exceed the PMTU, i.e., | 3.2 | | SHOULD NOT send messages that exceed the PMTU, i.e., | 3.2 |
| SHOULD discover PMTU or send messages < minimum PMTU | | | SHOULD discover PMTU or send messages < minimum PMTU | |
| | | | | |
| SHOULD handle message loss, duplication, reordering | 3.3 | | SHOULD handle message loss, duplication, reordering | 3.3 |
| SHOULD be robust to delivery delays up to 2 minutes | |
| | | | | |
| SHOULD enable UDP checksum | 3.4 | | SHOULD enable UDP checksum | 3.4 |
| else, MAY use UDP-Lite with suitable checksum coverage | 3.4.1 | | else, MAY use UDP-Lite with suitable checksum coverage | 3.4.1 |
| | | | | |
| SHOULD NOT always send middlebox keep-alives | 3.5 | | SHOULD NOT always send middlebox keep-alives | 3.5 |
| MAY use keep-alives when needed (min. interval 15 sec) | | | MAY use keep-alives when needed (min. interval 15 sec) | |
| | | | | |
| MUST check IP source address | 3.6 | | 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 | | SHOULD use standard IETF security protocols when needed | 4 |
+---------------------------------------------------------+---------+ +---------------------------------------------------------+---------+
Table 1: Summary of recommendations. Table 1: Summary of recommendations.
6. IANA Considerations 6. IANA Considerations
This document raises no IANA considerations. This document raises no IANA considerations.
7. Acknowledgments 7. Acknowledgments
Thanks to Paul Aitken, Mark Allman, Francois Audet, Stewart Bryant, Thanks to Paul Aitken, Mark Allman, Francois Audet, Iljitsch van
Remi Denis-Courmont, Wesley Eddy, Sally Floyd, Jeffrey Hutzelman, Beijnum, Stewart Bryant, Remi Denis-Courmont, Wesley Eddy, Sally
Tero Kivinen, Philip Matthews, Joerg Ott, Colin Perkins, Carlos Floyd, Jeffrey Hutzelman, Cullen Jennings, Tero Kivinen, Philip
Pignataro, Pasi Sarolahti, Joe Touch and Magnus Westerlund for their Matthews, Joerg Ott, Colin Perkins, Tom Petch, Carlos Pignataro, Pasi
Sarolahti, Pascal Thubert, Joe Touch and Magnus Westerlund for their
comments on this document. comments on this document.
The middlebox traversal guidelines in Section 3.5 incorporate ideas The middlebox traversal guidelines in Section 3.5 incorporate ideas
from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda Srisuresh from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda Srisuresh
and Dan Kegel. and Dan Kegel.
Lars Eggert is partly funded by [TRILOGY], a research project
supported by the European Commission under its Seventh Framework
Program.
8. References 8. References
8.1. Normative References 8.1. Normative References
[POSIX] IEEE Std. 1003.1-2001, "Standard for Information [POSIX] IEEE Std. 1003.1-2001, "Standard for Information
Technology - Portable Operating System Interface (POSIX)", Technology - Portable Operating System Interface (POSIX)",
Open Group Technical Standard: Base Specifications Issue Open Group Technical Standard: Base Specifications Issue
6, ISO/IEC 9945:2002, December 2001. 6, ISO/IEC 9945:2002, December 2001.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
skipping to change at page 20, line 27 skipping to change at page 21, line 36
[I-D.ford-behave-app] [I-D.ford-behave-app]
Ford, B., "Application Design Guidelines for Traversal Ford, B., "Application Design Guidelines for Traversal
through Network Address Translators", through Network Address Translators",
draft-ford-behave-app-05 (work in progress), March 2007. draft-ford-behave-app-05 (work in progress), March 2007.
[I-D.ietf-dccp-ccid4] [I-D.ietf-dccp-ccid4]
Floyd, S. and E. Kohler, "Profile for Datagram Congestion Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Control Protocol (DCCP) Congestion ID 4: TCP-Friendly
Rate Control for Small Packets (TFRC-SP)", Rate Control for Small Packets (TFRC-SP)",
draft-ietf-dccp-ccid4-00 (work in progress), October 2007. draft-ietf-dccp-ccid4-01 (work in progress),
November 2007.
[I-D.ietf-dccp-rfc3448bis] [I-D.ietf-dccp-rfc3448bis]
Handley, M., "TCP Friendly Rate Control (TFRC): Protocol Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Specification", draft-ietf-dccp-rfc3448bis-02 (work in Friendly Rate Control (TFRC): Protocol Specification",
progress), July 2007. draft-ietf-dccp-rfc3448bis-04 (work in progress),
January 2008.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-nsis-nslp-natfw] [I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies,
Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
progress), July 2007. draft-ietf-nsis-nslp-natfw-17 (work in progress),
January 2008.
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIST: General Internet Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", draft-ietf-nsis-ntlp-14 (work in Signalling Transport", draft-ietf-nsis-ntlp-15 (work in
progress), July 2007. progress), February 2008.
[I-D.wing-behave-nat-control-stun-usage] [I-D.wing-behave-nat-control-stun-usage]
Wing, D., Rosenberg, J., and H. Tschofenig, "Discovering, Wing, D., Rosenberg, J., and H. Tschofenig, "Discovering,
Querying, and Controlling Firewalls and NATs", Querying, and Controlling Firewalls and NATs",
draft-wing-behave-nat-control-stun-usage-05 (work in draft-wing-behave-nat-control-stun-usage-05 (work in
progress), October 2007. progress), October 2007.
[RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks",
RFC 896, January 1984. RFC 896, January 1984.
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
Miller, "Common DNS Implementation Errors and Suggested Miller, "Common DNS Implementation Errors and Suggested
Fixes", RFC 1536, October 1993. Fixes", RFC 1536, October 1993.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the Queue Management and Congestion Avoidance in the
Internet", RFC 2309, April 1998. Internet", RFC 2309, April 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., [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
Floyd, S., and M. Luby, "Reliable Multicast Transport Floyd, S., and M. Luby, "Reliable Multicast Transport
Building Blocks for One-to-Many Bulk-Data Transfer", Building Blocks for One-to-Many Bulk-Data Transfer",
RFC 3048, January 2001. RFC 3048, January 2001.
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC 3124, June 2001. RFC 3124, June 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
skipping to change at page 23, line 26 skipping to change at page 24, line 43
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963, July 2007. Errors at High Data Rates", RFC 4963, July 2007.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007. Mitigations", RFC 4987, August 2007.
[STEVENS] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network [STEVENS] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network
Programming, The sockets Networking API", Addison-Wesley, Programming, The sockets Networking API", Addison-Wesley,
2004. 2004.
[TRILOGY] "Trilogy Project", http://www.trilogy-project.org/.
[UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized [UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized
Device Control Protocol V 1.0", November 2001. Device Control Protocol V 1.0", November 2001.
Authors' Addresses Authors' Addresses
Lars Eggert Lars Eggert
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
Nokia Group 00045 Nokia Group 00045
Finland Finland
skipping to change at page 25, line 7 skipping to change at page 26, line 7
Department of Engineering Department of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen AB24 3UE Aberdeen AB24 3UE
Scotland Scotland
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/ URI: http://www.erg.abdn.ac.uk/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 33 change blocks. 
103 lines changed or deleted 159 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/