RFC 1918: Private IPv4 Addressing Was an Allocation Policy, Not a Firewall

The address 192.168.1.10 appears in home routers, labs, and company networks, but “private IP” is often used as shorthand for several different things: an address that is not globally unique, one that cannot be routed on the public Internet, one translated by NAT, and one protected by a firewall. Those are related operationally, not interchangeable definitions. The history of RFC 1918 is more precise: it established a shared IPv4 allocation policy for networks whose hosts did not need globally unique addresses. It did not itself translate packets, filter traffic, authenticate users, or encrypt connections.

The policy took shape alongside two pressures in the early 1990s: more organizations were using TCP/IP internally, while Internet operators worried about both finite IPv4 space and the growth of routing information. RFC 1597 described private allocation in March 1994. RFC 1631 proposed Network Address Translation two months later. RFC 1918, published in February 1996 as Best Current Practice 5, replaced RFC 1597 and RFC 1627. The dates place these proposals in the same debate, but chronology alone does not establish that one mechanism caused the other.

RFC 1597 made address uniqueness a design choice

RFC 1597 began from an observation that seems ordinary now: many organizations were using TCP/IP without needing every internal machine to communicate directly with every host on the Internet. The existing habit of assigning globally unique addresses to all IP hosts consumed address space even when global uniqueness added no value. The memo proposed that an enterprise could use a designated pool for such internal hosts without requesting a separate allocation for each network.

Its model separated hosts by connectivity need. One group needed only enterprise-local communication. Another group needed selected outside services, including email, FTP, netnews, and remote login, which could be reached through application-layer gateways. Only the third group needed network-layer access beyond the enterprise and therefore globally unambiguous addresses. In this model, “private” described where an address had to be unique and what kind of outside connectivity a host required. It was not a synonym for “safe.”

RFC 1597 named three pools, using the then-common classful terminology: 10.0.0.0 through 10.255.255.255, 172.16.0.0 through 172.31.255.255, and 192.168.0.0 through 192.168.255.255. In today’s CIDR notation these are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Notice the middle boundary: it is only 172.16 through 172.31, not the whole 172.0.0.0/8 range.

The pool could be reused by many independent enterprises. That was the point, but also the limit: an address from it was unique only inside one enterprise, or among organizations that deliberately coordinated a shared private network. No registry check prevented two unrelated sites from choosing the same subnet. For hosts that needed outside services without general IP reachability, the 1994 memo described application relays. Those relays were a design option; the address assignment itself did not create them.

NAT was a neighboring mechanism, not the definition

RFC 1631, The IP Network Address Translator, appeared in May 1994. It proposed a border router that maps local addresses to globally unique addresses, using a translation table. The memo framed this as address reuse for stub domains: only a subset of internal hosts might need an externally unique address at a given time. It described NAT as a preliminary design that could be installed without changing the hosts or other routers, while also listing costs such as extra network state, broken applications, and loss of end-to-end address significance.

The distinction matters. Private addressing answers, “Which hosts need globally unique numbers?” NAT answers, “How can a border device rewrite packet addresses between an internal network and another network?” An enterprise can have private addresses without NAT, for example on a network with no external IP connection or one that offers selected applications through proxies. Conversely, translation is a configured network function, not an automatic property of choosing a private prefix. RFC 1631 cites RFC 1597, evidence that the proposals were part of the same contemporary discussion, but it does not make RFC 1918 a NAT specification.

RFC 1918 widened the routing argument

RFC 1918 retained the allocation idea and made the routing context more explicit. Its motivation did not reduce to “IPv4 addresses were running out.” The document described address scarcity, but called growth in routing overhead a separate and more pressing concern for Internet service providers. CIDR and provider-based address aggregation were part of the backdrop: customers might use a provider’s block to make routes aggregatable, and changing providers could require renumbering even when an organization already had globally unique addresses.

The 1996 document formalized the same three connectivity categories and the same exact private ranges. It was a Best Current Practice, not an Internet Standard, and its header says it obsoletes RFC 1597 and RFC 1627. It also made operational costs plain. Hosts moved from private to public addressing would need renumbering, DNS and configuration references could need changes, and two organizations that later merged their private networks could discover that both had used the same addresses. DHCP was named as one possible aid to renumbering, not as a way to make overlapping networks unique automatically.

RFC 1918 also treated containment as an operational responsibility. Because the addresses had no global meaning, it says routing information about private networks shall not be propagated across inter-enterprise links, while packets bearing private source or destination addresses should not be forwarded across those links. Operators should filter routing and packet leakage, and the document discusses keeping private DNS data out of public views. Those are instructions for network operation around the allocation scheme; they are not packet-filtering behavior supplied by the prefix itself.

Reuse makes overlap a real integration problem

Imagine two independent companies that each assign 10.20.0.0/16 to office devices. While the networks are isolated, the same numerical addresses can work because neither company needs to distinguish the other company’s hosts. If the companies later connect their networks, a packet destined for 10.20.0.25 is ambiguous unless the networks are coordinated or one side is translated or renumbered. This is an illustrative consequence of reuse, not a historical case study.

RFC 1918 explicitly called out this merger problem. Its recommended directions included planning subnets around similar connectivity needs, filtering private routes at network boundaries, and considering renumbering where private networks were joined. A VPN or tunnel can carry traffic between sites, but encapsulation does not resolve overlapping inner address plans by itself. Nor does an address being in an RFC 1918 range tell an operator which organization, device, or person is using it.

What “private” means in a current configuration

The current IANA IPv4 Address Space Registry continues to identify 10/8, 172.16/12, and 192.168/16 as reserved for private-use networks under RFC 1918. The exact prefix is important: neighboring space is not automatically part of the same reservation. The term “private” here is about allocation and global uniqueness, not a universal guarantee that packets cannot leave a local segment.

A private address can be routed within an enterprise, across a deliberately connected private network, or inside a tunnel. At a boundary, route policy, packet filters, application gateways, and NAT determine what is actually forwarded or translated. Those mechanisms can be configured incorrectly. The older RFC 1597 explicitly warned that private addressing could improve security but was not a substitute for dedicated security measures; RFC 1918’s security-considerations section says security issues are not addressed in that memo. Neither source defines an address as proof of identity, authorization, confidentiality, or trust.

When diagnosing a “private IP” claim, check the boundaries separately:

Confirm that the address falls within one of the three exact prefixes; a hostname, 172.* string, or locally assigned label is not enough.
Inspect the route lookup in the relevant routing table or network namespace. A prefix’s classification does not tell you which interface or next hop the local system will select.
Review the boundary’s firewall and forwarding policy independently from any NAT rules. Translation changes addressing; it is not, by itself, a complete access-control policy.
Check what routes and DNS answers cross the boundary. RFC 1918 specifically warns about leaking private routes and references to private addresses.
Before joining VPN, cloud, or merger networks, compare their actual subnets for overlap and decide whether coordination, translation, or renumbering is required.

These checks follow the original distinction between an allocation decision and the mechanisms that connect networks. They do not make every present-day network behave like the 1996 architecture; they keep the historical term from hiding the routing and security decisions an operator still has to make.

RFC 1918 endured because its compact policy made local IPv4 growth practical without pretending that every host needed a globally unique number. Its limits were present in the original documents too: reuse permits collisions, network boundaries need explicit treatment, and changing connectivity can require renumbering. The best summary is not “private addresses are protected.” It is that these three prefixes are deliberately reusable, and the network must supply the routing, translation, and security behavior around them.

Related:

Sources: