跳到主要内容

18. DHCP 配置交换 (DHCP Configuration Exchanges)

客户端发起与一个或多个服务器之间的消息交换, 以获取或更新其关注的配置信息. 客户端发起配置交换有很多原因. 较常见的原因包括:

  1. 作为操作系统配置/引导过程的一部分.

  2. 在应用层请求这样做时, 通过特定于操作系统的 API.

  3. 当路由器通告 (Router Advertisement) 指示 DHCPv6 可用于地址配置时, 见 [RFC4861] 第 4.2 节.

  4. 按需要使用 Renew 和 Rebind 消息延长地址和/或委派前缀的生命周期.

  5. 在收到 Reconfigure 消息时, 按服务器要求这样做.

客户端负责创建 IA, 并请求服务器为这些 IA 分配地址和/或委派前缀. 客户端首先创建 IA 并为其分配 IAID. 然后, 客户端发送包含 IA options 的 Solicit 消息, 这些 IA options 描述相应 IA. 客户端禁止正在使用它试图通过发送 Solicit 消息获取绑定的任何地址或委派前缀. 特别是, 如果客户端已有一些有效绑定, 并选择启动服务器发现过程以从另一台服务器获取相同绑定, 则客户端必须停止使用它从先前服务器获得且现在试图从新服务器获得的这些绑定中的地址和委派前缀. 关于此上下文中"停止使用"的含义, 见第 18.2.7 节.

如果 DHCP 客户端不需要 DHCP 服务器为其分配 IP 地址或委派前缀, 则可以通过与 DHCP 服务器的一次消息和回复交换来获取配置信息, 例如可用 DNS 服务器 [RFC3646] 或 NTP 服务器 [RFC5908] 列表. 为获取配置信息, 客户端首先向 All_DHCP_Relay_Agents_and_Servers 多播地址发送 Information-request 消息, 见第 18.2.6 节. 服务器使用包含客户端配置信息的 Reply 消息进行响应, 见第 18.3.6 节.

为请求分配一个或多个地址或委派前缀, 客户端首先定位 DHCP 服务器, 然后从该服务器请求分配地址/前缀以及其他配置信息. 客户端通过向 All_DHCP_Relay_Agents_and_Servers 多播地址发送 Solicit 消息并收集响应服务器返回的 Advertise 消息来完成此过程, 见第 18.2.1 节. 随后客户端选择它希望从中获取配置信息的服务器. 此过程称为服务器发现 (server discovery). 客户端选择服务器后, 按第 18.2.2 节所述向该服务器发送 Request 消息.

愿意执行第 18.2.1 节所述 Solicit/Reply 消息交换的客户端, 在其 Solicit 消息中包含 Rapid Commit option, 见第 21.14 节.

能够为 IA 分配地址或委派前缀的服务器用 Advertise 消息响应客户端. 如果客户端包含 Rapid Commit option 且服务器配置为接受该选项, 服务器也可以用 Reply 消息响应.

如果服务器用 Advertise 消息响应, 客户端按第 18.2.2 节所述发起配置交换.

服务器可以通过向客户端发送 Reconfigure 消息来发起消息交换, 促使客户端在收到 Reconfigure 消息后尽快发送 Renew, Rebind 或 Information-request 消息以刷新其配置信息.

图 9 展示了在一个或多个租约的典型生命周期中, 客户端与两台服务器之间交换消息的时间线图. 该过程从用于获得租约的四消息 Solicit/Advertise/Request/Reply 交换开始, 随后是用于延长租约生命周期的两消息 Renew/Reply 交换, 最后以用于结束客户端使用租约的两消息 Release/Reply 交换结束.

                Server                          Server
            (not selected)      Client        (selected)
                  v               v               v
                  |               |               |
                  |     Begins initialization     |
                  |               |               |
     start of     | _____________/|\_____________ |
     4-message    |/ Solicit      | Solicit      \|
     exchange     |               |               |
              Determines          |          Determines
             configuration        |         configuration
                  |               |               |
                  |\              |  ____________/|
                  | \________     | /Advertise    |
                  | Advertise\    |/              |
                  |           \   |               |
                  |      Collects Advertises      |
                  |             \ |               |
                  |     Selects configuration     |
                  |               |               |
                  | _____________/|\_____________ |
                  |/ Request      |  Request     \|
                  |               |               |
                  |               |     Commits configuration
                  |               |               |
     end of       |               | _____________/|
     4-message    |               |/ Reply        |
     exchange     |               |               |
                  |    Initialization complete    |
                  |               |               |
                  .               .               .
                  .               .               .
                  |   T1 (renewal) timer expires  |
                  |               |               |
     2-message    | _____________/|\_____________ |
     exchange     |/ Renew        |  Renew       \|
                  |               |               |
                  |               | Commits extended lease(s)
                  |               |               |
                  |               | _____________/|
                  |               |/ Reply        |
                  .               .               .
                  .               .               .
                  |               |               |
                  |      Graceful shutdown        |
                  |               |               |
     2-message    | _____________/|\_____________ |
     exchange     |/ Release      |  Release     \|
                  |               |               |
                  |               |         Discards lease(s)
                  |               |               |
                  |               | _____________/|
                  |               |/ Reply        |
                  |               |               |
                  v               v               v

图 9: 在一个或多个租约的典型生命周期中, 客户端与两台服务器之间交换消息的时间线图.

18.1. 用于多个 IA Options 的单次交换 (A Single Exchange for Multiple IA Options)​

本文假定客户端应当对一个接口上所需的所有 IA options 使用单个事务. 这会简化客户端实现, 并减少可能需要的事务数量. 为便于客户端对所有 IA options 使用单个事务, 服务器必须在 Reply 中为所有 IA options 返回相同的 T1/T2 值, 见第 18.3.2, 18.3.4 和 18.3.5 节, 使客户端在更新或重新绑定其租约时生成单个事务. 但是, 由于某些服务器可能尚未符合此要求, 客户端必须准备好按第 18.2.4 节所述选择适当的 T1/T2 时间.

18.2. 客户端行为 (Client Behavior)​

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

在地址和委派前缀的正常生命周期中, 客户端使用 Request, Renew, Rebind, Release 和 Decline 消息. 当客户端检测到自己可能已移动到新链路时, 如果它只有地址, 则使用 Confirm; 如果它有委派前缀以及地址, 则使用 Rebind. 当客户端需要配置信息但不需要地址和前缀时, 使用 Information-request 消息.

当客户端在 Solicit, Request, Renew 或 Rebind 中请求多个 IA option 类型或同一 IA 类型的多个实例时, 可用服务器可能只配置为提供其中的一个子集. 在可能的情况下, 客户端应当使用可用的最佳配置, 并在后续消息中继续请求额外 IA. 这允许客户端维护单个会话和状态机. 实践中, 特别是在处理 IA_NA 和 IA_PD 请求 [RFC7084] 时, 这种情况应当很少出现, 或者是临时操作错误的结果. 因此, 如果客户端在每次后续配置交换中继续请求其被编程为尝试获取的全部配置信息, 包括先前消息交换未返回结果的任何有状态配置选项, 它更有可能获得完整配置.

收到来自服务器的 Reconfigure 消息后, 客户端按照 Reconfigure Message option 指示, 使用 Renew, Rebind 或 Information-request 消息进行响应, 见第 21.19 节. 客户端应当对 Reconfigure 消息保持警惕, 因为它们可能被伪造, 并且客户端禁止放弃其可能已经获得的任何资源. 客户端应当将 Reconfigure 消息视为 T1 计时器已过期. 客户端将期待服务器在 Reply 消息中向其发送 IA 和/或其他配置信息.

18.2.1. Solicit 消息的创建和传输 (Creation and Transmission of Solicit Messages)​

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

客户端必须包含 Client Identifier option, 见第 21.2 节, 以向服务器标识自身. 对于客户端希望服务器为其分配租约的任何 IA, 客户端包含相应 IA options.

客户端必须包含 Elapsed Time option, 见第 21.9 节, 以指示客户端尝试完成当前 DHCP 消息交换已经持续了多长时间.

客户端使用 IA_NA options, 见第 21.4 节, 请求分配非临时地址, 并使用 IA_PD options, 见第 21.21 节, 请求前缀委派. DHCP 消息中可以包含 IA_NA 或 IA_PD options, 或二者组合. 此外, 任意 IA option 类型均可包含多个实例.

客户端可以在封装于 IA_NA option 内的 IA Address options 中包含地址, 作为向服务器提示客户端偏好的地址.

