要約

  • IMP は「初期の IP ルーター」ではなく、ARPANET 専用に作られた機能豊富なパケット交換装置だった。メッセージの分割・再構成、チェック、論理リンク、トレース、フロー制御などを共有網に持たせる一方、最初期の RFC は、ホスト側が合意し実装しなければ成立しない機能を明確に残している。
  • この分業から読み取れる制度的な意味は限定的だが重要である。BBN は ARPA との契約、納入したハードウェアとソフトウェア、そして Host–IMP インターフェースについて実質的な権限を持った。しかしその権限は、ホストソフトウェア、アプリケーション、まして将来の独立ネットワーク全体を統治する恒久的な権限ではなかった。のちのオープンアーキテクチャとエンドツーエンドの設計は、インフラを不要にしたのではなく、共通基盤が完全に正しくできる仕事と、端点の知識を必要とする仕事とを、より厳密に分け直した。

ネットワークを「箱」に切り出すという決断

1960年代末の ARPANET について語るとき、パケット交換という技術概念そのものの発明史へ話を広げることは容易である。だが IMP の意味を理解するうえで重要なのは、誰が最初にパケット交換を思いついたかではない。BBN だけをその発明者とみなすことも史料からは正当化できない。ここで見るべきなのは、ARPA が通信機能の一部を専用のサブネットとして切り出し、それを実際に調達し、納入可能な機械として運用したことである。

1968年、BBN は ARPANET の IMP 開発契約を獲得した。実装の土台には Honeywell 516 が使われ、これが専用パケット交換機へと作り替えられた。最初の IMP は1969年9月に UCLA へ納入される予定であり、ホスト側のチームはその日程に合わせて、自分たちのコンピューターを IMP に接続するインターフェースとソフトウェアを準備しなければならなかった。

この事実には二つの意味がある。

第一に、ARPANET の共有網は抽象的な協議体ではなかった。契約があり、納期があり、機械があり、コードがあり、回線があり、故障に対処する運用があった。通信機能をホストから切り離すという発想は、調達された装置として動かなければネットワークにはならない。

第二に、専用サブネットを設けたからといって、ネットワークに関するすべての問題が BBN の箱へ移されたわけではない。むしろ最初期の文書は、箱の責任範囲を具体化すると同時に、その外側に残った責任を露出させた。

RFC 1 は、この分業を驚くほど率直に記している。ARPA Network のソフトウェアは、一部が IMP に、一部がホストに存在する。IMP ソフトウェアについては BBN が仕様を定める一方、ホストソフトウェアについては各ホストグループが合意しなければならない。

これは単なる組織図ではない。

一方には、調達され、共通に配備され、単一の請負業者が責任を持って実装する通信基盤がある。他方には、異なるコンピューターを所有する研究拠点があり、それぞれが自分のホスト上で動く通信ソフトウェアを作らなければならない。両者の境界には Host–IMP インターフェースがある。

初期 ARPANET の重要な革新の一つは、この境界が紙の上だけではなく、実際の機械とコードの境界として存在したことである。

IMP は「空の土管」ではなかった

後世のインターネットを知る者が初期 ARPANET を読むと、二つの逆方向の誤解に陥りやすい。

一つは、IMP を現代の IP ルーターの未熟な祖先として扱うことだ。これは粗すぎる。IMP は IP より前の ARPANET 専用パケット交換機であり、後世の IP ルーターと同じサービスモデルで動いていたわけではない。

もう一つは、後世の「薄いコア」という発想を逆投影し、IMP を単純な中継装置だったと考えることだ。これも間違っている。

RFC 1 に記された IMP の仕事は相当に厚い。

ホストから渡されるメッセージは最大8,080ビットで、それを最大1,010ビットの単位へ分割する。パケットには24ビットの循環チェックが用いられ、ネットワークを通過した後、宛先側の IMP がメッセージを再構成する。論理リンクが存在し、トレース機能があり、Request-for-Next-Message、RFNM によるフロー制御も組み込まれている。

つまり IMP は、ただ宛先を見て次の回線へビット列を押し出すだけの装置ではない。

そこにはパケット化、再構成、エラー検出に関わる処理、測定や診断のための仕組み、通信量を制御する仕組みがあった。その後の RFC 528 が IMP ソフトウェアのチェックサムを扱っていることも、信頼性が単なる初期実験上の関心ではなく、運用上継続して重要だったことを示している。

Frank Heart の回想で強調される設計上の関心も、同じ方向を向いている。信頼性、デバッグ、再ロード、回線のクロスパッチング。ネットワークを研究デモから稼働するシステムへ変えるには、パケット交換アルゴリズムだけでは足りなかった。壊れたときに調べられ、復旧でき、通信線を扱え、ソフトウェアを再び動かせなければならない。

