権限を変えたフラッグデイ：TCP/IP カットオーバー後のガバナンス

概要

• 1983 年 1 月の移行は実質的だが不均一だった：2 月の測定では数百の TCP サービスエンドポイントが確認されたが、結果はサービス、アドレス集団、テスト日、ネットワーク経路によって異なり、深夜に一斉に切り替わる普遍的な集団を示すものではなかった。
• スポンサーと運用者の影響力は、IMP レベルでの NCP トラフィック拒否、DDN-PMO の例外決定、ホストやポートのアクティベーションを通じて行使された。SRI-NIC の記録と USC/ISI の番号調整への依存は運用上高まったが、このカットオーバーによっていずれかの機関に新たな裁量権が与えられたという証拠はない。
• 例外プロセスは実際に存在したが、独立的というより部分的だった：管理者はレクラマ（reclama）を提出でき、公開リストには一時的な NCP 有効化と期限が記録され、TAC と UDEL のリレーが限定的な到達性を維持したが、公開された理由、完全な決定ファイル、DDN-PMO 外部のレビューは存在しなかった。

1983 年 2 月 1 日、ARPANET が NCP から TCP/IP への変換目標期限から 1 か月後、ISI-VAXA によるテストが、最近の Network Information Center のホストテーブルに含まれるすべてのアドレスへの接続を試みた。結果は、過去と未来にきれいに分割されたネットワークではなかった。それは、受け入れられた接続、拒否、到達不能アドレス、停止システム、空の結果フィールドで満たされた固定幅のレポートだった。

ホストリストは、1 月 28 日付の NIC テーブルから取得された。テストは 2 月 1 日と 2 日に ISI-VAXA から実行され、停止、到達不能、拒否を示したエントリは 2 月 3 日に再試行された。この調査では、Telnet、FTP、SMTP の 3 つの TCP サービスが試行された。ソフトウェアの検査、すべての TCP や IP 機能のテスト、ホストの継続的な可用性の証明、参加ネットワークに接続されているすべてのコンピューターの列挙は行われなかった。特定の送信元が特定の期間に特定のサービスポートを試行したときに何が起こったかを記録しただけである。

RFC 842「Who Talks TCP?」の分母は 328 のアドレス行だった。そのうち 200 はネットワーク番号 10（ARPANET アドレス空間）で始まり、128 は他のネットワークに属していた。各行が必ずしも一意の物理コンピューター、機関、DDN 加入者、組織を表すわけではなかった。一つの名前付きシステムが複数のアドレスに現れる可能性があり、ゲートウェイやその他の運用エントリもテーブルに現れる可能性があった。逆に、未登録、切断、機密扱い、または省略されたシステムは測定対象外だった。

RFC 842 の結果行を直接再集計すると、以下の監査結果になる。FTP のaccepted+結果は、accepted に含まれる。サービス列にわたって停止または到達不能と表示されているものは、各サービスについてその状態としてカウントされる。

これらのカテゴリは観測結果を記述するものであり、説明ではない。停止エントリは、電源が切られたマシン上で完全に機能する TCP ソフトウェアが存在した可能性がある。到達不能アドレスは、ゲートウェイ、ルーティング、アドレッシング、または測定の問題を示す可能性がある。拒否は、パケットが TCP エンドポイントに到達したが、アプリケーションが要求されたセッションを受け付けなかったことを意味する可能性がある。空白の結果は、失敗がホスト、経路、サービス、テーブルのいずれに起因するかを明らかにしない。一つのポートでの受付は、TCP、IP、ICMP、ルーティング、名前処理、主要アプリケーションとの完全な適合性を証明するものではない。

また、ホストテーブルはスポンサーの 1 月目標への準拠状況の調査ではなかった。ネットワーク 10 以外の 128 行には、独立して運用されるネットワーク、研究ネットワーク、ローカルネットワーク、外国ネットワーク、パケット無線ネットワーク、衛星接続ネットワークなど、さまざまなシステムが含まれていた。これらの存在は、拡大するインターネット環境への参加を示していたが、Defense Communications Agency がそれらすべての運用者に変換を命じることができたことを示すものではなかった。

したがって、見出しの「フラッグデイ」は後付けのレッテルであり、運用記録の通常の言葉ではない。当時の通知では、カットオーバー、変換、または TCP のみの実験と表現されていた。1997 年、主要な参加者数名によって書かれた Internet Society の歴史では、この出来事を「フラッグデイ」方式の移行と表現している。その後の説明は、期限の調整力を捉えてはいるが、2 月のテーブルが保存している不均一な実装を圧縮している。

この変換は依然として重要だった。これは、NCP と TCP の共存を ARPANET の通常の将来として扱うことをやめるという、スポンサーが後押しする決定だった。その重要性は、神話的な深夜の一斉変換ではなく、目標を信頼できるものにしたメカニズムにある。つまり、交換ネットワークで NCP を無効にするテスト、運用者が管理する例外プロセス、一時的なリレーと端末のサポート、ホストとポートの承認、正確な共有記録への依存の高まりである。

1983 年 2 月 1 日～18 日：変化する観測結果は採用曲線ではなかった

2 番目の調査は、集計結果を安易に着実な採用の物語に変換できない理由を示している。

RFC 843は、2 月 3 日付の NIC ホストテーブルを使用し、2 月 8 日と 9 日に ISI-VAXA からテストされた。その集団は 328 行から 329 行に増加していた。合計受付数は、Telnet が 187、FTP が 174、SMTP が 170 で、以前のレポートの 183、170、169 と比較された。しかし、ネットワーク 10 とそれ以外のグループは逆方向に動いた。

ネットワーク 10 の受付数は 3 つのサービスすべてで増加した。その他のネットワークの受付数は 3 つすべてで減少した。基礎となるテーブルも 1 行変更され、個々のマシンはあるテストでは起動していて、別のテストでは利用できないこともあった。追加、削除、一時的な障害、経路変更を制御したマッチドエントリ分析がなければ、2 つの調査は採用率の測定ではなく、変化した観測結果を示しているにすぎない。

