動的ホスト構成プロトコル

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

動的ホスト構成プロトコルDHCP)は、インターネットプロトコル(IP)ネットワークで使用されるネットワーク管理プロトコルであり、クライアントサーバーアーキテクチャを使用してネットワークに接続されたデバイスにIPアドレスやその他の通信パラメーターを自動的に割り当てます。[2]

このテクノロジは、ネットワークデバイスを手動で個別に構成する必要をなくし、中央にインストールされたネットワークDHCPサーバーと各コンピューターまたはデバイス上のプロトコルスタックのクライアントインスタンスの2つのネットワークコンポーネントで構成されます。ネットワークに接続すると、その後定期的に、クライアントはDHCPプロトコルを使用してDHCPサーバーに一連のパラメーターを 要求します。

DHCPは、住宅用ネットワークから大規模なキャンパスネットワークや地域のISPネットワークまでのサイズのネットワークに実装できます。[3]多くのルーターレジデンシャルゲートウェイにはDHCPサーバー機能があります。ほとんどの住宅用ネットワークルーターは、ISPネットワーク内で一意のIPアドレスを受け取ります。ローカルネットワーク内では、DHCPサーバーが各デバイスにローカルIPアドレスを割り当てます。

DHCPサービスは、インターネットプロトコルバージョン4(IPv4)およびバージョン6(IPv6 )を実行しているネットワーク用に存在しますDHCPプロトコルのIPv6バージョンは、一般にDHCPv6と呼ばれます。

歴史

リバースアドレス解決プロトコル(RARP)は、適切なIPアドレスを使用してディスクレスワークステーションなどの単純なデバイスを構成するために、1984年にRFC903で定義されましたデータリンク層で機能するため、多くのサーバープラットフォームでの実装が困難になりました。個々のネットワークリンクにサーバーが存在する必要がありました。RARPは、1985年9月にRFC 951で定義されたブートストラッププロトコル( BOOTP )に取って代わられました。これにより、ネットワーク間でBOOTPパケットを転送できるリレーエージェントの概念が導入され、1つの中央BOOTPサーバーが多くのIPサブネット上のホストにサービスを提供できるようになりました。[4]

DHCPはBOOTPに基づいていますが、プールからIPアドレスを動的に割り当て、使用されなくなったときにそれらを再利用できます。また、プラットフォーム固有のパラメーターを含む、さまざまな追加の構成パラメーターをIPクライアントに配信するためにも使用できます。[5] DHCPは1993年10月にRFC1531で最初に定義されましたが、編集プロセスのエラーのため、RFC1541としてほぼ即座に再発行されました。

4年後、DHCPINFORMメッセージタイプ[6]およびその他の小さな変更がRFC 2131によって追加されました。これは、2021年現在、RFC 3396、RFC 4361、RFC 5494、およびRFC 6842の更新により、IPv4ネットワークの標準のコアのままです。[7]

DHCPv6は、2003年にRFC 3315によって最初に記述されました。その後の多くのRFCによる更新の後、[8]プレフィックス委任ステートレスアドレス自動構成に統合されたRFC8415に置き換えられました

概要

インターネットプロトコル(IP)は、デバイスがインターネット上のローカルネットワーク内およびローカルネットワーク間で通信する方法を定義します。DHCPサーバーは、ローカルネットワーク上のデバイスのIP設定を管理できます。たとえば、それらのデバイスにIPアドレスを自動的かつ動的に割り当てることができます。

DHCPは、クライアントサーバーモデルに基づいて動作しますコンピュータまたは他のデバイスがネットワークに接続すると、DHCPクライアントソフトウェアは必要な情報を要求するDHCPブロードキャストクエリを送信します。ネットワーク上のすべてのDHCPサーバーが要求を処理できます。DHCPサーバーは、IPアドレスのプールと、デフォルトゲートウェイドメイン名ネームサーバータイムサーバーなどのクライアント構成パラメーターに関する情報を管理します。DHCPサーバーは、DHCP要求を受信すると、管理者によって以前に構成された各クライアントの特定の情報、またはネットワーク全体と割り当て(リース)期間に有効な特定のアドレスとその他の情報で応答する場合があります。)は有効です。DHCPクライアントは通常、起動直後、およびその後定期的に情報の有効期限が切れる前に、この情報を照会します。DHCPクライアントが割り当てを更新すると、最初は同じパラメータ値が要求されますが、DHCPサーバーは、管理者が設定した割り当てポリシーに基づいて新しいアドレスを割り当てる場合があります。

複数のリンクで構成される大規模なネットワークでは、相互接続ルーターに配置されたDHCPリレーエージェントの支援を受けて、単一のDHCPサーバーがネットワーク全体にサービスを提供する場合があります。このようなエージェントは、DHCPクライアントと異なるサブネット上にあるDHCPサーバーの間でメッセージを中継します。

実装に応じて、DHCPサーバーにはIPアドレスを割り当てる3つの方法があります。

動的割り当て
ネットワーク管理者はDHCP用にIPアドレスの範囲を予約し、 LAN上の各DHCPクライアントは、ネットワークの初期化中にDHCPサーバーにIPアドレスを要求するように構成されています。要求と許可のプロセスでは、制御可能な期間のリースコンセプトを使用して、DHCPサーバーが再利用し、更新されていないIPアドレスを再割り当てできるようにします。
自動割り当て
DHCPサーバーは、管理者によって定義された範囲から、要求元のクライアントにIPアドレスを永続的に割り当てます。これは動的割り当てに似ていますが、DHCPサーバーは過去のIPアドレス割り当てのテーブルを保持するため、クライアントが以前に持っていたのと同じIPアドレスを優先的にクライアントに割り当てることができます。
手動割り当て
この方法は、静的DHCP割り当て固定アドレス割り当て予約、およびMAC / IPアドレスバインディングとも呼ばれます。管理者は、各クライアントの一意の識別子(クライアントIDまたはMACアドレス)を、要求元のクライアントに提供されるIPアドレスにマップします。これが失敗した場合、DHCPサーバーは他の方法にフォールバックするように構成されている可能性があります。

