DHCPとは｜仕組み・DORAの流れをtcpdumpの実物で解説

機器は、電源を入れた直後は自分の IP アドレスを知りません。そこで、ネットワーク全体に向けて呼びかけ、DHCP サーバー（家庭では Wi-Fi ルーター）から設定をもらいます。4つの頭文字を取って DORA と呼ばれる流れです。

flowchart TD
    C[クライアント<br>まだアドレスが無い] -->|1 DISCOVER| S[DHCP サーバー]
    S -->|2 OFFER<br>候補 .140| C
    C -->|3 REQUEST| S
    S -->|4 ACK<br>確定・リース 120 秒| C

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、ip netns で作った仮想のネットワーク空間（t10srv・t10cli）を veth でつなぎ、サーバー側に dnsmasq 2.91 の DHCP サーバー（DNS は止めて DHCP だけ）、クライアント側に BusyBox 1.36.1 の udhcpc と ISC dhclient 4.4.3-P1 を動かしました。パケットは tcpdump 4.99.4（libpcap 1.10.4）でクライアント側の veth で取り、DHCP サーバーの判断は dnsmasq の log-dhcp のログで確かめました。DHCP が無いときの 169.254 は avahi-autoipd 0.8 で、DHCP リレーは3つ目・4つ目の netns に dnsmasq の dhcp-relay を置いて動かしました。ホストのネットワーク設定・/etc は変えていません。仕様は RFC 2131（DHCP）・RFC 3927（169.254）・RFC 9915（DHCPv6）、Windows と Mac の操作は Microsoft と Apple の公式ドキュメント、家庭用ルーターの設定項目は NEC（Aterm WX3600HP）と ELECOM（WRC-BE100XS）の公式マニュアルで確かめた範囲だけを書いています。IPv6 の DHCPv6 と SLAAC は、この環境のカーネルが IPv6 に対応していなかったため、仕様と dnsmasq のドキュメントで書いています。図は mermaid 11 で描画を確かめています（確認日 2026年10月29日）。

DHCPとは（意味・役割・無いとどうなるか）

この節では、DHCP が何をする仕組みで、無いと何が起きるのかが分かります。

DHCP は、ネットワークにつないだ機器に、通信に必要な設定を自動で配るプロトコルです。 配るのは IP アドレスだけではなく、サブネットマスク・デフォルトゲートウェイ（ルーターのアドレス）・DNS サーバーのアドレス・リース期間（借りていられる時間）です。家庭の Wi-Fi ルーター、会社のルーターや Windows Server、スマホのテザリングなど、「つないだらすぐ使える」環境には必ず DHCP サーバーがいます。

RFC 2131 は、アドレスを割り当てる期間を「リース（lease）」と呼び、クライアントは決まった期間（無期限もある）だけアドレスを借りる、と定めています。「もらう」ではなく「借りる」のが DHCP の考え方で、期限が来る前に延長を頼み、使わなくなったら返します。

DHCP が無いと、どうなるかも手元で確かめました。DHCP サーバーを止めてクライアントを動かすと、3回呼びかけて諦め、IP アドレスが無いままです。

$ ip netns exec t10cli busybox udhcpc -i t10veth1 -f -q -n -t 3 -T 2 -s ./udhcpc.sh
udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: broadcasting discover
udhcpc: broadcasting discover
[script] event=leasefail ip= mask= router= dns= lease= domain= serverid=
udhcpc: no lease, failing
$ ip -n t10cli -4 addr show t10veth1 | grep inet
(IPv4 アドレスなし)

Windows や Mac では、この状態になると 169.254 で始まるアドレスを自分で付けます（後述）。「Wi-Fi にはつながっているのにインターネットに出られない」ときの代表的な原因です。

DHCPの仕組み：DISCOVER→OFFER→REQUEST→ACK（tcpdumpの原文）

この節では、アドレスが決まるまでの4つのパケットの中身と、それぞれの役割が分かります。

クライアントは、自分のアドレスが 0.0.0.0 のまま、宛先 255.255.255.255（全員）に DISCOVER を送ります。 手元のクライアント側で tcpdump を取った4パケットです（-e で MAC アドレスも表示）。

$ ip netns exec t10cli tcpdump -i t10veth1 -n -e 'port 67 or port 68'
17:43:06.736142 02:42:ac:10:00:05 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:42:ac:10:00:05, length 300
17:43:06.736408 2a:a9:93:42:8d:ad > 02:42:ac:10:00:05, ethertype IPv4 (0x0800), length 347: 192.168.50.1.67 > 192.168.50.140.68: BOOTP/DHCP, Reply, length 305
17:43:06.772127 02:42:ac:10:00:05 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:42:ac:10:00:05, length 300
17:43:06.773408 2a:a9:93:42:8d:ad > 02:42:ac:10:00:05, ethertype IPv4 (0x0800), length 347: 192.168.50.1.67 > 192.168.50.140.68: BOOTP/DHCP, Reply, length 305

