摘要

  • AFRINIC在2018年的实施经验报告中记录了一个具体矛盾：一名匿名终端用户想为第二座冗余数据中心取得额外的IPv4 /24，但现有资源合计利用率不足90%，所以申请不合格。
  • 正处于Last Call的AFPUB-2026-IPv4-002-DRAFT02拟允许AFRINIC针对现有资源无法实际满足的关键技术用途豁免90%门槛。可是草案只要求理由“充分记录”，会议录像中的讨论还明确拒绝一份适用于所有情况的文件清单。
  • 灵活判断不等于不可见判断。受保护、带版本的例外回执可以统一保存最低事实、证据保管、问答过程、理由代码和申诉路径，而把拓扑、厂商与部署选择留给运营者。

第二座数据中心不是假设

这项提案最早的事实并不来自2026年，而在AFRINIC的2018年政策实施经验报告第八页。

Hostmaster遇到的案例很短：一名终端用户会员为数据中心冗余申请额外的IPv4 /24；当时持有资源的总利用率低于90%；按AFRINIC对Soft Landing规则的解释，会员不能取得更多地址，也就无法建设第二座数据中心。

公开材料没有说出申请人、国家、工单日期、原有前缀、具体拓扑、替代方案、是否申诉以及此后的结果。它更没有证明每一座冗余站点都理应得到新的/24。它只证明一个窄而关键的冲突：顺序门槛要求先把第一份资源用到接近满载，故障域设计却要求第二套功能在第一套出事之前已经存在。

利用率描述已经持有的地址处于什么状态。冗余描述两个功能必须在同一时间可用。前者可以是诚实的节约指标，却仍可能错误衡量后者。

草案2有条件地修正了类别

NOG Alliance中立提案追踪页以较宽泛的Under discussion标签收录AFPUB-2026-IPv4-002-DRAFT02。AFRINIC-37会议录像则记录了共同主席认定形成粗略共识并将其送入Last Call。草案1提交于2026年5月6日，草案2修订于6月16日，并于6月24日讨论。截至8月23日，它仍是提案，不是已经实施的豁免。

通常规则没有消失。在Exhaustion Phase期间，已经持有IPv4的LIR或终端用户再次申请分配或指派，仍须证明以往所有IPv4资源至少使用了90%。从未持有IPv4的新LIR或终端用户，第一次申请继续不受这个条件约束。

草案2拟增加第三条路。如果申请人能够证明关键技术用途，而现有资源无法实际为其服务，或者相关用途对现有地址池形成技术约束，AFRINIC可以豁免90%。冗余、高可用、IPv6过渡机制和扩展到新站点只是非穷举例子。就这一条而言，合格请求会按第一次分配或指派处理。

然后，整套公共证据规范被压缩成一句话：申请理由必须被充分记录，使AFRINIC能够验证理由是否成立。

这比只写“高可用”进步了一步。标签不能自行证明，申请人负有举证义务，AFRINIC负有核验任务。但草案没有继续回答：真正需要证明的命题是什么；哪些最低事实必须留下；多年后换一位复核者，怎样分清技术约束与运营偏好。

普通门槛有百分比，例外却没有类型

现行综合政策手册把1.6版列为当前版本。90%是可见的，通用举证原则也可见：申请可以提交工程、子网、拓扑和路由计划；预测必须现实并且能够说明理由；政策和实践不应因地点、国籍或规模而差别适用；用于评估但无须登记公开的商业资料必须保密。

这些条款构成专业审查环境，却没有为新例外规定数据类型。

设想两名利用率完全相同的申请人。第一名因为客户合同偏好另一座城市，想建第二站点。第二名已经设计两个独立供电、独立失效的域，无法把两套转换功能放在同一物理或路由依赖之后。两者都能写“冗余”。只有名词之下的证据，才能判断现有地址是否真的无法服务，也才能判断约束在草案意义上属于技术还是运营。

字段不能自动作出结论。字段能保存结论如何形成。这两件事不可混为一谈。

