DHCPv6-原理浅谈+报文示例+简易配置(SLAAC+DHCPv6+PD前缀代理)--RFC8415

个人认为，理解报文就理解了协议。通过报文中的字段可以理解协议在交互过程中相关传递的信息，更加便于理解协议。

因此本文将在DHCP协议报文的基础上进行介绍。

• 关于DHCP基本原理，可参考RFC2131-Dynamic Host Configuration Protocol。
• 关于DHCPv6基本原理，可参考RFC8415-Dynamic Host Configuration Protocol for IPv6。

• 关于DHCP协议基本原理，可参考博客 – DHCP-原理介绍+报文解析+配置示例—RFC2131。
• 关于DHCPv6协议的相关字段，可参考IANA的Dynamic Host Configuration Protocol for IPv6。
• 关于IPv6协议基本原理，可参考博客 – IPv6/ICMPv6-原理介绍+报文分析+配置示例。

…
DHCPv6还存在大量相关RFC，感兴趣者可查阅相关资料。

Note：RFC8415是一篇综合性标准文档，融合了大量先前内容。例如，RFC3633中关于 Prefixes Delegation内容；RFC3736中关于无状态DHCPv6内容；…等。有意者可阅读相关资料。
并且DHCPv6交互过程常与ND协议相关联，建议优先了解IPv6/ICMPv6协议等相关内容。
个人能力有限，这里仅涉及简易内容。敬请各位指导。

目录

1.DHCPv6协议原理

DHCPv6协议主要用于IPv6网络环境中，其协议背景与IPv4网络下的DHCP背景相类似。先期已进行相关介绍，这里直接进行相关内容说明。

1.1.DHCPv6术语

GUA：Global unicast address，IPv6全球单播地址。
ULA：Unique local address，IPv6私网地址。
binding：将身份关联信息与DHCPv6配置信息绑定的过程，与DHCP概念类似。
DHCP domain：单个管理实体负责的DHCP管理链路集合。

DUID：DHCP Unique Identifier，DHCP参与者唯一标识。每台设备仅有一个，不随时间而更改。DUID通常与设备的链路层地址有关，但不应当以DUID解析其链路层地址而是通过 Option79=Client Link-Layer Address option 来获取。

《RFC8415的11.DHCP Unique Identifier》定义了DUID的4种格式：
DUID-Type 1=Link-layer address plus time（DUID-LLT）；
DUID-Type 2=Vendor-assigned unique ID based on Enterprise Number（DUID-EN）；
DUID-Type 3=Link-layer address （DUID-LL）；
DUID-Type 4=Universally Unique Identifier（DUID-UUID）
自动换行//这里使用的是 DUID-Type 3=DUID-LL的DUID。两个字节的DUID Type=0x0003；两个字节的Hardware Type=0x0001；6个字节的Link-layer Address=0x00e0fc6c6b31。//这里则使用的是DUID-Type 1的格式。具体使用还是要看设备实际选择的方式。//dhcpv6 duid用来配置DHCPv6设备的唯一标识符DUID为Type1还是Type4。

IA：Identity Association，身份联盟。Client负责生成，向Server请求分配给Client的租约集合。IA中的配置信息由一个或多个IPv6地址以及T1和T2生存期组成。IA中的每个地址都有 preferred lifetime首选生存期和 valid lifetime有效生存期。一个接口至少关联一个唯一IA，一个IA可以包含一个或多个地址信息。
IAID：Identity Association Identifier，IA标识。IA的身份由IAID唯一确定，同一个客户端的IAID不能出现重复。
IA_NA：Identity Association for Non-temporary Addresses，非临时地址IA。
IA_PD：Identity Association for Prefix Delegation，前缀代理IA。与DHCPv6的前缀代理场景相关。
IA_TA：Identity Association for Temporary Addresses，临时地址IA。
这三种IA与DHCPv6工作模式相关。

@：Client必须至少将一个不同的 IA 与其每个网络接口相关联。
@：Client与接口关联的 IA 应当从该接口连接的服务器获取而来。
@：Option3=IA_NA 中的配置信息由一个或多个 IPv6 地址以及 IA 的 T1 和 T2 值组成。
@：IA_PD 与用于地址分配的 IA 不同，因为它不需要只与一个接口关联。 一个 IA_PD 可以与Client、一组接口或仅与一个接口相关联。 配置为请求 PD 的Client必须至少创建一个不同的IA_PD。
@：Option25=IA_PD 中的配置信息由一个或多个 IPv6 前缀以及 IA 的 T1 和 T2 值组成。
@：IA 中的每个地址都有一个 preferred lifetime首选生存期 和一个 valid lifetime有效生存期。
@：DHCPv6 Server不得分配保留IPv6地址给IA。
这三种IA Option将在后文进行介绍。

singleton option：只允许作为 top-level option 或任何封装级别出现一次的option。 大多数选项都是 singleton option。
top-level option：直接在DHCP消息中传达的option，即未封装在任何其他option中作为子option。
transaction ID：传输ID/交易ID，用于标识特定相应和回复的编码。与IPv4的DHCP中xid字段意义相同。

1.2.DHCPv6基本内容

