[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 rfc2663                                           
NAT Working Group                                           P. Srisuresh
INTERNET-DRAFT                                       Lucent Technologies
Category: Informational                                    Matt Holdrege
Expire in six months                               Ascend Communications
                                                               July 1998

   IP Network Address Translator (NAT) Terminology and Considerations

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups. Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   To view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).


   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 draft, 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 ADs, Scott Bradner and Vern Paxson, for their detailed review

Srisuresh & Holdrege                                            [Page 1]

Internet Draft     NAT Terminology and Considerations          July 1998

   of the document.


   Network Address Translation is a method by which IP addresses are
   mapped from one realm to another, providing transparent routing to
   users. Traditionally, NATs are used to connect an isolated routing
   realm with private unregistered addresses to an external routing
   realm with globally unique registered addresses. This document
   attempts to describe the operation of NATs in general and to
   define the terminology used to identify various flavors of NAT.

1. Introduction and Overview

   The need for IP Address translation arises when a network's internal
   IP addresses cannot be used outside the network either for security
   reasons or because they are invalid for use outside the network.

   Address translation would allow hosts in a private network to
   transparently access 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 NATs in general.

   Note, however, this document is not intended to describe the
   operations of individual NAT variations or the applicability
   of NATs.

   NATs provide transparent routing solution to end hosts trying to
   communicate from disparate routing realms. This transparent routing
   is achieved by modifying end node addresses en-route and
   maintaining state for these updates so that datagrams pertaining
   to a session are transparently routed to the right end-node in
   either realm. This solution works best when the end user identifier
   (such as host name) is different from the address used to locate
   the end user. IPsec techniques which are intended to guarantee the
   end-to-end security of an IP packet cannot be assumed to transit NAT.
   Techniques such as AH and ESP secure IP header address contents of
   the end host packets. Yet, NAT's fundamental role is to alter the
   addresses in the IP header of a packet.

   NATs cannot by themselves 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

Srisuresh & Holdrege                                            [Page 2]

Internet Draft     NAT Terminology and Considerations          July 1998

   transparency for their environment.

2. Terminology and concepts used

2.1. NAT terminology

   Terms most frequently used in the context of NATs are defined here
   for reference.

2.1.1. 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, packets belonging to a
   TCP/UDP  session 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.1.3).

2.1.2. 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 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 TU port number
   in the range of 0-1023, and there are servers  listening on TU
   port numbers in the range of 1024-65535.

Srisuresh & Holdrege                                            [Page 3]

Internet Draft     NAT Terminology and Considerations          July 1998

   A list of assigned TU port services may be found in [Ref 2].

2.1.3. 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.

2.1.4. 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 sets RST bit in
   TCP flags field. Within a short period (say, a couple of seconds)
   after one of the session partners sets RST bit, the session can
   be safely assumed to have been terminated. However, it is
   possible to have TCP sessions hung forever. As for non-TCP
   sessions, there is no deterministic way of identifying session
   end unless you know the application protocol.

   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
   say, 1 minute, are terminated. Often this assumption works, but
   sometimes it doesn't. These idle period session timeouts may vary
   considerably across the board and may be made user configurable.

   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.1.5. Routing realm

   A routing 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. Although NATs may be used with IPv6, this document is
   limited to describing NATs in a IPv4 environment.

2.1.6. Private/Local network

   A private network is a routing realm that connects to an external
   network by means of a NAT device. Private network may also be

Srisuresh & Holdrege                                            [Page 4]

Internet Draft     NAT Terminology and Considerations          July 1998

   referred to as Local Network.

   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,
   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 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, with NAT enabled on their
   border routers.

2.1.7. Public/Global/External network

   A Global or Public Network is a routing realm with unique network
   addresses assigned by Internet Assigned Numbers Authority (IANA)
   or an equivalent address registry.