客户端可以在封装于 IA_PD options 内的 IA Prefix options 中包含值, 作为向服务器提示客户端偏好的委派前缀和/或前缀长度. 关于前缀长度提示的更多信息, 见第 18.2.4 节.

客户端必须包含 Option Request option (ORO), 见第 21.7 节, 以请求 SOL_MAX_RT option, 见第 21.24 节, 以及客户端有兴趣接收的任何其他 options. 客户端还可以包含在 Option Request option 中标识的这些 options 的实例, 并带有数据值, 作为向服务器提示客户端希望返回的参数值.

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

除非单个 option 的定义中特别允许, 客户端禁止在 Solicit 消息中包含任何其他 options.

客户端在接口上的第一个 Solicit 消息应当随机延迟 0 到 SOL_MAX_DELAY 之间的一段时间. 这种随机延迟有助于使同时启动 DHCP 会话的客户端去同步, 例如在电源故障恢复后, 或在路由器中断恢复并在 Router Advertisement 消息中看到 DHCP 可用之后, 见 [RFC4861] 第 4.2 节.

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

  • IRT: SOL_TIMEOUT

  • MRT: SOL_MAX_RT

  • MRC: 0

  • MRD: 0

希望使用 Rapid Commit 两消息交换的客户端在其 Solicit 消息中包含 Rapid Commit option, 见第 21.14 节. 客户端可能收到来自不同服务器的多个不同回复. 客户端会记录其收到的任何有效 Advertise 消息. 客户端会丢弃不包含 Rapid Commit option 的任何 Reply 消息.

收到带 Rapid Commit option 的有效 Reply 后, 客户端按第 18.2.10 节所述处理该消息.

在第一个 RT 周期结束时, 如果没有收到合适的 Reply 消息, 但客户端已有有效 Advertise 消息, 则客户端按第 18.2.9 节所述处理 Advertise.

如果客户端随后收到包含 Rapid Commit option 的有效 Reply 消息, 它执行以下操作之一:

  • 按第 18.2.10 节所述处理 Reply 消息, 并丢弃响应 Request 消息而收到的任何 Reply 消息.

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

如果客户端正在等待 Advertise 消息, 则第 15 节所述机制在用于传输 Solicit 消息时按如下方式修改. 消息交换不会因在第一个 RT 经过前收到 Advertise 而终止. 相反, 客户端会一直收集有效 Advertise 消息, 直到第一个 RT 经过. 此外, 必须通过选择严格大于 0 的 RAND, 使第一个 RT 被选为严格大于 IRT.

客户端必须在第一个 RT 秒内收集有效 Advertise 消息, 除非它收到偏好值为 255 的有效 Advertise 消息. 偏好值由 Preference option 携带, 见第 21.8 节. 任何未包含 Preference option 的有效 Advertise 均视为偏好值为 0. 如果客户端收到包含 Preference option 且偏好值为 255 的有效 Advertise 消息, 客户端立即通过向发送该 Advertise 消息的服务器发送 Request 消息来开始客户端发起的消息交换, 如第 18.2.2 节所述. 如果客户端收到的有效 Advertise 消息没有包含偏好值为 255 的 Preference option, 客户端继续等待直到第一个 RT 经过. 如果第一个 RT 经过且客户端已收到有效 Advertise 消息, 客户端应当通过发送 Request 消息继续进行客户端发起的消息交换.

如果客户端在第一个 RT 经过前没有收到任何有效 Advertise 消息, 则它应用第 15 节所述的重传机制. 客户端一收到任何有效 Advertise 消息即终止重传过程, 并对收到的 Advertise 消息采取操作, 而不等待任何额外 Advertise 消息.

DHCP 客户端应当选择 MRC 和 MRD 值为 0. 如果 DHCP 客户端配置了 MRC 或 MRD 且其值不是 0, 则当消息交换失败时, 它必须停止尝试配置该接口. DHCP 客户端停止尝试配置接口后, 应当在某些外部事件之后重新启动重新配置过程, 例如用户输入, 系统重启, 或客户端连接到新链路时.

18.2.2. Request 消息的创建和传输 (Creation and Transmission of Request Messages)​

客户端使用 Request 消息为 IA 填充租约并获取其他配置信息. 客户端在 Request 消息中包含一个或多个 IA options. 随后服务器在 Reply 消息中的 IA options 中向客户端返回租约以及有关 IA 的其他信息.

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

客户端必须在 Server Identifier option 中包含目标服务器的标识符, 见第 21.3 节.

客户端必须包含 Client Identifier option, 见第 21.2 节, 以向服务器标识自身. 客户端添加任何其他适当 options, 包括一个或多个 IA options.

客户端必须包含 Elapsed Time option, 见第 21.9 节, 以指示客户端尝试完成当前 DHCP 消息交换已经持续了多长时间.

客户端必须包含 Option Request option, 见第 21.7 节, 以请求 SOL_MAX_RT option, 见第 21.24 节, 以及客户端有兴趣接收的任何其他 options. 客户端还可以包含在 Option Request option 中标识的这些 options 的实例, 并带有数据值, 作为向服务器提示客户端希望返回的参数值.

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

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

  • IRT: REQ_TIMEOUT

  • MRT: REQ_MAX_RT

  • MRC: REQ_MAX_RC

  • MRD: 0

如果消息交换失败, 客户端根据本地策略采取操作. 客户端可能采取的操作示例包括:

  • 从客户端已知服务器列表中选择另一台服务器, 例如曾用 Advertise 消息响应的服务器.

  • 发起第 18 节所述的服务器发现过程.

  • 终止配置过程并报告失败.

18.2.3. Confirm 消息的创建和传输 (Creation and Transmission of Confirm Messages)​

当客户端检测到第 18.2.12 节所述网络信息发生变化时, 如果客户端只有 DHCP 服务器分配的地址而没有委派前缀, 则使用 Confirm 消息确定它是否仍连接到同一链路.

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

客户端必须包含 Client Identifier option, 见第 21.2 节, 以向服务器标识自身.

客户端必须包含 Elapsed Time option, 见第 21.9 节, 以指示客户端尝试完成当前 DHCP 消息交换已经持续了多长时间.

客户端为发送 Confirm 消息的接口上分配的所有 IA 包含 IA options. IA options 包含客户端当前与这些 IA 关联的所有地址. 客户端应当将任何 IA_NA options 中的 T1 和 T2 字段, 见第 21.4 节, 以及 IA Address options 中的 preferred-lifetime 和 valid-lifetime 字段, 见第 21.6 节, 设置为 0, 因为服务器会忽略这些字段.

客户端在接口上的第一个 Confirm 消息必须随机延迟 0 到 CNF_MAX_DELAY 之间的一段时间. 客户端按照第 15 节传输消息, 使用以下参数:

  • IRT: CNF_TIMEOUT

  • MRT: CNF_MAX_RT

  • MRC: 0

  • MRD: CNF_MAX_RD

如果在第 15 节所述消息传输过程终止前客户端未收到响应, 则客户端应当继续使用任何租约, 使用这些租约最后已知的生命周期, 并应当继续使用先前获得的任何其他配置参数.

18.2.4. Renew 消息的创建和传输 (Creation and Transmission of Renew Messages)​

为延长分配给 IA 的租约的首选生命周期和有效生命周期, 并为 IA 获取新地址或委派前缀, 客户端向获得这些租约的服务器发送 Renew 消息. Renew 消息包含其租约生命周期需要延长的 IA 的 IA options. 对于分配给 IA 的地址, 客户端在 IA_NA options, 见第 21.4 节, 内包含 IA Address options, 见第 21.6 节. 对于分配给 IA 的委派前缀, 客户端在 IA_PD options, 见第 21.21 节, 内包含 IA Prefix options, 见第 21.22 节.

服务器通过分配给 IA 的 T1 和 T2 值控制客户端应当联系服务器以延长已分配租约生命周期的时间. 但是, 由于客户端应当同时更新/重新绑定来自该服务器的所有 IA, 客户端必须从所有 IA options 中选择 T1 和 T2 时间, 以保证客户端发起 Renew/Rebind 消息传输的时间不晚于客户端任何绑定关联的 T1/T2 时间, 即最早 T1/T2.

在时间 T1, 客户端发起 Renew/Reply 消息交换, 以延长 IA 中任何租约的生命周期.

如果客户端先前与服务器交互所使用的链路本地地址不再有效, 且客户端愿意接收 Reconfigure 消息, 则客户端也必须在时间 T1 之前发起 Renew/Reply 消息交换. 这样会更新服务器的信息, 使其能够继续与客户端通信, 可以直接通信或经由 Relay-reply 消息通信.

