rfc2391.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 2391                         LSNAT                       August 1998


   In the case where virtual server address is same as the interface
   address of an LSNAT router, server applications (such as telnet) on
   LSNAT router must be disabled for external access on that address.
   This is the limitation to using address owned by LSNAT router as the
   virtual server address.

   Load share NAT operation is also applicable during individual server
   upgrades as follows. Say, a server, that needs to be upgraded is
   statically mapped to a backup server on the inbound.  Subsequent to
   this mapping, new session requests to the original server would be
   redirected by LSNAT to the backup server.  As an extension, it is
   also possible to statically map a specific TU port service on a
   server to that of  backup sever.

   We illustrate the operation of LSNAT in the following subsections,
   where  (a) servers are confined to a stub domain, and belong to
   globally unique address space as shared by clients, (b) servers are
   confined to private address space stub domain, and (c) servers are
   not restrained by any topological limitations.

3.1 Operation of LSNAT in a globally unique address space

   In this section, we will illustrate the operation of LSNAT in a
   globally unique address space. The border router with LSNAT enabled
   on WAN link would perform load sharing and address translations for
   inbound sessions. However, sessions outbound from the hosts in server
   pool will not be subject to any type of translation, as all nodes
   have globally unique IP addresses.

   In the example below, servers S1 (172.85.0.1), S2(172.85.0.2) and
   S3(172.85.0.3) form a server pool, confined to a stub domain. LSNAT
   on the border router is enabled on the WAN link, such that the
   virtual server address S(172.87.0.100) is mapped to the server pool
   consisting of hosts S1, S2 and S3. When a client 198.76.29.7
   initiates a HTTP session to the virtual server S, the LSNAT router
   examines the load on hosts in server pool and selects a host, say S1
   to service the request. The transparent address and TU port
   translations performed by the LSNAT router become apparent as you
   follow the down arrow line. IP packets on the return path go through
   similar address translation. Suppose, we have another client
   198.23.47.2 initiating telnet session to the same virtual server S.
   The LSNAT would determine that host S3 is a better choice to service
   this session as S1 is busy with a session and redirect the session to
   S3. The second session redirection path is delineated with colons.
   The procedure continues for any number of sessions the same way.






Srisuresh & Gan              Informational                      [Page 7]

RFC 2391                         LSNAT                       August 1998


   Notice that this requires no changes to clients or servers. All the
   configuration and mapping necessary would be limited just to the
   LSNAT router.

                                   \ | /
                                 +---------------+
                                 |Backbone Router|
                                 +---------------+
                               WAN |
                                   |
         Stub domain border .......|.........
                                   |
   {s=198.76.29.7, 2745, v         |            {s=198.23.47.2,  3200,
    d=172.87.0.100, 80 } v         |             d=172.87.0.100, 23 }
                         v +------------------+ :
                         v |Border Router with| :
                         v |LSNAT enabled on  | :
                         v |WAN interface     | :
                         v +------------------+ :
                         v       |              :
                         v       |  LAN         :
                   ------v----------------------:---
   {s=198.76.29.7, 2745, v |            |         |:{s=198.23.47.2, 3200,
    d=172.85.0.1,  80  }   |         |         |  d=172.85.0.3,  23 }
                         +--+      +--+       +--+
                         |S1|      |S2|       |S3|
                         |--|      |--|       |--|
                        /____\    /____\     /____\
                    172.85.0.1   172.85.0.2  172.85.0.3

    Figure 1: Operation of LSNAT in Globally unique address space

3.2. Operation of LSNAT in conjunction with a private network

   In this section, we will illustrate the operation of LSNAT in
   conjunction with NAT on the same router. The NAT configuration is
   required for translation of outbound sessions and could be either
   Basic NAT or NAPT.  The illustration below will assume NAPT on the
   outbound and LSNAT on the inbound on WAN link.

   Say, an organization has a private IP network and a WAN link to
   backbone router. The private network's stub router is assigned a
   globally valid address on the WAN link and the remaining nodes in the
   organization have IP addresses that have only local significance. The
   border router is NAPT configured on the outbound allowing access to
   external hosts, using the single registered IP address.





Srisuresh & Gan              Informational                      [Page 8]