10 日後、RFC 844は異なる質問をした。RFC 843 で Telnet を受け入れた 187 エントリを選択し、BBN のクラス C ネットワーク 192.1.2 上の端末コンセントレータからそれらへの到達を試みた。成功には、以前の経路に沿った受付 Telnet サービス以上のものが必要だった。パケットと応答は、ゲートウェイルーティング、クラス C アドレッシング、関連する ICMP の動作を通じて機能しなければならなかった。

接続はドット付きアドレスで手動入力され、3 回のパスしか行われなかった。そのパス中に利用できなかったホストは見逃される可能性があった。それでも結果は、見かけ上の TCP 成功がテストの起点とネットワーク経路にいかに強く依存するかを露呈した。

187 台中 127 台という集計結果は、外部ネットワークが ARPANET に遅れを取っていたという単純な主張を支持できない。非クラス A グループの観測成功率は 32 台中 30 台と最も高かった。また、このテストは、成功しなかったすべてのエントリがクラス C または ICMP サポートを欠いていたことを立証するものでもない。一時的な可用性と経路条件は未解決のままだった。

これら 3 つのレポートを合わせると、より限定的だが価値のある事実が確立される。目標から 1 か月後、数百のテーブル行が主要な TCP サービスを受け入れていたが、記録された能力、アプリケーションの可用性、異なる起点からの到達性は依然として不均一だった。この変換は、即時の均一性ではなく、実質的な運用を生み出していた。

これが最初のガバナンスの境界である。測定は実装を見えるようにしたが、測定はホストが失敗した理由やどのような対策を取るべきかを決定しなかった。それらの決定は、ホスト管理者、実装者、ゲートウェイおよび交換オペレーター、NIC、DDN プログラム管理オフィス、研究スポンサー、そしてスポンサーの管理下にない自律的なネットワーク運用者に委ねられていた。

1981 年 11 月：計画は仲介を終わらせるために設計された

運用目標は、何百台ものマシンが一度に変更できるという主張ではなく、段階的な計画として始まった。

1981 年 11 月に発行されたRFC 801は、1983 年 1 月 1 日を ARPANET の NCP から IP および TCP への完全な切り替え目標として設定した。各ホスト組織に対し、1982 年 1 月 1 日までに IP/TCP の実装を開始するよう指示し、Telnet、ファイル転送、メールについても同じくローカルな責任を割り当てた。新しい ARPANET ホストは、NCP 経由で参加するのではなく、TCP/IP で開始することが期待された。

計画のマイルストーンは、実際の設計を明らかにする。TCP 対応および TCP 専用のホストは既に存在していた。リレーサービスは、互換性のないホストを橋渡しすることが期待されていた。最後の NCP 専用変換は 1982 年 1 月に開始される予定であり、7 月までにほとんどのホストが TCP 対応になると見込まれ、最終的な変換は 11 月に完了するようスケジュールされていた。その上で、1983 年 1 月に完全な TCP ベースのサービスが開始され、NCP が削除され、通常のリレーサポートが終了することになっていた。

実装は分散されたままだった。ARPANET のホスト組織は、異なるプロセッサ、オペレーティングシステム、スタッフ、ソフトウェアソース、ローカルなサービス要件を持つマシンを管理していた。スポンサーは期限を発表し、実装に資金を提供することはできたが、欠陥のあるチェックサムルーチンを命令で修正することはできなかった。ホストは IP と TCP を備えながら SMTP を欠くこともあり得た。あるゲートウェイを経由して機能したシステムが、別のルート、オプション、フラグメンテーション、ICMP の処理を誤る可能性もあった。RFC 801 自体が、チェックサムを省略したり、フラグメントを再構成できなかったり、限られたルーティングデータに依存したり、オプションを無視したり、TCP データの順序を誤って並べ替えたり、静的な名前テーブルを維持したりする実装について警告していた。

目標ができたことは、遅延のコストを変えることだった。ホスト組織は自らのコンピューターに NCP ソフトウェアを保持することはできたが、ARPANET の運用者に NCP トラフィックを無期限に搬送させるよう強制することはできなかった。交換ネットワークが古いトラフィックを拒否し、通常のリレーが終了すれば、未完了のローカル実装はホストとそのユーザーにとってアクセスの問題となった。

RFC 801 は、長期にわたる共存がなぜ魅力的でないかをモデル化していた。NCP 専用エンドポイントと TCP 専用エンドポイントは直接通信できず、したがってデュアルプロトコルのリレーホストが Telnet、FTP、メールを仲介しなければならなかった。Telnet は中間アカウントと二度目のログインを作った。FTP はファイルをリレーストレージに移動してから再び転送することを必要とする可能性があった。メールは転送ロジックとプロトコルを意識したアドレス指定を必要とした。すべてのリレーは、可用性がなければならない別のマシンと、キャパシティ、アクセス制御、文書化、サポートを必要とする別のサービスを追加することになった。

文書のリレー負荷の数値モデルは明らかに推測に基づくものだったが、制度的なポイントは健全だった。無期限の共存は、選択肢の中立的な維持ではなかった。誰かが二つの環境の間の継ぎ目に資金を提供し、運用しなければならなかった。期限はその負担をリレー運用者から変換を完了していないホスト組織へと移転した。

この計画だけでは、この移転が実際に起こったことを証明できない。実行の記録は別の情報源、すなわち NIC が DCA とその DDN プログラム管理オフィスのために配布した運用ニュースレターに現れる。

1982 年 10 月～12 月：強制は IMP に移された

1982 年 10 月 1 日、正午から午後 4 時（東部標準時）まで、ARPANET は TCP のみの実験を実施した。この 4 時間の間、インタフェースメッセージプロセッサ (IMP) は、NCP のホスト間トラフィックに関連付けられたリンク 0 を使用するホストメッセージを拒否するよう指示された。IMP は、宛先との通信が「管理上禁止されている」ことを示すタイプ 7、サブタイプ 3 のステータスを返した。

