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

DHCP 服务器发起的配置交换

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

19.1. 服务器行为

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

19.1.1. Reconfigure 消息的创建与传输

服务器将 "msg-type" 字段设置为 RECONFIGURE. 服务器将 transaction-id 字段设置为 0. 服务器在 Reconfigure 消息中包含一条含有自身 DUID 的服务器标识符 (Server Identifier) 选项, 以及一条含有客户端 DUID 的客户端标识符 (Client Identifier) 选项.

服务器可以 (MAY) 包含一条选项请求 (Option Request) 选项, 以告知客户端哪些信息已改变或已添加新信息. 特别是, 如果服务器希望客户端获取新的地址信息, 它会在选项请求选项中指定 IA 选项. 如果服务器在选项请求选项中标识了 IA 选项, 服务器必须 (MUST) 包含一个不含任何其他子选项的 IA 选项, 以标识客户端上要被重新配置的每一个 IA.

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

服务器必须 (MUST) 包含一条 Reconfigure Message 选项 (在 22.19 节中定义), 以选择客户端是以 Renew 消息还是以 Information-Request 消息作出响应.

除各个选项的定义中明确允许的之外, 服务器不得 (MUST NOT) 在 Reconfigure 消息中包含任何其他选项.

服务器使用属于该 DHCP 客户端、具有足够范围的 IPv6 单播 (unicast) 地址, 将每条 Reconfigure 消息发送给单个 DHCP 客户端. 如果服务器没有可用于直接向客户端发送 Reconfigure 消息的地址, 服务器使用一条 Relay-reply 消息 (如第 20.3 节所述) 将该 Reconfigure 消息发送给一个中继代理, 由该代理将消息中继给客户端. 服务器可以通过它所掌握的、关于曾与该服务器有过联系的客户端的信息, 或通过某个外部代理, 来获取客户端的地址 (以及必要时的适当中继代理地址).

要重新配置多个客户端, 服务器向每个客户端分别单播一条单独的消息. 服务器可以 (MAY) 并发地发起对多个客户端的重新配置; 例如, 服务器可以在先前的重新配置消息交换仍在进行时, 向其他客户端发送 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 消息, 其中包含配置参数的选项.

服务器可以 (MAY) 在这条 Reply 消息中包含含有 IA 和其他配置参数新取值的选项, 即使这些 IA 和参数并未在客户端发来的 Renew 消息中被请求.

19.3. Information-request 消息的接收

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

服务器可以 (MAY) 在这条 Reply 消息中包含含有其他配置参数新取值的选项, 即使这些参数并未在客户端发来的 Information-request 消息中被请求.

19.4. 客户端行为

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

19.4.1. Reconfigure 消息的接收

在收到一条有效的 Reconfigure 消息后, 客户端以一条 Renew 消息或一条 Information-request 消息作出响应, 具体由 Reconfigure Message 选项 (在 22.19 节中定义) 所指示. 客户端忽略收到的 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 时, 客户端创建并发送 Renew 消息的方式, 与第 18.1.3 节所述完全相同, 唯一的例外是客户端将选项请求选项以及任何 IA 选项从 Reconfigure 消息复制到 Renew 消息中.

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

当响应一条 Reconfigure 时, 客户端创建并发送 Information-request 消息的方式, 与第 18.1.5 节所述完全相同, 唯一的例外是客户端包含一条含有客户端所响应之 Reconfigure 消息中标识符的服务器标识符选项.

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

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

19.4.5. Reply 消息的接收

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