RFC 2391                         LSNAT                       August 1998


   In addition, say the organization has servers S1 (10.0.0.1),
   S2(10.0.0.2) and S3 (10.0.0.3) that form a pool to provide inbound
   access to external clients. This is made possible by enabling LSNAT
   on the WAN link of the border router, such that virtual server
   address S(198.76.28.4) is mapped to the server pool consisting of
   hosts S1, S2 and S3. When an external client 198.76.29.7 initiates a
   HTTP session to the virtual server S, the LSNAT router examines load
   on hosts in server pool and selects a host, say S1 to service the
   request. The transparent address  and TU port translations performed
   by the LSNAT router are apparent as you follow the down arrow line.
   IP packets on the return path go through similar address translation.
   Suppose, we have another client 198.23.47.2 initiating telnet session
   to the same address. The LSNAT would determine that host S3 is a
   better choice to service this session as S1 is busy with a session
   and redirect the session to S3. The second session redirection path
   is delineated with colons. The procedure continues for any number of
   sessions the same way.

                                   \ | /
                                 +---------------+
                                 |Backbone Router|
                                 +---------------+
                               WAN |
                                   |
        Stub domain border ........|.........
                                   |
   {s=198.76.29.7, 2745, v         |           {s=198.23.47.2, 3200,
    d=198.76.28.4, 80   }v         |           :d=198.76.28.4, 23 }
                         v+-------------------+:
                         v|Border Router with |:
                         v|  LSNAT and NAPT   |:
                         v|enabled on WAN link|:
                         v+-------------------+:
                         v      |              :
                         v      |  LAN         :
                   ------v---------------------:------
   {s=198.76.29.7, 2745, v |            |       | : {s=198.23.47.2, 3200,
    d=10.0.0.1,    80  }   |         |       |    d=10.0.0.3,    23 }
                         +--+      +--+     +--+
                         |S1|      |S2|     |S3|
                         |--|      |--|     |--|
                        /____\    /____\   /____\
                       10.0.0.1  10.0.0.2  10.0.0.3

     Figure 2: Operation of LSNAT, in coexistence with NAPT






Srisuresh & Gan              Informational                      [Page 9]

RFC 2391                         LSNAT                       August 1998


   Once again, notice that this requires no changes to clients or
   servers.  The translation is completely transparent to end nodes.
   Address mapping on the LSNAT performs load sharing and address
   translations for inbound sessions. Sessions outbound from hosts in
   server pool are subject to NAPT. Both NAT and LSNAT co-exist with
   each other in the same router.

3.3. Load Sharing with no topological restraints on servers

   In this section, we will illustrate a configuration in which load
   sharing can be accomplished on a router without enforcing topological
   limitations on servers. In this configuration, virtual server address
   will be owned by the router that supports load sharing. I.e., virtual
   server address will be same as address of one of the interfaces of
   load share router. We will distinguish this configuration from LSNAT
   by referring this as "Load Share Network Address Port Translation"
   (LS-NAPT). Routers that support the LS-NAPT configuration will be
   termed "LS-NAPT routers", or simply LS-NAPTs.

   In an LSNAT router, inbound TCP/UDP sessions, represented by the
   tuple of (client address, client TU port, virtual server address,
   service port) are translated into a tuple of (client address, client
   TU port, selected server address, service port). Translation is
   carried out on all datagrams pertaining to the same session, in
   either direction. Whereas, LS-NAPT router would translate the same
   session into a tuple of (virtual server address, virtual server TU
   port, selected server, service port). Notice that LS-NAPT router
   translates the client address and TU port with the address and TU
   port of virtual server, which is same as the address of one of its
   interfaces. By doing this, datagrams from clients as well as servers
   are forced to bear the address of LS-NAPT router as the destination
   address, thereby guaranteeing that the datagrams would necessarily
   traverse the LS-NAPT router. As a result, there is no need to require
   servers to be under topological constraints.

   Take for example, figure 1 in section 3.1. Let us say the router on
   which load sharing is enabled is not just a border router, but can be
   any kind of router. Let us also say that the virtual server address S
   (172.87.0.100) is same as the address of WAN link and LS-NAPT is
   enabled on the WAN interface. Figure 3 summarizes the new router
   configuration.

   When a client 198.76.29.7 initiates a HTTP session to the virtual
   server address S (i.e., address of the WAN interface), the LS-NAPT
   router examines load on hosts in server pool and selects a host, say
   S1 to service the request. Appropriately, the destination address is
   translated to be S1 (172.85.0.1). Further, original client address
   and TU port are replaced with the address and TU port of the WAN



