5. DHCP 常量

5. DHCP 常量

本节描述 DHCP 使用的各种程序常量和网络常量.

5.1. 组播地址

DHCP 使用以下组播地址 (multicast addresses):

All_DHCP_Relay_Agents_and_Servers (FF02::1:2) 一个链路作用域 (link-scoped) 组播地址, 客户端使用它与相邻的, 即同链路 (on-link) 的中继代理 (relay agents) 和服务器通信. 所有服务器和中继代理都是此组播组的成员.

All_DHCP_Servers (FF05::1:3) 一个站点作用域 (site-scoped) 组播地址, 中继代理使用它与服务器通信, 原因可能是中继代理希望向所有服务器发送消息, 或者它不知道服务器的单播地址. 注意, 为了让中继代理使用此地址, 它必须具有足够作用域的地址, 以便服务器能够到达它. 站点内的所有服务器都是此组播组的成员.

5.2. UDP 端口

客户端在 UDP 端口 546 上侦听 DHCP 消息. 服务器和中继代理在 UDP 端口 547 上侦听 DHCP 消息.

5.3. DHCP 消息类型

DHCP 定义以下消息类型 (message types). 关于这些消息类型的更多细节见第 6 节和第 7 节. 此处未列出的消息类型保留供将来使用. 每种消息类型的数字编码显示在括号中.

SOLICIT (1) 客户端发送 Solicit 消息以定位服务器.

ADVERTISE (2) 服务器发送 Advertise 消息以表明它可提供 DHCP 服务, 作为对从客户端收到的 Solicit 消息的响应.

REQUEST (3) 客户端向特定服务器发送 Request 消息, 以请求配置参数, 包括 IP 地址.

CONFIRM (4) 客户端向任何可用服务器发送 Confirm 消息, 以确定分配给它的地址对于客户端所连接的链路是否仍然适用.

RENEW (5) 客户端向最初提供客户端地址和配置参数的服务器发送 Renew 消息, 以延长分配给客户端的地址生命周期 (lifetimes), 并更新其他配置参数.

REBIND (6) 客户端向任何可用服务器发送 Rebind 消息, 以延长分配给客户端的地址生命周期, 并更新其他配置参数. 当客户端没有收到 Renew 消息的响应后, 会发送此消息.

REPLY (7) 服务器发送 Reply 消息, 其中包含已分配地址和配置参数, 作为对从客户端收到的 Solicit, Request, Renew, Rebind 消息的响应. 服务器发送包含配置参数的 Reply 消息, 作为对 Information-request 消息的响应. 服务器发送 Reply 消息, 作为对 Confirm 消息的响应, 用于确认或否认分配给客户端的地址对于客户端所连接的链路是否适用. 服务器发送 Reply 消息以确认收到 Release 或 Decline 消息.

RELEASE (8) 客户端向为其分配地址的服务器发送 Release 消息, 以表明客户端将不再使用一个或多个已分配地址.

DECLINE (9) 客户端向服务器发送 Decline 消息, 以表明客户端已确定服务器分配的一个或多个地址在客户端所连接的链路上已被使用.

RECONFIGURE (10) 服务器向客户端发送 Reconfigure 消息, 以通知客户端服务器有新的或更新后的配置参数, 并且客户端要与服务器发起 Renew/Reply 或 Information-request/Reply 事务 (transaction), 以接收更新后的信息.

INFORMATION-REQUEST (11) 客户端向服务器发送 Information-request 消息, 以请求配置参数, 但不向客户端分配任何 IP 地址.

RELAY-FORW (12) 中继代理发送 Relay-forward 消息以向服务器中继消息, 可直接发送, 也可通过另一个中继代理发送. 收到的消息, 可以是客户端消息或来自另一个中继代理的 Relay-forward 消息, 被封装在 Relay-forward 消息的一个选项中.

RELAY-REPL (13) 服务器向中继代理发送 Relay-reply 消息, 其中包含中继代理要递送给客户端的消息. Relay-reply 消息可以由其他中继代理中继, 以递送给目标中继代理.

                     服务器将客户端消息作为 Relay-reply 消息中的一个选项封装, 中继代理提取该选项并将其转发给客户端.

5.4. 状态码

DHCPv6 使用状态码 (status codes) 来传达客户端和服务器在消息中请求的操作是成功还是失败, 并提供关于消息失败具体原因的附加信息. 具体的状态码在第 24.4 节中定义.

5.5. 传输和重传参数

本节给出一个值表, 用于描述客户端和服务器的消息传输行为.

参数 默认值 描述

SOL_MAX_DELAY 1 sec 首个 Solicit 的最大延迟 SOL_TIMEOUT 1 sec 初始 Solicit 超时 SOL_MAX_RT 120 secs 最大 Solicit 超时值 REQ_TIMEOUT 1 sec 初始 Request 超时 REQ_MAX_RT 30 secs 最大 Request 超时值 REQ_MAX_RC 10 最大 Request 重试次数 CNF_MAX_DELAY 1 sec 首个 Confirm 的最大延迟 CNF_TIMEOUT 1 sec 初始 Confirm 超时 CNF_MAX_RT 4 secs 最大 Confirm 超时 CNF_MAX_RD 10 secs 最大 Confirm 持续时间 REN_TIMEOUT 10 secs 初始 Renew 超时 REN_MAX_RT 600 secs 最大 Renew 超时值 REB_TIMEOUT 10 secs 初始 Rebind 超时 REB_MAX_RT 600 secs 最大 Rebind 超时值 INF_MAX_DELAY 1 sec 首个 Information-request 的最大延迟 INF_TIMEOUT 1 sec 初始 Information-request 超时 INF_MAX_RT 120 secs 最大 Information-request 超时值 REL_TIMEOUT 1 sec 初始 Release 超时 REL_MAX_RC 5 最大 Release 尝试次数 DEC_TIMEOUT 1 sec 初始 Decline 超时 DEC_MAX_RC 5 最大 Decline 尝试次数 REC_TIMEOUT 2 secs 初始 Reconfigure 超时 REC_MAX_RC 8 最大 Reconfigure 尝试次数 HOP_COUNT_LIMIT 32 Relay-forward 消息中的最大跳数

5.6. 时间值和作为时间值的 "Infinity" 的表示

生命周期, T1 和 T2 的所有时间值都是无符号整数 (unsigned integers). 当 0xffffffff 用作生命周期, 如 RFC2461 [17] 中所述, 或用作 T1 或 T2 的值时, 其含义为 "infinity".