What Is a Reserved IP Address? Special Blocks You Can't Use

Why Some IP Addresses Cannot Be Routed Publicly

The global routing system for the public internet operates on one fundamental rule: every IP address on the routing table must be globally unique, and every packet sent to that address must reach exactly one destination. This works because the organizations that manage IP address allocation — IANA (Internet Assigned Numbers Authority) at the global level, and Regional Internet Registries like ARIN, RIPE, and APNIC at the regional level — maintain strict control over which addresses are assigned to which organizations.

But not all IP addresses go through that assignment process. IANA has set aside a substantial portion of the IPv4 address space for specific technical purposes that require addresses to exist on networks without being routable on the public internet. These are reserved IP addresses, and they represent some of the most important infrastructure decisions in networking history. Misunderstanding which ranges are reserved — and why — is a consistent source of configuration errors that range from harmless (a misconfigured test environment) to serious (a production service accidentally configured with a private range).

The Major Reserved IP Ranges in IPv4

The following blocks are defined by IANA and various RFCs as reserved for specific purposes. None of them should appear as destination addresses in BGP routing tables on the public internet.

The RFC 1918 Private Ranges: The Foundation of Every Internal Network

The three private address ranges defined in RFC 1918 — 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 — are the backbone of every internal network ever built. The critical design principle is that these addresses are free to use by any organization on their internal networks, with one absolute constraint: traffic to and from these addresses must never be forwarded onto the public internet. Public routers are configured to drop packets with RFC 1918 source or destination addresses.

This is why Network Address Translation (NAT) exists. Your home router gives every device on your network an address in the 192.168.x.x range. When those devices communicate with the internet, the router replaces the private source address with its own public IP address before forwarding the packet. Return traffic comes back to the router's public IP, and the router uses its NAT table to forward each packet to the correct private address. This lets an entire household — or an enterprise with thousands of devices — share a single public IP address.

Loopback: When a Device Talks to Itself

The entire 127.0.0.0/8 range is reserved for loopback, though in practice almost all software uses only 127.0.0.1. Traffic sent to any address in this range is processed entirely within the local networking stack — it never leaves the machine, never touches a network interface card, and is never visible to any external device.

Loopback addresses are essential for software development and service configuration. When you start a web server on a development machine and access it at http://127.0.0.1:8080, the request travels through the OS networking stack but never goes out to the network. Database servers like PostgreSQL and MySQL default to binding on 127.0.0.1 for exactly this reason — it ensures that the database is not accidentally exposed to external connections. Many distributed system components use loopback for health check endpoints and internal inter-process communication.

APIPA / Link-Local: The Fallback Address

When a device is configured to use DHCP but cannot reach a DHCP server, modern operating systems use a protocol called APIPA (Automatic Private IP Addressing) to self-assign an address in the 169.254.0.0/16 range. On Linux and macOS this is implemented as the Zeroconf / link-local mechanism defined in RFC 3927. On Windows it is marketed as APIPA.

The self-assigned address allows the device to communicate with other devices on the same physical network segment that have also fallen back to link-local addressing — useful for local file sharing or printer access when a router is down. However, link-local addresses have no route to any other network and no gateway. They are strictly local to a single network segment. If you see a 169.254.x.x address on a device that should have a normal IP, it is a strong indicator that the device cannot reach the DHCP server — the router may be down, the DHCP lease pool may be exhausted, or there may be a cable or port issue.

Shared Address Space (100.64.0.0/10): The CGNAT Range

The 100.64.0.0/10 block, defined in RFC 6598, was added in 2012 to solve a specific problem faced by ISPs deploying Carrier-Grade NAT (CGNAT). ISPs need IP addresses for the internal network between their NAT devices and their customers' routers. They cannot use RFC 1918 space because many customers already use those ranges for their home networks, which would create overlapping address conflicts. They cannot use public IPs for this internal purpose because it would waste scarce public address space. RFC 6598 created a new reserved range specifically for this ISP-internal use case.

