Zusammenfassung

  • Cerf und Robert Kahn entwarfen 1974 eine gemeinsame Architektur für die Kommunikation zwischen unterschiedlichen paketvermittelten Netzen. Sie bauten dabei auf einem Feld auf, zu dem Donald Davies am NPL sowie Louis Pouzin und CYCLADES bereits entscheidende Konzepte beigetragen hatten.

  • Das frühe TCP war nicht das spätere TCP/IP. RFC 675 bündelte Funktionen, die in der anschließenden Debatte und Implementierung getrennt wurden. Jon Postels Kritik an dieser Bündelung machte die Grenze zwischen dem netzübergreifenden IP und der Ende-zu-Ende-Transportfunktion von TCP ausdrücklich zum Gegenstand der Gestaltung.

  • Der Übergang wurde erst durch Implementierer, Gateways, stabile Nummern, Terminalzugänge, institutionelle Vorgaben und die Arbeit der einzelnen Host-Organisationen real. Der Stichtag von 1983 war das Ergebnis eines verteilten Systems von Verantwortlichkeiten, nicht der Vollzug einer Erfindung durch eine Person.

  • RFC 801 setzte als Ziel den vollständigen Wechsel von NCP zu IP/TCP am 1. Januar 1983. Zugleich legte das Dokument offen, warum ein Datum allein nichts umstellt. Die Organisationen hinter den Hosts sollten die neuen Protokolle und die wichtigsten Dienste implementieren. Für die Übergangszeit waren Relay-Hosts vorgesehen, damit Systeme in unterschiedlichen Umstellungsständen miteinander kommunizieren konnten.

  • Diese Aufgabenteilung ist der beste Ausgangspunkt, um Cerfs Rolle zu bestimmen. Er war an den grundlegenden Entwürfen beteiligt, schrieb an Spezifikationen und wirkte als Programmverantwortlicher an der Koordination mit. Er installierte aber nicht jede Host-Implementierung, betrieb nicht jedes Gateway und erzwang nicht persönlich den Wechsel an jedem Standort. Sein Einfluss lag darin, eine gemeinsame technische Grenze beschreibbar zu machen, an der viele voneinander unabhängige Akteure arbeiten konnten.

Der unmittelbare Befund nach dem Termin war entsprechend ungleichmäßig. RFC 842 erfasste im Februar 1983 Tests von TCP-Diensten. Zahlreiche Verbindungen kamen zustande; daneben standen abgelehnte Verbindungen, nicht erreichbare Systeme und tote Hosts. Das Dokument erlaubt keine sichere Diagnose der Ursache jedes einzelnen Fehlschlags. Es belegt jedoch, dass der Übergang weder rein zeremoniell noch augenblicklich vollständig war. Der Erfolg bestand darin, dass eine gemeinsame Betriebsrichtung geschaffen worden war und die verbleibenden Fehler nun innerhalb dieser Ordnung bearbeitet werden konnten.

Um zu verstehen, was Cerf dazu beitrug, muss man vom Termin zehn Jahre zurückgehen. 1973 bestand die Herausforderung nicht darin, eine weitere Paketnetz-Technik zu erfinden. Die Aufgabe war, ARPANET, Paketfunk-, Satelliten- und andere Netze so miteinander sprechen zu lassen, dass ihre interne Verschiedenheit nicht beseitigt werden musste.

Was Cerf vorfand – und was er mit Kahn entwarf

Cerf und Robert Kahn veröffentlichten im Mai 1974 gemeinsam „A Protocol for Packet Network Intercommunication“. Der in den IEEE Transactions on Communications erschienene Aufsatz, dessen öffentliche Kopie von der Princeton University bereitgestellt wird, beschrieb die Kommunikation zwischen unterschiedlichen paketvermittelten Netzen.

