I believe the RFC states SHALL NOT propigate these out to the global net. SHOULD NOT != SHALL NOT On Tue, Oct 08, 2002 at 10:34:51PM +0100, Stephen J. Wilcox wrote:
On Tue, 8 Oct 2002, Sean Donelan wrote:
On Tue, 8 Oct 2002, Jared Mauch wrote:
install this on all your internal, upstream, downstream interfaces (cisco router) [cef required]:
"ip verify unicast source reachable-via any"
This will drop all packets on the interface that do not have a way to return them in your routing table.
Once again, which providers do this?
If c.root-servers.net provider did this, they wouldn't see any RFC1918 traffic because it would be dropped at their provider's border routers. If c.root-servers.net provider's peer did this, again c.root-servers.net provider wouldn't see the rfc1918 packets.
So why doesn't c.root-servers.net provider or its peers implement this "simple" solution? Its not a rhetorical question. If it was so simple, I assume they would have done it already. PSI wrote one of the original peering agreements that almost everyone else copied. If it was a concern, I imagine PSI could have included the requirement, most of their peers would have signed it 10 years ago. But they didn't.
If you do it on ingress from customers then this is probably a good thing and makes your network compliant to RfC1918.
But you need to accept the internet isnt RFC1918 compliant in the same way that we implement hacks in all kinds of applications to enable compatibility with other non-RFC compliant implementations. You try running an RFC822 compliant mail server as an example and see how many microsoft users complain they cant send email!
Not all IP packets require a return, indeed only TCP requires it. It is quite possible to send data over the internet on UDP or ICMP with RFC1918 source addresses and for their to be no issue. Examples of this might be icmp fragments or UDP syslog which altho shouldnt according to RFC1918 be on these source addresses might be and if you block these on major backbone routes you may break something.
So I guess you may argue block RFC1918 tcp inbound but icmp and udp .. you start to break things, perhaps that is why large providers dont do this on backbone links.
Steve
Does AT&T? Yes Does UUNET? ? Does Cable & Wireless? ? Does Level 3? ? Does Qwest? ? Does Genuity? ? Does Sprint? ?