跳到主要内容

2. 协议摘要

从客户端角度看, DHCP 是 BOOTP 机制的扩展. 这种行为允许现有 BOOTP clients 与 DHCP servers 互操作, 而不需要更改客户端初始化软件. RFC 1542 [2] 详细说明了 BOOTP 与 DHCP clients 和 servers [9] 之间的交互. 第 3 和第 4 节描述了一些新的可选事务, 用于优化 DHCP clients 与 servers 之间的交互.

图 1 给出 DHCP 消息格式, 表 1 描述 DHCP 消息中的每个字段. 括号中的数字表示每个字段的大小, 单位为 octets (八位组). 图中给出的字段名称将在本文档全文中用于引用 DHCP 消息中的字段.

DHCP 和 BOOTP 之间有两个主要区别. 首先, DHCP 定义了一些机制, 通过这些机制, 客户端可以在有限租约内被分配网络地址, 从而允许网络地址按顺序重新分配给不同客户端. 其次, DHCP 提供一种机制, 使客户端能够获取其运行所需的全部 IP 配置参数.

DHCP 引入了一个小的术语变化, 旨在澄清某个字段的含义. BOOTP 中的 'vendor extensions' 字段在 DHCP 中被重命名为 'options' 字段. 类似地, 原先在 BOOTP 'vendor extensions' 字段内使用并称为 "vendor extensions" 的带标签数据项, 现在简称为 "options".

DHCP 消息格式​

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
+---------------+---------------+---------------+---------------+
|                            xid (4)                            |
+-------------------------------+-------------------------------+
|           secs (2)            |           flags (2)           |
+-------------------------------+-------------------------------+
|                          ciaddr  (4)                          |
+---------------------------------------------------------------+
|                          yiaddr  (4)                          |
+---------------------------------------------------------------+
|                          siaddr  (4)                          |
+---------------------------------------------------------------+
|                          giaddr  (4)                          |
+---------------------------------------------------------------+
|                                                               |
|                          chaddr  (16)                         |
|                                                               |
|                                                               |
+---------------------------------------------------------------+
|                                                               |
|                          sname   (64)                         |
+---------------------------------------------------------------+
|                                                               |
|                          file    (128)                        |
+---------------------------------------------------------------+
|                                                               |
|                          options (variable)                   |
+---------------------------------------------------------------+

                Figure 1: Format of a DHCP message

DHCP 定义了一个新的 'client identifier' option, 用于向 DHCP server 传递显式客户端标识符. 这一变化消除了 BOOTP 消息中 'chaddr' 字段的重载, 在 BOOTP 中 'chaddr' 既用作传输 BOOTP 回复消息的硬件地址, 又用作客户端标识符. 'client identifier' 是不透明键, 不由服务器解释; 例如, 'client identifier' 可以包含与 'chaddr' 字段内容相同的硬件地址, 也可以包含另一种类型的标识符, 如 DNS 名称. DHCP client 选择的 'client identifier' 在该客户端所连接的子网内 MUST (必须) 对该客户端唯一. 如果客户端在一条消息中使用 'client identifier', 则它 MUST 在所有后续消息中使用同一标识符, 以确保所有服务器正确识别该客户端.

DHCP 澄清了 'siaddr' 字段的解释: 它是客户端 bootstrap 过程下一步要使用的服务器地址. 如果 DHCP server 准备提供下一项 bootstrap 服务 (例如交付操作系统可执行映像), 它可以在 'siaddr' 字段中返回自己的地址. DHCP server 总是在 'server identifier' option 中返回自己的地址.

DHCP 消息字段说明​

字段Octets描述
op1消息操作码/消息类型.<br/>1 = BOOTREQUEST, 2 = BOOTREPLY
htype1硬件地址类型, 见 "Assigned Numbers" RFC 的 ARP 章节; 例如 '1' = 10mb ethernet.
hlen1硬件地址长度 (例如 10mb ethernet 为 '6').
hops1客户端设为零, 通过 relay agent 启动时可由 relay agents 选择性使用.
xid4Transaction ID (事务 ID), 由客户端选择的随机数, 客户端和服务器用它关联客户端与服务器之间的消息和响应.
secs2由客户端填写, 表示客户端开始地址获取或续租过程以来经过的秒数.
flags2标志 (见图 2).
ciaddr4客户端 IP 地址; 仅当客户端处于 BOUND, RENEW 或 REBINDING 状态且能够响应 ARP 请求时填写.
yiaddr4'your' (client) IP 地址.
siaddr4bootstrap 中下一台要使用的服务器 IP 地址; 由服务器在 DHCPOFFER, DHCPACK 中返回.
giaddr4Relay agent IP 地址, 用于通过 relay agent 启动.
chaddr16客户端硬件地址.
sname64可选服务器主机名, 以 null 结尾的字符串.
file128启动文件名, 以 null 结尾的字符串; 在 DHCPDISCOVER 中为 "generic" 名称或 null, 在 DHCPOFFER 中为完全限定目录路径名.
optionsvar可选参数字段. 已定义 options 列表见 options 文档.

