NAT – Network Address Translation

In the early 1990’s engineers in the IETF began to realize that we were going to run out of IPv4 public addresses in a very short time – perhaps by 2005 or so, if we didn’t make some major changes. First, they began developing the successor protocol to IPv4 (later to be called IPv6) as the real, long term solution. But they knew this would take a long time to design and mature. So, there were also a number of short term fixes created and rapidly deployed. These include:

RFC 1631 was later replaced by RFC 3022, “Traditional IP Network Address Translator (Traditional NAT)”, January 2001. RFC 1519 was later replaced with RFC 4632, “Classless Inter-Domain Routing (CIDR)”, August 2006.

CIDR helped slow the rate that IPv4 addresses were being allocated by providing a closer fit to the needs of the customers in terms of allocation block size. Before CIDR, there were only 3 allocation block sizes: Class A (16.7 million addresses), Class B (65,534 addresses) and Class C (254 addresses). In theory someone could obtain several contiguous Class B or several Class C blocks, but this usually involved messy routing. Fully half of the address space (0/8 to 127/8) was giant Class A blocks. Half of what remained was smaller, but still large Class B blocks. Half of what remained after that was about 2 million tiny Class C blocks.

After CIDR, the larger blocks could be broken up into any of 23 different allocation block sizes, from /8 down to /30.

What Are the Details of Your ISP Service?

Until recently, home and SOHO Internet service usually included one public IPv4 address, configured on the external (WAN) interface of your modem/router (also known as Customer Premises Equipment, or CPE). Now, new service may be behind CGN (Carrier Grade NAT), and your service includes no public IPv4 addresses at all. The WAN interface of your modem/router gets a private IPv4 address, then you hide your own private internet behind that private address. You are now going through not one, but two NAT44 gateways (one in your CPE, and one at the ISP). Basically, the translation process described below happens twice (on both outgoing traffic and incoming traffic). With this kind of service you cannot do Port Forwarding to run a public server, or 6in4 tunneling to bring IPv6 into your LAN. Some network protocols (like HTTP/HTTPS) work fine going out through multiple layers of NAT. Other protocols that may have worked through one layer will break when there are two layers. To do BINAT, you actually need at least two public IPv4 addresses. Good luck getting those today.

Many ISPs have commercial service available (although they may give you grief about installing it in a home) that comes with not just one Public IPv4 address, but several. For example, my home service is a commercial account, and includes an entire /29 block (five usable public IPv4 addresses). I have to pay a real premium for this (close to 5X the price of the same speed, but with only one public IPv4 address), and as IPv4 goes further and further past its shelf life, this will certainly increase. To an ISP, each public IPv4 address is another potential home/SOHO “customer”, and they are already very short of public addresses. In comparison, I have 2.9 E+20 public IPv6 addresses, just for my home network. They came free with the ISP service in my colo (which amazingly is only twice the cost of my service at home – and it has 254 public IPv4 addresses – but that is in the US and my home account is in the Philippines).

Most home and SOHO ISP service is asymmetric (e.g. ADSL) – the downlink speed (traffic from external nodes into your network) should be the “advertised speed” (e.g. 1 Mbit), while the uplink speed (traffic from your network to external nodes) is much slower (maybe 10% of downlink speed). If you run a web server in such a network, your uplink speed will almost certainly be the bottleneck in people accessing your server. To get the same speed on upload as download, you need symmetric service (e.g. SDSL or T1 / E1). This is generally much more expensive than asymmetric service. Even though you can run a web server in your home, you may prefer to run it in a co-location (hosting) facility where they have higher bandwidth and plenty of public IP addresses. As an alternative, you can rent rack space and provide your own servers, or share one of the colo’s servers using virtualization (or FreeBSD jails). You can also rent space “in the cloud”, e.g. AWS or Azure. For example, our co-location facility has symmetric 100 MBit native IPv4 and IPv6 service, with 256 public IPv4 addresses and a /48 block of IPv6 addresses (enough for 65,536 /64 subnets).

Another aspect of Internet Service is the Committed Information Rate (CIR). Even if the service you bought is advertised as a “1 Mbit” or “8 Mbit” connection, read the contract. That may be the “burst” speed (it may occasionally go that fast, for a limited time). The only bandwidth they are obligated to provide to you is the CIR in the contract (usually 10% or less of the “burst” speed). The more expensive commercial accounts may come with a 100% CIR. In other words, if your service plan claims to be 4 Mbit, you actually get 4 Mbit of real service, at all times (or at least you are supposed to, and can complain if you don’t). If you don’t have a 100% CIR plan, and often get far less than the plan rate, and complain, they will refer you to the contract and explain all about CIR. I once had a 1.5 Mbit ADSL plan with a CIR of only 12Kbit. The ISP service in our colo is 100 Mbit with 100% CIR. Of course it costs about 25 times what typical home ISP service costs, but it is still a really good deal, and can handle serious commercial web traffic with no problem.

