DHCPの4ウェイハンドシェイクとIPアドレス管理：パケット挙動の解剖からLinuxでの実践チューニングまで
家庭用ルーターという、リビングの片隅で静かに光を放つ小さな箱。その内部では、私たちが意識することすらないコンマ数秒の間に、ネットワークの生命線とも言えるドラマが繰り広げられています。デバイスがWi-Fiの電波を掴み、ブラウザを開くその瞬間、背後では何が起きているのか。今回は、IPアドレス自動割当の主役であるDHCP（Dynamic Host Configuration Protocol）のプロトコル深層に潜り、DiscoverからAckに至るまでの4ウェイハンドシェイクのパケットレベルでの挙動、そしてインフラエンジニアとして避けて通れないリース時間の設計哲学について、徹底的に解剖していこうと思います。
1. パケットレベルで紐解くDHCP 4ウェイハンドシェイクの真実
DHCPの通信は、OSI参照モデルのトランスポート層においてUDPを使用します。送信元ポートは 68（DHCPクライアント）、宛先ポートは 67（DHCPサーバー）です。まだ自局のIPアドレスが確定していないクライアントは、レイヤー2のブロードキャスト（FF:FF:FF:FF:FF:FF）とレイヤー3のIPブロードキャスト（255.255.255.255）を駆使して、ネットワーク上のサーバーへ存在をアピールします。
この一連のやり取りは、いわゆる「DORA」と呼ばれる4つのフェーズで構成されています。
[Client] [DHCP Server]
|---- 1. DHCPDISCOVER (Broadcast) -------------->|
|<--- 2. DHCPOFFER (Broadcast/Unicast) ----------|
|---- 3. DHCPREQUEST (Broadcast) -------------->|
|<--- 4. DHCPACK (Broadcast/Unicast) ------------|1. DHCPDISCOVER（ディスカバリー）
クライアントがネットワークに参加した瞬間、宛先IP 255.255.255.255:67、送信元IP 0.0.0.0:68 としてブロードキャストパケットを送信します。このパケットのペイロードには、クライアントのMACアドレス（chaddrフィールド）や、要求するオプション（サブネットマスク、ルーター、DNSなど）がOption 55（Parameter Request List）として詰め込まれています。
2. DHCPOFFER（オファー）
DISCOVERを受信したDHCPサーバー（家庭内では通常ブロードバンドルーター）は、プールされている未割当のIPアドレスから1つを選び、クライアントに対して貸し出しの提案を行います。この際、サーバーは yiaddr（Your IP address）フィールドに提案するIPアドレスを格納します。ここで注意すべきは、まだクライアントはこのIPアドレスを正式に取得しておらず、ルーティングテーブルも確立されていないため、多くの実装ではレイヤー2の宛先をブロードキャスト（またはユニキャスト）で返送することです。
3. DHCPREQUEST（リクエスト）
クライアントはオファーされたIPアドレスを受け入れる意思表示として、再度ブロードキャストで DHCPREQUEST を投げます。なぜユニキャストではなくブロードキャストなのか？ これは、同一セグメント内に複数のDHCPサーバーが存在した場合に、「どのサーバーのオファーを受諾したか」をすべてのサーバーに知らせるための仕様（サーバー選択の通知）です。選ばれなかったサーバーは、該当IPアドレスのプールを解放します。
4. DHCPACK（アック）
最後に、DHCPサーバーが DHCPACK を返し、ここで正式にIPアドレスの割り当て（リース）が完了します。クライアントはこのパケットを受け取った瞬間に自身のインターフェースへIPアドレスをバインドし、ARP（Address Resolution Protocol）による重複確認（Gratuitous ARP）を経て、晴れてネットワークの正式な一員となります。
—
2. リース時間の設計哲学とパフォーマンス・セキュリティのトレードオフ
「DHCPのリース時間なんて、デフォルトの24時間（86400秒）や1週間で十分だろう」――そう考えていませんか？ インフラアーキテクトの視点から言えば、リース時間は単なる設定値ではなく、「ネットワークの流動性」と「リソース枯渇リスク」、そして「セキュリティ（不正端末の検知スピード）」のバランスを決定づける重要なチューニングパラメータです。
短いリース時間（例: 10分〜1時間）のメリット・デメリット
- メリット: IoTデバイスの入れ替わりが激しいスマートホーム環境において、IPアドレスプールの枯渇を防ぎます。また、不正なMACアドレスを持つ端末が排除された際、速やかにIPが回収されます。
- デメリット: リース更新（T1タイマー＝リース時間の50%経過時に発生）の頻度が増え、無線LAN環境においては不要なブロードキャスト/ユニキャストトラフィックが微増します。バッテリー駆動のIoTセンサーなどでは、スリープからの復帰時にトラフィックが発生するため、わずかに消費電力に影響を与える可能性があります。
長いリース時間（例: 7日〜無制限）のメリット・デメリット
- メリット: トラフィックのオーバーヘッドが最小化され、安定した長期稼働が見込めます。
- デメリット: 固定IPのように振る舞う端末が増え、DHCPプールの回転率が低下します。特にゲストWi-Fiや一時的な訪問者のデバイスが多い環境では、アドレス枯渇（
DHCPNAKの頻発）の原因となります。
プロトコル仕様上、リース時間の50%（T1）でユニキャストによる更新要求、87.5%（T2）でブロードキャストによる再取得試行が行われます。一般的な家庭環境であれば、4時間〜12時間程度に設定するのが、リソースの流動性とトラフィック効率の最適な妥協点と言えます。
—
3. Linux環境におけるdnsmasqを用いたDHCP高度チューニングと実装
市販の家庭用ルーターのファームウェアでは隠蔽されている細かい挙動を、ご自身のLinuxルーター（OpenWrtやRaspberry Piなど）でコントロールする場合、dnsmasq や isc-dhcp-server を用いるのが定石です。ここでは、現場で即座に使える dnsmasq.conf の最適化設定例を紹介します。
# /etc/dnsmasq.conf
# 実インフラストラクチャを想定した高度なDHCP/DNSサーバー設定
# インターフェースの指定（内部ブリッジネットワークを指定）
interface=br-lan
# 外部からの誤動作を防ぐため、指定インターフェース以外からのDHCPリクエストを厳格に拒否
bind-interfaces
# DHCPプールの範囲と、リース時間を「12時間（12h）」に設定
dhcp-range=192.168.10.100,192.168.10.200,255.255.255.0,12h
# クライアントのホスト名からDNSレコードを自動生成（ローカル名前解決の迅速化）
domain=home.arpa
expand-hosts
# 固定IPの付与（MACアドレスベースでの静的マッピング）
# IoTハブやNASなど、常に同一IPを保持すべきインフラ機器の定義
dhcp-host=11:22:33:44:55:66,192.168.10.10,nas-server01
dhcp-host=aa:bb:cc:dd:ee:ff,192.168.10.20,smart-hub
# ログの詳細化（トラブルシューティング用：パケットの往来をカーネルログに吐き出す）
log-dhcp
# リース情報の永続化ファイル（再起動時にリース状態を失わないための設定）
dhcp-leasefile=/var/lib/misc/dnsmasq.leasesこの設定により、dnsmasq はバックグラウンドで効率的にIPアドレスを管理し、軽量かつ高速なDNS/DHCPフォワーダーとして機能します。
—
4. セキュリティリスクとエンタープライズ視点からの対策：Rogue DHCPの脅威
家庭内ネットワークであっても、セキュリティに対する姿勢を妥協してはなりません。DHCPプロトコルには、暗号化や認証のメカニズムが標準では組み込まれていません。つまり、悪意ある、あるいは誤って接続された不正なDHCPサーバー（Rogue DHCP Server）がネットワーク内に存在した場合、次のような深刻な被害が生じます。
1. 不正なデフォルトゲートウェイの強制: 偽のルーターIPを配布され、すべてのトラフィックが攻撃者のデバイスにルーティングされる（中間者攻撃：MitM）。
2. 悪意あるDNSサーバーの指定: 偽のDNS（例: 8.8.8.8 の代わりに攻撃者のIP）を割り当てられ、名前解決をハイジャックされてフィッシングサイトへ誘導される。
対策：DHCP Snoopingの実装
もし家庭用であってもスイッチングハブやマネージドスイッチ（L2/L3スイッチ）を導入している場合は、DHCP Snooping機能の有効化が不可欠です。
- 信頼ポート（Trusted Port）: 正当なブロードバンドルーターが接続されているポートのみを「Trusted」に設定し、そこからの
DHCPOFFERやDHCPACKのみを通過させます。 - 不信任ポート（Untrusted Port）: その他のユーザーポートや無線アクセスポイントからのサーバー側メッセージを自動的にドロップし、不正なDHCPサーバーの侵入を物理的・論理的にブロックします。
また、Wi-Fi環境においては、Client Isolation（AP隔離）を有効化することで、万が一無線LAN上に不正な挙動をする端末が紛れ込んでも、他のクライアントへの直接的なDHCPスプーフィングやARPポイズニングの伝播を防ぐことができます。
—
おわりに
普段何気なくスマートフォンをWi-Fiに接続したとき、一瞬でインターネットの海へと飛び出せるのは、裏側でこうした厳密なパケットの往来と、プロトコルの美しく調律されたハンドシェイクが存在するからです。
DHCPは、単なる「IPアドレスを配るおままわりさん」ではありません。ネットワークの入り口であり、セキュリティの最初の防壁です。パケットの挙動に思いを馳せ、自身のネットワーク環境のリース時間やルーティングを見直してみると、そこにはエンジニアリングのロマンと、確かな最適化の余地が広がっていることに気づくはずです。あなたのネットワークは、今日も正しく美しく、パケットをさばき続けているでしょうか？
コメント