ダイナミックホスト構成プロトコル

Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

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

この技術により、ネットワークデバイスを個別に手動で設定する必要がなくなり、中央に設置されたネットワークDHCPサーバーと、各コンピューターまたはデバイス上のプロトコルスタックのクライアントインスタンスという2つのネットワークコンポーネントで構成されます。クライアントは、ネットワークに接続した直後、およびその後定期的に、DHCPを使用してサーバーにパラメータセットを要求します。

DHCPは、住宅ネットワークから大規模なキャンパスネットワーク、地域ISPネットワークまで、あらゆる規模のネットワークに導入できます。 [2]多くのルーターや住宅用ゲートウェイはDHCPサーバー機能を備えています。ほとんどの住宅用ネットワークルーターは、 ISPネットワーク内で固有のIPアドレスを受け取ります。ローカルネットワーク内では、DHCPサーバーが各デバイスにローカルIPアドレスを割り当てます。

DHCPサービスは、インターネットプロトコルバージョン4（IPv4）とバージョン6（IPv6）を実行するネットワークで利用できます。DHCPプロトコルのIPv6バージョンは、一般的にDHCPv6と呼ばれます。

歴史

逆アドレス解決プロトコル（RARP）は、ディスクレスワークステーションなどの単純なデバイスに適切なIPアドレスを設定するために1984年に定義されました。 [3]データリンク層で動作するため、多くのサーバープラットフォームでの実装は困難でした。個々のネットワークリンクごとにサーバーが必要でした。RARPは、1985年9月に定義されたブートストラッププロトコル（BOOTP）に置き換えられました。 [4]これにより、リレーエージェントの概念が導入され、ネットワーク間でBOOTPパケットを転送できるようになり、1つの中央BOOTPサーバーが複数のIPサブネット上のホストにサービスを提供できるようになりました。

DHCPは1993年10月に初めて定義されました。[5] [6] BOOTPをベースにしていますが、IPアドレスをプールから動的に割り当て、使用されなくなったアドレスを回収することができます。また、プラットフォーム固有のパラメータを含む、幅広い追加設定パラメータをIPクライアントに提供するためにも使用できます。[7]

4年後、DHCPINFORMメッセージタイプ（WPADで使用）とその他の小さな変更が追加されました。1997年に定義されたこの定義[1]は、現在もIPv4ネットワークの標準規格の中核となっています。

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

概要

インターネットプロトコル（IP）は、インターネット上のローカルネットワーク内およびローカルネットワーク間でデバイスがどのように通信するかを定義します。DHCPサーバーは、ローカルネットワーク上のデバイスのIP設定を管理し、例えば、デバイスにIPアドレスを自動的かつ動的に割り当てることができます。[10]

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アドレスと同じIPアドレスを優先的に割り当てることができます。
手動割り当て
この方法は、静的DHCP割り当て、固定アドレス割り当て、予約、MAC/IPアドレスバインディングなどとも呼ばれます。管理者は、各クライアントの一意の識別子（クライアントIDまたはMACアドレス）をIPアドレスにマッピングし、そのIPアドレスを要求元のクライアントに提供します。DHCPサーバーは、この方法が失敗した場合に他の方法にフォールバックするように設定できます。

DHCPサービスは、インターネットプロトコルバージョン4（IPv4）とIPv6で使用されます。IPv4とIPv6のプロトコルの詳細は大きく異なるため、別々のプロトコルと見なすことができます。[11] IPv6の動作では、デバイスはステートレスアドレス自動設定を使用することもできます。IPv6ホストは、ローカルネットワークリンクに限定された動作を実現するために、リンクローカルアドレス指定を使用することもできます。

手術

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

DHCPは、ユーザーデータグラムプロトコル（UDP）を用いたコネクションレス型のサービスモデルを採用しています。DHCPは、ブートストラッププロトコル（ BOOTP ）と同様に、2つのUDPポート番号を使用して動作します。サーバーはUDPポート67番を、クライアントはUDPポート68番をそれぞれリッスンします。

DHCPの動作は、サーバーの検出、IPリースのオファー、IPリースの要求、IPリースの確認の4つのフェーズに分かれています。これらの段階は、検出（discovery）、オファー（offer）、要求（request）、確認（acknowledgement）の頭文字をとってDORAと略されることが多いです。

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

発見

DHCPクライアントは、宛先アドレス255.255.255.255（限定ブロードキャスト）または特定のサブネットブロードキャストアドレス（ダイレクトブロードキャスト）を使用して、ネットワークサブネット上にDHCPDISCOVERメッセージをブロードキャストします。DHCPクライアントはDHCPDISCOVERメッセージでIPアドレスを要求する場合もあり、サーバーはこれを考慮して提供するアドレスを選択します。

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

DHCPDISCOVERメッセージを含むイーサネットフレームの例
オフセットオクテット0123
オクテット少し012345678910111213141516171819202122232425262728293031
00宛先MAC  ( FF:FF:FF:FF:FF:FF )
432  
864ソース MAC  ( 00:05:3C:04:8D:59 )
1296イーサタイプ ( 0x0800 ) 
16128DHCP ペイロードを含む UDP PDU を含む IPv4 パケット...
20160
⋮⋮
⋮⋮フレームチェックシーケンス
IPv4ヘッダー
オフセットオクテット0123
オクテット少し012345678910111213141516171819202122232425262728293031
00IPv4ヘッダーの開始
432
864TTLプロトコル （17 UDP）ヘッダーチェックサム
1296送信元アドレス ( 0.0.0.0 )
16128宛先アドレス
UDPヘッダー
20160送信元ポート (68)目的地港 (67)
24192長さチェックサム
DHCPペイロード: DHCPDISCOVER
28224OP  ( 0x01 )HTYPE  ( 0x01 )HLEN  ( 0x06 )ホップ ( 0x00 )
32256XID  ( 0x3903F326 )
36288秒 ( 0x0000 )フラグ ( 0x0000 )
40320CIADDR  (クライアントIPアドレス: 0x00000000 )
44352YIADDR  (あなたのIPアドレス: 0x00000000 )
48384SIADDR  (サーバーIPアドレス: 0x00000000 )
52416GIADDR  (ゲートウェイIPアドレス: 0x00000000 )
56448CHADDR  (クライアントハードウェアアドレス: 0x00053C04 0x8D590000 0x00000000 0x00000000 )