2.1.8. Application Level gateway (ALG)

   Not all applications lend themselves easily to translation by NATs;
   especially those that include IP addresses and TCP/UDP ports in the
   payload. Application Level Gateways (ALGs) are application specific
   translation agents that allow an application on a host in one
   routing realm to connect to its counterpart running on a host in
   different realm. An ALG may interact with NAT to set up state,
   use NAT state information, modify application specific payload and
   perform whatever else is required to get the application running
   across disparate routing realms.

   ALGs may not always utilize NAT state information. They may glean
   application payload and simply notify NAT to add additional state
   information in some cases. ALGs are similar to Proxies, in that,
   both ALGs and proxies facilitate Application specific
   communication between clients and servers. Just as with proxies,
   ALGs could be transparent as well as non-transparent. Proxies
   relay client data to servers and vice versa, by using a special
   protocol to communicate with proxy clients. Unlike Proxies, ALGs
   do not use a special protocol to communicate with application
   clients and do not require changes to application clients.

3. What is NAT?

Srisuresh & Holdrege                                            [Page 5]

Internet Draft     NAT Terminology and Considerations          July 1998

   Network Address Translation is a method by which IP addresses are
   mapped from one routing realm to another, providing transparent
   routing to end hosts. There are many variations of address
   translation that lend themselves to different applications. However,
   all flavors of NATs should share the following characteristics.

          a) Transparent Address assignment.
          b) Transparent routing through address translation.
             (routing here refers to forwarding packets, and not
             exchanging routing information)
          c) ICMP error packet payload translation.

   Below is a diagram illustrating a scenario in which NAT is enabled
   on a stub domain border router, connected to the Internet through a
   regional router made available by a service provider.

        \ | /                 .                                /
   +---------------+  WAN     .           +-----------------+/
   |Regional Router|----------------------|Stub Router w/NAT|---
   +---------------+          .           +-----------------+\
                              .                      |         \
                              .                      |  LAN
                              .               ---------------
                        Stub border

        Figure 1: A typical NAT operation scenario

3.1. Transparent Address Assignment

   NAT binds addresses in private network with addresses in global
   network and vice versa to provide transparent routing for
   the datagrams traversing between routing realms. The binding in some
   cases may extend to transport level identifiers (such as TCP/UDP
   ports). Address binding is done at the start of a session. The
   following sub-sections describe two types of address assignments.

3.1.1. Static Address assignment

   In the case of static address assignment, there is one-to-one
   address mapping for hosts between a private network address and
   an external network address for the lifetime of NAT operation.
   Static address assignment ensures that NAT does not have to
   administer address management with session flows.

3.1.2. Dynamic Address assignment

Srisuresh & Holdrege                                            [Page 6]

Internet Draft     NAT Terminology and Considerations          July 1998

   In this case, external addresses are assigned to private network
   hosts or vice versa, dynamically based on usage requirements and
   session flow detected by NAT. When the last session using an address
   binding is terminated, NAT would free the binding so that the global
   address could be recycled for later use. The exact nature of address
   assignment is specific to individual NAT implementations.

3.2. Transparent routing

   NATs translate addresses in IP header to contain routable addresses,
   so that each routing realm can use routing protocols appropriate to
   the realm to route datagrams.  NATs should be careful to not
   advertise networks in a routing realm, where such an advertisement
   would be deemed unacceptable.

   There are three phases to Address translation, as follows. Together
   these phases result in creation, maintenance and terminations of
   soft state for sessions passing through NATs.

3.2.1. Address binding:

   Address binding is the phase in which a local node IP address is
   associated with an external address or vice versa, for purposes of
   translation. Address binding is fixed with static address
   assignments and dynamic at session startup time with dynamic
   address assignments. Once the binding between two addresses is in
   place, all subsequent sessions originating from or to this host
   will use the same binding for session based packet translation.

   New address bindings are made at the start of a new session, if
   such an address bind didn't already exist. Once a local address is
   bound to an external address, all subsequent sessions originating
   from the same local address or directed to the same local address
   will use the same binding.

   Start of each new session will result in the creation of a state
   to facilitate translation of datagrams pertaining to the session.
   There can be many simultaneous sessions originating from the same
   host, based on a single address binding.

3.2.2. Address lookup and translation:

   Once a state is established for a session, all packets belonging
   to the session will be subject to address lookup (and transport
   identifier lookup, in some cases) and translation.

   Address or transport identifier translation for a datagram will
   result in the datagram forwarding from the origin routing realm

