要約

  • draft-ietf-v6ops-framework-md-ipv6only-underlay-28 は、複数 AS の IPv6-only 基盤で、分散マッピング規則に基づき両端 PE がステートレス変換する枠組みを示す。
  • フロー表がなくても、規則の発行権限、MR-DB 版、Pref6 の再帰到達性、送信元検証、撤回、既定出口は共有状態として残る。
  • 同じ台帳だけでは足りず、合意、認証済み規則、ローカル採用、FIB、変換、出口 IPv4 経路、復路、アプリ結果を結ぶ必要がある。

九つの PE が同じ MR-DB ダイジェストを報告した。小さな疎通確認も成功した。しかし 1500 バイトの IPv4 フローだけが、二つの事業者境界を越えるたび沈黙した。原因は規則ではなく、途中の ICMPv6 Packet Too Big が通らないことだった。

第28版は、この種の運用を複数 AS の限定ドメインとして描く。Datatracker、履歴、文書レコードによれば、2026年9月28日付の V6OPS Informational Internet-Draft で、IESG Evaluation 中である。RFC でも配備実績でもなく、規則配布プロトコルの詳細は範囲外だ。

入口 PE は IPv4 宛先を MR-DB で最長一致させ、出口 PE の Pref6(PE) を選ぶ。RFC 6052に従い IPv4 を IPv6 アドレスへ埋め込み、RFC 7915に従ってヘッダと ICMP を変換する。中間 P は IPv6 だけを転送し、出口が IPv4 を復元する。個々のフローに対応する変換表は不要だ。

だが規則は自然発生しない。枠組みは、参加事業者に既存の相互信頼、二者合意、接頭辞配分、共通 ICMP 方針、信頼済み入口があると仮定する。RFC 8799の限定ドメイン概念は境界を説明するが、合意の履行までは証明しない。マッピング接頭辞の外部漏えいを止めるのは実際のフィルタである。

各規則は IPv4 ブロック、Pref6、変換方式を結ぶ。出口は自らが権威または集約点である顧客ブロック、プール、サイト集約だけを個別に発行でき、外部 transit 経路を自分の規則として再発行してはならない。配布方式はフィールド完全性、境界スコープ、起点認証、権限外バインドの拒否を備える必要がある。

起点認証は、主張者を示すだけだ。IPv4 ブロックの現在の支配、宣言した Conversion Type の実装、全 PE の採用、出口の稼働までは示さない。受信側の import policy は別の権限であり、受け入れ結果を保存しなければならない。

さらに Pref6 は発行元出口へ再帰解決できなければならない。到達性が失われれば規則を撤回または無効化し、古い規則で転送してはならない。MR-DB の一致と FIB の一致は別だ。正しい規則でも、ローカル経路が別地点を指せば実行は異なる。

個別規則がない場合、0.0.0.0/0: Pref6(PE) が既定出口へ誘導する。これは欠落時の連続性を作る一方、未知を積極的な選択へ変える。既定カウンタの増加は回復力かもしれず、配布欠陥かもしれない。管理境界を越える既定規則には明示的な二者合意が必要である。

既定出口には再入ループもある。復元後の IPv4 パケットは「一度枠組みを通過した」という印を持たない。出口の IPv4 最良経路が別の参加 PE に戻れば、再び IPv6 にマップされる。TTL は停止時刻を与えるだけで、ループを予防しない。出口には完全な IPv4 ビューと再入禁止が要る。

撤回も一斉ではない。新規変換から即時除去し、パイプライン中のパケットには短い猶予を許し、個別規則がなければ既定へ、なければ破棄するという段階がある。発行元、配布、各 MR-DB、FIB、パイプラインが異なる時刻を持つ。版と有効期間を記録しなければ、事故後に判断を再構成できない。

冒頭の障害はデータ面の別境界だ。IPv6 化でヘッダが増え、断片ではさらに増える。事業者ごとの MTU と ICMP フィルタが違えば PMTUD ブラックホールになる。RFC 6791は変換 ICMP の送信元を扱うが、越境配送を保証しない。規則、経路、小パケットの三つが正常でも、サービスは失敗し得る。

送信元検証も独立している。出口は、埋め込み IPv6 の接頭辞が認可入口に属し、内包 IPv4 源が方針と一致し、期待した参加網から来たかを確かめる。RFC 2827の反 spoofing 原則に沿うが、通過は事業上の権利やアプリ受領を示さない。

既存仕様との境界も明確だ。RFC 6992は単一 AS の OSPFv3、RFC 8950は IPv6 next hop 付き IPv4 NLRI、RFC 5565は Softwire Mesh を扱う。RFC 8585と RFC 9313はアクセス側 IPv4aaS を整理する。いずれも複数事業者の MR-DB 証跡を完成させない。

必要な記録は、合意と境界、IPv4 範囲と接頭辞権限、認証規則と採用判断、PE ごとの版、発行元への再帰経路、送信元検証、変換カウンタ、撤回と既定選択、出口 IPv4 ビュー、ICMP/MTU、復路、アプリ結果である。

Reality Layersは合意、主張、導入、観測を分ける。Minimum Initial Specificationは共通契約を検証可能な最小部分に留める。Running-Code Primacyは実際の版、経路、カウンタ、エラー、結果を最終証拠とする。

出典