Reserved and Bogon IPv4 Ranges
Ranges with a defined special purpose, and the filters that stop them appearing in the global routing table. Check a block against this list before you buy it, and check your own filters against it before you blame someone else’s network.
Special-purpose ranges
From the IANA IPv4 Special-Purpose Address Registry, current as of 2026.
| Range | RFC | Purpose | Globally routable |
|---|---|---|---|
| 0.0.0.0/8 | 1122 | “This network” | No |
| 10.0.0.0/8 | 1918 | Private use | No |
| 100.64.0.0/10 | 6598 | Shared space for CGNAT | No |
| 127.0.0.0/8 | 1122 | Loopback | No |
| 169.254.0.0/16 | 3927 | Link-local | No |
| 172.16.0.0/12 | 1918 | Private use | No |
| 192.0.0.0/24 | 6890 | IETF protocol assignments | No |
| 192.0.2.0/24 | 5737 | Documentation (TEST-NET-1) | No |
| 192.31.196.0/24 | 7535 | AS112-v4 | Yes |
| 192.52.193.0/24 | 7450 | AMT | Yes |
| 192.88.99.0/24 | 7526 | Former 6to4 relay anycast, deprecated | No |
| 192.168.0.0/16 | 1918 | Private use | No |
| 192.175.48.0/24 | 7534 | Direct delegation AS112 | Yes |
| 198.18.0.0/15 | 2544 | Benchmark testing | No |
| 198.51.100.0/24 | 5737 | Documentation (TEST-NET-2) | No |
| 203.0.113.0/24 | 5737 | Documentation (TEST-NET-3) | No |
| 224.0.0.0/4 | 5771 | Multicast | No |
| 233.252.0.0/24 | 5771 | Multicast documentation | No |
| 240.0.0.0/4 | 1112 | Reserved for future use | No |
| 255.255.255.255/32 | 8190 | Limited broadcast | No |
The three documentation ranges are worth memorising. If an example, a vendor manual, or a configuration template contains 192.0.2.x, 198.51.100.x, or 203.0.113.x, it was written to be copied and adapted — those addresses are not meant to reach anything.
Bogons and full bogons
A bogon is any prefix that should not appear in the global table. The stable part of that list is the table above: reserved and special-purpose space that changes every few years at most. Filtering it is safe and standard.
A full bogon list adds space that IANA has delegated to a registry but which the registry has not yet issued to anyone. That list changes continuously as registries make allocations and as blocks move through transfers.
The distinction is operationally important in one direction: a hardcoded full bogon list is a liability. Space gets issued, the holder announces it, and networks whose filters were written three years ago still discard it. This is the single most common reason a newly acquired block is reachable from most of the internet but not all of it.
If you filter unallocated space, feed the filter from a live source — a BGP-based bogon feed or a regularly regenerated list — rather than from a static configuration.
Checking a block before you commit
Reserved space cannot be acquired, but adjacent problems can be. Before agreeing to buy or lease a range:
Confirm it is not special-purpose. Cross-check the prefix against the table above. Space inside 240.0.0.0/4 or the documentation ranges is not usable no matter what a listing says.
Confirm the registry record. The block should appear in the correct RIR database with a plausible holder and status. How to read those records is in WHOIS and RDAP.
Confirm current visibility. Check whether the prefix is announced today, by whom, and whether public looking glasses see it. A block that vanished from the table years ago may sit in stale filters.
Check reputation separately. Clean bogon status says nothing about blocklists. A range can be perfectly routable and still be useless for mail.
When your own space is being filtered
Symptoms are partial: reachable from most networks, invisible from a few. Work through it in this order.
- Confirm your upstreams accept and propagate the announcement — check a public route collector, not your own router.
- Check that the prefix is not longer than /24, which most networks filter regardless of validity.
- Verify the IRR route object exists and matches the originating AS.
- Verify RPKI validity, since invalid announcements are dropped by a growing share of the internet.
- If all of the above are correct and specific networks still cannot see it, the remaining cause is usually a stale bogon filter on their side. Contact them directly; there is no way to fix it from yours.
Related
- Private IP ranges — the RFC 1918 subset in detail
- CGNAT — what 100.64.0.0/10 is for
- WHOIS and RDAP — verifying who holds a block
- CIDR chart — prefix lengths and the /24 filtering floor