IPv6 Success Stories Shared in ARIN 51 Panel

By Christina Paladeau – Social Media and Content Specialist

ARIN has been publishing IPv6 case studies on our blog since 2017, and we wanted to bring some of these success stories to the ARIN 51 Public Policy and Members Meeting last month. So, we gathered together a panel of five community members who have contributed to those case studies over the years or have other IPv6 deployment experience. Here’s a summary of their compelling and informative discussion and details on where you can watch the full panel for yourself.

Hosted on Day Two of ARIN 51 following a keynote address about Virginia Tech’s 25 years of production IPv6, the IPv6 Succuss Stories panel was moderated by ARIN President and CEO John Curran and featured the following panelists:

• Ben Bittfield – IPv6 Contractor
• Brian Jones – Virginia Tech, ARIN Advisory Council
• Madhura Kale – AWS
• Brent Mc Intosh – MCNET-SOLUTIONS
• Matthew Wilder – TELUS Communications, ARIN Advisory Council

Summarizing Their Stories

First, each panelist gave a short presentation to share the history, status, and impact of IPv6 at their organization, what other organizations can learn from their experience, and more to help others take the next steps in their IPv6 journeys.

Sprint

Currently the IPv6 engineer at Johnson & Johnson, Ben Bittfield reviewed the success story from his time at T-Mobile and Sprint and shared a look at plans for the future at Johnson & Johnson. Ben explained how, at Sprint, they progressed through all the phases of migration from IPv4 to IPv6 while trying to keep up with aggressive smartphone adoption: public IP addresses, carrier-grade NAT (CGNAT), dual stack, and eventually the target state of IPv6-only. “Our target state was always a v6-only world, but it took a while to get there,” he said. “We went from a situation where we basically did not control our own destiny … to where, in a v6-only world … we controlled our own destiny again.”

You can read the case study on Sprint’s journey through IPv6 transition mechanisms for more details on that process. Ben concluded his opening statement by sharing his excitement for the future of IPv6. “When I first started at Sprint, we were talking about predominantly tunneling, and … v4 dual stack where you can, tunnel where you must. And now it’s v6-only where you can and dual stack where you must,” he said. “I like that v6-only is not just practical, but it’s in production and it’s out there. And it should be the default going forward, if possible.”

Virginia Tech

Next, Brian Jones shared a step-by-step history of IPv6 at Virginia Tech. Doctoral candidates took an interest in it in 1997, and then a future-focused, collaborative effort with the operational side of the house began. After receiving an allocation from RIPE NCC on 30 January 1998, they began production of IPv6 on the Virginia Tech campus. For the next 10 years, they worked with vendors, built parallel networks and tunnels, and did what they could to support IPv6 across the campus. In 2008 they emerged from the test phase, and in 2009 Virginia Tech became one of the first places where users could reach Google over IPv6.

Traffic soared and, in 2010, Google ranked Virginia Tech as one of the top five deployments worldwide. They proceeded to consult with the United States IPv6 Task Force, present at the 2011 IPv6 World Congress in London, and emerge at World IPv6 Launch Day in 2012 as one of the top network operators (with nearly 60 percent of the Virginia Tech hosts supporting IPv6). Their deployment has since continued to grow, with nearly 90 percent of Virginia Tech’s network hosts supporting IPv6 today as compared to 45 percent worldwide.

Read Brian’s case study for more details on Virginia Tech’s IPv6 journey.

AWS

Madhura Kale then provided a background of what IPv6 on Amazon Web Services (AWS) — which provides infrastructure that allows different businesses and organizations to build IPv6 — means. AWS launched IPv6 on its Elastic Load Balancer in 2011 and then began introducing additional IPv6 support with more products, including load balancers, DNS, core compute, storage, and distribution.

AWS began seeing customers scale their very large networks. “We’d have customers being extremely creative with how they managed routing space,” Mahura said. “And then several that said, ‘Hey, we want to stop. We want to pull the plug on this. We’d like everything in our internal applications to support IPv6 and v6-only.’” So, in the last few years, AWS has launched IPv6-only for its core compute and Kubernetes services and continuously expanded its IPv6 support for data stores. IPv6-only will soon be available for its serverless compute, too.

To learn more about IPv6 recent launches, read customer success stories, and see a detailed support matrix to demystify the cloud, visit the AWS IPv6 webpage.

Cable Bahamas

Up next was Brent Mc Intosh, who highlighted the challenge faced in the Caribbean of getting Internet Service Providers (ISPs) to provide not just transit IPv6 but also Internet access over IPv6 infrastructure. To provide a valuable example of the latter, Brent presented a case study of Cable Bahamas’ IPv6 deployment. When the 100 percent Bahamian-owned ISP foresaw the challenges presented by IPv4 shortage, it set out to build an access solution using IPv6. “It started from looking at what was required and building the right team,” Brent said. “Building a tech team to get this done was important for them, and they decided [their] solution was to deliver access to content and Internet services over IPv6.”

