|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical 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 <[email protected]> > To: Randy Bush <[email protected]> > Cc: [email protected] > 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 >
|