Step1 やりとりを追いかけてみよう
四つのメッセージを交わせば
設定情報がもらえる

 どんな設定情報がもらえるかという話はStep2に任せて,Step1ではDHCPのやりとりを見ていこう。

 その前に,DHCP通信のプレーヤから確認しておこう。

 登場するプレーヤは二人。IPアドレスなどの設定情報を割り当ててもらうDHCPクライアントと,設定情報を一元管理してDHCPクライアントに情報を割り当てるDHCPサーバーだ。

 この二人が通信し合うことでDHCP通信は成り立つ。当然そこには,どんな手順でどんなフォーマットのパケットをやりとりするかというプロトコルが決まっている。この決まりがDHCPである。そして,実際にこの決まりに従って動くプログラムが二人のプレーヤの正体である。

図2 DHCPはどこにある?
IPアドレスなどの設定情報をもらうDHCPクライアントは,ほとんどのパソコンOSが備えている。一方,DHCPサーバーはサーバーOSやブロードバンド・ルーターが持っている。
図3 DHCP通信は四つのメッセージのやりとりで成り立つ
パソコンがサブネット全体に届くブロードキャストで設定情報を要求することから始まる。
 DHCPクライアント用のプログラムは,WindowsやMacOSなど,たいていのパソコン用OSが標準で持っている(図2[拡大表示])。例えばWindowsでは,ネットワーク設定の画面からTCP/IPのプロパティを開き,「IPアドレスを自動的に取得する」と書かれたフィールドにチェックを付ければDHCPクライアント用のプログラムが有効になる。

 一方のDHCPサーバー用プログラムは,Windows2000ServerやLinuxリナックスなどのサーバーOSが標準で持っている。こうしたサーバーOSは,DHCPクライアント用ソフトも持っており,二つの役割を時と場合に応じて使い分ける。また,ブロードバンド・ルーターもDHCPサーバー用ソフトが内蔵されている。家庭などでブロードバンド・ルーターにパソコンをつなぐだけでインターネットへアクセスできるのは,このDHCPサーバーのおかげである。

通信はパソコン側から始まる

 DHCP通信のプレーヤを確認したところで,実際のやりとりを順番に見ていこう。

 最初はDHCPクライアントであるパソコンから始まる。パソコンが「私にIPアドレスなどの設定情報を割り当てて下さい」といった要求するメッセージを送信するのだ。このメッセージはDHCPディスカバーと呼ばれる(図3[拡大表示](1))。

 このメッセージを受け取ったDHCPサーバーは,パソコンに対して「このIPアドレスでどうですか」と提案するDHCPオファー・パケットを返信する(2)。DHCPサーバーはあらかじめ自分が割り当てられるIPアドレスを確保しているので,その中から選んで提案することになる。

 IPアドレスが提案されても,これで終わりではない。DHCPサーバーからのオファー・パケットを受信したパソコンは,DHCPサーバーから提案されたIPアドレスを実際に使いたい旨を伝える(3)。このメッセージはDHCPリクエストと呼ばれる。「リクエスト」と名が付いていることからもわかるように,こちらが正式な申請だと考えればよいだろう。

 そして最後に,このDHCPリクエストを受信したDHCPサーバーが,パソコンに対して,使用許諾にあたるDHCPアックを送る(4)。

 以上,(1)DHCPディスカバー,(2)DHCPオファー,(3)DHCPリクエスト,(4)DHCPアック——という四つのやりとりを経て,パソコンとDHCPサーバーのやりとりが完了し,パソコンはDHCPサーバーから設定情報を得る。このあとの実用編などで出てくる例外的な処理も,実はこの四つのやりとりの応用である。つまり,この四つのやりとりさえ押さえておけば,DHCP通信の知識の土台は完成だ。

一対一通信ではなく放送

 でも,ちょっと待った!

 パソコンはDHCPサーバーから設定情報をもらう前は,なにも情報がなかったはず。自分のIPアドレスもなければ,通信相手であるDHCPサーバーのアドレスも知らない。こんな状態で,どうやって,DHCPサーバーと通信したのだろうか——。

 その答えは,「ブロードキャスト」である。相手や自分のIPアドレスがわからないときでも,なんとか相手に情報を伝える手段として使える(別掲記事参照)。

 ブロードキャストは,その名が表すように,「通信」というよりも「放送」のイメージに近い。放送はテレビ塔などから電波を発信して,電波が届く範囲にあるすべてのアンテナが受信する。これと同じように,同じネットワークの中にあるすべての端末に向けてパケットを送信するのがブロードキャストである。この場合の「同じネットワーク」とは,ルーターで区切られた範囲(これを「サブネット」という)のことである。

 このブロードキャストでは,パケットのあて先IPアドレスが「255.255. 255.255」になる。このアドレスはブロードキャスト・アドレスと呼ばれ,IPではすべての端末が受信する決まりになっている。

