摘要

  • 加密生成地址（CGA）把公钥与 IPv6 接口标识符绑定；签名可证明发送方掌握相应私钥，却不能证明真实身份或路由器权限。
  • 主机要验证路由器，仍须将证书链追溯到本地已配置的信任锚。SEND 没有消除这个起点。

主机刚接入 IPv6 链路时，通常还不能把周围环境当成可信网络。它需要解析邻居的链路层地址、发现默认路由器，并持续判断邻居是否可达。RFC 4861 定义了这些邻居发现功能。原始设计提到用 IPsec 保护报文，但没有给出细致的使用办法；RFC 3971 还指出，为大量潜在对端手工配置安全关联，对多数场景并不现实。SEND 试图解决的是这个引导难题，而非所有网络信任问题。换言之，难点不只在算法能否签名，还在此前尚未互相认识的节点如何获得可验证的保护关系。若每一组潜在邻居都要先由管理员逐一建立安全关联，链路发现本身就被昂贵的前置配置挡住了。

它没有让一个签名同时代表“地址属于谁”和“谁有权当路由器”。对普通节点，SEND 可采用加密生成地址。RFC 3972 用公钥及辅助参数计算接口标识符；接收方重新计算哈希，再验证相应私钥生成的签名。因此这项检查无需证书机构，就能验证地址与公钥之间的绑定。

但“能证明密钥”不等于“证明身份”。RFC 3972 明确指出，攻击者可以在任意子网前缀下创建自己的新 CGA；它不能仅凭自己的密钥，冒充另一条既有 CGA 的签名者。这个机制不说明谁分配了前缀，也不授予路由通告权，更不把公钥持有人映射成现实世界中的个人或组织。

CGA 也把计算成本放进了参数选择。RFC 3972 说明，安全参数大于零时，生成过程要反复寻找满足哈希条件的候选值，工作量随参数增长；规范同时允许实现使用 Sec=0。于是“地址由密钥生成”并不意味着所有强度选择都没有代价。它是协议设计中的一个明确取舍，不是对任何现行设备性能的测量。

验证路由器要走另一条路径。主机需要一条路由器证书链，并且链尾必须落在主机早已配置的信任锚上。SEND 的授权委派发现消息可以帮助取得证书路径，却无法让一枚未知根证书自动变成可信根。所以，“无证书基础设施”只适用于地址—密钥绑定这一半；路由器授权仍有明确的配置责任。

后续标准逐步刻画这条边界。RFC 6494 为 SEND 规定基于资源证书的证书配置文件；RFC 6495 补充 Subject Key Identifier 的名称类型。RFC 6980 则限制特定邻居发现与 SEND 报文使用 IPv6 分片，因为分片头可能绕过某些监测或过滤机制。这些变化记录的是证书和报文处理规则的演进，并不能说明 SEND 的部署规模或某个网络的安全结果。

RFC 3971 的历史价值，在于把证据和权限放回各自的位置：密钥签名对应地址声明，预设信任锚对应路由器授权。两者被混成一句“密码学证明了所有权”，结论就超过了协议实际能证明的范围。