Gateways sollten zwischen ihnen vermitteln; ein gemeinsames Adressierungs- und Paketformat sollte den netzübergreifenden Verkehr tragen; Hosts und Prozesse übernahmen Aufgaben wie Sequenzierung, Flusssteuerung und Ende-zu-Ende-Prüfung. Das war Entwurfswissen, kein Nachweis eines bereits fertig implementierten Internets und schon gar kein Beleg für eine Alleinerfindung durch Cerf.

Auch die Vorgeschichte beginnt nicht bei Cerf und Kahn. Die offizielle Geschichte des National Physical Laboratory ordnet Donald Davies die Entwicklung der Paketvermittlung in seiner Arbeit zur Datenkommunikation am NPL zu. Louis Pouzins Arbeit an CYCLADES steht für die Datagramm- und „Catenet“-Tradition, auf die spätere Internetworking-Entwürfe Bezug nahmen. Diese Beiträge sind keine dekorative Vorgeschichte. Sie markieren, was Cerf erbte: Paketvermittlung, Datagrammdenken und die Vorstellung, eigenständige Netze miteinander zu verketten.

Was Cerf und Kahn bauten, war eine konkrete Antwort auf die Heterogenität. Statt alle angeschlossenen Netze auf dieselbe interne Technik zu zwingen, definierten sie eine Ebene der Verständigung über Netzgrenzen hinweg. Diese Entscheidung verteilte Autonomie und Risiko zugleich.

Lokale Netze konnten ihre Verfahren behalten, mussten aber an Gateways und Hosts verlässliche gemeinsame Regeln einhalten. Der Nutzen lag bei allen Teilnehmern, die Reichweite über das eigene Netz hinaus gewannen. Die Kosten trugen zunächst die Entwickler und Betreiber, die Adressierung, Pufferung, Paketverlust, Reihenfolge, Prüfsummen und unterschiedliche Paketgrößen in funktionierende Software übersetzen mussten.

Wie Cerf und Kahn die Arbeit in allen privaten Treffen und frühen Entwürfen von 1973 exakt aufteilten, lässt sich aus dem eingefrorenen Quellenbestand nicht vollständig rekonstruieren. Die veröffentlichte Arbeit belegt die gemeinsame Autorschaft und den gemeinsamen Architekturbeitrag. Mehr sollte aus ihr nicht personalisiert werden.

RFC 675: ein wichtiger Entwurf, noch nicht die endgültige Schichtung

Im Dezember 1974 folgte mit RFC 675 eine ausführlichere Spezifikation des „Internet Transmission Control Program“. Als Autoren werden Vinton Cerf, Yogen Dalal und Carl Sunshine genannt. Das Dokument würdigt außerdem Robert Kahn, Jon Postel und weitere Mitwirkende. Schon die Titelseite widerspricht damit der späteren Erzählung eines einsamen Erfinders.

RFC 675 machte aus der Architektur einen wesentlich konkreteren Arbeitsgegenstand. Prozesse und Sockets, Internetwork-Pakete, Gateways, Wiederholungen und die Behandlung von Fragmenten erhielten technische Form. Doch die damalige Anordnung der Funktionen war noch nicht das saubere Paar aus IP und TCP, das die Standards von 1981 prägen sollte. Das frühe TCP umfasste Aufgaben der netzübergreifenden Paketbehandlung und des Gateways ebenso wie Ende-zu-Ende-Transportaufgaben.

Diese Bündelung war eine realistische Alternative. Ein umfassendes Programm konnte zunächst einfacher erscheinen, weil die für eine zuverlässige Kommunikation nötigen Funktionen an einer Stelle beschrieben wurden. Aber es koppelte zwei verschiedene Arten von Verantwortung: die Zustellung von Datagrammen über wechselnde Netze und die verlässliche Kommunikation zwischen Endpunkten. Fehler, Weiterentwicklung und Implementierung ließen sich schwerer voneinander abgrenzen, wenn beides in derselben Protokollschicht lag.

