要約

  • RFC 2185 は、IPv6-over-IPv4 トンネルが上位層で一つのリンクに見えても、IPv4 と IPv6 の到達性を別々に計算するものとして扱った。
  • 自動トンネリングでは、IPv6 経路が正しいカプセル化ルーターを選び、そこから IPv4 経路が外側パケットを運ぶ必要があった。経路リークはその引き継ぎを決める操作だった。
  • 優先エンドポイント、バックアップの集約経路、デカプセル化成功、片方向受信はいずれも限定的な証拠であり、往復対称性やアプリ配送、移行完了を証明しない。

パケットは、プロトコルを切り替える場所を先に見つける

初期の IPv6 トンネルで難しかったのは、ヘッダーを追加する処理だけではない。その処理をどのノードが行うかを経路として決めることだった。

1997 年9月の RFC 2185 は、IPv4 と IPv6 の基盤が長期間共存する状況を描いた。IPv4 パケットは IPv4 のルーティングプロトコルで学習した経路を使い、IPv6 パケットは当時の IPv4-compatible IPv6 アドレスを含めて IPv6 の経路を使う。一つの統合プロセスが両方を運べるようになっても、計算の二層性は消えないとした。

したがって、トンネルは二つの約束から成る。カプセル化前には、IPv6 経路が実行可能で正当なカプセル化点へパケットを置く。その後は IPv4 経路が外側の宛先へ運ぶ。片方の経路表に正常表示があっても、もう片方の約束を代行できない。

RFC Editor の記録と IETF Datatracker は、この文書を Informational と分類する。標準化、普及、実測性能、移行完了の証拠ではない。

一つの仮想リンクが、下側のネットワークを隠す

手動設定の静的トンネルは、IPv6 の見え方を単純にした。両端は通常のポイント・ツー・ポイントリンクとして隣接を形成し、経路情報を交換する。IPv6 から見れば相手は1ホップである。

しかし外側パケットは、現在の IPv4 ルーティングが選ぶ複数ホップを通る。仮想隣接が示すのは両端が隣接として振る舞う合意であり、中間ルーター、容量、フィルター、MTU、戻り経路まで同一という事実ではない。

当時の RFC 1933 は、トンネル MTU、フラグメント、IPv4 Path MTU、ICMP エラーの反映という隠れた責任を示した。RFC 2003 は一般的な IP-in-IP を規定し、出口がデカプセル化可能だと事前に知る必要を述べた。これらは包み方を説明する。RFC 2185 の焦点は、包む場所へどの経路が導き、その場所を誰が選ぶかだった。

経路リークはカプセル化点を任命した

ホスト間の自動トンネルでは、双方が IPv4-compatible IPv6 アドレスを持つ場合、送信元はそこから外側の IPv4 送信元と宛先を抽出し、最初から IPv4 で運べた。

設定済みデフォルトトンネルでは、ローカルに適切な IPv6 ルーターを持たないホストが、IPv6 バックボーンへ接続するデュアルルーターの IPv4 アドレスを設定される。その値は単なる位置ではない。どこで外側ヘッダーを外し、責任を IPv6 へ戻すかを選んでいた。

ルーターからホストへの自動トンネルでは、境界がさらに明確になる。カプセル化ルーターは、到達できる IPv4-compatible IPv6 宛先を IPv6 領域へ注入する。IPv6 はリークされた経路をたどって広告元へ到達し、そこで初めて IPv4 に包まれ、通常の IPv4 経路へ渡される。

RFC 2185 は route leaking を、ルーティング領域の境界を越えたネットワーク層到達性の広告と定義した。この広告は「この IPv6 宛先を私へ送れば、IPv4 で次の区間を完了できる」という約束であり、中立的なコピーではない。広告元をカプセル化点に選び、責任範囲を増やす。

規模の選択にも代償があった。小さな IPv4 stub なら集約プレフィックス一つで済むかもしれない。大規模 IPv4-only バックボーンとデュアルバックボーンの境界では、IPv4 全表を IPv6 へ入れて表をほぼ倍増させるか、IPv6 対応ノードがいると判断した宛先だけを人手で選ぶ。前者は状態を、後者は継続的な判断を消費する。

バックアップは「同じサービス」を意味しない

設定済みデフォルトの例では、各デュアルルーターが固有エンドポイントのホスト経路と、共通ブロックのカバー経路を広告できる。優先ルーターが生きている間は具体的な経路が勝ち、消えれば別の稼働中ルーターへ集約経路で届けられる。

ただし、それが証明するのは別の広告元が外側パケットを受け取れたことまでである。同じポリシー、トンネル状態、容量、フィルター、Path MTU、後続 IPv6 経路を持つとは限らない。逆方向が同じ出口を選ぶとも限らない。

RFC は、通信には双方向が必要であっても、アドレス形式、接続、方針によって方向ごとに異なるトンネル方式を使えると明記した。往路がホスト間トンネルでも、復路はネイティブ IPv6 とルーター・ホスト間トンネルの組合せかもしれない。往路成功は復路図ではない。

セキュリティ節が示した範囲も狭い。トンネリングは下位ルーティング基盤のファイアウォールに違反し得る。それ以外の問題は論じていない。デカプセル化成功は認証や方針適合を自動的に与えない。

残ったのは、段階ごとの証拠の読み方である

経路エントリは制御プロセスが到達性を選んだことを示す。リークされたプレフィックスは一方の領域が他方へ主張を広告したことを示す。設定済みエンドポイントはローカルな選択、隣接は仮想リンク上の制御交換、デカプセル化は一つの外側パケットが動作中の出口へ届いたことを示す。

どれも単独では、広告権限、ループのない引き継ぎ、ポリシー整合、対称な復路、持続容量、アプリ配送、移行完了を証明しない。

隣接文書の境界も分ける必要がある。RFC 1955 の ENCAPS は AD ヘッダー、DNS 対応、境界ルーターへ中期の抽象を移した。RFC 2003 は一般的な外側エンベロープを扱う。後の RFC 4213 も、IPv6 から1ホップに見えるトンネルの外側で独立した IPv4 TTL が動くことを示す。RFC 2185 が所有するのは、二層を正しい場所で接続する経路責任である。

Lu Heng の Running-Code Primacy は、文書や広告と、実行され局所検証できる運用事実を分ける分析視点になる。Minimum Initial Specification は共通不変条件を狭く保ち、後の採用と方針を運用者へ残す。彼のデュアルスタック費用論は二つの経路・監視・障害面を経済的に読むが、RFC 2185 の導入証拠ではない。Reality Layers の区別は、設定・広告と、実際の経路・サービス結果を同一視しないために使える。

RFC 2185 は移行成功を証明しなかった。代わりに、約束の受け渡し地点を示した。IPv6 経路は正しいカプセル化点を、IPv4 経路は外側の出口を約束する。両方が守られたかを言えるのは、端から端までの観測だけである。