摘要

  • AFRINIC 董事会在 2006 年 5 月通过 Resolution 200605.27，批准了 AFPUB-2006-v6-001，即从 IANA 向各区域互联网注册管理机构分配 IPv6 地址空间的拟议全球政策，并要求工作人员采取必要的实施行动。ICANN 后来的区域流程表把 AFRINIC 董事会采纳日记为 5 月 15 日；编号末尾的“.27”只是决议序号，不能被解读成 5 月 27 日。规则以 /12 为最小上游分配单位，目标是覆盖至少 18 个月的登记需求。
  • 这不是一次可用票数展示的民意授权。AFRINIC-3 的记录把该提案列为形成共识的提案之一，但事后的最后征求意见摘要同时写明：这个具体提案没有讨论，却被认定形成共识。2 月 9 日通知曾误称参与者投了票；Alan Barrett 随即纠正说没有投票，Alan Levin 只是不确定地回忆也许投过票且当时只有两名有投票权的成员在场，首席执行官 Adiel Akplogan 最后明确表示没有投票，因为当时的政策发展程序以共识而不是表决处理政策。
  • 开放会议上的共识认定与董事会批准是两个关口。AFRINIC 的同意是共同文本进入后续 NRO、ASO、ICANN 与 IANA 环节所必需的区域步骤，却不足以单独约束 IANA、其他 RIR 或未参加这一私人安排的人。它是有效而有用的内部协调行动，不是主权授予，也不是对 IPv6 地址空间的产权凭证。
  • 最可靠的证据在于政策文本、公开通知、决议措辞和后续登记结果；最薄弱之处在于 AFRINIC 自己的董事会问责记录。现有公开材料没有给出出席者、法定人数、动议人、附议人、利益冲突、逐人立场、赞成票数、反对票数或弃权数，也没有公开政策工作组主席向董事会提交的报告。

一项短决议究竟完成了什么

Resolution 200605.27 的重要性不在文字篇幅，而在它所处的位置。AFRINIC 的董事会页面把该决议列在 2006 年 5 月名下，称董事会先听取政策工作组主席关于未决政策状态的报告，随后批准四项提案，并指示工作人员采取实施这些提案所必需的行动。其中一项就是 AFPUB-2006-v6-001。它处理的是 IANA 如何向 RIR 补充 IPv6 库存，而不是 AFRINIC 如何把地址分给会员、网络或终端用户。把上下游混在一起，会使一次供应规则的公司批准，看起来像是对非洲所有地址使用者的立法；文本本身并不支持这种扩大解释。

这项决议把四项政策放在同一条记录里。除本篇研究的全球 IPv6 上游分配政策外，记录还提到临时资源分配、区域 ASN 资格标准和四字节 ASN 提案。这里列出它们，仅为说明决议的捆绑呈现方式以及旧会议材料在政策清单上的可能歧义；其期限、续期、归还、费用、多宿主、路由证据、资格条件、转换时间表或兼容性机制均不是本篇的对象。公开记录也没有说明董事会是否把四项提案作为不可分割的一揽子事项决定，还是分别审议后共同记入一项决议。

AFRINIC 的当前政策页面把 Alan Barrett 列为提案作者，并保留早期编号 afpol-glbipv6200508，但页面对其姓氏的拼写有误，详情栏还显示了与流程顺序不一致的 2005 年 5 月 17 日。ICANN 后来的背景表把该议题进入 AFRINIC 流程的时间记为 2005 年 8 月 1 日，这比当前页面那个详情日期更符合已核对的顺序。因此，8 月 1 日是目前较可靠的引入日期；5 月 17 日不能被当成采纳日或实施日。小小的页面字段冲突恰好说明，长期保存流程不仅要留下结论，还要保留版本、上下文和纠错轨迹。

AFRINIC 同意的是一套上游库存算法

共同文本的核心是把 IANA 向 RIR 供给 IPv6 空间的判断，从逐案协商尽量转化为可比较的数量规则。最小分配单位是 /12。按前缀容量计算，一个 /12 包含 2 的 20 次方、即 1,048,576 个不同的 /32 单位。这个数字只描述地址前缀的容量结构，不说明多少地址已被下游分配、实际使用或路由，也不证明需求、市场价值或所有权。规则要求一次上游分配足以支持 RIR 至少 18 个月的登记需求，从而把补货视野从临时救急拉长到可以安排库存和服务连续性的周期。

