Private networks are commonly connected to the Internet through one or more routers so that hosts (PCs or other arbitrary network entities) on the private network can communicate with nodes on the Internet. Typically, the host will send packets to locations both within its private network and on the Internet. To receive packets from the Internet, a private network or a host on that network must have a globally unique 32-bit IP address. Each such IP address has a four octet format. Typically, humans communicate IP addresses in a dotted decimal format, with each octet written as a decimal integer separated from other octets by decimal points.
Global IP addresses are issued to enterprises by a central authority known as the Internet Assigned Number Authority (“IANA”). The IANA issues such addresses in one of three commonly used classes. Class A IP addresses employ their first octet as a “netid” and their remaining three octets as a “hostid.” The netid identifies the enterprise network and the hostid identifies a particular host on that network. As three octets are available for specifying a host, an enterprise having class A addresses has 224 (nearly 17 million) addresses at its disposal for use with possible hosts. Thus, even the largest companies vastly under use available class A addresses. Not surprisingly, Class A addresses are issued to only very large entities such as IBM and ATT. Class B addresses employ their first two octets to identify a network (“netid”) and their second two octets to identify a host (“hostid”). Thus, an enterprise having class B addresses can use those addresses on approximately 64,000 hosts. Finally, class C addresses employ their first three octets as a netid and their last octet as a hostid. Only 254 host addresses are available to enterprises having a single class C netid.
Unfortunately, there has been such a proliferation of hosts on the Internet, coupled with so many class A and B licenses issued to large entities (who have locked up much address space), that it is now nearly impossible to obtain a class B address. Many organizations now requiring Internet access have far more than 254 hosts—for which unique IP addresses are available with a single class C network address. It is more common for a mid to large size enterprise to have 1000 to 10,000 hosts. Such companies simply can not obtain enough IP addresses for each of their hosts.
To address this problem, Network Address Translation (“NAT”) has been proposed. See K. Egevang and P. Francis, “The IP Network Address Translator (NAT),” Request For Comments “RFC” 1631, Cray Communications, NTT, May 1994 which is available at http://andrew2.andrew.cmuedu/rfc/rfc1631.html and is incorporated herein by reference for all purposes. NAT is based on the concept of address reuse by private networks, and operates by mapping the reusable IP addresses of the leaf domain to the globally unique ones required for communication with hosts on the Internet. In implementation, a local host wishing to access the Internet receives a temporary IP address from a pool of such addresses available to the enterprise (e.g., class C 254 addresses). While the host is sending and receiving packets on the Internet, it has a global IP address which is unavailable to any other host. After the host disconnects from the Internet, the enterprise takes back its global IP address and makes it available to other hosts wishing to access outside networks.
To implement NAT, a translation system must be provided between the enterprise private network and the Internet. Unfortunately, as the translation system is positioned between the enterprise and the Internet, communication performance can be degraded if NAT is not performed efficiently. FIG. 1 illustrates a typical prior art Internet/Enterprise computer network configuration 10, where a server load balancer is used to distribute requests to different servers in the intranet 18. In this case, client NAT is necessary to force all responses to be returned to the server load balancer. In this example, client 12 issues a request from the Enterprise organization. The client's request designates a source IP address “C” (S=C) and a virtual server IP address “V” (D=V). The client's request is transmitted to the Internet 14 and arrives at the Enterprise's server load balancer 16. The server load balancer 16 translates both the source and destination IP address to “N1” and “R1,” respectively. “R1” is the IP address of one of the real servers 20, 22, or 24 chosen by the server load balancer. “N1” is a generated IP address that is advertised within the intranet 18 so that routing tables (of network devices within the intranet 18) are updated to cause all responses sent to “N1” to be routed to the server load balancer. This is necessary because the server load balancer must maintain connection state information and perform a reverse translation. The translation of the C to “N1” is called client NAT. The server load balancer 16 then routes the request to “R1” (say 20). Server 20 generates a response to the request causing it to be routed to the server load balancer 16. Before the response can be routed to the client, the server load balancer must reverse the translation. “N1” is translated to “C” and “R1” is translated to “V.” The source address of the response message is set to “V” (S=V) and the destination address is set to “C” (D=C). If client NAT were not employed, the response could be routed to router 26, resulting in network errors.
A major source of overhead of the NAT translation process is the allocation and management of client NAT addresses and their associated address pools each time a new address is required for each new connection that is initiated by the client device. Prior art solutions to this problem have either required substantial hardware resources or have otherwise created a bottleneck between the enterprise private network and the Internet. There is, therefore, a need in the art for providing a NAT that consumes fewer resources and yet provides faster performance.
USPTO Backgrounds
USPTO Backgrounds