--- 1/draft-ietf-tsvwg-udp-guidelines-04.txt 2008-02-05 11:12:12.000000000 +0100 +++ 2/draft-ietf-tsvwg-udp-guidelines-05.txt 2008-02-05 11:12:12.000000000 +0100 @@ -1,19 +1,19 @@ Transport Area Working Group L. Eggert Internet-Draft Nokia Intended status: Best Current G. Fairhurst Practice University of Aberdeen -Expires: May 22, 2008 November 19, 2007 +Expires: August 8, 2008 February 5, 2008 UDP Usage Guidelines for Application Designers - draft-ietf-tsvwg-udp-guidelines-04 + draft-ietf-tsvwg-udp-guidelines-05 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,25 +24,25 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). 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 establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of @@ -51,34 +51,34 @@ also provides guidance on other topics, including message sizes, reliability, checksums and middlebox traversal. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. UDP Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 4 3.1. Congestion Control Guidelines . . . . . . . . . . . . . . 5 3.2. Message Size Guidelines . . . . . . . . . . . . . . . . . 10 - 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 10 - 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 11 + 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 11 + 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 12 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 13 - 3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 14 - 3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 16 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 - Intellectual Property and Copyright Statements . . . . . . . . . . 25 + 3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 15 + 3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 17 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 + Intellectual Property and Copyright Statements . . . . . . . . . . 26 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 @@ -112,28 +112,28 @@ avoidance mechanisms." This is an important requirement, even for applications that do not use UDP for streaming. For example, an application that generates five 1500-byte UDP messages in one second can already exceed the capacity of a 56 Kb/s path. For applications that can operate at higher, potentially unbounded data rates, congestion control becomes vital to prevent congestion collapse and establish some degree of fairness. Section 3 describes a number of simple guidelines for the designers of such applications. A UDP 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 - fragmentation. At least for IPv4, fragmentation decreases - communication reliability and efficiency and should be avoided. One - reason for this decrease in reliability is that many NATs and - firewalls do not forward IPv4 fragments; other reasons are documented - in [RFC4963]. Some of the guidelines in Section 3 describe how - applications should determine appropriate message sizes. + 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. This document provides guidelines to designers of applications that use UDP for unicast transmission. A special class of applications uses UDP for IP multicast transmissions. Congestion control, flow control or reliability for multicast transmissions is more difficult to establish than for unicast transmissions, because a single sender may transmit to multiple receivers across potentially very heterogeneous paths at the same time. Designing multicast applications requires expertise that goes beyond the simple guidelines given in this document. The IETF has defined a reliable @@ -284,33 +284,33 @@ benefit, because those mechanisms perform congestion control in a way that is only effective for longer transmissions. Applications that exchange only a small number of messages with a destination at any time SHOULD still control their transmission behavior by not sending more than one UDP message 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. A lost response from the peer SHOULD be treated - as a very large RTT sample, instead of being ignored, in order to - cause a sufficiently large (exponential) back-off. 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 [I-D.ietf-nsis-ntlp] 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. + 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 + [I-D.ietf-nsis-ntlp] 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 applications that exchange too few messages with a peer to establish a statistically accurate RTT estimate. Such applications MAY use a pre-determined 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 [I-D.ietf-nsis-ntlp] use an interval of 500 ms, and shorter values are likely problematic in many cases. As in the previous @@ -357,52 +357,70 @@ 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 tunneling scheme generates UDP traffic at a volume that corresponds to the volume of 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 - 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 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. 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). + to be IP-based or is known to be IP-based, but not congestion- + controlled. - This is the case, for example, when link-layer protocols are - encapsulated within UDP. 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. + This can be 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. 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 not. + 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- 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. @@ -410,28 +428,41 @@ Designing 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 - Because IPv4 fragmentation lowers the efficiency and reliability of - Internet communication [RFC4963], an application SHOULD NOT send UDP - messages that result in IPv4 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. + 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 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 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 SHOULD NOT send UDP messages that would result in IP datagrams that exceed the effective PMTU. In the absence of actual knowledge of the minimum MTU along the path, the effective PMTU depends upon the IP version used for transmission. It is the smaller of 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460]. The effective PMTU for a directly connected destination (with no routers on the path) is the configured interface MTU, which could be less than the maximum link payload size. Transmission of @@ -467,27 +498,29 @@ duplicate messages 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 message reordering, where UDP messages arrive at the receiver in an order different from the transmission order. Applications that require ordered delivery MUST reestablish message 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. The Internet protocol suite defines the Maximum Segment - Lifetime (MSL) for TCP segments as 2 minutes [RFC0793]; this value - applies to all IP datagrams, and hence also to UDP. The MSL is the - maximum delay a packet should experience. Applications SHOULD be - robust to the reception of delayed or duplicate packets that are - received within this two-minute interval. + were sent. [RFC0793] defines the the maximum delay a TCP segment + should experience - the Maximum Segment Lifetime (MSL) - as 2 + minutes. No other RFC defines an MSL for other transport protocols + or IP itself. 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. Applications that require 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 ones-complement checksum that provides an integrity check. This results in a relatively weak @@ -654,24 +687,26 @@ 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. When applications need to ensure that they receive packets from a particular source address, they 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 MUST ensure that it sends any UDP - responses in reply to arriving UDP datagrams with an IP source - address that matches the IP destination address of the datagram that - carried the request. + IP interface, the application SHOULD send any UDP responses in reply + to arriving UDP datagrams with an IP source address that matches the + IP destination address of the datagram that 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 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 @@ -703,35 +738,38 @@ 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 robust to 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. 3.7. ICMP Guidelines - Applications can utilize ICMP error messages that the UDP layer - passes up for a variety of purposes [RFC1122]. Applications SHOULD - validate the information in the ICMP message payload, e.g., that the - reported error corresponds to a UDP datagram that the application - actually sent. + 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 + 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 are RECOMMENDED to appropriately respond to 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-orientated transport protocols is not always - maintained by UDP-based applications. + Applications SHOULD appropriately respond to 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. One option of securing UDP communications is with IPsec [RFC4301], which can provide authentication for flows of IP packets through the @@ -748,28 +786,30 @@ 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. - Many other options of authenticating or encrypting UDP payloads - exist, including other IETF standards, such as S/MIME [RFC3851] or - PGP [RFC4880], security frameworks such as GSS-API [RFC1964], SASL - [RFC4422] and EAP [RFC3748], as well as many non-IETF protocols. Out - of these, S/MIME and PGP are likely to better suit less immediate and - less ephemeral communications than typically the case for UDP - applications, because they generally require public-key operations - for each message. + Many other options for authenticating or encrypting UDP payloads + exist. These include IETF security frameworks such as GSS-API GSS- + API [RFC2743], SASL [RFC4422] and EAP [RFC3748], which are designed + to provide security services for network protocols. For some + applications, S/MIME [RFC3851] or PGP [RFC4880] might provide a + better solution, because they provide protection for larger + standalone objects such as files or messages. However, they + 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 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. 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 @@ -794,50 +834,58 @@ | else, SHOULD otherwise use bandwidth similar to TCP | | | | | | for non-bulk transfers, | 3.1.2 | | SHOULD measure RTT and transmit 1 message/RTT | | | else, SHOULD send at most 1 message every 3 seconds | | | | | | SHOULD NOT send messages that exceed the PMTU, i.e., | 3.2 | | SHOULD discover PMTU or send messages < minimum PMTU | | | | | | SHOULD handle message loss, duplication, reordering | 3.3 | + | SHOULD be robust to delivery delays up to 2 minutes | | | | | | SHOULD enable UDP checksum | 3.4 | | 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. 6. IANA Considerations This document raises no IANA considerations. 7. Acknowledgments - Thanks to Paul Aitken, Mark Allman, Francois Audet, Stewart Bryant, - Remi Denis-Courmont, Wesley Eddy, Sally Floyd, Jeffrey Hutzelman, - Tero Kivinen, Philip Matthews, Joerg Ott, Colin Perkins, Carlos - Pignataro, Pasi Sarolahti, Joe Touch and Magnus Westerlund for their + Thanks to Paul Aitken, Mark Allman, Francois Audet, Iljitsch van + Beijnum, Stewart Bryant, Remi Denis-Courmont, Wesley Eddy, Sally + Floyd, Jeffrey Hutzelman, Cullen Jennings, Tero Kivinen, Philip + Matthews, Joerg Ott, Colin Perkins, Tom Petch, Carlos Pignataro, Pasi + Sarolahti, Pascal Thubert, Joe Touch and Magnus Westerlund for their comments on this document. The middlebox traversal guidelines in Section 3.5 incorporate ideas from Section 5 of [I-D.ford-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. + 8. References 8.1. Normative References [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. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, @@ -890,66 +938,72 @@ [I-D.ford-behave-app] Ford, B., "Application Design Guidelines for Traversal through Network Address Translators", draft-ford-behave-app-05 (work in progress), March 2007. [I-D.ietf-dccp-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)", - 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] - Handley, M., "TCP Friendly Rate Control (TFRC): Protocol - Specification", draft-ietf-dccp-rfc3448bis-02 (work in - progress), July 2007. + Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP + Friendly Rate Control (TFRC): Protocol Specification", + draft-ietf-dccp-rfc3448bis-04 (work in progress), + January 2008. [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 2007. [I-D.ietf-nsis-nslp-natfw] - Stiemerling, M., "NAT/Firewall NSIS Signaling Layer - Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in - progress), July 2007. + Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, + "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", + draft-ietf-nsis-nslp-natfw-17 (work in progress), + January 2008. [I-D.ietf-nsis-ntlp] Schulzrinne, H. and R. Hancock, "GIST: General Internet - Signalling Transport", draft-ietf-nsis-ntlp-14 (work in - progress), July 2007. + Signalling Transport", draft-ietf-nsis-ntlp-15 (work in + progress), February 2008. [I-D.wing-behave-nat-control-stun-usage] Wing, D., Rosenberg, J., and H. Tschofenig, "Discovering, Querying, and Controlling Firewalls and NATs", draft-wing-behave-nat-control-stun-usage-05 (work in progress), October 2007. [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984. [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, "Common DNS Implementation Errors and Suggested 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, 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. + [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. @@ -1035,20 +1089,22 @@ [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. [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/. + [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 @@ -1061,21 +1118,21 @@ Department of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland Email: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk/ 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 contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF