rfc2663.txt

NAT协议完整源代码

   NAPT extends the notion of translation one step further by also
   translating transport identifier (e.g., TCP and UDP port numbers,
   ICMP query identifiers). This allows the transport identifiers of a
   number of private hosts to be multiplexed into the transport
   identifiers of a single external address. NAPT allows a set of hosts
   to share a single external address. Note that NAPT can be combined
   with Basic NAT so that a pool of external addresses are used in
   conjunction with port translation.

   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 packets, the
   destination IP address, destination transport identifier and the IP
   and transport header checksums are translated.








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


   A NAPT router in figure 2 may be configured to translate sessions
   originated from N-Pri into a single external address, say Addr-i.

   Very often, the external interface address Addr-Nx of NAPT router is
   used as the address to map N-Pri to.

4.2. Bi-directional NAT (or) Two-Way 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 end-to-end unique.
   Hosts in external realm access private realm hosts by using DNS for
   address resolution. A DNS-ALG must be employed in conjunction with
   Bi-Directional NAT to facilitate name to address mapping.
   Specifically, the DNS-ALG must be capable of translating private
   realm addresses in DNS Queries and responses into their external
   realm address bindings, and vice versa, as DNS packets traverse
   between private and external realms.

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

   A Bi-directional NAT router in figure 2 would allow Host-A to
   initiate sessions to Host-X, and Host-X to initiate sessions to
   Host-A. Just as with traditional NAT, N-Ext is routable from within
   N-Pri, but N-Pri may not be routable from N-Ext.

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
   address realms. This is in contrast to Traditional-NAT and Bi-
   Directional NAT, where only one of the addresses (either source or
   destination) is translated. Note, there is no such term as 'Once-
   NAT'.

   Twice NAT is necessary when private and external realms have address
   collisions. The most common case where this would happen is when a
   site had (improperly) numbered its internal nodes using public
   addresses that have been assigned to another organization.
   Alternatively, a site may have changed from one provider to another,
   but chosen to keep (internally) the addresses it had been assigned by
   the first provider. That provider might then later reassign those
   addresses to someone else. The key issue in such cases is that the
   address of the host in the external realm may have been assigned the



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


   same address as a host within the local site. If that address were to
   appear in a packet, it would be forwarded to the internal node rather
   than through the NAT device to the external realm. Twice-NAT attempts
   to bridge these realms by translating both source and destination
   address of an IP packet, as the packet transitions realms.

   Twice-NAT works as follows. When Host-A wishes to initiate a session
   to Host-X, it issues a DNS query for Host-X. A DNS-ALG intercepts the
   DNS query, and in the response returned to Host-A the DNS-ALG
   replaces the address for Host-X with one that is properly routable in
   the local site (say Host-XPRIME). Host A then initiates communication
   with Host-XPRIME. When the packets traverse the NAT device, the
   source IP address is translated (as in the case of traditional NAT)
   and the destination address is translated to Host-X. A similar
   translation is performed on return packets coming from Host-X.

   The following is a description of the properties of realms supported
   by Twice-NAT. 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.

   A Twice NAT router in figure 2 would allow Host-A to initiate
   sessions to Host-X, and Host-X to initiate sessions to Host-A.
   However, N-Ext (or a subset of N-Ext) is not routable from within N-
   Pri, and N-Pri is not routable from N-Ext.

   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 200.200.200.0/24 address space
   which is officially assigned to another site in the public internet.
   Host_A (200.200.200.1) in Private space seeks to connect to Host_X
   (200.200.200.100) 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         Informational                     [Page 13]

RFC 2663           NAT Terminology and Considerations        August 1999


       Private to Public : 200.200.200.0/24 -> 138.76.28.0/24
       Public to Private : 200.200.200.0/24 -> 172.16.1.0/24

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

       a) Within private network

          DA: 172.16.1.100      SA: 200.200.200.1

       b) After twice-NAT translation

         DA: 200.200.200.100    SA: 138.76.28.1

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

       a) Within Public network

          DA: 138.76.28.1       SA: 200.200.200.100

       b) After twice-NAT translation, in private network

          SA: 200.200.200.1     DA: 172.16.1.100

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
   NAT routers 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 router 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 NAT
   routers fail, the other could route traffic for all connections.







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


   Multiple NAT boxes or multiple links on the same NAT box, sharing the
   same NAT configuration can provide fail-safe backup for each other.
   In such a case, it is necessary for backup NAT device 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. Realm Specific IP (RSIP)

   "Realm Specific IP" (RSIP) is used to characterize the functionality
   of a realm-aware host in a private realm, which assumes realm-
   specific IP address to communicate with hosts in private or external
   realm.

   A "Realm Specific IP Client" (RSIP client) is a host in a private
   network that adopts an address in an external realm when connecting
   to hosts in that realm to pursue end-to-end communication. Packets
   generated by hosts on either end in such a setup would be based on
   addresses that are end-to-end unique in the external realm and do not
   require translation by an intermediary process.

   A "Realm Specific IP Server" (RSIP server) is a node resident on both
   private and external realms, that can facilitate routing of external
   realm packets within a private realm. These packets may either have
   been originated by an RSIP client or directed to an RSIP-client.
   RSIP-Server may also be the same node that assigns external realm
   addresses to RSIP-Clients.

   There are two variations to RSIP, namely Realm-specific Address IP
   (RSA-IP) and Realm-Specific Address and Port IP (RSAP-IP). These
   variations are discussed in the following sub-sections.

5.1. Realm Specific Address IP (RSA-IP)

   A Realm Specific Address IP (RSA-IP) client adopts an IP address from
   the external address space when connecting to a host in external
   realm. Once an RSA-IP client assumes an external address, no other
   host in private or external domain can assume the same address, until
   that address is released by the RSA-IP client.

   The following is a discussion of routing alternatives that may be
   pursued for the end-to-end RSA-IP packets within private realm.  One
   approach would be to tunnel the packet to the destination. The outer
   header can be translated by NAT as normal without affecting the
   addresses used in the internal header. Another approach would be to
   set up a bi-directional tunnel between the RSA-IP Client and the
   border router straddling the two address realms. Packets to and from
   the client would be tunneled, but packets would be forwarded as



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


   normal between the border router and the remote destination. Note,
   the tunnel from the client TO the border router may not be necessary.
   You might be able to just forward the packet directly. This should
   work so long as your internal network isn't filtering packets based
   on source addresses (which in this case would be external addresses).

   As an example, Host-A in figure 2 above, could assume an address
   Addr-k from the external realm and act as RSA-IP-Client to allow
   end-to-end sessions between Addr-k and Addr-X. Traversal of end-to-
   end packets within private realm may be illustrated as follows:

   First method, using NAT router enroute to translate:
   ===================================================

   Host-A               NAT router               Host-X
   ------               -----------              ------

   <Outer IP header, with
   src=Addr-A, Dest=Addr-X>,
   embedding
   <End-to-end packet, with
   src=Addr-k, Dest=Addr-X>
   ----------------------------->

                        <Outer IP header, with
                        src=Addr-k, Dest=Addr-X>,
                        embedding
                        <End-to-end packet, with
                        src=Addr-k,  Dest=Addr-X>
                        --------------------------->

                             .
                             .
                             .

                                              <Outer IP header, with
                                              src=Addr-X, Dest=Addr-k>,
                                              embedding
                                              <End-to-end packet, with
                                              src=Addr-X, Dest=Addr-k>
                                     <---------------------------------

                        <Outer IP header, with
                        src=Addr-X, Dest=Addr-A>,
                        embedding <End-to-end packet,