☰

DHCPリクエストがリクエストと呼ばれるのはなぜですか

tag-icon • tag-icon networking dhcp
DHCPリクエストがリクエストと呼ばれるのはなぜですか

DHCP には、検出、提供、要求、確認の 4 つのステップがあります。

3 番目のステップはなぜ「リクエスト」と呼ばれるのでしょうか? このステップでは誰も何もリクエストしていないですよね?

クライアントは、DHCP サーバーによって提供された IP を受け入れると単純に伝えます。

このステップの「リクエスト」部分はどこにありますか?

答え1

はい、何か要求されています。

会話は次のように読み取れます:

Computer:  "I need an IP address!"          <-- This is the discover
Server:    "I have 10.11.12.13 available."  <-- This is the offer
Computer:  "May I have have 10.11.12.13?"   <-- This is the request
Server:    "Yes, you may."                  <-- This is the ack

他にもいろいろありますが、基本的にはこれがプロセスです。会話を考えると納得できます。できた次のようになります:

Computer:  "I need an IP address!"
Server1:   "I have 10.11.12.13 available."
Server2:   "I have 10.11.12.19 available."
Server3:   "I have 10.12.1.2 available."
Computer:  "May I have 10.11.12.13?"
Server1:   "Yes, you may."

この場合、3 つの DHCP サーバーがすべて検出パケットを受信し、3 つすべてがオファーで応答しました。クライアントは最初に受け取ったオファーを「選択」し、Server1 に要求で応答しました。アドレスがスコープ内にあり、使用可能であったため、Server1 はそれを許可しました。

Server2 と Server3 はリクエストを受け取っていないため、提供した IP を割り当てず、引き続き利用可能な状態になっています。追加のリクエスト手順がない場合は、1 つのクライアントが 1 つの IP アドレスではなく 3 つの IP アドレスを使い果たしていたでしょう。

答え2

クライアントはまだリースを持っていないので、リースを要求しているので、「リクエスト」と呼ばれます。リースの発行、検証、または延長を要求します。

答え3

3 番目のステップは、「私 (クライアント) はあなた (サーバー) の IP を使用したいと思います」です。次のステップはサーバーがそれを承認するか、承認しないかです。サーバーが承認と受け入れを承認しなければならないというのは馬鹿げているように聞こえます。

答え4

本当に好きウェス・サイードの回答複数の DHCP サーバーが、この要求が役立つ理由の 1 つである可能性があります。

もう 1 つの理由は、以前と同じアドレスを再利用しようとしていることです。

このリクエストは、アドレスを使用する許可を求めるリクエストです。Discover、Offer、Request、Acknowledgement は DORA と呼ばれることもあります。

#1: DISCOVER: クライアントはネットワークに（ブロードキャストメッセージ経由で）DHCPサーバーを要求します

#2: OFFER: DHCPサーバーが応答し、潜在的なアドレスを提供する

#3: 要求: エンドユーザーのマシン/デバイスはサーバーに要求を送信し、DHCPサーバーがそのデバイスに要求されたアドレスを割り当て/予約/使用するように要求します。

#4: ACKnowledge: 応答が NACK (否定応答) ではなく ACKnowledge である場合、要求は許可されたとみなされます。

ここで難しいのは、リクエストがオファーと一致する必要はありません。

たとえば、ラップトップがしばらくネットワークから切断され、その後 (同じネットワークまたは別のネットワークに) 接続しようとする場合、ラップトップは可能であれば同じアドレスを使用しようとする可能性があります。架空の会話の例を次に示します。

#1: DISCOVER: 0.0.0.0 が 255.255.255.255 に問い合わせます:「アドレスを提供してもらい、あなたが誰であるかを知ることはできますか?」 レイヤー 2 アドレスは、デバイスの MAC-48 アドレスから FF-FF-FF-FF-FF-FF (ブロードキャスト) に送信されます。

#2: OFFER: 192.168.0.10 は、「私は DHCP サーバーです。192.168.0.235 を使用するのはいかがですか?」と言います。これは IP アドレス 0.0.0.0 に送り返され、DHCP クライアントの MAC-48 アドレスに送信されます。

#3: REQUEST: 0.0.0.0 は 192.168.0.10 に「192.168.0.117 をいただけますか?」と伝えます (たとえば、ラップトップは以前 192.168.0.117 を使用していました。)

#4: NACK: 192.168.0.10 は「いいえ」と応答します。(おそらく、別のシステムが現在それを使用しています。)

#5: ラップトップは、希望していたアドレスを引き続き使用することができなくなります。

#6: (おそらく別の DISCOVER と OFFER の後で?) DHCP クライアントは別の REQUEST を作成します。したがって、この例ですでに示されている番号を使用して、0.0.0.0 は 192.168.0.10 に次のように伝えます: 「192.168.0.235 を譲ってもらえませんか?」

#6: ACK: DHCP サーバーは、「わかりました。192.168.0.235 は、今後 8 時間、お客様のために予約されています。このアドレスを引き続き予約したい場合は、その時間までに更新をリクエストしてください。そうしないと、このアドレスを他のユーザーに渡す可能性があります。」と応答します。

これは、REQUEST ステップのおかげで得られるもう 1 つの利点を示しています。

さて、REQUEST は設計の一部であるため、このステップは実際には電子会話の必須部分です。

DISCOVER と OFFER は、基本的に計画に関する会話です。REQUEST は、実際にコミットメントを取得しようとするものです。ACK が行われるまで、実際には何もコミットされません。DHCP サーバーは、1 台のマシンへのアドレスの割り当てを ACK するだけであれば、複数のマシンに同じアドレスを正当に OFFER できます (DHCP サーバーがこれを行う正当な理由があると言っているわけではありません。プロトコル/標準では、IP アドレスの競合を起こさずにそれが可能だと言っているだけです)。クライアントは、REQUEST の後にのみ送信される ACK を受信するまで、そのアドレスを使用することはできません。DHCP サーバーは、REQUEST の前に ACK を送信することはありません。これは、一般的な DHCP クライアントは REQUEST を送信するまで ACK を受け取る準備ができていないため、一般的な DHCP クライアントは予期しない ACK を無視して見逃してしまうためです。

関連情報