要約

  • IESGは2026年9月4日、ステートフルNAT64の改訂をInternet Standardとして承認した。これは広い実装経験と技術的成熟の判断であり、個別製品や設備容量、フィルター設定、状態切替を認証するものではない。
  • IPv6クライアントは、限られたIPv4アドレスとポートを一定時間だけ使う。容量、継続性、帰属を説明するには、BIB、セッション、期限、フィルター、複製世代、アプリ結果を分けて残す必要がある。

IESGのProtocol Actionは、draft-ietf-v6ops-rfc6146-bis-16をInternet Standardとして承認した。完成する文書はRFC 6146を廃止し、STD 103に加わる予定である。Datatrackerでは承認アナウンス送信済み、IANA作業中となっている。確認した時点では最終RFC番号はまだ示されていなかった。

したがって、技術判断は済んでいるが、出版処理は終わっていない。この時間差を正しく書くこと自体が、状態を扱う記事の最低条件になる。

成熟度と適合性は同じ証拠ではない

承認版16は、二つの正誤をプロトコル動作の変更なしに解決し、参照を更新し、ポートの偶奇保存を明確化し、非規範的な運用考慮を加えた。RFC 6146が元の動作を、RFC 6144がIPv4/IPv6変換の枠組みを支える。

版16には多数の製品、オープンソース実装、クラウド、OSが挙げられている。ただし本文は、その一覧が公開情報に基づき、IETFの推奨ではなく、今回の出版のために正式な相互運用試験で確認されたものでもないと明記する。RFC 7942の実装状況報告も、標準化判断を助ける資料であって認証票ではない。

製品名から、稼働版、選択したオプション、実容量、ログ完全性、切替成功を導くことはできない。Running-Code Primacyの観点では、標準は実装を検証する座標を与える。個別サービスの事実は稼働コードと観測結果が与える。

共有されるのはアドレスだけではない

ステートフルNAT64は、IPv6のみのクライアントからIPv4サーバーへのUDP、TCP、ICMP通信を変換する。少数の公開IPv4アドレスを多数のクライアントが共有するため、通常はポートも変換する。

貸し出される単位はIPv4トランスポートアドレス、すなわちアドレスとUDP/TCPポートの組、またはアドレスとICMP識別子の組である。これは永続的な利用者IDではない。期限が切れれば同じ組を別のクライアントへ再利用できる。

資源が許せば元のポート範囲や偶奇を保つ。適切な組を確保できなければICMPv6エラーを返せるが、ローカル方針で抑止もできる。利用者のタイムアウトだけでは、プール不足、フィルター、無応答方針、経路、変換、IPv4サーバー、アプリのどこで終わったか分からない。

RFC 6269はアドレス共有が帰属やアプリの前提に与える問題を扱い、RFC 6888は大規模変換のログ要件を示す。版16も、ポートを動的に詰め込めば小さいIPv4プールで多くの加入者を扱える反面、ログが大きくなると述べる。

台帳には外側のアドレスとポート、プロトコル、内側IPv6タプル、割当と解放の時刻、時計誤差、装置世代、プール世代、適用規則が要る。IPv4アドレス単独は、個人でもセッションでもない。

BIBは権利、セッションは利用の記録

仕様はUDP、TCP、ICMP QueryごとにBIBを持つ。BIBはIPv6トランスポートアドレスとIPv4トランスポートアドレスの対応を保存する。別に三つのセッション表があり、実際の通信相手と状態を保存する。

一つの宛先非依存BIBが複数の宛先へのセッションを支えることがある。手動BIBは対応セッションがなくても存在し、明示的に削除されるまで残り得る。TCPセッションは過渡、確立、終了など異なる時計を持つ。BIBとセッションを一つの「NAT件数」にすると、割当と利用を区別できない。

障害切替ではこの違いがさらに重要になる。待機系が同じ外部タプルを再構成しても、内部IDと時計の世代が変わっているかもしれない。元の記録を上書きせず、継承関係として残すべきである。

Reality Layersに沿えば、「NAT64有効」は設定層、BIBは割当層、セッションはプロトコル層、変換パケットは観測層、利用者の処理完了はアプリ層に属する。一つの緑表示で全部を代表できない。

マッピングとフィルタリングを混同しない

