Windows Insider

NAT Expands the Net

With everyone jumping on the Internet bandwagon, address space has become hot property. But with NAT as a core function in Windows 2000, even smaller businesses can have their share of the pie.

• By Michael Chacon
• 03/01/2001

I can remember when there were arguments over whether a network would be best served with TCP/IP or some other protocol, such as IPX, or even XNS, which were each surely destined to network the world. The emergence of the Internet has solidly resolved this debate in the obvious favor of TCP/IP. This resolution has created a bandwagon — with everyone jumping on board even though the wheels are growing creaky as the participants’ numbers grow.

As is now fairly common knowledge, the address space available in the 32-bit IPv4 protocol stack doesn’t have enough room to map all of the devices that are rushing to be connected to the Internet. IPv6 is poised to resolve this and other problems with a more robust protocol stack and a 128-bit address space. But wide-scale implementation is down the road, and the movement to IPv6 will be cascading from the backbone with a slow radiation down to the client devices on the edge of the network.

Growing Pains
While we wait for the long-term solution, the growth of publicly interconnected devices continues to expand relentlessly. The addressing problem has been patched over by reswizzling the allocation of class A and B addresses recovered from entities that couldn’t justify their continued retention. ISPs and ASPs that have the architecture to rationally allocate address space across multiple client entities have acquired many of these addresses. This has stretched the ability for participation on the Internet rather well, but there’s still some expansion to go. This stretching of the address space is particularly useful for small- to medium-size companies that can’t even acquire a public class C address. When they go to their ISPs, they have the opportunity to acquire a rather small block of IP addresses, commonly in the four- to 32-address range. For the most part, this still leaves too few addresses to uniquely identify all of the devices within a given network.

What’s become a common resolution is for companies to use a private address space to build their network. These are properly built upon addresses such as 10.0.0.0, 172.16.0.0 or 192.168.0.0, which have been defined and set aside in RFC 1918 for private internal networks. But these addresses can’t be directly connected to the Internet because it would result in duplicate addresses. What makes these private addresses work on the Internet is that the internal addresses are then mapped to the public address space that has been provided to them by InterNIC or leased from their ISP. This mapping is accomplished through a method called Network Address Translation (NAT), which is described in RFC 1631. This RFC description defines the mapping and translation of IP addresses and the port numbers of the TCP and UDP packets as they’re forwarded through a router that supports NAT.

Windows 2000 NAT to the Rescue
NAT mapping has been traditionally handled by specialized routers that, in many cases, are cost prohibitive to small- to medium-size businesses that want to fully participate in the Internet. What Windows 2000 adds to this addressing technique is NAT functionality in the core product — bypassing the need for a specialized, and usually costly, router. Cisco Systems might not be too happy about this Win2K feature; but a lot of small companies are starting to use the added functionality of what used to be considered the simple and often-ridiculed multi-homed computer. A multi-homed computer is simply a PC with two or more NICs installed that have routing tables configured between them to forward traffic. At this point an example would be useful. When a client wants to establish a connection to an IP-identified resource on the network, or the Internet, it initiates that session with the following identity information:

• Destination IP address — Used to identify the ultimate resource location: 132.14.1.25

• Destination port number — Used to identify the ultimate resource service at that location: TCP 80

• Source IP address — Used to identify the client machine: 10.1.1.27

• Source port number — Used to identify the requesting service on the client machine: TCP 1025

Normally this packet would simply be routed to its ultimate destination. However, in our scenario, it’s first forwarded to the NAT software, which modifies the source address and port number as shown below:

• Destination IP address — Used to identify the ultimate resource location: 132.14.1.25

• Destination port number — Used to identify the ultimate resource service at that location: TCP 80

• Source IP address — Used to identify the client machine: 204.17.1.23

• Source port number — Used to identify the requesting service on the client machine: TCP 5001

Notice that the source address and port number now reflect a public address and a new port number. Any IP device that receives this packet will now consider it to have come from the new public address. The mapping between the internal private address and the external public address is stored in a table on the NAT router. That was, when the response is received from the target resource, the translation can be reversed and it can be forwarded to the machine that initiated the session.

When the packets come back to the NAT router’s public interface, the address is compared to the mapping table. The information from the table is translated back to the packet and forwarded to the internal private network. If no matching entry exists in the table, that packet is considered intrusive and discarded. This illustrates one of the advantages of NAT, which is protection from malicious sources trolling for access to machines in your private network.

Mapping to the Outside World
Two types of mappings are available in the NAT environment: static and dynamic. Static mappings, appropriately enough, create a consistent mapping between a particular private address and a particular public address. This is used most commonly for resources you want exposed to and reachable from external clients, but also available on the internal private network. The most common examples would be a Web or mail server.

A dynamic mapping arbitrarily changes each time a session is established. As dynamic mapping is used, it’s refreshed in the mapping table. If a dynamic mapping isn’t used for a specific period of time, it’s flushed from the table. This period of time is configurable with a default time of 24 hours for TCP connections and 60 seconds for UDP packets.

Do a Lot with Just a Little
NAT variations to consider depend upon whether you have a large public address space to work with or only a handful of addresses. As you can see, the first method I outlined suggests that you have a unique public address available for each private address that requires mapping.

If you don’t have a large public address space available — and usually you won’t — you can do what’s referred to as Port Address Translation (PAT). With PAT you only need enough public addresses to map specific resources that you want exposed outside of your network. For example, along with your Web and mail server, you may have a database and a handful of file servers that you want clients to be able to connect to across the Internet. With this example, you could get by with a block of eight public addresses from your ISP to cover these servers — with a little room to grow. You could then create static mappings to these servers and use only one of the remaining addresses for “one direction” traffic. What I mean by this is that outside clients can’t establish a session with internally addressed machines. However, multiple machines in your private network can establish sessions to resources in the public network by sharing one public address in your NAT and uniquely identifying the internal machines using port numbers. This would allow your internal machines to browse the Internet but not be reachable from outside requests.

But There’s More
As you can see, NAT and PAT are fairly straightforward, but there’s another consideration with this technique. TCP and UDP headers are designed for modification as necessary for fundamental routing. However, some protocols that use IP, such as FTP, ICMP and PPTP, also carry IP addressing information in what IP considers the data portion of the packet. For example, the FTP port command (from RFC 265), which is used to locate the exposed FTP service running on the target machine, stores the dotted decimal notation of the target IP address in the data portion of the packet. If the NAT translates the IP header information but not the address information stored in the FTP packet, they won’t match after the translation that occurs during NAT and, therefore, won’t work properly.

This problem is resolved by using a NAT editor. The NAT editor is a software component that modifies the necessary information in the packets so that embedded information is in agreement with the information supplied in the IP packet headers as they’re translated and forwarded during the NAT process.

So What Does This All Mean?
NAT is a great straightforward technique that not only expands the available address space, particularly for smaller organizations, but also provides another layer of security from external maliciousness. But how does all of this general information relate to Win2K? Now that I’ve provided the overview of how NAT is used and generally functions, next month I’ll discuss how NAT and PAT are implemented in Win2K. Stay tuned.