DHCP とは｜IP アドレスを自動取得する仕組みと取得後の確認

はじめに

企業のネットワークでは、PC、スマートフォン、プリンターへ 1 台ずつ IP アドレスを手作業で設定する運用は現実的ではありません。DHCP（Dynamic Host Configuration Protocol）は、端末が通信に必要とする設定情報をサーバー側でまとめて管理し、端末の接続時に自動で配布する仕組みです。

一方で、実務では「IP アドレスは取得できているのに通信できない」という問い合わせが発生します。DHCP が何を配り、その値が端末のどこへ反映されるかを押さえておくと、取得までは正常と判断したうえで、次に確認すべき箇所へ進めます。

結論として、DHCP サーバーは IP アドレスに加えて、サブネットマスク、デフォルトゲートウェイ、DNS サーバー、リース時間をまとめて配布します。端末はブロードキャストを使った Discover から ACK までのやり取りでこれらを受け取り、自身の設定として反映します。ただし、IP アドレスを取得できたことは、目的の通信が成立することの保証ではありません。

本記事は IPv4 向けの DHCP（DHCPv4）を対象とします。IPv6 で使う DHCPv6 は、Solicit・Advertise・Request・Reply といった別のメッセージを使う仕組みのため、本記事の流れをそのまま当てはめることはできません。

DHCP が配布する情報と関係する機器の役割

DHCP の動作を理解する前に、登場する要素と、配布される情報の中身を整理します。ここを押さえておくと、後述する取得後の確認がそのまま設計値の照合になります。

クライアント・サーバー・アドレスプール・リースの関係

DHCP クライアント

設定情報を要求する端末側の機能です。Windows では、アダプターの設定が「IP アドレスを自動的に取得する」になっている状態が該当します。

DHCP サーバー

要求に応じて設定情報を返す側です。専用サーバーのほか、ルーターやファイアウォールの内蔵機能として動作する構成もあります。ルーターに持たせる場合の設定は、『Cisco ルーター DHCP サーバー設定｜固定 IP 割り当ての落とし穴と対処』で扱っています。

アドレスプール（スコープ）

配布対象として定義した IP アドレスの範囲と、あわせて配る情報の設定をまとめた単位です。呼び方は製品によって異なります。

リース

割り当てを期限付きで貸し出す考え方です。どの端末にどのアドレスをいつまで割り当てたかは、サーバー側が記録します。

配布される主な情報と、端末側での用途

DHCP で配布される代表的な情報と、端末がそれを何に使うかは次のとおりです。運ばれ方の列は、パケットを確認するときの対応付けに使えます。

割り当てられる IP アドレスだけは、オプションではなくメッセージ本体のフィールドで通知されます。すべてをオプションとして覚えると、キャプチャを読むときに表示と対応が取れなくなります。サブネットマスクの読み方に不安がある場合は、『IP アドレスとサブネットマスクの仕組みと計算方法｜CIDR 表記の基礎』を先に確認する方法もあります。

DHCP サーバー・ゲートウェイ・DNS サーバーは別の役割

小規模な環境ではルーター 1 台がこれらを兼ねることが多いため、混同されがちです。しかしDHCP サーバーとデフォルトゲートウェイは、同じ機器である必要はありません。DHCP サーバーは設定情報を配る役割、ゲートウェイは別ネットワーク宛ての通信を転送する役割で、担当する機器は自由に分けられます。

DNS サーバーについても同様です。DHCP が配布できるのは DNS サーバーのアドレスまでで、名前解決そのものを行うのは DNS サーバーです。DHCP から DNS サーバーのアドレスを受け取っていても、そのサーバーへ到達できなければ名前は引けません。

本記事で使う構成例

以降の説明では、同一 VLAN 内の単純な構成を使います。各機器は SW1 に接続し、PC-A は IP アドレスと DNS サーバーの両方を自動取得に設定しているものとします。実機検証の結果ではなく、説明のために用意した構成です。

