What is Carrier-grade NAT (CGN/CGNAT)?
Way back in the early days of the internet (the 1980s) every connected computer was intended to have its own unique public IP address. IP addressing was originally defined by four octets—four groups of eight bits, a standard called IPv4—which resulted in over four billion unique values (actually, 4,294,967,296), so at the time it seemed we’d never run out.
IPv4 Exhaustion and Network Address Translation
Fast forward to June 1992 and, as a result of the astounding growth of the internet, RFC 1338, Supernetting: an Address Assignment and Aggregation Strategy, was published. This memo was the first to discuss the consequences of the “eventual exhaustion of the 32-bit IP address space.” Two years later RFC 1631, The IP Network Address Translator (NAT), was published which proposed a solution:
Until the long-term solutions are ready, an easy way to hold down the demand for IP addresses is through address reuse. This solution takes advantage of the fact that a very small percentage of hosts in a stub domain are communicating outside of the domain at any given time. (A stub domain is a domain, such as a corporate network, that only handles traffic originated or destined to hosts in the domain). Indeed, many (if not most) hosts never communicate outside of their stub domain. Because of this, only a subset of the IP addresses inside a stub domain, need be translated into IP addresses that are globally unique when outside communications is required.
IPv4 vs. IPv6 and IPv6 Transition
The successor to IPv4 and the solution to IPv4 address exhaustion, a system called IPv6, became a draft standard (RFC 2460) in 1998. This protocol provided an address space of 128 bits (a total of 3.4×1038 addresses) but it wasn’t until July 2017, 19 years later, that the Internet Engineering Task Force (IETF) declared it an internet standard (RFC 8200).
Standard NAT, which maps multiple stub domain internal addresses to a single global public address and vice versa, worked fine for consumer and corporate point solutions but the needs of large organizations and internet service providers (ISPs) are on a different scale, hence the development of carrier-grade network address translation (shortened to “CGN” or “CGNAT”) also known as large-scale NAT (LSN).
Carrier-grade NAT is an enhancement of traditional network address translation (NAT) technology and the impetus to adopt CGNAT is mainly due to its ability to share a global IP address among multiple remote sites, handle IPv4 exhaustion, and provide a path for migrating to IPv6.
Standard NAT and IPv4 Addresses
The original design of network address translation allows multiple end customers to use any private address range for their internal networks. To route internal hosts to external hosts, a NAT service translates private IP addresses to public IP addresses. When the routing is between IPv4 networks the technology is referred to as NAT44 for network address translation from IPv4 to IPv4 addresses. The diagram below depicts a simplified diagram of a Customer Premises Equipment (CPE) gateway with NAT translating private addresses to public addresses.
NAT deployments soon expanded beyond business networks to other network customers including home and mobile networks. Each customer CPE required a public IP address and as consumer adoption quickly escalated the problem of internet IPv4 exhaustion became dire. As a result, internet service providers required a technology to stretch the limited pool of Public IP addresses even further thus carrier-grade NAT was developed.
CGNAT vs. NAT for Service Providers
Standard NAT or NAT44 translates a private IPv4 address to public IPv4 address. NAT444 translates private IPv4 addresses to private IPv4 addresses then to public IPv4 addresses so ISPs using CGNAT were able to replace the public IPv4 address on a CPE with their own private IPv4 addresses and then, at the ISP’s interconnect to the internet, use a public IPv4 address. The result of a NAT444 (private, private, public) was multiple customer networks all sharing a common public IPv4 address.
The diagram below shows a deployment of NAT444 (private, private, public) with three customer networks all using the same internal IPv4 address spaces with external IPv4 addresses that are private to the ISP sharing a single public IPv4 address.
While handling IPv4 exhaustion is conceptually simple, doing so at scale can be complicated which is where A10’s expertise in large-scale NAT (LSN) is invaluable; see the case study Uber Solves IPv4 Exhaustion at Scale.
NAT64 and Migrating to IPv6
NAT64 is a technology that allows IPv6-only clients to access legacy IPv4-only services. The NAT64 device acts as a gateway for the client’s DNS requests (using DNS64) and translates IPv4 DNS responses into IPv6 DNS responses when needed.
For more information about the IPv6 transition for carriers, refer to the Internet Engineering Task Force (IETF) specification An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition.
IP was originally designed according to the end-to-end principle for networking. This means that application protocols may expect to communicate directly between hosts without intermediate systems modifying the packet headers or payload. As NAT modifies the IP addresses at the very least and sometimes has to alter other packet headers and payloads then NAT can break these protocols.
Application level gateway (ALG) was developed to solve the problem of breaking protocols by intelligently modifying the packet headers and payloads to conform to the protocol.
CGNAT also provides transparent NAT connectivity for as Endpoint Independent Mapping (EIM), Endpoint Independent Filtering (EIF), and hairpinning. Traditional NAT implementations do not allow any traffic that is initiated from the outside (EIM, EIF) or for protocols that need to hairpin, i.e. loop their traffic back to the inside.
Application Level Gateway and CGNAT
Carrier-grade NAT performs the same NAT functions as standard NAT and so it will also cause the same network protocol problems making ALG a critical function for any large-scale NAT (LSN) solution.
Carrier Requirements for Carrier-grade NAT
Carrier networks, large enterprises, and ISPs require far more sophisticated CGNAT capabilities than consumer and small business networks because along with dealing with IPv4 exhaustion they also have critical performance, reliability, and manageability requirements.
- Performance – Carrier-grade NAT solutions must support millions of simultaneous network connections
- Scale-out – Carrier solutions must be able to scale dynamically, adding additional throughput as needed without interrupting existing network traffic
- High Availability – Carrier-grade NAT solutions require 24/7 uptime without downtime for component failures or upgrades
- Central Management – Large-scale NAT (LSN) solutions must integrate with any of the major central network management platforms and DevOps infrastructures using Restful API capabilities
- Advanced Logging – Because the local private IP address is not shown to the public internet, logs are another major aspect of CGN that have to be considered. All devices that connect to the internet produce a multitude of sessions. Tracking all sessions produces a vast amount of log messages. A carrier-grade NAT service must provide advanced techniques that help reduce the volume of logs, such as port batching, zero-logging, compact logging and others
Additional Service Provider Requirements
Internet service providers and mobile network providers have additional requirements when it comes to supporting vast numbers of subscribers in incredibly complex network infrastructures.
- Subscriber Awareness – A complete carrier-grade NAT solution for this market will provide visibility into the data flows down to the level of individual network subscribers to manage and track their services use
- User Quotas – The ability of an administrator to limit the amount of TCP and UDP ports that can be used by a single subscriber is crucial in ISP/MNP environments to maintain fairness in sharing resources among subscribers. IoT botnets used in Distributed Denial of Service (DDoS) attacks use a large amount of connections per end device, which rapidly depletes port availability. If left unmanaged, the connectivity for other subscribers can be easily compromised by external attackers
- DNS64 Support – To make migrating to ipv6 easier, support for DNS64 is absolutely required.
Carrier-grade NAT as a Lifecycle Strategy
Service providers will need to implement an address translation strategy that includes both a short-term plan to address the preservation of their existing IPv4 address allocation, and a long-term plan to seamlessly migrate to an IPv6 infrastructure.
This approach will require a solution that not only provides a robust set of carrier-grade network address translation large-scale NAT (LSN) capabilities — and migrating to IPv6 options based on each service provider’s existing infrastructure — but one that also addresses the entire lifecycle of the transition from IPv4 to IPv6.
A10’s white paper, CGNAT Isn’t a Capability, It’s a Lifecycle Strategy, is an overview of the various components that are required to handle IPv4 exhaustion and deliver a complete CGNAT solution that makes migrating to IPv6 simple and straightforward.
How A10 Networks Can Help
A10 customers worldwide have successfully deployed A10’s CGNAT solution as part of their strategy for migrating to IPv6. For example, a deployment at one of the nation’s largest mobile carriers uses A10’s CGNAT solution to maintain IPv4 connectivity for their ever-growing mobile and smartphone user base. A10’s DDoS appliances provide a feature-rich CGNAT solution with high availability because of active session synchronization (the ability for multiple appliances to track sessions so that failover to a less trafficked route can be made in the case of a DDoS attack or service outage).
A10 devices leave the competition behind with large number of features supported, superior processing power while being extremely cost-efficient (typically 10x to 100x lower cost per subscriber versus traditional network vendors). A single A10 device provides more power than multiple hyper-expensive chassis-based processing cards that are part of large networking vendors’ NAT solutions.
More features and more power out of the box means A10’s CGNAT solution can fit in and adapt to any growing network. A10 devices can be clustered combining processing power with simple management.
Learn more about the A10 Thunder® Carrier Grade Networking (CGN) solution for IPv4 preservation and migrating to IPv6.