idnits 2.17.1 draft-ietf-lisp-rfc8113bis-03.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 (January 25, 2019) is 1910 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC8113' is mentioned on line 144, but not defined ** Obsolete undefined reference: RFC 8113 (Obsoleted by RFC 9304) == Missing Reference: 'ThisDocument' is mentioned on line 149, but not defined == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-23 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP M. Boucadair 3 Internet-Draft C. Jacquenet 4 Obsoletes: 8113 (if approved) Orange 5 Intended status: Standards Track January 25, 2019 6 Expires: July 29, 2019 8 Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA 9 Registry for Packet Type Allocations 10 draft-ietf-lisp-rfc8113bis-03 12 Abstract 14 This document specifies a Locator/ID Separation Protocol (LISP) 15 shared message type for defining future extensions and conducting 16 experiments without consuming a LISP packet type codepoint for each 17 extension. 19 This document obsoletes RFC 8113. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 29, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 57 3. LISP Shared Extension Message Type . . . . . . . . . . . . . 3 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 60 5.1. LISP Packet Types . . . . . . . . . . . . . . . . . . . . 3 61 5.2. Sub-Types . . . . . . . . . . . . . . . . . . . . . . . . 4 62 6. Changes from RFC 8113 . . . . . . . . . . . . . . . . . . . . 4 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 64 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 The Locator/ID Separation Protocol (LISP) base specification, 70 [I-D.ietf-lisp-rfc6833bis], defines a set of primitives that are 71 identified with a packet type code. Several extensions have been 72 proposed to add more LISP functionalities. It is expected that 73 additional LISP extensions will be proposed in the future. 75 The "LISP Packet Types" IANA registry (see Section 5) is used to ease 76 the tracking of LISP message types. 78 Because of the limited type space [I-D.ietf-lisp-rfc6833bis] and the 79 need to conduct experiments to assess new LISP extensions, this 80 document specifies a shared LISP extension message type and describes 81 a procedure for registering LISP shared extension sub-types (see 82 Section 3). Concretely, one single LISP message type code is 83 dedicated to future LISP extensions; sub-types are used to uniquely 84 identify a given LISP extension making use of the shared LISP 85 extension message type. These identifiers are selected by the 86 author(s) of the corresponding LISP specification that introduces a 87 new LISP extension message type. 89 2. Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119][RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 3. LISP Shared Extension Message Type 99 Figure 1 depicts the common format of the LISP shared extension 100 message. The type field MUST be set to 15 (see Section 5). 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 |Type=15| Sub-type | extension-specific | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 // extension-specific // 108 // // 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 Figure 1: LISP Shared Extension Message Type 113 The "Sub-type" field conveys a unique identifier that MUST be 114 registered with IANA (see Section 5.2). 116 The exact structure of the 'extension-specific' portion of the 117 message is specified in the corresponding specification document. 119 4. Security Considerations 121 This document does not introduce any additional security issues other 122 than those discussed in [I-D.ietf-lisp-rfc6833bis]. 124 5. IANA Considerations 126 5.1. LISP Packet Types 128 IANA has created a protocol registry for LISP Packet Types, numbered 129 0-15. 131 Values can be assigned via Standards Action [RFC8126]. Documents 132 that request for a new LISP packet type may indicate a preferred 133 value in the corresponding IANA sections. 135 IANA is requested to replace the reference to RFC8113 with the RFC 136 number to be assigned to this document. 138 Also, IANA is requested to update the table as follows: 140 OLD: 142 Message Code Reference 143 ================================= ==== =============== 144 LISP Shared Extension Message 15 [RFC8113] 146 NEW: 147 Message Code Reference 148 ================================= ==== =============== 149 LISP Shared Extension Message 15 [ThisDocument] 151 5.2. Sub-Types 153 IANA has created the "LISP Shared Extension Message Type Sub-types" 154 registry. IANA is requested to update that registry by replacing the 155 reference to RFC8113 with the RFC number to be assigned to this 156 document. 158 The values in the range 0-1023 are assigned via Standards Action. 159 This range is provisioned to anticipate, in particular, the 160 exhaustion of the LISP Packet types. 162 The values in the range 1024-4095 are assigned on a First Come, First 163 Served (FCFS) basis. The registration procedure should provide IANA 164 with the desired codepoint and a point of contact; providing a short 165 description (together with an acronym, if relevant) of the foreseen 166 usage of the extension message is also encouraged. 168 6. Changes from RFC 8113 170 The following changes were made from RFC 8113: 172 o Change the status from Experimental to Standard track. 174 o Indicate explicitly that the shared extension is used for two 175 purposes: extend the type space and conduct experiments to assess 176 new LISP extensions. 178 o Delete pointers to some examples illustrating how the shared 179 extension message is used to extend the LISP protocol. 181 o Request IANA to update the "IANA LISP Packet Types" and "LISP 182 Shared Extension Message Type Sub-types" registries to point to 183 this document instead of RFC8113. 185 7. Acknowledgments 187 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 188 009-X. 190 Many thanks to Luigi Iannone, Dino Farinacci, and Alvaro Retana for 191 the review. 193 Thanks to Geoff Huston, Brian Carpenter, Barry Leiba, and Suresh 194 Krishnan for the review. 196 8. Normative References 198 [I-D.ietf-lisp-rfc6833bis] 199 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 200 "Locator/ID Separation Protocol (LISP) Control-Plane", 201 draft-ietf-lisp-rfc6833bis-23 (work in progress), December 202 2018. 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, 206 DOI 10.17487/RFC2119, March 1997, 207 . 209 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 210 Writing an IANA Considerations Section in RFCs", BCP 26, 211 RFC 8126, DOI 10.17487/RFC8126, June 2017, 212 . 214 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 215 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 216 May 2017, . 218 Authors' Addresses 220 Mohamed Boucadair 221 Orange 222 Rennes 35000 223 France 225 EMail: mohamed.boucadair@orange.com 226 Christian Jacquenet 227 Orange 228 Rennes 35000 229 France 231 EMail: christian.jacquenet@orange.com