The details of your ISP service have a major impact on this discussion. For example:

If you don’t have any public IPv4 address, you can do outgoing connections with most protocols through Hide-Mode NAT, but you can’t do any incoming connections, via Port Forwarding or BINAT. You can’t use 6in4 tunneling to bring IPv6 into your network (you may still be able to use TSP or 6rd).

If you have only a single public IPv4 address, you can use it for Hide-Mode NAT and do outgoing connections through Hide-Mode NAT, and you can do limited incoming connections via Port Forwarding. You can also use that same public address for 6in4 tunneling to bring IPv6 into your network.

If you have multiple public IPv4 addresses, you can use one for Hide-Mode NAT and 6in4 tunneling, plus create one BINAT mapping for each additional public address beyond the one used for Hide-Mode NAT. For nodes with a BINAT mapping, you can do incoming and outgoing connections using any port. For other nodes, you can do outgoing connections via Hide-Mode NAT, and you can do limited incoming connections via Port Forwarding.

Private Internets

Look at the name of RFC 1597 (March 1994), later updated to RFC 1918 (February 1996): “Address Allocation for Private Internets“. The IETF knew exactly what they were doing. Not “private addresses for the Internet”, but “addresses for private internets”. Anyone can build a private internet (lower case i), completely disconnected from the Public Internet (upper case I), controlled by that organization (or organizations). It can have numerous subnets, and even be global in geographic scope. For example, NIPRNet and SIPRNet were global private internets completely owned and run by the U.S. Department of Defense. NIPRNet was the Nonclassified Internet Protocol Router Network. SIPRNet was the Secret Internet Protocol Router Network. Neither has any connections to the Public Internet (or each other). “Air gaps” are an amazingly effective security mechanism. NIPRNet and SIPRNet are TCP/IP based networks and they can use any IPv4 addresses they want, because there is no possible conflict between the IPv4 addresses on those private internets and those on the public IPv4 Internet. They use the same address ranges for unicast and multicast as the Public Internet, so they can use existing network software and routers. However, they don’t need to use NAT because there are plenty of public IPv4 addresses for all the nodes in those entire private internets. Even though NIPRNet is the largest private internet in the world, it still has far less than a billion nodes connected, so they can give every node on it a real IPv4 address. Just like the real public IPv4 Internet was before RFC 1918 and NAT.

BTW, NIPRNet is still around, but is now called the Sensitive but Unclassified IP Data (SBU-IP). SIPRNet is now called Secret IP Data (Secret-IP).

Private internets are useful, but a node connected to one can’t connect to any servers on the Public IPv4 Internet, or run servers that can be accessed from nodes in the Public Internet. The remaining part of the splintering of the Public IPv4 Internet into millions of private internets was provided by the creation and deployment of NAT (Network Address Translation) – specifically “hide mode” NAT, which allows many nodes with private addresses (actually entire private internets) to be hidden behind one (or a few) public IPv4 addresses. We now call this NAT44 (Network Address Translation from IPv4 to IPv4) to differentiate it from other forms of NAT (like NAT64).

Today, the IPv4 Internet is irreversibly splintered into tiny fragments. Some people call it the “InterNAT”. There are not even enough public IPv4 addresses left to continue in that damaged form. There is no possible way of restoring the single, flat address space of the early IPv4 Internet, aside from migration to IPv6. This is the single biggest reason to migrate. The IPv6 Internet has no NAT66. It is (and will continue to be) a single, flat address space that covers the entire world. All of the problems associated with the temporary fixes of private internets and NAT44 do not exist in IPv6.

Network Address Translation (NAT or NAT44)

This is one of the most difficult topics to understand in the entire TCP/IP tutorial. I’ve tried to make it clear, but NAT is just really complex, and has many problems. It was a necessary evil to extend the life of the IPv4 Address space for another 10 or 15 years, and it did that. But those years were over about 2010. In 2011, IPv4 addresses started running out.

