概況

  • 2001年に Brian Carpenter と Keith Moore が共著した RFC 3056は、6to4 をオプションの暫定的な橋渡しとして定義し、ネイティブ IPv6 が利用可能になった時点でそちらに移行するよう明示的に指示していた。したがって、そのライフサイクルの問題は、有効期限ラベルの欠如ではなく、展開が容易で分散化した後にそのラベルを効果的にする難しさにあった。
  • Christian Huitema のエニーキャスト拡張により、リレーを見つけるための設定は削減されたが、サービスが成功するかどうかはルーティングの範囲、監視、障害分離、そして独立して管理される順方向と逆方向のパスに依存するようになった。その後の運用実績は、6to4 がアクティブであることを知らなかったユーザーにとって、その取引がいかに脆弱になり得るかを示した。
  • Carpenter の2011年の勧告は、散在する症状を役割別の運用報告書にまとめた。ブラックホール、可変遅延、パス MTU 障害、誤解を招く診断、ヘルプデスクのコストなどである。Dan Wing と Andrew Yourtchenko の Happy Eyeballs は、その後、基礎となる6to4 パスを修復することなく、クライアントから見える遅延の一部を抑制した。
  • Ole Troan が著し、Carpenter が編集した IETF Best Current Practice である RFC 7526は、2015年にエニーキャスト6to4 を非推奨とし、デフォルトを厳格化した。しかし、基本的なユニキャスト6to4 や IPv6 プレフィックス2002::/16を非推奨にはしなかった。この境界は、エンジニアリング上の決定と Carpenter の役割の両方を理解する上で不可欠である。

設計上は一時的、運用上は永続的

「恒久的な解決策として意図されたものではない」という一文は、2001年2月に Brian Carpenter と Keith Moore が発表したRFC 3056の冒頭の説明に登場する。この但し書きは、著者を後の批判から守るために付録に埋め込まれたものではなく、メカニズムの定義の一部をなしていた。6to4 はオプションの暫定的な橋渡しであり、ネイティブ IPv6 接続が利用可能になる前に、孤立した IPv6 サイトが IPv4 ネットワークを介して通信できるようにすることを意図していた。同じ文書は、プロバイダがそれを可能にした場合、サイトはネイティブ IPv6 プレフィックスと接続に移行すべきであると述べている。したがって、一時性は後付けの解釈ではなく、アーキテクチャ上の前提条件であった。

14年後、RFC 7526は、6to4 はエニーキャストモードで使用されると広範なインターネット展開には不適切であると結論付けた。これらの声明の間にこそ、本当のストーリーがある。これは、発明者が欠陥のある技術をリリースし、最終的にそれを破棄するというおなじみの教訓話ではない。Carpenter は元のメカニズムの2人の著者の1人であり、Christian Huitema のエニーキャスト設計を執筆したわけでも、製品のデフォルト、リレー事業者、ルーティングポリシー、ユーザー採用を管理したわけでもない。2015年には、Ole Troan が非推奨文書の著者であり、Carpenter がその編集者であった。元の設計も後の Best Current Practice も、技術コミュニティ内で動作する成果物であり、一人の人間の指揮下にある独占的な行為ではなかった。

より鋭い問いは、明示的に一時的なメカニズムが、なぜ2011年に運用上の勧告を必要とし、2015年に正式で限定された非推奨を必要とするほどの永続性を獲得したのかということである。答えは、一般的な移行の取引から始まる。6to4 は、すべての中間ネットワークが IPv6 をサポートすることを必要とせずに、既存の IPv4 インターネットをキャリアとして使用できるという点で、まさに価値を提供した。これにより、IPv6 サイトの即時の調整負担は軽減された。しかし、負担は消えたわけではなかった。それは、アドレス構築、自動トンネリング、リレーの可用性、ルーティングアナウンス、フィルタリング、パスの対称性、障害診断に移行した。遷移状態への参入が容易になればなるほど、サービスが依存するすべての関係者が単一の運用計画を共有する可能性は低くなった。

この区別は、Carpenter の記録にとって中心的なものである。一時的なラベルは設計意図を規定できるが、それだけでインストールされたソフトウェア、デフォルト設定、独立して運用されるネットワークを規定することはできない。2011年の6to4 展開に関する勧告ガイドライン（Carpenter が執筆し、IETF のコンセンサス文書として公開）は、長い再試行遅延、完全な失敗、そして6to4 が動作していることに気づいていないユーザーについて報告した。この勧告は、2001年に「暫定的」と言ったことが、後のすべてのホストやルーターにタイマーを作成したと主張するものではなかった。それは、永続性を管理すべき運用条件として扱った。

2015年の対応は、元の境界を書き換えることなくテストした。IETF は、6to4 を使用するすべてのパケットを違法と宣言したり、アドレスアーキテクチャ全体を再利用したり、メカニズムが決して機能しなかったと主張したりはしなかった。エニーキャスト移行メカニズムとそのよく知られた IPv4 リレーアドレスを非推奨とし、新しい実装への組み込みを推奨せず、残っている場合はデフォルトで無効にすることを要求した。同時に、基本的なユニキャスト6to4 と2002::/16を非推奨の対象外とすることを明示した。結果は、普遍的な退役よりも劇的ではなく、より規律正しいものであった。広範囲にわたる管理されていない運用が最も明確な害の証拠を生み出した部分を撤回し、その決定がカバーしなかった範囲を正確に記録したのである。

