There may be a little confusion about the roles of these two technologies. Plus, I have heard a few provider architects’ say “we were thinking of deploying LSN, because we will quickly run short of routable IPv4 addresses, but now we think maybe DNS64/NAT64 would be better”. Both solutions do conserve routable IPv4 addresses provisioned to the subscriber (let’s take the broadband case – specifically cable), but are in other ways very different in how they work and what the relative strengths and weaknesses of the solution are.
I’m going to cover this topic over several posts. For this post, let’s review basic elements of LSN.
Large Scale NAT (LSN) involves Providers assigning non-routable IPv4 addresses to their subscribers (either the subscriber host – say Windows 7 – or more commonly the subscriber’s edge router or Home Gateway (HGW)). The provider then implements, at the edge of their network, the LSN device, which performs IPv4 “Hide NAT” on the non-routable source address of subscriber packets.
As an example, let’s take the case of a subscriber with a Home Gateway (HGW), as shown below. The graphic shows two subscribers – we will focus on the top subscriber. Inside the subscriber home, the network is numbered using 192.168.1.0/24. The subscriber’s HGW provider-facing interface is assigned 10.1.1.3. The HGW performs IPv4 “Hide NAT” on outbound packets. The packet is carried across the provider’s IPv4 infrastructure to the LSN device, where the subscriber-facing interface is assigned 10.5.5.5. The LSN then also performs IPv4 “Hide NAT”, this time to a routable address, 192.0.2.15 (note that address is taken from the “documentation” range for IPv4, and is not really routable, but in a real deployment a routable address would be used).
Therefore this solution is an *all IPv4* solution, and shares a single routable IPv4 address across multiple subscribers. There is no simple rule for deciding how many subscribers can be supported through a single outside routable address, but for this example let’s say we’ve chosen 100 subscribers per routable address. Some key considerations for LSN include:
- Application failure or degradation, where some applications will not run properly, or at all, through the NAT444 mechanism (for example, although the list is longer and growing, some peer-to-peer file sharing solutions, some online gaming, video streaming, and other applications do not work across NAT444). For a comprehensive document with supporting testing, read this excellent IETF draft authored by a number of cable industry IPv6 leaders at http://tools.ietf.org/html/draft-donley-nat444-impacts-04.
- L4 port exhaustion when supporting too many subscribers behind a single routable address, where port-hungry applications (Google Maps is a common example of a single function that opens many L4 connections immediately) use up the shared 64K TCP and 64K UDP ports available for a single routable address
- Blacklisting, where one subscriber performs some action that results in the shared IPv4 address blacklisted, resulting in all 99 other subscribers losing the use of the blacklisted service in addition to the perpetrator
- Some providers are short non-routable IPv4 addresses for use within the provider network, so this is also a constraint
- Any provisioning, logging, billing, lawful intercept, or monitoring systems within the provider environment that assume a “1 routable address = 1 subscriber” scheme will be impacted and will have to be modified to understand the NAT444 solution, and where the amount of stored history on subscriber activity will likely be much larger
- Subscriber service provisioning limitations, where a subscriber would want to host a website using HTTP (TCP port 80), because only one subscriber can have use of that port
- LSN/NAT444 requires no investment at all in IPv6 – in fact it has nothing to do with IPv6
So then, to wrap up this entry, LSN/NAT444 is an IPv4-only solution that allows subscribers to ration their shrinking pool of routable IPv4 addresses. This comes with some functionality limitations for subscribers, and will still require the provider to implement new platforms, new functionality, and will almost certainly impact some provider back-end support systems. No investment in IPv6 is required.
The most likely outcome of LSN implementation by providers is for deployment only in the lowest-cost service tier, where these subscribers can only run “simple applications”. Subscribers that want better service would pay more, and still get a single routable IPv4 address allocation.
By the way, Jeff Doyle wrote an excellent article that takes a deeper look at NAT444/LSN/CGN which I highly recommend (http://www.networkworld.com/community/node/45776).
The next blog entry we will examine how DNS64/NAT64 works and some key considerations with that technology.