Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6740 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6740 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
Identifier-Locator Network Protocol (ILNP) Architectural Description
标识符定位器网络协议（ILNP）体系结构描述
Abstract
摘要
This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This 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/rfc6740.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6740.
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 ...........................................5
1.2. History ....................................................6
1.3. Terminology ................................................7
2. Architectural Overview ..........................................7
2.1. Identifiers and Locators ...................................7
2.2. Deprecating IP Addresses ...................................9
2.3. Session Terminology .......................................10
2.4. Other Goals ...............................................12
3. Architectural Changes Introduced by ILNP .......................12
3.1. Identifiers ...............................................12
3.2. Locators ..................................................14
3.3. IP Address and Identifier-Locator Vector (I-LV) ...........16
3.4. Notation ..................................................16
3.5. Transport-Layer State and Transport Pseudo-Headers ........18
3.6. Rationale for This Document ...............................18
3.7. ILNP Multicasting .........................................19
4. ILNP Basic Connectivity ........................................20
4.1. Basic Local Configuration .................................20
4.2. I-L Communication Cache ...................................21
4.3. Packet Forwarding .........................................22
4.4. Packet Routing ............................................23
5. Multihoming and Multi-Path Transport ...........................24
5.1. Host Multihoming (H-MH) ...................................25
5.2. Support for Multi-Path Transport Protocols ................27
5.3. Site Multihoming (S-MH) ...................................28
5.4. Multihoming Requirements for Site Border Routers ..........29
6. Mobility .......................................................30
6.1. Mobility / Multihoming Duality in ILNP ....................31
6.2. Host Mobility .............................................32
1. Introduction ....................................................3
1.1. Document Roadmap ...........................................5
1.2. History ....................................................6
1.3. Terminology ................................................7
2. Architectural Overview ..........................................7
2.1. Identifiers and Locators ...................................7
2.2. Deprecating IP Addresses ...................................9
2.3. Session Terminology .......................................10
2.4. Other Goals ...............................................12
3. Architectural Changes Introduced by ILNP .......................12
3.1. Identifiers ...............................................12
3.2. Locators ..................................................14
3.3. IP Address and Identifier-Locator Vector (I-LV) ...........16
3.4. Notation ..................................................16
3.5. Transport-Layer State and Transport Pseudo-Headers ........18
3.6. Rationale for This Document ...............................18
3.7. ILNP Multicasting .........................................19
4. ILNP Basic Connectivity ........................................20
4.1. Basic Local Configuration .................................20
4.2. I-L Communication Cache ...................................21
4.3. Packet Forwarding .........................................22
4.4. Packet Routing ............................................23
5. Multihoming and Multi-Path Transport ...........................24
5.1. Host Multihoming (H-MH) ...................................25
5.2. Support for Multi-Path Transport Protocols ................27
5.3. Site Multihoming (S-MH) ...................................28
5.4. Multihoming Requirements for Site Border Routers ..........29
6. Mobility .......................................................30
6.1. Mobility / Multihoming Duality in ILNP ....................31
6.2. Host Mobility .............................................32
6.3. Network Mobility ..........................................34
6.4. Mobility Requirements for Site Border Routers .............36
6.5. Mobility with Multiple SBRs ...............................36
7. IP Security for ILNP ...........................................36
7.1. Adapting IP Security for ILNP .............................37
7.2. Operational Use of IP Security with ILNP ..................37
8. Backwards Compatibility and Incremental Deployment .............38
9. Security Considerations ........................................39
9.1. Authentication of Locator Updates .........................39
9.2. Forged Identifier Attacks .................................40
9.3. IP Security Enhancements ..................................42
9.4. DNS Security ..............................................42
9.5. Firewall Considerations ...................................42
9.6. Neighbour Discovery Authentication ........................42
9.7. Site Topology Obfuscation .................................43
10. Privacy Considerations ........................................43
10.1. Location Privacy .........................................43
10.2. Identity Privacy .........................................44
11. References ....................................................45
11.1. Normative References .....................................45
11.2. Informative References ...................................47
12. Acknowledgements ..............................................53
6.3. Network Mobility ..........................................34
6.4. Mobility Requirements for Site Border Routers .............36
6.5. Mobility with Multiple SBRs ...............................36
7. IP Security for ILNP ...........................................36
7.1. Adapting IP Security for ILNP .............................37
7.2. Operational Use of IP Security with ILNP ..................37
8. Backwards Compatibility and Incremental Deployment .............38
9. Security Considerations ........................................39
9.1. Authentication of Locator Updates .........................39
9.2. Forged Identifier Attacks .................................40
9.3. IP Security Enhancements ..................................42
9.4. DNS Security ..............................................42
9.5. Firewall Considerations ...................................42
9.6. Neighbour Discovery Authentication ........................42
9.7. Site Topology Obfuscation .................................43
10. Privacy Considerations ........................................43
10.1. Location Privacy .........................................43
10.2. Identity Privacy .........................................44
11. References ....................................................45
11.1. Normative References .....................................45
11.2. Informative References ...................................47
12. Acknowledgements ..............................................53
This document is part of the ILNP document set, which has had extensive review within the IRTF Routing RG. ILNP is one of the recommendations made by the RG Chairs. Separately, various refereed research papers on ILNP have also been published during this decade. So, the ideas contained herein have had much broader review than the IRTF Routing RG. The views in this document were considered controversial by the Routing RG, but the RG reached a consensus that the document still should be published. The Routing RG has had remarkably little consensus on anything, so virtually all Routing RG outputs are considered controversial.
本文件是ILNP文件集的一部分，已在IRTF路由RG内进行了广泛审查。ILNP是RG主席提出的建议之一。另外，在这十年中还发表了各种关于ILNP的参考研究论文。因此，本文所包含的思想比IRTF路由RG有更广泛的审查。本文件中的观点被路由RG认为是有争议的，但RG达成共识，即该文件仍应发布。路由RG在任何事情上几乎没有共识，因此几乎所有路由RG输出都被认为是有争议的。
At present, the Internet research and development community is exploring various approaches to evolving the Internet Architecture to solve a variety of issues including, but not limited to, scalability of inter-domain routing [RFC4984]. A wide range of other issues (e.g., site multihoming, node multihoming, site/subnet mobility, node mobility) are also active concerns at present. Several different classes of evolution are being considered by the Internet research and development community. One class is often called "Map and Encapsulate", where traffic would be mapped and then tunnelled through the inter-domain core of the Internet. Another class being
目前，互联网研发界正在探索各种方法来改进互联网体系结构，以解决各种问题，包括但不限于域间路由的可扩展性[RFC4984]。目前，广泛的其他问题（例如，站点多主、节点多主、站点/子网移动性、节点移动性）也是人们关注的热点。互联网研发界正在考虑几种不同的进化类型。一个类通常被称为“映射和封装”，在这个类中，流量将被映射，然后通过互联网的域间核心进行隧道传输。另一类是
considered is sometimes known as "Identifier/Locator Split". This document relates to a proposal that is in the latter class of evolutionary approaches.
有时被称为“标识符/定位器拆分”。本文件涉及后一类进化方法中的建议。
There has been substantial research relating to naming in the Internet through the years [IEN1] [IEN19] [IEN23] [IEN31] [IEN135] [RFC814] [RFC1498] [RFC2956]. Much of that research has indicated that binding the end-to-end transport-layer session state with a specific interface of a node at a specific location is undesirable, for example, creating avoidable issues for mobility, multihoming, and end-to-end security. More recently, mindful of that important prior work, and starting well before the Routing RG was re-chartered to focus on inter-domain routing scalability, the authors have been examining enhancements to certain naming aspects of the Internet Architecture. Separately, the Internet Architecture Board (IAB) recently considered the matter of Internet evolution, including naming [RFC6250].
在过去的几年中[IEN1][IEN1][IEN19][IEN23][IEN31][IEN135][RFC814][RFC1498][RFC2956]对互联网上的命名进行了大量研究。许多研究表明，将端到端传输层会话状态与特定位置的节点的特定接口绑定是不可取的，例如，这会为移动性、多归属和端到端安全带来可避免的问题。最近，考虑到这项重要的前期工作，并且在路由RG重新注册以关注域间路由可伸缩性之前，作者已经开始研究对Internet架构的某些命名方面的增强。另外，互联网架构委员会（IAB）最近审议了互联网发展问题，包括命名[RFC6250]。
Our ideas and progress so far are embodied in the ongoing definition of an experimental protocol that we call the Identifier-Locator Network Protocol (ILNP).
到目前为止，我们的想法和进展体现在正在进行的实验协议定义中，我们称之为标识符定位器网络协议（ILNP）。
Links to relevant material are all available at:
http://ilnp.cs.st-andrews.ac.uk/
Links to relevant material are all available at:
http://ilnp.cs.st-andrews.ac.uk/
At the time of writing, the main body of peer-reviewed research from which the ideas in this and the accompanying documents draw is given in [LABH06], [ABH07a], [ABH07b], [ABH08a], [ABH08b], [ABH09a], [ABH09b], [RAB09], [ABH10], [RB10], [BA11], [BAK11], and [BA12].
在撰写本报告时，同行评议研究的主体（本文件和随附文件中的思想来源于此）见[LABH06]、[ABH07a]、[ABH07b]、[ABH08a]、[ABH08b]、[ABH09a]、[ABH09b]、[RAB09]、[ABH10]、[RB10]、[BA11]、[BA11]和[BA12]。
In this document, we:
在本文件中，我们：
a) describe the architectural concepts behind ILNP and how various ILNP capabilities operate: this document deliberately focuses on describing the key architectural changes that ILNP introduces and defers engineering discussion to separate documents.
a) 描述ILNP背后的体系结构概念以及各种ILNP功能是如何运作的：本文档有意重点描述ILNP引入的关键体系结构更改，并将工程讨论推迟到单独的文档中。
Other documents (listed below):
其他文件（如下所列）：
b) show how functions based on ILNP would be realised on today's Internet by proposing an instance of ILNP based on IPv6, which we call ILNPv6 (there is also a document describing ILNPv4, which is how ILNP could be applied to IPv4).
b) 通过提出一个基于IPv6的ILNP实例（我们称之为ILNPv6），展示基于ILNP的功能将如何在当今的互联网上实现（还有一个文档描述了ILNPv4，它是如何将ILNP应用于IPv4的）。
c) discuss salient operational and engineering issues impacting the deployment of ILNPv6 and the impact on the Internet.
c) 讨论影响ILNPv6部署的突出运营和工程问题以及对互联网的影响。
d) give architectural descriptions of optional advanced capabilities in advanced deployments based on the ILNP approach.
d) 给出基于ILNP方法的高级部署中可选高级功能的体系结构描述。
This document describes the architecture for the Identifier-Locator Network Protocol (ILNP) including concept of operations. The authors recommend reading and understanding this document as the starting point to understanding ILNP.
本文档描述了标识符定位器网络协议（ILNP）的体系结构，包括操作概念。作者建议阅读和理解本文件作为理解ILNP的起点。
The ILNP architecture can have more than one engineering instantiation. For example, one can imagine a "clean-slate" engineering design based on the ILNP architecture. In separate documents, we describe two specific engineering instances of ILNP. The term "ILNPv6" refers precisely to an instance of ILNP that is based upon, and backwards compatible with, IPv6. The term "ILNPv4" refers precisely to an instance of ILNP that is based upon, and backwards compatible with, IPv4.
ILNP体系结构可以有多个工程实例。例如，可以想象基于ILNP体系结构的“干净板岩”工程设计。在单独的文档中，我们描述了ILNP的两个具体工程实例。术语“ILNPv6”正是指基于IPv6并向后兼容IPv6的ILNP实例。术语“ILNPv4”正是指基于IPv4并向后兼容IPv4的ILNP实例。
Many engineering aspects common to both ILNPv4 and ILNPv6 are described in [RFC6741]. A full engineering specification for either ILNPv6 or ILNPv4 is beyond the scope of this document.
[RFC6741]中描述了ILNPv4和ILNPv6共同的许多工程方面。ILNPv6或ILNPv4的完整工程规范超出了本文件的范围。
Readers are referred to other related ILNP documents for details not described here:
读者可参考其他相关ILNP文件，了解此处未描述的详细信息：
a) [RFC6741] describes engineering and implementation considerations that are common to both ILNPv4 and ILNPv6.
a) [RFC6741]描述了ILNPv4和ILNPv6通用的工程和实施注意事项。
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 the 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的操作或使用不需要这些，而是作为附加选项提供的。
In 1977, Internet researchers at University College London wrote the first Internet Experiment Note (IEN), which discussed issues with the interconnection of networks [IEN1]. This identified the inclusion of network-layer addresses in the transport-layer session state (e.g., TCP checksum) as a significant problem for mobile and multihomed nodes and networks. It also proposed separation of identity from location as a better approach to take when designing the TCP/IP protocol suite. Unfortunately, that separation did not occur, so the deployed IPv4 and IPv6 Internet entangles upper-layer protocols (e.g., TCP, UDP) with network-layer routing and topology information (e.g., IP Addresses) [IEN1] [RFC768] [RFC793].
1977年，伦敦大学学院的互联网研究人员撰写了第一份互联网实验笔记（IEN），其中讨论了网络互连的问题[IEN1]。这将网络层地址包含在传输层会话状态（例如TCP校验和）中确定为移动和多宿节点及网络的一个重要问题。它还建议在设计TCP/IP协议套件时，将身份与位置分离作为一种更好的方法。不幸的是，这种分离没有发生，因此部署的IPv4和IPv6 Internet将上层协议（如TCP、UDP）与网络层路由和拓扑信息（如IP地址）[IEN1][RFC768][RFC793]纠缠在一起。
The architectural concept behind ILNP derives from a June 1994 note by Bob Smart to the IETF SIPP WG mailing list [SIPP94]. In January 1995, Dave Clark sent a similar note to the IETF IPng WG mailing list, suggesting that the IPv6 address be split into separate Identifier and Locator fields [IPng95].
ILNP背后的架构概念源自1994年6月Bob Smart给IETF SIPP WG邮件列表[SIPP94]的一份说明。1995年1月，Dave Clark向IETF IPng WG邮件列表发送了一份类似的通知，建议将IPv6地址拆分为单独的标识符和定位器字段[IPng95]。
Afterwards, Mike O'Dell pursued this concept in Internet-Drafts describing "8+8" [8+8] and "GSE" (Global, Site, and End-system) [GSE]. More recently, the IRTF Namespace Research Group (NSRG) studied this matter around the turn of the century. Unusually for an IRTF RG, the NSRG operated on the principle that unanimity was required for the NSRG to make a recommendation. Atkinson was a member of the IRTF NSRG. At least one other protocol, the Host Identity Protocol (HIP), also derives in part from the IRTF NSRG studies (and related antecedent work). This current proposal differs from O'Dell's work in various ways, notably in that it does not require deployment or use of Locator rewriting.
后来，迈克·奥戴尔在描述“8+8”[8+8]和“GSE”（全球、站点和终端系统）[GSE]的互联网草稿中提出了这一概念。最近，IRTF名称空间研究小组（NSRG）在世纪之交研究了这一问题。对于IRTF RG来说，不同寻常的是，国家战略参考小组的运作原则是，国家战略参考小组提出建议需要一致同意。阿特金森是IRTF NSRG的成员。至少还有一种协议，即主机标识协议（HIP），也部分源自IRTF NSRG研究（以及相关的前期工作）。目前的提议与O'Dell的工作在许多方面不同，特别是它不需要部署或使用定位器重写。
The key idea proposed for ILNP is to directly and specifically change the overloaded semantics of the IP Address. The Internet community has indicated explicitly, several times, that this use of overloaded semantics is a significant problem with the use of the Internet protocol today [RFC1498] [RFC2101] [RFC2956] [RFC4984].
ILNP的关键思想是直接而具体地改变IP地址的重载语义。互联网社区多次明确表示，这种使用重载语义的方式是当今互联网协议使用中的一个重大问题[RFC1498][RFC2101][RFC2956][RFC4984]。
While the research community has made a number of proposals that could provide solutions, so far there has been little progress on changing the status quo.
虽然研究界已经提出了一些可以提供解决方案的建议，但到目前为止，在改变现状方面进展甚微。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
ILNP takes a different approach to naming of communication objects within the network stack. Two new data types are introduced which subsume the role of the IP Address at the network and transport layers in the current IP architecture.
ILNP采用不同的方法命名网络堆栈中的通信对象。引入了两种新的数据类型，它们包含了当前IP体系结构中网络和传输层IP地址的作用。
ILNP explicitly replaces the use of IP Addresses with two distinct name spaces, each having distinct and different semantics:
ILNP使用两个不同的名称空间显式替换IP地址的使用，每个名称空间具有不同的语义：
a) Identifier: a non-topological name for uniquely identifying a node.
a) 标识符：用于唯一标识节点的非拓扑名称。
b) Locator: a topologically bound name for an IP subnetwork.
b) 定位器：IP子网的拓扑绑定名称。
The use of these two new namespaces in comparison to IP is given in Table 1. The table shows where existing names are used for state information in end-systems or protocols.
表1给出了这两个新名称空间相对于IP的使用情况。该表显示了现有名称用于终端系统或协议中状态信息的位置。
Layer | IP | ILNP
---------------+----------------------+---------------
Application | FQDN or IP Address | FQDN
Transport | IP Address | Identifier
Network | IP Address | Locator
Physical i/f | IP Address | MAC address
---------------+----------------------+---------------
Layer | IP | ILNP
---------------+----------------------+---------------
Application | FQDN or IP Address | FQDN
Transport | IP Address | Identifier
Network | IP Address | Locator
Physical i/f | IP Address | MAC address
---------------+----------------------+---------------
FQDN = Fully Qualified Domain Name i/f = interface MAC = Media Access Control
FQDN=完全限定域名i/f=接口MAC=媒体访问控制
Table 1: Use of Names for State Information in Various Communication Layers for IP and ILNP
表1:IP和ILNP不同通信层中状态信息名称的使用
As shown in Table 1, if an application uses a Fully Qualified Domain Name at the application-layer, rather than an IP Address or other lower-layer identifier, then the application perceives no architectural difference between IP and ILNP. We call such applications "well-behaved" with respect to naming as use of the FQDN at the application-layer is recommended in [RFC1958]. Some other applications also avoid use of IP Address information within the application-layer protocol; we also consider these applications to be "well-behaved". Any well-behaved application should be able to operate on ILNP without any changes. Note that application-level use of IP Addresses includes application-level configuration information, e.g., Apache web server (httpd) configuration files make extensive use of IP Addresses as a form of identity.
如表1所示，如果应用程序在应用程序层使用完全限定的域名，而不是IP地址或其他较低层标识符，则应用程序认为IP和ILNP之间没有架构差异。由于[RFC1958]中建议在应用层使用FQDN，因此我们称此类应用程序在命名方面“表现良好”。其他一些应用程序也避免在应用层协议中使用IP地址信息；我们也认为这些应用程序是“行为良好”的。任何表现良好的应用程序都应该能够在ILNP上运行，而无需任何更改。请注意，IP地址的应用程序级使用包括应用程序级配置信息，例如，Apache web server（httpd）配置文件广泛使用IP地址作为身份的一种形式。
ILNP does not require applications to be rewritten to use a new Networking Application Programming Interface (API). So existing well-behaved IP-based applications should be able to work over ILNP as is.
ILNP不需要重写应用程序以使用新的网络应用程序编程接口（API）。因此，现有性能良好的基于IP的应用程序应该能够按原样在ILNP上工作。
In ILNP, transport-layer protocols use only an end-to-end, non-topological node Identifier in any transport-layer session state. It is important to note that the node Identifier names the node, not a specific interface of the node. In this way, it has different semantics and properties than either the IPv4 address, the IPv6 address, or the IPv6 interface identifier [RFC791] [RFC4291].
在ILNP中，传输层协议在任何传输层会话状态下仅使用端到端、非拓扑节点标识符。请务必注意，节点标识符命名节点，而不是节点的特定接口。这样，它的语义和属性与IPv4地址、IPv6地址或IPv6接口标识符[RFC791][RFC4291]不同。
The use of the ILNP Identifier value within application-layer protocols is not recommended. Instead, the use of either a FQDN or some different topology-independent namespace is recommended.
不建议在应用层协议中使用ILNP标识符值。相反，建议使用FQDN或其他与拓扑无关的命名空间。
At the network-layer, Locator values, which have topological significance, are used for routing and forwarding of ILNP packets, but Locators are not used in upper-layer protocols.
在网络层，具有拓扑意义的定位器值用于ILNP数据包的路由和转发，但在上层协议中不使用定位器。
As well as the new namespaces, another significant difference in ILNP, as shown in Table 1, is that there is no binding of a routable name to an interface, or Sub-Network Point of Attachment (SNPA), as there is in IP. The existence of such a binding in IP effectively binds transport protocol flows to a specific, single interface on a node. Also, applications that include IP Addresses in their application-layer session state effectively bind to a specific, single interface on a node [RFC2460] [RFC6724].
与新名称空间一样，ILNP中的另一个显著区别（如表1所示）是，没有像IP中那样将可路由名称绑定到接口或子网连接点（SNPA）。IP中这种绑定的存在有效地将传输协议流绑定到节点上特定的单个接口。此外，在应用层会话状态中包含IP地址的应用程序有效地绑定到节点[RFC2460][RFC6724]上的特定单个接口。
In ILNP, dynamic bindings exist between Identifier values and associated Locator values, as well as between {Identifier, Locator} pairs and (physical or logical) interfaces on the node.
在ILNP中，动态绑定存在于标识符值和关联的定位器值之间，以及节点上的{Identifier，Locator}对和（物理或逻辑）接口之间。
This change enhances the Internet Architecture by adding crisp and clear semantics for the Identifier and for the Locator, removing the overloaded semantics of the IP Address [RFC1992] [RFC4984], by updating end-system protocols, but without requiring any router or backbone changes. In ILNP, the closest approximation to an IP Address is an I-L Vector (I-LV), which is a given binding between an Identifier and Locator pair, written as [I, L]. I-LVs are discussed in more detail below.
这一变化通过为标识符和定位器添加清晰明了的语义，通过更新终端系统协议消除了IP地址[RFC1992][RFC4984]的过载语义，但不需要任何路由器或主干网更改，从而增强了Internet体系结构。在ILNP中，最接近IP地址的是I-L向量（I-LV），它是标识符和定位器对之间的给定绑定，写为[I，L]。下文将更详细地讨论I-LV。
Where, today, IP packets have:
其中，今天的IP数据包具有：
- Source IP Address, Destination IP Address
- 源IP地址，目标IP地址
instead, ILNP packets have:
相反，ILNP数据包具有：
- source I-LV, destination I-LV
- 源I-LV，目标I-LV
However, it must be emphasised that the I-LV and the IP Address are *not* equivalent.
但是，必须强调的是，I-LV和IP地址是*不*等效的。
With these naming enhancements, we will improve the Internet Architecture by adding explicit harmonised support for many functions, such as multihoming, mobility, and IPsec.
通过这些命名增强，我们将通过添加对许多功能的明确协调支持来改进Internet体系结构，如多归属、移动性和IPsec。
ILNP places an explicit Locator and Identifier in the IP packet header, replacing the usual IP Address. Locators are tied to the topology of the network. They may change frequently, as the node or site changes its network connectivity. The node Identifier is normally much more static and remains constant throughout the life of a given transport-layer session, and frequently much longer. However, there are various options for Identifier values, as discussed in [RFC6741]. The way that I-LVs are encoded into packet headers is different for IPv4 and IPv6, as explained in [RFC6741].
ILNP在IP数据包报头中放置一个显式定位器和标识符，以替换通常的IP地址。定位器与网络拓扑相关联。当节点或站点更改其网络连接时，它们可能会频繁更改。节点标识符通常更为静态，在给定传输层会话的整个生命周期内保持不变，并且通常更长。但是，如[RFC6741]中所述，标识符值有多种选项。对于IPv4和IPv6，I-LV编码到数据包头中的方式不同，如[RFC6741]中所述。
Identifiers and Locators for hosts are advertised explicitly in DNS, through the use of new Resource Records (RRs). This is a logical and reasonable use of DNS, completely analogous to the capability that DNS provides today. At present, among other current uses, the DNS is used to map from an FQDN to a set of addresses. As ILNP replaces IP Addresses with Identifiers and Locators, it is then clearly rational to use the DNS to map an FQDN to a set of Identifiers and a set of Locators for a node.
主机的标识符和定位器通过使用新资源记录（RRs）在DNS中显式公布。这是DNS的一种合乎逻辑的合理使用，与DNS今天提供的功能完全类似。目前，在其他当前用途中，DNS用于从FQDN映射到一组地址。由于ILNP将IP地址替换为标识符和定位器，因此使用DNS将FQDN映射到节点的一组标识符和定位器显然是合理的。
The presence of ILNP Locators and Identifiers in the DNS for a DNS owner name is an indicator to correspondents that the correspondents can try to establish an ILNP-based transport-layer session with that DNS owner name.
DNS中DNS所有者名称的ILNP定位器和标识符的存在是通信方可以尝试使用该DNS所有者名称建立基于ILNP的传输层会话的指示符。
Specifically in response to [RFC4984], ILNP improves routing scalability by helping multihomed sites operate effectively with Provider Aggregated (PA) address prefixes. Many multihomed sites today request provider-independent (PI) address prefixes so they can provide session survivability despite the failure of one or more access links or Internet Service Providers (ISPs). ILNP provides this transport-layer session survivability by having a provider-independent Node Identifier (NID) value that is free of any topological semantics. This NID value can be bound dynamically to a Provider Aggregated Locator (L) value, the latter being a topological name, i.e., a PA network prefix. By allowing correspondents to change arbitrarily among multiple PA Locator values, survivability is enabled as changes to the L values need not disrupt transport-layer sessions. In turn, this allows an ILNP multihomed site to have both the full transport-layer and full network-layer session resilience that is today offered by PI addressing while using the equivalent of PA addressing. In turn, this eliminates the current need to use globally visible PI routing prefixes for each multihomed site.
特别是为了响应[RFC4984]，ILNP通过使用提供商聚合（PA）地址前缀帮助多宿站点有效运行，从而提高了路由可伸缩性。如今，许多多址站点请求独立于提供商（PI）的地址前缀，以便在一个或多个访问链路或互联网服务提供商（ISP）出现故障时仍能提供会话生存能力。ILNP通过具有不受任何拓扑语义影响的独立于提供者的节点标识符（NID）值来提供这种传输层会话生存能力。此NID值可以动态绑定到提供者聚合定位器（L）值，后者是拓扑名称，即PA网络前缀。通过允许通信者在多个PA定位器值之间任意更改，可生存性得以实现，因为L值的更改不需要中断传输层会话。反过来，这允许ILNP多址站点同时具有完整的传输层和完整的网络层会话恢复能力，这是目前由PI寻址提供的，同时使用相当于PA寻址的功能。反过来，这消除了当前对每个多址站点使用全局可见PI路由前缀的需要。
To improve clarity and readability of the several ILNP specification documents, this section defines the terms "network-layer session" and "transport-layer session" both for IP-based networks and ILNP-based networks.
为了提高几个ILNP规范文档的清晰度和可读性，本节定义了基于IP网络和基于ILNP网络的术语“网络层会话”和“传输层会话”。
Today, network-layer IP sessions have 2 components:
如今，网络层IP会话有两个组件：
- Source IP Address (A_S) - Destination IP Address (A_D)
- 源IP地址（A_S）-目标IP地址（A_D）
For example, a tuple for an IP layer session would be:
例如，IP层会话的元组为：
<IP: A_S, A_D>
<IP: A_S, A_D>
Instead, network-layer ILNP sessions have 4 components:
相反，网络层ILNP会话有4个组件：
- Source Locator(s) (L_S) - Source Identifier(s) (I_S) - Destination Locator(s) (L_D) - Destination Identifier(s) (L_S)
- 源定位器（L_s）-源标识符（I_s）-目标定位器（L_D）-目标标识符（L_s）
and a tuple for an ILNP session would be:
ILNP会话的元组是：
<ILNP: I_S, L_S, I_D, L_D>
<ILNP: I_S, L_S, I_D, L_D>
The phrase "ILNP session" refers to an ILNP-based network-layer session, having the 4 components in the definition above.
短语“ILNP会话”指基于ILNP的网络层会话，具有上述定义中的4个组件。
For engineering efficiency, multiple transport-layer sessions between a pair of ILNP correspondents normally share a single ILNP session (I-LV pairs and associated Nonce values). Also, for engineering convenience (and to cope with situation where different nodes, at different locations, might use the same I values), in the specific implementation of ILNPv6 and ILNPv4, we define the use of nonce values:
为了提高工程效率，一对ILNP对应者之间的多个传输层会话通常共享一个ILNP会话（I-LV对和相关的Nonce值）。此外，为了工程上的方便（以及应对不同位置的不同节点可能使用相同的I值的情况），在ILNPv6和ILNPv4的具体实现中，我们定义了nonce值的使用：
- Source-to-destination Nonce value (N_S) - Destination-to-source Nonce value (N_D)
- 源到目标Nonce值（N_S）-目标到源Nonce值（N_D）
These are explained in more detail in [RFC6741], with [RFC6744] for ILNPv6 and [RFC6746] for ILNPv4.
[RFC6741]对其进行了更详细的解释，其中[RFC6744]用于ILNPv6，[RFC6746]用于ILNPv4。
Today, transport-layer sessions using IP include these 5 components:
如今，使用IP的传输层会话包括以下5个组件：
- Source IP Address (A_S) - Destination IP Address (A_D) - Transport-layer protocol (e.g., UDP, TCP, SCTP) - Source transport-layer port number (P_S) - Destination transport-layer port number (P_D)
- 源IP地址（A_S）-目标IP地址（A_D）-传输层协议（如UDP、TCP、SCTP）-源传输层端口号（P_S）-目标传输层端口号（P_D）
For example, a TCP tuple would be:
例如，TCP元组可能是：
<TCP: P_S, P_D, A_S, A_D>
<TCP: P_S, P_D, A_S, A_D>
Instead, transport-layer sessions using ILNP include these 5 components:
相反，使用ILNP的传输层会话包括以下5个组件：
- Source Identifier (I_S) - Destination Identifier (I_D) - Transport-layer protocol (e.g., UDP, TCP, SCTP) - Source transport-layer port number (P_S) - Destination transport-layer port number (P_D)
- 源标识符（I_S）-目标标识符（I_D）-传输层协议（如UDP、TCP、SCTP）-源传输层端口号（P_S）-目标传输层端口号（P_D）
and an example tuple:
和一个示例元组：
<TCP: P_S, P_D, I_S, I_D>
<TCP: P_S, P_D, I_S, I_D>
While we seek to make significant enhancements to the current Internet Architecture, we also wish to ensure that instantiations of ILNP are:
在我们寻求对当前互联网体系结构进行重大改进的同时，我们还希望确保ILNP的实例化：
a) Backwards compatible: implementations of ILNP should be able to work with existing IPv6 or IPv4 deployments, without requiring application changes.
a) 向后兼容：ILNP的实现应该能够与现有IPv6或IPv4部署协同工作，而无需更改应用程序。
b) Incrementally deployable: to deploy an implementation of ILNP, changes to the network nodes should only be for those nodes that choose to use ILNP. The use of ILNP by some nodes does not require other nodes (that do not use ILNP) to be upgraded.
b) 增量部署：要部署ILNP的实现，对网络节点的更改应该只针对选择使用ILNP的节点。某些节点使用ILNP不需要升级其他节点（不使用ILNP）。
In this section, we describe the key changes that are made to the current Internet Architecture. These key changes impact end-systems, rather than routers.
在本节中，我们将描述对当前Internet体系结构所做的关键更改。这些关键变化影响终端系统，而不是路由器。
Identifiers, also called Node Identifiers (NIDs), are non-topological values that identify an ILNP node. A node might be a physical node or a virtual node. For example, a single physical device might contain multiple independent virtual nodes. Alternately, a single virtual device might be composed from multiple physical devices. In the case of a Multi-Level Secure (MLS) system [DIA] [DoD85] [DoD87] [RFC5570], each valid Sensitivity Label of that system might be a separate virtual node.
标识符，也称为节点标识符（NID），是标识ILNP节点的非拓扑值。节点可以是物理节点或虚拟节点。例如，单个物理设备可能包含多个独立的虚拟节点。或者，单个虚拟设备可能由多个物理设备组成。在多级安全（MLS）系统[DIA][DoD85][DoD87][RFC5570]的情况下，该系统的每个有效灵敏度标签可能是一个单独的虚拟节点。
A node MAY have multiple Identifier values associated with it, which MAY be used concurrently.
一个节点可以具有多个与其关联的标识符值，这些标识符值可以同时使用。
In normal operation, when a node is responding to a received ILNP packet that creates a new network-layer session, the correct NID value to use for that network-layer session with that correspondent node will be learned from the received ILNP packet.
在正常操作中，当节点响应接收到的创建新网络层会话的ILNP数据包时，将从接收到的ILNP数据包中学习用于与对应节点的网络层会话的正确NID值。
In normal operation, when a node is initiating communication with a correspondent node, the correct I value to use for that session with that correspondent node will be learned either through the application-layer naming, through DNS name resolution, or through
在正常操作中，当节点开始与对应节点通信时，将通过应用层命名、DNS名称解析或
some alternative name resolution system. Another option is an application may be able to select different I values directly -- as Identifiers are visible above the network layer via the transport protocol.
一些替代名称解析系统。另一个选项是应用程序可以直接选择不同的I值——因为标识符通过传输协议在网络层上方可见。
Once a Node Identifier (NID) value has been used to establish a transport-layer session, that Node Identifier value forms part of the end-to-end (invariant) transport-layer session state and so MUST remain fixed for the duration of that session. This means, for example, that throughout the duration of a given TCP session, the Source Node Identifier and Destination Node Identifier values will not change.
一旦使用节点标识符（NID）值来建立传输层会话，该节点标识符值将构成端到端（不变）传输层会话状态的一部分，因此在该会话期间必须保持固定。这意味着，例如，在给定TCP会话的整个持续时间内，源节点标识符和目标节点标识符值不会改变。
In normal operation, a node will not change its set of valid Identifier values frequently. However, a node MAY change its set of valid Identifier values over time, for example, in an effort to provide identity obfuscation, while remaining subject to the architectural rule of the preceding paragraph. When a node has more than one Node Identifier value concurrently, the node might have multiple concurrent ILNP sessions with some correspondent node, in which case Node Identifier values MAY differ between the different concurrent ILNP sessions.
在正常操作中，节点不会频繁更改其有效标识符值集。然而，节点可以随着时间的推移改变其有效标识符值集，例如，为了提供身份混淆，同时仍受上一段的体系结构规则的约束。当一个节点同时具有多个节点标识符值时，该节点可能与某个对应节点具有多个并发ILNP会话，在这种情况下，不同并发ILNP会话之间的节点标识符值可能不同。
ILNP Identifiers have the same syntax as IPv6 interface identifiers [RFC4291], based on the EUI-64 format [IEEE-EUI], which helps with backwards compatibility. There is no semantic equivalent to an ILNP Identifier in IPv4 or IPv6 today.
ILNP标识符与基于EUI-64格式[IEEE-EUI]的IPv6接口标识符[RFC4291]具有相同的语法，这有助于向后兼容。目前，IPv4或IPv6中没有与ILNP标识符等价的语义。
The Modified EUI-64 syntax used by both ILNP Identifiers and IPv6 interface identifiers contains a bit indicating whether the value has global scope or local scope [IEEE-EUI] [RFC4291]. ILNP Identifiers have either global scope or local scope. If they have global scope, they SHOULD be globally unique.
ILNP标识符和IPv6接口标识符使用的修改后的EUI-64语法包含一个位，指示该值是具有全局作用域还是具有局部作用域[IEEE-EUI][RFC4291]。ILNP标识符具有全局范围或局部范围。如果它们具有全局范围，则它们应该是全局唯一的。
Regardless of whether an Identifier is global scope or local scope, an Identifier MUST be unique within the scope of a given Locator value to which it is bound for a given ILNP session or packet flow. As an example, with ILNPv6, the ordinary IPv6 Neighbour Discovery (ND) processes ensure that this is true, just as ND ensures that no two IPv6 nodes on the same IPv6 subnetwork have the same IPv6 address at the same time.
无论标识符是全局作用域还是局部作用域，标识符在给定的定位器值范围内必须是唯一的，该定位器值与给定的ILNP会话或数据包流绑定。例如，对于ILNPv6，普通IPv6邻居发现（ND）过程确保这一点，正如ND确保同一IPv6子网上的两个IPv6节点不会同时具有相同的IPv6地址一样。
Both the IEEE EUI-64 specification and the Modified EUI-64 syntax also has a 'Group' bit [IEEE-EUI] [RFC4291]. For both ILNP node Identifiers and also IPv6 interface identifiers, this Group bit is set to 0.
IEEE EUI-64规范和修改后的EUI-64语法也有一个“组”位[IEEE-EUI][RFC4291]。对于ILNP节点标识符和IPv6接口标识符，此组位设置为0。
Unicast ILNP Identifier values name the node, rather than naming a specific interface on that node. So ILNP Identifiers have different semantics than IPv6 interface identifiers.
单播ILNP标识符值命名节点，而不是命名该节点上的特定接口。因此，ILNP标识符与IPv6接口标识符具有不同的语义。
Locators are topologically significant names, analogous to (sub)network routing prefixes. The Locator names the IP subnetwork that a node is connected to. ILNP neither prohibits nor mandates in-transit modification of Locator values.
定位器是具有拓扑意义的名称，类似于（子）网络路由前缀。定位器命名节点连接到的IP子网。ILNP既不禁止也不强制在传输过程中修改定位器值。
A host MAY have several Locators at the same time, for example, if it has a single network interface connected to multiple subnetworks (e.g., VLAN deployments on wired Ethernet) or has multiple interfaces each on a different subnetwork. Locator values normally have Locator Preference Indicator (LPI) values associated with them. These LPIs indicate that a specific Locator value has higher or lower preference for use at a given time. Local LPI values may be changed through local policy or via management interfaces. Remote LPI values are normally learned from the DNS, but the local copy of a remote LPI value might be modified by local policy relating to preferred paths or prefixes.
例如，如果主机具有连接到多个子网的单个网络接口（例如，有线以太网上的VLAN部署），或在不同子网上具有多个接口，则主机可能同时具有多个定位器。定位器值通常具有与其关联的定位器首选项指示器（LPI）值。这些LPI指示特定定位器值在给定时间具有较高或较低的使用偏好。本地LPI值可以通过本地策略或管理接口进行更改。远程LPI值通常从DNS学习，但远程LPI值的本地副本可能会被与首选路径或前缀相关的本地策略修改。
Locator values are used only at the network layer. Locators are not used in end-to-end transport state. For example, Locators are not used in transport-layer session state or application-layer session state. However, this does not preclude an end-system setting up local dynamic bindings for a single transport flow to multiple Locator values concurrently.
定位器值仅在网络层使用。定位器不在端到端传输状态下使用。例如，在传输层会话状态或应用层会话状态中不使用定位器。但是，这并不排除终端系统为单个传输流同时设置到多个定位器值的本地动态绑定。
The routing system only uses Locators, not Identifiers. For unicast traffic, ILNP uses longest-prefix match routing, just as the IP Internet does.
路由系统仅使用定位器，而不使用标识符。对于单播流量，ILNP使用最长前缀匹配路由，就像IP Internet一样。
Section 4 below describes in more detail how Locators are used in forwarding and routing packets from a sending node on a source subnetwork to one or more receiving nodes on one or more destination subnetworks.
下面的第4节更详细地描述了如何使用定位器将数据包从源子网上的发送节点转发和路由到一个或多个目标子网上的一个或多个接收节点。
A difference from earlier proposals [GSE] [8+8] is that, in normal operation, the originating host supplies both Source Locator and Destination Locator values in the packets it sends out.
与先前的建议[GSE][8+8]不同的是，在正常操作中，发起主机在其发送的数据包中同时提供源定位器和目标定位器值。
Section 4.3 describes packet forwarding in more detail, while Section 4.4 describes packet routing in more detail.
第4.3节更详细地描述了数据包转发，而第4.4节更详细地描述了数据包路由。
The ILNP architecture recognises that Locator values are topologically significant, so the set of Locator values associated with a node normally will need to change when the node's connectivity to the Internet topology changes. For example, a mobile or multihomed node is likely to have connectivity changes from time to time, along with the corresponding changes to the set of Locator values.
ILNP体系结构认识到定位器值在拓扑上是重要的，因此当节点与Internet拓扑的连接发生变化时，通常需要改变与节点相关联的定位器值集。例如，移动或多址节点可能会不时更改连接，以及定位器值集的相应更改。
When a node using a specific set of Locator values changes one or more of those Locator values, then the node (1) needs to update its local knowledge of its own Locator values, (2) needs to inform all active Correspondent Nodes (CNs) of those changes to its set of Locator values so that ILNP session continuity is maintained, and (3) if it expects incoming connections the node also needs to update its Locator-related entries in the Domain Name System. [RFC6741] describes the engineering and implementation details of this process.
当使用一组特定定位器值的节点更改一个或多个定位器值时，节点（1）需要更新其自身定位器值的本地知识，（2）需要通知所有活动对应节点（CNs）其定位器值集的更改，以便保持ILNP会话连续性，以及（3）如果需要传入连接，则节点还需要更新域名系统中与其定位器相关的条目。[RFC6741]描述了该过程的工程和实施细节。
As Locator values can be dynamic, and they could change for a node during an ILNP session, correspondents need to be notified when a Locator value for a node changes for any existing ILNP session. To enable this, a node that sees its Locator values have changed MUST send a Locator Update (LU) message to its correspondent nodes. The details of this procedure are discussed in other ILNP documents -- [RFC6741], [RFC6743], and [RFC6745]. (The change in Locator values may also need to be notified to DNS but that is discussed elsewhere.)
由于定位器值可以是动态的，并且在ILNP会话期间，它们可以为节点更改，因此当任何现有ILNP会话的节点定位器值更改时，需要通知通信方。要启用此功能，发现其定位器值已更改的节点必须向其对应节点发送定位器更新（LU）消息。该程序的细节在其他ILNP文件[RFC6741]、[RFC6743]和[RFC6745]中讨论。（定位器值的更改也可能需要通知DNS，但这将在其他地方讨论。）
ILNP Locators have the same syntax as an IP unicast routing prefix.
ILNP定位器的语法与IP单播路由前缀相同。
ILNP unicast Locators have the same semantics as an IP unicast routing prefix, since they name a specific subnetwork. ILNP neither prohibits nor requires in-transit modification of Locator values.
ILNP单播定位器具有与IP单播路由前缀相同的语义，因为它们命名特定的子网络。ILNP既不禁止也不要求在传输过程中修改定位器值。
Historically, an IP Address has been considered to be an atomic datum, even though it is recognised that an IP Address has an internal structure: the network prefix plus either the host ID (IPv4) or the interface identifier (IPv6). However, this internal structure has not been used in end-system protocols; instead, all the bits of the IP Address are used. (Additionally, in IPv4 the IPv4 subnet mask uses bits from the host ID, a further confusion of the structure, even thought it is an extremely useful engineering mechanism.)
从历史上看，IP地址被视为原子数据，尽管IP地址有一个内部结构：网络前缀加上主机ID（IPv4）或接口标识符（IPv6）。然而，这种内部结构尚未用于终端系统协议；而是使用IP地址的所有位。（此外，在IPv4中，IPv4子网掩码使用来自主机ID的位，这进一步混淆了结构，尽管它是一种非常有用的工程机制。）
In ILNP, the IP Address is replaced by an "Identifier-Locator Vector" (I-LV). This consists of a pairing of an Identifier value and a Locator value for that packet, written as [I, L]. All ILNP packets have Source Identifier, Source Locator, Destination Identifier, and Destination Locator values. The I value of the I-LV is used by upper-layer protocols (e.g., TCP, UDP, SCTP), so needs to be immutable. Locators are not used by upper-layer protocols (e.g., TCP, UDP, SCTP). Instead, Locators are similar to IP routing prefixes, and are only used to name a specific subnetwork.
在ILNP中，IP地址被替换为“标识符定位向量”（I-LV）。这包括该数据包的标识符值和定位器值的配对，写为[I，L]。所有ILNP数据包都具有源标识符、源定位器、目标标识符和目标定位器值。I-LV的I值由上层协议（例如TCP、UDP、SCTP）使用，因此需要是不可变的。上层协议（如TCP、UDP、SCTP）不使用定位器。相反，定位器类似于IP路由前缀，仅用于命名特定的子网络。
While it is possible to say that an I-LV is an approximation to an IP Address of today, it should be understood that an I-LV:
虽然可以说I-LV是当今IP地址的近似值，但应该理解I-LV：
a) is not an atomic datum, being a pairing of two data types, an Identifier and a Locator.
a) 不是原子数据，而是两种数据类型（标识符和定位器）的配对。
b) has different semantics and properties to an IP Address, as is described in this document.
b) 与IP地址具有不同的语义和属性，如本文档所述。
In our discussion, it will be convenient sometimes to refer to an I-LV, but sometimes to refer only to an Identifier value, or only to a Locator value.
在我们的讨论中，有时引用I-LV是方便的，但有时仅引用标识符值，或仅引用定位器值。
ILNP packets always contain a source I-LV and a destination I-LV.
ILNP数据包始终包含源I-LV和目标I-LV。
In describing how capabilities are implemented in ILNP, we will consider the differences in end-systems' state between IP and ILNP in order to highlight the architectural changes.
在描述如何在ILNP中实现能力时，我们将考虑IP和ILNP之间的终端系统状态的差异，以突出体系结构的变化。
We define a formal notation to represent the data contained in the transport-layer session state. We define:
我们定义了一个正式的表示法来表示传输层会话状态中包含的数据。我们定义：
A = IP Address I = Identifier L = Locator P = Transport-layer port number
A=IP地址I=标识符L=定位器P=传输层端口号
To differentiate the local and remote values for the above items, we also use suffixes, for example:
为了区分上述项目的本地值和远程值，我们还使用后缀，例如：
_L = local _R = remote
_L=本地_R=远程
With IPv4 and IPv6 today, the invariant state at the transport-layer for TCP can be represented by the tagged tuple:
在今天的IPv4和IPv6中，TCP传输层的不变状态可以用标记的元组表示：
<TCP: A_L, A_R, P_L, P_R> --- (1)
<TCP: A_L, A_R, P_L, P_R> --- (1)
Tag values that will be used are:
将使用的标记值包括：
IP Internet Protocol ILNP Identifier-Locator Network Protocol TCP Transmission Control Protocol UDP User Datagram Protocol
IP Internet协议ILNP标识符定位器网络协议TCP传输控制协议UDP用户数据报协议
So, for example, with IP, a UDP packet would have the tagged tuple:
因此，例如，对于IP，UDP数据包将具有标记的元组：
<UDP: A_L, A_R, P_L, P_R> --- (2)
<UDP: A_L, A_R, P_L, P_R> --- (2)
A TCP segment carried in an IP packet may be represented by the tagged tuple binding:
IP数据包中携带的TCP段可由标记的元组绑定表示：
<TCP: A_L, A_R, P_L, P_R><IP: A_L, A_R> --- (3)
<TCP: A_L, A_R, P_L, P_R><IP: A_L, A_R> --- (3)
and a UDP packet would have the tagged tuple binding:
UDP数据包将具有标记的元组绑定：
<UDP: A_L, A_R, P_L, P_R><IP: A_L, A_R> --- (4)
<UDP: A_L, A_R, P_L, P_R><IP: A_L, A_R> --- (4)
In ILNP, the transport-layer state for TCP is:
在ILNP中，TCP的传输层状态为：
<TCP: I_L, I_R, P_L, P_R> --- (5)
<TCP: I_L, I_R, P_L, P_R> --- (5)
The binding for a TCP segment within an ILNP packet:
ILNP数据包中TCP段的绑定：
<TCP: I_L, I_R, P_L, P_R><ILNP: L_L, L_R> --- (6)
<TCP: I_L, I_R, P_L, P_R><ILNP: L_L, L_R> --- (6)
When comparing tuple expressions (3) and (6), we see that for IP, any change to network addresses impacts the end-to-end state, but for ILNP, changes to Locator values do not impact end-to-end state. This provides end-system session state invariance, a key feature of ILNP compared to IP as it is used in some situations today. ILNP adopts the end-to-end approach for its architecture [SRC84]. As noted previously, nodes MAY have more than one Locator concurrently, and nodes MAY change their set of active Locator values as required.
当比较元组表达式（3）和（6）时，我们发现对于IP，网络地址的任何更改都会影响端到端状态，但是对于ILNP，定位器值的更改不会影响端到端状态。这提供了终端系统会话状态不变性，这是ILNP与IP相比的一个关键特性，因为它目前在某些情况下使用。ILNP的体系结构采用端到端的方法[SRC84]。如前所述，节点可以同时具有多个定位器，并且节点可以根据需要更改其活动定位器值集。
While these documents do not include SCTP examples, the same notation can be used, simply substituting the string "SCTP" for the string "TCP" or the string "UDP" in the above examples.
虽然这些文档不包括SCTP示例，但可以使用相同的符号，只需在上述示例中用字符串“SCTP”替换字符串“TCP”或字符串“UDP”。
In ILNP, protocols above the network layer do not use the Locator values. Thus, the transport layer uses only the I values for the transport-layer session state (e.g., TCP pseudo-header checksum, UDP pseudo-header checksum), as is shown, for example, in expression (6) above.
在ILNP中，网络层之上的协议不使用定位器值。因此，传输层仅使用传输层会话状态的I值（例如，TCP伪报头校验和、UDP伪报头校验和），如上面的表达式（6）中所示。
Additionally, from a practical perspective, while the I values are only used in protocols above the network layer, it is convenient for them to be carried in network packets, so that the namespace for the I values can be used by any transport-layer protocols operating above the common network layer.
此外，从实际的角度来看，虽然I值仅在网络层之上的协议中使用，但是它们便于在网络分组中携带，因此I值的名称空间可由在公共网络层之上操作的任何传输层协议使用。
This document provides an architectural description of the core ILNP capabilities and functions. It is based around the use of example scenarios so that practical issues can be highlighted.
本文档提供了ILNP核心功能的体系结构描述。它基于示例场景的使用，以便突出实际问题。
In some cases, illustrative suggestions and light discussion are presented with respect to engineering issues, but detailed discussion of engineering issues are deferred to other ILNP documents.
在某些情况下，针对工程问题提出了说明性建议和轻松讨论，但工程问题的详细讨论推迟到其他ILNP文件。
The order of the examples presented below is intended to allow an incremental technical understanding of ILNP to be developed. There is no other reason for the ordering of the examples listed below.
下面给出的示例顺序旨在增加对ILNP的技术理解。下面列出的示例的排序没有其他原因。
Many of the descriptions are based on the use of an example site network as shown in Figure 3.1.
许多描述基于图3.1所示的示例站点网络的使用。
site . . . . +----+
network . .-----+ CN |
. . . . +------+ link1 . . +----+
. . | +------. .
. D . | | . .
. .----+ SBR | . Internet .
. H . | | . .
. . | +------. .
. . . . +------+ link2 . .
. .
. . . .
site . . . . +----+
network . .-----+ CN |
. . . . +------+ link1 . . +----+
. . | +------. .
. D . | | . .
. .----+ SBR | . Internet .
. H . | | . .
. . | +------. .
. . . . +------+ link2 . .
. .
. . . .
CN = Correspondent Node D = Device H = Host SBR = Site Border Router
CN=对应节点D=设备H=主机SBR=站点边界路由器
Figure 3.1: A Simple Site Network for ILNP Examples
图3.1:ILNP示例的简单站点网络
In some cases, hosts (H) or devices (D) act as end-systems within the site network, and communicate with (one or more) Correspondent Node (CN) instances that are beyond the site.
在某些情况下，主机（H）或设备（D）充当站点网络内的终端系统，并与站点之外的（一个或多个）对应节点（CN）实例通信。
Note that the figure is illustrative and presents a logical view. For example, the CN may itself be on a site network, just like H or D.
请注意，该图是说明性的，显示了逻辑视图。例如，CN本身可能位于站点网络上，就像H或D一样。
Also, for formulating examples, we assume ILNPv6 is in use, which has the same packet header format (as viewed by routers) as IPv6, and can be seen as a superset of IPv6 capabilities.
此外，为了制定示例，我们假设ILNPv6正在使用，它与IPv6具有相同的数据包头格式（由路由器查看），并且可以被视为IPv6功能的超集。
For simplicity, we assume that name resolution is via the deployed DNS, which has been updated to store DNS records for ILNP [RFC6742].
为简单起见，我们假设名称解析是通过已部署的DNS进行的，该DNS已更新以存储ILNP[RFC6742]的DNS记录。
Note that, from an engineering viewpoint, this does NOT mean that the DNS also has to be ILNP capable: existing IPv4 or IPv6 infrastructure can be used for DNS transport.
请注意，从工程的角度来看，这并不意味着DNS也必须具有ILNP功能：现有的IPv4或IPv6基础设施可用于DNS传输。
Multicast forwarding and routing are unchanged, in order to avoid requiring changes in deployed IP routers and routing protocols. ILNPv4 multicasting is the same as IETF Standards Track IPv4 multicasting [RFC1112] [RFC3376]. ILNPv6 multicasting is the same as IETF Standards Track IPv6 multicasting [RFC4291] [RFC2710] [RFC3810].
多播转发和路由保持不变，以避免需要更改已部署的IP路由器和路由协议。ILNPv4多播与IETF标准跟踪IPv4多播相同[RFC1112][RFC3376]。ILNPv6多播与IETF标准跟踪IPv6多播相同[RFC4291][RFC2710][RFC3810]。
In this section, we describe basic packet forwarding and routing in ILNP. We highlight areas where it is similar to current IP, and also where it is different from current IP. We use examples in order to illustrate the intent and show the feasibility of the approach.
在本节中，我们将介绍ILNP中的基本数据包转发和路由。我们强调了与当前IP相似的领域，以及与当前IP不同的领域。我们使用示例来说明该方法的意图和可行性。
For this section, in Figure 4.1, H is a fixed host in a simple site network, and CN is a remote Correspondent Node outside the site; H and CN are ILNP-capable, while the Site Border Router (SBR) does not need to be ILNP-capable.
对于本节，在图4.1中，H是简单站点网络中的固定主机，CN是站点外的远程通信节点；H和CN支持ILNP，而站点边界路由器（SBR）不需要支持ILNP。
site . . . . +----+
network . .-----+ CN |
. . . . +------+ . . +----+
. . | +------. .
. . | | . .
. .----+ SBR | . Internet .
. H . | | . .
. . | | . .
. . . . +------+ . .
. .
. . . .
site . . . . +----+
network . .-----+ CN |
. . . . +------+ . . +----+
. . | +------. .
. . | | . .
. .----+ SBR | . Internet .
. H . | | . .
. . | | . .
. . . . +------+ . .
. .
. . . .
CN = Correspondent Node H = Host SBR = Site Border Router
CN=对应节点H=主机SBR=站点边界路由器
Figure 4.1: A Simple Site Network for ILNP Examples
图4.1:ILNP示例的简单站点网络
This section uses the term "address management", in recognition of the analogy with capabilities present in IP today. In this document, address management is about enabling hosts to attach to a subnetwork and enabling network-layer communication between and among hosts, also including:
本节使用“地址管理”一词，以确认与当今IP中存在的功能的相似性。在本文档中，地址管理是指使主机能够连接到子网，并在主机之间和主机之间实现网络层通信，还包括：
a) enabling identification of a node within a site. b) allowing basic routing/forwarding from a node acting as an end-system.
a) 启用站点内节点的标识。b） 允许从作为终端系统的节点进行基本路由/转发。
If we consider Figure 4.1, imagine that host H has been connected to the site network. Administratively, it needs at least one I value and one L value in order to be able to communicate.
如果我们考虑图4.1，假设主机H已经连接到站点网络。在管理上，它至少需要一个I值和一个L值才能进行通信。
Today, local administrative procedures allocate IP Addresses, often using various protocol mechanisms (e.g., NETCONF-based router configuration, DHCP for IPv4, DHCP for IPv6, IPv6 Router Advertisements). Similarly, local administrative procedures can allocate I and L values as required, e.g., I_H and L_H. This may be through manual configuration.
如今，本地管理过程通常使用各种协议机制（例如，基于NETCONF的路由器配置、IPv4的DHCP、IPv6的DHCP、IPv6路由器广告）来分配IP地址。类似地，本地管理程序可以根据需要分配I和L值，例如I_H和L_H。这可以通过手动配置实现。
Additionally, if it is expected or desired that H might have incoming communication requests, e.g., it is a server, then the values I_H and L_H can be added to the relevant name services (e.g., DNS, NIS/YP), so that FQDN lookups for H resolve to the appropriate DNS resource records (e.g., NID, L32, L64, and LP [RFC6742]) for node H.
此外，如果预期或期望H可能具有传入的通信请求，例如，它是服务器，则可以将值I_H和L_H添加到相关的名称服务（例如，DNS，NIS/YP），以便针对H的FQDN查找解析到节点H的适当DNS资源记录（例如，NID，L32，L64和LP[RFC6742]）。
From a network operations perspective, this whole process also can be automated. As an example, consider that in Figure 3.1 the Site Border Router (SBR) is an IPv6-capable router and is connected via link1 to an ISP that supports IPv6. The SBR will have been allocated one (or more) IPv6 prefixes that it will multicast using IPv6 Routing Advertisements (RAs) into the site network, e.g., prefix L_1. L_1 is actually a local IPv6 prefix (/64), which is formed from an address assignment by the upstream ISP, according to [RFC3177] or [RFC6177]. Host H will see these RAs, for example, on its local interface with name eth0, will be able to use that prefix as a Locator value, and will cache that Locator value locally.
从网络运营的角度来看，整个过程也可以自动化。作为一个例子，考虑在图3.1中，站点边界路由器（SBR）是可IPv6的路由器，并且通过LIK1连接到支持IPv6的ISP。SBR将被分配一个（或多个）IPv6前缀，该前缀将使用IPv6路由公告（RAs）多播到站点网络中，例如前缀L_1。L_1实际上是一个本地IPv6前缀（/64），根据[RFC3177]或[RFC6177]，它由上游ISP的地址分配形成。例如，主机H将在其名为eth0的本地接口上看到这些RAs，将能够使用该前缀作为定位器值，并将在本地缓存该定位器值。
Also, node H can use the mechanism documented in either Section 2.5.1 of [RFC4291], in [RFC3972], [RFC4581], [RFC4982], or in [RFC4941] in order to create a default I value (say, I_H), just as an IPv6 host can. For DNS, the I_H and L_1 values may be pre-configured in DNS by an administrator who already has knowledge of these, or added to DNS by H using Secure DNS Dynamic Update [RFC3007] to add or update the correct NID and L64 records to DNS for the FQDN for H.
此外，节点H可以使用[RFC4291]第2.5.1节、[RFC3972]、[RFC4581]、[RFC4982]或[RFC4941]中记录的机制来创建默认I值（例如，I_H），就像IPv6主机一样。对于DNS，I_H和L_1值可以由已经了解这些值的管理员在DNS中预先配置，或者由H使用安全DNS动态更新[RFC3007]添加到DNS中，以便为H的FQDN向DNS添加或更新正确的NID和L64记录。
For the purposes of explaining the concept of operations, we talk of a local I-L Communication Cache (ILCC). This is an engineering convenience and does not form part of the ILNP architecture, but is used in our examples. More details on the ILCC can be found in [RFC6741]. The ILCC contains information that is required for the operation of ILNP. This will include, amongst other things, the current set of valid Identifier and Locator values in use by a node, the bindings between them, and the bindings between Locator values and interfaces.
为了解释操作的概念，我们讨论本地I-L通信缓存（ILCC）。这是一种工程上的便利，不构成ILNP体系结构的一部分，但在我们的示例中使用。有关ILCC的更多详细信息，请参见[RFC6741]。ILCC包含ILNP操作所需的信息。除其他外，这将包括节点正在使用的当前有效标识符和定位器值集、它们之间的绑定以及定位器值和接口之间的绑定。
When the SBR needs to send a packet to H, it uses local address resolution mechanisms to discover the bindings between interface addresses and currently active I-LVs for H. For our example of Figure 3.1, IPv6 Neighbour Discovery (ND) can be used without modification, as the I-LV for ILNPv6 occupies the same bits as the IPv6 address in the IPv6 header. For packets from H to SBR, the same basic mechanism applies, as long as SBR supports IPv6 and even if it is not ILNPv6-capable, as IPv6 ND is used unmodified for ILNPv6.
当SBR需要向H发送数据包时，它使用本地地址解析机制来发现H的接口地址和当前活动的I-LV之间的绑定。对于图3.1的示例，可以使用IPv6邻居发现（ND），无需修改，因为ILNPv6的I-LV与IPv6标头中的IPv6地址占用相同的位。对于从H到SBR的数据包，同样的基本机制也适用，只要SBR支持IPv6，即使它不支持ILNPv6，因为IPv6 ND未经修改地用于ILNPv6。
For Figure 3.1, assuming:
对于图3.1，假设：
- SBR advertises prefix L_1 locally, uses I value I_S, and has an Ethernet MAC address M_S on interface with local name sbr0
- SBR在本地播发前缀L_1，使用I值I_S，并且在接口上具有以太网MAC地址M_S，本地名称为sbr0
- H uses I value I_H, and has an Ethernet MAC address of M_H on the interface with local name eth0
- H使用I值I_H，并且在本地名为eth0的接口上具有M_H的以太网MAC地址
then H will have in its ILCC:
那么H在其ILCC中有：
[I_H, L_1] --- (7a)
L_1, eth0 --- (7b)
[I_H, L_1] --- (7a)
L_1, eth0 --- (7b)
After the IPv6 RA and ND mechanism has executed, the ILCC at H would contain, as well as expressions (7a) and (7b), the following entry for SBR:
执行IPv6 RA和ND机制后，H处的ILCC以及表达式（7a）和（7b）将包含SBR的以下条目：
[I_S, L_1], M_S --- (8)
[I_S, L_1], M_S --- (8)
For ILNPv6, it does not matter that the SBR is not ILNPv6-capable, as the I-LV [I_S, L_1] is physically equivalent to the IPv6 address for the internal interface sbr0.
对于ILNPv6，SBR不支持ILNPv6并不重要，因为I-LV[I_S，L_1]在物理上等同于内部接口sbr0的IPv6地址。
At SBR, which is not ILNP-capable, there would be the following entries in its local cache and configuration:
在不支持ILNP的SBR，其本地缓存和配置中将有以下条目：
L_1:I_S --- (9a)
L_1, sbr0 --- (9b)
L_1:I_S --- (9a)
L_1, sbr0 --- (9b)
Expression (9a) represents a valid IPv6 ND entry: in this case, the I_S value (which is 64 bits in ILNPv6) and the L_1 values are, effectively, concatenated and treated as if they were a single IPv6 address. Expression (9b) binds transmissions for L_1 to interface sbr0. (Again, sbr0 is a local, implementation-specific name, and such a binding is possible with standard tools today, for example, ifconfig(8).)
表达式（9a）表示有效的IPv6 ND条目：在本例中，I_S值（在ILNPv6中为64位）和L_1值有效地连接在一起，并被视为单个IPv6地址。表达式（9b）将L_1的传输绑定到接口sbr0。（同样，sbr0是一个本地的、特定于实现的名称，这种绑定在今天的标准工具中是可能的，例如ifconfig（8）。）
If we assume that host H is configured as in the previous section, it is now ready to send and receive ILNP packets.
如果我们假设主机H的配置与上一节中相同，那么它现在就可以发送和接收ILNP数据包了。
Let us assume that, for Figure 4.1, it wishes to contact the node CN, which has FQDN cn.example.com and is ILNP-capable. A DNS query by H for cn.example.com will result in NID and L64 records for CN, with values I_CN and L_CN, respectively, being returned to H and stored in its ILCC:
让我们假设，对于图4.1，它希望联系节点CN，该节点有FQDN CN.example.com，并且支持ILNP。H对cn.example.com的DNS查询将导致cn的NID和L64记录，其值分别为I_cn和L_cn，返回给H并存储在其ILCC中：
[I_CN, L_CN] --- (10)
[I_CN, L_CN] --- (10)
This will be considered active as long as the TTL values for the DNS records are valid. If the TTL for an I or L value is zero, then the value is still usable but becomes stale as soon as it has been used once. However, it is more likely that the TTL value will be greater than zero [BA11] [SBK01].
只要DNS记录的TTL值有效，这将被视为活动。如果I或L值的TTL为零，则该值仍然可用，但一旦使用一次，该值就会过时。然而，TTL值更有可能大于零[BA11][SBK01]。
Once the CN's I value is known, the upper-layer protocol, e.g., the transport protocol, can set up suitable transport-layer session state:
一旦CN的I值已知，上层协议（例如，传输协议）可以设置合适的传输层会话状态：
<UDP: I_H, I_CN, P_H, P_CN> --- (11)
<UDP: I_H, I_CN, P_H, P_CN> --- (11)
For routing of ILNP packets, the destination L value in an ILNPv6 packet header is semantically equivalent to a routing prefix. So, once a packet has been forwarded from a host to its first-hop router, only the destination L value needs to be used for getting the packet to the destination network. Once the packet has arrived at the router for the site network, local mechanisms and the packet-forwarding mechanism, as described above in Section 4.3, allow the packet to be delivered to the host.
对于ILNP数据包的路由，ILNPv6数据包头中的目的地L值在语义上等同于路由前缀。因此，一旦数据包从主机转发到其第一跳路由器，就只需要使用目的地L值将数据包发送到目的地网络。一旦数据包到达站点网络的路由器，本地机制和数据包转发机制（如上文第4.3节所述）允许将数据包发送到主机。
For our example of Figure 4.1, H will send a UDP packet over ILNP as:
对于图4.1的示例，H将通过ILNP发送UDP数据包，如下所示：
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (12a)
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (12a)
and CN will send UDP packets to H as:
CN将向H发送UDP数据包，如下所示：
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_1> --- (12b)
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_1> --- (12b)
The I value for H used in the transport-layer state (I_H in expression (12a)) selects the correct L value (L_1 in this case) from the bindings in the ILCC (expression (7a)), and that, in turn, selects the correct interface from the ILCC (expression (7b)), as
在传输层状态中使用的H的I值（表达式（12a）中的I_H）从ILCC（表达式（7a））中的绑定中选择正确的L值（在本例中为L_1），然后从ILCC（表达式（7b））中选择正确的接口，如下所示：
described in Section 4.2. This gets the packet to the first hop router; beyond that, the ILNPv6 packet is treated as if it were an IPv6 packet.
如第4.2节所述。这将数据包发送到第一跳路由器；除此之外，ILNPv6数据包被视为IPv6数据包。
For multihoming, there are three cases to consider:
对于多归宿，有三种情况需要考虑：
a) Host Multihoming (H-MH): a single host is, individually, connected to multiple upstream links, via separate routing paths, and those multiple paths are used by that host as it wishes. That is, use of multiple upstream links is managed by the single host itself. For example, the host might have multiple valid Locator values on a single interface, with each Locator value being associated with a different upstream link (provider).
a) 主机多宿主（H-MH）：单个主机通过单独的路由路径单独连接到多个上游链路，并且该主机可以根据自己的意愿使用这些多个路径。也就是说，多个上行链路的使用由单个主机本身管理。例如，主机在单个接口上可能有多个有效的定位器值，每个定位器值都与不同的上游链路（提供者）关联。
b) Multi-Path Transport (MTP): This is similar to using ILNP's support for host multihoming (i.e., H-MH), so we describe multi-path transport here. (Indeed, for ILNP, this can be considered a special case of H-MH.)
b) 多径传输（MTP）：这类似于使用ILNP对主机多宿（即H-MH）的支持，因此我们在这里描述多径传输。（事实上，对于ILNP，这可以被视为H-MH的特例。）
c) Site Multihoming (S-MH): a site network is connected to multiple upstream links via separate routing paths, and hosts on the site are not necessarily aware of the multiple upstream paths. That is, the multiple upstream paths are managed, typically, through a site border router, or via the providers.
c) 站点多宿主（S-MH）：站点网络通过单独的路由路径连接到多个上游链路，站点上的主机不一定知道多个上游路径。也就是说，通常通过站点边界路由器或提供商来管理多个上游路径。
Essentially, for ILNP, multihoming is implemented by enabling:
从本质上讲，对于ILNP，多归宿是通过启用：
a) multiple Locator values to be used simultaneously by a node
a) 一个节点同时使用的多个定位器值
b) dynamic, simultaneous binding between one (or more) Identifier value(s) and multiple Locator values
b) 一个（或多个）标识符值和多个定位器值之间的动态、同时绑定
With respect to the requirements for hosts [RFC1122], the multihoming function provided by ILNP is very flexible. It is not useful to discuss ILNP multihoming strictly within the confines of the exposition presented in Section 3.3.4 of [RFC1122], as that text is couched in terms of relationships between IP Addresses and interfaces, which can be dynamic in ILNP. The closest relationship between ILNP multihoming and [RFC1122] would be that certainly ILNP could support the notion of "Multiple Logical Networks", "Multiple Logical Hosts", and "Simple Multihoming".
对于主机[RFC1122]的要求，ILNP提供的多主功能非常灵活。在[RFC1122]第3.3.4节所述的范围内严格讨论ILNP多宿是没有用的，因为该文本是根据IP地址和接口之间的关系来表述的，在ILNP中可能是动态的。ILNP多宿主与[RFC1122]之间最密切的关系是，ILNP肯定可以支持“多逻辑网络”、“多逻辑主机”和“简单多宿主”的概念。
At present, host multihoming is not common in the deployed Internet. When TCP or UDP are in use with an IP-based network-layer session, host multihoming cannot provide session resilience, because the transport protocol's pseudo-header checksum binds the transport-layer session to a single IP Address of the multihomed node, and hence to a single interface of that node. SCTP has a protocol-specific mechanism to support node multihoming; SCTP can support session resilience both at present and also without change in the proposed approach [RFC5061].
目前，主机多宿主在部署的Internet中并不常见。当TCP或UDP与基于IP的网络层会话一起使用时，主机多宿主无法提供会话弹性，因为传输协议的伪报头校验和将传输层会话绑定到多宿主节点的单个IP地址，从而绑定到该节点的单个接口。SCTP有一个特定于协议的机制来支持节点多归属；SCTP目前可以支持会话弹性，并且在不改变提议方法的情况下也可以支持会话弹性[RFC5061]。
Host multihoming in ILNP is supported directly in each host by ILNP. The simplest explanation of H-MH for ILNP is that an ILNP-capable host can simultaneously use multiple Locator values, for example, by having a binding between an I value and two different L values, e.g., the ILCC may contain the I-LVs:
ILNP在每个主机中直接支持ILNP中的主机多宿主。对于ILNP的H-MH的最简单解释是，支持ILNP的主机可以同时使用多个定位器值，例如，通过在I值和两个不同的L值之间具有绑定，例如，ILCC可以包含I-LV：
[I_1, L_1] --- (14a)
[I_1, L_2] --- (14b)
[I_1, L_1] --- (14a)
[I_1, L_2] --- (14b)
Additionally, a host may use several I values concurrently, e.g., the ILCC may contain the I-LVs:
此外，主机可同时使用多个I值，例如，ILCC可包含I-LVs：
[I_1, L_1] --- (15a)
[I_1, L_2] --- (15b)
[I_2, L_2] --- (15c)
[I_3, L_1] --- (15d)
[I_1, L_1] --- (15a)
[I_1, L_2] --- (15b)
[I_2, L_2] --- (15c)
[I_3, L_1] --- (15d)
Architecturally, ILNP considers these all to be cases of multihoming: the host is connected to more than one subnetwork, each subnetwork being named by a different Locator value.
在体系结构上，ILNP认为这些都是多主的情况：主机连接到多个子网，每个子网由不同的定位器值命名。
In the cases above, the selection of which I-LV to use would be through local policy or through management mechanisms. Additionally, suitably modified transport-layer protocols, such as multi-path transport-layer protocol implementations, may make use of multiple I-LVs. Note that in such a case, the way in which multiple I-LVs are used would be under the control of the higher-layer protocol.
在上述情况下，应通过当地政策或管理机制选择使用哪种I-LV。此外，经适当修改的传输层协议，例如多路径传输层协议实现，可利用多个I-lv。注意，在这种情况下，使用多个I-lv的方式将在更高层协议的控制下。
Recall, however, that L values also have preference -- LPI values -- and these LPI values can be used at the network layer, or by a transport-layer protocol implementation, in order make use of L values in a specific manner.
然而，回想一下，L值也有优先权——LPI值——这些LPI值可以在网络层使用，或者由传输层协议实现使用，以便以特定的方式使用L值。
Note that, from a practical perspective, ILNP dynamically binds L values to interfaces on a node to indicate the SNPA for that L value, so the multihoming is very flexible: a node could have a single
注意，从实用的角度来看，ILNP动态地将L值绑定到节点上的接口，以指示该L值的SNPA，因此多宿主非常灵活：一个节点可以有一个
interface and have multiple L values bound to that interface. For example, for expressions (14a) and (14b), if the end-system has a single interface with local name eth0, then the entries in the ILCC will be:
接口，并将多个L值绑定到该接口。例如，对于表达式（14a）和（14b），如果终端系统具有本地名称eth0的单个接口，则ILCC中的条目将为：
L_1, eth0 --- (16a)
L_2, eth0 --- (16b)
L_1, eth0 --- (16a)
L_2, eth0 --- (16b)
And, if we assume that for expressions (15a-c) the end-system has two interfaces, eth0 and eth1, then these ILCC entries are possible:
并且，如果我们假设对于表达式（15a-c），最终系统有两个接口，eth0和eth1，那么这些ILCC条目是可能的：
L_1, eth0 --- (17a)
L_2, eth1 --- (17b)
L_1, eth0 --- (17a)
L_2, eth1 --- (17b)
Let us consider the network in Figure 5.1.
让我们考虑图5.1中的网络。
site . . . .
network . .
. . . . +------+ L_1 . .
. . | +------. .
. . | | . .
. .----+ SBR | . Internet .
. . | | . .
. H . | +------. .
. . . . +------+ L_2 . .
. .
. . . .
site . . . .
network . .
. . . . +------+ L_1 . .
. . | +------. .
. . | | . .
. .----+ SBR | . Internet .
. . | | . .
. H . | +------. .
. . . . +------+ L_2 . .
. .
. . . .
L_1 = global Locator value 1 L_2 = global Locator value 2 SBR = Site Border Router
L_1=全局定位器值1 L_2=全局定位器值2 SBR=站点边界路由器
Figure 5.1: A Simple Multihoming Scenario for ILNP
图5.1:ILNP的简单多主场景
We assume that H has a single interface, eth0. SBR will advertise L_1 and L_2 internally to the site. Host H will configure these as both reachable via its single interface, eth0, by using ILCC entries as in expressions (16a) and (16b). When packets from H that are to egress the site network reach SBR, it can make appropriate decisions on which link to use based on the source Locator value (which has been inserted by H) or based on other local policy.
我们假设H有一个接口eth0。SBR将在现场内部宣传L_1和L_2。主机H将通过使用表达式（16a）和（16b）中的ILCC条目，通过其单个接口eth0将这些配置为可访问。当来自H的要离开站点网络的数据包到达SBR时，它可以基于源定位器值（由H插入）或基于其他本地策略做出关于使用哪个链路的适当决定。
If, however, H has two interfaces, eth0 and eth1, then it can use ILCC entries as in expressions (17a) and (17b).
但是，如果H有两个接口eth0和eth1，那么它可以使用表达式（17a）和（17b）中的ILCC条目。
Note that the values L_1 and L_2 do not need to be PI-based Locator values, and can be taken from ISP-specific PA routing prefix allocations from the upstream ISPs providing the two links.
注意，值L_1和L_2不需要是基于PI的定位器值，并且可以从提供两个链路的上游ISP的ISP特定PA路由前缀分配中获取。
Of course, this example is illustrative: many other configurations are also possible, but the fundamental mechanism remains the same, as described above.
当然，这个示例是说明性的：许多其他配置也是可能的，但基本机制保持不变，如上所述。
If any Locator values change, then H will discover this when it sees new Locator values in RAs from SBR, and sees that L values that were previously used are no longer advertised. When this happens, H will:
如果任何定位器值发生变化，那么H将在从SBR看到RAs中的新定位器值时发现这一点，并看到以前使用的L值不再公布。发生这种情况时，H将：
a) maintain existing active network-layer sessions: based on its current ILCC entries and active sessions, send Locator Update (LU) messages to CNs to notify them of the change of L values. (LU messages are synonymous to Mobile IPv6 Binding Updates.)
a) 维护现有的活动网络层会话：根据当前的ILCC条目和活动会话，向CNs发送定位器更新（LU）消息，通知他们L值的更改。（LU消息与移动IPv6绑定更新同义。）
b) if required, update its relevant DNS entries with the new L value in the appropriate DNS records, to enable correct resolution for new incoming session requests.
b) 如果需要，使用相应DNS记录中的新L值更新其相关DNS条目，以便为新传入的会话请求启用正确的解析。
From an engineering viewpoint, H also updates its ILCC data, removing the old L value(s) and replacing with new L value(s) as required.
从工程角度来看，H还更新其ILCC数据，删除旧的L值，并根据需要替换为新的L值。
Depending on the nature of the physical change in connectivity that the L value change represents, this may disrupt upper-level protocols, e.g., a fibre cut. Dealing with such physical-level disruption is beyond the scope of ILNP. However, ILNP supports graceful changes in L values, and this is explained below in Section 6 in the discussion on mobility support.
根据L值变化所代表的连接物理变化的性质，这可能会中断上层协议，例如光纤切断。处理此类物理级中断超出了ILNP的范围。然而，ILNP支持L值的优雅变化，这将在下文第6节关于移动性支持的讨论中解释。
ILNP supports deployment and use of multi-path transport protocols, such as the Multi-Path extensions to TCP (MP-TCP) being defined by the IETF TCPM Working Group. Specifically, ILNP will support the use of multiple paths as it allows a single I value to be bound to multiple L values -- see Section 5.1, specifically expressions (15a) and (15b).
ILNP支持多路径传输协议的部署和使用，如IETF TCPM工作组定义的TCP多路径扩展（MP-TCP）。具体地说，ILNP将支持使用多个路径，因为它允许单个I值绑定到多个L值——请参见第5.1节，特别是表达式（15a）和（15b）。
Of course, there will be specific mechanisms for: - congestion control - signalling for connection/session management - path discovery and path management - engineering and implementation issues
当然，将有具体的机制：-拥塞控制-连接/会话管理的信令-路径发现和路径管理-工程和实施问题
These transport-layer mechanisms fall outside the scope of ILNP and would be defined in the multi-path transport protocol specifications.
这些传输层机制不属于ILNP的范围，将在多路径传输协议规范中定义。
As far as the ILNP architecture is concerned, the transport protocol connection is simply using multiple I-LVs, but with the same I value in each, and different L values, i.e., a multihomed host.
就ILNP体系结构而言，传输协议连接只是使用多个I-LV，但每个I-LV中的I值相同，L值不同，即多宿主机。
At present, site multihoming is common in the deployed Internet. This is primarily achieved by advertising the site's routing prefix(es) to more than one upstream Internet service provider at a given time. In turn, this requires de-aggregation of routing prefixes within the inter-domain routing system. This increases the entropy of the inter-domain routing system (e.g., RIB/FIB size increases beyond the minimal RIB/FIB size that would be required to reach all sites).
目前，在部署的Internet中，站点多宿主是很常见的。这主要是通过在给定时间向多个上游互联网服务提供商公布站点的路由前缀来实现的。反过来，这需要在域间路由系统中取消路由前缀的聚合。这增加了域间路由系统的熵（例如，RIB/FIB大小的增加超过了到达所有站点所需的最小RIB/FIB大小）。
Site multihoming, in its simplest form in ILNP, is an extension of the H-MH scenario described in Section 5.1. If we consider Figure 5.1, and assume that there are many hosts in the site network, then each host can choose (a) whether or not to manage its own ILNP connectivity, and (b) whether or not to use multiple Locator values. This allows maximal control of connectivity for each host.
ILNP中最简单的站点多宿是第5.1节中描述的H-MH场景的扩展。如果我们考虑图5.1，并且假设站点网络中有许多主机，那么每个主机可以选择（a）是否管理其自己的ILNP连接性，以及（b）是否使用多个定位器值。这允许最大限度地控制每个主机的连接。
Of course, with ILNPv6, just as any IPv6 router is required to generate IPv6 Router Advertisement messages with the correct routing prefix information for the link the RA is advertised upon, the SBR is also required to generate RAs containing the correct Locator value(s) for the link that the RA is advertised upon. The correct values for these RA messages are typically configured by system administration, or might be passed down from the upstream provider.
当然，对于ILNPv6，正如需要任何IPv6路由器为RA播发的链路生成具有正确路由前缀信息的IPv6路由器播发消息一样，SBR也需要为RA播发的链路生成包含正确定位器值的RAs。这些RA消息的正确值通常由系统管理部门配置，或者可能由上游提供程序传递。
To avoid a DNS Update burst when a site or (sub)network changes location, a DNS record optimisation is possible by using the new LP record for ILNP. This would change the number of DNS Updates required from Order(Number of nodes within the site/subnetwork that moved) to Order(1) [RFC6742].
为了避免当站点或（子）网络更改位置时DNS更新突发，可以使用ILNP的新LP记录优化DNS记录。这会将所需的DNS更新数量从顺序（站点/子网络中移动的节点数量）更改为顺序（1）[RFC6742]。
The scenario of Figure 5.1 is an example to illustrate the architectural operation of multihoming for ILNP. For site multihoming, a scenario such as the one depicted in Figure 5.2 is also common. Here, there are two SBRs, each with its own global connectivity.
图5.1的场景是一个示例，用于说明ILNP的多主架构操作。对于站点多宿主，如图5.2所示的场景也很常见。这里有两个SBR，每个SBR都有自己的全球连接。
site . . . .
network . .
. . . . +-------+ L_1 . .
. . | +------. .
. . | | . .
. .---+ SBR_A | . .
. . | | . .
. . | | . .
. . +-------+ . .
. . ^ . .
. . | CP . Internet .
. . v . .
. . +-------+ L_2 . .
. . | +------. .
. . | | . .
. .---+ SBR_B | . .
. . | | . .
. . | | . .
. . . . +-------+ . .
. .
. . . .
site . . . .
network . .
. . . . +-------+ L_1 . .
. . | +------. .
. . | | . .
. .---+ SBR_A | . .
. . | | . .
. . | | . .
. . +-------+ . .
. . ^ . .
. . | CP . Internet .
. . v . .
. . +-------+ L_2 . .
. . | +------. .
. . | | . .
. .---+ SBR_B | . .
. . | | . .
. . | | . .
. . . . +-------+ . .
. .
. . . .
CP = coordination protocol L_1 = global Locator value 1 L_2 = global Locator value 2 SBR_A = Site Border Router A SBR_B = Site Border Router B
CP=协调协议L_1=全局定位器值1 L_2=全局定位器值2 SBR_A=站点边界路由器A SBR_B=站点边界路由器B
Figure 5.2: A Dual-Router Multihoming Scenario for ILNP
图5.2:ILNP的双路由器多主场景
The use of two physical routers provides an extra level of resilience compared to the scenario of Figure 5.1. The coordination protocol (CP) between the two routers keeps their actions in synchronisation according to whatever management policy is in place for the site network. Such capabilities are available today in products. Note that, logically, there is little difference between Figures 5.1 and 5.2, but with two distinct routers in Figure 5.2, the interaction using CP is required. Of course, it is also possible to have multiple interfaces in each router and more than two routers.
与图5.1中的场景相比，使用两个物理路由器提供了额外的恢复能力。根据站点网络的任何管理策略，两个路由器之间的协调协议（CP）保持其动作同步。如今，这些功能在产品中可用。请注意，从逻辑上讲，图5.1和图5.2之间的差别不大，但对于图5.2中的两个不同路由器，需要使用CP进行交互。当然，也可以在每个路由器和两个以上的路由器中有多个接口。
For multihoming, the SBR does NOT need to be ILNP-capable for host multihoming or site multihoming. This is true provided the multihoming is left to individual hosts as described above. In this deployment approach, the SBR need only issue Routing Advertisements
对于多宿，SBR不需要具备主机多宿或站点多宿的ILNP能力。这是真实的，前提是如上所述，将多宿主留给各个主机。在这种部署方法中，SBR只需要发布路由公告
(RAs) that are correct with respect to its upstream connectivity; that is, the SBR properly advertises routing prefixes (Locator values) to the ILNP hosts.
（RAs）其上游连接正确；也就是说，SBR正确地向ILNP主机播发路由前缀（定位器值）。
In such a scenario, when hosts in the site network see new Locator values, and see that a previous Locator value is no longer being advertised, those hosts can update their ILCCs, send Locator Updates to CNs, and change connectivity as required.
在这种情况下，当站点网络中的主机看到新的定位器值，并且看到以前的定位器值不再被公布时，这些主机可以更新其ILCC，向CNs发送定位器更新，并根据需要更改连接。
ILNP supports mobility directly, rather than relying upon special-purpose mobility extensions as is the case with both IPv4 [RFC2002] (which was obsoleted by [RFC5944]) and IPv6 [RFC6275].
ILNP直接支持移动性，而不是像IPv4[RFC2002]（已被[RFC5944]淘汰）和IPv6[RFC6275]那样依赖专用移动性扩展。
There are two different mobility cases to consider:
需要考虑两种不同的机动性情况：
a) Host Mobility: individual hosts may be mobile, moving across administrative boundaries or topological boundaries within an IP-based network, or across the Internet. Such hosts would need to independently manage their own mobility.
a) 主机移动性：单个主机可以是移动的，可以在基于IP的网络中跨越管理边界或拓扑边界移动，也可以跨Internet移动。这样的主机需要独立管理自己的移动性。
b) Network (Site) Mobility: a whole site, i.e., one or more IP subnetworks may be mobile, moving across administrative boundaries or topological boundaries within an IP-based network, or across the Internet. The site as a whole needs to maintain consistency in connectivity.
b) 网络（站点）移动性：整个站点，即一个或多个IP子网可以是移动的，可以跨基于IP的网络内的管理边界或拓扑边界移动，也可以跨Internet移动。整个站点需要保持连接的一致性。
Essentially, for ILNP, mobility is implemented by enabling:
基本上，对于ILNP，移动性是通过以下方式实现的：
a) Locator values to be changed dynamically by a node, including for active network-layer sessions.
a) 节点动态更改的定位器值，包括活动网络层会话。
b) use of Locator Updates to allow active network-layer sessions to be maintained.
b) 使用定位器更新以允许维护活动网络层会话。
c) for those hosts that expect incoming network-layer or transport-layer session requests (e.g., servers), updates to the relevant DNS entries for those hosts.
c) 对于那些期望收到传入网络层或传输层会话请求的主机（例如服务器），更新这些主机的相关DNS条目。
It is possible that a device is both a mobile host and part of a mobile network, e.g., a smartphone in a mobile site network. This is supported in ILNP as the mechanism for mobile hosts and mobile networks are very similar and work in harmony.
设备可能既是移动主机又是移动网络的一部分，例如，移动站点网络中的智能手机。这在ILNP中得到支持，因为移动主机和移动网络的机制非常相似，并且协调工作。
For mobility, there are two general features that must be supported:
对于移动性，必须支持两个通用功能：
a) Handover (or Hand-off): when a host changes its connectivity (e.g., it has a new SNPA as it moves to a new ILNP subnetwork), any active network-layer sessions for that host must be maintained with minimal disruption (i.e., transparently) to the upper-layer protocols.
a) 切换（或切换）：当主机更改其连接时（例如，当它移动到新的ILNP子网时，它有一个新的SNPA），该主机的任何活动网络层会话都必须在对上层协议中断最小（即透明）的情况下进行维护。
b) Rendezvous: when a host that expects incoming network-layer or transport-layer session requests has new connectivity (e.g., it has a new SNPA as it moves to a new ILNP subnetwork), it needs to update its relevant DNS entries so that name resolution will provide the correct I and L values to remote nodes.
b) 会合：当期望传入网络层或传输层会话请求的主机具有新的连接（例如，它在移动到新的ILNP子网络时具有新的SNPA）时，它需要更新其相关DNS条目，以便名称解析将为远程节点提供正确的I和L值。
Mobility and multihoming present the same set of issues for ILNP. Indeed, mobility and multihoming form a duality: the set of Locators associated with a node or site changes. The reason for the change might be different for the case of mobility and multihoming, but the effects on the network-layer session state and on correspondents is identical.
移动性和多归属性为ILNP提出了相同的问题。事实上，移动性和多宿形成了二元性：与节点或站点相关联的定位器集发生了变化。对于移动性和多归属的情况，改变的原因可能不同，但对网络层会话状态和通信者的影响是相同的。
With ILNP, mobility and multihoming are supported using a common set of mechanisms. In both cases, different Locator values are used to identify different IP subnetworks. Also, ILNP nodes that expect incoming network-layer or transport-layer session requests are assumed to have a Fully Qualified Domain Name (FQDN) stored in the Domain Name System (DNS), as is already done within the deployed Internet. ILNP mobility normally relies upon the Secure Dynamic DNS Update standard for mobile nodes to update their location information in the DNS. This approach of using DNS for rendezvous with mobile systems was proposed earlier by others [PHG02].
在ILNP中，使用一组通用机制支持移动性和多址。在这两种情况下，使用不同的定位器值来标识不同的IP子网。此外，预期传入网络层或传输层会话请求的ILNP节点被假定具有存储在域名系统（DNS）中的完全限定域名（FQDN），这在已部署的Internet中已经完成。ILNP移动性通常依赖于移动节点的安全动态DNS更新标准来更新其在DNS中的位置信息。这种使用DNS与移动系统会合的方法是其他人较早提出的[PHG02]。
Host Mobility considers individual hosts that are individually mobile -- for example, a mobile telephone carried by a person walking in a city. Network (Site) Mobility considers a group of hosts within a local topology that move jointly and periodically change their uplinks to the rest of the Internet -- for example, a ship that has wired connections internally but one or more wireless uplinks to the rest of the Internet.
主机移动性考虑单独移动的主机——例如，在城市中行走的人携带的移动电话。网络（站点）移动性考虑本地拓扑中的一组主机，这些主机联合并定期更改其到Internet其余部分的上行链路——例如，一艘内部有有线连接但有一个或多个到Internet其余部分的无线上行链路的船。
For ILNP, Host Mobility is analogous to host multihoming (H-MH) and Network Mobility is analogous to site multihoming (S-MH). So, mobility and multihoming capabilities can be used together, without conflict.
对于ILNP，主机移动性类似于主机多宿（H-MH），网络移动性类似于站点多宿（S-MH）。因此，移动性和多主功能可以一起使用，而不会产生冲突。
With Host Mobility, each individual end-system manages its own connectivity through the use of Locator values. (This is very similar to the situation described for H-MH in Section 5.1.)
通过主机移动性，每个单独的终端系统通过使用定位器值来管理自己的连接。（这与第5.1节中描述的H-MH情况非常相似。）
Let us consider the network in Figure 6.1.
让我们考虑图6.1中的网络。
site . . . .
network A . .
. . . . +-------+ L_A . .
. . | +------. .
. . | | . .
. .---+ SBR_A | . .
. . | | . .
. H(1) . | | . .
. . +-------+ . .
. . . . . . . .
. H(2) . . Internet .
. . . . . . . .
. . +-------+ L_B . .
. H(3) . | +------. .
. . | | . .
. .---+ SBR_B | . .
. . | | . .
. . | | . .
. . . . +-------+ . .
site . .
network B . . . .
site . . . .
network A . .
. . . . +-------+ L_A . .
. . | +------. .
. . | | . .
. .---+ SBR_A | . .
. . | | . .
. H(1) . | | . .
. . +-------+ . .
. . . . . . . .
. H(2) . . Internet .
. . . . . . . .
. . +-------+ L_B . .
. H(3) . | +------. .
. . | | . .
. .---+ SBR_B | . .
. . | | . .
. . | | . .
. . . . +-------+ . .
site . .
network B . . . .
H(X) = host H at position X L_A = global Locator value A L_B = global Locator value B SBR = Site Border Router
H（X）=主机H在X位置L_A=全局定位器值A L_B=全局定位器值B SBR=站点边界路由器
Figure 6.1: A Simple Mobile Host Scenario for ILNP
图6.1:ILNP的简单移动主机场景
A host H is at position (1), hence H(1) in a site network A. This site network might be, for example, a single radio cell under administrative domain A. We assume that the host will move into site network B, which might be a single radio cell under administrative domain B. We also assume that the site networks have a region of overlap so that connectivity can be maintained; else, of course, the host will lose connectivity. Also, let us assume that the host already has ILNP connectivity in site network A.
主机H位于位置（1），因此H（1）位于站点网络A中。例如，此站点网络可能是管理域A下的单个无线小区。我们假设主机将移动到站点网络B中，这可能是管理域B下的单个无线小区。我们还假设站点网络有一个重叠区域，以便可以保持连接；当然，否则主机将失去连接。另外，假设主机在站点网络A中已经具有ILNP连接。
If site network A has connectivity via Locator value L_A, and H uses Identifier value I_H with a single interface ra0, then the host's ILCC will contain:
如果站点网络A通过定位器值L_A连接，并且H使用标识符值I_H与单个接口ra0，则主机的ILCC将包含：
[I_H, L_A] --- (18a)
L_A, ra0 --- (18b)
[I_H, L_A] --- (18a)
L_A, ra0 --- (18b)
Note the equivalence of expressions (18a) and (18b), respectively, with the expressions (15a) and (16a) for host multihoming.
请注意表达式（18a）和（18b）分别与主机多宿主的表达式（15a）和（16a）的等效性。
The host now moves into the overlap region of site networks A and B, and has position (2), hence H(2) as indicated in Figure 6.1. As this region is now in site network B, as well as site network A, H should see RAs from SBR_B for L_B, as well as the RAs for L_A from SBR_A. The host can now start to use L_B for its connectivity. The host H must now:
主机现在移动到站点网络A和B的重叠区域，并具有位置（2），因此H（2）如图6.1所示。由于该区域现在位于站点网络B和站点网络A中，H应该看到SBR_B中的RAs代表L_B，以及SBR_A中的L_A的RAs。主机现在可以开始使用L_B进行连接。主机H现在必须：
a) maintain existing active upper-layer sessions: based on its current ILCC entries and active sessions, send Locator Update (LU) messages to CNs to notify them of the change of L values. (LU messages are synonymous to Mobile IPv6 Binding Updates.)
a) 维护现有的活动上层会话：根据其当前的ILCC条目和活动会话，向CNs发送定位器更新（LU）消息，通知他们L值的更改。（LU消息与移动IPv6绑定更新同义。）
b) if required, update its relevant DNS entries with the new L value in the appropriate DNS records, to enable correct resolution for new incoming network-layer or transport-layer session requests.
b) 如果需要，使用相应DNS记录中的新L值更新其相关DNS条目，以便为新传入的网络层或传输层会话请求启用正确的解析。
However, it can opt to do this one of two ways:
但是，它可以选择以下两种方式之一：
1) immediate handover: the host sends Locator Update (LU) messages to CNs, immediately stops using L_A, and switches to using L_B only. In this case, its ILCC entries change to:
1) 立即切换：主机向CNs发送定位器更新（LU）消息，立即停止使用L_A，并切换到仅使用L_B。在这种情况下，其ILCC条目更改为：
[I_H, L_B] --- (19a)
L_B, ra0 --- (19b)
[I_H, L_B] --- (19a)
L_B, ra0 --- (19b)
There might be packets in flight to H that use L_A, and H MAY choose to ignore these on reception.
在飞往H的过程中可能有使用L_A的数据包，H可能会选择在接收时忽略这些数据包。
2) soft handover: the host sends Locator Update (LU) messages to CNS, but it uses both L_A and L_B until (i) it no longer receives incoming packets with destination Locator values set to L_A within a given time period and (ii) it no longer sees RAs for L_A (i.e., it has left the overlap region and so has left site network A). In this case, its ILCC entries change to:
2) 软切换：主机向CNS发送定位器更新（LU）消息，但它同时使用L_A和L_B，直到（i）在给定时间段内不再接收目标定位器值设置为L_A的传入数据包，以及（ii）不再看到L_A的RAs（即，它已离开重叠区域，因此离开了站点网络A）。在这种情况下，其ILCC条目更改为：
[I_H, L_A] --- (20a)
L_A, ra0 --- (20b)
[I_H, L_B] --- (20c)
L_B, ra0 --- (20d)
[I_H, L_A] --- (20a)
L_A, ra0 --- (20b)
[I_H, L_B] --- (20c)
L_B, ra0 --- (20d)
ILNP does not mandate the use of one handover option over another. Indeed, a host may implement both and decide, through local policy or other mechanisms (e.g., under the control of a particular transport protocol implementation), to use one or other for a specific transport-layer session, as required.
ILNP不强制使用一种切换选项而不是另一种。实际上，主机可以实现这两者，并根据需要通过本地策略或其他机制（例如，在特定传输协议实现的控制下）决定将一个或另一个用于特定传输层会话。
Note that if using soft handover, when in the overlap region, the host is multihomed. Also, soft handover is likely to provide a less disruptive handover (e.g., lower packet loss) compared to immediate handover, all other things being equal.
请注意，如果使用软切换，当处于重叠区域时，主机是多址的。此外，在所有其他条件相同的情况下，与即时切换相比，软切换可能提供更少的中断性切换（例如，更低的分组丢失）。
There is a case where both the host and its correspondent node are mobile. In the unlikely event of simultaneous motion that changes both nodes' Locators within a very small time period, there is the possibility that communication may be lost. If the communication between the nodes was direct (i.e., one node initiated communication with another, through a DNS lookup), a node can use the DNS to discover the new Locator value(s) for the other node. If the communication was through some sort of middlebox providing a relay service, then communication is more likely to disrupted only if the middlebox is also mobile.
在这种情况下，主机及其对应节点都是移动的。在不太可能的情况下，同时运动会在很短的时间内改变两个节点的定位器，因此可能会丢失通信。如果节点之间的通信是直接的（即，一个节点通过DNS查找发起与另一个节点的通信），则节点可以使用DNS来发现另一个节点的新定位器值。如果通信是通过某种提供中继服务的中间箱进行的，那么只有在中间箱也是移动的情况下，通信才更有可能中断。
It is also possible that high packet loss results in Locator Updates being lost, which could disrupt handover. However, this is an engineering issue and does not impact the basic concept of operation; additional discussion on this issue is provided in [RFC6741].
高数据包丢失也可能导致定位器更新丢失，从而中断切换。然而，这是一个工程问题，不影响基本的运行概念；[RFC6741]中提供了关于此问题的更多讨论。
Of course, for any handover, the new end-to-end path through SBR_B might have very different end-to-end path characteristics (e.g., different end-to-end delay, packet loss, throughput). Also, the physical connectivity on interface ra0 as well as through SBR_B's uplink may be different. Such impacts on end-to-end packet transfer are outside the scope of ILNP.
当然，对于任何切换，通过SBR_B的新的端到端路径可能具有非常不同的端到端路径特征（例如，不同的端到端延迟、分组丢失、吞吐量）。此外，接口ra0上以及通过SBR_B上行链路的物理连接可能不同。这种对端到端数据包传输的影响超出了ILNP的范围。
For network mobility, a whole site may be mobile, e.g., the SBRs of Figure 6.1 have a radio uplink on a moving vehicle. Within the site, individual hosts may or may not be mobile.
对于网络移动性，整个站点可以是移动的，例如，图6.1中的SBR在移动车辆上具有无线上行链路。在站点内，单个主机可能是移动的，也可能不是移动的。
In the simplest case, ILNP deals with mobile networks in the same way as for site multihoming: the management of mobility is delegated to each host in the site, so it needs to be ILNP-capable. Each host,
在最简单的情况下，ILNP以与站点多归属相同的方式处理移动网络：移动管理委托给站点中的每个主机，因此需要具有ILNP能力。每一位主持人，
effectively, behaves as if it were a mobile host, even though it may not actually be mobile. Indeed, in this way, the mechanism is very similar to that for site multihoming. Let us consider the mobile network in Figure 6.2.
实际上，它的行为就像是一个移动主机，即使它实际上可能不是移动主机。事实上，通过这种方式，该机制与站点多宿主机制非常相似。让我们考虑图6.2中的移动网络。
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . | ra1+------. .
. .----+ | . .
. H . | ra2+-- . .
. . . . +------+ . .
. . .
Figure 6.2a: ILNP Mobile Network before Handover
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . | ra1+------. .
. .----+ | . .
. H . | ra2+-- . .
. . . . +------+ . .
. . .
Figure 6.2a: ILNP Mobile Network before Handover
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . | ra1+------. . . . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ L_2 . . . . .
. .
. . .
ISP_2
Figure 6.2b: ILNP Mobile Network during Handover
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . | ra1+------. . . . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ L_2 . . . . .
. .
. . .
ISP_2
Figure 6.2b: ILNP Mobile Network during Handover
site ISP_2
network SBR . . .
. . . . +------+ . .
. . | ra1+-- . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ . .
. . .
Figure 6.2c: ILNP Mobile Network after Handover
site ISP_2
network SBR . . .
. . . . +------+ . .
. . | ra1+-- . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ . .
. . .
Figure 6.2c: ILNP Mobile Network after Handover
H = host L_1 = global Locator value 1 L_2 = global Locator value 2 SBR = Site Border Router
H=主机L_1=全局定位器值1 L_2=全局定位器值2 SBR=站点边界路由器
Figure 6.2: A Simple Mobile Network Scenario for ILNP
图6.2:ILNP的简单移动网络场景
In Figure 6.2, we assume that the site network is mobile, and the SBR has two radio interfaces ra1 and ra2. However, this particular figure is chosen for simplicity and clarity for our scenario, and other configurations are possible, e.g., a single radio interface which uses separate radio channels (separate carriers, coding channels, etc.). In the figure, ISP_1 and ISP_2 are separate, radio-based service providers, accessible via ra1 and ra2.
在图6.2中，我们假设站点网络是移动的，SBR有两个无线电接口ra1和ra2。然而，选择该特定图是为了我们的场景的简单性和清晰性，并且其他配置是可能的，例如，使用单独无线电信道（单独载波、编码信道等）的单个无线电接口。在图中，ISP_1和ISP_2是独立的、基于无线电的服务提供商，可通过ra1和ra2访问。
In Figure 6.2a, the SBR has connectivity via ISP_1 using Locator value L_1. The host H, with interface ra0 and Identifier I_H, has an established connectivity via the SBR and so has ILCC entries as shown in (21):
在图6.2a中，SBR使用定位器值L_1通过ISP_1连接。具有接口ra0和标识符I_H的主机H通过SBR建立连接，因此具有ILCC条目，如（21）所示：
[I_H, L_1] --- (21a)
L_1, ra0 --- (21b)
[I_H, L_1] --- (21a)
L_1, ra0 --- (21b)
Note the equivalence to expressions (18a) and (18b). As the whole network moves, the SBR detects a new radio provider, ISP_2, and connects to it using ra2, as shown in Figure 6.2b, with the service areas of ISP_1 and ISP_2 overlapping. ISP_2 provides Locator L_2, which the SBR advertises into the site network along with L_1. As with the mobile host scenario above, individual hosts may decide to perform immediate handover or soft handover. So, the ILCC state for H will be as for expressions (19a) and (19b) and (20a)-(20d), but with L_1 in place of L_A, and L_2 in place of L_B. Finally, as in Figure 6.2c, the site network moves and is no longer served by ISP_1, and handover is complete. Note that during the handover the site is multihomed, as in Figure 6.2b.
注意表达式（18a）和（18b）的等价性。随着整个网络的移动，SBR检测到一个新的无线提供商ISP_2，并使用ra2连接到它，如图6.2b所示，ISP_1和ISP_2的服务区域重叠。ISP_2提供定位器L_2，SBR将其与L_1一起发布到站点网络中。与上面的移动主机场景一样，各个主机可能决定执行即时切换或软切换。因此，H的ILCC状态将与表达式（19a）和（19b）以及（20a）-（20d）相同，但用L_1代替L_A，用L_2代替L_B。最后，如图6.2c所示，站点网络移动，不再由ISP_1服务，切换完成。请注意，在移交期间，站点是多址的，如图6.2b所示。
As for multihoming, the SBR does NOT need to be ILNP-capable: it simply needs to advertise the available routing prefixes into the site network. The mobility capability is handled completely by the hosts.
至于多宿，SBR不需要具备ILNP功能：它只需要将可用的路由前缀发布到站点网络中。移动能力完全由主机处理。
Just as Section 5.3.1 describes the use of multiple routers for multihoming, so it is possible to have multiple routers for mobility for ILNP, for both mobile hosts and mobile networks.
正如第5.3.1节所述，多个路由器用于多归属，因此，对于移动主机和移动网络，ILNP的移动性可以有多个路由器。
IP Security for ILNP [RFC6741] becomes simpler, in principle, than IPsec as it is today, based on the use of IP Addresses as Identifiers.
基于IP地址作为标识符的使用，ILNP[RFC6741]的IP安全原则上比今天的IPsec更简单。
An operational issue in the deployed IP Internet is that the IPsec protocols, AH and ESP, have Security Associations (IPsec SAs) that include the IP Addresses of the secure IPsec session endpoints. This was understood to be a problem when AH and ESP were originally defined in [RFC1825], [RFC1826], and [RFC1827] (which were obsoleted by [RFC4301], [RFC4302], and [RFC4303]). However, the limited set of namespaces in the Internet Architecture did not provide any better choices at that time. ILNP provides more namespaces, thus now enabling better IPsec architecture and engineering.
部署的IP Internet中的一个操作问题是，IPsec协议AH和ESP具有安全关联（IPsec SA），其中包括安全IPsec会话端点的IP地址。当AH和ESP最初在[RFC1825]、[RFC1826]和[RFC1827]中定义时（被[RFC4301]、[RFC4302]和[RFC4303]淘汰），这被认为是一个问题。然而，当时互联网体系结构中有限的名称空间并没有提供更好的选择。ILNP提供了更多的名称空间，因此现在可以实现更好的IPsec体系结构和工程。
In essence, ILNP provides a very simple architectural change to IPsec: in place of IP Addresses as used today for IPsec SAs, ILNP uses Node Identifier values instead. Recall that Identifier values are immutable once in use, so they can be used to maintain end-to-end state for any protocol that requires it. Note from the discussion above that the Identifier values for a host remain unchanged when multihoming and mobility are in use, so IPsec using ILNP can work in harmony with multihoming and mobility [ABH08b] [ABH09a].
本质上，ILNP为IPsec提供了一个非常简单的体系结构更改：ILNP使用节点标识符值代替目前用于IPsec SAs的IP地址。回想一下，标识符值在使用时是不可变的，因此它们可以用于维护任何需要它的协议的端到端状态。从上面的讨论中注意到，当使用多主和移动性时，主机的标识符值保持不变，因此使用ILNP的IPsec可以与多主和移动性协调工作[ABH08b][ABH09a]。
To resolve the issue of IPsec interoperability through a Network Address Translator (NAT) deployment [RFC1631] [RFC3022], UDP encapsulation of IPsec [RFC3948] is commonly used as of the date this document was published. This special-case handling for IPsec traffic traversing a NAT is not needed with ILNP IPsec.
为了通过网络地址转换器（NAT）部署[RFC1631][RFC3022]解决IPsec互操作性问题，自本文档发布之日起，通常使用IPsec[RFC3948]的UDP封装。ILNP IPsec不需要对穿越NAT的IPsec流量进行这种特殊情况处理。
Further, it would obviate the need for specialised IPsec NAT traversal mechanisms, thus simplifying IPsec implementations while enhancing deployability and interoperability [RFC3948].
此外，它将消除对专用IPsec NAT遍历机制的需要，从而简化IPsec实现，同时增强可部署性和互操作性[RFC3948]。
This architectural change does not reduce the security provided by the IPsec protocols. In fact, had the Node Identifier namespace existed back in the early 1990s, IPsec would always have bound to that location-independent Node Identifier and would not have bound to IP Addresses.
此体系结构更改不会降低IPsec协议提供的安全性。事实上，如果节点标识符名称空间早在20世纪90年代初就存在，IPsec将始终绑定到该位置独立的节点标识符，而不会绑定到IP地址。
Operationally, this change in SA bindings to use Identifiers rather than IP Addresses causes problems for the use of the IPsec protocols through IP Network Address Translation (NAT) devices, with mobile nodes (because the mobile node's IP Address changes at each network-layer handoff), and with multihomed nodes (because the network-layer IPsec session is bound to a particular interface of the multihomed node, rather than being bound to the node itself) [RFC3027] [RFC3715].
在操作上，SA绑定中使用标识符而不是IP地址的这种变化会导致通过IP网络地址转换（NAT）设备、移动节点（因为移动节点的IP地址在每个网络层切换时发生变化）和多宿节点使用IPsec协议的问题（因为网络层IPsec会话绑定到多宿节点的特定接口，而不是绑定到节点本身）[RFC3027][RFC3715]。
ILNPv6 is fully backwards compatible with existing IPv6. No router software or silicon changes are necessary to support the proposed enhancements. An IPv6 router would be unaware whether the packet being forwarded were classic IPv6 or the proposed enhancement in ILNPv6. IPv6 Neighbour Discovery will work unchanged for ILNPv6. ILNPv6 multicasting is the same as IETF standards-track IPv6 multicasting.
ILNPv6与现有IPv6完全向后兼容。无需对路由器软件或硅片进行任何更改即可支持拟议的增强功能。IPv6路由器将不知道转发的数据包是经典IPv6还是ILNPv6中建议的增强。IPv6邻居发现对于ILNPv6将保持不变。ILNPv6多播与IETF标准跟踪IPv6多播相同。
ILNPv4 is backwards compatible with existing IPv4. As the IPv4 address fields are used as 32-bit Locators, using only the address prefix bits of the 32-bit space, IPv4 routers also would not require changes. An IPv4 router would be unaware whether the packet being forwarded were classic IPv4 or the proposed enhancement in ILNPv4 [RFC6746]. ARP [RFC826] requires enhancements to support ILNPv4 [RFC6747] [RFC6741]. ILNPv4 multicasting is the same as IETF standards-track IPv4 multicasting.
ILNPv4与现有IPv4向后兼容。由于IPv4地址字段用作32位定位器，仅使用32位空间的地址前缀位，IPv4路由器也不需要更改。IPv4路由器将不知道转发的数据包是经典IPv4还是ILNPv4[RFC6746]中建议的增强。ARP[RFC826]需要增强以支持ILNPv4[RFC6747][RFC6741]。ILNPv4多播与IETF标准跟踪IPv4多播相同。
If a node supports ILNP and intends to receive incoming network-layer or transport-layer sessions, the node's Fully Qualified Domain Name (FQDN) normally will have one or more NID records and one or more Locator (i.e., L32, L64, and/or LP) records associated with the node within the DNS [RFC6741] [RFC6742].
如果节点支持ILNP并打算接收传入的网络层或传输层会话，则该节点的完全限定域名（FQDN）通常将具有一个或多个NID记录以及与DNS[RFC6741][RFC6742]内的节点相关联的一个或多个定位器（即L32、L64和/或LP）记录。
When an IP host ("initiator") initiates a new network-layer session with a correspondent ("responder"), it normally will perform a DNS lookup to determine the address(es) of the responder. An ILNP host normally will look for Node Identifier ("NID") and Locator (i.e., L32, L64, and LP) records in any received DNS replies. DNS servers that support NID and Locator (i.e., L32, L64, and LP) records SHOULD include them (when they exist) as additional data in all DNS replies to queries for DNS AAAA records [RFC6742].
当IP主机（“启动器”）与对应方（“响应方”）启动新的网络层会话时，它通常会执行DNS查找以确定响应方的地址。ILNP主机通常会在任何接收到的DNS应答中查找节点标识符（“NID”）和定位器（即L32、L64和LP）记录。支持NID和定位器（即L32、L64和LP）记录的DNS服务器应将它们（当它们存在时）作为附加数据包含在对DNS AAAA记录查询的所有DNS回复中[RFC6742]。
If the initiator supports ILNP, and from DNS information learns that the responder also supports ILNP, then the initiator will generate an unpredictable ILNP Nonce value, cache that value locally as part of the network-layer ILNP session, and will include the ILNP Nonce value in its initial packet(s) to the responder [RFC6741] [RFC6744] [RFC6746].
如果发起者支持ILNP，并且从DNS信息得知响应者也支持ILNP，则发起者将生成不可预测的ILNP Nonce值，将该值作为网络层ILNP会话的一部分本地缓存，并将ILNP Nonce值包括在发送给响应者的初始数据包中[RFC6741][RFC6744][RFC6746]。
If the initiator node does not find any ILNP-specific DNS resource records for the responder node, then the initiator uses classic IP for the new network-layer session with the responder, rather than trying to use ILNP for that network-layer session. Of course, multiple transport-layer sessions can concurrently share a single network-layer (e.g., IP or ILNP) session.
如果发起方节点未找到响应方节点的任何ILNP特定DNS资源记录，则发起方将使用经典IP与响应方进行新的网络层会话，而不是尝试将ILNP用于该网络层会话。当然，多个传输层会话可以同时共享单个网络层（例如，IP或ILNP）会话。
If the responder node for a new network-layer session does not support ILNP and the responder node receives initial packet(s) containing the ILNP Nonce, then the responder will drop the packet and send an ICMP error message back to the initiator. If the responder node for a new network-layer session supports ILNP and receives initial packet(s) containing the ILNP Nonce, the responder learns that ILNP is in use for that network-layer session (i.e., by the presence of that ILNP Nonce).
如果新网络层会话的响应者节点不支持ILNP，并且响应者节点接收到包含ILNP Nonce的初始数据包，则响应者将丢弃该数据包并将ICMP错误消息发送回启动器。如果新网络层会话的响应者节点支持ILNP并接收到包含ILNP Nonce的初始分组，则响应者得知ILNP正用于该网络层会话（即，通过该ILNP Nonce的存在）。
If the initiator node using ILNP does not receive a response from the responder in a timely manner (e.g., within TCP timeout for a TCP session) and also does not receive an ICMP Unreachable error message for that packet, OR if the initiator receives an ICMP Parameter Problem error message for that packet, then the initiator concludes that the responder does not support ILNP. In this case, the initiator node SHOULD try again to create the new network-layer session, but this time using IP (and therefore omitting the ILNP Nonce).
如果使用ILNP的发起方节点没有及时从响应方接收到响应（例如，在TCP会话的TCP超时内），也没有接收到该数据包的ICMP不可访问错误消息，或者如果发起方接收到该数据包的ICMP参数问题错误消息，然后发起者得出结论，响应者不支持ILNP。在这种情况下，发起方节点应再次尝试创建新的网络层会话，但这次使用IP（因此省略ILNP Nonce）。
Finally, since an ILNP node also is a fully capable IP node, the upgraded node can use any standardised IP mechanisms for communicating with a legacy IP-only node. So, ILNP will not be worse than existing IP, but when ILNP is used, the enhanced capabilities described in these ILNP documents will be available.
最后，由于ILNP节点也是完全有能力的IP节点，升级后的节点可以使用任何标准化的IP机制与传统的纯IP节点通信。因此，ILNP不会比现有IP差，但当使用ILNP时，这些ILNP文档中描述的增强功能将可用。
This proposal outlines a proposed evolution for the Internet Architecture to provide improved capabilities. This section discusses security considerations for this proposal.
本提案概述了互联网体系结构的拟议演变，以提供改进的功能。本节讨论此提案的安全注意事项。
Note that ILNP provides security equivalent to IP for similar threats when similar mitigations (e.g., IPsec or not) are in use. In some cases, but not all, ILNP exceeds that objective and has lower security risk than IP. Additional engineering details for several of these topics can be found in [RFC6741].
请注意，ILNP在使用类似的缓解措施（如IPsec或未使用IPsec）时，为类似的威胁提供与IP等效的安全性。在某些情况下，但并非所有情况下，ILNP都超过了这一目标，并且具有比IP更低的安全风险。[RFC6741]中提供了其中几个主题的其他工程细节。
All Locator Update messages are authenticated. ILNP requires use of an ILNP session nonce [RFC6744] [RFC6746] to prevent off-path attacks, and also allows use of IPsec cryptography to provide stronger protection where required.
所有定位器更新消息都经过身份验证。ILNP需要使用ILNP会话nonce[RFC6744][RFC6746]来防止非路径攻击，并且还允许在需要时使用IPsec加密来提供更强的保护。
Ordinary network-layer sessions based on IP are vulnerable to on-path attacks unless IPsec is used. So the Nonce Destination Option only seeks to provide protection against off-path attacks on an ILNP-based network-layer session -- equivalent to ordinary IP-based network-layer sessions that are not using IPsec.
除非使用IPsec，否则基于IP的普通网络层会话容易受到路径攻击。因此，Nonce-Destination选项仅寻求在基于ILNP的网络层会话上提供对非路径攻击的保护——相当于不使用IPsec的普通基于IP的网络层会话。
It is common to have non-symmetric paths between two nodes on the Internet. To reduce the number of on-path nodes that know the Nonce value for a given session when ILNP is in use, a nonce value is unidirectional, not bidirectional. For example, for a network-layer ILNP-based session between nodes A and B, one nonce value is used from A to B and a different nonce value is used from B to A.
在Internet上的两个节点之间存在非对称路径是很常见的。为了减少在使用ILNP时知道给定会话的Nonce值的路径上节点的数量，Nonce值是单向的，而不是双向的。例如，对于节点a和B之间基于网络层ILNP的会话，从a到B使用一个nonce值，从B到a使用不同的nonce值。
ILNP sessions operating in higher risk environments SHOULD also use the cryptographic authentication provided by IPsec *in addition* to concurrent use of the ILNP Nonce.
在高风险环境中运行的ILNP会话除了并行使用ILNP Nonce外，还应使用IPsec*提供的加密身份验证。
It is important to note that, at present, a network-layer IP-based session is entirely vulnerable to on-path attacks unless IPsec is in use for that particular IP session, so the security properties of the new proposal are never worse than for existing IP.
重要的是要注意，目前，基于网络层IP的会话完全容易受到路径攻击，除非IPsec用于该特定IP会话，因此新方案的安全性永远不会比现有IP更差。
In the deployed Internet, active attacks using packets with a forged Source IP Address have been publicly known at least since early 1995 [CA-1995-01]. While these exist in the deployed Internet, they have not been widespread. This is equivalent to the issue of a forged Identifier value and demonstrates that this is not a new threat created by ILNP.
在部署的互联网中，至少自1995年初以来，使用伪造源IP地址的数据包进行的主动攻击已为公众所知[CA-1995-01]。虽然这些存在于已部署的Internet中，但它们还没有普及。这相当于伪造标识符值的问题，并证明这不是ILNP造成的新威胁。
One mitigation for these attacks has been to deploy Source IP Address filtering [RFC2827] [RFC3704]. Jun Bi at Tsinghua University cites Arbor Networks as reporting that this mechanism has less than 50% deployment and cites an MIT analysis indicating that at least 25% of the deployed Internet permits forged Source IP Addresses.
针对这些攻击的一种缓解措施是部署源IP地址过滤[RFC2827][RFC3704]。清华大学的毕军（Jun Bi）引用Arbor Networks的报告称，这种机制的部署不到50%，并引用了麻省理工学院的一项分析，该分析表明，至少25%的部署互联网允许伪造源IP地址。
In [RFC6741], there is a discussion of an accidental use of a duplicate Identifier on the Internet. However, this sub-section instead focuses on methods for mitigating attacks based on packets containing deliberately forged Source Identifier values.
[RFC6741]中讨论了在互联网上意外使用重复标识符的问题。然而，本小节将重点介绍基于包含故意伪造的源标识符值的数据包减轻攻击的方法。
Firstly, the recommendations of [RFC2827] and [RFC3704] remain. So, any packets that have a forged Locator value can be easily filtered using existing widely available mechanisms.
首先，[RFC2827]和[RFC3704]的建议仍然存在。因此，任何具有伪造定位器值的数据包都可以使用现有的广泛可用的机制轻松过滤。
Secondly, the receiving node does not blindly accept any packet with the proper Source Identifier and proper Destination Identifier as an authentic packet. Instead, each ILNP node maintains an ILNP Communication Cache (ILCC) for each of its correspondents, as described in [RFC6741]. Information in the cache is used in validating received messages and preventing off-path attackers from succeeding. This process is discussed more in [RFC6741].
其次，接收节点不盲目地接受具有适当源标识符和适当目的标识符的任何分组作为真实分组。相反，如[RFC6741]所述，每个ILNP节点为其每个对应方维护一个ILNP通信缓存（ILCC）。缓存中的信息用于验证接收到的消息并防止非路径攻击者成功。[RFC6741]中详细讨论了此过程。
Thirdly, any node can distinguish different nodes using the same Identifier value by other properties of their ILNP sessions. For example, IPv6 Neighbor Discovery prevents more than one node from using the same source I-LV at the same time on the same link [RFC4861]. So, cases of different nodes using the same Identifier value will involve nodes that have different sets of valid Locator values. A node thus can demultiplex based on the combination of Source Locator and Source Identifier if necessary. If IPsec is in use, the combination of the Source Identifier and the Security Parameter Index (SPI) value would be sufficient to demux two different ILNP sessions.
第三，任何节点都可以通过其ILNP会话的其他属性来区分使用相同标识符值的不同节点。例如，IPv6邻居发现可防止多个节点在同一链路上同时使用同一源I-LV[RFC4861]。因此，不同节点使用相同标识符值的情况将涉及具有不同有效定位器值集的节点。因此，如果需要，节点可以基于源定位器和源标识符的组合来解复用。如果使用IPsec，则源标识符和安全参数索引（SPI）值的组合将足以解复用两个不同的ILNP会话。
Fourthly, deployments in high-threat environments also SHOULD use IPsec to authenticate control traffic and data traffic. Because IPsec for ILNP binds only to the Identifier values, and never to the Locator values, a mobile or multihomed node can use IPsec even when its Locator value(s) have just changed.
第四，在高威胁环境中的部署还应使用IPsec对控制流量和数据流量进行身份验证。由于IPsec for ILNP仅绑定到标识符值，而从不绑定到定位器值，因此移动或多宿节点可以使用IPsec，即使其定位器值刚刚更改。
Lastly, note well that ordinary IPv4, ordinary IPv6, Mobile IPv4, and also Mobile IPv6 already are vulnerable to forged Identifier and/or forged IP Address attacks. An attacker on the same link as the intended victim simply forges the victims MAC address and the victim's IP Address. With IPv6, when Secure Neighbour Discovery (SEND) and Cryptographically Generated Addresses (CGAs) are in use, the victim node can defend its use of its IPv6 address using SEND. With ILNP, when SEND and CGAs are in use, the victim node also can defend its use of its IPv6 address using SEND. There are no standard mechanisms to authenticate ARP messages, so IPv4 is especially vulnerable to this sort of attack. These attacks also work against Mobile IPv4 and Mobile IPv6. In fact, when either form of Mobile IP is in use, there are additional risks, because the attacks work not only when the attacker has access to the victim's current IP subnetwork but also when the attacker has access to the victim's home IP subnetwork. Thus, the risks of using ILNP are not greater than exist today with IP or Mobile IP.
最后，请注意，普通IPv4、普通IPv6、移动IPv4以及移动IPv6已经很容易受到伪造标识符和/或伪造IP地址攻击。与目标受害者在同一链路上的攻击者只是伪造受害者的MAC地址和IP地址。在IPv6中，当使用安全邻居发现（SEND）和加密生成地址（CGA）时，受害节点可以使用SEND保护其IPv6地址的使用。使用ILNP，当使用SEND和CGA时，受害节点还可以使用SEND保护其IPv6地址的使用。没有标准的机制来验证ARP消息，因此IPv4特别容易受到此类攻击。这些攻击还针对移动IPv4和移动IPv6。事实上，当使用任何一种形式的移动IP时，都存在额外的风险，因为攻击不仅在攻击者能够访问受害者当前的IP子网络时有效，而且在攻击者能够访问受害者的家庭IP子网络时也有效。因此，使用ILNP的风险并不比目前使用IP或移动IP的风险大。
The IPsec standards are enhanced here by binding IPsec Security Associations (SAs) to the Node Identifiers of the endpoints, rather than binding IPsec SAs to the IP Addresses of the endpoints as at present. This change enhances the deployability and interoperability of the IPsec standards, but does not decrease the security provided by those protocols. See Section 7 for a more detailed explanation.
通过将IPsec安全关联（SA）绑定到端点的节点标识符，而不是像目前那样将IPsec SA绑定到端点的IP地址，IPsec标准在这里得到了增强。此更改增强了IPsec标准的可部署性和互操作性，但不会降低这些协议提供的安全性。有关更详细的说明，请参见第7节。
The DNS enhancements proposed here are entirely compatible with, and can be protected using, the existing IETF standards for DNS Security [RFC4033]. The Secure DNS Dynamic Update mechanism used here is also used unchanged [RFC3007]. So, ILNP does not change the security properties of the DNS or of DNS servers.
此处提出的DNS增强功能与现有的IETF DNS安全标准[RFC4033]完全兼容，并且可以使用这些标准进行保护。此处使用的安全DNS动态更新机制也会原封不动地使用[RFC3007]。因此，ILNP不会更改DNS或DNS服务器的安全属性。
In the proposed new scheme, stateful firewalls are able to authenticate ILNP-specific control messages arriving on the external interface. This enables more thoughtful handling of ICMP messages by firewalls than is commonly the case at present. As the firewall is along the path between the communicating nodes, the firewall can snoop on the ILNP Nonce being carried in the initial packets of an ILNP session. The firewall can verify the correct ILNP Nonce is present on incoming control packets, dropping any control packets that lack the correct nonce value.
在提出的新方案中，有状态防火墙能够对到达外部接口的特定于ILNP的控制消息进行身份验证。这使得防火墙能够比目前更周全地处理ICMP消息。由于防火墙沿着通信节点之间的路径，防火墙可以窥探ILNP会话的初始数据包中携带的ILNP Nonce。防火墙可以验证传入控制数据包上是否存在正确的ILNP Nonce，从而丢弃任何缺少正确Nonce值的控制数据包。
By always including the ILNP Nonce in ILNP-specific control messages, even when IPsec is also in use, the firewall can filter out off-path attacks against those ILNP messages without needing to perform computationally expensive IPsec processing. In any event, a forged packet from an on-path attacker will still be detected when the IPsec input processing occurs in the receiving node; this will cause that forged packet to be dropped rather than acted upon.
通过始终在ILNP特定的控制消息中包含ILNP Nonce，即使IPsec也在使用中，防火墙也可以过滤掉针对这些ILNP消息的非路径攻击，而无需执行计算昂贵的IPsec处理。在任何情况下，当接收节点中发生IPsec输入处理时，仍然会检测到来自路径上攻击者的伪造数据包；这将导致伪造的数据包被丢弃，而不是采取行动。
Nothing in this proposal prevents sites from using the Secure Neighbour Discovery (SEND) proposal for authenticating IPv6 Neighbour Discovery with ILNPv6 [RFC3971].
此方案中的任何内容都不会阻止站点使用安全邻居发现（SEND）方案通过ILNPv6[RFC3971]验证IPv6邻居发现。
A site that wishes to obscure its internal topology information MAY do so by deploying site border routers that rewrite the Locator values for the site as packets enter or leave the site. This operational scenario was presented in [ABH09a] and is discussed in more detail in [RFC6748].
希望隐藏其内部拓扑信息的站点可以通过部署站点边界路由器来实现，该路由器在数据包进入或离开站点时重写站点的定位器值。该操作场景在[ABH09a]中介绍，并在[RFC6748]中进行了更详细的讨论。
For example, a site might choose to use a ULA prefix internally for this reason [RFC4193] [ID-ULA]. In this case, the site border routers would rewrite the Source Locator of ILNP packets leaving the site to a global-scope Locator associated with the site. Also, those site border routers would rewrite the Destination Locator of packets entering the site from the global-scope Locator to an appropriate interior ULA Locator for the destination node [ABH08b] [ABH09a] [RFC6748].
例如，站点可能会因为这个原因选择在内部使用ULA前缀[RFC4193][ID-ULA]。在这种情况下，站点边界路由器将把离开站点的ILNP数据包的源定位器重写为与站点相关联的全局范围定位器。此外，这些站点边界路由器将把进入站点的数据包的目的地定位器从全局范围定位器重写为目的地节点的适当内部ULA定位器[ABH08b][ABH09a][RFC6748]。
ILNP has support for both:
ILNP支持以下两种功能：
- Location Privacy: to hide a node's topological location by obfuscating the ILNP Locator information. (See also Section 7 of [RFC6748].)
- 位置隐私：通过混淆ILNP定位器信息来隐藏节点的拓扑位置。（另见[RFC6748]第7节）
- Identity Privacy: to hide a node's identity by allowing the use of Node Identifier values that are not tied to the node in some permanent or semi-permanent manner. (See also Section 11 of [RFC6741].)
- 身份隐私：通过允许使用未以某种永久或半永久方式绑定到节点的节点标识符值来隐藏节点的身份。（另见[RFC6741]第11节）
A more detailed exposition of the possibilities is given in [BAK11].
[BAK11]中给出了更详细的可能性说明。
Some users have concerns about the issue of "location privacy", whereby the user's location might be determined by others. The term "location privacy" does not have a crisp definition within the Internet community at present. Some mean the location of a node relative to the Internet's routing topology, while others mean the geographic coordinates of the node (i.e., latitude X, longitude Y). The concern seems to focus on Internet-enabled devices, most commonly handheld devices such as a smartphone, that might have 1:1 mappings with individual users.
一些用户担心“位置隐私”问题，即用户的位置可能由其他人确定。“位置隐私”一词目前在互联网社区中没有明确的定义。一些表示节点相对于Internet路由拓扑的位置，而另一些表示节点的地理坐标（即纬度X、经度Y）。关注点似乎集中在支持互联网的设备上，最常见的是手持设备，如智能手机，它们可能与个人用户有1:1的映射。
There is a fundamental trade-off here. Quality of a node's Internet connectivity tends to be inversely proportional to the "location privacy" of that node. For example, if a node were to use a router with NAT as a privacy proxy, routing all traffic to and from the
这里有一个基本的权衡。节点的互联网连接质量往往与该节点的“位置隐私”成反比。例如，如果一个节点使用带有NAT的路由器作为隐私代理，则将所有流量路由到
Internet via that proxy, then (a) latency will increase as the distance increases between the node seeking privacy and its proxy, and (b) communications with the node seeking privacy will be more vulnerable to communication faults -- both due to the proxy itself (which might fail) and due to the longer path (which has more points of potential failure than a more direct path would have).
通过该代理访问Internet，则（a）延迟将随着寻求隐私的节点与其代理之间距离的增加而增加，（b）与寻求隐私的节点之间的通信将更容易发生通信故障——这是由于代理本身（可能会失败）和路径较长（与更直接的路径相比，具有更多潜在故障点）。
Any Internet node that wishes for other Internet nodes to be able to initiate transport-layer or network-layer sessions with it needs to include associated address (e.g., A, AAAA) or Locator (e.g., L32, L64, LP) records in the publicly accessible Domain Name System (DNS). Information placed in the DNS is publicly accessible. Since the goal of DNS is to distribute information to other Internet nodes, it does not provide mechanisms for selective privacy. Of course, a node that does not wish to be contacted need not be present in the DNS.
任何希望其他Internet节点能够与其启动传输层或网络层会话的Internet节点都需要在可公开访问的域名系统（DNS）中包含相关地址（例如，A、AAAA）或定位器（例如，L32、L64、LP）记录。放置在DNS中的信息可以公开访问。由于DNS的目标是将信息分发给其他Internet节点，因此它不提供选择性隐私的机制。当然，不希望被联系的节点不需要出现在DNS中。
In some cases, various parties have attempted to create mappings between IP Address blocks and geographic locations. The quality of such mappings appears to vary [GUF07]. Many such mapping efforts are driven themselves by efforts to comply with legal requirements in various legal jurisdictions. For example, some content providers reportedly have licenses authorising distribution of content in one set of locations, but not in a different set of locations.
在某些情况下，各方试图在IP地址块和地理位置之间创建映射。这种映射的质量似乎有所不同[GUF07]。许多此类测绘工作都是由遵守不同法律管辖区法律要求的努力推动的。例如，据报道，一些内容提供商拥有授权在一组位置分发内容的许可证，但不在另一组位置分发内容。
ILNP does not compromise user location privacy any more than base IPv6. In fact, by its nature ILNP provides additional choices to the user to protect their location privacy.
ILNP不会像基本IPv6那样损害用户位置隐私。事实上，就其性质而言，ILNP为用户提供了额外的选择，以保护其位置隐私。
Both ILNP and IPv6 permit use of identifier values generated using the IPv6 Privacy Address extension [RFC4941]. ILNP and IPv6 also support a node having multiple unicast addresses/locators at the same time, which facilitates changing the node's addresses/locators over time. IPv4 does not have any non-topological identifiers, and many IPv4 nodes only support one IPv4 unicast address per interface, so IPv4 is not directly comparable with IPv6 or ILNP.
ILNP和IPv6都允许使用使用IPv6隐私地址扩展[RFC4941]生成的标识符值。ILNP和IPv6还支持同时具有多个单播地址/定位器的节点，这有助于随着时间的推移更改节点的地址/定位器。IPv4没有任何非拓扑标识符，而且许多IPv4节点每个接口只支持一个IPv4单播地址，因此IPv4无法直接与IPv6或ILNP进行比较。
In normal operation with IPv4, IPv6, or ILNP, a mobile node might intend to be accessible for new connection attempts from the global Internet and also might wish to have both optimal routing and maximal Internet availability, both for sent and received packets. In that case, the node will want to have its addressing or location information kept in the DNS and made available to others.
在IPv4、IPv6或ILNP的正常操作中，移动节点可能希望能够从全局Internet访问新的连接尝试，并且可能希望具有最佳路由和最大Internet可用性，包括发送和接收的数据包。在这种情况下，节点将希望其地址或位置信息保留在DNS中，并提供给其他人。
In some cases, a mobile node might only desire to initiate network-layer or transport-layer sessions with other Internet nodes, and thus not desire to be a responder, in which case that node need not be
在某些情况下，移动节点可能只希望发起与其他因特网节点的网络层或传输层会话，因此不希望成为响应者，在这种情况下，该节点不需要是响应者
present in the DNS. Some potential correspondent nodes might, as a matter of local security policy, decline to communicate with nodes that do not have suitable DNS records present in the DNS. For example, some deployed IPv4-capable mail relays refuse to communicate with an initiating node that lacks an appropriate PTR record in the DNS.
存在于DNS中。根据本地安全策略，某些潜在的对应节点可能会拒绝与DNS中没有适当DNS记录的节点通信。例如，一些部署的支持IPv4的邮件中继拒绝与DNS中缺少适当PTR记录的发起节点通信。
In some cases (for example, intermittent electronic mail access or browsing specific web pages), support for long-lived network sessions (i.e., where network-layer session lifetime is longer than the time the node remains on the same subnetwork) is not required. In those cases, support for node mobility (i.e., network-layer session continuity even when the SNPA changes) is not required and need not be used.
在某些情况下（例如，间歇性电子邮件访问或浏览特定网页），不需要支持长寿命网络会话（即，网络层会话生存期长于节点保持在同一子网络上的时间）。在这些情况下，不需要并且不需要使用对节点移动性的支持（即，即使SNPA改变，网络层会话连续性）。
If an ILNP node that is mobile chooses not to use DNS for rendezvous, yet desires to permit any node on the global Internet to initiate communications with that node, then that node may fall back to using Mobile IPv4 or Mobile IPv6 instead.
如果移动的ILNP节点选择不使用DNS进行集合，但希望允许全球Internet上的任何节点启动与该节点的通信，则该节点可能会转而使用移动IPv4或移动IPv6。
Many residential broadband Internet users are subject to involuntary renumbering, usually when their ISP's DHCP server(s) deny a DHCP RENEW request and instead issue different IP addressing information to the residential user's device(s). In many cases, such users want their home server(s) or client(s) to be externally reachable. Such users today often use Secure DNS Dynamic Update to update their addressing or location information in the DNS entries, for the devices they wish to make reachable from the global Internet [RFC2136] [RFC3007] [LA2006]. This option exists for those users, whether they use IPv4, IPv6, or ILNP. Users also have the option not to use such mechanisms.
许多住宅宽带互联网用户会受到非自愿重新编号的影响，通常是当他们的ISP的DHCP服务器拒绝DHCP续订请求，而是向住宅用户的设备发出不同的IP地址信息时。在许多情况下，这样的用户希望他们的家庭服务器或客户端可以从外部访问。如今，这类用户经常使用安全DNS动态更新来更新DNS条目中的地址或位置信息，以便从全球互联网访问设备[RFC2136][RFC3007][LA2006]。此选项适用于这些用户，无论他们使用IPv4、IPv6还是ILNP。用户还可以选择不使用此类机制。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724]Thaler，D.，Ed.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 67242012年9月。
[RFC6741] Atkinson, R. and S. Bhatti, "Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations", RFC 6741, November 2012.
[RFC6741]Atkinson，R.和S.Bhatti，“标识符定位器网络协议（ILNP）工程和实施注意事项”，RFC 67412012年11月。
[RFC6742] Atkinson, R., Bhatti, S., and S. Rose, "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)", RFC 6742, November 2012.
[RFC6742]Atkinson，R.，Bhatti，S.和S.Rose，“标识符定位器网络协议（ILNP）的DNS资源记录”，RFC 6742，2012年11月。
[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月。
[8+8] O'Dell, M., "8+8 - An Alternate Addressing Architecture for IPv6", Work in Progress, October 1996.
[8+8]O'Dell，M.，“8+8-IPv6的替代寻址体系结构”，正在进行的工作，1996年10月。
[ABH07a] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility as an Integrated Service Through the Use of Naming", Proceedings of ACM MobiArch 2007, August 2007, Kyoto, Japan.
[ABH07a]Atkinson，R.，Bhatti，S.和S.Hailes，“通过使用命名将移动作为一种综合服务”，ACM MobiArch会议记录，2007年8月，日本京都。
[ABH07b] Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal for Unifying Mobility with Multi-Homing, NAT, & Security", Proceedings of ACM MobiWAC 2007, Chania, Crete. ACM, October 2007.
[ABH07b]Atkinson，R.，Bhatti，S.和S.Hailes，“将机动性与多主、NAT和安全性统一起来的提案”，ACM MobiWAC会议录，2007年，克里特岛查尼亚。ACM，2007年10月。
[ABH08a] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility Through Naming: Impact on DNS", Proceedings of ACM MobiArch 2008, August 2008, ACM, Seattle, WA, USA.
[ABH08a]Atkinson，R.，Bhatti，S.和S.Hailes，“通过命名的移动性：对DNS的影响”，ACM MobiArch会议记录，2008年8月，美国华盛顿州西雅图ACM。
[ABH08b] Atkinson, R., Bhatti, S., and S. Hailes, "Harmonised Resilience, Security, and Mobility Capability for IP", Proceedings of IEEE Military Communications (MILCOM) Conference, San Diego, CA, USA, November 2008.
[ABH08b]Atkinson，R.，Bhatti，S.和S.Hailes，“IP的协调弹性、安全性和移动性”，IEEE军事通信（MILCOM）会议记录，加利福尼亚州圣地亚哥，美国，2008年11月。
[ABH09a] Atkinson, R., Bhatti, S., and S. Hailes, "Site-Controlled Secure Multi-Homing and Traffic Engineering For IP", Proceedings of IEEE Military Communications (MILCOM) Conference, Boston, MA, USA, October 2009.
[ABH09a]Atkinson，R.，Bhatti，S.和S.Hailes，“IP的现场控制安全多主和流量工程”，IEEE军事通信（MILCOM）会议记录，美国马萨诸塞州波士顿，2009年10月。
[ABH09b] Atkinson, R., Bhatti, S., and S. Hailes, "ILNP: Mobility, Multi-Homing, Localised Addressing and Security Through Naming", Telecommunications Systems, Volume 42, Number 3-4, pp. 273-291, Springer-Verlag, December 2009, ISSN 1018-4864.
[ABH09b]阿特金森，R.，巴蒂，S.，和S.海尔，“ILNP：移动，多主，通过命名的本地化寻址和安全”，电信系统，第42卷，第3-4号，第273-291页，斯普林格·维拉格，2009年12月，ISSN 1018-4864。
[ABH10] Atkinson, R., Bhatti, S., S. Hailes, "Evolving the Internet Architecture Through Naming", IEEE Journal on Selected Areas in Communication (JSAC), vol. 28, no. 8, pp. 1319-1325, IEEE, Piscataway, NJ, USA, Oct 2010.
[ABH10]Atkinson，R.，Bhatti，S.，S.Hailes，“通过命名发展互联网架构”，《IEEE通信选定领域杂志》（JSAC），第28卷，第8期，第1319-1325页，IEEE，Piscataway，NJ，USA，2010年10月。
[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日。
[BA12] Bhatti, S. and R. Atkinson, "Secure and Agile Wide-area Virtual Machine Mobility", Proceedings of IEEE Military Communications Conference (MILCOM), Orlando, FL, USA, Oct 2012.
[BA12]Bhatti，S.和R.Atkinson，“安全和灵活的广域虚拟机移动”，IEEE军事通信会议记录（MILCOM），美国佛罗里达州奥兰多，2012年10月。
[BAK11] Bhatti, S., Atkinson, R., and J. Klemets, "Integrating Challenged Networks", Proceedings of IEEE Military Communications Conference (MILCOM), Baltimore, MD, USA, November 2011.
[BAK11]Bhatti，S.，Atkinson，R.，和J.Klemets，“整合挑战网络”，IEEE军事通信会议记录（MILCOM），马里兰州巴尔的摩，美国，2011年11月。
[CA-1995-01] US CERT, "IP Spoofing Attacks and Hijacked Terminal Connections", CERT Advisory 1995-01, Issued 23 Jan 1995, Revised 23 Sep 1997.
[CA-1995-01]美国CERT，“IP欺骗攻击和被劫持的终端连接”，CERT咨询1995-01，1995年1月23日发布，1997年9月23日修订。
[DIA] Defense Intelligence Agency, "Compartmented Mode Workstation Specification", Technical Report DDS-2600-6243-87, US Defense Intelligence Agency, Bolling AFB, DC, USA.
国防情报局，“分隔式工作站规范”，技术报告DDS-2600-6243-87，美国国防情报局，美国柏林空军基地。
[DoD85] US National Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD, USA, December 1985.
[DoD85]美国国家计算机安全中心，“国防部可信计算机系统评估标准”，国防部5200.28-STD，美国国防部，马里兰州米德堡，1985年12月。
[DoD87] US National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD, USA, 31 July 1987.
[DoD87]美国国家计算机安全中心，“可信网络对可信计算机系统评估标准的解释”，NCSC-TG-005，第1版，美国国防部，马里兰州米德堡，1987年7月31日。
[GSE] O'Dell, M., "GSE - An Alternate Addressing Architecture for IPv6", Work in Progress, February 1997.
[GSE]O'Dell，M.，“GSE-IPv6的替代寻址体系结构”，正在进行的工作，1997年2月。
[GUF07] Gueye, B., Uhlig, S., and S. Fdida, "Investigating the Imprecision of IP Block-Based Geolocation", Lecture Notes in Computer Science, Volume 4427, pp. 237-240, Springer-Verlag, Heidelberg, Germany, 2007.
[GUF07]Gueye，B.，Uhlig，S.和S.Fdida，“研究基于IP块的地理定位的不精确性”，《计算机科学》课堂讲稿，第4427卷，第237-240页，德国海德堡斯普林格·维拉格，2007年。
[ID-ULA] Hinden, R., Huston, G., and T. Narten, "Centrally Assigned Unique Local IPv6 Unicast Addresses", Work in Progress, June 2007.
[ID-ULA]Hinden，R.，Huston，G.，和T.Narten，“集中分配的唯一本地IPv6单播地址”，正在进行的工作，2007年6月。
[IEEE-EUI] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", Piscataway, NJ, USA, March 1997, <http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>.
[IEEE-EUI]IEEE，“64位全局标识符（EUI-64）注册机构指南”，美国新泽西州皮斯卡塔韦，1997年3月<http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>。
[IEN1] Bennett, C., Edge, S., and A. Hinchley, "Issues in the Interconnection of Datagram Networks", Internet Experiment Note (IEN) 1, INDRA Note 637, PSPWN 76, 29 July 1977, <http://www.rfc-editor.org/ien/ien1.pdf>.
[IEN1]Bennett，C.，Edge，S.和A.Hinchley，“数据报网络互连中的问题”，互联网实验说明（IEN）1，INDRA注释637，PSPWN 76，1977年7月29日<http://www.rfc-editor.org/ien/ien1.pdf>.
[IEN19] Shoch, J., "Inter-Network Naming, Addressing, and Routing", IEN 19, January 1978, <http://www.rfc-editor.org/ien/ien19.txt>.
[IEN19]Shoch，J.，“网络间命名、寻址和路由”，IEN19，1978年1月<http://www.rfc-editor.org/ien/ien19.txt>.
[IEN23] Cohen, D., "On Names, Addresses, and Routings", IEN 23, January 1978, <http://www.rfc-editor.org/ien/ien23.pdf>.
[IEN23]Cohen，D.，“关于姓名、地址和路线”，IEN231978年1月<http://www.rfc-editor.org/ien/ien23.pdf>.
[IEN31] Cohen, D., "On Names, Addresses, and Routings (II)", IEN 31, April 1978, <http://www.rfc-editor.org/ien/ien31.pdf>.
[IEN31]Cohen，D.“关于姓名、地址和路线（II）”，IEN31978年4月<http://www.rfc-editor.org/ien/ien31.pdf>.
[IEN135] Sunshine, C. and J. Postel, "Addressing Mobile Hosts in the ARPA Internet Environment", IEN 135, March 1980, <http://www.rfc-editor.org/ien/ien135.pdf>.
[IEN135]Sunshine，C.和J.Postel，“在ARPA互联网环境中寻址移动主机”，IEN135，1980年3月<http://www.rfc-editor.org/ien/ien135.pdf>.
[IPng95] Clark, D., "A thought on addressing", electronic mail message to IETF IPng WG, Message-ID: 9501111901.AA28426@caraway.lcs.mit.edu, Laboratory for Computer Science, MIT, Cambridge, MA, USA, 11 January 1995.
[IPng95]Clark，D.，“关于寻址的思考”，发给IETF IPng工作组的电子邮件，消息ID:9501111901。AA28426@caraway.lcs.mit.edu，麻省理工学院计算机科学实验室，美国马萨诸塞州剑桥，1995年1月11日。
[LA2006] Liu, C. and P. Albitz, "DNS & Bind", 5th Edition, O'Reilly & Associates, Sebastopol, CA, USA, May 2006, ISBN 0-596-10057-4.
[LA2006]Liu，C.和P.Albitz，“DNS和Bind”，第五版，O'Reilly&Associates，塞巴斯托波尔，加利福尼亚州，美国，2006年5月，ISBN 0-596-10057-4。
[LABH06] Lad, M., Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal for Coalition Networking in Dynamic Operational Environments", Proceedings of IEEE Military Communications Conference, Washington, DC, USA, Nov. 2006.
[LABH06]Lad，M.，Atkinson，R.，Bhatti，S.，和S.Hailes，“动态作战环境中的联盟网络提案”，IEEE军事通信会议记录，美国华盛顿特区，2006年11月。
[PHG02] Pappas, A., Hailes, S., and R. Giaffreda, "Mobile Host Location Tracking through DNS", Proceedings of IEEE London Communications Symposium, IEEE, London, England, UK, September 2002.
[PHG02]Pappas，A.，Hailes，S.，和R.Giaffreda，“通过DNS跟踪移动主机位置”，IEEE伦敦通信研讨会论文集，IEEE，伦敦，英国，2002年9月。
[RAB09] Rehunathan, D., Atkinson, R., and S. Bhatti, "Enabling Mobile Networks Through Secure Naming", Proceedings of IEEE Military Communications Conference (MILCOM), Boston, MA, USA, October 2009.
[RAB09]Rehunahan，D.，Atkinson，R.，和S.Bhatti，“通过安全命名实现移动网络”，IEEE军事通信会议记录（MILCOM），美国马萨诸塞州波士顿，2009年10月。
[RB10] Rehunathan, D. and S. Bhatti, "A Comparative Assessment of Routing for Mobile Networks", Proceedings of IEEE International Conference on Wireless and Mobile Computing Networking and Communications (WiMob), IEEE, Niagara Falls, ON, Canada, Oct. 2010.
[RB10]Rehunahan，D.和S.Bhatti，“移动网络路由的比较评估”，IEEE无线和移动计算网络与通信国际会议记录，IEEE，尼亚加拉瀑布，加拿大，2010年10月。
[SBK01] 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.
[SBK01]Snoren，A.，Balakrishnan，H.，和M.Frans Kaashoek，“重新考虑互联网移动性”，第八届操作系统热点研讨会论文集，IEEE，德国埃尔莫，2001年5月。
[SIPP94] Smart, B., "Re: IPng Directorate meeting in Chicago; possible SIPP changes", electronic mail to the IETF SIPP WG mailing list, Message-ID: 199406020647.AA09887@shark.mel.dit.csiro.au, Commonwealth Scientific & Industrial Research Organisation (CSIRO), Melbourne, VIC, 3001, Australia, 2 June 1994.
[SIPP94]Smart，B.，“回复：芝加哥IPng董事会会议；可能的SIPP变更”，发送至IETF SIPP工作组邮件列表的电子邮件，信息ID:199406020647。AA09887@shark.mel.dit.csiro.au，英联邦科学与工业研究组织（CSIRO），墨尔本，维多利亚州，3001，澳大利亚，1994年6月2日。
[SRC84] Saltzer, J., Reed, D., and D. Clark, "End to End Arguments in System Design", ACM Transactions on Computer Systems, Volume 2, Number 4, ACM, New York, NY, USA, November 1984.
[SRC84]Saltzer，J.，Reed，D.，和D.Clark，“系统设计中的端到端参数”，计算机系统上的ACM交易，第2卷，第4号，ACM，纽约，美国，纽约，1984年11月。
[RFC814] Clark, D., "Name, addresses, ports, and routes", RFC 814, July 1982.
[RFC814]Clark，D.，“名称、地址、港口和路线”，RFC8141982年7月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，1989年10月。
[RFC1498] Saltzer, J., "On the Naming and Binding of Network Destinations", RFC 1498, August 1993.
[RFC1498]Saltzer，J.，“网络目的地的命名和绑定”，RFC 1498，1993年8月。
[RFC1631] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.
[RFC1631]Egevang，K.和P.Francis，“IP网络地址转换器（NAT）”，RFC16311994年5月。
[RFC1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
[RFC1825]阿特金森，R.，“互联网协议的安全架构”，RFC18251995年8月。
[RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[RFC1826]阿特金森，R.，“IP认证头”，RFC18261995年8月。
[RFC1827] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995.
[RFC1827]阿特金森，R.，“IP封装安全有效载荷（ESP）”，RFC18271995年8月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，Ed.“互联网的架构原则”，RFC19581996年6月。
[RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996.
[RFC1992]Castineyra，I.，Chiapa，N.，和M.Steenstrup，“Nimrod路由架构”，RFC 1992，1996年8月。
[RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, October 1996.
[RFC2002]Perkins，C.，编辑，“IP移动支持”，RFC 2002，1996年10月。
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[RFC2101]Carpenter，B.，Crowcroft，J.，和Y.Rekhter，“今天的IPv4地址行为”，RFC 21011997年2月。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Ed.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", RFC 2956, October 2000.
[RFC2956]Kaat，M.，“1999年IAB网络层研讨会概述”，RFC 2956，2000年10月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[RFC3027]Holdrege，M.和P.Srisuresh，“IP网络地址转换器的协议复杂性”，RFC 3027，2001年1月。
[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月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715]Aboba，B.和W.Dixon，“IPsec网络地址转换（NAT）兼容性要求”，RFC 3715，2004年3月。
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.，Ed.，和L.Costa，Ed.，“IPv6的多播侦听器发现版本2（MLDv2）”，RFC 38102004年6月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec ESP数据包的UDP封装”，RFC 3948，2005年1月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[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月。
[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月。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5061]Stewart，R.，Xie，Q.，Tuexen，M.，Maruyama，S.，和M.Kozuka，“流控制传输协议（SCTP）动态地址重新配置”，RFC 50612007年9月。
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, July 2009.
[RFC5570]StJohns，M.，Atkinson，R.，和G.Thomas，“通用架构标签IPv6安全选项（CALIPSO）”，RFC 55702009年7月。
[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月。
[RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, May 2011.
[RFC6250]Thaler，D.“知识产权模型的演变”，RFC6250，2011年5月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Ed.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[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问题的技术和程序方面提供了专家指导。
Noel Chiappa graciously provided the authors with copies of the original email messages cited here as [SIPP94] and [IPng95], which enabled the precise citation of those messages herein.
Noel Chiappa慷慨地向作者提供了此处引用为[SIPP94]和[IPng95]的原始电子邮件的副本，这使得此处能够准确引用这些邮件。
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