8/17/2020

今日のインターネットはいまだにARPANET時代のプロトコルを信頼している: Request for Comments

IEEE Spectrumより

RFCは、ARPANETの最も永続的な遺産かも知れません。

スティーブ・クロッカー

UCLAのBoelter Hallには、4つのオリジナルARPANETノードの1つが収容されていました。

毎年3月、7月、11月になると、私たちはインターネットが成熟して安定した技術ではないことを思い知らされます。私たちは、経済、社会、教育、政治の生活に不可欠なツールとしてインターネットに依存しています。しかし、インターネット・エンジニアリング・タスク・フォースが4か月に1度、大陸から大陸へと移動する公開会議で会合を開くと、世界中から1,000人以上の人々が考えを変えさせるために集まって来ます。全人類が共有するグローバル・ネットワークに関する彼らのビジョンは、ダイナミックで進化し、継続的に改善されています。彼らの努力は、無数の他の人々の貢献と相まって、インターネットを常に機能することを保証していますが、決して完成されたものではなく、決して完全なものではありません。

インターネットの急速かつ秩序だった進化は、企業、政府、また管理する理事会がない非常に珍しい方法で起こっていることを考えると、なおさら驚くべきことです。デジタル通信技術は、自己組織化されたものであるべきと示唆するもの何もありませんし、ましたや根本的に信頼できると示唆するものもありません。私たちはインターネットを楽しんでいるのは、何世代にわたるネットワーク開発者たちが、技術の歴史の中で、非常にまれな原理とプロセスを採用してきたからです。原理とは、インターネットに接続されたデバイスの通信方法をコントロールするプロトコルは、オープンで拡張性があり、堅牢でなければならないというものです。そして、それらのプロトコルを発明し、洗練させるプロセスには、参加を希望するすべての人の間での協力と高度なコンセンサスが必要です。

インターネットの前身であるARPANETのプロトコルを開発するために、非常に意図的に協調的で合意に基づくプロセスを採用した小さなチームの一員であった者として、私は物理的なネットワークが1960年代半ばの50キロビット/秒の電話回線から今日の私たちが享受する光ファイバー、5G、衛星回線へと進化しても、これらのアイデアがいかに存続し、成功したかに驚いています。私たちのチームは、忘れられない「プライバシーパス」や、インターネット接続されたドローンのための偽造不可能なユニークな識別子など、今年3月のタスク・フォースで話し合われた2つのプロトコルの提案を決して想像していませんでしたが、ARPANETのアイデアを技術メモとして、遠く離れたコンピュータ科学者グループに回覧し、フィードバックを集め、はるかに小規模ではありますが、今日と同じような方法で、解決策に決定しました。

私たちは、これらの初期のメモのそれぞれを「Request for Comments (コメントの要求)」またはRFCと呼んでいました。今日使用しているネットワーク・デバイスが何であれ、それはほぼ間違いなく数十年前に書かれたARPANET RFCで定められた規則に従っています。おそらく、プレーンASCIIテキスト(RFC 20、1969年発行)、オーディオやビデオ・データ・ストリーム(RFC 768、1980年)、ポスト・オフィス・プロトコル(POP)、電子メール(RFC 918、1984年)を送信するためのプロトコルが含まれていると思われます。

RFCの分析