ここから見えてくるのは、共有インフラへ機能を集める強い経済合理性である。

もし各ホストが独自に回線制御、ネットワーク内部の障害対処、メッセージ分割、経路上の診断機能を実装しなければならないなら、参加拠点ごとに重複投資が発生する。しかもホストは互いに異なる。通信部分を専用装置へ集約すれば、共通機能を一度設計し、同じ仕組みとして配備できる。

これは共有基盤の典型的な便益である。

だが同時に、それは責任集中でもあった。

共通装置が多くの仕事を引き受ければ、その実装の誤り、状態管理、性能限界、障害復旧が複数のホストに共通する問題となる。共有機能が増えるほど、参加者はその機能を個別に置き換えにくくなる。

IMP は、その便益と集中の両方を体現していた。

RFC が露出させた「ネットワークだけでは完結しない仕事」

IMP が多くの仕事を担ったことと、IMP が通信の正しさを単独で保証できたことは同じではない。

ここが、この歴史で最も重要な点の一つである。

RFC 1 は論理リンクの仕組みを説明しながら、特定の輻輳を制限できる一方で、宛先 IMP がすべてのリンクを同時に扱える容量を持っているわけではないことにも触れている。そのためホスト側の協力が必要になる。

つまり共有網にフロー制御の機構を置いても、ホストの行動まで不要にはならなかった。

RFC 2 を見ると、ホストソフトウェア側ではリンク状態、チェック、確認応答、遠隔ホストの状態などを扱う。RFC 7 では、Host–IMP インターフェース処理に加え、ホスト側の多重化やバッファ処理が扱われる。

境界は、単純な「ネットワークが下、アプリケーションが上」という二分法ではない。

IMP が一部の信頼性を担う。ホストも状態を持つ。IMP がフローを制御する。ホストもバッファとリンクを管理する。ネットワークは診断機能を提供するが、通信相手やアプリケーションに関する完全な意味知識を持つわけではない。

ここから得られる教訓は、「ネットワーク機能は悪い」というものではない。

より正確には、ある機能が共有インフラに実装されていることと、その機能によってシステム全体の正しさが完成することを区別しなければならない。

例えば下位層のチェックは、転送中に生じた特定の破損を発見するのに有用である。だが最終的にアプリケーションが意図したデータを受け取ったかどうかは、より広い経路と状態を知る端点でしか完全には確認できない場合がある。

フロー制御も同様である。あるリンクや IMP の過負荷を抑える仕組みは有益だが、それによってすべての送受信者の意味上の要求が自動的に満たされるわけではない。

この違いは、後にエンドツーエンドの議論が明示的な設計基準として言語化することになる。

しかし1969年の参加者がすでに成熟したエンドツーエンド原則を共有していた、と書くべきではない。

当時の ARPANET は、むしろ相当量の機能を IMP に置いていた。後世の理論は初期の境界を照らすためには使えるが、後世の思想を当時の意図として読み込んではならない。

信頼できる一つのネットワークという前提

初期 ARPANET の分業は、一つのネットワークの内部では合理的だった。

IMP サブネットが共通して存在し、ホストはそのサービスを前提に NCP を使う。ネットワーク側が高い信頼性を提供するなら、ホストはその前提の上に通信機能を構築できる。

だが、インターネットワーキングが必要になった瞬間、この前提の弱さが表面化する。

Internet Society の歴史整理では、NCP は ARPANET がエンドツーエンドの信頼性を提供することに依存していた。また宛先の扱いも、ARPANET 内の宛先 IMP という枠を越えることができなかった。

この設計は、「一つの共通ネットワーク」が通信の土台である限りには成立する。

ところがパケット無線、衛星ネットワーク、その他の独立に設計されたネットワークを相互接続しようとすれば、事情が変わる。

独立ネットワークには独立した技術判断がある。異なるパケットサイズ、性能、遅延、信頼性の性質、運用主体、内部プロトコルを持ちうる。それらを一つの巨大な ARPANET のように統一しないまま接続するには、「共有ネットワークがすべてを正しくしてくれる」という前提を捨てなければならない。

ここでオープンアーキテクチャの考え方が重要になる。

各ネットワークはそれ自体で成立する。内部の変更を要求されずに接続できる。ネットワーク間の中継点は単純なブラックボックスとして働き、転送はベストエフォートを基本とする。必要な再送は送信元側から行う。

これは初期 IMP モデルを全面否定したのではない。

むしろ、IMP が一つのネットワーク内部で提供していた価値と、複数の独立ネットワークをまたぐ共通層が提供できる価値とを分離し直したのである。

