Contents

Chapter Description

Network address translation (NAT) is a function by which IP addresses within a packet are replaced with different IP addresses. This function is most commonly performed by either routers or firewalls. This sample chapter from Cisco Press focuses on NAT within routers.

From the Book

Operation of NATThis section discusses the basics of network
address translation, including fundamental concepts and terminology, and typical
NAT applications.

NAT IssuesThis section examines some potential problems that
you might encounter with NAT. Solutions to many of the problems, either through
Cisco IOS Software functionality or through design techniques, are
identified.

The acronym NAT is used interchangeably to mean network address
translation and network address translator (software that runs the
NAT function).

Operation of NAT

NAT is described in RFC 1631.1 The original intention of NAT was,
like classless interdomain routing (CIDR), to slow the depletion of available IP
address space by allowing many private IP addresses to be represented by some
smaller number of public IP addresses. Since that time, users have found NAT to
be a useful tool for network migrations and mergers, server load sharing, and
creating "virtual servers." This section examines all these
applications, but first describes the basics of NAT functionality and
terminology.

Basic NAT Concepts

Figure 4-1 depicts a simple NAT function. Device A has an IP address that
belongs to the private range specified by RFC 1918, whereas device B has a
public IP address. When device A sends a packet to device B, the packet passes
through a router that is running NAT. The NAT replaces device A's private
address (192.168.2.23) in the source address field with a public address
(203.10.5.23) that can be routed across the Internet, and forwards the packet.
When device B sends a reply to device A, the destination address of the packet
is 203.10.5.23. This packet again passes through the NAT router, and the
destination address is replaced with device A's private address.

Figure 4-1 The NAT Router Replaces the Private Address of Device A
(192.168.2.23) with a Publicly Routable Address (203.10.5.23)

NAT is transparent to the end systems involved in the translation. In Figure 4-1, device A knows only that its IP address is 192.168.2.23; it is unaware of
the 203.10.5.23 address. Device B, on the other hand, thinks the address of
device A is 203.10.5.23; it knows nothing about the 192.168.2.23 address. That
address is "hidden" from device B.

NAT can hide addresses in both directions. In Figure 4-2, NAT is performed on
the addresses of both device A and device B. Device A thinks device B's
address is 172.16.80.91, when in fact device B's real address is
192.31.7.130. You can see that the NAT router is translating both the source and
destination addresses in both directions to support this address scheme.

Cisco NAT devices divide their world into the inside and the
outside. Typically the inside is a private enterprise or ISP, and the
outside is the public Internet or an Internet-facing service provider.
Additionally, a Cisco NAT device classifies addresses as either local or
global. A local address is an address that is seen by devices on the
inside, and a global address is an address that is seen by devices on the
outside. Given these four terms, an address may be one of four types:

Inside local (IL)Addresses assigned to inside devices. These
addresses are not advertised to the outside.

Inside global (IG)Addresses by which inside devices are
known to the outside.

Outside global (OG)Addresses assigned to outside devices.
These addresses are not advertised to the inside.

Outside local (OL)Addresses by which outside devices are
known to the inside.

Figure 4-2 The NAT Router Is Translating Both the Source and Destination
Addresses in Both Directions

In Figure 4-2, device A is on the inside and device B is on the outside.
192.168.2.23 is an inside local address, and 203.10.5.23 is an inside global
address. 172.16.80.91 is an outside local address, and 192.31.7.130 is an
outside global address.

IG addresses are mapped to IL addresses, and OL addresses are mapped to OG
addresses. The NAT device tracks these mappings in an address translation
table. Example 4-1 shows the address translation table for the NAT router in
Figure 4-2. This table contains three entries. Reading the entries from the
bottom up, the first entry maps OL address 172.16.80.91 to the OG address
192.31.7.130. The next entry maps the IG address 203.10.5.23 to the IL address
192.168.2.23. These two entries are static, created when the router was
configured to translate the specified addresses. The last (top) entry maps the
inside addresses to the outside addresses. This entry is dynamic and was created
when device A first sent a packet to device B.

Example 4-1 The Address Translation Table of the NAT Router in Figure
4-2

As the preceding paragraph demonstrates, a NAT entry may be static or
dynamic. Static entries are one-to-one mappings of local addresses and
global addresses. That is, a unique local address is mapped to a unique global
address. Dynamic entries may be many-to-one or one-to-many. A many-to-one
mapping means that many addresses can be mapped to a single address. In a
one-to-many mapping, a single address can be mapped to one of several available
addresses.

The following sections describe several common applications of NAT and
demonstrate more clearly how static NAT and the various implementations of
dynamic NAT operate.