ARPANET News No. 14に記述されたこのメカニズムは、変換における運用上の強制の最も明確な証拠である。NCP は単に文書上で非推奨とされたわけではない。パケット交換インフラが該当するトラフィックを拒否したのだ。NCP 専用ホストはテスト中に ARPANET を使用できなかった。共有されたリモートホスト状態を持つデュアルプロトコルシステムも、管理者がその期間に NCP 実装を無効にしない限り、問題に遭遇する可能性があった。

強制ポイントが重要である。それは NIC が名前を削除したからでも、USC/ISI が番号を拒否したからでもない。IMP はネットワーク管理の指示の下で拒否を実行し、ネットワークオペレーションセンター (NOC) と DCA にリンクされた管理者が運用環境を担当した。返されるステータスは、拒否の管理的な性質を送信ホストに見えるように設計されていた。

News No. 16 は管理者に 10 月 1 日のテストを再認識させ、参加者に観察結果を Jon Postel、NOC、NIC に報告するよう求めた。また、1 月までに SMTP と 4 オクテットのインターネットアドレス指定を実装するようサイトに強く要請した。ここで調整は複数の機能を組み合わせた。交換ネットワークがテスト条件を作り出し、実装者とホスト管理者が障害を観察し、ISI が技術報告を受け取り、NOC が運用を監視し、NIC が指示を配布して実装情報を収集した。

この 4 時間の実験に続いて、より長いリハーサルが行われた。News No. 17は、11 月 15 日と 12 月 13～14 日に 24 時間の TCP 専用期間を発表した。同じ IMP レベルの拒否方法が使用されることになっていた。この通知は、これが 1 月 1 日の目標後も意図されたメカニズムであることを明示的に警告した。

これらのテストは、ホストテーブルの主張では提供できない情報を提供した。あるサイトが TCP を持っていると報告しても、NCP が無効化された日になっても、本番サービス、メーラー、端末経路、ゲートウェイ、またはローカルの運用手順が依然として NCP に依存していることが発覚するかもしれない。ホストはラボテストには合格しても、完全な運用期間のトラフィックとユーザーの振る舞いの下で不合格になるかもしれない。実験を繰り返すことで、継続的なネットワークポリシーが変更される前に依存関係が発見される可能性が高まった。

テストはまた、影響力も生み出した。変換を完了していないスポンサー管理下のホストは、テスト中に単に古いプロトコルを使い続けることはできなかった。そのユーザーは未変換の結果を経験し、管理者はネットワークから特定のステータスを受け取った。これは RFC を通じた説得とは実質的に異なっていた。

しかし、その影響力には限界があった。それは ARPANET の IMP を通じて提出された NCP トラフィックに直接適用された。NCP を内部で運用している独立したローカルネットワーク、ARPA インターネットに参加していない外部ネットワーク、または RFC 842 に後でリストされたすべての非ネットワーク 10 アドレスにまでは及ばなかった。DARPA の資金提供を受けた研究パートナーは、契約上の期待や強い相互運用性のインセンティブに直面するかもしれないが、それらの関係は ARPANET 運用に対する DCA の支配と同一ではなかった。

この同じ区別は、登録に関する主張を制限する。テストは、運用者が交換層でプロトコルを無効にできることを証明している。しかし、カットオーバーによって NIC に名前に関する新たな裁量が与えられたり、USC/ISI に番号割り当てに関する新たな裁量が与えられたりしたことは証明しない。これらの管理機能は相互運用性にとって重要だったが、観察された強制の行為は別の場所で発生した。

1983 年 1 月：例外は公開されていたが、部分的にしかなかった

運用ポリシーは、遅延のための手段のない単なる期限ではなかった。

1982 年 12 月 22 日付けのARPANET News No. 19は、1983 年 1 月 1 日東部標準時 0 時 01 分以降、DDN プログラム管理オフィスからの具体的な例外なく NCP の使用は許可されないと述べた。例外申請にはreclamaという名前を付け、提出方法を指定した。

1 月より前には、申請はネットワークメールで DDN-PMO のアドレスに送信し、NIC にコピーを提出できた。期限後は、ネットワークアクセスを使用できない管理者は米国郵便で DCA 本部に申請を送付することができた。そのオフライン経路は運用上重要だった。このポリシーは、NCP アクセスの復旧を求める者が依然として機能するネットワークアクセスを持っているとは想定しなかった。

申請者は詳細な正当化、変換スケジュール、可能であれば意図する TCP/IP 実装の出所、相互運用性が必要なホストのリストを提供しなければならなかった。さらなる情報のために、DDN-PMO の指名連絡先が提供された。これは、特定された決定権限と記載された情報要件を持つ文書化された申請プロセスだった。

その後、1 月 13 日に配布された News No. 20 は、NCP が有効化されたアドレスと予定変換日の表を公開した。直接カウントすると、44 のアドレスまたはポート行が得られる。それらは 44 の独立した組織ではなかった。いくつかの機関は複数の物理的または論理的なホストアドレスを持っていた。2 行はテストポートとラベル付けされ、別の行は S1 ゲートウェイを特定していた。1 行はカットオーバー日が不明だった。日付付きの行は 1 月 16 日から 5 月 1 日までに及んだが、25 行は 2 月 1 日が割り当てられていた。

古い省略形式のネットワーク 10 表記は、この表が何を表していたかを強調している。それは ARPANET 環境内の運用アドレスまたはポートエントリだった。唯一の法的実体、契約、サイト、または人間の意思決定者のリストではなかった。また、より広範な DDN や DoD のどこかで残余の NCP を使用しているすべてのコンピューターの完全な目録でもなかった。

News No. 20 は、深刻なサービスの中断に直面しているサイトには例外が認められており、各ホスト管理者は個別に NCP の有効化を要求しなければならないと述べた。また、期限は厳格であるとも述べた。したがって、表は管理上の決定を具体的なネットワーク状態、すなわち指定された日付まで指定されたアドレスに対して NCP 有効化が継続されることに結び付けた。

