You are here: Home > Publications > RIPE Labs > Mirjam Kühne > Commercial Incentives of IPv6 Deployment
Content by this author

Commercial Incentives of IPv6 Deployment

Mirjam Kühne — 21 Feb 2017
This article is based on the IPv6 Best Practices document published for the Internet Governance Forum 2016 by Izumi Okutani, Sumon A. Sabir and Wim Degezelle.

 

An IPv6 Best Practices document was published for the 11th Internet Governance Forum (IGF), held in Guadalajara, Mexico in December 2016. The IGF is an annual global conference organised by the UN and open for anyone to participate.

About the IPv6 Best Practices Forum

As part of the IGF’s community intersessional work program, Best Practice Forums provide an open platform to collect and exchange experiences on Internet governance-related issues. IPv6 adoption was selected as the topic for a Best Practice Forum for the second consecutive year. The group looked at commercial and economic incentives to deploy IPv6 and published a document, written with substantial contributions from Regional Internet Registries (RIR) community members.

The document was developed through online discussions on a dedicated mailing list and regular calls several months before the IGF. Anyone was welcome and free to contribute. In addition, we collected 20 case studies across different regions.

This article highlight some key points of the document. Note that the document is not very technical, and a lot of the information described here will likely not be new to you. The document is targeting policy makers and business decision makers, and members of the RIR communities were contributors rather than the target audience. 

The complete document of the 2016 IGF BPF on Understanding the commercial and economic incentives behind a successful IPv6 deployment can be found online. There is also a video of the BPF on IPv6.

General trend of IPv6 deployment

Several major global players are commercially deploying IPv6 as well as some local players in different regions of the world. When looking at a map that shows the IPv6 deployment rates we can see that there are big differences between countries and that these differences cannot always be explained by traditional economic variables (e.g. GDP or the state of development of the Internet in a country). For example, Ecuador, Peru, Greece, and Trinidad and Tobago are among the top 20 countries in the world when it comes to IPv6 deployment, with no correlation to their GDP. While the world average deployment rate of IPv6 is a little less than 8% as of the end of 2016, deployment rates per countries and individual players vary. Some countries or players show a much higher deployment rate than the world average, as high as 50%, while other countries or players have a deployment rate of zero.

2016 saw several notable developments around IPv6. In the area of mobile, Apple made an announcement that all applications submitted to the App Store must support IPv6-only networking as of 1 June 2016. This is expected to result in a jump in direct native IPv6 traffic. One of the reasons for this requirement was the decision by a major mobile operator in the US to eventually cut off all IPv4 underlying connectivity on Apple iPhones. In the area of standards development, the Internet Architecture Board (IAB) published a statement that the IETF will stop requiring IPv4 compatibility for new or extended protocols. Future IETF protocol work will then be optimised for and depend on IPv6. This means that vendors do not need to support IPv4 in future protocols developed by the IETF to comply with the IETF standards.

In terms of customer demands, most users are not aware of what IP version they are using, however, they might see their user experience degrading if their provider does not move to IPv6. In a world where IPv4 connectivity goes through a Carrier Grade NAT (CGN) box, it loses the end‑to‑end connectivity and applications degrade and become difficult to use, such as gaming, video streaming and downloading large files. Therefore, your customers may not explicitly request for IPv6 but you may receive customer complaints in such circumstances.

The end user environment is also getting IPv6 ready without users being conscious of it. Major global content providers, recent versions of both Windows and Mac OSs, and major cloud/CDN service providers such as Akamai and Cloudflare, all support IPv6. If an ISP turns on IPv6 by default, without asking its customers to apply for IPv6 service, a substantial volume of traffic is expected to be observed in IPv6. As of the end of 2015, projections of the IPv6 percentage of IPv6-enabled web browsers show approximately 15% now but if the rate of current growth continues, it is extrapolated to be 20% by the end of 2017 and around 35% by the end of 2019 (according to Google).

Observation per industry sector

Observations per industry sector shows that there are several commercial ISPs in various regions that allow access over IPv6, and there is substantial commercial deployment in this sector. For ISPs, nearly all current routers and access equipment support IPv6. At the same time, although it is technically ready and commercial IPv6 deployment is observed, there is still room for improvement in this sector. According to a calculation done by Geoff Huston, APNIC’s Chief Scientist, in May 2015, the 30 largest ISPs serviced 42% of the entire Internet user population. If large providers deploy IPv6, the global deployment rate goes up visibly - at the time of writing it was 20%.

