Lately the IPv6 community has been witnessing a disturbing trend. Brand new networked products are being introduced to the market without IPv6 capabilities. Undoubtedly, these companies intend for their products to remain relevant for the foreseeable future. However, they RTM their software with an already obsolete feature-set. But the cost to change these products later in the development cycle will be higher than simply introducing the product with IPv6 capabilities right from the start. Meanwhile, the rate of adoption of IPv6 continues to accelerate.
For example, IPv6 is continuing to gain steam and the statistics on the amount of IPv6 packets traversing the Internet continues to rise. Just a couple of years ago Google was only observing a fraction of one percent of IPv6 traffic. In the last 18 months, their amount of IPv6 traffic has gone from 1% to 4% of their total traffic volume. Cisco’s 6Lab site shows more green and darker green areas than just a year ago. Many European countries like Belgium are experiencing climbing IPv6 traffic volumes. Comcast’s IPv6 deployment is now reaching well over 20% and Verizon Wireless is approximately 50%.
It is important to realize that for every Facebook page that is served up over IPv6, it means that there is one less Facebook page that must be served up over IPv4. My personal prediction is that in just a couple of years we will reach the tipping point and the rate of rise in IPv6 traffic will be nearly vertical. The aggregate traffic volume will continue to rise; no one ever uses less bandwidth. It is only the relative percentage of mix of IPv4 and IPv6 that will vary over time. IPv4 traffic volumes will continue to rise until the tipping point, when more connections will prefer IPv6. Eventually, the use of IPv4 will taper off, though IPv4 systems will be with us for decades. Following is a very basic diagram illustrating this concept.
As early as 2003 many U.S. Federal government agencies drafted procurement guidelines mandating that they prefer products that supported IPv6. This policy was formally adopted in the Federal Acquisition Regulation (FAR) 11.002(g). This was a great idea at the time to help position IPv6 in federal organizations and help manufacturers prioritize IPv6 on their product roadmaps. If a federal organization had an 8-year information technology refresh cycle and they stopped buying IPv4-only products in 2004 and started buying dual-protocol capable products, then by 2012 all their networks, computers and software would support IPv6. The idea was that if you waited long enough, eventually all the IT products in their environments would support IPv6. The plan was not to try to enable IPv6 right way, but to wait until some point when the federal government organizations would be able to enable IPv6 on their own timetable. The reality is that many federal organizations and many commercial enterprises continue to unknowingly purchase IPv4-only products.
Many manufacturers and cloud providers are releasing products (and APIs) that are only configurable with IPv4 addresses. In 2014, it is disappointing to be seeing some new products introduced that do not have dual-protocol capability. These new IPv4-only products are in a class of products in the highly competitive areas of cloud management, software defined networking, and IT automation and orchestration software. Because of the high level of competition in these markets, the vendors are trying to come out with new features rapidly that appeal to the majority of use cases. Since virtually all organizations use IPv4 today, that is the only protocol these companies are concerning themselves with at the moment.
The types of products that seem to be launched without any IPv6 support include:
- IaaS Cloud Services Management Interfaces – Many cloud providers offer only virtual compute systems using IPv4 networking
- PaaS and SaaS managed services – Some of these platforms and applications are only reachable over the IPv4 Internet
- Cloud Automation and Orchestration Software – Many of these products offer no way to have these systems mange other IPv6-enabled cloud or data center infrastructure
- Software Defined Networking Controllers and APIs – Some of these products only allow configuration of IPv4 forwarding via their southbound protocols, and their northbound protocols are only concerned with IPv4
There are products in these market segments that do support dual-protocol. Organizations who are preparing for a purchase are encouraged to ask the vendors what level of IPv6 capability they have in their products. It behooves the consumer to be informed and fully understand where the product may not have full IPv4 to IPv6 feature parity.
Here is a list of some of the IPv6-capable products in the above-mentioned categories:
- OpenFlow version 1.3
- OpenDaylight with OpenFlow Plugin
- OpenStack Grizzly, Havana, Icehouse
- AWS with Elastic Load Balancing
- Rackspace Cloud Load Balancers
- VMware vCloud Automation Center with Infoblox IPAM
- Infoblox Network Automation for Hosting and Cloud and IPAM for VMware
- Bluelock
- Brightbox Cloud Servers
- Linode NodeBalancers
- CloudFlare Automatic IPv6 Gateway
- Cisco UCS Manager 2.2(1)
- Embrane heleos 2.2.1
- MuleSoft iPaaS software
It seems strange that some enterprise-grade cloud management products do not come with IPv6 capabilities, yet Facebook is already contemplating a world where they would only use IPv6 and disable IPv4. There was discussion at RIPE 64 about the topic of IPv6 only data centers. The Internet Society (ISOC) has also covered this topic and it was mentioned at the V6 World Congress 2012.
It is easier to design a piece of software to be dual-protocol as that software is being initially developed. The cost to change an IT product to be dual-protocol after the product is designed takes more effort than if IPv6 would have been built into the product right from the start. We are not talking about an insurmountable amount of effort, but the further down the road you get, it will likely add up to be more work to make your system work in a fully dual-protocol environment.
There is a list of the “Top 10 Tasks for IPv6 Application Developers” that goes over some of the ideas you must keep in mind when you are making a dual-protocol software system. It may actually be quite difficult to make an IPv4-only system because so many of the software development environments and modern programming languages really assist developers in writing dual-protocol code. If you have an IPv4-only piece of code, then you will need to go back through your code and determine which modules, functions, objects, methods, and data structures have IPv4-only syntax. You will need to check for applications that input, store, or output IP addresses and/or DNS names, and check those applications that are making socket connections (RFC 3493). You need to handle dual-protocol DNS queries and take into account RFC 6555 Happy Eyeballs. You must allocate the proper amount of memory to hold an IPv6 address. Your code should also properly handle Path MTU Discovery (PMTUD) (RFC 1981).
The Bottom Line:
If you are a company that makes an IT product then you should build it in such a way that it would support both IP address families: IPv4 and IPv6. You should make your product dual-protocol right from the start or you may pay the consequences later.
If you are a company that has internally developed software, you should be building it so it works in both an IPv4-only, dual-protocol, and IPv6-only environment. Even if your environment is predominantly IPv4 today, you should make sure the application will soon support dual-protocol networks.
If you are a consumer of IT products, then you should look for products with support for both protocols. That will put your organization in the most advantageous position to enable IPv6 when you want to, without having to do a major upgrade to gain IPv6 support.
