Network Working Group M. Blaze
Request for Comments: 3586 AT&T Labs - Research
Category: Standards Track A. Keromytis
Columbia University
M. Richardson
Sandelman Software Works
L. Sanchez
Xapiens Corporation
August 2003
Network Working Group M. Blaze
Request for Comments: 3586 AT&T Labs - Research
Category: Standards Track A. Keromytis
Columbia University
M. Richardson
Sandelman Software Works
L. Sanchez
Xapiens Corporation
August 2003
IP Security Policy (IPSP) Requirements
IP安全策略（IPSP）要求
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes the problem space and solution requirements for developing an IP Security Policy (IPSP) configuration and management framework. The IPSP architecture provides a scalable, decentralized framework for managing, discovering and negotiating the host and network security policies that govern access, authorization, authentication, confidentiality, data integrity, and other IP Security properties. This document highlights such architectural components and presents their functional requirements.
本文档描述了开发IP安全策略（IPSP）配置和管理框架的问题空间和解决方案要求。IPSP体系结构提供了一个可扩展、分散的框架，用于管理、发现和协商管理访问、授权、身份验证、机密性、数据完整性和其他IP安全属性的主机和网络安全策略。本文档重点介绍了此类体系结构组件，并介绍了它们的功能需求。
Table of Contents
目录
1. Introduction.................................................. 2
1.1. Terminology............................................. 2
1.2. Security Policy and IPsec............................... 2
2. The IP Security Policy Problem Space.......................... 3
3. Requirements for an IP Security Policy Configuration and
Management Framework.......................................... 5
3.1. General Requirements.................................... 5
3.2. Description and Justification........................... 5
3.2.1. Policy Model.................................... 5
3.2.2. Security Gateway Discovery...................... 6
1. Introduction.................................................. 2
1.1. Terminology............................................. 2
1.2. Security Policy and IPsec............................... 2
2. The IP Security Policy Problem Space.......................... 3
3. Requirements for an IP Security Policy Configuration and
Management Framework.......................................... 5
3.1. General Requirements.................................... 5
3.2. Description and Justification........................... 5
3.2.1. Policy Model.................................... 5
3.2.2. Security Gateway Discovery...................... 6
3.2.3. Policy Specification Language................... 6
3.2.4. Distributed policy.............................. 6
3.2.5. Policy Discovery................................ 6
3.2.6. Security Association Resolution................. 6
3.2.7. Compliance Checking............................. 7
4. Security Considerations....................................... 7
5. IANA Considerations........................................... 7
6. Intellectual Property Statement............................... 7
7. References.................................................... 8
7.1. Normative References.................................... 8
7.2. Informative References.................................. 8
8. Disclaimer.................................................... 8
9. Acknowledgements.............................................. 8
10. Authors' Addresses............................................ 9
11. Full Copyright Statement...................................... 10
3.2.3. Policy Specification Language................... 6
3.2.4. Distributed policy.............................. 6
3.2.5. Policy Discovery................................ 6
3.2.6. Security Association Resolution................. 6
3.2.7. Compliance Checking............................. 7
4. Security Considerations....................................... 7
5. IANA Considerations........................................... 7
6. Intellectual Property Statement............................... 7
7. References.................................................... 8
7.1. Normative References.................................... 8
7.2. Informative References.................................. 8
8. Disclaimer.................................................... 8
9. Acknowledgements.............................................. 8
10. Authors' Addresses............................................ 9
11. Full Copyright Statement...................................... 10
The keywords "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]中所述进行解释。
Network-layer security now enjoys broad popularity as a tool for protecting Internet traffic and resources. Security at the network layer can be used as a tool for at least two kinds of security architecture:
网络层安全现在作为一种保护互联网流量和资源的工具受到广泛的欢迎。网络层的安全性可以用作至少两种安全体系结构的工具：
a) Security gateways. Security gateways (including "firewalls") at the edges of networks use IPsec [RFC-2401] to enforce access control, protect the confidentiality and authenticity of network traffic entering and leaving a network, and to provide gateway services for virtual private networks (VPNs).
a) 安全网关。网络边缘的安全网关（包括“防火墙”）使用IPsec[RFC-2401]实施访问控制，保护进出网络的网络流量的机密性和真实性，并为虚拟专用网络（VPN）提供网关服务。
b) Secure end-to-end communication. Hosts use IPsec to implement host-level access control, to protect the confidentiality and authenticity of network traffic exchanged with the peer hosts with which they communicate, and to join virtual private networks.
b) 安全的端到端通信。主机使用IPsec实现主机级访问控制，保护与其通信的对等主机交换的网络流量的机密性和真实性，并加入虚拟专用网络。
On one hand, IPsec provides an excellent basis for a very wide range of protection schemes; on the other hand, this wide range of applications for IPsec creates complex management tasks that become especially difficult as networks scale up and require different security policies, and are controlled by different entities, for different kinds of traffic in different parts of the network.
一方面，IPsec为广泛的保护方案提供了良好的基础；另一方面，IPsec的这一广泛应用程序创建了复杂的管理任务，随着网络规模的扩大，这些任务变得特别困难，需要不同的安全策略，并且由不同的实体针对网络不同部分的不同类型的流量进行控制。
As organizations deploy security gateways, the Internet divides into heterogeneous regions that enforce different access and security policies. Yet it is often still necessary for hosts to communicate across the network boundaries controlled by several different policies. The wide range of choices of cryptographic parameters (at multiple protocol layers) complicates matters and introduces the need for hosts and security gateways to identify and negotiate a set of security parameters that meets each party's requirements. Even more complexity arises as IPsec becomes the means through which firewalls enforce access control and VPN membership; two IPsec endpoints that want to establish a security association must identify, not only the mutually acceptable cryptographic parameters, but also exactly what kind of access the combined security policy provides.
当组织部署安全网关时，Internet会分成不同的区域，这些区域实施不同的访问和安全策略。然而，主机通常仍然需要跨越由多个不同策略控制的网络边界进行通信。加密参数的广泛选择（在多个协议层）使问题复杂化，并引入了主机和安全网关识别和协商满足各方要求的一组安全参数的需求。随着IPsec成为防火墙实施访问控制和VPN成员身份的手段，情况变得更加复杂；要建立安全关联的两个IPsec端点不仅必须标识相互可接受的加密参数，而且还必须准确标识组合安全策略提供的访问类型。
While the negotiation of cryptographic and other security parameters for IPsec security associations (SAs) is supported by key management protocols (e.g., ISAKMP [RFC-2408]), the IPsec key management layer does not provide a scheme for managing, negotiating, or enforcing the security policies under which SAs operate.
虽然密钥管理协议（例如，ISAKMP[RFC-2408]）支持IPsec安全关联（SA）的加密和其他安全参数协商，但IPsec密钥管理层不提供用于管理、协商或强制执行SA运行所依据的安全策略的方案。
IPSP provides the framework for managing IPsec security policy, negotiating security association (SA) parameters between IPsec endpoints, and distributing authorization and policy information among hosts that require the ability to communicate via IPsec.
IPSP提供用于管理IPsec安全策略、在IPsec端点之间协商安全关联（SA）参数以及在需要通过IPsec进行通信的主机之间分发授权和策略信息的框架。
IPSP aims to provide a scalable, decentralized framework for managing, discovering and negotiating the host and network IPsec policies that govern access, authorization, cryptographic mechanisms, confidentiality, data integrity, and other IPsec properties.
IPSP旨在提供一个可扩展、分散的框架，用于管理、发现和协商主机和网络IPsec策略，这些策略管理访问、授权、加密机制、机密性、数据完整性和其他IPsec属性。
The central problem solved by IPSP is that of controlling security policy in a manner that is useful for the wide range of IPsec applications and modes of operation. In particular:
IPSP解决的中心问题是以一种对广泛的IPsec应用程序和操作模式有用的方式控制安全策略。特别地：
- IPSP hosts may serve as IPsec endpoints, security gateways, network management hubs, or a combination of these functions. IPSP will manage end-users computers (which may be fixed workstations controlled by a single organization or mobile laptops that require remote access to a corporate VPN), firewalls (which provide different services and allow different levels of access to different classes of traffic and users), VPN routers (which support links to other VPNs that might be controlled by a different organization's network policy), web and other servers (which might provide different services depending on where a client request came from), and so on.
- IPSP主机可以用作IPsec端点、安全网关、网络管理中心或这些功能的组合。IPSP将管理终端用户计算机（可能是由单个组织控制的固定工作站或需要远程访问公司VPN的移动笔记本电脑）、防火墙（提供不同服务并允许不同级别的访问不同类别的流量和用户）、VPN路由器（支持到可能由不同组织的网络策略控制的其他VPN的链接）、web和其他服务器（根据客户端请求来自何处，可能提供不同的服务），等等。
- IPSP administration will be inherently heterogeneous and decentralized. A basic feature of IPsec is that two hosts can establish a Security Association even though they might not share a common security policy, or, indeed, trust one another at all. This property of IPsec becomes even more pronounced at the higher level abstraction managed by IPSP.
- IPSP管理将本质上是异构和分散的。IPsec的一个基本特性是，两台主机可以建立安全关联，即使它们可能不共享公共安全策略，或者实际上彼此信任。IPsec的这一特性在IPSP管理的更高级别抽象中变得更加明显。
- The SA parameters acceptable to any pair of hosts (operating under different policies) will often not be specified in advance. IPSP will often have to negotiate and discover the mutually-acceptable SA parameters on-the-fly when two hosts attempt to create a new SA.
- 通常不会提前指定任何一对主机（在不同策略下运行）可接受的SA参数。当两台主机试图创建新的SA时，IPSP通常必须动态协商和发现双方可接受的SA参数。
- Some hosts will be governed by policies that are not directly specified in the IPSP language. For example, a host's IPsec policy might be derived from a more comprehensive higher-layer security policy managed by some other system. Similarly, some vendors might develop specialized (and proprietary) tools for managing policy in their products. In such cases, it is necessary to derive an IPSP policy specification for only those aspects of a host's policy that involve interoperability with other hosts running IPSP.
- 某些主机将由IPSP语言中未直接指定的策略管理。例如，主机的IPsec策略可能来自由其他系统管理的更全面的高层安全策略。类似地，一些供应商可能会开发专门的（和专有的）工具来管理其产品中的策略。在这种情况下，有必要仅为主机策略中涉及与运行IPSP的其他主机互操作性的那些方面推导IPSP策略规范。
- IPSP must scale to support complex policy administration schemes. In even modest-size networks, one administrator must often control policy remotely, and must have the ability to change the policy on many different hosts at the same time. In larger networks (or those belonging to large organizations), a host's policy might be governed by several different authorities (e.g., several different departments might have the authority to add users to a firewall or open access to new services). Different parts of a policy might be "owned" by different entities in a complex hierarchy. IPSP must provide a mechanism for delegating specific kinds of authority to specific entities.
- IPSP必须扩展以支持复杂的策略管理方案。在中等规模的网络中，一名管理员通常必须远程控制策略，并且必须能够同时在多个不同主机上更改策略。在大型网络（或属于大型组织的网络）中，主机的策略可能由多个不同的机构管理（例如，多个不同的部门可能有权将用户添加到防火墙或开放访问新服务）。策略的不同部分可能由复杂层次结构中的不同实体“拥有”。IPSP必须提供一种机制，将特定类型的权限委托给特定实体。
- The semantics of IPSP must be well defined, particularly with respect to any security-critical aspects of the system.
- IPSP的语义必须得到很好的定义，特别是关于系统的任何安全关键方面。
- IPSP must be secure, sound, and comprehensible. It should be possible to understand what an IPSP policy does; the difficulty of understanding an IPSP policy should be somewhat proportional to the complexity of the problem it solves. It should also be possible to have confidence that an IPSP policy does what it claims, and that IPSP implementation is correct; architecturally, the security-critical parts of IPSP should be small and well-specified enough to allow verification of their correct operation. Ideally, IPSP should be compatible with
- IPSP必须安全、可靠且易于理解。应该能够理解IPSP政策的作用；理解IPSP策略的难度应与其解决问题的复杂性成一定比例。还应能够确信IPSP政策符合其要求，且IPSP实施是正确的；在体系结构上，IPSP的安全关键部分应该很小，并且有足够的详细说明，以允许验证它们的正确操作。理想情况下，IPSP应该与
formal methods, such as implementing security policies with provable properties.
形式化方法，例如实现具有可证明属性的安全策略。
3. Requirements for an IP Security Policy Configuration and Management Framework
3. IP安全策略配置和管理框架的要求
An IPSP solution MUST include:
IPSP解决方案必须包括：
- A policy model with well-defined semantics that captures the relationship between IPsec SAs and higher-level security policies,
- 具有定义良好语义的策略模型，可捕获IPsec SA与更高级别安全策略之间的关系，
- A gateway discovery mechanism that allows hosts to discover where to direct IPsec traffic intended for a specific endpoint,
- 网关发现机制，允许主机发现将用于特定端点的IPsec通信定向到何处，
- A well-specified language for describing host policies,
- 用于描述主机策略的指定语言，
- A means for distributing responsibility for different aspects of policy to different entities,
- 将政策不同方面的责任分配给不同实体的方法，
- A mechanism for discovering the policy of a host,
- 发现主机策略的机制，
- A mechanism for resolving the specific IPsec parameters to be used between two hosts governed by different policies (and for determining whether any such parameters exist); and,
- 用于解析由不同策略管理的两台主机之间要使用的特定IPsec参数的机制（以及用于确定是否存在任何此类参数）；和
- A well-specified mechanism for checking for compliance with a host's policy when SAs are created.
- 创建SA时，用于检查是否符合主机策略的指定机制。
The mechanisms used in IPSP must not require any protocol modifications in any of the IPsec standards (ESP [RFC-2406], AH, [RFC-2402], IKE [RFC-2409]). The mechanisms must be independent of the SA-negotiation protocol, but may assume certain functionality from such a protocol (this is to ensure that future SA-negotiation protocols are not incompatible with IPSP).
IPSP中使用的机制不得要求任何IPsec标准（ESP[RFC-2406]、AH[RFC-2402]、IKE[RFC-2409]）中的任何协议修改。这些机制必须独立于SA协商协议，但可以承担此类协议的某些功能（这是为了确保未来的SA协商协议不会与IPSP不兼容）。
A Policy Model defines the semantics of IPsec policy. Policy specification, checking, and resolution should implement the semantics defined in the model. However, the model should be independent of the specific policy distribution mechanism and policy discovery scheme, to the extent possible.
策略模型定义IPsec策略的语义。策略规范、检查和解析应该实现模型中定义的语义。但是，该模型应尽可能独立于特定的策略分发机制和策略发现方案。
The gateway discovery mechanism may be invoked by any host or gateway. Its goal is to determine what IPsec gateways exist between the initiator and the intended communication peer. The actual mechanism employed may be used to piggy-back information necessary by other components of the IPSP architecture (e.g., policy discovery, as is done in [SPP]). The discovery mechanism may have to be invoked at any time, independently of existing security associations or other communication, to detect topology changes.
网关发现机制可由任何主机或网关调用。其目标是确定发起方和预期通信对等方之间存在哪些IPsec网关。所采用的实际机制可用于携带IPSP体系结构的其他组件所需的信息（例如，策略发现，如[SPP]中所述）。可能必须随时调用发现机制，独立于现有安全关联或其他通信，以检测拓扑更改。
In order to allow for policy discovery, compliance checking, and resolution across a range of hosts, a common language is necessary in which to express the policies of hosts that need to communicate with one another. Statements in this language are the output of policy discovery, and provide the input to the policy resolution and compliance checking systems. Note that a host's or network's security policy may be expressed in a vendor-specific way, but would be translated to the common language when it is to be managed by the IPSP services.
为了允许跨一系列主机进行策略发现、法规遵从性检查和解析，需要一种通用语言来表示需要相互通信的主机的策略。此语言中的语句是策略发现的输出，并向策略解析和符合性检查系统提供输入。请注意，主机或网络的安全策略可能以特定于供应商的方式表示，但在由IPSP服务管理时，会转换为通用语言。
As discussed above, it must be possible for all or part of a host's policy to be managed remotely, possibly by more than one entity. This is a basic requirement for large-scale networks and systems.
如上所述，必须能够远程管理主机策略的全部或部分，可能由多个实体管理。这是大规模网络和系统的基本要求。
A policy discovery mechanism must provide the essential information that two IPsec endpoints can use to determine what kinds of SAs are possible between one another. This is especially important for hosts that are not controlled by the same entity, and that might not initially share any common information about one another. Note that a host need not reveal its entire security policy, only enough information to support the SA resolution system for hosts that might want to communicate with it.
策略发现机制必须提供两个IPsec端点可以用来确定彼此之间可能存在何种SA的基本信息。这对于不受同一实体控制的主机尤其重要，因为这些主机可能最初不共享关于彼此的任何公共信息。请注意，主机不需要显示其整个安全策略，只需要提供足够的信息来支持可能要与其通信的主机的SA解析系统。
Once two hosts have learned enough about each other's policies, it must be possible (and computationally feasible) to find an acceptable set of SA parameters that meets both host's requirements and will lead to the successful creation of a new SA.
一旦两个主机充分了解了彼此的策略，就必须能够（并且在计算上是可行的）找到一组可接受的SA参数，以满足两个主机的要求，并成功创建新的SA。
When a host proposes the output of the SA resolution scheme, it must be checked for compliance with the local security policy of each host. The security and soundness of the SAs created by IPSP-managed communication should depend only on the correctness of the compliance checking stage. In particular, even if the SA resolution scheme (which is likely to be computationally and conceptually complex) produces an incorrect result, it should still not be possible to violate the specified policy of either host.
当主机提出SA解决方案的输出时，必须检查其是否符合每个主机的本地安全策略。IPSP管理的通信创建的SA的安全性和可靠性应仅取决于合规性检查阶段的正确性。特别是，即使SA解析方案（可能在计算和概念上都很复杂）产生错误的结果，也不可能违反任一主机的指定策略。
This document discusses the high-level requirements for a policy framework and architecture for IPsec. A justification for the various components is given.
本文档讨论IPsec策略框架和体系结构的高级需求。给出了各种组件的理由。
No action is required by IANA.
IANA无需采取任何行动。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。
Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC-2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC-2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC-2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC-2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC-2408] Maughan, D., Shertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC-2408]Maughan，D.，Shertler，M.，Schneider，M.和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[RFC-2409] Harkins, D and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC-2409]Harkins，D和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[SPP] Sanchez, L. and M. Condell, "The Security Policy Protocol", Work in Progress.
[SPP]Sanchez，L.和M.Condell，“安全策略协议”，正在进行中。
The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification.
这里的观点和规范是作者的观点和规范，不一定是他们的雇主的观点和规范。作者及其雇主明确否认对因正确或不正确实施或使用本规范而产生的任何问题负责。
The authors thank the members of the IPsec Policy working group that contributed to this document.
作者感谢IPsec策略工作组的成员，他们为本文档做出了贡献。
Matt Blaze AT&T Labs - Research 180 Park Avenue Florham Park, NJ 07932 USA
马特·布莱泽AT&T实验室-美国新泽西州弗洛勒姆公园公园大道180号研究中心，邮编：07932
EMail: mab@crypto.com
EMail: mab@crypto.com
Angelos D. Keromytis Computer Science Department Columbia University 1214 Amsterdam Avenue, M.C. 0401 New York, NY 10027, USA
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系Angelos D.Keromytis 0401
EMail: angelos@cs.columbia.edu
EMail: angelos@cs.columbia.edu
Michael C. Richardson Sandelman Software Works Corp. 470 Dawson Avenue Ottawa, ON K1Z 5V7 Canada
加拿大K1Z 5V7渥太华道森大道470号Michael C.Richardson Sandelman软件工程公司
Phone: +1 613 276-6809
EMail: mcr@sandelman.ottawa.on.ca
Phone: +1 613 276-6809
EMail: mcr@sandelman.ottawa.on.ca
Luis A. Sanchez Xapiens Corporation PO Box 9023694 San Juan, PR 00902 USA
路易斯·桑切斯·哈皮恩斯公司，邮政信箱9023694，圣胡安，美国，邮编00902
Phone: +1 (787) 832-4717
EMail: lsanchez@xapiens.com
Phone: +1 (787) 832-4717
EMail: lsanchez@xapiens.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。