So far, the whole Internet ecosystem is successfully ignoring the impeding IPv4 address exhaustion catastrophe.
Ivan Pepelnjak, NIL Data Communications
Whether you choose to believe it or not, public IPv4 address space will be exhausted sometime in the next two years -- unless a miracle happens and the Internet's early adopters return their Class A networks to the public pool, which would delay the inevitable by a few months or years. And what about the transition from IPv4 to IPv6?
So far, the whole Internet ecosystem is successfully ignoring the impeding IPv4 address exhaustion catastrophe. Large carriers are slow to deploy IPv6 services since there's no demand for them. Low-end customer premise equipment (CPE) and mobile device makers are pretending IPv6 does not exist (as the only mobile devices supporting IPv6 on UMTS are the Symbian-based phones).
And most content providers probably don't even know what IPv6 is. Google and other big content providers are an obvious exception, since they don't want to lose a single visitor. Google will do whatever is necessary, including beginning their IPv6 transition as soon as possible.
Here are the grim facts:
- It will be impossible to get significant amounts of new public IPv4 address space in a few years;
- New devices (and users) will have to use IPv6 to connect to the Internet;
- The very long tail -- the niche strategy of selling a large number of unique items in relatively small quantities -- of the content curve will not be directly accessible to these users.
The result? Even if service providers like Comcast try to be future-oriented, invest heavily in IPv6 and work with vendors to develop the standards and gear needed to deploy IPv6, they are stuck with the need to access IPv4 servers. Dual-stack deployment -- running IPv4 and IPv6 parallel to one another -- would be an ideal solution, if only we weren't approaching public IPv4 address exhaustion.
Faced with this unenviable situation and the total indifference of large parts of the IT industry, the networking experts turned to Network Address Translation (NAT), the tool that saved them 15 years ago, but even here they couldn't agree on a single workable approach.
Early solutions to link IPv4 and IPv6: Nice try
The need to link the IPv4 and IPv6 worlds was recognized more than a decade ago, resulting in the Internet Engineering Task Force's (IETF) Stateless IP/ICMP Translation Algorithm (SIIT) RFC 2765 and Network Address Translation -- Protocol Translation NAT-PT (RFC 2766) protocols. SIIT translates each IPv6 address into a unique IPv4 address, which is clearly useless when you're trying to solve the IPv4 address exhaustion problem.
NAT-PT did not fare any better. It tried to solve too many problems at once and failed miserably in solving any of them satisfactorily. It was rescinded in July 2007 (RFC 4966) and deemed an historic, yet defunct, document. But it's still the only translation mechanism between IPv6 and IPv4 implemented in production-grade equipment (including, among others, Juniper NetScreen and Cisco IOS devices, although NAT-PT on Cisco IOS has had a bit of a performance problem lately).
Next: Comparing IPv4 to IPv6 address translation solutions
About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and Web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. Check out his IOS Hints blog.
This was first published in July 2010