摘要

  • RFC 8805 定义了由网络运营者自行发布的、按前缀记录的粗粒度位置数据；使用方可以只把它当作提示。
  • RFC 9632 能把已签名文件与所覆盖地址空间的管理权联系起来，但不能认证现实中的物理位置。
  • 可靠的修正回执应把签名版本与抓取、启用、重叠处理及最终服务观察连在一起。

签名通过，地图仍然错误

运营者把一个前缀迁到另一座城市，更新 geofeed，并附上可选的 RPKI 验证材料。签名校验成功。几天后，视频目录、反欺诈判断或 CDN 选择仍把客户放在旧城市。

这不表示签名无用。它证明的是另一个事实。RFC 9632 可验证签名者对覆盖地址资源的权威，并确认规范化文件字节未被改变。HTTPS 能保护抓取端点，但 WebPKI 不能证明 IP 地址空间的分配权。

RFC 8805 定义的是前缀、国家、地区和城市组成的简单 CSV，精度本来就是粗粒度。使用方可以把它视作提示，也可以优先采用其他来源；规范还把发布者权威和位置准确性明确分开。密码学检查无法观察路由器、用户或服务实际位于哪里。

RFC 9632 通过 RPSL inetnum: 对象的 geofeed: 属性发现文件。之后，何时抓取、如何选择最具体前缀、是否合并其他数据以及何时启用新版本，仍由使用方决定。规范不鼓励频繁实时查询，因此缓存年龄和数据集版本都是证据链的一部分。

调查应沿一个具体前缀核对 feed 哈希、签名与证书覆盖、发现对象、抓取时间、解析结果、重叠规则、使用方数据集版本、实际启用位置及外部探测。“签名有效”只关闭身份与完整性这一步。

来源