You are here: Home > Publications > RIPE Labs > David Holder > Blockers to IPv6 Adoption

Blockers to IPv6 Adoption

David Holder — 07 Jun 2018
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. Many cite 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, the President and CEO of the American Registry for Internet Numbers (ARIN) 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 organisation’s lack of an IPv6 budget. Even though they wanted to deploy IPv6, they could not proceed due to a lack of funding. Many organisations 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 and medium-sized enterprises 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

Sometimes overcoming the blockers to IPv6 deployment is easy. Today there are many scenarios where organisations are driven to IPv6 to solve specific real-world problems. It is worth reiterating some of these drivers for IPv6 adoption here:

  • Organisations that have exhausted their RFC1918 address space
  • Organisations that have exhausted their allocated public IPv4 space
  • Application providers developing apps for the Apple App Store
  • Organisations with specific peer-to-peer requirements
  • Cyber security organisations that must consider dual-stacks
  • Those deploying the Internet of Things (IoT)
  • New ISPs and service providers with an insufficient stock of IPv4 addresses
  • Operators faced with the problems of deploying Carrier Grade NAT (CGN)

In recent months, I have spoken with clients who have deployed IPv6 for each of the reasons above.

Overcoming Blockers: 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.

Most people understand that IPv6 has an unimaginably huge address space and that, in contrast, the IPv4 address space is tiny and completely exhausted. The IPv4 address exhaustion only directly affects a subset of enterprises. However, the indirect impact of exhaustion, affects all organisations. The scale of this impact depends upon how organisations use the internet and how important it is to their business.

There are several areas that are critical to enterprises that are worse in IPv4 than IPv6. These include:

  • Performance. In our experience, network latency is often less on IPv6 networks. This influences not only user experience but also influences factors such as search engine rankings. Studies into IPv6 performance generally do not measure a large sample of clients against a large sample of content providers at the same time. Therefore, it is difficult to give definitive measures. However, factors such as the size of the IPv4 routing tables and the latency due to CGN may go some way to explain our observations.
  • Reliability. Some applications fail intermittently over IPv4 networks. CGN between your site or your application and your customers or end-users can cause some applications to fail. You may have no control over which customers or end-users, are behind CGN. We found many examples of this whilst carrying our research on CGN for Ofcom, the UK’s telecommunications regulator. We knew that even applications designed to work through NAT44 can fail through CGN. In mobile networks, we suspected that intermittent failures are often being attributed to the mobile network when in fact they are caused by CGN. We looked at the support forums for UK mobile operators and searched for a well-known message application and intermittent faults. We found that there were many reports of intermittent failures using this application with the same phone, network and at the same location. We surmised, but could not prove, that this was due to CGN. The difficulties of logging in CGN make it impossible for the operators and application providers to prove this too. Interestingly there was a special thread on the application’s support forum discussing the same symptoms.
  • Analytics. Web analytics is very important to organisations of all sizes. Again, CGN in the path from your end-users can make tracking users by address impossible. You have no control over this as you cannot control how your end-users, partners or potential clients connect to the internet.
  • Failure of important functionality. For example, the widescale sharing of IPv4 addresses in the IPv4 internet means that the usefulness of geolocation has deteriorated to the point that in some cases it is no longer meaningful. This impacts web-sites, analytics, forensics and applications that use geolocation. Again, the enterprise has no control or knowledge of whether geolocation is being degraded.

Whilst enterprise managers have no interest in the technical details of IPv4 imperfections like CGN, they are very interested in the business implications.

It is important to reiterate that enterprises have no control over whether their customers are behind CGN. Worse, they will usually not be able to even detect that they are behind CGN.

The intermittent nature of these and other problems means that it is hard for enterprises to be aware that these problems exist. Even if they do detect them, the lack of visibility means that is often impossible for them to attribute them to deterioration in the IPv4 internet. Therefore, we need to educate enterprises on the deterioration of the IPv4 internet in terms which they can understand.