如果服务器在先前 Reply 中为 IA_NA 或 IA_PD 将 T1 或 T2 设置为 0, 客户端可以自行决定分别发送 Renew 或 Rebind 消息. 客户端必须遵循第 14.2 节定义的规则.

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

客户端必须在 Renew 消息中包含 Server Identifier option, 见第 21.3 节, 以标识客户端最近通信过的服务器.

客户端必须包含 Client Identifier option, 见第 21.2 节, 以向服务器标识自身. 客户端添加任何适当 options, 包括一个或多个 IA options.

客户端必须包含 Elapsed Time option, 见第 21.9 节, 以指示客户端尝试完成当前 DHCP 消息交换已经持续了多长时间.

对于已分配租约的 IA, 客户端包含对应 IA option, 其中为分配给该 IA 的每个地址包含 IA Address option, 并为分配给该 IA 的每个前缀包含 IA Prefix option. 客户端禁止在任何 IA option 中包含客户端并非从服务器获得或已不再有效的地址和前缀, 即 valid lifetime 为 0 的地址和前缀.

客户端可以为每个它希望获得但未能获得的绑定包含 IA option. 在这种情况下, 如果客户端包含 IA_PD option 以请求前缀委派, 则客户端可以包含封装在 IA_PD option 内的 IA Prefix option, 并将 "IPv6-prefix" 字段设置为 0, 将 "prefix-length" 字段设置为期望委派前缀的长度. 服务器可以将该值用作前缀长度提示. 除非客户端提供前缀长度提示, 否则客户端不应包含 "IPv6-prefix" 字段设置为 0 的 IA Prefix option.

客户端包含 Option Request option, 见第 21.7 节, 以请求 SOL_MAX_RT option, 见第 21.24 节, 以及客户端有兴趣接收的任何其他 options. 客户端可以包含带有数据值的 options, 作为向服务器提示客户端希望返回的参数值.

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

  • IRT: REN_TIMEOUT

  • MRT: REN_MAX_RT

  • MRC: 0

  • MRD: 到最早 T2 的剩余时间

当到达最早时间 T2 时, 消息交换终止. 当客户端正在响应 Reconfigure 时, 客户端忽略并丢弃它可能收到的任何额外 Reconfigure 消息.

当到达最早时间 T2 时, 消息交换终止, 此时客户端开始 Rebind 消息交换, 见第 18.2.5 节.

18.2.5. Rebind 消息的创建和传输 (Creation and Transmission of Rebind Messages)​

在时间 T2, 仅当从时间 T1 开始向其发送 Renew 消息的服务器尚未响应时才会到达该时间, 客户端向任何可用服务器发起 Rebind/Reply 消息交换.

Rebind 也用于验证委派前缀绑定, 但使用第 18.2.3 节所述不同重传参数.

客户端按第 18.2.4 节所述构造 Rebind 消息, 但有以下差异:

  • 客户端将 "msg-type" 字段设置为 REBIND.

  • 客户端不在 Rebind 消息中包含 Server Identifier option, 见第 21.3 节.

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

  • IRT: REB_TIMEOUT

  • MRT: REB_MAX_RT

  • MRC: 0

  • MRD: 到所有 IA 中所有租约的 valid lifetime 均过期的剩余时间

如果某个 IA 的所有租约都已过期, 客户端可以选择在后续 Rebind 消息中包含此 IA, 以表示客户端有兴趣为此 IA 分配租约.

当所有 IA 中所有租约的 valid lifetime 均已过期时, 消息交换终止. 此时客户端使用 Solicit 消息定位新的 DHCP 服务器, 并向新服务器发送针对已过期 IA 的 Request. 如果终止的 Rebind 交换是因收到 Reconfigure 消息而发起的, 客户端终止重新配置过程, 并恢复到仿佛未收到 Reconfigure 消息一样的状态.

18.2.6. Information-request 消息的创建和传输 (Creation and Transmission of Information-request Messages)​

客户端使用 Information-request 消息获取配置信息, 而不请求分配地址和/或委派前缀.

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

客户端应当包含 Client Identifier option, 见第 21.2 节, 以向服务器标识自身. 但是, 关于客户端可能不希望包含此 option 的原因, 见 [RFC7844] 第 4.3.1 节. 如果客户端不包含 Client Identifier option, 服务器将无法向客户端返回任何特定于客户端的 options, 或者服务器可以选择完全不响应该消息.

客户端必须包含 Elapsed Time option, 见第 21.9 节, 以指示客户端尝试完成当前 DHCP 消息交换已经持续了多长时间.

客户端必须包含 Option Request option, 见第 21.7 节, 以请求 INF_MAX_RT option, 见第 21.25 节, Information Refresh Time option, 见第 21.23 节, 以及客户端有兴趣接收的任何其他 options. 客户端可以包含带有数据值的 options, 作为向服务器提示客户端希望返回的参数值.

当响应 Reconfigure 时, 客户端必须包含 Server Identifier option, 见第 21.3 节, 其标识符来自客户端正在响应的 Reconfigure 消息.

客户端在接口上的第一个 Information-request 消息必须随机延迟 0 到 INF_MAX_DELAY 之间的一段时间. 客户端按照第 15 节传输消息, 使用以下参数:

  • IRT: INF_TIMEOUT

  • MRT: INF_MAX_RT

  • MRC: 0

  • MRD: 0

18.2.7. Release 消息的创建和传输 (Creation and Transmission of Release Messages)​

为释放一个或多个租约, 客户端向服务器发送 Release 消息.

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

客户端必须在 Renew 消息中包含 Server Identifier option, 见第 21.3 节, 以标识分配租约的服务器.

客户端必须包含 Client Identifier option, 见第 21.2 节, 以向服务器标识自身.

客户端必须包含 Elapsed Time option, 见第 21.9 节, 以指示客户端尝试完成当前 DHCP 消息交换已经持续了多长时间.

客户端在 "options" 字段中包含带有其正在释放的租约所属 IA 的 options. 要释放的租约必须包含在 IA 中. 客户端希望继续使用的 IA 的任何租约禁止添加到这些 IA 中.

客户端必须在开始 Release 消息交换过程之前停止使用所有正在释放的租约. 对于地址, 这表示该地址必须已从接口移除. 对于委派前缀, 这表示该前缀必须已在 Router Advertisement 消息中以 Preferred Lifetime 和 Valid Lifetime 均为 0 进行通告, 如 [RFC4862] 第 5.5.3 节 (e) 部分所述. 另见 [RFC7084] 第 4.3 节中的要求 L-13.

客户端禁止在 Release 消息或任何随后传输的消息中, 将其正在释放的任何地址用作源地址.

由于 Release 消息可能丢失, 如果未收到 Reply, 客户端应重传 Release. 但是, 在某些场景中客户端可能不希望在放弃前等待正常重传超时, 例如断电时. 实现应当重传一次或多次, 但可以选择提前终止重传过程.

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

  • IRT: REL_TIMEOUT

  • MRT: 0

  • MRC: REL_MAX_RC

  • MRD: 0

如果租约已释放但来自 DHCP 服务器的 Reply 丢失, 客户端会重传 Release 消息, 服务器可能以指示 NoBinding 状态的 Reply 响应. 因此, 客户端不会将在 Release 消息交换中带有 NoBinding 状态的 Reply 消息视为表示错误.

注意, 如果客户端未能释放租约, 分配给 IA 的每个租约都会在该租约的 valid lifetime 过期时由服务器回收.

18.2.8. Decline 消息的创建和传输 (Creation and Transmission of Decline Messages)​

如果客户端检测到服务器分配给它的一个或多个地址已被另一个节点使用, 客户端向服务器发送 Decline 消息, 通知服务器该地址可疑.

Decline 消息不用于前缀委派. 因此, 客户端禁止在 Decline 消息中包含 IA_PD options, 见第 21.21 节.

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

客户端必须在 Decline 消息中包含 Server Identifier option, 见第 21.3 节, 以标识分配租约的服务器.

客户端必须包含 Client Identifier option, 见第 21.2 节, 以向服务器标识自身.

客户端必须包含 Elapsed Time option, 见第 21.9 节, 以指示客户端尝试完成当前 DHCP 消息交换已经持续了多长时间.

客户端在 "options" 字段中包含带有其正在拒绝地址所属 IA 的 options. 要拒绝的地址必须包含在 IA 中. 客户端希望继续使用的 IA 的任何地址不应添加到这些 IA 中.

