Der Flaggentag, der die Autorität veränderte: Governance nach der TCP/IP-Migration

Zusammenfassung

• Der Übergang im Januar 1983 war substanziell, aber ungleichmäßig: Die Messungen im Februar fanden Hunderte von TCP-Dienstendpunkten, aber die Ergebnisse unterschieden sich je nach Dienst, Adresspopulation, Testdatum und Netzwerkpfad, und sie beschrieben keine universelle Bevölkerung, die um Mitternacht umschaltete.
• Der Hebel des Sponsors und Betreibers wurde durch die Ablehnung von NCP-Verkehr auf IMP-Ebene, die Ausnahmeentscheidungen des DDN-PMO und die Aktivierung von Hosts oder Ports ausgeübt; die Abhängigkeit von den Aufzeichnungen des SRI-NIC und der Nummernkoordination durch die USC/ISI nahm operativ zu, ohne dass es Beweise dafür gab, dass die Migration einem der Büros neue Ermessensbefugnisse verlieh.
• Das Ausnahmeverfahren war real, aber teilweise und nicht unabhängig: Administratoren konnten Ansprüche einreichen, eine öffentliche Liste verzeichnete die vorübergehende NCP-Aktivierung und Ablaufdaten, und die TAC- und UDEL-Relais bewahrten eine eingeschränkte Erreichbarkeit, aber veröffentlichte Begründungen, vollständige Entscheidungsunterlagen und eine Überprüfung außerhalb des DDN-PMO fehlten.

Am 1. Februar 1983, einen Monat nach dem ARPANET-Ziel der Umstellung von NCP auf TCP/IP, versuchte ein Test von ISI-VAXA aus, jede Adresse in einer aktuellen Host-Tabelle des Network Information Center zu erreichen. Das Ergebnis war kein sauber geteiltes Netz zwischen Vergangenheit und Zukunft. Es war ein Festbreitenbericht mit akzeptierten Verbindungen, Ablehnungen, unerreichbaren Adressen, toten Systemen und leeren Ergebnisfeldern.

Die Host-Liste wurde der NIC-Tabelle vom 28. Januar entnommen. Die Tests wurden am 1. und 2. Februar von ISI-VAXA aus durchgeführt, tote, unerreichbare und ablehnende Einträge wurden am 3. Februar erneut getestet. Die Umfrage versuchte drei TCP-Dienste: Telnet, FTP und SMTP. Sie überprüfte keine Software, testete nicht alle TCP- oder IP-Funktionen, bewies nicht, dass ein Host kontinuierlich verfügbar war, und zählte nicht alle Computer auf, die mit den Netzwerkentitäten verbunden waren. Sie zeichnete auf, was geschah, wenn ein Ursprung zu bestimmten Zeiten bestimmte Dienstports ansprach.

Der Nenner inRFC 842, „Who Talks TCP?“betrug 328 Adresszeilen. Davon begannen 200 mit der Netznummer 10, dem Adressraum des ARPANET, und 128 gehörten zu anderen Netzen. Eine Zeile war nicht unbedingt ein physischer Computer, eine Institution, ein DDN-Teilnehmer oder eine einzelne Organisation. Ein benanntes System konnte unter mehreren Adressen erscheinen; auch Gateways und andere betriebliche Einträge konnten in der Tabelle erscheinen. Umgekehrt war ein nicht registriertes, getrenntes, klassifiziertes oder weggelassenes System außerhalb der gemessenen Population.

Eine direkte Neuzählung der Ergebniszeilen der RFC 842 ergibt die folgende Prüfung. Das Ergebnisaccepted+von FTP ist in „akzeptiert“ enthalten. Eine Tot- oder Unerreichbarkeitsangabe, die die Dienstspalten abdeckt, wird für jeden Dienst in diesem Zustand gezählt.

Diese Kategorien beschreiben Beobachtungen, keine Erklärungen. Ein toter Eintrag könnte voll funktionsfähige TCP-Software auf einer Maschine gehabt haben, die ausgeschaltet war. Eine unerreichbare Adresse könnte auf ein Gateway-, Routing-, Adressierungs- oder Messproblem hinweisen. Eine Ablehnung könnte bedeuten, dass Pakete einen TCP-Endpunkt erreichten, die Anwendung die angeforderte Sitzung jedoch nicht akzeptierte. Ein leeres Ergebnis verrät nicht, ob der Fehler vom Host, vom Pfad, vom Dienst oder von der Tabelle herrührte.

Die Akzeptanz auf einem Port beweist keine vollständige Konformität mit TCP, IP, ICMP, Routing, Namensverwaltung und Kernanwendungen.

Die Host-Tabelle war auch keine Zählung der Konformität mit dem Januar-Ziel des Sponsors. Ihre 128 Nicht-Netz-10-Zeilen umfassten Systeme auf unabhängig betriebenen, Forschungs-, lokalen, ausländischen, Paketfunk-, Satelliten- und anderen Netzen. Ihr Erscheinen demonstrierte die Teilnahme an einer wachsenden Internet-Umgebung. Sie zeigte nicht, dass die Defense Communications Agency all ihren Betreibern die Migration befehlen konnte.

Der „Flag Day“ des Titels ist daher ein rückblickendes Etikett, nicht die übliche Sprache der Betriebsarchive. Zeitgenössische Mitteilungen sprachen von einer Umschaltung, einer Umstellung oder einem Nur-TCP-Experiment. 1997 beschrieb eine von mehreren führenden Einrichtungen verfasste Geschichte der Internet Society das Ereignis alsFlag-Day-ähnlichen Übergang. Diese spätere Erzählung erfasste die koordinierende Kraft der Frist, komprimierte aber die ungleichmäßige Umsetzung, die die Februartabellen bewahrten.

Die Umstellung war dennoch folgenreich. Es war eine vom Sponsor unterstützte Entscheidung, die NCP/TCP-Koexistenz nicht länger als normale Zukunft des ARPANET zu betrachten. Ihre Bedeutung liegt nicht in einem mythischen Mitternachtswandel, sondern in den Mechanismen, die das Ziel glaubwürdig machten: Tests, die NCP im Vermittlungsnetz deaktivierten, ein vom Betreiber verwaltetes Ausnahmeverfahren, temporäre Unterstützung durch Relais und Terminals, die Genehmigung von Hosts und Ports und eine wachsende Abhängigkeit von genauen gemeinsamen Aufzeichnungen.

1.–18. Februar 1983: Veränderte Beobachtungen waren keine Einführungskurve

Eine zweite Untersuchung zeigt, warum aggregierte Summen nicht leicht in eine Erzählung regelmäßiger Einführung umgewandelt werden können.

RFC 843verwendete die NIC-Host-Tabelle vom 3. Februar und testete am 8. und 9. Februar von ISI-VAXA aus. Ihre Population war von 328 auf 329 Zeilen angewachsen. Die akzeptierten Gesamtzahlen betrugen 187 für Telnet, 174 für FTP und 170 für SMTP, gegenüber 183, 170 und 169 im vorherigen Bericht. Aber die Netz-10- und Nicht-Netz-10-Gruppen entwickelten sich in entgegengesetzte Richtungen.

