Re: RFC1918 addresses to permit in for VPN?

I can't see allowing "martian" source addresses into ones network.
Operational reality may well be that there is simply not enough cpu power
at the border with peers (especially NAP connections) to drop such
packets.  Such garbage is usually clipped at the border with ones
customers.
I haven't read everything in this lengthy argument but seems to me that
(without checking) there was a BCP about this? Maybe even written by
Randy?

Implementation at the border with a peer is another matter. On cisco
one would love to use ip verify unicast reverse path but that's not going
to work because of asymmetric routes. An access list will work though.
Or traffic filter on Nortel gear. But then you all knew all this already.

why are you arguing over it? Haven't we had this discussion 3 or 4 times
in the last 3 years?

 On Sun, 31 Dec 2000, John Hawkinson wrote:

> Date: Sun, 31 Dec 2000 21:13:13 -0500
> From: John Hawkinson <jhawk@bbnplanet.com>
> To: Randy Bush <randy@psg.com>
> Cc: nanog@merit.edu
> Subject: Re: RFC1918 addresses to permit in for VPN?
>
>
> > so any isp which lets the outside world see a packet with a source in 1918
> > space is in direct violation of 1918.
> ...
> Nevertheless, the operational reality is that having a traceroute that
> shows RFC1918 addresses is more useful than a traceroute that shows
> * * *, and therefore I suspect most operators will continue to permit
> RFC1918 addresses into their networks as long as a few questionable
> individuals use them to source traffic.
>
> (If they even bother to think about it.)
>
> --jhawk
>