The internet is still expanding. Even more, we’re facing a major explosion of the number of devices connected to the internet. The rise of smartphones, wearables and the Internet of Things are evolutions that will expand the number of connected devices to numbers unseen so far. The transition to IPv6 is inevitable, but why does it seem to take so much time?

Reason 1: It’s bloody expensive

The internet is made up of millions of routers and switches. Those were initially designed to work with IPv4. Replacing or upgrading them takes time and budget.

For the edge network, the solution is time. End-user equipment is replaced regularly in general, but it exists out of billions of devices. There will still be many old home gateways, print servers, … unaware of and incompatible with the IPv6 protocol.

For the core network, replacing core routers with expensive hardware is something which isn’t done everyday. This means this transition even takes more time and money.

Reason 2: NAT to the rescue

IPv6, initially released in 1998, extends the total number of addresses to more than 7.9×10^28 times as IPv4 does. The IPv4 address exhaustion was the major driver to develop IPv6.

But by the time the IPv6 specification had matured, NAT was already used all over the internet, extending the lifetime of the IPv4 protocol. NAT can be deployed incrementally in the internet at a low cost while also providing some basic security. On the other hand, NAT also comes with some drawbacks and will not be able to scale far enough for future needs.

Reason 3: Compatibility please!

During the design of the IPv6 protocol, backward compatibility was not on the requirements list. According to Leslie Daigle, Former Chief Internet Technology Officer for the Internet Society, this lack of compatibility with the current IPv4 protocol was the single critical failure.

Because of this, the transition towards IPv6 does not provide a single, standardized solution to communicate with devices and systems that still run IPv4.

Reason 4: I will not do it if you don’t

The lack of compatibility requires operators to run IPv4 and IPv6 concurrently for the foreseeable future. This means a higher cost in maintenance now, with benefits becoming only visible when other networks are also switching to IPv6. There is no direct benefit of being an early adopter. Nobody will switch to IPv6 as long as none of their contacts is switching too.

Reason 5: It doesn’t reach the eye

While the adoption of IPv6 goes much slower than initially planned, the transition is already taking place. At this point, somewhere between five to six percent of traffic reaching Google is IPv6 traffic. Not much, but at least a 2 percent increase from last year. More importantly, the transition is gaining momentum and going faster and faster each month.

Google keeps statistics on the percentage of users that access Google over IPv6, and as of today that looks like this:

But, many people just don’t know. The end-user is unaware. The current operating systems are ready for IPv6 and, if available, will use it seamlessly in conjunction with IPv4.

IPv6 has been slowed down for many reasons, but the transition already started and we can expect a faster and faster adoption in the years to come. IPv6 doesn’t arrive with the big drum but gets widely applied in silence all over the world.

Reader interactions

