17. DHCP 服务器搜寻

DHCP 服务器搜寻

本节描述客户端如何定位那些将为属于该客户端的 IA 分配地址的服务器.

客户端负责创建 IA, 并请求服务器向该 IA 分配 IPv6 地址. 客户端首先创建一个 IA 并为其分配一个 IAID. 然后客户端发送一条 Solicit 消息, 其中包含描述该 IA 的一个 IA 选项. 能够向该 IA 分配地址的服务器以一条 Advertise 消息响应客户端. 随后客户端发起一次配置交换, 如第 18 节所述.

如果客户端愿意接受在响应 Solicit 消息时带有已提交 (committed) 地址分配及其他资源的 Reply 消息, 客户端会在 Solicit 消息中包含一条 Rapid Commit 选项 (见 22.14 节).

17.1. 客户端行为

客户端使用 Solicit 消息来发现被配置为在客户端所连接的链路上分配地址或返回其他配置参数的 DHCP 服务器.

17.1.1. Solicit 消息的创建

客户端将 "msg-type" 字段设置为 SOLICIT. 客户端生成一个事务 ID (transaction ID), 并将该取值插入 "transaction-id" 字段.

客户端必须 (MUST) 包含一条客户端标识符 (Client Identifier) 选项, 以向服务器标识自身. 客户端包含它希望服务器为其分配地址的那些 IA 所对应的 IA 选项. 客户端可以 (MAY) 在 IA 中包含地址, 作为向服务器提示客户端有所偏好的地址. 除了在各个选项的定义中明确允许的情况外, 客户端不得 (MUST NOT) 在 Solicit 消息中包含任何其他选项.

客户端使用 IA_NA 选项来请求非临时地址的分配, 并使用 IA_TA 选项来请求临时地址的分配. DHCP 消息中可以包含 IA_NA 选项、IA_TA 选项, 或两者组合.

客户端应当 (SHOULD) 包含一条选项请求 (Option Request) 选项 (见 22.7 节), 以表明客户端感兴趣接收哪些选项. 客户端可以 (MAY) 额外包含那些在选项请求选项中标识的选项的实例, 并将数据取值作为提示提供给服务器, 说明客户端希望返回的参数取值.

如果客户端愿意接受来自服务器的 Reconfigure 消息, 客户端包含一条 Reconfigure Accept 选项 (见 22.20 节).

17.1.2. Solicit 消息的传输

客户端在该接口上发出的第一条 Solicit 消息必须 (MUST) 被延迟一段介于 0 与 SOL_MAX_DELAY 之间的随机时长. 在由 IPv6 邻居发现 (Neighbor Discovery) 发起 DHCP 的情况下发送 Solicit 消息时, 该延迟给出的是在 IPv6 邻居发现导致客户端调用有状态地址自动配置协议 (见 RFC 2462 第 5.5.3 节) 之后需要等待的时间量. 这一随机延迟将同时启动的客户端 (例如, 在一次停电之后) 去同步化.

客户端按照第 14 节传输消息, 使用以下参数:

  IRT   SOL_TIMEOUT

  MRT   SOL_MAX_RT

  MRC   0

  MRD   0

如果客户端在其 Solicit 消息中包含了 Rapid Commit 选项, 则一旦收到带有 Rapid Commit 选项的 Reply 消息, 客户端即终止等待过程.

如果客户端正在等待一条 Advertise 消息, 则第 14 节中的机制被修改如下, 以用于 Solicit 消息的传输. 在第一个 RT 经过之前, 收到 Advertise 消息并不终止消息交换. 相反, 客户端收集 Advertise 消息, 直到第一个 RT 经过. 此外, 必须 (MUST) 通过选择严格大于 0 的 RAND, 使第一个 RT 被选择为严格大于 IRT.

客户端必须 (MUST) 收集第一个 RT 秒内的 Advertise 消息, 除非它收到一条偏好值 (preference value) 为 255 的 Advertise 消息. 偏好值由 Preference 选项携载 (22.8 节). 任何未包含 Preference 选项的 Advertise 都被视为偏好值为 0. 如果客户端收到一条包含偏好值为 255 的 Preference 选项的 Advertise 消息, 客户端立即通过向收到该 Advertise 消息的服务器发送 Request 消息, 开始一次客户端发起的消息交换 (如第 18 节所述). 如果客户端收到的 Advertise 消息不包含偏好值为 255 的 Preference 选项, 客户端继续等待, 直到第一个 RT 经过. 如果第一个 RT 经过且客户端已收到 Advertise 消息, 客户端应当 (SHOULD) 通过发送 Request 消息继续进行客户端发起的消息交换.

