跳到主要内容

6. 操作模型 (Operational Models)

本节描述若干当前最常见的 DHCP 操作模型. 这些模型并不互斥, 有时会组合使用. 例如, 一个设备可以先以有状态模式启动以获取地址, 然后在稍后某个应用程序启动时, 再使用无状态模式请求额外参数.

本文档假定 DHCP 服务器和通过特定接口与服务器通信的客户端属于同一个供应域 (provisioning domain).

DHCP 可以扩展为支持额外的有状态服务, 这些服务可能会与下面描述的一个或多个模型交互. 任何未来的协议扩展都应该考虑并记录这种交互.

6.1. 无状态 DHCP (Stateless DHCP)​

无状态 DHCP 可以在任何时候使用, 通常用于节点需要某些可通过 DHCP 获得但当前缺失或已过期的配置信息时.

这是 DHCP 最简单且最基本的操作. 它只要求客户端和服务器支持两种消息: Information-request 和 Reply. 注意, 当客户端和服务器不在同一条链路上时, DHCP 服务器和中继代理通常还需要支持 Relay-forward 和 Relay-reply 消息.

6.2. 用于非临时地址分配的 DHCP​

这种操作模型是 DHCP 最初的动机. 当仅使用无状态地址自动配置不足或不实际时, 该模型是合适的, 例如由于网络策略, DNS 动态更新等额外要求, 或客户端特定要求.

非临时地址分配的操作模型如下:

  • 服务器预配置了可用于向客户端分配地址的前缀, 以及关于哪些前缀存在于哪些链路上的相关网络拓扑信息.
  • 客户端请求由服务器分配非临时地址. 服务器根据客户端所连接的链路分配一个或多个适当地址.
  • 服务器将分配的一个或多个地址返回给客户端.

每个地址都有关联的首选生命周期和有效生命周期 (见第 12.1 节), 它们构成客户端可使用该地址的时长约定. 客户端可以请求延长某个地址的生命周期, 并且在地址的有效生命周期到期时必须停止使用该地址.

通常, 客户端在请求地址时也会请求其他配置参数, 例如 DNS 名称服务器地址和域搜索列表.

客户端也可以请求多个地址或多组地址 (见第 6.5 节和第 12 节).

6.3. 用于前缀委派的 DHCP​

前缀委派机制是另一种有状态操作模式, 最初用于从 DHCP 服务器向 DHCP 客户端 (通常是路由器) 简单委派前缀. 当客户端 (1) 不知道其所连接网络的拓扑, 且 (2) 不需要其他信息来选择要委派的前缀时, 该机制是合适的. ISP 可使用该机制向订户委派前缀, 委派出的前缀随后可能被划分为子网并分配给订户网络内的链路. [RFC7084] 和 [RFC7368] 详细描述了这种用法.

此前缀委派机制的设计满足 [RFC3769] 中的前缀委派要求.

DHCP 前缀委派本身并不要求客户端转发不是发往自身的 IP 数据包, 因此并不要求客户端或服务器成为 [RFC8200] 定义的路由器. 此外, 在许多场景中, 例如网络共享或托管虚拟机, 主机已经在转发 IP 数据包, 因而正作为 [RFC8200] 定义的路由器运行.

前缀委派的操作模型如下:

  • 服务器预配置了要委派给客户端的前缀.
  • 客户端按第 18 节的描述向服务器请求一个或多个前缀.
  • 服务器选择要委派的一个或多个前缀, 并向客户端返回这些前缀.
  • 随后客户端负责这些被委派的前缀. 例如, 客户端可以从被委派的前缀中为其某个接口分配一个子网, 并开始在该链路上为此前缀发送路由器通告 (Router Advertisements).

每个前缀都有关联的首选生命周期和有效生命周期 (见第 12.2 节), 它们构成客户端可使用该前缀的时长约定. 客户端可以请求延长被委派前缀的生命周期, 并且在该前缀的有效生命周期到期时必须停止使用被委派前缀.

图 1 展示了一个可使用前缀委派的网络架构.

                 ______________________         \
                /                      \         \
               |    ISP core network    |         \
                \__________ ___________/           |
                           |                       |
                   +-------+-------+               |
                   |  Aggregation  |               | ISP
                   |    device     |               | network
                   +-------+-------+               |
                           |                      /
                           |Network link to      /
                           |subscriber premises /
                           |
                    +------+--------+           \
                    |      CPE      |            \
                    | (DHCP client) |             \
                    +----+---+------+              |
                         |   |                     | Subscriber
  ---+-------------+-----+   +-----+------         | network
     |             |               |               |
+----+-----+ +-----+----+     +----+-----+         |
|Subscriber| |Subscriber|     |Subscriber|        /
|    PC    | |    PC    |     |    PC    |       /
+----------+ +----------+     +----------+      /

图 1: 前缀委派网络

