rfc2663.txt

NAT协议完整源代码

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 1999


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 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 1999


2.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 of



Srisuresh & 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, the



Srisuresh & 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