Srisuresh & Holdrege                                            [Page 7]

Internet Draft     NAT Terminology and Considerations          July 1998

   to the destination routing realm with network addresses
   appropriately updated.

3.2.3. Address unbinding:

   Address unbinding is the phase in which a private address is no
   longer associated with a global address for purposes of
   translation. When the last session using an address bind is
   terminated, it is safe to do the address unbinding. Refer section
   2.1 for some heuristic ways to handle session terminations.

3.3. ICMP error packet translation

   All ICMP error messages (with the exception of Redirect message
   type) will need to be modified, when passed through NAT. The ICMP
   error message types needing NAT modification would include
   Destination-Unreachable, Source-Quench, Time-Exceeded and
   Parameter-Problem.  NAT should not attempt to modify a Redirect
   message type.

   Changes to ICMP error message will include changes to the
   original IP packet (or portions thereof) embedded in the payload
   of the ICMP error message. In order for NAT to be completely
   transparent to end hosts, the IP address of the IP header embedded
   in the payload of the ICMP packet must be modified, the checksum
   field of the same IP header must correspondingly be modified, and
   the accompanying transport header. The ICMP header checksum must
   also be modified to reflect changes made to the IP and transport
   headers in the payload. Furthermore, the normal IP header must
   also be modified.

4.0. Various flavors of NAT

   There are many variations of address translation that lend
   themselves to different applications. The following list of NAT
   flavors are by no means exhaustive, but they do capture the
   significant differences that abound.

4.1. Traditional NAT

   Traditional NAT would allow hosts within a private network to
   transparently access hosts in the external network.  In a
   traditional NAT, sessions are uni-directional, outbound from
   the private network. Sessions in the opposite direction may be
   allowed on an exceptional basis using static address maps for
   pre-selected hosts.

Srisuresh & Holdrege                                            [Page 8]

Internet Draft     NAT Terminology and Considerations          July 1998

   In this setup, network address of hosts in external network
   are unique and valid in external as well as private networks.
   However, network address of hosts in private network are unique
   only within the private network. In other words, NAT would not
   be allowed to advertise private networks to the external realm.
   But, networks from the external realm may be advertised within
   the private network. The addresses used within private network
   must not overlap with the external addresses. Any given address
   must either be a private address or an external address; not

   Traditional NAT is primarily used to connect to the Internet sites
   which are RFC1918 addressed or sites with addresses that have
   private enterprise significance. This is also used to avoid address
   renumbering when changing service providers, even as the addressing
   within the private network is IANA assigned.

   There are two variations to traditional NAT, namely Basic NAT and
   NAPT (Network Address Port Translation). These are discussed in the
   following sub-sections.

4.1.1. Basic NAT

   With Basic NAT, a block of external addresses are set aside for
   translating addresses of hosts in a private domain as they originate
   sessions to the external domain. For packets outbound from the
   private network, the source IP address and related fields such as
   IP, TCP, UDP and ICMP header checksums are translated. For inbound
   packets, the destination IP address and the checksums as listed
   above are translated.

4.1.2. Network Address Port Translation (NAPT)

   With NAPT, a single external address is set aside for translating
   sessions originated by hosts in a private domain. This is made
   possible by multiplexing transport level identifiers of multiple
   private hosts simultaneously into the transport identifiers of
   a single assigned external address. For this reason, only the
   applications supported by transport protocols TCP and UDP are
   supported by NAPT. TCP and UDP protocols contain source and
   destination port numbers. ICMP query based applications are also
   supported as the queries contain a Query Identifier used to
   corelate responses with requests.

   For packets outbound from the private network, NAPT would translate
   the source IP address, source transport identifier and related
   fields such as IP, TCP, UDP and ICMP header checksums. Transport
   identifier can be one of TCP/UDP port or ICMP query ID. For inbound

Srisuresh & Holdrege                                            [Page 9]

Internet Draft     NAT Terminology and Considerations          July 1998

   packets, the destination IP address, destination transport
   identifier and the IP and transport header checksums are