政策生效之初，任何当时未分配 IPv6 库存少于一个 /12 的现有 RIR，都可以获得一个 /12；一个新 RIR 则在获得 ICANN 承认时取得分配。这里的“相同起始单位”提供了可比较的上游基线，却不意味着各地区的终端接入、部署规模、价格、需求或实际收益相同。共同文本还明确允许每个 RIR 选择自己的下游分配与预留策略。全球层面负责供给可用且唯一的库存，区域层面保留具体使用规则；这种分工减少了全球机构对区域政策的细部干预，同时也把下游政策风险继续留给运营商和资源使用者。

追加分配有两个可替代的资格门槛。第一，RIR 的可用空间低于一个 /12 的 50%；按前缀算术，这相当于 524,288 个 /32 单位，也就是一个 /13 的容量。第二，可用空间少于未来 9 个月已经确定的必要空间。只要满足其中一项，就可进入追加分配判断。追加量原则上是一笔足以覆盖已经确定的 18 个月必要空间的分配，而不是把许多小块零散地逐次塞入库存。

“可用空间”也不是页面上某个余额数字。它由当前空闲地址，加上未来 3 个月内将到期的预留，再减去碎片空间得出。碎片空间是现有库存中小于该 RIR 最小分配规模、因而难以按正常规则使用的块。把碎片扣除，承认了账面剩余与可运营库存并不相同：很多不适配的细小余块并不能替代一个可聚合的大块。这一设计既有库存管理意义，也有路由与登记管理意义，因为较大的连续前缀和清楚的余量口径，可以降低无法有效使用的小块带来的行政摩擦。

在普通情形下，必要空间依据过去 6 个月每月平均分配的地址数量，再乘以规划期的月数。若计算 18 个月的必要空间，就是此前 6 个月月均量的 18 倍，也等于此前 6 个月分配总量的 3 倍。历史平均让判断具有可重复的起点，但它不是对未来需求的绝对预言。因此，文本保留“特殊需要”路径：RIR 可以依据特殊事实提出不同的增长率，但必须提供清楚、详细的理由。根据主张所依赖的原因，证据可以包括趋势数据、政策变化的影响分析，或外部因素的分析与可核验引用。

特殊需要路径中仍有判断余地。政策规定，如果 IANA 没有掌握足以明确质疑 RIR 预测的材料，那么未来 18 个月的特殊需要预测应被视为有效。这比完全任意的裁量更受约束，因为 RIR 要提交可检验说明；但它也不是纯粹机械计算，因为“是否存在明确质疑材料”仍需作出判断。证据责任、审查理由和更正机制若记录不充分，公式看似客观，争议仍可能转移到预测可信度和审查者掌握的信息上。

文本还要求 IANA、NRO 和 RIR 公布分配并更新各自网站，由 ICANN 与 NRO 建立行政程序。公开公告让上游动作进入可核对的登记链。然而，政策明确不规定 IANA 的服务性能要求，把响应时间、服务承诺等问题留给适当的 ICANN—NRO 协议处理。运营商可以从这份政策知道资格数学，却不能从中获得何时答复、延误如何补救或服务中断如何升级的承诺。规则提高了“应分多少”的可预测性，没有解决“多久办完、拒绝怎样说明、失误怎样纠正”的全部执行问题。

开罗的共识：日期不稳，投票说法被纠正

AFRINIC-3 在开罗的材料构成董事会批准前的区域流程证据，但不能被整理成一个并不存在的整齐故事。当前政策历史把共识日期写成 2005 年 12 月 3 日；然而，12 月 5 日的一封邮件仍把提案描述为等待开罗讨论。会议纪要标注 12 月 14 日，2006 年 2 月 9 日的最后征求意见通知又把会议说成 12 月 12 至 13 日，AFRINIC 另一处活动页面则称 12 月 13 至 14 日。除非专门分析这些差异，最诚实的表述只能是“2005 年 12 月的开罗会议”，而不能挑选一个精确日子假装冲突已经消失。