60480
64512
68544
72576192 オクテットの 0、または追加オプション用のオーバーフロー スペース。BOOTP レガシー。
⋮⋮
2602080
2642112マジッククッキー （0x63825363）
DHCP オプション ( TLV形式)
2682144最初のオプション: 0x350101 : オプション53 (DHCPメッセージタイプ) 1オクテット (DHCPDISCOVERを含む)2番目のオプション:↴
2722176↪0x3204c0a80164 : オプション50 (IPアドレス要求) 4オクテット ( 192.168.1.100を含む)
27622083番目のオプション: 0x370401030f06 : オプション: 55 (パラメータ要求リスト) 4オクテット↴
2802240↪PRL 続き...ff

オファー

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アドレスを指定しています。

DHCPOFFERメッセージを含むイーサネットフレームの例
オフセットオクテット0123
オクテット少し012345678910111213141516171819202122232425262728293031
00宛先MAC  ( 00:05:3C:04:8D:59 )
432  
864送信元MAC  （B4:0C:25:E3:7D:62）
1296イーサタイプ ( 0x0800 ) 
16128DHCP ペイロードを含む UDP PDU を含む IPv4 パケット...
20160
⋮⋮
⋮⋮フレームチェックシーケンス
IPv4ヘッダー
オフセットオクテット0123
オクテット少し012345678910111213141516171819202122232425262728293031
00IPv4ヘッダーの開始
432
864TTLプロトコル（17 UDP）ヘッダーチェックサム
1296送信元アドレス ( 192.168.1.1 )
16128宛先アドレス ( 192.168.1.100 )
UDPヘッダー
20160送信元ポート (67)目的地ポート (68)
24192長さチェックサム
DHCPペイロード: DHCPOFFER
28224OP ( 0x02 )HTYPE ( 0x01 )HLEN ( 0x06 )ホップ ( 0x00 )
32256XID ( 0x3903F326 )
36288秒 ( 0x0000 )フラグ ( 0x0000 )
40320CIADDR (クライアントIPアドレス: 0x00000000 )
44352YIADDR (あなたのIPアドレス: 0xC0A80164または192.168.1.100 )
48384SIADDR (サーバーIPアドレス: 0xC0A80101または192.168.1.1 )
52416GIADDR (ゲートウェイIPアドレス: 0x00000000 )
56448CHADDR (クライアントハードウェアアドレス: 0x00053C04 0x8D590000 0x00000000 0x00000000 )


60480
64512
68544
72576192 オクテットの 0、または追加オプション用のオーバーフロー スペース。BOOTP レガシー。
⋮⋮
2602080
2642112マジッククッキー（0x63825363）
DHCP オプション ( TLV形式)
2682144最初のオプション: 0x350102 : オプション53 (DHCPメッセージタイプ) 1オクテット (DHCPOFFERを含む)2番目のオプション:↴
2722176↪0x0104ffffff00 : オプション1 (サブネットマスク) 4オクテット ( 255.255.255.0を含む)
27622083番目のオプション: 0x0304c0A80101 : オプション: 3 (ルーター) 4オクテット ( 192.168.1.1を含む)↴
2802240↪ルーター継続...4番目のオプション: 0x330400015080 : オプション51 (アドレス時間) 4オクテット (86400秒のリース時間)↴
2842272↪アドレス時間継続...5番目のオプション:
28823040x060c09070a0f09070a1009070a13 :オプション6
（ドメインサーバー）14オクテット（9.7.10.15、9.7.10.16、9.7.10.18を含む）
2922336
2962368
3002400 ff

リクエスト

DHCPオファーへの応答として、クライアントはDHCPREQUESTメッセージをサーバーにブロードキャストし、[a]提示されたアドレスを要求します。クライアントは複数のサーバーからDHCPオファーを受信できますが、受け入れるのは1つのDHCPオファーのみです。

クライアントは、DHCPREQUESTメッセージで、クライアントが選択したオファーのサーバーを示すサーバー識別オプションを送信する必要があります。 [1] ：セクション3.1、項目3 他のDHCPサーバーがこのメッセージを受信すると、クライアントに対して行ったオファーを撤回し、提供したIPアドレスを使用可能なアドレスのプールに戻します。

