Summary

  • Remco van Mook 与 Marco Hogewoning 提出的 RIPE 2010-06，让本地互联网注册机构选择逐笔登记 IPv6 用户分配，或用标记为 AGGREGATED-BY-LIR、注明 assignment-size 的 inet6num 对象汇总登记。大于 /48 的单笔分配仍需单独记录。
  • 汇总不等于免查：审计或申请后续地址时，运营商须提交池中实际分配数量，供 RIPE NCC 核算 HD ratio。提案于 2011 年 2 月 3 日获采纳；RIPE NCC 在 2 月 15 日的通知中确认数据库功能及相关流程已实施。

一千个用户，一张公开卡片

IPv6 地址空间很大，登记要求却不能靠“大”字糊弄过去。旧规则要求把最终用户分配信息放进区域注册机构可访问的数据库，却没说明是哪一个数据库、该写什么。运营商怕公开过细，审查者又怕看不出资源使用情况。2010-06 最终提案没有给双方各写一段安慰话，而是规定能放进实际数据库的字段。

RIPE-513举了一个直观例子：若一家运营商给一千名用户各分 /56，可以用一个 /46 地址池对象登记，状态写 AGGREGATED-BY-LIR，分配尺寸写 assignment-size: 56。公众能看见这个池和每笔分配的大小，不必翻出一千张附带客户线索的卡片。文件用这个算例说明登记办法，并没有宣称当时真的有这一千名用户。

公开卡片变少，后台账本却不能消失。采纳后的政策第 5.5 节允许逐笔登记，也允许汇总；选择汇总的机构，在审计或再申请 IPv6 地址时必须拿出实际分配数量，供 RIPE NCC 验证衡量利用程度的 HD ratio。单笔超过 /48，则要以 ASSIGNED 状态独立登记。边界并不含糊：对公众展示较粗的结构，对审核保留可核实的数量。

提案作者还点出这张公开卡片的另一面。assignment-size 会透露客户分配的规格，可能暴露运营商的业务轮廓，也可能被用于有针对性的攻击。于是“没写姓名”并不等于“一点信息也没露”。他们选择的是足以支撑登记和核算、又不把每个客户直接摆出来的颗粒度。这比一句笼统的“重视隐私”更接近运营现场。

RIPE 提案档案记载 2011 年 2 月 3 日获采纳；RIPE-513在 7 日发布；RIPE NCC 的二月通知在 15 日说明数据库和相关流程已经实施。一个看似枯燥的状态值，最终回答了很具体的问题：注册机构需要知道多少，才足以核查，却不至于索取整本客户通讯录？

RIPE 原始文件