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]