DHCPサービスは、インターネットプロトコルバージョン4(IPv4)およびIPv6で使用されます。IPv4とIPv6のプロトコルの詳細は十分に異なるため、別々のプロトコルと見なすことができます。[9] IPv6操作の場合、デバイスは代わりにステートレスアドレス自動構成を使用する場合があります。IPv6ホストは、リンクローカルアドレス指定を使用して、ローカルネットワークリンクに制限された操作を実行することもできます。

操作

典型的な非更新DHCPセッションの図。各メッセージは、DHCPクライアントの機能に応じて、ブロードキャストまたはユニキャストのいずれかになります。[10]

DHCPは、ユーザーデータグラムプロトコル(UDP)を使用したコネクションレス型サービスモデルを採用しています。ブートストラッププロトコル( BOOTP )の場合と同じ操作用に2つのUDPポート番号を使用して実装されますUDPポート番号67はサーバーの宛先ポートであり、UDPポート番号68はクライアントによって使用されます。

DHCP操作は、サーバーの検出、IPリースの提供、IPリースの要求、およびIPリースの確認の4つのフェーズに分類されます。これらの段階は、発見、提供、要求、および確認のためにDORAと略されることがよくあります。

DHCP操作は、クライアントが要求をブロードキャストすることから始まります。クライアントとサーバーが異なるブロードキャストドメインにある場合は、DHCPヘルパーまたはDHCPリレーエージェントを使用できます。既存のリースの更新を要求するクライアントは、UDPユニキャストを介して直接通信できます。これは、クライアントがその時点ですでに確立されたIPアドレスを持っているためです。さらに、BROADCASTフラグ(2バイトフラグフィールドに1ビット、他のすべてのビットは予約されているため0に設定)があり、クライアントはDHCPOFFERを受信できる方法(ブロードキャストまたはユニキャスト)を示すために使用できます:0x8000ブロードキャストの場合は0x0000、ユニキャストの場合は0x0000。[10]通常、DHCPOFFERはユニキャストを介して送信されます。IPアドレスが設定される前にユニキャストパケットを受け入れることができないホストの場合、このフラグを使用してこの問題を回避できます。

発見

DHCPクライアントは、宛先アドレス255.255.255.255(制限付きブロードキャスト)または特定のサブネットブロードキャストアドレス(ダイレクトブロードキャスト)を使用して、ネットワークサブネット上でDHCPDISCOVERメッセージをブロードキャストします。DHCPクライアントは、最後の既知のIPアドレスを要求する場合もあります。クライアントが同じネットワークに接続されたままの場合、サーバーは要求を許可する場合があります。それ以外の場合は、サーバーが権限のあるものとして設定されているかどうかによって異なります。権限のあるサーバーが要求を拒否し、クライアントに新しい要求を発行させます。権限のないサーバーは単に要求を無視するため、クライアントが要求を期限切れにして新しいIPアドレスを要求するための実装に依存するタイムアウトが発生します。

たとえば、HTYPEが1に設定されている場合、使用されるメディアがイーサネットであることを指定すると、イーサネットアドレス(MACアドレス)の長さが6オクテットであるため、HLENは6に設定されます。CHADDRは、クライアントが使用するMACアドレスに設定されます。いくつかのオプションも設定されています。

DHCPDISCOVERメッセージの例

イーサネット:source =送信者のMAC; 宛先= FF:FF:FF:FF:FF:FF

IP:ソース= 0.0.0.0; destination = 255.255.255.255
UDP:送信元ポート= 68; 宛先ポート= 67

オクテット0 オクテット1 オクテット2 オクテット3
OP HTYPE HLEN ホップ
0x01 0x01 0x06 0x00
XID
0x3903F326
SECS フラグ
0x0000 0x0000
CIADDR(クライアントIPアドレス)
0x00000000
YIADDR(あなたのIPアドレス)
0x00000000
SIADDR(サーバーIPアドレス)
0x00000000
GIADDR(ゲートウェイIPアドレス)
0x00000000
CHADDR(クライアントハードウェアアドレス)
0x00053C04
0x8D590000
0x00000000
0x00000000
0の192オクテット、または追加オプション用のオーバーフロースペース。BOOTPレガシー。
マジッククッキー
0x63825363
DHCPオプション
0x350101 53:1(DHCP検出)
0x3204c0a80164 50:192.168.1.100が要求されました
0x370401030f06 55(パラメータリクエストリスト):
  • 1(サブネットマスクの要求)、
  • 3(ルーター)、
  • 15(ドメイン名)、
  • 6(ドメインネームサーバー)
0xff 255(エンドマーク)

オファー

DHCPサーバーがクライアントからDHCPDISCOVERメッセージ(IPアドレスリース要求)を受信すると、DHCPサーバーはクライアントのIPアドレスを予約し、DHCPOFFERメッセージをクライアントに送信してリースオファーを行います。このメッセージには、クライアントのクライアントID(従来はMACアドレス)、サーバーが提供しているIPアドレス、サブネットマスク、リース期間、および提供しているDHCPサーバーのIPアドレスが含まれています。DHCPサーバーは、基盤となるトランスポート層のハードウェアレベルのMACアドレスにも注意を向けることができます。現在のRFCによると、DHCPパケットにクライアントIDが指定されていない場合、トランスポート層のMACアドレスが使用されることがあります。

DHCPサーバーは、CHADDR(クライアントハードウェアアドレス)フィールドで指定されたクライアントのハードウェアアドレスに基づいて構成を決定します。ここで、サーバー192.168.1.1は、YIADDR(IPアドレス)フィールドにクライアントのIPアドレスを指定します。

DHCPOFFERメッセージの例

イーサネット:source =送信者のMAC; destination = clientmacアドレス

IP:ソース= 192.168.1.1; destination = 255.255.255.255
UDP:送信元ポート= 67; 宛先ポート= 68