If you see a 100.64.x.x address, you are behind a CGNAT deployment — your ISP is sharing a single public IP among many customers, each with their own 100.64.x.x internal address assigned by the ISP's NAT infrastructure. This has implications for geolocation accuracy and for services that use IP addresses for per-user rate limiting.

Common Misconceptions

Misconception 1: Reserved IPs Are Wasted Address Space

The private RFC 1918 ranges are among the most heavily used addresses in existence — they are used simultaneously by billions of devices worldwide. Because they are never routed on the public internet, the same 192.168.1.1 address exists in millions of home networks simultaneously without conflict. The entire architecture of home networking, enterprise intranets, and cloud virtual private networks depends on this design. The loopback range similarly carries enormous traffic volume on every networked machine.

Misconception 2: Using 192.168.x.x on a Cloud Server Is Safe

On a bare-metal server or your home network, using 192.168.x.x for internal interfaces is standard. In cloud environments, the story is more complex. Cloud providers like AWS and Google Cloud use their own internal address spaces (often in the 10.x.x.x range) for VPC networking. If you manually assign a 192.168.x.x address to an interface inside a cloud VPC, it may conflict with the provider's internal routing or with VPN tunnels connecting on-premises networks where the same range is used. Always check the address plan of your cloud VPC before assigning private addresses manually.

Misconception 3: 127.0.0.1 Is the Only Loopback Address

The entire 127.0.0.0/8 block is reserved for loopback — that is 16,777,216 addresses, all of which route to the local device. While 127.0.0.1 is the universal convention and what nearly all software uses, any address in that range has identical behavior. Some testing frameworks assign multiple distinct loopback addresses to simulate multiple hosts on a single machine.

Misconception 4: Seeing 169.254.x.x Always Means a Serious Problem

A link-local address is always a symptom of a missing DHCP lease, but the severity depends on context. On a device that is supposed to reach the internet, a 169.254.x.x address is a connectivity-blocking problem. On an isolated test network intentionally running without a DHCP server, link-local addressing is functional and expected. Some IoT devices and industrial systems also use link-local addressing by design for local discovery protocols.

Pro Tips for Network Engineers and Administrators

• Plan your internal address space before deploying: Choose one of the three RFC 1918 ranges and define a subnetting scheme for your organization before you deploy any services. Re-numbering an internal network after services are deployed is painful. The 10.0.0.0/8 range offers the most room; use it for large deployments or future growth.
• Avoid using 192.168.1.0/24 for enterprise networks: This is the default range for most consumer routers and is heavily used in home networks. If your organization deploys a VPN that allows remote workers to connect from home, there is a high probability of IP conflicts if your corporate network also uses 192.168.1.0/24. Use 10.x.x.x or 172.16.x.x ranges for corporate infrastructure.
• Use documentation ranges in examples and training materials: RFC 5737 reserved 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 specifically for use in documentation and examples. Using these ranges in runbooks, training materials, and network diagrams prevents any risk of accidentally routing example traffic to real destinations.
• Treat 169.254.x.x as a monitoring alert trigger: Configure your monitoring system to alert when DHCP-enabled devices report link-local addresses. A device that acquires a 169.254.x.x address is telling you it cannot reach DHCP — catching this early prevents silent connectivity failures.
• Understand CGNAT implications before building customer-IP-based systems: If your application uses client IP addresses for rate limiting, fraud detection, or geolocation, CGNAT means multiple users may share a single public IP. Systems designed around the assumption of one IP per user will misfire in CGNAT environments. Factor this into your architecture for consumer-facing services.
• Check for accidental public routing of private ranges: Use tools like BGP routing table viewers or your cloud provider's route analysis tools to verify that no private range addresses are being inadvertently advertised into public routing. This is a configuration error that can expose internal services or create routing loops.

Reserved IP address ranges are not arbitrary restrictions — each one exists because a specific technical need required addresses that could be used universally without coordination with the global addressing system. Understanding which ranges are reserved and what they are for is fundamental to designing, troubleshooting, and securing any network. Check what type of IP address you are currently using here.