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.
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.
Except in the case of ICMP's and L3 NAT, I agree with this. Correctness is also important.
(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.)
RFC 1597 was a great thing. RFC 1918's language wasn't as strong as I would have liked (that is, I liked 1597's applicability statement better) but it names the same nets and thus I approve heartily of it. Private networks are a good thing. But they have to be private, and as shown by the ICMP examples as well as the PMTUD reference earlier in this thread, transit links are not private. So, use private addresses for leaf nets (even multiply homed ones if you can find a NAT solution that will do that for you), not transit nets like ISP T1's.
I agree that ever having a source or destination IP that's RFC1918 outside the domain is a very bad thing.
I don't see anyone here disagreeing with that, but apparently a number of ISP's did not consider the ICMP case when they gave numbers to their T1's, and so it's a question of definition rather than of intent. Transit nets are public, not private, and so they have to have public, not private, addresses. Yikes. A technical discussion on NANOG. What's the world coming to?
participants (2)
-
Joseph C. Pistritto -
Paul A Vixie