Internet DRAFT - draft-akkiraju-nat-multihoming

draft-akkiraju-nat-multihoming









NAT Working Group                                    Praveen Akkiraju
Internet Draft                                       Cisco Systems
Category: Informational                              Yakov Rekhter
Expires in six months                                Cisco Systems
                                                     November 1998





                   A Multihoming solution using NATs

                  < draft-akkiraju-nat-multihoming-00.txt >






1. Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and maybe updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   To view the entire list of current Internet-Drafts, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za(Africa), ftp.nordu.net (Northern Europe),
   ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
   ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).


2. Abstract

   Multihoming to upstream ISPs is a requirement today for most networks
   in the Internet. The most common motivation to multihome is for
   reliable, non-stop access to the Internet. However, Multihoming
   creates scaling problems for the global routing infrastructure by
   making route aggregation more difficult for multihomed networks.
   Multihoming also complicates the addressing scheme used by the
   network. Another requirement for multihomed networks is the ability
   to load balance traffic between the multiple links to upstream ISPs.
   This requirement is difficult to fulfill for traffic flow in both
   directions as the multihomed network has no control over the return
   path of the packet.





Akkiraju, Rekhter                                               [Page 1]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998








   This document outlines the use of NATs to address the problems with
   Multihoming discussed above. NATs are currently used by enterprise
   customers with non-unique address space to connect to the Internet.
   This document outlines ways in which NATs when deployed at the
   network-ISP border can minimize the impact on global routing tables
   while enabling load balancing to the Internet.

   Multihoming an enterprise to a single upstream ISP may mitigate some
   of the impact on Internet routing. However, this topic is beyond the
   scope of this document. The focus is on solving the problems
   associated with enterprises connecting to multiple upstream providers
   in the Internet routing infrastructure.

   For a detailed discussion of NAT limitations and other concerns refer
   to Section 7 of [NAT:98] document.


3. Introduction

   An enterprise may acquire its Internet connectivity from more than
   one Internet Service Provider (ISP) for some of the following
   reasons. Maintaining connectivity via more than one ISP could be
   viewed as a way to make connectivity to the Internet more reliable.
   This way when connectivity through one of the ISPs fails,
   connectivity via the other ISP(s) would enable the enterprise to
   preserve its connectivity to the Internet. In addition to providing
   more reliable connectivity, maintaining connectivity via more than
   one ISP could also allow the enterprise to distribute load among
   multiple connections. For enterprises that span wide geographical
   area this could also enable better (more optimal) routing.

   The above considerations, combined with the decreasing prices for the
   Internet connectivity, motivate more and more enterprises to become
   multi-homed to multiple ISPs. At the same time, the routing overhead
   that such enterprises impose on the Internet routing system becomes
   more and more significant. Scaling the Internet, and  being able to
   support a growing number of such enterprises demands mechanism(s) to
   contain this overhead. We assumes that an approach where routers in
   the default-free zone of the Internet would be required to maintain a
   route for every multi-homed enterprise that is connected to multiple
   ISPs does not provide an adequate scaling. Moreover, given the nature
   of the Internet, this paper assumes that any approach to handle
   routing for such enterprises should minimize the amount of
   coordination among ISPs, and especially ISPs that are not directly
   connected to these enterprises.







Akkiraju, Rekhter                                               [Page 2]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998







   In [RFC2260] we described an address allocation and routing scheme
   for multi-homed enterprises that has fairly good scaling properties.
   However, the scheme proposed in [RFC2260] is not without its own
   drawbacks. For one thing it requires renumbering part of an
   enterprise when the enterprise changes one of its ISPs. As a
   corollary, it requires renumbering part of an enterprise when the
   enterprise becomes multi-homed first time. In addition, the ability
   of an enterprise to balance load across multiple connections to ISPs
   is determined largely by the address assignment inside an enterprise.
   This could be viewed as making load balancing fairly rigid and
   inflexible. Controlling load balancing via address assignment also
   adds complexity to the addressing plan used inside an enterprise.

   In this paper we describe how Network Address Translators (NATs)
   could be used to address the deficiencies mentioned in the previous
   paragraph, while at the same time facilitate scalable routing for
   multi-homed multi-provider connectivity. The scheme described in this
   paper (a) doesn't require renumbering when changing ISPs, and (b)
   allows load balancing that does not depend on the address assignment
   inside an enterprise.


4. Address Allocation and Routing

   A multi-homed enterprise connected to a set of ISPs is allocated a
   block of addresses (address prefix) by each of these ISPs (an
   enterprise connected to N ISPs would get N different blocks). We
   refer to these addresses as Inside Global Addresses. The allocation
   of inside global addresses from the ISPs to the enterprise could be
   based on the "address-lending" policy [RFC2008]. Such addresses would
   be allocated out of a block of addresses that the ISP would use for
   lending to its customers. An enterprise's NAT connected to an ISP
   advertises to the ISP direct reachability to the inside global
   addresses obtained from that ISP. The ISP aggregates this
   reachability information for all of its customers into a single
   route.

   The scheme described in this paper places no constraints on the
   address allocation inside an enterprise. Address allocation inside an
   enterprise could use either globally unique addresses, or addresses
   out of the private address space [RFC1918]. We refer to addresses
   used for allocation inside an enterprise as Inside Local Addresses.

   In addition to the inside local and inside global addresses, an
   enterprise must allocate to each of its NATs a block of addresses
   (address prefix) that does not overlap with both the inside local







Akkiraju, Rekhter                                               [Page 3]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






   addresses and with any of the (globally unique) addresses in the
   Internet.  We refer to these addresses as Outside Local Addresses.
   The outside local addresses could  be allocated either out of the
   pool of globally unique addresses, or out of the private address
   space. In the latter case if the enterprise uses private address
   space for its inside local addresses, the enterprise has to put aside
   a portion of the private address space for the use as its outside
   local addresses. An enterprise NAT advertises into the enterprise
   routing direct reachability to the outside local addresses allocated
   to the NAT. That is the only routing information that the NAT
   advertises into the enterprise routing. Thus, the enterprise routing
   carries routes to all of its internal destinations, plus routes to
   the outside local addresses allocated to all the NATs of the
   enterprise, but no other routes. The terminology used to identify the
   various addresses is used in the context of this document only.

   As an illustration consider the example shown in Figure 1, where an
   enterprise foo.com is connected to two ISPs, ISP1, and ISP2. ISP1
   allocates out of its 140.16/16 address block a subblock 140.16.10/24
   to the enterprise. Likewise, ISP2 allocates out of  its 193.17/16
   block a subblock 193.17.15/24 to the enterprise. Both 140.16.10/24
   and 193.17.15/24 are inside global addresses of the enterprise. NAT1
   that connects the enterprise to ISP1 advertises to ISP1 direct
   reachability to 140.16.10/24. Likewise, NAT2 that connects the
   enterprise to ISP2 advertises to ISP2 direct reachability to
   193.17.15/24.

   For its outside local addresses the enterprise uses addresses out of
   the private address space. For NAT1 the enterprise allocates
   192.168.1/24 block, and for NAT2 the enterprise allocates
   192.168.2/24 block. NAT1 advertises into the enterprise routing
   direct reachability to 192.168.1/24, and NAT2 advertises into the
   enterprise routing direct reachability to 192.168.2/24. If the
   enterprise uses private address space for its internal allocation
   (for its inside local addresses), 192.168.1/24 and 192.168.2//24
   blocks cannot be used for such allocation.




                         140.16/16                 193.17/16
                       +---------+         +---------+
                       (         )         (         )
                       (  ISP-1  )         (  ISP-2  )
                       (         )         (         )
                       +---------+         +---------+
                             |                  |
                             |                  |






