摘要

  • FORCERENEW 让服务器可以催促已配置的客户端重新联系它，但客户端仍要执行普通 DHCP 交换。通知本身既不是新地址，也不是已经完成的配置变更。
  • 手工设置地址、仅用 DHCP 获取其他参数的主机，应以 DHCPINFORM 回应；扩展不应越过手工配置的边界。协议名称中的“强制”因此并不代表全面改写权。
  • 2012 年引入的 nonce 机制省去了事先向客户端分发密钥的步骤，主要约束无法观察正常交互的链路外攻击者。它保护后来的召回，不能替最初传送 nonce 的网络补上一条独立信任链。

那个不该被重新分配的地址

一台主机的地址由人手工设定，但它仍向 DHCP 服务器查询其他本地参数。后来，服务器发来一个名字很强硬的消息：FORCERENEW。主机是否就应交出原来的地址，接受服务器的新安排？

2001 年 12 月的 RFC 3203 给出的答案没有那么宽。这样的客户端应再发一次 DHCPINFORM，获取可能变化的其他参数；能够改变的仍是适合由 DHCP 配置的选项，不应覆盖手工设置。一个主动召回机制，在抵达主机时依然受原有配置边界约束。

这不是无关紧要的例外。它把扩展所增加的能力照得很清楚：服务器终于可以让对方提前回来问，但不能把“回来问”直接等同于“照我说的全部改”。即使地址本来就是租来的，FORCERENEW 也不是装着替代地址的一纸新租约。

互联网的配置往往有两个时钟。一个属于正在运行的设备：现有参数还能用，租期也没有要求它立刻行动。另一个属于管理者：服务已经调整，某个参数应该刷新，或者一次迁移希望现在启动。两只时钟不同步，并不意味着客户端已经失效。管理者需要的是一次新的交互机会。

新增的是入口，不是另一套配置流程

1997 年的 RFC 2131 已规定客户端如何申请、续租和重新寻找服务器，也允许客户端在 T1 之前自行续租。因此，FORCERENEW 的新意不是“DHCP 从此可以提前更新”，而是提前行动可以由服务器发起。

RFC 3203 规定，服务器向客户端单播通知。客户端收到后进入续租状态，按通常程序发出 DHCPREQUEST。接下来才是服务器的回应，以及客户端对回应的处理。扩展特意复用既有状态，而没有给客户端另加一套状态机。

如果服务器希望更换客户端的地址，文档描述的路径还要多走几步：在随后的请求中回复 DHCPNAK，客户端回到初始化状态，再广播 DHCPDISCOVER，服务器通过 DHCPOFFER 提供地址。最初那条通知没有替这些动作作证。它可能只导致普通续租，也可能开启更长的重新配置过程。

这一顺序决定了故障应该怎样描述。看见 FORCERENEW 发出，只能说明有人试图触发流程；看见客户端的请求，说明流程往前走了一步；看见后续确认，还要区分主机已接受什么、应用是否真的适应了变化。把第一条消息的发送记录计作一次成功迁移，会把最容易出问题的中间部分删掉。

消息的新身份也有明确位置。RFC 2132 中的选项 53 用来表示 DHCP 消息类型，RFC 3203 在这个取值空间加入了 9。9 不是认证选项号，更不是一个新的传输端口。复用消息外壳和状态机，是让新增入口尽量小，而不是让所有旧客户端自动获得新能力。

没有回来，不能靠多发几次证明回来过

服务器没有等到预期请求时，可以重发通知，采用指数退避，并限制重试次数。RFC 3203 把最初等待多久留给网络条件，没有规定一个适用于所有部署的固定数值。它还明确要求客户端静默丢弃收到的组播 FORCERENEW，而正常触发路径使用单播。

这里有一个重要的不对称：服务器决定何时敲门，却不能单凭敲门的次数判断里面发生了什么。请求缺席，可能涉及丢包、客户端状态、能力差异或消息被拒绝；它本身并不指出哪一种解释成立。重试是恢复手段，不是新的证据等级。

文档列举家庭网关服务调整、旅馆网络服务选择以及受控条件下的子网重新编号。这些例子说明设计者想打开哪些操作空间，不是这些场景已经普遍部署的统计。尤其是重新编号，客户端一个接一个被召回，不代表正在进行的会话也能无缝跟随。

RFC 3203 明言，改变地址或本地参数可能中断活动会话，应在受控条件下使用。通知格式再规范，也无法证明此刻变更对业务是合适的。让设备听见召回，是协议能力；判断是否值得打断它，是另一项责任。

为什么连一声召回都需要认证

如果不受约束的一方可以决定客户端什么时候重新发出请求，它得到的就不只是制造一点噪声的机会。原本由客户端自行安排的交互，变成了可以由别人挑选时点的事件。RFC 3203 因而要求 FORCERENEW 使用 DHCP 认证程序，认证失败则丢弃。

