摘要

  • AFRINIC 当前的手册把 IXP 的对等互联地址与管理地址分开，为 IXP 对等互联保留专用地址池，并规定可用相邻的 /24 支持扩展到 /23。AFRINIC-37 上，工作人员还报告称，有成员在两类用途之间调换前缀，违反了现行政策。
  • NAPafrica 的 Andrew Owens 介绍了约翰内斯堡的情况：已经有两个 /23，/22 快要用满；如果还要扩张，可能需要再拿两个 /23 才能形成 /21。他说，一项八年前启动的改号至今没有完成。这是单一运营者的报告，不是非洲 IXP 需求的普查，也不是通常所需迁移时长。
  • 在把预留从 /16 扩大到 /15 之前，社群需要了解资源消耗和受影响成员的数量，也需要一套连续扩容与迁移设计。更大的地址池可能缓解稀缺，却无法单独保证下一块地址正好位于交换点可用的位置。

分析

储备“有多大”，只是一个问题

AFRINIC 当前的综合政策手册将 1.6 版列为现行版本，页面给出的发布日期为 2020 年 11 月 17 日。第11节不只规定一个总量。它把对等互联 LAN——参与者通过共享交换基础设施交换流量所用的连续地址块——与管理网络区分开来；后者承载监控、统计、邮件等服务。手册要求管理地址不能从对等互联地址块中划出。它还规定专用且公开列明的对等互联地址池，并要求为每个交换点留下相邻的 /24，以便其扩展到 /23 而无须换到另一块连续空间、重新编号。该节提出为对等互联保留一个 /16，并另设等量的 /16 作为管理地址储备。综合政策手册

会议上，一位参与者问，整个区域使用的 /16 储备是否足够，还是应考虑 /15。/15 的地址数是 /16 的两倍，但这个算术关系无法说明还剩下多少可连续分配的空间、消耗速度有多快，或者哪些申请可能受到限制。AFRINIC 工作人员表示会提供消耗统计，供社群讨论。另一位参与者特别要求说明受影响成员数量，以便先判断问题的紧迫性。AFRINIC-37 会议记录

这不是程序上的小节。储备既是库存规则，也是分配规则：规模决定有多少地址被保留，分配单位与相邻关系决定运营者能否连续扩容，记录则要说明谁取得了资源、用途是什么、还剩多少余量。若只决定第一个问题，库存或许会变大，下一级扩容仍可能没有着落。

发现用途不合规，还不能解释成因

会议记录转述工作人员的说法：有成员把对等互联和管理用途的前缀互相调换，这不符合政策；工作人员正在与成员协作，使实际用法回到政策范围。这个表述指出了执行问题，却没有说明为何发生、涉及多少成员，或者主因究竟是规则文本、成员登记、行政流程还是运营实践。若不先识别失灵环节就改写政策，文字可能变了，网络里的用法却没有变。

手册第5.6.4节与第11节有关联，但并非同一项安排。前者讲的是关键基础设施的 IPv4 终端用户分配，通常不超过 /24，但特定情形可以有多个分配；后者讲的是 IXP 对等互联与管理地址池，预留相邻 /24 的目标是让网络扩展到 /23 而无须改号。手册还把 IXP 定义为由单一实体运营的第二层物理基础设施，至少接入三家 ISP，并对其他参与者保持开放。AFRINIC 的公开申请条件另要求证明在非洲有合法存在，提供至少三家 BGP 对等方的 ASN 和联系人或签署的合作备忘录，证明交换点公开开放，并在当地法律要求时提供运营许可。AFRINIC 资源申请条件

这些条件有助于判断申请者是否符合资格，却不能测算未来需求，也不能保证现有地址块恰好适合某个交换点的成长路径。同样，前缀被挪作别用，并不能说明工作人员是否拥有及时发现它的资料和工具。

约翰内斯堡案例说明地址几何，不代表整个大陆的需求

Owens 说，NAPafrica 在约翰内斯堡有两个 /23，接近把 /22 用满；若要继续拿到地址，还需要两个 /23 才能到 /21。他也说，该部署的重新编号八年前就开始了，至今没有收尾。会议记录只提供了这一个运营者的经验，没有样本分母、其他 IXP 的可比数据、独立成本估算，也没有解释迁移为何耗时如此之久。

这个例子仍然有价值，因为总地址数掩盖了地址布局。四个 /23 只有在相邻且边界对齐时才能组成 /21。若一个 IXP 通过几次分开的分配逐渐扩大，它需要的不只是“多少地址”：还需要可用的连续扩展次序、迁移期间维持服务的办法，以及协调参与者所需的时间。现行手册中的相邻 /24 机制，明确针对的是先扩展到 /23 这一步。Owens 所描述的情形则提出了后续问题：成功完成这一档之后，交换点怎样继续扩大？这个例子不能证明政策已经失效，却提醒政策设计者不要把下一档的解决方式想当然。

会议上也有人援引 RFC 8950，提出把它纳入双栈运营选项。IETF 标准允许在 BGP 对等方协商了相应能力后，用 IPv6 下一跳通告 IPv4 路由。这是一条可能的技术路线，却不能证明所有路由服务器和参与者都已准备就绪，更不能据此宣布专用 IPv4 对等互联 LAN 已无必要。RFC 8950

先公布证据，再决定是否扩大储备

会议记录表明，社群同时提出了两个问题：区域储备应该多大，以及单个交换点如何避免反复改号。工作人员回应称会在邮件列表上提供消耗数据；另一位参与者要求给出受影响成员的具体数量。本文查阅的公开资料尚不足以确认这项承诺是否兑现、何时兑现。这是报道范围的限制，并不能证明后续从未公布过数据。

下一份有用的记录应当把相关数据放在同一处，又把问题分开呈现。对对等互联池和管理池分别列出初始规模、已经分配、已归还和剩余空间；列出被限制的申请数、分配的前缀大小及其连续性。它还应区分已获批需求与预测需求，并说明“使用”究竟指已分配、已部署、已在路由中宣告，还是仅仅持有。附上日期和计算口径的一张表，比一个孤立的利用率百分比更能支持决策。

库存表还需要一张迁移路线图：政策允许哪些扩容档位，如何保留相邻地址，当连续空间无法提供时怎么办，谁来协调改号，运营方和参与者可以依赖哪些安全措施或例外流程。这不是要求保证每个申请都能拿到相邻地址，而是让节约资源与避免迁移之间的取舍在个案发生前可见。

如果数据表明专用 /16 已难以继续提供 /23，扩大地址池可能有理据。如果申请集中在少数需要较大连续扩展量的交换点，同一组数据也可能说明应调整预留的地址布局或采用分阶段过渡。如果前缀在类别间调换才是主因，完善登记和合规支持或许比把库存翻倍更有效。单凭会议记录无法在这些选择之间下结论。

合理的顺序很简单：公布池中还有多少空间，说明哪些申请无法满足，再展示规则允许怎样扩展和迁移。这样社群才能判断答案应是更多 IPv4、更合适的储备布局、更好的登记，或几种办法并用。NAPafrica 的个案让人看到错误排序可能造成的代价；只有更广泛、公开的数据才能告诉 AFRINIC，这种代价会多频繁地出现。

来源