1@：DHCPv6通常使用 Link-local链路本地地址 作为报文源地址。

《RFC8415的13.Assignment to an IA》中指出在某些情况下，允许其报文源地址非 Link-local链路本地地址。但需要Server使能相应功能。

2@：DHCPv6使用 ff02::1:2 作为报文目的地址。由于该地址为组播地址，因此DMac也为相应的组播Mac=33:33:00:01:00:02。

ff02::1:2：在RFC8415中称为 All_DHCP_Relay_Agents_and_Servers 组播地址。这一地址是Client使用具有链路范围的组播地址。 所有Server和中继代理都是此组播组的成员。
ff05::1:3：在RFC8415中称为 All_DHCP_Servers 组播地址。这一地址是中继代理所使用的具有站点范围的组播地址。因为中继代理希望将消息发送到所有Server，或者因为它不知道Server的单播地址。所有Server都是此组播组的成员。
组播/单播：通常Client向Server以组播消息作为目的地址。但如果Server携带 Option12=Server Unicast Option 向Client通知了Server单播地址，那么Client可通过单播方式进行交互。

3@：DHCPv6 Client使用546端口，监听来自Server的546端口，向Server使用的547端口发送消息；
DHCPv6 Server使用547端口，监听来自Client的547端口，向Client使用的546端口发送消息。

//DHCP报文帧头示例。

4@：类似与BGP的 Notification 消息，DHCPv6通过 Option13=Status Code option 来指示clients和servers之间交互可能出现的问题。

status-message使用UTF-8编码格式，介绍于RFC3926中。其值不得以空值结尾。
如果不包含该Option通常表示交互成功。

《RFC8415的7.DHCP Constants》中还定义一些用于程序执行上的相关参数，比如第一次 SOLICIT 最大时延为1s，重传间隔等。
《RFC8415的14.Transmission of Messages by a Client》详细描述了重传上的考虑，一个特性是不在租期到期后立刻进行RENEW和REBIND。
感兴趣者可查阅相关文档。

1.3.DHCPv6报文简介

DHCPv6目前已标准化了35种报文类型。与之前关于DHCP博客介绍的类似，这里仅简单介绍常用的13种报文类型。
报文详细内容，将在后文介绍。

msg-type Value	Description	Compared with DHCP	used
1	SOLICIT	DISCOVER	Client确定Server存在
2	ADVERTISE	OFFER	Server宣告可提供地址
3	REQUEST	REQUEST	Client请求地址及其他信息
4	CONFIRM	—	Client检查地址可用性
5	RENEW	REQUEST	Client第一次续租
6	REBIND	REQUEST	Client第二次续租
7	REPLY	ACK/NAK	Server对Client的回应
8	RELEASE	RELEASE	Client申请撤销地址
9	DECLINE	DECLINE	Client宣告地址的不可用性
10	RECONFIGURE	DISCOVER	Server宣告网络信息更新
11	INFORMATION-REQUEST	INFORM	Client请求其他网络信息
12	RELAY-FORW	—	Relay向Server转发请求消息
13	RELAY-REPL	—	Server向Relay回应网络信息

通用报文格式：
msg-type：1字节，用于标识DHCPv6报文格式。
transaction-id：3字节，用于标识Client/Server交互会话，与DHCP概念相同。
options：可变长选项，携带交互的相应信息。

中继报文格式：
msg-type：1字节，用于标识DHCPv6报文格式。这里仅有12标识 RELAY-FORW 和13标识 RELAY-RELY 两种。
hop-count：1字节，用于标识relay agents已经relay的次数。这里指的是途径中继节点的个数。在DHCP中未明确区分，实际上只有第一个relay节点处理相应消息。
link-address：16字节，Server可用于标识Client所在的链路的地址。 通常是 GUA 或 ULA。
peer-address：16字节，从中接收要中继消息的客户端或中继代理的地址。
options：可变长选项，携带交互的相应信息。

msg-type=13的 RELAY-RELY 消息中，hop-count、link-address和peer-address字段从msg-type=12的 RELAY-FORW 消息复制而来。
自动换行
DHCPv6报文示例：
//这里携带了携带了Option1=Client ID，Option3=IA_NA，Option6=ORO和Option8=ELAPSED_TIME。

报文消息的可用性：出于安全性等的考虑，RFC8514还给出了明显不符合报文交互流程的流程动作和报文内容。例如，Client不会处理 msg-type 1=Solicit 的消息，同样Server不会处理 msg-type 2=ADVERTISE 的消息。例如，msg-type 2=ADVERTISE 的消息应当包含 Option1=Client ID option 和 Option2=Server ID option。

点击此处回到目录

2.DHCPv6基本原理

2.1.DHCPv6的两种交互模型

Client/Server的两步交互模型：也即仅交互两次报文
当 DHCP Client 不需要让 DHCP Server 为其分配 IP 地址或 Prefix Delegation前缀代理时，Client可以通过与 DHCP Server 的单个消息和回复交换来获取其他例如DNS等配置信息。

这一过程通常和SLAAC结合使用。两步交互还可用于加快地址分配或 Prefix Delegation前缀代理。

