微软在企业网络中逐步从双栈转向 IPv6-only，旨在缓解私有 IPv4 地址枯竭，但遭遇 VPN 兼容性与厂商支持不足等阻碍。目前正在通过试点网络识别阻塞点，并等待负载均衡平台提供 IPv6 健康检查以及 VPN 网关新版本发布。
VPN 在 IPv6-only 环境下的故障与对策：
一次会议提供的 IPv6-only 网络导致 99% 参会者无法连接 VPN，问题在 RFC 7269 中有详细记录。微软 VPN 隧道内仍为双栈，正等待流量负载均衡平台实现 IPv6 健康检查；客户端曾自动创建 IPv4 套接字导致失败，已修复。为回收 IPv4 并避免与外包合作伙伴的 10./8 地址冲突，需部署 IPv6-only 客户端地址池，但 VPN 厂商暂不支持该配置，预计六个月内发布新网关代码。同时，内部仍有 IPv4-only 应用，需配合 NAT64/DNS64 实现互通。
客户端地址池与 NAT64/DNS64 的部署依赖：
IPv6-only 客户端池是回收 IPv4 资源的关键，也能消除与合作伙伴共用 10./8 空间的地址重叠。厂商尚未提供 IPv6-only 配置文件，微软只能等待新版本网关。内部应用逐步启用 IPv6，过程中必须维持 NAT64/DNS64 服务，以保证现有 IPv4-only 服务不中断。
试点网络用于识别阻塞点：
为满足 Apple App Store 等外部要求，微软部署了仅提供 IPv6 Internet 访问的试点网络，供产品组验证应用在纯 IPv6 环境下的行为。该环境帮助团队提前发现协议栈、DNS 解析及中间件的不兼容问题，为后续大规模推广提供实测依据。
对运维与网络工程师而言，微软的经验表明：推进 IPv6-only 必须同步解决 VPN 终端、负载均衡健康检查、厂商功能缺口以及 NAT64/DNS64 部署；通过小范围试点暴露隐性故障，再按模块逐步闭环，才能在不中断业务的前提下完成地址资源的彻底转型。
原文: APNIC Blog（2018-09-17）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog