Movatterモバイル変換

Internet Engineering Task Force (IETF)                      M. BoucadairRequest for Comments: 8113                                  C. JacquenetUpdates:6830                                                     OrangeCategory: Experimental                                        March 2017ISSN: 2070-1721Locator/ID Separation Protocol (LISP):Shared Extension Message & IANA Registry for Packet Type AllocationsAbstract   This document specifies a Locator/ID Separation Protocol (LISP)   shared message type for defining future extensions and conducting   experiments without consuming a LISP packet type codepoint for each   extension.  It also defines a registry for LISP Packet Type   allocations, thus updatingRFC 6830.Status of This Memo   This document is not an Internet Standards Track specification; it is   published for examination, experimental implementation, and   evaluation.   This document defines an Experimental Protocol for the Internet   community.  This document is a product of the Internet Engineering   Task Force (IETF).  It represents the consensus of the IETF   community.  It has received public review and has been approved for   publication by the Internet Engineering Steering Group (IESG).  Not   all documents approved by the IESG are a candidate for any level of   Internet Standard; seeSection 2 of RFC 7841.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc8113.Boucadair & Jacquenet         Experimental                      [Page 1]

RFC 8113              LISP Packet Type Allocations            March 2017Copyright Notice   Copyright (c) 2017 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents   (http://trustee.ietf.org/license-info) in effect on the date of   publication of this document.  Please review these documents   carefully, as they describe your rights and restrictions with respect   to this document.  Code Components extracted from this document must   include Simplified BSD License text as described in Section 4.e of   the Trust Legal Provisions and are provided without warranty as   described in the Simplified BSD License.Table of Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .22.  Requirements Language . . . . . . . . . . . . . . . . . . . .33.  LISP Shared Extension Message Type  . . . . . . . . . . . . .34.  Security Considerations . . . . . . . . . . . . . . . . . . .35.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .45.1.  LISP Packet Types . . . . . . . . . . . . . . . . . . . .45.2.  Sub-Types . . . . . . . . . . . . . . . . . . . . . . . .46.  References  . . . . . . . . . . . . . . . . . . . . . . . . .56.1.  Normative References  . . . . . . . . . . . . . . . . . .56.2.  Informative References  . . . . . . . . . . . . . . . . .5   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .6   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .61.  Introduction   The Locator/ID Separation Protocol (LISP) base specification,   [RFC6830], defines a set of primitives that are identified with a   packet type code.  Several extensions have been proposed to add more   LISP functionalities.  For example, new message types are proposed in   [LISP-DDT], [LISP-MN-EXT], [LISP-BULK], [NAT-LISP], or   [LISP-SUBSCRIBE].  It is expected that additional LISP extensions   will be proposed in the future.   In order to ease the tracking of LISP message types, this document   proposes to create a "LISP Packet Types" IANA registry (seeSection 5).   Because of the limited type space [RFC6830] and the need to conduct   experiments to assess new LISP extensions, this document specifies a   shared LISP extension message type and proposes a procedure for   registering LISP shared extension sub-types (seeSection 3).Boucadair & Jacquenet         Experimental                      [Page 2]

RFC 8113              LISP Packet Type Allocations            March 2017   Concretely, one single LISP message type code is dedicated to future   LISP extensions; sub-types are used to uniquely identify a given LISP   extension making use of the shared LISP extension message type.   These identifiers are selected by the author(s) of the corresponding   LISP specification that introduces a new LISP extension message type.2.  Requirements Language   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described in [RFC2119].3.  LISP Shared Extension Message Type   Figure 1 depicts the common format of the LISP shared extension   message.  The type field MUST be set to 15 (seeSection 5).        0                   1                   2                   3        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       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |Type=15|        Sub-type       |   extension-specific          |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       //                    extension-specific                       //       //                                                             //       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               Figure 1: LISP Shared Extension Message Type   The "Sub-type" field conveys a unique identifier that MUST be   registered with IANA (seeSection 5.2).   The exact structure of the 'extension-specific' portion of the   message is specified in the corresponding specification document.4.  Security Considerations   This document does not introduce any additional security issues other   than those discussed in [RFC6830].Boucadair & Jacquenet         Experimental                      [Page 3]

RFC 8113              LISP Packet Type Allocations            March 20175.  IANA Considerations5.1.  LISP Packet Types   IANA has created a new protocol registry for LISP Packet Types,   numbered 0-15.  The registry is initially populated with the   following values:   Message                           Code    Reference   ================================= ==== ===============   Reserved                           0      [RFC6830]   LISP Map-Request                   1      [RFC6830]   LISP Map-Reply                     2      [RFC6830]   LISP Map-Register                  3      [RFC6830]   LISP Map-Notify                    4      [RFC6830]   LISP Encapsulated Control Message  8      [RFC6830]   LISP Shared Extension Message     15      [RFC8113]   The values in the ranges 5-7 and 9-14 can be assigned via Standards   Action [RFC5226].  Documents that request for a new LISP packet type   may indicate a preferred value in the corresponding IANA sections.5.2.  Sub-Types   IANA has created the "LISP Shared Extension Message Type Sub-types"   registry.  No initial values are assigned at the creation of the   registry; (0-4095) are available for future assignments.   The values in the range 0-1023 are assigned via Standards Action.   This range is provisioned to anticipate, in particular, the   exhaustion of the LISP Packet types.   The values in the range 1024-4095 are assigned on a First Come, First   Served (FCFS) basis.  The registration procedure should provide IANA   with the desired codepoint and a point of contact; providing a short   description (together with an acronym, if relevant) of the foreseen   usage of the extension message is also encouraged.Boucadair & Jacquenet         Experimental                      [Page 4]

RFC 8113              LISP Packet Type Allocations            March 20176.  References6.1.  Normative References   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels",BCP 14,RFC 2119,              DOI 10.17487/RFC2119, March 1997,              <http://www.rfc-editor.org/info/rfc2119>.   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an              IANA Considerations Section in RFCs",BCP 26,RFC 5226,              DOI 10.17487/RFC5226, May 2008,              <http://www.rfc-editor.org/info/rfc5226>.   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The              Locator/ID Separation Protocol (LISP)",RFC 6830,              DOI 10.17487/RFC6830, January 2013,              <http://www.rfc-editor.org/info/rfc6830>.6.2.  Informative References   [LISP-BULK]              Boucadair, M. and C. Jacquenet, "LISP Mapping Bulk              Retrieval", Work in Progress,draft-boucadair-lisp-bulk-04, February 2017.   [LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.              Smirnov, "LISP Delegated Database Tree", Work in              Progress,draft-ietf-lisp-ddt-09, January 2017.   [LISP-MN-EXT]              Wang, J., Meng, Y., and N. Zhao, "LISP Mobile Node              extension", Work in Progress,draft-zhao-lisp-mn-extension-02, October 2011.   [LISP-SUBSCRIBE]              Boucadair, M. and C. Jacquenet,"LISP Subscription", Work              in Progress,draft-boucadair-lisp-subscribe-04, February              2017.   [NAT-LISP] Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,              F., and C. White, "NAT traversal for LISP", Work in              Progress,draft-ermagan-lisp-nat-traversal-11, August              2016.Boucadair & Jacquenet         Experimental                      [Page 5]

RFC 8113              LISP Packet Type Allocations            March 2017Acknowledgments   This work is partly funded by ANR LISP-Lab project #ANR-13-INFR-   009-X.   Many thanks to Luigi Iannone, Dino Farinacci, and Alvaro Retana for   the review.   Thanks to Geoff Huston for the RtgDir directorate review.Authors' Addresses   Mohamed Boucadair   Orange   Rennes  35000   France   Email: mohamed.boucadair@orange.com   Christian Jacquenet   Orange   Rennes  35000   France   Email: christian.jacquenet@orange.comBoucadair & Jacquenet         Experimental                      [Page 6]