跳到主要内容

12.1. Requesting router behavior (请求路由器行为)

12.1. Requesting router behavior (请求路由器行为)​

请求路由器使用 Request 消息来填充 IA_PD 的前缀。请求路由器在 Request 消息中包含一个或多个 IA_PD 选项。然后, 委派路由器在 Reply 消息的 IA_PD 选项中将 IA_PD 的前缀返回给请求路由器。

请求路由器在其发送的任何 Renew 或 Rebind 消息中包含 IA_PD 选项。IA_PD 选项包括请求路由器当前与该 IA_PD 关联的所有前缀。

在某些情况下, 请求路由器可能需要验证委派路由器是否仍然对请求路由器有有效的绑定。请求路由器可能请求此类验证的时间示例包括:

  • 请求路由器重新启动。

  • 请求路由器的上游链路抖动。

  • 请求路由器与有线连接物理断开。

如果需要此类验证, 则请求路由器必须按照 RFC 3315 第 18.1.4 节 "Creation and Transmission of Rebind Messages" 中的描述启动 Rebind/Reply 消息交换, 但重传参数应设置为 RFC 3315 第 18.1.2 节 "Creation and Transmission of Confirm Messages" 中描述的 Confirm 消息的参数。请求路由器在其 Rebind 消息中包含任何 IA_PD, 以及与这些 IA_PD 关联的前缀。

每个前缀都有有效生命周期和首选生命周期, 其持续时间在该前缀的 IA_PD Prefix 选项中指定。请求路由器使用 Renew 和 Rebind 消息请求延长委派前缀的生命周期。

请求路由器使用 Release 消息将委派的前缀返回给委派路由器。要释放的前缀必须包含在 IA_PD 中。

前缀委派不使用 Confirm 和 Decline 消息类型。

在接收到有效的 Reply 消息时, 对于每个 IA_PD, 请求路由器从每个委派前缀中将子网分配给关联接口所连接的每个链路, 但有以下例外: 请求路由器绝对不能将任何委派前缀或来自委派前缀的子网分配给它通过其接收到来自委派路由器的 DHCP 消息的链路。

当请求路由器对委派的前缀进行子网划分时, 它必须为前缀分配额外的位以生成唯一的更长前缀。例如, 如果图 1 中的请求路由器被委派 3FFE:FFFF:0::/48, 它可能生成 3FFE:FFFF:0:1::/64 和 3FFE:FFFF:0:2::/64 以分配给订户网络中的两个链路。如果请求路由器被委派 3FFE:FFFF:0::/48 和 3FFE:FFFF:5::/48, 它可能将 3FFE:FFFF:0:1::/64 和 3FFE:FFFF:5:1::/64 分配给其中一个链路, 并将 3FFE:FFFF:0:2::/64 和 3FFE:FFFF:5:2::/64 分配给另一个链路。

如果请求路由器将委派的前缀分配给它所连接的链路, 并开始在该链路上为该前缀发送路由器通告, 则请求路由器必须将这些通告中的有效生命周期设置为不晚于 IA_PD Prefix 选项中指定的有效生命周期。请求路由器可以使用 IA_PD Prefix 选项中指定的首选生命周期。

RFC 3315 第 18.1.8 节 "Receipt of Reply Messages" 中描述了对接收到的 Reply 消息中的 Status Code 选项的处理。NoPrefixAvail Status Code 的处理方式与 NoAddrsAvail Status Code 相同。

最后于 更新