Der Flag Day, der die Autorität veränderte: Governance nach dem TCP/IP-Cutover

Zusammenfassung

• Die Umstellung im Januar 1983 war erheblich, aber ungleichmäßig: Messungen im Februar ergaben Hunderte von TCP-Dienstendpunkten, doch die Ergebnisse unterschieden sich je nach Dienst, Adresspopulation, Testdatum und Netzwerkpfad und beschrieben keine einheitliche Population, die um Mitternacht umstellte.
• Der Einfluss von Sponsor und Betreiber wurde durch IMP-basierte Ablehnung von NCP-Verkehr, Ausnahmeentscheidungen des DDN-PMO sowie Host- oder Port-Aktivierung ausgeübt; die Abhängigkeit von SRI-NIC-Aufzeichnungen und der Nummernkoordination durch USC/ISI nahm betrieblich zu, ohne dass der Cutover einem dieser Ämter neue Ermessensbefugnisse verlieh.
• Das Ausnahmeverfahren war real, aber eher partiell als unabhängig: Administratoren konnten Reklamationen einreichen, eine öffentliche Liste führte befristete NCP-Freischaltungen und Ablauffristen, und TAC- sowie UDEL-Relays bewahrten eine begrenzte Erreichbarkeit, doch veröffentlichte Gründe, vollständige Entscheidungsunterlagen und eine Überprüfung außerhalb des DDN-PMO fehlten.

Am 1. Februar 1983, einen Monat nach dem Zieltermin des ARPANET für die Umstellung von NCP auf TCP/IP, versuchte ein Test von ISI-VAXA aus, sich mit jeder Adresse in einer aktuellen Host-Tabelle des Network Information Center zu verbinden. Das Ergebnis war kein Netzwerk, das sauber in eine Vergangenheit und eine Zukunft geteilt war. Es war ein festformatierter Bericht voller akzeptierter Verbindungen, Ablehnungen, unerreichbaren Adressen, abgeschalteten Systemen und leeren Ergebnisfeldern.

Die Host-Liste war der NIC-Tabelle vom 28. Januar entnommen. Die Tests liefen von ISI-VAXA aus am 1. und 2. Februar, wobei tote, unerreichbare und ablehnende Einträge am 3. Februar erneut versucht wurden. Die Erhebung versuchte drei TCP-Dienste: Telnet, FTP und SMTP. Sie untersuchte keine Software, testete nicht jede TCP- oder IP-Funktion, bewies keine kontinuierliche Verfügbarkeit eines Hosts und zählte nicht jeden Computer auf, der mit den teilnehmenden Netzwerken verbunden war. Sie zeichnete auf, was geschah, wenn ein Ursprung bestimmte Dienstports zu bestimmten Zeitpunkten ansprach.

Die Grundgesamtheit inRFC 842, „Who Talks TCP?“betrug 328 Adresszeilen. Davon begannen 200 mit der Netzwerknummer 10, dem ARPANET-Adressraum, und 128 gehörten zu anderen Netzwerken. Eine Zeile war nicht notwendigerweise ein eindeutiger physischer Computer, eine Institution, ein DDN-Teilnehmer oder eine Organisation. Ein namentlich genanntes System konnte unter mehr als einer Adresse erscheinen; Gateway- und andere betriebliche Einträge konnten ebenfalls in der Tabelle auftauchen. Umgekehrt befand sich ein nicht registriertes, abgetrenntes, eingestuftes oder ausgelassenes System außerhalb der gemessenen Population.

Eine direkte Nachzählung der Ergebniszeilen von RFC 842 ergibt die folgende Auswertung. Dasaccepted+-Ergebnis für FTP wird unter akzeptiert gezählt. Eine über die Dienstspalten hinweg als tot oder unerreichbar angezeigte Angabe wird für jeden Dienst in diesem Zustand gezählt.

Diese Kategorien beschreiben Beobachtungen, keine Erklärungen. Ein toter Eintrag konnte auf einem abgeschalteten Rechner voll funktionsfähige TCP-Software besitzen. Eine nicht erreichbare Adresse konnte auf ein Problem mit Gateway, Routing, Adressierung oder Messung hinweisen. Eine Ablehnung konnte bedeuten, dass Pakete einen TCP-Endpunkt erreichten, die Anwendung die angeforderte Sitzung jedoch nicht akzeptierte. Ein leeres Ergebnis verrät nicht, ob der Fehler beim Host, beim Pfad, beim Dienst oder in der Tabelle lag.

Die Annahme auf einem Port beweist keine vollständige Konformität mit TCP, IP, ICMP, Routing, Namensauflösung und den Hauptanwendungen.

Die Host-Tabelle war auch keine Volkszählung der Einhaltung des Januar-Ziels des Sponsors. Ihre 128 Zeilen außerhalb von Netzwerk 10 enthielten Systeme in unabhängig betriebenen, Forschungs-, lokalen, ausländischen, paketfunkbasierten, satellitengestützten und sonstigen Netzwerken. Ihr Erscheinen zeigte die Teilnahme an einer sich erweiternden Internet-Umgebung. Es zeigte nicht, dass die Defense Communications Agency allen Betreibern die Umstellung befehlen konnte.

Der „Flag Day“ in der Überschrift ist folglich eine rückblickende Bezeichnung, nicht die übliche Sprache der Betriebsaufzeichnungen. Die zeitgenössischen Mitteilungen sprachen von einem Cutover, einer Umstellung oder einem reinen TCP-Experiment. 1997 beschrieb eine von mehreren führenden Beteiligten verfasste Geschichte der Internet Society das Ereignis als einenÜbergang im „Flag-Day“-Stil. Dieser spätere Bericht fing die koordinierende Kraft des Stichtags ein, komprimierte aber die ungleichmäßige Umsetzung, die die Februar-Tabellen bewahrten.

Die Umstellung war dennoch folgenreich. Es war eine vom Sponsor unterstützte Entscheidung, die Koexistenz von NCP und TCP nicht mehr als normale Zukunft des ARPANET zu behandeln. Ihre Bedeutung liegt nicht in einer mythischen Mitternachts-Transformation, sondern in den Mechanismen, die das Ziel glaubhaft machten: Tests, die NCP im Vermittlungsnetz deaktivierten, ein vom Betreiber verwaltetes Ausnahmeverfahren, vorübergehende Relay- und Terminal-Unterstützung, Host- und Port-Freigabe und eine wachsende Abhängigkeit von korrekten gemeinsamen Aufzeichnungen.

1.–18. Februar 1983: Veränderte Beobachtungen waren keine Adoptionskurve

Eine zweite Erhebung veranschaulicht, warum aggregierte Gesamtwerte nicht einfach in eine Geschichte stetiger Annahme umgedeutet werden können.

RFC 843verwendete die NIC-Host-Tabelle vom 3. Februar und testete am 8. und 9. Februar von ISI-VAXA aus. Die Grundgesamtheit war von 328 auf 329 Zeilen angewachsen. Die Gesamtzahl der Akzeptierungen betrug 187 für Telnet, 174 für FTP und 170 für SMTP, gegenüber 183, 170 und 169 im früheren Bericht. Aber die Gruppe Netzwerk 10 und die Gruppe außerhalb bewegten sich in entgegengesetzte Richtungen.

Die akzeptierten Anzahlen in Netzwerk 10 stiegen für alle drei Dienste. In den anderen Netzwerken fielen sie für alle drei. Die zugrundeliegende Tabelle änderte sich ebenfalls um eine Zeile, und einzelne Rechner konnten bei einem Test aktiv und bei einem anderen nicht verfügbar sein. Ohne eine abgestimmte Analyse, die Hinzufügungen, Entfernungen, vorübergehende Ausfälle und geänderte Pfade kontrolliert, zeigen die beiden Erhebungen veränderte Beobachtungen, nicht eine gemessene Adoptionsrate.

