NAT was a standard developed to deal with the depletion of IPv4 addresses. Since IPv4 addresses are 32-bit addresses, there are potentially 4.3 billion addresses available. But since IPv4 was initially divided into Class A networks (first octet = 1 to 126, 8-bit subnet, over 16 million nodes per network), Class B networks (first octet = 128 to 191, 16-bit subnet, 64K nodes per network) and Class C networks (first octet = 192 to 223, 24-bit subnet, 254 nodes per network), the situation was even worse. Class A and Class B networks were too large to be used efficiently even by large organizations, and many Class A networks were assigned to large corporations, thus further reducing the pool of available addresses. The next smallest size, Class C networks, was too small for many organizations. Many organizations ended up using multiple Class C networks, which created inefficiencies in both address use and routing. By the late 1980s, the issue was enough of an imminent threat to warrant concern, and in 1991, the Internet Engineering Task Force (IETF) formed the Routing and Addressing Group (ROAD) to deal with the issue.

The long-term solution to the problem was IPv6, which increases the length of an IP address to 128 bits. Several short-term solutions were also developed. One was the advent of Classless Inter-Domain Routing (CIDR) in 1993, which allows us to define arbitrary subnets; thus, if a Class A or B network is too large for our needs, we can divide it into smaller networks by changing the subnet mask. For example, assume we have a Class B network, which is too large for our needs, and what we actually need are several networks of 4,000 nodes each. A Class B address traditionally would have 16 bits for the network identifier and 16 bits for the host identifier. Doing the math, we realize that 2 to the power of 12 is 4096. Therefore, we only need 12 bits for the host identifier. By ceding the other 4 bits to the network identifier, we now have 20 bits for the network identifier. Our Class B network which originally supported 65534 nodes (65536 minus the first and last address) now has been divided into 16 networks of 4094 nodes each.

Another solution developed around the same time was the addition of private networks—a network that follows the standards defined in RFC 1918, the IETF document that describes address allocation for such networks. This document defined three different private address allocations, one each for Class A, B, and C networks:

• 10.x.x.x for Class A
• 172.16.x.x to 172.31.x.x for Class B
• 192.168.1.x to 192.168.255.x for Class C

Since private addresses, by definition, cannot be routed on the public internet, there must be some means of translating these addresses into public addresses and vice versa. Thus, along with private addresses, NAT was developed:

Illustration of issues presented by the existence of private addresses. Nodes with private addresses cannot directly access the internet, yet may want to access resources on the internet or may have resources that nodes on the internet want to access.

The preceding diagram suggests the different issues created by the existence of public addresses. A node on the private network may access a resource on the public network, and we need a way of making that possible; we also need a means of routing the return traffic. A node on the public internet may access a resource on the private network (such as, the file server shown), and there needs to be a way of making a socket connection to that resource. Finally, there may be a node on our network (such as a file or web server) that has its own public address that we want to be accessible on both the private network and the internet.

We will consider that last case first. 1:1 NAT is fairly straightforward; it is simply a way of connecting two networks that have incompatible addressing modes (a public network and a private network). This is not what NAT is mainly used for, but if you have multiple public IP addresses and can afford to use one for each publicly available resource, it is an option to consider.

One-to-many NAT may be more difficult to grasp, but it provides two distinct functions. It enables multiple nodes on a private network to access resources on the internet (Outbound NAT), and it enables nodes on the internet to access resources on the private network (port forwarding). Thus one-to-many NAT, also known as Dynamic NAT, performs the following functions:

• For outbound connections it, provides a means of mapping local IP addresses to the WAN address
• For outbound connections it, converts ports in the 0 to 1023 range, also known as well-known ports because they are commonly associated with certain services, to ports in the 49152 to 65535 range, also known as ephemeral ports
• For outbound connections it, keeps track to the source IP address and port so that return traffic is directed to the right location
• For inbound connections it, provides a means of mapping the WAN addresses to multiple local nodes (by directing traffic to different nodes based to their source port)

Dynamic NAT is in many ways analogous to an office with a PBX and several extensions. Outgoing calls seem to come from the same phone number, but incoming calls can be redirected to individual extensions. In this analogy, the public IP address of the network is like the phone number for the whole office, and port numbers are like extensions.

Although NAT has its advantages - it not only provides a solution to the problem of IPv4 address exhaustion, but it provides a way to hide entire private networks from the internet - it does have disadvantages as well:

• NAT traffic does not have end-to-end connectivity. Thus, services that require end-to-end connectivity can fail.
• Some protocols can work when one of the nodes uses NAT, but tend to fail when the nodes at both ends of the connection are behind a firewall that uses NAT. NAT tampers with IP headers, and this can break things such as FTP, internet telephony (SIP), SNMP, and others. IPsec, a network tunneling protocol, also sometimes has problems with the IP changes made by NAT.
• Since the advent of NAT in the 1990s, web-based content has become increasingly complex. As a result, when a web page is requested, it is rare that such a request requires only a single stateful connection. Embedded content in such pages increases the number of connections required, and web traffic alone on anything but the smallest private networks can result in port exhaustion.
• The problem with web traffic suggests a much larger issue: NAT adds complexity to networks and makes it much more difficult to troubleshoot networks. 
• As a result of applications not having access to the actual IP addresses of nodes at the other end of connections, these applications may fail and thus may have to be rewritten to work with NAT.

Thus, NAT is hardly an ideal solution, but even as IPv6 makes inroads, NAT is not likely to go away soon, and we can implement it on our networks provided that we are cognizant of the drawbacks.

The advent of IPv6 makes NAT technically unnecessary, as we can now assign public IP addresses to each node on our private network without worrying about address space exhaustion. However, private address spaces do exist in IPv6, and we may want to make use of them for administrative and security reasons. Thus, there is a way of using NAT with IPv6 called Network Prefix Translation (NPt), and we will discuss that later in this chapter.

This is not an exhaustive discussion of NAT and private addresses by any means; those sufficiently motivated may want to read the IETF documents related to these subjects. In particular, they are:

• RFC 1631 (the original NAT RFC, published in May 1994, describing one-to-many NAT)
• RFC 1918 (describing private networks)
• RFC 2663 (1:1 NAT)
• RFC 3022 (supersedes RFC 1631; describes one-to-many NAT, referred to in the document as Traditional NAT)