Jon Postel formulierte diese Einwendung 1977 in IEN 2. Die netzübergreifende Verpackung und Weiterleitung sollte von dem Ende-zu-Ende arbeitenden TCP auf den Hosts getrennt werden. Die spätere IP/TCP-Schichtung erscheint damit nicht als bereits 1974 vollendete Einsicht, sondern als Revision unter dem Druck von Kritik und Praxis.

Für Cerfs Profil ist das entscheidend. Seine Leistung bestand nicht darin, dass der erste veröffentlichte Entwurf unverändert Recht behielt. Die Architektur blieb handlungsfähig, weil Einwände öffentlich formuliert, Funktionen neu zugeschnitten und Implementierungen gegeneinander geprüft werden konnten. Eine Protokollfamilie, die heterogene Netze verbinden soll, musste auch institutionell heterogene Beiträge verkraften.

Die Catenet-Grenze: Einheitliche Datagramme, unterschiedliche Netze

Cerfs IEN 48 vom Juli 1978 beschrieb ein „Catenet“-Modell für das Internetworking. Der Begriff verweist ausdrücklich auf Pouzins Vorarbeit. Cerfs Text war gleichwohl eine eigene, beobachtbare Architekturentscheidung: Verschiedene paketvermittelte Netze sollten durch Gateways zu einer Kommunikationsumgebung verbunden werden, ohne dass ihre lokalen Technologien vereinheitlicht werden mussten.

Die gemeinsame Ebene brauchte Annahmen über Internet-Datagramme, Adressen und Fragmentierung. Neue Netze sollten schrittweise hinzukommen können. Diese Konstruktion war weder völlige Zentralisierung noch bloße lose Kooperation. Sie zentralisierte die Regeln, die für die Interoperabilität unverzichtbar waren, und ließ die interne Netztechnik dezentral.

Genau darin lag ein dauerhafter Zielkonflikt. Je weniger der gemeinsame Standard über die angeschlossenen Netze voraussetzte, desto breiter war sein Anwendungsbereich. Je schmaler diese gemeinsame Schicht wurde, desto mehr Verantwortung wanderte an die Endsysteme und Betreiber. Hosts mussten korrekte Protokollsoftware bereitstellen; Gateways mussten Pakete über Grenzen hinweg transportieren; Institutionen mussten Nummern und Schnittstellen koordinieren. Die Architektur beseitigte Abhängigkeiten nicht. Sie ordnete sie so, dass Verantwortung lokalisierbar wurde.

Implementierung als Gegenprüfung der Architektur

Bis 1979 war TCP keine einzelne Referenzimplementierung mehr. IEN 98 sammelte den Stand von Implementierungen an mehreren Hosts und Institutionen, darunter BBN, UCLA, DTI, SRI, NDRE und MIT. Jede Portierung brachte Betriebssysteme, lokale Schnittstellen und unterschiedliche Reifegrade in die Architektur ein. Ein Feld in einer Spezifikation konnte formal eindeutig sein und sich dennoch erst in mehreren unabhängigen Programmen als praktikabel erweisen.

Cerfs Einfluss verschob sich in dieser Phase teilweise von der Autorenschaft zur Programmkoordination. RFC 1160, ein späterer Rückblick auf die Internet-Gremien, hält fest, dass er 1979 als DARPA-Programmmanager das Internet Configuration Control Board einrichtete. Diese Angabe erlaubt einen begrenzten Schluss: Cerf half, die Konfigurations- und Architekturarbeit zu organisieren. Sie macht ihn nicht zum Autor jeder Implementierung und nicht zum alleinigen Eigentümer der nachfolgenden Institutionen; spätere Reorganisationen und Verantwortlichkeiten gehörten seinen Nachfolgern und der Gemeinschaft.