Die akzeptierten Netz-10-Zahlen stiegen bei allen drei Diensten. Die Zahlen der anderen Netze sanken bei allen drei. Die zugrunde liegende Tabelle änderte sich ebenfalls um eine Zeile, und einzelne Maschinen konnten während eines Tests laufen und während eines anderen nicht verfügbar sein. Ohne eine Analyse nach gepaarten Einträgen, die Hinzufügungen, Löschungen, vorübergehende Ausfälle und geänderte Pfade kontrolliert, zeigen die beiden Untersuchungen veränderte Beobachtungen und keine gemessene Einführungsrate.

Zehn Tage später stellteRFC 844eine andere Frage. Sie wählte die 187 Einträge aus, die Telnet in RFC 843 akzeptiert hatten, und versuchte, sie von einem Terminalkonzentrator im Klasse-C-Netz 192.1.2 bei BBN zu erreichen. Der Erfolg erforderte mehr als einen Telnet-Dienst, der auf dem vorherigen Pfad akzeptierte: Pakete und Antworten mussten durch Gateway-Routing, Klasse-C-Adressierung und relevantes ICMP-Verhalten funktionieren.

Die Verbindungen wurden manuell über gepunktete Adressen eingegeben, und es wurden nur drei Durchläufe durchgeführt. Ein während dieser Durchläufe nicht verfügbarer Host konnte verpasst werden. Die Ergebnisse zeigten dennoch, wie sehr ein scheinbarer TCP-Erfolg von der Testquelle und dem Netzpfad abhing.

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

Zusammen etablieren die drei Berichte eine engere, aber wertvolle Tatsache. Einen Monat nach dem Ziel akzeptierten Hunderte von Tabellenzeilen die wichtigsten TCP-Dienste, während die aufgezeichnete Kapazität, die Anwendungsverfügbarkeit und die Erreichbarkeit von verschiedenen Quellen aus ungleichmäßig blieben. Die Umstellung hatte einen substanziellen Betrieb hervorgebracht, keine sofortige Einheitlichkeit.

Dies ist die erste Governance-Grenze. Die Messung machte die Implementierung sichtbar, aber die Messung entschied nicht, warum ein Host fehlschlug oder welche Abhilfe folgen sollte. Diese Entscheidungen lagen bei den Host-Administratoren, Implementierern, Gateway- und Vermittlungsbetreibern, dem NIC, dem DDN Program Management Office, den Forschungsförderern und, außerhalb der vom Sponsor kontrollierten Population, bei den Betreibern autonomer Netze.

November 1981: Der Plan war dazu gedacht, die Vermittlung zu beenden

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

RFC 801, veröffentlicht im November 1981, setzte den 1. Januar 1983 als Ziel für eine vollständige Umstellung des ARPANET von NCP auf IP und TCP. Sie forderte jede Host-Organisation auf, bis zum 1. Januar 1982 mit der Implementierung von IP/TCP zu beginnen, und wies die gleiche lokale Verantwortung für Telnet, Dateitransfer und E-Mail zu. Neue ARPANET-Hosts sollten mit TCP/IP beginnen, anstatt über NCP einzusteigen.

Die Meilensteine des Plans offenbaren sein tatsächliches Design. Es gab bereits Hosts, die TCP und nur TCP konnten. Relaisdienste sollten die Brücke zwischen inkompatiblen Hosts schlagen. Die letzte NUR-NCP-Umstellung sollte im Januar 1982 beginnen; die meisten Hosts sollten bis Juli TCP-fähig sein; die endgültige Umstellung sollte im November abgeschlossen sein. Erst dann sollte der Januar 1983 einen vollständigen TCP-basierten Dienst, die Abschaltung von NCP und das Ende der normalen Relaisunterstützung bringen.

Die Implementierung blieb verteilt. Die Host-Organisationen des ARPANET kontrollierten Maschinen mit unterschiedlichen Prozessoren, Betriebssystemen, Personal, Softwarequellen und lokalen Dienstleistungsanforderungen. Der Sponsor konnte eine Frist ankündigen und Implementierungen finanzieren, aber er konnte keine fehlerhafte Prüfsummenroutine per Dekret korrigieren. Ein Host konnte über IP und TCP verfügen, aber kein SMTP haben. Ein System, das über ein Gateway funktionierte, konnte eine andere Route, Optionen, Fragmentierung oder ICMP falsch handhaben.

Die RFC 801 selbst warnte vor Implementierungen, die Prüfsummen übersprangen, Fragmente nicht wieder zusammensetzen konnten, sich auf begrenzte Routing-Daten verließen, Optionen ignorierten, TCP-Daten falsch ordneten oder statische Namenstabellen führten.

Was das Ziel bewirken konnte, war, die Kosten der Verzögerung zu ändern. Eine Host-Organisation konnte die NCP-Software auf ihrem eigenen Computer behalten, aber sie konnte den ARPANET-Betreiber nicht zwingen, NCP-Verkehr auf unbestimmte Zeit weiterzuleiten. Sobald das Vermittlungsnetz den alten Verkehr ablehnte und die regulären Relais endeten, wurde eine unvollendete lokale Implementierung zu einem Erreichbarkeitsproblem für den Host und seine Benutzer.

Die RFC 801 modellierte, warum eine verlängerte Koexistenz nicht attraktiv war. Nur-NCP- und Nur-TCP-Endgeräte konnten nicht direkt kommunizieren, daher mussten Doppelprotokoll-Relais-Hosts die Vermittlung von Telnet, FTP und E-Mail übernehmen. Telnet beinhaltete ein Zwischenkonto und eine zweite Verbindung. FTP konnte erfordern, eine Datei auf den Relais-Speicher zu verschieben und dann erneut zu übertragen. E-Mail erforderte eine Übertragungslogik und eine protokollbewusste Adressierung.

Jedes Relais fügte eine weitere Maschine hinzu, die verfügbar sein musste, und einen weiteren Dienst, der Kapazität, Zugriffskontrolle, Dokumentation und Support erforderte.

Das numerische Relaislastmodell des Dokuments war ausdrücklich spekulativ, aber sein institutionelles Argument war solide. Eine unbestimmte Koexistenz war keine neutrale Bewahrung der Wahl. Jemand musste die Naht zwischen den beiden Umgebungen finanzieren und betreiben. Eine Frist verlagerte diese Last von den Relaisbetreibern auf die Host-Organisationen, die ihre Umstellungen nicht abgeschlossen hatten.

Der Plan allein beweist nicht, dass diese Verlagerung stattfand. Das Ausführungsdossier erscheint in einer anderen Quelle: den Betriebsinformationen, die vom NIC im Auftrag der DCA und ihres DDN Program Management Office verteilt wurden.

Oktober–Dezember 1982: Die Durchsetzung erfolgte in den IMPs

Am 1. Oktober 1982, von 12:00 bis 16:00 Uhr Eastern Time, führte das ARPANET ein Nur-TCP-Experiment durch. Während dieser vier Stunden wurden die Interface Message Processor angewiesen, Host-Nachrichten unter Verwendung von Link 0, dem Link, der mit dem NCP-Host-zu-Host-Verkehr verbunden ist, abzuweisen. Der IMP gab einen Status vom Typ 7, Untertyp 3 zurück, der anzeigte, dass die Kommunikation mit dem Ziel „administrativ verboten“ war.