オクテット0 オクテット1 オクテット2 オクテット3
OP HTYPE HLEN ホップ
0x02 0x01 0x06 0x00
XID
0x3903F326
SECS フラグ
0x0000 0x0000
CIADDR(クライアントIPアドレス)
0x00000000
YIADDR(あなたのIPアドレス)
0xC0A80164(192.168.1.100)
SIADDR(サーバーIPアドレス)
0xC0A80101(192.168.1.1)
GIADDR(ゲートウェイIPアドレス)
0x00000000
CHADDR(クライアントハードウェアアドレス)
0x00053C04
0x8D590000
0x00000000
0x00000000
0の192オクテット; BOOTPレガシー。
マジッククッキー
0x63825363
DHCPオプション
53:2(DHCPオファー)
1(サブネットマスク):255.255.255.0
3(ルーター):192.168.1.1
51(IPアドレスリース時間):86400秒(1日)
54(DHCPサーバー):192.168.1.1
6(DNSサーバー):
  • 9.7.10.15、
  • 9.7.10.16、
  • 9.7.10.18

リクエスト

DHCPオファーに応答して、クライアントはDHCPREQUESTメッセージで応答し、サーバーにブロードキャストして、[a]オファーされたアドレスを要求します。クライアントは複数のサーバーからDHCPオファーを受け取ることができますが、受け入れるDHCPオファーは1つだけです。クライアントは、同じIPアドレスを持つ他のホストがネットワークに存在するかどうかを確認するために、GratuitousARPを生成します。他のホストからの応答がない場合、ネットワーク内に同じIP構成のホストはなく、メッセージはサーバーにブロードキャストされ、IPアドレスの受け入れを示します。クライアントは、クライアントがオファーを選択したサーバーを示す要求メッセージでサーバー識別オプションを送信する必要があります。[12] :セクション3.1、アイテム3 他のDHCPサーバーがこのメッセージを受信すると、クライアントに対して行ったオファーをすべて取り消し、提供されたIPアドレスを使用可能なアドレスのプールに返します。

DHCPREQUESTメッセージの例

イーサネット:source =送信者のMAC; 宛先= FF:FF:FF:FF:FF:FF

IP:ソース= 0.0.0.0; 宛先= 255.255.255.255; [a]
UDP:送信元ポート= 68; 宛先ポート= 67

オクテット0 オクテット1 オクテット2 オクテット3
OP HTYPE HLEN ホップ
0x01 0x01 0x06 0x00
XID
0x3903F326
SECS フラグ
0x0000 0x0000
CIADDR(クライアントIPアドレス)
0xC0A80164(192.168.1.100)
YIADDR(あなたのIPアドレス)
0x00000000
SIADDR(サーバーIPアドレス)
0xC0A80101(192.168.1.1)
GIADDR(ゲートウェイIPアドレス)
0x00000000
CHADDR(クライアントハードウェアアドレス)
0x00053C04
0x8D590000
0x00000000
0x00000000
0の192オクテット; BOOTPレガシー。
マジッククッキー
0x63825363
DHCPオプション
53:3(DHCP要求)
50:192.168.1.100が要求されました
54(DHCPサーバー):192.168.1.1

謝辞

DHCPサーバーがクライアントからDHCPREQUESTメッセージを受信すると、構成プロセスは最終フェーズに入ります。確認応答フェーズでは、DHCPACKパケットをクライアントに送信します。このパケットには、リース期間と、クライアントが要求した可能性のあるその他の構成情報が含まれています。この時点で、IP構成プロセスは完了です。

プロトコルは、DHCPクライアントがネゴシエートされたパラメータを使用してネットワークインターフェイスを設定することを想定しています。

クライアントはIPアドレスを取得した後、新しく受信したアドレス[13]をプローブして(たとえば、ARPアドレス解決プロトコルを使用して)、DHCPサーバーのアドレスプールの重複によって引き起こされるアドレスの競合を防ぐ必要があります。このプローブがそのアドレスを使用している別のコンピューターを検出した場合、コンピューターはDHCPDECLINEをブロードキャストでサーバーに送信する必要があります。

DHCPACKメッセージの例

イーサネット:source =送信者のMAC; destination =クライアントのMAC

IP:ソース= 192.168.1.1; destination = 255.255.255.255
UDP:送信元ポート= 67; 宛先ポート= 68

オクテット0 オクテット1 オクテット2 オクテット3
OP HTYPE HLEN ホップ
0x02 0x01 0x06 0x00
XID
0x3903F326
SECS フラグ
0x0000 0x0000
CIADDR(クライアントIPアドレス)
0x00000000
YIADDR(あなたのIPアドレス)
0xC0A80164(192.168.1.100)
SIADDR(サーバーIPアドレス)
0xC0A80101(192.168.1.1)
GIADDR(リレーによって切り替えられるゲートウェイIPアドレス)
0x00000000
CHADDR(クライアントハードウェアアドレス)
0x00053C04
0x8D590000
0x00000000
0x00000000
0の192オクテット。BOOTPレガシー
マジッククッキー
0x63825363
DHCPオプション
53:5(DHCP ACK)
1(サブネットマスク):255.255.255.0
3(ルーター):192.168.1.1
51(IPアドレスリース時間):86400秒(1日)
54(DHCPサーバー):192.168.1.1
6(DNSサーバー):
  • 9.7.10.15、
  • 9.7.10.16、
  • 9.7.10.18

情報

DHCPクライアントは、元のDHCPOFFERで送信されたサーバーよりも多くの情報を要求する場合があります。クライアントは、特定のアプリケーションの繰り返しデータを要求する場合もあります。たとえば、ブラウザはDHCP Informを使用して、 WPADを介してWebプロキシ設定を取得します

リリース

クライアントはDHCPサーバーに要求を送信してDHCP情報を解放し、クライアントはそのIPアドレスを非アクティブ化します。クライアントデバイスは通常、ユーザーがいつネットワークからプラグを抜くことができるかを知らないため、プロトコルはDHCPリリースの送信を義務付けていません。

クライアント構成パラメーター

DHCPサーバーは、オプションの構成パラメーターをクライアントに提供できます。RFC 2132は、 Internet Assigned Numbers Authority (IANA)によって定義された使用可能なDHCPオプション(DHCPおよびBOOTPパラメータ)について説明しています。[14]