1行目と3行目がクライアントの送信（DISCOVER・REQUEST）、2行目と4行目がサーバーの返事（OFFER・ACK）です。-vv を付けると、どれがどのメッセージかと、中身のオプションが見えます（主な行だけ抜き出しています）。

17:43:06.736142 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 02:42:ac:10:00:05, length 300, xid 0x9d89c80a, Flags [none] (0x0000)
	  Client-Ethernet-Address 02:42:ac:10:00:05
	    DHCP-Message (53), length 1: Discover
	    Parameter-Request (55), length 7:
	      Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
	      Domain-Name (15), BR (28), NTP (42)
	    Vendor-Class (60), length 12: "udhcp 1.36.1"
	    Client-ID (61), length 7: ether 02:42:ac:10:00:05

17:43:06.736408 IP (tos 0xc0, ttl 64, id 38133, offset 0, flags [none], proto UDP (17), length 333)
    192.168.50.1.67 > 192.168.50.140.68: BOOTP/DHCP, Reply, length 305, xid 0x9d89c80a, Flags [none] (0x0000)
	  Your-IP 192.168.50.140
	  Server-IP 192.168.50.1
	  Client-Ethernet-Address 02:42:ac:10:00:05
	    DHCP-Message (53), length 1: Offer
	    Server-ID (54), length 4: 192.168.50.1
	    Lease-Time (51), length 4: 120
	    RN (58), length 4: 60
	    RB (59), length 4: 105
	    Subnet-Mask (1), length 4: 255.255.255.0
	    BR (28), length 4: 192.168.50.255
	    Domain-Name (15), length 11: "lab.example"
	    Domain-Name-Server (6), length 4: 192.168.50.1
	    Default-Gateway (3), length 4: 192.168.50.1

17:43:06.772127 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 02:42:ac:10:00:05, length 300, xid 0x9d89c80a, Flags [none] (0x0000)
	    DHCP-Message (53), length 1: Request
	    Requested-IP (50), length 4: 192.168.50.140
	    Server-ID (54), length 4: 192.168.50.1
	    Parameter-Request (55), length 7:
	      Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
	      Domain-Name (15), BR (28), NTP (42)

17:43:06.773408 IP (tos 0xc0, ttl 64, id 38142, offset 0, flags [none], proto UDP (17), length 333)
    192.168.50.1.67 > 192.168.50.140.68: BOOTP/DHCP, Reply, length 305, xid 0x9d89c80a, Flags [none] (0x0000)
	  Your-IP 192.168.50.140
	  Server-IP 192.168.50.1
	    DHCP-Message (53), length 1: ACK
	    Server-ID (54), length 4: 192.168.50.1
	    Lease-Time (51), length 4: 120
	    RN (58), length 4: 60
	    RB (59), length 4: 105
	    Subnet-Mask (1), length 4: 255.255.255.0
	    Domain-Name-Server (6), length 4: 192.168.50.1
	    Default-Gateway (3), length 4: 192.168.50.1

ACK を受けたクライアント側で、アドレスと経路が付いた状態です。

$ ip -n t10cli -4 addr show t10veth1
5: t10veth1@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link-netns t10srv
    inet 192.168.50.140/24 brd 192.168.50.255 scope global t10veth1
$ ip -n t10cli route
default via 192.168.50.1 dev t10veth1
192.168.50.0/24 dev t10veth1 proto kernel scope link src 192.168.50.140
$ ip netns exec t10cli ping -c1 192.168.50.1
1 packets transmitted, 1 received, 0% packet loss, time 0ms

サーバー側の dnsmasq のログでも、同じ4段階が1行ずつ残っています。先頭の数字（xid）は、この4パケットが同じやり取りだと示す番号です。

dnsmasq-dhcp[13856]: 2643052554 DHCPDISCOVER(t10veth0) 02:42:ac:10:00:05
dnsmasq-dhcp[13856]: 2643052554 DHCPOFFER(t10veth0) 192.168.50.140 02:42:ac:10:00:05
dnsmasq-dhcp[13856]: 2643052554 DHCPREQUEST(t10veth0) 192.168.50.140 02:42:ac:10:00:05
dnsmasq-dhcp[13856]: 2643052554 DHCPACK(t10veth0) 192.168.50.140 02:42:ac:10:00:05

ポート番号と「ブロードキャスト」

RFC 2131 は、クライアントからサーバーへは UDP の 67 番（DHCP server ポート）、サーバーからクライアントへは 68 番（DHCP client ポート）に送る、と定めています。DISCOVER と REQUEST がブロードキャスト（全員宛て）なのは、クライアントがまだサーバーの居場所も自分のアドレスも知らないためです。ブロードキャストはルーターを越えないので、DHCP サーバーは同じセグメント（同じスイッチ・同じ Wi-Fi）にいるか、ルーターが代わりに中継（DHCP リレー、後述）する必要があります。