これは、ガバナンスの欠如を推測するよりも強い証拠である。部分的な公開例外登録簿があった。コミュニティは、リストされたどのアドレスが NCP を保持し、ほとんどがいつ変換される予定かを知ることができた。申請通知は、意思決定者と申請者が提出しなければならない資料を開示した。行を公開することは、メールユーザーがいつリレーが必要になるかを判断するのにも役立った。

登録簿は他の点では不完全だった。各アドレスの横に理由は記載されていなかった。申請書、裏付け証拠、条件、却下、個別の期限の背後にある分析は再現されなかった。調査した通知は、独立した審査機関や DDN-PMO の決定に対する不服申し立てを特定していない。類似の事例が一貫して扱われたのか、またはすべての一時的な有効化が表に現れているのかは明らかにされていない。

したがって、正確な制度的結論は限定的である。移行には例外手続きやすべての公開状況報告が欠けていたわけではない。中央の運用意思決定者、個別の申請、一時的な有効化、公開されたアドレス行、有効期限は存在した。公開記録に欠けていたのは、完全な決定ファイル、ケースごとの理由、ネットワークポリシーを管理する権限から独立したレビューだった。

この組み合わせは、公開された憲法上のシステムよりも、管理された防衛ネットワークに適合しやすかった。DDN-PMO は、運用責任を負う環境で、時代遅れのプロトコルがどれだけの期間アクティブでいられるかを決定していた。申請者はサービスの継続を求めるホスト管理者であり、任意のプロトコルを使用する一般的な権利を主張する市民ではなかった。その後のガバナンス上の重要性は、技術環境とその共有記録が、元来の関係によって管理されていた集団を超えて拡大したために生じる。

1983 年 1 月～2 月：TAC と UDEL が継ぎ目を生かし続けた

カットオーバーは 1 月 1 日にすべての仲介を排除したわけではない。それは、それを特定の一時的な設備に集中させた。

News No. 20 は、ARPANET 端末アクセスコントローラ (TAC) が 1 月中は NCP をサポートし続けると発表した。端末ユーザーは TAC を通じて接続し、NCP ホストに到達するために追加のコマンドを入力することができた。2 月 1 日には、TAC は TCP/IP 専用になる予定だった。

その継続が重要だったのは、端末アクセスがサービスホストへの一般的な経路だったからである。ユーザー自身の端末は、接続されたコンピューターと同じ方法で完全なホストプロトコルスタックを実装していなかった。TAC が端末のホストへのアクセスを仲介した。そこでデュアルサポートを維持することは、宛先またはサポートシステムが変換を完了していない人々のための運用経路を保存した。

University of Delaware (UDEL) は別の現実の橋渡しを提供した。UDEL は TCP ユーザーと NCP ユーザーの間のメール転送リレーを運用することに同意した。NCP 宛先にアドレスする TCP 送信者は、受信者アカウントと NCP ホスト名を含む UDEL-RELAY 形式を使用した。TCP 受信者にアドレスする NCP 送信者は UDEL-TCP を使用した。リレーは、宛先の現在のステータスが不確かな場合に、同じプロトコルのトランザクションを完了することもできた。

これは透過的な翻訳ではなかった。ユーザーは送信者のプロトコルを知り、それに応じてアドレスを構成しなければならなかった。誤ったアドレス指定はメッセージの返送を引き起こす可能性があった。リレーは、機能するメールソフトウェア、到達可能なホスト、スタッフの連絡先、キューとディスクキャパシティ、宛先プロトコルステータスの最新知識を必要とした。公開された免除リストは、その最後の依存関係を管理しやすくするはずだった。

これらの便宜は、変換の実際の質感を明らかにする。強制と支援は対立するものではなかった。運用者は通常の NCP トラフィックを拒否しながら、選択された NCP アドレスを保持し、TAC サポートを延長し、メールリレーを手配することができた。一時的な互換性は、期限を放棄することなく混乱を軽減した。

この取り決めはまた、正確な記録が運用上より重要になった理由も示している。古い能力エントリはメールを誤った手順に向ける可能性がある。誤って変換済みと表示されたホストは、もはや通常の NCP 経路では到達可能でないかもしれず、一方で NCP 専用として扱われた変換ホストは不必要なリレー使用を引き起こすかもしれない。UDEL の指示は送信元プロトコルを決定的にした。例外表は残余の宛先を特定するのに役立ち、TAC のスケジュールは端末経路がいつ消滅するかをユーザーに伝えた。

その依存関係は NIC をすべての決定の源泉にしたわけではない。DDN-PMO が NCP 例外を認めた。ネットワーク運用者が交換環境での有効化を実施した。UDEL がメールリレーを運用した。TAC 運用者が端末互換性を提供した。NIC はニュースレターと表を配布した。各機関が異なるリンクを制御していた。

リレーはまた、反実仮想的な主張に規律を課す。デュアルプロトコルの TAC サービスと UDEL 転送が実際に運用されていたため、より遅い変換は技術的に可能だった。しかし、それらを維持するには、スタッフ、ホストキャパシティ、ユーザー指示、アクセス制御、ストレージ、アドレス知識、トラブルシューティング、継続的なテストが必要だった。共存を延長すれば、それらのコストを延長しただろう。

負担を確立するためにセキュリティインシデントを捏造する必要はない。中間アカウント、保存されたファイルやメッセージ、追加のサービスマシンは、侵害が発生したかどうかに関係なく管理を必要とした。現存する情報源は、移行リレーがそのようなインシデントを引き起こしたことを立証していない。しかし、リレーの信頼性、負荷、アカウント制御、一時ストレージが認識された運用上の懸念事項であったことは立証している。

記録は一つの権限になることなく運用経路に入った

プロトコル変換、ホスト登録、ポート承認、番号割り当て、情報配布はつながっていたが、それらは一つの機関によって行使される単一の権力ではなかった。