For more information on this topic, I would suggest viewing my presentation from last year’s North American IPv6 Task Force (NAv6TF) meeting (https://youtu.be/fbk4H6EmZzI) or the UK telecom’s regulator Ofcom’s CGN report at http://stakeholders.ofcom.org.uk/binaries/research/technology-research/2013/cgnat.pdf.

A brief side note – I do not think that making IPv6 ‘better’ through more stringent security will work. 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.

I do agree that if we find desirable functionality that is only possible in IPv6 then this is a useful incentive towards IPv6 deployment. We have had clients that have deployed IPv6 for these types of reasons such as deploying Microsoft’s DirectAccess or because Apple mandated IPv6-only support for all apps in the Apple App Store.

We have been searching for an IPv6 “killer app” for over twenty years. It remains elusive. The problem is that the killer app is the Internet itself and both IPv4 and IPv6 appear to provide this.

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.

Overcoming Blockers: We have no budget for IPv6

Deploying IPv6 can require a significant budget. However, this is not necessarily the case. Indeed, with foresight it is possible to eliminate many elements of an IPv6 budget in their entirety.

It is prudent in business to avoid unnecessary costs. In the case of IPv6 deployment a few simple policies can both facilitate the deployment of IPv6 and reduce the budget required significantly. Here are some examples:

Purchasing

Implement a purchasing policy that states that all network hardware, software and services purchased must be “IPv6-ready”. Not doing this runs the risk of making purchases that will need to be replaced when IPv6 is deployed. Defining and communicating what “IPv6-ready” is can be difficult. However, for may enterprises this statement alone, without further definition, will go a long way to creating an IPv6 deployment ready environment without the need for any additional budget.

Note that RIPE and other organisations have produced helpful guidance on IPv6 purchasing.

IT Training

Mandating that all IT training that has any reference to IP networking must include IPv6 along with legacy IPv4. Do not forget to include IPv6 as a requirement when recruiting new IT staff.

Opportunities for Stealth Deployments

I am not advocating deploying IPv6 without authorisation, rather I am recommending that enterprises should be thinking of how other IT projects could be used to deploy IPv6. For example, an office move might be an opportunity to make a new network IPv6-ready, IPv6-enabled or even IPv6-only. We have clients, with no specific IPv6 budget, who have deployed new networks as IPv6-only. Not only does this have no IPv6 deployment cost, but it also avoids the additional cost of operating a dual-stack environment.

The common denominator in all the examples above is that to do this an organisation needs to be thinking of IPv6. There needs to be an acceptance that IPv6 is the future and a determined effort to seek opportunities to deploy it. Otherwise, IPv6 deployment will remain a project with a budget that may be difficult to justify.

Overcoming Blockers: We lose the benefits of NAT44

Currently there is no good IPv6 solution for the subgroup of enterprises that use NAT44 for multihoming. Some will resolve this problem by obtaining PI space and either running BGP themselves or having their ISPs advertise their PI space on their behalf. Others will resort to undesirable solutions such as Network Address Prefix Translation (NPTv6).

In the future, enterprises will be able to use new standards-based solutions such as Provisioning Domains (draft-ietf-intarea-provisioning-domains-01), Enterprise Multihoming using PA Addresses (draft-ietf-rtgwg-enterprise-pa-multihoming-06) or Source Address Dependent Routing (draft-ietf-rtgwg-dst-src-routing-06). Until then, this remains a problem that is most likely to be addressed by using NPTv6.

Final Comments

Underpinning everything in this post is the need for a change of thought. The world today thinks of IPv4 as being the current version of the Internet protocol. IPv6 is seen as an addition that can be added on as a secondary, less important protocol. For any movement in the deployment of IPv6 to take place, we need to have a change in thinking. We, and others, need to believe that IPv6 is the current version of the Internet protocol and that IPv4 is a legacy protocol, inferior, broken and deteriorating.

12 Comments

Julien says:
19 Jun, 2018 01:28 PM
The only way IPv6 will be implemented is when IPv4 truly runs out of available addresses. New organisations will have no choice but to deploy IPv6.

With that said, there is so many things wrong about this article. Performance improvements in IPv6 ? Last I checked, most websites were slower to load on IPv6 than on IPv4. Don't go cherry picking 3 websites that load faster. "Performance" is simply not an argument for IPv6.

Analytics ? Are you saying NAT makes it impossible to do proper analytics ? Web analytics is done mostly with cookies and web browser fingerprinting. IP addresses are usually not used, or as a last resort. That's another odd argument.

The increasing use of Carrier-Grade NAT & IPv4 expiration is honestly the only argument in favor of IPv6, and they're sufficient. There's no need to make other bogus claims.

All in all, your arguments to solve the blockers are very unconvincing compared to the hurdles of implementing IPv6. Nobody likes IPv6. Nobody wants to work with it. And all of the concerns are very valid.

Calling IPv4 an "inferior" and "broken" protocol when IPv6 has been failing for over 20 years ? That's bold.
Thomas Schäfer says:
19 Jun, 2018 03:14 PM
"Nobody likes ...."

Please, don't say "nobody" when you mean only yourself.
mrthax says:
19 Jun, 2018 06:08 PM
I think this is spot-on. I was hoping to see some interesting suggestions for solutions to the blockers mentioned, but, as you said, I think they are unconvincing.
David Holder says:
21 Jun, 2018 10:50 AM
Thanks for your comments. There is no doubt that the biggest driver for IPv6 adoption is the exhaustion of IPv4 address space. In recent months I have had an increasing number of calls from clients whose plans to adopt IPv6 have been accelerated due to the exhaustion of their IPv4 address space. Some are LIRs others are well-known global enterprises.

I imagine that most readers of this blog will know that the IANA address pool was exhausted on 3rd February 2011, APNIC on 19th April 2011, RIPE on 14th September 2012, LACNIC 10th June 2014 and ARIN 24th September 2015. Today, if you require additional IPv4 address space you have limited set of options. If you are a new LIR then you can obtain a one-time-only /22 (1024 addresses). We have clients in this category and for them having only 1024 addresses is a significant challenge for their business. If you are not a new LIR then you may; (1) go to the address transfer market to buy address space, (2) purchase an organisation that has space, (3) free up existing address space and (4) find another way. We have clients who have taken all these approaches.

So, it is true that the IPv4 address space exhaustion is a powerful driver for IPv6 adoption. However, it is not the "only way IPv6 will be implemented". The reason for this is that the IPv4 address exhaustion indirectly affects everyone. CGN is one example of this. You may not be behind CGN, but those that you communicate might be. Another example would be the ongoing fragmentation of the IPv4 address space. This has implications for routing, geolocation, address reputation and address space squatting.

Performance is a huge area that we cannot do justice to here. As I indicated, one significant problem is that of obtaining meaningful measures. No one can measure the performance of every dual-stack node to every other dual-stack node. Hence every report of IPv6 performance has been different (although usually better or very close to IPv4). However, the point I was making was that in "our experience" around the world, in a wide-range of different scenarios and networks, we have found that IPv6 performance is almost always better than IPv4. Even when we would have expected it to be worse. If I had chosen to "cherry pick" I could have written about some of our clients where they experienced massive improvements in performance after deploying IPv6. For example, one client operating in Europe and Middle East migrated their WAN and WAN applications to IPv6. Afterwards it was ten times faster than IPv4!

No, you are right I was not saying that NAT or CGN makes it impossible to do analytics! I was specifically referring to analytics that depend on IP address. Whilst there are a lot of analytics that make use of cookies and fingerprinting it is not true that the use of IP addresses for client identification has diminished. It is often impractical or even impossible to use cookies or fingerprinting for client identification particularly in environments with high volumes of traffic or where speed is critical. Also, it is important to remember that there is a huge installed base of products and systems that continue to use IP addresses as an identifier.

I agree with you that CGN and IPv4 address expiration are by far two of the most powerful arguments in favour of IPv6. I do not agree that my other claims are bogus!

Thomas is correct, "nobody" is an exaggeration! ;-) There is a huge body of organisations that have deployed IPv6. Including many of the world's leading technology companies. Our clients who have deployed IPv6 come from all sectors and sizes of organisations.

