idnits 2.17.1 draft-ietf-lisp-vendor-lcaf-05.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 (September 29, 2019) is 1664 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-27 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-25 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 Systems 4 Intended status: Experimental V. Ermagan 5 Expires: April 1, 2020 Google 6 A. Smirnov 7 V. Ashtaputre 8 Cisco Systems 9 D. Farinacci 10 lispers.net 11 September 29, 2019 13 Vendor Specific LISP Canonical Address Format (LCAF) 14 draft-ietf-lisp-vendor-lcaf-05 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 April 1, 2020. 39 Copyright Notice 41 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . 3 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 fields defined by 109 the Vendor Specific LCAF are: 111 Rsvd3: This 8-bit field is reserved for future use. It MUST be 112 set to 0 on transmit and MUST be ignored on receipt. 114 Organizationally Unique Identifier (OUI): This is a 24-bit field 115 that carries the IEEE OUI [IEEE.802_2001] of the organization. 117 Internal format: This is a variable length field that is left 118 undefined on purpose. Each vendor or organization can define its 119 own internal format(s) to use with the Vendor Specific LCAF. 121 The Vendor Specific LCAF type SHOULD NOT be used in deployments where 122 different organizations interoperate. However, there may be cases 123 where two (or more) organizations share a common deployment on which 124 they explicitly and mutually agree to use a particular Vendor 125 Specific LCAF. In that case, the organizations involved need to 126 carefully assess the interoperability concerns for that particular 127 deployment. 129 If a LISP device receives a LISP message containing a Vendor Specific 130 LCAF with an OUI that it does not understand, it MUST drop the 131 message. 133 4. Security Considerations 135 This document enables organizations to define new LCAFs for their 136 internal use. It is the responsibility of these organizations to 137 properly assess the security implications of the formats they define. 139 5. Acknowledgments 141 The authors would like to thank Joel Halpern and Luigi Iannone for 142 their suggestions and guidance regarding this document. 144 6. IANA Considerations 146 Following the guidelines of [RFC8126], this document requests IANA to 147 update the "LISP Canonical Address Format (LCAF) Types" Registry 148 defined in [RFC8060] to allocate the following assignment: 150 +---------+---------------------+------------+ 151 | Value # | LISP LCAF Type Name | Reference | 152 +---------+---------------------+------------+ 153 | 255 | Vendor Specific | Section 3 | 154 +---------+---------------------+------------+ 156 Table 1: Vendor Specific LCAF assignment 158 7. Normative References 160 [I-D.ietf-lisp-rfc6830bis] 161 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 162 Cabellos-Aparicio, "The Locator/ID Separation Protocol 163 (LISP)", draft-ietf-lisp-rfc6830bis-27 (work in progress), 164 June 2019. 166 [I-D.ietf-lisp-rfc6833bis] 167 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 168 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 169 Plane", draft-ietf-lisp-rfc6833bis-25 (work in progress), 170 June 2019. 172 [IEEE.802_2001] 173 IEEE, "IEEE Standard for Local and Metropolitan Area 174 Networks: Overview and Architecture", IEEE 802-2001, 175 DOI 10.1109/ieeestd.2002.93395, July 2002, 176 . 178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels", BCP 14, RFC 2119, 180 DOI 10.17487/RFC2119, March 1997, 181 . 183 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 184 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 185 February 2017, . 187 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 188 Writing an IANA Considerations Section in RFCs", BCP 26, 189 RFC 8126, DOI 10.17487/RFC8126, June 2017, 190 . 192 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 193 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 194 May 2017, . 196 Authors' Addresses 198 Alberto Rodriguez-Natal 199 Cisco Systems 200 San Jose, CA 201 USA 203 Email: natal@cisco.com 205 Vina Ermagan 206 Google 207 USA 209 Email: ermagan@gmail.com 211 Anton Smirnov 212 Cisco Systems 213 Diegem 214 Belgium 216 Email: asmirnov@cisco.com 218 Vrushali Ashtaputre 219 Cisco Systems 220 San Jose, CA 221 USA 223 Email: vrushali@cisco.com 225 Dino Farinacci 226 lispers.net 227 San Jose, CA 228 USA 230 Email: farinacci@gmail.com