跳到主要内容

18. DHCP 客户端发起的配置交换 (DHCP Client-Initiated Configuration Exchange)

客户端发起与一个或多个服务器的消息交换, 以获取或更新其关注的配置信息. 客户端可以在操作系统配置过程中发起配置交换, 也可以在应用层请求时发起, 在 Stateless Address Autoconfiguration 要求时发起, 或在需要延长地址生命周期时发起 (Renew 和 Rebind 消息).

18.1. 客户端行为 (Client Behavior)

客户端在地址的正常生命周期中使用 Request, Renew, Rebind, Release 和 Decline 消息. 当客户端可能已移动到新链路时, 它使用 Confirm 来验证地址. 当客户端需要配置信息但不需要地址时, 它使用 Information-Request 消息.

如果客户端拥有一个作用域足够的源地址, 该地址可供服务器用作返回地址, 并且客户端已从服务器收到 Server Unicast option (第 22.12 节), 则客户端 SHOULD 以单播方式将任何 Request, Renew, Release 和 Decline 消息发送给该服务器.

DISCUSSION:

使用单播可以避免由于中继代理转发消息而产生的延迟, 也可以避免客户端消息被递送给多个服务器而造成的服务器开销和重复响应. 要求客户端通过中继代理中继所有 DHCP 消息, 可以使中继代理选项被包含在客户端发送的所有消息中. 服务器只有在不会使用中继代理选项时, 才应启用单播.

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

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

客户端生成一个 transaction ID, 并将该值插入 "transaction-id" 字段.

客户端在 Server Identifier option 中放置目标服务器的标识符.

客户端 MUST 包含 Client Identifier option, 以向服务器标识自己. 客户端添加任何其他适当的选项, 包括一个或多个 IA options (如果客户端请求服务器为其分配某些网络地址).

客户端 MUST 包含 Option Request option (见第 22.7 节), 以指明客户端希望接收的选项. 客户端 MAY 包含带有数据值的选项, 作为向服务器提示客户端希望返回的参数值.

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

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

IRT REQ_TIMEOUT

MRT REQ_MAX_RT

MRC REQ_MAX_RC

MRD 0

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

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

  • 发起第 17 节描述的服务器发现过程.

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

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

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

  • 客户端重启.

  • 客户端物理连接到有线连接.

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

  • 使用无线技术的客户端更换接入点.

在客户端可能已移动到新链路的任何情况下, 客户端 MUST 发起 Confirm/Reply 消息交换. 客户端在其 Confirm 消息中包含分配给可能已移动到新链路的接口的任何 IA, 以及与这些 IA 关联的地址. 任何响应服务器都会在返回给客户端的 Reply 消息中通过状态指示这些地址是否适用于客户端当前连接的链路.

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

客户端 MUST 包含 Client Identifier option, 以向服务器标识自己. 客户端为正在发送 Confirm 消息的接口上分配的所有 IA 包含 IA options. IA options 包含客户端当前与这些 IA 关联的所有地址. 客户端 SHOULD 将任何 IA_NA options 中的 T1 和 T2 字段, 以及 IA Address options 中的 preferred-lifetime 和 valid-lifetime 字段设置为 0, 因为服务器会忽略这些字段.

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

IRT CNF_TIMEOUT

MRT CNF_MAX_RT

MRC 0

MRD CNF_MAX_RD

如果在第 14 节所述的消息传输过程终止前客户端没有收到响应, 客户端 SHOULD 继续使用任何 IP 地址, 并使用这些地址最后已知的生命周期, 同时 SHOULD 继续使用任何其他先前获得的配置参数.

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

为了延长与某个 IA 关联的地址的有效生命周期和首选生命周期, 客户端向其获取该 IA 中地址的服务器发送 Renew 消息, 其中包含该 IA 的 IA option. 客户端在该 IA option 中包含与该 IA 关联地址的 IA Address options. 服务器根据自身的管理配置确定 IA 中地址的新生命周期. 服务器也可以向 IA 添加新地址. 服务器可以通过将某些地址的 preferred 和 valid lifetimes 设置为零, 从 IA 中移除这些地址.

