DHCP / DHCPv6 原理 / 报文解析 / 配置示例

注：本文为“DHCP”相关合辑。

图片清晰度受引文原图所限。
略作重排，如有内容异常，请看原文。

---

DHCP 原理介绍 + 报文解析 + 配置示例 — RFC2131

fengxingzhe008 已于 2023-12-11 20:37:42 修改

前言

个人认为，理解报文就理解了协议。通过报文中的字段可以理解协议在交互过程中相关传递的信息，更加便于理解协议。因此本文将在 DHCP 协议报文的基础上进行介绍。

1 背景介绍

1.1 DHCP 简介

DHCP 的需求主要来自于网络规模的扩大和网络复杂度的提高。终端位置变化（如便携机或无线网络）和计算机数量超过可分配的 IP 地址，造成 IP 地址变化频繁以及 IP 地址不足的情况。此时，人力将难以胜任该工作。

DHCP 是 Dynamic Host Configuration Protocol（动态主机配置协议）的简称，是一种对用户进行集中的动态管理和配置的技术。DHCP 技术保证了 IP 地址的合理分配问题，从而避免了 IP 地址的浪费，提高了整网的 IP 地址使用率。

1.2 网络发展

在网络发展的初期，可以部署 RARP 服务器来为特定主机分配 IP 地址。主要用于无盘工作站，在网卡启动时发送携带自身 Mac 地址的请求报文。RARP 服务器为其分配相应的 IP 地址后，终端可正常工作。关于 RARP 基本原理，可参考博客 ARP/RARP 原理介绍 + 报文分析 + 配置示例。

后续发展出了 BOOTSTRAP PROTOCOL 协议，也即 BOOTP 协议。无盘系统也可通过该协议获取相应的 IP 地址。除此之外，BOOTP 协议还可获取子网掩码和 DNS 等相关信息。关于 BOOTP 协议，可参考 RFC951-BOOTSTRAP PROTOCOL (BOOTP)。

DHCP 协议则相当于 BOOTP 协议的升级 Plus 版。因为 BOOTP 协议一个很大缺点在于为主机分配的 IP 是静态的。DHCP 协议使用 Client/Server 架构，继承了 BOOTP 协议大部分内容。两者都使用 UDP 的 67 和 68 端口进行信息交互。但 DHCP 可支持地址的动态分配，并具有多种 Option 属性具有丰富的可扩展性。

1.3 相关特性

RFC2131-Dynamic Host Configuration Protocol 中介绍 DHCP 支持三种地址分配方式：

1. automatic allocation（自动分配）：DHCP 为 Client 分配一个永久 IP 地址。
2. dynamic allocation（动态分配）：DHCP 在有限的时间段内（或直到 Client 明确放弃该地址）将 IP 地址分配给 Client。动态分配是三种机制中唯一一种允许自动重用 Client 不再需要特定地址的方式。
3. manual allocation（手动分配）：Client 的 IP 地址由网络管理员分配，DHCP 仅用于将分配的地址传达给 Client。特定网络将使用其中一种或多种机制，具体取决于网络管理员的策略。

DHCP 设计目标：

1. DHCP 必须允许本地系统管理员根据需要控制配置参数。例如，本地系统管理员应该能够在需要时执行有关分配和访问本地资源的本地策略。
2. Client 不应要求手动配置。每个 Client 都应该能够在没有用户干预的情况下发现适当的本地配置参数，并将这些参数合并到自己的配置中。
3. 网络不应要求对单个 Client 进行手动配置。在正常情况下，网络管理器不必为每个 Client 配置参数。
4. DHCP 不应要求每个子网上都有 Server。DHCP 必须允许跨路由器或通过 BOOTP delay 的干预工作。
5. DHCP Client 必须准备好接收对配置参数请求的多个响应。某些安装可能包括多个重叠的 DHCP Server，以增强可靠性和提高性能。
6. DHCP 必须与 RFC 951 和 RFC 1542 所述的 BOOTP 中继代理行为进行互操作。DHCP 必须为现有的 BOOTP Server 提供服务。
7. 保证任何特定的网络地址不会同时被多个 DHCP Client 使用。
8. DHCP Client 重新启动期间保留 DHCP Client 配置。应尽可能为 DHCP Client 分配相同的配置参数（例如，网络地址）以响应每个请求。
9. 在 Server 重新启动时保留 DHCP Client 配置，并且，只要有可能，尽管重新启动了 DHCP 机制，仍应为 DHCP Client 分配相同的配置参数。
10. 允许自动将配置参数分配给新客户端，以避免手动配置新客户端。
11. 支持将配置参数固定或永久分配给特定客户端。

