IPv6下的DHCP(DHCPv6)
一、IPv6概述
IPv6在IPv4的基礎上做了很多改進,如擴編地址(由32位擴編爲128位)、支持無狀態地址自動配置、簡化報頭、身份驗證、支持新的網絡服務(QoS)等,並且增強了移動性和安全性,這使得IPv6成爲下一代互聯網的核心協議。
IPv6支持的地址分配方式:
1、 無狀態地址自動配置;
2、 有狀態地址自動配置。
無狀態地址自動配置是指主機通過監聽路由通告獲得全局地址前綴(64位),然後在後邊綴上自己的接口地址得到全局IP地址。這主要是因爲IPv6有海量的IP地址資源,用戶可以自行配置一個全局IP。接口地址實際上就是MAC地址,由於MAC地址是48位的,所以這裏要用到一個IEEE提供的EUI64轉換算法,可以將48位的MAC地址換算爲64位。然後主機向該地址發送一個鄰居發現請求(Neighbor DiscoveryRequest),如果無響應,則證明網絡地址是唯一的。
主機通過無狀態地址自動配置獲得IP的過程如圖所示。
IPv6的無狀態地址自動配置
有狀態地址自動配置是由IPv4下的DHCP轉化而來,IPv6繼承並改進了這種服務,即DHCPv6協議,它向 IPv6主機提供有狀態的地址配置或無狀態的配置設置。IPv6主機自動執行無狀態地址自動配置,並在相鄰路由器發送的路由器公告消息中使用基於以下標記的配置協議(如 DHCPv6):
託管地址配置標記,也稱爲 M 標記。設置爲 1時,此標記指示主機使用配置協議來獲取有狀態地址。
其他有狀態配置標記 ,也稱爲 O 標記。設置爲 1時,此標記指示主機使用配置協議來獲取其他配置設置。
結合 M 和 O 標記的值可以產生以下組合:
M 和 O 標記均設置爲 0。 此組合對應不具有 DHCPv6基礎結構的網絡。主機使用非鏈接本地地址的路由器公告以及其他方法(如手動配置)來配置其他設置。
M 和 O 標記均設置爲 1。 DHCPv6用於這兩種地址(鏈接本地地址和其他非鏈接本地地址)和其他配置設置。該組合稱爲 DHCPv6 有狀態,其中 DHCPv6將有狀態地址分配給 IPv6 主機。
M 標記設置爲 0,O 標記設置爲 1。 DHCPv6不用於分配地址,僅用來分配其他配置設置。相鄰路由器配置爲通告非鏈接本地地址前綴,IPv6 主機從中派生出無狀態地址。此組合稱爲DHCPv6 無狀態:DHCPv6 不爲 IPv6 主機分配有狀態地址,但分配無狀態配置設置。
M 標記設置爲 1,O 標記設置爲 0。 在此組合中,DHCPv6用於地址配置,但不用於其他設置。因爲 IPv6 主機通常需要使用其他設置(如域名系統 (DNS) 服務器的 IPv6地址)進行配置,所以這是一種不太可能的組合。
類似於 DHCPv4,DHCPv6 基礎結構的組件由下列各項構成:請求配置的 DHCPv6客戶端、提供配置的 DHCPv6 服務器、以及 DHCPv6 中繼代理(當客戶端位於不具備 DHCPv6服務器的子網上時,它在客戶端和服務器之間傳遞信息)。
2、DHCPv6協議下主機與服務器交互
DHCPv6協議下客戶端與服務器端的交互與DHCPv4類似採用如下圖所示的4步交互:
DHCPv6協議下主機與服務器的四步交互
但DHCPv6支持快速的兩步交互,即如果客戶端發送的SOLICIT報文中有rapidcommit選項,並且服務器支持該交互方式,就可以進行如下圖所示的兩步交互:
DHCPv6協議下主機與服務器的兩步快速交互
在上述交互過程中提到的DHCPv6報文與DHCPv4類似,如solicit報文類似與discover報文,advertise報文類似於offer報文等等。
DHCPv6 消息 |
描述 |
等效的 DHCPv4 消息 |
要求(solicit) |
由客戶端發送以定位服務器。 |
DHCPDiscover |
公告(advertise) |
由服務器對“要求”消息進行響應時發送以指明可用性。 |
DHCPOffer |
請求(request) |
由客戶端發送以請求來自特定服務器的地址或配置設置。 |
DHCPRequest |
確認(confirm) |
由客戶端發送給所有服務器,以確定對於已連接的鏈接客戶端的配置是否有效。 |
DHCPRequest |
更新(renew) |
由客戶端發送給特定服務器以延長分配地址的生存期並獲取更新的配置設置。 |
DHCPRequest |
重新綁定(rebind) |
未接收到對“更新”消息的響應時由客戶端發送給任何服務器。 |
DHCPRequest |
應答(reply) |
對要求、請求、更新、重新綁定、信息請求、確認、發佈或拒絕消息進行響應時由服務器發送給特定客戶端。 |
DHCPAck |
發佈(release) |
由客戶端發送以指明客戶端不再使用分配的地址。 |
DHCPRelease |
拒絕(decline) |
由客戶端發送給特定服務器以指明分配的地址已在使用中。 |
DHCPDecline |
重新配置(reconfigure) |
由服務器發送給客戶端以指明該服務器具有新的或更新的配置設置。客戶端隨後發送“更新”或“信息請求”消息。 |
N/A |
信息請求(information-request) |
由客戶端發送以請求配置設置(但不包括地址)。 |
DHCPInform |
中繼轉發(relay-forw) |
由中繼代理髮送以轉發消息給服務器。中繼轉發包含封裝爲 DHCPv6 中繼消息選項的客戶端消息。 |
N/A |
中繼應答(relay-reply) |
由服務器發送以通過中繼代理髮送消息給客戶端。中繼應答包含封裝爲 DHCPv6中繼消息選項的服務器消息。 |
N/A |
表一 DHCP報文與DHCPv4報文對比
3、DHCPv6的報文結構
DHCPv6的封包有兩種結構,即在中繼與客戶端上使用的報文結構有時是不同的,在客戶端與服務器端報文結構如下圖所示:
客戶端與服務器端交互的報文——摘自RFC3315
而在服務器與中繼代理端交互的報文結構與客戶端與服務器端交互的報文是不同的,某種程度上顯得更爲複雜一些,RFC3315中描述的這種報文結構如圖所示:
服務器與中繼代理之間的報文——摘自RFC3315
結束語
從IPv4走向IPv6是必然的發展趨勢,雖然IPv6支持無狀態的自動分配地址,但這並不意味着DHCP會隨着IPv6的出現以及IPv6設備的大量部署而退出歷史舞臺。不僅是在這麼一個過渡時期,DHCP是不可或缺的,即便是在將來,DHCP仍將發揮重要作用。思科公司的Droms預計,大部分的企業都將花錢來支持DHCPv6。他說:“網管員們都想知道網絡上連接着什麼樣的主機和設備,以及這些設備的地址,因此,他們將希望使用DHCPv6。”
DHCPv6較DHCPv4更爲複雜,也有很多不同的地方,如DHCPv4使用67和68端口,而DHCPv6使用546和547端口;不同的報文結構以及交互方式,DHCPv6設備都要使用DUID來互相認證等。但他們的原理類似,具備DHCPv4知識的技術人員在熟悉IPv6的基礎上可以很快掌握DHCPv6協議。