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 . " ; 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]