DHCPクライアントは、DHCPサーバーによって提供されるパラメーターを選択、操作、および上書きできます。Unixライクなシステムでは、このクライアントレベルの改良は通常、構成ファイル/etc/dhclient.confの値に従って行われます

オプション

オプションは、さまざまな長さのオクテット文字列です。これはType-length-valueエンコーディングと呼ばれます。最初のオクテットはオプションコードであり、2番目のオクテットは後続のオクテットの数であり、残りのオクテットはコードに依存します。たとえば、オファーのDHCPメッセージタイプオプションは0x35、0x01、0x02として表示されます。ここで、0x35は「DHCPメッセージタイプ」のコード53、0x01は1オクテットが続くことを意味し、0x02は「オファー」の値です。

次の表に、RFC 2132 [15]およびIANAレジストリにリストされている使用可能なDHCPオプションを示します。[14]

RFC 1497(BOOTPベンダー情報拡張)ベンダー拡張[15] :セクション3 
コード 名前 長さ ノート
0 パッド[15] :セクション3.1  0オクテット 他のオプションをパディングして、単語の境界に揃えることができます。長さバイトが続かない
1 サブネットマスク[15] :セクション3.3  4オクテット 両方が含まれている場合は、ルーターオプション(オプション3)の前に送信する必要があります
2 時間オフセット[15] :セクション3.4  4オクテット
3 ルーター 4オクテットの倍数 使用可能なルーターは、優先順にリストする必要があります
4 タイムサーバー 4オクテットの倍数 同期に使用できるタイムサーバーは、優先順にリストする必要があります
5 ネームサーバー 4オクテットの倍数 使用可能なIEN116ネームサーバー。優先順にリストする必要があります
6 ドメインネームサーバー 4オクテットの倍数 使用可能なDNSサーバー。優先順にリストする必要があります
7 ログサーバー 4オクテットの倍数 使用可能なログサーバーは、優先順にリストする必要があります。
8 クッキーサーバー 4オクテットの倍数 この場合のCookieは、「フォーチュンCookie」または「今日の引用」を意味します。これは、大規模なコンピューターでのログオンプロセスの一部として送信されることが多い、うっとうしいまたはユーモラスな逸話です。Webサイトから送信されるCookieとは何の関係もありません
9 LPRサーバー 4オクテットの倍数
10 サーバーを印象付ける 4オクテットの倍数
11 リソースロケーションサーバー 4オクテットの倍数
12 ホスト名 最低1オクテット
13 ブートファイルサイズ 2オクテット 4KiBブロック単位のブートイメージの長さ
14 メリットダンプファイル 最低1オクテット クラッシュダンプを保存する必要があるパス
15 ドメイン名 最低1オクテット
16 スワップサーバー 4オクテット
17 ルートパス 最低1オクテット
18 拡張パス 最低1オクテット
255 終わり 0オクテット ベンダーオプションフィールドの終わりをマークするために使用されます
ホストごとのIP層パラメータ[15] :セクション4 
コード 名前 長さ ノート
19 IP転送の有効化/無効化 1オクテット
20 非ローカルソースルーティングの有効化/無効化 1オクテット
21 ポリシーフィルター 8オクテットの倍数
22 データグラム再構成の最大サイズ 2オクテット
23 デフォルトのIP存続時間 1オクテット
24 パスMTUエージングタイムアウト 4オクテット
25 パスMTUプラトーテーブル 2オクテットの倍数
インターフェイスごとのIPレイヤーパラメータ[15] :セクション5 
コード 名前 長さ ノート
26 インターフェイスMTU 2オクテット
27 すべてのサブネットはローカルです 1オクテット
28 ブロードキャストアドレス 4オクテット
29 マスク検出を実行する 1オクテット
30 マスクサプライヤー 1オクテット
31 ルーター検出を実行する 1オクテット
32 ルーター要請アドレス 4オクテット
33 静的ルート 8オクテットの倍数 宛先/ルーターペアのリスト
インターフェイスごとのリンク層パラメータ[15] :セクション6 
コード 名前 長さ ノート
34 トレーラーカプセル化オプション 1オクテット
35 ARPキャッシュタイムアウト 4オクテット
36 イーサネットカプセル化 1オクテット
TCPパラメータ[15] :セクション7 
コード 名前 長さ ノート
37 TCPデフォルトTTL 1オクテット
38 TCPキープアライブ間隔 4オクテット
39 TCPキープアライブガベージ 1オクテット
アプリケーションとサービスのパラメータ[15] :セクション8 
コード 名前 長さ ノート
40 ネットワーク情報サービスドメイン 最低1オクテット
41 ネットワーク情報サーバー 4オクテットの倍数
42 ネットワークタイムプロトコル(NTP)サーバー 4オクテットの倍数
43 ベンダー固有の情報 最小1オクテット
44 NetBIOS over TCP / IPネームサーバー 4オクテットの倍数
45 NetBIOS over TCP / IPデータグラム配布サーバー 4オクテットの倍数
46 NetBIOS over TCP / IPノードタイプ 1オクテット
47 NetBIOS over TCP / IPスコープ 最低1オクテット
48 X WindowSystemフォントサーバー 4オクテットの倍数
49 X WindowSystemディスプレイマネージャー 4オクテットの倍数
64 ネットワーク情報サービス+ドメイン 最低1オクテット
65 ネットワーク情報サービス+サーバー 4オクテットの倍数
68 モバイルIPホームエージェント 4オクテットの倍数
69 Simple Mail Transfer Protocol(SMTP)サーバー 4オクテットの倍数
70 Post Office Protocol(POP3)サーバー 4オクテットの倍数
71 ネットワークニュース転送プロトコル(NNTP)サーバー 4オクテットの倍数
72 デフォルトのワールドワイドウェブ(WWW)サーバー 4オクテットの倍数
73 デフォルトのFingerプロトコルサーバー 4オクテットの倍数
74 デフォルトのインターネットリレーチャット(IRC)サーバー 4オクテットの倍数
75 StreetTalkサーバー 4オクテットの倍数
76 StreetTalkディレクトリアシスタント(STDA)サーバー 4オクテットの倍数
DHCP拡張機能[15] :セクション9 
コード 名前 長さ ノート
50 要求されたIPアドレス 4オクテット
51 IPアドレスのリース時間 4オクテット
52 オプションの過負荷 1オクテット
53 DHCPメッセージタイプ 1オクテット
54 サーバー識別子 4オクテット
55 パラメータリクエストリスト 最低1オクテット
56 メッセージ 最低1オクテット
57 DHCPメッセージの最大サイズ 2オクテット
58 更新(T1)時間値 4オクテット
59 再バインド(T2)時間値 4オクテット
60 ベンダークラス識別子 最低1オクテット
61 クライアント識別子 最低2オクテット
66 TFTPサーバー名 最低1オクテット
67 ブートファイル名 最低1オクテット

