[要約] RFC 6830は、Locator/ID Separation Protocol（LISP）に関する標準化文書です。LISPは、インターネットのスケーラビリティとセキュリティを向上させるために、IPアドレスとロケータ（Locator）を分離するプロトコルです。このRFCの目的は、LISPの仕様と利点を説明し、実装と展開のためのガイダンスを提供することです。
Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 6830 Cisco Systems
Category: Experimental V. Fuller
ISSN: 2070-1721
D. Meyer
D. Lewis
Cisco Systems
January 2013
The Locator/ID Separation Protocol (LISP)
ロケータ/ ID分離プロトコル（LISP）
Abstract
概要
This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offers Traffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.
このドキュメントでは、IPアドレスを2つの新しい番号付けスペースに分割できるネットワークレイヤーベースのプロトコルについて説明します。エンドポイント識別子（EID）とルーティングロケーター（RLOC）です。ホストプロトコルスタックまたはインターネットインフラストラクチャの「コア」を変更する必要はありません。 Locator / ID Separation Protocol（LISP）は、「フラグデー」なしで段階的に展開でき、LISP対応のサイトが比較的少ない場合でも、トラフィックエンジニアリング、マルチホーミング、およびモビリティの利点をアーリーアダプターに提供します。
Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop.
LISPの設計と開発は、2006年10月のIAB Routing and Addressing Workshopによって作成された問題ステートメントによって主に動機付けられました。
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/rfc6830.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6830で入手できます。
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. Requirements Notation ...........................................5
3. Definition of Terms .............................................5
4. Basic Overview .................................................10
4.1. Packet Flow Sequence ......................................13
5. LISP Encapsulation Details .....................................15
5.1. LISP IPv4-in-IPv4 Header Format ...........................16
5.2. LISP IPv6-in-IPv6 Header Format ...........................17
5.3. Tunnel Header Field Descriptions ..........................18
5.4. Dealing with Large Encapsulated Packets ...................22
5.4.1. A Stateless Solution to MTU Handling ...............22
5.4.2. A Stateful Solution to MTU Handling ................23
5.5. Using Virtualization and Segmentation with LISP ...........24
6. EID-to-RLOC Mapping ............................................25
6.1. LISP IPv4 and IPv6 Control-Plane Packet Formats ...........25
6.1.1. LISP Packet Type Allocations .......................27
6.1.2. Map-Request Message Format .........................27
6.1.3. EID-to-RLOC UDP Map-Request Message ................30
6.1.4. Map-Reply Message Format ...........................31
6.1.5. EID-to-RLOC UDP Map-Reply Message ..................35
6.1.6. Map-Register Message Format ........................37
6.1.7. Map-Notify Message Format ..........................39
6.1.8. Encapsulated Control Message Format ................41
6.2. Routing Locator Selection .................................42
6.3. Routing Locator Reachability ..............................44
6.3.1. Echo Nonce Algorithm ...............................46
6.3.2. RLOC-Probing Algorithm .............................48
6.4. EID Reachability within a LISP Site .......................49
6.5. Routing Locator Hashing ...................................49
6.6. Changing the Contents of EID-to-RLOC Mappings .............50
6.6.1. Clock Sweep ........................................51
6.6.2. Solicit-Map-Request (SMR) ..........................52
6.6.3. Database Map-Versioning ............................53
7. Router Performance Considerations ..............................54
8. Deployment Scenarios ...........................................55
8.1. First-Hop/Last-Hop Tunnel Routers .........................56
8.2. Border/Edge Tunnel Routers ................................56
8.3. ISP Provider Edge (PE) Tunnel Routers .....................57
8.4. LISP Functionality with Conventional NATs .................58
8.5. Packets Egressing a LISP Site .............................58
9. Traceroute Considerations ......................................58
9.1. IPv6 Traceroute ...........................................59
9.2. IPv4 Traceroute ...........................................60
9.3. Traceroute Using Mixed Locators ...........................60
10. Mobility Considerations .......................................61
10.1. Site Mobility ............................................61
10.2. Slow Endpoint Mobility ...................................61
10.3. Fast Endpoint Mobility ...................................61
10.4. Fast Network Mobility ....................................63
10.5. LISP Mobile Node Mobility ................................64
11. Multicast Considerations ......................................64
12. Security Considerations .......................................65
13. Network Management Considerations .............................67
14. IANA Considerations ...........................................67
14.1. LISP ACT and Flag Fields .................................67
14.2. LISP Address Type Codes ..................................68
14.3. LISP UDP Port Numbers ....................................68
14.4. LISP Key ID Numbers ......................................68
15. Known Open Issues and Areas of Future Work ....................68
16. References ....................................................70
16.1. Normative References .....................................70
16.2. Informative References ...................................71
Appendix A. Acknowledgments .......................................74
This document describes the Locator/Identifier Separation Protocol (LISP), which provides a set of functions for routers to exchange information used to map from Endpoint Identifiers (EIDs) that are not globally routable to routable Routing Locators (RLOCs). It also defines a mechanism for these LISP routers to encapsulate IP packets addressed with EIDs for transmission across a network infrastructure that uses RLOCs for routing and forwarding.
このドキュメントでは、ルーターがルーティング可能なルーティングロケーター（RLOC）にグローバルにルーティングできないエンドポイント識別子（EID）からマップするために使用される情報をルーターが交換するための一連の機能を提供するロケーター/識別子分離プロトコル（LISP）について説明します。また、ルーティングと転送にRLOCを使用するネットワークインフラストラクチャ全体に送信するために、これらのLISPルーターがEIDでアドレス指定されたIPパケットをカプセル化するメカニズムも定義します。
Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October 2006 (see [RFC4984]). A key conclusion of the workshop was that the Internet routing and addressing system was not scaling well in the face of the explosive growth of new sites; one reason for this poor scaling is the increasing number of multihomed sites and other sites that cannot be addressed as part of topology-based or provider-based aggregated prefixes. Additional work that more completely describes the problem statement may be found in [RADIR].
LISPの作成は、2006年10月にアムステルダムで開催されたIAB主催のルーティングとアドレス指定ワークショップ（[RFC4984]を参照）での議論によって最初に動機付けられました。ワークショップの主な結論は、インターネットのルーティングとアドレス指定システムは、新しいサイトの爆発的な成長に直面してうまく拡張できなかったということでした。この不十分なスケーリングの理由の1つは、トポロジベースまたはプロバイダーベースの集約プレフィックスの一部として対処できないマルチホームサイトやその他のサイトの数の増加です。問題の記述をより完全に説明する追加の作業が[RADIR]にあります。
A basic observation, made many years ago in early networking research such as that documented in [CHIAPPA] and [RFC4984], is that using a single address field for both identifying a device and for determining where it is topologically located in the network requires optimization along two conflicting axes: for routing to be efficient, the address must be assigned topologically; for collections of devices to be easily and effectively managed, without the need for renumbering in response to topological change (such as that caused by adding or removing attachment points to the network or by mobility events), the address must explicitly not be tied to the topology.
[CHIAPPA]や[RFC4984]で文書化されているような初期のネットワーキング研究で何年も前に行われた基本的な観察は、デバイスの識別とネットワーク内のトポロジー上の場所の特定の両方に単一のアドレスフィールドを使用することは最適化を必要とするということです2つの矛盾する軸に沿って：ルーティングを効率的にするには、アドレスをトポロジー的に割り当てる必要があります。デバイスのコレクションを簡単かつ効果的に管理するには、トポロジの変更（ネットワークへの接続ポイントの追加や削除、またはモビリティイベントによる変更など）に応じて番号を付け直す必要がないため、アドレスを明示的に関連付けないでください。トポロジー。
The approach that LISP takes to solving the routing scalability problem is to replace IP addresses with two new types of numbers: Routing Locators (RLOCs), which are topologically assigned to network attachment points (and are therefore amenable to aggregation) and used for routing and forwarding of packets through the network; and Endpoint Identifiers (EIDs), which are assigned independently from the network topology, are used for numbering devices, and are aggregated along administrative boundaries. LISP then defines functions for mapping between the two numbering spaces and for encapsulating traffic originated by devices using non-routable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. Both RLOCs and EIDs are syntactically identical to IP addresses; it is the semantics of how they are used that differs.
LISPがルーティングのスケーラビリティの問題を解決するために使用するアプローチは、IPアドレスを2つの新しいタイプの番号で置き換えることです。ルーティングロケーター（RLOC）は、トポロジー的にネットワーク接続ポイントに割り当てられ（したがって、集約に適しています）、ルーティングとルーティングに使用されます。ネットワークを介したパケットの転送。エンドポイント識別子（EID）は、ネットワークトポロジとは別に割り当てられ、デバイスの番号付けに使用され、管理境界に沿って集約されます。次に、LISPは、2つの番号付けスペース間のマッピング機能と、RLOCを使用してルーティングおよび転送するネットワークインフラストラクチャ全体で転送するためにルーティング不可能なEIDを使用するデバイスから発信されたトラフィックをカプセル化する機能を定義します。 RLOCとEIDはどちらも構文的にIPアドレスと同じです。それらがどのように使用されるかという意味は異なります。
This document describes the protocol that implements these functions. The database that stores the mappings between EIDs and RLOCs is explicitly a separate "module" to facilitate experimentation with a variety of approaches. One database design that is being developed for experimentation as part of the LISP working group work is [RFC6836]. Others that have been described include [CONS], [EMACS], and [RFC6837]. Finally, [RFC6833] documents a general-purpose service interface for accessing a mapping database; this interface is intended to make the mapping database modular so that different approaches can be tried without the need to modify installed LISP-capable devices in LISP sites.
このドキュメントでは、これらの機能を実装するプロトコルについて説明します。 EIDとRLOCの間のマッピングを格納するデータベースは、さまざまなアプローチでの実験を容易にするために、明らかに別個の「モジュール」です。 LISPワーキンググループの作業の一部として実験用に開発されているデータベース設計の1つは、[RFC6836]です。説明されている他のものには、[CONS]、[EMACS]、および[RFC6837]が含まれます。最後に、[RFC6833]は、マッピングデータベースにアクセスするための汎用サービスインターフェイスを文書化しています。このインターフェイスは、マッピングデータベースをモジュール化することを目的としているため、LISPサイトにインストールされているLISP対応デバイスを変更する必要なく、さまざまなアプローチを試すことができます。
This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation.
この実験仕様には、追加の経験と測定が必要な領域があります。実験的な状況を超えた展開にはお勧めしません。実験の結果は、このドキュメントで定義されているプロトコルメカニズムの変更と拡張につながる可能性があります。開発、実装、実験中にさらに作業が必要な特定の既知の問題については、セクション15を参照してください。
An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on.
LISPがインターネットトラフィック、アプリケーション、ルーター、およびセキュリティに与える影響の調査は、今後の検討課題です。この分析では、スケーラブルルーティングでLISPが果たす役割について説明し、カプセル化、カプセル化解除、活性などに必要なスケーラビリティと状態レベルについても説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Provider-Independent (PI) Addresses: PI addresses are an address block assigned from a pool where blocks are not associated with any particular location in the network (e.g., from a particular service provider) and are therefore not topologically aggregatable in the routing system.
プロバイダーに依存しない（PI）アドレス：PIアドレスは、ブロックがネットワーク内の特定の場所（特定のサービスプロバイダーなど）に関連付けられていないプールから割り当てられたアドレスブロックであり、ルーティングシステムでトポロジ的に集約できません。
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に使用するため、これは明らかにスケーラブルではありません。
Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 [RFC2460] address of an Egress Tunnel Router (ETR). An RLOC 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; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site.
ルーティングロケータ（RLOC）：RLOCは、出力トンネルルーター（ETR）のIPv4 [RFC0791]またはIPv6 [RFC2460]アドレスです。 RLOCは、EIDからRLOCへのマッピングルックアップの出力です。 EIDは1つ以上のRLOCにマップします。通常、RLOCは、グローバルインターネットに接続する各ポイントでサイトに割り当てられるトポロジ的に集約可能なブロックから番号が付けられます。トポロジがプロバイダーネットワークの接続性によって定義される場合、RLOCはPAアドレスと考えることができます。複数のRLOCを同じETRデバイスまたはサイトの複数のETRデバイスに割り当てることができます。
Endpoint ID (EID): An EID is 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 Domain Name System (DNS) [RFC1034] lookup or Session Initiation Protocol (SIP) [RFC3261] exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID used on the public Internet must have the same properties as any other IP address used in that manner; this means, among other things, that it must be globally unique. 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. In theory, the bit string that represents an EID for one device can represent an RLOC for a different device. As the architecture is realized, if a given bit string is both an RLOC and an EID, it must refer to the same entity in both cases. When used in discussions with other Locator/ID separation proposals, a LISP EID will be called an "LEID". Throughout this document, any references to "EID" refer to an LEID.
エンドポイントID（EID）：EIDは、パケットの最初（最も内側）のLISPヘッダーの送信元および宛先アドレスフィールドで使用される32ビット（IPv4の場合）または128ビット（IPv6の場合）の値です。ホストは、たとえばドメインネームシステム（DNS）[RFC1034]ルックアップまたはセッション開始プロトコル（SIP）[RFC3261]交換を介して、宛先アドレスを取得するのと同じ方法で宛先EIDを取得します。ソースEIDは、ホストの「ローカル」IPアドレスを設定するために使用される既存のメカニズムを介して取得されます。パブリックインターネットで使用されるEIDは、その方法で使用される他のIPアドレスと同じプロパティを持つ必要があります。これは、とりわけ、グローバルに一意でなければならないことを意味します。 EIDは、ホストが配置されているサイトに関連付けられているEID-Prefixブロックからホストに割り当てられます。ホストは、EIDを使用して他のホストを参照できます。 EIDはLISP RLOCとして使用してはなりません。 EIDブロックは、マッピングデータベースのスケーリングを容易にするために、ネットワークトポロジーとは関係なく、階層的に割り当てることができることに注意してください。さらに、サイトに割り当てられたEIDブロックには、サイト内でルーティングするためのサイトローカル構造（サブネット化）がある場合があります。この構造は、グローバルルーティングシステムからは見えません。理論的には、あるデバイスのEIDを表すビット文字列は、別のデバイスのRLOCを表すことができます。アーキテクチャが実現されると、特定のビット文字列がRLOCとEIDの両方である場合、どちらの場合も同じエンティティを参照する必要があります。他のロケーター/ ID分離提案との議論で使用される場合、LISP EIDは「LEID」と呼ばれます。このドキュメント全体を通して、「EID」への言及はすべてLEIDを指します。
EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are allocated to a site by an address allocation authority. EID-Prefixes are associated with a set of RLOC addresses that make up a "database mapping". EID-Prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the larger EID-Prefix block. A globally routed address block (whether PI or PA) is not inherently an EID-Prefix. A globally routed address block MAY be used by its assignee as an EID block. The converse is not supported. That is, a site that receives an explicitly allocated EID-Prefix may not use that EID-Prefix as a globally routed prefix. This would require coordination and cooperation with the entities managing the mapping infrastructure. Once this has been done, that block could be removed from the globally routed IP system, if other suitable transition and access mechanisms are in place. Discussion of such transition and access mechanisms can be found in [RFC6832] and [LISP-DEPLOY].
EIDプレフィックス：EIDプレフィックスは、アドレス割り当て機関によってサイトに割り当てられるEIDの2のべき乗ブロックです。 EIDプレフィックスは、「データベースマッピング」を構成するRLOCアドレスのセットに関連付けられています。 RLOCセットがより大きなEID-Prefixブロックに関連付けられる場合、EID-Prefix割り当てはより小さなブロックに分割できます。グローバルにルーティングされるアドレスブロック（PIまたはPA）は、本質的にEIDプレフィックスではありません。グローバルにルーティングされたアドレスブロックは、EIDブロックとして割り当て先によって使用される場合があります。逆はサポートされていません。つまり、明示的に割り当てられたEIDプレフィックスを受信するサイトは、そのEIDプレフィックスをグローバルにルーティングされるプレフィックスとして使用できません。これには、マッピングインフラストラクチャを管理するエンティティとの調整と協力が必要になります。これが完了すると、他の適切な移行およびアクセスメカニズムが導入されている場合、そのブロックをグローバルにルーティングされたIPシステムから削除できます。このような移行とアクセスのメカニズムについての議論は、[RFC6832]と[LISP-DEPLOY]にあります。
End-system: An end-system is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP header when communicating globally (i.e., outside of its routing domain). An end-system can be a host computer, a switch or router device, or any network appliance.
エンドシステム：エンドシステムは、単一のIPv4またはIPv6ヘッダーを持つパケットを発信するIPv4またはIPv6デバイスです。エンドシステムは、グローバルに（つまり、ルーティングドメインの外部で）通信するときに、IPヘッダーの宛先アドレスフィールドにEID値を提供します。エンドシステムは、ホストコンピューター、スイッチまたはルーターデバイス、または任意のネットワークアプライアンスです。
Ingress Tunnel Router (ITR): An ITR is a router that resides in a LISP site. Packets sent by sources inside of the LISP site to destinations outside of the site are candidates for encapsulation by the ITR. The ITR treats the 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は、LISPサイトに存在するルーターです。 LISPサイト内の送信元からサイト外の宛先に送信されるパケットは、ITRによるカプセル化の候補です。 ITRはIP宛先アドレスをEIDとして扱い、EIDからRLOCへのマッピング検索を実行します。次に、ルーターは、「外部」IPヘッダーの先頭に、グローバルにルーティング可能なRLOCの1つを送信元アドレスフィールドに追加し、マッピング検索の結果を宛先アドレスフィールドに追加します。この宛先RLOCは、宛先EIDに近いEIDからRLOCへのマッピングについてより良い知識を持つ中間プロキシデバイスである場合があります。一般に、ITRは一方のサイトのエンドシステムからIPパケットを受信し、LISPカプセル化されたIPパケットをもう一方のインターネットに送信します。
Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router that does this is also regarded as an ITR. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or the inner destination address (the originating host's supplied EID).
具体的には、サービスプロバイダーがトラフィックエンジニアリングの目的でLISPヘッダーを付加する場合、これを行うルータもITRと見なされます。 ISP ITRが使用する外部RLOCは、外部宛先アドレス（元のITRが提供するRLOC）または内部宛先アドレス（元のホストが提供するEID）に基づくことができます。
TE-ITR: A TE-ITR is an ITR that is deployed in a service provider network that prepends an additional LISP header for Traffic Engineering purposes.
TE-ITR：TE-ITRは、トラフィックエンジニアリングの目的で追加のLISPヘッダーを付加するサービスプロバイダーネットワークに展開されるITRです。
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トンネルのエンドポイントにもなります。
TE-ETR: A TE-ETR is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes.
TE-ETR：TE-ETRは、トラフィックエンジニアリングの目的で外部LISPヘッダーを取り除くサービスプロバイダーネットワークに導入されるETRです。
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 and is used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router" indicates both ITR and ETR functionality at the CE router.
xTR：xTRは、データフローの方向がコンテキストの説明に含まれていない場合のITRまたはETRへの参照です。 「xTR」は、トンネルエンドポイントであり、「トンネルルーター」という用語と同義で使用されるルーターを指します。たとえば、「xTRはカスタマーエッジ（CE）ルーターに配置できます」は、CEルーターのITR機能とETR機能の両方を示します。
LISP Router: A LISP router is a router that performs the functions of any or all of the following: ITR, ETR, Proxy-ITR (PITR), or Proxy-ETR (PETR).
LISPルーター：LISPルーターは、ITR、ETR、Proxy-ITR（PITR）、またはProxy-ETR（PETR）のいずれかまたはすべての機能を実行するルーターです。
EID-to-RLOC Cache: The EID-to-RLOC Cache is 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; it 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へのキャッシュ：EIDからRLOCへのキャッシュは、ITR内の存続期間の短いオンデマンドテーブルであり、EIDからRLOCへのマッピングを保存および追跡し、タイムアウトなどの検証を行います。このキャッシュは、EIDからRLOCへのマッピングの完全な「データベース」とは異なります。これは動的で、ITRに対してローカルで比較的小さいですが、データベースは分散されており、比較的静的で、スコープははるかにグローバルです。
EID-to-RLOC Database: The EID-to-RLOC Database is 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. The same database mapping entries MUST be configured on all ETRs for a given site. In a steady state, the EID-Prefixes for the site and the Locator-Set for each EID-Prefix MUST be the same on all ETRs. Procedures to enforce and/or verify this are outside the scope of this document. Note that there MAY be transient conditions when the EID-Prefix for the site and Locator-Set for each EID-Prefix may not be the same on all ETRs. This has no negative implications, since a partial set of Locators can be used.
EID-to-RLOCデータベース：EID-to-RLOCデータベースは、すべての既知のEID-Prefix-to-RLOCマッピングを含むグローバル分散データベースです。通常、潜在的な各ETRには、データベースの小さな断片が含まれています。ルーターの「背後にある」EIDプレフィックスのEIDからRLOCへのマッピングです。これらは、ルーター自身のグローバルに表示されるIPアドレスの1つにマッピングされます。同じデータベースマッピングエントリは、特定のサイトのすべてのETRで構成する必要があります。定常状態では、サイトのEIDプレフィックスと各EIDプレフィックスのロケーターセットは、すべてのETRで同じでなければなりません。これを実施または確認する手順は、このドキュメントの範囲外です。サイトのEIDプレフィックスと各EIDプレフィックスのLocator-SetがすべてのETRで同じでない可能性がある場合、一時的な状態になる可能性があることに注意してください。ロケーターの部分的なセットを使用できるため、これには悪影響はありません。
Recursive Tunneling: Recursive Tunneling occurs when a packet has more than one LISP IP header. Additional layers of tunneling MAY be employed to implement Traffic Engineering or other re-routing as needed. When this is done, an additional "outer" LISP header is added, and the original RLOCs are preserved in the "inner" header. Any references to tunnels in this specification refer to dynamic encapsulating tunnels; they are never statically configured.
再帰的トンネリング：再帰的トンネリングは、パケットに複数のLISP IPヘッダーがある場合に発生します。必要に応じて、トラフィックエンジニアリングやその他の再ルーティングを実装するために、トンネリングの追加レイヤーを使用できます。これが行われると、追加の「外部」LISPヘッダーが追加され、元のRLOCは「内部」ヘッダーに保持されます。この仕様におけるトンネルへの言及は、動的カプセル化トンネルを指します。それらが静的に構成されることはありません。
Re-encapsulating Tunnels: Re-encapsulating Tunneling occurs when an ETR removes a LISP header, then acts as an ITR to prepend another LISP header. Doing this allows a packet to be re-routed by the re-encapsulating router without adding the overhead of additional tunnel headers. Any references to tunnels in this specification refer to dynamic encapsulating tunnels; they are never statically configured. When using multiple mapping database systems, care must be taken to not create re-encapsulation loops through misconfiguration.
再カプセル化トンネル：ETRがLISPヘッダーを削除すると、再カプセル化トンネルが発生し、ITRとして機能して別のLISPヘッダーを付加します。これにより、追加のトンネルヘッダーのオーバーヘッドを追加することなく、再カプセル化ルーターによってパケットを再ルーティングできます。この仕様におけるトンネルへの言及は、動的カプセル化トンネルを指します。それらが静的に構成されることはありません。複数のマッピングデータベースシステムを使用する場合、設定ミスによって再カプセル化ループが作成されないように注意する必要があります。
LISP Header: LISP header is a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-octet header that follow the UDP header and that an ITR prepends or an ETR strips.
LISPヘッダー：LISPヘッダーは、このドキュメントで使用されている用語で、外側のIPv4またはIPv6ヘッダー、UDPヘッダー、UDPヘッダーに続くLISP固有の8オクテットヘッダーを指し、ITRが付加またはETRストリップします。
Address Family Identifier (AFI): AFI is a term used to describe an address encoding in a packet. An address family currently pertains to an IPv4 or IPv6 address. See [AFI] and [RFC3232] for details. An AFI value of 0 used in this specification indicates an unspecified encoded address where the length of the address is 0 octets following the 16-bit AFI value of 0.
アドレスファミリ識別子（AFI）：AFIは、パケット内のアドレスエンコーディングを説明するために使用される用語です。アドレスファミリは現在、IPv4またはIPv6アドレスに関連しています。詳細については、[AFI]および[RFC3232]を参照してください。この仕様で使用されるAFI値0は、16ビットのAFI値0に続くアドレスの長さが0オクテットである、未指定のエンコードされたアドレスを示します。
Negative Mapping Entry: A negative mapping entry, also known as a negative cache entry, is an EID-to-RLOC entry where an EID-Prefix is advertised or stored with no RLOCs. That is, the Locator-Set for the EID-to-RLOC entry is empty or has an encoded Locator count of 0. This type of entry could be used to describe a prefix from a non-LISP site, which is explicitly not in the mapping database. There are a set of well-defined actions that are encoded in a Negative Map-Reply (Section 6.1.5).
ネガティブマッピングエントリ：ネガティブキャッシュエントリとも呼ばれるネガティブマッピングエントリは、EID-Prefixがアドバタイズされるか、RLOCなしで格納されるEID-to-RLOCエントリです。つまり、EIDからRLOCへのエントリのロケータセットが空であるか、エンコードされたロケータカウントが0です。このタイプのエントリは、非LISPサイトからのプレフィックスを記述するために使用できます。マッピングデータベース。 Negative Map-Reply（セクション6.1.5）でエンコードされた明確に定義されたアクションのセットがあります。
Data-Probe: A Data-Probe is a LISP-encapsulated data packet where the inner-header destination address equals the outer-header destination address used to trigger a Map-Reply by a decapsulating ETR. In addition, the original packet is decapsulated and delivered to the destination host if the destination EID is in the EID-Prefix range configured on the ETR. Otherwise, the packet is discarded. A Data-Probe is used in some of the mapping database designs to "probe" or request a Map-Reply from an ETR; in other cases, Map-Requests are used. See each mapping database design for details. When using Data-Probes, by sending Map-Requests on the underlying routing system, EID-Prefixes must be advertised. However, this is discouraged if the core is to scale by having less EID-Prefixes stored in the core router's routing tables.
Data-Probe：Data-ProbeはLISPカプセル化データパケットであり、内部ヘッダー宛先アドレスは、カプセル化解除ETRによってMap-Replyをトリガーするために使用される外部ヘッダー宛先アドレスと同じです。さらに、宛先EIDがETRで構成されたEIDプレフィックスの範囲内にある場合、元のパケットはカプセル化が解除され、宛先ホストに配信されます。それ以外の場合、パケットは破棄されます。一部のマッピングデータベース設計では、Data-Probeを使用して、ETRを「プローブ」またはMap-Replyを要求します。その他の場合は、Map-Requestsが使用されます。詳細については、各マッピングデータベースの設計を参照してください。 Data-Probesを使用する場合、基盤となるルーティングシステムでMap-Requestを送信することにより、EID-Prefixesをアドバタイズする必要があります。ただし、コアルータのルーティングテーブルに格納されるEIDプレフィックスを少なくしてコアをスケーリングする場合、これはお勧めできません。
Proxy-ITR (PITR): A PITR 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は[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サイトに代わって機能します。
Route-returnability: Route-returnability is an assumption that the underlying routing system will deliver packets to the destination. When combined with a nonce that is provided by a sender and returned by a receiver, this limits off-path data insertion. A route-returnability check is verified when a message is sent with a nonce, another message is returned with the same nonce, and the destination of the original message appears as the source of the returned message.
ルートの戻り性：ルートの戻り性は、基盤となるルーティングシステムがパケットを宛先に配信することを前提としています。送信側から提供され、受信側から返されるナンスと組み合わせると、オフパスデータ挿入が制限されます。メッセージがノンスで送信され、同じノンスで別のメッセージが返され、元のメッセージの宛先が返されたメッセージのソースとして表示される場合、ルートの戻り可能性チェックが検証されます。
LISP site: LISP site is a set of routers in an edge network that are under a single technical administration. LISP routers that reside in the edge network are the demarcation points to separate the edge network from the core network.
LISPサイト：LISPサイトは、単一の技術管理下にあるエッジネットワーク内のルーターのセットです。エッジネットワークにあるLISPルータは、エッジネットワークをコアネットワークから分離する境界ポイントです。
Client-side: Client-side is a term used in this document to indicate a connection initiation attempt by an EID. The ITR(s) at the LISP site are the first to get involved in obtaining database Map-Cache entries by sending Map-Request messages.
クライアント側：クライアント側は、このドキュメントでEIDによる接続開始の試みを示すために使用される用語です。 LISPサイトのITRは、Map-Requestメッセージを送信してデータベースMap-Cacheエントリを取得する最初の人です。
Server-side: Server-side is a term used in this document to indicate that a connection initiation attempt is being accepted for a destination EID. The ETR(s) at the destination LISP site are the first to send Map-Replies to the source site initiating the connection. The ETR(s) at this destination site can obtain mappings by gleaning information from Map-Requests, Data-Probes, or encapsulated packets.
サーバー側：サーバー側は、このドキュメントで使用されている用語であり、接続の開始試行が宛先EIDに対して受け入れられていることを示します。宛先LISPサイトのETRは、最初にMap-Repliesをソースサイトに送信して、接続を開始します。この宛先サイトのETRは、Map-Requests、Data-Probes、またはカプセル化されたパケットから情報を収集することにより、マッピングを取得できます。
Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the LISP header. They are used by ITRs to inform ETRs about the up/ down status of all ETRs at the local site. These bits are used as a hint to convey up/down router status and not path reachability status. The LSBs can be verified by use of one of the Locator reachability algorithms described in Section 6.3.
Locator-Status-Bits（LSBs）：Locator-Status-BitsはLISPヘッダーに存在します。これらはITRによって使用され、ローカルサイトのすべてのETRのアップ/ダウンステータスについてETRに通知します。これらのビットは、パスの到達可能性ステータスではなく、ルータのアップ/ダウンステータスを伝えるためのヒントとして使用されます。 LSBは、セクション6.3で説明されているロケーター到達可能性アルゴリズムの1つを使用して確認できます。
Anycast Address: Anycast Address is a term used in this document to refer to the same IPv4 or IPv6 address configured and used on multiple systems at the same time. An EID or RLOC can be an anycast address in each of their own address spaces.
エニーキャストアドレス：エニーキャストアドレスは、このドキュメントで使用される用語であり、同時に複数のシステムで構成および使用される同じIPv4またはIPv6アドレスを指します。 EIDまたはRLOCは、それぞれ独自のアドレススペース内のエニーキャストアドレスにすることができます。
One key concept of LISP is that end-systems (hosts) operate the same way they do today. The IP addresses that hosts use for tracking sockets and connections, and for sending and receiving packets, do not change. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs).
LISPの重要な概念の1つは、エンドシステム（ホスト）が現在と同じように動作することです。ホストがソケットと接続の追跡、およびパケットの送受信に使用するIPアドレスは変更されません。 LISPの用語では、これらのIPアドレスはエンドポイント識別子（EID）と呼ばれます。
Routers continue to forward packets based on IP destination addresses. When a packet is LISP encapsulated, these addresses are referred to as Routing Locators (RLOCs). Most routers along a path between two hosts will not change; they continue to perform routing/ forwarding lookups on the destination addresses. For routers between the source host and the ITR as well as routers from the ETR to the destination host, the destination address is an EID. For the routers between the ITR and the ETR, the destination address is an RLOC.
ルーターは、IP宛先アドレスに基づいてパケットを転送し続けます。パケットがLISPカプセル化されている場合、これらのアドレスはルーティングロケーター（RLOC）と呼ばれます。 2つのホスト間のパスに沿ったほとんどのルーターは変更されません。それらは宛先アドレスでルーティング/転送ルックアップを実行し続けます。送信元ホストとITRの間のルーター、およびETRから宛先ホストへのルーターの場合、宛先アドレスはEIDです。 ITRとETRの間のルーターの場合、宛先アドレスはRLOCです。
Another key LISP concept is the "Tunnel Router". A Tunnel Router prepends LISP headers on host-originated packets and strips them prior to final delivery to their destination. The IP addresses in this "outer header" are RLOCs. During end-to-end packet exchange between two Internet hosts, an ITR prepends a new LISP header to each packet, and an ETR strips the new header. The ITR performs EID-to-RLOC lookups to determine the routing path to the ETR, which has the RLOC as one of its IP addresses.
LISPのもう1つの重要な概念は、「トンネルルーター」です。トンネルルーターは、ホストから発信されたパケットにLISPヘッダーを付加し、宛先への最終的な配信の前にそれらを取り除きます。この「外部ヘッダー」のIPアドレスはRLOCです。 2つのインターネットホスト間のエンドツーエンドのパケット交換中に、ITRは各パケットに新しいLISPヘッダーを付加し、ETRは新しいヘッダーを削除します。 ITRはEIDからRLOCへのルックアップを実行して、IPアドレスの1つとしてRLOCを持つETRへのルーティングパスを決定します。
Some basic rules governing LISP are:
LISPを管理するいくつかの基本的なルールは次のとおりです。
o End-systems (hosts) only send to addresses that are EIDs. They don't know that addresses are EIDs versus RLOCs but assume that packets get to their intended destinations. In a system where LISP is deployed, LISP routers intercept EID-addressed packets and assist in delivering them across the network core where EIDs cannot be routed. The procedure a host uses to send IP packets does not change.
o エンドシステム（ホスト）は、EIDであるアドレスにのみ送信します。彼らは、アドレスがEID対RLOCであることを認識していませんが、パケットが目的の宛先に到達すると想定しています。 LISPが展開されているシステムでは、LISPルーターはEIDアドレスのパケットをインターセプトし、EIDをルーティングできないネットワークコア全体への配信を支援します。ホストがIPパケットを送信するために使用する手順は変更されません。
o EIDs are always IP addresses assigned to hosts.
o EIDは常にホストに割り当てられたIPアドレスです。
o LISP routers mostly deal with Routing Locator addresses. See details in Section 4.1 to clarify what is meant by "mostly".
o LISPルーターは、主にルーティングロケーターアドレスを扱います。 「ほぼ」が何を意味するのかを明確にするには、セクション4.1の詳細を参照してください。
o RLOCs are always IP addresses assigned to routers, preferably topologically oriented addresses from provider CIDR (Classless Inter-Domain Routing) blocks.
o RLOCは常にルーターに割り当てられたIPアドレスであり、できればプロバイダーCIDR（Classless Inter-Domain Routing）ブロックからのトポロジー指向のアドレスです。
o When a router originates packets, it may use as a source address either an EID or RLOC. When acting as a host (e.g., when terminating a transport session such as Secure SHell (SSH), TELNET, or the Simple Network Management Protocol (SNMP)), it may use an EID that is explicitly assigned for that purpose. An EID that identifies the router as a host MUST NOT be used as an RLOC; an EID is only routable within the scope of a site. A typical BGP configuration might demonstrate this "hybrid" EID/RLOC usage where a router could use its "host-like" EID to terminate iBGP sessions to other routers in a site while at the same time using RLOCs to terminate eBGP sessions to routers outside the site.
o ルーターがパケットを発信するとき、EIDまたはRLOCのいずれかを送信元アドレスとして使用できます。ホストとして機能する場合（たとえば、セキュアシェル（SSH）、TELNET、または簡易ネットワーク管理プロトコル（SNMP）などのトランスポートセッションを終了する場合）、その目的で明示的に割り当てられたEIDを使用することがあります。ルーターをホストとして識別するEIDをRLOCとして使用してはなりません（MUST NOT）。 EIDはサイトの範囲内でのみルーティング可能です。典型的なBGP構成は、この「ハイブリッド」EID / RLOCの使用法を示している可能性があります。この場合、ルーターは「ホストのような」EIDを使用してサイト内の他のルーターへのiBGPセッションを終了し、同時にRLOCを使用して外部のルーターへのeBGPセッションを終了します。サイト。
o Packets with EIDs in them are not expected to be delivered end-to-end in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication or to be encapsulated for inter-site communication.
o EIDからRLOCへのマッピング操作がない場合、EIDが含まれるパケットはエンドツーエンドで配信されることはありません。それらは、サイト内通信用にローカルで使用されるか、サイト間通信用にカプセル化されることが期待されています。
o EID-Prefixes are likely to be hierarchically assigned in a manner that is optimized for administrative convenience and to facilitate scaling of the EID-to-RLOC mapping database. The hierarchy is based on an address allocation hierarchy that is independent of the network topology.
o EIDプレフィックスは、管理上の便宜のために最適化され、EIDからRLOCへのマッピングデータベースのスケーリングを容易にする方法で階層的に割り当てられる可能性があります。階層は、ネットワークトポロジに依存しないアドレス割り当て階層に基づいています。
o EIDs may also be structured (subnetted) in a manner suitable for local routing within an Autonomous System (AS).
o EIDは、自律システム（AS）内のローカルルーティングに適した方法で構造化（サブネット化）することもできます。
An additional LISP header MAY be prepended to packets by a TE-ITR when re-routing of the path for a packet is desired. A potential use-case for this would be an ISP router that needs to perform Traffic Engineering for packets flowing through its network. In such a situation, termed "Recursive Tunneling", an ISP transit acts as an additional ITR, and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along an intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists).
パケットのパスの再ルーティングが必要な場合は、TE-ITRによって追加のLISPヘッダーがパケットの前に付加される場合があります。これの潜在的なユースケースは、ネットワークを流れるパケットのトラフィックエンジニアリングを実行する必要があるISPルーターです。 「再帰的トンネリング」と呼ばれるこのような状況では、ISPトランジットは追加のITRとして機能し、新しいプリペンドヘッダーに使用するRLOCは、ISP内のTE-ETR（ISP内のトラフィックエンジニアリングパスに沿ったもの）になります。または別のISP内のTE-ETR（ISP間トラフィックエンジニアリングパス。このようなパスを構築するための合意が存在する場合）。
In order to avoid excessive packet overhead as well as possible encapsulation loops, this document mandates that a maximum of two LISP headers can be prepended to a packet. For initial LISP deployments, it is assumed that two headers is sufficient, where the first prepended header is used at a site for Location/Identity separation and the second prepended header is used inside a service provider for Traffic Engineering purposes.
過剰なパケットオーバーヘッドとカプセル化ループの可能性を回避するために、このドキュメントでは、最大2つのLISPヘッダーをパケットの前に追加できることを義務付けています。最初のLISPの展開では、2つのヘッダーで十分であると想定されます。最初の付加ヘッダーはサイトでロケーション/アイデンティティの分離に使用され、2番目の付加ヘッダーはトラフィックエンジニアリングの目的でサービスプロバイダー内で使用されます。
Tunnel Routers can be placed fairly flexibly in a multi-AS topology. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the ETR might be the last-hop router directly connected to the destination host. Another example, perhaps for a VPN service outsourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Mixing and matching of site-operated, ISP-operated, and other Tunnel Routers is allowed for maximum flexibility. See Section 8 for more details.
トンネルルーターは、マルチASトポロジにかなり柔軟に配置できます。たとえば、特定のエンドツーエンドパケット交換のITRは、送信元ホストのサイト内の最初のホップまたはデフォルトのルーターになる場合があります。同様に、ETRは、宛先ホストに直接接続されているラストホップルーターである可能性があります。別の例として、おそらくサイトからISPに外部委託されたVPNサービスの場合、ITRは、サービスプロバイダー接続ポイントにあるサイトの境界ルーターになる可能性があります。サイト運用、ISP運用、およびその他のトンネルルーターを組み合わせて使用すると、最大限の柔軟性が得られます。詳細については、セクション8を参照してください。
This section provides an example of the unicast packet flow with the following conditions:
このセクションでは、次の条件でのユニキャストパケットフローの例を示します。
o Source host "host1.abc.example.com" is sending a packet to "host2.xyz.example.com", exactly what host1 would do if the site was not using LISP.
o 送信元ホスト「host1.abc.example.com」は、「host2.xyz.example.com」にパケットを送信しています。これは、サイトがLISPを使用していない場合のhost1の動作とまったく同じです。
o Each site is multihomed, so each Tunnel Router has an address (RLOC) assigned from the service provider address block for each provider to which that particular Tunnel Router is attached.
o 各サイトはマルチホームであるため、各トンネルルーターには、その特定のトンネルルーターが接続されている各プロバイダーのサービスプロバイダーアドレスブロックから割り当てられたアドレス（RLOC）があります。
o The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in the LISP site.
o ITRとETRはそれぞれ送信元と宛先に直接接続されていますが、送信元と宛先はLISPサイトのどこにでも配置できます。
o Map-Requests can be sent on the underlying routing system topology, to a mapping database system, or directly over an Alternative Logical Topology [RFC6836]. A Map-Request is sent for an external destination when the destination is not found in the forwarding table or matches a default route.
o Map-Requestは、基盤となるルーティングシステムトポロジで、マッピングデータベースシステムに、または代替論理トポロジ[RFC6836]を介して直接送信できます。宛先が転送テーブルで見つからないか、デフォルトルートと一致する場合、Map-Requestは外部宛先に送信されます。
o Map-Replies are sent on the underlying routing system topology.
o Map-Repliesは、基盤となるルーティングシステムトポロジで送信されます。
Client host1.abc.example.com wants to communicate with server host2.xyz.example.com:
クライアントhost1.abc.example.comは、サーバーhost2.xyz.example.comと通信する必要があります。
1. host1.abc.example.com wants to open a TCP connection to host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. An A/AAAA record is returned. This address is the destination EID. The locally assigned address of host1.abc.example.com is used as the source EID. An IPv4 or IPv6 packet is built and forwarded through the LISP site as a normal IP packet until it reaches a LISP ITR.
1. host1.abc.example.comは、host2.xyz.example.comへのTCP接続を開きたいと考えています。 host2.xyz.example.comでDNSルックアップを行います。 A / AAAAレコードが返されます。このアドレスは宛先EIDです。 host1.abc.example.comのローカルに割り当てられたアドレスは、ソースEIDとして使用されます。 IPv4またはIPv6パケットが作成され、LISP ITRに到達するまで、LISPサイトを通じて通常のIPパケットとして転送されます。
2. The LISP ITR must be able to map the destination EID to an RLOC of one of the ETRs at the destination site. The specific method used to do this is not described in this example. See [RFC6836] or [CONS] for possible solutions.
2. LISP ITRは、宛先EIDを宛先サイトのETRの1つのRLOCにマップできる必要があります。これを行うために使用される特定の方法は、この例では説明されていません。考えられる解決策については、[RFC6836]または[CONS]を参照してください。
3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be rate-limited.
3. ITRはLISP Map-Requestを送信します。 Map-Requestsはレート制限する必要があります。
4. When an alternate mapping system is not in use, the Map-Request packet is routed through the underlying routing system. Otherwise, the Map-Request packet is routed on an alternate logical topology, for example, the [RFC6836] database mapping system. In either case, when the Map-Request arrives at one of the ETRs at the destination site, it will process the packet as a control message.
4. 代替のマッピングシステムが使用されていない場合、Map-Requestパケットは、基盤となるルーティングシステムを介してルーティングされます。それ以外の場合、Map-Requestパケットは、代替の論理トポロジ、たとえば[RFC6836]データベースマッピングシステムにルーティングされます。どちらの場合も、Map-Requestが宛先サイトのETRの1つに到着すると、パケットは制御メッセージとして処理されます。
5. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to-RLOC mapping database. This is the list of EID-Prefixes the ETR is supporting for the site it resides in. If there is no match, the Map-Request is dropped. Otherwise, a LISP Map-Reply is returned to the ITR.
5. ETRはMap-Requestの宛先EIDを調べ、ETRの構成済みEID-to-RLOCマッピングデータベースのプレフィックスと照合します。これは、ETRが存在するサイトに対してETRがサポートするEIDプレフィックスのリストです。一致しない場合、Map-Requestはドロップされます。それ以外の場合は、LISP Map-ReplyがITRに返されます。
6. The ITR receives the Map-Reply message, parses the message (to check for format validity), and stores the mapping information from the packet. This information is stored in the ITR's EID-to-RLOC mapping cache. Note that the map-cache is an on-demand cache. An ITR will manage its map-cache in such a way that optimizes for its resource constraints.
6. ITRはMap-Replyメッセージを受信し、メッセージを解析して（形式の妥当性をチェックするため）、パケットからのマッピング情報を格納します。この情報は、ITRのEIDからRLOCへのマッピングキャッシュに保存されます。マップキャッシュはオンデマンドキャッシュであることに注意してください。 ITRは、リソースの制約を最適化するような方法でマップキャッシュを管理します。
7. Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR. Note that the packet MAY be sent to a different ETR than the one that returned the Map-Reply due to the source site's hashing policy or the destination site's Locator-Set policy.
7. host1.abc.example.comからhost2.xyz.example.comへの後続のパケットには、ETRから学習したLISPヘッダー宛先アドレスとして適切なRLOCを使用して、ITRによってLISPヘッダーが付加されます。パケットは、ソースサイトのハッシュポリシーまたは宛先サイトのロケーターセットポリシーが原因でMap-Replyを返したものとは異なるETRに送信される場合があります。
8. The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), checks the validity of the addresses, strips the LISP header, and forwards packets to the attached destination host.
8. ETRはこれらのパケットを直接受信し（宛先アドレスは割り当てられたIPアドレスの1つであるため）、アドレスの有効性をチェックし、LISPヘッダーを取り除き、パケットを接続された宛先ホストに転送します。
In order to defer the need for a mapping lookup in the reverse direction, an ETR MAY create a cache entry that maps the source EID (inner-header source IP address) to the source RLOC (outer-header source IP address) in a received LISP packet. Such a cache entry is termed a "gleaned" mapping and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. Both the ITR and the ETR may also influence the decision the other makes in selecting an RLOC. See Section 6 for more details.
逆方向のマッピングルックアップの必要性を遅らせるために、ETRは、受信したソースEID（内部ヘッダーソースIPアドレス）をソースRLOC（外部ヘッダーソースIPアドレス）にマップするキャッシュエントリを作成できます（MAY）。 LISPパケット。このようなキャッシュエントリは、「傾斜」マッピングと呼ばれ、問題のEIDの単一のRLOCのみを含みます。追加のRLOCに関するより完全な情報は、そのEIDのLISP Map-Requestを送信することによって確認する必要があります。 ITRとETRの両方が、RLOCを選択する際に他が行う決定にも影響を与える可能性があります。詳細については、セクション6を参照してください。
Since additional tunnel headers are prepended, the packet becomes larger and can exceed the MTU of any link traversed from the ITR to the ETR. It is RECOMMENDED in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMP Too Big message is returned to the source.
追加のトンネルヘッダーが付加されるため、パケットが大きくなり、ITRからETRに渡されるリンクのMTUを超える可能性があります。 IPv4では、ITRによってカプセル化されるため、パケットが断片化されないことが推奨されます。代わりに、パケットはドロップされ、ICMP Too Bigメッセージがソースに返されます。
This specification RECOMMENDS that implementations provide support for one of the proposed fragmentation and reassembly schemes. Two existing schemes are detailed in Section 5.4.
この仕様は、実装が提案された断片化および再構成スキームの1つのサポートを提供することを推奨します。既存の2つのスキームについては、セクション5.4で詳しく説明しています。
Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner header is in IPv4 packet format and the outer header is in IPv6 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header is in IPv6 packet format and the outer header is in IPv4 packet format). The next sub-sections illustrate packet formats for the homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 combinations MUST be supported.
IPv4またはIPv6アドレスはEIDまたはRLOCのいずれかであるため、LISPアーキテクチャはIPv6 RLOCを使用したIPv4 EID（内部ヘッダーはIPv4パケット形式で外部ヘッダーはIPv6パケット形式を使用）またはIPv4 RLOCを使用したIPv6 EID（内部ヘッダーはIPv6パケット形式で、外部ヘッダーはIPv4パケット形式です。次のサブセクションでは、同種の場合（IPv4-in-IPv4およびIPv6-in-IPv6）のパケット形式を示しますが、4つの組み合わせすべてをサポートする必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OH | Time to Live | Protocol = 17 | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Routing Locator |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|flags| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH | Time to Live | Protocol | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source EID |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IHL = IP-Header-Length
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| Traffic Class | Flow Label |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Payload Length | Next Header=17| Hop Limit |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
O + +
u | |
t + Source Routing Locator +
e | |
r + +
| |
H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | |
r + +
| |
^ + Destination Routing Locator +
| | |
\ + +
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|flags| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| Traffic Class | Flow Label |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Payload Length | Next Header | Hop Limit |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
I + +
n | |
n + Source EID +
e | |
r + +
| |
H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | |
r + +
| |
^ + Destination EID +
\ | |
\ + +
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Header (IH): The inner header is the header on the datagram received from the originating host. The source and destination IP addresses are EIDs [RFC0791] [RFC2460].
内部ヘッダー（IH）：内部ヘッダーは、発信元ホストから受信したデータグラムのヘッダーです。送信元と宛先のIPアドレスはEID [RFC0791] [RFC2460]です。
Outer Header: (OH) The outer header is a new header prepended by an ITR. The address fields contain RLOCs obtained from the ingress router's EID-to-RLOC Cache. The IP protocol number is "UDP (17)" from [RFC0768]. The setting of the Don't Fragment (DF) bit 'Flags' field is according to rules listed in Sections 5.4.1 and 5.4.2.
外部ヘッダー：（OH）外部ヘッダーは、ITRが前に付加された新しいヘッダーです。アドレスフィールドには、入力ルーターのEID-to-RLOCキャッシュから取得したRLOCが含まれます。 IPプロトコル番号は[RFC0768]からの「UDP（17）」です。 Do n't Fragment（DF）ビットの「Flags」フィールドの設定は、セクション5.4.1および5.4.2にリストされているルールに従います。
UDP Header: The UDP header contains an ITR selected source port when encapsulating a packet. See Section 6.5 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA-assigned port value 4341.
UDPヘッダー：UDPヘッダーには、パケットのカプセル化時にITRで選択された送信元ポートが含まれます。内部ヘッダーの5タプルに基づいて送信元ポートを選択するために使用されるハッシュアルゴリズムの詳細については、セクション6.5を参照してください。宛先ポートは、既知のIANA割り当てポート値4341に設定する必要があります。
UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS] [UDP-ZERO]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP checksums for all tunneling protocols, including LISP, is under active discussion within the IETF. When that discussion concludes, any necessary changes will be made to align LISP with the outcome of the broader discussion.
UDPチェックサム：「UDPチェックサム」フィールドは、IPv4 [RFC0768]またはIPv6カプセル化[UDP-TUNNELS] [UDP-ZERO]のいずれかのITRによってゼロとして送信される必要があります（SHOULD）。 UDPチェックサムがゼロのパケットがETRによって受信されると、ETRはカプセル化解除のためにパケットを受け入れる必要があります。 ITRがUDPチェックサムにゼロ以外の値を送信する場合、このフィールドに正しく計算された値を送信する必要があります。 ETRがゼロ以外のUDPチェックサムを持つパケットを受信すると、チェックサム値を検証することを選択できます（MAY）。そのような検証を実行することを選択し、検証が失敗した場合、パケットは黙って破棄されなければなりません（MUST）。 ETRが検証を実行しないことを選択した場合、または検証を正常に実行した場合、パケットのカプセル化解除を受け入れる必要があります。 LISPを含むすべてのトンネリングプロトコルのUDPチェックサムの処理は、IETF内で活発に議論されています。その議論が終了すると、LISPをより広範な議論の結果に合わせるために必要な変更が行われます。
UDP Length: The 'UDP Length' field is set for an IPv4-encapsulated packet to be the sum of the inner-header IPv4 Total Length plus the UDP and LISP header lengths. For an IPv6-encapsulated packet, the 'UDP Length' field is the sum of the inner-header IPv6 Payload Length, the size of the IPv6 header (40 octets), and the size of the UDP and LISP headers.
UDP長さ：「UDP長さ」フィールドは、IPv4でカプセル化されたパケットに対して、内部ヘッダーのIPv4合計長とUDPおよびLISPヘッダー長の合計になるように設定されます。 IPv6カプセル化パケットの場合、「UDP長さ」フィールドは、内部ヘッダーIPv6ペイロード長、IPv6ヘッダーのサイズ（40オクテット）、およびUDPヘッダーとLISPヘッダーのサイズの合計です。
N: The N-bit is the nonce-present bit. When this bit is set to 1, the low-order 24 bits of the first 32 bits of the LISP header contain a Nonce. See Section 6.3.1 for details. Both N- and V-bits MUST NOT be set in the same packet. If they are, a decapsulating ETR MUST treat the 'Nonce/Map-Version' field as having a Nonce value present.
N：Nビットはnonce-presentビットです。このビットを1に設定すると、LISPヘッダーの最初の32ビットの下位24ビットにノンスが含まれます。詳細については、セクション6.3.1を参照してください。 NビットとVビットの両方を同じパケットに設定してはなりません（MUST NOT）。存在する場合、カプセル化解除ETRは「Nonce / Map-Version」フィールドをNonce値が存在するものとして扱う必要があります。
L: The L-bit is the 'Locator-Status-Bits' field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32 bits of the LISP header are in use.
L：Lビットは「Locator-Status-Bits」フィールドが有効なビットです。このビットを1に設定すると、LISPヘッダーの2番目の32ビットのLocator-Status-Bitsが使用されます。
x 1 x x 0 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: The E-bit is the echo-nonce-request bit. This bit MUST be ignored and has no meaning when the N-bit is set to 0. When the N-bit is set to 1 and this bit is set to 1, an ITR is requesting that the nonce value in the 'Nonce' field be echoed back in LISP-encapsulated packets when the ITR is also an ETR. See Section 6.3.1 for details.
E：Eビットは、echo-nonce-requestビットです。このビットは無視する必要があり、Nビットが0に設定されている場合は意味がありません。Nビットが1に設定され、このビットが1に設定されている場合、ITRは「ノンス」フィールドのノンス値を要求しますITRがETRでもある場合、LISPカプセル化パケットでエコーバックされます。詳細については、セクション6.3.1を参照してください。
V: The V-bit is the Map-Version present bit. When this bit is set to 1, the N-bit MUST be 0. Refer to Section 6.6.3 for more details. This bit indicates that the LISP header is encoded in this case as:
V：Vビットは、マップバージョン存在ビットです。このビットが1に設定されている場合、Nビットは0でなければなりません。詳細については、セクション6.6.3を参照してください。このビットは、この場合LISPヘッダーが次のようにエンコードされていることを示します。
0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I: The I-bit is the Instance ID bit. See Section 5.5 for more details. When this bit is set to 1, the 'Locator-Status-Bits' field is reduced to 8 bits and the high-order 24 bits are used as an Instance ID. If the L-bit is set to 0, then the low-order 8 bits are transmitted as zero and ignored on receipt. The format of the LISP header would look like this:
I：IビットはインスタンスIDビットです。詳細については、セクション5.5を参照してください。このビットが1に設定されている場合、「Locator-Status-Bits」フィールドは8ビットに削減され、上位24ビットがインスタンスIDとして使用されます。 Lビットが0に設定されている場合、下位8ビットはゼロとして送信され、受信時に無視されます。 LISPヘッダーの形式は次のようになります。
x x x x 1 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | LSBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
flags: The 'flags' field is a 3-bit field reserved for future flag use. It MUST be set to 0 on transmit and MUST be ignored on receipt.
フラグ：「フラグ」フィールドは、将来のフラグの使用のために予約されている3ビットのフィールドです。送信時には0に設定する必要があり、受信時には無視する必要があります。
LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. Nonce generation algorithms are an implementation matter but are required to generate different nonces when sending to different destinations. However, the same nonce can be used for a period of time to the same destination. The nonce is also used when the E-bit is set to request the nonce value to be echoed by the other side when packets are returned. When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested echo-nonce or providing a random nonce. See Section 6.3.1 for more details.
LISPノンス：LISPの「ノンス」フィールドは、Nビットが1に設定されている場合にITRによってランダムに生成される24ビットの値です。ノンス生成アルゴリズムは実装上の問題ですが、異なるに送信するときに異なるノンスを生成する必要があります目的地。ただし、同じノンスを一定の期間、同じ宛先に使用できます。 nonceは、Eビットがパケットが返されたときに相手側でnonce値がエコーされるように要求するように設定されている場合にも使用されます。 EビットはクリアされているがNビットが設定されている場合、リモートITRは以前に要求されたエコーナンスをエコーするか、ランダムナンスを提供しています。詳細については、セクション6.3.1を参照してください。
LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the 'Locator-Status-Bits' field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator-Status-Bits are numbered from 0 to n-1 from the least significant bit of the field. The field is 32 bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a Locator-Status-Bit is set to 1, the ITR is indicating to the ETR that the RLOC associated with the bit ordinal has up status. See Section 6.3 for details on how an ITR can determine the status of the ETRs at the same site. When a site has multiple EID-Prefixes that result in multiple mappings (where each could have a different Locator-Set), the Locator-Status-Bits setting in an encapsulated packet MUST reflect the mapping for the EID-Prefix that the inner-header source EID address matches. If the LSB for an anycast Locator is set to 1, then there is at least one RLOC with that address, and the ETR is considered 'up'.
LISP Locator-Status-Bits（LSB）：Lビットも設定されている場合、LISPヘッダーの「Locator-Status-Bits」フィールドはITRによって設定され、ETRにロケーターのアップ/ダウンステータスを示します。ソースサイトで。 Map-Replyの各RLOCには、0〜n-1の序数値が割り当てられます（マッピングエントリにn個のRLOCがある場合）。 Locator-Status-Bitsには、フィールドの最下位ビットから0からn-1までの番号が付けられます。このフィールドは、Iビットが0に設定されている場合は32ビットで、Iビットが1に設定されている場合は8ビットです。Locator-Status-Bitが1に設定されている場合、ITRはETRに対してRLOCビット序数に関連付けられているステータスがアップしています。 ITRが同じサイトのETRのステータスを判別する方法の詳細については、セクション6.3を参照してください。サイトに複数のEIDプレフィックスがあり、複数のマッピングが発生する場合（それぞれに異なるLocator-Setが含まれる可能性があります）、カプセル化されたパケットのLocator-Status-Bits設定は、内部ヘッダーのEIDプレフィックスのマッピングを反映する必要があります送信元EIDアドレスが一致します。エニーキャストロケーターのLSBが1に設定されている場合、そのアドレスを持つRLOCが少なくとも1つあり、ETRは「アップ」と見なされます。
When doing ITR/PITR encapsulation:
ITR / PITRカプセル化を行う場合：
o The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
o アウターヘッダーの「Time to Live」フィールド（またはIPv6の場合は「Hop Limit」フィールド）は、インナーヘッダーの「Time to Live」フィールドからコピーする必要があります。
o The outer-header 'Type of Service' field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the inner-header 'Type of Service' field (with one exception; see below).
o 外部ヘッダーの「Type of Service」フィールド（またはIPv6の場合は「Traffic Class」フィールド）は、内部ヘッダーの「Type of Service」フィールドからコピーする必要があります（例外が1つあります。以下を参照）。
When doing ETR/PETR decapsulation:
ETR / PETRカプセル開放を行う場合：
o The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, when the Time to Live value of the outer header is less than the Time to Live value of the inner header. Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycles. This check is also performed when doing initial encapsulation, when a packet comes to an ITR or PITR destined for a LISP site.
o 内部ヘッダーの「Time to Live」フィールド（またはIPv6の場合は「Hop Limit」フィールド）は、外部ヘッダーのTime to Live値が次の場合に、外部ヘッダーの「Time to Live」フィールドからコピーする必要があります（SHOULD）。内部ヘッダーのTime to Live値よりも小さい。このチェックを実行しないと、内部ヘッダーのTime to Liveがカプセル化/カプセル化解除のサイクル全体で増加する可能性があります。このチェックは、最初のカプセル化を行うとき、パケットがLISPサイト宛てのITRまたはPITRに到達したときにも実行されます。
o The inner-header 'Type of Service' field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header 'Type of Service' field (with one exception; see below).
o 内部ヘッダーの「Type of Service」フィールド（またはIPv6の場合は「Traffic Class」フィールド）は、外部ヘッダーの「Type of Service」フィールドからコピーする必要があります（1つの例外を除き、以下を参照）。
Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header minus 1.
ETR / PETRがITR / PITRでもあり、カプセル化解除後に再カプセル化することを選択した場合、これの最終的な効果は、新しい外部ヘッダーが古い外部ヘッダーから1を引いたものと同じ存続時間を運ぶことです。
Copying the Time to Live (TTL) serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration. See Section 9.3 for TTL exception handling for traceroute packets.
存続時間（TTL）のコピーには2つの目的があります。1つ目は、ホストがパケットの移動を意図した距離を維持することです。 2つ目は、さらに重要なことに、構成の誤りにより連結されたトンネルのループが発生した場合に、ループするパケットが抑制されることです。 tracerouteパケットのTTL例外処理については、セクション9.3を参照してください。
The Explicit Congestion Notification ('ECN') field occupies bits 6 and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic Class' field [RFC3168]. The 'ECN' field requires special treatment in order to avoid discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints.
Explicit Congestion Notification（ 'ECN'）フィールドは、IPv4 'Type of Service'フィールドとIPv6 'Traffic Class'フィールド[RFC3168]の両方のビット6と7を占有します。 「ECN」フィールドは、混雑の兆候を破棄しないようにするために特別な処理が必要です[RFC3168]。 ITRカプセル化では、2ビットの「ECN」フィールドを内部ヘッダーから外部ヘッダーにコピーする必要があります。再カプセル化では、2ビットの「ECN」フィールドを、削除された外部ヘッダーから新しい外部ヘッダーにコピーする必要があります。 「ECN」フィールドに輻輳表示コードポイント（値は「11」、輻輳経験（CE）コードポイント）が含まれている場合、ETRカプセル化解除により、2ビットの「ECN」フィールドが除去された外部ヘッダーから存続する内部ヘッダーにコピーされる必要があります。 ETRを超えてパケットを転送するために使用されるヘッダー。これらの要件は、ECNを使用するパケットがLISPトンネルを通過し、トンネルエンドポイント間の輻輳が原因でCE標識でマークされた場合に、CE標識を保持します。
This section proposes two mechanisms to deal with packets that exceed the path MTU between the ITR and ETR.
このセクションでは、ITRとETR間のパスMTUを超えるパケットを処理する2つのメカニズムを提案します。
It is left to the implementor to decide if the stateless or stateful mechanism should be implemented. Both or neither can be used, since it is a local decision in the ITR regarding how to deal with MTU issues, and sites can interoperate with differing mechanisms.
ステートレスメカニズムとステートフルメカニズムのどちらを実装するかは、実装者が決定します。 MTUの問題への対処方法はITRのローカルな決定であり、サイトは異なるメカニズムと相互運用できるため、両方またはどちらも使用できません。
Both stateless and stateful mechanisms also apply to Re-encapsulating and Recursive Tunneling, so any actions below referring to an ITR also apply to a TE-ITR.
ステートレスメカニズムとステートフルメカニズムの両方が再カプセル化と再帰的トンネリングにも適用されるため、ITRを参照する以下のアクションはTE-ITRにも適用されます。
An ITR stateless solution to handle MTU issues is described as follows:
MTUの問題を処理するITRステートレスソリューションは次のとおりです。
1. Define H to be the size, in octets, of the outer header an ITR prepends to a packet. This includes the UDP and LISP header lengths.
1. Hを、ITRがパケットに付加する外部ヘッダーのサイズ（オクテット単位）になるように定義します。これには、UDPおよびLISPヘッダー長が含まれます。
2. Define L to be the size, in octets, of the maximum-sized packet an ITR can send to an ETR without the need for the ITR or any intermediate routers to fragment the packet.
2. Lは、ITRまたは中間ルーターがパケットをフラグメント化することなく、ITRがETRに送信できる最大サイズのパケットのサイズ（オクテット単位）として定義します。
3. Define an architectural constant S for the maximum size of a packet, in octets, an ITR must receive so the effective MTU can be met. That is, S = L - H.
3. パケットの最大サイズのアーキテクチャ定数Sをオクテットで定義します。有効なMTUを満たすためにITRが受信する必要があります。つまり、S = L-Hです。
When an ITR receives a packet from a site-facing interface and adds H octets worth of encapsulation to yield a packet size greater than L octets, it resolves the MTU issue by first splitting the original packet into 2 equal-sized fragments. A LISP header is then prepended to each fragment. The size of the encapsulated fragments is then (S/2 + H), which is less than the ITR's estimate of the path MTU between the ITR and its correspondent ETR.
ITRがサイトに面したインターフェイスからパケットを受信し、Hオクテット相当のカプセル化を追加してLオクテットより大きいパケットサイズを生成する場合、最初に元のパケットを2つの同じサイズのフラグメントに分割することにより、MTUの問題を解決します。次に、LISPヘッダーが各フラグメントに付加されます。カプセル化されたフラグメントのサイズは（S / 2 + H）で、ITRと対応するETR間のパスMTUのITRの推定値よりも小さくなります。
When an ETR receives encapsulated fragments, it treats them as two individually encapsulated packets. It strips the LISP headers and then forwards each fragment to the destination host of the destination site. The two fragments are reassembled at the destination host into the single IP datagram that was originated by the source host. Note that reassembly can happen at the ETR if the encapsulated packet was fragmented at or after the ITR.
ETRは、カプセル化されたフラグメントを受信すると、それらを2つの個別にカプセル化されたパケットとして扱います。 LISPヘッダーを取り除き、各フラグメントを宛先サイトの宛先ホストに転送します。 2つのフラグメントは、宛先ホストで再構成され、送信元ホストから発信された単一のIPデータグラムになります。カプセル化されたパケットがITR以降にフラグメント化された場合、ETRで再構成が発生する可能性があることに注意してください。
This behavior is performed by the ITR when the source host originates a packet with the 'DF' field of the IP header set to 0. When the 'DF' field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L and send an ICMP Too Big message to the source with a value of S, where S is (L - H).
この動作は、送信元ホストがIPヘッダーの「DF」フィールドを0に設定してパケットを発信したときにITRによって実行されます。IPヘッダーの「DF」フィールドが1に設定されている場合、またはパケットがIPv6パケットの場合ソースホストによって発信された場合、サイズがLより大きい場合、ITRはパケットをドロップし、Sが（L-H）の値であるICMP Too Bigメッセージをソースに送信します。
When the outer-header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR.
外部ヘッダーのカプセル化がIPv4ヘッダーを使用する場合、実装はDFビットを1に設定して（SHOULD）、ETRフラグメントの再構成を回避できるようにする必要があります。実装は、送信ITRと受信ETRの間に解決できないパスMTU問題があると信じる十分な理由がある場合、そのようなヘッダーのDFビットを0に設定してもよい（MAY）。
This specification RECOMMENDS that L be defined as 1500.
この仕様では、Lを1500として定義することを推奨しています。
An ITR stateful solution to handle MTU issues is described as follows and was first introduced in [OPENLISP]:
MTUの問題を処理するITRステートフルソリューションは次のように説明され、[OPENLISP]で最初に導入されました。
1. The ITR will keep state of the effective MTU for each Locator per Map-Cache entry. The effective MTU is what the core network can deliver along the path between the ITR and ETR.
1. ITRは、Map-Cacheエントリごとの各ロケーターの有効MTUの状態を保持します。実効MTUは、コアネットワークがITRとETR間のパスに沿って提供できるものです。
2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet with the DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMP Too Big message to the ITR. The ITR will parse the ICMP message to determine which Locator is affected by the effective MTU change and then record the new effective MTU value in the Map-Cache entry.
2. IPv6カプセル化パケット、またはDFビットが1に設定されたIPv4カプセル化パケットがコアネットワークが配信できる量を超えると、パス上の中間ルーターの1つがICMP Too BigメッセージをITRに送信します。 ITRはICMPメッセージを解析して、有効なMTUの変更の影響を受けるロケーターを特定し、新しい有効なMTU値をMap-Cacheエントリに記録します。
3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the Map-Cache entry associated with the destination EID the packet is for, the ITR will send an ICMP Too Big message back to the source. The packet size advertised by the ITR in the ICMP Too Big message is the effective MTU minus the LISP encapsulation length.
3. パケットがサイト内のソースからITRによって受信され、パケットのサイズが、パケットの宛先EIDに関連付けられたMap-Cacheエントリに格納されている有効なMTUより大きい場合、ITRはICMPを送信しますソースに戻るメッセージが大きすぎます。 ICMP Too BigメッセージでITRによってアドバタイズされるパケットサイズは、実効MTUからLISPカプセル化の長さを引いたものです。
Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets.
このメカニズムはステートフルですが、ITRフラグメント化パケットの再構成に宛先ホストを関与させないため、ステートレスIPフラグメンテーションメカニズムよりも優れています。
When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-Prefixes, their address spaces MUST remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI-based address unique. See IANA Considerations (Section 14.2) for details on possible address encodings.
LISPサイト内の複数の組織がプライベートアドレス[RFC1918]をEIDプレフィックスとして使用している場合、アドレスの重複の可能性があるため、それらのアドレス空間は分離されたままである必要があります。アドレスエンコーディングのインスタンスIDは、AFIベースのアドレス全体を一意にするのに役立ちます。可能なアドレスエンコーディングの詳細については、IANAの考慮事項（セクション14.2）を参照してください。
An Instance ID can be carried in a LISP-encapsulated packet. An ITR that prepends a LISP header will copy a 24-bit value used by the LISP router to uniquely identify the address space. The value is copied to the 'Instance ID' field of the LISP header, and the I-bit is set to 1.
インスタンスIDは、LISPカプセル化パケットで伝送できます。 LISPヘッダーを付加するITRは、LISPルーターがアドレス空間を一意に識別するために使用する24ビット値をコピーします。値はLISPヘッダーの「インスタンスID」フィールドにコピーされ、Iビットは1に設定されます。
When an ETR decapsulates a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup.
ETRがパケットをカプセル化解除すると、LISPヘッダーのインスタンスIDがテーブルIDとして使用され、内部宛先EIDルックアップに使用する転送テーブルが検索されます。
For example, an 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID.
たとえば、802.1Q VLANタグまたはVPN識別子を24ビットのインスタンスIDとして使用できます。
The following UDP packet formats are used by the LISP control plane.
次のUDPパケット形式は、LISPコントロールプレーンで使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol = 17 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port | Dest Port |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LISP Message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header=17| Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Routing Locator +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Routing Locator +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port | Dest Port |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LISP Message |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LISP UDP-based messages are the Map-Request and Map-Reply messages. When a UDP Map-Request is sent, the UDP source port is chosen by the sender and the destination UDP port number is set to 4342. When a UDP Map-Reply is sent, the source UDP port number is set to 4342 and the destination UDP port number is copied from the source port of either the Map-Request or the invoking data packet. Implementations MUST be prepared to accept packets when either the source port or destination UDP port is set to 4342 due to NATs changing port number values.
LISP UDPベースのメッセージは、Map-RequestメッセージとMap-Replyメッセージです。 UDP Map-Requestが送信されると、UDP送信元ポートが送信者によって選択され、宛先UDPポート番号が4342に設定されます。UDPMap-Replyが送信されると、送信元UDPポート番号が4342に設定され、宛先UDPポート番号は、Map-Requestまたは呼び出し元のデータパケットの送信元ポートからコピーされます。 NATがポート番号の値を変更するため、送信元ポートまたは宛先UDPポートが4342に設定されている場合、実装はパケットを受け入れる準備ができていなければなりません。
The 'UDP Length' field will reflect the length of the UDP header and the LISP Message payload.
「UDP長さ」フィールドは、UDPヘッダーとLISPメッセージペイロードの長さを反映します。
The UDP checksum is computed and set to non-zero for Map-Request, Map-Reply, Map-Register, and Encapsulated Control Message (ECM) control messages. It MUST be checked on receipt, and if the checksum fails, the packet MUST be dropped.
UDPチェックサムが計算され、Map-Request、Map-Reply、Map-Register、およびEncapsulated Control Message（ECM）制御メッセージに対してゼロ以外に設定されます。受信時にチェックする必要があり、チェックサムが失敗した場合は、パケットをドロップする必要があります。
The format of control messages includes the UDP header so the checksum and length fields can be used to protect and delimit message boundaries.
制御メッセージのフォーマットにはUDPヘッダーが含まれているため、チェックサムおよび長さフィールドを使用して、メッセージ境界を保護および区切ることができます。
This section will be the authoritative source for allocating LISP Type values and for defining LISP control message formats. Current allocations are:
このセクションは、LISPタイプの値を割り当て、LISP制御メッセージ形式を定義するための信頼できるソースになります。現在の割り当ては次のとおりです。
Reserved: 0 b'0000' LISP Map-Request: 1 b'0001' LISP Map-Reply: 2 b'0010' LISP Map-Register: 3 b'0011' LISP Map-Notify: 4 b'0100' LISP Encapsulated Control Message: 8 b'1000'
予約済み：0 b'0000 'LISP Map-Request：1 b'0001' LISP Map-Reply：2 b'0010 'LISP Map-Register：3 b'0011' LISP Map-Notify：4 b'0100 'LISP Encapsulated Controlメッセージ：8 b'1000 '
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s| Reserved | IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI n | ITR-RLOC Address n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Reserved | EID mask-len | EID-Prefix-AFI |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | EID-Prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions:
パケットフィールドの説明：
Type: 1 (Map-Request)
タイプ：1（Map-Request）
A: This is an authoritative bit, which is set to 0 for UDP-based Map-Requests sent by an ITR. It is set to 1 when an ITR wants the destination site to return the Map-Reply rather than the mapping database system.
A：これは信頼できるビットであり、ITRによって送信されるUDPベースのMap-Requestsに対して0に設定されます。 ITRが宛先サイトにマッピングデータベースシステムではなくMap-Replyを返すようにしたい場合は、1に設定されます。
M: This is the map-data-present bit. When set, it indicates that a Map-Reply Record segment is included in the Map-Request.
M：これは、map-data-presentビットです。設定すると、Map-Reply RecordセグメントがMap-Requestに含まれることを示します。
P: This is the probe-bit, which indicates that a Map-Request SHOULD be treated as a Locator reachability probe. The receiver SHOULD respond with a Map-Reply with the probe-bit set, indicating that the Map-Reply is a Locator reachability probe reply, with the nonce copied from the Map-Request. See Section 6.3.2 for more details.
P：これはプローブビットです。これは、マップ要求をロケーター到達可能性プローブとして扱う必要があることを示しています。受信者は、プローブビットが設定されたMap-Replyで応答する必要があります。これは、Map-ReplyがLocator到達可能性プローブ応答であり、ナンスがMap-Requestからコピーされていることを示します。詳細については、セクション6.3.2を参照してください。
S: This is the Solicit-Map-Request (SMR) bit. See Section 6.6.2 for details.
S：これはSolicit-Map-Request（SMR）ビットです。詳細はセクション6.6.2を参照してください。
p: This is the PITR bit. This bit is set to 1 when a PITR sends a Map-Request.
p：これはPITRビットです。このビットは、PITRがマップ要求を送信すると1に設定されます。
s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is sending a Map-Request in response to a received SMR-based Map-Request.
s：これは、SMRが呼び出すビットです。このビットは、xTRが受信したSMRベースのMap-Requestに応答してMap-Requestを送信しているときに1に設定されます。
Reserved: This field MUST be set to 0 on transmit and MUST be ignored on receipt.
予約済み：このフィールドは送信時に0に設定する必要があり、受信時には無視する必要があります。
IRC: This 5-bit field is the ITR-RLOC Count, which encodes the additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC-Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields are used, so a Map-Replier can select which destination address to use for a Map-Reply. The IRC value ranges from 0 to 31. For a value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, there are 2 ITR-RLOC addresses encoded, and so on up to 31, which encodes a total of 32 ITR-RLOC addresses.
IRC：この5ビットのフィールドはITR-RLOCカウントで、このメッセージに含まれる（ 'ITR-RLOC-AFI'、 'ITR-RLOCアドレス'）フィールドの追加数をエンコードします。少なくとも1つの（ITR-RLOC-AFI、ITR-RLOC-Address）ペアをエンコードする必要があります。複数の「ITR-RLOCアドレス」フィールドが使用されるため、Map-ReplierはMap-Replyに使用する宛先アドレスを選択できます。 IRC値の範囲は0〜31です。値が0の場合、ITR-RLOCアドレスが1つエンコードされます。値が1の場合、2つのITR-RLOCアドレスがエンコードされ、最大31まで続きます。これにより、合計32のITR-RLOCアドレスがエンコードされます。
Record Count: This is the number of records in this Map-Request message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. For this version of the protocol, a receiver MUST accept and process Map-Requests that contain one or more records, but a sender MUST only send Map-Requests containing one record. Support for requesting multiple EIDs in a single Map-Request message will be specified in a future version of the protocol.
レコード数：これは、このMap-Requestメッセージ内のレコード数です。レコードは、上記の「Rec」というラベルが付いたパケットの部分で構成され、レコードカウントに等しい回数発生します。このバージョンのプロトコルでは、受信者は1つ以上のレコードを含むMap-Requestを受け入れて処理する必要がありますが、送信者は1つのレコードを含むMap-Requestのみを送信する必要があります。単一のMap-Requestメッセージで複数のEIDを要求するためのサポートは、プロトコルの将来のバージョンで指定される予定です。
Nonce: This is an 8-octet random value created by the sender of the Map-Request. This nonce will be returned in the Map-Reply. The security of the LISP mapping protocol critically depends on the strength of the nonce in the Map-Request message. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security-sensitive random data.
Nonce：これは、Map-Requestの送信者によって作成された8オクテットのランダムな値です。このノンスはMap-Replyで返されます。 LISPマッピングプロトコルのセキュリティは、Map-Requestメッセージのナンスの強度に大きく依存します。 nonceは、適切にシードされた疑似ランダム（または強いランダム）ソースによって生成する必要があります（SHOULD）。セキュリティが重要なランダムデータの生成に関するアドバイスについては、[RFC4086]を参照してください。
Source-EID-AFI: This is the address family of the 'Source EID Address' field.
Source-EID-AFI：これは、「Source EID Address」フィールドのアドレスファミリーです。
Source EID Address: This is the EID of the source host that originated the packet that caused the Map-Request. When Map-Requests are used for refreshing a Map-Cache entry or for RLOC-Probing, an AFI value 0 is used and this field is of zero length.
Source EID Address：これは、Map-Requestの原因となったパケットを発信したソースホストのEIDです。 Map-RequestがMap-Cacheエントリの更新またはRLOC-Probingに使用される場合、AFI値0が使用され、このフィールドは長さがゼロです。
ITR-RLOC-AFI: This is the address family of the 'ITR-RLOC Address' field that follows this field.
ITR-RLOC-AFI：これは、このフィールドに続く「ITR-RLOCアドレス」フィールドのアドレスファミリーです。
ITR-RLOC Address: This is used to give the ETR the option of selecting the destination address from any address family for the Map-Reply message. This address MUST be a routable RLOC address of the sender of the Map-Request message.
ITR-RLOCアドレス：これは、ETRにMap-Replyメッセージのアドレスファミリーから宛先アドレスを選択するオプションを提供するために使用されます。このアドレスは、Map-Requestメッセージの送信者のルーティング可能なRLOCアドレスである必要があります。
EID mask-len: This is the mask length for the EID-Prefix.
EID mask-len：これはEID-Prefixのマスク長です。
EID-Prefix-AFI: This is the address family of the EID-Prefix according to [AFI].
EID-Prefix-AFI：これは、[AFI]によるEID-Prefixのアドレスファミリです。
EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family. When a Map-Request is sent by an ITR because a data packet is received for a destination where there is no mapping entry, the EID-Prefix is set to the destination IP address of the data packet, and the 'EID mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR wants to query a site about the status of a mapping it already has cached, the EID-Prefix used in the Map-Request has the same mask length as the EID-Prefix returned from the site when it sent a Map-Reply message.
EIDプレフィックス：このプレフィックスは、IPv4アドレスファミリの場合は4オクテット、IPv6アドレスファミリの場合は16オクテットです。マッピングエントリがない宛先のデータパケットが受信されたためにMap-RequestがITRによって送信された場合、EID-Prefixはデータパケットの宛先IPアドレスに設定され、「EID mask-len」 IPv4またはIPv6の場合、それぞれ32または128に設定されます。 xTRがすでにキャッシュしているマッピングのステータスについてサイトに問い合わせたい場合、Map-Requestで使用されるEID-Prefixは、サイトがMap-Replyを送信したときに返されたEID-Prefixと同じマスク長を持っています。メッセージ。
Map-Reply Record: When the M-bit is set, this field is the size of a single "Record" in the Map-Reply format. This Map-Reply record contains the EID-to-RLOC mapping entry associated with the Source EID. This allows the ETR that will receive this Map-Request to cache the data if it chooses to do so.
Map-Replyレコード：Mビットが設定されている場合、このフィールドはMap-Replyフォーマットの単一の「レコード」のサイズです。このMap-Replyレコードには、ソースEIDに関連付けられたEID-to-RLOCマッピングエントリが含まれています。これにより、このMap-Requestを受信するETRは、必要に応じてデータをキャッシュすることができます。
A Map-Request is sent from an ITR when it needs a mapping for an EID, wants to test an RLOC for reachability, or wants to refresh a mapping before TTL expiration. For the initial case, the destination IP address used for the Map-Request is the data packet's destination address (i.e., the destination EID) that had a mapping cache lookup failure. For the latter two cases, the destination IP address used for the Map-Request is one of the RLOC addresses from the Locator-Set of the Map-Cache entry. The source address is either an IPv4 or IPv6 RLOC address, depending on whether the Map-Request is using an IPv4 or IPv6 header, respectively. In all cases, the UDP source port number for the Map-Request message is a 16-bit value selected by the ITR/PITR, and the UDP destination port number is set to the well-known destination port number 4342. A successful Map-Reply, which is one that has a nonce that matches an outstanding Map-Request nonce, will update the cached set of RLOCs associated with the EID-Prefix range.
Map-Requestは、EIDのマッピングが必要な場合、RLOCの到達可能性をテストする場合、またはTTLの有効期限が切れる前にマッピングを更新する場合に、ITRから送信されます。最初のケースでは、Map-Requestに使用される宛先IPアドレスは、マッピングキャッシュのルックアップに失敗したデータパケットの宛先アドレス（つまり、宛先EID）です。後者の2つの場合、Map-Requestに使用される宛先IPアドレスは、Map-CacheエントリのLocator-SetからのRLOCアドレスの1つです。送信元アドレスは、Map-RequestがそれぞれIPv4またはIPv6ヘッダーを使用しているかどうかに応じて、IPv4またはIPv6 RLOCアドレスのいずれかです。すべての場合において、Map-RequestメッセージのUDPソースポート番号は、ITR / PITRによって選択された16ビット値であり、UDP宛先ポート番号は、既知の宛先ポート番号4342に設定されています。応答は、未解決のMap-Requestナンスと一致するナンスを持つものであり、EIDプレフィックス範囲に関連付けられたRLOCのキャッシュされたセットを更新します。
One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC-Address') fields MUST be filled in by the ITR. The number of fields (minus 1) encoded MUST be placed in the 'IRC' field. The ITR MAY include all locally configured Locators in this list or just provide one locator address from each address family it supports. If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-Request.
1つ以上のMap-Request（ 'ITR-RLOC-AFI'、 'ITR-RLOC-Address'）フィールドは、ITRによって入力される必要があります。エンコードされたフィールドの数（マイナス1）は、「IRC」フィールドに配置する必要があります。 ITRは、ローカルに構成されたすべてのロケーターをこのリストに含めるか、サポートする各アドレスファミリーから1つのロケーターアドレスを提供する場合があります。 ITRが誤ってITR-RLOCアドレスを提供しない場合、Map-ReplierはMap-Requestをドロップする必要があります。
Map-Requests can also be LISP encapsulated using UDP destination port 4342 with a LISP Type value set to "Encapsulated Control Message", when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are LISP encapsulated the same way from a Map-Server to an ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be found in [RFC6833].
Map-Requestは、UDP宛先ポート4342を使用してLISPカプセル化することもできます。ITRからMap-Resolverに送信されるとき、LISP Type値は「Encapsulated Control Message」に設定されます。同様に、Map-Requestは、Map-ServerからETRへと同じ方法でLISPカプセル化されます。カプセル化されたMap-RequestsとMap-Resolversの詳細は、[RFC6833]にあります。
Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map-Request for the same EID-Prefix be sent no more than once per second.
Map-Requestsはレート制限されている必要があります。同じEID-PrefixのMap-Requestは、1秒に1回だけ送信することをお勧めします。
An ITR that is configured with mapping database information (i.e., it is also an ETR) MAY optionally include those mappings in a Map-Request. When an ETR configured to accept and verify such "piggybacked" mapping data receives such a Map-Request and it does not have this mapping in the map-cache, it MAY originate a "verifying Map-Request", addressed to the map-requesting ITR and the ETR MAY add a Map-Cache entry. If the ETR has a Map-Cache entry that matches the "piggybacked" EID and the RLOC is in the Locator-Set for the entry, then it may send the "verifying Map-Request" directly to the originating Map-Request source. If the RLOC is not in the Locator-Set, then the ETR MUST send the "verifying Map-Request" to the "piggybacked" EID. Doing this forces the "verifying Map-Request" to go through the mapping database system to reach the authoritative source of information about that EID, guarding against RLOC-spoofing in the "piggybacked" mapping data.
マッピングデータベース情報で構成されたITR（つまり、ETRでもある）は、オプションでそれらのマッピングをMap-Requestに含めることができます。そのような「ピギーバックされた」マッピングデータを受け入れて検証するように構成されたETRがそのようなMap-Requestを受信し、マップキャッシュにこのマッピングがない場合、マップを要求するためにアドレス指定された「検証Map-Request」を発信してもよい（MAY） ITRとETRは、Map-Cacheエントリを追加する場合があります。 ETRに「piggybacked」EIDと一致するMap-Cacheエントリがあり、RLOCがそのエントリのロケーターセットにある場合、「検証Map-Request」を発信元のMap-Requestソースに直接送信できます。 RLOCがLocator-Setにない場合、ETRは「検証中のMap-Request」を「piggybacked」EIDに送信する必要があります。これを行うと、「検証Map-Request」がマッピングデータベースシステムを通過して、そのEIDに関する信頼できる情報源に到達し、「ピギーバックされた」マッピングデータのRLOCスプーフィングから保護されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions:
Type: 2 (Map-Reply)
タイプ：2（Map-Reply）
P: This is the probe-bit, which indicates that the Map-Reply is in response to a Locator reachability probe Map-Request. The 'Nonce' field MUST contain a copy of the nonce value from the original Map-Request. See Section 6.3.2 for more details.
P：これはプローブビットです。これは、Map-ReplyがLocator到達可能性プローブMap-Requestに応答していることを示します。 「Nonce」フィールドには、元のMap-Requestからのnonce値のコピーが含まれている必要があります。詳細については、セクション6.3.2を参照してください。
E: This bit indicates that the ETR that sends this Map-Reply message is advertising that the site is enabled for the Echo-Nonce Locator reachability algorithm. See Section 6.3.1 for more details.
E：このビットは、このMap-Replyメッセージを送信するETRが、サイトでEcho-Nonce Locator到達可能性アルゴリズムが有効になっていることをアドバタイズしていることを示します。詳細については、セクション6.3.1を参照してください。
S: This is the Security bit. When set to 1, the following authentication information will be appended to the end of the Map-Reply. The detailed format of the Authentication Data Content is for further study.
S：これはセキュリティビットです。 1に設定すると、次の認証情報がMap-Replyの末尾に追加されます。認証データコンテンツの詳細なフォーマットは、今後の検討課題です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: This field MUST be set to 0 on transmit and MUST be ignored on receipt.
予約済み：このフィールドは送信時に0に設定する必要があり、受信時には無視する必要があります。
Record Count: This is the number of records in this reply message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record Count.
レコード数：これは、この応答メッセージのレコード数です。レコードは、上記の「レコード」というラベルの付いたパケットのその部分で構成され、レコードカウントに等しい回数発生します。
Nonce: This is a 24-bit value set in a Data-Probe packet, or a 64-bit value from the Map-Request is echoed in this 'Nonce' field of the Map-Reply. When a 24-bit value is supplied, it resides in the low-order 64 bits of the 'Nonce' field.
Nonce：これは、Data-Probeパケットに設定された24ビット値です。または、Map-Requestからの64ビット値が、Map-Replyのこの「Nonce」フィールドにエコーされます。 24ビット値が提供される場合、それは「ノンス」フィールドの下位64ビットに常駐します。
Record TTL: This is the time in minutes the recipient of the Map-Reply will store the mapping. If the TTL is 0, the entry SHOULD be removed from the cache immediately. If the value is 0xffffffff, the recipient can decide locally how long to store the mapping.
レコードTTL：これは、Map-Replyの受信者がマッピングを保存する分単位の時間です。 TTLが0の場合、エントリはすぐにキャッシュから削除されるべきです（SHOULD）。値が0xffffffffの場合、受信者はマッピングを保存する期間をローカルで決定できます。
Locator Count: This is the number of Locator entries. A Locator entry comprises what is labeled above as 'Loc'. The Locator count can be 0, indicating that there are no Locators for the EID-Prefix.
Locator Count：これはロケーターエントリの数です。ロケーターエントリは、上記の「Loc」というラベルの付いたもので構成されます。ロケーターカウントは0にすることができ、EIDプレフィックスにロケーターがないことを示します。
EID mask-len: This is the mask length for the EID-Prefix.
EID mask-len：これはEID-Prefixのマスク長です。
ACT: This 3-bit field describes Negative Map-Reply actions. In any other message type, these bits are set to 0 and ignored on receipt. These bits are used only when the 'Locator Count' field is set to 0. The action bits are encoded only in Map-Reply messages. The actions defined are used by an ITR or PITR when a destination EID matches a negative Map-Cache entry. Unassigned values should cause a Map-Cache entry to be created, and when packets match this negative cache entry, they will be dropped. The current assigned values are:
ACT：この3ビットのフィールドは、否定的なMap-Replyアクションを記述します。その他のメッセージタイプでは、これらのビットは0に設定され、受信時に無視されます。これらのビットは、「Locator Count」フィールドが0に設定されている場合にのみ使用されます。アクションビットはMap-Replyメッセージでのみエンコードされます。定義されたアクションは、宛先EIDが負のMap-Cacheエントリと一致するときにITRまたはPITRによって使用されます。値が割り当てられていない場合、Map-Cacheエントリが作成され、パケットがこのネガティブキャッシュエントリに一致すると、それらはドロップされます。現在割り当てられている値は次のとおりです。
(0) No-Action: The map-cache is kept alive, and no packet encapsulation occurs.
（0）アクションなし：マップキャッシュは維持され、パケットのカプセル化は発生しません。
(1) Natively-Forward: The packet is not encapsulated or dropped but natively forwarded.
（1）ネイティブ転送：パケットはカプセル化もドロップもされず、ネイティブ転送されます。
(2) Send-Map-Request: The packet invokes sending a Map-Request.
（2）Send-Map-Request：パケットはMap-Requestの送信を呼び出します。
(3) Drop: A packet that matches this map-cache entry is dropped. An ICMP Destination Unreachable message SHOULD be sent.
（3）ドロップ：このマップキャッシュエントリに一致するパケットがドロップされます。 ICMP宛先到達不能メッセージを送信する必要があります（SHOULD）。
A: The Authoritative bit, when sent, is always set to 1 by an ETR. When a Map-Server is proxy Map-Replying [RFC6833] for a LISP site, the Authoritative bit is set to 0. This indicates to requesting ITRs that the Map-Reply was not originated by a LISP node managed at the site that owns the EID-Prefix.
A：Authoritativeビットは、送信されると、ETRによって常に1に設定されます。 Map-ServerがLISPサイトのプロキシMap-Replying [RFC6833]である場合、Authoritativeビットは0に設定されます。これは、Map-Replyが、サイトを所有するサイトで管理されているLISPノードによって発信されなかったことをITRに要求することを示します。 EIDプレフィックス。
Map-Version Number: When this 12-bit value is non-zero, the Map-Reply sender is informing the ITR what the version number is for the EID record contained in the Map-Reply. The ETR can allocate this number internally but MUST coordinate this value with other ETRs for the site. When this value is 0, there is no versioning information conveyed. The Map-Version Number can be included in Map-Request and Map-Register messages. See Section 6.6.3 for more details.
Map-Version Number：この12ビット値がゼロ以外の場合、Map-Reply送信者はITRにMap-Replyに含まれるEIDレコードのバージョン番号を通知しています。 ETRはこの番号を内部的に割り当てることができますが、この値をサイトの他のETRと調整する必要があります。この値が0の場合、バージョン情報は伝達されません。 Map-Version Numberは、Map-RequestおよびMap-Registerメッセージに含めることができます。詳細については、セクション6.6.3を参照してください。
EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI].
EID-Prefix-AFI：[AFI]によるEID-Prefixのアドレスファミリ。
EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family.
EIDプレフィックス：このプレフィックスは、IPv4アドレスファミリの場合は4オクテット、IPv6アドレスファミリの場合は16オクテットです。
Priority: Each RLOC is assigned a unicast Priority. Lower values are more preferable. When multiple RLOCs have the same Priority, they MAY be used in a load-split fashion. A value of 255 means the RLOC MUST NOT be used for unicast forwarding.
優先度：各RLOCにはユニキャスト優先度が割り当てられます。値が小さいほど好ましい。複数のRLOCが同じ優先度を持つ場合、それらはロードスプリット方式で使用される場合があります。値255は、RLOCをユニキャスト転送に使用してはならないことを意味します。
Weight: When priorities are the same for multiple RLOCs, the Weight indicates how to balance unicast traffic between them. Weight is encoded as a relative weight of total unicast packets that match the mapping entry. For example, if there are 4 Locators in a Locator-Set, where the Weights assigned are 30, 20, 20, and 10, the first Locator will get 37.5% of the traffic, the 2nd and 3rd Locators will get 25% of the traffic, and the 4th Locator will get 12.5% of the traffic. If all Weights for a Locator-Set are equal, the receiver of the Map-Reply will decide how to load-split the traffic. See Section 6.5 for a suggested hash algorithm to distribute the load across Locators with the same Priority and equal Weight values.
重み：複数のRLOCの優先度が同じ場合、重みはそれらの間のユニキャストトラフィックのバランスをとる方法を示します。重みは、マッピングエントリに一致するユニキャストパケットの合計の相対重みとしてエンコードされます。たとえば、ロケーターセットに4つのロケーターがあり、割り当てられた重みが30、20、20、10の場合、最初のロケーターはトラフィックの37.5％を取得し、2番目と3番目のロケーターは25％のトラフィックを取得します。トラフィック、および4番目のロケーターはトラフィックの12.5％を取得します。ロケーターセットのすべての重みが等しい場合、Map-Replyの受信者は、トラフィックのロードスプリット方法を決定します。同じ優先度と同じ重み値を持つロケーター間で負荷を分散するために推奨されるハッシュアルゴリズムについては、セクション6.5を参照してください。
M Priority: Each RLOC is assigned a multicast Priority used by an ETR in a receiver multicast site to select an ITR in a source multicast site for building multicast distribution trees. A value of 255 means the RLOC MUST NOT be used for joining a multicast distribution tree. For more details, see [RFC6831].
M優先度：各RLOCには、マルチキャスト配信ツリーを構築するためにソースマルチキャストサイトでITRを選択するために、受信側マルチキャストサイトのETRによって使用されるマルチキャスト優先度が割り当てられます。値255は、RLOCがマルチキャスト配信ツリーへの参加に使用されてはならないことを意味します。詳細については、[RFC6831]を参照してください。
M Weight: When priorities are the same for multiple RLOCs, the Weight indicates how to balance building multicast distribution trees across multiple ITRs. The Weight is encoded as a relative weight (similar to the unicast Weights) of the total number of trees built to the source site identified by the EID-Prefix. If all Weights for a Locator-Set are equal, the receiver of the Map-Reply will decide how to distribute multicast state across ITRs. For more details, see [RFC6831].
M重み：複数のRLOCで優先度が同じ場合、重みは、複数のITR間でマルチキャスト配信ツリーの構築のバランスをとる方法を示します。重みは、EIDプレフィックスで識別されるソースサイトに構築されたツリーの総数の相対重み（ユニキャストの重みと同様）としてエンコードされます。ロケータセットのすべての重みが等しい場合、Map-Replyの受信者は、ITR全体にマルチキャストステートを分散する方法を決定します。詳細については、[RFC6831]を参照してください。
Unused Flags: These are set to 0 when sending and ignored on receipt.
未使用フラグ：送信時にこれらは0に設定され、受信時には無視されます。
L: When this bit is set, the Locator is flagged as a local Locator to the ETR that is sending the Map-Reply. When a Map-Server is doing proxy Map-Replying [RFC6833] for a LISP site, the L-bit is set to 0 for all Locators in this Locator-Set.
L：このビットが設定されると、ロケーターは、マップ応答を送信しているETRへのローカルロケーターとしてフラグが立てられます。 Map-ServerがLISPサイトのプロキシMap-Reply [RFC6833]を実行している場合、このロケータセットのすべてのロケータのLビットは0に設定されます。
p: When this bit is set, an ETR informs the RLOC-Probing ITR that the locator address for which this bit is set is the one being RLOC-probed and MAY be different from the source address of the Map-Reply. An ITR that RLOC-probes a particular Locator MUST use this Locator for retrieving the data structure used to store the fact that the Locator is reachable. The p-bit is set for a single Locator in the same Locator-Set. If an implementation sets more than one p-bit erroneously, the receiver of the Map-Reply MUST select the first Locator. The p-bit MUST NOT be set for Locator-Set records sent in Map-Request and Map-Register messages.
p：このビットが設定されている場合、ETRはRLOCプローブITRに、このビットが設定されているロケーターアドレスがRLOCプローブ対象であり、Map-Replyのソースアドレスとは異なる可能性があることを通知します。 RLOCが特定のロケーターをプローブするITRは、ロケーターが到達可能であるという事実を格納するために使用されるデータ構造を取得するためにこのロケーターを使用する必要があります。 pビットは、同じロケーターセット内の単一のロケーターに設定されます。実装が誤って複数のpビットを設定する場合、Map-Replyの受信者は最初のロケーターを選択する必要があります。 Map-RequestおよびMap-Registerメッセージで送信されるLocator-Setレコードにpビットを設定してはなりません（MUST NOT）。
R: This is set when the sender of a Map-Reply has a route to the Locator in the Locator data record. This receiver may find this useful to know if the Locator is up but not necessarily reachable from the receiver's point of view. See also Section 6.4 for another way the R-bit may be used.
R：これは、Map-Replyの送信者がロケーターデータレコードのロケーターへのルートを持っている場合に設定されます。このレシーバーは、ロケーターが起動しているかどうかを知るのに役立ちますが、必ずしもレシーバーの観点から到達できるとは限りません。 Rビットを使用する別の方法については、セクション6.4も参照してください。
Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to an ETR. Note that the destination RLOC address MAY be an anycast address. A source RLOC can be an anycast address as well. The source or destination RLOC MUST NOT be the broadcast address (255.255.255.255 or any subnet broadcast address known to the router) and MUST NOT be a link-local multicast address. The source RLOC MUST NOT be a multicast address. The destination RLOC SHOULD be a multicast address if it is being mapped from a multicast destination EID.
ロケーター：これは、ETRに割り当てられたIPv4またはIPv6アドレス（「Loc-AFI」フィールドによってエンコードされる）です。宛先RLOCアドレスはエニーキャストアドレスである場合があります。ソースRLOCは、エニーキャストアドレスにすることもできます。ソースまたは宛先のRLOCは、ブロードキャストアドレス（255.255.255.255またはルーターが認識しているサブネットブロードキャストアドレス）であってはならず、リンクローカルマルチキャストアドレスであってはなりません。ソースRLOCはマルチキャストアドレスであってはなりません。宛先RLOCは、マルチキャスト宛先EIDからマッピングされる場合、マルチキャストアドレスである必要があります（SHOULD）。
A Map-Reply returns an EID-Prefix with a prefix length that is less than or equal to the EID being requested. The EID being requested is either from the destination field of an IP header of a Data-Probe or the EID record of a Map-Request. The RLOCs in the Map-Reply are globally routable IP addresses of all ETRs for the LISP site. Each RLOC conveys status reachability but does not convey path reachability from a requester's perspective. Separate testing of path reachability is required. See Section 6.3 for details.
Map-Replyは、要求されているEID以下のプレフィックス長のEID-Prefixを返します。要求されているEIDは、Data-ProbeのIPヘッダーの宛先フィールド、またはMap-RequestのEIDレコードのいずれかです。 Map-ReplyのRLOCは、LISPサイトのすべてのETRのグローバルにルーティング可能なIPアドレスです。各RLOCはステータスの到達可能性を伝達しますが、要求者の観点からはパスの到達可能性を伝達しません。パスの到達可能性を個別にテストする必要があります。詳細については、セクション6.3を参照してください。
Note that a Map-Reply may contain different EID-Prefix granularity (prefix + length) than the Map-Request that triggers it. This might occur if a Map-Request were for a prefix that had been returned by an earlier Map-Reply. In such a case, the requester updates its cache with the new prefix information and granularity. For example, a requester with two cached EID-Prefixes that are covered by a Map-Reply containing one less-specific prefix replaces the entry with the less-specific EID-Prefix. Note that the reverse, replacement of one less-specific prefix with multiple more-specific prefixes, can also occur, not by removing the less-specific prefix but rather by adding the more-specific prefixes that, during a lookup, will override the less-specific prefix.
Map-Replyには、それをトリガーするMap-Requestとは異なるEID-Prefixの細分性（接頭辞+長さ）が含まれる場合があることに注意してください。これは、Map-Requestが以前のMap-Replyによって返されたプレフィックスに対するものであった場合に発生する可能性があります。このような場合、リクエスタは新しいプレフィックス情報と粒度でキャッシュを更新します。たとえば、1つの固有性の低い接頭辞を含むMap-Replyでカバーされる2つのキャッシュされたEID接頭辞を持つリクエスタは、エントリを固有性の低いEID接頭辞に置き換えます。逆に、特定性の低い接頭辞を複数の特定性の高い接頭辞に置き換えることもできます。これは、特定性の低い接頭辞を削除するのではなく、より具体的な接頭辞を追加することにより、ルックアップ中に、より少ない優先度を上書きします。固有の接頭辞。
When an ETR is configured with overlapping EID-Prefixes, a Map-Request with an EID that best matches any EID-Prefix MUST be returned in a single Map-Reply message. For instance, if an ETR had database mapping entries for EID-Prefixes:
ETRが重複するEIDプレフィックスで構成されている場合、EIDプレフィックスに最も一致するEIDを持つMap-Requestが単一のMap-Replyメッセージで返される必要があります。たとえば、ETRにEIDプレフィックスのデータベースマッピングエントリがあった場合：
10.0.0.0/8 10.1.0.0/16 10.1.1.0/24 10.1.2.0/24
１０。０。０。０／８ １０。１。０。０／１６ １０。１。１。０／２４ １０。１。２。０／２４
A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record count of 1 to be returned with a mapping record EID-Prefix of 10.1.1.0/24.
EID 10.1.1.1のMap-Requestにより、レコードカウントが1のMap-Replyが、マッピングレコードEID-Prefixが10.1.1.0/24で返されます。
A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a record count of 3 to be returned with mapping records for EID-Prefixes 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24.
EID 10.1.5.5のMap-Requestは、EIDプレフィックス10.1.0.0/16、10.1.1.0/24、および10.1.2.0/24のマッピングレコードとともに、レコード数3のMap-Replyを返します。
Note that not all overlapping EID-Prefixes need to be returned but only the more-specific entries (note that in the second example above 10.0.0.0/8 was not returned for requesting EID 10.1.5.5) for the matching EID-Prefix of the requesting EID. When more than one EID-Prefix is returned, all SHOULD use the same Time to Live value so they can all time out at the same time. When a more-specific EID-Prefix is received later, its Time to Live value in the Map-Reply record can be stored even when other less-specific entries exist. When a less-specific EID-Prefix is received later, its map-cache expiration time SHOULD be set to the minimum expiration time of any more-specific EID-Prefix in the map-cache. This is done so the integrity of the EID-Prefix set is wholly maintained and so no more-specific entries are removed from the map-cache while keeping less-specific entries.
重複するすべてのEIDプレフィックスを返す必要があるわけではないことに注意してください。 EIDを要求します。複数のEIDプレフィックスが返された場合、すべてが同じTime to Live値を使用して、すべてが同時にタイムアウトできるようにする必要があります（SHOULD）。より具体的なEIDプレフィックスが後で受信されると、他のそれほど具体的でないエントリが存在する場合でも、Map-ReplyレコードのTime to Live値を格納できます。固有性の低いEIDプレフィックスを後で受信した場合、そのマップキャッシュの有効期限は、マップキャッシュ内の固有性の高いEIDプレフィックスの最小有効期限に設定する必要があります（SHOULD）。これは、EIDプレフィックスセットの整合性が完全に維持されるように行われ、特定性の低いエントリを維持しながら、特定性の高いエントリがマップキャッシュから削除されることはありません。
Map-Replies SHOULD be sent for an EID-Prefix no more often than once per second to the same requesting router. For scalability, it is expected that aggregation of EID addresses into EID-Prefixes will allow one Map-Reply to satisfy a mapping for the EID addresses in the prefix range, thereby reducing the number of Map-Request messages.
Map-Repliesは、EIDプレフィックスに対して、1秒に1回以下の頻度で同じ要求ルーターに送信する必要があります。スケーラビリティのために、EIDアドレスをEIDプレフィックスに集約すると、1つのMap-Replyでプレフィックス範囲のEIDアドレスのマッピングを満たすことができるため、Map-Requestメッセージの数が削減されると予想されます。
Map-Reply records can have an empty Locator-Set. A Negative Map-Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies convey special actions by the sender to the ITR or PITR that have solicited the Map-Reply. There are two primary applications for Negative Map-Replies. The first is for a Map-Resolver to instruct an ITR or PITR when a destination is for a LISP site versus a non-LISP site, and the other is to source quench Map-Requests that are sent for non-allocated EIDs.
Map-Replyレコードには、空のロケーターセットを含めることができます。 Negative Map-Replyは、Locator-Setが空のMap-Replyです。否定的なMap-Repliesは、Map-Replyを要求した送信者によるITRまたはPITRへの特別なアクションを伝えます。 Negative Map-Repliesには2つの主要なアプリケーションがあります。 1つ目は、宛先がLISPサイトと非LISPサイトのどちらであるかをMap-ResolverがITRまたはPITRに指示することです。もう1つは、割り当てられていないEIDに送信されるMap-Requestをクェンチすることです。
For each Map-Reply record, the list of Locators in a Locator-Set MUST appear in the same order for each ETR that originates a Map-Reply message. The Locator-Set MUST be sorted in order of ascending IP address where an IPv4 locator address is considered numerically 'less than' an IPv6 locator address.
Map-Replyレコードごとに、Locator-Set内のロケーターのリストは、Map-Replyメッセージを発信する各ETRに対して同じ順序で表示される必要があります。ロケーターセットは、IPv4ロケーターアドレスが数値的にIPv6ロケーターアドレスより「小さい」と見なされるIPアドレスの昇順でソートする必要があります。
When sending a Map-Reply message, the destination address is copied from one of the 'ITR-RLOC' fields from the Map-Request. The ETR can choose a locator address from one of the address families it supports. For Data-Probes, the destination address of the Map-Reply is copied from the source address of the Data-Probe message that is invoking the reply. The source address of the Map-Reply is one of the local IP addresses chosen to allow Unicast Reverse Path Forwarding (uRPF) checks to succeed in the upstream service provider. The destination port of a Map-Reply message is copied from the source port of the Map-Request or Data-Probe, and the source port of the Map-Reply message is set to the well-known UDP port 4342.
Map-Replyメッセージを送信するとき、宛先アドレスはMap-Requestの「ITR-RLOC」フィールドの1つからコピーされます。 ETRは、サポートするアドレスファミリーの1つからロケーターアドレスを選択できます。 Data-Probesの場合、Map-Replyの宛先アドレスは、応答を呼び出しているData-Probeメッセージの送信元アドレスからコピーされます。 Map-Replyのソースアドレスは、ユニキャストリバースパスフォワーディング（uRPF）チェックを上流のサービスプロバイダーで成功させるために選択されたローカルIPアドレスの1つです。 Map-Replyメッセージの宛先ポートは、Map-RequestまたはData-Probeの送信元ポートからコピーされ、Map-Replyメッセージの送信元ポートは、既知のUDPポート4342に設定されます。
When an ETR is misconfigured or compromised, it could return coarse EID-Prefixes in Map-Reply messages it sends. The EID-Prefix could cover EID-Prefixes that are allocated to other sites, redirecting their traffic to the Locators of the compromised site.
ETRが正しく構成されていないか危険にさらされている場合、送信するMap-Replyメッセージで粗いEIDプレフィックスを返す可能性があります。 EIDプレフィックスは、他のサイトに割り当てられたEIDプレフィックスをカバーし、侵害されたサイトのロケーターにトラフィックをリダイレクトできます。
To solve this problem, there are two basic solutions that could be used. The first is to have Map-Servers proxy Map-Reply on behalf of ETRs so their registered EID-Prefixes are the ones returned in Map-Replies. Since the interaction between an ETR and Map-Server is secured with shared keys, it is easier for an ETR to detect misbehavior. The second solution is to have ITRs and PITRs cache EID-Prefixes with mask lengths that are greater than or equal to a configured prefix length. This limits the damage to a specific width of any EID-Prefix advertised but needs to be coordinated with the allocation of site prefixes. These solutions can be used independently or at the same time.
この問題を解決するために使用できる2つの基本的な解決策があります。 1つ目は、ETRに代わってMap-ServerがMap-Replyをプロキシすることです。これにより、登録されたEID-PrefixがMap-Repliesで返されます。 ETRとMap-Serverの間の相互作用は共有キーで保護されているため、ETRが誤動作を検出するのは簡単です。 2番目の解決策は、ITRとPITRに、構成されたプレフィックス長以上のマスク長を持つEIDプレフィックスをキャッシュさせることです。これにより、アドバタイズされるEIDプレフィックスの特定の幅に損傷が制限されますが、サイトプレフィックスの割り当てと調整する必要があります。これらのソリューションは、独立して、または同時に使用できます。
At the time of this writing, other approaches are being considered and researched.
この記事の執筆時点では、他のアプローチが検討および調査されています。
The usage details of the Map-Register message can be found in specification [RFC6833]. This section solely defines the message format.
Map-Registerメッセージの使用法の詳細は、仕様[RFC6833]に記載されています。このセクションでは、メッセージ形式のみを定義します。
The message is sent in UDP with a destination UDP port of 4342 and a randomly selected UDP source port number.
メッセージは、UDPで送信され、宛先UDPポートは4342、ランダムに選択されたUDP送信元ポート番号です。
The Map-Register message format is:
Map-Registerメッセージの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P| Reserved |M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions:
パケットフィールドの説明：
Type: 3 (Map-Register)
タイプ：3（Map-Register）
P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a Map-Register message requesting the Map-Server to proxy a Map-Reply. The Map-Server will send non-authoritative Map-Replies on behalf of the ETR. Details on this usage can be found in [RFC6833].
P：これはプロキシMap-Replyビットです。 1に設定すると、ETRはMap-ServerにMap-Replyのプロキシを要求するMap-Registerメッセージを送信します。 Map-Serverは、ETRの代わりに権限のないMap-Repliesを送信します。この使用法の詳細は[RFC6833]にあります。
Reserved: This field MUST be set to 0 on transmit and MUST be ignored on receipt.
予約済み：このフィールドは送信時に0に設定する必要があり、受信時には無視する必要があります。
M: This is the want-map-notify bit. When set to 1, an ETR is requesting a Map-Notify message to be returned in response to sending a Map-Register message. The Map-Notify message sent by a Map-Server is used to acknowledge receipt of a Map-Register message.
M：これは、マップ要求通知ビットです。 1に設定されている場合、ETRはMap-Registerメッセージの送信に応答してMap-Notifyメッセージを返すように要求しています。 Map-Serverによって送信されたMap-Notifyメッセージは、Map-Registerメッセージの受信を確認するために使用されます。
Record Count: This is the number of records in this Map-Register message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record Count.
レコード数：これは、このMap-Registerメッセージ内のレコード数です。レコードは、上記の「レコード」というラベルの付いたパケットのその部分で構成され、レコードカウントに等しい回数発生します。
Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register messages. Since the Map-Register message is authenticated, the 'Nonce' field is not currently used for any security function but may be in the future as part of an anti-replay solution.
ノンス：この8オクテットの「ノンス」フィールドは、Map-Registerメッセージで0に設定されます。 Map-Registerメッセージが認証されるため、「Nonce」フィールドは現在、セキュリティ機能には使用されていませんが、将来、アンチリプレイソリューションの一部として使用される可能性があります。
Key ID: This is a configured ID to find the configured Message Authentication Code (MAC) algorithm and key value used for the authentication function. See Section 14.4 for codepoint assignments.
キーID：これは、認証機能に使用される構成済みのメッセージ認証コード（MAC）アルゴリズムとキー値を見つけるための構成済みIDです。コードポイントの割り当てについては、セクション14.4を参照してください。
Authentication Data Length: This is the length in octets of the 'Authentication Data' field that follows this field. The length of the 'Authentication Data' field is dependent on the MAC algorithm used. The length field allows a device that doesn't know the MAC algorithm to correctly parse the packet.
認証データ長：これは、このフィールドに続く「認証データ」フィールドのオクテット単位の長さです。 「認証データ」フィールドの長さは、使用するMACアルゴリズムによって異なります。長さフィールドは、MACアルゴリズムを知らないデバイスがパケットを正しく解析できるようにします。
Authentication Data: This is the message digest used from the output of the MAC algorithm. The entire Map-Register payload is authenticated with this field preset to 0. After the MAC is computed, it is placed in this field. Implementations of this specification MUST include support for HMAC-SHA-1-96 [RFC2404], and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED.
認証データ：これは、MACアルゴリズムの出力から使用されるメッセージダイジェストです。 Map-Registerペイロード全体は、このフィールドが0に事前設定されて認証されます。MACが計算されると、このフィールドに配置されます。この仕様の実装には、HMAC-SHA-1-96 [RFC2404]のサポートが含まれている必要があり、HMAC-SHA-256-128 [RFC4868]のサポートが推奨されます。
The definition of the rest of the Map-Register can be found in Section 6.1.4.
Map-Registerの残りの定義は、セクション6.1.4にあります。
The usage details of the Map-Notify message can be found in specification [RFC6833]. This section solely defines the message format.
Map-Notifyメッセージの使用法の詳細は、仕様[RFC6833]に記載されています。このセクションでは、メッセージ形式のみを定義します。
The message is sent inside a UDP packet with source and destination UDP ports equal to 4342.
メッセージは、送信元および宛先UDPポートが4342に等しいUDPパケット内で送信されます。
The Map-Notify message format is:
Map-Notifyメッセージの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=4 | Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions:
パケットフィールドの説明：
Type: 4 (Map-Notify)
タイプ：4（マップ通知）
The Map-Notify message has the same contents as a Map-Register message. See the Map-Register section for field descriptions.
Map-Notifyメッセージの内容は、Map-Registerメッセージと同じです。フィールドの説明については、Map-Registerセクションを参照してください。
An Encapsulated Control Message (ECM) is used to encapsulate control packets sent between xTRs and the mapping database system described in [RFC6833].
カプセル化された制御メッセージ（ECM）は、xRFと[RFC6833]で説明されているマッピングデータベースシステムの間で送信される制御パケットをカプセル化するために使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) |
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4342 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LH |Type=8 |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header |
IH | (uses RLOC or EID addresses) |
\ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = yyyy |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCM | LISP Control Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet header descriptions:
パケットヘッダーの説明：
OH: The outer IPv4 or IPv6 header, which uses RLOC addresses in the source and destination header address fields.
OH：外部IPv4またはIPv6ヘッダー。送信元および宛先ヘッダーアドレスフィールドでRLOCアドレスを使用します。
UDP: The outer UDP header with destination port 4342. The source port is randomly allocated. The checksum field MUST be non-zero.
UDP：宛先ポート4342の外部UDPヘッダー。送信元ポートはランダムに割り当てられます。チェックサムフィールドはゼロ以外でなければなりません。
LH: Type 8 is defined to be a "LISP Encapsulated Control Message", and what follows is either an IPv4 or IPv6 header as encoded by the first 4 bits after the 'Reserved' field.
LH：タイプ8は「LISPカプセル化制御メッセージ」として定義されており、その後に続くのは「予約済み」フィールドの後の最初の4ビットでエンコードされたIPv4またはIPv6ヘッダーです。
S: This is the Security bit. When set to 1, the field following the 'Reserved' field will have the following format. The detailed format of the Authentication Data Content is for further study.
S：これはセキュリティビットです。 1に設定すると、「予約済み」フィールドに続くフィールドは次の形式になります。認証データコンテンツの詳細なフォーマットは、今後の検討課題です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID addresses in the header address fields. When a Map-Request is encapsulated in this packet format, the destination address in this header is an EID.
IH：内部IPv4またはIPv6ヘッダー。ヘッダーアドレスフィールドでRLOCまたはEIDアドレスを使用できます。 Map-Requestがこのパケット形式でカプセル化される場合、このヘッダーの宛先アドレスはEIDです。
UDP: The inner UDP header, where the port assignments depend on the control packet being encapsulated. When the control packet is a Map-Request or Map-Register, the source port is selected by the ITR/PITR and the destination port is 4342. When the control packet is a Map-Reply, the source port is 4342 and the destination port is assigned from the source port of the invoking Map-Request. Port number 4341 MUST NOT be assigned to either port. The checksum field MUST be non-zero.
UDP：内部UDPヘッダー。ポートの割り当ては、カプセル化される制御パケットによって異なります。制御パケットがMap-RequestまたはMap-Registerの場合、送信元ポートはITR / PITRによって選択され、宛先ポートは4342です。制御パケットがMap-Replyの場合、送信元ポートは4342で宛先ポートは呼び出し元のMap-Requestの送信元ポートから割り当てられます。ポート番号4341はどちらのポートにも割り当ててはなりません。チェックサムフィールドはゼロ以外でなければなりません。
LCM: The format is one of the control message formats described in this section. At this time, only Map-Request messages are allowed to be encapsulated. In the future, PIM Join/Prune messages [RFC6831] might be allowed. Encapsulating other types of LISP control messages is for further study. When Map-Requests are sent for RLOC-Probing purposes (i.e., the probe-bit is set), they MUST NOT be sent inside Encapsulated Control Messages.
LCM：フォーマットは、このセクションで説明する制御メッセージフォーマットの1つです。現時点では、Map-Requestメッセージのみをカプセル化できます。将来的には、PIM Join / Pruneメッセージ[RFC6831]が許可される可能性があります。他のタイプのLISP制御メッセージのカプセル化は、今後の検討課題です。 Map-RequestsがRLOC-Probingの目的で送信される場合（つまり、プローブビットが設定されている場合）、それらはカプセル化された制御メッセージ内で送信してはなりません（MUST NOT）。
Both the client-side and server-side may need control over the selection of RLOCs for conversations between them. This control is achieved by manipulating the 'Priority' and 'Weight' fields in EID-to-RLOC Map-Reply messages. Alternatively, RLOC information MAY be gleaned from received tunneled packets or EID-to-RLOC Map-Request messages.
クライアント側とサーバー側の両方で、RLOC間の選択のための制御が必要になる場合があります。この制御は、EID-to-RLOC Map-Replyメッセージの「Priority」フィールドと「Weight」フィールドを操作することで実現されます。または、RLOC情報は、受信したトンネルパケットまたはEID-to-RLOC Map-Requestメッセージから収集される場合があります。
The following are different scenarios for choosing RLOCs and the controls that are available:
以下は、RLOCと利用可能なコントロールを選択するためのさまざまなシナリオです。
o The server-side returns one RLOC. The client-side can only use one RLOC. The server-side has complete control of the selection.
o サーバー側は1つのRLOCを返します。クライアント側で使用できるRLOCは1つだけです。サーバー側は選択を完全に制御します。
o The server-side returns a list of RLOCs where a subset of the list has the same best Priority. The client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and load-splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable.
oサーバー側はRLOCのリストを返し、リストのサブセットは同じ最高の優先度を持ちます。クライアントは、サーバー側によって割り当てられた重み付けに従ってのみサブセットリストを使用できます。この場合、サーバー側はサブセットリストとメンバー全体の負荷分散の両方を制御します。クライアント側は、サブセットリストが到達不能であると判断した場合（RLOCが優先度255に設定されていない限り）、サブセットリスト外のRLOCを使用できます。一部の制御の共有が存在します。サーバー側は宛先RLOCリストと負荷分散を決定しますが、リスト内のRLOCに到達できない場合、クライアント側はこのリストの代替を使用できます。
o The server-side sets a Weight of 0 for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared by the server-side determining the list and the client determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs is unreachable.
o サーバー側は、RLOCサブセットリストの重みを0に設定します。この場合、クライアント側では、トラフィックの負荷をサブセットリスト全体に分散する方法を選択できます。制御は、リストを決定するサーバー側と負荷分散を決定するクライアントによって共有されます。この場合も、サーバーが提供するRLOCのリストにアクセスできない場合、クライアントは代替のRLOCを使用できます。
o Either side (more likely the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner-header source EID and the outer-header source RLOC of received packets. The client-side ITR controls how traffic is returned and can alternate using an outer-header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server-side ETR MUST assume that each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-Prefix encoding cannot be conveyed in data packets, the EID-to-RLOC Cache on Tunnel Routers can grow to be very large.
o どちらかの側（おそらくサーバー側のETR）は、Map-Requestを送信しないことを決定します。たとえば、サーバー側のETRがMap-Requestを送信しない場合、クライアント側のITRからRLOCを収集し、双方向のRLOCの到達可能性と優先度についてクライアント側のITRに責任を与えます。クライアント側のITR RLOCのサーバー側のETR収集は、受信したパケットの内部ヘッダーソースEIDと外部ヘッダーソースRLOCをキャッシュすることによって行われます。クライアント側のITRは、トラフィックが返される方法を制御し、外部ヘッダーソースRLOCを使用して切り替えることができます。これは、サーバー側のETRがトラフィックを返すために使用するリストに追加できます。このメソッドを使用して優先度または重みは提供されないため、サーバー側のETRは、各クライアント側のITR RLOCが重み0の同じ最高の優先度を使用すると想定する必要があります。さらに、EIDプレフィックスエンコーディングはデータパケットで伝達できないため、トンネルルータ上のEIDからRLOCへのキャッシュは非常に大きくなる可能性があります。
o A "gleaned" Map-Cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner-header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the Map-Cache entry for the "gleaned" EID and is stored and used for the time indicated from the 'TTL' field of a received Map-Reply. When a verified Map-Cache entry is stored, data gleaning no longer occurs for subsequent packets that have a source EID that matches the EID-Prefix of the verified entry.
o 受信したカプセル化されたパケットのソースRLOCから学習された「収集された」Map-Cacheエントリは、検証が完了するまで数秒間のみ保存および使用されます。検証は、受信したカプセル化されたパケットの送信元EID（内部ヘッダーIP送信元アドレス）にMap-Requestを送信することによって実行されます。この「検証中のMap-Request」への応答は、「収集された」EIDのMap-Cacheエントリに完全に入力するために使用され、受信されたMap-Replyの「TTL」フィールドから指定された時間だけ保存および使用されます。検証済みのMap-Cacheエントリが保存されると、検証済みエントリのEID-Prefixと一致するソースEIDを持つ後続のパケットのデータ収集は行われなくなります。
RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the Locator record is set to 1. When the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the RLOC. Neither the information contained in a Map-Reply nor that stored in the mapping database system provides reachability information for RLOCs. Note that reachability is not part of the mapping system and is determined using one or more of the Routing Locator reachability algorithms described in the next section.
EID-to-RLOC Map-Replyメッセージに表示されるRLOCは、ロケーターレコードのRビットが1に設定されている場合に到達可能であると見なされます。Rビットが0に設定されている場合、ITRまたはPITRは、 RLOC。 Map-Replyに含まれる情報も、マッピングデータベースシステムに格納される情報も、RLOCの到達可能性情報を提供しません。到達可能性はマッピングシステムの一部ではなく、次のセクションで説明する1つ以上のルーティングロケーター到達可能性アルゴリズムを使用して決定されることに注意してください。
Several mechanisms for determining RLOC reachability are currently defined:
RLOC到達可能性を決定するためのいくつかのメカニズムが現在定義されています。
1. An ETR may examine the Locator-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC.
1. ETRは、ITRから受信したカプセル化されたデータパケットのLISPヘッダーのLocator-Status-Bitsを調べます。 ETRがITRとしても機能していて、元のITRサイトに戻るトラフィックがある場合、このステータス情報を使用してRLOCを選択できます。
2. An ITR may receive an ICMP Network Unreachable or Host Unreachable message for an RLOC it is using. This indicates that the RLOC is likely down. Note that trusting ICMP messages may not be desirable, but neither is ignoring them completely. Implementations are encouraged to follow current best practices in treating these conditions.
2. ITRは、使用しているRLOCに対してICMPネットワーク到達不能またはホスト到達不能メッセージを受信する場合があります。これは、RLOCがダウンしている可能性があることを示しています。 ICMPメッセージを信頼することは望ましくないかもしれませんが、どちらも完全に無視するわけではないことに注意してください。実装では、これらの状態を処理する際の現在のベストプラクティスに従うことが推奨されます。
3. An ITR that participates in the global routing system can determine that an RLOC is down if no BGP Routing Information Base (RIB) route exists that matches the RLOC IP address.
3. グローバルルーティングシステムに参加しているITRは、RLOC IPアドレスと一致するBGPルーティング情報ベース（RIB）ルートが存在しない場合、RLOCがダウンしていると判断できます。
4. An ITR may receive an ICMP Port Unreachable message from a destination host. This occurs if an ITR attempts to use interworking [RFC6832] and LISP-encapsulated data is sent to a non-LISP-capable site.
4. ITRは、宛先ホストからICMPポート到達不能メッセージを受信する場合があります。これは、ITRがインターワーキング[RFC6832]の使用を試み、LISPカプセル化データが非LISP対応サイトに送信された場合に発生します。
5. An ITR may receive a Map-Reply from an ETR in response to a previously sent Map-Request. The RLOC source of the Map-Reply is likely up, since the ETR was able to send the Map-Reply to the ITR.
5. ITRは、以前に送信されたMap-Requestに応答して、ETRからMap-Replyを受信する場合があります。 ETRがMap-ReplyをITRに送信できたため、Map-ReplyのRLOCソースはおそらくアップしています。
6. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up.
6. ETRがITRからカプセル化されたパケットを受信すると、パケットの外部ヘッダーからのソースRLOCがアップしている可能性があります。
7. An ITR/ETR pair can use the Locator reachability algorithms described in this section, namely Echo-Noncing or RLOC-Probing.
7. ITR / ETRペアは、このセクションで説明されているロケーター到達可能性アルゴリズム、つまりエコーノンシングまたはRLOCプロービングを使用できます。
When determining Locator up/down reachability by examining the Locator-Status-Bits from the LISP-encapsulated data packet, an ETR will receive up-to-date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows:
LISPカプセル化データパケットのLocator-Status-Bitsを調べてロケータのアップ/ダウン到達可能性を判断する場合、ETRはカプセル化ITRからサイトのすべてのETRの到達可能性に関する最新のステータスを受け取ります。ソースサイトのCEベースのITRは、次のようにサイトIGPを使用して相互の到達可能性を判断できます。
o Under normal circumstances, each ITR will advertise a default route into the site IGP.
o 通常の状況では、各ITRがデフォルトルートをサイトIGPにアドバタイズします。
o If an ITR fails or if the upstream link to its PE fails, its default route will either time out or be withdrawn.
o ITRに障害が発生した場合、またはそのPEへのアップストリームリンクに障害が発生した場合、そのデフォルトルートはタイムアウトするか撤回されます。
Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator-Status-Bits it sets for them.
したがって、各ITRは、他のITRが設定したLocator-Status-Bitsを特定するために、他のITRが発信したデフォルトルートの有無を監視できます。
RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for the packets they encapsulate.
Map-ReplyにリストされているRLOCには、序数0〜n-1の番号が付けられます。 LISPカプセル化パケットのロケータステータスビットには、最下位ビットから始まる0からn-1までの番号が付けられています。たとえば、Map-Replyの3番目の位置にリストされているRLOCがダウンした場合（通常の値2）、サイトのすべてのITRは「Locator-Status-Bits」の3番目の最下位ビット（xxxx x0xx）をクリアしますカプセル化するパケットのフィールド。
When an ETR decapsulates a packet, it will check for any change in the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the ETR, if acting also as an ITR, will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Locator-Status-Bit returns to a value of 1. Locator-Status-Bits are associated with a Locator-Set per EID-Prefix. Therefore, when a Locator becomes unreachable, the Locator-Status-Bit that corresponds to that Locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-Prefix.
ETRがパケットをカプセル化解除するとき、「Locator-Status-Bits」フィールドの変更をチェックします。ビットが1から0に移行すると、ETRがITRとしても機能している場合、ダウンとして示されているRLOCへのパケットのカプセル化は行われません。対応するLocator-Status-Bitの値が1に戻った場合にのみ、そのRLOCの使用が再開されます。Locator-Status-Bitsは、EIDプレフィックスごとのLocator-Setに関連付けられています。したがって、ロケーターが到達不能になると、最後のMap-Replyによって返されたリスト内のそのロケーターの位置に対応するLocator-Status-Bitは、その特定のEID-Prefixに対してゼロに設定されます。
When ITRs at the site are not deployed in CE routers, the IGP can still be used to determine the reachability of Locators, provided they are injected into the IGP. This is typically done when a /32 address is configured on a loopback interface.
サイトのITRがCEルーターに展開されていない場合でも、IGPがIGPに挿入されていれば、IGPを使用してロケーターの到達可能性を判断できます。これは通常、ループバックインターフェイスで/ 32アドレスが設定されている場合に行われます。
When ITRs receive ICMP Network Unreachable or Host Unreachable messages as a method to determine unreachability, they will refrain from using Locators that are described in Locator lists of Map-Replies. However, using this approach is unreliable because many network operators turn off generation of ICMP Destination Unreachable messages.
ITRが到達不能を判別する方法としてICMPネットワーク到達不能またはホスト到達不能メッセージを受信すると、マップ応答のロケーターリストに記載されているロケーターの使用を控えます。ただし、多くのネットワークオペレータがICMP宛先到達不能メッセージの生成をオフにしているため、このアプローチの使用は信頼できません。
If an ITR does receive an ICMP Network Unreachable or Host Unreachable message, it MAY originate its own ICMP Destination Unreachable message destined for the host that originated the data packet the ITR encapsulated.
ITRがICMPネットワーク到達不能またはホスト到達不能メッセージを受信した場合、ITRがカプセル化したデータパケットを発信したホストを宛先とする独自のICMP宛先到達不能メッセージを発信する場合があります。
Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a locator address from a Locator-Set in a mapping entry matches a prefix. If it does not find one and BGP is running in the Default-Free Zone (DFZ), it can decide to not use the Locator even though the Locator-Status-Bits indicate that the Locator is up. In this case, the path from the ITR to the ETR that is assigned the Locator is not available. More details are in [LOC-ID-ARCH].
また、BGP対応のITRは、RIBを一方的に調べて、マッピングエントリのロケータセットからのロケータアドレスがプレフィックスと一致するかどうかを確認できます。それが見つからず、BGPがデフォルトフリーゾーン（DFZ）で実行されている場合、Locator-Status-BitsがLocatorが起動していることを示していても、Locatorを使用しないことを決定できます。この場合、ロケーターが割り当てられているITRからETRへのパスは使用できません。詳細は[LOC-ID-ARCH]にあります。
Optionally, an ITR can send a Map-Request to a Locator, and if a Map-Reply is returned, reachability of the Locator has been determined. Obviously, sending such probes increases the number of control messages originated by Tunnel Routers for active flows, so Locators are assumed to be reachable when they are advertised.
オプションで、ITRはMap-Requestをロケーターに送信でき、Map-Replyが返された場合、ロケーターの到達可能性が確認されています。明らかに、そのようなプローブを送信すると、アクティブフローのトンネルルーターが発信する制御メッセージの数が増えるため、ロケーターはアドバタイズされたときに到達可能であると見なされます。
This assumption does create a dependency: Locator unreachability is detected by the receipt of ICMP Host Unreachable messages. When a Locator has been determined to be unreachable, it is not used for active traffic; this is the same as if it were listed in a Map-Reply with Priority 255.
この仮定は依存関係を作成します。ロケータ到達不能は、ICMPホスト到達不能メッセージの受信によって検出されます。ロケータが到達不能であると判断された場合、アクティブなトラフィックには使用されません。これは、優先度255のMap-Replyにリストされている場合と同じです。
The ITR can test the reachability of the unreachable Locator by sending periodic Requests. Both Requests and Replies MUST be rate-limited. Locator reachability testing is never done with data packets, since that increases the risk of packet loss for end-to-end sessions.
ITRは、定期的な要求を送信することにより、到達不能なロケータの到達可能性をテストできます。要求と返信の両方がレート制限されている必要があります。ロケータの到達可能性テストは、エンドツーエンドセッションのパケット損失のリスクを増大させるため、データパケットでは決して行われません。
When an ETR decapsulates a packet, it knows that it is reachable from the encapsulating ITR because that is how the packet arrived. In most cases, the ETR can also reach the ITR but cannot assume this to be true, due to the possibility of path asymmetry. In the presence of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT use the lack of return traffic as an indication that the ETR is unreachable. Instead, it MUST use an alternate mechanism to determine reachability.
ETRがパケットのカプセル化を解除すると、ETRはカプセル化ITRから到達可能であることを認識します。これは、その方法でパケットが到着したためです。ほとんどの場合、ETRはITRにも到達できますが、パスが非対称である可能性があるため、これが真であるとは想定できません。 ITRからETRへの単方向トラフィックフローが存在する場合、ITRは、リターントラフィックの欠如をETRに到達できないことを示すものとして使用してはなりません（SHOULD NOT）。代わりに、代替メカニズムを使用して到達可能性を判断する必要があります。
When data flows bidirectionally between Locators from different sites, a data-plane mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N- and E-bits and places a 24-bit nonce [RFC4086] in the LISP header of the next encapsulated data packet.
異なるサイトのロケーター間で双方向にデータが流れる場合、「ノンスエコー」と呼ばれるデータプレーンメカニズムを使用して、ITRとETR間の到達可能性を判断できます。 ITRがナンスエコーを要求する場合、NビットとEビットを設定し、次のカプセル化されたデータパケットのLISPヘッダーに24ビットナンス[RFC4086]を配置します。
When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR next sends a data packet to the ITR, it includes the nonce received earlier with the N-bit set and E-bit cleared. The ITR sees this "echoed nonce" and knows that the path to and from the ETR is up.
このパケットがETRによって受信されると、カプセル化されたパケットは通常どおり転送されます。次に、ETRがデータパケットをITRに送信するときに、Nビットがセットされ、Eビットがクリアされた、以前に受信されたナンスが含まれます。 ITRはこの「エコーされたナンス」を見て、ETRへの、およびETRからのパスがアップしていることを認識しています。
The ITR will set the E-bit and N-bit for every packet it sends while in the echo-nonce-request state. The time the ITR waits to process the echoed nonce before it determines the path is unreachable is variable and is a choice left for the implementation.
ITRは、echo-nonce-request状態のときに、送信するすべてのパケットにEビットとNビットを設定します。パスが到達不能であると判断する前に、ITRがエコーされたナンスの処理を待機する時間は可変であり、実装に任せる選択です。
If the ITR is receiving packets from the ETR but does not see the nonce echoed while being in the echo-nonce-request state, then the path to the ETR is unreachable. This decision may be overridden by other Locator reachability algorithms. Once the ITR determines that the path to the ETR is down, it can switch to another Locator for that EID-Prefix.
ITRがETRからパケットを受信しているが、echo-nonce-request状態の間にナンスがエコーされない場合、ETRへのパスに到達できません。この決定は、他のロケーター到達可能性アルゴリズムによってオーバーライドされる場合があります。 ITRは、ETRへのパスがダウンしていると判断すると、そのEIDプレフィックスの別のロケーターに切り替えることができます。
Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the echo nonce mechanism to operate.
「ITR」と「ETR」はここでは相対的な用語であることに注意してください。エコーナンスメカニズムが動作するには、両方のデバイスがITRとETRの両方の機能を実装している必要があります。
The ITR and ETR may both go into the echo-nonce-request state at the same time. The number of packets sent or the time during which echo nonce requests are sent is an implementation-specific setting. However, when an ITR is in the echo-nonce-request state, it can echo the ETR's nonce in the next set of packets that it encapsulates and subsequently continue sending echo-nonce-request packets.
ITRとETRの両方が同時にecho-nonce-request状態になる場合があります。送信されるパケットの数、またはエコーナンス要求が送信される時間は、実装固有の設定です。ただし、ITRがecho-nonce-request状態にある場合、ETRはカプセル化する次のパケットのセットでETRのナンスをエコーし、引き続きecho-nonce-requestパケットの送信を続けることができます。
This mechanism does not completely solve the forward path reachability problem, as traffic may be unidirectional. That is, the ETR receiving traffic at a site may not be the same device as an ITR that transmits traffic from that site, or the site-to-site traffic is unidirectional so there is no ITR returning traffic.
トラフィックは単方向である可能性があるため、このメカニズムでは、転送パスの到達可能性の問題は完全には解決されません。つまり、サイトでトラフィックを受信するETRは、そのサイトからトラフィックを送信するITRと同じデバイスではない可能性があります。または、サイト間トラフィックは単方向であるため、ITR戻りトラフィックはありません。
The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may erroneously consider the Locator unreachable. An ITR SHOULD only set the E-bit in an encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the Map-Reply message.
エコーノンスアルゴリズムは双方向です。つまり、一方の側でEビットを設定し、もう一方の側でエコーノンシングが有効になっていない場合、ナンスのエコーは発生せず、要求側は誤ってロケータに到達できないと見なす可能性があります。 ITRは、ETRがエコーノンシングに対して有効になっていることがわかっている場合にのみ、カプセル化されたデータパケットにEビットを設定する必要があります（SHOULD）。これは、Map-ReplyメッセージのEビットによって伝えられます。
Note that other Locator reachability mechanisms are being researched and can be used to compliment or even override the echo nonce algorithm. See the next section for an example of control-plane probing.
他のロケーター到達可能性メカニズムが研究されており、エコーナンスアルゴリズムを補完または上書きするために使用できることに注意してください。コントロールプレーンプローブの例については、次のセクションを参照してください。
RLOC-Probing is a method that an ITR or PITR can use to determine the reachability status of one or more Locators that it has cached in a Map-Cache entry. The probe-bit of the Map-Request and Map-Reply messages is used for RLOC-Probing.
RLOC-Probingは、ITRまたはPITRがMap-Cacheエントリにキャッシュした1つ以上のロケーターの到達可能性ステータスを判断するために使用できる方法です。 Map-RequestおよびMap-Replyメッセージのプローブビットは、RLOCプローブに使用されます。
RLOC-Probing is done in the control plane on a timer basis, where an ITR or PITR will originate a Map-Request destined to a locator address from one of its own locator addresses. A Map-Request used as an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to the mapping database system as one would when soliciting mapping data. The EID record encoded in the Map-Request is the EID-Prefix of the Map-Cache entry cached by the ITR or PITR. The ITR may include a mapping data record for its own database mapping information that contains the local EID-Prefixes and RLOCs for its site. RLOC-probes are sent periodically using a jittered timer interval.
RLOCプロービングは、コントロールプレーンでタイマーベースで行われます。この場合、ITRまたはPITRは、独自のロケーターアドレスの1つからロケーターアドレス宛てのマップ要求を発信します。 RLOCプローブとして使用されるMap-Requestはカプセル化されず、マッピングデータを要求する場合のように、Map-Serverまたはマッピングデータベースシステムに送信されません。 Map-RequestでエンコードされたEIDレコードは、ITRまたはPITRによってキャッシュされたMap-CacheエントリのEIDプレフィックスです。 ITRには、そのサイトのローカルEIDプレフィックスとRLOCを含む独自のデータベースマッピング情報のマッピングデータレコードを含めることができます。 RLOCプローブは、ジッタータイマー間隔を使用して定期的に送信されます。
When an ETR receives a Map-Request message with the probe-bit set, it returns a Map-Reply with the probe-bit set. The source address of the Map-Reply is set according to the procedure described in Section 6.1.5. The Map-Reply SHOULD contain mapping data for the EID-Prefix contained in the Map-Request. This provides the opportunity for the ITR or PITR that sent the RLOC-probe to get mapping updates if there were changes to the ETR's database mapping entries.
ETRは、プローブビットが設定されたMap-Requestメッセージを受信すると、プローブビットが設定されたMap-Replyを返します。 Map-Replyの送信元アドレスは、セクション6.1.5で説明されている手順に従って設定されます。 Map-Replyには、Map-Requestに含まれるEID-Prefixのマッピングデータを含める必要があります（SHOULD）。これは、ETRのデータベースマッピングエントリに変更があった場合に、RLOCプローブを送信したITRまたはPITRがマッピング更新を取得する機会を提供します。
There are advantages and disadvantages of RLOC-Probing. The greatest benefit of RLOC-Probing is that it can handle many failure scenarios allowing the ITR to determine when the path to a specific Locator is reachable or has become unreachable, thus providing a robust mechanism for switching to using another Locator from the cached Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) estimates between a pair of Locators, which can be useful for network management purposes as well as for selecting low delay paths. The major disadvantage of RLOC-Probing is in the number of control messages required and the amount of bandwidth used to obtain those benefits, especially if the requirement for failure detection times is very small.
RLOC-Probingには長所と短所があります。 RLOCプローブの最大の利点は、ITRが特定のロケーターへのパスが到達可能または到達不能になったときにITRが判断できるように、多くの障害シナリオを処理できるため、キャッシュされたロケーターから別のロケーターの使用に切り替えるための堅牢なメカニズムを提供することです。 RLOC-Probingは、ロケーターのペア間でおおよそのラウンドトリップ時間（RTT）見積もりを提供することもできます。これは、ネットワーク管理の目的と低遅延パスの選択に役立ちます。 RLOCプロービングの主な欠点は、特に障害検出時間の要件が非常に小さい場合に、必要な制御メッセージの数とそれらの利点を得るために使用される帯域幅の量にあります。
Continued research and testing will attempt to characterize the tradeoffs of failure detection times versus message overhead.
継続的な調査とテストにより、障害検出時間とメッセージのオーバーヘッドのトレードオフを特徴付けることが試みられます。
A site may be multihomed using two or more ETRs. The hosts and infrastructure within a site will be addressed using one or more EID-Prefixes that are mapped to the RLOCs of the relevant ETRs in the mapping system. One possible failure mode is for an ETR to lose reachability to one or more of the EID-Prefixes within its own site. When this occurs when the ETR sends Map-Replies, it can clear the R-bit associated with its own Locator. And when the ETR is also an ITR, it can clear its Locator-Status-Bit in the encapsulation data header.
1つのサイトが2つ以上のETRを使用してマルチホーム化されている場合があります。サイト内のホストとインフラストラクチャは、マッピングシステムで関連するETRのRLOCにマッピングされている1つ以上のEIDプレフィックスを使用してアドレス指定されます。考えられる障害モードの1つは、ETRが自身のサイト内の1つ以上のEIDプレフィックスに到達できなくなることです。 ETRがMap-Repliesを送信するときにこれが発生すると、独自のロケーターに関連付けられているRビットをクリアできます。また、ETRがITRでもある場合、カプセル化データヘッダーのLocator-Status-Bitをクリアできます。
It is recognized that there are no simple solutions to the site partitioning problem because it is hard to know which part of the EID-Prefix range is partitioned and which Locators can reach any sub-ranges of the EID-Prefixes. This problem is under investigation with the expectation that experiments will tell us more. Note that this is not a new problem introduced by the LISP architecture. The problem exists today when a multihomed site uses BGP to advertise its reachability upstream.
EIDプレフィックス範囲のどの部分がパーティション分割されているか、およびどのロケーターがEIDプレフィックスのサブ範囲に到達できるかを知ることが難しいため、サイトのパーティション分割問題に対する簡単な解決策はないことが認識されています。この問題は調査中であり、実験によってさらに多くのことが明らかになると予想されています。これは、LISPアーキテクチャによって導入された新しい問題ではないことに注意してください。マルチホームサイトがBGPを使用して到達可能性をアップストリームにアドバタイズするときに、問題が今日存在します。
When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to a requesting ITR, the Locator-Set for the EID-Prefix may contain different Priority values for each locator address. When more than one best Priority Locator exists, the ITR can decide how to load-share traffic against the corresponding Locators.
ETRがMap-ReplyメッセージでEIDからRLOCへのマッピングを要求しているITRに提供する場合、EIDプレフィックスのロケーターセットには、ロケーターアドレスごとに異なるPriority値が含まれる場合があります。複数の最高優先度ロケーターが存在する場合、ITRは、対応するロケーターに対してトラフィックをロードシェアする方法を決定できます。
The following hash algorithm may be used by an ITR to select a Locator for a packet destined to an EID for the EID-to-RLOC mapping:
次のハッシュアルゴリズムをITRが使用して、EIDからRLOCへのマッピングのEID宛てのパケットのロケーターを選択できます。
1. Either a source and destination address hash or the traditional 5-tuple hash can be used. The traditional 5-tuple hash includes the source and destination addresses; source and destination TCP, UDP, or Stream Control Transmission Protocol (SCTP) port numbers; and the IP protocol number field or IPv6 next-protocol fields of a packet that a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and destination addresses only from the header are used to compute the hash.
1. 送信元と宛先のアドレスハッシュまたは従来の5タプルハッシュを使用できます。従来の5タプルハッシュには、送信元アドレスと宛先アドレスが含まれます。送信元と宛先のTCP、UDP、またはストリーム制御伝送プロトコル（SCTP）ポート番号。ホストがLISPサイト内から発信するパケットのIPプロトコル番号フィールドまたはIPv6ネクストプロトコルフィールド。パケットがTCP、UDP、またはSCTPパケットではない場合、ヘッダーの送信元アドレスと宛先アドレスだけがハッシュの計算に使用されます。
2. Take the hash value and divide it by the number of Locators stored in the Locator-Set for the EID-to-RLOC mapping.
2. ハッシュ値を取得し、EIDからRLOCへのマッピング用のロケーターセットに格納されているロケーターの数で割ります。
3. The remainder will yield a value of 0 to "number of Locators minus 1". Use the remainder to select the Locator in the Locator-Set.
3. 残りは、0から「ロケーターの数-1」の値になります。残りを使用して、ロケーターセットでロケーターを選択します。
Note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set. Selecting a hashed value allows core routers that are attached to Link Aggregation Groups (LAGs) to load-split the encapsulated packets across member links of such LAGs. Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets that are originated by different EIDs at the source site. A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above.
パケットがLISPカプセル化されている場合、外部UDPヘッダーの送信元ポート番号を設定する必要があることに注意してください。ハッシュ値を選択すると、リンク集約グループ（LAG）に接続されているコアルーターが、そのようなLAGのメンバーリンク間でカプセル化されたパケットを負荷分割できます。それ以外の場合、送信元サイトの異なるEIDによって発信されたパケットの場合、パケットにはITRの送信元アドレスがあるため、コアルーターは単一のフローを参照します。上記のように、ITRによって計算される送信元ポート番号の推奨設定は、内部ヘッダーの5タプルハッシュ関数です。
Many core router implementations use a 5-tuple hash to decide how to balance packet load across members of a LAG. The 5-tuple hash includes the source and destination addresses of the packet and the source and destination ports when the protocol number in the packet is TCP or UDP. For this reason, UDP encoding is used for LISP encapsulation.
多くのコアルーター実装では、5タプルハッシュを使用して、LAGのメンバー間でパケットの負荷を分散する方法を決定しています。 5タプルハッシュには、パケットのプロトコル番号がTCPまたはUDPの場合、パケットの送信元アドレスと宛先アドレス、および送信元ポートと宛先ポートが含まれます。このため、LISPカプセル化にはUDPエンコーディングが使用されます。
Since the LISP architecture uses a caching scheme to retrieve and store EID-to-RLOC mappings, the only way an ITR can get a more up-to-date mapping is to re-request the mapping. However, the ITRs do not know when the mappings change, and the ETRs do not keep track of which ITRs requested its mappings. For scalability reasons, we want to maintain this approach but need to provide a way for ETRs to change their mappings and inform the sites that are currently communicating with the ETR site using such mappings.
LISPアーキテクチャはキャッシング方式を使用してEIDからRLOCへのマッピングを取得および保存するため、ITRがより最新のマッピングを取得できる唯一の方法は、マッピングを再要求することです。ただし、ITRはマッピングがいつ変更されたかを認識せず、ETRはどのITRがマッピングを要求したかを追跡しません。スケーラビリティの理由から、このアプローチを維持したいが、ETRがマッピングを変更し、そのようなマッピングを使用して現在ETRサイトと通信しているサイトに通知する方法を提供する必要があります。
When adding a new Locator record in lexicographic order to the end of a Locator-Set, it is easy to update mappings. We assume that new mappings will maintain the same Locator ordering as the old mapping but will just have new Locators appended to the end of the list. So, some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. When an ITR has only an old mapping but detects bits set in the Locator-Status-Bits that correspond to Locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing Locator-Set.
新しいLocatorレコードを辞書順でLocator-Setの最後に追加すると、マッピングを簡単に更新できます。新しいマッピングは、古いマッピングと同じロケーターの順序を維持すると想定していますが、リストの最後に新しいロケーターが追加されるだけです。そのため、一部のITRは新しいマッピングを持つことができますが、他のITRはタイムアウトするまで使用される古いマッピングしかありません。 ITRは古いマッピングしか持っていないが、キャッシュしたリスト以外のロケーターに対応するLocator-Status-Bitsに設定されたビットを検出した場合、それらを単に無視します。ただし、これは、辞書順で既存のロケーターセット内のロケーターアドレスよりも大きいロケーターアドレスに対してのみ発生します。
When a Locator record is inserted in the middle of a Locator-Set, to maintain lexicographic order, the SMR procedure in Section 6.6.2 is used to inform ITRs and PITRs of the new Locator-Status-Bit mappings.
Locator-RecordがLocator-Setの途中に挿入されると、辞書式順序を維持するために、セクション6.6.2のSMR手順を使用して、ITRおよびPITRに新しいLocator-Status-Bitマッピングを通知します。
When a Locator record is removed from a Locator-Set, ITRs that have the mapping cached will not use the removed Locator because the xTRs will set the Locator-Status-Bit to 0. So, even if the Locator is in the list, it will not be used. For new mapping requests, the xTRs can set the Locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding Locator-Status-Bit to 0. This forces ITRs with old or new mappings to avoid using the removed Locator.
ロケーターレコードがロケーターセットから削除されると、マッピングがキャッシュされているITRは、削除されたロケーターを使用しません。これは、xTRがロケーターステータスビットを0に設定するためです。したがって、ロケーターがリストにある場合でも、使用されません。新しいマッピングリクエストの場合、xTRはLocator AFIを0（未指定のアドレスを示す）に設定し、対応するLocator-Status-Bitを0に設定できます。これにより、古いマッピングまたは新しいマッピングを持つITRは、削除されたロケーターの使用を回避できます。
If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the Locator-Set and new records appended to the Locator-Set. At some point, it would be useful to compact the Locator-Set so the Locator-Status-Bit settings can be efficiently packed.
長期間にわたって多くの変更がマッピングに発生した場合、Locator-Setの中央に空のレコードスロットが見つかり、Locator-Setに新しいレコードが追加されます。ある時点で、Locator-Status-Bit設定を効率的にパックできるようにLocator-Setを圧縮すると便利です。
We propose here three approaches for Locator-Set compaction: one operational mechanism and two protocol mechanisms. The operational approach uses a clock sweep method. The protocol approaches use the concept of Solicit-Map-Requests and Map-Versioning.
ここでは、ロケータセットの圧縮に関する3つのアプローチを提案します。1つの操作メカニズムと2つのプロトコルメカニズムです。運用アプローチでは、クロックスイープ方式を使用します。プロトコルアプローチは、Solicit-Map-RequestsおよびMap-Versioningの概念を使用します。
The clock sweep approach uses planning in advance and the use of count-down TTLs to time out mappings that have already been cached. The default setting for an EID-to-RLOC mapping TTL is 24 hours. So, there is a 24-hour window to time out old mappings. The following clock sweep procedure is used:
クロックスイープアプローチでは、事前に計画を立て、カウントダウンTTLを使用して、すでにキャッシュされているマッピングをタイムアウトします。 EIDからRLOCへのマッピングTTLのデフォルト設定は24時間です。したがって、古いマッピングをタイムアウトするための24時間のウィンドウがあります。次のクロックスイープ手順が使用されます。
1. 24 hours before a mapping change is to take effect, a network administrator configures the ETRs at a site to start the clock sweep window.
1. マッピングの変更が有効になる24時間前に、ネットワーク管理者はサイトでETRを構成して、クロックスイープウィンドウを開始します。
2. During the clock sweep window, ETRs continue to send Map-Reply messages with the current (unchanged) mapping records. The TTL for these mappings is set to 1 hour.
2. クロックスイープウィンドウの間、ETRは現在の（変更されていない）マッピングレコードを含むMap-Replyメッセージを送信し続けます。これらのマッピングのTTLは1時間に設定されています。
3. 24 hours later, all previous cache entries will have timed out, and any active cache entries will time out within 1 hour. During this 1-hour window, the ETRs continue to send Map-Reply messages with the current (unchanged) mapping records with the TTL set to 1 minute.
3. 24時間後、以前のすべてのキャッシュエントリがタイムアウトし、アクティブなキャッシュエントリは1時間以内にタイムアウトします。この1時間の期間中、ETRは、TTLが1分に設定された現在の（変更されていない）マッピングレコードを含むMap-Replyメッセージを送信し続けます。
4. At the end of the 1-hour window, the ETRs will send Map-Reply messages with the new (changed) mapping records. So, any active caches can get the new mapping contents right away if not cached, or in 1 minute if they had the mapping cached. The new mappings are cached with a TTL equal to the TTL in the Map-Reply.
4. 1時間の終わりに、ETRは新しい（変更された）マッピングレコードを含むMap-Replyメッセージを送信します。そのため、アクティブなキャッシュは、キャッシュされていない場合はすぐに、マッピングがキャッシュされている場合は1分で新しいマッピングコンテンツを取得できます。新しいマッピングは、Map-ReplyのTTLと等しいTTLでキャッシュされます。
Soliciting a Map-Request is a selective way for ETRs, at the site where mappings change, to control the rate they receive requests for Map-Reply messages. SMRs are also used to tell remote ITRs to update the mappings they have cached.
Map-Requestの送信請求は、マッピングが変更されるサイトでETRがMap-Replyメッセージの要求を受信するレートを制御するための選択的な方法です。 SMRは、リモートITRがキャッシュしたマッピングを更新するように指示するためにも使用されます。
Since the ETRs don't keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests (called an SMR message) from those sites to which it has been sending encapsulated data for the last minute. In particular, an ETR will send an SMR to an ITR to which it has recently sent encapsulated data.
ETRはマッピングをキャッシュしたリモートITRを追跡しないため、マッピングを更新する必要があるITRがわかりません。その結果、ETRは、最後の1分間にカプセル化されたデータを送信していたサイトからマップ要求（SMRメッセージと呼ばれます）を要求します。特に、ETRは最近カプセル化されたデータを送信したITRにSMRを送信します。
An SMR message is simply a bit set in a Map-Request message. An ITR or PITR will send a Map-Request when they receive an SMR message. Both the SMR sender and the Map-Request responder MUST rate-limit these messages. Rate-limiting can be implemented as a global rate-limiter or one rate-limiter per SMR destination.
SMRメッセージは、単にMap-Requestメッセージに設定されたビットです。 ITRまたはPITRは、SMRメッセージを受信するとMap-Requestを送信します。 SMR送信者とMap-Request応答者の両方がこれらのメッセージをレート制限する必要があります。レート制限は、グローバルレートリミッタまたはSMR宛先ごとに1つのレートリミッタとして実装できます。
The following procedure shows how an SMR exchange occurs when a site is doing Locator-Set compaction for an EID-to-RLOC mapping:
次の手順は、サイトがEIDからRLOCへのマッピングのためにロケーターセットの圧縮を行っているときに、SMR交換がどのように行われるかを示しています。
1. When the database mappings in an ETR change, the ETRs at the site begin to send Map-Requests with the SMR bit set for each Locator in each Map-Cache entry the ETR caches.
1. ETR内のデータベースマッピングが変更されると、サイトのETRは、ETRがキャッシュする各Map-Cacheエントリ内の各ロケーターに設定されたSMRビットを使用してMap-Requestを送信し始めます。
2. A remote ITR that receives the SMR message will schedule sending a Map-Request message to the source locator address of the SMR message or to the mapping database system. A newly allocated random nonce is selected, and the EID-Prefix used is the one copied from the SMR message. If the source Locator is the only Locator in the cached Locator-Set, the remote ITR SHOULD send a Map-Request to the database mapping system just in case the single Locator has changed and may no longer be reachable to accept the Map-Request.
2. SMRメッセージを受信するリモートITRは、SMRメッセージのソースロケーターアドレスまたはマッピングデータベースシステムへのMap-Requestメッセージの送信をスケジュールします。新しく割り当てられたランダムnonceが選択され、使用されるEIDプレフィックスは、SMRメッセージからコピーされたものです。ソースロケーターがキャッシュされたロケーターセット内の唯一のロケーターである場合、リモートITRは、単一のロケーターが変更され、Map-Requestを受け入れることができなくなった場合に備えて、データベースマッピングシステムにMap-Requestを送信する必要があります（SHOULD）。
3. The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply while continuing to use the cached mapping. When Map-Versioning as described in Section 6.6.3 is used, an SMR sender can detect if an ITR is using the most up-to-date database mapping.
3. リモートITRは、キャッシュされたマッピングを引き続き使用しながらMap-Replyを取得するまでMap-Requestをレート制限する必要があります。セクション6.6.3で説明されているMap-Versioningを使用すると、SMR送信者は、ITRが最新のデータベースマッピングを使用しているかどうかを検出できます。
4. The ETRs at the site with the changed mapping will reply to the Map-Request with a Map-Reply message that has a nonce from the SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate-limited. This is important to avoid Map-Reply implosion.
4. マッピングが変更されたサイトのETRは、SMRによって呼び出されたMap-Requestからのナンスを持つMap-ReplyメッセージでMap-Requestに応答します。 Map-Replyメッセージはレート制限する必要があります。これは、Map-Replyの内破を回避するために重要です。
5. The ETRs at the site with the changed mapping record the fact that the site that sent the Map-Request has received the new mapping data in the Map-Cache entry for the remote site so the Locator-Status-Bits are reflective of the new mapping for packets going to the remote site. The ETR then stops sending SMR messages.
5. マッピングが変更されたサイトのETRは、Map-Requestを送信したサイトがリモートサイトのMap-Cacheエントリで新しいマッピングデータを受信したという事実を記録するため、Locator-Status-Bitsは新しいマッピングを反映していますリモートサイトに送信されるパケットの場合。次に、ETRはSMRメッセージの送信を停止します。
Experimentation is in progress to determine the appropriate rate-limit parameters.
適切なレート制限パラメータを決定するための実験が進行中です。
For security reasons, an ITR MUST NOT process unsolicited Map-Replies. To avoid Map-Cache entry corruption by a third party, a sender of an SMR-based Map-Request MUST be verified. If an ITR receives an SMR-based Map-Request and the source is not in the Locator-Set for the stored Map-Cache entry, then the responding Map-Request MUST be sent with an EID destination to the mapping database system. Since the mapping database system is a more secure way to reach an authoritative ETR, it will deliver the Map-Request to the authoritative source of the mapping data.
セキュリティ上の理由から、ITRは一方的なMap-Repliesを処理してはなりません。サードパーティによるMap-Cacheエントリの破損を回避するには、SMRベースのMap-Requestの送信者を確認する必要があります。 ITRがSMRベースのMap-Requestを受信し、ソースが保存されたMap-CacheエントリのLocator-Setにない場合、応答するMap-RequestはEID宛先とともにマッピングデータベースシステムに送信する必要があります。マッピングデータベースシステムは、信頼できるETRに到達するためのより安全な方法であるため、Map-Requestをマッピングデータの信頼できるソースに配信します。
When an ITR receives an SMR-based Map-Request for which it does not have a cached mapping for the EID in the SMR message, it MAY not send an SMR-invoked Map-Request. This scenario can occur when an ETR sends SMR messages to all Locators in the Locator-Set it has stored in its map-cache but the remote ITRs that receive the SMR may not be sending packets to the site. There is no point in updating the ITRs until they need to send, in which case they will send Map-Requests to obtain a Map-Cache entry.
ITRが、SMRメッセージ内のEIDのキャッシュされたマッピングを持たないSMRベースのMap-Requestを受信した場合、SMRが呼び出したMap-Requestを送信しない場合があります。このシナリオは、ETRがSMRメッセージを、マップキャッシュに格納されているロケーターセット内のすべてのロケーターに送信したが、SMRを受信したリモートITRがサイトにパケットを送信していない場合に発生する可能性があります。 ITRを送信する必要があるまでITRを更新しても意味がありません。その場合は、Map-Requestを送信してMap-Cacheエントリを取得します。
When there is unidirectional packet flow between an ITR and ETR, and the EID-to-RLOC mappings change on the ETR, it needs to inform the ITR so encapsulation to a removed Locator can stop and can instead be started to a new Locator in the Locator-Set.
ITRとETRの間に一方向のパケットフローがあり、ETRでEIDからRLOCへのマッピングが変更された場合、削除されたロケーターへのカプセル化が停止し、代わりに新しいロケーターへの開始が可能になるように、ITRに通知する必要があります。ロケータセット。
An ETR, when it sends Map-Reply messages, conveys its own Map-Version Number. This is known as the Destination Map-Version Number. ITRs include the Destination Map-Version Number in packets they encapsulate to the site. When an ETR decapsulates a packet and detects that the Destination Map-Version Number is less than the current version for its mapping, the SMR procedure described in Section 6.6.2 occurs.
ETRは、Map-Replyメッセージを送信するときに、独自のMap-Version番号を伝えます。これは、宛先マップバージョン番号と呼ばれます。 ITRは、サイトにカプセル化するパケットに宛先マップバージョン番号を含めます。 ETRがパケットをカプセル化解除し、宛先マップバージョン番号がそのマッピングの現在のバージョンより小さいことを検出すると、セクション6.6.2で説明されているSMR手順が発生します。
An ITR, when it encapsulates packets to ETRs, can convey its own Map-Version Number. This is known as the Source Map-Version Number. When an ETR decapsulates a packet and detects that the Source Map-Version Number is greater than the last Map-Version Number sent in a Map-Reply from the ITR's site, the ETR will send a Map-Request to one of the ETRs for the source site.
ITRは、ETRへのパケットをカプセル化するときに、独自のマップバージョン番号を伝達できます。これは、ソースマップバージョン番号と呼ばれます。 ETRがパケットのカプセル化を解除し、ソースMap-Version番号がITRのサイトからMap-Replyで送信された最後のMap-Version番号より大きいことを検出すると、ETRはMap-RequestをETRの1つに送信し、ソースサイト。
A Map-Version Number is used as a sequence number per EID-Prefix, so values that are greater are considered to be more recent. A value of 0 for the Source Map-Version Number or the Destination Map-Version Number conveys no versioning information, and an ITR does no comparison with previously received Map-Version Numbers.
Map-Version NumberはEID-Prefixごとのシーケンス番号として使用されるため、値が大きいほど新しいと見なされます。ソースマップバージョン番号または宛先マップバージョン番号の値0は、バージョン情報を伝えず、ITRは以前に受信したマップバージョン番号との比較を行いません。
A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server to assure that all ETRs for a site registering to it will be synchronized according to Map-Version Number.
Map-Version番号は、Map-Registerメッセージにも含めることができます。これは、Map-Serverが、それに登録しているサイトのすべてのETRがMap-Version番号に従って確実に同期されるようにするための良い方法です。
See [RFC6834] for a more detailed analysis and description of Database Map-Versioning.
データベースマップのバージョン管理の詳細な分析と説明については、[RFC6834]を参照してください。
LISP is designed to be very "hardware-based forwarding friendly". A few implementation techniques can be used to incrementally implement LISP:
LISPは非常に「ハードウェアベースの転送フレンドリー」であるように設計されています。 LISPを段階的に実装するには、いくつかの実装手法を使用できます。
o When a tunnel-encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special Forwarding Information Base (FIB) entries for the EID-Prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that control-plane processing should be performed. The forwarding logic of testing for particular IP protocol number values is not necessary. There are a few proven cases where no changes to existing deployed hardware were needed to support the LISP data-plane.
o トンネルでカプセル化されたパケットがETRによって受信された場合、外部宛先アドレスはルーターのアドレスではない可能性があります。これにより、コントロールプレーンがハードウェアからパケットを取得することが困難になります。これは、ETR（ルーターがRLOC変換を提供するもの）によって提供されるEIDのEIDプレフィックスの特別な転送情報ベース（FIB）エントリを作成することで軽減できます。これらのFIBエントリには、コントロールプレーン処理を実行する必要があることを示すフラグが付いています。特定のIPプロトコル番号の値をテストする転送ロジックは必要ありません。 LISPデータプレーンをサポートするために、既存の展開済みハードウェアを変更する必要のない、いくつかの実証済みのケースがあります。
o On an ITR, prepending a new IP header consists of adding more octets to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action.
o ITRでは、新しいIPヘッダーを付加することは、MAC書き換え文字列にオクテットを追加し、発信カプセル化手順の一部として文字列を付加することで構成されます。 Generic Routing Encapsulation（GRE）トンネリング[RFC2784]または6to4トンネリング[RFC3056]をサポートするルーターは、すでにこのアクションをサポートしている可能性があります。
o A packet's source address or interface the packet was received on can be used to select VRF (Virtual Routing/Forwarding). The VRF's routing table can be used to find EID-to-RLOC mappings.
o パケットの送信元アドレスまたはパケットが受信されたインターフェイスを使用して、VRF（仮想ルーティング/転送）を選択できます。 VRFのルーティングテーブルを使用して、EIDからRLOCへのマッピングを見つけることができます。
For performance issues related to map-cache management, see Section 12.
マップキャッシュ管理に関連するパフォーマンスの問題については、セクション12を参照してください。
This section will explore how and where ITRs and ETRs can be deployed and will discuss the pros and cons of each deployment scenario. For a more detailed deployment recommendation, refer to [LISP-DEPLOY].
このセクションでは、ITRとETRを展開する方法と場所を検討し、各展開シナリオの長所と短所について説明します。展開に関する推奨事項の詳細については、[LISP-DEPLOY]を参照してください。
There are two basic deployment tradeoffs to consider: centralized versus distributed caches; and flat, Recursive, or Re-encapsulating Tunneling. When deciding on centralized versus distributed caching, the following issues should be considered:
検討すべき2つの基本的な配置トレードオフがあります。集中型キャッシュと分散型キャッシュ。そして、フラット、再帰的、または再カプセル化トンネリング。集中型キャッシュと分散型キャッシュを決定するときは、次の問題を考慮する必要があります。
o Are the Tunnel Routers spread out so that the caches are spread across all the memories of each router? A centralized cache is when an ITR keeps a cache for all the EIDs it is encapsulating to. The packet takes a direct path to the destination Locator. A distributed cache is when an ITR needs help from other re-encapsulating routers because it does not store all the cache entries for the EIDs it is encapsulating to. So, the packet takes a path through re-encapsulating routers that have a different set of cache entries.
o キャッシュが各ルーターのすべてのメモリに分散されるように、トンネルルーターは分散していますか？集中型キャッシュとは、ITRがカプセル化するすべてのEIDのキャッシュを保持する場合です。パケットは宛先ロケーターへの直接パスをとります。分散キャッシュは、ITRがカプセル化しているEIDのすべてのキャッシュエントリを格納しないため、ITRが他の再カプセル化ルーターの助けを必要とする場合です。したがって、パケットは、キャッシュエントリの異なるセットを持つ再カプセル化ルーターを経由するパスをたどります。
o Should management "touch points" be minimized by only choosing a few Tunnel Routers, just enough for redundancy?
o 冗長性に十分な数のトンネルルータを選択するだけで、管理の「タッチポイント」を最小限に抑える必要がありますか
o In general, using more ITRs doesn't increase management load, since caches are built and stored dynamically. On the other hand, using more ETRs does require more management, since EID-Prefix-to-RLOC mappings need to be explicitly configured.
o 一般に、キャッシュは動的に構築および保存されるため、ITRを多く使用しても管理負荷は増加しません。一方、より多くのETRを使用するには、EIDプレフィックスからRLOCへのマッピングを明示的に構成する必要があるため、より多くの管理が必要になります。
When deciding on flat, Recursive, or Re-encapsulating Tunneling, the following issues should be considered:
フラット、再帰、または再カプセル化トンネリングを決定するときは、次の問題を考慮する必要があります。
o Flat tunneling implements a single tunnel between the source site and destination site. This generally offers better paths between sources and destinations with a single tunnel path.
o フラットトンネリングは、ソースサイトと宛先サイトの間に単一のトンネルを実装します。これにより、通常、単一のトンネルパスを使用して、送信元と宛先の間のパスが改善されます。
o Recursive Tunneling is when tunneled traffic is again further encapsulated in another tunnel, either to implement VPNs or to perform Traffic Engineering. When doing VPN-based tunneling, the site has some control, since the site is prepending a new tunnel header. In the case of TE-based tunneling, the site may have control if it is prepending a new tunnel header, but if the site's ISP is doing the TE, then the site has no control. Recursive Tunneling generally will result in suboptimal paths but with the benefit of steering traffic to parts of the network that have more resources available.
o再帰的トンネリングとは、VPNを実装するため、またはトラフィックエンジニアリングを実行するために、トンネル化されたトラフィックが別のトンネルに再びカプセル化されることです。 VPNベースのトンネリングを実行する場合、サイトは新しいトンネルヘッダーを付加するため、サイトがある程度制御できます。 TEベースのトンネリングの場合、サイトは新しいトンネルヘッダーを付加するかどうかを制御できますが、サイトのISPがTEを実行している場合、サイトは制御できません。再帰的トンネリングは一般に次善のパスになりますが、より多くのリソースを利用できるネットワークの部分にトラフィックをステアリングするという利点があります。
o The technique of re-encapsulation ensures that packets only require one tunnel header. So, if a packet needs to be re-routed, it is first decapsulated by the ETR and then re-encapsulated with a new tunnel header using a new RLOC.
o 再カプセル化の手法により、パケットに必要なトンネルヘッダーは1つだけになります。したがって、パケットを再ルーティングする必要がある場合、最初にETRによってカプセル化が解除され、次に新しいRLOCを使用して新しいトンネルヘッダーで再カプセル化されます。
The next sub-sections will examine where Tunnel Routers can reside in the network.
次のサブセクションでは、トンネルルーターがネットワーク内のどこに常駐できるかを調べます。
By locating Tunnel Routers close to hosts, the EID-Prefix set is at the granularity of an IP subnet. So, at the expense of more EID-Prefix-to-RLOC sets for the site, the caches in each Tunnel Router can remain relatively small. But caches always depend on the number of non-aggregated EID destination flows active through these Tunnel Routers.
ホストの近くにトンネルルーターを配置することにより、EIDプレフィックスセットはIPサブネットの細分性になります。そのため、サイトのEID-Prefix-to-RLOCセットが増える代わりに、各トンネルルーターのキャッシュを比較的小さく保つことができます。ただし、キャッシュは常に、これらのトンネルルーターを介してアクティブな非集約EID宛先フローの数に依存します。
With more Tunnel Routers doing encapsulation, the increase in control traffic grows as well: since the EID granularity is greater, more Map-Requests and Map-Replies are traveling between more routers.
カプセル化を行うトンネルルーターが増えると、制御トラフィックの増加も増加します。EIDの粒度が大きくなるため、より多くのルーター間を移動するMap-RequestsおよびMap-Repliesが増えます。
The advantage of placing the caches and databases at these stub routers is that the products deployed in this part of the network have better price-memory ratios than their core router counterparts. Memory is typically less expensive in these devices, and fewer routes are stored (only IGP routes). These devices tend to have excess capacity, both for forwarding and routing states.
キャッシュとデータベースをこれらのスタブルーターに配置することの利点は、ネットワークのこの部分に展開された製品が、対応するコアルーターよりも価格メモリ比が優れていることです。通常、これらのデバイスではメモリの方が安価であり、保存されるルートも少なくなります（IGPルートのみ）。これらのデバイスは、転送状態とルーティング状態の両方で過剰な容量を持つ傾向があります。
LISP functionality can also be deployed in edge switches. These devices generally have layer-2 ports facing hosts and layer-3 ports facing the Internet. Spare capacity is also often available in these devices.
LISP機能はエッジスイッチにも導入できます。これらのデバイスには通常、ホストに面するレイヤー2ポートとインターネットに面するレイヤー3ポートがあります。これらのデバイスでは、スペア容量も利用できることがよくあります。
Using Customer Edge (CE) routers for tunnel endpoints allows the EID space associated with a site to be reachable via a small set of RLOCs assigned to the CE routers for that site. This is the default behavior envisioned in the rest of this specification.
トンネルエンドポイントにカスタマーエッジ（CE）ルーターを使用すると、サイトに関連付けられたEIDスペースに、そのサイトのCEルーターに割り当てられた少数のRLOCを介して到達できます。これは、この仕様の残りの部分で想定されているデフォルトの動作です。
This offers the opposite benefit of the first-hop/last-hop Tunnel Router scenario: the number of mapping entries and network management touch points is reduced, allowing better scaling.
これは、ファーストホップ/ラストホップトンネルルーターシナリオとは逆の利点を提供します。マッピングエントリとネットワーク管理タッチポイントの数が削減され、より優れたスケーリングが可能になります。
One disadvantage is that fewer network resources are used to reach host endpoints, thereby centralizing the point-of-failure domain and creating network choke points at the CE router.
1つの欠点は、ホストエンドポイントに到達するために使用されるネットワークリソースが少なくなるため、障害点ドメインを集中化し、CEルーターでネットワークチョークポイントを作成することです。
Note that more than one CE router at a site can be configured with the same IP address. In this case, an RLOC is an anycast address. This allows resilience between the CE routers. That is, if a CE router fails, traffic is automatically routed to the other routers using the same anycast address. However, this comes with the disadvantage where the site cannot control the entrance point when the anycast route is advertised out from all border routers. Another disadvantage of using anycast Locators is the limited advertisement scope of /32 (or /128 for IPv6) routes.
サイトの複数のCEルーターに同じIPアドレスを設定できることに注意してください。この場合、RLOCはエニーキャストアドレスです。これにより、CEルーター間の回復力が可能になります。つまり、CEルーターに障害が発生した場合、トラフィックは同じエニーキャストアドレスを使用して他のルーターに自動的にルーティングされます。ただし、これには、エニーキャストルートがすべての境界ルーターからアドバタイズされるときに、サイトが入口を制御できないという欠点があります。エニーキャストロケーターを使用するもう1つの欠点は、/ 32（またはIPv6の場合は/ 128）ルートのアドバタイズ範囲が制限されていることです。
The use of ISP PE routers as tunnel endpoint routers is not the typical deployment scenario envisioned in this specification. This section attempts to capture some of the reasoning behind this preference for implementing LISP on CE routers.
トンネルエンドポイントルーターとしてのISP PEルーターの使用は、この仕様で想定されている典型的な展開シナリオではありません。このセクションでは、CEルーターにLISPを実装するためのこの設定の背後にあるいくつかの理由を説明します。
The use of ISP PE routers as tunnel endpoint routers gives an ISP, rather than a site, control over the location of the egress tunnel endpoints. That is, the ISP can decide whether the tunnel endpoints are in the destination site (in either CE routers or last-hop routers within a site) or at other PE edges. The advantage of this case is that two tunnel headers can be avoided. By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and re-encapsulate for a tunnel to the destination end site.
トンネルエンドポイントルーターとしてISP PEルーターを使用すると、サイトではなくISPが出力トンネルエンドポイントの場所を制御できます。つまり、ISPは、トンネルエンドポイントが宛先サイト（サイト内のCEルーターまたはラストホップルーターのいずれか）にあるか、他のPEエッジにあるかを決定できます。この場合の利点は、2つのトンネルヘッダーを回避できることです。カプセル化するパスの最初のルーターをPEにすることで、最初にTEパスを選択でき、ETRは宛先エンドサイトへのトンネルのカプセル化を解除して再カプセル化できます。
An obvious disadvantage is that the end site has no control over where its packets flow or over the RLOCs used. Other disadvantages include difficulty in synchronizing path liveness updates between CE and PE routers.
明らかな欠点は、エンドサイトがパケットのフロー場所や使用するRLOCを制御できないことです。その他の欠点としては、CEルーターとPEルーター間のパス活性更新の同期が困難なことが挙げられます。
As mentioned in earlier sections, a combination of these scenarios is possible at the expense of extra packet header overhead; if both site and provider want control, then Recursive or Re-encapsulating Tunnels are used.
前のセクションで述べたように、これらのシナリオの組み合わせは、追加のパケットヘッダーオーバーヘッドを犠牲にして可能です。サイトとプロバイダーの両方が制御を必要とする場合は、再帰的トンネルまたは再カプセル化トンネルが使用されます。
LISP routers can be deployed behind Network Address Translator (NAT) devices to provide the same set of packet services hosts have today when they are addressed out of private address space.
LISPルーターは、ネットワークアドレストランスレーター（NAT）デバイスの背後に配置して、ホストがプライベートアドレス空間の外にアドレス指定されたときに現在持っているパケットサービスと同じセットを提供できます。
It is important to note that a locator address in any LISP control message MUST be a globally routable address and therefore SHOULD NOT contain [RFC1918] addresses. If a LISP router is configured with private addresses, they MUST be used only in the outer IP header so the NAT device can translate properly. Otherwise, EID addresses MUST be translated before encapsulation is performed. Both NAT translation and LISP encapsulation functions could be co-located in the same device.
LISP制御メッセージ内のロケーターアドレスはグローバルにルーティング可能なアドレスでなければならず、したがって[RFC1918]アドレスを含むべきではないことに注意することが重要です。 LISPルーターがプライベートアドレスで構成されている場合、NATデバイスが適切に変換できるように、それらは外部IPヘッダーでのみ使用する必要があります。それ以外の場合は、カプセル化を実行する前にEIDアドレスを変換する必要があります。 NAT変換機能とLISPカプセル化機能の両方を同じデバイスに配置できます。
More details on LISP address translation can be found in [RFC6832].
LISPアドレス変換の詳細については、[RFC6832]を参照してください。
When a LISP site is using two ITRs for redundancy, the failure of one ITR will likely shift outbound traffic to the second. This second ITR's cache may not be populated with the same EID-to-RLOC mapping entries as the first. If this second ITR does not have these mappings, traffic will be dropped while the mappings are retrieved from the mapping system. The retrieval of these messages may increase the load of requests being sent into the mapping system. Deployment and experimentation will determine whether this issue requires more attention.
LISPサイトが冗長性のために2つのITRを使用している場合、1つのITRに障害が発生すると、発信トラフィックが2番目にシフトする可能性があります。この2番目のITRのキャッシュには、最初のものと同じEIDからRLOCへのマッピングエントリが読み込まれない場合があります。この2番目のITRにこれらのマッピングがない場合、マッピングシステムからマッピングが取得される間、トラフィックはドロップされます。これらのメッセージを取得すると、マッピングシステムに送信される要求の負荷が増加する可能性があります。展開と実験により、この問題にさらに注意が必要かどうかが決まります。
When a source host in a LISP site initiates a traceroute to a destination host in another LISP site, it is highly desirable for it to see the entire path. Since packets are encapsulated from the ITR to the ETR, the hop across the tunnel could be viewed as a single hop. However, LISP traceroute will provide the entire path so the user can see 3 distinct segments of the path from a source LISP host to a destination LISP host:
LISPサイトの送信元ホストが別のLISPサイトの宛先ホストへのtracerouteを開始する場合、パス全体を確認することが非常に望ましいです。パケットはITRからETRにカプセル化されるため、トンネルをまたぐホップは単一のホップと見なすことができます。ただし、LISP tracerouteはパス全体を提供するため、ユーザーはソースLISPホストから宛先LISPホストへのパスの3つの異なるセグメントを確認できます。
Segment 1 (in source LISP site based on EIDs):
セグメント1（EIDに基づくソースLISPサイト内）：
source host ---> first hop ... next hop ---> ITR
Segment 2 (in the core network based on RLOCs):
セグメント2（RLOCに基づくコアネットワーク内）：
ITR ---> next hop ... next hop ---> ETR
Segment 3 (in the destination LISP site based on EIDs):
セグメント3（EIDに基づく宛先LISPサイト内）：
ETR ---> next hop ... last hop ---> destination host
For segment 1 of the path, ICMP Time Exceeded messages are returned in the normal manner as they are today. The ITR performs a TTL decrement and tests for 0 before encapsulating. Therefore, the ITR's hop is seen by the traceroute source as having an EID address (the address of the site-facing interface).
パスのセグメント1の場合、ICMP Time Exceededメッセージは、今日と同じように通常の方法で返されます。 ITRはTTLデクリメントを実行し、カプセル化する前に0をテストします。したがって、ITRのホップは、tracerouteソースによってEIDアドレス（サイトに面したインターフェースのアドレス）を持っていると見なされます。
For segment 2 of the path, ICMP Time Exceeded messages are returned to the ITR because the TTL decrement to 0 is done on the outer header, so the destinations of the ICMP messages are the ITR RLOC address and the source RLOC address of the encapsulated traceroute packet. The ITR looks inside of the ICMP payload to inspect the traceroute source so it can return the ICMP message to the address of the traceroute client and also retain the core router IP address in the ICMP message. This is so the traceroute client can display the core router address (the RLOC address) in the traceroute output. The ETR returns its RLOC address and responds to the TTL decrement to 0, as the previous core routers did.
パスのセグメント2の場合、外部ヘッダーでTTLの0への減少が行われるため、ICMP Time ExceededメッセージがITRに返され、ICMPメッセージの宛先は、カプセル化されたtracerouteのITR RLOCアドレスとソースRLOCアドレスになります。パケット。 ITRはICMPペイロードの内部を調べてtracerouteソースを検査します。これにより、ICMPメッセージをtracerouteクライアントのアドレスに返し、ICMPメッセージにコアルーターのIPアドレスを保持できます。これは、tracerouteクライアントがtraceroute出力にコアルーターアドレス（RLOCアドレス）を表示できるようにするためです。以前のコアルーターが行ったように、ETRはRLOCアドレスを返し、TTLデクリメントに0に応答します。
For segment 3, the next-hop router downstream from the ETR will be decrementing the TTL for the packet that was encapsulated, sent into the core, decapsulated by the ETR, and forwarded because it isn't the final destination. If the TTL is decremented to 0, any router on the path to the destination of the traceroute, including the next-hop router or destination, will send an ICMP Time Exceeded message to the source EID of the traceroute client. The ICMP message will be encapsulated by the local ITR and sent back to the ETR in the originated traceroute source site, where the packet will be delivered to the host.
セグメント3の場合、ETRの下流のネクストホップルーターは、カプセル化され、コアに送信され、ETRによってカプセル化解除され、最終的な宛先ではないため転送されたパケットのTTLをデクリメントします。 TTLが0にデクリメントされると、ネクストホップルータまたは宛先を含む、tracerouteの宛先へのパス上のすべてのルータが、tracerouteクライアントのソースEIDにICMP Time Exceededメッセージを送信します。 ICMPメッセージはローカルITRによってカプセル化され、発信されたtracerouteソースサイトのETRに送り返されます。ここで、パケットはホストに配信されます。
IPv6 traceroute follows the procedure described above, since the entire traceroute data packet is included in the ICMP Time Exceeded message payload. Therefore, only the ITR needs to pay special attention to forwarding ICMP messages back to the traceroute source.
tracerouteデータパケット全体がICMP Time Exceededメッセージペイロードに含まれているため、IPv6 tracerouteは上記の手順に従います。したがって、ICMPメッセージをtracerouteソースに転送することに特に注意を払う必要があるのは、ITRだけです。
For IPv4 traceroute, we cannot follow the above procedure, since IPv4 ICMP Time Exceeded messages only include the invoking IP header and 8 octets that follow the IP header. Therefore, when a core router sends an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP payload is the encapsulated header it prepended, followed by a UDP header. The original invoking IP header, and therefore the identity of the traceroute source, is lost.
IPv4 tracerouteの場合、IPv4 ICMP Time Exceededメッセージには呼び出しIPヘッダーとIPヘッダーに続く8オクテットのみが含まれるため、上記の手順に従うことはできません。したがって、コアルーターがIPv4 Time ExceededメッセージをITRに送信すると、ICMPペイロード内のすべてのITRは、先頭に追加されたカプセル化されたヘッダーと、それに続くUDPヘッダーになります。元の呼び出しIPヘッダー、したがってtracerouteソースのIDは失われます。
The solution we propose to solve this problem is to cache traceroute IPv4 headers in the ITR and to match them up with corresponding IPv4 Time Exceeded messages received from core routers and the ETR. The ITR will use a circular buffer for caching the IPv4 and UDP headers of traceroute packets. It will select a 16-bit number as a key to find them later when the IPv4 Time Exceeded messages are received. When an ITR encapsulates an IPv4 traceroute packet, it will use the 16-bit number as the UDP source port in the encapsulating header. When the ICMP Time Exceeded message is returned to the ITR, the UDP header of the encapsulating header is present in the ICMP payload, thereby allowing the ITR to find the cached headers for the traceroute source. The ITR puts the cached headers in the payload and sends the ICMP Time Exceeded message to the traceroute source retaining the source address of the original ICMP Time Exceeded message (a core router or the ETR of the site of the traceroute destination).
この問題を解決するために提案するソリューションは、traceroute IPv4ヘッダーをITRにキャッシュし、コアルーターとETRから受信した対応するIPv4 Time Exceededメッセージと一致させることです。 ITRは循環バッファーを使用して、tracerouteパケットのIPv4およびUDPヘッダーをキャッシュします。後でIPv4 Time Exceededメッセージが受信されたときにそれらを見つけるためのキーとして16ビットの数値を選択します。 ITRがIPv4 tracerouteパケットをカプセル化するとき、カプセル化ヘッダーのUDPソースポートとして16ビット番号を使用します。 ICMP Time ExceededメッセージがITRに返されると、カプセル化ヘッダーのUDPヘッダーがICMPペイロードに存在するため、ITRはtracerouteソースのキャッシュされたヘッダーを見つけることができます。 ITRはキャッシュされたヘッダーをペイロードに入れ、元のICMP Time Exceededメッセージ（コアルーターまたはtraceroute宛先のサイトのETR）のソースアドレスを保持しているtracerouteソースにICMP Time Exceededメッセージを送信します。
The signature of a traceroute packet comes in two forms. The first form is encoded as a UDP message where the destination port is inspected for a range of values. The second form is encoded as an ICMP message where the IP identification field is inspected for a well-known value.
tracerouteパケットの署名には2つの形式があります。最初の形式は、宛先ポートの値の範囲が検査されるUDPメッセージとしてエンコードされます。 2番目の形式はICMPメッセージとしてエンコードされ、IP識別フィールドで既知の値が検査されます。
When either an IPv4 traceroute or IPv6 traceroute is originated and the ITR encapsulates it in the other address family header, one cannot get all 3 segments of the traceroute. Segment 2 of the traceroute cannot be conveyed to the traceroute source, since it is expecting addresses from intermediate hops in the same address format for the type of traceroute it originated. Therefore, in this case, segment 2 will make the tunnel look like one hop. All the ITR has to do to make this work is to not copy the inner TTL to the outer, encapsulating header's TTL when a traceroute packet is encapsulated using an RLOC from a different address family. This will cause no TTL decrement to 0 to occur in core routers between the ITR and ETR.
IPv4 tracerouteまたはIPv6 tracerouteのいずれかが生成され、ITRがそれを他のアドレスファミリヘッダーにカプセル化する場合、tracerouteの3つのセグメントすべてを取得することはできません。 tracerouteのセグメント2は、発信元のtracerouteのタイプと同じアドレス形式の中間ホップからのアドレスを期待しているため、tracerouteソースに伝達できません。したがって、この場合、セグメント2はトンネルを1つのホップのように見せます。この機能を実現するためにITRがしなければならないことは、tracerouteパケットが別のアドレスファミリのRLOCを使用してカプセル化されるときに、ヘッダーのTTLをカプセル化して内部TTLを外部にコピーしないことです。これにより、ITRとETRの間のコアルーターでTTLが0に減少することはありません。
There are several kinds of mobility, of which only some might be of concern to LISP. Essentially, they are as follows.
モビリティにはいくつかの種類がありますが、LISPで問題になるのは一部だけです。基本的には次のとおりです。
A site wishes to change its attachment points to the Internet, and its LISP Tunnel Routers will have new RLOCs when it changes upstream providers. Changes in EID-to-RLOC mappings for sites are expected to be handled by configuration, outside of LISP.
サイトはインターネットへの接続ポイントを変更したいと考えており、そのLISPトンネルルーターは、アップストリームプロバイダーを変更したときに新しいRLOCを持ちます。サイトのEIDからRLOCへのマッピングの変更は、LISP外の構成によって処理されることが期待されています。
An individual endpoint wishes to move but is not concerned about maintaining session continuity. Renumbering is involved. LISP can help with the issues surrounding renumbering [RFC4192] [LISA96] by decoupling the address space used by a site from the address spaces used by its ISPs [RFC4984].
個々のエンドポイントは移動を希望していますが、セッションの継続性の維持については心配していません。番号の付け直しが関係しています。 LISPは、サイトが使用するアドレススペースをそのISPが使用するアドレススペースから切り離すことで、番号の付け替えに関する問題[RFC4192] [LISA96]を支援できます[RFC4984]。
Fast endpoint mobility occurs when an endpoint moves relatively rapidly, changing its IP-layer network attachment point. Maintenance of session continuity is a goal. This is where the Mobile IPv4 [RFC5944] and Mobile IPv6 [RFC6275] [RFC4866] mechanisms are used and primarily where interactions with LISP need to be explored.
エンドポイントの高速モビリティは、エンドポイントが比較的速く移動し、そのIP層ネットワーク接続ポイントを変更するときに発生します。セッションの継続性の維持が目標です。これは、モバイルIPv4 [RFC5944]およびモバイルIPv6 [RFC6275] [RFC4866]メカニズムが使用される場所であり、主にLISPとの相互作用を調査する必要がある場所です。
The problem is that as an endpoint moves, it may require changes to the mapping between its EID and a set of RLOCs for its new network location. When this is added to the overhead of Mobile IP binding updates, some packets might be delayed or dropped.
問題は、エンドポイントが移動すると、そのEIDと新しいネットワークロケーションの一連のRLOC間のマッピングの変更が必要になる可能性があることです。これがモバイルIPバインディング更新のオーバーヘッドに追加されると、一部のパケットが遅延またはドロップされる可能性があります。
In IPv4 mobility, when an endpoint is away from home, packets to it are encapsulated and forwarded via a home agent that resides in the home area the endpoint's address belongs to. The home agent will encapsulate and forward packets either directly to the endpoint or to a foreign agent that resides where the endpoint has moved to. Packets from the endpoint may be sent directly to the correspondent node, may be sent via the foreign agent, or may be reverse-tunneled back to the home agent for delivery to the mobile node. As the mobile node's EID or available RLOC changes, LISP EID-to-RLOC mappings are required for communication between the mobile node and the home agent, whether via the foreign agent or not. As a mobile endpoint changes networks, up to three LISP mapping changes may be required:
IPv4モビリティでは、エンドポイントがホームから離れている場合、エンドポイントへのパケットはカプセル化され、エンドポイントのアドレスが属するホームエリアにあるホームエージェントを介して転送されます。ホームエージェントはパケットをカプセル化し、エンドポイントに直接、またはエンドポイントの移動先にある外部エージェントに転送します。エンドポイントからのパケットは、コレスポンデントノードに直接送信されるか、フォーリンエージェントを介して送信されるか、モバイルノードへの配信のためにホームエージェントにリバーストンネリングされます。モバイルノードのEIDまたは使用可能なRLOCが変更されると、モバイルエージェントとホームエージェント間の通信に、外部エージェントを介するかどうかにかかわらず、LISP EIDからRLOCへのマッピングが必要になります。モバイルエンドポイントがネットワークを変更すると、最大3つのLISPマッピングの変更が必要になる場合があります。
o The mobile node moves from an old location to a new visited network location and notifies its home agent that it has done so. The Mobile IPv4 control packets the mobile node sends pass through one of the new visited network's ITRs, which needs an EID-to-RLOC mapping for the home agent.
o モバイルノードは、古い場所から新しく訪れたネットワークの場所に移動し、移動したことをホームエージェントに通知します。モバイルノードが送信するモバイルIPv4制御パケットは、新しく訪問したネットワークのITRの1つを通過します。これには、ホームエージェントのEIDからRLOCへのマッピングが必要です。
o The home agent might not have the EID-to-RLOC mappings for the mobile node's "care-of" address or its foreign agent in the new visited network, in which case it will need to acquire them.
o ホームエージェントには、モバイルノードの「気付」アドレスのEIDからRLOCへのマッピングがない場合や、新しく訪問したネットワーク内のその外部エージェントの場合、それらを取得する必要があります。
o When packets are sent directly to the correspondent node, it may be that no traffic has been sent from the new visited network to the correspondent node's network, and the new visited network's ITR will need to obtain an EID-to-RLOC mapping for the correspondent node's site.
o パケットがコレスポンデントノードに直接送信される場合、新しい訪問先ネットワークからコレスポンデントノードのネットワークにトラフィックが送信されていない可能性があります。新しい訪問先ネットワークのITRは、コレスポンデントのEIDからRLOCへのマッピングを取得する必要があります。ノードのサイト。
In addition, if the IPv4 endpoint is sending packets from the new visited network using its original EID, then LISP will need to perform a route-returnability check on the new EID-to-RLOC mapping for that EID.
さらに、IPv4エンドポイントが元のEIDを使用して新しく訪問したネットワークからパケットを送信している場合、LISPはそのEIDの新しいEIDからRLOCへのマッピングでルートの戻り性チェックを実行する必要があります。
In IPv6 mobility, packets can flow directly between the mobile node and the correspondent node in either direction. The mobile node uses its "care-of" address (EID). In this case, the route-returnability check would not be needed but one more LISP mapping lookup may be required instead:
IPv6モビリティでは、パケットはモバイルノードとコレスポンデントノードの間を直接双方向に流れることができます。モバイルノードは「気付」アドレス（EID）を使用します。この場合、ルートの戻り性チェックは必要ありませんが、代わりにもう1つのLISPマッピングルックアップが必要になる場合があります。
o As above, three mapping changes may be needed for the mobile node to communicate with its home agent and to send packets to the correspondent node.
o 上記のように、モバイルノードがそのホームエージェントと通信し、対応するノードにパケットを送信するには、3つのマッピング変更が必要になる場合があります。
o In addition, another mapping will be needed in the correspondent node's ITR, in order for the correspondent node to send packets to the mobile node's "care-of" address (EID) at the new network location.
o さらに、コレスポンデントノードが新しいネットワークロケーションにあるモバイルノードの「気付」アドレス（EID）にパケットを送信するために、コレスポンデントノードのITRで別のマッピングが必要になります。
When both endpoints are mobile, the number of potential mapping lookups increases accordingly.
両方のエンドポイントがモバイルである場合、潜在的なマッピングルックアップの数はそれに応じて増加します。
As a mobile node moves, there are not only mobility state changes in the mobile node, correspondent node, and home agent, but also state changes in the ITRs and ETRs for at least some EID-Prefixes.
モバイルノードが移動すると、モバイルノード、コレスポンデントノード、およびホームエージェントのモビリティ状態の変化だけでなく、少なくとも一部のEIDプレフィックスのITRおよびETRの状態も変化します。
The goal is to support rapid adaptation, with little delay or packet loss for the entire system. Also, IP mobility can be modified to require fewer mapping changes. In order to increase overall system performance, there may be a need to reduce the optimization of one area in order to place fewer demands on another.
目標は、システム全体の遅延やパケット損失がほとんどない、迅速な適応をサポートすることです。また、IPモビリティを変更して、マッピングの変更を少なくすることができます。システム全体のパフォーマンスを向上させるには、ある領域の最適化を減らして、別の領域への要求を少なくする必要がある場合があります。
In LISP, one possibility is to "glean" information. When a packet arrives, the ETR could examine the EID-to-RLOC mapping and use that mapping for all outgoing traffic to that EID. It can do this after performing a route-returnability check, to ensure that the new network location does have an internal route to that endpoint. However, this does not cover the case where an ITR (the node assigned the RLOC) at the mobile-node location has been compromised.
LISPでは、1つの可能性は情報を「収集」することです。パケットが到着すると、ETRはEIDからRLOCへのマッピングを調べ、そのマッピングをそのEIDへのすべての発信トラフィックに使用できます。これは、ルートの戻り性チェックを実行した後にこれを実行して、新しいネットワークロケーションにそのエンドポイントへの内部ルートがあることを確認できます。ただし、これは、モバイルノードの場所にあるITR（RLOCが割り当てられたノード）が危険にさらされている場合には適用されません。
Mobile IP packet exchange is designed for an environment in which all routing information is disseminated before packets can be forwarded. In order to allow the Internet to grow to support expected future use, we are moving to an environment where some information may have to be obtained after packets are in flight. Modifications to IP mobility should be considered in order to optimize the behavior of the overall system. Anything that decreases the number of new EID-to-RLOC mappings needed when a node moves, or maintains the validity of an EID-to-RLOC mapping for a longer time, is useful.
モバイルIPパケット交換は、パケットを転送する前にすべてのルーティング情報が配布される環境向けに設計されています。インターネットを成長させて将来の予想される使用をサポートできるようにするために、パケットの送信後に一部の情報を取得する必要がある環境に移行しています。システム全体の動作を最適化するには、IPモビリティの変更を検討する必要があります。ノードが移動したときに必要となる新しいEIDからRLOCへのマッピングの数を減らしたり、EIDからRLOCへのマッピングの有効性を長期間維持したりすることは有用です。
In addition to endpoints, a network can be mobile, possibly changing xTRs. A "network" can be as small as a single router and as large as a whole site. This is different from site mobility in that it is fast and possibly short-lived, but different from endpoint mobility in that a whole prefix is changing RLOCs. However, the mechanisms are the same, and there is no new overhead in LISP. A map request for any endpoint will return a binding for the entire mobile prefix.
エンドポイントに加えて、ネットワークはモバイルである可能性があり、xTRを変更する可能性があります。 「ネットワーク」は、単一のルーターと同じくらい小さく、サイト全体と同じくらい大きくすることができます。これは、サイトモビリティとは異なり、高速であり、存続期間が短い可能性がありますが、エンドポイントモビリティとは異なり、プレフィックス全体がRLOCを変更します。ただし、メカニズムは同じであり、LISPに新しいオーバーヘッドはありません。エンドポイントのマップリクエストは、モバイルプレフィックス全体のバインディングを返します。
If mobile networks become a more common occurrence, it may be useful to revisit the design of the mapping service and allow for dynamic updates of the database.
モバイルネットワークがより一般的になるようになった場合は、マッピングサービスの設計を再検討して、データベースの動的更新を可能にすることが役立つ場合があります。
The issue of interactions between mobility and LISP needs to be explored further. Specific improvements to the entire system will depend on the details of mapping mechanisms. Mapping mechanisms should be evaluated on how well they support session continuity for mobile nodes.
モビリティとLISP間の相互作用の問題をさらに調査する必要があります。システム全体の具体的な改善は、マッピングメカニズムの詳細によって異なります。マッピングメカニズムは、モバイルノードのセッション継続性をどの程度サポートするかについて評価する必要があります。
A mobile device can use the LISP infrastructure to achieve mobility by implementing the LISP encapsulation and decapsulation functions and acting as a simple ITR/ETR. By doing this, such a "LISP mobile node" can use topologically independent EID IP addresses that are not advertised into and do not impose a cost on the global routing system. These EIDs are maintained at the edges of the mapping system (in LISP Map-Servers and Map-Resolvers) and are provided on demand to only the correspondents of the LISP mobile node.
モバイルデバイスはLISPインフラストラクチャを使用して、LISPカプセル化およびカプセル化解除機能を実装し、単純なITR / ETRとして機能することにより、モビリティを実現できます。これを行うことにより、そのような「LISPモバイルノード」は、アドバタイズされず、グローバルルーティングシステムにコストをかけないトポロジ的に独立したEID IPアドレスを使用できます。これらのEIDは、（LISP Map-ServersおよびMap-Resolversの）マッピングシステムのエッジで維持され、LISPモバイルノードの通信相手にのみオンデマンドで提供されます。
Refer to [LISP-MN] for more details.
詳細については、[LISP-MN]を参照してください。
A multicast group address, as defined in the original Internet architecture, is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol, and the network-based state the protocol creates, determine where the receivers are located.
マルチキャストグループアドレスは、元のインターネットアーキテクチャで定義されているように、トポロジ的に独立した受信ホストの場所のグループの識別子です。アドレスエンコーディング自体は、レシーバの場所を決定しません。マルチキャストルーティングプロトコル、およびプロトコルが作成するネットワークベースの状態によって、レシーバーの場所が決まります。
In the context of LISP, a multicast group address is both an EID and a Routing Locator. Therefore, no specific semantic or action needs to be taken for a destination address, as it would appear in an IP header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. The outer IP header (the destination Routing Locator address), prepended by a LISP router, will use the same group address as the destination Routing Locator.
LISPのコンテキストでは、マルチキャストグループアドレスはEIDとルーティングロケータの両方です。したがって、宛先アドレスはIPヘッダーに表示されるため、宛先アドレスに対して特定のセマンティックまたはアクションを実行する必要はありません。したがって、送信元ホストによって作成された内部IPヘッダーに表示されるグループアドレスは、宛先EIDとして使用されます。 LISPルーターによって付加された外部IPヘッダー（宛先ルーティングロケーターアドレス）は、宛先ルーティングロケーターと同じグループアドレスを使用します。
Having said that, only the source EID and source Routing Locator need to be dealt with. Therefore, an ITR merely needs to put its own IP address in the source 'Routing Locator' field when prepending the outer IP header. This source Routing Locator address, like any other Routing Locator address, MUST be globally routable.
そうは言っても、処理する必要があるのは、ソースEIDとソースルーティングロケーターだけです。したがって、ITRは、外部IPヘッダーを付加するときに、独自のIPアドレスをソースの「ルーティングロケーター」フィールドに入力するだけで済みます。このソースルーティングロケーターアドレスは、他のルーティングロケーターアドレスと同様に、グローバルにルーティング可能でなければなりません。
Therefore, an EID-to-RLOC mapping does not need to be performed by an ITR when a received data packet is a multicast data packet or when processing a source-specific Join (either by IGMPv3 or PIM). But the source Routing Locator is decided by the multicast routing protocol in a receiver site. That is, an EID-to-RLOC translation is done at control time.
したがって、受信されたデータパケットがマルチキャストデータパケットである場合、またはソース固有のJoinを（IGMPv3またはPIMによって）処理する場合、ITRがEIDからRLOCにマッピングする必要はありません。ただし、送信元ルーティングロケータは、受信側サイトのマルチキャストルーティングプロトコルによって決定されます。つまり、EIDからRLOCへの変換は制御時に行われます。
Another approach is to have the ITR not encapsulate a multicast packet and allow the packet built by the host to flow into the core even if the source address is allocated out of the EID namespace. If the RPF-Vector TLV [RFC5496] is used by PIM in the core, then core routers can RPF to the ITR (the locator address, which is injected into core routing) rather than the host source address (the EID address, which is not injected into core routing).
もう1つのアプローチは、ITRがマルチキャストパケットをカプセル化せず、送信元アドレスがEID名前空間の外に割り当てられている場合でも、ホストによって構築されたパケットがコアに流れるようにすることです。 RPF-Vector TLV [RFC5496]がコアのPIMで使用されている場合、コアルーターは、ホストの送信元アドレス（EIDアドレス、つまりEIDアドレス）ではなくITR（コアルーティングに挿入されるロケーターアドレス）にRPFできます。コアルーティングに挿入されません）。
To avoid any EID-based multicast state in the network core, the first approach is chosen for LISP-Multicast. Details for LISP-Multicast and interworking with non-LISP sites are described in [RFC6831] and [RFC6832].
ネットワークコアのEIDベースのマルチキャスト状態を回避するために、LISP-Multicastには最初のアプローチが選択されています。 LISPマルチキャストおよび非LISPサイトとのインターワーキングの詳細は、[RFC6831]および[RFC6832]で説明されています。
It is believed that most of the security mechanisms will be part of the mapping database service when using control-plane procedures for obtaining EID-to-RLOC mappings. For data-plane-triggered mappings, as described in this specification, protection is provided against ETR spoofing by using route-returnability (see Section 3) mechanisms evidenced by the use of a 24-bit 'Nonce' field in the LISP encapsulation header and a 64-bit 'Nonce' field in the LISP control message.
EIDからRLOCへのマッピングを取得するためにコントロールプレーン手順を使用する場合、ほとんどのセキュリティメカニズムはマッピングデータベースサービスの一部になると考えられています。この仕様で説明されているように、データプレーントリガーマッピングの場合、LISPカプセル化ヘッダーの24ビットの「ノンス」フィールドとLISP制御メッセージの64ビットの「ノンス」フィールド。
The nonce, coupled with the ITR accepting only solicited Map-Replies, provides a basic level of security, in many ways similar to the security experienced in the current Internet routing system. It is hard for off-path attackers to launch attacks against these LISP mechanisms, as they do not have the nonce values. Sending a large number of packets to accidentally find the right nonce value is possible but would already by itself be a denial-of-service (DoS) attack. On-path attackers can perform far more serious attacks, but on-path attackers can launch serious attacks in the current Internet as well, including eavesdropping, blocking, or redirecting traffic. See more discussion on this topic in Section 6.1.5.1.
nonceは、要請されたMap-Repliesのみを受け入れるITRと相まって、現在のインターネットルーティングシステムで経験されているセキュリティと同様に、基本的なレベルのセキュリティを提供します。これらのLISPメカニズムはノンス値を持たないため、オフパス攻撃者がこれらのLISPメカニズムに対して攻撃を開始することは困難です。誤って正しいnonce値を見つけるために大量のパケットを送信することは可能ですが、それ自体でサービス拒否（DoS）攻撃になる可能性があります。パス上の攻撃者ははるかに深刻な攻撃を実行できますが、パス上の攻撃者は現在のインターネットでも、トラフィックの盗聴、ブロック、リダイレクトなどの深刻な攻撃を仕掛けることができます。このトピックの詳細については、セクション6.1.5.1を参照してください。
LISP does not rely on a PKI or a more heavyweight authentication system. These systems challenge one of the primary design goals of LISP -- scalability.
LISPは、PKIまたはより重い認証システムに依存しません。これらのシステムは、LISPの主要な設計目標の1つであるスケーラビリティに挑戦します。
DoS attack prevention will depend on implementations rate-limiting Map-Requests and Map-Replies to the control plane as well as rate-limiting the number of data-triggered Map-Replies.
DoS攻撃の防止は、コントロールプレーンへのMap-RequestとMap-Repliesのレート制限の実装、およびデータによってトリガーされるMap-Repliesの数のレート制限に依存します。
An incorrectly implemented or malicious ITR might choose to ignore the Priority and Weights provided by the ETR in its Map-Reply. This traffic-steering would be limited to the traffic that is sent by this ITR's site and no more severe than if the site initiated a bandwidth DoS attack on (one of) the ETR's ingress links. The ITR's site would typically gain no benefit from not respecting the Weights and would likely receive better service by abiding by them.
正しく実装されていない、または悪意のあるITRは、マップ応答でETRによって提供される優先度と重みを無視することを選択する場合があります。このトラフィックステアリングは、このITRのサイトによって送信されるトラフィックに限定され、サイトがETRの入力リンク（のいずれか）に対して帯域幅DoS攻撃を開始した場合よりも深刻ではありません。 ITRのサイトは、通常、ウェイトを尊重しないことから利益を得ることはなく、それらを遵守することでより良いサービスを受ける可能性があります。
To deal with map-cache exhaustion attempts in an ITR/PITR, the implementation should consider putting a maximum cap on the number of entries stored with a reserve list for special or frequently accessed sites. This should be a configuration policy control set by the network administrator who manages ITRs and PITRs. When overlapping EID-Prefixes occur across multiple Map-Cache entries, the integrity of the set must be wholly maintained. So, if a more-specific entry cannot be added due to reaching the maximum cap, then none of the less-specific entries should be stored in the map-cache.
ITR / PITRでのマップキャッシュ枯渇の試行に対処するには、実装で、特別なサイトまたは頻繁にアクセスされるサイトの予約リストで保存されるエントリ数に最大制限を設けることを検討する必要があります。これは、ITRとPITRを管理するネットワーク管理者が設定する構成ポリシーコントロールである必要があります。重複するEIDプレフィックスが複数のMap-Cacheエントリで発生する場合、セットの整合性を完全に維持する必要があります。したがって、最大制限に達したために特定性の高いエントリを追加できない場合は、特定性の低いエントリをマップキャッシュに保存しないでください。
Given that the ITR/PITR maintains a cache of EID-to-RLOC mappings, cache sizing and maintenance are issues to be kept in mind during implementation. It is a good idea to have instrumentation in place to detect thrashing of the cache. Implementation experimentation will be used to determine which cache management strategies work best. In general, it is difficult to defend against cache-thrashing attacks. It should be noted that an undersized cache in an ITR/PITR not only causes adverse effects on the site or region it supports but may also cause increased Map-Request loads on the mapping system.
ITR / PITRがEIDからRLOCへのマッピングのキャッシュを維持していることを考えると、キャッシュのサイズ設定とメンテナンスは、実装時に留意すべき問題です。キャッシュのスラッシングを検出するためのインスツルメンテーションを用意することは良い考えです。実装実験を使用して、どのキャッシュ管理戦略が最適に機能するかを判断します。一般に、キャッシュスラッシング攻撃から防御することは困難です。 ITR / PITRのキャッシュが小さすぎると、サポートするサイトまたはリージョンに悪影響を及ぼすだけでなく、マッピングシステムでMap-Requestの負荷が増加する可能性があることに注意してください。
"Piggybacked" mapping data as discussed in Section 6.1.3 specifies how to handle such mappings and includes the possibility for an ETR to temporarily accept such a mapping before verification when running in "trusted" environments. In such cases, there is a potential threat that a fake mapping could be inserted (even if only for a short period) into a map-cache. As noted in Section 6.1.3, an ETR MUST be specifically configured to run in such a mode and might usefully only consider some specific ITRs as also running in that same trusted environment.
6.1.3項で説明する「ピギーバック」マッピングデータは、そのようなマッピングの処理方法を指定し、ETTが「信頼できる」環境で実行されている場合に検証前にそのようなマッピングを一時的に受け入れる可能性を含みます。このような場合、偽のマッピングが（たとえ短時間であっても）マップキャッシュに挿入される可能性があるという潜在的な脅威があります。セクション6.1.3で述べたように、ETRはそのようなモードで実行するように特別に設定する必要があり、特定のITRのみを同じ信頼できる環境で実行していると見なすこともできます。
There is a security risk implicit in the fact that ETRs generate the EID-Prefix to which they are responding. An ETR can claim a shorter prefix than it is actually responsible for. Various mechanisms to ameliorate or resolve this issue will be examined in the future [LISP-SEC].
ETRが応答するEIDプレフィックスを生成するという事実には、暗黙のセキュリティリスクがあります。 ETRは、実際に担当するよりも短い接頭辞を要求できます。この問題を改善または解決するためのさまざまなメカニズムが、今後検討されます[LISP-SEC]。
Spoofing of inner-header addresses of LISP-encapsulated packets is possible, as with any tunneling mechanism. ITRs MUST verify the source address of a packet to be an EID that belongs to the site's EID-Prefix range prior to encapsulation. An ETR must only decapsulate and forward datagrams with an inner-header destination that matches one of its EID-Prefix ranges. If, upon receipt and decapsulation, the destination EID of a datagram does not match one of the ETR's configured EID-Prefixes, the ETR MUST drop the datagram. If a LISP-encapsulated packet arrives at an ETR, it SHOULD compare the inner-header source EID address and the outer-header source RLOC address with the mapping that exists in the mapping database. Then, when spoofing attacks occur, the outer-header source RLOC address can be used to trace back the attack to the source site, using existing operational tools.
LISPカプセル化パケットの内部ヘッダーアドレスのスプーフィングは、他のトンネリングメカニズムと同様に可能です。 ITRは、カプセル化の前に、パケットのソースアドレスがサイトのEIDプレフィックス範囲に属するEIDであることを確認する必要があります。 ETRは、EIDプレフィックスの範囲のいずれかに一致する内部ヘッダーの宛先を持つデータグラムのみをカプセル化解除して転送する必要があります。受信およびカプセル化解除時に、データグラムの宛先EIDがETRの構成済みEIDプレフィックスのいずれとも一致しない場合、ETRはデータグラムをドロップする必要があります（MUST）。 LISPでカプセル化されたパケットがETRに到着すると、内部ヘッダーの送信元EIDアドレスと外部ヘッダーの送信元RLOCアドレスを、マッピングデータベースに存在するマッピングと比較する必要があります（SHOULD）。その後、スプーフィング攻撃が発生した場合、外部ヘッダーの送信元RLOCアドレスを使用して、既存の運用ツールを使用して、攻撃を送信元サイトまで追跡できます。
This experimental specification does not address automated key management (AKM). BCP 107 [RFC4107] provides guidance in this area. In addition, at the time of this writing, substantial work is being undertaken to improve security of the routing system [RFC6518] [RFC6480] [BGP-SEC] [LISP-SEC]. Future work on LISP should address the issues discussed in BCP 107 as well as other open security considerations, which may require changes to this specification.
この実験仕様では、自動キー管理（AKM）については触れていません。 BCP 107 [RFC4107]は、この領域のガイダンスを提供します。さらに、この記事の執筆時点では、ルーティングシステムのセキュリティを向上させるためにかなりの作業が行われています[RFC6518] [RFC6480] [BGP-SEC] [LISP-SEC]。 LISPに関する今後の作業では、BCP 107で説明されている問題や、この仕様の変更が必要になる可能性のあるその他のオープンセキュリティの考慮事項に対処する必要があります。
Considerations for network management tools exist so the LISP protocol suite can be operationally managed. These mechanisms can be found in [LISP-MIB] and [RFC6835].
LISPプロトコルスイートを運用管理できるように、ネットワーク管理ツールに関する考慮事項が存在します。これらのメカニズムは、[LISP-MIB]と[RFC6835]にあります。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the LISP specification, in accordance with BCP 26 [RFC5226].
このセクションでは、BCP 26 [RFC5226]に従って、LISP仕様に関連する値の登録に関するInternet Assigned Numbers Authority（IANA）へのガイダンスを提供します。
There are four namespaces (listed in the sub-sections below) in LISP that have been registered.
登録されているLISPには4つの名前空間（以下のサブセクションに記載）があります。
o LISP IANA registry allocations should not be made for purposes unrelated to LISP routing or transport protocols.
o LISP IANAレジストリの割り当ては、LISPルーティングまたはトランスポートプロトコルとは無関係の目的で行うべきではありません。
o The following policies are used here with the meanings defined in BCP 26: "Specification Required", "IETF Review", "Experimental Use", and "First Come First Served".
o 以下のポリシーは、BCP 26で定義された意味でここで使用されます：「仕様が必要です」、「IETFレビュー」、「実験的使用」、および「先着順」。
New ACT values (Section 6.1.4) can be allocated through IETF review or IESG approval. Four values have already been allocated by this specification (Section 6.1.4).
新しいACT値（セクション6.1.4）は、IETFレビューまたはIESG承認を通じて割り当てることができます。この仕様では、4つの値がすでに割り当てられています（セクション6.1.4）。
In addition, LISP has a number of flag fields and reserved fields, such as the LISP header flags field (Section 5.3). New bits for flags in these fields can be implemented after IETF review or IESG approval, but these need not be managed by IANA.
さらに、LISPには、LISPヘッダーフラグフィールド（5.3節）など、いくつかのフラグフィールドと予約フィールドがあります。これらのフィールドのフラグの新しいビットは、IETFレビューまたはIESG承認後に実装できますが、IANAで管理する必要はありません。
LISP Address [LCAF] type codes have a range from 0 to 255. New type codes MUST be allocated consecutively, starting at 0. Type Codes 0-127 are to be assigned by IETF review or IESG approval.
LISPアドレス[LCAF]タイプコードの範囲は0〜255です。新しいタイプコードは、0から開始して連続的に割り当てる必要があります。タイプコード0〜127は、IETFレビューまたはIESG承認によって割り当てられます。
Type Codes 128-255 are available according to the [RFC5226] First Come First Served policy.
タイプコード128〜255は、[RFC5226]先着順ポリシーに従って利用できます。
This registry, initially empty, is constructed for future use in experimental work related to LISP Canonical Address Format (LCAF) values. See [LCAF] for details of other possible unapproved address encodings. The unapproved LCAF encodings are an area for further study and experimentation.
このレジストリは最初は空でしたが、LISP Canonical Address Format（LCAF）値に関連する実験的な作業で将来使用するために構築されています。他の可能性のある未承認のアドレスエンコーディングの詳細については、[LCAF]を参照してください。未承認のLCAFエンコーディングは、さらなる研究と実験の領域です。
The IANA registry has allocated UDP port numbers 4341 and 4342 for lisp-data and lisp-control operation, respectively. IANA has updated the description for UDP ports 4341 and 4342 as follows:
IANAレジストリは、lisp-dataおよびlisp-control操作用にそれぞれUDPポート番号4341および4342を割り当てています。 IANAは、UDPポート4341および4342の説明を次のように更新しました。
lisp-data 4341 udp LISP Data Packets lisp-control 4342 udp LISP Control Packets
lisp-data 4341 udp LISPデータパケットlisp-control 4342 udp LISP制御パケット
The following Key ID values are defined by this specification as used in any packet type that references a 'Key ID' field:
次のキーID値は、「キーID」フィールドを参照するすべてのパケットタイプで使用されるように、この仕様で定義されています。
Name Number Defined in
-----------------------------------------------
None 0 n/a
HMAC-SHA-1-96 1 [RFC2404]
HMAC-SHA-256-128 2 [RFC4868]
Number values are in the range of 0 to 65535. The allocation of values is on a first come first served basis.
数値の範囲は0〜65535です。値の割り当ては先着順です。
As an experimental specification, this work is, by definition, incomplete. Specific areas where additional experience and work are needed include the following:
実験的な仕様として、この作品は定義上、不完全です。追加の経験と作業が必要な特定の領域には、次のものがあります。
o At present, only [RFC6836] is defined for implementing a database of EID-to-RLOC mapping information. Additional research on other mapping database systems is strongly encouraged.
o 現在、EIDからRLOCへのマッピング情報のデータベースを実装するために定義されているのは[RFC6836]だけです。他のマッピングデータベースシステムに関する追加の調査が強く推奨されます。
o Failure and recovery of LISP site partitioning (see Section 6.4) in the presence of redundant configuration (see Section 8.5) needs further research and experimentation.
o 冗長構成（セクション8.5を参照）がある場合のLISPサイト分割（セクション6.4を参照）の障害と回復には、さらに調査と実験が必要です。
o The characteristics of map-cache management under exceptional conditions, such as denial-of-service attacks, are not fully understood. Further experience is needed to determine whether current caching methods are practical or in need of further development. In particular, the performance, scaling, and security characteristics of the map-cache will be discovered as part of this experiment. Performance metrics to be observed are packet reordering associated with the LISP Data-Probe and loss of the first packet in a flow associated with map-caching. The impact of these upon TCP will be observed. See Section 12 for additional thoughts and considerations.
o サービス拒否攻撃などの例外的な状況下でのマップキャッシュ管理の特性は、完全には理解されていません。現在のキャッシング方法が実用的か、それともさらなる開発が必要かを判断するには、さらなる経験が必要です。特に、マップキャッシュのパフォーマンス、スケーリング、およびセキュリティ特性は、この実験の一部として発見されます。監視するパフォーマンスメトリックは、LISPデータプローブに関連するパケットの並べ替えと、マップキャッシュに関連するフローの最初のパケットの損失です。 TCPに対するこれらの影響が観察されます。追加の考慮事項と考慮事項については、セクション12を参照してください。
o Preliminary work has been done to ensure that sites employing LISP can interconnect with the rest of the Internet. This work is documented in [RFC6832], but further experimentation and experience are needed.
o LISPを使用するサイトが他のインターネットと相互接続できるようにするための予備作業が行われました。この作品は[RFC6832]に文書化されていますが、さらなる実験と経験が必要です。
o At present, no mechanism for automated key management for message authentication is defined. Addressing automated key management is necessary before this specification can be developed into a Standards Track RFC. See Section 12 for further details regarding security considerations.
o 現在、メッセージ認証の自動鍵管理のメカニズムは定義されていません。この仕様をStandards Track RFCに発展させるには、自動化されたキー管理に対処する必要があります。セキュリティに関する考慮事項の詳細については、セクション12を参照してください。
o In order to maintain security and stability, Internet protocols typically isolate the control and data planes. Therefore, user activity cannot cause control-plane state to be created or destroyed. LISP does not maintain this separation. The degree to which the loss of separation impacts security and stability is a topic for experimental observation.
o セキュリティと安定性を維持するために、インターネットプロトコルは通常、コントロールプレーンとデータプレーンを分離します。したがって、ユーザーアクティビティによってコントロールプレーンの状態が作成または破棄されることはありません。 LISPはこの分離を維持しません。分離の喪失がセキュリティと安定性に影響を与える度合いは、実験的観察のトピックです。
o LISP allows for the use of different mapping database systems. While only one [RFC6836] is currently well defined, each mapping database will likely have some impact on the security of the EID-to-RLOC mappings. How each mapping database system's security properties impact LISP overall is for further study.
o LISPでは、さまざまなマッピングデータベースシステムを使用できます。現在1つだけ[RFC6836]が適切に定義されていますが、各マッピングデータベースは、EIDからRLOCへのマッピングのセキュリティにある程度の影響を与える可能性があります。各マッピングデータベースシステムのセキュリティプロパティがLISP全体にどのように影響するかは、今後の検討課題です。
o An examination of the implications of LISP on Internet traffic, applications, routers, and security is needed. This will help implementors understand the consequences for network stability, routing protocol function, routing scalability, migration and backward compatibility, and implementation scalability (as influenced by additional protocol components; additional state; and additional processing for encapsulation, decapsulation, and liveness).
o LISPがインターネットトラフィック、アプリケーション、ルーター、およびセキュリティに与える影響の調査が必要です。これは、実装者がネットワークの安定性、ルーティングプロトコル機能、ルーティングのスケーラビリティ、移行と下位互換性、および実装のスケーラビリティ（追加のプロトコルコンポーネント、追加の状態、およびカプセル化、カプセル化解除、ライブネスの追加処理の影響を受ける）の影響を理解するのに役立ちます。
o Experiments need to verify that LISP produces no significant change in the behavior of protocols run between end-systems over a LISP infrastructure versus being run directly between those same end-systems.
o 実験では、LISPがLISPインフラストラクチャを介してエンドシステム間で実行されるプロトコルの動作に大きな変化をもたらさないことを確認する必要があります。
o Experiments need to verify that the issues raised in the Critique section of [RFC6115] are either insignificant or have been addressed by updates to LISP.
o 実験では、[RFC6115]の批評セクションで提起された問題が取るに足らないものであるか、LISPのアップデートによって対処されていることを確認する必要があります。
Other LISP documents may also include open issues and areas for future work.
その他のLISPドキュメントには、未解決の問題や将来の作業のための領域が含まれる場合もあります。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[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月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404] Madson、C。およびR. Glenn、「The Use of HMAC-SHA-1-96 within ESP and AH」、RFC 2404、1998年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232] Reynolds、J。、「割り当てられた番号：RFC 1700はオンラインデータベースに置き換えられました」、RFC 3232、2002年1月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[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月。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC4868]ケリーS.およびS.フランケル、「IPsecでのHMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512の使用」、RFC 4868、2007年5月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[RFC5496] Wijnands、IJ。、Boers、A。、およびE. Rosen、「The Reverse Path Forwarding（RPF）Vector TLV」、RFC 5496、2009年3月。
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944]パーキンス、C。、「IPv4のIPモビリティサポート、改訂」、RFC 5944、2010年11月。
[RFC6115] Li, T., "Recommendation for a Routing Architecture", RFC 6115, February 2011.
[RFC6115] Li、T。、「Recommendation for a Routing Architecture」、RFC 6115、2011年2月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275] Perkins、C.、Johnson、D。、およびJ. Arkko、「IPv6でのモビリティサポート」、RFC 6275、2011年7月。
[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月。
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, January 2013.
[RFC6834] Iannone、L.、Saucez、D。、およびO. Bonaventure、「Locator / ID Separation Protocol（LISP）Map-Versioning」、RFC 6834、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月。
[AFI] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[AFI] IANA、 "Address Family Numbers"、<http://www.iana.org/assignments/address-family-numbers>。
[BGP-SEC] Lepinski, M. and S. Turner, "An Overview of BGPSEC", Work in Progress, May 2012.
[BGP-SEC] Lepinski、M。およびS. Turner、「An Overview of BGPSEC」、Work in Progress、2012年5月。
[CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed Enhancement to the Internet Architecture", 1999, <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
[CHIAPPA] Chiappa、J。、「エンドポイントとエンドポイントの名前：インターネットアーキテクチャへの拡張案」、1999、<http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>。
[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.
[短所]ブリム、S。、チアッパ、N。、ファリナッチ、D。、フラー、V。、ルイス、D。、およびD.マイヤー、「LISP-CONS：A LISPのコンテンツ配信オーバーレイネットワークサービス」、Work in進捗状況、2008年4月。
[EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Mappings Multicast Across Cooperating Systems for LISP", Work in Progress, November 2007.
[EMACS]ブリム、S。、ファリナッチ、D。、マイヤー、D。、およびJ.カラン、「LISPの協調システム間でのEIDマッピングマルチキャスト」、2007年11月、作業中。
[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", Work in Progress, January 2013.
[LCAF] Farinacci、D.、Meyer、D。、およびJ. Snijders、「LISP Canonical Address Format（LCAF）」、Work in Progress、2013年1月。
[LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin, "Renumbering: Threat or Menace?", Usenix Tenth System Administration Conference (LISA 96), October 1996.
[LISA96]リア、E。、タープ、D。、カティンスキー、J.、J。コフィン、「番号を付け直す：脅威か脅威か？」、Usenix第10回システム管理会議（LISA 96）、1996年10月。
[LISP-DEPLOY] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-Pascual, J., and D. Lewis, "LISP Network Element Deployment Considerations", Work in Progress, October 2012.
[LISP-DEPLOY] Jakab、L.、Cabellos-Aparicio、A.、Coras、F.、Domingo-Pascual、J。、およびD. Lewis、「LISPネットワーク要素の展開に関する考慮事項」、Work in Progress、2012年10月。
[LISP-MIB] Schudel, G., Jain, A., and V. Moreno, "LISP MIB", Work in Progress, January 2013.
[LISP-MIB]シューデル、G。、ジャイナ、A。、およびV.モレノ、「LISP MIB」、作業中、2013年1月。
[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月。
[LOC-ID-ARCH] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", Work in Progress, January 2009.
[LOC-ID-ARCH]マイヤーD.およびD.ルイス、「ロケータ/ ID分離のアーキテクチャ上の意味」、2009年1月、作業中。
[OPENLISP] Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Implementation Report", Work in Progress, July 2008.
[OPENLISP] Iannone、L.、Saucez、D。、およびO. Bonaventure、「OpenLISP実装レポート」、進行中の作業、2008年7月。
[RADIR] Narten, T., "On the Scalability of Internet Routing", Work in Progress, February 2010.
[RADIR] Narten、T.、「インターネットルーティングのスケーラビリティについて」、Work in Progress、2010年2月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 2784、2000年3月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B。およびK.ムーア、「IPv4クラウドを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[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月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]ベイカー、F。、リア、E。、およびR.ドロムス、「フラグデーのないIPv6ネットワークの番号を付け直すための手順」、RFC 4192、2005年9月。
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4866] Arkko、J.、Vogt、C。、およびW. Haddad、「Enhanced Route Optimization for Mobile IPv6」、RFC 4866、2007年5月。
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
[RFC4984] Meyer、D.、Zhang、L。、およびK. Fall、「ルーティングとアドレッシングに関するIABワークショップからのレポート」、RFC 4984、2007年9月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、2012年2月。
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012.
[RFC6518] Lebovitz、G。およびM. Bhatia、「Keying and Authentication for Routing Protocols（KARP）Design Guidelines」、RFC 6518、2012年2月。
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, January 2013.
[RFC6831] Farinacci、D.、Meyer、D.、Zwiebel、J。、およびS. Venaas、「The Locator / ID Separation Protocol（LISP）for Multicast Environments」、RFC 6831、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月。
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, January 2013.
[RFC6835] Farinacci、D。およびD. Meyer、「Locator / ID Separation Protocol Internet Groper（LIG）」、RFC 6835、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月。
[UDP-TUNNELS] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", Work in Progress, January 2013.
[UDP-TUNNELS] Eubanks、M.、Chimento、P。、およびM. Westerlund、「トンネルパケットのIPv6およびUDPチェックサム」、作業中、2013年1月。
[UDP-ZERO] Fairhurst, G. and M. Westerlund, "Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums", Work in Progress, December 2012.
[UDP-ZERO] Fairhurst、G.およびM. Westerlund、「ゼロチェックサムを使用したIPv6 UDPデータグラムの使用に関する適用性声明」、作業中、2012年12月。
An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors.
LISPの最初のアイデアの種を植えてくれたDave Oranに最初に感謝します。彼の協議は、LISP作者に価値を提供し続けています。
A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed reviews of the LISP architecture and documents, coupled with enthusiasm for making LISP a practical and incremental transition for the Internet.
Noel Chiappaに特別な感謝の意を表します。ロケーションとIDの分離に関する過去10年間のアーキテクチャの推進力、およびLISPアーキテクチャとドキュメントの詳細なレビューを提供し、LISPを実用的かつ段階的に移行する熱意と併せてインターネット。
The authors would like to gratefully acknowledge many people who have contributed discussions and ideas to the making of this proposal. They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, and Alia Atlas.
著者は、この提案の作成に議論やアイデアを提供してくれた多くの人々に感謝したいと思います。スコットブリム、アンドリューパータン、ジョンズウィーベル、ジェイソンシラー、リクシアチャン、ドリアンキム、ピーターシェーンメーカー、ビジェイギル、ジェフヒューストン、デビッドコンラッド、マークハンドラリー、ロンボニカ、テッドシーリー、マークタウンズリー、クリスモロー、ブライアンウェイス、デイブ・マクルー、ピーター・ロスバーグ、デイブ・ターラー、エリオット・リア、シェーン・アマンテ、ヴェッド・カフレ、オリヴィエ・ボナベンチャー、ルイジ・イアンノーネ、ロビン・ウィットル、ブライアン・カーペンター、ジョエル・ハルパーン、テリー・マンダーソン、ロジャー・ジョルゲンセン、ラン・アトキンソン、スティグ・ヴェナース、イルジッチ・ヴァン・ベインブレス、ダナブレア、ビルリンチ、マークウールワード、ダミアンソース、ダミアンレザマ、アティラデグルート、パランタップラヒリ、デビッドブラック、ロケガリアーノ、イシドールコウベラス、ジェスパーシュクライバー、フレッドテンプリン、マーガレットワッサーマン、サムハートマン、マイケルホフリング、ペドロマーク、Jari Arkko、Gregg Schudel、Srinivas Subramanian、Amit Jain、Xu Xiaohu、Dhirendra Trivedi、Yakov Rekhter、John Scudder、John Drake、Dimitri Papadimitriou、Ross Callon、Selina Heimlich、Job Snijders、Vina Ermagan、Albert Cabos、Fabioモレノ、クリスWh ite、Clarence Filsfils、およびAlia Atlas。
This work originated in the Routing Research Group (RRG) of the IRTF. An individual submission was converted into the IETF LISP working group document that became this RFC.
この作業は、IRTFのルーティングリサーチグループ（RRG）から始まりました。個々の提出物は、このRFCになるIETF LISPワーキンググループドキュメントに変換されました。
The LISP working group would like to give a special thanks to Jari Arkko, the Internet Area AD at the time that the set of LISP documents were being prepared for IESG last call, and for his meticulous reviews and detailed commentaries on the 7 working group last call documents progressing toward experimental RFCs.
LISPワーキンググループは、一連のLISPドキュメントがIESGの最後の呼び出しのために準備されていた当時のインターネットエリアADであるJari Arkkoと、7つのワーキンググループに関する彼の細かいレビューと詳細なコメントに特に感謝します試験的なRFCに向けて進行中のドキュメントを呼び出します。
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
Vince Fuller
ヴィンスフラー
EMail: vaf@vaf.net
Dave Meyer Cisco Systems 170 Tasman Drive San Jose, CA USA
Dave Meyer Cisco Systems 170 Tasman Drive米国カリフォルニア州サンノゼ
EMail: dmm@1-4-5.net
Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA USA
Darrel Lewis Cisco Systems 170 Tasman Drive米国カリフォルニア州サンノゼ
EMail: darlewis@cisco.com