Akkiraju, Rekhter                                               [Page 4]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998







                             |                  |
           __________________|__________________|___________________
                             |                  |
                             |                  |
      140.16.10/24           |                  |                 193.17.15/24
      (inside global)   +--------+          +--------+        (inside global)
      192.168.1/24      |  NAT1  |          |  NAT2  |        192.168.2/24
      (outside local)   +--------+          +--------+        (outside local)
                             |                  |
                             |                  |
                             |                  |                        FOO.COM
                         +-------+           +-------+                -------
                         |RouterA|-----------|RouterB|
                         +-------+           +-------+
                             |                  |
                             |                  |
                         +-------+           +-------+
                         |DNS Srv|                  |Host X |
                         +-------+           +-------+
                  DNS Server for foo.com



                                 Figure 1





5. Overview of Operations


   Essential to the scheme proposed in this paper is the concept of a
   Network Address Translator (NAT), as  described in [RFC1631]. We
   expect that a reader is well familiar with the basic operations of a
   NAT. In the context of this paper we assume that  a NAT can perform
   translation of both source and destination IP addresses in a packet
   using the address translation table maintained by the NAT. Moreover,
   we assume that the DNS address translation functionality is augmented
   with some of the Application Layer Gateways (ALGs) functionality for
   applications that carry IP addresses as part of their application
   data stream. Specifically, we assume that a NAT implements the ALG
   functionality for the DNS protocol [RFC1034, RFC1035]. A detailed
   discussion of DNS extensions to the NAT are given in [NAT DNS_ALG].
   We expect that a reader is well familiar with the basic operations of
   DNS.







Akkiraju, Rekhter                                               [Page 5]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998




5.1. Address Translation Table

   The address translation table maintained by a NAT consists of two
   types of entries: inside address translation, and outside address
   translation. Each entry consists of two components: local address and
   global address.

   The local address component of an inside address translation type
   entry is an address taken out of the inside local addresses block. We
   refer to such an address as an Inside Local Address (ila). The global
   address component of such an entry is an address taken out of the
   inside global addresses block allocated to the NAT. We refer to such
   an address as an Inside Global Address (iga).

   The local address component of an outside address translation type
   entry is an address taken out of the outside local addresses block
   allocated to the NAT. We refer to such an address as an Outside Local
   Address (ola). Finally, the global address component of such an entry
   is an address of a host outside the enterprise. We refer to such an
   address as an Outside Global Address (oga).


5.2. Handling Data Packets

   The following describes how a NAT handles an IP packet received
   either inside or outside an enterprise. It describes only the
   procedures related to the address translation. The rest of the NAT
   operations follows the procedures described in [RFC1631]. 
   Note : Exceptions to the operations described below maybe configurable.


5.2.1. Processing a packet received inside an enterprise

   When a NAT receives a packet originated inside an enterprise, the NAT
   first searches its address translation table for the outside address
   translation type entry whose (ola) is equal to the destination IP
   address in the packet. If no such entry is found, the packet is
   discarded. If such an entry is found, the NAT replaces the
   destination address in the packet with the (oga) from the found entry.

   The next step in processing the packet is to search the address
   translation table for the inside address translation type entry whose
   (ila) is equal to the source IP address in the packet. If such an
   entry is found, the NAT replaces the source address in the packet
   with the (iga) from the found entry. If no entry is found, the NAT
   (a) creates a new inside address translation type entry, (b) sets the
   (ila) in the entry to the source address in the packet, (c) allocates









Akkiraju, Rekhter                                               [Page 6]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






   an address out of the inside global addresses block allocated to the
   NAT, and (d) sets the (iga) in the entry to the allocated address.
   After that the NAT replaces the source address in the packet with the
   (iga) from the newly created entry.


5.2.2. Processing a packet received outside an enterprise

   When a NAT receives a packet originated outside an enterprise, the
   NAT first searches its address translation table for the inside
   address translation type entry whose (iga) is equal to the destination
   IP address in the packet. If no such entry is found, the packet is
   discarded. If such an entry is found, the NAT replaces the
   destination address with the (ila) from the found entry.

   The next step in processing the packet is to search the address
   translation table for the outside address translation type entry
   whose (oga) is equal to the source IP address in the packet. If such
   an entry is found, the NAT replaces the source address with the (ola)
   from the found entry. If no entry is found, the NAT (a) creates a new
   outside address translation type entry, (b) sets the (oga) in the entry
   to the source address in the packet, (c) allocates an address out of
   the outside local addresses block allocated to the NAT, and (d) sets
   the (ola) in the entry to the allocated address. After that the NAT
   replaces the source address in the packet with the (ola) from the newly
   created entry.


5.3. DNS Configuration

   We assume that an enterprise contains one or more DNS servers
   authoritative for the zone of the enterprise, and that addresses
   assigned to these servers are taken out of the inside local addresses
   block. We further assume that these servers are authoritative for all
   the inside local addresses.


5.3.1. Configuration for bootstrapping

   Bootstrapping the system requires (a) the ability of DNS servers
   inside the enterprise to query some (small) number of DNS servers
   outside the enterprise, and (b)  the ability of DNS servers outside
   the enterprise to query DNS servers inside the enterprise. Usually a
   DNS server inside an enterprise is configured with IP address(es) of
   one or more of the DNS root servers. To accomplish (a) for each of
   such root server each NAT in the enterprise allocates an address out








Akkiraju, Rekhter                                               [Page 7]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






   of the outside local addresses block allocated to the NAT, and
   populates its address translation table with a (statically
   configured) outside address translation type entry whose (oga) is set
   to the address of the DNS root server, and whose (ola) is set to the
   address that the NAT allocates (out of its outside local addresses
   block) to that server. The DNS server inside the enterprise is then
   configured with the addresses that have been allocated by the NATs to
   the root servers.

   As an illustration consider the example shown in Figure 1, and assume
   that the IP address of the DNS root server is 26.0.0.73. Then NAT1
   allocates an address 192.168.1.254 out of the outside local addresses
   block allocated to it, and creates a new outside address translation
   type entry whose (oga) is set to 26.0.0.73 and whose (ola) is set to
   192.168.1.254. Likewise, NAT2 allocates an address 192.168.2.254 out
   of the outside local addresses block allocated to it, and creates a
   new outside address translation type entry whose (oga) is set to
   26.0.0.73 and whose (ola) is set to 192.168.2.254. The DNS server
   inside the enterprise is then configured with 192.168.1.254 and
   192.168.2.254 as the addresses of the root DNS server.

   To accomplish (b) for each  DNS server inside the enterprise each NAT
   in the enterprise allocates an address out of the inside global
   addresses block allocated to the NAT. Each NAT then populated its
   address translation table with a (statically configured) inside
   address translation type entry whose (ila) is set to the address of the
   DNS server (this is an address out of the inside local addresses
   block), and whose (iga)  is set to the address that the NAT allocates
   (out of its inside global addresses block) to that server. In
   addition, the glue Resource Records for that server in the DNS
   servers of the parent zone contain the (iga) addresses associated
   with that server.

   As an illustration consider the example shown in Figure 1, and assume
   that the IP address of the DNS server inside the enterprise foo.com
   is 10.20.20.10. Then NAT1 has an inside address translation type
   entry whose (ila)  is set to 10.20.20.10 and whose (iga)  is set to
   140.16.10.254 (an address taken out of NAT1's inside global addresses
   block). Likewise,  NAT2 has an inside address translation type entry
   whose (ila) is set to 10.20.20.10 and whose (iga)  is set to
   193.17.15.250 (an address taken out of NAT2's inside global addresses
   block). The DNS servers in the parent zone (.com) contain two glue A
   RRs for that server, one with 140.16.10.254 address, and another with
   193.17.15.250 address.










