6connect’s CEO, Aaron Hughes, worked amongst IPv6 leaders for the past several months on creating the IGF 2015 Best Practices Forum on IPv6, a ~70 page document that was prepared for the International Governance Forum held in November in Brazil. In addition to spending several months preparing this important industry document, Hughes was a speaker in two panel sessions. This is part 2 of a 6 part series with critical information pulled from the Best Practices Forum. Part 1, Why Adopt IPv6?, can be found here; part 2, Hurdles to IPv6 Adoption, can be found here; part 3, IPv6 Task Forces: A Platform for Best Practices, can be found here.
In Section 4, we examine best practices identified within private sector organizations – namely by ISPs and content providers. The Best Practices Forum (BPF) discussion revealed that ISPs and content providers share many best practices in common. This section reviews those practices.
Approaches to deployment depend on local considerations. As with other illustrations in this document, the practices described below are offered only as suggestions.
Review existing infrastructure
ISPs and content providers can begin planning for IPv6 deployment with a detailed review of their existing infrastructure, including software, services, support systems (including sales and customer support), and administrative processes. As one contributor noted:
During this process, it is common to learn a great deal about your underlying supporting infrastructure, and either establish a better relationship with existing vendors or … establish new relationships with vendors who support IPv6 and want to be your partner through this transition.
The review will ideally result in the identification and assessment of any and all dependence on IPv4. This will then allow the identification of all impacts of IPv6 adoption, as it impacts on the identified dependencies on IPv4.
Determine whether vendors are IPv6-ready
One challenge identified during the BPF related to the capacity of vendors to support IPv6 products and services. According to one contributor:
There is still a long way to go in terms of IPv6 support in a lot of the equipment out there. A lot of network gear is still IPv4 only on the management interface. Many vendor implementations are buggy.
When working with vendors, organizations must be prepared to test every function and feature equipment to ensure that it meets their needs. Based on the discussion during the BPF, IPv6 is not yet well understood by the majority of vendors. One contributor suggested that companies confirm vendor expertise in IPv6 before engaging in a contract. One contributor said “many vendors will tell you they are IPv6 ready, but this may not [necessarily] mean that parity exists for features which exist in IPv4.” Another survey response explained:
Don’t buy any equipment that doesn’t have the IPv6 features that you need. If a manufacturer says that IPv6 is “coming,” don’t take their word for it. Make sure they at least show you a working beta.
Vendors’ expertise and ability to fully support IPv6 will make a critical difference for businesses engaged in IPv6 deployment. In Singapore, ISP StarHub explained that the roll-out of IPv6 was not without challenges, but its vendor was were there to assist:
There were challenges along the way, mostly dealing with the scaling of routing tables to deal with a larger than expected deployment of IPv6-capable Customer Premise Equipment. Our vendor’s quick turnaround time and support allowed us to get back on track quickly, and we are happy to see continual growth in IPv6 traffic as our rollout continues.
Thus, it is critically important for the business to know whether its vendor supports IPv6, and if not, whether and when that vendor is willing to take steps to become IPv6-ready. One option, of course, is to contractually require vendors to be IPv6-ready. The US Department of Defense requires the vendors they work with to have dual-stacked their own websites. While this may not be directly relevant to the services required from such vendors, it provides an important indicator of their commitment to and capabilities in relation to IPv6.
Finally, another notable measure which was cited during the BPF, relating to IPv6 readiness requirements is that, since the introduction of iOS 9, Apple requires iPhone and iPad applications to support IPv6 in order to be carried by the Apple App Store.
Provide employees with training and knowledge
IPv6 expertise among technical staff is, of course, an absolute necessity for smooth deployment and operation of IPv6 capabilities. In terms of employees with non-technical roles, who interact directly with customers in the sales, account management, and customer service departments, they should possess an awareness if not a high-level understanding of IPv6. This recommendation of course relates primarily to ISPs, content providers, and other business in the ICT field. The manager of a restaurant, for example, need not be required to understand IPv6 issues, but their technical staff must.
Deploy IPv6 for public-facing services
ISPs and content providers should aim to offer end users IPv6 services through a dual stack approach, meaning that both IPv6 and IPv4 are used. Organizations can begin work on dual stack implementation by taking inventory of all outside, public-facing IPv4 services. This should help to define the steps that need be taken to enable dual stack technology. As one contributor summarized:
The simplest approach is to work from the outside in.
When content providers enable IPv6 access to their public-facing services, they immediately enable better access to their content; all IPv6-ready end users will immediately and automatically bypass the IPv4 bottlenecks of Network Address Translation and Carrier-Grade NAT. Dual stacking public-facing services improves the experience of IPv6 end users without affecting IPv4 end users.
ISPs and content providers who use Content Distribution Networks (CDNs) should contact their CDN about IPv6. Many CDN providers today offer dual stack services by default, though some will only enable IPv6 services upon request. For businesses who do not work with CDNs, enabling dual stack means ensuring that all load balancers, name servers, mail servers, web servers, app servers, etc., are available over both IPv6 and IPv4.
After deploying dual stack access to their public-facing services, Facebook saw an increase in performance for its mobile end users. In March 2013, it was reported that certain users connecting to Facebook via IPv6 were doing so “on average … about 30% faster” than users connecting via IPv4. As software engineer Paul Saab explained, “This is great for our users because that means their news feed loads faster, their pictures load faster – everybody’s happier when things are faster.”
The Canadian ISP Communicate Freely decided to deploy IPv6 in 2011 after the company encountered problems securing IPv4 addresses. The company considered “IPv6 adoption [to be] the ‘new normal’ for all IP connected systems.” The company explained in its survey response that it has since made IPv6 available to 100% of its customers via dual stack technology.
As of September 2015, 50% of Facebook’s traffic to 4G smartphone users in the U.S. was being delivered via IPv6.
Once public-facing services are dual stacked, then businesses should consider “work[ing] inwards, making sure that all back-end gear is singled stacked” – in other words, using IPv6 exclusively.
Set internal deadlines
Given that the pool of available IPv4 addresses continues to shrink, BPF contributors recommended that all businesses plan for the inevitability of no IPv4.
Planning for the inevitable unavailability of IPv4, and the complete adoption of IPv6, with eyes wide open, will make planning for and implementation of IPv6 far easier. Importantly, it will allow for your customers to plan accordingly.
Though simple, the phased plan outlined below was offered by a BPF contributor as one place to start:
- Begin with IPv6 education and outreach to customers and partners
- Support customers in their transition to IPv6
- Require IPv6 adoption by customers, but allow for dual stacking and IPv4 support at the same time
- When the time is right, support IPv6 only
Reach out to customers
One survey response from an ISP described how it sent an “email blast” to its business customers, “explaining the reasons for considering IPv6 adoption.” While the outreach effort, “did raise some level of awareness … very few people were interested” and “a few customers were confused.”
This experience suggests that a steady and repetitive approach to distributing information about IPv6 adoption to customers may be more effective than a one-off email campaign. Updating all customer-facing communications (e.g., invoices, maintenance notifications, marketing material, website, email signatures, etc.) with a note on IPv6 adoption or a link to further information would also be useful. One participant suggested creating and maintaining a wiki as a Frequently Asked Questions page for customers:
There is no better way to answer the same questions from all of your customers than to document them publicly in once place. Not only will you be building a repository for your customers, but you will also be educating your staff on the common issues that your customers face.
For business customers in particular, another suggestion for ISPs was to engage more directly, by inviting them to an on-site training. IPv6 education is a fantastic reason to have a “lunch and learn” with customers. This is also a useful practice for staff.
Consider different approaches to pricing (for ISPs)
The amount of IPv4 address space available will continue to decline, and the cost of supporting IPv4 will rise. To encourage customers to adopt IPv6 over IPv4, ISPs may want to consider passing on the cost of supporting IPv4 by charging the customer for IPv4 but not for IPv6. This approach may suit ISPs with non-residential customers.
In this case, it is important to give the customer clear notice and to explain the rationale supporting the price increase. This is also an opportunity to raise awareness about IPv6 adoption.
The above listed practices can be applied not only to ISPs and content providers, but to other businesses as well. Enterprise-wide IPv6 deployment, however, is a major undertaking that only a few enterprises have experienced. Few examples were identified during the BPF. Contributors suggested that, should the BPF continue, enterprise-wide IPv6 deployment be a future focus area for discussion and research into best practices.
Stay tuned for part five of the series.
Questions? Concerns? You can contact us at 6connect to speak directly with an engineer. If you are looking to automate and scale your provisioning, we’ve got your back.
Email: info@6connect.com or call +1 (650) 646-2206.
