跳到主要内容

17. DHCP 服务器征求

  1. DHCP 服务器征求

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

客户端负责创建 IA, 并请求服务器为该 IA 分配 IPv6 地址. 客户端首先创建一个 IA, 并为其分配 IAID. 然后客户端传输一条包含 IA option 的 Solicit 消息, 该 IA option 描述该 IA. 能够为该 IA 分配地址的服务器使用 Advertise 消息响应客户端. 随后客户端按第 18 章所述发起配置交换.

如果客户端愿意接受服务器为响应 Solicit 消息而返回的, 包含已提交地址分配和其他资源的 Reply 消息, 则客户端在 Solicit 消息中包含 Rapid Commit option (见第 22.14 节).

17.1. 客户端行为

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

17.1.1. Solicit 消息的创建

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

客户端 MUST 包含 Client Identifier option, 以向服务器标识自身. 客户端为希望服务器分配地址的任何 IA 包含 IA options. 客户端 MAY 在 IA 中包含地址, 作为向服务器提示客户端偏好地址的信息. 除非某个单独选项的定义中特别允许, 客户端 MUST NOT 在 Solicit 消息中包含任何其他选项.

客户端使用 IA_NA options 请求分配非临时地址, 并使用 IA_TA options 请求分配临时地址. DHCP 消息中可以包含 IA_NA options 或 IA_TA options, 或二者组合.

客户端 SHOULD 包含 Option Request option (见第 22.7 节), 以指示客户端希望接收的选项. 客户端还 MAY 包含 Option Request option 中所标识的那些选项实例, 并在其中提供数据值, 作为向服务器提示客户端希望返回哪些参数值的信息.

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

17.1.2. Solicit 消息的传输

客户端在该接口上发送的第一条 Solicit 消息 MUST 延迟一个介于 0 和 SOL_MAX_DELAY 之间的随机时间量. 对于在 IPv6 Neighbor Discovery 启动 DHCP 时传输的 Solicit 消息, 该延迟表示在 IPv6 Neighbor Discovery 使客户端调用有状态地址自动配置协议之后需要等待的时间量 (见 RFC 2462 第 5.5.3 节). 这个随机延迟会使同时启动的客户端去同步化, 例如断电后恢复供电时.

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

  IRT   SOL_TIMEOUT

  MRT   SOL_MAX_RT

  MRC   0

  MRD   0

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

如果客户端正在等待 Advertise 消息, 则第 14 章中的机制在用于传输 Solicit 消息时按如下方式修改. 消息交换不会因在第一个 RT 到期前收到 Advertise 而终止. 相反, 客户端会收集 Advertise 消息, 直到第一个 RT 到期. 另外, 第一个 RT MUST 通过选择严格大于 0 的 RAND 来选取为严格大于 IRT.

客户端 MUST 在第一个 RT 秒内收集 Advertise 消息, 除非它收到 preference 值为 255 的 Advertise 消息. preference 值承载在 Preference option (第 22.8 节) 中. 任何未包含 Preference option 的 Advertise 都被视为 preference 值为 0. 如果客户端收到一条 Advertise 消息, 其中包含 Preference option 且 preference 值为 255, 则客户端立即通过向发送该 Advertise 消息的服务器发送 Request 消息, 开始一次客户端发起的消息交换 (如第 18 章所述). 如果客户端收到的 Advertise 消息未包含 preference 值为 255 的 Preference option, 则客户端继续等待, 直到第一个 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 option 且其中值为 NoAddrsAvail 的 Advertise 消息, 但客户端 MAY 向用户显示相关状态消息.

收到一个或多个有效 Advertise 消息后, 客户端按以下准则选择一个或多个 Advertise 消息.

  • 与所有其他 Advertise 消息相比, 具有最高 server preference 值的 Advertise 消息更优先.

  • 在具有相同 server preference 值的一组 Advertise 消息内, 客户端 MAY 选择那些 Advertise 消息通告了客户端感兴趣信息的服务器. 例如, 客户端可以选择返回了客户端感兴趣配置选项的通告的服务器.

  • 如果某个较低优先级服务器具有更好的已通告参数集合, 例如 IA 中通告的可用地址, 客户端 MAY 选择该服务器.

一旦客户端选定 Advertise 消息, 客户端通常会存储关于每个服务器的信息, 例如 server preference 值, 已通告地址, 收到该通告的时间等.

如果在已选择服务器不响应的情况下客户端需要选择备用服务器, 客户端按上述准则选择下一个服务器.

17.1.4. Reply 消息的接收

