rfc2663.txt

NAT协议完整源代码

                        with src=Addr-X, Dest=Addr-k>
              <--------------------------------------




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


   Second method, using a tunnel within private realm:
   ==================================================

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

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

                        <End-to-end packet, with
                        src=Addr-k, Dest=Addr-X>
                        ------------------------------->

                             .
                             .
                             .

                                             <End-to-end packet, with
                                             src=Addr-X, Dest=Addr-k>
                                    <--------------------------------

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

   There may be other approaches to pursue.

   An RSA-IP-Client has the following characteristics. The collective
   set of operations performed by an RSA-IP-Client may be termed "RSA-
   IP".

   1. Aware of the realm to which its peer nodes belong.

   2. Assumes an address from external realm when communicating with
      hosts in that realm. Such an address may be assigned statically
      or obtained dynamically (through a yet-to-be-defined protocol)
      from a node capable of assigning addresses from external realm.
      RSA-IP-Server could be the node coordinating external realm
      address assignment.






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


   3. Route packets to external hosts using an approach amenable to
      RSA-IP-Server. In all cases, RSA-IP-Client will likely need
      to act as a tunnel end-point, capable of encapsulating
      end-to-end packets while forwarding and decapsulating in the
      return path.

   "Realm Specific Address IP Server" (RSA-IP server) is a node resident
   on both private and external realms, that facilitates routing of
   external realm packets specific to RSA-IP clients inside a private
   realm. An RSA-IP-Server may be described as having the following
   characteristics.

   1. May be configured to assign addresses from external realm to
      RSA-IP-Clients, either statically or dynamically.

   2. Must be a router resident on both the private and external
      address realms.

   3. Must be able to provide a mechanism to route external realm
      packets within private realm. Of the two approaches described,
      the first approach requires RSA-IP-Server to be a NAT router
      providing transparent routing for the outer header. This
      approach requires the external peer to be a tunnel end-point.

      With the second approach, an RSA-IP-Server could be any router
      (including a NAT router) that can be a tunnel end-point with
      RSA-IP-Clients.  It would detunnel end-to-end packets outbound
      from RSA-IP-Clients and forward to external hosts. On the
      return path, it would locate RSA-IP-Client tunnel, based on the
      destination address of the end-to-end packet and encapsulate the
      packet in a tunnel to forward to RSA-IP-Client.

   RSA-IP-Clients may pursue any of the IPsec techniques, namely
   transport or tunnel mode Authentication and confidentiality using AH
   and ESP headers on the embedded packets. Any of the tunneling
   techniques may be adapted for encapsulation between RSA-IP-Client and
   RSA-IP-Server or between RSA-IP-Client and external host.  For
   example, IPsec tunnel mode encapsulation is a valid type of
   encapsulation that ensures IPsec authentication and confidentiality
   for the embedded end-to-end packets.

