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.
By late 1980’s, however, it became apparent that the dramatic adoption rate of the internet would eventually deplete this large pool of addresses. IPv6 was envisioned as a successor protocol to IPv4 and would solve the limited address space. However, IPv6 was not made to be backward compatible, and the problem of limited addresses still became an issue. Carrier Grade NAT (CGNAT) was created as a solution to address this problem, primarily for service providers.
IPv4 Exhaustion – The History
In June 1992, 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.
A protocol called IPv6, became a draft standard (RFC 2460) in 1998, as the successor to IPv4 and the long-term solution to IPv4 address exhaustion. This protocol provided an address space of 128 bits (a total of 3.4×1038 addresses – approximately 340 trillion trillion) 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 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.
Standard Network Address Translation – Translating Private IP to Public IP Addresses
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 NAT deployments soon expanded beyond business networks to include home and mobile networks. As each customer CPE or mobile device required a public IP address and as consumer adoption quickly escalated, the problem of internet IPv4 exhaustion became dire.
Carrier Grade Network Address Translation (CGNAT)
As a result, service providers, including ISPs, broadband cable, and mobile operators, soon required a technology to stretch the limited pool of Public IP addresses even further and to meet some unique performance and feature requirements. The IETF Network Working Group began analyzing this problem and beginning in 2009, published a series of “Request for Comment” (RFCs) to enhance traditional network address translation (NAT).
The IETF RFCs provided recommendations, identified deployment limitations and requirements for “carrier grade NAT” also called large scale NAT (LSN) or NAT 444. Today, carrier grade NAT (CGNAT) is a mature technology whose operation is well standardized by IETF RFCs and draft documents.
Common Deployment Scenarios for NAT44 and NAT444
CGNAT for Service Providers
While standard NAT translates a private IPv4 address to public IPv4 address, Carrier Grade NAT (CGNAT) adds an additional translation layer. This allows ISPs to preserve their own public IPv4 addresses, process subscriber traffic through the service provider’s private IPv4 network and support subscribers or businesses that also have their own private IPv4 networks, and multiple locations or devices. Typically, Carrier Grade NAT (CGNAT) is used in a NAT 444 scenario, which translates:
- (Customer) Private IPv4 to (ISP) Private IPv4 network address
- (ISP) Private IPv4 network address to (ISP) Public IPv4 network address, for connection to the internet
The result of a NAT444 (private to private to public) deployment is that it allows multiple customer networks with their own internal network address space to route through the ISP’s internal network address space and share the ISPs single public Internet IPv4 address for access to the Internet
The diagram below shows a deployment of NAT444 (private, private, public) with three customer networks all using the same internal IPv4 address space with external IPv4 addresses that are private to the ISP sharing a single public IPv4 address.
CGNAT implementation of NAT444 with private to private to public Network Address Translation
While handling IPv4 exhaustion is conceptually simple, doing so at scale can be complicated which is where A10’s expertise in Carrier Grade NAT (CGNAT) is invaluable. A10 solution is compliant with industry standards and also offers enhancements for simplified operations. 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.
Advantages of Carrier Grade NAT
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 alters other protocol headers and payloads, NAT can break the communications. Carrier Grade NAT (CGNAT) solves this and other problems associated with using traditional NAT at scale with the inclusion of the following capabilities:
- Application level gateway (ALG) was developed to solve the problem of NAT servers breaking communications. Based on proxy server technology, ALGs intelligently modify necessary application protocol headers and payloads to conform to the protocol being routed by the NAT.
- Endpoint Independent Mapping (EIM), Endpoint Independent Filtering (EIF), and hairpinning provides transparent NAT connectivity. 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.
High Scale Requirements for Service Providers
Carrier networks, large enterprises, higher education institutions and ISPs require far more sophisticated Carrier Grade NAT (CGNAT) capabilities than consumer and small business networks because 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 very high availability 24/7 with no service disruption for the user. This requires seamless failover in the event of any component failures with session preservation
- Central Management – Large-scale NAT / Carrier Grade NAT solutions must be capable of integration with major central network management platforms and DevOps infrastructures for centralized logging
- Advanced Logging – All devices that connect to the Internet produce a multitude of sessions so tracking all sessions produces a vast amount of log messages. Carrier Grade NAT solutions must provide advanced techniques to reduce the volume of logs, such as port batching, zero-logging, and compact logging as well as filtering to provide relevant, actionable insights
- Security – Absolutely crucial to CGNAT deployments is the requirement for specific in-depth security and defenses against assaults such as Distributed Denial of Service (DDoS) attacks targeted at CGNAT pools
- 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 and Mobile Network Provider (MNP) environments to maintain fairness in sharing resources among subscribers. If left unmanaged, the connectivity for other subscribers can be easily compromised by external attackers
Migrating to IPv6
IPv6 was introduced as a draft standard by the IETF in December 1998 to solve the IPv4 exhaustion problem and was fully ratified in July 2017. Since its introduction, globally IPv6 adoption has progressively increased across devices, service provider networks, and content providers, but with quite a bit of geographic differences by country.
Mobile operators, ISPs and mobile device manufacturers have led adoption and the more recent generations of mobile devices (4G/5G) support both IPv4 and IPv6. Major web content providers such as Google, Alexa, Facebook, Yahoo, YouTube, and others have all deployed IPv6. Enterprise have generally been slower to move to IPv6, due largely to the cost of changing existing network infrastructure, but adoption is accelerating.
However, there are still large numbers of websites, devices and networks that are primarily IPv4 and most service providers, education institutions and enterprise have to support connectivity between both IPv4 and IPv6 for their users and subscribers, even when their own networks have been fully migrated to IPv6. As a result of this hybrid environment, several technologies have emerged that help this transition process and enables connectivity between IPv4 and IPv6 devices, networks, and Internet destinations. These technologies either translate between IPv4 and IPv6 addresses or encapsulate traffic to enable passage through the incompatible network. These technologies are listed below:
|Technology||Type||Subscriber Device||Service Provider Network||Web Destination (Internet)|
(NAT64 + client CLAT)
Mobile network operators often combine Carrier Grade NAT (CGNAT) with firewall to provide strong protection for both their IPv4 and IPv6 subscribers. See the case study, “Middle East Telecom Giant Scales out Security with A10 Networks Thunder CFW”.
Migration to IPv6: NAT64 Example
NAT64 allows IPv6-only devices to access legacy IPv4-only services by transparently translating IPv6 addresses into IPv4 addresses and vice versa. But NAT64 is only part of the solution because IPv6-only devices also need to make DNS queries to resolve the IP addresses of other devices. The answer is to use a DNS64 server on the internal IPv6 network.
NAT64/DNS64 uses a protocol translation approach, versus an encapsulation approach, to connect IPv6 users to IPv4 services. This allows data only available via IPv4 to be retrieved and returned to an IPv6 client.
A DNS64 server accepts an IPv6 DNS request and if no IPv6 address for the target host is available, transforms the target’s existing IPv4 address into a synthetic IPv6 address which encapsulates the IPv4 address for the client’s DNS requests (using DNS64) and translates IPv4 DNS responses into IPv6 DNS responses when needed.
The IPv6 client can then connect to the synthetic IPv6 address via the NAT64 gateway which converts the request into the correct IPv4 address and, when data is returned via IPv4, converts the response back to IPv6. The IPv6 clients see nothing but IPv6.
Carrier Grade NAT as a Lifecycle Strategy
Service providers need to implement a network 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 requires a solution that provides a robust set of Carrier Grade Network Address Translation capabilities and 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 Carrier Grade NAT (CGNAT) solution. The A10 Networks deployment guide also provides configuration details on the various configuration options for large scale NAT.
CGNAT or LSN have been successfully deployed in large service provider, enterprise, and higher education institution networks for many years. Combined with the IPv6 migration technologies identified previously in a robust CGN solution, such as offered by A10 Networks, Carrier Grade NAT (CGNAT) provides a well proven method for leveraging existing investment in IPv4 while providing seamless migration path to IPv6 for subscribers and users. Carrier Grade NAT (CGNAT) includes several capabilities that overcome limitations in standard NAT and make it successful for large scale, carrier deployments.
Through the work of the IETF Network Working Group and CGN vendors such as A10 Networks, Carrier Grade NAT has allowed service providers to share their scarce public IPv4 address among multiple and growing subscribers, and thus handle IPv4 exhaustion and preservation while providing a migration path for IPv6. These RFCs and others formalize Carrier Grade NAT (CGNAT) behavior and facilitate future application development:
- CGN (draft-nishitani-cgn-05)
- An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition (RFC 6264)
- Issues with IP Address Sharing (RFC 6269)
- Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion (RFC 6333)
- IANA-Reserved IPv4 Prefix for Shared Address Space (RFC 6598)
- 464XLAT: Combination of Stateful and Stateless Translation (RFC 6877)
How A10 Networks Can Help
A10 customers worldwide have successfully deployed A10 Thunder CGN for CGNAT as well as IPv6 migration features. This technology is available in bare metal, container, virtual and physical form factors to meet all network deployment scenarios at scale. 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. Another leading tier one mobile operator in South Korea deployed A10 Thunder CFW, including CGNAT as part of its 5G roll out.
A10 Thunder CGN solutions provide a feature-rich Carrier Grade NAT (CGNAT) solution, compliant with industry standards and also offers enhancements for simplified operations. For example, with high availability due to active session synchronization technology (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 Thunder CGN provide a complete Carrier Grade NAT solution with superior processing power while being extremely cost-efficient (typically 10x to 100x lower cost per subscriber versus traditional network vendors). A single A10 hardware appliance provides more power than multiple hyper-expensive chassis-based processing cards that are part of large networking vendors’ NAT solutions.
Standard features in A10 Networks Thunder CGN solution include:
- 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
- High Transparency – A10 Thunder CGN implements several features to provide a seamless user experience across a NAT environment. These features provide a transparent client access environment to outside resources, thus ensuring that both client-server and peer-to-peer applications continue to function as designed:
- Endpoint Independent Mapping (EIM)
- Endpoint-Independent Filtering (EIF), address pooling, hairpinning and port preservation.
- Fairness and Resource Sharing – The A10 Thunder CGN provides limits at both session and user levels to control the amount of allocated resources. This ensures that resources are distributed fairly across the user base in accordance with the service provider’s requirements
- Log File Size Management – A10 Thunder CGN implementation provides many logging techniques to limit both the number of log entries and their size
More features and more power out of the box means A10 Thunder CGN 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.
Implement a Complete Carrier Grade NAT (CGNAT) Solution
A10 Network’s Thunder® Carrier Grade Networking (CGN) provides a complete Carrier Grade NAT solution with superior processing power while being extremely cost-efficientLearn More