Dynamic Host Configuration Protocol

UDP/IPネットワークで使用されるネットワーク管理プロトコル
DHCPから転送)

Dynamic Host Configuration Protocol(ダイナミック ホスト コンフィギュレーション プロトコル、DHCP)は、IPv4ネットワークで使用されるネットワーク管理プロトコルであり、コンピュータネットワークに接続する際に必要な設定情報を自動的に割り当てるために使用する。 BOOTPにリース機能を追加してDHCPとなっている。

Dynamic Host Configuration Protocol
通信プロトコル
目的 コンピュータがネットワークに接続する際に必要な設定情報の自動的な割り当て
導入 1993年10月 (30年前) (1993-10)
派生元 BOOTP
派生先 DHCPv6
OSI階層 アプリケーション層
ポート 67(サーバ)
68(クライアント)
RFC RFC 2131

DHCPサーバは、IPアドレス等のネットワーク構成設定をネットワーク上の各デバイスに動的に割り当て、他のIPネットワークと通信できるようにする[1]。DHCPサーバを使用すると、コンピュータは自動的にIPアドレスとネットワーク設定を要求でき、ネットワーク管理者やエンドユーザが全てのネットワークデバイスに手動でIPアドレスを割り当てる必要がなくなる[1]

DHCPは、ホームネットワーク英語版から大規模なキャンパスネットワーク英語版、地域のインターネットサービスプロバイダネットワークまで、様々な規模のネットワークに実装できる[2]。ほとんどのルータまたはホームゲートウェイは、DHCPサーバとして機能させることができ、ローカルネットワーク内において、ネットワークに接続されている各デバイスにローカルIPアドレスを割り当てることができる。

概要 編集

UDP/IPは、あるネットワーク上のデバイスが別のネットワーク上のデバイスと通信する方法を定義する。DHCPサーバは、IPアドレスを自動的または動的にデバイスに割り当てることによって、ネットワーク上のデバイスのUDP/IP設定を管理できる。

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

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

DHCPは、IPv4IPv6のどちらでも使用される。どちらのバージョンでも目的は同じであるが、IPv4とIPv6のプロトコルの詳細は大きく異なることから別のプロトコルと見なされる[3]。IPv6のDHCPはDHCPv6と呼ばれ、 RFC 8415 で定められている。DHCPv6はDHCPv4とは互換性がないが、IPv6だけでなくIPv4のアドレスを割り当てることもできる。IPv6では、IPアドレスとネットマスクの情報をIPv6自体のアドレス自動設定機能により取得することもできるが、DNSサーバやNTPサーバなどほかの情報も自動取得するためにはDHCPが必要になる。

割り当ての種類 編集

DHCPサーバがIPアドレスを割り当てる方法には以下の3つがあり、サーバの設定により選択することができる。

動的割り当て
ネットワーク管理者がDHCP用のIPアドレスの範囲を予約し、LAN上の各DHCPクライアントはDHCPサーバにIPアドレスを要求するように構成されている。IPアドレスの割り当ての際には、そのIPアドレスが有効な期間(リース期間)が指定され、DHCPクライアントはリース期間満了前に更新を行う必要がある。DHCPサーバは、更新されずにリース期間が満了したIPアドレスを他のDHCPクライアントに再割り当てすることができる。
自動割り当て
DHCPサーバは、管理者によって定義された範囲からIPアドレスを要求側クライアントに永続的に割り当てる。これは動的割り当てに似ているが、DHCPサーバは過去のIPアドレス割り当てのテーブルを保持しているので、クライアントが以前に持っていたのと同じIPアドレスを優先的にクライアントに割り当てることができる。
静的割り当て
DHCPサーバは、管理者によって事前定義されたマッピングに基づいて、各クライアントのクライアント識別子(またはクライアントのMACアドレス)に応じてIPアドレスを発行する。この機能は、ルータのメーカーによって様々な名称で呼ばれている。DD-WRTは静的DHCP割り当て(static DHCP assignment)、dhcpdでは固定アドレス(fixed-address)、ネットギアではアドレス予約(address reservation)、シスコリンクシスはDHCP予約(DHCP reservation)または静的DHCP(static DHCP)としているほか、IPアドレス予約(IP address reservation)やMAC/IPアドレスバインディング(MAC/IP address binding)とも呼ばれる。クライアントのクライアント識別子またはMACアドレスに一致するものがマッピングになかった場合、サーバは動的割り当てまたは自動割り当てにフォールバックしてIPアドレスを割り当てる場合と、IPアドレス割り当て自体をしない場合がある。