4.2. Two-Way NAT or Bi-directional NAT

   With a Bi-directional NAT, sessions can be initiated from hosts in
   the public network as well as the private network. Private network
   addresses are bound to globally unique addresses, statically or
   dynamically as connections are established in either direction.
   The name space (i.e., their Fully Qualified Domain Names) between
   hosts in private and external networks is assumed to be unique.

   The address space requirements outlined for traditional NATs are
   applicable here as well.

4.3. Twice NAT

   Twice NAT is a variation of NAT in that both the source and
   destination addresses are modified by NAT as a datagram crosses
   routing realms. Typically, twice NAT would be deployed on an
   interface that attempts to "address isolate" private space from
   the public Internet.

   In this setup, the network address of hosts in external network are
   unique in external networks, but not within private network.
   Likewise, the network address of hosts in private network are
   unique only within the private network. In other words, the address
   space used in private network to locate hosts in private and public
   networks is unrelated to the address space used in public network
   to locate hosts in private and public networks.  Twice NAT would
   not be allowed to advertise local networks to the external network
   or vice versa.

   Sessions are allowed to be initiated from hosts in private network
   to hosts in public network or vice versa. The name space (i.e.,
   Fully Qualified Domain Names) between hosts in private and external
   networks is assumed to be unique.

   Twice NAT is typically used when address space used in a Private
   network overlaps with addresses used in the Public space.
   For example, say a private site uses the address
   space which is officially assigned to another site in the public
   internet. Host_A ( in Private space seeks to connect
   to Host_X ( in Public space. In order to make this
   connection work, Host_X's address is mapped to a different address
   for Host_A and vice versa. The twice NAT located at the Private site
   border may be configured as follows :

Srisuresh & Holdrege                                           [Page 10]

Internet Draft     NAT Terminology and Considerations          July 1998

       Private to Public : ->
       Public to Private : ->

       Datagram flow  : Host_A(Private) ->  Host_X(Public)

       a) Within private network

          DA:      SA:

       b) After twice-NAT translation

         DA:    SA:

       Datagram flow Host_X (Public) -> Host_A (Private)

       a) Within Public network

          DA:       SA:

       b) After twice-NAT translation, in private network

          SA:     DA:

4.4. Multihomed NAT

   There are limitations to using NAT. For example, requests and
   responses pertaining to a session must be routed via the same
   NAT router, as a NAT router maintains state information for
   sessions established through it. For this reason, it is often
   suggested that NATs be operated on a border router unique to a
   stub domain, where all IP packets are either originated from the
   domain or destined to the domain. However, such a configuration
   would turn a NAT box into a single point of failure.

   In order for a private network to ensure that connectivity with
   external networks is retained even as one of the NAT links fail,
   it is often desirable to multihome the private network to same
   or multiple service providers with multiple connections from the
   private domain, be it from same or different NAT boxes.

   For example, a private network could have links to two different
   providers and the sessions from private hosts could flow through
   the NAT router with the best metric for a destination. When one
   of NATs fail, the other could route traffic for all connections.

   Multiple NAT boxes or multiple links on the same NAT box, sharing

Srisuresh & Holdrege                                           [Page 11]

Internet Draft     NAT Terminology and Considerations          July 1998

   the same NAT configuration can provide fail-safe backup for each
   other. In such a case, it would be desirable for backup NATs to
   exchange state information so that a backup NAT can take on
   session load transparently when the primary NAT fails. NAT backup
   becomes simpler, when configuration is based on static maps.

5.0. Private Networks and Tunnels

   Let us consider the case where your private network is connected
   to the external world via tunnels. In such a case, tunnel
   encapsulated traffic may or may not contain translated packets
   depending upon the characteristics of routing realms a tunnel is

   The following subsections discuss two scenarios where tunnels are
   used (a) in conjunction with Address translation, and (b) without

