Private IP address ranges: RFC 1918, loopback, link-local and bogons

02Why private addresses exist and how they reach the internet

RFC 1918 was written to slow the exhaustion of IPv4 addresses. Most hosts inside an organisation never need to be reached from outside, so they do not need globally unique addresses. A router performing network address translation (NAT) rewrites their source address to its own public address on the way out, and back on the way in. The general background on public and private addressing is in what is an IP address.

The RFC also sets rules for the boundary. Routing information about private networks "shall not be propagated" between enterprises, packets with private source or destination addresses "should not be forwarded" across those links, and internet providers are expected to filter them. It also asks that DNS records pointing at private addresses stay inside the enterprise.

The three blocks hold 2^24 + 2^20 + 2^16 = 17,891,328 addresses, and because every network reuses them, collisions follow whenever two networks are joined by a VPN or a merger. RFC 1918 itself recommends choosing internal sub-blocks at random rather than starting at the first subnet everyone else uses.

03Loopback, link-local and the other special IPv4 ranges

RFC 1918 space is only part of the address space that never appears on the public internet. IANA's IPv4 Special-Purpose Address Registry, set up by RFC 6890, lists the blocks with a special meaning and whether each is globally reachable; multicast has a registry of its own. The ones a server operator meets most often:

04Private and special-purpose IPv6 ranges

IPv6 has no exact twin of RFC 1918, because it was designed with enough space for every host to have a global address. The closest equivalent is unique local addressing (ULA), and large clouds use it next to link-local space: one major provider's metadata service answers on 169.254.169.254 and, over IPv6, on the ULA address fd00:ec2::254.

05How to check whether an address is private

For one address, compare it with the blocks above: a first octet of 10, a start of 192.168, or 172 followed by a second octet from 16 to 31. In scripts, test membership exactly instead of trusting a library's idea of "private". A subnet calculator shows the full range of any block.

The last command below shows why. Python's is_private follows the IANA registry, so it is true for documentation, loopback and link-local addresses as well, and 100.64.0.1 is neither private nor global. Library behaviour also changes between versions: the Python 3.11 build tested here does not yet know that 3fff::/20 is documentation space and reports it as global.

is1918() { python3 -c 'import ipaddress,sys; a=ipaddress.ip_address(sys.argv[1]); print(any(a in ipaddress.ip_network(n) for n in ("10.0.0.0/8","172.16.0.0/12","192.168.0.0/16")))' "$1"; }

$ is1918 172.31.255.255
True
$ is1918 172.32.0.1
False
$ is1918 100.64.0.1
False

# the library's own flag is broader: it means 'not globally reachable'
$ python3 -c 'import ipaddress; a=ipaddress.ip_address("203.0.113.7"); print(a.is_private, a.is_global)'
True False

06Why the edge should drop private and bogon source addresses

A packet that arrives from the internet with a source address in any of these blocks cannot be genuine: nobody on the internet can be reached at 10.1.2.3 or 127.0.0.1, so the address was forged or leaked by a misconfigured network. Such addresses are called bogons, and Linux logs them as martians. Dropping them at the edge is cheap and removes a class of spoofed traffic.

This is the receiving half of anti-spoofing. The sending half is BCP 38 (RFC 2827, May 2000): every network should drop outbound packets with a source address it does not own. Where that is missing, reflection attacks such as the smurf attack and DNS amplification become possible. BCP 84 (RFC 3704) describes reverse-path filtering, which Linux implements as rp_filter. Before loading the ruleset below, adapt it to the network:

• Apply it only on the interface that faces the internet: 10.0.0.0/8 or fc00::/7 are legitimate on internal interfaces
• On a cloud instance, remove 169.254.0.0/16, because the metadata service answers over the same interface as internet traffic
• Remove 100.64.0.0/10 if your upstream numbers its side of the link from shared address space
• IPv6 link-local fe80::/10 is deliberately absent: neighbour discovery and router advertisements come from link-local addresses
• 192.0.0.0/24 is left out because IANA marks two addresses in it, 192.0.0.9 and 192.0.0.10, as globally reachable anycast services
• On Linux hosts, net.ipv4.conf.all.rp_filter=1 turns on strict reverse-path filtering and net.ipv4.conf.all.log_martians=1 logs impossible sources; use loose mode (2) with asymmetric routing

table inet bogon_filter {
    set bogon4 {
        type ipv4_addr
        flags interval
        elements = {
            0.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8,
            169.254.0.0/16, 172.16.0.0/12, 192.0.2.0/24,
            192.168.0.0/16, 198.18.0.0/15, 198.51.100.0/24,
            203.0.113.0/24, 224.0.0.0/4, 240.0.0.0/4
        }
    }
    set bogon6 {
        type ipv6_addr
        flags interval
        elements = {
            ::ffff:0:0/96, 100::/64, 2001:db8::/32, 3fff::/20, fc00::/7
        }
    }
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        iifname "wan0" ip saddr @bogon4 counter drop
        iifname "wan0" ip6 saddr @bogon6 counter drop
    }
}

07What bogon filtering and a proxy can and cannot stop

Bogon filtering is hygiene, not DDoS protection. Most spoofed floods forge routable public addresses and pass any bogon list, and reflection attacks arrive from the genuine addresses of the servers being abused. The filter removes a slice of junk and closes a few odd failure modes; it does not shrink a flood that is already filling the link. Unallocated public space is also a moving target: Team Cymru, which publishes widely used bogon lists, notes that bogon prefixes "shift constantly", so filter the fixed special-purpose blocks by hand and take unallocated space only from a maintained feed.

A reverse proxy handles spoofing differently. It forwards HTTP requests only from clients that completed a TCP handshake, and a spoofed source cannot complete one, because the SYN-ACK goes to the forged address. Spoofed packets aimed at a proxied website therefore end at the edge, and the origin sees only real connections. Volumetric floods still need upstream capacity, which is what DDoS mitigation provides.

08Common mistakes with private IP ranges

• Writing 172.16.0.0/16 when the whole private block is meant, or allowlisting 172.0.0.0/8, which covers a great deal of public space
• Numbering an office or VPN network 192.168.0.0/24 or 192.168.1.0/24, which many home routers also use, so remote users cannot reach it from home
• Publishing private addresses in public DNS, which RFC 1918 asks operators to avoid and which maps your internal network for outsiders
• Assuming a private address is safe: a service on 10.x is reachable by every compromised machine on that network and by any VPN that routes it
• Forgetting that 127.0.0.1 inside a container is the container itself, not the host
• Treating 100.64.0.0/10 as RFC 1918 space: RFC 6598 says it is distinct, because it is meant for service provider networks