Whilst there can be challenges in deploying IPv6 it is often much easier that people believe. We have found that the most important factor in successful IPv6 deployments is making sure that key staff have a good knowledge of IPv6 before you begin.
Cookiemonster. says:
22 Jun, 2018 07:12 AM
I think you confuse Internet with the World Wide Web, there are plenty of protocols that don't run over http(s) and that also are subject to analytics.
Thomas Schäfer says:
19 Jun, 2018 03:11 PM
Enabling IPv6 means also you should be able to disable IPv4 - at the moment of course only in particular areas.
But some people, even people promoting IPv6, have a limited foresight.
e.g.
https://issuetracker.google.com/issues/109894277
Conflicted says:
19 Jun, 2018 05:17 PM
Disclosure: author of this article also runs an "IPv6 consulting" company for enterprises. If I understood right, the author makes money thanks to IPv6 being difficult to implement. Author would be broke if IPv6 were well designed.
David Holder says:
21 Jun, 2018 10:55 AM
Hi "Conflicted",

Thanks for the "disclosure". It isn't really something I keep secret! I appreciate the advertisement ;-).

Frankly, the perception that IPv6 is difficult to implement is a hindrance to deployment. This is probably not a great advantage in selling IPv6 consultancy or training services. Having said that, if it was easy, many of us in the industry wouldn't have a job!
Backward says:
20 Jun, 2018 02:38 PM
To me the biggest issue is "why could ipv6 not have been made backwards compatible with ipv4". I understand a lot of effort and the reason for using hex etc etc. But if instead of 255:255:255:255 we had FFF:FFF:255:255:255:255, it might look messy but solves so many issues.

