要約

  • 入口境界は DNS から自治ドメインのアドレスを得て外側 IP ヘッダーを付け、出口境界はそれを外す。中を走る元のデータグラムと IPv4 アドレスは変更しない構想だった。
  • ホストを変えない代わりに、DNS の新規対応、ドメイン用アドレスの割り当て、境界での検索・封入・取り外し、ドメイン経路、通過パケットごとの 20 バイトが必要になった。
  • RFC 1955 は情報提供文書であり、公開は IPng による受容を意味しないと明記する。内側 IPv4 の世界的な一意性を前提とし、安全性は論じていない。

境界の間だけ、別の宛先を持つ

送信ホストが作るものは通常の IPv4 データグラムである。最初の境界に着くと、ルーターは内側の送信元と宛先を手掛かりに、別の自治ドメイン・アドレスを調べる。その対を新しい IP ヘッダーへ置き、古いデータグラム全体を内側へ収める。

中継網は外側の宛先を追う。最後の境界で外側だけが外され、元の宛先に従う転送が再開する。ホストは途中の包装を知らず、中間の多くのルーターも特別な意味を知らないまま外側 IP を処理できる。

この案が掲げたのは、パケット内アドレスを翻訳しないことだった。内側を書き換えなければ、翻訳に伴うチェックサム修正やアプリケーション内アドレスの探索を避けられる。しかし、バイト列を保つことと状態を持たないことは同じではない。ドメイン対応、外側の経路、正しい出口、取り外しの判断が新たに必要になる。

文書の発行は 1996 年 6 月だが、構想は 1992 年 1 月に ROAD グループへ送られ、当初は電子メールだったと本文が説明する。後に IPng の白書募集へ提出された。しかも RFC 自身が、公開は IPng 領域による採用を意味しないと釘を刺した。

ここに残っているのは勝者の仕様ではない。時間切れを恐れた時代が、何を変えずに何を境界へ移そうとしたかという記録である。

長期解が間に合わないという設計条件

当時の問題は一枚岩ではなかった。Class B の割り当ては先に苦しくなり、ルーティング表の増大は機械と運用者の双方を圧迫した。32 ビット空間全体の限界は、さらに先の根本問題だった。

ROAD の整理では、直ちに行う作業、短期、中期、長期を順番待ちにしてはいけなかった。すべてを始める必要があり、近い危機への対処でホスト変更は選べなかった。大きな既設基盤の移行が、設計そのものより遅いからである。

ENCAPS はそこで恒久解を装わなかった。将来の帯域保証や遅延保証をすべて扱えず、初期形には規模上の限界があると認めたうえで、長期案を選び実装するまでの時間を買おうとした。

目標は大胆だった。ホストを変えない。大半のルーターも変えない。新しいインターネット・プロトコルもルーティング・プロトコルも設計しない。現在のアドレス構造を使い、表を小さくする。

ただし、これは評価結果ではない。凍結した資料には展開台数、相互接続試験、実測性能、パケット観測がない。提案の箇条書きは、実装が検証すべき仮説である。

DNS が外側の地理を与える

入口境界は名前から AD アドレスを得る想定だった。内側の送信元・宛先に対応する外側の送信元・宛先を作り、ドメイン間ではその値を使って経路を選ぶ。

RFC 1955 は、少数の Class A と Class B の番号を AD 用に確保する案を示した。ネットワーク部が AD 識別子であることを示し、ローカル部が具体的なドメインを選ぶ。複数の番号空間は、本文が「commonwealths」と呼んだまとまりを作り、内部の詳細だけを各まとまりが知る形を可能にする。

境界ルーターは AD アドレスを通過ドメイン内のルーティングへ注入する。中間装置は特別なソフトウェアを持たず、普通の IP 宛先として扱える。境界同士の経路計算には BGP、IS-IS、OSPF も使えるとされた。

ここでの互換性は、全員が新しい意味を理解することではない。新しい意味を、既存機器が実行できる古い形へ投影することだった。

そのためには DNS と経路の二つが一致しなければならない。正しい対応表があっても出口へ届かなければ失敗する。外側が到達しても対応が古ければ、別の境界へ運ぶだけである。さらに外側の到着は、内側の到着を証明しない。

翻訳を避けても、制御は残る