Akkiraju, Rekhter                                               [Page 8]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






5.3.2. Configuration for handling Queries for PTR RR

   To provide correct handling of DNS Queries for PTR RRs it is
   important that when such queries are originated outside the
   enterprise and are for the addresses out of a particular inside
   global addresses block allocated to the enterprise, then these
   queries will be processed by a NAT to which this block has been
   allocated. Likewise, it is important that when such queries are
   originated inside the enterprise and are for the addresses out of a
   particular outside local addresses block of the enterprise, then
   these queries  will be processed by the NAT to which this block has
   been allocated.

   To accomplish this, in the DNS server authoritative for the block of
   addresses out of which a particular inside global addresses subblock
   is allocated to the enterprise, the glue Resource Record for the DNS
   server authoritative for the allocated inside global addresses
   subblock should contain the (iga) of the DNS server inside the
   enterprise that is assigned to it by the NAT to which the inside
   global address block is allocated. For each NAT inside the enterprise
   the DNS server inside the enterprise is configured with the (ola) that
   the NAT allocates to the DNS root server(s) as the address of the DNS
   server authoritative for the outside local addresses block allocated
   to the NAT.

   As an illustration consider the example shown in Figure 1, and assume
   that the DNS server inside the enterprise NAT1 has an inside address
   translation type entry whose (ila) is set to 10.20.20.10 (the address
   of the DNS server inside the enterprise), and whose (iga) is set to
   140.16.10.254, and NAT2 has an inside address translation type entry
   whose (ila) is set to 10.20.20.10 and whose (iga) is set to
   193.17.15.250. Then the glue  A RR in the DNS server authoritative
   for the 16.140.in-addr.arpa zone would contain 140.16.10.254, and the
   glue A RR in the DNS server authoritative for the 17.193.in-addr.arpa
   zone would contain 193.17.15.250. The DNS server inside the
   enterprise is configured with 192.168.1.254 as the address of the DNS
   server authoritative for the 1.168.192.in-addr.arpa zone, and with
   192.168.2.254 as the address of the DNS server authoritative for the
   2.168.192.in-addr.arpa zone.















Akkiraju, Rekhter                                               [Page 9]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






5.4. Handling DNS messages

   Handling DNS messages (both Query and Response) by a NAT follows the
   procedures for handling IP data packets (as described in Section
   5.2). Handling DNS messages may also involve modifying these
   messages. Specifically, the Question section of a DNS message is
   modified if the section contains a query for a PTR RR. The Answer or
   the Additional section is modified if the section contains either PTR
   RRs  or A Rrs. In addition, handling DNS Response messages that carry
   A RRs (either in the Answer, or in the Additional section) may result
   in creation of new entries in the address translation table of the
   NAT (based on the information carried by A RRs).


5.4.1. Modifying the Question Section

   When a NAT receives a DNS Query  that originates inside the
   enterprise, and the Question section contains a query for a PTR RR,
   the NAT searches its address translation table for the outside
   address translation type entry whose (ola) is equal to the address
   carried in the Question section. If no such entry is found the
   message is discarded. If the entry is found, then the address in the
   Question section is replaced with the (oga) of the found entry.

   When a NAT receives a DNS Query  that originates outside the
   enterprise, and the Question section contains a query for a PTR RR,
   the NAT searches its address translation table for the inside address
   translation type entry whose (iga) is equal to the address carried in
   the Question section. If no such entry is found the message is
   discarded. If the entry is  found, then the address in the Question
   section is replaced with the (ila) of the found entry.

   When a NAT receives a DNS Response that originates inside the
   enterprise, and the Question section contains a query for a PTR RR,
   the NAT searches its address translation table for the inside address
   translation type entry whose (ila) is equal to the address carried in
   the Question section. If no such entry is found the message is
   discarded. If the entry is  found, then the address in the Question
   section is replaced with the (iga) of the found entry.

   When a NAT receives a DNS  Response that originates outside the
   enterprise, and the Question section contains a query for a PTR RR,
   the NAT searches its address translation table for the outside
   address translation type entry whose (oga) is equal to the address
   carried in the Question section. If no such entry is found the
   message is discarded. If the entry is found, then the address in the








Akkiraju, Rekhter                                              [Page 10]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






   Question section is replaced with the (ola) of the found entry.


5.4.2. Handling PTR RRs

   When a NAT receives a DNS Response that originates inside the
   enterprise, and the Response contains a PTR RR, the NAT searches its
   address translation table for the inside address translation type
   entry whose (ila) is equal to the address carried in the PTR RR. If
   no such entry is found the message is discarded. If the entry is
   found, then the address in the PTR RR is replaced with the (iga) of
   the found entry.

   When a NAT receives a DNS  Response that originates outside the
   enterprise, and the Response contains a PTR RR, the NAT searches its
   address translation table for the outside address translation type
   entry whose (oga) is equal to the address carried in the PTR RR. If
   no such entry is found the message is discarded. If the entry is
   found, then the address in the PTR RR is replaced with the (ola) of
   the found entry.


5.4.3. Handling A RRs

   When a NAT receives a DNS Response originated outside an enterprise,
   and the Response carries A RRs (either in the Answer on in the
   Additional section), the NAT checks whether its address translation
   table has the outside address translation type entry whose (oga) is
   equal to the address carried in the A RR of the Response (regardless
   of whether the RR is carried in the Answer or in the Additional
   section of the message). If such an entry is found, the NAT replaces
   the address in the A RR with the (ola) from the found entry. If no
   such entry is found the NAT (a) creates a new outside address
   translation type entry, (b) sets the (oga) of the entry to the
   address carried in the A RR, (c) allocates an address out of the
   outside local addresses block associated with the NAT, (d) sets the
   (ola) to the allocated address, and (e) replaces the address in the A
   RR with the (ola).

   When a NAT receives a DNS Response originated inside an enterprise,
   and the Response carries A RRs (either in the Answer on in the
   Additional section), the NAT checks whether its address translation
   table has the inside address translation type entry whose (ila) is
   equal to the address carried in the A RR of the Response (regardless
   of whether the RR is carried in the Answer or in the Additional
   section of the message). If such an entry is found, the NAT replaces








Akkiraju, Rekhter                                              [Page 11]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






   the address in the A RR with the (iga) from the entry. Otherwise, the
   NAT (a) creates a new inside address translation type entry, (b) sets
   the (ila) of the entry to the address carried in the A RR, (c)
   allocates an address out of the inside global addresses block
   associated with the NAT, (d) sets the (iga) to the allocated address,
   and (e) replaces the address in the A RR with the (iga).