DHCPREQUEST メッセージを含むイーサネットフレームの例
オフセットオクテット0123
オクテット少し012345678910111213141516171819202122232425262728293031
00宛先MAC  ( FF:FF:FF:FF:FF:FF )
432  
864ソース MAC  ( 00:05:3C:04:8D:59 )
1296イーサタイプ ( 0x0800 ) 
16128DHCP ペイロードを含む UDP PDU を含む IPv4 パケット...
20160
⋮⋮
⋮⋮フレームチェックシーケンス
IPv4ヘッダー
オフセットオクテット0123
オクテット少し012345678910111213141516171819202122232425262728293031
00IPv4ヘッダーの開始
432
864TTLプロトコル（17 UDP）ヘッダーチェックサム
1296送信元アドレス ( 0.0.0.0 )
16128宛先アドレス ( 255.255.255.255 )
UDPヘッダー
20160送信元ポート (68)目的地港 (67)
24192長さチェックサム
DHCPペイロード: DHCPREQUEST
28224OP ( 0x01 )HTYPE ( 0x01 )HLEN ( 0x06 )ホップ ( 0x00 )
32256XID ( 0x3903F326 )
36288秒 ( 0x0000 )フラグ ( 0x0000 )
40320CIADDR (クライアントIPアドレス: 0x00000000 )
44352YIADDR (あなたのIPアドレス: 0x00000000 )
48384SIADDR (サーバーIPアドレス: 0xc0a80101または192.168.1.1 )
52416GIADDR (ゲートウェイIPアドレス: 0x00000000 )
56448CHADDR (クライアントハードウェアアドレス: 0x00053C04 0x8D590000 0x00000000 0x00000000 )


60480
64512
68544
72576192 オクテットの 0、または追加オプション用のオーバーフロー スペース。BOOTP レガシー。
⋮⋮
2602080
2642112マジッククッキー（0x63825363）
DHCP オプション ( TLV形式)
2682144最初のオプション: 0x350103 : オプション53 (DHCPメッセージタイプ) 1オクテット (DHCPREQUESTを含む)2番目のオプション:↴
2722176↪0x3204c0a80164 : オプション50 (IPアドレス要求) 4オクテット ( 192.168.1.100を含む)
27622083番目のオプション: 0x3604c0a801601 : オプション: 54 (DHCP サーバー) 4 オクテット ( 192.168.1.1を含む)↴
2802240↪DHCP サーバーは...ff

了承

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

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

DHCPACKメッセージを含むイーサネットフレームの例
オフセットオクテット0123
オクテット少し012345678910111213141516171819202122232425262728293031
00宛先MAC  ( 00:05:3C:04:8D:59 )
432  
864送信元MAC  （B4:0C:25:E3:7D:62）
1296イーサタイプ ( 0x0800 ) 
16128DHCP ペイロードを含む UDP PDU を含む IPv4 パケット...
20160
⋮⋮
⋮⋮フレームチェックシーケンス
IPv4ヘッダー
オフセットオクテット0123
オクテット少し012345678910111213141516171819202122232425262728293031
00IPv4ヘッダーの開始
432
864TTLプロトコル（17 UDP）ヘッダーチェックサム
1296送信元アドレス ( 192.168.1.1 )
16128宛先アドレス ( 192.168.1.100 )
UDPヘッダー
20160送信元ポート (67)目的地ポート (68)
24192長さチェックサム
DHCPペイロード: DHCPACK
28224OP ( 0x02 )HTYPE ( 0x01 )HLEN ( 0x06 )ホップ ( 0x00 )
32256XID ( 0x3903F326 )
36288秒 ( 0x0000 )フラグ ( 0x0000 )
40320CIADDR (クライアントIPアドレス: 0x00000000 )
44352YIADDR (あなたのIPアドレス: 0xC0A80164または192.168.1.100 )
48384SIADDR (サーバーIPアドレス: 0xC0A80101または192.168.1.1 )
52416GIADDR (ゲートウェイIPアドレス: 0x00000000 )
56448CHADDR (クライアントハードウェアアドレス: 0x00053C04 0x8D590000 0x00000000 0x00000000 )


60480
64512
68544
72576192 オクテットの 0、または追加オプション用のオーバーフロー スペース。BOOTP レガシー。
⋮⋮
2602080
2642112マジッククッキー（0x63825363）
DHCP オプション ( TLV形式)
2682144最初のオプション: 0x350105 : オプション53 (DHCPメッセージタイプ) 1オクテット (DHCPACKを含む)2番目のオプション:↴
2722176↪0x0104ffffff00 : オプション1 (サブネットマスク) 4オクテット ( 255.255.255.0を含む)
27622083番目のオプション: 0x0304c0A80101 : オプション: 3 (ルーター) 4オクテット ( 192.168.1.1を含む)↴
2802240↪ルーター継続...4番目のオプション: 0x330400015080 : オプション51 (アドレス時間) 4オクテット (86400秒のリース時間)↴
2842272↪アドレス時間継続...5番目のオプション:
28823040x060c09070a0f09070a1009070a13 :オプション6
（ドメインサーバー）14オクテット（9.7.10.15、9.7.10.16、9.7.10.18を含む）
2922336
2962368
3002400 ff

IPアドレスの選択と設定

サーバーがプールからIPアドレスを再利用する場合、最初に（pingを使用して）そのアドレスがすでに使用されていないかどうかを確認することがあります。[1] ：2.2節 これは、ホストがDHCPスコープ内にあるIPアドレスで手動で構成されている場合に発生する可能性があります。

IPアドレスを要求する前に、クライアントは新しく受信したアドレスを（例えばARPを使って）プローブし、ネットワーク内にそのIPアドレスを持つ別のホストが存在するかどうかを確認する必要があります。[1] ：第2.2節 応答がない場合、このアドレスは他のホストのアドレスと競合していないため、自由に使用できます。このプローブによって、そのアドレスを使用している別のコンピュータが見つかった場合、クライアントはDHCPサーバーにDHCPDECLINEをブロードキャストする必要があります。

情報

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

リリース

クライアントはDHCPサーバーにDHCP情報の解放要求を送信し、IPアドレスを非アクティブ化します。クライアントデバイスは通常、ユーザーがいつネットワークから切断されるかを把握できないため、プロトコルではDHCP Releaseの送信は必須ではありません。

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