1@Client：向 ff02::1:2 发送 msg-type 1=Solicit 消息，其中携带 Option14=Rapid Commit option。该Option表明 Client 愿意接受来自 Server 的即时回复消息。
2@Server：愿意分配地址和/或 Prefix Delegation前缀代理的 Server 会立即响应 msg-type 7=Reply 消息。

@分配给 Client 的每个地址或 Prefix Delegation 都具有 Server 指定的 preferred lifetimes 和 valid lifetimes。
@若要请求延长生存期，Client 会向 Server 发送 msg-type 5=Renew 消息。 Server 使用新的生存期向客户端发送 msg-type 7=Reply 消息，允许Client继续使用。
@如果 Server 无法延长地址或 Prefix Delegation 的生存期，则通过返回生存期为 0 的地址或 Prefix Delegation 来指示这一点。 同时，Server 可以分配其他地址或 Prefix Delegation。
@如果 msg-type 1=Solicit 消息中没有携带 Option14=Rapid Commit option，或消息中携带但Server不支持快速分配过程，则Server回复 msg-type 2=Advertise 报文随后按四步交互模型进行交互。

Client/Server的四步交互模型：这一交互过程与DHCP过程基本类似。
1@Client：向 ff02::1:2 发送 msg-type 1=Solicit 消息，查找可用的 DHCPv6 Server。
2@Server：任何可以满足Client要求的Server都会以 msg-type 2=ADVERTISE 消息进行响应。
3@Client：Client选择其中一个Server，并向Server发送 msg-type 3=REQUEST 消息，要求确认地址和/或前缀代理和其他配置信息的分配。
4@Server：Server使用包含已确认地址、前缀代理和配置的 msg-type 7=REPLY 消息进行响应。

此外，Client如果已经和Server协商监听 msg-type 10=RECONFIGURE。（Server可以通知Client网络信息的改变）。此时，Client通过发送 msg-type 11=Information-request、msg-type 5=Renew 或 msg-type 6=Rebind更新其配置。

2.2.DHCPv6的三种操作模型

本节介绍一些当前最常见的 DHCP 操作模型。 所描述的模型并不相互排斥，有时一起使用。

无状态DHCPv6：RFC3736-Stateless DHCP Server for IPv6
当 DHCP 不用于获取租约，但节点（DHCP 客户端）需要一个或多个 DHCP 其他配置参数（例如 除IPv6地址外的包括DNS[RFC3646]、SIP、SNTP等服务器配置信息）时，将使用无状态DHCP [RFC3736]。

1@Client：向 ff02::1:2 发送 msg-type 11=INFORMATION-REQUEST 消息，其中携带 Option6=ORO(Option Request option)。该Option表明Client所希望请求的信息。
2@Server：任何可以满足Client要求的Server都会以 msg-type 7=Reply 消息进行响应。 客户端将选择最先收到的Reply报文，并根据该报文中提供的参数完成客户端无状态配置。
这一NA过程通常进行两步交互，并且在交互前往往需要进行一次ND交互用于说明仅请求非IPv6地址以外的网络信息。

DHCPv6 for Non-temporary Address：适用于无状态DHCPv6不可用的情况。
这种模式是DHCP的最初目标。Client请求Server分配非临时地址。 Server分配适合于Client所连接链路的一个或多个地址。
每个地址都有关联的 preferred lifetimes 和 valid lifetimes。Client可以请求延长地址的生存期，并且如果地址的 preferred lifetimes 到期，则需要终止地址的使用。
这一NA过程通常使用DHCPv6四步交互分配模型或两步交互分配模型。具体使用上取决于对 Option14=Rapid Commit option 的支持能力。

DHCPv6 for Prefix Delegation：简单来说就是 PD Client/CPE/Requesting Router 向 PD Server/Agg Device/Delegating Router 请求IPv6大段前缀后，将其划分为小段前缀分配给 DHCP Client/Subscriber PC。
1@PD Client：首先发送 msg-type 1=SOLICIT 意味着 Prefix Delegation前缀代理过程开始。
2@PD Server：选择一个或多个可用的前缀通过 msg-type 2=Advertise 消息PD给Client。
3@PD Client：根据 msg-type 2=Advertise 消息中的Server优先级等参数，选择优先级最高的一台Server，发送 msg-type 3=Request报文以确认为其分配地址前缀。
4@PD Server：回复 msg-type 7=Reply报文，确认将IPv6地址前缀分配给DHCPv6 PD Client使用。
5@PD Client：将较长的前缀分配给Subscriber PC网络中的链路。这一过程主要通过 ICMPv6/NDP 协议的RA发现机制实现。

DHCPv6的多地址和前缀：
由于IPv6支持链路复用，也即一个路由器接口上可配置多个IPv6地址，这就可能发生DHCPv6获取多个地址和前缀的场景。RFC8415指出DHCPv6允许Client获取多个地址和前缀。基本原理在于通过 Option3=IA_NA 和 Option4=IA_TA 来实现。

