Zusammenfassung

  • Die Frist von 1983 konnte NCP auf ARPANET praktisch ausschließen, weil der Sponsor die IMPs und damit eine ausführbare Grenze kontrollierte; unabhängige Netze außerhalb davon wurden nicht ungültig.
  • RFC 801 verteilte die Umsetzung auf die einzelnen Host-Organisationen und flankierte sie mit Doppelprotokoll-Relays, gleichwertigen Anwendungen, Messungen und Probeabschaltungen.
  • Der Stichtag erzeugte keinen perfekten Zustand: Die Dienstmessungen lagen weit unter einer naiven 100-Prozent-Lesart, die Hosttabellen-Verteilung scheiterte teilweise und Volllast brachte neue Leistungsfehler hervor.

Wenn funktionierende Software keinen Dienst mehr erhält

Ein NCP-Host konnte am Jahreswechsel noch dieselbe Maschine, dieselbe Leitung und dieselben Benutzer besitzen. Trotzdem verlor er die reguläre Kommunikation, sobald das Netz unter ihm das alte Protokoll nicht mehr bediente. Darin liegt der Unterschied zwischen Spezifikation und Wirklichkeit. Ein Dokument beschreibt gemeinsames Verhalten; laufende Infrastruktur entscheidet, welches Verhalten tatsächlich transportiert wird.

Vint Cerf erinnerte sich später in einem Interview des Computer History Museum, dass die Interface Message Processors NCP ablehnen oder nicht mehr bedienen konnten. Mitte 1982 sei NCP für einen ganzen Tag abgeschaltet worden, im Herbst ungefähr zwei Tage. Für nicht migrierte Nutzer fiel E-Mail aus. Die Proteste zeigten, dass aus einer angekündigten Frist eine beobachtbare Konsequenz geworden war.

Die Erinnerung ist kein sekundengenaues Betriebsprotokoll. Cerf datierte die Tests nur ungefähr und erwähnte für Januar einige wenige Ausnahmen wegen besonderer Softwareprobleme. Der „Flag Day“ war daher kein makelloser Weltschalter, sondern das Ende einer längeren ARPANET-Sequenz aus Vorbereitung, Übergang, Probeausfällen, Ausnahmen und Nacharbeit.

NCP war an die Reichweite eines einzigen Netzes gebunden

NCP war nicht bloß eine frühere TCP-Fassung. Das Protokoll beruhte auf der Host-zu-Host-Umgebung von ARPANET. Die ARPA-Forschung umfasste inzwischen aber Paketfunk, Satellitennetze und lokale Netze mit anderen Übertragungseigenschaften. Diese Systeme sollten miteinander arbeiten, ohne zu einem einzigen physischen Netz umgebaut zu werden.

RFC 801 beschreibt IP und TCP als Antwort auf diese Grenze. RFC 791 legte die netzübergreifende Datagrammschicht fest, RFC 793 die zuverlässige Verbindung an den Endpunkten. Unterschiedliche Netze konnten damit eine gemeinsame Kommunikationsumgebung bilden. RFC 801 nannte diese Menge ARPA Internet oder Catenet.

NCP dauerhaft zu erhalten, wäre keineswegs neutral gewesen. Service-Hosts, Namenslisten, Konten, Relays und Betriebsteams hätten zwei Umgebungen finanzieren müssen. Die verspätete Organisation trug ihre Kompatibilitätskosten nicht allein; sie verlagerte einen Teil auf die Betreiber der Brücke.

Das US Department of Defense hatte IP/TCP als Standard seiner paketvermittelten Netze angenommen. Für ARPANET, das es finanzierte und über definierte Auftragnehmer betrieb, gab es somit eine legitime Eingriffsfläche: Fortgesetzter Dienst durfte an eine neue Kompatibilitätsbedingung geknüpft werden. Daraus folgte keine weltweite Zuständigkeit eines RFC-Autors.

Der Termin war zentral, die Umsetzung nicht

RFC 801 wies jedem Host-Betreiber die Aufgabe zu, IP/TCP auf den eigenen Systemen zu implementieren. Eine zentrale Stelle konnte heterogene Betriebssysteme, Host-IMP-Schnittstellen, Anwendungen und Supportabläufe nicht aus der Ferne umbauen. Der Plan definierte das Ziel und das Ende des alten Dienstes; die tatsächliche Betriebsfähigkeit entstand an vielen Standorten.

