DHCP（Dynamic Host Configuration Protocol）

DHCPとは

DHCP（Dynamic Host Configuration Protocol）は、ホストが起動時にIPv4アドレスやサブネットマスク、デフォルトゲートウェイ、DNSサーバーといったネットワーク設定を自動的に取得するためのプロトコルです。RFC 2131で定義され、配布できる設定項目（オプション）はRFC 2132で定義されています。

DHCPが無い環境では、管理者が全ホストに手作業でアドレスを設定することになり、台数が増えるほど設定ミスやアドレスの重複が起こりやすくなります。DHCPはアドレスを「貸し出す（リース）」方式で管理するため、使われなくなったアドレスが自動的に回収され、限られたアドレス空間を効率よく使い回せます。

DHCPは、ARPの記事で触れたRARPやBOOTPの後継にあたります。RARPがMACアドレスからIPアドレスを引くだけだったのに対し、BOOTP（RFC 951）はデフォルトゲートウェイやブートファイル名も配布できるように拡張され、DHCPはさらに「アドレスを恒久的に割り当てるのではなく期限付きで貸し出す」という動的な仕組みを加えたものです。DHCPメッセージがBOOTPと同じフォーマットを使っているのはこのためです。

メッセージフォーマット

DHCPメッセージはUDPで運ばれ、サーバーがポート67、クライアントがポート68を使用します。先頭236バイトはBOOTPから引き継いだ固定長部で、その後ろに可変長のoptions部が続きます。DHCP固有の情報（メッセージの種類、リース期間など）はすべてoptions部で表現されるため、固定長部だけを見てもDISCOVERなのかACKなのかは判別できません。

主要なDHCPオプション

options部の各オプションは「タグ（1バイト）・長さ（1バイト）・値（可変長）」の形式で並び、Option 255（End）で終端します。代表的なものは次のとおりです。

Option 53（DHCP Message Type）の値がメッセージの種類そのものを表します。

DHCPの動作（DORA）

クライアントが新規にアドレスを取得するときは、DISCOVER・OFFER・REQUEST・ACKの4つのメッセージをやり取りします。頭文字を取ってDORAと呼ばれます。

sequenceDiagram
    participant C as クライアント
（アドレス未設定）
    participant S as DHCPサーバー
192.168.10.1

    Note over C: アドレスを持たないため
送信元は0.0.0.0

    C->>S: ① DISCOVER（ブロードキャスト）
0.0.0.0:68 → 255.255.255.255:67
Option 53 = 1、yiaddr = 0.0.0.0

    Note over S: プールから未使用の
アドレスを選ぶ

    S->>C: ② OFFER
Option 53 = 2
yiaddr = 192.168.10.101
Option 54（Server Identifier）

    Note over C: 複数のOFFERが届いた場合は
1つを選ぶ

    C->>S: ③ REQUEST（ブロードキャスト）
Option 53 = 3
Option 50 = 192.168.10.101
Option 54 = 選んだサーバー

    S->>C: ④ ACK
Option 53 = 5
yiaddr・サブネットマスク・
デフォルトGW・DNS・リース期間

    Note over C: 重複が無いことを確認して
アドレスの使用を開始

1. DISCOVER：クライアントはまだアドレスを持たないため、送信元IPアドレスを 0.0.0.0、宛先を 255.255.255.255（リミテッドブロードキャスト）としてDHCPサーバーを探す。宛先MACアドレスもブロードキャスト（FF:FF:FF:FF:FF:FF）になる。
2. OFFER：DISCOVERを受信したサーバーは、アドレスプールから未使用のアドレスを1つ選び、yiaddrに入れて提示する。この時点ではまだ確定しておらず、サーバーは一時的に予約した状態になる。
3. REQUEST：クライアントは受け取ったOFFERの中から1つを選び、Option 50（Requested IP Address）に希望アドレス、Option 54（Server Identifier）に選んだサーバーを入れて要求する。このREQUESTもブロードキャストで送信されるため、選ばれなかったサーバーは自分のOFFERが断られたことを知り、予約していたアドレスを解放できる。
4. ACK：サーバーは要求を承認し、アドレス・サブネットマスク・デフォルトゲートウェイ・DNSサーバー・リース期間をまとめて返す。クライアントはこれを受け取ってアドレスの使用を開始する。

いずれのメッセージも同じ xid を持ち、クライアントはこの値で自分宛ての応答かどうかを判断します。

