rfc9306xml2.original.xml   rfc9306.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R <!ENTITY nbhy "&#8209;">
FC.2119.xml"> <!ENTITY wj "&#8288;">
<!ENTITY RFC8060 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R
FC.8060.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R
FC.8126.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R
FC.8174.xml">
<!ENTITY I-D.ietf-lisp-rfc6833bis SYSTEM "http://xml.resource.org/public/rfc/b
ibxml3/reference.I-D.ietf-lisp-rfc6833bis.xml">
<!ENTITY I-D.ietf-lisp-rfc6830bis SYSTEM "http://xml.resource.org/public/rfc/b
ibxml3/reference.I-D.ietf-lisp-rfc6830bis.xml">
]> ]>
<?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" ?>
<rfc category="exp" docName="draft-ietf-lisp-vendor-lcaf-12" ipr="trust200902" u
pdates="8060">
<front>
<title abbrev="LISP-Vendor-LCAF">Vendor Specific LISP Canonical Address Form at (LCAF)</title> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-lisp-vendor- lcaf-12" number="9306" ipr="trust200902" updates="8060" obsoletes="" submissionT ype="IETF" category="exp" consensus="true" xml:lang="en" tocInclude="true" tocDe pth="4" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.13.0 -->
<front>
<title abbrev="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"> <author fullname="Alberto Rodriguez-Natal" initials="A." surname="Rodriguez- Natal">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city></city> <city/>
<region></region> <region/>
<code></code> <code/>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone></phone> <phone/>
<email>natal@cisco.com</email> <email>natal@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Vina Ermagan" initials="V." surname="Ermagan"> <author fullname="Vina Ermagan" initials="V." surname="Ermagan">
<organization>Google</organization> <organization>Google, Inc.</organization>
<address> <address>
<postal> <postal>
<street></street> <street>1600 Amphitheatre Parkway</street>
<city></city> <city>Mountain View</city>
<region></region> <region>CA</region>
<code></code> <code>94043</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone></phone> <phone/>
<email>ermagan@gmail.com</email> <email>ermagan@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Anton Smirnov" initials="A." surname="Smirnov"> <author fullname="Anton Smirnov" initials="A." surname="Smirnov">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Diegem</city> <city>Diegem</city>
<region></region> <region/>
<code></code> <code/>
<country>Belgium</country> <country>Belgium</country>
</postal> </postal>
<phone></phone> <phone/>
<email>asmirnov@cisco.com</email> <email>asmirnov@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Vrushali Ashtaputre" initials="V." surname="Ashtaputre"> <author fullname="Vrushali Ashtaputre" initials="V." surname="Ashtaputre">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>San Jose</city> <city>San Jose</city>
<region>CA</region> <region>CA</region>
<code></code> <code/>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone></phone> <phone/>
<email>vrushali@cisco.com</email> <email>vrushali@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Dino Farinacci" initials="D." surname="Farinacci"> <author fullname="Dino Farinacci" initials="D." surname="Farinacci">
<organization>lispers.net</organization> <organization>lispers.net</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>San Jose</city> <city>San Jose</city>
<region>CA</region> <region>CA</region>
<code></code> <code/>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone></phone> <phone/>
<email>farinacci@gmail.com</email> <email>farinacci@gmail.com</email>
</address> </address>
</author> </author>
<date year="2022" month="October"/>
<date year="2022"/> <area>RTG</area>
<workgroup>LISP</workgroup>
<area>Internet</area> <keyword>lisp</keyword>
<keyword>lcaf</keyword>
<workgroup>LISP Working Group</workgroup> <keyword>internal</keyword>
<keyword>domain</keyword>
<keyword>lisp, lcaf, internal, domain, organization, private</keyword> <keyword>organization</keyword>
<keyword>private</keyword>
<abstract> <abstract>
<t>This document describes a new Locator/ID Separation Protocol (LISP) Can onical Address Format (LCAF), the Vendor Specific LCAF. This LCAF enables organi zations to have implementation-specific encodings for LCAF addresses. This docum ent updates RFC8060.</t> <t>This document describes a new Locator/ID Separation Protocol (LISP) Ca nonical Address Format (LCAF), the Vendor-Specific LCAF. This LCAF enables organ izations to have implementation-specific encodings for LCAF addresses. This docu ment updates RFC 8060.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>The LISP Canonical Address Format (LCAF) <xref target="RFC8060"></xref> <t>The LISP Canonical Address Format (LCAF) <xref target="RFC8060" format=
defines the format and encoding for different address types that can be used on "default"/> defines the format and encoding for different address types that can
LISP <xref target="I-D.ietf-lisp-rfc6830bis"></xref> <xref target="I-D.ietf-lis be used on deployments of the Locator/ID Separation Protocol (LISP) <xref targe
p-rfc6833bis"></xref> deployments. However, certain deployments require specific t="RFC9300" format="default"/> <xref target="RFC9301" format="default"/>. Howeve
format encodings that may not be applicable outside of the use-case for which t r, certain deployments require specific format encodings that may not be applica
hey are defined. This document extends <xref target="RFC8060"></xref> to introdu ble outside of the use case for which they are defined. This document extends <x
ce a Vendor Specific LCAF that defines how organizations can create LCAF address ref target="RFC8060" format="default"/> to introduce a Vendor-Specific LCAF that
es to be used only on particular LISP implementations. This document also update defines how organizations can create LCAF addresses to be used only on particul
s <xref target="RFC8060"></xref> to specify the behavior when receiving unrecogn ar LISP implementations. This document also updates <xref target="RFC8060" forma
ized LCAF Types.</t> t="default"/> to specify the behavior when receiving unrecognized LCAF types.</t
>
</section> </section>
<section numbered="true" toc="default">
<section title="Requirements Notation"> <name>Requirements Notation</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH <t>
OULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
this document are to be interpreted as described in BCP 14 <xref target="RFC2119 "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
"></xref> <xref target="RFC8174"></xref> when, and only when, they appear in all ",
capitals, as shown here. "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
</t> "<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>
<section numbered="true" toc="default">
<section title="Unrecognized LCAF types"> <name>Unrecognized LCAF Types</name>
<t><xref target="RFC8060"></xref> does not explain how an implementation s <t><xref target="RFC8060" format="default"/> does not explain how an imple
hould handle unrecognized LCAF Type. This document updates <xref target="RFC8060 mentation should handle an unrecognized LCAF type. This document updates <xref t
"></xref> to specify that any unrecognized LCAF Type received in a LISP control arget="RFC8060" format="default"/> to specify that any unrecognized LCAF type re
plane message MUST be ignored. If all Locators are ignored, this is equivalent t ceived in a LISP control plane message <bcp14>MUST</bcp14> be ignored. If all Lo
o a LISP control message with Locator Count = 0, as described in <xref target="I cators are ignored, this is equivalent to a LISP control message with Locator Co
-D.ietf-lisp-rfc6833bis"></xref>. If an EID-Prefix only contains unrecognized LC unt = 0, as described in <xref target="RFC9301" format="default"/>. If an EID-Pr
AF Types, the LISP control message MUST be dropped and the event MUST be logged. efix only contains unrecognized LCAF types, the LISP control message <bcp14>MUST
</t> </bcp14> be dropped and the event <bcp14>MUST</bcp14> be logged. (Here, "EID" re
fers to Endpoint Identifier.)</t>
</section> </section>
<section anchor="vendor-lcaf" numbered="true" toc="default">
<section anchor="vendor-lcaf" title="Vendor Specific LCAF"> <name>Vendor-Specific LCAF</name>
<t>
The Vendor Specific LCAF relies on using the IEEE Organizationally Uniqu
e Identifier (OUI) <xref target="IEEE.802"></xref> to prevent collisions across
vendors or organizations using the LCAF. The format of the Vendor Specific LCAF
is provided below.</t>
<t> <t>
<figure align="center" title="Vendor Specific LCAF"> The Vendor-Specific LCAF relies on using the IEEE Organizationally Uniqu
<artwork align="center"> e Identifier (OUI) <xref target="IEEE.802" format="default"/> to prevent collisi
<![CDATA[ ons across vendors or organizations using the LCAF. The format of the Vendor-Spe
0                   1                   2                   3 cific LCAF is provided below.</t>
<figure>
<name>Vendor-Specific LCAF</name>
<artwork align="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 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     |     Flags     | | AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD  |   Rsvd2     |            Length             | | Type = 255 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Rsvd3 |   Organizationally Unique Identifier (OUI)  | | Rsvd3 | Organizationally Unique Identifier (OUI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Internal format...  | | Internal format... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>The fields in the first 8 octets of the above Vendor-Specific LCAF are
</t> actually the fields defined in the general LCAF format specified in <xref targe
t="RFC8060" format="default"/>. The Type field <bcp14>MUST</bcp14> be set 255, t
<t>The fields in the first 8 octets of the above Vendor Specific LCAF are he value assigned by IANA to indicate that this is a Vendor-Specific LCAF; see <
actually the fields defined in the general LCAF format specified in <xref targe xref target="IANA" format="default"/>. The Length field has to be set accordingl
t="RFC8060"></xref>. The "Type" field MUST be set to the value assigned by IANA y to the length of the internal format, plus the OUI, plus the Rsvd3 fields, as
to indicate that this is a Vendor Specific LCAF (255 is recommended, see <xref t for <xref target="RFC8060" format="default"/>. The fields defined by the Vendor-
arget="IANA"></xref>). The Length field has to be set accordingly to the length Specific LCAF are as follows:
of the internal format plus the OUI plus the Rsvd3 fields as for <xref target="R
FC8060"></xref>. The fields defined by the Vendor Specific LCAF are:
</t>
<t>
<list style="hanging">
<t>Rsvd3: This 8-bit field is reserved for future use. It MUST be set
to 0 on transmit and MUST be ignored on receipt.</t>
<t>Organizationally Unique Identifier (OUI): This is a 24-bit field th
at carries an OUI or CID (Company ID) assigned by the IEEE Registration Authorit
y (RA) as defined by the IEEE Std 802 <xref target="IEEE.802"></xref></t>
<t>Internal format: This is a variable length field that is left undef
ined on purpose. Each vendor or organization can define its own internal format(
s) to use with the Vendor Specific LCAF.</t>
</list>
</t> </t>
<dl newline="false" spacing="normal">
<t>The Vendor Specific LCAF type SHOULD NOT be used in deployments where d <dt>Rsvd3:</dt>
ifferent organizations interoperate. However, there may be cases where two (or m <dd>This 8-bit field is reserved for future use. It <bcp14>MUST</bcp14>
ore) organizations share a common deployment on which they explicitly and mutual be set to 0 on transmit and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
ly agree to use a particular Vendor Specific LCAF. In that case, the organizatio <dt>Organizationally Unique Identifier (OUI):</dt>
ns involved need to carefully assess the interoperability concerns for that part <dd>This is a 24-bit field that carries an OUI or Company ID (CID) assig
icular deployment. It is NOT RECOMMENDED to use an OUI not assigned to an organi ned by the IEEE Registration Authority (RA) as defined by the IEEE Std 802 <xref
zation.</t> target="IEEE.802" format="default"/></dd>
<dt>Internal format:</dt>
<t>If a LISP device receives a LISP message containing a Vendor Specific L <dd>This is a variable-length field that is left undefined on purpose. E
CAF with an OUI that it does not understand, it MUST drop the message and it SHO ach vendor or organization can define its own internal format(s) to use with the
ULD create a log message.</t> Vendor-Specific LCAF.</dd>
</dl>
</section> <t>The Vendor-Specific LCAF type <bcp14>SHOULD NOT</bcp14> be used in depl
oyments where different organizations interoperate. However, there may be cases
<section anchor="security" title="Security Considerations"> where two (or more) organizations share a common deployment on which they explic
<t>This document enables organizations to define new LCAFs for their inter itly and mutually agree to use a particular Vendor-Specific LCAF. In that case,
nal use. It is the responsibility of these organizations to properly assess the the organizations involved need to carefully assess the interoperability concern
security implications of the formats they define. Security considerations from < s for that particular deployment. It is <bcp14>NOT RECOMMENDED</bcp14> to use an
xref target="RFC8060"></xref> apply to this document.</t> OUI not assigned to an organization.</t>
<t>If a LISP device receives a LISP message containing a Vendor-Specific L
CAF with an OUI that it does not understand, it <bcp14>MUST</bcp14> drop the mes
sage and it <bcp14>SHOULD</bcp14> create a log message.</t>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="Acknowledgments" title="Acknowledgments"> <name>Security Considerations</name>
<t>The authors would like to thank Joel Halpern, Luigi Iannone, and Alvaro <t>This document enables organizations to define new LCAFs for their inter
Retana for their suggestions and guidance regarding this document.</t> nal use. It is the responsibility of these organizations to properly assess the
security implications of the formats they define. Security considerations from <
xref target="RFC8060" format="default"/> apply to this document.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>Following the guidelines of <xref target="RFC8126"></xref>, IANA is ask <t>Following the guidelines of <xref target="RFC8126" format="default"/>,
ed to assign a value (255 is suggested) for the Vendor IANA has assigned the following value for the Vendor-Specific LCAF from the "LIS
Specific LCAF from the "LISP Canonical Address Format (LCAF) Types" registry P Canonical Address Format (LCAF) Types" registry (defined in <xref target="RFC8
(defined in <xref target="RFC8060"></xref>) as follows:</t> 060" format="default"/>):</t>
<table anchor="table_ex" align="center">
<texttable anchor="table_ex" title="Vendor Specific LCAF assignment"> <name>Vendor-Specific LCAF Assignment</name>
<ttcol align='center'>Value #</ttcol> <thead>
<ttcol align='center'>LISP LCAF Type Name</ttcol> <tr>
<ttcol align='center'>Reference</ttcol> <th align="center">Value</th>
<c>TBD</c> <th align="center">LISP LCAF Type Name</th>
<c>Vendor Specific</c> <th align="center">Reference</th>
<c> </tr>
[This Document], <xref target="vendor-lcaf"></xref> </thead>
</c> <tbody>
</texttable> <tr>
<td align="center">255</td>
<td align="center">Vendor Specific</td>
<td align="center">
RFC 9306, <xref target="vendor-lcaf" format="default"/>
</td>
</tr>
</tbody>
</table>
</section> </section>
</middle> </middle>
<back> <back>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.806
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.812
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
4.xml"/>
<references title="Normative References"> <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>
&RFC2119; <reference anchor='RFC9301' target="https://www.rfc-editor.org/info/rfc9301">
&RFC8060; <front>
&RFC8126; <title>Locator/ID Separation Protocol (LISP) Control Plane</title>
&RFC8174; <author initials='D' surname='Farinacci' fullname='Dino Farinacci'>
&I-D.ietf-lisp-rfc6830bis; <organization />
&I-D.ietf-lisp-rfc6833bis; </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>
<reference anchor='IEEE.802' target="https://ieeexplore.ieee.org/document/ 6847097"> <reference anchor="IEEE.802" target="https://ieeexplore.ieee.org/document/ 6847097">
<front> <front>
<title>IEEE Standard for Local and Metropolitan Area Networks: Overvie w and Architecture</title> <title>IEEE Standard for Local and Metropolitan Area Networks: Overvie w and Architecture</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date day="1" month="July" year='2014'/> <date month="July" year="2014"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6847097"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6847097"/>
<seriesInfo name="IEEE" value="Std 802" /> <seriesInfo name="IEEE" value="Std 802"/>
</reference> </reference>
</references> </references>
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Joel Halpern"/>, <co
ntact fullname="Luigi Iannone"/>, and <contact fullname="Alvaro Retana"/> for th
eir suggestions and guidance regarding this document.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 50 change blocks. 
197 lines changed or deleted 225 lines changed or added

This html diff was produced by rfcdiff 1.48.