In my last post, I talked about the underpinnings of networking at the lower layers. This post is going to talk about NAT: network address translation. NAT is almost as universal as IPv4 networking, and is used nearly universally on home and small-and-medium-sized business networks—with good reason, too: Having more than one IPv4 address carries with it a not-insignificant monetary cost. This entire post is going to be about what NAT is, and what function it performs in any network, and alternatives to NAT which can be used on both IPv4 and IPv6 networks.

What is NAT?

NAT, or network address translation, is a mechanism that attempts (and fails, in many cases) to provide transparent access to the Internet for multiple IP-networked devices that can not all have public IPv4 addresses. For example, it is used in homes and many small businesses to provide Internet connectivity to multiple computers on a single connection to the Internet with a single public IP address. NAT was invented in the early 1990s (approximately 1993, if memory serves) in an attempt to delay the exhaustion of the IPv4 address space. It was effective, too, for that purpose—we probably would have ran out of IP addresses ten years ago had NAT not come into existence.

NAT has one major advantage: it enables an entire network to share a single IP address, thus conserving address space. However, NAT comes with a number of disadvantages at different levels. Some of these disadvantages are:

• Increase in network operations overhead. Most types of NAT require the ability to maintain additional tables in memory which support the task of both address and port number translation.
• Having a NAT increases the complexity of a network at the IP layer. This will be discussed in more detail in a few minutes.
• Any NAT device will perform more slowly and consume more resources than a plain router—for most computer systems, this is not a major problem. However, for networks with high-bandwidth Internet connections which are using embedded devices for routing (such as a simple, consumer-grade wireless router) this can be a problem. It can also be a problem for any network that has very old routing equipment that has been retrofitted with the ability to perform NAT, as such devices were not designed with enough processor to handle the additional overhead when the network is at full load.
• In network operating systems which behave as routers, NAT is often implemented in the same area as the firewall. For example, in the Linux kernel, the iptables command is used to set up NAT networking on an IPv4 network, and iptables is the front-end to the Linux kernel’s built-in firewall capabilities. This increases the complexity of the firewall code itself, and can make it more difficult to maintain in general, as well as more difficult to audit for security problems.
• End-to-end communication is broken. The Internet was originally designed with the concept of end-to-end communication; that is, one system on the Internet can converse with another system on the Internet directly. Not only does this simplify network design, but it simplifies the design of network applications, as well (particularly those that require bidirectional communication but do not always maintain a persistent connection and require the ability for either side to reconnect upon some sort of a trigger). Some protocols (such as SIP) have worked around this, but such workarounds can be high-cost as well as brittle.

The removal of NAT from protocol stacks therefore yields a number of benefits, including removing all of the disadvantages above. With the transition to IPv6, NAT devices are no longer necessary. Their additional complexity can go away, and networks all around the world will operate more efficiently and with less latency than they do now. It still takes I/O and processor resources to perform normal routing, but nowhere near as much as it does to perform NAT.

Over the years, multiple types of NAT implementations have been created. I am not going to go into a terribly detailed analysis of them all, but they are:

• Full-cone NAT (or, 1:1 NAT). This type of NAT provides no conservation of the address space; one external IP address maps exactly to one internal IP address. While there are uses for this type of NAT, I can think of no use for it that is not better served by another type of device, such as a load balancer, monitoring and failover, or plain routing.
• Address-restricted cone NAT. This is one of the two most common types of NAT. When a system on the inside (usually using RFC 1918 IP address space) sends an IP packet to the outside, the NAT remembers the IP address, protocol, and port of the internal system and relays it to its destination. The destination system may reply by sending packets from any of its own ports to the NAT on the source port that it sent the original packet from.
• Port-restricted cone NAT. This is the other of the two most common types of NAT. When a system on the inside sends an IP packet to the outside, the NAT remembers the same things as for address-restricted cone NAT, but replies from the destination must come from the same port as the packet was sent out to.
• Symmetric NAT. This type of NAT is similar to port-restricted cone NAT.

It is important to consider that a single NAT implementation may combine behaviors from one or more of these types, and some implementations are extremely configurable in terms of what method or methods are used to perform the functions of NAT. It is also important to realize that NAT breaks many legal network behaviors, depending on the application and the type of NAT in use. Various workarounds have been developed in order to traverse NAT devices for some protocols, and sometimes protocols will change in order to add NAT traversal as a core feature, but the overall effect is that NAT (often significantly) reduces network efficiency.

What is NAT not?

NAT is not a security mechanism.

Let me repeat that: NAT is not a security mechanism.

One more time: NAT IS NOT A SECURITY MECHANISM.

I am uncertain where people have gotten the idea that somehow NAT was designed to increase security. It was not. It was designed to help conserve the increasingly scarce resource of IPv4 address space, nothing more. It is not a security tool, and it does not provide any additional security over a properly maintained IP firewall—using a firewall is essential with or without a NAT in place if you need to do any sort of packet filtering at all.

The idea that NAT is a security mechanism probably came from the notion that one cannot see the addresses on the inside of a NAT. However, there are many mechanisms by which a sufficiently interested attacker would be able to determine things such as an approximate (or even an accurate!) count of how many devices are behind the NAT and what their IP addresses are through the use of various protocols, application tricks, and security exploits. For that matter, it is trivial to do things such as setup IPv6 on a NAT’d network and give all the systems on the NAT’d network a globally reachable IPv6 address, all without the cooperation of the NAT device. Only a firewall can stop such a thing, and only if you know what it is that you are trying to stop. And there are some things that even a firewall cannot protect you from (such as trojan horses and intentionally malicious employees and ex-employees). Security is an insanely complex problem to solve, and NAT is not a tool in a security professional’s toolbox.