DHCPサーバーは、クライアントにオプションの設定パラメータを提供することができます。RFC 2132では、インターネット割り当て番号局（IANA）によって定義された利用可能なDHCPオプション（DHCPおよびBOOTPパラメータ）について説明しています。[12]

DHCPクライアントは、DHCPサーバーから提供されるパラメータを選択、操作、上書きできます。Unix系システムでは、このクライアントレベルの調整は通常、設定ファイル/etc/dhclient.confの値に基づいて行われます。

オプション

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

次の表は利用可能なDHCPオプションの一覧です。[13] [12]

RFC 1497 (BOOTPベンダー情報拡張) ベンダー拡張[13] : セクション3 
コード名前長さ注記
0パッド0オクテット他のオプションをワード境界に揃えるために使用できます。長さバイトは続きません。
1サブネットマスク4オクテットRFC 950 に準拠したクライアントのサブネット マスク。サブネット マスクとルーター オプション (オプション 3) の両方が含まれる場合は、サブネット マスク オプションを最初にする必要があります。
2時間オフセット4オクテットクライアントのサブネットの協定世界時（UTC）からのオフセット（秒単位）。オフセットは2の補数形式の32ビット整数で表されます。正のオフセットは基準子午線の東側、負のオフセットは西側を示します。
3ルーター4オクテットの倍数利用可能なルーターは優先順位に従ってリストされます
4タイムサーバー4オクテットの倍数同期可能なタイムプロトコルサーバーは、優先順位に従ってリストされます。
5ネームサーバー4オクテットの倍数利用可能なIEN 116ネームサーバーは、優先順位に従ってリストされる必要があります。
6ドメインネームサーバー4オクテットの倍数利用可能なDNSサーバーは、優先順にリストされます
7ログサーバー4オクテットの倍数利用可能なログサーバーは、優先順にリストされる必要があります
8クッキーサーバー4オクテットの倍数この場合のCookie は、「フォーチュン クッキー」や「今日の名言」など、大型コンピュータのログオン プロセスの一環として送信される簡潔でユーモラスな逸話を意味します。Webサイトから送信される Cookieとはまったく関係ありません。
9LPRサーバー4オクテットの倍数クライアントが利用できるラインプリンタデーモンプロトコルサーバのリストは、優先順位に従ってリストされる必要があります。
10Impressサーバー4オクテットの倍数クライアントが利用できるImagen Impressサーバーのリストは、優先順位に従ってリストされる必要があります。
11リソースロケーションサーバー4オクテットの倍数クライアントが利用できるリソースロケーションプロトコルサーバーのリストは、優先順位に従ってリストされる必要があります。
12ホスト名最小1オクテットクライアントの名前。名前はローカルドメイン名で修飾できます。
13ブートファイルのサイズ2オクテットブートイメージの長さ（512Bブロック）
14Meritダンプファイル最小1オクテットクラッシュダンプを保存するパス
15ドメイン名最小1オクテット
16スワップサーバー4オクテット
17ルートパス最小1オクテット
18拡張機能パス最小1オクテット
255終わり0オクテットベンダーオプションフィールドの終了を示すために使用されます
ホストごとのIP層パラメータ[13] ：セクション4 
コード名前長さ注記
19IP転送の有効化/無効化1オクテット
20非ローカルソースルーティングの有効化/無効化1オクテット
21ポリシーフィルター8オクテットの倍数
22最大データグラム再構成サイズ2オクテット
23デフォルトの IP 有効期間1オクテット
24パスMTUエージングタイムアウト4オクテット
25パスMTUプラトーテーブル2オクテットの倍数
インターフェースごとのIP層パラメータ[13] ：セクション5 
コード名前長さ注記
26インターフェースMTU2オクテット
27すべてのサブネットはローカルです1オクテット
28ブロードキャストアドレス4オクテット
29マスク検出を実行する1オクテット
30マスクサプライヤー1オクテット
31ルーターの検出を実行する1オクテット
32ルータ要請アドレス4オクテット
33静的ルート8オクテットの倍数宛先/ルーターのペアのリスト
インターフェースごとのリンク層パラメータ[13] ：セクション6 
コード名前長さ注記
34トレーラーカプセル化オプション1オクテット
35ARPキャッシュタイムアウト4オクテット
36イーサネットカプセル化1オクテット
TCPパラメータ[13] ：セクション7 
コード名前長さ注記
37TCPデフォルトTTL1オクテット
38TCPキープアライブ間隔4オクテット
39TCPキープアライブガベージ1オクテット
アプリケーションおよびサービスパラメータ[13] ：セクション8 
コード名前長さ注記
40ネットワーク情報サービスドメイン最小1オクテット
41ネットワーク情報サーバー4オクテットの倍数
42ネットワークタイムプロトコル（NTP）サーバー4オクテットの倍数
43ベンダー固有の情報最小1オクテット
44NetBIOS over TCP/IP ネームサーバー4オクテットの倍数
45NetBIOS over TCP/IP データグラム配布サーバー4オクテットの倍数
46NetBIOS over TCP/IP ノードタイプ1オクテット
47NetBIOS over TCP/IP スコープ最小1オクテット
48X Window Systemフォントサーバー4オクテットの倍数
49X Window System ディスプレイマネージャー4オクテットの倍数
64ネットワーク情報サービス+ ドメイン最小1オクテット
65ネットワーク情報サービス+サーバー4オクテットの倍数
68モバイルIPホームエージェント4オクテットの倍数
69シンプルメール転送プロトコル（SMTP）サーバー4オクテットの倍数
70ポストオフィスプロトコル（POP3）サーバー4オクテットの倍数
71ネットワークニュース転送プロトコル（NNTP）サーバー4オクテットの倍数
72デフォルトのワールドワイドウェブ(WWW) サーバー4オクテットの倍数
73デフォルトのFingerプロトコルサーバー4オクテットの倍数
74デフォルトのインターネットリレーチャット（IRC）サーバー4オクテットの倍数
75ストリートトークサーバー4オクテットの倍数
76ストリートトークディレクトリアシスタンス（STDA）サーバー4オクテットの倍数
DHCP拡張[13] ：セクション9 
コード名前長さ注記
50要求されたIPアドレス4オクテット
51IPアドレスのリース期間4オクテット
52オプションオーバーロード1オクテット
53DHCPメッセージタイプ1オクテット
54サーバー識別子4オクテット
55パラメータ要求リスト最小1オクテット
56メッセージ最小1オクテット
57最大DHCPメッセージサイズ2オクテット
58更新（T1）時間価値4オクテット
59再バインド（T2）時間値4オクテット
60ベンダークラス識別子最小1オクテット
61クライアント識別子最小2オクテット
66TFTPサーバー名最小1オクテット
67ブートファイル名最小1オクテット

