The evils of RFC1918
We were discussing today people using RFC1918 for operational networks. People suggested that with good filtering on the edge of the network (disallowing packets entering or leaving with rfc1918 source or destination addresses) that RFC1918 addresses are perfectly usable. I suggest that this is dangerous. People using RFC1918 addresses for routers is especially dangerous. A router that must respond with an error (such as fragmention required, or ttl exceeded) that has only RFC1918 addresses can only respond with a packet sourced from an RFC1918 address. This packet will be dropped at the next “site” border. This now creates a Path MTU Discovery blackhole, or a traceroute “*” on the graph. The former problem is actually a big one. A Path MTU Discovery blackhole is a major problem on the Internet, and is difficult to diagnose. It presents as weird behaviour where you can get small files over the link, but the connection “freezes” if you get more data over the link. [Update: This can occur if you don’t announce your routers IP’s into BGP too] There is no way to track down someone who’s using an RFC1918 address short of logging into every router and monitering it’s ports to figure out which interface the packet(s) are coming in from and repeating the procedure further upstream. This makes reporting broken machines leaking RFC1918 addresses onto the public internet nearly impossible. When the boundary drops are not properly put in place you get all kinds of problems including 2 to 3% of queries at the f root nameserver being from RFC1918 addresses in 2001. People can even multiply the problem by adding RFC1918 to the global DNS database. There are situations where people publish a host that resolves to an RFC1918 address as a low numbered MX. The idea is that the person won’t be able to connect to the host, so they’ll deliver to a higher mx which will then attempt to connect to the lower mx and succeed. Obviously giving no thought as to what happens if the sender can reach a machine with that address, and what will happen if it’s running a mail server. Other problems occur with RFC1918 that aren’t directly associated with using RFC1918 addresses such as bogus queries against the root name servers to reverse lookup rfc1918 addresses. Up to 10% of queries against the root name servers are looking for the reverse lookups for rfc1918 addresses. I’ve personally experienced sshing into a machine that had a rfc1918 address and ending up on a router somewhere inside someone elses network. Since then I beefed up the boundary checks on my network to include reject routes to avoid packets destined to rfc1918 out of my network space. People always swear that they are never going to connect to anyone elses network, and thus it doesn’t matter that they use non unique space. This is proven false time and time again, mostly by the use of vpns but occasionally by merging of companies or by other means. Sorting out a the mess of trying to talk to multiple organisations all using the same RFC1918 address space is a nightmare. Even trying to get transit across someones network is frought with danger as they are almost certainly using rfc1918 somewhere, so your packets are unlikely to reach the far end of their network. I have personally seen situations where someone has brought in a computer with a common RFC1918 address (192.168.1.1) and plugged into a network bringing it down, as that was an address also used by the default gateway. This would be avoided if people didn’t always end up using the same addresses. This can be ameliorated by using addresses out of 172.16.0.0/12 which seems to be mostly unused, presumably because the non multiple of 8 prefix makes calculating netmasks complicated. The major reason we have RFC1918 space is because we just don’t have enough IPv4 addresses to get everyone. A lot of machines should have realworld addresses but don’t, so they are hidden behind NAT and are using RFC1918 addresses because they are the only addresses that can be assured not to be used legitimately elsewhere on the Internet. APNIC (and a lot of others) claim that getting an IPv4 range is very easy. I’d be inclined to believe them in the cases they expect you to be (an ISP or large organisation). I’ve never experienced trying to get IP’s from APNIC. The only thing I’d want IP addresses for would be the Metanet which would almost deserve them. However I don’t have any way of providing routing for those IP’s at a reasonable price, and I dont’ think apnic will give me addresses that I don’t intend to make globally routable. Hrm, perhaps I’ll ask at NZNOG. Also, while in theory getting IPv4 addresses is free, there are a lot of hidden costs. There is a lot of paperwork to fill out (showing how you plan to use the space), Also to get more than one range or a large range, you must be a member of Apnic which is a reasonably pricey proposition for an organisation that doesn’t have the Internet as a primary service. RFC1918 space is often given as a “Security Measure”. This is bogus. The security you get from rfc1918 space is from the address space being filtered. If you cannot configure your filters correctly, then you will be left exposed no matter what address space you use. It’s just as likely that people will be able to route into your network with filtered rfc1918 space, as they will with filtered public address space. Most of the problems on modern networks are quite happy to jump over firewalls, and attack rfc1918 address space as well as they attack any other. Most of the time this is due to people bringing in compromised laptops, fetching infected webpages, reading trojaned emails, using weak passwords, or just simply falling for a phishing scam. So, in conclusion, RFC1918 is bad. There are lots of bad failure modes, including addresses leaking via IP packets (As sources or destinations), inside packets (in DNS queries) or being near malicious in their use of DNS. The small size of the RFC1918 ranges lead to collisions between people which can cause all kinds of weird issues. To resolve these problems we need more addresses so we don’t need to rely on private address space.