5.1. Tunneling translated packets

   All variations of  address translations discussed in the previous
   section can be applicable to direct connected links as well as
   tunnels and virtual private networks (VPNs).

   For example, a private network connected to a business partner
   through a VPN could employ traditional NAT to communicate with
   the partner. Likewise, it is possible to employ twice NAT,
   if the partner's address space overlapped with the private
   network.  There could be a NAT device on one end of the tunnel
   or on both ends of the tunnel. In all cases, traffic across the
   VPN can be encrypted for security purposes. Security here refers
   to security for traffic across VPNs alone. End-to-end security
   requires trusting NATs within private network.

5.2. Backbone partitioned private Networks

   There are many instances where a private network (such as a
   corporate network) is spread over different locations and use
   public backbone for communications between those locations. In
   such cases, it is not desirable to do address translation, both
   because large numbers of hosts may want to communicate across the
   backbone, thus requiring large address tables, and because there
   will be more applications that depend on configured addresses,
   as opposed to going to a name server. We call such a private
   network a backbone-partitioned private network.

   Backbone-partitioned stubs should behave as though they were a
   non-partitioned stub. That is, the routers in all partitions

Srisuresh & Holdrege                                           [Page 12]

Internet Draft     NAT Terminology and Considerations          July 1998

   should maintain routes to the local address spaces of all
   partitions. Of course, the (public) backbones do not maintain
   routes to any local addresses. Therefore, the border routers must
   tunnel (using VPNs) through the backbones using encapsulation.
   To do this, each NAT box will set aside a global address for

   When a NAT box x in stub partition X wishes to deliver a packet
   to stub partition Y, it will encapsulate the packet in an IP
   header with destination address set to the global address
   of NAT box y that has been reserved for encapsulation. When NAT
   box y receives a packet with that destination address, it
   decapsulates the IP header and routes the packet internally.

6.0. NAT operational characteristics

   NATs are application independent in that the translations are
   limited to IP/TCP/UDP/ICMP headers and ICMP error messages only.
   NATs do not change the payload of the packets, as payloads tend
   to be application specific.

   Due to their application independence, NATs are not considered
   a hindrance to applications pursuing end-to-end transport and
   application layer security. Applications that include IP
   addresses in payload are an exception to this. However,
   end-to-end IP network level security assured by current IPsec
   techniques is not possible, as NATs modify the IP header
   contents in transit.

   IPsec assumes the traditional IP address as the globally unique
   ID and requires IP addresses to be unique. Yet, NATs fundamentally
   operate on the premise of modifying the IP addresses. This
   strongly restricts the use of IPsec and any other protocol which
   includes an IP address in an end-to-end security association.
   Thus, NATs also break the same fundamental assumption by IKE
   (Session key negotiation protocol) and public key distribution
   infrastructures such as secure DNS and X.509 certificates with
   signed public keys.  Integrity of a Security Association (SA),
   identified by the tuple of (Destination Address, SPI, secure
   protocol) is jeopardized by the manipulation of addresses by NAT.
   Tampering of addresses along the way by NAT would break the
   authenticity of signed data and the confidentiality of encrypted
   data, vital to the security infrastructure of IPsec.

   One of the most popular internet applications "FTP" would not work
   with the definition of NAT as described. The following sub-section
   is devoted to describing how FTP is supported on NAT devices.  FTP

Srisuresh & Holdrege                                           [Page 13]

Internet Draft     NAT Terminology and Considerations          July 1998

   ALG is an integral part of most NAT implementations. Some vendors
   may choose to include additional ALGs to custom support other
   applications on the NAT device.

6.1. FTP support

   "PORT" command and "PASV" response in FTP control session payload
   identify the IP address and TCP port that must be used for the
   data session it supports. The arguments to the PORT command and
   PASV response are an IP address and a TCP port in ASCII. An FTP
   ALG is required to monitor and update the FTP control session
   payload so that information contained in the payload is relevant
   to end nodes. The ALG must also update NAT with appropriate data
   session tuples and session orientation so that NAT could set up
   state information for the FTP data sessions.

   Because the address and TCP port are encoded in ASCII, this may
   result in a change in the size of packet.  For instance,
   10,18,177,42,64,87 is 18 ASCII characters, whereas
   193,45,228,137,64,87 is 20 ASCII characters. If the new size is
   same as the previous, only the TCP checksum needs adjustment as a
   result of change of data. If the new size is less than or greater
   than the previous, TCP sequence numbers must also be changed to
   reflect the change in length of FTP control data portion.  A
   special table may be used by the ALG to correct the TCP sequence
   and acknowledge numbers.

