DHCP協議 動態主機配置協議

動態主機配置協議(Dynamic Host Configuration Protocol，DHCP)在TCP/IP網絡上使客戶機獲得配置信息的協議，它是基於BOOTP協議，並在BOOTP協議的基礎上添加了自動分配可用網絡地址等功能。這兩個協議可以通過一些機制互操作。

DHCP向網絡主機提供配置參數，它由兩個基本部分組成：一部分是向網絡主機傳送專用的配置信息，另一部分是給主機分配網絡地址。DHCP是基於客戶/服務器模式的，這種模式下，專門指定的主機分配網絡地址，傳送網絡配置參數給需要的網絡主機，被指定的主機稱爲服務器。我們以後將提供DHCP服務的主機稱爲服務器，把接收信息的主機稱爲客戶。不能隨便誰都可以成爲DHCP服務器，這需要管理員進行人爲指定。由於網絡中硬件和軟件的多樣性，使得任何一臺主機隨便響應DHCP請求的問題得到了解決，如果有一臺機器可以隨便響應的話，它也無法給用戶提供正確的配置參數，而配置TCP/IP協議的參數又那麼多，因此使得這種任意的響應成了不可能的事情。而分佈式地分配網絡地址要使用一些機制來防止地址重用，但是由於是分佈式分配，有時真是防不勝防，無法從根本上杜絕網絡地址衝突的問題。

DHCP支持三種IP地址分配方法。第一種是自動分配，DHCP給用戶分配一個永久的IP地址。第二種是動態分配，在這種情況下，用戶可以取得一個IP地址，但是是有時間限制的。第三種是手工分配，在這種方法下，用戶的IP地址是由管理員手工指定的，這種情況下，DHCP服務器只需要將這個指定的IP地址傳送給用戶即可。至於用什麼樣的分配方法，不同的網絡各不相同。

動態分配是唯一一種允許自動重用地址的機制。因此，這種方法對於有臨時上網用戶，而且網絡的IP地址資源又不是多得沒法用的時候特別有用。而手工指定對於管理不希望使用動態IP地址的用戶十分方便，不會因爲手工指定而和DHCP衝突或和別的已經分配的地址衝突。這裏的關鍵希望大家能夠理解，DHCP是一種相對集中式的管理方式。

DHCP信息包的格式是基於BOOTP包格式的，這使得BOOTP客戶可以訪問DHCP服務器。DHCP中使用了BOOTP的轉發代理，這樣就避免了在每個物理網段都設一個DHCP服務器的情況。

有許多協議與DHCP的功能相似，也同時爲DHCP提供服務。反向地址解析協議（Reverse Address Resolution Protocol，RARP）用於發現網絡地址和自動IP地址分配。小文件傳輸協議（Trivial File Transfer Protocol，TFTP）用於從啓動服務器傳送啓動鏡象。Internet控制信息協議（Internet Control Message Protocol，ICMP）用於向主機發送有關附加路由器信息。ICMP還被用於傳送子網掩碼信息和其它信息。主機也可能通過ICMP的路由尋找功能定位路由器 。BOOTP是用於傳送配置信息的方法，它是可擴展的，正式的擴展在一些配置參數中定義。麻省理工學院的Athena工程中使用的網絡信息協議（Network Information Protocol，NIP）採用分佈式動態IP地址分配。資源定位協議（Resource Location Protocol，RLP）提供了高層服務定位。由於Sun公司不喜歡工作站在啓動時的漫長過程，所以使用了RARP，TFTP和遠程過程調用（RPC）機制，並稱之爲"bootparams"，這種機制是用來爲無硬盤主機傳送配置信息和操作系統代碼。一些Sun網絡也在使用動態RARP（DRARP）和自動安裝機制使新加入的主機自動配置。

在其它一些相關的工作中，路徑最小傳輸單元（MTU）尋找算法使得尋找MTU的大小成爲了可能。地址解析協議（Address Resolution Protocol，ARP）也被用於一種傳輸協議進行資源和定位和選擇。

DHCP是用於向客戶傳送配置信息的，客戶從DHCP服務器那裏獲得配置信息後應該可以和Internet上任何一臺主機通信。TCP/IP協議棧參數請在本文後面尋找。在初始化一臺主機時並不需要配置所有這些參數，客戶和服務器可以通過一種商討機制決定傳送哪些參數。DHCP允許（不要求）客戶參數配置不直接與IP協議相關，而且它也不將最加入的主機加入域名系統（DNS）中。

有一些名詞需要解釋一下，DHCP客戶和DHCP服務器已經在前面說過了，這裏就不再說明了。BOOTP轉發代理或轉發代理是一臺Internet主機或路由器，它用於在DHCP客戶和DHCP服務器間傳送配置信息。綁定是一些配置參數，它至少應該包括IP地址，綁定由DHCP服務器管理。

DHCP的設計目標如下：

1．DHCP應該是一種機制而不是策略，它必須允許本地系統管理員控制配置參數，本地系統管理員應該能夠對所希望管理的資源管理進行有效地管理。