ホストテーブルの層は 1 月の変換より前から存在していた。1982 年 3 月に発行されたRFC 810は、古い ARPANET 指向のテーブル形式を、DoD インターネットワーキング向けに設計されたものに置き換えた。新しい形式は、ネットワーク、ゲートウェイ、ホスト、インターネットアドレス、オペレーティングシステム、プロトコル能力を記述した。行は、TCP/Telnet を NCP/Telnet と区別したり、SMTP が利用可能かどうかを記録したりすることができた。

テーブルはHOSTS.TXTとして SRI-NIC からダウンロードするか、Hostnames Server を通じて取得することができた。ローカルコピーは、すべての接続に対してライブクエリへの依存を減らしたが、よく知られた一貫性の問題を生み出した。古いコピーは、去ったアドレスや時代遅れのプロトコル主張を保持する可能性がある。変換は、ユーザーとアプリケーションが名前とアドレスだけでなく、宛先がどの通信環境をサポートしているかを知る必要があったため、そのような相違が重要になる頻度を高めた。

RFC 810 はまた、その規定された境界内で正式な規則を課した。DoD ネットワーク、ゲートウェイ、ホストの名前とアドレスは、使用前および DoD ホストがそれらのトラフィックを通過させる前に、NIC と交渉して登録されることになっていた。暫定期間中、NIC は運用者が情報を提供した場合、非 DoD ネットワークについて同様の情報を保持しようと試みることになっていた。

このテキストは登録要件を確立する。しかし、NIC が係争中の名前を拒否したり、それ以外に機能する外部ネットワークを除外したり、TCP/IP の期限のために新たなポリシー上の裁量を獲得したりした文書化された事例を確立するものではない。要件は既に 1982 年のホストテーブル仕様の一部だった。変換は記録の正確性と範囲をより重要なものにした。証拠はそれが規則を創設したことを示していない。

RFC 811は、NIC Hostnames Server を、DCA のために SRI で運用されている NCP および TCP でアクセス可能なサービスとして説明した。プログラムは名前によるレコードの要求、アドレスによるレコードの要求、またはテーブル全体の取得が可能だった。プロトコルは、名前またはアドレスが見つからない場合、不正なコマンド、または一時的なシステム障害に対する可能な応答を定義した。

これらの応答コードは、消費するソフトウェアが何を処理する準備をしなければならなかったかを示している。それらは、そのような障害がどのくらいの頻度で発生したかを示しておらず、そのために実際にサービスを失ったユーザーを特定していない。不足しているレコードは名前ベースのルックアップを失敗させる可能性があるが、直接の数値通信は依然として可能だった。一時的なサーバー障害はローカルテーブルによって軽減できたが、そのコピーは古いかもしれない。RFC は、単一のグローバルデータベースを、分散型の名前からアドレスへのサービスへの途上にある暫定的な取り決めとして提示した。

より直接的な管理ゲートは、計画された ARPANET/MILNET 分離を取り巻く運用通知に現れた。1982 年 12 月 17 日付けの News No. 18 は、分割中に誤ったユーザーへのサービス拒否を避けるために、ホストと IMP ポートの正確な記録が必要であると述べた。BBN は使用されていないポートを無効にし、DDN-PMO の承認後にのみそれらをアクティブにするよう指示された。新しいホストとポート変更は事前に調整されることになっていた。

News No. 21 は後に手順を改訂した。新規ホストの承認、ポートのアクティベーション、アクティブポートでのホスト変更の要求は、SRI-NIC のメールボックスに送られた。必要な情報には、ホスト名とアドレス、場所、ハードウェア、オペレーティングシステム、スポンサー、プロトコル、技術連絡先の詳細が含まれていた。

ここでは、データの正確性と運用上のアクティベーションが直接結び付けられていた。しかし、News No. 18 に述べられた理由は、NCP/TCP 変換だけに限らず、ネットワーク分割とポート管理だった。決定権限は DDN-PMO であり、BBN は指示の下でポート状態を制御し、NIC は情報を受け取り、維持し、回覧した。これら 3 つすべてを「登録機関」として扱うことは、権力が実際にどこにあったのかを隠蔽するだろう。

割り当てられた番号は別の独立した層を形成した。1983 年 1 月に発行されたRFC 820は、ネットワーク番号、プロトコル番号、ポート、ソケット、その他の実装フィールドに使用される値を記録した。申請者を USC/ISI の Jon Postel に誘導し、割り当ては DARPA の Information Processing Techniques Office と DDN-PMO との間の合意の下で処理されると述べた。

競合する実装や曖昧なパケット解釈を防ぐためには一意の番号が必要だった。その必要性は調整された割り当てへの依存を生み出した。ここで調査した現存資料は、カットオーバー関連の拒否、割り当て決定に対する不服申し立て、または Postel の正式な裁量の前後での変化を示していない。RFC 820 は調整機能とその制度的設定を文書化しているが、それだけでは 1 月の出来事がその機能の権限を拡大したことを証明できない。

これらのメカニズムの区別が、この話の因果的中心である：

• IMP の拒否は、有効化されている場合を除き、管理ネットワーク上で NCP を使用不可能にした。
• DDN-PMO は一時的な NCP 例外を決定し、ホストまたはポートのアクティベーションを承認した。
• ホスト組織は自身のプロトコルソフトウェアを実装し運用した。
• SRI-NIC は名前、アドレス、能力、連絡先、通知を登録・配布した。
• USC/ISI は割り当てられたプロトコル番号とネットワーク番号を調整した。
• ゲートウェイとリレーの運用者は、トラフィックが特定の技術的境界を越えられるかどうかを決定した。
• 外部の運用者は、すべてが DCA の命令ではない、資金提供の取り決め、研究協力、調達規則、または相互運用性のインセンティブの下で TCP/IP を採用した。

カットオーバーはこの連鎖全体にわたる依存を増大させた。しかし、連鎖を一つのオフィスに統合したわけではない。

1972 年～1985 年：制度的境界はネットワークの下で移動した

基本的な年表でさえ、一つの継続的な中央権限を記述することに注意を促している。