いずれの方法でも、通常配信されたIPアドレスはDHCPサーバーからリース(貸与)されたものとなっており、永続的に適用出来るものではない。貸与期間の有効期限はDHCP Optionとして配信される。Optionの値は32bit値で単位は秒のため、1秒〜約136年の間で指定が可能である。リース期間は延長が可能であり、リース期間の50%の時間が経過した際(T1と呼ばれる)と87.5%の時間が経過した際(T2と呼ばれる)に延長承認をDHCPサーバーから得るよう動作させることがRFCで定められている。この機能により、リース期間が短く設定されたDHCP環境であっても、DHCPクライアントが継続的に同一のIPアドレスを使用することが可能になっている。

この有効期限を定めたIPアドレスのリースはもっとも一般的な利用方法であるが、クライアントの種類(ノートPC、デスクトップ)と数、割り当て可能なIPアドレスの総数によって適切な有効期間は異なってくる。

短くするとIPアドレスを効率よく使えるが、ネットワーク上に頻繁にDHCPのプロトコルが流れることになる。長くするとクライアントは安定してIPアドレスを保持できるが、使用されていないにもかかわらず割り当てできないIPアドレスが多くなる。一般に、ノートPCが多くてIPアドレスを一時的にしか使用しないネットワークの場合は数十分〜1日程度、デスクトップPCが多くIPアドレスも十分に足りている場合は一週間以上とすればいいだろう。

リース期間のOptionを配信しないことで、有効期間を無期限とすることも可能だが、この場合はリースしたアドレスが回収されないので、時々使用していないIPアドレスを手動で解放する必要がある。

動作 編集

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

DHCPは、User Datagram Protocol(UDP)を使用した、コネクションレスサービスモデルを採用している。Bootstrap Protocol(BOOTP)と同じ動作をするために、2つのUDPポート番号で実装されている。UDPポート番号67はサーバの宛先ポートであり、UDPポート番号68はクライアントによって使用される。

DHCPの動作は、サーバ探索、IPリース提示、IPリース要求、IPリース確認の4段階に分けられる。これは、discovery(探索), offer(提示), request(要求), acknowledgement(確認)の頭文字をとって"DORA"とよばれることがある。

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

DHCP discover 編集

DHCPクライアントは、255.255.255.255(リミテッド・ブロードキャストアドレス)または特定のサブネットブロードキャストアドレス(ディレクテッド・ブロードキャストアドレス)を使用して、サブネット上にDHCPDISCOVERメッセージをブロードキャストで送信する。DHCPクライアントは、最後に認識されたIPアドレスを要求することもある。クライアントが同じネットワークに接続されたままの場合、サーバは要求を許可する。それ以外の場合は、サーバが権限(authoritative)ありに設定されているか否かによって異なる。権限ありのサーバは、要求を拒否して、クライアントに新しい要求を発行させる。権限なしのサーバは、単に要求を無視するため、クライアントは要求がタイムアウトしてから新しいIPアドレスを要求する。

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

DHCPDISCOVERメッセージの例

イーサネット: 送信元=送信者のMACアドレス; 送信先=FF:FF:FF:FF:FF:FF

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