2．客戶不需要進行手工配置，客戶應該在不參與的情況下發現合適於本地機的配置參數，並利用這些參數加以配置。

3．不需要對單個客戶配置網絡。在通常情況下，網絡管理員沒有必須輸入任何預先設計好的用戶配置參數。

4．DHCP不需要在每個子網上要一個服務器，爲了經濟的原因，它DHCP服務器必須可以和路由器和BOOTP轉發代理一起工作。

5．DHCP客戶必須可能對多個DHCP服務器提供的服務作出響應。出於網絡穩定與安全的考慮，有時需要爲網絡加入多個DHCP服務器。

6.DHCP必須靜態配置，而且必須以現存的網絡協議實現。

7．DHCP必須能夠和BOOTP轉發代理互操作。

8．DHCP必須能夠爲現有的BOOTP客戶提供服務。

　

下面幾個設計目標是對於網絡層參數的設計而言的，在網絡層參數上，DHCP必須可以做到以下幾點：

9．不允許有幾個客戶同時使用一個網絡地址。

10．在DHCP客戶重新啓動後仍然能夠保留它原先的配置參數，如果可能，客戶應該被指定爲相同的配置參數。

11．在DHCP服務器重新啓動後仍然能夠保留客戶的配置參數，如果可能，即使DHCP機制重新啓動，也應該能夠爲客戶分配原有的配置參數。

12．能夠爲新加入的客戶自動提供配置參數。

13．支持對特定客戶永久固定分配網絡地址。

　

在下面我們看一下DHCP的具體問題。從客戶的觀點來看，DHCP不過是BOOTP的擴展。這樣就可以使現有的BOOTP用戶在不進行任何改動的情況下使用DHCP。圖一和表一描述了DHCP信息包的格式和信息包內每個字段的意義。請注意括號內的數字，它表示此字段的大小。我們老是提到BOOTP，它和DHCP的主要區別有兩點，一點是DHCP對客戶分配網絡地址時不是無限期的，第二點是DHCP在提供網絡地址時還提供了其它配置參數。熟悉BOOTP協議的可以對比一下兩個協議的不同點。下圖定義了DHCP消息格式：

DHCP定義了一個新的“客戶標識”選項，它是用來顯式地將客戶標識傳送給DHCP服務器的。這個改變是針對BOOTP信息包中'chaddr'域即作爲BOOTP轉發信息的硬件地址又作爲用戶信息的情況而進行的。這個標記對於DHCP服務器來說沒有什麼意義，它可以是硬件地址，也可以是什麼別的東西，反正只要是對於這個DHCP服務器管理的每個子網段內的客戶是唯一的就可以了。客戶一旦在一個信息包中使用了這個選項，以後的信息包內的這個選項必須和第一次使用時一致，這樣DHCP服務器纔可以正確地辨識客戶。

　

域	字節	描述
op	1	消息op代碼/消息類型1 = BOOTREQUEST, 2 = BOOTREPLY
htype	1	硬件地址類型
hlen	1	硬件地址長度
hops	1	客戶需要將這一項設置爲零，當通過轉發代理啓動時可以供轉發代理使用。
xid	4	操作ID，這是一個隨機數，用於客戶和服務器之間同步消息和消息的響應。
secs	2	由客戶指定的時間，指的是開始地址獲取和更新進行後的時間。
flags	2	請參閱圖2。
ciaddr	4	用戶IP地址，此字段僅當用戶處於BOUND,RENEW或REBINDING狀態和能夠響應ARP請求時使用。
yiaddr	4	客戶IP地址
siaddr	4	用於bootstrap過程中的IP地址
giaddr	4	轉發代理IP地址
chaddr	16	客戶硬件地址
sname	64	可選的服務器主機名
file	128	啓動文件名
options	不定	可選的參數字段

options字段的長度不定，DHCP客戶可能會從服務器那裏接收到長度大於576字節的包。DHCP客戶也可以使用最大DHCP包長度字段要求服務器傳送的包長度在一定限度之內。在客戶使用DHCP進行配置的時候，DHCP需要使用TCP/IP軟件，在配置好IP地址之前，TCP/IP軟件應該能夠接收並轉發發送到客戶硬件地址上的IP包；DHCP服務器和BOOTP轉發代理在TCP/IP軟件未配置好之前不能向未接收硬件單播報文的客戶傳送DHCP消息。如果客戶在TCP/IP軟件未能配置好之前實在不能接收IP單播報文，DHCP可以使用“標記”域進行工作。請注意下圖中的那個B，它代表廣播標記。至於這個標記的具體內容，我們在文章的後面幾節內討論。至於其它各位，它們是保留的，它們的值只能由客戶設置爲0。服務器和轉發代理不會理會這一字段的內容。

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|B| 全爲0 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

B: 廣播標記位