サーバーが OFFER の前に3秒待った理由

最初に動かしたときは、OFFER が DISCOVER の3秒後に返り、クライアントは待ちきれずに DISCOVER をもう一度送っていました。

17:41:49.608230 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request ...   ← DISCOVER
17:41:52.613069 IP 192.168.50.1.67 > 192.168.50.140.68: BOOTP/DHCP, Reply ... ← 3秒後に OFFER
17:41:52.620126 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request ...   ← 2回目の DISCOVER

dnsmasq は既定で、候補のアドレスに ICMP echo（ping）を送って、ほかの機器が使っていないかを確かめてから OFFER を出します（dnsmasq のマニュアル）。この記事のほかの実験は、設定に no-ping を足して確認を省いたため、37 ミリ秒で終わっています。本番のサーバーでは、重複を避けるためにこの確認を残すのが安全です。

DHCPで配られる情報（オプション）と実際の値

この節では、IP アドレス以外に何が配られるのか、オプション番号と実際の値で分かります。

DHCP の設定情報は「オプション」という番号付きの項目で運ばれます。 OFFER と ACK に入っていたものを、番号つきで並べます。

クライアントは DISCOVER の Parameter-Request（55）で「ほしいもの」を伝え、サーバーは持っているものだけを返します。手元のクライアントは NTP（42）も頼みましたが、サーバーに設定が無いので返っていません。配る情報を増やしたいときは、サーバー側に設定を足します（dnsmasq なら dhcp-option=option:ntp-server,…）。

RFC 2131 が定めるメッセージは8種類です。

リース期間と更新（T1・T2）を実測する

この節では、リース期間の意味と、期限が来る前にクライアントが何をするのかが、実測で分かります。

リース期間の半分（T1）が来ると、クライアントはサーバーに直接（ユニキャストで）REQUEST を送って延長を頼みます。 RFC 2131 は、T1 の既定値をリース期間の 0.5 倍、T2 を 0.875 倍と定め、T1 では元のサーバーにユニキャストで、T2 までに ACK が無ければブロードキャストでほかのサーバーにも頼む、としています。手元のリースは 120 秒なので、T1 は 60 秒、T2 は 105 秒です（OFFER の RN=60・RB=105 がそれです）。

dhclient を動かしたままにして、更新の瞬間を捕まえました。

$ ip netns exec t10cli dhclient -d -v -4 -sf ./dhclient-script.sh -lf ./dhclient.leases t10veth1
DHCPDISCOVER on t10veth1 to 255.255.255.255 port 67 interval 3 (xid=0x77eaf37f)
DHCPOFFER of 192.168.50.140 from 192.168.50.1
DHCPREQUEST for 192.168.50.140 on t10veth1 to 255.255.255.255 port 67 (xid=0x7ff3ea77)
DHCPACK of 192.168.50.140 from 192.168.50.1 (xid=0x77eaf37f)
bound to 192.168.50.140 -- renewal in 58 seconds.
DHCPREQUEST for 192.168.50.140 on t10veth1 to 192.168.50.1 port 67 (xid=0x7ff3ea77)
DHCPACK of 192.168.50.140 from 192.168.50.1 (xid=0x77eaf37f)
bound to 192.168.50.140 -- renewal in 42 seconds.

17:43:30.744489 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:42:ac:10:00:05, length 300   ← DISCOVER（全員宛て）
17:43:30.744698 IP 192.168.50.1.67 > 192.168.50.140.68: BOOTP/DHCP, Reply, length 305                       ← OFFER
17:43:30.744855 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:42:ac:10:00:05, length 300   ← REQUEST（全員宛て）
17:43:30.747677 IP 192.168.50.1.67 > 192.168.50.140.68: BOOTP/DHCP, Reply, length 309                       ← ACK
17:44:28.336260 IP 192.168.50.140.68 > 192.168.50.1.67: BOOTP/DHCP, Request from 02:42:ac:10:00:05, length 300 ← 58秒後の更新 REQUEST（サーバー宛て）
17:44:28.339386 IP 192.168.50.1.67 > 192.168.50.140.68: BOOTP/DHCP, Reply, length 309                       ← ACK（リースが120秒に戻る）

最初の REQUEST は送信元 0.0.0.0・宛先 255.255.255.255 ですが、58 秒後の更新は 192.168.50.140 から 192.168.50.1 へ直接送られています。 更新は DISCOVER からやり直さず、REQUEST と ACK の2パケットだけで済みます。「renewal in 58 seconds」と 60 秒ちょうどでないのは、dhclient が少しずらしているためです。

dhclient が保存したリースファイルには、いつ更新・期限切れになるかが書かれています。