客户端禁止在 Decline 消息或任何随后传输的消息中, 将其正在拒绝的任何地址用作源地址.

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

  • IRT: DEC_TIMEOUT

  • MRT: 0

  • MRC: DEC_MAX_RC

  • MRD: 0

如果地址已被拒绝但来自 DHCP 服务器的 Reply 丢失, 客户端会重传 Decline 消息, 服务器可能以指示 NoBinding 状态的 Reply 响应. 因此, 客户端不会将在 Decline 消息交换中带有 NoBinding 状态的 Reply 消息视为表示错误.

客户端不应仅因为发送了 Decline 消息就为其可能已收到的其他绑定发送 Release 消息. 客户端应当保留无冲突的绑定. 对于因冲突而未能获得绑定的情况, 客户端在发送 Renew 和 Rebind 消息时的行为应当视同未收到该绑定.

18.2.9. Advertise 消息的接收 (Receipt of Advertise Messages)​

收到一个或多个有效 Advertise 消息后, 客户端根据以下条件选择一个或多个 Advertise 消息.

  • 与所有其他 Advertise 消息相比, 应当优先选择服务器偏好值最高的 Advertise 消息. 如果某个偏好较低的服务器具有更好的已通告参数集, 例如可用 IA 集合以及已通告的其他配置 options 集合, 客户端可以选择该偏好较低的服务器.

  • 在服务器偏好值相同的一组 Advertise 消息中, 客户端可以选择其 Advertise 消息通告了客户端关注信息的服务器.

客户端一旦选择 Advertise 消息, 通常会存储有关每台服务器的信息, 例如服务器偏好值, 已通告地址, 收到通告的时间等.

实践中, 这表示客户端将为每台选定服务器维护独立的每 IA 状态机.

如果在所选服务器不响应时客户端需要选择备用服务器, 客户端按上述条件选择下一台服务器.

客户端必须处理 Advertise 消息中存在的任何 SOL_MAX_RT option, 见第 21.24 节, 以及 INF_MAX_RT option, 见第 21.25 节, 即使该消息包含指示失败的 Status Code option, 见第 21.13 节, 且该 Advertise 消息会被客户端丢弃. 只有当所有收到且包含对应 option 的 Advertise 消息都指定相同值时, 客户端才应当更新其 SOL_MAX_RT 和 INF_MAX_RT 值. 否则, 它应使用默认值, 见第 7.6 节.

客户端必须忽略任何既不包含地址, 即封装在 IA_NA options, 见第 21.4 节, 中的 IA Address options, 见第 21.6 节, 也不包含委派前缀, 即封装在 IA_PD options, 见第 21.21 节, 中的 IA Prefix options, 见第 21.22 节, 的 Advertise 消息. 例外是客户端:

  • 必须处理包含的 SOL_MAX_RT option.

  • 必须处理包含的 INF_MAX_RT option.

客户端可以在活动日志中记录任何关联状态消息, 或将其显示给用户.

忽略 Advertise 消息的客户端禁止重新启动 Solicit 重传计时器.

18.2.10. Reply 消息的接收 (Receipt of Reply Messages)​

收到响应以下消息的有效 Reply 消息后, 客户端提取顶层 Status Code option, 见第 21.13 节, 如果存在的话: 带 Rapid Commit option 的 Solicit, 见第 21.14 节, Request, Confirm, Renew, Rebind 或 Information-request 消息.

客户端必须处理 Reply 消息中存在的任何 SOL_MAX_RT option, 见第 21.24 节, 以及 INF_MAX_RT option, 见第 21.25 节, 即使该消息包含指示失败的 Status Code option.

如果客户端收到状态码为 UnspecFail 的 Reply 消息, 则服务器指示它因未指定的失败条件而无法处理客户端消息. 如果客户端向同一服务器重传原始消息以重试所需操作, 则客户端必须限制重传该消息的速率, 并限制重传该消息的持续时间, 见第 14.1 节.

否则, 即没有状态码或有其他状态码, 客户端根据收到 Reply 所对应的原始消息按下文处理 Reply.

客户端可以选择报告 Reply 消息中 Status Code option 的任何状态码或消息.

撤销先前分配的 options 这一主题在第 18.2.10.5 节讨论.

当客户端收到请求的 option, 且其值相比先前收到的值已有更新时, 客户端应当尽快将该更新值用于其配置信息.

18.2.10.1. 针对 Solicit (带 Rapid Commit), Request, Renew 或 Rebind 的 Reply (Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind)​

如果客户端在响应带 Rapid Commit option 的 Solicit, 见第 21.14 节, 或 Request 时从服务器收到 NotOnLink 状态, 客户端可以重新发出不指定任何地址的消息, 或重新启动 DHCP 服务器发现过程, 见第 18 节或第 18.2.13 节.

如果 Reply 是响应 Solicit (带 Rapid Commit option), Request, Renew 或 Rebind 消息而收到的, 客户端根据 Reply 消息中包含的 IA options 更新其记录的 IA 信息:

  • 如果适用于该 IA 类型, 计算 T1 和 T2 时间, 基于消息中发送的 T1 和 T2 值以及消息接收时间.

  • 将 IA option 中的任何新租约添加到客户端记录的 IA.

  • 更新 IA option 中客户端已记录于 IA 的任何租约的生命周期.

  • 丢弃客户端记录的 IA 中任何在 IA Address 或 IA Prefix option 中 valid lifetime 为 0 的租约.

  • 对于客户端已记录在 IA 中但服务器返回的 IA 中未包含的租约信息, 保持不变.

如果客户端能够使用从服务器获得的地址和/或前缀运行:

  • 客户端使用不包含带 NoAddrsAvail 或 NoPrefixAvail 状态码的 Status Code option 的任何 IA 中的地址, 委派前缀和其他信息. 对于收到 NoAddrsAvail 或 NoPrefixAvail 状态码的 IA, 客户端可以在后续发送给服务器的 Renew 和 Rebind 消息中包含这些 IA, 但不带地址或前缀, 以重试为这些 IA 获取地址或前缀.

  • 客户端必须按照 [RFC4862] 第 5.4 节对收到地址中的每个地址执行重复地址检测, 该节确实列出了一些例外. 对象是在处理来自服务器的任何先前 Reply 消息期间尚未执行重复地址检测的任何 IA 中的地址. 客户端在将收到的地址用于任何流量前执行重复地址检测. 如果发现任何地址已在链路上使用, 客户端按第 18.2.8 节所述为这些地址向服务器发送 Decline 消息.

  • 对于每个没有任何关联可达性信息的已分配地址, 见 [RFC4861] 第 2.1 节中 "on-link" 的定义, 为避免 [RFC4943] 中描述的问题, 客户端禁止因收到 IA Address option, 见第 21.6 节, 而假定任何地址在链路上可达. 从 IA Address option 获得的地址禁止用于形成长度不是 128 的隐式前缀.

  • 对于每个委派前缀, 客户端为关联接口所连接的每条链路分配一个子网.

    当客户端对子网化委派前缀时, 它必须向该前缀分配额外比特以生成唯一且更长的前缀. 例如, 如果图 1 中的客户端被委派 2001:db8:0::/48, 它可以生成 2001:db8:0:1::/64 和 2001:db8:0:2::/64, 分配给订户网络中的两条链路. 如果客户端被委派 2001:db8:0::/48 和 2001:db8:5::/48, 它可以将 2001:db8:0:1::/64 和 2001:db8:5:1::/64 分配给其中一条链路, 并将 2001:db8:0:2::/64 和 2001:db8:5:2::/64 分配给另一条链路.

    如果客户端使用委派前缀为其自身或其后方其他节点上的接口配置地址, 则这些地址的 preferred lifetime 和 valid lifetime 在任何时候都必须分别不长于该委派前缀的剩余 preferred lifetime 和 valid lifetime. 特别是, 如果委派前缀或从其派生的前缀被通告用于无状态地址自动配置 [RFC4862], 则通告的 preferred lifetime 和 valid lifetime 禁止超过该委派前缀对应的剩余生命周期.

具体配置信息的管理在第 21 节每个 option 的定义中详述.

如果 Reply 消息包含任何 IA, 但客户端在这些 IA 中找不到任何可用地址和/或委派前缀, 客户端可以尝试另一台服务器, 可能重新启动 DHCP 服务器发现过程, 或仅使用 Information-request 消息获取其他配置信息.