メカニズムと利便性に隠された義務

Carpenter と Moore の設計は、特定のブートストラップ問題を解決した。グローバルにユニークな IPv4 アドレスを持つサイトは、その IPv4 アドレスを埋め込むことで、2002::/16の下で48ビットの IPv6 プレフィックスを導出できた。サイトを離れる IPv6 パケットは、プロトコル41を使用して IPv4 パケット内にカプセル化できた。6to4 サイト間のトラフィックには、埋め込まれたアドレスが境界ルータに必要な IPv4 宛先を提供した。6to4 サイトとネイティブ IPv6 間のトラフィックには、リレールータが2つのドメインを接続した。この魅力は具体的だった。孤立した IPv6 ドメインは、限られた手動設定と、サイト間の明示的なトンネルなしで、IPv4 広域ネットワークを介して通信できた。これらの設計要素と制限は、RFC 3056に記載されている。

アドレス形式は、ラベルを割り当てる以上のことを行った。IPv6 サイトの到達可能性を、グローバルにユニークで正しく埋め込まれなければならない IPv4 アドレスに結合した。カプセル化およびデカプセル化ノードは、プライベート、ブロードキャスト、マルチキャスト、またはループバックの IPv4 空間から派生したアドレスを拒否しなければならなかった。アドレス選択も重要だった。ネイティブと6to4 の両方のアドレスが利用可能な場合、エンドポイントは互換性のある選択を必要とし、文書は両方のピアが両方の形式を持つ場合、デフォルトでネイティブ IPv6 を優先した。これらは装飾的な実装詳細ではなかった。これらは、ショートカットが単なる IPv6 に見えるアドレスではなく、使用可能なルートを表すための条件だった。

リレーの境界は、別の種類の義務を追加した。ネイティブ IPv6 ドメインに向けてトラフィックを運ぶリレーは、適切な範囲内で2002::/16をアドバタイズし、そのアドバタイズによって引き寄せられたトラフィックを実際に受け入れなければならなかった。Carpenter と Moore は、誤ったポリシーが到達不能性や異常なトラフィックパターンを生み出す可能性があると警告した。彼らは、6to4 ルータと利用可能なリレー間の明示的なデフォルトルートやルーティング関係を含む管理されたオプションを説明した。この取り決めは、事業者がどのトラフィックをリレーが運ぶ用意があるかを決定し、ルートの可視性をその決定に合わせることを前提としていた。言い換えれば、6to4 は介在する IPv4 クラウドをアップグレードする必要性を取り除いたが、説明責任のあるエッジの必要性は取り除かなかった。

元の文書の移行シーケンスでさえ、長い尾を露出していた。サイトは6to4 で開始し、ネイティブ接続が到着したときにネイティブプレフィックスを追加し、アドレス選択に共存中にどのパスを使用するかを決定させ、6to4 設定の使用が停止した後に削除することができた。これはおそらく数年後になる。この段階的手順は、継続性のために賢明だった。しかし、それは出口が各展開サイトでの観察と行動に依存することを意味した。すべての依存関係がなくなったことを証明できる中央イベントはなかった。メカニズムの技術的な分散化は、ライフサイクルの分散化を生み出した。暫定パスを有効にできる当事者は、それを安全に削除できることに気付く必要がある当事者の1つでもあった。

元の仕様は、診断の不透明ささえ予見していた。キャリアネットワーク内で生成された IPv4「到達不能」は6to4 ルータに戻り、多くの場合、発信元の IPv6 ノードに有用な ICMPv6 エラーを配信するのに十分な情報を欠いていた。その結果、IPv4 ネットワークは IPv6 側から診断不能なリンク層として現れる可能性があった。この観察はすべての後の失敗を予測したわけではないが、構造的な問題を特定した。カプセル化は、管理上および診断上の継ぎ目を横断する。トンネルの下での障害は現実のものであり得るが、トンネルの上のエンドポイントのビューは不完全なままである。

これが、6to4 を労力が不要か単に欠陥があるかのいずれかと表現することが誤解を招く理由である。その利便性は条件付きだった。管理されたルーティング、正しいアドレス選択、グローバルに有効なアドレス指定、機能するリレー、互換性のあるフィルタリングの下で、それは約束した暫定的な接続を提供できた。ライフサイクルの困難は、目に見えるユーザー提案（IPv4 を介した自動 IPv6）が、その提案が依存する目に見えない運用規律から分離されたときに生じた。設計の参入コストはネイティブ展開に比べて低く、その保証コストは分散されていた。

エニーキャストは設定を減らし、調整の賭け金を引き上げた