服务器通过分配给 IA 的 T1 和 T2 参数控制客户端联系服务器以延长所分配地址生命周期的时间.

在某个 IA 的 T1 时间, 客户端发起 Renew/Reply 消息交换, 以延长该 IA 中任何地址的生命周期. 客户端在 Renew 消息中包含一个 IA option, 其中带有当前分配给该 IA 的所有地址.

如果服务器将 T1 或 T2 设置为 0 (对于 IA_NA), 或者不存在 T1 或 T2 时间 (对于 IA_TA), 客户端可以分别自行决定何时发送 Renew 或 Rebind 消息.

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

客户端在 Server Identifier option 中放置目标服务器的标识符.

客户端 MUST 包含 Client Identifier option, 以向服务器标识自己. 客户端添加任何适当的选项, 包括一个或多个 IA options. 客户端 MUST 在 Renew 消息中包含当前与这些 IA 关联的地址列表.

客户端 MUST 包含 Option Request option (见第 22.7 节), 以指明客户端希望接收的选项. 客户端 MAY 包含带有数据值的选项, 作为向服务器提示客户端希望返回的参数值.

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

IRT REN_TIMEOUT

MRT REN_MAX_RT

MRC 0

MRD 到 T2 为止的剩余时间

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

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

在某个 IA 的 T2 时间 (只有当在 T1 时间向其发送 Renew 消息的服务器没有响应时才会到达), 客户端与任何可用服务器发起 Rebind/Reply 消息交换. 客户端在 Rebind 消息中包含一个 IA option, 其中带有当前分配给该 IA 的所有地址.

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

客户端 MUST 包含 Client Identifier option, 以向服务器标识自己. 客户端添加任何适当的选项, 包括一个或多个 IA options. 客户端 MUST 在 Rebind 消息中包含当前与这些 IA 关联的地址列表.

客户端 MUST 包含 Option Request option (见第 22.7 节), 以指明客户端希望接收的选项. 客户端 MAY 包含带有数据值的选项, 作为向服务器提示客户端希望返回的参数值.

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

IRT REB_TIMEOUT

MRT REB_MAX_RT

MRC 0

MRD 到所有地址的 valid lifetimes 到期为止的剩余时间

当分配给 IA 的所有地址的 valid lifetimes 到期时, 消息交换终止 (见第 10 节). 此时客户端有多种可选行动; 例如:

  • 客户端可以选择使用 Solicit 消息定位新的 DHCP 服务器, 并向新服务器发送针对已到期 IA 的 Request.

  • 客户端可能在其他 IA 中还有其他地址, 因此客户端可以选择丢弃已到期的 IA, 并使用其他 IA 中的地址.

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

客户端使用 Information-request 消息获取配置信息, 而不让服务器为其分配地址.

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

客户端 SHOULD 包含 Client Identifier option, 以向服务器标识自己. 如果客户端未包含 Client Identifier option, 服务器将无法向客户端返回任何特定于客户端的选项, 或者服务器可以选择完全不响应该消息. 如果 Information-Request 消息将被认证, 客户端 MUST 包含 Client Identifier option.

客户端 MUST 包含 Option Request option (见第 22.7 节), 以指明客户端希望接收的选项. 客户端 MAY 包含带有数据值的选项, 作为向服务器提示客户端希望返回的参数值.

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

IRT INF_TIMEOUT

MRT INF_MAX_RT

MRC 0

MRD 0

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

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

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

客户端在 Server Identifier option 中放置分配该地址的服务器标识符.