公式のDARPA タイムラインは、ARPA の Defense Advanced Research Projects Agency への名称変更を 1973 年ではなく 1972 年としている。DARPA は主要なプロトコルおよび実装作業の背後の研究スポンサーであり続け、その契約者や資金提供パートナーに対してかなりの影響力を保持していた。

DCA が ARPANET の運用責任を引き受けた日付はより整然としていない。2011 年のSRI ARC/NIC 記録のガイドは、運用が 1973 年に DCA に引き渡されたと述べている。同時代の DCA の出版物は後の正式な日付を示している。同機関の 1978 年のARPANET 情報パンフレットは、管理責任が 1975 年 7 月 1 日に移転されたと述べている。

基礎となる段階的移転記録がなければ、これらの記述を誤った確実性に強制すべきではない。後の検索ツールはより早期の運用上の引き渡しを説明している可能性があり、一方で DCA 自身のパンフレットは管理責任の正式な移転を特定している。正式な日付については、同時代の DCA の説明の方が強い。1982 年までには、実際の通知自体が運用階層について曖昧さを残さない。それらは DCA の DDN プログラム管理オフィスのために NIC によって配布され、ネットワーク管理の指示はその構造から来ていた。

1983 年 1 月までに、少なくとも 5 つの集団を区別して保持しなければならなかった。

ARPANET ネットワーク 10 集団は、RFC 801 の NCP/TCP 計画と IMP レベルの TCP 専用テストの直接の対象だった。DCA の運用管理と DDN-PMO の例外決定は、そこで最も明確な効力を持っていた。

MILNET と他の DDN 加入者は、依然として構築中であり分化している、より大きな防衛環境に属していた。それらのプロトコル義務は ARPANET 計画のすべての行に還元可能ではなかった。1985 年の全米研究評議会の報告書であり、RFC 942として再掲されたものは、MILNET バックボーン自体は TCP を必要としなかったが、加入者は一般的にそれを使用するよう要求されていたと述べている。

他の DoD ネットワークは異なる技術的および調達上の経路をたどった。RFC 942 は、既に TCP を使用していたネットワーク、後の変換を計画しているネットワーク、他のプロトコルを使用しているシステムについて記述している。したがって、「DoD インターネット」は一つの普遍的な 1 月イベントを完了した一つの集団ではなかった。

DARPA 資金提供の外部研究パートナーは、スポンサーの期待に直面する可能性があり、実験的なインターネット作業に深く統合されている可能性があった。UCL、衛星ネットワーク参加者、パケット無線研究者、契約者は、様々な運用管理を伴う協力的な取り決めに属していた。プロトコル文書やホストテーブルにおけるそれらの存在は、すべてのマシンを DCA 加入者にしたわけではなかった。

独立した、そしてその後の外部採用者は、DCA の命令への露出がさらに弱かった。彼らは、実装が利用可能だったため、価値のある通信相手がそれを使用していたため、または互換性のないプロトコルが上昇する機会費用を課したために、TCP/IP を選択することができた。そのネットワーク効果の圧力は、内部システムに対する DCA の管轄権を創出することなく強力であり得た。

RFC 942 は、これらの区別を保持しながら、変換の運用上の結果も記録しているため、特に有用である。全米研究評議会の作業は DCA 契約を通じて支援され、1985 年に発表されたため、中立的な 1 月の国勢調査というよりは、部分的に防衛標準の議論によって形成された回顧的な評価である。

報告書は、カットオーバー前の 6 か月間に約 30 の TCP 専用ホストが既存のデュアルプロトコル集団に加わったと述べている。広範なテストが運用能力の維持に貢献し、数か月以内に通常のサービスレベルに達したと評価した。また、NIC は新しいプロトコルをサポートする準備ができておらず、ホストテーブルの配布問題を引き起こしたこと、およびサービスホストは、以前に長期間にわたって完全なユーザー負荷を担ったことがなかったため、大幅なパフォーマンス分析とパラメータチューニングを必要としたことも記録している。

これらは集中した依存の文書化された結果である。テーブル配布は運用的な依存関係であり、単に管理的な象徴ではなかった。限定的なテストでは機能したサービスソフトウェアが、持続的な需要の下ではなおもつまずく可能性があった。実装を整合させることができる期限は、共通サービスへの負荷も集中させた。

この同じ報告書は、勝利の説明を複雑にする。それは、ARPANET は一般的に TCP を使用していたが、一部のユーザーは NCP を使用し続けていたと述べている。この発言は、目標から 2 年後でも、関与するホストや経路を特定していない。しかし、すべての残余の使用が真夜中に普遍的に消滅したという文字通りの主張は論駁される。ポリシー変換、通常のネットワークサービス、ホストソフトウェア、ローカルな使用、一時的または例外的な到達可能性は異なる状態であった。

外部採用：命令が終わり互換性が始まった場所

TCP/IP の幅広い成功は、DCA が管理できる集団を超えて拡大することにかかっていた。

RFC 801 は、ARPANET をパケット無線、衛星、ローカル、その他のネットワークと接続する ARPA インターネットを説明した。RFC 842 と RFC 843 はネットワーク 10 外のアドレスを含んでいた。RFC 844 は、非クラス A テスト経路が多くのエントリに成功裏に到達できることを実証した。これらの情報源は、1983 年初頭までに技術的・制度的境界を越えたインターネットワーキング環境を示している。

しかし、それらはその環境全体にわたる単一の法的または管理的体制を確立するものではない。

ネットワーク 10 のホストにとって、IMP による NCP の拒否は即時の運用事実だった。別個に管理されるネットワークにとっては、決定的な要因は TCP 実装へのアクセス、ゲートウェイ関係、研究契約、ARPANET サービスに到達したいという希望、または増加する互換性のある通信相手の数であり得た。ネットワークは、すべてのローカルホストやポートに対する DDN-PMO の権限を受け入れることなく、内部および外部で TCP/IP を使用することができた。