Zehn Tage später stellteRFC 844eine andere Frage. Er wählte die 187 Einträge aus, die Telnet in RFC 843 akzeptiert hatten, und versuchte, sie von einem Terminal-Konzentrator im Klasse-C-Netz 192.1.2 bei BBN aus zu erreichen. Der Erfolg erforderte mehr als einen akzeptierenden Telnet-Dienst auf dem früheren Pfad: Pakete und Antworten mussten über Gateway-Routing, Klasse-C-Adressierung und das entsprechende ICMP-Verhalten funktionieren.

Die Verbindungen wurden manuell über die Punktadresse eingegeben, und es wurden nur drei Durchläufe gemacht. Ein während dieser Durchläufe nicht verfügbarer Host konnte verpasst werden. Die Ergebnisse offenbarten dennoch, wie stark ein scheinbarer TCP-Erfolg vom Testursprung und Netzwerkpfad abhing.

Die Gesamtmenge von 127 von 187 kann keine einfache Behauptung stützen, externe Netzwerke hätten hinter dem ARPANET zurückgelegen. Die Nicht-Klasse-A-Gruppe hatte die höchste beobachtete Rate, 30 von 32. Der Test beweist auch nicht, dass jedem erfolglosen Eintrag die Unterstützung von Klasse C oder ICMP fehlte; vorübergehende Verfügbarkeit und Pfadbedingungen blieben ungeklärt.

Zusammen belegen die drei Berichte eine engere, aber wertvolle Tatsache. Einen Monat nach dem Ziel akzeptierten Hunderte von Tabellenzeilen wichtige TCP-Dienste, während die aufgezeichnete Fähigkeit, die Anwendungsverfügbarkeit und die Erreichbarkeit von verschiedenen Ursprüngen aus ungleichmäßig blieben. Die Umstellung hatte einen substanziellen Betrieb hervorgebracht, nicht sofortige Einheitlichkeit.

Das ist die erste Governance-Grenze. Messung machte die Implementierung sichtbar, aber Messung entschied nicht, warum ein Host ausfiel oder welche Abhilfe folgen sollte. Diese Entscheidungen lagen bei den Host-Administratoren, Implementierern, Gateway- und Vermittlungsbetreibern, dem NIC, dem DDN Program Management Office, den Forschungssponsoren und, außerhalb der vom Sponsor kontrollierten Population, bei autonomen Netzbetreibern.

November 1981: Der Plan war darauf ausgelegt, die Vermittlung zu beenden

Das Betriebsziel begann als ein gestufter Plan, nicht als Behauptung, dass Hunderte von Maschinen auf einmal wechseln könnten.

Der im November 1981 veröffentlichteRFC 801legte den 1. Januar 1983 als Ziel für eine vollständige Umstellung des ARPANET von NCP auf IP und TCP fest. Er wies jede Host-Organisation an, bis zum 1. Januar 1982 mit der Implementierung von IP/TCP zu beginnen, und übertrug dieselbe lokale Verantwortung für Telnet, Dateiübertragung und Mail. Von neuen ARPANET-Hosts wurde erwartet, dass sie mit TCP/IP beginnen anstatt über NCP einzusteigen.

Die Meilensteine des Plans offenbaren sein tatsächliches Design. TCP-fähige und reine TCP-Hosts existierten bereits. Es wurde erwartet, dass Relay-Dienste inkompatible Hosts überbrückten. Die letzte reine NCP-Umstellung sollte im Januar 1982 beginnen; die meisten Hosts sollten bis Juli TCP-fähig sein; die letzte Umstellung sollte im November abgeschlossen sein. Erst dann würde der Januar 1983 den vollen TCP-basierten Dienst, die Entfernung von NCP und das Ende der regulären Relay-Unterstützung bringen.

Die Implementierung blieb verteilt. ARPANET-Host-Organisationen kontrollierten Maschinen mit unterschiedlichen Prozessoren, Betriebssystemen, Personal, Softwarequellen und lokalen Dienstleistungsanforderungen. Der Sponsor konnte einen Termin ankündigen und Implementierungen finanzieren, aber er konnte eine fehlerhafte Prüfsummenroutine nicht per Dekret korrigieren. Ein Host konnte IP und TCP haben, während SMTP fehlte. Ein System, das über ein Gateway hinweg funktionierte, konnte eine andere Route, Optionen, Fragmentierung oder ICMP falsch behandeln.

RFC 801 selbst warnte vor Implementierungen, die Prüfsummen ausließen, Fragmente nicht wieder zusammensetzten, sich auf begrenzte Routingdaten stützten, Optionen ignorierten, TCP-Daten falsch umordneten oder statische Namenstabellen pflegten.

Was das Ziel tun konnte, war, die Kosten der Verzögerung zu verändern. Eine Host-Organisation konnte NCP-Software auf ihrem eigenen Rechner behalten, aber sie konnte den ARPANET-Betreiber nicht zwingen, NCP-Verkehr auf unbestimmte Zeit zu transportieren. Sobald das Vermittlungsnetz den alten Verkehr ablehnte und die üblichen Relays endeten, wurde eine unvollendete lokale Implementierung zu einem Zugänglichkeitsproblem für den Host und seine Benutzer.

RFC 801 modellierte, warum eine längere Koexistenz unattraktiv war. Reine NCP- und reine TCP-Endpunkte konnten nicht direkt kommunizieren, daher mussten Dual-Protokoll-Relay-Hosts Telnet, FTP und Mail vermitteln. Telnet erforderte ein zwischengeschaltetes Konto und eine zweite Anmeldung. FTP konnte erfordern, eine Datei auf den Relay-Speicher zu verschieben und sie dann erneut zu übertragen. Mail erforderte Weiterleitungslogik und protokollbewusste Adressierung. Jedes Relay fügte eine weitere Maschine hinzu, die verfügbar sein musste, und einen weiteren Dienst, der Kapazität, Zugangskontrolle, Dokumentation und Unterstützung benötigte.

Das numerische Relay-Last-Modell des Dokuments war ausdrücklich spekulativ, aber seine institutionelle Aussage war stichhaltig. Eine unbegrenzte Koexistenz war keine neutrale Bewahrung der Wahlfreiheit. Jemand musste die Nahtstelle zwischen den beiden Umgebungen finanzieren und betreiben. Ein Stichtag verlagerte diese Last von den Relay-Betreibern auf die Host-Organisationen, die ihre Umstellungen noch nicht abgeschlossen hatten.

Der Plan allein beweist nicht, dass dieser Transfer stattfand. Die Aufzeichnungen der Ausführung erscheinen in einer anderen Quelle: den Betriebsnewslettern, die vom NIC für die DCA und ihr DDN Program Management Office verteilt wurden.

Oktober–Dezember 1982: Die Durchsetzung wanderte in die IMPs

Am 1. Oktober 1982, von 12 bis 16 Uhr Ostküstenzeit, führte das ARPANET ein reines TCP-Experiment durch. Während dieser vier Stunden wurden die Interface Message Processors angewiesen, Host-Nachrichten über Link 0 abzulehnen, den mit NCP-Host-zu-Host-Verkehr verbundenen Link. Der IMP gab einen Status vom Typ 7, Subtyp 3 zurück, der anzeigte, dass die Kommunikation mit dem Ziel „administrativ verboten“ war.