如果客户端在 Solicit 消息中包含 Rapid Commit option, 它将期望收到响应中包含 Rapid Commit option 的 Reply 消息. 客户端丢弃其收到的任何未包含 Rapid Commit option 的 Reply 消息. 如果客户端收到一条有效的 Reply 消息且其中包含 Rapid Commit option, 它按第 18.1.8 节所述处理该消息. 如果未收到这样的 Reply 消息, 但收到一条有效的 Advertise 消息, 客户端按第 17.1.3 节所述处理该 Advertise 消息.

如果客户端随后收到一条有效的 Reply 消息且其中包含 Rapid Commit option, 则它执行以下二者之一:

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

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

17.2. 服务器行为

服务器为响应其收到的有效 Solicit 消息而发送 Advertise 消息, 以向客户端宣布该服务器可用.

17.2.1. Solicit 消息的接收

服务器按第 11 章所述确定客户端及其位置相关信息, 并检查其关于响应该客户端的管理策略. 如果服务器不允许响应该客户端, 则服务器丢弃该 Solicit 消息. 例如, 如果服务器的管理策略规定它只能响应愿意接受 Reconfigure 消息的客户端, 而客户端在 Solicit 消息中通过 Reconfigure Accept option 指示其不会接受 Reconfigure 消息, 则服务器丢弃该 Solicit 消息.

如果客户端在 Solicit 消息中包含 Rapid Commit option, 且服务器已配置为使用已提交的地址分配和其他资源进行响应, 则服务器按第 17.2.3 节所述使用 Reply 消息响应该 Solicit. 否则, 服务器忽略 Rapid Commit option, 并像不存在 Rapid Commit option 一样处理消息的其余部分.

17.2.2. Advertise 消息的创建和传输

服务器将 "msg-type" 字段设置为 ADVERTISE, 并将从客户端收到的 Solicit 消息中的 transaction-id 字段内容复制到 Advertise 消息. 服务器在 Server Identifier option 中包含自身的 server identifier, 并将 Solicit 消息中的 Client Identifier 复制到 Advertise 消息.

服务器 MAY 添加 Preference option, 用来承载 Advertise 消息的 preference 值. 服务器实现 SHOULD 允许管理员设置 server preference 值. 除非服务器管理员另行配置, server preference 值 MUST 默认为零.

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

服务器包含其将在后续 Reply 消息中返回给客户端的选项. 如果客户端收到多个 Advertise 消息, 这些选项中的信息可供客户端用于服务器选择. 如果客户端在 Solicit 消息中包含 Option Request option, 则服务器在 Advertise 消息中包含一些选项, 这些选项为 Option Request option 标识的, 且服务器已配置为向客户端返回的所有选项提供配置参数. 如果服务器已配置为这样做, 服务器 MAY 向客户端返回额外选项. 服务器必须了解 RFC 2460 第 5 章中关于报文大小和分片使用的建议.

如果来自客户端的 Solicit 消息包含一个或多个 IA options, 则服务器 MUST 在 Advertise 消息中包含 IA options, 其中包含将分配给客户端 Solicit 消息中所含 IA 的任何地址. 如果客户端在 Solicit 消息的 IA 中包含地址, 服务器将这些地址用作关于客户端希望接收地址的提示.

如果服务器不会在客户端后续 Request 中向任何 IA 分配任何地址, 则服务器 MUST 向客户端发送一条 Advertise 消息, 该消息仅包含代码为 NoAddrsAvail 且带有用户状态消息的 Status Code option, 一个带有服务器 DUID 的 Server Identifier option, 以及一个带有客户端 DUID 的 Client Identifier option.

如果 Solicit 消息由服务器直接接收, 服务器使用接收该 Solicit 消息的 IP 数据报中源地址字段内的地址, 直接向客户端单播 Advertise 消息. Advertise 消息 MUST 在接收 Solicit 消息的链路上单播.

如果 Solicit 消息是在 Relay-forward 消息中接收的, 服务器构造一条 Relay-reply 消息, 并在 "relay-message" option 的 payload 中放入 Advertise 消息. 如果 Relay-forward 消息包含 Interface-id option, 服务器将该选项复制到 Relay-reply 消息. 服务器使用接收该 Relay-forward 消息的 IP 数据报中源地址字段内的地址, 直接向中继代理单播 Relay-reply 消息.

17.2.3. Reply 消息的创建和传输

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

DISCUSSION:

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

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

服务器在 Reply 消息中包含 Rapid Commit option, 以指示该 Reply 是对 Solicit 消息的响应.

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

服务器像已收到 Request 消息一样生成 Reply 消息, 如第 18.2.1 节所述. 服务器按第 18.2.8 节所述传输 Reply 消息.

最后于 更新