如果客户端在第一个 RT 经过之前没有收到任何 Advertise 消息, 它开始第 14 节所述的重传机制. 一旦收到任何 Advertise 消息, 客户端即终止重传过程, 并对收到的 Advertise 消息采取行动, 而无需等待任何额外的 Advertise 消息.

DHCP 客户端应当 (SHOULD) 将 MRC 和 MRD 都选择为 0. 如果 DHCP 客户端被配置为 MRC 或 MRD 被设置为非 0 的某值, 那么一旦消息交换失败, 它必须 (MUST) 停止尝试配置该接口. 在 DHCP 客户端停止尝试配置该接口之后, 它应当 (SHOULD) 在某个外部事件 (例如用户输入、系统重启, 或客户端连接到了一条新链路) 之后重新启动重新配置过程.

17.1.3. Advertise 消息的接收

客户端必须 (MUST) 忽略任何包含状态码 (Status Code) 选项、且其中取值为 NoAddrsAvail 的 Advertise 消息, 但客户端可以 (MAY) 将该相关联的状态消息显示给用户.

在收到一条或多条有效的 Advertise 消息后, 客户端基于以下标准选择一条或多条 Advertise 消息.

服务器偏好值最高的那些 Advertise 消息优先于所有其他 Advertise 消息.
在一组具有相同服务器偏好值的 Advertise 消息中, 客户端可以 (MAY) 选择那些其 Advertise 消息播发了客户端感兴趣信息的服务器. 例如, 客户端可以选择返回了带有客户端感兴趣配置选项的 Advertise 的服务器.
如果某台服务器拥有更好的播发参数集 (例如在 IA 中播发的可用地址), 客户端可以 (MAY) 选择偏好较低的服务器.

一旦客户端选定了 Advertise 消息, 客户端通常会存储关于每台服务器的信息, 例如服务器偏好值、播发的地址、收到播发的时间等.

如果所选服务器不予响应, 客户端需要选择一台备用服务器, 则客户端根据上述标准选择下一台服务器.

17.1.4. Reply 消息的接收

如果客户端在 Solicit 消息中包含了 Rapid Commit 选项, 它将预期收到一条包含 Rapid Commit 选项的 Reply 消息作为响应. 客户端丢弃它收到的任何不包含 Rapid Commit 选项的 Reply 消息. 如果客户端收到一条有效的、包含 Rapid Commit 选项的 Reply 消息, 它按照第 18.1.8 节所述处理该消息. 如果它没有收到这样的 Reply 消息, 而确实收到了一条有效的 Advertise 消息, 客户端按照第 17.1.3 节所述处理该 Advertise 消息.

如果客户端随后收到一条有效的、包含 Rapid Commit 选项的 Reply 消息, 它会:

  按照第 18.1.8 节所述处理该 Reply 消息, 并丢弃为响应 Request 消息而收到的任何 Reply
  消息; 或

  处理为响应 Request 消息而收到的任何 Reply 消息, 并丢弃那条包含 Rapid Commit 选项的
  Reply 消息.

17.2. 服务器行为

服务器向它收到的有效 Solicit 消息发送 Advertise 消息, 以宣告该服务器对客户端可用.

17.2.1. Solicit 消息的接收

服务器如第 11 节所述确定关于客户端及其位置的信息, 并检查其关于响应该客户端的行政策略. 如果服务器不被允许响应客户端, 服务器丢弃该 Solicit 消息. 例如, 如果服务器的行政策略是它只能响应愿意接受 Reconfigure 消息的客户端, 而客户端在 Solicit 消息中用 Reconfigure Accept 选项表明它不会接受 Reconfigure 消息, 则服务器丢弃该 Solicit 消息.

如果客户端在 Solicit 消息中包含了 Rapid Commit 选项, 且服务器已被配置为以已提交的地址分配及其他资源作出响应, 服务器按照第 17.2.3 节所述以 Reply 消息响应 Solicit. 否则, 服务器忽略 Rapid Commit 选项, 并如同不存在 Rapid Commit 选项一样处理消息的其余部分.