7.0. NAT limitations

7.1. Applications with IP-address Content

   Not All applications lend themselves easily to address translation
   by NATs. Especially, the applications that carry IP address
   (and TU port, in case of NAPT) inside the payload. Application Level
   Gateways, or ALGs must be used to perform translations on packets
   pertaining to such applications. ALGs may optionally utilize address
   (and TU port) assignments made by NAT and perform translations
   specific to the application. The combination of NATs and ALGs will
   not provide end-to-end security assured by IPsec. However, tunnel
   mode IPsec can be accomplished with NAT serving as tunnel end point.

   SNMP is one such application with address content in payload. NAT
   routers would not translate IP addresses within SNMP payloads. It
   is not uncommon for an SNMP specific ALG to reside on a NAT router
   to perform SNMP MIB translations proprietary to the private network.

7.2. Applications with inter-dependent control and data sessions

Srisuresh & Holdrege                                           [Page 14]

Internet Draft     NAT Terminology and Considerations          July 1998

   NATs operate on the assumption that each session is independent.
   Session characteristics like session orientation, source and
   destination IP addresses, session protocol, and source and
   destination transport level identifiers are determined
   independently at the start of each new session.

   However, there are applications such as H.323 that use one or
   more control sessions to set the characteristics of the follow-on
   sessions in their control session payload. Such applications
   require use of application specific ALGs that can interpret and
   translate the payload, if necessary. Payload interpretation
   would help NAT be prepared for the follow-on data sessions.

7.3. Debugging Considerations

   NAT increases the probability of mis-addressing. For example,
   same local address may be bound to different global address at
   different times and vice versa. As a result, any traffic flow
   study based purely on global addresses and TU ports could be
   confused and might misinterpret the results.

   If a host is abusing the Internet in some way (such as trying to
   attack another machine or even sending large amounts of junk mail
   or something) it is more difficult to pinpoint the source of the
   trouble because the IP address of the host is hidden in a NAT

7.4. Translation of fragmented FTP control packets

   Translation of fragmented FTP control packets is tricky when the
   packets contain "PORT" command or response to "PASV" command.
   Clearly, this is a pathological case. One option would be to drop
   the fragments and send an ICMP error message to packet
   originator. Alternately, NAT router could attempt to assemble
   fragments first and then translate prior to forwarding.

   Yet another case would be when each character of packets
   containing "PORT" command or response to "PASV" is sent in a
   separate datagram, unfragmented. In this case, NAT would simply
   have to let the packets through, without translating the TCP

7.5. Compute intensive

   NAT is compute intensive even with the help of a clever checksum
   adjustment algorithm, as each data packet is subject to NAT
   lookup and modifications.  As a result, router forwarding

Srisuresh & Holdrege                                           [Page 15]

Internet Draft     NAT Terminology and Considerations          July 1998

   throughput could be slowed considerably. However, so long as the
   processing capacity of the NAT device exceeds line processing
   rate, this should not be a problem.

