next up previous contents
Next: 色々な DHCP の実装 Up: DHCP Previous: DHCP

どうやって通信するか?

以下簡単に IP アドレスが不明な段階でどうやってサーバとクライアントが通信 するかを解説します。但し、DHCP を使う上で必要 最低限のスケッチを与える事を目標としますので、厳密には正しくない表現も ありますので、疑問の方は、RFC951,2131,2132 などの文書を読んで下さい。

 

TCP/IP では、IP がなければ通信は出来ない筈です。しかし、ここで問題になっている のは、その IP を他から提供してもらう事なのです。ここに、DHCP の実装上の問題が あり、システムによっては動かない場合もある理由があります。ここで TCP/IP が階層構造を持っていたことを思い出して下さい。最低限の通信のための仕組み は IP がない状態でも TCP/IP には実はあるのです。そうです、MAC アドレスです。 MAC アドレスさえ分かれば、相手への通信は原理的には可能です。そこで、DHCP に よってサービスを受けたいクライアントは、まず、ブロードキャストを流します。 通常 IP でのブロードキャストアドレスは、[ネットワーク部].255 の形 なのですが、クライアントはまだ IP そのものが分からない訳ですから、この ネットワーク部分そのものが分かりません。そこで all 1 のブロードキャストを 送り出します。一方、自分の IP アドレスには 0.0.0.0 を用います。 このパケットには、当然自分の MAC アドレスは入っている訳ですから、 同じネットワーク上にある DHCP サーバはこのパケットをキャッチすれ ば、サービスを要求しているクライアントの MAC アドレスを知ることが出来るので す。宛て先 IP アドレスには、255.255.255.255 を用います。 WindowsなどのDHCPクライアントはall 1以外のネットワーク部があるブロードキャスト を捕捉できないために(クライアントはまだネットワーク部を知らない訳ですから、 202.11.100.255のようなブロードキャストをDHCPプロトコルで出すのは問題 ではあるのですが)、サーバによってはDHCPサーバになれないものもあります。

 

概略は以上の通りなのですが、もう少し実際の動きを見てみましょう。 クライアントはまずDHCPサーバを探索するために、DHCPDISCOVERメッセージ をブロードキャストで流します。このメッセージを受けとったDHCPサーバは DHCPOFFERメッセージをクライアントに出します。このDHCPOFFERには 提供するIPアドレスなどの情報が入っていますが、あくまでも「申し出」で あってクライアントへの正式なIPの割り当てではありません。クライアントは次に offer されたIPアドレスを使いたい旨をDHCPREQUESTメッセージをブロードキャスト で流すことで通知します。最後に、正式に割り当てが成功したことをサーバから DHCPACKメッセージをクライアントに送ることでIP割り当てのシーケンスが 終わります。IPの貸し出し期間が過ぎる前にクライアントはそのIPの貸し出しの 延長を先の後半のやりとりの DHCPREQUEST を行う事によって申し出ます。 もし、延長も効かなくなると、最終的に最初からやり直しをします。

このように、このプロトコルを見れば分かるとおり、プロトコル上は同一セグメント に複数のDHCPサーバがあっても動作する筈ですが、IPの衝突をしないように アドレスプールの管理は人間が行わなければなりません。また、Windowsでは 必ずしもこのシーケンス通りではなく、貸し出し延長をユニキャストで行うために、 DHCPサーバが最初のものではなく、新しいものに初回貸し出しから変更が された場合うまく行かない場合があるようです。こうした場合にはユーザは マシンの立ち上げを行うか、winipcfgやipconfig などのツールでIPの開放を手動で行う必要があります。 (win2000 などでは困った事に ipconfig でIPを開放(release)しないと、 新しいIPを取得出来ません)  

DHCPではブロードキャストが基本となるために、そのサポートはセグメント内部 に限られてしまいます。これを一元管理するためにDHCPリレーサーバと呼ばれる ものを置く場合もあります。リレーサーバはDHCPリクエストをセグメント外の DHCPサーバに文字どおりリレーし、サーバの応答をクライアントに返します。 これによって、DHCPでサービスするIPアドレス資源を一元管理することが 出来ますが、DHCPリレーサーバというサーバが必要なのは同じなので、 そうした一元管理が得かどうかは場合によるでしょう。一方、ルータによっては こうしたリレーサーバと同じような働きをするものもあるので、そうした場合には 一元管理のメリットのみが残るでしょう。更に、DHCPサーバ自体になれる ルータもありますが、融通がきかないこともあるようです。

このようなDHCPの仕組みは実は、 BOOTP (Bootstrap Protocol) というものを発展させたもので、 基本的には TCP/IP の RARP (Reverse Address Resolution Protocol) という仕組みが 用意されていたのです。BOOTP は、例えばディスクのない X 端末などをどうやって 動かすかということを目的に作られました。随分と昔から実はちゃんとタネは用意 されていたのです。



Noriyo Kanayama