要約

  • 第28版は規則の撤回、管理上の観測、ループ回避を詳しくした。既定出口の仕組み自体は第27版にもあった。
  • 新規変換から特定規則を直ちに外しても、0.0.0.0/0: Pref6(PE) が設定されていれば別の出口へ流れ得る。設定がなければ破棄とICMPまたはICMPv6の通知が想定される。
  • 管理境界を越える既定規則には明示的な二者間合意が要る。出口は引き受ける通信について完全なIPv4転送情報を持ち、同じ仕組みに戻さない必要がある。

既定値は空欄を埋めるが、理由は埋めない

この草案は、単一の事業者または協力する複数の自律システムが構成する、範囲の限られたIPv6専用の下位ネットワークを扱う。残るIPv4通信を端で変換し、途中のデータ経路にはフローごとの状態を持つ変換ゲートウェイを置かない構想である。開かれたインターネット全体に一般化する文書ではない。事前の二者間合意、対応用プレフィックスの調整、共通のICMPフィルタリング、信頼する入口PEは成立条件として挙げられる。草案そのものが合意を発行するわけではない。

特定のIPv4ブロックを別の出口へ対応付ける規則が撤回されたとする。第28版は、新たに変換するパケットにはその規則を直ちに使わないことを勧める。一方、すでに飛んでいるパケットには設定可能な数秒程度の猶予を設け得る。ここで「規則を撤回した」だけでは、次の新しいパケットの行き先は決まらない。より具体的な規則がなければ、設定済みの既定規則が命中する。既定規則もなければ、破棄してICMPまたはICMPv6のエラーを返す。この分岐を記録せずに継続性だけを報告すれば、重要な運用判断が見えなくなる。

0.0.0.0/0: Pref6(PE) は、その分岐の受け皿となる。停止を避けられる半面、遠回り、出口への集中、輻輳、無差別に吸い込む標的化を招き得る。第28版がこの規則を初めて発明したわけではない。第27版にも仕組みと危険がある。今回の読みどころは、撤回時の扱いと規則データベースの一貫性、管理境界、復元されたIPv4経路のループが、より明確に結びついた点にある。

隣のASに届くことと、任せられること

第9.4節は、明示的な二者間合意なしに既定の対応規則を管理境界の外へ広告してはならないとする。ある相手が一部のプレフィックスを運んでいた事実は、未対応の全IPv4宛先を恒久的に受け入れる約束にはならない。どのブロック、どの入口、どの既定出口、いつの変更が対象なのかを両側で確かめる必要がある。受信したパケットの数は合意の文面ではないし、片側の変更票が相手のネットワークを一方的に拘束することもない。

規則の配布については、変換種別などの重要な値を途中で変えず、対象範囲を制限・フィルタリングでき、発信元を認証し、許可されないIPv4ブロックと対応プレフィックスの結合を拒むことが求められる。ただし、具体的な配布プロトコル拡張はこの枠組みの外にある。全参加者の合意を照合する共通台帳がここで標準化された、と読んではいけない。技術的に広告を受け取れることと、行政上の境界を越える許可があることは別の証拠を必要とする。

IPv4に戻ったパケットは過去を語らない

既定出口で復元されたIPv4パケットには、既にこのIPv6専用基盤を通ったことを示す標識がない。出口での最良のIPv4経路が別の参加PEを指していれば、再び変換され、同じ枠組みに入り直し得る。TTLやホップ制限は、やがて周回を終わらせるだけで、周回を選択しないことの証明にはならない。最初の一周で転送に成功しても、安全な到達先だったとは限らない。

そこで草案は、既定出口が引き受ける通信のための完全なIPv4転送視野を持ち、再流入する経路へ解決しないことを求める。既定規則への監視、レート制限、ACLも必要な運用手段として挙げる。変更前には影響を受ける宛先の最良経路を出口側で調べ、変更後には規則ごとのカウンタ、ICMPエラー、実際の出口を突き合わせるべきだろう。公開資料から、現実の事業者がこの試験を済ませたとも、具体的なループ事故が起きたとも言えない。

両者の判断をつなぐ証跡

第8節は、規則の版や時刻、一貫性確認用のMR-DB要約、変更通知、規則別カウンタ、管理アクセスを推奨する。これらは観測に必要な材料であり、既存ネットワークに備わっているという報告ではない。Daniel Kadeの提案は、さらに狭い共同変更記録を作ることだ。撤回したプレフィックスと版、新規変換を止めた時刻、飛行中のパケットへの猶予、両側の残存規則の状態、受け入れた二者間の範囲、選んだ既定出口、IPv4経路と再流入しないことの試験、カウンタとエラー、担当者と復旧条件を結びつける。これはIETFが定義した必須様式でもパケット内のフィールドでもない。

その記録は「旧規則を止めた」「代替経路を選んだ」「相手の管理域に責任を渡した」という三つの判断を別々に扱える。通信が届いたという測定値は最後の結果を示し得ても、前二者の承認を作り出さない。カウンタが静かな場合も、検査対象のパケットが来なかっただけかもしれない。必要なのは、合意範囲と規則状態と出口の経路を同じ時点で結ぶことだ。

Datatrackerで確認した第28版はv6opsの有効なInternet-Draftで、目標はInformational、IESGでは担当ADのフォローアップ段階にあり、DISCUSSも残る。承認済みRFC、完成した規則配布プロトコル、導入実績ではない。改訂もあり得る。その未確定さを差し引いても、既定出口を安全弁と呼ぶ前に誰の判断を肩代わりするのか問う価値はある。

出典