DHCPメッセージの種類

この表はDHCPメッセージの種類を示しています。これらのコードは、上記の表に示されているDHCP拡張53の値です。

DHCPメッセージの種類
コード名前長さRFC
1DHCP検出1オクテット2132 [13] : §9.6 
2DHCPオファー1オクテット2132
3DHCPリクエスト1オクテット2132
4DHCP拒否1オクテット2132
5DHCPACK1オクテット2132
6DHCPNAK1オクテット2132
7DHCPリリース1オクテット2132
8DHCPINFORM1オクテット2132
9DHCPFORCERENEW1オクテット3203 [14] : §4 
10DHCPLEASEQUERY1オクテット4388 [15] : §6.1 
11DHCPLEASE未割り当て1オクテット4388
12DHCPLEASE不明1オクテット4388
13DHCPLEASEACTIVE1オクテット4388
14DHCPバルクリースクエリ1オクテット6926 [16] : §6.2.1 
15DHCPLEASEQUERYDONE1オクテット6926
16DHCPアクティブリースクエリ1オクテット7724 [17] : §5.2.1 
17DHCPLEASEQUERYSTATUS1オクテット7724
18DHCPTLS1オクテット7724

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

DHCPクライアントのベンダーと機能を識別するオプションが存在します。この情報は、 DHCPクライアントのベンダーによって指定された意味を持つ、可変長の文字列またはオクテットです。DHCPクライアントが特定の種類のハードウェアまたはファームウェアを使用していることをサーバーに通知する方法の一つは、DHCP要求にベンダークラス識別子（VCI）（オプション60）を設定することです。

このオプションに設定された値は、DHCPサーバーに、クライアントがDHCP応答で必要とする追加情報に関するヒントを与えます。一部のセットトップボックスでは、VCIを設定して、デバイスのハードウェアタイプと機能をDHCPサーバーに通知します。例えば、Arubaキャンパス無線アクセスポイントは、DHCPDISCOVERメッセージのオプション60として「ArubaAP」という値を提供します。 [18] DHCPサーバーは、オプション43でAruba無線コントローラーのIPアドレスをDHCPOFFERに追加することで、アクセスポイントが自身を登録する場所を認識できるようにします。

クライアントが VCI を設定すると、DHCP サーバーはクライアント マシンを区別し、それらからの要求を適切に処理できるようになります。

その他の拡張機能

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

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

リレーエージェント情報オプション（オプション82）は、DHCPリレーとDHCPサーバー間で送信されるDHCP要求にサブオプションを添付するためのコンテナを指定します。[27]

リレーエージェントのサブオプション
コード名前長さRFC
1エージェント回路ID最小1オクテット3046 [20]
2エージェントリモートID最小1オクテット3046
4データオーバーケーブルサービスインターフェース仕様（DOCSIS）デバイスクラス4オクテット3256 [28]

リレー

1つのIPサブネットのみを管理する小規模ネットワークでは、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 が使用されます。

クライアント国

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

DHCPクライアントはサーバーから以下のメッセージを受信できる: [1] : §4.4 

  • DHCPオファー
  • DHCPACK
  • DHCPNAK

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

信頼性

DHCP は、定期的な更新、再バインド、[1] : §4.4.5 、フェイルオーバーなど、いくつかの方法で信頼性を確保します。DHCP クライアントには、一定期間有効なリースが割り当てられます。リース期間の半分が経過すると、クライアントはリースの更新を試行し始めます。[1] : §4.4.5 パラグラフ 3 クライアントは、元のリースを付与した DHCP サーバーにユニキャストDHCPREQUESTメッセージを 送信することでこれを行います。そのサーバーがダウンしているか到達不能な場合は、 DHCPREQUESTに応答できません。ただし、その場合、クライアントは定期的にDHCPREQUEST を繰り返します。 [1] : §4.4.5 パラグラフ 8  [b]そのため、DHCP サーバーが復旧するか再び到達可能になると、DHCP クライアントは接続に成功し、リースを更新します。

DHCPサーバーが長時間到達不能な場合、[1] : §4.4.5 パラグラフ5 によると、  DHCPクライアントはDHCPREQUESTをユニキャストではなくブロードキャストすることで再バインドを試みます。ブロードキャストであるため、DHCPREQUESTメッセージは利用可能なすべてのDHCPサーバーに到達します。他のDHCPサーバーがリースを更新できる場合、その時点で更新が行われます。

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

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

