RFC 9306 - Vendor-Specific LISP Canonical Address Format (LCAF) 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9306.html
タイトル : RFC 9306 - ベンダー固有のLISP Canonicalアドレス形式（LCAF）
翻訳編集 : 自動生成

[要約] RFC 9306 は、Vendor-Specific LISP Canonical Address Format (LCAF) を導入し、組織が独自の LCAF アドレスエンコーディングを持つことを可能にします。目的は RFC 8060 を更新し、LISP のアドレス形式を拡張することです。

Internet Engineering Task Force (IETF)                A. Rodriguez-Natal
Request for Comments: 9306                                         Cisco
Updates: 8060                                                 V. Ermagan
Category: Experimental                                      Google, Inc.
ISSN: 2070-1721                                               A. Smirnov
                                                           V. Ashtaputre
                                                                   Cisco
                                                            D. Farinacci
                                                             lispers.net
                                                            October 2022

Vendor-Specific LISP Canonical Address Format (LCAF)

ベンダー固有のLISP Canonicalアドレス形式（LCAF）

Abstract

概要

This document describes a new Locator/ID Separation Protocol (LISP) Canonical Address Format (LCAF), the Vendor-Specific LCAF. This LCAF enables organizations to have implementation-specific encodings for LCAF addresses. This document updates RFC 8060.

このドキュメントでは、ベンダー固有のLCAFである新しいロケーター/ID分離プロトコル（LISP）標準アドレス形式（LCAF）について説明します。このLCAFにより、組織はLCAFアドレスの実装固有のエンコーディングを持つことができます。このドキュメントは、RFC 8060を更新します。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。

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.

このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc9306.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9306で取得できます。

著作権表示

著作権（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.  Unrecognized LCAF Types
   4.  Vendor-Specific LCAF
   5.  Security Considerations
   6.  IANA Considerations
   7.  Normative References
   Acknowledgments
   Authors' Addresses

1. Introduction

1. はじめに

The LISP Canonical Address Format (LCAF) [RFC8060] defines the format and encoding for different address types that can be used on deployments of the Locator/ID Separation Protocol (LISP) [RFC9300] [RFC9301]. However, certain deployments require specific format encodings that may not be applicable outside of the use case for which they are defined. This document extends [RFC8060] to introduce a Vendor-Specific LCAF that defines how organizations can create LCAF addresses to be used only on particular LISP implementations. This document also updates [RFC8060] to specify the behavior when receiving unrecognized LCAF types.

LISP Canonicalアドレス形式（LCAF）[RFC8060]は、ロケーター/ID分離プロトコル（LISP）[RFC9300] [RFC9301]の展開で使用できるさまざまなアドレスタイプの形式とエンコードを定義します。ただし、特定の展開には、定義されているユースケース以外では適用できない特定の形式エンコーディングが必要です。このドキュメントは[RFC8060]を拡張して、特定のLISP実装でのみ使用するために組織がLCAFアドレスを作成する方法を定義するベンダー固有のLCAFを導入します。また、このドキュメントは[RFC8060]を更新して、認識されていないLCAFタイプを受信したときに動作を指定します。

2. Requirements Notation

2. 要件表記

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]で説明されているように、すべて大文字の場合にのみ解釈されます。

3. Unrecognized LCAF Types

3. 認識されていないLCAFタイプ

[RFC8060] does not explain how an implementation should handle an unrecognized LCAF type. This document updates [RFC8060] to specify that any unrecognized LCAF type received in a LISP control plane message MUST be ignored. If all Locators are ignored, this is equivalent to a LISP control message with Locator Count = 0, as described in [RFC9301]. If an EID-Prefix only contains unrecognized LCAF types, the LISP control message MUST be dropped and the event MUST be logged. (Here, "EID" refers to Endpoint Identifier.)