Dieser Mechanismus, beschrieben inARPANET News Nr. 14, ist der klarste Beweis für den operativen Zwang bei der Umstellung. Das NCP wurde nicht einfach in einem Dokument abgewertet. Die Paketvermittlungsinfrastruktur lehnte den betreffenden Verkehr ab. Nur-NCP-Hosts konnten das ARPANET während des Tests nicht nutzen. Dual-Protokoll-Systeme mit gemeinsamem Remote-Host-Status konnten ebenfalls Probleme haben, sofern Administratoren ihre NCP-Implementierung während des Zeitraums nicht deaktivierten.

Der Durchsetzungspunkt ist wichtig. Es war nicht das SRI-NIC, das einen Namen löschte, noch die USC/ISI, die eine Nummer verweigerte. Die IMPs führten die Ablehnung unter Netzmanagementanweisungen durch, wobei das Network Operations Center und die mit der DCA verbundene Leitung für die Betriebsumgebung verantwortlich waren. Der zurückgegebene Status sollte die administrative Natur der Ablehnung für den sendenden Host sichtbar machen.

News Nr. 16 erinnerte die Administratoren an den Test vom 1. Oktober und forderte die Entitäten auf, ihre Beobachtungen an Jon Postel, das NOC und das NIC zu melden. Es drängte die Standorte auch, SMTP und die Vier-Oktett-Internetadressierung bis Januar zu implementieren. Hier kombinierte die Koordination mehrere Funktionen: Das Vermittlungsnetz schuf die Testbedingung; die Implementierer und Host-Administratoren beobachteten die Ausfälle; die ISI empfing die technischen Berichte; das NOC überwachte den Betrieb; und das NIC verbreitete die Anweisungen und sammelte Implementierungsinformationen.

Das vierstündige Experiment wurde von längeren Wiederholungen gefolgt.News Nr. 17kündigte 24-stündige Nur-TCP-Perioden am 15. November sowie am 13. und 14. Dezember an. Es würde dieselbe Ablehnungsmethode auf IMP-Ebene verwendet werden. Die Mitteilung warnte ausdrücklich, dass dies auch der beabsichtigte Mechanismus nach dem Ziel des 1. Januar sei.

Diese Tests lieferten Informationen, die keine Host-Tabellenbehauptung liefern konnte. Ein Standort konnte erklären, dass er TCP habe, und dennoch während eines Tages ohne NCP feststellen, dass ein Produktionsdienst, eine E-Mail-Software, ein Terminalpfad, ein Gateway oder eine lokale Betriebsprozedur noch auf NCP angewiesen war. Ein Host konnte einen Labortest bestehen, aber unter dem Verkehr und Benutzerverhalten einer vollständigen Betriebsperiode scheitern. Die Wiederholung des Experiments erhöhte die Wahrscheinlichkeit, dass die Abhängigkeit entdeckt wurde, bevor die dauerhafte Netzrichtlinie änderte.

Die Tests schufen auch einen Hebel. Ein vom Sponsor kontrollierter Host, der nicht migriert war, konnte während des Tests nicht einfach das alte Protokoll weiterverwenden. Seine Benutzer erlitten die Konsequenz der Nicht-Migration, und seine Administratoren erhielten einen spezifischen Status vom Netz. Dies war materiell anders als die Überzeugung über eine RFC.

Dennoch war der Hebel begrenzt. Er galt direkt für den NCP-Verkehr, der über die ARPANET-IMPs eingespeist wurde. Er erreichte kein unabhängiges lokales Netz, das NCP intern betrieb, ein externes Netz, das dem ARPA-Internet nicht beigetreten war, oder jede Nicht-Netz-10-Adresse, die später in RFC 842 aufgeführt wurde. Von der DARPA finanzierte Forschungspartner konnten mit vertraglichen Erwartungen oder starken Anreizen zur Interoperabilität konfrontiert sein, aber diese Beziehungen waren nicht identisch mit der Kontrolle der DCA über die ARPANET-Operationen.

Dieselbe Unterscheidung schränkt Behauptungen bezüglich der Registrierung ein. Die Tests beweisen, dass der Betreiber ein Protokoll auf Vermittlungsebene deaktivieren konnte. Sie beweisen nicht, dass die Migration dem NIC neue Ermessensbefugnisse über Namen oder der USC/ISI neue Befugnisse über Nummernzuweisungen gab. Diese administrativen Funktionen waren für die Interoperabilität wichtig, aber der beobachtete Zwangsakt fand woanders statt.

Januar 1983: Ausnahmen waren öffentlich, aber nur teilweise

Die Betriebspolitik bestand nicht aus einer Frist ohne Aufschubmöglichkeit.

Datiert vom 22. Dezember 1982 gabARPANET News Nr. 19an, dass nach 00:01 Uhr Eastern Time am 1. Januar die Nutzung von NCP ohne eine spezifische Ausnahme des DDN Program Management Office nicht erlaubt sei. Es gab der Ausnahmeanfrage einen Namen –reclama– und erklärte, wie sie einzureichen sei.

Vor Januar konnte eine Anfrage per Netzpost an die DDN-PMO-Adressen gesendet werden, mit Kopien an das NIC. Nach der Frist konnte ein Administrator, der das Netz nicht nutzen konnte, die Anfrage per US-Post an den Hauptsitz der DCA senden. Dieser Offline-Weg war betrieblich bedeutsam: Die Politik ging nicht davon aus, dass jemand, der die Wiederherstellung des NCP-Zugangs suchte, noch über einen funktionierenden Netzwerkzugang verfügte.

Der Antragsteller musste eine detaillierte Begründung, einen Umstellungszeitplan, die Quelle der geplanten TCP/IP-Implementierung, falls bekannt, und eine Liste der Hosts angeben, mit denen Interoperabilität erforderlich war. Namentlich genannte Ansprechpartner des DDN-PMO wurden für weitere Informationen bereitgestellt. Es handelte sich um einen dokumentierten Antragsprozess mit einer identifizierten Entscheidungsbehörde und festgelegten Informationsanforderungen.

News Nr. 20, verteilt am 13. Januar, veröffentlichte anschließend eine Tabelle der aktivierten NCP-Adressen und geplanten Umstellungstermine. Eine direkte Zählung ergibt 44 Adress- oder Portzeilen. Es handelte sich nicht um 44 unabhängige Organisationen. Mehrere Institutionen hatten mehrere physische oder logische Host-Adressen; zwei Zeilen waren als Testports gekennzeichnet; eine andere identifizierte das S1-Gateway. Eine Zeile hatte ein unbekanntes Umstellungsdatum. Die datierten Zeilen reichten vom 16. Januar bis zum 1. Mai, obwohl 25 auf den 1. Februar fielen.

Die alte Netz-10-Kurznotation unterstreicht, was die Tabelle darstellte: betriebliche Adress- oder Porteinträge in der ARPANET-Umgebung. Es war keine Liste von Rechtspersonen, Verträgen, Standorten oder einzelnen menschlichen Entscheidern. Es war auch kein vollständiges Inventar jedes Computers mit residuellem NCP irgendwo im DDN oder im weiteren DoD.