NAT and IP Address Conservation

The original mission of NAT was to slow the depletion of IP addresses, and
this is the focus of RFC 1631. The core assumption of the concept is that only
some of an enterprise's hosts will be connected to the Internet at any one
time. Some devices (print servers and DHCP servers, for example) never require
connectivity outside of the enterprise at all. As a result, the enterprise can
be addressed out of the private RFC 1918 address space, and a significantly
smaller number of uniquely assigned public addresses are placed in a pool on a
NAT at the edge of the enterprise, as demonstrated in Figure 4-3. The non-unique
private addresses are IL addresses, and the public addresses are IG addresses.

Figure 4-3 In This NAT Design, a Pool of Public IP Addresses Serves a
Private Address Space 8 Times as Large

When an inside device sends a packet to the Internet, the NAT dynamically
selects a public address from the inside global address pool and maps it to the
device's inside local address. This mapping is entered into the NAT table.
For instance, Example 4-2 shows that three inside devices from the enterprise in
Figure 4-310.1.1.1.20, 10.1.197.64, and 10.1.63.148 have sent
packets through the NAT. Three addresses from the IG pool205.110.96.2,
205.110.96.3, and 205.110.96.1, respectivelyhave been mapped to the IL
addresses.

Example 4-2 Three Addresses from the Inside Local Address Space in Figure
4-3 Have Been Dynamically Mapped to Three Addresses from the Inside Global
Address Pool

The destination address of any packet from an outside device responding to
the inside device is the IG address. Therefore, the original mapping must be
held in the NAT table for some length of time to ensure that all packets of a
particular connection are translated consistently. Holding an entry in the NAT
table for some period also reduces subsequent lookups when the same device
regularly sends packets to the same or multiple outside destinations.

When an entry is first placed into the NAT table, a timer is started; the
period of the timer is the translation timeout. Each time the entry is
used to translate the source or destination address of a subsequent packet, the
timer is reset. If the timer expires, the entry is removed from the NAT table
and the dynamically assigned address is returned to the pool. Cisco's
default translation timeout is 86,400 seconds (24 hours); you can change this
with the command ip nat translation timeout.

NOTE

The default translation timeout varies according to protocol. Table 4-3,
later in this chapter, displays these values.

This particular NAT application is a many-to-one application, because for
each IG address in the pool, many IL addresses could be mapped to it. In the
case of Figure 4-3, an 8-to-1 relationship exists. This is a familiar
concepttelcos use it when they design switches and trunks that can handle
only a portion of their total subscribers, and airlines use it when they
overbook flights. Think of it as statistically multiplexing IL addresses to IG
addresses. The risk, as with telcos and airlines, is in underestimating peak
usage periods and running out of capacity.

No restrictions apply to the ratio of the size of the local address space
and the size of the address pool. In Figure 4-3, the IL range and/or the IG
range can be made larger or smaller to fit specific requirements. For example,
the IL range 10.0.0.0/8, comprising more than 16 million addresses, can be
mapped to a four-address pool of 205.110.96.1205.110.96.4 or smaller. The
real limitation is not the number of possible addresses in the specified IL
range, but the number of actual devices using addresses in the range. If only
four devices are using addresses out of the 10.0.0.0/8 range, no more than four
addresses are needed in the pool. If there are 500,000 devices on the inside,
you need a bigger pool.

When an address from the dynamic pool is in the NAT table, it is not
available to be mapped to any other address. If all the pool addresses are used
up, subsequent inside packets attempting to pass through the NAT router cannot
be translated and are dropped. Therefore, it is important to ensure that the NAT
pool is large enough, and that the translation timeout is small enough, so that
the dynamic address pool never runs dry.

Almost all enterprises have some systems, such as mail, Web, and FTP servers,
that must be accessible from the outside. The addresses of these systems must
remain the same; otherwise outside hosts will not know from one time to the next
how to reach them. Therefore, you cannot use dynamic NAT with these systems;
their IL addresses must be statically mapped to IG addresses. The IG addresses
used for static mapping must not be included in the dynamic address pool;
although the IG address is permanently entered into the NAT table, the same
address can still be chosen from the dynamic pool, creating an address
ambiguity.

The NAT technique described in this section can be very useful for scaling a
growing enterprise. Rather than repeatedly requesting more address space from
the addressing authorities or the ISP, you can move the existing public
addresses into the NAT pool and renumber the inside devices from a private
address space. Depending on the size of the organization and the structure of
its existing address allocations, you can perform the renumbering as a single
project or as an incremental migration.

NAT and ISP Migration

