[要約] RFC 6832は、Locator/ID Separation Protocol（LISP）と非LISPサイト間の相互運用性に関するものです。このRFCの目的は、LISPと非LISPサイト間の通信を可能にするためのガイドラインを提供することです。
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.
このドキュメントでは、Locator / ID Separation Protocol（LISP）を実行しているサイトが、IPv4、IPv6、またはその両方を使用している可能性があるがLISPを実行していないインターネットサイトと相互運用できるようにする手法について説明します。 LISPスピーキングサイトの基本的な特性は、発信または受信するすべてのトラフィックの送信元フィールドと宛先フィールドで、従来のIPアドレスではなくエンドポイント識別子（EID）を使用することです。 EIDは構文的にIPv4またはIPv6アドレスと同じですが、通常、それらへのルートはグローバルルーティングシステムでは伝送されないため、LISP非対応サイトがLISP対応サイトとトラフィックを交換するための相互運用性メカニズムが必要です。このドキュメントでは、そのような3つのメカニズムを紹介します。 1つ目は、新しいネットワーク要素であるLISPプロキシ入力トンネルルーター（Proxy-ITR）を使用して、LISP非対応ホストの中間LISP入力トンネルルーター（ITR）として機能します。次に、このドキュメントでは、ネットワークアドレス変換（NAT）機能をLISP ITRおよびLISP出力トンネルルーター（ETR）に追加して、ルーティング不可能なEIDをルーティング可能なIPアドレスに置き換えます。最後に、このドキュメントでは、LISP ITRがカプセル化なしで非LISPサイトにパケットを送信できない場合を処理するためのプロキシ出力トンネルルーター（Proxy-ETR）を紹介します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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プレフィックスがインターネットのデフォルトフリーゾーン（DFZ）にアドバタイズされないことです。 （例外のケースについては、セクション4を参照してください。）具体的には、ルーティングロケーター（RLOC）のみがインターネットのDFZで運ばれます。 LISPを実行していない既存のインターネットサイト（およびそのホスト）は、LISP EIDスペースから番号が付けられたサイトに到達できる必要があります。このドキュメントでは、LISP対応のサイトとそうでないサイトの間で到達可能性を提供するために使用できる3つのメカニズムについて説明します。
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プロキシ入力トンネルルーター（Proxy-ITR）を使用して、LISP非対応ホストの中間LISP入力トンネルルーター（ITR）として機能します。 2番目のメカニズムは、トンネルルーター（xTR、「xTR」はITRまたはETRのいずれかを指します）にネットワークアドレス変換（NAT）機能の形式を追加して、ルーティング不可能なEIDをルーティング可能なIPアドレスに置き換えます。最後のネットワーク要素はLISPプロキシ出力トンネルルーター（Proxy-ETR）であり、非LISPサイト宛てのLISPパケットをカプセル化する必要があるLISPサイトの中間出力トンネルルーター（ETR）として機能します。
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プレフィックススペースと現在のインターネットで使用されているIPアドレススペースの関係について説明します。
- Section 5 introduces and describes the operation of Proxy-ITRs.
- セクション5では、Proxy-ITRの動作を紹介し、説明します。
- Section 6 introduces and describes the operation of Proxy-ETRs.
- セクション6では、Proxy-ETRの動作を紹介し、説明します。
- Section 7 defines how NAT is used by ETRs to translate non-routable EIDs into routable IP addresses.
- セクション7では、ルーティング不可能なEIDをルーティング可能なIPアドレスに変換するために、ETRがNATを使用する方法を定義しています。
- 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）は、パケットを任意の宛先にルーティングするためにデフォルトルートを必要としない、すべてのインターネット自律システムのコレクションを指します。
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サイト。これらの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プロキシ入力トンネルルーター（Proxy-ITR）：Proxy-ITRは、LISP EIDを使用するサイトと使用しないサイト間の接続を提供するために使用されます。これらは、LISP（レガシーインターネット）を使用していないインターネットの部分間のゲートウェイとして機能します。特定のProxy-ITRは、1つ以上の高度に集約されたEIDプレフィックスを公衆インターネットにアドバタイズし、公衆インターネットから受信したトラフィックのITRとして機能します。 LISPプロキシITRについては、セクション5で説明します。
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スペース間のネットワークアドレス変換。 LISP-NATについては、セクション7で説明します。
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プロキシ出力トンネルルーター（Proxy-ETR）：Proxy-ETRは、カプセル化されていないパケット（デフォルトのメカニズム）が失敗した場合に、LISP（ルーティング可能またはルーティング不可能なEID）サイトのITRに非LISPサイトにパケットを送信する機能を提供します配信されます。 Proxy-ETRは、ITRがすべての非LISP宛てのトラフィックを事前設定されたProxy-ETRにカプセル化することによって機能します。 LISPプロキシETRについては、セクション6で説明します。
EID Sub-Namespace: A power-of-two block of aggregatable Locators set aside for LISP interworking.
EIDサブネームスペース：LISPインターワーキング用に確保された、集約可能なロケーターの2のべき乗ブロック。
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].
その他の用語の定義については、特にMap-Request、Map-Reply、Ingress Tunnel Router（ITR）、およびEgress Tunnel Router（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.
最初のケースはインターネットであり、今日私たちが知っているため、ここではこれ以上説明しません。 2番目のケースは[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カプセル化しない場合を知ることです。 ITRは、IPパケットの宛先IPアドレスが「Natively-Forward」アクションを持つ（負の）Map-Cacheエントリと一致する場合、宛先が非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.
LISP以外のサイトのホストがLISPサイトのホストにトラフィックを送信しようとすると、通常、最も困難なケース4が発生します。送信元ホストが（グローバルにルーティングできない）EIDを宛先IPアドレスとして使用している場合、パケットは、（デフォルトルートがないため）転送できないルーターに到達するまで、送信元サイト内で転送されます。トラフィックはドロップされます。トラフィックがドロップされないようにするには、この宛先EIDをルーティング可能にするためのメカニズムが必要です。セクション5（プロキシITR）およびセクション7（LISP-NAT）では、このような2つのメカニズムについて説明します。ケース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の主要な目標の1つを無効にするため、サイトでこれを行うことは望ましくありません。
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にアナウンスされる場合、これらのEIDプレフィックスは既存のPIアドレスよりも集約できないため、LISPが展開されていない場合と同様の影響があります。このようなメカニズムは、実行可能な長期的なソリューションとは見なされませんが、サイトが既存のルーティングポリシーを変更せずにアドレススペースの一部を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を発表することの影響を制限するために、2つのスキームが提案されています。
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対応および非LISP対応のサイトをブリッジするITR機能を提供するアプローチである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がインターネットルーティングインフラストラクチャに与える影響を制限します。
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 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（およびその他のロケーター/ ID分離の提案）の主な設計目標は、パスの計算に使用される名前空間のトポロジ的な集約を促進し、グローバルルーティングシステムのオーバーヘッドを減らすことです。もう1つの目標は、改善された集計の利点をできるだけ早く達成することです。したがって、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として使用できます。つまり、このようなサイトでは、追加のプレフィックスがアドバタイズされることはありません。このようなサイトの場合、「PA」（プロバイダー割り当て）EIDはすでにルーティング可能であるため、非LISPサイトへの接続にインターワーキングマシンは必要ありません（これらは事実上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）プレフィックスの継続的な発表は、もちろんそのサイトの管理下にあります。サイトがLISPマッピングシステムとインターネットルーティングシステムの個別のプレフィックスの両方で見つかる移行の期間は、実行可能な移行戦略となる場合があります。より具体的なLISP EIDプレフィックスをDFZにアドバタイズしないように注意する必要があります。
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:
プロキシ入力トンネルルーター（Proxy-ITR）を使用すると、LISP以外のサイトがLISP-NRサイトにパケットを送信できます。プロキシITRは、LISP ITRと多くの特性を共有する新しいネットワーク要素です。プロキシITRを使用すると、非LISPサイトでプロトコルや機器を変更することなく、非LISPサイトがLISP-NRサイトにパケットを送信できます。プロキシITRには2つの主要な機能があります。
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アドバタイズメント：Proxy-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.
レガシーインターネットトラフィックのカプセル化：Proxy-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 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.
Proxy-ITR機能の重要な部分は、高度に集約されたEIDプレフィックスのルートをグローバルルーティングシステムの一部にアドバタイズすることです。新しいアナウンスされたルートの数を最小限に抑えるために、アグレッシブアグリゲーションが実行されます。さらに、Proxy-ITRを注意深く配置すると、これらの新しいルートのアドバタイズされるスコープを大幅に削減できます。このため、Proxy-ITRは、LISPサイトの近くではなく、LISP非対応サイトの近くに配置する必要があります。このような展開により、EIDプレフィックスルートアドバタイズメントの範囲が制限されるだけでなく、トラフィック転送の負荷を多くのProxy-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:
以下は、Proxy-ITRを使用する場合のパケットのパスの例です。この例では、LISP-NRサイトにはEIDプレフィックス192.0.2.0/24が付与されています。この例では、このプレフィックスもカバーする集約もグローバルルーティングシステムには存在しません。つまり、Proxy-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|
+----+
Figure 1: Example of Proxy-ITR Packet Flow
図1：Proxy-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へのルートがあり、ネクストホップはProxy-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. Proxy-ITRは192.0.2.1のマッピングを取得または取得し、LISPでパケットをカプセル化します。外部IPヘッダーに、宛先EIDのRLOCのいずれかの宛先アドレスが含まれるようになりました。このカプセル化されたパケットの外部送信元アドレスは、Proxy-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. Proxy-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).
この例では、戻りパスが非対称であるため、戻りトラフィックはProxy-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.
トラフィックフローの非対称性により、Proxy-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スピーキンググローバルルーティングシステムの一部にアナウンスすることにより、トラフィックを引き付けます。トラフィックが特定のProxy-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. Proxy-ITRの集約ルートは選択的にアナウンスされ、そのProxy-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. IP Anycastを使用してトラフィックを共有するために、同じアドレスが複数のProxy-ITRによってアナウンスされる場合があります。 Proxy-ITRを介したトラフィックフローの非対称性は、運用上、一連のProxy-ITRをデプロイすることが、DNSキャッシュなどの既存のエニーキャストサービスと非常に似ていることを意味します。複数のProxy-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).
ネットワークがProxy-ITRを配置する際に使用できるアプローチはいくつかあります。トラフィックの送信元の近くにProxy-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).
いくつかの提案、たとえばCore Router-Integrated Overlay [CRIO]は、ETRの任意のサブセットの近くにProxy-ITRをグループ化し、EIDスペースの「ローカル」サブセットを発表することを提案しています。 EIDプレフィックスルートアドバタイズメントポイントが変更された場合、このモデルは最小ストレッチを保証できません（そのような変更は、サイトが1つ以上の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 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.
LISP-NRサイト宛のパケットが到着し、Proxy-ITRでカプセル化されると、新しいLISPパケットヘッダーが付加されます。これにより、パケットの宛先が宛先ETRのRLOCに設定されます。パケットはこのようにRLOCにルーティングされるため、Proxy-ITRネットワークのトラフィックエンジニアリングポリシー（最も近い出口ルーティングなど）に準拠する可能性があります。これはまた、デフォルトフリーではなく、Proxy-ITRを展開しないプロバイダーは、ETRのRLOCアドレスではなく、高価なトランジットリンク（それらのアップストリームがProxy-ITRを展開していると想定）により多くのトラフィックを送信することになります。より安価でより近い接続性を持っている（たとえば、和解のないピアリングを介して）。これの当然の結果は、Proxy-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.
プロキシ出口トンネルルーター（Proxy-ETR）を使用すると、LISPサイトがLISPサイトがサイトのEIDの送信元アドレスでパケットを送信できない場合に、LISPサイトが非LISPサイトにパケットを送信できます。プロキシETRは、概念的には非LISPサイト宛てのトラフィックのETRとして機能する新しいネットワーク要素です。これには、ITRがパケットをカプセル化するかどうかを決定する必要がないようにする効果もあります。パケットを常にカプセル化できます。 ITRはLISPサイト宛てのパケットをカプセル化し（ここでは変更なし）、これらはコア対応サイトのETRに直接ルーティングされます。その他のすべてのパケット（LISP以外のサイト宛てのパケット）は、発信元サイトのProxy-ETRに送信されます。
There are two primary reasons why sites would want to utilize a Proxy-ETR:
サイトがProxy-ETRを利用する主な理由は2つあります。
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サイトは、中間ネットワークの一部が特定のIPプロトコル（v4またはv6）をサポートしていない非LISPサイトにパケットを送信する場合があります。プロキシETRは、LISPの混合プロトコルカプセル化のサポートを利用することにより、この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サイトからのパケットは、Proxy-ETRを使用して非LISPサイトに到達できます。 ITRは、通常はネイティブに（カプセル化されずに）転送されるすべての非LISPトラフィックをProxy-ETRに送信するように構成されているだけです。 ITRが1つ以上のMap-Resolverを使用する場合、ITRは、受信したNegative Map-Cacheを構成済みのProxy-ETRに一致させるパケットをカプセル化します。 ITRがマッピングシステムに直接接続されている場合、キャッシュミスである構成済みのProxy-ETRへのすべてのパケットがカプセル化されます。 Proxy-ETRへのこの外部カプセル化は、（内部）カプセル化されたデータ以外のIPプロトコルにある場合があることに注意してください。次に、ルーターはLISP（外部）ヘッダーの宛先アドレスを使用して、構成されたProxy-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を検証して、これが構成済みのLISPサイトからのものであることを確認する必要があります。これは、スプーフィングされた内部ソースがProxy-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.
以下は、Proxy-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サイト宛のトラフィックをProxy-ETRにカプセル化するように設定されています。
4. The Proxy-ETR decapsulates the LISP packet and forwards the original packet to its next hop.
4. Proxy-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.
この例では、戻りパスは非対称であるため、戻りトラフィックはProxy-ETRを経由しないことに注意してください。つまり、LISP-NRサイトに到達するためには、非LISPサイトは引き続きProxy-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.
さらに、既存のRFC 1918 [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が関係する主なケースは2つあります。
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サイトまたは非LISPサイトのいずれかである可能性がある他のサイトと通信するRFC 1918プライベートEIDを使用する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（ルーティング可能なグローバルEID）ソースの場合、LISP-NATは必要ないことに注意してください。このケースは、サイトがそのプレフィックスをLISPマッピングシステムとインターネット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
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はパケット（この例では、非LISPサイト宛て）をデフォルトルート（ITR）に送信します。 ITRはパケットを受信し、宛先がLISPサイトではないと判断します。 ITRがこの決定を行う方法は、使用されるEIDからRLOCへのマッピングシステムのITRの実装次第です（たとえば、[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スペースで最初に使用可能なアドレスです。 192.0.2.2宛てのパケットを受信したときにこのプロセスを逆にするために、ITRはこの変換をテーブルに保持します。
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がカプセル化せずにこのパケットを転送する場合、ITRはLISP-NATテーブルのエントリを使用して、返されたパケットの宛先IPを適切なホストに変換します。
7.2. LISP Sites with Hosts Using RFC 1918 Addresses Sending to Non-LISP Sites
7.2. 非LISPサイトに送信するRFC 1918アドレスを使用するホストを持つ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 EIDを使用する必要があり、現在必要なすべての標準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.
上記のRFC 1918アドレスはEIDではなくプライベートアドレスであり、これらのRFC 1918アドレスはLISPマッピングシステムにはないことに注意してください。
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に変換する必要があり、このパケットは、LISPカプセル化なしで、宛先のITRのネクストホップに転送する必要があります。
7.3. LISP Sites with Hosts Using RFC 1918 Addresses Sending Packets to Other LISP Sites
7.3. RFC 1918アドレスを使用するホストを持つ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ホストにパケットを送信できます。変換後、[RFC6830]で説明されているように、送信元と宛先のITRおよびETR間の通信が続行されます。
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-Prefix 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スペースで最初に使用可能なアドレスです。 192.0.2.2宛てのパケットを受信したときにこのプロセスを逆にするために、ITRはこの変換をテーブルに保持します。
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では、特定のホストに対して2つのEIDが可能です。LISP-REIDとLISP-NR EIDです。ホストがグローバルな到達可能性のために使用する可能性がある2つのアドレスがサイトにある場合、名前からアドレスへのディレクトリの変更が必要になる場合があります。
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に存在しますが、上記の特定の問題は場所/ ID分離スキームに固有のものです。これらのいくつかは、新しいタイプのEIDに対して個別のDNSインスタンスを実行することを提案しています。これで問題は解決しますが、サイトが複雑になります。または、すべてのケースでLISP-NR EIDに到達できるため、Proxy-ITRを使用するとこの問題を軽減できます。
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 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.
要約すると、LISP以外のサイトとLISPをインターワーキングするための推奨メカニズムが3つあります（IPv4とIPv6の両方）。 LISP-NATオプションでは、LISPサイトは独自にインターワーキングを管理および制御できます。 Proxy-ITRの場合、サイトはEZプレフィックスのDFZへのアドバタイズを管理する必要がなく、LISPサイトにパケットを送信する非LISPサイトの接続に潜在的にストレッチを追加するコストがかかります。 3番目のオプションはProxy-ETRです。これは、オプションで、Proxy-ITRに依存するサイトが、LISP以外のサイトにパケットを送信するLISPサイトの2つの警告を軽減するために使用します。つまり、Proxy-ETRは通常、それ自体で展開されることは想定されていません。むしろ、それらはすでにProxy-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）と非対称型（Proxy-ITRおよびProxy-ETR）のインターワーキング技術には微妙な違いがあります。運用上、Proxy-ITRとProxy-ETRは切り離すことができます（おそらく分離する必要があります）。これは、Proxy-ITRは非LISPサイトに最も近い場所に配置するのが最適であり、Proxy-ETRはカプセル化を解除するLISPサイトの近くに配置するのが最適です。この2つのネットワーク要素の非対称配置により、パケットフローの各方向に課されるストレッチが最小限に抑えられ、EIDの粗く集約されたアナウンスがインターネットのルーティングテーブルに送られます。
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に代わって悪意のあるトラフィックを破棄することに影響を与える可能性があります（EIDまたはEIDのMap-Replyパケット[RFC6830]のACT（アクション）ビットを "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.
Proxy-ITRおよびProxy-ETRは、トラフィックを送受信するエンドサイトの組織以外の組織によって運用される可能性があります。サービスの品質がサイトの期待に応えることを保証するために、Proxy-ITR / Proxy-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].
Proxy-ITRおよびProxy-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サイトは、インターワーキングを有効にするためにProxy-ITRに依存しています）、パケットには送信元IPアドレスとしてサイトのEIDが含まれます。これらのEIDは、プロバイダーエッジルーターで有効になっているISPのユニキャストリバースパス転送（uRPF）ルールによって認識されない場合があります。サービスプロバイダーはいくつかのオプションを利用できます。たとえば、より厳密ではないバージョンのuRPFを有効にし、ルーティングテーブルでEIDプレフィックスの存在のみを探すことができます。より安全な別のオプションは、PEルーターに顧客の静的ルートを追加することですが、このルートをプロバイダーのルーティングテーブルに再配布しません。最後に、Proxy-ETRは、非LISPサイト宛てのすべての出力トラフィックをProxy-ETRにカプセル化することで、LISPサイトがこのuRPFチェックをバイパスできるようにします（これにより、外部IP送信元アドレスがサイトのRLOCであることを確認します）。
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.
LISPのインターワーキングと移行のメカニズムに関して洞察に満ちたコメントを寄せてくれたChristian Vogt、Lixia Zhang、Robin Whittle、Michael Menth、Xuewei Wang、Noel Chiappaに感謝します。
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] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol（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] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol Alternative Logical Topology（LISP + ALT）」、RFC 6836、2013年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：Scaling IP Routing with the Core Router-Integrated Overlay」、2006年11月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、T。、「NATのアーキテクチャ上の影響」、RFC 2993、2000年11月。
Authors' Addresses
著者のアドレス
Darrel Lewis Cisco Systems
ダレルルイスシスコシステムズ
EMail: darlewis@cisco.com
David Meyer Cisco Systems
David Meyer Cisco Systems
EMail: dmm@1-4-5.net
Dino Farinacci Cisco Systems
Dino Farinacci Cisco Systems
EMail: farinacci@gmail.com
Vince Fuller
ヴィンスフラー
EMail: vaf@vaf.net