Network Address Translation (NAT) | Hotspot Networks(c) Wi-Fi for Public Access Locations

As noted, a typical hotspot network employs NAT to support nomadic users. Several types of NAT methods are described by the Internet Engineering Task Force (IETF) in various Request for Comments (RFCs); the key ones are listed in Table 8-3. RFC 3022 is the baseline document.

8-3. : Key NAT-related RFCs

click to expand

A technique called overloading (also known also as Port Address Translation [PAT], single-address NAT, or port-level multiplexed NAT), is the recommended form of dynamic NAT to map multiple unregistered IP addresses to a single registered IP address via different ports.

With PAT, the following actions take place:

An internal network of APs and wireless bridges is set up with nonregistered/nonroutable IP addresses.
The hotspot carrier sets up the router to the Internet with NAT capabilities enabled. The router has a unique IP address given to the carrier by IANA or by an Internet network service provider (NSP).
A computer on a wireless domain attempts to connect to a computer on the Internet, such as a web server.
The router receives the packet from the station on the wireless domain.
The router saves the station's nonroutable IP address and port number to an address translation table. The router replaces the sending station's nonroutable IP address with the router's IP address. The router replaces the sending station's source port with the port number that matches where the router saved the sending station's address information in the address translation table. The translation table now has a mapping of the wireless station's nonroutable IP address and port number along with the router's IP address.
When a packet returns from the destination host on the Internet, the router looks at the destination port on the packet. It then scans the address translation table to see which station on the wireless domain the packet belongs to. It changes the destination address and destination port to the one saved in the address translation table and sends it to that station.
The station receives the packet from the router and the process repeats as needed.
Since the NAT router now has the wireless station's source address (likely provided via DHCP) and source port saved to the address translation table, it will continue to use that same port number for the duration of the connection. A timer is reset each time the router accesses an entry in the table. If the entry is not accessed again before the timer expires, the entry is removed from the table.

Note that it's perfectly possible to maintain some devices on the private domain that use dedicated IP addresses (infrastructure nodes or high-usage nodes). One can create an access list of IP addresses that instructs the router as to which devices on the network require NAT; the other IP addresses will pass through untranslated.

The number of simultaneous translations that a router can support is determined in large measure by the amount of Dynamic Random Access Memory (DRAM) it possesses. A typical entry in the address translation table requires about 160 bytes; hence, a router with 4 MB of DRAM can theoretically process 26,214 simultaneous translations.

IANA has actually set aside specific ranges of IP addresses for use as nonroutable internal network addresses. These addresses are considered unregistered, (see RFC 1918: Address Allocation for Private Internets).^[4] A range is recommended for each of the three classes of IP addresses used for networking:

Range 1/Class A: 10.0.0.0 through 10.255.255.255
Range 2/Class B: 172.16.0.0 through 172.31.255.255
Range 3/Class C: 192.168.0.0 through 192.168.255.255

Working with NAT

The NAT operation described in RFC 3022^[1] extends the address translation introduced in RFC 1631 and includes a new type of network address and Transmission Control Protocol/User Datagram Protocol (TCP/UDP) port translation. Basic NAT is a method by which IP addresses are mapped from one group to another, transparent to end users. Network Address Port Translation (NAPT) is a method by which many network addresses and their TCP/UDP ports are translated into a single network address and its TCP/UDP ports. Together, these two operations, referred to as traditional NAT, provide a mechanism to connect a realm that has private addresses to an external realm with globally unique registered addresses. The discussion that follows is with reference to the RFC.^[2]

Introduction to NAT Engineering The need for IP address translation arises when a network's internal IP addresses cannot be used outside the network either for privacy reasons or because they are invalid for use outside the network.

Network topology outside a local domain can change in many ways. Customers may change providers, company backbones may be reorganized, or providers may merge or split. Whenever external topology changes with time, address assignments for nodes within the local domain must also change to reflect the external changes. Changes of this type can be hidden from users within the domain by centralizing changes to a single address translation router.

Basic address translation would (in many cases, except as noted in Srisuresh and Holdrege)^[3] enable hosts in a private network to transparently access the external network and enable access to selective local hosts from the outside. Organizations with a network set up predominantly for internal use, with a need for occasional external access, are good candidates for this scheme.

