idnits 2.17.1 draft-ietf-lisp-vendor-lcaf-09.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 30, 2021) is 1117 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-36 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: October 1, 2021 Google 6 A. Smirnov 7 V. Ashtaputre 8 Cisco 9 D. Farinacci 10 lispers.net 11 March 30, 2021 13 Vendor Specific LISP Canonical Address Format (LCAF) 14 draft-ietf-lisp-vendor-lcaf-09 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 October 1, 2021. 39 Copyright Notice 41 Copyright (c) 2021 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 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 58 3. Vendor Specific LCAF . . . . . . . . . . . . . . . . . . . . 2 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 The LISP Canonical Address Format (LCAF) [RFC8060] defines the format 68 and encoding for different address types that can be used on LISP 69 [I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6833bis] deployments. 70 However, certain deployments require specific format encodings that 71 may not be applicable outside of the use-case for which they are 72 defined. The Vendor Specific LCAF allows organizations to create 73 LCAF addresses to be used only internally on particular LISP 74 deployments. 76 2. Requirements Notation 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 80 "OPTIONAL" in this document are to be interpreted as described in BCP 81 14 [RFC2119] [RFC8174] when, and only when, they appear in all 82 capitals, as shown here. 84 3. Vendor Specific LCAF 86 The Vendor Specific LCAF relies on using the IEEE Organizationally 87 Unique Identifier (OUI) [IEEE.802_2001] to prevent collisions across 88 vendors or organizations using the LCAF. The format of the Vendor 89 Specific LCAF is provided below. 91 0 1 2 3 92 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 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | AFI = 16387 | Rsvd1 | Flags | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 | Type = 255 | Rsvd2 | Length | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | Rsvd3 | Organizationally Unique Identifier (OUI) | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Internal format... | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 Vendor Specific LCAF 105 The fields in the first 8 octets of the above Vendor Specific LCAF 106 are actually the fields defined in the general LCAF format specified 107 in [RFC8060]. The "Type" field MUST be set to the value 255 to 108 indicate that this is a Vendor Specific LCAF. The Length field has 109 to be set accordingly to the length of the internal format plus the 110 OUI plus the Rsvd3 fields as for [RFC8060]. The fields defined by 111 the Vendor Specific LCAF are: 113 Rsvd3: This 8-bit field is reserved for future use. It MUST be 114 set to 0 on transmit and MUST be ignored on receipt. 116 Organizationally Unique Identifier (OUI): This is a 24-bit field 117 that carries the IEEE OUI [IEEE.802_2001] of the organization. 119 Internal format: This is a variable length field that is left 120 undefined on purpose. Each vendor or organization can define its 121 own internal format(s) to use with the Vendor Specific LCAF. 123 The Vendor Specific LCAF type SHOULD NOT be used in deployments where 124 different organizations interoperate. However, there may be cases 125 where two (or more) organizations share a common deployment on which 126 they explicitly and mutually agree to use a particular Vendor 127 Specific LCAF. In that case, the organizations involved need to 128 carefully assess the interoperability concerns for that particular 129 deployment. 131 If a LISP device receives a LISP message containing a Vendor Specific 132 LCAF with an OUI that it does not understand, it MUST drop the 133 message and it SHOULD create a log message. 135 4. Security Considerations 137 This document enables organizations to define new LCAFs for their 138 internal use. It is the responsibility of these organizations to 139 properly assess the security implications of the formats they define. 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], this document requests IANA to 149 update the "LISP Canonical Address Format (LCAF) Types" Registry 150 defined in [RFC8060] to allocate the following assignment: 152 +---------+---------------------+-------------------------------+ 153 | Value # | LISP LCAF Type Name | Reference | 154 +---------+---------------------+-------------------------------+ 155 | 255 | Vendor Specific | Section 3 | 156 +---------+---------------------+-------------------------------+ 158 Table 1: Vendor Specific LCAF assignment 160 7. Normative References 162 [I-D.ietf-lisp-rfc6830bis] 163 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 164 Cabellos-Aparicio, "The Locator/ID Separation Protocol 165 (LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress), 166 November 2020. 168 [I-D.ietf-lisp-rfc6833bis] 169 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 170 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 171 Plane", draft-ietf-lisp-rfc6833bis-30 (work in progress), 172 November 2020. 174 [IEEE.802_2001] 175 IEEE, "IEEE Standard for Local and Metropolitan Area 176 Networks: Overview and Architecture", IEEE 802-2001, 177 DOI 10.1109/ieeestd.2002.93395, July 2002, 178 . 180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 181 Requirement Levels", BCP 14, RFC 2119, 182 DOI 10.17487/RFC2119, March 1997, 183 . 185 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 186 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 187 February 2017, . 189 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 190 Writing an IANA Considerations Section in RFCs", BCP 26, 191 RFC 8126, DOI 10.17487/RFC8126, June 2017, 192 . 194 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 195 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 196 May 2017, . 198 Authors' Addresses 200 Alberto Rodriguez-Natal 201 Cisco 202 San Jose, CA 203 USA 205 Email: natal@cisco.com 207 Vina Ermagan 208 Google 209 USA 211 Email: ermagan@gmail.com 213 Anton Smirnov 214 Cisco 215 Diegem 216 Belgium 218 Email: asmirnov@cisco.com 219 Vrushali Ashtaputre 220 Cisco 221 San Jose, CA 222 USA 224 Email: vrushali@cisco.com 226 Dino Farinacci 227 lispers.net 228 San Jose, CA 229 USA 231 Email: farinacci@gmail.com