[100811] in North American Network Operators' Group
Re: General question on rfc1918
daemon@ATHENA.MIT.EDU (Robert Bonomi)
Tue Nov 13 10:37:45 2007
Date: Tue, 13 Nov 2007 09:35:34 -0600 (CST)
From: Robert Bonomi <bonomi@mail.r-bonomi.com>
To: nanog@merit.edu
Errors-To: owner-nanog@merit.edu
> 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.