[RFC8060]は、実装が認識されていないLCAFタイプをどのように処理するかを説明していません。このドキュメントは[RFC8060]を更新して、LISPコントロールプレーンメッセージで受信した認識されていないLCAFタイプを無視する必要があることを指定します。すべてのロケーターが無視されている場合、これは[RFC9301]で説明されているように、ロケーターカウント= 0のLISPコントロールメッセージに相当します。Eid-Prefixに認識されていないLCAFタイプのみが含まれている場合、LISPコントロールメッセージをドロップし、イベントを記録する必要があります。（ここで、「EID」とはEndPoint IDを指します。）

4. Vendor-Specific LCAF

4. ベンダー固有のLCAF

The Vendor-Specific LCAF relies on using the IEEE Organizationally Unique Identifier (OUI) [IEEE.802] to prevent collisions across vendors or organizations using the LCAF. The format of the Vendor-Specific LCAF is provided below.

ベンダー固有のLCAFは、LCAFを使用してベンダーまたは組織間の衝突を防ぐために、IEEE組織的に一意の識別子（OUI）[IEEE.802]を使用することに依存しています。ベンダー固有のLCAFの形式を以下に示します。

      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 = 255  |     Rsvd2     |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Rsvd3    |    Organizationally Unique Identifier (OUI)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Internal format...                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Vendor-Specific LCAF

図1：ベンダー固有のLCAF

The fields in the first 8 octets of the above Vendor-Specific LCAF are actually the fields defined in the general LCAF format specified in [RFC8060]. The Type field MUST be set 255, the value assigned by IANA to indicate that this is a Vendor-Specific LCAF; see Section 6. The Length field has to be set accordingly to the length of the internal format, plus the OUI, plus the Rsvd3 fields, as for [RFC8060]. The fields defined by the Vendor-Specific LCAF are as follows:

上記のベンダー固有のLCAFの最初の8オクテットのフィールドは、実際には[RFC8060]で指定された一般的なLCAF形式で定義されているフィールドです。タイプフィールドは255に設定する必要があります。これは、これがベンダー固有のLCAFであることを示すためにIANAによって割り当てられた値です。セクション6を参照してください。[RFC8060]のように、長さフィールドを内部形式の長さに加えてOUIとRSVD3フィールドに加えて設定する必要があります。ベンダー固有のLCAFによって定義されたフィールドは次のとおりです。

Rsvd3: This 8-bit field is reserved for future use. It MUST be set to 0 on transmit and MUST be ignored on receipt.

RSVD3：この8ビットフィールドは、将来の使用のために予約されています。送信時に0に設定する必要があり、受領時に無視する必要があります。

Organizationally Unique Identifier (OUI): This is a 24-bit field that carries an OUI or Company ID (CID) assigned by the IEEE Registration Authority (RA) as defined by the IEEE Std 802 [IEEE.802]

組織的に一意の識別子（OUI）：これは、IEEE STD 802 [IEEE.802]によって定義されているIEEE登録局（RA）によって割り当てられたOUIまたは会社ID（CID）を運ぶ24ビットフィールドです。

Internal format: This is a variable-length field that is left undefined on purpose. Each vendor or organization can define its own internal format(s) to use with the Vendor-Specific LCAF.

内部形式：これは、意図的に未定義のままにされる可変長フィールドです。各ベンダーまたは組織は、ベンダー固有のLCAFで使用する独自の内部形式を定義できます。

The Vendor-Specific LCAF type SHOULD NOT be used in deployments where different organizations interoperate. However, there may be cases where two (or more) organizations share a common deployment on which they explicitly and mutually agree to use a particular Vendor-Specific LCAF. In that case, the organizations involved need to carefully assess the interoperability concerns for that particular deployment. It is NOT RECOMMENDED to use an OUI not assigned to an organization.