客户端 MUST 包含 Client Identifier option, 以向服务器标识自己. 客户端在 "options" 字段中包含携带其正在释放的地址所属 IA 的选项. 待释放的地址 MUST 包含在这些 IA 中. 客户端希望继续使用的任何 IA 地址 MUST NOT 添加到这些 IA 中.

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

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

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

IRT REL_TIMEOUT

MRT 0

MRC REL_MAX_RC

MRD 0

一旦客户端开始 Release 消息交换过程, 客户端 MUST 停止使用所有正在释放的地址. 如果地址已被释放, 但来自 DHCP 服务器的 Reply 丢失, 客户端将重传 Release 消息, 服务器可能以 Reply 响应并指示 NoBinding 状态. 因此, 客户端不会将 Release 消息交换中带有 NoBinding 状态的 Reply 消息视为表示错误.

注意, 如果客户端未能释放这些地址, 当分配给 IA 的每个地址的 valid lifetime 到期时, 服务器将回收该地址.

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

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

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

客户端在 Server Identifier option 中放置分配该地址的服务器标识符.

客户端 MUST 包含 Client Identifier option, 以向服务器标识自己. 客户端在 "options" 字段中包含携带其正在拒绝的地址所属 IA 的选项. 待拒绝的地址 MUST 包含在这些 IA 中. 客户端希望继续使用的任何 IA 地址不应添加到这些 IA 中.

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

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

IRT DEC_TIMEOUT

MRT 0

MRC DEC_MAX_RC

MRD 0

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

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

在收到响应 Solicit (带 Rapid Commit option), Request, Confirm, Renew, Rebind 或 Information-request 消息的有效 Reply 消息时, 客户端提取 Reply 中包含的配置信息. 客户端 MAY 选择报告 Reply 消息中 Status Code option 的任何状态码或消息.

客户端 SHOULD 在使用 Reply 消息中任何 IA 内的每个地址进行通信前, 对其执行 duplicate address detection [17]. 如果发现任何地址已在该链路上使用, 客户端按照第 18.1.7 节所述向服务器发送 Decline 消息.

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

  • 记录 T1 和 T2 时间.

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

  • 更新 IA option 中客户端已在该 IA 中记录的任何地址的生命周期.

  • 丢弃客户端记录的 IA 中那些在 IA Address option 中 valid lifetime 为 0 的地址.

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

具体配置信息的管理在第 22 节各选项定义中详细说明.

如果客户端收到的 Reply 消息包含带 UnspecFail 的 Status Code, 服务器表示由于未指定的失败条件而无法处理该消息. 如果客户端向同一服务器重传原始消息以重试期望的操作, 客户端 MUST 限制重传该消息的速率, 并限制重传该消息所持续的时间.

当客户端收到带有值为 UseMulticast 的 Status Code option 的 Reply 消息时, 客户端记录该消息的接收, 并通过接收该消息的接口使用多播向服务器发送后续消息. 客户端使用多播重新发送原始消息.

当客户端收到服务器响应 Confirm 消息返回的 NotOnLink 状态时, 客户端执行第 17 节所述的 DHCP 服务器请求, 并执行第 18 节所述的客户端发起配置. 如果客户端收到任何未指示 NotOnLink 状态的 Reply 消息, 客户端可以使用 IA 中的地址, 并忽略任何指示 NotOnLink 状态的消息.

当客户端收到服务器响应 Request 返回的 NotOnLink 状态时, 客户端可以不指定任何地址而重新发出 Request, 或者重新启动 DHCP 服务器发现过程 (见第 17 节).

客户端分别检查每个 IA 中的状态码. 如果状态码为 NoAddrsAvail, 客户端在该 IA 中没有收到可用地址, 并且可以选择尝试从另一台服务器为该 IA 获取地址. 客户端使用任何不包含 NoAddrsAvail 代码的 Status Code option 的 IA 中的地址和其他信息. 如果客户端在所有 IA 中都没有收到地址, 它可以尝试另一台服务器 (也许重新启动 DHCP 服务器发现过程), 或者使用 Information-request 消息仅获取其他配置信息.

