DHCP Offer の仕組みとその通信の実態について
この記事では、ネットワークにおける DHCP通信の流れと仕組みについて解説します。
DHCPとは何か？
私たちが普段使っているスマートフォンやPCがWi-Fiに接続できるのは、背後で「ネットワーク設定」が自動で行われているからです。その設定を行ってくれるのが DHCP（Dynamic Host Configuration Protocol） という仕組みです。
たとえば、スマートフォンを家庭のWi-Fiに接続する場面を考えてみましょう。このとき、スマートフォンは自分専用のIPアドレスを持っていない状態です。そのままではネットワーク通信ができません。DHCPは、そんなスマートフォンに対して、IPアドレスやデフォルトゲートウェイ、DNSサーバなどの情報を自動で割り当ててくれる役割を果たします。
言い換えれば、DHCPは「新しくネットワークに接続された機器が、ネットワークの一員として正しく機能できるようにする」ための最初のやりとりを担う重要なプロトコルです。
DHCPの通信の基本的な流れ
IPアドレスを保持していないクライアントは、ネットワークに接続されると DHCP Discover（ブロードキャスト） を送信します。それに対して、ネットワーク内に存在するDHCPサーバ（通常はルーターなど）が DHCP Offer を返します。
この Offer に対して、クライアントは DHCP Request を送り、最終的に DHCPサーバは DHCP ACK を送ることで、設定が確定します。
この4段階のやりとりをまとめると、以下のようになります：
| 送信元 | パケット | 内容 | 宛先 |
|---|---|---|---|
| クライアント | DHCP Discover | IP欲しいですー | IP: 255.255.255.255 / MAC: FF:FF:FF:FF:FF:FF |
| DHCPサーバ | DHCP Offer | このIPどう？ | IP: 255.255.255.255 / MAC: クライアントのMAC |
| クライアント | DHCP Request | そのIPもらいます！ | IP: 255.255.255.255 / MAC: FF:FF:FF:FF:FF:FF |
| DHCPサーバ | DHCP ACK | OK、使っていいよ！ | クライアントの新IP（今後の通信用） |
各通信の役割について詳しく見ていく
1. DHCP Discover
IPアドレスを持たないクライアントが、LAN内にいるDHCPサーバに向けて「誰かIPアドレスをください」とブロードキャストを送信します。クライアントは自分のIPアドレスがないため、送信元IPには「0.0.0.0」を、宛先IPには「255.255.255.255（ブロードキャスト）」を使用します。
このパケットは、同じLAN内のすべてのデバイスに届きますが、実際に応答するのはDHCPサーバだけです。MACアドレスはNICに固有のものであり、サーバはそれを基に応答先を判断します。
2. DHCP Offer
DHCPサーバは、Discoverを受信すると「このIPアドレスを使ってみては？」という提案（Offer）を返します。これはまだ確定したIPアドレスではなく、あくまで仮の提示です。
このパケットは宛先IPにブロードキャスト（255.255.255.255）が使われますが、宛先MACアドレスにはDiscoverで受け取ったクライアントのMACが指定されます。これにより、IPレベルではブロードキャストでも、イーサネットレベルではユニキャストとなるため、クライアントにのみ届く仕組みになっています。Offerの中には、提案されたIPアドレス、サブネットマスク、デフォルトゲートウェイ、DHCPサーバ識別子、DNSサーバの情報などが含まれています。
補足
IPアドレス（Assigned IP Address）
DHCPサーバがクライアントに対して提供するIPアドレスです。これはまだ仮のIPであり、クライアントがRequestでそのIPを選択した場合、正式に割り当てられます。このIPアドレスは、ネットワーク内で他のデバイスと重複しないようにDHCPサーバによって管理されています。
デフォルトゲートウェイ（Default Gateway）
クライアントが同じネットワーク内で通信できない相手、例えばインターネットの外部にアクセスするために使用するルーターのIPアドレスです。デフォルトゲートウェイは、ネットワーク内の外部通信の出発点として機能します。
DHCPサーバ識別子（DHCP Server Identifier）
DHCPサーバのIPアドレスであり、クライアントがどのDHCPサーバからOfferを受け取ったかを識別するために使用されます。複数のDHCPサーバが存在する場合、クライアントがどのサーバの提案を選択したかを識別するために重要です。この識別子は、Requestメッセージでサーバに対して「このサーバのOfferを選んだ」という意思を伝えるために使われます。
3. DHCP Request
クライアントが、Offerで提案されたIPアドレスを実際に使いたいという意思を示すのがRequestです。この段階では、複数のDHCPサーバが存在する可能性があるため、Requestパケットには「どのサーバからのOfferを受け入れるか」をDHCPサーバ識別子として明示されます（通常は"Server Identifier"として指定）。
このパケットは再びIPアドレスとしてはブロードキャスト（255.255.255.255）を指定して送信されます。ただし、イーサネット（MAC）レベルでもブロードキャスト（FF:FF:FF:FF:FF:FF）になるため、LAN内のすべてのDHCPサーバに届きます。これにより、他のサーバは「このクライアントは別のサーバのOfferを選んだ」と判断し、自分が提案したIPアドレスの割り当てをキャンセルします。
4. DHCP ACK
DHCPサーバはRequestを受け取ると、その内容を確認し、クライアントが要求してきたIPアドレスを正式に割り当てたことを知らせるACK（Acknowledgement）を送ります。このACKには、IPアドレスの有効期間（リース期間）や、ネットワーク設定が改めて含まれています。
このパケットは、すでに提案されたIPが一時的に有効になっているため、宛先IPとしてそのアドレスを使用してユニキャストで送られることもあります。これにより、クライアントは正式にネットワークに参加し、他の通信（インターネットアクセスなど）が可能になります。
このようにして、クライアントはDHCPを通じて自動的にIPアドレスなどの情報を取得し、インターネットを含むネットワークへのアクセスが可能になります。