Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6748 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
Internet Research Task Force (IRTF) RJ Atkinson
Request for Comments: 6748 Consultant
Category: Experimental SN Bhatti
ISSN: 2070-1721 U. St Andrews
November 2012
Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)
标识符定位器网络协议（ILNP）的可选高级部署方案
Abstract
摘要
This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management of ILNP-based systems.
本文档提供了标识符定位器网络协议（ILNP）的一些可选高级部署方案的体系结构描述和操作概念，ILNP是对IP的一种改进。使用或部署ILNP不需要此处描述的任何功能。相反，它提供了工程和部署选项的描述，这些选项可以在基于ILNP的系统的管理或管理中提供增强的功能或便利。
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/rfc6748.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6748.
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 ....................................................4
1.1. Document Roadmap ...........................................5
1.2. Terminology ................................................6
2. Localised Numbering .............................................6
2.1. Localised Locators .........................................7
2.2. Mixed Local/Global Numbering ...............................9
2.3. Dealing with Internal Subnets with Locator Rewriting .......9
2.4. Localised Name Resolution with DNS ........................11
2.5. Use of mDNS ...............................................13
2.6. Site Network Name in DNS ..................................13
2.7. Site Interior Topology Obfuscation ........................14
2.8. Other SBR Considerations ..................................14
3. An Alternative for Site Multihoming ............................16
3.1. Site Multihoming (S-MH) Connectivity Using an SBR .........16
3.2. Dealing with Link/Connectivity Changes ....................17
3.3. SBR Updates to DNS ........................................18
3.4. DNS TTL Values for L32 and L64 Records ....................18
3.5. Multiple SBRs .............................................19
4. An Alternative for Site (Network) Mobility .....................20
4.1. Site (Network) Mobility ...................................20
4.2. SBR Updates to DNS ........................................22
4.3. DNS TTL Values for L32 and L64 Records ....................22
5. Traffic Engineering Options ....................................22
5.1. Load Balancing ............................................23
5.2. Control of Egress Traffic Paths ...........................24
6. ILNP in Datacentres ............................................26
6.1. Virtual Image Mobility within a Single Datacentre .........27
6.2. Virtual Image Mobility between Datacentres - Invisible ....28
6.3. Virtual Image Mobility between Datacentres - Visible ......29
6.4. ILNP Capability in the Remote Host for VM Image Mobility ..29
7. Location Privacy ...............................................30
7.1. Locator Rewriting Relay (LRR) .............................30
7.2. Options for Installing LRR Packet Forwarding State ........31
8. Identity Privacy ...............................................32
9. Security Considerations ........................................32
10. References ....................................................33
10.1. Normative References .....................................33
10.2. Informative References ...................................34
11. Acknowledgements ..............................................37
1. Introduction ....................................................4
1.1. Document Roadmap ...........................................5
1.2. Terminology ................................................6
2. Localised Numbering .............................................6
2.1. Localised Locators .........................................7
2.2. Mixed Local/Global Numbering ...............................9
2.3. Dealing with Internal Subnets with Locator Rewriting .......9
2.4. Localised Name Resolution with DNS ........................11
2.5. Use of mDNS ...............................................13
2.6. Site Network Name in DNS ..................................13
2.7. Site Interior Topology Obfuscation ........................14
2.8. Other SBR Considerations ..................................14
3. An Alternative for Site Multihoming ............................16
3.1. Site Multihoming (S-MH) Connectivity Using an SBR .........16
3.2. Dealing with Link/Connectivity Changes ....................17
3.3. SBR Updates to DNS ........................................18
3.4. DNS TTL Values for L32 and L64 Records ....................18
3.5. Multiple SBRs .............................................19
4. An Alternative for Site (Network) Mobility .....................20
4.1. Site (Network) Mobility ...................................20
4.2. SBR Updates to DNS ........................................22
4.3. DNS TTL Values for L32 and L64 Records ....................22
5. Traffic Engineering Options ....................................22
5.1. Load Balancing ............................................23
5.2. Control of Egress Traffic Paths ...........................24
6. ILNP in Datacentres ............................................26
6.1. Virtual Image Mobility within a Single Datacentre .........27
6.2. Virtual Image Mobility between Datacentres - Invisible ....28
6.3. Virtual Image Mobility between Datacentres - Visible ......29
6.4. ILNP Capability in the Remote Host for VM Image Mobility ..29
7. Location Privacy ...............................................30
7.1. Locator Rewriting Relay (LRR) .............................30
7.2. Options for Installing LRR Packet Forwarding State ........31
8. Identity Privacy ...............................................32
9. Security Considerations ........................................32
10. References ....................................................33
10.1. Normative References .....................................33
10.2. Informative References ...................................34
11. Acknowledgements ..............................................37
This document is part of the ILNP document set, which has had extensive review within the IRTF Routing RG. ILNP is one of the recommendations made by the RG Chairs. Separately, various refereed research papers on ILNP have also been published during this decade. So, the ideas contained herein have had much broader review than the IRTF Routing RG. The views in this document were considered controversial by the Routing RG, but the RG reached a consensus that the document still should be published. The Routing RG has had remarkably little consensus on anything, so virtually all Routing RG outputs are considered controversial.
本文件是ILNP文件集的一部分，已在IRTF路由RG内进行了广泛审查。ILNP是RG主席提出的建议之一。另外，在这十年中还发表了各种关于ILNP的参考研究论文。因此，本文所包含的思想比IRTF路由RG有更广泛的审查。本文件中的观点被路由RG认为是有争议的，但RG达成共识，即该文件仍应发布。路由RG在任何事情上几乎没有共识，因此几乎所有路由RG输出都被认为是有争议的。
At present, the Internet research and development community is exploring various approaches to evolving the Internet Architecture to solve a variety of issues including, but not limited to, scalability of inter-domain routing [RFC4984]. A wide range of other issues (e.g., site multihoming, node multihoming, site/subnet mobility, node mobility) are also active concerns at present. Several different classes of evolution are being considered by the Internet research and development community. One class is often called "Map and Encapsulate", where traffic would be mapped and then tunnelled through the inter-domain core of the Internet. Another class being considered is sometimes known as "Identifier/Locator Split". This document relates to a proposal that is in the latter class of evolutionary approaches.
目前，互联网研发界正在探索各种方法来改进互联网体系结构，以解决各种问题，包括但不限于域间路由的可扩展性[RFC4984]。目前，广泛的其他问题（例如，站点多主、节点多主、站点/子网移动性、节点移动性）也是人们关注的热点。互联网研发界正在考虑几种不同的进化类型。一个类通常被称为“映射和封装”，在这个类中，流量将被映射，然后通过互联网的域间核心进行隧道传输。考虑的另一类有时称为“标识符/定位器拆分”。本文件涉及后一类进化方法中的建议。
ILNP is, in essence, an end-to-end architecture: the functions required for ILNP are implemented in, and controlled by, only those end-systems that wish to use ILNP, as described in [RFC6740]. Other nodes, such as Site Border Routers (SBRs) need only support IP to allow operation of ILNP, e.g., an SBR should support IPv6 in order to enable end-systems to operate ILNPv6 within the site network for which an SBR provides a service [RFC6741].
ILNP本质上是一种端到端体系结构：如[RFC6740]所述，ILNP所需的功能仅在希望使用ILNP的终端系统中实现并由其控制。其他节点，如站点边界路由器（SBR）只需支持IP即可允许ILNP的运行，例如，SBR应支持IPv6，以便使终端系统能够在SBR提供服务的站点网络内运行ILNPv6[RFC6741]。
However, some features of ILNP could be optimised, from an engineering perspective, by the use of an intermediate system (a router, security gateway or "middlebox") that modifies (rewrites) Locator values of transit ILNP packets. It would also perform other control functions for an entire site, as an administrative convenience, such as providing a centralised point of management for a site. For example, an SBR might manipulate the topological presence of the packet, providing an elegant solution to the provision of functions such as site (network) mobility for an entire end site [ABH09a].
然而，从工程的角度来看，可以通过使用中间系统（路由器、安全网关或“中间箱”）来优化ILNP的一些特性，该中间系统修改（重写）传输ILNP数据包的定位器值。它还将为整个现场执行其他控制功能，以方便管理，例如为现场提供集中管理点。例如，SBR可以操纵分组的拓扑存在，为提供诸如整个终端站点的站点（网络）移动性之类的功能提供优雅的解决方案[ABH09a]。
This document discusses several such optional advanced deployment scenarios for ILNP. These typically use an ILNP-capable Site Border Router (SBR).
本文档讨论了ILNP的几种可选高级部署场景。这些路由器通常使用支持ILNP的站点边界路由器（SBR）。
Nothing in this document is a requirement for any ILNP implementation or any ILNP deployment.
本文件中的任何内容都不是任何ILNP实施或任何ILNP部署的要求。
Readers are strongly advised to first read the ILNP Architecture Description [RFC6740], as this document uses the notation and terminology described or referenced in that document.
强烈建议读者首先阅读ILNP体系结构描述[RFC6740]，因为本文档使用了该文档中描述或引用的符号和术语。
This document describes engineering and implementation considerations that are common to ILNP for both IPv4 and IPv6.
本文档描述了ILNP在IPv4和IPv6中常见的工程和实施注意事项。
The ILNP architecture can have more than one engineering instantiation. For example, one can imagine a "clean-slate" engineering design based on the ILNP architecture. In separate documents, we describe two specific engineering instances of ILNP. The term "ILNPv6" refers precisely to an instance of ILNP that is based upon, and backwards compatible with, IPv6. The term "ILNPv4" refers precisely to an instance of ILNP that is based upon, and backwards compatible with, IPv4.
ILNP体系结构可以有多个工程实例。例如，可以想象基于ILNP体系结构的“干净板岩”工程设计。在单独的文档中，我们描述了ILNP的两个具体工程实例。术语“ILNPv6”正是指基于IPv6并向后兼容IPv6的ILNP实例。术语“ILNPv4”正是指基于IPv4并向后兼容IPv4的ILNP实例。
Many engineering aspects common to both ILNPv4 and ILNPv6 are described in [RFC6741]. A full engineering specification for either ILNPv6 or ILNPv4 is beyond the scope of this document.
[RFC6741]中描述了ILNPv4和ILNPv6共同的许多工程方面。ILNPv6或ILNPv4的完整工程规范超出了本文件的范围。
Readers are referred to other related ILNP documents for details not described here:
读者可参考其他相关ILNP文件，了解此处未描述的详细信息：
a) [RFC6740] is the main architectural description of ILNP, including the concept of operations.
a) [RFC6740]是ILNP的主要架构描述，包括操作概念。
b) [RFC6741] describes engineering and implementation considerations that are common to both ILNPv4 and ILNPv6.
b) [RFC6741]描述了ILNPv4和ILNPv6通用的工程和实施注意事项。
c) [RFC6742] defines additional DNS resource records that support ILNP.
c) [RFC6742]定义支持ILNP的其他DNS资源记录。
d) [RFC6743] defines a new ICMPv6 Locator Update message used by an ILNP node to inform its correspondent nodes of any changes to its set of valid Locators.
d) [RFC6743]定义一条新的ICMPv6定位器更新消息，ILNP节点使用该消息通知其对应节点其有效定位器集的任何更改。
e) [RFC6744] defines a new IPv6 Nonce Destination Option used by ILNPv6 nodes (1) to indicate to ILNP correspondent nodes (by inclusion within the initial packets of an ILNP session) that the node is operating in the ILNP mode and (2) to prevent off-path attacks against ILNP ICMP messages. This Nonce is used, for example, with all ILNP ICMPv6 Locator Update messages that are exchanged among ILNP correspondent nodes.
e) [RFC6744]定义了一个新的IPv6 Nonce Destination选项，ILNPv6节点使用该选项（1）向ILNP对应节点（通过包含在ILNP会话的初始数据包中）指示该节点正在ILNP模式下运行，（2）防止针对ILNP ICMP消息的非路径攻击。例如，此Nonce用于在ILNP对应节点之间交换的所有ILNP ICMPv6定位器更新消息。
f) [RFC6745] defines a new ICMPv4 Locator Update message used by an ILNP node to inform its correspondent nodes of any changes to its set of valid Locators.
f) [RFC6745]定义一条新的ICMPv4定位器更新消息，ILNP节点使用该消息通知其对应节点其有效定位器集的任何更改。
g) [RFC6746] defines a new IPv4 Nonce Option used by ILNPv4 nodes to carry a security nonce to prevent off-path attacks against ILNP ICMP messages and also defines a new IPv4 Identifier Option used by ILNPv4 nodes.
g) [RFC6746]定义了一个新的IPv4 Nonce选项，ILNPv4节点使用该选项携带一个安全Nonce，以防止针对ILNP ICMP消息的非路径攻击，还定义了一个新的IPv4标识符选项，ILNPv4节点使用该选项。
h) [RFC6747] describes extensions to Address Resolution Protocol (ARP) for use with ILNPv4.
h) [RFC6747]描述了用于ILNPv4的地址解析协议（ARP）扩展。
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]中所述进行解释。
Today, Network Address Translation (NAT) [RFC3022] is used for a number of purposes. Whilst one of the original intentions of NAT was to reduce the rate of use of global IPv4 addresses, through use of IPv4 private address space [RFC1918], NAT also offers to site administrators a convenient localised address management capability combined with a local-scope/private address space, for example, [RFC1918] for IPv4.
如今，网络地址转换（NAT）[RFC3022]被用于许多目的。虽然NAT的最初目的之一是降低全局IPv4地址的使用率，但通过使用IPv4专用地址空间[RFC1918]，NAT还为站点管理员提供了方便的本地化地址管理功能，并结合了本地作用域/专用地址空间，例如，IPv4的[RFC1918]。
For IPv6, NAT would not necessarily be required to reduce the rate of IPv6 address depletion, because the availability of addresses is not such an issue as for IPv4. The IETF has standardised Unique Local IPv6 Unicast Addresses [RFC4193], which provide local-scope IPv6 unicast address space that can be used by end sites. However, localised address management, in a manner similar to that provided by
对于IPv6，不一定需要NAT来降低IPv6地址耗尽率，因为地址的可用性不像IPv4那样是一个问题。IETF已经标准化了唯一的本地IPv6单播地址[RFC4193]，该地址提供了终端站点可以使用的本地范围IPv6单播地址空间。但是，本地地址管理的方式与
IPv4 NAT and private address space [RFC1918], is still desirable for IPv6 [RFC5902], even though there is debate about the efficacy of such an approach [RFC4864].
IPv4 NAT和专用地址空间[RFC1918]对于IPv6[RFC5902]仍然是可取的，尽管对这种方法的有效性存在争议[RFC4864]。
One of the major concerns that many have had with NAT is the loss of end-to-end transport-layer and network-layer session state invariance, which is still considered an important architectural principle by the IAB [RFC4924]. Nevertheless, the use of localised addressing remains in wide use and there is interest in its continued use in IPv6, e.g., proposals such as [RFC6296].
许多人对NAT的主要担忧之一是端到端传输层和网络层会话状态不变性的丢失，IAB仍然认为这是一个重要的体系结构原则[RFC4924]。然而，本地化寻址的使用仍在广泛使用，人们对其在IPv6中的继续使用感兴趣，例如[RFC6296]等提案。
It is possible to have the benefits of NAT-like functions for ILNP without losing end-to-end state. Indeed, such a mechanism -- the use of Locator rewriting in ILNP -- forms the basis of many of the optional functions described in this document. In ILNP, we call this feature "localised numbering".
对于ILNP，有可能在不丢失端到端状态的情况下获得类似NAT的函数的好处。事实上，这种机制——在ILNP中使用定位器重写——构成了本文档中描述的许多可选函数的基础。在ILNP中，我们称此功能为“本地化编号”。
Recall, that a Locator value in ILNP has the same semantics as a routing prefix in IP: indeed, in ILNPv4 and ILNPv6 [RFC6741], routing prefixes from IPv4 and IPv6, respectively, are used as Locator values.
回想一下，ILNP中的定位器值与IP中的路由前缀具有相同的语义：实际上，在ILNPv4和ILNPv6[RFC6741]中，分别来自IPv4和IPv6的路由前缀用作定位器值。
We note that a deployment using private/local numbering can also provide a convenient solution to centralised management of site multihoming and network mobility by deploying SBRs in this manner -- this is described below.
我们注意到，通过以这种方式部署SBR，使用私有/本地编号的部署也可以为站点多主和网络移动性的集中管理提供一个方便的解决方案——下面将对此进行描述。
Please note that with this proposal, localised numbering (e.g., using the equivalent of IP NAT on the ILNP Locator bits) would work in harmony with multihoming, mobility (for individual hosts and whole networks), and IP Security (IPsec), plus the other advanced functions described in this document [BA11] [LABH06] [ABH07a] [ABH07b] [ABH08a] [ABH08b] [ABH09a] [ABH09b] [RAB09] [RB10] [ABH10] [BAK11].
请注意，根据本提案，本地化编号（例如，在ILNP定位器位上使用IP NAT的等效物）将与多宿、移动性（针对单个主机和整个网络）和IP安全（IPsec）以及本文件[BA11][LABH06][ABH07a][ABH07b][ABH08a][ABH08b]中描述的其他高级功能协调工作[ABH09a][ABH09b][RAB09][RB10][ABH10][BAK11]。
For ILNP, the NAT-like function can best be descried by using a simple example, based on Figure 2.1.
对于ILNP，类似NAT的函数可以通过使用图2.1所示的简单示例来描述。
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | +------. .
. .L_L | | . .
. .----+ | . Internet .
. H . | | . .
. . | | . .
. . . . +------+ . .
. .
. . . .
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | +------. .
. .L_L | | . .
. .----+ | . Internet .
. H . | | . .
. . | | . .
. . . . +------+ . .
. .
. . . .
CN = Correspondent Node H = Host L_1 = global Locator value L_L = local Locator value SBR = Site Border Router
CN=对应节点H=主机L_1=全局定位器值L_L=本地定位器值SBR=站点边界路由器
Figure 2.1: A Simple Localised Numbering Example for ILNP
图2.1:ILNP的简单本地化编号示例
In this scenario, the SBR is allocated global locator value L_1 from the upstream provider. However, the SBR advertises internally a "local" Locator value L_L. By "local" we mean that the Locator value only has significance within the site network, and any packets that have L_L as a source Locator cannot be forwarded beyond the SBR with value L_L as the source Locator. In engineering terms, L_L would, for example, in ILNPv6, be an IPv6 prefix based on the assignments possible according to IPv6 Unique Local Addresses (ULAs) [RFC4193].
在这种情况下，SBR从上游供应商处分配全局定位器值L_1。然而，SBR在内部宣传“本地”定位器值L_L。所谓“本地”，我们的意思是定位器值仅在站点网络内具有重要意义，任何以L_L作为源定位器的数据包都不能转发到SBR以外的以L_L作为源定位器的数据包。在工程术语中，例如，在ILNPv6中，L_L将是基于根据IPv6唯一本地地址（ULA）可能进行的分配的IPv6前缀[RFC4193]。
If we assume that H uses Identifier I_H, then it will use Identifier-Locator Vector (I-LV) [I_H, L_L], and that the correspondent node (CN) uses IL-V [I_CN, L_CN]. If we consider that H will send a UDP packet from its port P_H to CN's port P_CN, then H could send a UDP/ILNP packet with the tuple expression:
如果我们假设H使用标识符I_H，那么它将使用标识符定位器向量（I-LV）[I_H，L_L]，并且对应节点（CN）使用IL-V[I_CN，L_CN]。如果我们认为H将从其端口PUH发送UDP分组到CN的端口PYN CN，那么H可以用元组表达式发送UDP/ILNP分组：
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_L, L_CN> --- (1a)
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_L, L_CN> --- (1a)
When this packet reaches the SBR, it knows that L_L is a local Locator value and so rewrites the source Locator on the egress packet to L_1 and forwards that out onto its external-facing interface. The value L_1 is a global prefix, which allows the packet to be routed globally:
当该分组到达SBR时，它知道L_L是本地定位器值，因此将出口分组上的源定位器重写为L_1，并将其转发到其面向外部的接口上。值L_1是一个全局前缀，它允许数据包全局路由：
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (1b)
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (1b)
This packet reaches CN using normal routing based on the Locator value L_1, as it is a routing prefix.
此数据包使用基于定位器值L_1的正常路由到达CN，因为它是路由前缀。
Note that from expressions (1a) and (1b), the end-to-end state (in the UDP tuple) remains unchanged -- end-to-end state invariance is honoured, for UDP. CN would send a UDP packet to H as:
请注意，在表达式（1a）和（1b）中，端到端状态（在UDP元组中）保持不变——对于UDP，端到端状态不变性得到尊重。CN将向H发送UDP数据包，如下所示：
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_1> --- (2a)
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_1> --- (2a)
and the SBR would rewrite the Locator value on the ingress packet before forwarding the packet on its internal interface:
SBR将在其内部接口上转发数据包之前重写入口数据包上的定位器值：
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_L> --- (2b)
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_L> --- (2b)
Again, this preserves the end-to-end transport-layer session state invariance.
同样，这保持了端到端传输层会话状态不变性。
As the Locator values are not used in the transport-layer pseudo-header for ILNP [RFC6741], the checksum would not have to be rewritten. That is, the Locator rewriting function is stateless and has low overhead.
由于ILNP[RFC6741]的传输层伪报头中未使用定位器值，因此不必重写校验和。也就是说，定位器重写函数是无状态的，并且具有较低的开销。
(A discussion on the generation of Identifier values for initial use is presented in [RFC6741].)
（在[RFC6741]中对初始使用标识符值的生成进行了讨论。）
It is possible for the SBR to advertise both L_1 and L_L within the site, and for hosts within the site to have IL-Vs using both L_1 and L_L. For example, host H may have IL-Vs [I_H, L_1] and [I_H, L_L]. The configuration and use of such a mechanism can be controlled through local policy.
SBR有可能在站点内同时发布L_1和L_L，站点内的主机有同时使用L_1和L_L的IL-V。例如，主机H可能有IL-V[I_H，L_1]和[I_H，L_L]。这种机制的配置和使用可以通过本地策略进行控制。
Where the site network uses subnets, packets will need to be routed correctly, internally. That is, the site network may have several internal Locator values, e.g., L_La, L_Lb, and L_Lc. When an ingress packet has I-LV [I_H, L_1], it is expected that the SBR is capable of identifying the correct internal network for I_H, and so the correct Locator value to rewrite for the ingress packet. This is not obvious as the I value and the L value are not related in any way.
如果站点网络使用子网，则需要在内部正确路由数据包。也就是说，站点网络可以具有多个内部定位器值，例如，L_La、L_Lb和L_Lc。当入口分组具有I-LV[I_H，L_1]时，期望SBR能够为I_H识别正确的内部网络，因此能够为入口分组重写正确的定位器值。这并不明显，因为I值和L值没有任何关联。
There are numerous ways the SBR could facilitate the correct lookup of the internal Locator value. This document does not prescribe any specific method. Of course, we do not preclude mappings directly from Identifier values to internal Locator values.
SBR可以通过多种方式帮助正确查找内部定位器值。本文件未规定任何具体方法。当然，我们不排除直接从标识符值到内部定位器值的映射。
Of course, such a "flat" mapping (between Identifier values and Locators) would serve, but maintaining such a mapping would be impractical for a large site. So, we propose the following solution.
当然，这样一个“平面”映射（标识符值和定位器之间）是有用的，但是维护这样一个映射对于大型站点来说是不切实际的。因此，我们提出以下解决方案。
Consider that the Locator value, L_x consists of two parts, L_pp and L_ss, where L_pp is a network prefix and L_ss is a subnet selector. Also, consider that this structure is true for both the local identifier, L_L, as well as the global Identifier, L_1. Then, an SBR need only know the mapping from the values of L_ss as visible in L_1 and the values of L_ss used locally.
考虑到定位器值，LYX由两部分组成，LYPP和LSSSS，其中LYPP是网络前缀，LISS是子网选择器。此外，考虑此结构对于本地标识符Lyl以及全局标识符LY1都是正确的。然后，SBR只需要知道L_1中可见的L_ss值和本地使用的L_ss值的映射。
Such a mapping could be mechanical, e.g., the L_ss part of L_L and L_1 are the same and it is only the L_pp part that is different. Where this is not desirable (e.g., for obfuscation of interior topology), an administrator would need to configure a suitable mapping policy in the SBR, which could be realised as a simple lookup table. Note that with such a policy, the L_pp for L_L and L_1 do not need to be of the same size.
这种映射可能是机械的，例如，L_L和L_1的L_ss部分是相同的，只有L_pp部分不同。如果不希望这样做（例如，为了混淆内部拓扑），管理员需要在SBR中配置合适的映射策略，这可以实现为一个简单的查找表。请注意，有了这样的策略，L_L和L_1的L_pp不需要具有相同的大小。
From a practical perspective, this is possible for both ILNPv6 [RFC6177] and ILNPv4 [RFC4632]. For ILNPv6, recall that the Locator value is encoded to be syntactically similar to an IPv6 address prefix, as shown in Figure 2.2, taken from [RFC6741].
从实际角度来看，这对于ILNPv6[RFC6177]和ILNPv4[RFC4632]都是可能的。对于ILNPv6，回想一下定位器值被编码为语法上类似于IPv6地址前缀，如图2.2所示，取自[RFC6741]。
/* IPv6 */
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
|001|global routing prefix| subnet ID | Interface Identifier |
+---+---------------------+-----------+-------------------------+
/* ILNPv6 */
| 64 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
| Locator (L64) | Node Identifier (NID) |
+---+---------------------+-----------+-------------------------+
+<-------- L_pp --------->+<- L_ss -->+
/* IPv6 */
| 3 | 45 bits | 16 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
|001|global routing prefix| subnet ID | Interface Identifier |
+---+---------------------+-----------+-------------------------+
/* ILNPv6 */
| 64 bits | 64 bits |
+---+---------------------+-----------+-------------------------+
| Locator (L64) | Node Identifier (NID) |
+---+---------------------+-----------+-------------------------+
+<-------- L_pp --------->+<- L_ss -->+
L_pp = Locator prefix part (assigned IPv6 prefix) L_ss = Locator subnet selector (locally managed subnet ID)
L_pp=定位器前缀部分（分配的IPv6前缀）L_ss=定位器子网选择器（本地管理的子网ID）
Figure 2.2: IPv6 Address format [RFC3587] as used in ILNPv6, showing how subnets can be identified.
图2.2:ILNPv6中使用的IPv6地址格式[RFC3587]，显示了如何识别子网。
Note that the subnet ID forms part of the Locator value. Note also that [RFC6177] allows the global routing prefix to be more than 45 bits, and for the subnet ID to be smaller, but still preserving the 64-bit size of the Locator overall.
请注意，子网ID构成定位器值的一部分。还请注意，[RFC6177]允许全局路由前缀大于45位，子网ID更小，但仍然保留定位器的64位大小。
For ILNPv4, the L_pp value overall is an IPv4 routing prefix, which is typically less than 32 bits. However, the ILNPv4 Locator value is carried in the 32-bit IP Address space, so the bits not used for the
对于ILNPv4，L_pp值总体上是IPv4路由前缀，通常小于32位。但是，ILNPv4定位器值在32位IP地址空间中携带，因此这些位不用于
routing prefix could be used for L_ss, e.g., for a /24 IPv4 prefix, the situation would be as shown in Figure 2.3, and L_ss could use any of the remaining 8-bits as required.
路由前缀可用于L_-ss，例如，对于a/24 IPv4前缀，情况如图2.3所示，L_-ss可根据需要使用剩余的8位中的任何一位。
24 bits 8 bits
+------------------------+----------+
| Locator (L32) |
+------------------------+----------+
+<------- L_pp --------->+<- L_ss ->+
24 bits 8 bits
+------------------------+----------+
| Locator (L32) |
+------------------------+----------+
+<------- L_pp --------->+<- L_ss ->+
L_pp = Locator prefix (assigned IPv4 prefix) L_ss = Locator subnet selector (locally managed subnet ID)
L_pp=定位器前缀（分配的IPv4前缀）L_ss=定位器子网选择器（本地管理的子网ID）
Figure 2.3: IPv4 address format for /24 IPv4 prefix, as used in ILNPv4, showing how subnets can be identified.
图2.3:ILNPv4中使用的/24 IPv4前缀的IPv4地址格式，显示了如何识别子网。
As an example, for the case where the interior topology is not obfuscated, an interior "engineering" node might have an LP record pointing to eng.example.com and eng.example.com might have L32/L64 records for a specific subnet inside the site. Meanwhile, an interior "operations" node might have an LP record pointing at "ops.example.com" that might have different L32/L64 records for that specific subnet within the site. That is, eng.example.com might have Locator value L_pp_1:L_ss_1 and ops.example.com might have Locator value L_pp_1:L_ss_2. However, just as for IPv6 or IPv4 routing today, the routing for the site would only need to use L_pp_1, which is a routing prefix in either IPv6 (for ILNPv6) or IPv4 (for ILNPv4).
例如，对于内部拓扑未混淆的情况，内部“工程”节点可能有指向eng.example.com的LP记录，而eng.example.com可能有站点内特定子网的L32/L64记录。同时，内部“操作”节点可能有一个指向“ops.example.com”的LP记录，该记录对于站点内的特定子网可能有不同的L32/L64记录。也就是说，eng.example.com可能具有定位器值L_pp_1:L_ss_1，而ops.example.com可能具有定位器值L_pp_1:L_ss_2。但是，就像今天的IPv6或IPv4路由一样，站点的路由只需要使用L_pp_1，这是IPv6（对于ILNPv6）或IPv4（对于ILNPv4）中的路由前缀。
To support private numbering with IPv4 and IPv6 today, some sites use a split-horizon DNS service for the site [appDNS].
为了支持IPv4和IPv6的私有编号，一些站点对站点[appDNS]使用拆分地平线DNS服务。
If a site using localised numbering chooses to deploy a split-horizon DNS server, then the DNS server would return the global-scope Locator(s) (L_1 in our example above) of the SBR to DNS clients outside the site, and would advertise the local-scope Locator(s) (L_L in our example above) specific to that internal node to DNS clients inside the site. Such deployments of split-horizon DNS servers are not unusual in the IPv4 Internet today. If an internal node (e.g., portable computer) moves outside the site, it would follow the normal ILNP methods to update its authoritative DNS server with its current Locator set. In this deployment model, the authoritative DNS server for that mobile device will be either the split-horizon DNS server itself or the master DNS server providing data to the split-horizon DNS server.
如果使用本地化编号的站点选择部署拆分地平线DNS服务器，则DNS服务器将向站点外部的DNS客户端返回SBR的全局作用域定位器（在上面的示例中为L_1），并公布本地作用域定位器（在上面的示例中为L_L）特定于该站点内的DNS客户端的内部节点。这种拆分地平线DNS服务器的部署在今天的IPv4互联网中并不少见。如果内部节点（例如，便携式计算机）移动到站点外部，它将按照正常的ILNP方法使用其当前定位器集更新其权威DNS服务器。在此部署模型中，该移动设备的权威DNS服务器将是split horizon DNS服务器本身或向split horizon DNS服务器提供数据的主DNS服务器。
If a site using localised numbering chooses not to deploy a split-horizon DNS server, then each internal node would advertise the global-scope Locator(s) of the site border routers in its respective DNS entries. To deliver packets from one internal node to another internal node, the site would choose to use either Layer 2 bridging (e.g., IEEE Spanning Tree or IEEE Rapid Spanning Tree [IEEE04], or a link-state Layer 2 algorithm such as the IETF TRILL group or IEEE 802.1 are developing), or the interior routers would forward packets up to the nearest site border router, which in turn would then rewrite the Locators to appropriate local-scope values, and forward the packet towards the interior destination node.
如果使用本地化编号的站点选择不部署拆分地平线DNS服务器，则每个内部节点将在其各自的DNS条目中公布站点边界路由器的全局范围定位器。为了将数据包从一个内部节点传送到另一个内部节点，站点将选择使用第2层桥接（例如，IEEE生成树或IEEE快速生成树[IEEE04]，或正在开发的链路状态第2层算法，例如IETF TRILL组或IEEE 802.1），或者内部路由器将数据包转发到最近的站点边界路由器，该路由器接着将定位器重写为适当的本地范围值，并将数据包转发到内部目的地节点。
Alternately, for sites using localised numbering but not deploying a split-horizon DNS server, the DNS server could return all global-scope and local-scope Locators to all queriers, and assume that nodes would use normal, local address/route selection criteria to choose the best Locator to use to reach a given remote node ([RFC3484] for older IPv6 nodes, [RFC6724] for newer IPv6 nodes). Hosts within the same site as the correspondent node would only have a ULA configured; hence, they would select the ULA destination Locator for the correspondent (L_L in our example). Hosts outside the site would not have the same ULA configured (L_CN for the CN in our example).
或者，对于使用本地化编号但未部署拆分地平线DNS服务器的站点，DNS服务器可以将所有全局作用域和本地作用域定位器返回给所有查询器，并假设节点将使用正常的本地地址/路由选择标准来选择用于到达给定远程节点的最佳定位器（[RFC3484]对于较旧的IPv6节点，[RFC6724]对于较新的IPv6节点）。与对应节点位于同一站点内的主机将只配置一个ULA；因此，他们会为对应者选择ULA目的地定位器（在我们的示例中为L_L）。站点之外的主机不会配置相同的ULA（在我们的示例中，L_CN用于CN）。
However, ILNP allows use of Locator Preference values [RFC6742] [RFC6743]. These values would indicate explicitly the relative preference value given to Locator values and so result in the selection of the appropriate Locator (and therefore interface) to use for the transmission of an outgoing packet with respect to the value to be inserted into the IPv6 Source Address field (see Section 3 of [RFC6741]). A similar argument, with respect to use of Locator preference values, applies to the value to be inserted into the IPv6 Destination Address field. Certainly, by using appropriate Preference values for a host with multiple Locator values, it would be possible to emulate some level of resemblance to the address selection rules in [RFC3484] and [RFC6724], and this could be controlled via DNS entries for ILNP nodes, for example.
但是，ILNP允许使用定位器首选项值[RFC6742][RFC6743]。这些值将明确表示为定位器值提供的相对优先值，从而导致选择适当的定位器（以及接口），用于传输与要插入IPv6源地址字段的值相关的传出数据包（参见[RFC6741]第3节）。关于定位器首选项值的使用，类似的参数适用于要插入IPv6目标地址字段的值。当然，通过对具有多个定位器值的主机使用适当的首选项值，可以模拟[RFC3484]和[RFC6724]中的地址选择规则的某种程度的相似性，例如，这可以通过ILNP节点的DNS条目进行控制。
Indeed, with appropriate use of localised or site-wide policy, and appropriate mechanisms in the devices (e.g. in end hosts operating systems or in Site Border Routers), Preference values for Locator values within the DNS could be used for allowing options for multi-homed transport sessions and/or site-controlled traffic engineering [ABH09a]. However, the details for this are left for further study, and overall, the rules defined in [RFC3484] and [RFC6724] cannot be applied directly to ILNPv6 nodes.
事实上，通过适当使用本地或站点范围的策略，以及设备中的适当机制（例如，终端主机操作系统或站点边界路由器），DNS中定位器值的首选值可用于允许多宿传输会话和/或站点控制流量工程的选项[ABH09a]。但是，这方面的细节有待进一步研究，总体而言，[RFC3484]和[RFC6724]中定义的规则不能直接应用于ILNPv6节点。
Note that for split-horizon operation, there needs to be a DNS management policy for mobile hosts, as when such hosts are away from their "home" network, they will need to update DNS entries so that the global-scope Locator(s) only is (are) used, and these are consistent with the current topological position of the mobile host. Such updates would need to be done using Secure Dynamic DNS Update.
请注意，对于拆分地平线操作，需要为移动主机制定DNS管理策略，因为当这些主机远离其“家庭”网络时，它们需要更新DNS条目，以便仅使用全局范围定位器，并且这些定位器与移动主机的当前拓扑位置一致。这样的更新需要使用安全的动态DNS更新来完成。
For an ILNP mobile network using LP records, there are likely to separate LP records for internal and external use.
对于使用LP记录的ILNP移动网络，可能会有单独的LP记录供内部和外部使用。
Multicast DNS (mDNS) [mDNS11] is popularly used in many end-system OSs today, especially desktop OSs (such as Windows, Mac OS X and Linux). It is used for localised name resolution using names with a ".local" suffix, for both IPv4 and IPv6. This protocol would need to be modified so that when an ILNP-capable node advertises its ".local" name, another ILNP-capable node would be able to see that it is an ILNP-capable, but other, non-ILNP nodes would not be perturbed in operation. The details of a mechanism for using mDNS to enable such a feature are not defined here.
多播DNS（mDNS）[mDNS11]目前在许多终端系统OSs中得到广泛使用，尤其是桌面OSs（如Windows、Mac OS X和Linux）。它用于对IPv4和IPv6使用带有“.local”后缀的名称进行本地化名称解析。此协议需要修改，以便当一个支持ILNP的节点公布其“.local”名称时，另一个支持ILNP的节点能够看到它是一个支持ILNP的节点，但其他非ILNP节点在操作中不会受到干扰。此处未定义使用MDN启用此类功能的机制的详细信息。
In this scenario, if H expects incoming ILNP session requests, for example, then remote nodes normally will need to look up appropriate Identifier and Locator information in the DNS. Just as for IP, and as already described in [RFC6740], a Fully Qualified Domain Name (FQDN) lookup for H should resolve to the correct NID and L32/L64 records. If there are many hosts like H that need to keep DNS records (for any reason, including to allow incoming ILNP session requests), then, potentially, there are many such DNS resource records.
在这种情况下，例如，如果H期望传入ILNP会话请求，则远程节点通常需要在DNS中查找适当的标识符和定位器信息。与IP一样，正如[RFC6740]中所述，H的完全限定域名（FQDN）查找应解析为正确的NID和L32/L64记录。如果有许多像H这样的主机需要保留DNS记录（出于任何原因，包括允许传入的ILNP会话请求），那么可能会有许多这样的DNS资源记录。
As an optimisation, the network as a whole may be configured with one or more L32 and L64 records (to store the value L_1 from our example) that are resolved from an FQDN. At the same time, individual hosts now have an FQDN that returns one or more LP record entries [RFC6742] as well as NID records. The LP record points to the L32 or L64 records for the site. A multihomed site normally will have at least one L32 or L64 record for each distinct uplink (i.e., link from a Site Border Router towards the global Internet), because ILNP uses provider-aggregatable addressing.
作为优化，整个网络可以配置一个或多个L32和L64记录（用于存储我们示例中的值L_1），这些记录是从FQDN解析的。同时，单个主机现在有一个FQDN，它返回一个或多个LP记录条目[RFC6742]以及NID记录。LP记录指向站点的L32或L64记录。多址站点通常对于每个不同的上行链路（即从站点边界路由器到全球互联网的链路）至少有一条L32或L64记录，因为ILNP使用提供商可聚合寻址。
More than one L32 or L64 will be required if multiple Locator values are in use. For example, if an ILNPv6 site has multiple links for multihoming, it will use one L64 record for each Locator value it is using on each link.
如果使用多个定位器值，则需要多个L32或L64。例如，如果一个ILNPv6站点有多个用于多主的链接，它将为每个链接上使用的每个定位器值使用一条L64记录。
In some situations, it can be desirable to obfuscate the details of the interior topology of an end site. Alternately, in some situations, local site policy requires that local-scope routing prefixes be used within the local site. ILNP can provide these capabilities through the ILNP local addressing capability described here, under the control of the SBR.
在某些情况下，可能需要混淆终端站点内部拓扑的细节。或者，在某些情况下，本地站点策略要求在本地站点内使用本地作用域路由前缀。ILNP可以在SBR的控制下，通过此处描述的ILNP本地寻址功能提供这些功能。
As described in Section 2.3 above, locator rewriting can be used to hide the internal structure of the network with respect to the subnetting arrangement of the site network. Specifically, the procedure described in Section 2.3 would be followed, with the following additional modification of the use of Locator values:
如上文第2.3节所述，定位器重写可用于隐藏与站点网络子网布置相关的网络内部结构。具体而言，将遵循第2.3节中描述的程序，并对定位器值的使用进行以下附加修改：
(1) Only the aggregated Locator value, i.e., L_pp, is advertised outside the site (e.g., in an L32 or L64 record), and L_ss is zeroed in that advertisement.
(1) 只有聚合的定位器值，即L_pp，在站点外部发布（例如，在L32或L64记录中），并且L_ss在该发布中归零。
(2) The SBR needs to maintain a mapping table to restore the interior topology information for received packets, for example, by using a mapping table from I values to either L_ss values or internal Locator values.
(2) SBR需要维护映射表，以恢复接收到的分组的内部拓扑信息，例如，通过使用从I值到L_ss值或内部定位器值的映射表。
(3) The SBR needs to zero the L_ss values for all Source Locators of egress packets, as well as perform a Locator rewriting that affects the L_pp bits of the Locator value.
(3) SBR需要将出口数据包的所有源定位器的L_ss值归零，并执行影响定位器值的L_pp位的定位器重写。
Of course, this only obscures the interior topology of the site, not the exterior connectivity of the site. In order for the site to be reachable from the global Internet, the site's DNS entries need to advertise Locator values for the site to the global Internet (e.g., in L32, L64 records).
当然，这只会模糊站点的内部拓扑，而不是站点的外部连接。为了从全球互联网访问站点，站点的DNS条目需要向全球互联网公布站点的定位器值（例如，在L32、L64记录中）。
For backwards compatibility, for ILNP, the ICMP checksum is always calculated identically as for IPv6 or IPv4. For ILNPv6, this means that the SBR need not be aware if ILNPv6 is operating as described in [RFC6740] and [RFC6741]. For ILNPv4, again, the SBR need not be aware of the operation if ILNPv4 is operating as it will not need to inspect the extension header carrying the I value.
为了向后兼容，对于ILNP，ICMP校验和的计算始终与IPv6或IPv4相同。对于ILNPv6，这意味着SBR无需知道ILNPv6是否按照[RFC6740]和[RFC6741]中的说明运行。对于ILNPv4，同样，如果ILNPv4正在运行，SBR不需要知道运行情况，因为它不需要检查带有I值的扩展头。
In order to support communication between two internal nodes that happen to be using global-scope addresses (for whatever reason), the SBR MUST support the "hair pinning" behaviour commonly used in existing NAT/NAPT devices. (This behaviour is described in Section 6 of RFC 4787 [RFC4787].)
为了支持恰好使用全局作用域地址的两个内部节点之间的通信（无论出于何种原因），SBR必须支持现有NAT/NAPT设备中常用的“头发固定”行为。（RFC 4787[RFC4787]第6节中描述了这种行为。）
In the near-term, a more common deployment scenario will be to deploy ILNP incrementally, with some ordinary classic IP traffic still existing. In this case, the SBR should maintain flow state that contains a flag for each flow indicating whether or not that flow is using ILNP. If that flag indicated ILNP were enabled for a given flow, and ILNP local numbering were also enabled, then the SBR would know that it should perform the simpler ILNP Locator rewriting mapping. If that flag indicated ILNP were not enabled for a given flow and IP NAT or IP NAPT were also enabled, then the SBR would know that it should perform the more complex NAT/NAPT translation (e.g., including TCP or UDP checksum recalculation).
在短期内，更常见的部署场景将是增量部署ILNP，一些普通的经典IP流量仍然存在。在这种情况下，SBR应保持流量状态，其中包含每个流量的标志，指示该流量是否使用ILNP。如果该标志指示为给定流启用了ILNP，并且也启用了ILNP本地编号，则SBR将知道它应该执行更简单的ILNP定位器重写映射。如果该标志指示未为给定流启用ILNP，并且也启用了IP NAT或IP NAPT，则SBR将知道它应该执行更复杂的NAT/NAPT转换（例如，包括TCP或UDP校验和重新计算）。
NOTE: Existing commercial security-aware routers (e.g., Juniper SRX routers) already can maintain flow state for millions of concurrent IP flows. This feature would add one flag to each flow's state, so this approach is believed scalable today using existing commercial technology.
注意：现有的商业安全感知路由器（如Juniper SRX路由器）已经可以为数百万并发IP流保持流状态。这一特性将为每个流的状态添加一个标志，因此这种方法被认为可以使用现有的商业技术进行扩展。
Those applications that do not use IP Address values in application state or configuration data are considered to be "well behaved". For well-behaved applications, no further enhancements are required. Where application-layer protocols are not well behaved, for example, the File Transfer Protocol (FTP), then the SBR might need to perform additional stateful processing -- just as NAT and NAPT equipment needs to do today for FTP. See the description in Section 7.6 of [RFC6741].
那些在应用程序状态或配置数据中不使用IP地址值的应用程序被视为“性能良好”。对于性能良好的应用程序，不需要进一步的增强。如果应用层协议表现不好，例如文件传输协议（FTP），那么SBR可能需要执行额外的有状态处理——就像NAT和NAPT设备现在需要对FTP执行的那样。参见[RFC6741]第7.6节中的说明。
When the SBR rewrites a Locator in an ILNP packet, that obscures information about how well a particular path is working between the sender and the receiver of that ILNP packet. So, the SBR that rewrites Locator values needs to include mechanisms to ensure that any packet with a new Destination Locator will travel along a valid path to the intended destination node. For ILNPv4, the path liveness will be no worse than IPv4, and mechanisms already in use for IPv4 can be reused. For ILNPv6, the path liveness will be no worse than for IPv6, and mechanisms already in use for IPv6 can be reused.
当SBR重写ILNP数据包中的定位器时，这会模糊关于该ILNP数据包的发送方和接收方之间的特定路径工作情况的信息。因此，重写定位器值的SBR需要包括确保具有新目的地定位器的任何分组将沿着有效路径到预期目的地节点的机制。对于ILNPv4，路径活跃度不会比IPv4差，并且可以重用已用于IPv4的机制。对于ILNPv6，路径活跃度不会比IPv6差，并且可以重用已经用于IPv6的机制。
In the future, the Border Router Discovery Protocol (BRDP) also might be used in some deployments to indicate which routing prefixes are currently valid and which site border routers currently have a working uplink [BRDP11].
将来，边界路由器发现协议（BRDP）也可能用于某些部署中，以指示哪些路由前缀当前有效，哪些站点边界路由器当前具有工作上行链路[BRDP11]。
The ILNP Architectural Description [RFC6740] describes the basic approach to enabling Site Multihoming (S-MH) with ILNP. However, as an option, it is possible to leave the control of S-MH to an ILNP-enabled SBR. This alternative is based on the use of the Localised Numbering function described in Section 2 of this document.
ILNP体系结构描述[RFC6740]描述了使用ILNP实现站点多主（S-MH）的基本方法。然而，作为一种选择，可以将S-MH的控制权留给启用ILNP的SBR。该替代方案基于本文件第2节中所述的本地化编号功能的使用。
The approach to Site Multihoming (S-MH) using an SBR is best illustrated through an example, as shown in Figure 3.1.
如图3.1所示，使用SBR的站点多归宿（S-MH）方法通过一个示例得到了最好的说明。
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | sbr1+------. .
. .L_L | | . .
. .----+ | . Internet .
. H . | | . .
. . | sbr2+------. .
. . . . +------+ L_2 . .
. .
. . . .
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | sbr1+------. .
. .L_L | | . .
. .----+ | . Internet .
. H . | | . .
. . | sbr2+------. .
. . . . +------+ L_2 . .
. .
. . . .
CN = Correspondent Node H = Host L_1 = global Locator value 1 L_2 = global Locator value 2 L_L = local Locator value SBR = Site Border Router sbrN = interface N on SBR
CN=对应节点H=主机L_1=全局定位器值1 L_2=全局定位器值2 L_L=本地定位器值SBR=站点边界路由器sbrN=SBR上的接口N
Figure 3.1: Alternative Site Multihoming Example with an SBR
图3.1：使用SBR的替代站点多中心示例
The situation here is similar to the localised numbering example, except that the SBR now has two external links, with using Locator value L_1 and another using Locator value L_2. These could, e.g., for ILNPv6, be separate, Provider Aggregated (PA) IPv6 prefixes from two different ISPs. H has IL-V [I_H, L_L], and will forward a packet to CN as given in expression (1a). However, when the packet reaches the SBR, local policy will decide whether the packet is forwarded on the link sbr1 using L_1 or on sbr2 using L_2. Of course, the correct Locator value will be rewritten into the egress packet in place of L_L.
这里的情况与本地化编号示例类似，只是SBR现在有两个外部链接，使用定位器值L_1，另一个使用定位器值L_2。例如，对于ILNPv6，它们可以是来自两个不同ISP的独立的、提供商聚合（PA）IPv6前缀。H具有IL-V[I_H，L_L]，并且将如表达式（1a）中所给出的那样将分组转发到CN。然而，当数据包到达SBR时，本地策略将决定是在链路sbr1上使用L_1转发数据包，还是在sbr2上使用L_2转发数据包。当然，正确的定位器值将被重写到出口数据包中以代替L_L。
If only local numbering is being used, then the SBR need never advertise any global Locator values. However, it could do, as described in Section 2.2.
如果仅使用本地编号，则SBR不需要公布任何全局定位器值。但是，也可以这样做，如第2.2节所述。
One of the key uses for multihoming is providing resilience to link failure. If either link breaks, then the SBR can manage the change in connectivity locally. For example, assume SBR has been configured to use sbr1 for all traffic, and sbr2 only as backup link. So, SBR directs packets from H to communicate with CN using sbr1, and CN will receive packets as in expression (1b) and respond with packets as in expression (2a).
多归属的一个关键用途是提供链路故障恢复能力。如果任一链路中断，SBR可以在本地管理连接的变化。例如，假设SBR已配置为对所有流量使用sbr1，而sbr2仅作为备份链路。因此，SBR使用sbr1指示来自H的分组与CN通信，CN将接收表达式（1b）中的分组，并使用表达式（2a）中的分组进行响应。
However, if sbr1 goes down then SBR will move the communication to interface sbr2. As H is not aware of the actions of the SBR, the SBR must maintain some state about IL-V "pairs" in order to hand off the connectivity from sbr1 to sbr2. So, when moving the communication to sbr2, the SBR would firstly send a Locator Update (LU) message [RFC6745] [RFC6743], to CN informing it that L_2 is now the valid Locator for the communication. This operation would not be visible to H, although there might be some disruption to transmission, e.g., packets being sent from CN to H that are in flight when sbr1 goes down may be lost. The SBR might also need to update DNS entries (see Section 3.3). Since ILNP requires that all Locator Update messages be authenticated by the ILNP Nonce, the SBR will need to include the appropriate Nonce values as part of its cache of information about ILNP sessions traversing the SBR. (NOTE: Since commercial security gateways available as of this writing reportedly can handle full stateful packet inspection for millions of flows at multi-gigabit speeds, it should be practical for such devices to cache the ILNP flow information, including Nonce values.)
但是，如果sbr1下降，则SBR将把通信移动到接口sbr2。由于H不知道SBR的动作，SBR必须保持一些关于IL-V“对”的状态，以便将连接从sbr1切换到sbr2。因此，当将通信移动到sbr2时，SBR将首先向CN发送定位器更新（LU）消息[RFC6745][RFC6743]，通知CN L_2现在是通信的有效定位器。该操作对H不可见，尽管可能会对传输造成一些中断，例如，当sbr1下降时，从CN发送到H的正在飞行中的数据包可能会丢失。SBR可能还需要更新DNS条目（见第3.3节）。由于ILNP要求所有定位器更新消息都由ILNP Nonce进行身份验证，因此SBR将需要包括适当的Nonce值，作为其关于穿过SBR的ILNP会话的信息缓存的一部分。（注：据报道，由于截至本文撰写之时可用的商业安全网关可以以数千兆位的速度处理数百万流的全状态数据包检查，因此此类设备缓存ILNP流信息（包括Nonce值）应该是可行的。）
This approach has some efficiency gains over the approach for multihoming described in [RFC6740], where each hosts manages its own connectivity.
与[RFC6740]中所述的多宿方法相比，这种方法具有一些效率增益，其中每个主机管理自己的连接。
If sbr1 was to be reinstated, now with Locator value L_3, then local policy would determine if the communication should be moved back to sbr1, with appropriate additional actions, such as transmission of LU messages with the new Locator values and also the updates to DNS.
如果恢复sbr1，现在使用定位器值L_3，则本地策略将确定是否应将通信移回sbr1，并采取适当的附加措施，例如使用新定位器值传输LU消息，以及更新DNS。
Note that in such movement of an ILNP session across interfaces at the SBR, only Locator values in ILNP packets are changed. As already noted in [RFC6740], end-to-end transport-layer session state invariance is maintained.
注意，在SBR处的ILNP会话跨接口的这种移动中，仅改变ILNP数据包中的定位器值。如[RFC6740]中所述，端到端传输层会话状态保持不变。
When the SBR manages connectivity as described above, the internal hosts, such as H, are not necessarily aware of any connectivity changes. Indeed, there is certainly no requirement for them to be aware. So, if H was a server expecting incoming connections, the SBR must update the relevant DNS entries when the site connectivity changes.
当SBR如上所述管理连接时，内部主机（例如H）不一定知道任何连接更改。事实上，他们当然不需要知道。因此，如果H是一个需要传入连接的服务器，则SBR必须在站点连接更改时更新相关DNS条目。
There are two possibilities: each host could have its own L32 or L64 records; or the site might use a combination of LP and L32/L64 records (see Section 2.4). Either way, the SBR would need to update the relevant DNS entries. For our example, with ILNPv6 and LP records in use, the SBR would need to manage two L64 records (one for each uplink) that would resolve from a FQDN, for example, site.example.com. Meanwhile, individual hosts, such as H, have an FQDN that resolves to an NID value and an LP record that would contain the value site.example.com, which then would be used to look up the two L64 records.
有两种可能性：每个主机都可以有自己的L32或L64记录；或者，站点可以使用LP和L32/L64记录的组合（参见第2.4节）。无论哪种方式，SBR都需要更新相关的DNS条目。例如，在使用ILNPv6和LP记录的情况下，SBR需要管理两个L64记录（每个上行链路一个），这些记录将从FQDN解析，例如site.example.com。同时，个别主机（如H）具有解析为NID值的FQDN和包含值site.example.com的LP记录，然后将使用该值查找两条L64记录。
If the SBR is multihomed, as in Figure 3.1, then it will have (at least) two Locator values, one for each link, and local policy will need to be used to determine how preference values are applied in the relevant L32 and L64 records.
如果SBR是多址的，如图3.1所示，那么它将（至少）有两个定位值，每个链接一个，并且需要使用本地策略来确定如何在相关L32和L64记录中应用首选值。
Imagine that in the scenario described above, there was a link failure that resulted in sbr1 going down and sbr2 was used. Existing ILNP sessions in progress would move to sbr2 as described above. However, new incoming ILNP sessions to the site would need to know to use L_2 and not L_1. L_1 and L_2 would be stored in DNS records (e.g., L32 for ILNPv4 or L64 for ILNPv6). If a remote host has already resolved from DNS that L_1 is the correct Locator for sending packets to the site, then that host might be holding stale information.
想象一下，在上述场景中，出现了一个链路故障，导致sbr1停机，并使用了sbr2。如上文所述，正在进行的现有ILNP会议将转移到sbr2。但是，站点的新传入ILNP会话需要知道如何使用L_2而不是L_1。L_1和L_2将存储在DNS记录中（例如，L32用于ILNPv4或L64用于ILNPv6）。如果远程主机已从DNS解析出L_1是向站点发送数据包的正确定位器，则该主机可能持有过时信息。
DNS allows values returned to be aged using Time-To-Live (TTL), which is specified in the time unit of seconds. So that remote nodes do not hold on to stale values from DNS, the L64 records for our site should have low TTL values. An appropriate value must be considered carefully. For example, let us assume that the site administrator knows that when sbr1 fails, it takes 20 seconds to failover to sbr2. Then, 20 s would seem to be an appropriate time to use for the TTL value of an L64 for the site: if a remote node had just resolved the value L_1 for the site, and the link to sbr1 went down, that remote node would not hold the stale value of L_1 for any longer than it takes the site to failover to sbr2 and use L_2.
DNS允许使用生存时间（TTL）对返回的值进行老化，TTL以秒为时间单位指定。为了使远程节点不保留来自DNS的过时值，我们站点的L64记录应该具有较低的TTL值。必须仔细考虑适当的值。例如，假设站点管理员知道当sbr1失败时，故障切换到sbr2需要20秒。然后，对于站点L64的TTL值，20秒似乎是一个合适的时间：如果远程节点刚刚解析了站点的L_1值，并且到sbr1的链接中断，那么该远程节点保持L_1的过时值的时间不会超过站点故障切换到sbr2并使用L_2所需的时间。
Our studies for a university school site network show that low TTL values, as low as zero, are feasible for operational use [BA11].
我们对大学校园网的研究表明，低TTL值（低至零）可用于操作[BA11]。
NOTE: From 01 November 2010, the site network of the School of Computer Science, University of St Andrews, UK, has been running operational DNS with DNS A records that have TTL of zero. At the time of writing of this document (November 2012), a zero DNS TTL was still in use at the school.
注：从2010年11月01日起，英国圣·安驻斯大学计算机学院的网站网络运行DNS，DNS为TTL为零的记录。在编写本文件时（2012年11月），学校仍在使用零DNS TTL。
For site multihoming, with multiple SBRs, a situation may be as follows (see also Section 5.3.1 in [RFC6740]).
对于具有多个SBR的现场多主系统，情况可能如下（另见[RFC6740]第5.3.1节）。
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 P
CP=协调协议L_1=全局定位器值1 L_2=全局定位器值2 SBR_A=站点边界路由器A SBR_B=站点边界路由器P
Figure 3.2: A Dual-Router Multihoming Scenario for ILNP
图3.2:ILNP的双路由器多主场景
The use of two physical routers provides an extra level of resilience compared to the scenario of Figure 3.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
与图3.1中的场景相比，使用两个物理路由器提供了额外的恢复能力。两个路由器之间的协调协议（CP）根据站点的任何管理策略保持其动作同步
network. Such functions are available today in some commercial network security products. Note that, logically, there is little difference between Figures 5.1 and 3.2, but with two distinct routers in Figure 3.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和3.2之间的差别不大，但对于图3.2中的两个不同路由器，需要使用CP进行交互。当然，也可以在每个路由器和两个以上的路由器中有多个接口。
The ILNP Architectural Description [RFC6740] describes the basic approach to enabling site (network) mobility with ILNP. However, as an option, it is possible to leave the control of site mobility to an ILNP-enabled SBR by exploiting the alternative site multihoming feature described in Section 3 of this document.
ILNP体系结构描述[RFC6740]描述了使用ILNP实现站点（网络）移动性的基本方法。然而，作为一种选择，通过利用本文件第3节所述的替代站点多主功能，可以将站点移动控制权留给支持ILNP的SBR。
Again, as described in [RFC6740], we exploit the duality between mobility and multihoming for ILNP.
同样，如[RFC6740]中所述，我们利用ILNP的移动性和多宿之间的对偶性。
Let us consider the mobile network in Figure 4.2, which is taken from [RFC6740].
让我们考虑图4.2中的移动网络，它取自[RCFC4040]。
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . L_L | ra1+------. .
. .----+ | . .
. H . | ra2+-- . .
. . . . +------+ . .
. . .
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . L_L | ra1+------. .
. .----+ | . .
. H . | ra2+-- . .
. . . . +------+ . .
. . .
Figure 4.1a: ILNP Mobile Network before Handover
图4.1a：切换前的ILNP移动网络
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . L_L | ra1+------. . . . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ L_2 . . . . .
. .
. . .
ISP_2
site ISP_1
network SBR . . .
. . . . +------+ L_1 . .
. . L_L | ra1+------. . . . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ L_2 . . . . .
. .
. . .
ISP_2
Figure 4.1b: ILNP Mobile Network during Handover
图4.1b：切换期间的ILNP移动网络
site ISP_2
network SBR . . .
. . . . +------+ . .
. . L_L | ra1+-- . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ L_2 . .
. . .
site ISP_2
network SBR . . .
. . . . +------+ . .
. . L_L | ra1+-- . .
. .----+ | . .
. H . | ra2+------. .
. . . . +------+ L_2 . .
. . .
Figure 4.1c: ILNP Mobile Network after Handover
图4.1c：切换后的ILNP移动网络
H = host L_1 = global Locator value 1 L_2 = global Locator value 2 L_L = local Locator value raN = radio interface N SBR = Site Border Router
H=主机L_1=全局定位器值1 L_2=全局定位器值2 L_L=本地定位器值raN=无线电接口N SBR=站点边界路由器
Figure 4.1: An Alternative Mobile Network Scenario with an SBR
图4.1：使用SBR的替代移动网络场景
We assume that the site (network) is mobile, and the SBR has two radio interfaces, ra1 and ra2. In the figure, ISP_1 and ISP_2 are separate, radio-based service providers, accessible via interfaces ra1 and ra2.
我们假设站点（网络）是移动的，SBR有两个无线电接口，ra1和ra2。在图中，ISP_1和ISP_2是独立的、基于无线电的服务提供商，可通过接口ra1和ra2访问。
While the SBR makes the transition from using a single link (Figure 4.1a) to the handover overlap on both links (Figure 4.1b), to only using a single link again (Figure 4.1c), the host H continues to use only Locator value L_L, as already described for Site Multihoming (S-MH). During this time the actions taken by the SBR are the same as already described in [RFC6740], except that the SBR:
当SBR从使用单个链路（图4.1a）过渡到两个链路上的切换重叠（图4.1b）再过渡到仅使用单个链路（图4.1c）时，主机H继续仅使用定位器值L_L，如站点多址（S-MH）所述。在此期间，SBR采取的行动与[RFC6740]中所述的相同，但SBR：
a) also performs that ILNP localised numbering function described in Section 2.
a) 还执行第2节中描述的ILNP本地化编号功能。
b) does not need to advertise L_1 and L_2 internally if only local numbering is being used.
b) 如果仅使用本地编号，则无需在内部公布L_1和L_2。
As for the case of S-MH above, H need not be aware of the change in connectivity for the SBR if it is only using local numbering, and the SBR would send LU messages for H (for any correspondent nodes, not shown in Figure 4.1), and would update DNS entries as required.
对于上述S-MH的情况，如果SBR仅使用本地编号，则H无需知道SBR连接的变化，SBR将为H发送LU消息（对于任何对应节点，未在图4.1中显示），并根据需要更新DNS条目。
The difference to the S-MH scenario described earlier in this document is that in the situation of Figure 4.1b, the SBR can opt to use soft handover has previously described in [RFC6740].
与本文件前面描述的S-MH场景不同的是，在图4.1b的情况下，SBR可以选择使用[RFC6740]中先前描述的软切换。
Again, there is an efficiency gain compared to the situation described in [RFC6740]: the SBR provides a convenient point at which to centrally manage the movement of the site as a whole. Note that in Figure 4.1b, the site is multihomed.
同样，与[RFC6740]中描述的情况相比，效率有所提高：SBR提供了一个方便的点，可以集中管理整个场地的移动。注意，在图4.1b中，站点是多址的。
As for S-MH, L_1 and L_2 could be advertised internally, as a local policy decision, for those hosts that require direct control of their connectivity.
至于S-MH，L_1和L_2可以作为本地政策决定在内部发布，用于那些需要直接控制其连接的主机。
Note that for handover, immediate handover will have a similar behaviour to a link outage as described for S-MH. However, as ILNP allows soft-handover, during the handover period, this should help to reduce (perhaps even remove) packet loss.
注意，对于切换，立即切换将具有与S-MH所述的链路中断类似的行为。然而，由于ILNP允许软切换，因此在切换期间，这应有助于减少（甚至可能消除）数据包丢失。
As for S-MH, a similar discussion to Section 3.3 applies for mobile networks with respect to the updates to DNS. As a mobile network is likely to have more frequent changes to its connectivity than a multihomed network would due to connectivity changes, the use of LP DNS records is likely to be particularly advantageous here.
至于S-MH，第3.3节的类似讨论适用于移动网络的DNS更新。由于连接性变化，移动网络的连接性可能比多宿网络的连接性变化更频繁，因此使用LP DNS记录在这里可能特别有利。
As for S-MH, a similar discussion to Section 3.4 applies for mobile networks with respect to the TTL of L32 and/or L64 records that are used for the name of the mobile network. In the case of the mobile network, it makes sense for the TTL to be aligned to the time for handover.
对于S-MH，与第3.4节类似的讨论适用于移动网络，涉及用于移动网络名称的L32和/或L64记录的TTL。在移动网络的情况下，将TTL与切换时间对齐是有意义的。
The use of Locator rewriting provides some simple yet useful options for traffic engineering (TE) controlled from the edge-site via the SBR, requiring no cooperation from the service provider other than the provision of basic connectivity services, e.g., physical connectivity, allocation of IP Address prefixes and packet forwarding. This does not preclude other TE options that are already in use, such as use of MPLS, but we choose to highlight here the specific options available and controllable solely through the use of ILNP.
定位器重写的使用为通过SBR从边缘站点控制的流量工程（TE）提供了一些简单但有用的选项，除了提供基本连接服务（例如物理连接、IP地址前缀分配和数据包转发）外，不需要服务提供商的合作。这并不排除已经在使用的其他TE选项，例如MPLS的使用，但我们选择在此强调仅通过使用ILNP可用和可控的特定选项。
When a site network is multihomed, we have seen that the use of the Locator rewriting function permits the SBR to have packet-by-packet control when forwarding on external links. Various configuration and policies could be applied at the SBR in order to control the egress and ingress traffic to the site network.
当站点网络是多址网络时，我们已经看到，定位器重写功能的使用允许SBR在外部链路上进行转发时具有逐包控制。SBR可以应用各种配置和策略，以控制站点网络的进出流量。
Let us consider Figure 5.1, and assume ILNP local numbering is in use; that H1, H2, and H3 use, respectively, Identifier values, I_1, I_2 and I_3; and all of them use Locator value L_L.
让我们考虑图5.1，假设ILNP本地编号正在使用中；H1、H2和H3分别使用标识符值I_1、I_2和I_3；它们都使用定位值L_L。
site . . . .
network SBR . .
. . . . +------+ L_1 . .
. . | sbr1+------. .
. H2 .L_L | | . .
. H3 .----+ | . Internet .
. . | | . .
. H1 . | sbr2+------. .
. . . . +------+ L_2 . .
. .
. . . .
site . . . .
network SBR . .
. . . . +------+ L_1 . .
. . | sbr1+------. .
. H2 .L_L | | . .
. H3 .----+ | . Internet .
. . | | . .
. H1 . | sbr2+------. .
. . . . +------+ L_2 . .
. .
. . . .
HN = host N L_1 = global Locator value 1 L_2 = global Locator value 2 L_L = local Locator value SBR = Site Border Router sbrN = interface N on sbr
HN=主机N L_1=全局定位器值1 L_2=全局定位器值2 L_L=本地定位器值SBR=站点边界路由器sbrN=SBR上的接口N
Figure 5.1: A Site Multihoming Scenario for Traffic Control
图5.1：交通控制的站点多主场景
The SBR could be configured, subject to local policy, to try to control load across the external links. For example, it could be configured initially with the following mappings:
SBR可以根据本地策略进行配置，以尝试控制外部链路上的负载。例如，最初可以使用以下映射对其进行配置：
srcI=I_1, sbr1 --- (3a)
srcI=I_2, sbr2 --- (3b)
srcI=I_3, sbr1 --- (3c)
srcI=I_1, sbr1 --- (3a)
srcI=I_2, sbr2 --- (3b)
srcI=I_3, sbr1 --- (3c)
These mappings direct packets matching course Identifier values to particular outgoing interfaces. As load changes, these mappings could be changed. For example, expression (3c) could be changed to:
这些映射将匹配课程标识符值的数据包定向到特定的传出接口。随着负载的变化，这些映射可能会发生变化。例如，表达式（3c）可以更改为：
srcI=I_3, sbr2 --- (4)
srcI=I_3, sbr2 --- (4)
and the SBR would need to send LU message to the correspondents of H3 (sbr to uses L_2 while sbr1 uses L_1). The egress connectivity is totally within control of the SBR under administrative policy, as already seen in the descriptions of multihoming and mobility in this document.
SBR需要向H3的通讯员发送LU消息（SBR使用L_2，而sbr1使用L_1）。根据管理政策，出口连接完全在SBR的控制范围内，如本文件中关于多宿和移动性的描述所示。
Of course, more complex policies are possible, based on:
当然，更复杂的政策是可能的，基于：
- whether ILNP sessions are incoming or outgoing - time of day - internal subnets
- ILNP会话是传入还是传出-时间-内部子网
and any number of criteria already in use for control of traffic.
以及已经用于交通控制的任何数量的标准。
In expressions (3a,b,c) above, source I values are used. However:
在上面的表达式（3a、b、c）中，使用源I值。然而：
- destination I values could be used - source or destination L values could be used - mappings could be to L values, not to specific interfaces
- 可以使用目标I值-可以使用源或目标L值-映射可以是到L值，而不是到特定接口
and, again, any number of criteria could be used to manipulate the packet path, based on filtering of values in header fields and local policy.
并且，同样地，基于头字段和本地策略中的值的过滤，可以使用任意数量的标准来操纵分组路径。
With ILNP, hosts do not need to be aware of the operation of the SBR in this manner.
使用ILNP，主机不需要以这种方式了解SBR的操作。
Note, again, that in this scenario, there is nothing to prevent SBR from also advertising L_1 and L_2 into the site network. If required, administrative controls could be used to enable selective hosts in the site network to use L_1 and L_2 directly as described in [RFC6740].
再次注意，在这种情况下，没有任何东西可以阻止SBR在站点网络中宣传L_1和L_2。如果需要，可以使用管理控制，使站点网络中的选择性主机能够直接使用L_1和L_2，如[RFC6740]中所述。
Extending the scenario for load-balancing described above, it is also be possible for the ILNP-capable SBR to direct traffic along specific network paths based on the use of different L values, i.e., by using multiple prefixes assigned from upstream providers.
扩展上述负载平衡的场景，支持ILNP的SBR也可以基于不同L值的使用（即，通过使用从上游提供商分配的多个前缀）沿着特定网络路径引导流量。
Of course, as previously discussed, these prefixes can be Provider Aggregated (PA) and need not be Provider Independent (PI).
当然，如前所述，这些前缀可以是提供者聚合的（PA），而不需要是提供者独立的（PI）。
Let us consider Figure 5.2 and assume ILNP local numbering is in use; that H1, H2 and H3 use, respectively, Identifier values, I_1, I_2, and I_3; and all of them use Locator value L_L. Let us also assume that the node CN uses IL-V [I_CN, L_CN].
让我们考虑图5.2，假设ILNP本地编号正在使用中；H1、H2和H3分别使用标识符值I_1、I_2和I_3；它们都使用定位值L\u L。我们还假设节点CN使用IL-V[I\u CN，L\u CN]。
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L1,L2 . . +----+
. . | sbr1+--------. .
. H2 .L_L | | . .
. H3 .----+ sbr2+--------. Internet .
. . | | L3,L4 . .
. . | | . .
. H1 . | sbr3+--------. .
. . . . +------+ L5,L6 . .
. .
. . . .
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L1,L2 . . +----+
. . | sbr1+--------. .
. H2 .L_L | | . .
. H3 .----+ sbr2+--------. Internet .
. . | | L3,L4 . .
. . | | . .
. H1 . | sbr3+--------. .
. . . . +------+ L5,L6 . .
. .
. . . .
CN = correspondent node HN = host N LN = global Locator value N L_L = local Locator value SBR = Site Border Router sbrN = interface N on sbr
CN=对应节点HN=主机N LN=全局定位器值N L\U L=本地定位器值SBR=站点边界路由器sbrN=SBR上的接口N
Figure 5.2: A Site Multihoming Scenario for Traffic Control
图5.2：交通控制的站点多主场景
Here, many configurations are possible. For example, for egress traffic:
在这里，许多配置都是可能的。例如，对于出口交通：
srcI=I_2, L2 --- (5a)
srcI=I_3, L3 --- (5b)
dstI=I_CN, L6 --- (5c)
srcI=I_1 dstI=I_CN, L1 --- (5d)
srcI=I_2, L2 --- (5a)
srcI=I_3, L3 --- (5b)
dstI=I_CN, L6 --- (5c)
srcI=I_1 dstI=I_CN, L1 --- (5d)
Expression (5a) maps all egress packets from H2 to have their source Locator value rewritten to L2 (and implicitly to use interface sbr1). Expression (5b) maps all egress packets from H3 to have their source Locator value rewritten to L3 (and implicitly to use interface sbr2). Expression (5c) directs any traffic to CN to use Locator value L6 as the source Locator (and implicitly to use interface sbr3), and may override (5a) and (5b), subject to local policy, when packets to CN are from H2 or H3.
表达式（5a）将H2中的所有出口数据包映射为将其源定位器值重写为L2（并隐式使用接口sbr1）。表达式（5b）映射来自H3的所有出口数据包，使其源定位器值重写为L3（并隐式地使用接口sbr2）。表达式（5c）指示到CN的任何流量使用定位器值L6作为源定位器（并隐式使用接口sbr3），并且当到CN的数据包来自H2或H3时，可以根据本地策略覆盖（5a）和（5b）。
Meanwhile, in expression (5d), we see a further, more specific rule, in that packets from H1 destined to CN should use Locator value L1 (and implicitly to use interface sbr1).
同时，在表达式（5d）中，我们看到了更进一步、更具体的规则，即从H1发送到CN的数据包应该使用定位值L1（并且隐式地使用接口sbr1）。
Note the implicit bindings to interfaces in expressions (5a,b,c,d), compared to the explicit bindings in expressions (3a,b,c). ILNP only requires that the Locator values are correctly rewritten and packets forwarded in conformance with the routing already configured for the Locator values.
请注意，与表达式（3a，b，c，d）中的显式绑定相比，表达式（5a，b，c，d）中的接口隐式绑定。ILNP仅要求正确重写定位器值，并按照已为定位器值配置的路由转发数据包。
Of course, these rules can be changed dynamically at the SBR, and the SBR will migrate ILNP sessions across Locator values, as already described above for mobility.
当然，这些规则可以在SBR处动态更改，SBR将跨定位器值迁移ILNP会话，如上文针对移动性所述。
As ILNP has first class support for mobility and multihoming, and supports flexible options for localised addressing, there is great potential for it to be used in datacentre scenarios. Further details of possibilities are in [BA12], with a summary presented here.
由于ILNP对移动性和多宿具有一流的支持，并支持灵活的本地化寻址选项，因此它在数据中心场景中的应用潜力巨大。[BA12]中有关于可能性的更多详细信息，这里有一个摘要。
There are several scenarios that could be beneficial to datacentres, in order to provide functions such as load balancing, resilience and fault tolerance, and resource management:
为了提供负载平衡、恢复能力和容错以及资源管理等功能，有几种方案可能对数据中心有益：
- Same datacentre, internal Virtual Machine (VM) mobility: This could be beneficial in load balancing, dynamically, where load changes are taking place. The remote user does not see the VM has moved.
- 同一个数据中心，内部虚拟机（VM）移动性：这有利于动态地进行负载平衡，因为负载正在发生变化。远程用户看不到VM已移动。
- Different datacentres, transparent mobility: This is where the datacentre resources may be geographically distributed, but the geographical movement is transparent to the remote user.
- 不同的数据中心，透明的移动：这是数据中心资源可能在地理上分布的地方，但地理移动对远程用户是透明的。
- Different datacentres, mobility is visible: This is where the datacentre resources may be geographically distributed, but the geographical movement is visible to the remote user.
- 不同的数据中心，移动性是可见的：这是数据中心资源可能在地理上分布的地方，但地理移动对远程用户是可见的。
These are three situations that may be supported by ILNP, but they are not the only ones: we provide these here as examples, and they are not intended to be prescriptive. The intention is only to show the flexibility that is possible through the use of ILNP.
这是ILNP可能支持的三种情况，但它们不是唯一的情况：我们在这里提供这些作为示例，并且它们不是规定性的。其目的只是展示通过使用ILNP可能实现的灵活性。
This section describes some Virtual Machine (VM) mobility capabilities that are possible with ILNP. Depending on the internal details and virtualisation model provided by a VM platform, it might be sufficient for the guest operating system to support ILNP. In some cases, again depending on the internal details and virtualisation model provided by a VM platform, the VM platform itself also might need to include support for ILNP.
本节描述了ILNP可以实现的一些虚拟机（VM）移动性功能。根据VM平台提供的内部细节和虚拟化模型，来宾操作系统可能足以支持ILNP。在某些情况下，同样取决于VM平台提供的内部细节和虚拟化模型，VM平台本身也可能需要包括对ILNP的支持。
Details of how a particular VM platform works, and which virtualisation model(s) a VM platform supports, are beyond the scope of this document. Internal implementation details of VM platform support for ILNP are also beyond the scope of this document, just as internal implementation details for any other networked system supporting ILNP are beyond the scope of this document.
特定虚拟机平台如何工作以及虚拟机平台支持哪些虚拟化模型的详细信息超出了本文档的范围。支持ILNP的VM平台的内部实现细节也超出了本文档的范围，正如支持ILNP的任何其他网络系统的内部实现细节超出了本文档的范围一样。
Let us consider first the scenario of Figure 6.1, noting its similarity to Figure 2.1 for use of localised numbering.
让我们首先考虑图6.1的场景，注意到它与图2.1的相似性，用于使用本地化编号。
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | +------. .
. H2 .L_L | | . .
. .----+ | . Internet .
. V*H1 . | | . .
. . | | . .
. . . . +------+ . .
. .
. . . .
site . . . . +----+
network SBR . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | +------. .
. H2 .L_L | | . .
. .----+ | . Internet .
. V*H1 . | | . .
. . | | . .
. . . . +------+ . .
. .
. . . .
CN = Correspondent Node V = Virtual machine image Hx = Host x L_1 = global Locator value L_L = local Locator value SBR = Site Border Router
CN=对应节点V=虚拟机映像Hx=主机x L_1=全局定位器值L_L=本地定位器值SBR=站点边界路由器
Figure 6.1: A Simple Virtual Image Mobility Example for ILNP
图6.1:ILNP的简单虚拟图像移动示例
L_L is a Locator value used for the ILNP hosts H1 and H2. Here, the "V*H1" signifies that the virtual machine image V is currently resident on H1. Let us assume that V has Identifier I_V. Note that as H1 and H2 have the same Locator value (L_1), as far as CN is concerned, it does not matter if V is resident on H1 or H2, all transport packets between V and CN will have the same signature as far as CN is concerned, e.g., for a UDP flow (in analogy to (1a)):
L_L是用于ILNP主机H1和H2的定位器值。这里，“V*H1”表示虚拟机映像V当前驻留在H1上。让我们假设V具有标识符I_V。注意，由于H1和H2具有相同的定位值（L_1），就CN而言，无论V是否驻留在H1或H2上，就CN而言，V和CN之间的所有传输数据包将具有相同的签名，例如，对于UDP流（类似于（1a））：
<UDP: I_V, I_CN, P_V, P_CN><ILNP: L_1, L_CN> --- (6a)
<UDP: I_V, I_CN, P_V, P_CN><ILNP: L_1, L_CN> --- (6a)
Now, if V was to migrate to H2, the migration would be an issue purely local to the site network, and the end-to-end integrity of the transport flow would be maintained.
现在，如果V迁移到H2，迁移将是站点网络的纯本地问题，传输流的端到端完整性将得到维护。
Of course, there are practical operating systems issues in enabling such a migration locally, but products exist today that could be modified and made ILNP-aware in order to enable such VM image mobility.
当然，在本地实现这样的迁移存在实际的操作系统问题，但是现在存在的产品可以修改并使ILNP意识到，以便实现这样的VM映像移动。
Note that for convenience, above, we have used localised numbering for ILNP, but if local Locator values were not used and the whole site simply used L_1, the principle would be the same.
请注意，为了方便起见，我们在上面为ILNP使用了本地化编号，但是如果不使用本地定位器值，并且整个站点仅使用L_1，则原理是相同的。
Let us now consider an extended version of the scenario above in Fig. 6.2, where we see that there is a second site network, which is geographically distant to the first site network, and the two site networks are interconnected via their respective SBRs.
现在让我们考虑上面图6.2中的场景的扩展版本，在那里我们看到有第二个站点网络，它在地理上与第一个站点网络距离很远，并且两个站点网络通过它们各自的SBR互连。
site . . . . +----+
network 1 SBR1 . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | +------. .
. .L_L1| | . .
. .----+ | . Internet .
. V*H1 . | | . .
. . | | . .
. . . . +---+--+ . .
: . .
: . .
. . . . +---+--+ L_2 . .
. . | +------. .
. H2 .L_L2| | . .
. .----+ | . .
. . | | . .
. . | | . .
. . . . +------+ . .
site SBR2 . .
network 2 . . . .
site . . . . +----+
network 1 SBR1 . .-----+ CN |
. . . . +------+ L_1 . . +----+
. . | +------. .
. .L_L1| | . .
. .----+ | . Internet .
. V*H1 . | | . .
. . | | . .
. . . . +---+--+ . .
: . .
: . .
. . . . +---+--+ L_2 . .
. . | +------. .
. H2 .L_L2| | . .
. .----+ | . .
. . | | . .
. . | | . .
. . . . +------+ . .
site SBR2 . .
network 2 . . . .
: = logical inter-router link and coordination CN = Correspondent Node V = Virtual machine image Hx = Host x L_y = global Locator value y L_Lz = local Locator value z SBR = Site Border Router
：=逻辑路由器间链路和协调CN=对应节点V=虚拟机映像Hx=主机x L_y=全局定位器值y L_Lz=本地定位器值z SBR=站点边界路由器
Figure 6.2: A Simple Localised Numbering Example for ILNP
图6.2:ILNP的简单本地化编号示例
Note that the logical inter-router link between SBR1 and SBR2 could be realised physically in many different ways that are available today and are not ILNP-specific, e.g., leased line, secure IP-layer or Layer 2 tunnel, etc. We assume that this link also allows coordination between the two SBRs. For now, we ignore external link L_2 on SBR2, and assume that the remote node, CN, is in communication with V through SBR1.
请注意，SBR1和SBR2之间的逻辑路由器间链路可以通过许多不同的方式在物理上实现，这些方式目前可用，并且不是ILNP特定的，例如租用线路、安全IP层或第2层隧道等。我们假设此链路还允许两个SBR之间的协调。现在，我们忽略SBR2上的外部链路L_2，并假设远程节点CN通过SBR1与V通信。
When in initial communication, the packets have the signature is given in expression (6a). When V moves to H2, it now uses Locator value L_L2, but all communication between V and CN is still routed via SBR1. So, the remote CN still sees that same packet signature as given in expression (6a). L_L1 and L_L2 are, effectively, two internal (private) subnetworks, and are not visible to CN.
当在初始通信中时，具有签名的分组在表达式（6a）中给出。当V移动到H2时，它现在使用定位器值L_L2，但V和CN之间的所有通信仍然通过SBR1路由。因此，远程CN仍然看到与表达式（6a）中给出的相同的分组签名。L_L1和L_L2实际上是两个内部（专用）子网，对CN不可见。
However, SBR2 and SBR1 must coordinate so that any further communication to V via SBR1 is routed across the inter-router link. Again, there are commercial products today that could be adapted to manage such shared state.
但是，SBR2和SBR1必须协调，以便通过SBR1与V的任何进一步通信都通过路由器间链路路由。同样，今天有一些商业产品可以用来管理这种共享状态。
Clearly, in the scenario of the section above, once V has moved to site network 2, it may be beneficial, for a number of reasons, for communication to V to be routed via SBR2 rather than SBR1.
显然，在上述章节的场景中，一旦V移动到站点网络2，出于多种原因，通过SBR2而不是SBR1路由到V的通信可能是有益的。
When V moves from site network 1 to site network 2, this visibility of mobility could be by V sending ILNP Locator Update messages to the CN during the mobility process. Also, V would update any relevant ILNP DNS records, such as L64 records, for new ILNP session requests to be routed via SBR2.
当V从站点网络1移动到站点网络2时，可通过V在移动过程中向CN发送ILNP定位器更新消息来实现移动的可见性。此外，V将更新任何相关的ILNP DNS记录，例如L64记录，以便通过SBR2路由新的ILNP会话请求。
Indeed, let us now consider again Figure 6.2, and assume now that Local locators L_L1 and L_L2 are not in use on either site network, and each site networks uses its own global Locator value, L_1 and L_2, respectively, internally. In that case, the packet flow signature for V when it is in site network 1 as viewed from CN is, again as given in expression (6a). However, when V moves to site network 2, it would simply use L_2 as its new Locator, send Locator Update messages to CN as would a normal mobile node for ILNP, and complete its migration to H2. Then, CN would see the packet signatures as in expression (6b).
事实上，现在让我们再次考虑图6.2，假设现在本地定位器LYL1和LYL2不在任何一个站点网络上使用，并且每个站点网络分别使用其自己的全局定位器值LY1和LY2。在这种情况下，当V在从CN观看的站点网络1中时，其分组流签名也是如表达式（6a）中给出的。然而，当V移动到站点网络2时，它将简单地使用L_2作为它的新定位器，像ILNP的普通移动节点一样向CN发送定位器更新消息，并完成到H2的迁移。然后，CN将看到如表达式（6b）所示的分组签名。
<UDP: I_V, I_CN, P_V, P_CN><ILNP: L_2, L_CN> --- (6b)
<UDP: I_V, I_CN, P_V, P_CN><ILNP: L_2, L_CN> --- (6b)
In this case, no "special" inter-router link is required for mobility -- the normal Internet connectivity between SBR1 and SBR2 would suffice. However, it is quite likely that some sort of tunnelled link would still be desirable to offer protection of the VM image as it migrates.
在这种情况下，移动性不需要“特殊”路由器间链路——SBR1和SBR2之间的正常互联网连接就足够了。然而，很可能仍然需要某种隧道链接来在VM映像迁移时提供保护。
For the remote host -- the CN -- the availability of ILNP would be beneficial. However, for the first two scenarios listed above, as the packet signature of the transport flows remains fixed from the
对于远程主机CN来说，ILNP的可用性将是有益的。然而，对于上面列出的前两个场景，由于传输流的分组签名从
viewpoint of the CN, it seems possible that the benefits of ILNP VM mobility could be used for datacentres even while CNs remain as normal IP hosts. Of course, a major caveat here is that the application level protocols should be "well behaved": that is, the application protocol or configuration should not rely on the use of IP Addresses.
从CN的角度来看，ILNP虚拟机移动性的好处似乎可以用于数据中心，即使CNs仍然是正常的IP主机。当然，这里的一个主要警告是，应用程序级协议应该“表现良好”：即，应用程序协议或配置不应该依赖于IP地址的使用。
Extending the Locator rewriting paradigm, it is possible to also enable Location privacy for ILNP by a modified version of the "onion routing" paradigm that is used for Tor [DMS04] [RSG98].
扩展定位器重写范例，还可以通过Tor[DMS04][RSG98]使用的“洋葱路由”范例的修改版本，为ILNP启用位置隐私。
To enable this function, we use a middlebox that we call the Locator Rewriting Relay. The function of this unit is described by the use of Figure 7.1.
为了启用此功能，我们使用一个称为定位器重写继电器的中间盒。该装置的功能如图7.1所示。
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (7a)
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (7a)
v
|
+--+--+
| | src=[I_H, L_1], L_X --- (7b)
| LRR | dst=[I_H, L_X], L_1 --- (7c)
| |
+--+--+
|
v
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_X, L_CN> --- (7d)
v
|
+--+--+
| | src=[I_H, L_1], L_X --- (7b)
| LRR | dst=[I_H, L_X], L_1 --- (7c)
| |
+--+--+
|
v
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_X, L_CN> --- (7d)
LRR = Locator Rewriting Relay
LRR = Locator Rewriting Relay
Figure 7.1: Locator Rewriting Relay (LRR) Example
图7.1：定位器重写继电器（LRR）示例
The operation of the LRR is conceptually very simple. We assume that the LRR first has mappings as given in expressions (7b) and (7c) (see next subsection). Expression (7b) says that for packets with src IL-V [I_H, L_1], the packet's source Locator value should be rewritten to value L_X and then forwarded. Expression (7c) has the complimentary mapping for packets with destination IL-V [I_H, L_1] (for the reverse direction).
LRR的操作在概念上非常简单。我们假设LRR首先具有表达式（7b）和（7c）中给出的映射（见下一小节）。表达式（7b）表示，对于具有src IL-V[I_H，L_1]的数据包，数据包的源定位器值应重写为值L_X，然后转发。表达式（7c）具有与目的地IL-V[I_H，L_1]（用于反向）的包的互补映射。
Expression (6a) is a UDP/ILNP packet as might be sent in Figure 2.1 from H to CN. However, instead of going directly to L_CN, the packet with destination Locator L_1 goes to a LRR. Expression (7d) is the result of the mapping of packet (7a) using expression (7b).
表达式（6a）是一个UDP/ILNP数据包，如图2.1所示，可以从H发送到CN。然而，具有目的地定位器L_1的分组不是直接去到L_CN，而是去到LRR。表达式（7d）是使用表达式（7b）映射数据包（7a）的结果。
Note that it is entirely possible that the packet of expression (7d) then is processed by another LRR for source Locator value L_X. Effectively, this creates and LRR path for the packet, as an overlay path on top of the normal IP routing.
请注意，表达式（7d）的数据包随后完全可能由另一个源定位器值L_X的LRR处理。实际上，这为数据包创建和LRR路径，作为正常IP路由之上的覆盖路径。
In this way, there is a level of protection, without the need for cryptographic techniques, for the (topological) Location of the packet. Of course, an extremely well-resourced adversary could, potentially, backtrack the LRR path, but, depending on the LRR overlay path that is created, could be very difficult to trace in reality. For example, the mechanism will protect against off-path attacks, but where the threat regime includes the potential for on-path attacks, cryptographically protected tunnels between H and LRR might be required.
通过这种方式，对数据包的（拓扑）位置有一定程度的保护，而不需要加密技术。当然，一个资源极其丰富的对手可能会回溯LRR路径，但是，根据创建的LRR覆盖路径，在现实中很难追踪。例如，该机制将防止路径外攻击，但如果威胁机制包括路径内攻击的可能性，则可能需要H和LRR之间的加密保护隧道。
Again, as the Locator value is not part of the end-to-end state, this mechanism is very general and has a low overhead.
同样，由于定位器值不是端到端状态的一部分，因此该机制非常通用，开销较低。
There are many options for managing the "network" of LRRs that could be in place if such a system was used on a large scale, including the setting up and removal of LRR state for packet relaying, as for expressions (7b) and (7c). We consider this function to be outside the scope of these ILNP specifications, but note that there are many existing mechanisms that could modified for use, and also many possibilities for new mechanisms that would be specific to the use of ILNP LRRs.
如果大规模使用这样的系统，则有许多用于管理LRR的“网络”的选项，包括设置和移除用于分组中继的LRR状态，如表达式（7b）和（7c）。我们认为这个功能超出了这些ILNP规范的范围，但是请注意，有许多现有的机制可以修改使用，并且对于使用ILNP LRR的新机制也有许多可能性。
(Note also that the control/management communication with the LRR does not need to use ILNP: IPv4 or IPv6 could be used.)
（还请注意，与LRR的控制/管理通信不需要使用ILNP：可以使用IPv4或IPv6。）
The host, H, by itself could install the required state, assuming it was aware of suitable information to contact the LRR. The first packet in an ILNP session might contain a header option called a Locator Redirection Option (LRO). The LRO would contain the Locator value that should be rewritten into the source Locator of the packet. When a LRR receives such a packet, it would install the required state. Such a mechanism could be soft-state, requiring periodic use of the LRO in order to maintain the state in the LRR. The LRO could also be delivered using an ICMP ECHO packet sent from H to the LRR, periodically, again to maintain a soft-state update.
主机H本身可以安装所需状态，前提是它知道与LRR联系的适当信息。ILNP会话中的第一个数据包可能包含称为定位器重定向选项（LRO）的头选项。LRO将包含应该重写到数据包的源定位器中的定位器值。当LRR收到这样的数据包时，它将安装所需的状态。这种机制可以是软状态，需要定期使用LRO以保持LRR中的状态。LRO也可以使用从H定期发送到LRR的ICMP回送包来交付，以保持软状态更新。
It would, of course, be prudent to protect the LRR state control packets with some sort of authentication token, to prevent an adversary from easily installing false LRR state and causing packets
当然，谨慎的做法是使用某种身份验证令牌保护LRR状态控制数据包，以防止对手轻易安装错误的LRR状态并导致数据包丢失
from H or its correspondent to be subject to man-in-the-middle attacks, or black-holing. Again, such attacks are not specific to ILNP or new to ILNP.
从H或其通讯员受到中间人攻击，或黑洞。同样，此类攻击不是ILNP特有的，也不是ILNP的新攻击。
It would also be possible to use proprietary application level protocols, with strong authentication for the control of the LRR state. For example, an application level protocol based on XMPP (http://xmpp.org/) operating over SSL.
还可以使用专有的应用程序级协议，通过强身份验证控制LRR状态。例如，基于XMPP的应用程序级协议(http://xmpp.org/)通过SSL操作。
Above, we have offered very brief and incomplete descriptions of some possibilities, and we do not necessarily mandate any one of them: they serve only as examples.
在上文中，我们对一些可能性进行了非常简短和不完整的描述，我们不一定要求任何一种可能性：它们只是作为例子。
For the sake of completeness, and in complement to Section 6, it should be noted that ILNP can use either cryptographically verifiable Identifier values, or use Identifier values that provide a level of anonymity to protect a user's privacy. More details are given in Sections 2 and 11 of [RFC6741].
为完整起见，并作为对第6节的补充，应注意，ILNP可以使用可加密验证的标识符值，或使用提供匿名级别的标识符值来保护用户的隐私。更多详情见[RFC6741]第2节和第11节。
The relevant security considerations to this document are the same as for the main ILNP Architectural Description [RFC6740]. The one additional point to note is that this document describes ILNP capability in the SBR and so those adversaries wishing to subvert the operation of ILNP specifically, have a target that would, potentially, disable an entire site. However, this is not an attack vector that is specific to ILNP: today, disruption of an IPv4 or IPv6 SBR would have the same impact.
本文件的相关安全注意事项与主要ILNP体系结构描述[RFC6740]相同。另外需要注意的一点是，本文件描述了SBR中的ILNP能力，因此那些希望颠覆ILNP操作的对手有一个可能使整个站点失效的目标。然而，这不是一个特定于ILNP的攻击向量：今天，IPv4或IPv6 SBR的中断将产生相同的影响。
The security considerations for Section 7 (Location Privacy) are already documented in [DMS04] and [RSG98]. One possibility is that the LRR mechanism itself could be used by an adversary to launch an attack and hide his own (topological) Location, for example. This is already possible for IPv4 and IPv4 with a Tor-like system today, so is not new to ILNP.
第7节（位置隐私）的安全注意事项已记录在[DMS04]和[RSG98]中。一种可能性是LRR机制本身可能被对手用来发起攻击并隐藏自己的（拓扑）位置，例如。这在今天的IPv4和具有Tor类系统的IPv4中已经是可能的，因此对于ILNP来说并不陌生。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[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月。
[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月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，2006年8月。
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.，Ed.，和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864]Van de Velde，G.，Hain，T.，Droms，R.，Carpenter，B.，和E.Klein，“IPv6的本地网络保护”，RFC 4864，2007年5月。
[RFC4924] Aboba, B., Ed., and E. Davies, "Reflections on Internet Transparency", RFC 4924, July 2007.
[RFC4924]Aboba，B.，Ed.，和E.Davies，“关于互联网透明度的思考”，RFC 49242007年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月。
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on IPv6 Network Address Translation", RFC 5902, July 2010.
[RFC5902]Thaler，D.，Zhang，L.，和G.Lebovitz，“IAB对IPv6网络地址转换的思考”，RFC 59022010年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月。
[RFC6740] Atkinson, R. and S. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, November 2012.
[RFC6740]Atkinson，R.和S.Bhatti，“标识符定位器网络协议（ILNP）体系结构描述”，RFC 67402012年11月。
[RFC6741] Atkinson, R. and S. Bhatti, "Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations", RFC 6741, November 2012.
[RFC6741]Atkinson，R.和S.Bhatti，“标识符定位器网络协议（ILNP）工程和实施注意事项”，RFC 67412012年11月。
[RFC6742] Atkinson, R., Bhatti, S. and S. Rose, "DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)", RFC 6742, November 2012.
[RFC6742]Atkinson，R.，Bhatti，S.和S.Rose，“标识符定位器网络协议（ILNP）的DNS资源记录”，RFC 67422012年11月。
[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月。
[ABH07a] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility as an Integrated Service Through the Use of Naming", Proceedings of ACM Workshop on Mobility in the Evolving Internet Architecture (MobiArch), ACM SIGCOMM, Kyoto, Japan. 27 Aug 2007.
[ABH07a]Atkinson，R.，Bhatti，S.和S.Hailes，“通过使用命名将移动性作为一项综合服务”，ACM研讨会论文集，关于互联网架构演进中的移动性（MobiArch），ACM SIGCOMM，日本京都。2007年8月27日。
[ABH07b] Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal for Unifying Mobility with Multi-Homing, NAT, & Security", Proceedings of 2nd ACM Workshop on Mobility Management and Wireless Access (MobiWAC), ACM, Chania, Crete, Oct 2007. ISBN: 978-1-59593-809-1
[ABH07b]Atkinson，R.，Bhatti，S.和S.Hailes，“将移动性与多主、NAT和安全性统一起来的提案”，第二届ACM移动性管理和无线接入研讨会论文集，ACM，克里特岛查尼亚，2007年10月。ISBN:978-1-593-809-1
[ABH08a] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility Through Naming: Impact on DNS", Proceedings of 3rd ACM Workshop on Mobility in the Evolving Internet Architecture (MobiArch), ACM SIGCOMM, Seattle, WA, USA. Aug 2008.
[ABH08a]Atkinson，R.，Bhatti，S.和S.Hailes，“通过命名实现的移动性：对DNS的影响”，第三届ACM关于互联网架构演进中移动性的研讨会论文集，ACM SIGCOMM，华盛顿州西雅图，2008年8月。
[ABH08b] Atkinson, R., Bhatti, S., and S. Hailes, "Harmonised Resilience, Security, and Mobility Capability for IP", Proceedings of the IEEE Military Communications Conference (MILCOM), IEEE, San Diego, CA, USA, Nov 2008.
[ABH08b]Atkinson，R.，Bhatti，S.和S.Hailes，“IP的协调弹性、安全性和移动性”，IEEE军事通信会议记录（MILCOM），IEEE，圣地亚哥，加利福尼亚州，美国，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 Conference (MILCOM), IEEE, Boston, MA, USA, Oct 2009.
[ABH09a]Atkinson，R，Bhatti，S.和S.Hailes，“IP的现场控制安全多址和流量工程”，IEEE军事通信会议记录（MILCOM），IEEE，波士顿，马萨诸塞州，美国，2009年10月。
[ABH09b] Atkinson, R., Bhatti, S., and S. Hailes, "ILNP: Mobility, Multi-Homing, Localised Addressing and Security Through Naming"", Telecommunication Systems", vol. 42, no. 3-4, pp 273-291, Springer-Verlag, Dec 2009.
[ABH09b]Atkinson，R.，Bhatti，S.和S.Hailes，“ILNP：通过命名的移动性、多归属、本地化寻址和安全性”，电信系统，第42卷，第3-4期，第273-291页，Springer Verlag，2009年12月。
[ABH10] Atkinson, R., Bhatti, S., and S. Hailes, "Evolving the Internet Architecture Through Naming", IEEE Journal on Selected Areas in Communication (JSAC), vol. 28, no. 8, pp 1319-1325, IEEE, Oct 2010.
[ABH10]Atkinson，R.，Bhatti，S.和S.Hailes，“通过命名来发展互联网架构”，IEEE通信领域选定领域杂志（JSAC），第28卷，第8期，第1319-1325页，IEEE，2010年10月。
[appDNS] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, "Architectural Considerations on Application Features in the DNS", Work in Progress, July 2012.
[appDNS]Peterson，J.，Kolkman，O.，Tschofenig，H.，和B.Aboba，“DNS中应用程序功能的架构考虑”，正在进行的工作，2012年7月。
[BA11] Bhatti, S. and R. Atkinson, "Reducing DNS Caching", Proceedings of IEEE Global Internet Symposium (GI2011), Shanghai, P.R. China, 15 Apr 2011.
[BA11]Bhatti，S.和R.Atkinson，“减少DNS缓存”，IEEE全球互联网研讨会论文集（GI2011），中国上海，2011年4月15日。
[BA12] Bhatti, S. and R. Atkinson, "Secure & 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), IEEE, Baltimore, MD, USA, Nov 2011.
[BAK11]Bhatti，S.，Atkinson，R.，和J.Klemets，“整合挑战网络”，IEEE军事通信会议记录（MILCOM），IEEE，巴尔的摩，马里兰州，美国，2011年11月。
[BRDP11] Boot, T. and A. Holtzer, "BRDP Framework", Work in Progress, January 2011.
[BRDP11]Boot，T.和A.Holtzer，“BRDP框架”，正在进行的工作，2011年1月。
[DMS04] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the second-generation onion router", Proceedings of 13th USENIX Security Symposium, USENIX Association, San Diego, CA, USA, 2004.
[DMS04]丁莱丁，R.，马修森，N.，和P.塞弗森，“Tor：第二代洋葱路由器”，第13届USENIX安全研讨会论文集，USENIX协会，圣地亚哥，加利福尼亚州，美国，2004年。
[IEEE04] "IEEE 802.1D - IEEE Standard for Local and Metropolitan Area Networks, Media Access Control (MAC) Bridges", IEEE Standards Association, New York, NY, USA, 9 June 2004. Print: ISBN 0-7381-3881-5 SH95213. PDF: ISBN 0-7381-3982-3 SS95213.
[IEEE04]“IEEE 802.1D-局域网和城域网的IEEE标准，媒体访问控制（MAC）网桥”，IEEE标准协会，纽约，纽约，美国，2004年6月9日。打印：ISBN 0-7381-3881-5 SH95213。PDF:ISBN 0-7381-3982-3 SS95213。
[LABH06] Atkinson, R., Lad, M., Bhatti, S., and S. Hailes, "A Proposal for Coalition Networking in Dynamic Operational Environments", Proceedings of IEEE Military Communications Conference (MILCOM), IEEE, Washington, DC, USA, Nov 2006.
[LABH06]Atkinson，R.，Lad，M.，Bhatti，S.，和S.Hailes，“动态作战环境中的联盟网络提案”，IEEE军事通信会议记录（MILCOM），IEEE，华盛顿特区，美国，2006年11月。
[mDNS11] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, December 2011.
[mDNS11]Cheshire，S.和M.Krochmal，“多播DNS”，正在进行的工作，2011年12月。
[RAB09] Rehunathan, D., Atkinson, R., and S. Bhatti, "Enabling Mobile Networks Through Secure Naming", Proceedings of IEEE Military Communications Conference (MILCOM), IEEE, Boston, MA, USA, Oct 2009.
[RAB09]Rehunahan，D.，Atkinson，R.，和S.Bhatti，“通过安全命名实现移动网络”，IEEE军事通信会议记录（MILCOM），IEEE，波士顿，马萨诸塞州，美国，2009年10月。
[RB10] Rehunathan, D. and S. Bhatti, "A Comparative Assessment of Routing for Mobile Networks", Proceedings of 6th 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无线和移动计算网络与通信国际会议（WiMob）会议记录，IEEE，尼亚加拉瀑布，加拿大，2010年10月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 62962011年6月。
[RSG98] Reed, M., Syverson, P., and D. Goldschlag, "Anonymous Connections and Onion Routing", IEEE Journal on Selected Areas in Communications, Vol. 16, No. 4, IEEE, Piscataway, NJ, USA, May 1998.
[RSG98]Reed，M.，Syverson，P.，和D.Goldschlag，“匿名连接和洋葱路由”，IEEE通信选定领域杂志，第16卷，第4期，IEEE，皮斯卡塔韦，新泽西州，美国，1998年5月。
Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, Bruce Simpson, Robin Whittle, and John Wroclawski (in alphabetical order) provided review and feedback on earlier versions of this document. Steve Blake provided an especially thorough review of an early version of the entire ILNP document set, which was extremely helpful. We also wish to thank the anonymous reviewers of the various ILNP papers for their feedback.
Steve Blake、Stephane Bortzmeyer、Mohamed Boucadair、Noel Chiappa、Wes George、Steve Hailes、Joel Halpern、Mark Handley、Volker Hilt、Paul Jakma、Dae Young Kim、Tony Li、Yakov Rehkter、Bruce Simpson、Robin Whittle和John Wroclawski（按字母顺序）对本文件的早期版本进行了审查和反馈。Steve Blake对整个ILNP文档集的早期版本进行了特别彻底的审查，这非常有帮助。我们还要感谢各种ILNP论文的匿名评审员的反馈。
Roy Arends provided expert guidance on technical and procedural aspects of DNS issues.
Roy Arends就DNS问题的技术和程序方面提供了专家指导。
Authors' Addresses
作者地址
RJ Atkinson Consultant San Jose, CA 95125 USA
美国加利福尼亚州圣何塞RJ阿特金森咨询公司95125
EMail: rja.lists@gmail.com
EMail: rja.lists@gmail.com
SN Bhatti School of Computer Science University of St Andrews North Haugh, St Andrews Fife KY16 9SX Scotland, UK
SN BaTHI计算机学院圣·安驻斯大学北HAUH，圣安德鲁斯FIFE KY16 9SX苏格兰，英国
EMail: saleem@cs.st-andrews.ac.uk
EMail: saleem@cs.st-andrews.ac.uk