DHCPv6
DHCPv6簡介
IPv6動態主機配置協議DHCPv6(Dynamic Host Configuration Protocol for IPv6)是針對IPv6編址方案設計，為主機分配IPv6地址/前綴和其他網絡配置參數。
tcpdump: ether proto 0x86dd and udp and port 547 or port 546
wireshark: dhcpv6 && dhcpv6.msgtype==
IA（Identity Association）：一組分配給DHCPv6主機客戶端的地址集合。IA又分為IA-NA（Identity Association-Prefix Delegation）前綴集合。
UDP-server：546，UDP-client：547
采用多播地址FF02::1:2來表示鏈路范圍內所有的DHCPv6服務器和中繼
消息包含Solicit、Advertise、Request、Conform、Renew、Rebind、Reply、Release、Decline、Reconfig、Information-request、Relay-forw和Relay-repl等13種
報文格式有兩種，在客戶端和服務器之間使用的消息格式和在中繼和服務器之間使用的報文格式
各個字段意義。。。
工作機制
DHCP實現由狀態地址配置和其他信息的配置（路由器公告中的M和O標記均設置為1），其工作機制如下圖
終端客戶多播發送DHCPv6 Solicit報文，攜帶客戶端DHCP唯一標識選項（DUID）和用于配置客戶端的選項等選項信息，并定位DHCPv6服務器。
DHCP服務器收到Solicit報文后，添加服務器DHCP唯一標識選項（DUID）和優先級選項，響應Advertise消息，表明自身可用性。
客戶端根據DHCP服務器優先級和能提供的服務，選擇一臺DHCP服務器。多播發送Request報文，該報文攜帶客戶端DUID、選定服務器的DUID和相關配置選項。
擁有相同DUID的服務器回送Reply報文，攜帶配置選項。
客戶端根據Reply報文中的選項信息完成自動配置
DHCPv6客戶端通過鏈路范圍內的多播地址與DHCPv6服務器通信。如果服務器和客戶端不再用一個鏈路范圍內，則需要通過DHCPv6中繼來轉發報文。DHCPv6中繼和DHCPv6服務器之間交互兩種報文：Relay-forw和Relay-repl。DHCPv6客戶端通過DHCPv6中繼轉發報文，獲取IPv6地址和其他網絡配置參數的過程如下圖：
DHCPv6客戶端向所有DHCPv6服務器和中繼的多播地址FF02::1:2發送請求。
DHCPv6中繼接收到請求后，將其封裝在Relay-forw報文的中繼消息選項（Relay Message Option）中，并將Relay-forw報文發送給DHCPv6服務器
DHCPv6服務器從Relay-forw報文中解析出客戶端的請求，為客戶端選取IPv6地址和其他參數，構造應答消息，將應答消息封裝在Relay-repl報文的中繼消息選項中，并將Relay-repl報文發送給DHCPv6中繼。
DHCPv6中繼從Relay-repl報文中解析出服務器的應答，轉發給DHCPv6客戶端
客戶端根據DHCPv6服務器分配的IPv6地址和其他參數進行網絡配置
無狀態地址配置能夠實現終端地址的自動配置，但其他信息的配置，如DNS/NTP等服務器信息的配置（ND機制新定義了一個Option25選項，在RA報文攜帶DNS配置信息，實現主機DNS配置，但大多數主機不支持該選項），通常還需要借助DHCP機制（路由器公告中的M設置為0，O設置為1），其工作機制如圖：
客戶端通過無狀態地址配置方式實現地址配置，即客戶端 由自身MAC根據EUI-64生成64位接口ID。
鏈路本地路由器多播發送RA報文，并攜帶前綴選項
客戶端根據前綴和接口ID形成完整IPv6地址
為獲得其他配置信息，客戶端多播發送Information-request報文，請求配置信息。
中繼路由器將報文封裝到Relay-forw報文，發送給DHCPv6服務器（通常單播發送）
服務器響應發送攜帶相應配置信息的Relay-repl報文
中繼解析出Reply報文，并發送給客戶端。
客戶端根據Reply報文中提供的參數完成客戶端無狀態配置（若接收到多個Reply報文，客戶端將選擇最先收到的Reply報文）
目的：
IPv6協議具有地址空間巨大的特點，但同時長達128比特的IPv6地址又要求高效合理的地址自動分配和管理策略。IPv6無狀態地址配置方式（參看協議RFC2462）是目前廣泛采用的IPv6地址自動配置方式。配置了該協議的主機只需相鄰設備開啟IPv6路由通告功能，即可以根據通告報文包含的前綴信息自動配置本機地址。
無狀態地址配置方案中設備并不記錄所連接的IPv6主機的具體地址信息，可管理性差。而且當前無狀態地址配置方式不能使IPv6主機獲取DNS服務器的IPv6地址等配置信息，在可用性上有一定缺陷。對于互聯網服務提供商來說，也沒有相關的規范指明如何向設備自動分配IPv6前綴，所以在部署IPv6網絡時，只能采用手動配置的方法為設備配置IPv6地址。
DHCPv6技術解決了這一問題。DHCPv6屬于一種有狀態地址自動配置協議。
與其他IPv6地址分配方式（手工配置、通過路由器通告消息中的網絡前綴無狀態自動配置等）相比，DHCPv6具有以下優點：
更好地控制IPv6地址的分配。DHCPv6方式不僅可以記錄為IPv6主機分配的地址，還可以為特定的IPv6主機分配特定的地址，以便于網絡管理。
DHCPv6支持為網絡設備分配IPv6前綴，便于全網絡的自動配置和網絡層次性管理。
除了為IPv6主機分配IPv6地址/前綴外，還可以分配DNS服務器IPv6地址等網絡配置參數。
DHCPv6原理描述
DHCPv6概述：
DHCPv6是一種運行在客戶端和服務器之間的協議，與IPv4中的DHCP一樣，所有的協議報文都是基于UDP的。但是由于在IPv6中沒有廣播報文，因此DHCPv6使用組播報文，客戶端也無需配置服務器的IPv6地址。
IPv6地址分配類型：
IPv6協議具有地址空間巨大的特點，但同時長達128比特的IPv6地址又要求高效合理的地址自動分配和管理策略。
手動配置。手動配置IPv6地址/前綴及其他網絡配置參數（DNS、NIS、SNTP服務器地址等參數）。
無狀態自動地址分配。由接口ID生成鏈路本地地址，再根據路由通告報文RA（Router Advertisement）包含的前綴信息自動配置本機地址。
有狀態自動地址分配，即DHCPv6方式。DHCPv6又分為如下兩種:
DHCPv6有狀態自動分配。DHCPv6服務器自動分配IPv6地址/PD前綴及其他網絡配置參數（DNS、NIS、SNTP服務器地址等參數）。
DHCPv6無狀態自動分配。主機IPv6地址仍然通過路由通告方式自動生成，DHCPv6服務器只分配除IPv6地址以外的配置參數，包括DNS、NIS、SNTP服務器等參數。
DHCPv6基本架構：
圖：DHCPv6基本架構
DHCPv6基本協議架構中，主要包括以下三種角色：
DHCPv6 Client：
DHCPv6客戶端，通過與DHCPv6服務器進行交互，獲取IPv6地址/前綴和網絡配置信息，完成自身的地址配置功能。
DHCPv6 Relay：
DHCPv6中繼代理，負責轉發來自客戶端方向或服務器方向的DHCPv6報文，協助DHCPv6客戶端和DHCPv6服務器完成地址配置功能。一般情況下，DHCPv6客戶端通過本地鏈路范圍的組播地址與DHCPv6服務器通信，以獲取IPv6地址/前綴和其他網絡配置參數。如果服務器和客戶端不在同一個鏈路范圍內，則需要通過DHCPv6中繼代理來轉發報文，這樣可以避免在每個鏈路范圍內都部署DHCPv6服務器，既節省了成本，又便于進行集中管理。
DHCPv6基本協議架構中，DHCPv6中繼代理不是必須的角色。如果DHCPv6客戶端和DHCPv6服務器位于同一鏈路范圍內，或DHCPv6客戶端和DHCPv6服務器直接通過單播交互完成地址分配或信息配置的情況下，是不需要DHCPv6中繼代理參與的。只有當DHCPv6客戶端和DHCPv6服務器不在同一鏈路范圍內，或DHCPv6客戶端和DHCPv6服務器無法單播交互的情況下，才需要DHCPv6中繼代理的參與。
DHCPv6 Server：
DHCPv6服務器，負責處理來自客戶端或中繼代理的地址分配、地址續租、地址釋放等請求，為客戶端分配IPv6地址/前綴和其他網絡配置信息。
DHCPv6基本概念：
組播地址
在DHCPv6協議中，客戶端不用配置DHCPv6 Server的IPv6地址，而是發送目的地址為組播地址的Solicit報文來定位DHCPv6服務器。
在DHCPv4協議中，客戶端發送廣播報文來定位服務器。為避免廣播風暴，在IPv6中，已經沒有了廣播類型的報文，而是采用組播報文。DHCPv6用到的組播地址有兩個：
FF02::1:2（All DHCP Relay Agents and Servers）：所有DHCPv6服務器和中繼代理的組播地址，這個地址是鏈路范圍的，用于客戶端和相鄰的服務器及中繼代理之間通信。所有DHCPv6服務器和中繼代理都是該組的成員。
FF05::1:3（All DHCP Servers）：所有DHCPv6服務器組播地址，這個地址是站點范圍的，用于中繼代理和服務器之間的通信，站點內的所有DHCPv6服務器都是此組的成員。
UDP端口號
DHCPv6報文承載在UDPv6上。
客戶端偵聽的UDP目的端口號是546。
服務器、中繼代理偵聽的UDP端口號是547。
DHCP唯一標識符（DUID）
DHCP設備唯一標識符DUID（DHCPv6 Unique Identifier），每個服務器或客戶端有且只有一個唯一標識符，服務器使用DUID來識別不同的客戶端，客戶端則使用DUID來識別服務器。
客戶端和服務器DUID的內容分別通過DHCPv6報文中的Client Identifier和Server Identifier選項來攜帶。兩種選項的格式一樣，通過option-code字段的取值來區分是Client Identifier還是Server Identifier選項。
身份聯盟（IA）
身份聯盟IA（Identity Association）是使得服務器和客戶端能夠識別、分組和管理一系列相關IPv6地址的結構。每個IA包括一個IAID和相關聯的配置信息。
客戶端必須為它的每一個要通過服務器獲取IPv6地址的接口關聯至少一個IA。客戶端用給接口關聯的IA來從服務器獲取配置信息。每個IA必須明確關聯到一個接口。
IA的身份由IAID唯一確定，同一個客戶端的IAID不能出現重復。IAID不應因為設備的重啟等因素發生丟失或改變。
IA中的配置信息由一個或多個IPv6地址以及T1和T2生存期組成。IA中的每個地址都有首選生存期和有效生存期。
一個接口至少關聯一個IA，一個IA可以包含一個或多個地址信息。
DHCPv6報文類型
DHCPv6報文格式：
圖：DHCPv6的報文格式
| 字段 | 長度 | 含義 |
|---|---|---|
| msg-type | 1字節 | 表示報文的類型，取值為1～13，具體請參見DHCPv6報文類型。 |
| transaction-ID | 3字節 | DHCPv6交互ID，也叫事務ID，用來標識一個來回的DHCPv6報文交互。例如Solicit/Advertise報文為一個交互。Request/Reply報文為另外一個交互，兩者有不同的事務ID。交互ID特點如下：交互ID是DHCPv6客戶端生成的一個隨機值，DHCPv6客戶端應當保證交互ID具有一定的隨機性。對于DHCPv6服務器響應報文和相應的請求報文，兩者交互ID保持一致。如果是DHCPv6服務器主動發起的會話報文，則交互ID為0。 |
| Options | 可變 | 表示DHCPv6的選項字段。此字段包含了DHCPv6服務器分配給IPv6主機的配置信息，如DNS服務器的IPv6地址等信息。 |
DHCPv6報文類型：
目前DHCPv6定義了如下十三種類型報文，DHCPv6服務器和DHCPv6客戶端之間通過這十三種類型的報文進行通信。
DHCPv6和DHCPv4報文對比：
| 報文類型 | DHCPv6報文 | DHCPv4報文 | 說明 |
|---|---|---|---|
| 1 | SOLICIT | DHCP DISCOVER | DHCPv6客戶端使用Solicit報文來確定DHCPv6服務器的位置。 |
| 2 | ADVERTISE | DHCP OFFER | DHCPv6服務器發送Advertise報文來對Solicit報文進行回應，宣告自己能夠提供DHCPv6服務。 |
| 3 | REQUEST | DHCP REQUEST | DHCPv6客戶端發送Request報文來向DHCPv6服務器請求IPv6地址和其它配置信息。 |
| 4 | CONFIRM | - | DHCPv6客戶端向任意可達的DHCPv6服務器發送Confirm報文檢查自己目前獲得的IPv6地址是否適用與它所連接的鏈路。 |
| 5 | RENEW | DHCP REQUEST | DHCPv6客戶端向給其提供地址和配置信息的DHCPv6服務器發送Renew報文來延長地址的生存期并更新配置信息。 |
| 6 | REBIND | DHCP REQUEST | 如果Renew報文沒有得到應答，DHCPv6客戶端向任意可達的DHCPv6服務器發送Rebind報文來延長地址的生存期并更新配置信息。 |
| 7 | REPLY | DHCP ACK/NAK | DHCPv6服務器在以下場合發送Reply報文：DHCPv6服務器發送攜帶了地址和配置信息的Reply消息來回應從DHCPv6客戶端收到的Solicit、Request、Renew、Rebind報文。DHCPv6服務器發送攜帶配置信息的Reply消息來回應收到的Information-Request報文。用來回應DHCPv6客戶端發來的Confirm、Release、Decline報文。 |
| 8 | RELEASE | DHCP RELEASE | DHCPv6客戶端向為其分配地址的DHCPv6服務器發送Release報文，表明自己不再使用一個或多個獲取的地址。 |
| 9 | DECLINE | DHCP DECLINE | DHCPv6客戶端向DHCPv6服務器發送Decline報文，聲明DHCPv6服務器分配的一個或多個地址在DHCPv6客戶端所在鏈路上已經被使用了。 |
| 10 | RECONFIGURE | - | DHCPv6服務器向DHCPv6客戶端發送Reconfigure報文，用于提示DHCPv6客戶端，在DHCPv6服務器上存在新的網絡配置信息。 |
| 11 | INFORMATION-REQUEST | DHCP INFORM | DHCPv6客戶端向DHCPv6服務器發送Information-Request報文來請求除IPv6地址以外的網絡配置信息。 |
| 12 | RELAY-FORW | - | 中繼代理通過Relay-Forward報文來向DHCPv6服務器轉發DHCPv6客戶端請求報文。 |
| 13 | RELAY-REPL | - | DHCPv6服務器向中繼代理發送Relay-Reply報文，其中攜帶了轉發給DHCPv6客戶端的報文。 |
DHCPv6報文抓包：
tcpdump -iany ether proto 0x86dd -w ipv6.cap
wireshark過濾條件 dhcpv6 && dhcpv6.msgtype==1/2/3/4...：
---------------------------------------------------------------------------------------------------------------------------
Solicit報文（類型1）：
DHCPv6客戶端使用Solicit報文來確定DHCPv6服務器的位置。
圖：Solicit報文抓包示例
Advertise報文（類型2）：
DHCPv6服務器發送Advertise報文來對Solicit報文進行回應，宣告自己能夠提供DHCPv6服務。
圖：Advertise報文抓包示例
Request報文（類型3）：
DHCPv6客戶端發送Request報文來向DHCPv6服務器請求IPv6地址和其它配置信息。
圖：Request報文抓包示例
Confirm報文（類型4）：
客戶端發送給server的確認信息
Renew報文（類型5）：
DHCPv6客戶端向給其提供地址和配置信息的DHCPv6服務器發送Renew報文來延長地址的生存期并更新配置信息。
圖：Renew報文抓包示例
Rebind報文（類型6）：
如果Renew報文沒有得到應答，DHCPv6客戶端向任意可達的DHCPv6服務器發送Rebind報文來延長地址的生存期并更新配置信息。
圖：Rebind報文抓包示例
Reply報文（類型7）：
DHCPv6服務器在以下場合發送Reply報文：DHCPv6服務器發送攜帶了地址和配置信息的Reply消息來回應從DHCPv6客戶端收到的Solicit、Request、Renew、Rebind報文。
DHCPv6服務器發送攜帶配置信息的Reply消息來回應收到的Information-Request報文。用來回應DHCPv6客戶端發來的Confirm、Release、Decline報文。
圖：Reply報文抓包示例
Release(類型8);
DHCPv6客戶端向為其分配地址的DHCPv6服務器發送Release報文，表明自己不再使用一個或多個獲取的地址。
圖：Release報文抓包示例
Reply-forw報文（類型12）：
中繼代理通過Relay-Forward報文來向DHCPv6服務器轉發DHCPv6客戶端請求報文。
圖：Relay-Forw報文抓包示例
Relay-reply報文（類型13）：
DHCPv6服務器向中繼代理發送Relay-Reply報文，其中攜帶了轉發給DHCPv6客戶端的報文。
圖：Relay-Reply報文抓包示例
DHCPv6工作原理：
DHCPv6自動分配分為DHCPv6有狀態自動分配和DHCPv6無狀態自動分配。
DHCPv6有狀態自動分配。DHCPv6服務器自動配置IPv6地址/前綴，同時分配DNS、NIS、SNTP服務器等網絡配置參數。
DHCPv6無狀態自動分配。主機IPv6地址仍然通過路由通告方式自動生成，DHCP服務器只分配除IPv6地址以外的配置參數，包括DNS、NIS、SNTP服務器地址等參數。
DHVPv6有狀態自動分配：
IPv6主機通過有狀態DHCPv6方式獲取IPv6地址和其他配置參數（例如DNS服務器的IPv6地址等）。
DHCPv6服務器為客戶端分配地址/前綴的過程分為兩類：
DHCPv6四步交互分配過程
DHCPv6兩步交互快速分配過程
DHCPv6四步交互
四步交互常用于網絡中有多個DHCPv6服務器的情況。DHCPv6客戶端首先通過組播發送Solicit報文來定位可以為其提供服務的DHCPv6服務器，在收到多個DHCPv6服務器的Advertise報文后，根據DHCPv6服務器的優先級選擇一個為其分配地址和配置信息的服務器，接著通過Request/Reply報文交互完成地址申請和分配過程。
DHCPv6服務器端如果沒有配置使能兩步交互，無論客戶端報文中是否包含Rapid Commit選項，服務器都采用四步交互方式為客戶端分配地址和配置信息。
DHCPv6四步交互地址分配過程如下：
圖：DHCPv6四步交互地址分配過程
DHCPv6四步交互地址分配過程如下：
DHCPv6客戶端發送Solicit報文，請求DHCPv6服務器為其分配IPv6地址和網絡配置參數。
如果Solicit報文中沒有攜帶Rapid Commit選項，或Solicit報文中攜帶Rapid Commit選項，但服務器不支持快速分配過程，則DHCPv6服務器回復Advertise報文，通知客戶端可以為其分配的地址和網絡配置參數。
如果DHCPv6客戶端接收到多個服務器回復的Advertise報文，則根據Advertise報文中的服務器優先級等參數，選擇優先級最高的一臺服務器，并向所有的服務器發送Request組播報文，該報文中攜帶已選擇的DHCPv6服務器的DUID。
DHCPv6服務器回復Reply報文，確認將地址和網絡配置參數分配給客戶端使用。
DHCPv6兩步交互
兩步交互常用于網絡中只有一個DHCPv6服務器的情況。DHCPv6客戶端首先通過組播發送Solicit報文來定位可以為其提供服務的DHCPv6服務器，DHCPv6服務器收到客戶端的Solicit報文后，為其分配地址和配置信息，直接回應Reply報文，完成地址申請和分配過程。
兩步交換可以提高DHCPv6過程的效率，但在有多個DHCPv6服務器的網絡中，多個DHCPv6服務器都可以為DHCPv6客戶端分配IPv6地址，回應Reply報文，但是客戶端實際只可能使用其中一個服務器為其分配的IPv6地址和配置信息。為了防止這種情況的發生，管理員可以配置DHCPv6服務器是否支持兩步交互地址分配方式。
DHCPv6服務器端如果配置使能了兩步交互，并且客戶端報文中也包含Rapid Commit選項，服務器采用兩步交互方式為客戶端分配地址和配置信息。
如果DHCPv6服務器不支持快速分配地址，則采用四步交互方式為客戶端分配IPv6地址和其他網絡配置參數。
DHCPv6兩步交互地址分配過程如下圖：
圖：DHCPv6兩步交互地址分配過程
DHCPv6兩步交互地址分配過程如下：
DHCPv6客戶端在發送的Solicit報文中攜帶Rapid Commit選項，標識客戶端希望服務器能夠快速為其分配地址和網絡配置參數。
DHCPv6服務器接收到Solicit報文后，將進行如下處理：
如果DHCPv6服務器支持快速分配地址，則直接返回Reply報文，為客戶端分配IPv6地址和其他網絡配置參數，Replay報文中也攜帶Rapid Commit選項。
如果DHCPv6服務器不支持快速分配過程，則采用四步交互方式為客戶端分配IPv6地址/前綴和其他網絡配置參數。
DHCPv6無狀態自動分配：
IPv6節點可以通過DHCPv6無狀態方式獲取配置參數（包括DNS、SIP、SNTP等服務器配置信息，不包括IPv6地址）。
DHCPv6無狀態工作過程如下圖所示：
圖：DHCPv6無狀態工作過程
DHCPv6無狀態工作過程如下：
DHCPv6客戶端以組播方式向DHCPv6服務器發送Information-Request報文，該報文中攜帶Option Request選項，指定DHCPv6客戶端需要從DHCPv6服務器獲取的配置參數。
DHCPv6服務器收到Information-Request報文后，為DHCPv6客戶端分配網絡配置參數，并單播發送Reply報文，將網絡配置參數返回給DHCPv6客戶端。DHCPv6客戶端根據收到Reply報文提供的參數完成DHCPv6客戶端無狀態配置。
DHCPv6 PD工作原理：
DHCPv6前綴代理DHCPv6 PD(Prefix Delegation)是由Cisco公司提出的一種前綴分配機制，并在RFC3633中得以標準化。在一個層次化的網絡拓撲結構中，不同層次的IPv6地址分配一般是手工指定的。手工配置IPv6地址擴展性不好，不利于IPv6地址的統一規劃管理。
通過DHCPv6前綴代理機制，下游網絡設備不需要再手工指定用戶側鏈路的IPv6地址前綴，它只需要向上游網絡設備提出前綴分配申請，上游網絡設備便可以分配合適的地址前綴給下游設備，下游設備把獲得的前綴(一般前綴長度小于64)進一步自動細分成64前綴長度的子網網段，把細分的地址前綴再通過路由通告(RA)至與IPv6主機直連的用戶鏈路上，實現IPv6主機的地址自動配置，完成整個系統層次的地址布局。
DHCPv6 PD工作過程下圖所示：
圖：DHCPv6 PD工作原理
DHCPv6 PD四步交互地址分配過程如下：
DHCPv6 PD客戶端發送Solicit報文，請求DHCPv6 PD服務器為其分配IPv6地址前綴。
如果Solicit報文中沒有攜帶Rapid Commit選項，或Solicit報文中攜帶Rapid Commit選項，但服務器不支持快速分配過程，則DHCPv6服務器回復Advertise報文，通知客戶端可以為其分配的IPv6地址前綴。
如果DHCPv6客戶端接收到多個服務器回復的Advertise報文，則根據Advertise報文中的服務器優先級等參數，選擇優先級最高的一臺服務器，并向該服務器發送Request報文，請求服務器確認為其分配地址前綴。
DHCPv6 PD服務器回復Reply報文，確認將IPv6地址前綴分配給DHCPv6 PD客戶端使用。
DHCPv6中繼工作原理：
DHCPv6客戶端通過DHCPv6中繼轉發報文，獲取IPv6地址/前綴和其他網絡配置參數（例如DNS服務器的IPv6地址等）。
DHCPv6中繼工作過程如下圖所示：
圖：DHCPv6中繼工作原理
DHCPv6中繼工作交互過程如下：
DHCPv6客戶端向所有DHCPv6服務器和DHCPv6中繼發送目的地址為FF02::1:2（組播地址）的請求報文。
根據DHCPv6中繼轉發報文有如下兩種情況：
如果DHCPv6中繼和DHCPv6客戶端位于同一個鏈路上，即DHCPv6中繼為DHCPv6客戶端的第一跳中繼，中繼轉發直接來自客戶端的報文，此時DHCPv6中繼實質上也是客戶端的IPv6網關設備。DHCPv6中繼收到客戶端的報文后，將其封裝在Relay-Forward報文的中繼消息選項（Relay Message Option）中，并將Relay-Forward報文發送給DHCPv6服務器或下一跳中繼。
如果DHCPv6中繼和DHCPv6客戶端不在同一個鏈路上，中繼收到的報文是來自其他中繼的Relay-Forward報文。中繼構造一個新的Relay-Forward報文，并將Relay-Forward報文發送給DHCPv6服務器或下一跳中繼。
DHCPv6服務器從Relay-Forward報文中解析出DHCPv6客戶端的請求，為DHCPv6客戶端選取IPv6地址和其他配置參數，構造應答消息，將應答消息封裝在Relay-Reply報文的中繼消息選項中，并將Relay-Reply報文發送給DHCPv6中繼。
DHCPv6中繼從Relay-Reply報文中解析出DHCPv6服務器的應答，轉發給DHCPv6客戶端。如果DHCPv6客戶端接收到多個DHCPv6服務器的應答，則根據報文中的服務器優先級選擇一個DHCPv6服務器，后續從該DHCPv6服務器獲取IPv6地址和其他網絡配置參數。
IPv6地址/前綴的分配與更新原則：
IPv6地址分配的優先次序：
DHCPv6服務器按照如下次序為DHCPv6客戶端選擇IPv6地址/前綴。
選擇IPv6地址池
DHCPv6服務器的接口可以綁定IPv6地址池，DHCPv6服務器將選擇該IPv6地址池為接口下的DHCPv6客戶端分配地址/前綴。對于存在中繼的場景，DHCPv6服務器的接口可以不綁定IPv6地址池，而是根據報文中第一個不為0的“link-address”字段（標識DHCPv6客戶端所在鏈路范圍），選擇與地址池中已配置的網絡前綴或IPv6地址前綴屬于同一鏈路范圍的地址池。
選擇IPv6地址/前綴
確定地址池后，DHCPv6服務器將按照下面步驟為DHCPv6客戶端分配IPV6地址/前綴：
如果地址池中為客戶端指定了地址/前綴，優先從地址池中選擇與客戶端DUID匹配的地址/前綴分配給客戶端。
如果客戶端報文中的IA選項攜帶了有效的地址/前綴，優先從地址池中選擇該地址/前綴分配給客戶端。如果該地址/前綴在地址池中不可用，則另外分配一個空閑地址/前綴給客戶端。如果IPV6前綴長度比指定分配長度大，則按指定分配長度來分配。
從地址池中選擇空閑地址/前綴分配給客戶端，保留地址（例如RFC 2526中定義的任播地址）、沖突地址、已被分配的地址不能再分配給客戶端。
如果沒有合適的IPv6地址/前綴可以分配，則分配失敗。
DHCPv6地址租約更新：
DHCPv6服務器為DHCPv6客戶端分配的地址是有租約的，租約由生命期（包括地址的首選生命期和有效生命期構成）和續租時間點（IA的T1、T2）構成。地址有效生命期結束后，DHCPv6客戶端不能再使用該地址。在有效生命期到達之前，如果DHCPv6客戶端希望繼續使用該地址，則需要更新地址租約。
DHCPv6客戶端為了延長其與IA關聯的地址的有效生命期和首選生命期，在T1時刻，發送包含IA選項的Renew報文給服務器，其中IA選項中攜帶需要續租的IA地址選項。如果DHCPv6客戶端一直沒有收到T1時刻續租報文的回應報文，那么在T2時刻，DHCPv6客戶端通過Rebind報文向DHCPv6服務器繼續續租地址。
T1時刻地址租約更新過程如下：
DHCPv6客戶端在T1時刻（推薦值為優先生命期的0.5倍）發送Renew報文進行地址租約更新請求。
DHCPv6服務器回應Reply報文。
如果DHCPv6客戶端可以繼續使用該地址，則DHCPv6服務器回應續約成功的Reply報文，通知DHCPv6客戶端已經成功更新地址租約。
如果該地址不可以再分配給該DHCPv6客戶端，則DHCPv6服務器回應續約失敗的Reply報文，通知DHCPv6客戶端不能獲得新的租約。
T2時刻地址租約更新過程如下：
DHCPv6客戶端在T1時刻發送Renew請求更新租約，但是沒有收到DHCPv6服務器的回應報文。
DHCPv6客戶端在T2時刻（推薦值為優先生命期的0.8倍），向所有DHCPv6服務器組播發送Rebind報文請求更新租約。
DHCPv6服務器回應Reply報文。
如果DHCPv6客戶端可以繼續使用該地址，則DHCPv6服務器回應續約成功的Reply報文，通知DHCPv6客戶端已經成功更新地址/前綴租約。
如果該地址不可以再分配給該DHCPv6客戶端，則DHCPv6服務器回應續約失敗的Reply報文，通知DHCPv6客戶端不能獲得新的租約。
如果DHCPv6客戶端沒有收到DHCPv6服務器的應答報文，則到達有效生命期后，DHCPv6客戶端停止使用該地址。
IP地址預留：
DHCPv6服務器支持預留IPv6地址，即保留部分IPv6地址不參與動態分配。比如預留的IPv6地址可作為DNS服務器的IPv6地址。
DHCPv6
DHCPv6除了工作模式與DHCP類似以外，與DHCP也不兼容，它的協議內容也進行了重新定義。
因為IPv6中沒有廣播的概念，所以不像DHCP基于廣播地址255.255.255.255來發現DHCP Server，DHCPv6中，有兩個保留的組播地址，用來發現網絡中的DHCP Server：
All_DHCP_Relay_Agents_and_Servers (ff02::1:2)
DHCPv6 client使用這個地址將DHCP請求發送給所有的DHCPv6 relay（中繼）agent和DHCPv6 server，這樣可以發現網絡中的DHCPv6 Server
All_DHCP_Servers (ff05::1:3)
DHCPv6 relay agent通過這個地址將DHCP請求轉發給所有的DHCPv6 server
DHCPv6仍然是基于UDP協議，但是使用的是UDP的547（Server監聽端口）和546（Client監聽端口）。
IPv6協議下，每個網卡都默認帶一個link-local地址，這個地址是fe80::/10的前綴加上（一般情況下）網卡的MAC地址生成[RFC4291]。IPv6的link-local用來在一個二層鏈路中唯一標識一塊網卡，并且可以在有限場景下在一個二層鏈路中用來通信。
在DHCP（IPv4）協議下，DHCP Client在發起請求的時候，因為還沒有IP地址，所以源IP只能是Unspecified Address（0.0.0.0）。而DHCPv6 Client在發起請求的時候，網卡已經有IPv6地址了，所以源IPv6地址就是網卡的link-local地址，目的地址是DHCPv6保留的組播地址ff02::1:2
DHCPv6 Server在收到請求之后，將IPv6地址在單播回給Client網卡的link-local地址。其中IPv6地址包含在Advertise和Reply中，這個過程與DHCP類似。
兩個協議，三種模式
IPv6的動態地址配置主要依賴兩個協議，一個是DHCPv6（RFC8415），另一個是IPv6 Stateless Address Autoconfiguration（RFC4862）
實際應用中通常將DHCP Server配置在路由器上，或者路由器作為一個DHCP relay agent。如果沒有路由器，網絡只是一個二層網絡，作用有限。因此，這兩個設備本身可以只是一個設備，并且它們之中，路由器占主導地位。
基于這個背景，IPv6的動態地址配置有三種模式：
SLAAC，Stateless Auto Address Configuration
Stateless DHCPv6
Stateful DHCPv6
這里的Stateful，指的就是DHCP Server管理的IP地址，因為這些地址存在一個分配關系，需要一個程序去管理這個狀態。Stateless Address是指這個地址就是分配給某一個確定的主機使用，沒有其他狀態。
SLAAC
SLAAC基于協議RFC4861和RFC4862。在SLAAC的世界里，沒有DHCPv6。SLAAC協議由路由器來通告配置IPv6地址所需要的信息。具體工作流程是這樣：支持IPv6的網卡啟動的時候會發送一條RS（Router Solicitation）消息，源IP是網卡的link-local地址，目的IP是ff02::2。ff02::2也是保留的組播地址，用來表示所有的路由器。這條消息用來查找當前網絡中的路由器。
路由器收到這條消息之后，會回傳一條RA（Router Advertisement）。一般情況下，RA的源IP地址是Router的link-local地址，目的地址是ff02::1。ff02::1也是一個保留的組播地址，用來表示所有的主機。也就是說任意網卡發起的RS消息，都會引起路由器將RA消息在整個網絡中發送給所有的主機。除此之外，就算沒有任何RS消息，路由器也應當定期向所有主機發送RA。
RA可以發送給網絡中所有主機的基礎就是，不像DHCP消息，RA是無狀態的，任何主機接收到了RA消息之后，都能根據其中的信息完成IP地址配置。RA的options中通常包括：
MTU 主機可以根據這個MTU值配置自己的MTU 路由器的MAC地址0或者N個prefix（網段）
如果RA中一個prefix的auto標志位是1，那相當于告訴網卡，可以自己從這個prefix中生成一個IPv6的地址。網卡只需要使用一個局域網中唯一的標識符，再加上這個prefix，就能生成一個IPv6地址。網卡在局域網中的天然唯一標識符就是MAC地址，因此一般情況下，SLAAC協議中，網卡是通過RA中的prefix和自身的MAC地址，再根據EUI-64格式生成一個IPv6地址。SLAAC協議的基礎就是IPv6地址長度足夠大，能支持這樣的配置。
RA消息還能帶來一個潛在的配置，主機會將IPv6的默認網關，指向RA的源IP地址，也就是Router的link-local地址。生成的默認路由是有時效的，時間是Router Lifetime。所以需要路由器定時發布RA（類似于心跳），更新主機的默認路由。這個機制講道理是合理的，默認路由只有在路由器還活著的時候才有意義。但是這個機制增加了管理的復雜度，尤其在SDN場景，虛擬路由器下定時發布RA。
SLAAC協議有兩個問題，一個是IPv6的地址不可控了，一般情況下與主機的MAC地址相關；另一個是RA格式比較簡單，能傳遞的配置有限，一些復雜的主機配置無法通過RA傳遞。
但是好處是簡單，只用路由器，不需要DHCPv6的介入，就可以完成簡單的IP地址配置；另外無狀態地址能簡化管理，只需要一些簡單的程序就能完成Prefix分發，不需要集中的管理地址，處理多節點數據同步，這有點像分布式架構。SLAAC的配置過程如下如所示：
Stateless DHCPv6
Stateless DHCPv6就是結合了SLAAC和DHCPv6。其中IPv6地址配置通過SLAAC下發，其他配置通過DHCPv6下發。這樣能彌補SLAAC模式下，RA所能傳遞配置有限的問題。
Stateful DHCPv6
這里就是純純的DHCPv6了，但是前面說過，DHCPv6不支持子網掩碼長度，路由，和默認路由。這樣就導致通過DHCPv6獲得的IPv6地址，因為沒有掩碼長度，地址的掩碼都是128位。而路由和默認網關，還是需要依賴RA。因為在IPv6中，動態配置路由和默認網關的唯一方式就是使用Router Advertisement消息。所以，就算使用了DHCPv6，也不能完全擺脫RA消息。只是說DHCPv6下，IPv6地址變得可控了。所以，在IPv6動態地址配置中，Router Advertisement是必不可少的，因為它控制了主機路由和默認路由。同時Router Advertisement還控制了IPv6的動態地址配置模式。在RA的數據中，有兩個標志位M（Managed）和O（Other）。
當M=0，O=0時，IPv6地址工作在SLAAC模式下
當M=0，O=1時，IPv6地址工作在Stateless DHCPv6模式下
當M=1時，IPv6地址工作在Stateful DHCPv6模式下
深入研究自動分配IPv6地址的Stateless(無狀態)與Stateful(有狀態)方式
目錄
▪ 一. Link-Local Address的生成方式
▪ 二. Global Address的生成方式
▪ 三. RA報文中3個關鍵的Flag
▪ 四. 流程示意圖
▪ 五. 測試獲得IP效果
▪ 六. 應用場景（選擇無狀態還是有狀態）
▪ 七. 后續內容
▪ 附. 參考文檔
一. Link-Local Address的生成方式
生成“鏈路本地地址”，有2種方式
? 手動配置
? 自動配置
其中“自動配置”根據算法，又分為
? eui64：根據mac地址換算而來
? stable_secret：跟隨網絡環境的變化而變化，處于固定網絡環境時其值將固定
? random：隨機生成
二. Global Address的生成方式
生成“全球單播地址”（或者“唯一本地地址”），有2種方式
? 手動配置
? 自動配置
其中“自動配置”根據獲取方式，又分為
? 無狀態（Stateless）：根據路由通告報文RA（Router Advertisement）包含的prefix前綴信息自動配置IPv6地址，組成方式是Prefix + (EUI64 or 隨機)。Stateless也可以稱為SLAAC（Stateless address autoconfiguration）
? 有狀態（Stateful）：通過DHCPv6方式獲得IPv6地址
其中“有狀態”又分為2種
? 有狀態DHCPv6（Stateful DHCPv6）：IPv6地址、其他參數（如DNS）均通過DHCPv6獲取
? 無狀態DHCPv6（Stateless DHCPv6）：IPv6地址依然通過路由通告RA方式生成，其他參數（如DNS）通過DHCPv6獲取
為了避免混淆，在此解釋下有狀態、無狀態到底是什么意思：首先，請明確一點，有狀態、無狀態僅針對于IPv6地址分配方式，并不包含其他參數
? 有狀態：可控、可管理。在網絡中存在一個IP地址管理者，它能夠識別客戶端，根據不同的客戶端，分配對應的IPv6地址，客戶端與服務端之間需要維護IP地址的租期及續約。目前實現這種效果的，就是DHCPv6協議，IP地址管理者就是DHCPv6 Server
? 無狀態：不可控、難管理。在網絡中只有網關，沒有IP地址管理者。因此無人去識別客戶端，每個客戶端根據網關發送的相同的RA報文內容，自行配置IPv6地址
三. RA報文中3個關鍵的Flag
RA報文中存在3個關鍵的flag bit：
?Autonomous flag（簡稱A flag）：表示是否配置無狀態IP。在一個RA報文中，可存在多個prefix，比如2401::/64、2402::/64、2403::/64，每個prefix都可以獨立配置A flag
▪ 為on時（對應bit位為1）：表示客戶端應當在該prefix范圍內自動生成IPv6地址（客戶端通過DAD自行保證地址可用），并配置子網路由條目、網關
▪ 為off時（對應bit位為0）：表示客戶端不應當在該prefix范圍內自動生成IPv6地址，但是可以配置子網路由條目、網關
?Managed flag（簡稱M flag）：表示是否配置有狀態IP。M flag是RA報文的全局參數，一個RA報文只有一個M flag
▪ 為on時（對應bit位為1）：表示在stateless流程結束后開始stateful流程，也就是告訴客戶端可以通過DHCPv6來獲得IPv6地址和其他參數（如DNS列表）
▪ 為off時（對應bit位為0）：表示不通過DHCPv6來獲得IPv6地址。
?Other flag（簡稱O flag）：表示是否通過DHCPv6獲得除IP以外的其他參數（如DNS列表）。O flag也是RA報文中的全局參數，一個RA報文只有一個O flag。注意：僅當M flag為off時，該參數才會被讀取。
▪ 為on時（對應bit位為1）：當M flag為on，或者M flag為off且至少有一個A flag為on時，將通過DHCPv6獲得其他參數
▪ 為off時（對應bit位為0）：當M flag為on時，依然將通過DHCPv6獲得其他參數；當M flag也為off時，將不通過DHCPv6獲得其他參數
四. 流程示意圖
無狀態和有狀態并不是相互對立的，他們可以同時存在，也就是一張網卡上可以同時出現通過RA生成的IP以及通過DHCPv6獲得的IP。通過下面這張筆者繪制的流程圖可知曉其中奧秘。
從圖中可以看到，順序為：
1️⃣ Stateless自動配置“鏈路本地地址”
2️⃣ Stateless自動配置“全球地址”（或“唯一本地地址”）
3️⃣ Stateful自動配置“全球地址”（或“唯一本地地址”）和其他參數，其中Stateful階段中存在Stateful DHCPv6或Stateless DHCPv6
注意：部分客戶端操作系統或網絡管理器當Stateless階段沒有收到RA報文后，就到此結束，不會走Stateful階段，比如CentOS 7、Ubuntu 17的默認邏輯都是這樣，而windows server 2012就會繼續走Stateful階段。
五. 測試獲得IP效果
測試環境：客戶端基于CentOS 7+NetworkManager（即系統默認的網絡管理方式）進行測試
▪ 網關會發送RA報文，包含一個prefix
▪ DHCPv6 Server會分配IP、DNS
測試內容：測試M、O、A flag在所有排列組合的情況下
▪ 客戶端是否會通過RA報文配置無狀態IP
▪ 客戶端是否會通過RA報文配置prefix子網路由
▪ 客戶端是否會通過RA報文配置gateway
▪ 客戶端是否會通過DHCPv6獲得有狀態IP
▪ 客戶端是否會通過DHCPv6獲得DNS
測試結果：
六. 應用場景（選擇無狀態還是有狀態）
何時采用無狀態、何時采用有狀態，關鍵看應用場景。核心在于是否需要控制IP地址，比如保持IP不變，如果需要控制，就采用有狀態；如果無需控制，就采用無狀態。
? 服務端領域：如對外提供服務，通常需要采用有狀態IP。因為業務IP的突然變化容易導致業務中斷（除非做好服務發現）
? 客戶端領域：如移動設備、辦公室內PC機，只需要上IPv6互聯網，并不需要對外提供服務，可以采用無狀態IP
總結
- 上一篇： SAP Marketing Cloud功
- 下一篇： 只要200行JavaScript代码，就