[要約] RFC 6835は、Locator/ID Separation Protocol Internet Groper（LIG）に関する規格であり、LIGの目的は、LISPネットワークでのホストの位置情報と識別子の検索をサポートすることです。
Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 6835 D. Meyer
Category: Informational Cisco Systems
ISSN: 2070-1721 January 2013
The Locator/ID Separation Protocol Internet Groper (LIG)
Locator / ID Separation Protocol Internet Groper（LIG）
Abstract
概要
A simple tool called the Locator/ID Separation Protocol (LISP) Internet Groper or 'lig' can be used to query the LISP mapping database. This document describes how it works.
Locator / ID Separation Protocol（LISP）Internet Groperまたは 'lig'と呼ばれるシンプルなツールを使用して、LISPマッピングデータベースを照会できます。このドキュメントでは、その仕組みについて説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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/rfc6835.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6835で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Implementation Details . . . . . . . . . . . . . . . . . . . . 6
4.1. LISP Router Implementation . . . . . . . . . . . . . . . . 6
4.2. Public Domain Host Implementation . . . . . . . . . . . . 8
5. Testing the ALT . . . . . . . . . . . . . . . . . . . . . . . 9
6. Future Enhancements . . . . . . . . . . . . . . . . . . . . . 10
7. Deployed Network Diagnostic Tools . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12
The Locator/ID Separation Protocol [RFC6830] specifies an architecture and mechanism for replacing the addresses currently used by IP with two separate namespaces: Endpoint IDs (EIDs), used within sites, and Routing Locators (RLOCs), used on the transit networks that make up the Internet infrastructure. To achieve this separation, LISP defines protocol mechanisms for mapping from EIDs to RLOCs. In addition, LISP assumes the existence of a database to store and propagate those mappings globally. Several such databases have been proposed, among them: a Content distribution Overlay Network Service for LISP [LISP-CONS], a Not-so-novel EID-to-RLOC Database (LISP-NERD) [RFC6837], and LISP Alternative Topology (LISP+ ALT) [RFC6836], with LISP+ALT being the system that is currently being implemented and deployed on the pilot LISP network.
Locator / ID Separation Protocol [RFC6830]は、現在IPで使用されているアドレスを、サイト内で使用されるエンドポイントID（EID）と、トランジットネットワークで使用されるルーティングロケーター（RLOC）の2つの別々の名前空間に置き換えるためのアーキテクチャとメカニズムを指定していますインターネットインフラストラクチャを構成します。この分離を実現するために、LISPはEIDからRLOCにマッピングするためのプロトコルメカニズムを定義しています。さらに、LISPはデータベースの存在を前提として、これらのマッピングをグローバルに保存および伝達します。そのようなデータベースがいくつか提案されています。その中には、LISPのコンテンツ配信オーバーレイネットワークサービス[LISP-CONS]、それほど新しいEID-to-RLOCデータベース（LISP-NERD）[RFC6837]、およびLISP代替トポロジ（ LISP + ALT）[RFC6836]。LISP+ ALTは、パイロットLISPネットワークに現在実装および展開されているシステムです。
In conjunction with the various mapping systems, there exists a network-based API called LISP Map-Server [RFC6833]. Using Map-Resolvers and Map-Servers allows LISP sites to query and register into the database in a uniform way independent of the mapping system used. Sending Map-Requests to Map-Resolvers provides a secure mechanism to obtain a Map-Reply containing the authoritative EID-to-RLOC mapping for a destination LISP site.
さまざまなマッピングシステムと組み合わせて、LISP Map-Server [RFC6833]と呼ばれるネットワークベースのAPIが存在します。 Map-ResolversとMap-Serversを使用することで、LISPサイトは、使用されるマッピングシステムとは関係なく、統一された方法でデータベースにクエリおよび登録できます。 Map-ResolversへのMap-Requestsの送信は、宛先LISPサイトの信頼できるEID-to-RLOCマッピングを含むMap-Replyを取得するための安全なメカニズムを提供します。
The 'lig' is a manual management tool to query the mapping database. It can be run by all devices that implement LISP, including Ingress Tunnel Routers (ITRs), Egress Tunnel Routers (ETRs), Proxy-ITRs, Proxy-ETRs, Map-Resolvers, Map-Servers, and LISP-ALT Routers, as well as by a host system at either a LISP-capable or non-LISP-capable site.
「lig」は、マッピングデータベースを照会する手動管理ツールです。 Ingress Tunnel Router（ITRs）、Egress Tunnel Routers（ETRs）、Proxy-ITRs、Proxy-ETRs、Map-Resolvers、Map-Servers、およびLISP-ALT Routersを含む、LISPを実装するすべてのデバイスで実行できます。 LISP対応サイトまたはLISP非対応サイトのホストシステムによる。
The mapping database system is typically a public database used for wide-range connectivity across Internet sites. The information in the public database is purposely not kept private so it can be generally accessible for public use.
マッピングデータベースシステムは、通常、インターネットサイト間の広範囲の接続に使用されるパブリックデータベースです。公開データベースの情報は、意図的に非公開にされていないため、一般的に公開してアクセスできます。
Map-Server: a network infrastructure component that learns EID-to-RLOC mapping entries from an authoritative source (typically, an ETR, though static configuration or another out-of-band mechanism may be used). A Map-Server advertises these mappings in the distributed mapping database.
Map-Server：信頼できるソースからEIDからRLOCへのマッピングエントリを学習するネットワークインフラストラクチャコンポーネント（通常、静的構成または別の帯域外メカニズムが使用される場合がありますが、ETR）。 Map-Serverは、これらのマッピングを分散マッピングデータベースにアドバタイズします。
Map-Resolver: a network infrastructure component that accepts LISP Encapsulated Map-Requests, typically from an ITR, quickly determines whether or not the destination IP address is part of the EID namespace; if it is not, a Negative Map-Reply is immediately returned. Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC mapping by consulting the distributed mapping database system.
Map-Resolver：通常ITRからのLISPカプセル化Map-Requestを受け入れるネットワークインフラストラクチャコンポーネントは、宛先IPアドレスがEID名前空間の一部であるかどうかをすばやく判断します。そうでない場合、Negative Map-Replyがすぐに返されます。それ以外の場合、Map-Resolverは、分散マッピングデータベースシステムを参照して、適切なEIDからRLOCへのマッピングを見つけます。
Routing Locator (RLOC): the IPv4 or IPv6 address of an Egress Tunnel Router (ETR). It is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet. Thus, the topology is defined by the connectivity of provider networks, and RLOCs can be thought of as Provider-Assigned (PA) addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site.
ルーティングロケータ（RLOC）：出力トンネルルーター（ETR）のIPv4またはIPv6アドレス。これは、EIDからRLOCへのマッピングルックアップの出力です。 EIDは1つ以上のRLOCにマップします。通常、RLOCは、グローバルインターネットに接続する各ポイントでサイトに割り当てられているトポロジ的に集約可能なブロックから番号が付けられます。したがって、トポロジはプロバイダーネットワークの接続によって定義され、RLOCはプロバイダー割り当て（PA）アドレスと考えることができます。複数のRLOCを同じETRデバイスまたはサイトの複数のETRデバイスに割り当てることができます。
Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today, for example, through a DNS lookup. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. EIDs must not be used as LISP RLOCs. Note that EID blocks may be assigned in a hierarchical manner, independent of the network topology, to facilitate scaling of the mapping database. In addition, an EID block assigned to a site may have site-local structure (subnetting) for routing within the site; this structure is not visible to the global routing system.
エンドポイントID（EID）：パケットの最初（最も内側）のLISPヘッダーの送信元および宛先アドレスフィールドで使用される32ビット（IPv4の場合）または128ビット（IPv6の場合）の値。ホストは、たとえばDNSルックアップを介して、今日の宛先アドレスを取得するのと同じ方法で宛先EIDを取得します。ソースEIDは、ホストの「ローカル」IPアドレスを設定するために使用される既存のメカニズムを介して取得されます。 EIDは、ホストが配置されているサイトに関連付けられたEIDプレフィックスブロックからホストに割り当てられます。ホストは、EIDを使用して他のホストを参照できます。 EIDをLISP RLOCとして使用しないでください。 EIDブロックは、マッピングデータベースのスケーリングを容易にするために、ネットワークトポロジーとは無関係に階層的に割り当てることができます。さらに、サイトに割り当てられたEIDブロックには、サイト内でルーティングするためのサイトローカル構造（サブネット化）がある場合があります。この構造は、グローバルルーティングシステムからは見えません。
EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that stores, tracks, and is responsible for timing-out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID-to-RLOC mappings; the cache is dynamic, local to the ITR(s), and relatively small, while the database is distributed, relatively static, and much more global in scope.
EIDからRLOCへのキャッシュ：ITR内の存続期間が短いオンデマンドテーブル。これは、EIDからRLOCへのマッピングを保存、追跡し、タイムアウトやその他の検証を行います。このキャッシュは、EIDからRLOCへのマッピングの完全な「データベース」とは異なります。キャッシュは動的で、ITRに対してローカルで、比較的小さいですが、データベースは分散されており、比較的静的で、スコープははるかにグローバルです。
EID-to-RLOC Database: a global distributed database that contains all known EID-prefix to RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID prefixes "behind" the router. These map to one of the router's own, globally-visible, IP addresses.
EIDからRLOCへのデータベース：すべての既知のEIDプレフィックスからRLOCへのマッピングを含むグローバル分散データベース。潜在的な各ETRには、通常、データベースの小さな断片が含まれています。ルーターの「背後」にあるEIDプレフィックスのEIDからRLOCへのマッピングです。これらは、ルーター自身のグローバルに表示されるIPアドレスの1つにマッピングされます。
Encapsulated Map-Request (EMR): an EMR is a Map-Request message that is encapsulated with another LISP header using UDP destination port number 4342. It is used so an ITR, PITR, or a system initiating a 'lig' command can get the Map-Request to a Map-Resolver by using locator addresses. When the Map-Request is decapsulated by the Map-Resolver, it will be forwarded on the ALT network to the Map-Server that has injected the EID-prefix for a registered site. The Map-Server will then encapsulate the Map-Request in a LISP packet and send it to an ETR at the site. The ETR will then return an authoritative reply to the system that initiated the request. See [RFC6830] for packet format details.
カプセル化Map-Request（EMR）：EMRは、UDP宛先ポート番号4342を使用して別のLISPヘッダーでカプセル化されたMap-Requestメッセージです。ITR、PITR、または「lig」コマンドを開始するシステムが取得できるように使用されます。ロケーターアドレスを使用したMap-ResolverへのMap-Request Map-RequestがMap-Resolverによってカプセル化を解除されると、ALTネットワークを介して、登録済みサイトのEIDプレフィックスを挿入したMap-Serverに転送されます。次に、Map-ServerはMap-RequestをLISPパケットにカプセル化し、サイトのETRに送信します。次に、ETRは、要求を開始したシステムに信頼できる応答を返します。パケット形式の詳細については、[RFC6830]を参照してください。
Ingress Tunnel Router (ITR): An ITR is a router that accepts an IP packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its globally routable RLOCs in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC may be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side.
Ingress Tunnel Router（ITR）：ITRは、単一のIPヘッダーを持つIPパケット（より正確には、LISPヘッダーを含まないIPパケット）を受け入れるルーターです。ルータはこの「内部」IP宛先アドレスをEIDとして扱い、EIDからRLOCへのマッピング検索を実行します。次に、ルーターは、「外部」IPヘッダーの先頭に、グローバルにルーティング可能なRLOCの1つを送信元アドレスフィールドに追加し、マッピング検索の結果を宛先アドレスフィールドに追加します。この宛先RLOCは、宛先EIDに近いEIDからRLOCへのマッピングについてより詳しい知識を持つ中間プロキシデバイスである可能性があることに注意してください。一般に、ITRは一方のサイトのエンドシステムからIPパケットを受信し、LISPカプセル化されたIPパケットをもう一方のインターネットに送信します。
Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well.
出力トンネルルーター（ETR）：ETRは、「外部」IPヘッダーの宛先アドレスが独自のRLOCの1つであるIPパケットを受け入れるルーターです。ルータは「外部」ヘッダーを取り除き、見つかった次のIPヘッダーに基づいてパケットを転送します。一般に、ETRはLISPカプセル化IPパケットを一方のインターネットから受信し、カプセル化解除されたIPパケットを他方のサイトのエンドシステムに送信します。 ETR機能は、ルーターデバイスに限定する必要はありません。サーバーホストは、LISPトンネルのエンドポイントにもなります。
Proxy-ITR (PITR): A PITR, also known as a PTR, is defined and described in [RFC6832]. A PITR acts like an ITR but does so on behalf of non-LISP sites that send packets to destinations at LISP sites.
Proxy-ITR（PITR）：PITRはPTRとも呼ばれ、[RFC6832]で定義および説明されています。 PITRはITRのように機能しますが、LISPサイトの宛先にパケットを送信する非LISPサイトの代わりに機能します。
Proxy-ETR (PETR): A PETR is defined and described in [RFC6832]. A PETR acts like an ETR but does so on behalf of LISP sites that send packets to destinations at non-LISP sites.
Proxy-ETR（PETR）：PETRは[RFC6832]で定義および説明されています。 PETRはETRのように機能しますが、LISP以外のサイトの宛先にパケットを送信するLISPサイトに代わって機能します。
xTR: An xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint; it is used synonymously with the term "tunnel router". For example, "an xTR can be located at the Customer Edge (CE) router" means that both ITR and ETR functionality is at the CE router.
xTR：xTRは、データフローの方向がコンテキストの説明に含まれていない場合のITRまたはETRへの参照です。 xTRは、トンネルエンドポイントであるルーターを指します。 「トンネルルーター」という用語の同義語として使用されます。たとえば、「xTRはカスタマーエッジ（CE）ルーターに配置できる」とは、ITR機能とETR機能の両方がCEルーターにあることを意味します。
Provider-Assigned (PA) Addresses: PA addresses are an address block assigned to a site by each service provider to which a site connects. Typically, each block is a sub-block of a service-provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and is aggregated into the larger block before being advertised into the global Internet. Traditionally, IP multihoming has been implemented by each multihomed site acquiring its own globally visible prefix. LISP uses only topologically assigned and aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable practice.
プロバイダー割り当て（PA）アドレス：PAアドレスは、サイトが接続する各サービスプロバイダーによってサイトに割り当てられるアドレスブロックです。通常、各ブロックはサービスプロバイダーのクラスレスドメイン間ルーティング（CIDR）[RFC4632]ブロックのサブブロックであり、グローバルインターネットにアドバタイズされる前に、より大きなブロックに集約されます。従来、IPマルチホーミングは、グローバルに表示される独自のプレフィックスを取得するマルチホームサイトごとに実装されていました。 LISPはトポロジ的に割り当てられ、集約可能なアドレスブロックのみをRLOCに使用するため、これは明らかにスケーラブルではありません。
When the 'lig' command is run, a Map-Request is sent for a destination EID. When a Map-Reply is returned, the contents are displayed to the user. The information displayed includes:
「lig」コマンドが実行されると、宛先EIDに対してMap-Requestが送信されます。 Map-Replyが返されると、コンテンツがユーザーに表示されます。表示される情報は次のとおりです。
o The EID-prefix for the site that the queried destination EID matches.
o 照会された宛先EIDが一致するサイトのEIDプレフィックス。
o The locator address of the Map Replier.
o Map Replierのロケーターアドレス。
o The Locator-Set for the mapping entry, which includes the locator address, up/down status, priority, and weight of each Locator.
o ロケーターアドレス、アップ/ダウンステータス、優先度、各ロケーターの重みを含む、マッピングエントリのロケーターセット。
o A round-trip-time estimate for the Map-Request/Map-Reply exchange.
o Map-Request / Map-Reply交換の往復時間の見積もり。
A possible syntax for a 'lig' command could be:
「lig」コマンドの可能な構文は次のとおりです。
lig <destination> [source <source>] [to <map-resolver>]
Parameter description:
パラメータの説明：
<destination>: is either a Fully Qualified Domain Name (FQDN) or a destination EID for a remote LISP site.
<destination>：完全修飾ドメイン名（FQDN）またはリモートLISPサイトの宛先EIDのいずれかです。
source <source>: is an optional source EID to be inserted in the 'Source EID' field of the Map-Request.
source <source>：Map-Requestの「Source EID」フィールドに挿入されるオプションのソースEIDです。
to <map-resolver>: is an optional FQDN or RLOC address for a Map-Resolver.
to <map-resolver>：Map-ResolverのオプションのFQDNまたはRLOCアドレスです。
The 'lig' utility has two use cases. The first is a way to query the mapping database for a particular EID. The other is to verify if a site has registered successfully with a Map-Server.
「lig」ユーティリティには2つの使用例があります。 1つ目は、マッピングデータベースに特定のEIDを照会する方法です。もう1つは、サイトがMap-Serverに正常に登録されているかどうかを確認することです。
The first usage has already been described. Verifying registration is called "ligging yourself"; it happens as follows. In the 'lig' initiator, a Map-Request is sent for one of the EIDs for the 'lig' initiator's site. The Map-Request is then returned to one of the ETRs for the 'lig'-initiating site. In response to the Map-Request, a Map-Reply is sent back to the locator address of the 'lig' initiator (note the Map-Reply could be sent by the 'lig' initiator). That Map-Reply is processed, and the mapping data for the 'lig'- initiating site is displayed for the user. Refer to the syntax in Section 4.1 for an implementation of "ligging yourself". However, for host-based implementations within a LISP site, "lig self" is less useful since the host may not have an RLOC with which to receive a Map-Reply. But, 'lig' can be used in a non-LISP site, as well as from infrastructure hosts, to get mapping information.
最初の使用法はすでに説明されています。登録を確認することは「自分をライギングする」と呼ばれます。次のように発生します。 「lig」イニシエーターでは、「lig」イニシエーターのサイトのEIDの1つに対してMap-Requestが送信されます。 Map-Requestは、「lig」開始サイトのETRの1つに返されます。 Map-Requestに応答して、Map-Replyが「lig」イニシエーターのロケーターアドレスに返送されます（「lig」イニシエーターがMap-Replyを送信できることに注意してください）。そのMap-Replyが処理され、「lig」開始サイトのマッピングデータがユーザーに表示されます。 「自分をリギングする」の実装については、セクション4.1の構文を参照してください。ただし、LISPサイト内のホストベースの実装では、ホストがMap-Replyを受信するためのRLOCを持たない場合があるため、「lig self」はあまり役に立ちません。ただし、「lig」は、LISP以外のサイトでもインフラストラクチャホストからでも使用でき、マッピング情報を取得できます。
The Cisco LISP prototype implementation has support for 'lig' for IPv4 and IPv6. The command line description is:
Cisco LISPプロトタイプ実装は、IPv4およびIPv6の「lig」をサポートしています。コマンドラインの説明は次のとおりです。
lig <dest-eid> [source <source-eid>] [to <mr>] [count <1-5>]
This command initiates the LISP Internet Groper. It is similar to the DNS analogue 'dig' but works on the LISP mapping database. When this command is invoked, the local system will send a Map-Request to the configured Map-Resolver. When a Map-Reply is returned, its contents will be displayed to the user. By default, up to three Map-Requests are sent if no Map-Reply is returned, but, once a Map-Reply is returned, no other Map-Requests are sent. The destination can take a DNS name, or an IPv4 or IPv6 EID address. The <source-eid> can be one of the EID addresses assigned to the site in the default Virtual Routing and Forwarding (VRF) table. When <mr> is specified, then the Map-Request is sent to the address. Otherwise, the Map-Request is sent to a configured Map-Resolver. When a Map-Resolver is not configured, then the Map-Request is sent on the ALT network if the local router is attached to the ALT. When "count <1-5>" is specified, 1, 2, 3, 4, or 5 Map-Requests are sent.
このコマンドは、LISP Internet Groperを開始します。 DNSの「dig」に似ていますが、LISPマッピングデータベースで機能します。このコマンドが呼び出されると、ローカルシステムは構成されたMap-ResolverにMap-Requestを送信します。 Map-Replyが返されると、その内容がユーザーに表示されます。デフォルトでは、Map-Replyが返されない場合は最大3つのMap-Requestが送信されますが、Map-Replyが返されると、他のMap-Requestは送信されません。宛先は、DNS名、またはIPv4またはIPv6 EIDアドレスを取ることができます。 <source-eid>は、デフォルトの仮想ルーティングおよび転送（VRF）テーブルでサイトに割り当てられたEIDアドレスの1つです。 <mr>を指定すると、Map-Requestがアドレスに送信されます。それ以外の場合、Map-Requestは構成済みのMap-Resolverに送信されます。 Map-Resolverが構成されていない場合、ローカルルーターがALTに接続されていると、Map-RequestがALTネットワークで送信されます。 「count <1-5>」が指定された場合、1、2、3、4、または5つのMap-Requestが送信されます。
Some sample output:
いくつかの出力例：
router# lig abc.example.com Send map-request to 10.0.0.1 for 192.168.1.1 ... Received map-reply from 10.0.0.2 with rtt 0.081468 secs
router＃lig abc.example.com 192.168.1.1の10.0.0.1にマップ要求を送信... 10.0.0.2からrtt 0.081468秒でマップ応答を受信
Map-Cache entry for abc.example.com EID 192.168.1.1:
192.168.1.0/24, uptime: 13:59:59, expires: 23:59:58,
via map-reply, auth
Locator Uptime State Priority/Weight Packets In/Out
10.0.0.2 13:59:59 up 1/100 0/14
Using 'lig' to "lig yourself" is accomplished with the following syntax:
「lig」を使用して「自分をライグ」するには、次の構文を使用します。
lig {self | self6} [source <source-eid>] [to <mr>] [count <1-5>]
Use this command for a simple way to see if the site is registered with the mapping database system. The destination-EID address for the Map-Request will be the first configured EID-prefix for the site (with the host bits set to 0). For example, if the site's EID-prefix is 192.168.1.0/24, the destination-EID for the Map-Request is 192.168.1.0. The source-EID address for the Map-Request will also be 192.168.1.0 (in this example), and the Map-Request is sent to the configured Map-Resolver. If the Map-Resolver and Map-Server are the same LISP system, then the "lig self" is testing if the Map-Resolver can "turn back a Map-Request to the site". If another Map-Resolver is used, it can test that the site's EID-prefix has been injected into the ALT infrastructure, in which case the 'lig' Map-Request is processed by the Map-Resolver and propagated through each ALT-Router hop to the site's registered Map-Server. Then, the Map-Server returns the Map-Request to the originating site. In that case, an xTR at the originating site sends a Map-Reply to the source of the Map-Request (could be itself or another xTR for the site). All other command parameters are described above. Using "lig self6" tests for registering of IPv6 EID-prefixes.
このコマンドを使用すると、サイトがマッピングデータベースシステムに登録されているかどうかを簡単に確認できます。 Map-Requestの宛先EIDアドレスは、サイトに最初に構成されたEIDプレフィックスになります（ホストビットが0に設定されています）。たとえば、サイトのEIDプレフィックスが192.168.1.0/24の場合、Map-Requestの宛先EIDは192.168.1.0です。 Map-Requestの送信元EIDアドレスも192.168.1.0（この例では）になり、Map-Requestは構成されたMap-Resolverに送信されます。 Map-ResolverとMap-Serverが同じLISPシステムの場合、「lig self」はMap-Resolverが「Map-Requestをサイトに戻す」ことができるかどうかをテストしています。別のMap-Resolverが使用されている場合、サイトのEIDプレフィックスがALTインフラストラクチャに挿入されていることをテストできます。この場合、「lig」Map-RequestはMap-Resolverによって処理され、各ALTルーターホップを通じて伝播されます。サイトの登録済みMap-Server次に、Map-ServerはMap-Requestを元のサイトに返します。その場合、元のサイトのxTRがMap-RequestのソースにMap-Replyを送信します（それ自体またはサイトの別のxTRである可能性があります）。他のすべてのコマンドパラメータについては、上記で説明しています。 IPv6 EIDプレフィックスの登録に「lig self6」テストを使用します。
Some sample output for "ligging yourself":
「自分をリギングする」ためのサンプル出力：
router# lig self Send loopback map-request to 10.0.0.1 for 192.168.2.0 ... Received map-reply from 10.0.0.3 with rtt 0.001592 secs
router＃lig self 10.0.0.1に192.168.2.0のループバックマップ要求を送信... 10.0.0.3からrtt 0.001592秒でマップ応答を受信
Map-Cache entry for EID 192.168.2.0:
192.168.2.0/24, uptime: 00:00:02, expires: 23:59:57
via map-reply, self
Locator Uptime State Priority/Weight Packets In/Out
10.0.0.3 00:00:02 up 1/100 0/0
router# lig self6
Send loopback map-request to 10.0.0.1 for 2001:db8:1:: ...
Received map-reply from 10::1 with rtt 0.044372 secs
Map-Cache entry for EID 192:168:1:::
2001:db8:1::/48, uptime: 00:00:01, expires: 23:59:58
via map-reply, self
Locator Uptime State Priority/Weight Packets In/Out
10.0.0.3 00:00:01 up 1/100 0/0
2001:db8:ffff::1 00:00:01 up 2/0 0/0
There is a public domain implementation that can run on any x86-based system. The only requirement is that the system that initiates 'lig' must have an address assigned from the locator namespace.
任意のx86ベースのシステムで実行できるパブリックドメインの実装があります。唯一の要件は、「lig」を開始するシステムがロケーター名前空間から割り当てられたアドレスを持っている必要があることです。
lig [-d] <eid> -m <map-resolver> [-c <count>] [-t <timeout>]
Parameter description:
パラメータの説明：
-d: prints additional protocol debug output.
-d：追加のプロトコルデバッグ出力を出力します。
<eid>: the destination EID or FQDN of a LISP host.
<eid>：LISPホストの宛先EIDまたはFQDN。
-m <map-resolver>: the RLOC address or FQDN of a Map-Resolver.
-m <map-resolver>：Map-ResolverのRLOCアドレスまたはFQDN。
-c <count>: the number of Map-Requests to send before the first Map-Reply is returned. The default value is 3. The range is from 1 to 5.
-c <count>：最初のMap-Replyが返される前に送信するMap-Requestの数。デフォルト値は3です。範囲は1〜5です。
-t <timeout>: the amount of time, in seconds, before another Map-Request is sent when no Map-Reply is returned. The default value is 2 seconds. The range is from 1 to 5.
-t <timeout>：Map-Replyが返されない場合に別のMap-Requestが送信されるまでの時間（秒単位）。デフォルト値は2秒です。範囲は1〜5です。
Some sample output:
いくつかの出力例：
% lig xyz.example.com -m 10.0.0.1 Send map-request to 10.0.0.1 for 192.168.1.1 ... Received map-reply from 10.0.0.2 with rtt 0.04000 sec
％lig xyz.example.com -m 10.0.0.1 192.168.1.1の10.0.0.1にマップ要求を送信... 10.0.0.2からrtt 0.04000秒でマップ応答を受信
Mapping entry for EID 192.168.1.1: 192.168.1.0/24, record ttl: 60 Locator State Priority/Weight 10.0.0.1 up 1/25 10.0.0.2 up 1/25 10.0.0.3 up 1/25 10.0.0.4 up 2/25
EID 192.168.1.1のマッピングエントリ：192.168.1.0/24、レコードttl：60 Locator State Priority / Weight 10.0.0.1 up 1/25 10.0.0.2 up 1/25 10.0.0.3 up 1/25 10.0.0.4 up 2 / 25
The public domain implementation of 'lig' is available at <http://github.com/LISPmob/lig>.
「lig」のパブリックドメイン実装は、<http://github.com/LISPmob/lig>で入手できます。
There are cases where a Map-Reply is returned from a 'lig' request, but the user doesn't really know how much of the mapping infrastructure was tested. There are two cases to consider -- avoiding the ALT and traversing the ALT.
Map-Replyが「lig」リクエストから返される場合がありますが、ユーザーは実際にマッピングインフラストラクチャのどの程度がテストされたかわかりません。考慮すべき2つのケースがあります。ALTを回避することと、ALTをトラバースすることです。
When an ITR sends a 'lig' request to its Map-Resolver for a destination-EID, the Map-Resolver could also be configured as a Map-Server. And if the destination-EID is for a site that registers with this Map-Server, the Map-Request is sent to the site directly without testing the ALT. This occurs because the Map-Server is the source of the advertisement for the site's EID-prefix. So, if the map-reply is returned to the 'lig'-requesting site, you cannot be sure that other sites can reach the same destination-EID.
ITRが「lig」リクエストを宛先EIDのMap-Resolverに送信する場合、Map-ResolverはMap-Serverとしても構成できます。また、destination-EIDがこのMap-Serverに登録するサイト用である場合、ALTをテストせずにMap-Requestがサイトに直接送信されます。これは、Map-ServerがサイトのEIDプレフィックスのアドバタイズのソースであるために発生します。そのため、map-replyが「lig」を要求するサイトに返された場合、他のサイトが同じ宛先EIDに到達できるかどうかは確信できません。
If a Map-Resolver is used that is not a Map-Server for the EID-prefix being sought, then the ALT infrastructure can be tested. This test case is testing the functionality of the Map-Resolver, traversal of the ALT (testing BGP-over-GRE), and the Map-Server.
求められているEIDプレフィックスのMap-ServerではないMap-Resolverが使用されている場合、ALTインフラストラクチャをテストできます。このテストケースは、Map-Resolverの機能、ALTのトラバーサル（BGP-over-GREのテスト）、およびMap-Serverのテストです。
It is recommended that users issue two 'lig' requests; they send Map-Requests to different Map-Resolvers.
ユーザーは2つの「lig」リクエストを発行することをお勧めします。それらは異なるMap-ResolverにMap-Requestを送信します。
The network can have a LISP-ALT Router deployed as a "ALT looking-glass" node. This type of router has BGP peering sessions with other ALT Routers where it does not inject any EID-prefixes into the ALT but just learns ones advertised by other ALT Routers and Map-Servers. This router is configured as a Map-Resolver. 'lig' users can point to the ALT looking-glass router for Map-Resolver services via the "to <map-resolver>" parameter on the 'lig' command. The ALT looking- glass node can be used to 'lig' other sites as well as your own site. When the ALT looking-glass is used as a Map-Resolver, you can be assured the ALT network is being tested.
ネットワークでは、LISP-ALTルーターを「ALT looking-glass」ノードとして配置できます。このタイプのルーターには、他のALTルーターとのBGPピアリングセッションがあり、ALTにEIDプレフィックスを挿入せず、他のALTルーターとマップサーバーによってアドバタイズされたものを学習します。このルーターはMap-Resolverとして構成されています。 「lig」ユーザーは、「lig」コマンドの「to <map-resolver>」パラメータを介して、Map-ResolverサービスのALTグラスルーターを指すことができます。 ALTルッキンググラスノードは、他のサイトや自分のサイトを「つなぐ」ために使用できます。 ALT鏡をMap-Resolverとして使用すると、ALTネットワークが確実にテストされます。
When Negative Map-Replies have been further developed and implemented, 'lig' should be modified appropriately to process and clearly indicate how and why a Negative Map-Reply was received. Negative Map-Replies could be sent in the following cases: the 'lig' request was initiated for a non-EID address or there was rate-limiting on the replier.
Negative Map-Replyがさらに開発および実装された場合、Negative Map-Replyを受け取った方法と理由を処理して明確に示すために、「lig」を適切に変更する必要があります。否定のMap-Repliesは、次の場合に送信できます。「lig」リクエストが非EIDアドレスに対して開始されたか、または返信者にレート制限があった。
There is a web-based interface to do auto-polling with 'lig' on the back-end for most of the LISP sites on the LISP test network. The web page can be accessed at <http://www.lisp4.net/status>.
LISPテストネットワーク上のほとんどのLISPサイトのバックエンドで「lig」を使用して自動ポーリングを行うWebベースのインターフェイスがあります。 Webページには、<http://www.lisp4.net/status>からアクセスできます。
There is a LISP site monitoring web-based interface that can be found at <http://lispmon.net>.
<http://lispmon.net>にあるWebベースのインターフェイスを監視するLISPサイトがあります。
At <http://baldomar.ccaba.upc.edu/lispmon>, written by the folks at Universitat Politecnica de Catalunya (UPC), shows a geographical map indicating where each LISP site resides.
<http://baldomar.ccaba.upc.edu/lispmon>には、カタルーニャ大学（UPC）の人々が書いた、各LISPサイトがどこにあるかを示す地理的な地図が示されています。
The use of 'lig' does not affect the security of the LISP infrastructure as it is simply a tool that facilities diagnostic querying. See [RFC6830], [RFC6836], and [RFC6833] for descriptions of the security properties of the LISP infrastructure.
「lig」を使用しても、LISPインフラストラクチャのセキュリティには影響しません。これは、単に診断クエリを実行するためのツールであるためです。 LISPインフラストラクチャのセキュリティプロパティの説明については、[RFC6830]、[RFC6836]、および[RFC6833]を参照してください。
'lig' provides easy access to the information in the public mapping database. Therefore, it is important to protect the mapping information for private use. This can be provided by disallowing access to specific mapping entries or to place such entries in a private mapping database system.
'lig'は、パブリックマッピングデータベースの情報に簡単にアクセスできるようにします。したがって、個人使用のためにマッピング情報を保護することが重要です。これは、特定のマッピングエントリへのアクセスを禁止するか、そのようなエントリをプライベートマッピングデータベースシステムに配置することで提供できます。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632] Fuller、V。およびT. Li、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、BCP 122、RFC 4632、2006年8月。
[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月。
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6832] Lewis、D.、Meyer、D.、Farinacci、D。、およびV. Fuller、「Locator / ID Separation Protocol（LISP）and Non-LISP Sites between Interworking」、RFC 6832、2013年1月。
[RFC6833] Farinacci, D. and V. Fuller, "Locator/ID Separation Protocol (LISP) Map Server Interface", RFC 6833, January 2013.
[RFC6833] Farinacci、D。およびV. Fuller、「Locator / ID Separation Protocol（LISP）Map Server Interface」、RFC 6833、2013年1月。
[LISP-CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", Work in Progress, April 2008.
[LISP-CONS] Farinacci、D.、Fuller、V。、およびD. Meyer、「LISP-CONS：A Content distribution Overlay Network Service for LISP」、Work in Progress、2008年4月。
[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月。
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database", RFC 6837, January 2013.
[RFC6837]リア、E。、「NERD：A Not-so-novel Endpoint ID（EID）to Routing Locator（RLOC）Database」、RFC 6837、2013年1月。
Thanks and kudos to John Zwiebel, Andrew Partan, Darrel Lewis, and Vince Fuller for providing critical feedback on the 'lig' design and prototype implementations. To these folks, as well as all the people on lisp-beta@external.cisco.com who tested 'lig' functionality and continue to do so, we extend our sincere thanks.
「lig」の設計とプロトタイプの実装に関する重要なフィードバックを提供してくれたJohn Zwiebel、Andrew Partan、Darrel Lewis、Vince Fullerに感謝します。これらの人々、およびligp-beta@external.cisco.comで「lig」機能をテストしてテストを続けたすべての人々に、心から感謝します。
This document is based on an individual contribution.
このドキュメントは、個人の寄稿に基づいています。
Authors' Addresses
著者のアドレス
Dino Farinacci Cisco Systems Tasman Drive San Jose, CA 95134 USA
Dino Farinacci Cisco Systems Tasman Drive San Jose、CA 95134 USA
EMail: farinacci@gmail.com
Dave Meyer Cisco Systems 170 Tasman Drive San Jose, CA USA
Dave Meyer Cisco Systems 170 Tasman Drive米国カリフォルニア州サンノゼ
EMail: dmm@cisco.com