摘要

  • 旧版第6.5.8.2节的75%规则把单站点推向更大的nibble边界：一个站点占一个/48内全部/48的100%，字面结果是/44；但例子却从两个站点才开始给/44，因而暗示单站点得到/48。
  • 推荐草案先明确合资格组织的初始/48，再列出2–12 → /44、13–192 → /40、193–3,072 → /36和3,073–49,152 → /32。它目前仍是Recommended Draft Policy，不是已经通过或上线的政策。
  • /48不是IPv6协议强加的唯一答案。真正需要固化的是一张政策—实践一致性表和四个边界测试，使正文、例子与执行在同一版本下给出相同结果。

两个“可执行文件”

政策正文与例子通常被理解为主从关系：正文决定，例子解释。旧版第6.5.8.2节却形成了两个可以独立运行的对象。

正文的判断条件是：当站点数量超过一个前缀内可用/48数量的75%时，组织有资格进入下一个更大的nibble边界。把单站点代入最小单位，只有一个/48可计数，站点数量也是一，比例为1/1=100%。100%超过75%，所以下一边界是/44。

例子的第一行则把/44区间写成“多于1个、不多于12个站点”。一个站点不在该区间，于是留在/48。

独立邮件归档保存的2月修订直接承认这一冲突，并采取了一个结构性改法：不再说“初始分配规模”都由站点数决定，而是说“更大的初始分配规模”由站点数决定。这样，初始/48先成立，75%公式只处理多站点升级。

问题由此变得很清楚：算术没有争议，权威顺序有争议。在文字修正以前，实际操作必须替公共政策选择一个答案。

推荐草案做对了什么

6月公告在第三方邮件站点上的完整副本保存了Recommended Draft的现行文字和拟议文字。新版不再依赖读者把两段话拼起来猜测。

组织先满足初始资格条件，初始规模为/48。只有更大的规模才进入站点数阶梯：2至12个站点为/44，13至192为/40，193至3,072为/36，3,073至49,152为/32。四个边界前后相接，没有把一个站点重新交给75%公式。

修订还把assignment统一改为allocation。邮件中转载的咨询委员会评估说，这与现行注册程序一致，因为该场景不再签发assignment；评估同时称，修订与实际做法一致，不造成运行变化。

后一句应当保留为有出处的机构陈述。当前证据包没有匿名案例样本、历史规模统计或实现测试，外部读者无法独立复算“没有运行变化”。但也没有证据说明真实申请曾得到错误前缀、遭遇延误或受到不一致对待。审慎的结论不是怀疑或背书，而是要求可重复的一致性测试。

NOG Alliance政策追踪页把ARIN-2025-7列为Recommended Draft Policy，并记录5月20日的文字变化。推荐状态表示它已经前进了一步，却仍不等于董事会通过、政策手册更新或生产系统生效。本文讨论的是一项拟议修复，不是宣布新权利。

/48不是协议里的圣数

修正后的表格很整齐，容易使人误以为它来自IPv6本身。RFC 6177恰好划清了这个界线。它废止了“多数终端站点一律/48”的旧式建议，指出站点差异很大，单一默认值不够细致；IETF在这里提供架构和运行指导，具体给多少空间由运行社群决定。

RFC还提醒，不要把少数固定前缀边界硬编码成类似旧式地址分类的制度，CIDR仍适用于所有前缀位。

因此，RFC 6177既不否定ARIN为这类单站点选择/48，也不替ARIN作出选择。它证明的是：这是政策决定，不是协议定理。既然是政策决定，就需要清楚文本、适用范围、版本身份和纠错方式。

注册局可以根据公开规则判断申请属于哪个规模区间。运营者仍负责拓扑、子网设计、增长节奏和服务安排。记录一个前缀，不会自动赋予注册局设计整张网络的权限。

最小组织承担最大的解释成本

IPv4 Global对ARIN 57议程的外部分析把这项修订称为小改动，却认为它可以减少小型终端用户来回说明的成本。这是商业分析者的预期，不是修订上线后的测量结果，但成本机制成立。

注册局内部只需统一一次解释，以后可以重复执行。每个首次申请的组织却都要从外部重新发现这套解释。大型团队有政策专家和时间，小型单站点机构可能只能在提交前逐句比较。一个机构内的歧义因此被拆成许多申请人的私人成本。

真正昂贵的不是/48和/44之间四个位，而是不知道哪个公共对象具有最终效力：正文、表格、帮助页面还是工作人员的惯例。精确政策应当在私下沟通开始以前就回答这个问题。

从最小尺度看“政策镜像”

Lu Heng在《The Policy Mirror》中提出，政策手册会暴露机构如何理解自身权力。狭义注册局保护唯一性、记录准确、控制证明、安全声明和连续性；当行政惯例悄然变成对运营者更广泛选择的权威时，边界便开始移动。

ARIN-2025-7不是一个需要宏大指控的案例。恰恰因为它很小，制度问题才更容易看见：一项可以正当存在的规模判断，在公共层面有两种执行结果；例子承担了正文未能承担的规范作用，最后只能由实践定夺。

修正文字把决定重新放回可审查的政策对象。同时也应限制所需证据：注册局可以核验资格、普通站点数量和超大型站点的特殊需要，但不应因为“站点”一词而接管内部地址设计。

一张政策—实践一致性表

无需公开申请人的网络方案。每个关键版本只要保存八个公共安全字段：

字段 最小内容
文本身份 政策编号、日期、哈希和生命周期状态。
输入类别 资格、普通站点数、特殊大站点需要或纠错。
正文字面结果 不查例子时，规范句返回的前缀。
例子结果 公共表格返回的前缀。
实践结果 以测试或汇总方式公布的注册局适用类别。
差异处置 无差异、改正文、改例子、改实践或重审案例。
有界理由 单站点基线、多站点阈值或特殊需要。
复核纠错 决定者、日期、替代版本和挑战路径。

这是本文提出的审计模型，不是ARIN现有数据库结构。它要证明的是三个执行面是否一致，而不是披露商业机密。

四个测试就能抓住旧问题：1个普通站点应返回/48；2个返回/44；12个仍为/44；13个进入/40。每项结果都要绑定使用的文本哈希，并同时对正文、例子和实现运行。超大型站点另设测试，不应把特殊证据混进普通计数。

这套方法也能保护未来的“编辑性修改”。如果只是把assignment改成allocation，前后输出应完全不变；如果边界有意改变，差异会以一项公开决定出现，而不是藏在措辞里。

让修复完成，而不是把它夸大成事故

公开证据支持一个克制结论：矛盾确实存在，推荐草案给出了清楚修复；没有证据证明真实损害、错误分配或运行变化，也没有独立材料复现历史做法始终一致。

下一步应把最终文本指纹和四个边界测试带进后续程序。若政策通过，就同时公布生效版本与测试结果。这样，“没有运行变化”可以由前后相同的输出证明，而不只是一句要求信任的话。

单站点/48曾由例子代替规则守住。现在应该由规则自己承担。

来源

证据边界

已经验证：单站点的文字矛盾；推荐文本中的明确区间；咨询委员会关于实践连续性的陈述；独立追踪页的推荐状态；RFC 6177对统一/48默认的限制。

尚未证明：政策通过、上线、真实不一致案件、延误或损害、受影响申请数量、历史规模分布，以及对“没有运行变化”的独立复算。