You are here: Home > Publications > RIPE Labs > Mirjam Kühne > IPv6-only at Microsoft
Content by this author

IPv6-only at Microsoft

Mirjam Kühne — 24 Jan 2017
Please read this guest post by Marcus Keane from Microsoft in which he describes why the organisation is moving to IPv6-only and away from dual-stack.

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 guessed 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. This article was first published on the APNIC Blog.

5 Comments

Jeff Loughridge says:
05 Feb, 2017 08:15 PM
Marcus,

Thanks for sharing. I was surprised that you didn't point out that Windows is missing RDNSS support (without a 3rd party add-on). Has Microsoft's position changed on RDNSS?
Marcus Keane says:
09 Feb, 2017 03:24 PM
Hi Jeff,
I thought that was implicit with needing RDNSS only for Android(i.e. the others would use DHCPv6). :-)
But you're right, my wording could have been better, and been more explicit about the requirements.
Regarding RFC6106 support in Windows, we(Microsoft IT) have asked the PG for the feature, but I'm unable at this stage to say whether they will or will not implement it.
Regards,
Marcus
Mark Svancarek (MSFT) says:
15 Feb, 2017 09:45 PM
RFC6106 is being added to Windows 10. We will be announcing a release date soon.
Rich Burma says:
17 Feb, 2017 01:15 PM
Thanks for this article. Very useful. Our enterprise is also exploring IPv6 only (LAN/WAN) for our branch sites and this article helps us push it forward (get management buy-in/funding).

Could you please clarify how SD-WAN adoption impacts v6-only LAN/WAN? After all, NAT64 isn't needed on all the sites, as v4 traffic keeps on declining and we need to pool public v4 prefixes for better sharing anyway.
Marcus Keane says:
18 Feb, 2017 04:57 PM
Hi Rich,
I'm glad the article was helpful for you.
You ask a good question about SD-WAN. Most of our tail-site connectivity is through carrier-provided L3VPNs with centralised internet egress. Having local egress makes this interesting. If we assume about 50% of our internet traffic is IPv6(which is what we see internally), then maintaining a centralised NAT64 reduces the potential benefits of SD-WAN. You bring up a good point about public v4 ranges. Decentralising the NAT64 only makes sense if we can get internet service(and addresses) from a single carrier(assuming they could give us small components out of an aggregate).
To be honest, we haven't worked this out fully. But it's an interesting problem. :-)
Marcus
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.