爲了給網絡客戶機自動分配IP地址以及生成所需的配置參數，IETF分別給IPV4和IPV6網絡定義了相關的協議標準，即DHCP（RFC2131）和DHCPV6(RFC3315)，以及擴充的選項標準。本文主要闡述兩個協議產生的背景、功能並比較二者之間的異同點。
一、背景
DHCP協議的出現可以回推到無盤工作站的出現，人們希望工作站能夠通過網絡通信的方式從服務器中獲得自己的IP地址、服務器的IP地址、啓動映像名等信息，此時Bootstrap協議(簡寫爲BOOTP)應運而生，它主要應用於相對靜態的環境，每臺主機都有一個永久的網絡連接，管理人員只需要建立一個BOOTP配置文件，該文件定義了每臺主機的一組BOOTP參數，由於配置通常保持不變，因此該文件也不會經常改變，但是隨着網絡規模的不斷擴大，網絡配置也變得越來越複雜，原來針對靜態主機配置的BOOTP協議明顯不能滿足實際的需要，由此，爲了用戶能快速地接入和退出網絡，提高IP地址資源的利用率，IETF在BOOTP的基礎上制定了一種自動分配IP地址的機制，即DHCP協議，因此，我們DHCP協議可以看成是對BOOTP協議的升級(所以要想抓DHCP包，必須輸入bootp纔行)。爲了BOOTP協議的兼容，DHCP協議允許三種分配地址的方式，即手工配置，自動配置以及完全動態分配，除此之外，DHCP在原來的基礎上增加了對選項的支持，通過這種方式，可以獲得更多來自於服務器的配置信息。後來，隨着IPV6網絡的出現，以及IPV6地址所表現出來的巨大差異，IETF在2003年重新制定了針對IPV6的DHCP協議，即DHCPV6，對比V4，它增加了一些特有的功能，如支持有狀態和無狀態地址分配服務，支持臨時地址，非臨時地址以及前綴地址的分配等，後面小節將會更加具體比較二者在選項、客戶端與服務器行爲、消息類型的差異。
二、DHCP VS DHCP6
要比較兩個協議，最直觀的方式無非是通過比較二者有關的數據報，圖1與圖2分別對應的是正常情況下二者獲取IP地址的過程示意圖，從圖1中可以看出，客戶端首先利用0.0.0.0地址發送一個一個廣播discover消息，接着多個服務器響應併發回了可供客戶機使用的地址(參照offer消息)，然後客戶機從中選擇某臺服務器並向其發送request消息，最後被選中的服務器返回ACK確認消息，這樣就完成了對客戶機的地址分配。對於圖2，客戶機利用本地鏈路地址發送一個solicit廣播消息(廣播地址是ff02::1:2), 之後一臺服務器提供了advertise消息，並將IP地址以及客戶機所需要的配置參數信息返回，然後客戶機發送一個request消息，主要從服務器端索取自己所需要的請求參數信息，最後服務器響應請求。
圖1 DHCP獲取IP地址過程
圖2 DHCP6獲取IPV6地址過程
從上面這兩個簡單地過程，大體上了解了DHCP與DHCP6在獲取IP地址時的一般過程，也明白了其中的一些差異，下面將從各個方面更加深入地介紹二者之間的差異。
1. DHCP消息VS DHCP6消息
附A顯示了消息報的格式差異，DHCP消息報組成字段的長度及功能如表1所示，對比表2的DHCP6數據報，DHCP消息報字段顯得十分龐大，但是這並不代表，DHCP所支持的功能更多，因爲DHCP6的選項十分豐富，如DHCP中的ciaddr字段所表達的含義在DHCP6中的IA-NA或者IA-TA選項是對應的，類似的還有chaddr字段對應於Client Identifier，這些在後面的選項比較中都會講到。
表1 DHCP數據報字段的長度與功能
|
字段 |
長度（字節爲單位） |
功能 |
|
op |
1 |
定義DHCP消息類型，1爲BOOTREQUEST,2爲BOOTREPLY |
|
htype |
1 |
定義硬件類型，1代表ethernet |
|
hlen |
1 |
硬件地址長度，6代表10mb以太網 |
|
hops |
1 |
路由條數，通常用於中繼代理， |
|
xid |
4 |
由客戶機生成的隨機數，通常用於客戶機和服務器之間同步消息 |
|
secs |
2 |
由client填充，表示客戶機經歷地址獲取或續約所經歷的時間 |
|
flags |
2 |
定義廣播標誌 |
|
ciaddr |
4 |
客戶機的IP地址 |
|
yiaddr |
4 |
客戶機的IP地址 |
|
siaddr |
4 |
返回下一個使用BOOTP協議的服務器地址 |
|
giaddr |
4 |
中繼代理的IP地址 |
|
chaddr |
16 |
客戶機的硬件地址 |
|
sname |
64 |
服務器的hostname |
|
file |
128 |
boot文件名 |
|
options |
var |
支持的選項 |
表2 DHCP6數據報字段長度及功能
|
字段 |
長度（字節爲單位） |
功能 |
|
msg-type |
1 |
定義DHCP消息類型 |
|
transaction-id |
3 |
由客戶機生成的隨機數，通常用於客戶機和服務器之間同步消息 |
|
options |
var |
支持的選項 |
另外，需要指出的是，DHCP6將許多參數信息存放在選項中，這樣能夠減少數據報的淨長度，提高存儲利用率。這是因爲DHCP6的消息報頭僅佔4個字節，而將需要發送或者接收參數信息附在選項上，而DHCP消息報則是將大量的字段包含在報頭中，而實際情況是在某些消息報中，許多字段未得到充分運用而導致存儲浪費，如hops僅僅在支持中繼代理時才使用，file字段則幾乎被捨棄。
前面已經從消息報字段的長度以及功能兩個方面對DHCP與DHCP6做了比較，下面將着重闡述DHCP與DHCP6各自所包含的消息類型，以及消息的發方以及收方，消息產生的時間，client和server各自表現出怎樣的行爲等內容。
值得注意的是，DHCP消息報利用”op”字段來表示消息的類型，即BOOTREQUEST和BOOTREPLY，前者表示消息報是從客戶機發往服務器，而後者剛好相反，由此可以看到，op字段僅僅只是定義了該消息報的發送方向，而對該消息報的其他信息一無所知，基於此，RFC2131規定在DHCP消息報中一定要包含DHCP Messae Type選項，另外，還規定了常見的幾種消息類型：DHCPDISCOVER，DHCPOFFER，DHCPREQUEST ，DHCPACK，DHCPNAK，DHCPDECLINE，DHCPRELEASE和DHCPINFORM。在DHCP6消息報中，消息類型是由字段msg-type指定的，同樣定義了常見的幾種消息類型：SOLICIT，ADVERTISE，REQUEST，CONFIRM，RENEW，REBIND，REPLY，RELEASE，DECLINE，RECONFIGURE，INFORMATION-REQUEST，RELAY-FORW和RELAY-REPL，另外還定義了對應的數字編碼。下面將通過表格的形式對數據包內容做更詳細的解釋。
表3 DHCP消息報詳細信息
|
Type |
From |
To |
How and when to use |
Client behavior |
Server behavior |
Relay agent |
|
DHCPDISCOVER |
客戶機 |
本地服務器/中繼代理 |
客戶機向本地可得到的服務器發送廣播消息，可能會包含選項內容(網絡地址和租約時間), 注意：若目的地是中繼代理，應該填充’giaddr’字段消息 |
發送廣播消息，廣播地址爲255.255.255.255，自身地址爲0.0.0.0
|
1.返回客戶機DHCPOFFER消息，並在裏面填充“yiaddr”字段 2.若沒有可用的地址，則向管理員報告問題 |
給不與客戶機在同一子網內的DHCP服務器傳遞消息報
|
|
DHCPOFFER |
服務器/中繼代理 |
客戶機 |
迴應來自於客戶機發送的DHCPDISCOVER消息報 |
如果沒收到OFFER消息報，則重傳DISCOVER消息，否則選擇一個REQUEST消息報給選中的服務器，注意要填充'server identifier' 字段
|
在OFFER消息中返回客戶機DISCOVER消息中所需的參數信息 |
將來自於DHCP服務器的OFFER消息報轉發給客戶機 |
|
客戶機 |
本地服務器/中繼代理 |
滿足以下情形時，客戶端才發送請求包： 1.向選中的服務器發送請求需要的參數列表，同時拒絕未選中的服務器； 2.在客戶機狀態發生變化，如重啓，鏈路改變等，向服務器確認之前分配的地址是否還能使用； 3. 請求延長租約 |
向服務器或中繼代理髮送請求消息報，廣播地址依然爲255.255.255.255，自身地址爲0.0.0.0 |
1. 根據返回的’server identifier’字內容，服務器能判斷自己是否選中； 2.被選中的服務器將客戶機信息進行保存，併發送DHCPACK消息給客戶機，注意，此時所提ACK消息中的內容應該與之前的OFFER消息一致。這與客戶端第一種情形對應。 3. 若服務器不能滿足客戶機的請求(如地址已經被分配)，此時發送DHCPNAK消息給客戶機，與第二、三種情形對應。 4. 對應租約到期的客戶機，服務器沒有收到它的續約請求，則將所分配地址標記爲available |
將客戶機發送的請求包轉發給DHCP 服務器 |
|
|
DHCPACK |
服務器/中繼代理 |
客戶機 |
服務器收到來自於客戶機的DHCPREQUEST消息。消息報中應該攜帶客戶機所需要的配置信息。 |
1.若客戶機接收到ACK消息報，則利用ARP協議判斷報中的地址是否內使用，若不能使用，則發送DECLINE消息給服務器並重啓配置過程，發送請求報； 2. 若客戶機沒收到ACK消息，或者NAK消息，首先客戶機啓動重傳算法，若重傳之後依然沒有獲得，則則客戶機重啓配置過程，發送請求報。 |
發送ACK消息給客戶端 |
將來自於DHCP服務器的ACK消息報轉發給客戶機 |
|
DHCPNAK |
服務器/中繼代理 |
客戶機 |
當服務器判斷之前給客戶機發送的地址已被使用或者租約期已到 |
重啓配置過程併發送請求報 |
服務器發送NAK消息，並在`mseeage`選項中報告此問題 |
將來自於DHCP服務器的NAK消息報轉發給客戶機 |
|
DHCPDECLINE |
客戶機 |
服務器/中繼代理 |
客戶機通過ARP協議探測到服務器所分配的IP地址已經被本網絡中其它主機佔用 |
發送DECLINE消息報，並重啓配置過程 |
服務器將該地址標記爲`unavailable`,並向管理員通報 |
將客戶機發送的DECLINE消息報轉發給DHCP 服務器 |
|
DHCPRELEASE |
客戶機 |
服務器/中繼代理 |
客戶機向釋放掉之前分配的IP地址 |
客戶機在RELEASE消息報中填充`client identifier`, `chaddr`和網絡地址，並將其發給服務器或者中繼代理 |
服務器首先將客戶機釋放的地址標記爲`available`,並將客戶機的配置信息進行保存，已被後來重新使用 |
將客戶機發送的RELEASE消息報轉發給DHCP 服務器 |
|
DHCPINFORM |
客戶機 |
服務器/中繼代理 |
客戶機已經通過其他方式獲得IP地址(如手動)，但是需要從服務器處獲得本地配置信息 |
發送INFORM給服務器 |
構造出一個不包含“分配的IP地址，`yiaddr`字段和租約”信息的ACK消息報，但是包含客戶機所要求的配置信息 |
將客戶機發送的INFORM消息報轉發給DHCP 服務器 |
上表詳細描述了DHCP消息報的屬性以及行爲內容，有幾個需要特別說明的地方是：
◆ 客戶機所採取的重傳機制是隨機指數退避算法，具體思想可參考RFC2131文檔；
◆ 客戶機在發送DHCPDISCOVER消息報與DHCPREQUEST消息報時，廣播地址與自身地址分別爲：255.255.255.255,0.0.0.0.
◆ DHCP協議所運用的端口分別是：客戶機-68，服務器-67.
◆ 在客戶機釋放掉IP地址後，服務器還將保存之前對客戶機的配置信息，這樣有助於相對穩定地分配IP地址，只要下次這個IP地址沒有分給其它客戶機，當前客戶機在下 次發出配置地址請求時，服務器會將先前的配置信息賦給它。
◆ 注意發送DHCPREQUEST消息報的幾種情形的區別（將狀態的改變視爲參考點）：第一種情況出現在Client收到DHCPOFFER並進入SELECTING狀態 之後，Client向感興趣的Server發送DHCPREQUEST報，此時的消息報需要填充Server identifier, Request ip address等選項內容，結合後面馬上要講到的DHCP選項內容，一定要注意Server identifier填充的是server的標識符，Request ip address填充的是服務器在發送的DHCP OFFER消息報中附帶的IP地址信息；第二種情況是當客戶機發生狀態 改變，如重啓時需要跟服務器確認之前分配的IP地址是否依然可用，此時Client 處於INIT-REBOOTING狀態併發送DHCPREQUEST消息報，注意此時消息報中依然 需要填充Request ip address選項，但是填充的內容則是0.0.0.0(known network address), 並且此時也不需填充Server identifier選項；第三種情況則出現在Client正處於BOUND狀態並需要延長租 約時，向Server發送DHCPREQUEST消息報，不過此時不應該含有Server identifier以及Request ip address選項內容信息，增加的則是client ip address(ciaddr)信息。
表3只是列出了DHCP消息報的屬性及行爲內容，但是對消息報中應該包括的字段或者選項內容卻涉及很少，下面將按照消息報的類型，列出各自應該包括的內容。
表4 DHCP消息報填充字段與選項
|
Type |
Client |
Server |
|
DHCPDISCOVER |
必須包含的字段有：`xid`,`secs`,`flags`,`ciaddr`,`chaddr`,,其它字段可選；對於選項內容，不能包括的是`server identifer`,其它可選。 |
N/A |
|
DHCPOFFER |
N/A |
必須包含的字段有：`xid`, `yiaddr`, `siaddr`, `flags`, `giaddr`, `chaddr`,其它可選；對於選項，必須包括:`ip address lease`, `server identifier`,不能包含的是`request ip address`, `parameter request list`以及`client identifier`,其他可選 |
|
DHCPREQUEST |
必須包含`xid`,`secs`,`flags`,`ciaddr`,`chaddr`,`chadrr`等字段，而對於`sname`,`file`,`options`等字段是可選的。至於選項內容，`request ip address`必須包含，`server identifer`在僅僅當客戶機請求處於第一種情形，必須包含。其他選項均是可選的。 |
N/A |
|
DHCPACK |
N/A |
必須設置同之前發送給客戶機OFFER消息報中相同的字段和選項內容，另外再加上客戶機REQUEST消息報中所請求的參數內容消息 |
|
DHCPNAK |
N/A |
必須包含’client identifer’選項，或者錯誤報告選項 |
|
DHCPDECLINE |
必須填充`xid`,`ciaddr`(0), ‘chaddr’等字段，同時必須包含`request ip address`選項，可能包含`client identifer`選項，不能包含的有：`IP address lease time`, `vendor classidentifer`, `parameter request list`等選項 |
N/A |
|
DHCPRELEASE |
同DHCPDECLINE，但是此時不能包括`request ip address` |
N/A |
|
DHCPINFORM |
同DHCPDISCOVER，但是`request ip address` 和`ip address lease`布恩那個包含 |
N/A |
上表詳細列出了DHCP的消息報填充字段與選項信息，但有幾點值得注意的是：
◆ 各種消息報的`msg type`字段是一定包括的，在上表沒有寫出。
◆ DHCPREQUEST消息報中能否包含`server identifier`，主要跟客戶機何時發出這種請求消息報有關，若是從初始狀態開始發出請求報，則必須包含， 若是基於狀態改變或者申請延長租約等因素髮出請求報，則不能包含。
◆ 在各種消息報中，若客戶機與DHCP服務器不在同一網段，此時必須加上`giaddr`字段信息。
下面主要闡述在DHCP6中各種消息報的屬性、行爲內容以及需要填充的字段與選項。
表5 DHCP6消息報詳細信息
|
Type（registry code） |
From |
To |
How and when to use |
Client behavior |
Server behavior |
|
Solicit (1) |
客戶機 |
服務器/中繼代理 |
客戶機給服務器發送solicit消息，以便得到Ipv6地址，以及選項中所附帶的配置參數 |
創建solicit消息報並將其發送給服務器 |
1. 首先驗證solicit消息的有效性，若消息報中沒有包含`client identifier`或者包含有`server identifier`選項，則該報無效並捨棄； 2. 根據管理策略來驗證服務器是否允許接收該報; 3.若服務器擁有可以分配的地址，則回發Advertise消息報(狀態碼爲成功)，否則回髮狀態碼爲` NoAddrsAvail `的Advertise消息報。 4. 若socilit消息報中包含有`rapid commit`選項，則返回一個Reply消息報. |
|
Advertise (2) |
服務器/中繼代理 |
客戶機 |
迴應客戶機發送的solicit消息報 |
1. 驗證Advertise消息報的有效性: 若出現消息報中不含有`server identifier`字段和`client identifier`字段, `client identifier`字段中的DUID不匹配或者` transaction-id ``字段不匹配等情形，則該報無效並捨棄; 若包含狀態碼選項值爲` NoAddrsAvail `,同樣丟棄該報; 2. 基於某種策略（後面將有詳細介紹）選取Advertise消息報; |
給客戶機發送advertise消息報，報中包含一些設置的字段與選項 |
|
Request (3) |
客戶機 |
服務器/中繼代理 |
客戶機請求更多的配置參數 |
創建併發送request消息報給服務器 |
1. 首先驗證request消息的有效性：若消息中不包含`client identifier`選項`和server identifier`選項,，或者選項中的DUID內容與服務器不匹配，則該報無效並捨棄; 2.若無可用的地址分配，則返回一個狀態碼爲` NoAddrsAvail `的Reply消息; 3. 若服務器發現在IA選項中的地址前綴與自身不匹配，則返回一個狀態碼爲`NotOnLink`的Reply消息報; 4.創建一個Reply消息報，其中包括客戶機所需要的地址以及其他參數配置信息。 |
|
Confirm (4) |
客戶機 |
服務器/中繼代理 |
由於客戶機的狀態發生變化，發送confirm消息報去確認是否之前的配置是否還適合 |
當客戶機出現以下情形時:重啓，客戶機改爲有線連接，客戶機改變了無線接入點。此時客戶機需要發送confirm消息進行確認
|
1. 捨棄掉任何沒有包含`server identifier`和`client identifier`選項的消息報; 2. 判斷消息報中的IA選項中的地址是否與自己同屬一個鏈路，若是，返回一個狀態碼錶示爲爲成功的Reply消息報; 否則返回一個狀態碼爲NotOnLink的消息報； |
|
Renew (5) |
客戶機 |
服務器/中繼代理 |
要求服務器延長之前分配的租約以及升級其它的參數 |
創建併發送Renew消息報 |
1. 捨棄掉任何沒有包含`server identifier`和`client identifier`選項，或者`server identifier`選項中的DUID與服務器不匹配的消息報; 2. 驗證消息保證中`IA`選項中地址是否與服務器中的存儲信息吻合，若沒找到對應信息，則返回狀態碼爲`NoBinding`的Reply消息報; 3. 返回包含新的lifetime, T1/T2值的Reply消息報給客戶機
|
|
Rebind (6) |
客戶機 |
服務器/中繼代理 |
要求服務器延長之前分配的租約以及升級其它的參數，注意這個消息報只有在之前客戶機發送的Renew消息報沒得到服務器響應後才產生 |
創建併發送Rebind消息報 |
1.捨棄掉任何沒有包括`server identifier`和`client identifier`選項的Rebind消息報; 2.若在服務器中沒有找到與Rebind消息報中的IA選項中吻合的地址，或者發現地址但不再適合本鏈路，則服務器發回一個ilifetime置爲0的Reply消息; 3. 若找到吻合的地址信息，服務器發回一個包含新的lifetime以及T1/T2值的Reply消息報。 |
|
Reply (7) |
服務器/中繼代理 |
客戶機 |
當服務器收到客戶機發送的Solicit(含rapid commit選項),Request, Renew以及Rebind消息時，產生Reply消息報迴應 |
|
|
|
Release (8) |
客戶機 |
服務器/中繼代理 |
客戶機發送Release消息報告知服務器自己所分配的一個或者多個地址不再使用時產生Release消息報 |
創建併發送Release消息報，值得注意的是，釋放掉的地址不能再使用，若沒有收到Reply反饋消息報，則實現重傳。 |
1. 捨棄掉任何沒有包含`server identifier`和`client identifier`選項，或者`server identifier`選項中的DUID與服務器不匹配的消息報; 2. 服務器從Release消息報IA選項中的地址列表中找出有效的地址(即是由本服務器之前分配的)，並將這些地址標記爲available; 3. 返回一個Reply反饋消息報; 4. 服務器保留分配信息，以備下次直接將配置信息賦給這臺客戶機.
|
|
Decline (9) |
客戶機 |
服務器/中繼代理 |
客戶機發送Decline消息告知服務器自己所分配的地址已經被本鏈路的其它主機佔用 |
創建併發送Decline消息報,注意Decline消息報的`IA`選項中一定含有被佔用的地址信息 |
1. 捨棄掉任何沒有包含`server identifier`和`client identifier`選項，或者`server identifier`選項中的DUID與服務器不匹配的消息報; 2. 服務器檢測Decline消息報中IA選項報告的地址，並將其刪除，然後在本地做標記，下次將不再分配給其它客戶機 3. 處理完地址後，返回帶有狀態碼的Reply消息
|
|
Reconfigure (10) |
服務器/中繼代理 |
客戶機 |
服務器通過發送Reconfigure消息去告知客戶機，服務器端出現新的配置參數或者某些參數已經更新，並觸發客戶機同服務器共同去完成Renew/Reply和Information-request/Reply |
1. 首先驗證消息報的有效性：若消息報不是單播傳給客戶機;沒有包含`server identifier`和`client identifier`,消息中沒有包含`Reconfigure message`選項，消息中包含`IA`選項並且`Reconfigure meaasge`選項的消息類型是` INFORMATION-REQUEST `,則將該消息報捨棄; 2.客戶機返回一個Renew或者Information-request消息報 |
創建併發送Reconfigure消息報，若在某個時間範圍內，沒有收到來自於客戶機的Renew或者Information-request消息，則服務器重傳該消息報 |
|
Information-request (11) |
客戶機 |
服務器/中繼代理 |
客戶機發送該消息報給服務器，僅僅爲了得到配置參數，而不需要分配地址 |
創建併發送Information-request消息報，若沒收到Reply反饋消息,則重傳消息報 |
1. 驗證消息報的有效性，若消息報中包含`server identifier`並且選項中的DUID與本地服務器不匹配,或者包含IA選項，則將該報捨棄; 2.構造一個包含配置信息的Reply消息報併發送給客戶機 |
|
Relay-forward (12) |
|
|
|
|
|
|
Relay-reply (13) |
|
|
|
|
|
上表詳細列出了DHCP6消息報的屬性以及行爲內容，有幾個特別需要說明的地方是：
◆ 對比，DHCP消息報，DHCP6在中繼代理方面增加了消息報，以及其它一些機制，這方面的知識將在後面還會比較到。
◆ 在`IA_NA`選項中，定義了多種狀態碼，分別爲：
|
Name |
Code |
description |
|
Success |
0 |
表示成功 |
|
UnspecFail |
1 |
表示出現不知原因的失敗 |
|
NoAddrsAvail |
2 |
表示服務器沒有可用的地址去分配客戶機 |
|
NoBinding |
3 |
表示服務器沒有綁定客戶機信息 |
|
NotOnLink |
4 |
表示服務器與客戶機的地址前綴不匹配，即二者不在同一鏈路上 |
|
UseMulticast |
5 |
表示服務器強制客戶機使用 All_DHCP_Relay_Agents_and_Servers多播地址去發送消息 |
◆ 在DHCP6中，客戶機去選取連接DHCP6服務器是基於某種策略的，具體跟服務器所返回消息報中的`prefere option`有關，在這個選項中定義了服務器參考值(server prefere value)，它的最大值爲255, 客戶機正是根據服務器中的參考值不同選取目標服務器的，具體策略如下：
● 若某個服務器中的參考值爲255，則它擁有最高優先級;
● 若服務器中的參考值正好相等，則根據對服務器返回的配置參數的興趣而定;
● 客戶機甚至會選取某些儘管參考值較低但返回更匹配的配置參數的服務器。 值得注意的是，在DHCP中，一般會選取最先返回配置參數的服務器！
表6列出了DHCP6消息報的填充字段以及選項。
表6 DHCP6消息報填充字段與選項
|
Type |
Client |
Server |
|
Solicit (1) |
填充`msg-type`, ` transaction-id `字段，必須包含的選項有：` Client Identifier`,`IA-NA/TA`,可選的有:` Option Request`,` Reconfigure Accept `和`rapid commit`. 另外還有注意，客戶機發送solicit消息時採用的是本地鏈路地址，而目的地址是” All_DHCP_Relay_Agents_and_Servers address”多播地址,即ff02::1:2 |
N/A |
|
Advertise (2) |
N/A |
填充`msg-type`字段，` transaction-id `字段來自於客戶機發送的solicit消息報中的相應字段值。必須包含的選項有：`server identifier`, `client identifier`, `IA`選項(注意IA選項的數量由silicit消息報中的`IA`選項而定)以及客戶機中的`optional request`選項中含有的一些選項。可選的有：` Preference `, ` Reconfigure Accept `, `` |
|
Request (3) |
填充`msg-type`, ` transaction-id `字段,必須包含的選項有：`server identifier`, `client identifier`, ` Option Request `,`IA-NA/TA`,可選的有：` Reconfigure Accept `以及其它選項，注意請求時的目的地址以及多播地址同solicit消息報。 |
N/A |
|
Confirm (4) |
填充`msg-type`字段，併產生` transaction-id `字段內容，必須包含的選項有：`client identifier`, `IA`(對於IA_NA選項，應該設置T1,T2域，以及preferred-lifetime and valid-lifetime域) |
N/A |
|
Renew (5) |
填充`msg-type`字段，併產生` transaction-id `字段內容，必須包含的選項有：`client identifier`, `server identifier`, `IA`, ` Option Request `以及其他可選項 |
N/A |
|
Rebind (6) |
填充`msg-type`字段，併產生` transaction-id `字段內容，必須包含的選項內容有：`client identifier`, `IA`, `option request` |
N/A |
|
Reply (7) |
N/A |
1. 若是對solicit消息報(包含`rapid commit`選項)的回覆：必須填充字段`msg-type`和` transaction-id `字段（來自於solicit消息報），必須包含的選項有：server identifier`, `client identifier`, `IA`以及request消息報中所請求的參數選項, `rapid commit`。 2. 若是對Request消息報的回覆：必須填充字段`msg-type`和` transaction-id `字段（來自於request消息報）,必須包含的選項有:`server identifier`, `client identifier`, `IA`以及request消息報中所請求的參數選項; 3. 若是對Confirm消息的回覆：填充`msg-type`字段，` transaction-id `字段來自於客戶機發送的solicit消息報中的相應字段值。必須包含的選項有:`server identifier`, `client identifier`, `status code` 4. 若是對Renew消息的回覆：填充`msg-type`字段，` transaction-id `字段來自於客戶機發送的solicit消息報中的相應字段值。必須填充的選項有：`server identifier`, `client identifier`,,`IA` 5. 若是對Rebind消息的回覆：填充`msg-type`字段，` transaction-id `字段來自於客戶機發送的solicit消息報中的相應字段值。必須填充的選項有：`server identifier`, `client identifier`,,`IA` 6. 若是對Release消息的回覆：填充`msg-type`字段，` transaction-id `字段來自於客戶機發送的solicit消息報中的相應字段值。必須填充的選項有：`server identifier`, `client identifier`, `IA`(包含狀態碼選項) 7. 若是對Decline消息的回覆：填充`msg-type`字段，` transaction-id `字段來自於客戶機發送的solicit消息報中的相應字段值。必須填充的選項是：`server identifier`, `client identifier`, `IA`(包含狀態碼選項) |
|
Release (8) |
填充`msg-type`字段，併產生` transaction-id `字段內容,必須包含的選項有：`client identifier`, `server identifier`, `IA` |
N/A |
|
Decline (9) |
填充`msg-type`字段，併產生` transaction-id `字段內容,,必須包含的選項有: `client identifier`, `server identifier`, `IA` |
N/A |
|
Reconfigure (10) |
N/A |
填充`msg-type`字段，並將` transaction-id `設置成0；必須包含的選項有:`server identifier`, `Reconfigure message`, `IA`, `Option request`則是可選的,其他的選項則都不能使用 |
|
Information-request (11) |
填充`msg-type`字段，併產生` transaction-id `字段內容,必須包含的選項有：`option request`, `client identifier` |
N/A |
|
Relay-forward (12) |
|
|
|
Relay-reply (13) |
|
|
2. 兩種版本的選項格式比較：
DHCP:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +
| option-data |
| (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fix-length options: option 0 and option 255 are considered as without data, so it only includes option-code filed.
Variable-length options(except fix-length option): must follow a option-len field and the field value only specifies the size of option-data field, not include the size of option-code and option-len fields.
These options are encoded as a one-byte type code, a one-byte length, and a buffer consisting of the number of bytes specified in the length, from zero to 255. In RFC 3396, provides a rule how to concatenate(decode) and split(encode) option field when the option-len excedes 255 octets in size.
【注意】這個地方與DHCPV6存在着不同的處理方式，RFC 3396定義瞭如何處理當同code的選項數據被split並出現在不同的域內(field,主要有option, file和sname)時如何將它們連成一個單獨的選項的規則；而在RFC 3315中則規定(section 22.1),當出現多個同code的選項時，它的選項數據是不能夠聯合在一起的，這也是跟二者所定義的選項內容結構差異密切相關的。
DHCPv6：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data |
| (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DHCP與DHCPV6常見的支持選項:
DHCP常見支持選項 (Public-defined options in DHCP)
|
Option Name |
Code |
Len (octet) |
MAY, Must or Must not include |
Function |
|
pad |
0 |
1 |
All MAY |
align a subsequent field on a word (two-byte) boundary
|
|
end |
255 |
1 |
All MUST |
Placed after all other options to mark the end of the option list
|
|
Subnet Mask |
1 |
4 |
|
Specific the client's subnet mask
|
|
Router |
2 |
variable( multiply of 4) |
|
Specifies a list of router addresses for the client to use on the local network
|
|
Domain name server |
6 |
variable( multiply of 4) |
|
Specifies a list of domain name servers available to client |
|
Host name |
12 |
variable( multiply of 4) |
|
Specifies a list of DNS name server addresses for the client to use on the local network
|
|
Network Time Protocol Servers |
42 |
variable( multiply of 4) |
|
Specifies a list of IP addresses indicating NTP servers available to the client. |
|
Requested IP Address |
50 |
4 |
Must: DHCPREQUEST(when in SELECTING or INIT-REBOOT state), DHCPDECLINE, DHCPNAK MUST NOT: DHCPREQUEST(when in BOUND or RENEWING state), DHCPRELEASE, DHCPINFORM
|
Allow the client to request that a particular IP address be assigned
|
|
IP Address Lease Time |
51 |
4 |
Must: DHCPOFFER, DHCPACK MUST NOT: DHCPINFORM, DHCPDECLINE, DHCPRELEASE
|
Allow the client to request a lease time for the IP address.
|
|
DHCP Message Type |
53 |
1 |
All MUST |
Specifies the type of the DHCP message
|
|
Server Identifier |
54 |
4 |
MUST: DHCPREQUEST(when in SELECTING state), DHCPDECLINE, DHCPRELEASE, DHCPACK, DHCPNAK, DHCPOFFER MUST NOT: DHCPDISCOVER, DHCPINFORM
|
Specifies the ip address for the selected server to client
|
|
Parameter request list |
55 |
variable |
MAY: DHCPDISCOVER, DHCPREQUEST |
Used by a DHCP client to request values for specified configuration parameters
|
|
Message |
56 |
variable |
MAY: DHCPNAK |
Used by a DHCP server to provide an error message to a DHCP client in a DHCPNAK message in the event of a failure
|
|
Maximum DHCP message size |
57 |
2 |
ALL MAY |
Specifies the maximum length DHCP message that it is willing to accept
|
|
Renewal Time Value (T1) |
58 |
4 |
|
Specifies the time interval from address assignment until the client transitions to the RENEWING state.
|
|
RebindingTime Value (T2) |
59 |
4 |
|
Specifies the time interval from address assignment until the client transitions to the REBINDING state.
|
|
Vendorclassidentifier |
60 |
variable |
|
Used by DHCP clients to optionally identify the vendor type and configuration of a DHCP client. such as “udhcpc 1.21.1”
|
|
Client identifier |
61 |
variable |
MUST: DHCPOFFER, DHCPACK, DHCPNAK |
Used by DHCP clients to specify their unique identifier, usually consist of a hardware type (htype) and hardware address (chaddr).
|
DHCPV6 常見支持選項
|
Option Name |
Code |
Len (octet) |
MAY, Must or Must not include |
Function |
|
Client identifier(RFC 3315) |
1 |
Variable(equal to DUID)
|
Must: |
Used to carry a DUID identifying a client between a client and a server |
|
Server identifier(RFC 3315) |
2 |
Variable(equal to DUID)
|
|
Used to carry a DUID identifying a server between a client and a server |
|
IA_NA(RFC 3315) |
3 |
12(IAID+T1+T2) + length of IA_NA options |
|
Used to carry an IA_NA, the parameters associated with the IA_NA, and the non-temporary addresses associated with the IA_NA.
|
|
IA_TA(RFC 3315) |
4 |
4(IAID) + length of IA_TA options |
|
Used to carry an IA_TA, the parameters associated with the IA_TA and the addresses associated with the IA_TA.
|
|
IA address(RFC 3315) |
5 |
16(IPV6 address) + 4(prefered-lifetime) +4(valid-lifetime) + length of Iaaddr-options |
|
Used to specify IPv6 addresses associated with an IA_NA or an IA_TA.
|
|
Option request(RFC 3315) |
6 |
2 * number of request options (each option needs two octets ) |
|
Used to identify a list of options in a message between a client and a server
|
|
Preference(RFC 3315) |
7 |
1(pref-value) |
|
Sent by a server to a client to affect the selection of a server by the client.
|
|
Elapsed time(RFC 3315) |
8 |
2 |
|
Sent by client to indicate how long the client has been trying to complete a DHCP message exchange
|
|
Status code(RFC 3315) |
13 |
2(status code) + length of status-message |
|
Returns a status indication related to the DHCP message or option in which it appears
|
|
Rapid commit(RFC 3315) |
14 |
0 |
|
Used to signal the use of the two message exchange for address assignment |
|
Vendor class(RFC 3315) |
16 |
4(enterprise-number) + length of vendor-class-data |
|
Used by a client to identify the vendor that manufactured the hardware on which the client is running
|
|
Reconfigure message (RFC 3315) |
19 |
1(msg-type) |
|
Included in server and to indicate to the client whether the client responds with a Renew message or an Information-request message |
|
Reconfigure accept (RFC 3315) |
20 |
0 |
|
Announce to the server whether the client is willing to accept Reconfigure messages, and a server uses this option to tell the client whether or not to accept Reconfigure messages.
|
|
IA_PD(RFC 3315) |
25 |
12(IAID + T1 + T2) + length of IA_PD options |
|
Used to carry a prefix delegation identity association |
|
IA_PD prefix (RFC 3633) |
26 |
4(prefered-lifetime) + 4(valid-lifetime) + 1(prefix-length) + 16(IPV6 prefix) |
|
Used to specify IPv6 address prefixes associated with an IA_PD |
|
DNS Recursive Name Server (RFC 3646) |
23 |
A multiply of 16 octets (each IPV6 address) |
|
Provides a list of one or more IPv6 addresses of DNS recursive name servers to which a client's DNS resolver MAY send DNS queries |
|
Information Refresh Time (RFC 4242) |
32 |
4 |
|
Used from server to client to inform the client when it should refresh the other configuration data
|