摘要

  • RFC 10078 区分了路由器转发表经常被要求同时回答的两个问题：某个前缀从哪里可达，以及接入客户获准使用哪些源地址。
  • 严格 uRPF 会在非对称路径或隐藏前缀场景丢弃合法数据包；宽松 uRPF 去掉入接口检查，却可能放过源地址恰好出现在本地转发表中的伪造包。

客户从一个获准使用的地址发出数据包。路由器查转发表，发现该前缀指向别处，或者根本没有记录，于是丢包。路由器确实回答了一个问题，只是答错了题。

这正是 RFC 10078 的缺口。IETF 于 2026 年 10 月发布这份信息类 RFC，讨论一个自治系统内部的源地址验证（SAV）：在面向非邻接 AS 的主机或客户网络的外部接口上检查源地址。制造这个问题的客户不必拥有 ASN；它可能使用服务商分配的地址段，也可能自带地址空间。

严格的单播反向路径转发（uRPF）会检查本地转发信息库（FIB）是否有覆盖源地址的路由，以及该路由指向的接口是否就是数据包进入的接口。这个检查很整齐，网络路径却未必整齐。多宿客户可能从路由器 1 发流量，而服务商路由系统认为该源前缀的回程应经过路由器 2。严格 uRPF 把“接口不合预期”当作数据包可疑的证据。RFC 10078 的例子给出结果：合法客户流量被丢弃。

宽松模式取消了入接口比较。只要本地 FIB 中存在覆盖该源地址的前缀，数据包就能通过。它救回部分非对称流量，却削弱了另一处防线：攻击者可以伪造一个源地址，而这个前缀碰巧存在于转发表里。一种设置把回程路径当成使用许可；另一种则把一般意义的可达性当成许可。

隐藏前缀让修补更棘手。主机或客户可以合法地从一个服务商内部路由协议看不到的地址发包。RFC 举例说明了直接服务器返回（DSR）：请求抵达某个任播服务节点，另一个边缘服务器则用该服务地址作为源地址直接回复。客户地址未通告进服务商内部网络，也会造成同样的错位。前缀不在 FIB 里时，严格和宽松 uRPF 都可能丢包。访问控制列表可以写清哪些前缀获准使用，但必须有人知道授权何时改变，并及时更新规则。

RFC 为未来机制列出五项要求：提高验证准确性；自动收集并更新 SAV 信息；允许在部分合格接口上逐步部署；通过协议分发信息时不损害路由收敛或快速重路由；使用经过认证或可信的信息。这些要求指向缺失的记录：一份路由器可以信任、也能持续更新的源地址使用授权。转发表的职责是表达可达性。把它兼作客户许可簿，只有在两者发生冲突前才显得省事。

RFC 10078 没有定义这份授权记录、分发协议或完整机制。它给出问题和要求，不是部署手册。运营商现在能做的测试很具体：分别从非对称路径和隐藏前缀发送合法数据包，再发送使用 FIB 中已有和没有前缀的伪造包。记录是哪条规则做出判断、谁提供授权、更新如何抵达边缘，以及路由变化时会发生什么。

来源