One of the drawbacks of CIDR, as discussed in Chapter 2, "Introduction
to Border Gateway Protocol 4," is that it can increase the difficulty of
changing Internet service providers. If you have been assigned an address block
that belongs to ISP1, and you want to change to ISP2, you almost always have to
return ISP1's addresses and acquire a new address range from ISP2. This
return can mean a painful and costly re-addressing project within your
enterprise.

TIP

It cannot be overemphasized that the pain and expense of an address migration
is sharply reduced when the addressing scheme is well designed in the first
place.

Suppose you are a subscriber of ISP1, which has a CIDR block of
205.113.48.0/20, and the ISP has assigned you an address space of
205.113.50.0/23. You then decide to switch your Internet service to ISP2, which
has a CIDR block of 207.36.64.0/19. ISP2 assigns you a new address space of
207.36.76.0/23. Instead of renumbering your inside systems, you can use NAT (see
Figure 4-4). The 205.113.50.0/23 address space has been returned to ISP1, but
you continue to use this space for the IL addresses. Although the addresses are
from the public address space, you can no longer use them to represent your
internetwork to the public Internet. You use the 207.36.76.0/23 space from ISP2
as the IG addresses and map (statically or dynamically) the IL addresses to
these IG addresses.

Figure 4-4 This Enterprise Has an Inside Local Address Space That Belongs
to ISP1 But Is a Subscriber of ISP2. It Uses NAT to Translate the IL Addresses
to IG Addresses Assigned Out of ISP2's CIDR Block

The danger in using a scheme such as this is in the possibility that any of
the inside local addresses might be leaked to the public Internet. If this were
to happen, the leaked address would conflict with ISP1, which has legal
possession of the addresses. If ISP2 is using appropriately paranoid route
filtering, such a mistake should not cause leakage to the Internet. As Chapter 2
emphasized, however, you should never make the assumption that an
AS-external peer is filtering properly. Therefore, you must take extreme care to
ensure that all the IL addresses are translated before packets are allowed into
ISP2.

Another problem arising from this scheme is that ISP1 will probably reassign
the 205.113.50.0/23 range to another customer. That customer is then unreachable
to you. Suppose, for example, that a host on your network wants to send a packet
to newbie@ISP1.com. DNS translates the address of that destination as
205.113.50.100, so the host uses that address. Unfortunately, that address is
interpreted as belonging to your local internet and is either misrouted or is
dropped as unreachable.

The moral of the story is that the migration scheme described in this
section is very useful on a temporary basis, to reduce the complexity of the
immediate move. Ultimately, however, you should still re-address your internet
with private addresses.

NAT and Multihomed Autonomous Systems

Another shortcoming of CIDR is that multihoming to different service
providers becomes more difficult. Figure 4-5 recaps the problem as discussed in
Chapter 2. A subscriber is multihomed to ISP1 and ISP2 and has a CIDR block that
is a subset of ISP1's block. To establish correct communication with the
Internet, both ISP1 and ISP2 must advertise the subscriber's specific
address space of 205.113.50.0/23. If ISP2 does not advertise this address, all
the subscriber's incoming traffic passes through ISP1. And if ISP2
advertises 205.113.50.0/23, whereas ISP1 advertises only its own CIDR block, all
the subscriber's incoming traffic matches the more-specific route and
passes through ISP2. This poses several problems:

ISP1 must "punch a hole" in its CIDR block, which probably
means modifying the filters and policies on many routers.

ISP2 must advertise part of a competitor's address space, an action
that both ISPs are likely to find objectionable.

Advertising the subscriber's more-specific address space represents
a small reduction in the effectiveness of CIDR in controlling the size of
Internet routing tables.

Some national service providers do not accept prefixes longer than /19,
meaning the subscriber's route through ISP2 will be unknown to some portion
of the Internet.

Figure 4-6 shows ways that NAT can help solve the problem of CIDR in a
multihomed environment. Translation is configured on the router connecting to
ISP2, and the IG address pool is a CIDR block assigned by ISP2. ISP2 no longer
advertises an ISP1 address space, so it is no longer necessary for ISP1 to
advertise the subscriber's more-specific aggregate. Hosts within the
subscriber's enterprise can access the Internet either by selecting the
closest edge router or by some established policy. The IL address of the
hosts' packets will be the same, no matter which router they pass through;
if packets are sent to ISP2, however, the address is translated. So from the
perspective of the Internet, the source addresses of packets from the subscriber
vary according to which ISP has forwarded the packets.

Figure 4-5 Because the Multihomed Subscriber's CIDR Block Is a
Subset of ISP1's CIDR Block, Both ISP1 and ISP2 Must Advertise the
More-Specific Aggregate

