Another guest posting from Scott Hogg of our Technical Advisory Board.
cricket
For years people have been looking for the “Killer App” that will make everyone want to deploy IP Version 6 (IPv6). The primary reasons to deploy IPv6 have been to gain a larger address space and to avoid technological obsolescence. There have been several applications that we thought would be the Killer App for IPv6. These include IPSec, Mobile IPv6, Microsoft Three Degrees, Microsoft Direct Access, and sensor networks enabled with Stateless Address Auto-Configuration (SLAAC). However, these technologies and products have not caught on or have not been rapidly deployed. The search goes on for the one thing that will drive rapid IPv6 adoption.
The fact remains that IPv4 address exhaustion has occurred in Asia and is coming soon to Europe and North America. If you do not believe the “rumors” about IPv4 address exhaustion, then just try to ask your local RIR for another /18. You will likely be unsuccessful unless you have some pretty heavy-weight justification for needing more public IPv4 addresses. The reality is that many organizations are going to be running IPv4 in their environment for the next 20 years. Does your organization really have enough IPv4 addresses to last for 20 years?
Many times I have heard people utter the words “our organization has plenty of IPv4 addresses so we don’t need IPv6.” It may be true that they have plenty of IPv4 address for their immediate needs, but they may not be anticipating changes coming in the next 20 years. And just because you may have plenty of IPv4 addresses does not mean that there won’t be others on the Internet who want to do business with you but they may be trying to use IPv6 to reach you. 20 years ago could any of us predicted the explosion of WiFi, 3G, and 4G mobile devices. We can daydream and wonder what life will be like in 20 years. Regardless, it is easy to predict that the number of IP-enabled devices will continue to increase and put an even greater strain on IPv4 addressing.
Now that the industry has reached a late stage of IPv4 address depletion there are many creative ways to extend the lifespan of IPv4. These techniques include continuing to increase the efficiency of IPv4 addressing by continuing to chop up the address space into smaller and smaller subnets. This puts a greater strain on your IPv4 addressing plan and requires an efficient IP Address Management (IPAM) system to maintain your sanity and the accuracy of the addressing.
Network Address Translation (NAT) is the technique that virtually all organizations use to allow for an internal network that uses private IPv4 addresses and translate them to a very limited number of public IPv4 addresses. Most enterprise organizations use NAT at their Internet perimeter and virtually all residential broadband Internet links use NAT. In fact, NAT has to be used with IPv4 because there is not enough address space for all IP nodes. If it weren’t for NAT, the Internet would have run out of public IPv4 addresses many years ago.
NAT is not an optimal solution for Internet communications because NAT breaks the end-to-end model of communications between nodes using unique IP addresses. The use of NAT has slowed down or limited the growth of transparent applications. Troubleshooting with NATs adds complexity and there is no easy way to maintain states of NAT in case of node failures. NAT breaks several applications like IP security (IPSec), reputation filtering, geolocation, FTP (requiring PASV mode), SNMP, and any other application that embeds the IP address in the application protocol payload. NAT allows for anonymity on the Internet and thus creates an environment for hackers hiding behind NATs. NAT also complicates mergers/acquisitions and “double-NATing” is often needed for devices at the two companies to communicate with each other.
Service providers have been feeling the pinch when it comes to limited IPv4 addresses. Many service providers do not have sufficient IPv4 addresses to continue to connect their customers to the Internet and sustain their growth for years to come. The fact is that service providers will need to continue to allocate IPv4 addresses to customers regardless of their IPv6 deployment plans. This situation has caused service providers to starting contemplating using NAT in their networks. In fact, service providers are actively planning and deploying Large-Scale NAT (LSN)/Carrier-Grade NAT (CGN) solutions. This means that their customers will not be given a public IPv4 address for their connection and instead will be allocated a private IPv4 address. The customer will have one level of NAT at their location translating their private IPv4 addresses into their private IPv4 address provided by the service provider. The service provider will use private IPv4 addresses in the core of their infrastructure and perform another level of NAT to translate the connections to the limited public IPv4 address space they have remaining. This would create multiple layers of NAT and is sometimes referred to at NAT444. For most organizations, one level of NAT is not that difficult to live with, but problems start to arise when multiple levels of NAT are used.
Today, some international organizations cannot get public IPv4 addresses for their Internet links. These organizations use residential broadband Internet connections to link up their small remote sites to their corporate extranet. The service providers in other countries are no longer offering public IPv4 addresses on residential-grade service and are using a LSN/CGN system in their core. If the organization’s remote sites cannot get a public, static IPv4 address then they cannot build site-to-site IPsec VPN tunnels between their sites.
There are many miseries resulting from using multiple layers of NAT. For example, the performance of the IPv4 connections may deteriorate if the CGN/LSN system is not scaled appropriately for the number of customers the service provider is connecting through the system. If the pool of public IPv4 addresses is too small then customers will be fighting for connections based on the limited number of addresses and port numbers available. The subscribers will also experience increased Internet latency as all their Internet traffic follows its path to the Internet through the city where the carrier has positioned the CGN/LSN system. Subscribers may also find many applications that have difficulties going through multiple layers of NAT. The service provider will likely field many technical support calls from their subscribers as a result of the problems the end users experience.
Over time, service providers will fully deploy IPv6 in their networks and more and more subscribers will gain IPv6 Internet connectivity. Customers may start to notice that their IPv6 connections will use native connectivity and follow the most direct path to and from the Internet. This will be a contrast to their experience using IPv4 in a double-NAT environment. Over time, service provider customers will start to see the benefits of native IPv6 and this will drive consumers of Internet connectivity to further adopt IPv6. Over time IPv6 will become the preferred transport method.
It turns out that the “Killer App” for IPv6 is the poor IPv4 performance people will experience through using multiple layers of IPv4 NAT.
Scott
