<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-lisp-rfc8113bis-03" number="9304" ipr="trust200902" obsoletes="8113" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.2.1 -->
  <front>
    <title abbrev="LISP Packet Type Allocations">Locator/ID Separation
    Protocol (LISP): Shared Extension Message and IANA Registry for Packet
    Type Allocations</title>
    <seriesInfo name="RFC" value="9304"/>
    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>Orange</organization>
      <address>
        <postal>
          <street/>
          <city>Rennes</city>
          <code>35000</code>
          <country>France</country>
        </postal>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
      <organization>Orange</organization>
      <address>
        <postal>
          <street/>
          <city>Rennes</city>
          <code>35000</code>
          <country>France</country>
        </postal>
        <email>christian.jacquenet@orange.com</email>
      </address>
    </author>
    <date month="October" year="2022"/>
    <area>RTG</area>
    <workgroup>LISP</workgroup>
    <keyword>Shared Experiment Code</keyword>
    <keyword>LISP codepoints</keyword>
    <keyword>Experiment Identifier</keyword>
    <keyword>Experiment ID</keyword>
    <keyword>LISP Experimental Registry</keyword>
    <keyword>LISP Extension</keyword>
    <keyword>Extending LISP</keyword>
    <keyword>Exhausted LISP types</keyword>
    <keyword>LISP IANA</keyword>
    <keyword>IANA</keyword>
    <abstract>
      <t>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.</t>
      <t>This document obsoletes RFC 8113.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Locator/ID Separation Protocol (LISP) base specification, <xref target="RFC9301" format="default"/>, defines a set of primitives
      that are identified with a packet type code. Several extensions have
      been proposed to add more LISP functionalities. It is expected that
      additional LISP extensions will be proposed in the future.</t>
      <t>The "LISP Packet Types" IANA registry (see <xref target="iana" format="default"/>) is used to ease the tracking of LISP message
      types.</t>
      <t>Because of the limited type space <xref target="RFC9301" format="default"/> and the need to conduct
      experiments to assess new LISP extensions, this document specifies a
      shared LISP extension message type and describes a procedure for
      registering LISP shared extension sub-types (see <xref target="exp" format="default"/>). 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.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Requirements Language</name>
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
    </section>
    <section anchor="exp" numbered="true" toc="default">
      <name>LISP Shared Extension Message Type</name>
      <t><xref target="expf" format="default"/> depicts the common format of the LISP
      shared extension message. The type field <bcp14>MUST</bcp14> be set to 15 (see <xref target="iana" format="default"/>).</t>
      <figure anchor="expf">
        <name>LISP Shared Extension Message Type</name>
        <artwork name="" type="" align="center" alt=""><![CDATA[
 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                       //
//                                                             //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>The 'Sub-type' field conveys a unique identifier that <bcp14>MUST</bcp14> be
      registered with IANA (see <xref target="id" format="default"/>).</t>
      <t>The exact structure of the 'extension-specific' portion of the
      message is specified in the corresponding specification document.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document does not introduce any additional security issues other
      than those discussed in <xref target="RFC9301" format="default"/>.</t>
    </section>
    <section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="ptype" numbered="true" toc="default">
        <name>LISP Packet Types</name>
        <t>IANA has created a registry titled "LISP Packet Types",
        numbered 0-15.</t>
        <t>Values can be assigned via Standards Action <xref target="RFC8126" format="default"/>. Documents that request for a new LISP Packet
        Type may indicate a preferred value in the corresponding IANA
        sections.</t>
        <t>IANA has replaced the reference to RFC 8113 with the RFC
        number of this document.</t>
        <t>Also, IANA has updated the table as follows:</t>
	<t>OLD:</t>
	<table align="left">
	  <thead>
	    <tr>
	      <th>Message</th>
	      <th>Code</th>
	      <th>Reference</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      
	      <td>LISP Shared Extension Message</td>
	      <td>15</td>
	      <td>[RFC8113]</td>
	    </tr>
	  </tbody>
	</table>
	  
	    <t>NEW:</t>
	    <table align="left">
	      <thead>
		<tr>
		  <th>Message</th>
                  <th>Code</th>
		  <th>Reference</th>
		</tr>
	      </thead>
	      <tbody>
	     	<tr>
		  <td>LISP Shared Extension Message</td>
		  <td>15</td>
		  <td>RFC 9304</td>
		</tr>
	      </tbody>
	      
	    </table>
	    
	  </section>
		
      <section anchor="id" numbered="true" toc="default">
        <name>Sub-Types</name>
        <t>IANA has created the "LISP Shared Extension Message Type Sub-types"
        registry. IANA has updated that registry by replacing the
        reference to RFC 8113 with the RFC number of this
        document.</t>
        <t>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.</t>
        <t>The values in the range 1024-4095 are assigned on a First Come,
        First Served (FCFS) basis. The registration procedure is to 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.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Changes from RFC 8113</name>
      <t>The following changes were made from RFC 8113:</t>
      <ul spacing="normal">
        <li>Changed the status from Experimental to Standards Track.</li>
        <li>Indicated explicitly that the shared extension is used for two
          purposes: extend the type space and conduct experiments to assess
        new LISP extensions.</li>
        <li>Deleted pointers to some examples illustrating how the shared
          extension message is used to extend the LISP protocol.</li>
        <li>IANA has updated the "IANA LISP Packet Types" and "LISP
          Shared Extension Message Type Sub-types" registries to point to this
          document instead of RFC 8113.</li>
      </ul>
    </section>
  </middle>
  <back>
    <references>

      <name>Normative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

<reference anchor='RFC9301' target="https://www.rfc-editor.org/info/rfc9301">
<front>
<title>Locator/ID Separation Protocol (LISP) Control Plane</title>
<author initials='D' surname='Farinacci' fullname='Dino Farinacci'>
    <organization />
</author>
<author initials='F' surname='Maino' fullname='Fabio Maino'>
    <organization />
</author>
<author initials='V' surname='Fuller' fullname='Vince Fuller'>
    <organization />
</author>
<author initials='A' surname='Cabellos' fullname='Albert Cabellos' role='editor'>
    <organization />
</author>
<date month='October' year='2022' />
</front>
<seriesInfo name="RFC" value="9301"/>
<seriesInfo name="DOI" value="10.17487/RFC9301"/>
</reference>

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
    </references>
    
    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>This work is partly funded by ANR LISP-Lab project
      #ANR-13-INFR-009-X.</t>
      <t>Many thanks to <contact fullname="Luigi Iannone"/>, <contact fullname="Dino Farinacci"/>, and <contact fullname="Alvaro Retana"/> for
      the review.</t>
      <t>Thanks to <contact fullname="Geoff Huston"/>, <contact fullname="Brian Carpenter"/>, <contact fullname="Barry Leiba"/>, and <contact fullname="Suresh
      Krishnan"/> for the review.</t>
    </section>    
  </back>
</rfc>
