摘要

  • RFC 3315 允许 DHCPv6 客户端请求以 Solicit–Reply 取代通常的 Solicit–Advertise–Request–Reply，但服务器仍可按自己的配置拒绝快速路径。
  • Rapid Commit 下，服务器先提交租约再发送 Reply；多个服务器可能都占用地址而客户端只使用其中一方的租约，回复丢失也会造成服务器记录与客户端已收到信息之间的落差。

四报文流程中的停顿承担着一项具体工作。客户端发出 Solicit 后，可以接收多个 Advertise，比较服务器提供的配置，再通过 Request 选择其一，最后收到 Reply 确认。RFC 3315 于 2003 年发布，给 IPv6 定义有状态配置协议，也为这段过程设计了一条短路。但短路不是默认规则。

客户端可在 Solicit 中放入长度为零的 Rapid Commit 选项，表示愿意直接收到 Reply。这个选项表达的是客户端的意愿，并不替服务器做决定。服务器仍须依据自身管理策略和配置判断，是否准备好立即提交地址及其他资源。若不接受，它可以忽略该选项并返回 Advertise，客户端仍可走常规的服务器选择流程；若接受，服务器会在 Reply 发出前提交租约。

顺序的变化带来了速度，也改变了服务端需要承担的风险。客户端收到有效且含 Rapid Commit 的 Reply 后，不必再发送 Request 即可使用其中的配置。服务器却没有随后一道确认，知道客户端是否实际收到了这份 Reply。RFC 3315 特别指出：如果多个服务器都回复同一条快速提交 Solicit，它们可能各自提交地址，而客户端最终只用其中一台服务器的租约。其他租约虽已提交，却没人使用。若 Reply 在途中丢失，服务器也可能保留一条客户端无法据以行动的提交记录。

因此，省去 Advertise 和 Request 并没有消除不确定性，而是搬动了它。四报文路线让客户端先看到候选项，再明确选择；两报文路线让服务端先提交，客户端事后依据收到的 Reply 接受配置。当多个响应者能独立决策时，地址池可能在服务器尚不知道客户端选择和接收结果前就被占用。这并不能证明发生了地址冲突，也不意味着每条闲置租约都会造成实际危害，但它确实改变了分配资源的时间边界。

RFC 3315 建议，采用 Solicit–Reply 的部署通常应安排只有一台服务器响应；较短的初始租期也可以缩小未使用分配的影响。这些是运维设计选择，不是对单服务器拓扑或共享状态的保证。Rapid Commit 因而适合在响应者集合可控、快速配置收益明确的环境中启用，而不是只看报文少两条就视为白赚。

2005 年的 RFC 4039 将类似 Rapid Commit 机制带入 DHCPv4，指出在接入点频繁变化的高移动性环境中，快速配置可能有价值；它同时强调四报文流程允许多台服务器先提供暂定选项，待客户端选择后才正式分配。2018 年 RFC 8415 汇总了 DHCPv6，2026 年取代它的 RFC 9915 仍保留同一机制与多响应者可能留下未使用租约的警告。标准的延续证明这一控制面取舍长期存在，却不能证明其普及率、实际启动耗时或真实事故数量。

这段历史不只是“减少延迟”的优化案例。关键在于：资源何时被提交、哪些服务器有权在没有客户端确认的情况下提交，以及两端依据什么证据认定地址已到达并被使用。少一轮交换，也少了一次选择和确认的机会。

来源：RFC 3315、RFC 4039、RFC 8415 与 RFC 9915。