[要約] RFC 9302 は、LISP Map-Versioning 機構を説明し、EID-to-RLOC マッピングのバージョン番号を伝達することで、LISP データパケットのカプセル化に関する情報を提供します。この機構は、パケットのカプセル化に使用されるマッピングの変更を通知するために、ITR と ETR に特に役立ちます。
Internet Engineering Task Force (IETF) L. Iannone
Request for Comments: 9302 Huawei Technologies France
Obsoletes: 6834 D. Saucez
Category: Standards Track Inria
ISSN: 2070-1721 O. Bonaventure
Universite catholique de Louvain
October 2022
Locator/ID Separation Protocol (LISP) Map-Versioning
ロケーター/ID分離プロトコル（LISP）マップバージョン
Abstract
概要
This document describes the Locator/ID Separation Protocol (LISP) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. This approach is based on associating a version number to EID-to-RLOC mappings and transporting 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 optional and 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 or do not want to use the mechanism.
このドキュメントでは、LISPデータパケットのカプセル化に使用されるエンドポイント-IDからルーティングロケーター（EIDからRLOC）マッピングに関するインパケット情報を提供するロケーター/ID分離プロトコル（LISP）マップバージョンメカニズムについて説明します。このアプローチは、バージョン番号をEID-to-RLOCマッピングに関連付け、LISPにカプセル化されたパケットのLISP固有のヘッダーにそのようなバージョン番号を輸送することに基づいています。LISPマップバージョンは、パケットをカプセル化するために使用されるマッピングの変更について、イングレストンネルルーター（ITR）および出力トンネルルーター（ETR）の通信を通知するのに特に役立ちます。LISP固有のヘッダーおよびマップレコードでは、マップバージョンに使用されるビットは、サポートしていない、または使用したくないITRおよびETRによって安全に無視できるため、メカニズムはこの機能をサポートしていない実装に対してオプションで透明です。メカニズム。
This document obsoletes RFC 6834, which is the initial experimental specifications of the mechanisms updated by this document.
このドキュメントは、RFC 6834を廃止します。これは、このドキュメントによって更新されたメカニズムの初期実験仕様です。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9302.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9302で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Requirements Notation
3. Definitions of Terms
4. LISP-Specific Header and Map-Version Numbers
5. Map Record and Map-Version
6. EID-to-RLOC Map-Version Number
6.1. The Null Map-Version
7. Dealing with Map-Version Numbers
7.1. Handling Dest Map-Version Number
7.2. Handling Source Map-Version Number
8. Security Considerations
9. Deployment Considerations
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Benefits and Case Studies for Map-Versioning
A.1. Map-Versioning and Unidirectional Traffic
A.2. Map-Versioning and Interworking
A.2.1. Map-Versioning and Proxy-ITRs
A.2.2. Map-Versioning and LISP-NAT
A.2.3. Map-Versioning and Proxy-ETRs
A.3. RLOC Shutdown/Withdraw
Authors' Addresses
This document describes the Map-Versioning mechanism used to provide information on changes in the Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mappings used in the Locator/ID Separation Protocol (LISP) [RFC9300] [RFC9301] context to perform packet encapsulation. The mechanism is totally transparent to Ingress and Egress Tunnel Routers (xTRs) not supporting or not using such functionality. The architecture of LISP is described in [RFC9299]. The reader is expected to be familiar with this introductory document.
このドキュメントでは、ロケーター/ID分離プロトコル（LISP）[RFC9300] [RFC9301]で使用されるエンドポイント-IDからルーティングロケーター（EIDからRLOC）マッピングの変化に関する情報を提供するために使用されたマップバージョンメカニズムについて説明します。パケットカプセル化を実行するコンテキスト。このメカニズムは、そのような機能をサポートしていない、または使用しないトンネルルーター（XTR）に完全に透明です。LISPのアーキテクチャは[RFC9299]で説明されています。読者は、この入門書に精通していることが期待されています。
This document obsoletes [RFC6834], which is the initial experimental specification that describes the mechanisms updated by this document.
このドキュメントは、このドキュメントで更新されたメカニズムを記述する初期の実験仕様である廃止[RFC6834]です。
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 modification in the RLOCs set, such as addition of, removal of, or change in the priority or weight of one or more RLOCs.
基本的なメカニズムは、マップバージョン数を各LISP EID-to-RLOCマッピングに関連付け、LISP固有のヘッダーでそのようなバージョン番号を輸送することです。マッピングが変更されると、更新されたマッピングに新しいバージョン番号が割り当てられます。EIDからRLOCへのマッピングの変更は、1つ以上のRLOCの優先度または重量の追加、除去、または変更など、RLOCSセットの変更となる可能性があります。
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 RLOCs). This information has two uses:
マップバージョンを使用すると、LISPにカプセル化されたデータパケットには、外側ヘッダーのRLOC（つまり、ソースと宛先の両方のRLOCの両方）を選択するために使用される2つのマッピングのバージョン番号が含まれています。この情報には2つの用途があります。
1. Map-Versioning enables the Egress Tunnel Router (ETR) receiving the packet to know if the Ingress Tunnel Router (ITR) is using the latest mapping version for the destination EID. If this is not the case, the ETR can directly send a Map-Request containing the updated mapping to the ITR to notify it of the latest version. The ETR can also solicit the ITR to trigger a Map-Request to obtain the latest mapping by sending a Solicit Map-Request (SMR) message. Both options are defined in [RFC9301].
1. マップバージョンにより、パケットを受信する出力トンネルルーター（ETR）が、イングレストンネルルーター（ITR）が宛先EIDの最新マッピングバージョンを使用しているかどうかを知ることができます。そうでない場合、ETRは、更新されたマッピングを含むMap-RequestをITRに直接送信して、最新バージョンに通知することができます。また、ETRは、Solict Map-Request（SMR）メッセージを送信することにより、Map-Requestをトリガーして最新のマッピングを取得するようにITRを求めています。両方のオプションは[RFC9301]で定義されています。
2. Map-Versioning enables an ETR receiving the packet to know if it has in its EID-to-RLOC Map-Cache the latest mapping for the source EID. If this is not the case, a Map-Request can be sent.
2. マップバージョンにより、ETRがPacketを受信すると、Source Eidの最新マッピングがEid-to-Rlocマップキャッシュがあるかどうかを知ることができます。そうでない場合は、マップレクエストを送信できます。
Considerations about the deployment of LISP Map-Versioning are discussed in Section 9.
LISPマップバージョンの展開に関する考慮事項については、セクション9で説明します。
The benefits of Map-Versioning in some common LISP-related use cases are discussed in Appendix A.
いくつかの一般的なLISP関連のユースケースでのマップバージョンの利点については、付録Aで説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses terms already defined in the main LISP specifications ([RFC9300] and [RFC9301]). Here, we define the terms that are specific to the Map-Versioning mechanism. Throughout the whole document, big-endian bit ordering is used.
このドキュメントでは、メインのLISP仕様（[RFC9300]および[RFC9301]）で既に定義されている用語を使用します。ここでは、マップバージョンメカニズムに固有の用語を定義します。ドキュメント全体を通して、ビッグエンディアンビット注文が使用されます。
Map-Version number: An unsigned 12-bit integer is assigned to an EID-to-RLOC mapping, indicating its version number (Section 6).
マップバージョン番号：署名されていない12ビット整数は、バージョン番号（セクション6）を示すEid-to-Rlocマッピングに割り当てられます。
Null Map-Version: A Map-Version number with a value of 0x000 (zero), which is used to signal that the Map-Version feature is not used and no Map-Version number is assigned to the EID-to-RLOC mapping (Section 6.1).
Null Map-Version：値0x000（ゼロ）のマップバージョン数は、Map-version機能が使用されておらず、Map-version番号がEid-to-rlocマッピングに割り当てられていないことを示すために使用されます（セクション6.1）。
Dest Map-Version number: Map-Version of the mapping in the EID-to-RLOC Map-Cache used by the ITR to select the RLOC present in the 'Destination Routing Locator' field of the outer IP header of LISP-encapsulated packets (Section 7.1).
Dest Map-version Number：ITRが使用するEid-to-rlocマップキャッシュのマッピングのマップバージョンは、LISPにカプセル化されたパケットの外側IPヘッダーの「宛先ルーティングロケーター」フィールドに存在するRLOCを選択するために使用されます（セクション7.1）。
Source Map-Version number: Map-Version of the mapping in the EID-to-RLOC Database used by the ITR to select the RLOC present in the 'Source Routing Locator' field of the outer IP header of LISP-encapsulated packets (Section 7.2).
ソースマップバージョン番号：ITRが使用するEID-to-RLOCデータベースのマッピングのマップバージョンITRが使用して、LISPでカプセル化されたパケットの外側IPヘッダーの「ソースルーティングロケーター」フィールドに存在するRLOCを選択する（セクション7.2）。
In order for the versioning approach to work, the LISP-specific header has to carry both the Source Map-Version number and Dest Map-Version number. This is done by setting the V-bit in the LISP-specific header as specified in [RFC9300] and shown in the example in Figure 1. All permissible combinations of the flags when the V-bit is set to 1 are described in [RFC9300]. Not all of the LISP-encapsulated packets need to carry version numbers. When the V-bit is set, the LISP-specific header has the following encoding:
バージョン化アプローチが機能するため、LISP固有のヘッダーは、ソースマップバージョン番号とDest Map-version番号の両方を運ぶ必要があります。これは、[RFC9300]で指定され、図1の例に示されているLISP固有のヘッダーにVビットを設定することによって行われます。Vビットが1に設定されているときのフラグのすべての許容される組み合わせは[RFC9300で説明されています。]。すべてのLISPにカプセル化されたパケットがバージョン番号を掲載する必要があるわけではありません。Vビットが設定されると、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: LISP-Specific Header Example When Map-Versioning Is in Use
図1：マップバージョンが使用されている場合のLISP固有のヘッダーの例
Source Map-Version number (12 bits): See Section 3.
ソースマップバージョン番号（12ビット）：セクション3を参照してください。
Dest Map-Version number (12 bits): See Section 3.
Dest Map-version Number（12ビット）：セクション3を参照してください。
To accommodate the 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 reference, the Map Record (specified in [RFC9301]) is reported here as an example in Figure 2. This memo does not change the operation of Map-Request/Map-Reply/Map-Register messages; they continue to be used as specified in [RFC9301].
メカニズムに対応するために、マップリケスト/マップリプリー/マップレジスターメッセージで輸送されるマップレコードも、マップバージョン番号を掲載する必要があります。参照のために、MAPレコード（[RFC9301]で指定）を図2の例としてここで報告します。このメモは、Map-Request/Map-Reply/Map-Registerメッセージの操作を変更しません。それらは[RFC9301]で指定されているように引き続き使用されます。
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 |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Map-Record Format Example
図2：マップ録音形式の例
Map-Version Number: Map-Version of the mapping contained in the Record. As explained in Section 6.1, this field can be zero (0), meaning that no Map-Version is associated to the mapping.
マップバージョン番号：レコードに含まれるマッピングのマップバージョン。セクション6.1で説明したように、このフィールドはゼロ（0）になる可能性があります。つまり、マッピングに関連付けられているマップバージョンはありません。
This packet format is backward compatible with xTRs that do not support Map-Versioning, since they can simply ignore those bits.
このパケット形式は、マップバージョンをサポートしないXTRとの逆方向に互換性があります。なぜなら、それらは単にそれらのビットを無視できるからです。
A Map-Server receiving a message with an unexpected Map-Version number, for instance an old one, MUST silently drop the message and an appropriate log action SHOULD be taken.
予期しないマップバージョン番号、たとえば古いもののメッセージを受信するマップサーバーは、メッセージを静かにドロップする必要があり、適切なログアクションを実行する必要があります。
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 different version numbers, which are updated independently. An update in the version number (i.e., a newer version) MUST consist of an increment of the older version number (the only exception is for the Null Map-Version as explained in at the end of Section 6.1).
Eid-to-RLOCマップバージョン数は、署名されていない12ビット整数で構成されています。バージョン番号はマッピングごとに割り当てられます。つまり、マッピングが異なると、バージョン番号が異なり、独立して更新されます。バージョン番号（つまり、新しいバージョン）の更新は、古いバージョン番号の増分で構成されている必要があります（セクション6.1の最後で説明されているように、ヌルマップバージョンの唯一の例外です）。
The space of version numbers has a circular order where half of the version numbers are considered greater (i.e., newer) than the current Map-Version number and the other half of the version numbers are considered smaller (i.e., older) than the current Map-Version number. This is basically a serial number on which the arithmetic described in [RFC1982] applies. The ordering enables different reactions to "older" and "newer" Map-Version numbers, whereby "older" numbers are discarded and "newer" numbers trigger Map-Requests (see Section 7 for further details). In a formal way, assuming that we have two version numbers (V1 and V2), both different from the special value Null Map-Version (see Section 6.1), and that the numbers are expressed on 12 bits, the following steps MUST be performed (in the same order shown below) to strictly define their order:
バージョン番号のスペースには、バージョン番号の半分が現在のマップバージョン数よりも大きい（つまり、新しい）と見なされる循環順序があり、バージョン番号の残りの半分は現在のマップよりも小さい（つまり、古い）と見なされます。-バージョンナンバー。これは基本的に、[RFC1982]で説明されている算術が適用されるシリアル番号です。この順序は、「古い」および「新しい」マップバージョン番号に対する異なる反応を可能にし、「古い」数字が破棄され、「新しい」数字がマップリケストをトリガーします（詳細についてはセクション7を参照）。正式には、特別な値nullマップバージョンとは異なる2つのバージョン番号（V1とV2）があると仮定すると（セクション6.1を参照）、数字は12ビットで表されると、次の手順を実行する必要があります。（以下に示すのと同じ順序で）順序を厳密に定義します。
1. V1 = V2 : The Map-Version numbers are the same.
1. V1 = V2：マップバージョン数は同じです。
2. V2 > V1 : if and only if
2. v2> v1：場合のみ
V2 > V1 AND (V2 - V1) <= 2^(12-1)
OR
また
V1 > V2 AND (V1 - V2) > 2^(12-1)
3. V1 > V2 : otherwise.
3. V1> V2：それ以外の場合。
Using 12 bits 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 + 4095) mod 4096] are smaller than 69.
12ビットを使用し、69のマップバージョン値を想定して、範囲内のマップバージョン数[70;69 2048]は69を超えていますが、範囲内のマップバージョン数[69 2049;（69 4095）mod 4096]は69未満です。
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 6.1). Optionally, the initial Map-version number may be configured.
新しいEid-to-RLOCマッピングの初期マップバージョン数はランダムに割り当てる必要がありますが、ヌルマップバージョン数には特別な意味があるため、nullマップバージョン値（0x000）に設定しないでください（参照）セクション6.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-to-RLOCデータベースで構成されたマッピングを使用します。これらのマッピングにマップバージョン数がある場合、このドキュメントで説明されているメカニズムに従って使用されます。ETRは、EID-to-RLOCデータベースのマッピングにマップバージョン番号を自動的に生成および割り当ててはなりません。
The value 0x000 (zero) is a special Map-Version number indicating that there is actually no version number associated to the EID-to-RLOC mapping. Such a value is used for special purposes and is named the Null Map-Version number.
値0x000（ゼロ）は、実際にはEid-to-RLOCマッピングに関連付けられているバージョン番号がないことを示す特別なマップバージョン数です。このような値は、特別な目的で使用され、nullマップバージョン番号と呼ばれます。
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 NOT contain any Map-Version numbers (V-bit set to 0). If an ETR receives 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, then those packets MUST be silently dropped.
ヌルマップバージョン数を持つマップレコードは、マッピングに関連付けられたマップバージョン数がないことを示しています。これは、MAPレコードで言及されているEID-Prefixに導かれるLISPエンカプト化パケットを、マップバージョン番号（vビット設定0に設定）を含めてはならないことを意味します。ETRがVビットセットを使用してLISPカプセル化パケットを受信した場合、EID-to-RLOCデータベースの元のマッピングにバージョン番号がNULLマップバージョン値に設定されている場合、それらのパケットは静かにドロップする必要があります。
The Null Map-Version may appear in the LISP-specific header as a Source Map-Version number (Section 7.2). 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 Map-Cache, then the ETR MUST NOT compare the received Null Map-Version with the content of the EID-to-RLOC Map-Cache (Section 7.2).
ヌルマップバージョンは、LISP固有のヘッダーにソースマップバージョン数として表示される場合があります（セクション7.2）。ソースマップバージョン番号がNULLマップバージョン値に設定されている場合、ソースサイトにマップバージョン情報が伝えられないことを意味します。これは、Eid-to-RLOCマップキャッシュのソースEIDにマッピングが存在する場合、ETRは受信したヌルマップバージョンをEid-to-RLOCマップキャッシュの内容と比較してはならないことを意味します（セクション7.2 7.2）。
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 (0x001), which is the next valid value).
0値がマップバージョン数に特別な意味を持つという事実は、マッピングの変更のためにマップバージョン数を更新するとき、次の値が0の場合、マップバージョン数を増分する必要があることを意味します。2（つまり、1（0x001）に設定されていますが、これは次の有効な値です）。
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 no longer reachable from a local perspective (e.g., through IGP or policy changes), the LISP site updates the mapping and also assigns a new Map-Version number. Only the latest Map-Version number has to be considered valid. Mapping updates and their corresponding Map-Version Number must be managed so that a very old version number will not be confused as a new version number (because of the circular numbering space). To this end, simple measures can be taken, like updating a mapping only when all active traffic is using the latest version, or waiting a sufficient amount of time to be sure that the mapping in LISP caches expires, which means waiting at least as long as the mapping Time To Live (TTL) (as defined in [RFC9301]).
マップバージョン数を使用する主な考え方は、マッピングに変更がある場合（たとえば、RLOCの追加/削除、トラフィックエンジニアリングポリシーによる重みの変更、または優先順位の変更）またはLISPサイトが実現することです。 1つ以上の独自のRLOCがローカルの観点から（たとえば、IGPやポリシーの変更を介して）到達できなくなったこと、LISPサイトはマッピングを更新し、新しいマップバージョン番号を割り当てます。最新のマップバージョン番号のみを有効と見なす必要があります。マッピングの更新と、それに対応するマップバージョン番号を管理する必要があります。これにより、非常に古いバージョン番号が新しいバージョン番号として混乱しないようにします（円形の番号付けスペースのため）。この目的のために、すべてのアクティブトラフィックが最新バージョンを使用している場合にのみマッピングを更新するか、LISPキャッシュのマッピングが期限切れになることを確認するために十分な時間を待っているように、単純な測定値をとることができます。ライブ（TTL）のマッピング時間として（[RFC9301]で定義されています）。
An ETR receiving a LISP packet with Map-Version numbers checks the following predicates:
MAP-version NumbersでLISPパケットを受け取るETRが次の述語をチェックします。
1. The ITR that has sent the packet has an up-to-date mapping in its EID-to-RLOC Map-Cache for the destination EID and is performing encapsulation correctly. See Section 7.1 for details.
1. Packetを送信したITRは、宛先EIDのEIDからRLOCのマップキャッシュに最新のマッピングを備えており、カプセル化を正しく実行しています。詳細については、セクション7.1を参照してください。
2. In the case of bidirectional traffic, the mapping in the local ETR EID-to-RLOC Map-Cache for the source EID is up to date. See Section 7.2 for details.
2. 双方向トラフィックの場合、ソースEIDのローカルETR EIDからRLOCへのマップキャッシュのマッピングは最新です。詳細については、セクション7.2を参照してください。
When an ETR receives a packet, the Dest 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 Dest Map-Version number. A check on this version number MUST be done, where the following cases can arise:
ETRがパケットを受信すると、Dest Map-version番号は、ETRがRLOCである宛先EIDのマッピングに関連しています。このマッピングは、ETR EID-to-RLOCデータベースの一部です。ETRはマッピングに対して権威あるため、正しいデスティブマップバージョン数が正しいです。このバージョン番号のチェックは、次のケースが発生する可能性がある場合に行う必要があります。
1. The packet arrives with the same Dest 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 Map-Cache, an up-to-date mapping. No further actions are needed.
1. パケットは、Eid-to-RLOCデータベースに保存されている同じDest Map-version番号で到着します。これは通常のケースです。パケットを送信するITRには、EIDからRLOCへのマップキャッシュには、最新のマッピングがあります。それ以上のアクションは必要ありません。
2. The packet arrives with a Dest Map-Version number newer (as defined in Section 6) 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, the packet carries a version number that is not considered valid. Therefore, the packet MUST be silently dropped and an appropriate log action SHOULD be taken.
2. このパケットは、EID-to-RLOCデータベースに保存されているものよりも（セクション6で定義されているように）新しい（セクション6で定義されている）、Dest Map-version Numberを使用して到着します。ETRはマッピングで権威あるため、マッピングのマップバージョン数は正しいものであるため、パケットには有効とは見なされないバージョン番号が付いています。したがって、パケットを静かに削除する必要があり、適切なログアクションを実行する必要があります。
3. The packet arrives with a Dest Map-Version number older (as defined in Section 6) 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 Map-Cache containing stale information. The ETR MAY choose to normally process the encapsulated datagram according to [RFC9300]; however, the ITR sending the packet MUST be informed that a newer mapping is available, respecting rate-limitation policies described in [RFC9301]. This is done with a Map-Request message sent back to the ITR, as specified in [RFC9301]. One feature introduced by Map-Version numbers is the possibility of blocking traffic not using the latest mapping. This can happen if an ITR is not updating the mapping for which the ETR is authoritative, or it might be some form of attack. According to the rate-limitation policy defined in [RFC9301] for Map-Request messages, after 10 retries, Map-Requests are sent every 30 seconds; if after the first 10 retries the Dest Map-Version number in the packets is not updated, the ETR SHOULD drop packets with a stale Map-Version number. Operators can configure exceptions to this recommendation, which are outside the scope of this document.
3. このパケットは、EID-to-RLOCデータベースに保存されているものよりも古い（セクション6で定義されている）デスティマップバージョン数で到着します。これは、Packetを送信するITRに、古い情報を含むEid-to-RLOCマップキャッシュに古いマッピングがあることを意味します。 ETRは、[RFC9300]に従って、カプセル化されたデータグラムを通常処理することを選択できます。ただし、[RFC9301]に記載されているレート制限ポリシーを尊重して、パケットを送信するITRに新しいマッピングが利用可能であることを通知する必要があります。これは、[RFC9301]で指定されているように、ITRに送信されたマップレクエストメッセージで行われます。マップバージョン番号によって導入された機能の1つは、最新のマッピングを使用しないトラフィックをブロックする可能性です。これは、ITRがETRが権威あるマッピングを更新していない場合、または何らかの形の攻撃である場合に発生する可能性があります。 [RFC9301]でMAP-Requestメッセージについて定義されているレートリミテーションポリシーによれば、10回の再試行後、30秒ごとにMAP-Requestが送信されます。最初の10回の後にパケット内のDest Map-version番号が更新されない場合、ETRは古いマップバージョン数でパケットをドロップする必要があります。オペレーターは、このドキュメントの範囲外のこの推奨事項の例外を構成できます。
The rule in the third case MAY be more restrictive. If the Record TTL of the previous mapping has already expired, all packets arriving with an old Map-Version MUST 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 amount of time as the Record TTL of the older mapping, all the entries in the EID-to-RLOC Map-Caches of ITRs must have expired. Indeed, all ITRs sending traffic should have refreshed the mapping according to [RFC9301].
3番目のケースのルールはより制限的になる場合があります。以前のマッピングのレコードTTLがすでに期限切れになっている場合、古いマップバージョンで到着するすべてのパケットは、マップレクエストを発行せずにすぐに静かにドロップする必要があります。このようなアクションは、更新されたバージョン番号を使用した新しいマッピングが、古いマッピングのレコードTTLと少なくとも同じ時間の間変更されていない場合、IID-to-RLOCマップキャッシュのすべてのエントリがITRSのすべてのエントリであるためです。有効期限が切れている必要があります。実際、トラフィックを送信するすべてのITRは、[RFC9301]に従ってマッピングを更新する必要があります。
It is a protocol violation for LISP-encapsulated packets to contain a Dest Map-Version number equal to the Null Map-Version number (see Section 6.1).
これは、LISPにカプセル化されたパケットがNULLマップバージョン数に等しいデスティマップバージョン数を含むためのプロトコル違反です（セクション6.1を参照）。
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 Map-Cache for the source EID, then a check MUST be performed, and the following cases can arise:
ETRがパケットを受信すると、ソースマップバージョン数は、パケットを送信したITRが権威あるソースEIDのマッピングに関連しています。ETRがソースEIDのEid-to-RLOCマップキャッシュにエントリを持っている場合、チェックを実行する必要があり、次のケースが発生する可能性があります。
1. The packet arrives with the same Source Map-Version number as that stored in the EID-to-RLOC Map-Cache. This is the regular case. The ETR has in its EID-to-RLOC Map-Cache an up-to-date copy of the mapping. No further actions are needed.
1. パケットは、Eid-to-Rlocマップキャッシュに保存されているものと同じソースマップバージョン数で到着します。これは通常のケースです。ETRには、EIDからRLOCへのマップキャッシュには、マッピングの最新のコピーがあります。それ以上のアクションは必要ありません。
2. The packet arrives with a Source Map-Version number newer (as defined in Section 6) than the one stored in the local EID-to-RLOC Map-Cache. This means that the ETR has in its EID-to-RLOC Map-Cache a mapping that is stale and needs to be updated. A Map-Request MUST be sent to get the new mapping for the source EID, respecting rate-limitation policies described in [RFC9301].
2. このパケットは、ローカルEIDからRLOCへのマップキャッシュに保存されているものよりも（セクション6で定義されている）ソースマップバージョン数（セクション6で定義されている）で到着します。これは、ETRがEid-to-RLOCマップキャッシュに、古くて更新する必要があるマッピングを持っていることを意味します。[RFC9301]に記載されているレート制限ポリシーを尊重して、ソースEIDの新しいマッピングを取得するには、MAP-Requestを送信する必要があります。
3. The packet arrives with a Source Map-Version number older (as defined in Section 6) than the one stored in the local EID-to-RLOC Map-Cache. Note that if the mapping is already present in the EID-to-RLOC Map-Cache, this means that an explicit Map-Request has been sent and a Map-Reply has been received from an authoritative source. In this situation, the packet SHOULD be silently dropped. Operators can configure exceptions to this recommendation, which are outside the scope of this document.
3. このパケットは、ローカルEIDからRLOCのマップキャッシュに保存されているものよりも古いソースマップバージョン数（セクション6で定義されている）で到着します。MappingがEid-to-RLOCマップキャッシュにすでに存在している場合、これは明示的なMap-Requestが送信され、MAP Replyが権威あるソースから受信されたことを意味することに注意してください。この状況では、パケットを静かにドロップする必要があります。オペレーターは、このドキュメントの範囲外のこの推奨事項の例外を構成できます。
If the ETR does not have an entry in the EID-to-RLOC Map-Cache for the source EID, then the Source Map-Version number MUST be ignored. See Appendix A.1 for an example of when this situation can arise.
ETRがソースEIDのEIDからRLOCへのマップキャッシュにエントリがない場合、ソースマップバージョン数は無視する必要があります。この状況がいつ発生するかの例については、付録A.1を参照してください。
This document builds on the specification and operation of the LISP control and data planes. The Security Considerations of [RFC9300] and [RFC9301] apply. As such, Map-Versioning MUST NOT be used over the public Internet and MUST only be used in trusted and closed deployments. A thorough security analysis of LISP is documented in [RFC7835].
このドキュメントは、LISP制御およびデータプレーンの仕様と動作に基づいています。[RFC9300]および[RFC9301]のセキュリティ上の考慮事項が適用されます。そのため、マップバージョンはパブリックインターネットを介して使用する必要はなく、信頼できる展開および閉鎖展開でのみ使用する必要があります。LISPの徹底的なセキュリティ分析は、[RFC7835]に記録されています。
Attackers can try to trigger a large number of Map-Requests by simply forging packets with random Map-Versions. The Map-Requests are rate limited as described in [RFC9301]. With Map-Versioning, it is possible to filter packets carrying invalid version numbers before triggering a Map-Request, thus helping to reduce the effects of DoS attacks. However, it might not be enough to really protect against a DDoS attack.
攻撃者は、ランダムなマップバージョンを使用してパケットを鍛造するだけで、多数のマップ再クエストをトリガーしようとすることができます。[RFC9301]に記載されているように、マップの要求はレート制限されています。マップバージョンを使用すると、マップリケストをトリガーする前に無効なバージョン番号を持つパケットをフィルタリングすることができ、DOS攻撃の影響を減らすことができます。ただし、DDOS攻撃から実際に保護するだけでは不十分な場合があります。
The present memo includes log action to be taken upon certain events. It is recommended that implementations include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks.
現在のメモには、特定のイベントで実行されるログアクションが含まれています。ログリソースの枯渇攻撃を避けるために、実装にはメカニズム（このドキュメントの範囲を超えています）を含めることをお勧めします。
The specifications in the present memo are relatively conservative in the sense that, in several cases, the packets are dropped. Such an approach is the outcome of considerations made about the possible risks that control plane actions that are triggered by the data plane can be used to carry out attacks. There exists corner cases where, even with an invalid Map-Version number, forwarding the packet might be potentially considered safe; however, system manageability has been given priority with respect to having to put in place more machinery to be able to identify legitimate traffic.
現在のメモの仕様は、いくつかの場合にパケットが削除されるという意味で比較的保守的です。このようなアプローチは、データプレーンによってトリガーされる平面アクションを制御する可能性のあるリスクについて行われた考慮事項の結果を使用して攻撃を実行できます。マップバージョン数が無効であっても、パケットを転送することが安全であると見なされる可能性があるコーナーケースが存在します。ただし、正当なトラフィックを特定できるように、より多くの機械を設置しなければならないことに関して、システムの管理が優先されています。
LISP requires multiple ETRs within the same site to provide identical mappings for a given EID-Prefix. Map-Versioning does not require additional synchronization mechanisms. Clearly, all the ETRs have to reply with the same mapping, including the same Map-Version number; otherwise, there can be an inconsistency that creates additional control traffic, instabilities, and traffic disruptions.
LISPは、特定のEID-Prefixの同一のマッピングを提供するために、同じサイト内の複数のETRを必要とします。マップバージョンでは、追加の同期メカニズムは必要ありません。明らかに、すべてのETRは、同じマップバージョン数を含む同じマッピングで返信する必要があります。それ以外の場合、追加の制御トラフィック、不安定性、トラフィックの混乱を作成する矛盾があります。
There are two ways Map-Versioning is helpful with respect to synchronization. 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.
同期に関してマップバージョンが役立つ2つの方法があります。一方では、マッピングにバージョン番号を割り当てるのに役立ちます。なぜなら、マップバージョン数を見ると、異なるETRのマッピングの一貫性の迅速なチェックを実行できるからです。一方、マップバージョンを使用して、最新のマッピングを発表するETRへのトラフィックを制御できます。
As an example, let's consider the topology of Figure 3 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に単方向トラフィックを送信している図3のトポロジーを考えてみましょう。ドメインAのA.2はドメインBとの交換双方向トラフィックを交換します。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 3: Example Topology
図3：トポロジの例
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.
明らかに、マップバージョンの場合、ドメインAのITR A.1とITR A.2の両方が同じ値を使用する必要があります。それ以外の場合、ドメインBのETRはMap-Requestsの送信を開始します。
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 does not verify reachability or if ETR B will start sending Map-Requests to confirm each change in reachability.
ただし、ドメインの2つのITRが異なるロケーターステータスビットを送信する場合、同じ問題はマップバージョンなしで発生する可能性があります。この場合、ETR Bが到達可能性を検証しない場合、またはETR Bが各変更性の各変化を確認するためにMAP-Requestsの送信を開始する場合、トラフィックが破壊されます。
So far, LISP does not provide any specific synchronization mechanism but assumes that synchronization is provided by configuring the different xTRs consistently. 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 Map Record format, as described in Section 5.
これまでのところ、LISPは特定の同期メカニズムを提供していませんが、異なるXTRを一貫して構成することにより同期が提供されると仮定しています。同じことがマップバージョンにも当てはまります。将来的に同期メカニズムが提供されている場合、セクション5で説明されているように、マップレコード形式に含まれているため、マップバージョンは自動的に活用されます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., "The Locator/ID Separation Protocol (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022, <https://www.rfc-editor.org/info/rfc9300>.
[RFC9300] Farinacci、D.、Fuller、V.、Meyer、D.、Lewis、D.、およびA. Cabellos、ed。、「ロケーター/ID分離プロトコル（LISP）」、RFC 9300、DOI 10.17487/RFC9300、2022年10月、<https://www.rfc-editor.org/info/rfc9300>。
[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., "Locator/ID Separation Protocol (LISP) Control Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022, <https://www.rfc-editor.org/info/rfc9301>.
[RFC9301] Farinacci、D.、Maino、F.、Fuller、V。、およびA. Cabellos、ed。、「Locator/ID分離プロトコル（LISP）コントロールプレーン」、RFC 9301、DOI 10.17487/RFC9301、10月2022年、<https://www.rfc-editor.org/info/rfc9301>。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>.
[RFC1982] Elz、R。およびR. Bush、「シリアル番号算術」、RFC 1982、DOI 10.17487/RFC1982、1996年8月、<https://www.rfc-editor.org/info/rfc1982>。
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, January 2013, <https://www.rfc-editor.org/info/rfc6832>.
[RFC6832] Lewis、D.、Meyer、D.、Farinacci、D.、およびV. Fuller、「ロケーター/ID分離プロトコル（LISP）と非リスプサイト間のインターワーキング」、RFC 6832、DOI 10.17487/RFC6832、1月2013、<https://www.rfc-editor.org/info/rfc6832>。
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, DOI 10.17487/RFC6834, January 2013, <https://www.rfc-editor.org/info/rfc6834>.
[RFC6834] Iannone、L.、Sauce、D。、およびO. Bonaventure、「ロケーター/ID分離プロトコル（LISP）マップバージョン」、RFC 6834、DOI 10.17487/RFC6834、2013年1月、<https：// www。rfc-editor.org/info/rfc6834>。
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, <https://www.rfc-editor.org/info/rfc7835>.
[RFC7835] Saucez、D.、Iannone、L。、およびO. Bonaventure、「ロケーター/ID分離プロトコル（LISP）脅威分析」、RFC 7835、DOI 10.17487/RFC7835、2016年4月、<https：//ww.rfc-editor.org/info/rfc7835>。
[RFC9299] Cabellos, A. and D. Saucez, Ed., "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", RFC 9299, DOI 10.17487/RFC9299, October 2022, <https://www.rfc-editor.org/info/rfc9299>.
[RFC9299] Cabellos、A。and D. Sauce、ed。、「ロケーター/ID分離プロトコル（LISP）の建築紹介」、RFC 9299、DOI 10.17487/RFC9299、2022年10月、<https：//ww.rfc-editor.org/info/rfc9299>。
In the following sections, we provide more discussion on various aspects and uses of Map-Versioning. Security observations are grouped in Section 8.
以下のセクションでは、地図バージョンのさまざまな側面と使用についてさらに議論します。セキュリティ観測はセクション8にグループ化されています。
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 4, since the LISP specifications do not mandate that the ETR have a mapping from the source EID.
マップバージョンを使用する場合、LISP固有のヘッダーは、ソースマッピングと宛先マッピングの両方に2つのマップバージョン番号を搭載します。これにより、LISP仕様はETRがソースEIDからマッピングを持っていることを義務付けていないため、図4に示されている場合、単方向の流れの場合に何が起こるかについて疑問を提起できます。
+-----------------+ +-----------------+
| Domain A | | Domain B |
| +---------+ +---------+ |
| | ITR A |----------->| ETR B | |
| +---------+ +---------+ |
| | | |
+-----------------+ +-----------------+
Figure 4: Unidirectional Traffic between LISP Domains
図4：LISPドメイン間の単方向トラフィック
An ITR is able to put both the source and destination version numbers in the LISP-specific header since the Source Map-Version number is in its database, while the Dest Map-Version number is in its cache.
ITRは、ソースマップバージョン数がデータベース内にあるため、Sourceと宛先のバージョン番号の両方をLISP固有のヘッダーに配置できます。
The ETR checks only the Dest Map-Version number, ignoring the Source Map-Version number as specified in the final sentence of Section 7.2.
ETRは、セクション7.2の最終文で指定されているソースマップバージョン数を無視して、Dest Map-version番号のみをチェックします。
Map-Versioning is compatible with the LISP interworking between LISP and non-LISP sites as defined in [RFC6832]. LISP interworking defines three techniques to allow communication 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.
マップバージョンは、[RFC6832]で定義されているように、LISP部位と非LISPサイト間のLISPインターワーキングと互換性があります。LISP Interworkingは、通信LISPサイトと非リスプサイト、つまりProxy-ITR、LISP-NAT、およびProxy-Ertを許可する3つの手法を定義します。次のテキストは、マップバージョンがこれらの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 5). This case is very similar to the unidirectional traffic case described in Appendix A.1; hence, similar rules apply.
プロキシ-ITR（PITR）の目的は、LISPサイトのETRの1つにパケットを配信するために、非リスプサイトに発信されるトラフィックをカプセル化することです（図5を参照）。このケースは、付録A.1に記載されている単方向の交通事例と非常によく似ています。したがって、同様のルールが適用されます。
+----------+ +-------------+
| LISP | | non-LISP |
| Domain A | | Domain B |
| +-------+ +-----------+ | |
| | ETR A |<-------| Proxy-ITR |<-------| |
| +-------+ +-----------+ | |
| | | |
+----------+ +-------------+
Figure 5: Unidirectional Traffic from Non-LISP Domain to LISP Domain
図5：非リスプドメインから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.
主な違いは、プロキシ-ITRにはマッピングがないことです。これは、非リスプサイトから到着するパケットをカプセル化するだけで、ソースマップバージョンを提供できないためです。この場合、プロキシ-ITRは、NULLマップバージョン値をソースマップバージョン数として配置するだけで、受信ETRはフィールドを無視します。
With this setup, LISP Domain A is able to check whether the PITR is using the latest mapping. In the Dest Map-Version Number of the LISP-specific header, the Proxy-ITR will put the version number of the mapping it is using for encapsulation; the ETR A can use such value as defined in Section 7.1.
このセットアップにより、LISPドメインAは、PITRが最新のマッピングを使用しているかどうかを確認できます。LISP固有のヘッダーのDESTマップバージョン番号では、プロキシ-ITRは、カプセル化に使用しているマッピングのバージョン番号を配置します。ETR Aは、セクション7.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からルーティング可能なEidsへの住所変換に基づいており、いかなる形態のカプセル化も含まれません。そのため、この場合、マップバージョンは適用されません。
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 6). One of the main reasons to deploy PETRs is to bypass Unicast Reverse Path Forwarding checks on the domain.
Proxy-ERT（PETR）の目的は、Packetを非LISPサイトに配信するために、LISPサイトに由来するトラフィックを脱カプセル化することです（図6を参照）。PETRSを展開する主な理由の1つは、ドメインのユニキャストリバースパス転送チェックをバイパスすることです。
+----------+ +-------------+
| LISP | | non-LISP |
| Domain A | | Domain B |
| +-------+ +-----------+ | |
| | ITR A |------->| Proxy-ETR |------->| |
| +-------+ +-----------+ | |
| | | |
+----------+ +-------------+
Figure 6: Unidirectional Traffic from LISP Domain to Non-LISP Domain
図6：LISPドメインから非リスプドメインへの単方向トラフィック
A Proxy-ETR does not have any mapping, since it just decapsulates packets arriving from the LISP site. In this case, the ITR can interchangeably put a Map-Version value or the Null Map-Version value as the Dest Map-Version number, since the receiving Proxy-ETR will ignore the field.
Proxy-ERTには、LISPサイトから到着するパケットを脱カプセル化するだけなので、マッピングはありません。この場合、ITRは、受信プロキシ-Ertがフィールドを無視するため、Map-version値またはNull Map-version値をDest Map-version数として互換的に配置できます。
With this setup, the Proxy-ETR, by looking at the Source Map-Version Number, is able to check whether the mapping of the source EID has changed. This is useful to perform source RLOC validation. In the example above, traffic coming from the LISP domain has to be LISP encapsulated with a source address being an RLOC of the domain. The Proxy-ETR can retrieve the mapping associated to the LISP domain and check if incoming LISP-encapsulated traffic is arriving from a valid RLOC. A change in the RLOC-Set that can be used as source addresses can be signaled via the version number, with the Proxy-ETR able to request the latest mapping if necessary as described in Section 7.2.
このセットアップにより、Proxy-ERTは、ソースマップバージョン番号を調べることにより、ソースEIDのマッピングが変更されたかどうかを確認できます。これは、ソースRLOC検証を実行するのに役立ちます。上記の例では、LISPドメインからのトラフィックは、ドメインのRLOCであるソースアドレスでLISPをカプセル化する必要があります。Proxy-ERTは、LISPドメインに関連付けられたマッピングを取得し、有効なRLOCから着信するLISPカプセル化トラフィックが到着しているかどうかを確認できます。ソースアドレスとして使用できるRLOC-SETの変更は、バージョン番号を介して信号を送信できます。プロキシ-Ertは、セクション7.2で説明されているように、必要に応じて最新のマッピングを要求できます。
Map-Versioning can also be used to perform a graceful shutdown or to withdraw 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 [RFC9301]) but without actually turning it off.
マップバージョンを使用して、優雅なシャットダウンを実行したり、特定のRLOCを引き出したりすることもできます。これは、新しいマッピングを発行するだけで達成されます。特定のRLOCが撤回または到達不可として撤回または発表される更新されたマップバージョン番号を使用して（マップレコードのRビットを介して、[RFC9301]を参照）オフにします。
Upon updating the mapping, the RLOC will receive less and less traffic because remote LISP sites will request the updated mapping and see that it is disabled. At least one TTL, plus a little time for traffic transit, after the mapping is updated, it should be safe to shut down the RLOC gracefully, because all sites actively using the mapping should have been updated.
マッピングを更新すると、RLOCは、リモートLISPサイトが更新されたマッピングを要求し、無効になっていることを確認するため、トラフィックの受信をますます少なくします。少なくとも1つのTTLと、マッピングが更新された後、トラフィックトランジットの少しの時間に加えて、マッピングを積極的に使用するすべてのサイトが更新されるはずであるため、RLOCを優雅にシャットダウンすることが安全である必要があります。
Note that a change in ETR for a flow can result in the reordering of the packet in the flow just as any other routing change could cause reordering.
フローのETRの変更により、他のルーティングの変更が並べ替えを引き起こす可能性があるように、フロー内のパケットが並べ替える可能性があることに注意してください。
Authors' Addresses
著者のアドレス
Luigi Iannone Huawei Technologies France Email: luigi.iannone@huawei.com
Luigi Iannone Huawei Technologies France Email：luigi.iannone@huawei.com
Damien Saucez Inria 2004 route des Lucioles - BP 93 Sophia Antipolis France Email: damien.saucez@inria.fr
Damien Saucez Inria 2004 Route Des Lucioles -BP 93 Sophia Antipolis France Email：damien.saucez@inria.fr
Olivier Bonaventure Universite catholique de Louvain Email: olivier.bonaventure@uclouvain.be
Olivier Bonaventure Universite Catholique de Louvainメール：olivier.bonaventure@uclouvain.be