摘要

  • v6ops 草案第 28 版更明确地处理规则撤回、管理可见性和默认出口的环路风险；默认规则本身在第 27 版已经存在。
  • 具体映射规则对新转换失效后，若配置了 0.0.0.0/0: Pref6(PE)，剩余流量可能转向默认出口；没有该规则则应丢弃并返回 ICMP 或 ICMPv6 错误。
  • 默认规则不能在缺少明确双边协议的情况下跨越管理边界；出口还必须掌握所吸引流量的完整 IPv4 转发视图，避免重新进入该机制。

数据包仍在动，控制权已变

这份草案讨论的是受限的多自治系统 IPv6-only 底层网络，可由一个运营者或若干合作运营者组成。残余 IPv4 流量在边缘转换，经 IPv6 底层转发；数据路径上不依赖逐流状态的转换网关。适用范围不是开放互联网。草案要求事先有双边安排、协调的映射前缀、共同的 ICMP 过滤办法和可信的入口 PE。文件描述这些部署前提，不会替参与者建立信任或签订协议。

设想某个 IPv4 地址块原本有一条指向特定出口的映射规则。运营者撤回它之后，第 28 版建议对新的转换立即移除该规则；对已经在途的数据包，可以设置以秒计的宽限期。这是两个不同的时钟。随后到来的新包要看剩余规则，而不是沿着旧规则惯性前进。如果设置了默认映射，它可能接管没有更具体映射的目的地址。如果没有，草案要求丢包并发出相应的 ICMP 或 ICMPv6 错误。因此，仅有“撤回成功”的操作记录，不能证明后续流量去了哪里。

默认规则能缓解中断，也能集中风险。0.0.0.0/0: Pref6(PE) 把所有未命中更具体映射的 IPv4 流量引向一个出口，可能产生次优路径、容量拥塞和可被劫持的兜底目标。不能把这条规则称作第 28 版的新发明：第 27 版已提出默认出口并提醒其风险。新版更值得注意之处，是把规则一致性、撤回后的行为、边界和环路条件连成一套更明确的运营约束。

协议不能由默认路由代签

草案第 9.4 节指出，没有明确的双边协议，默认映射规则不得越过管理边界传播。这不是一句抽象的“跨域要合作”。协议范围应当能回答：哪一侧可以吸引哪些前缀，哪个 PE 承接剩余流量，规则何时变化，谁能叫停。一项针对特定业务的合作安排，不能自动扩展为兜底接收所有未匹配 IPv4 流量的永久授权。即使包顺利抵达对端，也只是转发事实，不是对端同意的证据。

第 5.2.2 节要求分发机制保持规则的关键字段不被篡改，支持范围控制和过滤、来源认证，并拒绝未经授权的 IPv4 地址块与映射前缀绑定。但具体分发协议扩展不在这份框架内。草案没有给出一个可查询的全球双边授权登记簿，更不能使一方的变更单单方面约束另一方。两边都需要核对当前接受的规则范围。这里的治理问题不是谁拥有全网，而是谁能证明自己只在协议边界内转发。

出口恢复 IPv4 后，记忆消失了

第 9.4 节的环路场景尤其具体。默认出口完成转换后，恢复的 IPv4 包没有“此前已经经过这套框架”的标记。如果出口的最佳 IPv4 路由指向另一参与 PE，该包就可能再次映射、再次穿越底层网络，然后循环。IPv4 TTL 或 IPv6 跳数限制终会耗尽，只是给损害设上限，并非防止错误决策。首次成功穿越不代表后续路径安全。

草案因此要求默认出口对吸引来的流量具备完整 IPv4 转发视图，不能把目的地解析为重新进入框架的路径；默认规则还应受到监测、速率限制和 ACL 约束。真正有用的验收不是单次连通测试，而是按受影响目的地址查看出口的实际最佳路由，验证离开合作域的路径，并在变更后对照规则计数器和错误信号。现有公开草案并没有证明任何运营者已完成这种验收，也没有报告一个可供归因的真实环路事故。

一张有边界的联合变更记录

第 8 节建议记录规则版本或时间戳、比较 MR-DB 摘要、发送变更通知、提供逐规则计数器和管理访问。这些是可观察性的建议，不是现网普遍部署的证明。Daniel Kade 在此提出的编辑性方案，是一份经双方确认的有限撤回与兜底记录：被撤回的前缀及版本，新转换停止使用的时点，在途包宽限期，两边剩余规则快照，双方接受的范围，选中的默认出口，IPv4 转发视图和不回流测试，计数器与 ICMP 结果，负责人与回滚触发条件。它不是 IETF 定义的报文字段、强制表格，也不预设某一方能替另一方批准流量。

这份记录的作用在于区分三件经常被合并的事。撤回旧规则是一件事；确定缺口由默认规则还是丢包处理是第二件事；让另一个管理域承担出口责任是第三件事。流量继续到达终点可以支持第三件事的运营观察，却不能追认前两件事的授权。没有流量的计数器也不能证明防环路，只有带目标的路径核验才能回答是否回流。

IETF Datatracker 在核实时仍将第 28 版列为 v6ops 活跃工作草案，目标状态为 Informational，处于 IESG 的 AD Followup，仍有 DISCUSS 立场未解决。它不是已批准的 RFC、完整分发协议或部署事实；文本也可能继续修改。其当下的价值，是逼迫运营者承认一个精确的边界：默认出口可以保留连通性，却不能自动继承被撤回规则的授权与责任。

来源