Many Small Office, Home Office (SOHO) users and telecommuting employees have multiple network nodes in their office running TCP/UDP applications, but they have a single IP address assigned to their remote access router by their service provider to access remote networks. This ever-increasing community of remote access users would be benefited by NAPT, which would permit multiple nodes in a local network to simultaneously access remote networks using the single IP address assigned to their router.

Using the translation method has its limitations, however. It is mandatory that all requests and responses pertaining to a session be routed via the same NAT router. One way to ascertain this would be to have NAT based on a border router that is unique to a stub domain, where all IP packets are either originated from the domain or destined to the domain. There are other ways to ensure this with multiple NAT devices. For example, a private domain could have two distinct exit points to different providers, and the session flow from the hosts in a private network could traverse through whichever NAT device has the best metric for an external host. When one of the NAT routers fails, the other could route traffic for all the connections. However, the caveat with this approach is that rerouted flows could fail at the time of switchover to the new NAT router. A way to overcome this potential problem is that the routers share the same NAT configuration and exchange state information to ensure a failsafe backup for each other.

Address translation is application independent and often accompanied by application-specific gateways (application-level gateways [ALGs]) to perform payload monitoring and alterations. File Transfer Protocol (FTP) is the most popular ALG resident on NAT devices. Applications requiring ALG intervention must not have their payload encoded, as doing that would effectively disable the ALG, unless the ALG has the key to decrypt the payload.

This solution has the disadvantage of taking away the end-to-end significance of an IP address and making up for it with increased state in the network. As a result, end-to-end IP network-level security assured by IP Security (IPSec) cannot be assumed to end hosts, with a NAT device en route. The advantage of this approach, however, is that it can be installed without changes to hosts or routers.

Definitions of terms such as address realm, transparent routing, TCP/UDP (TU) ports, ALG, and others, used throughout the section, may be found in Srisuresh and Holdrege's 'IP Network Address Translator (NAT) Terminology and Considerations.'^[3]

Traditional NAT

The address translation operation presented in RFC 3022 is referred to as traditional NAT. Other variations of NAT exist but will not be explored here. In most cases, traditional NAT enables hosts within a private network to access hosts in the external network transparently. Sessions are unidirectional, outbound from the private network. Sessions in the opposite direction may be allowed on an exceptional basis using static address maps for preselected hosts. Basic NAT and NAPT are two variations of traditional NAT, in that translation in Basic NAT is limited to IP addresses alone, whereas translation in NAPT is extended to include the IP address and transport identifier (such as the TCP/UDP port or Internet Control Message Protocol [ICMP] query ID).

Unless specifically mentioned, usage of the terms address translation or NAT throughout this chapter should be read as traditional NAT, namely Basic NAT and NAPT. Only the stub border routers, as described in Figure 8-19, may be configured to perform address translation.

click to expand
Figure 8-19: Traditional NAT configuration

Summary of Basic NAT Basic NAT operation is as follows. A stub domain with a set of private network addresses could be enabled to communicate with the external network by dynamically mapping the set of private addresses to a set of globally valid network addresses. If the number of local nodes is less than or equal to addresses in the global set, each local address is guaranteed a global address to map to. Otherwise, nodes permitted simultaneous access to the external network are limited by the number of addresses in the global set. Individual local addresses may be statically mapped to specific global addresses to ensure guaranteed access to the outside or to enable access to the local host from external hosts via a fixed public address. Multiple simultaneous sessions may be initiated from a local node, using the same address mapping.

Addresses inside a stub domain are local to that domain and not valid outside the domain. Thus, addresses inside one stub domain can be reused by other stub domains. Single Class A addresses are used by many stub domains. NAT is installed at each exit point between a stub domain and a backbone. If more than one exit point exists, it is essential to ensure that each NAT has the same translation table.

For instance, in the example of Figure 8-20, both stubs A and B internally use class A private address block 10.0.0.0/8.^[4] Stub A's NAT is assigned the class C address block 198.76.29.0/24, and stub B's NAT is assigned the class C address block 198.76.28.0/24. The class C addresses are globally unique; no other NAT boxes can use them.

click to expand
Figure 8-20: Basic NAT operation

When stub A host 10.33.96.5 wishes to send a packet to stub B host 10.81.13.22, it uses the globally unique address 198.76.28.4 as the destination and sends the packet to its primary router. The stub router has a static route for net 198.76.0.0, so the packet is forwarded to the WAN link. However, NAT translates the source address 10.33.96.5 of the IP header to the globally unique 198.76.29.7 before the packet is forwarded. Likewise, IP packets on the return path go through similar address translations.