lease {
  interface "t10veth1";
  fixed-address 192.168.50.140;
  option subnet-mask 255.255.255.0;
  option dhcp-lease-time 120;
  option routers 192.168.50.1;
  option dhcp-server-identifier 192.168.50.1;
  option domain-name-servers 192.168.50.1;
  option dhcp-renewal-time 55;
  option dhcp-rebinding-time 100;
  option domain-name "lab.example";
  renew 4 2026/10/29 08:45:55;
  rebind 4 2026/10/29 08:46:50;
  expire 4 2026/10/29 08:47:10;
}

1. 10〜T1（50%）：そのまま使う手元では 0〜60 秒
2. 2T1：元のサーバーに直接 REQUEST（RENEWING）ACK が返ればリースが延びて 1 に戻る
3. 3T2（87.5%）：全員宛てに REQUEST（REBINDING）元のサーバーが応答しないとき。どのサーバーでもよい
4. 4期限切れ：アドレスを捨てて DISCOVER からやり直す通信が一度切れる

リース期間の決め方

家庭用ルーターの初期値は ELECOM WRC-BE100XS で 24 時間（後述の公式マニュアル）、dnsmasq の既定は 1 時間、最短は 2 分です（dnsmasq のマニュアル）。短くすると、来客の多いカフェのようにアドレスが足りなくなりがちな場所で回収が早くなり、長くすると更新のパケットが減り、サーバーが短時間止まっても影響が出にくくなります。

解放（RELEASE）と拒否（NAK）の原文

使い終わったアドレスを返すのが DHCPRELEASE です。dhclient -r で送ると、サーバーのリース一覧からすぐ消えました。

$ ip netns exec t10cli dhclient -r -v -4 -sf ./dhclient-script.sh -lf ./dhclient.leases t10veth1
DHCPRELEASE of 192.168.50.140 on t10veth1 to 192.168.50.1 port 67 (xid=0x3eb01212)

17:45:16.505035 IP 192.168.50.140.68 > 192.168.50.1.67: BOOTP/DHCP, Request from 02:42:ac:10:00:05, length 300
dnsmasq-dhcp[13856]: 1477424936 DHCPRELEASE(t10veth0) 192.168.50.140 02:42:ac:10:00:05
$ cat dnsmasq.leases
（空）

ノート PC を別のネットワークに持っていくと、前のネットワークで借りたアドレスを「まだ使えますか」と REQUEST で確かめます（INIT-REBOOT）。別のネットワークのアドレスなので、サーバーは DHCPNAK で断り、クライアントは DISCOVER からやり直します。前のリース（192.168.60.5）を持たせたクライアントで再現した原文です。

17:45:55.200699 IP 0.0.0.0.68 > 255.255.255.255.67: ... DHCP-Message (53), length 1: Request
	    Requested-IP (50), length 4: 192.168.60.5
17:45:55.200892 IP 192.168.50.1.67 > 255.255.255.255.68: ... DHCP-Message (53), length 1: NACK
	    Server-ID (54), length 4: 192.168.50.1
	    MSG (56), length 13: "wrong address"
17:45:55.211160 ... DHCP-Message (53), length 1: Discover
17:45:55.211324 ... Your-IP 192.168.50.20  DHCP-Message (53), length 1: Offer

dnsmasq-dhcp[17437]: 2344225659 DHCPREQUEST(t10veth0) 192.168.60.5 02:42:ac:10:00:05
dnsmasq-dhcp[17437]: 2344225659 DHCPNAK(t10veth0) 192.168.60.5 02:42:ac:10:00:05 wrong address
dnsmasq-dhcp[17437]: 4143896633 DHCPDISCOVER(t10veth0) 02:42:ac:10:00:05

NAK のあと約 10 ミリ秒で DISCOVER からやり直し、新しいアドレスをもらっています。会社と家で Wi-Fi を切り替えてもすぐ使えるのは、この仕組みのおかげです。

MACアドレスでの予約（DHCP固定割当・リザベーション）

この節では、プリンターや NAS のように「いつも同じアドレスにしたい」機器を、DHCP のまま固定する方法が分かります。

DHCP サーバーに「この MAC アドレスにはこの IP アドレスを配る」と登録しておくと、機器側は何も変えずに、毎回同じアドレスになります。 ルーターの画面では「DHCP固定割当」「DHCPサーバー固定設定」「予約」などの名前です。dnsmasq では dhcp-host の1行です。

# dnsmasq.conf
dhcp-range=192.168.50.100,192.168.50.150,255.255.255.0,2m
dhcp-host=02:42:ac:10:00:05,192.168.50.20,pc-takahira

同じクライアントがもらったアドレスが、.140 から .20 に変わり、ホスト名も配られました。

udhcpc: broadcasting discover
udhcpc: broadcasting select for 192.168.50.20, server 192.168.50.1
udhcpc: lease of 192.168.50.20 obtained from 192.168.50.1, lease time 120

	  Your-IP 192.168.50.20
	    DHCP-Message (53), length 1: ACK
	    Lease-Time (51), length 4: 120
	    Hostname (12), length 11: "pc-takahira"