Dieser Mechanismus, beschrieben inARPANET News Nr. 14, ist der klarste Beleg für betrieblichen Zwang bei der Umstellung. NCP wurde nicht nur in einem Dokument als veraltet bezeichnet. Die Paketvermittlungsinfrastruktur verweigerte den entsprechenden Verkehr. Reine NCP-Hosts konnten das ARPANET während des Tests nicht nutzen. Dual-Protokoll-Systeme mit gemeinsamen Remote-Host-Zuständen konnten ebenfalls auf Probleme stoßen, es sei denn, die Administratoren deaktivierten ihre NCP-Implementierung für diesen Zeitraum.

Der Durchsetzungspunkt ist wichtig. Es war nicht SRI-NIC, das einen Namen löschte, und nicht USC/ISI, das eine Nummer verweigerte. Die IMPs führten die Ablehnung unter Netzmanagement-Anweisungen aus, wobei das Network Operations Center und das mit der DCA verbundene Management für die Betriebsumgebung verantwortlich waren. Der zurückgegebene Status war darauf ausgelegt, den administrativen Charakter der Ablehnung für den einreichenden Host sichtbar zu machen.

News Nr. 16 erinnerte die Administratoren an den Test vom 1. Oktober und bat die Teilnehmer, Beobachtungen an Jon Postel, das NOC und das NIC zu melden. Es drängte die Standorte außerdem, SMTP und die Vier-Oktett-Internet-Adressierung bis Januar zu implementieren. Hier bündelte die Koordination mehrere Funktionen: Das Vermittlungsnetz schuf die Testbedingung; Implementierer und Host-Administratoren beobachteten Ausfälle; ISI erhielt technische Berichte; das NOC überwachte den Betrieb; und das NIC verteilte Anweisungen und sammelte Implementierungsinformationen.

Dem vierstündigen Experiment folgten längere Probedurchläufe.News Nr. 17kündigte 24-stündige reine TCP-Perioden am 15. November und am 13.–14. Dezember an. Es würde dieselbe Ablehnungsmethode auf IMP-Ebene verwendet. Die Mitteilung warnte ausdrücklich, dass dies auch der Mechanismus sein würde, der nach dem Ziel 1. Januar vorgesehen war.

Diese Tests lieferten Informationen, die kein Host-Tabellen-Eintrag bieten konnte. Ein Standort konnte melden, dass er TCP hatte, jedoch während eines NCP-freien Tages entdecken, dass ein Produktionsdienst, Mailer, Terminalpfad, Gateway oder ein lokales Betriebsverfahren noch von NCP abhing. Ein Host konnte einen Labortest bestehen, aber unter dem Verkehr und Nutzerverhalten einer vollen Betriebsperiode versagen. Die Wiederholung des Experiments erhöhte die Chance, dass eine Abhängigkeit entdeckt wurde, bevor die dauerhafte Netzrichtlinie wechselte.

Die Tests schufen auch Druck. Ein vom Sponsor kontrollierter Host, der nicht umgestellt hatte, konnte das alte Protokoll während des Tests nicht einfach weiterverwenden. Seine Nutzer erfuhren die Konsequenz der Nichtumstellung, und seine Administratoren erhielten einen spezifischen Status vom Netz. Das war wesentlich anders als Überzeugung durch einen RFC.

Doch der Druck war begrenzt. Er galt direkt für NCP-Verkehr, der über ARPANET-IMPs eingereicht wurde. Er erreichte kein unabhängiges lokales Netz, das intern NCP betrieb, kein externes Netz, das nicht dem ARPA-Internet beigetreten war, und nicht jede Nicht-Netzwerk-10-Adresse, die später in RFC 842 aufgeführt war. Von DARPA finanzierte Forschungspartner mochten vertraglichen Erwartungen oder starken Interoperabilitätsanreizen unterliegen, aber diese Beziehungen waren nicht identisch mit der Kontrolle der DCA über den ARPANET-Betrieb.

Dieselbe Unterscheidung begrenzt Behauptungen über die Registrierung. Die Tests beweisen, dass der Betreiber ein Protokoll auf der Vermittlungsebene abschalten konnte. Sie beweisen nicht, dass der Cutover dem NIC neue Ermessensspielräume über Namen oder USC/ISI neue Ermessensspielräume über Nummernzuteilungen gab. Diese administrativen Funktionen waren für die Interoperabilität wichtig, aber der beobachtete Zwangsakt fand anderswo statt.

Januar 1983: Ausnahmen waren öffentlich, aber nur teilweise

Die Betriebspolitik bestand nicht aus einer Frist ohne Möglichkeit des Aufschubs.

Vom 22. Dezember 1982 datiert, erklärteARPANET News Nr. 19, dass nach 0:01 Uhr Ostküstenzeit am 1. Januar die Nutzung von NCP ohne eine spezifische Ausnahme des DDN Program Management Office nicht erlaubt sein würde. Es gab der Ausnahmeanfrage einen Namen—reclama—und legte fest, wie man eine einreichte.

Vor Januar konnte eine Anfrage per Netzwerk-Mail an DDN-PMO-Adressen geschickt werden, mit Kopien an das NIC. Nach der Frist konnte ein Administrator, der das Netz nicht nutzen konnte, die Anfrage per Post an das DCA-Hauptquartier senden. Dieser Offline-Weg war betrieblich bedeutsam: Die Richtlinie ging nicht davon aus, dass jemand, der die Wiederherstellung des NCP-Zugangs beantragte, noch über funktionierenden Netzwerkzugang verfügte.

Der Antragsteller musste eine detaillierte Begründung, einen Umstellungsplan, die Quelle der beabsichtigten TCP/IP-Implementierung (falls bekannt) und eine Liste von Hosts, mit denen Interoperabilität erforderlich war, vorlegen. Genannte Kontakte beim DDN-PMO wurden für weitere Informationen angegeben. Dies war ein dokumentiertes Antragsverfahren mit einer benannten Entscheidungsinstanz und festgelegten Informationsanforderungen.

News Nr. 20, am 13. Januar verteilt, veröffentlichte dann eine Tabelle mit NCP-fähigen Adressen und geplanten Umstellungsdaten. Eine direkte Zählung ergibt 44 Adress- oder Port-Zeilen. Es handelte sich nicht um 44 unabhängige Organisationen. Mehrere Einrichtungen hatten mehrere physische oder logische Host-Adressen; zwei Zeilen waren als Testports gekennzeichnet; eine weitere bezeichnete das S1-Gateway. Eine Zeile hatte ein unbekanntes Cutover-Datum. Die datierten Zeilen reichten vom 16. Januar bis 1. Mai, obwohl 25 dem 1. Februar zugewiesen waren.

Die alte abgekürzte Netzwerk-10-Notation verstärkt, was die Tabelle darstellte: betriebliche Adress- oder Port-Einträge innerhalb der ARPANET-Umgebung. Es war keine Liste von eindeutigen rechtlichen Einheiten, Verträgen, Standorten oder menschlichen Entscheidungsträgern. Es war auch kein vollständiges Verzeichnis jedes Computers, der irgendwo im weiteren DDN oder DoD noch NCP verwendete.

News Nr. 20 besagte, dass Ausnahmen für Standorte mit schwerwiegenden Dienstunterbrechungen gewährt worden waren, und betonte, dass jeder Host-Administrator einzeln die NCP-Freischaltung beantragen musste. Es hieß auch, dass die Fristen fest seien. Die Tabelle verband daher eine administrative Entscheidung mit einem konkreten Netzzustand: fortgesetzte NCP-Freischaltung für eine bestimmte Adresse bis zu einem bestimmten Datum.

Dies ist ein stärkerer Beleg als eine bloß unterstellte Abwesenheit von Governance. Es gab ein partielles öffentliches Ausnahmenverzeichnis. Die Gemeinschaft konnte sehen, welche aufgeführten Adressen NCP behielten und wann die meisten voraussichtlich umstellen würden. Die Antragsmitteilung offenbarte den Entscheidungsträger und das Material, das ein Antragsteller einreichen musste. Die Veröffentlichung der Zeilen half auch Mail-Nutzern festzustellen, wann ein Relay benötigt werden könnte.

