Re: RFC 1918 addresses

["Joseph C. Pistritto" <jcp () jcphome com>]

While this is technically correct, actually changing the addresses in ICMP
payloads violates my first rule of debugging complex systems:

        Diagnostics should be a simple as possible and never be altered by any
non-diagnostic system.

(Which begs the question of should people be using these addresses locally
at all.  Which is kind of metaphysical except that it *does* preserve
address space, which is a universal good.  Some people do this for security
reasons too, although it's at best only moderately effective security
measure and could produce a false sense of security inside such an
addressing realm.)

I agree that ever having a source or destination IP that's RFC1918 outside
the domain is a very bad thing.   

        -jcp-


----------
> From: Paul A Vixie <paul () vix com>
> To: nanog () merit edu
> Subject: RFC 1918 addresses
> Date: Saturday, May 31, 1997 4:38 PM
>
> I think that any exposure of these addresses outside their addressing
realm
> is a mistake.  Using them for otherwise unnumbered serial links would be
fine
> if Cisco had an option to "use loopback address when sending ICMP's" but
they
> don't.  Traceroute is sending increasing-TTL'd UDP datagrams, and if you
are
> seeing a 10.0.0.2 source address on an router's ICMP to you it means you
would
> get that as a normal ICMP too -- meaning not just one due to a diagnostic
like
> Traceroute.  I think this is an error.
>
> Exposing an RFC 1918 private address in, say, a "Received:" header in
e-mail
> is less of a problem, though the spammers who do it are actually better
able
> to cover their origins, there's no way to prevent it and no normal damage

> from doing it.
>
> No IP datagram with an RFC 1918 address in the protocol headers should be
> allowed outside a private addressing realm.  This means not the source
> address, not the destination address, and not the encapsulated addresses
> inside an ICMP payload.