Techniques for Prolonging the Lifespan of IPv4

May the road rise up to meet you, may the wind be ever at your back and may you outlive IPv4

IPv6 proponents have long been predicting the death of IPv4 to get the industry to recognize the importance of IPv6. Although IPv4 address exhaustion has occurred, many organizations are still uncertain about the next steps. It is clear that IPv4 is going to be with us for decades to come and there are strategies to prolong the lifespan of IPv4. Are these strategies worthwhile or are they distracting and confusing the industry from moving to IPv6?

For many years the networking industry has been in denial of IPv4 address depletion. It is clear that we are completely dependent on IP communications and IPv4 address depletion is imminent. If we understand the total number of things on the Earth that may be connected to the Internet we can estimate the number of IP addresses we need.

For example, the news media has been running many stories lately on the fact that we are approaching 7 billion people. If we only have 4.2 billion IPv4 addresses, then we can easily see that not everyone can have their very own public IPv4 address.

The other statistic to keep an eye on is the worldwide literacy rate. People who cannot read and write their native language will not easily be able to use the Internet. If you estimate that the world illiteracy rate is 15% that means that over 1 billion people will not be using the Internet anytime soon.

I was also surprised to discover that the total number of mobile phones on the planet is approximately 5 billion. The number of smartphones is rapidly increasing and each of those phones will need an IP address.

Other statistics that give an idea of the world population that may use the Internet is the number of people who have access to safe drinking water and the number of people who have electricity to their homes. If you don't have drinking water or electricity you probably aren't interested in the Internet.

Regardless, it is clear that the Internet-connected population is expanding and the number of devices that use IP is growing. John Curran, President and CEO of ARIN, gave a presentation at the September Texas IPv6 Summit titled "Ready or not...IPv6 is here".

Curran's presentation covered information about IPv4 address exhaustion and prescribed an action plan. The facts are that the IANA free pool was exhausted in February of 2011 and APNIC has run out of IPv4 addresses. RIPE may run out of IPv4 addresses in the next six months while ARIN has prolonged its date for IPv4 exhaustion due to extreme conservation of IPv4 addresses. LACNIC and AFRNIC will not run out of IPv4 addresses for a few years.

It is clear that the world will run out of public IPv4 addresses, it is just a matter of exactly when that will happen. The lack of public IPv4 addresses is starting to hamper innovation. If we had more IPv4 addresses, systems like sensor networks and smartgrid technologies would be growing faster.

What if a company wanted to create a system that made cars function as mobile Wi-Fi hotspots with 4G uplinks? Besides the issues with distracted drivers, we simply do not have enough IPv4 addresses to make this possible.

I have heard some people say that cloud computing is not taking off because of lack of public IP addresses. Some large networks are even running out of private IPv4 addresses. If there is a system that needs a large amount of IP addresses then IPv6 may be the only alternative.

We are in a very awkward time in the Internet's history because we have exhausted all the IPv4 addresses but we have not fully deployed IPv6 yet. The industry has basically waited until the last minute to migrate to IPv6. Therefore, we are all going to enjoy the last-minute pain of transitioning in a short period of time.

Instead of being able to transition to IPv6 slowly and methodically we are going to do it quickly. Like Seinfeld famously said in "The Ex-Girlfriend" episode, "You should just do it like a Band-Aid. One motion! Right off! ..."

It may sound painful to transition to IPv6 rapidly, but the longer we wait, the more pain we may experience.

Geoff Huston, Chief Scientist, Asia Pacific Network Information Centre (APNIC), has been writing and presenting on some insightful thoughts on the transition of IP protocols. The March 2011 The Internet Protocol Journal (Volume 14, Number 1) had an article on World IPv6 Day and its contents are almost completely IPv6-related. Geoff Huston wrote two articles "Transitional Myths" and "Transitioning Protocols" about all the methods of transitioning from IPv4 to IPv6.

Recently, Geoff Huston posted a similar article about the transition to IPv6 titled "IPv6 Transitional Uncertainties". Geoff Huston wrote about a variety of these techniques in his The Internet Protocol Journal, Volume 13, No.2 titled "NAT++: Address Sharing in IPv4". Geoff Huston also gave a presentation at NANOG53 titled "Keynote: A Progress Report on IPv4 Address Exhaustion".

These articles provide an objective look at where we are heading, the dangers of inaction, and the issues facing adoption of IPv6. Even though there is a large portion of the Internet backbone that supports IPv6 and most of the end-user computers run dual-protocol-capable operating systems, there are few broadband ISPs providing native IPv6 services to their subscribers and there are few content providers offering their content over IPv6.

It is apparent that we will have IPv4-only systems in our environments for decades to come. Due to the issues facing IPv6 adoption and our dependency on IPv4, the industry has come up with many gyrations to prolong the lifespan of IPv4 and slowly move to IPv6.

IPv4 Address Efficiency

One strategy of prolonging IPv4 is to continue to use IPv4 but increase the efficient use of those precious addresses. Many large ISPs are spending considerable time with IP address reclamation projects to find blocks of unused IPv4 address blocks and repurpose them in the network.  Enterprises continue to break up their IPv4 blocks into smaller and smaller subnets and increase their use of NAT/PAT.  

Many organizations feel that "we have plenty of IPv4 addresses for our needs" and therefore, IPv6 holds no interest or provides them no benefit. The question is; do these organizations have enough IPv4 addresses to sustain their businesses for the next 20 years?

You could always just purchase/lease more IPv4 addresses from your service provider. You could purchase IPv4 addresses from an organization willing to sell some of theirs and perform an "address transfer".

For example, ARIN provides a process for performing an address transfer. ARIN also approves several organization to perform address transfers, also calls Specialized Transfer Listing Service (STLS).

