BCP38 making it work, solving problems
Christopher L. Morrow
christopher.morrow at mci.com
Tue Oct 12 03:16:07 UTC 2004
On Tue, 12 Oct 2004, Suresh Ramasubramanian wrote:
> Daniel Senie wrote:
> > One of your arguments presented was that corporate customers weren't
> > asking for unicast RPF, and I responded that corporate customers are not
> > in need of automated mechanisms to implement BCP38, since in most cases
> > their networks are EDGE networks, and it's quite simple to filter your
> > egress points to ensure you don't send out any spoofed packets.
> There is, of course, the issue of multihomed networks, or networks that
> have satellite connectivity etc emitting spoofed source packets.
a common occurance we've seen is a customer of a customer NOT announcing
, nor planning on announcing, their routes to their upstream#1 which they
use ONLY for outbound traffic (cheap transit for instance, and perhaps
only for some portions of their total sources) though they announce to
upstreams#2-N the proper sources to gather the return traffic. These
things make uRPF 'difficult'.
As to the entire conversation I think more folks will implement BCP38, or
parts atleast, as they replace gear which is not capable of dealing with
parts of the implementation of BCP38. Hopefully new gear is being
tested/certified/bought that can do wirespeed filtering on all interfaces.
More information about the NANOG