OFFERとACKをブロードキャストで返すかユニキャストで返すかは、クライアントがflagsフィールドのブロードキャストフラグを立てているかどうかで決まります。アドレスが未設定の状態ではユニキャストのIPパケットを受け取れない実装があるため、その場合はフラグを立ててブロードキャストでの返送を要求します。

リース期間と更新

ACKで通知されるリース期間（Option 51）は無期限ではなく、クライアントは期限が切れる前に更新（リニューアル）を行う必要があります。更新には2段階のタイマーが使われます。

更新時のREQUESTは、クライアントが既にアドレスを持っている状態で送るため、ciaddrに現在のアドレスが入り、Option 50（Requested IP Address）は使いません。DISCOVERは発生せず、REQUESTとACKの2メッセージだけで完了します。

なお、T1・T2の既定値はRFC 2131が示す目安であり、実装によってはランダム化が入るため厳密に50%・87.5%にならないことがあります。

その他のDHCPメッセージ

DORAとリース更新以外に、次のメッセージが使われます。

• DECLINE：ACKで割り当てられたアドレスが既に他のホストで使われていた場合に、クライアントがサーバーへ通知する。サーバーはそのアドレスを問題ありとして記録し、しばらく割り当てから除外する。
• NAK：サーバーが要求を拒否するときに返す。クライアントが別のセグメントに移動したのに以前のアドレスを要求してきた場合など、要求されたアドレスがそのセグメントで有効でないときに送られる。NAKを受け取ったクライアントはアドレスを破棄し、DISCOVERからやり直す。
• RELEASE：クライアントがアドレスを明示的に返却する。サーバーはリースを削除し、そのアドレスを再び割り当て可能にする。ユニキャストで送信される。
• INFORM：クライアントが静的にアドレスを設定済みで、DNSサーバーなどアドレス以外の設定だけを取得したい場合に使う。サーバーはyiaddrを設定せずにACKを返す。

DHCPリレーエージェント

DISCOVERはブロードキャストで送信されるため、ルータを越えられません。そのままではセグメントごとにDHCPサーバーを置く必要がありますが、実際にはルータがブロードキャストを受け取ってユニキャストに変換し、別セグメントのDHCPサーバーへ転送します。この機能をDHCPリレーエージェントと呼び、Cisco IOSではインターフェースにip helper-addressを設定して有効にします。

このとき、リレーエージェントは自身のIPアドレスをgiaddrに書き込みます。サーバーはgiaddrを見て「どのセグメントからの要求か」を判断し、そのセグメントに対応するプールからアドレスを選びます。giaddrはリレーの有無を判断する鍵となるフィールドです。

リレーエージェントの詳細な動作とOption 82については、DHCPリレーエージェントを参照してください。

セキュリティ上の注意点

DHCPにはサーバーを認証する仕組みがありません。クライアントは最初に届いたOFFERを受け入れるため、正規のサーバーより早く応答する不正なDHCPサーバー（Rogue DHCPサーバー）を同一セグメントに設置されると、誤ったデフォルトゲートウェイやDNSサーバーを配布され、通信を攻撃者の機器に誘導されてしまいます。

また、chaddrを偽装したDISCOVERを大量に送ってアドレスプールを枯渇させ、正規のクライアントがアドレスを取得できなくする攻撃（DHCPスタベーション）もあります。

対策としては、スイッチのDHCP Snooping機能が用いられます。DHCP Snoopingは、正規のDHCPサーバーが接続されたポートだけを「信頼ポート」として扱い、それ以外のポートから届いたOFFERやACKを破棄します。同時に「どのポートのどのMACアドレスにどのIPアドレスが割り当てられたか」をバインディングテーブルとして記録するため、この情報をARPのDynamic ARP Inspection（DAI）と組み合わせることで、ARPスプーフィングの検出にも利用されます。

実機での検証

R1（DHCPサーバー）・R2（クライアント）・Linux1（クライアント）を1つのセグメントに接続し、DORA・リース更新・RELEASE・2台目の割り当てを実機で確認しました。ルータはCisco IOS XE 17.03.08a（csr1000v）、Linux1はUbuntu 24.04です。

R1のプール設定は次のとおりです。リース期間を2分と短くしているのは、T1（リースの50% = 60秒）の発火を待って更新の動作を観測するためです。

ip dhcp excluded-address 192.168.10.1 192.168.10.100
!
ip dhcp pool LAN
 network 192.168.10.0 255.255.255.0
 default-router 192.168.10.1
 dns-server 192.168.10.53
 domain-name kazulog.example
 lease 0 0 2