Major cloud services and Contents Delivery Networks (CDNs) provide IPv6 by default. Up-to-date operating systems for both Windows and Mac are IPv6 supported. Major global content providers make their content available over IPv6. In other words, the environment for end users is getting ready without them having to be aware of IPv6. If an ISP turns on IPv6 by default, we expect a substantial amount of IPv6 traffic. Rapid growth in IPv6 traffic is observed by some mobile operators, with over 70% traffic observed over IPv6 for T-Mobile and Verizon Wireless in the US and Reliance Jio in India.

IPv6 adoption can also be observed in some applications outside the conventional global Internet connections. Some examples are the use of IPv6 in nationwide smart metres for electricity supplies and IPv6 multicast services as an infrastructure platform for image streaming on a nationwide scale by Japan's largest Telecom with over 19 million subscribers. They see the benefit in IPv6 for a large-scale multicast service. Continental's website is IPv6-ready and they have presented their steps towards IPv6 deployment: first network infrastructure, then devices and services and then innovation. There are several banks and financial institutions that have adopted IPv6, such as Banrisul, Banco do Estado do Rio Grande do Sul, Rabobank and Wellsfargo. Sony's corporate network is now running on IPv6. It also provides commercial TV which can be connected with IPv6.

On the other hand, challenges are observed in sectors such as IXPs and data centres. Also local content is not yet IPv6-capable in many cases. In October 2016, only 5.8% of the Alexa top one million websites was IPv6-ready, and 22% of the Top Alexa 1,000 websites. Vendor support is needed in specific areas such as security features and functionality which needs consistent enhancements for both IPv4 and IPv6. IPv6 adoption cases for corporate networks are not large in number but global corporations such as BMW and Sony have deployed IPv6.

Major motivation for IPv6 deployment

Over 20 case studies collected from different regions by the Best Practices Forum showed the following key motivations behind IPv6 deployment:

  1.  Declining availability and rising cost of IPv4 addresses/Accommodate significant customer base growth;
  2. Corporate image of being prepared for up-to-date technology/environment;
  3. Migrating to IPv6 without further IPv4 growth is more cost-effective solution;
  4. Business opportunity

Common challenges

The case studies collected by the BPF not only showcase successful deployment, they also identified some challenges. The main challenge in thdecision-makingng process is the difficulty defining a clear business case for the deployment of IPv6 with, for example, the generation of additional income within a certain period. The deployment itself takes time and planning. The complete network infrastructure needs to be made IPv6-capable and the technical team can come across specific issues and bugs. There is a clear call for more vendor support for IPv6. A decent training for the technical staff is indispensable and will avoid problems and misconfigurations. For small companies and providers with a limited technical staff, it can be more challenging to organise training so that staff has sufficient knowledge to deploy an IPv6 network.

For ISPs with a large number of customers, replacing all the CPEs in customer premises is a time intensive and costly process. It is more cost efficient to spread the deployment over a longer period and include IPv6 in the regular or planned maintenance or upgrade cycle. Equipment bought by customers might create its own challenge, as most customers are not aware of the difference between IPv4 and IPv6 and whether their equipment is IPv6-ready. It is important that customers choose IPv6-enabled equipment to avoid costs and issues later on. If an ISP only offers IPv6 upon request or as an opt-in option, it will slow down the speed of the deployment.

In developing countries, challenges such as bandwidth limitations or the use of IPv4-only second-hand equipment are a serious hindrance.

At the IGF, the BPF on IPv6 discussed the takeaways from their 2016 work.

Takeaways for policy makers

  • Encourage vendors to support IPv6.
  • Reach out to decision makers in the industry and encourage policy makers to stimulate the industry, taking into account the the local situation and environment.
  • Raise awareness and inform consumers, for example by sharing information on which products support IPv6 and encourage the purchase of IPv6-supported CPE.
  • Support IPv6 training for engineers, in particular for small- and medium-sized businesses and in developing countries. Training could be organised in collaboration with private organisations. The trainings organised by RIRs are a good example.

Takeaways for business decision makers

  • Every person, business, government and organisation that today depends on the Internet must understand that IPv6 is needed if they want to continue to rely on the Internet in the future. Doing nothing hurts, as eventually it will be necessary to use IPv4 translators which will impact user experience and cost.
  • Consider IPv6 for long-term business sustainability. IPv4 addresses are a limited and a finite resource. It is unlikely that you can continue buying all the IPv4 addresses you need. IPv4 address sharing technologies such as CGN cost money as well, and can have higher operational costs than running IPv6. Some applications or services might not work correctly without native IPv6. Customers are not aware of IPv6 but might complain about a degrading quality of service.
  • IPv6 deployment is no longer an "insurance" for an unexpected situation.

Takeaways for vendors

  • Have your products support IPv6!

