https://tools.ietf.org/html/rfc2131
動態主機配置協議
本備忘錄的狀態
本文檔爲以下內容指定了Internet標準跟蹤協議：互聯網社區，並要求討論和提出建議改進。請參考最新版的“互聯網標準化狀態的官方協議標準”（STD1）協議的狀態。該備忘錄的分發是無限的。
摘要
動態主機配置協議（DHCP）提供了一個框架,用於將配置信息傳遞到TCPIP網絡上的主機。DHCP基於引導協議（BOOTP），添加了自動分配可重用網絡地址的功能以及其他配置選項。DHCP捕獲行爲BOOTP中繼代理，和DHCP參與者可以互操作與BOOTP參與者。
1.簡介
動態主機配置協議（DHCP）向Internet主機提供配置參數。DHCP由兩個部分組成：一種用於將特定主機的配置參數從DHCP服務器傳送到主機的協議，以及一種將網絡地址分配給主機的機制。
dhcp建立在客戶機-服務器模型上，在該模型中，指定的dhcp服務器主機分配網絡地址並將配置參數傳遞給動態配置的主機。在本文檔的其餘部分中，“服務器”一詞是指通過dhcp提供初始化參數的主機，“客戶端”一詞是指從dhcp服務器請求初始化參數的主機。
除非由系統管理員明確配置，否則主機不應充當DHCP服務器。如果允許隨機主機響應dhcp請求，將妨礙本網絡中不同的硬件和協議實現可靠的操作。例如，IP需要在協議實現（工具）軟件中設置許多參數。因爲IP可以在許多不同類型的網絡硬件上使用，所以不能猜測或假設這些參數的值具有正確的默認值。此外，已分配地址分配方案依賴於輪詢/防禦機制來發現已使用的地址。IP主機並不總能保護其網絡地址，因此像這一個已分配地址，發佈機無法保證避免分配重複的網絡地址。
DHCP支持三種IP地址分配機制：在“自動分配”中，dhcp爲客戶端分配一個永久ip地址；在“動態分配”中，dhcp在一段有限的時間內爲客戶端分配一個ip地址（或直到客戶端明確放棄地址）；在“手動分配”中，客戶端的IP地址由網絡管理員分配，而DHCP僅用於將分配的地址傳遞給客戶端。根據網絡管理員的策略，特定網絡將使用這些機制中的一個或多個。
動態分配是三種機制中唯一允許自動重用被分配地址的客戶端不再需要的地址的機制。因此，動態分配對於將地址分配給僅暫時連接到網絡的客戶機或對於在不需要永久ip地址的客戶機組之間共享有限的ip地址池特別有用。動態分配也可以是將ip地址分配給永久連接到ip地址足夠稀少的網絡的新客戶機的好選擇，當舊客戶機退役時，回收它們非常重要。手動分配允許使用dhcp來消除在需要在dhcp機制之外管理ip地址分配的環境中（無論出於何種原因）使用ip地址手動配置主機的易出錯過程。
動態分配是三種機制中唯一允許自動重用被分配地址的客戶端不再需要的地址的機制。因此，動態分配對於將地址分配給僅暫時連接到網絡的客戶機或對於在不需要永久ip地址的客戶機組之間共享有限的ip地址池特別有用。動態分配也可以是將ip地址分配給永久連接到ip地址少量的網絡的新客戶機的好選擇，當舊客戶機退出網絡時，回收它們非常重要。在管理ip地址分配的環境中（無論出於何種原因）手動分配允許使用dhcp來消除在需要在dhcp機制之外，手動配置ip地址主機的容易出錯過程。
dhcp消息的格式基於bootp消息的格式，以捕獲bootp規範中描述的bootp中繼代理行爲，並允許現有bootp客戶端與dhcp服務器的互操作性。使用bootp中繼代理可以有效消除在每個物理網絡上都有dhcp服務器。
對於新初始化的客戶端，並非所有這些參數都是必需的。客戶機和服務器可以協商只傳輸客戶機要求的或特定於特定子網的參數。
dhcp允許但不要求配置與ip協議不直接相關的客戶端參數。DHCP也不處理新配置的客戶端在域中的註冊
DHCP不用於配置路由器。
在本文件中，用於定義特定需求重要性的詞語均加粗。這些話是：
“必須”
該詞或形容詞“必需”是指該項目是本規範的絕對要求。
“不得”
這句話的意思是這個項目是絕對禁止本規範。
“應該”
這個詞或形容詞“推薦”的意思是，在特定情況下有正當理由可以忽略這一項，但在選擇不同的情景之前，應理解其全部含義並仔細權衡情景。
“不應該”
這句話的意思是，當所列行爲是可接受的，甚至是有用的，在特定情況下可能存在正當理由，但是，在實現用這個標籤描述的任何行爲之前，應該理解其全部含義並仔細權衡案例。
“可以”
這個詞或形容詞“可選”意味着這個項目是真正可選的。
本文件使用以下術語：
"DHCP client"
DHCP客戶端是使用DHCP獲取配置參數（如網絡地址）的Internet主機。
"DHCP server"
DHCP服務器是向DHCP客戶端返回配置參數的Internet主機。
BOOTP relay agent
bootp中繼代理或中繼代理是在dhcp客戶端和dhcp服務器之間傳遞dhcp消息的internet主機或路由器。dhcp被設計爲使用bootp協議規範中指定的相同中繼代理行爲。
binding
綁定是配置參數的集合，至少包括與DHCP客戶端關聯或“綁定到”DHCP客戶端的IP地址。綁定由DHCP服務器管理。
給出了dhcp的一般設計目標。
dhcp應該是一種機制，而不是策略。DHCP必須允許本地系統管理員在需要時控制配置參數；例如，本地系統管理員應該能夠在需要時強制執行有關分配和訪問本地資源的本地策略。
客戶端不需要手動配置。每個客戶機都應該能夠在不需要用戶干預的情況下發現適當的本地配置參數，並將這些參數合併到自己的配置中。
網絡中不需要爲單個客戶端進行手動配置。在正常情況下，網絡管理員不必輸入任何單一客戶端配置參數。
DHCP不需要在每個子網上的都有服務器。爲了實現規模和經濟性，dhcp必須跨路由器或通過bootp中繼代理進行干預。
DHCP客戶端必須準備好接收對配置參數請求的多個響應。一些安裝可能包括多個重疊的dhcp服務器，以提高可靠性和性能。
dhcp必須與靜態配置的非參與主機和現有的網絡協議實現共存。
dhcp必須與rfc 951和rfc 1542所描述的bootp中繼代理行爲互操作
DHCP必須爲現有的BOOTP客戶端提供服務。
給出了特定於網絡層參數傳輸的設計目標。DHCP必須：
保證任何特定的網絡地址不會被多個dhcp客戶端使用
在dhcp客戶端重新啓動時保留dhcp客戶端配置。在可能的情況下，dhcp客戶端響應每個請求應該使用 被分配相同的配置參數（例如，網絡地址）
在服務器重新啓動時保留dhcp客戶端配置，並且在可能的情況下，儘管dhcp機制重新啓動，仍應爲dhcp客戶端分配相同的配置參數
允許自動將配置參數分配給新客戶機，以避免手動配置新客戶機
支持將配置參數固定或永久分配給特定客戶端。
2。協議摘要
從客戶端的角度來看，dhcp是bootp機制的擴展。此行爲允許現有的bootp客戶端與dhcp服務器互操作，不需要對客戶端的初始化軟件進行任何更改。RFC1542[2]詳細說明了BOOTP與DHCP客戶端和服務器之間的交互[9]。有一些新的可選事務優化了dhcp客戶端和服務器之間的交互，如第3節所述，圖1給出了dhcp消息的格式，表1描述了dhcp消息中的每個字段。括號中的數字表示每個字段的大小（八位字節）。圖中給出的字段的名稱將在整個文檔中用於引用dhcp消息中的字段。
dhcp和bootp有兩個主要區別。首先，dhcp定義了一些機制，通過這些機制可以爲客戶端分配一個有限租約的網絡地址，從而允許將網絡地址串行重新分配給不同的客戶端。其次，dhcp爲客戶端提供了一種機制，使其能夠獲取運行所需的所有ip配置參數。
dhcp在術語上引入了一個小的變化，旨在澄清其中一個字段的含義。bootp中的“vendor extensions”字段被重新命名爲dhcp中的“options”字段。類似地，在bootp“vendor extensions”字段中使用的標記數據項（以前稱爲“vendor extensions”）現在只被稱爲“options”。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| op (1) | htype (1) | hlen (1) | hops (1) |
|報文的操作類型 |客的MAC地址類型|客的MAC地址長度|報文經中繼數目 |
+---------------+---------------+---------------+---------------+
| xid (4) |
|客戶端通過DHCP Discover報文發起一次IP地址請求時選擇的隨機數 |
+-------------------------------+-------------------------------+
| secs (2) | flags (2) |
|續約過程開始到現在所消耗的時間 |標識DHCP服務器應答報文是採用單播還是廣播發送
+-------------------------------+-------------------------------+
| ciaddr (4) |
| DHCP客戶端的IP地址 |
+---------------------------------------------------------------+
| yiaddr (4) |
| DHCP服務器分配給客戶端的IP地址 |
+---------------------------------------------------------------+
| siaddr (4) |
| 下一個爲DHCP客戶端分配IP地址等信息的DHCP服務器IP地址 |
+---------------------------------------------------------------+
| giaddr (4) |
| DHCP客戶端發出請求報文後經過的第一個DHCP中繼的IP地址 |
+---------------------------------------------------------------+
| chaddr (16) |
| DHCP客戶端的MAC地址 |
+---------------------------------------------------------------+
| sname (64) |
| 爲DHCP客戶端分配IP地址的DHCP服務器名稱 |
+---------------------------------------------------------------+
| file (128) |
| DHCP服務器爲DHCP客戶端指定的啓動配置文件名稱及路徑信息 |
+---------------------------------------------------------------+
| options (variable) |
+---------------------------------------------------------------+
圖 1: DHCP消息的格式
Field DHCPOFFER DHCPACK DHCPNAK
----- --------- ------- -------
'op' BOOTREPLY BOOTREPLY BOOTREPLY
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' 'xid' from client 'xid' from client 'xid' from client
DHCPDISCOVER DHCPREQUEST DHCPREQUEST
message message message
'secs' 0 0 0
'ciaddr' 0 'ciaddr' from 0
DHCPREQUEST or 0
'yiaddr' IP address offered IP address 0
to client assigned to client
'siaddr' IP address of next IP address of next 0
bootstrap server bootstrap server
'flags' 'flags' from 'flags' from 'flags' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'sname' Server host name Server host name (unused)
or options or options
'file' Client boot file Client boot file (unused)
name or options name or options
'options' options options
Option DHCPOFFER DHCPACK DHCPNAK
------ --------- ------- -------
Requested IP address MUST NOT MUST NOT MUST NOT
IP address lease time MUST MUST (DHCPREQUEST) MUST NOT
MUST NOT (DHCPINFORM)
Use 'file'/'sname' fields MAY MAY MUST NOT
DHCP message type DHCPOFFER DHCPACK DHCPNAK
Parameter request list MUST NOT MUST NOT MUST NOT
Message SHOULD SHOULD SHOULD
Client identifier MUST NOT MUST NOT MAY
Vendor class identifier MAY MAY MAY
Server identifier MUST MUST MUST
Maximum message size MUST NOT MUST NOT MUST NOT
All others MAY MAY MUST NOT
Table 3: Fields and options used by DHCP servers
-------- -------
| | +-------------------------->| |<-------------------+
| INIT- | | +-------------------->| INIT | |
| REBOOT |DHCPNAK/ +---------->| |<---+ |
| |Restart| | ------- | |
-------- | DHCPNAK/ | | |
| Discard offer | -/Send DHCPDISCOVER |
-/Send DHCPREQUEST | | |
| | | DHCPACK v | |
----------- | (not accept.)/ ----------- | |
| | | Send DHCPDECLINE | | |
| REBOOTING | | | | SELECTING |<----+ |
| | | / | | |DHCPOFFER/ |
----------- | / ----------- | |Collect |
| | / | | | replies |
DHCPACK/ | / +----------------+ +-------+ |
Record lease, set| | v Select offer/ |
timers T1, T2 ------------ send DHCPREQUEST | |
| +----->| | DHCPNAK, Lease expired/ |
| | | REQUESTING | Halt network |
DHCPOFFER/ | | | |
Discard ------------ | |
| | | | ----------- |
| +--------+ DHCPACK/ | | |
| Record lease, set -----| REBINDING | |
| timers T1, T2 / | | |
| | DHCPACK/ ----------- |
| v Record lease, set ^ |
+----------------> ------- /timers T1,T2 | |
+----->| |<---+ | |
| | BOUND |<---+ | |
DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/
DHCPNAK/Discard ------- | Broadcast Halt network
| | | | DHCPREQUEST |
+-------+ | DHCPACK/ | |
T1 expires/ Record lease, set | |
Send DHCPREQUEST timers T1, T2 | |
to leasing server | | |
| ---------- | |
| | |------------+ |
+->| RENEWING | |
| |----------------------------+
----------
Figure 5: State-transition diagram for DHCP clients
DHCP定義了一個新的“客戶端標識符”選項，用於將已明確的客戶端標識符傳遞給DHCP服務器。此更改消除了bootp消息中“chaddr”字段的重載，其中“chaddr”既用作發送bootp回覆消息的硬件地址，也用作客戶端標識符。“客戶端標識符”是一個不透明的密鑰，不能由服務器解釋；例如，“客戶端標識符”可以包含與“chaddr”字段內容相同的硬件地址，也可以包含其他類型的標識符，例如dns名稱。DHCP客戶端選擇的“客戶端標識符”必須是該客戶端所連接的子網中唯一的。如果客戶端在一條消息中使用“客戶端標識符”，則它必須在所有後續消息中使用相同的標識符，以確保所有服務器都正確地標識該客戶端。
dhcp將“siaddr”字段解釋爲在下一步客戶端引導進程的中使用的服務器地址。如果DHCP服務器準備提供下一個引導服務（例如，傳遞操作系統可執行映像），則它可以在“siaddr”字段中返回自己的地址。DHCP服務器總是在“服務器標識符”選項中返回自己的地址。
字段 字節 描述
----- ------ -----------
op 1 消息操作代碼/消息類型。 1=引導請求，2=引導回覆
htype 1 硬件地址類型，見“分配號碼”RFC中的ARP部分；例如，“1”=10MB以太網。
hlen 1 硬件地址長度（例如，“6”爲10MB以太網）。
hops 1 客戶端設置爲零，中繼代理在通過中繼代理時可以選擇使用。
xid 4 業務ID，由客戶端選擇的一個隨機數，客戶端和服務器使用它在客戶端和服務器之間關聯消息和響應。
secs 2 由客戶端填寫，自客戶端開始地址獲取或續訂過程以來經過的秒數。
flags 2 標誌（見圖2）。
ciaddr 4 客戶端IP地址；僅當客戶端處於綁定、續訂或重新綁定狀態並且可以響應ARP請求時填寫。
yiaddr 4 “你的”（客戶端）IP地址。
siaddr 4 引導中使用的下一個服務器的IP地址； 在dhcpoffer、dhcpack由服務器返回。
giaddr 4 中繼代理IP地址，用於引導通過中繼代理。
chaddr 16 客戶端硬件地址。
sname 64 選擇的服務器主機名, null terminated string最後一個字節用0x00填充
options var 可選參數字段。有關已定義選項的列表，請參見選項文檔。
------------------------------------------------------------------------------------------
表1:DHCP消息中字段的描述
“選項”字段現在是可變長度。DHCP客戶端必須接收“選項”字段長度至少爲312個字節的DHCP消息。此要求意味着DHCP客戶端必須準備好接收多達576個字節的消息，IP主機必須準備好接受的最小IP數據報大小[3]。DHCP客戶端可以通過“最大DHCP消息大小”選項協商使用較大的DHCP消息。選項字段可以進一步擴展到“file ”和“sname”字段。
對於使用dhcp進行初始配置的客戶機（在客戶機的tcp/ip軟件完全配置之前），dhcp要求創造性地使用客戶機的tcp/ip軟件和自由解釋rfc 1122。在配置IP地址之前，TCP/IP軟件應接受並轉發到IP層傳送到客戶端硬件地址的任何IP數據包；在配置TCP/IP軟件之前，DHCP服務器和BOOTP中繼代理可能無法將DHCP消息傳送到無法接受硬件單播數據報的客戶端。
爲了在配置TCP/IP軟件之前解決某些無法接受IP單播數據報的客戶端，DHCP使用'flags'字段[21]。最左邊的位被定義爲廣播（b）標誌。本文件第4.1節討論了該標誌的語義。標記字段的剩餘位保留供將來使用。客戶端必須將它們設置爲零，服務器和中繼代理必須忽略它們。圖2給出了“flags”字段的格式。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B: BROADCAST flag
MBZ: 必須爲零（保留供將來使用）
圖2：“flags”字段的格式
配置參數存儲庫
dhcp提供的第一個服務是爲網絡客戶端提供網絡參數的持久存儲。dhcp持久存儲的模型是，dhcp服務爲每個客戶端存儲一個密鑰值條目，其中密鑰是一些唯一的標識符（例如，ip子網號和子網內的唯一標識符），並且該值包含客戶端的配置參數。
例如，密鑰可能是對（IP子網號，硬件地址）（注意橋接網絡中，“硬件地址”應該按硬件類型鍵入，以適應混合介質中位排序問題可能導致的硬件地址重複）允許在不同子網上串行或併發地重用硬件地址，以及可能不是全局唯一的硬件地址。另外，密鑰可能是對（IP子網號、主機名），允許服務器智能地將參數分配給已移動到其他子網或已更改硬件地址的DHCP客戶端（可能是因爲網絡接口失敗並被替換）。協議定義密鑰爲（IP子網號、硬件地址），除非客戶端使用“客戶端標識符”選項顯式提供標識符。客戶端可以查詢DHCP服務以檢索其配置參數。配置參數存儲庫的客戶機接口由請求配置參數的協議消息和承載配置參數的服務器的響應組成。
網絡地址的動態分配
dhcp提供的第二個服務是將臨時或永久網絡（ip）地址分配給客戶端。動態分配網絡地址的基本機制很簡單：客戶端請求在一段時間內使用地址。分配機制（dhcp服務器的集合）保證在請求的時間內不重新分配該地址，並在每次客戶端請求地址時嘗試返回相同的網絡地址。在本文檔中，將網絡地址分配給客戶端的時間段稱爲“租約”[11]。客戶可以通過後續請求延長其租約。當客戶機不再需要地址時，客戶機可能會發出消息將地址釋放回服務器。客戶可以通過要求無限期租賃來要求永久性轉讓。即使在分配“永久”地址時，服務器也可以選擇發出長而非無限的租約，以允許檢測客戶機已退出的事實。
在某些環境中，由於可用地址用盡，需要重新分配網絡地址。在這種環境中，分配機制將重用租約已過期的地址。服務器應該使用配置信息存儲庫中可用的任何信息來選擇要重用的地址。例如，服務器可以選擇最近分配的最少地址。作爲一致性檢查，分配服務器應在分配地址（例如，使用icmp echo請求）之前探測重用的地址，而客戶端應探測新接收的地址（例如，使用arp）。
3客戶機-服務器協議
dhcp使用rfc 951中定義的bootp消息格式，如表1和圖1所示。從客戶端發送到服務器的每個dhcp消息的“op”字段都包含bootrequest。bootpreply用於從服務器發送到客戶端的每個dhcp消息的“op”字段。
dhcp使用rfc 951中定義的bootp消息格式，如表1和圖1所示。從客戶端發送到服務器的每個dhcp消息的“op”字段都包含bootrequest。bootpreply用於從服務器發送到客戶端的每個dhcp消息的“op”字段。
dhcp消息的“options”字段的前四個字節分別包含（十進制）值99、130、83和99（這是rfc 1497[17]中定義的相同的magic cookie[與BOOTP兼容,]）。“options”字段的其餘部分由一個名爲“options”的標記參數列表組成。RFC1497中列出的所有“供應商擴展”也是DHCP選項。rfc 1533給出了定義用於dhcp的完整選項集。
到目前爲止，已經定義了幾個選項。每個dhcp消息中都必須包含一個特定的選項-dhcp消息類型“選項。此選項定義DHCP消息的“類型”。根據DHCP消息類型，可能允許、需要或不允許其他選項。
在本文檔中，包含“dhcp消息類型”選項的dhcp消息將按消息類型引用；例如，具有“dhcp消息類型”選項類型1的dhcp消息將被稱爲“dhcpdiscover”消息。
客戶機服務器交互-------分配網絡地址
客戶機和服務器之間的協議交換的以下摘要涉及表2中描述的dhcp消息。圖3中的時間線圖顯示了典型的客戶機-服務器交互中的時間關係。如果客戶機已經知道其地址，則可以省略一些步驟；這種簡化的交互在第3.2節中進行了描述。
1。客戶端在其本地物理子網上廣播dhcpdiscover消息。dhcpdiscover消息可能包含建議網絡地址和租用期限值的選項。BOOTP中繼代理可以將消息傳遞到不在同一物理子網上的DHCP服務器。
2。每個服務器都可以用dhcpoffer消息進行響應，該消息在“yiaddr”字段中包含一個可用的網絡地址（以及dhcp選項中的其他配置參數）。服務器無需保留提供的網絡地址，但如果服務器避免將提供的網絡地址分配給另一個客戶端，則協議將更有效地工作。在分配新地址時，服務器應檢查所提供的網絡地址是否尚未使用；例如，服務器可以使用ICMP回送請求探測所提供的地址。應實現服務器，以便網絡管理員可以選擇禁用新分配地址的探測。服務器將dhcpoffer消息傳輸到客戶端，必要時使用bootp中繼代理。
Message Use
------- ---
DHCPDISCOVER - 客戶端廣播以定位可用服務器。
DHCPOFFER - 服務器到客戶端響應dhcpdiscover並提供配置參數。
DHCPREQUEST - 客戶機消息向服務器（a）請求來自一個服務器的提供的參數，並絕對拒絕來自所有其他服務器，（b）確認以前分配的地址在系統重新啓動後的正確性（c）在特定的網絡地址上擴展租約。
DHCPACK - 服務器到客戶端的配置參數，包括提交的網絡地址。
DHCPNAK - 服務器到客戶端指示客戶端的網絡地址概念不正確（例如，客戶端已移動到新的子網）或客戶端的租約已過期
DHCPDECLINE - 表示網絡地址已在使用的客戶端到服務器。
DHCPRELEASE - 客戶端到服務器放棄網絡地址並取消剩餘租約。
DHCPINFORM - 客戶端到服務器，只請求本地配置參數；客戶端已經具有外部配置的網絡地址。
表2:DHCP消息
服務器 客戶機 服務器
(未找到) (存在)
v v v
| | |
| 開始初始化 |
| | |
| _____________/|\____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
| | |
確定配置 | 確定配置
| | |
| | |
|\ | ____________/|
| \________ | /DHCPOFFER |
| DHCPOFFER\ |/ |
| \ | |
| 收集迴應 |
| \ | |
| 選擇配置 |
| | |
| _____________/|\____________ |
|/ DHCPREQUEST | DHCPREQUEST\ |
| | |
| | 提交配置
| | |
| | _____________/|
| |/ DHCPACK |
| | |
| 初始化完成 |
| | |
. . .
. . .
| | |
| 正常關機 |
| | |
| |\ ____________ |
| | DHCPRELEASE \|
| | |
| | 放棄租賃
| | |
v v v
圖3：分配新網絡地址時DHCP客戶端和服務器之間交換消息的時間線圖
3。客戶端從一個或多個服務器接收一個或多個dhcpoffer消息。客戶端可以選擇等待多個響應。客戶機根據dhcpoffer消息中提供的配置參數選擇一個服務器，從中請求配置參數。客戶端廣播dhcprequest消息，該消息必須包含“服務器標識符”選項，以指示它選擇了哪個服務器，並且可能包含指定所需配置值的其他選項。“請求的IP地址”選項必須設置爲來自服務器的dhcpoffer消息中的“yiaddr”值。dhcprequest消息通過dhcp/bootp中繼代理進行廣播和中繼。爲了幫助確保任何bootp中繼代理將dhcprequest消息轉發到接收原始dhcpdiscover消息的同一組dhcp服務器，dhcprequest消息必須在dhcp消息頭的“secs”字段中使用相同的值，併發送到與原始dhcpdiscover消息相同的ip廣播地址。如果客戶端沒有收到dhcpoffer消息，則客戶端超時並重新傳輸dhcpdiscover消息。
4。服務器從客戶端接收dhcprequest廣播。dhcprequest消息未選擇的服務器使用該消息作爲客戶端已拒絕該服務器提供的通知。dhcprequest消息中選擇的服務器將客戶端的綁定提交到持久性存儲，並用包含請求客戶端的配置參數的dhcpack消息進行響應。“客戶端標識符”或“chaddr”與分配的網絡地址的組合構成客戶端租約的唯一標識符，客戶端和服務器都使用它來標識任何dhcp消息中引用的租約。dhcpack消息中的任何配置參數都不應與客戶端正在響應的早期dhcpoffer消息中的配置參數衝突。此時服務器不應檢查提供的網絡地址。dhcpack消息中的“yiaddr”字段用已選定的網絡地址填充。
如果所選服務器無法滿足dhcprequest消息（例如，已分配請求的網絡地址），則服務器應使用dhcpnak消息響應。
服務器可以選擇將dhcpoffer消息中提供給客戶端的地址標記爲不可用。如果服務器未從該客戶端接收到dhcprequest消息，則服務器應將dhcpoffer消息中提供給客戶端的地址標記爲可用。
5。客戶端接收帶有配置參數的dhcpack消息。客戶端應該對參數（例如，分配的網絡地址的arp）執行最終檢查，並注意dhcpack消息中指定的租用期限。此時，客戶端已配置。如果客戶端檢測到地址已在使用中（例如，通過使用arp），則客戶端必須向服務器發送dhcpdreen消息並重新啓動配置過程。客戶端應在重新啓動配置進程之前至少等待10秒，以避免在循環情況下出現過多的網絡流量。
如果客戶端收到dhcpnak消息，則客戶端重新啓動配置過程。
如果客戶端既沒有收到dhcpack消息，也沒有收到dhcpnak消息，則客戶端將超時並重新傳輸dhcprequest消息。客戶端根據第4.1節中的重傳算法重傳dhcprequest。客戶端應該選擇重新傳輸dhcprequest足夠的時間，以提供足夠的概率來聯繫服務器，而不會導致客戶端（和該客戶端的用戶）在放棄之前等待太長時間；例如，如第4.1節所述的客戶機重傳可以在重新啓動初始化過程之前重傳4次dhcprequest消息，總延遲爲60秒。如果客戶端在採用重傳算法後既沒有收到dhcpack消息，也沒有收到dhcpnak消息，則客戶端將恢復到init狀態並重新啓動初始化過程。客戶端應通知用戶初始化過程已失敗並正在重新啓動。
6。客戶端可以選擇通過向服務器發送dhcprelease消息來放棄對網絡地址的租用。客戶端使用dhcprelease消息中的“客戶端標識符”或“chaddr”和網絡地址標識要釋放的租約。如果客戶端在獲得租約時使用了“客戶端標識符”，則它必須在DHCPRORYLY消息中使用相同的“客戶端標識符”。
客戶機-服務器交互-重用以前分配的網絡地址
如果客戶機記住並希望重用先前分配的網絡地址，則客戶機可以選擇省略上一節中描述的一些步驟。圖4中的時間線圖顯示了客戶機重用先前分配的網絡地址的典型客戶機-服務器交互中的時間關係。
1。客戶端在其本地子網上廣播dhcprequest消息。消息在“請求的IP地址”選項中包含客戶端的網絡地址。由於客戶端尚未收到其網絡地址，因此不能填寫“ciaddr”字段。BOOTP中繼代理將消息傳遞到不在同一子網上的DHCP服務器。如果客戶端使用“客戶端標識符”獲取其地址，則客戶端必須在dhcprequest消息中使用相同的“客戶端標識符”。
2。瞭解客戶機配置參數的服務器用dhcpack消息響應客戶機。服務器不應檢查客戶端的網絡地址是否已在使用中；此時客戶端可能會響應ICMP回顯請求消息。
Server Client Server
v v v
| | |
| 開始初始化 |
| | |
| /|\ |
| ___________/ | \___________ |
| /DHCP REQUEST | DHCPREQUEST\ |
|/ | \|
| | |
定位配置 | 定位配置
| | |
|\ | /|
| \ | ___________/ |
| \ | / DHCPACK |
| \ _______ |/ |
| DHCPACK\ | |
| 初始化完成 |
| \| |
| | |
| 忽略後續dhcp包 |
| | |
| | |
v v v
圖4：重用以前分配的網絡地址時DHCP客戶端和服務器之間交換的消息的時間線圖
如果客戶機的請求無效（例如，客戶機已移動到新的子網），服務器應使用dhcpnak消息響應客戶機。如果不能保證服務器的信息是準確的，則服務器不應響應。例如，標識由另一臺服務器擁有的過期綁定請求的服務器不應使用dhcpnak響應，除非服務器使用明確的機制來保持服務器之間的一致性。
客戶端使用其“客戶端標識符”標識要釋放的租約，或dhcprelease消息中的“chaddr”和網絡地址。如果客戶端在獲取租約時使用了“客戶端標識符”，則必須在dhcprelease消息中使用相同的“客戶端標識符”。
3。客戶端接收具有配置參數的DHCPACK消息。客戶端對參數進行最終檢查（如第3.1節），並記錄DHCPACK消息中指定的租約的持續時間。特定租約由“客戶端標識符”或“chaddr”和網絡地址隱式標識。此時，客戶端已配置。
如果客戶端檢測到dhcpack消息中的IP地址已在使用中，則客戶端必須向服務器發送dhcpdecline消息，並通過請求新的網絡地址重新啓動配置過程。此操作對應於客戶端移動到DHCP狀態圖中的init狀態，如4.4節所述。
如果客戶端接收到dhcpnak消息，則無法重用其記住的網絡地址。相反，它必須通過重新啓動配置過程來請求新地址，這次使用第3.1節中描述的（非縮寫）過程。此操作還對應於客戶端移動到dhcp狀態圖中的init狀態。
如果客戶端既沒有收到dhcpack消息，也沒有收到dhcpnak消息，則客戶端將超時並重新傳輸dhcprequest消息。客戶端根據第4.1節中的重傳算法重傳dhcprequest。客戶端應該選擇重新傳輸dhcprequest足夠的時間，以提供足夠的概率來聯繫服務器，而不會導致客戶端（和該客戶端的用戶）在放棄之前等待太長時間；例如，如第4.1節所述的客戶機重傳可以在重新啓動初始化過程之前重傳4次dhcprequest消息，總延遲爲60秒。如果客戶端在採用重傳算法之後既沒有收到dhcpack消息，也沒有收到dhcpnak消息，則客戶端可以選擇在剩餘的未到期租約中使用先前分配的網絡地址和配置參數。這對應於在圖5所示的客戶機狀態轉換圖中移動到綁定狀態。
4。客戶端可以通過向服務器發送DHCPRORYLY消息來選擇在網絡地址上放棄其租約。客戶端使用dhcprelease消息中的“客戶端標識符”或“chaddr”和網絡地址標識要釋放的租約。
注意，在這種情況下，客戶端在本地保留其網絡地址，在正常關機期間，客戶端通常不會放棄其租約。只有在客戶端明確地需要放棄其租約的情況下，例如，客戶端將被移動到不同的子網時，客戶端纔會發送DHCPRORYLY消息。
客戶端在固定的時間段（可能是無限的）獲取網絡地址的租約。在整個協議中，時間以秒爲單位來表示。0xFFFFFFF的時間值被保留爲表示“無窮大”。
由於客戶端和服務器可能沒有同步時鐘，所以在DHCP消息中以相對時間來表示時間，以相對於客戶端的本地時鐘進行解釋。在無符號32位字中以秒爲單位表示相對時間，給出了從0到大約100年的相對時間範圍，這對於用DHCP測量相對時間是足夠的。
在前一段中給出的租期解釋的算法假定客戶機和服務器時鐘相對彼此穩定。如果兩個時鐘之間有漂移，則服務器可以考慮在客戶端之前終止租約。爲了補償，服務器可能會向客戶端返回比服務器提交給其本地客戶端數據庫更短的租用期限
利用外部配置的網絡地址獲取參數
如果客戶端已經通過一些其他手段（例如，手動配置）獲得網絡地址，則它可以使用DHCpFILM請求消息來獲得其他本地配置參數。接收DHCPNFLATH消息的服務器構造一個DHCPACK消息，該DHCPACE消息具有適合於客戶端的任何本地配置參數，而無需分配新地址、檢查現有綁定、填寫“yiaddr”或包含租約時間參數。服務器應將dhcpack回覆單播到dhcpinfo消息的“ciaddr”字段中給定的地址。
服務器應該檢查DHCPNFLASH消息中的網絡地址的一致性，但不能檢查現有的租約。服務器形成包含請求客戶端的配置參數的DHCPACK消息，並將DHCPACK消息直接發送給客戶端。
DHCP中的客戶端參數
使用兩種技術來減少從服務器發送到客戶端的參數的數量。首先，大多數參數在主機要求RFCS中定義了默認值；如果客戶端從覆蓋默認值的服務器接收不到任何參數，則客戶端使用這些默認值。其次，在其初始DHCPDISCOVER 或DHCPRQuest消息中，客戶端可以向服務器提供客戶端感興趣的特定參數列表。如果客戶端包含DHCPDISCOVER 消息中的參數列表，則它必須在任何後續的DHCPRESQuess消息中包含該列表。
客戶端應該包括“最大DHCP消息大小”選項，服務器可能生成其dhcp消息的大小。返回到客戶端的參數可能仍然超過分配給DHCP消息中選項的空間。在這種情況下，兩個附加的選項標誌（必須出現在消息的“options”字段中）指示“file”和“sname”字段將用於選項。
另外，客戶機可以建議網絡地址和DHCPOR消息中的租賃時間。
客戶端可以包括“請求的IP地址”選項，建議指定一個特定的IP地址，並且可以包括“IP地址租借時間”選項來建議它希望租用的時間。在DHCPDISCOVER或DHCPREQUEST消息中允許其他表示配置參數的“提示”選項。但是，服務器可能會忽略其他選項，因此，多個服務器可能不會爲某些選項返回相同的值。當客戶端驗證先前獲得的網絡參數時，只在DDHCPREQUEST消息中填寫所請求的IP地址選項。只有正確配置IP地址處於綁定、續訂或重新綁定狀態時，客戶端纔會填寫“ciaddr”字段。
3.6在具有多個接口的客戶端中使用dhcp
具有多個網絡接口的客戶端必須獨立地通過每個接口使用dhcp來獲取這些獨立接口的配置信息參數。
3.7客戶端何時應使用DHCP
當本地網絡參數可能發生變化時，客戶端應使用dhcp重新獲取或驗證其ip地址和網絡參數；例如，在系統啓動時或與本地網絡斷開連接後，因爲本地網絡配置可能在客戶端或用戶不知情的情況下發生變化。
如果客戶端知道以前的網絡地址，並且無法聯繫本地DHCP服務器，則客戶端可以繼續使用以前的網絡地址，直到該地址的租約到期。如果租約在客戶端可以聯繫DHCP服務器之前過期，客戶端必須立即停止使用以前的網絡地址，並可能將問題通知本地用戶。
四。dhcp客戶機服務器協議規範
在本節中，我們假設dhcp服務器有一個網絡地址塊，它可以從中滿足對新地址的請求。每個服務器還維護一個數據庫，其中包含分配的地址和本地永久存儲器中的租約。
4.1構造和發送DHCP消息
dhcp客戶端和服務器都通過在消息的固定格式部分填充字段並在可變長度選項區域中附加標記的數據項來構造dhcp消息。選項區域首先包括一個四個字節的“magic cookie”（在第3節中有描述），然後是選項。最後一個選項必須始終是“結束”選項。
dhcp使用udp作爲其傳輸協議。從客戶端到服務器的DHCP消息發送到“DHCP服務器”端口（67），從服務器到客戶端的DHCP消息發送到“DHCP客戶端”端口（68）。具有多個網絡地址（例如，多宿主主機）的服務器可以在傳出的dhcp消息中使用其任何網絡地址。
“服務器標識符”字段既用於在DHCP消息中標識DHCP服務器，也用作從客戶端到服務器的目標地址。具有多個網絡地址的服務器必須準備好接受其任何網絡地址，以在DHCP消息中標識該服務器。爲了適應可能不完全的網絡連接，服務器必須選擇一個地址作爲“服務器標識符”，據服務器所知，該地址可以從客戶端訪問。例如，如果DHCP服務器和DHCP客戶端連接到同一子網（來自客戶端的消息中的“giaddr”字段爲零），則服務器應選擇服務器在該子網上用於通信的IP地址作爲“服務器標識符”。如果服務器在該子網上使用多個IP地址，則可以使用任何此類地址。如果服務器已通過DHCP中繼代理接收到消息，則服務器應從消息所在的接口中選擇一個地址作爲“服務器標識符”接收（除非服務器有其他更好的信息可供選擇）。對於任何到DHCP服務器的單播請求，DHCP客戶端必須使用“服務器標識符”選項中提供的IP地址。
客戶端在獲取其IP地址之前廣播的DHCP消息必須將IP頭中的“源地址”字段設置爲0。
如果來自客戶端的DHCP消息中的“giaddr”字段爲非零，則服務器會將任何返回消息發送到bootp中繼代理上的“dhcp server”端口，其地址顯示在“giaddr”中。
如果“giaddr”字段爲零，“ciaddr”字段爲非零，則服務器將dhcpoffer和dhcpack消息單播到“ciaddr”中的地址。
如果“giaddr”爲零，“ciaddr”爲零，並且設置了廣播位，則服務器將dhcpoffer和dhcpack消息廣播到0xffffff。
如果未設置廣播位，“giaddr”爲零，“ciaddr”爲零，則服務器將dhcpoffer和dhcpack消息單播到客戶端的硬件地址和“yiaddr”地址。
在所有情況下，當“giaddr”爲零時，服務器會將任何dhcpnak消息廣播到0xffffff。
如果來自客戶端的DHCP消息中的“giaddr”字段爲非零，則服務器會將任何返回消息發送到bootp中繼代理上的“dhcp server”端口，其地址顯示在“giaddr”中。如果“giaddr”字段爲零，“ciaddr”字段爲非零，則服務器將dhcpoffer和dhcpack消息單播到“ciaddr”中的地址。如果“giaddr”爲零，“ciaddr”爲零，並且設置了廣播位，則服務器將dhcpoffer和dhcpack消息廣播到0xffffff。如果未設置廣播位，“giaddr”爲零，“ciaddr”爲零，則服務器將dhcpoffer和dhcpack消息單播到客戶端的硬件地址和“yiaddr”地址。在所有情況下，當“giaddr”爲零時，服務器會將任何dhcpnak消息廣播到0xffffff。
如果DHCP消息中的選項擴展到“sname”和“file”字段，則“option overload”選項必須出現在“options”字段中，其值爲1、2或3，如RFC 1533中所指定。如果“選項”字段中存在“選項重載”選項，“option”字段中的選項必須由“end”選項終止，並且可以包含一個或多個“pad”選項來填充選項字段。“sname”和“file”字段中的選項（如果按“options overload”選項指示使用）必須以字段的第一個字節開頭，必須以“end”選項結尾，並且必須後跟“pad”選項才能填充字段的其餘部分。“options”、“sname”和“file”字段中的任何單個選項都必須完全包含在該字段中。必須首先解釋“options”字段中的選項，以便可以解釋任何“option overload”選項。接下來必須解釋“file”字段（如果“option overload”選項指示“file”字段包含dhcp選項），然後是“sname”字段。
DHCP客戶端負責所有消息的重新傳輸。客戶端必須採用一種重傳策略，該策略採用隨機指數退避算法來確定重傳之間的延遲。應選擇重傳之間的延遲，以便根據客戶機和服務器之間的互連網的特性，從服務器傳送足夠的時間來回復。例如，在10MB/秒的以太網網絡中，第一次重新傳輸前的延遲應爲4秒，由從-1到+1範圍內選擇的均勻隨機數的值隨機化。具有提供小於一秒的分辨率粒度的時鐘的客戶端可以選擇非整數隨機化值。下一次重新傳輸前的延遲應爲8秒，由從-1到+1範圍內選擇的統一數字的值隨機化。重傳延遲應該加倍，隨後的重傳達到最大64秒。客戶端可以向用戶提供重傳嘗試的指示，作爲配置過程的進展的指示。
客戶端使用“xid”字段將傳入的dhcp消息與掛起的請求相匹配。DHCP客戶端必須選擇“xid”，這樣才能最大限度地減少使用與另一個客戶端使用的xid相同的xid的機會。例如，每次重新啓動客戶機時，客戶機可以選擇不同的隨機初始“xid”，然後使用順序“xid”，直到下次重新啓動。爲每次重新傳輸選擇一個新的“xid”是一個實現決策。客戶端可以選擇重複使用相同的“xid”或爲每個重新傳輸的消息選擇新的“xid”。
通常，DHCP服務器和BOOTP中繼代理嘗試使用UICAST遞送直接向客戶端遞送DHCPOFFER、DHCPACK和DHCPNAK消息。IP目的地址（在IP報頭中）是設置爲DHCP“YAdDR”地址，鏈路層目標地址設置爲DHCP“CHADDR”地址。不幸的是，一些客戶端實現無法接收這樣的單播IP數據報，直到實現了具有有效IP地址的配置（導致在客戶端配置IP地址之前無法傳送客戶端IP地址的死鎖）。
如果客戶端在其協議軟件配置了IP地址之前無法接收單播IP數據報，則應在客戶端發送的任何DHCPdiscover或DHCPrequest消息中，將“標誌”字段中的廣播位設置爲1。廣播位將向dhcp服務器和bootp中繼代理提供一個提示，以便向客戶端子網上的客戶端廣播任何消息。可以在配置協議軟件之前接收單播IP數據報的客戶端應將廣播位清除爲0。BOOTP澄清文件討論了使用廣播位的影響
服務器或中繼代理直接向DHCP客戶端發送或轉發DHCP消息（即，不是在“GiADDR”字段中指定的中繼代理）應檢查“標誌”字段中的廣播位。如果該比特被設置爲1，則DHCP消息應當作爲IP廣播地址（最好是0xFFFFFFFF）作爲IP目的地址和鏈路層廣播地址作爲鏈路層目的地地址作爲IP廣播來發送。如果廣播位被清除爲0，則該消息應作爲IP單播發送到“YAdDR”字段中指定的IP地址和“CHADDR”字段中指定的鏈路層地址。如果單播是不可能的，消息可以作爲IP廣播地址（最好是0xFFFFFFFF）作爲IP目的地址和鏈路層廣播地址作爲鏈路層目的地地址來發送。
4.2 DHCP服務器管理控制
dhcp服務器不需要響應它們接收到的每個dhcpdiscover和dhcprequest消息。例如，網絡管理員對連接到網絡的客戶端保持嚴格的控制，可以選擇配置DHCP服務器只響應已經通過某些外部機制註冊的客戶端。當客戶機和服務器選擇交互時，dhcp規範僅描述客戶機和服務器之間的交互；描述系統管理員可能要使用的所有管理控件超出了dhcp規範的範圍。特定的DHCP服務器實現可以包含網絡管理員期望的任何控件或策略。
在某些環境中，當確定特定客戶機的校正參數時，DHCP服務器將不得不考慮DHCP Debug或DHCPRQuestEnter消息中包含的供應商類選項的值。
DHCP服務器需要使用某個唯一標識符將客戶端與其租約關聯起來。客戶端可以選擇通過“客戶端標識符”選項顯式提供標識符。如果客戶機提供了“客戶標識符”，則客戶機必須在所有後續消息中使用相同的“客戶標識符”，服務器必須使用該標識符來標識客戶機。如果客戶端不提供“客戶端標識符”選項，則服務器必須使用“CHADDR”字段的內容來標識客戶端。對於DHCP客戶端來說，在“客戶端標識符”選項中客戶端附加到的子網中使用唯一的標識符是至關重要的。使用“chaddr”作爲客戶端的唯一標識符可能會導致意外結果，因爲該標識符可能與可以移動到新客戶端的硬件接口相關聯。一些站點可能選擇使用製造商的序列號作爲“客戶端標識符”，以避免由於計算機之間的硬件接口傳輸而導致客戶端網絡地址發生意外更改。網站也可以選擇使用作爲“客戶端標識符”的DNS名稱，導致地址租約與DNS名稱關聯，而不是與特定硬件框關聯。
DHCP客戶端可以自由地使用任何策略來選擇DHCP服務器，其中客戶端接收DHCCPFARE消息。DHCP的客戶端實現應該爲用戶提供一種直接選擇“供應商類別標識符”值的機制。
當服務器從客戶端接收DHCP發現消息時，服務器爲請求客戶端選擇網絡地址。如果沒有可用的地址，服務器可以選擇向系統管理員報告問題。如果有地址可用，則應按如下方式選擇新地址：
o客戶當前綁定中記錄的客戶當前地址，否則
o客戶機綁定（現在已過期或已釋放）中記錄的客戶機以前的地址，如果該地址位於服務器的可用地址池中且尚未分配，則爲
o在“請求的IP地址”選項中請求的地址，如果該地址有效且尚未分配，則爲
o從服務器可用地址池中分配的新地址；根據從中選擇地址的子網
已收到消息（如果“giaddr”爲0），或位於轉發消息的中繼代理的地址（如果不是0，則爲“giaddr”）
o從服務器可用地址池中分配的新地址；基於接收消息的子網（如果‘GiADDR’是0）或轉發消息的中繼代理的地址（“GiADDR”，而不是0）選擇地址。
如第4.2節所述，出於管理原因，服務器可以分配所請求的地址以外的地址，或者可以拒絕分配地址給特定的客戶端，即使有可用的空閒地址。
注意，在某些網絡體系結構中（例如，具有分配給物理網段的多個IP子網的Internet），可能是DHCP客戶機應該分配給一個不同於“giaddr”中記錄的地址的子網地址。因此，dhcp不要求將客戶端作爲地址從“giaddr”中的子網分配。服務器可以自由選擇其他子網，並且它超出了dhcp規範的範圍，無法描述選擇分配的ip地址的方式。
雖然不需要正確操作dhcp，但在客戶端響應服務器的dhcpoffer消息之前，服務器不應重用選定的網絡地址。服務器可以選擇記錄提供給客戶端的地址。