摘要

  • AFPUB-2018-V6-001-DRAFT01 修复的不是一个孤立错字，而是一组会影响成员和工作人员理解的依赖关系：旧手册仍援引已被取代的 RFC 3177，保留 /128 单设备建议，以固定 /48 口径描述利用率，并带有错误的内部章节引用和过时的多 /48 审查条款。
  • 这项修订最有说服力的地方恰恰在于它平凡、公开而可核对：当前文本与拟议文本并排呈现，经过讨论、Last Call 和实施，最终反映在 CPM 1.3 中。公开程序在这里提供了纠错证据和版本轨迹，却不是立法，也不构成某种地区主权授权。
  • 准确的手册能够降低前缀规划、说明材料、重新编号和解释分歧的成本。可是这种效用只能证明私人登记机构应把唯一性、记录准确、联系可达、安全元数据、抗欺诈变更和运行连续性做好，不能把狭窄的技术协调扩张成对运营者资产、商业选择或权利争议的管辖。
  • 下一步不应停留在“以后更仔细”的承诺，而应形成可审计的维护制度：依赖登记册、可见红线、解释回执、实施通知和权限防火墙必须一起工作，让每次修订既容易追溯，又无法借维护之名夹带控制。

L3 — 藏在手册里的过时引用

2018 年 3 月，AFRINIC 的 IPv6 手册仍然把读者带回 2001 年的 RFC 3177。旧文本给出一套很容易被记成公式的分配图景：通常使用 /48，在明确只有一个子网时使用 /64，在明确只有一个设备时使用 /128。问题不在于二十多年前的技术文件曾经提出这些建议；技术资料本来就属于特定时期。真正的问题是，RFC 6177 已在 2011 年明确取代 RFC 3177，反对给所有终端站点套用单一的 /48 默认值，也不赞成只给终端站点一个 /128。到 2018 年，登记手册中的外部依赖已经落后七年，却仍以现行操作说明的姿态出现。

七年延迟揭示了文档治理中一个常被忽略的事实：引用不是脚注装饰，而是规则的一部分。成员不会只阅读一句孤立条文；他们会沿着条文指向的技术文件理解什么被视为正常、什么需要额外说明、什么可能遭到追问。工作人员也会以同一文本整理申请、形成检查习惯。只要外部文件在手册中承担解释功能，它的版本状态就会进入服务的控制面。被取代的依赖仍留在控制面上，即使数据库中的某一条资源记录没有立即变化，也会制造两套并存的预期：一套来自旧手册，一套来自较新的工程实践。

这不等于可以倒推出故意误导、失职或实际损害。封闭的事实记录没有说明有多少成员真的照旧引用取得了 /128，没有证明有人因此重新编号，也没有量化工作人员究竟提出过多少多余问题。把可能的解释风险写成已经发生的伤害，会把严谨的制度分析变成指控。更准确的判断是：旧依赖提供了足够清楚的风险机制。它可能让网络设计者低估终端站点的增长空间，可能让成员围绕错误默认值准备材料，也可能让不同工作人员对同一需求形成不同认识。风险真实存在，但实际发生率仍未知。

AFPUB-2018-V6-001-DRAFT01 的编号在这里必须准确。它是“IPv6 Policy and References Update”第一版草案，即 V6-001，而不是 V6-002。后者属于另一项关于 IPv6 子分配的提案，不是本文对象。编号更正之所以重要，不是因为目录错误值得喧宾夺主，而是因为一篇讨论手册准确性的文章不能从混淆文书身份开始。准确的标识符把作者、修订历史、会议记录和实施结果接在同一条证据链上；错误编号则会把两个不同问题缝在一起，污染后续判断。

官方提案页把作者记为 Jordi Palet Martinez，记录了 2018 年 3 月 11 日的提交日期，并显示第一版草案于 3 月 14 日发往 rpd 邮件列表。提案对问题的描述相当克制：IPv6 部署实践与此前的文本变化已经使现行政策出现不一致和错误引用，目标是澄清、修正和更新，而不是宣告一次全新的分配制度。年度报告后来也以澄清、纠错和更新引用来概括它。这样的自我描述不能替代逐项核对，但它提示读者应把注意力放在文本差异本身，而非先假定一次激进的制度转向。