DHCPメッセージタイプ

この表は、RFC 2132、RFC 3203、[16] RFC 4388、[17] RFC 6926 [18]、およびRFC 7724に記載されているDHCPメッセージタイプを示しています。 [19] これらのコードは、DHCP拡張53の値です。上記の表。


DHCPメッセージタイプ
コード 名前 長さ RFC
1 DHCPDISCOVER 1オクテット rfc2132 [15] :セクション9.6 
2 DHCPOFFER 1オクテット rfc2132 [15] :セクション9.6 
3 DHCPREQUEST 1オクテット rfc2132 [15] :セクション9.6 
4 DHCPDECLINE 1オクテット rfc2132 [15] :セクション9.6 
5 DHCPACK 1オクテット rfc2132 [15] :セクション9.6 
6 DHCPNAK 1オクテット rfc2132 [15] :セクション9.6 
7 DHCPRELEASE 1オクテット rfc2132 [15] :セクション9.6 
8 DHCPINFORM 1オクテット rfc2132 [15] :セクション9.6 
9 DHCPFORCERENEW 1オクテット rfc3203 [16] :セクション4 
10 DHCPLEASEQUERY 1オクテット rfc4388 [17] :セクション6.1 
11 DHCPLEASEUNASSIGNED 1オクテット rfc4388 [17] :セクション6.1 
12 DHCPLEASEUNKNOWN 1オクテット rfc4388 [17] :セクション6.1 
13 DHCPLEASEACTIVE 1オクテット rfc4388 [17] :セクション6.1 
14 DHCPBULKLEASEQUERY 1オクテット rfc6926 [18] :セクション6.2.1 
15 DHCPLEASEQUERYDONE 1オクテット rfc6926 [18] :セクション6.2.1 
16 DHCPACTIVELEASEQUERY 1オクテット rfc7724 [19] :セクション5.2.1 
17 DHCPLEASEQUERYSTATUS 1オクテット rfc7724 [19] :セクション5.2.1 
18 DHCPTLS 1オクテット rfc7724 [19] :セクション5.2.1 

クライアントベンダーの識別

DHCPクライアントのベンダーと機能を識別するためのオプションがあります。情報は、DHCPクライアントのベンダーによって指定された意味を持つ文字またはオクテットの可変長文字列です。DHCPクライアントが特定の種類のハードウェアまたはファームウェアを使用していることをサーバーと通信できる1つの方法は、ベンダークラス識別子(VCI)(オプション60)と呼ばれるDHCP要求に値を設定することです。この方法により、DHCPサーバーは2種類のクライアントマシンを区別し、2種類のモデムからの要求を適切に処理できます。一部のタイプのセットトップボックスまた、デバイスのハードウェアタイプと機能についてDHCPサーバーに通知するようにVCI(オプション60)を設定します。このオプションが設定されている値は、DHCPサーバーに、このクライアントがDHCP応答で必要とする必要な追加情報に関するヒントを提供します。

その他の拡張機能

文書化されたDHCPオプション
コード 名前 長さ RFC
82 リレーエージェント情報 最低2オクテット RFC 3046 [20]
85 Novell Directory Service(NDS)サーバー 最小4オクテット、4オクテットの倍数 RFC 2241 [21] :セクション2 
86 NDSツリー名 変数 RFC 2241 [21] :セクション3 
87 NDSコンテキスト 変数 RFC 2241 [21] :セクション4 
100 タイムゾーン、POSIXスタイル 変数 RFC 4833 [22]
101 タイムゾーンtzデータベーススタイル 変数 RFC 4833 [22]
114 DHCPキャプティブポータル 変数 RFC 8910 [23]
119 ドメイン検索 変数 RFC 3397 [24]
121 クラスレス静的ルート 変数 RFC 3442 [25]
209 構成ファイル 変数 RFC 5071 [26]
210 パスプレフィックス 変数 RFC 5071 [26]
211 再起動時間 変数 RFC 5071 [26]

リレーエージェント情報サブオプション

リレーエージェント情報オプション(オプション82)は、DHCPリレーとDHCPサーバー間で送信されるDHCP要求にサブオプションをアタッチするためのコンテナーを指定します。[20]

リレーエージェントのサブオプション
コード 名前 長さ RFC
1 エージェント回路ID 最低1オクテット RFC 3046 [20]
2 エージェントリモートID 最低1オクテット RFC 3046 [20]
4 Data-Over-Cable Service Interface Specification(DOCSIS)デバイスクラス 4オクテット RFC 3256 [27]

中継

1つのIPサブネットのみが管理されている小規模なネットワークでは、DHCPクライアントはDHCPサーバーと直接通信します。ただし、DHCPサーバーは複数のサブネットにIPアドレスを提供することもできます。この場合、IPアドレスをまだ取得していないDHCPクライアントは、同じサブネット上にないDHCPサーバーと直接通信することはできません。これは、クライアントのブロードキャストはそれ自体のサブネットでのみ受信できるためです。