R2はGigabitEthernet1にip address dhcpを設定してDHCPクライアントとして動作させ、インターフェースのshutdown / no shutdownでDORAを任意のタイミングで発生させています。

検証の流れとサーバー側カウンタの推移

show ip dhcp server statisticsのメッセージ種別ごとのカウンタで、各STEPで何が起きたかを追えます。

STEP 2でDISCOVERとOFFERが増えずREQUESTとACKだけが増えている点が、前述の「更新はREQUESTとACKの2メッセージだけで完了する」ことの裏づけです。一方STEP 4はreleaseでリースを手放した後の再取得なので、DISCOVERからのフルDORAになっています。

DORAのキャプチャ

R1のGigabitEthernet1（SWとの間）でキャプチャしました。添付のキャプチャーのNo.1〜No.5が、R2がアドレスを取得したときのDORAです。

    1   0.000000      0.0.0.0 → 255.255.255.255 DHCP 357 DHCP Discover - Transaction ID 0xfdd
    2   0.119593 52:54:00:8c:63:71 → Broadcast    ARP 60 Who has 192.168.10.101? Tell 192.168.10.1
    3   2.089207 192.168.10.1 → 255.255.255.255 DHCP 372 DHCP Offer    - Transaction ID 0xfdd
    4   2.131093      0.0.0.0 → 255.255.255.255 DHCP 375 DHCP Request  - Transaction ID 0xfdd
    5   2.134861 192.168.10.1 → 255.255.255.255 DHCP 372 DHCP ACK      - Transaction ID 0xfdd

4つのメッセージすべてが Transaction ID 0xfdd を共有しており、xid で1回のアドレス取得手続きが対応付けられていることが分かります。No.2でR1が「192.168.10.101は誰が使っていますか」とARPを送っている点にも注目してください。これはサーバーがOFFERを出す前に、割り当てようとしているアドレスが実際に使われていないかを確認しているものです。

またDISCOVERだけでなくOFFERとACKもブロードキャスト（255.255.255.255）で返っています。これはR2がBroadcast flagを立てているためです。

Dynamic Host Configuration Protocol (Discover)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x00000fdd
    Seconds elapsed: 0
    Bootp flags: 0x8000, Broadcast flag (Broadcast)
    Client IP address: 0.0.0.0
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: 52:54:00:cf:69:eb (52:54:00:cf:69:eb)
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Discover)
        DHCP: Discover (1)
    Option: (61) Client identifier
        Client Identifier: cisco-5254.00cf.69eb-Gi1
    Option: (55) Parameter Request List
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (6) Domain Name Server
        Parameter Request List Item: (15) Domain Name
        Parameter Request List Item: (3) Router

ciaddr・yiaddr・giaddrがすべて 0.0.0.0 で、chaddrにR2のMACアドレスが入っています。giaddrが 0.0.0.0 なのはリレーエージェントを経由していないためです。Option 55（Parameter Request List）で、クライアントが「サブネットマスク・DNS・ドメイン名・デフォルトゲートウェイを教えてほしい」と要求している点も確認できます。

ACKには、要求された設定がオプションとして詰め込まれて返ってきます。

Dynamic Host Configuration Protocol (ACK)
    Message type: Boot Reply (2)
    Transaction ID: 0x00000fdd
    Your (client) IP address: 192.168.10.101
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (ACK)
        DHCP: ACK (5)
    Option: (54) DHCP Server Identifier (192.168.10.1)
        DHCP Server Identifier: 192.168.10.1
    Option: (51) IP Address Lease Time
        IP Address Lease Time: 2 minutes (120)
    Option: (58) Renewal Time Value
        Renewal Time Value: 1 minute (60)
    Option: (59) Rebinding Time Value
        Rebinding Time Value: 1 minute, 45 seconds (105)
    Option: (1) Subnet Mask (255.255.255.0)
        Subnet Mask: 255.255.255.0
    Option: (3) Router
        Router: 192.168.10.1

yiaddrに割り当てるアドレス192.168.10.101が入り、Option 51でリース期間120秒、Option 58でT1が60秒、Option 59でT2が105秒と通知されています。T1・T2はクライアントが自分で計算するのではなく、サーバーがオプションとして明示的に配布していることが分かります。この値はリース期間のちょうど50%・87.5%です。

クライアント側からも同じ情報が確認できます。

R2#show dhcp lease
Temp IP addr: 192.168.10.101  for peer on Interface: GigabitEthernet1
Temp  sub net mask: 255.255.255.0
   DHCP Lease server: 192.168.10.1, state: 5 Bound
   DHCP transaction id: FDD
   Lease: 120 secs,  Renewal: 60 secs,  Rebind: 105 secs