ゲートウェイや各サーバーのアドレスは、動的配布範囲の外に置いています。固定設定の機器と同じアドレスが配布されると、アドレスの重複につながるためです。

初回取得の流れ（Discover・Offer・Request・ACK）

有効なリースを持たない端末が初めて設定情報を受け取る場合、4 つのメッセージをやり取りします。頭文字から DORA と呼ばれる流れです。各段階を「誰から誰へ」「何を知らせるか」「端末が何を判断するか」で整理します。

最初のやり取りにブロードキャストを使う理由

初回取得で Discover と Request がブロードキャストで送られるのは、それぞれ別の理由によるものです。

• Discover: 端末は DHCP サーバーの所在を知らないため、同一セグメント全体へ送って応答できるサーバーを探します。
• Request: Offer の中から採用したサーバーを示し、採用しなかったサーバーにも選択結果を知らせる必要があるため、全体へ送ります。

一方、サーバーからの Offer と ACK は、端末宛てのユニキャストで返す場合と、ブロードキャストで返す場合があります。IP アドレスが設定される前はユニキャストを受け取れない端末があるため、クライアントがその旨を示すフラグを立てて要求すると、サーバーやリレーはブロードキャストで応答します。DHCP のメッセージをすべてブロードキャスト、あるいはすべてユニキャストと整理すると、実際の通信と合いません。本記事の図では、Discover と Request をブロードキャストで描き、Offer と ACK は IP 設定前のユニキャスト受信に対応した端末を想定してユニキャストで描いています。

複数の Offer を受け取った場合

同じセグメントに応答できるサーバーが複数あると、端末は複数の Offer を受け取ります。どの提案を採用するかはクライアント側の実装によって決まり、規格として選択方法が定められているわけではありません。端末は採用したサーバーを Request の中で明示するため、サーバー側は自分が選ばれたかどうかを判断できます。

このため、意図しない機器が DHCP サーバーとして応答している環境では、端末が想定と違う設定を受け取る可能性があります。取得したアドレスだけでなく、どのサーバーから受け取ったかを確認する意味はここにあります。

動的割り当て・DHCP 予約・手動固定設定の違い

アドレスの決め方には複数の方式があり、混同すると障害時の切り分け先を誤ります。設定を管理する場所、端末側の設定、IP アドレスの取得・更新における DHCP サーバーへの依存の 3 点で比較します。

DHCP 予約は端末側の固定設定ではない

予約は、特定の端末へ決まったアドレスを対応付けておき、配布自体は通常どおり DHCP で行う方式です。DHCP 予約は、端末側で IP アドレスを手動設定する方式とは異なります。端末の設定は自動取得のままなので、アドレス設計を変更する際もサーバー側の変更で対応できます。反面、DHCP のやり取りが成立しなければアドレスを取得できません。

端末側の手動固定設定では、IP アドレスの取得・更新に DHCP を使いません。サーバーの状態に左右されない代わりに、設計変更のたびに端末ごとの作業が必要になり、設定した値がネットワーク側の設計とずれても気付きにくくなります。

動的割り当てでも毎回アドレスが変わるとは限らない

DHCP サーバーは、同じ端末からの要求に対しては、記録している現在のアドレスや以前使っていたアドレスを優先して返そうとします。このため、端末を再起動しても同じアドレスになることは珍しくありません。

ただしこれは保証ではありません。リースが切れて別の端末へ再利用された場合や、プールの空き状況が変わった場合には変化します。「動的だから毎回変わる」「同じアドレスが続いているから予約されている」は、どちらも正確ではありません。

予約時の識別方法は製品と端末で異なる

予約の対象を特定する識別子は、MAC アドレスとは限りません。クライアントが client identifier（オプション 61）を送る場合、サーバーはその値で端末を識別します。識別子の中身は、ハードウェアアドレスに限定されていません。

参考: RFC 2132（DHCP Options and BOOTP Vendor Extensions）
“Identifiers SHOULD be treated as opaque objects by DHCP servers.”
（識別子は、DHCP サーバーが内容を解釈しない値として扱うことが推奨されます。）
https://www.rfc-editor.org/rfc/rfc2132

