DHCP协议详细流程分析

本文将解释DHCP的详细操作。

首先，我们将描述一种检测通过DHCP刚分配/租用的IP地址与先前分配的IP地址之间的IP地址冲突的过程。

接下来，我们将研究如何传输DHCP服务器发送的DHCP Offer / Ack消息（广播或单播）。

最后，我们将解释状态转换图，该图说明了DHCP客户端如何在IP地址分配和租用时间过程继续进行时进行状态转换。

概述

动态主机配置协议（DHCP）已被广泛用作一种协议，用于随着时间的推移将网络配置数据（包括IP地址）动态分配给运营商网络和公司网络内的客户端设备（PC）。尽管数十年来协议的使用如此广泛，但只有极少数人完全了解其详细操作。因此，在本文档中，我们将通过三个不同的技术主题来解释DHCP的详细操作。

本文档涵盖有关DHCP详细操作的三个技术主题，其组织方式如下：第二章将描述具有分配/租用IP地址的DHCP客户端如何通过地址解析协议（ARP）检测IP地址冲突。第三章将描述如何根据DHCP Discover / Request消息的广播标志将DHCP Offer / Ack消息单播或广播到DHCP服务器。第四章将描述IP地址分配/租赁和IP地址更新过程中设备（DHCP客户端）的状态转换。

检测IP地址冲突的过程

设备通过图1中的过程（a）〜（d）获得DHCP服务器分配的IP地址后，它将在同一子网中广播ARP请求数据包（使用分配的IP地址作为目标IP地址）以检测一个客户端设备，该客户端设备使用与自己的IP地址相同的IP地址，如图1的过程（e）所示。然后，它会等待发送任何ARP Reply数据包以响应其广播的ARP Request数据包。如果有ARP Reply数据包，则表示子网中有冲突的设备，如果没有，则表示没有冲突的设备。

图1. IP地址分配和IP冲突检测过程

图2显示了从PC（Windows 7）广播以检测IP地址冲突的ARP请求数据包。此处，数据包正在传送的消息是“请让我（00：17：42：c1：c8：f7）知道是否存在IP地址为（192.168.10.11）的设备”。

图2.用于检测IP地址冲突的ARP请求数据包

发送ARP请求报文的过程如下：

1. 它被广播到整个子网，以便所有客户端都可以接收该数据包。
2. 发送方MAC地址字段包括发送数据包的客户端的MAC地址（00：17：42：c1：c8：f7）。
3. “发件人IP地址”字段包含一个无效地址（0.0.0.0）而不是分配给客户端的地址，以防止同一子网上的其他设备/路由器更新其自己的ARP缓存（因为尚未确认是否或设备无法使用IP地址（192.168.10.11）。
4. 目标IP地址字段包括由DHCP服务器分配的客户端IP地址。如果还有其他客户端已经在使用相同的IP地址，则它将发送ARP Reply数据包以响应ARP Request数据包。

通常，子网上没有其他客户端具有与该客户端相同的IP地址（除非IP地址已在PC中设置为静态IP地址）。显然，客户端没有收到响应ARP请求数据包的ARP应答数据包，最后使用DHCP服务器分配的IP地址连接到Internet。

但是，如果其他客户端已经在使用与子网中的客户端相同的IP地址，则接收ARP请求数据包的其他客户端将通过单播ARP应答数据包来进行响应，如图1的过程（f）所示。 。那就是传达一条信息，“我正在使用IP地址！” 到客户端（ARP请求数据包的发送者）。图3显示了ARP Reply数据包中包含的信息。

图3. IP地址冲突时，冲突的客户端发送的ARP应答数据包

发送ARP应答报文的过程如下：

1. 接收到ARP Request数据包的客户端发送ARP Reply数据包，其中包括分别设置为ARP Reply数据包发送方的MAC地址和ARP Request数据包发送方的MAC地址的源MAC地址和目标MAC地址。
2. “发件人MAC地址”和“发件人IP地址”字段分别包括ARP回复发送者的MAC地址和IP地址。
3. 目标MAC地址字段包括ARP应答数据包接收者的MAC地址。

当客户端通过这些过程意识到其IP地址冲突时，它通过向服务器发送DHCP拒绝消息来通知DHCP服务器已分配的IP地址已在子网中使用的事实。然后，客户端恢复另一个IP分配过程，再次广播DHCP发现消息。

DHCP提供/确认消息：广播还是单播？

根据我们的技术文档“了解DHCP的基本操作” [3]，将广播IP分配过程中交换的所有DHCP消息（包括DHCP Offer / Ack）（目标MAC = FF：FF：FF：FF： FF：FF，目标IP = 255.255.255.255），如表1所示。