一つの管理されたサブネットなら、ネットワーク内部にかなり厚い信頼性機能を持たせることができる。

しかし異質なネットワークを接続する共通層が同じ種類の内部状態や保証を要求すれば、各ネットワークの独立性を失わせる。共有層が厚くなるほど、参加条件も統一される。

この転換の経済的意味は大きい。

統一された共有基盤は、参加者の重複コストを減らす代わりに、参加者が基盤の設計前提へ従うことを要求する。

それに対して最小限の共通層は、一部の重複や端点実装の負担を残す代わりに、独立したシステムが異なる内部設計を維持したまま相互接続する余地を広げる。

したがって「コアを薄くする」とは、単に機能を減らす美学ではない。

異質性を受け入れるための制度設計でもある。

TCP の前段階で起きた責任の再配置

1974年12月の RFC 675 に記録された Internet Transmission Control Program は、この変化を具体的なプロトコル設計へ進めた一つの節目である。

ここでも重要なのは、1983年の TCP/IP 切替を再話することではない。

注目すべきなのは、複数のネットワークを結ぶという問題が、通信の回復可能性をどこへ置くかという問題を作り変えたことである。

一つの ARPANET 内部なら、IMP サブネットに信頼性機能を持たせ、そのサービスを NCP が前提にできる。

しかし独立したネットワークをまたぐ場合、中間ネットワークの一つ一つが完全な信頼性を保証することを要求すれば、インターネットワーキングはそのネットワークすべての共通設計を必要とする。

そこで共通部分の役割を狭め、失われたデータへの対処などを端点側へ戻す。

この再配置は、ネットワーク内部の信頼性向上を無意味にするわけではない。

あるネットワークがローカルにエラー率を下げたり、フローを円滑にしたり、経路を効率化したりすることは依然として価値がある。

ただし、そのローカルな改善を「全経路にわたる完全な正しさ」と同一視しない。

後の Saltzer、Reed、Clark のエンドツーエンド論は、この区別をより一般的な配置基準として定式化した。

ある機能を完全かつ正しく実装するためにアプリケーション固有の知識が必要なら、端点の協力なしに下位層だけで完結させることはできない。一方で下位層に同様の機能を置くことが、性能改善として有益な場合はある。

この「完全な正しさ」と「有益な補助」の区別こそ、IMP の歴史を後世から読むときに最も生産的な視点である。

IMP は多くの仕事をした。

その仕事の多くは本当に必要だった。

しかし、共有網が多くの仕事をしているという事実から、共有網がアプリケーションの最終的な正しさまで所有するという結論は導けない。

RFC 3439 に見られる後世のシンプルな IP 層への志向も、同じく「ネットワークを空にする」提案ではない。

ルーティングも転送も測定も運用状態も必要である。粗い粒度の経路状態も存在する。

問題は状態の有無ではなく、どの種類の状態を、すべての参加者が共有しなければならない共通層へ置くのかである。

契約上の権限とアーキテクチャ上の権限は同じではない

IMP の歴史を制度論へつなげるとき、最も慎重でなければならないのはここである。

BBN の権限は実在した。

1968年の契約を獲得し、Honeywell 516 を IMP へ作り替え、ソフトウェアを実装し、納入し、信頼性やデバッグ、再ロード、回線運用の問題に責任を負った。ホストチームは BBN が提供する IMP とそのインターフェースに合わせて準備する必要があった。

したがって「請負業者に権限などなかった」と書くのは誤りである。

調達権限は重要だった。

納入された実装も重要だった。

インターフェース仕様も重要だった。

動くシステムを作るには、誰かが決めなければならない領域が確かに存在する。

しかし、その権限の範囲は無限ではない。

RFC 1 が示すように、IMP ソフトウェアとホストソフトウェアには責任の分離があった。BBN が IMP を定義することから、ホスト側のすべてのプロトコルを恒久的に決める権利は生まれない。

さらにその後、独立したネットワーク同士を結ぶインターネットワーキングが必要になったとき、ARPANET 内部の IMP 設計が、他のすべてのネットワークにとって永久の設計権限となったわけでもない。

ここから導ける制度的な推論は狭く保つべきである。

権限は、実際に調達され、実装され、運用され、インターフェースとして提供された機能に追随する。

ある主体が共有インフラを正当に運用しているからといって、その主体がインフラを利用するすべての上位機能について継続的な政策権限を得るとは限らない。

これは、契約を軽視する議論ではない。

逆である。

何が契約され、何が納入され、どのインターフェースが約束され、何がその外側に残されたかを厳密に区別するからこそ、権限の範囲を正確に測れる。

