摘要

  • James Spenceley 与 Jonny Martin 在 2009 年 1 月的 prop-070 原案中，为 APNIC 单次 IPv4 分配设置上限：IANA 空闲池逐步缩小时，最高可领块从 /8 依次降至 /9、/12、/14、/16 和 /18。
  • APNIC 27 逐字稿记录了支持小机构留有机会的论点，也记录了大网络客户需求、申请工作量及 NAT 风险的反对意见。APNIC 年表将提案状态记为 2009 年 2 月 26 日放弃。

IPv4 快用尽时，最后一个大块该给谁？眼前有运营商拿着实际客户需求，门外还有尚未轮到的小网络。Spenceley 和 Martin 提出一把会自动收紧的尺子：不管单个申请者能证明多大的需求，APNIC 一次发放的地址不得超过当时的上限。尺子的刻度由 IANA 全球空闲池决定。

prop-070 的表格从 IANA 还剩 30 个 /8 时的单次最高 /8 开始；剩 25 个时改为 /9，20 个为 /12，15 个为 /14，10 个为 /16，五个为 /18。两端分别是 16,777,216 和 16,384 个地址。它限制的是一次分配的大小，并非一个机构终生可持有的总量。另案保留的最后一个 /8 不在这把尺子的适用范围内。

Spenceley 在马尼拉会议上描绘的坏结局是：一个大会员或国家注册机构先拿走剩余大块，后面二三十个小会员只能等空池。他没有举出已经发生的具体案例；这是一份防患于未然的设计。原案也承认自己的代价：若只有 APNIC 设上限，其他区域注册机构仍发大块，亚太可能吃亏；申请变小、次数变多，会员和秘书处都要多跑流程。

讨论把抽象的“公平”拉回网络。Izumi Okutani 问，大运营商若确有客户要接，APNIC 凭什么只因上限就少给？John Schnizlein 担心细水长流的配给反而鼓励 NAT 和封闭网络。共同作者 Martin 已判断硬上限难获支持，转而展示排队优先级的方案。Philip Smith 指出反复申请的额外工作。Spenceley 承认方案越写越复杂，却仍希望保留防止单个会员突然拿走大份额的保险。

他没有要求现场对硬上限宣布共识。官方提案年表把 prop-070 记为 APNIC 27 放弃。/18 从未通过这份提案变成真实的发放闸门。会议留下的难题比表格更具体：给后来者保留机会，会不会让眼前已证明需求的网络把客户挡在门外？

来源

prop-070 原文 · APNIC 27 政策组逐字稿 · APNIC 提案年表 · 肖像依据的官方具名照片