To LSN or Not to LSN?
While everyone is talking about IPv6 in light of the IPv4 address space depletion – driven by the increasing demand for mobile and hand-held data services – the actual transition into pure-IPv6 networks and equipments takes place rather more slowly. There are several reasons for that, while the prominent one is cost: Large carriers and ISPs that made enormous investments in their currently deployed IPv4 infrastructure (servers, switches, routers, firewalls, etc.) are not keen to replace this entire equipment at once due to the massive investment that needs to be made. The decision to delay the transition into IPv6 equipment is also driven by the fact that although IPv6 end-user devices become more popular, there is still a large portion of clients that use IPv4 stacks – giving a partial justification to keep the good, old IPv4 equipment.
Nevertheless, these carriers and ISPs cannot stay behind and must also be able to support IPv6 clients – while at the same time address IPv4 clients. So how can this emerging issue be resolved cost-effectively?
Carrier Grade NAT (CGN) or Large Scale NAT (LSN) is an approach which addresses the above pain point; it does that by moving the process of Network Address Translation (NAT – discussed more below) into the carrier network from its previous (classic) domain – the customer premises. In other words, LSN/CGN enables to better utilize public IPv4 addresses by sharing it between several subscribers (using different source ports) while using private IPv4 addresses or IPv6 addresses at the carrier access network. The result: more public IP services can be provided thanks to the NAT which takes place at the carrier end.
The Plot Thickens: Along Came IPv6
Network Address Translation (NAT), or NAT44 (named so as it translates a private IPv4 address to a public IPv4 address), is a common service in most border routers (at your office, and even at your home!). But as its name implies, it can process only IPv4 addresses. So the deployment of IPv6 clients and hosts adds much more complexity into the equation – meaning that NAT needs to now support a mixture of both IPv4 and IPv6 addresses.
As a result, several approaches evolved in addition to LSN/CGN, including NAT 64, NAT 444, DS-Lite and more. Here is a brief explanation what each means:
- NAT64 – enables IPv6 clients to interoperate with IPv4 servers. A similar DNS64 mechanism also exists, which does the same task for DNS queries
- NAT 444 – combines CGN plus NAT44 (the latter takes place at the customer premises equipment); this means that the client’s request will go through two translations as it moves from the client’s own private network to the carrier’s private network and then to the public Internet.
- Dual-Stack Lite (DS-Lite) – which combines NAT44 and 4-over-6 tunnel; in other words it means that it reduces the overhead upon translating between the two protocols by encapsulating the IPv4 packets into IPv6, leaving native IPv6 packets untouched.
Into the great wide open…
Today, while GGSNs support dual IPv4/IPv6 stacks, they support neither NAT64 nor NAT44; the question remains partially unanswered in next-generation PGW (PDN Gateways) planned to be deployed in LTE/4G networks. But in reality, some LSN/CGN solutions start to be offered on top of firewalls, routers and ADCs. So where does an LSN/CGN solution best fit in the carrier network? The answer stays open as it depends on the carrier’s scalability and capacity needs; in any case it requires deeper examination of the carrier’s goals and requirements – and how much is it ready to invest today – versus in the future.