次のステップは Carpenter の設計ではなかった。2001年6月に Christian Huitema が著したRFC 3068は、6to4 リレーエニーキャストプレフィックスとアドレスを導入した。その目標は、IPv6 ドメイン間ルーティングに参加せず、他の方法でデフォルトリレーを見つけて設定する必要があるネットワークの設定を簡素化することだった。6to4 ルータは、よく知られた IPv4 アドレス192.88.99.1にトラフィックを向けることができ、ルーティングは関連するプレフィックスをアドバタイズする利用可能なリレーにそれを運ぶ。これにより、リレー発見が自動化され、1つのリレーがサービスのアドバタイズを停止した場合にルーティングベースのフェイルオーバーが提供された。

この拡張は、元の管理された取り決めにおける実際のユーザビリティ問題に対処した。小規模ネットワークはインターネット全体でのみリレーを見つけ、パフォーマンスが低下するか、まったく設定に失敗する可能性があった。エニーキャストは、「どのリレーか？」をユーザーごとの設定タスクではなくルーティングの答えにした。この変更により、6to4 は小規模ネットワークやシンプルなゲートウェイにとってよりアクセスしやすくなった。また、依存関係の性質も変わった。ユーザーはもはや名前付きの利用可能なリレーを選択しなかった。ルーティングシステムが共通アドレスの背後にあるインスタンスを選択し、発信元インスタンスはネイティブ IPv6 からの戻りトラフィックを運ぶために後で選択されるリレーである必要はなかった。

Huitema の文書は、エニーキャストに運用上の注意が必要であることを明示していた。送信ルータがリレーインスタンスを直接識別しなかったため、断続的な障害の割り当てが困難になる可能性があった。仕様は、適切な監視と障害分離手順を要求した。リレーは、そのリレー機能が失敗した場合、エニーキャストプレフィックスへのルートの注入を直ちに停止し、対応するユニキャストアドレスが事業者が特定のリレーをテストするのに役立つ可能性があるとしていた。設計はまた、6to4 サイトに最も近いリレーがネイティブ宛先への最良のルートを提供しない可能性があることを認識し、可能なリダイレクトは今後の検討課題とした。実際の展開には、監視とテストツール、進化する管理プラクティス、運用経験が必要であると述べていた。

これらの但し書きが重要なのは、192.88.99.1がエレガントな発見デバイスであったかどうかのみでエニーキャストのライフサイクルを判断できないからである。サービスの約束は、いくつかの命題が一致している間だけ存在した。ルートが有用な場所につながっていること、到達したリレーが送信者のトラフィックを受け入れること、リレーがネイティブ IPv6 接続を保持していること、監視が悪いルートを迅速に撤回すること、戻りリレーが宛先近くで2002::/16をアドバタイズしていること、プロトコル41が介在するフィルタを通過すること、両方向がセキュリティポリシーを満たすこと。エニーキャストは、これらの選択をユーザーに露出する設定を減らした。それは選択を排除しなかった。

これは、技術的ロックインの繰り返し発生する形態である。ベンダー契約や意図的に閉じられたインターフェースを伴う必要はない。メカニズムは、便利さが単一の事業者が完全なインベントリを持たない場所に状態を広げるため、粘着性になる可能性がある。ホスト、ホームゲートウェイ、トランジットネットワーク、リレー、ファイアウォール、コンテンツネットワークが同じパスについて独立した仮定を行うと、削除は調整の演習になる。ユーザーは、背後にあるサービスが利用不可または損なわれていても、有効に見えるアドレスとデフォルトルートを持つ可能性がある。目に見える設定は、それを信頼できるものにする制度的取り決めが存在しないにもかかわらず存続する。

エニーキャスト RFC はこのリスクを隠しておらず、いずれにせよ Carpenter のせいにされるべきではない。Huitema が著者である。Carpenter はワーキンググループの議論の謝辞に登場するが、それはエニーキャストメカニズムの著作者ではない。正しい分析ポイントはより広い。標準文書は管理上の前提を正確に述べることができるが、大規模な展開は依然として、自動化を信頼できるものにする規律ではなく、自動的に見える機能を選択する可能性がある。後の証拠は秘密の意図を明らかにしなかった。それは、運用上の前提がパブリックインターネット全体で確実に実現されなかったことを示した。

セキュリティ分析は開放性を運用上の負債に変えた

2004年までに、自動トンネリングのセキュリティ影響は専用の分析を受けていた。RFC 3964は、Carpenter ではなく Pekka Savola と Chirayu Patel が著した。それはリスクの多く背後にある2つの特性を特定した。6to4 ルータは他の6to4 ルータやリレーからのプロトコル41トラフィックを受け入れてデカプセル化しなければならず、リレールータはネイティブ IPv6 ノードに関連するトラフィックを受け入れなければならなかった。結果として生じる信頼面により、いくつかのシナリオでサービス拒否、反射型サービス拒否、アドレスなりすましが容易になった。

セキュリティ問題は単にトンネリングが存在することではなかった。自動設計により、内部と外部のアドレス関係が自己認証的でない一方で、カプセル化されたパケットを処理のために提示できる者が広がったことだった。Savola と Patel は、非グローバル IPv4 アドレスを拒否し、埋め込まれた IPv4 と6to4 の送信元情報の一致を要求し、リレーが2つの6to4 宛先間でトラフィックをバウンスするのを防ぎ、トンネルを介して到着する無意味なネイティブ間パケットを破棄するチェックを説明した。これらのチェックは、比較的安全な実装の前提条件であり、すべての脅威が消えるという約束ではなかった。

