深度分析DHCPV6協定，比較與DHCP的區別

獨白

Posted on by

深度分析DHCPV6協定，比較與DHCP的區別

一、DHCPV6產生的背景
隨著全球IPV4位址逐漸枯竭，IPV6應運而生，IPV6是將來地址的趨勢。位址轉變了，當然相應在IPV4上運用的協定也要轉變到IPV6中來，所以DHCPV4也要轉到DHCPV6中來。所以本文就引出了DHCP V6協定。IETF在2003年重新制定了針對IPV6的DHCP協定，即DHCPV6，對比V4，它增加了一些特有的功能，如支援有狀態和無狀態位址分配服務，支援臨時位址，非臨時位址以及首碼位址的分配等，後面將會更加具體比較二者在選項、用戶端與伺服器行為、消息類型的差異。

二、DHCP6交互資料詳細解析並分析與DHCPV4的區別

下面詳細解析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中，一般會選取最先返回配置參數的伺服器！

下表列出了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 
 

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)

    


從實際資料進行比較DHCPV4和DHCPV6的區別，下面兩張圖第一張對應的是正常情況下獲取IPv4位址的過程示意圖，從圖可以看出，用戶端首先利用0.0.0.0位址發送一個一個廣播discover消息，接著多個伺服器響應併發回了可供客戶機使用的位址(參照offer消息)，然後客戶機從中選擇某台伺服器並向其發送request消息，最後被選中的伺服器返回ACK確認消息，這樣就完成了對客戶機的位址分配。具體DHCPV4工作分析請見：《深度分析DHCP工作原理》一文。第二張，客戶機利用本地鏈路位址發送一個solicit廣播消息(廣播位址是ff02::1:2), 之後一台伺服器提供了advertise消息，並將IP位址以及客戶機所需要的配置參數資訊返回，然後客戶機發送一個request消息，主要從伺服器端索取自己所需要的請求參數資訊，最後伺服器回應請求。


DHCP獲取IP地址過程


DHCP6獲取IPV6地址過程

從上面的DHCPV4和DHCP6兩個資料交互過程，可以清楚的看出兩者的差異。

當然今天在這裡分析的只是DHCP6協定的冰山一角，在後面的文章中還會陸續給出DHCPV6協定的更深的內容，希望繼續關注。

發表留言