初期のARPANETのための新しいプロトコルの開発を管理するため、ネットワーク・ワーキング・グループは、コンセンサスで合意されたRequests for Comments(RFC)に依存していました。1969年に発行されたRFC 20は、ARPANET上でのテキスト送信を扱いました。


  1. ジョン・ポステル(上)は、スティーブ・クロッカーとヴィント・サーフの高校時代の同級生であり、UCLAの同僚でもありました。彼は、Request for Commentsシリーズの編集者として知られるようになり、197のRFCを執筆しました。これは、RFC 20のポステルのコピーをスキャンしたもので、この文書はサーフがARPANETホスト間の通信のための標準テキスト符号化方式として7ビットASCIIを提案したものです。ポステルが1998年に亡くなったとき、サーフは彼の追悼文をRFC 2468として公開しました。
  2. 各RFCにはシリアル番号が割り当てられていて、通常は書き込まれた後に、シーケンス内のギャップを避けるために番号が付けられています。このRFCは20番目に回覧されたものでした。
  3. ARPANETは、オペレーティング・システムが文字を表現するために異なるビット数を使用する多様なマシン・セットやホストを接続していました。7ビットと8ビットの両方のシステムで動作する米国のASCII標準は、ホスト間の通信に理想的でした。ポステルのRFCのコピーには、固定上位ビットを0から1に変更する提案が含まれています。その変更は採用されませんでした。
  4. ASCIIには、ACK(確認)、EOT(伝送の終了)、SYN(同期アイドル)など、テレタイプサービスで頻繁に使用される32のデバイスと伝送制御文字が含まれていましたが、ARPANETでは使用されませんでした。
  5. RFCでは、128文字のそれぞれが7ビットの数値で表すことを提案しており、3ビットが表の列に対応し、4ビットが行に対応します。従って、「A」は1000001であり、列/行の形式では4/1、または0x41または10進数65で表されます。
  6. HT(水平タブ)のような一部のデバイス制御コードは、技術の進化に伴って簡単に再利用できるものがあり、この場合はタブに転用されました。CR(キャリッジ・リターン)やLF(ライン・フィード)などの他のコードは、様々なオペレーティング・システムで一貫して使用されておらず、整理するのに数十年かかりました。

もちろん、技術は進歩します。ARPANETを構築するために使用されたコンピュータや通信ハードウェアのどれもが、今日のインターネットの重要な部分ではありません。しかし、1969年以降、常に使用され続けている技術システムが1つだけあります。それは、初期の段階で変更そのものを管理するために発明したつつましいRFCです。

1969年12月、ARPANETにはわずか4つのノードしかありませんでした。

ARPANETは、ネットワークのネットワークではなく単一のネットワークであったため、インターネットよりもはるかに単純でした。しかし、1966年に国防総省の高等研究計画局(ARPA)が、カリフォルニアからマサチューセッツまでの数十以上の研究大学で、全く異なる種類のコンピュータを結びつけるアイデアを計画し始めたとき、このプロジェクトは非常に野心的なものに思えました。

基本設計には2年の歳月を要しましたが、それは、わずか4つのサイトでコンピュータを接続する専用の電話回線でデータのパケットを交換する初期のサブネットのためのものでした。その4つのサイトは、カリフォルニア大学のサンタバーバラ・キャンパスとロサンゼルス・キャンパス、カリフォルニア州メンロパークにあるスタンフォード研究所(SRI)、ソルトレイクシティのユタ大学です。各サイトでは、ルータ(インタフェース・メッセージ・プロセッサの略でIMPと呼ばれています)は、送信されたビットのブロックを小さなパケットに分割します。また、IMPは、遠方のコンピュータからの着信パケットを、ローカルの「ホスト」コンピューターが処理できるブロックに再構成します。

1968年にUCLAでARPANETプロジェクトに取り組み始めたときのスティーブ・クロッカー[左]とヴィント・サーフ[右]は大学院生でした。

1968年の激動の夏、私は大学院生で、高校の親友であるヴィント・サーフが勉強していたUCLAのコンピュータ・サイエンス学部で数か月間過ごしたした。この分野の他の多くの研究者と同様に、私はネットワークよりも人工知能やコンピュータ・グラフィックスに興味を持っていました。実際、最初の4つのサイト以外の研究責任者の中には、当初ARPANETプロジェクトを好機というよりはむしろ侵入(intrusion)と見なしている人もいました。8月の終わりに、ARPAが4つのパイロット・サイトのそれぞれ2人をサンタバーバラで開催されたキックオフ・ミーティングに招待したとき、ヴィントと私はUCLAから車で向かったのですが、他の参加者は全員、大学院生かスタッフメンバーであることが分かりました。教授は一人も来ていませんでした。

