Internet Engineering Task Force (IETF) D. Farinacci
Request for Comments: 9735 lispers.net
Category: Standards Track L. Iannone, Ed.
ISSN: 2070-1721 Huawei
February 2025
This document defines how to use the Address Family Identifier (AFI) 17 "Distinguished Name" in the Locator/ID Separation Protocol (LISP). LISP introduces two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). Distinguished Names (DNs) can be used in either EID-Records or RLOC-Records in LISP control messages to convey additional information.
このドキュメントでは、Locator/ID分離プロトコル（LISP）でアドレスファミリ識別子（AFI）17「著名な名前」を使用する方法を定義します。LISPは、エンドポイント識別子（EIDS）とルーティングロケーター（RLOC）の2つの新しい番号付けスペースを導入します。著名な名前（DNS）は、LISPコントロールメッセージのEID-RecordsまたはRLOC-Recordsで追加情報を伝えることができます。
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/rfc9735.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9735で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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ライセンステキストを含める必要があります。
1. Introduction
2. Terminology
2.1. Definition
2.2. Requirements Language
3. Distinguished Name Format
4. Mapping-System Lookups for DN EIDs
5. Example Use Cases
6. Name-Collision Considerations
7. Security Considerations
8. IANA Considerations
9. Sample LISP DN Deployment Experience
9.1. DNs to Advertise Specific Device Roles or Functions
9.2. DNs to Drive xTR Onboarding Procedures
9.3. DNs for NAT-Traversal
9.4. DNs for Self-Documenting RLOC Names
9.5. DNs Used as EID Names
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Authors' Addresses
LISP ([RFC9300] and [RFC9301]) introduces two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). To provide flexibility for current and future applications, these values can be encoded in LISP control messages using a general syntax that includes the Address Family Identifier (AFI).
LISP（[RFC9300]および[RFC9301]）は、エンドポイント識別子（EIDS）とルーティングロケーター（RLOC）の2つの新しい番号付けスペースを導入します。現在および将来のアプリケーションに柔軟性を提供するために、これらの値は、アドレスファミリ識別子（AFI）を含む一般的な構文を使用して、LISP制御メッセージでエンコードできます。
The length of addresses encoded in EID-Records and RLOC-Records can easily be determined by the AFI field, as the size of the address is implicit in its AFI value. For instance, for AFI equal to 1, which is "IP (IP version 4)", the address length is known to be 4 octets. However, AFI 17 "Distinguished Name", is a variable-length value, so the length cannot be determined solely from the AFI value 17 [ADDRESS-FAMILY]. This document defines a termination character, an 8-bit value of 0, to be used as a string terminator so the length can be determined.
アドレスのサイズがAFI値に暗黙的であるため、EID-RecordsおよびRLOC-Recordsでエンコードされたアドレスの長さはAFIフィールドによって簡単に決定できます。たとえば、「IP（IPバージョン4）」であるAFIの場合、アドレスの長さは4オクテットであることが知られています。ただし、AFI 17 "Distinguished Name"は可変長さの値であるため、長さはAFI値17 [アドレスファミリー]からのみ決定することはできません。このドキュメントでは、長さを決定できるように、文字列ターミネーターとして使用するために、0の8ビット値が0の終端文字を定義します。
LISP DNs are useful when encoded either in EID-Records or RLOC-Records in LISP control messages. As EIDs, they can be registered in the Mapping System to find resources, services, or simply be used as a self-documenting feature that accompanies other address-specific EIDs. As RLOCs, DNs, along with RLOC-specific addresses and parameters, can be used as labels to identify equipment type, location, or any self-documenting string a registering device desires to convey.
LISP DNSは、LISPコントロールメッセージのeid-Recordsまたはrloc-Recordsのいずれかでエンコードされた場合に役立ちます。Eidsとして、それらはマッピングシステムに登録されて、リソース、サービスを見つけるか、単に他のアドレス固有のEIDに伴う自己文書化機能として使用できます。RLOCSとして、DNSは、RLOC固有のアドレスとパラメーターとともに、登録デバイスが伝える必要のある機器の種類、場所、または自己文書文字列を特定するためのラベルとして使用できます。
The Distinguished Name field in this document has no relationship to the similarly named field in the Public-Key Infrastructure using X.509 (PKIX) specifications (e.g., [RFC5280]).
このドキュメントの著名な名前のフィールドは、X.509（PKIX）仕様（[RFC5280]など）を使用して、パブリックキーインフラストラクチャの同様に指定されたフィールドと関係がありません。
Address Family Identifier (AFI):
住所ファミリ識別子（AFI）：
a term used to describe an address encoding in a packet. An address family is currently defined for IPv4 or IPv6 addresses. See [ADDRESS-FAMILY] for details on other types of information that can be AFI encoded.
パケットでエンコードするアドレスを記述するために使用される用語。現在、アドレスファミリはIPv4またはIPv6アドレスに対して定義されています。AFIエンコードできる他の種類の情報の詳細については、[アドレスファミリー]を参照してください。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
An AFI 17 "Distinguished Name" is encoded as:
AFI 17 "Distinguished Name"は次のようにエンコードされています。
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 = 17 | NULL-Terminated (0x00) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ US-ASCII String |
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The variable-length string of characters are encoded as a NULL-terminated (0x00) US-ASCII character set as defined in [RFC3629], where UTF-8 has the characteristic of preserving the full US-ASCII range. A NULL character MUST appear only once in the string and MUST be at the end of the string.
可変長さの文字列の文字列は、[RFC3629]で定義されているヌル終端（0x00）US-ASCII文字セットとしてエンコードされます。UTF-8は、完全なUS-ASCII範囲を保存する特性を持っています。ヌル文字は、文字列に1回だけ表示され、文字列の最後に表示されなければなりません。
When DNs are encoded for EIDs, the EID Mask-Len length of the EID-Records, for all LISP control messages [RFC9301], is the length of the string in bits (including the NULL-terminated 0x00 octet).
DNSがEIDSに対してエンコードされると、すべてのLISP制御メッセージ[RFC9301]のEIDマスクレンの長さは、ビット内の文字列の長さ（ヌル終端0x00オクテットを含む）です。
Where DNs are encoded anywhere else (i.e., nested in LISP Canonical Address Format (LCAF) encodings [RFC8060]), an explicit length field can be used to indicate the length of the ASCII string in octets. The length field MUST include the NULL octet (0x00). The string MUST still be NULL-terminated (0x00). If a NULL octet (0x00) appears before the end of the octet field, i.e., the NULL octet (0x00) appears before the last position in the octet fields, then the string MAY be accepted and the octets after the NULL octet (0x00) MUST NOT be used as part of the octet string.
DNSが他のどこにでもエンコードされている場合（つまり、LISP Canonicalアドレス形式（LCAF）エンコーディング[RFC8060]にネストされています）、明示的な長さフィールドを使用して、オクテットのASCII文字列の長さを示すことができます。長さのフィールドには、nullオクテット（0x00）を含める必要があります。文字列はまだヌルターミネーション（0x00）でなければなりません。オクテットフィールドの終了前にヌルオクテット（0x00）が現れる場合、つまりnullオクテット（0x00）がオクテットフィールドの最後の位置の前に現れると、弦が受け入れられ、nullオクテット（0x00）の後にオクテットが受け入れられる場合があります。Octet Stringの一部として使用しないでください。
If the octet after the AFI field is the NULL octet (0x00), the string is a NULL string and MUST be accepted. That is, an AFI 17 "Distinguished Name" encoded string MUST be at least 1 octet in length.
AFIフィールドの後のオクテットがnullオクテット（0x00）の場合、文字列はnull文字列であり、受け入れる必要があります。つまり、AFI 17の「著名な名前」エンコード文字列の長さは少なくとも1オクテットでなければなりません。
When performing DN-EID lookups, Map-Request messages MUST carry an EID Mask-Len length equal to the length of the name string in bits. This instructs the Mapping System to do either an exact-match or a longest-match lookup.
DN-EIDルックアップを実行する場合、Map-Requestメッセージは、ビットの名前の文字列の長さに等しいEid Mask-Lenの長さを運ぶ必要があります。これにより、マッピングシステムに、正確な試合または最長試合の検索を行うように指示します。
If the DN EID is registered with the same length as the length in a Map-Request, the Map-Server (when configured for proxy Map-Replying) returns an exact-match lookup with the same EID Mask-Len length. If a less specific name is registered, then the Map-Server returns the registered name with the registered EID Mask-Len length.
DN EIDがMAP-Requestの長さと同じ長さで登録されている場合、MAPサーバー（プロキシマップリップリング用に構成されている場合）は、同じEIDマスクレンの長さで正確なマッチルックアップを返します。特定の名前が登録されていない場合、Map-Serverは登録されたEid Mask-Lenの長さで登録名を返します。
For example, if the registered EID name is "ietf" with an EID Mask-Len length of 40 bits (the length of the string "ietf" plus the length of the NULL octet (0x00) makes 5 octets), and a Map-Request is received for EID name "ietf.lisp" with an EID Mask-Len length of 80 bits, the Map-Server will return EID "ietf" with a length of 40 bits.
たとえば、登録されたEid名が40ビットのEid Mask-Lenの長さ（文字列「IETF」の長さとnullオクテット（0x00）の長さが5オクテットを作成）を持つ「IETF」である場合、マップ -Eid Name "ietf.lisp"のリクエストが80ビットのEid Mask-lenの長さで受信され、Map-Serverは40ビットの長さでEid "IETF"を返します。
This section identifies three specific use-case examples for the DN format: two are used for an EID encoding and one for an RLOC-Record encoding. When storing public keys in the Mapping System, as in [LISP-ECDSA], a well-known format for a public-key hash can be encoded as a DN. When street-location-to-GPS-coordinate mappings exist in the Mapping System, as in [LISP-GEO], the street location can be a free-form UTF-8 ASCII representation (with whitespace characters) encoded as a DN. An RLOC that describes an Ingress or Egress Tunnel Router (xTR) behind a NAT device can be identified by its router name, as in [LISPERS-NET-NAT]. In this case, DN encoding is used in NAT Info-Request messages after the EID-prefix field of the message.
このセクションでは、DN形式の3つの特定のユースケースの例を識別します。2つはEIDエンコードに使用され、1つはRLOCレコードエンコードに使用されます。[lisp-ecdsa]のように、マッピングシステムにパブリックキーを保存する場合、パブリックキーハッシュの有名な形式をDNとしてエンコードできます。[lisp-geo]のように、マッピングシステムにストリートロケーションとGPSへの配置マッピングが存在する場合、通りの場所は、dnとしてエンコードされたフリーフォームのUTF-8 ASCII表現（空白文字を使用）にすることができます。[lispers-net-nat]のように、NATデバイスの背後にある侵入または出口トンネルルーター（xtr）を記述するRLOCをルーター名で識別できます。この場合、メッセージのEid-Prefixフィールドの後、DNエンコードはNAT Info-Requestメッセージで使用されます。
When a DN encoding is used to format an EID, the uniqueness and allocation concerns are no different than registering IPv4 or IPv6 EIDs to the Mapping System. See [RFC9301] for more details. Also, the use cases documented in Section 5 of this specification provide allocation recommendations for their specific uses.
DNエンコーディングを使用してEIDをフォーマットする場合、マッピングシステムにIPv4またはIPv6 Eidsを登録するのと一意性と割り当ての懸念は違いはありません。詳細については、[RFC9301]を参照してください。また、この仕様のセクション5に文書化されたユースケースは、特定の用途に関する割り当て推奨事項を提供します。
It is RECOMMENDED that each use case register their DNs with a unique Instance-ID. Any use cases that require different uses for DNs within an Instance-ID MUST define their own Instance-ID and syntax structure for the name registered to the Mapping System. See the encoding procedures in [LISP-VPN] for an example.
各ユースケースは、独自のInstance-IDでDNSを登録することをお勧めします。Instance-ID内のDNSに異なる用途を必要とするユースケースは、マッピングシステムに登録された名前の独自のInstance-IDと構文構造を定義する必要があります。例については、[lisp-vpn]のエンコード手順を参照してください。
DNs are used in mappings that are part of the LISP control plane and may be encoded using LCAF; thus, the security considerations of [RFC9301] and [RFC8060] apply.
DNSは、LISPコントロールプレーンの一部であり、LCAFを使用してエンコードできるマッピングで使用されます。したがって、[RFC9301]および[RFC8060]のセキュリティ上の考慮事項が適用されます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
Practical implementations of the LISP DN, defined in this document, have been running in production networks for some time. The following sections provide some examples of its usage and lessons learned out of this experience.
このドキュメントで定義されているLISP DNの実用的な実装は、しばらくの間生産ネットワークで実行されてきました。次のセクションでは、この経験から学んだ使用と教訓の例をいくつか説明します。
In a practical implementation of [LISP-EXT] on LISP deployments, routers running as Proxy Egress Tunnel Routers (Proxy-ETRs) register their role with the Mapping System in order to attract traffic destined for external networks. Practical implementations of this functionality make use of a DN as an EID to identify the Proxy-ETR role in a Map-Registration.
LISP展開での[LISP-EXT]の実際の実装では、外部ネットワークに向けてトラフィックを引き付けるために、プロキシエグレストンネルルーター（Proxy-Erts）として実行されるルーター（プロキシ-Erts）がマッピングシステムに役割を登録します。この機能の実用的な実装では、DNをEIDとして使用して、マップ登録におけるプロキシ-ERTの役割を特定します。
In this case, all Proxy-ETRs supporting this function register a common DN together with their own offered locator. The Mapping System aggregates the locators received from all Proxy-ETRs as a common locator-set that is associated with this DN EID. In this scenario, the DN serves as a common reference EID that can be requested (or subscribed as per [RFC9437]) to dynamically gather this Proxy-ETR list as specified in the LISP Site External Connectivity document [LISP-EXT].
この場合、この関数をサポートするすべてのプロキシエートは、提供されるロケーターと一緒に共通のDNを登録します。マッピングシステムは、このDN EIDに関連付けられている共通のロケーターセットとして、すべてのプロキシ-Ertsから受信したロケーターを集約します。このシナリオでは、DNは、LISPサイト外部接続ドキュメント[LISP-EXT]で指定されているように、このプロキシ-ERTリストを動的に収集するために要求できる（または[RFC9437]に従ってサブスクライブ）できる一般的な参照EIDとして機能します。
The use of a DN here provides descriptive information about the role being registered and allows the Mapping System to form locator-sets associated with a specific role. These locator-sets can be distributed on-demand based on using the shared DN as EID. It also allows the network admin and the Mapping System to selectively choose what roles and functions can be registered and distributed to the rest of the participants in the network.
ここでDNを使用すると、登録されている役割に関する記述情報が提供され、マッピングシステムが特定の役割に関連付けられたロケーターセットをフォームできます。これらのロケーターセットは、共有DNをEIDとして使用することに基づいて、オンデマンドで配布できます。また、ネットワーク管理者とマッピングシステムが、ネットワークの残りの参加者に登録および配布できる役割と機能を選択的に選択できるようにします。
Following the LISP reliable transport [LISP-MAP], ETRs that plan to switch to using reliable transport to hold registrations first need to start with UDP registrations. The UDP registration allows the Map-Server to perform basic authentication of the ETR and to create the necessary state to permit the reliable transport session to be established (e.g., establish a passive open on TCP port 4342 and add the ETR RLOC to the list allowed to establish a session).
LISP信頼できるトランスポート[LISP-MAP]に続いて、登録を保持するために信頼できるトランスポートを使用することを計画しているETRは、最初にUDP登録を開始する必要があります。UDP登録により、Map-ServerはETRの基本認証を実行し、信頼できる輸送セッションを確立できるように必要な状態を作成できます（たとえば、TCPポート4342にパッシブオープンを確立し、ETR RLOCを許可されたリストに追加しますセッションを確立するため）。
In the basic implementation of this process, the ETRs need to wait until local mappings are available and ready to be registered with the Mapping System. Furthermore, when the Mapping System is distributed, the ETR requires having one specific mapping ready to be registered with each one of the relevant Map-Servers. This process may delay the onboarding of ETRs with the Mapping System so that they can switch to using reliable transport. This can also lead to generating unnecessary signaling as a reaction to certain triggers like local port flaps and device failures.
このプロセスの基本的な実装では、ETRはローカルマッピングが利用可能になり、マッピングシステムに登録する準備ができるまで待つ必要があります。さらに、マッピングシステムが分散されている場合、ETRは、関連するマップサーバーのそれぞれに登録される特定のマッピング1つを準備する必要があります。このプロセスでは、Mappingシステムを使用したETRのオンボーディングを遅らせるため、信頼できる輸送の使用に切り替えることができます。これはまた、ローカルポートフラップやデバイスの障害などの特定のトリガーに対する反応として、不必要なシグナル伝達を生成することにつながる可能性があります。
The use of dedicated name registrations allows driving this initial ETR onboarding on the Mapping System as a deterministic process that does not depend on the availability of other mappings. It also provides more stability to the reliable transport session to survive through transient events.
専用の名前登録を使用すると、他のマッピングの可用性に依存しない決定論的プロセスとして、マッピングシステム上のこの最初のETRオンボーディングを駆動できます。また、一時的なイベントを通じて生き残るために、信頼できる輸送セッションにより安定性を提供します。
In practice, LISP deployments use dedicated DNs that are registered as soon as xTRs come online with all the necessary Map-Servers in the Mapping System. The mapping with the dedicated DN together with the RLOCs of each Egress Tunnel Router (ETR) in the locator-set is used to drive the initial UDP registration and also to keep the reliable transport state stable through network condition changes. On the Map-Server, these DN registrations facilitate setting up the necessary state to onboard new ETRs rapidly and in a more deterministic manner.
実際には、LISPの展開では、マッピングシステムのすべての必要なマップサーバーとともにXTRがオンラインで登場するとすぐに登録される専用のDNSを使用します。ロケーターセットの各出力トンネルルーター（ETR）のRLOCとともに専用のDNを使用したマッピングは、最初のUDP登録を駆動し、ネットワーク状態の変更を通じて信頼できる輸送状態を安定させるために使用されます。マップサーバーでは、これらのDN登録により、新しいETRを迅速かつより決定的な方法で搭載するために必要な状態を設定することが容易になります。
At the time of writing, the open-source lispers.net NAT-Traversal implementation [LISPERS-NET-NAT] has deployed DNs for documenting xTRs versus Re-encapsulating Tunnel Routers (RTRs) as they appear in a locator-set for 10 years.
執筆時点で、オープンソースのlispers.net nat-traversal実装[lispers-net-nat]は、ロケーターセットに10年間表示されているように、XTRSと再エンコールトンネルルーター（RTR）を文書化するためにDNSを展開しています。。
At the time of writing, the open-source lispers.net implementation [LISPERS-NET-NAT] has self-documented RLOC names in production and pilot environments for 10 years. The RLOC name is encoded with the RLOC address in DN format.
執筆時点では、オープンソースLispers.net実装[lispers-net-nat]は、生産およびパイロット環境で10年間自己文書化されたRLOC名を持っています。RLOC名は、DN形式のRLOCアドレスでエンコードされています。
At the time of writing, the open-source lispers.net implementation [LISPERS-NET-NAT] has deployed xTRs that are allowed to register EIDs as DNs for 10 years. The LISP Mapping System can be used as a DNS proxy for Name-to-EID-address or Name-to-RLOC-address mappings. The implementation also supports Name-to-Public-Key mappings to provide key management features in [LISP-ECDSA].
執筆時点で、オープンソースLispers.net実装[lispers-net-nat]は、Eidsを10年間DNSとして登録できるXTRを展開しています。LISPマッピングシステムは、名前からEIDへの名前へのDNSプロキシまたは名前からRLOC-AddressマッピングのDNSプロキシとして使用できます。この実装は、[LISP-ECDSA]の主要な管理機能を提供するために、名前からパブリックまでのキーマッピングもサポートしています。
[ADDRESS-FAMILY]
IANA, "Address Family Numbers",
<https://www.iana.org/assignments/address-family-numbers>.
[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>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[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>.
[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>.
[RFC9437] Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai,
S., and M. Boucadair, "Publish/Subscribe Functionality for
the Locator/ID Separation Protocol (LISP)", RFC 9437,
DOI 10.17487/RFC9437, August 2023,
<https://www.rfc-editor.org/info/rfc9437>.
[LISP-ECDSA]
Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
Authentication and Authorization", Work in Progress,
Internet-Draft, draft-ietf-lisp-ecdsa-auth-13, 18 August
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
lisp-ecdsa-auth-13>.
[LISP-EXT] Jain, P., Moreno, V., and S. Hooda, "LISP Site External
Connectivity", Work in Progress, Internet-Draft, draft-
ietf-lisp-site-external-connectivity-01, 24 September
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
lisp-site-external-connectivity-01>.
[LISP-GEO] Farinacci, D., "LISP Geo-Coordinate Use-Cases", Work in
Progress, Internet-Draft, draft-ietf-lisp-geo-09, 15
January 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-lisp-geo-09>.
[LISP-MAP] Venkatachalapathy, B., Portoles-Comeras, M., Lewis, D.,
Kouvelas, I., and C. Cassar, "LISP Map Server Reliable
Transport", Work in Progress, Internet-Draft, draft-ietf-
lisp-map-server-reliable-transport-05, 4 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
map-server-reliable-transport-05>.
[LISP-VPN] Moreno, V. and D. Farinacci, "LISP Virtual Private
Networks (VPNs)", Work in Progress, Internet-Draft, draft-
ietf-lisp-vpn-12, 19 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
vpn-12>.
[LISPERS-NET-NAT]
Farinacci, D., "lispers.net LISP NAT-Traversal
Implementation Report", Work in Progress, Internet-Draft,
draft-farinacci-lisp-lispers-net-nat-09, 8 December 2024,
<https://datatracker.ietf.org/doc/html/draft-farinacci-
lisp-lispers-net-nat-09>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[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>.
The authors would like to thank the LISP WG for their review and acceptance of this document. A special thank you goes to Marc Portoles for moving this document through the process and providing deployment-experience samples.
著者は、この文書のレビューと受け入れについてLISP WGに感謝したいと思います。このドキュメントをプロセスで移動し、展開 - 実験サンプルを提供してくれたMarc Portolesに感謝します。
Dino Farinacci
lispers.net
San Jose, CA
United States of America
Email: farinacci@gmail.com
Luigi Iannone (editor)
Huawei Technologies France S.A.S.U.
18, Quai du Point du Jour
92100 Boulogne-Billancourt
France
Email: luigi.iannone@huawei.com