draft-ietf-behave-rfc3489bis-05.txt   draft-ietf-behave-rfc3489bis-06.txt 
BEHAVE J. Rosenberg BEHAVE J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco
Expires: April 26, 2007 C. Huitema Obsoletes: 3489 (if approved) C. Huitema
Microsoft Intended status: Standards Track Microsoft
R. Mahy Expires: September 6, 2007 R. Mahy
Plantronics Plantronics
D. Wing D. Wing
Cisco Systems Cisco Systems
October 23, 2006 March 5, 2007
Simple Traversal Underneath Network Address Translators (NAT) (STUN) Session Traversal Utilities for (NAT) (STUN)
draft-ietf-behave-rfc3489bis-05 draft-ietf-behave-rfc3489bis-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 39 skipping to change at page 1, line 39
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 April 26, 2007. This Internet-Draft will expire on September 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Simple Traversal Underneath NATs (STUN) is a lightweight protocol Session Traversal Utilities for NAT (STUN) is a lightweight protocol
that serves as a tool for application protocols in dealing with NAT that serves as a tool for application protocols in dealing with NAT
traversal. It allows a client to determine the IP address and port traversal. It allows a client to determine the IP address and port
allocated to them by a NAT and to keep NAT bindings open. It can allocated to them by a NAT and to keep NAT bindings open. It can
also serve as a check for connectivity between a client and a server also serve as a check for connectivity between a client and a server
in the presence of NAT, and for the client to detect failure of the in the presence of NAT, and for the client to detect failure of the
server. STUN works with many existing NATs, and does not require any server. STUN works with many existing NATs, and does not require any
special behavior from them. As a result, it allows a wide variety of special behavior from them. As a result, it allows a wide variety of
applications to work through existing NAT infrastructure. applications to work through existing NAT infrastructure.
Table of Contents Table of Contents
skipping to change at page 3, line 20 skipping to change at page 3, line 20
12.1.5. New Attributes . . . . . . . . . . . . . . . . . . . . 38 12.1.5. New Attributes . . . . . . . . . . . . . . . . . . . . 38
12.1.6. New Error Response Codes . . . . . . . . . . . . . . . 38 12.1.6. New Error Response Codes . . . . . . . . . . . . . . . 38
12.1.7. Client Procedures . . . . . . . . . . . . . . . . . . 38 12.1.7. Client Procedures . . . . . . . . . . . . . . . . . . 38
12.1.8. Server Procedures . . . . . . . . . . . . . . . . . . 38 12.1.8. Server Procedures . . . . . . . . . . . . . . . . . . 38
12.1.9. Security Considerations for Binding Discovery . . . . 38 12.1.9. Security Considerations for Binding Discovery . . . . 38
12.2. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 39 12.2. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 39
12.2.1. Applicability . . . . . . . . . . . . . . . . . . . . 39 12.2.1. Applicability . . . . . . . . . . . . . . . . . . . . 39
12.2.2. Client Discovery of Server . . . . . . . . . . . . . . 39 12.2.2. Client Discovery of Server . . . . . . . . . . . . . . 39
12.2.3. Server Determination of Usage . . . . . . . . . . . . 39 12.2.3. Server Determination of Usage . . . . . . . . . . . . 39
12.2.4. New Requests or Indications . . . . . . . . . . . . . 39 12.2.4. New Requests or Indications . . . . . . . . . . . . . 39
12.2.5. New Attributes . . . . . . . . . . . . . . . . . . . . 39 12.2.5. New Attributes . . . . . . . . . . . . . . . . . . . . 40
12.2.6. New Error Response Codes . . . . . . . . . . . . . . . 40 12.2.6. New Error Response Codes . . . . . . . . . . . . . . . 40
12.2.7. Client Procedures . . . . . . . . . . . . . . . . . . 40 12.2.7. Client Procedures . . . . . . . . . . . . . . . . . . 40
12.2.8. Server Procedures . . . . . . . . . . . . . . . . . . 40 12.2.8. Server Procedures . . . . . . . . . . . . . . . . . . 40
12.2.9. Security Considerations for NAT Keepalives . . . . . . 40 12.2.9. Security Considerations for NAT Keepalives . . . . . . 40
12.3. Short-Term Password . . . . . . . . . . . . . . . . . . . 41 12.3. Short-Term Password . . . . . . . . . . . . . . . . . . . 41
12.3.1. Applicability . . . . . . . . . . . . . . . . . . . . 41 12.3.1. Applicability . . . . . . . . . . . . . . . . . . . . 41
12.3.2. Client Discovery of Server . . . . . . . . . . . . . . 41 12.3.2. Client Discovery of Server . . . . . . . . . . . . . . 41
12.3.3. Server Determination of Usage . . . . . . . . . . . . 41 12.3.3. Server Determination of Usage . . . . . . . . . . . . 42
12.3.4. New Requests or Indications . . . . . . . . . . . . . 42 12.3.4. New Requests or Indications . . . . . . . . . . . . . 42
12.3.5. New Attributes . . . . . . . . . . . . . . . . . . . . 42 12.3.5. New Attributes . . . . . . . . . . . . . . . . . . . . 43
12.3.6. New Error Response Codes . . . . . . . . . . . . . . . 42 12.3.6. New Error Response Codes . . . . . . . . . . . . . . . 43
12.3.7. Client Procedures . . . . . . . . . . . . . . . . . . 43 12.3.7. Client Procedures . . . . . . . . . . . . . . . . . . 43
12.3.8. Server Procedures . . . . . . . . . . . . . . . . . . 43 12.3.8. Server Procedures . . . . . . . . . . . . . . . . . . 43
12.3.9. Security Considerations for Short-Term Password . . . 44 12.3.9. Security Considerations for Short-Term Password . . . 44
13. Security Considerations . . . . . . . . . . . . . . . . . . . 45 13. Security Considerations . . . . . . . . . . . . . . . . . . . 45
13.1. Attacks on STUN . . . . . . . . . . . . . . . . . . . . . 45 13.1. Attacks on STUN . . . . . . . . . . . . . . . . . . . . . 45
13.1.1. Attack I: DDoS Against a Target . . . . . . . . . . . 45 13.1.1. Attack I: DDoS Against a Target . . . . . . . . . . . 46
13.1.2. Attack II: Silencing a Client . . . . . . . . . . . . 46 13.1.2. Attack II: Silencing a Client . . . . . . . . . . . . 46
13.1.3. Attack III: Assuming the Identity of a Client . . . . 46 13.1.3. Attack III: Assuming the Identity of a Client . . . . 46
13.1.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 46 13.1.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 46
13.2. Launching the Attacks . . . . . . . . . . . . . . . . . . 46 13.2. Launching the Attacks . . . . . . . . . . . . . . . . . . 47
13.2.1. Approach I: Compromise a Legitimate STUN Server . . . 47 13.2.1. Approach I: Compromise a Legitimate STUN Server . . . 47
13.2.2. Approach II: DNS Attacks . . . . . . . . . . . . . . . 47 13.2.2. Approach II: DNS Attacks . . . . . . . . . . . . . . . 47
13.2.3. Approach III: Rogue Router or NAT . . . . . . . . . . 47 13.2.3. Approach III: Rogue Router or NAT . . . . . . . . . . 48
13.2.4. Approach IV: Man in the Middle . . . . . . . . . . . . 48 13.2.4. Approach IV: Man in the Middle . . . . . . . . . . . . 48
13.2.5. Approach V: Response Injection Plus DoS . . . . . . . 48 13.2.5. Approach V: Response Injection Plus DoS . . . . . . . 49
13.2.6. Approach VI: Duplication . . . . . . . . . . . . . . . 49 13.2.6. Approach VI: Duplication . . . . . . . . . . . . . . . 49
13.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 50 13.3. Countermeasures . . . . . . . . . . . . . . . . . . . . . 50
13.4. Residual Threats . . . . . . . . . . . . . . . . . . . . 51 13.4. Residual Threats . . . . . . . . . . . . . . . . . . . . 51
14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 51 14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 51
14.1. Problem Definition . . . . . . . . . . . . . . . . . . . 51 14.1. Problem Definition . . . . . . . . . . . . . . . . . . . 52
14.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 52 14.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 52
14.3. Brittleness Introduced by STUN . . . . . . . . . . . . . 52 14.3. Brittleness Introduced by STUN . . . . . . . . . . . . . 52
14.4. Requirements for a Long Term Solution . . . . . . . . . . 53 14.4. Requirements for a Long Term Solution . . . . . . . . . . 54
14.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 54 14.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 55
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
15.1. STUN Methods Registry . . . . . . . . . . . . . . . . . . 55 15.1. STUN Methods Registry . . . . . . . . . . . . . . . . . . 55
15.2. STUN Attribute Registry . . . . . . . . . . . . . . . . . 55 15.2. STUN Attribute Registry . . . . . . . . . . . . . . . . . 55
16. Changes Since RFC 3489 . . . . . . . . . . . . . . . . . . . . 56 16. Changes Since RFC 3489 . . . . . . . . . . . . . . . . . . . . 56
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
18.1. Normative References . . . . . . . . . . . . . . . . . . 57 18.1. Normative References . . . . . . . . . . . . . . . . . . 57
18.2. Informational References . . . . . . . . . . . . . . . . 58 18.2. Informational References . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59
Intellectual Property and Copyright Statements . . . . . . . . . . 61 Intellectual Property and Copyright Statements . . . . . . . . . . 61
1. Applicability Statement 1. Applicability Statement
This protocol is not a cure-all for the problems associated with NAT. This protocol is not a cure-all for the problems associated with NAT.
It is a tool that is typically used in conjunction with other It is a tool that is typically used in conjunction with other
protocols, such as Interactive Connectivity Establishment (ICE) [13] protocols, such as Interactive Connectivity Establishment (ICE) [13]
for a more complete solution. The binding discovery usage, defined for a more complete solution. The binding discovery usage, defined
by this specification, can be used by itself with numerous by this specification, can be used by itself with numerous
application protocols as a solution for NAT traversal. However, when application protocols as a solution for NAT traversal. However, when
skipping to change at page 6, line 21 skipping to change at page 6, line 21
the message. ALGs have serious limitations, including scalability, the message. ALGs have serious limitations, including scalability,
reliability, and speed of deploying new applications. reliability, and speed of deploying new applications.
Many existing proprietary protocols, such as those for online games Many existing proprietary protocols, such as those for online games
(such as the games described in RFC3027 [21]) and Voice over IP, have (such as the games described in RFC3027 [21]) and Voice over IP, have
developed tricks that allow them to operate through NATs without developed tricks that allow them to operate through NATs without
changing those NATs and without relying on ALG behavior in the NATs. changing those NATs and without relying on ALG behavior in the NATs.
This document takes some of those ideas and codifies them into an This document takes some of those ideas and codifies them into an
interoperable protocol that can meet the needs of many applications. interoperable protocol that can meet the needs of many applications.
The protocol described here, Simple Traversal Underneath NAT (STUN), The protocol described here, Session Traversal Utilities for NAT
provides a toolkit of functions. These functions allow entities (STUN), provides a toolkit of functions. These functions allow
behind a NAT to learn the address bindings allocated by the NAT and entities behind a NAT to learn the address bindings allocated by the
to keep those bindings open. STUN requires no changes to NATs and NAT and to keep those bindings open. STUN requires no changes to
works with an arbitrary number of NATs in tandem between the NATs and works with an arbitrary number of NATs in tandem between the
application entity and the public Internet. application entity and the public Internet.
3. Terminology 3. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[1] and indicate requirement levels for compliant STUN [1] and indicate requirement levels for compliant STUN
implementations. implementations.
4. Definitions 4. Definitions
STUN Client: A STUN client (also just referred to as a client) is an STUN Client: A STUN client (also just referred to as a client) is an
entity that generates STUN requests and receives STUN responses. entity that generates STUN requests and receives STUN responses.
Clients can also generate STUN indications. Clients can also generate STUN indications.
STUN Server: A STUN Server (also just referred to as a server) is an STUN Server: A STUN Server (also just referred to as a server) is an
entity that receives STUN requests and sends STUN responses. entity that receives STUN requests and sends STUN responses.
Servers also send STUN indications. Servers also send STUN indications.
Transport Address: The combination of an IP address and (UDP or TCP) Transport Address: The combination of an IP address and transport
port. protocol (such as UDP or TCP) port.
Reflexive Transport Address: A transport address learned by a client Reflexive Transport Address: A transport address learned by a client
that identifies that client as seen by another host on an IP that identifies that client as seen by another host on an IP
network, typically a STUN server. When there is an intervening network, typically a STUN server. When there is an intervening
NAT between the client and the other host, the reflexive transport NAT between the client and the other host, the reflexive transport
address represents the binding allocated to the client on the address represents the binding allocated to the client on the
public side of the NAT. Reflexive transport addresses are learned public side of the NAT. Reflexive transport addresses are learned
from the mapped address attribute (MAPPED-ADDRESS or XOR-MAPPED- from the mapped address attribute (MAPPED-ADDRESS or XOR-MAPPED-
ADDRESS) in STUN responses. ADDRESS) in STUN responses.
skipping to change at page 12, line 33 skipping to change at page 12, line 33
The most significant two bits of every STUN message are both zeroes. The most significant two bits of every STUN message are both zeroes.
This, combined with the magic cookie and the fingerprint attribute, This, combined with the magic cookie and the fingerprint attribute,
aid in differentiating STUN packets from other protocols when STUN is aid in differentiating STUN packets from other protocols when STUN is
multiplexed with other protocols on the same port. multiplexed with other protocols on the same port.
The message type field is decomposed further into the following The message type field is decomposed further into the following
structure: structure:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|M|M|M|M|C|M|M|M|C|M|M|M|M| |M|M|M|M|M|C|M|M|M|C|M|M|M|M|
|1|1|9|8|7|1|6|5|4|0|3|2|2|0| |1|1|9|8|7|1|6|5|4|0|3|2|1|0|
|1|0| | | | | | | | | | | | | |1|0| | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of STUN Message Type Field Figure 3: Format of STUN Message Type Field
M11 through M0 represent a 12-bit encoding of the method. C1 through M11 through M0 represent a 12-bit encoding of the method. C1 through
C0 represent a 2 bit encoding of the class. A class of 0 is a C0 represent a 2 bit encoding of the class. A class of 0 is a
Request, a class of 1 is an indication, a class of 2 is a success Request, a class of 1 is an indication, a class of 2 is a success
response, and a class of 3 is an error response. This specification response, and a class of 3 is an error response. This specification
defines two methods, Binding and Shared Secret. Their method values defines two methods, Binding and Shared Secret. Their method values
skipping to change at page 18, line 49 skipping to change at page 18, line 49
equal to 0x2112A442), the FINGERPRINT attribute MUST be present. equal to 0x2112A442), the FINGERPRINT attribute MUST be present.
Otherwise, its inclusion is RECOMMENDED. Otherwise, its inclusion is RECOMMENDED.
Next, the client sends the request. For UDP-based requests, Next, the client sends the request. For UDP-based requests,
reliability is accomplished through client retransmissions, following reliability is accomplished through client retransmissions, following
the procedure in Section 7.1. For TCP (including TLS over TCP), the procedure in Section 7.1. For TCP (including TLS over TCP),
there are no retransmissions. there are no retransmissions.
For TCP and TLS over TCP, the client MAY send multiple requests on For TCP and TLS over TCP, the client MAY send multiple requests on
the connection. When using TCP or TLS over TCP, the client SHOULD the connection. When using TCP or TLS over TCP, the client SHOULD
close the connection as soon as it has received the STUN Response, if keep the connection open until it has no further requests to send,
it has no plans to send further requests. and has no plans to use any resources (such as a mapped address or
relayed address [16]) learned though STUN requests sent over that
connection.
Regardless of the transport protocol, a client MAY pipeline requests Regardless of the transport protocol, a client MAY pipeline requests
(that is, it can have multiple requests outstanding at the same (that is, it can have multiple requests outstanding at the same
time). time).
8.3.2. Processing Responses 8.3.2. Processing Responses
Once the client has received a response to its request that it did Once the client has received a response to its request that it did
not discard, it MUST discard any further responses for the same not discard, it MUST discard any further responses for the same
request. request.
skipping to change at page 57, line 22 skipping to change at page 57, line 40
Mankin, Eric Rescorla, and Henning Schulzrinne for IESG and IAB input Mankin, Eric Rescorla, and Henning Schulzrinne for IESG and IAB input
on this work. on this work.
18. References 18. References
18.1. Normative References 18.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [2] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[5] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [5] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[6] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating [6] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Denial of Service Attacks which employ IP Source Address Defeating Denial of Service Attacks which employ IP Source
Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[7] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [7] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999. Basic and Digest Access Authentication", RFC 2617, June 1999.
[8] Paxson, V. and M. Allman, "Computing TCP's Retransmission [8] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[9] International Telecommunications Union, "Error-correcting [9] International Telecommunications Union, "Error-correcting
Procedures for DCEs Using Asynchronous-to-Synchronous Procedures for DCEs Using Asynchronous-to-Synchronous
skipping to change at page 58, line 20 skipping to change at page 58, line 35
[11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[12] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [12] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[13] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [13] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-11 (work in Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in
progress), October 2006. progress), January 2007.
[14] Audet, F. and C. Jennings, "NAT Behavioral Requirements for [14] Audet, F. and C. Jennings, "NAT Behavioral Requirements for
Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress), Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress),
October 2006. October 2006.
[15] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN [15] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through - Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003. Network Address Translators (NATs)", RFC 3489, March 2003.
[16] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal [16] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in
progress), October 2006. progress), October 2006.
[17] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [17] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications",
RFC 3550, July 2003. RFC 3550, July 2003.
[18] Jennings, C. and R. Mahy, "Managing Client Initiated [18] Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-04 (work in progress), June 2006. draft-ietf-sip-outbound-07 (work in progress), January 2007.
[19] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [19] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[20] Senie, D., "Network Address Translator (NAT)-Friendly [20] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002. Application Design Guidelines", RFC 3235, January 2002.
[21] Holdrege, M. and P. Srisuresh, "Protocol Complications with the [21] Holdrege, M. and P. Srisuresh, "Protocol Complications with the
IP Network Address Translator", RFC 3027, January 2001. IP Network Address Translator", RFC 3027, January 2001.
skipping to change at page 60, line 8 skipping to change at page 59, line 36
Address Fixing (UNSAF) Across Network Address Translation", Address Fixing (UNSAF) Across Network Address Translation",
RFC 3424, November 2002. RFC 3424, November 2002.
[25] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [25] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco
600 Lanidex Plaza Edison, NJ
Parsippany, NJ 07054
US US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Christian Huitema Christian Huitema
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
US US
Email: huitema@microsoft.com Email: huitema@microsoft.com
skipping to change at page 61, line 5 skipping to change at page 61, line 5
Email: rohan@ekabal.com Email: rohan@ekabal.com
Dan Wing Dan Wing
Cisco Systems Cisco Systems
771 Alder Drive 771 Alder Drive
San Jose, CA 95035 San Jose, CA 95035
US US
Email: dwing@cisco.com Email: dwing@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 61, line 29 skipping to change at page 61, line 45
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.
Disclaimer of Validity
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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 29 change blocks. 
60 lines changed or deleted 61 lines changed or added

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