要約

  • Remco van Mookが著者のINTAREA作業部会ドラフトは、192.0.0.11/32をセンチネル型IPv4ゲートウェイとして提案する。対応ホストはARPせず、選択したIPv6デフォルトルーターのMACを使う。
  • パケットはトンネル化も変換もされず、ネイティブIPv4のままである。一方、戻りにはホストのIPv4 /32と、ルーティング可能なIPv6次ホップが必要になる。
  • DHCP、RA、NUD、IPv4転送、戻り経路、旧ホスト向けARP応答は同じ成功条件ではない。機構を共有しても、証拠まで一つにはならない。

宛先ではなく動作を示す番号

この方式では、ルーティング表にある数字を装置の住所だと考えると誤る。192.0.0.11に実在のIPv4インターフェースは必要ない。ホストのスタックに対し、「このデフォルトルートだけは、IPv6のデフォルトルーター一覧を調べよ」と伝える制御値である。

アプリケーションはIPv4 socketを使い続け、ホストもIPv4パケットを生成し、ルーターもIPv4として転送する。選ばれたIPv6ルーターのNeighbor Cacheからリンク層アドレスを取り、そのMAC宛てにIPv4フレームを送る。NAT64ではなく、IPv6カプセル化もない。変わるのはローカルリンクの解決方法だけだ。

文書は2026年8月にINTAREA作業部会のドラフトとなった。Windows 11、macOS、Android、iOS、Linux、FreeBSD、ChromeOSで、アプリケーションやDHCPv4設定の変更なしに確認したと報告している。ただし、これは著者側の検証結果であり、独立した認証表ではない。Internet-Draftは変更され得るため、提案中のセンチネルを確立済みの標準として扱ってはならない。

最初のRAを待つ時間

DHCPでセンチネルを受け取っても、IPv6 Router Advertisementがなければ借りる相手がいない。最初のRA以前にIPv4パケットを保持するなら、その時間と量には上限が必要である。無期限に待つ状態は到達性ではない。

複数のルーターがある場合、RFC 4191のpreference、到達性、実装固有の判断の順で候補が絞られる。選択先が変わればIPv4ルートも再評価され、既存セッションが切れる可能性がある。IETF 126でLorenzo Colittiは、IPv6経路の増減に追随し損ねる実装がIPv4を壊す危険を指摘した。Van Mookは追随が必要だと答えている。

Neighbor Cacheにも有効期限と状態がある。RFC 4861のreachable、stale、delay、probeはいずれも同じ確度ではない。MACが残っていても相手がIPv4を転送している保証にはならず、転送能力のある機器でもRAやNDの状態が失われれば利用できない。

戻り経路には別の住所が要る

ホストから最初のルーターへ出すだけなら、IPv6 link-localアドレスで足りる。ところがルーター間の次ホップにlink-localをそのまま持ち出せない。ネットワーク側は、そのホスト固有のIPv4 /32を、到達可能なIPv6 GUAまたはULAの次ホップと組み合わせて広告する必要がある。

RFC 8950はBGPでIPv4 NLRIにIPv6次ホップを付ける形式を標準化している。v4-via-v6ドラフトはルーター間の転送をさらに扱う。ホスト側のセンチネルと合わせて初めて往復の構図になるのであり、片方が他方を自動的に成立させるわけではない。

したがって、外向きのping成功は部分証拠にすぎない。正しいDHCP値、意図したRA、選択ルーターのMAC、ネイティブIPv4転送、そして遠方から戻る/32の経路を別々に確認する必要がある。

/32が余計なARPを封じる

IPv4アドレスに広いプレフィックスを付けると、ホストは他のアドレスをオンリンクと判断し、再びARPを始める。/32は割当量の問題ではなく、隣接の境界である。センチネルをルーティングへ注入したり、転送パケットの送信元・宛先として使ったりしてもいけない。

ドラフトは、Hetzner、OVH、Scalewayにおける単一IPv4とオフリンクゲートウェイの運用を先例として挙げる。現状ではOS別の回避設定が必要だという。これは共通動作への需要を説明する事例であって、三社が新方式を導入済みだと独立確認したものではない。

RFC 8925のIPv6-Only Preferredは、対応端末にIPv6-onlyを選ばせる。今回の方法は別の場所を埋める。IPv6中心のアクセス網でも、dual-stack端末へネイティブIPv4を残したい場合である。二つの仕組みは併用できるが、試験項目は共有できない。

互換モードは別のサービス

未対応ホストは192.0.0.11を普通のゲートウェイだと解釈し、ARPを送る。ドラフトはルーター自身のMACで応答することを推奨する。新方式と旧方式を同じセグメントに置ける点は、段階導入に有利だ。

ただし、旧ホストが動いたからといってIPv6から借りる経路が正しいとは限らない。新ホストの成功も、ARP互換層の健全性を示さない。二つの集団を同じ可用性数字へ混ぜると、片方の失敗を片方が隠す。

IETF 126でTobias Fiebigは、DHCPv4をDHCPv6で運ぶ案と比べてエレガントだと評した。これは線上の構成要素が少ないという意味である。選択、近隣、転送、戻りという状態まで少なくなるわけではない。

実装が示す到達点と未到達点

v4-with-v6-nhにはLinux向けユーザー空間デーモンがある。センチネルを見つけ、RFC 4191に基づきルーターを選び、IPv6次ホップを持つIPv4デフォルトルートを導入し、変化に追随して不要になれば削除する。Linuxカーネルは5.2以降、この表現を扱える。

しかし最初のRAまで個々のパケットを待たせることはできず、起動時の挙動は近似になる。systemd-networkdはパッチ段階で、FreeBSDは構文確認のみ、商用ルーター設定は実機未検証、タグ付きリリースもない。動くコードは設計の実現可能性を示すが、製品成熟度を代弁しない。

必要な試験は定常時より状態遷移にある。DHCP期限切れ、最初のRAの遅延、優先ルーターの撤退、staleな近隣、戻り/32の消失、同一preferenceの競合、新旧ホストの混在を意図的に起こすべきだ。

信頼はARPからRAへ移る

ARPをなくせば、対応ホストでのなりすまし面と運用雑音は減る。第一ホップの信頼自体は消えず、RAとNDへ移行する。誤ったRAはIPv4に使うMACを変え、ND障害は二つのアドレス族を同時に止め得る。

RA Guard、信頼する接続点、近隣状態の検査、明示的なルーターpreferenceがIPv4保護にもなる。もっとも危険なのは、機構の片側しかないセグメントでDHCPがセンチネルを配ることだ。IPv4は静かに失敗する。オフリンクゲートウェイを不正とみなすDHCP検証により、さらに手前で拒否される場合もある。設定受理と転送可能性は一つのランプにまとめられない。

出典