Large Scale NAT Architectures

NAT444 and NAT 464

Traditional NAT, as discussed in the previous article, has been used for fifteen or so years to enable the sharing of a small number of public IPv4 addresses by a larger number of privately-addressed devices. In the case of homes and small businesses, there is usually just a single public IPv4 address on the outside NAT interface. That public address is assigned by a broadband service provider.

As we approach the depletion of public IPv4 addresses, broadband providers are looking at how to continue giving their customers public-facing IP addresses when there are no IPv4 addresses left to hand out. The answer seems rather obvious: If NAT has been effective at the provider-facing customer edge, it should also be effective at the customer-facing provider edge. That’s the basis of Large Scale NAT (LSN).

LSN adds another layer of translation, so that just as private IPv4 addresses are used on the inside of the CPE NAT they can also be used to assign addresses to the outside of the CPE NAT.

Figure 1 shows a conceptual example. The service provider assigns addresses out of its public IPv4 aggregate to the “Internet-facing” side of its LSN devices. On the “customer-facing” side of each LSN, an address out of a private IPv4 block – say, the 172.16.0.0/12 block – is assigned to the outside of each attached CPE NAT. Each customer then uses another private IPv4 block – typically 10.0.0.0/8 – to address all the devices within his network.

A device in one of the customer networks might send a packet to some Internet destination with a source address of 10.1.1.1; the CPE NAT then translates the source address to, for instance, 172.16.1.1 (with accompanying port mapping). At the LSN the source address is translated to the public IPv4 address, say 201.15.83.1 (again with port mapping), and the packet is routed to the destination. Responding packets to 201.15.83.1 are routed to the service provider’s aggregate IPv4 address, then to the appropriate LSN, which translates the destination address back to 172.16.1.1 and forwards the packet to the corresponding CPE NAT which translates the destination address to 10.1.1.1.

Accurate routing from the Internet to the correct device within the correct customer network depends on two things:

1)    The session was initiated from within the customer network, so that the CPE NAT and the LSN have the correct address and port mappings; and

2)    The route view from the outside is always toward a destination that can be uniquely identified. So a packet from the public Internet can be routed to the service provider’s unique IPv4 aggregate address; once within the service provider network, a more-specific route is used to send the packet to a particular LSN (which is usually a software process on some edge or aggregation router). The LSN has an outside-to-inside address/port mapping that points to a specific CPE NAT, and the CPE NAT has another outside-to-inside address/port mapping that either takes the packet to a directly connected destination or matches a route that is unique within the boundaries of that customer’s network.

This architecture is NAT444: It translates from IPv4 address to another IPv4 address to a third IPv4 address. The approach is attractive because existing CPE NATs can be used with no modifications. NATs do not care whether their outside IPv4 addresses are public or private, so from the CPE NAT’s perspective nothing is different. Service providers deploying this architecture do not have to impose special equipment requirements on their customers or require customers to change out existing equipment. Any old NAT will do.

While it is simple, NAT444 is not without issues. One concern common not only to this architecture but any LSN solution is scalability. For a broadband provider, each customer network can represent several devices behind the CPE NAT in a home or perhaps a dozen devices behind the CPE NAT in a small office. And each of those devices can produce multiple application streams. There is not yet enough production experience to know the upper boundaries of how many customer networks a single LSN can handle, either in terms of performance or in terms of mapping steams to a single public IPv4 address. 

An issue particular to NAT444 is the possibility of address overlaps between the customer’s network and the private addresses used by the service provider. For example, if the provider uses addresses out of the 172.16.0.0/12 block between the LSN and the CPE NAT, and the customer addresses his network out of the same block, uniqueness between the two zones is lost and packets might be misrouted. Insuring that customers use non-conflicting address ranges can be an administrative headache for the provider.

Another issue with NAT444 occurs when a customer wants to send packets to another customer behind the same LSN, as illustrated in Figure 2. Filtering policies in firewalls, router ACLs, and even servers often block packets from outside the network that have private source addresses. To circumvent this problem packets must pass through the LSN so that their source addresses can be translated to a public address and then “hairpinned” back through the LSN to the destination. LSN resources are consumed even though the packets are not going to a destination beyond the LSN.

A proposed solution to both of these problems is to set aside a block of the remaining public IPv4 space as an “ISP Shared Address” space. Because the address block would be reserved for use in NAT444 architectures, the same addresses can be used behind different LSNs the same way RFC1918 addresses are used. But because they are not RFC1918 addresses, they won’t conflict with the private addresses in any customer network. And because they are not RFC1918 addresses, they will not be blocked by filtering policies; packet flows between customers behind the same LSN do not have to pass through the LSN.

Another solution to these problems is to use public IPv6 addresses between the LSN and the CPE NATs, as shown in Figure 3. IPv4 packets originating in the customer network are translated into IPv6 packets for the hop between the CPE NAT and the LSN, and then translated back to IPv4 (with a public address) by the LSN. This architecture is NAT464.

There is no chance of address conflicts between the IPv6 address on the outside of the CPE NAT and the IPv4 private addresses on the inside. And assuming that the CPE NAT translates incoming packets to an IPv4 address internal to the local network, there should be no filtering issues effecting communications between two customers behind the same LSN.

NAT464 has the added advantage that the links between the provider and the customer are IPv6 only, rather than dual stacked, so the most of the issue of finding enough IPv4 addresses for customers goes away. And, because it supports IPv4 over IPv6 rather than supporting IPv4 and IPv6 in parallel, it gets us closer to where we eventually want to be: A pure IPv6 network.

While NAT464 simplifies things in the intermediate zone between the LSN and CPE NATs, it is more problematic for the LSN and CPE NATs themselves. The most obvious problem is that both these devices must now be NAT64 – that is, they must translate between the two protocol versions. Very few current CPE NATs support NAT64, so providers adopting this solution are faced with requiring their customers to change their equipment: an administrative and customer relations headache most providers would rather avoid.

More importantly, translation between address families is more complex than simple translation within a single address family, which is reflected in the fact that NAT64 implementations (formerly called NAT-PT) neither perform as well nor scale as well as NAT44. NAT64 implementations have improved, and will continue to improve, but it is unlikely that they will ever be as efficient as NAT44.

A promising compromise is a solution called Dual Stack Lite, which eliminates some of the complexity of NAT464 by using tunneling rather than address family translation. I’ll cover DS-Lite in the next post.

• carrier grade NAT
• CGN
• large scale NAT
• LSN
• NAT
• NAT444
• NAT464
• NAT64