[要約] RFC 6833は、LISPマップサーバーインターフェースに関する仕様を提供しています。このRFCの目的は、LISPプロトコルのマップサーバーとのインターフェースを定義し、LISPネットワークのスケーラビリティと柔軟性を向上させることです。
Internet Engineering Task Force (IETF) V. Fuller
Request for Comments: 6833
Category: Experimental D. Farinacci
ISSN: 2070-1721 Cisco Systems
January 2013
Locator/ID Separation Protocol (LISP) Map-Server Interface
ロケータ/ ID分離プロトコル（LISP）Map-Serverインターフェイス
Abstract
概要
This document describes the Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases.
このドキュメントでは、Locator / ID Separation Protocol（LISP）のマッピングサービスについて説明します。これは、LISP Map-ResolverとLISP Map-Serverの2つの新しいタイプのLISPスピーキングデバイスによって実装され、シンプルな「フロントエンド」を提供します。ルーティングロケータマッピングデータベースへの1つ以上のエンドポイントID。
By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP.
このサービスインターフェイスを使用し、Map-ResolversおよびMap-Serverと通信することにより、LISP入力トンネルルーターおよび出力トンネルルーターは、データベースシステムのマッピングの詳細に依存しないため、さまざまなデータベース設計の実験が容易になります。これらのデバイスは、LISPインフラストラクチャの「エッジ」を実装し、LISP対応のインターネットエンドサイトに直接接続し、LISPを話すデバイスの大部分を構成するため、実装と運用の複雑さを軽減することで、LISPの展開にかかる全体的なコストと労力も削減できます。 。
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/rfc6833.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6833で入手できます。
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 ..................................................4
4. Interactions with Other LISP Components .........................5
4.1. ITR EID-to-RLOC Mapping Resolution .........................5
4.2. EID-Prefix Configuration and ETR Registration ..............6
4.3. Map-Server Processing ......................................8
4.4. Map-Resolver Processing ....................................9
4.4.1. Anycast Map-Resolver Operation .....................10
5. Open Issues and Considerations .................................10
6. Security Considerations ........................................11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................12
Appendix A. Acknowledgments .......................................13
The Locator/ID Separation Protocol [RFC6830] specifies an architecture and mechanism for replacing the addresses currently used by IP with two separate name spaces: 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 are the Content distribution Overlay Network Service for LISP (LISP-CONS) [LISP-CONS], LISP-NERD (a Not-so-novel EID-to-RLOC Database) [RFC6837], and LISP Alternative Logical Topology (LISP+ALT) [RFC6836].
Locator / ID Separation Protocol [RFC6830]は、現在IPで使用されているアドレスを2つの別個の名前空間に置き換えるためのアーキテクチャとメカニズムを指定しています。サイト内で使用されるエンドポイントID（EID）。インターネットインフラストラクチャを構成するトランジットネットワークで使用されるルーティングロケータ（RLOC）。この分離を実現するために、LISPはEIDからRLOCにマッピングするためのプロトコルメカニズムを定義しています。さらに、LISPはデータベースの存在を前提として、これらのマッピングをグローバルに保存および伝達します。このようなデータベースがいくつか提案されています。その中には、LISP用コンテンツ配信オーバーレイネットワークサービス（LISP-CONS）[LISP-CONS]、LISP-NERD（Not-so-novel EID-to-RLOC Database）[RFC6837]、およびLISP Alternative Logical Topology（LISP）があります。 + ALT）[RFC6836]。
The LISP Mapping Service defines two new types of LISP-speaking devices: the Map-Resolver, which accepts Map-Requests from an Ingress Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a mapping database; and the Map-Server, which learns authoritative EID-to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes them in a database.
LISPマッピングサービスは、2つの新しいタイプのLISPスピーキングデバイスを定義します。Map-Resolverは、Ingress Tunnel Router（ITR）からのMap-Requestsを受け入れ、マッピングデータベースを使用してEID-to-RLOCマッピングを「解決」します。また、Map-Serverは、Egress Tunnel Router（ETR）からEIDからRLOCへの信頼できるマッピングを学習し、データベースに公開します。
Conceptually, LISP Map-Servers share some of the same basic configuration and maintenance properties as Domain Name System (DNS) [RFC1035] servers; likewise, Map-Resolvers are conceptually similar to DNS caching resolvers. With this in mind, this specification borrows familiar terminology (resolver and server) from the DNS specifications.
概念的には、LISP Map-Serverは、ドメインネームシステム（DNS）[RFC1035]サーバーと同じ基本構成およびメンテナンスプロパティのいくつかを共有します。同様に、Map-Resolversは概念的にDNSキャッシングリゾルバーに似ています。これを念頭に置いて、この仕様はDNS仕様からおなじみの用語（リゾルバーとサーバー）を借用しています。
Note that while this document assumes a LISP+ALT database mapping infrastructure to illustrate certain aspects of Map-Server and Map-Resolver operation, the Mapping Service interface can (and likely will) be used by ITRs and ETRs to access other mapping database systems as the LISP infrastructure evolves.
このドキュメントでは、Map-ServerおよびMap-Resolver操作の特定の側面を説明するためにLISP + ALTデータベースマッピングインフラストラクチャを想定していますが、マッピングサービスインターフェイスは、ITRおよびETRが他のマッピングデータベースシステムにアクセスするために使用できます（使用される可能性があります）。 LISPインフラストラクチャが進化します。
Section 5 of this document notes a number of issues with the Map-Server and Map-Resolver design that are not yet completely understood and are subjects of further experimentation.
このドキュメントのセクション5には、Map-ServerおよびMap-Resolverの設計に関する多くの問題が記載されていますが、これらはまだ完全には理解されておらず、さらなる実験の対象となっています。
The LISP Mapping Service is an important component of the LISP toolset. Issues and concerns about the deployment of LISP for Internet traffic are discussed in [RFC6830].
LISPマッピングサービスは、LISPツールセットの重要なコンポーネントです。インターネットトラフィック用のLISPの展開に関する問題と懸念事項は、[RFC6830]で説明されています。
Map-Server: A network infrastructure component that learns of EID-Prefix mapping entries from an ETR, via the registration mechanism described below, or some other authoritative source if one exists. A Map-Server publishes these EID-Prefixes in a mapping database.
Map-Server：以下で説明する登録メカニズム、または存在する場合はその他の信頼できるソースを介して、ETRからEIDプレフィックスマッピングエントリを学習するネットワークインフラストラクチャコンポーネント。 Map-Serverは、これらのEIDプレフィックスをマッピングデータベースに公開します。
Map-Resolver: A network infrastructure component that accepts LISP Encapsulated Map-Requests, typically from an ITR, and determines whether or not the destination IP address is part of the EID namespace; if it is not, a Negative Map-Reply is returned. Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC mapping by consulting a mapping database system.
Map-Resolver：通常はITRからのLISPカプセル化Map-Requestを受け入れ、宛先IPアドレスがEID名前空間の一部であるかどうかを決定するネットワークインフラストラクチャコンポーネント。そうでない場合、Negative Map-Replyが返されます。それ以外の場合、Map-Resolverは、マッピングデータベースシステムを参照して、適切なEIDからRLOCへのマッピングを見つけます。
Encapsulated Map-Request: A LISP Map-Request carried within an Encapsulated Control Message, which has an additional LISP header prepended. Sent to UDP destination port 4342. The "outer" addresses are globally routable IP addresses, also known as RLOCs. Used by an ITR when sending to a Map-Resolver and by a Map-Server when forwarding a Map-Request to an ETR.
カプセル化されたMap-Request：追加のLISPヘッダーが前に付加されたカプセル化された制御メッセージ内で運ばれるLISP Map-Request。 UDP宛先ポート4342に送信されます。「外部」アドレスは、グローバルにルーティング可能なIPアドレスであり、RLOCとも呼ばれます。 Map-Resolverに送信するときにITRによって使用され、Map-RequestをETRに転送するときにMap-Serverによって使用されます。
Negative Map-Reply: A LISP Map-Reply that contains an empty Locator-Set. Returned in response to a Map-Request if the destination EID does not exist in the mapping database. Typically, this means that the "EID" being requested is an IP address connected to a non-LISP site.
Negative Map-Reply：空のLocator-Setを含むLISP Map-Reply。宛先EIDがマッピングデータベースに存在しない場合、Map-Requestへの応答として返されます。通常、これは、要求される「EID」が非LISPサイトに接続されたIPアドレスであることを意味します。
Map-Register message: A LISP message sent by an ETR to a Map-Server to register its associated EID-Prefixes. In addition to the set of EID-Prefixes to register, the message includes one or more RLOCs to be used by the Map-Server when forwarding Map-Requests (re-formatted as Encapsulated Map-Requests) received through the database mapping system. An ETR may request that the Map-Server answer Map-Requests on its behalf by setting the "proxy Map-Reply" flag (P-bit) in the message.
Map-Registerメッセージ：関連するEIDプレフィックスを登録するためにETRからMap-Serverに送信されるLISPメッセージ。登録するEIDプレフィックスのセットに加えて、メッセージには、データベースマッピングシステムを介して受信したMap-Request（カプセル化Map-Requestとして再フォーマット）を転送するときにMap-Serverが使用する1つ以上のRLOCが含まれます。 ETRは、メッセージに「プロキシMap-Reply」フラグ（Pビット）を設定することにより、Map-ServerがMap-Requestに代わって応答することを要求できます。
Map-Notify message: A LISP message sent by a Map-Server to an ETR to confirm that a Map-Register has been received and processed. An ETR requests that a Map-Notify be returned by setting the "want-map-notify" flag (M-bit) in the Map-Register message. Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both source and destination.
Map-Notifyメッセージ：Map-Registerが受信および処理されたことを確認するためにMap-ServerからETRに送信されるLISPメッセージ。 ETRは、Map-Registerメッセージで「want-map-notify」フラグ（Mビット）を設定することにより、Map-Notifyが返されることを要求します。 Map-Replyとは異なり、Map-Notifyは送信元と宛先の両方にUDPポート4342を使用します。
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]を参照してください。
A Map-Server is a device that publishes EID-Prefixes in a LISP mapping database on behalf of a set of ETRs. When it receives a Map Request (typically from an ITR), it consults the mapping database to find an ETR that can answer with the set of RLOCs for an EID-Prefix. To publish its EID-Prefixes, an ETR periodically sends Map-Register messages to the Map-Server. A Map-Register message contains a list of EID-Prefixes plus a set of RLOCs that can be used to reach the ETR when a Map-Server needs to forward a Map-Request to it.
Map-Serverは、一連のETRに代わってLISPマッピングデータベースにEIDプレフィックスを公開するデバイスです。 （通常はITRから）マップ要求を受信すると、マッピングデータベースを調べて、EIDプレフィックスのRLOCのセットで応答できるETRを見つけます。 EIDプレフィックスを公開するために、ETRは定期的にMap-RegisterメッセージをMap-Serverに送信します。 Map-Registerメッセージには、EIDプレフィックスのリストと、Map-ServerがMap-Requestを転送する必要があるときにETRに到達するために使用できるRLOCのセットが含まれています。
When LISP+ALT is used as the mapping database, a Map-Server connects to the ALT network and acts as a "last-hop" ALT-Router. Intermediate ALT-Routers forward Map-Requests to the Map-Server that advertises a particular EID-Prefix, and the Map-Server forwards them to the owning ETR, which responds with Map-Reply messages.
LISP + ALTがマッピングデータベースとして使用される場合、Map-ServerはALTネットワークに接続し、「ラストホップ」ALT-Routerとして機能します。中間のALTルータは、Map-Requestを特定のEID-PrefixをアドバタイズするMap-Serverに転送し、Map-Serverはそれらを所有するETRに転送します。所有するETRはMap-Replyメッセージで応答します。
A Map-Resolver receives Encapsulated Map-Requests from its client ITRs and uses a mapping database system to find the appropriate ETR to answer those requests. On a LISP+ALT network, a Map-Resolver acts as a "first-hop" ALT-Router. It has Generic Routing Encapsulation (GRE) tunnels configured to other ALT-Routers and uses BGP to learn paths to ETRs for different prefixes in the LISP+ALT database. The Map-Resolver uses this path information to forward Map-Requests over the ALT to the correct ETRs.
Map-Resolverは、クライアントのITRからカプセル化されたMap-Requestを受け取り、マッピングデータベースシステムを使用して、それらの要求に応答する適切なETRを見つけます。 LISP + ALTネットワークでは、Map-Resolverは「ファーストホップ」ALT-Routerとして機能します。他のALTルータに設定されたGeneric Routing Encapsulation（GRE）トンネルがあり、BGPを使用して、LISP + ALTデータベースのさまざまなプレフィックスのETRへのパスを学習します。 Map-Resolverはこのパス情報を使用して、ALT経由でMap-Requestを正しいETRに転送します。
Note that while it is conceivable that a Map-Resolver could cache responses to improve performance, issues surrounding cache management will need to be resolved so that doing so will be reliable and practical. As initially deployed, Map-Resolvers will operate only in a non-caching mode, decapsulating and forwarding Encapsulated Map Requests received from ITRs. Any specification of caching functionality is left for future work.
Map-Resolverがパフォーマンスを向上させるために応答をキャッシュすることは考えられますが、キャッシュ管理を取り巻く問題を解決して、信頼性と実用性を高める必要があることに注意してください。最初にデプロイされたとき、Map-Resolversは非キャッシングモードでのみ動作し、ITRから受信したカプセル化されたマップ要求をカプセル化解除して転送します。キャッシング機能の仕様は今後の作業に残します。
Note that a single device can implement the functions of both a Map-Server and a Map-Resolver, and in many cases the functions will be co-located in that way.
単一のデバイスがMap-ServerとMap-Resolverの両方の機能を実装できることに注意してください。多くの場合、機能はそのように同じ場所に配置されます。
Detailed descriptions of the LISP packet types referenced by this document may be found in [RFC6830].
このドキュメントで参照されているLISPパケットタイプの詳細な説明は、[RFC6830]にあります。
An ITR is configured with one or more Map-Resolver addresses. These addresses are "Locators" (or RLOCs) and must be routable on the underlying core network; they must not need to be resolved through LISP EID-to-RLOC mapping, as that would introduce a circular dependency. When using a Map-Resolver, an ITR does not need to connect to any other database mapping system. In particular, the ITR need not connect to the LISP+ALT infrastructure or implement the BGP and GRE protocols that it uses.
ITRは、1つ以上のMap-Resolverアドレスで構成されます。これらのアドレスは「ロケーター」（またはRLOC）であり、基盤となるコアネットワークでルーティング可能である必要があります。 LISPのEIDからRLOCへのマッピングを通じて解決する必要はありません。循環依存が発生するためです。 Map-Resolverを使用する場合、ITRは他のデータベースマッピングシステムに接続する必要はありません。特に、ITRはLISP + ALTインフラストラクチャに接続したり、使用するBGPおよびGREプロトコルを実装したりする必要はありません。
An ITR sends an Encapsulated Map-Request to a configured Map-Resolver when it needs an EID-to-RLOC mapping that is not found in its local map-cache. Using the Map-Resolver greatly reduces both the complexity of the ITR implementation and the costs associated with its operation.
ITRは、ローカルのマップキャッシュにないEIDからRLOCへのマッピングが必要な場合、カプセル化されたマップ要求を構成済みのマップリゾルバーに送信します。 Map-Resolverを使用すると、ITR実装の複雑さとその操作に関連するコストの両方が大幅に削減されます。
In response to an Encapsulated Map-Request, the ITR can expect one of the following:
カプセル化されたMap-Requestに応答して、ITRは次のいずれかを予期できます。
o An immediate Negative Map-Reply (with action code of "Natively-Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if the Map-Resolver can determine that the requested EID does not exist. The ITR saves the EID-Prefix returned in the Map-Reply in its cache, marks it as non-LISP-capable, and knows not to attempt LISP encapsulation for destinations matching it.
o Map-Resolverが要求されたEIDが存在しないと判断できる場合、Map-Resolverからの即時の負のMap-Reply（「Natively-Forward」のアクションコード、15分の存続可能時間（TTL））。 ITRはMap-Replyで返されたEIDプレフィックスをキャッシュに保存し、非LISP対応としてマークし、それに一致する宛先に対してLISPカプセル化を試行しないことを認識しています。
o A Negative Map-Reply, with action code of "Natively-Forward", from a Map-Server that is authoritative for an EID-Prefix that matches the requested EID but that does not have an actively registered, more-specific ID-prefix. In this case, the requested EID is said to match a "hole" in the authoritative EID-Prefix. If the requested EID matches a more-specific EID-Prefix that has been delegated by the Map-Server but for which no ETRs are currently registered, a 1-minute TTL is returned. If the requested EID matches a non-delegated part of the authoritative EID-Prefix, then it is not a LISP EID and a 15-minute TTL is returned. See Section 4.2 for discussion of aggregate EID-Prefixes and details of Map-Server EID-Prefix matching.
o 要求されたEIDと一致するが、アクティブに登録された、より具体的なIDプレフィックスを持たないEIDプレフィックスに対して信頼できるMap-Serverからの、アクションコードが「Natively-Forward」の負のMap-Reply。この場合、要求されたEIDは、信頼できるEIDプレフィックスの「穴」と一致すると言われています。要求されたEIDが、Map-Serverによって委任されているが、現在ETRが登録されていない、より具体的なEIDプレフィックスと一致する場合、1分のTTLが返されます。要求されたEIDが信頼できるEIDプレフィックスの委任されていない部分と一致する場合、それはLISP EIDではなく、15分のTTLが返されます。集約EID-Prefixesの説明とMap-Server EID-Prefixマッチングの詳細については、セクション4.2を参照してください。
o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or possibly from a Map-Server answering on behalf of the ETR. See Section 4.4 for more details on Map-Resolver message processing.
o EIDからRLOCへのマッピングを所有するETRからのLISP Map-Reply、またはETRに代わって応答するMap-ServerからのLISP Map-Reply。 Map-Resolverメッセージ処理の詳細については、4.4項を参照してください。
Note that an ITR may be configured to both use a Map-Resolver and to participate in a LISP+ALT logical network. In such a situation, the ITR should send Map-Requests through the ALT network for any EID-Prefix learned via ALT BGP. Such a configuration is expected to be very rare, since there is little benefit to using a Map-Resolver if an ITR is already using LISP+ALT. There would be, for example, no need for such an ITR to send a Map-Request to a possibly non-existent EID (and rely on Negative Map-Replies) if it can consult the ALT database to verify that an EID-Prefix is present before sending that Map-Request.
ITRは、Map-Resolverを使用するようにも、LISP + ALT論理ネットワークに参加するようにも構成できることに注意してください。このような状況では、ITRは、ALT BGPを介して学習されたEIDプレフィックスについて、ALTネットワークを介してマップ要求を送信する必要があります。 ITRがすでにLISP + ALTを使用している場合、Map-Resolverを使用するメリットはほとんどないため、このような構成は非常にまれであると予想されます。たとえば、ALTデータベースを調べてEIDプレフィックスが存在することを確認できれば、そのようなITRが存在しない可能性のあるEIDにMap-Requestを送信する（そして負のMap-Repliesに依存する）必要はありません。そのMap-Requestを送信する前に存在します。
An ETR publishes its EID-Prefixes on a Map-Server by sending LISP Map-Register messages. A Map-Register message includes authentication data, so prior to sending a Map-Register message, the ETR and Map-Server must be configured with a shared secret or other relevant authentication information. A Map-Server's configuration must also include a list of the EID-Prefixes for which each ETR is authoritative. Upon receipt of a Map-Register from an ETR, a Map-Server accepts only EID-Prefixes that are configured for that ETR. Failure to implement such a check would leave the mapping system vulnerable to trivial EID-Prefix hijacking attacks. As developers and operators gain experience with the mapping system, additional, stronger security measures may be added to the registration process.
ETRは、LISP Map-Registerメッセージを送信して、EIDプレフィックスをMap-Serverに公開します。 Map-Registerメッセージには認証データが含まれているため、Map-Registerメッセージを送信する前に、ETRとMap-Serverに共有シークレットまたはその他の関連認証情報を設定する必要があります。 Map-Serverの構成には、各ETRが信頼できるEIDプレフィックスのリストも含まれている必要があります。 ETRからMap-Registerを受信すると、Map-Serverは、そのETR用に構成されたEIDプレフィックスのみを受け入れます。このようなチェックを実装しないと、マッピングシステムが簡単なEIDプレフィックスハイジャック攻撃に対して脆弱になります。開発者とオペレーターがマッピングシステムの経験を積むにつれて、登録プロセスにさらに強力なセキュリティ対策が追加される可能性があります。
In addition to the set of EID-Prefixes defined for each ETR that may register, a Map-Server is typically also configured with one or more aggregate prefixes that define the part of the EID numbering space assigned to it. When LISP+ALT is the database in use, aggregate EID-Prefixes are implemented as discard routes and advertised into ALT BGP. The existence of aggregate EID-Prefixes in a Map-Server's database means that it may receive Map Requests for EID-Prefixes that match an aggregate but do not match a registered prefix; Section 4.3 describes how this is handled.
登録される可能性のある各ETRに対して定義されたEIDプレフィックスのセットに加えて、マップサーバーは通常、それに割り当てられたEIDナンバリングスペースの一部を定義する1つ以上の集約プレフィックスで構成されます。 LISP + ALTが使用中のデータベースである場合、集約EIDプレフィックスは廃棄ルートとして実装され、ALT BGPにアドバタイズされます。 Map-Serverのデータベースに集約EIDプレフィックスが存在するということは、集約に一致するが登録済みのプレフィックスには一致しないEIDプレフィックスに対するマップ要求を受け取る可能性があることを意味します。セクション4.3では、この処理方法について説明します。
Map-Register messages are sent periodically from an ETR to a Map-Server with a suggested interval between messages of one minute. A Map-Server should time out and remove an ETR's registration if it has not received a valid Map-Register message within the past three minutes. When first contacting a Map-Server after restart or changes to its EID-to-RLOC database mappings, an ETR may initially send Map-Register messages at an increased frequency, up to one every 20 seconds. This "quick registration" period is limited to five minutes in duration.
Map-Registerメッセージは、推奨されるメッセージ間隔を1分として、ETRからMap-Serverに定期的に送信されます。 Map-Serverは、過去3分以内に有効なMap-Registerメッセージを受信しなかった場合、タイムアウトしてETRの登録を削除する必要があります。再起動後、またはEIDからRLOCへのデータベースマッピングを変更した後、最初にMap-Serverに接続するとき、ETRは最初に最大20秒ごとに1回の頻度でMap-Registerメッセージを送信します。この「クイック登録」期間は、5分間に制限されています。
An ETR may request that a Map-Server explicitly acknowledge receipt and processing of a Map-Register message by setting the "want-map-notify" (M-bit) flag. A Map-Server that receives a Map-Register with this flag set will respond with a Map-Notify message. Typical use of this flag by an ETR would be to set it for Map-Register messages sent during the initial "quick registration" with a Map-Server but then set it only occasionally during steady-state maintenance of its association with that Map-Server. Note that the Map-Notify message is sent to UDP destination port 4342, not to the source port specified in the original Map-Register message.
ETRは、「want-map-notify」（Mビット）フラグを設定することにより、Map-ServerがMap-Registerメッセージの受信と処理を明示的に確認することを要求する場合があります。このフラグが設定されたMap-Registerを受信したMap-Serverは、Map-Notifyメッセージで応答します。 ETRによるこのフラグの一般的な用途は、Map-Serverとの最初の「クイック登録」中に送信されたMap-Registerメッセージに対して設定しますが、その後、そのMap-Serverとの関連付けの定常状態のメンテナンス中にのみ設定します。 Map-Notifyメッセージは、元のMap-Registerメッセージで指定された送信元ポートではなく、UDP宛先ポート4342に送信されることに注意してください。
Note that a one-minute minimum registration interval during maintenance of an ETR-Map-Server association places a lower bound on how quickly and how frequently a mapping database entry can be updated. This may have implications for what sorts of mobility can be supported directly by the mapping system; shorter registration intervals or other mechanisms might be needed to support faster mobility in some cases. For a discussion on one way that faster mobility may be implemented for individual devices, please see [LISP-MN].
ETR-Map-Serverアソシエーションのメンテナンス中の最小登録間隔は1分であり、マッピングデータベースエントリを更新できる速度と頻度に下限があることに注意してください。これは、どのような種類のモビリティがマッピングシステムによって直接サポートされるかについて、意味があるかもしれません。場合によっては、より高速なモビリティをサポートするために、より短い登録間隔または他のメカニズムが必要になることがあります。個々のデバイスに高速モビリティを実装する方法の1つについては、[LISP-MN]を参照してください。
An ETR may also request, by setting the "proxy Map-Reply" flag (P-bit) in the Map-Register message, that a Map-Server answer Map-Requests instead of forwarding them to the ETR. See [RFC6830] for details on how the Map-Server sets certain flags (such as those indicating whether the message is authoritative and how returned Locators should be treated) when sending a Map-Reply on behalf of an ETR. When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-Prefix being registered, along with the routable flag ("R-bit") setting for each RLOC. The Map-Server includes all of this information in Map-Reply messages that it sends on behalf of the ETR. This differs from a non-proxy registration, since the latter need only provide one or more RLOCs for a Map-Server to use for forwarding Map-Requests; the registration information is not used in Map-Replies, so it being incomplete is not incorrect.
ETRは、Map-Registerメッセージの「proxy Map-Reply」フラグ（Pビット）を設定することにより、Map-ServerがETRに転送する代わりにMap-Requestに応答することを要求する場合もあります。 ETRの代わりにMap-Replyを送信するときにMap-Serverが特定のフラグを設定する方法（メッセージが信頼できるかどうか、返されたロケーターをどのように処理する必要があるかなど）の詳細については、[RFC6830]を参照してください。 ETRがプロキシ応答サービスを要求する場合、登録されているEIDプレフィックスのすべてのETRのすべてのRLOCと、各RLOCのルーティング可能なフラグ（「Rビット」）設定を含める必要があります。 Map-Serverは、ETRの代わりに送信するMap-Replyメッセージにこのすべての情報を含めます。これは、非プロキシ登録とは異なります。後者は、Map-ServerがMap-Requestの転送に使用する1つ以上のRLOCを提供するだけでよいためです。登録情報はMap-Repliesでは使用されないため、不完全であることは間違いありません。
An ETR that uses a Map-Server to publish its EID-to-RLOC mappings does not need to participate further in the mapping database protocol(s). When using a LISP+ALT mapping database, for example, this means that the ETR does not need to implement GRE or BGP, which greatly simplifies its configuration and reduces its cost of operation.
Map-Serverを使用してEIDからRLOCへのマッピングを公開するETRは、マッピングデータベースプロトコルにさらに参加する必要はありません。たとえば、LISP + ALTマッピングデータベースを使用する場合、これは、ETRがGREまたはBGPを実装する必要がないことを意味します。これにより、構成が大幅に簡素化され、運用コストが削減されます。
Note that use of a Map-Server does not preclude an ETR from also connecting to the mapping database (i.e., it could also connect to the LISP+ALT network), but doing so doesn't seem particularly useful, as the whole purpose of using a Map-Server is to avoid the complexity of the mapping database protocols.
Map-Serverを使用しても、ETRがマッピングデータベースに接続することを妨げるものではないことに注意してください（つまり、LISP + ALTネットワークに接続することもできます）。ただし、これを行うことは、 Map-Serverを使用するのは、マッピングデータベースプロトコルの複雑さを回避するためです。
Once a Map-Server has EID-Prefixes registered by its client ETRs, it can accept and process Map-Requests for them.
Map-Serverは、クライアントETRによってEIDプレフィックスが登録されると、それらのMap-Requestを受け入れて処理できます。
In response to a Map-Request (received over the ALT if LISP+ALT is in use), the Map-Server first checks to see if the destination EID matches a configured EID-Prefix. If there is no match, the Map-Server returns a Negative Map-Reply with action code "Natively-Forward" and a 15-minute TTL. This may occur if a Map Request is received for a configured aggregate EID-Prefix for which no more-specific EID-Prefix exists; it indicates the presence of a non-LISP "hole" in the aggregate EID-Prefix.
Map-Request（LISP + ALTが使用されている場合はALTを介して受信）に応答して、Map-Serverはまず、宛先EIDが構成済みのEID-Prefixと一致するかどうかを確認します。一致がない場合、Map-Serverはアクションコード「Natively-Forward」と15分のTTLを含む否定のMap-Replyを返します。これは、特定のEIDプレフィックスが存在しない構成済みの集約EIDプレフィックスに対してマップ要求を受信した場合に発生する可能性があります。集約EIDプレフィックスに非LISP「ホール」が存在することを示します。
Next, the Map-Server checks to see if any ETRs have registered the matching EID-Prefix. If none are found, then the Map-Server returns a Negative Map-Reply with action code "Natively-Forward" and a 1-minute TTL.
次に、Map-Serverは、ETRが一致するEID-Prefixを登録しているかどうかを確認します。何も見つからない場合、Map-Serverはアクションコード「Natively-Forward」と1分のTTLを含む否定のMap-Replyを返します。
If any of the registered ETRs for the EID-Prefix have requested proxy reply service, then the Map-Server answers the request instead of forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, and other information learned through the registration process.
EIDプレフィックスに登録されているETRのいずれかがプロキシ応答サービスを要求した場合、Map-Serverは転送せずに要求に応答します。 EIDプレフィックス、RLOC、および登録プロセスで学習したその他の情報とともにMap-Replyを返します。
If none of the ETRs have requested proxy reply service, then the Map-Server re-encapsulates and forwards the resulting Encapsulated Map-Request to one of the registered ETRs. It does not otherwise alter the Map-Request, so any Map-Reply sent by the ETR is returned to the RLOC in the Map-Request, not to the Map-Server. Unless also acting as a Map-Resolver, a Map-Server should never receive Map-Replies; any such messages should be discarded without response, perhaps accompanied by the logging of a diagnostic message if the rate of Map-Replies is suggestive of malicious traffic.
どのETRもプロキシ応答サービスを要求していない場合、Map-Serverは再カプセル化し、結果のカプセル化Map-Requestを登録済みのETRの1つに転送します。それ以外の場合はMap-Requestを変更しないため、ETRによって送信されたMap-Replyは、Map-ServerではなくMap-RequestのRLOCに返されます。 Map-Resolverとしても機能している場合を除き、Map-ServerはMap-Repliesを受信してはなりません。このようなメッセージは、応答なしで破棄する必要があります。Map-Repliesのレートが悪意のあるトラフィックを示唆している場合は、おそらく診断メッセージのロギングも伴います。
Upon receipt of an Encapsulated Map-Request, a Map-Resolver decapsulates the enclosed message and then searches for the requested EID in its local database of mapping entries (statically configured or learned from associated ETRs if the Map-Resolver is also a Map-Server offering proxy reply service). If it finds a matching entry, it returns a LISP Map-Reply with the known mapping.
カプセル化されたMap-Requestを受信すると、Map-Resolverは囲まれたメッセージをカプセル化解除し、マッピングエントリのローカルデータベースで要求されたEIDを検索します（Map-ResolverがMap-Serverでもある場合、静的に構成されているか、関連するETRから学習しますプロキシ応答サービスの提供）。一致するエントリが見つかると、既知のマッピングでLISP Map-Replyを返します。
If the Map-Resolver does not have the mapping entry and if it can determine that the EID is not in the mapping database (for example, if LISP+ALT is used, the Map-Resolver will have an ALT forwarding table that covers the full EID space), it immediately returns a negative LISP Map-Reply, with action code "Natively-Forward" and a 15-minute TTL. To minimize the number of negative cache entries needed by an ITR, the Map-Resolver should return the least-specific prefix that both matches the original query and does not match any EID-Prefix known to exist in the LISP-capable infrastructure.
Map-Resolverにマッピングエントリがなく、EIDがマッピングデータベースにないことを判別できる場合（たとえば、LISP + ALTが使用されている場合、Map-Resolverには、完全にカバーするALT転送テーブルがあります。 EIDスペース）、アクションコード「Natively-Forward」と15分のTTLを使用して、負のLISP Map-Replyをすぐに返します。 ITRに必要なネガティブキャッシュエントリの数を最小限に抑えるため、Map-Resolverは、元のクエリに一致し、LISP対応のインフラストラクチャに存在することがわかっているEIDプレフィックスに一致しない、最も固有性の低いプレフィックスを返す必要があります。
If the Map-Resolver does not have sufficient information to know whether the EID exists, it needs to forward the Map-Request to another device that has more information about the EID being requested. To do this, it forwards the unencapsulated Map-Request, with the original ITR RLOC as the source, to the mapping database system. Using LISP+ALT, the Map-Resolver is connected to the ALT network and sends the Map-Request to the next ALT hop learned from its ALT BGP neighbors. The Map-Resolver does not send any response to the ITR; since the source RLOC is that of the ITR, the ETR or Map-Server that receives the Map-Request over the ALT and responds will do so directly to the ITR.
Map-ResolverがEIDが存在するかどうかを知るのに十分な情報を持っていない場合、Map-ResolverはMap-Requestを、要求されているEIDに関する詳細情報を持つ別のデバイスに転送する必要があります。これを行うには、元のITR RLOCをソースとして、カプセル化されていないMap-Requestをマッピングデータベースシステムに転送します。 LISP + ALTを使用して、Map-ResolverはALTネットワークに接続され、ALT-BGPネイバーから学習した次のALTホップにMap-Requestを送信します。 Map-ResolverはITRに応答を送信しません。ソースRLOCはITRのRLOCであるため、ALTを介してMap-Requestを受信して応答するETRまたはMap-Serverは、ITRに直接応答します。
A Map-Resolver can be set up to use "anycast", where the same address is assigned to multiple Map-Resolvers and is propagated through IGP routing, to facilitate the use of a topologically close Map-Resolver by each ITR.
Map-Resolverは、「anycast」を使用するように設定できます。この場合、同じアドレスが複数のMap-Resolverに割り当てられ、IGPルーティングを介して伝搬されるため、各ITRによるトポロジ的に近いMap-Resolverの使用が容易になります。
Note that Map-Server associations with ETRs should not use anycast addresses, as registrations need to be established between an ETR and a specific set of Map-Servers, each identified by a specific registration association.
ETRとMap-Serverの関連付けではエニーキャストアドレスを使用しないでください。ETRと特定の登録関連付けによって識別されるMap-Serverの特定のセット間で登録を確立する必要があるためです。
There are a number of issues with the Map-Server and Map-Resolver design that are not yet completely understood. Among these are:
Map-ServerおよびMap-Resolverの設計には、まだ完全には理解されていない多くの問題があります。これらの中で：
o Constants, such as those used for Map-Register frequency, retransmission timeouts, retransmission limits, Negative Map-Reply TTLs, et al. are subject to further refinement as more experience with prototype deployment is gained.
o Map-Registerの頻度、再送信のタイムアウト、再送信の制限、負のMap-Reply TTLなどに使用される定数など。プロトタイプの展開に関する経験が増えるにつれて、さらに改良が加えられます。
o Convergence time when an EID-to-RLOC mapping changes, and mechanisms for detecting and refreshing or removing stale, cached information.
o EIDからRLOCへのマッピングが変更されたときの収束時間、および古いキャッシュされた情報を検出および更新または削除するためのメカニズム。
o Deployability and complexity tradeoffs of implementing stronger security measures in both EID-Prefix registration and Map-Request/ Map-Reply processing.
o EID-Prefix登録とMap-Request / Map-Reply処理の両方でより強力なセキュリティ対策を実装することの導入可能性と複雑さのトレードオフ。
o Requirements for additional state in the registration process between Map-Servers and ETRs.
o Map-ServerとETR間の登録プロセスにおける追加の状態の要件。
A discussion of other issues surrounding LISP deployment may also be found in Section 15 of [RFC6830].
LISPの導入を取り巻くその他の問題については、[RFC6830]のセクション15でも説明されています。
The authors expect that experimentation on the LISP pilot network will help answer open questions surrounding these and other issues.
著者は、LISPパイロットネットワークでの実験が、これらの問題やその他の問題に関する未解決の質問への回答に役立つことを期待しています。
The 2-way LISP header nonce exchange documented in [RFC6830] can be used to avoid ITR spoofing attacks.
[RFC6830]で文書化されている双方向LISPヘッダーナンス交換を使用して、ITRスプーフィング攻撃を回避できます。
To publish an authoritative EID-to-RLOC mapping with a Map-Server, an ETR includes authentication data that is a hash of the message using a pair-wise shared key. An implementation must support use of HMAC-SHA-1-96 [RFC2104] and should support use of HMAC-SHA-256-128 [RFC6234] (SHA-256 truncated to 128 bits).
Map-Serverで信頼できるEIDからRLOCへのマッピングを公開するために、ETRにはペアワイズ共有キーを使用したメッセージのハッシュである認証データが含まれています。実装は、HMAC-SHA-1-96 [RFC2104]の使用をサポートする必要があり、HMAC-SHA-256-128 [RFC6234]（128ビットに切り捨てられたSHA-256）の使用をサポートする必要があります。
During experimental and prototype deployment, all authentication key configuration will be manual. Should LISP and its components be considered for IETF standardization, further work will be required to follow the BCP 107 [RFC4107] recommendations on automated key management.
実験的およびプロトタイプの展開中、すべての認証キーの設定は手動で行われます。 LISPとそのコンポーネントがIETF標準化のために考慮される場合、自動化されたキー管理に関するBCP 107 [RFC4107]勧告に従うためにさらなる作業が必要になります。
As noted in Section 4.2, a Map-Server should verify that all EID-Prefixes registered by an ETR match the configuration stored on the Map-Server.
セクション4.2で説明したように、Map-Serverは、ETRによって登録されたすべてのEIDプレフィックスがMap-Serverに保存されている構成と一致することを確認する必要があります。
The currently defined authentication mechanism for Map-Register messages does not provide protection against "replay" attacks by a "man-in-the-middle". Additional work is needed in this area.
Map-Registerメッセージに対して現在定義されている認証メカニズムは、「中間者」による「リプレイ」攻撃に対する保護を提供しません。この領域では追加の作業が必要です。
[LISP-SEC] defines a proposed mechanism for providing origin authentication, integrity, anti-replay protection, and prevention of man-in-the-middle and "overclaiming" attacks on the Map-Request/ Map-Reply exchange. Work is ongoing on this and other proposals for resolving these open security issues.
[LISP-SEC]は、オリジン認証、整合性、リプレイ防止保護、および中間者攻撃とMap-Request / Map-Reply交換に対する「過剰要求」攻撃の防止を提供するために提案されたメカニズムを定義しています。これらの未解決のセキュリティ問題を解決するためのこの提案やその他の提案については作業が進行中です。
While beyond the scope of securing an individual Map-Server or Map-Resolver, it should be noted that a BGP-based LISP+ALT network (if ALT is used as the mapping database infrastructure) can take advantage of standards work on adding security to BGP.
個々のMap-ServerまたはMap-Resolverを保護する範囲を超えていますが、BGPベースのLISP + ALTネットワーク（ALTがマッピングデータベースインフラストラクチャとして使用されている場合）は、セキュリティを追加するための標準作業を利用できることに注意してください。 BGP。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC6234] Eastlake、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、2011年5月。
[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月。
[LISP-CONS] Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", Work in Progress, April 2008.
[LISP-CONS]ブリム、S。、チアッパ、N。、ファリナッチ、D。、フラー、V。、ルイス、D。、およびD.マイヤー、「LISP-CONS：LISPのコンテンツ配信オーバーレイネットワークサービス」、進行中の作業、2008年4月。
[LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", Work in Progress, October 2012.
[LISP-MN] Farinacci、D.、Lewis、D.、Meyer、D。、およびC. White、「LISP Mobile Node」、Work in Progress、2012年10月。
[LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., Saucez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", Work in Progress, October 2012.
[LISP-SEC] Maino、F.、Ermagan、V.、Cabellos、A.、Saucez、D。、およびO. Bonaventure、「LISP-Security（LISP-SEC）」、Work in Progress、2012年10月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin、S。およびR. Housley、「暗号鍵管理のガイドライン」、BCP 107、RFC 4107、2005年6月。
[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月。
The authors would like to thank Gregg Schudel, Darrel Lewis, John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, Fabio Maino, and members of the lisp@ietf.org mailing list for their feedback and helpful suggestions.
著者らは、Gregg Schudel、Darrel Lewis、John Zwiebel、Andrew Partan、Dave Meyer、Isidor Kouvelas、Jesper Skriver、Fabio Maino、およびlisp@ietf.orgメーリングリストのメンバーにフィードバックと役立つ提案を提供してくれたことに感謝します。
Special thanks are due to Noel Chiappa for his extensive work on caching with LISP-CONS, some of which may be used by Map-Resolvers.
Noel ChiappaがLISP-CONSでのキャッシングに関する広範な作業を行ったことに特に感謝します。その一部はMap-Resolversで使用される場合があります。
Authors' Addresses
著者のアドレス
Vince Fuller
ヴィンスフラー
EMail: vaf@vaf.net
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