Temp default-gateway addr: 192.168.10.1
   Next timer fires after: 00:00:40
   Retry count: 0   Client-ID: cisco-5254.00cf.69eb-Gi1
   Hostname: R2

サーバー側ではshow ip dhcp bindingにリースが1件登録されます。

R1#show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address      Client-ID/ 		Lease expiration 	Type       State      Interface
		Hardware address/
		User name
192.168.10.101  0063.6973.636f.2d35.    Sep 06 2026 04:39 AM    Automatic  Active     GigabitEthernet1
                3235.342e.3030.6366.
                2e36.3965.622d.4769.
                31

Client-IDの 0063.6973.636f.2d35... は、先頭の 00 に続く部分が cisco-5254.00cf.69eb-Gi1 のASCIIコードです。

リース更新（T1）のキャプチャ

リース取得から60秒後、T1の満了によって更新が行われました。添付のキャプチャーのNo.10・No.11です。抜き出したファイルでは、No.10がNo.1、No.11がNo.2として表示されます。

   10 112.192916 192.168.10.101 → 255.255.255.255 DHCP 363 DHCP Request  - Transaction ID 0xfdd
   11 112.198228 192.168.10.1 → 192.168.10.101 DHCP 372 DHCP ACK      - Transaction ID 0xfdd

DISCOVERとOFFERが無く、REQUESTとACKの2メッセージだけで完了しています。 送信元IPアドレスが 0.0.0.0 ではなく既に割り当てられている192.168.10.101になっている点も、新規取得時との違いです。

Dynamic Host Configuration Protocol (Request)
    Message type: Boot Request (1)
    Client IP address: 192.168.10.101
    Your (client) IP address: 0.0.0.0
    Option: (53) DHCP Message Type (Request)
        DHCP: Request (3)
    Option: (61) Client identifier
        Client Identifier: cisco-5254.00cf.69eb-Gi1
    Option: (51) IP Address Lease Time
    Option: (55) Parameter Request List

ciaddr（Client IP address）に現在のアドレスが入り、Option 50（Requested IP Address）が含まれていません。新規取得時のREQUESTと比較すると違いが分かります。

Dynamic Host Configuration Protocol (Request)
    Message type: Boot Request (1)
    Client IP address: 0.0.0.0
    Your (client) IP address: 0.0.0.0
    Option: (53) DHCP Message Type (Request)
        DHCP: Request (3)
    Option: (54) DHCP Server Identifier (192.168.10.1)
        DHCP Server Identifier: 192.168.10.1
    Option: (50) Requested IP Address (192.168.10.101)
        Requested IP Address: 192.168.10.101

新規取得時はciaddrが 0.0.0.0 で、代わりにOption 50で希望アドレスを、Option 54でどのサーバーのOFFERを受け入れたかを示しています。

RELEASEのキャプチャ

R2でrelease dhcp GigabitEthernet1を実行すると、RELEASEが送信されてbindingが削除されます。添付のキャプチャーのNo.12〜No.14です。

   12 158.227141 192.168.10.101 → 192.168.10.1 DHCP 319 DHCP Release  - Transaction ID 0xfdd
   13 158.289871 192.168.10.101 → 192.168.10.1 DHCP 319 DHCP Release  - Transaction ID 0xfdd
   14 159.257198 192.168.10.101 → 192.168.10.1 DHCP 319 DHCP Release  - Transaction ID 0xfdd

前述のとおりRELEASEはユニキャストでサーバー宛てに送信されています。またこの実装では同じRELEASEが3回送出されました。RELEASEは応答（ACK）が返らないメッセージであるため、確実に届けるために複数回送る実装になっています。

この後にR2でrenew dhcp GigabitEthernet1を実行すると、リースを手放した状態からの取得になるため更新ではなくフルDORAが発生します。添付のキャプチャーのNo.15〜No.19で、xidも新しい値（0x11df）に変わっています。

   15 201.064437      0.0.0.0 → 255.255.255.255 DHCP 357 DHCP Discover - Transaction ID 0x11df
   16 201.071284 52:54:00:8c:63:71 → Broadcast    ARP 60 Who has 192.168.10.102? Tell 192.168.10.1
   17 203.070332 192.168.10.1 → 255.255.255.255 DHCP 372 DHCP Offer    - Transaction ID 0x11df
   18 203.074758      0.0.0.0 → 255.255.255.255 DHCP 375 DHCP Request  - Transaction ID 0x11df
   19 203.078088 192.168.10.1 → 255.255.255.255 DHCP 372 DHCP ACK      - Transaction ID 0x11df