Client：在初始DHCPv6交互过程中传递多个 Option3=IA_NA 和 Option4=IA_TA 来显式请求多个地址。
Server：将为每个 Option3=IA_NA 提供一个地址。
同样的原则也适用于 Prefix Delegation前缀代理过程，但通常不在PD过程中使用这种方式。Server的确切行为取决于相应策略。

关于RFC8514中介绍的 Customer Edge 场景和 Temporary Addresses 场景，这里不再进行描述。有意者可查阅相关资料。

RFC7084中详细说明了家用小型路由的CE场景下WAN侧的DHCPv6交互过程。此场景下的典型CE设备提供的IPv4网络往往承担NAT的角色，而IPv6可能存在差异。一种可能的方式是类似PD交互的过程，实际上CE也可通过PPP等方式提供IPv6服务。
引入临时地址最初是为了避免无状态地址自动配置的隐私问题，以便在使用有状态地址分配时提供补充支持。临时地址分配的工作方式与非临时地址分配大致相同。

点击此处回到目录

3.DHCPv6场景及过程浅谈

在实际应用时，DHCPv6交互过程往往受链路质量等情况影响。并且相关程序处理涉及多个判定，此处不进行细致的描述而仅介绍主要的交互过程。
Note：此处的场景交互仅作参考，实际的交互内容需考虑实际效果。

3.1.DHCPv6中继场景

在如上图所示场景中：
AR1：做DHCPv6 Server为DHCPv6 Client分配网络信息。
AR2：做DHCPv6 Relay设备为PC1和PC2中继DHCPv6报文。
AR3：做DHCPv6 Client，采用 SLAAC+DHCPv6 方式获取网络信息。
PC1/PC2：做DHCPv6 Client通过DHCPv6方式获取网络网络信息。
Note：此处的场景交互仅作参考，实际的交互内容需考虑实际效果。有相关问题可私信指导，以便本文及时更新错误。谢谢~

自动换行
AR1：

#
sysname AR1
#
ipv6 
#
dhcp enable
#
dhcpv6 pool pool2
 address prefix FC00:2::/64 life-time 71 61
 static-bind address FC00:2::20 duid 000300015489981041B9
 excluded-address FC00:2::1 to FC00:2::3
 dns-server fc00:1::1
 information-refresh 600
#
interface GigabitEthernet0/0/0
 ipv6 enable 
 ipv6 address FC00:1::1/64 
 ipv6 address FE80:1::1 link-local
 undo ipv6 nd ra halt
 ipv6 nd autoconfig other-flag
 dhcpv6 server pool2
#
ipv6 route-static :: 0 FC00:1::2 
#

1@这里在地址池中手动指定了 msg-type11=INFORMATION-REQUEST 消息的刷新时间，并且进行 DHCPv6 Client 的手动绑定。
2@由于AR3采用SLAAC方式获取地址，因此不应当将ND报文的 M-bit 置位。ND报文详细内容可参考博客 – IPv6/ICMPv6-原理介绍+报文分析+配置示例等其他资料。
3@DHCPv6中继报文的源地址为中继代理的Client侧接口地址，因此需要在 DHCPv6 Server 上配置lPv6路由保证其可达。

AR2：

#
sysname AR2
#
ipv6 
#
dhcp enable
#
interface GigabitEthernet0/0/0
 ipv6 enable 
 ipv6 address FC00:1::2/64 
 ipv6 address FE80:1::2 link-local
#
interface GigabitEthernet0/0/1
 ipv6 enable 
 ipv6 address FC00:2::1/64 
 ipv6 address FE80:2::1 link-local
 undo ipv6 nd ra halt
 ipv6 nd autoconfig managed-address-flag
 ipv6 nd autoconfig other-flag
 dhcpv6 relay destination FC00:1::1
#

AR3：

#
sysname AR3
#
ipv6 
#
dhcp enable
#
interface GigabitEthernet0/0/0
 ipv6 enable 
 ipv6 address FE80:1::3 link-local
 ipv6 address auto global default
 dhcpv6 client information-request
#

1@AR3这里使用SLAAC方式获取地址。
2@并且通过 msg-type 11=information-request 消息获取除地址以外的信息。

3.2.报文交互

1@PC<—>DHCPv6 Relay：
上图所示报文展示了 PC<—>DHCPv6 Relay 报文交互过程。仅作参考。
1@：其中夹杂了IPv6的 ICMPv6/NDP 协议的进行邻居发现和DAD，其主要作用类似于ARP的地址解析和重复地址检测。详细内容可参考博客 – IPv6/ICMPv6-原理介绍+报文分析+配置示例等其他资料。
2@：这里PC使用的是DHCPv6的四步交互模型，而非 Solicit/Replay 两步交互模型。两步交互模型不仅需要Client在发送 msg-type 1=Solicit 消息时携带 Option14=Rapid Commit Option 进行标识，并且需要Server支持提供该功能并在 msg-type 7=Reply 消息中同样携带该Option。由于网络中可能存在多台Server，此时有可能造成相应的混乱。
3@：这里成功获取到地址后还进行了 ND 的3次重复地址检测。如果有地址冲突的情况，Client将发送 msg-type 9 Decline 消息并携带 option13=Status Code Option 通知Server相应情况。随后重新发起DHCPv6交互过程。
4@：对于 PC/Client 而言，Relay的存在通常并不具有特别的意义。