Das Verzeichnis war in anderer Hinsicht unvollständig. Es gab keinen Grund neben jeder Adresse an. Es reproduzierte keine Anträge, unterstützende Nachweise, Bedingungen, Ablehnungen oder die Analyse hinter einzelnen Fristen. Die untersuchten Mitteilungen nennen keine unabhängige Prüfungsinstanz oder eine Berufung gegen eine DDN-PMO-Entscheidung. Sie offenbaren nicht, ob ähnliche Fälle einheitlich behandelt wurden oder ob jede vorübergehende Freischaltung in der Tabelle erschien.

Die zutreffende institutionelle Schlussfolgerung ist daher begrenzt. Der Umstellung fehlte weder ein Ausnahmeverfahren noch jegliche öffentliche Statusberichterstattung. Sie hatte eine zentrale betriebliche Entscheidungsinstanz, individuelle Anträge, vorübergehende Freischaltung, veröffentlichte Adresszeilen und Ablauffristen. Was in der öffentlichen Aufzeichnung fehlte, war eine vollständige Entscheidungsakte, eine fallbezogene Begründung und eine von der netzpolitischen Autorität unabhängige Überprüfung.

Diese Kombination passte eher zu einem gemanagten Verteidigungsnetz als zu einem öffentlichen verfassungsmäßigen System. Das DDN-PMO entschied, wie lange ein veraltetes Protokoll in einer Umgebung aktiv bleiben durfte, für die es betriebliche Verantwortung trug. Die Antragsteller waren Host-Administratoren, die fortgesetzten Dienst suchten, und keine Bürger, die ein allgemeines Recht auf Nutzung irgendeines Protokolls geltend machten. Die spätere Governance-Bedeutung ergibt sich daraus, dass die technische Umgebung und ihre gemeinsamen Aufzeichnungen über die Population hinauswuchsen, die durch diese ursprünglichen Beziehungen geregelt war.

Januar–Februar 1983: TACs und UDEL hielten die Nahtstelle am Leben

Der Cutover beseitigte nicht jegliche Vermittlung am 1. Januar. Er konzentrierte sie auf bestimmte, vorübergehende Einrichtungen.

News Nr. 20 kündigte an, dass die ARPANET Terminal Access Controllers NCP noch bis Ende Januar unterstützen würden. Ein Terminalnutzer konnte sich über einen TAC verbinden und einen zusätzlichen Befehl eingeben, um einen NCP-Host zu erreichen. Am 1. Februar sollten die TACs auf reines TCP/IP umgestellt werden.

Diese Fortführung war wichtig, weil Terminalzugang ein üblicher Weg zu Diensthosts war. Das eigene Terminal eines Nutzers implementierte keinen vollständigen Host-Protokollstapel wie ein angeschlossener Computer. Der TAC vermittelte den Terminalzugang zu Hosts. Die dortige Aufrechterhaltung der Dual-Unterstützung bewahrte einen betrieblichen Pfad für Personen, deren Ziel- oder Unterstützungssysteme die Umstellung noch nicht abgeschlossen hatten.

Die University of Delaware stellte eine weitere echte Brücke. UDEL erklärte sich bereit, ein Mail-Weiterleitungs-Relay zwischen TCP- und NCP-Nutzern zu betreiben. Ein TCP-Absender, der ein NCP-Ziel adressierte, verwendete eine UDEL-RELAY-Form, die das Empfängerkonto und den NCP-Host-Namen enthielt. Ein NCP-Absender, der einen TCP-Empfänger adressierte, verwendete UDEL-TCP. Das Relay konnte auch eine Transaktion innerhalb desselben Protokolls abschließen, wenn der aktuelle Status des Ziels unsicher war.

Dies war keine unsichtbare Übersetzung. Die Nutzer mussten das Protokoll des Absenders kennen und die Adresse entsprechend konstruieren. Falsche Adressierung konnte dazu führen, dass eine Nachricht zurückgesendet wurde. Das Relay erforderte funktionierende Mail-Software, einen erreichbaren Host, Personalkontakte, Warteschlangen- und Plattenkapazität sowie aktuelle Kenntnis des Protokollstatus des Ziels. Die veröffentlichte Ausnahmenliste sollte diese letzte Abhängigkeit leichter handhabbar machen.

Diese Anpassungen offenbaren die tatsächliche Beschaffenheit der Umstellung. Durchsetzung und Hilfe waren keine Gegensätze. Der Betreiber konnte normalen NCP-Verkehr ablehnen und gleichzeitig ausgewählte NCP-Adressen erhalten, die TAC-Unterstützung verlängern und ein Mail-Relay einrichten. Vorübergehende Kompatibilität verringerte die Störung, ohne den Stichtag aufzugeben.

Die Regelung zeigt auch, warum korrekte Aufzeichnungen betrieblich bedeutsamer wurden. Ein veralteter Fähigkeitseintrag konnte Mail in die falsche Prozedur lenken. Ein Host, der fälschlich als umgestellt angezeigt war, konnte über normale NCP-Pfade nicht mehr erreichbar sein, während ein umgestellter Host, der als NCP-only behandelt wurde, unnötige Relay-Nutzung anziehen konnte. Die UDEL-Anweisungen machten das Quellprotokoll entscheidend; die Ausnahmentabelle half, verbliebene Ziele zu identifizieren; der TAC-Zeitplan sagte den Nutzern, wann ein Terminalpfad verschwinden würde.

Diese Abhängigkeit machte das NIC nicht zur Quelle jeder Entscheidung. Das DDN-PMO gewährte die NCP-Ausnahmen. Die Netzbetreiber setzten die Freischaltung in der Vermittlungsumgebung um. UDEL betrieb das Mail-Relay. TAC-Betreiber stellten die Terminalkompatibilität bereit. Das NIC verteilte den Newsletter und die Tabelle. Jede Institution kontrollierte ein anderes Glied.

Die Relays erlegen auch kontrafaktischen Behauptungen Disziplin auf. Eine langsamere Umstellung war technisch möglich, weil der Dual-Protokoll-TAC-Dienst und die UDEL-Weiterleitung im Betrieb existierten, nicht nur auf dem Papier. Aber ihre Aufrechterhaltung erforderte Personal, Host-Kapazität, Nutzeranweisungen, Zugangskontrollen, Speicher, Adresskenntnis, Fehlerbehebung und fortlaufende Tests. Eine Verlängerung der Koexistenz hätte diese Kosten verlängert.

Es ist nicht nötig, einen Sicherheitsvorfall zu erfinden, um die Belastung zu belegen. Zwischengeschaltete Konten, gespeicherte Dateien oder Nachrichten und zusätzliche Dienstmaschinen erforderten Verwaltung, unabhängig davon, ob ein Verstoß stattfand. Die erhaltenen Quellen belegen nicht, dass ein Übergangs-Relay einen solchen Vorfall verursachte. Sie belegen, dass Relay-Zuverlässigkeit, Auslastung, Konto-Kontrolle und temporäre Speicherung als betriebliche Anliegen anerkannt waren.

Aufzeichnungen gelangten in den Betriebspfad, ohne eine einzige Autorität zu werden

Protokollumstellung, Host-Registrierung, Port-Freigabe, Nummernzuteilung und Informationsverteilung hingen zusammen, aber sie waren keine einzige Macht, die von einer Institution ausgeübt wurde.

Die Host-Tabellen-Ebene ging der Januar-Umstellung voraus.RFC 810, im März 1982 herausgegeben, ersetzte das ältere ARPANET-orientierte Tabellenformat durch ein für DoD-Internetworking entworfenes. Das neue Format beschrieb Netzwerke, Gateways, Hosts, Internetadressen, Betriebssysteme und Protokollfähigkeiten. Eine Zeile konnte TCP/Telnet von NCP/Telnet unterscheiden oder aufzeichnen, ob SMTP verfügbar war.