Auch eine vorhandene Transport-Schicht genügte nicht. Telnet, Dateiübertragung und E-Mail mussten über TCP funktionieren. Für Nutzer bedeutete Migration nicht, dass ein Testpaket zurückkam, sondern dass Anmeldung, Datei und Nachricht wieder zuverlässig ankamen.

Beim E-Mail-Verkehr wurde Kontinuität zur harten Anforderung. RFC 773 verlangte, bekannte ARPANET-Postfachnamen beizubehalten, alte Mechanismen während der Übergangszeit weiter zu unterstützen und Nachrichten möglichst ohne Eingriff des Nutzers zwischen NCP und TCP weiterzuleiten. Der neue Dienst musste den bereits entstandenen sozialen Nutzen übernehmen.

Doppelprotokoll-Hosts bildeten deshalb Relays. Eine Telnet-Sitzung konnte per TCP beim Relay eintreffen und per NCP weiterlaufen. Dateien ließen sich in zwei Schritten kopieren. E-Mail konnte in einer Umgebung angenommen, zwischengespeichert und in der anderen zugestellt werden.

Das Relay schuf zugleich neue Abhängigkeit. Eine weitere Maschine, besondere Konten, Kapazität und eine zusätzliche Fehlerstelle kamen in den Pfad. RFC 801 diskutierte Zuverlässigkeit und Last ausdrücklich. Die Brücke sollte Zeit für lokale Arbeit schaffen, nicht NCP einen ewigen Anspruch auf fremde Ressourcen geben.

Eine Testabschaltung ist mehr als eine Warnung

Ein begrenzter Ausfalltest beantwortet drei Fragen: Existiert der Schalter wirklich? Welche Abhängigkeiten fehlen im Inventar? Wer erkennt und behebt den Schaden? 1982 machte der E-Mail-Ausfall die Restabhängigkeit so sichtbar, wie es eine Checkliste nicht konnte.

Das war keine Abstimmung über technische Wahrheit. Die ARPANET-Hostgemeinde war kein Weltparlament. Die relevante Legitimation war enger: Der Sponsor durfte den von ihm verantworteten Dienst ändern; jede Organisation verantwortete die angeschlossenen Systeme; und die Folgen der Probe trafen denselben Forschungsbetrieb, der die Regel gesetzt hatte.

Gerade deshalb taugt 1983 nicht als Vollmacht für eine globale Protokollpolizei. Wer keine Geräte betreibt, keine Migration finanziert und keinen Schaden trägt, gewinnt durch die Veröffentlichung eines Datums keine Ausführungsgewalt. Auf ARPANET verloren NCP-Pakete ihren Dienst. Ein fremdes Netz verlor dadurch weder Existenz noch Recht, einen anderen Kompatibilitätssatz zu betreiben.

Der Plan sagte „alle“, die Messung sagte „welcher Dienst?“

RFC 801 formulierte den Januar-Meilenstein sauber: alle Hosts TCP-fähig, alle Hauptdienste auf TCP, NCP und Relays beendet. Die wöchentlichen Erhebungen von David Smallberg zeigen eine weniger gleichförmige Betriebswirklichkeit.

RFC 847 fasst Verbindungsversuche zu Telnet-, FTP- und SMTP-Servern zusammen. Am 28. Dezember 1982 akzeptierten von 314 gelisteten Hosts 95 Telnet, 80 FTP und 72 SMTP. Am 4. Januar 1983 waren es 151, 132 und 124 von 315. Am 22. Februar lagen die Werte bei 190, 181 und 178 von 325.

Diese Zahlen sind keine vollständige TCP-Compliance-Quote. Ein Host konnte abgeschaltet sein, einem Sonderzweck dienen oder TCP ausführen, ohne einen der getesteten Dienste anzubieten. Die Autoren schätzten 37 Hosts beziehungsweise elf Prozent als Sonderkategorie und hielten etwa 89 Prozent für die vernünftige Obergrenze. Auch der Nenner wechselte.

Die belastbare Aussage lautet deshalb: Sichtbare TCP-Dienste nahmen um den Stichtag stark zu, doch ein einziger 100-Prozent-Wert existierte nicht. Veröffentlichte Norm, installierter Stack, offener Dienst, realer Verkehr und erfolgreiche Nutzung sind verschiedene Tatsachen. Die Erhebung maß nur eine davon – und war gerade dadurch wertvoll.

