In 2011, the Internet Assigned Numbers Authority (IANA) issued the last remaining /8 address blocks to the Regional Internet Registries (RIR), leaving the RIRs in control of assigning the remainder of the available IPv4 addresses. This increases the difficulty for Internet Service Providers (ISPs) to continue to obtain unallocated IPv4 address space, forcing a plan of action both to preserve the remaining IPv4 address space and to provide a mechanism for IPv6 translation. Many technologies have emerged to solve this problem, including NAT444, DS-Lite, and 6rd; all of which are based upon a common foundation of Carrier Grade Network Address Translation (CGN).
The Solution
ARKITEK’s solution on CGNAT provides a reliable path for Commercial Operators (Fixed and Mobile Subscribers) and large-enterprises to implement CGNAT – including an overview of the solution, design and scaling considerations, and an explanation of system configuration, optional features, and traffic logging.
Note: CGN also is sometimes called Large Scale NAT (LSN), and is the term used in the IETF documents referenced on this page.
Solution Overview
CGN provides a methodology for preserving IPv4 addresses by centralizing the public address resources and sharing those resources across a large user community.
CGN general architecture consists of an access network (addressed with RFC 6598 reserved address 100.64.0.0/10), an aggregation routing layer, CGN devices, and peering routers egressing to the public Internet. For business or residential customers that are directly connected to the access network, there is only one level of NAT (NAT44) required. These customers receive an address directly from the 100.64.0.0/10 subnet. Typically, residential customers deploy a gateway device that implements NAT, creating the NAT444 model. The clients use private addresses from the RFC 1918 IP address space. The private addresses are translated into addresses in the 100.64.0.0/10 subnet, which is configured within the ISP access infrastructure. Client (end-user) traffic then is routed through an aggregation layer to the assigned CGN device, and then translated into IPv4 public addresses. CGN deployment is transparent to end-users and requires no configuration changes to customer-premise equipment (CPE) or hosts.
CGN offers the following advantages over traditional NAT operations:
High Transparency
CGN implements several features to provide a seamless user experience across a NAT environment, including Endpoint-independent Mapping (EIM), Endpoint-independent Filtering (EIF), address pooling, hair-pinning, and port preservation. These features provide a transparent client access environment to outside resources, thus insuring that both client-server and peer-to- peer applications continue to function as designed.
Well-Defined Behavior
CGN is a mature technology whose operation is well standardized by several IETF RFCs and draft documents, including the following (links open in new window):
- BEHAVE-TCP (RFC 5382 and RFC 7857)
- BEHAVE-UDP (RFC 4787 and RFC 6888)
- BEHAVE-ICMP (RFC 5508)
- CGN (draft-nishitani-cgn-05)
These RFCs provide a foundation for application transparency and they formalize CGN behavior to facilitate future application development.
Fairness and Resource Sharing
Our CGN implementation provides limits at both session and user levels in order 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
CGN implementations can create large amounts of logging data in service provider networks. Configuring and fine-tuning the NAT equipment, many logging techniques can be implemented to limit both the number of log entries and their size.
Commercial References
Our solution is currently implemented and serving fixed and mobile subscribers in Turkey, on TURKCELL (mobile operator with 35M subscribers), TURKCELL SUPERONLINE (fixed operator with 2M subscribers), Turk Telekom Mobile (formerly AVEA / mobile operator with 20M subscribers), DSMART (fixed operator with 400K subscribers) and Millenicom (fixed operator with 200K subscribers).
Complementary Solutions
When implementing CGNAT in commercial operators; local regulatory authority(ies) may require operators to log address translations, correlate this data with subscriber identity information, and to provide a search facility to be able to identify a subscriber using specific public IP address (and port range) at given time/date interval.
We can work with you to build carrier-grade logging, data correlation and search tool, based on local laws and regulatory authority specific requirements.