摘要

  • 微软 Azure 虚拟网络 IPv6 文档在「限制」一节写明：不支持纯 IPv6 的虚拟机与虚拟机规模集（即一组可按需扩缩的同构虚拟机），每块网络接口必须至少包含一个 IPv4 的 IP 配置。
  • 同一份文档写明：使用公共 IPv6 地址与公共 IPv6 前缀不收费，关联资源与带宽按与 IPv4 相同的费率计费；Azure 公共 IP 地址文档另写明公共 IPv4 地址收取名义费用，公共 IPv6 地址不收费。
  • 这条约束落在网络接口这一层，而不是工作负载或订阅，所以它跟着文档路径上的每一台虚拟机和每一个规模集一起走，随接口数量增长，而不随应用究竟说多少 IPv6 增长。
  • 没有找到微软解释这条规则缘由、时间表或终点的任何声明。本文拒绝替它编造一个。

一句话决定了一切

在 Azure 虚拟网络 IPv6 概览的「限制」小节里，有一句话比整页其余内容加起来都重：「IPv6-only Virtual Machines or Virtual Machines Scale Sets aren't supported. Each NIC must include at least one IPv4 IP configuration」——纯 IPv6 的虚拟机和虚拟机规模集不受支持，每块网卡必须至少包含一个 IPv4 的 IP 配置（Azure 虚拟网络 IPv6 概览）。

整篇文章的论点就在这一行上。它不是下线通告，不是路线图延误，也不是泄漏出来的内部备忘。它是一条限制，被放在限制该放的位置，就在那页解释如何给虚拟网络添加 IPv6 的文档里。

同一页还写明：使用公共 IPv6 地址或公共 IPv6 前缀不收费，关联资源与带宽按与 IPv4 相同的费率计费。Azure 的公共 IP 地址文档把这两半又重复了一遍：公共 IPv4 地址收取名义费用，公共 IPv6 地址不收费；纯 IPv6 的虚拟机和规模集不受支持，因为每块网卡都必须在双栈配置里（也就是同时具备 IPv4 与 IPv6 两套地址的设置里）至少包含一个 IPv4 的 IP 配置（Azure 公共 IP 地址）。

把这两段并排放，高下立见。微软白送的那个地址家族，正是它不许客户单独依赖的；微软收费的那个地址家族，正是它不许客户放弃的。没有人把它藏起来。只是它被归档为一条限制，而不是一项决定。

文档究竟写了什么

范围很重要，因为这件事诚实的版本比煽情的版本窄得多。

Azure 并不拒绝 IPv6。它提供双栈虚拟网络，并把这项能力描述为让 Azure 上托管的应用程序既能到达既有的 IPv4 互联网，又能到达新的 IPv6 设备与网络——一种与 IPv4 枯竭共存的方式，而不是取代 IPv4。微软 Windows Server 关于过渡的技术指引摆出同样的姿态：IPv4 与 IPv6 之间的共存与过渡机制，而不是放弃其中任何一个（IPv6 过渡技术）。

这条禁令具体指向的是文档所述的虚拟机与虚拟机规模集路径。它不是在讲 Azure 的全部服务，也不是在讲微软的整个网络。谁把它读成「Azure 是纯 IPv4 平台」的证据，就越界了；谁把它读成「微软没有 IPv6 地址段」的证据，同样越界。

站得住脚的说法更窄，也更有用：在文档所述的算力路径里，IPv6 是作为附加项给出的，从来不是作为替代项。Azure 支持 IPv6；它不支持「只有 IPv6」。

为什么网络接口是承重的那处细节

这条规则写在网络接口这一层。不是订阅，不是工作负载，不是应用。选在哪一层落笔，决定了这条约束能伸多远。

写应用层的约束，讲的是软件会说什么话；写接口层的约束，讲的是一个部署必须用什么搭起来。每台虚拟机至少有一块网卡，于是每台虚拟机都继承这条要求，无论上面跑的是什么软件栈。一个开通一百块接口的部署，就把这条要求背上了一百遍，而应用代码一行都没改。