其引用的 RFC 3118 早于这项扩展数月，发表于 2001 年 6 月。该文档并非只有一种强度完全相同的机制：简单的配置令牌以明文传递，只能提供很弱的实体匹配，不能认证整个消息；延迟认证则依赖共享秘密和消息认证码。把两者都称作“已认证”，会抹平它们实际能证明的内容。

延迟认证还有部署前提。秘密需要通过 DHCP 交换以外的渠道交给参与者；如果要逐个认证客户端，就要安排相应的密钥关系。对管理者而言，服务器发一条短消息之前，可能先要维护一套分发和保存秘密的工作。

2012 年 8 月的 RFC 6704 正是从这个成本出发。作者认为，原有要求比特定召回场景所需的更严格，并限制了 FORCERENEW 的采用。这是那份文档对当时问题的判断，不能被改写成今天的部署比例，也不能据此猜测任何厂商当前支持到了哪一步。

先留下一份秘密，后来再认得那声召回

新的办法借鉴了 2003 年 DHCPv6 文档 RFC 3315 的 Reconfigure Key 思路。引用的是这个历史机制，不是把整个 DHCPv6 协议搬进 IPv4，也不是把已经被替代的文档当成今天的完整实施指南。

在 RFC 6704 的流程中，双方没有使用原来的 DHCP 认证机制，并且已经协商使用 nonce 方式，服务器才启用它。客户端在 DISCOVER 和 REQUEST 中声明支持；服务器在 OFFER 中表明相应能力或选择。能力声明与后来的认证信息不是同一回事，客户端不能把这种 nonce 协议的认证选项放进自己发送的 DHCP 消息。

接着，服务器在适当的 REQUEST／ACK 交换中生成一个 128 位、具有足够随机性的 nonce，随 ACK 交给客户端保存。以后发 FORCERENEW 时，它不再把秘密重新亮出来，而是用保存的值作为密钥生成消息认证码。客户端用自己的副本核验。

这使部署更容易的原因相当具体：不必先通过另一条分发渠道把召回所需的秘密交给每台客户端。代价也同样具体：最初传送秘密的配置交换，成为后来判断通知的基础。

能力协商不能省略。没有声明支持的客户端，不应收到服务器擅自加进 ACK 的相应 nonce 认证选项。初次选择过程中，若 OFFER 已声明采用该机制，随后 ACK 却缺少有效的对应认证选项，客户端应丢弃它并回到初始化。这是在检查双方刚才的约定是否得到执行，不是在凭空认证第一次接触的服务器身份。

名字叫 nonce，也不代表每次用完即废

这个随机值会被双方保存，并不因一次 FORCERENEW 就自动耗尽。RFC 6704 的规范文字说，普通续租的 ACK 不应重复发送 nonce，除非生成了新值；不能因为示意图在一次续租后画了新 nonce，就推断每次续租都必须轮换。

当重新绑定换到另一台服务器时，新服务器必须生成自己的值。若客户端支持这种能力，但服务器没有此前的 nonce 记录，也需要建立相应状态。秘密的生命周期于是和客户端、服务器及它们的交互历史有关，不能仅从“每条消息都有认证字段”推断状态一直正确。

认证码和新鲜度又是两件事。这里描述的历史算法是 HMAC-MD5，而不是加密通道；协议另外携带重放检测信息。RFC 3118 的已核实勘误 3474 在 2013 年澄清，计数值必须严格增加。一个旧消息的认证码仍然能够通过数学检验，不意味着它再次出现就应当被当作新通知。

这些约束共同说明，客户端不是认出某个固定标记就无条件行动。它依赖的是已保存的秘密、收到的消息、重放状态以及此前的能力约定。丢失其中一部分，可能表现为召回失灵，也可能诱使管理者错误地放宽检查。

保护的是谁看不见的那段交互

RFC 6704 明确讨论的，是不能观察正常客户端与服务器交互的链路外攻击者。对这类对手，不知道初次传下来的 nonce，就难以伪装成服务器，在自己选定的时间把客户端叫回来。

但这不能反推首次交换已经可信。能截获初始 nonce 的观察者，会破坏这项保护的前提；位于本地链路上的对手，本来就可以看到正常请求。协议没有把不可信的接入网络变成独立的身份认证设施，也没有给服务器补发一份行政授权证明。

即使无效通知最终被丢弃，核验它们也有资源成本。大量伪造消息仍可能压垮处理能力。这里应当看到的是一类攻击机会受到约束，而不是“启用认证以后，拒绝服务与配置劫持就都消失了”。

IANA 的 BOOTP 与 DHCP 参数登记 分别记录了消息类型 9、认证选项 90 和能力选项 145。共同的编号使双方能够解释相同的字段，却不能证明某台设备实现了扩展、完成了协商，或愿意接受某次维护安排。登记的是语言，不是一次变更的完成记录。

FORCERENEW 最值得保留的历史分寸，就在这些小边界里。服务器取得了主动开启下一轮谈话的能力；客户端仍按既有流程处理配置；较便宜的认证守住了一个有限的召回入口，却没有越过初始信任问题。任何一层的成功，都不能替下一层提前盖章。