<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYRFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYRFC8060 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8060.xml">zwsp "​"> <!ENTITYRFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">nbhy "‑"> <!ENTITYRFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY I-D.ietf-lisp-rfc6833bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-rfc6833bis.xml"> <!ENTITY I-D.ietf-lisp-rfc6830bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-rfc6830bis.xml">wj "⁠"> ]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <?rfc strict="yes" ?> <?rfc toc="yes"?> <?rfc tocdepth="4"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes" ?> <?rfc compact="yes" ?> <?rfc subcompact="no" ?><rfccategory="exp"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-lisp-vendor-lcaf-12" number="9306" ipr="trust200902"updates="8060">updates="8060" obsoletes="" submissionType="IETF" category="exp" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.13.0 --> <front> <titleabbrev="LISP-Vendor-LCAF">Vendor Specificabbrev="Vendor-Specific LCAF">Vendor-Specific LISP Canonical Address Format (LCAF)</title> <seriesInfo name="RFC" value="9306"/> <author fullname="Alberto Rodriguez-Natal" initials="A." surname="Rodriguez-Natal"> <organization>Cisco</organization> <address> <postal><street></street> <city></city> <region></region> <code></code><street/> <city/> <region/> <code/> <country>Spain</country> </postal><phone></phone><phone/> <email>natal@cisco.com</email> </address> </author> <author fullname="Vina Ermagan" initials="V." surname="Ermagan"><organization>Google</organization><organization>Google, Inc.</organization> <address> <postal><street></street> <city></city> <region></region> <code></code> <country>USA</country><street>1600 Amphitheatre Parkway</street> <city>Mountain View</city> <region>CA</region> <code>94043</code> <country>United States of America</country> </postal><phone></phone><phone/> <email>ermagan@gmail.com</email> </address> </author> <author fullname="Anton Smirnov" initials="A." surname="Smirnov"> <organization>Cisco</organization> <address> <postal><street></street><street/> <city>Diegem</city><region></region> <code></code><region/> <code/> <country>Belgium</country> </postal><phone></phone><phone/> <email>asmirnov@cisco.com</email> </address> </author> <author fullname="Vrushali Ashtaputre" initials="V." surname="Ashtaputre"> <organization>Cisco</organization> <address> <postal><street></street><street/> <city>San Jose</city> <region>CA</region><code></code> <country>USA</country><code/> <country>United States of America</country> </postal><phone></phone><phone/> <email>vrushali@cisco.com</email> </address> </author> <author fullname="Dino Farinacci" initials="D." surname="Farinacci"> <organization>lispers.net</organization> <address> <postal><street></street><street/> <city>San Jose</city> <region>CA</region><code></code> <country>USA</country><code/> <country>United States of America</country> </postal><phone></phone><phone/> <email>farinacci@gmail.com</email> </address> </author> <dateyear="2022"/> <area>Internet</area> <workgroup>LISP Working Group</workgroup> <keyword>lisp, lcaf, internal, domain, organization, private</keyword>year="2022" month="October"/> <area>RTG</area> <workgroup>LISP</workgroup> <keyword>lisp</keyword> <keyword>lcaf</keyword> <keyword>internal</keyword> <keyword>domain</keyword> <keyword>organization</keyword> <keyword>private</keyword> <abstract> <t>This document describes a new Locator/ID Separation Protocol (LISP) Canonical Address Format (LCAF), theVendor SpecificVendor-Specific LCAF. This LCAF enables organizations to have implementation-specific encodings for LCAF addresses. This document updatesRFC8060.</t>RFC 8060.</t> </abstract> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>The LISP Canonical Address Format (LCAF) <xreftarget="RFC8060"></xref>target="RFC8060" format="default"/> defines the format and encoding for different address types that can be used onLISPdeployments of the Locator/ID Separation Protocol (LISP) <xreftarget="I-D.ietf-lisp-rfc6830bis"></xref>target="RFC9300" format="default"/> <xreftarget="I-D.ietf-lisp-rfc6833bis"></xref> deployments.target="RFC9301" format="default"/>. However, certain deployments require specific format encodings that may not be applicable outside of theuse-caseuse case for which they are defined. This document extends <xreftarget="RFC8060"></xref>target="RFC8060" format="default"/> to introduce aVendor SpecificVendor-Specific LCAF that defines how organizations can create LCAF addresses to be used only on particular LISP implementations. This document also updates <xreftarget="RFC8060"></xref>target="RFC8060" format="default"/> to specify the behavior when receiving unrecognized LCAFTypes.</t>types.</t> </section> <sectiontitle="Requirements Notation"> <t>Thenumbered="true" toc="default"> <name>Requirements Notation</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<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"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119"></xref>target="RFC2119"/> <xreftarget="RFC8174"></xref>target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> <sectiontitle="Unrecognizednumbered="true" toc="default"> <name>Unrecognized LCAFtypes">Types</name> <t><xreftarget="RFC8060"></xref>target="RFC8060" format="default"/> does not explain how an implementation should handle an unrecognized LCAFType.type. This document updates <xreftarget="RFC8060"></xref>target="RFC8060" format="default"/> to specify that any unrecognized LCAFTypetype received in a LISP control plane messageMUST<bcp14>MUST</bcp14> be ignored. If all Locators are ignored, this is equivalent to a LISP control message with Locator Count = 0, as described in <xreftarget="I-D.ietf-lisp-rfc6833bis"></xref>.target="RFC9301" format="default"/>. If an EID-Prefix only contains unrecognized LCAFTypes,types, the LISP control messageMUST<bcp14>MUST</bcp14> be dropped and the eventMUST<bcp14>MUST</bcp14> belogged.</t>logged. (Here, "EID" refers to Endpoint Identifier.)</t> </section> <section anchor="vendor-lcaf"title="Vendor Specific LCAF">numbered="true" toc="default"> <name>Vendor-Specific LCAF</name> <t> TheVendor SpecificVendor-Specific LCAF relies on using the IEEE Organizationally Unique Identifier (OUI) <xreftarget="IEEE.802"></xref>target="IEEE.802" format="default"/> to prevent collisions across vendors or organizations using the LCAF. The format of theVendor SpecificVendor-Specific LCAF is provided below.</t><t> <figure align="center" title="Vendor Specific LCAF"><figure> <name>Vendor-Specific LCAF</name> <artworkalign="center"> <![CDATA[ 0 1 2align="center" name="" type="" 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|| AFI =16387 | Rsvd1 | Flags16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =TBD | Rsvd2 | Length255 | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Rsvd3 |OrganizationallyOrganizationally Unique Identifier (OUI)|| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Internal format...|| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]> </artwork>]]></artwork> </figure></t><t>The fields in the first 8 octets of the aboveVendor SpecificVendor-Specific LCAF are actually the fields defined in the general LCAF format specified in <xreftarget="RFC8060"></xref>.target="RFC8060" format="default"/>. The"Type"Type fieldMUST<bcp14>MUST</bcp14> be setto255, the value assigned by IANA to indicate that this is aVendor Specific LCAF (255 is recommended,Vendor-Specific LCAF; see <xreftarget="IANA"></xref>).target="IANA" format="default"/>. The Length field has to be set accordingly to the length of the internalformatformat, plus theOUIOUI, plus the Rsvd3fieldsfields, as for <xreftarget="RFC8060"></xref>.target="RFC8060" format="default"/>. The fields defined by theVendor SpecificVendor-Specific LCAFare:are as follows: </t><t> <list style="hanging"> <t>Rsvd3: This<dl newline="false" spacing="normal"> <dt>Rsvd3:</dt> <dd>This 8-bit field is reserved for future use. ItMUST<bcp14>MUST</bcp14> be set to 0 on transmit andMUST<bcp14>MUST</bcp14> be ignored onreceipt.</t> <t>Organizationallyreceipt.</dd> <dt>Organizationally Unique Identifier(OUI): This(OUI):</dt> <dd>This is a 24-bit field that carries an OUI orCID (Company ID)Company ID (CID) assigned by the IEEE Registration Authority (RA) as defined by the IEEE Std 802 <xreftarget="IEEE.802"></xref></t> <t>Internal format: Thistarget="IEEE.802" format="default"/></dd> <dt>Internal format:</dt> <dd>This is avariable lengthvariable-length field that is left undefined on purpose. Each vendor or organization can define its own internal format(s) to use with theVendor Specific LCAF.</t> </list> </t>Vendor-Specific LCAF.</dd> </dl> <t>TheVendor SpecificVendor-Specific LCAF typeSHOULD NOT<bcp14>SHOULD NOT</bcp14> be used in deployments where different organizations interoperate. However, there may be cases where two (or more) organizations share a common deployment on which they explicitly and mutually agree to use a particularVendor SpecificVendor-Specific LCAF. In that case, the organizations involved need to carefully assess the interoperability concerns for that particular deployment. It isNOT RECOMMENDED<bcp14>NOT RECOMMENDED</bcp14> to use an OUI not assigned to an organization.</t> <t>If a LISP device receives a LISP message containing aVendor SpecificVendor-Specific LCAF with an OUI that it does not understand, itMUST<bcp14>MUST</bcp14> drop the message and itSHOULD<bcp14>SHOULD</bcp14> create a log message.</t> </section> <section anchor="security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>This document enables organizations to define new LCAFs for their internal use. It is the responsibility of these organizations to properly assess the security implications of the formats they define. Security considerations from <xreftarget="RFC8060"></xref>target="RFC8060" format="default"/> apply to this document.</t> </section> <sectionanchor="Acknowledgments" title="Acknowledgments"> <t>The authors would like to thank Joel Halpern, Luigi Iannone, and Alvaro Retana for their suggestions and guidance regarding this document.</t> </section> <sectionanchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>Following the guidelines of <xreftarget="RFC8126"></xref>,target="RFC8126" format="default"/>, IANAis asked to assign ahas assigned the following value(255 is suggested)for theVendor SpecificVendor-Specific LCAF from the "LISP Canonical Address Format (LCAF) Types" registry (defined in <xreftarget="RFC8060"></xref>) as follows:</t> <texttabletarget="RFC8060" format="default"/>):</t> <table anchor="table_ex"title="Vendor Specificalign="center"> <name>Vendor-Specific LCAFassignment"> <ttcol align='center'>Value #</ttcol> <ttcol align='center'>LISPAssignment</name> <thead> <tr> <th align="center">Value</th> <th align="center">LISP LCAF TypeName</ttcol> <ttcol align='center'>Reference</ttcol> <c>TBD</c> <c>Vendor Specific</c> <c> [This Document],Name</th> <th align="center">Reference</th> </tr> </thead> <tbody> <tr> <td align="center">255</td> <td align="center">Vendor Specific</td> <td align="center"> RFC 9306, <xreftarget="vendor-lcaf"></xref> </c> </texttable>target="vendor-lcaf" format="default"/> </td> </tr> </tbody> </table> </section> </middle> <back><references title="Normative References"> &RFC2119; &RFC8060; &RFC8126; &RFC8174; &I-D.ietf-lisp-rfc6830bis; &I-D.ietf-lisp-rfc6833bis;<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.8060.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <reference anchor='RFC9300' target="https://www.rfc-editor.org/info/rfc9300"> <front> <title>The Locator/ID Separation Protocol (LISP)</title> <author initials='D' surname='Farinacci' fullname='Dino Farinacci'> <organization /> </author> <author initials='V' surname='Fuller' fullname='Vince Fuller'> <organization /> </author> <author initials='D' surname='Meyer' fullname='Dave Meyer'> <organization /> </author> <author initials='D' surname='Lewis' fullname='Darrel Lewis'> <organization /> </author> <author initials='A' surname='Cabellos' fullname='Albert Cabellos' role='editor'> <organization /> </author> <date year='2022' month='October'/> </front> <seriesInfo name="RFC" value="9300"/> <seriesInfo name="DOI" value="10.17487/RFC9300"/> </reference> <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 year='2022' month='October'/> </front> <seriesInfo name="RFC" value="9301"/> <seriesInfo name="DOI" value="10.17487/RFC9301"/> </reference> <referenceanchor='IEEE.802'anchor="IEEE.802" target="https://ieeexplore.ieee.org/document/6847097"> <front> <title>IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture</title> <author> <organization>IEEE</organization> </author> <dateday="1"month="July"year='2014'/>year="2014"/> </front> <seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6847097"/> <seriesInfo name="IEEE" value="Std802" />802"/> </reference> </references> <section anchor="Acknowledgments" numbered="false" toc="default"> <name>Acknowledgments</name> <t>The authors would like to thank <contact fullname="Joel Halpern"/>, <contact fullname="Luigi Iannone"/>, and <contact fullname="Alvaro Retana"/> for their suggestions and guidance regarding this document.</t> </section> </back> </rfc>