17.2.2. Advertise 消息的创建与传输

服务器将 "msg-type" 字段设置为 ADVERTISE, 并将从客户端收到的 Solicit 消息中的 transaction-id 字段内容, 复制到 Advertise 消息中. 服务器在其服务器标识符 (Server Identifier) 选项中包含自身的服务器标识符, 并将 Solicit 消息中的客户端标识符 (Client Identifier) 复制到 Advertise 消息中.

服务器可以 (MAY) 添加一条 Preference 选项来携载该 Advertise 消息的偏好值. 服务器实现应当 (SHOULD) 允许管理员设置服务器偏好值. 除非服务器管理员另有配置, 服务器偏好值必须 (MUST) 默认为零.

如果服务器希望要求客户端接受 Reconfigure 消息, 服务器包含一条 Reconfigure Accept 选项.

服务器包含它将在随后的 Reply 消息中返回给客户端的选项. 如果客户端收到多于一条 Advertise 消息, 这些选项中的信息可被客户端用于服务器的选择. 如果客户端在 Solicit 消息中包含了选项请求 (Option Request) 选项, 服务器在 Advertise 消息中包含那些在选项请求选项中标识的、且服务器已被配置为要返回给客户端的所有选项的配置参数. 如果服务器已被如此配置, 它可以 (MAY) 向客户端返回额外的选项. 服务器必须意识到 RFC 2460 第 5 节中关于数据包大小以及分片使用的建议.

如果来自客户端的 Solicit 消息包含了一个或多个 IA 选项, 服务器必须 (MUST) 在 Advertise 消息中包含 IA 选项, 其中含有将被分配给客户端 Solicit 消息中那些 IA 的任何地址. 如果客户端在 Solicit 消息的 IA 中包含了地址, 服务器将这些地址用作关于客户端希望接收的地址的提示.

如果服务器不会在客户端随后的 Request 中向任何 IA 分配任何地址, 服务器必须 (MUST) 向客户端发送一条 Advertise 消息, 其中仅包含一个状态码 (Status Code) 选项 (其取值为 NoAddrsAvail, 并带有给用户的 status message)、一个带有服务器 DUID 的服务器标识符选项, 以及一个带有客户端 DUID 的客户端标识符选项.

如果 Solicit 消息是由服务器直接收到的, 服务器使用收到 Solicit 消息的那个 IP 数据报的源地址字段中的地址, 将 Advertise 消息单播 (unicast) 直接发给客户端. Advertise 消息必须 (MUST) 在收到 Solicit 消息的那条链路上被单播.

如果 Solicit 消息是在 Relay-forward 消息中收到的, 服务器构造一条 Relay-reply 消息, 并将 Advertise 消息置于一条 "relay-message" 选项的载荷中. 如果 Relay-forward 消息包含了一条 Interface-id 选项, 服务器将该选项复制到 Relay-reply 消息中. 服务器使用收到 Relay-forward 消息的那个 IP 数据报的源地址字段中的地址, 将 Relay-reply 消息单播直接发给该中继代理.

17.2.3. Reply 消息的创建与传输

在向客户端发送 Reply 消息以响应 Solicit 消息之前, 服务器必须 (MUST) 已提交任何地址或其他配置信息消息的分配.

讨论 (DISCUSSION):

  当使用 Solicit-Reply 消息交换时, 服务器在发送 Reply 消息之前提交任何地址的分配. 客户端
  可以假定它已被分配了 Reply 消息中的地址, 并且无需为那些地址发送 Request 消息.

  通常, 被配置为使用 Solicit-Reply 消息交换的服务器会被部署为只有一台服务器响应 Solicit
  消息. 如果有多台服务器响应, 客户端将只使用其中一台服务器的地址, 而来自其他服务器的地址
  虽被提交给客户端但不会被客户端使用.

服务器在 Reply 消息中包含一条 Rapid Commit 选项, 以表明该 Reply 是响应 Solicit 消息的.

如果服务器希望要求客户端接受 Reconfigure 消息, 服务器包含一条 Reconfigure Accept 选项.

如同它已收到一条 Request 消息那样 (如第 18.2.1 节所述), 服务器生成该 Reply 消息. 服务器按照第 18.2.8 节所述传输该 Reply 消息.