Microsoft has been running IPv6 in some fashion on its corporate network for many years now.
We have a substantial IPv6 footprint across more than 100 countries, but as you have probably surmised from the title of the post, dual-stack doesn’t meet our needs.
What is driving this push to IPv6-only?
The first – and most obvious – reason is exhaustion of IPv4 address space. The depletion of public IPv4 space is well-known, but Microsoft IT has exhausted almost all RFC1918 space. There are small discontiguous pockets remaining, but not enough for our current and future needs.
This situation has been exacerbated by two main factors: integration of corporate acquisitions (for example, Nokia) and Azure expansion. Even worse, these last factors have resulted in an overlap of RFC1918 space.
As interconnectivity is required between the corporate network and both Azure and the acquired company’s network, this has necessitated sub-optimal NAT solutions. These, of course, are potentially fragile – and certainly operationally challenging.
The second reason to consider a move to IPv6-only is the complexity of dual-stack. For helpdesk as well as network (and systems) operations staff, dual-stack more than doubles the complexity of dealing with issues. Equally, having to consider both IPv4 and IPv6 in the network engineering and design process, makes life more complicated than it needs to be.
With this in mind, during the last couple of years, we have been experimenting with IPv6-only.
How we have been experimenting with IPv6-only
We started out with a couple of test networks in Redmond, USA: one on the wireless guest network in one building, and a segment on the wired corporate network. This latter network was an opt-in. We configured these two networks with various address acquisition schemes (SLAAC, DHCP stateful and stateless) to get a picture of what worked and what did not.
Surprisingly, most scenarios worked. It was also interesting to gain experience with various NAT64/DNS64 platforms, which served as input into our shortlist for platform selection.
Following this initial pilot, we decided we needed to move aggressively to widen the deployment to more production networks. We elected to concentrate on the guest network as this gave us the most flexibility with the minimum of risk. We soon encountered a problem, however.
Testing has its challenges
The routers in buildings where we wanted to deploy did not support RDNSS in our current code. You’ll be aware RDNSS (RFC6106) is a facility to provide DNS resolver information in RAs. As we needed to support Android devices on our guest network, and Android doesn’t support DHCPv6, not having this feature was a problem.
Our temporary solution was to move the default gateway function to a centralized pair of routers that supported RDNSS. These routers are reached using a L2VPN overlay.
This isn’t ideal (operationally), so we are currently testing new code from the router vendor which supports RDNSS. This will allow us to move the default gateway back to the building. This highlights the fact that some IPv6 features are not consistent among platforms.
This change enabled IPv6-only on the guest network, but we have encountered two issues that have slowed us down. One vendor-based, and the other more home-grown.
The first is that our new wireless design allows employees to authenticate for network access using Azure AD. This, in turn, requires reauthorization ACLs on the wireless controller. These ACLs are dynamic (name-based) and are not supported with IPv6 by one of our vendors, and only by the second vendor in code, which we have not finished testing. Clearly, feature parity between IPv4 and IPv6 in vendors’ equipment can be difficult to achieve.
We expect to complete testing of both the wireless controller code and the router code supporting RDNSS in the next month or so, meaning we should be able to roll out IPv6-only to the guest network in our Redmond campus (100+ buildings) in the next six months.
The second issue slowing us down was a DHCPv6 bug in Windows 10. This affected both stateful and stateless schemes. Needless to say, IPv6-only expansion was impossible until we resolved this issue. We have reported it to the product group, and they are duly working on a fix.
The final bit of the puzzle is IPv6-only on the corporate network. This is complicated by the disparate requirements, which are different between regions, and even between buildings in the same city.
Specifically, this is about types of users – such as developers – having vastly different requirements to corporate functions such as HR or Finance. Technically, this means assessing whether NAT64 will break applications in use.
There’s also the question of NAT64 and DNS64 placement. This is complicated when we assess ideas such as SD-WAN (meaning no more than sites having local instead of centralized Internet egress).
In an environment such as this, centralizing functions such as DNS64 is easier to manage but less flexible. However, distributing the function allows more flexibility, but is more to manage. Issues such as these are what we will have to grapple with as we plan our move to IPv6-only in the corporate network.
So, is all this trouble worth it?
Hopefully, migrating to IPv6 (dual-stack) is uncontroversial at this stage. But for us, moving to IPv6-only as soon as possible solves our problems with IPv4 depletion and address oversubscription. But it also moves us to a simpler world of network operations where we can concentrate on innovation and providing network services, instead of wasting energy battling with such a fundamental resource as addressing. It will be an interesting journey to get there!
Marcus Keane is Principal Network Engineer at Microsoft Corporation.
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.
Excellent article, I’m actually curious why the use of private up ranges were not limited greatly to end user machines only, moving almost all server systems to v6 only first, as well as leveraging shared address space (100.64.0.0/10) for overflow areas.
Very excited to see this improve v6 support in Windows client and server systems! thanks!
It’s quite funny that you are lamenting about lack of rdnss support on your vendor’s platform when rdnss is not supported on windows as well 🙂 However, I would rather see dhcpv6 support in android than rdnss in windows.
Hi,
Thanks for the comment. The issue with no RDNSS on the routers was that we couldn’t support Android at all. This is boviously a non-starter for a production guest service.
Regarding RDNSS on Windows, there are plans to implement it in Windows 10, but I can’t give any release dates. Hope this helps.
Marcus
Hi,
Thanks for the comment. The issue with no RDNSS on the routers was that we couldn’t support Android at all. This is obviously a non-starter for a production guest service.
Regarding RDNSS on Windows, there are plans to implement it in Windows 10, but I can’t give any release dates. Hope this helps.
Marcus
I would like to know if you find issues with skype, we try a IPv6-only network but the main issue was applications not supporting IPv6, skype between others. What do you plan to do with apps not working even with NAT64/DNS64?
Hello,
Which DNS64 implementation did you use?
Bye
Rainer Tammer
I’ve had the same experience. The two main applications not working with v6-only and DNS64/NAT64 are Skype and Steam. Steam is not really a concern in business networks but Skype clearly is. Steam however is a big problem for service provider deployement. For the details about skype, it down not work with the desktop versions (mac/win7). However the iOS version works. I don’t know about android.
I used tayga for nat64 and PowerDNS for dns64
Very interesting read.
I was using an IPv6-only network and all was well with Linux, FreeBSD and Windows XP.
I had to revert back to dual stack since Vista, 7 and 8 lack a correct IPv6 support. I didn’t try Windows 10, but since it’s based on the same TCP stack of the 3 previous version, I don’t expect much. And you said it in your article : there are IPv6 related bugs in Windows 10.
You really should throw away all the code you added in Windows since Vista and start back from the source code of XP.
I hope that this won’t mean poor dual stack support in Windows. While I’d love to go pure IPv6 with NAT64/DNS64 at egress points, I think we all know this is 10 or more years away.
Hi Daniel,
Not at all; we will continue to fully support dual-stack. I think IPv6-only with NAT64/DNS64 at the edge is closer than you might imagine. In fact, this is exactly what we are trying to do. I agree that we’ll have IPv4 around for at least 10 years.
Marcus
Moving to IPv6-only in the corporate network we need Windows ADS servers and DCs to learn NAT64/DNS64 addresses. A server needs to know how to publish his NAT64 address to the DNS/DCs and get it replicated through ADS. Dear Marcus Keane, when can we expect that?
Hi Christian,
I’m not sure I understand. The whole point of DNS64 is that the IPv4 host doesn’t know of the existence of the DNS64. If the server publishes its A record in DNS, and the client talks to the DNS64, then it will receive a synthesised address.
Or did I misunderstand the question?
Marcus
Thanks for knowledge sharing.
But it’s WOW, never known before that Android DO NOT support DHCPv6.
This is a deliberate design decision by Google: “Implementing stateful DHCPv6 would break planned use cases such as IPv6 tethering (which would require implementing IPv6 NAT in order to work with DHCPv6) and 464xlat on wifi (which requires that the device be able to use more than one IPv6 address). It also has greater privacy implications than stateless autoconfiguration and DHCPv4. Stateful DHCPv6 will provide the ability to connect to IPv6-only networks that don’t use RDNSS, but because stateful DHCPv6 will in general not provide the two IPv6 addresses that are required to run native and 464xlat, such a network will not support IPv4-only applications; this will impact users, because they won’t be able to use applications such as Skype, Hangouts, and many others. ”
https://issuetracker.google.com/issues/36949085
I am disappointed ! Bugs in IPV6 stack in windows are clearly discouraging. I do Dual stack , ipv4 only ,cgnat testing and development and when it doesnt work on a windows like a windows based pc unable to attach on wireless ipv6 networks due to bugs or implementation specific behaviour rather than rfc specific , it doesnt help.
Interestingly Skype, the single application that prevents massive rollout of IPv6-only, is by… Microsoft.
I know because I’ve been running an IPv6-only network for ages.
Can Skype be updated to support IPv6-only networks – please?
Let’s hope that NAT64 dies. There is no reason to have NAT in a 2^128 bit address space world.
Where’s the +1 button, please let NAT die a horrid death
Good idea, but first we need to migrate to IPv6. Still waiting for big vendors like Microsoft to support IPv6 only and NAT64 migration possibilities in Microsoft Active Directory systems. ( How to update DNS with IPv4 addresses when server have just IP6 addresess).
Hi Tones,
Yes, the need for NAT64 is unfortunate, but it will be a requirement until every resource on the internet has deployed IPv6. If not every resource, then at least the resources you care about on your network.
Marcus
NAT64 will die away naturally as IPv6 adoption grows.
A worse threat is NAT66 used by a router to provide IPv6 connectivity to downstream devices because the router can’t request a prefix shorter than /64 from its upstream. e.g. An ISP home router that doesn’t act as a DHCPv6-PD server on its LAN side. So connected devices than want to further tether are tempted into using NAT66.
Any update on a fix for the IPv6 DHCP bug in Windows 10, 1607? I’m in the middle of an IPv6 migration and this is a real issue. The older Windows 10 clients work but the ones with 1607 “Anniversary Edition” don’t. I have a crude workaround, using a scheduled task on startup that runs “ipconfig /renew6”; however, it’s a really hacky way of fixing an issue that shouldn’t exist.
MS have recently fixed that bug and the Windows Creators Update also now uses RDNSS.
Windows 10 doesn’t run on IPv6-only networks! I tried so, but it cannot contact the update servers from Microsoft. Windows 7 had no problem at this, but Windows 10 does.
Any news on fixing the IP V6 Bug in windows 10 ??
What could also help with the adoption is to have the CLAT feature from WWAN(Windows Mobile) also work on Wired/Wireless adapters that are connected to an IPv6 single-stack network.
Besides Skype, Discord voice/video calls don’t work as they use IP literals when connected to an IPv6-Only network and possibly with other types of voice/video messenger apps out there.