Especially for consumer products and the security features and functionalities for both IPv4- and IPv6-capable devices need consistent enhancements as the Internet keeps evolving.

Takeaways for service providers

  • Choose IPv6-supported products when updating or renewing the network.
  • When deploying IPv6 commercially, turn it on by default (not as an opt-in). Do not require your clients to ask for IPv6. Several companies have already done this without major complaints from their clients.
  • Training your staff is not hard if they already know how to run an IPv4 network. Make use of the available external training courses. Problems with IPv6 are often caused by simple misconfiguration. Having your staff properly trained will help to avoid them.
  • Not deploying IPv6 in a new infrastructure and service is a wasted opportunity and a waste of money. Every purchase decision by an individual, government, company or organisation should ask for IPv6, even if their own network is not yet ready. This will save on upgrade and replacement costs in the future.

Potential for further analysis

Further research could help to better understand what factors stimulate and hinder the commercial deployment of IPv6. The BPF on IPv6 is the work of a group of community volunteers. Some specific questions would require more specialist research. It is suggested that further research is done among others around the following questions:

  • What is the decision making process around IPv6 deployment by industry players? Is this decision driven by individuals or triggered by external factors? And are there differences between regions? For example, cases in the Asia Pacific region show more tendencies to have external factors such as government encouragement and/or joint community initiative, compared to cases in Europe or the US.
  • What other factors can be found that can explain why the IPv6 deployment rate is high in some countries and why other countries are lagging behind?
  • What is the link between IPv6 deployment, Internet penetration, Internet development and economic development? Certain countries have a high IPv6 deployment rate, while others with similar economic development, or Internet development do not show high deployment rate. Is there a correlation between IPv6 deployment and other technologies that are encouraged by the operational community, such as DNSSEC?
  • How can we explain that there are countries with low IPv6 deployment rates but high usage rate, and vice versa?
  • Do operators with new or small IPv4 networks have a better chance to develop higher IPv6 capability than those with large networks? Do newcomers to the industry have a better chance to have a high IPv6 deployment rate, if they build networks which support IPv6?
  • Is there a correlation between operators with a high IPv6 deployment rate and high cycle of equipment upgrade?

 

Thanks to the RIR community

We would like to thank the members of the RIR community. Many have made substantive contributions to the content of the document, both online, during the calls and at face-to-face interviews. The list of contributors are listed in our output document, with several names many of you may recognise. Special thanks to Aaron Hughes and Marco Hogewoning, who have planned the BPF activity together with us, and have served as the core contributors.

 

About the authors

Izumi Okutani and Sumon Sabir served as members of the 2016 Multistakeholder Advisory Group (MAG) of the Internet Governance Forum (IGF) and coordinated the work of the Best Practice Forum on IPv6.

Wim Degezelle, served as consultant with the IGF secretariat to support the work of the BPF on IPv6 and act as pen-holder.  

About the IGF Best Practice Forum on IPv6

IPv6 adoption was selected as the topic for a Best Practice Forum (BPF) of the IGF for the second consecutive year. As part of the IGF’s community intersessional work program, BPFs provide an open platform to collect and exchange experiences on Internet governance issues. The 2016 BPF on IPv6 was active during the months leading up to the IGF and recently produced a best practice outcome document.

2 Comments

ExSiXXsuser says:
20 Apr, 2017 01:00 PM
Thanks for this survey!

From a user's actual experience the reality rather depressing. For example my ISP has a /32 prefix
and refuses to provide its customers with statically assigned prefixes.
One of the purposes for having IPv6 in the first place was to restore end-to-end connectivity IIRC.
Assigning ephemeral prefixes contravenes this.

When RIPE allocated IPv6 prefixes to ISPs (aka LIRs) in early 2000, was there a
clause or policy that recommended to assign static prefixes to customers?
Written statements by RIPE to that effect would be nice to reason with ISPs.

Best regards!
Marco Schmidt says:
21 Apr, 2017 11:40 AM
Hello ExSiXXsuser,

Neither the RIPE IPv6 policies in the early 2000 nor the current IPv6 policy contain a specific recommendation or mandate for LIRs to assign static prefixes to customers. The current IPv6 policy mentions the minimum value of a /64 but makes no comments about static or dynamic assignments.
https://www.ripe.net/publications/docs/ripe-684#assignment

You might be interested to know that currently the RIPE BCOP TF is working on a document that seems to deal with situation like yours
http://www.internetsociety.org/[…]/draft-IPv6pd-BCOP-v1.pdf

Maybe you are interested to join that discussion?

Marco Schmidt
Policy Development Officer
RIPE NCC
Add comment

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.