Implementation Topologies


Although NAT was originally conceived for a single purpose (staving off address-space depletion), it has proven itself remarkably versatile. Today, NAT can be used to support numerous, vastly different network topologies. In addition to the simple stub network connected to the Internet (as you saw in Figure 7-1), some of the more common implementation varieties include the following:

  • Private network with multiple egress points

  • Partitioned-backbone stub network

  • Using NAT for a subset of IP addresses in a network

We'll look at each in a bit more detail throughout this section.

NOTE

Since its inception, NAT has become almost synonymous with the nonunique private IP addresses reserved in RFCs 1597 and 1918. However, nothing in any of the NAT RFCs requires the use of these nonunique IP addresses. Thus, you can use NAT to simply "hide" globally routable IP addresses from external networks. In and of itself, that would tend to improve the security of the networked computing assets behind the NAT router.


A Network with Multiple Egress Points

Two implementation varieties are very similar but have a single, significant difference. These varieties are a network with multiple egress points, and a multihomed network. Egress is a networking term that indicates a way off a network. In simpler terms, it is a connection to a different network. Both varieties are topologically similar in that they feature two or more connections from the private network to the "outside."

The key difference between these two varieties lies in how you define "outside." A network with multiple egress points enjoys redundant connections to an external network. A multihomed network also enjoys redundant connections, but with an added measure of fault tolerance. This additional fault tolerance derives from connecting to two or more external networks.

Redundant Connections to an External Network

Figure 7-2 demonstrates a simple network with multiple egress points. For the sake of this example, assume that both connections run to the same Internet service provider. In other words, this is just a network with multiple egress points, as opposed to a multihomed network.

Figure 7-2. NAT Translation Tables Must Be Kept Consistent in Networks That Have Multiple Egress Points


In this case, you have multiple connections to the same ISP network, and you use their address blocks as inside global addresses. As shown in Figure 7-2, both egress connections go to the same external network, and they both use inside global addresses that were created from that service provider's large block of addresses. The enterprise network uses 254.1.1.0/24 as its network address. That block was carved from the service provider's 254.1.0.0/16 block. So, all route advertisements to the Internet are simply aggregated up to the /16. No smaller or more-specific route advertisements are needed. In more practical terms, the entire Internet can access all the destinations within the ISP's customer base just by remembering a route to 254.1.0.0/16. That ISP then assumes responsibility for remembering more-specific routes within its network to each destination network created from this large address space.

The only subtle issue in this type of topology is that there are multiple address translation tables. Specifically, there is one per NAT interface. Given that each redundant NAT interface supports the same base of internal devices, it is imperative that the tables be kept consistent with each other. In practice, this can become tedious and time-consuming. Yet it is the price that must be paid for redundancy in a network that must connect externally without the benefit of globally routable IP addresses.

NAT in Multihomed Private Networks

Multihoming is another one of those concepts that made more sense for end users of the Internet than it did for the entities responsible for maintaining its technology base. At its simplest, a multihomed network is one that enjoys two or more connections to another network. Those connections would most likely run to different locations, and probably even to different service provider networks. That greatly complicates routing across the Internet, because it creates two very different, but valid, paths to the same destination. There are other issues too, but they're strictly tangential to our discussion of NAT. We'll come back to multihoming issues in Chapter 12, "Network Stability."

For now, it is sufficient just to know that multihoming greatly complicates internetworking. However, it is highly desirable to end-user organizations for the functionality it brings. Potential benefits of multihoming include reducing and/or eliminating downtime and load balancing. Both are highly attractive to any organization that relies on its network for commercial purposes. But multihoming makes network operations "interesting," and supporting NAT in a multihomed environment is no exception.

For the purposes of this book, let's assume that external network is the Internet. Figure 7-3 gives you a relatively simple topology of a multihomed private network. We'll use this to further explore and explain the vicissitudes of supporting NAT with multiple egress points.

Figure 7-3. Multihomed Private Network


The first thing that a multihomed network needs, like any network, is an address space. Without it, communication is not possible. There are several options for obtaining valid inside global addresses in multihomed configurations. Using Figure 7-3 as a guide, these options are as follows:

  • Use a directly registered address space.

  • Accept a range of addresses from both ISP #1 and ISP #2 and use them both.

  • Accept a range of addresses from ISP #1.

  • Accept a range of addresses from ISP #2.

