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.
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).
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.
Public Telecomm Solves IPv4 Exhaustion & Saves ~$2 Million
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
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:
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
This research was conducted to understand the challenges and issues facing communications service providers when it comes to the lasting impact that COVID-19 has had on their subscribers and enterprises. It identifies trends in demand and usage patterns, expectations around security and resiliency in what has been an unprecedented year. It examines communications service providers’ plans for investment, adoption of new technologies, and the complexity of operating in the current hybrid environment.
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 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 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:
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.
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.
The advent of new Internet-connected locations and Internet-connected devices has precipitated IPv4 exhaustion, because each device places greater pressure on the existing IPv4 infrastructure. Learn about various techniques for IPv6 Migration, IPv4 Preservation and IPv4/IPv6 Translation.
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”.
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.
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.
Exponential subscriber growth and connected IoT devices has forced service providers to investing in infrastructure to support increased traffic. With the global IPv4 exhaustion and the adoption of IPv6, service providers are facing challenges in sustaining growth and business continuity. This white paper provides an overview of the various components that are required for a CGNAT and IPv6 migration solution.
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:
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:
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.
How much is growth in subscribers or locations going to cost you in the next 5 years for additional IPv4 addresses?Estimate Your IPv4 Costs Now