2 DHCP 基本原理

在具体介绍之前，这里先介绍 DHCP 底层封装：

1. 这里显示为广播帧是特定 DHCP 报文的显示结果，后续进行介绍。
2. IP 报文中的通常用于 QOS 的 DSCP 字段为 0，是低等级的优先报文。这一点与 OSPF/BGP 不同。
3. IP 报文中的 TTL 字段为 128，这一特点允许其跨局域网进行转发。而其他协议报文则有明确限制，例如 IGMP 的 TTL = 1，OSPF 的 TTL = 1，VRRP 的 TTL = 255。这些特定 TTL 都是基于协议安全的考虑。
4. 使用 IP 协议号 17（也即 UDP 协议）进行承载。DHCP/BOOTP 使用 67/68 作为目的端口进行识别。
   • 其中 DHCP Client 使用 68 端口，监听来自 Server 的 68 端口，向 Server 使用的 67 端口发送消息；
   • DHCP Server 使用 67 端口，监听来自 Client 的 67 端口，向 Client 使用的 68 端口发送消息。

@1：这里的 IP TTL 仅用于说明协议未做严格限制。一个重要考虑可能是 Relay 中继情况下跨越多个子网的情况。

// dhcp set ttl 命令用于 DHCP 请求报文在经过 DHCP 中继三层转发之后的处理情况。自动换行

@2：UDP 的 SPort 未使用 68 作为 Client 的 SPort，应与网卡厂家的 DHCP 实现相关。

2.1 DHCP 基本报文格式

• Op – Message op code / message type：1 字节。表示 DHCP/BOOTP 报文类型 – 取值 1 表明为 BOOTREQUEST（Client 发给 Server），取 2 表明为 BOOTREPLY（Server 发给 Client）。
• Htype – Hardware address type：1 字节。取值 1 表示为 10M Ethernet，目前也沿用该值。
• hlen – Hardware address length：1 字节。取值 6 表示为 10M Ethernet，目前也沿用该值。
• hops：1 字节。Client 通常设备为 0，在中继代理是有意义。
• xid：4 字节。Transaction ID，Client 选择的随机数。可用于标识特定会话。Client 和 Server 的交互需要 xid 一致。
• secs：2 字节。由 Client 填写自 Client 开始地址获取或续订过程地址以来已经过去了几秒钟。
• flags：2 字节。目前仅第一个 bit 使用，broadcast flag。取 1 时标识报文为广播报文。
  • 当 DISCOVER 的 BOOTP Flag 的 B-bit 未置位，Server 应当以单播方式进行回应 OFFER 消息。
• ciaddr：4 字节。Client IP address。仅当 Client 处于绑定、续订或重新绑定状态并且可以响应 ARP 请求时才填写。
• yiaddr：4 字节。“your”（client）IP address。也即 DHCP Server 告知 Client 分配到的地址。
• siaddr：4 字节。bootstrap 引导所使用的下一个服务器的地址。在 DHCPOFFER，DHCPACK 中携带。
• giaddr：4 字节。Relay agent IP address。在中继场景下使用。
• chaddr：16 字节。Client hardware address。
• sname：64 字节。Server Host Name。可选的 Server 主机名，以 Null 结尾的字符串。
• file：128 字节。Boot file name，以 Null 结尾的字符串。
• Option：可变长。DHCP Client 必须准备好接收长度至少为 312 * 8 字节的“选项”字段的 DHCP 消息。

DHCP Option 前 4 个字节为 magic cookie。RFC1497 中解释用于后续数据的模式说明。通常固定为 0x63，0x82，0x53 和 0x63。
DHCP Option 最后 1 个字节为 Option255，该 Option 无 length 和 value 字段。
DHCP Option 其余字段采用 TLV 的格式进行定义：

