摘要

  • HCGA 草案扩展 RFC 3972，把运营方聚合前缀与 /64 边界之间的 IPv6 子网位也从公钥和修饰量导出，供多租户工作负载使用。
  • 在 /48 聚合下这部分只有 16 位。另一把密钥约经 2^16 次尝试即可得到同一 /64；独占准入记录和源地址约束因此决定这个子网到底归谁。

密码学给地址盖章，没法替运营方排队。HCGA 草案提出让工作负载的 IPv6 子网与公钥发生可核验关系：看见 /64，就能沿着记录追溯一把密钥。草案自己的安全章节马上补上一句更重要的话：两把不同密钥可以撞到同一个子网，先获准的那把必须由外部系统记下。

RFC 3972 的密码学生成地址只把低位接口标识与公钥关联，/64 前缀由网络提供。新方案把运营方控制的聚合前缀与 /64 之间的子网位也导出，计算还用到前缀修饰量。核验者若拥有公钥、修饰量和碰撞计数，就能重算地址关系。谁负责把这些参数保存给日后的核验者，草案交给更大的部署架构。

数字不能看错。在常见的 /48 聚合示例中，供子网导出的只有 16 位。草案称另一把密钥或另一组修饰量约试 2^16 次就能匹配同一 /64。这指的是子网位碰撞，完整 128 位地址与私钥并未因此被破解；接口标识另有更大的哈希边界。单看 /64，不能证明独一无二的密钥身份。

草案要求周边架构在地址生成时记录哪把公钥及前缀修饰量获准占用该 /64，并保证独占。要把数据包归到那把密钥，还需对应私钥签名，或者网络层阻止别的节点冒用源地址。离开本地链路的调查者更依赖当时保存的参数。丢掉那份账本，地址再漂亮也不能重建原本声称的工作负载身份。

路由的授权又在另一层。运营方通过 BGP 发布聚合前缀，并以 RPKI ROA覆盖它；各工作负载的 /64 路由只在内部存在。聚合 ROA 证明的是大前缀的起源授权，不能替内部 /64 选出获准密钥。那项更细的任命属于运营方的准入、留档和源地址执行。

一旦长期保留这个任命，隐私也会改变。草案指出接口标识轮换时 /64 仍保持稳定，观察者可以把多次活动串起来；RFC 8981 的临时地址追求不同的隐私效果。地址核验也不显示密钥究竟受硬件保护还是仅在软件中生成。RFC 9334提供远程证明框架，具体证明仍要另行获得。

Datatracker将它列为 I-D Exists 的个人 Standards Track 草案。最有用的测试是生成两把撞上同一测试 /64 的密钥，拒绝第二把准入，再让远端核验者凭保存的参数和源地址证据重建第一把的资格。地址负责查账，账本负责选人。