Network Working Group T. Bradley
Request for Comments: 2390 Avici Systems, Inc.
Obsoletes: 1293 C. Brown
Category: Standards Track Consultant
A. Malis
Ascend Communications, Inc.
September 1998
Network Working Group T. Bradley
Request for Comments: 2390 Avici Systems, Inc.
Obsoletes: 1293 C. Brown
Category: Standards Track Consultant
A. Malis
Ascend Communications, Inc.
September 1998
Inverse Address Resolution Protocol
反向地址解析协议
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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. Specifically, this applies to Frame Relay stations that may have a Data Link Connection Identifier (DLCI), the Frame Relay equivalent of a hardware address, associated with an established Permanent Virtual Circuit (PVC), but do not know the protocol address of the station on the other side of this connection. It will also apply to other networks with similar circumstances.
本备忘录描述了ARP的新增功能，允许站点请求与给定硬件地址对应的协议地址。具体地说，这适用于可能具有数据链路连接标识符（DLCI）的帧中继站，数据链路连接标识符是与已建立的永久虚拟电路（PVC）相关联的硬件地址的等效帧中继站，但不知道该连接另一侧的站的协议地址。它也将适用于其他具有类似情况的网络。
This memo replaces RFC 1293. The changes from RFC 1293 are minor changes to formalize the language, the additions of a packet diagram and an example in section 7.2, and a new security section.
本备忘录取代RFC 1293。RFC1293的变化是对语言形式化的微小变化，增加了包图和第7.2节中的示例，以及新的安全部分。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [5].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、推荐、可和可选时，应按照[5]中所述进行解释。
This document will rely heavily on Frame Relay as an example of how the Inverse Address Resolution Protocol (InARP) can be useful. It is not, however, intended that InARP be used exclusively with Frame Relay. InARP may be used in any network that provides destination hardware addresses without indicating corresponding protocol addresses.
本文档将高度依赖帧中继作为反向地址解析协议（InARP）如何发挥作用的示例。然而，不打算将InARP专用于帧中继。INRAP可用于提供目标硬件地址而不指示相应协议地址的任何网络中。
The motivation for the development of Inverse ARP is a result of the desire to make dynamic address resolution within Frame Relay both possible and efficient. Permanent virtual circuits (PVCs) and eventually switched virtual circuits (SVCs) are identified by a Data Link Connection Identifier (DLCI). These DLCIs define a single virtual connection through the wide area network (WAN) and may be thought of as the Frame Relay equivalent to a hardware address. Periodically, through the exchange of signaling messages, a network may announce a new virtual circuit with its corresponding DLCI. Unfortunately, protocol addressing is not included in the announcement. The station receiving such an indication will learn of the new connection, but will not be able to address the other side. Without a new configuration or a mechanism for discovering the protocol address of the other side, this new virtual circuit is unusable.
开发反向ARP的动机是希望在帧中继中实现动态地址解析，使之成为可能并提高效率。永久虚拟电路（PVC）和最终交换虚拟电路（SVC）由数据链路连接标识符（DLCI）标识。这些DLCI定义了通过广域网（WAN）的单个虚拟连接，可以将其视为与硬件地址等效的帧中继。通过交换信令消息，网络可以周期性地宣布一个新的虚拟电路及其相应的DLCI。不幸的是，协议寻址未包含在公告中。接收到此类指示的站点将了解新连接，但无法寻址另一端。如果没有新的配置或发现另一方协议地址的机制，这个新的虚拟电路将无法使用。
Other resolution methods were considered to solve the problems, but were rejected. Reverse ARP [4], for example, seemed like a good candidate, but the response to a request is the protocol address of the requesting station, not the station receiving the request. IP specific mechanisms were limiting since they would not allow resolution of other protocols other than IP. For this reason, the ARP protocol was expanded.
考虑采用其他解决方法来解决问题，但被拒绝。例如，反向ARP[4]似乎是一个很好的候选，但对请求的响应是请求站的协议地址，而不是接收请求的站的协议地址。特定于IP的机制受到限制，因为它们不允许解析IP以外的其他协议。由于这个原因，ARP协议被扩展。
Inverse Address Resolution Protocol (InARP) will allow a Frame Relay station to discover the protocol address of a station associated with the virtual circuit. It is more efficient than sending ARP messages on every VC for every address the system wants to resolve and it is more flexible than relying on static configuration.
反向地址解析协议（InARP）将允许帧中继站发现与虚拟电路相关的站点的协议地址。它比在每个VC上为系统想要解析的每个地址发送ARP消息更高效，也比依赖静态配置更灵活。
Inverse ARP is an extension of the existing ARP. Therefore, it has the same format as standard ARP.
反向ARP是现有ARP的扩展。因此，它的格式与标准ARP相同。
ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type ar$hln 8 bits Byte length of each hardware address (n) ar$pln 8 bits Byte length of each protocol address (m) ar$op 16 bits Operation code ar$sha nbytes source hardware address ar$spa mbytes source protocol address ar$tha nbytes target hardware address ar$tpa mbytes target protocol address
ar$hrd 16位硬件类型ar$pro 16位协议类型ar$hln每个硬件地址的8位字节长度（n）ar$pln每个协议地址的8位字节长度（m）ar$op 16位操作代码ar$sha nbytes源硬件地址ar$spa mbytes源协议地址ar$tha nbytes目标硬件地址ar$tpa mbytes目标协议地址
Possible values for hardware and protocol types are the same as those for ARP and may be found in the current Assigned Numbers RFC [2].
硬件和协议类型的可能值与ARP的值相同，可以在当前分配的编号RFC[2]中找到。
Length of the hardware and protocol address are dependent on the environment in which InARP is running. For example, if IP is running over Frame Relay, the hardware address length is either 2, 3, or 4, and the protocol address length is 4.
硬件和协议地址的长度取决于INAP运行的环境。例如，如果IP通过帧中继运行，则硬件地址长度为2、3或4，协议地址长度为4。
The operation code indicates the type of message, request or response.
操作代码表示消息、请求或响应的类型。
InARP request = 8 InARP response = 9
InARP请求=8 InARP响应=9
These values were chosen so as not to conflict with other ARP extensions.
选择这些值是为了不与其他ARP扩展冲突。
Basic InARP operates essentially the same as ARP with the exception that InARP does not broadcast requests. This is because the hardware address of the destination station is already known.
基本INAP的操作与ARP基本相同，只是INAP不广播请求。这是因为目标站的硬件地址已经已知。
When an interface supporting InARP becomes active, it should initiate the InARP protocol and format InARP requests for each active PVC for which InARP is active. To do this, a requesting station simply formats a request by inserting its source hardware, source protocol addresses and the known target hardware address. It then zero fills the target protocol address field. Finally, it will encapsulate the packet for the specific network and send it directly to the target station.
当支持InARP的接口变为活动接口时，它应启动InARP协议，并为InARP活动的每个活动PVC格式化InARP请求。为此，请求站只需通过插入其源硬件、源协议地址和已知目标硬件地址来格式化请求。然后零填充目标协议地址字段。最后，它将封装特定网络的数据包，并将其直接发送到目标站。
Upon receiving an InARP request, a station may put the requester's protocol address/hardware address mapping into its ARP cache as it would any ARP request. Unlike other ARP requests, however, the receiving station may assume that any InARP request it receives is destined for it. For every InARP request, the receiving station should format a proper response using the source addresses from the request as the target addresses of the response. If the station is unable or unwilling to reply, it ignores the request.
接收到InARP请求后，站点可以像处理任何ARP请求一样，将请求者的协议地址/硬件地址映射放入其ARP缓存。然而，与其他ARP请求不同的是，接收站可以假定它接收到的任何INAP请求都是以它为目的地的。对于每个INRAP请求，接收站应使用请求的源地址作为响应的目标地址来格式化适当的响应。如果电台无法或不愿回复，则会忽略该请求。
When the requesting station receives the InARP response, it may complete the ARP table entry and use the provided address information. Note: as with ARP, information learned via InARP may be aged or invalidated under certain circumstances.
当请求站接收到INAP响应时，它可以完成ARP表条目并使用提供的地址信息。注意：与ARP一样，在某些情况下，通过InARP学习的信息可能会老化或失效。
In the context of this discussion, a multi-addressed host will refer to a host that has multiple protocol addresses assigned to a single interface. If such a station receives an InARP request, it must choose one address with which to respond. To make such a selection, the receiving station must first look at the protocol address of the requesting station, and then respond with the protocol address corresponding to the network of the requester. For example, if the requesting station is probing for an IP address, the responding multi-addressed station should respond with an IP address which corresponds to the same subnet as the requesting station. If the station does not have an address that is appropriate for the request it should not respond. In the IP example, if the receiving station does not have an IP address assigned to the interface that is a part of the requested subnet, the receiving station would not respond.
在本讨论的上下文中，多地址主机将指具有分配给单个接口的多个协议地址的主机。如果这样的站点收到INAP请求，它必须选择一个地址来响应。要进行这样的选择，接收站必须首先查看请求站的协议地址，然后使用与请求者的网络相对应的协议地址进行响应。例如，如果请求站正在探测IP地址，则响应的多地址站应使用与请求站相同的子网对应的IP地址进行响应。如果站点没有适合请求的地址，则不应响应。在IP示例中，如果接收站没有为作为请求子网一部分的接口分配IP地址，则接收站不会响应。
A multi-addressed host should send an InARP request for each of the addresses defined for the given interface. It should be noted, however, that the receiving side may answer some or none of the requests depending on its configuration.
多地址主机应为给定接口定义的每个地址发送INAP请求。然而，应当注意，接收方可以根据其配置回答部分请求或不回答任何请求。
One case where Inverse ARP can be used is on a frame relay interface which supports signaling of DLCIs via a data link management interface. An InARP equipped station connected to such an interface will format an InARP request and address it to the new virtual circuit. If the other side supports InARP, it may return a response indicating the protocol address requested.
可以使用反向ARP的一种情况是在支持通过数据链路管理接口发送DLCI信号的帧中继接口上。连接到此类接口的配备INAP的站将格式化INAP请求，并将其发送到新的虚拟电路。如果另一方支持InARP，它可能会返回一个响应，指示请求的协议地址。
In a frame relay environment, InARP packets are encapsulated using the NLPID/SNAP format defined in [3] which indicates the ARP protocol. Specifically, the packet encapsulation will be as follows:
在帧中继环境中，INAP数据包使用[3]中定义的NLPID/SNAP格式进行封装，该格式表示ARP协议。具体地，分组封装将如下所示：
+----------+----------+
| Q.922 address |
+----------+----------+
|ctrl 0x03 | pad 00 |
+----------+----------+
|nlpid 0x80| oui 0x00 |
+----------+ +
| oui (cont) 0x00 00 |
+----------+----------+
| pid 0x08 06 |
+----------+----------+
| . |
| . |
+----------+----------+
| Q.922 address |
+----------+----------+
|ctrl 0x03 | pad 00 |
+----------+----------+
|nlpid 0x80| oui 0x00 |
+----------+ +
| oui (cont) 0x00 00 |
+----------+----------+
| pid 0x08 06 |
+----------+----------+
| . |
| . |
The format for an InARP request itself is defined by the following:
INAP请求本身的格式由以下内容定义：
ar$hrd - 0x000F the value assigned to Frame Relay
ar$pro - protocol type for which you are searching
(i.e. IP = 0x0800)
ar$hln - 2,3, or 4 byte addressing length
ar$pln - byte length of protocol address for which you
are searching (for IP = 4)
ar$op - 8; InARP request
ar$sha - Q.922 [6] address of requesting station
ar$spa - protocol address of requesting station
ar$tha - Q.922 address of newly announced virtual circuit
ar$tpa - 0; This is what is being requested
ar$hrd - 0x000F the value assigned to Frame Relay
ar$pro - protocol type for which you are searching
(i.e. IP = 0x0800)
ar$hln - 2,3, or 4 byte addressing length
ar$pln - byte length of protocol address for which you
are searching (for IP = 4)
ar$op - 8; InARP request
ar$sha - Q.922 [6] address of requesting station
ar$spa - protocol address of requesting station
ar$tha - Q.922 address of newly announced virtual circuit
ar$tpa - 0; This is what is being requested
The InARP response will be completed similarly.
InARP响应将以类似方式完成。
ar$hrd - 0x000F the value assigned to Frame Relay ar$pro - protocol type for which you are searching (i.e. IP = 0x0800) ar$hln - 2,3, or 4 byte addressing length ar$pln - byte length of protocol address for which you are searching (for IP = 4) ar$op - 9; InARP response ar$sha - Q.922 address of responding station ar$spa - protocol address requested ar$tha - Q.922 address of requesting station ar$tpa - protocol address of requesting station
ar$hrd-0x000F分配给帧中继ar$pro的值—您正在搜索的协议类型（即IP=0x0800）ar$hln-2,3或4字节寻址长度ar$pln—您正在搜索的协议地址的字节长度（对于IP=4）ar$op-9；InARP响应ar$sha-Q.922响应站地址ar$spa-协议地址请求ar$tha-Q.922请求站地址ar$tpa-协议地址请求站
Note that the Q.922 addresses specified have the C/R, FECN, BECN, and DE bits set to zero.
请注意，指定的Q.922地址将C/R、FECN、BECN和DE位设置为零。
Procedures for using InARP over a Frame Relay network are as follows:
在帧中继网络上使用INAP的步骤如下：
Because DLCIs within most Frame Relay networks have only local significance, an end station will not have a specific DLCI assigned to itself. Therefore, such a station does not have an address to put into the InARP request or response. Fortunately, the Frame Relay network does provide a method for obtaining the correct DLCIs. The solution proposed for the locally addressed Frame Relay network below will work equally well for a network where DLCIs have global significance.
由于大多数帧中继网络中的DLCI仅具有本地意义，因此终端站不会为其自身分配特定的DLCI。因此，这样的站点没有一个地址可以放入InARP请求或响应中。幸运的是，帧中继网络确实提供了一种获得正确DLCI的方法。下面针对本地寻址帧中继网络提出的解决方案同样适用于DLCI具有全球重要性的网络。
The DLCI carried within the Frame Relay header is modified as it traverses the network. When the packet arrives at its destination, the DLCI has been set to the value that, from the standpoint of the receiving station, corresponds to the sending station. For example, in figure 1 below, if station A were to send a message to station B, it would place DLCI 50 in the Frame Relay header. When station B received this message, however, the DLCI would have been modified by the network and would appear to B as DLCI 70.
帧中继报头中携带的DLCI在穿越网络时被修改。当数据包到达其目的地时，DLCI已被设置为从接收站的角度来看与发送站相对应的值。例如，在下面的图1中，如果站点A向站点B发送消息，它将把DLCI 50放在帧中继报头中。然而，当站点B收到此消息时，DLCI将被网络修改，并在B看来是DLCI 70。
~~~~~~~~~~~~~~~
( )
+-----+ ( ) +-----+
| |-50------(--------------------)---------70-| |
| A | ( ) | B |
| |-60-----(---------+ ) | |
+-----+ ( | ) +-----+
( | )
( | ) <---Frame Relay
~~~~~~~~~~~~~~~~ network
80
|
+-----+
| |
| C |
| |
+-----+
~~~~~~~~~~~~~~~
( )
+-----+ ( ) +-----+
| |-50------(--------------------)---------70-| |
| A | ( ) | B |
| |-60-----(---------+ ) | |
+-----+ ( | ) +-----+
( | )
( | ) <---Frame Relay
~~~~~~~~~~~~~~~~ network
80
|
+-----+
| |
| C |
| |
+-----+
Figure 1
图1
Lines between stations represent data link connections (DLCs). The numbers indicate the local DLCI associated with each connection.
站之间的线表示数据链路连接（DLC）。这些数字表示与每个连接关联的本地DLCI。
DLCI to Q.922 Address Table for Figure 1
图1中Q.922地址表的DLCI
DLCI (decimal) Q.922 address (hex) 50 0x0C21 60 0x0CC1 70 0x1061 80 0x1401
DLCI（十进制）Q.922地址（十六进制）50 0x0C21 60 0x0CC1 70 0x1061 80 0x1401
For authoritative description of the correlation between DLCI and Q.922 [6] addresses, the reader should consult that specification. A summary of the correlation is included here for convenience. The translation between DLCI and Q.922 address is based on a two byte address length using the Q.922 encoding format. The format is:
对于DLCI和Q.922[6]地址之间相关性的权威性描述，读者应参考该规范。为方便起见，此处提供了相关性摘要。DLCI和Q.922地址之间的转换基于使用Q.922编码格式的两字节地址长度。格式为：
8 7 6 5 4 3 2 1
+------------------------+---+--+
| DLCI (high order) |C/R|EA|
+--------------+----+----+---+--+
| DLCI (lower) |FECN|BECN|DE |EA|
+--------------+----+----+---+--+
8 7 6 5 4 3 2 1
+------------------------+---+--+
| DLCI (high order) |C/R|EA|
+--------------+----+----+---+--+
| DLCI (lower) |FECN|BECN|DE |EA|
+--------------+----+----+---+--+
For InARP, the FECN, BECN, C/R and DE bits are assumed to be 0.
对于InARP，FECN、BECN、C/R和DE比特被假定为0。
When an InARP message reaches a destination, all hardware addresses will be invalid. The address found in the frame header will, however, be correct. Though it does violate the purity of layering, Frame Relay may use the address in the header as the sender hardware address. It should also be noted that the target hardware address, in both the InARP request and response, will also be invalid. This should not cause problems since InARP does not rely on these fields and in fact, an implementation may zero fill or ignore the target hardware address field entirely.
当INAP消息到达目标时，所有硬件地址都将无效。但是，在帧头中找到的地址将是正确的。虽然它确实违反了分层的纯度，但帧中继可能会使用报头中的地址作为发送方硬件地址。还应注意，INRAP请求和响应中的目标硬件地址也将无效。这不会引起问题，因为INAP不依赖于这些字段，事实上，实现可能会完全零填充或忽略目标硬件地址字段。
Using figure 1 as an example, station A may use Inverse ARP to discover the protocol address of the station associated with its DLCI 50. The Inverse ARP request would be as follows:
以图1为例，站点A可以使用反向ARP来发现与其DLCI 50相关联的站点的协议地址。反向ARP请求如下所示：
InARP Request from A (DLCI 50) ar$op 8 (InARP request) ar$sha unknown ar$spa pA ar$tha 0x0C21 (DLCI 50) ar$tpa unknown
来自（DLCI 50）ar$op 8的INAP请求（INAP请求）ar$sha未知ar$spa pA ar$tha 0x0C21（DLCI 50）ar$tpa未知
When Station B receives this packet, it will modify the source hardware address with the Q.922 address from the Frame Relay header. This way, the InARP request from A will become:
当站点B接收到此数据包时，它将使用帧中继报头中的Q.922地址修改源硬件地址。这样，来自的InARP请求将变为：
ar$op 8 (InARP request) ar$sha 0x1061 (DLCI 70) ar$spa pA ar$tha 0x0C21 (DLCI 50) ar$tpa unknown.
ar$op 8（InARP请求）ar$sha 0x1061（DLCI 70）ar$spa pA ar$tha 0x0C21（DLCI 50）ar$tpa未知。
Station B will format an Inverse ARP response and send it to station A:
站点B将格式化反向ARP响应，并将其发送给站点A：
ar$op 9 (InARP response) ar$sha unknown ar$spa pB ar$tha 0x1061 (DLCI 70) ar$tpa pA
ar$op 9（InARP响应）ar$sha未知ar$spa pB ar$tha 0x1061（DLCI 70）ar$tpa pA
The source hardware address is unknown and when the response is received, station A will extract the address from the Frame Relay header and place it in the source hardware address field. Therefore, the response will become:
源硬件地址未知，当收到响应时，站点A将从帧中继报头提取地址，并将其放入源硬件地址字段。因此，回应将变成：
ar$op 9 (InARP response) ar$sha 0x0C21 (DLCI 50) ar$spa pB ar$tha 0x1061 (DLCI 70) ar$tpa pA
ar$op 9（InARP响应）ar$sha 0x0C21（DLCI 50）ar$spa pB ar$tha 0x1061（DLCI 70）ar$tpa pA
This means that the Frame Relay interface must only intervene in the processing of incoming packets.
这意味着帧中继接口必须只干预传入数据包的处理。
Also, see [3] for a description of similar procedures for using ARP [1] and RARP [4] with Frame Relay.
此外，请参见[3]了解使用ARP[1]和RARP[4]与帧中继的类似过程的说明。
This document specifies a functional enhancement to the ARP family of protocols, and is subject to the same security constraints that affect ARP and similar address resolution protocols. Because authentication is not a part of ARP, there are known security issues relating to its use (e.g., host impersonation). No additional security mechanisms have been added to the ARP family of protocols by this document.
本文档规定了对ARP协议系列的功能增强，并受影响ARP和类似地址解析协议的相同安全约束的约束。由于身份验证不是ARP的一部分，因此存在与其使用相关的已知安全问题（例如，主机模拟）。本文件未向ARP协议系列中添加其他安全机制。
[1] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[1] Plummer，D.，“以太网地址解析协议-或-将网络协议地址转换为48位以太网地址以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.html
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994. See also: http://www.iana.org/numbers.html
[3] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 1490, July 1993.
[3] Bradley，T.，Brown，C.和A.Malis，“帧中继上的多协议互连”，RFC 1490，1993年7月。
[4] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984.
[4] Finlayson，R.，Mann，R.，Mogul，J.，和M.Theimer，“反向地址解析协议”，STD 38，RFC 903，1984年6月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Information technology - Telecommunications and Information Exchange between systems - Protocol Identification in the Network Layer, ISO/IEC TR 9577: 1992.
[6] 信息技术.系统间远程通信和信息交换.网络层协议识别，ISO/IEC TR 9577:1992。
Terry Bradley Avici Systems, Inc. 12 Elizabeth Drive Chelmsford, MA 01824
Terry Bradley Avici Systems，Inc.马萨诸塞州切姆斯福德伊丽莎白大道12号01824
Phone: (978) 250-3344 EMail: tbradley@avici.com
电话：（978）250-3344电子邮件：tbradley@avici.com
Caralyn Brown Consultant
卡拉林·布朗顾问
EMail: cbrown@juno.com
EMail: cbrown@juno.com
Andrew Malis Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886
马萨诸塞州韦斯特福德罗宾斯路1号安德鲁·马利斯·阿森德通信公司，邮编01886
Phone: (978) 952-7414 EMail: malis@ascend.com
电话：（978）952-7414电子邮件：malis@ascend.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。