会议纪要把从 IANA 向 RIR 分配 IPv6 地址的提案列入“取得共识”的提案清单，并说这些提案将回到邮件列表进行 15 天的最后征求意见，然后才交董事会作最终批准。这个顺序本身很重要：会议层面的共识认定不是最终的公司批准。后来的提案专门摘要同时写着“没有讨论，政策形成共识”。因此，记录所能证明的是工作人员和会议材料怎样描述流程状态；它不能证明谁就该提案发言、提出何种异议、举了多少只手、同意者占多少比例，甚至不能说明在没有提案专门讨论的情况下究竟用什么可审计标准判断了共识。

2 月 9 日，AFRINIC 工作人员就四项提案开启为期 15 天的最后征求意见。通知的总述先称“社区”同意并投了票，随后对本提案的摘要却说没有讨论、实现了共识。2 月 11 日，提案作者和参与者 Alan Barrett 在公开邮件列表中指出，没有发生投票，尽管当时看起来存在共识。2 月 13 日，Alan Levin 提供了不同但明确带有不确定性的记忆：他以为也许在讨论前投过票，并回忆现场只有两名有投票权的成员。Adiel Akplogan 随后以 AFRINIC 首席执行官身份回答，没有投票；按照当时的政策发展程序，政策不是投票事项，而是以共识决定。

这个纠错链不能被压扁成“所有人都记得同一件事”，也不能把 Alan Levin 的犹疑记忆抹去。恰当的证据权重是：通知中关于投票的说法受到当事人及时质疑；一人记忆不确定且只提到两名有投票权者；最后的 AFRINIC 第一方解释明确否认投票，并说明采用共识程序。无论采信哪一条，材料都没有给出参与者总数、邮件列表订阅者数量、回应数量、支持与反对的分母或完整异议台账。由此能确认的是“无投票的共识认定”，而不是一场可量化的选举。

最后征求意见的结束日也不应被悄悄修平。现行政策历史写的是 2006 年 2 月 9 日至 24 日；2 月 9 日通知承诺 15 天后结束，按经过天数推算也指向 24 日。可是 3 月 7 日的关闭通知称征求意见在“25/02/2005 中午”到期，并说政策工作组将把提案交给董事会。这里既有显然与邮件日期及整个顺序不相容的 2005 年，又与 24 日相差一天。可以判断年份字段很可能有误，却不能因此擅自把原记录改写成唯一正确的 24 日或 25 日。精确结束日仍是 2006 年 2 月 24 日或 25 日之间的文献冲突。

董事会关口：有决议，没有可核对的票箱

ICANN 的跨区域流程表把 AFRINIC 董事会采纳日期记为 2006 年 5 月 15 日。AFRINIC 自己的页面只把 Resolution 200605.27 归入 5 月，并没有用编号证明 27 日开会。决议所留下的清楚事实有三项：董事会听取了政策工作组主席关于开放政策的报告；董事会批准了包括全球 IPv6 政策在内的四项提案；工作人员收到采取必要实施行动的指示。AFRINIC 当前政策历史又把 AFPUB-2006-v6-001 标记为 5 月 17 日实施，但页面没有说明那天完成了哪一个具体动作、由谁负责、如何验收。

同样清楚的是缺失项。决议页面没有提供本项议题的董事会出席名单、法定人数证明、动议、动议人、附议人、单项表决、赞成与反对票数、弃权、利益冲突声明、个别董事立场或提案专门理由。政策工作组主席的报告没有被公开，决议文本也没有在该处点名主席。没有董事会专门文件说明实施指令对应哪些任务、完成标准或签署者。还无法判断四项提案是作为一个不可拆分的包通过，还是分别判断后合并记录。决议可以证明公司作了批准，却承载不了后来附加的“所有非洲运营商都已授权”之类宏大结论。

尤其需要隔离数字 13-0。公开的 13 票赞成、0 票反对且无弃权，属于 ICANN 董事会 2006 年 9 月 7 日的特别会议，时间比 AFRINIC 的行动晚约四个月。该记录说 13 名出席的 ICANN 董事一致批准相关决议。AFRINIC Resolution 200605.27 没有公开票数。把 ICANN 的票数倒贴到 AFRINIC，不只是小错，而是用一个机构透明的记录填补另一个机构的空白，最终会伪造 AFRINIC 内部问责的历史。

必要，但绝非充分：五个相继关口

