Reserved IP ranges
16 IPv4 blocks and 14 IPv6 blocks are set aside for something other than ordinary public addressing. Each one below names the document that defines it, so every claim on this page can be checked rather than taken on trust.
Reference data last reviewed:
Reserved does not mean one thing. A loopback address never leaves the host, a private address is routed inside a network but not outside it, a documentation address is not routed anywhere by design, and a multicast address does not identify one interface at all. Lumping them together as not public is the reason so many tools give the wrong answer for 100.64.0.0/10.
Reserved IPv4 blocks
Ordered from the most specific block to the least, which is also the order a lookup has to check them in: 255.255.255.255/32 sits inside 240.0.0.0/4, and the more specific answer is the right one.
| Block | Name | Defined by | Globally routable | What it is for |
|---|---|---|---|---|
| 255.255.255.255/32 | Limited broadcast | RFC 919 | No | The all-hosts broadcast address for the local link. Routers never forward it. |
| 192.0.2.0/24 | Documentation (TEST-NET-1) | RFC 5737 | No | Reserved for examples and documentation. Safe to print, never routed. |
| 198.51.100.0/24 | Documentation (TEST-NET-2) | RFC 5737 | No | The second documentation range, used when an example needs two distinct networks. |
| 203.0.113.0/24 | Documentation (TEST-NET-3) | RFC 5737 | No | The third documentation range, used when an example needs a third network. |
| 192.88.99.0/24 | 6to4 relay anycast (deprecated) | RFC 7526 | No | The old 6to4 relay anycast prefix. Its use was deprecated in 2015. |
| 192.0.0.0/24 | IETF protocol assignments | RFC 6890 | No | Held by the IETF for protocol assignments such as DS-Lite and NAT64 discovery. |
| 169.254.0.0/16 | Link-local | RFC 3927 | No | Self-assigned when DHCP fails. Valid only on the local link, never routed. |
| 192.168.0.0/16 | Private-use | RFC 1918 | No | The private range home routers and small offices use by default. |
| 198.18.0.0/15 | Benchmarking | RFC 2544 | No | Reserved for network device benchmarking so test traffic cannot escape. |
| 172.16.0.0/12 | Private-use | RFC 1918 | No | The mid-sized private range, 172.16.0.0 through 172.31.255.255. |
| 100.64.0.0/10 | Shared address space (CGNAT) | RFC 6598 | No | Carrier-grade NAT space. It is not RFC 1918 private space, and it must not be used inside a customer network that a carrier also NATs. |
| 224.0.0.0/4 | Multicast | RFC 5771 | No | Group addressing. A multicast address identifies a set of receivers, never one interface. |
| 240.0.0.0/4 | Reserved for future use | RFC 1112 | No | Formerly class E. Still reserved, and many stacks refuse to assign it. |
| 10.0.0.0/8 | Private-use | RFC 1918 | No | The largest private range, 16,777,216 addresses. The usual choice for a big internal network. |
| 127.0.0.0/8 | Loopback | RFC 1122 | No | Traffic never leaves the host. The whole /8 loops back, not just 127.0.0.1. |
| 0.0.0.0/8 | This network | RFC 1122 | No | Means this host on this network. 0.0.0.0/0 as a route is a different thing: the default route. |
Reserved IPv6 blocks
IPv6 is not IPv4 with longer addresses. There is no broadcast address to reserve, private addressing barely matters because there is no shortage to work around, and several of these blocks exist only to carry IPv4 across an IPv6 network or the other way round.
| Block | Name | Defined by | Globally routable | What it is for |
|---|---|---|---|---|
| ::/128 | Unspecified | RFC 4291 | No | The all-zeros address. A host uses it as a source while it still has no address. |
| ::1/128 | Loopback | RFC 4291 | No | The IPv6 loopback. Unlike IPv4 it is a single address, not a whole block. |
| 64:ff9b::/96 | IPv4-IPv6 translation (NAT64) | RFC 6052 | Yes | The well-known prefix a NAT64 gateway uses to embed an IPv4 address in IPv6. |
| ::ffff:0:0/96 | IPv4-mapped | RFC 4291 | No | How a dual-stack socket represents an IPv4 peer, for example ::ffff:192.0.2.1. |
| 64:ff9b:1::/48 | Local-use IPv4-IPv6 translation | RFC 8215 | No | For translation prefixes that stay inside one network rather than being global. |
| 100::/64 | Discard-only | RFC 6666 | No | A black hole prefix. Routing unwanted traffic here drops it cheaply. |
| 2001:db8::/32 | Documentation | RFC 3849 | No | Reserved for examples. This is the IPv6 counterpart of 192.0.2.0/24. |
| 2001:20::/28 | ORCHIDv2 | RFC 7343 | No | Overlay routable cryptographic hash identifiers, used by HIP. |
| 3fff::/20 | Documentation | RFC 9637 | No | A second, larger documentation range added in 2024 for examples that need more room. |
| 2001::/32 | Teredo | RFC 4380 | Yes | Teredo tunnelling, which carried IPv6 over UDP through IPv4 NATs. |
| 2002::/16 | 6to4 | RFC 3056 | Yes | The 6to4 transition scheme. Its relay anycast prefix was deprecated in 2015. |
| fe80::/10 | Link-local unicast | RFC 4291 | No | Every IPv6 interface has one. Valid only on its own link, so it usually needs a zone id. |
| ff00::/8 | Multicast | RFC 4291 | No | IPv6 has no broadcast at all. Multicast groups do the work broadcast did in IPv4. |
| fc00::/7 | Unique local | RFC 4193 | No | The IPv6 equivalent of private space, though the addresses are meant to be globally unique. |
The same data as JSON
This table is published as a free, keyless endpoint under CC BY 4.0, with the same fields and the same RFC links. No key, no rate limit, CORS open.
curl -s https://subnetkit.dev/api/reserved.json | jq '.ipv4.blocks[] | {cidr, name, rfc}'Full field schema in the OpenAPI document, and the endpoint list on the API page.
Frequently asked questions
Is 100.64.0.0/10 a private IP range?
No. It is shared address space for carrier-grade NAT, defined by RFC 6598, and it is a separate thing from the RFC 1918 private ranges. An ISP hands it out between the customer and the public internet. Using it inside your own network risks colliding with your provider, and the symptom is a connection that works from everywhere except one carrier.
What are the private IP ranges?
Exactly three, from RFC 1918: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Loopback (127.0.0.0/8) and link-local (169.254.0.0/16) are unroutable too, but they are not private address space and serve different purposes.
Which IP ranges can I safely use in documentation?
192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24 for IPv4 (RFC 5737), and 2001:db8::/32 or 3fff::/20 for IPv6 (RFC 3849 and RFC 9637). They are reserved so an example can never point at somebody's real network. Every example on this site uses them.
Does IPv6 have a broadcast address?
No. IPv6 has no broadcast at all, so nothing is reserved for it. The functions broadcast served in IPv4 are handled by multicast groups under ff00::/8, and every interface also carries a link-local address in fe80::/10.
Is 172.32.0.0 a private address?
No. RFC 1918 reserves 172.16.0.0/12, which runs from 172.16.0.0 to 172.31.255.255. 172.32.0.0 is one address past the end and is ordinary public space. This off-by-one is the most common mistake with the middle private range.
Sources
Every block above is taken from one of the two IANA registries and carries the RFC that defines it. Those documents, in full:
- IANA IPv4 Special-Purpose Address Registry
- IANA IPv6 Special-Purpose Address Registry
- RFC 919, which defines 255.255.255.255/32
- RFC 1112, which defines 240.0.0.0/4
- RFC 1122, which defines 127.0.0.0/8
- RFC 1918, which defines 192.168.0.0/16
- RFC 2544, which defines 198.18.0.0/15
- RFC 3056, which defines 2002::/16
- RFC 3849, which defines 2001:db8::/32
- RFC 3927, which defines 169.254.0.0/16
- RFC 4193, which defines fc00::/7
- RFC 4291, which defines ::/128
- RFC 4380, which defines 2001::/32
- RFC 5737, which defines 192.0.2.0/24
- RFC 5771, which defines 224.0.0.0/4
- RFC 6052, which defines 64:ff9b::/96
- RFC 6598, which defines 100.64.0.0/10
- RFC 6666, which defines 100::/64
- RFC 6890, which defines 192.0.0.0/24
- RFC 7343, which defines 2001:20::/28
- RFC 7526, which defines 192.88.99.0/24
- RFC 8215, which defines 64:ff9b:1::/48
- RFC 9637, which defines 3fff::/20
Spotted something wrong? Tell us and it gets corrected. How the data is maintained is described on the about page.