要約

  • IPv4 as a ServiceはIPv4依存を消さず、DNS64、プレフィックス発見、CLAT、PLAT状態、共有ポートへ移す。
  • ネイティブIPv6が正常なまま、IPv4専用名、リテラル、切替前から続く変換セッションだけが失敗し得る。
  • 運用証拠にはリゾルバー応答、Pref64、CLAT経路、PLAT状態と切替、時刻付き帰属、非対応の受信条件が必要だ。

家庭用ゲートウェイのDNSを利用者が変更する。IPv6ネイティブのサービスは開くが、Aレコードしか持たない宛先は合成AAAAを得られず到達不能になる。別の端末は同じ宛先へ接続できる。CLATがIPv4パケットを受け、別の方法で事業者の変換プレフィックスを学習しているからだ。どちらの回線も「接続中」だが、互換性の実体は異なる。

これがIPv4-as-a-Service、IPv4aaSの運用面である。アクセス網やコア網からネイティブIPv4を外しても、変換によりIPv4サーバーへの到達性を残せる。ただし、互換性は一利用者に端から端まで渡すアドレスではなく、リゾルバー、端末、宅内ルーター、経路制御、事業者の変換器が分担するサービスになる。

合成アドレスは経路への約束にすぎない

RFC 6147はDNS64を定義する。AAAA問い合わせに対して宛先がAレコードしか持たない場合、DNS64はIPv4アドレスをIPv6変換プレフィックスPref64::/nへ埋め込み、合成AAAAを返せる。クライアントはそのIPv6アドレスへ送信する。

ただし、合成に使ったプレフィックスが同じ規則を持つNAT64へルーティングされなければ意味がない。リゾルバーと変換器は問い合わせごとに合意を取り直すわけではない。DNS成功が示すのはアドレス生成であり、PLATの容量、プレフィックス一致、既存セッションの継続ではない。

DNSSECとの関係も設計項目になる。DNS64は回答を変え、DNSSECは不正な変更を検出する。検証と合成の場所を意図的に置けば両立できるが、証跡にはリゾルバー、A/AAAA、検証結果、使用したPref64を残す必要がある。

CLATは古い前提の一部を救う

RFC 6877の464XLATでは、端末または顧客側ルーターのステートレスCLATがIPv4をIPv6へ変換し、事業者側のステートフルPLATがIPv4へ戻す。名前を使うアプリはDNS64経由で一回のステートフル変換を利用できる。IPv4リテラルや古いAPIを使うアプリにはCLATが最初の変換を提供する。

そのため、外部リゾルバーへの変更が同じ障害を生むとは限らない。RFC 8683によれば、NAT64だけでCLATがないネットワークでは、DNS64をしないリゾルバーに替えるとIPv4専用宛先を失い得る。464XLATならDNS64がなくてもCLATが正しいPref64を見つければ二重変換で動ける。一方、別プレフィックスを合成するリゾルバーは予定したPLATから経路を外す可能性がある。

464XLATは完全なネイティブIPv4の代替ではない。RFC 6877の基本範囲はグローバルIPv4サーバーへのクライアント・サーバー通信であり、一般的なIPv4受信や任意のP2Pを自動的に提供しない。その制約は製品説明と障害分類に明示すべきだ。

Pref64には寿命とスコープがある

RFC 8781はIPv6ルーター広告のPREF64オプションを定める。プレフィックス長と有効期間を運び、期間ゼロは利用停止を意味する。ホストは受信インターフェース固有、対応する場合はProvisioning Domain固有として扱う。同一リンクの広告が不整合なら、ルーターは検出して記録すべきとされる。

したがって、記録するのは「Pref64あり」だけではない。発見方法、値、残存期間、インターフェースまたはPvD、広告の一貫性が必要だ。古い値が退役済み変換器を指し続けることも、短い寿命が次の有効広告より先に切れることもある。

冗長機はセッションを自動で引き継がない

RFC 6146のステートフルNAT64は、戻りパケットをIPv6クライアントへ結び付けるバインディングとセッション状態を持つ。断片パケットが資源を使い尽くさないよう上限も必要だ。しかし、二台の変換器が活動中の状態を共有することまでは保証しない。

切替後に新規接続が成功しても、長いダウンロード、決済、トンネルはリセットされ得る。切替後に新しいTCPだけを開く監視は復旧と判定してしまう。試験では同じセッションを切替前後に通し、活動PLAT、状態余力、切替イベント、既存マッピングの期待動作を記録する必要がある。

RFC 9099は、状態枯渇、DNSSECとの相互作用、UDPカプセル化なしの多くのIPsec利用への影響を示す。DNS64なしの464XLATは合成問題を避けられるが、その他の変換境界は残る。

アドレス節約は帰属台帳を事業者へ移す

RFC 9313は五つのIPv4aaS技術を比較する。464XLATでは、事業者NAT64がフロー状態を持ち、公開ポートを動的に割り当てる。IPv4アドレスを効率的に共有できる代わりに、状態容量、復旧、ログが集中する。

一つの公開IPv4を複数利用者が共有すれば、アドレスとポートの帰属には時刻付きマッピングが要る。全セッション記録は詳細だが重い。一定時間ポートブロックを割り当てればログを減らせるが、ポート効率は下がる。法制度も関係し、RFCは世界共通の保存期間を定めない。

事業者側状態だけでは公開受信ポートも得られない。サーバー用途にはPCPや明示マッピングが必要な場合がある。これは偶発障害ではなく契約上の境界である。

資料は2026年の世界的利用率、普遍的な性能改善、典型障害率を示さない。示すのは、検証可能な制御の連鎖だ。

出典

  1. RFC 6146 — Stateful NAT64
  2. RFC 6147 — DNS64
  3. RFC 6877 — 464XLAT
  4. RFC 8683 — NAT64/464XLATの展開指針
  5. RFC 8781 — ルーター広告によるPREF64発見
  6. RFC 9099 — IPv6ネットワークの運用セキュリティ
  7. RFC 9313 — IPv4aaS技術の比較