要約

  • RFC 1385 の EIP は IPv4 と同じ形の基本ヘッダーを保ち、拡張部を旧来ノードには未知の IP オプションとして見せる、新しいアドレス指定・経路制御方式だった。
  • 32ビットのホスト番号と可変長のネットワーク番号を分け、境界ルーター、DNS、暫定変換を軸に移行を段階化した。

RFC 1385 は1992年11月、EIP という方向を提案する「idea」文書として公開された。既に展開されたアーキテクチャでも、採用済みのインターネット標準でもなかった。

EIP で最も象徴的なのは、新しいホストが信用しないフィールドである。4ビットの Version は互換性だけのため IPv4 と同じ値を保ち、EIP 実装は確認しない。IHL も同じ理由で残った。新しいヘッダーが実際にどこまで続くかは、IPv4 の IHL ではなく、別の拡張長バイトが決めた。

先頭20バイトの形を守る一方、その意味は組み替えられた。送信元アドレスと宛先アドレスは、それぞれ32ビットの送信元ホスト番号と宛先ホスト番号になる。番号は世界全体ではなく各ネットワーク内で一意ならよい。ネットワーク番号は可変長の拡張部へ移り、そこには他の経路制御・アドレス情報も収められる。総ヘッダー長は拡張長に20を加えた値で、IPv4 の IHL が表せる60バイトを超え、最大276バイトまで許した。

提案された EIP 識別子は 0x8A に固定された。EIP 対応ホストは決まった位置から新プロトコルを見分ける。古い IPv4 ホストやルーターには、拡張部は知らない新オプションに見え、無視される想定だった。同じネットワーク内なら拡張そのものを省略できる。移行中、未変更のサブネットルーターはホスト番号を IPv4 アドレスのように扱い続けられた。

互換性の負担が消えたわけではない。境界へ集められた。境界ルーターは既存アドレスのネットワーク部分を新しい EIP ネットワーク番号へ対応付け、外向きの IPv4 データグラムに拡張を加える。RFC 1385 は、戻ってきた EIP パケットを旧ホスト向けに逆変換する必要はないとした。旧ホストが拡張を無視するからである。DNS にはネットワーク番号を格納する新しいレコードが必要だった。

移行順序は依存関係に沿っていた。まずアドレス体系を決め、ネットワーク番号を割り当てる。次にバックボーンと境界ルーター、DNS、変換機構を更新する。その後に重要なサーバー、さらに他のホストを移し、サブネットルーターは最後でよい。ただし変換は、再利用した32ビットのホスト番号が世界的にも一意である間しか機能しない。枯渇が進めば、その橋は使えなくなる。

文書は30か国35台のホストによる実験で、設定上は目に見える性能差がなかったと報告した。これは限定された試験であり、未知オプションがあらゆる経路を通る証明でも、EIP が展開された証拠でもない。1995年、RFC 1752 は128ビットの SIPP を IPng の基礎として勧告した。2012年、RFC 6814 は EIP オプションを正式に非推奨とし、IPv6 に取って代わられたと記して、RFC 1385 を Historic に変更した。

EIP が残したのは、互換性の賭けについての問いである。更新済みの機器には未来を読ませながら、過去の機器には安全に退屈なものとして通過させられるか。

出典