Dynamic Host Configuration Protocol

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

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

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アドレスを指定する。

クライアントは、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アドレスを利用可能なアドレスのプールに返却する。

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

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

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

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

クライアントは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オプションは、元々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 ^[10]およびIANAレジストリ^[9]で定義されている利用可能なDHCPオプションを一覧にしたものである。

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

この方法により、DHCPサーバーは2種類のクライアントマシンを区別し、2種類のモデムからの要求を適切に処理できる。一部のタイプのセットトップボックスでは、デバイスのハードウェアタイプと機能についてDHCPサーバーに通知するようにVCI（オプション60）も設定されている。このオプションが設定されている値は、このクライアントがDHCP応答で必要とする必要な追加情報についてのヒントをDHCPサーバに与える。特に、vendor-specific information（オプション43）を用いた運用にあっては本オプションを用いたベンダ識別が事実上必須となる。

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

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

以下は実際の実装例。

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には、認証のメカニズムは含まれていない^[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系環境
• Windows系環境
• ルータ内実装

もっとも初期の頃から存在しているサーバ実装を含む。ISC DHCP^[34]、Kea^[35]、WIDE版の3種類がよく知られている。

ISC DHCPは元来ISCがDHCPのリファレンス実装として開発していたもので、サーバだけでなくクライアントやリレーエージェントも同梱している。2022年末をもって、既存の有償サポート契約分を除いて全てのバージョンがEOLとなった。

KeaはISC DHCPからサーバ機能のみを抽出した後継ソフトウェアであり、ISCが引き続き開発している。C++での再実装やデータベースバックエンド、Stork（管理用GUI）のサポート等の機能が追加されている。

WIDE版DHCPサーバは現在^[いつ?]開発が終了している。

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]として規格が発表された。

• 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