In today’s world of connected refrigerators, thermostats, cars, and phones, IP addresses are in high demand. IPv6 was invented to solve this problem, but the radical departure from the IPv4 standard has made it slow to adopt. This problem isn’t going away any time soon either: Cisco forecasts that by 2021, the average North American consumer will own 13 connected devices. Publicly addressing each device in North America alone would consume 3,780,000,000 of the 4,294,967,296 IPv4 addresses, or about 90% of the global total of IPv4 addresses available.
So without a complete migration to IPv6, how do service providers keep up?
CGNAT
Carrier Grade Network Address Translation (CGNAT) allows providers to offer customers access to the publicly routable internet space on a limited budget of addresses.
For example, your home router runs DHCP, leasing private addresses to devices from a limited pool. Then the router performs Port Address Translation (PAT) to map all of the internal addresses to one public IP assigned to your house by the service provider.
Without CGNAT, local PAT only moves the address shortage problem up to the provider. Now a provider would have to have a public IP available for each household. This is unsustainable, as current estimates put global internet penetration at the household level around 45%. So how does CGNAT solve this problem?
We just NAT again!
Often referred to as NAT444, CGNAT allows carriers to run NAT between multiple households and a single public address. Now the carrier can offer the end customer a private address and NAT multiple households behind a single publicly routed IP.
Another benefit of using CGNAT is the possibility of seamless communication between networks using different versions of the IP protocol. These types of NAT are called NAT64 or NAT464. In NAT64, IPv6 addresses are mapped into IPv4 addresses that are either publicly routable or now translated into an IPv4 network.
How can we get visibility into NAT?
Whether used for large-scale NAT or IP version translation, these types of NAT can be difficult to work with without visibility into your network traffic. Using a solution like Scrutinizer, we can collect network infrastructure metadata and use it to correlate events like NAT translations with the network traffic flows. Often while doing research, we will trace a flow back to an IP that is from a NAT pool. Without capturing NAT event data, it can be laborious to figure out possible endpoints that could have been translated through the address found in the flow.
With NetFlow/IPFIX data from a device like the Cisco ASA, we can look at the flow properties both behind and in front of your NAT. CGNAT visibility works the same; effectively, it’s just a second layer of address translation. Using Scrutinizer, you can easily see network utilization as it is attributed to NAT consumers.
In Scrutinizer, you can tell if a device is supplying NAT information by clicking into the reporting menu. If we have parsed NAT-centric elements, a ‘NAT’ reporting group will become available for selection. As you can see from the image below, we can display NAT details in a few different contexts. Some are source- or destination-oriented, while others show all details.
For example, the ‘NAT > Src Translations’ report gives us quick visibility into how source addresses are being NAT’d. In the case of CGNAT, this type of view would show us which subscriber is NAT’d to which public IP. We can now roll back the clock and see how things were translated an hour/day/week/month ago.
Are you losing track of traffic when it goes through your NAT? Are you using NAT to move traffic between networks with different IP versions? Then you need the ability to collect network metadata from your infrastructure and correlate it to NAT events using a tool like Scrutinizer. Check out other networking problems that can be solved with network infrastructure metadata in our blog on Cisco ASA NAT reports!
