IPv4 Address Exhaustion, a case for CGNAT?

The long-talked-about exhaustion of public Internet IPv4 addresses is now official, one could be tempted to say again. We have heard warnings of the “wolf coming” pretty much over the last decade. Now it is here for real. IPv4 Address Exhaustion, a case for CGNAT? We will answer the question in this article.

The first warning was around the year 2011 were pools of /8 network addresses were no longer available. Recall that a “slash 8” network contains 16M+ addresses. 
Historically the IPv4 address space of 4.3 Billion routable addresses were being managed and allocated for reasonable fees by 5 Regional Internet Registries (RIRs). 
With the explosion of the internet, the shortage progressed and today even the smallest pool (/24) is not directly available. A /24 contains 254 IP addresses and should be a familiar from most home networks.

So what are the implications of this IPv4 address shortage? 

The life of IPv4 which was supposed to be replaced by IPv6 got extended by CIDR, a Classless Inter-Domain routing scheme that improved the allocation of addresses from the standard and wasteful class A, B, C type networks. Also, the introduction of Network Address Translation (NAT) using ports greatly limited the need for public IPv4 addresses, but the number of ports per IP address still limits the growth to match what we are seeing today.

What is an Internet Service Provider to do? There are a few choices. 

Checking the Global Registries for addresses one will find waiting lists consisting of IPv4 address pools that were previously allocated to entities (now reclaimed) or ones that were simply never used. The reclaimed ones go through a 6-month quarantine to flush out prior usage and could still appear on various blacklists resulting in connectivity problems that your organization would have to resolve on its own. At the time this was written /24 blocks can have waiting lists of more than 8 months for certain regions.

The next choice could be to investigate buying or leasing IPv4 addresses from the open market.

A few commercial sites offer blocks of addresses where the going rate for /24 blocks seems to be something in the order of $25.00 per IPv4 address. Leasing is also an option. There are a number of websites offering leases, some having pools of various sizes available. Check their long-term vs. short-term rates and be aware of fees.

Finally, there is a choice of planning for the future and be less dependent on pools of public IPv4 addresses being available, namely CGNAT, also commonly known as Large Scale NAT. A significant benefit of this choice is the built-in preparation for the near future. IPv6 is happening and the need for support of dual-stack environments (IPv4 + IPv6) is fast becoming unavoidable. The growth of IoT devices alone which by their sheer numbers almost dictates the use of IPv6 addresses. IoT devices are often battery-powered and any unnecessary network traffic drains those batteries. Unlike IPv6 which has a number of ways to facilitate dynamically assigning addresses, IPv4 has routine broadcast packets received by all devices in a broadcast domain, adding to the battery drain.

Carrier-Grade NAT provides the ability to share a minimal set of public IPv4 addresses between internal remote sites while providing support for coexisting with IPv6 networks thus mitigating IPv4 address exhaustion.

6WIND is a company that emerged a couple of decades ago with the vision to ease the upcoming transition to IPv6. So, a bit ahead of its time, the focus switched to IPv4 routing, IPSec, and CGNAT all in one router product. The product installs onto most Intel XEON bare-metal servers or into a VM with an underlying hypervisor such as VMware, KVM, etc.

Let’s delve into CGNAT and see some use cases for service providers.

NAT44

Regular IPv4 address translation from a public IPv4 address to a private IPv4 address can be performed by regular routers, including the 6WIND Virtual Border Router without the optional CGNAT module. This obviously helps in conserving public IPv4 addresses. But regular NAT has some limitations with scaling which CGNAT helps overcoming, one issue is limiting mappings per user. There are also concerns relating to pool management, performance, logging/filtering of mappings and a number of applications/protocols that have their IP addresses embedded in the payload, i.e. regular NAT breaks them. CGNAT has ALG support to help overcome this. More about these issues later in the NAT444 section.

NAT64

NAT64 is an evolution of standard NAT that allows communication between IPv4 and IPv6 devices. The 3 main parts to NAT64 are as follows:

• NAT64 prefix
• DNS64 Servers
• NAT64 Routers

A NAT64 prefix can be a network-specific prefix (NSP) or a well-known prefix (WKP). NSPs are assigned to or determined by an organization. The WKP for NAT64 is 64:FF9B::/96. This prefix will be used when translating IPv6 addresses to IPv4 and ensures that the packet is routed to the NAT64 router.

The DNS64 server serves DNS requests in the following manner; if no AAAA is found then an IPv4 A record will be encoded in the AAAA record.

Finally, the NAT64 router advertises the NAT64 prefix into the IPv6-only network and performs the translation between IPv6 and IPv4 networks.

The following picture illustrates the translation process.

This example has an IPv6 only source host that wants to access the destination.com website, which is on an IPv4-only network. The source host will need to obtain an IPv6 address that the NAT64 router can route to the corresponding IPv4 address of the destination. The source host sends an IPv6 DNS request to the DNS64 server. The DNS server may have the AAAA record already or creates an IPv6 address from the A record obtained from the IPv4 network. It does this by converting the obtained IPv4 address into 64:FF9B::0102:0304 in this case. The requesting source host now uses this generated IPv6 address as the destination. The packet is sent to the NAT64 router which now builds the appropriate IPv4 header for the IPv4 network. The packet is forwarded to the destination server and a response with a regular IPv4 header will be returned to the CGNAT server that converts it for transmission to the IPv6 address of the source host.

NAT444

Regular NAT translates one private IPv4 address [RFC1918] to a public IPv4 address. NAT444 is a network model that uses 2 Network Address/Port Translators (NAPTs) and 3 different blocks of IPv4 addresses. Why is this useful? Looking at the diagram below we will see that service providers will have to deal with double NAT’ing. Customer Premise Equipment will NAT from one private IPv4 address (using IP ports) to another that in turn will be NAT’ed to the global routable public IPv4 address.

So as trivial as that seems when NAT’ing scales to large numbers there are real concerns with:

• Port assignments (it fairness of the shared IP addresses between users).
• IP Pool Management (Paired pooling, pool resizing).
• Logging (ISP’s must be able to track IP/port assignments at any given time).
• Mapping/Filtering (Endpoint-Independent, Address & Port Dependent).
• Hairpinning (hosts behind the same NAT device using their mapped endpoints for communication).
• Applications like SIP, H323, ICMP, FTP,  that breaks because IP addresses are embedded in the payload (ALG-support overcomes this).
• Performance for latency-sensitive applications like for instance video gaming and IoT.
• Scaling, a single web session from a user can result in hundreds of connections that each need a mapping (multiple tabs, pop-up windows, commercials, etc.) resulting in millions of connections for large ISPs.

All these issues are addressed with the CGNAT Virtual Border Router. 

Conclusion

Using the 6WIND vRouter with the optional CGNAT module, an ISP can now easily implement both NAT64 and NAT444 functions to connect IPv6 networks to the IPv4 world. This can be done on a massive scale with millions of connections. The end result will be less reliance on the availability of public IPv4 addresses and better support for the rapidly growing number of IoT devices and internet-connected devices in general.

Feel free to request an evaluation as well. We will be happy to hear from you.