Octet 0 Octet 1 Octet 2 Octet 3
OP HTYPE HLEN HOPS
0x01 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP address)
0x00000000
YIADDR (Your IP address)
0x00000000
SIADDR (Server IP address)
0x00000000
GIADDR (Gateway IP address)
0x00000000
CHADDR (Client hardware address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192オクテットの0、または追加オプション用のオーバーフロースペース。BOOTPとの互換性のため
マジッククッキー
0x63825363
DHCPオプション
0x350101 53: 1 (DHCP Discover)
0x3204c0a80164 50: 192.168.1.100を要求
0x370401030f06 55 (パラメータ要求リスト):
  • 1 (サブネットマスク),
  • 3 (ルータ),
  • 15 (ドメイン名),
  • 6 (DNSサーバ)
0xff 255 (終端マーク)

DHCP offer 編集

IPアドレスリース要求であるDHCPDISCOVERメッセージをクライアントから受信したDHCPサーバは、クライアントのIPアドレスを予約し、クライアントにDHCPOFFERメッセージを送信してリース提示を行う。このメッセージには、クライアントのクライアント識別子(またはMACアドレス)、サーバが提供しようとしているIPアドレスとそのサブネットマスク、リース期間、提供しているDHCPサーバのIPアドレスが含まれている。DHCPサーバは、基盤となるトランスポート層のハードウェアレベルのMACアドレスを参照することができる。現在のRFCでは、DHCPパケットにクライアント識別子が指定されていない場合はトランスポート層のMACアドレスを使用できる。

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

DHCPOFFERメッセージの例

イーサネット: 送信元=送信者のMACアドレス; 送信先=クライアントのMACアドレス

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

Octet 0 Octet 1 Octet 2 Octet 3
OP HTYPE HLEN HOPS
0x02 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP address)
0x00000000
YIADDR (Your IP address)
0xC0A80164 (192.168.1.100)
SIADDR (Server IP address)
0xC0A80101 (192.168.1.1)
GIADDR (Gateway IP address)
0x00000000
CHADDR (Client hardware address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192オクテットの0。BOOTPとの互換性のため
マジッククッキー
0x63825363
DHCPオプション
53: 2 (DHCP Offer)
1(サブネットマスク): 255.255.255.0
3(ルータ): 192.168.1.1
51(IPアドレスリース期間): 86400s(1日)
54(DHCPサーバ): 192.168.1.1
6(DNSサーバ):
  • 9.7.10.15,
  • 9.7.10.16,
  • 9.7.10.18

DHCP request 編集

クライアントは、DHCP offerに応答して、サーバにDHCPREQUESTメッセージでブロードキャストで送信し[注釈 1]、提示されたアドレスを要求する。クライアントは複数のサーバからDHCP offerを受信しても、1つのDHCP offerしか受け入れない。DHCP requestメッセージで要求されたserver identificationオプションによって、サーバは、DHCP offerがクライアントにより受け入れられたことを知る[7]:Section 3.1, Item 3。このメッセージを受け取った他のDHCPサーバは、クライアントに送信したDHCP offerを取り消し、IPアドレスを利用可能なアドレスのプールに返却する。

DHCPREQUESTメッセージの例

イーサネット: 送信元=送信者のMACアドレス; 送信先=FF:FF:FF:FF:FF:FF

IP: 送信元=0.0.0.0; 送信先=255.255.255.255[注釈 1]
UDP: 送信元ポート=68; 送信先ポート=67

Octet 0 Octet 1 Octet 2 Octet 3
OP HTYPE HLEN HOPS
0x01 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP address)
0x00000000
YIADDR (Your IP address)
0x00000000
SIADDR (Server IP address)
0xC0A80101 (192.168.1.1)
GIADDR (Gateway IP address)
0x00000000
CHADDR (Client hardware address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192オクテットの0。BOOTPとの互換性のため
マジッククッキー
0x63825363
DHCPオプション
53: 3 (DHCP Request)
50: 192.168.1.100を要求
54(DHCPサーバ): 192.168.1.1

DHCP acknowledgement 編集

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

プロトコルでは、DHCPクライアントがサーバから通知されたパラメータを使用してネットワークインターフェースを設定することを期待している。

クライアントはIPアドレスを得た後で、複数のDHCPサーバ間のアドレスプールの重なりによって引き起こされるアドレスの衝突を防ぐために、(Address Resolution Protocol(ARP)などを使って)新しく設定したアドレスが他のコンピュータで使われていないかを調べるべきである[8]

DHCPACKメッセージの例

イーサネット: 送信元=送信者のMACアドレス; 送信先=クライアントのMACアドレス

IP: 送信元=192.168.1.1; 送信先=192.168.1.100
UDP: 送信元ポート=67; 送信先ポート=68

Octet 0 Octet 1 Octet 2 Octet 3
OP HTYPE HLEN HOPS
0x02 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP address)
0x00000000
YIADDR (Your IP address)
0xC0A80164 (192.168.1.100)
SIADDR (Server IP address)
0xC0A80101 (192.168.1.1)
GIADDR (Gateway IP address switched by relay)
0x00000000
CHADDR (Client hardware address)
0x00053C04
0x8D590000
0x00000000

0x00000000
192オクテットの0。BOOTPとの互換性のため
マジッククッキー
0x63825363
DHCPオプション
53: 5 (DHCP ACK) または 6 (DHCP NAK)
1 (サブネットマスク): 255.255.255.0
3(ルータ): 192.168.1.1
51(IPアドレスリース期間): 86400s(1日)
54(DHCPサーバ): 192.168.1.1
6(DNSサーバ):
  • 9.7.10.15,
  • 9.7.10.16,
  • 9.7.10.18

DHCP information 編集

DHCPクライアントは、元のサーバがDHCPOFFERで送信したものよりも多くの情報を要求する可能性がある。クライアントは特定のアプリケーションのために繰り返しデータを要求することもある。例えば、ブラウザはDHCP Inform(DHCP通知)を使用してWeb Proxy Auto-Discovery Protocol(WPAD)経由でプロキシ設定を取得する。

DHCP releasing 編集

クライアントはDHCP情報を解放(リリース)するようにDHCPサーバに要求を送信し、それを受信したクライアントはそのIPアドレスを無効にする。通常、クライアントデバイスは、ユーザーがネットワークからデバイスを取り外すことができるかどうかを知らないので、プロトコルではDHCP Releaseの送信を義務付けていない。

クライアント設定パラメータ 編集

