idnits 2.17.1 draft-ietf-lisp-type-iana-04.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 (November 30, 2016) is 2702 days in the past. Is this intentional? 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) == Outdated reference: A later version (-07) exists of draft-boucadair-lisp-bulk-03 == Outdated reference: A later version (-05) exists of draft-boucadair-lisp-subscribe-03 == Outdated reference: A later version (-19) exists of draft-ermagan-lisp-nat-traversal-11 == Outdated reference: A later version (-09) exists of draft-ietf-lisp-ddt-08 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Experimental Orange 5 Expires: June 3, 2017 November 30, 2016 7 LISP Shared Extension Message & IANA Registry for LISP Packet Type 8 Allocations 9 draft-ietf-lisp-type-iana-04 11 Abstract 13 This document defines a registry for LISP Packet Type allocations. 14 It also specifies a LISP shared message type for defining future 15 extensions and conducting experiments without consuming a LISP packet 16 type codepoint for each extension. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 3, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. LISP Shared Extension Message Type . . . . . . . . . . . . . 3 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 62 4.1. LISP Packet Types . . . . . . . . . . . . . . . . . . . . 3 63 4.2. Sub-Types . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 6.1. Normative references . . . . . . . . . . . . . . . . . . 4 67 6.2. Informative References . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 The Locator/ID Separation Protocol (LISP, [RFC6830] ) base 73 specification defines a set of primitives that are identified with a 74 packet type code. Several extensions have been proposed to add more 75 LISP functionalities. For example, new message types are proposed in 76 [I-D.ietf-lisp-ddt], [I-D.zhao-lisp-mn-extension], 77 [I-D.boucadair-lisp-bulk], [I-D.ermagan-lisp-nat-traversal], or 78 [I-D.boucadair-lisp-subscribe]. It is expected that additional LISP 79 extensions will be proposed in the future. 81 In order to ease the tracking of LISP message types, this document 82 proposes to create a "LISP Packet Types" IANA registry (see 83 Section 4). 85 Because of the limited type space [RFC6830] and the need to conduct 86 experiments to assess new LISP extensions, this document specifies a 87 shared LISP extension message type and proposes a procedure for 88 registering LISP shared extension sub-types (see Section 2). 89 Concretely, one single LISP message type code is dedicated to future 90 LISP extensions; sub-types are used to uniquely identify a given LISP 91 extension making use of the shared LISP extension message type. 92 These identifiers are selected by the author(s) of the corresponding 93 LISP specification that introduces a new LISP extension message type. 95 2. LISP Shared Extension Message Type 97 Figure 1 depicts the common format of the LISP shared extension 98 message. The type field MUST be set to 15 (see Section 4). 100 0 1 2 3 101 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 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 |Type=15| Sub-type | extension-specific | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 // extension-specific // 106 // // 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 Figure 1: LISP Shared Extension Message Type 111 The "Sub-type" field conveys a unique identifier that is assigned on 112 a First Come, First Served (FCFS) basis [RFC5226]. These identifiers 113 are registered with IANA (see Section 4.2). 115 The exact structure of the 'extension-specific' portion of the 116 message is specified in the corresponding specification document. 118 3. Security Considerations 120 This document does not introduce any additional security issues other 121 than those discussed in [RFC6830]. 123 4. IANA Considerations 125 4.1. LISP Packet Types 127 IANA is requested to create a new protocol registry for LISP Packet 128 Types, numbered 0-15. The registry must be initially populated with 129 the following values: 131 Message Code Reference 132 ================================= ==== =============== 133 Reserved 0 [RFC6830] 134 LISP Map-Request 1 [RFC6830] 135 LISP Map-Reply 2 [RFC6830] 136 LISP Map-Register 3 [RFC6830] 137 LISP Map-Notify 4 [RFC6830] 138 LISP Encapsulated Control Message 8 [RFC6830] 139 LISP Shared Extension Message 15 [This document] 140 The values in the ranges 5-7 and 9-14 can be assigned via Standards 141 Action [RFC5226]. Documents that request for a new LISP packet type 142 may indicate a preferred value in the corresponding IANA sections. 144 The value 15 is reserved for Experimental Use [RFC5226]. 146 4.2. Sub-Types 148 IANA is requested to create a "LISP Shared Extension Message type 149 Sub-types" registry. No initial values are assigned at the creation 150 of the registry; (0-4095) are available for future assignments. 152 Entries are assigned on a FCFS basis. 154 The registration procedure should provide IANA with the desired 155 codepoint and a point of contact. Providing a short description 156 (together with an acronym, if relevant) of the foreseen usage of the 157 extension message is also encouraged. 159 5. Acknowledgments 161 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 162 009-X. 164 Many thanks to Luigi Iannone and Dino Farinacci for the review. 166 Thanks to Geoff Huston for the RtgDir directorate review. 168 6. References 170 6.1. Normative references 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, 174 DOI 10.17487/RFC2119, March 1997, 175 . 177 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 178 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 179 DOI 10.17487/RFC5226, May 2008, 180 . 182 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 183 Locator/ID Separation Protocol (LISP)", RFC 6830, 184 DOI 10.17487/RFC6830, January 2013, 185 . 187 6.2. Informative References 189 [I-D.boucadair-lisp-bulk] 190 Boucadair, M. and C. Jacquenet, "LISP Mapping Bulk 191 Retrieval", draft-boucadair-lisp-bulk-03 (work in 192 progress), July 2016. 194 [I-D.boucadair-lisp-subscribe] 195 Boucadair, M. and C. Jacquenet, "LISP Subscription", 196 draft-boucadair-lisp-subscribe-03 (work in progress), July 197 2016. 199 [I-D.ermagan-lisp-nat-traversal] 200 Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, 201 F., and C. White, "NAT traversal for LISP", draft-ermagan- 202 lisp-nat-traversal-11 (work in progress), August 2016. 204 [I-D.ietf-lisp-ddt] 205 Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 206 Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- 207 ddt-08 (work in progress), September 2016. 209 [I-D.zhao-lisp-mn-extension] 210 Wang, J., Meng, Y., and N. Zhao, "LISP Mobile Node 211 extension", draft-zhao-lisp-mn-extension-02 (work in 212 progress), October 2011. 214 Authors' Addresses 216 Mohamed Boucadair 217 Orange 218 Rennes 35000 219 France 221 EMail: mohamed.boucadair@orange.com 223 Christian Jacquenet 224 Orange 225 Rennes 35000 226 France 228 EMail: christian.jacquenet@orange.com