NAT

Network Address Translation (NAT) was developed specifically to counter the lone weakness inherent in the private addresses of RFC 1918. That's not to suggest that it makes those nonunique addresses globally routable, because it doesn't. Rather, it lets you translate those nonunique addresses to unique and routable addresses at the edge of your network. This permits access to and from the global Internet. In other words, you operate with two sets of addresses: You would have your private RFC 1918 addresses configured on endpoints throughout your network, and then a globally routable block of addresses would be configured on your NAT device. NAT would be responsible for correlating the internal and global addresses and translating as needed to support communications.

Originally described in RFC 1631 in May 1994, NAT was originally conceived as yet another of the stopgap measures to shore up the flagging IPv4 address space. If you take the time to read this document (www.ietf.org/rfc/rfc1631.txt), you will see that the IETF was absolutely counting on IPv6 to save the Internet from its impending address crisis. This document explicitly identifies the two biggest problems facing the Internet as a shortage of IP addresses and the scalability of routing across the Internet. In Chapter 5, "The Date of Doom," we looked at how these two are really different perspectives on the same problem, so their appearance in RFC 1631 shouldn't be a startling revelation.

What is startling is the explicit admission that at least some parties within the IETF were concerned that CIDR (then under development) might not buy enough time for IPv6 to be completed. That's a staggering statement! CIDR was initially conceived as just another stopgap tool to buy time for the new IP protocol and addressing system to be developed. This fear became the motivator for the development of NAT.

Framing the Problem Statement

The authors of RFC 1631 apparently believed strongly enough in their proposal to say the following:

It is possible that CIDR will not be adequate to maintain the IP Internet until the long-term solutions are in place. This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary.

With the benefit of hindsight, that remarkable statement is both amusing and illuminating. As late as the middle of 1994, there was still great debate as to whether a migration to a classless IP address system was even needed. This is significant because CIDR was stipulated in a series of RFCs published in September 1993, 8 months prior to the release of RFC 1631 NAT! If nothing else, this should give you some indication that there was little consensus on anything other than three basic facts:

• The IPv4 address space, in its class-based configuration, was about to break.

• The correct way to solve the problem was to make a completely new Internet Protocol (eventually named IPv6).

• Something needed to be done immediately to forestall the impending collapse of the classful system long enough to roll out the new version of IP.

Beyond these three basic facts, consensus broke down. Nobody really knew the correct approach to take, so the IETF attacked in all directions. The development of NAT capability was aimed at enhancing the usefulness of the RFC 1918 addresses. One of the single biggest "traps" inherent in the use of nonunique addresses was the inability to convert them to routable addresses. Should requirements change, and Internet connectivity become necessary, anyone using RFC 1918 addresses would face a painful address migration. In comparison, address translation seemed like a welcome alternative.

As significant as NAT has become, it is almost laughable to think that at its inception it was being bandied about as an alternative to CIDR. With hindsight, it is remarkably obvious that CIDR and NAT are different tools intended for different uses. Both technologies were also so successful at buying time for IPv4 that they are still in active use.

Technical Overview

Before we get too caught up in technical details, one salient point to understand is that NAT is a router-based function. It was designed to provide hosts on a private network with a means of communicating transparently with destinations outside that network, and vice versa. Traditionally, NAT has been used in conjunction with RFC 1918 addresses (specifically designed for use in addressing private numbers), but that is not a mandate. NAT can be used to translate unique addresses into other unique addresses, too. Either way, it enhances security by hiding addresses within a private network from the outside world. Thus, NAT can be highly appropriate for securing a network, regardless of what kind of IP addresses are in use.

The way this works is actually quite simple. A gateway router (one that sits at the border of two different networks) functions as an address translator between two neighboring networks. This translation means that a NAT network has different types of IP addresses, each serving a slightly different purpose. Before we venture too far ahead, you need to understand the subtle distinctions between these address types. If you assume that an enterprise is using NAT to establish communications with the Internet, this helps you establish a frame of reference for understanding the differences between the address types. The original specification for NAT had two address types:

• Inside local (IL) address This is the address of a host inside an enterprise's network as it is known within that network. The IL may be globally unique (either obtained from the ISP or directly registered to the enterprise), or it may be selected from an RFC 1918 reserved range. Communications within a network may occur directly using IL addresses, without the need for translation.