News Nr. 20 sagte, dass Ausnahmen an Standorte gewährt worden seien, die mit schwerwiegenden Dienstunterbrechungen konfrontiert waren, und betonte, dass jeder Host-Administrator individuell die NCP-Aktivierung beantragen müsse. Es sagte auch, dass die Fristen fest seien. Die Tabelle verband daher eine administrative Entscheidung mit einem konkreten Netzwerkzustand: die Aufrechterhaltung der NCP-Aktivierung für eine bestimmte Adresse bis zu einem bestimmten Datum.

Dies ist ein stärkerer Beweis als eine abgeleitete Governance-Abwesenheit. Es gab ein öffentliches Teilregister der Ausnahmen. Die Gemeinschaft konnte sehen, welche gelisteten Adressen NCP behielten und wann die meisten migrieren sollten. Die Antragsmitteilung offenbarte den Entscheider und das Material, das ein Antragsteller einreichen musste. Die Veröffentlichung der Zeilen half auch E-Mail-Nutzern zu bestimmen, wann ein Relais erforderlich sein könnte.

Das Register war in anderer Hinsicht unvollständig. Es gab keinen Grund neben jeder Adresse an. Es reproduzierte nicht die Anträge, unterstützenden Beweise, Bedingungen, Ablehnungen oder die Analyse hinter den einzelnen Fristen. Die untersuchten Mitteilungen identifizieren kein unabhängiges Überprüfungsorgan oder eine Berufung gegen eine Entscheidung des DDN-PMO. Sie offenbaren nicht, ob ähnliche Fälle konsistent behandelt wurden oder ob jede vorübergehende Aktivierung in der Tabelle erschien.

Die präzise institutionelle Schlussfolgerung ist daher begrenzt. Dem Übergang fehlte es weder an einem Ausnahmeverfahren noch an einem öffentlichen Statusbericht. Es gab einen zentralen operativen Entscheider, individuelle Anträge, vorübergehende Aktivierung, veröffentlichte Adresszeilen und Ablaufdaten. Was in der öffentlichen Aufzeichnung fehlte, war ein vollständiger Entscheidungsdatensatz, eine Begründung pro Fall und eine unabhängige Überprüfung der Autorität, die die Netzwerkpolitik verwaltete.

Diese Kombination passte eher zu einem verwalteten Verteidigungsnetz als zu einem öffentlichen Verfassungssystem. Das DDN-PMO entschied, wie lange ein veraltetes Protokoll in einer Umgebung aktiv bleiben konnte, für die es die Betriebsverantwortung trug. Die Antragsteller waren Host-Administratoren, die den Dienst aufrechterhalten wollten, keine Bürger, die ein allgemeines Recht auf Nutzung eines beliebigen Protokolls beanspruchten.

Die spätere Bedeutung für die Governance ergibt sich daraus, dass sich die technische Umgebung und ihre gemeinsamen Aufzeichnungen über die Bevölkerung hinaus ausdehnten, die von diesen ursprünglichen Beziehungen regiert wurde.

Januar–Februar 1983: TAC und UDEL hielten die Naht am Leben

Die Migration eliminierte nicht jede Vermittlung am 1. Januar. Sie konzentrierte sie auf spezifische und temporäre Einrichtungen.

News Nr. 20 kündigte an, dass die ARPANET Terminal Access Controller während des Monats Januar weiterhin NCP unterstützen würden. Ein Terminalbenutzer konnte sich über einen TAC verbinden und einen zusätzlichen Befehl eingeben, um einen NCP-Host zu erreichen. Am 1. Februar sollten TACs ausschließlich TCP/IP werden.

Diese Fortsetzung war wichtig, weil der Terminalzugang ein üblicher Weg zu Diensthosts war. Das eigene Terminal eines Benutzers implementierte keinen vollständigen Host-Protokollstapel wie ein angeschlossener Computer. Der TAC vermittelte den Terminalzugang zu Hosts. Die Aufrechterhaltung der Doppelunterstützung bewahrte einen operativen Pfad für Personen, deren Ziele oder unterstützende Systeme die Umstellung nicht abgeschlossen hatten.

Die University of Delaware stellte eine weitere reale Brücke bereit. UDEL erklärte sich bereit, ein E-Mail-Transfer-Relay zwischen TCP- und NCP-Benutzern zu betreiben. Ein TCP-Absender, der ein NCP-Ziel adressierte, verwendete eine Form UDEL-RELAY, die das Konto des Empfängers und den NCP-Hostnamen enthielt. Ein NCP-Absender, der einen TCP-Empfänger adressierte, verwendete UDEL-TCP. Das Relay konnte auch innerhalb desselben Protokolls durchführen, wenn der aktuelle Status des Ziels unsicher war.

Dies war keine unsichtbare Übersetzung. Benutzer mussten das Protokoll des Absenders kennen und die Adresse entsprechend aufbauen. Eine falsche Adressierung konnte zur Rückgabe einer Nachricht führen. Das Relay erforderte funktionierende E-Mail-Software, einen erreichbaren Host, persönliche Kontakte, Warteschlangen- und Plattenkapazität sowie aktualisiertes Wissen über den Zielprotokollstatus. Die veröffentlichte Ausnahmeliste sollte diese letzte Abhängigkeit handhabbarer machen.

Diese Vorkehrungen offenbaren die tatsächliche Textur der Umstellung. Durchsetzung und Unterstützung waren keine Gegensätze. Der Betreiber konnte gewöhnlichen NCP-Verkehr ablehnen, während er bestimmte NCP-Adressen beibehielt, die TAC-Unterstützung erweiterte und ein E-Mail-Relay organisierte. Die temporäre Kompatibilität reduzierte Störungen, ohne die Frist aufzugeben.

Die Vereinbarung zeigt auch, warum genaue Aufzeichnungen betrieblich folgenreicher wurden. Ein veralteter Kapazitätseintrag konnte E-Mails in die falsche Prozedur leiten. Ein fälschlicherweise als migrierter gekennzeichneter Host konnte über gewöhnliche NCP-Pfade nicht mehr erreichbar sein, während ein migrierter, aber als Nur-NCP behandelter Host unnötige Relay-Nutzung anziehen konnte. Die UDEL-Anweisungen machten das Quellprotokoll entscheidend; die Ausnahmetabelle half, residuelle Ziele zu identifizieren; der TAC-Zeitplan sagte Benutzern, 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. Netzbetreiber implementierten die Aktivierung in der Vermittlungsumgebung. UDEL betrieb das E-Mail-Relay. TAC-Betreiber stellten die Terminalkompatibilität bereit. Das NIC verteilte das Bulletin und die Tabelle. Jede Institution kontrollierte ein anderes Glied.

