Zusammenfassung

  • TUBA sollte TCP, UDP und viele Internetanwendungen erhalten, IPv4 aber durch CLNP und strukturierte NSAP-Adressen ersetzen.
  • Für den Umstieg brauchte es mehr als CLNP-fähige Router: Hosts, DNS, Anwendungen mit eingebetteten IPv4-Adressen, Routenaggregation und die Zuständigkeit für Änderungen an CLNP waren ebenfalls entscheidend.

Vertraute Transporte, eine andere Netzwerkschicht

Im Juni 1992 veröffentlichte Ross Callon RFC 1347 mit dem Vorschlag TUBA, „TCP and UDP with Bigger Addresses“. Der Text beschrieb zwei zusammenhängende Probleme: Der IPv4-Adressraum mit 32 Bit wurde knapp, während die Routinginformationen in den Netzkernen rasch zunahmen. TUBA vergrößerte nicht das IPv4-Feld. Der Vorschlag ersetzte die Netzwerkschicht: TCP oder UDP sollten über CLNP laufen, dem verbindungslosen Netzwerkprotokoll der ISO-Architektur; NSAP-Adressen sollten IP-Adressen ablösen.

Die Bezeichnung machte sichtbar, was erhalten bleiben konnte, aber nicht, wie viel sich darunter änderte. Browser, Mailprogramme und Dateiübertragungen konnten TCP oder UDP weiterverwenden, sofern ihre eigenen Protokolle nicht auf 32-Bit-IP-Adressen angewiesen waren. Die transportierten Pakete hätten jedoch ein anderes Format und eine andere Adressierung gehabt. Callon verwies darauf, dass CLNP bereits einen Datagrammdienst bot und in Teilen der Internet-Backbones und regionaler Netze eingesetzt wurde. Vorhandene Technik wiederzuverwenden sollte den Aufwand verringern, eine neue Netzwerkschicht zu entwerfen, zu testen und auszurollen.

TUBA verlangte keine vollständige Umstellung auf OSI. Der engere Plan war, IP zu ersetzen und TCP sowie UDP zu behalten. Das im Dezember 1993 veröffentlichte experimentelle RFC 1561 legte dafür ein CLNP-Profil fest. Es hielt zugleich fest, dass CLNP und IP ähnliche, aber nicht identische Dienste anbieten; die erwartete Bedeutung bestimmter Internetprotokoll-Informationen musste erhalten bleiben.

DNS entschied mit über die Netzwerkschicht

RFC 1347 entwarf ein schrittweises Nebeneinander alter und aktualisierter Hosts. Fragte ein neuer Host DNS nach einem alten Ziel und erhielt eine gewöhnliche IP-Adresse, nutzte er den bisherigen Stack. Erhielt er für einen TUBA-fähigen Partner eine längere NSAP-Adresse, lief TCP oder UDP über CLNP. Dafür brauchte DNS einen neuen „long-address“-Eintrag. Router mussten IP- und CLNP-Pakete unabhängig weiterleiten, entweder in Mehrprotokollgeräten oder auf getrennten Routergruppen. Die DNS-Antwort wählte den Netzwerkpfad; eine Übersetzung oder ein Tunnel für jedes Paket war nicht Teil des bevorzugten Weges.

Ein inkrementeller Start beseitigte die Abhängigkeiten nicht. Ein aktualisierter Host konnte weiterhin an einem Netz ohne CLNP-Dienst hängen. Manche FTP- und NFS-Anwendungen übertrugen IP-Adressen in ihren Nutzdaten und mussten daher angepasst werden, auch wenn TCP blieb. Hostentwickler, DNS-Betreiber und Netzanbieter mussten ihre Schritte koordinieren. Längere Adressen allein sorgten auch nicht für kompakte Routingtabellen: NSAP-Zuteilungen mussten die Netzstruktur abbilden, damit sich Routen zusammenfassen ließen.

Ein Argument für TUBA war die bereits vorhandene Unterstützung von CLNP in Routern. Die Bewertung in RFC 1752 vom Januar 1995 unterschied zwischen Routerkapazität und Ende-zu-Ende-Betrieb. Die Gutachter sahen eine bedeutende Verbreitung CLNP-fähiger Router, waren sich bei CLNP-fähigen Hosts und tatsächlich mit CLNP betriebenen Netzen aber deutlich weniger einig. Ein Router, der Pakete weiterleiten kann, ist nützliche Infrastruktur; er beweist noch keinen erreichbaren Dienst zwischen Anwendungen.

Mit dem Protokoll kam eine Zuständigkeitsfrage

RFC 1752 nennt Bedenken zur Feldanordnung im CLNP-Header, zum Source Routing, zu Fehlermeldungen und zur Verwendung von NSAP-Adressen für die Routenaggregation. Einige Probleme konnten Änderungen an CLNP oder seinem Profil erfordern. In der TUBA-Gemeinschaft war umstritten, wer sie beschließen durfte: Konnte das IETF die CLNP-Grundnorm ändern, oder musste dies über ISO geschehen? Das betraf nicht nur Verfahren, sondern die Wartbarkeit einer Schicht, auf die der Internetbetrieb angewiesen gewesen wäre.

Die IPng-Empfehlung machte die Beiträge von TUBA nicht gegenstandslos. Nach der Prüfung mehrerer Kandidaten empfahl RFC 1752 das überarbeitete SIPP als Grundlage von IPng. Der Bericht beschreibt zugleich eine Synthese: SIPP lieferte den größten Teil des Protokollkerns; TUBA beeinflusste Autokonfiguration und Übergangsmechanismen. CLNP wurde nicht zur neuen Netzwerkschicht des Internets, doch TUBA war mehr als eine folgenlose Niederlage.

Heng Lus spätere Note:64 ist ein rückblickendes Analysewerkzeug, kein Beleg für die damalige Geschichte: Welche Regeln müssen alle teilen, welche Entscheidungen können Implementierer selbst treffen, und woran lässt sich tatsächlicher Einsatz erkennen? TUBA zeigt, dass Wiederverwendung Entwicklungsarbeit sparen kann, aber nicht klärt, wer eine Norm pflegt, welche Hosts sie umsetzen und welche Netze sie wirklich transportieren.

Quellen