网络应用层之(1)DHCPv4协议
Author: Once Day Date: 2024年5月18日
一位热衷于Linux学习和开发的菜鸟，试图谱写一场冒险之旅，也许终点只是一场白日梦…
漫漫长路，有人对你微笑过嘛…
全系列文档可参考专栏：通信网络技术_Once-Day的博客-CSDN博客。
参考文章:
- 《TCP/IP详解卷一》
- DHCP协议详解 - 知乎 (zhihu.com)
- 只需三分钟！读懂DHCP的原理与配置 - 知乎 (zhihu.com)
- 37 张图详解 DHCP ：给你 IP 地址的隐形人 - 知乎 (zhihu.com)
- 【网络协议详解】——DHCP系统协议（学习笔记）-CSDN博客
- 什么是DHCP？为什么要用DHCP？ - 华为 (huawei.com)
- RFC 2131: Dynamic Host Configuration Protocol (rfc-editor.org)
- Info-Finder（在线工具） 报文格式 (huawei.com)
- DHCP - IP 报文格式大全 (huawei.com)
- BOOTP - IP 报文格式大全 (huawei.com)
### 网络应用层之(1)DHCPv4协议
Author：Once Day Date: 2024年5月18日
漫漫长路，有人对你笑过嘛…
全系列文档可参考专栏：通信网络技术_Once-Day的博客-CSDN博客。
参考文档:
- 《TCP/IP详解卷一》
- DHCP协议详解 - 知乎 (zhihu.com)
- 只需三分钟！读懂DHCP的原理与配置 - 知乎 (zhihu.com)
- 37 张图详解 DHCP ：给你 IP 地址的隐形人 - 知乎 (zhihu.com)
- 【网络协议详解】——DHCP系统协议（学习笔记）-CSDN博客
- 什么是DHCP？为什么要用DHCP？ - 华为 (huawei.com)
- RFC 2131: Dynamic Host Configuration Protocol (rfc-editor.org)
- Info-Finder（在线工具） 报文格式 (huawei.com)
- DHCP - IP 报文格式大全 (huawei.com)
- BOOTP - IP 报文格式大全 (huawei.com)
文章目录
- 网络应用层之(1)DHCPv4协议
- 1. 介绍
- 1.1 DHCP协议介绍
- 1.2 DHCP和BOOTP协议的联系
- 1.3 DHCP相关的RFC文档
- 2. 报文格式
- 2.1 DHCPv4报文格式
- 2.2 BOOTP报文格式
- 2.3 DHCP报文选项
- 2.4 DHCP消息类型
- 2.5 DHCP服务端
- 2.6 DHCP客户端
- 3. 工作流程
- 3.1 DHCP服务器地址分配方式
- 3.2 DHCP客户端接入网络流程
- 3.3 DHCP客户端续租
- 3.4 DHCP中继场景接入网络流程
- 3.5 DHCP客户端状态机
- 3.6 DHCP认证
- 4. 总结
1. 介绍
1.1 DHCP协议介绍
DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）是一种网络管理协议，用于自动为加入网络的设备分配IP地址和其他网络配置参数。它简化了网络管理，使得设备可以即插即用，无需手动配置。
DHCP的前身是BOOTP(Bootstrap Protocol)(RFC0951)，由Bill Croft和John Gilmore于1985年开发，用于无盘工作站的IP地址分配。1993年，DHCP作为BOOTP的增强版被提出，由Ralph Droms主要设计和开发。
1997年，DHCP成为RFC 2131标准，得到广泛应用。2002年，DHCPv6（RFC 3315）发布，支持IPv6地址的动态分配。
随着网络规模的不断扩大，手动为每台设备分配IP地址变得越来越困难。对于服务器和路由器这种网络拓扑中的核心设备， 出于可靠性原因，通常是静态手工配置。但是大量的家用客户机和嵌入式设备，需要灵活的IP地址分配策略，其操作者常常对网络知识了解甚少，因此就需要一种集中服务来统一管理和自动分配IP地址。
DHCP广泛应用于各种网络环境，如家庭网络、企业网络、校园网等。它不仅适用于有线网络，也支持无线网络（如Wi-Fi）。当设备接入网络时，DHCP服务器会自动为其分配IP地址、子网掩码、默认网关、DNS服务器等参数，使设备能够正常通信。
当一台启动DHCP client功能的客户机首次接入网络时，将会经历如下流程：
- DHCP客户端向网络广播DHCP Discover消息，请求IP地址。
- DHCP服务器收到请求后，从地址池中选择一个可用的IP地址，并发送DHCP Offer消息给客户端。
- 客户端接收到一个或多个DHCP Offer后，选择其中一个，并向服务器发送DHCP Request消息，请求使用该地址。
- 服务器收到DHCP Request后，将地址标记为已分配，并发送DHCP ACK消息，确认地址分配。
DHCP虽然极大便利了网络配置流程，但是也存在一些风险，如下所示:
- DHCP缺乏对设备身份的验证机制，可能导致地址盗用和安全问题。
- DHCP服务器单点故障可能导致整个网络瘫痪，需要配置冗余和故障转移机制。
- DHCP的地址分配策略相对简单，对于复杂网络环境，可能需要更精细的控制和管理。
在公共场所和公司办公场景，DHCP通常会搭配额外的认证服务流程，并绑定设备MAC和IP之间的关系，从而确保客户机受控接入，提高安全性。
1.2 DHCP和BOOTP协议的联系
BOOTP协议是DHCP的前身，最初由Bill Croft和John Gilmore于1985年开发，用于为无盘工作站自动分配IP地址。
BOOTP工作原理如下：
- 客户端广播BOOTREQUEST消息，请求IP地址和引导信息。
- BOOTP服务器收到请求后，从配置文件中查找客户端的硬件地址，并返回对应的IP地址和引导信息。
DHCP协议是在BOOTP的基础上发展而来，由Ralph Droms主要设计和开发，于1993年提出。
DHCP在保留BOOTP基本功能的同时，进行了多方面的增强和扩展：
- 引入了地址租期的概念，客户端获得的IP地址有一定的有效期，到期后需要续租或重新获取。
- 支持更多的网络配置参数，如子网掩码、默认网关、DNS服务器等。
- 引入了DHCP中继代理（DHCP Relay Agent），解决了跨网段分配IP地址的问题。
- 提供了更灵活的地址分配策略，如手动分配、自动分配、动态分配等。
DHCP协议在设计时充分考虑了与BOOTP的兼容性，使得DHCP服务器能够同时为BOOTP和DHCP客户端提供服务：
- DHCP使用与BOOTP相同的UDP端口(67和68)，消息格式也基本兼容。
- DHCP服务器可以识别BOOTP请求，并按照BOOTP的方式进行响应。
- DHCP中继代理可以转发BOOTP请求，扩展了BOOTP的适用范围。
目前，大多数DHCP服务器实现都同时支持DHCP和BOOTP协议，提供了很好的兼容性。例如，广泛使用的ISC DHCP服务器(DHCPD)默认支持BOOTP协议，可以为BOOTP客户端分配IP地址。Windows Server的DHCP服务也提供了BOOTP支持，通过配置选项可以启用BOOTP兼容模式。
1.3 DHCP相关的RFC文档
以下是与DHCP相关的主要RFC文档列表：
-
RFC 2131 - Dynamic Host Configuration Protocol (DHCP)，DHCP协议的主要规范，定义了DHCP的工作原理、报文格式和选项等。
-
RFC 2132 - DHCP Options and BOOTP Vendor Extensions，定义了DHCP协议中常用的选项和BOOTP供应商扩展。
-
RFC 3046 - DHCP Relay Agent Information Option，引入了DHCP中继代理信息选项(Option 82)，用于在DHCP中继代理和服务器之间传递额外的信息。
-
RFC 3118 - Authentication for DHCP Messages，为DHCP消息添加身份验证机制，提高了DHCP的安全性。
-
RFC 3203 - DHCP reconfigure extension，定义了DHCP重新配置扩展，允许DHCP服务器向客户端发送重新配置消息，触发客户端重新获取配置信息。
-
RFC 3315 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6)，定义了用于IPv6网络的DHCP协议，称为DHCPv6。
-
RFC 3396 - Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)，描述了在DHCPv4中编码长选项的方法，通过将长选项分割成多个子选项来传输。
-
RFC 3442 - The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4，定义了DHCPv4的无类静态路由选项，用于为DHCP客户端分配静态路由。
-
RFC 3925 - Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)，定义了DHCPv4的供应商标识选项，允许供应商在DHCP消息中传递特定于供应商的信息。
-
RFC 4242 - Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)，为DHCPv6定义了信息刷新时间选项，用于指示客户端刷新配置信息的时间间隔。
-
RFC 4361 - Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)，定义了DHCPv4的节点特定客户端标识符，用于在多个接口上唯一标识DHCP客户端。
-
RFC 4436 - Detecting Network Attachment in IPv4 (DNAv4)，描述了在IPv4网络中检测网络连接的机制，其中利用了DHCP的特性。
-
RFC 4704 - The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option，定义了DHCPv6的客户端完全限定域名（FQDN）选项，用于在DHCPv6中传递客户端的FQDN信息。
涵盖了DHCP协议的各个方面，包括基本规范、选项定义、安全性、IPv6支持等，共同构成了DHCP协议的完整规范和参考资料。
2. 报文格式
2.1 DHCPv4报文格式
DHCPv4报文格式由固定长度的字段和可变长度的选项字段组成，如下所示：
各字段说明如下:
- op(1字节)，操作码，指示报文的类型。1表示客户端请求报文(BOOTREQUEST)，2表示服务器响应报文(BOOTREPLY)。
- htype(1字节)，硬件地址类型，表示客户端的硬件地址类型。例如，以太网类型值为1。
- hlen(1字节)，硬件地址长度，表示客户端硬件地址的字节数。例如，以太网地址长度为6字节。
- hops(1字节)，跳数，用于DHCP中继代理，指示报文经过的中继代理数量。客户端设置为0，也能被一个代理服务器设置，超过某个阈值之后，就会丢弃报文。
- xid(4字节)，事务ID，用于将请求与响应匹配。客户端生成一个随机数，服务器在响应中使用相同的值，服务器和客户端用来在它们之间交流请求和响应，客户端用它对请求和应答进行匹配。
- secs(2字节)，客户端启动以来的秒数。由客户端填充，表示从客户端开始获得IP地址或IP地址续借后所使用了的秒数
- flags(2字节)：标志位，指示客户端的某些特性。此字段在BOOTP中保留未用，在DHCP中表示标志字段。最常用的是广播标志(0x8000)，表示服务器应该使用广播而不是单播来响应，全零表示服务器应该用单播报文来回复(只有最低位被使用，其余位都是零)。
- ciaddr(4字节)，客户端IP地址，客户端在续租时使用。客户端处于Bound、Renew、Rebinding状态，并且能响应ARP请求时，才能被填充。客户端初始状态没有地址的时候，可填充0.0.0.0地址。
- yiaddr(4字节)，服务器分配给客户端的IP地址。当服务器发送响应报文时，将分配给客户端的 IP 地址填入这个字段。仅在DHCP服务器发送的Offer和ACK报文中显示，其他报文中显示为0。
- siaddr(4字节)，服务器IP地址，用于引导程序下载。表明DHCP协议流程的下一个阶段要使用的服务器的IP地址。
- giaddr(4字节)，网关IP地址，DHCP中继代理使用，表示中继代理的IP地址。当客户端发出DHCP请求时，如果服务器和客户端不在同一个网络中，那么第一个DHCP中继在转发这个DHCP请求报文时会把自己的IP地址填入此字段。服务器会根据此字段来判断出网段地址，从而选择为用户分配地址的地址池。服务器还会根据此地址将响应报文发送给此DHCP中继，再由DHCP中继将此报文转发给客户端。
- chaddr(16字节)，客户端硬件地址。与前面的硬件地址类型和硬件地址长度保持一致，当客户端发出DHCP请求时，将自己的硬件地址填入此字段
- sname(64字节)，服务器名称，用于引导程序下载。此字段由DHCP Server填写，是可选的，如果填写，必须是一个以0结尾的字符串。
- file(128字节)，引导文件名，用于引导程序下载。此字段由DHCP Server填写，是可选的，如果填写，必须是一个以0结尾的字符串。
- options(可变长度)，选项字段，包含了附加的配置参数，如子网掩码、网关、DNS服务器等。选项字段以"魔术字节"(0x63,0x82,0x53,0x63)开头，后跟一系列的选项代码、长度和值，选项字段以255(0xFF)结束，至少为312字节。
2.2 BOOTP报文格式
DHCPv4是在BOOTP的基础上发展而来的，因此它们的报文格式基本一致：
-
DHCPv4和BOOTP使用相同的UDP端口。服务器使用端口67，客户端使用端口68。
-
它们的报文格式基本相同，都包含固定长度的字段，如操作码、硬件地址类型、硬件地址长度、跳数、事务ID、客户端IP地址、你的IP地址、服务器IP地址等。
-
它们都使用"魔术字节"（0x63,0x82,0x53,0x63）来标识选项字段的开始。
-
BOOTP的供应商信息字段对应于DHCPv4的选项字段，用于传递附加的配置参数。
DHCPv4在Bootp基础上，对报文的字段进行了增强解释和使用，如下：
- 标志位(flags)，DHCPv4引入了广播标志(0x8000)，用于指示服务器是否应该使用广播来响应客户端，而BOOTP没有这个标志位。
- 硬件地址长度(hlen)，BOOTP的硬件地址长度固定为16字节，而DHCPv4的硬件地址长度可以根据实际的硬件地址类型而变化，以太网地址长度为6字节。
- 文件字段(file)和服务器名称字段(sname)，在BOOTP中，这两个字段用于引导程序下载，而在DHCPv4中，这两个字段可以被选项覆盖（通过Option Overload选项），用于传递额外的选项数据。
- 选项字段(options)，DHCPv4引入了许多新的选项，如DHCP消息类型、租约时间、续约时间等，这些选项在BOOTP中没有定义。
BOOTP主要用于无盘工作站的IP地址分配和引导程序下载，而DHCPv4除了IP地址分配外，还支持传递更多的网络配置参数，如子网掩码、默认网关、DNS服务器等，适用于各种类型的网络设备。
2.3 DHCP报文选项
DHCP选项的格式如下:
| -- 选项标签(8 bit) -- | -- 选项长度(8 bit) -- | -- 选项值(可变) -- |除了空白和结束填充选项之外，其他选项都由上面TLV格式组成，常见选项如下:
| 标签(代码) | 名称 | 描述 |
|---|---|---|
| 0 | Pad | 填充选项，用于将选项字段填充到特定的边界 |
| 1 | 子网掩码 | 指定客户端的子网掩码 |
| 3 | 路由器 | 指定客户端的默认网关 |
| 6 | 域名服务器 | 指定客户端的DNS服务器 |
| 12 | 主机名 | 指定客户端的主机名 |
| 15 | 域名 | 指定客户端的域名 |
| 50 | 请求的IP地址 | 客户端请求的特定IP地址 |
| 51 | IP地址租约时间 | 指定分配给客户端的IP地址租约期 |
| 53 | DHCP消息类型 | 指定DHCP消息的类型（如DHCPDISCOVER、DHCPOFFER等） |
| 54 | 服务器标识符 | 标识DHCP服务器的IP地址 |
| 56 | 消息 | 服务器向客户端发送的错误消息或其他信息 |
| 58 | 续约时间 | 客户端在IP地址租约过期前，应该开始尝试续约的时间 |
| 59 | 重绑定时间 | 如果客户端无法与原始服务器续约，它应该开始广播请求新的租约的时间 |
| 55 | 参数请求列表 | 客户端请求的特定配置参数列表 |
| 61 | 客户端标识符 | 唯一标识客户端的信息 |
| 255 | End | 选项字段的结束标记，表示没有更多的选项 |
当DHCP报文的选项字段长度超过了可用空间时，可以使用选项超载(Option Overload)机制来扩展选项字段。选项超载通过复用DHCP报文中的"文件名"（File）和"服务器主机名"（Sname）字段来传递额外的选项数据。
选项超载的工作原理如下：
- 在DHCP报文的选项字段中添加"Option Overload"选项（代码52），用于指示选项数据的存储位置。
- "Option Overload"选项的值指定了额外选项数据的存储位置：
- 值为1：表示额外的选项数据存储在"文件名"字段中。
- 值为2：表示额外的选项数据存储在"服务器主机名"字段中。
- 值为3：表示额外的选项数据同时存储在"文件名"和"服务器主机名"字段中。
- 接收方根据"Option Overload"选项的值，从相应的字段中读取额外的选项数据。
假设一个DHCP服务器需要为客户端分配IP地址、子网掩码、默认网关、DNS服务器，并且还需要传递一些自定义的配置参数。选项字段的长度超过了可用空间，服务器决定使用选项超载机制。
DHCP报文的选项字段可能如下：
Option 53 (DHCP Message Type): DHCP OfferOption 1 (Subnet Mask): 255.255.255.0Option 3 (Router): 192.168.1.1Option 6 (Domain Name Server): 8.8.8.8, 8.8.4.4Option 52 (Option Overload): 1额外的选项数据存储在"文件名"字段中：
Option 128 (Custom Option): 0x01020304Option 129 (Custom Option): "example.com"当客户端收到这个DHCP Offer报文时，它会检查"Option Overload"选项，发现额外的选项数据存储在"文件名"字段中，然后从该字段中读取并解析额外的选项数据，获得完整的配置信息。
2.4 DHCP消息类型
DHCP消息类型选项(选项代码53)是DHCP协议中最关键的选项之一，它用于标识DHCP消息的类型，以便客户端和服务器能够正确地解释和响应彼此的消息，每个DHCP消息都必须包含这个选项。
| 代码 | 消息类型 | 描述 |
|---|---|---|
| 1 | DHCPDISCOVER | 客户端广播寻找可用的DHCP服务器 |
| 2 | DHCPOFFER | DHCP服务器提供可用的IP地址和配置参数 |
| 3 | DHCPREQUEST | 客户端请求特定的IP地址，或者确认接受DHCP服务器的提议 |
| 4 | DHCPDECLINE | 客户端拒绝DHCP服务器提供的IP地址 |
| 5 | DHCPACK | DHCP服务器确认客户端的IP地址请求 |
| 6 | DHCPNAK | DHCP服务器拒绝客户端的IP地址请求 |
| 7 | DHCPRELEASE | 客户端释放IP地址，通知DHCP服务器 |
| 8 | DHCPINFORM | 客户端请求额外的配置参数，但不请求IP地址 |
DHCP客户端和服务器通过这些消息类型来协调IP地址分配和网络配置的过程：
- 客户端广播DHCPDISCOVER消息，寻找可用的DHCP服务器。
- DHCP服务器响应DHCPOFFER消息，提供可用的IP地址和其他配置参数。
- 客户端选择一个DHCP服务器，并发送DHCPREQUEST消息，请求特定的IP地址或确认接受服务器的提议。
- DHCP服务器发送DHCPACK消息，确认客户端的IP地址请求；或者发送DHCPNAK消息，拒绝客户端的请求。
DHCP服务器处理的消息类型：
-
DHCPDISCOVER，服务器接收客户端广播的DHCPDISCOVER消息：
- 服务器根据自己的IP地址池和配置策略，选择一个可用的IP地址，并准备其他必要的配置参数。
- 服务器生成DHCPOFFER消息，提供选定的IP地址和配置参数。
-
DHCPREQUEST，服务器接收客户端发送的DHCPREQUEST消息，该消息可以是广播或单播。
- 服务器检查DHCPREQUEST消息中请求的IP地址是否与之前提供的一致。
- 如果IP地址匹配，服务器生成DHCPACK消息，确认客户端的IP地址请求。
- 如果IP地址不匹配或者客户端请求的IP地址无效，服务器生成DHCPNAK消息，拒绝客户端的请求。
-
DHCPDECLINE，服务器接收客户端广播的DHCPDECLINE消息，表示客户端拒绝接受分配的IP地址。
- 服务器将该IP地址标记为不可用，以避免将其分配给其他客户端。
-
DHCPRELEASE，服务器接收客户端单播的DHCPRELEASE消息，表示客户端释放分配的IP地址。
- 服务器将该IP地址标记为可用，以便将其分配给其他客户端。
-
DHCPINFORM，服务器接收客户端单播的DHCPINFORM消息，请求额外的配置参数。
- 服务器生成DHCPACK消息，提供请求的配置参数，但不分配IP地址。
DHCP客户端处理的消息类型(服务端是否发送广播与客户端请求报文的flags有关)：
-
DHCPOFFER，客户端接收服务器单播或广播的DHCPOFFER消息，其中包含服务器提供的IP地址和配置参数。
- 客户端选择一个DHCPOFFER，并准备发送DHCPREQUEST消息。
-
DHCPACK，客户端接收服务器单播或广播的DHCPACK消息，确认之前请求的IP地址和配置参数。
- 客户端配置网络接口，使用分配的IP地址和配置参数。
-
DHCPNAK，客户端接收服务器单播或广播的DHCPNAK消息，表示服务器拒绝客户端的IP地址请求。
- 客户端重新开始DHCP流程，发送新的DHCPDISCOVER消息。
2.5 DHCP服务端
该表格信息来自RFC 2131: Dynamic Host Configuration Protocol (rfc-editor.org)
根据RFC 2131文档的4.3.1节，以太网环境下DHCP服务器发送的三种消息(DHCPOFFER、DHCPACK和DHCPNAK)的报文字段如下：
| 字段 | DHCPOFFER | DHCPACK | DHCPNAK |
|---|---|---|---|
| 操作码(op) | 2(响应消息) | 2(响应消息) | 2(响应消息) |
| 硬件地址类型(htype) | 1 | 1 | 1 |
| 硬件地址长度(hlen) | 6 | 6 | 6 |
| 中继跳跃步数(hops) | 0 | 0 | 0 |
| 事务ID(xid) | DHCPDISCOVER的xid | DHCPREQUEST的xid | DHCPREQUEST的xid |
| secs | 0 | 0 | 0 |
| ciaddr | 0 | 0或者 DHCPREQUEST的客户端地址 | 0 |
| yiaddr | 提供给客户端的IP地址 | 提供给客户端的IP地址 | 0 |
| siaddr | 0或者下一个服务器地址 | 0或者下一个服务器地址 | 0 |
| flags | DHCPDISCOVER的flags | DHCPREQUEST的flags | DHCPREQUEST的flags |
| giaddr | DHCPDISCOVER的giaddr | DHCPREQUEST的giaddr | DHCPREQUEST的giaddr |
| chaddr | DHCPDISCOVER的chaddr | DHCPREQUEST的chaddr | DHCPREQUEST的chaddr |
| sname | 服务器主机名或空 | 服务器主机名或空 | 空 |
| file | 启机文件名或空 | 启机文件名或空 | 空 |
| options | 必须包含选项 | 必须包含选项 | 必须包含选项 |
选项字段的要求如下：
| Option | DHCPOFFER | DHCPACK | DHCPNAK |
|---|---|---|---|
| Requested IP address | MUST NOT | MUST NOT | MUST NOT |
| IP address lease time | MUST | MUST (DHCPREQUEST) MUST NOT (DHCPINFORM) | MUST NOT |
| Use ‘file’/‘sname’ fields | MAY | MAY | MUST NOT |
| DHCP message type | DHCPOFFER | DHCPACK | DHCPNAK |
| Parameter request list | MUST NOT | MUST NOT | MUST NOT |
| Message | SHOULD | SHOULD | SHOULD |
| Client identifier | MUST NOT | MUST NOT | MAY |
| Vendor class identifier | MAY | MAY | MAY |
| Server identifier(54) | MUST | MUST | MUST |
| Maximum message size | MUST NOT | MUST NOT | MUST NOT |
| All others | MAY | MAY | MUST NOT |
必须包含的选项有三类：消息类型（option 53）、服务器标识符（option 54）、IP地址租约时间（option 51，DHCPOFFER和DHCPACK）。
2.6 DHCP客户端
可参考文档：RFC 2131: Dynamic Host Configuration Protocol (rfc-editor.org)
根据RFC 2131文档的4.4.1节，DHCP客户端发送的消息（DHCPDISCOVER、DHCPREQUEST、DHCPDECLINE、DHCPRELEASE和DHCPINFORM）的字段如下：
| 字段 | DHCPDISCOVER | DHCPREQUEST | DHCPDECLINE | DHCPRELEASE | DHCPINFORM |
|---|---|---|---|---|---|
| op | 1 | 1 | 1 | 1 | 1 |
| htype | 1 | 1 | 1 | 1 | 1 |
| hlen | 6 | 6 | 6 | 6 | 6 |
| hops | 0 | 0 | 0 | 0 | 0 |
| xid | 随机生成 | DHCPOFFER的xid | 随机生成 | 随机生成 | 随机生成 |
| secs | 0或已过秒数 | 0或已过秒数 | 0 | 0 | 0或已过秒数 |
| flags | 0或1 | 0或1 | 0 | 0 | 0或1 |
| ciaddr | 0 | 'ciaddr’或0 | 0 | ‘ciaddr’ | ‘ciaddr’ |
| yiaddr | 0 | 0 | 0 | 0 | 0 |
| siaddr | 0 | 0 | 0 | 0 | 0 |
| giaddr | 0 | 0 | 0 | 0 | 0 |
| chaddr | 客户端硬件地址 | 客户端硬件地址 | 客户端硬件地址 | 客户端硬件地址 | 客户端硬件地址 |
| sname | 服务器主机名或空 | 服务器主机名或空 | 空 | 空 | 服务器主机名或空 |
| file | 启机文件名或空 | 启机文件名或空 | 空 | 空 | 启机文件名或空 |
| options | 必须包含选项 | 必须包含选项 | 必须包含选项 | 必须包含选项 | 必须包含选项 |
补充说明：
- ‘xid’：DHCPOFFER或DHCPACK消息中的’xid’字段，用于标识客户端的请求。
- ‘ciaddr’：客户端的IP地址，如果客户端已经有IP地址（在DHCPREQUEST、DHCPRELEASE和DHCPINFORM消息中），则填写该地址；否则为0。
- ‘giaddr’：网关IP地址，如果客户端通过中继代理发送DHCPREQUEST消息，则填写中继代理的IP地址。
- flags字段中的广播标志(1位)可以设置为0或1，指示服务器是否应该将响应作为广播发送。
options字段必须包含以下选项：
- DHCPDISCOVER：客户端标识符(如果已知)、请求的参数列表、最大DHCP消息大小、vendor class identifier(可选)。
- DHCPREQUEST：客户端标识符(如果已知)、请求的IP地址(如果在SELECTING状态)、服务器标识符（如果在SELECTING状态）、请求的参数列表、最大DHCP消息大小、vendor class identifier(可选)。
- DHCPDECLINE：服务器标识符、请求的IP地址。
- DHCPRELEASE：服务器标识符。
- DHCPINFORM：请求的参数列表、最大DHCP消息大小、vendor class identifier(可选)。
3. 工作流程
3.1 DHCP服务器地址分配方式
DHCP服务器有三种主要的IP地址分配方式：
-
自动分配(Automatic Allocation)，DHCP服务器从定义的IP地址池中为客户端分配一个永久的IP地址。
- 客户端第一次请求IP地址时，服务器会为其分配一个特定的IP地址，并将该地址与客户端的MAC地址关联。
- 在客户端的生命周期内，它将一直使用这个分配的IP地址，除非管理员手动更改。
- 自动分配适用于需要长期稳定IP地址的客户端，如服务器或网络打印机。
-
动态分配(Dynamic Allocation)，DHCP服务器从定义的IP地址池中为客户端分配一个临时的IP地址，并设置一个租约时间。
- 客户端在租约时间内可以使用这个IP地址，租约到期后必须续租或请求新的IP地址。
- 如果客户端在租约到期前释放IP地址或租约到期后未续租，服务器将回收该IP地址，并可以将其分配给其他客户端。
- 动态分配适用于对IP地址需求灵活、网络中客户端频繁变化的环境，如办公网络或公共Wi-Fi。
-
手动分配(Manual Allocation)，管理员手动为特定的客户端分配固定的IP地址，通常基于客户端的MAC地址。
- 手动分配的IP地址不属于DHCP服务器的IP地址池，而是单独保留给指定的客户端。
- 客户端请求IP地址时，DHCP服务器会检查客户端的MAC地址，并分配预先配置的固定IP地址。
- 手动分配适用于需要固定IP地址的特殊设备，或需要严格控制IP地址分配的网络环境。
除了这三种主要的分配方式，DHCP服务器还可以通过以下方式优化IP地址分配：
-
IP地址保留(Reservation)，为特定的MAC地址预留固定的IP地址，确保客户端始终获得相同的IP地址。
-
地址排除(Exclusion)，从DHCP服务器的IP地址池中排除特定的IP地址或地址范围，防止这些地址被分配给客户端。
-
地址范围划分(Scopes)，将IP地址池划分为多个范围，每个范围对应不同的网络区域或客户端类型，方便管理和控制IP地址分配。
3.2 DHCP客户端接入网络流程
DHCP客户端和服务器交互示意图，来自华为IP知识百科：什么是DHCP？为什么要用DHCP？ - 华为 (huawei.com)
一台新设备通过DHCP获取网络地址的流程通常包括以下步骤：
(1) 客户端广播DHCP Discover消息，DHCP客户端启动时，本机接口上没有IP地址，通过本地链路发送广播报文寻找服务器：
- 本地链路广播报文，因此源mac为接口mac地址，目的mac为广播mac地址(FF:FF:FF:FF:FF:FF)。
- 由于没有接口IP，所以源IP地址为0.0.0.0，目标IP地址为255.255.255.255(受限广播地址)，UDP报文的源端口为68，目的端口为67。
- 事务ID(xid)由客户端生成的随机数，用于标识该次交互。
- 标志flags根据客户端的情况设置为单播或者广播，会影响到服务器DHCPOFFER报文的回复情况。
- DHCP消息类型设置为1，表示DHCPDISCOVER。
(2) 服务器广播/单播DHCP Offer消息，DHCP服务器收到DHCPDISCOVER报文后，会给客户端提供IP地址和租期等信息：
- DHCP服务器从其管理的IP地址池中选择一个可用的IP地址，并发送一个DHCPOFFER消息给客户端，其中包含IP地址、子网掩码、地址租期等信息。
- DHCP服务器可以回复二层单播或者广播报文，单播报文的目的mac地址是客户端mac地址。
- 源IP地址为DHCP服务器的IP地址，目标IP地址为255.255.255.255(广播地址)，目的IP为广播地址不代表二层转发是广播转发。目标IP某些DHCP实现也会用分配的客户端IP代替。
- 事务ID(xid)，与DHCPDISCOVER消息中的xid相同。
- 分配的IP地址(yiaddr)，服务器提供给客户端的IP地址。
- 服务器标识符(option 54)，DHCP服务器的IP地址，标准实现必须提供服务器标识符。
- DHCP消息类型设置为2，表示DHCPOFFER。
(3) 客户端广播DHCPRequest消息，DHCP客户端从收到的DHCPOFFER消息中选择合适的服务端进行回复。
- 客户端收到一个或多个DHCPOFFER消息后，选择其中一个服务器提供的IP地址，并广播/单播一个DHCPREQUEST消息。
- 源IP地址为0.0.0.0，目标IP地址为255.255.255.255(受限广播地址)。
- 事务ID(xid)，与DHCPDISCOVER消息中的xid相同。
- 请求的IP地址(option 50)，客户端选择的IP地址。
- 服务器标识符(option 54)，提供所选IP地址的DHCP服务器的IP地址。
- DHCP消息类型设置为3，表示DHCPREQUEST。
(4) 服务端广播/单播DHCP Ack消息，DHCP服务器收到DHCPRequest消息后，通过DHCPACK消息回复客户端：
- DHCP服务器收到DHCPREQUEST消息后，确认客户端的IP地址请求，并发送一个DHCPACK消息给客户端。
- 对于广播消息，源IP地址为DHCP服务器的IP地址，目标IP地址为255.255.255.255(广播地址)。
- 对于单播消息，源IP地址为DHCP服务器的IP地址，客户端的IP地址(如果客户端在DHCPREQUEST消息中设置了ciaddr字段)。
- 交易ID(xid)，与DHCPREQUEST消息中的xid相同。
- 分配的IP地址(yiaddr)，确认客户端请求的IP地址。
- DHCP消息类型设置为5，表示DHCPACK。
客户端在接收到DHCP ack广播后，会向网络发送三个针对此IP地址的ARP解析请求以执行冲突检测，如果发现该IP地址已经被使用，客户机会发出一个DHCP decline数据包给DHCP服务器，拒绝此IP地址租约，并重新发送DHCP discover信息。
3.3 DHCP客户端续租
DHCP客户端续租交互示意图，来自华为IP知识百科：什么是DHCP？为什么要用DHCP？ - 华为 (huawei.com)
DHCP客户端在获得IP地址后，需要在租约期限内定期续租，以下是DHCP客户端续租的流程：
(1) T1时间点(Renewal时间点)，T1时间点是租约时间的50%，例如，如果租约时间为8天，则T1时间点为4天。
- 当客户端达到T1时间点时，它会尝试与为其提供IP地址的DHCP服务器联系，以续租其IP地址。
- 客户端向DHCP服务器发送一个DHCPREQUEST消息。
- 客户端IP地址(ciaddr)，客户端当前使用的IP地址。
- 服务器标识符(option 54)，提供客户端当前IP地址的DHCP服务器的IP地址。
- 此DHCPREQUEST消息以单播方式发送给DHCP服务器。
(2) DHCP服务器响应，如果DHCP服务器可以续租客户端的IP地址，它会响应一个DHCPACK消息，确认续租请求。
-
客户端IP地址（ciaddr）：确认客户端当前使用的IP地址。
-
租约时间（option 51）：更新后的租约时间。
-
客户端收到DHCPACK消息后，更新其租约时间，并继续使用当前的IP地址。
(3) T2时间点(Rebinding时间点)，T2时间点是租约时间的87.5%，例如，如果租约时间为8天，则T2时间点为7天。
- 如果客户端在T1时间点之后未能从DHCP服务器收到DHCPACK消息，则在达到T2时间点时，客户端会尝试与任何DHCP服务器联系以续租其IP地址。
- 客户端会广播一个DHCPREQUEST消息，以便任何DHCP服务器都可以响应。
- 客户端IP地址(ciaddr)，客户端当前使用的IP地址。
(4) DHCP服务器响应，任何收到DHCPREQUEST消息的DHCP服务器都可以响应一个DHCPACK消息，确认续租请求。
- DHCPACK消息包含与步骤2中相同的重要字段。
- 客户端收到DHCPACK消息后，更新其租约时间，并继续使用当前的IP地址。
如果客户端在T2时间点之后仍未收到DHCPACK消息，则它必须停止使用当前的IP地址，并重新启动DHCP流程，从DHCPDISCOVER阶段开始请求新的IP地址。
3.4 DHCP中继场景接入网络流程
DHCP中继场景交互示意图，来自华为IP知识百科：什么是DHCP？为什么要用DHCP？ - 华为 (huawei.com)
在DHCP中继场景下，DHCP客户端和服务器之间的交互流程与直连场景类似，以下是DHCP中继场景下的大致流程：
(1) DHCP Discover，客户端广播DHCPDISCOVER消息，请求IP地址。
- DHCP中继代理（通常是路由器）接收到DHCPDISCOVER消息。
- 中继代理将DHCPDISCOVER消息中的giaddr字段设置为自己的IP地址，并将消息转发给DHCP服务器。
(2) DHCP Offer，DHCP服务器收到转发的DHCPDISCOVER消息，选择一个可用的IP地址，并发送DHCPOFFER消息给中继代理。
- 中继代理接收到DHCPOFFER消息，将其转发给客户端。
(3) DHCP Request，客户端接收到一个或多个DHCPOFFER消息，选择其中一个，并广播DHCPREQUEST消息。
- 中继代理接收到DHCPREQUEST消息，将其转发给DHCP服务器。
(4) DHCP Ack，DHCP服务器收到转发的DHCPREQUEST消息，确认IP地址分配，并发送DHCPACK消息给中继代理。
- 中继代理接收到DHCPACK消息，将其转发给客户端。
与直连场景相比，DHCP中继场景有以下主要差异：
-
中继代理的作用，在DHCP中继场景下，客户端和服务器之间存在一个或多个中继代理(通常是路由器)。
-
giaddr字段的使用，在DHCP中继场景下，中继代理将自己的IP地址插入到DHCPDISCOVER和DHCPREQUEST消息的giaddr字段中。DHCP服务器使用giaddr字段来识别客户端所在的子网，并选择适当的IP地址进行分配。
-
消息转发，在DHCP中继场景下，客户端和服务器之间的DHCP消息由中继代理进行转发。
在DHCP客户端视角，DHCP中继与DHCP服务器一样，交互流程和直连场景无异。在DHCP中继和DHCP服务器之间，所有交互报文都是单播报文，两者的IP信息都是固定的，因此无需通过广播报文进行发现和查找。
3.5 DHCP客户端状态机
DHCP客户端状态变更图，来自37 张图详解 DHCP ：给你 IP 地址的隐形人 - 知乎 (zhihu.com)
非常推荐这篇文档，里面有很多简洁易懂的图，可以用来直观形象的感受DHCP工作流程。
DHCP客户端的状态机流程图描述了客户端在获取、使用和更新IP地址时所经历的不同状态，如下所示:
-
初始(INIT)状态：
- 客户端开始DHCP进程，准备请求IP地址。
- 客户端转换到SELECTING状态。
-
选择(SELECTING)状态：
- 客户端广播DHCPDISCOVER消息，请求IP地址。
- 当客户端收到一个或多个DHCPOFFER消息时，它选择其中一个服务器，并转换到REQUESTING状态。
-
请求(REQUESTING)状态：
- 客户端向选定的服务器发送DHCPREQUEST消息，请求所选的IP地址。
- 如果客户端收到DHCPACK消息，表示服务器确认了IP地址分配，客户端转换到BOUND状态。
- 如果客户端收到DHCPNAK消息，表示服务器拒绝了IP地址请求，客户端返回到INIT状态。
-
绑定(BOUND)状态：
- 客户端已成功获得一个IP地址，并可以使用它进行网络通信。
- 当租约时间的50%（T1时间点）过去后，客户端转换到RENEWING状态。
- 如果租约时间过期，客户端返回到INIT状态。
-
更新(RENEWING)状态：
- 客户端向原DHCP服务器发送DHCPREQUEST消息，请求续租其IP地址。
- 如果客户端收到DHCPACK消息，表示服务器确认了续租请求，客户端返回到BOUND状态。
- 如果租约时间的87.5%（T2时间点）过去后，客户端转换到REBINDING状态。
-
重新绑定(REBINDING)状态：
- 客户端向所有DHCP服务器广播DHCPREQUEST消息，请求续租其IP地址。
- 如果客户端收到DHCPACK消息，表示服务器确认了续租请求，客户端返回到BOUND状态。
- 如果租约时间过期，客户端返回到INIT状态。
3.6 DHCP认证
DHCP认证是一种安全机制，用于验证DHCP客户端的身份，并确保只有经过授权的客户端才能获得IP地址和其他网络配置参数。
DHCP认证通常使用DHCP消息中的认证选项（Option 90）来携带认证信息。常见的DHCP认证协议包括DHCP Authentication Protocol (RFC 3118)和DHCP Delayed Authentication Protocol (RFC 4030)。
DHCP认证可以使用共享密钥或数字证书等方法来验证客户端的身份。
- 共享密钥认证：客户端和服务器使用预共享的密钥对DHCP消息进行签名和验证。
- 数字证书认证：客户端使用数字证书对DHCP消息进行签名，服务器使用证书的公钥验证签名。
DHCP认证过程如下：
- 客户端在DHCPDISCOVER或DHCPREQUEST消息中包含认证选项，其中包含客户端的标识符和签名。
- 服务器接收到包含认证选项的DHCP消息后，使用共享密钥或数字证书验证客户端的签名。
- 如果认证成功，服务器会处理客户端的请求，并发送包含认证选项的DHCPOFFER或DHCPACK消息。
- 如果认证失败，服务器会忽略客户端的请求，或发送DHCPNAK消息。
DHCP认证可以防止未经授权的客户端获得IP地址和其他网络资源。通过认证，管理员可以对网络接入进行更严格的控制，防止DHCP欺骗和其他类型的攻击。
4. 总结
DHCP协议是日常生活中到处可见的动态地址配置协议，相对而言比较复杂，涉及广播报文和8种消息类型的交互。
在深入学习和分析之后，主要可以分为DHCP客户端获取IP地址和租期续约两种流程。每种流程的消息类型和交互是固定样式，因此掌握起来并不难。
DHCP协议报文交互学习的一种有效方式是通过wireshar抓包分析实际报文，TCP详解和各种网页文档，基本都包含这步，所以本篇文档就不再重复这步，如下:
- 37 张图详解 DHCP ：给你 IP 地址的隐形人 - 知乎 (zhihu.com)
- DHCP协议详解 - 知乎 (zhihu.com)
这两份文档里面关于DHCP交互流程，介绍很充分，值得一看。
对于DHCPv6协议，整体上和DHCPv4类似，但是细节不同，下篇文档单独介绍。
Once Day
也信美人终作土，不堪幽梦太匆匆......
如果这篇文章为您带来了帮助或启发，不妨点个赞👍和关注，再加上一个小小的收藏⭐！
(｡◕‿◕｡)感谢您的阅读与支持~~~