DHCPサーバは、オプションの設定パラメータをクライアントに提供できる。 RFC 2132 には、Internet Assigned Numbers Authority(IANA)によって定義されている使用可能なDHCPオプション(DHCPおよびBOOTPのパラメータ)が記載されている[9]

DHCPクライアントは、DHCPサーバによって提供されたパラメータを選択・操作・上書きすることができる。Unix系OSでは、このクライアントレベルの変更は通常、設定ファイル/etc/dhclient.confの値に従って行われる。

DHCPオプション 編集

オプションは様々な長さのオクテット文字列である。最初のオクテットはオプションコード、2番目のオクテットは後続オクテットの数で、残りのオクテットはオプションコードに依存する。例えば、offerのDHCPメッセージタイプオプションは0x35、0x01、0x02と表示される。ここで、0x35はDHCPメッセージタイプ(DHCP message type)のコード53で、0x01は後ろに1オクテットが続くことを表し、0x02は"offer"を表す値である。

RFC 2132 で定義 編集

次の表は、 RFC 2132 [10]およびIANAレジストリ[9]で定義されている利用可能なDHCPオプションを一覧にしたものである。


RFC 1497 (BOOTP Vendor Information Extensions) ベンダ拡張[10]:Section 3
コード 名称 長さ 備考
0 Pad[10]:Section 3.1 0 オクテット 他のオプションがバイト境界に揃うようにパディングするために使用する。長さバイトの後には何も続かない。
1 Subnet mask[10]:Section 3.3 4オクテット ルータオプション(オプション3)がある場合は、その前に送信する必要がある。
2 Time offset[10]:Section 3.4 4オクテット
3 Router 4オクテットの倍数 利用可能なルータ。優先順にリストされている。
4 Time server 4オクテットの倍数 利用可能な同期タイムサーバ。優先順にリストされている。
5 Name server 4オクテットの倍数 利用可能なIEN 116英語版ネームサーバ。優先順にリストされている。
6 Domain name server 4オクテットの倍数 利用可能なDNSサーバ。優先順にリストされている。
7 Log server 4オクテットの倍数 利用可能なログサーバ。優先順にリストされている。.
8 Cookie server 4オクテットの倍数 ここで言うCookieとは、fortuneコマンドで表示されるフォーチュン・クッキー(おみくじ)のための格言やジョークなどのことで、HTTP cookieとは関係ない。
9 LPR Server 4オクテットの倍数
10 Impress server 4オクテットの倍数
11 Resource location server 4オクテットの倍数
12 Host name 1オクテット以上
13 Boot file size 2オクテット ブートイメージの大きさ(4KiBブロック単位)
14 Merit英語版 dump file 1オクテット以上 クラッシュダンプを保存した場所のパス
15 Domain name 1オクテット以上
16 Swap server 4オクテット
17 Root path 1オクテット以上
18 Extensions path 1オクテット以上
255 End 0オクテット ベンダーオプションフィールドの終端を示すために使用される
ホストごとのIP層パラメータ[10]:Section 4
コード 名称 長さ 備考
19 IP forwarding enable/disable 1オクテット
20 Non-local source routing enable/disable 1オクテット
21 Policy filter 8オクテットの倍数
22 Maximum datagram reassembly size 2オクテット
23 Default IP time-to-live 1オクテット
24 Path MTU aging timeout 4オクテット
25 Path MTU plateau table 2オクテットの倍数
インターフェースごとのIP層パラメータ[10]:Section 5
コード 名称 長さ 備考
26 Interface MTU 2オクテット
27 All subnets are local 1オクテット
28 Broadcast address 4オクテット
29 Perform mask discovery 1オクテット
30 Mask supplier 1オクテット
31 Perform router discovery 1オクテット
32 Router solicitation address 4オクテット
33 Static route 8オクテットの倍数 送信先・ルータのペアのリスト
インターフェースごとのリンク層パラメータ[10]:Section 6
コード 名称 長さ 備考
34 Trailer encapsulation option 1オクテット
35 ARP cache timeout 4オクテット
36 Ethernet encapsulation 1オクテット
TCPパラメータ[10]:Section 7
コード 名称 長さ 備考
37 TCP default TTL 1オクテット
38 TCP keepalive interval 4オクテット
39 TCP keepalive garbage 1オクテット
アプリケーションとサービスのパラメータ[10]:Section 8
コード 名称 長さ 備考
40 Network information service domain 1オクテット以上
41 Network information servers 4オクテットの倍数
42 Network Time Protocol (NTP) servers 4オクテットの倍数
43 Vendor-specific information 1オクテット以上
44 NetBIOS over TCP/IP name server 4オクテットの倍数
45 NetBIOS over TCP/IP datagram Distribution Server 4オクテットの倍数
46 NetBIOS over TCP/IP node type 1オクテット
47 NetBIOS over TCP/IP scope 1オクテット以上
48 X Window System font server 4オクテットの倍数
49 X Window System display manager 4オクテットの倍数
64 Network Information Service+ domain 1オクテット以上
65 Network Information Service+ servers 4オクテットの倍数
68 Mobile IP home agent 4オクテットの倍数
69 Simple Mail Transfer Protocol (SMTP) server 4オクテットの倍数
70 Post Office Protocol (POP3) server 4オクテットの倍数
71 Network News Transfer Protocol (NNTP) server 4オクテットの倍数
72 Default World Wide Web (WWW) server 4オクテットの倍数
73 Default Finger protocol server 4オクテットの倍数
74 Default Internet Relay Chat (IRC) server 4オクテットの倍数
75 StreetTalk server 4オクテットの倍数
76 StreetTalk Directory Assistance (STDA) server 4オクテットの倍数
DHCP拡張[10]:Section 9
コード 名称 長さ 備考
50 Requested IP address 4オクテット
51 IP address lease time 4オクテット
52 Option overload 1オクテット
53 DHCP message type 1オクテット
54 Server identifier 4オクテット
55 Parameter request list 1オクテット以上
56 Message 1オクテット以上
57 Maximum DHCP message size 2オクテット
58 Renewal (T1) time value 4オクテット
59 Rebinding (T2) time value 4オクテット
60 Vendor class identifier 1オクテット以上
61 Client-identifier 2オクテット以上
66 TFTP server name 1オクテット以上
67 Bootfile name 1オクテット以上

