Summary

  • RFC 1335 proposed that every host keep a permanent, network-local address while obtaining a globally unique external address temporarily from an External Address Sharing Service (EASS).
  • This was an informational “idea” paper, not a deployment record: it makes a distinct allocation proposal, but the available evidence does not show that operators implemented it or that it solved IPv4 exhaustion.

The usual mental picture of an Internet address is a label attached to a machine. RFC 1335 asks whether that label needs to be global all the time. Its answer, written amid early-1990s concern about the 32-bit address space, was to separate the address useful inside a network from the scarce address needed to communicate beyond it.

The memo is unusually candid about its status. Dated May 1992, it identifies itself as informational, says it does not specify an Internet standard, calls itself an “idea” paper, and invites discussion. That matters: its design is evidence of what one proposal considered possible, not evidence of a service in operation. RFC 1335

Its pressure came from the classful allocation system as the authors described it. A table labeled April 1992 counted 7,006 allocated Class B networks out of 16,383 and warned that B space might soon run out if growth continued. Class C offered many more network numbers, but only 254 host numbers per network—too small for most networks in the memo's judgment. These are the document's contemporary counts and forecast, not a retrospective measurement of when exhaustion occurred.

RFC 1335 contrasted its proposal with approaches then under discussion. Supernetting and what it called C-sharp would reorganize Class C allocations, but the memo argued they would require changes to exterior routing and potentially coordination across the Internet. Other proposals reused the 32-bit field with a different meaning and boundary rewriting, which the authors thought would demand substantial gateway and routing changes. Those are the memo's characterization of alternatives, not a neutral evaluation of every proposal.

Dual Network Addressing (DNA) split the job in two. Each machine would retain an internal address, unique within its own network, as its permanent address there. A network would also hold a limited pool of globally unique external addresses. When a host needed to contact another network, it could ask that network's External Address Sharing Service for a temporary external address and return it afterward. In this account, the EASS was an administrative and technical allocation point between local use and global reachability—not a claim that an address authenticates a person, host, or transaction.

The policy was not simply “everyone shares.” RFC 1335 described three classes: machines needing frequent inbound and outbound communication could receive permanent external addresses; machines barred from outside communication would receive none; and other machines could share temporary addresses for client-initiated communication, without being callable from outside under the proposal. The distinctions make allocation a question of operating policy as much as packet format.

To make the proposal work, hosts would need software changes supporting two logical IP interfaces or addresses on one physical interface. The memo also proposed source-sensitive DNS behavior: a name server could return an internal or external address depending on where a query came from. It suggested DHCP might provide the EASS function. That sentence is a design suggestion, not evidence that DHCP deployed DNA or that the two systems became one lineage.

This bottom-up adoption claim is the most interesting governance feature. RFC 1335 argued that networks could adopt DNA at different times without changing exterior-routing algorithms or affecting networks that did not adopt it. The paper thus moved the proposed intervention inward—from global routing coordination toward local address pools, host software, and network policy. But the document supplies no operator deployment record, interoperability test, traffic observation, or adoption count with which to verify that promise.

Later documents mark useful boundaries, not a proven succession. RFCs 1518 and 1519 made CIDR a standards-track strategy for address allocation and route aggregation; CIDR operates at prefix and routing scale, unlike DNA's internal addresses and temporary pool. RFC 1531 later specified DHCP as a configuration framework that included reusable address allocation; that does not show EASS was implemented. RFC 1631 described Network Address Translation at a border, a bounded comparison to address rewriting but not proof that DNA caused NAT. And RFC 1752 records an IESG-accepted IPng recommendation—an institutional decision unlike RFC 1335's open idea paper. RFC 1287 · RFC 1518 · RFC 1519 · RFC 1531 · RFC 1631 · RFC 1752

RFC 1335 therefore gives historians a clean separation between proposal and outcome. It shows that address scarcity could be approached by changing who receives a globally unique number, for how long, and under whose local policy—not only by enlarging or reorganizing the global routing system. It does not tell us that this arrangement was deployed, secure, interoperable, or successful. The memo itself says security issues are not discussed. A temporary address can be an allocation mechanism; it is not identity, permission, proof of reachability, or proof that an application exchange completed.