5.2 Realm Specific Address and port IP (RSAP-IP)

   Realm Specific Address and port IP (RSAP-IP) is a variation of RSIP
   in that multiple private hosts use a single external address,
   multiplexing on transport IDentifiers (i.e., TCP/UDP port numbers and
   ICMP Query IDs).




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


   "RSAP-IP-Client" may be defined similar to RSA-IP-Client with the
   variation that RSAP-IP-Client assumes a tuple of (external address,
   transport Identifier) when connecting to hosts in external realm to
   pursue end-to-end communication. As such, communication with external
   nodes for an RSAP-IP-Client may be limited to TCP, UDP and ICMP
   sessions.

   "RSAP-IP-Server" is similar to RSA-IP-Server in that it facilitates
   routing of external realm packets specific to RSAP-IP clients inside
   a private realm. Typically, an RSAP-IP-Server would also be the one
   to assign transport tuples to RSAP-IP-Clients.

   A NAPT router enroute could serve as RSAP-IP-Server, when the outer
   encapsulation is TCP/UDP based and is addressed between the RSAP-IP-
   Client and external peer. This approach requires the external peer to
   be  the end-point of TCP/UDP based tunnel. Using this approach,
   RSAP-IP-Clients may pursue any of the IPsec techniques, namely
   transport or tunnel mode authentication and confidentiality using AH
   and ESP headers on the embedded packets.  Note however, IPsec tunnel
   mode is not a valid type of encapsulation, as a NAPT router cannot
   provide routing transparency to AH and ESP protocols.

   Alternately, packets may be tunneled between RSAP-IP-Client and
   RSAP-IP-Server such that RSAP-IP-Server would detunnel packets
   outbound from RSAP-IP-Clients and forward to external hosts. On the
   return path, RSAP-IP-Server  would locate RSAP-IP-Client tunnel,
   based on the tuple of (destination address, transport Identifier) and
   encapsulate the original packet within a tunnel to forward to RSAP-
   IP-Client. With this approach, there is no limitation on the
   tunneling technique employed between RSAP-IP-Client and RSAP-IP-
   Server. However, there are limitations to applying IPsec based
   security on end-to-end packets.  Transport mode based authentication
   and integrity may be attained.  But, confidentiality cannot be
   permitted because RSAP-IP-Server must be able to examine the
   destination transport Identifier in order to identify the RSAP-IP-
   tunnel to forward inbound packets to. For this reason, only the
   transport mode TCP, UDP and ICMP packets protected by AH and ESP-
   authentication can traverse a RSAP-IP-Server using this approach.

   As an example, say Host-A in figure 2 above, obtains a tuple of
   (Addr-Nx, TCP port T-Nx) from NAPT router to act as RSAP-IP-Client to
   initiate end-to-end TCP sessions with Host-X.  Traversal of end-to-
   end packets within private realm may be illustrated as follows. In
   the first method, outer layer of the outgoing packet from Host-A uses
   (private address Addr-A, source port T-Na) as source tuple to
   communicate with Host-X. NAPT router enroute translates this tuple
   into (Addr-Nx, Port T-Nxa). This translation is independent of RSAP-
   IP-Client tuple parameters used in the embedded packet.



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


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

   Host-A               NAPT router              Host-X
   ------               -----------              ------

   <Outer TCP/UDP packet, with
   src=Addr-A, Src Port=T-Na,
   Dest=Addr-X>,
   embedding
   <End-to-end packet, with
   src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X>
   ----------------------------->

                        <Outer TCP/UDP packet, with
                        src=Addr-Nx, Src Port=T-Nxa,
                        Dest=Addr-X>,
                        embedding
                        <End-to-end packet, with
                        src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X>
                        --------------------------------------->

                             .
                             .
                             .

                                             <Outer TCP/UDP packet with
                                             src=Addr-X, Dest=Addr-Nx,
                                             Dest Port=T-Nxa>,
                                             embedding
                                             <End-to-end packet, with
                                             src=Addr-X, Dest=Addr-Nx,
                                             Dest Port=T-Nx>
                                     <----------------------------------

                        <Outer TCP/UDP packet, with
                        src=Addr-X, Dest=Addr-A,
                        Dest Port=T-Na>,
                        embedding
                        <End-to-end packet, with
                        src=Addr-X, Dest=Addr-Nx,
                        Dest Port=T-Nx>
              <-----------------------------------








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


   Second method, using a tunnel within private realm:
   ==================================================

   Host-A               NAPT router              Host-X
   ------               -----------              ------

   <Outer IP header, with
   src=Addr-A, Dest=Addr-Np>,
   embedding
   <End-to-end packet, with
   src=Addr-Nx, Src Port=T-Nx,
   Dest=Addr-X>
   ----------------------------->

                        <End-to-end packet, with
                        src=Addr-Nx, Src Port=T-Nx,
                        Dest=Addr-X>
                        -------------------------------->

                             .
                             .
                             .

                                             <End-to-end packet, with
                                             src=Addr-X, Dest=Addr-Nx,
                                             Dest Port=T-Nx>
                                   <----------------------------------

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

6.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 address realms a tunnel is bridging.

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





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


6.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).