私たちのほとんど全員が、他のサイトの誰とも会ったことはなく、一緒に仕事をしたこともありませんでした。しかし、私たちは皆、集中型メインフレーム・コンピュータの処理時間の塊を、リモート接続された一連のユーザに分配するタイム・シェアリング・システムに取り組んできたので、遠く離れたコンピュータを接続して、そのアプリケーションを相互に作用させることで、面白いことができるという感覚を持っていました。実際、私たちは、コンピュータの汎用的な相互接続が非常に便利になり、最終的には基本的にすべてのコンピュータに普及するだろうと予想していました。しかし、私たちは、この小さなネットワークをグローバルなインフラの重要な部分に成長させるための共同プロセスが、この会議でどのように開始するのか、私たちは確かに予想していませんでした。そして、今後数年間の共同作業が、私たちの生活を劇的に変えることになるかとは、全く考えてもいませんでした。

サンタバーバラでお互いを知り合った後、他の各拠点でフォローアップ・ミーティングを開催し、この折衷的なネットワークがどのようなものになるのか、全員が共通の見解を持てるようにしました。UCLAのSDS Sigma 7コンピュータは、ユタ州のDEC PDP-10、サンタバーバラのIBM System/360、そしてSRIのSDS 940に接続されていました。

私たちは分散型チームで、様々なマシンやオペレーティング・システム上で動作するソフトウェアを作成することになります。その一部は、文字を表すために同じビット数を使用していませんでした。このプロジェクトに担当したARPAが任命した教授からなる委員会の名前を採用して、私たちは自分たちを『ネットワーク・ワーキング・グループ』と呼びました。

ボルト・ベラネク・アンド・ニューマンのチームは、各ARPANETサイト用のインタフェース・メッセージ・プロセッサ(IMP)を構築しました。

私たちは、R&D会社のボルト・ベラネク・アンド・ニューマン(BBN)がマサチューセッツ州ケンブリッジでIMPが構築されるのを待っている間、1968年の秋から1969年の冬にかけて、プロトコルの一般的なアーキテクチャに関する理論的な作業を完了させるのに数か月しかありませんでした。

私たちのグループは、ネットワークが何をすべきかという具体的な要件を与えられていませんでした。プロジェクト・マネージャーから定期的なステータス・レポートの提出や、確固たるマイルストーンの設定を求められることもありませんでした。各サイトのユーザがリモートでログオンし、他のサイトのホストとの間でファイルを転送できるという一般的な前提以外は、便利なサービスを作るのは私たちに任されていました。

定期的な会議を重ねる中で、3つのアイデアが形となり、より広範なビジョンが見えて来ました。第一に、私たちは多くの興味深いネットワーク。サービスの可能性を見ました。例えば、異なるアプリケーション・プログラムがネットワークを介してメッセージを交換したり、互いのサブルーチンを実行して、リモートで相互に制御したりすることもできるのではないかと想像しました。私たちは、その可能性を探りたかったのです。

次に、ネットワーク・サービスは拡張可能であるべきだと考えました。タイム・シェアリング・システムは、プログラムを書いて、他のユーザに使わせるだけで、新しいサービスを提供できることを実証していました。ネットワークもそれと同じような能力を持つべきだと感じました。

最後に、私たちは、ネットワークがホストのハードウェアにとらわれなければ、最も有用であることを認識していました。私たちが書いたどのようなソフトウェアであっても、単語の長さ、文字セット、命令セット、アーキテクチャに関係なく、あらゆるマシンをシームレスにサポートしなければなりません。

BBNは、IMPへのインタフェース仕様をまだリリースしていなかったので、これらのアイデアをすぐにソフトウェアに変換することはできませんでした。しかし、私たちは考えを紙に書き留めておきたかったのです。1969年3月にネットワーク・ワーキング・グループがユタ州に集まったとき、私たちはお互いに執筆の課題を出し合いました。ネットワークを稼働させ、電子メール・プロトコルを作成するまでは、郵便を使ってメモを共有しなければなりませんでした。このプロセスをできるだけ簡単で効率的なものにするために、私は番号付きのドキュメント・リストを回覧し、著者は自分たちが書いたメモのコピーを他の人に郵送しました。

