192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24 are the three IPv4 blocks reserved for documentation. IANA lists them as TEST-NET-1, TEST-NET-2 and TEST-NET-3 in its IPv4 Special-Purpose Address Space registry, next to 22 other entries that cover private networks, loopback, the carrier-grade NAT range and a few anycast services. The IPv6 registry has 25 entries of its own. Both were last updated on October 9, 2025.
This page goes through all 50. On September 29, 2026, we also sent one address from each entry to the Ipregistry API and checked the prefixes against RIPE's routing data, because "reserved" covers three different situations. Some addresses cannot be located because they exist in millions of networks at once. Some are bogons that should never show up in a packet. And a handful are announced in BGP right now and will answer you from anywhere.
How to read a row of the IANA special-purpose registries
Until 2013 the IETF cataloged special addresses by publishing a fresh RFC every few years, the last ones being RFC 5735 for IPv4 and RFC 5156 for IPv6. RFC 6890 (April 2013, BCP 153) replaced those with two living registries that share one set of columns. A new row requires IETF Review.
Five boolean columns carry the meaning. Source and Destination say whether an address from the block is valid in that field of a packet that transits two devices. Forwardable says whether a router may pass such a packet between external interfaces, and Globally Reachable whether it may travel beyond a single administrative domain. Reserved-by-Protocol is true when the defining RFC obliges every IP implementation to treat the block specially, as with 127.0.0.0/8.
The fourth column used to be called "Global". RFC 8190 renamed it in June 2017 because the word was ambiguous: an address can be global in allocation scope without being globally reachable. One rule ties the columns together: if Destination is false, Forwardable and Globally Reachable must be false too.
A word on names, since it changes what you type into a search box. IANA now titles the pages "IPv4 Special-Purpose Address Space" and "IPv6 Special-Purpose Address Space", each with a note saying it was formerly known as the IANA IPv4 (or IPv6) Special-Purpose Address Registry. The URLs still contain iana-ipv4-special-registry, and every RFC written before the rename uses the old name.
TEST-NET-1, TEST-NET-2 and TEST-NET-3, the documentation ranges
| Block | Name | Range | Defined by |
|---|---|---|---|
| 192.0.2.0/24 | Documentation (TEST-NET-1) | 192.0.2.0 to 192.0.2.255 | RFC 5737 |
| 198.51.100.0/24 | Documentation (TEST-NET-2) | 198.51.100.0 to 198.51.100.255 | RFC 5737 |
| 203.0.113.0/24 | Documentation (TEST-NET-3) | 203.0.113.0 to 203.0.113.255 | RFC 5737 |
| 2001:db8::/32 | Documentation | 2001:db8:: to 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff | RFC 3849 |
| 3fff::/20 | Documentation | 3fff:: to 3fff:fff:ffff:ffff:ffff:ffff:ffff:ffff | RFC 9637 |
RFC 5737, written by Jari Arkko, Michelle Cotton and Leo Vegoda and published in January 2010, defines the three IPv4 blocks. 192.0.2.0/24 is the old one, which the RFC traces back to RFC 1166 of July 1990. The other two were added "primarily to ease the writing of examples involving addresses from multiple networks". With a single /24 you cannot draw a customer, a transit provider and a server on separate networks without making addresses up.
Their registry rows are the strictest possible, with all five columns set to False. A documentation address is not a valid source, not a valid destination, and no router should forward it. RFC 5737 adds that "these blocks are not for local use", which is where they differ from private space. 10.0.0.1 belongs on a LAN. 192.0.2.1 belongs in a PDF.
The reason to bother is that every other address belongs to someone, or will. RFC 5737 gives its own cautionary example: 128.66.0.0/16 "has been used for some examples in the past" but was never reserved, so it "can be used for regular address assignments with caution". An example that hardcodes 1.2.3.4 gets pasted into a config file sooner or later, and from then on a real network receives the traffic.
Filtering these blocks is a SHOULD in the RFC, and operators have not always done it. RIPEstat shows none of its 327 RIS peers carrying any of the three prefixes on September 29, 2026, but its history has 192.0.2.0/24 in the routing table as late as April 28, 2020, and both 198.51.100.0/24 and 203.0.113.0/24 on January 30, 2023. (Registries slip too: ARIN's RDAP record for 198.51.100.0/24 is named TEST-NET-1.)
Private, shared and loopback space fill most of the IPv4 registry
Counted in addresses, five entries dominate. 240.0.0.0/4, the former Class E, holds 268,435,456 addresses that RFC 1112 (August 1989) reserves "for future addressing modes". Loopback (127.0.0.0/8), "this network" (0.0.0.0/8) and 10.0.0.0/8 take a /8 each, and 100.64.0.0/10 adds 4,194,304 more. All 25 entries together cover 324,274,176 addresses, or 7.55% of IPv4.
The three RFC 1918 blocks (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16, 17,891,328 addresses in total) are Forwardable but not Globally Reachable: routers inside one organization may carry them, and they stop at its edge. 100.64.0.0/10 has the same flags and a different tenant. RFC 6598 reserved it in April 2012 for the link between a carrier-grade NAT and the customer's router, so that an ISP's internal numbering never collides with the 192.168.1.0/24 behind the customer's own NAT. We covered what that does to location data in our post on CGNAT.
Link-local space, 169.254.0.0/16, is not Forwardable at all, so packets stay on the link where they were sent. That makes it a natural home for the instance metadata endpoint that cloud providers expose at 169.254.169.254. Benchmarking space (198.18.0.0/15, from RFC 2544) exists so that a test rig plugged into a production network by accident does not collide with anything real.
Some reserved blocks are routed on the internet today
Five IPv4 entries and nine IPv6 entries are marked Globally Reachable. The clearest case is AS112, an anycast service run by volunteer operators that absorbs reverse DNS queries for private addresses, the lookups for names like 1.1.168.192.in-addr.arpa that leak out of home and office networks. Its servers prisoner.iana.org, blackhole-1.iana.org and blackhole-2.iana.org live in 192.175.48.0/24 (RFC 7534), and the newer blackhole.as112.arpa sits at 192.31.196.1 and 2001:4:112::1 (RFC 7535).
These prefixes are as routed as a prefix gets. On September 29, 326 of 327 RIS peers carried 192.175.48.0/24 with origin AS112, and 324 carried 192.31.196.0/24.
Globally Reachable is a permission, though, and most blocks that have it are absent from the global table. No RIS peer saw a route for AMT (192.52.193.0/24 and 2001:3::/32), ORCHIDv2 (2001:20::/28), the drone remote ID prefix (2001:30::/28) or the NAT64 well-known prefix. The rest are single anycast addresses for protocols that need a fixed destination, such as 192.0.0.9 and 2001:1::1 for the Port Control Protocol.
Then there is the block that should be gone. RFC 7526 deprecated the 6to4 relay anycast prefix, 192.88.99.0/24, in May 2015, and the registry gives it a termination date. Eleven years later AS6939 (Hurricane Electric) still originates it, and 243 of 327 RIS peers see the route. The same AS originates 2002::/16 for 6to4 and 2001::/32 for Teredo.
The IPv6 registry, from 2001:db8::/32 to 64:ff9b::/96
IPv6 had a documentation prefix before IPv4 had three. APNIC allocated 2001:db8::/32 after a proposal in its own policy community, and RFC 3849 recorded it in July 2004. In August 2024 Geoff Huston and Nick Buraglio added 3fff::/20 through RFC 9637. Their argument was arithmetic: in August 2023, 25.9% of the 62,770 IPv6 allocations and assignments recorded by the RIRs were larger than a /32, so a /32 could not depict a large network with its real prefix lengths.
64:ff9b::/96 is the NAT64 well-known prefix from RFC 6052. An IPv6-only host reaches an IPv4 server by writing the IPv4 address into the low 32 bits, so 64:ff9b::808:808 means 8.8.8.8 by way of a translator. Its sibling 64:ff9b:1::/48 (RFC 8215) is for translation inside one network and is not Globally Reachable. The mechanics are in our RFC 10001 post.
Most recent additions are on the IPv6 side: 2001:30::/28 for drone remote identification tags (RFC 9374), 5f00::/16 for SRv6 segment identifiers (RFC 9602), and 100:0:0:1::/64, a dummy prefix that RFC 9780 introduced in May 2025 as the destination for OAM packets such as BFD over MPLS, in place of an IPv4-mapped loopback address.
Every entry, with what a lookup returns
The two tables below reproduce the registries as of September 29, 2026. The last column is what the Ipregistry API answered for an address inside the block. Error is HTTP 400 with the code RESERVED_IP_ADDRESS. Bogon is HTTP 200 with security.is_bogon set to true. Record is HTTP 200 with is_bogon false.
| Block | Name | RFC | Globally reachable | Lookup |
|---|---|---|---|---|
| 0.0.0.0/8 | This network | RFC 791 | No | Error |
| 0.0.0.0/32 | This host on this network | RFC 1122 | No | Error |
| 10.0.0.0/8 | Private-Use | RFC 1918 | No | Error |
| 100.64.0.0/10 | Shared Address Space | RFC 6598 | No | Error |
| 127.0.0.0/8 | Loopback | RFC 1122 | No | Error |
| 169.254.0.0/16 | Link Local | RFC 3927 | No | Error |
| 172.16.0.0/12 | Private-Use | RFC 1918 | No | Error |
| 192.0.0.0/24 | IETF Protocol Assignments | RFC 6890 | No | Bogon |
| 192.0.0.0/29 | IPv4 Service Continuity Prefix | RFC 7335 | No | Bogon |
| 192.0.0.8/32 | IPv4 dummy address | RFC 7600 | No | Bogon |
| 192.0.0.9/32 | Port Control Protocol Anycast | RFC 7723 | Yes | Bogon |
| 192.0.0.10/32 | Traversal Using Relays around NAT Anycast | RFC 8155 | Yes | Bogon |
| 192.0.0.170/32, 192.0.0.171/32 | NAT64/DNS64 Discovery | RFC 8880, RFC 7050 | No | Bogon |
| 192.0.2.0/24 | Documentation (TEST-NET-1) | RFC 5737 | No | Bogon |
| 192.31.196.0/24 | AS112-v4 | RFC 7535 | Yes | Record (AS112) |
| 192.52.193.0/24 | AMT | RFC 7450 | Yes | Record |
| 192.88.99.0/24 | Deprecated (6to4 Relay Anycast) | RFC 7526 | Deprecated | Bogon |
| 192.88.99.2/32 | 6a44-relay anycast address | RFC 6751 | No | Bogon |
| 192.168.0.0/16 | Private-Use | RFC 1918 | No | Error |
| 192.175.48.0/24 | Direct Delegation AS112 Service | RFC 7534 | Yes | Record (AS112) |
| 198.18.0.0/15 | Benchmarking | RFC 2544 | No | Bogon |
| 198.51.100.0/24 | Documentation (TEST-NET-2) | RFC 5737 | No | Bogon |
| 203.0.113.0/24 | Documentation (TEST-NET-3) | RFC 5737 | No | Bogon |
| 240.0.0.0/4 | Reserved | RFC 1112 | No | Bogon |
| 255.255.255.255/32 | Limited Broadcast | RFC 8190, RFC 919 | No | Bogon |
| Block | Name | RFC | Globally reachable | Lookup |
|---|---|---|---|---|
| ::1/128 | Loopback Address | RFC 4291 | No | Error |
| ::/128 | Unspecified Address | RFC 4291 | No | Error |
| ::ffff:0:0/96 | IPv4-mapped Address | RFC 4291 | No | Bogon |
| 64:ff9b::/96 | IPv4-IPv6 Translat. | RFC 6052 | Yes | Record (empty) |
| 64:ff9b:1::/48 | IPv4-IPv6 Translat. | RFC 8215 | No | Bogon |
| 100::/64 | Discard-Only Address Block | RFC 6666 | No | Bogon |
| 100:0:0:1::/64 | Dummy IPv6 Prefix | RFC 9780 | No | Bogon |
| 2001::/23 | IETF Protocol Assignments | RFC 2928 | No | Record |
| 2001::/32 | TEREDO | RFC 4380, RFC 8190 | N/A | Bogon |
| 2001:1::1/128 | Port Control Protocol Anycast | RFC 7723 | Yes | Record |
| 2001:1::2/128 | Traversal Using Relays around NAT Anycast | RFC 8155 | Yes | Record |
| 2001:1::3/128 | DNS-SD Service Registration Protocol Anycast | RFC 9665 | Yes | Record |
| 2001:2::/48 | Benchmarking | RFC 5180 | No | Bogon |
| 2001:3::/32 | AMT | RFC 7450 | Yes | Record |
| 2001:4:112::/48 | AS112-v6 | RFC 7535 | Yes | Record (AS112) |
| 2001:10::/28 | Deprecated (previously ORCHID) | RFC 4843 | Deprecated | Bogon |
| 2001:20::/28 | ORCHIDv2 | RFC 7343 | Yes | Record |
| 2001:30::/28 | Drone Remote ID Protocol Entity Tags (DETs) Prefix | RFC 9374 | Yes | Record |
| 2001:db8::/32 | Documentation | RFC 3849 | No | Bogon |
| 2002::/16 | 6to4 | RFC 3056 | N/A | Bogon |
| 2620:4f:8000::/48 | Direct Delegation AS112 Service | RFC 7534 | Yes | Record (AS112) |
| 3fff::/20 | Documentation | RFC 9637 | No | Bogon |
| 5f00::/16 | Segment Routing (SRv6) SIDs | RFC 9602 | No | Bogon |
| fc00::/7 | Unique-Local | RFC 4193, RFC 8190 | No | Error |
| fe80::/10 | Link-Local Unicast | RFC 4291 | No | Error |
Two things are absent. Multicast (224.0.0.0/4 and ff00::/8) has registries of its own, and unallocated space is not special-purpose at all. That is the territory of bogon lists, which combine these reserved blocks with whatever the RIRs have not handed out yet.
What an IP geolocation API returns for a reserved address
Private, shared, loopback, link-local and unique-local addresses are refused outright, and so are 0.0.0.0/8, the unspecified address :: and multicast:
https://api.ipregistry.co/10.1.2.3?key=YOUR_API_KEY
HTTP 400
{
"code": "RESERVED_IP_ADDRESS",
"message": "You tried to look up a site local (private) IP address. This kind of IP address cannot be used to deduce geolocation data (learn more at https://en.wikipedia.org/wiki/Private_network).",
"resolution": "If you got the address from a user request, you should consider the request as a threat. Otherwise, retry with a public and non-reserved IPv4 or IPv6 address."
}There is nothing to look up. 10.1.2.3 exists in millions of networks at the same moment, and no database can know which one you mean. The resolution field is blunt about an address like this arriving in a user request: "you should consider the request as a threat". The usual culprit is more boring. If your application logs 10.x or 100.64.x addresses as client IPs, it is reading the socket address of its own load balancer and should be parsing the forwarding header that balancer sets.
Documentation, benchmarking, protocol-assignment and Class E addresses get a response, with the bogon flag raised and every location field null:
https://api.ipregistry.co/203.0.113.7?key=YOUR_API_KEY&fields=ip,type,location.country.code,connection.asn,connection.organization,connection.route,security.is_bogon
HTTP 200
{
"connection": {
"asn": null,
"organization": null,
"route": null
},
"ip": "203.0.113.7",
"location": {
"country": {
"code": null
}
},
"security": {
"is_bogon": true
},
"type": "IPv4"
}Entries that are announced in BGP come back as ordinary records. 192.175.48.1 returns AS112, DNS-OARC, the route 192.175.48.0/24 and is_anycast: true. A city comes attached, but for a prefix served from many sites at once it is registry bookkeeping, and the same goes for protocol anycast addresses like 2001:1::1 that nobody announces. Trust the ASN and ignore the city.
Transition addresses need one step of preprocessing. 64:ff9b::808:808 returns an empty record that is not flagged as a bogon, so to learn where that traffic ends up, take the low 32 bits and look up 8.8.8.8. An IPv4-mapped address such as ::ffff:808:808 already resolves to the location of the embedded IPv4 address, with the bogon flag set because the mapped form is not valid on the wire.
Checking an address against the registry in code
IANA publishes both registries as CSV, so a checker does not need a hardcoded list that goes stale. This Python function downloads them and returns the most specific matching entry. Specificity matters inside 192.0.0.0/24, where a /32 can carry different flags from the /24 around it.
import csv
import ipaddress
import re
import urllib.request
REGISTRY = ("https://www.iana.org/assignments/iana-ipv{v}-special-registry/"
"iana-ipv{v}-special-registry-1.csv")
def load_registry():
entries = []
for version in (4, 6):
with urllib.request.urlopen(REGISTRY.format(v=version)) as response:
lines = response.read().decode().splitlines()
for row in csv.DictReader(lines):
# Drop footnote markers like "[2]" and split "a/32, b/32" cells
blocks = re.sub(r"\[\d+\]", "", row["Address Block"]).split(",")
for block in blocks:
entries.append((ipaddress.ip_network(block.strip()), row))
return entries
def special_purpose(address, entries):
ip = ipaddress.ip_address(address)
matches = [(net, row) for net, row in entries
if net.version == ip.version and ip in net]
# The most specific block wins: 192.0.0.9/32 beats 192.0.0.0/24
return max(matches, key=lambda match: match[0].prefixlen, default=None)>>> entries = load_registry()
>>> special_purpose("203.0.113.7", entries)[1]["Name"]
'Documentation (TEST-NET-3)'
>>> special_purpose("192.0.0.9", entries)[1]["Name"]
'Port Control Protocol Anycast'
>>> special_purpose("8.8.8.8", entries) is None
TrueCache the result in production. The registries change slowly: 16 new rows from 2014 to 2025, and none at all in half of those years.
Python's built-in ipaddress module reads the same registries, but its property names mislead. On Python 3.14, ip_address("192.0.2.1").is_private is True although documentation space is not private, ip_address("100.64.1.1").is_private is False, and ip_address("192.88.99.1").is_global is True for a prefix deprecated in 2015.
Ipregistry returns the bogon flag, the origin ASN and the anycast flag in the same response as the location, so a single call tells you whether an address can be located at all. A free account comes with 20,000 lookups to get started.
Keep users in the loop Ship release notes that get read. Try Noticeable