6. Examples of operations

   In this section we present several examples that illustrate
   operations of the scheme described in this paper. We assume that
   initially the DNS server inside the enterprise foo.com does not have
   any information about DNS servers authoritative for the bar.com zone.
   We further assume that NATs and the DNS  server inside the enterprise
   are configured as described in Section 5.3. Thus the address
   translation table maintained by NAT1 contains the following entries:


   Entry Type                      Local Address            Global Address
   inside address translation      10.20.20.10 (ila)        140.16.10.254 (iga)
   outside address translation     192.168.1.254 (ola)      26.0.0.73 (oga)


   Likewise, the address translation table maintained by NAT2 contains
   the following entries:

   Entry Type                      Local Address            Global Address

   inside address translation      10.20.20.10 (ila)        193.17.15.250 (iga)
   outside address translation     192.168.2.254 (ola)      26.0.0.73 (oga)



6.1. Internally originated connection

   In this section we describe the operations where a host inside an
   enterprise originates a connection to a host outside the enterprise.
   Consider the example shown in Figure 2, where host X.foo.com inside
   an enterprise wants to establish communication with host Y.bar.com
   that is outside the enterprise.












Akkiraju, Rekhter                                              [Page 12]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






6.1.1. Finding DNS server authoritative for bar.com

   First, the DNS server inside foo.com sends a query to one of its
   preconfigured root DNS servers. Lets assume that the query is sent to
   the address 192.168.1.254. In this case the Query will be routed to
   NAT1 (as NAT1 advertises direct reachability to 192.168.1/24 into the
   enterprise routing). Following the procedures described in Section
   5.2.1, NAT1 finds in its address translation table an outside address
   translation type entry whose (ola) is equal to 192.168.1.254, and then
   replaces the destination address in the packet with the (oga) of the
   found entry (26.0.0.73). Next NAT1 finds in its address translation
   table an inside address translation type entry whose (ila) is equal
   to 10.20.20.10, and then replaces the source address in the packet
   with the iga of the found entry (140.16.10.254).

   When the Query  reaches the root DNS server, the server composes a
   Response that includes in its Additional section one or more A RRs of
   the DNS servers authoritative for the bar.com zone. Lets assume that
   one such server has IP address 35.1.1.42. The Response will be
   forwarded towards NAT1 (since the destination IP address in the
   packet that carries the response is 140.16.10.254).

   When NAT1  receives the Response message, following the procedures
   described in Section 5.2.2, it finds in its address translation table
   an inside address translation type entry whose (iga) is equal to the
   destination address in the packet (140.16.10.254), and then replaces
   the destination address with the (ila) of the found entry
   (10.20.20.10). Next NAT1 finds in its address translation table an
   outside address translation type entry whose (oga) is equal to the
   source address in the message (26.0.0.73), and then replaces the
   source address in the packet with the (ola) of the found entry
   (192.168.1.254).

   In addition, NAT1 notices that the Additional section of the Response
   contains an A RR. Following the procedures described in Section
   5.4.3, NAT1 checks whether its address translation table has an
   outside address translation type entry whose (oga) is equal to
   35.1.1.42 (the address carried in the A RR). Since no such entry is
   found, NAT1 (a) creates a new outside address translation type entry,
   (b) sets the(oga) of the entry to 35.1.1.42, (c) allocates an address
   192.168.1.253 out of the outside local addresses block allocated to
   NAT1, (d) sets the (ola) of the entry to 192.168.1.253, and (e)
   replaces 35.1.1.42 with 192.168.1.53 in the A RR. At this point the
   address translation table maintained by NAT1 contains the following
   entries:









Akkiraju, Rekhter                                              [Page 13]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






   Entry Type                      Local Address            Global Address

   inside address translation      10.20.20.10 (ila)        140.16.10.254 (iga)
   outside address translation     192.168.1.254 (ola)      26.0.0.73 (oga)
   outside address translation     192.168.1.253 (ola)      35.1.1.42 (oga)




6.1.2. Communication with the DNS server authoritative for bar.com

   When the DNS server inside the enterprise receives the Response from
   the root DNS server, it originates a Query to the DNS server
   authoritative for the bar.com zone. The destination IP address in the
   packet that carries the Query is set to 192.168.1.253. Since NAT1
   advertises into the enterprise routing direct reachability to
   192.68.1/24, the packet will be routed to NAT1. When NAT1 receives
   the packet, following the procedures described in Section 5.2.1 NAT1
   finds in its address translation table an outside address translation
   type entry whose (ola) is equal to the destination address in the
   packet (192.168.1.253), and replaces the destination address in the
   packet with the oga from the found entry (35.1.1.42). Next NAT1 finds
   in its address translation table an inside address translation type
   entry whose (ila) is equal to 10.20.20.10, and replaces the source
   address in the packet with the iga from the found entry
   (140.16.10.254).

   When the Query reaches the DNS server authoritative for the bar.com
   zone (35.1.1.42), the server composes a Response and sends it back.
   The Response is forwarded towards NAT1 (since the destination IP
   address in the packet that carries the response is 140.16.10.254).

   When NAT1 receives the Response, NAT1 finds that its address
   translation table does not have an outside address translation type
   entry whose (oga) is equal to the address of Y.bar.com (16.10.10.2).
   Therefore, following the procedures described in Section 5.4.3, NAT1
   (a) creates a new outside address translation type entry, (b) sets
   the (oga) of the entry to the IP address carried in the A RR of the
   Response (16.10.10.2), (c) allocates an address out of its outside
   local addresses block (192.168.1.5), (d) sets the (ola) of the entry
   to this address, and (e) replaces the IP address carried in the A RR
   of the Response with this address. This completes the creation of a
   new outside address translation type entry.

   The modified Response is then sent to the DNS server inside the
   enterprise, which in turn, sends it to X.foo.com. At this point the








Akkiraju, Rekhter                                              [Page 14]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






   address translation table maintained by NAT1  contains the following
   entries:

   Entry Type                      Local Address            Global Address

   inside address translation      10.20.20.10 (ila)        140.16.10.254 (iga)
   outside address translation     192.168.1.254 (ola)      26.0.0.73 (oga)
   outside address translation     192.168.1.253 (ola)      35.1.1.42 (oga)
   outside address translation     192.168.1.5 (ola)        16.10.10.2 (oga)




           DNS REPLY
          (Y.bar.com=16.10.10.2)
       /\     |
       |      |         140.16/16           193.17/16
       |      |        +---------+         +---------+
       |      |        (         )         (         )
       |      |        (  ISP-1  )         (  ISP-2  )
       |      |        (         )         (         )
       |     \/        +---------+         +---------+
                             |                  |
   DNS QUERY                 |                  |
   (Y.bar.com)               |                  |
           __________________|__________________|___________________
                             |                  |
                             |                  |
      140.16.10/24           |                  |             193.17.15/24
      (inside global)   +--------+          +--------+        (inside global)
      192.168.1/24      |  NAT1  |          |  NAT2  |        192.168.2/24
      (outside local)   +--------+          +--------+        (outside local)
                             |                  |
                             |                  |
       /\       |            |                  |                     FOO.COM
        |       |        +-------+           +-------+                -------
        |       |        |RouterA|-----------|RouterB|
        |       |        +-------+           +-------+
        |       |            |                  |
        |       |            |     <--------    |
        |       |        +-------+    DNS    +-------+
        |       \/       |DNS Srv|   QUERY   |Host X |
                         +-------+           +-------+

   DNS QUERY      DNS REPLY
   (Y.bar.com)    (Y.bar.com=192.168.1.5)








