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.
-jcp-
----------
> 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
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.
More information about the NANOG
mailing list