その制限は重要である。分析は、正しいチェックがあっても、6to4 開発者やリレー事業者が完全に解決するのが困難または不可能ないくつかの脅威が残ると結論付けた。なりすましと反射は、メカニズム自身の制御外のフィルタリングに部分的に依存していた。リレーは、トラフィックをデカプセル化または再カプセル化するため、悪用のソースと区別するのが難しくなり、事業者に調査と管理上の負担を生じさせる可能性があった。プロトコル41を共有する複数の自動トンネルメカニズムは、パケットが別個の遷移メカニズム識別子を持たないため、厳密な分類をさらに困難にする可能性があった。

この証拠は、暫定的な取引の評価方法を変える。リレーは、移行のために提供された単なる有用な転送ポイントではなかった。それはセキュリティ実施面、潜在的な標的、増幅器、管理上の連絡先であった。「無料リレー」は、ユーザーによる直接の設定や支払いがないことを説明したものであり、リレーに運用コストがないことを意味するものではなかった。監視、フィルタリング、ログ記録、容量、インシデント対応は、ユーザーがそれらを見ることはなくても、サービスの一部であった。

これらの発見のいずれも Carperson 個人に帰属するものではない。Savola と Patel が分析を実行し、脅威を文書化した。また、脅威はすべての6to4 パスが安全でないか失敗したことを証明するものでもない。ライフサイクルにおけるそれらの重要性は証拠的である。安全な運用には、短い転送パスを実装する以上のものが必要であることを示した。メカニズムの保証ケースは、ルータ、リレー、ネットワークエッジでの動作に依存しており、それらは互いに強制できないアクターを含んでいた。この証拠が蓄積されるにつれて、正当化の負担は変化した。メカニズムが2つのドメインを接続できることを示すだけではもはや十分ではなかった。継続的な広範な使用は、開放的な自動リレーシステムを信頼できるものに保つコストと比較検討されなければならなかった。

2011年の勧告：プロトコルの可能性からユーザーが見える証拠へ

メカニズムの後のライフサイクルに対する Carpenter の最も直接的な個人的貢献は、RFC 6343であり、彼は公開レビュー後に IETF コミュニティコンセンサス記録として情報提供用に著した。その目的は実践的であり、謝罪的ではなかった。それは、インターネットサービスプロバイダ、コンテンツプロバイダ、実装者を対象としており、自ら IPv6 を提供していないネットワークも含まれていた。なぜなら、その顧客やヘルプデスクも6to4 の影響を受ける可能性があったからである。

勧告の冒頭は、プロトコル仕様の視点を逆転させる。パケットが所定の条件下でカプセル化および中継できるかどうかを尋ねる代わりに、それらの条件が部分的にしか満たされていない場合にユーザーが何を経験するかを尋ねる。答えには、長い再試行遅延または完全な失敗が含まれていた。一部のエンドシステムや顧客宅内ルータは6to4 をサポートし、一部の機器はデフォルトで有効にしていたため、ユーザーはそれがアクティブであることを知らずにメカニズムに遭遇する可能性があった。助けを求めたとき、根本的な原因は診断が困難だった。文書は、多くのヘルプデスクが IPv6 を完全に無効にするようアドバイスしたという観察を逸話的とラベル付けしている。普遍的な調査を主張するものではない。

それでも、その逸話は重要な因果関係の逆転を明らかにしている。6to4 は、ネイティブサービスがない場合に初期の IPv6 使用を促進することを意図していた。障害のある6to4 パスがユーザーとサポートスタッフに「IPv6」が無効にするものであると教えた場合、移行ツールは宛先技術への信頼を損なう可能性があった。障害はパケット損失だけではなかった。それは人間のインターフェースでの誤解を招く帰属だった。自動ブリッジは目に見えない形で失敗し、より広いプロトコルファミリーが非難を受けた。

勧告は、ルータ6to4 とエニーキャスト6to4 を区別した。元のルータ設計は、管理された協力的な設定を前提としており、発信トラフィックを運ぶ意思のあるリレーを含んでいた。エニーキャストバリアントは、デフォルトのリレーアドレスを提供することで、ユーザーがその取り決めを行う必要性を取り除いた。実際には、Carpenter のコンセンサス記録によると、管理されたルータ6to4 の推奨事項に従った公的展開はほとんどなく、エニーキャスト6to4 が支配的だった。ホストまたはゲートウェイはグローバル IPv4 アドレスを認識し、IPv6 宛先を解決し、192.88.99.1に向けた送信が機能することを推測する可能性があった。その推測は、すべてのローカルインジケータがもっともらしく見えても間違っている可能性があった。