$ cat dnsmasq.leases
1793263655 02:42:ac:10:00:05 192.168.50.20 pc-takahira 01:02:42:ac:10:00:05

• 予約するアドレスは、配る範囲と同じサブネットにある必要があります（dnsmasq のマニュアル）。NEC Aterm の公式マニュアルも、「うまく動作しない場合」として、設定した IP アドレスが DHCP サーバーの割り当て範囲外になっている可能性を挙げています。
• スマホは「プライベート Wi-Fi アドレス」「ランダム化された MAC アドレス」で、ネットワークごとに違う MAC を名乗ることがあります。予約が効かないときは、その機能を確かめます。

DHCPサーバーが無いとき：169.254（APIPA・リンクローカル）になる理由

この節では、「IP アドレスが 169.254 で始まる」のはどういう状態で、どう直すのかが分かります。

DHCP サーバーから返事が無いと、機器は 169.254.0.0/16 の中から自分でアドレスを選びます。 RFC 3927 が定める IPv4 リンクローカルアドレスで、Windows では APIPA（Automatic Private IP Addressing）と呼びます。同じセグメントの機器とは通信できますが、ルーターを越えられないため、インターネットには出られません。

Linux でこの動きをする avahi-autoipd を、DHCP サーバーを止めた netns で動かしました。

$ ip netns exec t10cli avahi-autoipd --debug --no-drop-root --script ./autoipd.sh t10veth1
Starting with address 169.254.3.233
State transition START-0 -> WAITING_PROBE-0
State transition WAITING_PROBE-0 -> PROBING-0
State transition PROBING-1 -> WAITING_ANNOUNCE-0
Callout BIND, address 169.254.3.233 on interface t10veth1
Successfully claimed IP address 169.254.3.233

$ ip -n t10cli -4 addr show t10veth1
    inet 169.254.3.233/16 brd 169.254.255.255 scope link t10veth1
$ ip -n t10cli route
169.254.0.0/16 dev t10veth1 proto kernel scope link src 169.254.3.233

選んだアドレスをほかの機器が使っていないか、ARP で3回確かめてから（probe）、2回宣言（announce）しています。tcpdump の原文です。

17:46:48.456250 ARP, Request who-has 169.254.3.233 tell 0.0.0.0, length 28
17:46:50.272190 ARP, Request who-has 169.254.3.233 tell 0.0.0.0, length 28
17:46:52.103267 ARP, Request who-has 169.254.3.233 tell 0.0.0.0, length 28
17:46:54.104511 ARP, Request who-has 169.254.3.233 tell 169.254.3.233, length 28
17:46:56.106258 ARP, Request who-has 169.254.3.233 tell 169.254.3.233, length 28

RFC 3927 の PROBE_NUM=3・ANNOUNCE_NUM=2・ANNOUNCE_INTERVAL=2 秒のとおりです。経路表に default（デフォルトゲートウェイ）が無いことが、「つながっているのに外に出られない」理由です。

• 1ルーター（DHCP サーバー）が起動しているか再起動直後は DHCP が立ち上がるまで返事が無い
• 2ケーブル・Wi-Fi が本当につながっているかリンクが無ければ DISCOVER は届かない
• 3ルーターの DHCP サーバー機能が「有効」かアクセスポイントモードにすると DHCP は上位のルーターが担当する
• 4割り当て範囲が埋まっていないか範囲が 16 台分で機器が 20 台なら、残りはもらえない
• 5IP アドレスを取り直すWindows は ipconfig /release → /renew、Mac は「DHCPリースを更新」

固定IPとDHCPの使い分け（判断表）

この節では、どの機器を固定（または予約）にして、どの機器を DHCP のままにするかの決め方が分かります。

「ほかの機器から名指しでアクセスされる機器」は固定か予約、「自分からアクセスしに行くだけの機器」は DHCP が基本です。

機器側で固定にするときは、ルーターの配る範囲（例：192.168.50.100〜150）の外のアドレス（例：192.168.50.20）を選びます。範囲の中を手で使うと、同じアドレスが DHCP で配られて衝突することがあります。サブネットマスクと範囲の考え方は、関連記事「サブネットマスクとは｜計算方法・早見表・確認方法を図と実例で解説」で扱っています。

家庭用ルーターの設定項目の読み方（公式マニュアルで確認）

この節では、ルーターの設定画面にある DHCP の項目が、それぞれ何を意味するのかが分かります。

どのメーカーも、項目は「DHCP サーバーを使うか」「配る範囲」「リース時間」「固定割当（MAC と IP の組）」の4つに集約されます。 公式マニュアルで確かめた2機種の項目名です。