Akkiraju, Rekhter                                              [Page 15]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






                   oga = 16.10.10.2        ola = 192.168.1.5




                                   Figure 2




6.1.3. First data packet

   Now consider what happens when X.foo.com sends a packet to Y.bar.com
   (see Figure 3). The packet destination address is set to 192.168.1.5,
   and since NAT1 advertises direct reachability to 192.168.1/24 into
   the enterprise routing, the packet is routed to NAT1. When NAT1
   receives the packet, NAT1 finds no inside address translation type
   entry with (ila) equal to the IP source address in the packet.
   Therefore, following the procedures described in Section 5.2.1, NAT1
   creates a new entry of type inside address translation, sets the
   (ila) of the entry to the source address of the packet (10.1.1.1),
   allocates an address (140.16.10.2) out of its inside global addresses
   block, and sets the (iga) to that address.

   That completes the creation of the inside address translation type
   entry. NAT1 then replaces the source address in the packet (10.1.1.1)
   with the (iga) of the entry (140.16.10.2). After that NAT1 searches
   its address translation table for an outside address translation type
   entry with (ola) equal to the destination address in the packet. Once
   the entry is found, NAT1 replaces the destination address
   (192.68.1.5) with the (oga) from the found entry (16.10.10.2) and the
   packet is sent to Y.bar.com.

   At this point the address translation table maintained by NAT1
   contains the following entries

   Entry Type                      Local Address            Global Address

   inside address translation      10.20.20.10 (ila)        140.16.10.254 (iga)
   outside address translation     192.168.1.254 (ola)      26.0.0.73 (oga)
   outside address translation     192.168.1.253 (ola)      35.1.1.42 (oga)
   outside address translation     192.168.1.5 (ola)        16.10.10.2 (oga)
   inside address translation      10.1.1.1 (ila)           140.16.10.2 (iga)



   Observe that at this point is has all the necessary entries to
   support communication between X.foo.com and Y.bar.com.






Akkiraju, Rekhter                                              [Page 16]



Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998








   * Data Packet *
   s = 140.16.10.2
   d = 16.10.10.2
                         140.16/16                 193.17/16
          /\           +---------+         +---------+
          |            (         )         (         )
          |            (  ISP-1  )         (  ISP-2  )
          |            (         )         (         )
          |            +---------+         +---------+
          |                  |                  |
          |                  |                  |
                             |                  |
           __________________|__________________|___________________
                             |                  |
                             |                  |
      140.16.10/24           |                  |             193.17.15/24
      (inside global)   +--------+          +--------+        (inside global)
      192.168.1/24      |  NAT1  |          |  NAT2  |        192.168.2/24
      (outside local)   +--------+          +--------+        (outside local)
                             |                  |
                             |                  |
                             |                  |                     FOO.COM
          /\             +-------+           +-------+                -------
          |              |RouterA|-----------|RouterB|
          |              +-------+           +-------+
          |                  |                  |
          |                  |                  |
          |              +-------+           +-------+
          |              |DNS Srv|           |Host X |
                         +-------+           +-------+
   * Data Packet *
   s = 10.1.1.1
   d = 192.168.1.5


                   oga = 16.10.10.2        ola = 192.168.1.5
                   ila = 10.1.1.1          iga = 140.16.10.2





                                    Figure 3









Akkiraju, Rekhter                                              [Page 17]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






6.1.4. Query for PTR RR

   When X.foo.com sends a Query for PTR RR associated with Y.bar.com,
   the QNAME field in the Question section of the Query contains
   5.1.168.192.in-addr.arpa. The DNS server inside foo.com notices (from
   its configuration) that such Query should be sent to 192.168.1.254.
   When the Query reaches NAT1, it replaces the source IP address in the
   packet (10.20.20.10) with 140.16.10.254, the destination IP address
   in the packet (192.168.1.254) with 26.0.0.73, and following the
   procedures described in Section 5.4.1 replaces 5.1.168.192 in the
   QNAME  field with 2.10.10.16.

   The Response to the Query would carry 2.10.10.16 in the QNAME  field,
   and will also contain a PTR RR that carries 16.10.10.2. When the
   Response reaches NAT1, it  replaces 2.10.10.16 in the QNAME  field
   with 5.1.168.192 and 16.10.10.2 in the PTR RR with 192.168.1.5. NAT1
   then translates IP source and destination addresses, and sends the
   Response to the DNS server inside foo.com, which in turn sends it to
   X.foo.com.


6.2. Externally originated connection

   In this section we describe the operations where a host outside an
   enterprise originates a connection to a host inside the enterprise.
   Consider the example shown in Figure 4, where host Y.bar.com wants to
   establish communication with host X.foo.com (Y.bar.com is outside the
   enterprise). Assume that the DNS server inside bar.com does not have
   any information about DNS servers authoritative for the foo.com zone.


6.2.1. Finding DNS server authoritative for foo.com

   To determine IP address of the DNS server authoritative for the
   foo.com zone the DNS server inside bar.com (whose IP address is
   assumed to be 35.1.1.42) sends a Query to one of the DNS servers
   authoritative for the foo.bar's parent zone. The server in the
   parent's zone returns in the Response two A RRs,  one that contains
   140.16.10.254, and another that contains 193.17.15.250.















Akkiraju, Rekhter                                              [Page 18]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998







6.2.2. Communication with the DNS server authoritative for foo.com

   After the server in the bar.com zone finds addresses of the server
   authoritative for the foo.com zone, the server in the bar.com zone
   sends a Query message to one of these addresses. Let's assume that
   the Query is sent to the address 140.16.10.254. In this case the
   Query will be routed to NAT1 (as NAT1 advertises direct reachability
   to 140.16.10/24 into the Internet routing).

   Following the procedures described in Section 5.2.2, NAT1 finds in
   its address translation table an inside address translation type
   entry whose (iga) is equal to 140.16.10.254, and then replaces the
   destination address in the packet with the (ila) of the found entry
   (10.20.20.10). Next NAT1 finds that there is no outside address
   translation type entry whose (oga) is equal to the source address in
   the packet (35.1.1.42), and then (a) creates a new outside address
   translation type entry, (b) sets the (oga) in the entry to 35.1.1.42,
   (c) allocates an address 192.168.1.253 out of the outside local
   addresses block allocated to NAT1, and (d) sets the (ola) of the
   entry to 192.168.1.253. After that NAT1  replaces the source address
   in the packet (35.1.1.42) with 192.168.1.253.

   At this point the address translation table maintained by NAT1
   contains the following entries:

   Entry Type                      Local Address           Global Address

   inside address translation      10.20.20.10 (ila)        140.16.10.254 (iga)
   outside address translation     192.168.1.254 (ola)      26.0.0.73 (oga)
   outside address translation     192.168.1.253 (ola)      35.1.1.42 (oga)





           DNS QUERY
          (X.foo.com)
      /\           |
       |      |         140.16/16           193.17/16
       |      |        +---------+         +---------+
       |      |        (         )         (         )
       |      |        (  ISP-1  )         (  ISP-2  )
       |      |        (         )         (         )
       |      \/       +---------+         +---------+
                             |                  |
   DNS REPLY                 |                  |







