As a colleague of mine published in a post here on the APNIC Blog in January 2017, Microsoft has been running IPv6 in a form of dual stack in our network environment for some years. Due to the fact that it does not help us with private IPv4-address depletion, we have progressed from discussing IPv6-only and are now experimenting with it for real deployment.
At the time of the previous blog post, our team worked on moving our wireless Guest network to IPv6-only. The deployment was pending some IPv6 features from vendors.
Unfortunately, we had to stop this work because we came across something that the previous internal testing had not uncovered — a team member attended a conference where Internet access was provided as IPv6-only and 99% of attendees could not get their VPN clients to connect on this network.
VPN failing on IPv6-only networks (through NAT64) is, as we then found out, well documented in RFC 7269. This finding made it clear that visitors to Microsoft offices who rely on the Guest network would be heavily impacted unless their VPN gateways were IPv6-enabled.
Deployment of IPv6 by other companies is out of our control and therefore this network is currently undergoing a less radical makeover to dual stack. IPv6-only is on-hold for production even though we intend to pilot it to assess the real impact on Microsoft visitors.
Getting VPN ready for IPv6-only
Our VPN is currently dual stacked inside the tunnel and we are working on enabling the VPN termination with IPv6. Here we are waiting for our traffic load-balancing platform to provide us with IPv6-based health-checking of VPN gateways.
We used to have another unexpected blocker with IPv6 termination where our VPN client would automatically create a v4 socket which caused it to fail on IPv6-only networks, but that has been fixed.
We also tried to test IPv6-only Client pool, which means no IPv4 inside the VPN tunnel. We need this function in order to reclaim IPv4 as well as to avoid clashes of IPv4 space with our outsourcing partners who need to use our VPN solution to provide services to Microsoft organizations and internally also use 10./8 space. We found out that the VPN vendor did not support IPv6-only client profile at the time and we are waiting for a new VPN gateway code version to be released in the next six months.
IPv6-only inside the VPN tunnel will have to be deployed alongside with NAT64/DNS64 as some of our internal applications are still IPv4-only. Their enablement with IPv6 is also a work in progress.
Pilot IPv6-only networks allow us to identify blockers
In order to facilitate our product groups meeting the IPv6 demands imposed on them by the industry, like the ones of Apple App Store, we deployed a network which gives them IPv6-only access to the Internet and thus simulates consumer home environment. The network helps them test their apps to meet the requirements.
This network, currently available in 12 locations, leverages NAT64/DNS64 deployed at our Internet edges in North America and Europe. The address assignment used on this network is SLAAC with stateless DHCPv6 and RDNSS for Android clients since we have had the RDNSS functionality available in our building routers’ code for the last 10 months. It seems to work rather well, and it helped the product groups to root out some usage of old APIs that caused app failures on IPv6-only.
In spring 2018, we started a pilot deployment of our corporate wireless network as IPv6-only with NAT64/DSN64. It is deployed as an opt-in separate SSID, alongside with our dual-stack wireless network, which allows users to fall back on dual stack when they come across non-working applications on IPv6-only.
The aim of this pilot, which is currently running in eight locations in North America and Europe, is to identify applications that fail on IPv6-only; we can then work with the application owners to resolve this.
We have also come across IPv6 software bugs in the code of our wireless vendors which were masked in dual stack because of IPv4 and therefore not user impacting. We have since deployed new code versions with the appropriate fixes (8.5 MR3 for Cisco and 6.5.4.8 for Aruba).
Network part is easy, applications are the big unknown
IPv6 and IPv6-only are becoming easier from the network deployment perspective, and so far, our experience has confirmed what many suspected.
While the network part is easy, barring software bugs, applications are the big unknown. Not just our own but the third-party applications that often claim ‘IPv6 compatible’ however when it comes to a real deployment, the experience is quite different.
This post attempts to share only a few activities out of many that our organization is undertaking on its journey to IPv6; a journey that will still take many years to achieve. That said the end goal still remains: IPv6 enabled everywhere and IPv6-only everywhere we can. We are certainly making a good progress in achieving our goal.
Veronika McKillop is a Network Architect at Microsoft.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
You’re right – it’s the applications that are the known unknown.
From the structure of most enterprise IT, the network, infrastructure (h/w and s/w) and applications groups will be separate and fight over the causes and budgets for any move to native IPv6.
So you’d need to escalate the budget issue within an enterprise to get any ownership. Then you’d have to overcome the challenge that few of those responsible for the s/w will have suitable tests and may be missing the relevant source code/not know where the oldest binaries are deployed/what they support. And they will not want to ‘fess up to that situation (remember y2k?).
Pushing the change through will require significant political capital and some sort of strategic need (eg at MS the impact of trying to merge overlapping rfc 1918 address spaces when the business strategy calls for it.)