DHCPクライアントは、複数のDHCPOFFERSのどれを受け入れるかをどのようにして知るのですか？

写真のようなネットワークがあると想像してください。1つのレイヤー2ネットワーク上の6つのホスト、VLANなし。ネットワークは、それぞれ1つのDHCPサーバーを持つ2つのサブネットに分割されることになっています。DHCPサーバーには固定IPアドレスがあるため、DHCPサーバーが属しているサブネットは明らかです。

その後、新しいクライアントはプラグインされます。どのサブネットに属しているかについて何も知らず、DHCPDISCOVERをイーサネットブロードキャスト255.255.255.255に送信するため、両方のDHCPサーバーに送信されます。両方のサーバーがオファーで応答します。さて、ここに私の質問があります：クライアントはどのDHCPOFFERを受け入れるべきかをどのように知るのですか？

最も簡単な答え-先着順です。

複数のVLANがあり、10.10.10.0 / 24が10.10.20.0/24とは異なるVLAN上にある場合-ブロードキャストはVLANを通過しません。

DHCPサーバーがクライアントとは別のVLAN上にある場合、VLAN間のルーティングインターフェイス上のiphelperは、ブロードキャストを正しい場所に向けます。

同じVLAN内に2つの別個のネットワーク（またはその欠如）があり、異なるサブネットにサービスを提供しているシナリオ-レース。

DHCPは、次のトランザクションを使用して機能します。

1. DHCPディスカバリ（DHCPDISCOVER）-クライアントブロードキャスト-「DHCPサーバーはありますか？」
2. DHCPオファー（DHCPOFFER）-サーバーからクライアント-「ええ、私はここにいます、利用可能です！」
3. DHCPリクエスト（DHCPREQUEST）-クライアントからサーバーへ「素晴らしい、アドレスを教えてもらえますか？」
4. DHCP Acknowledgment（DHCPACK）-サーバーからクライアントへ「もちろん、IP、マスク、ゲートウェイ、一部のDNS / WINSサーバー、タイムサーバー、およびスコープに設定されたその他すべてのものです」

これはすべて、サーバーのUDPポート67およびクライアントの68で発生します。

ステップ2に到達するとすぐに-クライアントは他のDHCPサーバーの応答を「聞く」のをやめます-最初のサーバーに満足して対処し、それに注意を向けます。

サイドノートとして-この権利を悪用するDoS（サービス拒否）攻撃のシリーズが実際にあります。攻撃者は、デバイスにプラグインし、DHCPOFFERパケットに応答して送信します。その後、何度も何度もDHCPACKERを送信しません。「偽の」DHCPサーバーがルーティングできないアドレスを提供したり、ネットワークを混乱させようとする他のIPと競合するアドレスを提供するDoS攻撃もあります。

@ Fazer87からの既存の回答は実際にはほぼ正しいので、それを支持して受け入れることをお勧めします。この回答では、もう少し詳細に少し詳しく説明します。

両方のDHCPサーバーがDHCPOfferメッセージで応答する場合があります。

DHCPクライアントは、「先着順」でそれらを受け入れる場合があります。ただし、そのアプローチを取る必要はありません。

RFC2131の指定：

クライアントは、1つ以上のサーバーから1つ以上のDHCPOFFERメッセージを受信します。クライアントは、複数の応答を待つことを選択できます。クライアントは、DHCPOFFERメッセージで提供される構成パラメーターに基づいて、構成パラメーターを要求するサーバーを1つ選択します。

そのため、2番目のDHCPサーバーがより長いIPアドレスの予約を提供した場合、または他のDHCPサーバーが提供しなかったタイムサーバーを提供した場合、またはクライアントが優先するようにプログラムされたカスタムフィールドがあった場合、2番目の提供を受け入れる場合があります。

通常、「先着順」のアプローチでは、デバイス間のいくつかのホップ（BOOTP再ブロードキャスト）を経ていないオファーを取得できるため、気にする理由がない場合は従うのに適したプロトコルです。

私は、カスタムデバイスが、更新されたファームウェアを見つけることができるTFTPサーバーを含むDHCPOfferを好むプロジェクトにいました。