Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6744 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6744 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)
IPv6标识符定位器网络协议（ILNPv6）的IPv6 Nonce Destination选项
Abstract
摘要
The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations. This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of the IRTF Routing Research Group.
标识符定位网络协议（ILNP）是对IP的一种实验性、进化性增强。ILNP有多个实例化。本文档描述了一个仅与ILNP for IPv6（ILNPv6）一起使用的实验性Nonce Destination选项。本文件是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/rfc6744.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6744.
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. ILNP Document Roadmap ......................................3
1.2. Terminology ................................................5
2. Syntax ..........................................................5
3. Transport Protocol Effects ......................................6
4. Location Changes ................................................7
5. Implementation Considerations ...................................7
5.1. ILNP Communication Cache ...................................8
5.2. Mode Indicator .............................................8
5.3. IP Security ................................................8
6. Backwards Compatibility .........................................8
7. Security Considerations ........................................10
8. IANA Considerations ............................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................13
10. Acknowledgements ..............................................14
1. Introduction ....................................................2
1.1. ILNP Document Roadmap ......................................3
1.2. Terminology ................................................5
2. Syntax ..........................................................5
3. Transport Protocol Effects ......................................6
4. Location Changes ................................................7
5. Implementation Considerations ...................................7
5.1. ILNP Communication Cache ...................................8
5.2. Mode Indicator .............................................8
5.3. IP Security ................................................8
6. Backwards Compatibility .........................................8
7. Security Considerations ........................................10
8. IANA Considerations ............................................12
9. References .....................................................12
9.1. Normative References ......................................12
9.2. Informative References ....................................13
10. Acknowledgements ..............................................14
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 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]。目前，广泛的其他问题（例如，站点多主、节点多主、站点/子网移动性、节点移动性）也是人们关注的热点。互联网研发界正在考虑几种不同的进化类型。一个类通常被称为“映射和封装”，在这个类中，流量将被映射，然后通过互联网的域间核心进行隧道传输。考虑的另一类有时称为“标识符/定位器拆分”。本文件涉及后一类进化方法中的建议。
This document describes a new option for the IPv6 Destination Options header that is used with the Identifier-Locator Network Protocol for IPv6 (ILNPv6). ILNPv6 is an experimental protocol that is backwards compatible with, and incrementally upgradable from, IPv6. This option is ONLY used in ILNPv6 sessions and is never used with classic IPv6 sessions.
本文档介绍用于IPv6标识符定位器网络协议（ILNPv6）的IPv6目标选项标头的新选项。ILNPv6是一种实验性协议，它向后兼容IPv6，并可从IPv6增量升级。此选项仅在ILNPv6会话中使用，从未在经典IPv6会话中使用。
The Nonce Option for the IPv6 Destination Options Header that is described in this document provides two functions. First, it provides protection against off-path attacks for packets when ILNPv6 is in use. Second, it provides a signal during initial network-layer session creation that ILNPv6 is proposed for use with this network-layer session, rather than classic IPv6. This last function is particularly important for ensuring that ILNP is both incrementally deployable and backwards compatible with IPv6. Consequently, this option MUST NOT be used except by an ILNPv6-capable node.
本文档中描述的IPv6目标选项标头的Nonce选项提供了两个功能。首先，在使用ILNPv6时，它为数据包提供了防止路径外攻击的保护。其次，它在初始网络层会话创建期间提供了一个信号，表明ILNPv6建议用于此网络层会话，而不是传统的IPv6。最后一个功能对于确保ILNP可增量部署且与IPv6向后兼容尤为重要。因此，只有支持ILNPv6的节点才能使用此选项。
Further, each Nonce value is unidirectional. Since packets often travel asymmetric paths between two correspondents, having separate Nonces for each direction limits the number of on-path nodes that can easily learn an ILNP session's nonce. So a typical TCP session will have two different nonce values in use: one nonce is used from Local Node to the Correspondent Node and a different nonce is used from the Correspondent Node to the Local Node.
此外，每个Nonce值都是单向的。由于数据包通常在两个对应方之间的非对称路径上传输，因此每个方向具有单独的nonce限制了可以轻松学习ILNP会话nonce的路径上节点的数量。因此，典型的TCP会话将使用两个不同的nonce值：从本地节点到对应节点使用一个nonce，从对应节点到本地节点使用一个不同的nonce。
This document 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.
本文档定义了ILNPv6节点使用的新IPv6 Nonce Destination选项（1）用于向ILNP对应节点（通过包含在ILNP会话的初始数据包中）指示该节点正在ILNP模式下运行，以及（2）防止针对ILNP ICMP消息的非路径攻击。例如，此Nonce用于在ILNP对应节点之间交换的所有ILNP ICMPv6定位器更新消息。
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) [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.
e) [RFC6745]定义一条新的ICMPv4定位器更新消息，ILNP节点使用该消息通知其对应节点其有效定位器集的任何更改。
f) [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.
f) [RFC6746]定义了一个新的IPv4 Nonce选项，ILNPv4节点使用该选项携带一个安全Nonce，以防止针对ILNP ICMP消息的非路径攻击，还定义了一个新的IPv4标识符选项，ILNPv4节点使用该选项。
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]中所述进行解释。
The Nonce Option is carried within an IPv6 Destination Options header. Section 4 of [RFC2460] provides much more information on the various options and optional headers used with IPv6.
Nonce选项包含在IPv6目标选项标头中。[RFC2460]的第4节提供了有关IPv6使用的各种选项和可选标头的更多信息。
More than one option might be inside the IPv6 Destination Options Header; however, at most, one Nonce Option exists in a given IPv6 packet.
IPv6目标选项标头中可能有多个选项；但是，在给定的IPv6数据包中最多存在一个Nonce选项。
A system that receives a packet containing more than one Nonce Option SHOULD discard the packet as "Authentication Failed" (instead of passing the packet up to the appropriate transport-layer protocol or to ICMP) and SHOULD log the event, including the Source Locator, Source Identifier, Destination Locator, Destination Identifier, upper-layer protocol (e.g., OSPF, TCP, UDP) if any, and transport-layer port numbers (if any), as a security fault in accordance with local logging policies.
接收到包含多个Nonce选项的数据包的系统应将该数据包丢弃为“身份验证失败”（而不是将该数据包传递给适当的传输层协议或ICMP），并应记录事件，包括源定位器、源标识符、目的地定位器、目的地标识符、，根据本地日志策略，上层协议（例如OSPF、TCP、UDP）和传输层端口号（如果有）作为安全故障。
As of this writing, IPv6 Destination Options headers, and the options carried by such headers, are extremely uncommon in the deployed Internet. So, it is expected that this Nonce Option commonly would be the only IPv6 Destination Option present in a given IPv6 packet. If a Common Architecture Label IPv6 Security Option (CALIPSO) label option [RFC5570] is also present in the same IPv6 Destination Options header, the CALIPSO Option SHOULD precede the Nonce Option. The Nonce Option SHOULD precede other possible options in the same IPv6 Destination Options header.
在撰写本文时，IPv6目标选项标头以及此类标头携带的选项在部署的Internet中极为罕见。因此，预计此Nonce选项通常是给定IPv6数据包中唯一的IPv6目标选项。如果公共体系结构标签IPv6安全选项（CALIPSO）标签选项[RFC5570]也存在于同一IPv6目标选项标头中，则CALIPSO选项应位于Nonce选项之前。Nonce选项应位于同一IPv6目标选项标头中的其他可能选项之前。
In the diagram below, we show not only the Nonce Option but also the IPv6 Destination Options header that carries the Nonce Option.
在下图中，我们不仅显示了Nonce选项，还显示了携带Nonce选项的IPv6目标选项标头。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Nonce Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Nonce Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header: 8-bit selector. Identifies the type of header immediately following the Destination Options header. This field uses the same values as the IPv4 Protocol field, as described in [RFC2460].
下一个标题：8位选择器。标识紧跟在目标选项标头之后的标头类型。此字段使用与IPv4协议字段相同的值，如[RFC2460]中所述。
Hdr Ext Len: 8-bit unsigned integer. Length of the Destination Options header in 8-octet units, not including the first 8 octets.
Hdr Ext Len:8位无符号整数。目标选项标头的长度，以8个八位字节为单位，不包括前8个八位字节。
Option Type: This contains the value 0x8B (139). This is the first octet of the Nonce Option itself.
选项类型：包含值0x8B（139）。这是Nonce选项本身的第一个八位组。
Option Length: This indicates the length in 8-bit octets of the Nonce Value field of the Nonce Option. This value must be selected so that the enveloping IPv6 Destination Option complies with the IPv6 header alignment rules. Common values are 4 (when the Nonce Value is 32 bits) and 12 (when the Nonce value is 96 bits).
选项长度：这表示Nonce选项的Nonce值字段的长度（以8位八位字节为单位）。必须选择此值，以便包络IPv6目标选项符合IPv6标头对齐规则。公共值为4（当Nonce值为32位时）和12（当Nonce值为96位时）。
Nonce Value: An unpredictable cryptographically random value [RFC4086] used to prevent off-path attacks on an ILNP session. This field has variable length, with the length indicated by the Option Length field preceding it. Note that the overall IPv6 IPv6 Destination Option MUST comply with IPv6 header alignment rules. Implementations MUST support sending and receiving 32-bit and 96-bit Nonce values.
Nonce值：一个不可预测的加密随机值[RFC4086]，用于防止ILNP会话上的非路径攻击。此字段具有可变长度，长度由其前面的选项长度字段指示。请注意，整个IPv6目标选项必须符合IPv6标头对齐规则。实现必须支持发送和接收32位和96位Nonce值。
When the initial packet(s) of an IPv6 session contain this Nonce Destination Option, ILNPv6 is in use for that network-layer session. (NOTE: Backwards compatibility and incremental deployment are discussed in more detail in Section 6 below.)
当IPv6会话的初始数据包包含此Nonce Destination选项时，ILNPv6将用于该网络层会话。（注意：向后兼容性和增量部署将在下面的第6节中详细讨论。）
When a network-layer session is using ILNPv6, the transport-layer pseudo-header calculations MUST set to zero the high-order 64-bits ("Locator" or "Routing Prefix") of each IPv6 address. This has the effect that the transport-layer is no longer aware of the topological network location of either node in that transport-layer session.
当网络层会话使用ILNPv6时，传输层伪报头计算必须将每个IPv6地址的高阶64位（“定位器”或“路由前缀”）设置为零。这会导致传输层不再知道该传输层会话中任一节点的拓扑网络位置。
The preceding rule applies not only to unicast ILNPv6 sessions but also to multicast or anycast ILNPv6 sessions.
上述规则不仅适用于单播ILNPv6会话，还适用于多播或任意播ILNPv6会话。
When a node has a change in its Locator set that causes all previously valid Locators to become invalid, the node MUST send an ICMP Locator Update message (containing the Nonce Option with the appropriate nonce value) to each of its correspondents [RFC6740] [RFC6743].
当节点的定位器集发生更改，导致所有以前有效的定位器无效时，该节点必须向其每个对应方发送ICMP定位器更新消息（包含具有适当Nonce值的Nonce选项）[RFC6740][RFC6743]。
In the deployed Internet, packets sometimes arrive at a destination out of order. A receiving node MUST drop a packet arriving from a correspondent if the Source Locator of the received packet is not in the receiving node's Identifier-Locator Communication Cache's (ILCC's) Set of Correspondent Locators UNLESS that packet contains a Nonce Option with the appropriate nonce value for that Source Identifier and Destination Identifier pair. This is done to reduce the risk of ILNP session hijacking or ILNP session interference attacks.
在部署的Internet中，数据包有时会无序到达目的地。如果接收到的数据包的源定位器不在接收节点的标识符定位器通信缓存（ILCC）中，则接收节点必须丢弃来自通信方的数据包一组对应的定位器，除非该数据包包含具有该源标识符和目标标识符对的适当Nonce值的Nonce选项。这样做是为了降低ILNP会话劫持或ILNP会话干扰攻击的风险。
Hence, the node that has had all previously valid Locators become invalid MUST include the Nonce Option with the appropriate nonce value in all packets (data or otherwise) to all correspondents for at least three round-trip times (RTTs) for each correspondent. (N.B. An implementation need not actually calculate RTT values; it could just use a fixed timer with a time long enough to cover the longest RTT path, such as 1 minute.) This "gratuitous authentication" ensures that the correspondent can authenticate any received packet, even if the ICMP Locator Update control message arrives and is processed AFTER some other packet using the new Source Locator(s). If an ILNP session is using IPsec, then, of course, IPsec SHOULD continue to be used even if one or more participating nodes change location. Because IP Security for ILNP [RFC6741] binds only to the Identifiers, and not to the Locators in the packet, changes in Locator value have no impact on IP Security for ILNP sessions.
因此，使所有先前有效的定位器变为无效的节点必须在所有对应方的所有分组（数据或其他）中包括具有适当的Nonce值的Nonce选项，每个对应方至少有三个往返时间（rtt）。（注意，一个实现不需要实际计算RTT值；它可以使用一个固定的计时器，其时间足以覆盖最长的RTT路径，例如1分钟。）这种“免费身份验证”确保通信方可以对任何接收到的数据包进行身份验证，即使ICMP定位器更新控制消息到达并在使用新的源定位器的其他数据包之后处理。如果ILNP会话正在使用IPsec，那么，当然，即使一个或多个参与节点更改了位置，IPsec也应该继续使用。由于ILNP[RFC6741]的IP安全性仅绑定到标识符，而不绑定到数据包中的定位器，因此定位器值的更改不会影响ILNP会话的IP安全性。
As mobility and multihoming are functionally equivalent for ILNP, this section applies equally to either situation and also to any other situation in which a node's set of Locators might change over time.
由于移动性和多宿在功能上等同于ILNP，因此本节同样适用于任一情况，也适用于节点定位器集可能随时间变化的任何其他情况。
Implementers may use any internal implementation they wish, PROVIDED that the externally visible behaviour is the same as this implementation approach.
只要外部可见的行为与此实现方法相同，实现者可以使用他们希望的任何内部实现。
As described in [RFC6741], ILNP nodes maintain an Identifier-Locator Communication Cache (ILCC) that contains several variables for each correspondent. The ILNP Nonce value is an important part of that cache.
如[RFC6741]所述，ILNP节点维护一个标识符定位器通信缓存（ILCC），该缓存包含每个通信对象的多个变量。ILNP Nonce值是该缓存的一个重要部分。
To support ILNP, and to retain needed incremental deployability and backwards compatibility, the network layer needs a (logical) mode bit in the Transport Control Block (or equivalent for one's implementation) to track which IP sessions are using traditional IPv6 and which IP sessions are using ILNPv6.
为了支持ILNP，并保持所需的增量部署能力和向后兼容性，网络层需要传输控制块中的（逻辑）模式位（或用于实现的等效位），以跟踪哪些IP会话使用传统IPv6，哪些IP会话使用ILNPv6。
If a given transport-layer session is using ILNP, then an entry corresponding to the network-layer components of that transport-layer session also will exist in the ILNP Communication Cache. Multiple transport-layer sessions between a given pair of nodes normally share a single entry in the ILNP Communication Cache, provided their network-layer details (e.g., Identifiers, Nonces) are identical. Because two different ILNP nodes at two different locations might share the same Identifier value, it is important for an ILNP implementation to use the ILNP Nonce values to distinguish between different ILNP nodes that happen to be using the same (or some of the same) Identifier value(s).
如果给定的传输层会话正在使用ILNP，则与该传输层会话的网络层组件相对应的条目也将存在于ILNP通信缓存中。给定一对节点之间的多个传输层会话通常共享ILNP通信缓存中的一个条目，前提是它们的网络层详细信息（例如标识符、nonce）相同。由于位于两个不同位置的两个不同ILNP节点可能共享相同的标识符值，因此ILNP实现必须使用ILNP Nonce值来区分恰好使用相同（或某些相同）标识符值的不同ILNP节点。
Whether or not ILNP is in use, the IPsec subsystem MUST maintain an IPsec Security Association Database (SAD) and MUST maintain information about which IPsec Selectors apply to traffic received by or sent from the local node [RFC4301]. By combining the information in the IPsec SAD, of what IPsec Selectors apply, and the information in the ILCC, an implementation has sufficient knowledge to apply IPsec properly to both received and transmitted packets.
无论ILNP是否在使用中，IPsec子系统都必须维护IPsec安全关联数据库（SAD），并且必须维护有关哪些IPsec选择器应用于本地节点接收或发送的流量的信息[RFC4301]。通过组合IPsec SAD中的信息、IPsec选择器应用的内容以及ILCC中的信息，实现具有足够的知识将IPsec正确应用于接收和传输的数据包。
This option MUST NOT be present in an IPv6 packet unless the packet is part of an ILNPv6 session. As is explained below in more detail, the presence or absence of this option from the initial packets of a new IPv6 session is an important indication of whether the session is using classic IPv6 or ILNPv6.
此选项不得出现在IPv6数据包中，除非该数据包是ILNPv6会话的一部分。如下文更详细解释的，新IPv6会话的初始数据包中是否存在此选项是会话使用经典IPv6还是ILNPv6的重要指示。
ILNPv6 nodes MUST include this option in the first few packets of each ILNPv6 session, MUST include this option in all ICMP messages generated by endpoints participating in an ILNPv6 session, and MAY
ILNPv6节点必须在每个ILNPv6会话的前几个数据包中包含此选项，必须在参与ILNPv6会话的端点生成的所有ICMP消息中包含此选项，并且可以
include this option in any and all packets of an ILNPv6 session. It is recommended that this option be included in all packets of the ILNPv6 session if the packet loss for that session is known to be much higher than normal.
在ILNPv6会话的任何和所有数据包中包括此选项。如果已知ILNPv6会话的数据包丢失比正常情况高得多，建议将此选项包括在该会话的所有数据包中。
If a node supports ILNP and the node wishes to be able to receive incoming new ILNP sessions, then that node's FQDN SHOULD have one or more Node Identifier (NID) records and also one or more Locator (e.g., L64 or LP) records associated with it in the DNS [RFC6742].
如果一个节点支持ILNP，并且该节点希望能够接收传入的新ILNP会话，那么该节点的FQDN应该具有一个或多个节点标识符（NID）记录以及一个或多个与DNS中的它相关联的定位器（例如L64或LP）记录[RFC6742]。
When a host ("initiator") initiates a new IP session with a correspondent ("responder"), it normally will perform a DNS lookup to determine the address(es) of the responder. A host that has been enhanced to support the Identifier/Locator Split operating mode SHOULD look for Node Identifier ("NID") and Locator ("L64") records in any received DNS replies. DNS servers that support Identifier and Locator (i.e., L64 or LP) records might include them (when they exist) as additional data in all DNS replies to DNS queries for DNS A or AAAA records associated with a specified DNS FQDN.
当主机（“启动器”）与对应方（“响应方”）启动新的IP会话时，它通常会执行DNS查找以确定响应方的地址。已增强以支持标识符/定位器拆分操作模式的主机应在任何接收到的DNS应答中查找节点标识符（“NID”）和定位器（“L64”）记录。支持标识符和定位器（即L64或LP）记录的DNS服务器可能将它们（当它们存在时）作为附加数据包含在对与指定DNS FQDN关联的DNS A或AAAA记录的DNS查询的所有DNS答复中。
If the initiator supports ILNP, and from DNS data learns that the responder also supports ILNP, then the initiator SHOULD attempt to use ILNP for new sessions with that responder. In such cases, the initiator MUST generate an unpredictable, cryptographically random, ILNP Nonce value, MUST store that ILNP Nonce value in the local ILCC, and MUST include the ILNP Nonce Destination Option in its initial packet(s) to the responder. The IETF has provided advice on generating cryptographically random numbers, such as this nonce value [RFC4086].
如果发起方支持ILNP，并且从DNS数据得知响应方也支持ILNP，则发起方应尝试将ILNP用于与该响应方的新会话。在这种情况下，发起方必须生成不可预测的、加密随机的ILNP Nonce值，必须将该ILNP Nonce值存储在本地ILCC中，并且必须在发送给响应方的初始数据包中包含ILNP Nonce Destination选项。IETF提供了关于生成加密随机数的建议，如此nonce值[RFC4086]。
If the responder supports ILNP and receives initial packet(s) containing the ILNP Nonce Destination Option, the responder will thereby learn that the initiator supports ILNP and the responder also will use ILNP for this new IP session.
如果响应者支持ILNP并接收到包含ILNP Nonce Destination选项的初始数据包，则响应者将因此了解到发起方支持ILNP，并且响应者还将使用ILNP进行此新IP会话。
If the responder supports ILNP and receives initial IP packet(s) NOT containing the Nonce Destination Option, the responder will thereby learn that the initiator does NOT support ILNP and the responder will use classic IPv6 for this new IP session.
如果响应程序支持ILNP并接收到不包含Nonce Destination选项的初始IP数据包，则响应程序将因此了解到发起程序不支持ILNP，并且响应程序将为此新IP会话使用经典IPv6。
If the responder does not support ILNP and receives initial packet(s) containing the ILNP Nonce Destination Option, the responder MUST drop the packet and MUST send an ICMP "Parameter Problem" error message back to the initiator [RFC4443]. Indeed, it is not expected that this behaviour will need to be coded into non-ILNP nodes, as this is the normal behaviour for nodes receiving unknown option headers.
如果响应者不支持ILNP并接收到包含ILNP Nonce Destination选项的初始数据包，则响应者必须丢弃该数据包，并且必须将ICMP“参数问题”错误消息发送回启动器[RFC4443]。事实上，预计不需要将此行为编码到非ILNP节点中，因为这是接收未知选项头的节点的正常行为。
If the initiator EITHER does not receive a response from the responder in a timely manner (e.g., within the applicable TCP timeout for a TCP session), and does not receive an ICMP Unreachable error message for that packet, OR receives an ICMP Parameter Problem error message for that packet, then the initiator infers that the responder is not able to support ILNP. In this case, the initiator should try again to create the new IP session, but this time use classic IPv6 and hence MUST NOT include the ILNP Nonce Destination Option.
如果发起方未及时收到响应方的响应（例如，在TCP会话的适用TCP超时内），且未收到该数据包的ICMP无法访问错误消息，或收到该数据包的ICMP参数问题错误消息，然后，发起方推断响应方无法支持ILNP。在这种情况下，发起方应再次尝试创建新的IP会话，但这次使用经典IPv6，因此不得包含ILNP Nonce Destination选项。
The ILNPv6 Nonce Destination Option is used ONLY for ILNPv6 sessions, because this option is part of the backwards compatibility and incremental-deployment approach for the Identifier-Locator Network Protocol (ILNP). This option MUST NOT be used with classic IPv6 sessions.
ILNPv6 Nonce Destination选项仅用于ILNPv6会话，因为该选项是标识符定位器网络协议（ILNP）的向后兼容性和增量部署方法的一部分。此选项不得用于经典IPv6会话。
The ILNPv6 Nonce Destination Option only seeks to provide protection against off-path attacks on an IP session. Ordinary IPv6 is vulnerable to on-path attacks unless IPsec is in use [CA-1995-01] [RFC4301]. This option exists to provide non-cryptographic protection for ILNP sessions, protection equivalent to the security of IP sessions that do NOT use IPsec.
ILNPv6 Nonce Destination选项仅旨在针对IP会话上的非路径攻击提供保护。除非使用IPsec，否则普通IPv6容易受到路径攻击[CA-1995-01][RFC4301]。此选项用于为ILNP会话提供非加密保护，保护相当于不使用IPsec的IP会话的安全性。
When ILNPv6 is in use, the ILNP Nonce Destination Option MUST be included in any ICMP control messages (e.g., ICMP Unreachable, ICMP Locator Update) sent by participants in that ILNPv6 session, even if IPsec also is in use for that ILNPv6 session. Note that certain ICMP messages, for example, a "Packet Too Big" message, might be generated by transit devices that are not aware of the ILNP Nonce in use for that ILNPv6 session; hence, they are not able to include the ILNP Nonce. Again, this is also true of classic IPv6 in the same operational situations, so this does not create a new security issue.
当ILNPv6正在使用时，ILNP Nonce Destination选项必须包含在该ILNPv6会话的参与者发送的任何ICMP控制消息（例如，ICMP不可访问、ICMP定位器更新）中，即使IPsec也在该ILNPv6会话中使用。请注意，某些ICMP消息，例如“数据包太大”消息，可能由不知道该ILNPv6会话使用的ILNP Nonce的传输设备生成；因此，它们不能包含ILNP Nonce。同样，在相同的操作情况下，经典IPv6也是如此，因此这不会产生新的安全问题。
For ILNPv6 sessions, any ICMP control messages received from a participant in that ILNPv6 session that lack a Nonce Destination Option MUST be discarded as forgeries. This security event SHOULD be logged in accordance with local security logging policies, including details of the received packet (i.e., Source Locator, Source Identifier, Destination Locator, Destination Identifier, upper-layer protocol (e.g., TCP, UDP, OSPF) if any, transport-layer port numbers if any, and the date and time the packet was received).
对于ILNPv6会话，从该ILNPv6会话中的参与者收到的任何缺少Nonce Destination选项的ICMP控制消息都必须作为伪造消息丢弃。应根据本地安全日志记录策略记录此安全事件，包括接收数据包的详细信息（即，源定位器、源标识符、目标定位器、目标标识符、上层协议（例如TCP、UDP、OSPF））如果有，传输层端口号（如果有，以及接收数据包的日期和时间）。
For ILNPv6 sessions, ICMP control messages received from a participant in that ILNPv6 session that have a Nonce Destination Option, but do NOT have the correct nonce value inside the Nonce Destination Option, MUST be discarded as forgeries. This security event SHOULD be logged as described above.
对于ILNPv6会话，从该ILNPv6会话中的参与者接收的ICMP控制消息，如果具有Nonce Destination选项，但在Nonce Destination选项中没有正确的Nonce值，则必须作为伪造消息丢弃。应如上所述记录此安全事件。
Of course, longer nonce values provide greater resistance to random guessing of the nonce value. However, ILNPv6 sessions operating in higher risk environments SHOULD also use the cryptographic authentication provided by IP Security for ILNP [RFC6741] [RFC4301]. Use of IP Security for ILNP for an ILNPv6 session does not eliminate the need for the ILNPv6 Nonce Option to be included as described here or as described in [RFC6743].
当然，较长的nonce值对随机猜测nonce值具有更大的抵抗力。但是，在高风险环境中运行的ILNPv6会话也应该使用IP Security为ILNP[RFC6741][RFC4301]提供的加密身份验证。在ILNPv6会话中使用ILNP的IP安全性并不意味着需要包括ILNPv6 Nonce选项，如本文所述或[RFC6743]中所述。
As a performance optimisation, it is suggested that when both the Nonce Option and IPsec are present in a packet and the Nonce Option has not been encrypted the Nonce Option value be checked for validity before beginning IPsec processing. This minimises the ability of an off-path attacker to force the recipient to perform expensive cryptographic computations on received control packets.
作为性能优化，建议当数据包中同时存在Nonce选项和IPsec且Nonce选项未加密时，在开始IPsec处理之前检查Nonce选项值的有效性。这最大限度地降低了非路径攻击者强制收件人对接收到的控制数据包执行昂贵的加密计算的能力。
For environments with data at differing Sensitivity Levels operating over common infrastructure (e.g., when the IPv6 CALIPSO is deployed), it is recommended that the ILNP Nonce Option be encrypted by using ESP Transport-Mode or ESP Tunnel-Mode in order to reduce the covert channel bandwidth potential created by the Nonce Option and to prevent a node at one Sensitivity Level from attacking an ILNP session at a different Sensitivity Level [RFC5570]. Further, Multi-Level Secure (MLS) systems SHOULD use different nonce values for ILNP sessions having different Sensitivity Levels [RFC5570]. Also, an MLS implementation of ILNP will also store the Sensitivity Label information associated with each ILNP session in the implementation's ILCC. When the Nonce Option and the CALIPSO Option are present in the same IPv6 Destination Options header, the CALIPSO Option SHOULD appear before the Nonce Option.
对于在公共基础设施上运行的数据具有不同敏感度级别的环境（例如，部署IPv6 CALIPSO时），建议使用ESP传输模式或ESP隧道模式对ILNP Nonce选项进行加密，以减少Nonce选项产生的隐蔽信道带宽潜力，并防止一个敏感度级别的节点攻击另一个敏感度级别的ILNP会话[RFC5570]。此外，多级安全（MLS）系统应为具有不同灵敏度级别的ILNP会话使用不同的nonce值[RFC5570]。此外，ILNP的MLS实现还将在实现的ILCC中存储与每个ILNP会话相关联的灵敏度标签信息。当Nonce选项和CALIPSO选项出现在同一IPv6目标选项标头中时，CALIPSO选项应出现在Nonce选项之前。
In all cases, the ILNP Nonce Value MUST be unpredictable and cryptographically random. [RFC4086] provides concrete advice on how to generate a suitable nonce value.
在所有情况下，ILNP Nonce值都必须是不可预测的，并且是加密随机的。[RFC4086]就如何生成合适的nonce值提供了具体建议。
As this is an option within the IPv6 Destination Options header, rather than an option within the IPv6 Hop-by-Hop Option Header, the presence of this option in an IPv6 packet ought not disturb routers along the path an IP packet containing this option happens to travel. 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 attack vector on backbone routers.
由于这是IPv6目的地选项标头中的一个选项，而不是IPv6逐跳选项标头中的选项，因此IPv6数据包中存在此选项不应干扰包含此选项的IP数据包沿路径移动的路由器。此外，许多已部署的现代IP路由器（IPv4和IPv6）已明确配置为在转发未寻址到路由器本身的数据包时忽略所有IP选项，甚至包括“路由器警报”选项。报告指出，这已经做了，以排除使用IP选项作为（分布式）拒绝服务攻击向量在骨干路由器上。
As the Nonce is used in the checksum of all Authentication Header (AH) protected packets, as an implementation hint, it would seem sensible to include the Nonce value from the ILCC for that ILNP session.
由于Nonce用于所有受身份验证头（AH）保护的数据包的校验和中，因此作为实现提示，将ILCC中的Nonce值包含在该ILNP会话中似乎是明智的。
Consistent with the procedures of [RFC2780], IANA has assigned a new IPv6 Destination Option Type value of 0x8B.
与[RFC2780]的过程一致，IANA已将新的IPv6目标选项类型值指定为0x8B。
The Nonce Option MUST NOT change in transit and MUST be included in IP Authentication Header calculations.
Nonce选项在传输过程中不得更改，并且必须包含在IP身份验证标头计算中。
Further, if an end system receives an IPv6 packet containing this option, but does not recognise this option, the end system MUST discard the packet and, regardless of whether or not the received packet's Destination Address was a multicast address, send an ICMPv6 Parameter Problem, Code 2 ("Unrecognised IPv6 Option Encountered"), message to the received packet's Source IPv6 Address, pointing to the unrecognised Option Type.
此外，如果终端系统接收到包含此选项的IPv6数据包，但未识别此选项，则终端系统必须丢弃该数据包，并且无论接收到的数据包的目的地地址是否为多播地址，发送ICMPv6参数问题，代码2（“遇到未识别的IPv6选项”），消息发送到接收数据包的源IPv6地址，指向无法识别的选项类型。
[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月。
[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月。
[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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.，和M.Gupta，Ed.，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[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月。
[RFC6743] Atkinson, R. and S. Bhatti, "ICMPv6 Locator Update Message", RFC 6743, November 2012.
[RFC6743]Atkinson，R.和S.Bhatti，“ICMPv6定位器更新消息”，RFC 67432012年11月。
[CA-1995-01] US CERT, "CERT Advisory CA-1995-01 IP Spoofing Attacks and Hijacked Terminal Connections", Pittsburgh, PA, USA, 1995.
[CA-1995-01]美国证书，“证书咨询CA-1995-01 IP欺骗攻击和劫持终端连接”，美国宾夕法尼亚州匹兹堡，1995年。
[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月。
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, July 2009.
[RFC5570]StJohns，M.，Atkinson，R.，和G.Thomas，“通用架构标签IPv6安全选项（CALIPSO）”，RFC 55702009年7月。
[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 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月。
[RFC6747] Atkinson, R. and S. Bhatti, "Address Resolution Protocol (ARP) Extension for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)", RFC 6747, November 2012.
[RFC6747]Atkinson，R.和S.Bhatti，“IPv4标识符定位器网络协议（ILNPv4）的地址解析协议（ARP）扩展”，RFC 6747，2012年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计算机学院圣·安驻斯大学北HAUH，圣安德鲁斯FIFE KY16 9SX苏格兰，英国
EMail: saleem@cs.st-andrews.ac.uk
EMail: saleem@cs.st-andrews.ac.uk