DHCPクライアントのベンダ識別 編集

DHCPクライアントのベンダと機能を識別するためのオプションがある。この情報は、DHCPクライアントのベンダによって指定された意味を持つ可変長文字列またはオクテットである。DHCPクライアントが特定の種類のハードウェアまたはファームウェアを使用していることをサーバに通信するには、DHCP requestにベンダクラス識別子(VCI)と呼ばれる値(オプション60)を設定する。

この方法により、DHCPサーバーは2種類のクライアントマシンを区別し、2種類のモデムからの要求を適切に処理できる。一部のタイプのセットトップボックスでは、デバイスのハードウェアタイプと機能についてDHCPサーバーに通知するようにVCI(オプション60)も設定されている。このオプションが設定されている値は、このクライアントがDHCP応答で必要とする必要な追加情報についてのヒントをDHCPサーバに与える。

RFC 2132以外で定義 編集

定義されたDHCPオプション
コード 名称 長さ RFC
82 Relay agent information 2オクテット以上 RFC 3046[11]
85 Novell Directory Service (NDS) servers 4オクテット以上で、4オクテットの倍数 RFC 2241[12]:Section 2
86 NDS tree name 可変 RFC 2241[12]:Section 3
87 NDS context 可変 RFC 2241[12]:Section 4
100 Time zone, POSIX style 可変 RFC 4833[13]
101 Time zone, tz database style 可変 RFC 4833[13]
119 Domain search 可変 RFC 3397[14]
121 Classless static route 可変 RFC 3442[15]

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

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

Relay agent sub-options
コード 名称 長さ RFC
4 Data-Over-Cable Service Interface Specifications (DOCSIS) device class 4オクテット RFC 3256[16]

DHCPリレー 編集

DHCPはDHCPサーバの検索にブロードキャストを使用する関係上、通常はクライアントとサーバが同一ブロードキャスト・ドメイン上にないと正常に動作しない。しかしながら、企業や大学など比較的大規模なネットワークでは、サーバを1カ所に集中させたい等の理由でDHCPクライアントとサーバとが全く異なるネットワーク上に設置されることがある。

このような場合に使用されるのがDHCP Relay Agent(DHCPリレーエージェント) である。DHCP Relay Agent はサーバまたはルータ(L3スイッチ)上にBootp relay, IP helper, DHCP relay などの呼称で実装されている。「DHCPヘルパー」とも呼ばれる。

AgentがDHCPクライアントからのブロードキャスト(DHCP Request)を受信すると、宛先IPアドレスを設定されているDHCPサーバのアドレスに変換し、送信元を自己のLAN側(クライアントと同一サブネット)のIPアドレスに変換して転送する。また、リクエストデータ内に自己IPアドレスを書き込む。(ここで、注目したいのは、宛先IP/送信元IP/データを書き換えるという荒業をエレガントに行っていることである。)

DHCPサーバは、転送されたパケットを確認し、データ内に書き込まれたAgentのIPアドレスにより割り当てるべきネットワークのアドレスを決定する。また、データ内のクライアントのMACアドレスを読んで、リーステーブルを更新する。リースパケットは、パケットの送信元である、Agentに返信される。