• Type/Option = 1 字节，用于说明 Option 类型。也即 DHCP 最多有 255 种 Option；
• Length = 1 字节，用于说明 Value 字段的长度。也即 Value 字段最多有 255 字节；
• Value = 可变长，用于携带 DHCP 的具体参数信息。

DHCP 报文示例：

// 上图为 DHCP 的一个报文示例。自动换行
Q：从上文的 DHCP/BOOTP 报文字段介绍中，我们可以发现在通用字段中只能标识报文发送类型。那么报文的具体类型应该如何体现？
A：通过 Option53 DHCP Message Type 辨别具体的报文类型。目前该 Option 中定义了 18 种 DHCP 消息，这里仅介绍前 8 种。

Value	Mess Type	Ref
1	DISCOVER	RFC2123
2	OFFER	RFC2123
3	REQUEST	RFC2123
4	DECLINE	RFC2123
5	ACK	RFC2123
6	NAK	RFC2123
7	RELEASE	RFC2123
8	INFORM	RFC2123
9	FORCERENEW	RFC3203
10	LEASEQUERY	RFC4388
11	LEASEUNASSIGNED	RFC4388
12	LEASEUNKNOWN	RFC4388
13	LEASEACTIVE	RFC4388
14	BULKLEASEQUERY	RFC6926
15	LEASEQUERYDONE	RFC6926
16	ACTIVELEASEQUERY	RFC7724
17	LEASEQUERYSTATUS	RFC7724
18	TLS	RFC7724

DHCP 常用 8 种消息的作用：

• DISCOVER：Client 广播以发现 Server 存在；
• OFFER：Server 携带相应网络参数回应 Client 的 DISCOVER 消息；
• REQUEST：
  1. Client 携带特定一台 Server 提供的网络参数用于隐式拒绝其他 Server 提供的网络参数；
  2. Client 重启等情况，用于直接确认先前获得地址的可用性；
  3. 动态分配方式下，Client 用于租期续约。
• DECLINE：Client 向 Server 广播通知分配地址的不可用性。
• ACK：Server 携带网络参数向 Client 固化网络配置。
• NAK：Server 向 Client 表明获得地址的错误性。
• RELEASE：Client 向 Server 单播通知撤销所分配地址并释放租约。
• INFORM：Client 向 Server 广播请求获取其他本地配置参数。

2.2 DHCP C/S 基本交互过程

这里以局域网内有两台 Server 为例进行相关说明：（无 DHCP Relay 情况）

// 如上图所示 DHCP 的 Client/Server 交互首先由 Client 发起。
第一次 Client/Server 交互：

1. Client 广播 DISCOVER 消息：该报文在局域网内广播，并携带了期望的地址和租期等 Option 信息。
2. Server 回应 OFFER 消息：局域网内所有 Server 都会回应 OFFER 消息，该 OFFER 消息的 yiaddr（your (client) IP address）字段中携带 Server 所提供的地址信息。并在发送前，Server 可以检测该地址的可用性。例如进行 ICMP 探测。
   • Client 可能会收到多个 OFFER 消息，通常 Client 以第一个收到的 OFFER 消息为主进行响应；
   • 如果 Client 在定时器内未收到 OFFER 消息，则客户端超时并重新传输 DISCOVER 消息。

第二次 Client/Server 交互：
3. Client 广播 REQUEST 消息：该报文在局域网内广播，并携带了 Option 信息。

• Option50 = Requested IP Address，Value 值携带步骤 2 中 Server 提供的 yiaddr（your (client) IP address）字段地址。
• Option54 = DHCP Server Identification，Value 值携带步骤 2 中 Server 提供的 DHCP Server Identification 相关信息。用于指示 Client 选择了哪个 Server。

4. Server 广播 ACK/NAK 消息：REQUEST 消息中选择的 Server 将 Client 的网络信息进行绑定，并使用包含配置参数的 ACK 消息进行响应。
   • Server 和 Client 都通过 DHCP 报文的 Option61 = Client Identifier 或 Chaddr 字段（Client hardware address）与分配的网络地址的组合构成了客户端租约的唯一标识符。
   • 如果所选 Server 无法满足 Client 的 REQUEST 消息请求，则回应 NAK 消息。
   • 如果所选 Server 收到 REQUEST 消息，则应将先前提供的地址进行绑定。
   • 如果所选 Server 未收到 REQUEST 消息，则先前提供的地址应当可分配给其他 Client。