「誰が重要だったか」ではなく、「何について、どの根拠で決定権を持ったのか」を問うのである。

動くコードが境界を現実にする

この点では、実際に稼働する実装を重視することが有用である。

ただし、それを1969年の参加者自身の思想として扱ってはならない。これは史料ではなく、史料を読むための規律である。

IMP の責任境界が現実だったのは、宣言されたからではない。

BBN が実装し、ハードウェアを納入し、ホスト側がインターフェースを作り、両者のコードが通信したからである。

Host–IMP インターフェースは、制度上の抽象概念ではなく、異なる責任領域を接続する実行可能な境界だった。

この見方からは、共通層に何を置くべきかという問いも変わってくる。

最初の共通仕様に必要なのは、すべての参加者が同じでなければ相互運用できない部分である。

しかし将来生じうるあらゆる選択を最初から共通層へ入れる必要はない。

実際に異なるネットワークを相互接続する歴史が示したのは、共通基盤が一つのネットワークの内部事情を過度に要求すれば、異種ネットワーク間の接続可能性が損なわれるということだった。

だからこそ、後のインターネットは「何もないコア」を選んだのではなく、「最低限共通でなければならないもの」と「参加者ごとに異なってよいもの」とを区別する方向へ進んだ。

この区別には、技術上の効果だけでなく制度上の効果がある。

共通層に置かれた機能は、全参加者の相互運用条件になりやすい。

端点または任意サービスに置かれた機能は、導入しない参加者が存在しても、他者の相互運用を必ずしも壊さない。

したがって共通層へ新しい状態や判断を追加するとは、単にコードを一つ追加することではない。

それは、どの主体の判断を全員の依存関係へ変えるかという決定でもある。

中間装置へ戻ってくる誘惑

この歴史が現在にも意味を持つのは、中間装置が役に立たないからではない。

むしろ逆である。

中間装置は役に立つから、機能が集まる。

信頼性を上げられる。トラフィックを測定できる。異常を検知できる。アクセスを制御できる。共通処理を一度実装すれば、端点側の重複を減らせる。

IMP が示したのも、まさにこの強みだった。

だから現代のインフラ設計で問題になるのは、「中間装置を使うか、使わないか」という二択ではない。

問うべきなのは、その中間装置が持つ状態や判断が、ローカルな性能補助なのか、システム全体の正しさを決める不可欠な状態なのかということである。

さらに、その状態が特定のアプリケーション、特定の主体のアイデンティティ、特定の政策判断、特定の商業条件を理解しなければ成立しないのであれば、それをすべての参加者が共有するネットワーク層へ置くことには高いコストが伴う。

第一に、置き換えコストが上がる。

端点が独立して正しさを確認できず、中間装置だけが重要な状態を持つなら、その装置を迂回したり別実装へ移行したりすることが難しくなる。

第二に、障害範囲が広がる。

一つの中間装置の誤動作が、単なる局所的性能低下ではなく、アプリケーションや利用主体の有効性そのものへ波及しうる。

第三に、運用上の集中が制度上の権限へ変わりやすくなる。

あるサービスが便利だから多くの参加者が利用している状態と、そのサービスの判断を利用しなければ参加者として成立しない状態は異なる。

IMP の歴史から導けるのは、後者への移行を自明視すべきではないということだ。

BBN は IMP を動かすための実際の権限を持っていた。それが必要だったからである。

しかしその権限は、ネットワークの外部にあるあらゆる意思決定を吸収する根拠にはならなかった。

この区別は、中間装置がより賢くなり、より多くの状態を保持できるほど重要になる。

「薄いコア」とは、弱いコアではない

インターネット史を制度論へ利用するとき、「中央を薄くすればよい」というスローガンに還元するのも危険である。

薄いコアは、無責任なコアではない。

転送が必要である。

ルーティングが必要である。

相互運用に必要な形式がある。

共有セキュリティ上の不変条件もありうる。

測定もデバッグも運用状態も必要である。

初期 IMP の経験は、こうした共通機能の価値を否定するどころか、その重要性を証明している。

問題は厚さそれ自体ではない。

その厚さが何を根拠にしているかである。

共有層の機能が、独立した参加者が相互運用するために不可欠であり、各参加者が共通に理解できる客観的な規則で実装できるなら、共通層へ置く強い理由がある。

一方、ある機能の完全な正しさが端点しか持たない知識に依存するなら、共有層だけにそれを預けることはできない。

また、ある機能が便利ではあっても、全参加者の共通条件である必要がないなら、任意サービスとして提供する余地がある。