割り当てられたアドレスが192.168.10.101ではなく192.168.10.102になっている点にも注目してください。解放されたアドレスはすぐには再利用されず、プールの次のアドレスが割り当てられています。

2台目のクライアントへの割り当て

Linux1のens2を有効にすると、systemd-networkdがDHCPクライアントとして動作しアドレスを取得します。添付のキャプチャーのNo.22〜No.28です。

cisco@linux1:~$ sudo cat /run/systemd/netif/leases/2
ADDRESS=192.168.10.103
NETMASK=255.255.255.0
ROUTER=192.168.10.1
SERVER_ADDRESS=192.168.10.1
T1=1min
T2=1min 45s
LIFETIME=2min
DNS=192.168.10.53
DOMAINNAME=kazulog.example

サブネットマスク（Option 1）・デフォルトゲートウェイ（Option 3）・DNS（Option 6）・ドメイン名（Option 15）・リース期間（Option 51）・サーバー識別子（Option 54）・T1（Option 58）・T2（Option 59）が、いずれもR1のプール設定どおりに届いています。

この時点でサーバー側には2件のbindingが登録されています。

R1#show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address      Client-ID/ 		Lease expiration 	Type       State      Interface
		Hardware address/
		User name
192.168.10.102  0063.6973.636f.2d35.    Sep 06 2026 04:44 AM    Automatic  Active     GigabitEthernet1
                3235.342e.3030.6366.
                2e36.3965.622d.4769.
                31
192.168.10.103  ff32.39f9.b500.0200.    Sep 06 2026 04:44 AM    Automatic  Active     GigabitEthernet1
                00ab.11bf.2c47.2a54.
                c859.64

Client-IDが異なるため、2台には別々のアドレスが割り当てられています。 R2（IOS XE）は cisco-<MACアドレス>-<インターフェース名> という文字列を、Linux1（systemd-networkd）はRFC 4361形式の識別子をClient-ID（Option 61）として送っており、サーバーはこの値でクライアントを区別しています。

ACK後のARPによる重複確認

Linux1がACKを受け取った直後、割り当てられたアドレスが本当に空いているかをARPで確認しています。添付のキャプチャーのNo.32〜No.35です。

   32 254.094669 52:54:00:ae:85:ed → Broadcast    ARP 42 Who has 192.168.10.104? (ARP Probe)
   33 255.983190 52:54:00:ae:85:ed → Broadcast    ARP 42 Who has 192.168.10.104? (ARP Probe)
   34 257.577179 52:54:00:ae:85:ed → Broadcast    ARP 42 Who has 192.168.10.104? (ARP Probe)
   35 259.583695 52:54:00:ae:85:ed → Broadcast    ARP 42 ARP Announcement for 192.168.10.104

前述のRFC 2131 §2.2の推奨どおり、ARP Probeを3回送って応答が無いことを確認してから、ARP Announcementで使用開始を周囲に通知しています。これらの詳細はARPのGratuitous ARPの節で解説しています。応答があった場合はDECLINEをサーバーに送り、別のアドレスを要求し直すことになります。

検証Configおよびshow結果

各STEPでR1・R2から、次の3種類をルータごとに分けて取得しています。検証Configはこの..._run.txtです（最終状態はSTEP 5のもの）。

Linux1はshow相当の出力のみをSTEP 0とSTEP 5で取得しています。

STEP 0：初期状態（R2のGi1はshutdown、Linux1のens2はdown）

STEP 1：R2のGi1をno shutdownしてDORAでアドレスを取得した状態

STEP 2：T1の満了によりリースが更新された状態

STEP 3：R2でrelease dhcpを実行しリースを返却した状態

STEP 4：R2でrenew dhcpを実行し再取得した状態

STEP 5：Linux1もアドレスを取得し、クライアント2台になった状態（最終状態）

参考

関連記事

• IPv4パケットヘッダー構造

• IPv4 アドレス

• IPv4 サブネットマスク計算ツール

• DHCP（Dynamic Host Configuration Protocol）

  • DHCPリレーエージェント

• ARP（Address Resolution Protocol）

• ICMP（Internet Control Message Protocol）

  • ICMP Echo Request/Reply（ping）

  • ICMP Time Exceeded（traceroute）

  • ICMP Destination Unreachable