上圖表示了標記位的格式。前面已經提到過了，DHCP的一個重要功能就是能夠向客戶提供網絡配置參數，這種存儲模型實際上就是DHCP服務爲每個客戶保存了一個關鍵字，這個關鍵字中保存了保存了用戶特有的標記和客戶的配置參數。關鍵字可能是一個二元組（IP子網號，硬件地址），這種設計考慮到不同子網內的硬件地址可能是一樣的，所以要加入一個子網號加以區別。當然關鍵字也可以是（IP子網號，主機名），這是爲了照顧客戶機會經常在不同子網間轉換，或者經常改變物理地址的情況。在協議規定是，關鍵字需要是（IP子網號，物理地址），當然了，如果客戶在信息包中顯式地應用了“客戶標記”這一字段的話就不這樣使用了。客戶可以通過查詢DHCP服務器取得配置信息。

DHCP的另外一個重要特點就是能夠動態地分配網絡地址，這種動態分配的機制是很簡單的：客戶會要求使用某一網絡地址一段時間，服務器就對客戶說：“好的，在這一段時間內，這個地址我不給別人。”當客戶使用完這一地址後再次申請時，服務器總是優先將它使用過的地址再次分配給它。我們把這種分配稱爲一種“租用”。說到租用，當然了，客戶也可以要求增加租用期，當客戶不再使用這一地址時，它就把它還給服務器。客戶也可以要求永久租用，這個永久對可不是永遠，當服務器覺得客戶機可能已經不存在時，它可以再次把這一地址分配給別的機器使用。當網絡內地址不夠用的時候，永久的分配就不可能了，當地址不夠用的時候，由客戶歸還的地址還要被繼續使用，這幾乎是人人都可以想得到的，服務器可以使用配置信息庫內的信息幫助它決定分配哪一個地址，比如說它可以選擇最近最少使用的地址進行分配。爲了安全起見，服務器應該在分配前使用ICMP協議進行探測，保證這個地址沒有機器使用，客戶也應該能夠使用一些協議（如ARP）探測新接收的地址是不是被人使用。

下面我們來說一下服務器客戶協議的內容。DHCP使用BOOTP消息格式，這種格式請見表1和圖1。在每個由客戶發送到服務器消息的'op'字段中包括了一個BOOTREQUEST，而在服務器發送到客戶消息內的'op'字段則包括了一個BOOTREPLY。DHCP信息包內'options'字段包含了十進制數99，130，83和99，這幾個值。其餘的地方是稱爲“選項”的標記參數。有幾個參數定義也沒幾天，大家應該注意其中的一個重要的選項“DHCP消息類型”選項，這一項必須在每個DHCP信息包中存在，其它的選項有的是必須的，有的不是必須的，有的根本就是可有可無。在下文中，消息格式就以這一選項的內容決定。

在下面的表2和圖3中描述了DHCP協議包中信息的意義以及DHCP客戶與服務器交換信息的流程圖。下面我們就過程簡述如下：

1. 客戶會首先進行廣播，它要地址當然是它先開口，它在本子網段內廣播一個DHCPDISCOVER消息，這個消息內可能包括了它希望租用的網絡地方和租用時間。BOOTP轉發代理可以將這個消息傳送到不在這個網段內的DHCP服務器上。

2. 每個有空閒地址的DHCP服務器都響應這個消息，在響應消息中包括了可用的地址，這個地址在消息的'yiaddr'字段中，其它的配置參數在DHCP選項中。服務器無需要保留已經分配的地址，雖然這樣可能想起來更有效率。在分配時，因爲未保留已經分配的地址，服務器必須想辦法知道這個地址未被別的客戶使用，服務器可以使用ICMP協議的迴應請求進行。在分配地址時，服務器有時候可能需要使用BOOTP轉發代理，這一點要在實現上給予支持。下表是各種消息及其應用：

　

消息 功能

------- ---

DHCPDISCOVER - 客戶進行廣播以確定本地可用的服務器。

DHCPOFFER - 服務器給客戶的應答，在其中包括了配置參數。

DHCPREQUEST - 此消息是客戶發送給服務器的，作用有三個：客戶從一臺服務器上請求配置信息（在這個時候客戶也就拒絕了其它服務器發來的地址，客戶就用這個地址了）；在系統重新啓動後，客戶利用這個消息確認原來分配的網絡地址仍然有效；客戶還可以腹這個地址對特定的網絡地址租用時間要求延期。

DHCPACK - 服務器發向用戶的消息，包括了配置參數和網絡地址。

DHCPNAK - 服務器發向用戶的消息，告知客戶當前使用的網絡地址無效或租期已滿。

DHCPDECLINE - 客戶發向服務器的消息，告知服務器此地址已被使用。

DHCPRELEASE - 客戶發向服務器的消息，告知服務器此地址不再使用。

DHCPINFORM - 客戶發向服務器的消息，要求服務器發送本地配置信息，客戶已經配置好了網絡地址，不需要再發送網絡地址了。

3. 客戶將會接收到一個或多個服務器發來的地址和配置參數。客戶可以不用那麼急於迴應哪一個地址，它也可以挑的。當選擇好了以後，客戶廣播DHCPREQUEST消息，在這個消息中的“服務器標記”字段中必須包括選定的服務器的標記，此消息中也可以包括希望獲得的網絡配置參數，而“請求IP地址”選項則要填寫服務器發來信息包中'yiaddr'的內容，也就是服務器給客戶提供的IP地址。DHCPREQUEST消息在本網段廣播，並通過DHCP/BOOTP轉發代理向不同網段轉發。如果客戶在規定時間內沒有收到任何服務器的迴應，它會再次發送DHCPDISCOVER。

　

