Type 127.0.0.1 and you reach your own machine. Most developers know that address the way they know their own phone number, and most assume it is the loopback address, a single reserved number set aside for the purpose.
It is one of 16,777,216. The whole of 127.0.0.0/8 was reserved for loopback, and the document that reserved it never mentions 127.0.0.1 at all.
What the standard actually reserves
RFC 1122, the requirements for internet hosts, gives the reservation in two lines of a table:
"{ 127, <any> } — Internal host loopback address. Addresses of this form MUST NOT appear outside a host."
Any address beginning 127 qualifies. Search that RFC for the string 127.0.0.1 and you will not find it — the document uses MUST 199 times and names the famous address zero times, because it is reserving a network rather than an address.
The current special-purpose registry records the same block, allocated in September 1981, marked not forwardable, not global, and reserved by protocol. Two protocols have been granted exceptions and may legitimately carry 127-block addresses in their payloads: MPLS LSP ping and BFD for MPLS.
Whether the other sixteen million work depends on your operating system
This is where the tidy version of the story breaks, and it is worth testing on the machine in front of you rather than taking anyone's word for it.
On Linux, the whole block behaves as advertised. Binding a socket to 127.0.0.2 works. So does 127.9.9.9. So, unusually, do 127.0.0.0 and 127.255.255.255, which in any ordinary subnet would be the network and broadcast addresses and unusable. All 16,777,216 are live host addresses on the loopback interface.
On macOS, exactly one works. Binding to 127.0.0.2 fails with EADDRNOTAVAIL, and pinging it loses every packet. Each additional address has to be added by hand as an interface alias before anything can use it.
⚠️ The interface configuration gives no warning of this. Both systems show the loopback interface carrying a /8 netmask, so the thing that differs is the kernel's willingness to treat the rest of the block as local, not anything you can read off ifconfig.
The Internet-Draft that proposes reclaiming part of the block describes the same split: some operating systems "treat all 127.0.0.0/8 as distinct loopback addresses by default, while others assign this function only to 127.0.0.1 and make all other such addresses unusable."
Something does use them
The block is not quite as empty as it looks. On many Linux systems the systemd stub DNS resolver listens on 127.0.0.53, which is why that address turns up in resolv.conf on machines nobody deliberately configured that way.
Binding is per-address, not per-block, which surprises people the first time they hit it. A server listening on 127.0.0.1 refuses a connection to 127.0.0.2 even where the operating system considers both perfectly valid local addresses.
Two different rules about the wire
Host behaviour and router behaviour are set by different documents with different force, and they are frequently merged into one overstated sentence.
For hosts, RFC 1122 is absolute: addresses of this form MUST NOT appear outside a host. For routers, RFC 1812 is deliberately softer — a router "SHOULD NOT forward, except over a loopback interface, any packet that has a source address on network 127", with the same wording for destination addresses, and it explicitly permits a switch to disable the check so long as the default leaves it on.
Writing that routers must not forward 127-block traffic upgrades a SHOULD NOT into a MUST NOT, and the exception for the loopback interface is exactly why the standard could not use the stronger word.
IPv6 made the opposite choice
The contrast is the sharpest argument that 16.7 million was never needed. IPv6 has vastly more address space and allocates exactly one loopback address:
"The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. It may be used by a node to send an IPv6 packet to itself. It must not be assigned to any physical interface."
That is ::1/128 — a single address where IPv4 set aside one two-hundred-and-fifty-sixth of its entire space. One note for anyone quoting the two side by side: RFC 1122's prohibition is written in capitals and RFC 4291's is not. The IPv6 document carries no RFC 2119 boilerplate and uses lowercase "must not" throughout, so rendering it in capitals would quietly strengthen the citation.
The proposals to reclaim it have lapsed
A group of engineers spent four years trying to hand most of the block back. The draft on 127/8 was revised roughly every six months from November 2021 through June 2025, alongside companion drafts on 0/8, 240/4 and the lowest address in a subnet.
All of them expired on 25 December 2025 and none was ever adopted by an IETF working group. The datatracker says so in its own words: an Internet-Draft is "not endorsed by the IETF and has no formal standing in the IETF standards process". After four years of punctual revisions, the authors let this one lapse, and nothing has replaced it.
The proposal was also narrower than its reputation. It would have kept 127.0.0.0/16 — 65,536 addresses — for loopback, and freed everything from 127.1.0.0 upward for ordinary unicast use.
Neighbouring traps
0.0.0.0/8 is reserved as "this host on this network", but it is not simply forbidden: it is legitimately used as a source address while a host is learning its own address over DHCP. 240.0.0.0/4 remains reserved, under RFC 1112 rather than RFC 1122, and is still marked reserved in the current registry.
As for the name, RFC 6761 requires resolvers to treat localhost as special and to answer it without consulting DNS — but it never names an address. The specification says "the respective IP loopback address" and leaves it there, which is why a dual-stack machine resolving localhost to ::1 rather than 127.0.0.1 is behaving correctly.
What to do with it
Running several local services on distinct addresses in the block is a genuinely useful trick on Linux, and one worth testing before relying on it anywhere else, since the same script will fail on a colleague's Mac with an error that looks like a permissions problem.
Binding a service to 127.0.0.1 keeps it off the network because the address itself is non-routable, not because the socket API is enforcing a policy. Anything already on the machine — another user, a container sharing the network namespace, a forwarded port — still reaches it.
Where this comes from
The reservation is RFC 1122 section 3.2.1.3 and the current IANA IPv4 special-purpose registry, whose entry for the block was last revised in October 2025. The forwarding rule is RFC 1812 section 5.3.7, the IPv6 loopback RFC 4291 section 2.5.3, and the localhost rules RFC 6761 section 6.3. The reclamation work is draft-schoen-intarea-unicast-127, revision 08, and its companion drafts, all read from the IETF datatracker on 18 September 2026.
The operating-system behaviour was measured rather than looked up: bind and ping tests against 127.0.0.1, 127.0.0.2 and 127.9.9.9 on Linux 6.12 and on macOS 25.6, plus a connection test proving a listener on one address refuses another.
View author profile → · Editorial policy
