DHCP协议
DHCP协议——RFC2131
1 Introduction
该协议定义为Dynamic Host Configuration Protocol（D H C P），旨在解决动态主机配置问题。该协议提供了一个在网络层（TCP/IP）中分配给主机所需参数的一个框架。它源于BOOTP协议，并引入了可重用地址自动分配功能以及额外的设置选项以提高网络效率与灵活性。此外，在与 traditional BOOTP 设备交互时实现了良好的兼容性。
1.1 相关协议
对于动态主机配置问题的解决，在现有技术中已有多种网络协议与机制进行了相关处理。其中RARP协议明确地解决了网络地址识别的问题并拥有自动IP分配功能；而TFTP则负责将一个较小且简单的文件从启动服务器传输；此外ICMP协议通过发送'ICMP重定向'消息实现了对路由器相关信息的有效通知；同时该协议还能够借助'ICMP掩码请求'消息传递子网掩码数据；此外主机还可以依靠'ICMP路由发现'机制来确定路由器的具体位置。一般而言，在常规网络环境中通常会有多款协议协同解决动态主机配置问题；其中主要采用的是DHCP协议，在配置初始化阶段发挥核心作用；而在后续操作中，则主要依赖于其在地址更新或重新分配过程中的服务功能。
1.2 设计目标
RFC 2131对DHCP协议的设计思路进行了明确的目标设定,这也正是该协议所具备的基本功能.
- DHCP本质上是一个机制而非策略
- 无需由客户端进行手动参数配置
- 无需对客户机进行自动配置相关网络参数
- 不应在每个子网内独立配置独立的 DHCP 服务器
- 必须能够及时处理来自客户机端点的同时多条响应请求
- 需要与静态主机、非活跃参与网络协议以及现有的网络规范协同工作
- 支持与 RFC 951 和 RFC 1542 所定义的 BOOTP 中继代理行为的交互操作
- 应能够提供服务给现有的 BOOTP 客户端
因此，DHCP必须：
- 确保同一时间段内, 每个网络地址仅绑定一个 DHCP 客户端。
- 即使重新启动客户端，在满足条件时为每个请求提供一致的 DHCP 配置。
- 即使服务器发生重启，在满足条件时为 DHCP 客户端分配与当前相同的配置参数。
- 系统应支持自动为新连接申请必要的 DHCP 参数。
- 具体而言，则可针对特定客户维护其固定或永久性的 DHCP 配置设置。
1.3 术语
1.4 资料引用
这三个文档分别是RFC 2131、RFC 951以及RFC 1542
2 Summary
从客户端角度来看，DHCP可以被视为BOOTP机制的一种延伸。这种设计使得现有的BOOTP客户端能够直接与DHCP服务器实现交互，并不需要对客户端初始化程序进行任何修改即可实现功能。根据RFC 1542，该标准不仅涵盖了基本功能的描述还包括其与其他相关协议如RIP（另一种网络层协议）之间的兼容性问题。在RFC 2131中进一步引入了一些新的可选处理方案以优化双方的数据包交换过程。
| FIELD | OCTETS | DESCRIPTION |
|---|---|---|
| op | 1 | Message op code / message type. 1 = BOOTREQUEST, 2 = BOOTREPLY |
| htype | 1 | Hardware address type, see ARP section in “Assigned Numbers” RFC; e.g., ’1’ = 10mb ethernet. |
| hlen | 1 | Hardware address length (e.g. ’6’ for 10mb ethernet). |
| hops | 1 | Client sets to zero, optionally used by relay agents when booting via a relay agent. |
| xid | 4 | Transaction ID, a random number chosen by the client, used by the client and server to associate messages and responses between a client and a server. |
| secs | 2 | Filled in by client, seconds elapsed since client began address acquisition or renewal process. |
| flags | 2 | Flags (see figure 2). |
| ciaddr | 4 | Client IP address; only filled in if client is in BOUND, RENEW or REBINDING state and can respond to ARP requests. |
| yiaddr | 4 | ’your’ (client) IP address. |
| siaddr | 4 | IP address of next server to use in bootstrap; returned in DHCPOFFER, DHCPACK by server. |
| giaddr | 4 | Relay agent IP address, used in booting via a relay agent. |
| chaddr | 16 | Client hardware address. |
| sname | 64 | Optional server host name, null terminated string. |
| file | 128 | Boot file name, null terminated string; “generic” name or null in DHCPDISCOVER, fully qualified directory-path name in DHCPOFFER. |
| options | var | Optional parameters field. See the options documents for a list of defined options. |
目前，‘option’字段的长度是可变的，但长度至少在312字节，这一要求表明，一个DHCP客户端必须能够接受一个长度达576字节的消息，这是一个IP主机必须能接收的最小IP数据报长度。DHCP客户端可以通过’maximum DHCP message size’选项协商使用更大的DHCP消息报文。这一选择字段可能在后续扩展进‘filt’和‘sname’字段。
在一个客户端使用DHCP用于初始化配置的情况下，DHCP需要对客户端TCP/IP软件进行创造性的运用，并对RFC 1211进行自由的解释。在IP地址配置之前，TCP/IP软件应该接受和转发任何客户端接收到的IP报文给IP层；在TCP/IP软件被配置之前，DHCP服务器和BOOTP中继器肯恩无法传送DHCP消息给那些无法接收硬件广播数据报的终端。针对这些终端，DHCP使用‘flags’字段，如下图2所示，最左边的bit被定义为BROADCAST（B）标志位，该位语义的讨论稍后展开。其他位必须被客户端设为0并且被服务器和中继器忽略。
2.1 配置参数仓库
第一个由DHCP提供的服务旨在向网络客户端提供持久化的网络参数存储库。其模式为：DHCP服务会将每个客户端存储一个键值入口，在此入口中键是一个独特的标识符；其值则包含该客户端相应的配置信息。
例如，在某些情况下：
- 键可以是一对（IP子网号与硬件地址），这种赋值允许在不同的子网上连续或同时使用同一个硬件地址；此外还可以采用非全局唯一的硬件地址。
- 或者键可以是一对（IP子网号与主机名），这种机制使得服务器能够智能地自动分配给已移机或更换了硬件地址的主机新的IP地址。
根据协议定义，在未明确支持客户识别符的情况下，默认情况下键应采用（IP子网号与硬件地址）这对组合。
此外，在发生故障时客户机可以通过发起重置配置请求来恢复相关设置；客户机与此存储库之间的接口包括两个方面：发送方发起重置配置的数据包以及接收方返回的相关数据包。
2.2 网络地址的动态配置
向客户端临时或永久分配网络地址是 DHCP 的第二个服务。该服务的基本运作如下：客户端可在指定时间段内请求使用某个网络地址。这种动态分配机制确保在指定的时间段内不会重复使用同一网络地址，并尽可能在同一时间段内每次请求都获得相同的网络地址。根据 DHCP 协议，在此期间称为租期（lease）。客户端可通过后续请求延长租期，在无需IP时可通过发送消息将已使用的IP释放回服务器。如果客户端愿意接受无限租期，则可获得永久性的IP地址分配。然而即使获得了永久性IP地址，在这种情况下服务器可能仍会提供一个很长但非无限的租期给客户端以进行退出状态探测。
在某些环境中当可用 IP 地址用尽时 网络地址重新分配机制会开始工作 这种机制会重用那些已过时的租期 服务器应利用参数信息仓库中的任何可用信息来选择一个可重用的IP 地址 例如最近最少被使用的IP 可供选择作为候选值 作为对这种行为兼容性的检测 分配服务器应在尝试重新使用旧IP之前先探测该旧IP是否仍被当前客户端所拥有 可以通过向目标服务器发送ICMP ECHO请求来实现这一点 同样地 客户端也需要探测新接收到的新IP以确定其有效性
2.3 DHCP和BOOTP的区别
DHCP和BOOTP有两个主要的区别：
- DHCP定义了一种机制，在一个限定的时间段内为客户端分配一个网络地址，并赋予其选择多个网络地址的权利。
- DHCP提供的机制能够自动为客户端获取所需的IP配置信息进行配置。
此外，在术语体系上,DHCP对某个字段的意义做出了微调.其中, BOOTP中的‘vendor extension’一词在DHCP中被正式定性为option.类似的数据项名称同样被统一命名为option.
3 客户端-服务器协议
DHCP使用BOOTP消息格式（RFC 951），每一个从客户端发送到服务器的DHCP消息的‘op’字段办好BOOTREQUEST，BOOTREPLY在每一个从服务器发送到客户端的DHCP消息中的‘op’字段使用。
DHCP消息的‘options’字段的前四个字节分别包含四个十进制数值99,130,83和99，该字段的余下部分由一系列被称为‘options’的打了标签的参数组成。RFC 1497中所有列出的供应商扩展‘vender extension’也是DHCP选项。RFC 1533给出了DHCP使用的一套完整的选项定义。
目前，一些选项已经被定义。一个特殊的option——DHCP消息类型选项——必须被包含在每一个DHCP消息中。这个option定义了DHCP消息的类型。其他选项的允许、需要、或不被允许都依赖于该DHCP消息类型。
3.1 客户端-服务器交互——分配一个网络地址
客户端与服务器之间的交互基于DHCP消息（如图2所示）。图3中的时序图呈现了一个典型客户端-服务器交互的时间轴关系。若客户端已熟悉自身IP地址，则部分操作步骤可被简化处理。
| Message | Use |
|---|---|
| DHCPDISCOVER | Client broadcast to locate available servers. |
| DHCPOFFER | Server to client in response to DHCPDISCOVER withoffer of configuration parameters. |
| DHCPREQUEST | Client message to servers either (a) requesting offered parameters from one server and implicitly declining offers from all others, (b) confirming correctness of previously allocated address after, e.g., system reboot, or (c) extending the lease on a particular network address. |
| DHCPACK | Server to client with configuration parameters, including committed network address. |
| DHCPNAK | Server to client indicating client’s notion of network address is incorrect (e.g., client has moved to new subnet) or client’s lease as expired |
| DHCPDECLINE | Client to server indicating network address is already in use. |
| DHCPRELEASE | Client to server relinquishing network address and cancelling remaining lease. |
| DHCPINFORM | Client to server, asking only for local configuration parameters; client already has externally configured network address. |
Table 2： DHCP message
- 客户端在物理子网络上发布DHCPDISCOVER消息（选项可能包含建议值）。该消息可能会通过中继器传递至不同的物理子网络。
- 相应服务器可能返回DHCPOFFER消息（'yiaddr'字段包含可用地址），该消息可能包含其他配置信息。服务器无需存储已提供的地址信息；当分配新地址时需检查已提供的地址是否已被使用（例如通过ICMP Echo请求探测）。服务器可选择不探测新分配地址；必要时可利用中继器将DHCPOFFER消息传输给客户端。
- 客户端从一个或多个服务器接收一个或多个DHCPOFFER消息（基于配置参数选择目标服务器），然后发送DHCPREQUEST消息（带有目标服务器标识），并可能附加其他参数以指定所需配置值。所选IP地址必须与收到的DHCPOFFER消息中的yiaddr字段值一致；DHCPREQUEST消息经中继器传播并转发至初始接收点的所有相关服务器。
- 服务器接收客户端发送的DHCPREQUEST消息（广播）；未被选中的服务器可通过此得知客户端拒绝其请求；被选中的服务器为其绑定永久存储设备，并用DHCPACK响应（携带客户端参数）；客户端ID与分配IP组合构成唯一租期标识符。
- DHCPACK消息中的参数不应与DHCPOFFER中的冲突；服务器无需检查分配IP是否可用；
- 如果目标服务器无法满足要求（如IP已被占用），则返回DHCPACK响应；
- 被标记为不可用的地址若无相应请求则重新变为可用状态。
当客户端接收到包含配置参数的DHCPACK报文时，在完成相关检测后（例如通过ARP协议验证分配的网络地址），必须注明DHCPACK报文中指定的时间租期。在此过程中，默认情况下该端口已为该设备配置相关服务信息。若客户端通过ARP探针探测到目标地址已被占用，则应立即发送DHCPDECLINE报文指示冲突，并重新开始配置流程。在重新开始配置前，请确保等待至少10秒以避免网络超载问题。
在收到DHCPDECLINE报文后，请立即重启配置流程。
若未接收到DHCPACK或DHCPDECLINE报文，则应等待超时时间后按照重传算法重新发送 DHCP.REQUEST 报文（建议最多重传4次）。为了尽可能联系服务器并减少等待时间，在重传过程中应尽量减少重复操作以控制总延迟时间（建议不超过60秒）。如果经过四次重传仍未能成功接收 DHCPACK 和 DHCPNAK 报文，则应返回初始状态并重启整个初始化过程，并将相关信息通知用户。
通过发送DHCP_RELEASE消息至服务器端上, 客户端能够放弃其在某特定网络地址上的租赁. 在 DHCP_RELEASE 消息中明确标出客户标识符 (client identifier) 或 chaddr 信息及相关网络地址信息, 即可表明上述租赁关系已被解除. 特别指出, 在此操作过程中所使用的客户标识符必须与之前获取该租赁时所采用的一致.
3.2 客户端-服务器交互——重用一个之前分配的网络地址
如果客户端能够记住并选择性地重用之前分配的一个网络地址，则可以选择跳过一些上述提到的关键步骤
-
客户端向其子网发送DHCPREQUEST消息，在该消息中携带了客户端网络地址信息（即'requested IP address'字段中的值）。由于客户端尚未获得其所在的网络地址信息,'ciaddr'字段因此无法填入有效数据。BOOTP中继器将在同一子网上将此消息转发给 DHCP 服务器进行处理。
若客户端曾通过 'client identifier' 获取其IP地址,则在 DHCPREQUEST 消息中必须使用相同的 'client identifier' 进行标识。 -
当服务器收到携带客户端配置参数的 DHCPACK 消息时,它无需检查客户端当前所在的网络是否已使用;此时,客户端可以通过响应ICMP Echo请求来确认响应状态。（换言之,DHCP 服务器可以直接返回 DHCPACK 消息,而无需主动进行检测,但可以通过客户端对ICMP Echo请求的响应来进行间接探测）。
若客户机的请求无效（例如已移动至新子网）,则服务器应返回 DHCPNAK 回复；但如果服务器无法保证当前绑定信息的有效性,则不应返回此回复。
例如,当服务器检测到一个过期绑定请求时（该绑定属于其他服务器），它不应发送 DHCPNAK 回复,除非通过某种机制维护各服务之间的一致性（coherency）。
当 DHCPREQUEST 消息中的 'giaddr' 值为 0x0 时,表示客户端与服务器位于同一子网内。
在这种情况下,所有广播型 DHCPNAK 消息必须以全广播地址（即 0xffffffff）发送给各客户端；此外,每台服务还须将 DHCPNAK 消息发送给对应的 BOOTP 中继器 IP 地址。
相应地,中继器会直接转发此消息至客户端硬件地址端口；这样一来,即使客户机被移动至新子网,DHCPNAK 也能及时传送到相关设备上进行处理。 -
客户端接收到包含配置信息的DHCPACK报文后会进行最终参数验证，并会说明消息中所设定的时间跨度。该时间跨度将被精确地通过'client identifier'或'chaddr'以及网络地址加以明确标识。
在此情况下如果客户端检测到DHCPACK中的IP地址已被使用必须向服务器发送DHCPDECLINE报文并重新获取新网络地址以重启配置流程这一操作与 DHCP 状态机中客户端移至初始状态的行为相对应。
如果客户端接收到 DHCPNAK 报告那么它将无法复用已存储的网络地址相反必须重新启动配置流程以获取新地址这一次获取将采用本章所述的非简化方法。
如果客户端未能接收到 DHCPACK 或 DHCPNAK 报告则应等待超时后依据重传算法重新发送 DHCPREQUEST 报文直至联系服务器为止。
客户端应尽量多次（最多四次）重复发送 DHCPREQUEST 以减少等待时间以免导致在未过期租期结束前出现连接中断的风险选择重传次数后总延迟控制在 60 秒内。
若经过重传算法处理后依然未能接收到 DHCPACK 和 DHCPNAK 报告则应考虑继续使用当前配置（通常会在租期结束前四分之一半程三 quarters处自动续费）。 -
客户端可通过发送 DHCP_RELEASE 消息至服务器以主动放弃其在特定 IP 地址上的租赁期。该租赁期则可由 DHCP_RELEASE 消息中所包含的 'client identifier' 或 'chaddr' 以及相关 IP 地址共同确定。注意：当客户端本地维护其 IP 地址时，其无法正常地借助优雅关闭机制（graceful shutdown）释放该租赁期。仅当客户端明确有必要释放其租赁期时才采取此措施。
3.3 时间值的解释和表示
客户接收一个固定时间段内的IP地址租用时段（也可能设为无限）。该协议体系中所有时间均以秒作为单位计算。数值0xffffffff则用于表示无限时段。
鉴于客户端与服务器的时钟可能存在同步偏差，在DHCP消息中采用相对时间表示法，并由客户端本地时钟进行解读。
如前所述，在客户端与服务器时钟之间存在稳定关系的前提下，默认采用特定算法进行租期时间解释。然而，在实际应用中若出现时钟漂移情况，则可能导致服务器提前判断租期已结束。为此**,为了避免这种误判现象, 服务器可能会返回一个较短的时间跨度供客户端使用。
3.4 使用外部配置的网络地址获得参数
如果客户端通过其他方式获得了一个网络地址（例如手动设置），它可以通过发送DHCPINFORM请求消息来获取其他本地配置参数。当服务器接收到该 DHCPINFORM 请求时，会根据客户端的具体情况进行 DHCPACK 响应的构建过程；具体而言，在构建 DHCPACK 消息时应当避免包含如下信息：分配一个新的 IP 地址、审查现有的绑定记录、“yiaddr”字段的填充以及涉及租期时间参数的内容。此外，在 DHCPINFORM 请求中所指定的有效地址应被单播响应 DHCPACK 消息以完成数据传输过程。
3.5 DHCP中的客户端参数
通常情况下，在初始化阶段所需参数数量并非如附录A所述全部必要。有两项技术被用来降低传输给客户端的参数量。
- 大多数从服务器传送到客户端的参数本地已定义于Host Requirement RFCs中；若客户端未接收可修改这些默认值的参数，则将使用预设值。
- 初始化阶段，在 DHCPDISCOVER 和 DHCPREQUEST 消息中，客户端可向服务器传达一系列感兴趣的具体参数；若客户在 DHCPDISCOVER 中提供了该系列参数，则须在后续的所有 DHCPREQUEST 消息中包含它们。
客户端应设置‘最大 DHCP 消息长度’字段以告知服务器构建相应大小的 DHCP 报文。当回复给客户端的信息超出 DHCP 消息中分配给 options 字段的空间时，则需采用两个额外的标志位字段（这些标志位必须包含在消息的 options 字段中）来标识将用于选项设置的数据字段为文件名和 sname（即文件名和名称）。
通过设置‘请求参数列表’字段可以使客户端告知服务器哪些配置参数为其所关注。
该字段的数据部分明确列出了以标签号排序的选择请求数据。
此外，在 DHCPDISCOVER 消息中客户端可以提议指定所需的网络地址及其租约时间。
在‘请求 IP 地址’选项中客户端可指定分配的目标 IP 地址，并在‘IP 地址租约时间’字段中设定期望的时间跨度。
在配置参数中其他以暗示方式表现出来的选项同样可以在 DHCPDISCOVER 或 DHCPREQUEST 消息中使用。
然而，在某些情况下服务器可能会忽略这些额外选项并返回不一致的数据值。
需要注意的是只有当客户端处于 BOUND、RENEWING 或 REBINDING 状态下并且已正确配置了一个 IP 地址时才会填充‘ciaddr’字段。
如果服务器接收到一个包含无效‘请求 IP 地址’信息的 DHCPREQUEST 消息应当立即返回一个 DHCPNAK 消息并将错误信息可能包含在消息选项中的内容通知给客户端并可能向系统管理员反馈此问题
3.6 带有多路接口的客户端中DHCP的使用
带有多路网络接口的客户端每个都需要独立使用DHCP服务以获取配置信息参数
3.7 客户端何时使用DHCP
每当本地网络参数可能发生变化时，客户端应该使用DHCP服务去重新获取或校验它的IP地址和网络参数，比如系统启动时或从本地网络断开之后，因为本地网络配置可能在客户端或用户不知情的情况下发生改变。
如果客户端拥有一个之前分配的网络地址，并且无法连接到本地的DHCP服务器，客户端可以继续使用该网络地址，直到该地址的租约过期。
如果租约在客户端能够联系到服务器之前过期，客户端必须立刻停止使用该网络地址，并告知用户该问题。
4 DHCP客户端-服务器协议规范
4.1 构造和发送DHCP消息
DHCP客户端和服务器都通过在固定格式的消息字段里填充以及在变长选项区域里附加标签数据来构造DHCP消息。选项区域首先包含衣蛾四字节的‘magic cookie’，接着是选项字段。最后的选项必须是end。
DHCP使用UDP作为它的传输协议 。从客户端至服务器的DHCP消息从‘DHCP server’端口（67）发送，从服务器到客户端的DHCP消息从‘DHCP client’端口（68）发送。具有多个网络地址的服务器（比如一个多连接的主机），可以在发送的DHCP消息中使用它任意的网络地址。
‘server identifier’字段在DHCP消息中被用于识别DHCP服务器，也在从客户端到服务器的消息中作为目标地址。具有多个网络地址的服务器，必须准备好在DHCP消息中去接收它的任意一个网络地址来识别该服务器。为了适应潜在的不完全的网络连接，服务器必须选择一个能够被客户端获得的地址作为‘server identifier’。比如，如果DHCP客户端和服务器连接到相同的子网（比如，在来自客户端的消息中‘giaddr’字段为0），服务器应该选择它用于该子网通信的IP地址作为‘server identifier’。如果服务器在该子网上也使用多个IP地址，那么其中任意地址都是可用的。如果服务器从一个DHCP中继器接收到消息，服务器应该从接收消息的接口选择一个地址作为‘server identifier’（除非服务器由其他更好的信息来帮助做出选择）。DHCP客户端必须使用‘server identifier’选项提供的IP地址作为发送给DHCP服务器的单播请求的地址。
在客户端获取IP地址之前被该客户端广播的DHCP消息，必须让IP头部的源地址设为0.
如果来自客户端的DHCP消息中**‘giaddr’消息不为0** ，那么服务器将所有的回复消息发送到‘giaddr’字段中地址所指的BOOTP中继器的‘DHCP server’端口。如果‘giaddr’字段为0且‘ciaddr’不为0 ，那么服务器将向给‘ciaddr’字段中的地址单播DHCPOFFER和DHCPACK。如果‘giaddr’字段为0且‘ciaddr’为0，并且广播位被设置，那么服务器向0xffffffff广播DHCPOFFER和DHCPACK消息。如果广播为没有被设置，且‘giaddr’和‘ciaddr’为0，那么服务器将向客户端的硬件地址和‘yiaddr’地址单播DHCPOFFER和DHCPACK消息。在所有情况下，当‘giaddr’为0，那么服务器会将所有DHCPNAK消息广播到0xffffffff。
如果DHCP消息中的options扩展至‘sname’和‘file’字段，那么‘option overload’选项必须出现在‘options’字段中，限定值为1,2或3，如RFC 1533 中定义。
在一个‘option’标签中传递的值可能太长而无法填入单个option的可用的255字节中（比如，在‘router’选项中的一系列路由器）。选项可能只出现一次，除非在选项文档中有其他的说明。客户端将同一个选项的多个实例的值连接在一个配置使用的单参数列表中。
DHCP客户端负责所有的消息重传。客户端必须使用包含一个随机指数退避算法的重传策略，来决定两次重传之间的时间延迟。该延迟的选择应该基于客户端和服务器之间网络的特性，允许服务器的回复有充分的时间被传递。比如，在10Mb/s以太网中，第一次重传之前的延迟应该是4s被-1到1之间选择的均匀随机数随机化处理后的值。第二次重传之前的延迟应该是8s被-1到1之间选择的均匀随机数随机化处理后的值。重传延迟在接下来每一次重传中都被加倍，直至最大值64s。客户端可以提供一个重传尝试的指示给用户，作为配置过程进展的指示。
‘xid’字段被客户端用于匹配接收到的携带待定请求的DHCP消息。
通常情况下，DHCP服务器和BOOTP中继器尝试使用单播方式直接将DHCPOFFER、DHCPACK和DHCPNAK消息传递给客户端。目的IP地址在DHCP消息的‘yiaddr’字段设置，连接层目的地址在DHCP消息的‘chaddr’字段设置。然而，一些客户端实现无法在一个有效IP地址被完全配置之前接收这样的单播IP地址（这导致一个死锁，即客户端在被配置一个IP地址前无法接收IP地址）。
一个在其协议栈软件被IP地址配置前无法接收单播IP数据报的客户端，应该在其发送 的任何的DHCPDISCOVER和DHCPREQUEST消息中，设置‘flags’字段的BROADCAST位为1。BROADCAST位将会为DHCP服务器和BOOTP中继器在客户端所在子网发送向客户端的所有广播信息提供线索。而一个可以在其协议栈被设置之前接收单播IP数据包的客户端应该讲BROADCAST位清零。BOOTP说明文档讨论了这种对BROADCAST位使用的区别。
4.2 DHCP服务器管理控制
该服务器无需针对其接收的所有DHCPDISCOVER及DHCPREQUEST消息作出回应。
例如，在配置时，默认情况下该服务器将仅响应那些已通过外部机制预先配置好的客户端。
这些规则仅限于当客户端与服务器选择进行交互时所定义的行为；而所有可能涉及的系统管理控制措施则超出了该规范的适用范围。
具体来说，在实际应用中可以根据网络管理员的需求设置各种灵活多样的控制策略与参数组合。
例如，在特定环境中为指定客户机设定参数时，默认情况下该服务器将仅响应那些已通过外部机制预先配置好的客户机。
需要注意的是，在某些情况下使用‘chaddr’字段作为唯一标识符可能会引发意想不到的问题或冲突。
为了防止硬件接口迁移导致子网划分变化的问题，请尽量避免在默认情况下使用‘chaddr’字段作为唯一标志符。
此外，请确保所有DHCPOFFER消息接收方都能自由地根据自身需求选择相应的策略选项以完成分配。
4.3 DHCP服务器行为
DHCP服务器根据该客户端当前绑定的状态来处理来自该客户端的所有 DHCP 消息，能够接收的消息包括：
- DHCPDISCOVER
- DHCPREQUEST
- DHCPDECLINE
- DHCPRELEASE
- DHCPINFORM
表3列出了服务器在消息中使用的这些字段和选项。本节余下部分阐述了DHCP服务器处理所有可能接收的消息的过程。
4.3.1 DHCPDISCOVER消息
当服务器接收到来自客户端的一个DHCPDISCOVER消息时, 会根据客户端的具体需求自动分配一个合适的网络IP地址. 在没有任何可用的IP地址可供使用的情况下, 应请通知系统管理员该问题. 如果存在足够的可用IP地址供选择, 则新分配到的IP地址应遵循以下规定
从客户端绑定中获取当前连接的IP地址；
若目标地址存在于服务器的可用地址池中且未被占用，则获取前一个绑定的有效IP位置；
若目标位置的有效性良好且未被占用，则将请求源设置为'Requested IP Address'选项中的目标位置；
在源子网（当giaddr为0时）或基于转发该消息的中继节点（当giaddr不为0时）的基础上选取一个新的目标位置。
如4.2所述，在管理的目的下
- 如果未在DHCPDISCOVER消息中主动申请指定租期且已有IP地址，则服务器将返回前一次为该IP地址分配的时间片超时值；
- 若未在DHCPDISCOVER消息中主动申请指定租期且无可用IP地址，则服务器将按本地配置设定默认的时间片长度；
- 当客户端主动申请了一个指定的时间片（无论其是否已有IP资源），则服务器将根据策略决定是否采用此时间片或选择其他合适的；
表3 Fields and options used by DHCP servers
| Field | DHCPOFFER | DHCPACK | DHCPNAK |
|---|---|---|---|
| ’op’ | BOOTREPLY | BOOTREPLY | BOOTREPLY |
| ’htype’ | (From “Assigned Numbers” RFC) | ||
| ’hlen’ | (Hardware address length in octets) | ||
| ’hops’ | 0 | 0 | 0 |
| ’xid’ | ’xid’ from client DHCPDISCOVER message | ’xid’ from client DHCPDISCOVER message | ’xid’ from client DHCPDISCOVER message |
| ’secs’ | 0 | 0 | 0 |
| ’ciaddr’ | 0 | ’ciaddr’ from DHCPREQUEST or 0 | 0 |
| ’yiaddr’ | IP address offered to client | IP address assigned to client | 0 |
| ’siaddr’ | IP address of next bootstrap server | IP address of next bootstrap server | 0 |
| ’flags’ | ’flags’ from client DHCPDISCOVER message | ’flags’ from client DHCPREQUEST message | ’flags’ from client DHCPREQUEST message |
| ’giaddr’ | ’giaddr’ from client DHCPDISCOVER message | ’giaddr’ from client DHCPREQUEST message | ’giaddr’ from client DHCPREQUEST message |
| ’chaddr’ | ’chaddr’ from client DHCPDISCOVER message | ’chaddr’ from client DHCPREQUEST message | ’chaddr’ from client DHCPREQUEST message |
| ’sname’ | Server host name or options | Server host name or options | (unused) |
| ’file’ | Client boot file name or options | Client boot file name or options | (unused) |
| ’options’ | options | options | |
| 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 | MUST | MUST | MUST |
| Maximum message size | MUST NOT | MUST NOT | MUST NOT |
| All others | MAY | MAY | MUST NOT |
当网络地址及租期被指定后, 服务器将依据提供的配置参数生成DHCPOFFER消息.无论客户端选择哪台服务器, 对所有的DHCP服务器而言, 回应相同的配置参数至关重要, 以便能够预测客户机的行为.这些配置参数必须遵循如下的策略, 按照给定的顺序进行筛选.网络管理员需配置多台DHCP服务器以确保它们的一致响应.
-
网络地址的设置，在相关章节中已有详细说明。
- 超时时间的设置，在相关章节中已有详细说明。
- 客户端发送的请求参数设置，请根据以下规定执行：
-
当服务器对某一项特定配置设置了一个明确的标准预设值时，则要求服务器应在'options'字段中选择相应的选项来体现这一标准预设值。
-
当服务器将此特定配置视为Host Requirements Document所定义的一项标准配置时，则要求应在'options'字段中选择相应的选项来体现这一标准配置所附带的标准预设值。
-
为了避免因无法提供特定请求数据而导致服务中断，在未得到DHCP或BOOTP供应商扩展文档授权的情况下，默认应避免返回此类请求数据。
-
在现有的绑定项中存在与Host Requirements Document标准预设值不同的项目时，
-
由网络管理员指定的各项具体配置（如前所述），
-
由网络管理员指定的各项具体类别配置（如前述）；这些都需要通过明确匹配的方式来识别。
-
客户端子网内的各项项目均未预先设定对应的默认值。
服务器可以选择提供在DHCPOFFER消息中用于确定参数的'vendor class identifier'来协助客户端选择接收哪一个DHCPOFFER。服务器将DHCPDISCOVER消息中的'xid'字段插入到相应DHCPOFFER消息的'xid'字段中，并向请求该客户端发送相应的DHCPOFFER消息以完成配置过程。
4.3.2 DHCPREQUEST消息
DHCPREQUEST 消息源自客户端响应 DHCPOFFER 消息、验证前分配固定的 IP 地址或用于网络地址延迟租期；如果携带'server identifier'字段，则该消息为响应 DHCPOFFER 消息；客户端发送的 DHCP.REQUEST 消息如下：
-
在SELECTING状态下产生的DHCPREQUEST消息：
在"server identifier"字段中输入选定服务器的地址，在"ciaddr"字段输入0值，在"requested IP address"字段填入被选中的DHCPOFFER对应的yiaddr数值。
注意，在这种情况下客户端可以选择接收多个DHCPOFFER消息并选择最适合的一个offer。如果客户端未能接收到可接受的offer，则可以尝试重新发送DHCPDISCOVER消息。
由于服务器并未基于DHCPOFFER提交任何网络地址分配信息，在后续请求中可以根据需要自由使用已经分配好的网络地址。
然而根据具体的实现细节规定 server 应该避免重复使用已提供的网络地址，并且应当采用一种预先设定好的超时机制来决定何时可以重新使用一个已经分配过的地址。- 在INIT-REBOOT状态下产生的DHCPREQUEST消息
‘server identifier’字段必须不能被填充，‘requested IP address’选项必须被客户端之前分配的地址填充。‘ciaddr’必须为0.客户端需要验证一个之前分配的、缓存的配置。如果‘requested IP address’不正确，或者出在错误的自王忠，服务器应该发送DHCPNAK消息给客户端。
通过检测‘giaddr’的内容、’requested IP address’选项和一个数据库查询，确定处于INIT_REBOOT状态的客户端是否处于正确的网络中。如果检测到客户端处于错误网络中，服务器应该发送DHCPNAK消息给客户端。如果网络是正确的，DHCP服务器应该检查客户端IP地址的意义是否正确。如果不是，服务器应该发送DHCPNAK给客户端。如果服务器没有记录该客户端，那么它必须保持静默，并且可以发送一个警告给网络管理者。这一举动对于爆出同一线路上互相没有沟通的服务器之间保持和平共处非常必要。
如果DHCPREQUEST消息的‘giaddr’为0，那么客户端和服务器是在一个子网上的。因为客户端可能没有正确的网络地址或子网掩码，或者客户端肯无法响应ARP请求，所以服务器必须向0xffffffff广播DHCPNAK消息。
如果DHCPREQUEST消息的‘giaddr’被设置为1，客户端和服务器则在不同的子网。服务器必须设置DHCPACK消息的广播位为1，一遍中继器广播DHAPNAK给客户端，原因同上一段所述。
- 在INIT-REBOOT状态下产生的DHCPREQUEST消息
在RENEWING状态产生的DHCPREQUEST消息中：
' server identifier '字段无法填写，
' requested IP address '选项也无法填写，
' ciaddr '必须由客户端的IP地址填写。
在这种情况下，
客户端已完全配置，
并试图延长其租期。
由于消息采用单播传输，
不会有中继器参与其传输过程，
因此' giaddr '不会被填写。
DHCP服务器将信任' ciaddr '的值，
并在回复客户时将其包含进去。
客户端可以选择在其租期开始前更新或延长其租赁范围。
服务器可以选择不延长租期，
但应仍发送响应消息DHCPACK。
- 在REBINDING状态下产生的DHCPREQUEST消息：
其中'server identifier'和'requested IP address字段无法设置；必须将'ciaddr'字段填入客户端的IP地址。在这种情况下, 客户端将完成配置, 并尝试延长其租期的时间段. 该消息需发送至全网广播地址0xffffffffIP. DHCP服务器应在回复DHCPREQUEST消息前核实'ciaddr'的有效性。
4.3.3 DHCPDECLINE消息
当服务器收到一个DHCPDECLINE消息时, 表明客户端已知该网络地址已被使用。为此, 服务器应将其所在网络地址标记为不可用, 并向本地系统管理员发出警告关于这一潜在配置问题。
4.3.4 DHCPRELEASE消息
当服务器接收到 DHCPreleased 消息时，在回应后续客户的请求时
4.3.5 DHCPINFORM消息
该服务器直接向位于DHCPINFROM消息中的'ciaddr'字段指定地址的接收端发送'DHCPACK'报文以回应该消息。此外,该服务器不可传输租期超时信息至客户端,同样地,该服务器也不可填充'yesterday's address'字段。在'DHCPACK'报文中,该设备还包含了第4.3.1节所定义的其他参数信息
4.3.6 客户端消息
表4系统地阐述了各个状态下客户端的差异。
表4用于详细分析不同状态下的客户端特征。
表4全面描述了各个状态下客户端的独特性。
| INIT-REBOOT | SELECTING | RENEWING | REBINDING |
|---|---|---|---|
| broad/unicast | broadcast | broadcast | unicast |
| server-ip | MUST NOT | MUST | MUST NOT |
| requested-ip | MUST | MUST | MUST NOT |
| ciaddr | zero | zero | IP address |
4.4 DHCP客户端行为
图5展示了DHCP客户端的状态转换流程图。该客户端能够通过服务器接收一系列相关信息。
- DHCPOFFER
- DHCPACK
- DHCPNAK
未列出的DHCPINFORM消息。客户端发送了未列出的DHCPINFORM消息并等待响应。一旦客户端选择了所需参数，则完成配置流程。
表5详细列出了客户端对DHCP相关字段和选项的操作方法。
4.4.1 网络地址的初始化和分配
客户端开始于INIT状态并构造DHCPDISCOVER消息。一开始，客户端应该随机等待1到10s，以便DHCP的使用不同步。客户端设置‘ciaddr’为0x00000000。客户端可以通过包含‘parameter request list’选项来请求指定的参数，可以通过包含‘requested IP address’和’IP address lease time’选项来建议一个网络地址和/或租期事件。如果对DHCP回复消息的传递有必要，客户端必须在‘chaddr’字段包含它的硬件地址。客户端可以在’client identifier’选项包含不同的唯一标识符。如果客户端在DHCPDISCOVER消息中包含一列请求的参数，那么它在后续的所有消息中都必须包含该列表。
客户端产生和记录一个随机的事务标识符，并且将该标识符插入‘xid’字段。客户端记录自己的本地时间用于之后租期过期的计算。随后，客户端从本地硬件地址广播DHCPDISCOVER消息给0xffffffff广播IP地址和‘DHCP server’UDP端口。
如果一个到达的DHCPOFFER消息不匹配最近发送的DHCPDISCOVER消息的‘xid’字段，则该DHCPOFFER消息必须被静默丢弃。对应任何到达的DHCPACK消息必须被静默丢弃。
客户端在一定周期内收集DHCPOFFER消息，并从进来的DHCPOFFER消息选择一个（比如，可能是第一个DHCPOFFER消息，或者之前使用的服务器的DHCPOFFER消息），然后从DHCPOFFER消息的‘server identifier’选项中提取服务器地址。客户端收集消息的时间和用于选择一个DHCPOFFER消息的机制是依据实现的。
表5: Fields and options used by DHCP clients
| Field | DHCPDISCOVER DHCPINFORM | DHCPREQUEST | DHCPDECLINE,DHCPRELEASE |
|---|---|---|---|
| ’op’ | BOOTREQUEST | BOOTREQUEST | BOOTREQUEST |
| ’htype’ | (From “Assigned Numbers” RFC) | ||
| ’hlen’ | (Hardware address length in octets) | ||
| ’hops’ | 0 | 0 | 0 |
| ’xid’ | selected by client | ’xid’ from server DHCPOFFER message | selected by client |
| ’secs’ | 0 or seconds since DHCP process started | 0 or seconds since DHCP process started | 0 |
| ’flags’ | Set ’BROADCAST’ flag if client requires broadcast | Set ’BROADCAST’ 0 | Set ’BROADCAST’ flag if client requires broadcast |
| ’ciaddr’ | 0 (DHCPDISCOVER) client’s network address (DHCPINFORM) | 0 or client’s network address (BOUND/RENEW/REBIND) | 0 (DHCPDECLINE) client’s network address (DHCPRELEASE) |
| ’yiaddr’ | 0 | 0 | 0 |
| ’siaddr’ | 0 | 0 | 0 |
| ’giaddr’ | 0 | 0 | 0 |
| ’chaddr’ | client’s hardware address | client’s hardware address | client’s hardware address |
| ’sname’ | options, if indicated in ’sname/file’ option; otherwise unused | options, if indicated in ’sname/file’ option; otherwise unused | (unused) |
| ’file’ | options, if indicated in ’sname/file’ option; otherwise unused | options, if indicated in ’sname/file’ option; otherwise unused | (unused) |
| ’options’ | options | options | (unused) |
| Requested IP address | MAY (DISCOVER) MUST NOT (INFORM) | MUST (in SELECTING or INIT-REBOOT) MUST NOT (in BOUND or RENEWING) | MUST (DHCPDECLINE),MUST NOT (DHCPRELEASE) |
| IP address lease time | MAY (DISCOVER) MUST NOT (INFORM) | MAY | MUST NOT |
| Use ’file’/’sname’ fields | MAY | MAY | MAY |
| DHCP message type | DHCPDISCOVER/DHCPINFORM | DHCPREQUEST | DHCPDECLINE/DHCPRELEASE |
| Client identifier | MAY | MAY | MAY |
| Vendor class identifier | MAY | MAY | MAY |
| Server identifier | MUST NOT | MUST (after SELECTING) MUST NOT (after INIT-REBOOT, BOUND, RENEWING or REBINDING) | MUST |
| Parameter request list | MAY | MAY | MUST NOT |
| Maximum message size | MAY | MAY | MUST NOT |
| Message | SHOULD NOT | SHOULD NOT | SHOULD |
| Site-specific | MAY | MAY | MUST NOT |
| All others | MAY | MAY | MUST NOT |
当参数被确认为可接受时，在 DHCPREQUEST 广播消息的 server identifier 字段中发送该 address 信息给客户端。一旦服务器发送回 corresponding DHCPACK 消息，则客户端将进入初始状态并切换到 BOUND 状态。客户端会记录租赁期超时时间这一指标值（即初始请求发送时间和 DHCPACK 消息中租赁期时间之和）。为了确保建议 address 未被占用，请对建议 address 进行验证：例如，在支持 ARP 的网络环境中，请相关设备执行 ARP 请求以确认可用性。当为建议 address 广播一个 ARP 请求时，请目标设备在本地设备接口处设置本地设备 IP 地址并将目标设备 MAC 地址填入广播数据包中的 sender MAC 地址字段，并将本地设备 IP 地址设为 0 以便隐藏真实 IP 地址来源（hop-by-hop）。如果服务器检测到当前网络已处于使用状态，则必须向相关服务器发送 DHCPDECLINE 消息以释放当前资源并重新获取新的资源块号值（lease ID value）。最后，请相关端口执行 arp-receive 命令并在响应数据包中包含新的 IP 地址信息的同时清除过期ARP缓存项。
4.4.2 使用已知的网络地址初始化
客户端开始于INIT-REBOOT状态，并发送DHCPREQUEST消息。客户端必须将它已知的网络地址插入DHCPREQUEST消息的’requested IP address’选项。客户端可以通过包含’parameter request list’选项来请求指定的配置参数。客户端产生和记录一个随机的事务标识符，并插入该标识符到‘xid’字段。客户端记录自己的本地时间用于之后租期过期的计算。客户端不能在DHCPREQUEST消息中包含‘sever identifier’字段。客户端随后在本地硬件广播地址向‘DHCP server’UDP端口广播DHCPREQUEST消息。
一旦‘xid’字段与客户端DHCPREQUEST消息该字段相匹配的DHCPACK消息从任意服务器到达，客户端即被初始化，并跳转至BOUND状态。客户端记录租期超时时间，该时间是初始请求被发送和DHCPACK消息中租期的时间的总和。
4.4.3 使用外部分配的网络地址初始化
客户端发送DHCPINFORM消息。客户端可以通过包含’parameter request list’选项来请求指定的配置参数。客户端产生和记录一个随机的事务标识符，并插入该标识符到‘xid’字段。客户端将它自身的网络地址填充进‘ciaddr’字段。客户端不应该请求租约超时参数。
如果知道服务器的地址，客户端随后会向DHCP服务器单播DHCPINFORM消息，否则它会向该有限的广播地址广播该消息。DHCPINFORM消息必须针对‘DHCP server’UDP端口发送。
一旦一旦‘xid’字段与客户端DHCPREQUEST消息该字段相匹配的DHCPACK消息从任意服务器到达，客户端即被初始化。
如果在合理的时间周期内（60s，或者如果使用4.1所建议的超时时间，即4次尝试）客户端没有收到DHCPACK消息，那么它应该展示一个消息通知问题的用户，然后应该使用合适的默认值（依据附录A）来开始网络处理。
4.4.4 广播和单播的使用
只有当 DHCP 服务器的 IP 地址被客户端所知时，在 INIT 或 REBOOT 过程中才可发送 DHCPDISCOVER、DHCPREQUEST 和 DHCPINFORM 消息；此时客户端会单播一个 DHCP_RELEASE 消息返回给客户端自身。由于客户端拒绝接受由 DHCP 服务器提供的 IP 地址而进行配置尝试，则会通过发送一个响应断言消息来通知其所在网络。
在 INIT 态或 REBOOT 过程中且已知 DHCP 服务器 IP 地址时，则可直接向该地址发送 DHCPDISCOVER 或 DHCPREQUEST 消息而不必依赖 IP 广播；此外还可以向已知的一个 DHCP 服务器发送响应断言消息以完成配置过程。如果未能接收到针对已知 DHCP 服务器的响应断言，则将默认使用 IP 广播地址进行配置。
4.4.5 再获取和过期
客户端保维护两个时间，T1和T2，用于指定在何时客户端应尝试延迟在其网络地址上的租期。T1是客户端进入RENEWING状态，并尝试联系初始给客户端分配网络地址的服务器的时间。T2是客户端进入REBINDING状态，并尝试联系任何服务器的时间。T1必须早于T2，而T2必须早于客户端租期过期的时间。
为避免需要同步时钟，T1和T２在选项中以相对时间表达。
在T1时刻，客户端转到RENEWING状态，并发送（通过单播）衣蛾DHCPREQUEST消息给服务器来延迟它的租期。客户端设置DHCPREQUEST消息的‘ciaddr’字段为其当前网络地址。客户端记录DHCPREQUEST消息被发送的本地时间，用于计算租期超时时间。客户端不能再DHCPREQUEST消息消息中包含‘server identifier’。
任何到达的DHCPACK消息，如果其‘xid’字段和客户端DHCPREQUEST消息的‘xid’字段不匹配，都将被静默抛弃。当客户端从服务器接收到DHCPACK消息，客户端计算租期超时时间，该时间是客户端发送DHCPREQUEST消息消息加上DHCPACK消息中的租期时长 。客户端成功重新获取它的网络地址，将回到BOUND状态，并可以继续网络处理。
如果在T2时刻之前，没有DHCPACK消息到达，客户端将会转到REBINDING状态，并且发送（通过广播）DHCPREQUEST消息来延迟它的租期。客户端将其当前网络地址填充到DHCPREQUEST消息‘ciaddr’字段，并且不能再该消息中包含‘server identifier’。
时刻T1和T2被服务器通过选项配置。T1默认值为（0.5duration_of_lease）。T2默认值为（0.875duration_of_lease）。时刻T1和T2应该选择一个固定值附近随机波动后的值，来避免客户端重获取的同步问题。
客户端可以选择在T1时刻之前刷新或延迟它的租期。服务器可以选择根据网络管理员设定的策略延迟客户端的租期。服务器返回T1和T2，并且考虑到租期余下的时间，他们的值应该根据他们的原始值进行调整。
在RENEWING和REBINDING状态，如果客户端没有接收到DHCPREQUEST消息，在重传DHCPREQUEST消息之前，客户端应该等待余下一半的时间直至T2（在RENEWING状态下），或等待余下一半时间（在REBINDING状态下），直至将至最小的60s。
如果在客户端接收到DHCPACK之前租期过期，客户端会转到INIT状态，必须立即停止任何其他的网络处理，并且像尚未初始化时那样请求网络初始化参数。如果客户端接收到DHCPACK分配给他之前的网络参数，那么客户端应继续网络处理。如果客户端被给予一个新的网络地址，它不能继续使用前一个网络地址，并且应该像本地用户通知该问题。
4.4.6 DHCPRELEASE
当客户不再需要它被分配的那个网络地址（例如，在客户端正常关机的情况下），客户端将发送DHCPRELEASE消息给服务器。需要注意的是，在DHCP的操作中，并不需要等待DHCPRELEASE消息的传递过程完成才能完成相关的功能操作。