Dynamic Host Configuration Protocol
UDP/IPネットワークで使用されるネットワーク管理プロトコル
Dynamic Host Configuration Protocol（ダイナミック ホスト コンフィギュレーション プロトコル、DHCP）は、IPv4ネットワークで使用されるネットワーク管理プロトコルであり、コンピュータがネットワークに接続する際に必要な設定情報を自動的に割り当てるために使用する。 BOOTPにリース機能を追加してDHCPとなっている。
| 通信プロトコル | |
| 目的 | コンピュータがネットワークに接続する際に必要な設定情報の自動的な割り当て |
|---|---|
| 導入 | 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は、IPv4とIPv6のどちらでも使用される。どちらのバージョンでも目的は同じであるが、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は、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アドレスに設定される。その他のいくつかのオプションも設定されている。
|
イーサネット: 送信元=送信者のMACアドレス; 送信先=FF:FF:FF:FF:FF:FF | |||
|
IP: 送信元=0.0.0.0; 送信先=255.255.255.255 | |||
| 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 （パラメータ要求リスト）:
| |||
| 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アドレスを指定する。
|
イーサネット: 送信元=送信者のMACアドレス; 送信先=クライアントのMACアドレス | ||||
|
IP: 送信元=192.168.1.1; 送信先=255.255.255.255 | ||||
| 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サーバ）:
| ||||
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アドレスを利用可能なアドレスのプールに返却する。
|
イーサネット: 送信元=送信者のMACアドレス; 送信先=FF:FF:FF:FF:FF:FF | ||||
|
IP: 送信元=0.0.0.0; 送信先=255.255.255.255[注釈 1] | ||||
| 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]。
|
イーサネット: 送信元=送信者のMACアドレス; 送信先=クライアントのMACアドレス | |||
|
IP: 送信元=192.168.1.1; 送信先=192.168.1.100 | |||
| 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サーバ）:
| |||
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オプション
編集DHCPオプションは、元々BOOTPにてvendor extensions（ベンダー拡張）として提供されていた機能であり、BOOTPをサポートしていたネットワーク機器メーカがBOOTPサーバからBOOTPクライアントとなる各機器へ設定を送信するために使用していた。DHCPではこの機能をDHCPオプションとして標準化している。一方、従来からのベンダー拡張機能は専用のオプションコードにより引き続き利用できるようにしている。
DHCPオプションはTLV形式のオクテット文字列として表現される。最初のオクテットはオプションコード、2番目のオクテットは後続オクテットの数で、残りのオクテットはオプションコードに依存する。例えば、offerのDHCPメッセージタイプオプションは0x35、0x01、0x02と表示される。ここで、0x35はDHCPメッセージタイプ(DHCP message type)のコード53で、0x01は後ろに1オクテットが続くことを表し、0x02は"offer"を表す値である。
RFC 2132 で定義
編集次の表は、 RFC 2132 [10]およびIANAレジストリ[9]で定義されている利用可能なDHCPオプションを一覧にしたものである。
| コード | 名称 | 長さ | 備考 |
|---|---|---|---|
| 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オクテット | ベンダーオプションフィールドの終端を示すために使用される |
| コード | 名称 | 長さ | 備考 |
|---|---|---|---|
| 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オクテットの倍数 |
| コード | 名称 | 長さ | 備考 |
|---|---|---|---|
| 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オクテットの倍数 | 送信先・ルータのペアのリスト |
| コード | 名称 | 長さ | 備考 |
|---|---|---|---|
| 34 | Trailer encapsulation option | 1オクテット | |
| 35 | ARP cache timeout | 4オクテット | |
| 36 | Ethernet encapsulation | 1オクテット |
| コード | 名称 | 長さ | 備考 |
|---|---|---|---|
| 37 | TCP default TTL | 1オクテット | |
| 38 | TCP keepalive interval | 4オクテット | |
| 39 | TCP keepalive garbage | 1オクテット |
| コード | 名称 | 長さ | 備考 |
|---|---|---|---|
| 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オクテットの倍数 |
| コード | 名称 | 長さ | 備考 |
|---|---|---|---|
| 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サーバに与える。特に、vendor-specific information（オプション43）を用いた運用にあっては本オプションを用いたベンダ識別が事実上必須となる。
RFC 2132以外で定義
編集| コード | 名称 | 長さ | 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要求にサブオプションを付加するためのコンテナを指定する。
| コード | 名称 | 長さ | RFC |
|---|---|---|---|
| 4 | Data-Over-Cable Service Interface Specifications (DOCSIS) device class | 4オクテット | RFC 3256[16] |
ベンダー固有DHCPオプションおよび例
編集Vendor-specific informationオプション（オプション43）[10]:Section 8.4は、各ネットワーク機器ベンダが自由に設定できるDHCPオプションである。書式はマジッククッキーを除いたDHCPオプションに同じ。0および255以外のオプションコードはベンダにて再定義が可能。
以下は実際の実装例。
| コード（ベンダ再定義） | 名称 | 長さ | 意味 |
|---|---|---|---|
| 241 | Wireless LAN controller IP addresses | 4オクテットの倍数 | アクセスポイントが接続すべき無線LANコントローラのIPアドレス |
DHCPリレー
編集
DHCPはDHCPサーバの検索にブロードキャストを使用する関係上、通常はクライアントとサーバが同一ブロードキャスト・ドメイン上にないと正常に動作しない。しかしながら、企業や大学など比較的大規模なネットワークでは、サーバを1カ所に集中させたい等の理由でDHCPクライアントとサーバとが全く異なるネットワーク上に設置されることがある。
このような場合に使用されるのがDHCP Relay Agent︵DHCPリレーエージェント︶ である。DHCP Relay Agent はサーバまたはルータ︵L3スイッチ︶上にBootp relay, IP helper, DHCP relay などの呼称で実装されている。﹁DHCPヘルパー﹂とも呼ばれる。Bootp relayの名称が示すように元々はBOOTP向けの機能であり[18]、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を利用する際の注意点として、以下がある。
- DHCPサーバとDHCP Relay Agentとは同一のサーバもしくはルータ内に同居することは出来ない。
- 同一ブロードキャストドメイン内に複数のサブネットが存在する場合、DHCP Relay Agentを経由すると、DHCP Relay AgentのIPアドレスによってDHCPサーバがリースするIPアドレスの範囲が決定される。
- DHCPサーバとクライアント間のユニキャストによるDHCPパケットの疎通は、DHCP Relay Agentを使用する場合でも必要となる。IPアドレスのリースを更新するためにDHCP requestをクライアントからサーバへ送信する際、宛先がDHCP Relay Agentの有無にかかわらずDHCPサーバになることに依る。
- DHCP Relay Agentが処理してもよいパケットは、マルチキャスト、ブロードキャストおよびDHCP Relay Agentが動作しているホスト宛のユニキャストに限られる。特に、実際のDHCPサーバ宛にユニキャストにより送信されたパケットはDHCP Relay Agentの処理対象にならないことに注意する。
信頼性
編集
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に提出されたが、まだ正式化はされていない[19][注釈3]。
再バインドが失敗すると、リースは最終的に期限切れになる。リースが期限切れになると、クライアントはリースで付与されたIPアドレスの使用を停止する必要がある[7]:Section 4.4.5 Paragraph 9。そして、DHCPプロセスを最初から再開し、DHCPDISCOVERメッセージをブロードキャスト送信する。リース期限が切れているため、提示されたIPアドレスはすべて受け入れられる。新しいIPアドレスを︵おそらく別のDHCPサーバから︶取得すると、もう一度ネットワークを使用できるようになる。ただし、IPアドレスが変更されるため、進行中の接続は全て切断される。
セキュリティ
編集「DHCPスヌーピング」も参照
基本のDHCPには、認証のメカニズムは含まれていない[20]。このため、様々な攻撃に対して脆弱である。DHCPを利用した攻撃は、主に以下の3つのカテゴリに分類される。
●不正なDHCPサーバがクライアントに誤った情報を提示する[21]。
●無許可のクライアントがリソースにアクセスする[21]。
●悪意のあるDHCPクライアントからのリソース枯渇攻撃[21]。
クライアントにはDHCPサーバの身元を検証する方法がないため、攻撃者が不正DHCPサーバ(rogue DHCP)をネットワーク上に設置して、DHCPクライアントに誤った情報を提示する可能性がある[22]。これは、クライアントがネットワーク接続にアクセスするのを妨げるDoS攻撃[23]や、中間者攻撃に使うことができる[24]。DHCPサーバはDHCPクライアントにDNSサーバなどのサーバIPアドレスを提供するため[21]、攻撃者はDHCPクライアントに自分のDNSサーバを介してDNS問い合わせを実行させることができる[25][26]。これにより、攻撃者は自分自身を介してネットワークトラフィックをリダイレクトし、接続しているクライアントとネットワークサーバ間の接続を盗聴したり、単にそれらのネットワークサーバを自分のネットワークサーバに置き換えることができる[25]。
DHCPサーバにはクライアントを認証するための安全なメカニズムがないため、クライアント識別子など、他のDHCPクライアントに属する資格情報を提示することで、攻撃者のクライアントはIPアドレスを不正に取得することができる[22]。これにより、DHCPクライアントがDHCPサーバのIPアドレスのプールを全て使い果たすことも可能になる。アドレスを尋ねる度に新しい資格を提示することにより、クライアントは特定のネットワークリンク上の全ての利用可能なIPアドレスを消費できる[22]。
DHCPでは、これらの問題を軽減するためのメカニズムをいくつか提供している。リレーエージェント情報オプションプロトコル拡張︵ RFC 3046 、通常は実際のオプション番号から"Option 82"と呼ばれる[27][28]︶は、これらのメッセージがネットワーク事業者の信頼できるネットワークに届くときにDHCPメッセージにタグを付けることをネットワーク事業者に許可する。このタグは、クライアントのネットワークリソースへのアクセスを制御するための認証トークンとして使用される。クライアントはリレーエージェントの上流にあるネットワークにアクセスできないため、認証がなくてもDHCPサーバオペレータが認可トークンに依存することを妨げることはない[20]。
別の拡張、DHCPメッセージ認証︵ RFC 3118 ︶では、DHCPメッセージを認証するためのメカニズムを提供する。2002年の時点では、多数のDHCPクライアントの鍵を管理するという問題があるため、RFC 3118では広く採用されていなかった。DSL技術に関する2007年の本には、次のように書かれている。
RFC 3118で提案されたセキュリティ対策に対して特定された多数のセキュリティ脆弱性があった。この事実は、802.1xの導入と相まって、DHCP認証の導入と普及率を低下させ、広く普及したことは一度もない[29]。
2010年の本では次のように書かれている。
DHCP認証の実装はこれまでほとんどなかった。ハッシュ計算による鍵管理と処理遅延の課題は、認識されている利点の代価を払うには高すぎる代償と見なされてきた[30]。
2008年からの提案には、802.1xやPANA︵どちらもEAPを転送する︶を使用することでDHCP要求を認証するものがある[31]。DHCP自体にEAPを含める、いわゆるEAPoDHCPについてIETFの提案がなされた[32]が、これはIETFドラフトよりも先に進行した形跡はなく、最後の議論は2010年で止まっている[33]。
実装
編集サーバの実装
編集DHCPサーバが実装されている環境としては、大きく分けて以下の三種類がある。
UNIX系環境
編集
もっとも初期の頃から存在しているサーバ実装を含む。ISC DHCP[34]、Kea[35]、WIDE版の3種類がよく知られている。
ISC DHCPは元来ISCがDHCPのリファレンス実装として開発していたもので、サーバだけでなくクライアントやリレーエージェントも同梱している。2022年末をもって、既存の有償サポート契約分を除いて全てのバージョンがEOLとなった。
KeaはISC DHCPからサーバ機能のみを抽出した後継ソフトウェアであり、ISCが引き続き開発している。C++での再実装やデータベースバックエンド、Stork︵管理用GUI︶のサポート等の機能が追加されている。
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 9x・Windows NT 4.x・Mac OSなどでDHCPのクライアントモジュールが標準添付されるようになり、広く利用されるようになった。
初期のMac OS 9においては、DHCPの仕様の解釈の違いから、うまく通信できない場合があり、フリーズしたかのような症状になるという問題が発生した。この問題は、のちにバージョンアップで解決された。
ジョークとしての実装
編集1997年、オランダでのハッキングイベントにて洗濯ばさみを用いたDHCPが実施された。翌年、RFC 2322 [36]として規格が発表された。
関連する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
関連項目
編集
- UPnP
- Boot Service Discovery Protocol (BSDP) – AppleのNetBootで使用されるDHCPの拡張
- DHCPサーバソフトウェアの比較
- Peg DHCP (RFC 2322)
- Preboot Execution Environment (PXE)
- Reverse Address Resolution Protocol (RARP)
- 不正DHCP
- UDPヘルパーアドレス – DHCPリクエストをサブネット境界を超えてルーティングするためのルータの設定
- Zeroconf – Zero Configuration Networking
脚注
編集注釈
編集- ^ a b クライアントのオプションの動作として、DHCPクライアントが既にDHCPサーバのIPアドレスを知っている場合は、DHCP deliverおよびrequestメッセージなど、一部のメッセージをブロードキャストではなくユニキャストで送信することができる[6]。
- ^ RFCでは、クライアントがDHCPREQUESTパケットを再送信する前に、T2までの残り時間の半分待機するように規定している。
- ^ この提案では、1台のサーバが完全に故障した場合でも、2台のサーバがリースデータベースを回復して動作を継続できるように、2台のサーバが互いにゆるやかに同期し続けることができるメカニズムを提供している。仕様が長くて複雑だったため、規格としては発表されなかった。ただし、この仕様で説明されている技法は広く使用されており、ISC DHCPサーバでのオープンソース実装や、いくつかの商用の実装もある。
出典
編集
(一)^ abTechTarget Network: DHCP (Dynamic Host Configuration Protocol)
(二)^ Peterson LL, Davie BS. (2011). Computer Networks: A Systems Approach.
(三)^ Ralph Droms; Ted Lemon (2003). The DHCP Handbook. SAMS Publishing. p. 436. ISBN 978-0-672-32327-0
(四)^ Droms, Ralph. “Dynamic Host Configuration Protocol”. tools.ietf.org. 2017年7月4日閲覧。
(五)^ Droms, Ralph. “Dynamic Host Configuration Protocol”. tools.ietf.org. 2015年12月26日閲覧。
(六)^ Droms, Ralph. “Dynamic Host Configuration Protocol”. tools.ietf.org. 2017年7月4日閲覧。
(七)^ abcdefDroms, Ralph (1997年3月). DHCP Options and BOOTP Vendor Extensions (英語). IETF. doi:10.17487/RFC2131. RFC 2131. 2014年9月9日閲覧。
(八)^ RFC2131 Dynamic Host Configuration Protocol: Dynamic allocation of network addresses https://datatracker.ietf.org/doc/html/rfc2131#section-2.2
(九)^ ab“Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters”. iana.org. 2018年10月16日閲覧。
(十)^ abcdefghijklAlexander, Steve; Droms, Ralph (1997年3月). DHCP options and BOOTP vendor extensions (英語). IETF. doi:10.17487/RFC2132. RFC 2132. 2012年6月10日閲覧。
(11)^ abPatrick, Michael (January 2001) (英語). DHCP Relay Agent Information Option. IETF. doi:10.17487/RFC3046 2017年7月22日閲覧。.
(12)^ abcProvan, Don (November 1997) (英語). RFC [https://datatracker.ietf.org/doc/html/rfc2241 2241 – DHCP Options for Novell Directory Services]. IETF. doi:10.17487/RFC3256 2017年7月23日閲覧。.
(13)^ ab“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 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 2017年7月23日閲覧。.
(17)^ Cisco TAC (2022年11月3日). “Lightweight アクセスポイントの DHCP オプション43の設定”. Cisco. 2024年5月9日閲覧。
(18)^ Wimer, Walt (October 1993) (英語). RFC [https://datatracker.ietf.org/doc/html/rfc1542 1542 – Clarifications and Extensions for the Bootstrap Protocol, 4. BOOTP Relay Agents]. IETF. doi:10.17487/RFC1542 2024年5月7日閲覧。.
(19)^ 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日閲覧。
(20)^ abMichael Patrick (2001年1月). “RFC 3046 - DHCP Relay Agent Information Option”. Network Working Group. 2019年2月22日閲覧。
(21)^ abcdRalph Droms (1997年3月). “RFC 2131 - Dynamic Host Configuration Protocol”. Network Working Group. 2019年2月22日閲覧。
(22)^ abcTimothy Stapko (2011). Practical Embedded Security: Building Secure Resource-Constrained Systems. Newnes. p. 39. ISBN 978-0-08-055131-9
(23)^ Derrick Rountree (2013). Windows 2012 Server Network Security: Securing Your Windows Network Systems and Infrastructure. Newnes. p. 22. ISBN 978-1-59749-965-1
(24)^ Timothy Rooney (2010). Introduction to IP Address Management. John Wiley & Sons. p. 180. ISBN 978-1-118-07380-3
(25)^ abSergey Golovanov (Kaspersky Labs) (2011年6月). “TDSS loader now got "legs"”. 2019年2月22日閲覧。
(26)^ Akash K Sunny (2015年10月). “dhcp protocol and its vulnerabilities”. 2019年2月22日閲覧。
(27)^ 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
(28)^ David H. Ramirez (2008). IPTV Security: Protecting High-Value Digital Contents. John Wiley & Sons. p. 55. ISBN 978-0-470-72719-5
(29)^ Philip Golden; Hervé Dedieu; Krista S. Jacobsen (2007). Implementation and Applications of DSL Technology. Taylor & Francis. p. 484. ISBN 978-1-4200-1307-8
(30)^ Timothy Rooney (2010). Introduction to IP Address Management. John Wiley & Sons. pp. 181–182. ISBN 978-1-118-07380-3
(31)^ Rebecca Copeland (2008). Converging NGN Wireline and Mobile 3G Networks with IMS. Taylor & Francis. pp. 142–143. ISBN 978-1-4200-1378-8
(32)^ 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
(33)^ “Archived copy”. 2015年4月3日時点のオリジナルよりアーカイブ。2013年12月12日閲覧。
(34)^ “ISC DHCP”. ISC. 2024年5月9日閲覧。
(35)^ “Kea DHCP”. ISC. 2024年5月9日閲覧。
(36)^ “Management of IP numbers by peg-dhcp”. Network Working Group (1998年4月1日). 2024年5月9日閲覧。