Network Working Group D. Eastlake 3rd
Request for Comments: 2931 Motorola
Updates: 2535 September 2000
Category: Standards Track
Network Working Group D. Eastlake 3rd
Request for Comments: 2931 Motorola
Updates: 2535 September 2000
Category: Standards Track
DNS Request and Transaction Signatures ( SIG(0)s )
DNS请求和事务签名（SIG（0）s）
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
Extensions to the Domain Name System (DNS) are described in [RFC 2535] that can provide data origin and transaction integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures.
[RFC 2535]中描述了域名系统（DNS）的扩展，该扩展可以通过使用加密数字签名向具有安全意识的解析程序和应用程序提供数据源和事务完整性以及身份验证。
Implementation experience has indicated the need for minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ). These changes are documented herein.
实施经验表明，需要对请求和事务签名资源记录（SIG（0）进行微小但不可互操作的更改。这些变更记录在本文中。
Acknowledgments
致谢
The contributions and suggestions of the following persons (in alphabetic order) to this memo are gratefully acknowledged:
感谢以下人士（按字母顺序）对本备忘录的贡献和建议：
Olafur Gudmundsson
奥拉弗尔·古德蒙松
Ed Lewis
艾德·路易斯
Erik Nordmark
埃里克·诺德马克
Brian Wellington
布莱恩·惠灵顿
Table of Contents
目录
1. Introduction................................................. 2
2. SIG(0) Design Rationale...................................... 3
2.1 Transaction Authentication.................................. 3
2.2 Request Authentication...................................... 3
2.3 Keying...................................................... 3
2.4 Differences Between TSIG and SIG(0)......................... 4
3. The SIG(0) Resource Record................................... 4
3.1 Calculating Request and Transaction SIGs.................... 5
3.2 Processing Responses and SIG(0) RRs......................... 6
3.3 SIG(0) Lifetime and Expiration.............................. 7
4. Security Considerations...................................... 7
5. IANA Considerations.......................................... 7
References...................................................... 7
Author's Address................................................ 8
Appendix: SIG(0) Changes from RFC 2535.......................... 9
Full Copyright Statement........................................ 10
1. Introduction................................................. 2
2. SIG(0) Design Rationale...................................... 3
2.1 Transaction Authentication.................................. 3
2.2 Request Authentication...................................... 3
2.3 Keying...................................................... 3
2.4 Differences Between TSIG and SIG(0)......................... 4
3. The SIG(0) Resource Record................................... 4
3.1 Calculating Request and Transaction SIGs.................... 5
3.2 Processing Responses and SIG(0) RRs......................... 6
3.3 SIG(0) Lifetime and Expiration.............................. 7
4. Security Considerations...................................... 7
5. IANA Considerations.......................................... 7
References...................................................... 7
Author's Address................................................ 8
Appendix: SIG(0) Changes from RFC 2535.......................... 9
Full Copyright Statement........................................ 10
This document makes minor but non-interoperable changes to part of [RFC 2535], familiarity with which is assumed, and includes additional explanatory text. These changes concern SIG Resource Records (RRs) that are used to digitally sign DNS requests and transactions / responses. Such a resource record, because it has a type covered field of zero, is frequently called a SIG(0). The changes are based on implementation and attempted implementation experience with TSIG [RFC 2845] and the [RFC 2535] specification for SIG(0).
本文件对[RFC 2535]的一部分作了微小但不可互操作的更改，假定熟悉该部分，并包括其他解释性文本。这些更改涉及用于对DNS请求和事务/响应进行数字签名的SIG资源记录（RRs）。这样的资源记录，因为它的类型覆盖字段为零，所以通常称为SIG（0）。这些变更基于TSIG[RFC 2845]和SIG（0）的[RFC 2535]规范的实施和尝试实施经验。
Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2 and 4.3. No changes are made herein related to the KEY or NXT RRs or to the processing involved with data origin and denial authentication for DNS data.
更新的[RFC 2535]章节全部为4.1.8.1以及4.2和4.3的部分。此处未对密钥或NXT RRs或涉及数据来源和DNS数据拒绝认证的处理进行任何更改。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC 2119]中所述进行解释。
SIG(0) provides protection for DNS transactions and requests that is not provided by the regular SIG, KEY, and NXT RRs specified in [RFC 2535]. The authenticated data origin services of secure DNS either provide protected data resource records (RRs) or authenticatably deny their nonexistence. These services provide no protection for glue records, DNS requests, no protection for message headers on requests or responses, and no protection of the overall integrity of a response.
SIG（0）为[RFC 2535]中指定的常规SIG、密钥和NXT RRs未提供的DNS事务和请求提供保护。安全DNS的经过身份验证的数据源服务要么提供受保护的数据资源记录（RRs），要么通过身份验证拒绝其不存在。这些服务不保护粘合记录、DNS请求、请求或响应上的消息头，也不保护响应的整体完整性。
Transaction authentication means that a requester can be sure it is at least getting the messages from the server it queried and that the received messages are in response to the query it sent. This is accomplished by optionally adding either a TSIG RR [RFC 2845] or, as described herein, a SIG(0) resource record at the end of the response which digitally signs the concatenation of the server's response and the corresponding resolver query.
事务身份验证意味着请求者可以确保至少从其查询的服务器获取消息，并且收到的消息是对其发送的查询的响应。这是通过可选地在响应末尾添加TSIG RR[RFC 2845]或如本文所述的SIG（0）资源记录来实现的，该SIG（0）资源记录对服务器的响应和相应的解析器查询的串联进行数字签名。
Requests can also be authenticated by including a TSIG or, as described herein, a special SIG(0) RR at the end of the request. Authenticating requests serves no function in DNS servers that predate the specification of dynamic update. Requests with a non-empty additional information section produce error returns or may even be ignored by a few such older DNS servers. However, this syntax for signing requests is defined for authenticating dynamic update requests [RFC 2136], TKEY requests [RFC 2930], or future requests requiring authentication.
还可以通过在请求的末尾包括TSIG或如本文所述的特殊SIG（0）RR来认证请求。验证请求在动态更新规范之前的DNS服务器中不起任何作用。带有非空附加信息部分的请求会产生错误返回，甚至可能会被一些较旧的DNS服务器忽略。但是，此签名请求语法是为验证动态更新请求[RFC 2136]、TKEY请求[RFC 2930]或需要验证的未来请求而定义的。
The private keys used in transaction security belong to the host composing the DNS response message, not to the zone involved. Request authentication may also involve the private key of the host or other entity composing the request or of a zone to be affected by the request or other private keys depending on the request authority it is sought to establish. The corresponding public key(s) are normally stored in and retrieved from the DNS for verification as KEY RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY).
事务安全性中使用的私钥属于构成DNS响应消息的主机，而不属于涉及的区域。请求认证还可能涉及构成请求的主机或其他实体的私钥，或受请求影响的区域的私钥或其他私钥，具体取决于请求所寻求建立的请求权限。相应的公钥通常存储在DNS中并从DNS中检索，作为密钥RRs进行验证，协议字节为3（DNSSEC）或255（任意）。
Because requests and replies are highly variable, message authentication SIGs can not be pre-calculated. Thus it will be necessary to keep the private key on-line, for example in software or in a directly connected piece of hardware.
由于请求和回复高度可变，因此无法预先计算消息身份验证sig。因此，有必要保持私钥在线，例如在软件或直接连接的硬件中。
There are significant differences between TSIG and SIG(0).
TSIG和SIG之间存在显著差异（0）。
Because TSIG involves secret keys installed at both the requester and server the presence of such a key implies that the other party understands TSIG and very likely has the same key installed. Furthermore, TSIG uses keyed hash authentication codes which are relatively inexpensive to compute. Thus it is common to authenticate requests with TSIG and responses are authenticated with TSIG if the corresponding request is authenticated.
由于TSIG涉及安装在请求者和服务器上的密钥，因此此类密钥的存在意味着另一方理解TSIG，并且很可能安装了相同的密钥。此外，TSIG使用键控哈希认证码，计算成本相对较低。因此，通常使用TSIG对请求进行身份验证，如果相应的请求经过身份验证，则使用TSIG对响应进行身份验证。
SIG(0) on the other hand, uses public key authentication, where the public keys are stored in DNS as KEY RRs and a private key is stored at the signer. Existence of such a KEY RR does not necessarily imply implementation of SIG(0). In addition, SIG(0) involves relatively expensive public key cryptographic operations that should be minimized and the verification of a SIG(0) involves obtaining and verifying the corresponding KEY which can be an expensive and lengthy operation. Indeed, a policy of using SIG(0) on all requests and verifying it before responding would, for some configurations, lead to a deadly embrace with the attempt to obtain and verify the KEY needed to authenticate the request SIG(0) resulting in additional requests accompanied by a SIG(0) leading to further requests accompanied by a SIG(0), etc. Furthermore, omitting SIG(0)s when not required on requests halves the number of public key operations required by the transaction.
另一方面，SIG（0）使用公钥认证，其中公钥作为密钥RRs存储在DNS中，私钥存储在签名者处。这种密钥RR的存在并不一定意味着SIG（0）的实现。此外，SIG（0）涉及应最小化的相对昂贵的公钥密码操作，并且SIG（0）的验证涉及获取和验证相应的密钥，这可能是一个昂贵且冗长的操作。事实上，对于某些配置，对所有请求使用SIG（0）并在响应前进行验证的策略将导致致命的拥抱，即试图获取和验证验证请求SIG（0）所需的密钥，从而导致附加请求伴随SIG（0），导致附加请求伴随SIG（0），从而导致附加请求伴随SIG（0），此外，当请求不需要SIG（0）时，省略SIG（0）将使事务所需的公钥操作数量减半。
For these reasons, SIG(0)s SHOULD only be used on requests when necessary to authenticate that the requester has some required privilege or identity. SIG(0)s on replies are defined in such a way as to not require a SIG(0) on the corresponding request and still provide transaction protection. For other replies, whether they are authenticated by the server or required to be authenticated by the requester SHOULD be a local configuration option.
出于这些原因，只有在需要验证请求者是否具有某些必需的特权或身份时，才应在请求上使用SIG（0）。回复上的SIG（0）被定义为不需要相应请求上的SIG（0），并且仍然提供事务保护。对于其他回复，无论它们是由服务器进行身份验证还是需要由请求者进行身份验证，都应该是本地配置选项。
The structure of and type number of SIG resource records (RRs) is given in [RFC 2535] Section 4.1. However all of Section 4.1.8.1 and the parts of Sections 4.2 and 4.3 related to SIG(0) should be considered replaced by the material below. Any conflict between [RFC 2535] and this document concerning SIG(0) RRs should be resolved in favor of this document.
[RFC 2535]第4.1节给出了SIG资源记录（RRs）的结构和类型编号。但是，第4.1.8.1节的所有内容以及第4.2节和第4.3节中与SIG（0）相关的部分应被视为替换为以下材料。[RFC 2535]与本文件之间关于SIG（0）RRs的任何冲突应以本文件为准予以解决。
For all transaction SIG(0)s, the signer field MUST be a name of the originating host and there MUST be a KEY RR at that name with the public key corresponding to the private key used to calculate the
对于所有事务SIG（0），签名者字段必须是发起主机的名称，并且该名称处必须有一个密钥RR，其公钥对应于用于计算签名的私钥
signature. (The host domain name used may be the inverse IP address mapping name for an IP address of the host if the relevant KEY is stored there.)
签名（如果存储了相关密钥，则使用的主机域名可能是主机IP地址的反向IP地址映射名称。）
For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are meaningless. The TTL fields SHOULD be zero and the CLASS field SHOULD be ANY. To conserve space, the owner name SHOULD be root (a single zero octet). When SIG(0) authentication on a response is desired, that SIG RR MUST be considered the highest priority of any additional information for inclusion in the response. If the SIG(0) RR cannot be added without causing the message to be truncated, the server MUST alter the response so that a SIG(0) can be included. This response consists of only the question and a SIG(0) record, and has the TC bit set and RCODE 0 (NOERROR). The client should at this point retry the request using TCP.
对于所有SIG（0）RRs，所有者名称、类、TTL和原始TTL都是无意义的。TTL字段应为零，CLASS字段应为ANY。为节省空间，所有者名称应为root（单个零八位字节）。当需要对响应进行SIG（0）身份验证时，必须将该SIG RR视为包含在响应中的任何附加信息的最高优先级。如果在不导致消息被截断的情况下无法添加SIG（0）RR，则服务器必须更改响应，以便可以包含SIG（0）。此响应仅包含问题和SIG（0）记录，并且设置了TC位和RCODE 0（无错误）。此时，客户端应使用TCP重试请求。
A DNS request may be optionally signed by including one SIG(0)s at the end of the query additional information section. Such a SIG is identified by having a "type covered" field of zero. It signs the preceding DNS request message including DNS header but not including the UDP/IP header and before the request RR counts have been adjusted for the inclusions of the request SIG(0).
DNS请求可以通过在查询附加信息部分的末尾包含一个SIG（0）来选择性地签名。此类SIG通过“类型覆盖”字段为零来识别。它对前面的DNS请求消息进行签名，该消息包括DNS头，但不包括UDP/IP头，并且在针对请求SIG（0）的包含调整请求RR计数之前。
It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of (1) the SIG's RDATA section entirely omitting (not just zeroing) the signature subfield itself, (2) the DNS query messages, including DNS header, but not the UDP/IP header and before the reply RR counts have been adjusted for the inclusion of the SIG(0). That is
它是通过使用（1）SIG的RDATA部分中的“数据”（见[RFC 2535]，第4.1.8节）来计算的，（2）DNS查询消息，包括DNS报头，但不包括UDP/IP报头，并且在应答RR计数调整为包含SIG（0）之前。就是
data = RDATA | request - SIG(0)
data = RDATA | request - SIG(0)
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being calculated less the signature itself.
其中“|”是串联，RDATA是正在计算的SIG（0）的RDATA减去签名本身。
Similarly, a SIG(0) can be used to secure a response and the request that produced it. Such transaction signatures are calculated by using a "data" of (1) the SIG's RDATA section omitting the signature itself, (2) the entire DNS query message that produced this response, including the query's DNS header but not its UDP/IP header, and (3) the entire DNS response message, including DNS header but not the UDP/IP header and before the response RR counts have been adjusted for the inclusion of the SIG(0).
类似地，可以使用SIG（0）来保护响应和生成响应的请求。此类事务签名是通过使用以下“数据”计算的：（1）忽略签名本身的SIG的RDATA部分，（2）生成此响应的整个DNS查询消息，包括查询的DNS头，但不包括其UDP/IP头，以及（3）整个DNS响应消息，包括DNS报头，但不包括UDP/IP报头，并且在响应RR计数调整为包含SIG（0）之前。
That is
就是
data = RDATA | full query | response - SIG(0)
data = RDATA | full query | response - SIG(0)
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being calculated less the signature itself.
其中“|”是串联，RDATA是正在计算的SIG（0）的RDATA减去签名本身。
Verification of a response SIG(0) (which is signed by the server host key, not the zone key) by the requesting resolver shows that the query and response were not tampered with in transit, that the response corresponds to the intended query, and that the response comes from the queried server.
请求解析程序对响应SIG（0）（由服务器主机密钥而非区域密钥签名）的验证表明，查询和响应在传输过程中未被篡改，响应与预期查询相对应，并且响应来自被查询的服务器。
In the case of a DNS message via TCP, a SIG(0) on the first data packet is calculated with "data" as above and for each subsequent packet, it is calculated as follows:
在经由TCP的DNS消息的情况下，第一个数据分组上的SIG（0）使用如上所述的“数据”计算，并且对于每个后续分组，其计算如下：
data = RDATA | DNS payload - SIG(0) | previous packet
data = RDATA | DNS payload - SIG(0) | previous packet
where "|" is concatenations, RDATA is as above, and previous packet is the previous DNS payload including DNS header and the SIG(0) but not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an alternative, TSIG may be used after, if necessary, setting up a key with TKEY [RFC 2930].
其中“|”是连接，RDATA如上所述，前一个数据包是前一个DNS有效负载，包括DNS头和SIG（0），但不包括TCP/IP头。对TCP的SIG（0）支持是可选的。作为替代方案，如有必要，可在使用TKEY[RFC 2930]设置钥匙后使用TSIG。
Except where needed to authenticate an update, TKEY, or similar privileged request, servers are not required to check a request SIG(0).
除非需要验证更新、TKEY或类似特权请求，否则服务器不需要检查请求SIG（0）。
Note: requests and responses can either have a single TSIG or one SIG(0) but not both a TSIG and a SIG(0).
注意：请求和响应可以具有单个TSIG或一个SIG（0），但不能同时具有TSIG和SIG（0）。
If a SIG RR is at the end of the additional information section of a response and has a type covered of zero, it is a transaction signature covering the response and the query that produced the response. For TKEY responses, it MUST be checked and the message rejected if the checks fail unless otherwise specified for the TKEY mode in use. For all other responses, it MAY be checked and the message rejected if the checks fail.
如果SIG RR位于响应的附加信息部分的末尾，并且包含的类型为零，则它是覆盖响应和生成响应的查询的事务签名。对于TKEY响应，除非对使用中的TKEY模式另有规定，否则如果检查失败，则必须对其进行检查并拒绝消息。对于所有其他响应，如果检查失败，则可能会对其进行检查并拒绝消息。
If a response's SIG(0) check succeed, such a transaction authentication SIG does NOT directly authenticate the validity any data-RRs in the message. However, it authenticates that they were sent by the queried server and have not been diddled. (Only a proper SIG(0) RR signed by the zone or a key tracing its authority to the zone or to static resolver configuration can directly authenticate
如果响应的SIG（0）检查成功，则此类事务验证SIG不会直接验证消息中任何数据RRs的有效性。但是，它可以验证它们是由查询的服务器发送的，并且没有被欺骗。（只有由区域签名的正确SIG（0）RR或跟踪其权限到区域或静态解析器配置的密钥才能直接进行身份验证。）
data-RRs, depending on resolver policy.) If a resolver or server does not implement transaction and/or request SIGs, it MUST ignore them without error where they are optional and treat them as failing where they are required.
数据RRs，取决于冲突解决程序策略。）如果冲突解决程序或服务器未实现事务和/或请求SIG，则它必须在可选的情况下无误地忽略它们，并在需要时将其视为失败。
The inception and expiration times in SIG(0)s are for the purpose of resisting replay attacks. They should be set to form a time bracket such that messages outside that bracket can be ignored. In IP networks, this time bracket should not normally extend further than 5 minutes into the past and 5 minutes into the future.
SIG（0）中的起始时间和到期时间是为了抵抗重放攻击。它们应设置为形成一个时间范围，以便可以忽略该范围之外的消息。在IP网络中，此时间段通常不应在过去和未来分别延长5分钟和5分钟。
No additional considerations beyond those in [RFC 2535].
除[RFC 2535]中的内容外，无其他考虑因素。
The inclusion of the SIG(0) inception and expiration time under the signature improves resistance to replay attacks.
在签名下包含SIG（0）起始和到期时间可以提高对重播攻击的抵抗力。
No new parameters are created or parameter values assigned by this document.
此文档未创建新参数或指定参数值。
References
工具书类
[RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, September 1996.
[RFC 1982]Elz，R.和R.Bush，“序列号算术”，RFC 1982，1996年9月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC 2136]Vixie，P.，Thomson，S.，Rekhter，Y.和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 2136，1997年4月。
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC 2535]Eastlake，D.，“域名系统安全扩展”，RFC 25351999年3月。
[RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Signatures for DNS (TSIG)", RFC 2845, May 2000.
[RFC 2845]Vixie，P.，Gudmundsson，O.，Eastlake，D.和B.Wellington，“DNS的密钥交易签名（TSIG）”，RFC 28452000年5月。
[RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC 2930, September 2000.
[RFC 2930]Eastlake，D.，“DNS的密钥建立（RR）”，RFC 2930，2000年9月。
Author's Address
作者地址
Donald E. Eastlake 3rd Motorola 140 Forest Avenue Hudson, MA 01749 USA
美国马萨诸塞州哈德逊森林大道140号唐纳德E东湖第三摩托罗拉01749
Phone: +1-978-562-2827(h)
+1-508-261-5434(w)
Fax: +1 978-567-7941(h)
+1-508-261-4447(w)
EMail: Donald.Eastlake@motorola.com
Phone: +1-978-562-2827(h)
+1-508-261-5434(w)
Fax: +1 978-567-7941(h)
+1-508-261-4447(w)
EMail: Donald.Eastlake@motorola.com
Appendix: SIG(0) Changes from RFC 2535
附录：RFC 2535的SIG（0）变更
Add explanatory text concerning the differences between TSIG and SIG(0).
添加关于TSIG和SIG（0）之间差异的解释性文本。
Change the data over which SIG(0) is calculated to include the SIG(0) RDATA other than the signature itself so as to secure the signature inception and expiration times and resist replay attacks. Specify SIG(0) for TCP.
更改计算SIG（0）的数据，使其包含签名本身以外的SIG（0）RDATA，以确保签名开始和过期时间的安全，并抵抗重播攻击。为TCP指定SIG（0）。
Add discussion of appropriate inception and expiration times for SIG(0).
添加关于SIG（0）的适当起始时间和到期时间的讨论。
Add wording to indicate that either a TSIG or one or more SIG(0)s may be present but not both.
添加措辞，表明TSIG或一个或多个SIG（0）可能存在，但不能同时存在。
Reword some areas for clarity.
为清晰起见，改写一些区域。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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编辑功能的资金目前由互联网协会提供。