[要約] RFC 10040は、Locator/ID Separation Protocol（LISP）において地理座標（緯度・経度・高度）を扱うための仕様と、新しいLISP標準アドレス形式（LCAF）エンコーディングを定義する実験的文書です。エンドポイントID（EID）やルーティングロケータ（RLOC）に地理位置情報を関連付けることで、近接性に基づく最適なパス選択や位置ベースのルーティングポリシー適用を実現します。LISPにおける位置情報の表現形式を標準化し、RFC 8060（LISP LCAF）を更新します。
Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 10040 lispers.net
Updates: 8060 September 2026
Category: Experimental
ISSN: 2070-1721
This document describes how Geo-Coordinates can be used in the Locator/ID Separation Protocol (LISP) and defines a new LISP Canonical Address Format (LCAF) encoding for such Geo-Coordinates.
この文書では、地理座標を Locator/ID Separation Protocol (LISP) で使用する方法について説明し、そのような地理座標用の新しい LISP Canonical Address Format (LCAF) エンコーディングを定義します。
This document updates RFC 8060.
この文書は RFC 8060 を更新します。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネット コミュニティ向けの実験プロトコルを定義します。このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。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/rfc10040.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10040 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Requirements Language
3. Definition of Terms
4. Geo-Points in RLOC-Records
5. Geo-Prefixes in EID-Records and RLOC-Records
6. Geo-Points and Geo-Prefixes Examples
6.1. Locating a Package
6.2. Wireless Connectivity
6.3. Vehicular Networks
7. Geo-Prefix and Geo-Point Encodings
8. Backward-Compatibility Considerations
9. Security Considerations
10. Privacy Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Acknowledgments
Author's Address
The Locator/ID Separation Protocol (LISP) [RFC9300] introduces two new namespaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs), which are intended to separate the semantics of identity and topological location from an IP address. To provide flexibility for current and future applications, these values can be encoded in LISP control messages using a general syntax that includes Address Family Identifiers (AFIs) [AFN].
Locator/ID Separation Protocol (LISP) [RFC9300] では、エンドポイント識別子 (EID) とルーティング ロケーター (RLOC) という 2 つの新しい名前空間が導入されています。これらは、ID とトポロジ上の位置のセマンティクスを IP アドレスから分離することを目的としています。現在および将来のアプリケーションに柔軟性を提供するために、これらの値は、アドレス ファミリ識別子 (AFI) [AFN] を含む一般的な構文を使用して LISP 制御メッセージ内にエンコードできます。
This document defines a new LCAF encoding for Geo-Coordinates, which deviates from the structure defined in [RFC9179], because a more compact encoding was desired.
この文書は地理座標の新しい LCAF エンコーディングを定義しますが、よりコンパクトなエンコーディングが望まれていたため、[RFC9179] で定義された構造から逸脱しています。
This document updates [RFC8060]. In particular, the use of the Geo-Coordinates encoding defined in Section 4.3 of [RFC8060] and identified by LCAF type 5 is deprecated. The LCAF type defined in this document is called "Geo-Location", and a new LCAF type has been allocated.
この文書は [RFC8060] を更新します。特に、[RFC8060] のセクション 4.3 で定義され、LCAF タイプ 5 で識別される地理座標エンコーディングの使用は非推奨です。この文書で定義されている LCAF タイプは「Geo-Location」と呼ばれ、新しい LCAF タイプが割り当てられています。
The Geo-Location LCAF type is used in EID-Records and RLOC-Records. See [RFC9301] for which LISP messages contain EID-Records and RLOC-Records.
Geo-Location LCAF タイプは、EID レコードと RLOC レコードで使用されます。LISP メッセージに EID レコードと RLOC レコードが含まれるかについては、[RFC9301] を参照してください。
This document is part of a development effort to include Geo-Coordinates in LISP. It is not part of an "experiment", as not all Experimental RFCs are necessarily part of an experiment. It is about the maturity level of the technology.
このドキュメントは、LISP に地理座標を組み込むための開発作業の一部です。すべての実験 RFC が必ずしも実験の一部であるとは限らないため、これは「実験」の一部ではありません。それはテクノロジーの成熟度に関係します。
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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Refer to [RFC9300] for authoritative definitions for the basic terms "EID", "RLOC", and "xTR". The terms defined in this section add to the canonical definitions to reflect the design considerations in this specification.
基本用語「EID」、「RLOC」、および「xTR」の信頼できる定義については、[RFC9300] を参照してください。このセクションで定義されている用語は、この仕様の設計上の考慮事項を反映するために標準的な定義に追加されています。
Geo-Point:
ジオポイント:
A coordinate according to [GEO] that defines a point using the latitude, longitude, and altitude parameters.
緯度、経度、高度のパラメーターを使用して点を定義する、[GEO] に従った座標。
Geo-Prefix:
地域プレフィックス:
Forms a sphere (in three dimensions) of a geographic area made up of a Geo-Point and a radius. A Geo-Point is known to be "more specific" than a Geo-Prefix when its physical location is within the geographic sphere.
Geo-Point と半径で構成される地理領域の球 (3 次元) を形成します。Geo-Point は、物理的な位置が地理範囲内にある場合、Geo-Prefix よりも「より具体的」であることが知られています。
Geo-Points MAY be present in an RLOC-Record to determine the physical location of an Egress Tunnel Router (ETR) or Re-encapsulating Tunneling Router (RTR). This can aid in determining geographical distance when topological distance is inaccurate or hidden. When Geo-Points are encoded in RLOC-Records with RLOC addresses, the LCAF AFI-List Type SHOULD be used.
地理的ポイントは、出口トンネル ルーター (ETR) または再カプセル化トンネリング ルーター (RTR) の物理的な位置を決定するために、RLOC レコードに存在してもよい(MAY)。これは、トポロジー的距離が不正確または隠されている場合に、地理的距離を決定するのに役立ちます。Geo-Point が RLOC アドレスを持つ RLOC-Records にエンコードされている場合、LCAF AFI-List Type を使用する必要があります (SHOULD)。
Geo-Points MAY be used as the sole piece of information in an RLOC-Record when an EID maps to a Geo-Coordinate. If it is desirable to find the geographical location of any EID, this method can be convenient. For instance, let's say that an EID is assigned to a physical shipping package by a package delivery company and the EID is encoded as an IPv6 address where the tracking number is embedded in an IPv6 EID. The network has LISP nodes deployed in many locations that are configured with their respective Geo-Coordinates. As the package roams, the LISP node that discovers the EID registers it to the LISP Mapping Database System. The EID-to-RLOC mapping is EID=IPv6 and RLOC=geo-point. If someone does a Mapping Database System lookup on the IPv6 EID, the Geo-Coordinate is returned. As the EID roams, new registrations with different Geo-Coordinates are stored, allowing the physical tracking of the package.
EID が地理座標にマッピングされる場合、地理ポイントは RLOC レコード内の唯一の情報として使用されてもよい (MAY)。EID の地理的位置を見つけたい場合は、この方法が便利です。たとえば、EID が荷物配達会社によって物理的な発送荷物に割り当てられ、EID が IPv6 アドレスとしてエンコードされ、追跡番号が IPv6 EID に埋め込まれているとします。ネットワークには、それぞれの地理座標で構成された LISP ノードが多くの場所に展開されています。パッケージが移動すると、EID を検出した LISP ノードは、EID を LISP マッピング データベース システムに登録します。EID から RLOC へのマッピングは、EID=IPv6 および RLOC=geo-point です。誰かが IPv6 EID に対してマッピング データベース システム ルックアップを実行すると、地理座標が返されます。EID が移動すると、異なる地理座標を持つ新しい登録が保存され、荷物の物理的な追跡が可能になります。
A Geo-Prefix is defined to be a Geo-Point and a radius. This allows a sphere to be drawn on a geographic map. The Geo-Prefix can describe a coarse physical location for an RLOC when encoded in an RLOC-Record. So, an RLOC could be registered in the Mapping Database System, indicating it is in a city or country versus the exact location where a Geo-Point would locate it. For instance, a Geo-Prefix could allow a Distinguished Name [RFC9735] to be registered as an EID with an RLOC that contains a Geo-Prefix. For example, EID="San Francisco", with RLOC=geo-prefix could be stored in the Mapping Database System.
地理プレフィックスは、地理点と半径として定義されます。これにより、地理地図上に球を描画できるようになります。Geo-Prefix は、RLOC-Record にエンコードされるときに、RLOC の大まかな物理的位置を記述することができます。したがって、RLOC をマッピング データベース システムに登録し、それが都市または国にあることと、ジオポイントが位置を特定する正確な位置を示すことができます。たとえば、地域プレフィックスを使用すると、識別名 [RFC9735] を地域プレフィックスを含む RLOC に EID として登録できるようになります。たとえば、EID="San Francisco" を RLOC=geo-prefix とともにマッピング データベース システムに保存できます。
A Geo-Prefix, when encoded in an EID-Record, could be registered as an EID-Prefix, and when a Geo-Point is used as an EID lookup key, a sort of longest match could be looked up. If the Geo-Point is in the sphere described by the Geo-Prefix, the matching entry MUST be returned to the Map-Requester. In this context, what is returned is the Geo-Prefix with the largest radius value, which corresponds to the largest physical area. If the Geo-Point supplied in a Map-Request matches several Geo-Prefixes in the Mapping Database System, then all Geo-Prefixes MUST be returned. This uses the same overlapping lookup semantics defined in [RFC9301] for IP address EIDs.
地域プレフィックスは、EID レコード内でエンコードされている場合、EID プレフィックスとして登録でき、地域ポイントが EID ルックアップ キーとして使用される場合、一種の最長一致を検索できます。Geo-Point が Geo-Prefix によって記述された球内にある場合、一致するエントリを Map-Requester に返さなければなりません (MUST)。このコンテキストでは、最大の物理エリアに対応する、最大の半径値を持つ地理プレフィックスが返されます。Map-Request で提供された Geo-Point がマッピング データベース システム内の複数の Geo-Prefix と一致する場合、すべての Geo-Prefix を返さなければなりません (MUST)。これは、IP アドレス EID に対して [RFC9301] で定義されているのと同じ重複検索セマンティクスを使用します。
You could take a combination of mappings from the above examples to ask the question: "Is the package in San Francisco?" This could be done with two lookups to the Mapping Database System:
上記の例のマッピングを組み合わせて、「パッケージはサンフランシスコにありますか?」という質問をすることができます。これは、マッピング データベース システムへの 2 つのルックアップで実行できます。
Contents of Mapping Database System:
EID=<dist-name="san francisco">
RLOC=<geo-prefix-of-60-mile-radius-of-sf>
EID=<ipv6-package-tracking-number>
RLOC=<geo-point-of-current-location>
EID=<geo-prefix-of-60-mile-radius-of-sf>
RLOC=<dist-name="san francisco">
Map-Request for package:
EID=<ipv6-package-tracking-number>
Mapping Database System returns:
RLOC=<geo-point-of-current-location>
Map-Request for Geo-Point:
EID=<geo-point-of-current-location>
Mapping Database System longest-match lookup returns:
EID=<geo-prefix-of-60-mile-radius-of-sf>
RLOC=<dist-name="san francisco">
If the package is not in San Francisco, the second mapping table lookup would fail.
パッケージがサンフランシスコにない場合、2 回目のマッピング テーブルの検索は失敗します。
Another application is concentric rings of Wi-Fi access points (APs). The radius of each ring corresponds to the Wi-Fi signal strength. An EID could be located in any of the inner rings and possibly on the edge of a ring. A Wi-Fi AP RLOC can be selected to encapsulate packets because it will have a better signal to the current EID location. In addition, when there are intersecting spheres, a good time to transition radios to closer Wi-Fi APs or 3GPP Radio Access Network (RAN) base stations is when the EID is in the intersection of the spheres.
別のアプリケーションは、Wi-Fi アクセス ポイント (AP) の同心リングです。各リングの半径は Wi-Fi 信号強度に対応します。EID は、内側のリングのいずれか、場合によってはリングの端に配置される可能性があります。Wi-Fi AP RLOC は、現在の EID 位置への信号が良好になるため、パケットをカプセル化するために選択できます。さらに、交差する球がある場合、EID が球の交差部分にあるときが、無線をより近い Wi-Fi AP または 3GPP 無線アクセス ネットワーク (RAN) 基地局に移行するのに適したタイミングです。
When assigning EIDs to vehicles [V2I-PROB], a Geo-Prefix could be used to create a "reachability set" of Roadside Units (RSUs). So an Ingress Tunnel Router (ITR) could encapsulate to multiple RLOCs in the Geo-Prefix to try to create connectivity to the vehicle while roaming. This makes use of predictive RLOCs [PRED-RLOCS] that can be used when the direction of the roaming EID is known (a train track or single direction road, but not a flight path of a plane).
EID を車両に割り当てる場合 [V2I-PROB]、Geo-Prefix を使用して路側機 (RSU) の「到達可能性セット」を作成できます。したがって、イングレス トンネル ルーター (ITR) は、地域プレフィックス内の複数の RLOC にカプセル化して、ローミング中に車両への接続を確立しようとする可能性があります。これは、ローミング EID の方向がわかっている場合に使用できる予測 RLOC [PRED-RLOCS] を利用します (飛行機の飛行経路ではなく、電車の線路または一方向の道路)。
When a Geo-Prefix or a Geo-Point is encoded in an EID-Record, it is encoded solely with the Geo-Location LCAF Type format when VPNs are not in use. When VPNs are used, the Geo-Location LCAF Type is encoded in the 'AFI' field of the Instance-ID LCAF Type.
地理プレフィックスまたは地理ポイントが EID レコードでエンコードされる場合、VPN が使用されていないときは、地理位置 LCAF タイプ形式のみでエンコードされます。VPN が使用される場合、地理位置情報 LCAF タイプは、インスタンス ID LCAF タイプの「AFI」フィールドでエンコードされます。
This document has no provision to validate the Geo-Location values.
この文書には、地理的位置の値を検証するための規定はありません。
The Geo-Location format is:
地理的位置の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 17 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|N|E|A|M|R|K| Reserved | Location Uncertainty |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lat Degrees | Latitude Milliseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Long Degrees | Longitude Milliseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Altitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radius | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Geo-Location LCAF Encoding Format
図 1: 地理位置情報の LCAF エンコーディング形式
AFI:
AFI:
Set to 16387 to indicate that the address is using the LCAF format from [RFC8060].
アドレスが [RFC8060] の LCAF 形式を使用していることを示すには、16387 に設定します。
Type:
タイプ：
17
17
Rsvd1/Rsvd2/Flags:
Rsvd1/Rsvd2/フラグ:
See [RFC8060] for details.
詳細については[RFC8060]を参照してください。
Length:
長さ：
The length in bytes, starting with and including the byte after the 'Length' field.
「長さ」フィールドの後のバイトを含む、バイト単位の長さ。
U-bit:
Uビット:
If the U-bit is set, it indicates that the 'Location Uncertainty' field is used. If the U-bit is clear, it indicates the 'Location Uncertainty' field sent as 0 and ignored on receipt.
U ビットが設定されている場合、「位置不確実性」フィールドが使用されていることを示します。U ビットがクリアの場合、「位置不確実性」フィールドが 0 として送信され、受信時に無視されたことを示します。
N-bit:
Nビット:
If the N-bit is set, it indicates the latitude is north relative to the Equator. If the N-bit is clear, it indicates the latitude is south of the Equator.
N ビットが設定されている場合、緯度が赤道に対して北であることを示します。N ビットがクリアの場合、緯度が赤道の南にあることを示します。
E-bit:
Eビット:
If the E-bit is set, it indicates the longitude is east of the Prime Meridian. If the E-bit is clear, it indicates the longitude is west of the Prime Meridian.
E ビットが設定されている場合、経度が本初子午線の東にあることを示します。E ビットがクリアの場合、経度が本初子午線より西にあることを示します。
A-bit:
ちょっと:
If the A-bit is set, it indicates the 'Altitude' field is used. If the A-bit is clear, it indicates the 'Altitude' field is sent as 0 and ignored on receipt.
A ビットが設定されている場合は、「高度」フィールドが使用されていることを示します。A ビットがクリアの場合、「高度」フィールドが 0 として送信され、受信時に無視されることを示します。
M-bit:
M ビット:
If the M-bit is set, it indicates the altitude is specified in meters. If the M-bit is clear, it indicates the altitude is in centimeters.
M ビットが設定されている場合は、高度がメートル単位で指定されていることを示します。M ビットがクリアの場合は、高度がセンチメートル単位であることを示します。
R-bit:
Rビット:
If the R-bit is set, it indicates the 'Radius' field is used and the encoding is a Geo-Prefix. If the R-bit is clear, it indicates the 'Radius' field is set to 0 and the encoding is a Geo-Point.
R ビットが設定されている場合、「Radius」フィールドが使用され、エンコーディングが地理プレフィックスであることを示します。R ビットがクリアの場合は、「Radius」フィールドが 0 に設定されており、エンコーディングが Geo-Point であることを示します。
K-bit:
Kビット:
If the K-bit is set, it indicates the radius is specified in kilometers. If the K-bit is clear, it indicates the radius is in meters.
K ビットが設定されている場合は、半径がキロメートル単位で指定されていることを示します。K ビットがクリアの場合は、半径がメートル単位であることを示します。
Reserved:
予約済み：
Reserved for future addition of bit fields. These bits MUST be set to 0 when sending protocol packets and MUST be ignored when receiving protocol packets.
将来のビットフィールドの追加のために予約されています。これらのビットは、プロトコル パケットを送信するときは 0 に設定しなければならず、プロトコル パケットを受信するときは無視しなければなりません (MUST)。
Location Uncertainty:
位置の不確実性:
Unsigned 16-bit integer indicating the number of centimeters of uncertainty for the location.
位置の不確実性をセンチメートル単位で示す符号なし 16 ビット整数。
Latitude Degrees:
緯度:
Unsigned 8-bit integer with a range of 0 to 90 degrees north or south of the Equator (northern or southern hemisphere, respectively).
赤道の北または南 (それぞれ北半球または南半球) 0 ～ 90 度の範囲の符号なし 8 ビット整数。
Latitude Milliseconds:
緯度ミリ秒:
Unsigned 24-bit integer with a range of 0 to 3,599,999 (i.e., less than 60 minutes).
0 ～ 3,599,999 の範囲の符号なし 24 ビット整数 (つまり、60 分未満)。
Longitude Degrees:
経度:
Unsigned 8-bit integer with a range of 0 to 180 degrees east or west of the Prime Meridian.
本初子午線の東または西 0 ～ 180 度の範囲の符号なし 8 ビット整数。
Longitude Milliseconds:
経度ミリ秒:
Unsigned 24-bit integer with a range of 0 to 3,599,999 (i.e., less than 60 minutes).
0 ～ 3,599,999 の範囲の符号なし 24 ビット整数 (つまり、60 分未満)。
Altitude:
高度：
Signed 32-bit integer containing the height relative to sea level in centimeters or meters. A negative height indicates that the location is below sea level.
海面に対する相対的な高さをセンチメートルまたはメートル単位で含む符号付き 32 ビット整数。負の高さは、その場所が海面より低いことを示します。
Radius:
半径：
Unsigned 16-bit integer containing the radius of a sphere (or circle if altitude not specified) centered at the specified coordinates. The radius is specified in meters unless the K-bit is specified, indicating radius is in kilometers. When the radius is specified, this LCAF type encodes a Geo-Prefix where the Geo-Coordinates define the entire area of the sphere or circle defined by the radius and center point.
指定された座標を中心とする球 (高度が指定されていない場合は円) の半径を含む符号なし 16 ビット整数。K ビットが指定されていない限り、半径はメートル単位で指定され、半径がキロメートル単位であることを示します。半径が指定されている場合、この LCAF タイプは、半径と中心点によって定義される球または円の領域全体を地理座標で定義する地理プレフィックスをエンコードします。
AFI/Address:
AFI/アドレス:
The 'AFI' field indicates the Address Family Identifier [AFN] [RFC8060] for the address in the 'Address' field.
「AFI」フィールドは、「Address」フィールドのアドレスのアドレス ファミリ識別子 [AFN] [RFC8060] を示します。
EID-Records encoded with the Geo-Location LCAF are supported only by LISP nodes that support them for registration and lookup purposes.
Geo-Location LCAF でエンコードされた EID レコードは、登録および検索の目的で EID レコードをサポートする LISP ノードによってのみサポートされます。
RLOC-Records encoded with the Geo-Location LCAF can be returned from the Mapping Database System lookups to LISP nodes that do not understand them. In such situations, the RLOC-Record is ignored.
Geo-Location LCAF でエンコードされた RLOC レコードは、マッピング データベース システムのルックアップから、それを理解できない LISP ノードに返されることがあります。このような状況では、RLOC レコードは無視されます。
The use of Geo-Coordinates in any application must be considered carefully to not violate any privacy concerns about physical location. This document does take into consideration the applicability of BCP 160 [RFC6280] for location-based privacy protection.
アプリケーションでの地理座標の使用は、物理的な位置に関するプライバシー上の懸念を侵害しないように慎重に検討する必要があります。この文書では、位置ベースのプライバシー保護に対する BCP 160 [RFC6280] の適用可能性を考慮しています。
In a LISP environment, Geo-Coordinates can be registered to the Mapping Database System. When this occurs, any Tunnel Router (xTR) is allowing its physical location to be known to queriers of the Mapping Database System as well as network components that make up the Mapping Database System. There are various sets of trust relationships that may exist.
LISP 環境では、地理座標をマッピング データベース システムに登録できます。これが発生すると、トンネル ルーター (xTR) によって、その物理的な位置がマッピング データベース システムのクエリーおよびマッピング データベース システムを構成するネットワーク コンポーネントに知られるようになります。さまざまな信頼関係が存在する可能性があります。
When xTRs register their mappings with Geo-Coordinate information, a policy is associated about who can access the information. Typically, the policy is stored locally on the xTR and applied when the Mapping Service Provider (MSP) forwards Map-Requests to the xTRs of the LISP site. Conditionally, based on the requesting xTR, the responding xTR can apply the local policy to decide if a Map-Reply is sent with all RLOC-Records or, perhaps, the RLOC-Records that do not contain Geo-Coordinate information.
xTR が地理座標情報を使用してマッピングを登録すると、誰がその情報にアクセスできるかに関するポリシーが関連付けられます。通常、ポリシーは xTR 上にローカルに保存され、マッピング サービス プロバイダー (MSP) がマップ要求を LISP サイトの xTR に転送するときに適用されます。条件付きで、要求元の xTR に基づいて、応答する xTR はローカル ポリシーを適用して、マップ応答がすべての RLOC レコードとともに送信されるか、またはおそらく地理座標情報を含まない RLOC レコードとともに送信されるかを決定できます。
The MSP can also be requested by LISP site xTRs to proxy Map-Replies to Map-Requests. In this case, the MSP MUST apply the xTR policy so only authorized requesters get access to Geo-Coordinate information.
MSP は、LISP サイト xTR によって Map-Replies を Map-Request にプロキシするように要求することもできます。この場合、MSP は、許可された要求者のみが地理座標情報にアクセスできるように、xTR ポリシーを適用しなければなりません。
Note that once a requester is authorized, Map-Replies are returned directly to the requester and are signed as described in [RFC9303]. The Map-Replies not only authenticate the Map-Replier but can be encrypted by the Map-Replier so no eavesdropping of Geo-Coordinate information can occur.
リクエスタが認可されると、Map-Replies がリクエスタに直接返され、[RFC9303] で説明されているように署名されることに注意してください。Map-Replies は Map-Replier を認証するだけでなく、Map-Replier によって暗号化できるため、地理座標情報の盗聴が発生することはありません。
In most deployment cases, there is no tracking of EID host-based systems since Geo-Coordinate assignment is typically registered for LISP xTR devices or other asset inventory. However, since Geo-Coordinate-encoded RLOCs can be associated with any EID, tracking of hosts can occur if such an EID is assigned to hosts.
ほとんどの導入ケースでは、地理座標の割り当ては通常、LISP xTR デバイスまたはその他の資産インベントリに登録されるため、EID ホストベースのシステムは追跡されません。ただし、地理座標でエンコードされた RLOC は任意の EID に関連付けることができるため、そのような EID がホストに割り当てられている場合、ホストの追跡が発生する可能性があります。
In addition to controlling where LISP Geo-Coordinate mapping records go and applying policies (see "Security Considerations" section) for who can access them, there are additional steps that can be taken to protect against threats.
LISP 地理座標マッピング レコードの送信先を制御し、アクセスできるユーザーに関するポリシーを適用することに加えて (「セキュリティに関する考慮事項」セクションを参照)、脅威から保護するために実行できる追加の手順があります。
The privacy guidelines in [RFC6973] can be implemented with existing LISP features, for example:
[RFC6973] のプライバシー ガイドラインは、次のような既存の LISP 機能を使用して実装できます。
* Using signatures from [ECDSA-AUTH] can authenticate and authorize who can request such mapping records.
* [ECDSA-AUTH] からの署名を使用すると、そのようなマッピング レコードを要求できるユーザーを認証および認可できます。
* Obfuscating a Geo-Point by using Geo-Prefixes uses data minimization techniques.
* Geo-Prefix を使用して Geo-Point を難読化するには、データ最小化手法を使用します。
* Using short TTLs so the Geo-Coordinate mapping records are ephemeral reduces the attack window.
* 地理座標マッピング レコードが一時的なものとなるように短い TTL を使用すると、攻撃ウィンドウが減少します。
The typical applicability for the use of Geo-Coordinates is to describe the physical location of well-known public structures, places, and landmarks rather than people, vehicles, and equipment.
地理座標の使用の一般的な用途は、人、車両、設備ではなく、よく知られた公共の建造物、場所、ランドマークの物理的な位置を記述することです。
Following the guidelines of [RFC8126], IANA has assigned the following value in the "LISP Canonical Address Format (LCAF) Types" registry [RFC8060]:
[RFC8126] のガイドラインに従って、IANA は「LISP Canonical Address Format (LCAF) Types」レジストリ [RFC8060] に次の値を割り当てました。
+=======+=====================+======================+
| Value | LISP LCAF Type Name | Reference |
+=======+=====================+======================+
| 17 | Geo-Location | RFC 10040, Section 7 |
+-------+---------------------+----------------------+
Table 1: Geo-Location LCAF Type Assignment
表 1: 地理的位置の LCAF タイプの割り当て
In addition, IANA has marked LCAF type 5 (Geo-Coordinates) as deprecated in the "LISP Canonical Address Format (LCAF) Types" registry. This type was defined in [RFC8060], which this document updates.
さらに、IANA は、LCAF タイプ 5 (地理座標) を「LISP Canonical Address Format (LCAF) Types」レジストリで非推奨としてマークしました。このタイプは [RFC8060] で定義されており、この文書はそれを更新しています。
[GEO] National Geospatial-Intelligence Agency, "Department of
Defense World Geodetic System 1984: Its Definition and
Relationships with Local Geodetic Systems",
NGA.STND.0036_1.0.0_WGS84, 8 July 2014,
<https://nsgreg.nga.mil/doc/view?i=4085>.
[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>.
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011,
<https://www.rfc-editor.org/info/rfc6280>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC9179] Hopps, C., "A YANG Grouping for Geographic Locations",
RFC 9179, DOI 10.17487/RFC9179, February 2022,
<https://www.rfc-editor.org/info/rfc9179>.
[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>.
[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>.
[RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
"Locator/ID Separation Protocol Security (LISP-SEC)",
RFC 9303, DOI 10.17487/RFC9303, October 2022,
<https://www.rfc-editor.org/info/rfc9303>.
[RFC9735] Farinacci, D. and L. Iannone, Ed., "Locator/ID Separation
Protocol (LISP) Distinguished Name Encoding", RFC 9735,
DOI 10.17487/RFC9735, February 2025,
<https://www.rfc-editor.org/info/rfc9735>.
[AFN] IANA, "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers>.
[BGP-GEO] Chen, E., Shen, N., and R. Raszuk, "Carrying Geo
Coordinates in BGP", Work in Progress, Internet-Draft,
draft-chen-idr-geo-coordinates-02, 31 October 2016,
<https://datatracker.ietf.org/doc/html/draft-chen-idr-geo-
coordinates-02>.
[ECDSA-AUTH]
Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
Authentication and Authorization", Work in Progress,
Internet-Draft, draft-ietf-lisp-ecdsa-auth-17, 26 July
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
lisp-ecdsa-auth-17>.
[ISIS-GEO] Shen, N., Ed. and E. Chen, "Carrying Geo Coordinates
Information In IS-IS", Work in Progress, Internet-Draft,
draft-shen-isis-geo-coordinates-04, 18 October 2017,
<https://datatracker.ietf.org/doc/html/draft-shen-isis-
geo-coordinates-04>.
[OSPF-GEO] Lindem, A., Ed., Shen, N., and E. Chen, "OSPF Extensions
for Advertising/Signaling Geo Location Information", Work
in Progress, Internet-Draft, draft-acee-ospf-geo-location-
05, 18 October 2017,
<https://datatracker.ietf.org/doc/html/draft-acee-ospf-
geo-location-05>.
[PRED-RLOCS]
Farinacci, D. and P. Pillay-Esnault, "LISP Predictive
RLOCs", Work in Progress, Internet-Draft, draft-ietf-lisp-
predictive-rlocs-15, 19 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
predictive-rlocs-15>.
[V2I-PROB] Jeong, J. P. and T. T. Oh, "Problem Statement for Vehicle-
to-Infrastructure Networking", Work in Progress, Internet-
Draft, draft-jeong-its-v2i-problem-statement-02, 19 July
2016, <https://datatracker.ietf.org/doc/html/draft-jeong-
its-v2i-problem-statement-02>.
The author would like to thank the LISP WG for their review and acceptance of this document and Kiran Makhijani for shepherding the document.
著者は、この文書をレビューして受け入れてくれた LISP WG と、この文書を導いてくれた Kiran Makhijani に感謝したいと思います。
Special thanks goes to Chris Hopps, Enke Chen, Acee Lindem, and Naiming Shen for collaborating on a Geo-Location encoding format that is consistent with OSPF [OSPF-GEO], IS-IS [ISIS-GEO], and BGP [BGP-GEO].
OSPF [OSPF-GEO]、IS-IS [ISIS-GEO]、および BGP [BGP-GEO] と一貫性のある地理位置情報エンコード形式に関して協力してくれた Chris Hopps、Enke Chen、Acee Lindem、Naiming Shen に特別な感謝を捧げます。
Dino Farinacci
lispers.net
San Jose, CA
United States of America
Email: farinacci@gmail.com