NAT is essentially a mechanism for allowing the same sets of IP addresses to be reused in different parts of the Internet. The primary motivation for the creation of NAT was the limited and diminishing availability of IP address space. The most common use case for a NAT is when a site with a single Internet connection is assigned a small range of IP addresses (perhaps only a single address), but there are multiple computers requiring Internet access. When all incoming and outgo- ing traffic passes through a single NAT device that partitions the inside (private) address realm from the global Internet address realm, all the internal systems can be provided Internet connectivity as clients using locally assigned, private IP addresses. Allowing privately addressed systems to offer services on the Internet, however, is somewhat more complicated. We discuss this case in Section 7.3.4.
NAT was introduced to solve two problems: address depletion and con- cerns regarding the scalability of routing. At the time of its introduction (early 1990s), NAT was suggested as a stopgap, temporary measure to be used until the deployment of some protocol with a larger number of addresses (ultimately, IPv6) became widespread. Routing scalability was being tackled with the development of Classless Inter-Domain Routing (CIDR; see Chapter 2). NAT is popular because it reduces the need for globally routable Internet addresses but also because it offers some degree of natural firewall capability and requires little configuration.
Perhaps ironically, the development and eventual widespread use of NAT has con- tributed to significantly slow the adoption of IPv6. Among its other benefits, IPv6 was intended to make NAT unnecessary [RFC4864].
Despite its popularity, NAT has several drawbacks. The most obvious is that offering Internet-accessible services from the private side of a NAT requires spe- cial configuration because privately addressed systems are not directly reach- able from the Internet. In addition, for a NAT to work properly, every packet in both directions of a connection or association must pass through the same NAT.
This is because the NAT must actively rewrite the addressing information in each packet in order for communication between a privately addressed system and a conventionally addressed Internet host to work. In many ways, NATs run counter to a fundamental tenet of the Internet protocols: the “smart edge” and “dumb middle.” To do their job, NATs require connection state on a per-association (or
ptg999 per-connection) basis and must operate across multiple protocol layers, unlike con-
ventional routers. Modifying an address at the IP layer also requires modifying checksums at the transport layer (see Chapters 10 and 13 regarding the pseudo- header checksum to see why).
NAT poses problems for some application protocols, especially those that send IP addressing information inside the application-layer payload. The File Transfer Protocol (FTP) [RFC0959] and SIP [RFC5411] are among the best-known protocols of this type. They require a special application-layer gateway function that rewrites the application content in order to work unmodified with NAT or other NAT traversal methods that allow the applications to determine how to work with the specific NAT they are using. A more complete list of considerations regarding NAT appears in [RFC3027]. Despite their numerous problems, NATs are very widely used, and most network routers (including essentially all low-end home routers) support it. Today, NATs are so prevalent that application designers are encouraged to make their applications “NAT-friendly” [RFC3235]. It is worth mentioning that despite its shortcomings, NAT supports the basic protocols (e.g., e-mail, Web browsing) that are needed by millions of client systems accessing the Internet every day.
A NAT works by rewriting the identifying information in packets transit- ing through a router. Most commonly this happens for two directions of a data transfer. In its most basic form, NAT involves rewriting the source IP address of packets as they are forwarded in one direction and the destination IP addresses of packets traveling in the reverse direction (see Figure 7-3). This allows the source IP address in outgoing packets to become one of the NAT router’s Internet-facing interfaces instead of the originating host’s. Thus, to a host on the Internet, packets coming from any of the hosts on the privately addressed side of the NAT appear to be coming from a globally routable IP address of the NAT router.
,QWHUQHW
3 XEOLF,3$GGUHVV
$VVLJQHGE\,6 3
3 XEOLF,3$GGUHVVLQJ5HDOP ,QWHUQHW
3 ULYDWH,3$GGUHVVLQJ5HDOP +RPH( QWHUSULVH
1$7
+RVW´6HHVv 2QO\3 XEOLF ,3$GGUHVVHV
Figure 7-3 A NAT isolates private addresses and the systems using them from the Internet. Packets with private addresses are not routed by the Internet directly but instead must be trans- lated as they enter and leave the private network through the NAT router. Internet hosts see traffic as coming from a public IP address of the NAT.
ptg999 Section 7.3 Network Address Translation (NAT) 305
Most NATs perform both translation and packet filtering, and the packet-filtering criteria depend on the dynamics of the NAT state. The choice of packet-filtering policy may have a different granularity—for example, the treatment of unsolic- ited packets (those not associated with packets originating from behind the NAT) received by the NAT may depend on source and destination IP address and/or source and destination port number. The behavior may vary between NATs or in some cases vary over time through the same NAT. This presents challenges for applications that must operate behind a wide variety of NATs.
7.3.1 Traditional NAT: Basic NAT and NAPT
The precise behavior of a NAT remained unspecified for many years. Nonetheless, a taxonomy of NAT types has emerged, based largely on observing how different implementations of the NAT idea behave. The so-called traditional NAT includes both basic NAT and Network Address Port Translation (NAPT) [RFC3022]. Basic NAT performs rewriting of IP addresses only. In essence, a private address is rewritten to be a public address, often from a pool or range of public addresses supplied by an ISP. This type of NAT is not the most popular because it does not help to dramatically reduce the need for IP addresses—the number of globally routable addresses must equal or exceed the number of internal hosts that wish to access the Internet simultaneously. A much more popular approach, NAPT involves using the transport-layer identifiers (i.e., ports for TCP and UDP, query identifiers for ICMP) to differentiate which host on the private side of the NAT is associated with a particular packet (see Figure 7-4). This allows a large number of internal hosts (i.e., multiple thousands) to access the Internet simultaneously using a lim- ited number of public addresses, often only a single one. We shall ordinarily use the term NAT to include both traditional NAT and NAPT unless the distinction is important in a particular context.
1$7 6UF,3
6UF3RUW
6UF,3 6UF3RUW
6UF,3 6UF3RUW
6UF,3 6UF3RUW
6UF,3 6UF3RUW
6UF,3 6UF3RUW
1$37 6UF,3
6UF3RUW
6UF,3 6UF3RUW
6UF,3 6UF3RUW
6UF,3 6UF3RUW
6UF,3 6UF3RUW
6UF3RUW 6UF,3
Figure 7-4 A basic IPv4 NAT (left) rewrites IP addresses from a pool of addresses and leaves port numbers unchanged. NAPT (right), also known as IP masquerading, usually rewrites address to a single address. NAPT must sometimes rewrite port numbers in order to avoid collisions. In this case, the second instance of port number 23479 was rewritten to use port number 3000 so that returning traffic for 192.168.1.2 could be distinguished from the traffic returning to 192.168.1.35.
ptg999 The addresses used in a private addressing realm “behind” or “inside” a NAT
are not enforced by anyone other than the local network administrator. Thus, it is possible for a private realm to make use of global address space. In principle, this is acceptable. However, when such global addresses are owned and being used by another entity on the Internet, local systems in the private realm would most likely be unable to reach the public systems using the same addresses because the close proximity of the local systems would effectively “mask” the visibility of the farther-away systems using the same addresses. To avoid this undesirable situa- tion, there are three IPv4 address ranges reserved for use with private address- ing realms [RFC1918]: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. These address ranges are often used as default values for address pools in embedded DHCP servers (see Chapter 6).
As suggested earlier, a NAT provides some degree of security similar to that of a firewall. By default, all systems on the private side of the NAT cannot be reached from the Internet. In most NAT deployments, the internal systems use private addresses. Consequently, communications between hosts in the private addressing realm and those in the public realm can be facilitated only with partic- ipation from the NAT, according to its usage policies and behavior. While a large variety of policies may be used in practice, a common policy allows almost all outgoing and returning traffic (associated with outgoing traffic) to pass through the NAT but blocks almost all incoming new connection requests. This behav- ior inhibits “probing” attacks that attempt to ascertain which IP addresses have active hosts available to exploit. In addition, a NAT (especially a NAPT) “hides”
the number and configuration of internal addresses from the outside. Some users feel this topology information is proprietary and should remain confidential. NAT helps by providing so-called topology hiding.
As we shall now explore, NATs are tailored to the protocols and applications that they need to support, so it is difficult to discuss NAT behavior without also mentioning the particular protocol(s) it is being asked to handle. Thus, we now turn to how NAT behaves with each major transport protocol and how it may be used in mixed IPv4/IPv6 environments. Many of the behavioral specifics for NATs have been the subject of the IETF Behavior Engineering for Hindrance Avoidance (BEHAVE) working group. BEHAVE has produced a number of documents, start- ing in 2007, that clarify consistent behaviors for NATs. These documents are useful for application writers and NAT developers so that a consistent expectation can be established as to how NATs should operate.
7.3.1.1 NAT and TCP
Recall from Chapter 1 that the primary transport-layer protocol for the Internet, TCP, uses an IP address and port number to identify each end of a connection. A connection is identified by the combination of two ends; each unique TCP con- nection is identified by two IP addresses and two port numbers. When a TCP connection starts, an “active opener” or client usually sends a synchronization (SYN) packet to a “passive opener” or server. The server responds with its own
ptg999 Section 7.3 Network Address Translation (NAT) 307
SYN packet, which also includes an acknowledgment (ACK) of the client’s SYN.
The client then responds with an ACK to the server. This “three-way handshake”
establishes the connection. A similar exchange with finish (FIN) packets is used to gracefully close a connection. The connection can also be forcefully closed right away using a reset (RST) packet. (See Chapter 13 for more detail on TCP connec- tions.) The behavioral requirements for traditional NAT with TCP are defined in [RFC5382] and relate primarily to the TCP three-way handshake.
Referring to the example home network in Figure 7-3, consider a TCP con- nection initiated by the wireless client at 10.0.0.126 destined for the Web server on the host www.isoc.org (IPv4 address 212.110.167.157). Using the following notation to indicate IPv4 addresses and port numbers—(source IP:source port;
destination IP:destination port)—the packet initiating the connection on the pri- vate segment might be addressed as (10.0.0.126:9200; 212.110.167.157:80). The NAT/
firewall device, acting as the default router for the client, receives the first packet.
The NAT notices that the incoming packet is a new connection (because the SYN bit in the TCP header is turned on; see Chapter 13). If policy permits (which it typically does because this is an outgoing connection), the source IP address is modified in the packet to reflect the routable IP address of the NAT router’s external interface. Thus, when the NAT forwards this packet, the addressing is (63.204.134.177:9200; 212.110.167.157:80). In addition to forwarding the packet, the NAT creates internal state to remember the fact that a new connection is being handled by the NAT (called a NAT session). At a minimum, this state includes an entry (called a NAT mapping) containing the source port number and IP address of the client. This becomes useful when the Internet server replies. The server replies to the endpoint (63.204.134.177:9200), the external NAT address, using the port number chosen initially by the client. This behavior is called port preservation.
By matching the destination port number on the received datagram against the appropriate NAT mapping, the NAT is able to ascertain the internal IP address of the client that made the initial request. In our example, this address is 10.0.0.126, so the NAT rewrites the response packet from (212.110.167.157:80; 63.204.134.177:9200) to (212.110.167.157:80; 10.0.0.126:9200) and forwards it. The client then receives a response to its request and for most purposes is now connected to the server.
This example conveys how a basic NAT session is established in the nor- mal case, but not how the session is cleared. Session state is removed if FINs are exchanged, but not all TCP connections are cleared gracefully. Sometimes a computer is simply turned off, which can leave stale NAT mappings in the NAT’s memory. Thus, a NAT must also remove mappings thought to have “gone dead”
because of a lack of traffic (or if an RST segment indicates some other form of problem).
Most NATs include a simplified version of the TCP connection establishment procedures and can distinguish between connection success and failure. In par- ticular, when an outgoing SYN segment is observed, a connection timer is acti- vated, and if no ACK is seen before the timer expires, the session state is cleared.
If an ACK does arrive, the timer is canceled and a session timer is created, with a
ptg999 considerably longer timeout (e.g., hours instead of minutes). When this happens,
the NAT may send an additional packet to the internal endpoint, just to double- check if the session is indeed dead (called probing). If it receives an ACK, the NAT realizes that the connection is still active, resets the session timer, and does not delete the session. If it receives either no response (after a close timer has expired) or an RST segment, the connection has gone dead, and the state is cleared.
[RFC5382], a product of the BEHAVE working group, notes that a TCP con- nection can be configured to send “keepalive” packets (see Chapter 17), and the default rate is one packet every 2 hours, if enabled. Otherwise, a TCP connection can remain established indefinitely. While a connection is being set up or cleared, however, the maximum idle time is 4 minutes. Consequently, [RFC5382] requires (REQ-5) that a NAT wait at least 2 hours and 4 minutes before concluding that an established connection is dead and at least 4 minutes before concluding that a partially opened or closed connection is dead.
One of the tricky problems for a TCP NAT is handling peer-to-peer applica- tions operating on hosts residing on the private sides of multiple NATs [RFC5128].
Some of these applications use a simultaneous open whereby each end of the con- nection acts as a client and sends SYN packets more or less simultaneously. TCP is able to handle this case by responding with SYN + ACK packets that complete the connection faster than with the three-way handshake, but many existing NATs do not handle it properly. [RFC5382] addresses this by requiring (REQ-2) that a NAT handle all valid TCP packet exchanges, and simultaneous opens in particular.
Some peer-to-peer applications (e.g., network games) use this behavior. In addi- tion, [RFC5382] specifies that an inbound SYN for a connection about which the NAT knows nothing should be silently discarded. This can occur when a simulta- neous open is attempted but the external host’s SYN arrives at the NAT before the internal host’s SYN. Although this may seem unlikely, it can happen as a result of clock skew, for example. If the incoming external SYN is dropped, the internal SYN has time to establish a NAT mapping for the same connection represented by the external SYN. If no internal SYN is forthcoming in 6s, the NAT may signal an error to the external host.
7.3.1.2 NAT and UDP
The NAT behavioral requirements for unicast UDP are defined in [RFC4787].
Most of the same issues arise when performing NAT on a collection of UDP data- grams as arise when performing NAT on TCP. UDP is somewhat different, how- ever, because there are no connection establishment and clearing procedures as there are in TCP. More specifically, there are no indicators such as the SYN, FIN, and RST bits to indicate that a session is being created or destroyed. Furthermore, the participants in an association may not be completely clear. UDP does not use a 4-tuple to identify a connection like TCP; instead, it can rely on only the two endpoint address/port number combinations. To handle these issues, UDP NATs use a mapping timer to clear NAT state if a binding has not been used “recently.”
There is considerable variation in the values used for this timer to determine what
ptg999 Section 7.3 Network Address Translation (NAT) 309
“recently” means, but [RFC4787] requires the timer to be at least 2 minutes and rec- ommends that it be 5 minutes. A related consideration is when the timer should be considered refreshed. Timers can be refreshed when packets travel from the inside to the outside of the NAT (NAT outbound refresh behavior) or vice versa (NAT inbound refresh behavior). [RFC4787] requires NAT outbound refresh behavior to be true. Inbound behavior may or may not be true.
As we discussed in Chapter 5 (and will see again in Chapter 10), UDP and IP packets can be fragmented. Fragmentation allows for a single IP packet to span multiple chunks (fragments), each of which is treated as an independent data- gram. However, because of the layering of UDP above IP, an IP fragment other than the first one does not contain the port number information needed by NAPT to operate properly. This also applies to TCP and ICMP. Thus, in general, frag- ments cannot be handled properly by simple NATs or NAPTs.
7.3.1.3 NAT and Other Transport Protocols (DCCP, SCTP)
Although TCP and UDP are by far the most widely used Internet transport pro- tocols, there are two other protocols for which NAT behaviors have been defined or are being defined. The Datagram Congestion Control Protocol (DCCP) [RFC4340]
provides a congestion-controlled datagram service. [RFC5597] gives NAT behav- ioral requirements with respect to DCCP, and [RFC5596] gives a modification to DCCP to support a TCP-like simultaneous open procedure for use with DCCP. The Stream Control Transmission Protocol (SCTP) [RFC4960] provides a reliable messag- ing service that can accommodate hosts with multiple addresses. Considerations for NAT with SCTP are given in [HBA09] and [IDSNAT].
7.3.1.4 NAT and ICMP
ICMP, the Internet Control Message Protocol, is detailed in Chapter 8. It provides status information about IP packets and can also be used for making certain mea- surements and gathering information about the state of the network. The NAT behavioral requirements for ICMP are defined in [RFC5508]. There are two issues involved when NAT is used for ICMP. ICMP has two categories of messages: infor- mational and error. Error messages generally contain a (partial or full) copy of the IP packet that induced the error condition. They are sent from the point where an error was detected, often in the middle of the network, to the original sender.
Ordinarily, this presents no difficulty, but when an ICMP error message passes through a NAT, the IP addresses in the included “offending datagram” need to be rewritten by the NAT in order for them to make sense to the end client (called ICMP fix-up). For informational messages, the same issues arise, but in this case most message types are of a query/response or client/server nature and include a Query ID field that is handled much like port numbers for TCP or UDP. Thus, a NAT handling these types of messages can recognize outgoing informational requests and set a timer in anticipation of a returning response.