Die Produktion schrieb den fehlenden Testfall

Der spätere Bericht des National Research Council, veröffentlicht als RFC 942, nennt ungefähr dreißig TCP-only-Hosts in den sechs Monaten vor dem Cutover. Diese Erfahrung half, die Betriebsfähigkeit während der Umstellung zu erhalten. Normale Servicequalität kehrte trotzdem erst nach einigen Monaten zurück.

Das Network Information Center war auf die neue Protokollumgebung nicht vorbereitet, wodurch die Hosttabelle schlecht verteilt wurde. Service-Rechner litten unter Leistungsproblemen, weil keiner zuvor über längere Zeit die volle Benutzerlast erlebt hatte. Nach der Umschaltung mussten Parameter analysiert und nachgestellt werden. Mail-Relays wurden stark, andere Relays wenig genutzt.

Das widerlegt den Erfolg nicht, sondern bestimmt seinen Preis. Ein altes Kompatibilitätsversprechen kann beendet werden, während Grundbetrieb erhalten bleibt; Kapazität, Zustandsverteilung und Support können dennoch unreif sein. Ein Termin schließt eine Option. Er erzeugt keine sofortige Betriebsreife.

Zugleich wird die Grenze zentraler Steuerung sichtbar. Der Sponsor konnte NCP im Subnetz abschalten, aber nicht die Arbeit von Betriebssystementwicklern, Service-Administratoren, NIC, TAC-Betreibern und Relay-Wartung ersetzen. Die Vollzugsgrenze war konzentriert, das notwendige Können blieb verteilt.

Wo der Befehl endete und Adoption begann

Innerhalb von ARPANET besaß kein Standort ein unbegrenztes Recht, NCP auf Kosten aller weiter bedienen zu lassen. Der Betreiber durfte einen Dienst beenden, der die Mehrnetz-Architektur blockierte, wenn Ersatzfunktionen, sichtbare Risiken, begrenzte Ausnahmen und Verantwortung für Fehlvollzug vorhanden waren.

Jenseits dieser Vermögens- und Vertragsgrenze konnte derselbe Sponsor Adoption nicht anordnen. Universitäten, Hersteller, lokale und andere Paketnetze mussten TCP/IP implementieren und Gegenstellen wählen. Die breitere Autorität der Protokollfamilie entstand durch laufenden Code, der über unterschiedliche Techniken hinweg interoperierte – nicht durch ein Etikett für Nichtanwender.

Hier verläuft die Linie zwischen Koordination und Souveränität. Ein Betreiber kann inkompatiblen Verkehr auf eigenen Geräten ablehnen. Er muss die Bedingung erklären, Folgen messen und Fehler tragen. Kontrolle über eine lokale Grenze wird dadurch nicht zu Eigentum an fremden Maschinen oder künftigen Netzen.

Der 1. Januar 1983 lässt sich deshalb genauer als Ende des regulären NCP-Dienstes auf ARPANET beschreiben, nicht als Geburtstag des Internets. Innerhalb drängte die Frist zur Umsetzung; außerhalb zog Interoperabilität die Adoption an. Die technische Autorität war historisch wirksam, weil sie einen Endpunkt hatte.

Quellen und Beweisgrenzen

Plan, Verantwortlichkeiten und Meilensteine stammen aus RFC 801. Die Mail-Kontinuität steht in RFC 773. Die gemeinsamen Regeln liefern RFC 791 und RFC 793; RFC 820 dokumentiert die damalige Protokollumgebung.

Die Dienstzahlen kommen aus RFC 847 und bleiben auf dessen Messgrenze beschränkt. Betriebserfahrungen kommen aus RFC 942. Testabschaltungen, IMP-Mechanismus und wenige Ausnahmen werden Cerfs Computer-History-Museum-Interview zugeschrieben.

Die Quellen enthalten weder eine vollständige Ausnahmeliste noch eine exakte Gesamtausfallzeit oder einen weltweiten Host-Nenner. Sie belegen einen geplanten und vollzogenen ARPANET-Cutover mit monatelanger Nacharbeit, nicht den einen Augenblick, in dem alle Netze der Welt TCP/IP übernahmen.