Figure 4-7 shows a more efficient design. NAT is implemented on both edge
routers and the CIDR blocks from each ISP become the IG address pools of the
respective NATs. The IL addresses are from the private 10.0.0.0 address space.
This enterprise can change ISPs with relative ease, needing only to reconfigure
the IG address pools when the ISP changes.

Figure 4-7 The IL Addresses of This Enterprise Have No Relationship to Any
ISP; All ISP CIDR Blocks Are Assigned to NAT Inside Global Address Pools

Port Address Translation

The many-to-one applications of NAT discussed so far have involved a
statistical multiplexing of a large range of addresses into a smaller pool of
addresses. However, there is a one-to-one mapping of individual addresses. When
an address from an inside global pool is mapped to an inside local address, for
instance, that IG address cannot be mapped to any other address until the first
mapping is cleared. However, there is a specialized function of NAT that allows
many addresses to be mapped to a single address at the same time. Cisco calls
this function port address translation (PAT). The same function is known
in other circles as network address and port translation (NAPT) or IP
masquerading. It is also sometimes referred to as address
overloading.

A TCP/IP session is not identified as a packet exchange between two IP
addresses, but as an exchange between two IP sockets. A socket is an (address,
port) tuple. For example, a Telnet session might consist of a packet
exchange between 192.168.5.2, 23 and 172.16.100.6, 1026. PAT translates both the
IP address and the port. Packets from different addresses can be translated to a
common address, but to different ports of that address, and therefore can share
the same address. Figure 4-8 shows how PAT works.

Figure 4-8 By Translating Both the IP Address and the Associated Port,
PAT Allows Many Hosts to Simultaneously Use a Single Global Address

Four packets with inside local addresses arrive at the NAT. Notice that
packets 1 and 4 are from the same address but different source ports. Packets 2
and 3 are from different addresses but have the same source port. The source
addresses of all four packets are translated to the same inside global address,
but the packets remain unique because they each have a different source port. By
translating ports, approximately 32,000 different inside local sockets can be
translated to a single inside global address. As a result, PAT is a very useful
application for small office/home office (SOHO) installations, where several
devices might share a single assigned address on a single connection to an
ISP.

NAT and TCP Load Distribution

You can use NAT to represent multiple, identical servers as having a single
address. In Figure 4-9, devices on the outside reach a server at address
206.35.91.10. In actuality, there are four mirrored servers on the inside, and
the NAT distributes sessions among them in a round-robin fashion. Notice that
the destination addresses of packets 1 through 4, each from a different source,
are translated to servers 1 through 4. Packet 5, representing a session from yet
another source, is translated to server 1.

Obviously, the accessible contents of the four servers in Figure 4-9 must be
identical. A host accessing the server farm might hit server 2 at one time and
server 4 another time. It must appear to the host that it has hit the same
server on both occasions.

Figure 4-9 TCP Packets Sent to a Server Farm, Represented by the Single
Address 206.35.91.10, Are Translated Round-Robin to the Actual Addresses of the
Four Identical Servers

This scheme is similar to DNS-based load sharing, in which a single name is
resolved round-robin to several IP addresses. The disadvantage of DNS-based load
sharing is that when a host receives the name/address resolution, the host
caches it. Future sessions are sent to the same address, reducing the
effectiveness of the load sharing. NAT-based load sharing performs a translation
only when a new TCP connection is opened from the outside, so the sessions are
more likely to be distributed evenly. In NAT TCP load balancing, non-TCP packets
pass through the NAT untranslated.

It is important to note that NAT-based load balancing, like DNS-based load
balancing, is not robust. NAT has no way to know when one of the servers goes
down, so it continues to translate packets to that address. As a result, a
failed or offline server can cause some traffic to the server farm to be
black-holed.

NAT and Virtual Servers

NAT also can allow the distribution of services to different addresses, while
giving the appearance that the services are all reachable at one address (see
Figure 4-10).

Figure 4-10 You Can Configure NAT to Translate Incoming Packets to
Different Addresses Based on the Destination Port

In Figure 4-10, the enterprise has a mail server at the local address
192.168.50.1 and an HTTP server at the local address 192.168.50.2. Both servers
have a global address of 206.35.91.10. When a host from the outside sends a
packet to the inside, the NAT examines the destination port in addition to the
destination address. In Figure 4-10, a host has sent a packet to 206.35.91.10
with a destination port of 25, indicating mail. The NAT translates this
packet's destination address to the mail server's, 192.168.50.1. A
second packet from the same host has a destination port of 80, indicating HTTP.
The NAT translates this packet's destination address to the Web
server's, 192.168.50.2.