1@PC—>DHCPv6 Relay=msg-type 1 Solicit：
Client 通常以组播方式将 Solicit 发向特定组播地址 ff02::1:2 ，并在其中必须携带 Option1 ，Option6 等信息。

Option1=Client ID用于唯一标识Client，通常与其链路层地址相关。但不得以该值解析其链路层地址，而是应当以 Option80=LINK_ADDRESS 交互信息为准。
Option3=IA_NA 和 Option8=Elapsed time在DHCPv6初始交互过程填0。
Option6=ORO为必须携带Option用于Client明确请求获得参数信息，相当于IPv4环境下DHCP的 Option55=Parameter Request List。

2@PC<—DHCPv6 Relay=msg-type 2 Advertise：
DHCPv6 Relay 代替Server回应 msg-type 2 Advertise 消息，其中必须携带 Option1 ，Option2 和其他Client请求的信息。

此处以单播方式进行回应。
其中必须携带 Option1=Client ID，Option2=Server ID。
在 Option3=IA_NA 中还携带了Server提供的地址租期和生存期。T1和T2分别默认为 Preferred lifetime 的0.5倍和0.8倍。
相应的回应了Client请求 Option6=ORO参数的 Option23=DNS recursive name server。

3@PC—>DHCPv6 Relay=msg-type 3 Request：
Client 通常以组播方式重新发送 IA 的相关请求。此时将携带具有参数意义的内容。

携带内容几乎与 msg-type 1=Solicit 消息相同。

4@PC<—DHCPv6 Relay=msg-type 7 Reply：
DHCPv6 Relay 代替Server回应 msg-type 7 Reply 消息，与msg-type 2 Advertise 消息几乎相同。

与msg-type 2 Advertise 消息几乎相同。

2@DHCPv6 Relay<—>DHCPv6 Server：
上图所示报文展示了 DHCPv6 Relay<—>DHCPv6 Server 报文交互过程。仅作参考。
1@：其中也可能夹杂了IPv6的 ICMPv6/NDP 协议的进行邻居发现和DAD。详细内容可参考博客 – IPv6/ICMPv6-原理介绍+报文分析+配置示例等其他资料。
2@：注意这里使用单播进行Relay和Server之间的报文交互。并且Relay以 PC/Client 侧的接口地址为源IPv6进行交互。
3@：简单而言这一部分就是将Client与Relay之间的报文封装在 Option9=Relay Message Option 中以 msg-type 12=Relay-forward 消息和 msg-type 13=Relay-reply 消息承载进行交互。

1@DHCPv6 Relay—>DHCPv6 Server=msg-type 12 Relay-forward：2@DHCPv6 Server—>DHCPv6 Relay=msg-type 13 Relay-reply：
其余两次交互过程不在展示。

3@DHCPv6 Client<—>DHCPv6 Server：SLAAC+DHCPv6
*上图所示报文展示了 SLAAC+DHCPv6 报文交互过程。
其中夹杂了IPv6的 ICMPv6/NDP 协议的进行邻居发现和DAD。详细内容可参考博客 – IPv6/ICMPv6-原理介绍+报文分析+配置示例等其他资料。此处仅作报文交互参考。

ICMP/NDP的交互过程
1@：首先 DHCPv6 Client 在接口Up起来后进行了一次 fe80:1::3链路本地地址的 DAD 重复地址检测。
2@：随后 DHCPv6 Client 与 DHCPv6 Server 进行了3次 RS/RA 交互，以便进行路由器和前缀发现。
3@：DHCPv6 Client 在第一次前缀发现后，SLAAC自动生成了一个 GUI IPv6地址并进行该地址的DAD重复地址检测。
//这里SLAAC生成的地址为fc00:1::2e0:fcff:fe2c:74c8。
4@：DAD重复地址检测完成后，DHCPv6 Client 与 DHCPv6 Server 开始进行其他网络参数的 DHCPv6 交互过程。
5@：之后的时间 DHCPv6 Server “周期性”泛洪 RA 消息。

1@DHCPv6 Client—>DHCPv6 Server=msg-type 11 Information-request：
Client 通常以组播方式发送相关请求，此时请求除IPv6地址以外的其他网络参数信息。
2@DHCPv6 Client<—DHCPv6 Server=msg-type 7 Reply：
Server以单播方式回应option6=ORO中的相关内容。

//msg-type 11=Information-request，无特别注意内容
自动换行//msg-type 7=Reply，无特别注意内容。Option32=Information Refresh Time Option 中内容为DHCPv6 Server中指定的 information-refresh 600 时间，未指定时默认取 IRT_DEFAULT =86400s。

点击此处回到目录

3.3.Prefix Delegation 前缀代理场景

在如上图所示场景中：
AR1：做DHCPv6 PD Server为DHCPv6 Client分配网络信息。
AR2：做DHCPv6 PD Client设备为PC1和AR3请求前缀信息。
PC1/AR3：做DHCPv6 Client，采用SLAAC方式获取网络信息。
Note：此处的场景交互仅作参考，实际的交互内容需考虑实际效果。有相关问题可私信指导，以便本文及时更新错误。谢谢~

