The TCP/IP Guide - IP NAT Unidirectional (Traditional/Outbound) Operation

Now that we understand the motivation behind NAT and its pros and cons, and have also covered NAT address terminology and translation table creation, it's time to get down to the nitty gritty of how it works. There are many different flavors of NAT, and four common ones are covered in this Guide. It makes sense to start by looking at the original variety of NAT described in RFC 1631. This is the simplest NAT method and therefore the easiest one to explain.

NAT was of course designed to allow hosts on a private network to share public IP addresses in accessing an Internet. Since most hosts are clients that initiate transactions, NAT was designed under the assumption that a client/server request/response communication would begin with a datagram sent from the inside network to the outside. For this reason, this first type of NAT is sometimes called Unidirectional or Outbound NAT. Since it is the oldest flavor it is also now called Traditional NAT, to differentiate it from newer varieties.

To show how unidirectional NAT works, we will of course use an example. Explaining things is always easier with examples, especially when it is a confusing thing like NAT. Let's use the same numbers from the previous two topics. We'll assume the inside network has 250 hosts that use private (inside local) addresses from the 10.0.0.0/8 address range (which I selected because it has small numbers!) These hosts use dynamic NAT sharing a pool of 20 inside global addresses from 194.54.21.1 through 194.54.21.20.

In our example, device 10.0.0.207 wants to access the World Wide Web server at public address 204.51.16.12. Table 74 shows the four basic steps that are involved in this (simplified) transaction. I did this in table form instead of bullet points so I could show you explicitly what happens to the addresses in both the request datagram (in steps #1 and #2) and the response datagram (steps #3 and #4). I have also highlighted the translated address values for clarity, and provided Figure 112, which shows the process graphically.

**Table 74: Operation Of Unidirectional (Traditional/Outbound) NAT**
Step #	Description	Datagram Type	Datagram Source Address	Datagram Destination Address
1	Inside Client Generates Request And Sends To NAT Router: Device 10.0.0.207 generates an HTTP request that is eventually passed down to IP and encapsulated in an IP datagram. The source address is itself, 10.0.0.207, and the destination is 204.51.16.12. The datagram is sent to the NAT-capable router that connects the organization's internal network to the Internet.	*Request* (from inside client to outside server)	10.0.0.207 (Inside Local)	204.51.16.12 (Outside Local)
2	NAT Router Translates Source Address and Sends To Outside Server: The NAT router realizes that 10.0.0.207 is an inside local address and knows it must substitute an inside global address in order to let the public Internet destination respond. It consults its pool of addresses and sees the next available one is 194.54.21.11. It changes the source address in the datagram from 10.0.0.207 to 194.54.21.11. The destination address is not translated in traditional NAT. In other words, the outside local address and outside global address are the same. The NAT router puts the mapping from 10.0.0.207 to 194.54.21.11 into its translation table. It sends out the modified datagram, which is eventually routed to the server at 204.51.16.12.	*Request* (from inside client to outside server)	194.54.21.11 (Inside Global)	204.51.16.12 (Outside Global)

3	Outside Server Generates Response And Sends Back To NAT Router: The server at 204.51.16.12 generates an HTTP response. It of course has no idea that NAT was involved; it sees 194.54.21.11 in the request sent to it, so that's where it sends back the response. It is then routed back to the original client's NAT router.	*Response* (from outside server to inside client)	204.51.16.12 (Outside Global)	194.54.21.11 (Inside Global)
4	NAT Router Translates Destination Address And Delivers Datagram To Inside Client: The NAT router sees 194.54.21.11 in the response that arrived from the Internet. It consults its translation table and knows this datagram is intended for 10.0.0.207. This time the destination address is changed but not the source. It then delivers the datagram back to the originating client.	*Response* (from outside server to inside client)	204.51.16.12 (Outside Local)	10.0.0.207 (Inside Local)

As you can see, this really isn’t rocket science, and it’s fairly easy to understand what is going on as soon as you get used to the terminology and concepts. In unidirectional NAT the source address is translated on outgoing datagrams and the destination address on incoming ones. Traditional NAT only supports this sort of outbound transaction, which is started by a device on the inside network. It cannot handle a device on the public Internet sending a request to a private address.

Please Whitelist This Site?