From owner-nanog@merit.edu Tue Nov 13 09:12:04 2007
Cc: "nanog@merit.edu" <nanog@merit.edu>
From: Joe Abley <jabley@ca.afilias.info>
To: Drew Weaver <drew.weaver@thenap.com>
Subject: Re: General question on rfc1918
Date: Tue, 13 Nov 2007 10:10:26 -0500
> Hi there, I just had a real quick question. I hope this is
> found to be on topic.
>
> Is it to be expected to see rfc1918 src'd packets coming from
> transit carriers?
You should not send packets with RFC1918 source or destination
addresses to the Internet. Everybody should follow this advice. If
everybody did follow that advice, you wouldn't see the packets you are
seeing.
Really? What do you do if a 'network internal' device -- a legitimate
use of RFC1918 addresses -- discovers 'host/network unreachable' for an
external-origin packet transitinng that device? <evil grin>
Your comment _is_ "generally correct", but there are some significant
'corner cases' that do complicate life.
Packets that could conceivably generate a reply/response and have an
RFC 1918 address (source -or- dest) should be ingress *and* egress
filtered -- unless there is specific agreement with the adjacent network
with regard to coordinated use of specific portions of that space.
Packets which are strictly error/status reporting -- e.g. IMP 'unreachable',
'ttl exceeded', 'redirect', etc. -- should *NOT* be filtered at network
boundaries _solely_ because of an RFC1918 source address.
Hi there, I just had a real quick question. I hope this is
found to be on topic.
Is it to be expected to see rfc1918 src'd packets coming from
transit carriers?
You should not send packets with RFC1918 source or destination
addresses to the Internet. Everybody should follow this advice. If
everybody did follow that advice, you wouldn't see the packets you are
seeing.
Really? What do you do if a 'network internal' device -- a legitimate
use of RFC1918 addresses -- discovers 'host/network unreachable' for an
external-origin packet transitinng that device? <evil grin>
You drop the packet at your border before it is sent out to the Internet.
This is why numbering interfaces in the data path of non-internal traffic is a bad idea.
Packets which are strictly error/status reporting -- e.g. IMP 'unreachable',
'ttl exceeded', 'redirect', etc. -- should *NOT* be filtered at network
boundaries _solely_ because of an RFC1918 source address.
I respectfully disagree.
Joe
Joe Abley (jabley) writes:
You drop the packet at your border before it is sent out to the Internet.
This is why numbering interfaces in the data path of non-internal traffic is
a bad idea.
Unfortunately many providers have the bad habit of using RFC1918
for interconnect, on the basis that a) it saves IPs b) it makes
the interconnect "not vulnerable" [1].
> Packets which are strictly error/status reporting -- e.g. IMP
> 'unreachable',
> 'ttl exceeded', 'redirect', etc. -- should *NOT* be filtered at network
> boundaries _solely_ because of an RFC1918 source address.
I respectfully disagree.
Same here, and even if egress filtering didn't catch it, many inbound
filters will.
[1] I'v also heard of ISPs having an entire /16 of routable addresses
for their interconnect, but they just don't advertise to peers.