ステートフルNAT64は宛先非依存マッピングを要求する。BIBが有効な間、同じIPv6トランスポートアドレスは複数の宛先に対して同じ外部組を使える。

しかし、IPv4側から何を戻せるかはフィルターが決める。無フィルターなら有効な割当に届く任意のIPv4送信元を通し得る。アドレス依存フィルターなら、IPv6クライアントが先に接触したIPv4アドレスに返送元を絞れる。RFC 4787がUDP、RFC 5382がTCPの動作とタイマーを定める。

「宛先非依存マッピング対応」という表示は、戻り通信の許可を説明しない。マッピング、フィルター、既定拒否か許可か、例外、静的BIB、設定版、許可元と拒否元からの実測を一組で残す必要がある。

外側の指定も権限設定である。外側から来たパケットで期限を延ばさない運用にすれば、第三者による状態維持を抑えられる。しかし外側を誤って指定すれば、正しい規則が逆向きに働く。インターフェース名ではなく、経路と実際の更新挙動を確認しなければならない。

タイマーは資源回収の決定者である

動的な割当は時計で終わる。UDPとICMPには寿命があり、TCPは状態ごとの期限を持つ。フラグメントも有限のメモリと待ち時間を使う。期限切れでポートとメモリが共用資源へ戻る。

短すぎれば正当なアイドル通信を壊す。長すぎればポートを占有し、外部から状態を延命する余地を増やす。運用節はQUICに妥当なUDP寿命が必要だとし、QUIC Connection IDをNAT状態キーにしてはならないと警告する。

監視では、生成数、更新方向、年齢、予定期限、早期削除、割当失敗、無通知破棄、フラグメントメモリ、TCP状態を構成世代別に分ける。セッション数の減少は、正常な回収にも大規模切断にも見える。理由とアプリ結果が必要である。

有限資源を集める以上、枯渇を測る

セキュリティ節は、IPv4アドレスとポート、メモリ、CPU、リンクを有限資源として挙げる。多数のIPv6送信元が割当を消費でき、フラグメントやSYNがメモリを使い、周期的なパケットが状態を保持し得る。

これは現行攻撃の報告ではない。特定事業者の障害や不足を示す資料もない。ただし、空きIPv4、ポート範囲、BIB、セッション、フラグメント領域、割当遅延、拒否と警報を別々に測る理由にはなる。

RFC 9693はステートフルNATゲートウェイのベンチマーク方法を定める。数字は装置、版、設定、トラフィック構成、パケット長、試験法に属する。他製品や他ネットワークの収容数にはならない。

Minimum Initial Specificationの考え方なら、IETFが全世界共通のプール容量を決めないのは健全である。共通層は相互運用に必要な規則を持ち、容量と障害許容は現場が決める。その現場判断には責任と証拠が伴う。

高可用性は状態の引継ぎで判定する

RFC 7269と RFC 8683はNAT64の配備経験や高可用性を扱う。ただし、特定クラスタの状態複製を保証しない。

切替前に稼働系と待機系の世代、複製水位、遅延、欠落BIB、欠落セッション、タイマー差、プール所有者を保存する。切替後は既存のUDP、TCP、ICMP通信が継続、再生成、失敗のどれになったかを測る。

分断時には二つの生存ノードが同じプールを自分のものと考える恐れもある。両方が割り当てれば一意性が崩れ、待機系が未知状態を全て捨てれば継続性が崩れる。どちらをどの範囲で守るかは経営上のサービス判断である。

帰属には世代と時計精度が要る

RFC 8158はNAT資源管理用のIPFIX要素を定め、消費や閾値を見えるようにする。ただし、BIB、セッション、加入者情報、パケット、アプリ監査を自動で一つにするわけではない。

外部タプルと時刻から内側へ、内側クライアントから外部へ、両方向で再構成する。各結合には時計差、保存方針、不確実性を残す。結果が一致しなければ、人名で空欄を埋めてはならない。

Internet Standardは翻訳動作の共通基準である。運用ログに法的な最終性を与えず、個人の操作を証明せず、アプリ処理の完了も示さない。

承認の価値は、その境界が明確であることにある。共通動作が成熟したからこそ、個別設備には比較可能な証拠を要求できる。プール、タイマー、待機系、ログは運用者が制御する。制御する主体が、結果も説明しなければならない。

出典