Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6741 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6741 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
Identifier-Locator Network Protocol (ILNP) Engineering Considerations
标识符定位器网络协议（ILNP）工程注意事项
Abstract
摘要
This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group.
本文档描述了标识符定位器网络协议（ILNP）的通用（即独立于版本）工程细节，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/rfc6741.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6741.
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. Document Roadmap ...........................................4
1.2. Terminology ................................................5
2. ILNP Identifiers ................................................5
2.1. Syntax .....................................................6
2.2. Default Values for an Identifier ...........................6
2.3. Local-Scoped Identifier Values .............................6
2.4. Multicast Identifiers ......................................7
2.5. Administration of Identifier Values ........................7
3. Encoding of Identifiers and Locators for ILNPv6 .................7
3.1. Encoding of I and L Values .................................7
3.2. Network-Level Packet Formats ..............................10
3.3. Encoding of Identifiers and Locators for ILNPv4 ...........11
4. Transport-Layer Changes ........................................12
4.1. End-System State ..........................................12
4.2. TCP/UDP Checksum Handling .................................12
4.3. ICMP Checksum Handling ....................................12
5. ILNP Communication Cache (ILCC) ................................13
5.1. Formal Definition .........................................13
5.2. Ageing ILCC Entries .......................................15
5.3. Large Numbers of Locators .................................15
5.4. Lookups into the ILCC .....................................16
6. Handling Location/Connectivity Changes .........................16
6.1. Node Location/Connectivity Changes ........................16
6.2. Network Connectivity/Locator Changes ......................17
7. Subnetting .....................................................17
7.1. Subnetting for ILNPv6 .....................................18
7.2. Subnetting for ILNPv4 .....................................19
7.3. Subnetting for Router-Router Links in IPv6/ILNPv6 .........19
8. DNS Considerations .............................................19
1. Introduction ....................................................3
1.1. Document Roadmap ...........................................4
1.2. Terminology ................................................5
2. ILNP Identifiers ................................................5
2.1. Syntax .....................................................6
2.2. Default Values for an Identifier ...........................6
2.3. Local-Scoped Identifier Values .............................6
2.4. Multicast Identifiers ......................................7
2.5. Administration of Identifier Values ........................7
3. Encoding of Identifiers and Locators for ILNPv6 .................7
3.1. Encoding of I and L Values .................................7
3.2. Network-Level Packet Formats ..............................10
3.3. Encoding of Identifiers and Locators for ILNPv4 ...........11
4. Transport-Layer Changes ........................................12
4.1. End-System State ..........................................12
4.2. TCP/UDP Checksum Handling .................................12
4.3. ICMP Checksum Handling ....................................12
5. ILNP Communication Cache (ILCC) ................................13
5.1. Formal Definition .........................................13
5.2. Ageing ILCC Entries .......................................15
5.3. Large Numbers of Locators .................................15
5.4. Lookups into the ILCC .....................................16
6. Handling Location/Connectivity Changes .........................16
6.1. Node Location/Connectivity Changes ........................16
6.2. Network Connectivity/Locator Changes ......................17
7. Subnetting .....................................................17
7.1. Subnetting for ILNPv6 .....................................18
7.2. Subnetting for ILNPv4 .....................................19
7.3. Subnetting for Router-Router Links in IPv6/ILNPv6 .........19
8. DNS Considerations .............................................19
8.1. Secure Dynamic DNS Update .................................19
8.2. New DNS RR Types ..........................................20
8.4. DNS TTL Values for ILNP RRS Types .........................21
8.5. IP/ILNP Dual Operation and Transition .....................21
9. IP Security for ILNP ...........................................22
9.1. IPsec Security Association Enhancements for ILNP ..........22
9.2. IP Authentication Header Enhancements for ILNP ............23
9.3. Key Management Considerations .............................23
10. Backwards Compatibility and Incremental Deployment ............24
10.1. Priorities in the Design of ILNPv6 and ILNPv4 ............24
10.2. Infrastructure ...........................................25
10.3. Core Protocols ...........................................25
10.4. Scope of End-System Changes ..............................26
10.5. Applications .............................................27
10.6. Interworking between IP and ILNP .........................27
11. Security Considerations .......................................28
11.1. Authenticating ICMP Messages .............................29
11.2. Forged Identifier Attacks ................................31
12. Privacy Considerations ........................................31
13. Operational Considerations ....................................31
13.1. Session Liveness and Reachability ........................32
13.2. Key Management Considerations ............................33
13.3. Point-to-Point Router Links ..............................33
14. Referrals and Application Programming Interfaces ..............34
14.1. BSD Sockets APIs .........................................34
14.2. Java (and Other) APIs ....................................34
14.3. Referrals in the Future ..................................35
15. References ....................................................35
15.1. Normative References .....................................35
15.2. Informative References ...................................36
16. Acknowledgements ..............................................38
8.1. Secure Dynamic DNS Update .................................19
8.2. New DNS RR Types ..........................................20
8.4. DNS TTL Values for ILNP RRS Types .........................21
8.5. IP/ILNP Dual Operation and Transition .....................21
9. IP Security for ILNP ...........................................22
9.1. IPsec Security Association Enhancements for ILNP ..........22
9.2. IP Authentication Header Enhancements for ILNP ............23
9.3. Key Management Considerations .............................23
10. Backwards Compatibility and Incremental Deployment ............24
10.1. Priorities in the Design of ILNPv6 and ILNPv4 ............24
10.2. Infrastructure ...........................................25
10.3. Core Protocols ...........................................25
10.4. Scope of End-System Changes ..............................26
10.5. Applications .............................................27
10.6. Interworking between IP and ILNP .........................27
11. Security Considerations .......................................28
11.1. Authenticating ICMP Messages .............................29
11.2. Forged Identifier Attacks ................................31
12. Privacy Considerations ........................................31
13. Operational Considerations ....................................31
13.1. Session Liveness and Reachability ........................32
13.2. Key Management Considerations ............................33
13.3. Point-to-Point Router Links ..............................33
14. Referrals and Application Programming Interfaces ..............34
14.1. BSD Sockets APIs .........................................34
14.2. Java (and Other) APIs ....................................34
14.3. Referrals in the Future ..................................35
15. References ....................................................35
15.1. Normative References .....................................35
15.2. Informative References ...................................36
16. Acknowledgements ..............................................38
The ILNP document set 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 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内部进行了广泛审查。ILNP是RG主席提出的建议之一。另外，在这十年中还发表了各种关于ILNP的参考研究论文。因此，本文所包含的思想比IRTF有更广泛的回顾。本文件中的观点被路由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 an experimental network protocol that provides evolutionary enhancements to IP. ILNP is backwards compatible with IP and is incrementally deployable. The best starting point for learning about ILNP is the ILNP Architectural Description, which includes a document roadmap [RFC6740].
标识符定位器网络协议（ILNP）是一种实验性的网络协议，它为IP提供了进化增强。ILNP向后兼容IP，并可增量部署。学习ILNP的最佳起点是ILNP体系结构描述，其中包括文档路线图[RFC6740]。
This document describes engineering and implementation considerations that are common to both ILNP for IPv4 (ILNPv4) and ILNP for IPv6 (ILNPv6).
本文档描述了IPv4的ILNP（ILNPv4）和IPv6的ILNP（ILNPv6）的工程和实施注意事项。
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 this document. A full engineering specification for either ILNPv6 or ILNPv4 is beyond the scope of this document.
本文档描述了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) [RFC6742] defines additional DNS resource records that support ILNP.
b) [RFC6742]定义支持ILNP的其他DNS资源记录。
c) [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.
c) [RFC6743]定义一条新的ICMPv6定位器更新消息，ILNP节点使用该消息通知其对应节点其有效定位器集的任何更改。
d) [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.
d) [RFC6744]定义了一个新的IPv6 Nonce Destination选项，ILNPv6节点使用该选项（1）向ILNP对应节点（通过包含在ILNP会话的初始数据包中）指示该节点正在ILNP模式下运行，（2）防止针对ILNP ICMP消息的非路径攻击。例如，此Nonce用于在ILNP对应节点之间交换的所有ILNP ICMPv6定位器更新消息。
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]中所述进行解释。
Several technical terms (e.g., "ILNP session") that are used by this document are defined in [RFC6740]. It is strongly recommended that one read [RFC6740] before reading this document.
[RFC6740]中定义了本文件使用的几个技术术语（如“ILNP会话”）。强烈建议读者在阅读本文件之前先阅读[RFC6740]。
All ILNP nodes must have at least one Node Identifier (or just "Identifier") value. However, there are various options for generating those Identifier values. We describe, in this section, the relevant engineering issues related to Identifier generation and usage.
所有ILNP节点必须至少有一个节点标识符（或仅“标识符”）值。但是，有各种选项可用于生成这些标识符值。在本节中，我们将介绍与标识符生成和使用相关的工程问题。
Note well that an ILNP Node Identifier names an ILNP-capable node, and it is NOT bound to a specific interface of that node. So a given ILNP Node Identifier is valid on all active interfaces of the node to which that ILNP Identifier is bound. This is true even if the bits used to form the Identifier value happened to be taken from a specific interface as an engineering convenience.
请注意，ILNP节点标识符命名了一个支持ILNP的节点，并且它没有绑定到该节点的特定接口。因此，给定的ILNP节点标识符在绑定该ILNP标识符的节点的所有活动接口上都有效。即使用于形成标识符值的位恰好是为了工程方便而从特定接口获取的，这也是正确的。
ILNP Identifiers are always unsigned 64-bit strings, and they may be realised as 64-bit unsigned integers. Both ILNPv4 and ILNPv6 use the Modified EUI-64 [IEEE-EUI] syntax that is used by IPv6 interface identifiers [RFC4291], Section 2.5.1, as shown in Figure 2.1.
ILNP标识符始终是无符号64位字符串，它们可以实现为64位无符号整数。ILNPv4和ILNPv6都使用修改后的EUI-64[IEEE-EUI]语法，该语法由IPv6接口标识符[RFC4291]第2.5.1节使用，如图2.1所示。
+--------------------------------------------------+
| 6 id bits | U bit | G bit | 24 id bits |
+--------------------------------------------------+
| 32 id bits |
+--------------------------------------------------+
+--------------------------------------------------+
| 6 id bits | U bit | G bit | 24 id bits |
+--------------------------------------------------+
| 32 id bits |
+--------------------------------------------------+
Figure 2.1: Node Identifier Format as Used for IPv6, Using the Same Syntax as in RFC 4291, Section 2.5.1.
图2.1：用于IPv6的节点标识符格式，使用与RFC 4291第2.5.1节中相同的语法。
That syntax contains two special reserved bit flags. One flag (the U bit) indicates whether the value has "universal" (i.e., global) scope (1) or "local" (0) scope. The other flag (the G bit) indicates whether the value is an "individual" address (1) or "group" (i.e., multicast) (0) address.
该语法包含两个特殊的保留位标志。一个标志（U位）指示该值是具有“通用”（即全局）范围（1）还是“局部”（0）范围。另一个标志（G位）指示该值是“单个”地址（1）还是“组”（即多播）（0）地址。
However, this format does allow other values to be set, by use of administrative or other policy control, as required, by setting the U bit to "local".
但是，此格式允许根据需要通过使用管理或其他策略控制，通过将U位设置为“本地”来设置其他值。
By default, this value, including the U bit and G bit, are set as described in Section 2.5.1 of [RFC4291]. Where no other value of Identifier is available for an ILNP node, this is the value that MUST be used.
默认情况下，该值（包括U位和G位）的设置如[RFC4291]第2.5.1节所述。如果ILNP节点没有其他标识符值可用，则必须使用该值。
Because ILNP Identifiers might have local scope, and also to handle the case where two nodes at different locations happen to be using the same global scope Identifier (e.g., due to a manufacturing fault in a network chipset or card), implementers must be careful in how ILNP Identifiers are handled within an end system's networking implementation. Some details are discussed in Section 4 below.
因为ILNP标识符可能具有局部作用域，并且还用于处理位于不同位置的两个节点恰好使用相同全局作用域标识符的情况（例如，由于网络芯片组或卡中的制造故障），在终端系统的网络实现中如何处理ILNP标识符，实现者必须小心。下文第4节讨论了一些细节。
ILNP Identifiers for a node also MAY have the Scope bit of the Node Identifier set to "local" scope. Locally unique identifiers MAY be Cryptographically Generated, created following the procedures used for IPv6 Cryptographically Generated Addresses (CGAs) [RFC3972] [RFC4581] [RFC4982].
节点的ILNP标识符还可以将节点标识符的作用域位设置为“本地”作用域。本地唯一标识符可以加密生成，按照IPv6加密生成地址（CGA）[RFC3972][RFC4581][RFC4982]使用的过程创建。
Also, locally unique identifiers MAY be used to create the ILNP equivalent to the Privacy Extensions for IPv6, generating ILNP Identifiers following the procedures used for IPv6 [RFC4941].
此外，本地唯一标识符可用于创建等同于IPv6隐私扩展的ILNP，按照用于IPv6的过程生成ILNP标识符[RFC4941]。
An ILNP Identifier with the G bit set to "group" names an ILNP multicast group, while an ILNP Identifier with the G bit set to "individual" names an individual ILNP node. However, this usage of multicast for Identifiers for ILNP is currently undefined: ILNP uses IPv6 multicast for ILNPv6 and IPv4 multicast for ILNPv4 and uses the multicast address formats defined as appropriate.
G位设置为“group”的ILNP标识符命名ILNP多播组，而G位设置为“individual”的ILNP标识符命名单个ILNP节点。但是，对于ILNP标识符的这种多播用法目前尚未定义：ILNP对ILNPv6使用IPv6多播，对ILNPv4使用IPv4多播，并使用适当定义的多播地址格式。
The use of multicast Identifiers and design of an enhanced multicast capability for ILNPv6 and ILNPv4 is currently work in progress.
目前正在为ILNPv6和ILNPv4使用多播标识符和设计增强的多播功能。
Note that just as IPv6 does not need global, centralised administrative management of its interface identifiers, so ILNPv6 does not need global, centralised administrative management of the Node Identifier (NID) values.
请注意，正如IPv6不需要对其接口标识符进行全局集中管理一样，ILNPv6也不需要对节点标识符（NID）值进行全局集中管理。
With ILNPv6, the Identifier and Locator values within a packet are encoded in the existing space for the IPv6 address. In general, the ILNPv6 Locator has the same syntax and semantics as the current IPv6 unicast routing prefix, as shown in Figure 3.1:
使用ILNPv6，数据包中的标识符和定位器值在IPv6地址的现有空间中进行编码。通常，ILNPv6定位器与当前IPv6单播路由前缀具有相同的语法和语义，如图3.1所示：
/* IPv6 */
| 64 bits | 64 bits |
+-------------------------------------+-------------------------+
| IPv6 Unicast Routing Prefix | Interface Identifier |
+-------------------------------------+-------------------------+
/* IPv6 */
| 64 bits | 64 bits |
+-------------------------------------+-------------------------+
| IPv6 Unicast Routing Prefix | Interface Identifier |
+-------------------------------------+-------------------------+
/* ILNPv6 */
| 64 bits | 64 bits |
+-------------------------------------+-------------------------+
| Locator | Node Identifier (NID) |
+-------------------------------------+-------------------------+
/* ILNPv6 */
| 64 bits | 64 bits |
+-------------------------------------+-------------------------+
| Locator | Node Identifier (NID) |
+-------------------------------------+-------------------------+
Figure 3.1: The General Format of Encoding of I/NID and L Values for ILNPv6 into the IPv6 Address Bits
图3.1:ILNPv6的I/NID和L值编码为IPv6地址位的通用格式
The syntactical structure of the IPv6 address spaces remains as given in Section 2.5.4 of [RFC4291], and an example is shown in Figure 3.2, which is based in part on [RFC3177] (which has since been obsoleted by [RFC6177]).
IPv6地址空间的语法结构仍如[RFC4291]第2.5.4节所示，图3.2中显示了一个示例，该示例部分基于[RFC3177]（已被[RFC6177]淘汰）。
/* IPv6 */
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
|001|global routing prefix| subnet ID | Interface Identifier |
+---+---------------------+-----------+-------------------------+
/* IPv6 */
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
|001|global routing prefix| subnet ID | Interface Identifier |
+---+---------------------+-----------+-------------------------+
/* ILNPv6 */
| 64 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
| Locator (L64) | Node Identifier (NID) |
+---+---------------------+-----------+-------------------------+
/* ILNPv6 */
| 64 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
| Locator (L64) | Node Identifier (NID) |
+---+---------------------+-----------+-------------------------+
Figure 3.2: Example of IPv6 Address Format as Used in ILNPv6
图3.2:ILNPv6中使用的IPv6地址格式示例
The global routing prefix bits and subnet ID bits above are as for [RFC3177], but could be different, e.g., as for [RFC6177].
上述全局路由前缀位和子网ID位与[RFC3177]相同，但可能不同，例如，与[RFC6177]相同。
The ILNPv6 Locator uses the upper 64-bits of the 128-bit IPv6 address space. It has the same syntax and semantics as today's IPv6 routing prefix. So, an ILNPv6 packet carrying a Locator value can be used just like an IPv6 packet today as far as core routers are concerned.
ILNPv6定位器使用128位IPv6地址空间的高64位。它的语法和语义与今天的IPv6路由前缀相同。因此，就核心路由器而言，携带定位器值的ILNPv6数据包可以像今天的IPv6数据包一样使用。
The example in Figure 3.2 happens to use a /48 prefix, as was recommended by [RFC3177]. However, more recent advice is that prefixes need not be fixed at /48 and could be up to /64 [RFC6177]. This change, however, does not impact the syntax or semantics of the Locator value.
图3.2中的示例碰巧使用了[RFC3177]推荐的/48前缀。然而，最近的建议是，前缀不必固定在/48，可以高达/64[RFC6177]。但是，此更改不会影响定位器值的语法或语义。
The ILNPv6 Identifier value uses the lower 64-bits of the 128-bit IPv6 address. It has the same syntax as an IPv6 identifier, but different semantics. This provides a fixed-length non-topological name for a node. Identifiers are bound to nodes, not to interfaces of a node. All ILNP Identifiers MUST comply with the modified EUI-64 syntax already specified for IPv6's "interface identifier" values, as described in Section 2.1.
ILNPv6标识符值使用128位IPv6地址的低位64位。它的语法与IPv6标识符相同，但语义不同。这为节点提供了固定长度的非拓扑名称。标识符绑定到节点，而不是节点的接口。如第2.1节所述，所有ILNP标识符必须符合已为IPv6“接口标识符”值指定的修改过的EUI-64语法。
IEEE EUI-64 Identifiers can have either global-scope or local-scope. So ILNP Identifiers also can have either global-scope or local-scope. A reserved bit in the modified EUI-64 syntax clearly indicates whether a given Identifier has global-scope or local-scope. A node is not required to use a global-scope Identifier, although that is the recommended practice. Note that the syntax of the Node
IEEE EUI-64标识符可以具有全局范围或局部范围。因此，ILNP标识符也可以具有全局范围或局部范围。修改后的EUI-64语法中的保留位清楚地指示给定标识符是全局作用域还是局部作用域。节点不需要使用全局范围标识符，尽管这是推荐的做法。请注意，节点的语法
Identifier field has exactly the same syntax as that defined for IPv6 address in Section 2.5.1 of [RFC4291]. (This is based on the IEEE EUI-64 syntax [IEEE-EUI], but is not the same.)
标识符字段的语法与[RFC4291]第2.5.1节中为IPv6地址定义的语法完全相同。（这是基于IEEE EUI-64语法[IEEE-EUI]，但不同。）
Most commonly, Identifiers have global-scope and are derived from one or more IEEE 802 or IEEE 1394 'MAC Addresses' (sic) already associated with the node, following the procedure already defined for IPv6 [RFC4291]. Global-scope identifiers have a high probability of being globally unique. This approach eliminates the need to manage Identifiers, among other benefits.
最常见的情况是，标识符具有全局范围，并根据已为IPv6定义的过程[RFC4291]从已与节点关联的一个或多个IEEE 802或IEEE 1394“MAC地址”（sic）派生而来。全局范围标识符具有全局唯一性的高概率。除其他好处外，这种方法无需管理标识符。
Local-scope Identifiers MUST be unique within the context of their Locators. The existing mechanisms of the IPv4 Address Resolution Protocol [RFC826] and IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] automatically enforce this constraint.
本地范围标识符在其定位器的上下文中必须是唯一的。IPv4地址解析协议[RFC826]和IPv6无状态地址自动配置（SLAAC）[RFC4862]的现有机制会自动执行此约束。
For example, on an Ethernet-based IPv4 subnetwork the ARP Reply message is sent via link-layer broadcast, thereby advertising the current binding between an IPv4 address and a Media Access Control (MAC) address to all nodes on that IPv4 subnetwork. (Note also that a well-known, long standing, issue with ARP is that it cannot be authenticated.) Local-scope Identifiers MUST NOT be used with other Locators without first ensuring uniqueness in the context of those other Locators e.g., by using IPv6 Neighbour Discovery's Duplicate Address Detection mechanism when using ILNPv6 or by sending an ARP Request when using ILNPv4.
例如，在基于以太网的IPv4子网上，ARP回复消息通过链路层广播发送，从而向该IPv4子网上的所有节点公布IPv4地址和媒体访问控制（MAC）地址之间的当前绑定。（还请注意，ARP的一个众所周知的、长期存在的问题是无法对其进行身份验证。）在未首先确保这些其他定位器上下文中的唯一性（例如。，在使用ILNPv6时使用IPv6邻居发现的重复地址检测机制，或者在使用ILNPv4时发送ARP请求。
Other methods might be used to generate local-scope Identifiers. For example, one might derive Identifiers using some form of cryptographic generation or using the methods specified in the IPv6 Privacy Extensions [RFC4941] to Stateless Address Autoconfiguration (SLAAC) [RFC4862]. When cryptographic generation of Identifiers using methods described in RFC 3972 is in use, only the Identifier is included, never the Locator, thereby preserving roaming capability. One could also imagine creating a local-scope Identifier by taking a cryptographic hash of a node's public key. Of course, in the unlikely event of an Identifier collision, for example, when a node has chosen to use a local-scope Identifier value, the node remains free to use some other local-scope Identifier value(s).
可以使用其他方法来生成本地范围标识符。例如，可以使用某种形式的加密生成或使用IPv6隐私扩展[RFC4941]到无状态地址自动配置（SLAAC）[RFC4862]中指定的方法来派生标识符。当使用RFC 3972中描述的方法加密生成标识符时，仅包括标识符，而不包括定位器，从而保持漫游能力。还可以想象通过获取节点公钥的加密散列来创建本地作用域标识符。当然，在不太可能发生标识符冲突的情况下，例如，当节点选择使用本地作用域标识符值时，节点仍然可以自由使用其他一些本地作用域标识符值。
It is worth remembering here that an IPv6 address names a specific network interface on a specific node, but an ILNPv6 Identifier names the node itself, not a specific interface on the node. This difference in definition is essential to providing seamless support for mobility and multihoming, which are discussed in more detail later in this note.
这里值得记住的是，IPv6地址命名特定节点上的特定网络接口，但ILNPv6标识符命名节点本身，而不是节点上的特定接口。这种定义上的差异对于为移动性和多宿提供无缝支持至关重要，本说明后面将更详细地讨论这一点。
ILNPv6 Locator and Identifier values are encoded into IPv6 address space and ILNPv6 uses directly the Classic IPv6 packet format, as shown in Figure 3.3. This is also the view of an ILNPv6 packet as seen by core routers -- they simply use the Locator value (top 64-bits of the address field) just as they would use an IPv6 prefix today (e.g., either as /48 or as /64 when using sub-network routing).
ILNPv6定位器和标识符值被编码到IPv6地址空间，ILNPv6直接使用经典的IPv6数据包格式，如图3.3所示。这也是核心路由器看到的ILNPv6数据包的视图——它们只是使用定位器值（地址字段的前64位），就像今天使用IPv6前缀一样（例如，使用子网路由时使用as/48或as/64）。
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| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3.3: Existing ("Classic") IPv6 Header
图3.3：现有（“经典”）IPv6标头
In essence, the Locator names a subnetwork. (Locators can also be referred to as Routing Prefixes if discussing Classic IPv6). Of course, backwards compatibility requirements mean that ILNPv6 Locators use the same number space as IPv6 routing prefixes. This ensures that no changes are needed to deployed IPv6 routers when deploying ILNPv6.
本质上，定位器为子网络命名。（如果讨论经典IPv6，定位器也可以称为路由前缀）。当然，向后兼容性要求意味着ILNPv6定位器使用与IPv6路由前缀相同的数字空间。这确保了在部署ILNPv6时不需要更改已部署的IPv6路由器。
The low-order 64-bits of the IPv6 address become the Identifier. Details of the Identifier were discussed above. The Identifier is only used by end-systems, so Figure 3.4 shows the view of the same packet format, but as viewed by an ILNPv6 node. As this only needs to be parsed in this way by the end-system, so ILNPv6 deployment is enabled incrementally by updating end-systems as required.
IPv6地址的低位64位成为标识符。上面讨论了标识符的详细信息。标识符仅由终端系统使用，因此图3.4显示了相同数据包格式的视图，但由ILNPv6节点查看。由于这只需要由终端系统以这种方式进行解析，因此通过根据需要更新终端系统来增量启用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| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Locator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Identifier |
| |
+ +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Locator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Locator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Identifier |
| |
+ +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Locator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Identifier |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3.4: ILNPv6 Header as Seen by ILNPv6-Enabled End-Systems
图3.4:ILNPv6启用的终端系统所示的ILNPv6标题
Encoding of Identifier and Locator values for ILNPv4 is not as straightforward as for ILNPv6. In analogy to ILNPv6, in ILNPv4, the Locator value is a routing prefix for IPv4, but is at most 30 bits. Source Locator values are carried in the source address field of the IPv4 header, and destination Locator values in the destination address field. So, just like for ILNPv6, for ILNPv4, packet routing can be performed by routers examining existing prefix values in the IPv4 header.
ILNPv4的标识符和定位器值的编码不像ILNPv6那样简单。与ILNPv6类似，在ILNPv4中，定位器值是IPv4的路由前缀，但最多为30位。源定位器值在IPv4标头的源地址字段中携带，目标定位器值在目标地址字段中携带。因此，与ILNPv6一样，对于ILNPv4，路由器可以通过检查IPv4报头中的现有前缀值来执行数据包路由。
However, for ILNPv4, additional option headers have to be used to carry the Identifier value as there is not enough room in the normal IPv4 header fields. A 64-bit Identifier value is carried in an option header. So, the detailed explanation of the ILNPv4 packet header is to be found in [RFC6746].
但是，对于ILNPv4，必须使用额外的选项标头来携带标识符值，因为在正常的IPv4标头字段中没有足够的空间。64位标识符值在选项标头中携带。因此，ILNPv4数据包头的详细说明见[RFC6746]。
ILNP uses an Identifier value in order to form the invariant end-system state for end-to-end protocols. Currently, transport protocols such as TCP and UDP use all the bits of an IP Address to form such state. So, transport protocol implementations MUST be modified in order to operate over ILNP.
ILNP使用标识符值来形成端到端协议的不变端系统状态。目前，TCP和UDP等传输协议使用IP地址的所有位来形成这种状态。因此，为了在ILNP上运行，必须修改传输协议实现。
Currently, TCP and UDP, for example, use the 4-tuple:
例如，当前TCP和UDP使用4元组：
<local port, remote port, local IP Address, remote IP Address>
<本地端口、远程端口、本地IP地址、远程IP地址>
for the end-system state for a transport layer end-point. For ILNP, implementations must be modified to instead use the following:
用于传输层端点的结束系统状态。对于ILNP，必须修改实现以使用以下内容：
<local port, remote port, local Identifier, remote Identifier>
<本地端口，远程端口，本地标识符，远程标识符>
In IP-based implementations, the TCP or UDP pseudo-header checksum calculations include all the bits of the IP Address. By contrast, when calculating the TCP or UDP pseudo-header checksums for use with ILNP, only the Identifier values are included in the TCP or UDP pseudo-header checksum calculations.
在基于IP的实现中，TCP或UDP伪报头校验和计算包括IP地址的所有位。相比之下，在计算用于ILNP的TCP或UDP伪报头校验和时，TCP或UDP伪报头校验和计算中仅包括标识符值。
To minimise the changes required within transport protocol implementations, and to maximise interoperability, current implementations are modified to zero the Locator fields (only for the purpose of TCP or UDP checksum calculations). For example, for ILNPv6, this means that the existing code for IPv6 can be used, with the ILNPv6 Identifier bits occupying the lower 64 bits of the IPv6 address field, and the upper 64 bits of the IPv6 address filed being set to zero. For ILNPv4, the Identifier fields are carried in an IPv4 Option [RFC6746].
为了最大限度地减少传输协议实现中所需的更改，并最大限度地提高互操作性，将当前实现修改为将定位器字段归零（仅用于TCP或UDP校验和计算）。例如，对于ILNPv6，这意味着可以使用IPv6的现有代码，ILNPv6标识符位占据IPv6地址字段的低64位，而IPv6地址字段的高64位设置为零。对于ILNPv4，标识符字段包含在IPv4选项[RFC6746]中。
Section 7 describes methods for incremental deployment of this ILNP-specific change and backwards compatibility with non-upgraded nodes (e.g., classic IPv4 or IPv6 nodes) in more detail.
第7节更详细地描述了增量部署此ILNP特定更改的方法以及与未升级节点（例如，经典IPv4或IPv6节点）的向后兼容性。
To maximise backwards compatibility, the ILNPv6 ICMP checksum is always calculated in the same way as for IPv6 ICMP. Similarly, the ILNPv4 ICMP checksum is always calculated in the same way as for IPv4 ICMP.
为了最大限度地提高向后兼容性，ILNPv6 ICMP校验和的计算方法始终与IPv6 ICMP相同。类似地，ILNPv4 ICMP校验和的计算方式始终与IPv4 ICMP相同。
For operational purposes, implementations need to have a local cache of state information that allow communication endpoints to be constructed and for communication protocols to operate. Such cache information is common today, e.g., IPv4 nodes commonly maintain an Address Resolution Protocol (ARP) cache with information relating to current and recent Correspondent Nodes (CNs); IPv6 nodes maintain a Neighbor Discovery (ND) table with information relating to current and CNs. Likewise, ILNP maintains an Identifier Locator Communication Cache (ILCC) with information relating to the operation of ILNP.
出于操作目的，实现需要有一个状态信息的本地缓存，该缓存允许构造通信端点，并允许通信协议运行。这种缓存信息在今天很常见，例如，IPv4节点通常维护一个地址解析协议（ARP）缓存，其中包含与当前和最近对应节点（CNs）相关的信息；IPv6节点维护一个邻居发现（ND）表，其中包含与当前和CNs相关的信息。类似地，ILNP使用与ILNP的操作相关的信息维护标识符定位器通信缓存（ILCC）。
The ILCC is a (logical) set of data values required for ILNP to operate. These values are maintained by the endpoints of each ILNP session.
ILCC是ILNP运行所需的一组（逻辑）数据值。这些值由每个ILNP会话的端点维护。
In theory, this cache is within the ILNP network-layer. However, many network protocol implementations do not have strict protocol separation or layering. So there is no requirement that the ILCC be kept partitioned from transport-layer protocols.
理论上，该缓存位于ILNP网络层内。然而，许多网络协议实现没有严格的协议分离或分层。因此，不需要将ILCC与传输层协议分开。
Note that, in many implementations, much of the information required for the ILCC may already be present. Where some additional information is required for ILNP, from an engineering viewpoint, the ILCC could be implemented by extending or enhancing existing data structures within existing implementations. For example, by adding appropriate flags to the data structures in existing implementations.
注意，在许多实现中，ILCC所需的许多信息可能已经存在。如果ILNP需要一些额外的信息，从工程的角度来看，ILCC可以通过扩展或增强现有实现中的现有数据结构来实现。例如，通过向现有实现中的数据结构添加适当的标志。
Note that the ILCC does not impose any extra state maintenance requirements for applications or applications servers. For example, in the case of, say, HTTP, there will be no additional state for a server to maintain, and any TCP state will be handled by the ILNP code in the OS just as for IP.
请注意，ILCC不会对应用程序或应用程序服务器施加任何额外的状态维护要求。例如，在HTTP的情况下，服务器不需要维护其他状态，任何TCP状态都将由操作系统中的ILNP代码处理，就像处理IP一样。
The ILCC contains information about both the local node and also about current or recent correspondent nodes, as follows.
ILCC包含有关本地节点以及当前或最近对应节点的信息，如下所示。
Information about the local node:
有关本地节点的信息：
- Each currently valid Identifier value, including its Identifier Precedence and whether it is active at present.
- 每个当前有效的标识符值，包括其标识符优先级以及当前是否处于活动状态。
- Each currently valid Locator value, including its associated local interface(s), its Locator Precedence and whether it is active at present.
- 每个当前有效的定位器值，包括其关联的本地接口、定位器优先级以及当前是否处于活动状态。
- Each currently valid IL Vector (I-LV), including whether it is active at present.
- 每个当前有效的IL向量（I-LV），包括其当前是否处于活动状态。
Information about each correspondent node:
有关每个对应节点的信息：
- Most recent set of Identifiers, including lifetime and validity for each.
- 最新的一组标识符，包括每个标识符的生存期和有效期。
- Most recent set of Locators, including lifetime and validity for each.
- 最新的定位器集，包括每个定位器的生存期和有效期。
- Nonce value for packets from the local host to the correspondent.
- 从本地主机到通讯器的数据包的Nonce值。
- Nonce value for packets from the correspondent to the local host.
- 从对应方到本地主机的数据包的Nonce值。
In the above list for the ILNP Communication Cache:
在上面的ILNP通信缓存列表中：
- A "valid" item is usable, from an administrative point of view, but it might or might not be in use at present.
- 从管理的角度来看，“有效”项是可用的，但它目前可能在使用中，也可能不在使用中。
- The "validity" parameter for the correspondent node indicates one of several different states for a datum. These include at least the following:
- 对应节点的“有效性”参数表示基准的几种不同状态之一。这些措施至少包括：
- "valid": data is usable and has not expired.
- “有效”：数据可用且未过期。
- "active": data is usable, has not expired, and is in active use at present.
- “活动”：数据可用，尚未过期，且当前处于活动使用状态。
- "expired": data is still in use at present, but is beyond its expiration (i.e., without a replacement value).
- “过期”：数据目前仍在使用，但已过期（即没有替换值）。
- "aged": data was recently in use, but is not in active use at present, and is beyond its expiration.
- “老化”：数据最近正在使用，但目前未在使用中，并且已过期。
- The "lifetime" parameter is an implementation-specific representation of the validity lifetime for the associated data element. In normal operation, the Lifetime for a correspondent node's Locator(s) are learned from the DNS Time-To-Live (DNS TTL) value associated with DNS records (NID, L32, L64, etc.) of the Fully Qualified Domain Name (FQDN) owner name of the correspondent node. For time, a node might use UTC (e.g., via Network Time Protocol) or perhaps some node-specific time (e.g., seconds since node boot).
- “lifetime”参数是关联数据元素的有效期的特定于实现的表示形式。在正常操作中，从与对应节点的完全限定域名（FQDN）所有者名称的DNS记录（NID、L32、L64等）关联的DNS生存时间（DNS TTL）值中学习对应节点定位器的生存期。对于时间，节点可能使用UTC（例如，通过网络时间协议）或某些特定于节点的时间（例如，自节点启动后的秒数）。
As a practical engineering matter, it is not sensible to flush all Locator values associated with an existing ILNP session's correspondent node even if the DNS TTL associated with those Locator values expires.
作为一个实际工程问题，刷新与现有ILNP会话的对应节点关联的所有定位器值是不明智的，即使与这些定位器值关联的DNS TTL过期。
In some situations, a CN might be disconnected briefly when moving location (e.g., immediate handover, which sometimes is called "break before make"). If this happens, there might be a brief pause before the Correspondent Node can (a) update its own L values in the DNS, and (b) send an ICMP Locator Update message to the local node with information about its new location. Implementers ought to try to maintain ILNP sessions even when such events occur.
在某些情况下，移动位置时CN可能会短暂断开连接（例如，即时切换，有时称为“先断后接”）。如果发生这种情况，可能会有短暂的暂停，然后对应节点才能（a）更新DNS中自己的L值，以及（b）向本地节点发送ICMP定位器更新消息，其中包含有关其新位置的信息。即使发生这样的事件，实现者也应该尝试维护ILNP会话。
Instead, Locator values cached for a correspondent node SHOULD be marked as "aged" when their TTL has expired, but retained until either the next Locator Update message is received, there is other indication that a given Locator is not working any longer, there is positive indication that the Correspondent Node has terminated the ILNP session (e.g., TCP RST if the only transport-layer session for this ILNP session is a TCP session), until some appropriate timeout (e.g., 2*MSL for TCP if the only transport-layer session for this ILNP session is a TCP session), or the ILNP session has been inactive for several minutes (e.g., no transport-layer session exists for this ILNP session) and the storage space associated with the aged entry needs to be reclaimed.
相反，当对应节点的TTL过期时，为其缓存的定位器值应标记为“已过期”，但应保留到收到下一个定位器更新消息、存在给定定位器不再工作的其他指示、存在对应节点已终止ILNP会话的肯定指示（例如，如果此ILNP会话的唯一传输层会话是TCP会话，则为TCP RST），直到某个适当的超时（例如，如果此ILNP会话的唯一传输层会话是TCP会话，则为TCP的2*MSL），或者ILNP会话已停用数分钟（例如，此ILNP会话不存在任何传输层会话）需要回收与旧条目相关的存储空间。
Separately, received authenticated Locator Update messages cause the ILCC entries listed above to be updated.
另外，收到的经过身份验证的定位器更新消息会导致更新上面列出的ILCC条目。
Similarly, if there is indication that an ILNP session with a Correspondent Node remains active and the DNS TTL associated with that Correspondent Node's active Identifier value(s) has expired, those remote Identifier value(s) ought to be marked as "expired", but retained since they are in active use.
类似地，如果存在与对应节点的ILNP会话保持活动且与该对应节点的活动标识符值相关联的DNS TTL已过期的指示，则这些远程标识符值应标记为“已过期”，但由于它们处于活动使用状态而保留。
Implementers should keep in mind that a node or site might have a large number of concurrent Locators, and it should ensure that a system fault does not arise if the system receives an authentic ICMP Locator Update containing a large number of Locator values.
实施者应记住，节点或站点可能有大量并发定位器，并且应确保如果系统接收到包含大量定位器值的真实ICMP定位器更新，则不会出现系统故障。
For received packets containing an ILNP Nonce Option, lookups in the ILCC MUST use the <remote Identifier, Nonce> tuple as the lookup key.
对于包含ILNP Nonce选项的接收数据包，ILCC中的查找必须使用<remote Identifier，Nonce>元组作为查找键。
For all other ILNP packets, lookups in the ILNP Correspondent Cache MUST use the <remote Locator, remote Identifier> tuple, i.e., the remote I-LV, as the lookup key.
对于所有其他ILNP数据包，ILNP对应缓存中的查找必须使用<remote Locator，remote Identifier>元组，即远程i-LV，作为查找键。
These two checks between them facilitate situations where, perhaps due to deployment of Local-scope Identifiers, more than one correspondent node is using the same Identifier value.
它们之间的这两个检查有助于以下情况：可能由于部署了本地作用域标识符，多个对应节点正在使用相同的标识符值。
(NOTE: Other mechanisms, such as IPv6 Neighbor Discovery, ensure that two different nodes are incapable of using a given I-LV at the same location, i.e., on the same link.)
（注意：其他机制，如IPv6邻居发现，确保两个不同的节点无法在同一位置（即在同一链路上）使用给定的I-LV。）
While Locators are omitted from the transport-layer checksum, an implementation SHOULD use Locator values to distinguish between correspondents coincidentally using the same Identifier value (e.g., due to deployment of Local-scope Identifier values) when demultiplexing to determine which application(s) should receive the user data delivered by the transport-layer protocol.
虽然传输层校验和中省略了定位器，但在解复用以确定哪个应用程序时，实现应使用定位器值来区分同时使用相同标识符值（例如，由于部署本地作用域标识符值）的对应程序应接收传输层协议交付的用户数据。
In normal operation, an ILNP node uses the DNS for initial rendezvous in setting up ILNP sessions. The use of DNS for initial rendezvous with mobile nodes was earlier proposed by others [PHG02] and then separately reinvented by the current authors later on.
在正常操作中，ILNP节点在设置ILNP会话时使用DNS进行初始会合。使用DNS进行与移动节点的初始会合是其他人较早提出的[PHG02]，然后由当前的作者在稍后分别重新发明。
To handle the move of a node or a change to the upstream connectivity of a multihomed node, we add a new ICMP control message [RFC6745] [RFC6743]. The ICMP Locator Update (LU) message is used by a node to inform its existing CNs that the set of valid Locators for the node has changed. This mechanism can be used to add newly valid Locators, to remove no longer valid Locators, or to do both at the same time. The LU mechanism is analogous to the Binding Update mechanism in Mobile IPv6, but in ILNP, such messages are used any time Locator value changes need to be notified to CNs, e.g., for multihomed hosts as well as for mobile hosts.
为了处理节点的移动或多宿节点的上游连接的更改，我们添加了一个新的ICMP控制消息[RFC6745][RFC6743]。节点使用ICMP定位器更新（LU）消息通知其现有CNs该节点的有效定位器集已更改。此机制可用于添加新的有效定位器、删除不再有效的定位器或同时执行这两项操作。LU机制类似于移动IPv6中的绑定更新机制，但在ILNP中，当需要向CNs通知定位器值更改时（例如，对于多宿主机和移动主机），都会使用此类消息。
Further, if the node wishes to be able to receive new incoming ILNP sessions, the node normally uses Secure Dynamic DNS Update [RFC3007] to ensure that a correct set of Locator values are present in the
此外，如果节点希望能够接收新的传入ILNP会话，则该节点通常使用安全动态DNS更新[RFC3007]来确保该会话中存在一组正确的定位器值
appropriate DNS records (i.e., L32, L64) in the DNS for that node [RFC6742]. This enables any new correspondents to correctly initiate a new ILNP session with the node at its new location.
该节点的DNS中的适当DNS记录（即L32、L64）[RFC6742]。这使任何新的通信者都能够正确地启动新的ILNP会话，使节点位于其新位置。
While the Locator Update control message could be an entirely new protocol running over UDP, for example, there is no obvious advantage to creating a new protocol rather than using a new ICMP message. So ILNP defines a new ICMP Locator Update message for both IPv4 and IPv6.
例如，虽然定位器更新控制消息可能是通过UDP运行的全新协议，但创建新协议而不是使用新ICMP消息并没有明显的优势。因此，ILNP为IPv4和IPv6定义了新的ICMP定位器更新消息。
As a DNS performance optimisation, the LP DNS resource record MAY be used to avoid requiring each node on a subnetwork to update its DNS L64 record entries when that subnetwork's location (e.g., upstream connectivity) changes [RFC6742]. This can reduce the number of DNS updates required when a subnetwork moves from Order (number of nodes on subnetwork) to Order(1).
作为DNS性能优化，LP DNS资源记录可用于避免子网络上的每个节点在该子网络的位置（例如，上游连接）改变时更新其DNS L64记录条目[RFC6742]。这可以减少子网络从订单（子网络上的节点数）移动到订单（1）时所需的DNS更新次数。
In this case, the nodes on the subnetwork each would have an LP record pointing to a common FQDN used to name that subnetwork. In turn, that subnetwork's domain name would have one or more L64 record(s) in the DNS. Since the contents of an LP record are stable, relatively long DNS TTL values can be associated with these records facilitating DNS caching. By contrast, the DNS TTL of an L32 or L64 record for a mobile or multihomed node should be small. Experimental work at the University of St Andrews indicates that the DNS continues to work well even with very low (e.g., zero) DNS TTL values [BA11].
在这种情况下，子网络上的每个节点都将有一个指向用于命名该子网络的公共FQDN的LP记录。反过来，该子网络的域名将在DNS中有一个或多个L64记录。由于LP记录的内容是稳定的，因此相对较长的DNS TTL值可以与这些记录关联，从而促进DNS缓存。相比之下，移动或多址节点的L32或L64记录的DNS TTL应该很小。圣·安驻斯大学的实验工作表明，即使在非常低（例如，零）DNS TTL值[BA11]的情况下，DNS仍能很好地工作。
Correspondents of a node on a mobile subnetwork using this DNS performance optimisation would initially perform a normal FQDN lookup for a node. If that lookup returned another FQDN in an LP record as additional data, then the correspondent would perform a lookup on that FQDN and expect an L32 or L64 record returned as additional data, in order to learn the Locator value to use to reach that target node. (Of course, a lookup that did not return any ILNP-related DNS records would result in an ordinary IPv4 session or ordinary IPv6 session being initiated, instead.)
使用此DNS性能优化的移动子网上节点的对应方最初将对节点执行正常FQDN查找。如果该查找将LP记录中的另一个FQDN作为附加数据返回，则对应方将对该FQDN执行查找，并期望将L32或L64记录作为附加数据返回，以便了解用于到达该目标节点的定位器值。（当然，不返回任何与ILNP相关的DNS记录的查找将导致启动普通IPv4会话或普通IPv6会话。）
For ILNPv4 and ILNPv6, the Locator value includes the subnetting information, as that also is topological information. As well as being architecturally correct, the placement of subnetting as part of the Locator is also convenient from an engineering point of view in both IPv4 and IPv6.
对于ILNPv4和ILNPv6，定位器值包括子网信息，因为子网信息也是拓扑信息。除了在体系结构上是正确的之外，从工程的角度来看，在IPv4和IPv6中，子网作为定位器的一部分的放置也很方便。
We consider that a Locator value, L consists of two parts:
我们认为一个定位器值，L由两部分组成：
- L_pp: the Locator prefix part, which occupies the most significant bits in the address (for both ILNPv4 and ILNPv6).
- L_pp：定位器前缀部分，它占据地址中的最高有效位（对于ILNPv4和ILNPv6）。
- L_ss: Locator subnetwork selector, which occupies bits just after the L_pp.
- L_ss：定位器子网选择器，它占用L_pp后面的位。
For each of ILNPv4 and ILNPv6, L_pp gets its value from the provider-assigned routing prefix for IPv4 and IPv6, respectively. For L_ss, in each case of ILNPv4 and ILNPv6, the L_ss bits are located in the part of the address space which you might expect them to be located if IPv4 or IPv6 addresses were being used, respectively.
对于ILNPv4和ILNPv6，L_pp分别从提供程序为IPv4和IPv6分配的路由前缀中获取其值。对于L_-ss，在ILNPv4和ILNPv6的每种情况下，L_-ss位都位于地址空间中，如果分别使用IPv4或IPv6地址，则您可能希望它们位于该地址空间中。
For ILNPv6, recall that the Locator value is encoded to be syntactically similar to an IPv6 address prefix, as shown in Figure 7.1.
对于ILNPv6，回想一下定位器值被编码为语法上类似于IPv6地址前缀，如图7.1所示。
/* IPv6 */
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
|001|global routing prefix| subnet ID | Interface Identifier |
+---+---------------------+-----------+-------------------------+
/* IPv6 */
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
|001|global routing prefix| subnet ID | Interface Identifier |
+---+---------------------+-----------+-------------------------+
/* ILNPv6 */
| 64 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
| Locator (L64) | Node Identifier (NID) |
+---+---------------------+-----------+-------------------------+
+<-------- L_pp --------->+<- L_ss -->+
/* ILNPv6 */
| 64 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
| Locator (L64) | Node Identifier (NID) |
+---+---------------------+-----------+-------------------------+
+<-------- L_pp --------->+<- L_ss -->+
L_pp = Locator prefix part (assigned IPv6 prefix) L_ss = Locator subnet selector (locally managed subnet ID)
L_pp=定位器前缀部分（分配的IPv6前缀）L_ss=定位器子网选择器（本地管理的子网ID）
Figure 7.1: IPv6 Address Format [RFC3587] as Used in ILNPv6, Showing How Subnets Can Be Identified
图7.1:ILNPv6中使用的IPv6地址格式[RFC3587]，显示了如何识别子网
Note that the subnet ID forms part of the Locator value. Note also that [RFC6177] allows the global routing prefix to be more than 45 bits, and for the subnet ID to be smaller, but still preserving the 64-bit size of the Locator.
请注意，子网ID构成定位器值的一部分。还要注意，[RFC6177]允许全局路由前缀大于45位，子网ID更小，但仍然保留定位器的64位大小。
For ILNPv4, the L_pp value is an IPv4 routing prefix as used today, which is typically less than 32 bits. However, the ILNPv4 Locator value is carried in the 32-bit IP Address space, so the bits not used for the routing prefix could be used for L_ss, e.g., for a /24 IPv4 prefix, the situation would be as shown in Figure 7.2.
对于ILNPv4，L_pp值是当前使用的IPv4路由前缀，通常小于32位。然而，ILNPv4定位器值在32位IP地址空间中携带，因此未用于路由前缀的位可用于L_ss，例如，对于a/24 IPv4前缀，情况如图7.2所示。
24 bits 8 bits
+------------------------+----------+
| Locator (L32) |
+------------------------+----------+
+<------- L_pp --------->+<- L_ss ->+
24 bits 8 bits
+------------------------+----------+
| Locator (L32) |
+------------------------+----------+
+<------- L_pp --------->+<- L_ss ->+
L_pp = Locator prefix part (assigned IPv4 prefix) L_ss = Locator subnet selector (locally managed subnet ID)
L_pp=定位器前缀部分（分配的IPv4前缀）L_ss=定位器子网选择器（本地管理的子网ID）
Figure 7.2: IPv4 Address Format for /24 IPv4 Prefix, as Used in ILNPv4, Showing How Subnets Can Be Identified
图7.2:ILNPv4中使用的/24 IPv4前缀的IPv4地址格式，显示了如何识别子网
Note that the L_ss occupies bits that in an IPv4 address would normally be the host part of the address, which the site network could use for subnetting in any case.
请注意，L_ss占用的位在IPv4地址中通常是地址的主机部分，站点网络在任何情况下都可以将其用于子网。
There is a special case of /127 prefixes used in router-router, point-to-point links for IPv6 [RFC6164]. ILNPv6 does not preclude such use.
在IPv6的点到点链路路由器中使用/127前缀是一种特殊情况[RFC6164]。ILNPv6不排除此类使用。
ILNP makes use of DNS for name resolution, as does IP. Unlike IP, ILNP also uses DNS to support features such as mobility and multihoming. While such usage is appropriate use of the DNS, it is important to discuss operational and engineering issues that may impact DNS usage.
ILNP和IP一样使用DNS进行名称解析。与IP不同，ILNP还使用DNS来支持移动性和多归属等功能。虽然这种使用是DNS的适当使用，但讨论可能影响DNS使用的操作和工程问题很重要。
When a host that expects incoming connections changes one or more of its Locator values, the host normally uses the IETF Secure Dynamic DNS Update protocol [RFC3007] to update the set of currently valid Locator values associated with its FQDN. This ensures that the authoritative DNS server for its FQDN will be able to generate an accurate set of Locator values if the DNS server receives DNS name resolution request for its FQDN.
当期望传入连接的主机更改其一个或多个定位器值时，该主机通常使用IETF安全动态DNS更新协议[RFC3007]更新与其FQDN关联的当前有效定位器值集。这确保了当DNS服务器收到其FQDN的DNS名称解析请求时，其FQDN的权威DNS服务器将能够生成一组准确的定位器值。
Liu and Albitz [LA06] report that Secure Dynamic DNS Update has been supported on the client-side for several years now in widely deployed operating systems (e.g., MS Windows, Apple Mac OS X, UNIX, and Linux) and also in DNS server software (e.g., BIND). Publicly available product data sheets indicate that some other DNS server software packages, such as that from Nominum, also support this capability.
Liu和Albitz[LA06]报告说，安全动态DNS更新已经在客户端得到支持好几年了，现在广泛部署的操作系统（如MS Windows、Apple Mac OS X、UNIX和Linux）以及DNS服务器软件（如BIND）都支持这种更新。公开提供的产品数据表表明，其他一些DNS服务器软件包（如Nominum的软件包）也支持此功能。
For example, Microsoft Windows XP (and later versions), the freely distributable BIND DNS software package (used in Apple Mac OS X and in most UNIX systems), and the commercial Nominum DNS server all implement support for Secure Dynamic DNS Update and are known to interoperate [LA06]. There are credible reports that when a site deploys Microsoft's Active Directory, the site (silently) automatically deploys Secure Dynamic DNS Update [LA06]. So, many sites have already deployed Secure Dynamic DNS Update even though they are not actively using it (and might not be aware they have already deployed that protocol) [LA06].
例如，Microsoft Windows XP（及更高版本）、可自由分发的BIND DNS软件包（在Apple Mac OS X和大多数UNIX系统中使用）以及商用Nominum DNS服务器都实现了对安全动态DNS更新的支持，并且已知可互操作[LA06]。有可靠的报告称，当站点部署Microsoft的Active Directory时，该站点（静默）会自动部署安全的动态DNS更新[LA06]。因此，许多站点已经部署了安全的动态DNS更新，即使它们没有积极使用它（并且可能不知道它们已经部署了该协议）[LA06]。
So DNS update via Secure Dynamic DNS Update is not only standards-based, but also readily available in widely deployed systems today.
因此，通过安全动态DNS更新进行DNS更新不仅是基于标准的，而且在当今广泛部署的系统中也很容易获得。
As part of this proposal, additional DNS resource records have been proposed in a separate document [RFC6742]. These new records are summarised in Table 6.1.
作为本提案的一部分，在单独的文件[RFC6742]中提出了其他DNS资源记录。表6.1总结了这些新记录。
new DNS RR type | Purpose
-----------------+------------------------------------------------
NID | store the value of a Node Identifier
L32 | store the value of a 32-bit Locator for ILNPv4
L64 | store the value of a 64-bit Locator for ILNPv6
LP | points to a (several) L32 and/or L64 record(s)
-----------------+------------------------------------------------
new DNS RR type | Purpose
-----------------+------------------------------------------------
NID | store the value of a Node Identifier
L32 | store the value of a 32-bit Locator for ILNPv4
L64 | store the value of a 64-bit Locator for ILNPv6
LP | points to a (several) L32 and/or L64 record(s)
-----------------+------------------------------------------------
Table 6.1. Summary of new DNS RR Types for ILNP
表6.1。ILNP的新DNS RR类型摘要
With this proposal, mobile or multihomed nodes and sites are expected to use the existing "Secure Dynamic DNS Update" protocol to keep their Node Identifier (NID) and Locator (L32 and/or L43) records correct in their authoritative DNS server(s) [RFC3007] [RFC6742].
根据该方案，移动或多宿节点和站点预计将使用现有的“安全动态DNS更新”协议，在其权威DNS服务器中保持其节点标识符（NID）和定位器（L32和/或L43）记录的正确性[RFC3007][RFC6742]。
Reverse DNS lookups, to find a node's FQDN from the combination of a Locator and related Identifier value, can be performed as at present.
反向DNS查找，从定位器和相关标识符值的组合中查找节点的FQDN，目前可以执行。
Existing DNS specifications require that DNS clients and DNS resolvers honour the TTL values provided by the DNS servers. In the context of this proposal, short DNS TTL values are assigned to particular DNS records to ensure that the ubiquitous DNS caching resolvers do not cache volatile values (e.g., Locator records of a mobile node) and consequently return stale information to new requestors.
现有DNS规范要求DNS客户端和DNS解析程序遵守DNS服务器提供的TTL值。在本提案的上下文中，短DNS TTL值被分配给特定DNS记录，以确保无处不在的DNS缓存解析器不会缓存易失性值（例如，移动节点的定位器记录），并因此将过时信息返回给新的请求者。
The TTL values for L32 and L64 records may have to be relatively low (perhaps a few seconds) in order to support mobility and multihoming. Low TTL values may be of concern to administrators who might think that this would reduce efficacy of DNS caching increase DNS load significantly.
L32和L64记录的TTL值可能必须相对较低（可能需要几秒钟），以便支持移动性和多主。低TTL值可能会引起管理员的关注，他们可能认为这会降低DNS缓存的效率，从而显著增加DNS负载。
Previous research by others indicates that DNS caching is largely ineffective, with the exception of NS records and the addresses of DNS servers referred to by NS records [SBK02]. This means DNS caching performance and DNS load will not be adversely affected by assigning very short TTL values (down to zero) to the Locator records of typical nodes for an edge site [BA11]. It also means that it is preferable to deploy the DNS server function on nodes that have longer DNS TTL values, rather than on nodes that have shorter DNS TTL values.
其他人之前的研究表明，DNS缓存在很大程度上是无效的，NS记录和NS记录所指DNS服务器的地址除外[SBK02]。这意味着DNS缓存性能和DNS负载不会因为边缘站点的典型节点的定位器记录分配非常短的TTL值（降至零）而受到不利影响[BA11]。这还意味着最好在具有较长DNS TTL值的节点上部署DNS服务器功能，而不是在具有较短DNS TTL值的节点上。
LP records normally are stable and will have relatively long TTL values, even if the L32 or L64 records they point to have values that have relatively low TTL values.
LP记录通常是稳定的，具有相对较长的TTL值，即使它们指向的L32或L64记录具有相对较低的TTL值。
Identifier values might be very long-lived (e.g., days) when they have been generated from an IEEE MAC address on the system. Identifier values might have a shorter lifetime (e.g., hours or minutes) if they have been cryptographically generated [RFC3972], have been created by the IPv6 Privacy Extensions [RFC4941], or otherwise have the EUI-64 scope bit set to "local-scope". Note that when ILNP is used, the cryptographic generation method described in RFC 3972 is used only for the Identifier, omitting the Locator, thereby preserving roaming capability. Note that a given ILNP session normally will use a single Identifier value for the lifetime of that ILNP session.
从系统上的IEEE MAC地址生成标识符值时，标识符值可能会很长（例如，天）。如果标识符值是以加密方式生成的[RFC3972]，由IPv6隐私扩展[RFC4941]创建的，或者将EUI-64作用域位设置为“本地作用域”，则标识符值的生存期（例如，小时或分钟）可能较短。注意，当使用ILNP时，RFC 3972中描述的加密生成方法仅用于标识符，省略定位器，从而保持漫游能力。请注意，给定的ILNP会话通常在该ILNP会话的生存期内使用单个标识符值。
During a long transition period, a node that is ILNP-capable SHOULD have not only NID and L32/L64 (or NID and LP) records present in its authoritative DNS server but also SHOULD have A/AAAA records in the DNS for the benefit of non-upgraded nodes. Then, when any CN
在较长的过渡期内，具有ILNP能力的节点不仅应在其权威DNS服务器中具有NID和L32/L64（或NID和LP）记录，而且还应在DNS中具有a/AAAA记录，以利于未升级的节点。那么,什么时候,
performs an FQDN lookup for that node, it will receive the A/AAAA with the appropriate NID, L32/L64 records, and/or LP records as "additional data".
对该节点执行FQDN查找，它将接收A/AAAA，并将相应的NID、L32/L64记录和/或LP记录作为“附加数据”。
Existing DNS specifications require that a DNS resolver or DNS client ignore unrecognised DNS record types. So, gratuitously appending NID and Locator (i.e., L32, L64, or LP) records as "additional data" in DNS responses to A/AAAA queries ought not to create any operational issues. So, IP only nodes would use the A/AAAA RRs, but ILNP-capable nodes would be able to use the NID, L32/L64 and/or LP records are required.
现有DNS规范要求DNS解析程序或DNS客户端忽略未识别的DNS记录类型。因此，在对A/AAAA查询的DNS响应中，无偿附加NID和定位器（即L32、L64或LP）记录作为“附加数据”不应产生任何操作问题。因此，仅IP节点将使用A/AAAA RRs，但支持ILNP的节点将能够使用NID，需要L32/L64和/或LP记录。
There is nothing to prevent this capability being implemented strictly inside a DNS server, whereby the DNS server synthesises a set of A/AAAA records to advertise from the NID and Locator (i.e., L32, L64, or LP) values that the node has kept updated in that DNS server. Indeed, such a capability may be desirable, reducing the amount of manual configuration required for a site, and reducing the potential for errors as the A/AAAA records would be automatically generated.
没有什么可以阻止严格在DNS服务器内部实现此功能，由此DNS服务器合成一组a/AAAA记录，以从NID和定位符（即L32、L64或LP）中公布节点在该DNS服务器中保持更新的值。事实上，这样的功能可能是可取的，减少了站点所需的手动配置量，并减少了由于自动生成a/AAAA记录而产生错误的可能性。
The primary conceptual difference from ordinary IP security (IPsec) is that ILNP IP Security omits all use of, and all reference to, Locator values. This leads to several small, but important, changes to IPsec when it is used with ILNP sessions.
与普通IP安全（IPsec）在概念上的主要区别在于，ILNP IP安全忽略了定位器值的所有使用和所有引用。当IPsec与ILNP会话一起使用时，这会导致对IPsec进行一些小但重要的更改。
IPsec Security Associations for ILNP only include the Identifier values for the endpoints, and omit the Locator values. As an implementation detail, ILNP implementations MUST be able to distinguish between different Security Associations with ILNP correspondents (at different locations, with different ILNP Nonce values in use) that happen to use the same Identifier values (e.g., due to an inadvertent Identifier collision when using identifier values generated by using the IPv6 Privacy Addressing extension). One possible way to distinguish between such different ILNP sessions is to maintain a mapping between the IPsec Security Association Database (SAD) entry and the corresponding ILCC entry.
ILNP的IPsec安全关联仅包括端点的标识符值，而忽略定位器值。作为实现细节，ILNP实现必须能够区分与恰好使用相同标识符值的ILNP对应者（在不同位置，使用不同的ILNP Nonce值）的不同安全关联（例如，由于使用通过使用IPv6隐私寻址扩展生成的标识符值时无意中发生标识符冲突）。区分此类不同ILNP会话的一种可能方法是维护IPsec安全关联数据库（SAD）条目与相应ILCC条目之间的映射。
Consistent with this enhancement to the definition of an IPsec Security Association, when processing received IPsec packets associated with an ILNP session, ILNP implementations ignore the Locator bits of the received packet and only consider the Identifier bits. This means, for example, that if an ILNP correspondent node
与IPSec安全关联定义的这种增强一致，当处理与ILNP会话相关联的接收到的IPSec分组时，ILNP实现忽略所接收分组的定位比特，而仅考虑标识符比特。这意味着，例如，如果ILNP对应节点
moves to a different subnetwork, and thus is using a different Source Locator in the header of its ILNP IPsec packets, the ILNP session will continue to work and will continue to be secure.
移动到不同的子网，从而在其ILNP IPsec数据包的报头中使用不同的源定位器，ILNP会话将继续工作并将继续保持安全。
Since implementations of ILNP are also required to support IP, implementers need to ensure that ILNP IPsec Security Associations can be distinguished from ordinary IPsec Security Associations. The details of this are left to the implementer. As an example, one possible implementation strategy would be to retain a single IPsec Security Association Database (SAD), but add an internal flag bit to each entry of that IPsec SAD to indicate whether ILNP is in use for that particular IPsec Security Association.
由于ILNP的实现也需要支持IP，所以实现者需要确保ILNP IPsec安全关联可以与普通IPsec安全关联区分开来。这方面的细节留给实现者。例如，一种可能的实现策略是保留单个IPsec安全关联数据库（SAD），但向该IPsec SAD的每个条目添加一个内部标志位，以指示ILNP是否用于该特定IPsec安全关联。
Similarly, for an ILNP session using IPsec, the IPsec Authentication Header (AH) only includes the Identifier values for the endpoints in its authentication calculations, and it omits the Source Locator and Destination Locator fields from its authentication calculations. This enables IPsec AH to work well even when used with ILNP localised numbering [RFC6748] or other situations where a Locator value might change while the packet travels from origin to destination.
类似地，对于使用IPsec的ILNP会话，IPsec身份验证头（AH）在其身份验证计算中仅包括端点的标识符值，并且在其身份验证计算中省略源定位器和目标定位器字段。这使得IPsec AH即使在与ILNP本地化编号[RFC6748]一起使用时，或在数据包从源位置移动到目标位置时定位器值可能发生变化的其他情况下，也能正常工作。
In order to distinguish at the network-layer between multiple ILNP nodes that happen to be using the same Node Identifier values (e.g., because the identifier values were generated using the IPv6 Privacy Addressing method), key management packets being used to set up an ILNP IPsec session MUST include the ILNP Nonce Option.
为了在网络层区分恰好使用相同节点标识符值的多个ILNP节点（例如，因为标识符值是使用IPv6隐私寻址方法生成的），用于设置ILNP IPsec会话的密钥管理包必须包括ILNP Nonce选项。
Similarly, key management protocols used with IPsec are enhanced to deprecate use of IP Addresses as identifiers and to substitute the use of the new Node Identifier values for that purpose. This results in an ILNP IPsec Security Association that is independent of the Locator values that might be used.
类似地，与IPsec一起使用的密钥管理协议也得到了增强，以禁止使用IP地址作为标识符，并取代为此目的使用新的节点标识符值。这将导致独立于可能使用的定位器值的ILNP IPsec安全关联。
For ILNPv6 implementations, the ILNP Node Identifier (64-bits) is smaller than the IPv6 Address (128-bits). So support for ILNPv6 IPsec is accomplished by zeroing the upper-64 bits of the IPv6 Address fields in the application-layer key management protocol, while retaining the Node Identifier value in the lower-64 bits of the application-layer key management protocol.
对于ILNPv6实现，ILNP节点标识符（64位）小于IPv6地址（128位）。因此，通过将应用层密钥管理协议中IPv6地址字段的上64位归零，同时在应用层密钥管理协议的下64位保留节点标识符值，可以实现对ILNPv6 IPsec的支持。
For ILNPv4 implementations, enhancements to the key management protocol likely will be needed, because existing key management protocols rely on 32-bit IPv4 addresses, while ILNP Node Identifiers are 64-bits. Such enhancements are beyond the scope of this specification.
对于ILNPv4实现，可能需要对密钥管理协议进行增强，因为现有的密钥管理协议依赖于32位IPv4地址，而ILNP节点标识符是64位的。此类增强超出了本规范的范围。
Experience with IPv6 deployment over the past many years has shown that it is important for any new network protocol to provide backwards compatibility with the deployed IP base and should be incrementally deployable, ideally requiring modification of only those nodes that wish to use ILNP and not requiring the modification of nodes that do not intend to use ILNP. The two instances of ILNP, ILNPv4 and ILNPv6, are intended to be, respectively, backwards compatible with, and incrementally deployable on, the existing IPv4 and IPv6 installed bases. Indeed, ILNPv4 and ILNPv6 can each be seen, from an engineering viewpoint, as supersets of the IPv4 and IPv6, respectively.
过去多年的IPv6部署经验表明，任何新的网络协议都必须提供与已部署IP基础的向后兼容性，并且应可增量部署，理想情况下，只需要修改希望使用ILNP的节点，而不需要修改不打算使用ILNP的节点。ILNP的两个实例ILNPv4和ILNPv6旨在分别与现有IPv4和IPv6安装基础向后兼容，并可增量部署。事实上，从工程的角度来看，ILNPv4和ILNPv6可以分别看作IPv4和IPv6的超集。
However, in some cases, ILNP introduces functions that supersede equivalent functions available in IP. For example, ILNP has a mobility model, and so it does not need to use the models for Mobile IPv4 or Mobile IPv6.
然而，在某些情况下，ILNP引入的函数会取代IP中可用的等效函数。例如，ILNP有一个移动模型，因此它不需要使用移动IPv4或移动IPv6的模型。
As ILNP changes, the use of end-to-end namespaces, for the most part, it is only end-systems that need to be modified. However, in order to leverage existing engineering (e.g., existing protocols), in some cases, there is a compromise, and these are highlighted in this section.
随着ILNP的变化，端到端名称空间的使用在很大程度上只需要修改端系统。然而，为了利用现有工程（例如，现有协议），在某些情况下，存在折衷方案，本节将重点介绍这些方案。
In the engineering design of ILNPv6 and ILNPv4, we have used the following priorities. In some ways, this choice is arbitrary, and it may be equally valid to "invert" these priorities for a different architectural and engineering design.
在ILNPv6和ILNPv4的工程设计中，我们使用了以下优先级。在某些方面，这种选择是任意的，对于不同的建筑和工程设计，“颠倒”这些优先级同样有效。
1. Infrastructure
1. 基础设施
As much of the deployed IP network infrastructure should be used without change. That is, routers and switches should require minimal or zero modifications in order to run ILNP. As much as possible of the existing installed base of core protocols should be reused.
大部分已部署的IP网络基础设施都应在不作更改的情况下使用。也就是说，为了运行ILNP，路由器和交换机应该需要最少或零修改。应尽可能重复使用现有的核心协议安装基础。
2. Core protocols
2. 核心协议
As much of the deployed network control protocols, such as routing, should be used without change. That is, existing routing protocols and switch configuration should require minimal or zero modifications in order to run ILNP.
许多已部署的网络控制协议（如路由）都应在不作更改的情况下使用。也就是说，为了运行ILNP，现有的路由协议和交换机配置应该需要最少或零修改。
3. Scope of end-system changes
3. 终端系统变更的范围
Any nodes that do not need to run ILNP should not need to be upgraded. It should be possible to have a site network that has a mix of IP-only and ILNP-capable nodes without any changes required to the IP-only nodes.
任何不需要运行ILNP的节点都不需要升级。站点网络应该可以混合使用纯IP和支持ILNP的节点，而不需要对纯IP节点进行任何更改。
4. Applications
4. 应用
There should be minimal impact on applications, even though ILNP requires end-to-end protocols to be upgraded. Indeed, for those applications that are "well behaved" (e.g., do not use IP Address values directly for application state or application configuration), there should be little or no effort required in enabling them to operate over ILNP.
即使ILNP需要升级端到端协议，对应用程序的影响也应该最小。事实上，对于那些“表现良好”的应用程序（例如，不直接将IP地址值用于应用程序状态或应用程序配置），在使它们能够在ILNP上运行时应该很少或不需要付出任何努力。
Each of these items is discussed in its own section below.
这些项目中的每一项都将在下面的章节中讨论。
ILNP is designed to be deployed on existing infrastructure. No new infrastructure is required to run ILNP as it will be implemented as a software upgrade impacting only end-to-end protocols. Existing routing protocols can be reused: no new routing protocols are required. This means that network operators and service providers do not need to learn about, test, and deploy new protocols, or change the structure of their network in order for ILNP to be deployed. Exceptionally, edge routers supporting ILNPv4 hosts will need to support an enhanced version of ARP.
ILNP旨在部署在现有基础设施上。运行ILNP不需要新的基础设施，因为它将作为软件升级实施，只影响端到端协议。现有的路由协议可以重用：不需要新的路由协议。这意味着网络运营商和服务提供商不需要了解、测试和部署新协议，也不需要为了部署ILNP而更改其网络结构。例外情况下，支持ILNPv4主机的边缘路由器将需要支持ARP的增强版本。
Existing routing and other control protocols should not need to change in devices such as switches and routers. We believe this to be true for ILNPv6. However, for ILNPv4, we believe that ARP will need to be enhanced in edge routers (or Layer 3 switches) that support ILNPv4 hosts. Backbone and transit routers still ought not require changes for either ILNPv4 or ILNPv6.
现有的路由和其他控制协议不需要在交换机和路由器等设备中进行更改。我们相信ILNPv6也是如此。然而，对于ILNPv4，我们认为ARP需要在支持ILNPv4主机的边缘路由器（或第3层交换机）中得到增强。主干和传输路由器仍然不应该要求对ILNPv4或ILNPv6进行更改。
For both ILNPv4 and ILNPv6, the basic packet format for packets reuses that format that is seen by routers for IPv4 and IPv6, respectively. Specifically, as the ILNP Locator value is always a routing prefix (either IPv4 or IPv6), routing protocols should work unchanged.
对于ILNPv4和ILNPv6，数据包的基本数据包格式分别重用IPv4和IPv6路由器看到的格式。具体来说，由于ILNP定位器值始终是路由前缀（IPv4或IPv6），因此路由协议应保持不变。
Both ILNPv4 and ILNPv6 introduce new header options (e.g., Nonce Option messages) and ICMP messages (e.g., Locator Update messages) that are used to enable end-to-end signalling. For packet forwarding, depending on the forwarding policies used by some providers or site border routers, there may need to be modifications to those policies to allow the new header options and new ICMP messages to be forwarded. However, as the header options and new ICMP messages are end-to-end, such modifications are likely to be in configuration files (or firewall policy on edge routers), as core routers do NOT need to parse and act upon the information contained in the header options or ICMP messages.
ILNPv4和ILNPv6都引入了用于启用端到端信令的新报头选项（例如，Nonce选项消息）和ICMP消息（例如，定位器更新消息）。对于数据包转发，根据某些提供商或站点边界路由器使用的转发策略，可能需要对这些策略进行修改，以允许转发新的报头选项和新的ICMP消息。但是，由于标头选项和新ICMP消息是端到端的，因此此类修改可能在配置文件（或边缘路由器上的防火墙策略）中，因为核心路由器不需要解析标头选项或ICMP消息中包含的信息并对其采取行动。
Only end-systems that need to use ILNP need to be updated in order for ILNP to be used at a site.
只有需要使用ILNP的终端系统需要更新，以便在现场使用ILNP。
There are three exceptions to this statement as follows:
本声明有以下三种例外情况：
a) ILNPv4 ARP: as the Identifier value for IPv4 cannot fit into the normal 20-byte IPv4 packet header (a header extension is used), ARP must be modified. This only impacts end-systems that use ILNPv4 and those switches or site border routers that are the first hop from an ILNPv4 node. For ILNPv6, as the I and L values fit into the existing basic IPv6 packet, IPv6 Neighbour Discovery can operate without modification.
a) ILNPv4 ARP：由于IPv4的标识符值无法放入正常的20字节IPv4数据包头（使用了头扩展），因此必须修改ARP。这只会影响使用ILNPv4的终端系统以及作为ILNPv4节点第一个跃点的交换机或站点边界路由器。对于ILNPv6，由于I和L值适合现有的基本IPv6数据包，因此IPv6邻居发现可以在不进行修改的情况下运行。
b) Use of IP NAT: Where IP NAT or NAPT is in use for a site, existing NAT/NAPT device will rewrite address fields in ILNPv4 packets or ILNPv6 packets. To avoid this, the NAT should either (i) be configured to allow the pass-through of packets originating from ILNP-capable nodes (e.g., by filtering on source address fields in the IP header); or (ii) should be enhanced to recognise ILNPv4 or ILNPv6 packets (e.g., by looking for the ILNP Nonce Option).
b) IP NAT的使用：当站点使用IP NAT或NAPT时，现有NAT/NAPT设备将重写ILNPv4数据包或ILNPv6数据包中的地址字段。为了避免这种情况，NAT应当（i）被配置为允许来自支持ILNP的节点的分组的通过（例如，通过在IP报头中的源地址字段上进行过滤）；或者（ii）应增强以识别ILNPv4或ILNPv6数据包（例如，通过查找ILNP Nonce选项）。
c) Site Border Routers (SBRs) in ILNP Advanced Deployment scenarios: There are options to use an ILNP-capable Site Border Router (SBR) as described in another document [RFC6748]. In such scenarios, the SBR(s) need to be ILNP-capable.
c) ILNP高级部署场景中的站点边界路由器（SBR）：如另一份文档[RFC6748]所述，可以选择使用支持ILNP的站点边界路由器（SBR）。在这种情况下，SBR需要具备ILNP能力。
Other than these exceptions, it is entirely possible to have a site that uses a mix of IP and ILNP nodes and requires no changes to nodes other than the nodes that wish to use ILNP. For example, if a user on a site wishes to have his laptop use ILNPv6, only that laptop would need to have an upgraded stack: no other devices (end-systems, Layer 2 switches or routers) at that site would need to be upgraded.
除了这些例外情况之外，完全可以让站点混合使用IP和ILNP节点，并且除了希望使用ILNP的节点之外，不需要对其他节点进行任何更改。例如，如果站点上的用户希望其笔记本电脑使用ILNPv6，则只有该笔记本电脑需要升级堆栈：该站点上的其他设备（终端系统、第2层交换机或路由器）不需要升级。
As noted, in the Architecture Description [RFC6740], those applications that do not use IP Address values in application state or configuration data are considered to be "well behaved". Applications that work today through a NAT or Network Address Port Translation (NAPT) device without application-specific support are also considered "well behaved". Such applications might use DNS FQDNs or application-specific name spaces. (Note Well: application-specific name spaces should not be derived from IP Address values.)
如前所述，在体系结构描述[RFC6740]中，那些在应用程序状态或配置数据中不使用IP地址值的应用程序被视为“性能良好”。今天通过NAT或网络地址端口转换（NAPT）设备工作的应用程序没有特定于应用程序的支持，也被视为“性能良好”。此类应用程序可能使用DNS FQDNs或特定于应用程序的名称空间。（请注意：应用程序特定的名称空间不应从IP地址值派生。）
For well-behaved applications, replacing IP with ILNP should have no impact. That is, well-behaved applications should work unmodified over ILNP.
对于性能良好的应用程序，用ILNP替换IP应该不会产生影响。也就是说，行为良好的应用程序应该在ILNP上不经修改地工作。
Those applications that directly use IP Address values in application state or configuration will need to be modified for operation over ILNP. Examples of such applications include the following:
那些在应用程序状态或配置中直接使用IP地址值的应用程序需要修改，以便通过ILNP进行操作。此类应用的示例包括：
- FTP: which uses IP Address values in the application-layer protocol. In practice, use of Secure Copy (SCP) is growing, while use of FTP is either flat or declining, in part due to the improved security provided by SCP.
- FTP：在应用层协议中使用IP地址值。在实践中，安全拷贝（SCP）的使用正在增长，而FTP的使用要么停滞不前，要么正在下降，部分原因是SCP提供的安全性有所提高。
- SNMP: which uses IP Address values in MIB definitions, and values derived from IP Address values in SNMP object names.
- SNMP：在MIB定义中使用IP地址值，在SNMP对象名称中使用从IP地址值派生的值。
Further experimentation in this area is planned to validate these details.
计划在该领域进行进一步试验，以验证这些细节。
A related topic is interworking: for example, how would an IPv6 node communicate with an ILNPv6 node? Currently, we make the assumption that ILNP nodes "drop down" to using IP when communicating with a non-ILNP capable node, i.e., there is no interworking as such. In the future, it may be beneficial to define interworking scenarios that do not rely on having ILNP nodes fall back to IP, for example, by the use of suitable protocol translation gateways or middleboxes.
一个相关的主题是互通：例如，IPv6节点如何与ILNPv6节点通信？目前，我们假设ILNP节点在与不支持ILNP的节点通信时“下拉”到使用IP，即不存在这样的互通。在将来，例如通过使用合适的协议转换网关或中间盒来定义不依赖于使ILNP节点退回到IP的互通场景可能是有益的。
For now, a simplified summary of the process for interaction between ILNP hosts and non-ILNP hosts is as follows:
目前，ILNP主机和非ILNP主机之间交互过程的简化摘要如下：
a) For a host initiating communication using DNS, the resolution of the FQDN for the remote host will return at least one NID record and at least one of an L32 record (for ILNPv4) or an L64 record (for ILNPv6). Then, the host knows that the remote host supports ILNP.
a) 对于使用DNS启动通信的主机，远程主机的FQDN解析将返回至少一条NID记录和至少一条L32记录（对于ILNPv4）或L64记录（对于ILNPv6）。然后，主机知道远程主机支持ILNP。
b) When a host has I and L values for a remote host, the initial packet to initiate communication MUST contain a Nonce Header [RFC6746] [RFC6744] that indicates to the remote host that this packet is attempting to set up an ILNP session.
b) 当主机具有远程主机的I和L值时，启动通信的初始数据包必须包含一个Nonce头[RFC6746][RFC6744]，该头向远程主机指示此数据包正在尝试设置ILNP会话。
c) When a receiving host sees a Nonce Header, if it DOES support ILNP it will proceed to set up an ILNP session.
c) 当接收主机看到Nonce头时，如果它确实支持ILNP，它将继续设置ILNP会话。
d) When a receiving host sees a Nonce Header, if it DOES NOT support ILNP, it will reject the packet and this will be indicated to the sender through an ICMP message [RFC6743] [RFC6745]. Upon receiving the ICMP messages, the sender will re-initiate communication using standard IPv4 or IPv6.
d) 当接收主机看到Nonce报头时，如果它不支持ILNP，它将拒绝该数据包，并通过ICMP消息[RFC6743][RFC6745]向发送方指示。收到ICMP消息后，发送方将使用标准IPv4或IPv6重新启动通信。
Many observers in the community expect IPv4 to remain in place for a long time even though IPv6 has been available for over a decade. With a similar anticipation, it is likely that in the future there will be a mixed environment of both IP and ILNP hosts. Until there is a better understanding of the deployment and usage scenarios that will develop, it is not clear what interworking scenarios would be useful to define and focus on between IP and ILNP.
社区中的许多观察家预计IPv4将在很长一段时间内保持不变，尽管IPv6已经提供了十多年。出于类似的预期，未来可能会出现IP和ILNP主机的混合环境。在更好地理解将要开发的部署和使用场景之前，不清楚在IP和ILNP之间定义和关注哪些互通场景是有用的。
There are numerous security considerations for ILNP from an engineering viewpoint. Overall, ILNP and its capabilities are no less secure than IP and equivalent IP capabilities. In some cases, ILNP has the potential to be more secure, or offer security capability in a more harmonised manner, for example, with ILNP's use of IPsec in conjunction with multihoming and mobility. [RFC6740] describes several security considerations that apply to ILNP and is included here by reference.
从工程的角度来看，ILNP有许多安全考虑因素。总体而言，ILNP及其功能的安全性不亚于IP和同等IP功能。在某些情况下，ILNP有可能更安全，或以更协调的方式提供安全功能，例如，ILNP将IPsec与多宿和移动性结合使用。[RFC6740]描述了适用于ILNP的几个安全注意事项，并通过引用包含在此处。
ILNP offers an enhanced version of IP security (IPsec). The details of IP Security for ILNP were described separately above. All ILNP implementations MUST support the use of the IP Authentication Header (AH) for ILNP and also the IP Encapsulating Security Payload (ESP) for ILNP, but deployment and use of IPsec for ILNP remains a matter for local operational security policy.
ILNP提供了IP安全（IPsec）的增强版本。上面分别描述了ILNP的IP安全细节。所有ILNP实现都必须支持对ILNP使用IP身份验证头（AH）以及对ILNP使用IP封装安全负载（ESP），但对ILNP部署和使用IPsec仍然是本地操作安全策略的问题。
Separate documents propose a new IPv4 Option [RFC6746] and a new IPv6 Destination Option [RFC6744]. Each of these options can be used to carry an ILNP Nonce value end-to-end between communicating nodes. That nonce provides protection against off-path attacks on an ILNP session. These ILNP Nonce Options are used ONLY for ILNP and not for IP. The nonce values are exchanged in the initial packets of an ILNP session by including them in those initial/handshake packets.
单独的文件提出了一个新的IPv4选项[RFC6746]和一个新的IPv6目标选项[RFC6744]。这些选项中的每一个都可用于在通信节点之间端到端地携带ILNP Nonce值。该nonce为ILNP会话上的非路径攻击提供保护。这些ILNP Nonce选项仅用于ILNP，不用于IP。通过将nonce值包括在那些初始/握手数据包中，在ILNP会话的初始数据包中交换nonce值。
ALL ICMP Locator Update messages MUST include an ILNP Nonce Option and MUST include the correct ILNP Nonce value for the claimed sender and intended recipient of that ICMP Locator Update message. There are no exceptions to this rule. ICMP Locator Update messages MAY be protected by IPsec, but they still MUST include an ILNP Nonce Option and the ILNP Nonce Option still MUST include the correct ILNP Nonce value.
所有ICMP定位器更新消息必须包含ILNP Nonce选项，并且必须包含该ICMP定位器更新消息的声明发件人和预期收件人的正确ILNP Nonce值。这条规则没有例外。ICMP定位器更新消息可能受IPsec保护，但它们仍然必须包含ILNP Nonce选项，并且ILNP Nonce选项仍然必须包含正确的ILNP Nonce值。
When a node has an active ILNP session, and that node changes its Locator set, it SHOULD include the appropriate ILNP Nonce Option in the first few data packets sent using a new Locator value so that the recipient can validate the received data packets as valid (despite having an unexpected Source Locator value).
当节点具有活动的ILNP会话且该节点更改其定位器集时，它应在使用新定位器值发送的前几个数据包中包含适当的ILNP Nonce选项，以便接收方可以验证接收到的数据包是否有效（尽管具有意外的源定位器值）。
Any ILNP Locator Update messages received without an ILNP Nonce Option MUST be discarded as forgeries.
收到的任何没有ILNP Nonce选项的ILNP定位器更新消息都必须作为伪造消息丢弃。
Any ILNP Locator Update messages received with an ILNP Nonce Option, but that do NOT have the correct ILNP Nonce value inside the ILNP Nonce Option, MUST be discarded as forgeries.
使用ILNP Nonce选项接收的任何ILNP定位器更新消息，如果在ILNP Nonce选项中没有正确的ILNP Nonce值，则必须作为伪造消息丢弃。
When the claimed sender of an ICMP message is known to be a current ILNP correspondent of the recipient (e.g., has a valid, non-expired, ILCC entry), then any ICMP error messages from that claimed sender MUST include the ILNP Nonce Option and MUST include the correct ILNP Nonce value (i.e., correct for that sender recipient pair) in that ILNP Nonce Option.
如果已知ICMP消息的声明发件人是收件人的当前ILNP对应方（例如，具有有效、未过期的ILCC条目），则来自该声明发件人的任何ICMP错误消息必须包含ILNP Nonce选项，并且必须包含正确的ILNP Nonce值（即，对于该发送方-收件人对正确）在该ILNP Nonce选项中。
When the claimed sender of an ICMP error message is known to be a current ILNP correspondent of the recipient (e.g., has a valid, non-expired, ILCC entry), then any ICMP error messages from that claimed sender that are received without an ILNP Nonce Option MUST be discarded as forgeries.
当已知ICMP错误消息的声称发送方是接收方的当前ILNP对应方（例如，具有有效的、未过期的ILCC条目）时，则必须将来自声称发送方的任何ICMP错误消息作为伪造消息丢弃。
When the claimed sender of an ICMP error message is known to be a current ILNP correspondent of the recipient (e.g., has a valid, non-expired, ILCC entry), then any ICMP error messages from that claimed
当已知ICMP错误消息的声明发件人是收件人的当前ILNP通讯员（例如，具有有效、未过期的ILCC条目）时，则来自该声明发件人的任何ICMP错误消息
sender that contain an ILNP Nonce Option, but that do NOT have the correct ILNP Nonce value inside the ILNP Nonce Option, MUST be discarded as forgeries.
包含ILNP Nonce选项但在ILNP Nonce选项内没有正确的ILNP Nonce值的发送方必须作为伪造品丢弃。
ICMP messages (not including ICMP Locator Update messages) with a claimed sender that is NOT known to be a current ILNP correspondent of the recipient (e.g., does not have a valid, non-expired, ILCC entry) MAY include the ILNP Nonce Option, but, in this case, the ILNP Nonce Option is ignored by the recipient upon receipt, since the recipient has no way to authenticate the received ILNP Nonce value.
ICMP消息（不包括ICMP定位器更新消息）中声明的发送方不知道是接收方的当前ILNP对应方（例如，没有有效、未过期的ILCC条目），可能包括ILNP Nonce选项，但在这种情况下，接收方在收到时会忽略ILNP Nonce选项，因为收件人无法验证收到的ILNP Nonce值。
Received ICMP messages (not including ICMP Locator Update messages) with a claimed sender that is NOT known to be a current ILNP correspondent of the recipient (e.g., does not have a valid, non-expired, ILCC entry) do NOT require the ILNP Nonce Option because the security risks are no different than for deployed IPv4 and IPv6 -- provided that the received ICMP message is not an ICMP Locator Update message. Such ICMP messages (e.g., Destination Unreachable, Packet Too Big) might legitimately originate in an intermediate system along the path of an ILNP session. That intermediate system might not be ILNP capable. Even if ILNP capable itself, that intermediate system might not know which of the packets it forwards are part of ILNP sessions.
接收到的ICMP消息（不包括ICMP定位器更新消息），其声称的发送方不知道是接收方的当前ILNP通信方（例如，没有有效的、未过期的ILCC条目）不需要ILNP Nonce选项，因为安全风险与已部署的IPv4和IPv6相同——前提是收到的ICMP消息不是ICMP定位器更新消息。此类ICMP消息（例如，目的地不可到达、数据包太大）可能合法地起源于沿ILNP会话路径的中间系统。该中间系统可能不具备ILNP能力。即使中间系统本身具有ILNP功能，也可能不知道它转发的数据包中的哪些是ILNP会话的一部分。
When ILNP is in use, IP Security for ILNP also MAY be used to protect stronger protections for ICMP packets associated with an ILNP session. Even in this case, the ILNP Nonce Option also MUST be present and MUST contain the correct ILNP Nonce value. This simplifies packet processing and enables rapid discard of any forged packets from an off-path attacker that lack either the ILNP Nonce Option or the correct ILNP Nonce value -- without requiring computationally expensive IPsec processing. Received ICMP messages that are protected by ILNP IP Security, but fail the recipient's IPsec checks, MUST be dropped as forgeries. If a deployment chooses to use ILNP IPsec ESP to protect its ICMP messages and is NOT also using ILNP IPsec AH with those messages, then the ILNP Nonce Option MUST be placed in the ILNP packet after the ILNP IPsec ESP header, rather than before the ILNP IPsec ESP header, to ensure that the Nonce Option is protected in transit.
当使用ILNP时，ILNP的IP安全性也可用于保护与ILNP会话相关联的ICMP数据包的更强保护。即使在这种情况下，ILNP Nonce选项也必须存在，并且必须包含正确的ILNP Nonce值。这简化了数据包处理，并能够从缺少ILNP Nonce选项或正确的ILNP Nonce值的非路径攻击者处快速丢弃任何伪造数据包，而无需计算昂贵的IPsec处理。收到的受ILNP IP安全保护但未通过收件人IPsec检查的ICMP邮件必须作为伪造邮件删除。如果部署选择使用ILNP IPsec ESP来保护其ICMP消息，并且未对这些消息使用ILNP IPsec AH，则ILNP Nonce选项必须放在ILNP IPsec ESP头之后的ILNP数据包中，而不是放在ILNP IPsec ESP头之前，以确保Nonce选项在传输过程中受到保护。
Receipt of any ICMP message that is dropped or discarded as a forgery SHOULD cause the details of the received forged ICMP packet (e.g., Source and Destination Locators / Source and Destination Identifiers / Source and Destination IP Addresses, ICMP message type, receiving interface, receive date, receive time) to be logged in the receiving system's security logs. Implementations MAY rate-limit such logging
收到任何作为伪造而丢弃或丢弃的ICMP消息时，应显示收到的伪造ICMP数据包的详细信息（例如，源和目标定位器/源和目标标识符/源和目标IP地址、ICMP消息类型、接收接口、接收日期、接收时间）要记录在接收系统的安全日志中。实现可能会限制此类日志记录
in order to reduce operational risk of denial-of-service attacks on the system logging functions. The details of system logging are implementation specific.
为了降低拒绝服务攻击对系统日志功能的操作风险。系统日志记录的详细信息是特定于实现的。
The ILNP Communication Cache (ILCC) contains two unidirectional nonce values (one used in control messages sent by this node, a different one used to authenticate messages from the other node) for each active or recent ILNP session. The ILCC also contains the currently valid set of Locators and set of Identifiers for each correspondent node.
对于每个活动或最近的ILNP会话，ILNP通信缓存（ILCC）包含两个单向nonce值（一个用于此节点发送的控制消息，另一个用于验证来自另一个节点的消息）。ILCC还包含当前有效的定位器集和每个对应节点的标识符集。
If a received ILNP packet contains valid Identifier values and a valid Destination Locator, but contains a Source Locator value that is not present in the ILCC, the packet MUST be dropped as an invalid packet and a security event SHOULD be logged, UNLESS the packet also contains a Nonce Destination Option with the correct value used for packets from the node with that Source Identifier to this node. This prevents an off-path attacker from stealing an existing ILNP session.
如果接收到的ILNP数据包包含有效标识符值和有效目标定位器，但包含ILCC中不存在的源定位器值，则必须将该数据包作为无效数据包丢弃，并记录安全事件，除非数据包还包含一个Nonce Destination选项，该选项的值对于从具有该源标识符的节点到该节点的数据包是正确的。这可防止非路径攻击者窃取现有ILNP会话。
There are no additional privacy issues created by ILNP compared to IP. Please see Section 10 of [RFC6740] for more detailed discussion of Privacy Considerations.
与IP相比，ILNP不会产生额外的隐私问题。请参阅[RFC6740]第10节，了解隐私注意事项的更详细讨论。
ILNPv6 supports use of the IPv6 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC4941] to enable identity privacy (see also Section 2).
ILNPv6支持在IPv6[RFC4941]中使用IPv6隐私扩展进行无状态地址自动配置，以实现身份隐私（另请参见第2节）。
Location Privacy can be provided by locator rewriting techniques as described in Section 7 of [RFC6748].
位置隐私可以通过[RFC6748]第7节中描述的定位器重写技术提供。
A description of various possibilities for obtaining both identity privacy and location privacy with ILNP can be found in [BAK11].
[BAK11]中描述了通过ILNP获得身份隐私和位置隐私的各种可能性。
This section covers various operational considerations relating to ILNP, including potential session liveness and reachability considerations and Key Management considerations. Again, the situation is similar to IP, but it is useful to explain the issues in relation to ILNP nevertheless.
本节介绍与ILNP相关的各种操作注意事项，包括潜在的会话活跃性和可达性注意事项以及密钥管理注意事项。同样，情况类似于知识产权，但解释与ILNP相关的问题是有用的。
For bidirectional flows, such as a TCP/ILNP session, each node knows whether the current path in use is working by the reception of data packets, acknowledgements, or both. Therefore, as with TCP/IP, TCP/ILNP does not need special path probes. UDP/ILNP sessions with acknowledgements work similarly and do not need special path probes.
对于双向流，例如TCP/ILNP会话，每个节点通过接收数据包、确认或两者来知道当前使用的路径是否工作。因此，与TCP/IP一样，TCP/ILNP不需要特殊的路径探测。具有确认的UDP/ILNP会话的工作方式类似，不需要特殊的路径探测。
In the deployed Internet, the sending node for a UDP/IP session without acknowledgements does not know for certain that all packets are received by the intended receiving node. Such UDP/ILNP sessions have the same properties as UDP/IP sessions in this respect. The receiver(s) of such an UDP/ILNP session SHOULD send a gratuitous IP packet containing an ILNP Nonce Option to the sender, in order to enable the receiver to subsequently send ICMP Locator Updates if appropriate [RFC6744]. In this case, UDP/ILNP sessions fare better than UDP/IP sessions, still without using network path probes.
在已部署的Internet中，没有确认的UDP/IP会话的发送节点无法确定所有数据包是否已由预期的接收节点接收。在这方面，此类UDP/ILNP会话与UDP/IP会话具有相同的属性。这种UDP/ILNP会话的接收方应向发送方发送包含ILNP Nonce选项的免费IP数据包，以便在适当的情况下使接收方能够随后发送ICMP定位器更新[RFC6744]。在这种情况下，UDP/ILNP会话的性能优于UDP/IP会话，仍然不使用网络路径探测。
A mobile (or multihomed) node may change its connectivity more quickly than DNS can be updated. This situation is unlikely, particularly given the widespread use of link-layer mobility mechanisms (e.g., GSM, IEEE 802 bridging) in combination with network-layer mobility. However, the situation is equivalent to the situation where a traditional IP node is moving faster than the Mobile IPv4 or Mobile IPv6 agents/servers can be updated with the mobile node's new location. So the issue is not new in any way to ILNP. In all cases, Mobile IPv4 and Mobile IPv6 and ILNP, a node moving that quickly might be temporarily unreachable until it remains at a given network-layer location (e.g., IP subnetwork, ILNP Locator value) long enough for the location update mechanisms (for Mobile IPv4, for Mobile IPv6, or ILNP) to catch up.
移动（或多宿）节点更改其连接的速度可能快于DNS更新的速度。这种情况不太可能发生，特别是考虑到链路层移动性机制（如GSM、IEEE 802桥接）与网络层移动性的广泛使用。但是，这种情况相当于传统IP节点的移动速度快于移动IPv4或移动IPv6代理/服务器可以使用移动节点的新位置进行更新的情况。因此，这个问题对ILNP来说并不新鲜。在所有情况下，移动IPv4、移动IPv6和ILNP，一个快速移动的节点可能暂时无法访问，直到它停留在给定的网络层位置（例如，IP子网、ILNP定位器值）足够长的时间，以便位置更新机制（移动IPv4、移动IPv6或ILNP）跟上。
Another potential issue for IP is what is sometimes called "Path Liveness" or, in the case of ILNP, "Locator Liveness". This refers to the question of whether an IP packet with a particular destination Locator value will be able to reach the intended destination network or not, given that some otherwise valid paths might be unusable by the sending node (e.g., due to security policy or other administrative choice). In fact, this issue has existed in the IPv4 Internet for decades.
IP的另一个潜在问题是有时被称为“路径活跃度”，或者在ILNP的情况下称为“定位器活跃度”。这是指具有特定目的地定位器值的IP分组是否能够到达预期目的地网络的问题，因为发送节点可能无法使用某些其他有效路径（例如，由于安全策略或其他管理选择）。事实上，这个问题在IPv4互联网上已经存在了几十年。
For example, an IPv4 server might have multiple valid IP Addresses, each advertised to the world via a DNS A record. However, at a given moment in time, it is possible that a given sending node might not be able to use a given (otherwise valid) destination IPv4 address in an IP packet to reach that IPv4 server.
例如，IPv4服务器可能有多个有效IP地址，每个地址都通过DNS a记录向世界公布。但是，在给定的时刻，给定的发送节点可能无法使用IP数据包中的给定（否则有效）目标IPv4地址到达该IPv4服务器。
Indeed, for ILNPv6, as the ILNP packet reuses the IPv6 packet header and uses IPv6 routing prefixes as Locator values, such liveness considerations are no worse than they are for IPv6 today. For example, for IPv6, if a host, H, performs a DNS lookup for an FQDN for remote host F, and receives a AAAA RR with IPv6 address F_A, this does not mean necessarily that H can reach F on its F_A using its current connectivity, i.e., an IPv6 path may not be available from H to F at that point in time.
事实上，对于ILNPv6，由于ILNP数据包重用IPv6数据包头并使用IPv6路由前缀作为定位值，因此这种活跃性考虑并不比今天的IPv6更糟糕。例如，对于IPv6，如果主机H对远程主机F的FQDN执行DNS查找，并接收到带有IPv6地址F_a的AAAA RR，这并不一定意味着H可以使用其当前连接到达其F_a上的F，即，在该时间点，从H到F的IPv6路径可能不可用。
So we see that using an Identifier/Locator Split architecture does not create this issue, nor does it make this issue worse than it is with the deployed IPv4 Internet.
因此，我们看到，使用标识符/定位器拆分体系结构不会产生此问题，也不会使此问题比部署的IPv4 Internet更严重。
In ILNP, the same conceptual approach described in [RFC5534] (Locator Pair Exploration for SHIM6) can be reused. Alternatively, an ILNP node can reuse the existing IPv4 methods for determining whether a given path to the target destination is currently usable, for which existing methods leverage transport-layer session state information that the communicating end systems are already keeping for transport-layer protocol reasons.
在ILNP中，可以重用[RFC5534]（针对SHIM6的定位器对探索）中描述的相同概念方法。或者，ILNP节点可以重用现有的IPv4方法来确定到目标目的地的给定路径当前是否可用，对于这些方法，现有方法利用通信终端系统出于传输层协议原因已经保留的传输层会话状态信息。
Lastly, it is important to note that the ICMP Locator Update mechanism described in [RFC6743] [RFC6745] is a performance optimisation, significantly shortening the network-layer handoff time if/when a correspondent changes location. Architecturally, using ICMP is no different from using UDP, of course.
最后，重要的是要注意，[RFC6743][RFC6745]中描述的ICMP定位器更新机制是一种性能优化，当对应方改变位置时，显著缩短了网络层切换时间。当然，在体系结构上，使用ICMP与使用UDP没有什么不同。
ILNP potentially has advantages over either form of Mobile IP with respect to key management, given that ILNP is using Secure Dynamic DNS Update -- which capability is much more widely available today in deployed desktop and server environments (e.g., Microsoft Windows, Mac OS X, Linux, other UNIX), as well as being widely available today in deployed DNS server software (e.g., Microsoft and the freely available BIND) and appliances [LA06], than the security enhancements needed by either Mobile IPv4 or Mobile IPv6.
在密钥管理方面，ILNP可能比任何一种形式的移动IP都具有优势，因为ILNP使用的是安全的动态DNS更新，这一功能如今在已部署的桌面和服务器环境（如Microsoft Windows、Mac OS X、Linux和其他UNIX）中更为广泛，除了移动IPv4或移动IPv6所需的安全增强功能外，如今在部署的DNS服务器软件（如Microsoft和免费提供的BIND）和设备[LA06]中广泛可用。
In the IESG, there is work in progress that addresses use of DNS to support key management for entities having DNS Fully Qualified Domain Names.
在IESG中，正在进行的工作涉及使用DNS来支持具有DNS完全限定域名的实体的密钥管理。
As a special case, for the operational reasons described in [RFC6164], ILNPv6 deployments MAY continue to use classic IPv6 with a /127 routing prefix on router to router point-to-point links (e.g., SONET/SDH). Because an ILNPv6 packet and an IPv6 packet are
作为特例，出于[RFC6164]中所述的操作原因，ILNPv6部署可能会继续在路由器到路由器点到点链路（例如SONET/SDH）上使用带有/127路由前缀的经典IPv6。因为ILNPv6数据包和IPv6数据包是
indistinguishable for forwarding purposes to a transit router, this should not create any operational difficulty for ILNPv6 traffic travelling over such links.
对于转发到中转路由器的目的而言，这是无法区分的，这不应给通过此类链路传输的ILNPv6流量造成任何操作困难。
This section is concerned with support for using existing ("legacy") applications over ILNP, including both referrals and Application Programming Interfaces (APIs).
本节涉及在ILNP上使用现有（“遗留”）应用程序的支持，包括引用和应用程序编程接口（API）。
ILNP does NOT require that well-behaved applications be modified to use a new networking API, nor does it require applications be modified to use extensions to an existing API. Existing well-behaved IP applications should work over ILNP without modification using existing networking APIs.
ILNP不要求修改行为良好的应用程序以使用新的网络API，也不要求修改应用程序以使用对现有API的扩展。现有的性能良好的IP应用程序应该在ILNP上工作，而不需要使用现有的网络API进行修改。
The existing BSD Sockets API can continue to be used with ILNP underneath the API. That API can be implemented in a manner that hides the underlying protocol changes from the applications. For example, the combination of a Locator and an Identifier can be used with the API in the place of an IPv6 address.
现有的BSD套接字API可以继续与API下面的ILNP一起使用。该API可以以对应用程序隐藏底层协议更改的方式实现。例如，定位器和标识符的组合可以与API一起使用来代替IPv6地址。
So it is believed that existing IP address referrals can continue to work properly in most cases. For a rapidly moving target node, referrals might break in at least some cases. The potential for referral breakage is necessarily dependent upon the specific application and implementation being considered.
因此，人们相信，在大多数情况下，现有的IP地址转介可以继续正常工作。对于快速移动的目标节点，至少在某些情况下可能会中断转介。转诊中断的可能性必然取决于所考虑的具体应用和实施。
It is suggested, however, that a new, optional, more abstract, C language API be created so that new applications may avoid delving into low-level details of the underlying network protocols. Such an API would be useful today, even with the existing IPv4 and IPv6 Internet, whether or not ILNP were ever widely deployed.
然而，建议创建一个新的、可选的、更抽象的C语言API，以便新的应用程序可以避免深入底层网络协议的低级细节。即使在现有的IPv4和IPv6互联网上，这样的API在今天仍然是有用的，无论ILNP是否曾经被广泛部署。
Most existing Java APIs already use abstracted network programming interfaces, for example, in the java.Net.URL class. Because these APIs already hide the low-level network-protocol details from the applications, the applications using these APIs (and the APIs themselves) don't need any modification to work equally well with IPv4, IPv6, ILNP, and probably also HIP.
大多数现有Java API已经使用抽象的网络编程接口，例如，在Java.Net.URL类中。因为这些API已经对应用程序隐藏了底层网络协议的细节，所以使用这些API的应用程序（以及API本身）不需要任何修改就可以与IPv4、IPv6、ILNP以及HIP同样良好地工作。
Other programming languages, such as C++, python and ruby, also provide higher-level APIs that abstract away from sockets, even though sockets may be used beneath those APIs.
其他编程语言，如C++、Python和Ruby，也提供了更高级别的API，它们可以抽象出套接字，即使在API之下也可以使用套接字。
The approach proposed in [REFERRAL] appears to be very suitable for use with ILNP, in addition to being suitable for use with the deployed Internet. Protocols using that approach would not need modification to have their referrals work well with IPv4, IPv6, ILNP, and probably also other network protocols (e.g., HIP).
[参考]中提出的方法似乎非常适合与ILNP一起使用，此外还适合与部署的互联网一起使用。使用这种方法的协议不需要修改，就可以使其引用与IPv4、IPv6、ILNP以及其他网络协议（如HIP）一起正常工作。
A sensible approach to referrals is to use FQDNs, as is commonly done today with web URLs. This approach is highly portable across different network protocols, even with both the IPv4 Internet or the IPv6 Internet.
推荐的一种明智方法是使用FQDN，这是当今web URL的常见做法。这种方法在不同的网络协议之间具有高度的可移植性，即使是IPv4 Internet或IPv6 Internet。
[IEEE-EUI] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", <http://standards.ieee.org/ regauth/oui/tutorials/EUI64.html>, IEEE, Piscataway, NJ, USA, March 1997.
[IEEE-EUI]IEEE，“64位全局标识符（EUI-64）注册机构指南”<http://standards.ieee.org/ regauth/oui/tutorials/EUI64.html>，IEEE，皮斯卡塔韦，新泽西州，美国，1997年3月。
[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月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177]IAB和IESG，“IAB/IESG对站点IPv6地址分配的建议”，RFC3177，2001年9月。
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003.
[RFC3587]Hinden，R.，Deering，S.，和E.Nordmark，“IPv6全球单播地址格式”，RFC 3587，2003年8月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[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月。
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, March 2011.
[RFC6177]Narten，T.，Huston，G.和L.Roberts，“终端站点的IPv6地址分配”，BCP 157，RFC 6177，2011年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月。
[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月。
[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月。
[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月。
[BA11] Bhatti, S. and R. Atkinson, "Reducing DNS Caching", Proceedings of IEEE Global Internet Symposium (GI2011), Shanghai, P.R. China, 15 April 2011.
[BA11]Bhatti，S.和R.Atkinson，“减少DNS缓存”，IEEE全球互联网研讨会论文集（GI2011），中国上海，2011年4月15日。
[BAK11] Bhatti, S.N., Atkinson, R., and J. Klemets, "Integrating Challenged Networks", Proceedings of IEEE Military Communications Conference (MILCOM), IEEE, Baltimore, MD, USA, Nov 2011.
[BAK11]Bhatti，S.N.，Atkinson，R.，和J.Klemets，“整合挑战网络”，IEEE军事通信会议记录（MILCOM），IEEE，巴尔的摩，马里兰州，美国，2011年11月。
[LA06] Liu, C. and P. Albitz, "DNS and Bind", 5th Edition, O'Reilly & Associates, Sebastopol, CA, USA, 2006. ISBN 0-596-10057-4.
[LA06]Liu，C.和P.Albitz，“DNS和绑定”，第五版，O'Reilly&Associates，塞巴斯托波尔，加利福尼亚州，美国，2006年。ISBN 0-596-10057-4。
[PHG02] Pappas, A., Hailes, S. and R. Giaffreda, "Mobile Host Location Tracking through DNS", Proceedings of IEEE London Communications Symposium, IEEE, September 2002, London, England, UK.
[PHG02]Pappas，A.，Hailes，S.和R.Giaffreda，“通过DNS跟踪移动主机位置”，IEEE伦敦通信研讨会论文集，IEEE，2002年9月，英国伦敦。
[SBK02] Snoeren, A., Balakrishnan, H. and M. Frans Kaashoek, "Reconsidering Internet Mobility", Proceedings of 8th Workshop on Hot Topics in Operating Systems, IEEE, Elmau, Germany, May 2001.
[SBK02]Snoren，A.，Balakrishnan，H.和M.Frans Kaashoek，“重新考虑互联网移动性”，第八届操作系统热点研讨会论文集，IEEE，德国埃尔莫，2001年5月。
[REFERRAL] Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and K. Moore, "A Generic Referral Object for Internet Entities", Work in Progress, October 2009.
[转介]Carpenter，B.，Boucadair，M.，Halpern，J.，Jiang，S.，和K.Moore，“互联网实体的通用转介对象”，正在进行的工作，2009年10月。
[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月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4581] Bagnulo, M. and J. Arkko, "Cryptographically Generated Addresses (CGA) Extension Field Format", RFC 4581, October 2006.
[RFC4581]Bagnulo，M.和J.Arkko，“加密生成地址（CGA）扩展字段格式”，RFC 4581，2006年10月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", RFC 4982, July 2007.
[RFC4982]Bagnulo，M.和J.Arkko，“在加密生成地址（CGA）中支持多散列算法”，RFC 4982，2007年7月。
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, June 2009.
[RFC5534]Arkko，J.和I.van Beijnum，“IPv6多宿的故障检测和定位器对探测协议”，RFC 55342009年6月。
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-Router Links", RFC 6164, April 2011.
[RFC6164]Kohno，M.，Nitzan，B.，Bush，R.，Matsuzaki，Y.，Colitti，L.，和T.Narten，“在路由器间链路上使用127位IPv6前缀”，RFC 61642011年4月。
[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