In the referenced message, Iljitsch van Beijnum said:
So what is the collective wisdom on the NANOG list? Is uRPF on peering interfaces a viable option and if it breaks esoteric customer configurations, too bad; or is it something that should be discouraged because it breaks legitimate customer needs?
I believe that every little bit helps. If some amount of collateral damage for odd configs is too much for you, you can still do the below. This should only break the most egregiously broken setups (sources in space which is entirely unreachable.) The most permissive configuration: loose-check RPF (allow if any path available) combined with: interface acls (in and outbound) deny src or dst in rfc1918 deny src or dst in class e !supposedly, some mcast apps set both src and dst to group !so permit permit src _and_ dst in class d !nothing else should have source in class d deny src in class d the interface acls aren't needed assuming you have no active routes for RFC1918, class d, or class e. IMHO, they are still a good idea anyways, esp. on _outbound_ to reduce crap sent to others. As with all things, every little bit helps. Filter what you can, contribute to the overall improvement of the net. Become a White Hat respected by all, or do nothing and become a Black Hat reviled by millions of small children.