2004 年 10 月 21 日，ICANN 与 NRO 签署了当时适用的 ASO 谅解备忘录。它把全球政策定义为：由所有 RIR 按各自政策发展程序同意、再由 ICANN 同意，并需要 IANA 或其他与 ICANN 有关的外部机构采取行动的互联网号码资源政策。附件所列链条要求工作人员找出共同文本，各 RIR 以自己选择的方式批准，NRO 执行委员会转交，ASO 地址理事会审查流程，最后由 ICANN 董事会批准。这个文件证明相关私人机构采用了什么程序，不自动证明未参加安排的运营商、用户或国家授予了公共权力。

在这条链上，AFRINIC 的同意既不是可有可无，也不是一锤定音。若一个区域没有接受共同文本，提案就不能如实作为“所有 RIR 已同意”的文本继续前行，除非回到区域处理、修改文本或改变程序。因此 AFRINIC 有事实上的流程阻断位置，这使其批准具有后果。但这种阻断位置来自共同程序的设计，不是对互联网的主权否决权。它可以让私人协调链暂停，不能让 AFRINIC 对其他机构或非当事人立法。

AFRINIC 通过后，后续行动仍分别发生。ICANN 的背景报告称，第二版共同文本到 2006 年 5 月 16 日已由五个 RIR 正式采纳。NRO 执行委员会在 6 月 6 日把提案提交给 ASO 地址理事会；地址理事会在 7 月 12 日采纳，并由秘书在 7 月 13 日转交 ICANN。9 月 7 日，ICANN 董事会才批准全球政策，指示工作人员实施，要求与 RIR 一起及时报告分配，并要求在三年内评估政策效果。随后 IANA 才在顶层登记中执行分配。

因此，每一层只证明自己的动作。NRO 的转交不替代 AFRINIC 批准，ASO 的流程审查不是法院判决，ICANN 的批准不是对 AFRINIC 公共授权的追认，IANA 的登记也不是对区域政治所有权的确认。多层机构依次重复“同意”，容易制造授权在流转中不断变厚的视觉效果；事实上，任何一层都不能洗出原始文书没有授予的主权。流程的兼容性可以随着每一关增加，公共权力却不会因印章数量增加而凭空生成。

2c00::/12 是执行结果，不是领土凭证

2006 年 10 月 3 日，IANA 的 IPv6 全球单播地址分配登记表记录了分给 AFRINIC 的 2c00::/12。同一天，APNIC、ARIN、LACNIC 与 RIPE NCC 也各有 /12 分配记录。表中还保留 AFRINIC 更早的 2001:4200::/23 条目，日期为 2004 年 6 月 1 日。这个后续记录是本案最直接的操作结果：在各区域与全球关口完成后，顶层账本出现了一笔可核对的 AFRINIC 分配。

但登记表没有公开 AFRINIC 的申请、IANA 审查材料、决定所用时间、实施往来函件或一套所有权法理。它证明前缀在全球唯一性账本中怎样记载，不证明 AFRINIC 获得非洲网络、用户、国家或地址的政治所有权。服务区域不是领土，获得 /12 也不是立法授予。全球唯一性要求各方避免顶层记录冲突，而“由谁维护唯一记录”与“谁拥有政治统治权”是两件不同的事。

这种区分并不贬低技术结果。网络运营商和 AFRINIC 资源使用者需要稳定的上游库存，才能安排下游申请与服务连续性。18 个月的供给视野减少临近耗尽时逐案谈判的压力；/12 单位与碎片扣除有利于保持可用、较易聚合的库存；普通需求公式使不同 RIR 的请求更可比较；特殊需要的证据要求让预测有机会被质疑和核验。成功的协调越有运营影响，越需要强韧的审计、连续性与纠错控制，而不是越有理由把账本管理员神化成统治者。

运营收益及其未覆盖的风险

第一项收益是库存可预测性。至少 18 个月的规划期让 AFRINIC 不必完全依赖最后一刻的上游协商，可以更有秩序地规划登记服务能力。第二项收益是减少不一致和临时讨价还价。统一的 /12 起始单位、两个补货门槛和共同计算方法，为一个全球唯一地址池提供可协调的供应语言。没有共同口径，五个区域分别进行无关联的逐案交易，可能更快处理个别请求，却更难比较、更依赖裁量，也更难审计。