したがって、予約が効かない場合に「この OS だからこの形式のはず」と決め打ちせず、対象機器が実際に送っている識別子を確認することをおすすめします。Cisco ルーターでの指定方法と、識別子の違いで予約が一致しない場合の対処は、『Cisco ルーター DHCP サーバー設定｜固定 IP 割り当ての落とし穴と対処』で扱っています。

取得後の確認と、取得できたことの意味

Windows 端末では、ipconfig /all で現在の設定を確認できます。アダプターごとの詳細が表示されるため、対象のアダプターを選んで読み取ります。

ipconfig /all

参考: Microsoft Learn（ipconfig）
“Displays the full TCP/IP configuration for all adapters.”
（すべてのアダプターの TCP/IP 構成を表示します。）
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig

出力から確認する項目と構成例との照合

確認したい行だけを抜き出すと、次のような形になります。項目名や表示形式は Windows のバージョンや言語環境によって異なるため、説明用の抜粋として掲載します。

イーサネット アダプター イーサネット:

   DHCP 有効 . . . . . . . . . . . . : はい
   IPv4 アドレス . . . . . . . . . . : 192.168.10.100(優先)
   サブネット マスク . . . . . . . . : 255.255.255.0
   リースが取得された日時 . . . . . : 2026年9月21日 9:00:00
   リースの有効期限 . . . . . . . . : 2026年9月21日 17:00:00
   デフォルト ゲートウェイ . . . . . : 192.168.10.1
   DHCP サーバー . . . . . . . . . . : 192.168.10.2
   DNS サーバー . . . . . . . . . . : 192.168.10.53

この出力を、構成例の設計値と 1 項目ずつ突き合わせます。

この照合で値がそろっていれば、設計どおりの設定が端末に入っていることを確認できます。ただし、値が一致しているだけでは、すべての項目が DHCP から配布されたとは断定できません。端末側で同じ値を手動指定していても、表示は変わらないためです。値が設計とずれている場合は、端末側の手動設定、プールの定義、応答したサーバーの順に確認します。

表示された値がすべて DHCP 由来とは限らない

ipconfig /all が表示するのは、現時点で端末に入っている設定です。表示されている値がすべて DHCP から配布されたものとは限りません。公式リファレンスでも、表示される値の出どころが複数あることが示されています。

「DHCP 有効」が「いいえ」であれば、IP アドレスは端末側の手動設定です。「はい」であっても、DNS サーバーだけを手動で指定している場合があり、その値は表示上、配布された値と区別できません。項目ごとの取得方法は、対象アダプターの IPv4 設定で、IP アドレスと DNS サーバーがそれぞれ自動取得か手動指定かを確認します。本記事の構成例では、IP アドレスと DNS サーバーの両方を自動取得として扱っています。

ipconfig /release は現在の設定を解放する操作で、実行すると通信が中断します。値を確認するだけであれば必要ないため、基本の確認手順には含めていません。

IP アドレスを取得できたことと通信できることは別

取得できた時点で分かるのは、DHCP サーバーとのやり取りが成立し、配布された値が端末へ入ったところまでです。目的の通信が成立するかどうかは、ここから先の確認になります。

• デフォルトゲートウェイの値が意図した機器か、その機器まで到達できるか
• DNS サーバーへの問い合わせが通るか、返ってくる結果が妥当か
• 通信先までの経路と、途中のフィルタリングやポリシーで遮断されていないか
• 通信先の機器やサービス自体が応答できる状態か

取得できた値の照合と、この 4 点の切り分けを分けて考えると、DHCP の問題なのか、経路や通信先の問題なのかを早い段階で判断できます。なお、アドレスを取得できない場合の詳細な診断や、169.254 で始まるアドレスが付いた場合の切り分けは本記事では扱いません。

