RFC2131：Dynamic Host Configuration Protocol，March 1997
本备忘录的状态
本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。
梗概
动态主机配置协议 (Dynamic Host Configuration Protocol，DHCP) 提供了一个框架，用于将配置信息传递给 TCP/IP 网络上的主机。DHCP 基于引导协议 (Bootstrap Protocol，BOOTP) [7]，增加了自动分配可重用网络地址和附加配置选项的能力 [19]。DHCP 捕获 BOOTP 中继代理的行为 [7, 21]，并且 DHCP 参与者可以与 BOOTP 参与者进行互操作 [9]。
1、 简介
动态主机配置协议 (DHCP) 为 Internet 主机提供配置参数。DHCP 由两部分组成：用于将特定于主机的配置参数从 DHCP 服务器传送到主机的协议和用于为主机分配网络地址的机制。
DHCP 建立在客户端/服务器（C/S）模型上，其中指定的 DHCP 服务器主机分配网络地址并将配置参数传递给动态配置的主机。在本文档的其余部分，术语“服务器/server”是指通过 DHCP 提供初始化参数的主机，而术语“客户端/client”是指从 DHCP 服务器请求初始化参数的主机。
除非系统管理员明确配置，否则主机不应充当 DHCP 服务器。如果允许随机主机响应 DHCP 请求，则 Internet 中硬件和协议实现的多样性将妨碍可靠操作。例如，IP 需要在协议实现软件中设置许多参数。由于 IP 可用于许多不同类型的网络硬件，因此无法猜测或假定这些参数的值具有正确的默认值。此外，分布式地址分配方案依赖于用于发现已在使用的地址的轮询/防御机制。IP 主机可能无法始终保护自己的网络地址，因此这种分布式地址分配方案无法保证避免分配重复的网络地址。
DHCP 支持三种 IP 地址分配机制。在“自动分配/automatic allocation”中，DHCP 为客户端分配一个永久的 IP 地址。在“动态分配/dynamic allocation”中，DHCP 会在有限的时间段内（或直到客户端明确放弃该地址）为客户端分配 IP 地址。在“手动分配/manual allocation”中，客户端的 IP 地址由网络管理员分配，DHCP 仅用于将分配的地址传送给客户端。特定网络将使用一种或多种这些机制，具体取决于网络管理员的策略。
动态分配是三种机制中唯一一种允许自动重用分配给它的客户端不再需要的地址。因此，动态分配对于将地址分配给仅临时连接到网络的客户端或用于在不需要永久 IP 地址的一组客户端之间共享有限的 IP 地址池特别有用。动态分配也可能是将 IP 地址分配给永久连接到 IP 地址非常稀缺的网络的新客户端的不错选择，因此在旧客户端离开时回收它们很重要。手动分配允许使用 DHCP 来消除在需要（出于任何原因）在 DHCP 机制之外管理 IP 地址分配的环境中，手动配置具有 IP 地址的主机的容易出错的过程。
DHCP 消息的格式基于 BOOTP 消息的格式，以捕获作为 BOOTP 规范 [7, 21] 一部分描述的 BOOTP 中继代理行为，并允许现有 BOOTP 客户端与 DHCP 服务器的互操作性。使用 BOOTP 中继代理消除了在每个物理网段上都有 DHCP 服务器的必要性。
1.1、 对 RFC 1541 的更改
本文档更新了出现在 RFC1541 中的 DHCP 协议规范。添加了新的 DHCP 消息类型 DHCPINFORM；详见 3.4、4.3 和 4.4 节。用于向 DHCP 服务器识别 DHCP 客户端的分类机制已扩展为包括第 4.2 和 4.3 节中定义的“厂商/vendor”类。已删除最短租用时间限制。最后，由于在 DHCP 互操作性测试中获得的经验，对文本进行了许多编辑更改以澄清文本。
1.2、 相关工作
有几种 Internet 协议和相关机制可以解决动态主机配置问题的某些部分。反向地址解析协议 (Reverse Address Resolution Protocol，RARP) [10]（通过动态 RARP (Dynamic RARP，DRARP) [5] 中定义的扩展）明确解决了网络地址发现问题，并包括自动 IP 地址分配机制。简单文件传输协议 (Trivial File Transfer Protocol，TFTP) [20] 提供从引导服务器传输引导映像。 Internet 控制消息协议 (Internet Control Message Protocol，ICMP) [16] 提供通过“ICMP 重定向”消息通知主机附加路由器。ICMP还可以通过“ICMP掩码请求”消息提供子网掩码信息，通过（过时的）“ICMP信息请求”消息提供其他信息。主机可以通过 ICMP 路由器发现机制来定位路由器 [8]。
BOOTP 是一种用于收集配置信息的传输机制。BOOTP 也是可扩展的，官方扩展 [17] 已经定义了几个配置参数。Morgan 已提议扩展 BOOTP 以实现动态 IP 地址分配 [15]。麻省理工学院 Athena 项目使用的网络信息协议 (Network Information Protocol，NIP) 是一种用于动态 IP 地址分配的分布式机制 [19]。资源定位协议（Resource Location Protocol，RLP）[1] 提供更高级别服务的定位。Sun Microsystems 无盘工作站使用引导程序，该程序采用 RARP、TFTP 和称为“bootparams”的 RPC 机制将配置信息和操作系统代码传送到无盘主机。（Sun Microsystems、Sun Workstation 和 SunOS 是 Sun Microsystems, Inc. 的商标）某些 Sun 网络还使用 DRARP 和自动安装机制来自动配置现有网络中的新主机。
在其他相关工作中，路径最小传输单元（minimum transmission unit，MTU）发现算法可以确定任意互联网路径的 MTU [14]。地址解析协议 (Address Resolution Protocol，ARP) 已被提议作为用于资源定位和选择的传输协议 [6]。最后，主机要求 RFC [3, 4] 提到了主机重新配置的具体要求，并建议了无盘主机的初始配置方案。
1.3、 问题定义和说明
DHCP 旨在为 DHCP 客户端提供主机要求 RFC 中定义的配置参数。通过 DHCP 获取参数后，DHCP 客户端应该能够与 Internet 上的任何其他主机交换数据包。DHCP 提供的 TCP/IP 堆栈参数在附录 A 中列出。
对于新初始化的客户端，并非所有这些参数都是必需的。客户端和服务器可以协商仅传输客户端所需的或特定于特定子网的那些参数。
DHCP 允许但不需要配置与 IP 协议没有直接关系的客户端参数。DHCP 也不解决新配置的客户端向域名系统 (Domain Name System，DNS) [12, 13] 的注册问题。
DHCP 不适用于配置路由器。
1.4、 要求
在本文档中，用于定义特定要求重要性的词语大写。这些话是：
“必须/MUST”
这个词或形容词“REQUIRED”表示该项目是本规范的绝对要求。
“禁止/MUST NOT”
这句话的意思是该项目是本规范的绝对禁止。
“应该/SHOULD”
这个词或形容词“推荐/RECOMMENDED”的意思是在特定情况下可能存在合理的理由来忽略这个项目，但在选择不同的课程之前应该理解全部含义并仔细权衡案例。
“不应该/SHOULD NOT”
这句话意味着在特定情况下，当列出的行为可接受甚至有用时，可能存在正当理由，但在实施此标签描述的任何行为之前，应了解全部含义并仔细权衡案例。
“可能/MAY”
这个词或形容词“OPTIONAL”意味着这个项目是真正可选的。例如，一个厂商可能会选择包含该项目，因为特定市场需要它或因为它增强了产品；另一个厂商可能会省略相同的项目。
1.5、 术语
本文档使用以下术语：
“DHCP 客户端”
DHCP 客户端是使用 DHCP 获取网络地址等配置参数的 Internet 主机。
“DHCP 服务器”
DHCP 服务器是将配置参数返回给 DHCP 客户端的 Internet 主机。
“BOOTP 中继代理”
BOOTP 中继代理或中继代理是在 DHCP 客户端和 DHCP 服务器之间传递 DHCP 消息的 Internet 主机或路由器。DHCP 旨在使用与 BOOTP 协议规范中指定的相同的中继代理行为。
“绑定/binding”
绑定是一组配置参数，至少包括一个 IP 地址，与 DHCP 客户端关联或“绑定到”DHCP 客户端。绑定由 DHCP 服务器管理。
1.6、 设计目标
以下列表给出了 DHCP 的一般设计目标。
** DHCP 应该是一种机制而不是一种策略。DHCP 必须允许本地系统管理员在需要时控制配置参数；例如，本地系统管理员应该能够在需要时执行有关分配和访问本地资源的本地策略。
** 客户端不需要手动配置。每个客户端都应该能够在没有用户干预的情况下发现适当的本地配置参数，并将这些参数合并到自己的配置中。
** 网络不需要为单个客户端手动配置。在正常情况下，网络管理员不必输入任何每个客户端的配置参数。
** DHCP 不应要求每个子网上都有服务器。为了实现规模和经济，DHCP 必须跨路由器或通过 BOOTP 中继代理的干预工作。
** DHCP 客户端必须准备好接收对配置参数请求的多个响应。某些安装可能包括多个重叠的 DHCP 服务器，以增强可靠性并提高性能。
** DHCP 必须与静态配置的非参与主机和现有网络协议实现共存。
** DHCP 必须与 RFC 951 和 RFC 1542 [21] 描述的 BOOTP 中继代理行为互操作。
** DHCP 必须为现有的 BOOTP 客户端提供服务。
以下列表给出了特定于网络层参数传输的设计目标。DHCP 必须：
** 保证任何特定网络地址不会同时被多个 DHCP 客户端使用，
** 在 DHCP 客户端重新启动后保留 DHCP 客户端配置。应尽可能为 DHCP 客户端分配相同的配置参数（例如，网络地址）以响应每个请求，
** 在服务器重新启动时保留 DHCP 客户端配置，并且只要有可能，尽管 DHCP 机制重新启动，DHCP 客户端仍应分配相同的配置参数，
** 允许将配置参数自动分配给新客户端，以避免为新客户端手动配置，
** 支持将配置参数固定或永久分配给特定客户端。
2、 协议概要
从客户端的角度来看，DHCP 是 BOOTP 机制的扩展。此行为允许现有 BOOTP 客户端与 DHCP 服务器互操作，而无需对客户端的初始化软件进行任何更改。RFC 1542 [2] 详细说明了 BOOTP 和 DHCP 客户端和服务器 [9] 之间的交互。有一些新的、可选的事务可以优化 DHCP 客户端和服务器之间的交互，这些在第 3 节和第 4 节中进行了描述。
图 1 给出了 DHCP 消息的格式，表 1 描述了 DHCP 消息中的每个字段。括号中的数字表示以八位字节表示的每个字段的大小。图中给出的字段名称将在整个文档中用于指代 DHCP 消息中的字段。
DHCP 和 BOOTP 之间有两个主要区别。首先，DHCP 定义了一种机制，通过该机制可以为客户端分配有限租用的网络地址，从而允许将网络地址连续重新分配给不同的客户端。其次，DHCP 为客户端提供了获取其运行所需的所有 IP 配置参数的机制。
DHCP 在术语中引入了一个小的变化，旨在阐明其中一个字段的含义。BOOTP 中的“厂商扩展/vendor extensions”字段已被重命名为 DHCP 中的“选项/options”字段。类似地，在 BOOTP“厂商扩展/vendor extensions”字段中使用的标记数据项（以前称为“厂商扩展”）现在简称为“选项”。
图 1：DHCP 消息的格式
DHCP 定义了一个新的“客户端标识符”选项，用于将显式客户端标识符传递给 DHCP 服务器。此更改消除了 BOOTP 消息中“chaddr”字段的过载，其中“chaddr”既用作传输 BOOTP 回复消息的硬件地址，也用作客户端标识符。“客户端标识符”是一个不透明的值，不会被服务器解释；例如，“客户端标识符”可能包含一个硬件地址，与“chaddr”字段的内容相同，或者它可能包含另一种类型的标识符，例如 DNS 名称。DHCP 客户端选择的“客户端标识符”对于该客户端所连接的子网中的该客户端必须是唯一的。如果客户端在一个消息中使用“客户端标识符”，它必须在所有后续消息中使用相同的标识符，以确保所有服务器正确识别客户端。
DHCP 阐明了“siaddr”字段的解释，即在客户端引导过程的下一步中使用的服务器地址。如果 DHCP 服务器准备提供下一个引导服务（例如，操作系统可执行映像的交付），则 DHCP 服务器可以在“siaddr”字段中返回其自己的地址。DHCP 服务器总是在“服务器标识符”选项中返回它自己的地址。
表 1：DHCP 消息中的字段说明
“options” 字段现在是可变长度的。DHCP 客户端必须准备好接收带有至少 312 个八位字节长度的“选项”字段的 DHCP 消息。此要求意味着 DHCP 客户端必须准备好接收最多 576 个八位字节的消息，这是 IP 主机必须准备接受的最小 IP 数据报大小 [3]。DHCP 客户端可以通过“最大 DHCP 消息大小”选项协商使用更大的 DHCP 消息。选项字段可以进一步扩展到“file”和“sname”字段。
在客户端使用 DHCP 进行初始配置的情况下（在客户端的 TCP/IP 软件完全配置之前），DHCP 要求创造性地使用客户端的 TCP/IP 软件和对 RFC 1122 的自由解释。TCP/IP 软件应该接受并将IP地址配置之前交付给客户端硬件地址的任何IP数据包转发到IP层；在配置 TCP/IP 软件之前，DHCP 服务器和 BOOTP 中继代理可能无法将 DHCP 消息传递给无法接受硬件单播数据报的客户端。
为了解决一些在 TCP/IP 软件配置之前无法接受 IP 单播数据报的客户端，DHCP 使用了“flags”字段 [21]。最左边的位定义为 BROADCAST (B) 标志。此标志的语义在本文档的第 4.1 节中讨论。标志字段的其余位保留供将来使用。它们必须由客户端设置为零，并被服务器和中继代理忽略。图 2 给出了“标志”字段的格式。
图 2：“flags” 字段的格式
B：广播标志 MBZ：必须为零（保留以备将来使用）
2.1、 配置参数仓库
DHCP 提供的第一个服务是为网络客户端提供网络参数的持久存储。DHCP 持久化存储的模型是 DHCP 服务为每个客户端存储一个 key-value 条目，其中 key 是某个唯一标识符（例如，IP 子网编号和子网内的唯一标识符），该值包含配置客户端的参数。
例如，密钥可能是一对（IP-子网号，硬件地址）（注意，“硬件地址”应该按硬件类型输入，以适应位序问题导致的硬件地址可能重复在混合媒体、桥接网络中）允许在不同子网上串行或并发重用硬件地址，以及可能不是全局唯一的硬件地址。或者，密钥可能是这对（IP-子网号、主机名），允许服务器智能地将参数分配给已移动到不同子网或已更改硬件地址的 DHCP 客户端（可能是因为网络接口故障和被取代）。除非客户端使用“客户端标识符”选项明确提供标识符，否则该协议定义密钥将是（IP 子网号、硬件地址）。客户端可以查询 DHCP 服务以检索其配置参数。配置参数存储库的客户端接口由用于请求配置参数的协议消息和来自携带配置参数的服务器的响应组成。
2.2、 网络地址的动态分配
DHCP 提供的第二项服务是为客户端分配临时或永久网络 (IP) 地址。网络地址动态分配的基本机制很简单：客户端请求使用某个地址一段时间。分配机制（DHCP 服务器的集合）保证不会在请求的时间内重新分配该地址，并在每次客户端请求地址时尝试返回相同的网络地址。在本文档中，将网络地址分配给客户端的时间段称为“租期/lease”[11]。客户端可以通过后续请求延长其租期。当客户端不再需要该地址时，客户端可以发布消息将地址释放回服务器。客户可以通过要求无限租用来要求永久分配。即使在分配“永久/permanent”地址时，服务器也可以选择给出冗长但非无限的租约，以允许检测客户端已离开的事实。
在某些环境中，由于可用地址耗尽，需要重新分配网络地址。在这种环境中，分配机制将重用租期已到期的地址。服务器应使用配置信息存储库中可用的任何信息来选择要重用的地址。例如，服务器可以选择最近最少分配的地址。作为一致性检查，分配服务器应该在分配地址之前探测重用的地址，例如，使用 ICMP 回显请求，客户端应该探测新接收的地址，例如，使用 ARP。
3、 客户端-服务器协议
DHCP 使用 RFC 951 中定义并在表 1 和图 1 中给出的 BOOTP 消息格式。从客户端发送到服务器的每个 DHCP 消息的“op”字段包含 BOOTREQUEST。BOOTREPLY 用于从服务器发送到客户端的每个 DHCP 消息的“op”字段。
DHCP 消息的“options”字段的前四个八位字节分别包含（十进制）值 99、130、83 和 99（这与 RFC 1497 [17] 中定义的魔法 cookie 相同）。“options” 字段的其余部分由称为“选项”的标记参数列表组成。RFC 1497 中列出的所有“厂商扩展”也是 DHCP 选项。RFC 1533 提供了为与 DHCP 一起使用而定义的完整选项集。
到目前为止已经定义了几个选项。每个 DHCP 消息中必须包含一个特定选项——“DHCP 消息类型”选项。此选项定义 DHCP 消息的“type”。根据 DHCP 消息类型，可能允许、需要或不允许其他选项。
在本文档中，包含“DHCP 消息类型”选项的 DHCP 消息将通过消息类型来引用；例如，具有“DHCP 消息类型”选项类型 1 的 DHCP 消息将被称为“DHCPDISCOVER”消息。
3.1、 客户端-服务器交互——分配网络地址
以下客户端和服务器之间协议交换的摘要参考了表 2 中描述的 DHCP 消息。图 3 中的时间线图显示了典型客户端-服务器交互中的时序关系。如果客户端已经知道它的地址，可以省略一些步骤；这种简短的交互在第 3.2 节中进行了描述。
1. 客户端在其本地物理子网上广播 DHCPDISCOVER 消息。 DHCPDISCOVER 消息可以包括建议网络地址和租用期限值的选项。BOOTP 中继代理可能会将消息传递到不在同一物理子网上的 DHCP 服务器。
2. 每个服务器都可以使用 DHCPOFFER 消息进行响应，该消息在“yiaddr”字段中包含可用网络地址（以及 DHCP 选项中的其他配置参数）。服务器不需要保留提供的网络地址，尽管如果服务器避免将提供的网络地址分配给另一个客户端，协议将更有效地工作。当分配一个新地址时，服务器应该检查提供的网络地址是否已经被使用；例如，服务器可以使用 ICMP Echo Request 探测提供的地址。服务器应该被实现，以便网络管理员可以选择禁用对新分配地址的探测。服务器将 DHCPOFFER 消息传输到客户端，必要时使用 BOOTP 中继代理。
表 2：DHCP 消息
图 3：分配新网络地址时 DHCP 客户端和服务器之间交换的消息的时间线图
3. 客户端从一台或多台服务器接收一个或多个 DHCPOFFER 消息。客户端可以选择等待多个响应。客户端根据 DHCPOFFER 消息中提供的配置参数，选择一台服务器来请求配置参数。客户端广播一个 DHCPREQUEST 消息，该消息必须包括“服务器标识符”选项以指示它选择了哪个服务器，并且可以包括指定所需配置值的其他选项。“requested IP address” 选项必须设置为来自服务器的 DHCPOFFER 消息中的 “yiaddr” 值。此 DHCPREQUEST 消息通过 DHCP/BOOTP 中继代理进行广播和中继。为了帮助确保任何 BOOTP 中继代理将 DHCPREQUEST 消息转发到接收原始 DHCPDISCOVER 消息的同一组 DHCP 服务器，DHCPREQUEST 消息必须在 DHCP 消息头的“secs”字段中使用相同的值并发送到相同的 IP广播地址作为原始 DHCPDISCOVER 消息。如果客户端没有收到 DHCPOFFER 消息，则客户端超时并重新传输 DHCPDISCOVER 消息。
4. 服务器接收来自客户端的 DHCPREQUEST 广播。 DHCPREQUEST 消息未选择的那些服务器使用该消息作为客户端拒绝该服务器提供的通知。在 DHCPREQUEST 消息中选择的服务器将客户端的绑定提交到持久存储，并使用包含请求客户端的配置参数的 DHCPACK 消息进行响应。“客户端标识符”或“chaddr”与分配的网络地址的组合构成了客户端租用的唯一标识符，客户端和服务器都使用它来标识任何 DHCP 消息中引用的租用。DHCPACK 消息中的任何配置参数不应与客户端正在响应的较早 DHCPOFFER 消息中的配置参数冲突。服务器此时不应检查提供的网络地址。DHCPACK 消息中的“yiaddr”字段用选定的网络地址填充。
如果选择的服务器不能满足 DHCPREQUEST 消息（例如，请求的网络地址已被分配），服务器应该响应 DHCPNAK 消息。
服务器可以选择将 DHCPOFFER 消息中提供给客户端的地址标记为不可用。如果服务器没有收到来自客户端的 DHCPREQUEST 消息，则服务器应该在 DHCPOFFER 消息中将提供给客户端的地址标记为可用。
5. 客户端收到带有配置参数的 DHCPACK 消息。客户端应该对参数（例如，分配的网络地址的 ARP）执行最终检查，并记录 DHCPACK 消息中指定的租用期限。至此，客户端配置完毕。如果客户端检测到地址已被使用（例如，通过使用 ARP），则客户端必须向服务器发送 DHCPDECLINE 消息并重新启动配置过程。客户端应该在重新启动配置过程之前等待至少十秒钟，以避免在循环的情况下过多的网络流量。
如果客户端收到 DHCPNAK 消息，则客户端重新启动配置过程。
如果客户端未收到 DHCPACK 或 DHCPNAK 消息，则客户端超时并重新传输 DHCPREQUEST 消息。客户端根据4.1节的重传算法重传DHCPREQUEST。客户端应该选择重传 DHCPREQUEST 足够的次数，以提供足够的可能性联系服务器，而不会导致客户端（和该客户端的用户）在放弃之前等待太久；例如，在 4.1 节中描述的重新传输的客户端可能会在重新启动初始化过程之前重新传输 DHCPREQUEST 消息四次，总共延迟 60 秒。如果客户端在使用重传算法后既没有收到DHCPACK 也没有收到DHCPNAK 消息，则返回INIT 状态并重新开始初始化过程。客户端应该通知用户初始化过程失败并正在重新启动。
6. 客户端可以通过向服务器发送 DHCPRELEASE 消息来选择放弃对网络地址的租用。客户端使用其“客户端标识符”或 DHCPRELEASE 消息中的“chaddr”和网络地址来标识要释放的租约。如果客户端在获得租用时使用了“客户端标识符”，则它必须在 DHCPRELEASE 消息中使用相同的“客户端标识符”。
3.2、 客户端-服务器交互——重用之前分配的网络地址
如果客户端记住并希望重用先前分配的网络地址，则客户端可以选择省略上一节中描述的某些步骤。图 4 中的时间线图显示了客户端重用先前分配的网络地址的典型客户端-服务器交互中的时序关系。
1. 客户端在其本地子网上广播 DHCPREQUEST 消息。该消息在“请求的 IP 地址”选项中包含客户端的网络地址。由于客户端尚未收到其网络地址，因此它不得填写“ciaddr”字段。BOOTP 中继代理将消息传递到不在同一子网上的 DHCP 服务器。如果客户端使用“客户端标识符”来获取其地址，则客户端必须在 DHCPREQUEST 消息中使用相同的“客户端标识符”。
2. 知道客户端配置参数的服务器向客户端响应 DHCPACK 消息。 服务器不应该检查客户端的网络地址是否已经被使用；此时客户端可能会响应 ICMP Echo Request 消息。
图 4：重用先前分配的网络地址时 DHCP 客户端和服务器之间交换的消息的时间线图
如果客户端的请求无效（例如，客户端已移动到新的子网），服务器应该向客户端响应 DHCPNAK 消息。如果不能保证其信息准确无误，则服务器不应响应。例如，一个服务器识别另一个服务器拥有的过期绑定请求，除非服务器使用显式机制来维护服务器之间的一致性，否则不应该用 DHCPNAK 响应。
如果 DHCPREQUEST 消息中的 “giaddr” 为 0x0，则客户端与服务器位于同一子网上。服务器必须向 0xffffffff 广播地址广播 DHCPNAK 消息，因为客户端可能没有正确的网络地址或子网掩码，并且客户端可能没有响应 ARP 请求。否则，服务器必须将 DHCPNAK 消息发送到 BOOTP 中继代理的 IP 地址，如“giaddr”中记录的那样。继而，中继代理会将消息直接转发到客户端的硬件地址，这样即使客户端移动到新网络，也可以传递 DHCPNAK。
3. 客户端收到带有配置参数的 DHCPACK 消息。客户端对参数执行最终检查（如第 3.1 节所述），并记录 DHCPACK 消息中指定的租用期限。特定租用由“客户端标识符”或“chaddr”和网络地址隐式标识。至此，客户端配置完毕。
如果客户端检测到 DHCPACK 消息中的 IP 地址已被使用，则客户端必须向服务器发送 DHCPDECLINE 消息并通过请求新的网络地址重新启动配置过程。此操作对应于客户端在 DHCP 状态图中移动到 INIT 状态，这在 4.4 节中进行了描述。
如果客户端收到一个 DHCPNAK 消息，它就不能重用它记住的网络地址。它必须通过重新启动配置过程来请求一个新地址，这次使用第 3.1 节中描述的（非缩写）过程。此操作也对应于客户端在 DHCP 状态图中移动到 INIT 状态。
如果客户端既没有收到 DHCPACK 也没有收到 DHCPNAK 消息，则客户端超时并重新传输 DHCPREQUEST 消息。客户端根据4.1节的重传算法重传DHCPREQUEST。客户端应该选择重传 DHCPREQUEST 足够的次数，以提供足够的可能性联系服务器，而不会导致客户端（和该客户端的用户）在放弃之前等待太久；例如，在 4.1 节中描述的重新传输的客户端可能会在重新启动初始化过程之前重新传输 DHCPREQUEST 消息四次，总共延迟 60 秒。如果客户端在使用重传算法后既没有收到 DHCPACK 消息也没有收到 DHCPNAK 消息，则客户端可以选择使用之前分配的网络地址和配置参数用于未到期租用的剩余部分。这对应于在图 5 所示的客户端状态转换图中移动到 BOUND 状态。
4. 客户端可以通过向服务器发送 DHCPRELEASE 消息来选择放弃对网络地址的租用。客户端使用其“客户端标识符”或 DHCPRELEASE 消息中的“chaddr”和网络地址来标识要释放的租约。
请注意，在这种情况下，客户端在本地保留其网络地址，客户端通常不会在正常关闭期间放弃其租用。只有在客户端明确需要放弃其租约的情况下，例如，客户端将被移动到不同的子网，客户端才会发送 DHCPRELEASE 消息。
3.3、 时间值的解释和表示
客户端在固定的时间段（可能是无限的）内获得网络地址的租约。在整个协议中，时间以秒为单位表示。0xffffffff 的时间值被保留用来表示“无穷大”。
由于客户端和服务器可能没有同步时钟，时间在 DHCP 消息中表示为相对时间，以相对于客户端的本地时钟进行解释。在无符号 32 位字中以秒为单位表示相对时间给出了从 0 到大约 100 年的相对时间范围，这足以使用 DHCP 测量相对时间。
上一段中给出的租用期限解释算法假设客户端和服务器时钟相对于彼此是稳定的。如果两个时钟之间存在偏差，服务器可能会在客户端之前认为租用已过期。作为补偿，服务器可以向客户端返回比服务器提交给其本地客户端信息数据库更短的租用期限。
3.4、 获取外部配置网络地址的参数
如果客户端通过某种其他方式（例如，手动配置）获得了网络地址，则它可以使用 DHCPINFORM 请求消息来获取其他本地配置参数。接收 DHCPINFORM 消息的服务器使用适合客户端的任何本地配置参数构造 DHCPACK 消息，而无需分配新地址、检查现有绑定、填写“yiaddr”或包括租用时间参数。服务器应该将 DHCPACK 回复单播到 DHCPINFORM 消息的“ciaddr”字段中给出的地址。
服务器应该检查 DHCPINFORM 消息中的网络地址的一致性，但不能检查现有的租约。服务器形成包含请求客户端的配置参数的 DHCPACK 消息，并将 DHCPACK 消息直接发送到客户端。
3.5、 DHCP客户端参数
并非所有客户端都需要对附录 A 中列出的所有参数进行初始化。使用两种技术来减少从服务器传输到客户端的参数数量。首先，大多数参数在主机要求 RFC 中定义了默认值；如果客户端没有从服务器接收到覆盖默认值的参数，则客户端使用这些默认值。其次，在其初始 DHCPDISCOVER 或 DHCPREQUEST 消息中，客户端可以向服务器提供客户端感兴趣的特定参数列表。如果客户端在 DHCPDISCOVER 消息中包含参数列表，则它必须在任何后续 DHCPREQUEST 中包含该列表消息。
客户端应该包括“最大 DHCP 消息大小”选项，让服务器知道服务器可以制作多大的 DHCP 消息。返回给客户端的参数可能仍然超过分配给 DHCP 消息中选项的空间。在这种情况下，两个额外的选项标志（必须出现在消息的 “options” 字段中）表明 “file” 和 “sname” 字段将用于选项。
客户端可以通过包含“参数请求列表”选项来通知服务器客户端感兴趣的配置参数。此选项的数据部分明确列出了标签号请求的选项。
此外，客户端可以在 DHCPDISCOVER 消息中建议网络地址和租用时间的值。客户端可以包括“请求的IP地址”选项来建议分配特定的IP地址，并且可以包括“IP地址租用时间”选项来建议它想要的租用时间。在 DHCPDISCOVER 或 DHCPREQUEST 消息中允许在配置参数中表示“hints”的其他选项。但是，服务器可能会忽略其他选项，因此多个服务器可能不会为某些选项返回相同的值。“requested IP address” 选项仅在客户端验证先前获得的网络参数时填写在 DHCPREQUEST 消息中。仅当正确配置了处于 BOUND、RENEWING 或 REBINDING 状态的 IP 地址时，客户端才会填写“ciaddr”字段。
如果服务器收到带有无效“请求的 IP 地址”的 DHCPREQUEST 消息，服务器应该用 DHCPNAK 消息响应客户端，并可以选择向系统管理员报告问题。服务器可能会在“message”选项中包含错误消息。
3.6、 在具有多个接口的客户端中使用 DHCP
具有多个网络接口的客户端必须通过每个接口独立使用 DHCP 来获取这些单独接口的配置信息参数。
3.7、 客户端什么时候应该使用 DHCP
每当本地网络参数可能发生变化时，客户端应该使用 DHCP 重新获取或验证其 IP 地址和网络参数；例如，在系统启动时或与本地网络断开连接后，因为本地网络配置可能会在客户端或用户不知情的情况下发生变化。
如果客户端知道先前的网络地址并且无法联系本地 DHCP 服务器，则客户端可能会继续使用先前的网络地址，直到该地址的租用期到期。如果租用期在客户端可以联系 DHCP 服务器之前到期，则客户端必须立即停止使用先前的网络地址，并且可能会将问题通知本地用户。
4、 DHCP 客户端-服务器协议规范
在本节中，我们假设 DHCP 服务器有一个网络地址块，它可以从中满足对新地址的请求。每个服务器还在本地永久存储中维护分配地址和租用的数据库。
4.1、 构造和发送DHCP报文
DHCP 客户端和服务器都通过在消息的固定格式部分填充字段并在可变长度选项区域中附加标记数据项来构建 DHCP 消息。选项区域首先包括一个四个八位字节的“magic cookie”（在第 3 节中进行了描述），然后是选项。最后一个选项必须始终是 “end” 选项。
DHCP 使用 UDP 作为其传输协议。从客户端到服务器的 DHCP 消息被发送到“DHCP 服务器”端口 (67)，而从服务器到客户端的 DHCP 消息被发送到“DHCP 客户端”端口 (68)。具有多个网络地址的服务器（例如，多宿主主机）可以在传出的 DHCP 消息中使用其任何网络地址。
“服务器标识符”字段既用于标识 DHCP 消息中的 DHCP 服务器，也用作从客户端到服务器的目标地址。具有多个网络地址的服务器必须准备好接受其任何网络地址作为在 DHCP 消息中标识该服务器的能力。为了适应可能不完整的网络连接，服务器必须选择一个地址作为“服务器标识符”，据服务器所知，该地址可从客户端访问。例如，如果 DHCP 服务器和 DHCP 客户端连接到同一个子网（即，来自客户端的消息中的 “giaddr” 字段为零），服务器应该选择服务器用于通信的 IP 地址。子网作为“服务器标识符”。如果服务器在该子网上使用多个 IP 地址，则可以使用任何此类地址。如果服务器已经通过 DHCP 中继代理接收到消息，服务器应该从接收消息的接口中选择一个地址作为“服务器标识符”（除非服务器有其他更好的信息来做出选择）。DHCP 客户端必须将“服务器标识符”选项中提供的 IP 地址用于对 DHCP 服务器的任何单播请求。
客户端在获取其 IP 地址之前广播的 DHCP 消息必须将 IP 标头中的源地址字段设置为 0。
如果来自客户端的 DHCP 消息中的“giaddr”字段不为零，则服务器将任何返回消息发送到地址出现在“giaddr”中的 BOOTP 中继代理上的“DHCP 服务器”端口。如果“giaddr”字段为零且“ciaddr”字段不为零，则服务器将 DHCPOFFER 和 DHCPACK 消息单播到“ciaddr”中的地址。如果“giaddr”为零且“ciaddr”为零，并且设置了广播位，则服务器将 DHCPOFFER 和 DHCPACK 消息广播到 0xffffffff。如果广播位未设置且“giaddr”为零且“ciaddr”为零，则服务器将 DHCPOFFER 和 DHCPACK 消息单播到客户端的硬件地址和“yiaddr”地址。在所有情况下，当“giaddr”为零时，服务器将向 0xffffffff 广播任何 DHCPNAK 消息。
如果 DHCP 消息中的选项扩展到 “sname” 和 “file” 字段，则 “optionoverload” 选项必须出现在 “options” 字段中，值为 1、2 或 3，如 RFC 1533 中所指定。“option overload”选项出现在“options”字段中，“options”字段中的选项必须以“end”选项终止，并且可以包含一个或多个“pad”选项来填充选项字段。“sname” 和 “file” 字段中的选项（如果按照 “options overload” 选项指示使用）必须以该字段的第一个八位字节开始，必须以一个 “end” 选项结束，并且必须在其后通过 “pad” 选项来填充字段的其余部分。“options”、“sname” 和 “file” 字段中的任何单个选项都必须完全包含在该字段中。“options” 字段中的选项必须首先被解释，以便可以解释任何“options overload”选项。接下来必须解释“文件”字段（如果“options overload”选项指示“file”字段包含 DHCP 选项），然后是“sname”字段。
要在“option”标签中传递的值可能太长而无法放入单个选项可用的 255 个八位字节（例如，“路由器”选项中的路由器列表 [21]）。除非在选项文档中另有规定，否则选项只能出现一次。客户端将同一选项的多个实例的值连接到一个用于配置的参数列表中。
DHCP 客户端负责所有的消息重传。客户端必须采用包含随机指数退避算法的重传策略来确定重传之间的延迟。应该选择重传之间的延迟，以便根据客户端和服务器之间的网络特性，为来自服务器的回复提供足够的时间。例如，在一个 10Mb/sec 的以太网互联网络中，第一次重传之前的延迟应该是 4 秒，由从 -1 到 +1 范围内选择的统一随机数的值随机化。具有提供小于一秒分辨率粒度的时钟的客户端可以选择非整数随机化值。下一次重传之前的延迟应该是 8 秒，由从 -1 到 +1 范围内选择的统一数字的值随机化。重传延迟应该加倍，随后的重传最多可达 64 秒。客户端可以向用户提供重传尝试的指示，作为配置过程进度的指示。
客户端使用“xid”字段将传入的 DHCP 消息与未决请求进行匹配。DHCP 客户端必须以这样一种方式选择 “xid”，以尽量减少使用与另一个客户端使用的 “xid” 相同的 “xid” 的机会。例如，每次重新启动客户端时，客户端可能会选择不同的随机初始“xid”，然后在下次重新启动之前使用连续的“xid”。为每次重传选择一个新的“xid”是一个实现决策。客户端可以选择重用相同的“xid”或为每个重传的消息选择一个新的“xid”。
通常，DHCP 服务器和 BOOTP 中继代理尝试使用单播传递将 DHCPOFFER、DHCPACK 和 DHCPNAK 消息直接传递给客户端。IP 目标地址（在 IP 标头中）设置为 DHCP “yiaddr” 地址，链路层目标地址设置为 DHCP “chaddr” 地址。不幸的是，一些客户端实现无法接收这样的单播 IP 数据报，直到实现配置了有效的 IP 地址（导致死锁，在客户端配置了 IP 地址之前无法传递客户端的 IP 地址）。
在客户端发送的任何 DHCPDISCOVER 或 DHCPREQUEST 消息中，在其协议软件配置了 IP 地址之前无法接收单播 IP 数据报的客户端应该将“flags”字段中的 BROADCAST 位设置为 1。BROADCAST 位将向 DHCP 服务器和 BOOTP 中继代理提供一个提示，以向客户端子网上的客户端广播任何消息。可以在其协议软件配置之前接收单播 IP 数据报的客户端应该将 BROADCAST 位清除为 0。BOOTP 澄清文档讨论了使用 BROADCAST 位 [21] 的后果。
服务器或中继代理直接向 DHCP 客户端发送或中继 DHCP 消息（即，不发送或中继到 “giaddr” 字段中指定的中继代理）应该检查 “flags” 字段中的 BROADCAST 位。如果该位设置为 1，则 DHCP 消息应该作为 IP 广播发送，使用 IP 广播地址（最好是 0xffffffff）作为 IP 目的地址和链路层广播地址作为链路层目的地址。如果 BROADCAST 位被清除为 0，则消息应该作为 IP 单播发送到“yiaddr”字段中指定的 IP 地址和“chaddr”字段中指定的链路层地址。如果单播是不可能的，消息可以作为 IP 广播发送，使用 IP 广播地址（最好是 0xffffffff）作为 IP 目的地址和链路层广播地址作为链路层目的地址。
4.2、 DHCP 服务器管理控制
DHCP 服务器不需要响应它们收到的每个 DHCPDISCOVER 和 DHCPREQUEST 消息。例如，网络管理员为了保持对连接到网络的客户端的严格控制，可能会选择配置 DHCP 服务器以仅响应先前通过某种外部机制注册的客户端。DHCP 规范只描述了客户端和服务器选择交互时客户端和服务器之间的交互；描述系统管理员可能想要使用的所有管理控制超出了 DHCP 规范的范围。特定的 DHCP 服务器实现可能包含网络管理员所需的任何控制或策略。
在某些环境中，DHCP 服务器在确定特定客户端的正确参数时必须考虑 DHCPDISCOVER 或 DHCPREQUEST 消息中包含的厂商类选项的值。
DHCP 服务器需要使用某个唯一标识符来将客户端与其租用相关联。客户端可以选择通过“客户端标识符”选项显式提供标识符。如果客户端提供“客户端标识符”，则客户端必须在所有后续消息中使用相同的“客户端标识符”，并且服务器必须使用该标识符来标识客户端。如果客户端不提供“客户端标识符”选项，则服务器必须使用“chaddr”字段的内容来标识客户端。对于 DHCP 客户端来说，在“客户端标识符”选项中使用客户端所连接的子网内唯一的标识符是至关重要的。使用“chaddr”作为客户端的唯一标识符可能会导致意外结果，因为该标识符可能与可以移动到新客户端的硬件接口相关联。一些站点可能会选择使用制造商的序列号作为“客户端标识符”，以避免由于计算机之间的硬件接口传输而导致客户端网络地址发生意外变化。站点还可以选择使用 DNS 名称作为“客户端标识符”，从而使地址租用与 DNS 名称相关联，而不是与特定的硬件盒相关联。
DHCP 客户端可以自由使用任何策略来选择客户端从其接收 DHCPOFFER 消息的 DHCP 服务器。DHCP 的客户端实现应该为用户提供一种直接选择“厂商类别标识符”值的机制。
4.3、 DHCP 服务器行为
DHCP 服务器根据客户端绑定的当前状态处理来自客户端的传入 DHCP 消息。DHCP 服务器可以从客户端接收以下消息：
DHCPDISCOVER DHCPREQUEST DHCPDECLINE DHCPRELEASE DHCPINFORM
表 3 给出了服务器对 DHCP 消息中字段和选项的使用。本节的其余部分描述了 DHCP 服务器对每个可能的传入消息的操作。
4.3.1、 DHCPDISCOVER 报文
当服务器收到来自客户端的 DHCPDISCOVER 消息时，服务器会为请求客户端选择一个网络地址。如果没有地址可用，服务器可能会选择向系统管理员报告问题。如果地址可用，则应按如下方式选择新地址：
** 客户当前地址记录在客户当前绑定中，ELSE
** 记录在客户端（现在已过期或已释放）绑定中的客户端先前地址，如果该地址在服务器的可用地址池中且尚未分配，则为该地址，ELSE
** 在“请求的 IP 地址”选项中请求的地址，如果该地址有效且尚未分配，则为该地址，ELSE
** 从服务器可用地址池中分配的新地址；根据接收消息的子网（如果“giaddr”为 0）或转发消息的中继代理的地址（“giaddr”不为 0）选择地址。
如第 4.2 节所述，出于管理原因，服务器可以分配一个不同于请求地址的地址，或者可能拒绝为特定客户端分配地址，即使有空闲地址可用。
请注意，在某些网络架构中（例如，将多个 IP 子网分配给一个物理网段的互联网），可能会为 DHCP 客户端分配一个来自不同子网的地址，而不是 “giaddr 中记录的地址”。因此，DHCP 不要求将客户端分配为来自“giaddr”中子网的地址。服务器可以自由选择某个其他子网，并且描述可能选择分配的 IP 地址的方式超出了 DHCP 规范的范围。
虽然 DHCP 的正确操作不需要，但在客户端响应服务器的 DHCPOFFER 消息之前，服务器不应该重用选定的网络地址。服务器可以选择记录提供给客户端的地址。
服务器还必须为租约选择一个到期时间，如下所示：
** 如果客户端没有在 DHCPDISCOVER 消息中请求特定的租约，并且客户端已经有分配的网络地址，则服务器返回先前分配给该地址的租约到期时间（注意，客户端必须明确请求特定的租约才能延长先前分配的地址的到期时间），ELSE
** 如果客户端没有在 DHCPDISCOVER 消息中请求特定的租约，并且客户端没有分配网络地址，则服务器分配本地配置的默认租用时间，ELSE
** 如果客户端在 DHCPDISCOVER 消息中请求了特定的租用（无论客户端是否有分配的网络地址），服务器可以选择返回请求的租用（如果本地策略可以接受该租用）或选择另一个租。
表 3：DHCP 服务器使用的字段和选项
一旦确定了网络地址和租用，服务器就会使用提供的配置参数构建 DHCPOFFER 消息。无论客户端选择哪个服务器，所有 DHCP 服务器都必须返回相同的参数（新分配的网络地址可能除外）以确保可预测的客户端行为。必须按以下顺序应用以下规则来选择配置参数。网络管理员负责配置多个 DHCP 服务器以确保来自这些服务器的统一响应。服务器必须返回给客户端：
** 客户端的网络地址，由本节前面给出的规则确定，
** 客户租约的到期时间，由本节前面给出的规则确定，
** 客户端请求的参数，按照以下规则：
-- 如果已将服务器显式配置为参数的默认值，则服务器必须在“选项”字段中包含该值，否则
-- 如果服务器将该参数识别为主机需求文档中定义的参数，则服务器必须在“选项”字段的相应选项中包含主机需求文档中给出的该参数的默认值，否则
-- 服务器不得为该参数返回值。
服务器必须提供尽可能多的请求参数，并且必须省略它不能提供的任何参数。除非在 DHCP 选项和 BOOTP 厂商扩展文档中明确允许，否则服务器必须只包含每个请求的参数一次。
** 现有绑定中与主机要求文档默认值不同的任何参数，
** 特定于此客户端的任何参数（由 DHCPDISCOVER 或 DHCPREQUEST 消息中的“chaddr”或“客户端标识符”的内容标识），例如，由网络管理员配置，
** 特定于此客户端类的任何参数（由 DHCPDISCOVER 或 DHCPREQUEST 消息中的“厂商类标识符”选项的内容标识），例如，由网络管理员配置；参数必须通过客户端的厂商类标识符和服务器中标识的客户端类之间的精确匹配来标识，
** 客户端子网上具有非默认值的参数。
服务器可以选择返回用于确定 DHCPOFFER 消息中的参数的“厂商类别标识符”，以帮助客户端选择接受哪个 DHCPOFFER。服务器将 DHCPDISCOVER 消息中的“xid”字段插入到 DHCPOFFER 消息的“xid”字段中，并将 DHCPOFFER 消息发送到请求客户端。
4.3.2、 DHCPREQUEST 消息
DHCPREQUEST 消息可能来自响应来自服务器的 DHCPOFFER 消息的客户端、来自验证先前分配的 IP 地址的客户端或来自延长网络地址租期的客户端。如果 DHCPREQUEST 消息包含“服务器标识符”选项，则该消息是对 DHCPOFFER 消息的响应。否则，该消息是验证或延长现有租约的请求。如果客户端在 DHCPREQUEST 消息中使用“客户端标识符”，则它必须在所有后续消息中使用相同的“客户端标识符”。如果客户端在 DHCPDISCOVER 消息中包含请求参数列表，则它必须在所有后续消息中包含该列表。
DHCPACK 消息中的任何配置参数不应与客户端正在响应的较早 DHCPOFFER 消息中的配置参数冲突。客户端应该使用 DHCPACK 消息中的参数进行配置。
客户端发送 DHCPREQUEST 消息如下：
** 在 SELECTING 状态期间生成的 DHCPREQUEST：
客户端在“服务器标识符”中插入所选服务器的地址，“ciaddr”必须为零，“请求的 IP 地址”必须填写来自所选 DHCPOFFER 的 yiaddr 值。
请注意，客户端可能会选择收集多个 DHCPOFFER 消息并选择“最佳”选项。客户端通过在 DHCPREQUEST 消息中标识提供服务器来指示其选择。如果客户端没有收到可接受的选项，客户端可能会选择尝试另一个 DHCPDISCOVER 消息。因此，服务器可能不会收到特定的 DHCPREQUEST，它们可以从中决定客户端是否已接受选项。因为服务器没有根据 DHCPOFFER 提交任何网络地址分配，服务器可以自由地重用提供的网络地址以响应后续请求。作为一个实现细节，服务器不应该重用提供的地址，并且可以使用特定于实现的超时机制来决定何时重用提供的地址。
** 在 INIT-REBOOT 状态期间生成的 DHCPREQUEST：
“服务器标识符”不得填写，“请求的 IP 地址”选项必须填写客户端对其先前分配地址的概念。“ciaddr” 必须为零。客户端正在寻求验证先前分配的缓存配置。如果“请求的 IP 地址”不正确，或者在错误的网络上，服务器应该向客户端发送 DHCPNAK 消息。
通过检查 “giaddr” 的内容、“requested IP address” 选项和数据库查找来确定处于 INIT-REBOOT 状态的客户端是否在正确的网络上。如果 DHCP 服务器检测到客户端在错误的网络上（即，将本地子网掩码或远程子网掩码（如果 “giaddr” 不为零）应用于 “requested IP address” 选项值的结果与现实不符)，那么服务器应该向客户端发送一个 DHCPNAK 消息。
如果网络正确，则 DHCP 服务器应检查客户端对其 IP 地址的概念是否正确。如果不是，那么服务器应该向客户端发送一个 DHCPNAK 消息。如果 DHCP 服务器没有这个客户端的记录，那么它必须保持沉默，并且可以向网络管理员输出警告。这种行为对于同一线路上非通信 DHCP 服务器的和平共存是必要的。
如果 DHCPREQUEST 消息中的 “giaddr” 为 0x0，则客户端与服务器位于同一子网上。服务器必须向 0xffffffff 广播地址广播 DHCPNAK 消息，因为客户端可能没有正确的网络地址或子网掩码，并且客户端可能没有响应 ARP 请求。
如果在 DHCPREQUEST 消息中设置了“giaddr”，则客户端位于不同的子网上。服务器必须在 DHCPNAK 中设置广播位，以便中继代理将 DHCPNAK 广播给客户端，因为客户端可能没有正确的网络地址或子网掩码，并且客户端可能不会响应 ARP 请求。
** 在 RENEWING 状态期间生成的 DHCPREQUEST：
“服务器标识符”不得填写，“请求的 IP 地址”选项不得填写，“ciaddr”必须填写客户端的 IP 地址。在这种情况下，客户端已完全配置，并且正在尝试延长其租期。此消息将是单播的，因此在其传输中不会涉及中继代理。因为“giaddr”因此没有填写，DHCP服务器会信任“ciaddr”中的值，并在回复客户端时使用它。
客户可以选择在 T1 之前续订或延长租期。服务器可以选择不延长租期（作为网络管理员的策略决定），但无论如何都应该返回 DHCPACK 消息。
** 重新绑定状态期间生成的 DHCPREQUEST：
“服务器标识符”不得填写，“请求的 IP 地址”选项不得填写，“ciaddr”必须填写客户端的 IP 地址。在这种情况下，客户端已完全配置，并且正在尝试延长其租期。此消息必须广播到 0xffffffff IP 广播地址。DHCP 服务器应该在回复 DHCPREQUEST 之前检查 “ciaddr” 的正确性。
来自 REBINDING 客户端的 DHCPREQUEST 旨在容纳具有多个 DHCP 服务器的站点以及用于在由多个服务器管理的租约之间保持一致性的机制。DHCP 服务器可以仅在它具有本地管理权限的情况下延长客户端的租期。
4.3.3、 DHCPDECLINE 消息
如果服务器收到 DHCPDECLINE 消息，则客户端已通过某种其他方式发现建议的网络地址已在使用中。服务器必须将网络地址标记为不可用，并且应该将可能的配置问题通知本地系统管理员。
4.3.4、 DHCPRELEASE 消息
收到 DHCPRELEASE 消息后，服务器将网络地址标记为未分配。服务器应该保留客户端初始化参数的记录，以便在响应来自客户端的后续请求时可能重用。
4.3.5、 DHCPINFORM 消息
服务器通过直接向 DHCPINFORM 消息的“ciaddr”字段中给出的地址发送 DHCPACK 消息来响应 DHCPINFORM 消息。服务器不得向客户端发送租约到期时间，也不应填写“yiaddr”。服务器在 DHCPACK 消息中包含其他参数，如第 4.3.1 节中所定义。
4.3.6、 客户端消息
表 4 详细说明了来自不同状态的客户端的消息之间的差异。
表 4：来自不同状态的客户端消息
4.4、 DHCP 客户端行为
图 5 给出了 DHCP 客户端的状态转换图。客户端可以从服务器接收以下消息：
DHCPOFFER DHCPACK DHCPNAK
DHCPINFORM 消息未在图 5 中显示。客户端只需发送 DHCPINFORM 并等待 DHCPACK 消息。一旦客户端选择了它的参数，它就完成了配置过程。
表 5 给出了客户端对 DHCP 消息中字段和选项的使用。本节的其余部分描述了 DHCP 客户端对每个可能的传入消息的操作。以下部分的描述对应于之前3.1节中描述的完整配置过程，后续部分中的文本对应于3.2节中描述的缩略配置过程。
图 5：DHCP 客户端的状态转换图
4.4.1、 网络地址的初始化和分配
客户端开始于 INIT 状态并形成 DHCPDISCOVER 消息。客户端应该等待 1 到 10 秒之间的随机时间，以在启动时不同步 DHCP 的使用。客户端将“ciaddr”设置为 0x00000000。客户端可以通过包含“参数请求列表”选项来请求特定参数。客户端可以通过包含“请求的 IP 地址”和“IP 地址租用时间”选项来建议网络地址和/或租用时间。客户端必须在 “chaddr” 字段中包含它的硬件地址，如果需要传递 DHCP 回复消息。客户端可以在“客户端标识符”选项中包含不同的唯一标识符，如第 4.2 节所述。如果客户端在 DHCPDISCOVER 消息中包含请求参数列表，则它必须在所有后续消息中包含该列表。
客户端生成并记录一个随机事务标识符并将该标识符插入到“xid”字段中。客户端记录自己的本地时间，以供以后计算租约到期时使用。然后客户端将本地硬件广播地址上的 DHCPDISCOVER 广播到 0xffffffff IP 广播地址和“DHCP 服务器”UDP 端口。
如果到达的 DHCPOFFER 消息的“xid”与最近的 DHCPDISCOVER 消息的“xid”不匹配，则必须静默丢弃 DHCPOFFER 消息。任何到达的 DHCPACK 消息都必须以静默方式丢弃。
客户端在一段时间内收集 DHCPOFFER 消息，从（可能很多）传入的 DHCPOFFER 消息（例如，第一个 DHCPOFFER 消息或来自先前使用的服务器的 DHCPOFFER 消息）中选择一个 DHCPOFFER 消息，并从“服务器”中提取服务器地址DHCPOFFER 消息中的标识符选项。客户端收集消息的时间和用于选择一个 DHCPOFFER 的机制取决于实现。
表 5：DHCP 客户端使用的字段和选项
如果参数是可接受的，则客户端记录从“服务器标识符”字段提供参数的服务器的地址，并在 DHCPREQUEST 广播消息的“服务器标识符”字段中发送该地址。一旦来自服务器的 DHCPACK 消息到达，客户端就会被初始化并进入绑定状态。DHCPREQUEST 消息包含与 DHCPOFFER 消息相同的“xid”。客户端将租用到期时间记录为发送原始请求的时间与来自 DHCPACK 消息的租用持续时间的总和。客户端应该对建议的地址执行检查以确保该地址尚未被使用。例如，如果客户端位于支持 ARP 的网络上，则客户端可能会针对建议的请求发出 ARP 请求。客户端在广播建议地址的ARP请求时，必须填写自己的硬件地址作为发送方的硬件地址，0作为发送方的IP地址，以免混淆同一子网其他主机的ARP缓存。如果网络地址似乎正在使用，则客户端必须向服务器发送 DHCPDECLINE 消息。客户端应该广播一个 ARP 回复来宣布客户端的新 IP 地址并清除客户端子网上主机中任何过时的 ARP 缓存条目。
4.4.2、 用已知网络地址初始化
客户端开始处于 INIT-REBOOT 状态并发送 DHCPREQUEST 消息。客户端必须在 DHCPREQUEST 消息中插入其已知的网络地址作为“请求的 IP 地址”选项。客户端可以通过包含“参数请求列表”选项来请求特定的配置参数。客户端生成并记录一个随机事务标识符并将该标识符插入到“xid”字段中。客户端记录自己的本地时间，以供以后计算租约到期时使用。客户端不得在 DHCPREQUEST 消息中包含“服务器标识符”。然后客户端将本地硬件广播地址上的 DHCPREQUEST 广播到“DHCP 服务器”UDP 端口。
一旦来自任何服务器的具有与客户端的 DHCPREQUEST 消息中的“xid”字段匹配的 DHCPACK 消息到达，客户端将被初始化并移动到绑定状态。客户端将租用到期时间记录为发送 DHCPREQUEST 消息的时间与来自 DHCPACK 消息的租用持续时间的总和。
4.4.3、 使用外部分配的网络地址进行初始化
客户端发送 DHCPINFORM 消息。客户端可以通过包含“参数请求列表”选项来请求特定的配置参数。客户端生成并记录一个随机事务标识符并将该标识符插入到“xid”字段中。客户端将自己的网络地址放在“ciaddr”字段中。客户端不应该请求租用时间参数。
如果客户端知道服务器的地址，则客户端然后将 DHCPINFORM 单播到 DHCP 服务器，否则它将消息广播到有限的（全 1）广播地址。DHCPINFORM 消息必须被定向到“DHCP 服务器”UDP 端口。
一旦来自任何服务器的具有与客户端的 DHCPINFORM 消息中的“xid”字段匹配的 DHCPACK 消息到达，客户端就会被初始化。
如果客户端在合理的时间段内（60 秒或 4 次尝试，如果使用第 4.1 节中建议的超时）没有收到 DHCPACK，那么它应该显示一条消息通知用户这个问题，然后应该开始使用合适的网络处理附录 A 中的默认值。
4.4.4、 广播和单播的使用
DHCP 客户端广播 DHCPDISCOVER、DHCPREQUEST 和 DHCPINFORM 消息，除非客户端知道 DHCP 服务器的地址。客户端向服务器单播 DHCPRELEASE 消息。由于客户端拒绝使用服务器提供的 IP 地址，因此客户端会广播 DHCPDECLINE 消息。
当 DHCP 客户端知道 DHCP 服务器的地址时，无论是在 INIT 还是 REBOOTING 状态，客户端都可以在 DHCPDISCOVER 或 DHCPREQUEST 中使用该地址，而不是 IP 广播地址。客户端也可以使用单播向已知的 DHCP 服务器发送 DHCPINFORM 消息。如果客户端没有收到对发送到已知 DHCP 服务器 IP 地址的 DHCP 消息的响应，则 DHCP 客户端将恢复使用 IP 广播地址。
4.4.5、 收回和到期
客户端维护两个时间，T1 和 T2，指定客户端尝试延长其网络地址租用的时间。T1 是客户端进入 RENEWING 状态并尝试联系最初发布客户端网络地址的服务器的时间。T2 是客户端进入 REBINDING 状态并尝试联系任何服务器的时间。T1 必须早于 T2，反过来，T2 必须早于客户端的租约到期时间。
为避免需要同步时钟，T1 和 T2 在选项中表示为相对时间 [2]。
在时间 T1，客户端移动到 RENEWING 状态并向服务器发送（通过单播）DHCPREQUEST 消息以延长其租期。客户端将 DHCPREQUEST 中的“ciaddr”字段设置为其当前网络地址。客户端记录发送 DHCPREQUEST 消息的本地时间，用于计算租用到期时间。客户端不得在 DHCPREQUEST 消息中包含“服务器标识符”。
任何带有与客户端 DHCPREQUEST 消息的“xid”不匹配的“xid”到达的 DHCPACK 消息都将被静默丢弃。当客户端收到来自服务器的 DHCPACK 时，客户端计算租约到期时间为客户端发送 DHCPREQUEST 消息的时间和 DHCPACK 消息中租用的持续时间之和。客户端已成功重新获取其网络地址，返回到 BOUND 状态并可以继续网络处理。
如果在时间 T2 之前没有 DHCPACK 到达，则客户端移动到 REBINDING 状态并（通过广播）发送 DHCPREQUEST 消息以延长其租期。客户端将 DHCPREQUEST 中的“ciaddr”字段设置为其当前网络地址。客户端不得在 DHCPREQUEST 消息中包含“服务器标识符”。
时间 T1 和 T2 可由服务器通过选项配置。T1 默认为 (0.5 * duration_of_lease)。T2 默认为 (0.875 * duration_of_lease)。时间 T1 和 T2 应该在固定值周围随机“模糊”选择，以避免客户端重新获取同步。
客户可以选择在 T1 之前续订或延长租期。服务器可以根据网络管理员设置的策略选择延长客户端的租期。服务器应该返回 T1 和 T2，并且它们的值应该从它们的原始值调整以考虑租用剩余的时间。
在 RENEWING 和 REBINDING 状态下，如果客户端没有收到对其 DHCPREQUEST 消息的响应，则客户端应该等待剩余时间的一半直到 T2（在 RENEWING 状态）和剩余租用时间的一半（在 REBINDING 状态） ，在重新传输 DHCPREQUEST 消息之前，最少需要 60 秒。
如果租约在客户端收到 DHCPACK 之前到期，则客户端移动到 INIT 状态，必须立即停止任何其他网络处理并请求网络初始化参数，就像客户端未初始化一样。如果客户端随后收到一个 DHCPACK 分配该客户端其先前的网络地址，则客户端应该继续网络处理。如果给客户端一个新的网络地址，它不得继续使用以前的网络地址，并且应该将问题通知本地用户。
4.4.6、 DHCPRELEASE
如果客户端不再需要使用其分配的网络地址（例如，客户端正常关闭），则客户端向服务器发送 DHCPRELEASE 消息。请注意，DHCP 的正确操作不依赖于 DHCPRELEASE 消息的传输。
5、 致谢
作者感谢 DHC WG 的许多（不胜枚举！）成员在 DHCP 和本文档的开发中所做的不懈努力。
非常感谢 J Allard、Mike Carney、Dave Lapp、Fred Lien 和 John Mendonca 在组织 DHCP 互操作性测试会议方面所做的努力。
本文档的开发部分得到了国家研究计划公司 (CNRI)、巴克内尔大学和 Sun Microsystems 的资助。
6、 参考文献
[1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December 1983. [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 1533, Lachman Technology, Inc., Bucknell University, October 1993. [3] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989. [4] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support, STD 3, RFC 1123, USC/Information Sciences Institute, October 1989. [5] Brownell, D, "Dynamic Reverse Address Resolution Protocol (DRARP)", Work in Progress. [6] Comer, D., and R. Droms, "Uniform Access to Internet Directory Services", Proc. of ACM SIGCOMM “90 (Special issue of Computer Communications Review), 20(4):50--59, 1990. [7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, Stanford and SUN Microsystems, September 1985. [8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991. [9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534, Bucknell University, October 1993. [10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", RFC 903, Stanford, June 1984. [11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency", In Proc. of the Twelfth ACM Symposium on Operating Systems Design, 1989. [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987. [13] Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987. [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached Hosts", Work in Progress. [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981. [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, USC/Information Sciences Institute, August 1993. [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic Assignment of IP Addresses for use on an Ethernet. (Available from the Athena Project, MIT), 1989. [20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC, June 1981. [21] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, Carnegie Mellon University, October 1993.
7、 安全考虑
DHCP 直接建立在 UDP 和 IP 上，而这些 UDP 和 IP 本质上是不安全的。此外，DHCP 通常旨在使远程和/或无盘主机的维护更容易。虽然并非不可能，但使用密码或密钥配置此类主机可能很困难且不方便。因此，当前形式的 DHCP 非常不安全。
可以轻松设置未经授权的 DHCP 服务器。然后，这些服务器可以向客户端发送虚假的和潜在的破坏性信息，例如不正确或重复的 IP 地址、不正确的路由信息（包括欺骗路由器等）、不正确的域名服务器地址（例如欺骗名称服务器）等等。显然，一旦这些种子信息到位，攻击者就可以进一步破坏受影响的系统。
恶意 DHCP 客户端可以伪装成合法客户端并检索用于这些合法客户端的信息。在使用资源动态分配的情况下，恶意客户端可以为自己声明所有资源，从而拒绝向合法客户端提供资源。
附录A、 主机配置参数
Key:
MTU = Path MTU Discovery (RFC 1191, Proposed Standard) RD = Router Discovery (RFC 1256, Proposed Standard)