記録された障害は、単一のバグではなく連鎖を形成していた。発信ブラックホールは、エニーキャストプレフィックスへのルートが受け入れられたが、フィルタ、利用不可のリレー、またはどこにも有用でない場所につながった場合に存在する可能性があった。着信ブラックホールは、発信パケットがリレーに到達し、ネイティブ宛先が応答した後に発生する可能性があり、それはプロトコル41フィルタが返ってくるカプセル化パケットをブロックしたためだった。戻りリレーが欠落しているか、2002::/16への到達可能性をアドバタイズするリレーが引き寄せたトラフィックを拒否する可能性があった。両方向が存在する場合、管理されておらず、おそらく異なるリレーが依然として大きくまたは可変のラウンドトリップタイムを生み出す可能性があった。

パス MTU 発見は、より欺瞞的な失敗を生み出した。カプセル化により、有用なパス MTU が減少した。小さな診断パケットや TCP ハンドシェイクの開始でさえ成功する一方で、より大きなデータパケットは、「パケットが大きすぎる」情報が正しく伝わらない場合や最大セグメントサイズ処理が失敗した場合に消失する可能性があった。したがって、ユーザーは1つのサイトに到達し、別のサイトに ping を実行し、トンネルが分割線であることを示す明白な兆候を見ない可能性があった。これは、クリーンな拒否よりもコストの高い障害である。成功した予備的動作がオペレーターを誤った診断パスに送るためである。

他の障害は、アドレス証拠と現実の間の結合を露出させた。プライベート空間であるかのように使用されるグローバルに見える IPv4 値は、有効な戻りパスのない6to4 プレフィックスを生成する可能性があった。キャリアグレードアドレス変換は、埋め込まれたアドレスが到達可能なトンネルエンドポイントを表すという仮定を破る可能性があった。一部の実装は、元の仕様に反して、プライベート IPv4 アドレスでもアクティブになると報告された。逆 DNS チェックは、委任を欠いた6to4 クライアントを拒否する可能性もあった。これらの条件のいずれも普遍的ではなく、一緒になって「ウェブページが遅い」などの症状を多すぎる原因と互換性のあるものにした。

RFC 6343は、実験から報告された測定値を含んでいたが、それらを普遍的な展開統計に変えることはなかった。それは、ある実験で9～20%、別の実験で9～19%の6to4 接続失敗範囲を引用しており、それぞれの方法に基づく。また、デュアルスタックコンテンツサーバーへの試行のごく一部しか6to4 を試みなかったため、試行全体の損失は1%未満であると説明した。勧告は、かなりの成功した使用があることを明示的に指摘した。したがって、規律正しい結論は、インターネットの一定割合が壊れていたということではない。研究された6to4 試行の中での失敗が重要であり、小さな総合的なシェアでもプロバイダにとって重要であり、ユーザーの遅延とサポート需要を生み出す可能性があるということである。

文書は、それらの失敗をコンテンツプロバイダの金銭的影響とヘルプデスクコストに関連付けたが、正確な合計は提供せず、それらのコストを Carpenter に割り当てなかった。ベンダーのデフォルト、事業者のルーティング、リレーの動作、ファイアウォール、クライアントのフォールバックが特定の結果を決定した。Carpenter の説明責任のある行為は、メカニズムレベルの証拠と運用証拠をまとめて、影響を受ける役割を指名した記録にすることであった。彼は分散した展開履歴を自身の成功や失敗の物語に変換しなかった。

その形式の選択は重要である。個人的な意図を中心に書かれた回顧録は、2001年の著者が正しかったかどうかを尋ねたかもしれない。勧告は代わりに、現在の各アクターが何ができるかを尋ねた。ベンダーと実装者は、エニーキャスト6to4 をデフォルトで有効にせず、プライベートアドレスでアクティブになる実装を修正するよう指示された。IPv6 のないネットワークは、エニーキャストアドレスへのルートが明示的で、安定しており、合理的に近く、利用可能なリレーによって受け入れられることを確認するよう指示された。ネイティブ IPv6 を持つネットワークは、ユーザーを6to4 から遠ざけ、誤ってリレーになっていないことを確認するよう奨励された。トランジットとコンテンツプロバイダは、別個のルーティング、戻りパス、容量、フィルタリングのガイダンスを受けた。

この役割別の構造は、エンジニアリングの説明責任の証拠である。なぜなら、それは制御に従うからである。ベンダーはデフォルトを変更できるが、すべてのトランジットルートを修復できるわけではない。アクセスプロバイダは到達可能性をテストしたり明示的な失敗を返したりできるが、遠くのコンテンツネットワークに戻りリレーを運用させることはできない。コンテンツプロバイダはサーバーの近くにリレーを配置できるが、ユーザーの障害のあるゲートウェイを削除することはできない。関連する制御面を持つアクターにアドバイスを割り当てることは、2つの反対の誤りを避ける。集団的な失敗を誰の責任でもないとすること、または一人の名前のある標準著者にすべての実装とネットワーク決定の責任を負わせることである。

緩和策は暫定状態を維持するコストを露出させた

