On a recent flight from the UK to the USA I sat next to the IT director for a global corporation. He asked me why I was travelling, to which I answered that I was giving the keynote presentation at an IPv6 conference held by the US Federal government. Without hesitation, his response was “IPv6 is not even on my radar”.
For many enterprises, IPv6 is a long way from being on their to-do lists, with many citing several blockers to adopting it. Here are the three biggest blockers that I’ve seen over 20 years of providing IPv6 services.
Blocker 1: Why should we fix something that is not broken?
Enterprises perceive IPv6 as a technology that gives them exactly what they have today; the Internet, but at increased cost and risk. They ask, “why should we fix something that is not broken?”. Enterprises see no difference between an Internet based on IPv4 and an Internet based on IPv6.
Even some leaders in the IPv6 community appear to agree with them. At the North American IPv6 Task Force in 2017, John Curran, ARIN’s president and CEO, said in his keynote presentation that there is no real difference between the IPv4 and IPv6 Internets. His answer was to make IPv6 more attractive than IPv4 by making it more secure. I believe that this is wrong.
Blocker 2: We have no budget for IPv6
I hear this repeatedly. At another recent conference, the speakers were bemoaning their organization’s lack of an IPv6 budget. Even though they wanted to deploy IPv6, they could not proceed due to a lack of funding. Many organizations see the initial cost of deploying IPv6 and the ongoing costs of managing it alongside IPv4 as prohibitive and, as a result, have not allocated any budget for the process.
Blocker 3: We lose the benefits of NAT44
Enterprises often use NAT44 at the edge of their networks, not for security, but for load-balancing and resilience. This is especially true of small- and medium-sized enterprises that connect to multiple Internet providers and do not run BGP or have their own provider independent (PI) address space. Even large enterprises sometimes use NAT44 to ease the use of multiple providers.
For small- or medium-sized enterprise that do not wish to obtain PI space and run BGP, IPv6 presents a big problem. There is currently no standardized IPv6 solution for these types of multi-homing scenarios.
Overcoming blockers: let’s focus on how IPv6 mitigates side-effects of IPv4 decline
I will cover how to respond to these blockers in more detail in future posts. However, for the moment, let us look briefly at the first one; “Why should we fix something that is not broken?”
This is a valid question, if and only if, we accept the underlying premise; that the IPv6 Internet is identical to the IPv4 Internet. Personally, I do not agree with this. More importantly, I see the differences between the two Internets as being some of the most powerful reasons for enterprises to adopt IPv6.
First, a quick aside, I do not think that making IPv6 ‘better’ will work. Especially, if it is by making it more ‘secure’. Remember Microsoft Windows Vista? It was more secure. Businesses should have welcomed this. Instead, users widely hated Vista because the security got in their way. We do not want IPv6 to become the networking equivalent of Windows Vista.
Instead, we should focus on how the IPv4 Internet is measurably deteriorating. And how, in sharp contrast to IPv4, IPv6 overcomes all the things that are leading to problems in IPv4.
One powerful example of how the IPv4 Internet is deteriorating is the detrimental impact of the increasing use of Carrier Grade NAT (CGN). CGN has a negative impact on all Internet players; end-users, carriers, and content providers alike. CGN impacts the very things that matter to enterprises; reliability, accountability, security, governance, and performance.
We should promote IPv6 as the only way to mitigate the unavoidable side effects of the IPv4 Internet’s decline.
Contributor: Veronika McKillip
Dr David Holder is the CEO and chief consultant at Erion Ltd.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
From the post, it’s apparent that the blog author failed to comprehend my presentation at the North American IPv6 Task Force in 2017. In particular, the author states –
“Even some leaders in the IPv6 community agree with them. At the North American IPv6 Task Force in 2017, John Curran, ARIN’s president and CEO, said in his keynote presentation that there is no difference between the IPv4 and IPv6 Internets. His answer was to make IPv6 more attractive than IPv4 by making it more secure. I believe that this is wrong.”
My actual presentation did make plain that most organizations see no real difference between the IPv4 and IPv6 Internet, but also that this view was justified due to the relatively small advances in capabilities that are realized in the IPv6 protocol, and the reality that without otherwise changing the service model, the functionality of the Internet over IPv6 is looks quite the same to most enterprises as the Internet over IPv4.
The blog author fails to identify any meaningful functionality improvement with IPv6 aside from larger address space, but IPv6’s larger address isn’t a feature that addresses any problem that enterprises face with the Internet today.
The author acknowledges that the benefit of IPv6 is principally the avoidance of IPv4’s deterioration (i.e. the result of increasing CGN use due to IPv4 address space depletion), but somehow presumes that the consequences of CGN deployment equates to the IPv4 Internet being broken for enterprises.
Alas, the impact of CGN is highly variable depending on the service provider, and is very challenging for enterprise customers to detect, let alone serve as a meaningful motivation. Given the difficulty in perceiving any IPv4 deterioration effect, and absent any improvement in protocol functionality or improved deployment model, it is not surprising that IPv6 is seen by enterprises as providing (at best) the same Internet experience as IPv4.
This is why an assertion that today’s typical enterprise have a concern with IPv4 is rather specious, and the adoption rate of IPv6 among typical enterprises reflects this reality. For companies that have significant Internet-based content, such as audio/video streaming, gaming, or e-commerce, there is increasing awareness of mobile’s move to IPv6 and need to follow, but the enterprises significantly impacted by that transition remain the exception rather than the rule.
I will observe that authors final point is valid; i.e. “We should promote IPv6 as the only way to mitigate the unavoidable side effects of the IPv4 Internet’s decline”, but again, that reflects a concern principally of faced by broadband service providers, and major content providers, and mobile network operators – the idea that typical enterprises are facing a “broken Internet” due to IPv4 runout is simply an assertion that lacks credibility.
That is apparently true typical enterprises have no interest in differentiating IPv6 and IPv4, but in getting their business going smoothly.
Maybe the fundamental blocker is the rumor that the IPv6 is not a super-set / direct upgrade replacement of the IPv4? Also, some people state that IPv6 can not encapsulate IPv4 packets, while the reverse has been working?
How about looking into the possibility of making use of the basic IPv4 protocol RFC791 and the long-reserved yet hardly-used 240/4 address block? A few years ago, we accidentally ventured into studying this subject. We now have submitted a proposal called EzIP (phonetic for Easy IPv4) to IETF:
Basically, the EzIP approach will not only resolve IPv4 address shortage issues, but also largely mitigate the root cause to cyber security vulnerabilities, plus open up new possibilities for the Internet, all within the confines of the IPv4 domain. In fact, this scheme may be deployed “stealthily” at isolated regions where needed. This approach could relieve the urgency to deploy the IPv6 for an appreciable length of time.
Any thought or comment would be much appreciated.
Abe (2018-07-14 20:31)