Editor's note: This article is co-authored by Ciprian Popoviciu, president, CEO and founder of Nephos6, and Shixiong Shang and Randy Tuttle, solution architects for a networking equipment vendor.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
We started drawing attention to the importance of simultaneously addressing the IPv6 transition and cloud adoption about two years ago. IPv6 and cloud are two of several major inflection points in the evolution of IT environments, those of both enterprises and service providers.
As the worldwide pool of unallocated IPv4 addresses becomes rapidly exhausted, the Internet of Things rolls in -- along with its need for the larger address space IPv6 provides. Meanwhile, cloud adoption drives agility in our service delivery and provides business customers with new service options. Both transitions are happening at the same time, and each is complex in its own right -- affecting every aspect of IT -- while also being interdependent. Pursuing one without consideration for the other will lead to substandard deployments that will require expensive and substantial rework.
To be blunt, we firmly believe cloud computing will not be able to reach its potential if it is not built on top of IPv6. The current IPv4-based clouds are mere proofs of concept for the ubiquitous cloud-based services the market envisions.
When we evaluated IPv6 support among cloud providers in 2011 to 2012, our assessments painted a bleak picture. As more and more providers have started to offer IPv6 support, we have shifted our attention to measuring the quality of services offered over IPv6 with a cloud-based service we created called v6Sonar. While a lot of work remains, we found some cloud services perform a lot better over IPv6 than they do over IPv4. We were, however, itching to see IPv6 in action in cloud orchestrators -- and not just simple IPv6 transport to pre-provisioned virtual machines (VMs). After all, the "cloud plus IPv6" message is not just about the efficiencies of jointly managing two strategic IT initiatives; it is also about the intrinsic technical value IPv6 provides to cloud implementations. All along, we have been excited about the innovation opportunities that lie at the boundary between cloud and IPv6.
Playing with the cool kid: OpenStack
From Day 1, we had our eyes on OpenStack -- the open source cloud computing platform used to build and manage public and private clouds. OpenStack is emerging as one of the leading competitors to Amazon Web Services' proprietary platform -- making it a major contender in the cloud platforms race --- so it was natural for us to assess its IPv6 compatibility. After all, when we evaluated the IPv6 readiness of proprietary cloud platforms, it quickly became clear that many, at best, needed a bit of work. And as an open source project, OpenStack allows us to fix and tweak components that are not IPv6-ready.
OpenStack is gaining significant traction with service providers and large enterprises, which are both also experiencing increasing pressure to migrate to IPv6. To demonstrate and further evaluate the advantages of a combined cloud- and IPv6-deployment strategy, we decided to get in the lab to see how IPv6-ready OpenStack really is.
Often times, there is a long and bumpy road from idea to implementation. OpenStack announced IPv6 support, starting with API 1.1, and Nova was supposed to support limited functionality -- that is, when Nova still covered both OpenStack networking and compute functions prior to the Folsom release in September 2012. Nova's networking component was phased out and received its own component, then known as Quantum. But the Folsom release had no support for IPv6 DHCP and IPv6 external routing, so we had to temper our enthusiasm in expectation of the following release, Grizzly, in April 2013.
Wrestling with the bear: OpenStack Grizzly
Each component in Grizzly, as shown in Figure 1, plays a key role in the orchestration process. Nova delivers virtual servers on demand, while Quantum -- recently renamed Neutron for the upcoming Havana release in October -- establishes the network connectivity between the resources spun up by Nova and other OpenStack components.
Our goal was to evaluate OpenStack's ability to operate at control-plane level in the following three modes while it creates dual-stack or IPv6-only virtual machines accessible from outside the cloud footprint:
- IPv6 and IPv4: dual-stack
- IPv6 and IPv4: complementary (some functions over IPv6 while others over IPv4, as needed)
- IPv6 only
We want to see cloud services not only withstand the IPv6 transition period but also build the IPv6-based, next-generation architectures.
We first evaluated the mandatory core components of OpenStack Grizzly: Nova, Glance and Quantum. Both Nova and Quantum displayed issues with IPv6 (see Figure 2), and it soon became apparent that a lot of the development for OpenStack was not done with IPv6 in mind. It's not easy to get multiple IP addresses for a VM, for example, not to mention contextualizing them based on scope. It's clear that IPv6 expertise is still in very short supply.
For tenant networks -- meaning a single tenant's environment in a multi-tenant cloud -- we identified the following issues:
- Dnsmasq, a DNS forwarder and DHCP server, is not launched to support router advertisement and stateless address autoconfiguration.
- Dnsmasq is not bound to the right interface, so the IPv6 default route on a VM points to the DHCP server address instead of the gateway address.
- Default ip6table rules on the compute node need to be tweaked so that the router and VMs on the same subnet can communicate with each other via Neighbor Discovery messages.
For external networks -- meaning communications between an OpenStack cloud and the outside world -- our tests yielded the following results:
- The router gateway (that is, the router's port that faces external networks) doesn't support multiple subnets. In other words, one cannot associate both IPv4 and IPv6 subnets to the same interface.
- Network address translation (NAT) and NAT64 is not recommended between the tenant network and the external network.
- There is no need for Generic Attribute Registration Protocol in IPv6 because we have Duplicate Address Detection right on the stack, another nice benefit of IPv6.
Yes, we made it work, but it took some effort and some Python coding. Despite this, we have OpenStack running on IPv6, and that is good progress.
Learn more and join the fun
If you want the gritty details of our testing and results, we encourage you to read our free white paper, "OpenStack Grizzly on IPv6," which offers a good way to get started in the world of cloud and IPv6 while learning about each individual technology involved.
We cannot wish IPv6 away and we cannot ignore cloud, but if you run a service provider business or enterprise IT organization, the smart thing to do is to buckle up and do it right. Cloud plus IPv6 is more than the sum of its parts, and OpenStack plus IPv6 will be part of many next-generation IT environments. For more information, contact us at the addresses below and stay tuned for results of follow-up tests.
About the authors:
Ciprian Popoviciu is president, CEO and founder of Nephos6, a consultancy specializing in IPv6 and cloud computing and based in Raleigh, N.C. Contact him at email@example.com.
Shixiong Shang, MSEE, CCIE, is a solution architect with more than 14 years of experience in networking technologies. His current projects relate to OpenStack deployment and use in cloud-based video solutions. Contact him at firstname.lastname@example.org.
Randy Tuttle, BSEE, is a solution architect with more than 25 years of experience in software design and Voice over IP solutions architecture. He currently works on cloud-based solutions for video services. Contact him at email@example.com.