4. 許多服務器會接收到DHCPREQUEST廣播，那些沒有被選擇的服務器將DHCPREQUEST視爲拒絕包。那個被選擇的服務器會記錄這個地址已經有人用了，並以包含配置參數的DHCPACK包返回給客戶。“客戶標記”字段和指定的網絡地址用以唯一確定一個客戶。服務器發送的DHCPACK包內的參數不應該和原來發送的DHCPOFFER包內的內容有衝突，服務器也不在這時再次檢測提供的網絡地址，在DHCPACK包內的'yiaddr'字段包括了選擇的網絡地址。如果被選的主機不能滿足DHCPREQUEST包內的要求，它應該以DHCPNAK包回覆。服務器可以將DHCPOFFER包內包括的地址設置爲不可用，也可以不設置，但是如果服務器沒有從客戶那兒接收到DHCPREQUEST包，此地址一定要保證是可用的。

5. 客戶接收到包括配置參數的DHCPACK包，它應該對此參數進行最後一次檢查，不要和人家的衝突了，當沒有發現衝突時客戶纔算真正配置好了。如果客戶發現有人已經使用了這個地址，它需要向服務器發送DHCPDECLINE包，並重新開始配置過程，當然了，客戶機必須等待一段時間後才能進行重要的配置過程，如果緊接着就進行會對網絡造成巨大的壓力。不但在地址衝突的時候要重新開始配置過程，在接收到DHCPNAK包時也要進行重要配置過程。如果超時而未接收到DHCPACK或DHCPNAK包，客戶需要再次發送DHCPREQUEST。當然這個發送的過程要有一定的時間，不要人家服務器還沒接收到呢，這邊就放棄了。如果重新發送後還是沒有收到DHCPACK或DHCPNAK包，客戶要返回初始狀態，並通用用戶，初始化過程失敗，正在重新開始。

6. 客戶可以通過發送DHCPRELEASE包取消租用。客戶在消息中放置“客戶標記”或”chaddr”和網絡地址。如果客戶在租用的時候使用了“客戶標記”，在取消租用的時候必須還使用這一標記項。

如果客戶希望再次使用過去使用過的網絡地址，客戶就不需要進行上面說的一些步驟，對老客戶的服務要方便一些嗎。下面的時間圖就能夠幫助您理解這一過程。

1. 客戶在自己的子網裏廣播一個DHCPREQUEST消息，在此消息的“請求IP地址”選項中包括了客戶現在的網絡地址。（這裏要注意一點，如果客戶目前沒有網絡地址，'ciaddr'域絕對不能填寫）。BOOTP轉發代理把這個消息發送到不在同一子網內的DHCP主機上。如果客戶當時申請租用地址的時候使用了“客戶標記”，這個新發的包內也必須使用相同的“客戶標記”，說自己是老客戶總要有證據。

2. 這個時候服務器已經知道客戶是個老客戶，也知道了它的配置參數，就返回一個DHCPACK消息。此時服務器不負責檢查網絡地址是否已經被使用，這個工作要客戶自己完成。既然說自己是老客戶了，那有些事情自己辦了。

如果客戶的請求無效（可以客戶已經移到另外一個子網內了），服務器應該以DHCPNAK返回，如果服務器不能確認發送到的消息是否準確，它乾脆什麼都不返回。我們可以想象一個，如果一個服務器接收到一個應該屬於別的服務器管理的網絡地址，它就不要返回DHCPNAK包了，自己不知道的事情就不要說不。

如果包內的'giaddr'域爲零說明客戶和服務器處於同一子網內，服務器不會輕信這樣的好事的，它會發向0xffffffff發送廣播，它擔心這個客戶已經離開這個子網，或者它的子網掩碼不正確，即使客戶接收到了這個消息，也不需要發送ARP。如果服務器知道客戶不在這個子網內，它只需要按照'giaddr'內記錄的地址發送一個消息給BOOTP轉發代理就是了，轉發代理會將服務器發送的包發到客戶手中，即使客戶此時已經處於新的子網中了。

3. 客戶接收了帶配置參數的DHCPACK信息，客戶最後對參數進行檢查，標記了租用時間。指定的租用時間由包內的“客戶標記”或'chaddr'字段確定，這時客戶也就配置好了。如果客戶檢測到地址衝突，客戶必須以DHCPDECLINE包通知服務器並重新開始請求網絡地址。如果客戶接收到DHCPNAK包，它不能再使用當前地址了，它必須重新開始配置過程以獲得新的網絡地址。如果客戶既然沒有收到DHCPACK或DHCPNAK，它必須重新發送DHCPREQUEST包以進行配置。客戶應該在一定時間再次發送DHCPREQUEST請求。在地址沒有過期的時候，如果客戶既沒有收到DHCPACK或DHCPNAK，客戶可以繼續使用這個地址及相應的參數。