• Inside global (IG) address This is the IP address of a host inside an enterprise's network as it appears to the Internet. That last phrase is the critical distinction between an IG and an IL address. IG addresses must be globally unique, regardless of whether they were obtained from the ISP or directly registered to the enterprise. It is important to recognize that the IG address is advertised to external networks and is used for routing to the internal network. Thus, RFC 1918 private addresses cannot be used as IG addresses.

Together, these address types let a network communicate with other IP-based networks without having to reveal its internal addresses. That's a key statement, because so many people think that the only reason NAT exists is for use with RFC 1918 addresses. The truth is, it can be used with any network address and may be implemented to enhance a network's security regardless of whether it uses private or globally routable addresses.

The NAT router must keep a tableknown as an address translation table (no acronyms, please)that correlates these different address types. How this correlation works depends on whether we are talking about packets coming into, or going out of, that private network. We'll look at both traffic types in the next section.

Over time, NAT has become much more sophisticated and feature-rich. Today's NAT can translate external as well as internal addresses and can even translate TCP port addresses. Later in this chapter we'll look at some of the technological advances that NAT has benefited from. For now, let's continue with our examination of the basic NAT specification. This will give you a context within which you can better appreciate the enhancements made to NAT since RFC 1631.

Operational Mechanics

NAT is a router-based function that must reside at a network's border. For the purposes of explaining how a NAT works, let's start with a very basic implementation topology. Take a look at Figure 7-1. This figure shows a simple stub network that consists of just one local-area network. This LAN uses private addresses in the 172.16.9.0/24 block. NAT is performed at the gateway router between that network and the Internet. This connection is the only egress point for this network.

Figure 7-1. NAT Translates Nonunique and Unique Addresses at the Border of a Stub Network

For now, let's make the simplifying assumption that the end user entered an IP address as opposed to a host and domain name string. This lets you focus on the mechanics of NAT without the added complexity of translating a name into an IP number. We'll look at how that is done in Chapter 9, "IP Multicasting." Given this simplifying assumption, when an endpoint on that LAN tries to access a host that resides outside its boundaries, the request can't be resolved locally, and the gateway router accepts it. That router has only two interfaces configured: the LAN and a serial connection to the Internet. Because it is seldom useful to send a datagram or packet back through the interface it came in on, the router has only two choicesdrop the packet or send it out the other interface. Using the other interface requires that some work be done to the datagram, because that is the interface where NAT resides.

The first thing NAT does is check the header of that packet to determine its source IP address. The packet is coming from an endpoint located somewhere within the network, so the source IP address is an inside local address. NAT won't permit such addresses to pass into an external network. NAT searches its address translation table for this address. If no entry is found that corresponds to that destination address, the packet is simply discarded. If a match is found within the address translation table, the corresponding inside global address is retrieved from the table and is used in lieu of the inside local address in the packet's source address field.

Table 7-4 summarizes this gateway router's address translation table. For the sake of example, let's pretend that the globally routable address is in the 254.16.35.0 range. That address is not a valid address. In fact, it's a part of the reserved Class E address space. But I am extremely reluctant to use "real" IP addresses in an example.

Table 7-4. Stub Network's Address Translation Table

Inside Local Addresses	Inside Global Addresses
172.16.9.0/24	254.16.35.0/24
172.16.9.1	254.16.35.1
172.16.9.3	254.16.35.3
172.16.9.4	254.16.35.4
172.16.9.5	254.16.35.5
172.16.9.6	254.16.35.6

After a packet's source address field is updated with the appropriate inside global address, the packet can be launched out the router's interface and into the foreign network that lies beyond. Although that's a brief-enough synopsis of how NAT treats outbound packets, it is also necessary to see how NAT supports address translation for incoming packets.

Very generally speaking, there are two basic reasons for packets to be inbound to a NAT network:

• Responses to a session generated from within the NAT network

• Sessions that originate from external hosts

Regardless of the variety, packets that are inbound to a NAT network pass through the same process. Such packets are sent to machines bearing inside local address types. As such, they must be intercepted by the NAT for translation of the destination address to an inside global address.

The process by which NAT translates IG addresses to IL addresses is exactly the reverse of the one we just looked at. An incoming packet is accepted by the NAT (which could be a process configured on a router interface, firewall, or other specialized network appliance), and its destination address is examined and hashed against the address translation table for a matching record. If the destination address (really an IG address) is known, the corresponding IL address is then substituted in the packet's destination address, and the packet is launched into the private network. If the destination IG address isn't known, the packet is discarded.