Summary

  • RFC 1955's ENCAPS proposal asked entrance and exit border routers to add and remove an autonomous-domain IP header, allowing ordinary transit routers to route the wrapper while the original datagram and its addresses remained unchanged.
  • “No changes to hosts” did not mean no migration cost. DNS needed an AD-address record for each name, border routers needed new lookup and encapsulation behavior, AD addresses needed allocation, and each transit packet acquired a 20-byte outer header.
  • The memo was Informational, said publication did not imply IPng acceptance, assumed globally unique inner IPv4 addresses, and did not discuss security. It records a design choice, not a deployment receipt.

The packet kept its old address

Consider a packet at the entrance to another routing domain. Its source and destination already mean something to the sending host. RFC 1955 did not ask the border to erase either value. Instead, the entrance border would look up a second pair of addresses, place them in another IP header, and send the wrapped datagram across the inter-domain system. The exit border would remove the new header and expose the original packet again.

The distinction was deliberate. The proposal's list of benefits included “no translation of addresses in packets.” Its compatibility bargain was not that every layer would stay the same. It was that the installed hosts and most routers could keep speaking the same language while a smaller set of boundary machines carried the transition.

This is why the proposal deserves attention even though it was not accepted as an Internet architecture. It makes migration cost visible as a location problem. The cost did not vanish. It moved from the population of hosts into DNS mappings, border processing, autonomous-domain identifiers, routing abstractions and an extra header on every wrapped packet.

RFC 1955 was published in June 1996, but it says the design had been offered to the ROAD group in January 1992 and first circulated as an email. The document was later submitted in response to the IPng white-paper process. Its own warning is decisive: publication did not imply that the IPng area accepted any of its ideas. The RFC is an archival window into a choice under pressure, not proof that the choice won.

A medium-term answer to two clocks

The early-1990s routing debate ran on more than one clock. Class B numbers were being consumed poorly. Routing tables and the human work of controlling them were growing. Eventual exhaustion of the 32-bit space remained a different, longer problem. A design that solved everything too late could still lose the network to the nearer constraint.

The ROAD account separated immediate, short-, medium- and long-term work and insisted that the phases begin in parallel. Short-term measures could not require host changes. Long-term work could consider a new Internet layer, but its transition across a large installed base would be difficult. RFC 1955 adopted this sense of time explicitly. It called ENCAPS a medium-term measure meant to keep the Internet going while longer-term candidates were designed and deployed.

That claim was modest in one respect and ambitious in another. ENCAPS did not promise new guarantees of bandwidth or delay, and it admitted that its initial form imposed limits. But it advertised an unusually broad compatibility surface: no changes to hosts, no changes to most routers, no new Internet protocol, no new routing protocol, continued use of IPv4 addresses, and smaller routing tables.

The advertised list should not be read as an observed result. It was a design target. No implementation record, packet trace, measured table reduction or interoperability report appears in the frozen evidence. Running code would have had to prove each advantage independently.

The border constructed another destination

ENCAPS proposed routing between autonomous domains by routing on autonomous-domain addresses. When an entrance border received an ordinary datagram, it would examine the source and destination and query DNS for the corresponding AD addresses. Those addresses became the source and destination of a new outer IP header.

The original datagram was now payload. Between boundaries, the network could select a route from the wrapper. At the final border, the wrapper disappeared and the original destination again governed forwarding.

The proposal suggested reserving a small number of Class A and Class B network numbers for AD addresses. The network-number portion would identify the value as an AD identifier; the local part would select the particular AD. More than one reserved network could organize ADs into what the memo called commonwealths. A commonwealth would need detailed knowledge of its own ADs, while other commonwealths could appear in more aggregated form.

This was not merely packet formatting. Border routers would inject suitable AD addresses into the intra-domain routing of transit domains. Ordinary routers could then forward the outer headers without knowing that they were special. BGP, IS-IS or OSPF might calculate routes among borders. The scheme reduced the number of modified devices by making the new abstraction look ordinary to the devices in between.

The mechanism therefore depended on two compatible beliefs. DNS had to map a name to the right AD address, and routing had to carry that AD address to the right exit. A correct mapping with no usable route was insufficient. A route to an AD address with the wrong mapping was also insufficient. The wrapper joined records from two systems, and the exit boundary had to agree with both.

No translation was still a stateful choice

The contrast with address translation matters. A translator replaces an address in the packet and must repair consequences of that edit: checksums, embedded addresses, application protocols and sometimes synchronized tables at several exits. Encryption can make payload rewriting impossible. RFC 1955 avoided those specific transformations by preserving the inner packet.

But preservation did not make the border stateless. The entrance still needed a name-to-AD result. The network still needed allocated AD identifiers and routes. The exit still needed to recognize itself as the correct place to remove the wrapper. Operational evidence still had to distinguish a DNS answer, a constructed header, a forwarded wrapper, a successful de-encapsulation and a delivered application message.