Client 收到 ACK/NCK 后的动作：

• Client 对所分配的网络参数进行最终检测和记录。例如地址复用检测。如果地址被占用则应发送 DECLINE 消息，随后在一定定时器时间后重启 DHCP 交互过程。
• 如果 Client 收到 NAK 消息，Client 将重启 DHCP 交互过程。
• 如果 Client 既未收到 ACK 又未收到 NCK 消息，应在一定定时器时间后和重传次数后重传 REQUEST 消息。如果还未收到响应消息，Client 将重启 DHCP 交互过程。

图示的 Graceful shutdown：
Client 主动向 Server 单播发送 RELEASE 消息来放弃其在网络地址上的租约。

RELEASE 消息使用客户端租约的唯一标识符确认要释放的租约。也即前文所说的 Option61 = Client Identifier 或 Chaddr 字段（Client hardware address）与分配的网络地址的组合。如果客户端在获取租约时使用 Option61，则必须在 RELEASE 消息中使用 Option61。

自动换行
DHCP 地址重用过程：
如果 Client 记住并希望重用以前分配的网络地址，则客户端可以选择省略上述某些步骤。例如，我们的电脑和手机在家庭 WIFI 网络中通常获得的都是同一个地址。

1@Client 广播 REQUEST 消息：该报文在局域网内广播，并携带了 Option 信息。

• Option50 = Requested IP Address，Value 值携带先前 Server 提供也即本地记录保存的地址。

2@Server 广播 ACK/NAK 消息：REQUEST 消息中选择的 Server 将 Client 的网络信息进行绑定，并使用包含配置参数的 ACK 消息进行响应。

• 此时，Server 不应进行地址可用探测，因为此时 Client 可能会进行响应。
• 如果所选 Client 请求无效，则 Server 回应 NAK 消息。
• 如果所选 Server 收到 REQUEST 消息，则应将先前提供的地址进行绑定。
• 如果所选 Server 未收到 REQUEST 消息，则先前提供的地址应当可分配给其他 Client。

Client 收到 ACK/NCK 后的动作：

• Client 对所分配的网络参数进行最终检测和记录。例如地址复用检测。如果地址被占用则应发送 DECLINE 消息，随后在一定定时器时间后重启 DHCP 交互过程。
• 如果 Client NAK 消息，Client 将重启 DHCP 交互过程。
• 如果 Client 既未收到 ACK 又未收到 NCK 消息，应在一定定时器时间后和重传次数后重传 REQUEST 消息。如果还未收到响应消息，Client 将重启 DHCP 交互过程。

DHCP 的相关参数说明：

1. 由于 Client 和 Server 之间很可能不存在时钟同步，因此时间在 DHCP 消息中显示为相对时间。并且出于补偿考虑，Server 提供给 Client 的租期时间可以比 Server 保存到本地数据库的租约持续时间短。
2. 如果 Client 通过其他方式（例如手动配置）获得了网络地址，则可以使用 INFORM 请求消息来获取其他本地配置参数。响应的 Server 应单播给 INFORM 消息中 ciaddr 地址回应 ACK/NCK 消息。
3. Client 在初始化和报文发送中，无需请求所有的 Option。仅在 Client 明确在消息中请求的 Option 才需携带，并且 Server 应当对其进行响应。未携带的 Option 应当认为其选定为默认值。
4. 每当本地网络参数可能已更改时，Client 应使用 DHCP 重新获取或验证其 IP 地址和网络参数。如果此时 Client 无法正常向 Server 通信，则 Client 可继续使用先前的网络参数直至租约过期。

2.3 DHCP 协议原理

Server 的 Option54 = DHCP Server Identification：
服务器必须选择一个地址作为 DHCP Server Identification。

• 如果 Server 和 Client 在同一子网中，Server 使用在该子网上进行通信的 IP 地址作为 DHCP Server Identification。
• 如果 Server 和 Client 在不同子网中，Server 使用从接收消息的接口中选择一个地址作为 DHCP Server Identification。

