Internet Engineering Task Force (IETF) D. Lewis
Request for Comments: 6832 D. Meyer
Category: Experimental D. Farinacci
ISSN: 2070-1721 Cisco Systems
V. Fuller
January 2013
Internet Engineering Task Force (IETF) D. Lewis
Request for Comments: 6832 D. Meyer
Category: Experimental D. Farinacci
ISSN: 2070-1721 Cisco Systems
V. Fuller
January 2013
Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites
定位器/ID分离协议（LISP）和非LISP站点之间的互通
Abstract
摘要
This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP. A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non-LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. Second, this document adds Network Address Translation (NAT) functionality to LISP ITRs and LISP Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation.
本文档描述了允许运行定位器/ID分离协议（LISP）的站点与可能使用IPv4、IPv6或两者但未运行LISP的Internet站点进行互操作的技术。讲LISP的站点的一个基本特性是，它们在发出或接收的所有流量的源和目标字段中使用端点标识符（EID），而不是传统的IP地址。虽然EID在语法上与IPv4或IPv6地址相同，但通常在全局路由系统中不携带到它们的路由，因此非讲LISP的站点需要一种互操作性机制来与讲LISP的站点交换流量。本文件介绍了三种这样的机制。第一种是使用一种新的网元，即LISP代理入口隧道路由器（代理ITR），作为非LISP主机的中间LISP入口隧道路由器（ITR）。其次，本文档将网络地址转换（NAT）功能添加到LISP ITR和LISP出口隧道路由器（ETR）中，以将可路由IP地址替换为不可路由EID。最后，本文档介绍了代理出口隧道路由器（Proxy ETR），用于处理LISP ITR在没有封装的情况下无法向非LISP站点发送数据包的情况。
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 Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见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/rfc6832.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6832.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Definition of Terms .............................................5
3. LISP Interworking Models ........................................6
4. Routable EIDs ...................................................7
4.1. Impact on Routing Table ....................................7
4.2. Requirement for Sites to Use BGP ...........................7
4.3. Limiting the Impact of Routable EIDs .......................7
4.4. Use of Routable EIDs for Sites Transitioning to LISP .......7
5. Proxy Ingress Tunnel Routers ....................................8
5.1. Proxy-ITR EID Announcements ................................8
5.2. Packet Flow with Proxy-ITRs ................................9
5.3. Scaling Proxy-ITRs ........................................11
5.4. Impact of the Proxy-ITR's Placement in the Network ........11
5.5. Benefit to Networks Deploying Proxy-ITRs ..................11
6. Proxy Egress Tunnel Routers ....................................12
6.1. Packet Flow with Proxy-ETRs ...............................12
7. LISP-NAT .......................................................13
7.1. Using LISP-NAT with LISP-NR EIDs ..........................14
7.2. LISP Sites with Hosts Using RFC 1918 Addresses Sending
to Non-LISP Sites .........................................15
7.3. LISP Sites with Hosts Using RFC 1918 Addresses Sending
Packets to Other LISP Sites ...............................15
7.4. LISP-NAT and Multiple EIDs ................................16
8. Discussion of Proxy-ITRs, LISP-NAT, and Proxy-ETRs .............16
8.1. How Proxy-ITRs and Proxy-ETRs Interact ....................17
9. Security Considerations ........................................17
10. Acknowledgments ...............................................18
11. References ....................................................18
11.1. Normative References .....................................18
11.2. Informative References ...................................18
1. Introduction ....................................................3
2. Definition of Terms .............................................5
3. LISP Interworking Models ........................................6
4. Routable EIDs ...................................................7
4.1. Impact on Routing Table ....................................7
4.2. Requirement for Sites to Use BGP ...........................7
4.3. Limiting the Impact of Routable EIDs .......................7
4.4. Use of Routable EIDs for Sites Transitioning to LISP .......7
5. Proxy Ingress Tunnel Routers ....................................8
5.1. Proxy-ITR EID Announcements ................................8
5.2. Packet Flow with Proxy-ITRs ................................9
5.3. Scaling Proxy-ITRs ........................................11
5.4. Impact of the Proxy-ITR's Placement in the Network ........11
5.5. Benefit to Networks Deploying Proxy-ITRs ..................11
6. Proxy Egress Tunnel Routers ....................................12
6.1. Packet Flow with Proxy-ETRs ...............................12
7. LISP-NAT .......................................................13
7.1. Using LISP-NAT with LISP-NR EIDs ..........................14
7.2. LISP Sites with Hosts Using RFC 1918 Addresses Sending
to Non-LISP Sites .........................................15
7.3. LISP Sites with Hosts Using RFC 1918 Addresses Sending
Packets to Other LISP Sites ...............................15
7.4. LISP-NAT and Multiple EIDs ................................16
8. Discussion of Proxy-ITRs, LISP-NAT, and Proxy-ETRs .............16
8.1. How Proxy-ITRs and Proxy-ETRs Interact ....................17
9. Security Considerations ........................................17
10. Acknowledgments ...............................................18
11. References ....................................................18
11.1. Normative References .....................................18
11.2. Informative References ...................................18
This document describes interoperation mechanisms between LISP [RFC6830] sites that use EIDs that are not globally routed, and non-LISP sites. A key behavior of the separation of Locators and Endpoint IDs is that EID-Prefixes are normally not advertised into the Internet's Default-Free Zone (DFZ). (See Section 4 for the exception case.) Specifically, only Routing Locators (RLOCs) are carried in the Internet's DFZ. Existing Internet sites (and their hosts) that do not run LISP must still be able to reach sites numbered from LISP EID space. This document describes three mechanisms that can be used to provide reachability between sites that are LISP-capable and those that are not.
本文档描述了使用非全局路由EID的LISP[RFC6830]站点与非LISP站点之间的互操作机制。定位器和端点ID分离的一个关键行为是，EID前缀通常不会发布到Internet的默认自由区（DFZ）中。（例外情况见第4节。）具体来说，互联网的DFZ中只携带路由定位器（RLOC）。不运行LISP的现有Internet站点（及其主机）必须仍然能够访问从LISP EID空间编号的站点。本文档描述了三种机制，可用于在支持LISP的站点和不支持LISP的站点之间提供可访问性。
The first mechanism uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. The second mechanism adds a form of Network Address Translation (NAT) functionality to Tunnel Routers (xTRs, where "xTR" refers to either an ITR or ETR), to substitute routable IP addresses for non-routable EIDs. The final network element is the LISP Proxy Egress Tunnel Router (Proxy-ETR), which acts as an intermediate Egress Tunnel Router (ETR) for LISP sites that need to encapsulate LISP packets destined to non-LISP sites.
第一种机制使用一种新的网元，即LISP代理入口隧道路由器（代理ITR），作为非LISP主机的中间LISP入口隧道路由器（ITR）。第二种机制向隧道路由器（xTR，其中“xTR”指ITR或ETR）添加一种形式的网络地址转换（NAT）功能，以将可路由IP地址替换为不可路由的EID。最后一个网元是LISP代理出口隧道路由器（代理ETR），它充当LISP站点的中间出口隧道路由器（ETR），这些站点需要封装发送到非LISP站点的LISP数据包。
More detailed descriptions of these mechanisms and the network elements involved may be found in the following sections:
有关这些机制和所涉及的网络元件的更详细说明，请参见以下章节：
- Section 2 defines terms used throughout this document.
- 第2节定义了本文件中使用的术语。
- Section 3 describes the different cases where interworking mechanisms are needed.
- 第3节描述了需要互通机制的不同情况。
- Section 4 describes the relationship between the new EID-Prefix space and the IP address space used by the current Internet.
- 第4节描述了新EID前缀空间和当前Internet使用的IP地址空间之间的关系。
- Section 5 introduces and describes the operation of Proxy-ITRs.
- 第5节介绍并描述了代理ITRs的操作。
- Section 6 introduces and describes the operation of Proxy-ETRs.
- 第6节介绍并描述了代理ETR的操作。
- Section 7 defines how NAT is used by ETRs to translate non-routable EIDs into routable IP addresses.
- 第7节定义了ETRs如何使用NAT将不可路由的EID转换为可路由的IP地址。
- Section 8 describes the relationship between asymmetric and symmetric interworking mechanisms (Proxy-ITRs and Proxy-ETRs vs. LISP-NAT).
- 第8节描述了不对称和对称互通机制（代理ITR和代理ETR与LISP-NAT）之间的关系。
Note that any successful interworking model should be independent of any particular EID-to-RLOC mapping algorithm. This document does not comment on the value of any of the particular LISP mapping systems.
请注意，任何成功的互通模型都应该独立于任何特定的EID到RLOC映射算法。本文档不评论任何特定LISP映射系统的价值。
Several areas concerning the interworking of LISP and non-LISP sites remain open for further study. These areas include an examination of the impact of LISP-NAT on Internet traffic and applications, understanding the deployment motivations for the deployment and operation of Proxy Tunnel Routers, the impact of EID routes originated into the Internet's Default-Free Zone, and the effects of Proxy Tunnel Routers or LISP-NAT on Internet traffic and applications. Until these issues are fully understood, it is possible that the interworking mechanisms described in this document will be hard to deploy or may have unintended consequences to applications.
关于LISP和非LISP站点交互工作的几个领域仍有待进一步研究。这些领域包括检查LISP-NAT对互联网流量和应用程序的影响，了解代理隧道路由器部署和操作的部署动机，起源于互联网默认自由区的EID路由的影响，以及代理隧道路由器或LISP-NAT对互联网流量和应用程序的影响。在完全理解这些问题之前，本文档中描述的交互机制可能很难部署，或者可能会对应用程序产生意外后果。
Default-Free Zone: The Default-Free Zone (DFZ) refers to the collection of all Internet autonomous systems that do not require a default route to route a packet to any destination.
默认自由区：默认自由区（DFZ）是指不需要默认路由将数据包路由到任何目的地的所有Internet自治系统的集合。
LISP Routable (LISP-R) Site: A LISP site whose addresses are used as both globally routable IP addresses and LISP EIDs.
LISP可路由（LISP-R）站点：其地址用作全局可路由IP地址和LISP EID的LISP站点。
LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are EIDs only; these EIDs are not found in the legacy Internet routing table.
LISP非路由（LISP-NR）站点：地址仅为EID的LISP站点；在传统Internet路由表中找不到这些EID。
LISP Proxy Ingress Tunnel Router (Proxy-ITR): Proxy-ITRs are used to provide connectivity between sites that use LISP EIDs and those that do not. They act as gateways between those parts of the Internet that are not using LISP (the legacy Internet). A given Proxy-ITR advertises one or more highly aggregated EID-Prefixes into the public Internet and acts as the ITR for traffic received from the public Internet. LISP Proxy-ITRs are described in Section 5.
LISP代理入口隧道路由器（代理ITR）：代理ITR用于在使用LISP EID和不使用LISP EID的站点之间提供连接。它们充当未使用LISP（遗留Internet）的Internet部分之间的网关。给定的代理ITR将一个或多个高度聚合的EID前缀播发到公共Internet，并充当从公共Internet接收的流量的ITR。第5节介绍了LISP代理ITR。
LISP Network Address Translation (LISP-NAT): Network address translation between EID space assigned to a site and RLOC space also assigned to that site. LISP-NAT is described in Section 7.
LISP网络地址转换（LISP-NAT）：分配给站点的EID空间和也分配给该站点的RLOC空间之间的网络地址转换。第7节介绍了LISP-NAT。
LISP Proxy Egress Tunnel Router (Proxy-ETR): Proxy-ETRs provide a LISP (routable or non-routable EID) site's ITRs with the ability to send packets to non-LISP sites in cases where unencapsulated packets (the default mechanism) would fail to be delivered. Proxy-ETRs function by having an ITR encapsulate all non-LISP destined traffic to a pre-configured Proxy-ETR. LISP Proxy-ETRs are described in Section 6.
LISP代理出口隧道路由器（代理ETR）：代理ETR为LISP（可路由或不可路由EID）站点的ITR提供了在未封装的数据包（默认机制）无法交付的情况下向非LISP站点发送数据包的能力。代理ETR的功能是让ITR将所有非LISP目的地流量封装到预先配置的代理ETR。第6节介绍了LISP代理ETR。
EID Sub-Namespace: A power-of-two block of aggregatable Locators set aside for LISP interworking.
EID子名称空间：为LISP互通预留的两块可聚合定位器的幂。
For definitions of other terms -- notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please consult the LISP specification [RFC6830].
关于其他术语的定义——特别是映射请求、映射应答、入口隧道路由器（ITR）和出口隧道路由器（ETR）——请参考LISP规范[RFC6830]。
There are 4 unicast connectivity cases that describe how sites can send packets to each other:
有4个单播连接案例描述了站点如何相互发送数据包：
1. non-LISP site to non-LISP site
1. 非LISP站点到非LISP站点
2. LISP site to LISP site
2. LISP站点到LISP站点
3. LISP site to non-LISP site
3. LISP站点到非LISP站点
4. non-LISP site to LISP site
4. 非LISP站点到LISP站点
Note that while Cases 3 and 4 seem similar, there are subtle differences due to the way packets are originated.
注意，虽然案例3和案例4看起来很相似，但由于数据包的产生方式，存在细微的差异。
The first case is the Internet as we know it today and as such will not be discussed further here. The second case is documented in [RFC6830], and there are no new interworking requirements because there are no new protocol requirements placed on intermediate non-LISP routers.
第一个案例是我们今天所知道的互联网，因此这里不再进一步讨论。第二种情况记录在[RFC6830]中，没有新的互通要求，因为中间非LISP路由器上没有新的协议要求。
In Case 3, LISP site to non-LISP site, a LISP site can (in most cases) send packets to a non-LISP site because the non-LISP site prefixes are routable. The non-LISP sites need not do anything new to receive packets. The only action the LISP site needs to take is to know when not to LISP-encapsulate packets. An ITR knows explicitly that the destination is non-LISP if the destination IP address of an IP packet matches a (negative) Map-Cache entry that has the action 'Natively-Forward'.
在情况3中，LISP站点到非LISP站点，LISP站点可以（在大多数情况下）向非LISP站点发送数据包，因为非LISP站点前缀是可路由的。非LISP站点不需要做任何新的事情来接收数据包。LISP站点需要采取的唯一行动是知道何时不使用LISP封装数据包。如果IP数据包的目标IP地址与具有“本机转发”操作的（负）映射缓存项匹配，则ITR明确知道目标为非LISP。
There could be some situations where (unencapsulated) packets originated by a LISP site may not be forwarded to a non-LISP site. These cases are reviewed in Section 6 (Proxy Egress Tunnel Routers).
在某些情况下，LISP站点发出的（未封装的）数据包可能无法转发到非LISP站点。第6节（代理出口隧道路由器）对这些情况进行了审查。
Case 4, typically the most challenging, occurs when a host at a non-LISP site wishes to send traffic to a host at a LISP site. If the source host uses a (non-globally routable) EID as the destination IP address, the packet is forwarded inside the source site until it reaches a router that cannot forward it (due to lack of a default route), at which point the traffic is dropped. For traffic not to be dropped, some mechanism to make this destination EID routable must be in place. Sections 5 (Proxy-ITRs) and 7 (LISP-NAT) describe two such mechanisms. Case 4 also applies to non-LISP packets (as in Case 3) that are returning to the LISP site.
案例4通常是最具挑战性的，发生在非LISP站点的主机希望向LISP站点的主机发送流量时。如果源主机使用（非全局可路由的）EID作为目标IP地址，则数据包将在源站点内转发，直到到达无法转发它的路由器（由于缺少默认路由），此时流量将被丢弃。为了不丢弃流量，必须有某种机制使该目的地EID可路由。第5节（代理ITR）和第7节（LISP-NAT）描述了两种这样的机制。案例4也适用于返回LISP站点的非LISP数据包（如案例3）。
An obvious way to achieve interworking between LISP and non-LISP hosts is for a LISP site to simply announce EID-Prefixes into the DFZ, much like the current routing system, effectively treating them as "Provider-Independent" (PI) prefixes. Having a site do this is undesirable, as it defeats one of the primary goals of LISP -- to reduce global routing system state.
实现LISP和非LISP主机之间互通的一个明显方法是，LISP站点只需将EID前缀通知到DFZ中，这与当前的路由系统非常相似，有效地将它们视为“独立于提供程序”（PI）的前缀。让站点这样做是不可取的，因为它违背了LISP的主要目标之一——减少全局路由系统状态。
If EID-Prefixes are announced into the DFZ, the impact is similar to the case in which LISP has not been deployed, because these EID-Prefixes will be no more aggregatable than existing PI addresses. Such a mechanism is not viewed as a viable long-term solution but may be a viable short-term way for a site to transition a portion of its address space to EID space without changing its existing routing policy.
如果EID前缀被公布到DFZ中，其影响与未部署LISP的情况类似，因为这些EID前缀不会比现有PI地址更具聚合性。这种机制不被视为可行的长期解决方案，但可能是站点在不改变现有路由策略的情况下将部分地址空间转换为EID空间的可行短期方法。
Routable EIDs might require non-LISP sites today to use BGP to, among other things, originate their site's routes into the DFZ, in order to enable ingress Traffic Engineering. Relaxing this requirement (and thus potentially reducing global DFZ routing state) while still letting sites control their ingress Traffic Engineering policy is a design goal of LISP.
可路由EID可能需要非LISP站点使用BGP，除其他外，将其站点的路由发起到DFZ，以便启用入口流量工程。LISP的设计目标是在允许站点控制其入口流量工程策略的同时放宽这一要求（从而潜在地减少全局DFZ路由状态）。
Two schemes are proposed to limit the impact of having EIDs announced in the current global Internet routing table:
建议采用两种方案来限制在当前全球互联网路由表中公布EID的影响：
1. Section 5 discusses the LISP Proxy Ingress Tunnel Router, an approach that provides ITR functionality to bridge LISP-capable and non-LISP-capable sites.
1. 第5节讨论了LISP代理入口隧道路由器，这是一种提供ITR功能以桥接支持LISP和不支持LISP的站点的方法。
2. Section 7 discusses another approach, LISP-NAT, in which NAT [RFC2993] is combined with ITR functionality to limit the impact of routable EIDs on the Internet routing infrastructure.
2. 第7节讨论了另一种方法LISP-NAT，其中NAT[RFC2993]与ITR功能相结合，以限制可路由EID对Internet路由基础设施的影响。
A primary design goal for LISP (and other Locator/ID separation proposals) is to facilitate topological aggregation of namespaces used for the path computation, and thus decrease global routing system overhead. Another goal is to achieve the benefits of improved
LISP（以及其他定位器/ID分离方案）的主要设计目标是促进用于路径计算的名称空间的拓扑聚合，从而减少全局路由系统开销。另一个目标是实现改进后的
aggregation as soon as possible. Individual sites advertising their own routes for LISP EID-Prefixes into the global routing system is therefore not recommended.
尽快集合。因此，不建议个别站点在全球路由系统中为自己的LISP EID前缀路由做广告。
That being said, single-homed sites (or multihomed sites that are not leaking more-specific exceptions) that are already using provider-aggregated prefixes can use these prefixes as LISP EIDs without adding state to the routing system. In other words, such sites do not cause additional prefixes to be advertised. For such sites, connectivity to a non-LISP site does not require interworking machinery because the "PA" (Provider-Assigned) EIDs are already routable (they are effectively LISP-R type sites). Their EIDs are found in the LISP mapping system, and their (aggregate) PA prefix(es) are found in the DFZ of the Internet.
也就是说，已经使用提供者聚合前缀的单宿主站点（或未泄漏更多特定异常的多宿主站点）可以将这些前缀用作LISP EID，而无需向路由系统添加状态。换句话说，这样的网站不会导致额外的前缀被广告。对于此类站点，与非LISP站点的连接不需要互通机制，因为“PA”（提供商指定）EID已经可以路由（它们实际上是LISP-R类型的站点）。他们的EID可以在LISP映射系统中找到，他们的（聚合）PA前缀可以在互联网的DFZ中找到。
The continued announcements of an existing site's Provider-Independent (PI) prefix(es) is of course under the control of that site. Some period of transition, where a site is found both in the LISP mapping system, and as a discrete prefix in the Internet routing system, may be a viable transition strategy. Care should be taken not to advertise additional more-specific LISP EID-Prefixes into the DFZ.
现有站点的独立于提供商（PI）前缀（es）的持续公告当然由该站点控制。在某个过渡时期，站点既可以在LISP映射系统中找到，也可以作为Internet路由系统中的离散前缀，这可能是一种可行的过渡策略。应注意不要在DFZ中公布更多更具体的LISP EID前缀。
Proxy Ingress Tunnel Routers (Proxy-ITRs) allow non-LISP sites to send packets to LISP-NR sites. A Proxy-ITR is a new network element that shares many characteristics with the LISP ITR. Proxy-ITRs allow non-LISP sites to send packets to LISP-NR sites without any changes to protocols or equipment at the non-LISP site. Proxy-ITRs have two primary functions:
代理入口隧道路由器（代理ITR）允许非LISP站点向LISP-NR站点发送数据包。代理ITR是一种新的网络元素，它与LISP ITR具有许多相同的特性。代理ITR允许非LISP站点向LISP-NR站点发送数据包，而无需更改非LISP站点的协议或设备。代理ITR有两个主要功能：
Originating EID Advertisements: Proxy-ITRs advertise highly aggregated EID-Prefix space on behalf of LISP sites so that non-LISP sites can reach them.
原始EID播发：代理ITR代表LISP站点播发高度聚合的EID前缀空间，以便非LISP站点可以访问它们。
Encapsulating Legacy Internet Traffic: Proxy-ITRs also encapsulate non-LISP Internet traffic into LISP packets and route them towards their destination RLOCs.
封装传统互联网流量：代理ITR还将非LISP互联网流量封装到LISP数据包中，并将其路由到目标RLOC。
A key part of Proxy-ITR functionality is to advertise routes for highly aggregated EID-Prefixes into parts of the global routing system. Aggressive aggregation is performed to minimize the number of new announced routes. In addition, careful placement of Proxy-ITRs can greatly reduce the advertised scope of these new routes. To this end, Proxy-ITRs should be deployed close to
代理ITR功能的一个关键部分是将高度聚合EID前缀的路由播发到全局路由系统的各个部分。执行主动聚合以最小化新公布路由的数量。此外，仔细放置代理ITR可以大大减少这些新路由的广告范围。为此，应在附近部署代理ITR
non-LISP-speaking sites rather than close to LISP sites. Such deployment not only limits the scope of EID-Prefix route advertisements but also allows the traffic forwarding load to be spread among many Proxy-ITRs.
非LISP语言网站，而不是接近LISP网站。这种部署不仅限制了EID前缀路由播发的范围，而且允许在多个代理ITR之间分配流量转发负载。
What follows is an example of the path a packet would take when using a Proxy-ITR. In this example, the LISP-NR site is given the EID-Prefix 192.0.2.0/24. For the purposes of this example, neither this prefix nor any covering aggregate are present in the global routing system. In other words, without the Proxy-ITR announcing 192.0.2.0/24, if a packet with this destination were to reach a router in the Default-Free Zone, it would be dropped. The following diagram describes a high-level view of the topology:
下面是使用代理ITR时数据包将采用的路径示例。在本例中，LISP-NR站点被赋予EID前缀192.0.2.0/24。在本例中，全局路由系统中既不存在该前缀也不存在任何覆盖聚合。换句话说，在没有代理ITR宣布192.0.2.0/24的情况下，如果具有此目的地的数据包到达默认自由区中的路由器，它将被丢弃。下图描述了拓扑的高级视图：
Internet DFZ
因特网DFZ
.--------------------------------.
/ \
| Traffic Encap'd to Site's |
| +-----+ RLOC(s) | LISP Site:
| |P-ITR|=========> |
| +-----+ +--+ +-----+ |
| | |PE+------+CE 1 |-|
| | Originated Route +--+ +-----+ | +----+
| V 192.0.2.0/24 | |-|Host|
| +--| +-----+ | +----+
| |PE+------+CE 2 |-| 192.0.2.1
| +---+ +--+ +-----+ |
\ |PE | /
'---------------+-+-+------------' Site EID-Prefix:
| 192.0.2.0/24
| ^
| |
+--+--+ | Traffic
Non LISP Site: | CE | | to
+--+--+ | 192.168.2.1
| |
-----------
|
+----+
|Host|
+----+
.--------------------------------.
/ \
| Traffic Encap'd to Site's |
| +-----+ RLOC(s) | LISP Site:
| |P-ITR|=========> |
| +-----+ +--+ +-----+ |
| | |PE+------+CE 1 |-|
| | Originated Route +--+ +-----+ | +----+
| V 192.0.2.0/24 | |-|Host|
| +--| +-----+ | +----+
| |PE+------+CE 2 |-| 192.0.2.1
| +---+ +--+ +-----+ |
\ |PE | /
'---------------+-+-+------------' Site EID-Prefix:
| 192.0.2.0/24
| ^
| |
+--+--+ | Traffic
Non LISP Site: | CE | | to
+--+--+ | 192.168.2.1
| |
-----------
|
+----+
|Host|
+----+
Figure 1: Example of Proxy-ITR Packet Flow
图1：代理ITR数据包流示例
A full protocol exchange example follows:
完整的协议交换示例如下：
1. The source host makes a DNS lookup EID for the destination and gets 192.0.2.1 in return.
1. 源主机对目标进行DNS查找EID，并得到192.0.2.1作为回报。
2. The source host has a default route to the Customer Edge (CE) router and forwards the packet to the CE.
2. 源主机具有到客户边缘（CE）路由器的默认路由，并将数据包转发给CE。
3. The CE has a default route to its Provider Edge (PE) router and forwards the packet to the PE.
3. CE具有到其提供商边缘（PE）路由器的默认路由，并将数据包转发到PE。
4. The PE has a route to 192.0.2.0/24, and the next hop is the Proxy-ITR.
4. PE有一个到192.0.2.0/24的路由，下一个跃点是代理ITR。
5. The Proxy-ITR has or acquires a mapping for 192.0.2.1 and LISP-encapsulates the packet. The outer IP header now has a destination address of one of the destination EID's RLOCs. The outer source address of this encapsulated packet is the Proxy-ITR's RLOC.
5. 代理ITR拥有或获取192.0.2.1的映射，LISP封装数据包。外部IP报头现在有一个目标EID的RLOC之一的目标地址。此封装数据包的外部源地址是代理ITR的RLOC。
6. The Proxy-ITR looks up the RLOC and forwards the LISP packet to the next hop, after which it is forwarded by other routers to the ETR's RLOC.
6. 代理ITR查找RLOC并将LISP数据包转发到下一跳，然后由其他路由器转发到ETR的RLOC。
7. The ETR decapsulates the packet and delivers the packet to the 192.0.2.1 host in the destination LISP site.
7. ETR解除数据包的封装，并将数据包传送到目标LISP站点中的192.0.2.1主机。
8. Packets from host 192.0.2.1 will flow back through the LISP site's ITR. Such packets are not encapsulated because the ITR knows that the destination (the original source) is a non-LISP site. The ITR knows this because it can check the LISP mapping database for the destination EID and on a failure determines that the destination site is not LISP enabled.
8. 来自主机192.0.2.1的数据包将通过LISP站点的ITR返回。由于ITR知道目的地（原始源）是非LISP站点，因此不会封装此类数据包。ITR知道这一点，因为它可以检查目标EID的LISP映射数据库，并在出现故障时确定目标站点未启用LISP。
9. Packets are then routed natively and directly to the destination (original source) site.
9. 然后，数据包以本机方式直接路由到目的地（原始源）站点。
Note that in this example the return path is asymmetric, so return traffic will not go back through the Proxy-ITR. This is because the LISP-NR site's ITR will discover that the originating site is not a LISP site and will not encapsulate the returning packet (see [RFC6830] for details of ITR behavior).
请注意，在本例中，返回路径是不对称的，因此返回流量不会通过代理ITR返回。这是因为LISP-NR站点的ITR将发现原始站点不是LISP站点，并且不会封装返回的数据包（有关ITR行为的详细信息，请参阅[RFC6830]）。
The asymmetric nature of traffic flows allows the Proxy-ITR to be relatively simple -- it will only have to encapsulate LISP packets.
流量流的不对称性质使得代理ITR相对简单——它只需封装LISP数据包。
Proxy-ITRs attract traffic by announcing the LISP EID namespace into parts of the non-LISP-speaking global routing system. There are several ways that a network could control how traffic reaches a particular Proxy-ITR to prevent it from receiving more traffic than it can handle:
代理ITR通过将LISP EID名称空间宣布为非LISP语言的全局路由系统的一部分来吸引流量。网络可以通过多种方式控制流量到达特定代理ITR的方式，以防止其接收的流量超过其处理能力：
1. The Proxy-ITR's aggregate routes might be selectively announced, giving a coarse way to control the quantity of traffic attracted by that Proxy-ITR. For example, some of the routes being announced might be tagged with a BGP community and their scope of announcement limited by the routing policy of the provider.
1. 代理ITR的聚合路由可能会被选择性地宣布，从而提供一种粗略的方式来控制该代理ITR吸引的流量。例如，正在宣布的某些路由可能会被标记为BGP社区，其宣布范围受提供商的路由策略限制。
2. The same address might be announced by multiple Proxy-ITRs in order to share the traffic using IP Anycast. The asymmetric nature of traffic flows through the Proxy-ITR means that operationally, deploying a set of Proxy-ITRs would be very similar to existing anycasted services like DNS caches. Multiple Proxy-ITRs could advertise the same BGP Next Hop IP address as their RLOC, and traffic would be attracted to the nearest Next Hop according to the network's IGP.
2. 同一地址可能由多个代理ITR宣布，以便使用IP选播共享流量。通过代理ITR的流量的不对称性质意味着，在操作上，部署一组代理ITR与现有的任意广播服务（如DNS缓存）非常相似。多个代理ITR可以公布与其RLOC相同的BGP下一跳IP地址，根据网络的IGP，流量将被吸引到最近的下一跳。
There are several approaches that a network could take in placing Proxy-ITRs. Placing the Proxy-ITR near the source of traffic allows the communication between the non-LISP site and the LISP site to have the least "stretch" (i.e., the least number of forwarding hops when compared to an optimal path between the sites).
网络在放置代理ITR时可以采用几种方法。将代理ITR放置在流量源附近可使非LISP站点和LISP站点之间的通信具有最小的“延伸”（即，与站点之间的最佳路径相比，转发跳数最少）。
Some proposals, for example the Core Router-Integrated Overlay [CRIO], have suggested grouping Proxy-ITRs near an arbitrary subset of ETRs and announcing a 'local' subset of EID space. This model cannot guarantee minimum stretch if the EID-Prefix route advertisement points are changed (such a change might occur if a site adds, removes, or replaces one or more of its ISP connections).
一些提案，例如核心路由器集成覆盖[CRIO]，建议将代理ITR分组到ETR的任意子集附近，并宣布EID空间的“本地”子集。如果EID前缀路由公告点发生更改，此模型无法保证最小拉伸（如果站点添加、删除或替换其一个或多个ISP连接，则可能会发生此类更改）。
When packets destined for LISP-NR sites arrive and are encapsulated at a Proxy-ITR, a new LISP packet header is prepended. This causes the packet's destination to be set to the destination ETR's RLOC. Because packets are thus routed towards RLOCs, it can potentially better follow the Proxy-ITR network's Traffic Engineering policies (such as closest exit routing). This also means that providers that are not default-free and do not deploy Proxy-ITRs end up sending more traffic to expensive transit links (assuming their upstreams have
当发送到LISP-NR站点的数据包到达并封装在代理ITR中时，一个新的LISP数据包头被预先封装。这将导致数据包的目的地设置为目的地ETR的RLOC。由于数据包因此被路由到RLOC，因此它可能更好地遵循代理ITR网络的流量工程策略（例如最近出口路由）。这也意味着，非默认免费且未部署代理ITR的提供商最终会向昂贵的传输链路发送更多流量（假设其上游有
deployed Proxy-ITRs) rather than to the ETR's RLOC addresses, to which they may well have cheaper and closer connectivity (via, for example, settlement-free peering). A corollary to this would be that large transit providers deploying Proxy-ITRs may attract more traffic, and therefore more revenue, from their customers.
部署的代理ITR）而不是ETR的RLOC地址，它们很可能具有更便宜和更紧密的连接（例如，通过无结算对等）。由此产生的一个推论是，部署代理ITR的大型运输提供商可能会从其客户那里吸引更多的流量，从而带来更多的收入。
Proxy Egress Tunnel Routers (Proxy-ETRs) allow LISP sites to send packets to non-LISP sites in the case where the access network does not allow the LISP site to send packets with the source address of the site's EID(s). A Proxy-ETR is a new network element that, conceptually, acts as an ETR for traffic destined to non-LISP sites. This also has the effect of allowing an ITR to avoid having to decide whether to encapsulate packets or not -- it can always encapsulate packets. An ITR would encapsulate packets destined for LISP sites (no change here), and these would be routed directly to the corespondent site's ETR. All other packets (those destined to non-LISP sites) will be sent to the originating site's Proxy-ETR.
代理出口隧道路由器（代理ETR）允许LISP站点在接入网络不允许LISP站点发送包含站点EID源地址的数据包的情况下向非LISP站点发送数据包。代理ETR是一种新的网元，从概念上讲，它充当发送到非LISP站点的流量的ETR。这还可以使ITR避免决定是否封装数据包——它总是可以封装数据包。ITR将封装发送给LISP站点的数据包（此处无更改），这些数据包将直接路由到共同响应站点的ETR。所有其他数据包（发送到非LISP站点的数据包）将发送到源站点的代理ETR。
There are two primary reasons why sites would want to utilize a Proxy-ETR:
站点希望使用代理ETR的主要原因有两个：
Avoiding strict Unicast Reverse Path Forwarding (uRPF) failures: Some providers' access networks require the source of the packets emitted to be within the addressing scope of the access networks (see Section 9).
避免严格的单播反向路径转发（uRPF）故障：一些提供商的接入网络要求发送的数据包的源在接入网络的寻址范围内（见第9节）。
Traversing a different IP Protocol: A LISP site may want to transmit packets to a non-LISP site where some of the intermediate network does not support the particular IP protocol desired (v4 or v6). Proxy-ETRs can allow this LISP site's data to 'hop over' this by utilizing LISP's support for mixed-protocol encapsulation.
穿越不同的IP协议：LISP站点可能希望将数据包传输到非LISP站点，其中一些中间网络不支持所需的特定IP协议（v4或v6）。通过利用LISP对混合协议封装的支持，代理ETR可以允许此LISP站点的数据“跳过”此操作。
Packets from a LISP site can reach a non-LISP site with the aid of a Proxy-ETR. An ITR is simply configured to send all non-LISP traffic, which it normally would have forwarded natively (non-encapsulated), to a Proxy-ETR. In the case where the ITR uses one or more Map-Resolvers, the ITR will encapsulate packets that match the received Negative Map-Cache to the configured Proxy-ETR(s). In the case where the ITR is connected to the mapping system directly, it would encapsulate all packets to the configured Proxy-ETR that are cache misses. Note that this outer encapsulation to the Proxy-ETR may be in an IP protocol other than the (inner) encapsulated data. Routers then use the LISP (outer) header's destination address to route the packets toward the configured Proxy-ETR.
来自LISP站点的数据包可以通过代理ETR到达非LISP站点。ITR只需配置为将所有非LISP通信发送到代理ETR，这些通信通常会以本机方式（非封装）转发。在ITR使用一个或多个Map解析器的情况下，ITR将封装将接收到的负Map缓存与配置的代理ETR匹配的数据包。在ITR直接连接到映射系统的情况下，它会将缓存未命中的所有数据包封装到配置的代理ETR。请注意，对代理ETR的这种外部封装可能采用IP协议，而不是（内部）封装的数据。路由器然后使用LISP（外部）报头的目标地址将数据包路由到配置的代理ETR。
A Proxy-ETR should verify the (inner) source EID of the packet at the time of decapsulation in order to verify that this is from a configured LISP site. This is to prevent spoofed inner sources from being encapsulated through the Proxy-ETR.
代理ETR应在解除封装时验证数据包的（内部）源EID，以验证该EID是否来自已配置的LISP站点。这是为了防止通过代理ETR封装伪造的内部源。
What follows is an example of the path a packet would take when using a Proxy-ETR. In this example, the LISP-NR (or LISP-R) site is given the EID-Prefix 192.0.2.0/24, and it is trying to reach a host at a non-LISP site with the IP prefix 198.51.100.0/24. For the purposes of this example, the destination (198.51.100.0/24) is found in the Internet's routing system.
下面是使用代理ETR时数据包将采用的路径示例。在本例中，LISP-NR（或LISP-R）站点被赋予EID前缀192.0.2.0/24，并且它正试图到达IP前缀为198.51.100.0/24的非LISP站点上的主机。在本例中，目的地（198.51.100.0/24）位于互联网的路由系统中。
A full protocol exchange example follows:
完整的协议交换示例如下：
1. The source host makes a DNS lookup for the destination and gets 198.51.100.100 (an IP address of a host in the non-LISP site) in return.
1. 源主机对目标进行DNS查找，并得到198.51.100.100（非LISP站点中主机的IP地址）。
2. The source host has a default route to the Customer Edge (CE) router and forwards the packet towards the CE.
2. 源主机具有到客户边缘（CE）路由器的默认路由，并将数据包转发到CE。
3. The CE is a LISP ITR and is configured to encapsulate traffic destined for non-LISP sites to a Proxy-ETR.
3. CE是一个LISP ITR，配置为将目的地为非LISP站点的流量封装到代理ETR。
4. The Proxy-ETR decapsulates the LISP packet and forwards the original packet to its next hop.
4. 代理ETR解除LISP数据包的封装，并将原始数据包转发到其下一跳。
5. The packet is then routed natively and directly to the destination (non-LISP) site 198.51.100.0/24.
5. 然后，数据包以本机方式直接路由到目的地（非LISP）站点198.51.100.0/24。
Note that in this example the return path is asymmetric, so return traffic will not go back through the Proxy-ETR. This means that in order to reach LISP-NR sites, non-LISP sites must still use Proxy-ITRs.
请注意，在本例中，返回路径是不对称的，因此返回流量不会通过代理ETR返回。这意味着为了到达LISP-NR站点，非LISP站点必须仍然使用代理ITR。
LISP Network Address Translation (LISP-NAT) is a limited form of NAT [RFC2993]. LISP-NAT is designed to enable the interworking of non-LISP sites and LISP-NR sites by ensuring that the LISP-NR's site addresses are always routable. LISP-NAT accomplishes this by translating a host's source address from an 'inner' (LISP-NR EID) value to an 'outer' (LISP-R) value and keeping this translation in a table that it can reference for subsequent packets.
LISP网络地址转换（LISP-NAT）是NAT的一种有限形式[RFC2993]。LISP-NAT旨在确保LISP-NR的站点地址始终可路由，从而实现非LISP站点和LISP-NR站点之间的互通。LISP-NAT通过将主机的源地址从“内部”（LISP-NR EID）值转换为“外部”（LISP-R）值并将此转换保存在表中以供后续数据包参考来实现这一点。
In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to talk to both LISP and non-LISP sites.
此外，现有RFC1918[RFC1918]站点可以使用LISP-NAT与LISP和非LISP站点进行对话。
The basic concept of LISP-NAT is that when transmitting a packet, the ITR replaces a non-routable EID source address with a routable source address, which enables packets to return to the site. Note that this section is intended as a rough overview of what could be done and is not an exhaustive guide to IPv4 NAT.
LISP-NAT的基本概念是，在传输数据包时，ITR将不可路由的EID源地址替换为可路由的源地址，从而使数据包能够返回到站点。请注意，本节旨在粗略概述可以做什么，而不是IPv4 NAT的详尽指南。
There are two main cases that involve LISP-NAT:
有两种主要情况涉及LISP-NAT：
1. Hosts at LISP sites that use non-routable global EIDs speaking to non-LISP sites using global addresses.
1. LISP站点上使用不可路由全局EID的主机使用全局地址与非LISP站点对话。
2. Hosts at LISP sites that use RFC 1918 private EIDs speaking to other sites, who may be either LISP or non-LISP sites.
2. LISP站点上使用RFC 1918专用EID与其他站点（可能是LISP站点或非LISP站点）对话的主机。
Note that LISP-NAT is not needed in the case of LISP-R (routable global EIDs) sources. This case occurs when a site is announcing its prefix into both the LISP mapping system and the Internet DFZ. This is because the LISP-R source's address is routable, and return packets will be able to natively reach the site.
请注意，对于LISP-R（可路由全局EIDs）源，不需要LISP-NAT。当站点在LISP映射系统和Internet DFZ中同时宣布其前缀时，就会发生这种情况。这是因为LISP-R源的地址是可路由的，返回的数据包将能够以本机方式到达站点。
LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP hosts by translating the LISP-NR EID to a globally unique address (a LISP-R EID). This globally unique address may be either a PI or PA address.
LISP-NAT允许具有LISP-NR EID的主机通过将LISP-NR EID转换为全局唯一地址（LISP-R EID）向非LISP主机发送数据包。此全局唯一地址可以是PI或PA地址。
An example of this translation follows. For this example, a site has been assigned a LISP-NR EID of 203.0.113.0/24. In order to utilize LISP-NAT, the site has also been provided the PA EID 192.0.2.0/24 and uses the first address (192.0.2.1) as the site's RLOC. The rest of this PA space (192.0.2.2 to 192.0.2.254) is used as a translation pool for this site's hosts who need to send packets to non-LISP hosts.
下面是这种翻译的一个例子。对于本例，已为站点分配了203.0.113.0/24的LISP-NR EID。为了利用LISP-NAT，站点还提供了PA EID 192.0.2.0/24，并使用第一个地址（192.0.2.1）作为站点的RLOC。此PA空间的其余部分（192.0.2.2到192.0.2.254）用作需要向非LISP主机发送数据包的此站点主机的翻译池。
The translation table might look like the following:
翻译表可能如下所示：
Site NR-EID Site R-EID Site's RLOC Translation Pool
==============================================================
203.0.113.0/24 192.0.2.0/24 192.0.2.1 192.0.2.2-254
Site NR-EID Site R-EID Site's RLOC Translation Pool
==============================================================
203.0.113.0/24 192.0.2.0/24 192.0.2.1 192.0.2.2-254
Figure 2: Example Translation Table
图2：示例转换表
The host 203.0.113.2 sends a packet (which, for the purposes of this example, is destined for a non-LISP site) to its default route (the ITR). The ITR receives the packet and determines that the destination is not a LISP site. How the ITR makes this determination is up to the ITR's implementation of the EID-to-RLOC mapping system used (see, for example, [RFC6836]).
主机203.0.113.2向其默认路由（ITR）发送数据包（在本例中，该数据包的目的地为非LISP站点）。ITR接收数据包并确定目的地不是LISP站点。ITR如何做出这一决定取决于ITR对所用EID到RLOC映射系统的实施（例如，参见[RFC6836]）。
The ITR then rewrites the source address of the packet from 203.0.113.2 to 192.0.2.2, which is the first available address in the LISP-R EID space available to it. The ITR keeps this translation in a table in order to reverse this process when receiving packets destined to 192.0.2.2.
然后，ITR将数据包的源地址从203.0.113.2重写为192.0.2.2，这是LISP-R EID空间中第一个可用的地址。ITR将此转换保存在一个表中，以便在接收发送到192.0.2.2的数据包时反转此过程。
Finally, when the ITR forwards this packet without encapsulating it, it uses the entry in its LISP-NAT table to translate the returning packets' destination IPs to the proper host.
最后，当ITR转发此数据包而不封装它时，它使用其LISP-NAT表中的条目将返回数据包的目标IP转换到适当的主机。
7.2. LISP Sites with Hosts Using RFC 1918 Addresses Sending to Non-LISP Sites
7.2. 主机使用RFC 1918地址的LISP站点发送到非LISP站点
In the case where hosts using RFC 1918 addresses desire to send packets to non-LISP hosts, the LISP-NAT implementation acts much like an existing IPv4 NAT device that is doing address translation only (not port translation). The ITR providing the NAT service must use LISP-R EIDs for its global address pool and also provide all the standard NAT functions required today.
在使用RFC 1918地址的主机希望向非LISP主机发送数据包的情况下，LISP-NAT实现的作用非常类似于只进行地址转换（而不是端口转换）的现有IPv4 NAT设备。提供NAT服务的ITR必须为其全局地址池使用LISP-R EIDs，并提供目前所需的所有标准NAT功能。
Note that the RFC 1918 addresses above are private addresses and not EIDs, and that these RFC 1918 addresses are not found in the LISP mapping system.
请注意，上面的RFC1918地址是专用地址，而不是EID，并且在LISP映射系统中找不到这些RFC1918地址。
The source of the packet must be translated to a LISP-R EID in a manner similar to that discussed in Section 7, and this packet must be forwarded to the ITR's next hop for the destination, without LISP encapsulation.
数据包的源必须以类似于第7节中讨论的方式转换为LISP-R EID，并且该数据包必须转发到ITR的下一个目的地跃点，而无需LISP封装。
7.3. LISP Sites with Hosts Using RFC 1918 Addresses Sending Packets to Other LISP Sites
7.3. 主机使用RFC1918地址将数据包发送到其他LISP站点的LISP站点
LISP-NAT allows a host with an RFC 1918 address to send packets to LISP hosts by translating the RFC 1918 address to a LISP EID. After translation, the communication between the source and destination ITR and ETRs continues as described in [RFC6830].
LISP-NAT允许具有RFC 1918地址的主机通过将RFC 1918地址转换为LISP EID向LISP主机发送数据包。翻译后，源和目标ITR与ETR之间的通信继续进行，如[RFC6830]所述。
While the communication of LISP EIDs to LISP EIDs is, strictly speaking, outside the scope of interworking, it is included here in order to complete the conceptual framework of LISP-NAT.
虽然严格来说，LISP EID与LISP EID之间的通信不在互通范围内，但为了完成LISP-NAT的概念框架，本文将其包括在内。
An example of this translation and encapsulation follows. For this example, a host has been assigned an RFC 1918 address of 192.168.1.2. In order to utilize LISP-NAT, the site also has been provided the LISP-R EID-Prefix 192.0.2.0/24 and uses the first address (192.0.2.1) as the site's RLOC. The rest of this PA space (192.0.2.2 to 192.0.2.254) is used as a translation pool for this site's hosts who need to send packets to both non-LISP and LISP hosts.
下面是这种转换和封装的示例。对于本例，已为主机分配了192.168.1.2的RFC 1918地址。为了利用LISP-NAT，站点还提供了LISP-R EID前缀192.0.2.0/24，并使用第一个地址（192.0.2.1）作为站点的RLOC。此PA空间的其余部分（192.0.2.2至192.0.2.254）用作此站点主机的翻译池，这些主机需要向非LISP主机和LISP主机发送数据包。
The host 192.168.1.2 sends a packet destined for a non-LISP site to its default route (the ITR). The ITR receives the packet and determines that the destination is a LISP site. How the ITR makes this determination is up to the ITR's implementation of the EID-to-RLOC mapping system.
主机192.168.1.2将目的地为非LISP站点的数据包发送到其默认路由（ITR）。ITR接收数据包并确定目的地是LISP站点。ITR如何做出这一决定取决于ITR实施EID到RLOC映射系统。
The ITR then rewrites the source address of the packet from 192.168.1.2 to 192.0.2.2, which is the first available address in the LISP EID space available to it. The ITR keeps this translation in a table in order to reverse this process when receiving packets destined to 192.0.2.2.
然后，ITR将数据包的源地址从192.168.1.2重写为192.0.2.2，这是LISP EID空间中第一个可用的地址。ITR将此转换保存在一个表中，以便在接收发送到192.0.2.2的数据包时反转此过程。
The ITR then LISP-encapsulates this packet (see [RFC6830] for details). The ITR uses the site's RLOC as the LISP outer header's source and the translation address as the LISP inner header's source. Once it decapsulates returning traffic, it uses the entry in its LISP-NAT table to translate the returning packet's destination IP address and then forwards it to the proper host.
然后，ITR LISP封装该数据包（有关详细信息，请参见[RFC6830]）。ITR使用站点的RLOC作为LISP外部标头的源，使用翻译地址作为LISP内部标头的源。一旦解除对返回流量的封装，它将使用其LISP-NAT表中的条目转换返回数据包的目标IP地址，然后将其转发到适当的主机。
With LISP-NAT, there are two EIDs possible for a given host: the LISP-R EID and the LISP-NR EID. When a site has two addresses that a host might use for global reachability, name-to-address directories may need to be modified.
对于LISP-NAT，给定主机可能有两个EID：LISP-R EID和LISP-NR EID。当一个站点有两个主机可能用于全局可达性的地址时，可能需要修改从名称到地址的目录。
This problem -- global vs. local addressability -- exists for NAT in general, but the specific issue described above is unique to location/identity separation schemes. Some of these have suggested running a separate DNS instance for new types of EIDs. This solves the problem but introduces complexity for the site. Alternatively, using Proxy-ITRs can mitigate this problem, because the LISP-NR EID can be reached in all cases.
一般来说，NAT存在全局寻址能力与本地寻址能力的问题，但上述具体问题是位置/身份分离方案所特有的。其中一些建议为新类型的EID运行单独的DNS实例。这解决了问题，但为站点带来了复杂性。或者，使用代理ITR可以缓解此问题，因为在所有情况下都可以达到LISP-NR EID。
In summary, there are three suggested mechanisms for interworking LISP with non-LISP sites (for both IPv4 and IPv6). In the LISP-NAT option, the LISP site can manage and control the interworking on its own. In the Proxy-ITR case, the site is not required to manage the
总之，有三种建议的机制可用于将LISP与非LISP站点（IPv4和IPv6）进行交互。在LISP-NAT选项中，LISP站点可以自行管理和控制互通。在代理ITR的情况下，站点不需要管理
advertisement of its EID-Prefix into the DFZ, with the cost of potentially adding stretch to the connections of non-LISP sites sending packets to the LISP site. The third option is Proxy-ETRs, which are optionally used by sites relying on Proxy-ITRs to mitigate two caveats for LISP sites sending packets to non-LISP sites. This means Proxy-ETRs are not usually expected to be deployed by themselves; rather, they will be used to assist LISP-NR sites that are already using Proxy-ITRs.
将其EID前缀播发到DFZ中，其代价可能是向向LISP站点发送数据包的非LISP站点的连接增加拉伸。第三个选项是代理ETR，依赖代理ITR的站点可以选择使用代理ETR来缓解LISP站点向非LISP站点发送数据包时的两个警告。这意味着代理ETR通常不会自行部署；相反，它们将用于帮助已经使用代理ITR的LISP-NR站点。
There is a subtle difference between symmetrical (LISP-NAT) and asymmetrical (Proxy-ITR and Proxy-ETR) interworking techniques. Operationally, Proxy-ITRs and Proxy-ETRs can (and likely should) be decoupled, since Proxy-ITRs are best deployed closest to non-LISP sites and Proxy-ETRs are best located close to the LISP sites they are decapsulating for. This asymmetric placement of the two network elements minimizes the stretch imposed on each direction of the packet flow while still allowing for coarsely aggregated announcements of EIDs into the Internet's routing table.
对称（LISP-NAT）和非对称（代理ITR和代理ETR）互通技术之间存在细微差别。在操作上，代理ITR和代理ETR可以（也可能应该）解耦，因为代理ITR最好部署在最靠近非LISP站点的位置，代理ETR最好位于其解封的LISP站点附近。这两个网络元素的不对称放置最小化了对分组流的每个方向施加的拉伸，同时仍然允许将EID粗略地聚合到Internet的路由表中。
Like any router or LISP ITR, Proxy-ITRs will have the opportunity to inspect traffic at the time that they encapsulate. The location of these devices in the network can have implications for discarding malicious traffic on behalf of ETRs that request this behavior (by setting the ACT (action) bit in Map-Reply packets [RFC6830] to "Drop" for an EID or EID-Prefix). This is an area that would benefit from further experimentation and analysis.
与任何路由器或LISP ITR一样，代理ITR将有机会在封装时检查流量。这些设备在网络中的位置可能会影响代表请求此行为的ETR丢弃恶意流量（通过将映射应答包[RFC6830]中的ACT（操作）位设置为EID或EID前缀的“Drop”）。这一领域将受益于进一步的实验和分析。
LISP interworking via Proxy-ITRs should have no impact on the existing network beyond what LISP ITRs and ETRs introduce when multihoming. That is, if a site multihomes today (with LISP or BGP), there is a possibility of asymmetric flows.
通过代理ITR的LISP互通对现有网络的影响不应超过LISP ITR和ETR在多宿时引入的影响。也就是说，如果一个站点现在有多个家庭（使用LISP或BGP），则可能存在不对称流量。
Proxy-ITRs and Proxy-ETRs will likely be operated by organizations other than those of the end site receiving or sending traffic. Care should be taken, then, in selecting a Proxy-ITR/Proxy-ETR provider to insure that the quality of service meets the site's expectations.
代理ITR和代理ETR可能由接收或发送流量的终端站点以外的组织运营。因此，在选择代理ITR/代理ETR提供商时应小心，以确保服务质量满足站点的期望。
Proxy-ITRs and Proxy-ETRs share many of the same security issues as those discussed for ITRs and ETRs. For further information, see the security considerations section of [RFC6830].
代理ITR和代理ETR与讨论的ITR和ETR有许多相同的安全问题。有关更多信息，请参阅[RFC6830]的安全注意事项部分。
As with traditional NAT, LISP-NAT will obscure the actual host LISP-NR EID behind the LISP-R addresses used as the NAT pool.
与传统NAT一样，LISP-NAT将掩盖用作NAT池的LISP-R地址后面的实际主机LISP-NR EID。
When LISP sites send packets to non-LISP sites (these non-LISP sites rely on Proxy-ITRs to enable interworking), packets will have the site's EID as the source IP address. These EIDs may not be recognized by their ISP's Unicast Reverse Path Forwarding (uRPF) rules enabled on the Provider Edge router. Several options are available to the service provider. For example, they could enable a less strict version of uRPF, where they only look for the existence of the EID-Prefix in the routing table. Another option, which is more secure, is to add a static route for the customer on the PE router but not redistribute this route into the provider's routing table. Finally, Proxy-ETRs can enable LISP sites to bypass this uRPF check by encapsulating all of their egress traffic destined to non-LISP sites to the Proxy-ETR (thus ensuring that the outer IP source address is the site's RLOC).
当LISP站点向非LISP站点发送数据包时（这些非LISP站点依赖代理ITR来启用互通），数据包将以站点的EID作为源IP地址。供应商边缘路由器上启用的ISP单播反向路径转发（uRPF）规则可能无法识别这些EID。服务提供商可以使用多个选项。例如，它们可以启用uRPF的一个不太严格的版本，其中它们只查找路由表中是否存在EID前缀。另一个更安全的选择是在PE路由器上为客户添加静态路由，但不将此路由重新分发到提供商的路由表中。最后，代理ETR可以通过将发送到非LISP站点的所有出口流量封装到代理ETR（从而确保外部IP源地址是站点的RLOC），使LISP站点绕过此uRPF检查。
Thanks go to Christian Vogt, Lixia Zhang, Robin Whittle, Michael Menth, Xuewei Wang, and Noel Chiappa, who have made insightful comments with respect to LISP interworking and transition mechanisms.
感谢Christian Vogt、Lixia Zhang、Robin Whittle、Michael Meth、Xuewei Wang和Noel Chiapa，他们就LISP互通和转换机制发表了深刻的评论。
A special thanks goes to Scott Brim for his initial brainstorming of these ideas and also for his careful review.
特别感谢Scott Brim对这些想法的初步头脑风暴，以及他对这些想法的仔细审查。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.
[RFC6830]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（LISP）”，RFC 6830，2013年1月。
[RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC6836]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/ID分离协议替代逻辑拓扑（LISP+ALT）”，RFC 68362013年1月。
[CRIO] Zhang, X., Francis, P., Wang, J., and K. Yoshida, "CRIO: Scaling IP Routing with the Core Router-Integrated Overlay", November 2006.
[CRIO]Zhang，X.，Francis，P.，Wang，J.，和K.Yoshida，“CRIO：利用核心路由器集成覆盖扩展IP路由”，2006年11月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]Hain，T.，“NAT的建筑含义”，RFC 29932000年11月。
Authors' Addresses
作者地址
Darrel Lewis Cisco Systems
达雷尔·刘易斯思科系统公司
EMail: darlewis@cisco.com
EMail: darlewis@cisco.com
David Meyer Cisco Systems
大卫梅耶思科系统公司
EMail: dmm@1-4-5.net
EMail: dmm@1-4-5.net
Dino Farinacci Cisco Systems
迪诺·法里纳奇思科系统公司
EMail: farinacci@gmail.com
EMail: farinacci@gmail.com
Vince Fuller
文斯·富勒
EMail: vaf@vaf.net
EMail: vaf@vaf.net