DHCP协议
DHCP协议——RFC2131
1 Introduction
DHCP协议，即Dynamic Host Configuration Protocol，动态主机配置协议，主要是为了解决动态主机 配置问题，DHCP提供了一个在TCP/IP网络中传递配置信息给主机的框架。DHCP基于BOOTP开发，增加了可重用网络地址的自动分配功能和额外的配置选项。DHCP可以捕获BOOTP中继器的动作，并且DHCP设备可以BOOTP设备互操作。
1.1 相关协议
对于动态主机配置问题的解决，已有几种网络协议和相关的机制在工作。RARP协议明确的处理网络地址发现的问题，并包括一套自动IP地址分配机制。TFTP提供了将一个小的简单文件从boot服务器传输的问题。ICMP协议通过“ICMP重定向”消息提供了额外路由器的通知主机。ICMP同样可以通过“ICMP掩码请求”消息提供子网掩码信息。主机可以通过ICMP路由发现机制来定位路由器。
一般网络中会有数种协议参与解决动态主机的配置问题，DHCP协议主要用于在配置的初始化过程中，在后面的工作中，一般只在地址续期或重新分配时再次使用。
1.2 设计目标
RFC2131对DHCP协议的设计提出几点目标，这也是DHCP协议所具备的基本功能：
- DHCP应该是一个机制，而不是策略
- 客户端无需手动配置参数
- 网络无需为客户端手动配置桉树
- DHCP应该无需再每个子网都配置DHCP服务器
- DHCP客户端必须随时准备接收一个参数配置请求的多个响应
- DHCP必须和静态配置的、不参与的主机以及已存在的网络协议实现共存
- DHCP必须可以与RFC 951和RFC 1542所定义的BOOTP中继代理行为交互操作
- DHCP必须为已存在的BOOTP客户端提供服务
因此，DHCP必须：
- 确保任何指定的网络地址在同一时间，只能被不超过一个的DHCP客户端使用
- 在客户端重启后，保持DHCP客户端配置参数不变，只要可能的情况下，对每个请求，DHCP客户端都应该被分配一样的配置参数
- 在服务器重启后，保持DHCP客户端配置参数不变，只要可能的情况下，DHCP客户端应该被分配同样的配置参数，而不管DHCP机制的重启
- 允许对新客户端配置参数的自动分配，来避免手动配置
- 对于指定客户端，支持固定或永久的配置的分配
1.3 术语
1.4 资料引用
RFC 2131
RFC 951
RFC 1542
2 Summary
从客户端的角度看来，DHCP是BOOTP机制的一个扩展，这导致已在的BOOTP客户端可以和DHCP服务器直接相互操作，而不需对客户端的初始化软件进行任何修改。RFC 1542详细描述了BOOTP设备和DHCP客户端及服务器之间的交互。在RFC 2131中，提供了一些新的可选的处理，用于优化DHCP客户端和服务器之间的交互操作。
图1给出了DHCP消息的格式，表1描述了消息中的每个字段。
| 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服务为每个客户端存储一个key-value入口，这里的key是一个唯一标志，这里的value包含这个客户端的配置参数。
比如，key可能是一对（IP-subnet-number，hardware-address），允许在不同的子网内连续或同时使用一个硬件地址，并且允许使用非全球唯一的硬件地址。同时，key可能是一对（IP-subnet-number,hostname），允许服务器去智能的给那些已经移动到别的子网或变动了硬件地址的客户端分配地址。根据协议定义，除非客户端使用‘client identifier’字段明确支持一个标识符，key应是（IP-subnet-number，hardware-address）对。客户端可以向DHCP服务请求重新获取配置参数。客户端对接配置参数仓库的接口包含两部分，发给服务器的请求配置参数的协议消息和来自服务器的携带配置参数的响应。
2.2 网络地址的动态配置
为客户端临时的或永久的分配网络地址，是DHCP提供的第二个服务。该服务的基本机制是：客户端请求在一定周期时间内使用某个网络地址。这种分配机制确保在请求的时间内，不会重复分配该地址，并且尽力在每次指定客户端请求地址时，都分配同样的网络地址，在DHCP协议中，该周期被称为租期（lease）。客户端可以通过后续的请求来延长租期，也可以在不需要地址时通过发送消息来释放地址给服务器。客户端可以通过请求一个无限的租期来获取一个永久的地址分配。但是即使分配了永久地址，服务器可能选择给出一个很长但是非无穷的租期，来允许对客户端已经退出这一事实进行探测。
在一些环境中，由于可用地址耗尽，有必要对网络地址进行重新分配。此时，分配机制会重用那些租期已经时效的地址。服务器应该利用参数信息仓库中任何可用信息，去选择一个可重用的地址。比如，服务器可能会选择最近最少被分配的地址。作为一种相容性检测，分配服务器应该在分配地址之前对重用地址进行探测，比如使用ICMPecho请求，而客户端应该探测新接收到的地址，比如使用ARP。
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中的时序图展示了在一个典型的客户端-服务器交互中的书时序关系。如果客户端已经知道了自己的地址，那么一些步骤可能会被省略。
| 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消息。该消息的选项可能会包含网络地址和租期时间的建议值。BOOTP中继器可能会在非相同物理子网上将消息传递给DHCP服务器。
- 对应服务器可能会回复一个DHCPOFFER消息，该消息在‘yiaddr’字段包含一个可用的网络地址（并且在‘options’字段包含其他配置参数）。服务器不需要保存已提供的网络地址，当分配一个新的地址时，服务器应该检查已经提供的网络地址没有在使用；比如，服务器会使用ICMP echo请求来探测已提供的地址。服务器应该这样做，以便网络管理员可以选择不去探测新分配的地址。必要情况下，服务器使用BOOTP中继器来传输DHCPOFFER消息给客户端。
- 客户端从一个或多个服务器接收到一个或多个DHCPOFFER消息。客户端可以选择等待多路的响应。基于DHCPOFFER消息中提供的配置参数，客户端从中选择的服务器，然后广播一个DHCPREQUEST消息，该消息必须携带‘server identifier’选项来表明它所选择的服务器，并且可能包含其他选择来指明所需要的配置值。‘被请求的IP地址’选择必须被设为服务器发送的DHCPOFFER消息‘yiaddr’字段的值。DHCPRREQUEST消息通过DHCP/BOOTP中继器被广播和中继。为了保证所有的BOOTP中继器都会转发DHCPREQUEST消息给接收初始DHCPDISCOVER消息的同一组DHCP服务器，所有DHCPREQUEST消息必须使用DHCP消息头部‘secs’字段相同的值，并且被发送到和初始DHCPREQUEST消息一样IP广播地址。如果没有接收到DHCPOFFER消息，客户端将会超时并重传DHCPDISCOVER消息。
- 服务器接收来自客户端的DHCPREQUEST消息广播。那些没有被选中的服务器，通过DHCPREQUEST消息得知他们被客户端拒绝。被选中的服务器为客户端提交与永久存储的绑定，并且以DHCPACK消息回复，该消息包含发送请求的客户端配置参数。在任何DHCP消息中，客户端ID或‘chaddr’和分配的网络地址的组合，为客户端的租期构成了一个唯一的ID，并同时被客户端和服务器用于分辨一个相关的租期。DHCPACK消息里的任何配置参数都不应该和那些在早先DHCPOFFER消息里的相互冲突。服务器在这里不应该检查分配的网络地址。DHCPACK消息里的‘yiaddr’字段此时被选中的网络地址填充。
如果选中的服务器无法满足DHCPREQUEST消息的要求，比如请求的网络地址已经被分配了，服务器应该以一个DHCPACK消息回复客户端。
一个服务器可以在DHCPOFFER消息中标记提供给客户端的网络地址为不可用。如果该服务器没有从该客户端接收到DHCPREQUEST消息，则应该在DHCPOFFER消息中将提供给客户端的地址标记为可用。 - 客户端接受携带配置参数的DHCPACK消息。客户端应该对参数执行最终的检测，比如使用ARP对分配的网络地址进行检测，并且注明DHCPACK消息中指定的租期时间。在这里，客户端就被配置了。如果客户端探测到地址已经被使用了，比如通过ARP探针，客户端必须发送DHCPDECLINE消息给服务器，并重新开始配置的过程。在循环的情况下，在重新开启配置过程之前，客户端应该等待至少10s，以避免造成网络过载。
如果客户端接收到DHCPDECLINE消息，则直接重新开始配置过程。
如果客户端既没有接收到DHCPACK消息，也没有接收到DHCPDECLINE消息，则会等待超时，并根据重传算法重新传输DHCPREQUEST。客户端应该选择重传DHCPREQUEST足够多次，来尽可能联系服务器，以免导致客户端（以及客户端的使用者）在放弃连接之前等待过长时间。选择重发的客户端可能重复发送四次，即总的延迟60s。如果在使用重传算法之后（即四次重发）仍没有收到DHCPACK和DHCPNAK消息，客户端会返回到初始状态并重启初始化过程。客户端应该通知使用者，初始化过程已经失败并重新开启。 - 客户端可以通过向服务器发送DHCPRELEASE消息来放弃它在一个网络地址上的租期。客户端通过在DHCPRELEASE消息里面标明它的‘client identifier’或‘chaddr’以及网络地址，来表明该租期已经被释放，注意该‘client identifier’必须和获取该租期时所使用的保持一致。
3.2 客户端-服务器交互——重用一个之前分配的网络地址
如果客户端记得并想要重用一个之前分配的网络地址，它可以选择去忽略一些上述的步骤，比如客户端广播DHCPDISCOVER消息和服务器回复DHCPOFFER消息的步骤，以及服务器回复DHCPACK的步骤。图4中的时序图展示了在典型的客户端-服务器交互中，一个客户端重用之前分配的网络地址的时序图。
- 客户端在它的子网上广播DHCPREQUEST消息。消息包含‘requested IP address’项中的客户端网络地址。由于客户端还没有收到它的网络地址，所以‘ciaddr’项不能填充数据。BOOTP中继器在相同的子网上将消息传递给DHCP服务器。如果客户端曾使用‘client identifier’来获取它的地址，客户端必须在DHCPREQUEST消息中使用相同的‘client identifier’。
- 携带客户端配置参数的服务器以DHCPACK消息回复客户端。服务器不应该检查客户端的网络是否已使用；此时，客户端可以回应ICMP echo请求。（也就是说，在这里DHCP服务器直接回复DHCPACK消息，而不去主动进行检查，但是可以通过客户端对ICMP Echo Request的响应，来进行探测。）如果客户端你的请求是无效的，比如客户端已经移动到新的子网络），服务器应以DHCPNAK回复客户端。如果服务器不能保证它的新的是准确的，那么它不应该回复。比如，如果服务器检测到一个对已过期绑定的请求，而该绑定是属于另一个服务器的，那么它就不应回复DHCPNAK，除非使用一个明确的机制来在服务器之间维持一致性（coherency）。
如果DHCPREQUEST消息中‘giaddr’为0x0，那么客户端和服务器分布在一个子网中。服务器广播DHCPNAK消息的广播地址必须为0xffffffff，因为客户端可能没有正确的网络地址或子网掩码，并且可能没有正在响应ARP请求。此外，服务器必须发送DHCPNAK消息给‘giaddr’字段所记录的BOOTP中继器的IP地址。相应的，中继器将会直接转发消息给客户端的硬件地址，这样一来，即使客户端被移动到一个新的子网，DHCPNAK也能被传送到。 - 客户端接受到携带配置信息的DHCPACK消息，然后会对参数进行最终的检查，并且说明在消息中指定的租期时长。该指定的租期被‘client identifier’或‘chaddr’和网络地址含蓄的定义。在这里，客户端被配置了
如果客户端检测到DHCPACK中的IP地址已经被使用，客户端必须发送一个DHCPDECLINE消息给服务器，并且通过请求一个新的网络地址来重启配置过程。这一操作和DHCP状态图中客户端移至初始状态时相对应。
如果客户端接受到DHCPNAK消息，那么它无法重用它所记忆的网络地址。相反，它必须通过重启配置过程来请求一个新的地址，这一次使用上述章节中的非简化过程来获得配置。
如果客户端没有收到DHCPACK或DHCPNAK消息，则它需要等待超时，并根据重传算法来重新传输DHCPREQUEST消息。客户端应该选择重传DHCPREQUEST足够多次，来尽可能联系服务器，以免导致客户端（以及客户端的使用者）在放弃连接之前等待过长时间。选择重发的客户端可能重复发送四次，即总的延迟60s。如果在使用了重传算法重传之后，客户端仍没有收到DHCPACK和DHCPNAK消息，则它可能为他未过期租期的余下时间选择使用之前配置的网络地址和配置参数（续约行为一般发生在租期的1/4,1/2,3/4处，所以可以继续使用原来的配置）。 - 客户端可以通过发送DHCPRELEASE消息给服务器来主动放弃它在某一网络地址上的租期，该租期通过DHCPRELEASE消息中的‘client identifier’或‘chaddr’和网络地址来识别。
注意：在客户端本地保持它的网络地址的情况下，它不能正常的通过一个优雅的关闭行为（graceful shutdown）来放弃它的租期。只有在客户端明确需要放弃它的租期的情况下，比如客户端移至其他子网，客户端才会发送DHCPRELEASE消息。
3.3 时间值的解释和表示
客户端获取一个确定周期的一个网络地址租期（也可能是无限）。在整个协议中，时间都是以秒为单位来表示。0xffffffff的时间值被保留代表无限。
由于客户端和服务器可能不会同步时钟，所以时间值在DHCP消息中以相对时间来表示，在客户端的本地时钟中来解释。以秒为单位表示的相对时间长度是一个32位无符号整型，范围从0s到大约100年，已经满足使用DHCP进行计量的要求。
上述章节中给出的租期时间解释的算法，是建立在客户端和服务器时钟彼此相对稳定的基础上的。如果在两个时钟之间有漂移，服务器可能在客户端之前认为租约过期。为了补偿这一点，服务器可能回复一个比提交给本地客户端数据库更短的租约时间给客户端。
3.4 使用外部配置的网络地址获得参数
如果客户端通过一些其他的手段获得了一个网络地址（比如手动设置），它可是使用DHCPINFORM请求消息来获取其他的本地配置参数。接收到DHCPINFORM消息的服务器使用任何适合该客户端的配置参数来构造DHCPACK消息，但不包括以下信息：分配一个新地址、检查已存在的绑定、填充‘yiaddr’字段或包含租期时间参数。服务器应该向DHCPINFORM消息中提供的地址单播DHCPACK消息。
服务器应该对DHCPINFORM消息中的网络地址进行相容性检测，但不能对已存在的租期进行检查。服务器为发出请求的客户端组织包含配置参数的DHCPACK消息，并且直接将消息发送给客户端。
3.5 DHCP中的客户端参数
并不是所有客户端在初始化时都需要附录A中所列出的所有参数。有两种技术被用于减少从服务器传送给客户端的参数。
- 大多数从服务器传送到客户端的参数在本地都有定义在Host Requirement RFCs中的默认值；如果客户端没有从服务器接收到可以重写该默认值的参数，则会使用这些默认值。
- 在初始化的DHCPDISCOVER和DHCPREQUEST消息中，客户端可以向服务器提供一系列它感兴趣的指定参数。如果客户端在DHCPDISCOVER消息中包含了一系列参数，那么他在所有后续的DHCPREQUEST消息中都必须包含该系列参数。
客户端应包含‘maximum DHCP消息长度’选项来让服务器知道应该构建多大的DHCP消息报文。回复给客户端的参数可能仍然超出在DHCP消息中分配给options字段的空间。在这种情况下，两种额外的选项标志位（该标志位必须出现在消息的‘options’字段）标志着‘file’和‘sname’字段将被用于选项设置。
通过包含‘parameter request list’字段，客户端可以告知服务器哪些配置参数是客户端感兴趣的。该选项的这部分数据，明确列出了以标签号排序的被请求的数据。
此外，客户端可以在DHCPDISCOVER消息中提议想要的网络地址和租期时间。客户端可以在‘requested IP address’选项中来提议分配一个特定的IP，并在‘IP address lease time’字段中提议一个想要的租约时间。在配置参数中其他表现“暗示”的选项在DHCPDISCOVER或DHCPREQUEST消息中也是被允许的。然而，额外的选项可能被服务器忽略，因此多种路由器可能不会为一些选项返回完全一致的值。‘requested IP address’选项只在客户端校验之前获取的网络参数的时候，在DHCPREQUEST消息中被填充。只有在BOUND、RENEWING或REBINDING状态下，客户端被一个IP地址正确配置时，客户端会填充‘ciaddr’字段。
如果服务器接收到一个携带无效‘requested IP address’信息的DHCPREQUEST消息，服务器应该给客户端返回一个DHCPNAK消息，并且可能选择向系统管理员反馈这个问题，并可能在‘message’选项中包含错误信息。
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服务器管理控制
DHCP服务器不需要对它接收到的所有DHCPDISCOVER和DHCPREQUEST消息做出响应。比如，网络管理员可以选择配置DHCP服务器只对先前通过外部机制配置的客户端做出响应。DHCP规则只描述当客户端和服务器选择去交互时，二者之间的交互；描述所有的系统管理可能使用到的管理控制，是超出DHCP规范范围的。指定的DHCP服务器实习可以包含任意的被网络管理员所需要的控制或策略。
在一些环境中，在为一个指定的客户端确定正确参数的时候，DHCP服务器会不得不考虑在DHCPDISCOVER或DHCPREQUEST消息中包含的供应商类选项的值。
DHCP服务器需要使用一些唯一的标识来讲客户端和他的租约联系在一起。客户端可以选择通过‘client identifier’选项明确的提供该标志符，如果这样，该客户端必须在接下来的所有消息中都是用统一的‘client identifier’，并且服务器必须使用该标识符来确定该客户端。在客户端被连接到‘client identifier’选项的子网中，使用一个唯一标志符对DHCP客户端来说是很重要的。使用‘chaddr’字段作为唯一标识符可能引起一些意想不到的结果，因为该标识符可能和一个可以被移动到一个新子网的硬件接口绑定。一些网站选择使用一个供应商的序列号作为‘client identifier’，来避免由于硬件接口在计算机之间的转移导致的客户端网络子网的意想不到的变化。
DHCP客户端可以在它接收DHCPOFFER消息的服务器中，自由的使用任何策略进行选择。DHCP的客户端实现应提供一种机制为用户来直接选择’vendor class identifier’值。
4.3 DHCP服务器行为
DHCP服务器基于该客户端当前的绑定状态来处理接收自该客户端的DHCP消息，可以接收的消息如下：
- DHCPDISCOVER
- DHCPREQUEST
- DHCPDECLINE
- DHCPRELEASE
- DHCPINFORM
表3给出了服务器对消息中这些字段和选项的使用。本节的余下部分描述了DHCP服务器对任意可能接收的消息的处理。
4.3.1 DHCPDISCOVER消息
当服务器从客户端接收一个DHCPDISCOVER消息，服务器为发送请求的客户端选择一个网络地址。如果无可用地址，服务器可以选择项系统管理员报告该问题。如果有可用地址，新的地址应该按照如下规则：
- 选择记录在客户端当前绑定中的当前地址，或者
- 如果该地址在服务器的地址池中并且没有被分配，选择记录在客户端绑定中的前一个地址，或者
- 如果该地址有效并且没有被分配，选择在‘Requested IP Address’选项中请求的地址，或者
- 选择一个服务器可用地址池中的一个新地址；改地址基于消息被接收的源子网（如果‘giaddr’为0）或者基于转发该消息的中继器的地址（如果‘giaddr’不为0）。
如4.2所描述，处于管理的原因，服务器可以分配一个与请求的地址不一致，或在空余地址有效的情况下，拒绝给指定客户端分配地址。
注意，在一些网络结构中（比如，在分配给一个物理网段不住一个IP子网的网络中），可能存在这种情况，DHCP客户端应该从一个与‘giaddr’字段记录的地址不同的子网中分配一个地址。因此，DHCO不要求客户端从‘giaddr’的子网中分配地址。服务器可以自由选择一些其他子网，并且DHCP规范不描述被IP地址如何被分配和选择的方式。
虽然不要求DHCP的正确操作，但是服务器不应该在客户端回复服务器的DHCPOFFER请求之前重用选择的网络地址。服务器可以选择记录提供给客户端的地址。
服务器也必须为租期选择一个超时时间，如下：
- 如果客户端没有在DHCPDISCOVER消息中请求一个指定的租期，并且客户度已经拥有一个已分配的网络地址，那么服务器返回前一个给该地址分配的租期超时时间（注意，客户端必须明确请求一个指定的租期来在分配的前一个地址的基础上延长超时时间），或者
- 如果客户端没有在DHCPDISCOVER消息中请求一个指定的租期，并且客户度没有一个已分配的地址，服务器分配一个本地配置的默认租期时间，或者
- 如果客户端在DHCPDISCOVER消息中请一个指定的租期（不考虑客户端是否有一个已分配的地址），服务器可以选择返回一个请求的租期（如果租期对于本地策略是可接受的），或者选项一个其他的租期。
表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’字段的合适的选项中，包含该参数在Host Requirements Document中给定的默认值，或者
- 服务器不能为该参数返回一个值，必须提供尽可能多的请求的参数，并且必须忽略不可提供的参数。除非在DHCP选项和BOOTP供应商扩展文档中明确被允许，服务器必须包含每个请求的数据仅一次。
- 任何现存绑定中与Host Requirements Document默认值不一样的参数，
- 任何指定给该客户端的参数，比如被网络管理员配置的参数，
- 任何指定给该客户端类的参数，比如被网络管理员配置的；该参数必须被一个明确的匹配所识别，该匹配是客户端服务器类标识符与客户端类之间的，并能在服务器中识别的匹配。
- 在客户端子网中没有默认值的参数
服务器可以选择返回在DHCPOFFER消息中用于决定参数的’vendor class identifier’来帮助客户端选择接收哪一个DHCPOFFER。服务器将DHCPDISCOVER消息中的‘xid’字段插入DHCPOFFER消息的‘xid’字段中，并且发送DHCPOFFER消息给请求的客户端。
4.3.2 DHCPREQUEST消息
DHCPREQUEST消息可以来自于客户端响应服务器的DHCPOFFER消息，或者来自客户端验证之前分配的IP地址，或者来自客户端为一个网络地址延迟租期。如果DHCPREQUEST包含一个‘server identifier’选项， 则该消息是响应DHCPOFFER消息的。
客户端发送的DHCPREQUEST消息如下：
在SELECTING状态下产生的DHCPREQUEST消息：
客户端在‘server identifier’字段插入选中服务器的地址，‘ciaddr’字段必须为0，‘requested IP address’必须被选中的DHCPOFFER字段的yiaddr数值填充。
注意，客户端可以选择去手机数个DHCPOFFER消息并选择最佳的offer。如果客户端没有接收到可接受的offer，可以选择重新发送DHCPDISCOVER消息。由于服务器没有基于DHCPOFFER提交任何网络地址分配，服务器可以在接下来的请求中自由的重用提供的网络地址。但是根据实现细节，服务器不应该重用已提供的网络地址，并且可以使用一个实现指定的超时机制，来决定何时重用一个已提供的地址。在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给客户端，原因同上一段所述。在RENEWING状态产生的DHCPREQUEST消息：
‘server identifier’不能被填充，‘requested IP address’选项不能被填充，‘ciaddr’必须被客户端IP地址填充。在这种情况下，客户端是被完全配置的，并且尝试去延长它的租期。该消息将会被单播，所以没有中继器会参与他的传输。因此，‘giaddr’不会被填充，DHCP服务器会信任‘ciaddr’的值，并且在回复客户端时使该值。
客户端可以选择在T1之前更新或扩展他的租约。服务器可以选择不去延长该租期，但是应该仍然回复DHCPACK消息。- 在REBINDING状态下产生的DHCPREQUEST：
‘server identifier’和’requested IP address’不能被填充，‘ciaddr’必须被客户端IP地址填充。在这种情况下，客户端被完全配置，并且尝试去延长它的租期。消息必须被广播到0xffffffffIP广播地址。DHCP服务器应该在回复DHCPREQUEST消息之前检查‘ciaddr’的正确性。
4.3.3 DHCPDECLINE消息
如果服务器接收到一个DHCPDECLINE消息，那么该客户端已经通过其他方式发现所建议的网络地址已经被使用。服务器必须标记该网络地址为不可用，并且应该通知本地系统管理员这个可能的配置问题。
4.3.4 DHCPRELEASE消息
收到DHCPRELEASE消息时，服务器标记该网络地址为未分配。在对后续的该客户请求的响应中，服务器应该为可能的重用保持一个该客户端初始化参数的记录。
4.3.5 DHCPINFORM消息
服务器通过直接向DHCPINFROM消息中的‘ciaddr’字段中给定地址发送DHCPACK消息，来响应DHCPINFROM消息。服务器不能发送租期超时时间给客户端，也不能填充‘yiaddr’字段。服务器在DHCPACK消息中包含如4.3.1所定义的其他参数。
4.3.6 客户端消息
表4详细说明了在不同状态下来自客户端的区别。
表4 Client messages from different states
| 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消息并且等待DHCPACK消息的回复。一旦客户端选择了它的参数，它就完成了配置过程。
表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 |
如果参数是可接受的，客户端记录从‘server identifier’西段提供参数的服务器的地址，并且在一个DHCPREQUEST广播消息的‘server identifier’字段发送该地址。一旦来自服务器的DHCPACK消息到达，客户端即被初始化并切换至BOUND状态。客户端记录租期超时时间，该时间是初始请求被发送和DHCPACK消息中租期的时间的总和。客户端应该对建议的地址进行检查以确保该地址没有被使用。例如，如果客户端处于支持ARP的网络中，它可以为建议的地址发送一个ARP请求。当为建议的地址广播一个ARP请求时，客户端必须在它自己的硬件地址上填充发送者的硬件地址，并设发送者的IP地址为0，来避免迷惑同一子网中其他主机的ARP缓存。如果该网络地址显示出正在使用，客户端必须发送DHCPDECLINE消息给服务器。客户端应该广播一个ARP响应来声明客户端的新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服务器的地址，DHCP客户端广播DHCPDISCOVER, DHCPREQUEST and DHCPINFORM消息。客户端单播DHCPRELEASE消息给客户端。由于客户端拒绝服务器提供的IP地址的使用，所以客户端广播DHCPDECLINE消息。
在INIT或REBOOTING状态下，但客户端知道DHCP服务器的地址，客户端可以在DHCPDISCOVER或DHCPREQUEST消息使用该地址，而不是使用IP广播地址。客户端也可以使用单播去发送DHCPINFORM消息给一个已知的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.5*duration_of_lease）。T2默认值为（0.875*duration_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消息的传输。