Die Tabelle konnte alsHOSTS.TXTvon SRI-NIC heruntergeladen oder über den Hostnames Server bezogen werden. Lokale Kopien verringerten die Abhängigkeit von einer Live-Abfrage für jede Verbindung, schufen aber ein bekanntes Konsistenzproblem: Eine alte Kopie konnte eine nicht mehr vorhandene Adresse oder einen veralteten Protokollanspruch enthalten. Die Umstellung erhöhte die Häufigkeit, mit der solche Unterschiede eine Rolle spielten, weil Nutzer und Anwendungen nicht nur einen Namen und eine Adresse, sondern auch die Kommunikationsumgebung kennen mussten, die ein Ziel unterstützte.

RFC 810 erließ auch eine formale Regel innerhalb seiner angegebenen Grenzen. Namen und Adressen für DoD-Netzwerke, Gateways und Hosts sollten vor der Nutzung und bevor ein DoD-Host ihren Verkehr durchleitete, mit dem NIC verhandelt und registriert werden. Für eine Übergangszeit würde das NIC versuchen, vergleichbare Informationen für Nicht-DoD-Netzwerke aufzubewahren, wenn die Betreiber sie lieferten.

Dieser Text legt eine Registrierungspflicht fest. Er belegt keinen dokumentierten Fall, in dem das NIC einen umstrittenen Namen ablehnte, ein ansonsten funktionsfähiges externes Netzwerk ausschloss oder aufgrund der TCP/IP-Frist einen neuen politischen Ermessensspielraum erwarb. Die Pflicht war bereits Teil der Host-Tabellen-Spezifikation von 1982. Die Umstellung machte die Genauigkeit und Reichweite der Aufzeichnung wichtiger; die Beweise zeigen nicht, dass sie die Regel schuf.

RFC 811beschrieb den NIC Hostnames Server als einen über NCP und TCP erreichbaren Dienst, der bei SRI im Auftrag der DCA betrieben wurde. Programme konnten einen Eintrag nach Namen anfordern, einen nach Adresse anfordern oder die gesamte Tabelle abrufen. Das Protokoll definierte mögliche Antworten für einen nicht gefundenen Namen oder eine nicht gefundene Adresse, einen unzulässigen Befehl oder einen vorübergehenden Systemausfall.

Diese Antwortcodes zeigen, worauf konsumierende Software vorbereitet sein musste. Sie zeigen nicht, wie oft solche Ausfälle auftraten oder identifizieren einen Nutzer, der deswegen tatsächlich einen Dienstausfall erlitt. Ein fehlender Datensatz konnte eine namensbasierte Abfrage scheitern lassen, während direkte numerische Kommunikation möglich blieb. Ein vorübergehender Serverausfall konnte durch eine lokale Tabelle gemildert werden, obwohl diese Kopie veraltet sein konnte. Der RFC stellte die einzelne globale Datenbank als Übergangslösung auf dem Weg zu einem verteilten Name-zu-Adresse-Dienst dar.

Eine direktere administrative Hürde erschien in den Betriebsmitteilungen im Zusammenhang mit der geplanten Trennung von ARPANET und MILNET. News Nr. 18 vom 17. Dezember 1982 besagte, dass eine genaue Aufzeichnung der Hosts und IMP-Ports notwendig sei, um zu vermeiden, während der Teilung dem falschen Nutzer den Dienst zu verweigern. BBN wurde angewiesen, nicht genutzte Ports zu deaktivieren und sie nur nach Freigabe durch das DDN-PMO zu aktivieren. Neue Hosts und Port-Änderungen sollten im Voraus koordiniert werden.

News Nr. 21 überarbeitete später das Verfahren. Anfragen für die Genehmigung neuer Hosts, Port-Aktivierung oder eine Host-Änderung an einem aktiven Port gingen an ein Postfach bei SRI-NIC. Die erforderlichen Angaben umfassten Host-Name und -Adresse, Standort, Hardware, Betriebssystem, Sponsor, Protokolle und Angaben zum technischen Ansprechpartner.

Hier waren Datengenauigkeit und betriebliche Aktivierung direkt verbunden. Aber der in News Nr. 18 angegebene Grund war die Netztrennung und das Port-Management, nicht allein die NCP/TCP-Umstellung. Die Entscheidungsinstanz war das DDN-PMO; BBN kontrollierte den Port-Zustand auf Anweisung; das NIC empfing, pflegte und verteilte die Information. Alle drei als „das Register“ zu behandeln, würde verschleiern, wo die Macht tatsächlich lag.

Zugewiesene Nummern bildeten eine weitere separate Ebene.RFC 820, im Januar 1983 herausgegeben, zeichnete Werte auf, die für Netzwerknummern, Protokollnummern, Ports, Sockets und andere Implementierungsfelder verwendet wurden. Er verwies Antragsteller an Jon Postel bei USC/ISI und besagte, dass Zuteilungen gemäß einer Vereinbarung zwischen DARPA's Information Processing Techniques Office und DDN-PMO gehandhabt wurden.

Eindeutige Nummern waren notwendig, um widersprüchliche Implementierungen und mehrdeutige Paketinterpretation zu verhindern. Diese Notwendigkeit schuf eine Abhängigkeit von koordinierten Zuteilungen. Das hier untersuchte erhaltene Material zeigt keine cutover-bedingte Ablehnung, keine Berufung gegen eine Zuteilungsentscheidung oder eine Vorher-Nachher-Änderung von Postels formellem Ermessen. RFC 820 dokumentiert eine Koordinationsfunktion und ihren institutionellen Rahmen; er kann allein nicht beweisen, dass das Januar-Ereignis die Befugnis dieser Funktion erweiterte.

Die Unterscheidung zwischen diesen Mechanismen ist der kausale Kern der Geschichte:

• IMP-Ablehnung machte NCP auf dem gemanagten Netz unbenutzbar, außer dort, wo es freigeschaltet war.
• DDN-PMO entschied über vorübergehende NCP-Ausnahmen und genehmigte Host- oder Port-Aktivierungen.
• Host-Organisationen implementierten und betrieben ihre eigene Protokollsoftware.
• SRI-NIC registrierte und verteilte Namen, Adressen, Fähigkeiten, Kontakte und Mitteilungen.
• USC/ISI koordinierte zugewiesene Protokoll- und Netzwerknummern.
• Gateway- und Relay-Betreiber bestimmten, ob Verkehr bestimmte technische Grenzen überschreiten konnte.
• Externe Betreiber übernahmen TCP/IP aufgrund von Finanzierungsvereinbarungen, Forschungskooperation, Beschaffungsregeln oder Interoperabilitätsanreizen, die nicht alle Befehle der DCA waren.

Der Cutover erhöhte die Abhängigkeit entlang dieser Kette. Er vereinigte die Kette nicht in einem einzigen Amt.

1972–1985: Die institutionelle Grenze verlagerte sich unter das Netzwerk

Selbst die grundlegende Chronologie mahnt zur Vorsicht, eine einzige durchgehende zentrale Autorität zu beschreiben.

Die offizielleDARPA-Zeitleistedatiert die Umbenennung von ARPA in Defense Advanced Research Projects Agency auf 1972, nicht 1973. DARPA blieb der Forschungssponsor hinter wichtiger Protokoll- und Implementierungsarbeit, mit erheblichem Einfluss auf seine Auftragnehmer und geförderten Partner.