Akkiraju, Rekhter                                              [Page 19]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998







   (X.foo.com=140.16.10.2)   |                  |
           __________________|__________________|___________________
                             |                  |
                             |                  |
      140.16.10/24           |                  |             193.17.15/24
      (inside global)   +--------+          +--------+        (inside global)
      192.168.1/24      |  NAT1  |          |  NAT2  |        192.168.2/24
      (outside local)   +--------+          +--------+        (outside local)
                             |                  |
                             |                  |
       /\       |            |                  |                     FOO.COM
        |       |        +-------+           +-------+                -------
        |       |        |RouterA|-----------|RouterB|
        |       |        +-------+           +-------+
        |       |            |                  |
        |       |            |                  |
        |       |        +-------+           +-------+
        |       \/       |DNS Srv|           |Host X |
                         +-------+           +-------+

   DNS REPLY      DNS QUERY
                  (X.foo.com)
   (X.foo.com=10.1.1.1)


                   ila = 10.1.1.1                iga = 140.16.10.2


                                   Figure 4



   When the Query reaches the DNS server authoritative for the foo.com
   zone (10.20.20.10), the server composes a Response and sends it back.
   The Response will be forwarded towards NAT1 (since the destination IP
   address in the packet that carries the response is 192.168.1.253).
   When NAT1 receives the Response that contains an A RR (for
   X.foo.com), NAT1 following the procedures described in Section 5.4.3
   finds that its address translation table does not have an inside
   address translation type entry whose (ila) is equal to the address
   carried in the A RR of the Response. Therefore NAT1 (a) creates a new
   inside address translation type entry, (b) sets the (ila) of the
   entry to 10.1.1.1 (the address carried in the A RR), (c) allocates an
   address 140.16.10.2 out of the inside global addresses block
   allocated to NAT1 , (d) sets the (iga) of the entry to 140.16.10.2,
   and (e) replaces 10.1.1.1 in the A RR carried by the Response with







Akkiraju, Rekhter                                              [Page 20]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998







   140.16.10.2.

   At this point the address translation table maintained by NAT1
   contains the following entries:


   Entry Type                      Local Address            Global Address

   inside address translation      10.20.20.10 (ila)        140.16.10.254 (iga)
   outside address translation     192.168.1.254 (ola)      26.0.0.73 (oga)
   outside address translation     192.168.1.253 (ola)      35.1.1.42 (oga)
   inside address translation      10.1.1.1 (ila)           140.16.10.2 (iga)




   * Data Packet *
   s = 16.10.10.2
   d = 140.16.10.2
                         140.16/16          193.17/16
          |            +---------+         +---------+
          |            (         )         (         )
          |            (  ISP-1  )         (  ISP-2  )
          |            (         )         (         )
          |            +---------+         +---------+
          |                  |                  |
          \/                 |                  |
                             |                  |
           __________________|__________________|___________________
                             |                  |
                             |                  |
      140.16.10/24           |                  |             193.17.15/24
      (inside global)   +--------+          +--------+        (inside global)
      192.168.1/24      |  NAT1  |          |  NAT2  |        192.168.2/24
      (outside local)   +--------+          +--------+        (outside local)
                             |                  |
                             |                  |
                             |                  |                     FOO.COM
          |              +-------+           +-------+                -------
          |              |RouterA|-----------|RouterB|
          |              +-------+           +-------+
          |                  |                  |
          |                  |                  |
          |              +-------+           +-------+
          \/             |DNS Srv|           |Host X |
                         +-------+           +-------+







Akkiraju, Rekhter                                              [Page 21]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






   * Data Packet *
   s = 192.168.1.5
   d = 10.1.1.1


                   oga = 16.10.10.2        ola = 192.168.1.5
                   ila = 10.1.1.1          iga = 140.16.10.2





                                    Figure 5




6.2.3. First data packet

   Now consider what happens when Y.bar.com sends a packet to X.foo.com
   (see Figure 5). The packet destination address is set to 140.16.10.2,
   and since NAT1 advertises direct reachability to 140.16.10/24 into
   the Internet routing, the packet is routed to NAT1. When NAT1
   receives the packet, following the procedures described in Section
   5.2.2, NAT1 finds an inside address translation type entry with ila
   equal to the IP destination address in the packet. Therefore, NAT1
   replaces the destination address (140.16.10.2) with the (oga) from
   the found entry (192.168.1.5). Next NAT1 finds that its address
   translation table does not have an outside address translation type
   entry whose (oga) is equal to the IP source address in the packet.
   Therefore, NAT1  (a) creates a new outside address translation type
   entry, (b) sets the (oga) of the entry to the source address of the
   packet (16.10.10.2), (c) allocates an address 192.168.1.5 out of its
   outside local addresses block, and sets the (ola) of the entry to
   that address. That completes the creation of the outside address
   translation type entry. NAT1 then replaces the source address in the
   packet (16.10.10.2) with the (ola) of the entry (192.168.1.5) and the
   packet is sent to X.foo.com.

   At this point the address translation table maintained by NAT1
   contains the following entries:

   Entry Type                      Local Address           Global Address

   inside address translation      10.20.20.10 (ila)        140.16.10.254 (iga)
   outside address translation     192.168.1.254 (ola)      26.0.0.73 (oga)
   outside address translation     192.168.1.253 (ola)      35.1.1.42 (oga)
   inside address translation      10.1.1.1 (ila)           140.16.10.2 (iga)






Akkiraju, Rekhter                                              [Page 22]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998







   outside address translation     192.168.1.5 (ola)        16.10.10.2 (oga)


6.2.4. Query for PTR RR

   When Y.bar.com sends a Query for PTR RR associated with X.foo.com, the
   QNAME field in the Question section of the Query contains
   2.10.16.140.in-addr.arpa. The glue RR in the DNS server authoritative
   for the 16.140.in-addr.arpa zone indicates that the address of the
   DNS server authoritative for the 10.16.140.in-addr.arpa zone is
   140.16.10.254. Thus the Query would be sent to NAT1. When the Query
   reaches NAT1, it replaces 2.10.16.140 in the QNAME  field with
   1.1.1.10, and sends the Query to the DNS server inside the
   enterprise.

   The Response to the Query from the DNS server inside the enterprise
   would carry 1.1.1.10 in the QNAME  field, and will also contain a PTR
   RR that carries 10.1.1.1 (as well as the name of the host -
   X.foo.com). When the Response reaches NAT1, following the procedures
   described in Sections 5.4.2, NAT1 replaces 1.1.1.10 in the QNAME
   field and in the PTR RR with 2.10.16.140, and 10.1.1.1 in the PTR RR
   with 140.16.10.2.



7. Discussion

   In this section we discuss issues related to addressing and routing
   (both internal and external), and the use of DNS for load balancing.


7.1. Internal addressing and routing

   The scheme described in this paper places little constraints on how
   an enterprise could organize its internal addressing and routing.
   Specifically, the scheme allows the enterprise to use either the
   private address space [RFC1918], or globally unique addresses, or a
   mix of both. The scheme places no restrictions on the type of routing
   protocols used inside the enterprise.

   The only requirement imposed by the scheme on the interior addressing
   and routing is the requirement  for an enterprise to allocate to each
   of its NATs a block of addresses (address prefix) that will be used
   by the NAT as its outside local addresses block, and then let each
   NAT advertise into the interior routing direct reachability to the
   allocated block. Important to stress that this is all what each NAT







