The private range of IP addresses defined in RFC 1918 and allocated by the IANA discussed in the previous section is used for internal use, and ISPs will simply not forward traffic with those addresses. The first question that comes to mind is, what happens when one of the privately addressed private networks wishes to connect to the Internet?
As the Internet grew, many organizations simply connected their networks to the Internet using routable IP addresses assigned to them by the IANA or ISP. Unfortunately, this process was consuming IP addresses at an astounding rate. Therefore, a process was defined that allowed internal private IP addresses to be translated into valid Internet IP addresses. To reduce the numbers of used Internet routable IP addresses, several internal systems could communicate using only one external IP address.
Note: The translation process can work for any IP address and not just for the ranges defined in the RFC. The internal private addresses are consis-tently referred to, allowing simplicity and uniformity in the explanation.
Network Address Translation (NAT) is a method that allows the mapping of one network of IP addresses to another, differently addressed network. This is not routing — it is a translation process to get one network to communicate with another. NAT has been typically associated with providing access to the Internet for networks assigned with the private addressing scheme.
There are two aspects of IP communications that NAT attempts to answer. The first is allowing IP address to have valid communications to remote networks that may have the same IP address domain or would not normally allow communications from the assigned IP domain. Second, NAT provides anonymity by hiding the originating IP address from the external peer. The peer simply receives a datagram from the device performing the NAT for the hidden network.
Within NAT there are two basic states, each having a different name, depending on who one is talking to at the time; here, the two states are Hide and Static. Hide represents the state of the NAT device where any number of internal hosts assigned with private IP addresses can be allowed access to the Internet via a single valid address assigned to the NAT’ing device.
As shown in Exhibit 2-12, each internal system has its own private IP address.
However, as the communication is forwarded to the Internet, the traffic assumes the IP address of the router’s external IP address. Any remote system will see traffic originating from the router and not the internal systems. The router maintains a table of associations and state information to properly forward incoming packets to the appropriate internal system. The layers of operation within TCP/IP allow several
instances communications. For example, if three internal users are accessing the same Web page at the same time, the remote Web server will establish three separate sessions with the same IP address — that of the router. The robustness of TCP/IP and the relationships between the layers of operations allow seemingly complicated trans-action to happen nearly effortlessly.
The other state of NAT is Static. Static is a direct coloration of a single internal IP address to a single external IP address. This is simply a Hide NAT for a single box and nearly eliminates the need for a state table.
As shown in Exhibit 2-13, the communication is coming from the external system wishing to access services on System #1 on the internal network. In the example, the remote system is attempting to communicate with a virtual address. A virtual address is an IP address that is not necessarily associated with an interface or MAC address.
However, the router has been configured to accept any packets for that IP address.
Exhibit 2-12. Hide network address translation.
Exhibit 2-13. Static network address translation.
In some configurations, especially with firewalls on a broadcast medium, the NAT’ing device (i.e., firewall) can be configured to answer ARP requests from external communica-tion systems. In such a scenario, a router may be providing access to the Internet with a firewall behind the router, as shown in Exhibit 2-14. In any case, the IP address must be properly routed to the NAT’ing device, where a routing table resides that determines how to forward the packet. In the example, the router is forwarded to the virtual IP address because the ISP has assigned that range to the router. Once the packet is received, the router must determine who the IP address is assigned to forward it. If the router does not already have the MAC address of the owner, it will broadcast for it with an ARP request.
Unfortunately, the system that needs the traffic is not only inside the internal network but does not have that IP address. To accommodate this process, the firewall is configured to answer any ARP requests for that IP address; this method is called an ARP proxy. The router obtains the firewall’s MAC address and forwards the IP packet to the firewall. Because the firewall is the final destination for the data link layer, the protocol is removed from the frame and processed by the protocol stack. At that point, the firewall provides NAT service and forwards the datagram accordingly to System #1.
Note: It is possible to have Static and Hide NAT at the same time on the same device performing the NAT operations.
Network Address Translation is responsible for several operations and each depends on the protocols and communication being established.
1. changing the source IP address and destination IP address, depending on the communication direction and requirements
2. updating the checksum of the checksum of the protocol headers 3. updating IP addresses internal to the datagram payload
4. maintaining a communication state table to allow the multiplexing of internal communications to an external singularity
Exhibit 2-14. Static network address translation with proxy ARP.
To accommodate these changes, the NAT device must change several aspects about the packet. Specifically, the checksums must be recalculated. In a simple scenario, only the IP header addresses and checksum must be changed. However, the TCP or UDP header checksum must also be updated, to allow for the pseudo header that was calculated during the creation of the datagram. This is true because some NAT provi-sioning systems modify the source service port to assist in keeping track of the NAT’ed communications. Therefore, because NAT operations modify all the way to the transport layer, the TCP or UDP checksums must be calculated.