2011年のガイダンスはまだ非推奨ではなかった。大規模なインストールベースが残っている間に害を減らそうとした。IPv6 サービスのないプロバイダにとって、192.88.99.1へのルートは単なるデフォルトルート以上のものでなければならなかった。それは機能し、安定しており、利用可能なリレーにつながる必要があった。それが確立できない場合、勧告は明示的な到達不能応答を検討することを示唆し、一部のクライアントがより速くフォールバックできるようにしたが、その戦術での運用経験は限られていることを認めた。単にプロトコル41をドロップすることはクリーンな解決策ではなかった。なぜなら、それは黙って6to4 を悪化させ、意図的に設定された IPv6 トンネルにも害を及ぼしたからである。

サービスをサポートすることを選択したトランジットプロバイダにとって、義務は substantial だった。IPv4 エニーキャストプレフィックスは、トラフィックが受け入れられるクライアントネットワークに向けてのみアナウンスされなければならなかった。2002::/16ルートは、それによって引き寄せられたトラフィックが実際に中継できるようにスコープされなければならなかった。リレーの戻り送信元アドレスは、ステートフルファイアウォールと入力フィルタリングを考慮して選択されなければならなかった。プロトコル41と必要な ICMPv6 メッセージは通過しなければならなかった。容量は監視され、拡張可能でなければならず、管理されていないリレーは避けられなければならなかった。これらの要件は、RFC 6343から来ており、1つの設定がすべての事業者に適合するという主張からではない。

コンテンツプロバイダは、特に明らかな非対称性に直面した。6to4 クライアントは、1つのリレーを介してデュアルスタックサーバーに到達できる一方、サーバーの応答は2002::/16への異なるルートに依存していた。勧告は、ローカルに配置された戻りリレーと慎重なルーティングスコープを推奨し、戻りパスが短く機能するようにした。それは、ネイティブ IPv6 を正しく展開したプロバイダでも、他の場所で管理されていない移行メカニズムを使用するクライアントのためにインフラストラクチャを必要とする可能性があることを意味した。互換性のコストは、宛先を提供する当事者に向かって移行しており、必ずしも6to4 を有効にした当事者ではなかった。

ここで、ソフトウェアライフサイクルとネットワークリソースの証拠が出会う。機能は設計意図において「レガシー」でありながら、運用コストにおいて現役であり続けることができる。ルート、パケットフィルタ、リレー容量、サポートケースは、古いコードの抽象的な痕跡ではなく、現在消費されているリソースである。2011年の勧告は、事実上これらのリソースを可視化した。互換性の維持が、古いアドレス形式を受動的に許容するのではなく、監視とポリシーを必要とするアクティブなサービスであることを示した。

それはまた、「機能する」と「機能しない」の間の二項決定の弱点を露出させた。エニーキャスト6to4 は多くのパスで機能し、ルートスコープ、リレーの意思、ファイアウォールの状態、MTU、戻りトポロジに応じてサブセットで失敗する可能性があった。部分的でパス依存の成功を持つメカニズムは、クリーンに失敗するものよりも退役が難しい。なぜなら、成功したユーザーは継続に正当な関心を持つ一方、失敗したユーザーはどの機能が原因かを知らない可能性があるからである。したがって、適切な対応は、新しい自動アクティベーションを減らし、正当な場合に明示的な運用を保存し、残存トラフィックを考慮してのみ共有インフラを削除しなければならない。その論理は、2015年の境界のバックボーンとなるだろう。

Happy Eyeballs は損害を封じ込めたが、6to4 を修復しなかった

クライアントソフトウェアは別の緩和層を提供した。2012年に Dan Wing と Andrew Yourtchenko が著したRFC 6555は、IPv6 パスが損なわれているが IPv4 が機能する場合にデュアルスタックアプリケーションが経験する遅延に対処した。壊れた6to4 は、他の壊れたトンネル、欠落した IPv6 接続、ピアリング問題と並んで、リストされた原因の1つであった。このアルゴリズムは、優先接続が完了しないときに他のアドレスファミリを迅速に試し、成功した接続を使用し、結果を記憶してネットワークに繰り返し負荷をかけるのを避けることができた。

Happy Eyeballs は、悪いパスのユーザーに見える結果を変えた。長い IPv6 タイムアウトを待ってから IPv4 を試す代わりに、アプリケーションは試行を競合または密接にずらして、機能するファミリで続行できた。これは貴重な損害封じ込めだった。ユーザーが RFC 6343で説明された完全な遅延を経験する確率を減らし、アプリケーションを応答性良くするためだけに IPv6 を全面的に無効にするインセンティブを弱めた。

しかし、封じ込めと修復の区別は正確でなければならない。Happy Eyeballs は、欠落したリレーを出現させたり、プロトコル41フィルタを開放したり、無効な埋め込みアドレスを修正したり、パス MTU 発見を復元したり、6to4 トンネルを保護したりしなかった。それはクライアントで損なわれたパスを回避して選択した。Wing と Yourtchenko はまた、トレードオフを指摘した。余分な試行はネットワークとサーバーにいくらかの負荷を生み出すため、アルゴリズムは無差別な同時接続を避け、成功しなかったものを放棄すべきである。