当客户端收到响应 Renew 或 Rebind 消息的 Reply 消息时, 客户端独立检查每个 IA. 对于原始 Renew 或 Rebind 消息中的每个 IA, 客户端:

  • 如果该 IA 包含带 NoBinding 状态的 Status Code option, 则发送 Request 消息 (并且不再发送任何额外的 Renew/Rebind 消息)

  • 如果该 IA 不在 Reply 消息中, 则发送 Renew/Rebind

  • 否则接受该 IA 中的信息

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

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

18.2. 服务器行为 (Server Behavior)

在本讨论中, 假定 Server 已经以实现特定的方式配置了客户端关注的配置.

在大多数情况下, 服务器会响应客户端消息发送 Reply. 该 Reply 消息 MUST 始终包含带有服务器 DUID 的 Server Identifier option, 并且如果客户端消息中存在 Client Identifier option, 也必须包含该选项.

在大多数 Reply 消息中, 服务器包含携带客户端配置信息的选项. 服务器必须了解 RFC 2460 第 5 节中关于包大小和分片使用的建议. 如果客户端在其消息中包含 Option Request option, 服务器在 Reply 消息中包含携带配置参数的选项, 覆盖 Option Request option 标识的所有且服务器已配置为返回给客户端的选项. 如果服务器已配置为这样做, 服务器 MAY 向客户端返回其他选项.

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

当服务器通过单播从某个客户端收到 Request 消息, 而服务器尚未向该客户端发送 unicast option 时, 服务器丢弃该 Request 消息, 并以 Reply 消息响应. 该 Reply 消息包含值为 UseMulticast 的 Status Code option, 包含服务器 DUID 的 Server Identifier option, 来自客户端消息的 Client Identifier option, 且不包含其他选项.

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

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

服务器 MUST 在 Reply 消息中包含带有服务器 DUID 的 Server Identifier option, 以及 Request 消息中的 Client Identifier option.

如果服务器发现客户端消息中任何 IA 内一个或多个 IP 地址的前缀不适用于客户端所连接的链路, 服务器 MUST 将该 IA 返回给客户端, 并附带值为 NotOnLink 的 Status Code option.

如果服务器无法为客户端消息中的某个 IA 分配任何地址, 服务器 MUST 在 Reply 消息中包含该 IA, 该 IA 中不含地址, 并在该 IA 中包含 Status Code option, 其状态码为 NoAddrsAvail.

对于服务器能够分配地址的任何 IA, 服务器包含带有地址和其他配置参数的 IA, 并将该 IA 记录为新的客户端绑定.

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

服务器按照第 18.2 节所述包含其他携带配置信息的选项, 以返回给客户端.

如果服务器发现客户端在 Request 消息中包含了某个 IA, 而服务器已有将该 IA 与该客户端关联的绑定, 则说明客户端重新发送了未收到 Reply 消息的 Request 消息. 服务器要么重新发送先前缓存的 Reply 消息, 要么发送新的 Reply 消息.

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

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

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

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

服务器 MUST 在 Reply 消息中包含带有服务器 DUID 的 Server Identifier option, 以及 Confirm 消息中的 Client Identifier option. 服务器包含一个 Status Code option, 指示 Confirm 消息的状态.

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

当服务器通过单播从某个客户端收到 Renew 消息, 而服务器尚未向该客户端发送 unicast option 时, 服务器丢弃该 Renew 消息, 并以 Reply 消息响应. 该 Reply 消息包含值为 UseMulticast 的 Status Code option, 包含服务器 DUID 的 Server Identifier option, 来自客户端消息的 Client Identifier option, 且不包含其他选项.

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

如果服务器无法找到该 IA 的客户端条目, 服务器在 Reply 消息中返回不包含地址且 Status Code option 设置为 NoBinding 的 IA.

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