自动换行
AR1：

#
sysname AR1
#
ipv6 
#
dhcp enable
#
dhcpv6 pool pool1
 prefix-delegation FC00:1::/60 63
 dns-server 2001:DB8::1
 dns-server 2001:DB8::2
#
interface GigabitEthernet0/0/0
 ipv6 enable 
 ipv6 address FC00:1::1/64 
 ipv6 address FE80:1::1 link-local
 undo ipv6 nd ra halt
 ipv6 nd autoconfig managed-address-flag
 ipv6 nd autoconfig other-flag
 dhcpv6 server pool1
#

AR2：

#
sysname AR2
#
ipv6 
#
dhcp enable
#
interface GigabitEthernet0/0/0
 ipv6 enable 
 ipv6 address FE80:1::2 link-local
 ipv6 address auto global default
 dhcpv6 client pd myprefix
#
interface GigabitEthernet0/0/1
 ipv6 enable 
 ipv6 address myprefix ::1:0:0:0:1/64
 ipv6 address FE80:2::1 link-local
 undo ipv6 nd ra halt
 ipv6 nd autoconfig other-flag
#

AR3：

#
sysname AR3
#
ipv6 
#
interface GigabitEthernet0/0/0
 ipv6 enable 
 ipv6 address FE80:2::3 link-local
 ipv6 address auto global default
#

3.4.报文交互

上图所示报文展示了 DHCPv6 PD Client<—>DHCPv6 PD Server 报文交互过程。仅作参考。
1@：其中夹杂了IPv6的 ICMPv6/NDP 协议的进行邻居发现和DAD，其主要作用类似于ARP的地址解析和重复地址检测。详细内容可参考博客 – IPv6/ICMPv6-原理介绍+报文分析+配置示例等其他资料。
2@：从报文交互流程上看，与普通DHCPv6场景无较大差别。

1@DHCPv6 PD Client—>DHCPv6 PD Server=msg-type 1 Solicit：
//主要差别在于DHCPv6中携带的 IA 内容为 option25=IA_PD ，请求IPv6前缀信息。此外还需要注意的是与 Relay 场景不同，交互的报文源地址不再是用户侧的接口地址。

2@DHCPv6 PD Client<—DHCPv6 PD Server=msg-type 2 Advertise：
//相应的DHCPv6 PD Server回应相应的前缀信息。

3@DHCPv6 PD Client—>DHCPv6 PD Server=msg-type 3 Request：
略。可参考先前内容。
4@DHCPv6 PD Client<—DHCPv6 PD Server=msg-type 7 Reply：
略。可参考先前内容。

AR2和AR3交互获取地址的过程可参考《3.1.DHCPv6中继场景》中的 SLAAC+DHCPv6 介绍内容。

3.5.信息查看

这里以《3.3.Prefix Delegation 前缀代理场景》场景为例进行简单查看
//display dhcpv6 pool，查看地址池情况。
//display dhcpv6 server interface GigabitEthernet 0/0/0，查看接口功能
//display dhcpv6 duid，查看设备duid。
//display dhcpv6 client，查看设备作为client时的相关信息。
//display dhcpv6 client statiistics，查看设备DHCPv6报文统计。
AR2和AR3上都获取到相应地址。

3.6.其他报文及协议细节

msg-type 8=Release：
//携带需要释放的 IA 信息，组播发送。

缺省路由：
需要注意的一点是，此种方式获得的缺省路由下一跳都为链路本地地址。
//注意DHCPv6 use network route 路由优先级为64，而DHCP默认为60。

点击此处回到目录

参考/附录：DHCPv6常用Option

每个Option可能仅出现在 DHCPv6 消息的Option区域中，并且只能出现一次。

如果一个Option确实出现多次，则每个实例都被视为单独的，并且Option的数据区域不得串联或以其他方式组合。只允许出现一次的选项称为 singleton option。

常用的 singleton option 有 Option3=IA_NA 、Option4=IA_TA 、Option16=Vendor Class、Option17=Vendor-specific Information 和 Option25=IA_PD。

通用Option格式：
option-code：2字节，Option类型。目前定义了约150种左右Option。
option-len：2字节，Option-data字段长度。
Option-data：不定长。

Option1=Client ID option 和 Option2=Server ID option：
两种Option都只包含DUID，用于唯一识别Client和Server。通常与链路层地址相关，前文已进行DUID介绍。

Option3=IA_NA：
IAID：4字节，IA标识。IAID 在此Client的所有 IA_NAs 列表中必须是唯一的，并且IA_NA、IA_TA和IA_PD的编号空间是隔离的。
T1：4字节，Client请求或Server分配的 IA_NA 地址的生存期，以秒为单位表示。
T2：4字节，Client请求或Server分配的 IA_NA 地址的延长生存期，以秒为单位表示。
IA_NA-Option：可变长，与 IA_NA 相关的Option。

