DHCPACKとは、RFC 2131で定義されているように、DHCPサーバーがアドレスのリースを確認し、最終的な設定パラメータをクライアントに送信するために送る、ダイナミック・ホスト・コンフィギュレーション・プロトコル(DHCP)の確認応答メッセージです。これは、標準的な4メッセージからなるDHCP交換における最後のメッセージであり、リースが有効になり、デバイスが正常にネットワークにアクセスできるようになる瞬間です。 アドレスプールの枯渇、リレーエージェントの設定ミス、サーバーの障害、ファイアウォールによるブロックなどの原因でDHCPACKメッセージの送信が遅れたり欠落したりすると、クライアントはネットワーク接続の途絶を経験し、リンクローカルアドレスに切り替わってしまう可能性があります。そのため、ネットワーク運用者がプールの枯渇を検知し、接続性の問題をトラブルシューティングするためには、DHCPACKアクティビティの正確なログ記録と監視が不可欠となります。
DHCPACKの仕組み
DHCPACKは、新しいリースに関する標準的な4メッセージからなるDHCP通信における最後のメッセージです。また、クライアントがリースを更新する場合や、設定パラメータのみを要求する場合にも使用されます。
- Discover:クライアントは、利用可能なDHCPサーバーを見つけるためにDHCPDISCOVERをブロードキャストします。
- オファー:応答した各サーバーは、提案されたアドレスと設定オプションを含む DHCPOFFER を送信します。
- リクエスト:クライアントはオファーの中から1つを選択し、選択したサーバー名を指定したDHCPREQUESTをブロードキャストします。これにより、他のサーバーに対してもそのオファーが拒否されたことが通知されます。
- 確認応答(Acknowledge):選択されたサーバーはリースを記録し、アドレス、リース期間、およびオプションを含むDHCPACKを送信します。これにより、クライアントはインターフェースを設定し、そのアドレスの使用を開始できます。
アドレスを使用する前に、クライアントは、例えばARPなどを用いてネットワークを調査し、他のホストがそのアドレスを保持していないことを確認する場合があります。そのアドレスがすでに使用中の場合、RFC 2131では、クライアントがDHCPDECLINEを送信し、最初からやり直すことになっています。 サーバーが要求に応じられない場合、DHCPACKの代わりにDHCPNAKを送信します。DHCPACKはDHCPINFORMへの応答としても使用されますが、その場合はオプションを含みますが、アドレスは含みません。
DHCPACKに関する一般的な問題
リモートサブネット上のクライアントはリクエストを送信するものの、リレーエージェントのgiaddrが間違っているか欠落している、あるいは返信トラフィックがブロックされているため、DHCPACKを受信できません。サーバーのログには確認応答が送信されたことが記録されていますが、クライアントのログにはリクエストが繰り返し行われていることが示されています。
停電やWi-Fiローミングストームの後、多くのクライアントが同時にリクエストを行い、過負荷状態のサーバーや処理が遅いバックエンドデータベースによってDHCPACKの送信が遅延します。クライアントはタイムアウトとなり、再試行を行い、場合によってはリンクローカルアドレスに切り替わることがあります。
不正なDHCPサーバー(多くの場合、スイッチに接続された家庭用ルーター)が、誤ったゲートウェイやDNSサーバーを指定した独自のDHCPACKを送信します。ユーザーはローカルでは機能するIPアドレスを取得しますが、他のネットワークには接続できません。
クライアントは DHCPACK 後にそのアドレスを調査し、すでに使用中であることを確認してリースを拒否します。これは通常、動的範囲内に静的設定のデバイスが存在することが原因であり、サーバーのログには繰り返し拒否される記録として現れます。
信頼されていないポートでのセキュリティポリシーやDHCPスヌーピングにより、サーバーからのDHCPACKが破棄されるため、サーバーはクライアントが認識することのないリースを記録してしまいます。サーバーに接続するポートが信頼済みであり、UDPポート67および68が許可されていることを確認してください。