第三项收益是证据质量。特殊需要不能只靠一句乐观预测，必须解释趋势、政策影响或外部因素并提供可核验材料。与此同时，IANA 在缺乏明确反证时接受预测的规则，仍给信息掌握者留下判断空间。这是典型的代理问题：流程保管者掌握资料、程序和登记杠杆，运营商承担部署和连续性成本。最合适的回应是公开收件、理由、时间与纠错路径，而不是假设“参与过流程”的人自然代表所有受影响者。

第四项收益与代价同时来自多关口设计。每个区域都能在靠近本地运营商的场所发现不兼容文本或实施问题，NRO、ASO 与 ICANN 又提供后续一致性检查；但任何一个未解决的共同文本或流程问题也会延迟上游确定性。这个系统以速度换取兼容性和可复核性。AFRINIC 若不批准，当时的程序就需要更多区域工作、文本修改或程序变化，相关运营商可能面对更不确定的上游库存；但现有材料不能量化究竟会延迟多久或影响多少请求。

第五项边界是上下游分离。共同政策给各 RIR 相同级别的上游大块，却保留不同的区域分配与预留策略。它不能证明终端用户因此获得同等接入、价格或区域福利，也不能回答 IPv6 的实际部署速度。本文讨论的是库存可得性、证据、连续性和登记秩序，不是 IPv4 与 IPv6 的优劣辩论，也不是以“地址丰富”叙事抹掉部署成本、IPv4 依赖或市场现实。

第六项空白是服务性能。规则明确把 IANA 性能要求排除在外，资格明确不等于响应及时。如果上游流程迟延，运营商可能知道 RIR“应当符合条件”，却不知道答复期限、理由标准或升级通道。假如共同政策带有完整服务级别附件，资格、响应时间、证据审查、说明、更正和升级可能更可执行；但现有材料没有这样一份 2006 年附件，也不能证明附件会消除所有延误。

最强辩护：窄任务不需要伪装成国家选举

对这次批准最有力的辩护，不是把 AFRINIC 说成主权机关，而是承认一个全球唯一的 IPv6 池确实不能靠五套彼此无关的临时交易维持。统一文本给出相同的最小单位和量化补货测试，让每个 RIR 有自己的区域流程，要求所有区域接受共同文本，再增加 ASO 的流程审查和 ICANN 的批准，最终形成可追踪的 IANA 分配。在这个狭窄的私人技术系统里，AFRINIC 董事会作出公司批准，既实际又必要。若要求每一个库存算法都先建立国家式选民名册，反而会把工程协调误当成立法，并可能破坏稳定供应。

这项辩护应得到足额承认。共同上游规则有实际用途；公式减少了一部分 IANA 与 RIR 的议价裁量；区域阶段提供了多次发现问题的机会；AFRINIC 即使没有获得所有运营商授权，其公司同意在私人制度范围内仍可能有效；10 月的登记结果说明这条链确实能够协调执行。技术协调并非虚幻，内部程序有效性也无需假装为公共法才有价值。

但辩护到此为止。内部有效不能补造外部主权。开罗记录没有提案专门讨论、没有投票、没有共识分母；董事会记录没有出席、法定人数或票数。这些缺口并不自动证明决定无效，却足以阻止把决定包装成“非洲社会的普遍授权”。AFRINIC 的同意是一项有用的私人协调行为，其范围止于公司、程序、合同和技术职能；它没有创造主权权力、立法权、监管权、警察权、检察权、司法权、惩罚权或没收权，也没有公共委任或对 IPv6 空间的领土产权。

参与、代表与第一方证据的正确位置

“开放”“自下而上”“社区”“公平”“非歧视”“代表性”或“具有历史意义”可以是机构对自己流程的描述，但不是自我认证的公共合法性。出席会议、订阅邮件列表、未提出异议或被工作人员归入共识，都是协调输入和证据现象；没有明确的委托人、授权范围和可审计分母，它们不能自动变成对缺席运营商的代表权。受行动影响的人很多，不等于参加行动的人获得了管理所有人的政治授权。

应当把现实分层。可执行层包括公司决议、谅解备忘录规定的步骤、共同政策文本、机构服务行动和 IANA 登记；象征层包括对“共同体意志”和“历史重要性”的表达。只有当象征性主张能接回具体文书、授权人、范围与救济时，才可能产生超出宣传语言的制度意义。本案能追踪的是一条私人协调链，不是国家、条约或法院向 AFRINIC 移交统治权的链。