DHCPサーバーが直接サービスを提供していないサブネット上のDHCPクライアントがDHCPサーバーと通信できるようにするために、DHCPリレーエージェントをこれらのサブネットにインストールできます。DHCPクライアントはローカルリンクでブロードキャストします。リレーエージェントはブロードキャストを受信し、ユニキャストを使用して1つ以上のDHCPサーバーに送信しますリレーエージェントは、DHCPパケットのフィールドGIADDRフィールドに独自のIPアドレスを格納します。DHCPサーバーは、GIADDR値を使用して、リレーエージェントがブロードキャストを受信したサブネットを判別し、そのサブネットにIPアドレスを割り当てます。DHCPサーバーがクライアントに応答すると、再びユニキャストを使用して、応答をGIADDRアドレスに送信します。次に、リレーエージェントはローカルネットワーク上で応答を再送信します。

この状況では、リレーエージェントとDHCPサーバー間の通信では、通常、送信元と宛先の両方のUDPポート67が使用されます。

クライアントの状態

RFC2131の図5に基づく簡略化されたDHCPクライアントの状態遷移図。

RFC 2131で説明されているように、[12] :セクション4.4DHCP クライアントはサーバーから次のメッセージを受信できます。

  • DHCPOFFER
  • DHCPACK
  • DHCPNAK

クライアントは、クライアントが送信するメッセージにサーバーがどのように応答するかに応じて、DHCP状態を移動します。

信頼性

DHCPは、定期的な更新、再バインド、[12] :セクション4.4.5 、およびフェイルオーバーなど、いくつかの方法で信頼性を保証します。DHCPクライアントには、一定期間続くリースが割り当てられます。クライアントは、リース間隔の半分が経過すると、リースの更新を試み始めます。[12] :セクション4.4.5パラグラフ3 これは、元のリースを許可したDHCPサーバーに ユニキャストDHCPREQUESTメッセージを送信することによって行われます。そのサーバーがダウンしているか到達不能である場合、DHCPREQUESTへの応答に失敗します。ただし、その場合、クライアントはDHCPREQUESTを時々繰り返します[12] :セクション4.4.5段落8  [b]そのため、DHCPサーバーが復旧するか、再び到達可能になった場合、DHCPクライアントはDHCPサーバーへの接続に成功し、リースを更新します。

DHCPサーバーに長期間アクセスできない場合、[12] :セクション4.4.5段落5  DHCPクライアントは、ユニキャストではなくDHCPREQUESTをブロードキャストすることにより、再バインドを試みます。ブロードキャストされるためDHCPREQUESTメッセージは使用可能なすべてのDHCPサーバーに到達します。他のDHCPサーバーがリースを更新できる場合は、この時点で更新します。

再バインドが機能するためには、クライアントがバックアップDHCPサーバーに正常に接続するときに、そのサーバーがクライアントのバインドに関する正確な情報を持っている必要があります。2つのサーバー間で正確なバインディング情報を維持することは複雑な問題です。両方のサーバーが同じリースデータベースを更新できる場合は、独立したサーバーでの更新間の競合を回避するメカニズムが必要です。フォールトトレラントDHCPサーバーを実装するための提案がインターネット技術特別調査委員会に提出されましたが、正式にはなりませんでした。[28] [c]

再バインドが失敗した場合、リースは最終的に期限切れになります。リースの有効期限が切れると、クライアントはリースで付与されたIPアドレスの使用を停止する必要があります。[12] :セクション4.4.5パラグラフ9  その時点で、DHCPDISCOVERメッセージをブロードキャストすることにより、DHCPプロセスを最初から再開します。リースの有効期限が切れているため、提供されたすべてのIPアドレスを受け入れます。(おそらく別のDHCPサーバーからの)新しいIPアドレスを取得すると、再びネットワークを使用できるようになります。ただし、IPアドレスが変更されたため、進行中の接続はすべて切断されます。

IPv6ネットワーク

DHCPの基本的な方法論は、インターネットプロトコルバージョン4(IPv4)に基づくネットワーク用に開発されました。IPv6ネットワークの開発と展開以来、ステートレスアドレス自動構成のためのIPv6の固有の機能にもかかわらず、DHCPはそのようなネットワークでのパラメーターの割り当てにも使用されてきましたプロトコルのIPv6バージョンはDHCPv6として指定されています。[29]

セキュリティ

ベースDHCPには、認証のメカニズムは含まれていません。[30] このため、さまざまな攻撃に対して脆弱です。これらの攻撃は、主に3つのカテゴリに分類されます。

  • クライアントに誤った情報を提供する不正なDHCPサーバー。[31]
  • 許可されていないクライアントがリソースにアクセスする。[31]
  • 悪意のあるDHCPクライアントからのリソース枯渇攻撃。[31]

クライアントにはDHCPサーバーのIDを検証する方法がないため、許可されていないDHCPサーバー(一般に「不正なDHCP」と呼ばれます)がネットワーク上で動作し、DHCPクライアントに誤った情報を提供する可能性があります。[32] これは、サービス拒否攻撃として機能し、クライアントがネットワーク接続にアクセスできないようにする[33]か、man-in-the-middle攻撃として機能します。[34] DHCPサーバーはDHCPクライアントに1つ以上のDNSサーバーのIPアドレスなどのサーバーIPアドレスを提供するため、[31]攻撃者はDHCPクライアントに独自のDNSサーバーを介してDNSルックアップを実行するように説得できます。したがって、クライアントからのDNSクエリに対して独自の回答を提供できます。[35][36]これにより、攻撃者はネットワークトラフィックを自分自身にリダイレクトし、クライアントと接続するネットワークサーバー間の接続を盗聴したり、単にそれらのネットワークサーバーを独自のものに置き換えたりすることができます。[35]

DHCPサーバーにはクライアントを認証するための安全なメカニズムがないため、クライアントは、他のDHCPクライアントに属するクライアント識別子などの資格情報を提示することにより、IPアドレスへの不正アクセスを取得できます。[32]これにより、DHCPクライアントはDHCPサーバーのIPアドレスのストアを使い果たすことができます。アドレスを要求するたびに新しい資格情報を提示することで、クライアントは特定のネットワークリンクで利用可能なすべてのIPアドレスを消費し、他のDHCPクライアントがサービスを受ける。[32]

