RFC 2663: IP Network Address Translator (NAT) Terminology and Considerations

INFORMATIONAL

Errata Exist

Network Working Group                                       P. Srisuresh
Request for Comments: 2663                                   M. Holdrege
Category: Informational                              Lucent Technologies
                                                             August 1999


    
IP Network Address Translator (NAT) Terminology and Considerations

Status 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 Overview8 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
Srisuresh & Holdrege         Informational                      [Page 2]

RFC 2663 NAT Terminology and Considerations August 19992.1 . Address realm or realm2.2 . Transparent routingSection 3.2 has a detailed description of transparent routing.

2.3 . Session flow vs. Packet flow
Srisuresh & Holdrege         Informational                      [Page 3]

RFC 2663 NAT Terminology and Considerations August 1999RFC 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 network2.8 . Private/Local networkRFC 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



Srisuresh & Holdrege         Informational                      [Page 5]

RFC 2663 NAT Terminology and Considerations August 19992.9 . Application Level gateway (ALG)3 . What is NAT?
Srisuresh & Holdrege         Informational                      [Page 6]

RFC 2663 NAT Terminology and Considerations August 19993.1 . Transparent Address Assignment3.1.1 . Static Address assignment3.1.2 . Dynamic Address assignment
Srisuresh & Holdrege         Informational                      [Page 7]

RFC 2663 NAT Terminology and Considerations August 19993.2 . Transparent routing3.2.1 . Address binding3.2.2 . Address lookup and translation
Srisuresh & Holdrege         Informational                      [Page 8]

RFC 2663 NAT Terminology and Considerations August 19993.2.3 . Address unbindingsection 2.6
   for some heuristic ways to handle session terminations.

3.3 . ICMP error packet translation4.0 . Various flavors of NAT
Srisuresh & Holdrege         Informational                      [Page 9]

RFC 2663 NAT Terminology and Considerations August 19994.1 . Traditional NAT (or) Outbound NATsection 4.2.

   The following is a description of the properties of realms supported
   by traditional NAT. IP addresses of hosts in external network are
   unique and valid in external as well as private networks. However,
   the addresses of hosts in private network are unique only within the
   private network and may not be valid in the external network. In
   other words, NAT would not 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 both.







Srisuresh & Holdrege         Informational                     [Page 10]

RFC 2663 NAT Terminology and Considerations August 19994.1.1 . Basic NAT4.1.2 . Network Address Port Translation (NAPT)
Srisuresh & Holdrege         Informational                     [Page 11]

RFC 2663 NAT Terminology and Considerations August 19994.2 . Bi-directional NAT (or) Two-Way NAT4.3 . Twice NAT
Srisuresh & Holdrege         Informational                     [Page 12]

RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh & Holdrege         Informational                     [Page 13]

RFC 2663 NAT Terminology and Considerations August 19994.4 . Multihomed NAT
Srisuresh & Holdrege         Informational                     [Page 14]

RFC 2663 NAT Terminology and Considerations August 19995.0 . Realm Specific IP (RSIP)5.1 . Realm Specific Address IP (RSA-IP)
Srisuresh & Holdrege         Informational                     [Page 15]

RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh & Holdrege         Informational                     [Page 16]

RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh & Holdrege         Informational                     [Page 17]

RFC 2663 NAT Terminology and Considerations August 19995.2 Realm Specific Address and port IP (RSAP-IP)
Srisuresh & Holdrege         Informational                     [Page 18]

RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh & Holdrege         Informational                     [Page 19]

RFC 2663 NAT Terminology and Considerations August 1999
Srisuresh & Holdrege         Informational                     [Page 20]

RFC 2663 NAT Terminology and Considerations August 19996.0 . Private Networks and Tunnels
Srisuresh & Holdrege         Informational                     [Page 21]

RFC 2663 NAT Terminology and Considerations August 19996.1 . Tunneling translated packets6.2 . Backbone partitioned private Networks
Srisuresh & Holdrege         Informational                     [Page 22]

RFC 2663 NAT Terminology and Considerations August 19997.0 . NAT operational characteristicsRFC 2385
   [Ref 17] do not.

   In IPSec transport mode, both AH and ESP have an integrity check
   covering the entire payload. When the payload is TCP or UDP, the
   TCP/UDP checksum is covered by the integrity check. When a NAT device
   modifies an address the checksum is no longer valid with respect to
   the new address. Normally, NAT also updates the checksum, but this is
   ineffective when AH and ESP are used.  Consequently, receivers will
   discard a packet either because it fails the IPSec integrity check
   (if the NAT device updates the checksum), or because the checksum is
   invalid (if the NAT device leaves the checksum unmodified).

   Note that IPsec tunnel mode ESP is permissible so long as the
   embedded packet contents are unaffected by the outer IP header
   translation. Although this technique does not work in traditional NAT
   deployments (i.e., where hosts are unaware that NATs are present),
   the technique is applicable to Realm-Specific IP as described in
   Section 5.0.

   Note also that end-to-end ESP based transport mode authentication and
   confidentiality are permissible for packets such as ICMP, whose IP
   payload content is unaffected by the outer IP header translation.

   NAT devices also break fundamental assumptions by public key
   distribution infrastructures such as Secure DNS RFC 2535 [Ref 18] and
   X.509 certificates with signed public keys. In the case of Secure







Srisuresh & Holdrege         Informational                     [Page 23]

RFC 2663 NAT Terminology and Considerations August 19997.1 . FTP support
Srisuresh & Holdrege         Informational                     [Page 24]

RFC 2663 NAT Terminology and Considerations August 19998.0 . NAT limitations8.1 . Applications with IP-address Content8.2 . Applications with inter-dependent control and data sessions8.3 . Debugging Considerations
Srisuresh & Holdrege         Informational                     [Page 25]

RFC 2663 NAT Terminology and Considerations August 19998.4 . Translation of fragmented FTP control packets8.5 . Compute intensive9.0 . Security Considerations
Srisuresh & Holdrege         Informational                     [Page 26]

RFC 2663 NAT Terminology and Considerations August 1999section 7.0 for a discussion on why
   end-to-end IPsec security cannot be assured with NAT devices along
   the route.

   The combination of NAT functionality, ALGs and firewalls will provide
   a transparent working environment for a private networking domain.
   With the exception of RSIP, end-to-end network security assured by
   IPsec cannot be attained for end-hosts within the private network
   (Refer section 5.0 for RSIP operation). In all other cases, if you
   want to use end-to-end IPsec, there cannot be a NAT device in the
   path. If we make the assumption that NAT devices are part of a
   trusted boundary, tunnel mode IPsec can be accomplished with NAT
   router (or a combination of NAT, ALGs and firewall) serving as tunnel
   end point.

   NAT devices, 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 NAT, ALG and firewall functions 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]). As a result, an incoming UDP packet
      might match the outbound session of a traditional NAT router
      only in part (the destination address and UDP port number of
      the packet match, but the source address and port number may
      not). In such a case, there is a potential security compromise
      for the NAT device in permitting inbound packets with partial
      match. This UDP security issue is also inherent to firewalls.

      Traditional NAT implementations that do not track datagrams on
      a per-session basis but lump states of multiple UDP sessions
      using the same address binding into a single unified session
      could compromise the security even further. This is because,
      the granularity of packet matching would be further limited to
      just the destination address of the inbound UDP packets.

   2. Multicast sessions (UDP based) are another source for security
      weakness for traditional-NAT routers. Once again, firewalls face
      the same security dilemma as the NAT routers.



Srisuresh & Holdrege         Informational                     [Page 27]

RFC 2663 NAT Terminology and Considerations August 1999