とりあえず、しかし、興奮が高まる中、私たちの大学院生のグループは、一緒に暗闇の中を進む方法を感じていました。私たちはリーダーを任命することすらしませんでした。きっとどこかの時点で、北東部やワシントンD.C.の有名な教育機関の「本当の専門家」が責任者になるだろう。私たちは誰かの足元を踏みたくありませんでした。だから、技術メモを「標準」や「命令」と呼ぶつもりはありませんでした。「提案」という言葉でさえ、あまりにも強すぎるように思えました。私たちは、これらの文書を事前の承認や調整なしにやり取りしているアイデアとしか見ていませんでした。最終的に、SRIの若手プログラマであるビル・デュバルが提案した言葉『Request for Comments』に落ち着きました。これは、これらの文書が進行中のものであり、しばしば予備的な議論の一部であることを強調する者です。

3 RFCs to Know

#1: Host Software

1969年4月に発行され、当時UCLAの大学院生だったスティーブ・クロッカーによって書かれたRFC 1と、SRIのビル・デュバルによって書かれたRFC 2は、ARPANETのホスト・コンピュータとIMPを接続するために使用されるソフトウェアの様々な側面を説明しています。RFCプロセスの流動性は、最初から明らかです。「ここに書かれていることのほとんどは確定的なものではなく、反応が期待されます」とクロッカーは書いています。

#760: Internet Protocol

1980年1月に発行されたこのRFCは、インターネット・アーキテクチャの基本要素の1つであるインターネットプロトコルについて概説しています。今日まで、ほとんどのインターネット・データは、このRFCで規定されているように、あるネットワークから別のネットワークへIPv4パケットでルーティングされています。IPv4アドレスは40億台のホストに制限されているため、新しいIPv6プロトコルがインターネット標準として1995年に導入されました。

#1035: Domain Names

ポール・モカペトリスによって書かれ、1987年11月に発行されたこのRFCとRFC 1034は、spectrum.ieee.orgのような人間が読めるホスト名を99.86.33.6のようなネットワーク・アドレスにマッピングする方法を説明しています。モカペトリスのドメイン・ネーム・システム(DNS)は、無数のサーバにルックアップ・テーブルを分散させ、ネットワークをグローバルサイズに拡張することを可能にしています。

最初のRFCのバッチは、1969年4月に到着しました。間違いなく私たちの初期の最高のアイデアの1つであったものは、これらのRFCには明記されていませんでしたが、それらは暗黙のうちにしかありませんでした。それは、必要に応じてあるプロトコルを別のプロトコル上に構築できるように、またプログラマが自分のニーズに最適なプロトコル・スタックを利用できるソフトウェアを書くことができるように、プロトコルをレイヤで構造化するという合意でした。

私たちは、最下層の基礎から始めました。私がRFC 1を書き、デュバルはRFC 2を書きました。これらの最初の2つのメモを合わせて、ホスト間の基本的なストリーミング接続を説明しました。私たちは、このレイヤはシンプルに保ちました — 定義が簡単で、実装も簡単な者にしました。インタラクティブなターミナル接続(Telnetなど)、ファイル転送メカニズム(FTPなど)、そしてまだ定義されていない他のアプリケーション(電子メールなど)は、このレイヤの上に構築することができました。

とにかく、それが計画でした。予想以上に難しいことが分かりました。私たちは、接続を確立する方法、複数の接続を可能にするアドレスの割り当て方、フロー制御を処理する方法、伝送の共通単位として何を使用するか、リモートシステムへのユーザの割り込むを可能にするにはどうすればよいか、などに取り組みました。何度も何度も繰り返し、何ヶ月も行き来をして、ようやく詳細についてのコンセンサスを得ることができました。