Brent emphasized the importance of training for their technology and customer services teams. “I was really happy to be part of that training process to get their Internet and their customer service reps up to speed,” he said, “Because no deployment in IPv6 is going to be successful if your supporting teams and your technical teams are not trained.” Cable Bahamas’ business customers and retail home subscribers are now testing IPv6, and just under 10 percent of content is being accessed over IPv6 in advance of the product’s full launch happening soon.

View the slides from Brent’s presentation for a more detailed look at the Cable Bahamas success story, and learn more about Brent’s experience in the case study “Enabling Internet Access Services over IPv6 in the Caribbean.”

TELUS Communications

To conclude the introductions, Matthew Wilder walked through the three stages of planning, building, and deploying IPv6 at TELUS. From 2008 to 2012, they progressed from assembling technical representation across different teams and discussing IPv4 exhaustion to identifying work streams, thinking about edge networks, and creating a structure to guide and organize their activities.

In 2011, they started training. “You need your teams to be aware, educated, and familiar with IPv6,” Matthew said. “We had lots of in-person training as well as [through] e-learning portals.” Then it was on to getting the core network IPv6-capable and establishing peering. In 2012, TELUS launched its first enterprise-managed service with dual stack — the sponsorship of the ARIN 29 meeting in Vancouver, to be exact. After enabling subsystems and service components in 2013 and going IPv6-only for voice over LTE in 2014, IPv6 support for residential Internet services launched in 2015 and traffic from the TELUS subscriber base over IPv6 reached 45 percent that fall.

Read Matthew’s TELUS case study to learn more about practical steps to accelerate IPv6 adoption.

Then, moving into a Q&A session, John Curran asked the panelists to share more details about their deployment experiences. Each provided helpful perspective, tips, and lessons learned for organizations to consider when it comes to IPv6.

What would you have done differently?

Matthew Wilder responded to this first question by explaining that “the sooner you can get more people involved and aware, the better; you’re going to need that core team.” He also identified procurement as an area that could have been improved in the deployment process at TELUS, emphasizing the importance of establishing clear parameters that acquired technologies must have IPv6 support.

What was the biggest hurdle you faced?

Ben Bittfield explained that his biggest hurdle was having it seem like he was crying wolf about IPv4 exhaustion concerns, especially when he kept having to push out those timelines due to the success of CGNAT.

Madhura Kale said that, as a product owner, her biggest hurdle is communicating to customers requesting IPv6 for something that it’s not just a matter of the network. Rather, IPv6 happens at different layers, and the applications and the software and managed services you build on top need to be IPv6-enabled.

Brent Mc Intosh identified his biggest hurdle as finding the right approach to convince executive management teams that IPv6 deployment should happen. He noted that it always came down to a financial decision, and that this is no longer a major issue as IPv6 is becoming an easier sell.

Brian Jones echoed Mahura’s response and expressed his wish that Virginia Tech’s team had gotten their service and applications deployment folks involved much earlier. While their IPv6 deployment was a great collaborative effort between the academic research side and the network team, Brian questioned, “How much can you really do over IPv6 until you get your services and applications in place?”

Matthew Wilder referred to the quote from former U.S. Secretary of Defense Donald Rumsfeld about “known knowns … known unknowns … [and] unknown unknowns,” emphasizing the need to identify those elements as quickly as possible by asking all teams involved what gaps need to be closed to make IPv6 a reality for your network and your customers.

How hard was it to make the business case for IPv6?

Ben said it was difficult initially to put a price behind the business case, but once the issue of IPv4 exhaustion made real the risk of blocking data for large amounts of subscribers, it was easy to make the argument for IPv6.

Madhura explained that this is an ongoing process, and she is still making the business case using a customer-driven approach: hearing from motivated customers, understanding what they are looking to do with IPv6, and recognizing the business impacts for them.

Brent echoed Ben’s comments about putting a price on IPv6, noting that many times he made the mistake of doing so in a way that caused the up-front cost of deployment to dissuade decision-makers. “So I started doing comparisons to running CGNAT for long computes, then it started making more sense,” he said. “While there’s a huge initial cost, in the long term it’s actually much better and it’ll cost you less. I think the approach is always to prove what it would mean to your network operating efficiently and communicating globally with everyone in the future.”

Brian shared that they had no trouble with this at Virginia Tech. Erv Blythe, Vice President for Information Technology at the time, was on board from the start, seeing the risk cost being larger and unknown versus the cost of putting a ready and willing network team to work right away.

