RFC3736：Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6，April 2004
本备忘录的状态
本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。
版权声明
版权所有 (C) 互联网协会 (2004)。版权所有。
梗概
节点使用基于IPv6的无状态动态主机配置协议服务 (Dynamic Host Configuration Protocol for IPv6，DHCPv6) 来获取配置信息，例如 DNS 递归名称服务器的地址，这不需要为单个客户端维护任何动态状态。使用无状态 DHCP 的节点必须通过其他机制（通常是无状态地址自动配置）获得其 IPv6 地址。本文档解释了 RFC 3315 的哪些部分必须在每种不同类型的 DHCP 代理中实现，以便代理可以支持无状态 DHCP。
1、 简介
通过其他一些机制（例如无状态地址自动配置 [6] 或手动配置）获得 IPv6 地址的节点可以使用无状态 DHCP 来获取其他配置信息，例如 DNS 递归名称服务器或 SIP 服务器列表。无状态 DHCP 服务器仅向节点提供配置信息，不执行任何地址分配。这样的服务器被称为“无状态”，因为它不需要为单个客户端维护任何动态状态。
虽然 DHCP 规范 [1] 定义了 10 多个协议消息和 20 个选项，但无状态 DHCP 服务只需要这些消息和选项的子集。本文档解释了无状态 DHCP 服务需要 RFC 3315 中定义的哪些消息和选项。该文档的预期用途是指导使用无状态 DHCP 服务的客户端和服务器的互操作实现。
对于无状态和有状态 DHCP 服务，中继代理的操作是相同的。中继代理的操作在 DHCP 规范中进行了描述。
本文档的第 4 节列出了 DHCP 文档的各个部分，实现者应阅读这些部分以了解 DHCP 规范的概述和 DHCP 服务的基本要求。第 5 节列出了无状态 DHCP 服务特别需要的特定消息和选项。第 6 节描述了无状态和有状态 DHCP 服务器如何交互以向需要地址分配的客户端和只需要无状态服务的客户端提供服务。
2、 术语
在本文档中，“DHCP”是指 IPv6 的 DHCP。
本文档使用 RFC 2460 [2]、DHCP 规范 [1] 和 DHCP DNS 配置选项规范 [3] 中定义的术语。
“无状态 DHCP”是指使用 DHCP 向客户端提供配置信息，不需要服务器维护有关 DHCP 客户端的动态状态。
3、 概述
本文档假定使用无状态 DHCP 配置的节点不使用 DHCP 进行地址分配，并且节点已确定至少一个链路本地地址，如 RFC 2461 [4] 的第 5.3 节所述。
为了通过无状态 DHCP 获取配置参数，节点使用 DHCP Information-request 消息。DHCP 服务器使用带有节点配置参数的回复消息来响应节点的消息。来自服务器的回复消息可以携带配置信息，例如 DNS 递归名称服务器 [3] 和 SIP 服务器 [5] 的列表。
本文档不适用于 RFC 3315 中描述的 DHCP 中继代理功能。一个网元可以同时提供 DHCP 服务器和 DHCP 中继服务。例如，网络元素可以向请求无状态DHCP服务的主机提供无状态DHCP服务，同时通过DHCP将来自请求地址分配的主机的消息中继到另一个DHCP服务器。
4、 DHCP实现的基本要求
DHCP 规范的几个部分提供了背景信息或定义了所有实现通用的规范部分：
1-4：介绍DHCP和DHCP消息流的概述
5：定义整个协议规范中使用的常量
6、7：说明DHCP报文的格式
8：描述域名的表示
9：定义“DHCP唯一标识符”（DHCP unique identifier，DUID）
13-16：描述DHCP消息传输、重传和验证
21：描述 DHCP 的身份验证
5、 无状态DHCP的实现
客户端通过发送一个包含“选项请求”选项的“信息请求”消息来指示它正在请求配置信息，该选项指定它希望从DHCP服务器接收的选项。例如，如果客户端试图获取 DNS 递归名称服务器列表，它会在信息请求消息中标识 DNS 递归名称服务器选项。服务器根据其配置策略为客户端确定适当的配置参数，并以包含请求参数的回复消息进行响应。在此示例中，服务器将使用 DNS 配置参数进行响应。
如 RFC 3315 的第 18.1.5 节所述，节点可能会在“信息请求”消息中包含客户端标识符选项，以向服务器标识自己，因为服务器管理员可能希望自定义服务器对每个节点的响应，基于节点的身份。
RFC 3315 没有定义任何机制来控制主机使用信息请求消息获取更新配置参数的时间。DHC WG 已经着手开发这样一种或多种机制，将作为标准跟踪 RFC 发布。
RFC 3315 也没有提供关于当主机移动到新链路时主机何时可以使用信息请求消息来获取更新的配置参数的任何指导。DHC WG 正在审查一份相关文件，“Detection of Network Attachment (DNA) in IPv4”[8]，该文件描述了使用 IPv4 的主机如何确定何时使用 DHCPv4。DHC WG 或由 DNA BOF 组成的 WG 将为 IPv6 开发类似的文件。
5.1、 无状态 DHCP 服务所需的消息
客户端和服务器为无状态 DHCP 服务实现以下消息；此列表中的部分编号是指 DHCP 规范：
Information-request：信息请求，由 DHCP 客户端发送到服务器以请求配置参数（第 18.1.5 和 18.2.5 节）
Reply：响应，由 DHCP 服务器发送到包含配置参数的客户端（第 18.2.6 和 18.2.8 节）
此外，服务器和中继代理为无状态 DHCP 服务实现以下消息；此列表中的部分编号是指 DHCP 规范：
Relay-forward：中继转发，由 DHCP 中继代理发送，将客户端消息传送到服务器（第 15.13 节）
Relay-reply：中继响应，由 DHCP 服务器发送，用于向中继代理发送响应消息（第 15.14 节）
5.2、 无状态 DHCP 服务所需的选项
客户端和服务器为无状态 DHCP 服务实现以下选项；此列表中的部分编号是指 DHCP 规范：
Option Request：选项请求，指定客户端向服务器请求的配置信息（第 22.7 节）
Status Code：状态码，用于指示完成状态或其他状态信息（第 22.13 节）
Server Identifier：服务器标识符，用于标识响应客户端请求的服务器（第 22.3 节）
服务器和中继代理为无状态 DHCP 服务实现以下选项；此列表中的部分编号是指 DHCP 规范：
Client message：客户端消息，由 DHCP 中继代理在 Relay-forward 消息中发送，以将客户端消息传送到服务器（第 20 节）
Server message：服务器消息，由 DHCP 服务器在 Relay-reply 消息中发送，以携带响应消息给中继代理（第 20 节）
Interface-ID：接口ID，由 DHCP 中继代理发送并由服务器返回，用于标识向客户端转发消息时要使用的接口（第 22.18 节）
5.3、 用于配置信息的选项
客户端和服务器使用以下选项将配置信息传递给客户端；请注意，配置信息的其他选项可能会在未来的 Internet 标准中指定：
DNS Recursive Name Servers：DNS 递归名称服务器，指定客户端用于名称解析的 DNS 递归名称服务器 [7]；请参阅“DHCPv6 的 DNS 配置选项”[3]
DNS search list：DNS搜索列表，指定名称解析时要搜索的域名；请参阅“DHCPv6 的 DNS 配置选项”[3]
SIP Servers：SIP服务器，指定客户端用于获取 IPv6 地址的域名列表的 SIP 服务器，这些地址可以映射到一个或多个 SIP 出站代理服务器 [5]
5.4、 无状态 DHCP 中使用的其他选项
客户端和服务器可以为无状态 DHCP 服务实现以下选项；此列表中的部分编号是指 DHCP 规范：
Preference：优先级，由DHCP服务器发送以指示服务器的优先级（第 22.8 节）
Elapsed time：耗时，由 DHCP 客户端发送，用于指示自客户端开始 DHCP 配置过程以来的时间（第 22.9 节）
User Class：用户类，由 DHCP 客户端发送，用于向服务器提供附加信息，以便为客户端选择配置参数（第 22.15 节）
Vendor Class：供应商类别，由 DHCP 客户端发送，用于向服务器提供有关客户端供应商和硬件的附加信息，以便为客户端选择配置参数（第 22.16 节）
Vendor-specific Information：供应商特定信息，用于在供应商定义的选项中向客户传递信息（第 22.17 节）
Client Identifier：客户端标识符，由 DHCP 客户端发送以标识自己（第 22.2 节）。客户端可以不发送此选项；如果包含在来自客户端的消息中，服务器会将选项发回
Authentication：验证，用于提供 DHCP 消息的验证（第 21 节）
6、 与DHCP交互进行地址分配
在某些网络中，可能有使用无状态地址自动配置和 DHCP 进行 DNS 配置的客户端和使用 DHCP 进行有状态地址配置的客户端。根据中继代理的部署和配置，仅用于无状态配置的 DHCP 服务器可能会从执行有状态地址配置的客户端接收消息。
只能通过信息请求/回复消息交换提供无状态配置信息的 DHCP 服务器会丢弃它接收到的任何其他 DHCP 消息。具体来说，服务器丢弃它收到的除了 Information-Request 或 Relay-forward 之外的任何消息，并且服务器不参与任何有状态地址配置消息交换。如果有其他 DHCP 服务器配置为提供有状态地址分配，则其中一台服务器将提供地址分配。
7、 安全考虑
无状态 DHCP 服务是 DHCP 规范 RFC 3315 [1] 中描述的 DHCP 服务的适当子集。因此，除了 DHCP 规范 [1] 第 21、22.11 和 23 节中讨论的内容之外，无状态 DHCP 服务没有引入额外的安全考虑。
通过无状态 DHCP 服务提供给节点的配置信息可能会引入欺骗、中间人、拒绝服务和其他攻击。这些攻击在每个携带配置信息的选项的规范中都有更详细的描述。如 DHCP 规范 [1] 的第 21 和 22.11 节所述，经过身份验证的 DHCP 可用于避免通过无状态 DHCP 服务引入的攻击。
8、 致谢
Jim Bound、Ted Lemon 和 Bernie Volz 审阅了本文档并提供了编辑建议。感谢 Peter Barany、Tim Chown、Christian Huitema、Tatuya Jinmei、Pekka Savola 和 Juha Wiljakka 的审阅和评论。
9、 参考文献
9.1、 规范性参考
[1] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
9.2、 参考资料
[3] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. [4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [5] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003. [6] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [7] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [8] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", Work in Progress.
10、 完整的版权声明
版权所有 (C) 互联网协会 (2004)。本文档受 BCP 78 中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
本文档和此处包含的信息按“原样”提供，贡献者、他/她代表或由（如果有）赞助的组织、互联网协会和互联网工程工作组不提供任何明示或暗示的，包括但不限于任何保证使用此处的信息不会侵犯任何权利或任何关于适销性或特定用途适用性的暗示保证。
知识产权
IETF 对可能声称与本文档中描述的技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或在此类权利下的任何许可可能或可能不会的程度不持任何立场能得到的;它也不表示它已做出任何独立努力来确定任何此类权利。有关 RFC 文档中权利的程序信息，请参见 BCP 78 和 BCP 79。
向 IETF 秘书处披露的 IPR 披露副本以及任何保证可用的许可，或试图获得本规范的实施者或用户使用此类专有权利的一般许可或许可的结果，可以获得来自位于 http://www.ietf.org/ipr 的 IETF 在线 IPR 存储库。
IETF 邀请任何相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施该标准可能需要的技术的其他专有权利。请将信息发送至 IETF，地址为 ietf-ipr@ietf.org。
致谢
RFC Editor 功能的资金目前由 Internet Society 提供。