Server 的报文类型：
在所有情况下，当“giaddr”为零时，服务器会向 0xffffffff 广播任何 DHCPNAK 消息。

• 如果“giaddr”字段为零，“ciaddr”字段为非零，则 Server 将 OFFER 和 ACK 消息单播到“ciaddr”中的地址。
• 如果“giaddr”为零，“ciaddr”为零，并且设置了广播位，则 Server 将 OFFER 和 ACK 消息广播到 0xffffffff。
• 并且“giaddr”为零，“ciaddr”为零，并且未设置了广播位，则 Server 将 OFFER 和 ACK 消息单播到 Client 的硬件地址和“yiaddr”地址。

sname 和 file 字段：
如果 DHCP 消息的 sname 和 file 字段被使用，则 Option 中必须携带 Option52 = Overload。

Server 的手动控制：
DHCP Server 不需要响应它们收到的每个 DISCOVERY 和 REQUEST 消息。例如，为了保持对连接到网络的 Client 的严格控制，网络管理员可以选择将 DHCP Server 配置为仅响应以前通过某种外部机制注册的 Client。

Server 通过 Client 的 Option61 = Client Identifier 来识别特定 Client。如果 Client 未通告该 Option，则 Server 必须使用 chaddr = Client Hardware Address 字段的内容来标识 Client。

Client 可以使用多种方式来填充 Option61 = Client Identifier，例如制造商标识，DNS 名称等。

Server 的提供地址原则：
Server 以如下原则为 Client 分配相应的地址：

• Client 当前绑定的地址。
• Client 当前绑定，但已经过期的地址。此时 Server 还需保证该地址在可分配地址池中状态正常。
• Client 中携带的 Option50 = Requested IP Address 的地址。此时 Server 还需保证该地址在可分配地址池中状态正常。
• Server 的可用地址池中分配的新地址。

对于地址的租约情况有如下原则：

• DISCOVER 消息中未请求特定租约，但 Client 已分配网络地址。Server 回应先前提供的租约。
• DISCOVER 消息中未请求特定租约未获得地址，Server 回应本地默认租约。
• DISCOVER 消息中请求特定租约，Server 依照本地策略同意或选择其他租约。

Server 接收 REQUEST 消息：

• 如果 REQUEST 消息包含 Option54 = DHCP Server Identification，则该消息是对 OFFER 消息的响应。
• Client 的 REQUEST 消息包含 Option61 = Client Identifier 来识别，必须在所有后续消息中使用相同的 Client Identifier。
• Server 对 REQUEST 消息的响应不应与 Client 正在响应的早期 OFFER 消息中的参数冲突。
• 在初始化重启状态期间生成的 REQUEST：不得携带 Option54 = DHCP Server Identification，Option50 = Requested IP address 必须填写 Client 先前分配的地址。ciaddr 字段必须为零。
• 在续订状态期间生成的 REQUEST（第一次单播续租）：不得携带 Option54 = DHCP Server Identification 和 Option50 = Requested IP address，ciaddr 字段必须填写 Client 先前分配的地址。
• 在重新绑定状态期间生成的 REQUEST（第二次广播续租）：不得携带 Option54 = DHCP Server Identification 和 Option50 = Requested IP address，ciaddr 字段必须填写 Client 先前分配的地址。

2.4 DHCP 状态机

在 RFC2131 的 4.4. 章节提及 Client 状态机，此时仅仅简单说明：

1@：Client 从 INIT 状态开始并形成 DHCP 发现消息。此时 Client 启动 1 - 10s 间随机等待计时器，以便取消 DHCP 的使用。
Client 可以通过包含“参数请求列表”选项来请求特定参数。客户端可以通过包括 Option55 = Parameter Request List 和 Option51 = IP Address Lease Time 来建议网络地址和 / 或租用时间。

2@：Client 在一定时间内收集 OFFER 消息，通常选择第一接收到的 OFFER 或先前使用 Server 的 OFFER 消息进行回应。如果参数可接受，则 Client 会记录 Option54 = DHCP Server Identification 中提供参数的服务器的地址，并在 REQUEST 广播消息携带该。

3@：一旦收到来自 Server 的 ACK 消息，Client 就会被初始化并进入 BOUND 状态。