表1. DHCP消息的以太网和IP地址

但是，某些与DHCP有关的文档对DHCP Offer / Ack消息的传输模式提供了不同的解释，从而引起混乱。

因此，为了更清楚地了解，我们配置了一个网络环境，其中Wireshark（http://www.wireshark.org/）安装在PC（Windows 7）上，如图1所示。然后，我们捕获了DHCP消息。查看使用捕获程序广播的消息还是单播的消息，并分析捕获的消息以找出使它们成为单播或广播的原因。

为此，我们让PC通过在DOS命令窗口中输入“ ipconfig / release”和“ ipconfig / renew”来获得IP地址。

DHCP发现消息

图4显示了PC（Windows 7）发送到DHCP服务器的DHCP Discover消息。

图4. DHCP发现消息

在这里，PC：

1. 在以太网上广播了DHCP Discover消息，其中源MAC地址和目标MAC地址分别设置为PC MAC地址和FF：FF：FF：FF：FF：FF。
2. 在子网中广播了DHCP Discover消息，其中源IP地址和目标IP地址分别设置为0.0.0.0和255.255.255.255。
3. 将消息中的“广播标志”设置为0，以使将接收并响应DHCP发现消息的DHCP服务器知道PC希望通过单播接收DHCP优惠消息。
4. 发送了一条DHCP Discover消息以及它保留在其中的分配的IP地址（192.168.10.28）（Windows 7注册表），以传达一条消息，“我想接收相同的IP地址192.168.10.28”到DHCP服务器。

DHCP提供消息

图5显示了DHCP服务器响应DHCP Discover消息而发送到DHCP客户端（Windows 7）的DHCP Offer消息。

图5. DHCP提供消息

在这里，DHCP服务器：

1. 在以太网上单播一条消息，其中源MAC地址和目标MAC地址分别设置为DHCP服务器MAC地址和PC MAC地址。由于DHCP Discover消息的广播标志值，其结果与表1中的结果（目标IP地址是广播地址）不同。换句话说，如果将DHCP发现消息的广播标志值设置为0（表示单播模式），则DHCP服务器肯定会单播DHCP提供消息。
2. 在IP子网上单播一条消息，其中源IP地址和目标IP地址分别设置为DHCP服务器IP地址和Your IP Address = 192.168.10.28。同样，由于DHCP Discover消息的广播标志值，其结果与表1中的结果（目标IP地址是广播地址）不同。换句话说，如果将DHCP Discover消息的Broadcast Flag值设置为0（表示单播模式），则DHCP服务器肯定会单播DHCP Offer消息。
3. 复制DHCP Discover消息的广播标志值，将其粘贴到DHCP Offer消息的相应字段中，然后将其发送给客户端。

DHCP请求消息

图6显示了从DHCP客户端（Windows 7）到DHCP服务器的DHCP请求消息。

图6. DHCP请求消息

在这里，DHCP客户端：

1. 在以太网上广播了一条消息，其中源MAC地址和目标MAC地址分别设置为PC MAC地址和FF：FF：FF：FF：FF：FF。
2. 在IP子网上广播了一条消息，其中源IP地址和目标IP地址分别设置为0.0.0.0和255.255.255.255。
3. 将消息中的“广播标志”设置为0，以使将接收并响应DHCP请求消息的DHCP服务器知道其希望通过单播接收DHCP确认消息。

DHCP确认消息

图7显示了响应于DHCP请求消息而从DHCP服务器发送到DHCP客户端（Windows 7）的DHCP Ack消息。

图7. DHCP确认消息

在这里，DHCP服务器：

1. 在以太网上单播一条消息，其中源MAC地址和目标MAC地址分别设置为DHCP服务器MAC地址和PC MAC地址。没有将目标地址设置为广播MAC地址，因为客户端发送的DHCP请求消息的广播标志值设置为0（单播）。
2. 在IP子网上单播一条消息，其中源IP地址和目标IP地址分别设置为DHCP服务器IP地址和Your IP Address = 192.168.10.28。同样，如在MAC地址中一样，未将目标地址设置为广播IP地址，因为客户端发送的DHCP请求消息的广播标志值设置为0（单播）。
3. 复制DHCP请求消息的广播标志值，将其粘贴到DHCP Ack消息的相应字段中，然后将其发送给客户端。

表2总结了上述测试结果。Windows PC（Windows 7）在DHCP Discover / Request消息中将“ Broadcast Flag”设置为0，以便它可以在单播模式下直接从DHCP服务器接收DHCP Offer / Ack消息。