The design also retained a foundational assumption: the original IPv4 addresses could remain globally unique for a long time. RFC 1955 mentioned a possible future in which the combination of AD address and inner IP address supplied global uniqueness. Yet avoiding host changes in that version would require NAT at the border, precisely the transformation the initial proposal had advertised away. Alternatively, hosts themselves could learn the AD mapping and construct the wrapper, but then the no-host-change bargain would end.

This is a useful form of architectural honesty. Every extension crosses one of the original boundaries. Either global uniqueness remains, the border translates, or the host changes. A design can postpone a trade. It cannot make the trade disappear.

Twenty bytes were only the visible price

RFC 1955 named the added bandwidth cost: another 20-byte IP header for traffic crossing the transit network. It also named extra processing at the entrance and exit borders. Those costs are easy to draw because they sit in the packet and on two machines.

The harder costs were control-plane obligations. DNS needed a new AD-address entry for every name. Border routers needed lookup, header construction and removal, and an inter-AD routing procedure. Operators needed a coherent allocation plan for AD addresses and their commonwealths. Failures needed attribution across inner and outer routes.

The memo did not specify cache lifetime, negative lookup behavior, authentication of the new DNS data, failure behavior when only one border had changed, MTU discovery, detailed fragmentation rules, ICMP attribution or a migration exit. It did not discuss security. These omissions do not prove that the design was bad. They show why a proposal and an operating system are different evidence objects.

Later IP-within-IP specifications define many wrapper mechanics more fully. The first IPv6 specification records the eventual IPng result. Neither fact allows a straight line to be drawn from ENCAPS to those systems. The careful comparison is structural: all transition mechanisms must decide who adds state, who removes it, how failures are observed, what the unchanged layer still guarantees, and when the compatibility layer may be retired.

CIDR bought time differently

ENCAPS should also be separated from CIDR. CIDR attacked routing growth by changing address allocation and allowing aggregates to be carried with masks. Its cost appeared in allocation policy, routing-protocol capability, provider attachment and the pressure to renumber for better aggregation. It did not add an AD wrapper to every inter-domain packet.

Both designs were responses to the same urgency and both described themselves as bridges to a longer-term architecture. They placed the bridge in different locations. CIDR made the visible address hierarchy carry routing aggregation. ENCAPS proposed a second address hierarchy outside the existing packet. One altered how routes over existing addresses were summarized; the other tried to let the old destination ride inside a new inter-domain destination.

The comparison is valuable precisely because the mechanisms are not interchangeable. “Aggregation” is not a single engineering act. It can be paid for by address holders, providers, routing tables, mapping systems, packet headers or boundary devices. The word reveals little until the payer and the reversible boundary are named.

The meaning of a proposal that did not become the system

Heng Lu's running-code principle prevents a document from impersonating deployment. RFC 1955 proves that a particular transition was described. A DNS record would prove that one mapping was configured. A border configuration would prove readiness. A packet capture with an outer header would prove emission at one observation point. None alone proves correct arrival, de-encapsulation, inner forwarding or application receipt.

The minimum-initial-specification lens asks how much shared machinery was truly necessary. ENCAPS attempted to keep hosts and most routers outside the change set. That was a form of localized future decision: concentrate the experiment at participating boundaries. Yet the shared DNS mapping and AD-address plan could still thicken into a new coordination layer. Local deployment remains local only if non-participating paths, fallback and withdrawal remain executable.

The reality-layer lens then separates the objects. An AD number written in a document is a proposed symbol. A DNS entry is configured belief. An outer header is a packet-level act. A border's de-encapsulation is local execution. A delivered service is a further result. Treating any earlier layer as proof of the next would turn a transition diagram into a false receipt.

RFC 1955 did not become the Internet's long-term answer. That makes it more useful, not less, for understanding transition architecture. It shows the discipline required before saying that a compatibility layer is cheap: count the systems that do not change, then count the state that moved somewhere else.

Sources and boundaries

The document's identity and status are in the RFC Editor record for RFC 1955, while the mechanism and its disclaimers are in RFC 1955. The routing crisis and phased response are bounded by RFC 1380, and the later submission context by the IPng white-paper solicitation. The separate short-term aggregation strategy is RFC 1519 on CIDR. The contemporary translation comparison comes from RFC 1631. Later outcomes are bounded, without claiming descent, by the first IPv6 specification and IP within IP. The analytical frame comes from Running-Code Primacy, Minimum Initial Specification and Reality Layers.

These sources establish the written proposal and bounded comparisons. They do not establish IPng acceptance, standardization, implementation, deployment, adoption, performance, interoperability, security, a named operator, a packet trace, a present product or a causal lineage into later protocols.