Summary

  • RFC 1918 reserved three reusable IPv4 blocks and made their addresses unique only inside one enterprise or a cooperating set. Both of two isolated networks could therefore use the same number correctly.
  • The document explicitly priced that freedom: if private internets later merged or established connectivity, duplicate addresses could require renumbering. Routing, DNS, translation and authentication solved different parts of the resulting problem.
  • Later RFCs named the missing context an address realm, described translation across realm boundaries and showed how a packet can be delivered successfully to the wrong local host. Reachability is not endpoint identity.

The first cable changes the meaning

Imagine two diagrams on separate walls. On the left, 10.1.1.10 identifies a payroll server. On the right, the same number identifies a print server. Each route table has one unambiguous next hop. Each local resolver returns a useful answer. No central registry has made a duplicate assignment error, because neither organization needed a registry assignment for that number.

Now connect the diagrams. A router receiving a packet for 10.1.1.10 cannot infer which biography the sender intended. The collision is not created by a corrupt octet or an unauthorized claim. It is created by a change in the set of systems expected to communicate. Yesterday the full identifier was effectively “this address inside the left enterprise.” Today the enterprise qualifier is no longer supplied by separation.

That is the operational bargain behind RFC 1918. The bargain is more interesting than the familiar ranges because it exposes the exact function of uniqueness. A number need not be unique everywhere to be useful somewhere. But reuse works only while every decision surface preserves the scope that disambiguates it.

The objection arrived before the best practice

The first allocation appeared in March 1994. RFC 1597 divided enterprise hosts by connectivity need and reserved address space that could be reused by private networks. It responded to a practical asymmetry: many machines used TCP/IP internally but did not need direct network-layer access outside their organization. Giving every such machine a globally unique number consumed a global resource to solve a local naming problem.

Four months later, RFC 1627 objected. Its authors defended the architectural value of global uniqueness and argued that today's isolated machine could become tomorrow's collaborator. Two private networks might connect; companies might merge; a service might acquire an external audience. The critique treated renumbering as more than a DHCP event. Known services, software licences and embedded assumptions could attach to an address. It even offered an Apple renumbering example, although this source packet does not independently verify the stated host count or cost.

The dissent matters because the collision was not a surprise discovered years after deployment. It was visible in the design debate. More strikingly, Eliot Lear co-authored both the critique and the 1996 replacement. RFC 1918, issued as BCP 5, did not erase the objection. It kept the reuse model and wrote its cost into the best practice.

Three blocks, one boundary condition

RFC 1918 reserved 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. An enterprise could use them without coordination with IANA or an Internet registry. Many enterprises could do the same. The governing sentence was not merely that the blocks were “private”; their addresses would be unique only within an enterprise or within a set of enterprises cooperating over that space.

The current IANA special-purpose registry still calls all three Private-Use and marks them not Globally Reachable. That status is often read as a property of the digits. Operationally, it is a rule about boundaries. RFC 1918 said private routes must not propagate across inter-enterprise links, packets carrying private sources or destinations should not cross those links, and indirect references such as DNS records should remain contained. A private number remains useful when route and name distribution preserve the same perimeter as the address plan.

The memo also declined a popular shortcut. Its security section said security issues were not addressed. Private addressing may coexist with filtering or application gateways, but the absence of a global route is not an authentication proof and RFC 1918 did not advertise the ranges as a security system.

The merger clause is the price tag

The disadvantages section is unusually candid. If several uncoordinated private internets merge into one, some addresses may no longer be unique and affected hosts may need renumbering. A second warning covers organizations that later establish IP connectivity with one another. Randomly selecting internal sub-blocks was recommended to reduce collision risk, not to certify that a collision could never occur.

This is a choice about when coordination cost is paid. Global allocation pays before use: obtain a unique number and preserve it across the communicating population. Private reuse defers that cost: deploy locally without external coordination, then reconcile only if the population expands. The initial administrator receives speed and address abundance. A future integration team receives an option whose exercise price is unknown.

Neither organization owns 10/8 against the other. Both followed a scheme designed for reuse. Asking which side has the “real” private address therefore mistakes a scoping rule for a title system. The practical questions are different: which realm can be renumbered, which dependencies can be found, which applications can tolerate translation, which services need stable identities, and who bears the interruption risk?

An address realm makes the hidden coordinate visible

RFC 2663 later supplied useful vocabulary. An address realm is a network domain in which addresses are uniquely assigned and routable. Traditional NAT joins unlike realms by rewriting addresses, but it assumes that the private and external spaces do not overlap. When the same address has meaning on both sides, ordinary one-sided translation is insufficient; the document describes twice NAT, in which source and destination can both be changed.

That terminology reveals why “just add a route” fails. A route selects a path for a destination as represented in one forwarding table. It cannot carry two incompatible meanings for the same prefix without some additional context—another table, a tunnel, policy separation, translation or renumbering. The missing fact is not reachability in the abstract. It is the realm in which the destination name is supposed to resolve.

RFC 3022 made the trade more concrete. Basic NAT maps one address set to another; NAPT includes transport identifiers. Sessions must traverse compatible translation state, and rerouted flows may fail if that state is absent. The technique can preserve local numbering while providing selected external connectivity, yet the RFC notes that translation removes the end-to-end significance of an IP address and replaces it with more state in the network.

Translation is therefore a remedy for a boundary, not a declaration that duplicate private addresses have become globally unique. The map itself becomes operational evidence: which inside host corresponded to which outside representation, at what time, for which protocol and through which device?

A green path can reach the wrong machine

RFC 5684, an Independent Submission rather than an IETF Standards Track specification, later examined overlapping private space in nested NAT and remote-access VPN topologies. One of its most useful phrases is “mistaken end host identity.” In its examples, a private address advertised for an upstream resolver can instead land on a same-numbered local host. A split VPN can expose a similar confusion between a corporate service and a service at the remote site.

The packet was not necessarily dropped. That is what makes the failure dangerous. A connectivity test may turn green because a host answered. The operational question is whether the intended host answered. RFC 5684's deployment-specific recommendations include non-overlapping or global addresses for critical advertised services, and end-to-end authentication rather than trust in source IP alone.

This separates five receipts that are often collapsed. An address assignment says which number was configured within a scope. A route says where a forwarding decision sent the packet. A translation record says how one representation became another. A credential can authenticate a peer. An application observation says whether the intended service completed. None silently proves the other four.

Shared address space repeated the lesson with a different perimeter

In 2012, RFC 6598 created 100.64.0.0/10 for Shared Address Space between service-provider CGN equipment and customer premises. It explicitly distinguished this provider use from RFC 1918 enterprise private space. Both appear in today's IANA registry as special-purpose and not globally reachable, but they are not interchangeable pools. Their intended administrative domains differ.

The distinction reinforces the historical point. “Not globally reachable” does not describe one undifferentiated nowhere. A home realm, an enterprise realm and a provider sharing realm have different operators, routes, naming practices and collision surfaces. Reuse remains safe only when the relevant scope travels with the decision.

RFC 1918 succeeded partly because it made local deployment cheap and ordinary. Its price was not hidden, however. The document told readers that connectivity requirements change, companies merge and addresses that were once unambiguous may cease to be so. The durable lesson is not to abolish local addressing or to pretend every internal machine needs public identity. It is to remember what the boundary was doing. When the wall comes down, the address needs another coordinate—or another address.

Sources