第一组差异位于第 6.0 节。旧手册使用 ISP 的称谓，并保留 /48、/64、/128 三种情形与 RFC 3177 的对应关系。拟议文本把称谓改为 LIR，保留 /48 和 /64 作为有条件的示例，删除单设备 /128 的建议，并把外部依据更新为 RFC 6177。这不是简单地把一个文件号换成另一个文件号。新依据改变了阅读方法：终端站点大小不再由一个面向所有场景的硬默认值决定，而应结合网络需要、IPv6 架构约束和运营判断来选择。

因此，修订也不能被误读成“所有终端站点都必须得到相同前缀”。RFC 6177 反对的正是僵硬的一刀切。/48 仍可作为较简单、可扩展基础设施的适当选择，/64 在具体场景中也有位置；关键是不能因为眼前只看见一个设备，便把一个站点永久压缩为 /128。外部技术指导所保护的是足够的寻址空间、合理的层级设计以及避免未来被迫重编的能力，而不是以新的统一数字取代旧统一数字。把“取消固定默认”再写成另一条固定默认，只会复制原来的错误结构。

第二组差异涉及“利用率”究竟计算什么。旧定义围绕已分配给终端站点的 /48 数量展开，容易让人以为衡量单位必须永远是固定大小的块。提案把利用率改写为已分配前缀的数量，而不是前缀大小，也不是某个前缀内部已经使用了多少单个地址。这个区别在 IPv6 环境中非常关键。一个 /48 和一个 /56 都是一次面向站点需求的前缀分配；若把它们强行换算成固定 /48 分母，可能扭曲成员对增长、聚合和后续申请的判断。若改为数地址，又会把 IPv4 式的稠密占用直觉错误移植到 IPv6。

“按前缀计数”也不是对真实网络利用情况的万能描述。它只是在这份手册的特定语境中明确计算对象，防止前缀长度或地址使用数混入另一种指标。任何人都不应由此推断，只要前缀数量达到某个值，所有运营、架构或说明问题便自动解决。它的治理价值更朴素：成员知道应报告哪种单位，工作人员知道不该暗中换用别的分母，双方可以在同一口径下核对记录。定义变得可复算，争议面便缩小；定义若含混，裁量就会在无形中扩大。

第三组差异把固定分配大小的项目符号替换为以需求为基础的运营选择。提案建议在较简单的基础设施中考虑 /48，强调前缀应保持持久，并建议点到点链路使用 /64 的全球单播地址。RIPE-690 提供的运营经验解释了这些措辞为什么不是纯粹风格调整：不充分的前缀大小和不稳定的分配可能导致重新编号、配置变更、日志处理负担、支持请求与客户摩擦。手册中的一句话会进入采购、地址规划、自动化配置和客户承诺，因此技术指导的时间有效性会转化为经济可预测性。

这里仍须保留证据边界。RIPE-690 说明错误选择可能造成哪些类型的成本，却没有证明 AFRINIC 服务区域内已经因旧条文发生特定事故。提案作者在 AFRINIC-28 表示，修订不会影响发放，也不会改变所需的说明信息；工作人员则说文本可按原样实施，对 AFRINIC 的运营没有影响。这些话分别是提案者对范围的说明和工作人员的可实施性判断。它们不应被改写成“运营者必然零成本”，也不能证明所有解释在修订前后完全一致。恰当读法是：正式流程把这次变化当作可低摩擦实施的澄清，但措辞改善仍可能改变规划者如何理解手册。

第四组差异是一条内部交叉引用。旧文本把例外指向第 6.3.3 节，提案改为第 6.5.2 节，同时保留通常不会要求提交详细用户网络信息的表述。错误的章节号很容易被贬为排版问题，然而交叉引用承担着程序导航功能。成员如果沿着死路寻找例外，可能无法判断自己是否属于例外、应准备什么材料；工作人员也可能因找不到正确限制而过度或不足地询问。修复编号恢复的不是机构权力，而是对既有边界的可见性。

“通常不要求详细用户网络信息”尤其值得和正确的例外入口一起阅读。若主句保留克制承诺，例外却指向错误章节，承诺就很难被实际检验。正确跳转使成员能够看见何种情况下规则可能不同，也使工作人员的请求可以对照具体文本。可核对性在此具有双重作用：它帮助合理申请顺利进行，也限制临场扩张证据负担。私人登记服务的正当性不来自要求越多资料，而来自只要求维护唯一性、记录准确和连续运行所确有必要的资料。

第五组差异是删除原第 6.5.4.2 节。该节针对向单一终端站点提供多个 /48，设置了 AFRINIC 层面的文档与审查安排。提案把它标为删除，实施后原来的后续小节顺位替代了这一编号。删除的意义不宜夸大为取消一切说明，也不能与另一份子分配提案混同。它更具体地移除了一项建立在旧固定大小思路上的一揽子审查规定，使手册不再因为“多个 /48”这一形式本身自动启动额外层级。

这项删除显示，编辑维护有时会减去裁量，而不只是修饰文字。过时条款留在手册里，会继续为文档请求提供表面依据；把它明确删掉，成员便不必猜测它是否仍有效，工作人员也不应以惯例将其悄悄复活。可是减负必须依赖清楚的替代文本：如果旧审查被删除，而新需求口径模糊不清，裁量只会从明文转入非正式沟通。V6-001 的价值在于把删除与需求导向、前缀计数和更新后的技术引用放进同一份可见差异中，让读者看到规则如何重新组合。

第 6.8 节有关 PI 的导言也被缩短，但这不意味着该提案重构了 PI 资格制度。更广泛的 PI 更新属于相邻的 V6-004 议题，不应被借来扩大本文范围。同理，V6-003 的初始分配更新和 V6-002 的子分配问题都各有自己的事实与争点。把几个编号相近的 IPv6 提案合成一场宏大改革，会掩盖 V6-001 最有分析价值的特征：它是一项窄而可枚举的手册修订，每一处变化都应当单独说明其对象和后果。

2018 年 5 月 9 日，AFRINIC-28 讨论了 V6-001 第一版。会议记录显示，工作人员认为它可以按原文实施，对内部运营没有影响；共同主席的结果是将其推进 Last Call。随后，实施记录表明 2018 年 11 月 1 日版本的 CPM 1.3 已包含第 6.0、6.1、6.5.4.1 节的更新，并删除此前的第 6.5.4.2 节。11 月 29 日，AFRINIC 又宣布这项更新已经实施，手册更新至 1.3 版。这条时间线足以证明草案、讨论与落地之间的联系。

不过，档案并非处处完美。提案页面仍显示“Under Discussion”，而会议、年度报告和实施记录说明它后来进入 Last Call 并落地。这一冲突说明，单页状态标签不是完整生命周期账本。现有记录也没有给出完整的 Last Call 消息清单、董事会批准会议纪要或精确批准日期，因而不能虚构这些细节。我们可以确认文本被实施，却不能用没有保存下来的程序材料填补叙事空白。档案的不完整本身，恰好支持对版本回执提出更高要求。

到这里，完整差异已经比“修正了几个引用”丰富得多：它更新外部 RFC，移除 /128 默认建议，调整角色称谓，改写终端站点大小的选择逻辑，把利用率明确为前缀计数，引入持久性与点到点链路建议，修复内部跳转，删除过时的多 /48 审查条款，并收短 PI 导言。称它为澄清是合理的；说它毫无解释影响则过于绝对。它没有被证明改变了实际发放结果，却确实改变了读者看到的选择框架。文字层面的变化正是控制面变化最早、最可审计的形态。