What do IPv6 and software-defined networking have in common? Not a lot, but then again, oh so much. Both IPv6 and SDN stand to radically change the way we build networks, and if implemented correctly, both play a role in making the cloud and IT as a Service more of a reality.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In the last five years, server and storage virtualization have revolutionized IT, enabling flexible provisioning of resources that can be used for an agile cloud. But the rigid network has been a bottleneck. Now, SDN promises to virtualize the rest of the data center infrastructure and make it so that network resources can be provisioned on demand and integrated into overall cloud orchestration.
Here is where SDN and IPv6 implementation meet. If both sets of technologies require network teams to rethink network design, why not do both at once? The good news is that these two technology trends can be mutually beneficial.
The perfect storm: IPv6, SDN, cloud as inflexion points
It's clear that SDN and IPv6 are both crucial for the long-term vision of the cloud. IPv6 is necessary for scalability; SDN enables infrastructure flexibility and both play into cloud agility. But why must SDN and IPv6 transition occur at once?
Why IPv6 transition now? There is no shortage of hype around the Internet of Things and its ability to let us network everything from corporate servers to home refrigerators. But to make that possible, we'll need more IP addresses as there simply aren't enough IPv4 addresses available to handle this kind of growth. Without IPv6, the evolution of the Internet and intranets alike would be slowed at best, but more likely halted due to the lack of both unicast and multicast addresses. But beyond that, IPv6 enables a range of other features important for growth, including simpler IP address management, as well improved packet processing and routing.
What's so important about SDN flexibility? We are finally bringing the network into the service delivery process as an active, flexible, adaptable and competitive resource. SDN enables IT teams to automate provisioning of virtual network resources, spinning up virtual instances of network with related Layer 4-7 services in a way that is application aware. Also, SDN allows IT shops to use less expensive hardware with software that takes over the complicated job of the network. As a result, software-driven networks will be more cost effective and better integrated with the other components of IT infrastructure. In the long run, all three will be provisioned specifically for the demands of services and applications and rolled back when they're not being used.
Cloud adoption delivers agility: The orchestration of compute, network and storage resources make delivering flexible cloud services possible. Without the ability to provision infrastructure on demand, it could take weeks or months instead of minutes to make an application go live on the network, or to change capacity to improve performance.
These inflexion points might be at different stages of maturity, but they are likely to hit IT organizations within a short window of time. SDN controllers and cloud orchestrators must be integrated to align application hosting infrastructure with the service delivery network infrastructure and to deliver optimal end-to-end services properly. Yet it'll take IPv6 to enable the scale of cloud infrastructure and SDN. This perfect storm of technology and process transformation must be very well managed.
SDN must be IPv6-based not just IPv6-ready
When it comes to IPv6 implementation, we often hear the term "IPv6-ready," or that products offer "feature and performance parity with IPv4." Too often this means IT teams are considering options that help them add IPv6 addresses without rethinking their architecture to enable all the features this technology could bring to bear.
SDN product manufacturers are already asking their potential customers to make massive shifts in their networks, so they should be developing solutions are IPv6-based, not just IPv6-ready. This way, customers can fully leverage the resources and capabilities offered by IPv6. After all, IPv6 solves more than just address depletion problem. The newer addressing system supports multicast rather than broadcast, which saves bandwidth by enabling packet flows to be sent to multiple destinations at once. Also, because of the difference in address header, IPv6 eliminates IP-level checksum, making packet processing more efficient. Address assignment and management also become simpler in IPv6.
The availability of globally unique unicast addresses for all interfaces simplifies SDN implementations. The link-local communication implemented by IPv6 can be leveraged for a hop-by-hop control plane independent of the unicast address plan. Another example where IPv6-specific features can be used is the flow label. This is prime real estate in the main IPv6 packet header that can be used for flow tracking and for maintaining state across federated SDN domains.
On the flip side, SDN can also make the transition to IPv6 simpler. When users deploy IPv6, they run a dual-stack environment, which proves to be complex and expensive. We already know the difficulties of managing the asymmetries between the IPv4 and IPv6 flows in a dual-stack network. In software networks, engineers can smoothly migrate services from one IP protocol to the other while making the management of dual-stacked environments more deterministic. The analogy that comes to mind is the ease with which we are able to IPv6-enable and manage MPLS-based backbones that were already delivering IPv4 services.
Enterprises should implement new technology that takes full advantage of all of these features. The SDN world should learn a lesson from OpenStack, which became IPv6-ready only with the Grizzly release. Waiting so long made provisioning difficult in an IPv6 environment, and as a result many OpenStack implementations still fail to leverage IPv6-specific functionality in facilitating the orchestration process.
IPv6, SDN transitions: Timing is everything
Both SDN and IPv6 transition efforts are expected to start over the next 24 months. As a result, IPv6 can be a great precursor and catalyst for SDN.
For one thing, tackling both at once helps with the potential downtime caused by redesign. Network infrastructure changes have significant impact to service delivery. IPv6 will also require such changes. IT teams could leverage this planned downtime to work on the rollout of SDN technology. Moreover, IPv6 is deployed as an overlay, dual-stack, where IPv6 and IPv4 run in parallel as ships in the night. This means SDN can be trialed and demonstrated on IPv6 without impacting IPv4-based production services. Many IT organizations, from service providers to enterprises used the IPv6 transition as an opportunity to test a new architecture, independent of the existing, production IPv4 one.
Ultimately, the IPv6 transition is inevitable and likely to occur within a timeframe relevant to SDN adoption. The IPv6 transition strategy should include the SDN vision for the organization. The transition can be leveraged to refresh the infrastructure for SDN readiness, train staff for SDN and use new SDN-enabled infrastructure to make the IPv6 transition easier.
About the author:
Cipriam Popoviciu is president, CEO and founder of Nephos6, a consultancy specializing in IPv6 and cloud computing. He is an industry-recognized IPv6 domain expert, contributing to both protocol standardization and the definition of national-level strategies for IPv6 adoption.