Notice that this requires no changes to hosts or routers. For instance, as far as the stub A host is concerned, 198.76.28.4 is the address used by the host in stub B. The address translations are transparent to end hosts in most cases. Of course, this is just a simple example. There are numerous issues to be explored.

Summary of NAPT Let's say an organization has a private IP network and a WAN link to a service provider. The private network's stub router is assigned a globally valid address on the WAN link and the remaining nodes in the organization have IP addresses that have only local significance. In such a case, nodes on the private network could be allowed simultaneous access to the external network, using the single registered IP address with the aid of NAPT. NAPT would enable the mapping of tuples with the local IP addresses and the local TU port number to tuples with the registered IP address and assigned TU port number.

This model fits the requirements of most SOHO groups to access external networks using a single service-provider-assigned IP address. This model could be extended to enable inbound access by statically mapping a local node per each service TU port of the registered IP address.

In the example of Figure 8-21, stub A uses class A address block 10.0.0.0/8 internally. The stub router's WAN interface is assigned IP address 138.76.28.4 by the service provider.

click to expand
Figure 8-21: Network address port translation (NAPT) operation

When stub A host 10.0.0.10 sends a telnet packet to host 138.76.29.7, it uses the globally unique address 138.76.29.7 as the destination and sends the packet to its primary router. The stub router has a static route for the subnet 138.76.0.0/16 so the packet is forwarded to the WAN link. However, NAPT translates the tuple of source address 10.0.0.10 and source TCP port 3017 in the IP and TCP headers into the globally unique 138.76.28.4 and a uniquely assigned TCP port, such as 1024, before the packet is forwarded. Packets on the return path go through similar address and TCP port translations for the target IP address and target TCP port. Once again, notice that this requires no changes to hosts or routers. The translation is completely transparent.

In this setup, only TCP/UDP sessions are allowed and must originate from the local network. However, services such as DNS demand inbound access.

There may be other services for which an organization enables inbound session access. It is possible to statically configure a well-known TU port service^[5] on the stub router to be directed to a specific node in the private network.

In addition to TCP/UDP sessions, ICMP messages, with the exception of the REDIRECT message type, may also be monitored by a NAPT router. ICMP-query-type packets are translated similar to that of TCP/UDP packets, in that the identifier field in ICMP message header will be uniquely mapped to a query identifier of the registered IP address. The identifier field in ICMP query messages is set by the query sender and returned unchanged in the response message from the query responder. So, the tuple of the local IP address and the local ICMP query identifier is mapped to a tuple of the registered IP address and the assigned ICMP query identifier by the NAPT router to uniquely identify ICMP queries of all types from any of the local hosts. Modifications to ICMP error messages are discussed in a later section, as that involves modifications to the ICMP payload as well as the IP and ICMP headers.

In NAPT setup, where the registered IP address is the same as the IP address of the stub router WAN interface, the router has to be sure to make a distinction between TCP, UDP, or ICMP query sessions originated from itself versus those originated from the nodes on the local network. The end node of the inbound sessions (including TCP, UDP, and ICMP query sessions) is assumed to be the NAT router, unless the target service port is statically mapped to a different node on the local network. Sessions other than the TCP, UDP, and ICMP query types are simply not permitted from local nodes serviced by a NAPT router.

Translation Phases of a Session

The translation phases with traditional NAT are the same as those described in Srisuresh and Holdrege's 'RFC 2663: IP Network Address Translator (NAT) Terminology and Considerations.'^[3] The following subsections identify items that are specific to traditional NAT.

Address binding With Basic NAT, a private address is bound to an external address when the first outgoing session is initiated from the private host. Subsequent to that, all other outgoing sessions originating from the same private address will use the same address binding for packet translation.

In the case of NAPT, where many private addresses are mapped to a single globally unique address, the binding would be from the tuple of the private address and the private TU port to the tuple of the assigned address and the assigned TU port. As with Basic NAT, this binding is determined when the first outgoing session is initiated by the tuple of the private address and the private TU port on the private host. Although not a common practice, it is possible to have an application on a private host establish multiple simultaneous sessions originating from the same tuple of the private address and the private TU port. In such a case, a single binding for the tuple of the private address and the private TU port may be used for the translation of packets pertaining to all sessions originating from the same tuple on a host.