当客户端收到响应 Renew 或 Rebind 消息的 Reply 消息时, 客户端:

  • 如果 Reply 消息中的任何 IA 包含 NoBinding 状态码, 则向响应的服务器发送 Request 消息. 客户端在该消息中为所有 IA 放置 IA options. 对于服务器未返回错误的其他绑定, 客户端继续使用.

  • 如果任何 IA 不在 Reply 消息中, 则发送 Renew/Rebind. 但是, 这很可能表示响应的服务器不支持该 IA 类型, 立即发送不太可能产生不同结果. 因此, 客户端必须限制其传输速率, 见第 14.1 节, 并且可以只等待正常重传时间, 如同未收到 Reply 消息一样. 对于服务器确实返回信息的其他绑定, 客户端继续使用.

  • 否则接受 IA 中的信息.

18.2.10.2. 针对 Release 和 Decline 的 Reply (Reply for Release and Decline)​

当客户端收到响应 Release 消息的有效 Reply 消息时, 无论服务器返回的 Status Code option, 见第 21.13 节, 如何, 客户端都认为 Release 事件已完成.

当客户端收到响应 Decline 消息的有效 Reply 消息时, 无论服务器返回的 Status Code option 如何, 客户端都认为 Decline 事件已完成.

18.2.10.3. 针对 Confirm 的 Reply (Reply for Confirm)​

如果客户端收到任何指示 Success 状态的 Reply 消息, 无论显式还是隐式, 客户端可以使用 IA 中的地址, 并忽略任何指示 NotOnLink 状态的消息. 当客户端响应 Confirm 消息只收到一个或多个带 NotOnLink 状态的 Reply 消息时, 客户端按第 18 节所述执行 DHCP 服务器发现.

18.2.10.4. 针对 Information-request 的 Reply (Reply for Information-request)​

关于客户端应如何处理 Information Refresh Time option, 无论 Reply 中是否存在该 option, 详见第 21.23 节.

18.2.10.5. 撤销先前提供的 Options (Revoking Previously Provided Options)​

当客户端收到针对 Renew, Rebind 或 Information-Request 的 Reply, 且该 Reply 未包含客户端先前在 Reply 中收到过的已请求配置 option 时, 客户端应当停止使用先前收到的配置信息. 换言之, 客户端应表现得好像从未收到此配置 option, 并返回相关默认状态. 如果没有可行方式停止使用收到的配置信息, 则在没有该数据的其他来源且这些值没有外部影响时, 从该 option 收到/配置的值可以持续存在. 例如, 客户端先前收到 Client FQDN option, 见 [RFC4704], 并用它设置主机名, 如果节点没有合理方式取消设置其主机名且该主机名没有外部影响, 则允许继续使用它. 作为反例, 如果客户端先前从 DHCP 服务器收到 NTP 服务器地址, 但不再收到该地址, 则必须停止使用已配置的 NTP 服务器地址. 客户端应当对相同配置信息的其他来源保持开放. 此行为不适用于任何 IA options. IA options 的处理见第 18.2.10.1 节.

18.2.11. Reconfigure 消息的接收 (Receipt of Reconfigure Messages)​

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

如果消息未通过第 16.11 节所述验证, 尤其是在认证缺失或失败的情况下, 必须丢弃该消息.

收到有效 Reconfigure 消息后, 客户端按照 Reconfigure Message option, 见第 21.19 节, 的指示, 使用 Renew 消息, Rebind 消息或 Information-request 消息进行响应. 客户端忽略收到的 Reconfigure 消息中的 "transaction-id" 字段. 在事务进行期间, 客户端丢弃其收到的任何 Reconfigure 消息.

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

重复消息会被忽略, 因为客户端会在收到第一个 Reconfigure 后开始交换. 重传消息要么触发交换, 如果客户端未收到第一个 Reconfigure, 要么被忽略. 一旦服务器收到来自客户端的 Renew, Rebind 或 Information-request 消息, 服务器可以停止向客户端重传 Reconfigure 消息.

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

18.2.12. 刷新配置信息 (Refreshing Configuration Information)​

每当客户端可能已移动到新链路时, 分配给该链路上接口的前缀/地址可能不再适用于客户端所连接的链路. 客户端可能已移动到新链路的时间示例包括:

  • 客户端重启, 且具有稳定存储和持久 DHCP 状态.

  • 客户端重新连接到其已获得租约的链路.

  • 客户端从睡眠模式返回.

  • 客户端更改接入点, 例如使用 Wi-Fi 技术时.

  • 客户端网络接口指示断开连接事件, 随后指示连接事件.

检测网络连接变化的具体算法超出本文范围. [RFC6059] 和 [RFC4957] 定义了两种可用于检测可能需要刷新配置信息情形的机制.

当客户端检测到自己可能已移动到新链路, 且它已从服务器获得地址但没有委派前缀时, 客户端应当发起 Confirm/Reply 消息交换. 客户端必须在其 Confirm 消息中包含可能已移动到新链路的接口上分配的任何 IA, 以及与这些 IA 关联的地址. 任何响应服务器都会在返回给客户端的 Reply 消息中用状态指示这些地址是否适用于客户端所连接的链路.

如果客户端有任何从 DHCP 服务器获得的有效委派前缀, 客户端必须按第 18.2.5 节所述发起 Rebind/Reply 消息交换, 但重传参数应设置为与 Confirm 消息相同, 见第 18.2.3 节. 客户端在其 Rebind 消息中包含 IA_NA 和 IA_PD 以及关联租约.

如果客户端仅通过 Information-request/Reply 消息交换获得网络信息, 客户端必须按第 18.2.6 节所述发起 Information-request/Reply 消息交换.

如果客户端未检测到自己已移动到新链路, 但检测到链路上可用前缀发生重大变化, 客户端应当发起 Renew/Reply, Confirm/Reply 或 Information-request/Reply 交换之一. 当添加一个或多个链路上前缀, 和/或弃用一个或多个现有链路上前缀时, 该变化视为重大变化. 原因是这种重大变化可能表示服务器发生了配置变化. 但是, 客户端必须限制此类发起尝试的速率, 以避免在存在链路问题时向服务器泛洪请求, 例如最多每 30 秒只执行其中一次.

上面对要发起交换的选择取决于客户端当前状态:

  • 如果客户端有任何从服务器获得的有效委派前缀, 它按第 18.2.4 节所述发送 Renew, 如同 T1 时间已过期.

  • 否则, 如果客户端从服务器获得了一个或多个地址, 它按第 18.2.3 节所述发送 Confirm.

  • 否则, 如果仅从服务器获得了网络信息, 它按第 18.2.6 节所述发送 Information-request.

18.2.13. 重新启动服务器发现过程 (Restarting Server Discovery Process)​

每当客户端重新启动 DHCP 服务器发现过程, 或按第 18.2.9 节所述选择备用服务器时, 客户端应当停止使用其已有绑定对应的任何地址和委派前缀, 见第 18.2.7 节, 并在可能时停止使用其先前收到的任何其他配置信息. 客户端还应当尝试从新服务器为同一接口获取新绑定和其他配置信息. 这有助于客户端对所有绑定使用单个状态机.

18.3. 服务器行为 (Server Behavior)​

在本讨论中, 假定服务器已按特定于实现的方式配置了客户端关注的配置.

服务器响应其收到的每个有效 Solicit 消息发送 Advertise 消息, 以向客户端通告服务器可用.

在大多数情况下, 服务器会响应客户端发送的 Request, Confirm, Renew, Rebind, Decline, Release 和 Information-request 消息发送 Reply. 当服务器配置为以已提交的租约分配进行响应时, 服务器也会响应带 Rapid Commit option, 见第 21.14 节, 的 Solicit 发送 Reply.

这些 Advertise 和 Reply 消息必须始终包含 Server Identifier option, 见第 21.3 节, 其中包含服务器的 DUID, 并且如果客户端消息中存在 Client Identifier option, 见第 21.2 节, 则还包含该 option.

在大多数响应消息中, 服务器包含带有客户端配置信息的 options. 服务器必须了解 [RFC8200] 第 5 节中关于消息大小和使用分片的建议. 如果客户端在其消息中包含 Option Request option, 见第 21.7 节, 服务器在响应消息中包含配置参数 options, 对应 Option Request option 中标识且服务器已配置为返回给客户端的所有 options. 如果服务器已配置为这样做, 服务器可以向客户端返回额外 options.