4@：Client 以 INIT-REBOOT 状态启动时，将直接发送 REQUEST 消息。客户端必须在 REQUEST 消息中插入 Option50 = Requested IP Address，携带其已知网络地址。 Client 可以通过携带 Option55 = Parameter Request List 来请求特定的配置参数。但该 REQUEST 消息不得携带 Option54 = DHCP Server Identification。

5@：Client 维护两个时间 T1 = 0.5 * duration_of_lease，T2 = 0.875 * duration_of_lease，用于尝试延长其网络地址租约的时间。T1 是 Client 进入 RENEWING 状态的时间，T2 是 Client 进入 REBINDING 状态的时间。
在第一次 T1 到达时，Client 向 Server 单播发送 REQUEST 消息。Client 收到 ACK 消息后可刷新租期时间。如果 Client 既未收到 ACK 消息又未收到 NAK 消息，将在 T2 时间点广播发送 REQUEST 消息。

这一处理过程与基本处理过程的内容相似，因此省略关于 NAK 等内容。

3 DHCP 配置示例

3.1 DHCP 配置示例

AR1 设备基于接口作为 DHCP Server：

DHCP Relay 用于 DHCP Server 与 Client 位于不同子网的场景，DHCP Relay 会将来自 Client 的消息全部以单播方式代替 Client 向 Server 进行请求。当然此时还会将 giaddr = Relay agent IP address 字段填充相应的 Relay 地址。

#
AR1：
dhcp enable
#
interface GE0/0/0
 ip address 10.1.1.1 255.255.255.0
 dhcp select interface
 dhcp server gateway-list 10.1.1.1
 dhcp server excluded-ip-address 10.1.1.2
 dhcp server static-bind ip-address 10.1.1.100 mac-address 00e0-fc88-b684
 // 设备可实现部分绑定。
 dhcp server lease day 30 hour 0 minute 0
 dhcp server dns-list 10.1.1.2
 dhcp server domain-name huawei.com
#

AR2：
dhcp enable
#
interface GE0/0/1
 ip address 10.20.20.1 255.255.255.0
 dhcp select relay
 dhcp relay server-ip 10.1.1.1
#
1234567891011121314151617181920212223

这里 Relay 还可指定 DHCP 服务器组的方式指定多个 DHCP Server。

// Relay 绑定 DHCP 服务器组。需定义 DHCP 服务器组。

dhcp server group <group1>
 dhcp-server 20.1.1.1 0
 dhcp-server 30.1.1.1 1
#

自动换行
AR1 设备基于全局地址池作为 DHCP Server：直接贴出配置

#
dhcp enable
#                                                                                 
dhcp option template template1                                                 
 gateway-list 10.1.1.1                                                        

 next-server 10.1.1.3                                                         
 bootfile configuration.ini
#
ip pool pool1
 gateway-list 10.1.1.1                                                        

 network 10.1.1.0 mask 255.255.255.0                                          
 excluded-ip-address 10.1.1.2 10.1.1.3                                      
 static-bind ip-address 10.1.1.4 mac-address 00e0-fc96-e4c0 option-template template1                                                                        
 lease unlimited                                                              
 dns-list 10.1.1.2      
#
interface GigabitEthernet0/0/1
 ip address 10.1.1.1 255.255.255.0
 dhcp select global
#

这里的模板用于为特定 Client 设定无盘启动，远程加载 10.1.1.3 的 Server 系统文件。

3.2 DHCP 常用命令

// ip address dhcp-alloc 设置设备作为 DHCP Client。

// 设置设备作为 DHCP Client 时，进行 DHCP 交互时携带自定义参数。

例如 dhcp client default-route preference <> 用于设定接收到 DHCP 路由 / User Network Router 路由的优先级。默认为 60。
注意不同设备对 DHCP 支持能力不同，比如定义作为 Client 时携带 Option55 = Parameter Request List。其他命令可查阅相关资料。

// 设置设备作为 DHCP Server 时，进行 DHCP 交互时携带参数。

// 查看设备的 dhcp 相关消息。

3.3 真实场景下 DHCP 报文交互

Windows 系统下的 DHCP：

其中 ipconfig /release 命令用于重启整个 DHCP 报文交互过程；ipconfig /renew 命令用于手动单播发送 REQUEST 消息，可刷新租约。