The only reason for NAT in IPv4 was to extend the lifetime of the IPv4 address space. It has NO other benefits. It does not improve the security of your network in any way. It actually makes securing things with a firewall much more complicated, than on a network without NAT. The last thing we want to do is to implement NAT in the IPv6 Internet. We’ve got all the addresses we could possibly ever use there. We don’t need to extend the lifetime of the IPv6 address space. Therefore there is no excuse whatever to deploy NAT66. However, some people are so used to using NAT in IPv4, they are trying to do this. These people need to understand exactly what NAT was for and give up on this really bad idea.

In the following sections we will use “addr:port” notation. For example, address 172.20.0.13, port 80 will be written 172.20.0.13:80.

How does a connection work when there is no NAT involved?

Say we have an internal client (lawrence-pc.hughesnet.org) at 172.20.2.1 that connects to an internal web server (ws3.hughesnet.org) at 172.20.0.13. Both addresses are in the private internet, so no address translation is required. The client (lawrence-pc) uses the destination address 172.20.0.13, port 80. It uses its own IPv4 address (172.20.2.1) as the source address, and obtains an unused high port from the OS for its source port (e.g. 10123). So the outgoing packets have a source of 172.20.2.1:10123, and destination of 172.20.0.13:80. Replies will be coming from source 172.20.0.13:80 to destination 172.20.2.1:10123. Everything works fine, because both the source and the destination nodes are in the same internet (which happens to be private).

Internal client to internal server:

Source address: 172.20.2.1:10123, destination address: 172.20.0.13:80

Internal server to internal client:
Source address: 172.20.0.13:80, destination address: 172.20.2.1:10123
It’s really easy when there is no NAT involved! Any internal node can connect to any other internal node. You can extend this to a multiple subnet LAN with routers (as long as you don’t implement internal NAT gateways). This is how the entire global IPv4 Internet was before NAT, and how the IPv6 Internet is today!
Kinds of NAT

There are actually several kinds of NAT. The most common are:

Bidirectional (One to One) NAT (also known as BINAT)
Port Forwarding 

If you have only a single public IPv4 address for your SOHO network, you can still run a public server or two (maybe web and email) by forwarding packets sent to your gateway to an internal server, based on the port number (e.g. 80 for HTTP, 443 for HTTPS, 25 for SMTP, etc). This is called Port Forwarding. Even small home routers usually support this kind of NAT. For example, you call configure your router to forward traffic for port 80 and 443 to node 172.20.2.1, and traffic for port 25 to node 172.20.0.21. You publish a domain name, such as router.hughesnet.org in DNS, and provide CNAME aliases for www and mail pointing to router.hughesnet.org. Then anyone, from anywhere on the Public IPv4 Internet can connect to your internal web server at www.hughesnet.org port 80, or your mail server at mail.hughesnet.org port 25.

What if you have two web servers, and you want to run both of them with the standard port 80? Port Forwarding cannot handle this. With Port Forwarding, you can forward port 80 traffic only to one internal address. You can’t forward it to two separate addresses.

So let’s say internal node lawrence-pc (at 172.20.2.1) and is running a web server. The WAN interface of the gateway has the public IPv4 address 125.83.56.187. The gateway is doing Port Forwarding of port 80 to internal node 172.20.2.1. An external node (at 123.45.67.89) wants to connect to the internal web server on lawrence-pc. The external node has to know to connect to the public address on the WAN interface of your gateway (125.83.56.187) – so publish that address in DNS for the domain name you want people to use (e.g. www.hughesnet.org).

Let’s say port 10123 is available on the external node. Incoming packets from external node 123.45.67.89 to internal node lawrence-pc (125.83.56.187) look like this:

Source 123.45.67.89:10123, Destination 125.83.56.187:80

After going through the gateway, they look like this:

Source 123.45.67.89:10123, Destination 172.20.2.1:80

The reply packets from lawrence-pc to the external node look like this:

Source 172.20.2.1:80, Destination 123.45.67.89:10123

After going back through the gateway, they now look like this:

Source 124.83.56.190:80, Destination 123.45.67.89:10123

For incoming packets, only the destination address is translated. The destination port is left unchanged. For outgoing replies, only the source address is translated. The source port is left unchanged.

Hide-Mode NAT (many to one, NAPT) 

Hide-mode NAT (also known as NAPT, or Network Address and Port Translation) involves hiding an entire private internet (often only one subnet, but it can be many) behind a single public IPv4 address.

So what happens when lawrence-pc (in a private internet) connects to an external web server (www.v4address.com)?