@：每个 IA_NA 都包含一个非临时地址。
@：一个DHCPv6消息可能包含多个 IA_NA Option。
@：IA_NA Option 本身没有生存期或租期的概念，这一概念对应的是IPv6地址。当 IA_NA 中所有地址的 valid lifetimes有效生存期 已过期时，可以将 IA_NA 视为已过期。
@：当Client发送该Option时，T1和T2字段应当置0。相应的Server忽略来自Client该消息的这两个字段。
@：建议T1和T2分别取值为Server所提供地址的 preferred lifetime首选生存期 的0.5和0.8倍。如果Server所提供地址的 preferred lifetime首选生存期是无穷大的 0xffffffff。T1和T2也应取该值。DHCP为IPv4提供的是0.5和0.875。
@：如果Server提供的 IA_NA-Option 中T1和T2字段为0，表示更新 IA_NA 中的地址的时间由Client自行决定。如果Client已经确定自行决定地址时间，那么也将忽略Server提供的 IA_NA-Option 中T1和T2字段并处理消息的其余部分。
自动换行//address prefix 2001:DB8::/64 life-time 100 80 手动指定DHCPv6 地址池的 Preferred lifetime 和 Valid lifetime 分别为80s和100s。
//T1和T2往往代表着DHCPv6 Client两次续租的时间，分别取 Preferred lifetime 的0.5和0.8倍。而DHCP的两次续租时间分别为0.5和0.875倍。
//renew-time-percent rebind-time-percent命令用于配置IPv6地址池的T1续租时间和T2重绑定时间。

Option4=IA_TA：
IAID：4字节，IA标识。IAID 在此Client的所有 IA_NAs 列表中必须是唯一的，并且IA_NA、IA_TA和IA_PD的编号空间是隔离的。
IA_TA-Option：可变长，与 IA_TA 相关的Option。

@：每个 IA_TA 都包含一个临时地址。
@：一个DHCPv6消息可能包含多个 IA_TA Option。
@：IA_TA Option 本身没有生存期或租期的概念，这一概念对应的是IPv6地址。当 IA_TA 中所有地址的 valid lifetimes有效生存期 已过期时，可以将IA_NA视为已过期。
@：IA_TA Option 不包含T1和T2概念。Client可以发送携带该Option的 msg-type=5的 RENEW 消息和 msg-type=6的 REBINDING 消息，以延长 valid lifetime有效生存期。仅延长 valid lifetime有效生存期 而不延长 preferred lifetime首选生存期 意味着地址最终将处于弃用状态。
@：Client通过向Server发送带有新 IAID 的 IA_TA Option 来获取新的临时地址，也可以在临时地址到期后重复使用 IAID 来标识具有新临时地址的新IA_TA。

Option5=IA Address Option：
IPv6-address：16字节，IPv6地址。
preferred-lifetime：4字节，IPv6地址的 preferred lifetime首选生存期，以秒为单位表示。
valid-lifetime：4字节，IPv6地址的 valid lifetime有效生存期，以秒为单位表示。
IAaddr-options：可变长，与 IPv6地址 相关的Option。

@：如果Client向Server发送的消息中携带该Option，preferred lifetime首选生存期 和 valid lifetime有效生存期 应当置0。相应的Server应忽略该字段。
@：Client丢弃Server发送的消息中携带该Option中 preferred lifetime首选生存期 大于 valid lifetime有效生存期 的地址。
@：一个 Option3=IA_NA 或 Option4=IA_TA中可以携带多个 Option5=IA Address Option。

Option6=Option Request Option（ORO）：
requested-option-code-n：不定长，携带Client所需请求的option。作用类似DHCP报文中的 Option55=Parameter Request List。

@：client必须在 msg-type 1=Solicit, msg-type 3=Request，msg-type 5=Renew，msg-type 6=Rebind 和 msg-type 11=Information-request 消息中携带该option。
@：处于安全考虑，某些Option-code不应出现在 requested-option-code-n 字段中。例如，Option1=Client ID Option、Option2=Server ID Option、Option3=IA_NA、Option4=IA_TA、Option5=IA Address Option、Option6=Option Request Option和Option8=Elapsed Time等。
@：只有 top-level 可能出现在 Option6=Option Request Option 中，并且只有Client请求Option后Server才会提供对应Option的响应。

Option7=Preference Option：
pref-value：1字节，用于Server告知Client优先级。可用于多个Server时的地址优选。通常优选pref-value最大的 Advertise 中的 IA 信息。

//服务器可以在Advertise报文中包含Preference选项，以便控制客户端对服务器的选择。

Option8=Elapsed Time Option：
elapsed-time：2字节，Client启动DHCPv6交互至今的时间，单位为0.01s。这里指的是每一次交互过程而非整个DHCPv6启动的时间，是与DHCPv6中 Transaction ID 字段相关联的时间。

@：client必须在消息中包含 Option8=Elapsed Time Option 以通知Server自己试图完成DHCP交互的时间。
@：该字段可帮助备用Server了解主用Server的失效而提供响应。
@：elapsed-time取0xffff时表示无穷大。

Option9=Relay Message Option：
DHCP-relay-message：不定长，在 msg-type 12=Relay-forward 消息中携带。Server在 msg-type 13=Relay-reply 消息中复制回应。

