|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: RFC 1918 addresses
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 <[email protected]> > To: [email protected] > 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.
|