表 1: DHCP 消息字段说明

'options' 字段现在为可变长度. DHCP client 必须准备好接收 'options' 字段长度至少为 312 octets 的 DHCP 消息. 这一要求意味着 DHCP client 必须准备好接收最长 576 octets 的消息, 这是 IP 主机必须准备接受的最小 IP 数据报大小 [3]. DHCP clients 可以通过 'maximum DHCP message size' option 协商使用更大的 DHCP 消息. options 字段还可以进一步扩展到 'file' 和 'sname' 字段中.

对于使用 DHCP 进行初始配置的客户端 (在客户端 TCP/IP 软件完全配置之前), DHCP 需要创造性地使用客户端 TCP/IP 软件, 并宽松解释 RFC 1122. TCP/IP 软件 SHOULD 在 IP 地址配置之前接受交付到客户端硬件地址的任何 IP 分组, 并将其转发给 IP 层; 对于在 TCP/IP 软件配置前无法接受硬件单播数据报的客户端, DHCP servers 和 BOOTP relay agents 可能无法交付 DHCP 消息.

为绕过上一段所述某些客户端在 TCP/IP 软件配置前无法接受 IP 单播数据报的问题, DHCP 使用 'flags' 字段 [21]. 最左位定义为 BROADCAST (B) flag. 该标志的语义在本文档第 4.1 节讨论. flags 字段的其余位保留供未来使用. 客户端 MUST 将它们设为零, 服务器和 relay agents 必须忽略它们. 图 2 给出 'flags' 字段格式.

                              1 1 1 1 1 1
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |B|             MBZ             |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            B:  BROADCAST flag

            MBZ:  MUST BE ZERO (reserved for future use)

            Figure 2: Format of the 'flags' field

2.1 配置参数存储库​

DHCP 提供的第一项服务是为网络客户端提供网络参数的持久存储. DHCP 持久存储模型是: DHCP 服务为每个客户端存储一个 key-value (键值) 条目, 其中键是某种唯一标识符 (例如 IP 子网号和该子网内的唯一标识符), 值是客户端的配置参数.

例如, 键可以是 (IP-subnet-number, hardware-address) 这一对, 允许在不同子网上按顺序或并发重用硬件地址, 也允许硬件地址不是全局唯一的情况. 或者, 键可以是 (IP-subnet-number, hostname) 这一对, 允许服务器为已移动到不同子网或已更改硬件地址 (可能由于网络接口故障和硬件替换) 的 DHCP client 智能分配参数. 协议规定, 除非客户端使用 'client identifier' option 显式提供标识符, 否则键将为 (IP-subnet-number, hardware-address). 客户端可以查询 DHCP 服务以检索其配置参数. 客户端到配置参数存储库的接口由请求配置参数的协议消息以及携带配置参数的服务器响应组成.

2.2 网络地址动态分配​

DHCP 提供的第二项服务是向客户端分配临时或永久网络 (IP) 地址. 网络地址动态分配的基本机制很简单: 客户端请求在一段时间内使用某个地址. 分配机制 (一组 DHCP servers) 保证不会在请求时间内重新分配该地址, 并尝试在客户端每次请求地址时返回相同网络地址. 在本文档中, 网络地址分配给客户端的时间段称为 "lease" (租约) [11]. 客户端可以通过后续请求延长其租约. 当客户端不再需要该地址时, 可以发出消息将地址释放回服务器. 客户端可以通过请求无限租约来请求永久分配. 即使分配 "permanent" 地址, 服务器也可以选择发放很长但非无限的租约, 以允许检测客户端已退役的事实.

在某些环境中, 由于可用地址耗尽, 必须重新分配网络地址. 在这类环境中, 分配机制会重用租约已过期的地址. 服务器应使用配置参数存储库中可用的任何信息来选择要重用的地址. 例如, 服务器可以选择最近最少分配的地址. 作为一致性检查, 分配服务器 SHOULD 在分配地址前探测被重用地址, 例如使用 ICMP echo request; 客户端 SHOULD 探测新收到的地址, 例如使用 ARP.

最后于 更新