客户端发送的任何消息到达服务器时可能封装在一个或多个 Relay-forward 消息中. 服务器必须使用收到的消息构造适当的 Relay-reply 消息, 以允许对收到消息的响应通过与原始客户端消息相同的中继代理以相反顺序被中继. 详见第 19.3 节. 服务器还可能需要为每个客户端记录此信息, 以防稍后需要发送 Reconfigure 消息, 除非服务器已配置可用于直接向客户端发送 Reconfigure 消息的地址, 见第 18.3.11 节. 注意, 支持 leasequery [RFC5007] 的服务器也需要记录此信息.

通过发送 Reconfigure 消息, 服务器可以发起配置交换, 促使 DHCP 客户端获得新的地址, 前缀和其他配置信息. 例如, 当 DHCP 域中的链路需要重新编号时, 或当其他配置 options 被更新时, 可能因为服务器被移动, 添加或移除, 管理员可以使用服务器发起的配置交换.

当客户端收到来自服务器的 Reconfigure 消息时, 客户端按照 Reconfigure Message option, 见第 21.19 节, 中 msg-type 指示开始发送 Renew, Rebind 或 Information-request 消息. 服务器在 Reply 消息中向客户端发送 IA 和/或其他配置信息. 即使客户端消息中未请求这些 IA 和参数, 服务器也可以在 Reply 消息中包含带有 IA 以及其他配置参数新值的 options.

18.3.1. Solicit 消息的接收 (Receipt of Solicit Messages)​

服务器按第 13 节所述确定有关客户端及其位置的信息, 并检查其有关响应客户端的管理策略. 如果不允许服务器响应客户端, 服务器丢弃 Solicit 消息. 例如, 如果服务器的管理策略是它只能响应愿意接受 Reconfigure 消息的客户端, 而客户端未在 Solicit 消息中包含 Reconfigure Accept option, 见第 21.20 节, 则服务器丢弃 Solicit 消息.

如果 (1) 允许服务器响应客户端, (2) 客户端未在 Solicit 消息中包含 Rapid Commit option, 见第 21.14 节, 或 (3) 服务器未配置为以已提交的租约和其他资源分配进行响应, 则服务器按第 18.3.9 节所述向客户端发送 Advertise 消息.

如果客户端在 Solicit 消息中包含 Rapid Commit option, 且服务器配置为以已提交的租约和其他资源分配进行响应, 则服务器用 Reply 消息响应 Solicit. 服务器生成 Reply 消息, 如同它已收到第 18.3.2 节所述 Request 消息. 服务器按第 18.3.10 节所述传输 Reply 消息. 服务器必须在向客户端发送 Reply 消息之前提交任何地址和委派前缀或其他配置信息的分配. 在这种情况下, 服务器在 Reply 消息中包含 Rapid Commit option, 以指示该 Reply 是对 Solicit 消息的响应.

讨论:

  • 使用 Solicit/Reply 消息交换时, 服务器在发送 Reply 消息之前提交任何租约分配. 客户端可以假定它已被分配 Reply 消息中的租约, 不需要为这些租约发送 Request 消息.

  • 通常, 配置为使用 Solicit/Reply 消息交换的服务器会部署为只有一台服务器响应 Solicit 消息. 如果多台服务器响应, 客户端只会使用其中一台服务器的租约, 而其他服务器的租约会被提交给客户端, 但不会被客户端使用.

18.3.2. Request 消息的接收 (Receipt of Request Messages)​

当服务器收到有效 Request 消息时, 服务器根据其策略和配置信息为该客户端创建绑定, 并记录客户端请求的 IA 和其他信息.

服务器通过将 "msg-type" 字段设置为 REPLY, 并将 Request 消息中的 transaction ID 复制到 "transaction-id" 字段来构造 Reply 消息.

服务器必须在 Reply 消息中包含 Server Identifier option, 见第 21.3 节, 其中包含服务器的 DUID, 以及来自 Request 消息的 Client Identifier option, 见第 21.2 节.

服务器检查来自客户端消息中的所有 IA.

对于 Request 消息中的每个 IA_NA option, 见第 21.4 节, 服务器检查其中包含地址的前缀是否适用于客户端所连接的链路. 如果其中包含地址的任何前缀不适用于客户端所连接的链路, 服务器必须向客户端返回该 IA, 并带有值为 NotOnLink 的 Status Code option, 见第 21.13 节. 如果服务器未发送 NotOnLink 状态码, 但无法向某个 IA 分配任何 IP 地址, 则服务器必须在 Reply 消息中返回该 IA option, IA 中不含地址, 并在 IA 中包含状态码为 NoAddrsAvail 的 Status Code option.

对于 Request 消息中服务器无法向其分配任何委派前缀的任何 IA_PD option, 见第 21.21 节, 服务器必须在 Reply 消息中返回该 IA_PD option, IA_PD 中不含前缀, 并在 IA_PD 中带有包含状态码 NoPrefixAvail 的 Status Code option.

服务器可以向 IA 分配不同于客户端 Request 消息的 IA 内所包含地址和/或委派前缀的地址和/或委派前缀.

对于服务器能够向其分配地址或委派前缀的所有 IA, 服务器包含带有地址, 对 IA_NA, 前缀, 对 IA_PD, 以及其他配置参数的 IA, 并将该 IA 记录为新的客户端绑定. 服务器禁止在 IA 中包含它未分配给客户端的任何地址或委派前缀.

Reply 中每个适用 IA option 设置的 T1/T2 时间必须在所有 IA 中为相同值. 服务器必须在 Reply 中根据该客户端所有适用绑定确定 T1/T2 时间. 这有助于客户端能够同时更新所有绑定.

如果服务器策略启用重新配置机制且客户端支持该机制, 服务器应当包含 Reconfigure Accept option, 见第 21.20 节. 目前, 在 Reply 中发送此 option 从技术上讲是冗余的, 因为使用重新配置机制需要认证. 当前唯一定义的机制是 RKAP, 见第 20.4 节, 而 reconfigure key 的存在即表示支持接受 Reconfigure 消息. 但是, 未来可能定义更好的安全机制, 使 RKAP 不再被使用.

服务器按第 18.3 节所述包含要返回给客户端的其他带配置信息的 options.

如果服务器发现客户端在 Request 消息中包含了一个 IA, 且服务器已具有将该 IA 与该客户端关联的绑定, 则服务器发送包含现有绑定的 Reply 消息, 生命周期可能已更新. 服务器可以根据其本地策略更新绑定, 但服务器应当重新生成响应, 而不是仅重传先前发送的信息, 即使 "transaction-id" 字段值与先前传输匹配也是如此. 服务器禁止缓存其响应.

讨论:

  • 缓存回复是不好的, 因为生命周期需要更新, 可以是将计时器减少自原始传输以来经过的时间, 或保留生命周期值并更新服务器数据库中的租约信息. 此外, 如果消息使用任何安全保护, 例如第 20.3 节所述 Replay Detection Method (RDM), 其值必须更新. 另外, 任何摘要也必须更新. 鉴于以上所有因素, 缓存回复远比简单发送与以前相同的缓冲区复杂, 而且很容易遗漏其中某些步骤.

18.3.3. Confirm 消息的接收 (Receipt of Confirm Messages)​

当服务器收到 Confirm 消息时, 服务器确定 Confirm 消息中的地址是否适用于客户端所连接的链路. 如果 Confirm 消息中的所有地址都通过此测试, 服务器返回 Success 状态. 如果任何地址未通过此测试, 服务器返回 NotOnLink 状态. 如果服务器无法执行此测试, 例如服务器没有关于客户端所连接链路上前缀的信息, 或者客户端发送的任何 IA 中都没有地址, 则服务器禁止向客户端发送 Reply.

服务器忽略 IA options 中的 T1 和 T2 字段, 以及 IA Address options 中的 preferred-lifetime 和 valid-lifetime 字段, 见第 21.6 节.

服务器通过将 "msg-type" 字段设置为 REPLY, 并将 Confirm 消息中的 transaction ID 复制到 "transaction-id" 字段来构造 Reply 消息.

服务器必须在 Reply 消息中包含 Server Identifier option, 见第 21.3 节, 其中包含服务器的 DUID, 以及来自 Confirm 消息的 Client Identifier option, 见第 21.2 节. 服务器包含指示 Confirm 消息状态的 Status Code option, 见第 21.13 节.

18.3.4. Renew 消息的接收 (Receipt of Renew Messages)​

对于来自客户端 Renew 消息中的每个 IA, 服务器定位客户端绑定, 并验证客户端 IA 中的信息是否与为该客户端存储的信息匹配.

