【Android】DHCP协议 IPv6协议

在讲解这个DHCPv6协议之前，先申明下以下几点

Only a single upper network, specifically the Mobile Data network, is permitted to facilitate IPv6 tethering.

基于之前所学的内容，我们收集到的日志信息表明，在Android项目中未能直接获取到该协议的具体细节。其中仅SLAAC能够通过ICMPv6完成相关功能。如图所示。

接下来我讲解的DHCPv6主要参考其他博主写的资料进行讲解的

一 DHCPv6简介

DHCPv6（动态主机配置协议IPv6）是一种用于配置IPv6地址、网络掩码以及DNS服务器的网络协议。

该协议通过客户端与服务端之间进行通信，并采用 UDP 格式传输（其中客户端连接至 546 端口以发送请求包），服务端则响应并返回相应的 DHCP 包信息）。如同 IPv4 上的 DHCP 协议一样，该协议的所有报文均采用 UDP 格式传输（其中客户端使用UDP 端口号546以发送请求包），服务端则响应并返回相应的 DHCP 包信息）。然而由于 IPv6 没有广播机制支持，在这种架构下无法直接实现广播功能。相反地，在这种架构下无法直接实现广播功能的情况下，则改用组播机制来完成资源分配任务（即默认情况下所有 DHCPv6 服务器都会加入该组播组并开始监听相关广播信息：FF02::1:2）。值得注意的是，在这种架构下无法直接实现广播功能的情况下，则改用组播机制来完成资源分配任务（即默认情况下所有 DHCPv6 服务器都会加入该组播组并开始监听相关广播信息：FF02::1:2）。值得注意的是，在这种架构下无法直接实现广播功能的情况下，则改用组播机制来完成资源分配任务（即默认情况下所有 DHCPv6 服务器都会加入该组播组并开始监听相关广播信息：FF02::1:2）。

二 DHCPv6基本协议架构

主要包括以下三种角色：

DHCPv6 Client：

该 DHCPv6 客户端 通过与 DHCPv6 服务器进行交互作用，并接收 IPv6 地址和前缀信息以及网络相关配置参数，在此过程中 实现 自身的地址配置功能。

DHCPv6 Relay：

在 DHCPv6 网络中部署中继代理节点的主要作用是转发来自客户端端点以及服务器端点发送过来的 DHCPv6 数据包，并参与完成 DHCPv6 客户端与服务器之间的地址配置。通常情况下，在本地网络范围内部署 DHCPv6 服务端点即可满足需求。然而，在某些复杂场景下（例如当客户端和服务器不在同一本地网段内），为了简化网络架构并减少硬件开销，在这两台设备之间无需直接建立连接的情况下仍可实现有效的 DHCPv6 配置管理。这种网络架构的优势在于能够避免在每个本地网段内都必须部署 DHCPv6 服务端点以实现类似功能的需求，从而显著降低了网络布线成本以及维护复杂度。

在dhcp-v6的基本架构体系下, dhcp-v6中的转发现代并非必需角色. 当dhcp-v2客户端与dovnloader-7810之间处于同一个本地范围之内, 或者两者之间能够直接采用单播机制直接完成地址分配与信息配置时，则无需dovnloaders-7810转发现代进行介入. 仅在dovnloaders-7810客户机与dovnloaders-7810服务器不在同一本地范围内, 或者两者之间无法实现单播交互时，则有必要引入dovnloaders-7810转发现代参与其中.

DHCPv6 Server：

DHCPv6服务器主要承担从客户端或中继代理那里接收相关请求的任务，并完成对这些请求的处理工作。该服务器负责接收并完成对客户端的IPv6地址及网络配置信息的分配任务。

三 DHCPv6报文格式

（1）Solicit ，DHCPv6 客户端使用Solicit报文来发现 DHCPv6 服务器的位置。

（2）广播**（2）Advertise** ，DHCPv6 服务器通过广播机制响应相关Solicit报文，并告知客户端可提供的 DHCPv6 服务类型。

（3）在请求阶段中Request ，DHCPv6 客户端通过提交一个Request报文以目的 toward 目标服务器获取所需配置信息。

通过发送Confirm报文至任意可到达的 DHCPv6 服务器进行确认，在此过程中，客户端将验证自己当前获取到的 IPv6 地址是否适用于其当前连接所在的网络段。

（5）Reply ，DHCPv6服务器在以下场合发送Reply报文：

DHCPv6 服务器通过发送带有地址和配置信息的Reply消息来应对从 DHCPv6 客户端接收到的Solicit、Request、Renew及Rebind请求。
该服务器通过传递包含配置信息的Reply消息来响应接收到的Information-Request请求。
这些Confirm、Release及Decline报文通常由该服务器负责处理。

