要約
サーフとロバート・カーンの1974年論文は、異質なパケット網をゲートウェイと共通のアドレス体系で結ぶ設計を示した。ただし、それは完成済みのインターネットでも、サーフ単独の発明でもなかった。
初期の TCP は、後の IP と TCP の役割をまだ一つに抱えていた。ジョン・ポステルらの批判、各機関の実装、番号管理、DoD と DCA の政策、ホストごとの移行作業が、設計を運用可能な境界へ変えた。
1983年の切り替え後にも、接続拒否、到達不能、停止中のホストは残った。成功とは一夜の完全移行ではなく、異なる組織が同じ失敗の見方と修正方法を共有できたことだった。
1983年1月1日、ARPANET で使われてきた NCP から TCP/IP へ切り替える目標日が来た。しかし、締め切りを決めることと、ネットワークが本当に動くことは別である。各ホスト組織は IP と TCP を実装し、Telnet やファイル転送、メールといった主要サービスを用意しなければならなかった。古い方式しか話せないホストと新しい方式しか話せないホストの間には、移行期間のリレーホストも必要だった。RFC 801が描いたのは、祝典ではなく、依存関係の表だった。
翌2月のRFC 842は、その依存関係がどれほど不均一だったかを示す。NIC のホスト表に載る328台を対象に Telnet、FTP、SMTP を試すと、接続を受け付けるサービスがある一方、拒否、到達不能、停止という結果も残った。表に「TCP 対応」と書かれていることと、利用者の接続が成立することは同じではなかった。
この場面からサーフを見ると、人物像の焦点が変わる。問うべきは「誰がインターネットを発明したか」ではない。1973年から積み上げられた彼の設計とプログラム上の判断が、なぜ他者による批判、実装、標準化、番号管理、命令、試験を必要としたのかである。サーフはこの鎖を通る重要な一本の糸だったが、鎖全体ではなかった。
サーフが受け継いだもの、カーンと組み直したもの
1973年の課題は、パケット交換そのものをゼロから思いつくことではなかった。ドナルド・デービスは NPL でデータ通信に取り組む中でパケット交換を発展させており、ルイ・プザンと CYCLADES の仕事はデータグラムと「catenet」という考え方の重要な先行線をつくっていた。サーフとカーンが向き合ったのは、ARPANET、パケット無線、衛星網など、性質も管理主体も異なるネットワークの間で通信を継続させる問題だった。
1974年5月の論文「A Protocol for Packet Network Intercommunication」は、サーフとカーンの共同著作である。設計の核心は、下位の各ネットワークを同じ技術へ作り替えることではなく、その差を越える共通の取り決めを置くことだった。ゲートウェイがネットワーク間をつなぎ、共通の送信元・宛先アドレスを運び、ホスト側が順序、フロー制御、終端間の検査といった責任を負う。統一するのは内部装置ではなく、境界を越えるパケットの意味だった。
そこには大きな取引条件がある。異なるネットワークが自律性を保てる代わりに、端点とゲートウェイは共通形式を厳密に扱わなければならない。中央がすべてを制御しない設計は、参加者の自由を増やすが、故障の場所を一つに限定できない。後の移行でホストごとの差が露出したのは、理念への裏切りではなく、この設計が引き受けたリスクの表れでもあった。
RFC 675は完成形ではなかった
同年12月のRFC 675は、抽象的な構想をより詳細な Internet Transmission Control Program へ落とし込んだ。著者はサーフだけではない。ヨーゲン・ダラル、カール・サンシャインとの三名であり、文書はカーン、ポステルらの寄与も認めている。ソケット、再送、断片化、ゲートウェイ、インターネット・パケットを具体化したことは、サーフの確かな著作上の実績である。同時に、それは共同で作られた途中の設計だった。
重要なのは、1974年の「TCP」を現在の TCP と同一視しないことだ。RFC 675の伝送制御プログラムは、終端間の信頼性だけでなく、インターネット・パケットやゲートウェイに関わる機能まで抱えていた。つまり、後に IP と TCP へ分かれる責任がまだ一つの大きな枠に入っていた。成功物語だけを後から投影すると、設計が修正された事実が消えてしまう。
1977年、ポステルの IEN 2は、ネットワーク間のパッケージ化と経路選択を、ホスト間の終端制御から分離すべきだと論じた。これは単なる整理ではない。パケットを宛先へ運ぶ IP が、信頼できるバイト列を提供する TCP から独立すれば、異なる上位用途が共通の配送層を利用できる。逆に分離は、二つの層の接点、誤りの責任、実装の複雑さを新たに管理する必要を生む。最終形は最初から自明だったのではなく、公開された異論に耐えて変わった。
catenet は「同じ網」を意味しなかった
サーフが1978年7月に書いた IEN 48は、異質なパケット網の連合を catenet として説明した。文書自身がプザンの用語を認めている点は重要だ。サーフの貢献を正確にするには、先行する概念を消す必要はない。むしろ、既存の発想をどの問題に適用し、どの運用条件まで明示したかを見るべきである。
IEN 48が扱ったのは、共通のインターネット・データグラムとアドレス、断片化、異なる網を段階的に追加する方法だった。参加網は内部の交換方式を捨てなくてよい。その代わり、外部との接点では、アドレスとデータグラムの扱いを守る。これは技術選択であると同時に制度設計でもある。全員に同じ設備を買わせるのではなく、相互運用に必要な最小の義務を共有するからだ。
この選択で利益を得たのは、新しいネットワークを全体改修なしに接続したい研究機関や運用者だった。リスクを負ったのは、断片化、経路、アドレス、再送の不整合を現場で診断する実装者である。サーフの構想は多様性を許したが、多様性の費用を消したわけではない。その費用を誰が測り、誰が修正するかが、次の段階の中心になった。
実装者が設計を反証可能にした
1979年5月の IEN 98に並ぶ TCP 実装は、BBN、UCLA、DTI、SRI、NDRE、MIT など複数の組織にまたがっていた。仕様書の文章は一つでも、オペレーティングシステム、端末制御、バッファ、タイマー、ゲートウェイとの接続は一様ではない。各実装は、設計の前提が現実の計算機で成立するかを試す独立した実験でもあった。
1981年の IEN 166が扱った Terminal Access Controller(TAC)は、その難しさをよく表す。既存の NCP と TCP/IP の双方を支えながら、IP 再構成、経路、ゲートウェイ・メッセージ、TCP 接続、再送、ウィンドウ処理を組み込む必要があった。即時の全面切り替えではなく、二重対応という妥協が移行を可能にした。しかし二重対応はコードと状態を増やし、障害の切り分けも難しくする。
同年の IEN 175に記録された会合で、サーフは参加者を迎え、性能、アドレス、文書化を重要課題として示した。そこでは UCL や RSRE を含む参加者が、ゲートウェイ、SATNET や SRCNET、X.25、断片化、送信元経路、動的タイムアウト、測定について報告している。これはサーフのプログラム上の影響を示す一方、解決を彼一人に帰す証拠ではない。彼の役割は問題を共有面に載せることであり、答えは複数の現場から返ってきた。
仕様、番号、政策は別々の権限だった
1980年1月にはRFC 760とRFC 761が、分離された IP と TCP の DoD 標準を記録した。1981年9月のRFC 791とRFC 793が、切り替え前の最終的な仕様境界を示す。これらは DARPA のインターネット計画と USC/ISI の標準化作業の成果であり、最終文面の全項目をサーフ個人の著作とすることはできない。
仕様だけでも動かない。RFC 790の Assigned Numbers は、ネットワーク番号、プロトコル番号、ポートなどの共通台帳を公開した。二つの実装が同じ数値を別の意味で使えば、正しいアルゴリズム同士でも通信できない。番号を安定して割り当て、文書に反映し、参加者が参照できるようにする仕事は、プロトコル設計とは別の運用権限だった。ポステルと USC/ISI の編集・台帳機能を、サーフの設計著作へ吸収してはならない。
サーフには限られた制度上の役割もあった。後年の RFC 1160は、DARPA のプログラム・マネージャーだった彼が1979年に Internet Configuration Control Board を設けたと記録する。だが、その後の再編と権限の継承は後任者と共同体に属する。技術的影響力が、そのまま全ホストへの命令権になったわけではない。
1982年3月の IEN 207では、DoD が相互接続の可能性を持つパケット網に TCP/IP を必須とし、DCA を通信プロトコルの執行主体に位置づけた。例外は個別判断となった。ここで初めて、標準は組織的な強制力を得る。設計者、文書編集者、番号管理者、政策当局、実装組織は同じ人物でも同じ権限でもない。移行が成立したのは、それらが混同されたからではなく、接続されたからである。
切り替えの成果は「完全」ではなく「修正可能」だった
RFC 801は、各ホスト組織にプロトコルと主要サービスの実装責任を置いた。ARPANET News は、ホスト、IMP、TIP ごとの連絡担当者が運用に不可欠だと伝え、DCA と SRI NIC が変更を現場へ流す経路になった。TCP-IP Digest には、実装者と運用者の議論が残る。中央の命令だけで移行したのではなく、ローカルな担当者が自分の装置とサービスを直すことで、全体の期限が意味を持った。
そのため、利益と負担は非対称だった。利用者は異なる網の向こうにあるサービスへ同じプロトコルで到達できる。新しいネットワークは、内部方式を捨てずに連合へ加われる。一方、ホスト管理者、ゲートウェイ担当者、端末アクセスの実装者は、期限までの改修と、期限後の不具合を引き受けた。RFC 842が示す拒否や到達不能の原因が、ソフトウェア、停止、設定、政策、サービス未実装のどれだったかは、全ホストについては分からない。
それでも切り替えは失敗ではなかった。完全性ではなく、共通の観測方法を持てたからである。接続を受け付けたか、拒否したか、届かなかったか、ホストが停止していたかを分類できれば、障害は神秘ではなく作業項目になる。共通のプロトコル境界は、成功した通信だけでなく、失敗を比較可能にした。
サーフの功績も、ここに置くと過不足なく見える。彼はカーンと異質網を結ぶ設計を提示し、ダラル、サンシャインと詳細な初期仕様を書き、catenet の運用前提を言語化し、DARPA の場で課題と参加者を結びつけた。しかし、ポステルの分離論、プザンやデービスの先行貢献、各機関の実装、番号の維持、DoD と DCA の政策、現場の切り替えがなければ、その設計は共有インフラにならなかった。人物を小さくするためではなく、何を実際に成し遂げたかを見えるようにするための共同帰属である。
情報源
- Vinton G. Cerf and Robert E. Kahn, “A Protocol for Packet Network Intercommunication,” IEEE Transactions on Communications, May 1974; public copy hosted by Princeton University.
- RFC 675: Specification of Internet Transmission Control Program, December 1974.
- IEN 48: The Catenet Model for Internetworking, July 1978.
- RFC 760: DoD Standard Internet Protocol and RFC 761: DoD Standard Transmission Control Protocol, January 1980.
- RFC 790: Assigned Numbers, RFC 791: Internet Protocol, and RFC 793: Transmission Control Protocol, September 1981.
- RFC 801: NCP/TCP Transition Plan, November 1981.
- RFC 842: Who Talks TCP? — Survey of 1 February 83, February 1983.
- National Physical Laboratory, Donald Davies.
- Internet Hall of Fame, Louis Pouzin.
画像クレジット
Joi(Jōichi Itō)が2005年に撮影した Vint Cerf の写真(Wikimedia Commons、CC BY 2.0)を基にした、AI 支援の編集用合成画像です。抽象的なネットワーク部分は Codex 経由の OpenAI imagegen で編集表現のために生成したもので、1973〜1983年のプロトコル設計や移行を記録した写真ではありません。
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