没有统一文件清单，不等于没有统一接口

AFRINIC-37会议录像保留了一场有价值的分歧。有人问：申请人未达到90%时，究竟要提交哪些技术文件？提案作者回答，不宜列一份适用于所有案例的清单，因为IPv6过渡和多站点部署所需证据不同，审查会是申请人与工作人员之间的输入输出对话。

这个判断有道理。适合数据中心的拓扑图，未必解释地址转换池；采购单能证明设备已买，却不能证明故障域已经分离；流量预测能描述负荷，却不能证明路由独立。

另一位与会者原则上支持提案，同时警告：任何申请人都可以声称需要高可用或冗余，过宽的措辞会让工作人员难以公平、一致地执行。作者反对穷举一切合法例子，因为固定清单会排除新情况，也会把政策变成对Hostmaster的微观管理。会员服务负责人则给出关键边界：技术约束可以触发例外，运营约束不可以。

讨论否定了两个极端，却没有补上中间层。万能材料包过于僵硬；没有结构的形容词又无法审计。所缺的是一组共同字段，而字段里的值允许因案而异。

共同主席在会上认定形成粗略共识，将提案送入Last Call。录像还说，秘书处会在这一阶段提供utilisation定义。中立追踪页仍保留较宽泛的标签，本稿采用的公开证据也没有证明提案已获批准、实施或形成字段级例外规范。这不能证明某个定义从未在别处流通过；它只能说明，读者无法从提案和录像内容中复原判定接口。

“充分”把保护措施搬进了工单

提案演示与讨论把保障放在“充分记录”这几个字上。新文本要求两点：现有资源对于所证明的技术需要确实不实用；申请人还必须让AFRINIC能够核验。

它实际定义了一条关系链：

技术功能 → 现有资源无法实际服务 → 需要新增IPv4切片

每个箭头都需要证据。功能是什么？核查过哪些现有地址块？为什么复用、重新编号、调整聚合或换一种位置不可行？新切片服务哪个站点或故障域？新旧资源需要并行多久？什么事实会推翻理由？

如果没有稳定答案，保障只存在于来往邮件之中。今天的申请人可能明白为何获批或被拒；换任复核者、审计者或准备申诉的申请人，看到的却可能只是一个结果和一袋互不相同的附件。

裁量、理由与复核各做一件事

会议录像把审查描述为输入输出对话，而不是一套万能材料包。它没有证明决定必须是终局，也没有证明任何特定的法律申诉权。专业裁量、留下理由以及适用的纠错或复核路径，因此是三个不同的设计选择。

这段讨论把三件常被“裁量”一词吞没的事拆开了。

裁量，是无法写成机器测试时解释事实的空间。理由，是说明如何使用这一空间的记录。申诉，是检查规则、事实和理由是否正确连接的路径。保留第一项，并不要求隐去第二项或取消第三项。

没有决定记录的纠错或复核，只是把同一场对话搬到另一层重新开始。申请人必须知道失败的究竟是架构、无法复用的证明、申请规模、材料质量、技术分类，还是规则版本。复核者也需要同一份记录，以免事后更换理由。

多PoP示例不自动产生权利

提案演示用一个多PoP的464XLAT部署说明问题。这是设计场景，不是经过审计的会员网络，不自动赋予新地址，也不是通用拓扑。它证明的边界更窄：某项技术功能可能必须在多个故障域同时存在，而总体利用率尚未达到顺序门槛。

RFC 6877描述的464XLAT把核心侧有状态转换与边缘侧无状态转换结合起来，为IPv6-only网络提供有限IPv4连接。该RFC属于Informational，并没有规定真实运营者必须使用四个PoP、每站两台设备或某个固定前缀长度。

所以政策不该编码唯一拓扑。共同层只需要知道：新增资源服务哪个转换功能和故障域；现有资源为何不能服务；需求如何计算。平台、冗余协议、设备摆放和路由设计仍应由运营者决定。