Die Relais erlegen auch Disziplin gegenüber kontrafaktischen Behauptungen auf. Eine langsamere Umstellung war technologisch möglich, weil der Doppelprotokoll-TAC-Dienst und der UDEL-Transfer tatsächlich in Betrieb waren, nicht nur auf dem Papier. Aber ihre Aufrechterhaltung erforderte Personal, Host-Kapazität, Benutzeranweisungen, Zugriffskontrollen, 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. Zwischenkonten, gespeicherte Dateien oder Nachrichten und zusätzliche Dienstmaschinen erforderten Administration, unabhängig davon, ob ein Einbruch stattfand oder nicht. Die überlieferten Quellen belegen nicht, dass ein Übergangsrelay einen solchen Vorfall verursachte. Sie belegen, dass Relais-Zuverlässigkeit, -Last, -Kontenverwaltung und -Zwischenspeicherung anerkannte betriebliche Anliegen waren.

Die Aufzeichnungen gelangten in den operativen Pfad, ohne eine einheitliche Autorität zu werden

Die Protokollumstellung, die Host-Registrierung, die Port-Genehmigung, die Nummernzuweisung und die Informationsverteilung waren miteinander verbunden, aber sie stellten keine einheitliche Macht dar, die von einer einzelnen Institution ausgeübt wurde.

Die Host-Tabellenebene ging der Januar-Umstellung voraus.RFC 810, veröffentlicht im März 1982, ersetzte das alte ARPANET-orientierte Tabellenformat durch ein Format, das für die DoD-Internetverbindung ausgelegt war. Das neue Format beschrieb Netze, 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 unter dem NamenHOSTS.TXTvom SRI-NIC heruntergeladen oder über den Host-Namensserver bezogen werden. Lokale Kopien reduzierten die Abhängigkeit von einer Live-Anfrage für jede Verbindung, schufen aber ein bekanntes Konsistenzproblem: Eine alte Kopie konnte eine verschwundene Adresse oder eine veraltete Protokollbehauptung enthalten. Die Umstellung erhöhte die Häufigkeit, mit der diese Unterschiede wichtig wurden, weil Benutzer und Anwendungen nicht nur einen Namen und eine Adresse kennen mussten, sondern auch die Kommunikationsumgebung, die ein Ziel unterstützte.

Die RFC 810 setzte auch eine formelle Regel in ihren angegebenen Grenzen durch. Namen und Adressen von DoD-Netzen, Gateways und Hosts mussten vor der Nutzung und bevor ein DoD-Host ihren Verkehr leitete, mit dem NIC ausgehandelt und registriert werden. Während einer Übergangszeit würde das NIC versuchen, vergleichbare Informationen für Nicht-DoD-Netze zu führen, wenn die Betreiber sie bereitstellten.

Dieser Text etabliert eine Registrierungsanforderung. Er etabliert keinen dokumentierten Fall, in dem das NIC einen bestrittenen Namen abgelehnt, ein ansonsten funktionierendes externes Netz ausgeschlossen oder aufgrund der TCP/IP-Frist neue Ermessensbefugnisse erlangt hätte. Die Anforderung war bereits Teil der Host-Tabellenspezifikation von 1982. Die Umstellung machte die Genauigkeit und Reichweite der Registrierung wichtiger; die Beweise zeigen nicht, dass sie die Regel schuf.

RFC 811beschrieb den Host-Namensserver des NIC als einen in NCP und TCP zugänglichen Dienst, der im SRI im Auftrag der DCA betrieben wurde. Programme konnten einen Eintrag nach Namen oder Adresse anfordern oder die gesamte Tabelle abrufen. Das Protokoll definierte die möglichen Antworten für einen nicht gefundenen Namen oder eine nicht gefundene Adresse, einen illegalen Befehl oder einen vorübergehenden Systemausfall.

Diese Antwortcodes zeigen, worauf die konsumierende Software vorbereitet sein musste. Sie zeigen nicht, wie oft diese Ausfälle auftraten, noch identifizieren sie einen Benutzer, der tatsächlich den Dienst aufgrund eines solchen verloren hätte. Ein fehlender Eintrag konnte eine Namenssuche zum Scheitern bringen, während die direkte numerische Kommunikation möglich blieb. Ein vorübergehender Serverausfall konnte durch eine lokale Tabelle abgemildert werden, obwohl diese Kopie veraltet sein konnte. Die RFC präsentierte die einheitliche globale Datenbank als eine Interimslösung auf dem Weg zu einem verteilten Namens-Adress-Zuordnungsdienst.

Eine direktere administrative Tür erschien in den Betriebsmeldungen um die geplante ARPANET/MILNET-Trennung. News Nr. 18, datiert auf den 17. Dezember 1982, besagte, dass eine genaue Registrierung von Hosts und IMP-Ports erforderlich sei, um zu vermeiden, dass während der Trennung der falsche Benutzer abgelehnt werde. BBN wurde angewiesen, ungenutzte Ports zu deaktivieren und sie nur nach Genehmigung durch das DDN-PMO zu aktivieren. Neue Hosts und Portänderungen mussten im Voraus koordiniert werden.

News Nr. 21 überarbeitete dann das Verfahren. Anträge auf Genehmigung eines neuen Hosts, einer Portaktivierung oder einer Hoständerung an einem aktiven Port wurden an eine Mailbox beim SRI-NIC gesendet. Zu den erforderlichen Informationen gehörten Hostname und -adresse, Standort, Hardware, Betriebssystem, Sponsor, Protokolle und Kontaktdaten der technischen Verbindung.

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

Die zugewiesenen Nummern bildeten eine weitere separate Schicht.RFC 820, veröffentlicht im Januar 1983, registrierte die Werte, die für Netznummern, Protokollnummern, Ports, Sockets und andere Implementierungsfelder verwendet wurden. Sie verwies Antragsteller an Jon Postel bei der USC/ISI und gab an, dass die Zuweisungen im Rahmen einer Vereinbarung zwischen dem Information Processing Techniques Office der DARPA und dem DDN-PMO behandelt wurden.

Eindeutige Nummern waren notwendig, um widersprüchliche Implementierungen und mehrdeutige Paketinterpretationen zu vermeiden. Diese Notwendigkeit schuf eine Abhängigkeit von koordinierten Zuweisungen. Das hier untersuchte erhaltene Material zeigt keine migrationsbedingte Ablehnung, eine Berufung gegen eine Zuweisungsentscheidung oder eine Vorher-Nachher-Änderung der formellen Ermessensbefugnis von Postel. Die RFC 820 dokumentiert eine Koordinationsfunktion und ihren institutionellen Rahmen; sie kann allein nicht beweisen, dass das Januar-Ereignis die Autorität dieser Funktion erweiterte.

Die Unterscheidung zwischen diesen Mechanismen ist das kausale Zentrum der Geschichte:

• Die Ablehnung durch die IMPs machte NCP im verwalteten Netz unbrauchbar, außer wo es aktiviert war.
• Das DDN-PMO entschied über temporäre NCP-Ausnahmen und genehmigte Host- oder Portaktivierungen.
• Die Host-Organisationen implementierten und betrieben ihre eigene Protokollsoftware.
• Das SRI-NIC registrierte und verteilte Namen, Adressen, Fähigkeiten, Kontakte und Mitteilungen.
• Die USC/ISI koordinierte die zugewiesenen Protokoll- und Netznummern.
• Gateway- und Relais-Betreiber bestimmten, ob Verkehr bestimmte technische Grenzen überschreiten konnte.
• Externe Betreiber übernahmen TCP/IP im Rahmen von Finanzierungsvereinbarungen, Forschungskooperationen, Beschaffungsregeln oder Interoperabilitätsanreizen, die nicht alle Anordnungen der DCA waren.
• Die Migration erhöhte die Abhängigkeit entlang dieser Kette. Sie verschmolz die Kette nicht zu einem einzigen Büro.