In the meantime there are plenty of people trying to predict the future. There was an interesting presentation given at NANOG53 titled "Economics of IPv4 Address Markets on IPv6 Deployment", by Andrew Dul, Cascadeo Corp. This presentation gave several economic models as to the depletion of IPv4 addresses and the adoption of IPv6. This presentation mentions the Hotelling's Rule which predicts the price and timing for the exhaustion of a finite resource like public IPv4 addresses.

It is clear that over time the cost of running an IPv4 network will increase. Putting forth effort to prolong the lifespan of IPv4 will add to these costs. Organizations may also re-arrange their use of public IPv4 addresses. IPv4 address reclamation activities are just "rearranging deck chairs on the Titanic". Time would be better spent furthering the deployment of IPv6. However, the reality is that organizations will be maintaining IPv4 and IPv6 networks simultaneously for many years so they have no choice but to increase the efficiency of IPv4. Because we have waited until the last possible minute to deploy IPv6 we are going to come with all kinds of creative ways to avoid having to continue to use IPv4 with the least amount of effort.

Carrier Grade NAT (CGN), Large Scale NAT (LSN), NAT444

Another technique to prolong the lifespan of IPv4 is to perform multiple layers of Network Address Translation (NAT)/Port Address Translation (PAT). This is a technique where there is one instance of NAT44 (translating an IPv4 address into another IPv4 address) is used by the broadband internet access subscriber CPE device at their location.

The subscriber has private IPv4 addresses inside their home and get a private IPv4 address for the external interface of their broadband access device. The service provider will use private IPv4 addresses in their core and use a CGN/LSN/NAT444 device in their core to NAT/PAT many private-addressed customers to a smaller pool of public IPv4 addresses.

This technique is sometimes referred to NAT444 because there are 2 levels of NAT/PAT being performed. This method works, but there are issues with some applications. Depending on the distance between the subscriber's home and the location of the CGN/LSN device within the service provider's network this could increase latency for all IPv4 communications for that subscriber.

The subscriber may experience connectivity problems if the performance of the CGN/LSN system is limited and cannot keep up with the total number of connections per second. Service providers recognize that deploying CGN/LSN devices at several points in their network is easier than migrating their core networks to be dual-protocol enabled.

However, there is capital costs and operational costs to deploying and maintaining CGN/LSN systems. The CGN/LSN system can be a single point of failure that can negatively impact the subscribers Internet experience. CGNs/LSNs further increase the amount of anonymity of attackers on the Internet and make forensics and reputation filtering difficult, if not impossible. Many agree that CGN/LSN is not an optimal solution but service providers have been slow to deploy IPv6 so they are in a tough situation trying to preserve their IPv4 address allocations for years to come.

Protocol Translation (NAT-PT, NAT64/DNS64)

Another extreme technique is to continue to use IPv4 inside of your organizations and translate those packet's source/destination addresses to IPv6 addresses as those packets leave an enterprise destined for the Internet.

You probably have enough RFC 1918 private IPv4 address space to sustain your internal networks for years to come. From the Internet perspective it looks like your organization is progressive in their use of IPv6. However, the problem is that, currently, there is little Internet content that is IPv6-reachable.

I liken this technique to trying to preserve the longevity of your Betamax video recorder. Even though the rest of the world has transitioned to using DVDs, BlueRay, and DVRs, you cling to your recorder to maximize your investment in that technology.

However, someday, your recorder may break or you can't buy tapes anymore. The reverse of this approach is the other extreme where an enterprise has fully transitioned to IPv6 internally and use their limited public IPv4 addresses on the outside of a protocol translator. This would require a system at the Internet perimeter to translate the internal IPv6 packets to external IPv4 packets for use on the Internet. It is not likely that an organization can easily fully deploy IPv6 within their enterprise today and disable all use of IPv4.

Protocol translation causes issues that are less than ideal and cause problems for many applications. Applications that have embedded IP addresses may not work as desired. Applications that use FTP, SNMP, SCTP, multicast, or fragmentation of packets can experience problems traversing a protocol translator. Stateless Network Address Translation - Protocol Translation (NAT-PT) also causes problems for DNS and IPsec.

These are some of the reasons why NAT-PT is now deprecated by RFC 4966. An organization could use NAT64/DNS64 at their Internet perimeter. However, for the DNS64 proxy function to make this work all communications must start with a DNS query. That may not work for all applications inside an enterprise. Therefore, protocol translation is considered a last-resort IPv6 transition technique.

Dual Stack Lite (DS-Lite)

Dual Stack Lite (DS-Lite) is yet another technique for prolonging the lifespan of IPv4. DS-Lite is an IPv6 transition mechanism that is implemented within the service provider's infrastructure. It is comprised of a centralized Address Family Transition Router (AFTR) element function and a Basic Bridging BroadBand (B4) element that is integrated into the subscriber's CPE device or as a software agent on their computer (cleaver names huh?).

DS-Lite encapsulates the end-user's IPv4 packets inside IPv6 packets for transport across the service-provider's IPv6-enabled core network. DS-Lite is a tunneling technique and effectively reduces the IPv4 MTU by 40 bytes to 1460 bytes. DS-Lite is standardized with the IETF RFC 6333 titled "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion".

DS-Lite improves upon multiple layers of NAT because it uses on a single centralized NAT function within the AFTR. There is no NAT being performed by the subscriber CPE B4 element. That single AFTR NAT function is stateful and uniquely differentiates each client IPv4 session based on the unique global IPv6 addresses used for encapsulating the subscriber's IPv4 packets.

In this way, each subscriber CPE devices can use the same overlapping IPv4 address space ( but their packets are identified by the unique IPv6 addresses used for the encapsulation.

1 2 Page 1
Must read: 10 new UI features coming to Windows 10