DHCP 报文交互一览：

和

从图中可以看出 DHCP 的基本交互使用广播消息传递，但有时也会使用单播消息传递。
当 DISCOVER 的 BOOTP Flag 的 B-bit 未置位，Server 应当以单播方式进行回应 OFFER 消息。

3.4 DHCP 的二层 Snooping

DHCP Snooping 是一种 DHCP 安全特性，主要在二层使用。交换机通过截获 Client 和 Relay 之间的 DHCP 报文并进行分析处理，可以过滤不信任的 DHCP 报文并建立和维护一个 DHCP-Snooping 绑定表（untrust）。

// 开启 DHCP Snooping 功能。除全局外，也需要在相应的 vlan 下开启。

// 查看 DHCP Snooping 的相关信息。

相关概念及原理：

Trust 端口：只允许该端口接收来自 DHCP Server 的消息。通过将端口设置为 Trust 端口，用于阻止私接路由器。

unTrust 端口：拒绝接收来自 DHCP Server 的消息。

// 将端口设置为 trust 端口。默认端口为 untrust。

DHCP-Snooping 绑定表：交换机通过识别 unTrust 端口接收到的 REQUEST 报文来建立绑定表。绑定表包括 MAC 地址、IP 地址、租约时间、VLAN ID 和接口信息等。并且绑定表又可分为动态生成和静态生成。

Option82：RFC3406-DHCP Relay Agent Information Option 中定义了 Option82 = Relay Agent Information 用于 Server 根据配置策略信息针对 Client 做出响应。

交换机将所有来自 Client 的 DHCP 报文插入 Option82 = Relay Agent Information。其中可以携带 Agent Circuit ID Sub - option（code = 1），Agent Remote ID Sub - option（code = 2），RADIUS Attributes Sub - option（code = 7）和 Authentication Suboption（code = 8）等多种用于识别特定终端的特定参数。

例如 Agent Circuit ID Sub - option 携带了端口 / 槽位 ID，vlan ID 等

交换机接收来自 Server 的 DHCP 报文也将 Option82 = Relay Agent Information，但将其转发给 Client 时将剥离该 Option。

// dhcp option82 基于端口和 vlan 配置使能相应功能。

自动换行

// 可以看到此处包含了端口号等信息。

自动换行

// dhcp snooping check dhcp-giaddr enable 命令用来检测 DHCP 报文中 GIADDR 字段 = Relay agent IP address 是否非零的功能。

从 Option82 描述上看，应当属于 Relay 的一种策略。因此有时 Server 接收配置了 Option82 的报文后，如果检查 GIADDR 字段为 0 后会将其丢弃。HW 默认不检查，Cisco 需要关闭。

DHCP 的防饿死：大量伪造 DHCP 请求报文耗尽 Server 地址池。

// 配置接口允许学习的 DHCP Snooping 绑定表项的最大个数。

// 配置接口收到 DHCP 报文的 Chaddr 地址，也即 Client Hardware Address，与数据帧的 SMAC 地址是否一致。DHCP Server 通常不关心二层帧的 MAC 地址，开启此功能可以防止伪造发送 DHCP 请求报文。同时，也可配合端口的 MAC 地址绑定一同使用。

参考

• 关于 DHCP 基本原理，可参考 RFC2131-Dynamic Host Configuration Protocol

• 关于 DHCPv6 基本原理，可参考 RFC8415-Dynamic Host Configuration Protocol

• 关于 DHCP Option 基本原理的 RFC，可参考 1997 年发布的 RFC2132

• 关于 DHCP 协议的相关字段，可参考 IANA 的 Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters

• 关于 IPv4 地址空间分类，可参考 IANA 的 IANA IPv4 Special-Purpose Address Registry

• 关于 Client 在 DHCP 时获得地址 169.254.0.0/16 的说明，可参考 2005 年发布的 RFC3927

• 关于 DHCPv6 协议基本原理，可参考博客 – DHCP-原理介绍 + 报文解析 + 配置示例 — RFC2131

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

Note：

关于 169.254.0.0/16，这里进行简单说明。RFC3927 所分配定义，具有链路本地范围。这一地址目前主要用于 Client 启动 DHCP 失败后，自动分配的一个地址。
个人能力有限，敬请各位指导。

