I believe that the automation evolution that is happening today will help to drive IPv6 adoption, so hear me out and let me know if you agree. Operational models that are pushing for automation such as cloud, network function virtualization and software defined networking will shape what products and IT solutions are utilized by companies. With the continued efforts of open source community solutions like OpenStack driving towards IPv6, it will make it easier for companies to deploy and consume IPv6. This will be critical in the adoption and usage of IPv6 over time.
Does this mean that all cloud infrastructures will support IPv6 soon? Not likely, it will be a slow steady march. While OpenStack is gaining more IPv6 support there is limited to no IPv6 support in the top 5 cloud providers in the market today. Amazon EC2 has limited IPv6 services (mainly load balancing and some public services), Microsoft Azure has no IPv6 services, Google has been a strong supporter of IPv6 however their cloud platform is not yet in the top 5 (depending on which ranking you believe). SoftLayer has IPv6 support and so does Verizon’s Terremark but not all services from all providers have IPv6 enabled. For instance, Rackspace has some services available via IPv6 but not everything. This is to be expected right now. The landscape is migrating to IPv6 and soon enough all the major cloud providers will have universal IPv6 capabilities. Why do I say this?
First, as they build more and more abstraction through software to enable functions in cloud architectures it becomes easier in many ways to decouple the networking protocol from the automation and orchestration that happen. It allows for these architectures to accommodate IPv6 as incremental changes are made to each function within a cloud environment. So as OpenStack Neutron matures over time more advanced IPv6 services will be made available. The same holds true for the open source controller OpenDaylight which actually has IPv6 support. Additional projects like OpenFlow have IPv6 also, making the complete package possible to run on top of IPv6. Additionally, both the overlay and underlay networks that are maintained in these cloud architecture are both being developed with IPv6. It is unfortunate that many of these projects did not start out day one as having IPv6 support but they are adding it and that is the critical message. See Scott Hogg’s excellent post (https://community.infoblox.com/blogs/2014/07/22/making-new-product-make-it-dual-protocol) about the current status of many of these projects.
So, do Puppet, Chef, Ansible, Salt, CF-Engine (all effectively declarative state solutions) or any other automation/orchestration/deployment solution care if IPv6 is involved in the process? The answer is likely no, they don’t. They utilize digital certificates, ssh, ssl and DNS to do the bulk of their work. If access to resources are provided over IPv4 or IPv6 those systems should not care at all. As a general rule of thumb, this is awesome news. This means that the only thing that matters in these solutions is being about to treat an IPv6 address (and its associated information) as a variable that those systems can configure or manipulate on a host. As long as the underlying system can support IPv6 these systems should be able to manipulate and set the right configurations for IPv6.
If you plan on starting to leverage automation more don’t leave IPv6 out of the provisioning and management part of the work you do on hosts. It is still common to see examples and implementations that only automate and manage IPv4 resources on hosts with no consideration for IPv6. In addition, many scripts only function when given IPv4 variables and are unable to run properly with IPv6 parameters. While it might take more time to develop a script or module that accepts both IPv4 and IPv6 parameters your life will be easier later down the road. So take Scott Hogg’s advice and develop (or script in this case) from the beginning with IPv6 in mind.
– Ed