1972–1985: Die institutionelle Grenze verschob sich unter dem Netz

Selbst der grundlegende Zeitplan mahnt zur Vorsicht bei der Beschreibung einer kontinuierlichen zentralen Autorität.

Dieoffizielle DARPA-Zeitleistedatiert die Namensänderung von ARPA in Defense Advanced Research Projects Agency auf 1972 und nicht 1973. Die DARPA blieb der Forschungsförderer hinter den Schlüsselarbeiten zu Protokollen und Implementierung, mit substanziellem Einfluss auf ihre Auftragnehmer und finanzierten Partner.

Das Datum, an dem die DCA die Betriebsverantwortung für das ARPANET übernahm, ist weniger klar. DerFindhilfsmittel für das SRI ARC/NIC-Archivvon 2011 gibt an, dass der Betrieb 1973 an die DCA übertragen wurde. Eine zeitgenössische DCA-Publikation gibt ein formelleres späteres Datum an: DieARPANET-Informationsbroschüreder Behörde von 1978 gibt an, dass die Managementverantwortung am 1. Juli 1975 übertragen wurde.

Ohne die zugrunde liegenden Aufzeichnungen der schrittweisen Übertragung sollten diese Aussagen nicht zu einer falschen Gewissheit gezwungen werden. Das spätere Findhilfsmittel beschreibt möglicherweise eine frühere Betriebsübertragung, während die eigene Broschüre der DCA die formelle Übertragung der Managementverantwortung identifiziert. Für das formelle Datum ist der zeitgenössische Bericht der DCA solider. 1982 lassen die Live-Mitteilungen selbst keine Unklarheit über die operative Hierarchie: Sie wurden vom NIC für das DDN Program Management Office der DCA verteilt, und die Netzmanagement-Anweisungen kamen von dieser Struktur.

Im Januar 1983 mussten mindestens fünf Populationen getrennt gehalten werden.

Die ARPANET-Netz-10-Bevölkerung war das direkte Subjekt des NCP/TCP-Plans der RFC 801 und der Nur-TCP-Tests auf IMP-Ebene. Die operative Kontrolle der DCA und die Ausnahmeentscheidungen des DDN-PMO hatten hier 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 Bericht des National Research Council von 1985, der unter dem NamenRFC 942wiedergegeben wurde, gab an, dass das MILNET-Backbone selbst kein TCP erforderte, obwohl die Teilnehmer allgemein verpflichtet waren, es zu verwenden.

Andere DoD-Netze folgten unterschiedlichen technischen und beschaffungstechnischen Wegen. Die RFC 942 beschrieb Netze, die bereits TCP verwendeten, Netze, die spätere Umstellungen planten, und Systeme, die andere Protokolle verwendeten. Das „DoD-Internet“ war daher keine einheitliche Population, die im Januar ein universelles Ereignis vollzog.

Externe, von der DARPA finanzierte Forschungspartner konnten an die Erwartungen des Sponsors gebunden und tief in die experimentellen Internet-Arbeiten eingebunden sein. Das UCL, Einrichtungen in Satellitennetzen, Paketfunkforscher und Auftragnehmer befanden sich in kooperativen Arrangements mit variabler operativer Kontrolle. Ihre Anwesenheit in Protokolldokumenten oder Host-Tabellen machte nicht jede Maschine zu einem DCN-Teilnehmer.

Spätere unabhängige externe Adoptierende waren noch weniger dem Kommando der DCA ausgesetzt. Sie konnten TCP/IP wählen, weil Implementierungen verfügbar waren, weil wertvolle Korrespondenten es nutzten, oder weil inkompatible Protokolle steigende Opportunitätskosten auferlegten. Dieser Netzwerkeffektdruck konnte mächtig sein, ohne eine Gerichtsbarkeit der DCA über ihre internen Systeme zu schaffen.

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

Der Bericht gab an, dass in den sechs Monaten vor der Migration etwa 30 Nur-TCP-Hosts zur bestehenden Doppelprotokoll-Population hinzugekommen waren. Er schrieb die gründlichen Tests zu, die betriebliche Kapazität bewahrt zu haben, und gab an, dass innerhalb weniger Monate normale Dienstniveaus erreicht wurden.

Er stellte auch fest, dass das NIC nicht bereit war, die neuen Protokolle zu unterstützen, was zu Problemen bei der Verteilung der Host-Tabelle führte, und dass die Diensthosts eine substanzielle Leistungsanalyse und Parametereinstellung erforderten, da sie zuvor noch nie über einen längeren Zeitraum eine volle Benutzerlast getragen hatten.

Dies sind dokumentierte Konsequenzen einer konzentrierten Abhängigkeit. Die Tabellenverteilung war eine operative Abhängigkeit, nicht nur ein administrativer Symbolismus. Dienstsoftware, die in begrenzten Tests funktionierte, konnte unter anhaltender Nachfrage dennoch schwächeln. Eine Frist, die Implementierungen ausrichten konnte, konzentrierte auch die Last auf gemeinsame Dienste.

Derselbe Bericht erschwert eine triumphale Erzählung. Er gab an, dass das ARPANET allgemein TCP verwendete, während einige Benutzer weiterhin NCP nutzten. Diese Aussage, zwei Jahre nach dem Ziel, identifiziert weder die beteiligten Hosts noch die Pfade. Sie widerlegt jede wörtliche Behauptung, dass jede residuelle Nutzung um Mitternacht universell verschwunden sei. Die politische Umstellung, der normale Netzbetrieb, die Host-Software, die lokale Nutzung und die vorübergehende oder ausnahmsweise Erreichbarkeit waren unterschiedliche Zustände.

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

Der breitere Erfolg von TCP/IP hing von seiner Ausdehnung über die Bevölkerung hinaus ab, die die DCA verwalten konnte.

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

Sie etablieren kein einheitliches rechtliches oder administratives Regime über diese Umgebung hinweg.

Für einen Netz-10-Host war die Ablehnung von NCP durch einen IMP eine unmittelbare betriebliche Tatsache. Für ein separat verwaltetes Netz 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 Netz 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 wichtiger werden konnten als die Jurisdiktion des ursprünglichen Sponsors. Ein unabhängig betriebenes Netz benötigte eindeutige Adressierung und Protokollwerte, wenn es mit dem weiteren Internet kommunizierte. Seine Benutzer profitierten von genauen Namensinformationen und erreichbaren Gateways. Die Abhängigkeit von einer gemeinsamen Koordination konnte sich über die vertragliche Autorität hinaus ausdehnen, die den Koordinationsdienst ursprünglich unterstützt hatte.

Die Abhängigkeit allein beweist jedoch kein Recht zu regieren. Ein Aufzeichnungsverwalter kann wichtig werden, weil Einrichtungen kompatible Informationen benötigen, während ihnen die Autorität über ihre Finanzierung, internen Systeme oder Entscheidungsverfahren fehlt. Ein Sponsor kann direkte Autorität über sein eigenes Netz besitzen, aber externe Adoptierende nur durch Interoperabilitätsanreize beeinflussen. Die Expansion von TCP/IP erweiterte daher den Bereich der Koordination, ohne diesen Bereich verfassungsrechtlich einheitlich zu machen.

