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
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
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- ---------- they 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.