この三分法――共通基盤、任意の中間サービス、端点――を意識すると、IMP から後のインターネットへの変化を「厚いネットワークから薄いネットワークへ」という単純な線形進歩として扱わずに済む。

より正確には、機能の配置基準が成熟したのである。

正しさを誰が最終確認できるか

エンドツーエンドの議論を、ネットワーク内部の機能を禁止する教義として読むと、その実務的な強さを失う。

重要なのは、最終的な正しさの確認に必要な知識を誰が持っているかである。

ネットワーク内部がチェックを行えば、転送中のエラーを早く検知できる。

中間層が再送やキャッシュを行えば、性能が向上する場合がある。

流量を制御すれば、局所的な輻輳を緩和できる。

これらは役に立つ。

しかしアプリケーションの目的そのもの――たとえば送信した完全な内容が意図した相手へ正しく届き、その内容をアプリケーションが受理できること――を最終的に判断するには、端点側の知識が不可欠になる場合がある。

下位層の補助を上位層の検証の代わりにしない。

この配置基準をネットワーク以外の機能へ拡張すれば、同じ質問が使える。

その判断は、ネットワーク層が本当に知りうる事実だけで完結するか。

端点自身が独立に確認できるか。

中間装置が誤った場合、端点はその結果を検出できるか。

別の実装へ切り替えても相互運用できるか。

そのサービスを拒否すると通信そのものが不可能になるのか、それとも単に一つの性能上の便益を失うだけなのか。

これらはすべて、機能配置と権限配置を同じ問題として考える質問である。

歴史が証明すること、証明しないこと

この歴史から強く言えることは限られている。

第一に、最初期の ARPANET には明確な責任分割が存在した。

IMP ソフトウェアは BBN の領域であり、ホストソフトウェアはホスト側グループが合意し、実装する領域だった。

第二に、IMP は非常に多くのネットワーク機能を担った。

したがって ARPANET が後世のエンドツーエンド原則をすでに完成させていたとは言えない。

第三に、それでもホスト協力を必要とする機能は残った。

IMP が共有網を賢くしても、ネットワークだけですべての通信状態を完結できたわけではない。

第四に、NCP が一つの信頼できる ARPANET を前提とすることは、独立した異種ネットワークをつなぐ段階で制約になった。

第五に、後のオープンアーキテクチャとエンドツーエンドの配置基準は、共有基盤の役割をなくすのではなく、その役割をより狭く、より一般化可能なものにした。

そこから制度的に推論できるのは、実装上の権限を機能の範囲へ結びつけるべきだ、という限定的な結論である。

BBN が IMP を作る権限を持ったことは、実際の契約と納入によって裏づけられている。

だが、そのことから将来のホスト、アプリケーション、独立ネットワーク全体を統治する恒久的な権限が生まれたとは言えない。

一方で、この史料だけから、当時の関係者が「権限の最小化」という政治哲学を共有していたと推論することもできない。

最初期の RFC は作業文書であって、ARPANET の完全な憲法ではない。

残された RFC や口述史も、あらゆる契約指示、実装上の議論、組織間の争いを網羅してはいない。

また1980年代以降のエンドツーエンド論を、1969年の参加者の自覚的教義として投影してはならない。

史料から見えるのは、より具体的なことである。

通信網は、責任を分けなければ作れなかった。

共有基盤は、具体的な仕事を担うから価値があった。

しかし共有基盤が価値を持つことと、共有基盤の運営主体が将来のすべての選択を支配することは同義ではなかった。

そして複数の独立ネットワークをつなぐ必要が生じると、共通層には「多くを知ること」よりも、「異なるもの同士でも共通に実行できること」が求められるようになった。

インターネットが学んだのは、インフラを信頼しないことではない。

信頼を、機能の境界より広く与えないことである。

出典と証拠の限界

https://www.rfc-editor.org/rfc/rfc1.html

https://www.rfc-editor.org/rfc/rfc2.html

https://www.rfc-editor.org/rfc/rfc7.html

https://www.rfc-editor.org/rfc/rfc528.html

https://www.rfc-editor.org/rfc/rfc1000.html

https://archive.computerhistory.org/resources/access/text/2012/11/102706168-05-01-acc.pdf

https://archive.computerhistory.org/resources/access/text/2017/11/102702222-05-01-acc.pdf

https://www.internetsociety.org/internet/history-internet/brief-history-internet/

https://www.internetsociety.org/internet/history-internet/brief-history-internet-related-networks/

https://datatracker.ietf.org/doc/html/rfc675

https://groups.csail.mit.edu/ana/People/DDC/ebook-arch-V1.pdf

https://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf

https://www.rfc-editor.org/rfc/rfc3439.html