リースパケットを受信したAgentは、宛先IPアドレスを0.0.0.0に変換し、リクエストクライアントのMACアドレスに向けたフレームにカプセリングして送出する。

リレーエージェントとDHCPサーバー間の通信では、通常、送信元と宛先のどちらもUDPポート67が使用される。

DHCP Relay Agentを利用する際の注意点として、以下の2点がある。

  • DHCPサーバとDHCP Relay Agentとは同一のサーバもしくはルータ内に同居することは出来ない。
  • 同一ブロードキャストドメイン内に複数のサブネットが存在する場合、DHCP Relay Agentを経由すると、DHCP Relay AgentのIPアドレスによってDHCPサーバがリースするIPアドレスの範囲が決定される。

信頼性 編集

DHCPは、定期的な更新、再バインド[7]:Section 4.4.5、フェイルオーバーなど、いくつかの方法で信頼性を保証する。DHCPクライアントには、一定期間リースが割り当てられている。リース期間の半分が経過すると、クライアントはリースの更新を試みる[7]:Section 4.4.5 Paragraph 3。元のリースを許可したDHCPサーバにユニキャストDHCPREQUESTメッセージを送信することで、これを行う。そのサーバが停止しているか、またはアクセスできない場合、DHCPREQUESTへの応答は届かない。その場合、クライアントはDHCPREQUESTを再送し[7]:Section 4.4.5 Paragraph 8[注釈 2]、DHCPサーバが復旧した場合、または再び到達可能になった場合は、応答が返るのでリースを更新することができる。

DHCPサーバに長期間到達できない場合[7]:Section 4.4.5 Paragraph 5、DHCPクライアントは、DHCPREQUESTをユニキャストではなくブロードキャストで送信し再バインドを試みる。ブロードキャストなので、DHCPREQUESTメッセージは全ての利用可能なDHCPサーバに届く。他のDHCPサーバがリースを更新できる場合は、この時点で更新される。

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

再バインドが失敗すると、リースは最終的に期限切れになる。リースが期限切れになると、クライアントはリースで付与されたIPアドレスの使用を停止する必要がある[7]:Section 4.4.5 Paragraph 9。そして、DHCPプロセスを最初から再開し、DHCPDISCOVERメッセージをブロードキャスト送信する。リース期限が切れているため、提示されたIPアドレスはすべて受け入れられる。新しいIPアドレスを(おそらく別のDHCPサーバから)取得すると、もう一度ネットワークを使用できるようになる。ただし、IPアドレスが変更されるため、進行中の接続は全て切断される。

セキュリティ 編集

基本のDHCPには、認証のメカニズムは含まれていない[18]。このため、様々な攻撃に対して脆弱である。DHCPを利用した攻撃は、主に以下の3つのカテゴリに分類される。

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

クライアントにはDHCPサーバの身元を検証する方法がないため、攻撃者が不正DHCP英語版サーバ(rogue DHCP)をネットワーク上に設置して、DHCPクライアントに誤った情報を提示する可能性がある[20]。これは、クライアントがネットワーク接続にアクセスするのを妨げるDoS攻撃[21]や、中間者攻撃に使うことができる[22]。DHCPサーバはDHCPクライアントにDNSサーバなどのサーバIPアドレスを提供するため[19]、攻撃者はDHCPクライアントに自分のDNSサーバを介してDNS問い合わせを実行させることができる[23][24]。これにより、攻撃者は自分自身を介してネットワークトラフィックをリダイレクトし、接続しているクライアントとネットワークサーバ間の接続を盗聴したり、単にそれらのネットワークサーバを自分のネットワークサーバに置き換えることができる[23]

DHCPサーバにはクライアントを認証するための安全なメカニズムがないため、クライアント識別子など、他のDHCPクライアントに属する資格情報を提示することで、攻撃者のクライアントはIPアドレスを不正に取得することができる[20]。これにより、DHCPクライアントがDHCPサーバのIPアドレスのプールを全て使い果たすことも可能になる。アドレスを尋ねる度に新しい資格を提示することにより、クライアントは特定のネットワークリンク上の全ての利用可能なIPアドレスを消費できる[20]

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

別の拡張、DHCPメッセージ認証( RFC 3118 )では、DHCPメッセージを認証するためのメカニズムを提供する。2002年の時点では、多数のDHCPクライアントの鍵を管理するという問題があるため、RFC 3118では広く採用されていなかった。DSL技術に関する2007年の本には、次のように書かれている。

RFC 3118で提案されたセキュリティ対策に対して特定された多数のセキュリティ脆弱性があった。この事実は、802.1xの導入と相まって、DHCP認証の導入と普及率を低下させ、広く普及したことは一度もない[27]

2010年の本では次のように書かれている。