在此示例中, 服务器位于 ISP 核心网络中或集成在汇聚设备中, 并配置了一组前缀, 用于在每个客户首次连接到 ISP 服务时分配给客户. 当前缀委派过程开始时, 客户端或客户驻地设备 (Customer Premises Equipment, CPE) 通过 DHCP 请求配置信息. 来自客户端的 DHCP 消息经由汇聚设备被服务器接收. 服务器收到请求后, 会选择一个或多个可用前缀委派给客户端. 随后服务器将该前缀或这些前缀返回给客户端.

客户端将被委派的前缀划分为子网, 并把更长的前缀分配给订户网络中的链路. 在基于图 1 所示网络的典型场景中, 客户端会把单个被委派的 /48 前缀划分为 /64 前缀, 并为订户网络中的每条链路分配一个 /64 前缀.

前缀委派选项可以与其他承载客户端配置信息的 DHCP 选项结合使用. 客户端随后也可以向连接到内部网络的节点提供 DHCP 服务. 例如, 客户端可以从 ISP 服务器获得 DNS 和 NTP 服务器地址, 然后通过客户端中的 DHCP 服务器把这些配置信息传递给订户主机.

如果客户端使用被委派前缀为自身接口或其后方其他节点配置地址, 这些地址的首选生命周期和有效生命周期在任何时候都不得长于对应被委派前缀的剩余首选生命周期和剩余有效生命周期. 特别是, 如果被委派前缀或由其派生的前缀被通告用于无状态地址自动配置 [RFC4862], 所通告的首选生命周期和有效生命周期不得超过被委派前缀的对应剩余生命周期.

已经委派了通过 DHCP Prefix Delegation 获得的任何地址空间的客户端, 在仍有任何地址空间处于外部分配状态时, 不得对相关被委派前缀发出 DHCP Release. 这包括由 DHCPv6 租出的地址 (IA_NA), 通过 DHCPv6-PD 委派的前缀 (IA_PD), 以及通过 IPv6 路由器通告自动配置的地址. [RFC9096] 中的要求 WPD-9 将此作为当前最佳实践.

[RFC9096] 第 3.3 节进一步提供了 WAN 侧 (DHCPv6-PD 客户端) 与 LAN 侧 (DHCPv6-PD 服务器) 之间协调生命周期的指导.

[RFC8987] 定义了若干与 Prefix Delegation 和 Relay Agents 相关的问题, 以及用于解决这些问题的一组要求.

6.4. 用于客户边缘路由器的 DHCP​

客户边缘路由器 (Customer Edge Routers) 的 DHCP 要求和网络架构在 [RFC7084] 中描述, [RFC9096] 则描述了对重编号的改进. 这种操作模型结合了地址分配 (见第 6.2 节) 和前缀委派 (见第 6.3 节). 通常, 该模型假定客户端和服务器之间的一组事务会分配或延长客户端的非临时地址和被委派前缀.

6.5. 多个地址和前缀​

DHCP 允许客户端接收多个地址. 在典型操作中, 客户端发送一个 IA_NA 选项实例, 服务器最多从分配给客户端所连接链路的每个前缀中分配一个地址. 特别是, 服务器可配置为从某条给定链路的多个前缀中提供地址. 这在网络重编号事件正在进行时很有用. 在典型部署中, 服务器会为每个 IA_NA 选项授予一个地址 (见第 21.4 节).

为满足 [RFC7934] 的建议, 客户端可以通过发送多个 IA_NA 选项来显式请求多个地址. 客户端可以在初始传输中发送多个 IA_NA 选项. 或者, 它也可以发送额外的 Request 消息, 其中包含新的额外 IA_NA 选项, 或在 Renew 消息中包含这些选项.

同一原则也适用于前缀委派. 原则上, DHCP 允许客户端通过发送额外 IA_PD 选项来请求委派新的前缀 (见第 21.21 节). 然而, 典型运营商通常更倾向于委派一个更大的单一前缀. 在大多数部署中, 建议客户端在初始传输中请求较大的前缀, 而不是稍后再请求额外前缀.

服务器是否授予额外地址和前缀的确切行为取决于服务器策略, 超出本文档范围.

关于服务器如何区分 IA 选项实例的更多信息, 见第 12 节.

6.6. 注册自生成地址​

[RFC9686] 引入了一种方法, 使设备能够在 DHCPv6 服务器中注册其自生成或静态配置的地址. 总体思路是设备通知服务器它正在使用的地址, 以便服务器根据本地策略记录这些地址.

该机制的主要特点是地址选择不是由 DHCP 服务器完成, 而是由设备自身完成. 生命周期的大部分原则上保持不变: 租约由服务器创建, 设备执行周期性操作以续订租约, 最终租约可能到期. 但是, 该机制使用不同的消息类型 (ADDR-REG-INFORM 和 ADDR-REG-REPLY), 并具有 [RFC9686] 中定义的不同源地址要求.

最后于 更新