IPv4 addresses are 32 bits long, 2³² = 4,294,967,296 in all, as (RFC) 791 defines them (RFC 791, section 2.3); see how IPv4 addresses work. RFC 1918, Best Current Practice (BCP) 5 since February 1996, records that the Internet Assigned Numbers Authority () has "reserved the following three blocks of the IP address space for private internets" (RFC 1918, section 3). You meet them on internal interfaces, in reverse lookups and in network mergers. By the end you can state each block in Classless Inter-Domain Routing () notation, apply RFC 1918's rules for routers and DNS, explain why mergers force renumbering, recognise a leaked reverse lookup, and check it all with ip, dig and Python.

The three blocks, exactly

Section 3 lists them (RFC 1918, section 3):

     10.0.0.0        -   10.255.255.255  (10/8 prefix)
     172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
     192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

RFC 1918 calls them the 24-bit, 20-bit and 16-bit blocks (section 3), the bits each leaves for hosts: 2²⁴ = 16,777,216, 2²⁰ = 1,048,576 and 2¹⁶ = 65,536 addresses. In classful terms the first is one class A network, "the second block is a set of 16 contiguous class B network numbers", and the third is 256 class C networks (section 3).

In binary, a /12 fixes the first octet and the top four bits of the second: 16 is 0001 0000, so the second octet ends at 0001 1111 (31), and 172.32.0.0, second octet 0010 0000, falls outside (see the Python capture). CIDR notation explained covers the slash.

IANA's IPv4 Special-Purpose Address Space registry gives all three the same flags (IANA, IPv4 Special-Purpose Address Space registry):

Address Block,Name,RFC,Allocation Date,Termination Date,Source,Destination,Forwardable,Globally Reachable,Reserved-by-Protocol
10.0.0.0/8,Private-Use,[RFC 1918],1996-02,N/A,True,True,True,False,False
172.16.0.0/12,Private-Use,[RFC 1918],1996-02,N/A,True,True,True,False,False
192.168.0.0/16,Private-Use,[RFC 1918],1996-02,N/A,True,True,True,False,False

Forwardable True: routers may forward datagrams addressed into the block between external interfaces (RFC 6890, section 2.2.1). Globally Reachable False, RFC 8190's name for the ambiguous Global: not forwardable past a given administrative domain (RFC 8190, section 2.1). The CIDR / Subnet Calculator computes a block's edges and counts; classifying blocks is the registry's job.

What RFC 1918 argues

RFC 1918 reasons about an enterprise, the entity that runs a network and decides its addressing plan (RFC 1918, section 1), and ranks routing overhead outgrowing what Internet service providers (ISPs) can carry above address exhaustion (section 2). Hosts needing no outside access, or only services such as mail through mediating gateways, are private; hosts needing outside IP connectivity are public (section 2).

The space needs no request to IANA or a registry, its addresses "will only be unique within the enterprise, or the set of enterprises which choose to cooperate over this space", and no registry assigns them for external connectivity (RFC 1918, section 3). The price: "The cost of using private internet address space is the potentially costly effort to renumber hosts and networks between public and private" (section 1).

RFC 1918 never names : "private hosts can still have access to external services via mediating gateways (e.g., application layer gateways)" (RFC 1918, section 3). Traditional NAT connects a privately numbered realm to registered, globally unique addresses (RFC 3022, Abstract); only its port-translating form shares one address among many hosts (section 2.2); and it assumes "The addresses used within private network must not overlap with the external addresses" (RFC 2663, section 4.1). See NAT explained.

The rules for routers and for DNS

The core rule: "Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links" (RFC 1918, section 3). Routes get a shall, packets a should. ISPs are expected to reject such routes, a rejection being no routing protocol error (section 3), and filters belong at both ends of every external link, inbound routes included (section 5). Today RFC 7454, BCP 194, says prefixes marked False in what is now the Globally Reachable column SHOULD be discarded on Internet peerings (RFC 7454, section 6.1.1.1); see BGP: how the internet decides where traffic goes.