表2. Windows 7 PC环境中DHCP消息的以太网和IP地址

这样，DHCP服务器根据DHCP发现/请求消息的广播标志值广播或单播DHCP提供/确认消息。引用DHCP标准[1]的以下文本来客观地支持有关DHCP消息操作的此类发现。

• 如果’giaddr’为零且’ciaddr’为零，并且设置了广播位（在DHCPDISCOVER和DHCPREQUEST消息中），则服务器将DHCPOFFER和DHCPACK消息广播到0xffffffff
• 如果未设置广播位，并且’giaddr’为零且’ciaddr’为零（在DHCPDISCOVER和DHCPREQUEST消息中），则服务器将DHCPOFFER和DHCPACK消息单播到客户端的硬件地址和’yiaddr’地址

DHCP消息中的广播标志值根据客户端PC的TCP / IP实现特定的性质而变化（0或1）。在最终通过DHCP Ack消息分配IP地址之前，某些客户端PC不能将IP地址用作其目标地址并在该地址接收单播数据包。在这种情况下，客户端PC已被编程为发送带有“广播标志= 1”的DHCP发现/请求消息。与此相反，如果客户端PC（Windows PC）甚至在IP分配之前就可以接收单播数据包，则它已被编程为发送带有“广播标记= 0”的DHCP发现/请求消息。

DHCP客户端的状态转换

图8是说明DHCP客户端在交换DHCP消息时的内部状态转换的图。

图8是说明DHCP客户端在交换DHCP消息时的内部状态转换的图。

图8. DHCP客户端的状态转换图

• 在INIT状态下，客户端PC广播DHCP Discover消息以搜索DHCP服务器，然后转换为SELECTING状态。
• 在SELECTING状态下，客户端PC将保持待机状态，等待DHCP Offer消息。在接收到多个DHCP Offer消息时，客户端PC选择一条消息（即，首先接收到的消息或从先前已为其分配IP地址的DHCP服务器接收到的一条消息），并广播包括所选DHCP服务器的DHCP请求消息。信息。然后，它转换为REQEUSTING状态。
• 在请求状态下，客户端PC收到DHCP Ack消息后，将根据DHCP Ack消息中指定的IP地址租用时间配置T1和T2计时器，并转换为BOUND状态。此处，计时器T1和T2用于延长IP地址的租用时间，可以根据参考文献[1]进行如下配置：
  • T1计时器：0.5 x IP地址租用时间（例如，如果IP地址租用时间为1小时，则T1设置为30分钟）
  • T2计时器：0.875 x IP地址租用时间（例如，如果IP地址租用时间为1小时，则T1设置为52.5分钟）
• 在BOUND状态下，客户端PC会检查DHCP服务器分配的IP地址是否在同一子网中（请参阅检测IP地址冲突的过程），并根据其中包含的信息配置网络环境。 DHCP确认消息。现在，客户端PC已连接到Internet。稍后，如果在客户端PC处于BOUND状态时T1计时器到期，则客户端PC单播DHCP请求消息以更新其IP地址，然后转换为RENEWING状态。
• 在RENEWING状态下，如果客户端PC从DHCP服务器接收到包含网络配置数据的DHCP Ack消息（因此被允许延长IP地址租用时间），它将重置T1和T2计时器并转换为BOUND状态。如果没有收到服务器的响应，它将保持待机状态，等待DHCP确认消息，直到T2计时器到期，然后转换为REBINDING状态。在RENEWING状态下，即使客户端PC尚未从DHCP服务器收到任何DHCP Ack消息，它也可以在租用时间内保持联机状态。
• 在重新绑定状态下，客户端PC在子网上广播DHCP请求消息，以便所有DHCP服务器都可以接收该消息。在这种状态下，如果客户端PC从DHCP服务器接收到DHCP确认消息，它将重置T1和T2计时器，并转换回BOUND状态。但是，如果没有收到来自DHCP服务器的响应消息，它将转换为INIT状态。在REBINDING状态下，即使客户端PC尚未从DHCP服务器收到任何DHCP Ack消息，它也可以保持联机状态，直到转变为INIT状态为止。
• INIT-REBOOT状态代表客户端PC已经知道要分配的IP地址，并且客户端PC（Windows 7）重新引导时转换为该状态的状态。在此状态下，客户端PC广播DHCP请求消息，然后转换为REBOOTING状态。

• 在REBOOTING状态下，客户端PC在收到DHCP Ack消息后，根据DHCP Ack消息中指定的IP地址租用时间设置T1和T2计时器，然后转换为BOUND状态。