1. 简介 (Introduction)
动态主机配置协议 (Dynamic Host Configuration Protocol, DHCP) 为Internet主机提供配置参数。DHCP由两个组件组成: 从DHCP服务器向主机传递主机特定配置参数的协议, 以及向主机分配网络地址的机制。
DHCP建立在客户端-服务器模型之上, 指定的DHCP服务器主机分配网络地址并向动态配置的主机传递配置参数。在本文档的其余部分中, 术语"服务器 (Server)" 指通过DHCP提供初始化参数的主机, 术语"客户端 (Client)" 指从DHCP服务器请求初始化参数的主机。
除非系统管理员明确配置, 否则主机不应充当DHCP服务器。如果允许随机主机响应DHCP请求, Internet中硬件和协议实现的多样性将妨碍可靠操作。例如, IP要求在协议实现软件中设置许多参数。由于IP可以用于许多不同类型的网络硬件, 因此无法猜测这些参数的值或假设它们具有正确的默认值。此外, 分布式地址分配方案依赖于轮询/防御机制来发现已在使用的地址。IP主机可能并不总是能够防御其网络地址, 因此这种分布式地址分配方案无法保证避免分配重复的网络地址。
DHCP支持三种IP地址分配机制。在"自动分配 (Automatic Allocation)" 中, DHCP为客户端分配永久IP地址。在"动态分配 (Dynamic Allocation)" 中, DHCP为客户端分配IP地址, 持续有限的时间 (或直到客户端明确放弃该地址)。在"手动分配 (Manual Allocation)" 中, 客户端的IP地址由网络管理员分配, DHCP仅用于将分配的地址传达给客户端。特定网络将使用这些机制中的一种或多种, 具体取决于网络管理员的策略。
动态分配是三种机制中唯一一种允许自动重用分配给客户端的不再需要的地址的机制。因此, 动态分配特别适用于为仅临时连接到网络的客户端分配地址, 或在不需要永久IP地址的客户端组之间共享有限的IP地址池。对于在IP地址足够稀缺以至于在旧客户端退役时回收它们很重要的网络中, 为永久连接到网络的新客户端分配IP地址, 动态分配也可能是一个很好的选择。手动分配允许在 (无论出于何种原因) 希望在DHCP机制之外管理IP地址分配的环境中, 使用DHCP来消除手动为主机配置IP地址的容易出错的过程。
DHCP消息的格式基于BOOTP消息的格式, 以捕获作为BOOTP规范 [7, 21] 一部分描述的BOOTP中继代理行为, 并允许现有BOOTP客户端与DHCP服务器互操作。使用BOOTP中继代理消除了在每个物理网段上都有DHCP服务器的必要性。
1.1 对RFC 1541的更改 (Changes to RFC 1541)
本文档更新了RFC 1541中出现的DHCP协议规范。添加了一个新的DHCP消息类型DHCPINFORM; 有关详细信息, 请参见第3.4, 4.3和4.4节。用于向DHCP服务器标识DHCP客户端的分类机制已扩展为包括第4.2和4.3节中定义的"供应商 (Vendor)" 类。最短租期限制已被删除。最后, 根据DHCP互操作性测试中获得的经验, 进行了许多编辑更改以澄清文本。
1.2 相关工作 (Related Work)
有几个Internet协议和相关机制解决了动态主机配置问题的某些部分。反向地址解析协议 (Reverse Address Resolution Protocol, RARP) [10] (通过动态RARP (DRARP) [5] 中定义的扩展) 明确解决了网络地址发现问题, 并包括自动IP地址分配机制。简单文件传输协议 (Trivial File Transfer Protocol, TFTP) [20] 提供了从引导服务器传输引导映像的功能。Internet控制消息协议 (Internet Control Message Protocol, ICMP) [16] 通过"ICMP重定向 (ICMP Redirect)" 消息为主机提供有关其他路由器的信息。ICMP还可以通过"ICMP掩码请求 (ICMP Mask Request)" 消息提供子网掩码信息, 并通过 (已过时的) "ICMP信息请求 (ICMP Information Request)" 消息提供其他信息。主机可以通过ICMP路由器发现机制 [8] 定位路由器。
BOOTP是配置信息集合的传输机制。BOOTP也是可扩展的, 已为几个配置参数定义了官方扩展 [17]。Morgan提出了用于动态IP地址分配的BOOTP扩展 [15]。麻省理工学院Athena项目使用的网络信息协议 (Network Information Protocol, NIP) 是动态IP地址分配的分布式机制 [19]。资源定位协议 (Resource Location Protocol, RLP) [1] 提供高级服务的定位。Sun Microsystems无盘工作站使用采用RARP, TFTP和名为"bootparams"的RPC机制的引导过程, 向无盘主机提供配置信息和操作系统代码。(Sun Microsystems, Sun Workstation和SunOS是Sun Microsystems, Inc.的商标。) 一些Sun网络还使用DRARP和自动安装机制来自动化现有网络中新主机的配置。
在其他相关工作中, 路径最小传输单元 (MTU) 发现算法可以确定任意互联网路径的MTU [14]。地址解析协议 (Address Resolution Protocol, ARP) 已被提议作为资源定位和选择的传输协议 [6]。最后, 主机需求RFC [3, 4] 提到了主机重新配置的具体要求, 并为无盘主机的初始配置提出了一种场景。
1.3 问题定义和议题 (Problem definition and issues)
DHCP旨在为DHCP客户端提供主机需求RFC中定义的配置参数。通过DHCP获取参数后, DHCP客户端应该能够与Internet中的任何其他主机交换数据包。DHCP提供的TCP/IP协议栈参数列在附录A中。
并非所有这些参数对于新初始化的客户端都是必需的。客户端和服务器可以协商仅传输客户端所需的参数或特定于特定子网的参数。
DHCP允许但不要求配置与IP协议不直接相关的客户端参数。DHCP也不涉及新配置的客户端在域名系统 (Domain Name System, DNS) [12, 13] 中的注册。
DHCP不适用于配置路由器。
1.4 需求 (Requirements)
在整个文档中, 用于定义特定需求的重要性的词语采用大写字母。这些词是:
"MUST" (必须)
此词或形容词"REQUIRED (需要的)" 表示该项目是本规范的绝对要求。
"MUST NOT" (不得)
此短语表示该项目是本规范的绝对禁止。
"SHOULD" (应该)
此词或形容词"RECOMMENDED (推荐的)" 表示在特定情况下可能存在忽略该项目的有效理由, 但在选择不同的做法之前, 应该理解完整的含义并仔细权衡情况。
"SHOULD NOT" (不应该)
此短语表示在特定情况下可能存在列出的行为是可接受的甚至有用的有效理由, 但在实现任何用此标签描述的行为之前, 应该理解完整的含义并仔细权衡情况。
"MAY" (可以)
此词或形容词"OPTIONAL (可选的)" 表示该项目确实是可选的。一个供应商可能选择包括该项目, 因为特定市场需要它或因为它增强了产品, 例如; 另一个供应商可能省略相同的项目。
1.5 术语 (Terminology)
本文档使用以下术语:
"DHCP client" (DHCP客户端)
DHCP客户端是使用DHCP获取配置参数 (如网络地址) 的Internet主机。
"DHCP server" (DHCP服务器)
DHCP服务器是向DHCP客户端返回配置参数的Internet主机。
"BOOTP relay agent" (BOOTP中继代理)
BOOTP中继代理或中继代理是在DHCP客户端和DHCP服务器之间传递DHCP消息的Internet主机或路由器。DHCP设计为使用与BOOTP协议规范中指定的相同的中继代理行为。
"binding" (绑定)
绑定是配置参数的集合, 包括至少一个IP地址, 与DHCP客户端关联或"绑定"到DHCP客户端。绑定由DHCP服务器管理。
1.6 设计目标 (Design goals)
以下列表给出了DHCP的一般设计目标。
-
DHCP应该是一种机制而不是策略。DHCP必须允许本地系统管理员在需要时控制配置参数; 例如, 本地系统管理员应该能够在需要时强制执行有关分配和访问本地资源的本地策略。
-
客户端不应需要手动配置。每个客户端应该能够在没有用户干预的情况下发现适当的本地配置参数, 并将这些参数合并到其自己的配置中。
-
网络不应需要为单个客户端进行手动配置。在正常情况下, 网络管理器不必输入任何每个客户端的配置参数。
-
DHCP不应要求每个子网上都有服务器。为了实现规模和经济性, DHCP必须通过路由器或通过BOOTP中继代理的干预工作。
-
DHCP客户端必须准备接收对配置参数请求的多个响应。某些安装可能包括多个重叠的DHCP服务器, 以增强可靠性并提高性能。
-
DHCP必须与静态配置的、不参与的主机以及现有网络协议实现共存。
-
DHCP必须与RFC 951和RFC 1542 [21] 描述的BOOTP中继代理行为互操作。
-
DHCP必须为现有BOOTP客户端提供服务。
以下列表给出了特定于网络层参数传输的设计目标。DHCP必须:
-
保证任何特定网络地址在同一时间不会被多个DHCP客户端使用,
-
在DHCP客户端重启时保留DHCP客户端配置。DHCP客户端应尽可能在响应每个请求时分配相同的配置参数 (例如, 网络地址),
-
在服务器重启时保留DHCP客户端配置, 并且尽可能, 尽管DHCP机制重启, DHCP客户端应分配相同的配置参数,
-
允许自动为新客户端分配配置参数, 以避免为新客户端进行手动配置,
-
支持为特定客户端固定或永久分配配置参数。