diff options
Diffstat (limited to 'doc/rfc/rfc9306.txt')
| -rw-r--r-- | doc/rfc/rfc9306.txt | 255 |
1 files changed, 255 insertions, 0 deletions
diff --git a/doc/rfc/rfc9306.txt b/doc/rfc/rfc9306.txt new file mode 100644 index 0000000..7b1bc37 --- /dev/null +++ b/doc/rfc/rfc9306.txt @@ -0,0 +1,255 @@ + + + + +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) + +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. + +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. + + 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. + +Copyright Notice + + Copyright (c) 2022 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + +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 + + 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. + +2. Requirements Notation + + 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. + +3. Unrecognized LCAF Types + + [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.) + +4. Vendor-Specific 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. + + + 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 + + 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: + + Rsvd3: This 8-bit field is reserved for future use. It MUST be set + to 0 on transmit and MUST be ignored on receipt. + + 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] + + 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. + + 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. + + 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. + +5. Security Considerations + + 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. + +6. IANA Considerations + + 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]): + + +=======+=====================+=====================+ + | Value | LISP LCAF Type Name | Reference | + +=======+=====================+=====================+ + | 255 | Vendor Specific | RFC 9306, Section 4 | + +-------+---------------------+---------------------+ + + Table 1: Vendor-Specific LCAF Assignment + +7. Normative References + + [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>. + + [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>. + + [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>. + + [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>. + +Acknowledgments + + The authors would like to thank Joel Halpern, Luigi Iannone, and + Alvaro Retana for their suggestions and guidance regarding this + document. + +Authors' Addresses + + Alberto Rodriguez-Natal + Cisco + Spain + Email: natal@cisco.com + + + Vina Ermagan + Google, Inc. + 1600 Amphitheatre Parkway + Mountain View, CA 94043 + United States of America + Email: ermagan@gmail.com + + + Anton Smirnov + Cisco + Diegem + Belgium + Email: asmirnov@cisco.com + + + Vrushali Ashtaputre + Cisco + San Jose, CA + United States of America + Email: vrushali@cisco.com + + + Dino Farinacci + lispers.net + San Jose, CA + United States of America + Email: farinacci@gmail.com |