Network Working Group A. Retana
Request for Comments: 3021 R. White
Category: Standards Track Cisco Systems
V. Fuller
GTE Internetworking
D. McPherson
Amber Networks
December 2000
Network Working Group A. Retana
Request for Comments: 3021 R. White
Category: Standards Track Cisco Systems
V. Fuller
GTE Internetworking
D. McPherson
Amber Networks
December 2000
Using 31-Bit Prefixes on IPv4 Point-to-Point Links
在IPv4点到点链路上使用31位前缀
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
摘要
With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way.
在互联网上保存IP地址空间的压力越来越大，考虑到如何进行相对较小的改变以提高编码效率，这是有意义的。本文件提出的一个此类变更是，通过允许以非常有限的方式使用31位子网掩码，将分配给点到点链路（在整个互联网基础设施中通用）的地址空间量减半。
The perceived problem of a lack of Internet addresses has driven a number of changes in address space usage and a number of different approaches to solving the problem:
缺乏互联网地址的问题已经导致地址空间使用的许多变化，以及解决问题的许多不同方法：
- More stringent address space allocation guidelines, enforced by the IANA and the regional address assignment authorities [RFC2050].
- 由IANA和区域地址分配机构执行的更严格的地址空间分配指南[RFC2050]。
- Use of Network Address Translators (NATs), where a small number of IANA-compliant addresses are shared by a larger pool of private, non-globally routed addresses topologically behind a NAT box [RFC1631].
- 网络地址转换器（NAT）的使用，其中少量符合IANA的地址由NAT盒后面拓扑上更大的私有、非全局路由地址池共享[RFC1631]。
- Deployment of a new Internet Protocol to increase the size of the address space. One such protocol, IPv6 [RFC2460], has been through the IETF process but has yet to see production deployment. Should it be, deployed, it will still face a many year transition period.
- 部署新的Internet协议以增加地址空间的大小。其中一个协议IPv6[RFC2460]已经通过IETF过程，但尚未看到产品部署。如果部署，它仍将面临多年的过渡期。
Prior to the availability of a larger address space, it seems prudent to consider opportunities for making more efficient use of the existing address space.
在获得更大地址空间之前，考虑更有效地使用现有地址空间似乎是谨慎的。
One such (small) opportunity is to change the way that point-to-point links are numbered. One option, which is used today on some parts of the Internet, is to simply not number point-to-point links between routers. While this practice may seem, at first, to handily resolve the problem, it causes a number of problems of its own, including the inability to consistently manage the unnumbered link or reach a router through it, difficulty in management and debugging of those links, and the lack of standardization [RFC1812].
其中一个（小）机会是改变点对点链接的编号方式。一种选择是不给路由器之间的点对点链接编号，这种选择目前在互联网的某些部分使用。虽然这种做法一开始似乎可以很容易地解决问题，但它本身也会导致一些问题，包括无法始终如一地管理未编号的链路或通过它到达路由器，这些链路的管理和调试困难，以及缺乏标准化[RFC1812]。
In current practice, numbered Internet subnets do not use longer than a 30-bit subnet mask (in most cases), which requires four addresses per link - two host addresses, one all-zeros network, and one all-ones broadcast. This is unfortunate for point-to-point links, since they can only possibly have two identifying endpoints and don't support the notion of broadcast - any packet which is transmitted by one end of a link is always received by the other.
在当前实践中，已编号的Internet子网使用的子网掩码长度不超过30位（在大多数情况下），每个链路需要四个地址—两个主机地址、一个全零网络和一个全一广播。这对于点到点链路来说是不幸的，因为它们可能只有两个识别端点，并且不支持广播的概念——任何由链路一端传输的数据包总是由另一端接收。
A third option is to use host addresses on both ends of a point-to-point link. This option provides the same address space savings as using a 31-bit subnet mask, but may only be used in links using PPP encapsulation [RFC1332]. The use of host addresses allows for the assignment of IP addresses belonging to different networks at each side of the link, causing link and network management not to be straight forward.
第三种选择是在点到点链路的两端使用主机地址。此选项提供与使用31位子网掩码相同的地址空间节省，但只能在使用PPP封装的链路中使用[RFC1332]。主机地址的使用允许在链路的每一侧分配属于不同网络的IP地址，从而导致链路和网络管理不能直接进行。
This document is based on the idea that conserving IP addresses on point-to-point links (using longer than a 30-bit subnet mask) while maintaining manageability and standard interaction is possible. Existing documentation [RFC950] has already hinted at the possible use of a 1-bit wide host-number field.
本文档基于这样一种理念，即在保持可管理性和标准交互的同时保存点到点链路上的IP地址（使用超过30位的子网掩码）。现有文档[RFC950]已经暗示可能使用1位宽的主机号字段。
The savings in address space resulting from this change is easily seen--each point-to-point link in a large network would consume two addresses instead of four. In a network with 500 point-to-point links, for example, this practice would amount to a savings of 1000 addresses (the equivalent of four class C address spaces).
这种改变所节省的地址空间显而易见——大型网络中的每个点到点链路将消耗两个地址，而不是四个地址。例如，在具有500个点到点链路的网络中，这种做法将节省1000个地址（相当于四个C类地址空间）。
This section discusses the possible effects, on Internet routing and operations, of using 31-bit prefixes on point-to-point links. The considerations made here are also reflected in Section 3.
本节讨论在点到点链路上使用31位前缀对Internet路由和操作的可能影响。这里所作的考虑也反映在第3节中。
For the length of this document, an IP address will be interpreted as:
在本文件中，IP地址将解释为：
<Network-number><Host-number>
<Network-number><Host-number>
where the <Host-number> represents the unmasked portion of the address and it SHOULD be at least 1 bit wide. The "-1" notation is used to mean that the field has all 1 bits. For purposes of this discussion, the routing system is considered capable of classless, or CIDR [RFC1519], routing.
其中，<Host number>表示地址的未屏蔽部分，并且至少应为1位宽。“-1”表示法用于表示该字段包含所有1位。在本讨论中，路由系统被认为能够进行无类路由或CIDR[RFC1519]路由。
If a 31-bit subnet mask is assigned to a point-to-point link, it leaves the <Host-number> with only 1 bit. Consequently, only two possible addresses may result:
如果将31位子网掩码分配给点到点链路，则<Host number>仅保留1位。因此，只能产生两个可能的地址：
{<Network-number>, 0} and {<Network-number>, -1}
{<Network-number>, 0} and {<Network-number>, -1}
These addresses have historically been associated with network and broadcast addresses (see Section 2.2). In a point-to-point link with a 31-bit subnet mask, the two addresses above MUST be interpreted as host addresses.
这些地址历来与网络和广播地址相关联（见第2.2节）。在具有31位子网掩码的点到点链路中，上述两个地址必须解释为主机地址。
There are several historically recognized broadcast addresses [RFC1812] on IP segments:
IP段上有几个历史上公认的广播地址[RFC1812]：
(a) the directed broadcast
(a) 定向广播
{<Network-number>, -1}
{<Network-number>, -1}
{<Network-number>, 0}
{<Network-number>, 0}
The network address itself {<Network-number>, 0} is an obsolete form of directed broadcast, but it may still be used by older hosts.
网络地址本身{<networknumber>，0}是一种过时的定向广播形式，但旧主机仍可以使用它。
(b) the link local (or limited) broadcast
(b) 本地（或有限）广播的链接
{-1, -1}
{-1, -1}
{0, 0}
{0, 0}
The {0, 0} form of a limited broadcast is obsolete, but may still be present in a network.
有限广播的{0，0}形式已经过时，但可能仍然存在于网络中。
Using a 31-bit prefix length leaves only two numbering possibilities (see Section 2.1), eliminating the use of a directed broadcast to the link (see Section 2.2.1). The limited broadcast MUST be used for all broadcast traffic on a point-to-point link with a 31-bit subnet mask assigned to it.
使用31位前缀长度只留下两种编号可能性（见第2.1节），从而消除了对链路的定向广播（见第2.2.1节）。有限广播必须用于分配有31位子网掩码的点到点链路上的所有广播流量。
The <Network-number> is assigned by the network administrator as unique to the local routing domain. The decision as to whether a destination IP address should be a directed broadcast or not is made by the router directly connected to the destination segment. Current forwarding schemes and algorithms are not affected in remote routers.
网络管理员将<Network number>指定为本地路由域唯一的。由直接连接到目的网段的路由器决定目的IP地址是否应该是定向广播。当前的转发方案和算法在远程路由器中不受影响。
The intent of this document is to discuss the applicability and operation of 31-bit prefixes on point-to-point links. The effects (if any) on other types of interfaces are not considered.
本文档旨在讨论点到点链路上31位前缀的适用性和操作。不考虑对其他类型接口的影响（如有）。
When a device wants to reach all the hosts on a given (remote, rather than directly connected) subnet, it may set the packet's destination address to the link's subnet broadcast address. This operation is not possible for point-to-point links with a 31-bit prefix.
当设备想要到达给定（远程，而不是直接连接）子网上的所有主机时，它可以将数据包的目标地址设置为链路的子网广播地址。对于具有31位前缀的点到点链路，此操作不可能。
As discussed in Section 6, the loss of functionality of a directed broadcast may actually be seen as a beneficial side effect, as it slightly enhances the network's resistance to a certain class of DoS Attacks [RFC2644, SMURF].
如第6节所述，定向广播功能的丧失实际上可能被视为一种有益的副作用，因为它略微增强了网络对某种DoS攻击的抵抗力[RFC2644，SMURF]。
Networks with 31-bit prefixes have no impact on current routing protocols. Most of the currently deployed routing protocols have been designed to provide classless routing. Furthermore, the communication between peers is done using multicast, limited broadcast or unicast addresses (all on the local network), none of which are affected with the use of 31-bit subnet masks.
具有31位前缀的网络对当前的路由协议没有影响。目前部署的大多数路由协议都是为提供无类路由而设计的。此外，对等方之间的通信使用多播、有限广播或单播地址（全部在本地网络上）完成，所有这些地址都不受31位子网掩码使用的影响。
The considerations presented in Section 2 affect other published work. This section details the updates made to other documents.
第2节中提出的考虑因素会影响其他已发表的作品。本节详细介绍了对其他文档所做的更新。
Section 3.2.1.3 (e) is replaced with:
第3.2.1.3（e）节替换为：
(e) { <Network-number>, <Subnet-number>, -1 }
(e) { <Network-number>, <Subnet-number>, -1 }
Directed broadcast to the specified subnet. It MUST NOT be used as a source address, except when the originator is one of the endpoints of a point-to-point link with a 31-bit mask.
定向广播到指定的子网。不得将其用作源地址，除非发起者是具有31位掩码的点到点链接的端点之一。
A new section (numbered 3.2.1.3 (h)) is added:
新增一节（编号为3.2.1.3（h））：
(h) { <Network-number>, <Subnet-number>, 0 }
(h) { <Network-number>, <Subnet-number>, 0 }
Subnetwork number. SHOULD NOT be used as a source address, except when the originator is one of the endpoints of a point-to-point link with a 31-bit mask. For other types of links, a packet with such a destination SHOULD be silently discarded. If these packets are not silently discarded, they MUST be treated as IP broadcasts [RFC1812].
子网编号。不应用作源地址，除非发起者是具有31位掩码的点到点链接的端点之一。对于其他类型的链接，具有这样一个目的地的数据包应该被悄悄地丢弃。如果这些数据包没有被悄悄地丢弃，它们必须被视为IP广播[RFC1812]。
Sub-section (e) of the "Special Addresses" section in the "Introduction" is replaced with:
“导言”中“特别地址”一节的（e）小节替换为：
(e) {<Network-number>, <Subnet-number>, -1}
(e) {<Network-number>, <Subnet-number>, -1}
Directed broadcast to specified subnet. Can only be used as a destination address. However, in the case where the originator is one of the endpoints of a point-to-point link with a 31-bit mask, it can also be used as a source address.
定向广播到指定子网。只能用作目标地址。但是，如果发起者是具有31位掩码的点到点链路的端点之一，则它也可以用作源地址。
Section 4.2.2.11 (d) is replaced with:
第4.2.2.11（d）节替换为：
(d) { <Network-prefix>, -1 }
(d) { <Network-prefix>, -1 }
Directed Broadcast - a broadcast directed to the specified network prefix. It MUST NOT be used as a source address, except when the originator is one of the endpoints of a point-
定向广播-定向到指定网络前缀的广播。不得将其用作源地址，除非发起者是点的端点之一-
to-point link with a 31-bit mask. A router MAY originate Network Directed Broadcast packets. A router MAY have a configuration option to allow it to receive directed broadcast packets, however this option MUST be disabled by default, and thus the router MUST NOT receive Network Directed Broadcast packets unless specifically configured by the end user.
到具有31位掩码的点链接。路由器可以发起网络定向广播分组。路由器可具有允许其接收定向广播数据包的配置选项，但是该选项在默认情况下必须被禁用，因此除非最终用户专门配置，否则路由器不得接收网络定向广播数据包。
The text above includes the update made by [RFC2644].
上述文本包括[RFC2644]所做的更新。
A new section (numbered 4.2.2.11 (f)) is added:
新增一节（编号为4.2.2.11（f））：
(f) { <Network-number>, <Subnet-number>, 0 }
(f) { <Network-number>, <Subnet-number>, 0 }
Subnetwork number. SHOULD NOT be used as a source address, except when the originator is one of the endpoints of a point-to-point link with a 31-bit mask. For other types of links, a packet with such a destination SHOULD be silently discarded. If these packets are not silently discarded, they MUST be treated as IP broadcasts.
子网编号。不应用作源地址，除非发起者是具有31位掩码的点到点链接的端点之一。对于其他类型的链接，具有这样一个目的地的数据包应该被悄悄地丢弃。如果这些数据包没有被悄悄地丢弃，它们必须被视为IP广播。
Sections 4.2.3.1 (1), (2) and (4) are replaced with:
第4.2.3.1（1）、（2）和（4）节替换为：
(1) MUST treat as IP broadcasts packets addressed to 255.255.255.255 or { <Network-prefix>, -1 }.
(1) 必须将地址为255.255.255.255或{<网络前缀>，-1}的数据包视为IP广播。
In a point-to-point link with a 31-bit mask, a packet addressed to { <Network-prefix>, -1 } corresponds to one of the endpoints of such link, it MUST be treated as directed to the router on which the address is applied.
在具有31位掩码的点到点链路中，寻址到{<Network prefix>，-1}的数据包对应于这种链路的一个端点，它必须被视为指向应用地址的路由器。
(2) SHOULD silently discard on receipt (i.e., do not even deliver to applications in the router) any packet addressed to 0.0.0.0 or { <Network-prefix>, 0 }. If these packets are not silently discarded, they MUST be treated as IP broadcasts (see Section [5.3.5]). There MAY be a configuration option to allow receipt of these packets. This option SHOULD default to discarding them.
(2) 应在收到任何发往0.0.0.0或{<Network prefix>，0}的数据包时自动丢弃（即，甚至不发送到路由器中的应用程序）。如果这些数据包未被悄悄丢弃，则必须将其视为IP广播（见第[5.3.5]节）。可能存在允许接收这些数据包的配置选项。此选项应默认为丢弃它们。
In a point-to-point link with a 31-bit mask, a packet addressed to { <Network-prefix>, 0 } corresponds to one of the endpoints of such link, it MUST be treated as directed to the router on which the address is applied.
在具有31位掩码的点到点链路中，寻址到{<Network prefix>，0}的数据包对应于该链路的一个端点，必须将其视为指向应用该地址的路由器。
(4) SHOULD NOT originate datagrams addressed to 0.0.0.0 or { <Network-prefix>, 0 }. There MAY be a configuration option to allow generation of these packets (instead of using the relevant 1s format broadcast). This option SHOULD default to not generating them.
(4) 不应产生地址为0.0.0.0或{<Network prefix>，0}的数据报。可能存在允许生成这些数据包的配置选项（而不是使用相关的1s格式广播）。此选项应默认为不生成它们。
In a point-to-point link with a 31-bit mask, the configuration of such a mask SHOULD allow for the generation of datagrams addressed to { <Network-prefix>, 0 }.
在具有31位掩码的点到点链路中，这种掩码的配置应允许生成寻址到{<Network prefix>，0}的数据报。
The following text is added to section 4.3.3.9:
第4.3.3.9节增加了以下内容：
The 255.255.255.255 IP broadcast address MUST be used for broadcast Address Mask Replies in point-to-point links with 31-bit subnet masks
255.255.255.255 IP广播地址必须用于具有31位子网掩码的点到点链路中的广播地址掩码回复
The recommendations presented in this document have been implemented by several router vendors in beta code. The implementation has been tested by at least three ISPs with positive results (i.e., no problems have been found). Among the routing protocols tested successfully are OSPF, IS-IS, BGP and EIGRP.
本文档中提出的建议已由多家路由器供应商在beta代码中实施。至少有三家ISP对该实施进行了测试，并取得了积极成果（即未发现任何问题）。成功测试的路由协议有OSPF、IS-IS、BGP和EIGRP。
It is expected that the implementation will be officially released within the next few months and that other vendors will adopt it.
预计该实现将在未来几个月内正式发布，其他供应商也将采用它。
The intent of this document is to discuss the applicability and operation of 31-bit prefixes on point-to-point links. The effects (if any) on other types of interfaces are not considered. Note that a point-to-point link in which only one end supports the use of 31- bit prefixes may not operate correctly.
本文档旨在讨论点到点链路上31位前缀的适用性和操作。不考虑对其他类型接口的影响（如有）。请注意，只有一端支持使用31位前缀的点对点链路可能无法正常工作。
In the light of various denial of service (DoS) attacks on various networks within the Internet, security has become a major concern. The use of 31-bit subnet masks within the core of the Internet will reduce the number of physical links against which a DoS attack relying on packet replication through the use of directed broadcasts can be launched [RFC2644, SMURF].
鉴于互联网中各种网络上的各种拒绝服务（DoS）攻击，安全性已成为一个主要问题。在互联网核心内使用31位子网掩码将减少物理链路的数量，通过使用定向广播，依赖数据包复制的DoS攻击可针对这些链路发起[RFC2644，SMURF]。
Overall, implementation of this document recommendation will improve the Internet's resilience to these types of DoS attacks.
总体而言，本文件建议的实施将提高互联网对此类拒绝服务攻击的抵御能力。
The authors of this document do not make any claims on the originality of the ideas described. Among other people, we would like to acknowledge Alex Zinin for his comments, and the many people who have tested 31 bit subnet masks in their labs and networks.
本文件的作者不对所述想法的独创性提出任何主张。在其他人中，我们要感谢Alex Zinin的评论，以及许多在实验室和网络中测试了31位子网掩码的人。
[RFC950] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985.
[RFC950]Mogul，J.和J.Postel，“互联网标准子网程序”，STD 5，RFC 950，1985年8月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求——通信层”，标准3，RFC 1122，1989年10月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]McGregor，G.“PPP互联网协议控制协议（IPCP）”，RFC1332，1992年5月。
[RFC1519] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[RFC1519]Fuller，V.，Li，T.，Yu，J.和K.Varadhan，“无类域间路由（CIDR）：地址分配和聚合策略”，RFC 1519，1993年9月。
[RFC1631] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.
[RFC1631]Egevang，K.和P.Francis，“IP网络地址转换器（NAT）”，RFC16311994年5月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700]Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 2050, November 1996.
[RFC2050]Hubbard，K.，Kosters，M.，Conrad，D.，Karrenberg，D.和J.Postel，“互联网注册IP分配指南”，BCP 12，RFC 2050，1996年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
[RFC2644]Senie，D.，“更改路由器中定向广播的默认设置”，BCP 34，RFC 2644，1999年8月。
[SMURF] Huegen, C., "The Latest in Denial of Service Attacks:
'Smurfing': Description and Information to Minimize
Effects", URL:
http://users.quadrunner.com/chuegen/smurf.cgi
[SMURF] Huegen, C., "The Latest in Denial of Service Attacks:
'Smurfing': Description and Information to Minimize
Effects", URL:
http://users.quadrunner.com/chuegen/smurf.cgi
Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709
阿尔瓦罗·雷塔纳思科系统公司，地址：北卡罗来纳州三角研究公园基特克里克路7025号，邮编：27709
EMail: aretana@cisco.com
EMail: aretana@cisco.com
Russ White Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709
Russ White Cisco Systems，Inc.地址：北卡罗来纳州三角研究公园Kit Creek路7025号，邮编：27709
EMail: riw@cisco.com
EMail: riw@cisco.com
Vince Fuller GTE Internetworking 3801 E. Bayshore Rd. Palo Alto, CA, 94303
Vince Fuller GTE互联网络美国加利福尼亚州帕洛阿尔托市海湾大道东3801号，邮编94303
EMail: vaf@valinor.barrnet.net
EMail: vaf@valinor.barrnet.net
Danny McPherson Amber Networks 2465 Augustine Drive Santa Clara, CA 95054
Danny McPherson Amber Networks加利福尼亚州圣克拉拉奥古斯丁大道2465号，邮编95054
EMail: danny@ambernetworks.com
EMail: danny@ambernetworks.com
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编辑功能的资金目前由互联网协会提供。