摘要

  • 在 status: AGGREGATED-BY-LIR 的 inet6num 对象中，assignment-size 表示聚合内单个终端用户分配所采用的前缀长度。
  • 聚合前缀与分配长度之差可以算出理论位置数，却不能得出活跃用户、连接数、在用前缀或已发布路由数。

算术精确，证据边界也要精确

RIPE NCC 给出的例子是 /46 聚合配合 /56 分配长度。多出的十个前缀位形成 1,024 个可能位置。它准确表达这个对象可怎样细分，但没有说明多少位置已经占用。某些位置可能从未分配，可能保留、回收或暂时闲置；同一客户也可能随时间获得多个分配，而一个分配可以服务家庭、企业、地址池或基础设施。

该对象没有会话计数、账单、设备清单、地址使用遥测或在线检测。把理论位置数直接改名为客户数，就是给来源添加了它未观察的事实。

聚合记录为何存在

RIPE-513 引入 AGGREGATED-BY-LIR 与 assignment-size，让 LIR 用一个较不具体的对象登记多个同样大小的 IPv6 终端用户分配。这样可以保留效率核验所需的结构，同时不公开每个终端用户的个人资料。单独的 ASSIGNED 对象则可以记录具体用户与不同联系人。

数据库规则要求分配长度比容器前缀更长，一个对象只能有一个该字段，使用 AGGREGATED-BY-LIR 时必须填写。不同分配长度需要不同对象。这些约束证明登记结构一致，不能证明实际部署。

不要跨越证据层

assignment-size 不识别 BGP 起源、RPKI 授权、route 对象维护权、可达性、流量、接入技术、法律所有权或地理位置。RIPE 模板把维护者、联系人、组织、路由字段与分配长度分开。相关结论必须依赖同时段 BGP 观察、RPKI、IRR、主动测量、运营商或法律证据。

可复核的记录应保存查询前缀、inet6num 键、status、assignment-size、抓取时间与来源。公式 2^(分配长度−聚合前缀长度) 的结果只能标为“该聚合可表示的同尺寸分配位置”，不能标为“活跃用户”。

来源