8.0. Security Considerations

   Many people view traditional NAT as a one-way (session) traffic
   filter, restricting sessions from external hosts into their
   machines. In addition, when address assignment in NAT is done
   dynamically, that makes it harder for an attacker to point to
   any specific host in the NAT domain. NATs may be used in
   conjunction with firewalls to filter unwanted traffic.

   If NATs and ALGs are not in a trusted boundary, that is a major
   security problem, as ALGs could snoop end user traffic payload.
   Session level payload could be encrypted end to end, so long as
   the payload does not contain IP addresses and transport
   identifiers. End-to-end IP network level security assured by
   current IPsec techniques is not attainable with NATs in
   between. One of the ends must be a NAT box. Refer section 6.0
   for a discussion on why end-to-end IPsec security cannot be
   assured with NAT devices along the route.

   The combination of NATs, ALGs and firewalls will provide a
   transparent working environment for a private networking domain.
   But, end-to-end network security assured by IPsec cannot be
   attained for end-hosts within the private network. If you want to
   use end-to-end IPsec, there cannot be any NATs in the path. If we
   make the assumption that NATs are part of a trusted boundary,
   tunnel mode IPsec can be accomplished with NAT (or a combination
   of NAT, ALGs and firewall) serving as tunnel end point.

   NATs, when combined with ALGs, can ensure that the datagrams
   injected into Internet have no private addresses in headers or
   payload. Applications that do not meet these requirements may be
   dropped using firewall filters. For this reason, it is not
   uncommon to find that NATs, ALGs and firewalls co-exist to provide
   security at the borders of a private network. NAT gateways can be
   used as tunnel end points to provide secure VPN transport of packet
   data across an external network domain.

   Below are some additional security considerations associated with
   NAT routers.

   1. UDP sessions are inherently unsafe. Responses to a datagram
      could come from an address different from the target address
      used by sender ([Ref 4]). NAT implementations that do not track

Srisuresh & Holdrege                                           [Page 16]

Internet Draft     NAT Terminology and Considerations          July 1998

      datagrams on a per-session basis but lump states of multiple UDP
      sessions into a single state could compromise the security even

   2. Multicast sessions (UDP based) are another source for security

      Say, a host on private network initiated a multicast session.
      Datagram sent by the private host could trigger responses in the
      reverse direction from multiple external hosts. NAT
      implementations that use a single state to track the multicast
      responses in a multicast session could potentially be the
      target of security attacks. This multicast specific security
      concern, however, is not unique to NAT implementations, and
      exists across all hosts supporting multicast applications.

   3. NATs can be a target for attacks.

      Since NATs are Internet hosts they can be the target of a
      number of different attacks, such as SYN flood and ping flood
      attacks. NATs should employ the same sort of protection
      techniques as Internet-based servers do.


   [1] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and,
       Lear, E.  "Address Allocation for Private Internets", RFC 1918

   [2] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700

   [3] R. Braden, "Requirements for Internet Hosts -- Communication
       Layers", RFC 1122

   [4] R. Braden, "Requirements for Internet Hosts -- Application
       and Support", RFC 1123

   [5] F. Baker, "Requirements for IP Version 4 Routers",  RFC 1812

   [6] J. Postel, J. Reynolds, "FILE TRANSFER PROTOCOL(FTP)", RFC 959


       RFC 792

   [9] J. Postel, "User Datagram Protocol (UDP)",  RFC 768

Srisuresh & Holdrege                                           [Page 17]

Internet Draft     NAT Terminology and Considerations          July 1998

   [10] J. Mogul, J. Postel, "Internet Standard Subnetting Procedure",
        RFC 950

   [11] Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4 Address
        Behavior Today", RFC 2101

   [12] S. Kent, R. Atkinson, "Security Architecture for the Internet
        Protocol", <draft-ietf-ipsec-arch-sec-05.txt> - Work in

   [13] S. Kent, R. Atkinson, "IP Encapsulating Security Payload
        (ESP)", <draft-ietf-ipsec-esp-v2-05.txt> - Work in progress.

   [14] S. Kent, R. Atkinson, "IP Authentication Header",
        <draft-ietf-ipsec-auth-header-06.txt> - Work in progress.

   [15] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
        <draft-ietf-ipsec-isakmp-oakley-08.txt> - Work in progress.

   [16] D. Piper, "The Internet IP Security Domain of Interpretation
        for ISAKMP", <draft-ietf-ipsec-ipsec-doi-09.txt> - Work in

Authors' Addresses

   Pyda Srisuresh
   Lucent technologies
   4464 Willow Road
   Pleasanton, CA 94588-8519

   Voice: (925) 737-2153
   Fax:   (925) 737-2110
   EMail: suresh@ra.lucent.com

   Matt Holdrege
   Ascend Communications, Inc.
   One Ascend Plaza
   1701 Harbor Bay Parkway
   Alameda, CA 94502

   Voice: (510) 769-6001
   Fax:   (510) 814-2300
   EMail: matt@ascend.com

Srisuresh & Holdrege                                           [Page 18]