AFRINIC 在本分析中的准确角色，是私人唯一性账本管理员与协调者。它可以维护记录、按规则申请和管理上游库存、在公司与合同范围内安排工作人员，也可以参与共同政策程序。它不拥有非洲的网络、地址、用户或国家。供应和登记规则更不会赋予执法与惩罚职能；超出记录完整性和合同履行的强制，仍属于合同、法院和公法的范围。一个中性的记账者不能因为早期协调成功，就把自己扩大成裁判、警察或财产没收者。

国家与法院保留公法权力。运营商实际建设网络、路由流量并服务客户，因此承担政策实施与连续性后果；可现有材料并不证明全部、多数或某个可测比例的运营商授权了开罗共识或董事会行动。这并不否认利益相关者参与的实用价值，而是拒绝把利益相关者参与偷换成委托人授权。

NRS、Heng Lu、LARUS 与 BTW 在今天的分析中是第一类资料来源，但必须角色准确。NRS 提供 IANA—RIR 分配层级、/12 单位以及权力受合同和本地法律约束的现代理解；它从事研究、倡导、召集，并代表明确授权的成员，却不运营注册管理机构、IANA、RPKI、WHOIS/RDAP、选举、申诉、和解、托管或连续性职能。Heng Lu 提供唯一性协调、参与和授权边界以及 RIR 非主权性的控制性论证。LARUS 从运营商连续性和登记风险说明为什么治理记录会影响基础设施。BTW 则用可合同化的狭窄 IANA 职能和“分配记录不等于下游权力”的方法区分技术依赖、产权与救济。

这些当代来源都没有撰写 2005 年的共同文本，没有宣布开罗形成共识，没有批准 AFRINIC 2006 年决议，也没有作出 IANA 分配。反过来，AFRINIC、NRO、ASO、ICANN 与 IANA 的第一方页面适合证明它们各自的文本、陈述、日期、记录和行动，却不能仅凭机构自己使用“社区”“授权”或“公平”等词，就证明公共合法性。历史事实与规范判断各有证据职责，不能让任何一类材料越位。

一份完整但不过度确定的事实结论

截至现有材料能够说明的程度，事件链是这样的：全球政策议题在 2005 年进入 AFRINIC 流程；2005 年 12 月开罗材料把它认定为形成共识，但具体提案没有讨论，精确会议日存在冲突；2006 年 2 月的最后征求意见通知错误使用了投票语言，随后被公开纠正为没有投票；最后征求意见结束日在 24 日与 25 日之间冲突，关闭通知又误写年份；提案随后交董事会；董事会在 5 月通过 Resolution 200605.27，ICANN 的表把采纳日记为 5 月 15 日；AFRINIC 页面把 5 月 17 日标为实施，却未解释具体动作；全球链条在 6 月、7 月和 9 月完成后续关口；IANA 于 10 月 3 日记录 2c00::/12。

仍未知的事项同样构成结论的一部分：无法从现有记录统一开罗精确日期；没有提案专门发言、异议、投票或参与分母；没有邮件列表订阅与回应分母；政策工作组主席报告未公开；AFRINIC 董事会的出席、法定人数、动议、动议人、附议人、逐人票数、汇总票数、弃权、冲突和理由均未公开；四项政策是否不可分割尚不清楚；5 月 17 日的实施动作不明；当前页面 2005 年 5 月 17 日字段没有纠错记录；没有区域共同文本完全相同的密码学证明或逐区修订对照；没有 AFRINIC 对 2c00::/12 的申请与 IANA 决定收据；政策没有 IANA 性能标准；也没有所有受影响运营商、政府、用户或资源持有者的授权证明，更没有由分配产生财产权或主权管辖的证明。

因此，最耐久的解释是“协调有效，宪制不膨胀”。Resolution 200605.27 完成了 AFRINIC 这一公司的区域批准环节，使一套较少依赖临时裁量的上游 IPv6 供应规则能够继续进入全球流程。其运营结果可以追溯，其内部理由与董事会问责却保存不足。承认前者，无须假装后者不存在；指出后者，也无需否认共同规则的技术价值。