Srisuresh & Gan              Informational                     [Page 10]

RFC 2391                         LSNAT                       August 1998


   link.  As a result, destination addresses as well as source address
   and source TU port are translated when the packet reaches S1, as can
   be noticed from the down-arrow path. IP packets on the return path go
   through similar translation. The second client 198.23.47.2 initiating
   telnet session to the same virtual server address S is load share
   directed to S3. This packet once again undergoes LS-NAPT translation,
   just as with the first client. The data path and translations can be
   noticed following the colon line. The procedure continues for any
   number of sessions the same way. The translations made to datagrams
   in either direction are completely transparent to end nodes.

                                   \ | /
                              +---------------+
                              |   Router      |
                              +---------------+
                            WAN |
                                |
                                |
   {s=198.76.29.7, 2745, v      |                {s=198.23.47.2, 3200,
    d=198.76.28.4, 80   }v      | 198.76.28.4  :d=198.76.28.4, 23 }
                         v +----------------+  :
                         v | A Router with  |  :
                         v | LS-NAPT enabled|  :
                            v | on WAN link    |  :
                         v +----------------+  :
                         v               |     :
                         v          LAN  |     :
                   ------v---------------------:------
   {s=198.76.28.4, 7001, v|             |        |:{s=198.76.28.4,7002,
    d=172.85.0.1,   80 }  |          |        |  d=172.85.0.3,  23 }
                        +--+       +--+      +--+
                        |S1|       |S2|      |S3|
                        |--|       |--|      |--|
                       /____\     /____\    /____\
                     172.85.0.1 172.85.0.2 172.85.0.3

     Figure 3: LS-NAPT configuration on a router

   As you will notice, datagrams from clients as well as servers are
   forced to be directed to the router, because they use WAN interface
   address of router as the destination address in their datagrams. With
   the assurance that all packets from clients and servers would
   traverse the router, there is no longer a requirement for servers to
   be confined to a stub domain and for LSNAT to be enabled only on
   border router to the stub domain.






Srisuresh & Gan              Informational                     [Page 11]

RFC 2391                         LSNAT                       August 1998


   The LS-NAPT configuration described in this section involves more
   translations and hence is more complex compared to LSNAT
   configurations described in the previous sections. While the
   processing is complex, there are benefits to this configuration.
   Firstly, it breaks down restraints on server topology. Secondly, it
   scales with bandwidth expansion for client access. Even if Service
   providers have one link today for client access, the LS-NAPT
   configuration allows them to expand to more links in the future
   guaranteeing the same LS-NAPT load share service on newer links.

   The configuration is not without its limitations. Server applications
   (such as telnet) on the router box would have to be disabled for the
   interface address assigned to be virtual server address. Load sharing
   would be limited to TCP and UDP applications only. Maximum
   concurrently allowed sessions would be limited by the maximum allowed
   TCP/UDP client ports on the same address. Assuming that ports 0-1023
   must be set aside as well-known service ports, that would leave a
   maximum of 63K TCP client ports and 63K of UDP client ports on the
   LS-NAPT router to communicate with each load-share server.  As a
   result, LS-NAPT routers will not be able to concurrently support more
   than a maximum of (63K * count of Load-share servers) TCP sessions
   and (63K * count of Load-share servers) UDP sessions.

4.0. Translation phases of a session in LSNAT router.

   As with NATs, LSNATs must monitor the following three phases in
   relation to Address translation.

4.1. Session binding:

   Session binding is the phase in which an incoming session is
   associated with the address of a host in server pool. This
   association essentially sets the translation parameters for all
   subsequent datagrams pertaining to the session. For addresses that
   have static mapping, the binding happens at startup time. Otherwise,
   each incoming session is dynamically bound to a different host based
   on a load sharing algorithm.

4.2. Address lookup and translation:

   Once session binding is established for a connection setup, all
   subsequent packets belonging to the same connection will be subject
   to session lookup for translation purposes.

   For outbound packets of a session, the source IP address (and source
   TU port, in case of TCP/UDP sessions) and related fields (such as IP,
   TCP, UDP and ICMP header checksums) will undergo translation. For
   inbound packets of a session, the destination IP address (and



Srisuresh & Gan              Informational                     [Page 12]

RFC 2391                         LSNAT                       August 1998