DHCPは、これらの問題を軽減するためのいくつかのメカニズムを提供します。リレーエージェント情報オプションプロトコル拡張(RFC 3046、通常、業界では実際の番号でオプション82 [37] [38]と呼ばれます使用すると、ネットワークオペレーターは、DHCPメッセージがネットワークオペレーターの信頼できるネットワークに到着するときに、DHCPメッセージにタグを付けることができます。 。このタグは、ネットワークリソースへのクライアントのアクセスを制御するための認証トークンとして使用されます。クライアントはリレーエージェントの上流のネットワークにアクセスできないため、認証がなくてもDHCPサーバーのオペレーターが認証トークンに依存することを妨げることはありません。[30]

もう1つの拡張機能であるDHCPメッセージの認証(RFC 3118)は、DHCPメッセージを認証するためのメカニズムを提供します。2002年の時点で、RFC 3118は、多数のDHCPクライアントのキーの管理に問題があるため、広く採用されていませんでした。[39] DSLテクノロジーに関する2007年の本は、次のように述べています。

RFC 3118によって提案されたセキュリティ対策に対して特定された多数のセキュリティの脆弱性がありました。この事実は、 802.1xの導入と相まって、認証されたDHCPの展開と実行速度を遅くし、広く展開されたことはありません。[40]

2010年の本は次のように述べています。

[t] DHCP認証の実装はほとんどありません。ハッシュ計算によるキー管理と処理の遅延の課題は、認識された利益を支払うには高すぎると見なされてきました。[41]

2008年のアーキテクチャの提案には、 802.1xまたはPANA(どちらもEAPを転送する)を使用したDHCP要求の認証が含まれます[42] DHCP自体にEAPを含めるためのIETF提案、いわゆるEAPoDHCPが作成されました。[43]これはIETFドラフトレベルを超えて進んでいないようであり、その最後は2010年までさかのぼります。[44]

IETF標準文書

  • RFC  2131、動的ホスト構成プロトコル
  • RFC  2132、DHCPオプションおよびBOOTPベンダー拡張
  • RFC  3046、DHCPリレーエージェント情報オプション
  • RFC  3397、動的ホスト構成プロトコル(DHCP)ドメイン検索オプション
  • RFC  3942、動的ホスト構成プロトコルバージョン4(DHCPv4)オプションの再分類
  • RFC  4242、IPv6の動的ホスト構成プロトコルの情報更新時間オプション
  • RFC  4361、動的ホスト構成プロトコルバージョン4(DHCPv4)のノード固有のクライアント識別子
  • RFC  4436、IPv4でのネットワーク接続の検出(DNAv4)
  • RFC  3442、動的ホスト構成プロトコル(DHCP)バージョン4のクラスレス静的ルートオプション
  • RFC  3203、DHCP再構成拡張機能
  • RFC  4388、動的ホスト構成プロトコル(DHCP)Leasequery
  • RFC  6926、DHCPv4バルクリースクエリ
  • RFC  7724、アクティブなDHCPv4リースクエリ

も参照してください

メモ

  1. ^ a b オプションのクライアント動作として、DHCP検出メッセージや要求メッセージを伝送するブロードキャストなどの一部のブロードキャストは、DHCPクライアントがDHCPサーバーのIPアドレスをすでに知っている場合にユニキャストに置き換えることができます。[11]
  2. ^ RFCは、クライアントがDHCPREQUESTパケットを再送信する前に、残り時間の半分をT2まで待機することを要求します。
  3. ^ この提案は、一方のサーバーに完全な障害が発生した場合でも、もう一方のサーバーがリースデータベースを回復して運用を継続できるように、2台のサーバーが互いに緩く同期し続けることができるメカニズムを提供しました。仕様の長さと複雑さのために、標準として公開されることはありませんでした。ただし、提案で説明されている手法は、オープンソースおよびいくつかの商用実装で広く使用されています。

参考文献

  1. ^ W. Richard Stevens、 TCP / IP Illustrated、Volume 1:The Protocols、Addison Wesley、1994、ISBN0-201-63346-9。
  2. ^ Gillis、Alexander S. 「DHCP(動的ホスト構成プロトコル)とは何ですか?」TechTarget:SearchNetworking 2021年2月19日取得
  3. ^ ピーターソン、ラリーL。; デイビー、ブルースS.(2011)。コンピュータネットワーク:システムアプローチ(第5版)。エルゼビア。ISBN 978-01238506072019年3月21日取得
  4. ^ ビルクロフト; ジョンギルモア(1985年9月)。「RFC951-ブートストラッププロトコル」ネットワークワーキンググループ
  5. ^ MicrosoftPressが発行したNetwork +認定2006。
  6. ^ Webプロキシ自動検出プロトコルに使用Webプロキシ自動検出プロトコル(WPAD)
  7. ^ Droms、R。(1997年3月)。「動的ホスト構成プロトコル」土井10.17487 / RFC2131 2021年12月2日取得
  8. ^ RFC 4361、RFC 5494、RFC 6221、RFC 6422、RFC 6644、RFC 7083、RFC 7227、RFC 7283
  9. ^ ドロムス、ラルフ; レモン、テッド(2003)。DHCPハンドブックSAMSパブリッシングp。436. ISBN 978-0-672-32327-0
  10. ^ a b Droms、ラルフ(1997年3月)。「動的ホスト構成プロトコル」tools.ietf.org 2017年7月4日取得
  11. ^ Droms、ラルフ(1997年3月)。「動的ホスト構成プロトコル」tools.ietf.org 2017年7月4日取得
  12. ^ a b c d e f g Droms、ラルフ(1997年3月)。DHCPオプションとBOOTPベンダー拡張IETF土井10.17487 / RFC2131RFC2131 _ 2014年9月9日取得
  13. ^ Droms、ラルフ(1997年3月)。「RFC2131動的ホスト構成プロトコル:ネットワークアドレスの動的割り当て」tools.ietf.org
  14. ^ a b 「動的ホスト構成プロトコル(DHCP)およびブートストラッププロトコル(BOOTP)パラメーター」iana.org 2018年10月16日取得
  15. ^ a b c d e f g h i j k l m n o p q r s Alexander、Steve; ドロムス、ラルフ(1997年3月)。DHCPオプションとBOOTPベンダー拡張IETF土井10.17487 / RFC2132RFC2132 _ 2012年6月10日取得
  16. ^ a b T'joens、Yves; De Schrijver、Peter(2001年12月)。DHCP再構成拡張IETF土井10.17487 / RFC3203RFC3203 _ 2020年11月13日取得
  17. ^ a b c d e Woundy、Rich; キム・キニア(2006年2月)。DHCP再構成拡張IETF土井10.17487 / RFC4388RFC4388 _ 2020年11月13日取得
  18. ^ a b c キニア、キム; スタップ、マーク; Rao、DTV Ramakrishna; ジョシー、バーラット; ラッセル、ニール; クラパティ、パヴァン; ヴォルツ、バーニー(2013年4月)。DHCP再構成拡張IETF土井10.17487 / RFC6926RFC6926 _ 2020年11月13日取得
  19. ^ a b c d キニア、キム; スタップ、マーク; ヴォルツ、バーニー; ラッセル、ニール(2015年12月)。DHCP再構成拡張IETF土井10.17487 / RFC7724RFC7724 _ 2020年11月13日取得
  20. ^ a b c d Patrick、Michael(2001年1月)。「DHCPリレーエージェント情報オプション」IETFドキュメントIETF土井10.17487 / RFC30462017年7月22日取得
  21. ^ a b c Provan、Don(1997年11月)。「RFC2241– Novell DirectoryServicesのDHCPオプション」IETFドキュメントIETF土井10.17487 / RFC32562017年7月23日取得
  22. ^ a b リア、E。; Eggert、P。(2007年4月)。「DHCPのタイムゾーンオプション」IETFドキュメントIETF 2018年6月28日取得
  23. ^ クマリ、ウォーレン。「RFC8910-DHCPおよびルーターアドバタイズメント(RA)でのキャプティブポータルの識別」ietf.orgIETF 2021年3月25日取得
  24. ^ バーナード、アボバ; スチュアート、チェシャー(2002年11月)。「RFC3397–動的ホスト構成プロトコル(DHCP)ドメイン検索オプション」IETFドキュメントIETF土井10.17487 / RFC33972017年7月22日取得
  25. ^ 「RFC3442」
  26. ^ a b c ハンキンス、デビッド(2007年12月)。「RFC5071-PXELINUXで使用される動的ホスト構成プロトコルオプション」ietf.orgIETF 2021年3月25日取得
  27. ^ ダグ、ジョーンズ; リッチ、ワウンディ(2002年4月)。「RFC3256– DOCSIS(データオーバーケーブルサービスインターフェイス仕様)デバイスクラスDHCP(動的ホスト構成プロトコル)リレーエージェント情報サブオプション」IETFドキュメントIETF土井10.17487 / RFC32562017年7月23日取得
  28. ^ ドロムス、ラルフ; キムの近く。スタップ、マーク; ヴォルツ、バーニー; ゴンジ、スティーブ; ラビル、グレッグ; ドゥーリー、マイケル; カプール、アルン(2003年3月)。DHCPフェイルオーバープロトコルIETFIDdraft-ietf-dhc-failover-12 2010年5月9日取得
  29. ^ ワインバーグ、ニール(2018-08-14)。「DHCPの日数が数えられる理由」ネットワークワールド2019年8月7日取得
  30. ^ a b Patrick、Michael(2001年1月)。「RFC3046-DHCPリレーエージェント情報オプション」ネットワークワーキンググループ
  31. ^ a b c d Droms、ラルフ(1997年3月)。「RFC2131-動的ホスト構成プロトコル」ネットワークワーキンググループ
  32. ^ a b c Stapko、Timothy(2011)。実用的な組み込みセキュリティ:安全なリソースに制約のあるシステムの構築ニューンズ。p。39. ISBN 978-0-08-055131-9
  33. ^ Rountree、Derrick(2013)。Windows 2012 Serverネットワークセキュリティ:Windowsネットワークシステムとインフラストラクチャの保護ニューンズ。p。22. ISBN 978-1-59749-965-1
  34. ^ ルーニー、ティモシー(2010)。IPアドレス管理の概要ジョン・ワイリー&サンズ。p。180. ISBN 978-1-118-07380-3
  35. ^ a b Golovanov(Kaspersky Labs)、Sergey(2011年6月)。「TDSSローダーに「レッグ」が追加されました"
  36. ^ Sunny、Akash K(2015年10月)。「dhcpプロトコルとその脆弱性」
  37. ^ 鶏、フランシスコJ。; カバレロ、ホセM.(2008)。トリプルプレイ:IP、VoIP、IPTVのコンバージェンスネットワークを構築しますジョン・ワイリー&サンズ。p。239. ISBN 978-0-470-75439-9
  38. ^ ラミレス、デビッドH.(2008)。IPTVセキュリティ:価値の高いデジタルコンテンツの保護ジョン・ワイリー&サンズ。p。55. ISBN 978-0-470-72719-5
  39. ^ レモン、テッド(2002年4月)。「RFC3118の実装」
  40. ^ ゴールデン、フィリップ; Dedieu、Hervé; ジェイコブセン、クリスタS.(2007)。DSLテクノロジーの実装とアプリケーションテイラーアンドフランシス。p。484. ISBN 978-1-4200-1307-8
  41. ^ ルーニー、ティモシー(2010)。IPアドレス管理の概要ジョン・ワイリー&サンズ。pp。181–182。ISBN 978-1-118-07380-3
  42. ^ コープランド、レベッカ(2008)。NGN有線およびモバイル3Gネットワ​​ークとIMSの統合テイラーアンドフランシス。pp。142–143。ISBN 978-1-4200-1378-8
  43. ^ プラサド、ラムジー; ミホフスカ、アルベナ(2009)。モバイルおよびワイヤレス通信の新しい地平:ネットワーク、サービス、およびアプリケーション2.アーテックハウス。p。339. ISBN 978-1-60783-970-5
  44. ^ 「アーカイブされたコピー」2015年4月3日にオリジナルからアーカイブされまし2013年12月12日取得{{cite web}}: CS1 maint: archived copy as title (link)

外部リンク