接口又恰好是客户向平台要地址的那一层。在这个位置上，地址家族不再是偏好问题，而变成平台到底会分配什么的问题。把要求放在这里，它就会陪着这个部署一路走下去：扩容时在，重新部署时还在，下一次重新部署时依然在。

有一个二阶效应值得说准，因为含糊的版本流传得太广。文档并没有说明被要求的那个 IPv4 配置必须是公网、私网、共享还是经过转换的，本文也不去断言。所以这条规则并没有说明某个工作负载会消耗多少个稀缺的公网 IPv4 地址。它说的是：这个部署不能被诚实地描述成「纯 IPv6」；而 Azure 自己的开通路径，本来也不会让运维者真的建出一个来。

这是一种以数据结构细节形式表达出来的权力关系，比一页价格表沉重得多。

免费的 IPv6、收费的 IPv4，以及一条走不到任何地方的价签

Azure 把两个地址家族的定价推向相反方向。公共 IPv6 地址与前缀：不收费。公共 IPv4 地址：收取名义费用（Azure 公共 IP 地址）。

单看这一句，它是指向 IPv6 的价格信号。价格信号本该改变行为，整套理论就建立在这上面。可它撞上了一条把另一个家族变成强制的配置规则，撞出来的东西比「矛盾」更奇怪：商业信号和技术要求在互相抵消吗？没有。在互相加强吗？也没有。它们各走一条平行线，永不相交。

想省成本的客户会被告知——而且说得没错——IPv6 免费。真去照做的客户会发现，免费的那个家族不能是接口上唯一存在的那个。节省是真实的，但被框住了：它作用在配置的 IPv6 一侧，IPv4 那一侧原地不动。

这不是虚伪，也不是什么隐藏议程的证据。这是一种排序。价格信号是商业偏好，接口规则是开通时强制执行的技术要求。两者冲突时，赢的是要求，因为闸门检查的就是要求。一个免费的家族挨着一个强制的家族，在微软的账上并不构成自相矛盾；它描述的是平台实际执行了哪一个决定。

公布出来的记录不等于网络本身

微软发布一份可下载的 Azure IP 地址段与服务标签文件，供那些需要机器可读数据的客户了解 Azure 服务所使用的地址空间（Azure IP 地址段与服务标签）。

这份文件的存在与它声明的用途是既成事实。它当前的 schema 版本（即文件的结构定义版本）、对前缀家族的覆盖范围以及发布频率，本次研究并未以文本形式读取，因此本文不主张它遗漏了 IPv6 前缀，也不主张它以多快的速度更新。

这份谨慎本身就是论点，不是回避。那种诱人的做法——在关于云网络的评论里到处都是——是把一份机器可读的地址段文件当成举到网络面前的镜子。它不是镜子。它是一份发布物，范围是有人选定的，节奏是有人维持的。服务标签同理：那是覆盖在地址集合之上的一层命名，而不是一张实时的路由表。

由此可以得出一条支配整件事的通则。注册管理机构的记录、对外发布的地址段文件、以及平台强制执行的配置要求，是三份不同的产物，出自三个不同的流程，走在三个不同的时钟上。当它们不一致时，第一个该问的问题不是谁在撒谎，而是各自覆盖什么、最后一次写入是什么时候。

注册记录能说什么、不能说什么

ARIN 在 MSFT 句柄下的 RDAP 组织记录（RDAP 是注册管理机构提供的机器可读查询协议），是微软公司机构登记及其关联互联网号码资源的注册管理机构入口（ARIN RDAP 实体 MSFT）。

这确立的是身份，不是一个总数。这份记录的正文以及它完整的关联资源集合，本次研究并未以文本形式读取，因此这里不推导任何持有量数字、前缀清单或资产台账——读者也应当把任何戏剧性的「微软持有多少 IPv4」数字，在没有对应底层记录的情况下，当作一个待证的主张，而不是到手的事实。

注册记录清楚确立的，是那套机制。ARIN 维护着公开的 IPv4 转移框架与注册轨迹，注册过的地址空间在其中从一个机构转到另一个机构，包括在中心 IPv4 池枯竭之后记录的转移（ARIN IPv4 转移政策）。地址空间可转移、可登记、可追溯。这是市场的结构。某一家公司在这套结构内部持有什么，是另一个问题，需要另一次阅读。

