TR19: Microsoft IT (secure) journey to IPv6-only

## Overview This talk documents Microsoft IT's multi-year journey toward IPv6-only networking infrastructure. The speaker, a network architect at Microsoft Core Services Engineering Operations, has been leading this initiative for over two years. Microsoft operates one of the world's largest enterprise networks, serving approximately 220,000–230,000 end-users across ~1.2 million daily device connections with ~80,000 DNS queries per second globally across four major regional campuses plus data centers and Azure cloud services.

## Historical Context and Current State Microsoft's IPv6 work began in 2001 with Microsoft Research exploring the protocol. In 2006, the organization created its first IPv6 addressing architecture document, which has required only minor updates despite protocol evolution. Dual-stack deployment began in 2011 on the backbone network and rolled out to user segments in 2016. Today, approximately 34% of internal traffic runs on IPv6, with the remainder on dual-stack. Microsoft holds three IPv6 prefixes from different Regional Internet Registries (ARIN, RIPE, APNIC), providing operational clarity based on geographic origin.

## Drivers for IPv6-Only Transition Multiple factors compel migration: (1) IPv4 address exhaustion and escalating costs ($7 per address in 2015 → $19+ by March 2019, with continued growth of $3.50–$4.50 annually); (2) Industry mandates including Apple's 2015 iOS requirement that all applications work on IPv6-only networks, US federal government directives, and Washington State's announcement to retire IPv4 from all services by end of 2024–2025; (3) Operational complexity of maintaining dual-stack, with estimated 2–3 year full transition timeline due to address reclamation and application dependencies.

## Major Technical Initiatives **Wireless Guest Network v6-Only Pilot**: An early pilot failed approximately three months into deployment when discovery at an industry conference revealed VPN clients (Cisco Anyconnect, Juniper Pulse) cannot traverse NAT64, affecting ~98 attendees. This led to 15+ months of testing before cancellation, teaching the critical lesson that not all IPSec-based VPNs function through NAT64 translation. The network remains dual-stack pending VPN concentrator IPv6 enablement.

**Product Group Testing Environment**: Microsoft provides isolated dual-stack networks with NAT64/DNS64 to internal product groups (specifically Skype and Minecraft) for testing applications in IPv6-only conditions, approximating real-world IPv6-only home broadband scenarios while maintaining corporate network isolation.

**Remote Access VPN**: Deployed in early 2018 supporting over 200,000 users. Transport layer is currently dual-stack with IPv4-only concentrator responses pending load balancer health check enhancements. A late 2017 proof-of-concept targets IPv6-only addressing inside tunnels; vendor (identified as a major provider) delivered production code for v6-only client pool assignment as of October 2018 after collaborative beta testing.

**IPv6-Only Corporate Network Pilot**: Started April 2018 with 12 locations, targeting ~20 by summer 2019. Deployed as parallel wireless networks alongside dual-stack to enable fallback. Uses NAT64/DNS64 infrastructure currently in US and AMEA regions with Asia-Pacific buildout planned this fiscal year. Desktop/laptop connectivity testing revealed issues invisible in mobile-only testing: both Arista and Cisco controllers dropped router advertisement messages carrying DNS information, and re-authentication dropped IPv6 connectivity—bugs masked by dual-stack fallback but critical for v6-only operation.

## Security Considerations IPv6 security spans multiple layers: firewall access lists (avoiding ICMP v6 blocking), infrastructure access control, Router Advertisement Guard, data center firewall inspection for IPv6 traffic, port security, device personal firewalls, and threat protection. Critical gaps include: monitoring and forensic capabilities in v6-only environments, correlation of IPv6-only security events, device firewall update delivery over v6-only networks, ATP across both protocols, personal device privacy and address rotation tracking, and cascading dependencies across cloud services. Microsoft uses stateless DHCPv6 with DNS options rather than stateful DHCPv6 to accommodate diverse unknown devices. Cloud security providers initially lacked IPv6 support; Cisco Umbrella recently added DNS64 record inspection.

## Lessons Learned **Vendor Engagement**: Feature requests require financial backing; vendors prioritize only when customers are significant. Testing revealed both wireless vendors had similar IPv6-related bugs invisible in dual-stack. Sustained engagement with Fortinet successfully produced beta and production code.

**Testing Methodology**: Dual-stack is insufficient for discovering real IPv6 issues; v6-only testing is mandatory.

**Applications**: The largest blocker. Microsoft must audit ~40,000 third-party applications plus internal development for IPv6 dependencies.

**Infrastructure Management**: Wireless controller discovery gaps, RADIUS authentication over IPv6 limitations, and monitoring tool deficiencies required rework.

**Adoption Strategy**: Communication represents ~75% of the work. Planned screening tests will temporarily disable IPv4 on selected networks. Bug bounty and sweepstakes incentivize participation.

## Next Steps Timeline targets end-of-year for expanded pilots, with full production rollout pending broad organizational agreement and elimination of user experience impacts.