要約

  • RFC 1241 は変更前の IP データグラムを Clear Datagram と呼び、外側の IP ヘッダーと 8 オクテットの専用ヘッダーを付けて Encapsulation Space へ送った。
  • 32 ビットの Flow ID は装置ごとのローカル値であり、未規定の上位機構が経路表と前段への変換を保守する必要があった。
  • トンネル内部の ICMP が引用するのは外側ヘッダーと専用ヘッダーまでで、Clear Datagram は含まれない。障害通知から元の問いを正確に復元できなかった。

送信元に見せない経路は、別の管理面を必要とした

Robert Woodburn と David L. Mills が 1991 年 7 月に公表した RFC 1241 は、実験プロトコルである。文書は封入前の IP パケットを Clear Datagram、通常の通信空間を User Space と呼んだ。封入装置と解除装置が使うアドレスおよび経路は、別の Encapsulation Space に属した。

目的は、障害のある経路やゲートウェイ、避けたいドメインを迂回することだった。送信元に中間トポロジーを教えずに経路実験を行うこともできる。入口が外側ヘッダーを追加し、出口がそれを外すため、内側の送信元アドレスは変わらない。

利用者から経路を隠せても、経路を選ぶ知識までは消えない。どの Clear Header をどの経路へ送るか、次の解除装置はどこか、障害時にどこへ戻すかを入口側が保持する。RFC 1241 は Encapsulation Space 内の終端間経路を Flow、すなわち tunnel と定義した。

Flow ID は 32 ビットだが、全体で一意ではない。一つの封入装置または解除装置の中だけで通用する。同じ Flow が次の装置では別番号になり得るため、エラーを戻すには前の封入装置のアドレスと、前の装置が使う Flow ID が必要だった。復路は同じ番号をたどるのではなく、各段で番号を翻訳する。

さらに、RFC 1241 は表の作成・更新方法を定めなかった。上位層の主体が管理し、実験なら ASCII ファイルでもよいとした。したがって、ローカル表で ID が見つかったことは、その時点の登録を示すだけである。次の装置との整合、更新時刻、エラー復路の存続までは証明しない。

内側を変えなくても、外側の大きさは変わる

封入時には新しい IP ヘッダーと、バージョン、種別、理由コード、チェックサム、Flow ID を持つ 8 オクテットのヘッダーが加わる。その後ろの Clear Datagram は変更されない。しかし、ネットワークが運ぶ単位は確実に大きくなった。

外側の送信元と宛先は封入装置と解除装置になる。優先度と QoS はコピーし得るが、timestamp、record route、source route はコピーしない。内側 TTL は外側へ写さない一方、封入前には減算する。Flow ID で通常の IP 転送を省略した解除装置も、次の封入前に TTL 処理を担わなければならない。

追加ヘッダーは MTU の余白を消費する。送信元のインターフェースでは収まったパケットが、封入後には収まらない場合がある。外側 IP のフラグメント化は可能だが、文書は非効率だと認識していた。外側の分割を許さないなら、トンネルの実効 MTU は物理 MTU より小さくなり、その事実を内側の送信元へ伝える必要がある。

分割済みパケットは選別規則も崩す。表は TCP ポートや接続を使って Flow を選べた。ところが TCP ヘッダーを含むのは最初の IP フラグメントだけで、後続片にはない。ポートで判定する規則は最初の片だけに一致し、残りには一致しない。これは特定障害の記録ではなく、完全なヘッダーを前提にした規則の限界である。

前年の RFC 1191 は DF と「fragmentation needed」ICMP を使う Path MTU Discovery を定めていた。封入空間で見える送信元は封入装置なので、外側の ICMP は封入装置へ戻る。その情報を内側送信元の判断材料に変える仕事は、トンネルの責任として残った。

ICMP の 64 ビットはラッパーだけで終わった

RFC 792 のエラー形式は、問題の IP ヘッダーと、その後ろの少なくとも 64 ビットを引用する。RFC 1241 では、その 64 ビットが専用ヘッダーの 8 オクテットと完全に一致した。引用は Clear Datagram の直前で終わる。

戻ってきた情報から外側宛先と Flow は分かる。しかし、内側 IP の送信元や TCP ポートは分からない。複数の Clear Header が同じ Flow へ対応し得るため、Flow ID を逆引きして元ヘッダーを正確に再現することもできない。エラーは外側経路の状態を表しても、どの内側パケットが原因かを一意には表さなかった。

未知の Flow ID は前段装置と表管理主体へ通知できた。一般の ICMP は Flow を逆向きに運び、各装置が前段用の ID に変換できた。それでも引用にないバイトは戻らない。エラー送信中のエラーには、さらにエラーを生成しないという終端もあった。

文書が検討した妥協策は、Flow に印を付け、次に一致する Clear Datagram が来た時に、その送信元へ新しい ICMP を発生させることだった。次のパケットが以前の状態を伝える契機になる。これは障害パケットそのものの受領証ではなく、一対一の対応でもない。安全と見なせる種類も限られていた。

後年の仕様は同じ境界を別の状態で補った

後年の文書が RFC 1241 の普及を証明するわけではない。RFC 1853 は、専用の中間ヘッダーを置かない IP-in-IP と RFC 1241 を区別し、その構成と一部文章から影響を受けたと明記した。この範囲なら文書上の関係を確認できる。

RFC 2003 も、ICMP の 8 オクテットでは内側 IP ヘッダーを含められないと記した。そこで MTU、TTL、到達性の soft state をトンネルごとに保持し、後続パケットへの判断に使う。より正確な通知は可能になるが、外側エラーが内側パケットの一件ごとの証拠になるわけではない。

RFC 4459 は後に、ネットワーク内トンネルのパケットサイズを一般的で容易ではない問題と整理した。外側を分割する、送信元へ小さい MTU を知らせる、余裕を確保する、内側を分割するという選択肢は、それぞれ別の主体に状態と費用を持たせる。

RFC 1241 から確実に言えるのは、提案された形式、ID のローカル性、逆向き翻訳、ICMP 引用から内側が消えることまでである。どの製品が動かしたか、内側パケットが届いたか、元送信者が同等のエラーを得たかは別の証拠を要する。入口の Clear Header、表の世代、外側ヘッダー、出口の解除記録、ICMP の実バイトを結んで初めて結果を論じられる。

参照資料