RFC 1918 addresses

Joseph C. Pistritto jcp at jcphome.com
Sun Jun 1 03:27:22 UTC 1997

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.   


> From: Paul A Vixie <paul at vix.com>
> To: nanog at 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
> is a mistake.  Using them for otherwise unnumbered serial links would be
> if Cisco had an option to "use loopback address when sending ICMP's" but
> don't.  Traceroute is sending increasing-TTL'd UDP datagrams, and if you
> seeing a source address on an router's ICMP to you it means you
> get that as a normal ICMP too -- meaning not just one due to a diagnostic
> Traceroute.  I think this is an error.
> Exposing an RFC 1918 private address in, say, a "Received:" header in
> is less of a problem, though the spammers who do it are actually better
> 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.

More information about the NANOG mailing list