Akkiraju, Rekhter                                              [Page 23]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






   injects into the interior routing - no routing information acquired
   via BGP should be injected into the interior routing. The addresses
   used for the outside local addresses blocks have to be unique within
   the enterprise, and also within the Internet. Use of the private
   address space is one possible source for such addresses; use of
   globally unique addresses is another. If the enterprise uses the
   private address space both for its internal addressing, and for its
   outside local addresses, the addresses used for its outside local
   addresses cannot be used for its internal addressing. Likewise, if
   the enterprise uses globally unique addresses both for its internal
   addressing and for its outside local addresses, the addresses used
   for its outside local addresses can't be used for its internal
   addressing. For a NAT to be able to advertise into the interior
   routing direct reachability to the outside local addresses block
   requires the NAT to participate in the enterprise's interior routing.

   When an enterprise changes its provider(s), such a change does not
   require any modifications to either addressing or routing inside the
   enterprise. Specifically, such a change does not require renumbering
   of any hosts and/or routers inside the enterprise.


7.2. External addressing and routing

   From the point of view of external (inter-domain) addressing and
   routing, an enterprise is assigned blocks of addresses (address
   prefixes) by each of its providers (ISPs). A NAT that connects an
   enterprise to a particular ISP uses the address block allocated by
   that ISP to the enterprise as its inside global addresses block. A
   NAT acts as a border router of the enterprise. That is, a NAT has an
   External BGP peering with one or more of the ISP routers, as well as
   an Internal BGP peering with other NATs inside the enterprise. A NAT
   advertises a direct reachability to its inside global addresses block
   via External BGP. Consequently, a NAT has to support BGP, and act as
   an enterprise border router.

   To provide fallback connectivity we assume that border routers of the
   enterprise use one of the strategies described in [RFC2260].
   Specifically, we assume that all the NATs of an enterprise maintain
   Internal BGP peering among themselves. Note that the address
   allocation strategy required by [RFC2260] is precisely the same as
   the one proposed in this paper for the allocation of inside global
   addresses.

   When a multihomed enterprise changes its provider, the impact of such
   a change on addressing and routing is  limited to external addressing








Akkiraju, Rekhter                                              [Page 24]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






   and routing. Specifically, when an enterprise connects to a new ISP,
   the enterprise has to acquire a block of address (address prefix) out
   of that ISP, configure this block of addresses as the inside global
   addresses block on the NAT that the enterprise uses to connect to
   that ISP, configure BGP peering between the NAT and the border
   routers of the ISP, and then advertise to the ISP direct reachability
   to the inside global addresses block.


7.3. Symmetry

   The scheme described in this paper results in a situation where a
   traffic associated with a particular pair of host (where one host is
   inside, and the other is outside an enterprise) to flow through a
   single NAT. As a consequence, this traffic flows (in both directions)
   through the same ISP connected to the enterprise.


7.4. Load balancing

   One could observe that DNS plays a very important role in selecting
   which of the NATs will be used by a particular connection. This
   suggests to use DNS as a tool to balance load among multiple NATs
   that connect an enterprise to the Internet. Specifically, by
   controlling the selection of a NAT that is used for forwarding a DNS
   Query, one could control the selection of a NAT that is used for
   communication with the target of that Query. In the example described
   earlier, since the Query for Y.bar.com is handled by NAT1,
   communication with Y.bar.com (which is a target of that Query) is
   handled by NAT1 as well.  And if the Query would be handled by NAT2,
   then the communication would be handled by NAT2  also.

   One possible strategy to control the distribution of internally
   originated connections among multiple NATs is to use multiple
   internal DNS servers. As an illustration consider the example where
   the DNS-Server-1's inside local address to inside global address
   mapping is configured on both NAT1  and NAT2. The same is done for
   DNS-Server-2.  DNS-Server-1 is configured with a primary DNS root
   server whose outside local address is taken out of the NAT1's outside
   local addresses block, and a secondary  DNS root server whose outside
   local address is taken out of the NAT2's outside local addresses
   block. Likewise, DNS-Server-2 is configured with a primary DNS root
   server whose outside local address is taken out of the NAT2's outside
   local addresses block, and a secondary DNS root server whose whose
   outside local address is taken out of the NAT1's outside local
   addresses block. As a result, in a steady state all the DNS Queries








Akkiraju, Rekhter                                              [Page 25]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998









   originated by DNS-Server-1 are handled by NAT1, and all the DNS
   Queries originated by DNS-Server-2 are handled by NAT2. Consequently
   if a host (e.g., Host-A) inside an enterprise is configured to use
   DNS-Server-1, then in a steady state all connections originated by
   that host are handled by NAT1. Likewise, if a host (e.g., Host-B) is
   configured to use DNS-Server-2, then in a steady state all
   connections originated by that host are handled by NAT2. By
   appropriately configuring hosts with the addresses of their DNS
   server, the administration of the enterprise can control distribution
   of internally originated connections among its connections to the
   Internet. Controlling which hosts use a particular DNS server can be
   facilitated by using DHCP.

   It is important to observe that the selection of a NAT is not
   affected by the interior routing inside an enterprise. As a result,
   changes in interior routing do not affect the selection of which NAT
   is used for a particular communication.


7.5. Single NAT to multiple ISPs

   A degenerate case of the scheme described in this paper is a scenario
   where a NAT is connected to multiple ISPs. In this case the NAT
   obtains out of each of these ISP a block of addresses that the NAT
   uses as its inside global addresses. To use DNS for load balancing
   one could deploy multiple DNS servers, as described in Section 7.4.



8. Security Considerations


   Security considerations with NAT routers as discussed in Section 10
   of [NAT 98] apply. Detailed discussion of DNS related security issue
   is outside the scope of this document.
















Akkiraju, Rekhter                                              [Page 26]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998




9. Appendix


9.1. Router NAT Configuration Example






                        +-------+
                        |DNS Srv| 140.16.150.150
                        +-------+
                            |
                            |
                         140.16/16          193.17/16
                       +---------+         +---------+
                       (         )         (         )                BAR.COM
                       (  ISP-1  )         (  ISP-2  )                -------
                       (         )         (         )
                       +---------+         +---------+
                             |                  |
                             |                  |
                             |                  |
           __________________|__________________|___________________
                             |                  |
                             |                  |
      140.16.10/24           |                  |             193.17.15/24
      (inside global)   +--------+          +--------+        (inside global)
      192.168.1/24      |  NAT1  |          |  NAT2  |        192.168.2/24
      (outside local)   +--------+          +--------+        (outside local)
                             |                  |
                             |                  |
                             |                  |                     FOO.COM
                         +-------+           +-------+                -------
                         |RouterA|-----------|RouterB|
                         +-------+           +-------+
                             |                  |
                             |                  |
                         +-------+           +-------+
                         |DNS Srv|           |Host X |
                         +-------+           +-------+
                         10.1.150.150


                   oga : 140.16.150.150      ola : 192.168.1.150
                   ila : 10.1.150.150        iga : 140.16.10.150