DHCP認証の実装はこれまでほとんどなかった。ハッシュ計算による鍵管理と処理遅延の課題は、認識されている利点の代価を払うには高すぎる代償と見なされてきた[28]

2008年からの提案には、802.1xPANA英語版(どちらもEAPを転送する)を使用することでDHCP要求を認証するものがある[29]。DHCP自体にEAPを含める、いわゆるEAPoDHCPについてIETFの提案がなされた[30]が、これはIETFドラフトよりも先に進行した形跡はなく、最後の議論は2010年で止まっている[31]

実装 編集

サーバの実装 編集

DHCPサーバが実装されている環境としては、大きく分けて以下の三種類がある。

UNIX系環境 編集

もっとも初期の頃から存在しているサーバ実装であり、ISC版とWIDE版の2種類がよく知られているが、WIDE版DHCPサーバは現在開発が終了している。

Windows系環境 編集

Windows NT 4 Server以降、MicrosoftはサーバOSに標準でDHCPサーバを添付しており、現行のWindows Server 2008 R2でも標準でDHCPサーバが付属している。

Windows 2000 Server以降のDHCPサーバでは、Active Directory環境においてはインストール後にドメイン管理者の「承認」を行わないと起動できないという特徴を持つ(非Active Directory環境下ではこの制限はない)。

このほかに、第三者が開発した Windows 95/98系環境で動作する(Windows 2000等でも動作する)フリーソフトのDHCPサーバも存在する。

ルータ内実装 編集

2000年頃から増加してきた形態で、ルータ内部にDHCPサーバ機能を組み込んだものである。特に、家庭向けのルータ(いわゆる「ブロードバンドルータ」)では必ずといってよいほど実装されており、現在家庭内で利用されているDHCPサーバでもっとも一般的なものと思われる。

クライアントの実装 編集

Windows 9xWindows NT 4.xMac OSなどでDHCPのクライアントモジュールが標準添付されるようになり、広く利用されるようになった。

初期のMac OS 9においては、DHCPの仕様の解釈の違いから、うまく通信できない場合があり、フリーズしたかのような症状になるという問題が発生した。この問題は、のちにバージョンアップで解決された。

関連するIETF標準 編集

  • RFC 2131, Dynamic Host Configuration Protocol
  • RFC 2132, DHCP Options and BOOTP Vendor Extensions
  • RFC 3046, DHCP Relay Agent Information Option
  • RFC 3397, Dynamic Host Configuration Protocol (DHCP) Domain Search Option
  • RFC 3942, Reclassifying Dynamic Host Configuration Protocol Version Four (DHCPv4) Options
  • RFC 4242, Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6
  • RFC 4361, Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
  • RFC 4436, Detecting Network Attachment in IPv4 (DNAv4)
  • RFC 3442, Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4

関連項目 編集

脚注 編集

注釈 編集

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

