摘要

  • RFC 8206 要求同时配置新旧 ASN 的 BGPsec PE 为二者保有有效密钥，并在相关 eBGP 会话迁移前保留旧密钥；这是一个路径认证条件，不是公司行为的证明。
  • 并存的 ROA、双重签名和 pCount=0 过渡段各自只描述限定的路由机制，不能证明并购、控制权、所有会话已切换、对端同意、报文到达或服务达成。

技术痕迹之所以容易被过度解释，是因为它往往真实而精确。旧密钥确实存在，签名确实可验，两个 ASN 也可能同时得到同一前缀的授权。问题不在这些事实是否为真，而在它们所回答的问题很窄。RFC 8206 讨论 AS 迁移可能发生的情形：提供商可以合并 AS，可能在一段时间内保留旧 ASN，PE 也可能对某个对端继续表现为旧 ASN。这里的“可以”是协议场景，不是对某一公司并购的报道。

该 RFC 反而提醒读者不要把迁移想成一次齐步走。迁移可能很漫长；它不要求所有路由器同时改变，也不要求与每个客户统一协调。因此，遗留 ASN 仍会有实际用途。一把旧密钥可能只是因为某台 PE 面向的 eBGP 邻接仍按旧 ASN 配置。它告诉我们存在一个待维持的本地条件，却不告诉我们有多少邻接尚未迁移、谁批准了变更，或哪一种法律关系导致了这种配置。

源地址验证同样不能跨层作答。RFC 8206 允许在过渡期为同一前缀并存新旧 ASN 的 ROA：新 ASN 可能已需要发起前缀，而旧 ASN 的 PE 仍在发起。ROA 所表达的是用于 RPKI 源地址验证的授权。它不是产权证、工商文件、客户同意书，也不是已完成迁移的回执。两个 ROA 扩大了被允许的源 ASN 集合，并没有把组织关系写入路由系统。

RFC 8205 对 BGPsec 的说明进一步限定了签名含义。RPKI 证书证明 ASN 与 IP 地址空间的分配；发送方以相应私钥签名，接收方无需持有私钥也可以验证。于是，验证成功意味着给定 Secure_Path 在接收方配置的信任与业务关系下满足路径验证条件。它不等同于转发表选择、报文送达、应用可用，当然也不等同于企业控制权。

RFC 8206 的实现边界很清楚。它面对的是一台本地配置了两个 ASN、并且已有 eBGP 关系的 PE。出站时，PE 为两个已配置 ASN 生成签名；旧 ASN 的过渡部分使用 pCount=0。若对端不是 BGPsec，对外重建的 AS_PATH 不显示这一段，而 BGPsec 的 Secure_Path 仍保留它。入站时，若 CE 仍期待旧 ASN，PE 在规定条件下加入该段。这个过程在已知的本地信任边界内解决路径语义；它不会把“我们已完成整合”的命题带给整个互联网。

尤其重要的是，RFC 明确不把向不受协调的客户域发送 pCount=0 当作可行前提。该方案不要求远端 CE 改配置，不要求全球同步，也不要求显示更长的 AS_PATH。这正是它作为最小共同机制的价值：兼容节点可在一个受限接口上互操作。但同样因为如此，它不能证明边界另一侧已经接受、部署或完成任何事情。

“旧密钥必须保留到所有相关 eBGP 会话迁移完毕”也不是一条自动向外报告完成状态的规则。它要求 PE 运营者维护密钥，直到其会话清单满足条件。一条有签名的路由不能证明清单已经清零。要提出这种结论，需要会话库存、PE 配置、密钥有效期、验证器记录和独立的转发或服务测量。远端验证器也只是依据自己的本地信任和商业策略接受或拒绝路径。

这与 Heng Lu 所说的“最小初始规范”相吻合：共享层只规定互操作与安全所需的确定性最小规则；迁移何时进行、谁保管密钥、哪些对端切换、客户是否采用，仍是本地决定。自愿采用只有在兼容参与者实际实现、验证并接受时才在运营上成立。RFC 的发表或密钥的存在都不会替代那条证据链。

因此，应当分层保存：RFC 规则、ROA 授权、密钥状态、已签名路径、验证结果、会话迁移、观测到的报文与服务，以及独立的登记或公司材料。Wesley George 是技术规范的共同作者；这并不使一把为本地过渡保留的旧密钥成为并购公告。

资料来源