要約

  • DHCPv4で/32を配り、ルーターオプションを省けば、旧式端末への応答を続けながら通常のリンク外IPv4経路をなくせる。
  • 再要求は減り得るが、端末ごとの固有リースは残り、同一リンクの別ホストからパケットが届く余地もある。

要求が静まっても、アドレスはプールへ戻らない

古いデュアルスタック端末は、運用者がアプリケーションをIPv6へ移そうとしていても、IPv4を求め続けることがある。DHCPv4への応答を止めるだけでは、応答のない要求が繰り返されるかもしれない。LACNICが10月2日に公開した技術ブログは、個人Internet-Draftにある、より限定的な方法を紹介している。端末が理解する従来のDHCPv4項目で応答し、そのインターフェースに通常のリンク外IPv4経路を与えない。

DHCPv4オプション1で255.255.255.255、つまり/32のサブネットマスクを渡す。サーバーはルーターを知らせるオプション3を配らない。/32を受けた端末は、ほかのIPv4宛先をリンク外と判断する。ルーター情報もないため、そこへ送る次の経路がない。端末は求めた設定を受け取り、再探索を止める可能性があるが、リンク外へ届くIPv4経路を得るわけではない。

これはIPv4を完全に無効化する方法ではない。設定対象のインターフェースにはIPv4アドレスがあり、DHCPv4も動作する。別インターフェース、手動経路、トンネル、異なる挙動のアプリケーションが存在する場合もある。IPv4接続の失敗後にIPv6を試すアプリケーションはあり得るが、draftが説明するのは期待される挙動で、すべてのOSやサービスへの保証ではない。

端末ごとの一意なリースが必要

draftが強調するのは、静かな端末にも割り当てが残るという点だ。同一リンク上では、DHCPv4サーバーは各端末に一意なIPv4アドレスを渡す必要がある。通常、同じセグメントの全端末で一つのアドレスを共有することはできない。アドレス重複検出が利用前にプローブすることがあり、二つの端末が同じアドレスを受け取れば競合が見つかる。draftは、同じ競合アドレスを繰り返し再配布するとDHCPDECLINEのループにつながり得ると警告している。

したがって、要求の騒がしさが下がっても割り当ては続く。端末が解放するか、動的リースの期限が切れるまで、サーバーのプール内で一枠を占める。RFC 2131が定める動的割り当ては期限付きで、不要になれば再利用できる。アクティブなリース記録は通信量の測定ではなく、アドレスが再び利用可能になった証拠でもない。

コストはどのプールを使うかで変わる。希少なパブリックIPv4を割り当てれば、端末が通常の経路で外部へ出られなくても、稼働中のリースには機会費用がある。draftはリンクローカルやRFC1918のプールも挙げる。専用のプライベートプールならパブリックアドレスを温存できるが、端末ごとの固有アドレス、サーバー上のリース状態、競合処理、既存のプライベートアドレス設計との重複確認は残る。

異なる物理リンクで同じプールを使えるのは、DHCPサーバーが各リンクに直接接続される場合など、条件が限られる。relay経由ではサーバーがrelayのアドレスでプールを選ぶため、draftは中継網全体での一意性を求める。この境界を無視すれば、帳簿上の節約がアドレス選択の障害になる。

リースを長くすると、更新は減り、占有は延びる

draftは、外部IPv4通信を想定しない端末には1日から数週間のリースも考えられるとしている。更新回数やサーバー負荷は下がるが、アドレスの確保期間は長くなる。希少なパブリックプールではDHCPメッセージが減っても空きアドレスが増えるとは限らない。要求率とアドレス占有日数を並べて測る必要がある。これはリースの仕組みから導く運用上の推論で、ブログの実測結果ではない。

Option 108は別の端末群への別の選択肢だ。RFC 8925は、対応端末と明示的に設定されたIPv6-mostlyネットワーク向けにIPv6-Only Preferredを標準化している。両側が対応すれば、必要なIPv6機能がある環境で端末はIPv4アドレスを辞退でき、プールを温存しやすい。/32方式はOption 108を理解しない旧端末向けとされ、draftは両方の併用を認める。どちらも、アプリケーションやDNS64/NAT64、必要なサービスの動作を単独では証明しない。

デフォルト経路がなくても受信はあり得る

ルーターオプションを省くと、リンク外IPv4の通常経路はなくなる。しかし同一リンクの端末から見えなくなるわけではない。draftのセキュリティ節は、別のホストが/32端末にIPv4パケットを送れる場合があると明記し、DHCPv4をクライアントとサーバーまたはrelay間だけ許可するホストファイアウォールを推奨している。

「リンク外へ通常のIPv4接続を開始できない」と「IPv4パケットを受信できない」は異なる。前者は提案された経路設定から導けるが、後者は導けない。ローカルサービスが残る場合や、別経路から端末に到達できる場合には、受信側の方針を明示する必要がある。

公開資料が示す範囲

LACNICのブログによれば、著者Alejandro AcostaはWindows 11、Fedora 43、Debian TrixieベースのRaspberry Pi OS、Chromecast、Google Nestで試したという。一方、スマートフォンは試しておらず、さらに互換性を検証する必要があると記す。これは著者が報告した試行であって、独立した再現試験、代表的な端末調査、商用展開の証拠ではない。ブログは、著者の意見がLACNICの見解を必ずしも示すわけではないとも明記している。

引用された文書は個人Internet-Draftの02版だ。IETF Datatrackerは2026年6月15日に失効し、IETF標準化プロセス上の正式な地位はないと記録する。失効だけで技術的に否定されたとはいえず、draftの存在だけで承認済み標準になるわけでもない。確認した公開資料にはDHCPブロードキャストの実測低下、プール占有の推移、アプリケーションのIPv6切替結果、入信セキュリティ監査はない。

運用者が試験するなら、対象群の反復要求数、パブリック・プライベート・リンクローカル別の稼働リースと占有日数、解放・期限切れ・DHCPDECLINE、relayとリンクの境界、抽出したアプリケーションのIPv6成功、入信ファイアウォール方針を分けて公表すべきだ。リンクが静かになること、希少アドレスが空くこと、アプリが動くこと、受信面が守られることは別の成果である。

出典：