What is uRPF?
uRPF blocks spoofed source addresses by checking each packet's source against the router's FIB. We explain strict, loose and feasible-path modes.
Last updated:
uRPF (unicast Reverse Path Forwarding) is a filtering mechanism in which a router checks the source address of an incoming packet against its own forwarding table (FIB) and drops the packet if the return path to that source does not meet a defined condition. It is a basic anti-spoofing technique for IP addresses. RFC 3704 (BCP 84) describes it and extends the ingress-filtering guidance of RFC 2827 (BCP 38).
How uRPF works
Normal routing makes decisions based on a packet's destination address. uRPF inverts the question and, for the source address, checks whether a return route exists and through which interface the router would send traffic back to that source. The mechanism uses the same FIB the router already maintains, so it runs in hardware at line rate. It also avoids the need for separate ACLs that you would have to update by hand on every routing change.
Strict mode vs loose mode
uRPF operates in two main modes that differ in how strictly they verify the source. The right mode depends on whether routing on a given interface is symmetric.
- Strict mode: the packet is accepted only if the best return route to the source address points out exactly the interface on which the packet arrived. It gives the strongest protection, but it breaks with asymmetric routing and multihoming.
- Loose mode: the packet is accepted if any route to the source address exists in the FIB other than a null/discard route, regardless of the ingress interface. It mainly drops traffic from unroutable addresses and bogons.
- Feasible-path mode: an extension of strict mode that also accepts alternate routes, such as a second-best BGP path, so it mitigates the asymmetry problem.
- Loose with allow-default disabled: a variant that additionally rejects traffic matching only the default route (0.0.0.0/0). This improves effectiveness at the edge facing the rest of the Internet.
uRPF and anti-spoofing
Source-address spoofing underpins many attacks, especially volumetric reflection and amplification DDoS, where an attacker forges the victim's address. uRPF deployed on customer-facing interfaces (strict mode) stops such traffic at the source, before it leaves the operator's network. On links to other networks, where routing is often asymmetric, loose or feasible-path mode is typically used so that legitimate traffic is not dropped. uRPF is one of the pillars of the MANRS initiative on traffic hygiene in operator networks.
uRPF in the AS202520 SkyPass network
At AS202520 SkyPass we use uRPF as part of anti-spoofing network hygiene aligned with BCP 38 and MANRS. On IP transit customer ports we enforce strict mode, so traffic leaving our network does not carry forged source addresses. The mechanism complements our DDoS protection and route filtering (RPKI, IRR) on BGP sessions in our Warsaw and Wrocław PoPs and at the THINX, TPIX, WRIX and 1-IX exchanges. If you take transit or peering from us, uRPF at the edge reduces the risk that your address space is abused for spoofing.
Frequently asked questions
What is the difference between strict and loose uRPF?
Strict mode requires the best return route to the source address to point out the same interface the packet arrived on. Loose mode only checks whether any route to the source exists in the FIB, regardless of interface, which suits links with asymmetric routing.
Does uRPF break with multihoming and asymmetric routing?
Strict mode can, because return traffic may leave on a different link than it arrived. In those places you use loose mode or the feasible-path variant, which also accepts alternate routes.
Does uRPF replace BCP 38?
No, it is one way to implement BCP 38 (RFC 2827). uRPF (described in RFC 3704) automates ingress filtering based on the FIB, but in some topologies you still complement it with static ACLs.
Where should uRPF be enabled?
Strict mode works best on customer and access interfaces where routing is symmetric and the assigned address space is known. On peering and transit links you typically use loose or feasible-path mode.