Die technischen Berichte von 1981 zeigen, wie konkret die offenen Fragen waren. IEN 166 behandelte TCP/IP für den Terminal Access Controller, der während der Migration sowohl TCP- als auch NCP-Verbindungen unterstützen musste. IEN 175 dokumentierte Arbeiten an Leistung, Adressierung, Dokumentation, Gateways, X.25-Umgebungen, Fragmentierung und Tests. Das Internet wurde nicht dadurch real, dass ein Prinzip überzeugte. Es wurde real, weil Teams an UCL, RSRE, ISI, UCLA, SRI, MIT, BBN, Ford und weiteren Orten die Grenzfälle ausführten.

Diese verteilte Umsetzung machte auch die Alternativen sichtbar. Eine sofortige Umstellung aller Systeme hätte eine klare Zielarchitektur geboten, aber schon ein verspäteter Host konnte wichtige Kommunikation unterbrechen. Längere Koexistenz verringerte das lokale Umstellungsrisiko, erhöhte jedoch die Komplexität und konnte den alten Zustand konservieren. Dual-Protokoll-Systeme und Relay-Hosts waren deshalb kein Zeichen konzeptioneller Reinheit, sondern ein Kompromiss zwischen einem verbindlichen Ziel und ungleich verteilten Fähigkeiten.

Von zwei Standards zu einer betreibbaren Ordnung

Im Januar 1980 erschienen mit RFC 760 und RFC 761 getrennte DoD-Standards für IP und TCP. Im September 1981 folgten RFC 791 und RFC 793. Die Trennung war damit nicht nur eine Kritik am frühen Entwurf, sondern in den veröffentlichten Spezifikationen verankert. Der vorliegende Quellenbestand erlaubt jedoch keine Zuschreibung jedes einzelnen Feldes der endgültigen Texte an Cerf, Postel, ISI-Redakteure oder bestimmte Implementierer.

Ein Protokoll ist außerdem nicht betreibbar, wenn alle dieselben Begriffe verwenden, aber unterschiedliche Nummern meinen. RFC 790 veröffentlichte zugewiesene Nummern für die entstehende Ordnung. Postels redaktionelle und registerbezogene Funktion war damit von Cerfs Protokoll- und Programmrolle zu unterscheiden. Der Namens- und Nummernraum bildete eine eigene Kontrollfläche: Wer Implementierungen koordinieren wollte, brauchte nicht nur Paketformate, sondern stabile, öffentlich gepflegte Identifikatoren.

IEN 207 dokumentierte 1982 die institutionelle Seite. TCP/IP wurde für die einschlägigen paketorientierten Netze des US-Verteidigungsministeriums verbindlich; die Defense Communications Agency erhielt die Rolle des ausführenden Organs. Damit gewann die technische Architektur politische Durchsetzungskraft. Aber auch diese Autorität war nicht Cerfs persönliche Autorität. Programmförderung, Spezifikationsarbeit, Registerpflege, Vorgaben und lokale Implementierung blieben unterschiedliche Funktionen.

Der Übergang profitierte von dieser Trennung. Cerf und andere Architekten konnten die gemeinsame Technik prägen. Postel und USC/ISI trugen Kritik, Publikation und Nummernverwaltung. DARPA finanzierte und koordinierte Forschung. DoD und DCA schufen Mandat und Verantwortlichkeit. Host-Organisationen und Verbindungsleute setzten die Änderung vor Ort um. Betreiber fanden heraus, welche Dienste tatsächlich erreichbar waren. Keiner dieser Akteure hätte allein das Ergebnis herstellen können.

Quellen

Bildnachweis

KI-gestützte redaktionelle Bildkomposition auf Grundlage eines 2005 von Joi (Jōichi Itō) aufgenommenen Fotos von Vint Cerf, via Wikimedia Commons, CC BY 2.0. Die abstrakte Netzwerkebene wurde mit OpenAI imagegen über Codex für die redaktionelle Darstellung erzeugt; das Bild dokumentiert weder die Protokollentwicklung noch die Umstellung von 1973 bis 1983.