Deshalb kann die Migration auch nicht für die Schaffung aller späteren Registrierungsmacht verantwortlich gemacht werden. Zentrale Host-Tabellen, die Koordination zugewiesener Nummern und die DoD-Registrierungsregeln existierten bereits. Was sich änderte, war die operative Exposition einer breiteren Kompatibilitätsumgebung gegenüber Fehlern, veralteten Kapazitätsdaten, Nummernkonflikten, Gateway-Ausfällen und Verteilungsschwächen. Eine erhöhte Konsequenz ist nicht identisch mit neu geschaffener Ermessensbefugnis.

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

Die tatsächlichen TAC- und UDEL-Vorkehrungen erlauben es, eine historisch plausible Alternative zu modellieren, ohne spätere Technologien im Jahr 1983.

Angenommen, die DCA hätte NCP über Januar hinaus als gewöhnlichen ARPANET-Dienst beibehalten und Host-Organisationen die freiwillige Migration ermöglicht. Doppelprotokoll-TACs hätten weiterhin verfügbar sein können. UDEL oder andere Hosts hätten den E-Mail-Transfer fortsetzen können. Die Telnet- und FTP-Relais-Konten hätten zwischen Benutzern und inkompatiblen Diensthosts vermitteln können. Standorte hätten datierte Kopien vonHOSTS.TXTherunterladen und die Protokollfähigkeitsfelder verwenden können, um direkte oder vermittelte Pfade auszuwählen.

Dies hätte den unmittelbaren Druck auf schwierige Systeme verringert. Ein Host, der von einem unvollendeten Lieferantenport abhängig war, hätte warten können. Administratoren hätten die Umstellung entsprechend lokalem Personal und Wartung planen können. Diensthosts hätten längere Auslastungstests durchlaufen können, bevor alle Benutzer ankamen. Das NIC hätte die TCP-basierte Verteilung verbessern können, während Standorte den alten Pfad beibehielten.

Der Preis wäre ein dauerhafter Übergangsdienst gewesen.

Doppelprotokoll-TACs erforderten fortlaufende Softwareunterstützung und Tests. Relais erforderten Konten, Speicher, Betreiber, Dokumentation und Kapazität. Ein zweistufiger Dateitransfer verbrauchte Plattenplatz und erforderte Wartung. E-Mail-Transfer erforderte Warteschlangen, protokollbewusste Adressverwaltung, aktualisierte Zielinformationen und Personal, das Fehler durch zwei Umgebungen verfolgen konnte. Terminalbenutzer mussten zusätzliche Befehle verstehen und zwischen direktem und vermitteltem Zugang unterscheiden.

Die Fehlerbehebung wäre weniger lokal geworden. Eine fehlgeschlagene Sitzung könnte einen der beiden Endpunkte, einen der beiden Protokollstapel, ein Relais-Konto, ein Gateway, eine veraltete Kopie der Host-Tabelle oder ein falsches Fähigkeitsfeld betreffen. Das Support-Personal müsste Fachwissen in beiden Protokollumgebungen behalten. Tests müssten fortgesetzt werden, da ein NCP-Pfad funktionsfähig bleiben könnte, während der entsprechende TCP-Dienst leise nachließ, oder umgekehrt.

Der Sponsor würde auch weiterhin für die Nicht-Konvergenz zahlen. Host-Organisationen, die ein Relais nutzen könnten, könnten schwierige Umbauarbeiten aufschieben, weil ein Teil der Kosten auf den Relaisbetreiber verlagert wurde. Je nützlicher der Kompatibilitätsdienst wurde, desto einfacher könnten Legacy-Inseln überleben. Netzeffekte könnten NCP schließlich unattraktiv machen, aber der Zeitplan wäre ungewiss, und die operative Naht könnte Jahre andauern.

Ein freiwilliger Übergang wäre nicht unbedingt dezentraler gewesen. Er hätte das Drama eines vom Betreiber auferlegten Datums reduziert, aber die Abhängigkeit von den Administratoren der Relais, TACs, Fähigkeitsaufzeichnungen und Doppelprotokoll-Diensthosts erhöht. Die Autorität wäre weniger sichtbar geworden, anstatt zu verschwinden.

Man kann die Alternative auch nicht mit der Behauptung verwerfen, dass sie einen Sicherheitsverstoß verursacht hätte. Die Quellen dokumentieren keinen solchen Vorfall. Sie stützen eine bescheidenere Beobachtung: Jedes zusätzliche Konto, jeder Zwischenhost, jede gespeicherte Nachricht, jede Dateikopie und jede Legacy-Implementierung erforderte Zugriffskontrolle und betriebliche Sorgfalt. Das Ausmaß des resultierenden Risikos ist nicht gemessen.

Die tatsächliche Umstellung wählte eine andere Kostenverteilung. Die temporäre Vermittlung blieb verfügbar, aber ihre Ablaufdaten zwangen die Host-Organisationen, die Implementierungsarbeit zu übernehmen. Die DCA und das DDN-PMO nutzten die Kontrolle über den Netzbetrieb, um diese Allokation glaubwürdig zu machen. Externe Netze außerhalb dieser Kontrolle übernahmen TCP/IP weiterhin nach ihrem eigenen Zeitplan.

Wie eine verantwortungsvollere Koordination im Jahr 1983 hätte aussehen können

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

Die Periode hatte bereits die grundlegenden Bausteine für eine bescheidene Verbesserung: postalische Mitteilungen, namentlich genannte betriebliche Ansprechpartner, Host-Status-Umfragen, lokale Kopien vonHOSTS.TXT, ein Antragsverfahren, eine veröffentlichte Ausnahmetabelle, geplante Testtage, telefonische Unterstützung, Relais und manueller Abgleich von Aufzeichnungen.

News Nr. 19 hätte zu einem vollständigen öffentlichen Entscheidungsformat für nicht sensible Fälle erweitert werden können. Jede Ausnahmezeile hätte eine kurze Grundkategorie, das Antragsdatum, das Entscheidungsdatum, das genehmigende Büro, die an die NCP-Aktivierung geknüpften Bedingungen und ob das angegebene Umstellungsdatum eingehalten wurde, enthalten können. Sensible Details könnten verborgen bleiben, ohne die Existenz und den Status der Entscheidung zu unterdrücken.

Ein Überprüfungsantrag könnte an einen Sponsor oder Betriebsverantwortlichen gerichtet werden, der die ursprüngliche Entscheidung nicht getroffen hatte. Ein solches Verfahren hätte die Kontrolle des DDN-PMO über das Netz nicht beseitigt. Es hätte die Erstverwaltung von der Überprüfung getrennt und einen Datensatz geschaffen, der anzeigt, ob ähnliche betriebliche Probleme ähnlich behandelt wurden.