4. 客戶可能通過DHCPRELEASE包取消租用。在這個取消的包中包括了“客戶標記”或'chaddr'和網絡地址。

　

客戶租用某一地址是有時間限制的，當然也可以是無期限限制的。在整個DHCP中，時間的單位是秒，而0xffffffff表示無限。在分佈式系統中有一個重要的問題就是時間的同步，服務器和客戶的時間可能是不同步的，爲了實現時間的同步，要靠在一定時間內發送DHCP包以客戶本地時間來表示。這個時間是由一個無符號的32位數表示，它可以表示0到100年，這對於現行的系統來說夠用了。在上面的圖中，我們假定時間是同步的，如果兩者時間上有一點差別，服務器可以給客戶發一個把租期稍微延長一點，這樣就可以了。

如果客戶通過別的手段獲得了網絡地址，它可以使用DHCPINFORM請求獲得其它配置參數，服務器接收到DHCPINFORM包，並建立一個DHCPACK消息，在其中包括一些合適客戶的配置參數，只是不包括分配網絡地址，檢查現有的綁定，在信息中不填充'yiaddr'字段或租用時間參數。服務器取得DHCPINFORM包內的'ciaddr'地址，而返回DHCPACK包。

並不是所有客戶需要初始化所有在附表內的參數。有兩種方法可以減少服務器到客戶發送參數的數目。客戶可以使用默認參數，如果服務器不發送任何參數，客戶就使用默認參數。第二種方法是讓客戶在DHCPDISCOVER和DHCPREQUEST包內給服務器發送一個自己覺得合適的參數表，讓服務器在這個表中選擇，如果客戶在DHCPDISCOVER內使用了這個表，在其後的DHCPREQUEST包內也要包括這個列表。客戶應該包括“最大DHCP包大小”選項使服務器預先知道DHCP消息的大小。而返回客戶的參數有可能超過給DHCP包分配的空間。在這種情況下，兩個額外的選項標記指示'file'和'sname'域可以用做選項使用。客戶在發送到服務器的包內指示自己希望得到哪一個參數項。當然客戶也可以自己把希望得到網絡地址和租用時間包括在包內發送到包內，這樣就減少了服務器發向客戶的數據量，這是因爲服務器是中心結點，如果它的處理速度下降會影響到整個網絡的性能。其它一些選項也可以在包內使用，但是服務器可能不理會這些消息，在多個服務器響應的時候，返回的值可能根本就不一樣。當客戶確認自己獲得的網絡地址時，“請求的IP地址”項可以僅在DHCPREQUEST包內包括。當客戶處於BOUND，RENEWING或REBINDING狀態而正確配置了IP地址時，客戶可以填充'ciaddr'域。如果服務器接收到一個包括無效請求地址的“請求的IP地址”包時，服務器應該向客戶返回DHCPNACK包，如果需要可以向管理員報告。如果客戶有多個網絡接口，各個接口必須獨立地以DHCP方式獲得自己的配置參數。

下面我們來介紹一下何時客戶應該使用DHCP協議，客戶在本地網絡參數發生改變時應該使用DHCP，例如在系統重新啓動時或在與網絡失去聯繫一段時間之後，本地網的參數可以在用戶不知情的情況下發生改變。如果客戶（機）還記得住自己的IP地址而且無法聯繫本地的DHCP服務器，它可以繼續使用這一地址，直到租期到期爲止，如果在地址失效前客戶（機）仍然不能聯繫到DHCP服務器，在租期過期時，它應該立即放棄對此網絡地址的使用，並通過用戶。

在下面，我們要具體介紹一下DHCP協議的客戶/服務器協議內容，這裏我們假設服務器有一些可供使用的地址，使用這些地址可以滿足客戶對地址的需求。每個服務器也支持一個分配的地址的數據庫及租用情況。

而在建立和傳送DHCP消息的問題上，DHCP客戶和服務器都向消息中的特定字段填充來建立DHCP消息。選項區域包括頭四個字節的'magic cookie'，在其後是選項，而最後的選項必須是'end'選項。DHCP使用UCP協議傳送信息，服務器方接收此消息的端口是端口67，而客戶在端口68接收服務器方面的消息。如果服務器有多個網絡地址，它可以使用其中任何一個來傳送DHCP消息。“服務器標記”字段用於DHCP服務器發送的DHCP消息，也用於客戶來確定服務器。如果服務器有多個網絡地址，那麼多哪個地址來的請求它也不應該拒絕。爲了照顧到網絡使用的實際情況，服務器必須選擇一個地址來專門接收客戶發送來的請求。比如一個服務器和客戶處於同一個子網，服務器應該使用這個子網內的地址作爲“服務器標記”使客戶便於發送請求。同樣客戶也應該使用提供的“服務器標記”向特定的服務器發送請求。如果客戶還沒有獲得網絡地址，在客戶發向服務器的請求包中的IP地址一欄中應該被設備爲0。