緩和策はまた、インフラストラクチャの障害をより見えにくくする可能性があった。RFC 6555は、この技術を使用するアプリケーションはデフォルトで特定のアドレスファミリの診断にあまり有用ではないと指摘した。なぜなら、成功した代替が失敗を隠すからである。RFC 7526は後に、多くのブラウザが Happy Eyeballs を通じて6to4 の障害モードをユーザーから隠していたと述べた。ここでの「隠された」は解決されたことを意味しない。ユーザーのトランザクションが成功する一方で、失敗した6to4 試行はネットワークの背景状態の一部として残ることを意味する。

これはライフサイクルのパラドックスを生み出す。優れた互換性メカニズムは移行中にユーザーを保護するが、症状を和らげることで原因を取り除く圧力を減らす可能性がある。正しい教訓は、クライアントの回復力を拒否することではない。それは、ポリシーにおいて層を区別し続けることである。アプリケーションがそれを回避することを学んだとしても、損なわれたネットワークメカニズムを測定し、修復または退役させることである。そうでなければ、アプリケーション層での成功は、基礎となる移行サービスが健在であるという誤った証拠になる。

2015年の決定は意図的に「6to4 を退役」よりも狭かった

RFC 7526のタイトルはその範囲を示している：「6to4 リレールータのエニーキャストプレフィックスの非推奨」。Ole Troan が著者であり、Brian Carpenter が編集者であった。この文書は2015年5月に IETF Best Current Practice として公開され、コミュニティのコンセンサスを表していた。それは RFC 3068と関連するプロバイダ管理エニーキャストフレームワークを Historic にし、エニーキャストメカニズムと関連アドレス192.88.99.1を非推奨とし、将来の製品が6to4 エニーキャストをサポートしないことを推奨した。

負の空間も同様に重要である。RFC 7526は、RFC 3056で定義された基本的なユニキャスト6to4 と IPv6 プレフィックス2002::/16は非推奨ではないと明示的に述べている。エニーキャストサービスに依存しないピアツーピア使用は対象外であった。文書は、すべての6to4 トラフィックまたはルートの一般的なフィルタリングを推奨しなかった。事業者は残存クライアントのために戻りリレーを継続でき、継続するエニーキャストサービスは RFC 6343の運用ガイダンスに従うよう指示された。

実装のデフォルトはより厳格になった。新しい実装はエニーキャスト6to4 を含まないことが推奨され、含む場合はデフォルトで無効にしなければならなかった。ホスト実装はまた、ユニキャスト6to4 をデフォルトで無効のままにし、更新された IPv6 アドレス選択ポリシーをサポートしなければならなかった。ルータ実装は6to4 をデフォルトで無効にしなければならず、IPv6 転送を有効にしても黙って有効にしてはならなかった。これらの規定は、ユニキャスト6to4 が非推奨ではないという声明と矛盾しなかった。ステータスとデフォルトは異なるポリシー手段であり、一方は明示的で制限された使用のために定義されたメカニズムを保存し、他方は偶発的なアクティベーションが管理されていない展開問題を再現するのを防ぐ。

運用上の撤退も同様に、瞬間的ではなく段階的だった。ネットワークは、エニーキャストリレーを積極的に運用および監視していない限り、192.88.99.1へのルートを発信してはならなかった。既存のリレー事業者は、トラフィックが減少したらサービスを廃止できるかどうかを検討するよう指示された。2002::/16を顧客にアドバタイズするプロバイダは、それが正しく機能する戻りリレーにつながる場合にのみそうすべきだった。これは、非推奨文書が展開されたクライアントを消去せず、時期尚早の撤退がポリシーが減らそうとしているまさにブラックホールを作り出す可能性があることを認識していた。

文書は、「非推奨」が通常の意味での不承認を表現するために使用されており、インターネットからコードを削除する魔法の規範的操作ではないことを明らかにした。非推奨機能は、後方互換性のために何年も残る可能性がある。これはライフサイクルのリアリズムの異常に有用な声明である。標準のステータスは、新しい実装と展開の方向を変えることができる。それはすべての製品、ルート、事業者の決定を同期的に更新することはできない。

Carpenter の編集上の役割は、その制限された制度的行为の中にある。彼が2001年に共著した一時的な境界、2011年に著した運用記録、2015年に編集した限定された非推奨の間の連続性を見ることは合理的である。IETF Datatracker 記録はそれらの役割をリストしている。その連続性を、彼が個人的に6to4 を退役させたという主張に変えることは合理的ではない。Troan が RFC 7526を著し、その権威は IETF Best Current Practice プロセスとコミュニティコンセンサスから来ている。

その区別は技術史の質を保護する。決定を個人化することは、運用者、実装者、研究者、ユーザーによって提供された証拠を隠しながら、標準ステータスに対する Carpenter の支配力を誇張するだろう。完全に非個人化することは、ライフサイクル全体に関与し続けることで表現された説明責任を見逃すだろう。正確な中間はより強い。Carpenter は一時的なメカニズムの定義に参加し、後にその運用コストに彼の名前を入れ、証拠に一致するように十分に狭く描かれたコミュニティ決定を編集した。

長い移行を通じた説明責任あるエンジニアリングの姿

