Summary

  • TUBA kept TCP, UDP and many Internet applications above the network layer, but proposed replacing IPv4 with CLNP and its structured NSAP addresses.
  • Its transition depended on more than router support: hosts, DNS records, embedded IPv4 assumptions, route aggregation and authority to change CLNP all mattered.

What stayed, and what moved

In June 1992, Ross Callon’s RFC 1347 offered a long-term answer to two linked pressures: 32-bit IPv4 addresses were becoming scarce, while backbone routing tables were growing quickly. The memo called its proposal TUBA, “TCP and UDP with Bigger Addresses.” It did not propose enlarging IPv4 itself. It proposed a different network layer: keep the familiar applications and transports, run TCP or UDP over the ISO Connectionless Network Protocol (CLNP), and use Network Service Access Point (NSAP) addresses in place of IP addresses.

The name described what would remain visible to applications, not what routers would carry. A browser, mail program or file-transfer program could continue to use TCP or UDP if it did not depend on a 32-bit address inside its own protocol. Below those transports, however, packet format, addressing and forwarding would change. Callon argued that implementing and deploying a completely new network protocol would take time and effort, while CLNP already offered a connectionless datagram service and was present in some Internet backbones and regional networks. Reuse seemed to reduce the amount of new machinery to build.

That was not a wholesale conversion to OSI. TUBA’s claim was narrower: replace IP, leave TCP and UDP in place, and avoid requiring OSI applications or transports. RFC 1561, an Experimental memo published in December 1993, then specified a CLNP profile for the TUBA environment. It also acknowledged that CLNP and IP were similar in service rather than identical in detail; the profile had to preserve meanings expected by Internet protocols.

The migration lived at the edges too

RFC 1347 sketched old and upgraded hosts operating side by side. An upgraded host could ask DNS for an ordinary IP address and use the old stack, or receive a longer NSAP address and send TCP or UDP over CLNP. DNS therefore needed a new long-address record. Routers had to forward both IP and CLNP, either through multiprotocol devices or separate router sets. The proposal did not require each packet to be translated or tunneled between the two protocols; the address returned by name lookup selected which network layer to use.

This design made incremental operation possible, but it did not erase dependencies. A host could support TUBA while sitting in an IP-only network. An application that copied IPv4 literals into a message, as some FTP and NFS uses did, could not remain unchanged merely because TCP still existed. DNS operators, host implementers and network operators each had a part of the transition. A larger address field also did not guarantee efficient routing: the hierarchy in NSAP assignments had to reflect topology closely enough for routers to aggregate routes.

The proposal’s attractive deployment argument was that CLNP-capable routers already existed. By January 1995, however, RFC 1752 recorded a gap between that claim and end-to-end readiness. Reviewers saw significant CLNP-capable router deployment, but agreed less that many hosts or actual networks ran CLNP. A device able to forward a protocol was useful infrastructure; it was not proof that applications could reach one another over that protocol.

The borrowed protocol had an owner

Reuse carried a governance question inside the technical design. RFC 1752 lists concerns about CLNP’s header alignment, source-route behavior, error messages and other fields. Some parts might need adjustment. Yet TUBA participants disagreed over whether the IETF could modify the base CLNP specifications or whether changes had to pass through ISO. For an Internet effort to depend on a protocol whose future edits might be controlled elsewhere was more than a paperwork issue: it affected how quickly defects could be fixed and who could define the interoperable profile.

The final IPng recommendation did not make TUBA irrelevant. RFC 1752 recommended the revised SIPP protocol as the basis for IPng after extensive discussion. It also describes a synthesis: SIPP supplied much of the base protocol, while TUBA influenced autoconfiguration and transition work. That is a more accurate ending than calling TUBA simply a failed alternative. Its approach preserved parts of the Internet stack and contributed ideas even though CLNP did not become the new Internet layer.

Heng Lu’s later Note:64 offers a useful retrospective lens, not evidence about the 1990s: separate the minimum rules participants need to interoperate, choices implementers can make locally, and adoption demonstrated in running systems. TUBA’s history puts pressure on all three questions. Reusing a protocol can reduce invention, but interoperability still depends on who can change it, which end systems implement it, and whether operators choose to carry it.

Sources