Option13=Status Code Option：
status-code：2字节，描述状态的编码。
status-message：使用UTF-8编码格式，介绍于RFC3926中。其值不得以空值结尾。如果不包含该Option通常表示交互成功。

Option14=Rapid Commit Option：
Client计划以 msg-type 1=Solicit/msg-type 7=Reply 两步交互模型启动时使用。

@：两步交互模型使用需要Client和Server都支持相应功能。
@：如果Server支持该功能，应在 msg-type 7=Reply 消息中也携带 Option14=Rapid Commit Option。
@：由于网络中多台Server都携带租期进行响应的可能，应当设计 DHCP 服务，以便只有一台Server响应请求。

Option18=Interface-Id Option：
interface-id：不定长，用于标识来自 relay agent 的接口信息。

@：该option必须仅出现在 msg-type 12=Relay-forward 和 msg-type 13=Relay-reply 消息中。
@：Server回应 msg-type 13=Relay-reply 消息时，应保证该字段与 msg-type 12=Relay-forward 消息中字段一致。//dhcpv6 interface-id insert enable在收到的DHCPv6报文中插入Interface-ID选项。

Option25=IA_PD：
IAID：4字节，IA标识。IAID 在此Client的所有 IA_PDs 列表中必须是唯一的，并且IA_NA、IA_TA和IA_PD的编号空间是隔离的。
T1：4字节，Client请求或Server分配的 IA_PD 地址的生存期，以秒为单位表示。
T2：4字节，Client请求或Server分配的 IA_PD 地址的延长生存期，以秒为单位表示。
IA_PD-Option：可变长，与 IA_PD 相关的Option。

@：一个DHCPv6消息可能包含多个 IA_PD Option。
@：IA_PD Option 本身没有生存期或租期的概念，这一概念对应的是IPv6地址。当 IA_PD 中所有地址的 valid lifetimes有效生存期 已过期时，可以将 IA_PD 视为已过期。
@：当PD Client发送该Option时，T1和T2字段应当置0。相应的Server忽略来自Client该消息的这两个字段。
@：建议T1和T2分别取值为Server所提供地址的 preferred lifetime首选生存期 的0.5和0.8倍。如果Server所提供地址的 preferred lifetime首选生存期是无穷大的 0xffffffff。T1和T2也应取该值。
@：如果Server提供的 IA_PD-Option 中T1和T2字段为0，表示更新 IA_PD 中的地址的时间由Client自行决定。如果Client已经确定自行决定地址时间，那么也将忽略Server提供的 IA_PD-Option 中T1和T2字段并处理消息的其余部分。

Option26=IA Prefix Option：
preferred-lifetime：4字节，IPv6前缀的 preferred lifetime首选生存期。
valid-lifetime：4字节，IPv6前缀的 valid lifetime有效生存期。
prefix-length：1字节，IPv6前缀的长度。
IPv6-prefix：16字节，IPv6前缀。
IAprefix-options：可变长，与 IPv6前缀 相关的Option。

@：如果PD Client向Server发送的消息中携带该Option，preferred lifetime首选生存期 和 valid lifetime有效生存期 应当置0。相应的Server应忽略该字段。并且PD Client发送时，不应将 prefix-length 字段置0。
@：Client丢弃Server发送的消息中携带该Option中 preferred lifetime首选生存期 大于 valid lifetime有效生存期 的地址。
@：Option26=IA Prefix Option 只能出现在 Option25=IA_PD 中。但其可以携带多个 Option26=IA Prefix Option。

Option32=Information Refresh Time Option：
information-refresh-time：4字节，以秒为单位表示。相对于当前时间的持续时间，也即配置信息刷新时间。

@：Client向Server发送 msg-type11=Information-request 的消息中 Option6=ORO 中必须携带该Option。
@：此Option只能出现在 msg-type7=Reply 消息的top-level options 区域中。并且值必须不小于 IRT_MINIMUM=600s或者Client认为该值不小于600s。如果 msg-type7=Reply 消息不包含此Option，则Client认为其提供了值为 IRT_DEFAULT=86400s 的Option。
@：取值0xffffffff时表示无穷大。

Option37=Relay Agent Remote-ID Option：
enterprise-number：4字节，设备制造商于IANA注册的企业标识。
remote-id：不定长，remote-id.。

@：remote-id 字段可以编码拨号连接的 caller ID，远程访问的用户名，DUID，VLAN，接口或端口标识符。
@：每个设备制造商必须确保 remote-id 对于其企业编号是唯一的。
@：DHCPv6 relay agents 可能会在 msg-type 12=RELAY-FORW 消息中携带该option，但Server的回应消息 msg-type 13=RRELAY-REPL 可能不会携带该Option。这一点与DHCP不同。
@：Option37=Relay Agent Remote-ID Option的作用相当于DHCP的 Option82=Relay Agent Information 属性。
//dhcpv6 remote-id insert enable用于DHCPv6中继代理插入 Remote-ID（Option37）Option。

Option79=Client Link-Layer Address Option：
link-layer type：2字节，Client的链路层地址类型。
link-layer address：不定长，Client的链路层地址。

点击此处回到目录

更新