Address Lookup and Translation After an address binding or an address and TU port tuple binding in case NAPT is established, a soft state may be maintained for each of the connections using the binding. Packets belonging to the same session will be subject to session lookup for translation purposes.

Address Unbinding When the last session based on an address, or an address and TU port tuple binding, is terminated, the binding itself may be terminated.

Packet Translations

Packets pertaining to NAT-managed sessions undergo translation in either direction. Individual packet translation issues are covered in detail in the following subsections.

IP, TCP, UDP, and ICMP Header Manipulations In the Basic NAT model, the IP header of every packet must be modified. This modification includes the IP address (the source IP address for outbound packets and the destination IP address for inbound packets) and the IP checksum.

For TCP^[6] and UDP^[7] sessions, modifications must include updating the checksum in the TCP/UDP headers. This is because the TCP/UDP checksum also covers a pseudoheader containing the source and destination IP addresses. As an exception, UDP headers with a 0 checksum should not be modified. As for ICMP query packets,^[8] no further changes in the ICMP header are required since the checksum in the ICMP header does not cover IP addresses.

In the NAPT model, modifications to the IP header are similar to that of Basic NAT. For TCP/UDP sessions, modifications must be extended to include the translation of the TU port (the source TU port for outbound packets and the destination TU port for inbound packets) in the TCP/UDP header. The ICMP header in ICMP query packets must also be modified to replace the query ID and ICMP header checksum. The private host query ID must be translated into an assigned ID on the outbound packet and the exact reverse on the inbound packet. The ICMP header checksum must be corrected to account for query ID translation.

Checksum Adjustment NAT modifications are per-packet-based and can be very computation intensive, as they involve one or more checksum modifications in addition to simple field translations. Luckily, we have an algorithm that makes checksum adjustments to IP, TCP, UDP, and ICMP headers very simple and efficient. Since all these headers use a one's complement sum, it is sufficient to calculate the arithmetic difference between the before-translation and after-translation addresses and add this to the checksum. The following algorithm is applicable only for even offsets (optr must be at an even offset from the start of the header) and even lengths (olen and nlen below must be even).

ICMP Error Packet Modifications Changes to the ICMP error message^[8] will include changes to IP and ICMP headers on the outer layer as well as changes to headers of the packet embedded within the ICMP error message payload.

In order for NAT to be transparent to the end host, the IP address of the IP header embedded within the payload of the ICMP error message must be modified, the checksum field of the embedded IP header must be modified, and lastly the ICMP header checksum must also be modified to reflect changes to the payload.

In a NAPT setup, if the IP message embedded within ICMP happens to be a TCP, UDP, or ICMP query packet, you will also need to modify the appropriate TU port number within the TCP/UDP header or the Query Identifier field in the ICMP query header. Lastly, the IP header of the ICMP packet must also be modified.

FTP Support One of the most popular applications, FTP, requires an ALG to monitor the control session payload to determine the ensuing data session parameters. FTP ALG is an integral part of most NAT implementations.

The FTP ALG would require a special table to correct the TCP sequence and acknowledge numbers with source port FTP or destination port FTP. The table entries should have a source address, destination address, source port, destination port, a delta for sequence numbers, and a timestamp. New entries are created only when FTP PORT commands or PASV responses are seen. The sequence number delta may be increased or decreased for every FTP PORT command or passive (PASV) response. Sequence numbers are incremented on the outbound, and acknowledge numbers are decremented on the inbound by this delta.

FTP payload translations are limited to private addresses and their assigned external addresses (encoded as individual octets in ASCII) for Basic NAT. For NAPT setup, however, the translations must be extended to include the TCP port octets (in ASCII) following the address octets.

DNS Support Considering that sessions in a traditional NAT are predominantly outbound from a private domain, DNS ALG may be obviated from use in conjunction with traditional NAT as follows. A DNS server(s) internal to the private domain maintains the mapping of names to IP addresses for internal hosts and possibly some external hosts. External DNS servers maintain name mapping for external hosts alone and not for any of the internal hosts. If the private network does not have an internal DNS server, all DNS requests may be directed to an external DNS server to find address mapping for the external hosts.