最小规范要求严格字段，不要求厚重设计

Lu Heng的最小初始规范提供了一条有用边界：共同规则应只保存协调所必需、能够验证的最低事实；不会改变共同不变量的后续运营选择，应留给真正运行网络的参与者。

IPv4节约是真实问题。AFRINIC控制有限地址池，必须核验新增委派确有依据。登记准确、唯一性和公平适用都要求共同决策规则。但这并不会把数据中心厂商、NAT64平台、内部路由或建设顺序变成注册管理机构的不变量。

可行的结合比一本政策手册更小，又比一个形容词更强：规定每项决定必须保留的字段；让运营者用适合本身设计的证据填写；敏感附件继续受保护；只公开不泄露会员和拓扑的统计，以及使用的规范版本。

这不是降低严格程度。含糊的共同层迫使每名Hostmaster和每位申请人私下发明一份规范。最小接口只是把真正共同的部分写明，其余部分留在本地。

例外回执需要十八个字段

以下是本文建议的最小接口，不是AFRINIC已经存在的表单或程序。

  1. 申请或工单ID。 把证据、问答和结果绑定到同一宗申请。
  2. 规则身份。 记录政策、草案或实施版本，以及实际引用的段落。
  3. 申请人和请求类型。 区分LIR与终端用户、分配与指派、首次与追加。
  4. 通常基线。 冻结本来适用的资源组合快照和90%精确计算。
  5. 例外类别。 明确冗余、高可用、IPv6过渡、新站点或另一项技术用途。
  6. 功能单元。 在受保护记录中标识站点、PoP或功能；对外仅使用匿名或汇总标签。
  7. 申请切片。 把所求前缀或数量对应到每个站点或功能，而不是审批无法解释的总量。
  8. 并行窗口。 说明为何功能必须同时部署，以及新旧资源共存的期限。
  9. 不实用关系。 记录现有资源因拓扑、路由、转换或故障域原因无法服务的逻辑。
  10. 地址计划。 保存每项有关切片的当前和预测使用量、计量单位与时间范围。
  11. 闲置空间分析。 列出未使用持有量，并记录为何不采用复用、重新编号或替代摆放。
  12. 证据保管。 列出文件、哈希、控制者、访问边界和保留期限，不把敏感拓扑塞进公共元数据。
  13. 对话历史。 追加保存复核问题、申请人答复与时间戳，不用后来的答案覆盖先前理由。
  14. 分类与理由。 记录技术、运营或混合判断，使用稳定理由代码并附自然语言说明。
  15. 决定与条件。 记录批准或拒绝、授予规模、条件、有效期和后续复查。
  16. 纠正与申诉。 标出通知、事实纠正渠道、期限和适用申诉路径。
  17. 替代版本。 链接后来改变测试的政策或程序，同时保留决定当时使用的版本。
  18. 公共汇总。 公开数量、类别、处理时间段、结果和纠正统计，使一致性可审计而不披露会员或拓扑。

这些字段不能替代判断四PoP设计是否真实。它们能让判断可重现：第二位复核者看到同一资源组合、同一约束和同一未回答问题；申请人能纠正事实而不改写历史；AFRINIC能观察某类例外、某种会员规模或某个流程阶段是否产生无法解释的差异。

例外成为入口之前，先公布接口

草案2的方向可以成立。第二个故障域不应因为第一个尚未接近满载，就被迫等到风险发生之后才建设。2018年的材料罕见地直接说明，现行顺序规则会阻挡其试图评价的架构。

草案也保留了重要约束：技术用途必须被证明，不能只被宣布。问题不在于存在专业判断，而在于公共规则没有说明判断结束后究竟留下什么。

“充分记录”可以启动对话，却不能充当稀缺资源例外的永久记录。AFRINIC应在豁免投入运行之前公布最小字段、受保护证据规则和理由代码。这样，注册管理机构可以节约地址池而不替运营者设计网络；运营者可以设计网络而不自行定义证据标准。

来源