|
|
2.9. NAT and Private IP AddressesRFC 1918 [Rekhter, Moskowitz, Karrenberg et al. 1996] specifies that certain IP addresses are private. That is, that routers should not forward them outside the organization that is using them. The original idea was that enterprises that had no need to connect to the Internet or that needed only limited connectivity to the Internet through application gateways could use the private address space rather than obtain, and waste, globally routable addresses. Figure 2.26 lists the private address blocks and their address ranges.
If an organization is never going to connect its network to the Internet, it doesn't matter what addresses it uses, of course. Before RFC 1918, it was common for such organizations to arbitrarily choose an address block and use it. Suppose, however, that such an organization decides to add a mail gateway that is connected to both the private network and the Internet, so as to provide email services to the hosts on the private network. Figure 2.27 shows an example of this for an organization that arbitrarily chose to number the hosts in its private network with addresses from the 18.0.0.0/8 block. As shown in the figure, the mail gateway has its internalto the private networkaddress set to 18.0.0.254 and is connected to the Internet through the globally routable address 96.29.5.15. Hosts inside the private network send their outgoing email to and receive their incoming email from the mail gateway. Figure 2.27. A Private Network with a Mail Gateway
Now suppose that someone in the organization wants to send email to a user at MIT. This creates a problem because MIT is the owner of the 18.0.0.0/8 address block, and the mail gateway will try to send the mail back into the private network rather than on to the mit.edu domain. Note how this problem disappears if the organization uses one of the private address blocks instead. If that were all there was to private addresses, they would have remained a little-known backwater, especially today when almost every network that doesn't need to be completely isolated from the Internet enjoys full connectivity. When combined with network address translation (NAT), private addresses become a useful tool for conserving Internet addresses and for providing an amount of independence from any particular Internet service provider (ISP). Before we can understand how this works, we have to know a little about network address translation. NAT is typically deployed on routers at the edge of an organization's network. If we replace the mail gateway in Figure 2.27 with a NAT-enabled router and renumber the private network with one of the private address blocks10.0.0.0/8, saywe get Figure 2.28. To understand why we need NAT, let's look again at what happens when a host in the private network10.0.0.1, saysends an email to someone at MIT. The MIT mail server is at 18.7.7.76, so the IP datagrams from our user on the private network to MIT will have a source address of 10.0.0.1 and a destination address of 18.7.7.76. This datagram could be delivered as it stands, but MIT's mail server will not be able to respond, because the 10.0.0.1 address is not routable. Figure 2.28. A Private Network with a NAT-Enabled Router
Therefore, before leaving the private network, the datagram must have its source address changed so that return datagrams can find their way back. NAT can operate in three modes:
To get a better view of how PAT operates, let's drill down into the private network of Figure 2.28, as shown in Figure 2.29. Figure 2.29. Part of a Private Network Using NAT
We once again suppose that host 1 wants to establish a connection with the MIT email server at 18.7.7.76 and that it uses the source port 2443. Figure 2.30 shows the progress of the IP datagramcontaining the TCP SYN segment for the connection to MIT's mail serveras it leaves host 1, prior to having NAT applied, and after it leaves the router, which applied NAT. Figure 2.30. An Outbound Datagram Before and After NAT
As expected, the datagram has a nonroutable source address of 10.0.0.1 and a source port of 2443 as it leaves host 1. After having had the router apply NAT, the datagram has a source address of 96.29.5.15 and a source port of 5420. MIT's mail server will see a connection request from a host at 96.29.5.15.5420, and will reply to the same address and port.
We show the return datagram in Figure 2.31. Notice that as expected, the datagram arrives at the router with a destination of 96.29.5.15.5420 and a source address and port of MIT's mail server. The router looks up the 96.29.5.15.5420 in its PAT state table and discovers that the datagram should be sent to 10.0.0.1.2443. The left side of Figure 2.31 shows the datagram after the router has applied NAT. Figure 2.31. An Inbound Datagram Before and After NAT
If another host on the private network, say host 2 at 10.0.0.2, decided to send email to MIT at the same time as host 1, NAT would also map host 2's source address to 96.29.5.15 but would use a different source port, say 7322. Then when a return packet arrives addressed to 96.29.5.15.7322, NAT would know from the destination port number that the packet should be forwarded to 10.0.0.2. The advantages of NAT are immediately clear. First, it saves IP address space by requiring only a single globally routable IP address for the entire private network. Second, it helps with router table growth by requiring only a single, or at most a few, router entries for the network. Third, it allows the organization to assign private addresses to all the computers in its network and to translate those addresses to public addresses at the edge of the network, where it connects to the outside world. Thus, the organization has a measure of independence from its ISP. If the ISP institutes policies that the organization finds unacceptable or if the organization is able to negotiate a more favorable contract with another provider, it need merely change its NAT rules, and won't have to worry about renumbering all the hosts within the network. Finally, NAT can result in cost savings by allowing the organization to obtain only a single globally routable IP address from its ISP. This last advantage makes NAT especially popular with home and small-business networks. Despite these advantages, NAT is almost universally reviled among networking experts. Although we discussed NAT as if it involved a simple remapping of the internal host's address, a closer look will reveal that much more is involved. Let's consider what happens after NAT performs its translation. First, when the host's IP address is changed in the IP header, the IP header checksum is invalidated and will have to be recalculated. Next, NAT will have to look in the IP datagram to see what type of data it's carrying; if it's a TCP or UDP packet, that checksum is also invalidated, because of the pseudoheader.
This is only the beginning, though. Many application protocols, such as ftp [Reynolds and Postel 1985], require the use of more than one connection. In the case of ftp, for example, the client sends the server a PORT command asking the server to open a connection to the client at a given address and port. The address and port number are transmitted as ASCII data. Note that NAT must be aware of this for two reasons: first, it must remap the private IP address that the client sends the server; second, it must remember, and possibly remap, the port number so that it won't interfere with a previously NAT-assigned port and so that NAT will know how to map the IP/port pair back to the private network when the server responds. This means that NAT must look inside the TCP packet to see whether it's carrying an ftp PORT command. If it is, NAT must change the address and port in that command. This invalidates the TCP checksum, of course, but we already have to recalculate that because of the pseudoheader. Note, though, that the size of the segment may changemapping 10.0.0.1 to 96.29.5.15 adds 2 bytes, for example. If the client believes that the last byte it sent has sequence number n, the serverassuming, as in the example, that 2 bytes were addedwill believe that the last byte has sequence number n + 2, and will send an ACK specifying n + 3 as the next expected byte. Thus, NAT will have to change the ACK back to n + 1. Furthermore, NAT will have to remember and correct this discrepancy in sequence numbers for the remainder of the connection.
NAT can and does deal with ftp and a few other well-known protocols but will certainly break any user-written protocols that depend on passing address or port information in the data stream. For our purposes, NAT, and especially PAT, have fatal flaws. As we shall see, certain IPsec modes will detect any changes in the source or destination IP addresses and drop the datagram if a change is detected. The most common IPsec protocol, the Encapsulating Security Payload protocol (ESP), encrypts the entire TCP or UDP header, so that the ports numbers will not even be visible. Thus, PAT cannot be used with IPsec. We will come back to these problems in Part 3 when we discuss IPsec and NAT traversal. The operation of NAT, its strengths, and its weaknesses are discussed in RFC 1631 [Egevang and Francis 1994]. NAT terminology is defined and discussed in RFC 2663 [Srisuresh and Holdrege 1999]. |
|
|