---

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

fengxingzhe008 已于 2024-08-08 22:39:07 修改

前言

个人认为，理解报文就理解了协议。通过报文中的字段可以理解协议在交互过程中相关传递的信息，更加便于理解协议。因此本文将在 DHCP 协议报文的基础上进行介绍。

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 置位。
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 的地址解析和重复地址检测。
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。
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。此处仅作报文交互参考。

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
#
123456789101112131415161718192021

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
#
1234567891011121314151617181920

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 的地址解析和重复地址检测。
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。

参考

• 关于 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 地址空间分类，可参考 IANA 的 IANA IPv6 Special-Purpose Address Registry

• 关于 IPv6 协议基本原理，可参考博客 – IPv6/ICMPv6-原理介绍 + 报文分析 + 配置示例

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

Note：

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

附录：DHCPv6 常用 Option

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

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

常用 Singleton Option

Option 编号	Option 名称	功能描述
Option1	Client ID option	包含 DUID，唯一标识 Client，与链路层地址相关
Option2	Server ID option	包含 DUID，唯一标识 Server，与链路层地址相关
Option3	IA_NA	包含 IAID、T1、T2 及地址选项，用于非临时地址分配
Option4	IA_TA	包含 IAID 及临时地址选项，无 T1/T2，用于临时地址分配
Option5	IA Address Option	包含 IPv6 地址、preferred/valid lifetimes 及相关 Option，属于 IA_NA/IA_TA 的子选项
Option6	Option Request Option (ORO)	携带 Client 请求的 Option 列表，类似 DHCP 的 Option55，必须在 SOLICIT、REQUEST 等消息中携带
Option8	Elapsed Time Option	2 字节，Client 启动交互至今的时间（0.01s 单位），帮助备用 Server 判断主 Server 状态
Option14	Rapid Commit Option	标识 Client 支持两步交互模型，Server 响应需携带该 Option
Option25	IA_PD	包含 IAID、T1、T2 及前缀选项，用于前缀代理场景
Option26	IA Prefix Option	包含前缀、preferred/valid lifetimes 及相关 Option，属于 IA_PD 的子选项
Option37	Relay Agent Remote-ID Option	包含企业编号和 remote-id（如用户名、DUID、VLAN 等），作用类似 DHCP 的 Option82，中继代理可在 RELAY-FORW 中携带
Option79	Client Link-Layer Address Option	包含链路层地址类型和地址，用于获取 Client 链路层地址

其他关键 Option

Option 编号	Option 名称	功能描述
Option9	Relay Message Option	中继代理转发消息时携带原始 DHCPv6 消息，用于跨子网交互
Option13	Status Code Option	携带交互状态码，标识成功或错误（如地址冲突、租期过期）
Option18	Interface-Id Option	标识中继代理的接口信息，确保 Server 响应与请求链路一致
Option26	IA Prefix Option	承载 IPv6 前缀及租期，属于 IA_PD 的子选项，用于前缀代理场景
Option32	Information Refresh Time	配置信息刷新时间，控制 Client 重新获取参数的周期

说明：

Singleton Option 特性：每个 Option 在消息中只能出现一次，若重复出现则每个实例独立处理，数据区域不得串联。
子选项关系：如 Option5（IA 地址选项）从属于 IA_NA/IA_TA，Option26（前缀选项）从属于 IA_PD。
中继代理相关：Option37（Remote-ID）和 Option9（Relay Message）用于跨网络场景的中继代理交互。

通用 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 的链路层地址。

---

via：

• DHCP - 原理介绍 + 报文解析 + 配置示例 — RFC2131_dhcp rfc - CSDN 博客
  https://blog.csdn.net/fengxingzhe008/article/details/131650032

• DHCPv6 - 原理浅谈 + 报文示例 + 简易配置 (SLAAC + DHCPv6 + PD 前缀代理) – RFC8415_dhcpv6 报文 - CSDN 博客
  https://blog.csdn.net/fengxingzhe008/article/details/131835377

• IPv6/ICMPv6-原理介绍+报文分析+配置示例_ipv6报文分析实例-CSDN博客
  https://blog.csdn.net/fengxingzhe008/article/details/128909919#t19