要約

  • IESG はステートフル NAT64 仕様の第16版を Internet Standard として承認したが、承認文書はマッピング動作と受信フィルタリングを明確に分けている。
  • 運用記録は、外部タプルの再利用と送信元の許可を別々に保存し、プロトコル、方向、実装結果まで結び付ける必要がある。

障害が起きていない変更審査ほど、誤解は見逃されやすい。同じ IPv6 アドレスとポートから複数の IPv4 宛先へ通信し、バインディングが生きている間は同じ外部 IPv4 アドレスとポートが割り当てられた。端点非依存マッピングの試験としては合格である。

ところが議事録には「未承認の IPv4 送信元からは到達不能」と書かれた。その試験は行われていない。既定の拒否動作も、投入済みのフィルターも、インターネット側のインターフェースも記録されていない。「同じタプルを使う」という割当ての性質が、「誰を通すか」という権限判断にすり替わった。

2026年9月4日、IESG は Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers の第16版を Internet Standard として承認し、STD 103 に収めるよう RFC Editor に求めた。発表は、ステートフル NAT64 が広く実装・導入され、文書が RFC 6146 を置き換える予定だと説明する。大きな論争は確認されなかったとも記している。

ただし、承認と刊行は同じ日付ではない。本稿の調査時点でDatatrackerは第16版を RFC Editor Queue に置き、著者からの入力待ちでブロック中と表示していた。履歴は承認までの経過を示すが、最終的な後継 RFC 番号はまだ存在しない。

また、承認を新しいパケット動作の導入と表現するのも正確ではない。発表は errata 4756 と 8416 を編集上または説明上の修正と位置付け、互換性やプロトコル動作を変えないとしている。第16版の付録 A も同じ境界を置く。RFC 6146は刊行までの歴史的基準である。今回読み直すべきなのは新機能ではなく、以前から別物だった二つの制御である。

マッピングは外側の表現を決める

ステートフル NAT64 は、IPv6 側のトランスポートアドレスと IPv4 側のトランスポートアドレスを対応させる。TCP と UDP では IP アドレスとポートの組がタプルとなり、セッションが止まりタイマーが切れれば動的な対応は解放される。

端点非依存マッピングでは、同じ内側のアドレスとポートが異なる外部宛先と通信しても、バインディング期間中は同じ外部タプルを再利用する。RFC 4787は UDP NAT にこの動作を要求し、ピア・ツー・ピアやトラバーサルの予測可能性を高める。一方で、マッピング方式は NAT のセキュリティ特性を決めず、許可されるパケットはフィルタリング動作で決まると明記している。

RFC 5382も TCP で両者を分ける。外部タプルを学習して他のピアへ伝えられても、外からの接続は NAT のセキュリティ方針に従う。つまりマッピング試験は、宛先が変わったときに割当てが変わるかを測る。送信元の許可集合は測っていない。

承認された草案は、端点非依存マッピングを必須能力とし、アドレス依存マッピングの追加実装も認める。能力があることと、あるインターフェースで選択されたことは別である。さらに、選択されたマッピングから既定のフィルターを逆算することはできない。

フィルターは既存の状態を誰が使えるか決める

第16版は、同じマッピングでも二つの結果があり得ると説明する。フィルタリングがなければ、対応する外部タプルへ送る IPv4 ノードのパケットは NAT64 を通り、内側の IPv6 トランスポートアドレスへ転送され得る。

フィルタリングがあれば、外部送信元は規則と照合される。動的なアドレス依存フィルターなら、IPv6 ホストが先に通信した IPv4 アドレスからの返送だけを認められる。明示的拒否や既定拒否も使える。マッピングの種類を変えずに、到達できる送信元を狭められるのである。

常に狭い方が正しいわけではない。RFC 4787 は、アプリケーション透過性を優先する場合は端点非依存フィルタリング、厳格さを優先する場合はアドレス依存フィルタリングを推奨し、管理者が設定できる選択肢として扱う。RFC 5382 は TCP の設定が UDP と異なってもよいとする。製品全体に一つの「独立」ラベルを貼れば、この選択は消えてしまう。

ICMP では用語の横流しがさらに危険である。RFC 5508はポートの代わりに Query Identifier を用いる。erratum 4756 の整理は、対象となる処理に TCP/UDP と同様のアドレス依存フィルタリング規則がないことを明確にした。UDP のテスト行を ICMP にコピーしても、比較可能な証拠にはならない。

静的バインディングは曖昧な証拠を許さない

セキュリティ節は、静的マッピングでは五つ組だけのフィルタリングが推測されやすい場合があると警告する。TCP のシーケンス番号を追跡し、SYN や FIN の順序を確かめる実装も可能だが、これは任意の追加策である。静的タプルが存在することは、その防御の有無を証明しない。

資源も有限だ。IPv4 のアドレスとポート、バインディング表、セッション表、フラグメント用メモリ、回線容量は枯渇し得る。草案はフラグメント保存の上限や、状態寿命の防御でどちらを外部側と扱うかを正しく設定する必要を述べる。方向、プロトコル、タイマー、静的・動的・PCP という状態の由来を欠く証拠は、運用判断に再利用できない。

RFC 7269は高可用性やセキュリティを含む NAT64 の導入経験を扱い、RFC 8683は NAT64/464XLAT の展開指針を示す。いずれも翻訳器を単独の箱ではなく運用システムとして見る。しかし、マッピングをフィルターの証明としてはいない。

二つの判断を一枚の受領書に残す

Daniel Kade が提案するマッピング・フィルタリング判断受領書は、項目を混ぜずに関連付ける。翻訳器、ソフトウェア版、インターフェースと方向、プロトコルを特定したうえで、マッピング方式、フィルタリング方式、既定動作、静的・動的・PCP の状態由来、各タイマー、方針版、承認者、資源上限、例外期限を別々に記す。

実測も二系統にする。複数宛先への送信で外部タプルの再利用を確認する。別の正負試験で、許可済みと未許可の IPv4 送信元が通るかを確かめる。投入済み規則、カウンター、アラーム、フェイルオーバー後の再試験が、意図と実装をつなぐ。

これは製品認証でも無期限の安全宣言でもない。この版、この方向、このプロトコルでは、このように割り当て、このように通過を判断した、という限定的な記録である。更新、方針変更、役割変更、タイマー調整、新しい静的対応、切替えが起きれば、該当部分を失効させる。

The Policy Mirrorが問うのは規則が効力を持つ場所である。マッピングは割当てで、フィルターは受信経路で効く。Running-Code Primacyに従えば、双方の実測が要る。Reality, Not Advocacyに従えば、標準の選択肢から未調査の事業者の欠陥を推定してはならない。

出典