NAPT does on-the-fly mapping between private IPv4 addresses and public IPv4 addresses, for both incoming and outgoing traffic, but only for outgoing connections. Lawrence-pc (at 172.20.2.1) wants to connect to a public web server (www.v4address.com at 184.105.238.114). Lawrence-pc can’t connect to it directly, it has a private address. The outgoing connection must be translated at the border gateway. The gateway has the public address 124.83.56.187 on the WAN side. The gateway can’t just route the packets normally, because the external server cannot send responses back to a private IP address in your private internet. That private address might exist in thousands of private Internets around the world. Which one would it reply to? How could it find the right one? It can only send responses to a node that has a public IPv4 address. So, as the packets go through the gateway node, it has to translate the source address to the public address of the WAN interface of the gateway (123.83.56.187). What about the source port? The gateway must translate the source port number to an unused high port number on the gateway itself, so that it can identify which internal node the reply is for. Hence the name Network Address and Port Translation (NAPT).

Assume that port 15234 is available on the gateway. The gateway translates the source address & port from 172.20.2.1:10123 to 125.83.56.187:15234. It also keeps track of this translation in a table (“I shifted the 172.20.2.1:10123 to port 15234“). Now the packets are from 125.83:56.187:15234 (one node on the public Internet) to www.v4address.com at 184.105.238.114:80 (another node on the public Internet). The reply from www.v4address.com comes back normally to the gateway, from 184.105.238.114:80 to 125.83.56.187:15234 (the WAN interface of your gateway). The gateway looks in its translation table, and sees that incoming traffic to port 15234 should be directed to internal node 172.20.2.1:10123. It translates the destination address in the incoming packets to 172.20.2.1:10123, and the packet reaches lawrence-pc.

Assume that port 10123 is available on lawrence-pc. The packets from internal node lawrence-pc (172.20.2.1) to external node www.v4address.com (184.105.238.114) look like this:

Source 172.20.2.1:10123, Destination 184.105.238.114:80

After going through the gateway (which has port 15234 available), they look like this:

Source 125.83.56.187:15234, Destination 184.105.238.114:80

On return, the reply packets from www.v4address.com to alice-pc look like this:

Source 184.105.238.114:80, Destination 125.83.56.187:15234

After going back through the gateway, they now look like this:

Source 184.105.238.114:80, Destination 172.20.2.1:10123

For outgoing packets, both the source address and source port are translated. For incoming replies, both the destination address and destination port are translated.

If another internal node, remy-pc (172.20.2.2) makes an outgoing connection to www.v4address.com, its private address is translated to the same public address (after all, that’s the only public address on the border gateway!). Let’s assume remy-pc has port 20456 available, and that the gateway has port 30678 available.

The packets from internal node remy-pc (172.20.2.2) to external node www.v4address.com (184.105.238.114) look like this:

Source 172.20.2.2:20456, Destination 184.105.238.114:80

After going through the gateway (which has port 30678 available), they look like this:

Source 125.83.56.187:30678, Destination 184.105.238.114:80

On return, the reply packets from www.v4address.com to remy-pc look like this:

Source 184.105.238.114:80, Destination 125.83.56.187:30678

After going back through the gateway, they now look like this:

Source 184.105.238.114:80, Destination 172.20.2.2:20456

All internal nodes behind Hide-Mode NAPT will appear to be coming from the same public address, the one used for Hide-Mode NAPT. If either lawrence-pc or remy-pc surf to whatismyipaddress.com, they will both get the public address of the gateway (125.83.56.187). If lawrence-pc gets blocked by someone by IP address, so does remy-pc. If remy-pc is used to hack someone, it will be difficult for the owner of lawrence-pc to convince the victim that he didn’t do it – after all the attack came from his IP address!

Also notice that every simultaneous outgoing connection consumes one available port on the gateway. If each node uses 300 ports on the average (common with apps like Google Maps or iTunes), how many internal nodes can one gateway support? There are a maximum of 65,000 or so ports to use. So, at 300 per internal node, you could have at most 200 nodes behind one IP address. Some companies have thousands of nodes behind one public address. Oops! What happens when the gateway runs out of available ports? Outgoing connections start failing, but it is very difficult to track down where the failure was. The gateway has no way to tell the internal nodes it has run out of ports.

What about incoming connections from external nodes (e.g. 123.45.67.89) to internal nodes behind Hide-Mode NAPT (apart from any using Port Forwarding)?

If an incoming connection from external node 123.45.67.89 hits the border gateway, it will look up the incoming port in its translation table, and won’t find the port. It can’t reverse a translation it never made. Sorry, Charlie. No incoming connections to most nodes behind Hide-Mode NAPT. It’s a one-way Internet for you! You can make outgoing connections, but nobody can connect to you. The one exception is applications that support NAT Traversal, like Skype (covered elsewhere).