IP Option Handling An IP datagram with any of the IP options Record Route, Strict Source Route, or Loose Source Route would involve recording or using IP addresses of intermediate routers. A NAT intermediate router may choose not to support these options or leave the addresses untranslated while processing the options. The result of leaving the addresses untranslated would be that private addresses along the source route are exposed end to end. This should not jeopardize the traversal path of the packet per se, as each router is supposed to look at the next hop router only.

Miscellaneous Issues

This section looks at a number of issues related to NAT.

Partitioning of Local and Global Addresses For NAT to operate as described in this chapter, it is necessary to partition the IP address space into two parts: the private addresses used internal to the stub domain, and the globally unique addresses. Any given address must either be a private address or a global address. There is no overlap.

The problem with overlap is the following. Let's say a host in stub A wants to send packets to a host in stub B, but the global addresses of stub B overlap with the private addresses of stub A. In this case, the routers in stub A would not be able to distinguish the global addresses of stub B from its own private addresses.

Private Address Space Recommendation RFC 1918, 'Address Allocation for Private Internets,' contains recommendations on address space allocation for private networks.^[4] IANA has three blocks of IP address space, namely 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 for private internets. In pre-Classless Interdomain Routing (CIDR) notation, the first block is nothing but a single class A network number, while the second block is a set of 16 contiguous class B networks, and the third block is a set of 256 contiguous class C networks.

An organization that decides to use IP addresses in the address space defined previously can do so without any coordination with IANA or an Internet registry. The address space can thus be used privately by many independent organizations at the same time, with NAT operation enabled on their border routers.

Routing across NAT The router running NAT should not advertise the private networks to the backbone. Only the networks with global addresses may be known outside the stub. However, global information that NAT receives from the stub border router can be advertised in the stub the usual way.

Typically, the NAT stub router will have a static route configured to forward all external traffic to the service provider router over a WAN link, and the service provider router will have a static route configured to forward NAT packets (those whose destination IP addresses fall within the range of the NAT-managed global address list) to the NAT router over a WAN link.

Switch-over from Basic NAT to NAPT In Basic NAT setup, when private network nodes outnumber global addresses available for mapping (say, a class B private network mapped to a class C global address block), external network access to some of the local nodes is abruptly cut off after the last global address from the address list is used up. This is very inconvenient and constraining. Such an incident can be safely avoided by optionally allowing the Basic NAT router to switch over to NAPT setup for the last global address in the address list. Doing this will ensure that hosts on the private network will have continued, uninterrupted access to the external nodes and services for most applications. Note, however, that it could be confusing if some of the applications that used to work with Basic NAT suddenly break due to the switchover to NAPT.^[9]

^[4]A method of increasing the transmission distance of a radio by the concentration of its signal in a single direction, typically through the use of a directional antenna. Gain does not increase the signal strength of a radio, but simply redirects it. Therefore, as gain increases, the decrease in angle of coverage is inversely proportional.

^[1]An antenna that concentrates transmission power into a direction that increases coverage distance at the expense of coverage angle. Directional antenna types include yagi, patch, and parabolic dish antennas. A yagi is a type of cylindrical directional antenna. A patch antenna is a type of flat antenna designed for flush wall mounting that radiates a hemispherical coverage area. A parabolic dish antenna is a concave or dish-shaped object, often refers to dish antennas. Parabolic dish antennas tend to provide the greatest gain and the narrowest beam width making them ideal for point-to-point transmission over the longest distances.

^[2]An antenna that provides a 360-degree transmission pattern. These types of antennas are used when coverage in all directions is required.

^[3]A linear measure of the distance that a transmitter can send a signal.

^[5]A type of low-gain (2.2 dBi) antenna consisting of two (often internal) elements.

^[3]A linear measure of the distance that a transmitter can send a signal.

^[6]An intelligent system of two antennas that continually senses incoming radio signals and automatically selects the antenna best positioned to receive it.

^[7]A ratio of decibels to an isotropic antenna that is commonly used to measure antenna gain. The greater the dBi value, the higher the gain, and therefore, the more acute the angle of coverage.

^[8]All range estimations are based on an integrated client adapter antenna associating with an AP under ideal indoor conditions. The distances referenced here are approximations and should be used for estimation purposes only.

^[9]All range estimations are based on an integrated client adapter antenna associating with an AP under ideal indoor conditions. The distances referenced here are approximations and should be used for estimation purposes only.