ELECOM のマニュアルは、アクセスポイントモードや中継器モードでは別の画面になると書いています。ルーターを2台つないだときに DHCP サーバーが2つになると、機器がどちらの提案を受けるかで設定が変わってしまうため、片方はアクセスポイントモードにするか DHCP を無効にします。ルーターとハブ・スイッチの役割の違いは、関連記事「ハブとは｜スイッチ・ルーターとの違いと仕組みを実例で解説」で扱っています。

DHCPリレー（別のセグメントのサーバーから配る）

この節では、DHCP サーバーが別のネットワークにあるときに、どうやって DISCOVER を届けるのかが、実物で分かります。

DISCOVER はブロードキャストなのでルーターを越えません。そこで、クライアントと同じセグメントにいるルーター（リレーエージェント）が、DISCOVER を受け取ってサーバーへユニキャストで転送します。 会社のように部署ごとにセグメントが分かれていて、DHCP サーバーは1台にまとめたいときの構成です。

netns を4つにして再現しました。クライアント（10.10.0.0/24 側）→ リレー（dnsmasq の dhcp-relay=10.10.0.1,10.0.0.1）→ サーバー（10.0.0.1）です。

[クライアント側で取った tcpdump]
17:48:06.320067 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:42:ac:10:00:77, length 300
17:48:06.321075 IP 10.10.0.1.67 > 10.10.0.101.68: BOOTP/DHCP, Reply, length 300

[サーバー側で取った tcpdump：リレーがユニキャストで転送している]
17:48:06.320193 IP 10.10.0.1.67 > 10.0.0.1.67: BOOTP/DHCP, Request from 02:42:ac:10:00:77, length 300
	  Gateway-IP 10.10.0.1
	    DHCP-Message (53), length 1: Discover
17:48:06.321033 IP 10.0.0.1.67 > 10.10.0.1.67: BOOTP/DHCP, Reply, length 300
	  Your-IP 10.10.0.101
	  Gateway-IP 10.10.0.1
	    DHCP-Message (53), length 1: Offer

[リレーのログ]
dnsmasq-dhcp[18205]: DHCP relay at 10.10.0.1 -> 10.0.0.1
[サーバーのログ]
dnsmasq-dhcp[18202]: 1675715661 DHCPDISCOVER(t10sr) 02:42:ac:10:00:77
dnsmasq-dhcp[18202]: 1675715661 DHCPOFFER(t10sr) 10.10.0.101 02:42:ac:10:00:77

見どころは Gateway-IP（giaddr）の欄です。リレーが自分のアドレス 10.10.0.1 を書き込んで転送し、サーバーはそれを見て「10.10.0.0/24 のセグメントから来た」と判断し、そのセグメント用の範囲（10.10.0.100〜150）から配っています。返事も giaddr 宛てに返り、リレーがクライアントに渡します（RFC 2131 の giaddr の決まりのとおり）。クライアントから見ると、サーバーが同じセグメントにいるときと同じ4パケットです。

業務用のルーターやスイッチでは「DHCP リレー」「ip helper-address」などの名前で設定します。オプション 82（Relay Agent Information）を使うと、リレーが「どのポートから来たか」をサーバーに伝えられます。

Windows・Mac・LinuxでDHCPの状態を確かめる・取り直す

この節では、自分の機器が DHCP で何をもらったかを見る方法と、取り直す方法が分かります。

Microsoft の公式ドキュメントは、/release を「DHCPRELEASE メッセージを DHCP サーバーに送信して、現在の DHCP 構成を解放し…IP アドレス構成を破棄します」、/renew を「DHCP 構成を更新します」と説明し、どちらも IP アドレスを自動で取得する設定のアダプターでだけ使える、としています。ipconfig /all の読み方は、関連記事「ipconfigの使い方とMTUとは｜/all・/flushdnsとMTUの実例」で扱っています。

Apple の公式ガイド「Macの「TCP/IP」設定を変更する」は、「IPv4の設定」の選択肢として「DHCPサーバを使用」「DHCPサーバを使用（アドレスは手入力）」「手入力」「オフ」を挙げています。「DHCPサーバを使用（アドレスは手入力）」は、IP アドレスだけ自分で決めて、ゲートウェイや DNS は DHCP からもらう形で、RFC 2131 の DHCPINFORM にあたります。

手元で試す：ip netnsとdnsmasqでDHCPサーバーを作る

この節では、この記事の実験を自分の Linux で再現する手順が分かります。ホストのネットワーク設定は変えません。

veth（仮想のケーブル）で2つの netns をつなぎ、片方に dnsmasq、片方にクライアントを置きます。 本物の LAN に DHCP サーバーをもう1台立てると、ほかの機器が誤ったアドレスをもらうので、必ず隔離した空間で試します。

# 1. 2つの空間と仮想ケーブル
ip netns add t10srv; ip netns add t10cli
ip link add t10veth0 type veth peer name t10veth1
ip link set t10veth0 netns t10srv; ip link set t10veth1 netns t10cli
ip -n t10srv addr add 192.168.50.1/24 dev t10veth0
ip -n t10srv link set t10veth0 up; ip -n t10cli link set t10veth1 up