如果在DHCP消息中的'giaddr'域不爲0，服務器就會向'giaddr'中指示的BOOTP轉發代理髮送。如果'giaddr'爲0，而'ciaddr'不爲0，服務器將DHCPOFFER和DHCPACK發向'ciaddr'中指示的地址。如果'giaddr'和'ciaddr'爲0，而廣播域被設置，應該將返回信息廣播，也就是向0xffffffff發送。如果廣播域也未被設置，那隻好向客戶的硬件地址發送了。無論發生何種情況，只要'giaddr'爲0，服務器都應該廣播DHCPNAK信息。

如果在DHCP信息中的選項擴展到了'sname'和'file'域，在“選項”域中必須有'option overload'選項。如果'option overload'在'options'中出現，那出現的選項必須以'end'選項結束，不足的地方以特定的填充字符填充。客戶在接收到相應的選項，如果有相同的選項，客戶將它們變爲一個。

DHCP客戶全權負責消息的再次傳送。客戶必須採用一種算法來決定採用何種算法來選擇隔多長時間再次發送。這個時間要選擇的合適，不要服務器的應答還沒有來，客戶就不煩麻而重新發送了，說起來容易，實際上還是很即使做到的，因爲網絡的結構與性能都是不好預測的。機器在重新發送前可以通知用戶。

通常情況下，DHCP服務器和BOOTP轉發代理試圖把DHCPOFFER，DHCPACK和DHCPNAK直接傳送給客戶。IP目的地址被設備在DHCP 'yiaddr'域內，而數據鏈路層地址設置在'chaddr'域內。但是，請注意，如果客戶還沒有設置IP時，它不會接收這種傳送的。這樣的客戶需要在發送給客戶的包內將廣播位設置爲1，這樣服務器和轉發代理就會在客戶所在子網內廣播這個消息。如果能夠直接接收，就不要爲網絡造成不必要的負擔，不要採用廣播的形式了。

如果客戶要求廣播，服務器和轉發代理應該向IP廣播地址發送這個包。如果客戶未要求廣播，則直接使用IP協議傳送就是了，這時需要使用'yiaddr'域內的IP地址和'chaddr'域內的數據鏈路層地址。

DHCP服務器不必理會所有的請求，管理員可以對服務器採用嚴格的管理機制，只對這個網絡中註冊的客戶響應。本文是討論服務器理會的客戶和服務器之間的關係。服務器在爲客戶服務時必須保留客戶的唯一標記，客戶可以直接在發送的請求包內設置“客戶標記”域，這樣服務器和客戶的所有消息中都必須包括這個唯一的標記，也靠這個標記來識別客戶。如果客戶未使用這個域，服務器使用'chaddr'域來達到唯一標記的目的，但這樣做可能會有意想不到的結果，因爲這個域一般和網絡適配器相關，是硬件地址，這個適配器卻可以被別的客戶使用，這時候事情就壞了。有時候可以選擇DNS名和一個客戶相關，這時候網絡就是被分配給DNS域而不是一個硬件單元。而客戶在識別服務器方面就沒這麼麻煩了，反正從誰那兒用都一樣。

DHCP服務器的動作要視客戶的響應而定，服務器可能從客戶那兒接收如下幾種包：

o DHCPDISCOVER

o DHCPREQUEST

o DHCPDECLINE

o DHCPRELEASE

o DHCPINFORM

　

下面我們就開始看一下服務器對各種消息的響應。

　

當服務器接到DHCPDISCOVER時，服務器爲客戶選擇一個網絡地址，如果沒有可用的網絡地址了，服務器需要把這個情況向管理員報告。如果有可用地址，新地址要麼是客戶現在使用的地址；要麼是客戶原來使用的，現在還未被分配給別的客戶使用；要麼是客戶在“請求的IP地址”選項標記的地址，而且這個地址還未被分配給別的客戶使用；要麼這個地址是根據客戶所在網段分配的，要麼是根據轉發代理進行分配的。那當然，有時候因爲管理的原理，服務器即使有空閒的地址也不會分配給未經過授權的用戶，或許還會爲用戶指定一個地址，即使這個客戶未提出任何申請。在一些網絡結構中，特別是是分網段的結構中，DHCP客戶會得到一個不是本網段地址的網絡地址，這是正常的。在沒有接收到客戶對DHCPOFFER的迴應以前，服務器不得將這個地址給別的客戶使用。

　

下面是服務器選擇租用時間的規則：

　

o 如果客戶未在DHCPDISCOVER內要求延長租用時間（或指定租用時間），服務器返回先前指定給此地址的最小的租用時間。（請注意：客戶必須顯式地要求對以前租用的地址租用時間延期），要不然的話

o 如果客戶未在DHCPDISCOVER內要求租用時間，而且用戶還未有網絡地址，就返回本地配置的默認租用時間，要不然的話

o 如果用戶在DHCPDISCOVER包內要求了租用時間（這時就不要管用戶是不是已經分配網絡地址了），服務器要麼答應它，要麼爲它選擇另外的租用時間。

　