Statusveröffentlichungen hätten auch die Populationen trennen können. Eine Netz-10-Konformitätstabelle, eine DDN-Teilnehmertabelle und eine informative Liste externer Internet-Einträge hätten vermieden, dass eine gemischte Host-Tabelle mit einer einzigen regierten Gemeinschaft verwechselt wird. Ergebnisse könnten zwischen aufgezeichneter Fähigkeit, akzeptierter Anwendungsverbindung, erfolgreichem Routentest von einer anderen Adressklasse, genehmigter NCP-Ausnahme, vorübergehender Nichtverfügbarkeit und ungeklärtem Ergebnis unterscheiden.

Eine Verteilungsresilienz war in begrenzter Form möglich. Mehr als ein Nur-Lese-Host hätte datierte Kopien der Host-Tabelle bereitstellen können. Betreiber konnten Versionsdaten vergleichen und manuelle Konsistenzchecks mit der NIC-Kopie durchführen. Dies würde die Abhängigkeit von einer einzigen Verteilungsmaschine während eines Ausfalls verringern. Es würde die Aktualisierungsautorität nicht dezentralisieren: Wenn jeder Spiegel denselben fehlerhaften Master-Eintrag replizierte, blieb der Fehler autoritativ.

Solche Maßnahmen hätten Personalzeit, Speicher, telefonische Koordination und zusätzliche Abgleicharbeit gekostet. Die Aufzeichnungen könnten auseinanderdriften. Die Veröffentlichung könnte hinter dringenden betrieblichen Änderungen zurückbleiben. Bestimmte Verteidigungsinformationen konnten nicht preisgegeben werden. Eine zweite Überprüfung könnte eine Entscheidung verzögern, die schnell getroffen werden musste, um den Dienst wiederherzustellen oder zu schützen.

Diese Kosten sind genau der Grund, warum Verantwortlichkeit nicht als kostenloser Zusatz zu technischer Koordination behandelt werden kann. Der relevante Vergleich liegt zwischen den Kosten der Führung klarerer Aufzeichnungen und den Kosten, die entstehen, wenn Betreiber nicht feststellen können, ob ein Fehler technisch, administrativ, vorübergehend oder absichtlich ist.

Das Dossier der Umstellung legt nahe, dass diese Unterscheidung nützlich gewesen wäre. Die 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 den beobachteten Betrieb nicht 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 zusammenfallen lassen; sie würde sie getrennt halten.

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

Die Januar-Umstellung war in ihrem primären operativen Ziel erfolgreich. TCP/IP wurde zur normalen Kommunikationsumgebung des ARPANET, die wichtigsten Dienste migrierten dorthin, und heterogene Netze konnten über eine gemeinsame Internet-Schicht teilnehmen. Die Februar-Umfragen zeigen Hunderte von Dienstendpunkten, die akzeptieren, obwohl sie auch unvollständigen und pfadabhängigen Betrieb zeigen.

Die Stärke der Umstellung beruhte auf einer spezifischen institutionellen Struktur. Die DARPA finanzierte die Forschung und beeinflusste die Auftragnehmer. Die DCA verwaltete das ARPANET seit Mitte der 1970er Jahre offiziell. Das DDN-PMO legte die Betriebspolitik fest, entschied über NCP-Ausnahmen und genehmigte Hosts oder Ports. Die IMPs und Netzbetreiber setzten die Protokollabschaltung durch. Die Host-Organisationen kontrollierten die Implementierung auf ihren Computern. Das SRI-NIC registrierte und verteilte Betriebsinformationen. Die USC/ISI koordinierte die Nummernzuweisungen.

Die TAC- und Relaisbetreiber bewahrten eine vorübergehende Erreichbarkeit.

Diese Teilung verhindert die stärkste Version der Zentralisierungsbehauptung. Die Beweise zeigen nicht, dass die Migration selbst dem SRI-NIC neue Befugnisse gab, zu entscheiden, wer einen Namen verdiente, oder der USC/ISI neue Befugnisse, externe Netze durch Nummernzuweisungen auszuschließen. Sie zeigen, dass genaue Namen, Adressen, Protokollfähigkeiten, numerische Werte und Verteilungsdienste betrieblich wichtiger wurden, je mehr Kommunikation auf TCP/IP konvergierte.

Der ausgeübte Hebel lag woanders. Die Ablehnung von NCP auf IMP-Ebene machte die Autorität des Sponsors und Betreibers konkret. Die individuellen Aktivierungen und Ablaufdaten machten das Ermessen des DDN-PMO für die betreffenden Netz-10-Adressen folgenreich. Die Host- und Port-Genehmigung verknüpfte administrative Daten mit der Netzaktivierung bei der ARPANET/MILNET-Trennung. Die späteren Verteilungsprobleme der NIC-Host-Tabelle zeigten eine Abhängigkeit von einem gemeinsamen Informationsdienst, keine politische Verweigerung.

Die Koordination der Nummernzuweisung bewahrte die Eindeutigkeit, aber das untersuchte Dossier liefert keine migrationsbezogene Ablehnung oder Berufung.

Außerhalb der verwalteten Population ersetzten Kompatibilitätsanreize den direkten Befehl. Externe Betreiber übernahmen TCP/IP, weil die Interoperabilität mit einer wachsenden Gemeinschaft nützlich war, weil Sponsoren oder Beschaffungsprogramme sie unterstützten, oder weil Implementierungen verfügbar wurden. Ihre technische Abhängigkeit von gemeinsamen Identifikatoren machte ihre Netze nicht zu Eigentum der DCA, der DARPA, des SRI oder der ISI.

Die institutionelle Errungenschaft und das Legitimitätsproblem sind daher unterschiedlich. Die Errungenschaft war eine koordinierte Interoperabilität über heterogene Systeme hinweg. Das Legitimitätsproblem war, dass die wachsende operative Abhängigkeit die Entscheidungsunterlagen, Überprüfungsverfahren und Kontinuitätsvereinbarungen von Institutionen übersteigen konnte, die für eine engere, vom Sponsor kontrollierte Umgebung geschaffen wurden.

Der 1. Januar war bedeutsam, weil er die unbestimmte Koexistenz als Standardpolitik des ARPANET beendete. Die Experimente im Oktober, November und Dezember zeigten, wie diese Politik durchgesetzt werden würde. Das Ausnahmeregister vom Januar zeigte, dass die Durchsetzung selektiv und temporär und nicht absolut war. Die TACs und UDEL bewahrten wesentliche Nähte. Die Februar-Umfragen zeigten, dass die formelle Umstellung, die aufgezeichnete Fähigkeit, die Anwendungsantwort und die geroutete Erreichbarkeit noch unterschiedliche Tatsachen waren.

Die Migration veränderte die Autorität, indem sie bestimmte bestehende Befugnisse operativ entscheidend machte: die Befugnis, ein Protokoll zu deaktivieren, eine vorübergehende Fortsetzung zu genehmigen, einen Port zu aktivieren, eine gemeinsame Aufzeichnung zu verteilen oder ein Relais zu betreiben. Sie erhöhte auch die Abhängigkeit von einer Koordination jenseits der Reichweite dieser Befugnisse. Das ist präziser, als zu sagen, dass eine einzelne Autorität das Internet umgeschaltet hat – und folgenreicher als die Legende einer perfekten Mitternacht.