Summary

  • Tore Anderson 与 Jeroen Lauwers 合著的 RIPE 2023-04 于 2024 年 4 月 15 日获通过，为 IPv4 PA 分配引入 AGGREGATED-BY-LIR 状态。
  • 本地互联网注册机构可把地址连续、用途与联系人一致的分配写入一条记录；受审计时仍须交出其中各笔分配的数量统计。

一边是纸山，一边是空白页

RIPE 2023-04 提案记录了 2023 年 8 月的一组奇妙账目：数据库里有 546,402 条 IPv4 PA /32 分配记录，按前缀长度算，每条只对应一个地址；与此同时，10,052 家本地互联网注册机构（LIR）名下的 19,221 个 PA 母块没有任何子分配记录。一边像每买一颗螺丝都单独开票，一边像只记下一整箱却不记箱里去了哪里。两种记录方式都让核对变得费劲。

Tore Anderson 和 Jeroen Lauwers 没有从“再填几张表”开始。他们看的是 INETNUM 对象本身。LIR 把 PA IPv4 地址分配给自身网络或终端客户时，通常要在 RIPE 数据库里登记。动态地址池里很多小分配有相同用途、相同联系人；逐条创建与维护就会反复抄写同一套信息。提案指出，有的 LIR 干脆不登记子块，有的则制造海量细碎对象。一个好账本不能只能在这两种苦差之间选。

三方关系被新状态重新安排。RIPE-822 的正式文本允许把连续的 IPv4 PA 分配放进一个 AGGREGATED-BY-LIR 对象，条件是这些地址的用途和联系人一致。公开记录展示地址范围与负责联系的人；LIR 在内部掌握每一笔分配，并在 RIPE NCC 审计时提供笔数统计。柜门上写清谁管，柜子里有几件仍得数得明白。

这项设计有意留出 IPv4 与 IPv6 的差别。IPv6 的同名状态要求写 assignment-size，因为那个大小参与后续扩容计算；IPv4 的各笔分配可以大小不同，所以该属性是可选项。反倒是用途和联系人不能乱：不同目的的地址不能因为挨得近，就挤进一条看起来整洁的登记。

争论中也有人担心，合并后的对象只写 LIR 联系人，终端用户会不会从公开记录中淡出。提案原文保留了这项反对意见，也记录了 RIPE NCC 对旧政策的解释：某些由 LIR 联系人负责的分配本就符合现行规则。作者把联系人制度的进一步争论留给另一项政策，把这次修改收束在重复登记与可核对性上。

2024 年 4 月 15 日，提案获通过。那组 2023 年数字是问题发生时的快照，不能拿来当改动后的成绩单。Anderson 的实质贡献是一种第三种记账法：公开记录更简洁，运营者依然对柜子里的每一个地址负责。

原始记录