パソコンからはネット全体に送信

 先ほどのパソコンとDHCPサーバー間のやりとりで,このブロードキャストがどのように活用されているかを再度確認しておこう。

 パソコンからDHCPサーバーへ最初に送信されるリクエスト・パケットは,ブロードキャストになる。パソコンはDHCPサーバーのアドレスを知らないから,サブネット全体に届くブロードキャストを使うのである。実際には,UDPポート番号が67番に向けてブロードキャスト・パケットが送信される。

 放送の例えに戻すと,DHCPサーバーはパソコンの発信電波を受信するために,ポート番号67番というアンテナで待ちかまえている。したがって,ポート番号67番あてのUDPパケットはDHCPサーバーのプログラムに届く。

 ところが,このDHCPリクエストに対するオファー・パケットはブロードキャストではなく,ユニキャストになる。最初にパソコンが発したDHCPディスカバー・パケット中に,パソコンのMAC(マック)アドレスが書き込まれていたからだ。MACアドレスはLANボードのROM(ロム)などに焼き込まれているので,パソコンは最初からこのアドレスを知っている。

 このMACアドレスをDHCPサーバーは読み取り,そこに向けてパケットを返信したのである。なお,このDHCPオファー・パケットはパソコンのUDP68番ポートに向かって送信される。

 そして,パソコンがブロードキャストでリクエストを送り,DHCPサーバーからユニキャストでオファーが返ってくる。まとめると,パソコンからDHCPサーバーへの通信はブロードキャスト,DHCPサーバーからパソコンへの通信はパソコンのMACアドレスあてのユニキャストになる。

念を入れて,重複していないか確認

 以上のようにして,パソコンは何の設定情報もない状態から自分のIPアドレスなどを取得する。しかし,パソコンの仕事はまだ続きがある。

 パソコンは念には念を入れて,DHCPサーバーから割り当てられたIPアドレスが本当にほかの端末で利用されていないか確認するのである。

図4 パソコンはDHCPサーバーから割り当てられた情報をそのまま鵜呑みにしない
DHCP通信が完了して設定情報が割り当てられたあと,パソコンはもらったIPアドレスがほかと重なっていないかを,ARP(アープ)というプロトコルを使って確認する。
 確認手順では,ARP(アープ)というプロトコルを使う(図4[拡大表示])。ARPの本来の目的は,通信相手のIPアドレスがわかっているときに,それに対応するMACアドレスを調べること。つまり,IPアドレスを明記したARP要求というパケットをブロードキャストすると,そのIPアドレスを持つ端末がMACアドレスを返信する。

 これをDHCP通信完了後のパソコンは,ちょっと違う目的で利用する。DHCPサーバーから割り当てられたIPアドレスを明記してARP要求を送信するのである。通常は,だれもこのIPアドレスを使っていないはずなので,応答は返ってこない。これで,ほかが利用していないことが確認できる。

 もし,DHCPサーバーから割り当ててもらったIPアドレスをほかが使っていたら,ARP要求に対する応答が返ってくる。この場合,パソコンは先ほど割り当てられたIPアドレスの利用停止を伝えるメッセージ(これをDHCPディクラインという)をDHCPサーバーへ送る。そして,最初からもう一度設定情報をもらい直す。

 なお,ARPを使ってIPアドレスが重複していないかを確認する方法は,DHCPの手順を定めているRFC2131では,必須項目になっていない。「できればやるべき」という推奨項目になっている。ただ,Windows98/Me/ 2000/XPやMacOSなどは,この推奨に従ってARPで重複していないことを確認してから,DHCPサーバーから割り当てられたIPアドレスを実際に使い始める作りになっている。

アドレスがなくてもIPやUDPは動く

図A DHCPはUDPの上で動くアプリケーション・プロトコル
なにも設定情報がない状態でもIPやUDPなどのプロトコル処理ソフトは動き出している。DHCPはこの状態でUDPを使って動く。
 IPアドレスなどの設定情報を要求するパソコンは,まだ設定情報を取得していない。物理的にネットワークにつながっているだけである。このため,設定情報を取得する前のパソコンでは,IPやその上位で動くTCP/UDPは動かず,イーサネット・レベル(データリンク層)の通信しかできないような気がする。ところが,意外なことに,DHCP自体はUDPの上位で動くアプリケーション・プロトコルである。Webアクセスに使うHTTPや,電子メールの送受信に使うSMTPなどと同じレベルのプロトコルなのだ(図A[拡大表示])。

 その理由は単純。IPやUDPなどのプロトコルを処理するプログラム自体は,設定情報がなくても動き始めているのだ。ただ,アドレス情報などがないので,いくつかの制約を受ける。

 例えば,自分自身に返信パケットをもらう場合,相手はあて先が決められないからユニキャストは使えない。またデフォルト・ゲートウエイも設定されていないので,ルーターを越える通信もできない。

 こうした制約を受けないでやりとりするのに適していたのが,相手を指定せずにネットワーク全体にパケットを届けるブロードキャストである。DHCPは,このブロードキャストをうまく利用することで,IPの設定情報がない状態でDHCPサーバーと通信し合って情報を取得するのである。