要約

  • RFC 814は、人が使う名前をアドレスへ、アドレスを経路へ、サービス名をトランスポート固有のポートへ変換する連鎖を示した。各段階は別の問いに答える。
  • インターネットの成長により完全な静的表は維持できない。分散名前サービス、実際の利用に比例するキャッシュ、後から実装を差し替えられる問い合わせ境界が必要になった。
  • 分離は証拠の意味も狭くした。名前解決は到達性を、経路はサービスを、登録ポートは通信の正当性を証明しない。DNSも後に、名前へネットワーク座標を埋め込まない原則を採った。

古い表は正しく配送してしまった

RFC 814が描いた事故では、壊れたパケットも誤った構文も登場しない。ホストが移転したのにNICの表の更新が届かず、古いアドレスに別の機械が存在する。端末の前に人がいれば違和感に気づくかもしれない。キューに積まれたメールは、人の確認なしに進む。

ここでアドレスへの配送成功を、名前で指定した相手への配送成功と同一視できない。David D. Clarkはその違いを、ホスト内部の複数の変換として整理した。文字列の名前はネットワーク、ホスト、サービスを指す。ホスト名は32ビットのインターネットアドレスに変わる。アドレスは接続位置を表し、そこから経路が選ばれる。サービス名はTCPやUDPのポートに変わる。

ひとつの「宛先」という表示は、この連鎖を隠す。名前が正しくてもキャッシュが古い場合がある。アドレスが正しくても経路がない場合がある。ホストに届いても想定したサービスが存在しない場合がある。

全員が世界全体を持つ必要はない

当時のインターネットは約25の稼働ネットワークと数百ホストだった。それでもRFC 814は、1,000ネットワーク、2万5,000ホストほどの世界を念頭に現在の実装を作るよう求めた。

完全な表は、容量だけでなく更新頻度と無関係なデータの量によって破綻する。あるホストが一生通信しないネットワークの名前まで、常に最新にする合理性はない。そこで、各ネットワーク側が名前を保守し、名前サーバーが問い合わせに応じ、ホストは最近使った対応だけを保持する分散方式が想定された。

実装上の提案も重要だった。表を直接読むコードを各所に置かず、サブルーチンを介して問い合わせる。遠隔名前サーバーが使えるようになれば、その内部だけを交換できる。アプリケーションは「この名前の現在のアドレスは何か」という問いを保ち、答えを得る仕組みには依存しない。

これは将来の決定を局所化する設計である。共通層は小さな問い合わせ境界を決める。新しい実装はその背後で動き、既存の実行コードを一度に書き換えなくてよい。

キャッシュには期限と出所が要る

分散化は古さを消さない。むしろローカルキャッシュは、元の対応が変わった後も過去の答えを保持する。RFC 814は、遠隔アドレスに関連する名前を照会する案に触れた。これは暗号学的認証ではなく、保存済みの対応を永続的な真実と扱えないという認識だった。

RFC 1034のDNSは、名前に型付きの資源情報を関連付け、ゾーンごとに責任を分散し、TTLで複製の寿命を扱った。設計目標はさらに明瞭で、名前の中へネットワーク識別子、アドレス、経路を必須要素として入れるべきではないとした。

アドレスは名前について取得するデータになった。名前を変えずにアドレスを差し替えられる。ただし、その名前が同じ主体に管理され続けること、回答が真正であること、現在到達できることまでは保証しない。分離は継続性の余地を作るが、名前を身分証明書にはしない。

アドレスから経路へは別の判断だった

IPは宛先ネットワークが直結かを調べ、違えばゲートウェイを選ぶ。初期の256項目の静的表は、ネットワーク番号が増え、ゲートウェイが移動または故障すると維持できない。

RFC 814は利用中の宛先についてだけ経路をキャッシュする方法を示した。項目がなければ到達可能なゲートウェイを試し、より良い次ホップがあればICMP Redirectで学習して表を直す。経路は現在のトポロジーに応じて変わる運用状態であり、名前の属性ではない。

最初のゲートウェイをどう知るかは、共通アーキテクチャの外に残された。ブロードキャストできる網、専用機構を持つ網、手動設定が必要な網があったからだ。ひとつの局所手段を全網に強制しなかった。

RFC 1122は後に、複雑な経路制御をゲートウェイへ寄せ、ホストソフトウェアを経路体系の変化から隔離する目標を示した。経路キャッシュはMTUや遅延といったパス特性も持ち得る。それらは観測期間に属し、名前に永久付与されるものではない。

サービス選択をIPへ押し込まなかった

IPアドレスが指定するのはホストまでである。到着後、IPは上位プロトコルへ渡し、TCPやUDPがポートでプロセスを選ぶ。RFC 814は、当時のTCPとUDPでポート欄の位置が同じでも、将来の全プロトコルをその形式へ固定しなかった。

ポートをIPに置けば、ゲートウェイがアプリケーションの分派を理解すべきだという誤解を招く。異なる上位プロトコルが別の識別子サイズや規則を選ぶ余地も失われる。

文字列のサービス記述を会合サーバーへ送り、その都度ポートを割り当てる案も検討された。接続設定には適するが、単一UDPデータグラムには余分な往復と中継を課す。RFC 814は会合を禁止せず、必要とする上位プロトコルだけが選べるようにした。

現在のIANA登録簿も、サービス名、トランスポート、ポートを結び付ける一方、割り当ては製品の承認ではなく、そのポートの通信が登録サービスである保証もないと明記する。

32ビットは事前接続のない配送の代価だった

仮想回線なら、設定時に長い完全アドレスを一度送り、その後は短い回線識別子を使える。インターネットデータグラムは事前設定なしで単独に経路選択できなければならず、アドレスを各パケットに入れる必要があった。RFC 814は32ビットを、表現力とヘッダー費用の妥協と説明した。

これはCIDR、NAT、IPv6や現在の市場を予言した記述ではない。アドレスが配送のための有限な座標だったことを示す。人が保持する名前まで同じ座標にすれば、位置の変更がそのまま識別の破壊になる。

証拠は段階ごとに残す

運用記録では、問い合わせた名前と回答元・TTL、返った各アドレス、選択したインターフェース・次ホップ・経路版、トランスポートとポート、最後にアプリケーションの認証・認可・完了を分けるべきだ。

そうすれば、「解決したが経路がない」「到達したが別サービスだった」「ポートは開いたが認証に失敗した」「認証したが処理は完了しなかった」を区別できる。最終的な緑色の状態だけでは、どの対応関係が正しかったのかを後から復元できない。

RFC 814の価値は、名前、アドレス、経路、ポートのどれにも全体を代表させなかった点にある。それぞれは交換可能な対応であり、観測範囲内だけを証明する。この狭さが、経路や実装の変化を受け入れる余地になった。

出典