6to4 の記録は、エンジニアリングの説明責任のための3つのテストを提供する。最初のテストは、元の約束がそれ自身の境界を含んでいるかどうかである。RFC 3056はそうだった。それは6to4 をオプションかつ暫定的と説明し、利用可能な場合はネイティブ IPv6 を優先し、最終的な削除のためのシーケンスを定めた。Carpenter と Moore は、IPv4 上のトンネルを IPv6 の恒久的なアーキテクチャとして販売しなかった。

2番目のテストは、後の証拠が運用推奨を変更することを許されるかどうかである。RFC 6343は、意図されたトポロジを繰り返すことによってメカニズムを防御しなかった。それは観察されたユーザー結果から始め、それらをルート、リレー、フィルタ、アドレス仮定、MTU 動作を通じてトレースバックした。また、証拠の限界を可視化し続けた。一部のヘルプデスク行動は逸話的であり、特定の失敗率は引用された実験に属し、成功した使用が存在し、普遍的なコスト総額は主張されなかった。この規律は重要である。弱い証拠は、否定が有害なデフォルトを保存するのと同じくらい容易に、過広範な救済策を生み出す可能性があるからである。

3番目のテストは、撤退が証拠が確立するものに比例しているかどうかである。RFC 7526は、広範なインターネット使用に不適切と判断されたモードであるエニーキャスト6to4 を対象とした。それは、目に見えないアクティベーションを防ぐためにデフォルトをより広く厳格化したが、基本的なユニキャスト使用と2002::/16が廃止されたふりはしなかった。それは残存サービスのための運用ガイダンスを保存し、ルート発信をアクティブな監視に結び付けた。救済策は、単純な見出しへの欲求ではなく、障害メカニズムに従った。

これらのテストは、Carpenter の物語が勝利として framing されるべきではない理由も説明する。ネイティブ IPv6 の目的地は、すべての移行実験を英雄的な足がかりに変換するわけではなく、凍結された記録は、6to4 の採用または撤退が彼に属していたと主張する根拠を提供しない。また、それは個人的な失敗の物語でもない。ベンダーはデフォルトを選択し、事業者はルートとフィルタを選択し、リレーインスタンスは異なる動作をし、アプリケーションはフォールバック戦略を選択し、ユーザーは結合されたパスを経験した。因果責任は、制御が分散されていたため分散されていた。

Carpenter の文書化された役割が示すのは、以前の仕事の結果に執着し続ける意欲であり、それらに対する指揮を主張することはない。2001年の共著は、明示された制限を持つ公的な技術的コミットメントを生み出した。2011年の著者は、実際の展開が元のメカニズムが説明できないコストを生み出したことを受け入れた。2015年の編集は、行き過ぎではないコンセンサス救済策を表現するのに役立った。これは、発明の後に悔い改めが続くよりも映画的ではない。また、展開されたコード、アドレス、ルートがどのくらい持続するかを単独で決定できる著者はいないインフラストラクチャにとって、より有用なパターンである。

ここには制度的正当性についてのより広い教訓があるが、それはメカニズムに基づいており、標準についての一般的なエッセイではない。正当性は、主張を役割に、救済策を証拠に一致させることから来た。Huitema はエニーキャスト拡張の著者であり続ける。Savola と Patel はその専用セキュリティ分析の著者であり続ける。Wing と Yourtchenko はクライアント側遅延緩和の著者であり続ける。Troan は非推奨の著者であり続け、Carpenter は編集者である。明確な帰属は、一人の有名な名前の周りで権威が製造されるのを防ぎ、因果関係の説明を監査可能にする。

記録はまた、ネットワークリソースの証拠がライフサイクル決定にとってなぜ重要かを示している。移行メカニズムは、より新しいアーキテクチャが好ましいからといって退役するわけではない。その継続的な価値とコストは、到達可能なプレフィックス、機能するリレー、失敗したハンドシェイク、パス遅延、MTU 動作、フィルタリング、残存クライアントトラフィックに現れる。これらのシグナルは不完全で分散しているが、意図の宣言よりもメカニズムに近い。2015年の決定は、元の暫定境界を長年のセキュリティと運用証拠に結び付け、事業者が実際に実装できる範囲を描いたため、信頼できるものになった。

結論

6to4 は有効期限条件で始まったが、普遍的な時計はなかった。Carpenter と Moore はネイティブ IPv6 への移行を期待した。Huitema のエニーキャスト拡張は暫定ルートへの参入を容易にした。Savola と Patel はセキュリティ負担を文書化した。Carpenter の2011年の勧告は、分散した障害がユーザーとサポートデスクにどのように到達するかを示した。Wing と Yourtchenko はクライアントでいくつかの遅延を封じ込めた。そして Troan の2015年の Best Current Practice（Carpenter 編集）は、すべての6to4 が死んだと宣言することなく、エニーキャストモードを非推奨とした。

そのシーケンスにおける Carpenter の重要性は、 appropriation のない連続性にある。彼は集合的な展開を制御せず、個人的にそれを退役させなかった。彼の記録は代わりに、より難しい形の責任を示している。一時的な取引を述べ、その隠れた運用コストが可視化されたときに文書化し、証拠が正当化できるメカニズムに救済策を狭めるのを助けることである。

ソース