摘要

  • IESG 于 2026 年 9 月 17 日启动 SAVNET 跨域源地址验证问题陈述第 21 版的最后征求意见，截止 10 月 1 日。文件拟以信息类 RFC 发布，目前仍是互联网草案。
  • 草案同时分析合法报文被错误拦截，以及伪造源地址被错误放行。第六节指出，使用 SAV 表的自治系统边界路由器不能天然识别自己的这两类判错。
  • 下游网络或对等网络的反馈可能是调查起点。本文建议建立可追溯的投诉与规则修正记录；这不是 IETF 已规定的跨运营商接口。

过滤动作看似确定：报文从哪条接口进来、源地址是否落在允许范围，本地表项立即给出答案。但“按表执行正确”与“表中的判断符合真实网络”并非一回事。SAVNET 工作组提交 IESG 的问题陈述把这道裂缝写得很清楚。它没有宣布一种已经上线的新过滤协议，而是在问既有方法何处会把正常流量当作伪造流量，以及何处会放过真正的伪造来源。

草案列举的误拦情形并不要求有人配置失误。某个前缀可以只向部分网络传播；也可能用作源地址或直接服务器返回的任播地址，而不以预期方式出现在过滤者可见的 BGP 路由中。路由可见性不是合法源地址的完整名册。倘若过滤表把“看不见”直接解释为“不该出现”，正常报文就可能被丢弃。反过来，为避免误拦而放宽报文进入方向的约束，又可能扩大伪造地址通过的空间。

局部部署还有边界。一个网络即使在自身对外接口执行检查，也不能因此宣称客户锥内部的源地址伪造已经彻底消失；其他网络是否部署及如何部署同样影响结果。草案要求未来方案在不假设普遍采用的前提下让早期采用者获益，同时提高判断精度、降低表项更新的人工作业、保护可能新增的 SAV 专用信息并较快收敛。这是待满足的要求清单，不是现实网络的通过率报告。

真正值得治理部门注意的是第六节的查错描述。边界路由器只能记录自己依据什么表放行或丢弃，不能从这一动作自动推知其是否误拦、误放。受影响的下游或对等运营者可能先看到连通性异常，再把线索交回执行过滤的一侧。投诉本身不是误拦的证明；本地丢包计数也不是过滤正确的证明。调查必须把外部观察与入口接口、相邻关系、当时的 SAV 表版本和生成表项的信息对上。

因此，Daniel Kade 提议为运营者保留一张范围明确的调查回执：谁在何时报告了哪类流量与源前缀、过滤决策发生在哪条接口、对应的输入与表项版本是什么、由谁判断是否修正规则，以及修改后怎样确认问题结束。涉及报文或商业拓扑的材料应尽量少取，并只交给有必要参与排查的人。这是本文的操作建议，不是草案第 21 版制定的强制格式，更不能把每条外部投诉自动视为过滤错误。

时间线也不能混淆。第 21 版草案本身标注 7 月 19 日；9 月的新事实是 IESG 开始最后征求意见，意见截止日为 10 月 1 日。信息类问题陈述尚未成为正式 RFC，也未证明任何厂商方案已经部署。它揭示的核心问题更具体：做出源地址决策的一方与最早知道后果的一方可能不同。若缺少把证据送回决策者的办法，过滤器越坚定地执行错误表项，纠错越难。

来源