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