ベンダー固有のLCAFタイプは、異なる組織が相互運用する展開に使用しないでください。ただし、2つの（またはそれ以上の）組織が、特定のベンダー固有のLCAFを使用することに明示的かつ相互に同意する共通の展開を共有する場合がある場合があります。その場合、関係する組織は、その特定の展開の相互運用性の懸念を慎重に評価する必要があります。組織に割り当てられていないOUIを使用することはお勧めしません。

If a LISP device receives a LISP message containing a Vendor-Specific LCAF with an OUI that it does not understand, it MUST drop the message and it SHOULD create a log message.

LISPデバイスが、理解できないOUIを備えたベンダー固有のLCAFを含むLISPメッセージを受信した場合、メッセージをドロップする必要があり、ログメッセージを作成する必要があります。

5. Security Considerations

5. セキュリティに関する考慮事項

This document enables organizations to define new LCAFs for their internal use. It is the responsibility of these organizations to properly assess the security implications of the formats they define. Security considerations from [RFC8060] apply to this document.

このドキュメントにより、組織は内部使用のために新しいLCAFを定義できます。これらの組織の責任は、定義する形式のセキュリティへの影響を適切に評価することです。[RFC8060]からのセキュリティ上の考慮事項は、このドキュメントに適用されます。

6. IANA Considerations

6. IANAの考慮事項

Following the guidelines of [RFC8126], IANA has assigned the following value for the Vendor-Specific LCAF from the "LISP Canonical Address Format (LCAF) Types" registry (defined in [RFC8060]):

[RFC8126]のガイドラインに従って、IANAは、「LISP Canonical Address Format（LCAF）タイプ」登録（[RFC8060]で定義）からベンダー固有のLCAFに次の値を割り当てました。

           +=======+=====================+=====================+
           | Value | LISP LCAF Type Name |      Reference      |
           +=======+=====================+=====================+
           |  255  |   Vendor Specific   | RFC 9306, Section 4 |
           +-------+---------------------+---------------------+

Table 1: Vendor-Specific LCAF Assignment

表1：ベンダー固有のLCAF割り当て

7. Normative References

7. 引用文献

[IEEE.802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", DOI 10.1109/IEEESTD.2014.6847097, IEEE Std 802, July 2014, <https://ieeexplore.ieee.org/document/6847097>.

[IEEE.802] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：概要とアーキテクチャ」、DOI 10.1109/IEEESTD.2014.6847097、IEEE STD 802、2014年7月<>。

[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>。

[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>.

[RFC8060] Farinacci、D.、Meyer、D。、およびJ. Snijders、「Lisp Canonical Address Format（LCAF）」、RFC 8060、DOI 10.17487/RFC8060、2017年2月、<https：//ww.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>.

[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.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>.

[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>。

Acknowledgments

謝辞

The authors would like to thank Joel Halpern, Luigi Iannone, and Alvaro Retana for their suggestions and guidance regarding this document.

著者は、この文書に関する提案とガイダンスについて、Joel Halpern、Luigi Iannone、およびAlvaro Retanaに感謝したいと思います。

Authors' Addresses

著者のアドレス

Alberto Rodriguez-Natal Cisco Spain Email: natal@cisco.com

Alberto Rodriguez-Natal Cisco Spainメール：natal@cisco.com

Vina Ermagan Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America Email: ermagan@gmail.com

Vina Ermagan Google、Inc。1600 Amphitheater Parkway Mountain View、CA 94043アメリカ合衆国電子メール：ermagan@gmail.com

Anton Smirnov Cisco Diegem Belgium Email: asmirnov@cisco.com

Anton Smirnov Cisco Diegem Belgiumメール：asmirnov@cisco.com

Vrushali Ashtaputre Cisco San Jose, CA United States of America Email: vrushali@cisco.com

Vrushali Ashtaputre Cisco San Jose、CA Necument of America Email：vrushali@cisco.com

Dino Farinacci lispers.net San Jose, CA United States of America Email: farinacci@gmail.com

Dino Farinacci lispers.netサンノゼ、カリフォルニア州統一されたアメリカ電子メール：farinacci@gmail.com