要約

  • RFC 1118は、Ethernet上で数台のIPホストを動かせるが、インターネットには未接続のサイトを想定していた。
  • アドレス取得、障害時の連絡先、情報サービスを案内しつつ、規格でもチュートリアルでもないと明記した。

新しいネットワークの接続で問題になるのは、技術だけではない。キャンパスにIPホストが動いていても、固有のネットワーク番号がない、上流の連絡先が分からない、あるいは自分たちの判断が他のネットワークにどう影響するか見通せないことがある。1989年9月のRFC 1118は、その隙間に向けた文書だった。対象はすでに動作する小さな孤立ネットワークで、接続によって双方を危険にさらさないことを目指した。

この前提が文書の形を決めている。新しいプロトコルを定義するのではなく、書き残されにくい情報、参考文献、ヒントを集めた。インターネットの運営方針の把握、オンライン情報の探し方、良きネットワーク隣人としての振る舞いを案内する。焦点はパケット形式ではなく、ローカル運用から相互接続環境への移行にある。

運用の窓口は分散していた。ARPANET、NSFNET、地域ネットワークにはそれぞれ運用センターがあった。地域ネットワークにつながるキャンパスで問題が起きた場合、窓口担当者は直接接続している事業者へ連絡する。地域網がゲートウェイを介してNSFNETやARPANETに到達していても、最初のエスカレーション先は直接の運用関係に沿う。新しいサイトを、著名なバックボーンのサポート窓口へいきなり送る構図ではない。

アドレス取得も接続手順の一部だった。RFC 1118は、固有のIPネットワーク番号をSRI-NICに申請する流れを説明し、当時のクラス別アドレスやネットワーク数増加によるゲートウェイ表の負担に触れている。RFC 950はサブネット化の正式な手順を示し、RFC 1009はゲートウェイ要件を定めた。RFC 1118はそれらをキャンパス管理者の判断に結びつける。クラスA/B/CやNICの連絡先は1989年の記録であり、現在の接続手順として使うものではない。

安全性は相互の責任として描かれている。ネットワーク設計時には約50網を想定していたが、当時は約1,000網に近づき、ゲートウェイ容量や混雑が課題となっていた。多くのゲートウェイが経路情報を信頼して受け入れ、悪意あるゲートウェイは大きな障害を起こし得ると警告した。これは実際の攻撃が起きた証明ではない。新規接続が一台の到達性を超える責任を伴う理由を示す。経路の広告はキャンパス外の通信にも影響する。

情報サービスも運用地図の一部だ。SRI-NICに加えて、BBNがCSNETとNSFNET向けに、MeritがNSFNET向けに提供する情報サービスを区別している。Telnet、FTP、メール、メーリングリスト、運用者への連絡は、それぞれ異なる情報経路だった。すべての質問を受け付ける単一窓口はなく、新規参加者には問い合わせ先を見分ける知識が要った。

文書は自らの限界を隠さない。RFC 1118は規格を定めないと述べ、編集のむらを認め、誤りについて冗談を交えた。インターネットが動的だから定期的に改訂するとしたが、これは保守の意図であり、改訂が常に行われた証拠でも、利用者が従った証拠でもない。翌月のRFC 1123はホストのアプリケーションとサポートプロトコル要件を、より規範的な文書として示した。RFC 1118をプロトコルに変えたわけでも、その運用案内を置き換えたわけでもない。

RFC 1118が残したのは、仕様書だけでは見えにくい層の歴史だ。インターネットに加わるには運用者を見つけ、番号を得て、最新情報を探し、隣接ネットワークの期待を理解する必要があった。誤り得ると認めたことは、知識の価値を下げるのではなく、寿命を問題にした。変化するネットワークの手引きは、日付を確かめて検証する地図であり、安全な経路や接続成功の証明ではなかった。

出典