Use of a router that has a NAT (Network Address Translation) feature has been intervening in accessing from the external network to the internal network which is evidently a problem for peer-to-peer applications such as voice communication over the Internet (known as VoIP) and/or online gaming, etc. NAT is an Internet standard that enables a local area network (LAN) to use of one set of private IP addresses for internal traffic and a second set of global IP addresses for external traffic. A node that has NAT capability is often referred as “NAT box”.
A NAT (literally) translates network (IP) address between the two networks. Network Address Port Translation (NAPT) translates not only IP address but also port numbers of a transport layer protocol. Although NAT/NAPT has its good properties, there is a significant side effect. If the translation is dynamically performed, nodes in the external network have no way to know the IP address (and the port number) on the NAT ahead of time to reach a node in the internal network. Unfortunately, this is the most common behavior of NAT in the residential and SOHO routers deployed in the current market.
NAPT (hereinafter, called “NAT” unless stated otherwise) is the most common NAT in today's residential routers. In a NAT, an IP address is used to identify an end node, or a host. There may be more than one application running on the same node. Typically, each application has a unique port number allocated to the same IP address. That is, in order to identify an application, both an IP address and a port number must be specified. The set of IP address and a port number is often called “transport address” which is typically denoted as <ip-address>:<port>.
The notion of “port” is important to understand NAT behavior. A NAT allows two or more IP nodes behind the NAT to share a single global IP address, by translating the port numbers. When an application on a node sends a packet to a server on the public network, the NAT allocates a public transport address, having an external IP address and an external port number that is associated with the source transport address. This association created by NAT is known as “NAT Binding”. When another application on a different node behind the NAT sends a packet to the same server the NAT creates another binding with the same external IP address but with another port number. For the server, those packets look like they originated from the same node but from different port numbers. The server then simply sends responses back to those external transport addresses on the NAT. Since the NAT already has bindings for packets received from the server these packets can be correctly forwarded to the associated local nodes. A problem occurs when a node behind the NAT wants to be accessed from anyone from the public network. A NAT binding cannot be created by packets from the pubic network. The NAT can forward the inbound packets only if an associated binding already exists.
To address this problem, many routers have a Port Forwarding feature which allows a user to manually configure the routing table in the router. As opposed to NAT binding, a specified external transport address on the NAT is static so that any inbound packets arrived on the external transport address are forwarded to the specified local node on the private network. Unfortunately, such manual configuration requires users to have sufficient knowledge of TCP/IP protocol and NAT. Users also need to know the transport addresses of the applications running on the local nodes to configure the port forwarding tables. Since port forwarding is not a standardized feature, each router has a different configuration menu some of which might not be able to meet requirements from an application. To application vendors, the cost for customer support for those users who are experiencing trouble with configuration for various NATs would be very significant.
Network Address Translators (NATs), while providing many benefits, also come with many drawbacks. The most troublesome of those drawbacks is the fact that they break many existing IP applications, and make it difficult to deploy new ones. Although guidelines have been developed that describe how to build “NAT friendly” protocols, many protocols simply cannot be constructed according to those guidelines. Examples of such protocols include almost all peer-to-peer protocols, such as multimedia communications, file sharing and games.
NAT is not a concern if a session is initiated from the internal network to the external network. In client-server system such as Web (HTTP) services or E-mail (SMTP/POP3) system, a client typically initiates a connection to a server, and NAT works well with this client-server model and the deployment of NAT has been very successful.
As the Internet population and its available bandwidth grow the demand for sending and receiving large amount data directly between peers over the Internet has gotten more. As opposed to the client-server model, connecting peer-to-peer solves issues with bandwidth scalability, data propagation delay and a cost for central servers. Well-known applications of this peer-to-peer model today are VoIP and file sharing systems, etc. The peer-to-peer solution is very attractive. It has, however, significant issues with connectivity between the peers through NAT.
It has been observed that NAT treatment of User Datagram Protocol (UDP) varies among implementations. Four treatments commonly observed in implementations are, Full Cone, Restricted Cone, Port Restricted Cone and Symmetric. A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address. In a restricted cone NAT all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X. A port restricted cone NAT is like a restricted cone NAT, but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P.
In a symmetric NAT all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host.
One prior art NAT traversal solution has been developed based on UPnP (Universal Plug and Play), a technical specification that enables communications among home appliances such as PC, AudioNideo devices, phones and etc., proposed by Microsoft in 1999 and supported by more than 20 companies including Intel, 3Com, AT&T, Dell Computer, etc. UPnP provides NAT traversal solution that allows a node behind a UPnP compliant NAT to discover the presence of the NAT and to add and delete external port mapping on the NAT. It is an automatic port forwarding configuration, so to speak. Many residential routers support UPnP today, however, not all of them do. Some UPnP compliant routers have UPnP mode turned off by default. Users may be prompted to turn on the UPnP mode manually, but this essentially falls into the same issue with the port forwarding.
UDP hole punching is another popular and effective NAT traversal technique that works well with most of the residential routers' NAT types. As illustrated in FIG. 1, this technique literally, it creates “a UDP hole” (or NAT binding) by sending a UDP packet 1 from a local node 2 behind a NAT 3 to the public network 4. In this example, the local node 2 has an IP address 192.168.0.2 and the UDP packet 1 is sent from local port 5060. The NAT 4 creates a binding which maps the local transport address of the local node 2 to a public transport address having a different IP address and port number. Once the NAT binding (UDP hole) is created, an allocated external port 5 can be used to receive packets 6 from anyone on the public network 4, e.g., a remote node 7, and get them forwarded to the local node 1 that created the binding initially.
Unfortunately, it is known that some NATs, e.g., Port restricted-cone or Symmetric NATs, forward the inbound packets received on the external port 5 only if the packets are sent from the same transport address (combination of IP address and port number) to which the initial hole punching packet was sent. Moreover, following issues needs to be solved to make use of UDP hole punching: (1) how can the external port number be obtained? (2) How the NAT behavior can be ascertained? (3) Will the same external port number allocated when the local node send a packet to the remote node?
To address these issues a protocol known as Simple Traversal of UDP through NAT (STUN) has been developed. STUN is a lightweight protocol proposed by Internet Engineering Task Force (IETF) that allows an IP enabled node to discover the presence and types of NAT that the node is behind. STUN works with most of NATs and does not depend on any special behavior of the NAT. The STUN server acts like a mirror held up to a node so that the node can see how its local transport address gets mapped to a public transport address.
In the example depicted in FIG. 2 STUN is of a client-server model, treating a NAT 10 as a black-box located between a client and server. A STUN client 11 at local transport address e.g., 192.168.0.2:5060 sends a binding request packet 12 to a STUN server 13 located on the public network 14 at transport address 67.2.2.2:3748. The NAT 10 allocates a public transport address of e.g., 67.1.2.3:6000 to the request packet 12. Then the STUN server 13 generates a response packet 15 that contains the source transport address (67.1.2.3:6000 in this example) of the request packet 12 in its payload so that the client 11 can tell if a NAT is present in the path by comparing the source transport address with its local transport address. The STUN client 11 also finds out the type of the NAT 10 through the communication with the STUN server 13. Additional details of the STUN protocol can be obtained from RFC 3489, by J. Rosenberg et al., “STUN—Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)”, which is incorporated herein by reference. The STUN protocol defines the four types of NAT behavior (Full Cone, Restricted Cone, Port Restricted Cone and Symmetric) as described above.
It is important to note that the STUN protocol alone does not support a complete NAT traversal mechanism. It just helps to get necessary information about a target NAT observed by STUN server and client. A typical NAT traversal scenario with STUN and UDP hole punching is performed as follows:                1. A local node A sends a binding request packet to STUN server.        2. Node A receives response packet with MAPPED-ADDRESS from the STUN server.        3. Node A sends a connection request to Node B with the MAPPED-ADDRESS via a proxy server. (e.g., a SIP proxy server).        4. Node B sends a response back to Node A with Node B's transport address to Node A via the proxy server.        5. Node A sends a UDP hole punching packet to Node B.        6. Node B starts sending packets directly to the MAPPED-ADDRESS.        7. The packets from Node B successfully get forward to Node A by the NAT.        
As described above, Node A and Node B need to exchange signals with their routable transport addresses through an intermediary (proxy) server prior to peer-to-peer connection establishment. SIP (Session Initiation Protocol) is a standardized signaling protocol, widely used for Voice over IP applications. Details of SIP are set forth in RFC 3261, which is incorporated herein by reference.
In the general NAT traversal mechanism described above, it is assumed that the MAPPED-ADDRESS obtained by using STUN can be used by Node B to reach Node A. This, however, is NOT true if the NAT is Symmetric. Since a Symmetric NAT allocates a different external port number if the destination address is different, the MAPPED-ADDRESS is not useful for Node B. Traversing a Symmetric NAT has generally been regarded as extremely difficult if not impossible.
The current practice to overcome the Symmetric NAT case is to utilize a relay server such as Traversal Using Relay NAT (TURN). TURN is a server-client protocol that allows a natted node to allocate an external transport address on a TURN server located in the public network. TURN server behaves just like a network address port translation (NAPT) box shared by many natted nodes, and relays traffic received on the allocated external port to a TURN client behind a NAT box. TURN can support any type of NAT behavior because traffic made to a TURN server is of a client-server model. However, it is clear that TURN has a significant scalability issue because all the traffic has to go through the central server.
Therefore, although several NAT traversal techniques have been developed, however, none of them have adequately solved the issue of traversal of a Symmetric NAT without a help from a relay server. Issues of NAT traversal are described in considerable detail in US Patent Application Publication 2004/0139228 entitled “Peer-to-peer (P2P) connection despite network address translators (NATs) at both ends”, which is incorporated herein by reference. Prior art solutions for traversal of the Symmetric NAT case involve highly complex operations.
One attempt Symmetric NAT traversal is based on port prediction. As shown in FIG. 3, node A is behind a Symmetric NAT. Recall that a Symmetric NAT allocates a different port each time it sends a packet. An initial packet from node A may be sent to node C through port 6001. Node B can respond to node A through port 6001. However, node A's communication with node B may be through port 6002. Subsequent packets sent from node B to port 6001 will be discarded since the NAT binding on port 6001 does not recognize node B. Port prediction takes advantage of the behavior of a Symmetric NAT in assigning ports. Typically, the Symmetric NAT increments the port number in subsequent bindings by an amount delta-P. In the above example, delta-P is equal to 1. Thus if node A can discover whether it is behind a Symmetric NAT, e.g., using STUN, and determine the value of delta-P it can send this information to node B. When node B next attempts to contact with node A, it sends a packet to a new transport address with the previous IP address and a port number equal to the previous port number incremented by delta-P.
Unfortunately, port prediction appears to be a “brittle” technique (as it is prediction based) and subject to failure in certain circumstances. Port prediction as described above also requires node A to send node B information regarding the type of the NAT and the value of delta-P. Port prediction techniques are known to those skilled in the art, e.g., as described in greater detail by Yutaka Takeda in “Symmetric NAT Traversal using STUN, <draft-takeda-symmetric-nat-traversal-00.txt>” a copy of which can be accessed on the Internet at http://www.ietf.org/proceedings/03nov/I-D/draft-takeda-symmetric-nat-traversal-00.txt, and which is incorporated herein by reference.
Another attempted solution to the problem of Symmetric NAT traversal is known as ICE (Interactive Connectivity Establishment). ICE is a very efficient and promising technology but it is also a relatively new methodology. ICE causes a node known as an initiation to send a transport address to another node referred to as a responder and asks the responder to send communication to an IPv6 address. ICE makes the fundamental assumption that clients (node s) exist in a network of segmented connectivity. This segmentation is the result of a number of addressing realms in which a client can simultaneously be connected. The term “realms” is used here in the broadest sense. A realm is defined purely by connectivity. Two clients are in the same realm if, when they exchange the addresses each has in that realm, they are able to send packets to each other. This includes IPv6 and IPv4 realms, which actually use different address spaces, in addition to private networks connected to the public Internet through NAT. The key assumption in ICE is that a client cannot know, a priori, which address realms it shares with any peer it may wish to communicate with. Therefore, in order to communicate, the client has to try connecting to addresses in all of the realms.
The basic flow of operation for ICE is shown in FIG. 4. Before an initiator I establishes a session, it obtains at step 21 as many IP address and port combinations in as many address realms as it can from one or more NAT discover servers N (e.g., STUN or TURN servers). These addresses all represent potential points at which the initiator I can receive a specific media stream. Any protocol that provides a client with an IP address and port on which it can receive traffic can be used. These include STUN, TURN, RSIP, and even a VPN. The client may also use any local interface addresses. For example, a dual-stack v4/v6 client will obtain both a v6 and a v4 address/port. Unfortunately, if the initiator communicates with a peer that doesn't support ICE, only one address can be provided to that peer. As such, the initiator I will need to choose one default address, which will be used by non-ICE clients. This may be a TURN derived transport address, as it is most likely to work with unknown non-ICE peers.
In the example depicted in FIG. 4, the initiator I then runs a STUN server on each the local transport addresses it has obtained. These include ones that will be advertised directly through ICE, and so-called associated local transport addresses, which are not directly advertised; rather, the transport address derived from them is advertised. The initiator I will need to be able to demultiplex STUN messages and media messages received on that IP address and port, and process them appropriately. All of these addresses are placed into the initiate message, and they are ordered in terms of preference. Preference is a matter of local policy, but typically, the highest priority is given to IPv6 addresses, the next highest priorities are given to local addresses, and STUN-derived address and transport addresses learned from a TURN server (i.e., TURN derived transport addresses) and the lowest priority to relay server addresses.
At step 22, the initiator I sends an initiate message to the responder R. Standard signaling protocol specific mechanisms may be used to enable the signaling messages to traverse any intervening NATs between the initiator I and the responder R. At step 23, the responder R follows a similar process as the initiator followed; it obtains addresses from the NAT discovery servers N it places all of them into an accept message at step 24. Once the responder R receives the initiate message, it has a set of potential addresses it can use to communicate with the initiator I. The initiator I may be running a STUN server at each address. At step 25, the responder R performs connectivity checks, e.g., by sending a STUN request to each address, in parallel. When the initiator I receives these, it sends a STUN response as indicated at step 26. If the responder R receives the STUN response, it knows that it can reach its peer at that address. It can then begin to send media to that address at step 27. As additional STUN responses arrive, the responder R will learn about additional transport addresses which work. If one of those has a higher priority than the one currently in use, it starts sending media to that one instead. No additional control messages (i.e., SIP signaling) occur for this change.
The STUN messages described above happen while the accept message is being sent to the intitiator I. Once the intitiator I receives the accept message, it too will have a set of potential addresses with which it can communicate to the responder. The initiator I follows exactly the same STUN check process described above at step 27 and can begin sending media at step 28 to the responder R once it receives a STUN response. Furthermore, when a either the initiator I or responder R receives a STUN request, it takes note of the source IP address and port of that request and compares that transport address to the existing set of potential addresses. If the transport address is not amongst the set of potential addresses, it gets added as another potential address. The incoming STUN message provides the client with enough context to associate that transport address with priority, just as if it had been sent in an initiate or accept message. As such, the client (initiator or responder) begins sending STUN messages to it as well, and if those succeed, the address can be used if it has a higher priority.
Those of skill in the art will be familiar with the ICE protocol and various ways of implementing it. For example, ICE is described in detail by J. Rosenberg in “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols” a copy of which can be downloaded from the internet at http://tools.ietforg/wg/mmusic/draft-ietf-mmusic-ice/draft-ietf-mmusic-ice-03.txt, and which is incorporated herein by reference.
Although ICE is a recognized and implemented methodology, there is currently no way for ICE to send information about NAT type to facilitate the prior art port prediction (e.g., as set forth in US 2004/0139228). One would have to add another field for the methodology to handle this information and implement port prediction. This would add extra processes to both ends, and also exposing NAT types to other nodes could become a security concern. Moreover, adding a new field may break compatibility with existing systems that support standard ICE.
Thus, there is a need in the art, for an improved method for peer-to-peer communication traversing symmetric network address translators and a system for implementing such a method.