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

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

DHCPは、ホームネットワークから大規模なキャンパスネットワーク、地域のインターネットサービスプロバイダネットワークまで、様々な規模のネットワークに実装できる。ほとんどのルータまたはホームゲートウェイは、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のプロトコルの詳細は大きく異なることから別のプロトコルと見なされる。IPv6のDHCPはDHCPv6と呼ばれ、 RFC 8415 で定められている。DHCPv6はDHCPv4とは互換性がないが、IPv6だけでなくIPv4のアドレスを割り当てることもできる。IPv6では、IPアドレスとネットマスクの情報をIPv6自体のアドレス自動設定機能により取得することもできるが、DNSサーバやNTPサーバなどほかの情報も自動取得するためにはDHCPが必要になる。

## 割り当ての種類

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

いずれの方法でも、通常配信された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であればユニキャストである。通常、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メッセージでブロードキャストで送信し、提示されたアドレスを要求する。クライアントは複数のサーバからDHCP offerを受信しても、1つのDHCP offerしか受け入れない。DHCP requestメッセージで要求されたserver identificationオプションによって、サーバは、DHCP offerがクライアントにより受け入れられたことを知る。このメッセージを受け取った他のDHCPサーバは、クライアントに送信したDHCP offerを取り消し、IPアドレスを利用可能なアドレスのプールに返却する。

DHCPREQUESTメッセージの例

|  |  |  |  |
| --- | --- | --- | --- |
| イーサネット: 送信元=送信者の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) | | | |
| 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)などを使って)新しく設定したアドレスが他のコンピュータで使われていないかを調べるべきである。

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のパラメータ)が記載されている。

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 およびIANAレジストリで定義されている利用可能なDHCPオプションを一覧にしたものである。

RFC 1497 (BOOTP Vendor Information Extensions) ベンダ拡張

| コード | 名称 | 長さ | 備考 |
| --- | --- | --- | --- |
| 0 | Pad | 0 オクテット | 他のオプションがバイト境界に揃うようにパディングするために使用する。長さバイトの後には何も続かない。 |
| 1 | Subnet mask | 4オクテット | ルータオプション(オプション3)がある場合は、その前に送信する必要がある。 |
| 2 | Time offset | 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層パラメータ

| コード | 名称 | 長さ | 備考 |
| --- | --- | --- | --- |
| 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層パラメータ

| コード | 名称 | 長さ | 備考 |
| --- | --- | --- | --- |
| 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オクテット |  |

TCPパラメータ

| コード | 名称 | 長さ | 備考 |
| --- | --- | --- | --- |
| 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オクテットの倍数 |  |

DHCP拡張

| コード | 名称 | 長さ | 備考 |
| --- | --- | --- | --- |
| 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以外で定義

定義されたDHCPオプション

| コード | 名称 | 長さ | RFC |
| --- | --- | --- | --- |
| 82 | Relay agent information | 2オクテット以上 | RFC 3046 |
| 85 | Novell Directory Service (NDS) servers | 4オクテット以上で、4オクテットの倍数 | RFC 2241 |
| 86 | NDS tree name | 可変 | RFC 2241 |
| 87 | NDS context | 可変 | RFC 2241 |
| 100 | Time zone, POSIX style | 可変 | RFC 4833 |
| 101 | Time zone, tz database style | 可変 | RFC 4833 |
| 119 | Domain search | 可変 | RFC 3397 |
| 121 | Classless static route | 可変 | RFC 3442 |

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

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

Relay agent sub-options

| コード | 名称 | 長さ | RFC |
| --- | --- | --- | --- |
| 4 | Data-Over-Cable Service Interface Specifications (DOCSIS) device class | 4オクテット | RFC 3256 |

#### ベンダー固有DHCPオプションおよび例

Vendor-specific informationオプション(オプション43)は、各ネットワーク機器ベンダが自由に設定できるDHCPオプションである。書式はマジッククッキーを除いたDHCPオプションに同じ。0および255以外のオプションコードはベンダにて再定義が可能。

以下は実際の実装例。

Cisco Lightweight Aironet Access Point (VCI: "Cisco AP ...")

| コード(ベンダ再定義) | 名称 | 長さ | 意味 |
| --- | --- | --- | --- |
| 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向けの機能であり、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は、定期的な更新、再バインド、フェイルオーバーなど、いくつかの方法で信頼性を保証する。DHCPクライアントには、一定期間リースが割り当てられている。リース期間の半分が経過すると、クライアントはリースの更新を試みる。元のリースを許可したDHCPサーバにユニキャストDHCPREQUESTメッセージを送信することで、これを行う。そのサーバが停止しているか、またはアクセスできない場合、DHCPREQUESTへの応答は届かない。その場合、クライアントはDHCPREQUESTを再送し、DHCPサーバが復旧した場合、または再び到達可能になった場合は、応答が返るのでリースを更新することができる。

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

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

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

## セキュリティ

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

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

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

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

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

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

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

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

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

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

## 実装

### サーバの実装

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

- UNIX系環境
- Windows系環境
- ルータ内実装

#### UNIX系環境

もっとも初期の頃から存在しているサーバ実装を含む。ISC DHCP、Kea、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 として規格が発表された。

## 関連する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