Network Working Group                                       P. SrisureshRequest for Comments: 2663                                   M. HoldregeCategory: Informational                              Lucent Technologies                                                             August 1999    IP Network Address Translator (NAT) Terminology and ConsiderationsStatus of this Memo   This memo provides information for the Internet community.  It does   not specify an Internet standard of any kind.  Distribution of this   memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (1999).  All Rights Reserved.Preface   The motivation behind this document is to provide clarity to the   terms used in conjunction with Network Address Translators.  The term   "Network Address Translator" means different things in different   contexts. The intent of this document is to define the various   flavors of NAT and standardize the meaning of terms used.   The authors listed are editors for this document and owe the content   to contributions from members of the working group. Large chunks of   the document titled, "IP Network Address Translator (NAT)" were   extracted almost as is, to form the initial basis for this document.   The editors would like to thank the authors Pyda Srisuresh and Kjeld   Egevang for the same. The editors would like to thank Praveen   Akkiraju for his contributions in describing NAT deployment   scenarios. The editors would also like to thank the IESG members   Scott Bradner, Vern Paxson and Thomas Narten for their detailed   review of the document and adding clarity to the text.Abstract   Network Address Translation is a method by which IP addresses are   mapped from one realm to another, in an attempt to provide   transparent routing to hosts. Traditionally, NAT devices are used to   connect an isolated address realm with private unregistered addresses   to an external realm with globally unique registered addresses. This   document attempts to describe the operation of NAT devices and the   associated considerations in general, and to define the terminology   used to identify various flavors of NAT.Srisuresh & Holdrege         Informational                      [Page 1]RFC 2663           NAT Terminology and Considerations        August 19991. Introduction and Overview   The need for IP Address translation arises when a network's internal   IP addresses cannot be used outside the network either because they   are invalid for use outside, or because the internal addressing must   be kept private from the external network.   Address translation allows (in many cases, except as noted in   sections 8 and 9) hosts in a private network to transparently   communicate with destinations on an external network and vice versa.   There are a variety of flavors of NAT and terms to match them. This   document attempts to define the terminology used and to identify   various flavors of NAT. The document also attempts to describe other   considerations applicable to NAT devices in general.   Note, however, this document is not intended to describe the   operations of individual NAT variations or the applicability of NAT   devices.   NAT devices attempt to provide a transparent routing solution to end   hosts trying to communicate from disparate address realms. This is   achieved by modifying end node addresses en-route and maintaining   state for these updates so that datagrams pertaining to a session are   routed to the right end-node in either realm. This solution only   works when the applications do not use the IP addresses as part of   the protocol itself. For example, identifying endpoints using DNS   names rather than addresses makes applications less dependent of the   actual addresses that NAT chooses and avoids the need to also   translate payload contents when NAT changes an IP address.   The NAT function cannot by itself support all applications   transparently and often must co-exist with application level gateways   (ALGs) for this reason. People looking to deploy NAT based solutions   need to determine their application requirements first and assess the   NAT extensions (i.e., ALGs) necessary to provide application   transparency for their environment.   IPsec techniques which are intended to preserve the Endpoint   addresses of an IP packet will not work with NAT enroute for most   applications in practice. Techniques such as AH and ESP protect the   contents of the IP headers (including the source and destination   addresses) from modification. Yet, NAT's fundamental role is to alter   the addresses in the IP header of a packet.2. Terminology and concepts used   Terms most frequently used in the context of NAT are defined here for   reference.Srisuresh & Holdrege         Informational                      [Page 2]RFC 2663           NAT Terminology and Considerations        August 19992.1. Address realm or realm   An address realm is a network domain in which the network addresses   are uniquely assigned to entities such that datagrams can be routed   to them. Routing protocols used within the network domain are   responsible for finding routes to entities given their network   addresses. Note that this document is limited to describing NAT in   IPv4 environment and does not address the use of NAT in other types   of environment. (e.g. IPv6 environments)2.2. Transparent routing   The term "transparent routing" is used throughout the document to   identify the routing functionality that a NAT device provides.  This   is different from the routing functionality provided by a traditional   router device in that a traditional router routes packets within a   single address realm.   Transparent routing refers to routing a datagram between disparate   address realms, by modifying address contents in the IP header to be   valid in the address realm into which the datagram is routed.   Section 3.2 has a detailed description of transparent routing.2.3. Session flow vs. Packet flow   Connection or session flows are different from packet flows.  A   session flow  indicates the direction in which the session was   initiated with reference to a network interface. Packet flow is the   direction in which the packet has traveled with reference to a   network interface. Take for example, an outbound telnet session.  The   telnet session consists of packet flows in both inbound and outbound   directions. Outbound telnet packets carry terminal keystrokes and   inbound telnet packets carry screen displays from the telnet server.   For purposes of discussion in this document, a session is defined as   the set of traffic that is managed as a unit for translation.   TCP/UDP sessions are uniquely identified by the tuple of (source IP   address, source TCP/UDP port, target IP address, target TCP/UDP   port). ICMP query sessions are identified by the tuple of (source IP   address, ICMP query ID, target IP address). All other sessions are   characterized by the tuple of (source IP address, target IP address,   IP protocol).   Address translations performed by NAT are session based and would   include translation of incoming as well as outgoing packets belonging   to that session. Session direction is identified by the direction of   the first packet of that session (see sec 2.5).Srisuresh & Holdrege         Informational                      [Page 3]RFC 2663           NAT Terminology and Considerations        August 1999   Note, there is no guarantee that the idea of a session, determined as   above by NAT, will coincide with the application's idea of a session.   An application might view a bundle of sessions (as viewed by NAT) as   a single session and might not even view its communication with its   peers as a session. Not all applications are guaranteed to work   across realms, even with an ALG (defined below in section 2.9)   enroute.2.4. TU ports, Server ports, Client ports   For the reminder of this document, we will refer TCP/UDP ports   associated with an IP address simply as "TU ports".   For most TCP/IP hosts, TU port range 0-1023 is used by servers   listening for incoming connections. Clients trying to initiate a   connection typically select a source TU port in the range of 1024-   65535. However, this convention is not universal and not always   followed. Some client stations initiate connections using a source TU   port number in the range of 0-1023, and there are servers listening   on TU port numbers in the range of 1024-65535.   A list of assigned TU port services may be found in RFC 1700 [Ref 2].2.5. Start of session for TCP, UDP and others   The first packet of every TCP session tries to establish a session   and contains connection startup information. The first packet of a   TCP session may be recognized by the presence of SYN bit and absence   of ACK bit in the TCP flags. All TCP packets, with the exception of   the first packet, must have the ACK bit set.   However, there is no deterministic way of recognizing the start of a   UDP based session or any non-TCP session. A heuristic approach would   be to assume the first packet with hitherto non-existent session   parameters (as defined in section 2.3) as constituting the start of   new session.2.6. End of session for TCP, UDP and others   The end of a TCP session is detected when FIN is acknowledged by both   halves of the session or when either half receives a segment with the   RST bit in TCP flags field. However, because it is impossible for a   NAT device to know whether the packets it sees will actually be   delivered to the destination (they may be dropped between the NAT   device and the destination), the NAT device cannot safely assume that   the segments containing FINs or SYNs will be the last packets of the   session (i.e., there could be retransmissions).  Consequently, a   session can be assumed to have been terminated only after a period ofSrisuresh & Holdrege         Informational                      [Page 4]RFC 2663           NAT Terminology and Considerations        August 1999   4 minutes subsequent to this detection. The need for this extended   wait period is described in RFC 793 [Ref 7], which suggests a TIME-   WAIT duration of 2 * MSL (Maximum Segment Lifetime) or 4 minutes.   Note that it is also possible for a TCP connection to terminate   without the NAT device becoming aware of the event (e.g., in the case   where one or both peers reboot). Consequently, garbage collection is   necessary on NAT devices to clean up unused state about TCP sessions   that no longer exist. However, it is not possible in the general case   to distinguish between connections that have been idle for an   extended period of time from those that no longer exist.  In the case   of UDP-based sessions, there is no single way to determine when a   session ends, since UDP-based protocols are application specific.   Many heuristic approaches are used to terminate sessions. You can   make the assumption that TCP sessions that have not been used for   say, 24 hours, and non-TCP sessions that have not been used for a   couple of minutes, are terminated. Often this assumption works, but   sometimes it doesn't. These idle period session timeouts vary a great   deal both from application to application and for different sessions   of the same application. Consequently, session timeouts must be   configurable. Even so, there is no guarantee that a satisfactory   value can be found. Further, as stated in section 2.3, there is no   guarantee that NAT's view of session termination will coincide with   that of the application.   Another way to handle session terminations is to timestamp entries   and keep them as long as possible and retire the longest idle session   when it becomes necessary.2.7. Public/Global/External network   A Global or Public Network is an address realm with unique network   addresses assigned by Internet Assigned Numbers Authority (IANA) or   an equivalent address registry. This network is also referred as   External network during NAT discussions.2.8. Private/Local network   A private network is an address realm independent of external network   addresses. Private network may also be referred alternately as Local   Network. Transparent routing between hosts in private realm and   external realm is facilitated by a NAT router.   RFC 1918 [Ref 1] has recommendations on address space allocation for   private networks. Internet Assigned Numbers Authority (IANA) has   three blocks of IP address space, namely 10/8, 172.16/12, and   192.168/16 set aside for private internets. In pre-CIDR notation, theSrisuresh & Holdrege         Informational                      [Page 5]RFC 2663           NAT Terminology and Considerations        August 1999   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 above can do so without coordination with IANA or any other   Internet registry such as APNIC, RIPE and ARIN.  The address space   can thus be used privately by many independent organizations at the   same time. However, if those independent organizations later decide   they wish to communicate with each other or the public Internet, they   will either have to renumber their networks or enable NAT on their