10 Replies to “5 reasons why the adoption of IPv6 takes so long”

  1. Ross Chandler June 28, 2015 at 6:29 am

    IPv6 isn’t expensive at all because hardly anyone ever pays specifically for an IPv6 feature. They add in IPv6 as an RFP requirement when buying something equipment for another reason like growing traffic or needing more ports. This has also meant that vendors have hardly pushed IPv6 deployment at all.

    20% of users in the USA already have IPv6 according to Google stats and it is growing well. It is now harder to justify delaying than deploying.


  2. Thanks for your reply!

    I agree IPv6 is not expensive if you add it as an additional requirement when buying new equipment. It is expensive if you need to replace your existing equipment just to be able to deploy IPv6. That was a good reason to delay IPv6 deployment for a long time and is now more and more irrelevant.


  3. Jean-Christophe Perrault September 30, 2015 at 6:30 am

    It is expensive if you consider training and configuration time. IPv6 is a significant change for most network admins. While the ISPs might see advantages to switching most SMB will only see increase complexity for most of their IT staff who are currently used to IPv4. I have a very hard time coming up with a reason to make them switch. To me, this is similar to switching your infrastructure from HP to Cisco, yes, it is better but your trained staff will really struggle and you might see very little difference.

    And seriously, I know all my important devices IP if I need to remote/console into it. I can’t memorize one IPv6, not cool.

    I don’t see any SMB switching to IPv6 in the near future. I see a world where the backbone is v6 with 6to4 on the edge to accomodate the businesses… until the robots take over, they won’t struggle with those crazy 128 bits addresses.


  4. ipv6 has taken so long because it’s a huge mistake. The problem could be solved in the same way that the telephone# problem was solved; add a country code. 1 byte (there’s only 196 countries). It could be implemented in a day, and would actually be quite useful to know what country traffic was originating.

    You can’t retrain a world that barely understands what a class C address is in a new, complicated protocol. ipv6 is an ill-advised disaster and countries that force adoption will suffer greatly. It’s unnecessary. It’s stupid.


  5. @Dennis
    absolute rubbish – add a country code … not an easy job just add one byte – in bigger routers it is not even software most of them use asic’s to be fast enough so no just add sth
    L3 switches are what most of the providers are using to aggregate the customer traffic so just add a country code wont do it.

    IPv6 is the present – and it will be necessary if you think about IoT and so on.

    Providers in Europe and US are happy with ipv4 because there are enough ipv4 addresses in use now they don’t want to change.

    UPC (big cable opreator accross Europe) switched a year ago to native ipv6 and does CarrierNAT on its Customers with ipv4 it is possible and obivously a good idea.

    NAT is an ugly beast most network software has to work around (eg. passive ftp, need for relays for p2p software, … you get the picture)


  6. I’ve been following IPv6 since 1999, when everybody in the academica and major equipment providers forecasted the inminent end of IPv4 in “few years”. In my opinion, there are two additional reasons:
    1. Security. With every connected device potentially able to get easily a public IPv6 address instead of a private behind a NAT, it would arise the thread of unathorized access or attack from anywhere in the world. Certainly, there are proxies, firewalls, etc. but the risk will be increased, even more, if all those devices get connected wirelessly (via 4G/5G or WiFi).

    2. The problem is not at the layer 3. In the recent years the evolution of the telecom industry has experienced a major paradigm shift, where the compatibility, scaling and functionality have been translated to the application layer and has a loose or weak relationship with the layer 3 (using the network architecture jargon).

    So, let’s wait some more years to see if Ipv6 finally get momentum … or not.


  7. @Jose Munoz
    I certainly agree that security will be a new challenge when switching to IPv6. But with the upcoming IoT revolution security will be important and a primary concern for a while, with or without IPv6.


  8. “If it ain’t broke, don’t fix it.”

    Network equipment will not be replaced until fails. In my country you can find Enterprises, ISP connecting to network hops identified as “impsat”, a “Dot-com bubble” ISP purchased by Global Crossing. Of course, zero ipv6.

    Progressively, all network equipment will be replaced.


  9. Abraham Y. Chen June 24, 2018 at 6:34 am

    Your observations and reader comments are quite interesting. Many of them echo in my mind. Particularly, the compatibility aspect is something really puzzling me as a system engineer. Allow me to share a bit of our experience.

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

    EzIP will not only resolve IPv4 address shortage issues, but also largely mitigate cyber security vulnerabilities, plus open up new possibilities for the Internet. These should relieve the urgency to move onto the IPv6. Originally, our efforts were inspired by two regularly updated worldwide statistics:

    So, we thought that the initial EzIP targets would be emerging regions and rural areas of developed countries where assignable IPv4 addresses are in short supply. A recent article about the Internet activities provided a surprising new perspective:

    It concluded that the IPv6 adoption even at US Federal Agencies was moving at “a glacial pace”. This seems to imply that the entire market for alternatives to the IPv6 approach, such as the EzIP, is now open. The general public should be equally informed of this kind of choices, instead of being led by the existing industrial interests. Hopefully, these provide you some updated references to review the web information.

    Feedback and comments are very much appreciated.

    Abe (2018-06-24 12:15)


  10. Abraham Y. Chen July 7, 2018 at 6:35 am

    I like to supplement two recent references about the IPv6 situation:

    A. UN ITU is drafting a Recommendation to reconfigure the IPv6 for avoiding digital divide, etc., among other considerations.

    B. This made IETF very uptight:

    It looks that a serious review of IPv6 is forthcoming.

    Abe (2018-07-07 15:19)


Leave a Reply

Your email address will not be published. Required fields are marked *

The reCAPTCHA verification period has expired. Please reload the page.