域	DHCPOFFER	DHCPACK	DHCPNAK
'op'	BOOTREPLY	BOOTREPLY	BOOTREPLY
'htype'	請參閱其它資料，這裏不做討論
'hlen'	硬件地址字節長度
'hops'	0	0	0
'xid'	同用戶DHCPDISCOVER內的'xid'	同用戶DHCPDISCOVER內的'xid'	同用戶DHCPDISCOVER內的'xid'
'secs'	0	0	0
'ciaddr'	0	0或同DHCPREQUST內的’ciaddr’	0
'yiaddr'	提供給客戶的IP地址	提供給客戶的IP地址	0
'siaddr'	下一個BOOTSTRAP服務器地址	下一個BOOTSTRAP服務器地址	0
'flags'	同用戶DHCPDISCOVER內的'flags'	同用戶DHCPDISCOVER內的'flags'	同用戶DHCPDISCOVER內的'flags'
'giaddr'	同用戶DHCPDISCOVER內的'giaddr'	同用戶DHCPREQUEST內的'giaddr'	同用戶DHCPREQUEST內的'giaddr'
'chaddr'	同用戶DHCPDISCOVER內的’chaddr’	同用戶DHCPREQUEST內的’chaddr’	同用戶DHCPREQUEST內的’chaddr’
'sname'	服務器名或選項	服務器名或選項	未使用
'file'	客戶啓動文件名或選項	客戶啓動文件名或選項	未使用

　

　

一旦決定了網絡地址和租用時間，服務器要發出帶有配置參數的DHCPOFFER。對於配置參數的考慮要取決於以下規則： 網絡地址和租用時間的決定前面已經說過了，這裏就不再哆嗦了。而其它配置參數要符合：

　

-- 如果服務器對某一選項已經有顯式指定的值，必須使用這個值，如果沒有顯式指定這樣的值

-- 如果服務器發現有“主機需求文檔”中定義的參數，服務器返回的信息中必須包括這樣的值，如果沒有定義這樣的數

-- 服務器不返回此參數的值

　

服務器必須提供儘可能多的配置參數，而且通常情況下一個參數只出現一次。

　

DHCPREQUEST消息可能來自客戶對DHCPOFFER的響應。如果在DHCPREQUEST內包括“服務器標記”選項，此消息是對DHCPOFFER的響應；否則可是對延長租期的確認。在DHCPACK內的參數不得和DHCPOFFER內的參數衝突，客戶也應該使用DHCPACK內的參數進行配置。

客戶在下面幾種情況下發送DHCPREQUEST。

o DHCPREQUEST在SELECTING狀態產生：

客戶將選擇的服務器填充在“服務器標記”，而'ciaddr'必須爲0，“請求的IP地址”必須和發送來的DHCPOFFER內的yiaddr值一致。一定要注意，客戶在接收到多個DHCPOFFER之後會選擇一個自己認爲最合適的，客戶需要在DHCPREQUEST中指出它選擇了哪一個服務器。服務器有可能根本收不到響應，因此在DHCPOFFER時，服務器並未分配這個地址，它可以用這個地址響應其它用戶的請求。

o DHCPREQUEST在INIT-REBOOT狀態產生：

“服務器標記”不填，“請求的IP地址”填充原先指定的網絡地址， 'ciaddr'必須爲0。客戶是爲了確認原來獲得的地址和參數，如果地址，或參數，或網絡不對，服務器應該發送DHCPNAK。如果服務器內沒有客戶的資料，它就保持沉默，或給網絡管理員發出警告。如果DHCPREQUEST內的'giaddr'是0x0，客戶和服務器在同一子網，服務器必須廣播DHCPNAK消息，因爲客戶可能沒有正確的網絡地址或子網掩碼，客戶可能無法響應ARP請求。如果'giaddr'不爲0，客戶和服務器不在同一子網，那麼DHCPNAK中的廣播選項必須設置，以讓轉發代理廣播這一消息。

o DHCPREQUEST在RENEWING狀態產生：

“服務器標記”不填，“請求的IP地址”不填，'ciaddr'內必須填寫客戶的IP地址。在這種情況下客戶已經完成了配置，它不過是想延長租期而已。這個消息是單播的，不需要進行中轉，因此'giaddr'沒用。

o DHCPREQUEST在REBINDING狀態產生：

“服務器標記”不填，“請求的IP地址”不填，'ciaddr'內必須填寫客戶的IP地址。在這種情況下客戶已經完成了配置，它不過是想延長租期而已。這個消息是廣播的，因此它應該發向0xffffffff。

如果服務器接收到DHCPDECLINE消息，客戶已經通過別的方法知道此網絡地址已經由別的計算機使用，服務器應該在此地址上打上標記，並將此情況通知網絡管理員。在接收到DHCPRELEASE消息時，服務器將相應的網絡地址標記爲未分配，同時保留相應的配置參數，因爲客戶很有可能會在不久的將來重新申請這一網絡地址和配置參數。服務器對DHCPINFORM消息的響應是DHCPACK，發送的地址在DHCPINFORM消息的'ciaddr'中包括。服務器對於租用期限和'yiaddr'不填。

　

下面我們說說客戶那邊的情況吧。客戶能夠從服務器接收到的消息也就是幾種：DHCPNCK，DHCPACK，DHCPOFFER。