如果服务器找到该 IA 的客户端条目, 服务器用新的生命周期以及适用时的 T1/T2 时间将 IA 发回客户端. 如果服务器无法延长 IA 中某个地址或委派前缀的生命周期, 服务器可以选择不包含该地址的 IA Address option, 见第 21.6 节, 或该委派前缀的 IA Prefix option, 见第 21.22 节. 如果服务器选择为这类地址或委派前缀包含 IA Address 或 IA Prefix option, 则除非服务器还包含它能够为该 IA 延长生命周期的其他地址或委派前缀, 否则服务器应当将 T1 和 T2 值设置为该 IA option 的 valid lifetime. 将 T1 和 T2 设置为等于 valid lifetime 的值会通知客户端, 与该 IA 关联的租约不会被延长, 因而没有必要尝试. 此外, 这避免在剩余生命周期接近 0 时生成不必要流量.

服务器可以选择更改返回给客户端的 IA 中的地址或委派前缀列表以及生命周期.

如果服务器发现 IA 中的任何地址不适用于客户端所连接的链路, 服务器将该地址以生命周期 0 返回给客户端.

如果服务器发现 IA 中的任何委派前缀不适用于客户端所连接的链路, 服务器将该委派前缀以生命周期 0 返回给客户端.

对于服务器找不到客户端条目的每个 IA, 服务器根据其策略和配置信息有以下选择:

  • 如果服务器配置为因处理 Renew 消息而创建新绑定, 服务器应当创建绑定, 并返回带有已分配地址或委派前缀的 IA, 同时带有生命周期, 适用时的 T1/T2 时间, 以及客户端请求的其他信息. 如果客户端在 IA_PD option, 见第 21.21 节, 内包含 IA Prefix option, 且 "IPv6-prefix" 字段为零值, "prefix-length" 字段为非零值, 服务器可以将 "prefix-length" 值用作待分配前缀长度的提示, 关于前缀长度提示的更多细节见 [RFC8168].

  • 如果服务器配置为因处理 Renew 消息而创建新绑定, 但服务器不会向某个 IA 分配任何租约, 服务器返回包含 Status Code option, 见第 21.13 节, 的 IA option, 其中带有 NoAddrsAvail 或 NoPrefixAvail 状态码以及面向用户的状态消息.

  • 如果服务器不支持为发送 Renew 消息的客户端创建新绑定, 或者根据服务器策略或配置信息禁用了此行为, 服务器返回包含 Status Code option 的 IA option, 其中带有 NoBinding 状态码以及面向用户的状态消息.

服务器通过将 "msg-type" 字段设置为 REPLY, 并将 Renew 消息中的 transaction ID 复制到 "transaction-id" 字段来构造 Reply 消息.

服务器必须在 Reply 消息中包含 Server Identifier option, 见第 21.3 节, 其中包含服务器的 DUID, 以及来自 Renew 消息的 Client Identifier option, 见第 21.2 节.

服务器按第 18.3 节所述包含要返回给客户端的其他带配置信息的 options.

即使 Renew 消息中未请求这些参数, 服务器也可以包含带有 IA 以及其他配置参数值的 options.

Reply 中每个适用 IA option 设置的 T1/T2 值必须在所有 IA 中相同. 服务器必须在 Reply 中根据该客户端所有适用绑定确定 T1/T2 值. 这有助于客户端能够同时更新所有绑定.

18.3.5. Rebind 消息的接收 (Receipt of Rebind Messages)​

当服务器收到来自客户端且包含 IA option 的 Rebind 消息时, 它定位客户端绑定, 并验证客户端 IA 中的信息是否与为该客户端存储的信息匹配.

如果服务器找到该 IA 的客户端条目, 并根据服务器的显式配置信息确定 IA 中的地址或委派前缀适用于客户端接口所连接的链路, 则服务器应当用新的生命周期以及适用时的 T1/T2 值将 IA 发回客户端. 如果服务器无法延长 IA 中某个地址的生命周期, 服务器可以选择不包含该地址的 IA Address option, 见第 21.6 节. 如果服务器无法延长 IA 中某个委派前缀的生命周期, 服务器可以选择不包含该前缀的 IA Prefix option, 见第 21.22 节.

如果服务器发现该 IA 的客户端条目存在, 但任何地址或委派前缀根据服务器的显式配置信息已不再适用于客户端接口所连接的链路, 则服务器将这些地址或委派前缀以生命周期 0 返回给客户端.

如果服务器找不到该 IA 的客户端条目, 服务器检查 IA 是否包含地址, 对 IA_NA, 或委派前缀, 对 IA_PD. 服务器根据其显式配置信息检查这些地址和委派前缀是否适用于客户端接口所连接的链路. 对于不适用于客户端接口所连接链路的任何地址, 服务器可以包含生命周期为 0 的 IA Address option. 对于不适用于客户端接口所连接链路的任何委派前缀, 服务器可以包含生命周期为 0 的 IA Prefix option. 带生命周期 0 的 Reply 构成对客户端的显式通知, 即这些特定地址和委派前缀不再有效, 客户端禁止使用. 如果服务器选择不包含任何带有生命周期为 0 的 IA Address 或 IA Prefix options 的 IA, 且服务器不包含任何其他带租约和/或状态码的 IA, 则服务器不发送 Reply 消息. 在这种情况下, 服务器丢弃 Rebind 消息.

否则, 对于服务器找不到客户端条目的每个 IA, 服务器根据其策略和配置信息有以下选择:

  • 如果服务器配置为因处理 Rebind 消息而创建新绑定, 另见下文关于 Rapid Commit option, 第 21.14 节, 的说明, 服务器应当创建绑定, 并返回带有已分配租约的 IA, 同时带有生命周期, 适用时的 T1/T2 值, 以及客户端请求的其他信息. 服务器禁止在 IA 中返回它未分配给客户端的任何地址或委派前缀.

  • 如果服务器配置为因处理 Rebind 消息而创建新绑定, 但服务器不会向某个 IA 分配任何租约, 服务器返回包含 Status Code option, 见第 21.13 节, 的 IA option, 其中带有 NoAddrsAvail 或 NoPrefixAvail 状态码以及面向用户的状态消息.

  • 如果服务器不支持为发送 Rebind 消息的客户端创建新绑定, 或者根据服务器策略或配置信息禁用了此行为, 服务器返回包含 Status Code option 的 IA option, 其中带有 NoBinding 状态码以及面向用户的状态消息.

当服务器为 IA 创建新绑定时, 其他服务器也可能因收到同一个 Rebind 消息而创建绑定. 见第 21.14 节中的"讨论"文本. 因此, 只有当服务器配置为响应包含 Rapid Commit option 的 Solicit 消息并返回 Reply 消息时, 服务器才应当在处理 Rebind 消息期间创建新绑定.

服务器通过将 "msg-type" 字段设置为 REPLY, 并将 Rebind 消息中的 transaction ID 复制到 "transaction-id" 字段来构造 Reply 消息.

服务器必须在 Reply 消息中包含 Server Identifier option, 见第 21.3 节, 其中包含服务器的 DUID, 以及来自 Rebind 消息的 Client Identifier option, 见第 21.2 节.

服务器按第 18.3 节所述包含要返回给客户端的其他带配置信息的 options.

即使 Rebind 消息中未请求这些 IA 和参数, 服务器也可以包含带有 IA 以及其他配置参数值的 options.

Reply 中每个适用 IA option 设置的 T1 或 T2 值必须在所有 IA 中为相同值. 服务器必须在 Reply 中根据该客户端所有适用绑定确定 T1 或 T2 值. 这有助于客户端能够同时更新所有绑定.

18.3.6. Information-request 消息的接收 (Receipt of Information-request Messages)​

当服务器收到 Information-request 消息时, 客户端正在请求不包括任何租约分配的配置信息. 服务器根据其已知的服务器配置策略, 确定适用于客户端的所有配置参数.

服务器通过将 "msg-type" 字段设置为 REPLY, 并将 Information-request 消息中的 transaction ID 复制到 "transaction-id" 字段来构造 Reply 消息.

服务器必须在 Reply 消息中包含 Server Identifier option, 见第 21.3 节, 其中包含服务器的 DUID. 如果客户端在 Information-request 消息中包含 Client Identifier option, 见第 21.2 节, 服务器将该 option 复制到 Reply 消息.

服务器按第 18.3 节所述包含要返回给客户端的带配置信息的 options. 服务器可以包含客户端在 Information-request 消息中未请求的额外 options.

如果从客户端收到的 Information-request 消息未包含 Client Identifier option, 服务器应当用包含任何不由客户端身份确定的配置参数的 Reply 消息进行响应. 如果服务器选择不响应, 客户端可能无限期继续重传 Information-request 消息.

