...

...

It was possible to implement BCP38 before the router vendors came up with uRPF.

Further, uRPF is frequently a very inefficient means of implementing BCP 38. Consider that you're going to either compare the source address against a table of 200,000 routes or against a handful of prefixes that you've statically configured in an ACL.

Isn't that only a problem if you want to run a loose mode uRPF? Given that loose mode uRPF isn't very useful in most places where you'd like to do ingress filtering, this doesn't seem like a big issue..

Loose mode is a RTBH Reaction tool - not BCP 38. Don't use a screw driver to hammer a nail.

BTW, I still keep wondering why Cisco hasn't implemented something like Juniper's feasible-path strict uRPF. Works quite well with multihomed and asymmetric routing as well -- no need to fiddle with communities, BGP weights etc. to ensure symmetry.

Wow - I'm going to need to dust off the tutorial materials on how uRPF and using the FIB as a policy enforcement tool works. Does uRPF need to scan through the entire FIB? Saying this is saying routers look through the entire FIB table to find the next hop? What ever happened to TRIE techniques? uRPF's look up is at the same speed as the forwarding look up. In fact, in many implementations, the "forwarding lookup" gets the source and destination address values from the FIB. Now, are there other ways of doing BCP38 - yes lots: - ACLs - Radius loaded ACLs - uRPF Strict-Feasible-VRF modes - IP Source Verify - DHCP Lease Query - NAT on the home CPE Why hasn't Cisco done uRPF Feasible path? Cause until recently, our CEF structures would not allow for feasible/alternate paths. If the FIB is your policy table, then _what_ you are limited to the capabilities of that FIB when using it to police the packet. Cisco has that now, so "feasible path" is just a matter of time to work through the coding queues. What I'm shaking my head over with this whole dialog is the 1990's thinking. BCP38 is out of date. Anyone who works, mitigates, analysis, and studies attack vectors on network systems know that checking the IP source address is one of many "Anti-Spoof" checks you need to do on the packet. With Ethernet and Cable, you need to do a MAC check. With all mediums you need to check the Prec/DSCP value (porn at Prec 6 does wonders for the routing protocols when there is congestion in the path). Then there is TTL values, Fragments, and other values which need to be policed on the edge. This is why uRPF - while helpful - is not the primary BCP38 tool people should be considering on the edge.