Das Datum, an dem die DCA die betriebliche Verantwortung für das ARPANET übernahm, ist weniger sauber. Der 2011erLeitfaden zu den SRI ARC/NIC-Unterlagenbesagt, dass der Betrieb 1973 an die DCA übergeben wurde. Eine zeitgenössische DCA-Veröffentlichung nennt ein späteres formelles Datum: DieARPANET-Informationsbroschüreder Behörde von 1978 besagt, dass die Managementverantwortung am 1. Juli 1975 übertragen wurde.

Ohne die zugrundeliegenden Aufzeichnungen zur schrittweisen Übergabe sollten diese Aussagen nicht zu einer falschen Sicherheit gezwungen werden. Das spätere Findmittel beschreibt möglicherweise eine frühere betriebliche Übergabe, während die eigene Broschüre der DCA die formelle Übertragung der Managementverantwortung benennt. Für das formelle Datum ist die zeitgenössische Darstellung der DCA stärker. 1982 lassen die laufenden Mitteilungen selbst keine Unklarheit über die Betriebshierarchie: Sie wurden vom NIC für das DDN Program Management Office der DCA verteilt, und Netzmanagement-Anweisungen kamen aus dieser Struktur.

Bis Januar 1983 mussten mindestens fünf Populationen auseinandergehalten werden.

Die ARPANET-Netzwerk-10-Population war das direkte Subjekt des NCP/TCP-Plans von RFC 801 und der reinen TCP-Tests auf IMP-Ebene. Die betriebliche Kontrolle der DCA und die Ausnahmeentscheidungen des DDN-PMO hatten dort ihre klarste Wirkung.

MILNET und andere DDN-Teilnehmer gehörten zu einer größeren Verteidigungsumgebung, die noch im Aufbau und in der Differenzierung begriffen war. Ihre Protokollverpflichtungen ließen sich nicht auf jede Zeile des ARPANET-Plans reduzieren. Der 1985 alsRFC 942veröffentlichte Bericht des National Research Council besagte, dass das MILNET-Backbone selbst kein TCP erforderte, obwohl die Teilnehmer es im Allgemeinen nutzen mussten.

Andere DoD-Netzwerke folgten anderen technischen und beschaffungsseitigen Pfaden. RFC 942 beschrieb Netzwerke, die bereits TCP nutzten, Netzwerke, die spätere Umstellungen planten, und Systeme, die andere Protokolle verwendeten. Das „DoD-Internet“ war daher nicht eine Population, die ein einziges universelles Januar-Ereignis abschloss.

Externe, von DARPA finanzierte Forschungspartner konnten mit Erwartungen des Sponsors konfrontiert sein und tief in experimentelle Internet-Arbeit integriert sein. UCL, Satellitennetz-Teilnehmer, Paketfunk-Forscher und Auftragnehmer gehörten zu kooperativen Arrangements mit unterschiedlicher betrieblicher Kontrolle. Ihr Erscheinen in Protokolldokumenten oder Host-Tabellen machte nicht jede Maschine zum DCA-Teilnehmer.

Unabhängige und spätere externe Anwender waren dem Befehl der DCA noch weniger ausgesetzt. Sie konnten TCP/IP wählen, weil Implementierungen verfügbar waren, weil wertvolle Korrespondenten es nutzten oder weil inkompatible Protokolle steigende Opportunitätskosten verursachten. Dieser Netzwerkeffekt-Druck konnte stark sein, ohne eine DCA-Hoheit über ihre internen Systeme zu schaffen.

RFC 942 ist besonders nützlich, weil er diese Unterscheidungen bewahrt und zugleich die betrieblichen Folgen der Umstellung festhält. Die Arbeit des National Research Council wurde durch einen DCA-Vertrag unterstützt und 1985 veröffentlicht, es handelt sich also um eine rückblickende Bewertung, die teilweise von einer Debatte über Verteidigungsstandards geprägt ist, nicht um eine neutrale Januar-Zählung.

Der Bericht besagte, dass etwa 30 reine TCP-Hosts in den sechs Monaten vor dem Cutover zur bestehenden Dual-Protokoll-Population hinzugekommen waren. Er schrieb umfangreichen Tests zu, die Betriebsfähigkeit erhalten zu haben, und sagte, dass innerhalb weniger Monate normale Dienstniveaus erreicht wurden. Er hielt auch fest, dass das NIC nicht bereit gewesen war, die neuen Protokolle zu unterstützen, was zu Verteilungsproblemen der Host-Tabelle führte, und dass Diensthosts erhebliche Leistungsanalysen und Parameterabstimmung benötigten, weil sie zuvor über längere Zeit keine volle Nutzerlast getragen hatten.

Dies sind dokumentierte Folgen konzentrierter Abhängigkeit. Die Tabellenverteilung war eine betriebliche Abhängigkeit, nicht bloß ein administratives Symbol. Dienst-Software, die in begrenzten Tests funktionierte, konnte unter anhaltender Nachfrage immer noch ins Stocken geraten. Ein zur Ausrichtung der Implementierung fähiger Stichtag konzentrierte auch die Last auf gemeinsame Dienste.

Derselbe Bericht erschwert eine triumphale Darstellung. Er sagte, dass das ARPANET im Allgemeinen TCP nutzte, während einige Nutzer weiterhin NCP verwendeten. Diese Aussage, zwei Jahre nach dem Ziel, identifiziert nicht die beteiligten Hosts oder Pfade. Sie widerlegt jedoch jede wörtliche Behauptung, dass jede restliche Nutzung um Mitternacht universell verschwand. Richtlinienumstellung, normaler Netzdienst, Host-Software, lokale Nutzung und vorübergehende oder ausnahmsweise Erreichbarkeit waren verschiedene Zustände.

Externe Annahme: Wo das Kommando endete und die Kompatibilität begann

Der breitere Erfolg von TCP/IP hing davon ab, über die Population hinauszugehen, die die DCA managen konnte.

RFC 801 beschrieb ein ARPA-Internet, das das ARPANET mit Paketfunk-, Satelliten-, lokalen und anderen Netzwerken verband. RFC 842 und RFC 843 enthielten Adressen außerhalb von Netzwerk 10. RFC 844 zeigte, dass ein Nicht-Klasse-A-Testpfad viele Einträge erfolgreich erreichen konnte. Diese Quellen zeigen eine Internetworking-Umgebung, die Anfang 1983 technische und institutionelle Grenzen überschritt.

Sie begründen kein einheitliches rechtliches oder administratives Regime in dieser Umgebung.

Für einen Netzwerk-10-Host war die IMP-Ablehnung von NCP eine unmittelbare betriebliche Tatsache. Für ein separat gemanagtes Netzwerk konnten die entscheidenden Faktoren der Zugang zu einer TCP-Implementierung, eine Gateway-Beziehung, ein Forschungsvertrag, der Wunsch, ARPANET-Dienste zu erreichen, oder die wachsende Zahl kompatibler Korrespondenten sein. Ein Netzwerk konnte TCP/IP intern und extern nutzen, ohne die Autorität des DDN-PMO über jeden lokalen Host oder Port zu akzeptieren.

Dieser Unterschied erklärt, wie gemeinsame Aufzeichnungen bedeutsamer werden konnten als die Zuständigkeit des ursprünglichen Sponsors. Ein unabhängig betriebenes Netzwerk benötigte eindeutige Adressierungs- und Protokollwerte, wenn es mit dem breiteren Internet kommunizierte. Seine Nutzer profitierten von genauen Namensinformationen und erreichbaren Gateways. Die Abhängigkeit von gemeinsamer Koordination konnte weiter reichen als die vertragliche Autorität, die ursprünglich den Koordinationsdienst getragen hatte.

