摘要

  • 7 月 21 日的个人草案提出“特定本地地址表”（SLAT）：同一个成员保留一组物理 MAC 和 IPv6 身份，别的客户却可以分别用各自的 IPv4 本地别名作下一跳。
  • 路由服务器向旧设备发路由时，按接收方那一列改写 BGP NEXT_HOP；交换中心的 ARP/ND 代理必须把这个别名解析到正确成员。两套记录只要分叉，BGP 有路不等于包能送达。
  • RFC 7947原本要求路由服务器原样传递 NEXT_HOP。草案拟设一项明确例外；绕开服务器的双边互联需要公开且及时更新的地址表，或自行完成转换。

在一个对等互联局域网上，两家网络收到同一条 IPv4 路由。一家能接收 IPv6 下一跳，另一家只能接收 IPv4 下一跳。目的前缀没有变化，数据包仍要抵达最初通告它的那个成员。变化的是每位接收者在 BGP 里看到的地址，以及它向局域网询问“这个地址对应谁”时得到的回答。过去给每个成员分一份公有 IPv4 地址，最省心也最耗地址；草案把这份开销转成每个客户自己的本地映射。

RFC 8950允许在双方协商相应能力后，给 IPv4 路由配 IPv6 下一跳。但协商不能让一台旧路由器凭空学会新编码。转换草案把客户分成三类：Legacy 只能用 IPv4 下一跳；Supporting 两种都能用；Unnumbered 只用 IPv6 下一跳，不支持 IPv4 下一跳。路由服务器因此成为三种视角的交汇处。

账本先从物理身份写起。交换中心为每个成员登记唯一的 MAC、IPv6 链路本地地址和 IPv6 全球单播地址，组成 LAT。对于每一个 Legacy 或 Supporting 客户，交换中心与它商定一段客户专属的本地 IPv4 前缀，再为 LAT 加一列地址，形成 SLAT。草案示例里，同一个物理邻居在甲客户眼中可以是 10.0.0.10，在乙客户眼中则是 192.0.2.10。这不是两台设备，只是两位读者手里的地址词典不同。

路由服务器必须在入、出两个方向查对词典。收到带 IPv4 NEXT_HOP 的 IPv4 路由，它先把下一跳改成通告者在 SLAT 中登记的 IPv6 地址。把路由送给 Legacy 客户时，再改成通告者在该接收者专属列里的 IPv4 别名。送给 Unnumbered 客户时不得改写；送给 Supporting 客户时原则上也保留。下一跳在 SLAT 中没有归属，路由就不能继续传播。这张表由此不只是资产清单，还决定哪条可达性声明能被转发给谁。

另一半工作发生在交换局域网上。交换中心监听 ARP 和邻居发现，按该客户适用的 SLAT 列自己回答查询；按草案的方案，客户之间的这些邻居报文也不应直接穿透交换网络。若路由服务器通告别名 A，代理却把 A 解析到另一名成员的 MAC，BGP 表可以一片绿色，包仍去了错误机器。判断某次部署是否可靠，缺的是每类接收方对应的 BGP 通告、SLAT 行、ARP/ND 应答、FIB 解析和实际包路径的同一组记录；成员地址变化后还要再跑一次。

这一步改动了路由服务器的传统边界。RFC 7947 第 2.2.1 节要求服务器原样传 NEXT_HOP，因为它不承载客户间的数据流。新草案明确要把这条规则在转换场景下让开。SLAT 主方案中，服务器依然不是包的中转站，却成了“客户拿什么地址找邻居”的记录管理者。交换中心的 ARP/ND 代理必须读同一本账。草案因此建议地址管理只有一个权威来源，并定期自动核对不同形式的下一跳是否解析到同一个成员。

迁移可以分步。先部署 ARP/ND 监听，再让能处理 IPv4 路由配 IPv6 下一跳的新服务器与旧服务器并行。最初各客户的 SLAT 列可以照搬现有公有 IPv4 分配；地址池紧张时再逐个改进本地前缀，包括私有 IPv4。并行期提供回退空间，也使两套地址视角同时在场。回退方案必须包含哪条通告、哪次解析会切回旧视角。

双边会话暴露了中央翻译的边界。两个成员直接交换路由，路由服务器碰不到它们的 NEXT_HOP。草案要求交换中心公开并更新 SLAT，让双方自己转换；还建议 Looking Glass 同时展示原始 IPv4 下一跳、实际 IPv6 下一跳，以及指定接收者的出口别名。只看其中一个值，容易把本地别名错当成成员的普遍身份。草案另给出一台代理机器真正跨两个域转发的变体；那台机器承担的是另一套转发风险。

这不是免费省下一批地址，而是把地址库存变成维护合同。交换中心能撤掉公有 IPv4，条件是按接收者发出的 BGP 名称和局域网上的解析回答始终指向同一个邻居。账可以写得漂亮，包会逐条查账。

路由服务器下一跳转换草案第 02 版 · RFC 7947 · RFC 8950 · RFC 9161