What about IPsec? IPsec AH in transport mode uses a keyed HMAC to detect any changes in certain fields (that include the source and destination IP addresses and ports). Guess what IPsec says about the things NAT does to your packets? It identifies it (correctly) as an attack! To use IPsec on the IPv4+NAT Internet, you must use NAT Traversal.

Bidirectional (one to one) NAT (also known as BINAT)

BINAT creates a bidirectional mapping between one internal private address and one external public address. Unlike with Port Forwarding, all ports are mapped. In addition to the one public IPv4 address used for Hide Mode NAT, Bidirectional NAT requires another public IPv4 address for each mapping. If you have three internal servers using BINAT, you need four public IPv4 addresses (one for Hide Mode, and one for each internal server). The internal server has only the private address assigned. It never actually sees the public IPv4 address it is mapped to. That address is actually assigned as an alias address to the WAN interface of your border gateway (in addition to the public IPv4 address used for Hide Mode NAT). If you want two internal web servers, both using the standard port 80, you can do it with BINAT (recall this cannot be handled with Port Forwarding). The BINAT address translation works pretty much like Hide Mode NAT, except there is no need to shift the port number, and incoming connections are possible.

BINAT does on-the-fly mapping between one private IPv4 address and one public IPv4 address (not the one used for Hide Mode NAT), for both incoming and outgoing traffic.

For incoming connections, a web server on ws4.hughesnet.org (at 172.20.0.14) wants to allow connections from any web client on the IPv4 Public Internet. Node ws4 is mapped with BINAT behind public address 124.83.56.190. The gateway has the the public address 124.83.56.190 on the WAN side (as an alias address), so it can accept packets with that as destination address. A node on the Public IPv4 Internet (123.45.67.89) can’t connect to ws4’s private address, so the destination address on incoming packets (124.83.56.190) must be translated at the border gateway to the private address of ws4 (172.20.0.14). The destination port number (80)does not need to be translated. The packet with translated destination address continues to ws4. Replies are sent back to 123.45.67.89 from source address 172.20.0.14. At the gateway, the source address is translated to 124.83.56.190. From there, the packet continues to the external node.

So what happens when ws4 makes an outgoing connection? The same thing in reverse. Say it wants to connect to www.v4address.com at 184.105.238.114:80. It sends a packet with source address 172.20.0.14 and destination address 184.105.238.114. When it hits the gateway, the source address is translated to 124.83.56.190 (the source port is not translated). From there, the packet can now continue to external node 184.105.238.114. When that node replies, a packet with source address 184.105.238.114 and destination address 124.83.56.190 is sent. The gateway (having 124.83.56.190 as an alias address) accepts the packet. That packet can’t be sent to internal address 172.20.0.14, so the destination address is translated to 172.20.0.14 (the destination port is not translated). At that point, the reply can go to ws4 with no problem.

Let’s say port 10123 is available on the external node. Incoming packets from external node 123.45.67.89 to internal node ws4.hughesnet.org (172.20.0.14) look like this:

Source 123.45.67.89:10123, Destination 124.83.56.190:80

After going through the gateway, they look like this:

Source 123.45.67.89:10123, Destination 172.20.0.14:80

On return, the reply packets from ws4.hughesnet.org look like this:

Source 172.20.0.14:80, Destination 125.83.56.187:10123

After going back through the gateway, they now look like this:

Source 124.83.56.190:80, Destination 123.45.67.89:10123

For incoming packets, just the destination address is translated. The destination port is left unchanged. For outgoing replies, just the source address is translated. The source port is left unchanged.

What about outgoing connections from a BINAT mapped node? It doesn’t use Hide-Mode NAT! If you surf to whatismyipaddress.com, it will show the public address mapped to this internal node using BINAT, not the public address used for Hide-Mode NAT. Let’s say internal node ws4 has port 20456 available. For outgoing packets from internal node ws4 (172.20.0.14) to external node www.v4address.com (184.105.238.114:80), look like this:

Source 172.20.0.14:20456, Destination 184.105.238.114:80

After going through the gateway, they look like this:

Source 124.83.56.190:20456, Destination 184.105.238.114:80

On return, the reply packets from www.v4address.com look like this:

Source 184.105.238.114:80, Destination 124.83.56.190:20456

After going back through the gateway, they now look like this:

Source 184.105.238.114:80, Destination 172.20.0.14:20456

For outgoing packets, just the source address is translated The source port is left unchanged. For incoming replies, just the destination address is translated. The destination port is left unchanged.