Allein die Abhängigkeit beweist jedoch kein Recht zu herrschen. Ein Aufzeichnungsführer kann bedeutsam werden, weil die Teilnehmer kompatible Informationen benötigen, während ihm die Autorität über ihre Finanzierung, internen Systeme oder Entscheidungsverfahren fehlt. Ein Sponsor mag direkte Autorität über sein eigenes Netz besitzen, externe Anwender aber nur durch Interoperabilitätsanreize beeinflussen. Die Ausbreitung von TCP/IP erweiterte daher den Bereich der Koordination, ohne diesen Bereich verfassungsmäßig einheitlich zu machen.

Dies ist auch der Grund, warum der Cutover nicht als Schöpfer aller späteren Registrierungsmacht gelten kann. Zentrale Host-Tabellen, zugewiesene Nummernkoordination und DoD-Registrierungsregeln existierten bereits. Was sich änderte, war die betriebliche Exposition einer größeren Kompatibilitätsumgebung gegenüber Fehlern, veralteten Fähigkeitsdaten, Nummernkonflikten, Gateway-Ausfällen und Verteilungsschwächen. Erhöhte Tragweite ist nicht dasselbe wie neu geschaffenes Ermessen.

Eine langsamere Umstellung war möglich, aber sie war nicht kostenlos

Die tatsächlichen TAC- und UDEL-Vorkehrungen ermöglichen es, eine historisch plausible Alternative zu modellieren, ohne spätere Technologien in das Jahr 1983 zu importieren.

Angenommen, die DCA hätte NCP über den Januar hinaus als gewöhnlichen ARPANET-Dienst beibehalten und den Host-Organisationen eine freiwillige Umstellung erlaubt. Dual-Protokoll-TACs hätten verfügbar bleiben können. UDEL oder weitere Hosts hätten die Mail-Weiterleitung fortsetzen können. Telnet- und FTP-Relay-Konten hätten Nutzer zu inkompatiblen Diensthosts überbrücken können. Standorte hätten datierte Kopien vonHOSTS.TXTherunterladen und Protokollfähigkeitsfelder nutzen können, um direkte oder relais-gestützte Pfade auszuwählen.

Dies hätte den unmittelbaren Druck auf schwierige Systeme verringert. Ein Host, der von einem unfertigen Hersteller-Port abhängig war, hätte warten können. Administratoren hätten die Umstellung um lokales Personal und Wartung herum planen können. Diensthosts hätten längeren Lasttests unterzogen werden können, bevor alle Nutzer ankamen. Das NIC hätte die TCP-basierte Verteilung verbessern können, während die Standorte den älteren Pfad beibehielten.

Der Preis wäre ein permanenter Übergangsdienst gewesen.

Dual-Protokoll-TACs benötigten fortlaufende Software-Unterstützung und Tests. Relays benötigten Konten, Speicher, Operatoren, Dokumentation und Kapazität. Eine zweistufige Dateiübertragung verbrauchte Plattenplatz und erforderte Datenpflege. Mail-Weiterleitung benötigte Warteschlangen, protokollbewusste Adressbehandlung, aktuelle Zielinformationen und Personal, das Fehler über zwei Umgebungen hinweg zurückverfolgen konnte. Terminalnutzer mussten zusätzliche Befehle verstehen und direkten von vermitteltem Zugang unterscheiden.

Die Fehlerbehebung würde weniger lokal. Eine fehlgeschlagene Sitzung konnte einen der beiden Endpunkte, einen der beiden Protokollstapel, ein Relay-Konto, ein Gateway, eine veraltete Host-Tabellen-Kopie oder ein falsches Fähigkeitsfeld betreffen. Das Unterstützungspersonal müsste Fachwissen in beiden Protokollumgebungen behalten. Tests müssten fortgesetzt werden, denn ein NCP-Pfad konnte funktionsfähig bleiben, während der entsprechende TCP-Dienst stillschweigend degenerierte, oder umgekehrt.

Der Sponsor würde weiterhin für Nicht-Konvergenz bezahlen. Host-Organisationen, die ein Relay nutzen konnten, mochten schwierige Umstellungsarbeiten aufschieben, weil ein Teil der Kosten auf den Relay-Betreiber abgewälzt worden war. Je nützlicher der Kompatibilitätsdienst wurde, desto leichter würden es Altlasten-Inseln haben zu überleben. Netzwerkeffekte könnten NCP schließlich unattraktiv machen, aber der Zeitplan wäre ungewiss, und die betriebliche Nahtstelle könnte jahrelang bestehen bleiben.

Eine freiwillige Umstellung wäre nicht notwendigerweise dezentraler gewesen. Sie hätte die Dramatik eines einzigen, vom Betreiber erzwungenen Datums verringert, aber die Abhängigkeit von den Administratoren der Relays, TACs, Fähigkeitsaufzeichnungen und Dual-Protokoll-Diensthosts erhöht. Autorität würde weniger sichtbar, anstatt zu verschwinden.

Die Alternative kann auch nicht mit der Behauptung verworfen werden, sie hätte zu einem Sicherheitsversagen geführt. Die Quellen dokumentieren keinen solchen Vorfall. Sie stützen eine bescheidenere Beobachtung: Jedes zusätzliche Konto, jeder zwischengeschaltete Host, jede gespeicherte Nachricht, jede Dateikopie und jede Alt-Implementierung erforderte Zugangskontrolle und betriebliche Sorgfalt. Das Ausmaß des resultierenden Risikos ist nicht gemessen.

Die tatsächliche Umstellung wählte eine andere Kostenverteilung. Vorübergehende Vermittlung blieb verfügbar, aber ihre Ablauffristen zwangen die Host-Organisationen, die Implementierungsarbeit zu übernehmen. DCA und DDN-PMO nutzten die Kontrolle über den Netzdienst, um diese Zuteilung glaubwürdig zu machen. Externe Netzwerke, außerhalb dieser Kontrolle, fuhren fort, TCP/IP nach ihren eigenen Zeitplänen zu übernehmen.

Wie rechenschaftspflichtigere Koordination 1983 hätte aussehen können

Eine lesbarere Umstellung erforderte keine modernen Authentifizierungssysteme, keine automatisierte globale Replikation und keine Annahmen über reichliche Rechenressourcen.

Die Zeit verfügte bereits über die notwendigen Bausteine für eine bescheidene Verbesserung: postalisch versandte Mitteilungen, namentlich genannte betriebliche Ansprechpartner, Host-Status-Erhebungen, lokaleHOSTS.TXT-Kopien, einen Antragsprozess, eine veröffentlichte Ausnahmentabelle, geplante Testtage, Telefon-Support, Relays und den manuellen Abgleich von Aufzeichnungen.

News Nr. 19 hätte zu einem vollständigen öffentlichen Entscheidungsformat für nicht-sensible Fälle ausgebaut werden können. Jede Ausnahmenzeile hätte eine kurze Grundkategorie, das Antragsdatum, das Entscheidungsdatum, das genehmigende Amt, mit der NCP-Freischaltung verbundene Bedingungen und die Angabe, ob das angegebene Umstellungsdatum eingehalten wurde, enthalten können. Sensible Einzelheiten hätten zurückgehalten werden können, ohne die Existenz und den Status der Entscheidung zu entfernen.

Ein Überprüfungsantrag hätte an einen Sponsor- oder Betriebsbeauftragten gehen können, der nicht die Erstbestimmung getroffen hatte. Ein solches Verfahren hätte die Kontrolle des DDN-PMO über das Netz nicht beseitigt. Es hätte die Erstadministration von der Überprüfung getrennt und eine Aufzeichnung darüber geschaffen, ob ähnliche betriebliche Probleme ähnlich behandelt wurden.

