Re: General question on rfc1918
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
On 13-Nov-2007, at 10:08, Drew Weaver wrote:
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.
On 13-Nov-2007, at 10:35, Robert Bonomi wrote:
On 13-Nov-2007, at 10:08, Drew Weaver wrote:
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.
participants (3)
-
Joe Abley -
Phil Regnauld -
Robert Bonomi