Internet Engineering Task Force (IETF) Y. Cui
Request for Comments: 7283 Q. Sun
Updates: 3315 Tsinghua University
Category: Standards Track T. Lemon
ISSN: 2070-1721 Nominum, Inc.
July 2014
Internet Engineering Task Force (IETF) Y. Cui
Request for Comments: 7283 Q. Sun
Updates: 3315 Tsinghua University
Category: Standards Track T. Lemon
ISSN: 2070-1721 Nominum, Inc.
July 2014
Handling Unknown DHCPv6 Messages
处理未知的DHCPv6消息
Abstract
摘要
DHCPv6 is not specific about handling messages with unknown types. This memo describes the problems associated with receiving DHCPv6 messages with unknown types, and defines how a DHCPv6 server, client, or relay agent should behave when receiving unknown DHCPv6 messages. This document also provides advice for authors of future documents that define new messages to be sent from DHCP servers to DHCP relay agents. This document updates RFC 3315.
DHCPv6没有具体说明如何处理具有未知类型的消息。此备忘录描述了与接收未知类型的DHCPv6消息相关的问题，并定义了DHCPv6服务器、客户端或中继代理在接收未知DHCPv6消息时的行为。本文档还为将来定义从DHCP服务器发送到DHCP中继代理的新消息的文档的作者提供建议。本文件更新了RFC 3315。
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/rfc7283.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7283.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Relay Agent Behavior Update . . . . . . . . . . . . . . . . . 3
4.1. A Valid Message for Constructing a New Relay-forward
Message . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Relaying a Message toward the Server . . . . . . . . . . 5
4.3. Relaying a Message toward the Client . . . . . . . . . . 5
5. Client and Server Behavior Update . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Relay Agent Behavior Update . . . . . . . . . . . . . . . . . 3
4.1. A Valid Message for Constructing a New Relay-forward
Message . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Relaying a Message toward the Server . . . . . . . . . . 5
4.3. Relaying a Message toward the Client . . . . . . . . . . 5
5. Client and Server Behavior Update . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6
DHCPv6 [RFC3315] provides a framework for conveying IPv6 configuration information to hosts on a TCP/IP network. But [RFC3315] is not specific about how to deal with messages with unrecognized types. This document describes the problems associated with receiving DHCPv6 messages with unknown types, and defines the behavior of a DHCPv6 server, client, or relay agent when handling unknown DHCPv6 messages.
DHCPv6[RFC3315]提供了一个框架，用于将IPv6配置信息传送到TCP/IP网络上的主机。但是[RFC3315]没有具体说明如何处理无法识别类型的消息。本文档描述了与接收未知类型的DHCPv6消息相关的问题，并定义了处理未知DHCPv6消息时DHCPv6服务器、客户端或中继代理的行为。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
When a relay agent receives a message, it sends the message toward either the server or the client. The relay agent decides on the direction to forward based on the message type. Since RFC 3315 was published, new message types have been defined. Additional message types may be defined in the future. RFC 3315 does not specify what to do when a DHCP agent does not recognize the type of message it has received. This may lead to relay agents inappropriately dropping these messages and to other DHCP agents inappropriately processing these messages.
中继代理收到消息时，会将消息发送到服务器或客户端。中继代理根据消息类型决定转发方向。自RFC 3315发布以来，定义了新的消息类型。将来可能会定义其他消息类型。RFC 3315未指定当DHCP代理无法识别其接收的消息类型时要执行的操作。这可能会导致中继代理不适当地丢弃这些消息，并导致其他DHCP代理不适当地处理这些消息。
In addition, there is no specific requirement for dealing with unknown messages by the client or server in RFC 3315.
此外，RFC 3315中对客户端或服务器处理未知消息没有具体要求。
Note that it is expected that most future DHCPv6 messages will not be used to communicate directly with relay agents (though they may need to be relayed by relay agents).
注意，预计大多数未来的DHCPv6消息将不会用于直接与中继代理通信（尽管它们可能需要由中继代理进行中继）。
Relay agents relay messages toward servers and clients according to the message type. The Relay-reply message is sent toward the client. The Relay-forward message and other types of messages are sent toward the server.
中继代理根据消息类型向服务器和客户端中继消息。中继回复消息被发送到客户端。中继转发消息和其他类型的消息被发送到服务器。
We say "toward the client" and "toward the server" because relay agents may be chained together, so a relay message may be sent through multiple relay agents along the path to its destination. Relay-reply messages specify a destination address; the relay agent extracts the encapsulated message and sends it to the specified destination address. Any message other than a Relay-reply does not
我们称之为“面向客户端”和“面向服务器”，因为中继代理可以链接在一起，所以中继消息可以通过多个中继代理沿着路径发送到目的地。中继应答消息指定目的地址；中继代理提取封装的消息并将其发送到指定的目标地址。中继回复以外的任何消息都不会
have such a specified destination, so it follows the default forwarding path configured on the relay agent, which is always toward the server.
具有这样一个指定的目的地，因此它遵循中继代理上配置的默认转发路径，该路径始终指向服务器。
The sole purpose of requiring relay agents to relay unknown messages is to ensure that when legitimate new messages are defined in the protocol, relay agents (even if they were manufactured prior to the definition of these new messages) will, by default, succeed in relaying such messages.
要求中继代理中继未知消息的唯一目的是确保当协议中定义了合法的新消息时，中继代理（即使它们是在定义这些新消息之前制造的）默认情况下将成功中继此类消息。
Section 20.1 of [RFC3315] states that:
[RFC3315]第20.1节规定：
When a relay agent receives a valid message to be relayed, it constructs a new Relay-forward message.
当中继代理接收到要中继的有效消息时，它将构造一个新的中继转发消息。
It does not define which types of messages are valid for constructing Relay-forward messages. In this document, we specify the definition as follows.
它没有定义哪些类型的消息对构造中继转发消息有效。在本文件中，我们将定义如下。
The message is valid for constructing a new Relay-forward message:
该消息对于构造新的中继转发消息有效：
(a) if the message is a Relay-forward message, or
(a) 如果消息是中继转发消息，或
(b) if the relay agent recognizes the message type and is not the intended target, or
(b) 如果中继代理识别消息类型且不是预期目标，或
(c) if the relay agent does not recognize the message type.
(c) 如果中继代理无法识别消息类型。
New DHCP message types may be defined in the future that are sent, unsolicited, to relay agents. Relay agents that do not implement these messages will not recognize the messages as being intended for them. Therefore, a relay agent that implements this specification will forward such messages to the DHCP servers to which it is configured to relay client messages.
将来可能会定义新的DHCP消息类型，这些消息类型会主动发送给中继代理。未实现这些消息的中继代理将无法识别这些消息。因此，实现此规范的中继代理将把此类消息转发到DHCP服务器，并将其配置为中继客户端消息。
At this time, no such message types have been specified. If such a message is specified in the future, it is possible that this would result in needless load on DHCP servers. If such a message type is defined in a future specification, authors may need to consider a strategy for identifying non-conforming relays and not sending such messages to those relay agents.
目前，尚未指定此类消息类型。如果将来指定这样的消息，则可能会导致DHCP服务器上出现不必要的负载。如果在未来规范中定义了这样的消息类型，则作者可能需要考虑识别不符合中继的策略，而不向中继代理发送这样的消息。
However, since DHCP servers do not respond to unknown messages, this is unlikely to create significant load and is therefore likely to be unnecessary.
但是，由于DHCP服务器不响应未知消息，因此不太可能产生显著的负载，因此可能是不必要的。
If the relay agent receives a Relay-forward message, Section 20.1.2 of [RFC3315] defines the required behavior. If the relay agent receives messages other than Relay-forward and Relay-reply and the relay agent does not recognize its message type, it MUST forward them as described in Section 20.1.1 of [RFC3315].
如果中继代理收到中继转发消息，[RFC3315]第20.1.2节定义了所需的行为。如果中继代理接收到中继转发和中继回复以外的消息，并且中继代理无法识别其消息类型，则必须按照[RFC3315]第20.1.1节中的说明进行转发。
If the relay agent receives a Relay-reply message, it MUST process the message as defined in Section 20.2 of [RFC3315], regardless of the type of message encapsulated in the Relay Message option.
如果中继代理收到中继回复消息，则它必须按照[RFC3315]第20.2节的规定处理该消息，而不管中继消息选项中封装的消息类型如何。
A client or server MUST silently discard any received DHCPv6 message with an unknown message type.
客户端或服务器必须以静默方式放弃任何接收到的消息类型未知的DHCPv6消息。
This document creates no new security issues that are not already present in RFC 3315. By explicitly documenting the correct handling of unknown messages, this document, if implemented, reduces any security exposure that might result from incorrect handling of unknown messages. The following issues are already present with Section 23 of [RFC3315], but we discuss them in detail here as guidance for implementors.
本文档不会产生RFC 3315中尚未出现的新安全问题。通过明确记录对未知消息的正确处理，本文档（如果实现的话）可以减少因错误处理未知消息而导致的任何安全风险。[RFC3315]第23节已经提出了以下问题，但我们在此详细讨论这些问题，作为实施者的指导。
As the relay agent will forward all unknown types of DHCPv6 messages, a malicious attacker can interfere with the relaying function by constructing fake DHCPv6 messages with an arbitrary type code. The same problem may occur in current DHCPv4 and DHCPv6 practice, where the attacker constructs the fake DHCP message with a known type code.
由于中继代理将转发所有未知类型的DHCPv6消息，恶意攻击者可以通过使用任意类型代码构造虚假DHCPv6消息来干扰中继功能。在当前的DHCPv4和DHCPv6实践中可能会出现相同的问题，攻击者使用已知类型代码构造假DHCP消息。
Clients and servers that implement this specification will discard unknown DHCPv6 messages. Since RFC 3315 did not specify relay agent, client, or server behavior in the presence of unknown messages, it is possible that some servers or clients that have not been updated to conform to this specification will become vulnerable to attacks through the relay agent as a result of this change.
实现此规范的客户端和服务器将丢弃未知的DHCPv6消息。由于RFC 3315未指定存在未知消息时的中继代理、客户端或服务器行为，因此，由于此更改，未更新以符合此规范的某些服务器或客户端可能会受到中继代理的攻击。
For this reason, we recommend that relay agents, clients, and servers be updated to follow this new specification. However, in most deployment scenarios, it will be much easier to attack clients directly than through a relay agent. Furthermore, attacks using unknown message types are already possible on the local wire.
因此，我们建议更新中继代理、客户端和服务器，以遵循此新规范。然而，在大多数部署场景中，直接攻击客户端比通过中继代理更容易。此外，使用未知消息类型的攻击在本地线路上已经是可能的。
So, in most cases, if clients are not upgraded, there should be minimal additional risk. At sites where only servers and relay agents can be upgraded, the incremental benefit of doing so most likely exceeds any risk of vulnerable clients.
因此，在大多数情况下，如果客户机没有升级，那么额外的风险应该最小。在只有服务器和中继代理可以升级的站点，这样做的增量好处很可能超过易受攻击客户端的任何风险。
Nothing in this update should be construed to mean that relay agents may not be administratively configurable to drop messages based on the message type, for security reasons (e.g., in a firewall).
此更新中的任何内容都不应解释为，出于安全原因（例如，在防火墙中），中继代理在管理上可能无法配置为根据消息类型丢弃消息。
Many thanks to Bernie Volz, Tomek Mrugalski, Sheng Jiang, Cong Liu, and Yuchi Chen for their contributions to the document.
非常感谢Bernie Volz、Tomek Mrugalski、Sheng Jiang、Cong Liu和Yuchi Chen对该文件的贡献。
[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., 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.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
Authors' Addresses
作者地址
Yong Cui Tsinghua University Beijing 100084 P.R. China
清华大学北京100084
Phone: +86-10-6260-3059
EMail: yong@csnet1.cs.tsinghua.edu.cn
Phone: +86-10-6260-3059
EMail: yong@csnet1.cs.tsinghua.edu.cn
Qi Sun Tsinghua University Beijing 100084 P.R. China
齐孙清华大学中国北京100084
Phone: +86-10-6278-5822
EMail: sunqi@csnet1.cs.tsinghua.edu.cn
Phone: +86-10-6278-5822
EMail: sunqi@csnet1.cs.tsinghua.edu.cn
Ted Lemon Nominum, Inc. 2000 Seaport Blvd Redwood City, CA 94063 USA
美国加利福尼亚州红木市海港大道2000号Ted Lemon Nominum公司，邮编94063
Phone: +1-650-381-6000
EMail: Ted.Lemon@nominum.com
Phone: +1-650-381-6000
EMail: Ted.Lemon@nominum.com