There’s an interesting post on the RIPE Labs discussing how Microsoft is moving to IPv6 only on its internal network. Marcus Keane presented their experiences during RIPE 73, and we also gave that some coverage on Deploy360, but this expands a bit more on their motivations for doing so.
The primary reason is of course the exhaustion of public IPv4 space, but with a large corporate network spread over more than 100 countries, they’re also running out of private IPv4 address space. Whilst operating multiple NATs might temporarily relieve the situation, this is becoming more difficult to manage and the problem has been exacerbated by the acquisition of other companies with their own NATs, plus the expansion of the Azure cloud computing service.
Dual-stack also only partially addresses the problem as not only are IPv4 addresses still required, but this doubles the complexity of designing their network and dealing with issues when they arise. As a result, Microsoft have been experimenting with IPv6-only networks for the past couple of years, and have now started to deploy this on their production networks.
By focusing initially on the guest network, this minimises the risk to existing and possibly more critical systems, and provides more flexibility for changing things if necessary. It’s interesting that some of the deployment issues encountered were due to DHCPv6 bug in Windows 10, plus the need to support Android devices which doesn’t support DHCPv6. Another interesting issue is that whilst Azure Active Directory can be used to authenticate users, the ACLs on the wireless controllers do not currently support IPv6, although this is in the process of being added.
Nevertheless, the article provides an interesting case study on how a large enterprise clearly understands the necessity of deploying IPv6, and is actively taking steps to implement IPv6 in a production environment.
Deploy360 also aims to help this process, so please take a look at our Start Here page to understand how you can get started with IPv6.