客戶在所需要的參數和網絡地址都已經在上面說過了，這裏就不再重複了。客戶在發送前產生並記錄一個隨機的操作標記，將這個標記插入'xid'，客戶同時還記錄了本地時間以便計算租期的過期時間。然後它廣播DHCPDISCOVER消息。如果接收到的DHCPOFFER內的'xid'與最近記錄的'xid'不符，這個包就會無迴應地丟棄了。

域	DHCPDISCOVER DHCPINFORM	DHCPREQUEST	DHCPDECLINE DHCPRELEASE
'op'	BOOTREQUEST	BOOTREQUEST	BOOTREQUEST
'htype'	請參閱其它資料。
'hlen'	以字節爲單位的硬件地址長度。
'hops'	0	0	0
'xid'	由客戶選擇	由服務器發送來DHCPOFFER中的’xid’獲得	由客戶選擇
'secs'	0或從DHCP過程開始到現在的時間	0或從DHCP過程開始到現在的時間	0
'flags'	如果客戶要求廣播響應，設置'BROADCAST'	如果客戶要求廣播響應，設置'BROADCAST'	0
'ciaddr'	在DHCPDISCOVER時爲0，在DHCPINFORM時爲客戶的網絡地址	0或客戶的網絡地址	0或客戶的網絡地址
'yiaddr'	0	0	0
'siaddr'	0	0	0
'giaddr'	0	0	0
'chaddr'	客戶的硬件地址	客戶的硬件地址	客戶的硬件地址
'sname'	相應的選項或未使用		未使用
'file'	相應的選項或未使用		未使用
'options'	相應的選項		未使用

　

　

在用戶接收到DHCPACK後，它將請求所使用的時間加上租用時間作爲自己對這個網絡地址的租用時間。這一點請注意。如果在INIT-REBOOT狀態下發送DHCPREQUEST消息，客戶必須要“請求的IP地址”內填上已知的IP地址。

客戶在使用廣播或者是單播的問題上有一個原則，儘量少使用廣播，因爲這會使網絡負擔加重，在知道服務器IP地址的情況下要使用單播，也就是直接向那個地址發送。如果單播不成功，再恢復爲廣播式發送。

　

客戶記錄兩個時間T1和T2，T1是客戶進入RENEWING狀態試圖聯繫分配給客戶IP地址的服務器的時間，T2是客戶進入REBINDING狀態並試圖聯繫服務器的時間。T1必須早於T2。這兩個時間表示爲相對時間，這是爲了避免使用同步時鐘。

在T1時間，客戶進入RENEWING狀態發送DHCPREQUEST要求延期，客戶在DHCPREQUEST消息內設置'ciaddr'域爲當前的網絡地址，並同時記錄發送時的本地時間。返回的DHCPACK包中的'xid'域如果和客戶保留的'xid'域不同，此消息被丟棄。直到接收到兩者一致的包。

DHCP的安全性不高，它在基於UDP和IP協議的，這兩個協議的安全性就不好，而且在開始的時候DHCP協議主要用於無盤站，在這樣的環境中實現密碼十分困難，因此DHCP到現在也是不安全的。非法的服務器和非法的客戶都可能會系統造成危害。

　

下面是主機配置參數：

　

IP-layer_parameters,_per_host:_

　

Be a router on/off HRC 3.1

Non-local source routing on/off HRC 3.3.5

Policy filters for

non-local source routing (list) HRC 3.3.5

Maximum reassembly size integer HRC 3.3.2

Default TTL integer HRC 3.2.1.7

PMTU aging timeout integer MTU 6.6

MTU plateau table (list) MTU 7

IP-layer_parameters,_per_interface:_

IP address (address) HRC 3.3.1.6

Subnet mask (address mask) HRC 3.3.1.6

MTU integer HRC 3.3.3

All-subnets-MTU on/off HRC 3.3.3

Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6

Perform mask discovery on/off HRC 3.2.2.9

Be a mask supplier on/off HRC 3.2.2.9

Perform router discovery on/off RD 5.1

Router solicitation address (address) RD 5.1

Default routers, list of:

router address (address) HRC 3.3.1.6

preference level integer HRC 3.3.1.6

Static routes, list of:

destination (host/subnet/net) HRC 3.3.1.2

destination mask (address mask) HRC 3.3.1.2

type-of-service integer HRC 3.3.1.2

first-hop router (address) HRC 3.3.1.2

ignore redirects on/off HRC 3.3.1.2

PMTU integer MTU 6.6

perform PMTU discovery on/off MTU 6.6

　

Link-layer_parameters,_per_interface:_

Trailers on/off HRC 2.3.1

ARP cache timeout integer HRC 2.3.2.1

Ethernet encapsulation (RFC 894/RFC 1042) HRC 2.3.3

　

TCP_parameters,_per_host:_

TTL integer HRC 4.2.2.19

Keep-alive interval integer HRC 4.2.3.6

Keep-alive data size 0/1 HRC 4.2.3.6

　

Key:

　

MTU = Path MTU Discovery (RFC 1191, Proposed Standard)

RD = Router Discovery (RFC 1256, Proposed Standard)