出典 編集

  1. ^ a b TechTarget Network: DHCP (Dynamic Host Configuration Protocol)
  2. ^ Peterson LL, Davie BS. (2011). Computer Networks: A Systems Approach.
  3. ^ Ralph Droms; Ted Lemon (2003). The DHCP Handbook. SAMS Publishing. p. 436. ISBN 978-0-672-32327-0 
  4. ^ Droms, Ralph. “Dynamic Host Configuration Protocol”. tools.ietf.org. 2017年7月4日閲覧。
  5. ^ Droms, Ralph. “Dynamic Host Configuration Protocol”. tools.ietf.org. 2015年12月26日閲覧。
  6. ^ Droms, Ralph. “Dynamic Host Configuration Protocol”. tools.ietf.org. 2017年7月4日閲覧。
  7. ^ a b c d e f Droms, Ralph (1997年3月). DHCP Options and BOOTP Vendor Extensions (英語). IETF. doi:10.17487/RFC2131. RFC 2131. 2014年9月9日閲覧
  8. ^ RFC2131 Dynamic Host Configuration Protocol: Dynamic allocation of network addresses https://datatracker.ietf.org/doc/html/rfc2131#section-2.2
  9. ^ a b Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters”. iana.org. 2018年10月16日閲覧。
  10. ^ a b c d e f g h i j k Alexander, Steve; Droms, Ralph (1997年3月). DHCP options and BOOTP vendor extensions (英語). IETF. doi:10.17487/RFC2132. RFC 2132. 2012年6月10日閲覧
  11. ^ a b Patrick, Michael (January 2001) (英語). DHCP Relay Agent Information Option. IETF. doi:10.17487/RFC3046. https://datatracker.ietf.org/doc/html/rfc3046 2017年7月22日閲覧。. 
  12. ^ a b c Provan, Don (November 1997) (英語). RFC [https://datatracker.ietf.org/doc/html/rfc2241 2241 – DHCP Options for Novell Directory Services]. IETF. doi:10.17487/RFC3256. https://datatracker.ietf.org/doc/html/rfc2241 2017年7月23日閲覧。. 
  13. ^ a b Timezone Options for DHCP” (英語). IETF Documents. IETF (2007年4月). 2018年6月28日閲覧。
  14. ^ Bernard, Aboba; Stuart, Cheshire (November 2002) (英語). RFC [https://datatracker.ietf.org/doc/html/rfc3397 3397 – Dynamic Host Configuration Protocol (DHCP) Domain Search Option]. IETF. doi:10.17487/RFC3397. https://datatracker.ietf.org/doc/html/rfc3397 2017年7月22日閲覧。. 
  15. ^ RFC [https://datatracker.ietf.org/doc/html/rfc3442 3442]
  16. ^ Doug, Jones; Rich, Woundy (April 2002) (英語). RFC [https://datatracker.ietf.org/doc/html/rfc3256 3256 – The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option]. IETF. doi:10.17487/RFC3256. https://datatracker.ietf.org/doc/html/rfc3256 2017年7月23日閲覧。. 
  17. ^ Droms, Ralph; Kinnear, Kim; Stapp, Mark; Volz, Bernie; Gonczi, Steve; Rabil, Greg; Dooley, Michael; Kapur, Arun (2003年3月). DHCP Failover Protocol (英語). IETF. I-D draft-ietf-dhc-failover-12. 2020年5月9日閲覧
  18. ^ a b Michael Patrick (2001年1月). “RFC 3046 - DHCP Relay Agent Information Option”. Network Working Group. 2019年2月22日閲覧。
  19. ^ a b c d Ralph Droms (1997年3月). “RFC 2131 - Dynamic Host Configuration Protocol”. Network Working Group. 2019年2月22日閲覧。
  20. ^ a b c Timothy Stapko (2011). Practical Embedded Security: Building Secure Resource-Constrained Systems. Newnes. p. 39. ISBN 978-0-08-055131-9. https://books.google.com/books?id=Mly55VntuYMC&pg=PA39 
  21. ^ Derrick Rountree (2013). Windows 2012 Server Network Security: Securing Your Windows Network Systems and Infrastructure. Newnes. p. 22. ISBN 978-1-59749-965-1. https://books.google.com/books?id=NFzou_d4MGUC&pg=SA2-PA13 
  22. ^ Timothy Rooney (2010). Introduction to IP Address Management. John Wiley & Sons. p. 180. ISBN 978-1-118-07380-3. https://books.google.com/books?id=QgRDxkuI1MkC&pg=PA180 
  23. ^ a b Sergey Golovanov (Kaspersky Labs) (2011年6月). “TDSS loader now got "legs"”. 2019年2月22日閲覧。
  24. ^ Akash K Sunny (2015年10月). “dhcp protocol and its vulnerabilities”. 2019年2月22日閲覧。
  25. ^ Francisco J. Hens; José M. Caballero (2008). Triple Play: Building the converged network for IP, VoIP and IPTV. John Wiley & Sons. p. 239. ISBN 978-0-470-75439-9. https://books.google.com/books?id=aS1ZngveBIkC&pg=PA239 
  26. ^ David H. Ramirez (2008). IPTV Security: Protecting High-Value Digital Contents. John Wiley & Sons. p. 55. ISBN 978-0-470-72719-5. https://books.google.com/books?id=70tr_hSDULwC&pg=PA55 
  27. ^ Philip Golden; Hervé Dedieu; Krista S. Jacobsen (2007). Implementation and Applications of DSL Technology. Taylor & Francis. p. 484. ISBN 978-1-4200-1307-8. https://books.google.com/books?id=Jjkd74jY47oC&pg=PA484 
  28. ^ Timothy Rooney (2010). Introduction to IP Address Management. John Wiley & Sons. pp. 181–182. ISBN 978-1-118-07380-3. https://books.google.com/books?id=QgRDxkuI1MkC&pg=PA181 
  29. ^ Rebecca Copeland (2008). Converging NGN Wireline and Mobile 3G Networks with IMS. Taylor & Francis. pp. 142–143. ISBN 978-1-4200-1378-8. https://books.google.com/books?id=ruWv8RGkBGgC&pg=PA142 
  30. ^ Ramjee Prasad; Albena Mihovska (2009). New Horizons in Mobile and Wireless Communications: Networks, services, and applications. 2. Artech House. p. 339. ISBN 978-1-60783-970-5. https://books.google.com/books?id=w9bEwBwd33MC&pg=PA339 
  31. ^ Archived copy”. 2015年4月3日時点のオリジナルよりアーカイブ。2013年12月12日閲覧。