[要約] RFC 6834は、LISP（Locator/ID Separation Protocol）のマップバージョニングに関する規格です。目的は、LISPネットワーク内のマッピングデータのバージョン管理を可能にし、ネットワークの拡張性と柔軟性を向上させることです。
Internet Engineering Task Force (IETF) L. Iannone
Request for Comments: 6834 Telecom ParisTech
Category: Experimental D. Saucez
ISSN: 2070-1721 INRIA Sophia Antipolis
O. Bonaventure
Universite catholique de Louvain
January 2013
Locator/ID Separation Protocol (LISP) Map-Versioning
ロケーター/ ID分離プロトコル（LISP）マップのバージョン管理
Abstract
概要
This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism.
このドキュメントでは、LISP（ロケータ/ ID分離プロトコル）マップバージョン管理メカニズムについて説明します。これは、LISPデータパケットのカプセル化に使用されるエンドポイントIDからルーティングロケータ（EIDからRLOC）へのマッピングに関するパケット内情報を提供します。提案されたアプローチは、バージョン番号をEIDからRLOCへのマッピングに関連付け、LISPカプセル化パケットのLISP固有のヘッダーでそのようなバージョン番号を転送することに基づいています。 LISP Map-Versioningは、パケットのカプセル化に使用されるマッピングの変更について、通信する入口トンネルルーター（ITR）および出口トンネルルーター（ETR）に通知するのに特に役立ちます。 LISP固有のヘッダーとマップレコードでは、メカニズムをサポートしないITRとETRがマップバージョン管理に使用されるビットを安全に無視できるため、このメカニズムはこの機能をサポートしない実装に対して透過的です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6834.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6834で入手できます。
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 ...........................................4
3. Definitions of Terms ............................................4
4. EID-to-RLOC Map-Version Number ..................................4
4.1. The Null Map-Version .......................................5
5. Dealing with Map-Version Numbers ................................6
5.1. Handling Destination Map-Version Number ....................7
5.2. Handling Source Map-Version Number .........................9
6. LISP Header and Map-Version Numbers ............................10
7. Map Record and Map-Version .....................................11
8. Benefits and Case Studies for Map-Versioning ...................12
8.1. Map-Versioning and Unidirectional Traffic .................12
8.2. Map-Versioning and Interworking ...........................12
8.2.1. Map-Versioning and Proxy-ITRs ......................13
8.2.2. Map-Versioning and LISP-NAT ........................13
8.2.3. Map-Versioning and Proxy-ETRs ......................14
8.3. RLOC Shutdown/Withdraw ....................................14
8.4. Map-Version for Lightweight LISP Implementation ...........15
9. Incremental Deployment and Implementation Status ...............15
10. Security Considerations .......................................16
10.1. Map-Versioning against Traffic Disruption ................16
10.2. Map-Versioning against Reachability Information DoS ......17
11. Open Issues and Considerations ................................17
11.1. Lack of Synchronization among ETRs .......................17
12. Acknowledgments ...............................................19
13. References ....................................................19
13.1. Normative References .....................................19
13.2. Informative References ...................................19
Appendix A. Estimation of Time before Map-Version Wrap-Around .....21
This document describes the Map-Versioning mechanism used to provide information on changes in the EID-to-RLOC (Endpoint ID to Routing Locator) mappings used in the LISP (Locator/ID Separation Protocol [RFC6830]) context to perform packet encapsulation. The mechanism is totally transparent to xTRs (Ingress and Egress Tunnel Routers) not supporting such functionality. It is not meant to replace any existing LISP mechanisms but rather to extend them by providing new functionalities. If for any unforeseen reason a normative conflict between this document and the LISP main specifications is found, the latter ([RFC6830]) has precedence over this document.
このドキュメントでは、パケットのカプセル化を実行するためにLISP（Locator / ID Separation Protocol [RFC6830]）コンテキストで使用されるEID-to-RLOC（Endpoint ID to Routing Locator）マッピングの変更に関する情報を提供するために使用されるマップバージョン管理メカニズムについて説明します。このメカニズムは、そのような機能をサポートしていないxTR（入力および出力トンネルルーター）に対して完全に透過的です。これは、既存のLISPメカニズムを置き換えるものではなく、新しい機能を提供してそれらを拡張するものです。予期しない理由でこのドキュメントとLISPの主な仕様の間に規範的な矛盾が見つかった場合、後者（[RFC6830]）がこのドキュメントよりも優先されます。
The basic mechanism is to associate a Map-Version number to each LISP EID-to-RLOC mapping and transport such a version number in the LISP-specific header. When a mapping changes, a new version number is assigned to the updated mapping. A change in an EID-to-RLOC mapping can be a change in the RLOCs set, by adding or removing one or more RLOCs, but it can also be a change in the priority or weight of one or more RLOCs.
基本的なメカニズムは、Map-Version番号を各LISP EID-to-RLOCマッピングに関連付け、そのようなバージョン番号をLISP固有のヘッダーで転送することです。マッピングが変更されると、更新されたマッピングに新しいバージョン番号が割り当てられます。 EIDからRLOCへのマッピングの変更は、1つ以上のRLOCを追加または削除することにより、RLOCセットの変更になる場合がありますが、1つ以上のRLOCの優先度または重みの変更になる場合もあります。
When Map-Versioning is used, LISP-encapsulated data packets contain the version number of the two mappings used to select the RLOCs in the outer header (i.e., both source and destination). These version numbers are encoded in the 24 low-order bits of the first longword of the LISP header and indicated by a specific bit in the flags (first 8 high-order bits of the first longword of the LISP header). Note that not all packets need to carry version numbers.
Map-Versioningを使用する場合、LISPカプセル化データパケットには、外部ヘッダー（つまり、送信元と宛先の両方）でRLOCを選択するために使用される2つのマッピングのバージョン番号が含まれます。これらのバージョン番号は、LISPヘッダーの最初のロングワードの下位24ビットでエンコードされ、フラグの特定のビット（LISPヘッダーの最初のロングワードの上位8ビット）で示されます。すべてのパケットがバージョン番号を運ぶ必要があるわけではないことに注意してください。
When an ITR (Ingress Tunnel Router) encapsulates a data packet, with a LISP header containing the Map-Version numbers, it puts in the LISP-specific header two version numbers:
ITR（Ingress Tunnel Router）がMap-Version番号を含むLISPヘッダーを使用してデータパケットをカプセル化すると、LISP固有のヘッダーに2つのバージョン番号が配置されます。
1. The version number assigned to the mapping (contained in the EID-to-RLOC Database) used to select the source RLOC.
1. ソースRLOCを選択するために使用される（EID-to-RLOCデータベースに含まれる）マッピングに割り当てられたバージョン番号。
2. The version number assigned to the mapping (contained in the EID-to-RLOC Cache) used to select the destination RLOC.
2. 宛先RLOCを選択するために使用される（EID-to-RLOCキャッシュに含まれる）マッピングに割り当てられたバージョン番号。
This operation is two-fold. On the one hand, it enables the ETR (Egress Tunnel Router) receiving the packet to know if the ITR has the latest version number that any ETR at the destination EID site has provided to the ITR in a Map-Reply. If this is not the case, the ETR can send to the ITR a Map-Request containing the updated mapping or solicit a Map-Request from the ITR (both cases are already defined in [RFC6830]). In this way, the ITR can update its EID-to-RLOC Cache. On the other hand, it enables an ETR receiving such a packet to know if it has in its EID-to-RLOC Cache the latest mapping for the source EID (in the case of bidirectional traffic). If this is not the case, a Map-Request can be sent.
この操作は2つあります。一方では、パケットを受信するETR（出力トンネルルーター）が、宛先EIDサイトのETRがMap-ReplyでITRに提供した最新のバージョン番号がITRにあるかどうかを知ることができます。そうでない場合、ETRは更新されたマッピングを含むMap-RequestをITRに送信するか、ITRからMap-Requestを要求できます（どちらの場合も[RFC6830]ですでに定義されています）。このようにして、ITRはEIDからRLOCへのキャッシュを更新できます。一方、このようなパケットを受信するETRは、EID-to-RLOCキャッシュにソースEIDの最新のマッピングがあるかどうかを確認できます（双方向トラフィックの場合）。そうでない場合は、Map-Requestを送信できます。
Issues and concerns about the deployment of LISP for Internet traffic are discussed in [RFC6830]. Section 11 provides additional issues and concerns raised by this document. In particular, Section 11.1 provides details about the ETRs' synchronization issue in the context of Map-Versioning.
インターネットトラフィック用のLISPの展開に関する問題と懸念事項は、[RFC6830]で説明されています。セクション11は、このドキュメントによって提起された追加の問題と懸念事項を提供します。特に、セクション11.1は、Map-VersioningのコンテキストにおけるETRの同期の問題に関する詳細を提供します。
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]で説明されているように解釈されます。
This document uses terms already defined in the main LISP specification [RFC6830]. Here, we define the terms that are specific to the Map-Versioning mechanism. Throughout the whole document, Big Endian bit ordering is used.
このドキュメントでは、メインのLISP仕様[RFC6830]ですでに定義されている用語を使用しています。ここでは、Map-Versioningメカニズムに固有の用語を定義します。ドキュメント全体を通して、ビッグエンディアンのビット順序が使用されています。
Map-Version number: An unsigned 12-bit integer is assigned to an EID-to-RLOC mapping, not including the value 0 (0x000).
Map-Version番号：値0（0x000）を含まない、符号なし12ビット整数がEIDからRLOCへのマッピングに割り当てられます。
Null Map-Version: The 12-bit null value of 0 (0x000) is not used as a Map-Version number. It is used to signal that no Map-Version number is assigned to the EID-to-RLOC mapping.
Null Map-Version：12ビットnull値0（0x000）はMap-Version番号として使用されません。 EIDからRLOCへのマッピングにMap-Version番号が割り当てられていないことを通知するために使用されます。
Source Map-Version number: This Map-Version number of the EID-to-RLOC mapping is used to select the source address (RLOC) of the outer IP header of LISP-encapsulated packets.
ソースMap-Version番号：このEID-to-RLOCマッピングのMap-Version番号は、LISPカプセル化パケットの外部IPヘッダーの送信元アドレス（RLOC）を選択するために使用されます。
Destination Map-Version number: This Map-Version number of the EID-to-RLOC mapping is used to select the destination address (RLOC) of the outer IP header of LISP-encapsulated packets.
宛先マップバージョン番号：EIDからRLOCへのマッピングのこのマップバージョン番号は、LISPカプセル化パケットの外部IPヘッダーの宛先アドレス（RLOC）を選択するために使用されます。
The EID-to-RLOC Map-Version number consists of an unsigned 12-bit integer. The version number is assigned on a per-mapping basis, meaning that different mappings have a different version number, which is also updated independently. An update in the version number (i.e., a newer version) consists of incrementing by one the older version number. Appendix A contains a rough estimation of the wrap-around time for the Map-Version number.
EID-to-RLOC Map-Version番号は、符号なし12ビット整数で構成されています。バージョン番号はマッピングごとに割り当てられます。つまり、マッピングごとに異なるバージョン番号があり、これも個別に更新されます。バージョン番号の更新（つまり、新しいバージョン）は、古いバージョン番号を1つインクリメントすることで構成されます。付録Aには、Map-Version番号のラップアラウンド時間の概算が含まれています。
The space of version numbers has a circular order where half of the version numbers are greater (i.e., newer) than the current Map-Version number and the other half of the version numbers are smaller (i.e., older) than the current Map-Version number. In a more formal way, assuming that we have two version numbers V1 and V2 and that the numbers are expressed in N bits, the following steps MUST be performed (in the same order as shown below) to strictly define their order:
バージョン番号のスペースには循環バージョンがあり、バージョン番号の半分は現在のMap-Version番号より大きく（つまり、新しい）、バージョン番号の残りの半分は現在のMap-Versionより小さい（つまり、古い）。数。より正式な方法では、2つのバージョン番号V1とV2があり、番号がNビットで表されていると仮定して、次の手順を（以下に示すのと同じ順序で）実行して、それらの順序を厳密に定義する必要があります。
1. V1 = V2 : The Map-Version numbers are the same.
1. V1 = V2：Map-Version番号は同じです。
2. V2 > V1 : if and only if
2. V2> V1：次の場合のみ
V2 > V1 AND (V2 - V1) <= 2**(N-1)
OR
または
V1 > V2 AND (V1 - V2) > 2**(N-1)
3. V1 > V2 : otherwise.
3. V1> V2：それ以外の場合。
Using 12 bits, as defined in this document, and assuming a Map-Version value of 69, Map-Version numbers in the range [70; 69 + 2048] are greater than 69, while Map-Version numbers in the range [69 + 2049; (69 + 4096) mod 4096] are smaller than 69.
このドキュメントで定義されているように12ビットを使用し、Map-Version値を69とすると、範囲[70; 69 + 2048]は69より大きく、Map-Version番号は[69 + 2049; （69 + 4096）mod 4096]は69よりも小さいです。
Map-Version numbers are assigned to mappings by configuration. The initial Map-Version number of a new EID-to-RLOC mapping SHOULD be assigned randomly, but it MUST NOT be set to the Null Map-Version value (0x000), because the Null Map-Version number has a special meaning (see Section 4.1).
Map-Version番号は、構成によってマッピングに割り当てられます。新しいEIDからRLOCへのマッピングの初期Map-Version番号はランダムに割り当てる必要があります（SHOULD）。ただし、Null Map-Version番号には特別な意味があるため、Null Map-Version値（0x000）に設定しないでください（セクション4.1）。
Upon reboot, an ETR will use mappings configured in its EID-to-RLOC Database. If those mappings have a Map-Version number, it will be used according to the mechanisms described in this document. ETRs MUST NOT automatically generate and assign Map-Version numbers to mappings in the EID-to-RLOC Database.
再起動すると、ETRはEIDからRLOCへのデータベースで構成されたマッピングを使用します。それらのマッピングにMap-Version番号がある場合、このドキュメントで説明されているメカニズムに従って使用されます。 ETRは、EIDからRLOCデータベースへのマッピングにMap-Version番号を自動的に生成して割り当ててはなりません（MUST NOT）。
The value 0x000 (zero) is not a valid Map-Version number indicating the version of the EID-to-RLOC mapping. Such a value is used for special purposes and is named the Null Map-Version number.
値0x000（ゼロ）は、EIDからRLOCへのマッピングのバージョンを示す有効なMap-Version番号ではありません。このような値は特別な目的で使用され、Null Map-Version番号と呼ばれます。
The Null Map-Version MAY appear in the LISP-specific header as either a Source Map-Version number (cf. Section 5.2) or a Destination Map-Version number (cf. Section 5.1). When the Source Map-Version number is set to the Null Map-Version value, it means that no map version information is conveyed for the source site. This means that if a mapping exists for the source EID in the EID-to-RLOC Cache, then the ETR MUST NOT compare the received Null Map-Version with the content of the EID-to-RLOC Cache. When the Destination Map-Version number is set to the Null Map-Version value, it means that no map version information is conveyed for the destination site. This means that the ETR MUST NOT compare the value with the Map-Version number of the mapping for the destination EID present in the EID-to-RLOC Database.
Null Map-Versionは、LISP固有のヘッダーに、Source Map-Version番号（セクション5.2を参照）またはDestination Map-Version番号（セクション5.1を参照）として表示される場合があります。ソースMap-Version番号がNull Map-Version値に設定されている場合、ソースサイトのマップバージョン情報が伝達されないことを意味します。これは、EIDからRLOCキャッシュ内のソースEIDのマッピングが存在する場合、ETRは受信したNull Map-VersionをEIDからRLOCキャッシュの内容と比較してはならないことを意味します。 Destination Map-Version番号がNull Map-Version値に設定されている場合、これは、宛先バージョンのマップバージョン情報が伝達されないことを意味します。これは、ETRが値をEID-to-RLOCデータベースに存在する宛先EIDのマッピングのMap-Version番号と比較してはならないことを意味します。
The other use of the Null Map-Version number is in the Map Records, which are part of the Map-Request, Map-Reply, and Map-Register messages (defined in [RFC6830]). Map Records that have a Null Map-Version number indicate that there is no Map-Version number associated with the mapping. This means that LISP-encapsulated packets destined to the EID-Prefix referred to by the Map Record MUST either not contain any Map-Version numbers (V-bit set to 0) or, if they contain Map-Version numbers (V-bit set to 1), then the destination Map-Version number MUST be set to the Null Map-Version number. Any value different from zero means that Map-Versioning is supported and MAY be used.
Null Map-Version番号の他の使用法は、Map-Request、Map-Reply、およびMap-Registerメッセージ（[RFC6830]で定義）の一部であるマップレコードにあります。 Null Map-Version番号を持つMapレコードは、マッピングに関連付けられたMap-Version番号がないことを示します。つまり、マップレコードによって参照されるEIDプレフィックス宛てのLISPカプセル化パケットには、マップバージョン番号（Vビットが0に設定）が含まれていないか、またはマップバージョン番号が含まれている場合（Vビットセット） 1）の場合、宛先のMap-Version番号はNull Map-Version番号に設定する必要があります。ゼロ以外の値は、Map-Versioningがサポートされており、使用できることを意味します。
The fact that the 0 value has a special meaning for the Map-Version number implies that, when updating a Map-Version number because of a change in the mapping, if the next value is 0, then the Map-Version number MUST be incremented by 2 (i.e., set to 1, which is the next valid value).
Map-Version番号に対して0の値が特別な意味を持つという事実は、マッピングの変更のためにMap-Version番号を更新するときに、次の値が0の場合、Map-Version番号をインクリメントする必要があることを意味します2（つまり、次の有効な値である1に設定）。
The main idea of using Map-Version numbers is that whenever there is a change in the mapping (e.g., adding/removing RLOCs, a change in the weights due to Traffic Engineering policies, or a change in the priorities) or a LISP site realizes that one or more of its own RLOCs are not reachable anymore from a local perspective (e.g., through IGP, or policy changes) the LISP site updates the mapping, also assigning a new Map-Version number.
Map-Version番号を使用する主なアイデアは、マッピングに変更がある場合（RLOCの追加/削除、トラフィックエンジニアリングポリシーによる重みの変更、または優先度の変更など）またはLISPサイトが実現することです。独自のRLOCの1つまたは複数がローカルの観点から（IGPやポリシーの変更などによって）到達できなくなった場合、LISPサイトはマッピングを更新し、新しいMap-Version番号も割り当てます。
To each mapping, a version number is associated and changes each time the mapping is changed. Note that Map-Versioning does not introduce new problems concerning the coordination of different ETRs of a domain. Indeed, ETRs belonging to the same LISP site must return for a specific EID-Prefix the same mapping, including the same Map-Version number. In principle, this is orthogonal to whether or not Map-Versioning is used. The synchronization problem and its implication on the traffic are out of the scope of this document (see Section 11).
各マッピングにはバージョン番号が関連付けられており、マッピングが変更されるたびに変更されます。 Map-Versioningでは、ドメインのさまざまなETRの調整に関する新しい問題が発生しないことに注意してください。実際、同じLISPサイトに属するETRは、特定のEIDプレフィックスに対して、同じMap-Version番号を含む同じマッピングを返す必要があります。原則として、これはMap-Versioningが使用されているかどうかとは関係ありません。同期の問題とそのトラフィックへの影響は、このドキュメントの範囲外です（セクション11を参照）。
In order to announce in a data-driven fashion that the mapping has been updated, Map-Version numbers used to create the outer IP header of the LISP-encapsulated packet are embedded in the LISP-specific header. This means that the header needs to contain two Map-Version numbers:
マッピングが更新されたことをデータ主導で通知するために、LISPカプセル化パケットの外部IPヘッダーの作成に使用されるMap-Version番号がLISP固有のヘッダーに埋め込まれています。つまり、ヘッダーには2つのMap-Version番号を含める必要があります。
o The Source Map-Version number of the EID-to-RLOC mapping in the EID-to-RLOC Database used to select the source RLOC.
o ソースRLOCを選択するために使用されるEID-to-RLOCデータベース内のEID-to-RLOCマッピングのSource Map-Version番号。
o The Destination Map-Version number of the EID-to-RLOC mapping in the EID-to-RLOC Cache used to select the destination RLOC.
o 宛先RLOCの選択に使用されるEID-to-RLOCキャッシュ内のEID-to-RLOCマッピングの宛先マップバージョン番号。
By embedding both the Source Map-Version number and the Destination Map-Version number, an ETR receiving a LISP packet with Map-Version numbers can perform the following checks:
Source Map-Version番号とDestination Map-Version番号の両方を埋め込むことにより、Map-Version番号を含むLISPパケットを受信するETRは、次のチェックを実行できます。
1. The ITR that has sent the packet has an up-to-date mapping in its EID-to-RLOC Cache for the destination EID and is performing encapsulation correctly.
1. パケットを送信したITRは、宛先EIDのEID-to-RLOCキャッシュに最新のマッピングがあり、カプセル化を正しく実行しています。
2. In the case of bidirectional traffic, the mapping in the local ETR EID-to-RLOC Cache for the source EID is up to date.
2. 双方向トラフィックの場合、ソースEIDのローカルETR EIDからRLOCキャッシュへのマッピングは最新です。
If one or both of the above conditions do not hold, the ETR can send a Map-Request either to make the ITR aware that a new mapping is available (see Section 5.1) or to update the mapping in the local EID-to-RLOC Cache (see Section 5.2).
上記の条件のいずれかまたは両方が満たされない場合、ETRはMap-Requestを送信して、新しいマッピングが利用可能であることをITRに認識させるか（セクション5.1を参照）、ローカルのEIDからRLOCへのマッピングを更新します。キャッシュ（セクション5.2を参照）。
When an ETR receives a packet, the Destination Map-Version number relates to the mapping for the destination EID for which the ETR is an RLOC. This mapping is part of the ETR EID-to-RLOC Database. Since the ETR is authoritative for the mapping, it has the correct and up-to-date Destination Map-Version number. A check on this version number can be done, where the following cases can arise:
ETRがパケットを受信すると、Destination Map-Version番号は、ETRがRLOCである宛先EIDのマッピングに関連します。このマッピングは、ETR EID-to-RLOCデータベースの一部です。 ETRはマッピングに対して信頼できるので、正しい最新の宛先マップバージョン番号を持っています。このバージョン番号のチェックを行うことができます。この場合、以下のケースが発生する可能性があります。
1. The packet arrives with the same Destination Map-Version number stored in the EID-to-RLOC Database. This is the regular case. The ITR sending the packet has in its EID-to-RLOC Cache an up-to-date mapping. No further actions are needed.
1. パケットは、EID-to-RLOCデータベースに格納されている同じ宛先マップバージョン番号で到着します。これは通常のケースです。パケットを送信するITRは、EIDからRLOCへのキャッシュに最新のマッピングを持っています。これ以上のアクションは必要ありません。
2. The packet arrives with a Destination Map-Version number greater (i.e., newer) than the one stored in the EID-to-RLOC Database. Since the ETR is authoritative on the mapping, meaning that the Map-Version number of its mapping is the correct one, this implies that someone is not behaving correctly with respect to the specifications. In this case, the packet carries a version number that is not valid; otherwise, the ETR would have the same number, and the packet SHOULD be silently dropped.
2.パケットは、EID-to-RLOCデータベースに格納されているものよりも大きい（つまり、新しい）宛先マップバージョン番号で到着します。 ETRはマッピングに対して信頼できます。つまり、マッピングのMap-Version番号が正しいものであるため、仕様に関して誰かが正しく動作していないことを意味します。この場合、パケットには無効なバージョン番号が含まれています。それ以外の場合、ETRは同じ番号になり、パケットは通知なしでドロップされる必要があります（SHOULD）。
3. The packets arrive with a Destination Map-Version number smaller (i.e., older) than the one stored in the EID-to-RLOC Database. This means that the ITR sending the packet has an old mapping in its EID-to-RLOC Cache containing stale information. The ETR MAY choose to normally process the encapsulated datagram according to [RFC6830]; however, the ITR sending the packet has to be informed that a newer mapping is available. This is done with a Map-Request message sent back to the ITR. The Map-Request will either trigger a Map-Request back using the Solicit-Map-Request (SMR) bit or it will piggyback the newer mapping. These are not new mechanisms; how to use the SMR bit or how to piggyback mappings in Map-Request messages is already described in [RFC6830], while their security is discussed in [LISP-THREATS]. These Map-Request messages should be rate-limited (rate-limitation policies are also described in [RFC6830]). The feature introduced by Map-Version numbers is the possibility of blocking traffic not using the latest mapping. Indeed, after a certain number of retries, if the Destination Map-Version number in the packets is not updated, the ETR MAY drop packets with a stale Map-Version number while strongly reducing the rate of Map-Request messages. This is because either the ITR is refusing to use the mapping for which the ETR is authoritative, or (worse) it might be some form of attack. Another case might be that the control plane is experiencing transient failures, so the Map-Requests cannot reach that ITR. By continually sending Map-Requests at a very low rate, it is possible to recover from this situation.
3. パケットは、EID-to-RLOCデータベースに格納されているものよりも小さい（つまり古い）宛先マップバージョン番号で到着します。これは、パケットを送信するITRが、古い情報を含むEID-to-RLOCキャッシュに古いマッピングを持っていることを意味します。 ETRは、[RFC6830]に従って、カプセル化されたデータグラムを通常どおり処理することを選択できます。ただし、パケットを送信するITRには、新しいマッピングが使用可能であることを通知する必要があります。これは、ITRに送り返されるMap-Requestメッセージで行われます。 Map-Requestは、Solicit-Map-Request（SMR）ビットを使用してMap-Requestをトリガーするか、新しいマッピングをピギーバックします。これらは新しいメカニズムではありません。 SMRビットの使用方法またはMap-Requestメッセージでマッピングをピギーバックする方法は、すでに[RFC6830]で説明されていますが、それらのセキュリティについては[LISP-THREATS]で説明されています。これらのMap-Requestメッセージはレート制限する必要があります（レート制限ポリシーは[RFC6830]でも説明されています）。 Map-Version番号によって導入された機能は、最新のマッピングを使用していないトラフィックをブロックする可能性です。実際、一定回数の再試行後、パケットの宛先Map-Version番号が更新されない場合、ETRは古いMap-Version番号のパケットをドロップする一方で、Map-Requestメッセージのレートを大幅に低下させる可能性があります。これは、ITRがETRが信頼できるマッピングの使用を拒否しているか、または（さらに悪いことに）何らかの形の攻撃である可能性があるためです。別のケースとして、コントロールプレーンで一時的な障害が発生しているため、Map-RequestがそのITRに到達できない場合があります。 Map-Requestを非常に低いレートで継続的に送信することにより、この状況から回復することが可能です。
The rule in the third case MAY be more restrictive. If the mapping has been the same for a period of time as long as the Time to Live (TTL) (defined in [RFC6830]) of the previous version of the mapping, all packets arriving with an old Map-Version SHOULD be silently dropped right away without issuing any Map-Request. Such action is permitted because if the new mapping with the updated version number has been unchanged for at least the same time as the TTL of the older mapping, all the entries in the EID-to-RLOC Caches of ITRs must have expired. Hence, all ITRs sending traffic should have refreshed the mapping according to [RFC6830]. If packets with old Map-Version numbers are still received, then either someone has not respected the TTL or it is a form of spoof/attack. In both cases, this is not valid behavior with respect to the specifications and the packet SHOULD be silently dropped.
3番目のケースのルールはより制限的かもしれません。以前のバージョンのマッピングの存続可能時間（TTL）（[RFC6830]で定義）である限り、マッピングが一定期間同じであった場合、古いMap-Versionで到着するすべてのパケットは警告なしにドロップされますMap-Requestを発行せずにすぐに。更新されたバージョン番号の新しいマッピングが古いマッピングのTTLと少なくとも同時に変更されていない場合、ITRのEID-to-RLOCキャッシュのすべてのエントリが期限切れになっている必要があるため、このようなアクションは許可されます。したがって、トラフィックを送信するすべてのITRは、[RFC6830]に従ってマッピングを更新する必要があります。古いMap-Version番号のパケットが引き続き受信される場合は、誰かがTTLを尊重していないか、それがスプーフィング/攻撃の形式であるかのいずれかです。どちらの場合も、これは仕様に関して有効な動作ではなく、パケットは通知なしで破棄される必要があります（SHOULD）。
LISP-encapsulated packets with the V-bit set, when the original mapping in the EID-to-RLOC Database has the version number set to the Null Map-Version value, MAY be silently dropped. As explained in Section 4.1, if an EID-to-RLOC mapping has a Null Map-Version, it means that ITRs, using the mapping for encapsulation, MUST NOT use a Map-Version number in the LISP-specific header.
Vビットが設定されたLISPカプセル化パケット、EIDからRLOCデータベースへの元のマッピングでバージョン番号がNull Map-Version値に設定されている場合、警告なしに破棄される場合があります。セクション4.1で説明したように、EIDからRLOCへのマッピングにNull Map-Versionがある場合、それはカプセル化にマッピングを使用するITRが、LISP固有のヘッダーでMap-Version番号を使用してはならないことを意味します。
For LISP-encapsulated packets with the V-bit set, when the original mapping in the EID-to-RLOC Database has the version number set to a value different from the Null Map-Version value, a Destination Map-Version number equal to the Null Map-Version value means that the Destination Map-Version number MUST be ignored.
Vビットが設定されたLISPカプセル化パケットの場合、EIDからRLOCデータベースへの元のマッピングでバージョン番号がNull Map-Version値とは異なる値に設定されている場合、Destination Map-Version番号はNull Map-Version値は、Destination Map-Version番号を無視する必要があることを意味します。
When an ETR receives a packet, the Source Map-Version number relates to the mapping for the source EID for which the ITR that sent the packet is authoritative. If the ETR has an entry in its EID-to-RLOC Cache for the source EID, then a check can be performed and the following cases can arise:
ETRがパケットを受信すると、Source Map-Version番号は、パケットを送信したITRが信頼できるソースEIDのマッピングに関連します。 ETRのEID-to-RLOCキャッシュにソースEIDのエントリがある場合、チェックを実行でき、次のケースが発生する可能性があります。
1. The packet arrives with the same Source Map-Version number as that stored in the EID-to-RLOC Cache. This is the correct regular case. The ITR has in its EID-to-RLOC Cache an up-to-date copy of the mapping. No further actions are needed.
1. パケットは、EID-to-RLOCキャッシュに保存されているものと同じSource Map-Version番号で到着します。これは正しい通常のケースです。 ITRのEIDからRLOCへのキャッシュには、マッピングの最新のコピーがあります。これ以上のアクションは必要ありません。
2. The packet arrives with a Source Map-Version number greater (i.e., newer) than the one stored in the local EID-to-RLOC Cache. This means that the ETR has in its EID-to-RLOC Cache a mapping that is stale and needs to be updated. A Map-Request SHOULD be sent to get the new mapping for the source EID. This is a normal Map-Request message sent through the mapping system and MUST respect the specifications in [RFC6830], including rate-limitation policies.
2. パケットは、ローカルのEID-to-RLOCキャッシュに格納されているものよりも大きい（つまり、新しい）Source Map-Version番号で到着します。これは、ETRのEIDからRLOCへのキャッシュに、古くて更新が必要なマッピングがあることを意味します。ソースEIDの新しいマッピングを取得するには、Map-Requestを送信する必要があります（SHOULD）。これは、マッピングシステムを介して送信される通常のMap-Requestメッセージであり、レート制限ポリシーを含む[RFC6830]の仕様を遵守する必要があります。
3. The packet arrives with a Source Map-Version number smaller (i.e., older) than the one stored in the local EID-to-RLOC Cache. Such a case is not valid with respect to the specifications. Indeed, if the mapping is already present in the EID-to-RLOC Cache, this means that an explicit Map-Request has been sent and a Map-Reply has been received from an authoritative source. Assuming that the mapping system is not corrupted, the Map-Version in the EID-to-RLOC Cache is the correct one, while the one carried by the packet is stale. In this situation, the packet MAY be silently dropped.
3. パケットは、ローカルのEID-to-RLOCキャッシュに格納されているものよりも小さい（つまり、古い）Source Map-Version番号で到着します。このような場合は仕様上有効ではありません。実際、マッピングがEID-to-RLOCキャッシュにすでに存在する場合、これは明示的なMap-Requestが送信され、Map-Replyが信頼できるソースから受信されたことを意味します。マッピングシステムが破損していないと想定すると、EID-to-RLOCキャッシュのMap-Versionは正しいものですが、パケットが運ぶものは古くなっています。この状況では、パケットは静かにドロップされるかもしれません。
If the ETR does not have an entry in the EID-to-RLOC Cache for the source EID (e.g., in the case of unidirectional traffic), then the Source Map-Version number can be safely ignored.
ETRのソースEIDに対するEID-to-RLOCキャッシュにエントリがない場合（たとえば、単方向トラフィックの場合）、ソースMap-Version番号は無視しても問題ありません。
For LISP-encapsulated packets with the V-bit set, if the Source Map-Version number is the Null Map-Version value, it means that the Source Map-Version number MUST be ignored.
Vビットが設定されたLISPカプセル化パケットの場合、Source Map-Version番号がNull Map-Version値である場合、Source Map-Version番号を無視する必要があることを意味します。
In order for the versioning approach to work, the LISP-specific header has to carry both the Source Map-Version number and Destination Map-Version number. This is done by setting the V-bit in the LISP-specific header as defined in [RFC6830] Section 5.3. When the V-bit is set, the low-order 24 bits of the first longword are used to transport both the source and destination Map-Version numbers. In particular, the first 12 bits are used for the Source Map-Version number and the second 12 bits for the Destination Map-Version number.
バージョン管理アプローチが機能するためには、LISP固有のヘッダーに、ソースマップバージョン番号と宛先マップバージョン番号の両方が含まれている必要があります。これは、[RFC6830]セクション5.3で定義されているように、LISP固有のヘッダーにVビットを設定することによって行われます。 Vビットが設定されている場合、最初のロングワードの下位24ビットを使用して、ソースと宛先の両方のMap-Version番号が転送されます。特に、最初の12ビットはソースマップバージョン番号に使用され、2番目の12ビットは宛先マップバージョン番号に使用されます。
Below is an example of a LISP header carrying version numbers in the case of IPv4-in-IPv4 encapsulation. The same setting can be used for any other case (IPv4-in-IPv6, IPv6-in-IPv4, and IPv6-in-IPv6).
以下は、IPv4-in-IPv4カプセル化の場合のバージョン番号を運ぶLISPヘッダーの例です。その他の場合（IPv4-in-IPv6、IPv6-in-IPv4、およびIPv6-in-IPv6）にも同じ設定を使用できます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |N|L|E|V|I|flags| Source Map-Version |Destination Map-Version|
LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Map-Version number (12 bits): Map-Version of the mapping used by the ITR to select the RLOC present in the 'Source Routing Locator' field. Section 5.2 describes how to set this value on transmission and handle it on reception.
ソースMap-Version番号（12ビット）：ITRが「Source Routing Locator」フィールドに存在するRLOCを選択するために使用するマッピングのMap-Version。セクション5.2では、送信時にこの値を設定し、受信時に処理する方法について説明します。
Destination Map-Version number (12 bits): Map-Version of the mapping used by the ITR to select the RLOC present in the 'Destination Routing Locator' field. Section 5.1 describes how to set this value on transmission and handle it on reception.
宛先マップバージョン番号（12ビット）：ITRが「宛先ルーティングロケーター」フィールドに存在するRLOCを選択するために使用するマッピングのマップバージョン。セクション5.1では、送信時にこの値を設定し、受信時に処理する方法について説明します。
This document only specifies how to use the low-order 24 bits of the first longword of the LISP-specific header when the V-bit is set to 1. All other cases, including the bit fields of the rest of the LISP-specific header and the whole LISP packet format, are specified in [RFC6830]. Not all of the LISP-encapsulated packets need to carry version numbers. When Map-Version numbers are carried in these packets, the V-bit MUST be set to 1. All permissible combinations of the flags when the V-bit is set to 1 are described in [RFC6830].
このドキュメントでは、Vビットが1に設定されている場合のLISP固有ヘッダーの最初のロングワードの下位24ビットの使用方法のみを指定しますおよびLISPパケット形式全体は、[RFC6830]で指定されています。すべてのLISPカプセル化パケットがバージョン番号を運ぶ必要はありません。 Map-Version番号がこれらのパケットで運ばれるとき、Vビットは1に設定されなければなりません（MUST）。
To accommodate the proposed mechanism, the Map Records that are transported in Map-Request/Map-Reply/Map-Register messages need to carry the Map-Version number as well. For this purpose, the 12 bits before the 'EID-Prefix-AFI' field in the Record that describes a mapping are used. This is defined in Section 6.1.4 of [RFC6830] and reported here as an example.
提案されたメカニズムに対応するには、Map-Request / Map-Reply / Map-Registerメッセージで転送されるマップレコードもMap-Version番号を運ぶ必要があります。この目的のために、マッピングを記述するレコードの「EID-Prefix-AFI」フィールドの前の12ビットが使用されます。これは[RFC6830]のセクション6.1.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
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 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 |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Map-Version Number: Map-Version of the mapping contained in the Record. As explained in Section 4.1, this field can be zero (0), meaning that no Map-Version is associated to the mapping; hence, packets that are LISP encapsulated using this mapping MUST NOT contain Map-Version numbers in the LISP-specific header, and the V-bit MUST be set to 0.
Map-Version番号：Recordに含まれるマッピングのMap-Version。セクション4.1で説明したように、このフィールドはゼロ（0）にすることができます。これは、Map-Versionがマッピングに関連付けられていないことを意味します。したがって、このマッピングを使用してLISPでカプセル化されたパケットには、LISP固有のヘッダーにMap-Version番号を含めてはならず、Vビットを0に設定する必要があります。
This packet format works perfectly with xTRs that do not support Map-Versioning, since they can simply ignore those bits.
このパケット形式は、Map-VersioningをサポートしないxTRと完全に連携します。それらは、それらのビットを単に無視できるからです。
In the following sections, we provide more discussion on various aspects and uses of Map-Versioning. Security observations are grouped in Section 10.
次のセクションでは、Map-Versioningのさまざまな側面と使用法について詳しく説明します。セキュリティ監視はセクション10にまとめられています。
When using Map-Versioning, the LISP-specific header carries two Map-Version numbers, for both source and destination mappings. This can raise the question on what will happen in the case of unidirectional flows, for instance, in the case presented in Figure 1, since the LISP specification does not mandate that the ETR have a mapping for the source EID.
Map-Versioningを使用する場合、LISP固有のヘッダーは、送信元と宛先の両方のマッピングに対して2つのMap-Version番号を保持します。 LISP仕様では、ETRにソースEIDのマッピングがあると規定されていないため、これは、たとえば図1に示されているケースのように、単方向フローの場合にどうなるかという問題を提起します。
+-----------------+ +-----------------+
| Domain A | | Domain B |
| +---------+ +---------+ |
| | ITR A |----------->| ETR B | |
| +---------+ +---------+ |
| | | |
+-----------------+ +-----------------+
Figure 1: Unidirectional Traffic between LISP Domains
図1：LISPドメイン間の単方向トラフィック
In the case of the ITR, the ITR is able to put both the source and destination version number in the LISP header, since the Source Map-Version number is in the ITR's database, while the Destination Map-Version number is in the ITR's cache.
ITRの場合、送信元マップバージョン番号はITRのデータベースにあり、送信先マップバージョン番号はITRのキャッシュにあるため、ITRは送信元バージョン番号と宛先バージョン番号の両方をLISPヘッダーに入れることができます。 。
In the case of the ETR, the ETR simply checks only the Destination Map-Version number in the same way as that described in Section 5, ignoring the Source Map-Version number.
ETRの場合、ETRはセクション5で説明したのと同じ方法で宛先マップバージョン番号のみをチェックするだけで、ソースマップバージョン番号は無視されます。
Map-Versioning is compatible with the LISP interworking between LISP and non-LISP sites as defined in [RFC6832]. LISP interworking defines three techniques to make LISP sites and non-LISP sites, namely Proxy-ITR, LISP-NAT, and Proxy-ETR. The following text describes how Map-Versioning relates to these three mechanisms.
Map-Versioningは、[RFC6832]で定義されているLISPサイトと非LISPサイト間のLISPインターワーキングと互換性があります。 LISPインターワーキングでは、LISPサイトと非LISPサイトを作成するための3つの技術、つまりProxy-ITR、LISP-NAT、およびProxy-ETRを定義しています。次のテキストは、Map-Versioningがこれら3つのメカニズムにどのように関係するかを説明しています。
The purpose of the Proxy-ITR (PITR) is to encapsulate traffic originating in a non-LISP site in order to deliver the packet to one of the ETRs of the LISP site (cf. Figure 2). This case is very similar to the unidirectional traffic case described in Section 8.1; hence, similar rules apply.
Proxy-ITR（PITR）の目的は、LISPサイトのETRの1つにパケットを配信するために、非LISPサイトで発生したトラフィックをカプセル化することです（図2を参照）。このケースは、セクション8.1で説明した単方向トラフィックのケースと非常に似ています。したがって、同様のルールが適用されます。
+----------+ +-------------+
| LISP | | non-LISP |
| Domain A | | Domain B |
| +-------+ +-----------+ | |
| | ETR A |<-------| Proxy-ITR |<-------| |
| +-------+ +-----------+ | |
| | | |
+----------+ +-------------+
Figure 2: Unidirectional Traffic from Non-LISP Domain to LISP Domain
図2：非LISPドメインからLISPドメインへの単方向トラフィック
The main difference is that a Proxy-ITR does not have any mapping, since it just encapsulates packets arriving from the non-LISP site and thus cannot provide a Source Map-Version. In this case, the Proxy-ITR will just put the Null Map-Version value as the Source Map-Version number, while the receiving ETR will ignore the field.
主な違いは、Proxy-ITRはマッピングを持たないということです。これは、非LISPサイトから到着するパケットをカプセル化するだけで、Source Map-Versionを提供できないためです。この場合、Proxy-ITRはNull Map-Version値をSource Map-Version番号として配置するだけですが、受信ETRはフィールドを無視します。
With this setup, LISP Domain A is able to check whether or not the PITR is using the latest mapping. If this is not the case, the mapping for LISP Domain A on the PITR can be updated using one of the mechanisms defined in [RFC6830] and [RFC6832].
この設定により、LISPドメインAは、PITRが最新のマッピングを使用しているかどうかを確認できます。そうでない場合、PITR上のLISPドメインAのマッピングは、[RFC6830]および[RFC6832]で定義されているメカニズムの1つを使用して更新できます。
The LISP-NAT mechanism is based on address translation from non-routable EIDs to routable EIDs and does not involve any form of encapsulation. As such, Map-Versioning does not apply in this case.
LISP-NATメカニズムは、ルーティング不可能なEIDからルーティング可能なEIDへのアドレス変換に基づいており、いかなる形式のカプセル化も含みません。そのため、この場合、マップのバージョン管理は適用されません。
The purpose of the Proxy-ETR (PETR) is to decapsulate traffic originating in a LISP site in order to deliver the packet to the non-LISP site (cf. Figure 3). One of the main reasons to deploy PETRs is to bypass uRPF (Unicast Reverse Path Forwarding) checks on the provider edge.
Proxy-ETR（PETR）の目的は、パケットを非LISPサイトに配信するために、LISPサイトで発生したトラフィックのカプセル化を解除することです（図3を参照）。 PETRを展開する主な理由の1つは、プロバイダーエッジでのuRPF（ユニキャストリバースパス転送）チェックをバイパスすることです。
+----------+ +-------------+
| LISP | | non-LISP |
| Domain A | | Domain B |
| +-------+ +-----------+ | |
| | ITR A |------->| Proxy-ETR |------->| |
| +-------+ +-----------+ | |
| | | |
+----------+ +-------------+
Figure 3: Unidirectional Traffic from LISP Domain to Non-LISP Domain
図3：LISPドメインから非LISPドメインへの単方向トラフィック
A Proxy-ETR does not have any mapping, since it just decapsulates packets arriving from the LISP site. In this case, the ITR will just put the Null Map-Version value as the Destination Map-Version number, while the receiving Proxy-ETR will ignore the field.
プロキシETRは、LISPサイトから到着するパケットのカプセル化を解除するだけなので、マッピングはありません。この場合、ITRはNull Map-Version値をDestination Map-Version番号として配置するだけですが、受信Proxy-ETRはフィールドを無視します。
With this setup, the Proxy-ETR is able to check whether or not the mapping has changed. If this is the case, the mapping for LISP Domain A on the PETR can be updated using one of the mechanisms defined in [RFC6830] and [RFC6832].
この設定により、Proxy-ETRはマッピングが変更されたかどうかを確認できます。この場合、PETR上のLISPドメインAのマッピングは、[RFC6830]および[RFC6832]で定義されているメカニズムの1つを使用して更新できます。
Map-Versioning can also be used to perform a graceful shutdown or withdraw of a specific RLOC. This is achieved by simply issuing a new mapping, with an updated Map-Version number where the specific RLOC to be shut down is withdrawn or announced as unreachable (via the R-bit in the Map Record; see [RFC6830]), but without actually turning it off.
Map-Versioningは、特定のRLOCの適切なシャットダウンまたは取り消しを実行するためにも使用できます。これは、シャットダウンする特定のRLOCが（マップレコードのRビットを介して）[RFC6830]を参照して）取り消されるか、到達不能であると更新されたMap-Version番号を使用して、新しいマッピングを発行するだけで実現できます。実際にはオフにしています。
Once no more traffic is received by the RLOC, it can be shut down gracefully, because all sites actively using the mapping have updated it.
RLOCがトラフィックを受信しなくなったら、マッピングをアクティブに使用しているすべてのサイトで更新されているため、正常にシャットダウンできます。
It should be pointed out that for frequent up/down changes such a mechanism should not be used, since this can generate excessive load on the mapping system.
アップ/ダウンを頻繁に変更する場合は、このようなメカニズムを使用しないでください。マッピングシステムに過度の負荷がかかる可能性があるためです。
The use of Map-Versioning can help in developing a lightweight implementation of LISP. However, this comes with the price of not supporting the Locator-Status-Bit, which is useful in some contexts.
Map-Versioningの使用は、LISPの軽量実装の開発に役立ちます。ただし、これにはLocator-Status-Bitをサポートしないという代償が伴います。これは、状況によっては役立ちます。
In the current LISP specifications, the set of RLOCs must always be maintained ordered and consistent with the content of the Locator-Status-Bits (see Section 6.5 of [RFC6830]). With Map-Versioning, such types of mechanisms can be avoided. When a new RLOC is added to a mapping, it is not necessary to "append" new Locators to the existing ones as explained in Section 6.5 of [RFC6830]. A new mapping with a new Map-Version number will be issued, and since the old Locators are still valid, the transition will occur with no disruptions. The same applies for the case where an RLOC is withdrawn. There is no need to maintain holes in the list of Locators, as is the case when using Locator-Status-Bits, for sites that are not using the RLOC that has been withdrawn; in this case, the transition will occur with no disruptions.
現在のLISP仕様では、RLOCのセットは常に順序付けされ、Locator-Status-Bitsの内容と一致するように維持する必要があります（[RFC6830]のセクション6.5を参照）。 Map-Versioningを使用すると、このようなタイプのメカニズムを回避できます。 [RLC6830]のセクション6.5で説明されているように、新しいRLOCをマッピングに追加する場合、新しいロケーターを既存のロケーターに「追加」する必要はありません。新しいMap-Version番号を使用した新しいマッピングが発行され、古いロケーターがまだ有効であるため、中断することなく移行が行われます。 RLOCが撤回された場合も同様です。撤回されたRLOCを使用していないサイトの場合、Locator-Status-Bitsを使用する場合のように、ロケーターのリストに穴を維持する必要はありません。この場合、移行は中断することなく行われます。
All of these operations, as already stated, do not need to maintain any consistency among Locator-Status-Bits and in the way that the RLOCs are stored in the EID-to-RLOC Cache.
すでに述べたように、これらの操作はすべて、Locator-Status-Bits間で一貫性を維持する必要はなく、RLOCがEID-to-RLOCキャッシュに格納されるようにする必要もありません。
Further, Map-Versioning can be used as a substitute for the "clock sweep" operation described in Section 6.6.1 of [RFC6830]. Indeed, every LISP site communicating to a specific LISP site that has updated the mapping will be informed of the available new mapping in a data-driven manner.
さらに、Map-Versioningは、[RFC6830]のセクション6.6.1で説明されている「クロックスイープ」操作の代わりに使用できます。実際、マッピングを更新した特定のLISPサイトと通信しているすべてのLISPサイトには、利用可能な新しいマッピングがデータ主導で通知されます。
Note that what is proposed in this section is just an example and MUST NOT be considered as specifications for a lightweight LISP implementation. If the IETF decides to undertake such work, it will be documented elsewhere.
このセクションで提案されているのは単なる例であり、軽量のLISP実装の仕様と見なしてはならないことに注意してください。 IETFがそのような作業を行うことを決定した場合、それは他の場所で文書化されます。
Map-Versioning can be incrementally deployed without any negative impact on existing LISP elements (e.g., xTRs, Map-Servers, Proxy-ITRs, etc.). Any LISP element that does not support Map-Versioning can safely ignore Map-Version numbers carried in the LISP header. Further, there is no need of any specific mechanism to discover whether or not an xTR supports Map-Versioning. This information is already included in the Map Record.
Map-Versioningは、既存のLISP要素（xTR、Map-Server、Proxy-ITRなど）に悪影響を与えることなく段階的に展開できます。 Map-VersioningをサポートしないLISP要素は、LISPヘッダーで運ばれるMap-Version番号を安全に無視できます。さらに、xTRがMap-Versioningをサポートしているかどうかを検出するための特定のメカニズムは必要ありません。この情報はすでにマップレコードに含まれています。
Map-Versioning is currently implemented in OpenLISP [OPENLISP].
Map-Versioningは現在OpenLISP [OPENLISP]で実装されています。
Note that the reference document for LISP implementations and interoperability tests remains [RFC6830].
LISP実装と相互運用性テストのリファレンスドキュメントは[RFC6830]のままであることに注意してください。
Map-Versioning does not introduce any security issues concerning both the data plane and the control plane. On the contrary, as described below, if Map-Versioning may also be used to update mappings in the case of change in the reachability information (i.e., instead of the Locator-Status-Bits), it is possible to reduce the effects of some DoS or spoofing attacks that can happen in an untrusted environment.
Map-Versioningでは、データプレーンとコントロールプレーンの両方に関するセキュリティの問題は発生しません。逆に、以下に説明するように、到達可能性情報が変更された場合（つまり、Locator-Status-Bitsの代わりに）、Map-Versioningを使用してマッピングを更新すると、一部の影響を減らすことができます。信頼できない環境で発生する可能性のあるDoSまたはスプーフィング攻撃。
Robustness of the Map-Versioning mechanism leverages on a trusted Mapping Distribution System. A thorough security analysis of LISP is documented in [LISP-THREATS].
マップのバージョン管理メカニズムの堅牢性は、信頼できるマッピング配布システムを活用しています。 LISPの完全なセキュリティ分析は、[LISP-THREATS]に文書化されています。
An attacker can try to disrupt ongoing communications by creating LISP-encapsulated packets with wrong Locator-Status-Bits. If the xTR blindly trusts the Locator-Status-Bits, it will change the encapsulation accordingly, which can result in traffic disruption.
攻撃者は、誤ったLocator-Status-BitsでLISPカプセル化パケットを作成することにより、進行中の通信を妨害しようと試みる可能性があります。 xTRがLocator-Status-Bitsを盲目的に信頼している場合、それに応じてカプセル化が変更されるため、トラフィックが中断する可能性があります。
This does not happen in the case of Map-Versioning. As described in Section 5, upon a version number change the xTR first issues a Map-Request. The assumption is that the mapping distribution system is sufficiently secure that Map-Request and Map-Reply messages and their content can be trusted. Security issues concerning specific mapping distribution systems are out of the scope of this document. In the case of Map-Versioning, the attacker should "guess" a valid version number that triggers a Map-Request as described in Section 5; otherwise, the packet is simply dropped. Nevertheless, guessing a version number that generates a Map-Request is easy; hence, it is important to follow the rate-limitation policies described in [RFC6830] in order to avoid DoS attacks.
これは、Map-Versioningの場合は発生しません。セクション5で説明したように、バージョン番号が変更されると、xTRは最初にMap-Requestを発行します。前提条件は、マッピング配布システムが十分に安全で、Map-RequestおよびMap-Replyメッセージとそれらのコンテンツを信頼できることです。特定のマッピング配布システムに関するセキュリティの問題は、このドキュメントの範囲外です。 Map-Versioningの場合、攻撃者はセクション5で説明されているようにMap-Requestをトリガーする有効なバージョン番号を「推測」する必要があります。それ以外の場合、パケットは単にドロップされます。それでも、Map-Requestを生成するバージョン番号を推測するのは簡単です。したがって、DoS攻撃を回避するには、[RFC6830]で説明されているレート制限ポリシーに従うことが重要です。
Note that a similar level of security can be obtained with Locator-Status-Bits by simply making it mandatory to verify any change through a Map-Request. However, in this case Locator-Status-Bits lose their meaning, because it does not matter anymore which specific bits have changed; the xTR will query the mapping system and trust the content of the received Map-Reply. Furthermore, there is no way to perform filtering as in Map-Versioning in order to drop packets that do not carry a valid Map-Version number. In the case of Locator-Status-Bits, any random change can trigger a Map-Request (unless rate limitation is enabled, which raises another type of attack as discussed in Section 10.2).
同様のレベルのセキュリティは、Map-Requestによる変更の検証を必須にするだけで、Locator-Status-Bitsを使用して取得できることに注意してください。ただし、この場合、どの特定のビットが変更されたかは問題ではなくなるため、Locator-Status-Bitsは意味を失います。 xTRはマッピングシステムを照会し、受信したMap-Replyのコンテンツを信頼します。さらに、有効なMap-Version番号を持たないパケットをドロップするためにMap-Versioningのようにフィルタリングを実行する方法はありません。 Locator-Status-Bitsの場合、ランダムな変更がMap-Requestをトリガーする可能性があります（レート制限が有効になっておらず、セクション10.2で説明した別のタイプの攻撃が発生する場合を除く）。
Attackers can try to trigger a large amount of Map-Requests by simply forging packets with random Map-Versions or random Locator-Status-Bits. In both cases, the Map-Requests are rate-limited as described in [RFC6830]. However, in contrast to the Locator-Status-Bit, where there is no filtering possible, in the case of Map-Versioning it is possible to filter invalid version numbers before triggering a Map-Request, thus helping to reduce the effects of DoS attacks. In other words, the use of Map-Versioning enables a fine control on when to update a mapping or when to notify someone that a mapping has been updated.
攻撃者は、ランダムなMap-VersionsまたはランダムなLocator-Status-Bitsでパケットを偽造するだけで、大量のMap-Requestsをトリガーしようと試みることができます。どちらの場合でも、[RFC6830]で説明されているように、Map-Requestはレート制限されています。ただし、フィルタリングができないLocator-Status-Bitとは対照的に、Map-Versioningの場合、Map-Requestをトリガーする前に無効なバージョン番号をフィルタリングすることができるため、DoS攻撃の影響を軽減するのに役立ちます。 。つまり、Map-Versioningを使用すると、マッピングを更新するタイミングや、マッピングが更新されたことを誰かに通知するタイミングを細かく制御できます。
It is clear that Map-Versioning does not protect against DoS and DDoS attacks, where an xTR loses processing power when doing checks on the LISP header of packets sent by attackers. This is independent of Map-Versioning and is the same for Locator-Status-Bits.
Map-VersioningがDoSおよびDDoS攻撃から保護されていないことは明らかです。この場合、攻撃者が送信したパケットのLISPヘッダーをチェックするときに、xTRは処理能力を失います。これはMap-Versioningから独立しており、Locator-Status-Bitsでも同じです。
There are a number of implications of the use of Map-Versioning that are not yet completely explored. Among these are:
Map-Versioningの使用には、まだ完全には検討されていない多くの影響があります。これらの中で：
o Performance of the convergence time when an EID-to-RLOC mapping changes, i.e., how much time is needed to update mappings in the EID-to-RLOC Cache of the ITRs currently sending traffic to ETRs for the EID whose mapping has been changed.
o EIDからRLOCへのマッピングが変更されたときの収束時間のパフォーマンス、つまり、マッピングが変更されたEIDのETRに現在トラフィックを送信しているITRのEIDからRLOCキャッシュへのマッピングを更新するために必要な時間。
o Support for ETR synchronization. The implications that a temporary lack of synchronization may have on the traffic are yet to be fully explored. Details on how to maintain synchronization are presented in Section 6.6 of [RFC6830]. Section 11.1 discusses the issue in further detail with respect to the Map-Versioning mechanism.
o ETR同期のサポート。一時的な同期の欠如がトラフィックに与える可能性のある影響については、まだ十分に検討されていません。同期を維持する方法の詳細は、[RFC6830]のセクション6.6に記載されています。セクション11.1では、マップのバージョン管理メカニズムに関してこの問題をさらに詳しく説明しています。
The authors expect that experimentation will help assess the performance and limitations of the Map-Versioning mechanism. Issues and concerns about the deployment of LISP for Internet traffic are discussed in [RFC6830].
著者は、実験がMap-Versioningメカニズムのパフォーマンスと制限の評価に役立つことを期待しています。インターネットトラフィック用のLISPの展開に関する問題と懸念事項は、[RFC6830]で説明されています。
Even without Map-Versioning, LISP ([RFC6830]) requires ETRs to announce the same mapping for the same EID-Prefix to a requester. The implications that a temporary lack of synchronization may have on the traffic are yet to be fully explored.
Map-Versioningがない場合でも、LISP（[RFC6830]）では、ETRが同じEID-Prefixの同じマッピングをリクエスタに通知する必要があります。一時的な同期の欠如がトラフィックに与える可能性のある影響については、まだ十分に検討されていません。
Map-Versioning does not require additional synchronization mechanisms as compared to the normal functioning of LISP without Map-Versioning. Clearly, all the ETRs have to reply with the same Map-Version number; otherwise, there can be an inconsistency that creates additional control traffic, instabilities, and traffic disruptions. It is the same without Map-Versioning, with ETRs that have to reply with the same mapping; otherwise, the same problems can arise.
Map-Versioningを使用しないLISPの通常の機能と比較して、Map-Versioningは追加の同期メカニズムを必要としません。明らかに、すべてのETRは同じMap-Version番号で応答する必要があります。そうしないと、追加の制御トラフィック、不安定性、およびトラフィックの中断を引き起こす不整合が発生する可能性があります。これは、Map-Versioningがなくても同じで、ETRは同じマッピングで応答する必要があります。そうしないと、同じ問題が発生する可能性があります。
There are two ways Map-Versioning is helpful with respect to the synchronization problem. On the one hand, assigning version numbers to mappings helps in debugging, since quick checks on the consistency of the mappings on different ETRs can be done by looking at the Map-Version number. On the other hand, Map-Versioning can be used to control the traffic toward ETRs that announce the latest mapping.
同期の問題に関してMap-Versioningが役立つ2つの方法があります。一方で、マッピングにバージョン番号を割り当てるとデバッグに役立ちます。これは、Map-Version番号を確認することで、さまざまなETRのマッピングの整合性をすばやく確認できるためです。一方、Map-Versioningを使用して、最新のマッピングを通知するETRへのトラフィックを制御できます。
As an example, let's consider the topology of Figure 4 where ITR A.1 of Domain A is sending unidirectional traffic to Domain B, while A.2 of Domain A exchanges bidirectional traffic with Domain B. In particular, ITR A.2 sends traffic to ETR B, and ETR A.2 receives traffic from ITR B.
例として、ドメインAのITR A.1が単一方向のトラフィックをドメインBに送信し、ドメインAのA.2がドメインBと双方向のトラフィックを交換している図4のトポロジを考えてみましょう。特に、ITR A.2がトラフィックを送信します。 ETR Bに送信され、ETR A.2はITR Bからトラフィックを受信します。
+-----------------+ +-----------------+
| Domain A | | Domain B |
| +---------+ | |
| | ITR A.1 |--- | |
| +---------+ \ +---------+ |
| | ------->| ETR B | |
| | ------->| | |
| +---------+ / | | |
| | ITR A.2 |--- -----| ITR B | |
| | | / +---------+ |
| | ETR A.2 |<----- | |
| +---------+ | |
| | | |
+-----------------+ +-----------------+
Figure 4: Example Topology
図4：トポロジーの例
Obviously, in the case of Map-Versioning, both ITR A.1 and ITR A.2 of Domain A must use the same value; otherwise, the ETR of Domain B will start to send Map-Requests.
明らかに、Map-Versioningの場合、ドメインAのITR A.1とITR A.2の両方が同じ値を使用する必要があります。それ以外の場合、ドメインBのETRはマップ要求の送信を開始します。
The same problem can, however, arise without Map-Versioning, for instance, if the two ITRs of Domain A send different Locator-Status-Bits. In this case, either the traffic is disrupted if ETR B trusts the Locator-Status-Bits, or if ETR B does not trust the Locator-Status-Bits it will start sending Map-Requests to confirm each change in reachability.
ただし、たとえばドメインAの2つのITRが異なるLocator-Status-Bitsを送信する場合、Map-Versioningなしで同じ問題が発生する可能性があります。この場合、ETR BがLocator-Status-Bitsを信頼している場合、またはETR BがLocator-Status-Bitsを信頼していない場合、トラフィックは中断され、到達可能性の各変更を確認するためにMap-Requestの送信を開始します。
So far, LISP does not provide any specific synchronization mechanism but assumes that synchronization is provided by configuring the different xTRs consistently (see Section 6.6 in [RFC6830]). The same applies for Map-Versioning. If in the future any synchronization mechanism is provided, Map-Versioning will take advantage of it automatically, since it is included in the Record format, as described in Section 7.
これまでのところ、LISPは特定の同期メカニズムを提供していませんが、さまざまなxTRを一貫して構成することで同期が提供されると想定しています（[RFC6830]のセクション6.6を参照）。同じことがMap-Versioningにも当てはまります。セクション7で説明されているように、将来的に同期メカニズムが提供された場合、Map-VersioningはRecordフォーマットに含まれているため、それを自動的に利用します。
The authors would like to thank Alia Atlas, Jesper Skriver, Pierre Francois, Noel Chiappa, and Dino Farinacci for their comments and review.
著者は、アリアアトラス、ジェスパースクリバー、ピエールフランソワ、ノエルチアッパ、ディノファリナッチにコメントとレビューをしてくれたことに感謝します。
This work has been partially supported by the INFSO-ICT-216372 TRILOGY Project (http://www.trilogy-project.org).
この作業は、INFSO-ICT-216372 TRILOGYプロジェクト（http://www.trilogy-project.org）によって部分的にサポートされています。
[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月。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.
[RFC6830] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol（LISP）」、RFC 6830、2013年1月。
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6832] Lewis、D.、Meyer、D.、Farinacci、D。、およびV. Fuller、「Locator / ID Separation Protocol（LISP）and Non-LISP Sites between Interworking」、RFC 6832、2013年1月。
[LISP-THREATS] Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Analysis", Work in Progress, October 2012.
[LISP-THREATS] Saucez、D.、Iannone、L。、およびO. Bonaventure、「LISP脅威分析」、Work in Progress、2012年10月。
[OPENLISP] Iannone, L., Saucez, D., and O. Bonaventure, "Implementing the Locator/ID Separation Protocol: Design and experience", Computer Networks Vol. 55, Number 4, Pages 948-958, March 2011.
[OPENLISP] Iannone、L.、Saucez、D。、およびO. Bonaventure、「Implementing Locator / ID Separation Protocol：Design and experience」、Computer Networks Vol。 55、Number 4、Pages 948-958、March 2011。
This section proposes an estimation of the wrap-around time for the 12-bit size of the Map-Version number.
このセクションでは、Map-Version番号の12ビットサイズのラップアラウンドタイムの見積もりを提案します。
Using a granularity of seconds and assuming as worst case that a new version is issued each second, it takes slightly more than 1 hour before the version wraps around. Note that the granularity of seconds is in line with the rate-limitation policy for Map-Request messages, as proposed in the LISP main specifications ([RFC6830]).
秒の粒度を使用し、最悪の場合、毎秒新しいバージョンが発行されると想定すると、バージョンが循環するまでに1時間強かかります。 LISPの主要な仕様（[RFC6830]）で提案されているように、秒の細分性はMap-Requestメッセージのレート制限ポリシーに沿っていることに注意してください。
Alternatively, a granularity of minutes can also be used, as for the TTL of the Map-Reply ([RFC6830]). In this case, the worst-case scenario is when a new version is issued every minute, leading to a much longer time before wrap-around. In particular, when using 12 bits, the wrap-around time is almost 3 days.
あるいは、Map-ReplyのTTL（[RFC6830]）のように、分単位の粒度も使用できます。この場合、最悪のシナリオは、毎分新しいバージョンが発行され、ラップアラウンドまでの時間が非常に長くなる場合です。特に、12ビットを使用する場合、ラップアラウンドタイムはほぼ3日です。
For general information, Figure 5 below provides a rough estimation of the time before wrap-around in the worst-case scenario, considering different sizes (length in bits) of the Map-Version number and different time granularities.
一般的な情報については、以下の図5は、Map-Version番号のさまざまなサイズ（ビット長）とさまざまな時間の細分性を考慮して、最悪のシナリオでのラップアラウンド前の時間の概算を示しています。
Since even in the case of a high mapping change rate (1 per second) the wrap-around time using 12 bits is far larger than any reasonable Round-Trip Time (RTT), there is no risk of race conditions.
高いマッピング変更率（1秒あたり1）の場合でも、12ビットを使用したラップアラウンドタイムは、妥当なラウンドトリップタイム（RTT）よりはるかに長いため、競合状態のリスクはありません。
+---------------+--------------------------------------------+
|Version Number | Time before Wrap-Around |
| Size (bits) +---------------------+----------------------+
| |Granularity: Minutes | Granularity: Seconds |
| | (mapping changes | (mapping changes |
| | every 1 minute) | every 1 second) |
+-------------------------------------+----------------------+
| 32 | 8171 years | 136 years |
| 30 | 2042 years | 34 years |
| 24 | 31 years | 194 days |
| 16 | 45 days | 18 hours |
| 15 | 22 days | 9 hours |
| 14 | 11 days | 4 hours |
| 13 | 5.6 days | 2.2 hours |
| 12 | 2.8 days | 1.1 hours |
+---------------+---------------------+----------------------+
Figure 5: Estimation of Time before Wrap-Around
図5：ラップアラウンド前の時間の推定
Authors' Addresses
著者のアドレス
Luigi Iannone Telecom ParisTech
Luigi Iannone Telecom ParisTech
EMail: luigi.iannone@telecom-paristech.fr
Damien Saucez INRIA Sophia Antipolis 2004 route des Lucioles - BP 93 Sophia Antipolis France
ダミアンサウセINRIAソフィアアンティポリス2004 route des Lucioles-BP 93ソフィアアンティポリスフランス
EMail: damien.saucez@inria.fr
Olivier Bonaventure Universite catholique de Louvain Place St. Barbe 2 Louvain-la-Neuve Belgium
Olivier Bonaventureカトリック大学ルーヴァン校Place St. Barbe 2ルーヴァンラヌーブベルギー
EMail: olivier.bonaventure@uclouvain.be