idnits 2.17.1 draft-ietf-lisp-vendor-lcaf-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The Vendor Specific LCAF type SHOULD not be used in deployments where different organizations interoperate. If a LISP device receives a LISP message containing a Vendor Specific LCAF with an OUI that it does not understand, it SHOULD drop the message and a log action MUST be taken. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 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 V. Ermagan 4 Intended status: Experimental A. Smirnov 5 Expires: August 20, 2018 V. Ashtaputre 6 Cisco Systems 7 D. Farinacci 8 lispers.net 9 2 16, 2018 11 Vendor Specific LCAF 12 draft-ietf-lisp-vendor-lcaf-01 14 Abstract 16 This document describes a new LCAF for LISP, the Vendor Specific 17 LCAF. This LCAF enables organizations to have internal encodings for 18 LCAF addresses. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 20, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 56 3. Vendor Specific LCAF . . . . . . . . . . . . . . . . . . . . 2 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 58 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 63 1. Introduction 65 The LISP Canonical Address Format [RFC8060] defines the format and 66 encoding for different address types that can be used on LISP 67 [RFC6830] deployments. However, certain deployments require specific 68 format encodings that may not be applicable outside of the use-case 69 for which they are defined. The Vendor Specific LCAF allows 70 organizations to create LCAF addresses to be used only internally on 71 particular LISP deployments. 73 2. Requirements Language 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119] 79 3. Vendor Specific LCAF 81 The Vendor Specific LCAF relies on using the IEEE Organizationally 82 Unique Identifier (OUI) [IEEE.802_2001] to prevent collisions across 83 vendors or organizations using the LCAF. The format of the Vendor 84 Specific LCAF is provided below. 86 0 1 2 3 87 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 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | AFI = 16387 | Rsvd1 | Flags | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | Type = 255 | Rsvd2 | Length | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | Rsvd3 | Organizationally Unique Identifier (OUI) | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Internal format... | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 Vendor Specific LCAF 100 The Vendor Specific LCAF has the following fields. 102 Rsvd3: This 8-bit field is reserved for future use. It MUST be 103 set to 0 on transmit and MUST be ignored on receipt. 105 Organizationally Unique Identifier (OUI): This is a 24-bit field 106 that carries the IEEE OUI [IEEE.802_2001] of the organization. 108 Internal format: This is a variable length field that is left 109 undefined on purpose. Each vendor or organization can define its 110 own internal format(s) to use with the Vendor Specific LCAF. 112 The definition for the rest of the fields can be found in [RFC8060]. 114 The Vendor Specific LCAF type SHOULD not be used in deployments where 115 different organizations interoperate. If a LISP device receives a 116 LISP message containing a Vendor Specific LCAF with an OUI that it 117 does not understand, it SHOULD drop the message and a log action MUST 118 be taken. 120 4. Security Considerations 122 This document enables organizations to define new LCAFs for their 123 internal use. It is the responsibility of these organizations to 124 properly assess the security implications of the formats they define. 126 5. Acknowledgments 128 The authors would like to thank Joel Halpern for his suggestions and 129 comments regarding this document. 131 6. IANA Considerations 133 Following the guidelines of [RFC5226], this document requests IANA to 134 update the "LISP Canonical Address Format (LCAF) Types" Registry 135 defined in [RFC8060] to allocate the following assignment: 137 +---------+---------------------+-----------+ 138 | Value # | LISP LCAF Type Name | Reference | 139 +---------+---------------------+-----------+ 140 | 255 | Vendor Specific | Section 3 | 141 +---------+---------------------+-----------+ 143 Table 1: Vendor Specific LCAF assignment 145 7. Normative References 147 [IEEE.802_2001] 148 IEEE, "IEEE Standard for Local and Metropolitan Area 149 Networks: Overview and Architecture", IEEE 802-2001, 150 DOI 10.1109/ieeestd.2002.93395, July 2002, 151 . 153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 154 Requirement Levels", BCP 14, RFC 2119, 155 DOI 10.17487/RFC2119, March 1997, 156 . 158 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 159 IANA Considerations Section in RFCs", RFC 5226, 160 DOI 10.17487/RFC5226, May 2008, 161 . 163 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 164 Locator/ID Separation Protocol (LISP)", RFC 6830, 165 DOI 10.17487/RFC6830, January 2013, 166 . 168 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 169 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 170 February 2017, . 172 Authors' Addresses 173 Alberto Rodriguez-Natal 174 Cisco Systems 175 170 Tasman Drive 176 San Jose, CA 177 USA 179 Email: natal@cisco.com 181 Vina Ermagan 182 Cisco Systems 183 170 Tasman Drive 184 San Jose, CA 185 USA 187 Email: vermagan@cisco.com 189 Anton Smirnov 190 Cisco Systems 191 170 Tasman Drive 192 San Jose, CA 193 USA 195 Email: asmirnov@cisco.com 197 Vrushali Ashtaputre 198 Cisco Systems 199 170 Tasman Drive 200 San Jose, CA 201 USA 203 Email: vrushali@cisco.com 205 Dino Farinacci 206 lispers.net 207 San Jose, CA 208 USA 210 Email: farinacci@gmail.com