A request for address allocation is made by a DHCPv6 client to its corresponding DHCPv6 server, declining an allocation of one or more addresses on the link within the client's assigned chain that are already occupied by other clients.

四 DHCPv6报文格式

报文类型	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客户端的报文。

五 首次获取IPV6地址解析过程

在此次连接中, 该CVM将通过网络地址转换(NAT)功能完成网络接口IP地址的映射, 并基于请求响应机制(RRO)返回对应的IPv6地址信息。

1. 发现阶段

客户端CVM发起Solicit请求以探测DHCPv6服务器的状态信息，并向该服务获取其提供的IPv6地址和网络配置参数的具体数值。

因为CVM不了解 DHCPv6 服务器的 IPv6 地址问题而无法直接获取相关信息，在这种情况下,CVM决定采用组播地址：FF02::1:2向所有相关服务器广播Solicit报文。

Solicit报文中包含有客户端的DUID、应申请的非临时地址、另外还有其他相关配置信息。

2. 提供阶段

该服务器在接收到一个Solicit报文之后，在遵循指定的规则下进行处理，并采用循环遍历的方式按照IPv6地址从小到大进行排序；在遍历过程中寻找到可用且可分配的第一个IPv6地址；随后通过单播式的Advertise报文将该地址反馈给相关虚拟机（CVM）。

Advertise报文中包含着服务器的信息标识（如服务器ID、服务名称等）、客户端的信息标识（如用户名、密码等）以及分配给该客户端的服务资源信息。

3. 选择阶段

由于Solicit报文采用了组播技术，在同一网络区域内若有多台DHCPv6服务器存在，则所有接收该报文的服务器都会主动发送Advertise报文以建立连接。

当多个 DHCPv6 服务器向 DHCPv6 客户端发送 Advertise 报文时，在此情况下 DHCPv6 客户端将来自服务器优先级最高的 Advertise 报文作为首选。随后该客户端采用组播机制向其所在的网络范围内所有 DHCPv6 服务器发送 Request 报文，并附加相关信息：客户端所选中 DHCPv6 服务器（具有较高优先级）的 DUID、本客户端自身的 DUID以及当前使用的 IPv6 地址信息。

4. 确认阶段

当DHCPv6服务器接收到Request报文时，在接收到该报文中所包含的服务端DUID信息时进行判断。

• 当报文中携带的服务端DUID不是本服务端的DUID时，则对该Request报文不响应，并将Request报文中请求的IPv6地址进行回收。
  • 当报文中携带的服务端DUID是本服务端的DUID时，则通过单播机制回复Reply报文，并确认Request报文中请求的IPv6地址已分配给客户端使用。

5. 客户端CVM处理阶段

当客户端CVM接收到Reply报文时, 会向网络中发起地址冲突探测请求 (Neighbor Solicitation). 这一请求用于核查是否存在其他在同一链路内的客户端使用同一IPv6地址. 如果在指定时间窗口内未得到回复, 则表示该客户端能够使用此IP地址作为分配.

当发送地址冲突探测报文（Neighbor Solicitation）并接收到响应时

六 重启后获取IPV6地址解析

CVM在首次接入腾讯云IPv6网络时会触发相关交互流程，在线网关端通过 DHCPv6 协议自动生成与该CVM相关的 IPv6 地址配置信息。

第一步，当客户端CVM首次连接 IPv6 网络时（例如重启或网卡被禁用后重新启用），该设备会通过广播地址FF02::1:2向服务器发送一个确认报文以验证该CVM之前配置的有效性

当 DHCPv6 服务器（基于腾讯云的虚拟组件）接收到Confirm报文时,核查Confirm报文中全部的IP地址是否都适配于该CVM.

当所有IPv6地址在Confirm报文中均获得确认时,服务器将返回成功响应的Reply报文.若客户端接收到失败响应的Reply报文,则会发出Solicit报文以重试请求该IPv6地址.

在第三步中，客户端CVM接收到确认成功的Reply报文后将发送地址冲突探测报文（Neighbor Solicitation），以探查本链路范围内是否存在其他客户端已使用相同的IPv6地址。若在规定时间内未获得响应，则表明该CVM能够安全地使用此地址。

在第三步中, 客户端CVM接收到确认成功的Reply报文后将发送地址冲突探测报文(Neighbor Solicitation), 以探查本链路范围内是否存在其他客户端已使用相同的IPv6地址. 若在规定时间内未获得响应, 则表明该CVM能够安全地使用此地址.

在此过程中，客户端通过DHCPv6协议自动获取IPv6地址的机制得到了清晰阐述。