Akkiraju, Rekhter                                              [Page 27]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998





   DNS Servers

   Domain Name : foo.com

   DNS Server for foo.com  -> 10.1.150.150      (papa.foo.com)
                              Use mama.bar.com (192.168.1.150) to resolve
                              bar.com hosts.

   Domain Name : bar.com

   DNS Server for bar.com-> 140.16.150.150        (mama.bar.com)
                            Uses papa.foo.com (140.16.10.150) to resolve
                            foo.com hosts.

   Cisco Router Configurations

   a] NAT Commands :

   These commands identify the pool of Inside Global and Outside Local
   addresses available for assignment to the NAT. Also shown are the
   interface commands required.

   ip nat pool abc 140.16.10.1 140.16.10.254 netmask 255.255.255.0
   ip nat pool xyz 192.168.1.1 192.168.1.254 netmask 255.255.255.0
   ip nat inside source list 1 nat pool xyz
   ip nat outside source list 1 nat pool abc

   access-list 1 permit any

   int s 0
   ! Link to Upstream ISP
   ip nat outside
   int e 0
   ! Link to Internal Network
   ip nat inside

   Bootstrap DNS Server commands (Refer Section 5.3.1)

   ip nat inside source static 10.1.150.150 140.16.10.150
   ip nat outside source static 140.16.150.150 192.168.1.150

   OSPF Routing commands which ensure default route is originated and also
   advertise reachability to the pool of Outside Local addresses.

   router ospf  1
   :









Akkiraju, Rekhter                                              [Page 28]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998







   default-info originate always
   redistribute static

   ip route 192.168.1.0 255.255.255.0 Null 0



9.2. DNS Server Configuration Sample

   Shown below are the DNS files for the server papa.foo.com

   Note: These configs. are for a lab setup and do not fully represent
   the real world.
        

   a] root.cache file

   Of interest is the reference to mama.bar.com as the root server for
   this DNS Server.

   ;       This file holds the information on root name servers needed to
   ;       initialize cache of Internet domain name servers
   ;       (e.g. reference this file in the "cache  .  <file>"
   ;       configuration file of BIND domain name servers).
   ;
   ;       This file is made available by InterNIC registration services
   ;       under anonymous FTP as
   ;           file                /domain/named.root
   ;           on server           FTP.RS.INTERNIC.NET
   ;       -OR- under Gopher at    RS.INTERNIC.NET
   ;           under menu          InterNIC Registration Services (NSI)
   ;              submenu          InterNIC Registration Archives
   ;           file                named.root
   ;
   ;       last update:    Nov 8, 1995
   ;       related version of root zone:   1995110800
   ;
   ;
   ; formerly NS.INTERNIC.NET

   mama.bar.com.        3600000        IN        A        192.168.1.150


   b] Named.boot

   Here we configure the primary for the domain foo.com referencing foo.db







Akkiraju, Rekhter                                              [Page 29]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998







   as the database for local host name to address mappings. It also points
   to root.cache for root server info.

   ;        BSDI        $Id: named.boot.sample,v 2.1 1996/01/16 17:39:49 polk
   ;                Exp $ @(#)named.boot        8.1 (Berkeley) 6/9/93

   ; boot file for secondary name server
   ; Note that there should be one primary entry for each SOA record.

   ; NOTE:  The name daemon looks for this file in /etc/named.boot, NOT
   ;        /etc/namedb/named.boot!

   sortlist 128.3.0.0

   directory        /etc/namedb

   ; type    domain                source host/file                backup file

   cache     .                root.cache
   primary foo.com                foo.db
   primary   0.0.127.IN-ADDR.ARPA        localhost.rev

   ; example secondary server config:
   ; secondary Berkeley.EDU        128.32.130.11 128.32.133.1 ucbhosts.bak
   ; secondary 32.128.IN-ADDR.ARPA        128.32.130.11 128.32.133.1
     ucbhosts.rev.bak

   ; example primary server config:
   ; primary  Berkeley.EDU                ucbhosts
   ; primary  32.128.IN-ADDR.ARPA        ucbhosts.rev


   c] foo.db

   This file contains the name to address mappings for local hosts.

   ;
   ; Forward resolution for local names
   ;
   ; This file is machine generated by the configdns program.  You should
   ; use that program to make changes if you want to continue using it
   ; in the future.  If you make changes here, they will be lost the
   ; next time configdns is run.
   ;
   @        IN        SOA        foo.com.        hostmaster.foo.com. (
                                   2        ; Serial number







Akkiraju, Rekhter                                              [Page 30]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998






                                   3600        ; Refresh every 2 days
                                   3600        ; Retry every hour
                                   3600        ; Expire every 20 days
                                   3600 ); Minimum 2 days
   ;
                      IN        NS        papa.foo.com.
   ;
   papa               IN        A        10.1.150.150
   ;
   xyz                IN        A        10.1.15.15
   ;
   abc                IN        A        10.1.100.100
   ;
   ; DO NOT DELETE THIS LINE -- place local changes below here



   d] 1.rev

   ;
   ; Reverse address resolution for local network addresses
   ;
   ; This file is machine generated by the configdns program.  You should
   ; use that program to make changes if you want to continue using it
   ; in the future.  If you make changes here, they will be lost the
   ; next time configdns is run.
   ;
   @        IN        SOA        foo.com.        hostmaster.foo.com. (
                                   2        ; Serial number
                                   600        ; Refresh every 2 days
                                   3600        ; Retry every hour
                                   600        ; Expire every 20 days
                                   600 ); Minimum 2 days
   ;
                        IN        NS        papa.foo.com.
   ;
   150.1                IN        PTR        mama.cisco.com.
   ;
   ; DO NOT DELETE THIS LINE -- place local changes below here















Akkiraju, Rekhter                                              [Page 31]




Internet Draft     draft-akkiraju-nat-multihoming-00.txt       November 1998




10. References


   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilites",
   RFC1034, November 1987.

   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
   Specification", RFC1034, November 1987.

   [RFC1631] Egevang, K., Francis, P., "The IP Network Address
   Translator (NAT)" RFC 1631, May 1994.

   [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot G.J.,
   and E. Lear, "Address Allocation for Private Internets", RFC 1918,
   February 1996.

   [RFC2008] Rekhter, Y., and T. Li, "Implications of Various Address
   Allocation Policies for Internet Routing", BCP 7, RFC 2008, October
   1996.

   [RFC2260] Bates, T., and Rekhter, Y., "Scalable Support for Multi-
   homed Multi-provider Connectivity", RFC 2260, January 1998.

   [NAT:98] Srisuresh, P., Egevang, K., "The IP Network Address
   Translator (NAT)", draft-rfced-info-srisuresh-05.txt, February 1998.

   [NAT DNS_ALG:98] Srisuresh, P., Tsirtsis, G., Akkiraju, P.,
   Heffernan, A., " DNS extensions to Network Address Translators
   (DNS_ALG), draft-ietf-nat-dns-alg-01.txt, October 1998.


11. Authors' Addresses

      Praveen Akkiraju
      Cisco Systems, Inc.
      170 West Tasman Drive
      San Jose, CA 95134

      EMail: spa@cisco.com


      Yakov Rekhter
      Cisco Systems, Inc.
      170 West Tasman Drive
      San Jose, CA 95134
      EMail: yakov@cisco.com











Akkiraju, Rekhter                                              [Page 32]