idnits 2.17.00 (12 Aug 2021) /tmp/idnits41502/draft-ietf-lisp-vendor-lcaf-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (12 April 2022) is 32 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- No information found for draft-ietf-lisp-rfc6830bis - is the name correct? -- No information found for draft-ietf-lisp-rfc6833bis - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group A. Rodriguez-Natal 3 Internet-Draft Cisco 4 Intended status: Experimental V. Ermagan 5 Expires: 14 October 2022 Google 6 A. Smirnov 7 V. Ashtaputre 8 Cisco 9 D. Farinacci 10 lispers.net 11 12 April 2022 13 Vendor Specific LISP Canonical Address Format (LCAF) 14 draft-ietf-lisp-vendor-lcaf-10 16 Abstract 18 This document describes a new LISP Canonical Address Format (LCAF), 19 the Vendor Specific LCAF. This LCAF enables organizations to have 20 internal encodings for LCAF addresses. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 14 October 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 57 3. Vendor Specific LCAF . . . . . . . . . . . . . . . . . . . . 2 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 The LISP Canonical Address Format (LCAF) [RFC8060] defines the format 67 and encoding for different address types that can be used on LISP 68 [I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6833bis] deployments. 69 However, certain deployments require specific format encodings that 70 may not be applicable outside of the use-case for which they are 71 defined. This document updates [RFC8060] to introduce a Vendor 72 Specific LCAF that defines how organizations can create LCAF 73 addresses to be used only internally on particular LISP deployments. 75 2. Requirements Notation 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 79 "OPTIONAL" in this document are to be interpreted as described in BCP 80 14 [RFC2119] [RFC8174] when, and only when, they appear in all 81 capitals, as shown here. 83 3. Vendor Specific LCAF 85 The Vendor Specific LCAF relies on using the IEEE Organizationally 86 Unique Identifier (OUI) [IEEE.802_2001] to prevent collisions across 87 vendors or organizations using the LCAF. The format of the Vendor 88 Specific LCAF is provided below. 90 0 1 2 3 91 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 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | AFI = 16387 | Rsvd1 | Flags | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Type = TBD | Rsvd2 | Length | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Rsvd3 | Organizationally Unique Identifier (OUI) | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Internal format... | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 Figure 1: Vendor Specific LCAF 104 The fields in the first 8 octets of the above Vendor Specific LCAF 105 are actually the fields defined in the general LCAF format specified 106 in [RFC8060]. The "Type" field MUST be set to the value 255 to 107 indicate that this is a Vendor Specific LCAF. The Length field has 108 to be set accordingly to the length of the internal format plus the 109 OUI plus the Rsvd3 fields as for [RFC8060]. The fields defined by 110 the Vendor Specific LCAF are: 112 Rsvd3: This 8-bit field is reserved for future use. It MUST be 113 set to 0 on transmit and MUST be ignored on receipt. 115 Organizationally Unique Identifier (OUI): This is a 24-bit field 116 that carries the IEEE OUI [IEEE.802_2001] of the organization. 118 Internal format: This is a variable length field that is left 119 undefined on purpose. Each vendor or organization can define its 120 own internal format(s) to use with the Vendor Specific LCAF. 122 The Vendor Specific LCAF type SHOULD NOT be used in deployments where 123 different organizations interoperate. However, there may be cases 124 where two (or more) organizations share a common deployment on which 125 they explicitly and mutually agree to use a particular Vendor 126 Specific LCAF. In that case, the organizations involved need to 127 carefully assess the interoperability concerns for that particular 128 deployment. 130 If a LISP device receives a LISP message containing a Vendor Specific 131 LCAF with an OUI that it does not understand, it MUST drop the 132 message and it SHOULD create a log message. 134 4. Security Considerations 136 This document enables organizations to define new LCAFs for their 137 internal use. It is the responsibility of these organizations to 138 properly assess the security implications of the formats they define. 139 Security considerations from [RFC8060] apply to this document. 141 5. Acknowledgments 143 The authors would like to thank Joel Halpern and Luigi Iannone for 144 their suggestions and guidance regarding this document. 146 6. IANA Considerations 148 Following the guidelines of [RFC8126], IANA is asked to assign a 149 value (255 is suggested) for the Vendor Specific LCAF from the "LISP 150 Canonical Address Format (LCAF) Types" registry (defined in 151 [RFC8060]) as follows: 153 +=========+=====================+============================+ 154 | Value # | LISP LCAF Type Name | Reference | 155 +=========+=====================+============================+ 156 | TBD | Vendor Specific | [This Document], Section 3 | 157 +---------+---------------------+----------------------------+ 159 Table 1: Vendor Specific LCAF assignment 161 7. Normative References 163 [I-D.ietf-lisp-rfc6830bis] 164 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 165 Cabellos, "The Locator/ID Separation Protocol (LISP)", 166 Work in Progress, Internet-Draft, draft-ietf-lisp- 167 rfc6830bis-36, 18 November 2020, 168 . 171 [I-D.ietf-lisp-rfc6833bis] 172 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 173 "Locator/ID Separation Protocol (LISP) Control-Plane", 174 Work in Progress, Internet-Draft, draft-ietf-lisp- 175 rfc6833bis-30, 18 November 2020, 176 . 179 [IEEE.802_2001] 180 IEEE, "IEEE Standard for Local and Metropolitan Area 181 Networks: Overview and Architecture", IEEE 802-2001, 182 DOI 10.1109/ieeestd.2002.93395, 27 July 2002, 183 . 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, 187 DOI 10.17487/RFC2119, March 1997, 188 . 190 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 191 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 192 February 2017, . 194 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 195 Writing an IANA Considerations Section in RFCs", BCP 26, 196 RFC 8126, DOI 10.17487/RFC8126, June 2017, 197 . 199 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 200 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 201 May 2017, . 203 Authors' Addresses 205 Alberto Rodriguez-Natal 206 Cisco 207 Spain 208 Email: natal@cisco.com 210 Vina Ermagan 211 Google 212 United States of America 213 Email: ermagan@gmail.com 215 Anton Smirnov 216 Cisco 217 Diegem 218 Belgium 219 Email: asmirnov@cisco.com 220 Vrushali Ashtaputre 221 Cisco 222 San Jose, CA 223 United States of America 224 Email: vrushali@cisco.com 226 Dino Farinacci 227 lispers.net 228 San Jose, CA 229 United States of America 230 Email: farinacci@gmail.com