Matthew said that what resonated with their executives was identifying projected exhaustion dates for specific product lines and getting those product managers’ attention. He also highlighted the impact of being able to determine the cost of an IP address on the transfer market to put a dollar value on action or inaction.

Did you encounter any unexpected upsides?

Ben explained that Sprint saw much improved latency and overall better performance. “It was the same number of hops; it was the same peering relationship,” he said, “But not going through that CGNAT enabled it to be so much faster and cleaner and better.”

Madhura said that, aside from scale, being able to tell a customer they no longer had to worry about the size of their virtual private cloud (VPC) was a big plus. Touching on latency as Ben brought up, she shared that AWS actually saw mixed results. They saw an improvement in some countries and a reduction in performance in others — which they suspect is due to where those different countries are at with their IPv6 adoption.

Brent shared that enterprise deployments have led to a proliferation of security-related questions. Although these create challenges, so far solutions have been found for just about all of them.

Brian focused on the unexpected public relations benefits of Virginia Tech’s early adoption of IPv6, which included a lot of positive press that was good exposure for the university.

Matthew said that being in the stage of dual stack, with IPv4 and IPv6 running in parallel, is like having multi-homing — creating redundancy that adds reliability and robustness that customers like.

What role did carrier-grade NAT (CGN or CGNAT) play, and what are your thoughts on that technology?

Ben labeled CGNAT a necessary evil, saying that it got the job done and worked well, but it was expensive, created performance issues, and wasn’t what they wanted as their target.

Madhura doesn’t have any experience with carrier-grade NAT, but she noted that customers can use private NAT on AWS and that the opinions she hears on it vary depending on people’s organizational roles. Infrastructure network administrators don’t like it because it makes their jobs harder and more expensive, but people who own applications and services don’t care as long as it works.

Brent, echoing Ben’s “necessary evil” description, made it very clear that he has plenty of experience with CGNAT, but, as a longtime IPv6 evangelist, is not a fan. “We need to move to IPv6,” he said. “That’s all I’ll say about that.”

Brian simply summarized that it is expensive, adds a lot of overhead, and makes troubleshooting harder.

Matthew shared the perspective that CGNAT is there for a reason, serving the purpose of providing an IPv4 option that doesn’t require the purchase of public IPv4 addresses.

Has it made your network more resilient?

Ben recalled that rolling out dual stack definitely increased their resiliency because, like Matthew mentioned earlier, having two networks effectively acts as multi-homing. Ben noted that this also helped win favor with executives for getting to a target state of IPv6-only.

Madhura said that, from an AWS perspective, resiliency is pretty much the same. There may be an occasional outage that’s IPv4-only or IPv6-only, but overall she sees them equally performing.

Brent hasn’t seen much difference in resilience. He added that all services on the Internet exchange points he has deployed ran dual stack and, since most of the applications you access tend to prefer IPv6 first, there’s perceived improved performance when users can get locally cached content over IPv6 with no NATs involved in the event of an outage.

Brian explained that some increased resiliency helped convince members of their service team about IPv6 — when IPv6 was working while IPv4 was down.

Matthew said it was an unexpected benefit to see the resiliency that comes from having the two address families put to use at the same time, creating the type of redundancy that everyone likes to see.

What one piece of advice would you share?

When asked what one piece of advice they would share with someone just starting their IPv6 journey or what key piece of the process they would tell them to pay attention to, panelists’ answers ranged from security and involving more people in the company to having a compelling business case, taking the free ARIN training webinar on IPv6 address planning, and building a strong team.

John Curran also asked Brent what changes are needed to make IPv6 accessible for Caribbean companies, and Brent suggested that getting their ISPs to be invested advocates is especially important. Then Brian responded to the question of what particular department or segment of the network he would suggest another college or university focus on first in their deployment; he emphasized the importance of getting dorms and students’ personal devices connected.

Questions from the Community

Questions from the floor and virtual queues prompted additional interesting answers and discussions. Panelists offered their thoughts on how they developed their implementation plans, whether or not they used slack for address allocation, and what their experience has been with DNS64/NAT64 and XSLT.

The final two questions posed to panelists were:

• What should we be building toward with IPv6 deployment: dual stack forever or IPv6-only?
• Do we need a sunset date for IPv4?

To hear the responses to those final questions and to watch the full panel for yourself, check out our ARIN 51 webcast archive or click below to play the video on YouTube. Then let us know about your own experiences, tips, tricks, and other thoughts on IPv6 deployment. Email us at blog@arin.net or find us on social media at @TeamARIN.

Recent blogs categorized under: IPv6

• The Business Case for IPv6-Only Enterprise
• 3 Strategies for Ensuring the Security of Your Digital Infrastructure
• The Business Case for IPv6: Crossing the IPv6 Chasm
• Caribbean Digital Progress by the Numbers