Statusveröffentlichungen hätten auch Populationen trennen können. Eine Netzwerk-10-Konformitätstabelle, eine DDN-Teilnehmertabelle und eine informative Liste externer Interneteinträge hätten verhindert, dass eine gemischte Host-Tabelle mit einer einzigen regierten Gemeinschaft verwechselt wurde. Die Ergebnisse hätten zwischen registrierter Fähigkeit, einer akzeptierten Anwendungsverbindung, einem erfolgreichen Routing-Test aus einer anderen Adressklasse, einer genehmigten NCP-Ausnahme, vorübergehender Nichtverfügbarkeit und einem unerklärten Ergebnis unterscheiden können.

Verteilungs-Resilienz war in begrenzter Form möglich. Mehr als ein schreibgeschützter Host hätte datierte Kopien der Host-Tabelle bereitstellen können. Betreiber hätten Versionsdaten vergleichen und manuelle Konsistenzprüfungen gegen die NIC-Kopie durchführen können. Dies würde die Abhängigkeit von einer Verteilungsmaschine während eines Ausfalls verringern. Es würde die Aktualisierungshoheit nicht dezentralisieren: Wenn jeder Spiegel denselben fehlerhaften Master-Datensatz reproduzierte, bliebe der Fehler maßgeblich.

Solche Maßnahmen hätten Personalzeit, Speicher, Telefon-Koordination und zusätzlichen Abgleichsaufwand gekostet. Aufzeichnungen konnten voneinander abweichen. Die Veröffentlichung konnte hinter dringenden betrieblichen Änderungen zurückbleiben. Einige Verteidigungsinformationen konnten nicht offengelegt werden. Eine zweite Überprüfung könnte eine Entscheidung verzögern, die schnell benötigt wurde, um den Dienst wiederherzustellen oder zu schützen.

Diese Kosten sind genau der Grund, warum Rechenschaftspflicht nicht als kostenlose Ergänzung zur technischen Koordination behandelt werden kann. Der relevante Vergleich ist der zwischen den Kosten für die Pflege klarerer Aufzeichnungen und den Kosten, die entstehen, wenn Betreiber nicht feststellen können, ob ein Fehler technisch, administrativ, vorübergehend oder beabsichtigt ist.

Die Umstellungsaufzeichnung legt nahe, dass diese Unterscheidung nützlich gewesen wäre. RFC 842 konnte zeigen, dass eine Adresse einen Dienst nicht akzeptierte, aber nicht warum. News Nr. 20 konnte zeigen, dass eine Adresse NCP behielt, aber nicht den vollständigen Grund. Das NIC konnte eine Protokollbehauptung veröffentlichen, aber nicht den beobachteten Betrieb garantieren. Das DDN-PMO konnte einen Port genehmigen, aber die Genehmigung konnte eine fehlerhafte Implementierung nicht reparieren. Eine bessere Aufzeichnung würde diese Zustände nicht kollabieren lassen; sie würde sie getrennt halten.

Die Autorität, die sich veränderte, war durch das Netzwerk begrenzt

Die Januar-Umstellung war in ihrem hauptsächlichen betrieblichen Zweck erfolgreich. TCP/IP wurde die normale Kommunikationsumgebung des ARPANET, wichtige Dienste zogen darauf um, und heterogene Netzwerke konnten über eine gemeinsame Internetwork-Schicht teilnehmen. Die Februar-Erhebungen zeigen Hunderte von akzeptierenden Dienstendpunkten, während sie zugleich unvollständigen und pfadabhängigen Betrieb zeigen.

Die Kraft der Umstellung rührte von einer spezifischen institutionellen Struktur. DARPA finanzierte Forschung und beeinflusste Auftragnehmer. Die DCA managte das ARPANET formal ab Mitte der 1970er Jahre. Das DDN-PMO gab die Betriebspolitik vor, entschied über NCP-Ausnahmen und genehmigte Hosts oder Ports. Die IMPs und Netzbetreiber setzten die Protokolldeaktivierung durch. Die Host-Organisationen kontrollierten die Implementierung auf ihren Rechnern. SRI-NIC registrierte und verteilte betriebliche Informationen. USC/ISI koordinierte zugewiesene Nummern. TAC- und Relay-Betreiber erhielten vorübergehende Erreichbarkeit.

Diese Aufteilung verhindert die stärkste Version der Zentralisierungsbehauptung. Die Beweise zeigen nicht, dass der Cutover selbst SRI-NIC eine neue Macht verlieh, zu entscheiden, wem ein Name zustand, oder USC/ISI eine neue Macht, externe Netzwerke durch Nummernzuteilungen auszuschließen. Sie zeigen, dass genaue Namen, Adressen, Protokollfähigkeiten, Nummernwerte und Verteilungsdienste betrieblich wichtiger wurden, als mehr Kommunikation auf TCP/IP konvergierte.

Der ausgeübte Druck lag anderswo. Die NCP-Ablehnung auf IMP-Ebene machte die Autorität von Sponsor und Betreiber konkret. Individuelle Freischaltungen und Ablauffristen machten den Ermessensspielraum des DDN-PMO für betroffene Netzwerk-10-Adressen folgenreich. Die Host- und Port-Genehmigung verband administrative Daten mit der Netzaktivierung während der ARPANET/MILNET-Trennung. Die späteren Verteilungsprobleme der Host-Tabelle durch das NIC demonstrierten eine Abhängigkeit von einem gemeinsamen Informationsdienst, keine politische Verweigerung.

Die Koordination zugewiesener Nummern bewahrte die Eindeutigkeit, aber die untersuchte Aufzeichnung liefert keine cutover-bezogene Ablehnung oder Berufung.

Jenseits der gemanagten Population ersetzten Kompatibilitätsanreize das direkte Kommando. Externe Betreiber übernahmen TCP/IP, weil die Interoperation mit einer wachsenden Gemeinschaft nützlich war, weil Sponsoren oder Beschaffungsprogramme es unterstützten oder weil Implementierungen verfügbar wurden. Ihre technische Abhängigkeit von gemeinsamen Identifikatoren machte ihre Netzwerke nicht zum Eigentum von DCA, DARPA, SRI oder ISI.

Die institutionelle Errungenschaft und das Legitimitätsproblem sind daher verschieden. Die Errungenschaft war die koordinierte Interoperabilität über heterogene Systeme hinweg. Das Legitimitätsproblem bestand darin, dass die wachsende betriebliche Abhängigkeit die Entscheidungsaufzeichnungen, Überprüfungsverfahren und Kontinuitätsvorkehrungen von Institutionen überholen konnte, die für eine kleinere, vom Sponsor kontrollierte Umgebung geschaffen worden waren.

Der 1. Januar war wichtig, weil er die unbefristete Koexistenz als Standardpolitik des ARPANET beendete. Die Experimente vom Oktober, November und Dezember demonstrierten, wie diese Politik durchgesetzt werden würde. Das Januar-Ausnahmenverzeichnis zeigte, dass die Durchsetzung eher selektiv und vorübergehend als absolut war. TACs und UDEL bewahrten wesentliche Nahtstellen. Die Februar-Erhebungen zeigten, dass formelle Umstellung, aufgezeichnete Fähigkeit, Anwendungsantwort und geroutete Erreichbarkeit noch immer verschiedene Tatsachen waren.

Der Cutover veränderte Autorität, indem er einige bestehende Befugnisse betrieblich entscheidend machte: die Macht, ein Protokoll zu deaktivieren, eine vorübergehende Fortführung zu genehmigen, einen Port zu aktivieren, eine gemeinsame Aufzeichnung zu verteilen oder ein Relay zu unterhalten. Er erhöhte auch die Abhängigkeit von Koordination jenseits der Reichweite dieser Befugnisse. Das ist präziser, als zu sagen, eine einzige Autorität habe das Internet umgestellt—und folgenreicher als die Legende von einer makellosen Mitternacht.