微软在过去的多年里一直在其企业网络中以某种形式运行IPv6。我们在全球100多个国家拥有庞大的IPv6足迹，但正如文章标题所暗示的，双栈并不满足我们的需求。推动向IPv6-only迁移的第一个，也是最明显的原因是IPv4地址空间的耗尽。众所周知，公共IPv4空间已经枯竭，但微软IT几乎耗尽了所有RFC1918空间。尽管还有一些零散的小块空间，但不足以满足我们当前和未来的需求。这种情况因两个主要因素而加剧：企业收购的整合（例如，诺基亚）和Azure的扩展。更糟糕的是，这些最后因素导致了RFC1918空间的重叠。由于企业网络与Azure和收购的公司网络之间需要互连，这迫使我们必须采用次优的NAT解决方案。当然，这些解决方案可能是不稳定的——并且在操作上具有挑战性。考虑迁移到IPv6-only的第二个原因是双栈的复杂性。对于帮助台以及网络（和系统）操作人员来说，双栈将处理问题的复杂性翻倍。同样，在网络工程和设计过程中必须同时考虑IPv4和IPv6，使得生活比必要的更复杂。因此，在过去的几年里，我们一直在尝试IPv6-only。我们如何进行IPv6-only的实验
实验网络与地址获取方案
我们最初在美国雷德蒙德建立了一些测试网络：一个在建筑物的无线访客网络上，另一个在有线企业网络的一个部分。后者是一个可选的网络。我们为这两个网络配置了各种地址获取方案（SLAAC、有状态和无状态DHCP）以了解哪些方案可行，哪些不可行。令人惊讶的是，大多数场景都成功了。同时，我们还积累了使用各种NAT64/DNS64平台的经验，这些经验为我们平台选择短名单提供了输入。在这次初步试点之后，我们决定需要积极地将部署扩展到更多的生产网络。我们选择专注于访客网络，因为这为我们提供了最大的灵活性，同时风险最小。然而，我们很快遇到了一个问题。测试有其挑战性
测试中的问题与解决方案
我们希望在建筑中部署的交换机不支持我们在当前代码中的RDNSS。您可能知道RDNSS（RFC6106）是一种在RA中提供DNS解析器信息的功能。由于我们需要在访客网络上支持Android设备，而Android不支持DHCPv6，因此没有这个功能是一个问题。我们的临时解决方案是将默认网关功能移至一个集中的路由器对，以解决这个问题。
IPv6-only部署的下一步
通过这些实验，微软积累了宝贵的经验，并决定将IPv6-only的部署扩展到更多的生产网络。这一决策不仅解决了IPv4地址空间的限制问题，还简化了网络操作，减少了双栈带来的复杂性。对于运维和网络工程师来说，了解微软的IPv6-only部署实践具有重要的实际意义，它为他们在面对类似挑战时提供了参考和借鉴。
结尾：微软的IPv6-only部署实践为网络工程师提供了宝贵的经验和启示。通过解决IPv4地址空间的限制和简化网络操作，这一实践有助于提高网络效率和稳定性，为未来的网络发展奠定了基础。
原文: APNIC Blog（2017-01-19）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog