In network communication, there is a general demand for providing connectivity between different networks, especially when the networks have different address realms. For example, this would normally be the case when a node in a private network wants to connect to a host in a public network. The private network usually have internal addresses that cannot be used outside the network, for privacy reasons or simply because the internal addresses are invalid for use outside the network. Other examples include connectivity between networks of different public domains, as well as between different private networks.
With the explosive growth of Internet Protocol (IP) networks such as the Internet, intranets and other networks, the limited IP address space offered by the current version of the IP protocol, IPv4, becomes a real challenge. With a 32-bit address field, it is possible to assign 232 different addresses, which are about 4 billion globally unique addresses. The next version of the IP protocol, IPv6, will have a 128-bit address field, thus providing a virtually unlimited number of globally unique IP addresses. The challenge is that there is a limited number of IPv4 addresses available to the operators for their new networks, and IPv6 is not yet supported by more than a very limited set of nodes within the Internet. Also, a large number of legacy networks including Internet subnets will likely be using the IPv4 or older versions of the IP protocol for many years to come.
For mobile or cellular networks, telecom vendors and operators are facing a great challenge deploying support for an expected vast number of IP-enabled mobile terminals in 2.5 and 3G networks. The IPv4 address space is apparently not large enough to cover the needs when a massive deployment of 2.5 and 3G networks takes place within the near future. Today, network operators that apply for address ranges for their new cellular networks receive address spaces far below the expected number of users. The ratio can be as low as a few thousand addresses for an expected customer base of millions of subscribers.
To meet the demand for addresses, telecom vendors are pushing the introduction of IPv6 into terminals as the standard protocol to use within next generation cellular networks. IPv6, fully deployed would naturally solve the address space problem, but unfortunately, IPv6 is not widely deployed in the Internet yet, and it is expected that this deployment will be quite slow, at least in the near future. Since IPv6 is not deployed in the Internet, vendors will have to use migration schemes for providing connectivity between different networks.
There are a number of existing schemes for both extending an address realm and for translating between different address realms. These schemes will be briefly outlined below, mainly with respect to the issue of providing connectivity between private and public networks operating under the IP protocol.
With reference to FIG. 1, a private realm is a domain where hosts are assigned addresses that are not unique within the Internet, or they are unique but for some reason they are hidden from the public realm. A common example is to assign hosts in a private network 10 with private addresses [a.a.a.a] to [a.d.d.d], for example as specified in RFC1918, to enable multiple hosts to share a single or some public IP addresses when the number of private realm hosts exceeds the number of public addresses assigned for the private network 10. Since there is no assigned body coordinating the use of private addresses, these addresses occur at multiple locations around the world and therefore they are generally not unique and can thus not be used within the public realm. In order for private hosts to be able to access the public realm network 20, a gateway 30 can be used for enabling multiple private hosts to share a single or some public IP addresses [x.x.x.x] to [x.x.x.z] for the purpose of public realm access. The gateway 30 thus provides the necessary means for connecting hosts within the private realm to the public realm, especially when the number of private hosts is larger than the number of available public IP addresses.
Network Address Translator (NAT)
Existing schemes for extending address realms such as the IPv4 address space are often based on so-called Network Address Translator (NAT) gateways, which translate private addresses into public addresses and vice versa [1]. The different flavors of NAT have in common that they all hide private addresses and reuse public addresses to enable communication between hosts in a private realm and hosts in the public realm.
Traditional NAT
A traditional NAT gateway typically uses a set of public IP addresses to assign to individual private nodes on a per-session basis. When a host within the private realm wants to contact a host within a public network such as the Internet, the NAT assigns one of its public addresses [x.x.x.x] to [x.x.x.z] to the private host. The NAT then rewrites the sender address in the IP header of the outgoing packet with the public address so the corresponding host in the public Internet gets the impression that the packet came from the publicly assigned IP address. When the public host sends a packet back to the publicly assigned address, the NAT rewrites the destination address in the IP header with the private address so the packet is correctly routed in the private realm.
This method of translating between the two realms is simple but suffers from two drawbacks other methods have tried to solve. Firstly, it does not allow a host in the public Internet to connect to a host within the private realm and secondly, it does not scale very well since every time a private host wants to connect to a public realm host, an entire public IP address is reserved for the host.
Network Address Port Translation (NAPT)
NAPT alleviates the scalability problem by enabling multiple private realm hosts to share a single IP address. This is accomplished by including transport protocol port information into the translation procedure. When a host in the private realm wants to connect to a host in the public realm, the gateway assigns a free port on the public realm interface to the connection and uses the original and assigned ports together with the IP addresses for the translation. This way the NAPT gateway can share a single IP address among several private hosts.
For example, consider a host [a.a.a.a] that wants to connect to host [d.d.d.d] on the public Internet. When the first packet to host [d.d.d.d] reaches the NAT it assigns a free port on an interface, say public IP address [x.x.x.x], to the connection and rewrites the sender address from [a.a.a.a] into [x.x.x.x] and the sender port number to the assigned port number. When the receiver replies the destination address is [x.x.x.x] and the port is the assigned port number. When this packet reaches the NAPT gateway, it rewrites the destination address with [a.a.a.a] and the destination port number with the original port number.
Thus, NAPT scales better than traditional NAT, but it is still impossible for hosts within the public realm to initiate sessions to hosts within the private realm.
Bi-directional NAT
Bi-directional NAT enables hosts on the public Internet to reach hosts within a private realm. This is accomplished through the introduction of a special Application Layer Gateway (ALG), to a Domain Name Server (DNS) in conjunction with the bi-directional NAT. The ALG is capable of resolving Fully Qualified Domain Names (FQDN) of private realm hosts to assigned public realm addresses. The ALG is capable of translating the private realm address corresponding to a FQDN into a public realm address and vice versa. The bi-directional NAT allows hosts within the public Internet to communicate with hosts within a private realm, but there is a one-to-one mapping between hosts and public IP addresses which scales poorly when public IP addresses are scarce.
Realm Specific IP (RSIP)
RSIP takes a different approach than NAT to provide connectivity between different realms [2, 3]. RSIP uses a special node that is aware of the different realms and can distinguish between the two.
In general terms, RSIP uses two entities, a RSIP server and a RSIP client. The RSIP server is present in both realms and can provide router functionality between the realms. It can also be the node assigning public addresses to private hosts. The RSIP client is a node within the private realm that can temporarily use a public address when communicating with public hosts. Hence, RSIP makes use of public addresses for both parties when communicating between the private and public realms, and does not perform any address translation.
An advantage of this scheme is that there is no need to deploy ALGs for applications since public realm addresses are used even for private clients. However, plain RSIP does not allow public realm initiated connections.
There are two flavors of RSIP, namely Realm Specific Address IP (RSA-IP) and Realm Specific Address and Port IP (RSAP-IP).
Realm Specific Address IP (RSA-IP)
An RSA-IP client is assigned a public IP address when communicating with the public realm. This procedure is a one-to-one mapping and hence, no other host can use the address until it is released by the client (so-called address granularity). The packets are typically tunneled through the private realm to the RSA-IP server or they can be tunneled end-to-end.
Realm Specific Address and Port IP (RSAP-IP)
RSAP-IP operates similar to RSA-IP with the difference that RSAP-IP clients are assigned public IP addresses as well as associated ports (so-called port granularity). This way, several RSAP-IP clients can share public IP addresses. The multiplexing is performed through adding both an IP tunnel and an additional transport header with the assigned port as identifier if the public host terminates the tunnel. If the RSAP-IP server terminates the tunnel, the multiplexing is based on both destination address and port.
NAT-PT
Another flavor of NAT, called NAT-PT, adds specific protocol translation between IPv4 and IPv6. NAT-PT comes in three flavors corresponding to standard NAT, NAPT and bi-directional NAT. Bi-directional NAT-PT has support for public realm initiated communication, but with a one-to-one mapping of public IP address to private realm host. However, this scheme also does not scale very well due to the limited number of available public IPv4 addresses.
In general, public-realm initiated communication is enabled by manually and statically configuring the gateway such that an inside-bound packet with a given destination address and port will be forwarded to a certain node in the private realm. This scheme is generally referred to as static port mapping.
Bridging between a private realm and a public realm could also be effectuated on the session level, e.g. as described in [4].
Apparently, there are limitations regarding the number of simultaneous flows that can be supported by the gateway, as well as limitations regarding the mechanisms for establishing a connection initiated from nodes in the public realm.
USPTO Backgrounds
USPTO Backgrounds