Summary

  • RFC 10078 separates two facts a router's forwarding table is often asked to supply: where a prefix is reachable and which source addresses a connected customer may use.
  • Strict uRPF can discard legitimate packets on asymmetric paths or from hidden prefixes. Loose uRPF avoids the interface test but can admit spoofed sources found anywhere in the local table.

A customer sends a packet from an address it is entitled to use. The router checks its forwarding table, sees that the prefix points somewhere else—or nowhere—and drops the packet. The router has answered a real question. It has answered the wrong one.

That is the gap in RFC 10078, an Informational RFC published by the IETF in October 2026. Its subject is source address validation (SAV) inside one autonomous system, at interfaces facing hosts or customer networks that are not neighboring ASes. A customer does not need its own ASN to create the problem. It may use an address block assigned by the provider or bring its own.

The familiar strict form of unicast Reverse Path Forwarding (uRPF) asks whether the local forwarding information base (FIB) has a route covering the packet's source address and whether that route points back through the interface where the packet arrived. The check is tidy; the network may not be. A multihomed customer can send traffic through Router 1 while the provider's routing system expects return traffic for that source prefix through Router 2. Strict uRPF treats the unexpected interface as evidence against the packet. RFC 10078's example shows the result: legitimate customer traffic is dropped.

The loose form removes the interface comparison. If any covering prefix appears in the local FIB, the packet passes. That rescues some asymmetric traffic, but weakens the test in a different way: a spoofed packet can use a source prefix that happens to be present in the table. One setting confuses the return path with permission; the other treats general reachability as enough.

Hidden prefixes make the confusion harder to patch. A host or customer can legitimately send from an address the provider's internal routing protocol never sees. The RFC points to Direct Server Return (DSR): a request reaches one anycast service location, while another edge server sends the reply using the service address as its source. Customer space not advertised inside the provider's network can create the same mismatch. If the prefix is absent from the FIB, both strict and loose uRPF can drop the packet.

An access-control list can name the permitted prefixes, but someone must know when the customer's authorization changes and update the rule.

The document asks future mechanisms to do five jobs: validate more accurately; collect and update SAV information automatically; work incrementally on a subset of eligible interfaces; avoid harming routing convergence or fast reroute when information is distributed; and use authenticated or trusted information. Those requirements point to the missing record: a source-use authorization the enforcement router can trust and keep current. The route table was built to describe reachability. Making it double as a customer permission ledger is convenient only until the two disagree.

RFC 10078 does not define that record, a protocol to distribute it, or a finished mechanism. It sets a problem statement and requirements, not a deployment recipe. The immediate operator test is therefore concrete: send authorized packets from an asymmetric path and a hidden prefix, then send spoofed packets using prefixes that are and are not in the FIB. Record which rule decides each case, who supplied the authorization, how updates reach the edge, and what happens during a route change.

Sources