DHCP協議——RFC2131
1 Introduction
DHCP協議，即Dynamic Host Configuration Protocol，動態主機配置協議，主要是爲了解決動態主機 配置問題，DHCP提供了一個在TCP/IP網絡中傳遞配置信息給主機的框架。DHCP基於BOOTP開發，增加了可重用網絡地址的自動分配功能和額外的配置選項。DHCP可以捕獲BOOTP中繼器的動作，並且DHCP設備可以BOOTP設備互操作。
1.1 相關協議
對於動態主機配置問題的解決，已有幾種網絡協議和相關的機制在工作。RARP協議明確的處理網絡地址發現的問題，幷包括一套自動IP地址分配機制。TFTP提供了將一個小的簡單文件從boot服務器傳輸的問題。ICMP協議通過“ICMP重定向”消息提供了額外路由器的通知主機。ICMP同樣可以通過“ICMP掩碼請求”消息提供子網掩碼信息。主機可以通過ICMP路由發現機制來定位路由器。
一般網絡中會有數種協議參與解決動態主機的配置問題，DHCP協議主要用於在配置的初始化過程中，在後面的工作中，一般只在地址續期或重新分配時再次使用。
1.2 設計目標
RFC2131對DHCP協議的設計提出幾點目標，這也是DHCP協議所具備的基本功能：
- DHCP應該是一個機制，而不是策略
- 客戶端無需手動配置參數
- 網絡無需爲客戶端手動配置桉樹
- DHCP應該無需再每個子網都配置DHCP服務器
- DHCP客戶端必須隨時準備接收一個參數配置請求的多個響應
- DHCP必須和靜態配置的、不參與的主機以及已存在的網絡協議實現共存
- DHCP必須可以與RFC 951和RFC 1542所定義的BOOTP中繼代理行爲交互操作
- DHCP必須爲已存在的BOOTP客戶端提供服務
因此，DHCP必須：
- 確保任何指定的網絡地址在同一時間，只能被不超過一個的DHCP客戶端使用
- 在客戶端重啓後，保持DHCP客戶端配置參數不變，只要可能的情況下，對每個請求，DHCP客戶端都應該被分配一樣的配置參數
- 在服務器重啓後，保持DHCP客戶端配置參數不變，只要可能的情況下，DHCP客戶端應該被分配同樣的配置參數，而不管DHCP機制的重啓
- 允許對新客戶端配置參數的自動分配，來避免手動配置
- 對於指定客戶端，支持固定或永久的配置的分配
1.3 術語
1.4 資料引用
2 Summary
從客戶端的角度看來，DHCP是BOOTP機制的一個擴展，這導致已在的BOOTP客戶端可以和DHCP服務器直接相互操作，而不需對客戶端的初始化軟件進行任何修改。RFC 1542詳細描述了BOOTP設備和DHCP客戶端及服務器之間的交互。在RFC 2131中，提供了一些新的可選的處理，用於優化DHCP客戶端和服務器之間的交互操作。
圖1給出了DHCP消息的格式，表1描述了消息中的每個字段。
| FIELD | OCTETS | DESCRIPTION |
|---|---|---|
| op | 1 | Message op code / message type. 1 = BOOTREQUEST, 2 = BOOTREPLY |
| htype | 1 | Hardware address type, see ARP section in “Assigned Numbers” RFC; e.g., ’1’ = 10mb ethernet. |
| hlen | 1 | Hardware address length (e.g. ’6’ for 10mb ethernet). |
| hops | 1 | Client sets to zero, optionally used by relay agents when booting via a relay agent. |
| xid | 4 | Transaction ID, a random number chosen by the client, used by the client and server to associate messages and responses between a client and a server. |
| secs | 2 | Filled in by client, seconds elapsed since client began address acquisition or renewal process. |
| flags | 2 | Flags (see figure 2). |
| ciaddr | 4 | Client IP address; only filled in if client is in BOUND, RENEW or REBINDING state and can respond to ARP requests. |
| yiaddr | 4 | ’your’ (client) IP address. |
| siaddr | 4 | IP address of next server to use in bootstrap; returned in DHCPOFFER, DHCPACK by server. |
| giaddr | 4 | Relay agent IP address, used in booting via a relay agent. |
| chaddr | 16 | Client hardware address. |
| sname | 64 | Optional server host name, null terminated string. |
| file | 128 | Boot file name, null terminated string; “generic” name or null in DHCPDISCOVER, fully qualified directory-path name in DHCPOFFER. |
| options | var | Optional parameters field. See the options documents for a list of defined options. |
目前，‘option’字段的長度是可變的，但長度至少在312字節，這一要求表明，一個DHCP客戶端必須能夠接受一個長度達576字節的消息，這是一個IP主機必須能接收的最小IP數據報長度。DHCP客戶端可以通過’maximum DHCP message size’選項協商使用更大的DHCP消息報文。這一選擇字段可能在後續擴展進‘filt’和‘sname’字段。
在一個客戶端使用DHCP用於初始化配置的情況下，DHCP需要對客戶端TCP/IP軟件進行創造性的運用，並對RFC 1211進行自由的解釋。在IP地址配置之前，TCP/IP軟件應該接受和轉發任何客戶端接收到的IP報文給IP層；在TCP/IP軟件被配置之前，DHCP服務器和BOOTP中繼器肯恩無法傳送DHCP消息給那些無法接收硬件廣播數據報的終端。針對這些終端，DHCP使用‘flags’字段，如下圖2所示，最左邊的bit被定義爲BROADCAST（B）標誌位，該位語義的討論稍後展開。其他位必須被客戶端設爲0並且被服務器和中繼器忽略。
2.1 配置參數倉庫
DHCP提供的第一個服務，是爲網絡客戶端提供永久的網絡參數倉庫。該倉庫的模式是，DHCP服務爲每個客戶端存儲一個key-value入口，這裏的key是一個唯一標誌，這裏的value包含這個客戶端的配置參數。
比如，key可能是一對（IP-subnet-number，hardware-address），允許在不同的子網內連續或同時使用一個硬件地址，並且允許使用非全球唯一的硬件地址。同時，key可能是一對（IP-subnet-number,hostname），允許服務器去智能的給那些已經移動到別的子網或變動了硬件地址的客戶端分配地址。根據協議定義，除非客戶端使用‘client identifier’字段明確支持一個標識符，key應是（IP-subnet-number，hardware-address）對。客戶端可以向DHCP服務請求重新獲取配置參數。客戶端對接配置參數倉庫的接口包含兩部分，發給服務器的請求配置參數的協議消息和來自服務器的攜帶配置參數的響應。
2.2 網絡地址的動態配置
爲客戶端臨時的或永久的分配網絡地址，是DHCP提供的第二個服務。該服務的基本機制是：客戶端請求在一定週期時間內使用某個網絡地址。這種分配機制確保在請求的時間內，不會重複分配該地址，並且盡力在每次指定客戶端請求地址時，都分配同樣的網絡地址，在DHCP協議中，該週期被稱爲租期（lease）。客戶端可以通過後續的請求來延長租期，也可以在不需要地址時通過發送消息來釋放地址給服務器。客戶端可以通過請求一個無限的租期來獲取一個永久的地址分配。但是即使分配了永久地址，服務器可能選擇給出一個很長但是非無窮的租期，來允許對客戶端已經退出這一事實進行探測。
在一些環境中，由於可用地址耗盡，有必要對網絡地址進行重新分配。此時，分配機制會重用那些租期已經時效的地址。服務器應該利用參數信息倉庫中任何可用信息，去選擇一個可重用的地址。比如，服務器可能會選擇最近最少被分配的地址。作爲一種相容性檢測，分配服務器應該在分配地址之前對重用地址進行探測，比如使用ICMPecho請求，而客戶端應該探測新接收到的地址，比如使用ARP。
2.3 DHCP和BOOTP的區別
DHCP和BOOTP有兩個主要的區別：
- DHCP定義的機制中，客戶端在有限的週期內分配一個網絡地址，並允許對不同客戶端分配一系列的網絡地址。
- DHCP提供的機制中，客戶端獲取所有它所需要的IP配置參數來進行操作。
此外，DHCP在術語上引入了一個小的改動來表明一個字段的意義，BOOTP中定義的“vendor extension”供應商擴展，在DHCP中被定義爲option，類似的標籤數據項也被重新命名爲option。
3 客戶端-服務器協議
DHCP使用BOOTP消息格式（RFC 951），每一個從客戶端發送到服務器的DHCP消息的‘op’字段辦好BOOTREQUEST，BOOTREPLY在每一個從服務器發送到客戶端的DHCP消息中的‘op’字段使用。
DHCP消息的‘options’字段的前四個字節分別包含四個十進制數值99,130,83和99，該字段的餘下部分由一系列被稱爲‘options’的打了標籤的參數組成。RFC 1497中所有列出的供應商擴展‘vender extension’也是DHCP選項。RFC 1533給出了DHCP使用的一套完整的選項定義。
目前，一些選項已經被定義。一個特殊的option——DHCP消息類型選項——必須被包含在每一個DHCP消息中。這個option定義了DHCP消息的類型。其他選項的允許、需要、或不被允許都依賴於該DHCP消息類型。
3.1 客戶端-服務器交互——分配一個網絡地址
客戶端和服務器的交互依賴於DHCP消息，如表2所定義。圖3中的時序圖展示了在一個典型的客戶端-服務器交互中的書時序關係。如果客戶端已經知道了自己的地址，那麼一些步驟可能會被省略。
| Message | Use |
|---|---|
| DHCPDISCOVER | Client broadcast to locate available servers. |
| DHCPOFFER | Server to client in response to DHCPDISCOVER withoffer of configuration parameters. |
| DHCPREQUEST | Client message to servers either (a) requesting offered parameters from one server and implicitly declining offers from all others, (b) confirming correctness of previously allocated address after, e.g., system reboot, or (c) extending the lease on a particular network address. |
| DHCPACK | Server to client with configuration parameters, including committed network address. |
| DHCPNAK | Server to client indicating client’s notion of network address is incorrect (e.g., client has moved to new subnet) or client’s lease as expired |
| DHCPDECLINE | Client to server indicating network address is already in use. |
| DHCPRELEASE | Client to server relinquishing network address and cancelling remaining lease. |
| DHCPINFORM | Client to server, asking only for local configuration parameters; client already has externally configured network address. |
Table 2： DHCP message
- 客戶端在本地物理子網上廣播DHCPDISCOVER消息。該消息的選項可能會包含網絡地址和租期時間的建議值。BOOTP中繼器可能會在非相同物理子網上將消息傳遞給DHCP服務器。
- 對應服務器可能會回覆一個DHCPOFFER消息，該消息在‘yiaddr’字段包含一個可用的網絡地址（並且在‘options’字段包含其他配置參數）。服務器不需要保存已提供的網絡地址，當分配一個新的地址時，服務器應該檢查已經提供的網絡地址沒有在使用；比如，服務器會使用ICMP echo請求來探測已提供的地址。服務器應該這樣做，以便網絡管理員可以選擇不去探測新分配的地址。必要情況下，服務器使用BOOTP中繼器來傳輸DHCPOFFER消息給客戶端。
- 客戶端從一個或多個服務器接收到一個或多個DHCPOFFER消息。客戶端可以選擇等待多路的響應。基於DHCPOFFER消息中提供的配置參數，客戶端從中選擇的服務器，然後廣播一個DHCPREQUEST消息，該消息必須攜帶‘server identifier’選項來表明它所選擇的服務器，並且可能包含其他選擇來指明所需要的配置值。‘被請求的IP地址’選擇必須被設爲服務器發送的DHCPOFFER消息‘yiaddr’字段的值。DHCPRREQUEST消息通過DHCP/BOOTP中繼器被廣播和中繼。爲了保證所有的BOOTP中繼器都會轉發DHCPREQUEST消息給接收初始DHCPDISCOVER消息的同一組DHCP服務器，所有DHCPREQUEST消息必須使用DHCP消息頭部‘secs’字段相同的值，並且被髮送到和初始DHCPREQUEST消息一樣IP廣播地址。如果沒有接收到DHCPOFFER消息，客戶端將會超時並重傳DHCPDISCOVER消息。
- 服務器接收來自客戶端的DHCPREQUEST消息廣播。那些沒有被選中的服務器，通過DHCPREQUEST消息得知他們被客戶端拒絕。被選中的服務器爲客戶端提交與永久存儲的綁定，並且以DHCPACK消息回覆，該消息包含發送請求的客戶端配置參數。在任何DHCP消息中，客戶端ID或‘chaddr’和分配的網絡地址的組合，爲客戶端的租期構成了一個唯一的ID，並同時被客戶端和服務器用於分辨一個相關的租期。DHCPACK消息裏的任何配置參數都不應該和那些在早先DHCPOFFER消息裏的相互衝突。服務器在這裏不應該檢查分配的網絡地址。DHCPACK消息裏的‘yiaddr’字段此時被選中的網絡地址填充。
如果選中的服務器無法滿足DHCPREQUEST消息的要求，比如請求的網絡地址已經被分配了，服務器應該以一個DHCPACK消息回覆客戶端。
一個服務器可以在DHCPOFFER消息中標記提供給客戶端的網絡地址爲不可用。如果該服務器沒有從該客戶端接收到DHCPREQUEST消息，則應該在DHCPOFFER消息中將提供給客戶端的地址標記爲可用。 - 客戶端接受攜帶配置參數的DHCPACK消息。客戶端應該對參數執行最終的檢測，比如使用ARP對分配的網絡地址進行檢測，並且註明DHCPACK消息中指定的租期時間。在這裏，客戶端就被配置了。如果客戶端探測到地址已經被使用了，比如通過ARP探針，客戶端必須發送DHCPDECLINE消息給服務器，並重新開始配置的過程。在循環的情況下，在重新開啓配置過程之前，客戶端應該等待至少10s，以避免造成網絡過載。
如果客戶端接收到DHCPDECLINE消息，則直接重新開始配置過程。
如果客戶端既沒有接收到DHCPACK消息，也沒有接收到DHCPDECLINE消息，則會等待超時，並根據重傳算法重新傳輸DHCPREQUEST。客戶端應該選擇重傳DHCPREQUEST足夠多次，來儘可能聯繫服務器，以免導致客戶端（以及客戶端的使用者）在放棄連接之前等待過長時間。選擇重發的客戶端可能重複發送四次，即總的延遲60s。如果在使用重傳算法之後（即四次重發）仍沒有收到DHCPACK和DHCPNAK消息，客戶端會返回到初始狀態並重啓初始化過程。客戶端應該通知使用者，初始化過程已經失敗並重新開啓。 - 客戶端可以通過向服務器發送DHCPRELEASE消息來放棄它在一個網絡地址上的租期。客戶端通過在DHCPRELEASE消息裏面標明它的‘client identifier’或‘chaddr’以及網絡地址，來表明該租期已經被釋放，注意該‘client identifier’必須和獲取該租期時所使用的保持一致。
3.2 客戶端-服務器交互——重用一個之前分配的網絡地址
如果客戶端記得並想要重用一個之前分配的網絡地址，它可以選擇去忽略一些上述的步驟，比如客戶端廣播DHCPDISCOVER消息和服務器回覆DHCPOFFER消息的步驟，以及服務器回覆DHCPACK的步驟。圖4中的時序圖展示了在典型的客戶端-服務器交互中，一個客戶端重用之前分配的網絡地址的時序圖。
- 客戶端在它的子網上廣播DHCPREQUEST消息。消息包含‘requested IP address’項中的客戶端網絡地址。由於客戶端還沒有收到它的網絡地址，所以‘ciaddr’項不能填充數據。BOOTP中繼器在相同的子網上將消息傳遞給DHCP服務器。如果客戶端曾使用‘client identifier’來獲取它的地址，客戶端必須在DHCPREQUEST消息中使用相同的‘client identifier’。
- 攜帶客戶端配置參數的服務器以DHCPACK消息回覆客戶端。服務器不應該檢查客戶端的網絡是否已使用；此時，客戶端可以迴應ICMP echo請求。（也就是說，在這裏DHCP服務器直接回復DHCPACK消息，而不去主動進行檢查，但是可以通過客戶端對ICMP Echo Request的響應，來進行探測。）如果客戶端你的請求是無效的，比如客戶端已經移動到新的子網絡），服務器應以DHCPNAK回覆客戶端。如果服務器不能保證它的新的是準確的，那麼它不應該回復。比如，如果服務器檢測到一個對已過期綁定的請求，而該綁定是屬於另一個服務器的，那麼它就不應回覆DHCPNAK，除非使用一個明確的機制來在服務器之間維持一致性（coherency）。
如果DHCPREQUEST消息中‘giaddr’爲0x0，那麼客戶端和服務器分佈在一個子網中。服務器廣播DHCPNAK消息的廣播地址必須爲0xffffffff，因爲客戶端可能沒有正確的網絡地址或子網掩碼，並且可能沒有正在響應ARP請求。此外，服務器必須發送DHCPNAK消息給‘giaddr’字段所記錄的BOOTP中繼器的IP地址。相應的，中繼器將會直接轉發消息給客戶端的硬件地址，這樣一來，即使客戶端被移動到一個新的子網，DHCPNAK也能被傳送到。 - 客戶端接受到攜帶配置信息的DHCPACK消息，然後會對參數進行最終的檢查，並且說明在消息中指定的租期時長。該指定的租期被‘client identifier’或‘chaddr’和網絡地址含蓄的定義。在這裏，客戶端被配置了
如果客戶端檢測到DHCPACK中的IP地址已經被使用，客戶端必須發送一個DHCPDECLINE消息給服務器，並且通過請求一個新的網絡地址來重啓配置過程。這一操作和DHCP狀態圖中客戶端移至初始狀態時相對應。
如果客戶端接受到DHCPNAK消息，那麼它無法重用它所記憶的網絡地址。相反，它必須通過重啓配置過程來請求一個新的地址，這一次使用上述章節中的非簡化過程來獲得配置。
如果客戶端沒有收到DHCPACK或DHCPNAK消息，則它需要等待超時，並根據重傳算法來重新傳輸DHCPREQUEST消息。客戶端應該選擇重傳DHCPREQUEST足夠多次，來儘可能聯繫服務器，以免導致客戶端（以及客戶端的使用者）在放棄連接之前等待過長時間。選擇重發的客戶端可能重複發送四次，即總的延遲60s。如果在使用了重傳算法重傳之後，客戶端仍沒有收到DHCPACK和DHCPNAK消息，則它可能爲他未過期租期的餘下時間選擇使用之前配置的網絡地址和配置參數（續約行爲一般發生在租期的1/4,1/2,3/4處，所以可以繼續使用原來的配置）。 - 客戶端可以通過發送DHCPRELEASE消息給服務器來主動放棄它在某一網絡地址上的租期，該租期通過DHCPRELEASE消息中的‘client identifier’或‘chaddr’和網絡地址來識別。
注意：在客戶端本地保持它的網絡地址的情況下，它不能正常的通過一個優雅的關閉行爲（graceful shutdown）來放棄它的租期。只有在客戶端明確需要放棄它的租期的情況下，比如客戶端移至其他子網，客戶端纔會發送DHCPRELEASE消息。
3.3 時間值的解釋和表示
客戶端獲取一個確定週期的一個網絡地址租期（也可能是無限）。在整個協議中，時間都是以秒爲單位來表示。0xffffffff的時間值被保留代表無限。
由於客戶端和服務器可能不會同步時鐘，所以時間值在DHCP消息中以相對時間來表示，在客戶端的本地時鐘中來解釋。以秒爲單位表示的相對時間長度是一個32位無符號整型，範圍從0s到大約100年，已經滿足使用DHCP進行計量的要求。
上述章節中給出的租期時間解釋的算法，是建立在客戶端和服務器時鐘彼此相對穩定的基礎上的。如果在兩個時鐘之間有漂移，服務器可能在客戶端之前認爲租約過期。爲了補償這一點，服務器可能回覆一個比提交給本地客戶端數據庫更短的租約時間給客戶端。
3.4 使用外部配置的網絡地址獲得參數
如果客戶端通過一些其他的手段獲得了一個網絡地址（比如手動設置），它可是使用DHCPINFORM請求消息來獲取其他的本地配置參數。接收到DHCPINFORM消息的服務器使用任何適合該客戶端的配置參數來構造DHCPACK消息，但不包括以下信息：分配一個新地址、檢查已存在的綁定、填充‘yiaddr’字段或包含租期時間參數。服務器應該向DHCPINFORM消息中提供的地址單播DHCPACK消息。
服務器應該對DHCPINFORM消息中的網絡地址進行相容性檢測，但不能對已存在的租期進行檢查。服務器爲發出請求的客戶端組織包含配置參數的DHCPACK消息，並且直接將消息發送給客戶端。
3.5 DHCP中的客戶端參數
並不是所有客戶端在初始化時都需要附錄A中所列出的所有參數。有兩種技術被用於減少從服務器傳送給客戶端的參數。
- 大多數從服務器傳送到客戶端的參數在本地都有定義在Host Requirement RFCs中的默認值；如果客戶端沒有從服務器接收到可以重寫該默認值的參數，則會使用這些默認值。
- 在初始化的DHCPDISCOVER和DHCPREQUEST消息中，客戶端可以向服務器提供一系列它感興趣的指定參數。如果客戶端在DHCPDISCOVER消息中包含了一系列參數，那麼他在所有後續的DHCPREQUEST消息中都必須包含該系列參數。
客戶端應包含‘maximum DHCP消息長度’選項來讓服務器知道應該構建多大的DHCP消息報文。回覆給客戶端的參數可能仍然超出在DHCP消息中分配給options字段的空間。在這種情況下，兩種額外的選項標誌位（該標誌位必須出現在消息的‘options’字段）標誌着‘file’和‘sname’字段將被用於選項設置。
通過包含‘parameter request list’字段，客戶端可以告知服務器哪些配置參數是客戶端感興趣的。該選項的這部分數據，明確列出了以標籤號排序的被請求的數據。
此外，客戶端可以在DHCPDISCOVER消息中提議想要的網絡地址和租期時間。客戶端可以在‘requested IP address’選項中來提議分配一個特定的IP，並在‘IP address lease time’字段中提議一個想要的租約時間。在配置參數中其他表現“暗示”的選項在DHCPDISCOVER或DHCPREQUEST消息中也是被允許的。然而，額外的選項可能被服務器忽略，因此多種路由器可能不會爲一些選項返回完全一致的值。‘requested IP address’選項只在客戶端校驗之前獲取的網絡參數的時候，在DHCPREQUEST消息中被填充。只有在BOUND、RENEWING或REBINDING狀態下，客戶端被一個IP地址正確配置時，客戶端會填充‘ciaddr’字段。
如果服務器接收到一個攜帶無效‘requested IP address’信息的DHCPREQUEST消息，服務器應該給客戶端返回一個DHCPNAK消息，並且可能選擇向系統管理員反饋這個問題，並可能在‘message’選項中包含錯誤信息。
3.6 帶有多路接口的客戶端中DHCP的使用
帶有多路網絡接口的客戶端必須爲每一個接口獨立的使用DHCP服務，去爲這些單獨的接口獲取配置信息參數。
3.7 客戶端何時使用DHCP
每當本地網絡參數可能發生變化時，客戶端應該使用DHCP服務去重新獲取或校驗它的IP地址和網絡參數，比如系統啓動時或從本地網絡斷開之後，因爲本地網絡配置可能在客戶端或用戶不知情的情況下發生改變。
如果客戶端擁有一個之前分配的網絡地址，並且無法連接到本地的DHCP服務器，客戶端可以繼續使用該網絡地址，直到該地址的租約過期。
如果租約在客戶端能夠聯繫到服務器之前過期，客戶端必須立刻停止使用該網絡地址，並告知用戶該問題。
4 DHCP客戶端-服務器協議規範
4.1 構造和發送DHCP消息
DHCP客戶端和服務器都通過在固定格式的消息字段裏填充以及在變長選項區域裏附加標籤數據來構造DHCP消息。選項區域首先包含衣蛾四字節的‘magic cookie’，接着是選項字段。最後的選項必須是end。
DHCP使用UDP作爲它的傳輸協議。從客戶端至服務器的DHCP消息從‘DHCP server’端口（67）發送，從服務器到客戶端的DHCP消息從‘DHCP client’端口（68）發送。具有多個網絡地址的服務器（比如一個多連接的主機），可以在發送的DHCP消息中使用它任意的網絡地址。
‘server identifier’字段在DHCP消息中被用於識別DHCP服務器，也在從客戶端到服務器的消息中作爲目標地址。具有多個網絡地址的服務器，必須準備好在DHCP消息中去接收它的任意一個網絡地址來識別該服務器。爲了適應潛在的不完全的網絡連接，服務器必須選擇一個能夠被客戶端獲得的地址作爲‘server identifier’。比如，如果DHCP客戶端和服務器連接到相同的子網（比如，在來自客戶端的消息中‘giaddr’字段爲0），服務器應該選擇它用於該子網通信的IP地址作爲‘server identifier’。如果服務器在該子網上也使用多個IP地址，那麼其中任意地址都是可用的。如果服務器從一個DHCP中繼器接收到消息，服務器應該從接收消息的接口選擇一個地址作爲‘server identifier’（除非服務器由其他更好的信息來幫助做出選擇）。DHCP客戶端必須使用‘server identifier’選項提供的IP地址作爲發送給DHCP服務器的單播請求的地址。
在客戶端獲取IP地址之前被該客戶端廣播的DHCP消息，必須讓IP頭部的源地址設爲0.
如果來自客戶端的DHCP消息中‘giaddr’消息不爲0，那麼服務器將所有的回覆消息發送到‘giaddr’字段中地址所指的BOOTP中繼器的‘DHCP server’端口。如果‘giaddr’字段爲0且‘ciaddr’不爲0，那麼服務器將向給‘ciaddr’字段中的地址單播DHCPOFFER和DHCPACK。如果‘giaddr’字段爲0且‘ciaddr’爲0，並且廣播位被設置，那麼服務器向0xffffffff廣播DHCPOFFER和DHCPACK消息。如果廣播爲沒有被設置，且‘giaddr’和‘ciaddr’爲0，那麼服務器將向客戶端的硬件地址和‘yiaddr’地址單播DHCPOFFER和DHCPACK消息。在所有情況下，當‘giaddr’爲0，那麼服務器會將所有DHCPNAK消息廣播到0xffffffff。
如果DHCP消息中的options擴展至‘sname’和‘file’字段，那麼‘option overload’選項必須出現在‘options’字段中，限定值爲1,2或3，如RFC 1533中定義。
在一個‘option’標籤中傳遞的值可能太長而無法填入單個option的可用的255字節中（比如，在‘router’選項中的一系列路由器）。選項可能只出現一次，除非在選項文檔中有其他的說明。客戶端將同一個選項的多個實例的值連接在一個配置使用的單參數列表中。
DHCP客戶端負責所有的消息重傳。客戶端必須使用包含一個隨機指數退避算法的重傳策略，來決定兩次重傳之間的時間延遲。該延遲的選擇應該基於客戶端和服務器之間網絡的特性，允許服務器的回覆有充分的時間被傳遞。比如，在10Mb/s以太網中，第一次重傳之前的延遲應該是4s被-1到1之間選擇的均勻隨機數隨機化處理後的值。第二次重傳之前的延遲應該是8s被-1到1之間選擇的均勻隨機數隨機化處理後的值。重傳延遲在接下來每一次重傳中都被加倍，直至最大值64s。客戶端可以提供一個重傳嘗試的指示給用戶，作爲配置過程進展的指示。
‘xid’字段被客戶端用於匹配接收到的攜帶待定請求的DHCP消息。
通常情況下，DHCP服務器和BOOTP中繼器嘗試使用單播方式直接將DHCPOFFER、DHCPACK和DHCPNAK消息傳遞給客戶端。目的IP地址在DHCP消息的‘yiaddr’字段設置，連接層目的地址在DHCP消息的‘chaddr’字段設置。然而，一些客戶端實現無法在一個有效IP地址被完全配置之前接收這樣的單播IP地址（這導致一個死鎖，即客戶端在被配置一個IP地址前無法接收IP地址）。
一個在其協議棧軟件被IP地址配置前無法接收單播IP數據報的客戶端，應該在其發送 的任何的DHCPDISCOVER和DHCPREQUEST消息中，設置‘flags’字段的BROADCAST位爲1。BROADCAST位將會爲DHCP服務器和BOOTP中繼器在客戶端所在子網發送向客戶端的所有廣播信息提供線索。而一個可以在其協議棧被設置之前接收單播IP數據包的客戶端應該講BROADCAST位清零。BOOTP說明文檔討論了這種對BROADCAST位使用的區別。
4.2 DHCP服務器管理控制
DHCP服務器不需要對它接收到的所有DHCPDISCOVER和DHCPREQUEST消息做出響應。比如，網絡管理員可以選擇配置DHCP服務器只對先前通過外部機制配置的客戶端做出響應。DHCP規則只描述當客戶端和服務器選擇去交互時，二者之間的交互；描述所有的系統管理可能使用到的管理控制，是超出DHCP規範範圍的。指定的DHCP服務器實習可以包含任意的被網絡管理員所需要的控制或策略。
在一些環境中，在爲一個指定的客戶端確定正確參數的時候，DHCP服務器會不得不考慮在DHCPDISCOVER或DHCPREQUEST消息中包含的供應商類選項的值。
DHCP服務器需要使用一些唯一的標識來講客戶端和他的租約聯繫在一起。客戶端可以選擇通過‘client identifier’選項明確的提供該標誌符，如果這樣，該客戶端必須在接下來的所有消息中都是用統一的‘client identifier’，並且服務器必須使用該標識符來確定該客戶端。在客戶端被連接到‘client identifier’選項的子網中，使用一個唯一標誌符對DHCP客戶端來說是很重要的。使用‘chaddr’字段作爲唯一標識符可能引起一些意想不到的結果，因爲該標識符可能和一個可以被移動到一個新子網的硬件接口綁定。一些網站選擇使用一個供應商的序列號作爲‘client identifier’，來避免由於硬件接口在計算機之間的轉移導致的客戶端網絡子網的意想不到的變化。
DHCP客戶端可以在它接收DHCPOFFER消息的服務器中，自由的使用任何策略進行選擇。DHCP的客戶端實現應提供一種機制爲用戶來直接選擇’vendor class identifier’值。
4.3 DHCP服務器行爲
DHCP服務器基於該客戶端當前的綁定狀態來處理接收自該客戶端的DHCP消息，可以接收的消息如下：
- DHCPDISCOVER
- DHCPREQUEST
- DHCPDECLINE
- DHCPRELEASE
- DHCPINFORM
表3給出了服務器對消息中這些字段和選項的使用。本節的餘下部分描述了DHCP服務器對任意可能接收的消息的處理。
4.3.1 DHCPDISCOVER消息
當服務器從客戶端接收一個DHCPDISCOVER消息，服務器爲發送請求的客戶端選擇一個網絡地址。如果無可用地址，服務器可以選擇項系統管理員報告該問題。如果有可用地址，新的地址應該按照如下規則：
- 選擇記錄在客戶端當前綁定中的當前地址，或者
- 如果該地址在服務器的地址池中並且沒有被分配，選擇記錄在客戶端綁定中的前一個地址，或者
- 如果該地址有效並且沒有被分配，選擇在‘Requested IP Address’選項中請求的地址，或者
- 選擇一個服務器可用地址池中的一個新地址；改地址基於消息被接收的源子網（如果‘giaddr’爲0）或者基於轉發該消息的中繼器的地址（如果‘giaddr’不爲0）。
如4.2所描述，處於管理的原因，服務器可以分配一個與請求的地址不一致，或在空餘地址有效的情況下，拒絕給指定客戶端分配地址。
注意，在一些網絡結構中（比如，在分配給一個物理網段不住一個IP子網的網絡中），可能存在這種情況，DHCP客戶端應該從一個與‘giaddr’字段記錄的地址不同的子網中分配一個地址。因此，DHCO不要求客戶端從‘giaddr’的子網中分配地址。服務器可以自由選擇一些其他子網，並且DHCP規範不描述被IP地址如何被分配和選擇的方式。
雖然不要求DHCP的正確操作，但是服務器不應該在客戶端回覆服務器的DHCPOFFER請求之前重用選擇的網絡地址。服務器可以選擇記錄提供給客戶端的地址。
服務器也必須爲租期選擇一個超時時間，如下：
- 如果客戶端沒有在DHCPDISCOVER消息中請求一個指定的租期，並且客戶度已經擁有一個已分配的網絡地址，那麼服務器返回前一個給該地址分配的租期超時時間（注意，客戶端必須明確請求一個指定的租期來在分配的前一個地址的基礎上延長超時時間），或者
- 如果客戶端沒有在DHCPDISCOVER消息中請求一個指定的租期，並且客戶度沒有一個已分配的地址，服務器分配一個本地配置的默認租期時間，或者
- 如果客戶端在DHCPDISCOVER消息中請一個指定的租期（不考慮客戶端是否有一個已分配的地址），服務器可以選擇返回一個請求的租期（如果租期對於本地策略是可接受的），或者選項一個其他的租期。
表3 Fields and options used by DHCP servers
| 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 DHCPDISCOVER message | ’xid’ from client DHCPDISCOVER message | ’xid’ from client DHCPDISCOVER message |
| ’secs’ | 0 | 0 | 0 |
| ’ciaddr’ | 0 | ’ciaddr’ from DHCPREQUEST or 0 | 0 |
| ’yiaddr’ | IP address offered to client | IP address assigned to client | 0 |
| ’siaddr’ | IP address of next bootstrap server | IP address of next bootstrap server | 0 |
| ’flags’ | ’flags’ from client DHCPDISCOVER message | ’flags’ from client DHCPREQUEST message | ’flags’ from client DHCPREQUEST message |
| ’giaddr’ | ’giaddr’ from client DHCPDISCOVER message | ’giaddr’ from client DHCPREQUEST message | ’giaddr’ from client DHCPREQUEST message |
| ’chaddr’ | ’chaddr’ from client DHCPDISCOVER message | ’chaddr’ from client DHCPREQUEST message | ’chaddr’ from client DHCPREQUEST message |
| ’sname’ | Server host name or options | Server host name or options | (unused) |
| ’file’ | Client boot file name or options | Client boot file name or options | (unused) |
| ’options’ | options | options | |
| Requested IP address | MUST NOT | MUST NOT | MUST NOT |
| IP address lease time | MUST | MUST (DHCPREQUEST) MUST NOT (DHCPINFORM) | MUST NOT |
| 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 |
一旦網絡地址和租期被確定，服務器使用提供的配置參數構造DHCPOFFER消息。不管客戶端選項了哪個服務器，對於所有DHCP服務器來說，回覆同樣的參數來確保可以預測的客戶端行爲是很重要的。配置參數必須溢出如下的策略，按照給定的順序來進行選擇。網絡管理員負責配置多個DHCP服務器來確保來自他們的統一的響應。
- 網絡地址的選擇，如上述章節所述
- 超時時間的選擇，如上述章節所述
- 客戶端請求參數的選擇，依據如下規則：
- 如果服務器對某參數有一個明確的默認配置的值，則服務器必須在‘options’字段中的合適的選項中包含該值，或者
- 如果服務器認爲該參數是Host Requirements Document中定義的參數，則服務器必須在‘options’字段的合適的選項中，包含該參數在Host Requirements Document中給定的默認值，或者
- 服務器不能爲該參數返回一個值，必須提供儘可能多的請求的參數，並且必須忽略不可提供的參數。除非在DHCP選項和BOOTP供應商擴展文檔中明確被允許，服務器必須包含每個請求的數據僅一次。
- 任何現存綁定中與Host Requirements Document默認值不一樣的參數，
- 任何指定給該客戶端的參數，比如被網絡管理員配置的參數，
- 任何指定給該客戶端類的參數，比如被網絡管理員配置的；該參數必須被一個明確的匹配所識別，該匹配是客戶端服務器類標識符與客戶端類之間的，並能在服務器中識別的匹配。
- 在客戶端子網中沒有默認值的參數
服務器可以選擇返回在DHCPOFFER消息中用於決定參數的’vendor class identifier’來幫助客戶端選擇接收哪一個DHCPOFFER。服務器將DHCPDISCOVER消息中的‘xid’字段插入DHCPOFFER消息的‘xid’字段中，並且發送DHCPOFFER消息給請求的客戶端。
4.3.2 DHCPREQUEST消息
DHCPREQUEST消息可以來自於客戶端響應服務器的DHCPOFFER消息，或者來自客戶端驗證之前分配的IP地址，或者來自客戶端爲一個網絡地址延遲租期。如果DHCPREQUEST包含一個‘server identifier’選項， 則該消息是響應DHCPOFFER消息的。
客戶端發送的DHCPREQUEST消息如下：
在SELECTING狀態下產生的DHCPREQUEST消息：
客戶端在‘server identifier’字段插入選中服務器的地址，‘ciaddr’字段必須爲0，‘requested IP address’必須被選中的DHCPOFFER字段的yiaddr數值填充。
注意，客戶端可以選擇去手機數個DHCPOFFER消息並選擇最佳的offer。如果客戶端沒有接收到可接受的offer，可以選擇重新發送DHCPDISCOVER消息。由於服務器沒有基於DHCPOFFER提交任何網絡地址分配，服務器可以在接下來的請求中自由的重用提供的網絡地址。但是根據實現細節，服務器不應該重用已提供的網絡地址，並且可以使用一個實現指定的超時機制，來決定何時重用一個已提供的地址。在INIT-REBOOT狀態下產生的DHCPREQUEST消息
‘server identifier’字段必須不能被填充，‘requested IP address’選項必須被客戶端之前分配的地址填充。‘ciaddr’必須爲0.客戶端需要驗證一個之前分配的、緩存的配置。如果‘requested IP address’不正確，或者出在錯誤的自王忠，服務器應該發送DHCPNAK消息給客戶端。
通過檢測‘giaddr’的內容、’requested IP address’選項和一個數據庫查詢，確定處於INIT_REBOOT狀態的客戶端是否處於正確的網絡中。如果檢測到客戶端處於錯誤網絡中，服務器應該發送DHCPNAK消息給客戶端。如果網絡是正確的，DHCP服務器應該檢查客戶端IP地址的意義是否正確。如果不是，服務器應該發送DHCPNAK給客戶端。如果服務器沒有記錄該客戶端，那麼它必須保持靜默，並且可以發送一個警告給網絡管理者。這一舉動對於爆出同一線路上互相沒有溝通的服務器之間保持和平共處非常必要。
如果DHCPREQUEST消息的‘giaddr’爲0，那麼客戶端和服務器是在一個子網上的。因爲客戶端可能沒有正確的網絡地址或子網掩碼，或者客戶端肯無法響應ARP請求，所以服務器必須向0xffffffff廣播DHCPNAK消息。
如果DHCPREQUEST消息的‘giaddr’被設置爲1，客戶端和服務器則在不同的子網。服務器必須設置DHCPACK消息的廣播位爲1，一遍中繼器廣播DHAPNAK給客戶端，原因同上一段所述。在RENEWING狀態產生的DHCPREQUEST消息：
‘server identifier’不能被填充，‘requested IP address’選項不能被填充，‘ciaddr’必須被客戶端IP地址填充。在這種情況下，客戶端是被完全配置的，並且嘗試去延長它的租期。該消息將會被單播，所以沒有中繼器會參與他的傳輸。因此，‘giaddr’不會被填充，DHCP服務器會信任‘ciaddr’的值，並且在回覆客戶端時使該值。
客戶端可以選擇在T1之前更新或擴展他的租約。服務器可以選擇不去延長該租期，但是應該仍然回覆DHCPACK消息。- 在REBINDING狀態下產生的DHCPREQUEST：
‘server identifier’和’requested IP address’不能被填充，‘ciaddr’必須被客戶端IP地址填充。在這種情況下，客戶端被完全配置，並且嘗試去延長它的租期。消息必須被廣播到0xffffffffIP廣播地址。DHCP服務器應該在回覆DHCPREQUEST消息之前檢查‘ciaddr’的正確性。
4.3.3 DHCPDECLINE消息
如果服務器接收到一個DHCPDECLINE消息，那麼該客戶端已經通過其他方式發現所建議的網絡地址已經被使用。服務器必須標記該網絡地址爲不可用，並且應該通知本地系統管理員這個可能的配置問題。
4.3.4 DHCPRELEASE消息
收到DHCPRELEASE消息時，服務器標記該網絡地址爲未分配。在對後續的該客戶請求的響應中，服務器應該爲可能的重用保持一個該客戶端初始化參數的記錄。
4.3.5 DHCPINFORM消息
服務器通過直接向DHCPINFROM消息中的‘ciaddr’字段中給定地址發送DHCPACK消息，來響應DHCPINFROM消息。服務器不能發送租期超時時間給客戶端，也不能填充‘yiaddr’字段。服務器在DHCPACK消息中包含如4.3.1所定義的其他參數。
4.3.6 客戶端消息
表4詳細說明了在不同狀態下來自客戶端的區別。
表4 Client messages from different states
| INIT-REBOOT | SELECTING | RENEWING | REBINDING |
|---|---|---|---|
| broad/unicast | broadcast | broadcast | unicast |
| server-ip | MUST NOT | MUST | MUST NOT |
| requested-ip | MUST | MUST | MUST NOT |
| ciaddr | zero | zero | IP address |
4.4 DHCP客戶端行爲
圖5給出了DHCP客戶端的狀態轉移圖。客戶端可以從服務器接收到以下消息：
- DHCPOFFER
- DHCPACK
- DHCPNAK
DHCPINFORM消息沒有列出。客戶端簡單的發送DHCPINFORM消息並且等待DHCPACK消息的回覆。一旦客戶端選擇了它的參數，它就完成了配置過程。
表5給出了客戶端對DHCP消息中字段和選項的使用。
4.4.1 網絡地址的初始化和分配
客戶端開始於INIT狀態並構造DHCPDISCOVER消息。一開始，客戶端應該隨機等待1到10s，以便DHCP的使用不同步。客戶端設置‘ciaddr’爲0x00000000。客戶端可以通過包含‘parameter request list’選項來請求指定的參數，可以通過包含‘requested IP address’和’IP address lease time’選項來建議一個網絡地址和/或租期事件。如果對DHCP回覆消息的傳遞有必要，客戶端必須在‘chaddr’字段包含它的硬件地址。客戶端可以在’client identifier’選項包含不同的唯一標識符。如果客戶端在DHCPDISCOVER消息中包含一列請求的參數，那麼它在後續的所有消息中都必須包含該列表。
客戶端產生和記錄一個隨機的事務標識符，並且將該標識符插入‘xid’字段。客戶端記錄自己的本地時間用於之後租期過期的計算。隨後，客戶端從本地硬件地址廣播DHCPDISCOVER消息給0xffffffff廣播IP地址和‘DHCP server’UDP端口。
如果一個到達的DHCPOFFER消息不匹配最近發送的DHCPDISCOVER消息的‘xid’字段，則該DHCPOFFER消息必須被靜默丟棄。對應任何到達的DHCPACK消息必須被靜默丟棄。
客戶端在一定週期內收集DHCPOFFER消息，並從進來的DHCPOFFER消息選擇一個（比如，可能是第一個DHCPOFFER消息，或者之前使用的服務器的DHCPOFFER消息），然後從DHCPOFFER消息的‘server identifier’選項中提取服務器地址。客戶端收集消息的時間和用於選擇一個DHCPOFFER消息的機制是依據實現的。
表5: Fields and options used by DHCP clients
| Field | DHCPDISCOVER DHCPINFORM | DHCPREQUEST | DHCPDECLINE,DHCPRELEASE |
|---|---|---|---|
| ’op’ | BOOTREQUEST | BOOTREQUEST | BOOTREQUEST |
| ’htype’ | (From “Assigned Numbers” RFC) | ||
| ’hlen’ | (Hardware address length in octets) | ||
| ’hops’ | 0 | 0 | 0 |
| ’xid’ | selected by client | ’xid’ from server DHCPOFFER message | selected by client |
| ’secs’ | 0 or seconds since DHCP process started | 0 or seconds since DHCP process started | 0 |
| ’flags’ | Set ’BROADCAST’ flag if client requires broadcast | Set ’BROADCAST’ 0 | Set ’BROADCAST’ flag if client requires broadcast |
| ’ciaddr’ | 0 (DHCPDISCOVER) client’s network address (DHCPINFORM) | 0 or client’s network address (BOUND/RENEW/REBIND) | 0 (DHCPDECLINE) client’s network address (DHCPRELEASE) |
| ’yiaddr’ | 0 | 0 | 0 |
| ’siaddr’ | 0 | 0 | 0 |
| ’giaddr’ | 0 | 0 | 0 |
| ’chaddr’ | client’s hardware address | client’s hardware address | client’s hardware address |
| ’sname’ | options, if indicated in ’sname/file’ option; otherwise unused | options, if indicated in ’sname/file’ option; otherwise unused | (unused) |
| ’file’ | options, if indicated in ’sname/file’ option; otherwise unused | options, if indicated in ’sname/file’ option; otherwise unused | (unused) |
| ’options’ | options | options | (unused) |
| Requested IP address | MAY (DISCOVER) MUST NOT (INFORM) | MUST (in SELECTING or INIT-REBOOT) MUST NOT (in BOUND or RENEWING) | MUST (DHCPDECLINE),MUST NOT (DHCPRELEASE) |
| IP address lease time | MAY (DISCOVER) MUST NOT (INFORM) | MAY | MUST NOT |
| Use ’file’/’sname’ fields | MAY | MAY | MAY |
| DHCP message type | DHCPDISCOVER/DHCPINFORM | DHCPREQUEST | DHCPDECLINE/DHCPRELEASE |
| Client identifier | MAY | MAY | MAY |
| Vendor class identifier | MAY | MAY | MAY |
| Server identifier | MUST NOT | MUST (after SELECTING) MUST NOT (after INIT-REBOOT, BOUND, RENEWING or REBINDING) | MUST |
| Parameter request list | MAY | MAY | MUST NOT |
| Maximum message size | MAY | MAY | MUST NOT |
| Message | SHOULD NOT | SHOULD NOT | SHOULD |
| Site-specific | MAY | MAY | MUST NOT |
| All others | MAY | MAY | MUST NOT |
如果參數是可接受的，客戶端記錄從‘server identifier’西段提供參數的服務器的地址，並且在一個DHCPREQUEST廣播消息的‘server identifier’字段發送該地址。一旦來自服務器的DHCPACK消息到達，客戶端即被初始化並切換至BOUND狀態。客戶端記錄租期超時時間，該時間是初始請求被髮送和DHCPACK消息中租期的時間的總和。客戶端應該對建議的地址進行檢查以確保該地址沒有被使用。例如，如果客戶端處於支持ARP的網絡中，它可以爲建議的地址發送一個ARP請求。當爲建議的地址廣播一個ARP請求時，客戶端必須在它自己的硬件地址上填充發送者的硬件地址，並設發送者的IP地址爲0，來避免迷惑同一子網中其他主機的ARP緩存。如果該網絡地址顯示出正在使用，客戶端必須發送DHCPDECLINE消息給服務器。客戶端應該廣播一個ARP響應來聲明客戶端的新IP地址，並且清除客戶端子網的主機上所有過期的ARP緩存入口。
4.4.2 使用已知的網絡地址初始化
客戶端開始於INIT-REBOOT狀態，併發送DHCPREQUEST消息。客戶端必須將它已知的網絡地址插入DHCPREQUEST消息的’requested IP address’選項。客戶端可以通過包含’parameter request list’選項來請求指定的配置參數。客戶端產生和記錄一個隨機的事務標識符，並插入該標識符到‘xid’字段。客戶端記錄自己的本地時間用於之後租期過期的計算。客戶端不能在DHCPREQUEST消息中包含‘sever identifier’字段。客戶端隨後在本地硬件廣播地址向‘DHCP server’UDP端口廣播DHCPREQUEST消息。
一旦‘xid’字段與客戶端DHCPREQUEST消息該字段相匹配的DHCPACK消息從任意服務器到達，客戶端即被初始化，並跳轉至BOUND狀態。客戶端記錄租期超時時間，該時間是初始請求被髮送和DHCPACK消息中租期的時間的總和。
4.4.3 使用外部分配的網絡地址初始化
客戶端發送DHCPINFORM消息。客戶端可以通過包含’parameter request list’選項來請求指定的配置參數。客戶端產生和記錄一個隨機的事務標識符，並插入該標識符到‘xid’字段。客戶端將它自身的網絡地址填充進‘ciaddr’字段。客戶端不應該請求租約超時參數。
如果知道服務器的地址，客戶端隨後會向DHCP服務器單播DHCPINFORM消息，否則它會向該有限的廣播地址廣播該消息。DHCPINFORM消息必須針對‘DHCP server’UDP端口發送。
一旦一旦‘xid’字段與客戶端DHCPREQUEST消息該字段相匹配的DHCPACK消息從任意服務器到達，客戶端即被初始化。
如果在合理的時間週期內（60s，或者如果使用4.1所建議的超時時間，即4次嘗試）客戶端沒有收到DHCPACK消息，那麼它應該展示一個消息通知問題的用戶，然後應該使用合適的默認值（依據附錄A）來開始網絡處理。
4.4.4 廣播和單播的使用
除非知道DHCP服務器的地址，DHCP客戶端廣播DHCPDISCOVER, DHCPREQUEST and DHCPINFORM消息。客戶端單播DHCPRELEASE消息給客戶端。由於客戶端拒絕服務器提供的IP地址的使用，所以客戶端廣播DHCPDECLINE消息。
在INIT或REBOOTING狀態下，但客戶端知道DHCP服務器的地址，客戶端可以在DHCPDISCOVER或DHCPREQUEST消息使用該地址，而不是使用IP廣播地址。客戶端也可以使用單播去發送DHCPINFORM消息給一個已知的DHCP服務器。如果客戶端沒有接收到發送給已知DHCP服務器的響應，它將轉而使用IP廣播地址。
4.4.5 再獲取和過期
客戶端保維護兩個時間，T1和T2，用於指定在何時客戶端應嘗試延遲在其網絡地址上的租期。T1是客戶端進入RENEWING狀態，並嘗試聯繫初始給客戶端分配網絡地址的服務器的時間。T2是客戶端進入REBINDING狀態，並嘗試聯繫任何服務器的時間。T1必須早於T2，而T2必須早於客戶端租期過期的時間。
爲避免需要同步時鐘，T1和T２在選項中以相對時間表達。
在T1時刻，客戶端轉到RENEWING狀態，併發送（通過單播）衣蛾DHCPREQUEST消息給服務器來延遲它的租期。客戶端設置DHCPREQUEST消息的‘ciaddr’字段爲其當前網絡地址。客戶端記錄DHCPREQUEST消息被髮送的本地時間，用於計算租期超時時間。客戶端不能再DHCPREQUEST消息消息中包含‘server identifier’。
任何到達的DHCPACK消息，如果其‘xid’字段和客戶端DHCPREQUEST消息的‘xid’字段不匹配，都將被靜默拋棄。當客戶端從服務器接收到DHCPACK消息，客戶端計算租期超時時間，該時間是客戶端發送DHCPREQUEST消息消息加上DHCPACK消息中的租期時長。客戶端成功重新獲取它的網絡地址，將回到BOUND狀態，並可以繼續網絡處理。
如果在T2時刻之前，沒有DHCPACK消息到達，客戶端將會轉到REBINDING狀態，並且發送（通過廣播）DHCPREQUEST消息來延遲它的租期。客戶端將其當前網絡地址填充到DHCPREQUEST消息‘ciaddr’字段，並且不能再該消息中包含‘server identifier’。
時刻T1和T2被服務器通過選項配置。T1默認值爲（0.5*duration_of_lease）。T2默認值爲（0.875*duration_of_lease）。時刻T1和T2應該選擇一個固定值附近隨機波動後的值，來避免客戶端重獲取的同步問題。
客戶端可以選擇在T1時刻之前刷新或延遲它的租期。服務器可以選擇根據網絡管理員設定的策略延遲客戶端的租期。服務器返回T1和T2，並且考慮到租期餘下的時間，他們的值應該根據他們的原始值進行調整。
在RENEWING和REBINDING狀態，如果客戶端沒有接收到DHCPREQUEST消息，在重傳DHCPREQUEST消息之前，客戶端應該等待餘下一半的時間直至T2（在RENEWING狀態下），或等待餘下一半時間（在REBINDING狀態下），直至將至最小的60s。
如果在客戶端接收到DHCPACK之前租期過期，客戶端會轉到INIT狀態，必須立即停止任何其他的網絡處理，並且像尚未初始化時那樣請求網絡初始化參數。如果客戶端接收到DHCPACK分配給他之前的網絡參數，那麼客戶端應繼續網絡處理。如果客戶端被給予一個新的網絡地址，它不能繼續使用前一個網絡地址，並且應該像本地用戶通知該問題。
4.4.6 DHCPRELEASE
如果客戶度不再需要使用它被分配的 網絡地址（比如，客戶端正常關機），客戶端會發送DHCPRELEASE消息給服務器。注意，DHCP的正確操作不依賴與DHCPRELEASE消息的傳輸。