IPv6ネットワーク

DHCPの基本的な手法は、インターネットプロトコルバージョン4 （IPv4）ベースのネットワーク向けに開発されました。IPv6ネットワークの開発と導入以来、ステートレスなアドレス自動設定というIPv6固有の機能にもかかわらず、DHCPはIPv6ネットワークにおけるパラメータ割り当てにも使用されるようになりました。このプロトコルのIPv6バージョンはDHCPv6と呼ばれます。[30]

安全

基本DHCPには認証機構が一切含まれていない。[20] : §7 このため、様々な攻撃に対して脆弱である。これらの攻撃は主に3つのカテゴリーに分類される。[1] : §7 

  • 不正な DHCP サーバーがクライアントに誤った情報を提供します。
  • 権限のないクライアントがリソースにアクセスする。
  • 悪意のある DHCP クライアントからのリソース枯渇攻撃。

クライアントはDHCPサーバーの身元を検証する方法がないため、ネットワーク上で不正なDHCPサーバー（一般に「不正DHCP」と呼ばれる）が稼働し、DHCPクライアントに誤った情報を提供する可能性があります。[31] これは、サービス拒否攻撃（クライアントがネットワーク接続にアクセスできないようにする攻撃）として、または中間者攻撃（man-in-the-middle attack）として機能します。[33] DHCPサーバーは、1つまたは複数のDNSサーバーのIPアドレスなどのサーバーのIPアドレスをDHCPクライアントに提供するため、[1] : sec. 7 攻撃者はDHCPクライアントに自身のDNSサーバーを介してDNSルックアップを行うように仕向けることができ、その結果、クライアントからのDNSクエリに対して独自の回答を提供できるようになります。[34]これにより、攻撃者はネットワークトラフィックを自身を経由してリダイレクトし、接続するクライアントとネットワークサーバー間の接続を盗聴したり、それらのネットワークサーバーを自身のサーバーに置き換えたりすることができます。[34]

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

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

もう一つの拡張であるDHCPメッセージの認証[37]（RFC 3118）は、DHCPメッセージの認証メカニズムを提供します。2002年時点では、多数のDHCPクライアントの鍵管理に問題があったため、この拡張は広く普及していませんでした。[38] 2007年に出版されたDSL技術に関する書籍では、次のように述べられています。

RFC 3118で提案されたセキュリティ対策に対して、多数のセキュリティ上の脆弱性が確認されました。この事実と802.1Xの導入が相まって、認証付きDHCPの導入と普及率が低下し、広く導入されることはありませんでした。[39]

2010 年の書籍では次のように述べられています。

DHCP認証の実装はごくわずかです。鍵管理の課題やハッシュ計算による処理遅延は、想定されるメリットに比べてあまりにも大きな代償であるとみなされてきました。[40]

2008年のアーキテクチャ提案では、DHCPリクエストの認証に802.1XまたはPANA（どちらもEAPを伝送する）が用いられている。[41] IETFは、DHCP自体にEAPを組み込む提案（いわゆるEAPoDHCP ）を行ったが、[42]これはIETFのドラフトレベルを超えて進展していないようで、最後のドラフトは2010年に遡る。[43]

IETF標準文書

  • RFC 2131 –「ダイナミックホスト構成プロトコル」[1] ドラフト標準。
  • RFC 2132 –「DHCPオプションとBOOTPベンダー拡張」[13] ドラフト標準。
  • RFC 3046 –「DHCPリレーエージェント情報オプション」[20] 提案標準。
  • RFC 3203 – 「DHCP再構成拡張」[14] 提案標準。
  • RFC 3397 –「ダイナミックホスト構成プロトコル（DHCP）ドメイン検索オプション」[24] 提案標準。
  • RFC 3442 –「ダイナミックホスト構成プロトコル（DHCP）バージョン4のクラスレス静的ルートオプション」[25] 提案標準。
  • RFC 3942 –「動的ホスト構成プロトコルバージョン4（DHCPv4）オプションの再分類」[44] 提案標準。
  • RFC 4361 – 「動的ホスト構成プロトコルバージョン4（DHCPv4）のノード固有のクライアント識別子」[45] 提案標準。
  • RFC 4388 –「ダイナミックホスト構成プロトコル（DHCP）リースクエリ」[15] 提案標準。
  • RFC 4436 – 「IPv4でのネットワーク接続の検出（DNAv4）」[46] 提案標準。
  • RFC 6926 – 「DHCPv4バルクリースクエリ」[16] 提案標準。
  • RFC 7724 –「アクティブDHCPv4リースクエリ」[17] 提案標準。
  • RFC 8415 –「IPv6用動的ホスト構成プロトコル（DHCPv6）」[9] 提案標準。

参照

注記

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

