Loading article…
動的ホスト構成プロトコル（DHCP）は、クライアント/サーバアーキテクチャを使用してネットワークに接続されたデバイスにIPアドレスやその他の通信パラメータを自動的に割り当てるために、インターネットプロトコル（IP）ネットワークで使用されるネットワーク管理プロトコルです。[ 1 ]：概要
この技術は、ネットワーク機器を個別に手動で設定する必要性をなくし、中央に設置されたネットワークDHCPサーバーと、各コンピュータまたはデバイス上のプロトコルスタックのクライアントインスタンスという2つのネットワークコンポーネントで構成されています。クライアントは、ネットワークに接続されると、その後定期的にDHCPを使用してサーバーから一連のパラメータを要求します。
DHCP は、住宅ネットワークから大規模なキャンパスネットワーク、地域 ISP ネットワークまで、さまざまな規模のネットワークで実装できます。 [ 2 ]多くのルーターや住宅用ゲートウェイには DHCP サーバー機能があります。ほとんどの住宅用ネットワークルーターは、 ISP ネットワーク内で固有のIP アドレスを受け取ります。ローカルネットワーク内では、DHCP サーバーが各デバイスにローカル IP アドレスを割り当てます。
DHCPサービスは、インターネットプロトコルバージョン4（IPv4）とバージョン6（IPv6）の両方で動作するネットワークに存在します。DHCPプロトコルのIPv6バージョンは、一般的にDHCPv6と呼ばれます。[ 3 ]
逆アドレス解決プロトコル(RARP) は、ディスクレス ワークステーションなどの単純なデバイスを適切なIP アドレスで構成するために 1984 年に定義されました。[ 4 ]データ リンク層で動作するため、多くのサーバー プラットフォームでの実装が困難でした。各ネットワーク リンクにサーバーが存在する必要がありました。RARP は、 1985 年 9 月に定義されたブートストラップ プロトコル(BOOTP)に取って代わられました。 [ 5 ]これにより、リレー エージェントの概念が導入され、ネットワーク間で BOOTP パケットを転送できるようになり、1 つの中央 BOOTP サーバーが多数の IP サブネット上のホストにサービスを提供できるようになりました。
DHCPは1993年10月に初めて定義されました。[ 6 ] [ 7 ]これはBOOTPに基づいていますが、IPアドレスをプールから動的に割り当て、使用されなくなったときにそれらを回収することができます。また、プラットフォーム固有のパラメータを含む、さまざまな追加構成パラメータをIPクライアントに提供するためにも使用できます。[ 8 ]
4年後、DHCPINFORMメッセージタイプ（WPADに使用）やその他の小さな変更が加えられました。1997年のこの定義[ 1 ]は、 IPv4ネットワークの標準の中核となっています。
DHCPv6は2003年に最初に定義されました。[ 9 ] その後の多くのRFCによる更新を経て、2018年に定義が置き換えられました。[ 10 ]そこではプレフィックス委任とステートレスアドレス自動構成が統合されました。
インターネットプロトコル（IP）は、デバイスがインターネット上のローカルネットワーク内およびネットワーク間でどのように通信するかを定義します。DHCPサーバーは、ローカルネットワーク上のデバイスのIP設定を管理できます。たとえば、デバイスにIPアドレス[ 8 ]を自動的かつ動的に割り当てることによってです。 [ 11 ]
DHCPはクライアント・サーバーモデルに基づいて動作します。コンピュータやその他のデバイスがネットワークに接続すると、DHCPクライアントソフトウェアは必要な情報を要求するDHCPブロードキャストクエリを送信します。ネットワーク上のどのDHCPサーバーでもこの要求に応答できます。DHCPサーバーは、IPアドレスのプールと、デフォルトゲートウェイ、ドメイン名、ネームサーバー、タイムサーバーなどのクライアント構成パラメータに関する情報を管理します。DHCP要求を受信すると、DHCPサーバーは、管理者が事前に設定した各クライアント固有の情報、またはネットワーク全体および割り当て（リース）の有効期間に有効な特定のアドレスとその他の情報で応答します。DHCPクライアントは通常、起動直後と、その後情報の有効期限が切れる前に定期的にこの情報を照会します。DHCPクライアントが割り当てを更新する場合、最初は同じパラメータ値を要求しますが、DHCPサーバーは管理者が設定した割り当てポリシーに基づいて新しいアドレスを割り当てる場合があります。
複数のリンクで構成される大規模ネットワークでは、相互接続ルーターに配置されたDHCPリレーエージェントの支援により、単一のDHCPサーバーがネットワーク全体を管理できる場合があります。これらのエージェントは、異なるサブネットに配置されたDHCPクライアントとDHCPサーバー間でメッセージを中継します。
実装方法によっては、DHCPサーバーはIPアドレスを割り当てる際に3つの方法を用いる場合があります。
DHCP サービスは、インターネット プロトコル バージョン 4 (IPv4) およびIPv6に使用されます。IPv4 と IPv6 のプロトコルの詳細は十分に異なるため、別々のプロトコルとみなすことができます。[ 12 ] IPv6 の動作では、デバイスは代わりにステートレス アドレス自動構成を使用することもできます。IPv6 ホストは、ローカル ネットワーク リンクに限定された操作を実現するために、リンク ローカル アドレス指定を使用することもできます。
DHCPは、ユーザーデータグラムプロトコル（UDP）を使用したコネクションレス型のサービスモデルを採用しています。動作には、ブートストラッププロトコル（ BOOTP ）と同じ2つのUDPポート番号が使用されます。サーバーはUDPポート番号67で、クライアントはUDPポート番号68でリッスンします。
DHCPの動作は、サーバー検出、IPリース提供、IPリース要求、IPリース確認の4つの段階に分けられます。これらの段階は、検出、提供、要求、確認の頭文字をとってDORAと略されることがよくあります。
DHCP 操作は、クライアントが要求をブロードキャストすることから始まります。クライアントとサーバーが異なるブロードキャスト ドメインにある場合、DHCP ヘルパーまたは DHCP リレー エージェントが使用されることがあります。既存のリースの更新を要求するクライアントは、その時点で既に確立された IP アドレスを持っているため、UDPユニキャストを介して直接通信できます。さらに、クライアントが DHCPOFFER を受信できる方法 (ブロードキャストまたはユニキャスト) を示すために使用できる BROADCAST フラグ (2 バイトのフラグ フィールドの 1 ビットで、他のすべてのビットは予約されているため 0 に設定されます) があります。ブロードキャストの場合は 0x8000、ユニキャストの場合は 0x0000 です。[ 1 ]通常、DHCPOFFER はユニキャストで送信されます。IP アドレスが構成される前にユニキャスト パケットを受け入れることができないホストの場合、このフラグを使用してこの問題を回避できます。
DHCPクライアントは、宛先アドレス255.255.255.255（限定ブロードキャスト）または特定のサブネットブロードキャストアドレス（ダイレクトブロードキャスト）を使用して、ネットワークサブネット上でDHCPDISCOVERメッセージをブロードキャストします。DHCPクライアントはDHCPDISCOVERメッセージ内でIPアドレスを要求することもでき、サーバーはこれを考慮して提供するアドレスを選択する場合があります。
例えば、HTYPEが1に設定されている場合、使用されるメディアがイーサネットであることを指定するため、イーサネットアドレス（MACアドレス）は6オクテット長であるため、HLENは6に設定されます。CHADDRはクライアントが使用するMACアドレスに設定されます。いくつかのオプションも設定されます。
DHCPサーバーは、クライアントからIPアドレスのリース要求であるDHCPDISCOVERメッセージを受信すると、クライアント用にIPアドレスを予約し、DHCPOFFERメッセージをクライアントに送信してリースを提供します。このメッセージには、クライアントのクライアントID（オプション61、一意の値、従来はMACアドレスを含む）、サーバーが提供するIPアドレス、サブネットマスク、リース期間、およびリースを提供するDHCPサーバーのIPアドレスが含まれる場合があります。DHCPサーバーは、ハードウェアレベルのMACアドレス（CHADDRフィールドで指定）も考慮に入れる場合があります。DHCPパケットにクライアントIDが提供されていない場合は、このフィールドを使用してクライアントを識別する必要があります。[ 1 ]： §4.2
DHCPサーバーは、CHADDR（クライアントハードウェアアドレス）フィールドに指定されたクライアントのハードウェアアドレスに基づいて設定を決定します。次の例では、サーバー（192.168.1.1）がYIADDR（クライアントIPアドレス）フィールドにクライアントのIPアドレスを指定しています。
DHCPオファーに応答して、クライアントはサーバーにブロードキャストされるDHCPREQUESTメッセージで返信し、提供されたアドレスを要求します。クライアントは複数のサーバーからDHCPオファーを受信できますが、受け入れるのは1つのDHCPオファーのみです。
クライアントは、選択したオファーを提供するサーバーを示すサーバー識別オプションを DHCPREQUEST メッセージで送信する必要があります。 [ 1 ] :セクション 3.1、項目 3他の DHCP サーバーがこのメッセージを受信すると、クライアントに対して行ったオファーを取り消し、提供した IP アドレスを利用可能なアドレスのプールに戻します。
DHCPサーバーがクライアントからDHCPREQUESTメッセージを受信すると、設定プロセスは最終段階に入ります。確認応答段階では、クライアントにDHCPACKパケットが送信されます。このパケットには、リース期間やクライアントが要求したその他の設定情報が含まれます。この時点で、IP設定プロセスは完了です。
このプロトコルでは、DHCPクライアントがネゴシエートされたパラメータを使用してネットワークインターフェースを設定することが想定されています。
サーバーがプールから IP アドレスを再利用する場合、まず ( pingを使用して) 既に使用されていないか確認することがあります。[ 1 ] : sec. 2.2これは、ホストが DHCP スコープ内の IP アドレスで手動で構成されている場合に発生する可能性があります。
IP アドレスを要求する前に、クライアントは新しく受信したアドレスをプローブし ( ARPなどを使用)、提案された IP アドレスを持つ別のホストがネットワーク上に存在するかどうかを確認する必要があります。[ 1 ] : sec. 2.2応答がない場合、このアドレスは他のホストのアドレスと競合しないため、自由に使用できます。このプローブでそのアドレスを使用している別のコンピュータが見つかった場合、クライアントは DHCP サーバーに DHCPDECLINE をブロードキャストする必要があります。
DHCPクライアントは、サーバーが最初に送信したDHCPOFFERメッセージに含まれる情報よりも多くの情報を要求する場合があります。また、特定のアプリケーションに対して、同じデータを繰り返し要求することもあります。例えば、ブラウザはDHCP Informを使用して、 WPAD経由でWebプロキシ設定を取得します。
クライアントはDHCPサーバーにDHCP情報の解放を要求し、自身のIPアドレスを無効化します。クライアントデバイスは通常、ユーザーがネットワークからデバイスを切断するタイミングを知らないため、プロトコルではDHCP Releaseの送信は必須ではありません。
DHCPサーバーは、クライアントにオプションの設定パラメータを提供できます。RFC 2132では、インターネット割り当て番号機関（IANA）によって定義された利用可能なDHCPオプション（DHCPおよびBOOTPパラメータ）について説明しています。[ 13 ]
DHCPクライアントは、DHCPサーバーから提供されるパラメータを選択、操作、上書きすることができます。Unix系システムでは、このクライアントレベルでの調整は通常、設定ファイル/etc/dhclient.confの値に基づいて行われます。
オプションは、長さが変化するオクテット文字列です。これはタイプ-長さ-値エンコーディングと呼ばれます。最初のオクテットはオプションコード、2番目のオクテットは後続のオクテット数、残りのオクテットはコードに依存します。たとえば、オファーのDHCPメッセージタイプオプションは、0x35、0x01、0x02と表示されます。ここで、0x35は「DHCPメッセージタイプ」のコード53、0x01は後続のオクテット数、0x02は「オファー」の値です。
以下の表に、利用可能な DHCP オプションを示します。[ 14 ] [ 13 ]
この表は、DHCPメッセージの種類を示しています。これらのコードは、上記の表に示されているDHCP拡張53の値です。
DHCPクライアントのベンダーと機能を識別するためのオプションがあります。この情報は、 DHCPクライアントのベンダーによって指定された意味を持つ、可変長の文字列（オクテット）です。DHCPクライアントが特定の種類のハードウェアまたはファームウェアを使用していることをサーバーに伝える方法の1つは、DHCPリクエストにベンダークラス識別子（VCI）（オプション60）と呼ばれる値を設定することです。
このオプションに設定されている値は、DHCP サーバーに、このクライアントが DHCP 応答で必要とする追加情報に関するヒントを与えます。一部のタイプのセットトップ ボックスは、 VCI を設定して、デバイスのハードウェア タイプと機能を DHCP サーバーに通知します。たとえば、Arubaキャンパスワイヤレス アクセス ポイントは、DHCPDISCOVER メッセージのオプション 60 として値「ArubaAP」を提供します。 [ 20 ]これにより、DHCP サーバーは、オプション 43 に Arubaワイヤレス コントローラの IP アドレスを追加して DHCPOFFER を拡張できるため、アクセス ポイントはどこに登録すればよいかを知ることができます。
クライアント側でVCIを設定することで、DHCPサーバーはクライアントマシンを区別し、それぞれのマシンからの要求を適切に処理できるようになります。
リレーエージェント情報オプション（オプション82）は、DHCPリレーとDHCPサーバー間で送信されるDHCP要求にサブオプションを付加するためのコンテナを指定します。[ 22 ]
小規模ネットワークでは、管理対象のIPサブネットが1つだけの場合、DHCPクライアントはDHCPサーバーと直接通信します。しかし、DHCPサーバーは複数のサブネットにIPアドレスを割り当てることもできます。この場合、まだIPアドレスを取得していないDHCPクライアントは、同じサブネット上にないDHCPサーバーと直接通信することはできません。クライアントのブロードキャストは、自身のサブネット内でのみ受信できるためです。
DHCPサーバーが直接サービスを提供していないサブネット上のDHCPクライアントがDHCPサーバーと通信できるようにするには、これらのサブネットにDHCPリレーエージェントをインストールできます。DHCPリレーエージェントは、クライアントのサブネットとDHCPサーバーのサブネット間のルーティングが可能なネットワークデバイス上で動作します。DHCPクライアントはローカルリンク上でブロードキャストを送信し、リレーエージェントはブロードキャストを受信して、ユニキャストを使用して1つ以上のDHCPサーバーに送信します。DHCPサーバーのIPアドレスは、リレーエージェントで手動で設定されます。リレーエージェントは、クライアントのブロードキャストを受信したインターフェイスから取得した自身のIPアドレスを、 DHCPパケットのGIADDRフィールドに格納します。DHCPサーバーはGIADDR値を使用してサブネットを決定し、続いてIPアドレスを割り当てる対応するアドレスプールを特定します。DHCPサーバーがクライアントに応答する場合、ユニキャストを使用してGIADDRアドレスに応答を送信します。リレーエージェントは、クライアントのMACアドレス宛てのイーサネットフレームで、ユニキャスト（ほとんどの場合）を使用して、新しく予約されたIPアドレスにローカルネットワーク上で応答を再送信します。クライアントは、その IP アドレスがまだインターフェースに設定されていない場合でも、パケットを自身のものとして受け入れる必要があります。[ 1 ] : 25 パケットを処理した直後、クライアントはインターフェースに IP アドレスを設定し、その後すぐに通常の IP 通信の準備が整います。
クライアントのIPスタックの実装が、まだIPアドレスが割り当てられていない状態でユニキャストパケットを受け入れない場合、クライアントはDHCPDISCOVERパケットを送信する際にFLAGSフィールドのブロードキャストビットを設定することができます。リレーエージェントは、255.255.255.255のブロードキャストIPアドレス（およびクライアントのMACアドレス）を使用して、クライアントにサーバーのDHCPOFFERを通知します。
リレーエージェントとDHCPサーバー間の通信では、通常、送信元と宛先の両方でUDPポート67が使用されます。
DHCPクライアントは、サーバーから以下のメッセージを受信できます。[ 1 ]： §4.4
クライアントは、サーバーがクライアントからのメッセージにどのように応答するかに応じて、DHCPの状態を遷移します。
DHCP は、定期的な更新、再バインド、[ 1 ] : §4.4.5、およびフェイルオーバーなど、いくつかの方法で信頼性を確保します。DHCP クライアントには、一定期間有効なリースが割り当てられます。クライアントは、リース期間の半分が経過すると、リースの更新を試みます。[ 1 ] : §4.4.5 パラグラフ 3クライアントは、元のリースを付与した DHCP サーバーにユニキャストDHCPREQUESTメッセージを 送信することでこれを行います。そのサーバーがダウンしているか到達不能な場合、 DHCPREQUESTに応答しません。ただし、その場合、クライアントは、DHCP サーバーが再び起動するか到達可能になったときに、DHCP サーバーと連絡を取り、リースを更新できるように、DHCPREQUESTを時々繰り返します。 [ 1 ] : §4.4.5 パラグラフ 8 [ b ]
DHCP サーバーに長時間アクセスできない場合、[ 1 ] : §4.4.5 パラグラフ 5 DHCP クライアントは、ユニキャストではなくDHCPREQUESTをブロードキャストして再バインドを試みます。ブロードキャストされるため、DHCPREQUESTメッセージは利用可能なすべての DHCP サーバーに到達します。他の DHCP サーバーがリースを更新できる場合は、この時点で更新します。
リバインディングが機能するためには、クライアントがバックアップDHCPサーバーに正常に接続したとき、そのサーバーはクライアントのバインディングに関する正確な情報を持っている必要があります。2つのサーバー間で正確なバインディング情報を維持することは複雑な問題です。両方のサーバーが同じリースデータベースを更新できる場合、独立したサーバー間での更新の競合を回避するメカニズムが必要です。フォールトトレラントDHCPサーバーを実装するための提案がインターネット技術タスクフォースに提出されましたが、正式には採用されませんでした。[ 31 ] [ c ]
リバインディングが失敗すると、リースは最終的に期限切れになります。リースが期限切れになると、クライアントはリースで割り当てられた IP アドレスの使用を停止する必要があります。[ 1 ] : §4.4.5 パラグラフ 9 その時、クライアントはメッセージをブロードキャストして DHCP プロセスを最初から再開しますDHCPDISCOVER。リースが期限切れになっているため、クライアントは提供される IP アドレスをすべて受け入れます。新しい IP アドレス (おそらく別の DHCP サーバーから) を取得すると、再びネットワークを使用できるようになります。ただし、IP アドレスが変更されたため、進行中の接続はすべて切断されます。
DHCP の基本的な方法論は、インターネット プロトコル バージョン 4 (IPv4) に基づくネットワーク向けに開発されました。IPv6ネットワークの開発と展開以降、IPv6 のステートレス アドレス自動構成という固有の機能にもかかわらず、DHCP はそのようなネットワークのパラメータ割り当てにも使用されています。このプロトコルの IPv6 バージョンはDHCPv6と呼ばれています。[ 32 ]
基本DHCPには認証メカニズムが含まれていません。[ 22 ]： §7 このため、さまざまな攻撃に対して脆弱です。これらの攻撃は主に3つのカテゴリに分類されます。[ 1 ]： sec.7
クライアントは DHCP サーバーの身元を検証する方法がないため、不正な DHCP サーバー (一般に「不正 DHCP」と呼ばれる) がネットワーク上で動作し、DHCP クライアントに誤った情報を提供する可能性があります。[ 33 ] これは、クライアントがネットワーク接続にアクセスできないようにするサービス拒否攻撃[ 34 ]または中間者攻撃[ 35 ]として機能します。DHCP サーバーは、1 つ以上の DNS サーバーの IP アドレスなどのサーバー IP アドレスを DHCP クライアントに提供するため[ 1 ] : sec. 7攻撃者は、DHCP クライアントに自身の DNS サーバーを介して DNS ルックアップを実行するように仕向け、クライアントからの DNS クエリに対して独自の応答を提供できます。[ 36 ]これにより、攻撃者はネットワーク トラフィックを自身にリダイレクトし、クライアントと接続するネットワーク サーバー間の接続を盗聴したり、単にそれらのネットワーク サーバーを自身のものに置き換えたりすることができます。[ 36 ]
DHCP サーバーにはクライアントを認証するための安全なメカニズムがないため、クライアントは他の DHCP クライアントに属するクライアント識別子などの認証情報を提示することで、IP アドレスへの不正アクセスを取得できます。[ 33 ]これにより、DHCP クライアントは DHCP サーバーの IP アドレスの保存場所を使い果たすこともできます。クライアントはアドレスを要求するたびに新しい認証情報を提示することで、特定のネットワーク リンク上の利用可能なすべての IP アドレスを消費し、他の DHCP クライアントがサービスを受けられなくなります。[ 33 ]
DHCPには、これらの問題を軽減するためのメカニズムがいくつか用意されています。リレーエージェント情報オプションプロトコル拡張機能[ 22 ]（業界では通常、実際の番号であるオプション82 [ 37 ] [ 38 ]で呼ばれています）を使用すると、ネットワークオペレーターは、DHCPメッセージがネットワークオペレーターの信頼済みネットワークに到着した際に、DHCPメッセージにタグを付加できます。このタグは、クライアントのネットワークリソースへのアクセスを制御するための認証トークンとして使用されます。クライアントはリレーエージェントより上流のネットワークにアクセスできないため、認証がないことは、DHCPサーバーオペレーターが認証トークンに依存することを妨げるものではありません。[ 22 ]：第7節
別の拡張機能であるDHCPメッセージの認証[ 39 ]（RFC 3118）は、DHCPメッセージを認証するメカニズムを提供します。2002年の時点では、この拡張機能は、多数のDHCPクライアントの鍵を管理するという問題のために広く採用されていませんでした。[ 40 ] 2007年のDSL技術に関する書籍では、次のように述べられています。
RFC 3118で提案されたセキュリティ対策に対して、多数のセキュリティ脆弱性が特定されました。この事実と802.1Xの導入が相まって、認証付きDHCPの展開と普及が遅れ、広く展開されることはありませんでした。[ 41 ]
2010年の書籍には次のように記されている。
DHCP認証の実装例は非常に少ない。鍵管理の課題やハッシュ計算による処理遅延は、期待されるメリットに対してあまりにも大きな代償であると考えられてきた。[ 42 ]
2008年のアーキテクチャ提案では、802.1XまたはPANA（どちらもEAPを伝送する）を使用してDHCP要求を認証することが含まれていました。[ 43 ] EAPをDHCP自体に含めるためのIETF提案、いわゆるEAPoDHCPが作成されました。[ 44 ]これはIETFドラフトレベルを超えて進展していないようで、最後のドラフトは2010年のものです。[ 45 ]
ウィキメディア・コモンズにある、動的ホスト構成プロトコル（DHCP）に関連するメディア