Spoofed traffic uses the same blocks: BCP 38's example attack forges RFC 1918 sources, generally absent from global routing tables and so unreachable (RFC 2827, section 2), and BCP 84 lists all three among the Martian sources that ingress filtering drops (RFC 3704, section 1).

DNS records stay inside too (RFC 1918, section 3): "DNS clients outside of the enterprise should not see addresses in the private address space used by the enterprise, since these addresses would be ambiguous" (section 5).

Before RFC 1918: RFC 1597 and RFC 1627

RFC 1597, an Informational memo of March 1994 by four of RFC 1918's five authors (RFC 1597, Status of this Memo), already recorded the reservation, and miscounted the third block as 255 class C networks (section 3): 65,536 / 256 = 256.

In July 1994 RFC 1627, Network 10 Considered Harmful (Some Practices Shouldn't be Codified), objected that "RFC 1597 departs from the basic architectural rule that IP addresses must be globally unique", and that RFC 1597 had skipped the usual public review (RFC 1627, Summary). Two RFC 1597 networks that later connect force one to renumber, at a cost likely linear in hosts, and "The probability of address clashes occurring over time approach 100% with RFC 1597." (Operational Issues). A company that had picked class A network 90 internally was "only now recovering from this error, having renumbered some 5,000 hosts" (Operational Issues).

RFC 1918 obsoletes both, and RFC 1627's first author, E. Lear, is its fifth (RFC 1918). Against RFC 1597 it adds BCP status, the count of 256, CIDR prefixes and the merger case with random sub-blocks; RFC 1597 had called renumbering only potential (RFC 1597, section 4).

When two private networks meet

Private space avoids clashes with numbers assigned to others, since IP routing cannot work correctly with ambiguous addresses, yet merging private internets may still require renumbering (RFC 1918, section 4).

Say one company used 10.1.0.0/16 and its merger partner 10.1.128.0/17. The /17 is the upper half of the /16 (third octet 128 to 255), so 2¹⁵ = 32,768 addresses exist twice, while 10.2.0.0/16 differs in the second octet and collides with neither. Python's overlaps() agrees (capture below), as does the CIDR / Subnet Calculator in Overlap / gap mode; Subnet overlaps and gaps generalises the check.

RFC 1918 strongly recommends that an organisation "choose randomly from the reserved pool of private addresses, when allocating sub-blocks for its internal allocation" (RFC 1918, section 5). 10.0.0.0/8 holds 2⁸ = 256 blocks of /16, so two random draws collide with probability 1/256, about 0.4%, while two networks that both take 10.0.0.0/16 always do. Tools such as the Dynamic Host Configuration Protocol () can lower the cost of renumbering (section 4; see the DHCP lease lifecycle), and twice NAT is necessary when realms collide, as with a partner whose space overlaps (RFC 2663, sections 4.3 and 6.1).

IPv6 unique local addresses (ULAs) are designed to let sites combine without conflicts or renumbering (RFC 4193, section 1). Their prefix is fc00::/7 and the next bit, L, is 1 for local assignment (section 3.1), so 1111 1100 becomes 1111 1101 and such prefixes start with fd; they are unique with high probability (section 4.2) and not expected to be globally routable (Abstract). The IPv6 Toolkit labels them Unique local.

When private addresses leak into the public DNS

A private address can also leave as a question. Looking up the name of 10.1.2.3 is a PTR query for 3.2.1.10.in-addr.arpa, and such queries commonly enough travel the public delegation path instead of staying inside the site (RFC 7534, section 1), a leakage RFC 6303 calls significant (RFC 6303, section 1).

The cure is a local answer with the authoritative answer (AA) flag and response code () 3, Non-Existent Domain (NXDOMAIN) (IANA, DNS Parameters registry: DNS RCODEs): "an iterative resolver will now return authoritatively (AA=1) name errors (RCODE=3) for queries within the zones in Section 4" (RFC 6303, section 3), commonly from empty zones whose RNAME SHOULD default to nobody.invalid. (section 3). RFC 6761, which updates RFC 1918, says caching servers SHOULD answer such queries immediately by default (RFC 6761, section 6.1). The 18 zones, 10.in-addr.arpa, 16.172.in-addr.arpa to 31.172.in-addr.arpa (the /12 ends mid-octet) and 168.192.in-addr.arpa, are in IANA's Locally-Served DNS Zones registry (IANA, Locally-Served DNS Zones registry) and among 9's built-in empty zones (BIND 9 Configuration Reference).

What still leaks reaches AS112, named after autonomous system (AS) number 112 (RFC 7534, section 7.1): an anycast sink, deployed since 2002 (Appendix A), that relieves the IN-ADDR.ARPA servers (section 1). RFC 7534 records the RFC 1918 reverse zones as delegated to BLACKHOLE-1.IANA.ORG and BLACKHOLE-2.IANA.ORG, with PRISONER.IANA.ORG in their SOA (sections 2.3 and 3.5):

@ IN SOA prisoner.iana.org. hostmaster.root-servers.org. (

A negative answer's SOA thus hints at its source: nobody.invalid. for an RFC 6303 local zone, prisoner.iana.org. for the sink.

The sink is a backstop. Its operators see no sign that sites are moving towards answering locally (RFC 7534, section 6), and hosts that query it "may well leak information relating to private infrastructure to the public network, and this could present a security risk" (section 8), and the unexpected replies set off intrusion detection systems (RFC 6305, Abstract). DNS rebinding reverses the leak: an attacker's domain answers with an address inside the user's own network, which BIND's deny-answer-addresses rejects when it matches the configured list (BIND 9 Configuration Reference).

The other non-public blocks, briefly

Private, Reserved, and Public IP Ranges maps the whole registry for server-side request forgery () filtering.

Shared address space, 100.64.0.0/10 (RFC 6598, April 2012), numbers links between -grade NAT (CGN) devices and customer premises equipment (), distinct from RFC 1918 space because it is for service provider networks (RFC 6598, Abstract); RFC 1918 space is unsafe there when subscribers number their own networks (section 3). It holds 2²² = 4,194,304 addresses, 100.64.0.0 to 100.127.255.255, and " queries for Shared Address Space addresses MUST NOT be forwarded to the global DNS infrastructure" (section 4). See what breaks when subscribers share one address.

Link-local 169.254.0.0/16 (RFC 3927) is not private either: "A router MUST NOT forward a packet with an IPv4 Link-Local source or destination address" (RFC 3927, section 7). Assignment follows the interface's state, not DHCP (section 1.9); Windows 98 autoconfigured after four unanswered DHCP packets, 24 seconds (Appendix A.3). Microsoft calls this Automatic Private IP Addressing (APIPA) (Microsoft Learn), but IANA lists the block as Link Local (IANA, IPv4 Special-Purpose Address Space registry).

The SSRF URL classifier labels 10.0.0.0/8 private and 100.64.0.0/10 carrier-grade NAT, rates them high and medium risk, never resolves DNS, and does not cover the whole registry.

Seeing it on a real network

ip address show to 10.0.0.0/8 lists only the addresses inside the prefix (ip-address(8)). Illustrative output, trimmed:

$ ip address show to 10.0.0.0/8
    inet 10.1.2.3/16 brd 10.1.255.255 scope global eth0

scope global is about the host and its links, not the internet, despite the manual's wording, "global - the address is globally valid" (ip-address(8)).

ip route get 10.1.2.3 prints the route the kernel would use (ip-route(8)), which for a private destination should stay internal; see routing tables and the default gateway.

$ dig -x 10.1.2.3
$ dig @prisoner.iana.org hostname.as112.net txt +short +norec

dig -x 10.1.2.3 builds the reverse name and asks for type PTR, class IN (BIND 9 Manual Pages: dig); a resolver serving the zone locally should answer NXDOMAIN with AA set. +norec clears the recursion desired (RD) bit that dig sets by default (same page), and the second command is AS112's own node check (RFC 7534, section 3.6). The dig command builder and the dig output explainer build and decode such queries.

Google's () interface returns answers as objects whose Status is the DNS response code (Google Public DNS documentation). Its answer on 2026-10-18 to a PTR query for 10.0.0.1:

{"Status":3,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,"Question":[{"name":"1.0.0.10.in-addr.arpa.","type":12}]}

Status 3 is NXDOMAIN (IANA, DNS Parameters registry: DNS RCODEs); RD is recursion desired; the question has type 12, PTR; no authority section follows. Cloudflare answered alike (Cloudflare 1.1.1.1 documentation). For 100.64.0.1 they differed: Cloudflare gave a bare NXDOMAIN, Google the public zone's SOA, so Google was not serving that zone locally.

Python's ipaddress module checks the rest offline (captured on 2026-10-18 with Python 3.13.16):

import ipaddress
for n in ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "100.64.0.0/10"):
    net = ipaddress.ip_network(n)
    print(n, "first", net.network_address, "last", net.broadcast_address, "num_addresses", net.num_addresses)
print("2**32 =", 2**32)
for a in ("10.1.2.3", "172.31.255.255", "192.168.1.1", "100.64.0.1", "169.254.1.1", "127.0.0.1", "192.0.2.1"):
    ip = ipaddress.ip_address(a)
    print(a, "is_private", ip.is_private, "is_global", ip.is_global)
print(ipaddress.ip_address("172.32.0.0") in ipaddress.ip_network("172.16.0.0/12"))
print(ipaddress.ip_address("172.31.255.255") in ipaddress.ip_network("172.16.0.0/12"))
print(ipaddress.ip_network("10.1.0.0/16").overlaps(ipaddress.ip_network("10.1.128.0/17")))
print(ipaddress.ip_network("10.1.0.0/16").overlaps(ipaddress.ip_network("10.2.0.0/16")))
print(ipaddress.ip_address("10.1.2.3").reverse_pointer)

10.0.0.0/8 first 10.0.0.0 last 10.255.255.255 num_addresses 16777216
172.16.0.0/12 first 172.16.0.0 last 172.31.255.255 num_addresses 1048576
192.168.0.0/16 first 192.168.0.0 last 192.168.255.255 num_addresses 65536
100.64.0.0/10 first 100.64.0.0 last 100.127.255.255 num_addresses 4194304
2**32 = 4294967296
10.1.2.3 is_private True is_global False
172.31.255.255 is_private True is_global False
192.168.1.1 is_private True is_global False
100.64.0.1 is_private False is_global False
169.254.1.1 is_private True is_global False
127.0.0.1 is_private True is_global False
192.0.2.1 is_private True is_global False
False
True
True
False
3.2.1.10.in-addr.arpa

So is_private is no RFC 1918 test: it is True for 127.0.0.1, 169.254.1.1 and 192.0.2.1, and False for 100.64.0.1, where is_global is False too. The documentation defines it as "True if the address is defined as not globally reachable by iana-ipv4-special-registry", with an exception for 100.64.0.0/10 (Python 3.14 documentation, ipaddress), a behaviour changed in version 3.13 (same page). The Python playground runs CPython 3.14 in the browser.

What to remember

  • RFC 1918 (BCP 5, February 1996) reserves 10.0.0.0/8 (16,777,216 addresses), 172.16.0.0/12 (up to 172.31.255.255, 1,048,576) and 192.168.0.0/16 (65,536).
  • The blocks need no registry and are unique only within an enterprise or a cooperating group; their routes shall not cross enterprise borders, and their packets should not.
  • Renumbering is RFC 1918's named cost, mergers included; random sub-blocks make collisions rare, and IPv6 ULAs avoid them.
  • Reverse lookups for private addresses belong inside the site (RFC 6303, RFC 6761); leaks reach the AS112 sink, whose SOA names prisoner.iana.org..
  • 100.64.0.0/10 (shared address space for carrier-grade NAT) and 169.254.0.0/16 (link-local) are not RFC 1918 space.
  • Python's is_private means not globally reachable in IANA's registry: True for 127.0.0.1, False for 100.64.0.1.

Sources