最初のバッチのRFCのいくつかは、より管理的なもので、これらのメモに求めていた最低限の規則を示し、ソフトウェアのテスト・スケジュールを提示し、増え続けるメーリング・リストを追跡しました。

他の人たちは、壮大なビジョンを掲げていましたが、それにもかかわらず推進力を得ることができませんでした。私の考えでは、RFC 5がその中で最も野心的で興味深いものでした。この中で、当時SRIにいたジェフ・リュリフソンは、非常に強力なアイデアを紹介しました。それは、対話型セッションの最初に小さなアプリケーションをダウンロードして、セッションを仲介し、「小さな」アクションをローカルで処理することで高速化するというものでした。

非常に単純な例として、ダウンロードしたプログラムは、リモートホストに送信する前に、コンソールでコマンドを編集したり、自動補完したりすることができます。このアプリケーションは、Decode-Encode Language (DEL)と呼ばれる機械に依存しない言語で書かれています。これを動作させるためには、すべてのホストがDELインタープリタを実行できなければなりません。しかし、私たちは言語を十分にシンプルに保つことで実現可能であり、ユーザーの応答性を大幅に向上させることができると感じていました。

しかし、DELでの実験の小さなバーストを除いて、このアイデアは、何年も後に、MicrosoftがActiveXをリリースし、Sun MicrosystemsがJavaを作成した時まで採用されませんでした。今日では、この技術はすべてのオンライン・アプリの中心になっています。


1969年10月29日、スタンフォード研究所のビル・デュバル[写真]は、UCLAのインタフェース・メッセージ・プロセッサと、大学院生のマイク・ウィングフィールドが設計したIMPとホスト間の2番目のインタフェースを介して、チャーリー・クラインから送信されたARPANET最初のメッセージを受信しました。このタスクは22:30に忠実にログに記録されました: 「Talked to SRI Host to Host. (SRIホストからホストに伝達された)」

1969年の初めに私たちが回覧した一握りのRFCは、ネットワーク・プロトコルに関する私たちのアイデアを捕らえたものでしたが、私たちの仕事は実際に本格的に始まったのは、9月と10月で、最初のIMPがUCLAとSRIに到達した時でした。実験を始めるには、2台で十分でした。SRIのデュバルとUCLAのチャーリー・クライン(レナード・クラインロックのグループで働いていた)は、UCLAマシンのユーザがSRIのマシンにログオンできるようにするためのソフトウェアのいくつかを開発しました。1969年10月29日の夕方、チャーリーはその試みに失敗しました。SRIのソフトウェアの小さな不具合を素早く修正した後、その夜、接続が成功しました。このソフトウェアは、UCLAをSRIを接続するのには十分なものでしたが、最終的にARPANETに接続されるすべてのマシンに対応するには十分ではありませんでした。さらなる作業が必要でした。

1970年2月までに、私たちは、基本的なホスト間通信プロトコルが完成させ、その春に、アトランティック・シティで開催された合同コンピュータ会議で発表することができました。さらに数か月もしないうちに、プロトコルは十分に堅牢なものになり、私たちの注意を2つのアプリケーション層プロトコルであるTelnetとFTPにシフトさせることができました。

私たちの上司の一部が当初想定していたように、各コンピュータ上で実行するためのモノリシックなプログラムを書くのではなく、システムがオープンで拡張可能なままであり続けるように、プロトコルはお互いに構築すべきであるという原則に固執しました。TelnetとFTPをホスト間プロトコルを介して通信するように設計することで、基本システムから独立して更新できることが保証されました。

1971年10月までには、私たちはARPANETを実際に動作させる準備が整いました。MITに集まり、完全なシェイクダウン・テスト(私たちは、これを「ベイクオフ」と呼んでいました)を行い、各ホストが他のすべてのホストにログオンできることを確認しました。これは誇りに思う瞬間であり、ネットワーク・ワーキング・グループが自らに課したマイルストーンでもありました。

1971年3月までに、ARPANETは15ノードにまで成長しました。