2011 年的北电交易，以及为什么它不是解释

2011 年 4 月，BBC News 与 Ars Technica 的报道称，微软以北电破产相关资产处置的一部分，收购了北电的 666,624 个 IPv4 地址，交易估值约 750 万美元（BBC News；Ars Technica）。

由此得出的算术——每个地址约 11.25 美元——是在被报道的数字上做的算术。它不是 ARIN 设定的价格，也绝不该被当成价格引用。这些报道本身也只是报道：本次研究没有以文本形式读取任何一篇文章的正文，地址数量与价格都来自被报道的叙述与 Ars Technica 的标题，而不是来自注册记录或法院文书。

这笔交易就该待在这里：作为 2011 年地址空间市场价值的历史背景——那时一家为云增长做准备的公司愿意为一个地址大块付钱。它不是关于 Azure 现行网卡规则的证据，更绝不是动机。把一笔 2011 年的收购端出来当作 2020 年代一条配置要求的理由，是一个形状很讨喜、里面却空无一物的故事。那笔采购解释的是地址空间当时值多少钱，并不解释 Azure 今天的开通闸门在执行什么。

迁移到底走到哪一步

用文档允许的最直白说法：Azure 支持 IPv6，支持双栈，不支持纯 IPv6 的虚拟机与规模集，并要求该路径上每块网卡至少有一个 IPv4 配置。公共 IPv6 地址与前缀免费，公共 IPv4 地址收费。微软的过渡指引描述的是共存，不是取代。

这份清单最有用的一点，是它并不完整，而微软把这种不完整公布了出来。「限制」一节正是平台安放自己还做不到之事的地方；这一条能写得这么干脆，说明这家工程组织清楚自己的边界在哪，也没兴趣给它上妆。

不完整不等于暂时，这个区别对做五年规划的人很要紧。没有找到任何日期、里程碑或终点状态，能让一个理性的人说出「每块网卡必须留 IPv4」这条要求何时可能解除。把它称作过渡性的，那是编造，而且对据此去设计网络容量的人来说是昂贵的编造。

这份材料里同样没有的，是一个理由。本次研究没有找到微软解释这条规则缘由、时间表或预期终点的任何声明。动机未知。这条规则对一家持有大量 IPv4 的公司当然方便，而「方便」并不能证明「方便」就是它存在的原因。为了给仍然假定 IPv4 的服务提供兼容性保证、一项尚未退役的支持成本、一个关于迁移该如何排序的刻意选择——这些都同样契合那句已经公开的话，而没有一个能从中得到确认。

如果有人想要的是微软网络资源处境的底层背景，而不是围绕它的争论，可以从 BTW 名录中的微软公司条目 开始。

什么会改变这一解读

三件事。

一是微软就缘由作出说明。如果这条接口要求是为了给仍然假定 IPv4 的服务提供兼容性保证，那是另一篇文章，而且是一篇更宽容的文章。如果它反映的是关于地址空间价值的商业判断，那同样也是另一篇文章。无论哪一种，一旦存在就值得写。

二是一份带日期的计划。如果纯 IPv6 的虚拟机与规模集出现在一份带里程碑的公开路线上，这条约束就不再是边界，而变成了一张时刻表。现有文档里没有任何东西提供这个。

三是一次测量。如果有人证明 Azure 公布的地址段数据与观测到的网络状态之间的偏差，超过了公布的发布窗口所能解释的范围，那就是一个有测试答案的测试问题。本文没有做任何 BGP（互联网自治系统之间交换路由的协议）、端点或客户侧测量，因此这里也不主张任何这类发现。

在这三者出现之前，诚实的读法就是文档本身支持的那个读法。层级是公开的：IPv6 免费，IPv4 收费，文档所述的算力路径上每块接口都必须有一个强制性的 IPv4 配置。支撑它的理由并不公开，而整个行业的 IPv6 迁移如今就活在这道缝里——在页面顶端被宣告，在脚注里被约束，又在完全另一页上被定价。