Network Address Translation
Technical Discussion

Not everyone wants the actual details of a NAT. But, for those that do, here they are for our products.

Technology Consulting

By the way, we are happy to work with others that wish to add NAT functionality to their products. In the nearly two years we have been providing Network Address Translation, we have learned that there is much to it beyond the RFC. Let us help you understand the finer points and not-so-obvious issues in bringing your product to market.

Network Address Translation

The standard features of Network Address Translation are detailed in RFC 1631. All of those features are supported by our NATs, including: In addition, the Net NAT expands upon the NAT standard with:

Conversion of IP Addresses

The main feature of an RFC 1631 NAT is to enable an organization to use the free IP Networks reserved in RFC 1597 while still permitting clients or servers on this network to access, or be accessed by, the public Internet. It does this through a mechanism that substitutes a globally registered IP Address into the source IP Address part of a message leaving the private network, and restores the private IP Address into the destination part of a reply message entering the private network. For example, assume a translate table of the following nature:

Name

Private IP Address

Public IP Address
ws12 192.168.16.12 204.116.73.1
ws26 192.168.16.26 204.116.73.2
ws27 192.168.16.27 204.116.73.3
ws59 192.168.16.59 204.116.73.4

A message originating at ws12 has 192.168.16.12 in the Source IP Address part of the message header. As it passes through the NAT to the Public Internet, the NAT substitutes 204.116.73.1 into that part of the header and recalculates the various message checksums. The message is then sent to the addressed host on the "outside" as though it originated from the public address. When a message arrives at the NAT from the Public Internet addressed to 204.116.73.1, the private IP Address of ws12 is substituted into the destination part of the message header, the checksums are recalculated, and the message is delivered to ws12.

Even though the four workstations in this example are spread across a wide section of the internal RFC 1597 Class C Network (192.168.16), their Public IP Addresses have been consolidated into a very small section of the external IP Network.

We Prefer Actual and Apparent

Instead of Private IP Addresses (or "reusable addresses" from RFC 1631) we prefer to call them "Actual Addresses." In the same light, we call the Public IP Addresses (non-reusables from RFC 1631) "Apparent Addresses." This seems much more understandable, and is less limiting. Many NATs are used in large Enterprise Networks that are not connected to the Public Internet, and so have no "non-reusable" addresses at all.

Correct Handling of FTP and ICMP Messages

Some of the NAT function would be much simpler if IP Addresses were only found in headers. But, several application protocols and the Internet Control Message Protocol carry IP Addresses in the message data. If a NAT is to work with these protocols, it must identify the protocol, find the embedded IP Address and fix it there, as well as in the header. Needless to say, the creation of protocols that do this should be discouraged or standardized to make the process more robust.

Dynamic Concentration of IP Addresses

An examination of the address translation table above will explain the first enhancement made to the RFC 1631 NAT. Instead of a fixed actual-to-apparent mapping, a pool of apparent addresses is created, and then dynamically assigned to the actual users. The assignment is temporary, so that apparent addresses can be used by other actual users.

Several other vendors of NAT products do this. We chose to do it differently. Please read on!

Conversion of TCP and UDP Port Numbers

The thought of tying up a large range of apparent IP Addresses seemed very silly to us, so we built the Net NAT to perform a different kind of concentration. Instead of translating just the IP Address, we also translate the TCP or UDP Port Numbers. These are also called service numbers. In our version of the address translation table, there is only one entry, and that is a single Apparent IP Address. And, instead of a pool of apparent addresses, there is a pool of "Apparent Ports."

So, when a workstation in the private network initiates a TCP session or a UDP exchange, the Net NAT assigns a port from the apparent port pool and then substitutes the apparent address and port for the actual address and port before sending the message to the public network. In a similar way, the apparent address and port in a message from the public network are replaced with the actual address and port before the message is passed to the workstation. The actual addresses may be RFC 1597 private addresses, or someone else's public addresses that were used before a connection to the Public Internet was anticipated, and must be kept to avoid the agony and expense of reconfiguring every computer in the network.

This permits the sharing of a single Apparent IP Address between a very large number of actual users. In practice, the number of users is virtually unlimited. The true limit is in the number of simultaneous sessions. That is limited by the size of the apparent port pool and the memory available for session context blocks.

BSD Authentication Server

When you connect to some BSD-derived unix hosts, they query your system to determine the identity of the user, before ever prompting you for a login. This typically wastes ten seconds of your time for each connection. Our customers wanted to know what they could do about this, and we responded by adding a server to our NAT code. We reply with a canned user identity so that the connection will complete right away.

Creation of Virtual Servers

The Net NAT can provide support for servers in the private network that need to be "seen" from the public network. Three modes are available for this function. We call them Fixed Mode, Port Mode, and Mux Mode

Fixed Server Mapping Mode

Fixed mode is the equivalent of plain RFC 1631 conversion. In this mode, a table defines a fixed relationship between apparent and actual addresses. No translation of port number is performed in this mode, since that isn't required.

Port Server Mapping Mode

Port mode is very similar to Fixed Mode, except that the fixed relationships are between combinations of apparent address and port and actual address and port. Thus, the port number is added to the translation process. Consider this new table:

Name

Actual Address and Port

Apparent Address and Port
ser12 192.168.16.12 80 204.116.73.1 80
ser26 192.168.16.26 80 204.116.73.2 80
ser27 192.168.16.27 80 204.116.73.3 80
ser59 192.168.16.59 80 204.116.73.4 80

This looks a lot like our earlier table, except that only the specified services are permitted in. This example shows 4 WWW Servers on the inside that are to be offered to users on the outside. In practice, the table also includes the higher-level protocol (TCP or UDP) so that the Net NAT may discriminate to that level. For a far more interesting configuration, consider:

Name

Actual Address and Port

Apparent Address and Port
ser12 192.168.16.12 8000 204.116.73.1 80
ser12 192.168.16.12 8001 204.116.73.2 80
ser12 192.168.16.12 8002 204.116.73.3 80
ser59 192.168.16.59 23 204.116.73.1 23

This shows three publically-visible WWW Servers on apparent addresses 1-3, and an inbound telnet destination sharing the first apparent address. While the outside "sees" three separate WWW Server "machines," there is really only one "machine" on the inside. There are, however, three separate WWW Server processes running on that machine, using ports 8000 through 8002. There is probably also one on port 80 for the internal users, but that doesn't need to be in the table. It's interesting to note that WWW requests to apparent address 1 go to machine ser12, while telnet requests go to machine ser59. This allows very tight securing of the network by directing telnets to a secured telnet proxy and keeping telnet accounts off of the WWW Server.

Mux Server Mapping Mode

This is much like Port Mode, in that an external combination of IP Address and port is mapped into the inside world. Unlike Port Mode, and unlike any established product, the Mux Mode maps incoming requests to up to four internal servers, to distribute the service load across multiple platforms. We called this our "WebMUX" product in 1994, but have added it to our standard NAT line at no extra cost.

Support for Great New Applications

The Public Internet is an exciting environment for us all. What is fueling the stunning growth is the array of wonderful new client/server applications, and new browsers for older applications. Running some of these new applications through a NAT device can be a real challenge. We mentioned the kind of problem that one encounters in our discussion of embedded IP Address and Port information. We will teach the Net NAT to deal with these applications if we can. A notable example (and a wonderful product) is Realaudio from Progressive Networks. The potential of this product encouraged us to add specific modifications to the Net NAT.

This page was last modified on April 18, 1996.

Copyright © 1996 Network Safety

This information is proprietary to Network Safety. Network Safety, WebElite and NetNAT are trademarks of Network Safety. For information on our products and services, please contact our sales department. This page was prepared using WebElite, our professional editor for the Web.