# 2. サーバー側で dnsmasq（DHCP だけ。DNS は port=0 で止める）
cat > dnsmasq.conf <<'EOF'
port=0
interface=t10veth0
bind-interfaces
dhcp-range=192.168.50.100,192.168.50.150,255.255.255.0,2m
dhcp-option=option:router,192.168.50.1
dhcp-option=option:dns-server,192.168.50.1
dhcp-leasefile=./dnsmasq.leases
log-dhcp
log-facility=./dnsmasq.log
EOF
ip netns exec t10srv dnsmasq --conf-file=./dnsmasq.conf --pid-file=./dnsmasq.pid

# 3. クライアント側で tcpdump を取りながら udhcpc
ip netns exec t10cli tcpdump -i t10veth1 -n -vv 'port 67 or port 68' &
ip netns exec t10cli busybox udhcpc -i t10veth1 -f -q -n -s ./udhcpc.sh

# 4. 片付け（netns を消すと中の veth も消える）
kill $(cat dnsmasq.pid); ip netns del t10cli; ip netns del t10srv

udhcpc と dhclient は、アドレスをもらうとスクリプトを呼び、環境変数で値を渡します。既定のスクリプトは /etc/resolv.conf を書き換えるので、手元では ip addr add だけを行う自作スクリプトを渡しました。

#!/bin/sh
# udhcpc.sh：netns の中のインターフェースだけ設定し、/etc には書かない
echo "[script] event=$1 ip=$ip mask=$mask router=$router dns=$dns lease=$lease"
case "$1" in
  deconfig) ip -4 addr flush dev "$interface" ;;
  bound|renew)
    ip -4 addr flush dev "$interface"
    ip addr add "$ip/$mask" broadcast "$broadcast" dev "$interface"
    [ -n "$router" ] && ip route replace default via "$router" dev "$interface"
    ;;
esac

パケットを画面で追いたいときは、Wireshark で dhcp（または bootp）のフィルターを使います。使い方は、関連記事「Wiresharkの使い方｜画面の見方・フィルター早見表を実例で解説」で扱っています。

IPv6のDHCPv6とSLAAC（短く）

この節では、IPv6 ではアドレスの自動設定がどう変わるのかが、要点だけ分かります。

IPv6 には、ルーターの広告（RA）だけで自分のアドレスを作る SLAAC と、IPv4 と同じようにサーバーから配る DHCPv6 の2つがあり、併用もできます。 RFC 9915（RFC 8415 を置き換えた DHCPv6 の仕様）は、DHCPv6 は SLAAC の代わりにも、SLAAC と併用することもできる、と書いています。

• DHCPv6 の Rapid Commit を使うと、Solicit と Reply の2パケットで終わります（RFC 9915）。
• DHCPv6 はデフォルトゲートウェイを配りません。IPv6 のゲートウェイは RA（ルーター広告）で知ります。
• Windows の ipconfig /renew6 は DHCPv6 の構成を更新します（Microsoft の公式ドキュメント）。
• dnsmasq は enable-ra と dhcp-range の IPv6 指定で、RA と DHCPv6 の両方を出せます（dnsmasq のマニュアル）。この記事の環境はカーネルが IPv6 に対応していなかったため、実行はしていません。

よくあるエラー／つまずき（原文つき）

この節では、DHCP まわりで見かける症状と文言、原因、直し方が一覧で分かります。

「IP アドレスはもらえたのにつながらない」ときは、ゲートウェイと DNS の値を疑います。切り分けの順番は、関連記事「グローバルIPの確認方法｜コマンド・プライベートIPとの違いとNATを実演」で扱っています。

DHCPの注意点（単一障害点・不正なサーバー・枯渇）

DHCP を運用するときに知っておく弱点と、その対策です。

よくある質問

Q. DHCPとは何ですか？ A. ネットワークにつないだ機器に、IP アドレス・サブネットマスク・デフォルトゲートウェイ・DNS サーバーなどの設定を自動で配るプロトコルです。家庭では Wi-Fi ルーターが DHCP サーバーの役目をしています。

Q. DHCPの仕組みを一言で言うと？ A. 機器が「アドレスをください」と全員に呼びかけ（DISCOVER）、サーバーが候補を出し（OFFER）、機器が選び（REQUEST）、サーバーが確定する（ACK）の4パケットです。手元では 37 ミリ秒で終わりました。

Q. DHCPはどのポートを使いますか？ A. UDP の 67 番（サーバー側）と 68 番（クライアント側）です。IPv6 の DHCPv6 は 547 番（サーバー・リレー）と 546 番（クライアント）です。

Q. リース期間とは何ですか？ A. DHCP で借りたアドレスを使っていられる時間です。半分の時点（T1）で機器がサーバーに延長を頼み、87.5% の時点（T2）までに返事が無ければ全員宛てに頼み、期限が切れるとアドレスを捨てて最初からやり直します。

