draft-ietf-tsvwg-udp-guidelines-05.txt   draft-ietf-tsvwg-udp-guidelines-06.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: BCP G. Fairhurst
Practice University of Aberdeen Expires: October 5, 2008 University of Aberdeen
Expires: August 8, 2008 February 5, 2008 April 3, 2008
UDP Usage Guidelines for Application Designers UDP Usage Guidelines for Application Designers
draft-ietf-tsvwg-udp-guidelines-05 draft-ietf-tsvwg-udp-guidelines-06
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 August 8, 2008. This Internet-Draft will expire on October 5, 2008.
Copyright Notice
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 20 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . 11 3.3. Reliability Guidelines . . . . . . . . . . . . . . . . . . 11
3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 12 3.4. Checksum Guidelines . . . . . . . . . . . . . . . . . . . 12
3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 13 3.5. Middlebox Traversal Guidelines . . . . . . . . . . . . . . 13
3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 15 3.6. Programming Guidelines . . . . . . . . . . . . . . . . . . 15
3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 17 3.7. ICMP Guidelines . . . . . . . . . . . . . . . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 26
skipping to change at page 7, line 27 skipping to change at page 7, line 27
3.1.2. Low Data-Volume Applications 3.1.2. Low Data-Volume Applications
When applications that exchange only a small number of messages with When applications that exchange only a small number of messages with
a destination at any time implement TFRC or one of the other a destination at any time implement TFRC or one of the other
congestion control schemes in Section 3.1.1, the network sees little congestion control schemes in Section 3.1.1, the network sees little
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 on average more than one UDP message per
(RTT) to a destination. Similar to the recommendation in [RFC1536], round-trip time(RTT) to a destination. Similar to the recommendation
an application SHOULD maintain an estimate of the RTT for any in [RFC1536], an application SHOULD maintain an estimate of the RTT
destination with which it communicates. Applications SHOULD for any 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. They SHOULD also detect packet loss and RTT (SRTT) estimate. They SHOULD also detect packet loss and
exponentially back-off their retransmission timer when a loss event exponentially back-off their retransmission timer when a loss event
occurs. When implementing this scheme, applications need to choose a occurs. When implementing this scheme, applications need to choose a
sensible initial value for the RTT. This value SHOULD generally be sensible initial value for the RTT. This value SHOULD generally be
as conservative as possible for the given application. TCP uses an 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 of 3 seconds [RFC2988], which is also RECOMMENDED as an
initial value for UDP applications. SIP [RFC3261] and GIST initial value for UDP applications. SIP [RFC3261] and GIST
[I-D.ietf-nsis-ntlp] use an initial value of 500 ms, and initial [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 timeouts that are shorter than this are likely problematic in many
skipping to change at page 10, line 21 skipping to change at page 10, line 21
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.
Designing tunneling mechanism requires significantly more expertise Designing a 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
IP fragmentation lowers the efficiency and reliability of Internet IP fragmentation lowers the efficiency and reliability of Internet
skipping to change at page 11, line 25 skipping to change at page 11, line 25
larger PMTU, which is a second reason to implement PMTU discovery. larger PMTU, which is a second reason to implement PMTU discovery.
To determine an appropriate UDP payload size, applications MUST To determine an appropriate UDP payload size, applications MUST
subtract the size of the IP header (which includes any IPv4 optional 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 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, header (8 bytes) from the PMTU size. This size, known as the MMS_S,
can be obtained from the TCP/IP stack [RFC1122]. can be obtained from the TCP/IP stack [RFC1122].
Applications that do not send messages that exceed the effective PMTU Applications that do not send messages that exceed the effective PMTU
of IPv4 or IPv6 need not implement any of the above mechanisms. Note of IPv4 or IPv6 need not implement any of the above mechanisms. Note
that the presence of tunnels can cause fragmentation even when that the presence of tunnels can cause an additional reduction of the
applications send messages that do not exceed the effective PMTU, so effective PMTU, so implementing PMTU discovery will still be
implementing PMTU discovery will still be beneficial in some cases. beneficial in some cases.
3.3. Reliability Guidelines 3.3. Reliability Guidelines
Application designers are generally aware that UDP does not provide Application designers are generally aware that UDP does not provide
any reliability, e.g., it does not retransmit any lost packets. any reliability, e.g., it does not retransmit any lost packets.
Often, this is a main reason to consider UDP as a transport. Often, this is a main reason to consider UDP as a transport.
Applications that do require reliable message delivery MUST implement Applications that do require reliable message delivery MUST implement
an appropriate mechanism themselves. an appropriate mechanism themselves.
UDP also does not protect against message duplication, i.e., an UDP also does not protect against message duplication, i.e., an
skipping to change at page 13, line 41 skipping to change at page 13, line 41
The receiver MUST set a minimum coverage threshold for incoming The receiver MUST set a minimum coverage threshold for incoming
packets that is not smaller than the smallest coverage used by the packets that is not smaller than the smallest coverage used by the
sender. This may be a fixed value, or may be negotiated by an sender. This may be a fixed value, or may be negotiated by an
application. UDP-Lite does not provide mechanisms to negotiate the application. UDP-Lite does not provide mechanisms to negotiate the
checksum coverage between the sender and receiver. checksum coverage between the sender and receiver.
Applications may still experience packet loss, rather than Applications may still experience packet loss, rather than
corruption, when using UDP-Lite. The enhancements offered by UDP- corruption, when using UDP-Lite. The enhancements offered by UDP-
Lite rely upon a link being able to intercept the UDP-Lite header to Lite rely upon a link being able to intercept the UDP-Lite header to
correctly identify the partial-coverage required. When tunnels correctly identify the partial coverage required. When tunnels
and/or encryption are used, this can result in UDP-Lite messages and/or encryption are used, this can result in UDP-Lite messages
being treated the same as UDP messages, i.e., result in packet loss. being treated the same as UDP messages, i.e., result in packet loss.
Use of IP fragmentation can also prevent special treatment for UDP- Use of IP fragmentation can also prevent special treatment for UDP-
Lite messages, and is another reason why applications SHOULD avoid IP Lite messages, and is another reason why applications SHOULD avoid IP
fragmentation Section 3.2. fragmentation Section 3.2.
3.5. Middlebox Traversal Guidelines 3.5. Middlebox Traversal Guidelines
Network address translators (NATs) and firewalls are examples of Network address translators (NATs) and firewalls are examples of
intermediary devices ("middleboxes") that can exist along an end-to- intermediary devices ("middleboxes") that can exist along an end-to-
skipping to change at page 15, line 13 skipping to change at page 15, line 13
state for arbitrary middleboxes. For NATs, [RFC4787] requires a state for arbitrary middleboxes. For NATs, [RFC4787] requires a
state timeout of 2 minutes or longer. However, empirical evidence state timeout of 2 minutes or longer. However, empirical evidence
suggests that a significant fraction of the deployed middleboxes suggests that a significant fraction of the deployed middleboxes
unfortunately uses shorter timeouts. The timeout of 15 seconds unfortunately uses shorter timeouts. The timeout of 15 seconds
originates with the Interactive Connectivity Establishment (ICE) originates with the Interactive Connectivity Establishment (ICE)
protocol [I-D.ietf-mmusic-ice]. Applications that operate in more protocol [I-D.ietf-mmusic-ice]. Applications that operate in more
controlled network environments SHOULD investigate whether the controlled network environments SHOULD investigate whether the
environment they operate in allows them to use longer intervals, or environment they operate in allows them to use longer intervals, or
whether it offers mechanisms to explicitly control middlebox state whether it offers mechanisms to explicitly control middlebox state
timeout durations, for example, using MIDCOM [RFC3303], NSIS timeout durations, for example, using MIDCOM [RFC3303], NSIS
[I-D.ietf-nsis-nslp-natfw], STUN [I-D.ietf-nsis-nslp-natfw] or UPnP [UPNP].
[I-D.wing-behave-nat-control-stun-usage] or UPnP [UPNP].
It is important to note that sending keep-alives is not a substitute It is important to note that sending keep-alives is not a substitute
for implementing robust connection handling. Like all UDP messages, for implementing robust connection handling. Like all UDP messages,
keep-alives can be delayed or dropped, causing middlebox state to keep-alives can be delayed or dropped, causing middlebox state to
time out. In addition, the congestion control guidelines in time out. In addition, the congestion control guidelines in
Section 3.1 cover all UDP transmissions by an application, including Section 3.1 cover all UDP transmissions by an application, including
the transmission of middlebox keep-alives. Congestion control may the transmission of middlebox keep-alives. Congestion control may
thus lead to delays or temporary suspension of keep-alive thus lead to delays or temporary suspension of keep-alive
transmission. transmission.
skipping to change at page 16, line 21 skipping to change at page 16, line 20
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
simplify the local send/receive functions and to filter the traffic simplify the local send/receive functions and to filter the traffic
for the specified addresses and ports. Binding a UDP socket does not for the specified addresses and ports. Binding a UDP socket does not
establish a connection - UDP does not notify the remote end when a establish a connection - UDP does not notify the remote end when a
local UDP socket is bound. Binding a socket also allows configuring 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 options that affect the UDP or IP layers, for example, use of the UDP
checksum or IP source routing. On some stacks, a bound socket also checksum or the IP Time Stamp Option. On some stacks, a bound socket
allows an application to be notified when ICMP error messages are also allows an application to be notified when ICMP error messages
received for its transmissions [RFC1122]. are received for its transmissions [RFC1122].
UDP provides no flow-control. This is another reason why UDP-based UDP provides no flow-control. This is another reason why UDP-based
applications need to be robust in the presence of packet loss. This applications need to be robust in the presence of packet loss. This
loss can also occur within the sending host, when an application loss can also occur within the sending host, when an application
sends data faster than the line rate of the outbound network sends data faster than the line rate of the outbound network
interface. It can also occur on the destination, where receive calls interface. It can also occur on the destination, where receive calls
fail to return data when the application issues them too frequently fail to return all the data that was sent when the application issues
(i.e., when no new data has arrived) or not frequently enough (i.e., them too infrequently (i.e., such that the receive buffer overflows).
such that the receive buffer overflows). Robust flow control Robust flow control mechanisms are difficult to implement, which is
mechanisms are difficult to implement, which is why applications that why applications that need this functionality SHOULD consider using a
need this functionality SHOULD consider using a full-featured full-featured transport protocol.
transport protocol.
When an application closes a TCP, SCTP or DCCP socket, the transport When an application closes a TCP, SCTP or DCCP socket, the transport
protocol on the receiving host is required to maintain TIME-WAIT protocol on the receiving host is required to maintain TIME-WAIT
state. This prevents delayed packets from the closed connection state. This prevents delayed packets from the closed connection
instance from being mistakenly associated with a later connection instance from being mistakenly associated with a later connection
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 be robust in this case. One
may close a socket or terminate, followed in time by another application may close a socket or terminate, followed in time by
application receiving on the same port. This later application may another application receiving on the same port. This later
then receive packets intended for the first application that were application may then receive packets intended for the first
delayed in the network. application that were delayed in the network.
3.7. ICMP Guidelines 3.7. ICMP Guidelines
Applications can utilize information about ICMP error messages that Applications can utilize information about ICMP error messages that
the UDP layer passes up for a variety of purposes [RFC1122]. the UDP layer passes up for a variety of purposes [RFC1122].
Applications SHOULD validate that the information in the ICMP message Applications SHOULD validate that the information in the ICMP message
payload, e.g., a reported error condition, corresponds to a UDP payload, e.g., a reported error condition, corresponds to a UDP
datagram that the application actually sent. Note that not all APIs datagram that the application actually sent. Note that not all APIs
have the necessary functions to support this validation, and some have the necessary functions to support this validation, and some
APIs already perform this validation internally before passing ICMP APIs already perform this validation internally before passing ICMP
skipping to change at page 18, line 8 skipping to change at page 17, line 50
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 for authenticating or encrypting UDP payloads Many other options for authenticating or encrypting UDP payloads
exist. These include IETF security frameworks such as GSS-API GSS- exist. These include IETF security frameworks such as GSS-API
API [RFC2743], SASL [RFC4422] and EAP [RFC3748], which are designed [RFC2743], SASL [RFC4422] and EAP [RFC3748], which are designed to
to provide security services for network protocols. For some provide security services for network protocols. The IETF standard
applications, S/MIME [RFC3851] or PGP [RFC4880] might provide a for securing RTP [RFC3550] realtime communication sessions over UDP
better solution, because they provide protection for larger is SRTP [RFC3711]. For some other applications, S/MIME [RFC3851] or
standalone objects such as files or messages. However, they PGP [RFC4880] might provide a better solution, because they provide
generally involve public-key operations on an entire object, which protection for larger standalone objects such as files or messages.
can have performance implications. In addition, there are many non- However, they generally involve public-key operations on an entire
IETF protocols in this area. 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 21, line 36 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-01 (work in progress), draft-ietf-dccp-ccid4-02 (work in progress),
November 2007. February 2008.
[I-D.ietf-dccp-rfc3448bis] [I-D.ietf-dccp-rfc3448bis]
Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
draft-ietf-dccp-rfc3448bis-04 (work in progress), draft-ietf-dccp-rfc3448bis-05 (work in progress),
January 2008. February 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., Tschofenig, H., Aoun, C., and E. Davies, Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies,
"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
draft-ietf-nsis-nslp-natfw-17 (work in progress), draft-ietf-nsis-nslp-natfw-18 (work in progress),
January 2008. February 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-15 (work in Signalling Transport", draft-ietf-nsis-ntlp-15 (work in
progress), February 2008. 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", [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.
[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,
skipping to change at page 23, line 21 skipping to change at page 23, line 16
RFC 3493, February 2003. RFC 3493, February 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. 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 [RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
Control (WEBRC) Building Block", RFC 3738, April 2004. Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP) Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, May 2004. Partial Reliability Extension", RFC 3758, May 2004.
skipping to change at page 26, line 44 skipping to change at line 1159
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 19 change blocks. 
56 lines changed or deleted 49 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/