Why is SDN Happening faster than IPv6?

IPv6 vs SDNIt often seems like my enthusiasm for new technologies is met with resistance. This is legitimized by statements like, “Sure SDN Will happen quickly–like IPv6.” While that is a statement I can relate to, I think this is an apples to oranges comparison.

I realize that the first IPv6 RFC actually appeared over 15 years ago (December 1998) and its deployment status has still not reached mainstream. I have repeatedly made the statement that it is an important technology that should and will be embraced. On the other hand, it often seems that the SDN movement is happening at a faster pace. The question is why?

Before sharing what I believe to be the answer to this question, let me define the assumptions I make for the perspective of this article.

SDN–Software Defined Networking including protocols for flow management (such as OpenFlow) and orchestration (Puppet, Chef, etc).

IPv6 Mainstream Deployment–most sites, subscribers and applications have and use native IPv6 connectivity.

SDN Mainstream Deployment–software defined networking would be considered mainstream when is widely used where  advantageous to do so.

From these definitions, there are a couple of obvious points. IPv6 being mainstream would be a more ubiquitous deployment than SDN being mainstream. From an SDN perspective, I never expect to see a centrally controlled Internet or even an Internet that is uniformly managed with the same protocols and methods. IPv6 deployment would also require global adoption of a protocol as opposed to allowing different methods for different needs.

I believe the answer to the original question is simple. When looking at why SDN seems to be gaining momentum faster than IPv6, we have to think about the people and groups involved. IPv6 requires investments by almost everyone in technology. This includes service providers, consumers, and enterprises and they must address changes to equipment, protocols, applications, operating systems, and processes. This inclusion and implicit agreement of all disciplines in IT create a significant challenge for widespread adoption.

SDN, on the other hand, can be implemented as it makes sense to do so. In some cases, this may only include individuals from the networking team. In other cases, it may include server administrators and even be extended to broader orchestration initiatives. There would typically be no need for modifications to user applications or worldwide acceptance of the newly implemented methods. This creates the possibility for incremental investment and payback potential within individual organizations or business units.


Technology, like most other things, gets complicated when many people, groups or organizations need to work together and agree. A typical prerequisite for investment for an organization is some expectation of benefit or payback. IPv6 will not be universally accepted as important until its adoption becomes widespread or its unintentional use creates operational challenges for an organization.

Software Defined Networking, and the greater DevOps movement, is something that can be invested in and have a more immediate payback for an organization. This, along with the ability for organizations to proceed independently, are the reasons for SDN happening faster and a trend that will likely continue until IPv6 reaches a tipping point.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Other. Bookmark the permalink.

2 Responses to Why is SDN Happening faster than IPv6?

  1. Pingback: Technology Advancement: It's All About The Money. - Global Config Technology Solutions

  2. Henk says:

    “I realize that the first IPv6 RFC actually appeared over 15 years ago (December 1998)”

    You are too optimistic. If you look inside RFC2460 you will see that it is actually an updated version of RFC1883. And RFC1883 was published in December 1995.

Comments are closed.