この違いは、共有記録が元々のスポンサーの管轄権よりも重要になり得た方法を説明する。独立して運用されるネットワークは、より広いインターネットと通信する際に一意のアドレス指定とプロトコル値を必要とした。そのユーザーは正確な名前情報と到達可能なゲートウェイから利益を得た。共通の調整への依存は、元々調整サービスを支えていた契約上の権限よりも遠くまで拡大し得た。

しかし、依存だけでは統治する権利を証明しない。記録管理者は、参加者が互換性のある情報を必要とするために重要になるかもしれないが、彼らの資金、内部システム、または意思決定手続きに対する権限を欠いている。スポンサーは自身のネットワークに対して直接の権限を持つかもしれないが、相互運用性のインセンティブを通じてのみ外部の採用者に影響を与える。したがって、TCP/IP の拡大は、その領域を憲法上均一にすることなく調整の領域を広げた。

これがまた、カットオーバーが後のすべての登録権力を創出したと見なすことができない理由でもある。中央ホストテーブル、割り当て番号調整、DoD 登録規則は既に存在していた。変わったのは、より大きな互換性環境の、エラー、古い能力データ、番号の競合、ゲートウェイ障害、配布の弱点への運用的露出だった。結果の増大は、新たに創出された裁量と同一ではない。

より遅い変換は可能だったが、無料ではなかった

実際の TAC と UDEL の取り決めは、後の技術を 1983 年に持ち込むことなく、歴史的に妥当な代替案をモデル化することを可能にする。

DCA が NCP を 1 月以降も通常の ARPANET サービスとして保持し、ホスト組織が自発的に変換することを許可したと仮定しよう。デュアルプロトコル TAC は引き続き利用可能だったかもしれない。UDEL または追加のホストはメール転送を継続できたかもしれない。Telnet と FTP のリレーアカウントは、互換性のないサービスホストへのユーザーを橋渡しできたかもしれない。サイトは日付付きのHOSTS.TXTのコピーをダウンロードし、プロトコル能力フィールドを使用して直接または中継経路を選択できたかもしれない。

これは困難なシステムへの当面の圧力を軽減しただろう。未完成のベンダーポートに依存するホストは待つことができたかもしれない。管理者はローカルの人員配置やメンテナンスに合わせて変換をスケジュールできたかもしれない。サービスホストは、すべてのユーザーが到着する前に、より長い負荷テストを受けることができたかもしれない。NIC は、サイトが古い経路を保持しながら、TCP ベースの配布を改善できたかもしれない。

代償は恒久的な移行サービスだっただろう。

デュアルプロトコル TAC は継続的なソフトウェアサポートとテストを必要とした。リレーはアカウント、ストレージ、オペレーター、文書化、キャパシティを必要とした。二段階のファイル転送はディスクスペースを消費し、ハウスキーピングを必要とした。メール転送はキュー、プロトコルを意識したアドレス処理、最新の宛先情報、二つの環境にわたる障害を追跡できるスタッフを必要とした。端末ユーザーは追加のコマンドを理解し、直接アクセスと仲介アクセスを区別しなければならなかった。

トラブルシューティングはより局所的でなくなるだろう。失敗したセッションは、いずれかのエンドポイント、いずれかのプロトコルスタック、リレーアカウント、ゲートウェイ、古いホストテーブルのコピー、または誤った能力フィールドを含む可能性がある。サポートスタッフは両方のプロトコル環境の専門知識を保持する必要があった。NCP 経路が機能し続ける一方で、対応する TCP サービスが静かに劣化する可能性があり、その逆もあり得るため、テストは継続されなければならなかっただろう。

スポンサーもまた、非収束に対して支払いを続けるだろう。リレーを使用できるホスト組織は、コストの一部がリレーオペレーターに転嫁されたために、困難な変換作業を延期するかもしれない。互換性サービスが有用になればなるほど、レガシーの孤島が存続しやすくなる。ネットワーク効果は最終的に NCP を魅力のないものにするかもしれないが、そのタイムテーブルは不確実であり、運用上の継ぎ目は何年も存続し得た。

自発的な移行は必ずしもより分散的だったとは限らない。それは一つの運用者が強制した日付のドラマを減らす一方で、リレー、TAC、能力記録、デュアルプロトコルサービスホストの管理者への依存を増大させただろう。権限は消えるのではなく、より見えにくくなっただろう。

また、セキュリティ障害を引き起こしただろうと主張して代替案を拒否することもできない。情報源はそのようなインシデントを文書化していない。それらはより控えめな観察を支持する：すべての追加のアカウント、中間ホスト、保存されたメッセージ、ファイルのコピー、レガシー実装は、アクセス制御と運用上の注意を必要とした。結果として生じるリスクの規模は測定されていない。

実際の変換は異なるコスト配分を選択した。一時的な仲介は引き続き利用可能だったが、その有効期限はホスト組織に実装の作業を吸収することを強制した。DCA と DDN-PMO はネットワークサービスの管理を使用して、その配分を信頼できるものにした。外部ネットワークはその管理の外側で、自らのスケジュールで TCP/IP を採用し続けた。

1983 年において、より説明責任のある調整はどのように見えたか

より読みやすい変換は、現代の認証システム、自動化されたグローバルレプリケーション、豊富な計算リソースについての仮定を必要としなかった。

当時、すでに控えめな改善のための必要な構成要素が存在していた：郵送通知、指名された運用連絡先、ホスト状況調査、ローカルのHOSTS.TXTのコピー、申請プロセス、公開された例外表、スケジュールされたテスト日、電話サポート、リレー、記録の手動比較である。

News No. 19 は、機密でないケースのための完全な公開決定形式に拡張されることができたかもしれない。各例外行は、簡潔な理由カテゴリ、申請日、決定日、承認事務所、NCP 有効化に付随する条件、および指定された変換日が達成されたかどうかを付記することができたかもしれない。機密の詳細は、決定の存在と状態を削除することなく、差し控えたままとすることができたかもしれない。