How does NAT work?

A NAT device has a fully functional IP stack, and operates at a combination of OSI layers 3 (Network Layer) and 4 (Transport Layer)—mostly layer 4. In comparison, a router is an OSI layer 3 device. (In case you haven’t memorized the OSI model yet, refer back to my previous post which shows it.) Let’s say that you have a computer system that is on an IPv4 network, and that IPv4 network is using NAT. When you came to my blog to pull up this post, your Web browser performed the following tasks:

1. It looked in its DNS cache to see if the hostname mike.trausch.us was there. If it was, it used the IP address from the cache; if not, it asked your computer to find the IP address for mike.trausch.us.
2. Then, it asked the operating system to open a TCP socket connected to the IP address for mike.trausch.us on port 80. Since you are reading this, it is probably safe to say that it succeeded, and it was given a socket to work with.
3. It then asked my Web server for the post, which my Web server kindly gave to you. There are a few back-and-forths that I am omitting here for the sake of clarity.
4. The connection from your computer to my Web server was then closed.

In a normal (that is, non-NAT’d) network, this was all nice and direct, and the edge router on your network made it possible for your packets to get here. Even better, in such an event, the chatter in such an event is directly between your computer and my Web server. However, on a NAT’d network, this is not the case. Instead, this is (some of) what happens:

1. Your browser looked in its DNS cache to see if the hostname mike.trausch.us was there. If it was, it used the IP address from the cache; if not, it asked your computer to find the IP address formike.trausch.us.
2. Then, it asked the operating system to open a TCP socket connected to the IP address for mike.trausch.us on port 80.
3. Your computer’s operating system opened the socket, but not to my Web server. It just thinks it did. When the packet went out that was supposed to start the TCP handshake, it ended up at your NAT.
4. Your NAT sees the packet, and makes a note of what the source IP address (your private IP) and source port was.
5. The NAT notes the (source IP, source port) pair, and notes the destination address (e.g., the IP address for mike.trausch.us in this instance), the protocol (in this case, TCP) and sometimes also the port number (in this case, TCP port 80).
6. It then forwards the packet to my Web server on port 80.
7. My Web server receives the packet, which at this point appears to come from your external IP address, and probably a different port from the source port on your computer.
8. My Web server sends a return packet, directed at your NAT device’s IP address and the port that it sent your packet from.
9. When your NAT receives the packet, it looks in its table of entries to see if it has a mapping for the IP address and port it received a packet on.
10. It then forwards my acknowledgement to your computer.
11. All of the rest of the steps are the same, but with the NAT intercepting, looking up, and rewriting every single packet before it is shipped to its destination (either your computer or my Web server).

It is a lot more complex to do all of this, obviously.

And for larger networks, it won’t scale at all: multiple external addresses will have to be used to represent the whole network, because each NAT device can only have a mapping for one system and one (IP, port) combination at a time. What that means is that for larger NAT’d networks, you might have a different “public” IP address for every connection—or if you have a large network and only one external IP address to NAT with, you might actually wind up sometimes not being able to connect to anything at all, because the mapping table in the NAT is full.

So I Have to Learn to Use a Firewall?

Yes. Well, no. Well, sort of.

Consumer devices for use in home networks that support native IPv6 will most likely be running their own firewall with a reasonably sane default set of rules (and hopefully, the ability to change those rules!). For example, not allowing inbound packets to protected ports (those below 1024) and ports well-known to be open and accessible by default by operating systems in the Microsoft Windows family. Of course, it will also be up to people to not install services on their computer systems that are configured to service the world. That’s not terribly hard, given that we have the loopback network (127/8) that is reserved for use locally (such IP addresses aren’t even allowed to reach the physical network outside of a sole system).  This means that a system can run services that aren’t to be exposed to the world (for testing, or in order to protect them from access without first using an SSH tunnel, or for any manner of other things).

Very small, client-system-only networks will most likely use consumer-grade devices, as well, and need not worry about it for the same reasons that home networks won’t likely need to worry about it.

Power users, network administrators, and everyone else in between can instead just configure a firewall. Whatever device is providing core routing functionality more likely than not has the ability to perform firewalling as well—and if not, it’s easy to obtain an operating system and a computer that can perform the task. After all, Linux, the BSD family, and most other UNIX and UNIX-like operating systems not only can function as routers, but can firewall (and Linux and the BSDs are free). If you are the administrator of a network that has more than ten nodes on it, or the administrator of an any-sized network that has more than zero server systems on it, you should know how to use a firewall both in general and the particular implementation that you have.

What About RFC 4193 (IPv6 Private Address Space)?

RFC 4193 does indeed provide for private address space in IPv6. That does not necessarily mean that it has to have NAT. Private address space can be used to ensure that one or more subnetworks have absolutely zero Internet connectivity (or can use something such as an IPv6-enabled SOCKS server in order to have strictly controlled connectivity). However, more often than not, servers that require such security need not use address space reserved for it by RFC 4193, as it would unnecessarily complicate the network. Instead, one could use a single subnet out of their allocation of subnets, treat that subnet as “dark” or private, and configure the firewall to prohibit all (direct) communication with that subnet. If you have a correctly configured network this is trivial.

Private address space in IPv6 can also be useful to create disconnected islands, or testbed networks. However, in production networks, I would expect to see a business that has a /48, for example, simply devote a single subnetwork to private-use.

There are other means by which one can protect their network without NAT; see RFC 4864 (“Local Network Protection for IPv6″) for more information.

So, no NAT in the future?

That’s right. We are heading to a world without NAT, a world where no NAT is needed, and a world where the overhead of the Internet as a whole will be reduced as a result. That pretty much wraps it up for today’s post. Questions? Comments? You know what to do with ’em!