midcom WG A. Simu Internet-Draft R. Mahy Expires: October 9, 2002 M. Somasundaram Cisco Systems, Inc. April 10, 2002 STUN-aware NAT draft-simu-midcom-stun-aware-nat-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 October 9, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract STUN provides an easy way to traverse some types of NATs and it will work satisfactorily in many NAT deployments. To overcome STUN's limitations, one solution is to accept the idea that NATs can change too (and they've been proven to change, an example being the proliferation of IPsec pass-thru NAT devices) and to colocate STUN server functionality on the NAT box itself. Upon receipt of a STUN request, the server colocated within the NAT device allocates addresses and ports, and installs bindings. This allows hosts running the STUN client software to transparently achieve symmetric NAT traversal and to make themselves addressable from the Global Simu, et al. Expires October 9, 2002 [Page 1] Internet-Draft STUN-aware NAT April 2002 Internet. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operating principle . . . . . . . . . . . . . . . . . . . . . 5 4. Potential STUN extensions for STUN-aware NAT . . . . . . . . . 6 4.1 Simplifying the NAT detection phase . . . . . . . . . . . . . 7 4.2 Timeout detection . . . . . . . . . . . . . . . . . . . . . . 7 4.3 Request a number of consecutive ports . . . . . . . . . . . . 7 4.4 Supporting servers in the private realm . . . . . . . . . . . 8 4.5 TCP handling . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Call Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Registration . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 Incoming Call from a client located in the Global internet . . 11 5.3 Setting up an incoming TCP connection . . . . . . . . . . . . 12 6. Discovery aspects . . . . . . . . . . . . . . . . . . . . . . 13 7. Multi-homed networks . . . . . . . . . . . . . . . . . . . . . 13 8. Backward compatibility . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 A. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 Simu, et al. Expires October 9, 2002 [Page 2] Internet-Draft STUN-aware NAT April 2002 1. Introduction STUN [1] allows applications to discover the presence and types of NATs between them and the public Internet. Moreover, STUN allows applications to determine the public IP addresses (and ports) allocated to them by NATs. There are 2 types of entities in a STUN interaction: the STUN client software, which runs on a host presumably located behind one or more NATs, and STUN servers (one or more) which have to be located in the public Internet address space. The main advantage of STUN (from a new application deployment point of view) is that no modification to the existing NATs is required. By using STUN and other techniques (for example symmetric RTP [2]), applications are able to communicate properly through full-cone, address restricted and port restricted NAT [1]. The main restriction of STUN is that it doesn't work for the most restrictive NAT type -- symmetric. Also, STUN doesn't provide any help for applications which wish to be on the receiving end of a connection. Symmetric NATs need to keep track of both the source IP address and the target IP address (and possibly the IP protocol and ports) for each session (as detailed in [3]). For instance, in the following scenario, a session between Host A and Host B will be defined by a NAT translation (A -> Global-A, B), where Global-A is an address from the Public Realm, assigned to A by the NAT. The IP protocol and port numbers may be included, for example: (TCP, A:port1 -> Global-A:port2, B:port3). Usually the NAT translation gets created when the host from the Private realm initiates communication. Private Public Address Realm Address Realm ---- +--+ +--------------+ ( ) ------ |__| Host B +--+ | | ( ) /____\ Host A |__|----| NAT router |----( ) /____\ | | ( ) +--+ +--------------+ ( ) ------ |__| Host C ---- /____\ Many NAPT implementations are symmetric. Like a port restricted NAT, the translations they operate with contain: (IP protocol, source private IP address:port -> source translated IP address:translated port, target IP address:port). The problem with a symmetric NAT is that network traffic from the same private address and port to two different targets will result in binding to two different global port numbers. This restriction makes it impossible to use an ordinary Simu, et al. Expires October 9, 2002 [Page 3] Internet-Draft STUN-aware NAT April 2002 STUN server to detect the IP address that the NAT will assign for a binding to a given target. For reference, the table below shows what a NAT binding table would look like (for NATs that fall into the four categories described in STUN), after Host A sends a request from port1 to Host B, port X, and from port1 to Host C, port Y. full cone NAT (UDP, A:port1 -> Global-A:port2, *:*) address restricted NAT (UDP, A:port1 -> Global-A:port2, B:*) (UDP, A:port1 -> Global-A:port2, C:*) port restricted NAT (UDP, A:port1 -> Global-A:port2, B:portX) (UDP, A:port1 -> Global-A:port2, C:portY) symmetric NAT (UDP, A:port1 -> Global-A:port2, B:portX) (UDP, A:port1 -> Global-A:port3, C:portY) In order to traverse symmetric NATs without requiring changes to these NATs, all solutions proposed up-to-date require additional entities (NAT relays, Application Proxies, RTP proxies)([4], [5], [6]). These solutions scale very badly, or they're too expensive for small users. If one accepts the idea that NATs can change too (and they've been proven to change, an example being the proliferation of IPsec pass- thru NAT devices) then a simple solution to the STUN's limitations is to run a STUN server on the NAT box itself. Upon receipt of a STUN request, the server colocated within the NAT device should be able to allocate addresses and ports, and install bindings. This allows hosts running the STUN client software to transparently achieve symmetric NAT traversal and to make themselves addressable from the Global Internet. STUN-aware NAT, compared with the other proposals for symmetric NAT traversal, doesn't require extra "fate-sharing" boxes to be involved in the communication. 2. Applicability STUN-aware NAT applies to one of the most deployed NAT scenarios: a private address realm (as in RFC 1918) connected to the global Internet through one NAT device. Applications employing STUN-aware NAT might not work properly if the private address realm re-uses non-RFC 1918 addresses for inside hosts ("twice NAT"). However the same restriction applies to STUN itself [1]. STUN-aware NAT traversal works through Firewalls (as well as STUN itself), if the Firewalls are deployed before the NAT w/STUN box: Simu, et al. Expires October 9, 2002 [Page 4] Internet-Draft STUN-aware NAT April 2002 NAT Host----FW-------w/----------Global Internet STUN 3. Operating principle STUN-Aware NAT is an implementation of a STUN server colocated with a Network Address Translation device, with a simple interface between the two. Host NAT router +-------------+ +----------------------+ | | (1) | +-----------+ | |STUN client <========================>|STUN server| | | | | +-----------+ | | | | | (2) | | | | +-----------+ | |Application <========================>|NAT process| | | | | +-----------+ | | | | | | | | | NAT translation table| +-------------+ +----------------------+ (1): is STUN as defined in [1] (2): is an implementation specific interface. The STUN server should be able to: - retrieve an existing binding for a private address [port] and reset its UDP timeout timer - if no binding exists, ask for the creation of a new binding (if the private address requires translation into the Global realm) New bindings are created in the same way that embedded IP addresses would be translated by a regular NAT ALG when the address that the target will use to send traffic back (to the client) is unknown. If the NAT is an address restricted, port restricted or symmetric NAT, once such a binding is being used by application traffic (initiated from either the Inside or the Outside), the binding should be restricted to include the Outside hosts's address [port]. Once a global address/port are allocated to a private address/port, the next requests to translate the same private address/port will return the same global pair (as long as the original binding is still active). This allows STUN clients to work from behind a NAT which is otherwise symmetric. Simu, et al. Expires October 9, 2002 [Page 5] Internet-Draft STUN-aware NAT April 2002 It is also desirable for some STUN clients to fetch a binding to use for a publicly reachable server. This "server" binding acts like a full cone NAT even if the default UDP binding behavior is address restricted, port restricted, or symmetric. Such a binding allows any number of hosts located in the Public realm to initiate connections to the global address/port, which is translated to the private address. Note that this mechanism is similar with the way ALGs for Registration protocols (such as DNS, H.225 RAS, SIP Register etc.) are traditionally supported, even on symmetric NATs. A STUN aware NAT implementation that accepts server bindings MUST be able to allocate the same global address/port for a private address/ host across multiple STUN requests (as long as the original binding is still active), in order to support inbound connections. As in STUN, the STUN client is responsible for maintaining an active binding by sending occasional keepalive traffic before the UDP binding timeout period expires. More details on how the keepalive mechanism can be optimised for STUN-aware NAT can be found in Section 4.1 and Section 4.2. The STUN server should be configured to use the addresses of the NAT- ed interfaces. The address the NAT will listen on is the address of the interface on the private network. If the NAT is required to use a STUN CHANGED_ADDRESS, it SHOULD use an aliased address for the same interface (to be configured by the network administrator). Once a NAT translation gets created for a particular session, its timeout should be reset for both inbound and outbound packets pertaining to that session which traverse the NAT box. 4. Potential STUN extensions for STUN-aware NAT The number of possible STUN extensions for a STUN-aware NAT is quite large. Below we present some which: o simplify the STUN client algorithm, minimizing the messages exchange (for NAT detection, timeout detection, keepalive) or o simplify and increase the robustness of the NAT with STUN implementation. These extensions assume a certain trust relationship between the client and the server. They should be deployed with caution. More on security issues is discussed in Section 9. Simu, et al. Expires October 9, 2002 [Page 6] Internet-Draft STUN-aware NAT April 2002 4.1 Simplifying the NAT detection phase STUN-aware NAT implies collaboration between a NAT box and the STUN client. In this case, the NAT box can specify its UDP binding behavior to the STUN client, instead of requiring the client to detect it. This can be achieved if the STUN-aware NAT server includes a new attribute type in its responses (NAT_TYPE, with 4 possible values: FULL_CONE, ADDRESS_RESTRICTED, PORT_RESTRICTED, SYMMETRIC). The FULL_CONE attribute is used in conjunction with a TIMEOUT value (see Section 4.2) by the client to determine if the binding is statically configured or dynamically allocated. SYMMETRIC should be used when subsequent requests to translate the same private address/ port might result in different global addresses/port being allocated. Upon receipt of a SYMMETRIC response, the STUN client knows that it has to issue a STUN request each time it needs a public address/port. 4.2 Timeout detection The next step in simplifying the life of a STUN client is to provide it with the timeout of the NAT binding (if the bindings are dynamic). We propose a new STUN attribute type: TIMEOUT (which represents the UDP timeout period for this binding in seconds). The server should send this attribute to inform the client how frequently it needs send network traffic to keep its binding active. In the case of a full cone NAT, with static mappings between private and public addresses, the TIMEOUT value is 0, which conveys that the binding was previously configured and will not timeout unless an administrator takes explicit action to do so. Typical TIMEOUT values for an ORDINARY_BIND (see Section 4.4) vary from 15 seconds to 5 minutes. For a SERVER_BIND, a default TIMEOUT of one hour is RECOMMENDED. 4.3 Request a number of consecutive ports We also propose a new STUN attribute type: NUMBER_OF_PORTS, used in Requests. This facility is very handy for application protocols like RTP/RTCP, which traditionally expect to use consecutive ports. To fetch consecutive ports when the NAT box is not aware of the needed port conventions requires: - complicating the STUN client algorithm Simu, et al. Expires October 9, 2002 [Page 7] Internet-Draft STUN-aware NAT April 2002 - possibly wasting resources (global ports) on the NAT box, which will be allocated, but never used, because they are not consecutive. If NUMBER_OF_PORTS is greater than one, the STUN-aware NAT should allocate the requested number of ports (subject to a policy configured maximum). If the port number from which the STUN request arrived is even, then the STUN aware NAT SHOULD allocate the requested number of ports starting with an even-numbered global port number. If the port number from which the STUN request arrived is odd, then the STUN aware NAT SHOULD allocate the requested number of ports starting with an odd-numbered global port number. The STUN client only needs to send a single STUN Query to allocate the entire group of bindings implied by the NUMBER_OF_PORTS attributes. If the server cannot or will not allocate the consecutive bindings, it should handle the STUN Query as an ordinary Query, and include NUMBER_OF_PORTS=1 in its Response. 4.4 Supporting servers in the private realm NAT ALGs for Registration protocols (such as H.225 RAS, SIP Register etc.) allow private hosts to receive any number of incoming connections. A STUN client should be able to request from the NAT box that it wishes to acquire such a "long-lived" binding. To achieve this, we propose a new request attribute: BINDING_TYPE, with possible values SERVER_BIND and ORDINARY_BIND. A SERVER_BIND binding created on a address restricted, port restricted or symmetric NAT should not be restricted to a specific Outside hosts address and/or port. Instead, a SERVER_BIND needs to act like a FULL_CONE NAT for that binding. Also, a SERVER_BIND binding is expected to have a longer timeout (one hour is RECOMMENDED) than an ORDINARY_BIND. An ORDINARY_BIND acts like a binding normally created by UDP traffic through such a NAT. ORDINARY_BIND bindings are particularly useful for media channels, for example. If no BINDING_TYPE attribute is present, an ORDINARY_BIND is assumed. 4.5 TCP handling STUN supports UDP only. While outgoing TCP traffic works fine through most NATs, it is desirable to provide a solution for incoming TCP without requiring an external relay service. With the cooperation of the NAT, this is entirely feasible. One obvious solution when TCP communications are required, is for the NAT to accept STUN requests running over TCP. Unfortunately this approach comes with the heaviness of TCP (establishing and tearing Simu, et al. Expires October 9, 2002 [Page 8] Internet-Draft STUN-aware NAT April 2002 down a connection). The STUN server on the NAT would become stateful, and as a consequence more prone to DoS attacks. Another alternative, possible only with STUN-aware NAT, is to send STUN requests over UDP to the NAT to request bindings for TCP traffic. Here we define a new STUN attribute type (TCP_TRANSLATION) -- used by STUN clients in Requests. Alternatively, a new flag within the existing STUN FLAG could be used. This approach scales much better than carrying STUN requests over TCP. From the point of view of the NAT implementation, it is easier to process such requests. Of course, the burden is placed on the client, which would have to juggle between using UDP (used by STUN) and TCP (used by the application itself) from the same source port number. 5. Call Flows To illustrate the interaction between different application/network entities, consider 2 SIP examples, both adapted from [7]. Private Public Address Realm Address Realm Proxy 173.2.2.1 ---- +--+ +--------------+ ( ) ------ |__| +--+ | | ( ) /____\ Host A |__|----| NAT router |----( ) 192.168.1.1 /____\ | | ( ) +--+ +--------------+ ( ) ------ |__| ---- /____\ 192.168.1.9 171.21.1.99 Host B 185.3.1.1 Assume that the NAT router is doing NAPT and is configured to translate addresses from the private realm using its Public interface address, 171.21.1.99. 5.1 Registration In this example, the STUN client requests a SERVER_BIND for one hour, and uses this address in a SIP Registration. Note that the example Simu, et al. Expires October 9, 2002 [Page 9] Internet-Draft STUN-aware NAT April 2002 are using the default port number for STUN: 3478. NAT Host A with Proxy STUN | | | | | | |(1) STUN Query | | |source=192.168.1.1:5060 | | |dest=192.168.1.9:3478 | | |BINDING_TYPE=SERVER_BIND | | |----------------------------->| | | | | |(2) STUN Response | | |MAPPED_ADDR=171.21.1.99:9100 | | |NAT_TYPE=FULL_CONE | | |TIMEOUT=3600 | | |source=192.168.1.9:3478 | | |dest=192.168.1.1:5060 | | |<-----------------------------| | | | | |(3) REGISTER | | |Contact: 171.21.1.99:9100 | | |Expires: 3600 | | |source=192.168.1.1:5060 | | |dest=173.2.2.1:5060 | | |----------------------------->| | | |(4) REGISTER | | |Contact: 171.21.1.99:9100 | | |Expires: 3600 | | |source=171.21.1.99:9100 | | |dest=173.2.2.1:5060 | | |-------------------------->| | | | | | (5) 200 OK | | | source=173.2.2.1:8090 | | | dest=171.21.1.99:9100 | | |<--------------------------| | (6) 200 OK | | | source=173.2.2.1:8090 | | | dest=192.168.1.1:5060 | | |<-----------------------------| | | | | Simu, et al. Expires October 9, 2002 [Page 10] Internet-Draft STUN-aware NAT April 2002 5.2 Incoming Call from a client located in the Global internet In this example, Host A receives a SIP INVITE as a result of its earlier registration, and uses STUN to allocate a pair of consecutive bindings for its RTP and RTCP traffic. Note that in this example, Host A assumes that Host B will send RTP using symmetric ports. Since most existing implementations actually send RTP and RTCP from an ephemeral port, we assume that usage of this symmetric RTP convention was communicated using some mechanism outside the scope of this document. NAT Host A with Proxy Host B STUN | | | (7) INVITE | | | |SDP: 185.3.1.1:4500 | | | |src=185.3.1.1:5000 | | | |dst=173.2.2.1:5060 | | | (8) INVITE |<-------------------| | |SDP:185.3.1.1:4500 | | | |src=173.2.2.1:3250 | | | (9) INVITE |dst=171.21.1.99:9100 | | |SDP:185.3.1.1:4500 |<--------------------| | |src=173.2.2.1:3250 | | | |dst=192.168.1.1:5060 | | | |<--------------------| | | | | | | | | | | |(10) STUN Query | | | |src=192.168.1.1:8976 | | | |dst=192.168.1.9:3478 | | | |NUMBER_OF_PORTS=2 | | | |-------------------->| | | | | | | |(11) STUN Response | | | |MAPPED_ADDR= | | | | 171.21.1.99:9554 | | | |NUMBER_OF_PORTS=2 | | | |<--------------------| | | | | | | | | | | |(12) 200 OK | | | |SDP:171.21.1.99:9554 | | | |src=192.168.1.1:5060 | | | |dst=173.2.2.1:5060 | (13) 200 OK | | |-------------------->|SDP:171.21.1.99:9554 | | | |src=171.21.1.99:9100 | | Simu, et al. Expires October 9, 2002 [Page 11] Internet-Draft STUN-aware NAT April 2002 | |dst=173.2.2.1:5060 |(14) 200 OK | | |-------------------->|SDP:171.21.1.99:9554| | | |src=173.2.2.1:5700 | |(15) RTP | |dst=185.3.1.1:5000 | |src=192.168.1.1:8976 | |------------------->| |dst=185.3.1.1:4500 | | | |-------------------->|(16) RTP | | | |src=171.21.1.99:9554 | | |(17) RTCP |dst=185.3.1.1:4500 | | |src=192.168.1.1:8977 |----------------------------------------->| |dst=185.3.1.1:4501 | | | |-------------------->|(18) RTCP | | | |src=171.21.1.99:9555 | | | |dst=185.3.1.1:4501 | | | |----------------------------------------->| | | | | | |<-- (19) SIP ACK -------------------------| |<-- (20) SIP ACK ----| | | | | |(21) RTP | |(22) RTP | |src=185.3.1.1:4500 | |src=185.3.1.1:4500 | |dst=171.21.1.99:9554| |dst=192.168.1.1:8976 |<-----------------------------------------| |<--------------------| | | | | |(23) RTCP | |(24) RTCP | |src=185.3.1.1:4501 | |src=185.3.1.1:4501 | |dst=171.21.1.99:9555| |dst=192.168.1.1:8977 |<-----------------------------------------| |<--------------------| | | | | | | 5.3 Setting up an incoming TCP connection In this example, the STUN client "Alice" wants her peer "Bob" to open a TCP connection to her. She then tells Bob her TCP address using some out-of-band mechanism (an Instant Message or a SIP INVITE for example), and waits for his connection. In this example she might want Bob to start a T.120 whiteboard sharing session with her. Simu, et al. Expires October 9, 2002 [Page 12] Internet-Draft STUN-aware NAT April 2002 STUN NAT TCP Client with Client (Alice) STUN (Bob) | | | |STUN Query ----------------->| | |source=192.168.1.1:5000 | | |dest=192.168.1.2:3478 | | |TCP_TRANSLATION | | | | | | | | |<-- STUN Response -----------| | |MAPPED_ADDR=171.21.1.99:9200 | | |TCP_TRANSLATION | | | | | | | | |-"OK, Open a connection to ->| | | 171.21.1.99:9200" |------------------------>| | | | | |<--- "Got it" -----------| |<----------------------------| | | | | | | | | |<-- TCP SYN -------------| |<--- TCP SYN ----------------|source=173.2.2.1:8070 | |source=173.2.2.1:8070 |dest=171.21.1.99:9200 | |dest=192.168.1.1:5000 | | | | | |---- TCP SYN/ACK ----------->| | | |--- TCP SYN/ACK -------->| | | | | |<-- TCP ACK -------------| |<-- TCP ACK -----------------| | | | | 6. Discovery aspects STUN [1] recommends the use of DNS to discover STUN servers. It is expected however that STUN clients could also be statically configured with the address of the STUN server to use. 7. Multi-homed networks In some scenarios, the translation of a private address to a public one depends on the packet destination. This can happen for instance if the private network is connected to multiple service providers, and each ISP provided a set of public addresses. Simu, et al. Expires October 9, 2002 [Page 13] Internet-Draft STUN-aware NAT April 2002 In such a case, ALGs colocated on a NAT make use of the addresses in a packet header to determine which set of public addresses to use. A simple STUN server colocated with a NAT will not have enough information to make this decision. A simple solution is to configure multiple STUN server addresses on the client. Each address should be an address of an outside NAT interface (towards the public internet). This solution effectively makes the choice the client's problem -- as it is in a regular STUN scenario also. 8. Backward compatibility The extensions proposed in this document are backward compatible with ordinary STUN clients and servers. STUN clients which contact a STUN-aware NAT instead of an ordinary STUN server will simply ignore the extra options provided by the STUN-aware NAT. A STUN client which understands extensions for STUN-aware NAT will fall back to standard STUN behavior when communicating with ordinary STUN server. When the STUN server colocated on a NAT router replies to a STUN request, it should include the new attributes NAT_TYPE and TIMEOUT. This will let STUN aware NAT clients know they are communicating with a STUN-aware NAT. A STUN Aware NAT Server MUST echo back any new client attributes present in the response (ex: TCP_TRANSLATION, BINDING_TYPE, and NUMBER_OF_PORTS). 9. Security Considerations STUN-aware NAT is vulnerable to the same attacks as STUN, with the difference that the domain is limited to the private network. If the private domain is trusted, then STUN-aware NAT and the newly defined STUN attributes can provide a very smooth NAT traversal solution. Administrators SHOULD NOT use the newly defined attribute types in untrusted environments. With STUN-aware NAT, no client authentication is necessary; the main reason being that proxying is not allowed. A client can request a translation only for itself. This is no different from a host generating packets -- it is subject to the same dangers (like a misbehaved client exhausting all resources) which need to be solved anyway by any well-behaved NAT device. STUN Aware NATs need to limit both SERVER_BIND and ORDINARY_BIND Queries to a reasonable maximum number (for example, 4 SERVER-BINDs and 20 ORDINARY_BINDs). STUN Aware NAT Servers MAY also employ additional policy (such as access lists) to constrain the use of STUN. Granting SERVER_BIND bindings doesn't represent a security flaw (a NAT device is not a security mechanism). The decision to allow of Simu, et al. Expires October 9, 2002 [Page 14] Internet-Draft STUN-aware NAT April 2002 not SERVER_BIND bindings is a matter of local policy. A firewall is free to prevent full-cones or server-style bindings. Also note that a STUN aware NAT server MUST NOT accept requests coming from the global Internet. References [1] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of UDP Through NATs", Internet Draft draft- rosenberg-midcom-stun-01.txt, March 2002. [2] Rosenberg, J., Weinberger, J. and H. Schulzrinne, "NAT Friendly SIP", Internet Draft draft-rosenberg-sip-entfw-02.txt, July 2001. [3] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC2663 , August 1999. [4] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "Traversal Using Relay NAT (TURN)", Internet Draft draft- rosenberg-midcom-turn-00.txt, November 2001. [5] Davies, S., Read, S., Scott, B. and P. Cordell, "Traversal of non-Protocol Aware Firewalls and NATS", Internet Draft draft- davies-fw-nat-traversal-01.txt, October 2001. [6] Sen, S., Sollee, P. and S. March, "Midcom-unaware NAT/Firewall Traversal", Internet Draft draft-sen-midcom-fw-nat-00.txt, September 2001. [7] Rosenberg, J., Mahy, R. and S. Sen, "NAT and Firewall Scenarios and Solutions for SIP", Internet Draft draft-rosenberg-sipping- nat-scenarios-00.txt, November 2001. Authors' Addresses Adina Simu Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: asimu@cisco.com Simu, et al. Expires October 9, 2002 [Page 15] Internet-Draft STUN-aware NAT April 2002 Rohan Mahy Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: rohan@cisco.com Mahadev Somasundaram Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: mahadev@cisco.com Appendix A. To Do Need to add sections that describe specific normative behavior for STUN-Aware NATs, and their clients. Simu, et al. Expires October 9, 2002 [Page 16] Internet-Draft STUN-aware NAT April 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Simu, et al. Expires October 9, 2002 [Page 17]