それでも、まだやらなければならないことがたくさんあることは分かっていました。ネットワークは、15のサイトに23のホストを接続するまでに成長していました。1年後、ワシントンD.C.で開催された大規模なコミュニケーション会議で、ホテルの宴会場でARPANETが公にデモされました。来場者は、いくつかの端末のどれかに座って、アメリカ中のコンピュータにログオンすることができました。

年々、私たちのグループは、ARPANETとそのプロトコルに対する観察、提案された変更、拡張の可能性を含むRFCを作成し続けました。電子メールはそれらの初期の追加機能の1つでした。電子メールは、ファイル転送の特殊ケースとして始まりましたが、後に別のプロトコルに作り直されました(Simple Mail Transfer Protocol、SMTP、RFC 788、1981年に発行)。私たちと上司の両方を喜ばせたのが、電子メールはARPANETの主要な使用用途となり、最初の「キラーアプリ」となりました。

もちろん、電子メールは私たち自身の仕事にも影響を与えました。これにより、私たちのグループはRFCをより速く、より多くの共同研究者に配布できるようになったからです。好循環が始まりました。それぞれの新機能により、プログラマは他の新機能をより簡単に作ることができるようになりました。

プロトコルの開発も盛んになりました。TCPとIPプロトコルは、ホスト間プロトコルをとって代わり、大幅に強化され、インターネットの基礎を築きました。RFCプロセスは、ドメインネームシステム(DNS、RFC 1035、1987年に発行)、シンプル・ネットワーク管理プロトコル(SNMP、RFC 1157、1990年)、ハイパー・テキスト転送プロトコル(HTTP、RFC 1945、1996年)の採用につながりました。

やがて、開発プロセスは技術とともに発展し、国際的な通信や商業におけるインターネットの重要性が高まりに伴って進化していきました。1979年、当時DARPAのプログラム・マネージャーであったヴィント・サーフがInternet Configuration Control Board(インターネット構成管理委員会)を設立し、最終的にはインターネット・エンジニアリング・タスク・フォース(Internet Engineering Task Force)が誕生しました。このタスクフォースは、もともとネットワーク・ワーキング・グループで行われていた作業を継続しています。タスクフォースのメンバーは今でも、ネットワークが直面している問題、既存のプロトコルに必要となるかも知れない変更、価値のあるかも知れない新しいプロトコルについて議論しています。また、プロトコルの仕様を「Request for Comments」というラベルの付いたドキュメントとして公開しています。

そして、意思のある人々の連合の間でのコンセンサスによる継続的な改善の中心的なアイデアは、インターネット文化の中でまだ強く生きています。新しいプロトコルやプロトコルへの変更のアイデアは、現在、ワーキング・グループと呼ばれる特定のプロトコルのトピックに特化したメーリング・リストを介して循環しています。現在、これらのグループは約100あります。彼らは3か月に1度の会議で会う時に、主催者はまだ投票をとることはありません。参加者にアイデアに同意するかどうかハミングしてもらい、その場の感覚を掴むのです。正式な決定は、その後のメールでのやり取りの後に行われます。

プロトコル仕様のドラフト(草案)は、「インターネット・ドラフト」として流通しています。これは、RFCにつながる議論を目的としています。例えば、量子インターネット通信を可能にする新しいネットワーク・ソフトウェアについて最近始まった議論の一つは、RFCのようなインターネット・ドラフトに記録されています。

そして、皮肉なことに、このプロトコルやその他の新しいプロトコルの仕様は、正式な採用が承認されて公開された後でなければ、Request for Commentsに表示されません。その時点では、もはやコメントは実際にはもはや要求されません。

この記事は、2020年8月の印刷版に「コンセンサス・プロトコル」として掲載されています。

著者について

スティーブ・クロッカーは、ArpanetのRequest for Comments (RFC)プロセスのチーフ・アーキテクトであり、Internet Engineering Task Forceの前身であるネットワーク・ワーキング・グループの創設メンバーの1人です。長年にわたり、ICANNの理事を務め、2017年までは副会長を経て会長を務めました。