The first option almost doesn't make sense in a NAT implementation. If you could obtain your own IP address space from your regional registrar, you would probably just implement that space and forget about address translation.

The other three options warrant an explanation before we look at them because they are different ways of solving a common problem. When NAT is introduced in a multihomed network, an added complexity is introduced in the form of a dual set of inside global addresses. Each set of inside global addresses is maintained in its own address translation table. Thus, in a network with multiple egress connections, you have multiple address translation tables to keep synchronized. If those connections go to different networks, you have created the potential for a single internal host to be known externally via two different inside global IP addresses.

So, the challenge in a dual-homed network is figuring out how to keep such a conflict from occurring. The key is carefully managing your inside global addresses. Think about it: Inside local addresses are strictly local. Therefore, who cares what they are! The only addresses that are visible are the inside global addresses maintained by each NAT.

With that brief explanation of the underlying problem, the second, third, and fourth options for obtaining IP addresses raise different sets of issues that need to be examined in more detail.

Option 2

Figure 7-3 demonstrates a multihomed network that uses two different sets of inside global addresses. Two different global addresses identify each of the internal networked devices on the Internet. The correlation between the single set of inside local addresses and the two different sets of inside global addresses is explained in Table 7-5.

Table 7-5. Address Translation Tables in a Multihomed Network with Redundant Inside Global Addresses

Inside Local Addresses