Q. IPアドレスが 169.254 で始まります。 A. DHCP サーバーから返事が無かったため、機器が自分で付けたリンクローカルアドレスです。ルーターを越えられないのでインターネットには出られません。ルーターの状態と接続を確かめ、アドレスを取り直します。

Q. DHCPと固定IPはどちらがよいですか？ A. ほかの機器から名指しされるサーバー・NAS・プリンター・ネットワーク機器は固定か予約、PC・スマホのように数が多く入れ替わる機器は DHCP が向いています。家庭や小規模オフィスでは、ルーターの「固定割当（予約）」でまとめるのが管理しやすいです。

Q. 同じ機器にいつも同じIPアドレスを配るには？ A. DHCP サーバー（ルーター）に、その機器の MAC アドレスと IP アドレスの組を登録します。NEC Aterm なら「DHCP固定割当設定」、ELECOM なら「DHCPサーバー固定設定」、dnsmasq なら dhcp-host=MAC,IP です。

Q. DHCPサーバーが別のネットワークにあっても使えますか？ A. 使えます。クライアント側のルーターに DHCP リレーを設定すると、ブロードキャストの DISCOVER をサーバーへユニキャストで転送します。サーバーは giaddr（リレーのアドレス）を見て、そのセグメント用の範囲から配ります。

Q. DHCPで配られるのはIPアドレスだけですか？ A. いいえ。サブネットマスク（1）・ルーター（3）・DNS（6）・ドメイン名（15）・リース時間（51）など、番号付きのオプションで多くの設定を配れます。NTP サーバー（42）などはサーバー側に設定があれば配られます。

Q. ルーターを2台つないだら通信が不安定になりました。 A. DHCP サーバーが2つになり、機器がどちらの提案を受けるかで設定が変わる状態です。2台目はアクセスポイント（ブリッジ）モードにするか、DHCP サーバー機能を無効にします。

Q. Windowsで IP アドレスを取り直すには？ A. コマンドプロンプトで ipconfig /release のあと ipconfig /renew を実行します。Microsoft の公式ドキュメントによると、/release は DHCPRELEASE をサーバーに送って構成を破棄し、/renew は DHCP 構成を更新します。

Q. DHCPはIPv6でも使いますか？ A. IPv6 では、ルーターの広告だけでアドレスを作る SLAAC と、サーバーから配る DHCPv6 があり、併用できます。DHCPv6 はゲートウェイを配らず、ゲートウェイはルーター広告から知ります。

まとめ

• DHCP は、IP アドレス・マスク・ゲートウェイ・DNS・リース時間を自動で配るプロトコル。UDP 67/68 で、DISCOVER→OFFER→REQUEST→ACK の4パケットで決まる（手元で 37 ミリ秒）。
• アドレスは「借りる」もの。リースの 50%（T1）で元のサーバーに直接 REQUEST、87.5%（T2）で全員宛てに切り替え、期限切れでやり直す。手元の 120 秒のリースでは 58 秒後に更新の REQUEST と ACK が流れた。
• いつも同じアドレスにしたい機器は、サーバー側の MAC 予約（dhcp-host・ルーターの固定割当）か機器側の固定。固定は配る範囲の外にする。
• DHCP の返事が無いと 169.254 のリンクローカルアドレスになり、ARP で3回確かめてから使う。デフォルトゲートウェイが無いので外には出られない。
• DISCOVER はルーターを越えないため、別セグメントのサーバーから配るときは DHCP リレーが giaddr を書いてユニキャストで転送する。IPv6 は DHCPv6（546/547）と SLAAC の併用。

参考・出典

確認日はいずれも 2026年10月29日です。

• IETF「RFC 2131 Dynamic Host Configuration Protocol」：https://www.rfc-editor.org/rfc/rfc2131
• IETF「RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses」：https://www.rfc-editor.org/rfc/rfc3927
• IETF「RFC 9915 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)」：https://www.rfc-editor.org/rfc/rfc9915
• dnsmasq「Dnsmasq man page」（--dhcp-range・--dhcp-host・--dhcp-relay・--no-ping・--dhcp-option）：https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
• Microsoft「ipconfig」（/all・/release・/renew・/release6・/renew6）：https://learn.microsoft.com/ja-jp/windows-server/administration/windows-commands/ipconfig
• Apple「Macの「TCP/IP」設定を変更する」：https://support.apple.com/ja-jp/guide/mac-help/mh14129/mac
• NEC「Aterm WX3600HP ユーザーズマニュアル DHCP固定割当を設定する」：https://www.aterm.jp/function/wx3600hp/guide/dhcpfixedset.html
• ELECOM「WRC-BE100XS ユーザーズマニュアル LAN設定」：https://www.elecom.co.jp/support/manual/network/wireless-lan/router/wrc-be100xs-h/usersmanual/05/section05.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。