Internet Engineering Task Force (IETF) T. Lemon
Request for Comments: 6422 Nominum
Updates: 3315 Q. Wu
Category: Standards Track Huawei
ISSN: 2070-1721 December 2011
Internet Engineering Task Force (IETF) T. Lemon
Request for Comments: 6422 Nominum
Updates: 3315 Q. Wu
Category: Standards Track Huawei
ISSN: 2070-1721 December 2011
Relay-Supplied DHCP Options
中继提供的DHCP选项
Abstract
摘要
DHCPv6 relay agents cannot communicate with DHCPv6 clients directly. However, in some cases, the relay agent possesses some information that would be useful to the DHCPv6 client. This document describes a mechanism whereby the DHCPv6 relay agent can provide such information to the DHCPv6 server, which can, in turn, pass this information on to the DHCP client.
DHCPv6中继代理无法直接与DHCPv6客户端通信。但是，在某些情况下，中继代理拥有一些对DHCPv6客户机有用的信息。本文档描述了DHCPv6中继代理可以向DHCPv6服务器提供此类信息的机制，DHCPv6服务器可以将此信息传递给DHCP客户端。
This document updates RFC 3315 (DHCPv6) by making explicit the implicit requirement that relay agents not modify the content of encapsulation payloads as they are relayed back toward clients.
本文档对RFC 3315（DHCPv6）进行了更新，明确了中继代理在将封装有效负载中继回客户端时不修改其内容的隐含要求。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6422.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6422.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
1.2. Terminology ................................................3
2. Protocol Summary ................................................3
3. Encoding ........................................................3
4. RSOO-Enabled Options ............................................4
5. DHCP Relay Agent Behavior .......................................4
6. DHCP Server Behavior ............................................5
7. Security Considerations .........................................6
8. IANA Considerations .............................................7
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................7
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
1.2. Terminology ................................................3
2. Protocol Summary ................................................3
3. Encoding ........................................................3
4. RSOO-Enabled Options ............................................4
5. DHCP Relay Agent Behavior .......................................4
6. DHCP Server Behavior ............................................5
7. Security Considerations .........................................6
8. IANA Considerations .............................................7
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................7
The DHCPv6 specification [RFC3315] allows DHCP relay agents to forward DHCPv6 messages between clients and servers that are not on the same IPv6 link. In some cases, the DHCP relay agent has information not available to the DHCP server that would be useful to provide to a DHCP client. For example, the DHCP client may need to learn the EAP Re-authentication Protocol (ERP) local domain name [RFC6440] for use in EAP re-authentication [RFC5296], which is known to the relay agent but not the server.
DHCPv6规范[RFC3315]允许DHCP中继代理在不在同一IPv6链路上的客户端和服务器之间转发DHCPv6消息。在某些情况下，DHCP中继代理具有DHCP服务器不可用的信息，这些信息可用于向DHCP客户端提供。例如，DHCP客户端可能需要学习EAP重新认证协议（ERP）本地域名[RFC6440]，以便在EAP重新认证[RFC5296]中使用，中继代理知道该域名，但服务器不知道。
The DHCPv6 protocol specification does not provide a mechanism whereby the relay agent can provide options to the client. This document extends DHCP with a mechanism that allows DHCP relay agents to propose options for the server to send to DHCP clients.
DHCPv6协议规范没有提供中继代理可以向客户端提供选项的机制。本文档使用一种机制扩展了DHCP，该机制允许DHCP中继代理为服务器向DHCP客户端发送建议选项。
This document is not intended to provide a general mechanism for storing client configuration information in the relay agent. Rather, it is intended to address specific use cases where only the relay agent has information needed by the client. This extension is not applicable to DHCP options in general, but rather provided as a mechanism for new specifications that require this functionality.
本文档无意提供在中继代理中存储客户端配置信息的一般机制。相反，它旨在解决只有中继代理具有客户机所需信息的特定用例。此扩展一般不适用于DHCP选项，而是作为需要此功能的新规范的机制提供。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The following terms and acronyms are used in this document:
本文件中使用了以下术语和首字母缩略词：
o DHCP: Dynamic Host Configuration Protocol Version 6 [RFC3315]
o DHCP:动态主机配置协议版本6[RFC3315]
o RSOO: Relay-Supplied Options option
o RSOO：继电器提供的选项
DHCP clients do not support a mechanism for receiving options from relay agents -- the relay agent is required to deliver the payload from the DHCP server to the DHCP client without changing it. In order for the DHCP relay agent to provide options to the client, it sends those options to the DHCP server, encapsulated in an RSOO. The DHCP server can then choose to place those options in the response it sends to the client.
DHCP客户端不支持从中继代理接收选项的机制——中继代理需要在不更改负载的情况下将负载从DHCP服务器传送到DHCP客户端。为了让DHCP中继代理向客户端提供选项，它将这些选项发送到封装在RSOO中的DHCP服务器。然后，DHCP服务器可以选择将这些选项放在它发送给客户端的响应中。
In order to supply options for the DHCP server to send to the client, the relay agent sends an RSOO in the Relay-Forward message. This option encapsulates whatever options the relay agent wishes to provide to the DHCPv6 server.
为了提供DHCP服务器发送到客户端的选项，中继代理在中继转发消息中发送RSOO。此选项封装中继代理希望提供给DHCPv6服务器的任何选项。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RSOO | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options...
+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RSOO | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options...
+-+-+-+-+-+-+-+-+-+-+-+
OPTION_RSOO
选择权
Relay-Supplied Options code (66).
继电器提供的选项代码（66）。
option-length
选项长度
Length of the RSOO.
RSOO的长度。
options
选择权
One or more DHCPv6 options.
一个或多个DHCPv6选项。
The RSOO MUST NOT contain any option that is not specifically called out as an RSOO-enabled option. Specifications that describe RSOO-enabled options MUST reference this specification, and MUST state that the option they define is RSOO-enabled. No DHCP option specified prior to the issuance of this specification is RSOO-enabled.
RSOO不得包含任何未被指定为启用RSOO选项的选项。描述支持RSOO的选项的规范必须引用此规范，并且必须说明它们定义的选项是支持RSOO的。在发布本规范之前未指定任何已启用RSOO的DHCP选项。
A current list of RSOO-enabled options can be found in the list titled "Options Permitted in the Relay-Supplied Options Option" maintained at http://www.iana.org/.
RSOO启用选项的当前列表可在维护的标题为“继电器提供选项中允许的选项”的列表中找到http://www.iana.org/.
DHCP option specifications that define RSOO-enabled options MUST add text similar to the following to their IANA Considerations section; "random relay option" should be replaced with the name of the option being defined in the specification:
定义RSOO启用选项的DHCP选项规范必须在其IANA注意事项部分添加类似于以下内容的文本；“随机继电器选项”应替换为规范中定义的选项名称：
We request that IANA add the name "random relay option" to the registry titled "Options Permitted in the Relay-Supplied Options Option" maintained at http://www.iana.org/.
我们要求IANA将名称“随机中继选项”添加到维护在的名为“中继提供的选项中允许的选项”的注册表中http://www.iana.org/.
Relay agents MAY include an RSOO in the option payload of a Relay-Forward message being sent toward a DHCP server. When relaying the payload of Relay-Reply messages toward clients, relay agents MUST NOT modify the payload.
中继代理可以在向DHCP服务器发送的中继转发消息的选项有效负载中包括RSOO。在向客户端中继中继中继回复消息的有效负载时，中继代理不得修改有效负载。
Relay agents MUST NOT send non-RSOO-enabled options in the Relay-Supplied Options option.
中继代理不得发送中继提供的选项中未启用RSOO的选项。
In order to allow network administrators to control the flow of RSOO options onto the network, relay agents that implement the Relay-Supplied Options option need to have a configuration parameter that determines whether or not they will relay Relay-Forward messages containing RSOOs.
为了允许网络管理员控制网络上的RSOO选项流，实现中继提供的选项选项的中继代理需要具有一个配置参数，该参数确定它们是否将中继转发包含RSOO的消息。
Relay agents that have this configuration parameter and that are configured to disable forwarding of a Relay-Forward message containing an RSOO MUST silently discard any such message.
具有此配置参数且配置为禁用包含RSOO的中继转发消息转发的中继代理必须以静默方式放弃任何此类消息。
Implementations that can be configured in this way MUST examine all Relay-Forward encapsulations, not just the outer encapsulation.
以这种方式配置的实现必须检查所有中继转发封装，而不仅仅是外部封装。
DHCP servers that implement this protocol specification MUST examine each option contained in an RSOO to see if it is an RSOO-enabled option. DHCP servers MUST silently discard any option contained in an RSOO that is not RSOO-enabled. DHCP server implementations SHOULD have an administrator-configurable list of RSOO-enabled options, so that new RSOO-enabled options do not require software to be updated.
实现此协议规范的DHCP服务器必须检查RSOO中包含的每个选项，以查看它是否是启用RSOO的选项。DHCP服务器必须以静默方式放弃RSOO中未启用RSOO的任何选项。DHCP服务器实现应具有管理员可配置的RSOO启用选项列表，以便新的RSOO启用选项不需要更新软件。
DHCP servers normally construct a list of options that are candidates to send to the DHCP client, and then construct the DHCP packet according to Section 17.2.2 of the DHCPv6 specification [RFC3315].
DHCP服务器通常构造一个选项列表，这些选项是发送到DHCP客户端的候选选项，然后根据DHCPv6规范[RFC3315]第17.2.2节构造DHCP数据包。
If the server implementing this protocol specification receives an RSOO, it SHOULD add any options that appear in the RSOO for which it has no internal candidate to the list of options that are candidates to send to the DHCP client. The server SHOULD discard any options that appear in the RSOO for which it already has one or more candidates.
如果实现此协议规范的服务器接收到RSOO，则应将RSOO中显示的、没有内部候选项的任何选项添加到要发送到DHCP客户端的候选选项列表中。服务器应该放弃RSOO中出现的任何选项，因为它已经有一个或多个候选项。
Aside from the addition of options from the RSOO, the DHCP server should then construct a DHCP packet as it normally would, and transmit it to the DHCP client as described in [RFC3315].
除了从RSOO添加选项外，DHCP服务器还应按照正常方式构造DHCP数据包，并按照[RFC3315]中的说明将其传输到DHCP客户端。
DHCP servers may receive multiply-nested Relay-Forward messages containing conflicting values for options contained in RSOOs in these messages.
DHCP服务器可能会收到多个嵌套中继转发消息，其中包含这些消息中RSOOs中包含的选项的冲突值。
When such a conflict exists, the DHCP server MUST choose no more than one of these options to forward to the client. The DHCP server MUST NOT forward more than one of these options to the client.
当存在此类冲突时，DHCP服务器只能选择其中一个选项转发到客户端。DHCP服务器不得将这些选项中的多个转发到客户端。
By default, the DHCP server MUST choose the innermost value -- the value supplied by the relay agent closest to the DHCP client -- to forward to the DHCP client.
默认情况下，DHCP服务器必须选择最里面的值——最靠近DHCP客户端的中继代理提供的值——转发到DHCP客户端。
DHCP server implementations MAY provide other heuristics for choosing which one of a set of such conflicting options to forward to the client, as long as the specified behavior is the default behavior.
只要指定的行为是默认行为，DHCP服务器实现可以提供其他启发式方法来选择将一组冲突选项中的哪一个转发给客户端。
This document provides a mechanism whereby a relay agent can inject options into the response the DHCP server sends to the DHCP client. In currently known use cases -- for example, the ERP Local Domain Option [RFC6440] -- RSOO-enabled options are options that will only ever originate on a relay agent, and do not make sense when originating on a DHCP server.
本文档提供了一种机制，中继代理可以在DHCP服务器发送给DHCP客户端的响应中插入选项。在当前已知的用例中——例如，ERP本地域选项[RFC6440]——启用RSOO的选项是仅在中继代理上发起的选项，在DHCP服务器上发起时没有意义。
In the event that some new RSOO-enabled option is specified that can originate from either the server or the relay agent, this should be addressed in the Security Considerations section of the document that specifies the use of that option.
如果指定了某个新的启用RSOO的选项，该选项可以来自服务器或中继代理，则应在指定该选项使用的文档的“安全注意事项”部分中说明。
In some environments, there is an interface on one side of which is the client, and zero or more routers, and on the other side of which is a network managed by a monolithic or effectively monolithic administrative entity. Nodes and routers on the client side of the interface are not controlled by this entity, and are considered "untrusted". Nodes and routers on the network side of this interface are considered trusted.
在某些环境中，有一个接口，其一端是客户机和零个或多个路由器，另一端是由单片或有效单片管理实体管理的网络。接口客户端上的节点和路由器不受此实体控制，被视为“不受信任”。此接口网络侧的节点和路由器被视为受信任的。
It is possible for a malicious node acting as a relay agent on the untrusted side of this interface to supply an RSOO containing one or more RSOO-enabled options that would override the same option or options that were provided by a relay agent on the trusted side of the interface.
作为此接口不受信任端的中继代理的恶意节点可能会提供包含一个或多个启用RSOO的选项的RSOO，这些选项将覆盖接口受信任端的中继代理提供的相同选项。
In environments where this is a possibility, network administrators are advised to use relay agents that are capable of dropping Relay-Forward messages containing the RSOO, and are advised to configure those relay agents to drop such messages.
在可能出现这种情况的环境中，建议网络管理员使用能够删除包含RSOO的中继转发消息的中继代理，并建议将这些中继代理配置为删除此类消息。
Note, however, that this will only be effective if the message from the DHCP server to the DHCP client is authenticated as specified in Section 21 of [RFC3315], or using some similar mechanism. Without this authentication, the malicious node on the untrusted portion of the network can simply modify the DHCP server's response in transit back to the DHCP client, and there is no way for the client to detect that this has happened.
但是，请注意，只有当从DHCP服务器发送到DHCP客户端的消息按照[RFC3315]第21节的规定进行了身份验证，或者使用了某种类似的机制时，这才有效。如果没有此身份验证，网络不受信任部分的恶意节点可以简单地修改传输回DHCP客户端的DHCP服务器响应，客户端无法检测到发生了这种情况。
IANA has assigned one new DHCPv6 option code from the registry of DHCP Option Codes maintained at http://www.iana.org/. The option code 66 (OPTION_RSOO) has been assigned to the Relay-Supplied Options option.
IANA已从位于的DHCP选项代码注册表中分配了一个新的DHCPv6选项代码http://www.iana.org/. 选项代码66（选项）已分配给继电器提供的选项。
IANA has created a new registry on the same assignments page, titled "Options Permitted in the Relay-Supplied Options Option". This registry will enumerate the set of all code points from the DHCP Option Codes table for options that may appear in the RSOO. Options may be added to this list after IETF Review [RFC5226]. When adding options to the list, please ensure that the description for the code added matches the description in the DHCP Option Codes table for that code. Option codes that have not been requested to be added according to the stated procedure should not be mentioned at all in the table, and should not be listed as "reserved" or "unassigned".
IANA在同一个分配页面上创建了一个新的注册表，标题为“继电器提供的选项中允许的选项”。此注册表将枚举DHCP选项代码表中可能出现在RSOO中的选项的所有代码点集。在IETF审查[RFC5226]后，可将选项添加到此列表中。向列表中添加选项时，请确保所添加代码的说明与DHCP选项代码表中该代码的说明相匹配。表中不应提及未根据规定程序要求添加的选项代码，也不应将其列为“保留”或“未指定”。
IETF Review should include careful consideration of the security implications of allowing a relay agent to provide a value for the option being considered for addition to this registry. In the case where an IETF working group chartered to review DHCP protocol extensions exists, it is not sufficient for some other working group to review the registry addition.
IETF审查应包括仔细考虑允许中继代理为考虑添加到此注册表的选项提供值的安全影响。如果存在特许审查DHCP协议扩展的IETF工作组，则其他工作组审查注册表添加是不够的。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3315] 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.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-authentication Protocol (ERP)", RFC 5296, August 2008.
[RFC5296]Narayanan，V.和L.Dondeti，“EAP再认证协议（ERP）的EAP扩展”，RFC 52962008年8月。
[RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, December 2011.
[RFC6440]Zorn，G.，Wu，Q.，和Y.Wang，“EAP重新认证协议（ERP）本地域名DHCPv6选项”，RFC 64402011年12月。
Authors' Addresses
作者地址
Ted Lemon Nominum 2000 Seaport Blvd. Redwood City, CA 94063 USA
泰德·莱蒙·诺米姆海港大道2000号。美国加利福尼亚州红木市94063
Phone: +1 650 381 6000
EMail: mellon@nominum.com
Phone: +1 650 381 6000
EMail: mellon@nominum.com
Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
中国江苏省南京市雨花区软件大道101号秦武华为技术有限公司210012
Phone: +86-25-56623633
EMail: sunseawq@huawei.com
Phone: +86-25-56623633
EMail: sunseawq@huawei.com