Inside Global Addresses (ISP #1)

Inside Global Addresses (ISP #2)

172.16.9.0/24

254.1.1.0/24

252.168.35.0/24

172.16.9.1

254.1.1.1

252.168.35.1

172.16.9.3

254.1.1.3

252.168.35.3

172.16.9.4

254.1.1.4

2592.168.35.4

172.16.9.5

254.1.1.5

252.168.35.5

172.16.9.6

254.1.1.6

252.168.35.6


Options 3 and 4

Options 3 and 4 are variants of the same solution. In effect, you are accepting a block of addresses from one service provider and using them as the only valid addresses for accessing your network. You could just implement them directly within your network and avoid NAT entirely. But if you wanted to change service providers, you would have to surrender those addresses. Thus, it makes much more sense to think of such "borrowed" addresses as fodder for translation.

Those ISP-provided addresses would serve as inside global addresses, and you would probably rely on the address blocks reserved in RFC 1918 for your inside local addressing. Migrating to a different service provider would be neatly accomplished just by reconfiguring your NAT routers' translation tables. This is illustrated in Figure 7-4. As with previous examples, all addresses shown are from RFC 1918 rather than using any particular organization's IP address blocks.

Figure 7-4. Using One Service Provider's Addresses in a Multihomed Network


In this example, the address block obtained from ISP #1 is used for both connections to the Internet. This forces ISP #2 to accept and advertise a route for a network address that does not belong to it. But there's no guarantee that any given service provider will support a different service provider's addresses. That's a very complex issue, and we'll come back to it in Part IV of this book. For now, let's just continue with the simplifying assumption that the two ISPs won't let you advertise your inside global addresses using a different ISP's address block. That leaves us with few good options for configuring NAT to work in a multihomed environment. This is where RFC 2260 comes in.

RFC 2260

RFC 2260 spelled out a proposed update to NAT specifically designed for enterprises that were multihomed to the Internet via different ISPs. The address allocation and routing scheme described in that document has the potential for tremendous scalability, because it balances traffic loads across multiple Internet connections. The load balancing is achieved by statically configuring which endpoint address uses which Internet connection. Anything statically configured is not flexible and requires manual intervention to change. To better appreciate how RFC 2260 advocates implementing static load balancing of the address translation function, see Figure 7-5.

Figure 7-5. Static Load Balancing in a Multihomed Private Network


As shown in Figure 7-5, the multihomed private network consists of two LAN environments. Each of those LANs connects to the Internet via a NAT router. Rather than trying to keep a pair of address translation tables synchronized, the hosts within the enterprise are arbitrarily divided into two groups. The hosts numbered 176.16.9.3 and 176.16.9.4 use ISP #1, and the hosts numbered 176.16.9.5 and 176.16.9.6 use ISP #2. This has the added value of improving performance by minimizing the size of each address translation table.

Anyone who's ever spent any time running a network knows one basic fact: Traffic loads are highly dynamic. Although you can discern some basic pattern over time, loads and flows vary continuously. Given this fluidity, it doesn't seem to make much sense to statically configure a load-balancing mechanism based solely on IP address. Quite simply, you are locking yourself into a rigid and inflexible load-balancing scheme despite the fact that traffic loads are anything but rigid and inflexible.

Perhaps the best way to explain this incongruity is to point out that RFC 2260 wasn't specifically designed to balance traffic loads across diverse network egress connections. It was designed to balance the workload imposed by the NAT function in a multihomed network. That's a subtle distinction, but it should help you set a more realistic expectation of what load balancing means in the context of this RFC.

NAT for a Subset of Addresses at a Single Location

Another variety of NAT implementation is to implement it for just a subset of hosts within a private network. The key to making NAT work well is to minimize the size of the address translation tables. Thus, it makes sense to implement NAT for just those hosts that require communication with the external network.

Figure 7-6 shows a stub network that has developed a demilitarized zone (DMZ) in its network. This DMZ is a semisecured network region that contains the company's commercial Web site. The computer that hosts this Web presence is the only device in the entire network that requires communication with devices outside the confines of that network. As such, it is the only device that requires an entry in the address translation table. Although all the networked devices use the RFC 1918 address space, only 172.16.9.65 and 172.16.9.66 are serviced by the NAT.

Figure 7-6. Using NAT for a Subset of Hosts in a Stub Network


Limiting the address translation table to just this one device offers two main benefits. First, because the translation table is kept to a minimum, the load that supporting NAT would otherwise impose on the router is also kept to a minimum. Second, because the other hosts in the company are kept hidden from the Internet, they are inherently more secure than if the entire network were accessible to the Internet via NAT.

Although this is an extreme example in that just one host requires Internet access, it isn't an unrealistic example. It also nicely demonstrates another use for NAT.

Partitioned Backbone Stubs

If you read RFCs long enough, eventually you'll come across a new term. That's what happened to me when I was doing the research for this chapter. The term that caught me by surprise was partitioned backbone stubs. RFC 1631 explains that one of the more "sophisticated" uses of NAT would be to let an enterprise outsource its backbone to an ISP. Each of that enterprise's locations would be connected to the ISP's network. This topology is shown in Figure 7-7.

Figure 7-7. Using NAT to Partition an Enterprise's Network Backbone


Figure 7-7 shows a company with four locations interconnected via a backbone owned and operated by an ISP. The inside local addresses are indicated inside each of the clouds that represent the network in each of the company's locations. The outside global addresses are indicated outside the NAT router facing the Internet. (Again, these network addresses are nonroutable, but let's pretend that they are for the sake of example.) Each location runs NAT at its border router. This allows that company's locations to use private addresses yet still communicate through another network. But there is a price to pay for this capability. The company's "backbone network" is a virtual one: Each location is a stub that hangs off someone else's networkhence the term partitioned backbone stub.

The original NAT concept called for a one-to-one mapping of IL to IG addresses. In large networks, or in networks in which a large percentage of the inside local host addresses needed to communicate with external networked devices, that one-to-one mapping between the different address types resulted in large address translation tables. Large tables directly translated into quite a bit of time added to any communication session that required address translation. But this configuration doesn't and shouldn't enable any-to-any connectivity. If you were responsible for this sample network, you wouldn't want other companies connected to the same service provider to enjoy access to your inside hosts.

Thus, it seems logical that the routers in each of the partitioned stubs should keep track of routes to the local address spaces of every other partitioned stub in the company's network. But you wouldn't want the routers in the ISP's public network to maintain routes to any of the local addresses. If they did, your "private" network wouldn't be very secure.

The only logical explanation is that the border routers (the ones that, by the way, also run NAT) must tunnel through the public backbone. Tunneling is a complex topic, but in its simplest form, it is a way of wrapping an IP packet with another IP packet. The external packet is intended solely for transporting the internal packet through an untrusted, unsecured, or technologically different network. In this particular case, wrapping a packet with a packet lets you forward packets of data to hosts in a different partition even though that partition uses RFC 1918 addresses that can't be routed globally.

The way this works is simple. The network topology for a partitioned backbone stub network can be used as an example to demonstrate NAT tunnels. Each NAT router is required to set aside one inside global address for tunneling. NAT uses encapsulation to transport IP packets that aren't considered globally routable (due to their RFC 1918 addresses) through the ISP network. Each NAT router's reserved global address becomes both of the following:

  • The source address of IP packets outbound from that router

  • The destination address of all IP packets destined for the stub network hiding behind each individual NAT router

To better understand how this works, consider the following list. Using Figure 7-7 as a guide, in a typical sequence of events, the steps are as follows:

Step 1.

A host in network 172.16.12.0/24 needs to communicate with a host in network 172.16.25.0/24.

Step 2.

The packets from this communication session can't be satisfied within network 172.16.12.0/24. They are accepted by that network's gateway router (NAT Router #1 in Figure 7-7) for delivery to an external network.

Step 3.

Router #1 examines each packet's destination IP address field and recognizes that the addresses aren't valid in the local network. Thus, it must find an acceptable address to use for transport on the Internet. This is where the NAT function is used. The destination address, such as 172.16.25.68, isn't valid globally.

Step 4.

Gateway router #1 wraps the host's IP packets with another IP packet that contains the corresponding inside global address reserved by the NAT at the destination network's edge. In this case, the "routable" destination address is 252.1.201.68. For the sake of example, each stub network in our example uses IG addresses provided by the ISP. Those addresses are known toand are routable bythat ISP's network.

Step 5.

The wrapped packet is launched into the service provider's network, where it is forwarded to its destination.

Step 6.

When the IP packet reaches its destination, the recipient NAT router, #4, unwraps (or decapsulates, to use the proper technical term) the packet. The wrapper, having fulfilled its mission, is discarded. What remains is the original IP packet, complete with the private address of its destination host. This private address can now be directly used to forward the IP packet to its intended destination.

In this manner, each NAT router correlates one destination address with an entire block of addresses that lie within each partition. Absent of any other considerations, this represents a tremendous reduction in the size of each NAT router's address translation table. The reduction in size pays dividends in the form of decreased processing time per packet.

You might wonder why anyone would build a network in this fashion instead of just directly interconnecting the locations. Without getting too far off topic, suffice it to say that treating each networked location as a stub off someone else's network is a way to provide interconnectivity without all the costs normally associated with a private network. As the telcom and Internet industries continue to commoditize, outsourcing a private backbone becomes increasingly attractive financially.

This concept led to the development of other, more-significant enhancements to NAT. They are explained in the next section.

Updates and Enhancements

NAT was created specifically to mitigate, at least in some small way, the impending IPv4 address-space crisis. Over time, it has evolved with the Internet and now is much more than its creators ever envisioned. The part about making CIDR unnecessary never really came to fruition, but NAT has seen numerous enhancements and updates since its original description back in 1994. The current NAT has been stretched to accommodate scalable routing and load distribution in multihomed networks, coexistence with IPSec, and compatibility with IPv6, to name just a few of its newer capabilities. Each of these enhancements was documented in an RFC.

These RFCs include the informational documents listed in Table 7-6.

Table 7-6. Additional NAT RFCs

RFC

URL

Topic

2663

www.ietf.org/rfc/rfc2663.txt

Standardizing NAT terminology

2694

www.ietf.org/rfc/rfc2694.txt

DNS extensions to NAT

2709

www.ietf.org/rfc/rfc2709.txt

Implementing NAT with tunnel-mode IPSec

2766

www.ietf.org/rfc/rfc2766.txt

IPv4-to-IPv6 NAT protocol translation

2993

www.ietf.org/rfc/rfc2993.txt

NAT's architectural implications

3022

www.ietf.org/rfc/rfc3022.txt

Introduction of TCP and UDP port number translation by NAT devices

3027

www.ietf.org/rfc/rfc3027.txt

NAT's architectural implications, updated


NAT has become a complex and sprawling array of capabilities rolled up and regarded euphemistically by a single name. The multitude of NAT-specific RFCs and other documents can be confusing. Table 7-6 presents some of the more salient documents for your later perusal. These documents are a combination of informational documents published to decrease the potential for confusion and important new extensions to NAT. Each merits examination, but such examination would detract from the primary topic of this book. For example, entire chapters could be devoted to IPSec and NAT, IPv6 and NAT, and port-address translation with NAT. Although each is significant and worth examination, they are advanced topics. As such, they are poor candidates for inclusion in a book on the fundamentals of IP addressing.




IP Addressing Fundamentals
IP Addressing Fundamentals
ISBN: 1587050676
EAN: 2147483647
Year: 2002
Pages: 118
Authors: Mark Sportack

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net