再審理の要求は、最初の決定を行っていないスポンサーまたは運用担当官に回付されることができたかもしれない。そのような手続きはネットワークに対する DDN-PMO の管理を除去しなかっただろう。しかし、一次管理をレビューから分離し、類似の運用上の問題が類似の扱いを受けたか否かの記録を創出しただろう。

状況の公開も集団を分離することができたかもしれない。ネットワーク 10 コンプライアンス表、DDN 加入者表、外部インターネットエントリの情報リストは、混在したホストテーブルが一つの統治されるコミュニティと誤認されるのを防いだだろう。結果は、登録された能力、受け入れられたアプリケーション接続、別のアドレスクラスからのルーティングテストの成功、承認された NCP 例外、一時的な利用不能、説明不能な結果を区別することができたかもしれない。

配布の回復力は限定的な形で可能だった。複数の読み取り専用ホストが日付付きのホストテーブルのコピーを提供することができたかもしれない。運用者はバージョン日付を比較し、NIC コピーに対して手動の一貫性チェックを実行できたかもしれない。これは停止中の一つの配布マシンへの依存を減らすだろう。しかし、更新権限を分散させることはない。もしすべてのミラーが同じ誤ったマスターレコードを再現するならば、その誤りは権威的なままである。

そのような措置は、スタッフの時間、ストレージ、電話調整、追加の照合作業のコストを要しただろう。記録は不一致となる可能性がある。公開は緊急の運用変更に遅れるかもしれない。一部の防衛情報は開示できなかった。二度目のレビューは、サービスを回復または保護するために迅速に必要とされる決定を遅らせるかもしれない。

これらのコストこそが、説明責任が技術的な調整への無料の追加として扱われ得ない理由である。関連する比較は、より明確な記録を維持するコストと、運用者が障害が技術的、管理的、一時的、または意図的であるかを判断できないときに課されるコストとの間である。

変換記録は、この区別が有用であったであろうことを示唆している。RFC 842 は、アドレスがサービスを受け付けなかったことを示すことができたが、その理由は示せなかった。News No. 20 は、アドレスが NCP を保持していたことを示すことができたが、完全な理由は示せなかった。NIC はプロトコル主張を公開することができたが、観察された動作を保証することはできなかった。DDN-PMO はポートを承認することができたが、承認は欠陥のある実装を修復することはできなかった。より良い記録はそれらの状態を崩壊させないだろう。それはそれらを分離し続けるだろう。

変更された権限はネットワークによって境界づけられていた

1 月の変換は、その主要な運用目的において成功した。TCP/IP は ARPANET の通常の通信環境となり、主要なサービスはその上に移行し、異種ネットワークは共通のインターネットワーク層を通じて参加することができた。2 月の調査は、不完全で経路依存の動作も示しながらも、数百の受け入れるサービスエンドポイントを示している。

変換の力は特定の制度的構造から来ていた。DARPA は研究に資金を提供し、契約者に影響を与えた。DCA は 1970 年代半ばまでに正式に ARPANET を管理した。DDN-PMO は運用ポリシーを設定し、NCP 例外を決定し、ホストまたはポートを承認した。IMP とネットワーク運用者はプロトコル無効化を強制した。ホスト組織は自らのコンピューター上の実装を管理した。SRI-NIC は運用情報を登録・配布した。USC/ISI は割り当てられた番号を調整した。TAC とリレー運用者は一時的な到達可能性を維持した。

この分割は中央集権化の主張の最も強いバージョンを妨げる。証拠は、カットオーバー自体が SRI-NIC に誰が名前に値するかを決定する新たな権力を与えたり、番号割り当てを通じて外部ネットワークを除外する新たな権力を USC/ISI に与えたりしたことを示していない。正確な名前、アドレス、プロトコル能力、数値、配布サービスが、より多くの通信が TCP/IP に収束するにつれて、運用上より重要になったことを示している。

行使された影響力は別の場所にあった。IMP レベルの NCP 拒否は、スポンサーと運用者の権限を具体的なものにした。個別の有効化と有効期限は、影響を受けるネットワーク 10 アドレスに対して DDN-PMO の裁量を結果的なものにした。ホストとポートの承認は、ARPANET/MILNET 分離の間に管理データをネットワークアクティベーションにリンクさせた。NIC の後日のホストテーブル配布問題は、ポリシー拒否ではなく、共有情報サービスへの依存を実証した。割り当てられた番号の調整は一意性を維持したが、調査した記録はカットオーバー関連の拒否や不服申し立てを提供していない。

管理された集団を超えて、互換性のインセンティブが直接の命令に取って代わった。外部の運用者は、成長するコミュニティと相互運用することが有用だったため、スポンサーや調達プログラムがそれを支援したため、または実装が利用可能になったために TCP/IP を採用した。共有識別子への技術的な依存は、彼らのネットワークを DCA、DARPA、SRI、ISI の所有物にはしなかった。

制度的な成果と正当性の問題はしたがって異なる。成果は異種システム間の調整された相互運用性だった。正当性の問題は、拡大する運用上の依存が、より小さなスポンサー管理の環境のために創設された機関の決定記録、審査手続き、継続性の取り決めを追い越す可能性があることだった。

1 月 1 日が重要だったのは、無期限の共存を ARPANET の既定ポリシーとして終わらせたからである。10 月、11 月、12 月の実験は、そのポリシーがどのように強制されるかを実証した。1 月の例外登録簿は、強制が絶対的ではなく、選択的かつ一時的であることを示した。TAC と UDEL は不可欠な継ぎ目を維持した。2 月の調査は、正式な変換、記録された能力、アプリケーション応答、ルーティングされた到達可能性は依然として異なる事実であることを示した。

カットオーバーは、いくつかの既存の権力を運用上決定的なものにすることによって権限を変えた：プロトコルを無効にする権力、一時的な継続を承認する権力、ポートをアクティブにする権力、共有記録を配布する権力、またはリレーを維持する権力。それはまた、それらの権力の範囲を超えた調整への依存を増大させた。これは、単一の権限がインターネットを切り替えたと言うよりも正確であり―そして完璧な真夜中の伝説よりも結果的である。