Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6746 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6746 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
IPv4 Options for the Identifier-Locator Network Protocol (ILNP)
标识符定位器网络协议（ILNP）的IPv4选项
Abstract
摘要
This document defines two new IPv4 Options that are used only with 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.
本文档定义了两个新的IPv4选项，它们仅与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/rfc6746.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6746.
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 ....................................................2
1.1. Document Roadmap ...........................................3
1.2. Terminology ................................................4
2. IPv4 Options for ILNPv4 .........................................4
2.1. ILNPv4 Packet Format .......................................5
2.2. ILNP Identifier Option for IPv4 ............................7
2.3. ILNP Nonce Option for IPv4 .................................8
3. Security Considerations .........................................8
4. IANA Considerations .............................................9
5. References ......................................................9
5.1. Normative References .......................................9
5.2. Informative References ....................................10
6. Acknowledgements ...............................................11
1. Introduction ....................................................2
1.1. Document Roadmap ...........................................3
1.2. Terminology ................................................4
2. IPv4 Options for ILNPv4 .........................................4
2.1. ILNPv4 Packet Format .......................................5
2.2. ILNP Identifier Option for IPv4 ............................7
2.3. ILNP Nonce Option for IPv4 .................................8
3. Security Considerations .........................................8
4. IANA Considerations .............................................9
5. References ......................................................9
5.1. Normative References .......................................9
5.2. Informative References ....................................10
6. Acknowledgements ...............................................11
This document is part of the ILNP document set, and it 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 is 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 a new IPv4 Nonce Option used by ILNPv4 nodes to carry a security nonce to prevent off-path attacks against ILNP ICMP messages and defines a new IPv4 Identifier Option used by ILNPv4 nodes.
本文档描述了ILNPv4节点使用的新IPv4 Nonce选项，该选项用于携带安全Nonce，以防止针对ILNP ICMP消息的非路径攻击，并定义了ILNPv4节点使用的新IPv4标识符选项。
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 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.
ILNP体系结构可以有多个工程实例。例如，可以想象基于ILNP体系结构的“干净板岩”工程设计。在单独的文档中，我们描述了ILNP的两个具体工程实例。术语“ILNPv6”正是指基于IPv6并向后兼容IPv6的ILNP实例。术语“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) [RFC6747] describes extensions to Address Resolution Protocol (ARP) for use with ILNPv4.
g) [RFC6747]描述了用于ILNPv4的地址解析协议（ARP）扩展。
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 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. As with ILNPv6, only the Locator values are used for routing and forwarding ILNPv4 packets.
IPv4的ILNP（ILNPv4）只是ILNP体系结构的一个不同实例，因此它保留了定位器和标识符之间的清晰区别。与IPv6的ILNP（ILNPv6）一样，当ILNPv4用于网络层会话时，上层协议（例如TCP/UDP伪头校验和、IPsec安全关联）仅绑定到标识符，而不绑定到定位器。与ILNPv6一样，只有定位器值用于路由和转发ILNPv4数据包。
However, just as the packet format for IPv4 is different from IPv6, so the engineering details for ILNPv4 are different also. Just as ILNPv6 is carefully engineered to be backwards-compatible with IPv6, ILNPv4 is carefully engineered to be backwards-compatible with IPv4.
然而，正如IPv4的数据包格式不同于IPv6一样，ILNPv4的工程细节也不同。正如ILNPv6经过精心设计以向后兼容IPv6一样，ILNPv4经过精心设计以向后兼容IPv4。
Each of these options MUST be copied upon fragmentation. Each of these options is used for control, so uses Option Class 0.
这些选项中的每一个都必须在分段时复制。每个选项都用于控制，因此使用选项类0。
Originally, these two options were specified to use separate IP option numbers. However, only one IP Option (decimal 158) has been defined for experimental use with properties of MUST COPY and CONTROL [RFC4727]. So these two options have been reworked to share that same IP Option number (158). To distinguish between the two actual options, the unsigned 8-bit field ILNPv4_OPT inside this option is examined.
最初，这两个选项被指定为使用单独的IP选项号。然而，只有一个IP选项（十进制158）被定义用于实验用途，其属性为必须复制和控制[RFC4727]。因此，这两个选项已被修改为共享相同的IP选项编号（158）。为了区分两个实际选项，将检查此选项内的无符号8位字段ILNPv4_OPT。
It is important for implementers to understand that IP Option 158 is not uniquely allocated to ILNPv4. Other IPv4-related experiments might be using that IP Option value for different IP options having different IP Option formats.
实现者必须了解IP选项158并不是唯一分配给ILNPv4的。其他与IPv4相关的实验可能会将该IP选项值用于具有不同IP选项格式的不同IP选项。
The Source IP Address in the IPv4 header becomes the Source ILNPv4 Locator value, while the Destination IP Address of the IPv4 header becomes the Destination ILNPv4 Locator value. Of course, backwards compatibility requirements mean that ILNPv4 Locators use the same number space as IPv4 routing prefixes.
IPv4标头中的源IP地址将成为源ILNPv4定位器值，而IPv4标头的目标IP地址将成为目标ILNPv4定位器值。当然，向后兼容性要求意味着ILNPv4定位器使用与IPv4路由前缀相同的数字空间。
ILNPv4 uses the same 64-bit Identifier, with the same modified EUI-64 syntax, as ILNPv6. Because the IPv4 address fields are much smaller than the IPv6 address fields, ILNPv4 cannot carry the Identifier values in the fixed portion of the IPv4 header. The obvious two ways to carry the ILNP Identifier with ILNPv4 are either as an IPv4 Option or as an IPv6-style Extension Header placed after the IPv4 header and before the upper-layer protocol (e.g., OSPF, TCP, UDP, SCTP).
ILNPv4使用与ILNPv6相同的64位标识符，具有相同的修改过的EUI-64语法。由于IPv4地址字段比IPv6地址字段小得多，因此ILNPv4无法在IPv4报头的固定部分中携带标识符值。使用ILNPv4携带ILNP标识符的两种明显方式是作为IPv4选项或作为IPv6样式的扩展标头，放在IPv4标头之后和上层协议（例如，OSPF、TCP、UDP、SCTP）之前。
Currently deployed IPv4 routers from multiple router vendors use packet forwarding silicon that is able to parse past IPv4 Options to examine the upper-layer protocol header at wire-speed on reasonably fast (e.g., 1 Gbps or better) network interfaces. By contrast, no existing IPv4-capable packet forwarding silicon is able to parse past a new Extension Header for IPv4. Hence, for engineering reasons, ILNPv4 uses a new IPv4 Option to carry the Identifier values. Another new IPv4 Option also carries a nonce value, performing the same function for ILNPv4 as the IPv6 Nonce Destination Option [RFC6744] performs for ILNPv6.
目前部署的来自多家路由器供应商的IPv4路由器使用包转发硅，该硅能够解析过去的IPv4选项，以便在速度相当快（例如，1 Gbps或更高）的网络接口上以线速检查上层协议头。相比之下，现有的支持IPv4的包转发硅无法解析IPv4的新扩展头。因此，出于工程原因，ILNPv4使用新的IPv4选项来携带标识符值。另一个新的IPv4选项还带有一个nonce值，它对ILNPv4执行与IPv6 nonce Destination选项[RFC6744]对ILNPv6执行相同的功能。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Locator (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Locator (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OT=158 | OL=5 | 0x00 |ILNPv4_OPT=0x01|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OT=158 | OL=2 | 0x00 |ILNPv4_OPT=0x02|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| top 32 bits of nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lower 32 bits of nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Locator (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Locator (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OT=158 | OL=5 | 0x00 |ILNPv4_OPT=0x01|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OT=158 | OL=2 | 0x00 |ILNPv4_OPT=0x02|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| top 32 bits of nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lower 32 bits of nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ILNPv4 Header with ILNP ID Option and ILNP Nonce Option
图1：带有ILNP ID选项和ILNP Nonce选项的ILNPv4头
Notation for Figure 1: IHL: Internet Header Length OT: Option Type OL: Option Length
图1的符号：IHL：互联网头长度OT:选项类型OL:选项长度
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OT=158 | OL=20 | 0x00 |ILNPv4_OPT=0x01|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OT=158 | OL=20 | 0x00 |ILNPv4_OPT=0x01|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ILNP Identifier Option for IPv4
图2:IPv4的ILNP标识符选项
Notation for Figure 2: OT: Option Type OL: Option Length
图2的符号：OT:选项类型OL:选项长度
RFC 791, Page 15 specifies that the Option Length is measured in words and includes the Option Type octet, the Option Length octet, and the option data octets.
RFC 791第15页规定，选项长度以文字计量，包括选项类型八位字节、选项长度八位字节和选项数据八位字节。
The Source Identifier and Destination Identifier are unsigned 64-bit integers. [RFC6741] specifies the syntax, semantics, and generation of ILNP Identifier values. Using the same syntax and semantics for all instantiations of ILNP Identifiers simplifies specification and implementation, while also facilitating translation or transition between ILNPv4 and ILNPv6 should that be desirable in future.
源标识符和目标标识符是无符号64位整数。[RFC6741]指定ILNP标识符值的语法、语义和生成。对ILNP标识符的所有实例化使用相同的语法和语义简化了规范和实现，同时也促进了ILNPv4和ILNPv6之间的翻译或转换，这在将来是可取的。
This IP Option MUST NOT be present in an IPv4 packet unless the packet is part of an ILNPv4 session. ILNPv4 sessions MUST include this option in the first few packets of each ILNPv4 session and MAY include this option in all packets of the ILNPv4 session. It is RECOMMENDED to include this option in all packets of the ILNPv4 session if packet loss is higher than normal.
此IP选项不得出现在IPv4数据包中，除非该数据包是ILNPv4会话的一部分。ILNPv4会话必须在每个ILNPv4会话的前几个数据包中包含此选项，并且可以在ILNPv4会话的所有数据包中包含此选项。如果数据包丢失高于正常值，建议在ILNPv4会话的所有数据包中包含此选项。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OT=158 | OL=2 | 0x00 |ILNPv4_OPT=0x02|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| top 32 bits of nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lower 32 bits of nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OT=158 | OL=2 | 0x00 |ILNPv4_OPT=0x02|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| top 32 bits of nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lower 32 bits of nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ILNP Nonce Option for IPv4
图3:IPv4的ILNP Nonce选项
Notation for Figure 3: OT: Option Type OL: Option Length
图3的符号：OT:选项类型OL:选项长度
This option contains a 64-bit ILNP Nonce. As noted in [RFC6740] and [RFC6741], all ILNP Nonce values are unidirectional. This means, for example, that when TCP is in use, the underlying ILNPv4 session will have two different NONCE values: one from Initiator to Responder and another from Responder to Initiator. The ILNP Nonce is used to provide non-cryptographic protection against off-path attacks (e.g., forged ICMP messages from the remote end of a TCP session).
此选项包含64位ILNP Nonce。如[RFC6740]和[RFC6741]中所述，所有ILNP Nonce值都是单向的。这意味着，例如，当使用TCP时，底层ILNPv4会话将具有两个不同的NONCE值：一个是从发起方到响应方，另一个是从响应方到发起方。ILNP Nonce用于提供非加密保护，防止非路径攻击（例如，来自TCP会话远程端的伪造ICMP消息）。
Each NONCE value MUST be unpredictable (i.e., cryptographically random). Guidance to implementers on generating cryptographically random values is provided in [RFC4086].
每个NONCE值必须是不可预测的（即，加密随机）。[RFC4086]中提供了对实现人员生成加密随机值的指导。
This IP Option MUST NOT be present in an IPv4 packet unless the packet is part of an ILNPv4 session. ILNPv4 nodes MUST include this option in the first few packets of each ILNP session, MUST include this option in all ICMP messages generated by endpoints participating in an ILNP session, and MAY include this option in all packets of an ILNPv4 session.
此IP选项不得出现在IPv4数据包中，除非该数据包是ILNPv4会话的一部分。ILNPv4节点必须在每个ILNP会话的前几个数据包中包含此选项，必须在参与ILNP会话的端点生成的所有ICMP消息中包含此选项，并且可以在ILNPv4会话的所有数据包中包含此选项。
Security considerations for the overall ILNP Architecture are described in [RFC6740]. Additional common security considerations are described in [RFC6741]. This section describes security considerations specific to ILNPv4 topics discussed in this document.
[RFC6740]中描述了整个ILNP体系结构的安全注意事项。[RFC6741]中描述了其他常见安全注意事项。本节介绍本文档中讨论的ILNPv4主题的特定安全注意事项。
If the ILNP Nonce value is predictable, then an off-path attacker might be able to forge data or control packets. This risk also is mitigated by the existing common practice of IP Source Address filtering [RFC2827] [RFC3704].
如果ILNP Nonce值是可预测的，则非路径攻击者可能能够伪造数据或控制数据包。IP源地址过滤[RFC2827][RFC3704]的现有常见做法也减轻了此风险。
IP Security for ILNP [RFC6741] [RFC4301] provides cryptographic protection for ILNP data and control packets. The ILNP Nonce Option is required in the circumstances described in Section 3, even if IPsec is also in use. Deployments of ILNPv4 in high-threat environments SHOULD use IPsec for additional risk reduction.
ILNP的IP安全[RFC6741][RFC4301]为ILNP数据和控制数据包提供加密保护。在第3节所述的情况下，需要ILNP Nonce选项，即使IPsec也在使用中。在高威胁环境中部署ILNPv4应使用IPsec以进一步降低风险。
This option is intended to be used primarily end-to-end between a source node and a destination node. However, unlike IPv6, IPv4 does not specify a method to distinguish between options with hop-by-hop behaviour versus end-to-end behaviour.
此选项主要用于源节点和目标节点之间的端到端连接。但是，与IPv6不同，IPv4没有指定方法来区分具有逐跳行为和端到端行为的选项。
[FILTERING] provides general discussion of potential operational issues with IPv4 options, along with specific advice for handling several specific IPv4 options. Further, many deployed modern IP routers (both IPv4 and IPv6) have been explicitly configured to ignore all IP options, even including the "Router Alert" option, when forwarding packets not addressed to the router itself. Reports indicate this has been done to preclude use of IP options as a (Distributed) Denial-of-Service (D)DoS attack vector on backbone routers.
[筛选]提供有关IPv4选项潜在操作问题的一般性讨论，以及处理多个特定IPv4选项的具体建议。此外，许多已部署的现代IP路由器（IPv4和IPv6）已明确配置为在转发未寻址到路由器本身的数据包时忽略所有IP选项，甚至包括“路由器警报”选项。报告表明，这已经做了排除使用IP选项作为（分布式）拒绝服务（D）DoS攻击向量骨干路由器。
This document makes no request of IANA.
本文件未向IANA提出任何要求。
If in the future the IETF decided to standardise ILNPv4, then allocation of two unique Header Option values to ILNPv4, one for the Identifier option and one for the Nonce option, would be sensible.
如果未来IETF决定标准化ILNPv4，那么将两个唯一的头选项值分配给ILNPv4是明智的，一个用于标识符选项，另一个用于Nonce选项。
[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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727]Fenner，B.，“IPv4、IPv6、ICMPv4、ICMPv6、UDP和TCP报头中的实验值”，RFC 4727，2006年11月。
[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 67422012年11月。
[RFC6745] Atkinson, R. and S. Bhatti, "ICMP Locator Update Message for the Identifier-Locator Network Protocol Version 4 (ILNPv4)", RFC 6745, November 2012.
[RFC6745]Atkinson，R.和S.Bhatti，“标识符定位器网络协议版本4（ILNPv4）的ICMP定位器更新消息”，RFC 67452012年11月。
[RFC6747] Atkinson, R. and S. Bhatti, "Address Resolution Protocol (ARP) Extension for the Identifier-Locator Network Protocol Version 4 (ILNPv4)", RFC 6747, November 2012.
[RFC6747]Atkinson，R.和S.Bhatti，“标识符定位器网络协议版本4（ILNPv4）的地址解析协议（ARP）扩展”，RFC 67472012年11月。
[FILTERING] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations on filtering of IPv4 packets containing IPv4 options", Work in Progress, March 2012.
[过滤]Gont，F.，Atkinson，R.，和C.Pignataro，“关于过滤包含IPv4选项的IPv4数据包的建议”，正在进行的工作，2012年3月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780]Bradner，S.和V.Paxson，“互联网协议和相关报头中值的IANA分配指南”，BCP 37，RFC 2780，2000年3月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[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, "ICMP Locator Update Message for the Identifier-Locator Network Protocol Version 6 (ICMPv6)", RFC 6743, November 2012.
[RFC6743]Atkinson，R.和S.Bhatti，“标识符定位器网络协议版本6（ICMPv6）的ICMP定位器更新消息”，RFC 67432012年11月。
[RFC6744] Atkinson, R. and S. Bhatti, "IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol Version 6 (ILNPv6)", RFC 6744, November 2012.
[RFC6744]Atkinson，R.和S.Bhatti，“标识符定位器网络协议版本6（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, Scotland KY16 9SX, UK
SN BaTHI计算机科学学院圣·安驻斯大学北部豪格，圣安德鲁斯法夫，苏格兰KY16 9SX，英国
EMail: saleem@cs.st-andrews.ac.uk
EMail: saleem@cs.st-andrews.ac.uk