要約

  • 2001 年に登場した 6to4 は、グローバルに一意な IPv4 アドレスから 2002::/16 配下の IPv6 プレフィックスを作り、個々のトンネルを事前調整せずに IPv4 網を越えられるようにした。
  • anycast はリレー選択を自動に見せたが、往路と復路が別々の、互いに責任を負わない運用者に依存することもあった。フィルタ、誤った経路、初期設定での有効化が、便利さを繰り返す障害へ変えた。
  • RFC 7526 が 2015 年に廃止したのは anycast リレーの仕組みである。基本的な unicast 6to4 と 2002::/16 は廃止されておらず、現在のレジストリを読むうえでも重要な境界だ。

合意より先にできたアドレス

6to4 で最も印象に残るのは、一つの計算である。グローバルに一意な IPv4 アドレスの 32 ビットを 2002 の後ろに置けば、サイトは /48 を得る。RFC 3056 の表記では 2002:V4ADDR::/48 となる。ネイティブ IPv6 サービスのないネットワークでも、そのプレフィックスから内部アドレスを配れる。境界の 6to4 ルーターは、IPv4 のプロトコル番号 41 を使い、IPv6 パケットを直接 IPv4 に包んだ。

2001 年 2 月に公開された RFC 3056 は、これを恒久的な IPv6 アーキテクチャではなく、任意の暫定メカニズムと位置づけた。狙いは具体的だった。相手ごとに設定済みトンネルを用意せず、この用途のために通常の IPv6 プレフィックスを先に取得しなくても、既存の IPv4 インターネット上でサイト同士をつなげる。IPv4 アドレスが素材と場所の手掛かりを兼ねた。

ただし、便利さには最初から条件があった。プライベート IPv4 アドレスからは世界で通用する 6to4 プレフィックスを作れない。IPv4 アドレスが変われば、派生した IPv6 プレフィックスも変わる。そして 6to4 の世界とネイティブ IPv6 の世界の間では、依然として誰かがパケットを運ばなければならない。自動化されたのはアドレス生成であって、普遍的な到達性ではなかった。

見えなくなったリレー

二つの 6to4 サイト間なら、プレフィックスに埋め込まれた IPv4 アドレスがトンネルの行き先を示す。ところが 6to4 サイトとネイティブ IPv6 の宛先の間には、両方の世界を理解するリレーが必要だった。

RFC 3068 は非常に単純な答えを出した。リレールーターに共通の IPv4 anycast アドレス 192.88.99.1 を持たせる。6to4 ルーターがそこへ送れば、通常の IPv4 ルーティングが、その経路を広告する近隣のリレーを選ぶ。利用者は特定のゲートウェイを探したり設定したりしなくてよい。運用上の取り決めを要した移行機構が、スイッチのように見えるようになった。

だが、そのスイッチは非対称性を隠していた。送信時に選ばれたリレーが、返信にも使われるとは限らない。ネイティブ IPv6 網から 2002::/16 へ戻るパケットは、別の事業者が別の経路方針で運用するリレーを選び得る。二つのリレーは互いの存在すら知らなくてよい。通信の成功は複数組織の互換性あるサービスに依存したが、仕組みはその間に契約も、往復全体の単一責任者も作らなかった。

問題はアドレス形式を見ても分からない。仕様どおりの正しい 6to4 アドレスでも、プロトコル 41 を捨てるファイアウォール、消えたリレー経路、配置の悪いリレー、ブラックホールへ向かう復路に遭遇する。プレフィックスが正しくても、利用体験は失敗し得た。

フォールバックが隠した請求書

2004 年の RFC 3964 は安全性に焦点を当てた。リレーは、トンネルの IPv4 送信元と、6to4 送信元に埋め込まれた IPv4 が一致するかを考慮しなければならない。フィルタがなければ、偽装トラフィックが反射され、移行システムを通じて出所を洗われ、追跡しにくくなる。すべてのリレーが悪意を持つという主張ではない。自動カプセル化が、アドレスだけでは管理できない信頼境界を越えるという指摘だった。

2011 年の RFC 6343 は、より広い運用記録をまとめた。プロトコル 41 を遮断するフィルタ、存在しないか到達できないリレー、片方向だけ動く経路である。同文書は当時の複数実験を引用し、6to4 の接続失敗率がおおむね 9～20％だったとした。世界全体や全期間の統計ではない。それでも移行支援を目に見える信頼性問題へ変えるには十分大きかった。

費用は消えたのではなく、しばしば見えなくなった。デュアルスタックのアプリケーションが IPv6 を試し、6to4 の失敗を待ち、最後に IPv4 へ戻れば、利用者には単にページが遅く見える。ソフトウェア側には、動くネイティブ経路を優先し、Happy Eyeballs のように候補を競争させる動機が生まれた。各層は自分に見える症状を軽減できても、リレー全体の責任者不在は変わらなかった。

初期設定での有効化が問題を長引かせた。6to4 を頼んだ覚えのない利用者にも、OS や境界機器が派生アドレスと見かけ上の IPv6 経路を与えた。RFC 6343 はこれを悪い慣行とし、初期状態では無効にするよう勧告した。調整の少なさが魅力だった機能が、今度は事情を理解した利用者の明示的判断を必要としたのである。

近道を廃止しても、過去は消さない

2015 年 5 月、RFC 7526 は撤退を正式なものにした。anycast 6to4 を廃止し、RFC 3068 と関連する RFC 6732 を Historic に移し、anycast 経路広告と 192.88.99.1 のリレーサービス停止を求めた。実装は 6to4 を初期状態で無効にすべきとされた。公共の近道は、もはや推奨される移行基盤ではなかった。

この決定の範囲は誤解されやすい。RFC 7526 は、RFC 3056 の基本的な unicast 方式も、2002::/16 プレフィックスも廃止していないと明記した。IANA の現行 IPv6 特別用途アドレスレジストリも、このブロックを 6to4 として掲載している。登録はアーキテクチャ上の割り当てを示すだけで、公共リレー経路の存在や推奨を保証しない。

だから、この歴史は削除で終わらない。標準化の過程は運用上の推奨を撤回しながら、古いアドレス、管理された構成、残存システムを識別する語彙を残せる。現在 2002::/16 を見たなら、仕組みが使われた証拠とは読めるが、anycast サービスが見直し後も生き残った証拠とは読めない。