如果服务器找到客户端 IA 中的地址, 则服务器将该 IA 以新的生命周期和 T1/T2 时间返回给客户端. 服务器可以选择更改返回给客户端的 IA 中的地址列表和地址生命周期.

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

服务器 MUST 在 Reply 消息中包含带有服务器 DUID 的 Server Identifier option, 以及 Renew 消息中的 Client Identifier option.

服务器按照第 18.2 节所述包含其他携带配置信息的选项, 以返回给客户端.

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

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

如果服务器无法找到该 IA 的客户端条目, 并且服务器根据自身的显式配置信息确定该 IA 中的地址不适用于客户端接口所连接的链路, 服务器 MAY 向客户端发送 Reply 消息, 其中包含客户端的 IA, 并将 IA 中地址的生命周期设置为零. 该 Reply 构成对客户端的显式通知, 表示该 IA 中的地址不再有效. 在这种情况下, 如果服务器不发送 Reply 消息, 则静默丢弃该 Rebind 消息.

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

如果服务器找到客户端 IA 中的地址, 则服务器 SHOULD 将该 IA 以新的生命周期和 T1/T2 时间返回给客户端.

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

服务器 MUST 在 Reply 消息中包含带有服务器 DUID 的 Server Identifier option, 以及 Rebind 消息中的 Client Identifier option.

服务器按照第 18.2 节所述包含其他携带配置信息的选项, 以返回给客户端.

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

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

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

服务器 MUST 在 Reply 消息中包含带有服务器 DUID 的 Server Identifier option. 如果客户端在 Information-request 消息中包含 Client Identification option, 服务器将该选项复制到 Reply 消息.

服务器按照第 18.2 节所述包含携带配置信息的选项, 以返回给客户端.

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

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

当服务器通过单播从某个客户端收到 Release 消息, 而服务器尚未向该客户端发送 unicast option 时, 服务器丢弃该 Release 消息, 并以 Reply 消息响应. 该 Reply 消息包含值为 UseMulticast 的 Status Code option, 包含服务器 DUID 的 Server Identifier option, 来自客户端消息的 Client Identifier option, 且不包含其他选项.

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

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

服务器可以选择在地址生命周期到期后保留已分配地址和 IA 的记录, 以便服务器将先前分配的地址重新分配给客户端.

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

当服务器通过单播从某个客户端收到 Decline 消息, 而服务器尚未向该客户端发送 unicast option 时, 服务器丢弃该 Decline 消息, 并以 Reply 消息响应. 该 Reply 消息包含值为 UseMulticast 的 Status Code option, 包含服务器 DUID 的 Server Identifier option, 来自客户端消息的 Client Identifier option, 且不包含其他选项.

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

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

处理完所有地址后, 服务器生成 Reply 消息, 并包含值为 Success 的 Status Code option, 带有服务器 DUID 的 Server Identifier option, 以及带有客户端 DUID 的 Client Identifier option. 对于 Decline 消息中服务器没有绑定信息的每个 IA, 服务器使用 Release 消息中的 IAID 添加一个 IA option, 并在该 IA option 中包含值为 NoBinding 的 Status Code option. IA option 中不包含其他选项.

18.2.8. Reply 消息的传输 (Transmission of Reply Messages)

如果原始消息由服务器直接接收, 服务器使用收到原始消息的 IP 数据报中源地址字段里的地址, 将 Reply 消息直接单播给客户端. Reply 消息 MUST 通过接收原始消息的接口以单播方式发送.

如果原始消息是在 Relay-forward 消息中收到的, 服务器构造 Relay-reply 消息, 并将 Reply 消息放入 Relay Message option (见第 22.10 节) 的载荷中. 如果 Relay-forward 消息包含 Interface-id option, 服务器将该选项复制到 Relay-reply 消息. 服务器使用收到 Relay-forward 消息的 IP 数据报中源地址字段里的地址, 将 Relay-reply 消息直接单播给中继代理.