Network Working Group R. Droms, Editor
Request for Comments: 3118 Cisco Systems
Category: Standards Track W. Arbaugh, Editor
University of Maryland
June 2001
Network Working Group R. Droms, Editor
Request for Comments: 3118 Cisco Systems
Category: Standards Track W. Arbaugh, Editor
University of Maryland
June 2001
Authentication for DHCP Messages
DHCP消息的身份验证
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document defines a new Dynamic Host Configuration Protocol (DHCP) option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. DHCP provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts. Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages.
本文档定义了一个新的动态主机配置协议（DHCP）选项，通过该选项可以轻松生成授权票证，并且可以从经过身份验证的DHCP服务器自动配置具有适当授权的新连接主机。DHCP提供了一个框架，用于将配置信息传递给TCP/IP网络上的主机。在某些情况下，网络管理员可能希望限制向授权主机分配地址。此外，一些网络管理员可能希望提供DHCP消息源和内容的身份验证。
DHCP [1] transports protocol stack configuration parameters from centrally administered servers to TCP/IP hosts. Among those parameters are an IP address. DHCP servers can be configured to dynamically allocate addresses from a pool of addresses, eliminating a manual step in configuration of TCP/IP hosts.
DHCP[1]将协议栈配置参数从集中管理的服务器传输到TCP/IP主机。这些参数中有一个IP地址。DHCP服务器可以配置为从地址池中动态分配地址，从而消除了TCP/IP主机配置中的手动步骤。
Some network administrators may wish to provide authentication of the source and contents of DHCP messages. For example, clients may be subject to denial of service attacks through the use of bogus DHCP servers, or may simply be misconfigured due to unintentionally instantiated DHCP servers. Network administrators may wish to constrain the allocation of addresses to authorized hosts to avoid denial of service attacks in "hostile" environments where the network
一些网络管理员可能希望提供DHCP消息源和内容的身份验证。例如，客户端可能会通过使用伪造的DHCP服务器受到拒绝服务攻击，或者可能只是由于无意中实例化了DHCP服务器而配置错误。网络管理员可能希望限制对授权主机的地址分配，以避免在网络受到攻击的“敌对”环境中发生拒绝服务攻击
medium is not physically secured, such as wireless networks or college residence halls.
媒体没有物理安全，如无线网络或大学宿舍。
This document defines a technique that can provide both entity authentication and message authentication. The current protocol combines the original Schiller-Huitema-Droms authentication mechanism defined in a previous work in progress with the "delayed authentication" proposal developed by Bill Arbaugh.
本文档定义了一种可以同时提供实体身份验证和消息身份验证的技术。目前的协议将先前正在进行的工作中定义的原始Schiller-Huitema Droms认证机制与Bill Arbaugh开发的“延迟认证”方案相结合。
The threat to DHCP is inherently an insider threat (assuming a properly configured network where BOOTP ports are blocked on the enterprise's perimeter gateways.) Regardless of the gateway configuration, however, the potential attacks by insiders and outsiders are the same.
对DHCP的威胁本质上是一种内部威胁（假设一个配置正确的网络，其中BOOTP端口在企业的外围网关上被阻塞）。但是，无论网关配置如何，内部人和外部人的潜在攻击都是相同的。
The attack specific to a DHCP client is the possibility of the establishment of a "rogue" server with the intent of providing incorrect configuration information to the client. The motivation for doing so may be to establish a "man in the middle" attack or it may be for a "denial of service" attack.
针对DHCP客户端的攻击可能是建立“恶意”服务器，目的是向客户端提供不正确的配置信息。这样做的动机可能是建立“中间人”攻击，也可能是“拒绝服务”攻击。
There is another threat to DHCP clients from mistakenly or accidentally configured DHCP servers that answer DHCP client requests with unintentionally incorrect configuration parameters.
错误或意外配置的DHCP服务器会对DHCP客户端造成另一种威胁，这些服务器会使用不正确的配置参数响应DHCP客户端请求。
The threat specific to a DHCP server is an invalid client masquerading as a valid client. The motivation for this may be for "theft of service", or to circumvent auditing for any number of nefarious purposes.
DHCP服务器特有的威胁是伪装为有效客户端的无效客户端。这样做的动机可能是为了“窃取服务”，或为了任何邪恶目的规避审计。
The threat common to both the client and the server is the resource "denial of service" (DoS) attack. These attacks typically involve the exhaustion of valid addresses, or the exhaustion of CPU or network bandwidth, and are present anytime there is a shared resource. In current practice, redundancy mitigates DoS attacks the best.
客户端和服务器共同面临的威胁是资源“拒绝服务”（DoS）攻击。这些攻击通常涉及耗尽有效地址，或耗尽CPU或网络带宽，并且在存在共享资源时随时存在。在当前实践中，冗余最能缓解DoS攻击。
These are the goals that were used in the development of the authentication protocol, listed in order of importance:
以下是认证协议开发中使用的目标，按重要性顺序列出：
1. Address the threats presented in Section 1.1. 2. Avoid changing the current protocol.
1. 解决第1.1节中提出的威胁。2.避免更改当前协议。
3. Limit state required by the server. 4. Limit complexity (complexity breeds design and implementation errors).
3. 服务器所需的限制状态。4.限制复杂性（复杂性导致设计和实现错误）。
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 [5].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释。
This document uses the following terms:
本文件使用以下术语：
o "DHCP client"
o “DHCP客户端”
A DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address.
DHCP客户端或“客户端”是使用DHCP获取配置参数（如网络地址）的Internet主机。
o "DHCP server"
o “DHCP服务器”
A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients.
DHCP服务器或“服务器”是向DHCP客户端返回配置参数的Internet主机。
The following diagram defines the format of the DHCP authentication option:
下图定义了DHCP身份验证选项的格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | |
+-+-+-+-+-+-+-+-+ |
| |
| Authentication Information |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Protocol | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | |
+-+-+-+-+-+-+-+-+ |
| |
| Authentication Information |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code for the authentication option is 90, and the length field contains the length of the protocol, RDM, algorithm, Replay Detection fields and authentication information fields in octets.
身份验证选项的代码为90，长度字段包含协议的长度、RDM、算法、重播检测字段和身份验证信息字段（以八位字节为单位）。
The protocol field defines the particular technique for authentication used in the option. New protocols are defined as described in Section 6.
协议字段定义选项中使用的特定身份验证技术。新协议的定义如第6节所述。
The algorithm field defines the specific algorithm within the technique identified by the protocol field.
算法字段定义协议字段标识的技术中的特定算法。
The Replay Detection field is per the RDM, and the authentication information field is per the protocol in use.
重播检测字段根据RDM，身份验证信息字段根据正在使用的协议。
The Replay Detection Method (RDM) field determines the type of replay detection used in the Replay Detection field.
重播检测方法（RDM）字段确定重播检测字段中使用的重播检测类型。
If the RDM field contains 0x00, the replay detection field MUST be set to the value of a monotonically increasing counter. Using a counter value such as the current time of day (e.g., an NTP-format timestamp [4]) can reduce the danger of replay attacks. This method MUST be supported by all protocols.
如果RDM字段包含0x00，则重播检测字段必须设置为单调递增计数器的值。使用计数器值，例如一天中的当前时间（例如，NTP格式的时间戳[4]）可以减少重播攻击的危险。所有协议都必须支持此方法。
Because a DHCP relay agent may alter the values of the 'giaddr' and 'hops' fields in the DHCP message, the contents of those two fields MUST be set to zero for the computation of any hash function over the message header. Additionally, a relay agent may append the DHCP relay agent information option 82 [7] as the last option in a message to servers. If a server finds option 82 included in a received message, the server MUST compute any hash function as if the option were NOT included in the message without changing the order of options. Whenever the server sends back option 82 to a relay agent, the server MUST not include the option in the computation of any hash function over the message.
由于DHCP中继代理可能会更改DHCP消息中“giaddr”和“hops”字段的值，因此必须将这两个字段的内容设置为零，以便计算消息头上的任何哈希函数。此外，中继代理可以将DHCP中继代理信息选项82[7]作为消息中的最后一个选项附加到服务器。如果服务器发现接收到的消息中包含选项82，则服务器必须在不更改选项顺序的情况下计算任何哈希函数，就像该选项未包含在消息中一样。每当服务器将选项82发回中继代理时，服务器不得将该选项包括在消息上任何哈希函数的计算中。
If the protocol field is 0, the authentication information field holds a simple configuration token:
如果协议字段为0，则身份验证信息字段包含一个简单的配置令牌：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | |
|-+-+-+-+-+-+-+-+ |
| |
| Authentication Information |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | |
|-+-+-+-+-+-+-+-+ |
| |
| Authentication Information |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The configuration token is an opaque, unencoded value known to both the sender and receiver. The sender inserts the configuration token in the DHCP message and the receiver matches the token from the message to the shared token. If the configuration option is present and the token from the message does not match the shared token, the receiver MUST discard the message.
配置令牌是发送方和接收方都知道的不透明、未编码的值。发送方在DHCP消息中插入配置令牌，接收方将消息中的令牌与共享令牌进行匹配。如果存在配置选项，并且消息中的令牌与共享令牌不匹配，则接收方必须丢弃消息。
Configuration token may be used to pass a plain-text configuration token and provides only weak entity authentication and no message authentication. This protocol is only useful for rudimentary protection against inadvertently instantiated DHCP servers.
配置令牌可用于传递纯文本配置令牌，只提供弱实体身份验证，不提供消息身份验证。此协议仅用于防止意外实例化DHCP服务器的基本保护。
DISCUSSION:
讨论：
The intent here is to pass a constant, non-computed token such as a plain-text password. Other types of entity authentication using computed tokens such as Kerberos tickets or one-time passwords will be defined as separate protocols.
这里的目的是传递一个常量、非计算令牌，例如纯文本密码。使用计算令牌（如Kerberos票证或一次性密码）的其他类型的实体身份验证将被定义为单独的协议。
If the protocol field is 1, the message is using the "delayed authentication" mechanism. In delayed authentication, the client requests authentication in its DHCPDISCOVER message and the server replies with a DHCPOFFER message that includes authentication information. This authentication information contains a nonce value generated by the source as a message authentication code (MAC) to provide message authentication and entity authentication.
如果协议字段为1，则消息使用“延迟身份验证”机制。在延迟身份验证中，客户端在其DHCPDISCOVER消息中请求身份验证，服务器使用包含身份验证信息的DHCPOFFER消息进行回复。此身份验证信息包含由源生成的作为消息身份验证码（MAC）的nonce值，以提供消息身份验证和实体身份验证。
This document defines the use of a particular technique based on the HMAC protocol [3] using the MD5 hash [2].
本文档使用MD5散列[2]定义了基于HMAC协议[3]的特定技术的使用。
The "delayed authentication" protocol does not attempt to address situations where a client may roam from one administrative domain to another, i.e., interdomain roaming. This protocol is focused on solving the intradomain problem where the out-of-band exchange of a shared secret is feasible.
“延迟认证”协议不试图解决客户端可能从一个管理域漫游到另一个管理域的情况，即域间漫游。该协议致力于解决域内共享秘密带外交换可行的问题。
The format of the authentication request in a DHCPDISCOVER or a DHCPINFORM message for delayed authentication is:
用于延迟身份验证的DHCPDISCOVER或DHCPINFORM消息中的身份验证请求格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |0 0 0 0 0 0 0 1| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |0 0 0 0 0 0 0 1| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+
The format of the authentication information in a DHCPOFFER, DHCPREQUEST or DHCPACK message for delayed authentication is:
用于延迟身份验证的DHCPOFFER、DHCPREQUEST或DHCPACK消息中的身份验证信息格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |0 0 0 0 0 0 0 1| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | Secret ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| secret id cont| HMAC-MD5 (128 bits) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |0 0 0 0 0 0 0 1| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RDM | Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay cont. | Secret ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| secret id cont| HMAC-MD5 (128 bits) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following definitions will be used in the description of the authentication information for delayed authentication, algorithm 1:
以下定义将用于描述延迟认证算法1的认证信息：
Replay Detection - as defined by the RDM field K - a secret value shared between the source and destination of the message; each secret has a unique identifier (secret ID) secret ID - the unique identifier for the secret value used to generate the MAC for this message HMAC-MD5 - the MAC generating function [3, 2].
重播检测-由RDM字段K定义-消息源和目的地之间共享的秘密值；每个机密都有一个唯一标识符（secret ID）secret ID-用于生成此消息的MAC的机密值的唯一标识符HMAC-MD5-MAC生成函数[3，2]。
The sender computes the MAC using the HMAC generation algorithm [3] and the MD5 hash function [2]. The entire DHCP message (except as noted below), including the DHCP message header and the options field, is used as input to the HMAC-MD5 computation function. The 'secret ID' field MUST be set to the identifier of the secret used to generate the MAC.
发送方使用HMAC生成算法[3]和MD5哈希函数[2]计算MAC。整个DHCP消息（以下说明除外），包括DHCP消息头和选项字段，用作HMAC-MD5计算函数的输入。“机密ID”字段必须设置为用于生成MAC的机密的标识符。
DISCUSSION:
讨论：
Algorithm 1 specifies the use of HMAC-MD5. Use of a different technique, such as HMAC-SHA, will be specified as a separate protocol.
算法1指定HMAC-MD5的使用。使用不同的技术，如HMAC-SHA，将被指定为单独的协议。
Delayed authentication requires a shared secret key for each client on each DHCP server with which that client may wish to use the DHCP protocol. Each secret key has a unique identifier that can be used by a receiver to determine which secret was used to generate the MAC in the DHCP message. Therefore, delayed authentication may not scale well in an architecture in which a DHCP client connects to multiple administrative domains.
延迟身份验证要求每个DHCP服务器上的每个客户端都有一个共享密钥，该客户端可能希望使用DHCP协议。每个密钥都有一个唯一的标识符，接收方可以使用该标识符来确定用于在DHCP消息中生成MAC的密钥。因此，在DHCP客户端连接到多个管理域的体系结构中，延迟身份验证可能无法很好地扩展。
To validate an incoming message, the receiver first checks that the value in the replay detection field is acceptable according to the replay detection method specified by the RDM field. Next, the receiver computes the MAC as described in [3]. The receiver MUST set the 'MAC' field of the authentication option to all 0s for computation of the MAC, and because a DHCP relay agent may alter the values of the 'giaddr' and 'hops' fields in the DHCP message, the contents of those two fields MUST also be set to zero for the computation of the MAC. If the MAC computed by the receiver does not match the MAC contained in the authentication option, the receiver MUST discard the DHCP message.
为了验证传入消息，接收器首先根据RDM字段指定的重播检测方法检查重播检测字段中的值是否可接受。接下来，接收机按照[3]中所述计算MAC。接收方必须将身份验证选项的“MAC”字段设置为所有0以计算MAC，并且由于DHCP中继代理可能会更改DHCP消息中的“giaddr”和“hops”字段的值，因此这两个字段的内容也必须设置为零以计算MAC。如果接收方计算的MAC与身份验证选项中包含的MAC不匹配，则接收方必须丢弃DHCP消息。
Section 3 provides additional information on handling messages that include option 82 (Relay Agents).
第3节提供了关于处理包含选项82（中继代理）的消息的附加信息。
Each DHCP client has a key, K. The client uses its key to encode any messages it sends to the server and to authenticate and verify any messages it receives from the server. The client's key SHOULD be initially distributed to the client through some out-of-band mechanism, and SHOULD be stored locally on the client for use in all authenticated DHCP messages. Once the client has been given its key, it SHOULD use that key for all transactions even if the client's configuration changes; e.g., if the client is assigned a new network address.
每个DHCP客户端都有一个密钥K。客户端使用其密钥对发送到服务器的任何消息进行编码，并对从服务器接收到的任何消息进行身份验证和验证。客户端的密钥最初应该通过一些带外机制分发给客户端，并且应该本地存储在客户端上，以便在所有经过身份验证的DHCP消息中使用。一旦客户机获得其密钥，即使客户机的配置发生变化，它也应在所有事务中使用该密钥；e、 例如，如果客户机被分配了一个新的网络地址。
Each DHCP server MUST know, or be able to obtain in a secure manner, the keys for all authorized clients. If all clients use the same key, clients can perform both entity and message authentication for all messages received from servers. However, the sharing of keys is strongly discouraged as it allows for unauthorized clients to masquerade as authorized clients by obtaining a copy of the shared key. To authenticate the identity of individual clients, each client MUST be configured with a unique key. Appendix A describes a technique for key management.
每个DHCP服务器必须知道或能够以安全的方式获得所有授权客户端的密钥。如果所有客户端使用相同的密钥，则客户端可以对从服务器接收的所有消息执行实体和消息身份验证。但是，强烈反对共享密钥，因为它允许未经授权的客户端通过获取共享密钥的副本伪装为授权客户端。要验证各个客户端的身份，必须使用唯一密钥配置每个客户端。附录A描述了一种密钥管理技术。
This section describes the behavior of a DHCP client using delayed authentication.
本节介绍使用延迟身份验证的DHCP客户端的行为。
When in INIT state, the client uses delayed authentication as follows:
当处于INIT状态时，客户端使用延迟身份验证，如下所示：
1. The client MUST include the authentication request option in its DHCPDISCOVER message along with a client identifier option [6] to identify itself uniquely to the server.
1. 客户机必须在其DHCPDISCOVER消息中包含身份验证请求选项以及客户机标识符选项[6]，以便为服务器唯一地标识自己。
2. The client MUST perform the validation test described in section 5.3 on any DHCPOFFER messages that include authentication information. If one or more DHCPOFFER messages pass the validation test, the client chooses one of the offered configurations.
2. 客户必须对任何包含身份验证信息的DHCPOFFER消息执行第5.3节所述的验证测试。如果一个或多个DHCPOFFERE消息通过了验证测试，则客户端将选择提供的配置之一。
Client behavior if no DHCPOFFER messages include authentication information or pass the validation test is controlled by local policy in the client. According to client policy, the client MAY choose to respond to a DHCPOFFER message that has not been authenticated.
如果没有包含身份验证信息或通过验证测试的DHCPOFFER消息，则客户端行为由客户端中的本地策略控制。根据客户端策略，客户端可以选择响应未经身份验证的DHCPOFFER消息。
The decision to set local policy to accept unauthenticated messages should be made with care. Accepting an unauthenticated DHCPOFFER message can make the client vulnerable to spoofing and other attacks. If local users are not explicitly informed that the client has accepted an unauthenticated DHCPOFFER message, the users may incorrectly assume that the client has received an authenticated address and is not subject to DHCP attacks through unauthenticated messages.
应谨慎决定是否设置本地策略以接受未经验证的邮件。接受未经验证的DHCPOFFER消息会使客户端容易受到欺骗和其他攻击。如果未明确告知本地用户客户端已接受未经验证的DHCPOFFER消息，则用户可能会错误地认为客户端已收到经验证的地址，并且未通过未经验证的消息受到DHCP攻击。
A client MUST be configurable to decline unauthenticated messages, and SHOULD be configured by default to decline unauthenticated messages. A client MAY choose to differentiate between DHCPOFFER messages with no authentication information and DHCPOFFER messages that do not pass the validation test; for example, a client might accept the former and discard the latter. If a client does accept an unauthenticated message, the client SHOULD inform any local users and SHOULD log the event.
客户端必须可配置为拒绝未经验证的消息，并且默认情况下应配置为拒绝未经验证的消息。客户端可以选择区分没有身份验证信息的DHCPOFFER消息和未通过验证测试的DHCPOFFER消息；例如，客户机可能接受前者而放弃后者。如果客户端确实接受未经验证的消息，则客户端应通知任何本地用户并记录事件。
3. The client replies with a DHCPREQUEST message that MUST include authentication information encoded with the same secret used by the server in the selected DHCPOFFER message.
3. 客户端使用DHCPREQUEST消息进行答复，该消息必须包含使用服务器在所选DHCPOFFER消息中使用的相同机密编码的身份验证信息。
4. If the client authenticated the DHCPOFFER it accepted, the client MUST validate the DHCPACK message from the server. The client MUST discard the DHCPACK if the message fails to pass validation and MAY log the validation failure. If the DHCPACK fails to pass validation, the client MUST revert to INIT state and returns to step 1. The client MAY choose to remember which server replied with a DHCPACK message that failed to pass validation and discard subsequent messages from that server.
4. 如果客户机对DHCPOFFER进行了身份验证，并且它已接受，则客户机必须验证来自服务器的DHCPACK消息。如果消息未能通过验证，客户端必须放弃DHCPACK，并可能记录验证失败。如果DHCPACK未能通过验证，则客户端必须恢复到INIT状态并返回到步骤1。客户机可以选择记住哪个服务器回复了未通过验证的DHCPACK消息，并放弃来自该服务器的后续消息。
If the client accepted a DHCPOFFER message that did not include authentication information or did not pass the validation test, the client MAY accept an unauthenticated DHCPACK message from the server.
如果客户端接受了不包含身份验证信息或未通过验证测试的DHCPOFFER消息，则客户端可能会接受来自服务器的未经验证的DHCPACK消息。
When in INIT-REBOOT state, the client MUST use the secret it used in its DHCPREQUEST message to obtain its current configuration to generate authentication information for the DHCPREQUEST message. The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages if no authenticated messages were received. The client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK messages as specified in section 3.2 of [1].
当处于INIT-REBOOT状态时，客户端必须使用它在其DHCPREQUEST消息中使用的密码来获取其当前配置，以生成DHCPREQUEST消息的身份验证信息。如果没有收到经过身份验证的消息，客户端可以选择接受未经身份验证的DHCPACK/DHCPNAK消息。客户必须按照[1]第3.2节的规定处理任何DHCPACK/DHCPNAK消息的接收（或不接收）。
When in RENEWING state, the client uses the secret it used in its initial DHCPREQUEST message to obtain its current configuration to generate authentication information for the DHCPREQUEST message. If client receives no DHCPACK messages or none of the DHCPACK messages pass validation, the client behaves as if it had not received a DHCPACK message in section 4.4.5 of the DHCP specification [1].
处于续订状态时，客户端使用其在初始DHCPREQUEST消息中使用的机密来获取其当前配置，以生成DHCPREQUEST消息的身份验证信息。如果客户端未接收到DHCPACK消息或没有一条DHCPACK消息通过验证，则客户端的行为与DHCP规范[1]第4.4.5节中未接收到DHCPACK消息的行为相同。
When in REBINDING state, the client uses the secret it used in its initial DHCPREQUEST message to obtain its current configuration to generate authentication information for the DHCPREQUEST message. If client receives no DHCPACK messages or none of the DHCPACK messages pass validation, the client behaves as if it had not received a DHCPACK message in section 4.4.5 of the DHCP specification [1].
当处于重新绑定状态时，客户端使用其在初始DHCPREQUEST消息中使用的机密来获取其当前配置，以生成DHCPREQUEST消息的身份验证信息。如果客户端未接收到DHCPACK消息或没有一条DHCPACK消息通过验证，则客户端的行为与DHCP规范[1]第4.4.5节中未接收到DHCPACK消息的行为相同。
Since the client already has some configuration information, the client may also have established a shared secret value, K, with a server. Therefore, the client SHOULD use the authentication request as in a DHCPDISCOVER message when a shared secret value exists. The client MUST treat any received DHCPACK messages as it does DHCPOFFER messages, see section 5.5.1.
由于客户端已经具有一些配置信息，因此客户端还可能已经与服务器建立了共享秘密值K。因此，当存在共享秘密值时，客户端应使用DHCPDISCOVER消息中的身份验证请求。客户机必须像对待DHCPOFFER消息一样对待任何收到的DHCPACK消息，见第5.5.1节。
Since the client is already in the BOUND state, the client will have a security association already established with the server. Therefore, the client MUST include authentication information with the DHCPRELEASE message.
由于客户端已处于绑定状态，因此客户端将与服务器建立安全关联。因此，客户端必须在DHCPRELEASE消息中包含身份验证信息。
This section describes the behavior of a server in response to client messages using delayed authentication.
本节描述服务器使用延迟身份验证响应客户端消息的行为。
Each server maintains a list of secrets and identifiers for those secrets that it shares with clients and potential clients. This information must be maintained in such a way that the server can:
每台服务器都维护一个机密列表和它与客户机和潜在客户机共享的机密的标识符。此信息的维护方式必须使服务器能够：
* Identify an appropriate secret and the identifier for that secret for use with a client that the server may not have previously communicated with
* 识别适当的秘密和该秘密的标识符，以便与服务器以前可能未与之通信的客户端一起使用
* Retrieve the secret and identifier used by a client to which the server has provided previous configuration information
* 检索服务器已向其提供以前配置信息的客户端使用的密码和标识符
Each server MUST save the counter from the previous authenticated message. A server MUST discard any incoming message which fails the replay detection check as defined by the RDM avoid replay attacks.
每个服务器都必须保存来自上一个已验证消息的计数器。服务器必须丢弃任何未通过RDM定义的重播检测检查的传入消息，以避免重播攻击。
DISCUSSION:
讨论：
The authenticated DHCPREQUEST message from a client in INIT-REBOOT state can only be validated by servers that used the same secret in their DHCPOFFER messages. Other servers will discard the DHCPREQUEST messages. Thus, only servers that used the secret selected by the client will be able to determine that their offered configuration information was not selected and the offered network address can be returned to the server's pool of available addresses. The servers that cannot validate the DHCPREQUEST message will eventually return their offered network addresses to their pool of available addresses as described in section 3.1 of the DHCP specification [1].
来自处于INIT-REBOOT状态的客户端的已验证DHCPREQUEST消息只能由在其DHCPOFFER消息中使用相同机密的服务器验证。其他服务器将丢弃DHCPREQUEST消息。因此，只有使用客户机选择的机密的服务器才能确定未选择其提供的配置信息，并且可以将提供的网络地址返回到服务器的可用地址池。无法验证DHCPREQUEST消息的服务器最终会将其提供的网络地址返回到DHCP规范[1]第3.1节所述的可用地址池中。
The server selects a secret for the client and includes authentication information in the DHCPOFFER message as specified in section 5, above. The server MUST record the identifier of the secret selected for the client and use that same secret for validating subsequent messages with the client.
服务器为客户端选择一个秘密，并按照上面第5节的规定在DHCPOFFER消息中包含身份验证信息。服务器必须记录为客户端选择的密码的标识符，并使用该密码验证客户端的后续消息。
The server uses the secret identified in the message and validates the message as specified in section 5.3. If the message fails to pass validation or the server does not know the secret identified by the 'secret ID' field, the server MUST discard the message and MAY choose to log the validation failure.
服务器使用消息中标识的秘密，并按照第5.3节的规定验证消息。如果消息未能通过验证，或者服务器不知道“机密ID”字段标识的机密，则服务器必须丢弃该消息，并可以选择记录验证失败。
If the message passes the validation procedure, the server responds as described in the DHCP specification. The server MUST include authentication information generated as specified in section 5.2.
如果消息通过了验证过程，服务器将按照DHCP规范中的描述进行响应。服务器必须包括按照第5.2节的规定生成的身份验证信息。
The server MAY choose to accept unauthenticated DHCPINFORM messages, or only accept authenticated DHCPINFORM messages based on a site policy.
服务器可以选择接受未经身份验证的DHCPINFORM消息，或者根据站点策略仅接受经过身份验证的DHCPINFORM消息。
When a client includes the authentication request in a DHCPINFORM message, the server MUST respond with an authenticated DHCPACK message. If the server does not have a shared secret value established with the sender of the DHCPINFORM message, then the server MAY respond with an unauthenticated DHCPACK message, or a DHCPNAK if the server does not accept unauthenticated clients based on the site policy, or the server MAY choose not to respond to the DHCPINFORM message.
当客户端在DHCPInfo消息中包含身份验证请求时，服务器必须使用经过身份验证的DHCPACK消息进行响应。如果服务器没有与DHCPINFORM消息的发送方建立共享机密值，则服务器可以使用未经验证的DHCPACK消息进行响应，或者如果服务器不接受基于站点策略的未经验证的客户端，则服务器可以使用DHCPNAK进行响应，或者服务器可以选择不响应DHCPINFORM消息。
Section 2 defines a new DHCP option called the Authentication Option, whose option code is 90.
第2节定义了一个称为身份验证选项的新DHCP选项，其选项代码为90。
This document specifies three new name spaces associated with the Authentication Option, which are to be created and maintained by IANA: Protocol, Algorithm and RDM.
本文档指定了与身份验证选项相关的三个新名称空间，这些名称空间将由IANA创建和维护：协议、算法和RDM。
Initial values assigned from the Protocol name space are 0 (for the configuration token Protocol in section 4) and 1 (for the delayed authentication Protocol in section 5). Additional values from the Protocol name space will be assigned through IETF Consensus, as defined in RFC 2434 [8].
从协议名称空间分配的初始值为0（对于第4节中的配置令牌协议）和1（对于第5节中的延迟认证协议）。协议名称空间中的附加值将通过IETF共识分配，如RFC 2434[8]中所定义。
The Algorithm name space is specific to individual Protocols. That is, each Protocol has its own Algorithm name space. The guidelines for assigning Algorithm name space values for a particular protocol should be specified along with the definition of a new Protocol.
算法名称空间特定于各个协议。也就是说，每个协议都有自己的算法名称空间。为特定协议分配算法名称空间值的指南应与新协议的定义一起指定。
For the configuration token Protocol, the Algorithm field MUST be 0. For the delayed authentication Protocol, the Algorithm value 1 is assigned to the HMAC-MD5 generating function as defined in section 5. Additional values from the Algorithm name space for Algorithm 1 will be assigned through IETF Consensus, as defined in RFC 2434.
对于配置令牌协议，算法字段必须为0。对于延迟认证协议，算法值1分配给第5节中定义的HMAC-MD5生成函数。算法1的算法名称空间中的附加值将通过IETF共识分配，如RFC 2434中所定义。
The initial value of 0 from the RDM name space is assigned to the use of a monotonically increasing value as defined in section 2. Additional values from the RDM name space will be assigned through IETF Consensus, as defined in RFC 2434.
RDM名称空间中的初始值0分配给使用第2节中定义的单调递增值。RDM名称空间中的其他值将通过IETF共识分配，如RFC 2434中所定义。
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[1] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[2] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
[3] Krawczyk H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[3] Krawczyk H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[4] Mills, D., "Network Time Protocol (Version 3)", RFC 1305, March 1992.
[4] Mills，D.，“网络时间协议（版本3）”，RFC13051992年3月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2219, March 1997.
[5] Bradner，S.“RFC中用于表示需求水平的关键词”，RFC 221997年3月。
[6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[6] Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[7] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[7] Patrick，M.，“DHCP中继代理信息选项”，RFC 3046，2001年1月。
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing and IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[8] Narten，T.和H.Alvestrand，“RFCs中的写作指南和IANA注意事项部分”，BCP 26，RFC 2434，1998年10月。
Jeff Schiller and Christian Huitema developed the original version of this authentication protocol in a terminal room BOF at the Dallas IETF meeting, December 1995. One of the editors (Droms) transcribed the notes from that discussion, which form the basis for this document. The editors appreciate Jeff's and Christian's patience in reviewing this document and its earlier drafts.
杰夫·席勒（Jeff Schiller）和克里斯蒂安·惠特马（Christian Huitema）于1995年12月在达拉斯IETF会议上在一个终端室BOF中开发了该认证协议的原始版本。其中一位编辑（DROM）转录了讨论中的注释，这些注释构成了本文件的基础。编辑们感谢Jeff和Christian在审阅本文件及其早期草稿时的耐心。
The "delayed authentication" mechanism used in section 5 is due to Bill Arbaugh. The threat model and requirements in sections 1.1 and 1.2 come from Bill's negotiation protocol proposal. The attendees of an interim meeting of the DHC WG held in June, 1998, including Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill Arbaugh, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan, Munil Shah, Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike Dooley, Greg Rabil and Arun Kapur, developed the threat model and reviewed several alternative proposals.
第5节中使用的“延迟认证”机制是由Bill Arbaugh提出的。第1.1节和第1.2节中的威胁模型和要求来自比尔的谈判协议提案。1998年6月举行的DHC工作组临时会议的与会者，包括彼得·福特、金·金尼尔、格伦·沃特斯、罗伯·史蒂文斯、比尔·阿博、拜朱·帕特尔、卡尔·史密斯、托马斯·纳滕、斯图尔特·关、穆尼尔·沙阿、奥拉弗尔·古德蒙德森、罗伯特·沃森、拉尔夫·德罗斯、迈克·杜利、格雷格·拉比尔和阿伦·卡普尔，开发了威胁模型并审查了若干备选方案。
The replay detection method field is due to Vipul Gupta.
回放检测方法字段由Vipul Gupta提供。
Other input from Bill Sommerfield is gratefully acknowledged.
感谢比尔·索默菲尔德的其他意见。
Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas Narten for reviewing earlier drafts of this document.
还感谢约翰·威尔金斯、阿金森、肖恩·马姆罗斯和托马斯·纳顿审阅了本文件的早期草稿。
This document describes authentication and verification mechanisms for DHCP.
本文档描述DHCP的身份验证和验证机制。
The configuration token authentication mechanism is vulnerable to interception and provides only the most rudimentary protection against inadvertently instantiated DHCP servers.
配置令牌身份验证机制容易被拦截，并且仅提供最基本的保护，以防无意中实例化DHCP服务器。
The delayed authentication mechanism described in this document is vulnerable to a denial of service attack through flooding with DHCPDISCOVER messages, which are not authenticated by this protocol. Such an attack may overwhelm the computer on which the DHCP server is running and may exhaust the addresses available for assignment by the DHCP server.
本文档中描述的延迟身份验证机制容易受到拒绝服务攻击，因为DHCPDISCOVER消息泛滥，未通过此协议进行身份验证。这种攻击可能会使运行DHCP服务器的计算机崩溃，并可能耗尽DHCP服务器可分配的地址。
Delayed authentication may also be vulnerable to a denial of service attack through flooding with authenticated messages, which may overwhelm the computer on which the DHCP server is running as the authentication keys for the incoming messages are computed.
延迟身份验证还可能容易受到拒绝服务攻击，因为已验证消息泛滥，在计算传入消息的身份验证密钥时，可能会淹没DHCP服务器运行的计算机。
Delayed authentication does not support interdomain authentication.
延迟身份验证不支持域间身份验证。
A real digital signature mechanism such as RSA, while currently computationally infeasible, would provide better security.
真正的数字签名机制，如RSA，虽然目前在计算上不可行，但可以提供更好的安全性。
Ralph Droms Cisco Systems 300 Apollo Drive Chelmsford, MA 01824
拉尔夫·德罗姆斯思科系统公司，马萨诸塞州切姆斯福德阿波罗大道300号，邮编01824
Phone: (978) 244-4733 EMail: rdroms@cisco.com
电话：（978）244-4733电子邮件：rdroms@cisco.com
Bill Arbaugh Department of Computer Science University of Maryland A.V. Williams Building College Park, MD 20742
马里兰大学计算机学院Bill Arbaugh Department·威廉姆斯·威廉姆斯楼学院公园，MD 20742
Phone: (301) 405-2774 EMail: waa@cs.umd.edu
电话：（301）405-2774电子邮件：waa@cs.umd.edu
Appendix A - Key Management Technique
附录A-密钥管理技术
To avoid centralized management of a list of random keys, suppose K for each client is generated from the pair (client identifier [6], subnet address, e.g., 192.168.1.0), which must be unique to that client. That is, K = MAC(MK, unique-id), where MK is a secret master key and MAC is a keyed one-way function such as HMAC-MD5.
为了避免对随机密钥列表进行集中管理，假设每个客户机的K是从该对（客户机标识符[6]，子网地址，例如192.168.1.0）生成的，该对必须是该客户机独有的。也就是说，K=MAC（MK，unique id），其中MK是一个秘密主密钥，MAC是一个键控单向函数，如HMAC-MD5。
Without knowledge of the master key MK, an unauthorized client cannot generate its own key K. The server can quickly validate an incoming message from a new client by regenerating K from the client-id. For known clients, the server can choose to recover the client's K dynamically from the client-id in the DHCP message, or can choose to precompute and cache all of the Ks a priori.
在不知道主密钥MK的情况下，未经授权的客户端无法生成自己的密钥K。服务器可以通过从客户端id重新生成K来快速验证来自新客户端的传入消息。对于已知客户端，服务器可以选择从DHCP消息中的客户端id动态恢复客户端的K，或者可以选择预先计算和缓存所有Ks。
By deriving all keys from a single master key, the DHCP server does not need access to clear text passwords, and can compute and verify the keyed MACs without requiring help from a centralized authentication server.
通过从单个主密钥派生所有密钥，DHCP服务器不需要访问明文密码，并且可以计算和验证密钥MAC，而无需集中式身份验证服务器的帮助。
To avoid compromise of this key management system, the master key, MK, MUST NOT be stored by any clients. The client SHOULD only be given its key, K. If MK is compromised, a new MK SHOULD be chosen and all clients given new individual keys.
为避免泄露此密钥管理系统，任何客户端都不得存储主密钥MK。应仅向客户端提供其密钥K。如果MK被泄露，则应选择一个新的MK，并向所有客户端提供新的单独密钥。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。