Declaring IPv6 a Standard and Declaring IPv4 Historic
2016 has witnessed IPv6 adoption continuing at an amazing rate. Even though IPv6 adoption has been doubling every year for the past few years, IPv4 usage continues to rise as well. However, at some point in the next few years, IPv6 will overtake IPv4 and IPv4 will eventually be considered the legacy protocol. The IETF has been watching these trends for more than two decades now and advocates for IPv6-only efforts as well as the prioritization of standards that support dual-protocol configuration. There have also been many discussions about declaring IPv4 as a “historic” protocol.
The IETF has formed a sunset4 working group focused on planning for the sun to set on IPv4 and to plan for the eventual disabling of IPv4. This group has produced a draft exploring the gaps that exist for systems that still cling to IPv4 and are unable to operate smoothly in an IPv6-only world. Lee Howard of Charter Communications has written a draft on ending work on IPv4 and a draft declaring IPv4 historic. The sunset4 WG met at IETF 95 and discussed if IPv4 can be considered historic. Geoff Huston also wrote about the conversations that took place at IETF 95, “Declaring IPv4 Historic” and about “Declaring IPv6 an Internet Standard.” The point of these efforts is that even though IPv6 is widely deployed on the Internet, RFC 2460 remains listed as “Standards Track, Draft Standard” and should be promoted to a full “Internet Standard.” The Internet Architecture Board (IAB) has also made a statement about the preference for IPv6 in new Internet standards.
Tunneling IPv6 within IPv4
Even back in the mid-1990s, the inventors of IPv6 knew full well that a transition to IPv6 would be challenging and that there needed to be a wide variety of transition mechanisms to make migration feasible and manageable. These transition techniques (RFC 4213) fall into three categories: dual-stack, tunneling, and translation. However, in spite of these techniques to facilitate transition to IPv6, as IPv4 continued to grow on a global scale, the process of wholesale rapid migration directly to IPv6 became increasingly unlikely.
Dual-stack is the dominant transition strategy. With dual-stack networks are configured with both IPv4 and IPv6 simultaneously and nodes support both protocols at the same time using whichever one is available, configured, or performs better (as in the case of Happy Eyeballs (RFC 6555). Tunneling techniques involve encapsulating IPv6 packets within IPv4, thus allowing “islands” of IPv6 to cross over an “ocean” of IPv4. Due to the drawbacks of tunneling (e.g., static configuration, poor resiliency and/or scale, MTU problems, general difficulty in troubleshooting, etc.), dual-stack is preferred whenever possible. Translation is a sub-optimal approach as it is difficult to properly map IPv4 to and from IPv6 due to the differences in their protocol headers and how applications behave.
Operating a Dual-Protocol Network
All of the mid-1990s transition mechanisms have now largely been superseded by the dual-stack approach. Today, IPv6 is widely deployed across the Internet and is continuing to be adopted by organizations. Although there is still significant effort required to fully deploy IPv6 within enterprises, IPv6 is becoming more ubiquitous everywhere else. IPv6 deployment has been a focus for all large service providers for many years and now virtually all large International carriers operate IPv6 on their backbones. Service providers have certainly felt the pressures of IPv4 address exhaustion and that has driven their IPv6 deployments.
However, operating a dual-protocol network is not a panacea. Running two network protocols in an environment may increase the administrative burden and drive up operating expenses. For Internet Service Providers (ISPs), reducing administrative overhead and creating a scalable network infrastructure that easily supports millions of subscribers are the primary paths towards higher profits. Operating a core network and services with IPv4 and IPv6 simultaneously increases expenses. Therefore, service providers would rather run a core network that uses a single protocol. Service providers would like to be able to operate an IPv6-only backbone network, yet still furnish connectivity for legacy IPv4 subscribers to the soon-to-be legacy IPv4 Internet.
Supporting IPv4-Only Nodes on an IPv6-Only Network
It is important to recognize that dual-protocol is a transition strategy, but the goal is to end up with an IPv6-only environment. Making the jump directly from IPv4 to IPv6 is not practical, but organizations – especially service providers – will typically want to minimize the time they spend in the dual-protocol transition phase. As we are making this transition from IPv4-only to dual stack to IPv6-only, service provider network architecture and design strategies will continue to evolve. For example, one benefit of having an IPv6-only network is that an organization reduces the number of routes their routers must process and store, which has the byproduct of reducing the cost of their hardware infrastructure. During the dual-protocol transition phase, the routers must hold both the IPv4 routing table (over 600,000 prefixes) and the IPv6 routing table (over 33,000 prefixes) in memory.
As service providers contemplate how to operate an IPv6-only core, they are still responsible for providing connectivity for IPv4 subscribers to content from the IPv4 Internet. Subscribers have numerous legacy devices that only use IPv4 and may not be IPv6-capable. As an example, consider a grandma who has a digital picture frame that can use exclusively IPv4 to retrieve pictures of her grandkids from a cloud picture repository. If her ISP turns off her IPv4 Internet connectivity in favor of IPv6, she will call the ISP’s tech support line to resolve the problem. As they attempt to explain to her how the world is moving toward IPv6, grandma will become more agitated and angry and tech support will soon feel the full force of her fury. She might even say something like, “Back in my day, all we had was 32 bit addresses, 32 bits was enough, and we were thankful!” You don’t want to take that tech-support call so it is best to keep her IPv4-only keepsake working.
IPv4 as a Service
Early transition mechanisms involved joining islands of IPv6 over an ocean of IPv4 by tunneling the IPv6 packets within IPv4. That gave way to the dual-protocol transition period we are in now. Therefore, it is only logical that there will be late-stage transition strategies that involve tunneling the ever-more-scarce IPv4 nodes over the IPv6-enabled core network. Service providers are financially motivated to explore the feasibility of running IPv4 as an overlay protocol over an underlay IPv6-only core network infrastructure.
The use of the word “cloud” has become an overused term and now every new technology is referred to as some type of “as a service.” The same is true for this concept of providing IPv4 service on top of a cloud of IPv6. There have been many other permutations of this as-a-service nomenclature. Hence, these methods of supporting legacy IPv4 subscribers over an IPv6-only core are now being referred to as “IPv4 as a Service” or IPv4aaS.
This picture illustrates this concept of an IPv6-only service provider core network that connects to the Internet at one end and to subscribers at the other. Subscribers using IPv6 (addresses shown in green) will traverse the IPv6-only ISP backbone seamlessly, without any NAT function, and flow directly to the IPv6 Internet. Subscribers using legacy IPv4 (addresses shown in red) will be tunneled across the IPv6-only ISP backbone and then go through a gateway where the decapsulation occurs and a centralized Carrier-Grade NAT/Large-Scale NAT (CGN/LSN) function will take place before the traffic reaches the IPv6 Internet.
Summary
Many residential broadband Internet subscribers are lucky enough to already have dual-protocol Internet connectivity through their ISPs. Most mobile phone subscribers already have dual-protocol connectivity — though they probably didn’t even realize it. Some enterprises, like U.S. Federal government departments and agencies, have established dual-protocol connectivity to their Internet perimeter, but few enterprises have purposely introduced IPv6 to their internal networks and systems. Beyond effectively managing the IPv6 that’s already running internally, enterprises may also want to establish IPv6 Internet connectivity sooner than later to allow their internal users to take advantage of potentially faster connectivity.
For enterprises, IPv4 as a Service can become part of the equation as they move to SD-WAN architectures. Enterprises already have IPv6-capable systems in their environments but many have not yet intentionally established end-to-end IPv6 connectivity. As enterprises procure cost-effective direct Internet links to their branches, stores, and remote-offices they may automatically receive dual-protocol Internet access. This will have an effect on their IPv4 and IPv6 addressing at those locations. With IPv4 as a Service from their ISPs, the native IPv6 systems at a branch will access the Internet directly, while the IPv4-only devices at a branch will experience tunneling. The bottom line is that if you are using IPv6, your Internet-bound traffic will not be tunneled and is end-to-end (as intended in the original concept of the Internet). However, if you are the last person on your block clinging to IPv4 then you may experience challenges.
Next month in part two of this series, I will explore the various methods with which service providers can create an IPv4 as a Service.
This post originally appeared on the Infoblox blog at https://community.infoblox.com/t5/IPv6-Center-of-Excellence/IPv4-as-a-Service-IPv4aaS-Part-1/ba-p/8279.
Scott Hogg is the Chief Technology Officer (CTO) for GTRI.