同時代の NAT は別の支払い方を示す。アドレスを書き換えると IP や TCP のチェックサムを直し、ペイロード内のアドレスを知る必要がある。複数出口では対応表の同期が問題となり、暗号化された内側は翻訳できない場合がある。

ENCAPS は元のパケットをそのまま運ぶので、これらの改変を避ける。しかし入口の検索、AD 番号の割り当て、外側経路、出口の識別は消えない。内側が正確に保存されていても、外側で迷えば通信は成立しない。

また、この案は内側 IPv4 が長く世界的に一意であり続けると仮定した。将来は AD アドレスと内側 IP の組で一意性を作る可能性にも触れる。だがホストを変えずにそれを行えば境界 NAT が必要になり、NAT を避ければホスト自身が検索と封入を担う。

つまり、内側の一意性、ホスト無変更、境界無翻訳をすべて永続させることはできない。RFC は問題を消したのではなく、次の選択がどの約束を破るかを見える形にした。

20 バイトより重いもの

明示された料金は外側 IP ヘッダーの 20 バイトと、入口・出口での処理である。パケット上の増分は測りやすい。

運用上の料金は表の外に広がる。名前ごとに AD レコードを追加し、ドメイン番号を配り、まとまりを設計し、境界で検索・封入・経路計算・解封入を行う。障害時には外側の経路と内側の宛先を別々に調べる必要がある。

キャッシュ寿命、否定応答、対応情報の認証、片側だけ更新された場合、経路 MTU、断片化、ICMP の帰属、撤退条件について、文書は詳細を与えない。安全性は論じないと明記する。図が単純であることは、運用が単純である証拠ではない。

後の IP-in-IP 仕様は外側ヘッダーの振る舞いをより詳しく定め、IPv6 は IPng の公式な成果となった。それらは問いを比較する資料であり、ENCAPS からの直系を証明する資料ではない。

CIDR は別の場所を変えた

CIDR も長期案までの時間を確保しようとしたが、経路集約を既存アドレスの割り当てとプレフィックス表現へ置いた。代価は割り当て方針、マスクを扱うルーティング、プロバイダーへの接続構造、再番号付けの圧力に現れた。

ENCAPS は既存アドレスを再編成する代わりに、その外へドメイン宛先を足した。古い目的地が、新しい目的地に乗って移動する。

同じ「表を小さくする」でも支払う主体は異なる。集約という言葉だけでは、利用者が再番号付けするのか、DNS が対応を持つのか、境界が全パケットを包むのかが見えない。設計判断は、その支払先を記述して初めて比較できる。

提案を運用実績へ変換しない

稼働コード優先の見方では、証拠は段階を踏む。RFC は構想の存在を示す。DNS レコードは設定された対応を示す。境界設定は準備を示す。外側ヘッダーの観測は一地点で封入したことを示す。その先の正しい出口、解封入、内側転送、アプリケーション受領は別の証拠である。

最小初期仕様の観点では、変更を境界へ限定することに意味がある。参加しないホストへ強制しないからだ。しかし共通の対応サービスが参加資格を決め始めれば、局所的な判断は失われる。拒否、通常経路、撤回が動作してこそ、移行層は補助に留まる。

現実の層も分ける必要がある。文書の AD 番号、DNS の記録、キャッシュの信念、パケットの外側、出口の動作、アプリケーションの結果は同じものではない。先の層を後の層の領収書として使わないことが、歴史を誇張から守る。

RFC 1955 が残す問いは現在にも通じる。変更しなかった装置を数え終えた後、どこへ移した状態を数えたのか。

出典と境界

文書の身元と位置づけは RFC 1955 の RFC Editor 記録 に、具体的な案は RFC 1955 による。ROAD の状況は RFC 1380、IPng 白書手続は RFC 1550 で区切る。別の短期策 CIDR は RFC 1519、変換との比較は RFC 1631 を参照した。直系を主張せず、後の結果として最初の IPv6 仕様 と IP within IP を比較する。分析枠は Running-Code Primacy、Minimum Initial Specification、Reality Layers に基づく。

資料が示すのは提案と限定的な比較である。IPng の採用、標準化、実装、展開、普及率、性能、相互運用、安全性、特定事業者、実パケット、現在製品、後続技術への因果系列は示さない。