摘要

  • RFC 9977 让运营者可以发布端站前缀长度；在 CGN 或代理场景中，还可声明每个前缀长度后的端站数。
  • RPKI 签名可验证文件与受覆盖地址资源之间的关系，却不能把“4,000”变成真实用户数或本地限流规则。

“4,000”出自 RFC 9977 的示例：一个使用 CGN 的 /24 可以如此表示其端站数。该例解释 CSV 的第三列，并不报告某个真实网络。标准解决的是分组难题：服务商仅按较大 IPv6 前缀限流，可能将互不相干的用户放进同一桶；按过细前缀又会迅速膨胀控制表。它提供一项可发现的输入，不规定服务商应当如何处置输入。

一行数据的边界

非注释行依次写入地址前缀、端站前缀长度，以及适用于 CGN/代理的端站数量。后两列同时留空，表示发布者不披露该更具体范围的信息；消费者必须丢弃来自覆盖前缀的推断。读取者还必须采用最长前缀匹配，跳过重复或错误条目。这些规则限定了文件的解释范围，不能为其中的数字背书。

文件可经 RPSL 的 prefixlen: 属性发现，迁移期间也可用大小写敏感的 remarks: Prefixlen。HTTPS 保护获取过程；RFC 特意区分它与对 IP 地址资源归属的 RPKI 认证。

签名证明什么

可选认证要求签名证书覆盖文件中的全部前缀，并验证证书链、清单、CMS 签名、内容类型和覆盖关系。RFC 6481 所说的资源证书，是把公钥与列明的 IP 块或 ASN 绑定；持有者可通过签名证明对这些列明资源的持有关系。

这并不是端站普查、请求身份认证、数据时效保证或服务资格证明。RFC 9977 的安全章节直接提出反例：恶意运营者可能虚报 CGN，以绕过正当的封锁或限流；极细粒度或极大文件也能压垮消费者。于是，签名有效与声明可信是两项需要并列记录的事实，而不是一项结论。

仍由本地承担的决定

标准只说服务商可以据 CGN 信号调整限流。服务商仍须判断文件是否新鲜、字段是否与行为信号相符、请求风险为何、规则是否适用、动作能否回滚及结果如何观察。前缀文件可以启动复核，不能替代复核。按照 Heng Lu 的原则，共同格式应保持为共同格式；承担服务后果的一方不能把决定权交给 CSV 的发布者。