Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6747 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6747 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)
IPv4标识符定位器网络协议（ILNPv4）的地址解析协议（ARP）
Abstract
摘要
This document defines an Address Resolution Protocol (ARP) extension to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group.
本文档定义了一个地址解析协议（ARP）扩展，以支持IPv4标识符定位器网络协议（ILNPv4）。ILNP是对IP的实验性、进化性增强。本文件是IRTF路由研究组的产品。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the Routing Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。本RFC代表互联网研究任务组（IRTF）路由研究组一名或多名成员的个人意见。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6747.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6747.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.
不得修改本文件，也不得创建其衍生作品，除非将其格式化为RFC出版或将其翻译为英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. ILNP Document Roadmap ......................................3
1.2. Terminology ................................................5
2. ARP Extensions for ILNPv4 .......................................5
2.1. ILNPv4 ARP Request Packet Format ...........................5
2.2. ILNPv4 ARP Reply Packet Format .............................7
2.3. Operation and Implementation of ARP for ILNPv4 .............8
3. Security Considerations .........................................9
4. IANA Considerations .............................................9
5. References .....................................................10
5.1. Normative References ......................................10
5.2. Informative References ....................................11
6. Acknowledgements ...............................................11
1. Introduction ....................................................3
1.1. ILNP Document Roadmap ......................................3
1.2. Terminology ................................................5
2. ARP Extensions for ILNPv4 .......................................5
2.1. ILNPv4 ARP Request Packet Format ...........................5
2.2. ILNPv4 ARP Reply Packet Format .............................7
2.3. Operation and Implementation of ARP for ILNPv4 .............8
3. Security Considerations .........................................9
4. IANA Considerations .............................................9
5. References .....................................................10
5.1. Normative References ......................................10
5.2. Informative References ....................................11
6. Acknowledgements ...............................................11
This document is part of the ILNP document set, which has had extensive review within the IRTF Routing RG. ILNP is one of the recommendations made by the RG Chairs. Separately, various refereed research papers on ILNP have also been published during this decade. So, the ideas contained herein have had much broader review than the IRTF Routing RG. The views in this document were considered controversial by the Routing RG, but the RG reached a consensus that the document still should be published. The Routing RG has had remarkably little consensus on anything, so virtually all Routing RG outputs are considered controversial.
本文件是ILNP文件集的一部分，已在IRTF路由RG内进行了广泛审查。ILNP是RG主席提出的建议之一。另外，在这十年中还发表了各种关于ILNP的参考研究论文。因此，本文所包含的思想比IRTF路由RG有更广泛的审查。本文件中的观点被路由RG认为是有争议的，但RG达成共识，即该文件仍应发布。路由RG在任何事情上几乎没有共识，因此几乎所有路由RG输出都被认为是有争议的。
At present, the Internet research and development community are exploring various approaches to evolving the Internet Architecture to solve a variety of issues including, but not limited to, scalability of inter-domain routing [RFC4984]. A wide range of other issues (e.g., site multihoming, node multihoming, site/subnet mobility, node mobility) are also active concerns at present. Several different classes of evolution are being considered by the Internet research and development community. One class is often called "Map and Encapsulate", where traffic would be mapped and then tunnelled through the inter-domain core of the Internet. Another class being considered is sometimes known as "Identifier/Locator Split". This document relates to a proposal that is in the latter class of evolutionary approaches.
目前，互联网研发界正在探索各种方法来改进互联网体系结构，以解决各种问题，包括但不限于域间路由的可扩展性[RFC4984]。目前，广泛的其他问题（例如，站点多主、节点多主、站点/子网移动性、节点移动性）也是人们关注的热点。互联网研发界正在考虑几种不同的进化类型。一个类通常被称为“映射和封装”，在这个类中，流量将被映射，然后通过互联网的域间核心进行隧道传输。考虑的另一类有时称为“标识符/定位器拆分”。本文件涉及后一类进化方法中的建议。
The Identifier Locator Network Protocol (ILNP) is a proposal for evolving the Internet Architecture. It differs from the current Internet Architecture primarily by deprecating the concept of an IP Address, and instead defining two new objects, each having crisp syntax and semantics. The first new object is the Locator, a topology-dependent name for a subnetwork. The other new object is the Identifier, which provides a topology-independent name for a node.
标识符定位器网络协议（ILNP）是一个用于发展互联网体系结构的建议。它与当前的Internet体系结构不同，主要是不赞成IP地址的概念，而是定义了两个新对象，每个对象都具有清晰的语法和语义。第一个新对象是定位器，它是子网络的拓扑相关名称。另一个新对象是标识符，它为节点提供与拓扑无关的名称。
This document describes extensions to ARP for use with ILNPv4.
本文档描述了用于ILNPv4的ARP扩展。
The ILNP architecture can have more than one engineering instantiation. For example, one can imagine a "clean-slate" engineering design based on the ILNP architecture. In separate documents, we describe two specific engineering instances of ILNP. The term ILNPv6 refers precisely to an instance of ILNP that
ILNP体系结构可以有多个工程实例。例如，可以想象基于ILNP体系结构的“干净板岩”工程设计。在单独的文档中，我们描述了ILNP的两个具体工程实例。术语ILNPv6正是指ILNP的一个实例
is based upon, and backwards compatible with, IPv6. The term ILNPv4 refers precisely to an instance of ILNP that is based upon, and backwards compatible with, IPv4.
基于IPv6并向后兼容IPv6。术语ILNPv4正是指基于IPv4并向后兼容IPv4的ILNP实例。
Many engineering aspects common to both ILNPv4 and ILNPv6 are described in [RFC6741]. A full engineering specification for either ILNPv6 or ILNPv4 is beyond the scope of this document.
[RFC6741]中描述了ILNPv4和ILNPv6共同的许多工程方面。ILNPv6或ILNPv4的完整工程规范超出了本文件的范围。
Readers are referred to other related ILNP documents for details not described here:
读者可参考其他相关ILNP文件，了解此处未描述的详细信息：
a) [RFC6740] is the main architectural description of ILNP, including the concept of operations.
a) [RFC6740]是ILNP的主要架构描述，包括操作概念。
b) [RFC6741] describes engineering and implementation considerations that are common to both ILNPv4 and ILNPv6.
b) [RFC6741]描述了ILNPv4和ILNPv6通用的工程和实施注意事项。
c) [RFC6742] defines additional DNS resource records that support ILNP.
c) [RFC6742]定义支持ILNP的其他DNS资源记录。
d) [RFC6743] defines a new ICMPv6 Locator Update message used by an ILNP node to inform its correspondent nodes of any changes to its set of valid Locators.
d) [RFC6743]定义一条新的ICMPv6定位器更新消息，ILNP节点使用该消息通知其对应节点其有效定位器集的任何更改。
e) [RFC6744] defines a new IPv6 Nonce Destination Option used by ILNPv6 nodes (1) to indicate to ILNP correspondent nodes (by inclusion within the initial packets of an ILNP session) that the node is operating in the ILNP mode and (2) to prevent off-path attacks against ILNP ICMP messages. This Nonce is used, for example, with all ILNP ICMPv6 Locator Update messages that are exchanged among ILNP correspondent nodes.
e) [RFC6744]定义了一个新的IPv6 Nonce Destination选项，ILNPv6节点使用该选项（1）向ILNP对应节点（通过包含在ILNP会话的初始数据包中）指示该节点正在ILNP模式下运行，（2）防止针对ILNP ICMP消息的非路径攻击。例如，此Nonce用于在ILNP对应节点之间交换的所有ILNP ICMPv6定位器更新消息。
f) [RFC6745] defines a new ICMPv4 Locator Update message used by an ILNP node to inform its correspondent nodes of any changes to its set of valid Locators.
f) [RFC6745]定义一条新的ICMPv4定位器更新消息，ILNP节点使用该消息通知其对应节点其有效定位器集的任何更改。
g) [RFC6746] defines a new IPv4 Nonce Option used by ILNPv4 nodes to carry a security nonce to prevent off-path attacks against ILNP ICMP messages and also defines a new IPv4 Identifier Option used by ILNPv4 nodes.
g) [RFC6746]定义了一个新的IPv4 Nonce选项，ILNPv4节点使用该选项携带一个安全Nonce，以防止针对ILNP ICMP消息的非路径攻击，还定义了一个新的IPv4标识符选项，ILNPv4节点使用该选项。
h) [RFC6748] describes optional engineering and deployment functions for ILNP. These are not required for the operation or use of ILNP and are provided as additional options.
h) [RFC6748]描述了ILNP的可选工程和部署功能。ILNP的操作或使用不需要这些，而是作为附加选项提供的。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
ILNP for IPv4 (ILNPv4) is merely a different instantiation of the ILNP architecture, so it retains the crisp distinction between the Locator and the Identifier. As with ILNPv6, only the Locator values are used for routing and forwarding ILNPv4 packets [RFC6740]. As with ILNP for IPv6 (ILNPv6), when ILNPv4 is used for a network-layer session, the upper-layer protocols (e.g., TCP/UDP pseudo-header checksum, IPsec Security Association) bind only to the Identifiers, never to the Locators [RFC6741].
IPv4的ILNP（ILNPv4）只是ILNP体系结构的一个不同实例，因此它保留了定位器和标识符之间的清晰区别。与ILNPv6一样，只有定位器值用于路由和转发ILNPv4数据包[RFC6740]。与IPv6的ILNP（ILNPv6）一样，当ILNPv4用于网络层会话时，上层协议（例如TCP/UDP伪报头校验和、IPsec安全关联）仅绑定到标识符，而不绑定到定位器[RFC6741]。
However, just as the packet format for IPv4 is different to IPv6, so the engineering details for ILNPv4 are different also. While ILNPv6 is carefully engineered to be fully backwards-compatible with IPv6 Neighbor Discovery, ILNPv4 relies upon an extended version of the Address Resolution Protocol (ARP) [RFC826], which is defined here. While ILNPv4 could have been engineered to avoid changes in ARP, that would have required that the ILNPv4 Locator (i.e., L32) have slightly different semantics, which was architecturally undesirable.
然而，正如IPv4的数据包格式不同于IPv6，ILNPv4的工程细节也不同。虽然ILNPv6经过精心设计，完全向后兼容IPv6邻居发现，但ILNPv4依赖于地址解析协议（ARP）[RFC826]的扩展版本，该协议在此处定义。虽然ILNPv4可以设计为避免ARP中的更改，但这需要ILNPv4定位器（即L32）具有稍微不同的语义，这在体系结构上是不可取的。
The packet formats used are direct extensions of the existing widely deployed ARP Request (OP code 1) and ARP Reply (OP code 2) packet formats. This design was chosen for practical engineering reasons (i.e., to maximise code reuse), rather than for maximum protocol design purity.
使用的数据包格式是现有广泛部署的ARP请求（操作码1）和ARP应答（操作码2）数据包格式的直接扩展。选择此设计是出于实际工程原因（即，最大限度地提高代码重用），而不是最大限度地提高协议设计纯度。
We anticipate that ILNPv6 is much more likely to be widely implemented and deployed than ILNPv4. However, having a clear definition of ILNPv4 helps demonstrate the difference between architecture and engineering, and also demonstrates that the common ILNP architecture can be instantiated in different ways with different existing network-layer protocols.
我们预计ILNPv6比ILNPv4更可能被广泛实施和部署。然而，对ILNPv4有一个清晰的定义有助于证明体系结构和工程之间的差异，也证明了通用ILNP体系结构可以用不同的现有网络层协议以不同的方式实例化。
The ILNPv4 ARP Request is an extended version of the widely deployed ARP Request (OP code 1). For experimentation purposes, the ILNPv4 ARP Request OP code uses decimal value 24. It is important to note that decimal value 24 is a pre-defined, shared-use experimental OP code for ARP [RFC5494], and is not
ILNPv4 ARP请求是广泛部署的ARP请求（操作代码1）的扩展版本。出于实验目的，ILNPv4 ARP请求操作代码使用十进制值24。需要注意的是，十进制值24是ARP[RFC5494]的预定义共享使用实验操作码，不是
uniquely assigned to ILNPv4 ARP Requests. The ILNPv4 ARP Request extension permits the Node Identifier (NID) values to be carried in the ARP message, in addition to the node's 32-bit Locator (L32) values [RFC6742].
唯一分配给ILNPv4 ARP请求。ILNPv4 ARP请求扩展允许在ARP消息中携带节点标识符（NID）值，以及节点的32位定位器（L32）值[RFC6742]。
0 7 15 23 31
+--------+--------+--------+--------+
| HT | PT |
+--------+--------+--------+--------+
| HAL | PAL | OP |
+--------+--------+--------+--------+
| S_HA (bytes 0-3) |
+--------+--------+--------+--------+
| S_HA (bytes 4-5)|S_L32 (bytes 0-1)|
+--------+--------+--------+--------+
|S_L32 (bytes 2-3)|S_NID (bytes 0-1)|
+--------+--------+--------+--------+
| S_NID (bytes 2-5) |
+--------+--------+--------+--------+
|S_NID (bytes 6-7)| T_HA (bytes 0-1)|
+--------+--------+--------+--------+
| T_HA (bytes 3-5) |
+--------+--------+--------+--------+
| T_L32 (bytes 0-3) |
+--------+--------+--------+--------+
| T_NID (bytes 0-3) |
+--------+--------+--------+--------+
| T_NID (bytes 4-7) |
+--------+--------+--------+--------+
0 7 15 23 31
+--------+--------+--------+--------+
| HT | PT |
+--------+--------+--------+--------+
| HAL | PAL | OP |
+--------+--------+--------+--------+
| S_HA (bytes 0-3) |
+--------+--------+--------+--------+
| S_HA (bytes 4-5)|S_L32 (bytes 0-1)|
+--------+--------+--------+--------+
|S_L32 (bytes 2-3)|S_NID (bytes 0-1)|
+--------+--------+--------+--------+
| S_NID (bytes 2-5) |
+--------+--------+--------+--------+
|S_NID (bytes 6-7)| T_HA (bytes 0-1)|
+--------+--------+--------+--------+
| T_HA (bytes 3-5) |
+--------+--------+--------+--------+
| T_L32 (bytes 0-3) |
+--------+--------+--------+--------+
| T_NID (bytes 0-3) |
+--------+--------+--------+--------+
| T_NID (bytes 4-7) |
+--------+--------+--------+--------+
Figure 2.1: ILNPv4 ARP Request packet format
图2.1:ILNPv4 ARP请求数据包格式
In Figure 2.1, the fields are as follows:
在图2.1中，字段如下所示：
HT Hardware Type (*) PT Protocol Type (*) HAL Hardware Address Length (*) PAL Protocol Address Length (uses new value 12) OP Operation Code (uses experimental value OP_EXP1=24) S_HA Sender Hardware Address (*) S_L32 Sender L32 (* same as Sender IPv4 address for ARP) S_NID Sender Node Identifier (8 bytes) T_HA Target Hardware Address (*) T_L32 Target L32 (* same as Target IPv4 address for ARP) T_NID Target Node Identifier (8 bytes)
HT硬件类型（*）PT协议类型（*）HAL硬件地址长度（*）PAL协议地址长度（使用新值12）OP操作代码（使用实验值OP_EXP1=24）S_HA发送方硬件地址（*）S_L32发送方L32（*与ARP的发送方IPv4地址相同）S_NID发送方节点标识符（8字节）T_HA目标硬件地址（*）T_L32目标L32（*与ARP的目标IPv4地址相同）T_NID目标节点标识符（8字节）
The changed OP code indicates that this is ILNPv4 and not IPv4. The semantics and usage of the ILNPv4 ARP Request are identical to the existing ARP Request (OP code 2), except that the ILNPv4 ARP Request is sent only by nodes that support ILNPv4.
更改的操作代码表示这是ILNPv4，而不是IPv4。ILNPv4 ARP请求的语义和用法与现有ARP请求（操作代码2）相同，只是ILNPv4 ARP请求仅由支持ILNPv4的节点发送。
The field descriptions marked with "*" should have the same values as for ARP as used for IPv4.
标有“*”的字段说明的值应与用于IPv4的ARP的值相同。
The ILNPv4 ARP Reply is an extended version of the widely deployed ARP Reply (OP code 2). For experimentation purposes, the ILNPv4 ARP Request OP code uses decimal value 25. It is important to note that decimal value 25 is a pre-defined, shared-use experimental OP code for ARP [RFC5494], and is not uniquely assigned to ILNPv4 ARP Requests. The ILNPv4 ARP Reply extension permits the Node Identifier (NID) values to be carried in the ARP message, in addition to the node's 32-bit Locator (L32) values [RFC6742].
ILNPv4 ARP应答是广泛部署的ARP应答（操作代码2）的扩展版本。出于实验目的，ILNPv4 ARP请求操作代码使用十进制值25。需要注意的是，十进制值25是ARP[RFC5494]的预定义共享使用实验操作码，并不是唯一分配给ILNPv4 ARP请求的。ILNPv4 ARP应答扩展允许在ARP消息中携带节点标识符（NID）值，以及节点的32位定位器（L32）值[RFC6742]。
0 7 15 23 31
+--------+--------+--------+--------+
| HT | PT |
+--------+--------+--------+--------+
| HAL | PAL | OP |
+--------+--------+--------+--------+
| S_HA (bytes 0-3) |
+--------+--------+--------+--------+
| S_HA (bytes 4-5)|S_L32 (bytes 0-1)|
+--------+--------+--------+--------+
|S_L32 (bytes 2-3)|S_NID (bytes 0-1)|
+--------+--------+--------+--------+
| S_NID (bytes 2-5) |
+--------+--------+--------+--------+
|S_NID (bytes 6-7)| T_HA (bytes 0-1)|
+--------+--------+--------+--------+
| T_HA (bytes 3-5) |
+--------+--------+--------+--------+
| T_L32 (bytes 0-3) |
+--------+--------+--------+--------+
| T_NID (bytes 0-3) |
+--------+--------+--------+--------+
| T_NID (bytes 4-7) |
+--------+--------+--------+--------+
0 7 15 23 31
+--------+--------+--------+--------+
| HT | PT |
+--------+--------+--------+--------+
| HAL | PAL | OP |
+--------+--------+--------+--------+
| S_HA (bytes 0-3) |
+--------+--------+--------+--------+
| S_HA (bytes 4-5)|S_L32 (bytes 0-1)|
+--------+--------+--------+--------+
|S_L32 (bytes 2-3)|S_NID (bytes 0-1)|
+--------+--------+--------+--------+
| S_NID (bytes 2-5) |
+--------+--------+--------+--------+
|S_NID (bytes 6-7)| T_HA (bytes 0-1)|
+--------+--------+--------+--------+
| T_HA (bytes 3-5) |
+--------+--------+--------+--------+
| T_L32 (bytes 0-3) |
+--------+--------+--------+--------+
| T_NID (bytes 0-3) |
+--------+--------+--------+--------+
| T_NID (bytes 4-7) |
+--------+--------+--------+--------+
Figure 2.2: ILNPv4 ARP Reply packet format
图2.2:ILNPv4 ARP应答包格式
In Figure 2.2, the fields are as follows:
在图2.2中，字段如下所示：
HT Hardware Type (*) PT Protocol Type (*) HAL Hardware Address Length (*) PAL Protocol Address Length (uses new value 12) OP Operation Code (uses experimental value OP_EXP2=25) S_HA Sender Hardware Address (*) S_L32 Sender L32 (* same as Sender IPv4 address for ARP) S_NID Sender Node Identifier (8 bytes) T_HA Target Hardware Address (*) T_L32 Target L32 (* same as Target IPv4 address for ARP) T_NID Target Node Identifier (8 bytes)
HT硬件类型（*）PT协议类型（*）HAL硬件地址长度（*）PAL协议地址长度（使用新值12）OP操作代码（使用实验值OP_EXP2=25）S_HA发送方硬件地址（*）S_L32发送方L32（*与ARP的发送方IPv4地址相同）S_NID发送方节点标识符（8字节）T_HA目标硬件地址（*）T_L32目标L32（*与ARP的目标IPv4地址相同）T_NID目标节点标识符（8字节）
The changed OP code indicates that this is ILNPv4 and not IPv4. The semantics and usage of the ILNPv4 ARP Reply are identical to the existing ARP Reply (OP code 2), except that the ILNPv4 ARP Reply is sent only by nodes that support ILNPv4.
更改的操作代码表示这是ILNPv4，而不是IPv4。ILNPv4 ARP应答的语义和用法与现有ARP应答（操作代码2）相同，只是ILNPv4 ARP应答仅由支持ILNPv4的节点发送。
The field descriptions marked with "*" should have the same values as for ARP as used for IPv4.
标有“*”的字段说明的值应与用于IPv4的ARP的值相同。
The operation of ARP for ILNPv4 is almost identical to that for IPv4. Essentially, the key differences are:
ILNPv4的ARP操作与IPv4几乎相同。本质上，主要区别在于：
a) where an IPv4 ARP Request would use IPv4 addresses, an ILNPv4 ARP Request MUST use: 1. a 32-bit L32 value (_L32 suffixes in Figures 2.1 and 2.2) 2. a 64-bit NID value (_NID suffixes in Figures 2.1 and 2.2)
a) 如果IPv4 ARP请求将使用IPv4地址，则ILNPv4 ARP请求必须使用：1。32位L32值（图2.1和图2.2中的_L32后缀）2。64位NID值（图2.1和图2.2中的\u NID后缀）
b) where an IPv4 ARP Reply would use IPv4 addresses, an ILNPv4 ARP Reply MUST use: 1. a 32-bit L32 value (_L32 suffixes in Figures 2.1 and 2.2) 2. a 64-bit NID value (_NID suffixes in Figures 2.1 and 2.2)
b) 如果IPv4 ARP应答将使用IPv4地址，则ILNPv4 ARP应答必须使用：1。32位L32值（图2.1和图2.2中的_L32后缀）2。64位NID值（图2.1和图2.2中的\u NID后缀）
As the OP codes 24 and 25 are distinct from ARP for IPv4, but the packet formats in Figures 2.1 and 2.2 are, effectively, extended versions of the corresponding ARP packets. It should be possible to implement this extension of ARP by extending existing ARP implementations rather than having to write an entirely new implementation for ILNPv4. It should be emphasised, however, that OP codes 24 and 25 are for experimental use as defined in [RFC5494], and so it is possible that other experimental protocols could be using these OP codes concurrently.
由于OP代码24和25不同于IPv4的ARP，但图2.1和2.2中的数据包格式实际上是相应ARP数据包的扩展版本。应该可以通过扩展现有的ARP实现来实现ARP的这种扩展，而不必为ILNPv4编写一个全新的实现。然而，应该强调的是，OP代码24和25是用于[RFC5494]中定义的实验用途，因此其他实验协议可能同时使用这些OP代码。
Security considerations for the overall ILNP architecture are described in [RFC6740]. Additional common security considerations applicable to ILNP are described in [RFC6741]. This section describes security considerations specific to the specific ILNPv4 topics discussed in this document.
[RFC6740]中描述了整个ILNP体系结构的安全注意事项。[RFC6741]中描述了适用于ILNP的其他常见安全注意事项。本节介绍本文档中讨论的特定ILNPv4主题的特定安全注意事项。
The existing widely deployed Address Resolution Protocol (ARP) for IPv4 is a link-layer protocol, so it is not vulnerable to off-link attackers. In this way, it is a bit different than IPv6 Neighbor Discovery (ND); IPv6 ND is a subset of the Internet Control Message Protocol (ICMP), which runs over IPv6.
现有广泛部署的IPv4地址解析协议（ARP）是一种链路层协议，因此不易受到脱离链路攻击者的攻击。这样，它与IPv6邻居发现（ND）有点不同；IPv6 ND是在IPv6上运行的Internet控制消息协议（ICMP）的子集。
However, ARP does not include any form of authentication, so current ARP deployments are vulnerable to a range of attacks from on-link nodes. For example, it is possible for one node on a link to forge an ARP packet claiming to be from another node, thereby "stealing" the other node's IPv4 address. [RFC5227] describes several of these risks and some measures that an ARP implementation can use to reduce the chance of accidental IPv4 address misconfiguration and also to detect such misconfiguration if it should occur.
但是，ARP不包括任何形式的身份验证，因此当前的ARP部署容易受到来自链路节点的一系列攻击。例如，链路上的一个节点可能伪造ARP数据包，声称来自另一个节点，从而“窃取”另一个节点的IPv4地址。[RFC5227]介绍了其中的几种风险以及ARP实现可用于减少意外IPv4地址错误配置的机会以及在发生此类错误配置时检测此类错误配置的一些措施。
This extension does not change the security risks that are inherent in using ARP.
此扩展不会改变使用ARP时固有的安全风险。
In situations where additional protection against on-link attackers is needed (for example, within high-risk operational environments), the IEEE standards for link-layer security [IEEE-802.1-AE] SHOULD be implemented and deployed.
在需要针对链路上攻击者提供额外保护的情况下（例如，在高风险操作环境中），应实施并部署IEEE链路层安全标准[IEEE-802.1-AE]。
Implementers of this specification need to understand that the two OP code values used for these 2 extensions are not uniquely assigned to ILNPv4. Other experimenters might be using the same two OP code values at the same time for different ARP-related experiments. Absent prior coordination among all users of a particular IP subnetwork, different experiments might be occurring on the same IP subnetwork. So, implementations of these two ARP extensions ought to be especially defensively coded.
本规范的实现者需要了解，用于这两个扩展的两个操作码值并不是唯一分配给ILNPv4的。其他实验者可能在同一时间使用相同的两个操作码值进行不同的ARP相关实验。如果某一特定IP子网的所有用户之间没有事先的协调，则可能会在同一IP子网上进行不同的实验。因此，这两个ARP扩展的实现应该特别进行防御性编码。
This document makes no request of IANA.
本文件未向IANA提出任何要求。
If in the future the IETF decided to standardise ILNPv4, then allocation of unique ARP OP codes for the two extensions above would be sensible as part of the IETF standardisation process.
如果未来IETF决定标准化ILNPv4，那么为上述两个扩展分配唯一的ARP操作码将是IETF标准化过程的一部分。
[IEEE-802.1-AE] IEEE, "Media Access Control (MAC) Security", IEEE Standard 802.1 AE, 18 August 2006, IEEE, New York, NY, 10016, USA.
[IEEE-802.1-AE]IEEE，“媒体访问控制（MAC）安全”，IEEE标准802.1 AE，2006年8月18日，IEEE，纽约，纽约，10016，美国。
[RFC826] Plummer, D., "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.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, July 2008.
[RFC5227]柴郡，S.，“IPv4地址冲突检测”，RFC 5227，2008年7月。
[RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines for the Address Resolution Protocol (ARP)", RFC 5494, April 2009.
[RFC5494]Arkko，J.和C.Pignataro，“地址解析协议（ARP）的IANA分配指南”，RFC 54942009年4月。
[RFC6740] Atkinson, R. and S. Bhatti, "Identifier Locator Network Protocol (ILNP) Architectural Description", RFC 6740, November 2012.
[RFC6740]Atkinson，R.和S.Bhatti，“标识符定位器网络协议（ILNP）体系结构描述”，RFC 67402012年11月。
[RFC6741] Atkinson, R. and S. Bhatti, "Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations", RFC 6741, November 2012.
[RFC6741]Atkinson，R.和S.Bhatti，“标识符定位器网络协议（ILNP）工程和实施注意事项”，RFC 67412012年11月。
[RFC6742] Atkinson, R., Bhatti, S., and S. Rose, "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)", RFC 6742, November 2012.
[RFC6742]Atkinson，R.，Bhatti，S.和S.Rose，“标识符定位器网络协议（ILNP）的DNS资源记录”，RFC 6742，2012年11月。
[RFC6745] Atkinson, R. and S. Bhatti, "ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)", RFC 6745, November 2012.
[RFC6745]Atkinson，R.和S.Bhatti，“IPv4标识符定位器网络协议（ILNPv4）的ICMP定位器更新消息”，RFC 67452012年11月。
[RFC6746] Atkinson, R. and S.Bhatti, "IPv4 Options for the Identifier-Locator Network Protocol (ILNP)", RFC 6746, November 2012.
[RFC6746]Atkinson，R.和S.Bhatti，“标识符定位器网络协议（ILNP）的IPv4选项”，RFC 67462012年11月。
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
[RFC4984]Meyer，D.，Ed.，Zhang，L.，Ed.，和K.Fall，Ed.，“IAB路由和寻址研讨会报告”，RFC 4984，2007年9月。
[RFC6743] Atkinson, R. and S. Bhatti, "ICMPv6 Locator Update Message", RFC 6743, November 2012.
[RFC6743]Atkinson，R.和S.Bhatti，“ICMPv6定位器更新消息”，RFC 67432012年11月。
[RFC6744] Atkinson, R. and S. Bhatti, "IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", RFC 6744, November 2012.
[RFC6744]Atkinson，R.和S.Bhatti，“IPv6标识符定位器网络协议（ILNPv6）的IPv6临时目的地选项”，RFC 67442012年11月。
[RFC6748] Atkinson, R. and S. Bhatti, "Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)", RFC 6748, November 2012.
[RFC6748]Atkinson，R.和S.Bhatti，“标识符定位器网络协议（ILNP）的可选高级部署场景”，RFC 6748，2012年11月。
Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, Bruce Simpson, Robin Whittle, and John Wroclawski (in alphabetical order) provided review and feedback on earlier versions of this document. Steve Blake provided an especially thorough review of an early version of the entire ILNP document set, which was extremely helpful. We also wish to thank the anonymous reviewers of the various ILNP papers for their feedback.
Steve Blake、Stephane Bortzmeyer、Mohamed Boucadair、Noel Chiappa、Wes George、Steve Hailes、Joel Halpern、Mark Handley、Volker Hilt、Paul Jakma、Dae Young Kim、Tony Li、Yakov Rehkter、Bruce Simpson、Robin Whittle和John Wroclawski（按字母顺序）对本文件的早期版本进行了审查和反馈。Steve Blake对整个ILNP文档集的早期版本进行了特别彻底的审查，这非常有帮助。我们还要感谢各种ILNP论文的匿名评审员的反馈。
Roy Arends provided expert guidance on technical and procedural aspects of DNS issues.
Roy Arends就DNS问题的技术和程序方面提供了专家指导。
Authors' Addresses
作者地址
RJ Atkinson Consultant San Jose, CA, 95125 USA
RJ阿特金森顾问公司，加利福尼亚州圣何塞，美国95125
EMail: rja.lists@gmail.com
EMail: rja.lists@gmail.com
SN Bhatti School of Computer Science University of St Andrews North Haugh, St Andrews, Fife KY16 9SX Scotland, UK
SN BaTHI计算机科学学院圣·安驻斯大学北部豪格，圣安德鲁斯，FIFE KY16 9SX苏格兰，英国
EMail: saleem@cs.st-andrews.ac.uk
EMail: saleem@cs.st-andrews.ac.uk