跳到主要内容

19. DHCP 服务器发起的配置交换

  1. DHCP 服务器发起的配置交换

服务器发起配置交换, 以使 DHCP 客户端获取新地址和其他配置信息. 例如, 当 DHCP 域中的链路需要重新编号时, 管理员可以使用服务器发起的配置交换. 其他示例包括目录服务器位置变化, 增加打印等新服务, 以及有新软件可用.

19.1. 服务器行为

服务器发送 Reconfigure 消息, 使客户端立即与服务器发起 Renew/Reply 或 Information-request/Reply 消息交换.

19.1.1. Reconfigure 消息的创建和传输

服务器将 "msg-type" 字段设置为 RECONFIGURE. 服务器将 transaction-id 字段设置为 0. 服务器在 Reconfigure 消息中包含一个 Server Identifier option 和一个 Client Identifier option, 前者包含自身 DUID, 后者包含客户端 DUID.

服务器 MAY 包含 Option Request option, 以通知客户端哪些信息已经变化或新增. 特别是, 如果服务器希望客户端获取新的地址信息, 则服务器在 Option Request option 中指定 IA option. 如果服务器在 Option Request option 中标识 IA option, 则服务器 MUST 包含一个不含任何其他 sub-options 的 IA option, 用于标识客户端上每个需要重新配置的 IA.

由于存在针对 DHCP 客户端的拒绝服务攻击风险, Reconfigure 消息中强制要求使用安全机制. 服务器 MUST 在 Reconfigure 消息中使用 DHCP authentication.

服务器 MUST 包含 Reconfigure Message option (定义于第 22.19 节), 以选择客户端使用 Renew 消息还是 Information-Request 消息进行响应.

除非某个单独选项的定义中特别允许, 服务器 MUST NOT 在 Reconfigure 中包含任何其他选项.

服务器使用属于 DHCP 客户端且作用域足够的 IPv6 单播地址, 将每条 Reconfigure 消息发送给单个 DHCP 客户端. 如果服务器没有可用于直接向客户端发送 Reconfigure 消息的地址, 则服务器使用 Relay-reply 消息 (如第 20.3 节所述), 将 Reconfigure 消息发送给会把该消息中继给客户端的中继代理. 服务器可以通过其掌握的曾与服务器联系过的客户端信息, 或通过某个外部代理, 获得客户端地址以及在需要时获得适当的中继代理地址.

要重新配置多个客户端, 服务器向每个客户端单播一条单独消息. 服务器可以并发发起多个客户端的重新配置. 例如, 当先前的重新配置消息交换仍在进行时, 服务器可以向其他客户端发送 Reconfigure 消息.

Reconfigure 消息使客户端发起与服务器之间的 Renew/Reply 或 Information-request/Reply 消息交换. 服务器将从客户端收到 Renew 或 Information-request 消息 (以原始 Reconfigure 消息中指定者为准) 解释为满足该 Reconfigure 消息请求.

19.1.2. Reconfigure 消息的超时和重传

如果服务器在 REC_TIMEOUT 毫秒内没有收到来自客户端的 Renew 或 Information-request 消息, 服务器会重传 Reconfigure 消息, 将 REC_TIMEOUT 值加倍, 并再次等待. 服务器持续此过程, 直到已经进行了 REC_MAX_RC 次不成功尝试, 此时服务器 SHOULD 中止该客户端的重新配置过程.

REC_TIMEOUT 和 REC_MAX_RC 的默认值和初始值记录在第 5.5 节.

19.2. Renew 消息的接收

服务器按第 18.2.3 节和第 18.2.8 节所述生成 Reply 消息并发送给客户端, 其中包含配置参数选项.

即使客户端的 Renew 消息未请求这些 IA 和参数, 服务器也 MAY 在 Reply 消息中包含带有 IA 以及其他配置参数新值的选项.

19.3. Information-request 消息的接收

服务器按第 18.2.5 节和第 18.2.8 节所述生成 Reply 消息并发送给客户端, 其中包含配置参数选项.

即使客户端的 Information-request 消息未请求这些参数, 服务器也 MAY 在 Reply 消息中包含带有其他配置参数新值的选项.

19.4. 客户端行为

客户端在已通过 DHCP 获取配置信息的接口上, 接收发送到 UDP 端口 546 的 Reconfigure 消息. 这些消息可以在任何时间发送. 由于重新配置事件的结果可能影响应用层程序, 客户端 SHOULD 记录这些事件, 并 MAY 通过实现特定接口通知这些程序发生了变化.

19.4.1. Reconfigure 消息的接收

收到有效 Reconfigure 消息后, 客户端按 Reconfigure Message option (定义于第 22.19 节) 的指示, 使用 Renew 消息或 Information-request 消息进行响应. 客户端忽略收到的 Reconfigure 消息中的 transaction-id 字段. 在事务进行期间, 客户端静默丢弃其收到的任何 Reconfigure 消息.

DISCUSSION:

  Reconfigure 消息充当触发器, 指示客户端完成一次成功的消息交换. 一旦客户端收到 Reconfigure, 客户端就继续进行消息交换, 必要时重传 Renew 或 Information-request 消息. 客户端会忽略任何额外的 Reconfigure 消息, 直到该交换完成. 后续 Reconfigure 消息会使客户端发起新的交换.

  当存在重复或重传的 Reconfigure 消息时, 该机制如何工作? 重复消息会被忽略, 因为客户端在收到第一条 Reconfigure 后就会开始交换. 重传消息要么触发交换 (如果客户端未收到第一条 Reconfigure), 要么被忽略. 一旦服务器收到来自客户端的 Renew 或 Information-request 消息, 服务器就可以停止向该客户端重传 Reconfigure 消息.

  重复或重传的 Reconfigure 可能被充分延迟 (并乱序递送), 以至于在由原始 Reconfigure 发起的交换完成后才到达客户端. 在这种情况下, 客户端会发起一次冗余交换. 延迟和乱序递送的可能性小到可以忽略. 冗余交换的后果是效率降低, 而不是操作错误.

19.4.2. Renew 消息的创建和传输

响应 Reconfigure 时, 客户端完全按照第 18.1.3 节所述方式创建并发送 Renew 消息, 唯一例外是客户端将 Reconfigure 消息中的 Option Request option 和任何 IA options 复制到 Renew 消息中.

19.4.3. Information-request 消息的创建和传输

响应 Reconfigure 时, 客户端完全按照第 18.1.5 节所述方式创建并发送 Information-request 消息, 唯一例外是客户端包含一个 Server Identifier option, 其中带有客户端正在响应的 Reconfigure 消息中的标识符.

19.4.4. Renew 或 Information-request 消息的超时和重传

客户端使用与作为客户端发起配置交换的一部分生成的 Renew 或 Information-request 消息相同的变量和重传算法. 详情见第 18.1.3 节和第 18.1.5 节. 如果客户端在重传过程结束时仍未收到来自服务器的响应, 客户端忽略并丢弃该 Reconfigure 消息.

19.4.5. Reply 消息的接收

收到有效 Reply 消息后, 客户端处理其中的选项, 并适当地设置或重置配置参数. 客户端记录并更新 Reply 消息中 IA 指定的任何地址的生命周期.

最后于 更新