18.3.7. Release 消息的接收 (Receipt of Release Messages)​

服务器通过将 "msg-type" 字段设置为 REPLY, 并将 Release 消息中的 transaction ID 复制到 "transaction-id" 字段来构造 Reply 消息.

收到有效 Release 消息后, 服务器检查 IA 以及 IA 中租约的有效性. 如果消息中的 IA 位于该客户端的绑定中, 且 IA 中的租约已由服务器分配给这些 IA, 则服务器从 IA 中删除这些租约, 并使这些租约可分配给其他客户端. 服务器忽略未分配给这些 IA 的租约, 但可以选择记录错误.

处理完所有租约后, 服务器生成 Reply 消息, 并包含值为 Success 的 Status Code option, 见第 21.13 节, 带服务器 DUID 的 Server Identifier option, 见第 21.3 节, 以及带客户端 DUID 的 Client Identifier option, 见第 21.2 节. 对于 Release 消息中服务器没有绑定信息的每个 IA, 服务器使用 Release 消息中的 IAID 添加 IA option, 并在该 IA option 中包含值为 NoBinding 的 Status Code option. IA option 中不包含其他 options.

服务器可以选择在租约生命周期过期后保留已分配租约和 IA 的记录, 以允许服务器将先前分配的租约重新分配给客户端.

18.3.8. Decline 消息的接收 (Receipt of Decline Messages)​

收到有效 Decline 消息后, 服务器检查 IA 以及 IA 中地址的有效性. 如果消息中的 IA 位于该客户端的绑定中, 且 IA 中的地址已由服务器分配给这些 IA, 则服务器从 IA 中删除这些地址. 服务器忽略未分配给这些 IA 的地址, 但如果发现这类地址, 可以选择记录错误.

客户端已发现 Decline 消息中的任何地址在其链路上已被使用. 因此, 服务器应当标记客户端拒绝的地址, 使这些地址不被分配给其他客户端, 并可以选择发出地址已被拒绝的通知. 服务器上的本地策略决定 Decline 消息中标识的地址何时可用于分配.

处理完所有地址后, 服务器通过将 "msg-type" 字段设置为 REPLY, 并将 Decline 消息中的 transaction ID 复制到 "transaction-id" 字段来生成 Reply 消息. 服务器包含值为 Success 的 Status Code option, 见第 21.13 节, 带服务器 DUID 的 Server Identifier option, 见第 21.3 节, 以及带客户端 DUID 的 Client Identifier option, 见第 21.2 节. 对于 Decline 消息中服务器没有绑定信息的每个 IA, 服务器使用 Decline 消息中的 IAID 添加 IA option, 并在该 IA option 中包含值为 NoBinding 的 Status Code option. IA option 中不包含其他 options.

18.3.9. Advertise 消息的创建 (Creation of Advertise Messages)​

服务器将 "msg-type" 字段设置为 ADVERTISE, 并将从客户端收到的 Solicit 消息中的 "transaction-id" 字段内容复制到 Advertise 消息. 服务器在 Server Identifier option, 见第 21.3 节, 中包含其服务器标识符, 并将 Solicit 消息中的 Client Identifier option, 见第 21.2 节, 复制到 Advertise 消息.

服务器可以添加 Preference option, 见第 21.8 节, 以携带 Advertise 消息的偏好值. 服务器实现应当允许管理员设置服务器偏好值. 除非服务器管理员另行配置, 服务器偏好值必须默认为 0.

如果服务器希望指示其支持 Reconfigure 机制, 则包含 Reconfigure Accept option, 见第 21.20 节. 客户端可以在服务器选择过程中使用此信息.

服务器包含其将在后续 Reply 消息中返回给客户端的 options. 如果客户端收到多个 Advertise 消息, 这些 options 中的信息可以由客户端用于选择服务器. 服务器必须在 Advertise 消息中包含配置参数 options, 对应 Solicit 消息的 Option Request option, 见第 21.7 节, 中标识且服务器已配置为返回给客户端的所有 options. 如果 Option Request option 包含容器 option, 服务器必须包含所有有资格封装在该容器中的 options. 即使某个 option 被封装, Option Request option 也可以用于表示对某项功能的支持, 例如 Prefix Exclude option [RFC6603]. 在这种情况下, 服务器需要特殊处理. 如果服务器已配置为这样做, 服务器可以向客户端返回额外 options.

服务器必须在 Advertise 消息中包含 IA options, 其中含有将分配给客户端 Solicit 消息中 IA 的任何地址和/或委派前缀. 如果客户端在 Solicit 消息中的 IA Address options, 见第 21.6 节, 中包含地址, 服务器可以将这些地址用作关于客户端希望接收地址的提示. 如果客户端包含 IA Prefix options, 见第 21.22 节, 服务器可以将 "IPv6-prefix" 字段中的前缀和/或 "prefix-length" 字段中的前缀长度用作关于客户端希望接收前缀的提示. 如果服务器不会分配在 Solicit 消息中作为提示收到的地址或委派前缀, 则服务器禁止在 Advertise 消息中包含该地址或委派前缀.

如果服务器不会在后续来自客户端的 Request 消息中向某个 IA_NA 分配任何地址, 服务器必须在 Advertise 消息中包含该 IA option, 且该 IA 中不含地址, 并在 IA option 中封装包含状态码 NoAddrsAvail 的 Status Code option, 见第 21.13 节.

如果服务器不会在后续来自客户端的 Request 消息中向某个 IA_PD 分配任何前缀, 服务器必须在 Advertise 消息中包含 IA_PD option, 见第 21.21 节, 且该 IA_PD option 中不含前缀, 并在 IA_PD 中封装包含状态码 NoPrefixAvail 的 Status Code option.

Advertise 消息的传输在下一节描述.

18.3.10. Advertise 和 Reply 消息的传输 (Transmission of Advertise and Reply Messages)​

如果原始消息由服务器直接收到, 服务器使用收到原始消息的 IP 数据报源地址字段中的地址, 将 Advertise 或 Reply 消息直接单播给客户端. Advertise 或 Reply 消息必须通过收到原始消息的接口进行单播.

如果原始消息是在 Relay-forward 消息中收到的, 服务器构造 Relay-reply 消息, 并将 Reply 消息放入 Relay Message option, 见第 21.10 节, 的负载中. 如果 Relay-forward 消息包含 Interface-Id option, 见第 21.18 节, 服务器将该 option 复制到 Relay-reply 消息. 服务器使用收到 Relay-forward 消息的 IP 数据报源地址字段中的地址, 将 Relay-reply 消息直接单播给中继代理. 关于 Relay-reply 消息构造的更多细节, 见第 19.3 节.

18.3.11. Reconfigure 消息的创建和传输 (Creation and Transmission of Reconfigure Messages)​

服务器将 "msg-type" 字段设置为 RECONFIGURE, 并将 "transaction-id" 字段设置为 0. 服务器在 Reconfigure 消息中包含 Server Identifier option, 见第 21.3 节, 其中包含其 DUID, 以及 Client Identifier option, 见第 21.2 节, 其中包含客户端 DUID.

由于存在针对 DHCP 客户端的拒绝服务 (Denial-of-Service, DoS) 攻击风险, Reconfigure 消息强制要求使用安全机制. 服务器必须在 Reconfigure 消息中使用 DHCP 认证, 见第 20.4 节.

服务器必须包含 Reconfigure Message option, 见第 21.19 节, 以选择客户端是用 Renew 消息, Rebind 消息还是 Information-request 消息进行响应.

除非单个 option 的定义中特别允许, 服务器禁止在 Reconfigure 消息中包含任何其他 options.

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

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

Reconfigure 消息使客户端发起与服务器的 Renew/Reply, Rebind/Reply 或 Information-request/Reply 消息交换. 服务器将收到来自客户端的 Renew, Rebind 或 Information-request 消息, 即原始 Reconfigure 消息中指定的消息, 解释为满足 Reconfigure 消息请求.

传输 Reconfigure 消息时, 服务器将重传时间 (retransmission time, RT) 设置为 REC_TIMEOUT. 如果服务器在 RT 经过前没有收到来自客户端的 Renew, Rebind 或 Information-request 消息, 服务器重传 Reconfigure 消息, 将 RT 值加倍, 然后再次等待. 服务器继续此过程, 直到已进行 REC_MAX_RC 次不成功尝试. 此时, 服务器应当中止该客户端的重新配置过程.

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

最后于 更新