DHCP に加えて、DNS・ARP・IP の役割も体系的に学びたい方には、『マスタリング TCP/IP 入門編（第 6 版）』が関連書籍の候補になります。第 5 章では、DHCP を含む IP 関連技術を扱っています。
（広告）Kindle 版（Amazon）／単行本（Amazon）

リースの更新と別セグメントへの配布

初回取得の流れをそのまま更新時にも当てはめると、実際の通信量や障害時の挙動を読み違えます。状況ごとの違いを整理します。

初回取得・再利用・更新で使うメッセージは同じではない

再利用や更新の要求に対して、サーバーが拒否（DHCPNAK）を返した場合は、端末はそのアドレスの利用をやめ、初回取得の流れからやり直します。端末が別のセグメントへ移動した場合などが該当します。

一方、サーバーから応答がない場合は扱いが異なります。更新は、リース期間の途中にある T1 と呼ばれる時点で割り当て元のサーバーへ要求します。応答がなくても端末はすぐに初回取得へ戻らず、同じアドレスを使い続けながら要求を再送します。応答がないまま T2 と呼ばれる時点に達すると、どのサーバーでも応答できるようブロードキャストで更新を要求します。リースの期限までにどのサーバーからも承認が得られなかった場合に、そのアドレスの利用を停止し、初回取得からやり直します。以前のアドレスを再利用しようとして応答がない場合も、残りのリース期間はそのアドレスを使い続けられる場合があります。

更新は期限切れを待ってから行うわけではない

端末は、リース期間の途中で更新を試みます。既定の考え方では、リース期間の半分を過ぎた時点が最初の更新タイミングです。

参考: RFC 2131（Dynamic Host Configuration Protocol）
“T1 defaults to (0.5 * duration_of_lease).”
（T1 の既定値は、リース期間の 0.5 倍です。）
https://www.rfc-editor.org/rfc/rfc2131

構成例のリース時間は 8 時間なので、9:00 に取得した端末は 13:00 ごろに更新を試み、受け入れられればその時点から期限が延びます。リース時間を短くすると、この更新のやり取りが増えることになります。

この仕組みがあるため、DHCP サーバーが停止しても、有効なリースを持つ端末がその理由だけで直ちに IP アドレスを失うわけではありません。ただし、更新できない状態が続いて期限を迎えると、端末はそのアドレスを使えなくなります。サーバー停止の影響は、停止した瞬間ではなく、残りのリース期間と合わせて判断します。

DHCP サーバーが別セグメントにある場合

本記事の構成例では DHCP サーバーを VLAN 10 の中に置いていますが、実際の環境ではサーバーを 1 か所へ集約することが多くなります。Discover はブロードキャストで送られる一方、ルーターは受け取ったブロードキャストをそのまま別のセグメントへ転送しません。そのため、端末とサーバーが別セグメントにある構成では、要求はそのままではサーバーまで届きません。

この場合は、経路上のルーターやスイッチを DHCP リレーとして動作させ、受け取った要求をサーバーへ中継します。リレーを使うと、セグメントごとにサーバーを置かずに、1 台のサーバーから複数のセグメントへ配布できます。本記事では入口の説明にとどめ、中継時に付与される情報や機器ごとの設定手順は扱いません。

まとめ

DHCP は、IP アドレスだけでなく、端末が通信を始めるために必要な設定情報をまとめて配布する仕組みです。初回取得の 4 メッセージを押さえたうえで、配布された値が端末のどこに反映されたかを照合できれば、取得までは正常と判断して次の確認へ進めます。

• IP アドレスに加えてマスク、ゲートウェイ、DNS、リース時間を配布
• 割り当てアドレスはフィールド、その他の情報はオプションで通知
• 初回取得は Discover から ACK までの 4 メッセージで確定
• 再利用や更新では 4 メッセージすべてを使うとは限らない。
• 予約は端末側の手動固定設定とは別で、配布は DHCP が担当
• ipconfig /all の表示は構成の設計値と 1 項目ずつ照合する。
• アドレスの取得成功は目的の通信が成立する保証ではない。

以上、最後までお読みいただきありがとうございました。