参考文献

  1. ^ abcdefghijklmnopqrs R. Droms (1997年3月). ダイナミックホストコンフィギュレーションプロトコル. IETFネットワークワーキンググループ. doi : 10.17487/RFC2131 . RFC 2131. ドラフト標準。RFC 1541 を廃止。RFC 3396、4361、5494、6842 により更新。
  2. ^ ピーターソン, ラリー・L.; デイヴィー, ブルース・S. (2011). 『コンピュータネットワーク：システムアプローチ』（第5版）. エルゼビア. ISBN 978-0-12-385060-7. 2019年3月21日閲覧。
  3. ^ R. Finlayson; T. Mann; J. Mogul; M. Theimer (1984年6月). 逆アドレス解決プロトコル. ネットワークワーキンググループ. doi : 10.17487/RFC0903 . STD 38. RFC 903. インターネット標準 38。
  4. ^ Bill Croft、John Gilmore (1985年9月). ブートストラッププロトコル (BOOTP). ネットワークワーキンググループ. doi : 10.17487/RFC0951 . RFC 951. ドラフト標準。RFC 1395、1497、1532、1542、および 5494 によって更新されました。
  5. ^ R. Droms (1993年10月). ダイナミックホスト構成プロトコル. ネットワークワーキンググループ. doi : 10.17487/RFC1531 . RFC 1531. 廃止。編集プロセスにおけるエラーのため、RFC 1541 によって廃止されました。
  6. ^ R. Droms (1993年10月). ダイナミックホスト構成プロトコル. ネットワークワーキンググループ. doi : 10.17487/RFC1541 . RFC 1541. 廃止。RFC 2131 により廃止。RFC 1531 より廃止。
  7. ^ Network+ Certification 2006 は Microsoft Press から出版されています。
  8. ^ J. Bound; B. Volz; T. Lemon; C. Perkins; M. Carney (2002年7月). R. Droms (編). IPv6用動的ホスト構成プロトコル (DHCPv6). ネットワークワーキンググループ. doi : 10.17487/RFC3315 . RFC 3315. 廃止。RFC 8415 により廃止。RFC 4361、5494、6221、6422、6644、7083、7283、7227、7550 により更新。
  9. ^ ab T. Mrugalski; M. Siodelski; B. Volz; A. Yourtchenko; M. Richardson; S. Jiang; T. Lemon; T. Winters (2018年11月). IPv6用動的ホスト構成プロトコル（DHCPv6）.インターネット技術タスクフォース. doi : 10.17487/RFC8415 . ISSN  2070-1721. RFC 8415. 提案された標準。RFC 3315、3633、3736、4242、7083、7283、および 7550 を廃止します。
  10. ^ 「DHCP - 動的ホスト構成プロトコル」。
  11. ^ Droms, Ralph; Lemon, Ted (2003). DHCPハンドブック. SAMS Publishing . p. 436. ISBN 978-0-672-32327-0。
  12. ^ ab 「Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters」. iana.org . 2018年10月16日閲覧。
  13. ^ abcdefghij S. Alexander; R. Droms (1997年3月). DHCPオプションとBOOTPベンダー拡張. IETFネットワークワーキンググループ. doi : 10.17487/RFC2132 . RFC 2132. ドラフト標準。RFC 1533 は廃止されました。RFC 3442、3942、4361、4833、および 5494 によって更新されました。
  14. ^ ab Y. ティジョーンズ; C. ハブレット。 P. De Schrijver (2001 年 12 月)。 DHCP 再構成拡張機能。ネットワークワーキンググループ。土井: 10.17487/RFC3203。RFC 3203。 提案された標準。RFC 6704 によって更新されました。
  15. ^ ab R. Woundy; K. Kinnear (2006年2月). Dynamic Host Configuration Protocol (DHCP) Leasequery. Network Working Group. doi : 10.17487/RFC4388 . RFC 4388. 提案された標準。RFC 6148 によって更新されました。
  16. ^ ab K. Kinnear; M. Stapp; R. Desetti; B. Joshi; N. Russell; P. Kurapati; B. Volz (2013年4月). DHCPv4 バルクリースクエリ.インターネット技術タスクフォース. doi : 10.17487/RFC6926 . ISSN  2070-1721. RFC 6926. 提案された標準。RFC 7724 によって更新されました。
  17. ^ ab K. Kinnear; M. Stapp; B. Volz; N. Russell (2015年12月). Active DHCPv4 Lease Query. Internet Engineering Task Force . doi : 10.17487/RFC7724 . ISSN  2070-1721. RFC 7724. 提案された標準。RFC 6926 を更新します。
  18. ^ “Aruba DHCP Option 60”. 2020年10月7日. 2022年4月17日時点のオリジナルよりアーカイブ。
  19. ^ G. Stump; R. Droms; Y. Gu; R. Vyaghrapuri; A. Demirtjis; B. Beser; J. Privat (2000年11月). DHCPのユーザークラスオプション. ネットワークワーキンググループ. doi : 10.17487/RFC3004 . RFC 3004. 提案された標準。
  20. ^ abcdef M. Patrick (2001年1月). DHCPリレーエージェント情報オプション. ネットワークワーキンググループ. doi : 10.17487/RFC3046 . RFC 3046. 提案された標準。RFC 6607 によって更新されました。
  21. ^ abc D. Provan (1997年11月). Novellディレクトリサービス用DHCPオプション. ネットワークワーキンググループ. doi : 10.17487/RFC2241 . RFC 2241. 提案された標準。
  22. ^ E. Lear; P. Eggert (2007年4月). DHCPのタイムゾーンオプション. ネットワークワーキンググループ. doi : 10.17487/RFC4833 . RFC 4833. 提案された標準。RFC 2132 を更新します。
  23. ^ W. Kumari; E. Kline (2020年9月). DHCPおよびルーター広告（RA）におけるキャプティブポータル識別.インターネット技術特別調査委員会. doi : 10.17487/RFC8910 . ISSN  2070-1721. RFC 8910. 提案された標準。RFC 7710 を廃止します。RFC 3679 を更新します。
  24. ^ ab B. Aboba; S. Cheshire (2002年11月). ダイナミックホスト構成プロトコル（DHCP）ドメイン検索オプション. ネットワークワーキンググループ. doi : 10.17487/RFC3397 . RFC 3397. 提案された標準。
  25. ^ ab T. Lemon; S. Cheshire ; B. Volz (2002年12月). Dynamic Host Configuration Protocol (DHCP) バージョン4のクラスレススタティックルートオプション. Network Working Group. doi : 10.17487/RFC3442 . RFC 3442. 提案された標準。RFC 2132 を更新します。
  26. ^ D. Hankins (2007年12月). PXELINUXで使用されるダイナミックホスト構成プロトコルオプション. ネットワークワーキンググループ. doi : 10.17487/RFC5071 . RFC 5071. 情報提供。
  27. ^ Patrick, Michael (2001年1月). 「DHCPリレーエージェント情報オプション」 . IETF文書. IETF . doi :10.17487/RFC3046 . 2017年7月22日閲覧。
  28. ^ D. Jones; R. Woundy (2002年4月). DOCSIS (Data-Over-Cable Service Interface Specifications) デバイスクラス DHCP (Dynamic Host Configuration Protocol) リレーエージェント情報サブオプション. ネットワークワーキンググループ. doi : 10.17487/RFC3256 . RFC 3256. 提案された標準。
  29. ^ Droms, Ralph; Kinnear, Kim; Stapp, Mark; Volz, Bernie; Gonczi, Steve; Rabil, Greg; Dooley, Michael; Kapur, Arun (2003年3月). DHCPフェイルオーバープロトコル. IETF . ID draft-ietf-dhc-failover-12 . 2010年5月9日閲覧。
  30. ^ Weinberg, Neal (2018年8月14日). 「DHCPの終焉が近い理由」. Network World . 2019年8月7日閲覧。
  31. ^ abc Stapko, Timothy (2011). 『実践的な組み込みセキュリティ：リソース制約のある安全なシステムの構築』Newnes. p. 39. ISBN 978-0-08-055131-9。
  32. ^ Rountree, Derrick (2013). Windows 2012 Server ネットワークセキュリティ: Windows ネットワークシステムとインフラストラクチャのセキュリティ保護. Newnes. p. 22. ISBN 978-1-59749-965-1。
  33. ^ ルーニー、ティモシー（2010年）『IPアドレス管理入門』John Wiley & Sons. p. 180. ISBN 978-1-118-07380-3。
  34. ^ ab Golovanov (Kaspersky Labs), Sergey (2011年6月). 「TDSSローダーが「足」を踏むようになった」. 2021年1月25日時点のオリジナルよりアーカイブ。
  35. ^ ヘンズ、フランシスコ・J.、カバレロ、ホセ・M. (2008). 『トリプルプレイ：IP、VoIP、IPTVのための統合ネットワークの構築』John Wiley & Sons. p. 239. ISBN 978-0-470-75439-9。
  36. ^ ラミレス、デビッド・H. (2008). IPTVセキュリティ：高価値デジタルコンテンツの保護. ジョン・ワイリー・アンド・サンズ. p. 55. ISBN 978-0-470-72719-5。
  37. ^ R. Droms; W. Arbaugh編 (2001年6月). DHCPメッセージの認証. ネットワークワーキンググループ. doi : 10.17487/RFC3118 . RFC 3118. 提案された標準。
  38. ^ Lemon, Ted (2002年4月). 「RFC 3118の実装」
  39. ^ ゴールデン、フィリップ、デディウ、エルヴェ、ヤコブセン、クリスタ・S. (2007). DSL技術の実装と応用. テイラー＆フランシス. p. 484. ISBN 978-1-4200-1307-8。
  40. ^ ルーニー、ティモシー（2010年）『IPアドレス管理入門』ジョン・ワイリー・アンド・サンズ、pp.  181– 182. ISBN 978-1-118-07380-3。
  41. ^ コープランド、レベッカ（2008年）『IMSによるNGN有線ネットワークとモバイル3Gネットワ​​ークの統合』テイラー＆フランシス、pp.  142– 143. ISBN 978-1-4200-1378-8。
  42. ^ Prasad, Ramjee; Mihovska, Albena (2009). 『モバイルおよび無線通信の新たな地平：ネットワーク、サービス、アプリケーション』第2巻. Artech House. p. 339. ISBN 978-1-60783-970-5。
  43. ^ 「Draft-pruss-DHCP-auth-DSL-07 - ブロードバンド向けダイナミックホスト構成プロトコルのEAP認証拡張」。2015年4月3日時点のオリジナルよりアーカイブ。 2013年12月12日閲覧。
  44. ^ B. Volz (2004年11月). ダイナミックホスト構成プロトコルバージョン4（DHCPv4）オプションの再分類. ネットワークワーキンググループ. doi : 10.17487/RFC3942 . RFC 3942. 提案された標準。RFC 2132 を更新します。
  45. ^ T. Lemon; B. Sommerfield (2006年2月). 動的ホスト構成プロトコルバージョン4（DHCPv4）におけるノード固有のクライアント識別子. ネットワークワーキンググループ. doi : 10.17487/RFC4361 . RFC 4361. 提案された標準。RFC 5494 によって更新されました。RFC 2131、3315、および 2132 を更新します。
  46. ^ B. Aboba; J. Carlson; S. Cheshire (2006年3月). IPv4におけるネットワーク接続の検出 (DNAv4). ネットワークワーキンググループ. doi : 10.17487/RFC4436 . RFC 4436. 提案された標準。
  • ウィキメディア・コモンズの動的ホスト構成プロトコル (DHCP) に関連するメディア
Retrieved from "https://en.wikipedia.org/w/index.php?title=Dynamic_Host_Configuration_Protocol&oldid=1317322558"