This is how my phone operator increased the number of phone numbers. They brought a 0 prefix to all current numbers and added 1-9.

all current ipv4 mapped by dual stacked models as ::ipv4 require much more setup than one expects.

Never understood why this is not done.
Thomas Schäfer says:
20 Jun, 2018 03:32 PM
Your suggestion is also a complete protocol change, including all the the stuff we have done with the upgrade to IPv6.
Don't forget the address is handled by a lot of devices. So an update to a 64-bit-address would have the same effort as the update to 128 had.
Implementations of IPv6 are almost finished. We already in a phase where we can say - just switch it on.
David Holder says:
21 Jun, 2018 10:57 AM
You are absolutely right, after a couple of decades we are now at the stage where just switching on IPv6 is possible. Most of the technical blockers have gone. It is a great time to be deploying IPv6.
Abraham Y. Chen says:
21 Jun, 2018 10:58 PM
The fundamental blocker to the IPv6 deployment may be what has been in the rumors, such as the IPv6 is not a super-set / direct upgrade replacement of the IPv4. In addition, I heard that IPv6 can not encapsulate IPv4 packets, while the reverse has been working. If these were true, they present a lot of hurdles for system planners.

A few years ago, we accidentally ventured into studying the IPv4 address pool exhaustion challenge, perhaps due to our curiosity from telephony background. We now have submitted a proposal to IETF. named EzIP (phonetic for Easy IPv4):

   https://tools.ietf.org/[…]/draft-chen-ati-adaptive-ipv4-address-space-03

EzIP will not only resolve IPv4 address shortage issues, but also mitigate the root cause to cyber security vulnerabilities, plus open up new possibilities for the Internet. These should relieve the urgency to deploy IPv6.

Feedback and comments would be much appreciated.

Abe (2018-06-21 16:56)
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.