Network Working Group R. Bush
Request for Comments: 2870 Verio
Obsoletes: 2010 D. Karrenberg
BCP: 40 RIPE NCC
Category: Best Current Practice M. Kosters
Network Solutions
R. Plzak
SAIC
June 2000
Network Working Group R. Bush
Request for Comments: 2870 Verio
Obsoletes: 2010 D. Karrenberg
BCP: 40 RIPE NCC
Category: Best Current Practice M. Kosters
Network Solutions
R. Plzak
SAIC
June 2000
Root Name Server Operational Requirements
根名称服务器操作要求
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
As the internet becomes increasingly critical to the world's social and economic infrastructure, attention has rightly focused on the correct, safe, reliable, and secure operation of the internet infrastructure itself. The root domain name servers are seen as a crucial part of that technical infrastructure. The primary focus of this document is to provide guidelines for operation of the root name servers. Other major zone server operators (gTLDs, ccTLDs, major zones) may also find it useful. These guidelines are intended to meet the perceived societal needs without overly prescribing technical details.
随着互联网对世界社会和经济基础设施变得越来越重要，人们的注意力理所当然地集中在互联网基础设施本身的正确、安全、可靠和安全运行上。根域名服务器被视为该技术基础架构的关键部分。本文档的主要重点是提供根名称服务器的操作指南。其他主要区域服务器运营商（GTLD、CCTLD、主要区域）也可能会发现它很有用。这些指南旨在满足感知的社会需求，而不过度规定技术细节。
The resolution of domain names on the internet is critically dependent on the proper, safe, and secure operation of the root domain name servers. Currently, these dozen or so servers are provided and operated by a very competent and trusted group of volunteers. This document does not propose to change that, but merely to provide formal guidelines so that the community understands how and why this is done.
internet上域名的解析在很大程度上取决于根域名服务器的正确、安全和安全操作。目前，这十几台服务器由一群非常有能力、值得信赖的志愿者提供和操作。本文件并不打算改变这一点，只是提供正式的指导方针，以便社区了解如何以及为什么这样做。
1.1 The Internet Corporation for Assigned Names and Numbers (ICANN) has become responsible for the operation of the root servers. The ICANN has appointed a Root Server System Advisory Committee (RSSAC) to give technical and operational advice to the ICANN board. The ICANN and the RSSAC look to the IETF to provide engineering standards.
1.1 互联网名称和号码分配公司（ICANN）负责根服务器的运行。ICANN已任命一个根服务器系统咨询委员会（RSSAC），向ICANN董事会提供技术和运营建议。ICANN和RSSAC希望IETF提供工程标准。
1.2 The root servers serve the root, aka ".", zone. Although today some of the root servers also serve some TLDs (top level domains) such as gTLDs (COM, NET, ORG, etc.), infrastructural TLDs such as INT and IN-ADDR.ARPA, and some ccTLDs (country code TLDs, e.g. SE for Sweden), this is likely to change (see 2.5).
1.2 根服务器服务于根区域，即“.”。尽管今天一些根服务器还服务于一些TLD（顶级域），如GTLD（COM、NET、ORG等）、基础设施TLD（如INT和IN-ADDR.ARPA）和一些CCTLD（国家代码TLD，如瑞典SE），但这可能会发生变化（见2.5）。
1.3 The root servers are neither involved with nor dependent upon the 'whois' data.
1.3 根服务器既不涉及也不依赖“whois”数据。
1.4 The domain name system has proven to be sufficiently robust that we are confident that the, presumably temporary, loss of most of the root servers should not significantly affect operation of the internet.
1.4 域名系统已经被证明是足够强大的，因此我们相信，大多数根服务器的丢失（可能是暂时的）不会对互联网的运行产生重大影响。
1.5 Experience has shown that the internet is quite vulnerable to incorrect data in the root zone or TLDs. Hence authentication, validation, and security of these data are of great concern.
1.5 经验表明，互联网很容易受到根区域或TLD中不正确数据的攻击。因此，这些数据的身份验证、验证和安全性备受关注。
The following are requirements for the technical details of the root servers themselves:
以下是根服务器本身的技术细节要求：
2.1 It would be short-sighted of this document to specify particular hardware, operating systems, or name serving software. Variations in these areas would actually add overall robustness.
2.1 在本文档中指定特定的硬件、操作系统或名称服务软件是短视的。这些方面的变化实际上会增加整体稳健性。
2.2 Each server MUST run software which correctly implements the IETF standards for the DNS, currently [RFC1035] [RFC2181]. While there are no formal test suites for standards compliance, the maintainers of software used on root servers are expected to take all reasonable actions to conform to the IETF's then current documented expectations.
2.2 每台服务器必须运行正确执行IETF DNS标准的软件，当前为[RFC1035][RFC2181]。虽然没有标准符合性的正式测试套件，但根服务器上使用的软件的维护人员应采取所有合理措施，以符合IETF当时记录的预期。
2.3 At any time, each server MUST be able to handle a load of requests for root data which is three times the measured peak of such requests on the most loaded server in then current normal conditions. This is usually expressed in requests per second. This is intended to ensure continued operation of root services should two thirds of the servers be taken out of operation, whether by intent, accident, or malice.
2.3 在任何时候，每个服务器都必须能够处理根数据的请求负载，该负载是当前正常情况下负载最大的服务器上此类请求峰值的三倍。这通常以每秒请求数表示。这是为了确保根服务在三分之二的服务器因故意、意外或恶意而停止运行时继续运行。
2.4 Each root server should have sufficient connectivity to the internet to support the bandwidth needs of the above requirement. Connectivity to the internet SHOULD be as diverse as possible.
2.4 每个根服务器应具有足够的internet连接能力，以支持上述要求的带宽需求。与互联网的连接应尽可能多样化。
Root servers SHOULD have mechanisms in place to accept IP connectivity to the root server from any internet provider delivering connectivity at their own cost.
根服务器应具有适当的机制，以接受来自任何互联网提供商的根服务器的IP连接，并自费提供连接。
2.5 Servers MUST provide authoritative responses only from the zones they serve. The servers MUST disable recursive lookup, forwarding, or any other function that may allow them to provide cached answers. They also MUST NOT provide secondary service for any zones other than the root and root-servers.net zones. These restrictions help prevent undue load on the root servers and reduce the chance of their caching incorrect data.
2.5 服务器必须仅从其服务的区域提供权威响应。服务器必须禁用递归查找、转发或任何其他允许其提供缓存答案的功能。它们还不得为根服务器和根服务器.net区域以外的任何区域提供辅助服务。这些限制有助于防止根服务器上的过度负载，并减少其缓存错误数据的机会。
2.6 Root servers MUST answer queries from any internet host, i.e. may not block root name resolution from any valid IP address, except in the case of queries causing operational problems, in which case the blocking SHOULD last only as long as the problem, and be as specific as reasonably possible.
2.6 根服务器必须回答来自任何internet主机的查询，即不能阻止任何有效IP地址的根名称解析，但导致操作问题的查询除外，在这种情况下，阻止应持续问题的时间，并尽可能具体。
2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer, queries from clients other than other root servers. This restriction is intended to, among other things, prevent unnecessary load on the root servers as advice has been heard such as "To avoid having a corruptible cache, make your server a stealth secondary for the root zone." The root servers MAY put the root zone up for ftp or other access on one or more less critical servers.
2.7 根服务器不应回答来自其他根服务器以外的客户端的AXFR或其他区域传输查询。除其他外，此限制旨在防止根服务器上出现不必要的负载，因为已听到建议，如“为了避免缓存损坏，请将您的服务器设置为根区域的隐形辅助服务器”。根服务器可以将根区域设置为ftp或在一个或多个不太关键的服务器上进行其他访问。
2.8 Servers MUST generate checksums when sending UDP datagrams and MUST verify checksums when receiving UDP datagrams containing a non-zero checksum.
2.8 服务器在发送UDP数据报时必须生成校验和，在接收包含非零校验和的UDP数据报时必须验证校验和。
The servers need both physical and protocol security as well as unambiguous authentication of their responses.
服务器需要物理和协议安全以及对其响应的明确身份验证。
3.1 Physical security MUST be ensured in a manner expected of data centers critical to a major enterprise.
3.1 必须以对大型企业至关重要的数据中心预期的方式确保物理安全。
3.1.1 Whether or not the overall site in which a root server is located has access control, the specific area in which the root server is located MUST have positive access control, i.e. the number of individuals permitted access to the area MUST be limited, controlled, and recorded. At a
3.1.1 无论根服务器所在的整个站点是否具有访问控制，根服务器所在的特定区域必须具有积极的访问控制，即，必须限制、控制和记录允许访问该区域的个人数量。至少
minimum, control measures SHOULD be either mechanical or electronic locks. Physical security MAY be enhanced by the use of intrusion detection and motion sensors, multiple serial access points, security personnel, etc.
至少，控制措施应为机械锁或电子锁。通过使用入侵检测和运动传感器、多个串行接入点、安全人员等，可以增强物理安全性。
3.1.2 Unless there is documentable experience that the local power grid is more reliable than the MTBF of a UPS (i.e. five to ten years), power continuity for at least 48 hours MUST be assured, whether through on-site batteries, on-site power generation, or some combination thereof. This MUST supply the server itself, as well as the infrastructure necessary to connect the server to the internet. There MUST be procedures which ensure that power fallback mechanisms and supplies are tested no less frequently than the specifications and recommendations of the manufacturer.
3.1.2 除非有文件证明当地电网比UPS的MTBF更可靠（即五到十年），否则必须确保至少48小时的电源连续性，无论是通过现场电池、现场发电还是其他方式。这必须提供服务器本身，以及将服务器连接到internet所需的基础设施。必须制定相关程序，确保对电源回退机制和电源的测试频率不低于制造商的规范和建议。
3.1.3 Fire detection and/or retardation MUST be provided.
3.1.3 必须提供火灾探测和/或减速装置。
3.1.4 Provision MUST be made for rapid return to operation after a system outage. This SHOULD involve backup of systems software and configuration. But SHOULD also involve backup hardware which is pre-configured and ready to take over operation, which MAY require manual procedures.
3.1.4 必须为系统停机后快速恢复运行做好准备。这应包括系统软件和配置的备份。但还应包括预配置的备份硬件，并准备好接管操作，这可能需要手动程序。
3.2 Network security should be of the level provided for critical infrastructure of a major commercial enterprise.
3.2 网络安全应达到为大型商业企业的关键基础设施提供的级别。
3.2.1 The root servers themselves MUST NOT provide services other than root name service e.g. remote internet protocols such as http, telnet, rlogin, ftp, etc. The only login accounts permitted should be for the server administrator(s). "Root" or "privileged user" access MUST NOT be permitted except through an intermediate user account.
3.2.1 根服务器本身不得提供根名称服务以外的服务，例如远程internet协议，如http、telnet、rlogin、ftp等。只允许服务器管理员使用登录帐户。除非通过中间用户帐户，否则不得允许“Root”或“特权用户”访问。
Servers MUST have a secure mechanism for remote administrative access and maintenance. Failures happen; given the 24x7 support requirement (per 4.5), there will be times when something breaks badly enough that senior wizards will have to connect remotely. Remote logins MUST be protected by a secure means that is strongly authenticated and encrypted, and sites from which remote login is allowed MUST be protected and hardened.
服务器必须具有用于远程管理访问和维护的安全机制。失败会发生；考虑到24x7支持要求（根据4.5），有时会出现严重故障，高级向导必须远程连接。远程登录必须通过经过强身份验证和加密的安全方式进行保护，并且必须对允许远程登录的站点进行保护和加固。
3.2.2 Root name servers SHOULD NOT trust other hosts, except secondary servers trusting the primary server, for matters of authentication, encryption keys, or other access or
3.2.2 根名称服务器不应信任其他主机，除了信任主服务器的辅助服务器之外，其他主机的身份验证、加密密钥或其他访问或访问权限问题
security information. If a root operator uses kerberos authentication to manage access to the root server, then the associated kerberos key server MUST be protected with the same prudence as the root server itself. This applies to all related services which are trusted in any manner.
安全信息。如果根操作员使用kerberos身份验证来管理对根服务器的访问，则必须以与根服务器本身相同的谨慎性保护关联的kerberos密钥服务器。这适用于以任何方式受信任的所有相关服务。
3.2.3 The LAN segment(s) on which a root server is homed MUST NOT also home crackable hosts. I.e. the LAN segments should be switched or routed so there is no possibility of masquerading. Some LAN switches aren't suitable for security purposes, there have been published attacks on their filtering. While these can often be prevented by careful configuration, extreme prudence is recommended. It is best if the LAN segment simply does not have any other hosts on it.
3.2.3 根服务器所在的LAN段不能同时也是可破解主机的所在地。也就是说，LAN段应进行交换或路由，因此不存在伪装的可能性。一些LAN交换机不适合用于安全目的，已经发布了针对其过滤的攻击。虽然这些通常可以通过小心配置来防止，但建议极其谨慎。最好是LAN网段上没有任何其他主机。
3.2.4 The LAN segment(s) on which a root server is homed SHOULD be separately firewalled or packet filtered to discourage network access to any port other than those needed for name service.
3.2.4 根服务器所在的LAN段应单独进行防火墙或数据包过滤，以阻止网络访问除名称服务所需端口以外的任何端口。
3.2.5 The root servers SHOULD have their clocks synchronized via NTP [RFC1305] [RFC2030] or similar mechanisms, in as secure manner as possible. For this purpose, servers and their associated firewalls SHOULD allow the root servers to be NTP clients. Root servers MUST NOT act as NTP peers or servers.
3.2.5 根服务器应通过NTP[RFC1305][RFC2030]或类似机制以尽可能安全的方式同步时钟。为此，服务器及其关联防火墙应允许根服务器成为NTP客户端。根服务器不得充当NTP对等方或服务器。
3.2.6 All attempts at intrusion or other compromise SHOULD be logged, and all such logs from all root servers SHOULD be analyzed by a cooperative security team communicating with all server operators to look for patterns, serious attempts, etc. Servers SHOULD log in GMT to facilitate log comparison.
3.2.6 应记录所有入侵或其他危害的尝试，并且所有根服务器的所有此类日志应由与所有服务器操作员通信的合作安全团队进行分析，以查找模式、严重尝试等。服务器应登录GMT以便于日志比较。
3.2.7 Server logging SHOULD be to separate hosts which SHOULD be protected similarly to the root servers themselves.
3.2.7 服务器日志记录应该是独立的主机，这些主机应该受到与根服务器本身类似的保护。
3.2.8 The server SHOULD be protected from attacks based on source routing. The server MUST NOT rely on address- or name-based authentication.
3.2.8 应保护服务器免受基于源路由的攻击。服务器不能依赖基于地址或名称的身份验证。
3.2.9 The network on which the server is homed SHOULD have in-addr.arpa service.
3.2.9 服务器所在的网络应具有in-addr.arpa服务。
3.3 Protocol authentication and security are required to ensure that data presented by the root servers are those created by those authorized to maintain the root zone data.
3.3 需要协议身份验证和安全性来确保根服务器提供的数据是那些被授权维护根区域数据的服务器创建的数据。
3.3.1 The root zone MUST be signed by the Internet Assigned Numbers Authority (IANA) in accordance with DNSSEC, see [RFC2535] or its replacements. It is understood that DNSSEC is not yet deployable on some common platforms, but will be deployed when supported.
3.3.1 根区域必须由互联网分配号码管理局（IANA）根据DNSSEC签署，见[RFC2535]或其替代文件。据了解，DNSSEC还不能部署在一些通用平台上，但将在支持时部署。
3.3.2 Root servers MUST be DNSSEC-capable so that queries may be authenticated by clients with security and authentication concerns. It is understood that DNSSEC is not yet deployable on some common platforms, but will be deployed when supported.
3.3.2 根服务器必须支持DNSSEC，以便查询可以由具有安全性和身份验证问题的客户端进行身份验证。据了解，DNSSEC还不能部署在一些通用平台上，但将在支持时部署。
3.3.3 Transfer of the root zone between root servers MUST be authenticated and be as secure as reasonably possible. Out of band security validation of updates MUST be supported. Servers MUST use DNSSEC to authenticate root zones received from other servers. It is understood that DNSSEC is not yet deployable on some common platforms, but will be deployed when supported.
3.3.3 根服务器之间的根区域传输必须经过身份验证，并且尽可能安全。必须支持更新的带外安全验证。服务器必须使用DNSSEC对从其他服务器接收的根区域进行身份验证。据了解，DNSSEC还不能部署在一些通用平台上，但将在支持时部署。
3.3.4 A 'hidden primary' server, which only allows access by the authorized secondary root servers, MAY be used.
3.3.4 可以使用“隐藏的主”服务器，该服务器只允许授权的次根服务器访问。
3.3.5 Root zone updates SHOULD only progress after a number of heuristic checks designed to detect erroneous updates have been passed. In case the update fails the tests, human intervention MUST be requested.
3.3.5 根区域更新应仅在通过了大量旨在检测错误更新的启发式检查后进行。如果更新未能通过测试，则必须请求人工干预。
3.3.6 Root zone updates SHOULD normally be effective no later than 6 hours from notification of the root server operator.
3.3.6 根区域更新通常应在通知根服务器操作员后6小时内生效。
3.3.7 A special procedure for emergency updates SHOULD be defined. Updates initiated by the emergency procedure SHOULD be made no later than 12 hours after notification.
3.3.7 应规定紧急更新的特殊程序。由应急程序启动的更新应在通知后12小时内进行。
3.3.8 In the advent of a critical network failure, each root server MUST have a method to update the root zone data via a medium which is delivered through an alternative, non-network, path.
3.3.8 在出现严重网络故障时，每个根服务器必须有一种方法，通过一种介质更新根区域数据，该介质通过另一种非网络路径传送。
3.3.9 Each root MUST keep global statistics on the amount and types of queries received/answered on a daily basis. These statistics must be made available to RSSAC and RSSAC sponsored researchers to help determine how to better deploy these machines more efficiently across the
3.3.9 每个root用户必须每天对收到/回答的查询数量和类型进行全局统计。这些统计数据必须提供给RSSAC和RSSAC赞助的研究人员，以帮助确定如何更好地在全球范围内更有效地部署这些机器
internet. Each root MAY collect data snapshots to help determine data points such as DNS query storms, significant implementation bugs, etc.
互联网每个根用户都可以收集数据快照，以帮助确定数据点，如DNS查询风暴、重大实现错误等。
Communications and coordination between root server operators and between the operators and the IANA and ICANN are necessary.
根服务器运营商之间以及运营商与IANA和ICANN之间的通信和协调是必要的。
4.1 Planned outages and other down times SHOULD be coordinated between root server operators to ensure that a significant number of the root servers are not all down at the same time. Preannouncement of planned outages also keeps other operators from wasting time wondering about any anomalies.
4.1 根服务器操作员之间应协调计划内停机和其他停机时间，以确保大量根服务器不会同时全部停机。计划停机的预先通知还可以避免其他运营商浪费时间去思考任何异常情况。
4.2 Root server operators SHOULD coordinate backup timing so that many servers are not off-line being backed up at the same time. Backups SHOULD be frequently transferred off site.
4.2 根服务器操作员应协调备份时间，以使许多服务器不会同时离线备份。备份应经常转移到异地。
4.3 Root server operators SHOULD exchange log files, particularly as they relate to security, loading, and other significant events. This MAY be through a central log coordination point, or MAY be informal.
4.3 根服务器操作员应交换日志文件，尤其是与安全、加载和其他重要事件相关的日志文件。这可以通过中心日志协调点进行，也可以是非正式的。
4.4 Statistics as they concern usage rates, loading, and resource utilization SHOULD be exchanged between operators, and MUST be reported to the IANA for planning and reporting purposes.
4.4 有关使用率、负载和资源利用率的统计数据应在运营商之间交换，并且必须向IANA报告，以便进行规划和报告。
4.5 Root name server administrative personnel MUST be available to provide service 24 hours a day, 7 days per week. On call personnel MAY be used to provide this service outside of normal working hours.
4.5 Root name服务器管理人员必须每周7天、每天24小时提供服务。待命人员可在正常工作时间以外提供此项服务。
The authors would like to thank Scott Bradner, Robert Elz, Chris Fletcher, John Klensin, Steve Bellovin, and Vern Paxson for their constructive comments.
作者要感谢Scott Bradner、Robert Elz、Chris Fletcher、John Klesins、Steve Bellovin和Vern Paxson的建设性评论。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（版本3）规范，实施”，RFC1305，1992年3月。
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2030]Mills，D.“IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版”，RFC 2030，1996年10月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC2535] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，D.和C.Kaufman，“域名系统安全扩展”，RFC25351999年3月。
Randy Bush Verio, Inc. 5147 Crystal Springs Bainbridge Island, WA US-98110
Randy Bush Verio，Inc.5147 Crystal Springs Bainbridge Island，WA US-98110
Phone: +1 206 780 0431
EMail: randy@psg.com
Phone: +1 206 780 0431
EMail: randy@psg.com
Daniel Karrenberg RIPE Network Coordination Centre (NCC) Singel 258 NL-1016 AB Amsterdam Netherlands
Daniel Karrenberg成熟网络协调中心（NCC）Singel 258 NL-1016 AB荷兰阿姆斯特丹
Phone: +31 20 535 4444
EMail: daniel.karrenberg@ripe.net
Phone: +31 20 535 4444
EMail: daniel.karrenberg@ripe.net
Mark Kosters Network Solutions 505 Huntmar Park Drive Herndon, VA 22070-5100
Mark Kosters网络解决方案，弗吉尼亚州赫恩登市亨特马公园大道505号，邮编22070-5100
Phone: +1 703 742 0400
EMail: markk@netsol.com
Phone: +1 703 742 0400
EMail: markk@netsol.com
Raymond Plzak SAIC 1710 Goodridge Drive McLean, Virginia 22102 +1 703 821 6535
雷蒙德·普扎克（Raymond Plzak SAIC）弗吉尼亚州麦克莱恩古德里奇大道1710号22102+1 703 821 6535
EMail: plzakr@saic.com
EMail: plzakr@saic.com
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中的说明进行解释。
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编辑功能的资金目前由互联网协会提供。