rfc9542.original.xml   rfc9542.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="rfc7991bis.rnc"?> <!-- Required for schema <?xml-model href="rfc7991bis.rnc"?>
validation and schema-aware editing -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY filename "draft-ietf-intarea-rfc7042bis-11"> <!ENTITY filename "draft-ietf-intarea-rfc7042bis-11">
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations
in XML processors, including most browsers -->
<!-- If further character entities are required then they should be
added to the DOCTYPE above. Use of an external entity file is not
recommended. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<rfc
xmlns:xi="http://www.w3.org/2001/XInclude"
category="bcp"
docName="&filename;"
ipr="trust200902"
obsoletes="7042"
submissionType="IETF"
xml:lang="en"
version="3">
<!--
* docName should be the name of your draft * category should be
one of std, bcp, info, exp, historic * ipr should be one of
trust200902, noModificationTrust200902, noDerivativesTrust200902,
pre5378Trust200902 * updates can be an RFC number as NNNN *
obsoletes can be an RFC number as NNNN
<!-- ____________________FRONT_MATTER____________________ --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" bcp" consensus="true" docName="draft-ietf-intarea-rfc7042bis-11" number="9542" i pr="trust200902" updates="" obsoletes="7042" xml:lang="en" tocInclude="true" sor tRefs="true" symRefs="true" version="3">
<front> <front>
<title abbrev="IANA/IETF and IEEE 802 Parameters">IANA <title abbrev="IANA/IETF and IEEE 802 Parameters">IANA
Considerations and IETF Protocol and Documentation Usage for IEEE Considerations and IETF Protocol and Documentation Usage for IEEE
802 Parameters</title> 802 Parameters</title>
<!-- The abbreviated title is required if the full title is <seriesInfo name="RFC" value="9542"/>
longer than 39 characters --> <seriesInfo name="BCP" value="141"/>
<author fullname="Donald E. Eastlake 3rd" initials="D." surname="Eastlake 3rd
<seriesInfo name="Internet-Draft" ">
value="&filename;"/> <organization>Independent</organization>
<author fullname="Donald E. Eastlake 3rd" initials="D."
surname="Eastlake">
<organization>Futurewei Technologies</organization>
<address> <address>
<postal> <postal>
<street>2386 Panoramic Circle</street> <street>2386 Panoramic Circle</street>
<city>Apopka</city> <city>Apopka</city>
<region>Florida</region> <region>Florida</region>
<code>32703</code> <code>32703</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<phone>+1-508-333-2270</phone> <phone>+1-508-333-2270</phone>
<email>d3e3e3@gmail.com</email> <email>d3e3e3@gmail.com</email>
<email>donald.eastlake@futurewei.com</email> <email>donald.eastlake@futurewei.com</email>
</address> </address>
</author> </author>
<author fullname="Joe Abley" initials="J.N." <author fullname="Joe Abley" initials="J."
surname="Abley"> surname="Abley">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
<address> <address>
<postal> <postal>
<city>Amsterdam</city> <postalLine>Amsterdam</postalLine>
<country>Netherlands</country> <postalLine>The Netherlands</postalLine>
</postal> </postal>
<phone>+31 45 56 36 34</phone> <phone>+31 45 56 36 34</phone>
<email>jabley@strandkip.nl</email> <email>jabley@strandkip.nl</email>
</address> </address>
</author> </author>
<author fullname="Yizhou Li" initials="Y." <author fullname="Yizhou Li" initials="Y."
surname="Li"> surname="Li">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
skipping to change at line 97 skipping to change at line 63
<city>Nanjing</city> <city>Nanjing</city>
<region>Jiangsu</region> <region>Jiangsu</region>
<code>210012</code> <code>210012</code>
<country>China</country> <country>China</country>
</postal> </postal>
<phone>+86-13809002299</phone> <phone>+86-13809002299</phone>
<email>liyizhou@huawei.com</email> <email>liyizhou@huawei.com</email>
</address> </address>
</author> </author>
<date year="2023" month="11" day="6"/> <date year="2024" month="April"/>
<area>Internet</area> <area>int</area>
<workgroup>INTAREA Working Group</workgroup> <workgroup>intarea</workgroup>
<!-- "Internet Engineering Task Force" is fine for individual
submissions. If this element is not present, the default is
"Network Working Group", which is used by the RFC Editor as a
nod to the history of the RFC Series. -->
<keyword></keyword> <keyword>Ethernet</keyword>
<!-- Multiple keywords are allowed. Keywords are incorporated <keyword>EtherType</keyword>
into HTML output files for use by search engines. --> <keyword>802</keyword>
<keyword>OUI</keyword>
<keyword>EUI</keyword>
<keyword>LSAP</keyword>
<keyword>AFN</keyword>
<keyword>CBOR</keyword>
<keyword>LLC</keyword>
<keyword>SLAP</keyword>
<keyword>SNAP</keyword>
<keyword>CID</keyword>
<abstract> <abstract>
<t>Some IETF protocols make use of Ethernet frame formats and IEEE <t>Some IETF protocols make use of Ethernet frame formats and IEEE
802 parameters. This document discusses several aspects of such 802 parameters. This document discusses several aspects of such
parameters and their use in IETF protocols, specifies IANA parameters and their use in IETF protocols, specifies IANA
considerations for assignment of points under the IANA OUI considerations for assignment of points under the IANA
(Organizationally Unique Identifier), and provides some values for Organizationally Unique Identifier (OUI), and provides some values for
use in documentation. This document obsoletes RFC 7042.</t> use in documentation. This document obsoletes RFC 7042.</t>
</abstract> </abstract>
</front> </front>
<!-- ____________________MIDDLE_MATTER____________________ -->
<middle> <middle>
<section> <!-- 1. --> <section> <!-- 1. -->
<name>Introduction</name> <name>Introduction</name>
<t>Some IETF protocols use Ethernet or other communication frame formats
<t>Some IETF protocols use Ethernet or other IEEE 802-related and parameters related to IEEE 802 <xref target="IEEE802"/>.
communication frame formats and parameters <xref target="IEEE802"/>. These include Media Access Control (MAC) addresses and protocol
These include MAC (Media Access Control) addresses and protocol
identifiers. The IEEE Registration Authority <xref identifiers. The IEEE Registration Authority <xref
target="IEEE_RA"/> manages the assignment of identifiers used in target="IEEE_RA"/> manages the assignment of identifiers used in
IEEE 802 networks, in some cases assigning blocks of such IEEE 802 networks, in some cases assigning blocks of such
identifiers whose sub-assignment is managed by the entity to which identifiers whose sub-assignment is managed by the entity to which
the block is assigned. The IEEE RA also provides a number of the block is assigned. The IEEE RA also provides a number of
tutorials concerning these parameters <xref tutorials concerning these parameters <xref
target="IEEEtutorials"/>.</t> target="IEEEtutorials"/>.</t>
<t>IANA has been assigned an Organizationally Unique Identifier <t>IANA has been assigned an Organizationally Unique Identifier
(OUI) by the IEEE RA and an associated set of MAC addresses and (OUI) by the IEEE RA and an associated set of MAC addresses and
skipping to change at line 151 skipping to change at line 120
document specifies IANA considerations for the assignment of code document specifies IANA considerations for the assignment of code
points under that IANA OUI, including MAC addresses and protocol points under that IANA OUI, including MAC addresses and protocol
identifiers, and provides some values for use in documentation. As identifiers, and provides some values for use in documentation. As
noted in <xref target="RFC2606"/> and <xref target="RFC5737"/>, the noted in <xref target="RFC2606"/> and <xref target="RFC5737"/>, the
use of designated code values reserved for documentation and use of designated code values reserved for documentation and
examples reduces the likelihood of conflicts and confusion arising examples reduces the likelihood of conflicts and confusion arising
from such code points conflicting with code points assigned for some from such code points conflicting with code points assigned for some
deployed use. This document also discusses several other uses by the deployed use. This document also discusses several other uses by the
IETF of IEEE 802 code points, including IEEE 802 Connectivity Fault IETF of IEEE 802 code points, including IEEE 802 Connectivity Fault
Management (CFM) code points <xref target="RFC7319"/> and IEEE 802 Management (CFM) code points <xref target="RFC7319"/> and IEEE 802
Link Local Discovery Protocol (LLDP <xref target="IEEE802.1AB"/>) Link Local Discovery Protocol (LLDP) <xref target="IEEE802.1AB"/>
Vendor Specific TLV Sub-Types <xref target="RFC8520"/>. It Vendor-Specific TLV Sub-Types <xref target="RFC8520"/>. It
also specifies CBOR tags for MAC addresses and OUI/CIDs.</t> also specifies Concise Binary Object Representation (CBOR) tags for MAC addres
ses and OUIs / Company Identifiers (CIDs).</t>
<t>Descriptions herein of <xref target="IANA"/> policies and <t>Descriptions herein of <xref target="IANA"/> policies and
procedures are authoritative but descriptions of IEEE registration procedures are authoritative, but descriptions of IEEE registration
policies, procedures, and standards are only informative; for policies, procedures, and standards are only informative; for
authoritative IEEE information, consult the IEEE sources.</t> authoritative IEEE information, consult the IEEE sources.</t>
<t><xref target="RFC8126"/> is incorporated herein except where <t><xref target="RFC8126"/> is incorporated herein except where
there are contrary provisions in this document. In this document, there are contrary provisions in this document. In this document,
"IESG Ratification", specified in Section 5.1, refers to a "IESG Ratification", specified in <xref target="ex-rev-iesg-rat"/>, refers to a
combination of Expert Review and IESG Approval as those are defined combination of Expert Review and IESG Approval as those are defined
in <xref target="RFC8126"/> where IESG Approval is required only if in <xref target="RFC8126"/>, where IESG Approval is required only if
the Expert does not reject the request. It is NOT the same as just the Expert does not reject the request. It is NOT the same as just
"IESG Approval" in <xref target="RFC8126"/>.</t> "IESG Approval" in <xref target="RFC8126"/>.</t>
<section> <!-- 1.1 --> <section> <!-- 1.1 -->
<name>Notations Used in This Document</name> <name>Notations Used in This Document</name>
<t>This document uses hexadecimal notation. Each octet (that is, <t>This document uses hexadecimal notation. Each octet (that is,
8-bit byte) is represented by two hexadecimal digits giving the value 8-bit byte) is represented by two hexadecimal digits giving the value
of the octet as an unsigned integer. Successive octets are separated of the octet as an unsigned integer. Successive octets are separated
by a hyphen. This document consistently uses IETF ("network") bit by a hyphen. This document consistently uses IETF ("network") bit
ordering although the physical order of bit transmission within an ordering although the physical order of bit transmission within an
octet on an IEEE <xref target="IEEE.802.3_2012"/> link is from the lowest octet on an IEEE <xref target="IEEE.802.3_2012"/> link is from the lowest
order bit to the highest order bit (i.e., the reverse of the IETF's order bit to the highest order bit (i.e., the reverse of the IETF's
ordering).</t> ordering).</t>
<t>In this document:</t> <t>In this document:</t>
<dl> <dl newline="false" indent="12">
<dt>"AFN"</dt><dd>Address Family Number <xref target="RFC4760"/>.</dd> <dt>"AFN"</dt><dd>Address Family Number <xref target="RFC4760"/>.</dd>
<dt>"CBOR"</dt><dd>Concise Binary Object Representation <xref <dt>"CBOR"</dt><dd>Concise Binary Object Representation <xref
target="RFC8949"/>.</dd> target="RFC8949"/>.</dd>
<dt>"CFM"</dt><dd>Connectivity Fault Management <xref <dt>"CFM"</dt><dd>Connectivity Fault Management <xref
target="RFC7319"/>.</dd> target="RFC7319"/>.</dd>
<dt>"CID"</dt><dd>Company Identifier. (See Section 2.1.2.)</dd> <dt>"CID"</dt><dd>Company Identifier. See <xref target="oui-cid"/>.</dd>
<dt>"DSAP"</dt><dd>Destination Service Access Point. See Section <dt>"DSAP"</dt><dd>Destination Service Access Point. See <xref target="eth-pro-p
3.</dd> aram"/>.</dd>
<dt>"EUI"</dt><dd>Extended Unique Identifier.</dd> <dt>"EUI"</dt><dd>Extended Unique Identifier.</dd>
<dt>"EUI-48"</dt><dd>48-bit EUI</dd> <dt>"EUI-48"</dt><dd>48-bit EUI</dd>
<dt>"IEEE"</dt><dd>Institute for Electrical and Electronics Engineers <dt>"IEEE"</dt><dd>Institute of Electrical and Electronics Engineers
<xref target="IEEE"/>.</dd> <xref target="IEEE"/>.</dd>
<dt>"IEEE 802"</dt><dd>The LAN/MAN Standards Committee <xref <dt>"IEEE 802"</dt><dd>The LAN/MAN Standards Committee <xref
target="IEEE802"/>.</dd> target="IEEE802"/>.</dd>
<dt>"IEEE RA"</dt><dd>IEEE Registration Authority <xref <dt>"IEEE RA"</dt><dd>IEEE Registration Authority <xref
target="IEEE_RA"/>.</dd> target="IEEE_RA"/>.</dd>
<dt>"IEEE SA"</dt><dd>IEEE Standards Association <xref <dt>"IEEE SA"</dt><dd>IEEE Standards Association <xref
target="IEEE_SA"/>.</dd> target="IEEE_SA"/>.</dd>
<dt>"LLC"</dt><dd>Logical Link Control. The type of frame header where <dt>"LLC"</dt><dd>Logical Link Control. The type of frame header where
the protocol is identified by source and destination LSAP the protocol is identified by source and destination LSAP
fields. See Section 3.</dd> fields. See <xref target="eth-pro-param"/>.</dd>
<dt>"LSAP"</dt><dd>Link-Layer Service Access Point. See Section <dt>"LSAP"</dt><dd>Link-Layer Service Access Point. See <xref target="eth-pro-pa
3.</dd> ram"/>.</dd>
<dt>"MA-L"</dt><dd>MAC Address Block Large.</dd> <dt>"MA-L"</dt><dd>MAC Address Block Large.</dd>
<dt>"MA-M"</dt><dd>MAC Address Block Medium.</dd> <dt>"MA-M"</dt><dd>MAC Address Block Medium.</dd>
<dt>"MA-S"</dt><dd>MAC Address Block Small.</dd> <dt>"MA-S"</dt><dd>MAC Address Block Small.</dd>
<dt>"MAC"</dt><dd>Media Access Control, not Message Authentication <dt>"MAC"</dt><dd>Media Access Control, not Message Authentication
Code.</dd> Code.</dd>
<dt>"MAC-48"</dt><dd>A 48-bit MAC address. This term is obsolete. If <dt>"MAC-48"</dt><dd>A 48-bit MAC address. This term is obsolete. If
globally unique, use EUI&nbhy;48.</dd> globally unique, use EUI&nbhy;48.</dd>
<dt>"OUI"</dt><dd>Organizationally Unique Identifier. (See Section <dt>"OUI"</dt><dd>Organizationally Unique Identifier. See <xref target="oui-cid"
2.1.2.)</dd> />.</dd>
<dt>"RRTYPE"</dt><dd>A DNS Resource Record type <xref <dt>"RRTYPE"</dt><dd>A DNS Resource Record type <xref
target="RFC6895"/>.</dd> target="RFC6895"/>.</dd>
<dt>"SLAP"</dt><dd>IEEE 802 Structured Local Address Plan <xref <dt>"SLAP"</dt><dd>IEEE 802 Structured Local Address Plan <xref
target="IEEE802_OandA"/>. See Section 2.1.1.</dd> target="IEEE802_OandA"/>. See <xref target="first-oct-bit"/>.</dd>
<dt>"SNAP"</dt><dd>Subnetwork Access Protocol. See Section 3.</dd> <dt>"SNAP"</dt><dd>Subnetwork Access Protocol. See <xref target="eth-pro-param"/ >.</dd>
<dt>"SSAP"</dt><dd>Source Service Access Point. See Section 3.</dd> <dt>"SSAP"</dt><dd>Source Service Access Point. See <xref target="eth-pro-param" />.</dd>
<dt>"tag"</dt><dd>"Tag" is used in two contexts in this document. For <dt>"tag"</dt><dd>"Tag" is used in two contexts in this document. For
"Ethernet tag", see Section 3. For "CBOR tag", see Section 2.4.</dd> "Ethernet tag", see <xref target="eth-pro-param"/>. For "CBOR tag", see <xref ta rget="cbor-tags"/>.</dd>
<dt>"TLV"</dt><dd>Type, Length, Value.</dd> <dt>"TLV"</dt><dd>Type-Length-Value.</dd>
<dt>"**"</dt><dd>The double asterisk symbol indicates exponentiation. <dt>"**"</dt><dd>The double asterisk symbol indicates exponentiation.
For example, 2**24 is two to the twenty-fourth power.</dd> For example, 2**24 is two to the twenty-fourth power.</dd>
</dl> </dl>
</section> </section>
<section anchor="IEEEregAuth"> <!-- 1.2 --> <section anchor="IEEEregAuth"> <!-- 1.2 -->
<name>The IEEE Registration Authority</name> <name>The IEEE Registration Authority</name>
<t>Originally the responsibility of Xerox Corporation, the <t>Originally the responsibility of the Xerox Corporation, the
registration authority for Ethernet parameters since 1986 has been the registration authority for Ethernet parameters since 1986 has been the
IEEE Registration Authority, available on the web at <xref IEEE Registration Authority, available on the Web at <xref
target="IEEE_RA"/>.</t> target="IEEE_RA"/>.</t>
<t>The IEEE Registration Authority operates under the direction of the <t>The IEEE Registration Authority operates under the direction of the
IEEE Standards Association (IEEE SA) Board of Governors, with IEEE Standards Association (IEEE SA) Board of Governors, with
oversight by the IEEE Registration Authority Committee (RAC). The IEEE oversight by the IEEE Registration Authority Committee (IEEE RAC). The IEEE
RAC is a committee of the Board of Governors.</t> RAC is a committee of the Board of Governors.</t>
<t>Anyone may apply to that Authority for parameter assignments. The <t>Anyone may apply to that authority for parameter assignments. The
IEEE Registration Authority may impose fees or other requirements but IEEE Registration Authority may impose fees or other requirements but
commonly waives fees for applications from standards development commonly waives fees for applications from standards development
organizations. Lists of assignments and their holders are downloadable organizations. Lists of assignments and their holders are downloadable
from the IEEE Registration Authority site.</t> from the IEEE Registration Authority site.</t>
</section> </section>
<section anchor="IANAOUI"> <!-- 1.3 --> <section anchor="IANAOUI"> <!-- 1.3 -->
<name>The IANA Organizationally Unique Identifier</name> <name>The IANA Organizationally Unique Identifier</name>
skipping to change at line 294 skipping to change at line 260
below.</t> below.</t>
</section> </section>
<section anchor="CFM"> <!-- 1.4 --> <section anchor="CFM"> <!-- 1.4 -->
<name>CFM Code Points</name> <name>CFM Code Points</name>
<t>IEEE Std 802.1Q <xref target="IEEE.802.1Q_2014"/> allocates two <t>IEEE Std 802.1Q <xref target="IEEE.802.1Q_2014"/> allocates two
blocks of 802 Connectivity Fault Management (CFM) code points to the blocks of 802 Connectivity Fault Management (CFM) code points to the
IETF, one for CFM OpCodes and one for CFM TLV Types. For further IETF, one for CFM OpCodes and one for CFM TLV Types. For further
information see <xref target="RFC7319"/>. The IANA "Connectivity Fault information, see <xref target="RFC7319"/>. The IANA "Connectivity Fault
Management (CFM) OAM IETF Parameters" Registry has subregistries for Management (CFM) OAM IETF Parameters" registry has subregistries for
these code points. This document does not further discuss these these code points. This document does not further discuss these
blocks of code points.</t> blocks of code points.</t>
</section> </section>
</section> <!-- end 1. Introduction --> </section> <!-- end 1. Introduction -->
<section> <!-- 2. --> <section> <!-- 2. -->
<name>Ethernet Identifier Parameters</name> <name>Ethernet Identifier Parameters</name>
<t>This section includes information summarized from <xref <t>This section includes information summarized from <xref
target="IEEE802_OandA"/> that is being provided for context. The target="IEEE802_OandA"/> that is being provided for context. The
definitive information, which prevails in case of any discrepancy, is definitive information, which prevails in case of any discrepancy, is
in <xref target="IEEE802_OandA"/>.</t> in <xref target="IEEE802_OandA"/>.</t>
<t>Section 2.1 discusses 48-bit MAC identifiers, their relationship to <t><xref target="bit-48"/> discusses 48-bit MAC identifiers, their relationship
OUIs and other prefixes, and assignment under the IANA OUI. Section to
2.2 extends this to 64-bit identifiers. Section 2.3 discusses other OUIs and other prefixes, and assignment under the IANA OUI. <xref target="bit-6
IETF MAC identifier use not under the IANA OUI. Section 2.4 specifies 4"/> extends this to 64-bit identifiers. <xref target="bit-48-ietf"/> discusses
CBOR tags for MAC addresses and OUI/CIDs.</t> other
IETF MAC identifier uses not under the IANA OUI. <xref target="cbor-tags"/> spec
ifies
CBOR tags for MAC addresses and OUIs/CIDs.</t>
<t indent="3">Historical Note: <xref target="RAC_OUI"/> is an expired <aside>
draft that provides additional historic information on <xref <t>Historical Note: <xref target="I-D.ieee-rac-oui-restructuring"/> is an expire
d
Internet-Draft that provides additional historic information on <xref
target="IEEE802"/> registries.</t> target="IEEE802"/> registries.</t>
</aside>
<section> <!-- 2.1 --> <section anchor="bit-48"> <!-- 2.1 -->
<name>48-Bit MAC Identifiers, OUIs, and Other Prefixes</name> <name>48-Bit MAC Identifiers, OUIs, and Other Prefixes</name>
<t>48-bit MAC "addresses" are the most commonly used Ethernet <t>48-bit MAC "addresses" are the most commonly used Ethernet
interface identifiers. Those that are globally unique are also called interface identifiers. Those that are globally unique are also called
EUI&nbhy;48 identifiers (Extended Unique Identifier 48). An EUI&nbhy;48 identifiers (Extended Unique Identifier 48). An
EUI&nbhy;48 is structured into an initial prefix assigned by the IEEE EUI&nbhy;48 is structured into an initial prefix assigned by the IEEE
Registration Authority and additional bits assigned by the prefix Registration Authority and additional bits assigned by the prefix
owner. As of 2023 there are three lengths of prefixes assigned, as owner. As of 2024, there are three lengths of prefixes assigned, as
shown in the table below; however, some prefix bits can have special shown in the table below; however, some prefix bits can have special
meaning as shown in <xref target="MACaddr"/>.</t> meaning, as shown in <xref target="MACaddr"/>.</t>
<table align="center"> <table align="center">
<thead> <thead>
<tr><th>Prefix Length in bits</th><th>Name</th><th>Owner Supplied <tr><th>Prefix Length in Bits</th><th>Name</th><th>Owner Supplied
Bits for 48&nbhy;bit MAC Addresses</th></tr> Bits for 48&nbhy;bit MAC Addresses</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align="center">24</td><td>MA-L</td><td <tr><td align="center">24</td><td>MA-L</td><td
align="center">24</td></tr> align="center">24</td></tr>
<tr><td align="center">28</td><td>MA-M</td><td align="center">20</td></tr> <tr><td align="center">28</td><td>MA-M</td><td align="center">20</td></tr>
<tr><td align="center">36</td><td>MA-S</td><td align="center">12</td></tr> <tr><td align="center">36</td><td>MA-S</td><td align="center">12</td></tr>
</tbody> </tbody>
</table> </table>
<t>The bottom (least significant) four bits of the first octet of the <t>The bottom (least significant) four bits of the first octet of the
6-octet 48-bit MAC have special meaning, as shown in <xref 6-octet 48-bit MAC have special meaning, as shown in <xref
target="MACaddr"/>, and are referred to below as the M, X, Y, and Z target="MACaddr"/>, and are referred to below as the M, X, Y, and Z
bits.</t> bits.</t>
<figure anchor="MACaddr"> <figure anchor="MACaddr">
<name>48-bit MAC Address Structure</name> <name>48-Bit MAC Address Structure</name>
<artwork type="ascii-art" align="center"> <artwork type="ascii-art" align="center">
<![CDATA[ <![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| . . . . Z Y X M| . . . . . . . .| octets 0+1 | . . . . Z Y X M| . . . . . . . .| octets 0+1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| . . . . . . . .| . . . . . . . .| octets 2+3 | . . . . . . . .| . . . . . . . .| octets 2+3
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| . . . . . . . .| . . . . . . . .| octets 4+5 | . . . . . . . .| . . . . . . . .| octets 4+5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]> ]]>
</artwork> </artwork>
</figure> </figure>
<t>For global addresses, X=0 and a MAC address begins with 3 octets or <t>For global addresses, X = 0 and a MAC address begins with 3 octets or
a larger initial prefix indicating the assignee of the block of MAC a larger initial prefix indicating the assignee of the block of MAC
addresses. This prefix is followed by a sequence of additional octets addresses. This prefix is followed by a sequence of additional octets
so as to add up to the total MAC address length. For example, the so as to add up to the total MAC address length. For example, the
IEEE assigns MA-S (MAC Address Block Small), where the first four and IEEE assigns MAC Address Block Small (MA-S), where the first four and
a half octets (36 bits) are assigned, giving the holder of the MA-S a half octets (36 bits) are assigned, giving the holder of the MA-S
one and a half octets (12 bits) they can control in constructing one and a half octets (12 bits) they can control in constructing
48-bit MAC addresses; other prefix lengths are also available <xref 48-bit MAC addresses; other prefix lengths are also available <xref
target="IEEEtutorials"/>.</t> target="IEEEtutorials"/>.</t>
<t>An AFN, a DNS RRTYPE, and a CBOR tag have been assigned for 48-bit <t>An AFN, a DNS RRTYPE, and a CBOR tag have been assigned for 48-bit
MAC addresses as discussed in Sections 2.4, 5.3 and 5.9.</t> MAC addresses, as discussed in Sections <xref target="cbor-tags" format="counter "/>, <xref target="mac-addresses" format="counter"/>, and <xref target="cbor-tag -assign" format="counter"/>.</t>
<t>IEEE Std 802 describes assignment procedures and policies for IEEE <t>IEEE Std 802 describes assignment procedures and policies for
802-related identifiers <xref target="IEEE802_OandA"/>. IEEE RA identifiers related to IEEE 802 <xref target="IEEE802_OandA"/>. IEEE RA
documentation on EUIs, OUIs, and CIDs is available at <xref documentation on EUIs, OUIs, and CIDs is available at <xref
target="IEEEtutorials"/>. </t> target="IEEEtutorials"/>. </t>
<section> <!-- 2.1.1 --> <section anchor="first-oct-bit"> <!-- 2.1.1 -->
<name>Special First Octet Bits</name> <name>Special First Octet Bits</name>
<t>There are bits within the initial octet of an IEEE MAC address that <t>There are bits within the initial octet of an IEEE MAC address that
have special significance <xref target="IEEE802_OandA"/> as have special significance <xref target="IEEE802_OandA"/>, as described as
follows:</t> follows:</t>
<dl> <dl>
<dt>M bit</dt><dd>- This bit is frequently referred to as the group or <dt>M bit -</dt><dd>This bit is frequently referred to as the "group" or
multicast bit. If it is zero, the MAC address is unicast. If it is a "multicast" bit. If it is zero, the MAC address is unicast. If it is a
one, the address is groupcast (multicast or broadcast). This meaning one, the address is groupcast (multicast or broadcast). This meaning
is independent of the values of the X, Y, and Z bits.</dd> is independent of the values of the X, Y, and Z bits.</dd>
<dt>X bit</dt><dd>- This bit is also called the "universal/local" <dt>X bit -</dt><dd>This bit is also called the "universal/local"
bit. If it is zero, the MAC address is a global address under the bit (formerly called the Local/Global bit). If it is zero, the MAC address is a
control of the owner of the IEEE assigned prefix. Previously, if it global address under the
control of the owner of the IEEE-assigned prefix. Previously, if it
was a one, the MAC address was considered "local" and under the was a one, the MAC address was considered "local" and under the
assignment and control of the local network operator (but see Section assignment and control of the local network operator (but see <xref target="bit-
2.3). If it is a one and if the IEEE 802 Structured Local Address Plan 48-ietf"/>). If it is a one and if the IEEE 802 Structured Local Address Plan
(SLAP) is in effect, the nature of the MAC address is optionally (SLAP) is in effect, the nature of the MAC address is optionally
determined by the Y and Z bits as described below.</dd> determined by the Y and Z bits, as described below.</dd>
<dt>Y+Z bits</dt><dd>- These two bits have no special meaning if the X <dt>Y&amp;Z bits -</dt><dd>These two bits have no special meaning if the X
bit is zero. If the X bit is one then, if the IEEE 802 Structured bit is zero. If the X bit is one and if the IEEE 802 Structured
Local Address Plan (SLAP) is in effect, these two bits divide the Local Address Plan (SLAP) is in effect, these two bits divide the
formerly uniform "local" MAC address space into four quadrants, as formerly uniform "local" MAC address space into four quadrants as
follows and further described below:</dd> follows and further described below:</dd>
</dl> </dl>
<table align="center"> <table align="center">
<thead> <thead>
<tr><th>Y bit</th><th>Z bit</th><th>Quadrant</th></tr> <tr><th>Y bit</th><th>Z bit</th><th>Quadrant</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align="center">0</td><td <tr><td align="center">0</td><td
skipping to change at line 442 skipping to change at line 408
</table> </table>
<t>While a local network administrator can assign any addresses with <t>While a local network administrator can assign any addresses with
the X bit a one, the optional SLAP characterizes the four quadrants of the X bit a one, the optional SLAP characterizes the four quadrants of
the "local" address space using the Y and Z bits as follows:</t> the "local" address space using the Y and Z bits as follows:</t>
<dl> <dl>
<dt>Administratively Assigned -</dt> <dt>Administratively Assigned -</dt>
<dd>MAC addresses in this quadrant are called Administratively <dd>MAC addresses in this quadrant are called Administratively
Assigned Identifiers. This is intended for arbitrary local Assigned Identifiers. This is intended for arbitrary local
assignment, such as random assignment; however, see Section assignment, such as random assignment; however, see <xref target="id-33-33"/>.
2.3.1.</dd> </dd>
<dt>Extended Local -</dt> <dt>Extended Local -</dt>
<dd>MAC addresses in this quadrant are called Extended Local <dd>MAC addresses in this quadrant are called Extended Local
Identifiers. These addresses are not actually "local" under Identifiers. These addresses are not actually "local" under
SLAP. They are available to the organization that has been assigned SLAP. They are available to the organization that has been assigned
the CID (see Section 2.1.2) specifying the other 20 bits of the the CID (see <xref target="oui-cid"/>) specifying the other 20 bits of the
24-bit prefix with X, Y, and Z bits having the values 1, 0, and 1 24-bit prefix with X, Y, and Z bits having the values 1, 0, and 1,
respectively.</dd> respectively.</dd>
<dt>Reserved -</dt> <dt>Reserved -</dt>
<dd>MAC addresses in this quadrant are reserved for future use under <dd>MAC addresses in this quadrant are reserved for future use under
the SLAP. Until such future use, they could be locally assigned as the SLAP. Until such future use, they could be locally assigned as
Administratively Assigned Identifiers are assigned but there is a Administratively Assigned Identifiers are assigned, but there is a
danger that future SLAP use would conflict with such local danger that future SLAP use would conflict with such local
assignments.</dd> assignments.</dd>
<dt>Standard Assigned -</dt> <dt>Standard Assigned -</dt>
<dd>MAC addresses in this quadrant are called Standard Assigned <dd>MAC addresses in this quadrant are called Standard Assigned
Identifiers (SAIs). An SAI is assigned by a protocol specified in an Identifiers (SAIs). An SAI is assigned by a protocol specified in an
IEEE 802 standard, for example <xref target="IEEE802.1CQ"/> (but see IEEE 802 standard, for example, <xref target="IEEE802.1CQ"/> (but see
NOTE below).</dd> the first NOTE below).</dd>
</dl> </dl>
<t indent="6">NOTE: While the SLAP has MAC addresses assigned through <t indent="6">NOTE: While the SLAP has MAC addresses assigned through
a local protocol in the SAI quadrant and assigned by a protocol a local protocol in the SAI quadrant and assigned by a protocol
specified in an IEEE 802 standard, the SLAP is optional. Local network specified in an IEEE 802 standard, the SLAP is optional. Local network
administrators may use the IETF protocol provisions in <xref administrators may use the IETF protocol provisions in <xref
target="RFC8947"/> and <xref target="RFC8948"/> which support target="RFC8947"/> and <xref target="RFC8948"/>, which support
assignment of a MAC address in the local MAC address space using assignment of a MAC address in the local MAC address space using
DHCPv6 <xref target="RFC8415"/> or other protocol methods.</t> DHCPv6 <xref target="RFC8415"/> or other protocol methods.</t>
<t indent="3">NOTE: There isn't any automated way to determine if or <t>NOTE: There isn't any automated way to determine if or
to what extent a local network is configured for and/or operating to what extent a local network is configured for and/or operating
according to SLAP.</t> according to SLAP.</t>
</section> <!-- 2.1.1 --> </section> <!-- 2.1.1 -->
<section> <!-- 2.1.2 --> <section anchor="oui-cid"> <!-- 2.1.2 -->
<name>OUIs and CIDs</name> <name>OUIs and CIDs</name>
<t>MA-L, MA-M, and MA-S MAC prefixes are assigned with the Local bit <t>MA-L, MA-M, and MA-S MAC prefixes are assigned with the Local bit
zero. The assignee of an OUI is exclusively authorized to assign zero. The assignee of an OUI is exclusively authorized to assign
group MAC addresses by extending a modified version of the assigned group MAC addresses by extending a modified version of the assigned
OUI in which the M bit (see <xref target="MACaddr"/>) is set to 1 OUI in which the M bit (see <xref target="MACaddr"/>) is set to 1
<xref target="IEEEtutorials"/>.</t> <xref target="IEEEtutorials"/>.</t>
<t>The Local bit is zero for globally unique EUI&nbhy;48 identifiers <t>The Local bit is zero for globally unique EUI&nbhy;48 identifiers
assigned by the owner of a MAC-L or owner of a longer prefix. If the assigned by the owner of a MAC-L or owner of a longer prefix. If the
Local bit is a one, the identifier has historically been a local Local bit is a one, the identifier has historically been a local
identifier under the control of the local network administrator; identifier under the control of the local network administrator;
however, there are now recommendations on optional management of the however, there are now recommendations on optional management of the
local address space as discussed in Section 2.1.1. If the Local bit local address space, as discussed in <xref target="first-oct-bit"/>. If the Loc al bit
is a one, the holder of an OUI has no special authority over MAC is a one, the holder of an OUI has no special authority over MAC
identifiers whose first 3 octets correspond to their OUI or the identifiers whose first 3 octets correspond to their OUI or the
beginning of their longer prefix.</t> beginning of their longer prefix.</t>
<t>A CID is a 24-bit Company Identifier. It is assigned for <t>A CID is a 24-bit Company Identifier. It is assigned for
organizations that need such an identifier that can be used in place organizations that need such an identifier that can be used in place
of an OUI, but do not need to assign subsidiary global MAC of an OUI but do not need to assign subsidiary global MAC
addresses. A CID has X and Z bits equal to 1 and its Y bit equal to 0 addresses. A CID has X and Z bits equal to 1 and its Y bit equal to 0
(see <xref target="MACaddr"/>).</t> (see <xref target="MACaddr"/>).</t>
<t>An AFN and a CBOR tag have been assigned for OUI/CIDs as discussed <t>An AFN and a CBOR tag have been assigned for OUIs/CIDs, as discussed
in Sections 2.4, 5.3 and 5.9.</t> in Sections <xref target="cbor-tags" format="counter"/>, <xref target="mac-addre
sses" format="counter"/>, and <xref target="cbor-tag-assign" format="counter"/>.
</t>
</section> </section>
<section> <!-- 2.1.3 --> <section anchor="bit-48-MAC"> <!-- 2.1.3 -->
<name>48-Bit MAC Assignments under the IANA OUI</name> <name>48-Bit MAC Assignments under the IANA OUI</name>
<t>The OUI 00&nbhy;00&nbhy;5E has been assigned to IANA as stated in <t>The OUI 00&nbhy;00&nbhy;5E has been assigned to IANA, as stated in
<xref target="IANAOUI"/> above. This includes 2**24 48&nbhy;bit <xref target="IANAOUI"/> above. This includes 2**24 48&nbhy;bit
multicast identifiers from 01&nbhy;00&nbhy;5E&nbhy;00&nbhy;00&nbhy;00 multicast identifiers from 01&nbhy;00&nbhy;5E&nbhy;00&nbhy;00&nbhy;00
to 01&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FF&nbhy;FF and 2**24 EUI&nbhy;48 to 01&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FF&nbhy;FF and 2**24 EUI&nbhy;48
unicast identifiers from 00&nbhy;00&nbhy;5E&nbhy;00&nbhy;00&nbhy;00 to unicast identifiers from 00&nbhy;00&nbhy;5E&nbhy;00&nbhy;00&nbhy;00 to
00&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FF&nbhy;FF. </t> 00&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FF&nbhy;FF. </t>
<t>Of these identifiers, the sub-blocks reserved or thus far assigned <t>Of these identifiers, the sub-blocks reserved or thus far assigned
are as follows: </t> are as follows: </t>
<t>Unicast, all blocks of 2**8 addresses thus far: </t> <dl newline="true" spacing="normal">
<dt>Unicast, all blocks of 2**8 addresses thus far: </dt>
<dd>
<dl> <dl>
<dt>00&nbhy;00&nbhy;5E&nbhy;00&nbhy;00&nbhy;00 through <dt>00&nbhy;00&nbhy;5E&nbhy;00&nbhy;00&nbhy;00 through
00&nbhy;00&nbhy;5E&nbhy;00&nbhy;00&nbhy;FF:</dt> 00&nbhy;00&nbhy;5E&nbhy;00&nbhy;00&nbhy;FF:</dt>
<dd>reserved and require IESG Ratification for assignment (see <dd>reserved and require IESG Ratification for assignment (see
Section 5.1).</dd> <xref target="ex-rev-iesg-rat"/>).</dd>
<dt>00&nbhy;00&nbhy;5E&nbhy;00&nbhy;01&nbhy;00 through <dt>00&nbhy;00&nbhy;5E&nbhy;00&nbhy;01&nbhy;00 through
00&nbhy;00&nbhy;5E&nbhy;00&nbhy;01&nbhy;FF:</dt> 00&nbhy;00&nbhy;5E&nbhy;00&nbhy;01&nbhy;FF:</dt>
<dd>assigned for the Virtual Router Redundancy Protocol (VRRP) <xref <dd>assigned for the Virtual Router Redundancy Protocol (VRRP) <xref
target="RFC5798"/>.</dd> target="RFC5798"/>.</dd>
<dt>00&nbhy;00&nbhy;5E&nbhy;00&nbhy;02&nbhy;00 through <dt>00&nbhy;00&nbhy;5E&nbhy;00&nbhy;02&nbhy;00 through
00&nbhy;00&nbhy;5E&nbhy;00&nbhy;02&nbhy;FF:</dt> 00&nbhy;00&nbhy;5E&nbhy;00&nbhy;02&nbhy;FF:</dt>
<dd>assigned for the IPv6 Virtual Router Redundancy Protocol (IPv6 <dd>assigned for the IPv6 Virtual Router Redundancy Protocol (IPv6
VRRP) <xref target="RFC5798"/>.</dd> VRRP) <xref target="RFC5798"/>.</dd>
<dt>00&nbhy;00&nbhy;5E&nbhy;00&nbhy;52&nbhy;00 through <dt>00&nbhy;00&nbhy;5E&nbhy;00&nbhy;52&nbhy;00 through
00&nbhy;00&nbhy;5E&nbhy;00&nbhy;52&nbhy;FF:</dt> 00&nbhy;00&nbhy;5E&nbhy;00&nbhy;52&nbhy;FF:</dt>
<dd>used for very small assignments. As of 2023, 4 out of these 256 <dd>used for very small assignments. As of 2024, 4 out of these 256
values have been assigned. See <xref target="EthernetNum"/>.</dd> values have been assigned. See <xref target="EthernetNum"/>.</dd>
<dt>00&nbhy;00&nbhy;5E&nbhy;00&nbhy;53&nbhy;00 through <dt>00&nbhy;00&nbhy;5E&nbhy;00&nbhy;53&nbhy;00 through
00&nbhy;00&nbhy;5E&nbhy;00&nbhy;53&nbhy;FF:</dt><dd>assigned for use 00&nbhy;00&nbhy;5E&nbhy;00&nbhy;53&nbhy;FF:</dt><dd>assigned for use
in documentation by this document.</dd> in documentation by this document.</dd>
<dt>00&nbhy;00&nbhy;5E&nbhy;90&nbhy;01&nbhy;00 through <dt>00&nbhy;00&nbhy;5E&nbhy;90&nbhy;01&nbhy;00 through
00&nbhy;00&nbhy;5E&nbhy;90&nbhy;01&nbhy;FF:</dt> 00&nbhy;00&nbhy;5E&nbhy;90&nbhy;01&nbhy;FF:</dt>
<dd>used for very small assignments that need parallel unicast and <dd>used for very small assignments that need parallel unicast and
multicast MAC addresses. As of 2023, 1 out of these 256 values has multicast MAC addresses. As of 2024, 1 out of these 256 values has
been assigned. See <xref target="EthernetNum"/>.</dd> been assigned. See <xref target="EthernetNum"/>.</dd>
</dl> </dl>
</dd>
<t>Multicast:</t> <dt>Multicast:</dt>
<dd>
<dl> <dl>
<dt>01&nbhy;00&nbhy;5E&nbhy;00&nbhy;00&nbhy;00 through <dt>01&nbhy;00&nbhy;5E&nbhy;00&nbhy;00&nbhy;00 through
01&nbhy;00&nbhy;5E&nbhy;7F&nbhy;FF&nbhy;FF:</dt> 01&nbhy;00&nbhy;5E&nbhy;7F&nbhy;FF&nbhy;FF:</dt>
<dd>2**23 addresses assigned for IPv4 multicast <xref <dd>2**23 addresses assigned for IPv4 multicast <xref
target="RFC1112"/>.</dd> target="RFC1112"/>.</dd>
<dt>01&nbhy;00&nbhy;5E&nbhy;80&nbhy;00&nbhy;00 through <dt>01&nbhy;00&nbhy;5E&nbhy;80&nbhy;00&nbhy;00 through
01&nbhy;00&nbhy;5E&nbhy;8F&nbhy;FF&nbhy;FF:</dt> 01&nbhy;00&nbhy;5E&nbhy;8F&nbhy;FF&nbhy;FF:</dt>
<dd>2**20 addresses assigned for MPLS multicast <xref <dd>2**20 addresses assigned for MPLS multicast <xref
target="RFC5332"/>. </dd> target="RFC5332"/>. </dd>
<dt>01&nbhy;00&nbhy;5E&nbhy;90&nbhy;00&nbhy;00 through <dt>01&nbhy;00&nbhy;5E&nbhy;90&nbhy;00&nbhy;00 through
01&nbhy;00&nbhy;5E&nbhy;90&nbhy;00&nbhy;FF:</dt> 01&nbhy;00&nbhy;5E&nbhy;90&nbhy;00&nbhy;FF:</dt>
<dd>2**8 addresses being used for very small assignments. As of <dd>2**8 addresses being used for very small assignments. As of
2023, 4 out of these 256 values have been assigned. See <xref 2024, 4 out of these 256 values have been assigned. See <xref
target="EthernetNum"/>.</dd> target="EthernetNum"/>.</dd>
<dt>01&nbhy;00&nbhy;5E&nbhy;90&nbhy;01&nbhy;00 through <dt>01&nbhy;00&nbhy;5E&nbhy;90&nbhy;01&nbhy;00 through
01&nbhy;00&nbhy;5E&nbhy;90&nbhy;01&nbhy;FF:</dt> 01&nbhy;00&nbhy;5E&nbhy;90&nbhy;01&nbhy;FF:</dt>
<dd>used for very small assignments that need parallel unicast and <dd>used for very small assignments that need parallel unicast and
multicast MAC addresses. As of 2023, 1 out of these 256 values has multicast MAC addresses. As of 2024, 1 out of these 256 values has
been assigned. See <xref target="EthernetNum"/>.</dd> been assigned. See <xref target="EthernetNum"/>.</dd>
<dt>01&nbhy;00&nbhy;5E&nbhy;90&nbhy;10&nbhy;00 through <dt>01&nbhy;00&nbhy;5E&nbhy;90&nbhy;10&nbhy;00 through
01&nbhy;00&nbhy;5E&nbhy;90&nbhy;10&nbhy;FF:</dt> 01&nbhy;00&nbhy;5E&nbhy;90&nbhy;10&nbhy;FF:</dt>
<dd>2**8 addresses assigned for use in documentation by this <dd>2**8 addresses assigned for use in documentation by this
document.</dd> document.</dd>
</dl> </dl>
</dd>
</dl>
<t>For more detailed and up-to-date information, see the "Ethernet <t>For more detailed and up-to-date information, see the "IANA OUI Ethernet Numb
Numbers" registry at <xref target="EthernetNum"/>.</t> ers" registry at <xref target="EthernetNum"/>.</t>
</section> </section>
<section> <!-- 2.1.4 --> <section> <!-- 2.1.4 -->
<name>48-Bit MAC Documentation Values</name> <name>48-Bit MAC Documentation Values</name>
<t>The following values have been assigned for use in <t>The following values have been assigned for use in
documentation:</t> documentation:</t>
<ul> <ul>
<li>00&nbhy;00&nbhy;5E&nbhy;00&nbhy;53&nbhy;00 through <li>00&nbhy;00&nbhy;5E&nbhy;00&nbhy;53&nbhy;00 through
00&nbhy;00&nbhy;5E&nbhy;00&nbhy;53&nbhy;FF for unicast and</li> 00&nbhy;00&nbhy;5E&nbhy;00&nbhy;53&nbhy;FF for unicast and</li>
<li>01&nbhy;00&nbhy;5E&nbhy;90&nbhy;10&nbhy;00 through <li>01&nbhy;00&nbhy;5E&nbhy;90&nbhy;10&nbhy;00 through
01&nbhy;00&nbhy;5E&nbhy;90&nbhy;10&nbhy;FF for multicast.</li> 01&nbhy;00&nbhy;5E&nbhy;90&nbhy;10&nbhy;FF for multicast.</li>
</ul> </ul>
</section> </section>
<section> <!-- 2.1.5 --> <section anchor="bit-48-assign-con"> <!-- 2.1.5 -->
<name>48-Bit IANA MAC Assignment Considerations</name> <name>48-Bit IANA MAC Assignment Considerations</name>
<t>48-bit assignments under the current or a future IANA OUI (see <t>48-bit assignments under the current or a future IANA OUI (see
Section 5.6) must meet the following requirements:</t> <xref target="oui-ex"/>) must meet the following requirements:</t>
<ul> <ul>
<li>must be for standards purposes (either for an IETF Standard or <li>must be for standards purposes (either for an IETF Standard or
other standard related to IETF work),</li> other standard related to IETF work),</li>
<li>must be for a power-of-two size block of identifiers starting at <li>must be for a power-of-two-sized block of identifiers starting at
a boundary that is an equal or greater power of two, including the a boundary that is an equal or greater power of two, including the
assignment of one (2**0) identifier, </li> assignment of one (2**0) identifier, </li>
<li>must not be used to evade the requirement for network interface <li>must not be used to evade the requirement for network interface
vendors to obtain their own block of identifiers from the IEEE, and vendors to obtain their own block of identifiers from the IEEE, and
</li> </li>
<li>must be documented in an Internet-Draft or RFC. </li> <li>must be documented in an Internet-Draft or RFC. </li>
</ul> </ul>
<t>In addition, approval must be obtained as follows (see the <t>In addition, approval must be obtained as follows (see the
procedure in Section 5.1):</t> procedure in <xref target="ex-rev-iesg-rat"/>):</t>
<ul> <ul>
<li>Small to medium assignments of a block of 1, 2, 4, ..., 32768, <li>Small to medium assignments of a block of 1, 2, 4, ..., 32768,
65536 (2**0, 2**1, 2**2, ..., 2**15, 2**16) EUI&nbhy;48 identifiers 65536 (2**0, 2**1, 2**2, ..., 2**15, 2**16) EUI&nbhy;48 identifiers
require Expert Review (see Section 5.1).</li> require Expert Review (see <xref target="ex-rev-iesg-rat"/>).</li>
<li>Large assignments of 131072 (2**17) or more EUI&nbhy;48 <li>Large assignments of 131072 (2**17) or more EUI&nbhy;48
identifiers require IESG Ratification (see Section 5.1).</li> identifiers require IESG Ratification (see <xref target="ex-rev-iesg-rat"/>).< /li>
</ul> </ul>
</section> </section>
</section> </section>
<section> <!-- 2.2 --> <section anchor="bit-64"> <!-- 2.2 -->
<name>64-Bit MAC Identifiers</name> <name>64-Bit MAC Identifiers</name>
<t>IEEE also defines a system of 64-bit MAC identifiers including <t>IEEE also defines a system of 64-bit MAC identifiers, including
EUI&nbhy;64s. EUI&nbhy;64 identifiers are used as follows:</t> EUI&nbhy;64s. EUI&nbhy;64 identifiers are used as follows:</t>
<ul> <ul>
<li>In IEEE Std 1394 <xref target="IEEE1394"/> (also known as <li>In IEEE Std 1394 <xref target="IEEE1394"/> (also known as
FireWire and i.Link)</li> FireWire and i.Link)</li>
<li>In IEEE Std 802.15.4 <xref target="IEEE802.15.4"/> (also known <li>In IEEE Std 802.15.4 <xref target="IEEE802.15.4"/> (also known
as ZigBee)</li> as Zigbee)</li>
<li>In <xref target="InfiniBand"/></li> <li>In <xref target="InfiniBand"/></li>
<li>In a modified form to construct some IPv6 interface identifiers <li>In a modified form to construct some IPv6 Interface Identifiers,
as described in Section 2.2.1, although this use is now as described in <xref target="ipv6"/>, although this use is now
deprecated</li> deprecated</li>
</ul> </ul>
<t>Adding a 5-octet (40-bit) extension to a 3-octet (24-bit) <t>Adding a 5-octet (40-bit) extension to a 3-octet (24-bit)
assignment, or a shorter extension to longer assigned prefixes <xref assignment, or a shorter extension to longer assigned prefixes <xref
target="RAC_OUI"/> so as to total 64 bits, produces an EUI&nbhy;64 target="I-D.ieee-rac-oui-restructuring"/> so as to total 64 bits, produces an EU I&nbhy;64
identifier under that OUI or longer prefix. As with EUI&nbhy;48 identifier under that OUI or longer prefix. As with EUI&nbhy;48
identifiers, the first octet has the same special low order bits.</t> identifiers, the first octet has the same special low-order bits.</t>
<t>An AFN, a DNS RRTYPE, and CBOR tag have been assigned for 64-bit <t>An AFN, a DNS RRTYPE, and CBOR tag have been assigned for 64-bit
MAC addresses as discussed in Sections 2.4, 5.3, and 5.9. </t> MAC addresses, as discussed in Sections <xref target="cbor-tags" format="counter "/>, <xref target="mac-addresses" format="counter"/>, and <xref target="cbor-tag -assign" format="counter"/>. </t>
<t>The discussion below is almost entirely in terms of the "Modified" <t>The discussion below is almost entirely in terms of the "Modified"
form of EUI&nbhy;64 identifiers; however, anyone assigned such an form of EUI&nbhy;64 identifiers; however, anyone assigned such an
identifier can also use the unmodified form as a MAC identifier on any identifier can also use the unmodified form as a MAC identifier on any
link that uses such 64-bit identifiers for interfaces. </t> link that uses such 64-bit identifiers for interfaces. </t>
<section> <!-- 2.2.1 --> <section anchor="ipv6"> <!-- 2.2.1 -->
<name>IPv6 Use of Modified EUI&nbhy;64 Identifiers</name> <name>IPv6 Use of Modified EUI&nbhy;64 Identifiers</name>
<t>The approach described below for constructing IPv6 Interface <t>The approach described below for constructing IPv6 Interface
Identifiers is now deprecated and the method specified in <xref Identifiers is now deprecated, and the method specified in <xref
target="RFC8064"/> is recommended.</t> target="RFC8064"/> is recommended.</t>
<t>EUI&nbhy;64 identifiers have been used to form the lower 64 bits of <t>EUI&nbhy;64 identifiers have been used to form the lower 64 bits of
some IPv6 addresses (Section 2.5.1 and Appendix A of <xref some IPv6 addresses (Section <xref target="RFC4291" section="2.5.1" sectionForma
target="RFC4291"/> and Appendix A of <xref target="RFC5214"/>). When t="bare"/> and Appendix <xref target="RFC4291" section="A" sectionFormat="bare"/
so used, the EUI&nbhy;64 is modified by inverting the X (Local/Global) > of <xref
target="RFC4291"/> and <xref target="RFC5214" sectionFormat="of" section="A"/>).
When
so used, the EUI&nbhy;64 is modified by inverting the X (universal/local)
bit to form an IETF "Modified EUI&nbhy;64 identifier". Below is an bit to form an IETF "Modified EUI&nbhy;64 identifier". Below is an
illustration of a Modified EUI&nbhy;64 unicast identifier under the illustration of a Modified EUI&nbhy;64 unicast identifier under the
IANA OUI, where aa-bb-cc-dd-ee is the extension. </t> IANA OUI, where aa-bb-cc-dd-ee is the extension. </t>
<t indent="3">02-00-5E-aa-bb-cc-dd-ee</t> <t indent="3">02-00-5E-aa-bb-cc-dd-ee</t>
<t>The first octet is shown as 02 rather than 00 because, in Modified <t>The first octet is shown as 02 rather than 00 because, in Modified
EUI&nbhy;64 identifiers, the sense of the X bit is inverted compared EUI&nbhy;64 identifiers, the sense of the X bit is inverted compared
with EUI&nbhy;48 identifiers. It is the globally unique values with EUI&nbhy;48 identifiers. It is the globally unique values
(universal scope) that have the 0x02 bit (also known as the X or (universal scope) that have the 0x02 bit (also known as the X or
universal/local bit) on in the first octet, while those with this bit universal/local bit) on in the first octet, while those with this bit
off are typically locally assigned and out of scope for global off are typically locally assigned and out of scope for global
assignment. </t> assignment. </t>
<t>The X (Local/Global) bit was inverted to make it easier for network <t>The X (universal/local) bit was inverted to make it easier for network
operators to type in local-scope identifiers. Thus, such Modified operators to type in local-scope identifiers. Thus, such Modified
EUI&nbhy;64 identifiers as 1, 2, etc. (ignoring leading zeros) are EUI&nbhy;64 identifiers as 1, 2, etc. (ignoring leading zeros) are
local. Without the modification, they would have to be local. Without the modification, they would have to be
02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02, etc. to be 02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02, etc. to be
local.</t> local.</t>
<t>As with 48-bit MAC identifiers, the M-bit (0x01) on in the first <t>As with 48-bit MAC identifiers, the M bit (0x01) on in the first
octet indicates a group identifier (multicast or broadcast). </t> octet indicates a group identifier (multicast or broadcast). </t>
<t>When the first two octets of the extension of a Modified <t>When the first two octets of the extension of a Modified
EUI&nbhy;64 identifier are FF-FE, the remainder of the extension is a EUI&nbhy;64 identifier are FF-FE, the remainder of the extension is a
24-bit value as assigned by the OUI owner for an EUI&nbhy;48. For 24-bit value, as assigned by the OUI owner for an EUI&nbhy;48. For
example: </t> example: </t>
<t indent="3">02-00-5E-FF-FE-yy-yy-yy</t> <t indent="3">02-00-5E-FF-FE-yy-yy-yy</t>
<t>or</t> <t>or</t>
<t indent="3">03-00-5E-FF-FE-yy-yy-yy</t> <t indent="3">03-00-5E-FF-FE-yy-yy-yy</t>
<t>where yy-yy-yy is the portion (of an EUI&nbhy;48 global unicast or <t>where yy-yy-yy is the portion (of an EUI&nbhy;48 global unicast or
multicast identifier) that is assigned by the OUI owner (IANA in this multicast identifier) that is assigned by the OUI owner (IANA in this
case). Thus, any holder of one or more EUI&nbhy;48 identifiers under case). Thus, any holder of one or more EUI&nbhy;48 identifiers under
the IANA OUI also has an equal number of Modified EUI&nbhy;64 the IANA OUI also has an equal number of Modified EUI&nbhy;64
identifiers that can be formed by inserting FF-FE in the middle of identifiers that can be formed by inserting FF-FE in the middle of
their EUI&nbhy;48 identifiers and inverting the Local/Global bit.</t> their EUI&nbhy;48 identifiers and inverting the universal/local bit.</t>
<t>In addition, certain Modified EUI&nbhy;64 identifiers under the <t>In addition, certain Modified EUI&nbhy;64 identifiers under the
IANA OUI are reserved for holders of IPv4 addresses as follows:</t> IANA OUI are reserved for holders of IPv4 addresses as follows:</t>
<t indent="3">02-00-5E-FE-xx-xx-xx-xx</t> <t indent="3">02-00-5E-FE-xx-xx-xx-xx</t>
<t>where xx-xx-xx-xx is a 32-bit IPv4 address. The owner of an IPv4 <t>where xx-xx-xx-xx is a 32-bit IPv4 address. The owner of an IPv4
address has both a unicast- and multicast-derived EUI&nbhy;64 address. address has both a unicast- and multicast-derived EUI&nbhy;64 address.
Modified EUI&nbhy;64 identifiers from </t> Modified EUI&nbhy;64 identifiers from </t>
<t indent="3">02-00-5E-FE-F0-00-00-00 to 02-00-5E-FE-FF-FF-FF-FF</t> <t indent="3">02-00-5E-FE-F0-00-00-00 to 02-00-5E-FE-FF-FF-FF-FF</t>
<t>are effectively reserved pending the specification of IPv4 "Class <t>are effectively reserved pending the specification of IPv4 "Class
E" addresses <xref target="RFC1112"/>. However, for Modified E" addresses <xref target="RFC1112"/>. However, for Modified
EUI&nbhy;64 identifiers based on an IPv4 address, the Local/Global bit EUI&nbhy;64 identifiers based on an IPv4 address, the universal/local bit
should be set to correspond to whether the IPv4 address is local or should be set to correspond to whether the IPv4 address is local or
global. (Keep in mind that the sense of the Modified EUI&nbhy;64 global. (Keep in mind that the sense of the Modified EUI&nbhy;64
identifier Local/Global bit is reversed from that in (unmodified) identifier universal/local bit is reversed from that in (unmodified)
EUI&nbhy;64 identifiers.)</t> EUI&nbhy;64 identifiers.)</t>
</section> </section>
<section> <section anchor="eui-64-assign-con">
<name>EUI&nbhy;64 IANA Assignment Considerations</name> <name>EUI&nbhy;64 IANA Assignment Considerations</name>
<t>The following table shows which Modified EUI&nbhy;64 identifiers <t>The following table shows which Modified EUI&nbhy;64 identifiers
under the IANA OUI are reserved, assigned, or available as indicated. under the IANA OUI are reserved, assigned, or available as indicated.
As noted above, the corresponding MAC addresses can be determined by As noted above, the corresponding MAC addresses can be determined by
complementing the 02 bit in the first octet. In all cases, the complementing the 02 bit in the first octet. In all cases, the
corresponding multicast 64-bit MAC addresses formed by complementing corresponding multicast 64-bit MAC addresses formed by complementing
the 01 bit in the first octet have the same status as the modified the 01 bit in the first octet have the same status as the modified
64-bit unicast address blocks listed below.</t> 64-bit unicast address blocks listed below. These values are prefixed with
02-00-5E to form unicast modified EUI-64 addresses.</t>
<dl>
<dt>02&nbhy;00&nbhy;5E&nbhy;00&nbhy;00&nbhy;00&nbhy;00&nbhy;00 to
02&nbhy;00&nbhy;5E&nbhy;0F&nbhy;FF&nbhy;FF&nbhy;FF&nbhy;FF</dt>
<dd>reserved</dd>
<dt>02&nbhy;00&nbhy;5E&nbhy;10&nbhy;00&nbhy;00&nbhy;00&nbhy;00 to
02&nbhy;00&nbhy;5E&nbhy;10&nbhy;00&nbhy;00&nbhy;00&nbhy;FF</dt>
<dd>assigned for documentation use</dd>
<dt>02&nbhy;00&nbhy;5E&nbhy;10&nbhy;00&nbhy;00&nbhy;01&nbhy;00 to
02&nbhy;00&nbhy;5E&nbhy;EF&nbhy;FF&nbhy;FF&nbhy;FF&nbhy;FF</dt>
<dd>available for assignment</dd>
<dt>02&nbhy;00&nbhy;5E&nbhy;F0&nbhy;00&nbhy;00&nbhy;00&nbhy;00 to
02&nbhy;00&nbhy;5E&nbhy;FD&nbhy;FF&nbhy;FF&nbhy;FF&nbhy;FF</dt>
<dd>reserved</dd>
<dt>02&nbhy;00&nbhy;5E&nbhy;FE&nbhy;00&nbhy;00&nbhy;00&nbhy;00 to
02&nbhy;00&nbhy;5E&nbhy;FE&nbhy;FF&nbhy;FF&nbhy;FF&nbhy;FF</dt>
<dd>assigned to IPv4 address holders as described above</dd>
<dt>02&nbhy;00&nbhy;5E&nbhy;FF&nbhy;00&nbhy;00&nbhy;00&nbhy;00 to
02&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FD&nbhy;FF&nbhy;FF&nbhy;FF</dt>
<dd>reserved</dd>
<dt>02&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FE&nbhy;00&nbhy;00&nbhy;00 to
02&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FE&nbhy;FF&nbhy;FF&nbhy;FF</dt>
<dd>assigned for holders of EUI&nbhy;48 identifiers under the IANA OUI
as described above</dd>
<dt>02&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FF&nbhy;00&nbhy;00&nbhy;00 to <table anchor="table_iana_64_bit_macs">
02&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FF&nbhy;FF&nbhy;FF&nbhy;FF</dt> <name>IANA 64-bit MAC Addresses </name>
<dd>reserved</dd> <thead>
</dl> <tr>
<th>Addresses</th>
<th>Usage</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>00-00-00-00-00 to 0F-FF-FF-FF-FF</td>
<td>Reserved</td>
<td>RFC 9542</td>
</tr>
<tr>
<td>10-00-00-00-00 to 10-00-00-00-FF </td>
<td>Documentation</td>
<td>RFC 9542</td>
</tr>
<tr>
<td>10-00-00-01-00 to EF-FF-FF-FF-FF</td>
<td>Unassigned</td>
<td></td>
</tr>
<tr>
<td>FD-00-00-00-00 to FD-FF-FF-FF-FF</td>
<td>Reserved</td>
<td>RFC 9542</td>
</tr>
<tr>
<td>FE-00-00-00-00 to FE-FF-FF-FF-FF</td>
<td>IPv4 Addr Holders</td>
<td>RFC 9542</td>
</tr>
<tr>
<td>FF-00-00-00-00 to FF-FD-FF-FF-FF</td>
<td>Reserved</td>
<td>RFC 9542</td>
</tr>
<tr>
<td>FF-FE-00-00-00 to FF-FE-FF-FF-FF</td>
<td>IANA EUI-48 Holders</td>
<td>RFC 9542</td>
</tr>
<tr>
<td>FF-FF-00-00-00 to FF-FF-FF-FF-FF</td>
<td>Reserved</td>
<td>RFC 9542</td>
</tr>
</tbody>
</table>
<t>The reserved identifiers above require IESG Ratification (see <t>The reserved identifiers above require IESG Ratification (see
Section 5.1) for assignment. IANA EUI&nbhy;64 identifier assignments <xref target="ex-rev-iesg-rat"/>) for assignment. IANA EUI&nbhy;64 identifier as signments
under the IANA OUI must meet the following requirements:</t> under the IANA OUI must meet the following requirements:</t>
<ul> <ul>
<li>must be for standards purposes (either for an IETF Standard or <li>must be for standards purposes (either for an IETF Standard or
other standard related to IETF work), </li> other standard related to IETF work), </li>
<li>must be for a power-of-two size block of identifiers starting at <li>must be for a power-of-two-sized block of identifiers starting at
a boundary that is an equal or greater power of two, including the a boundary that is an equal or greater power of two, including the
assignment of one (2**0) identifier, </li> assignment of one (2**0) identifier, </li>
<li>must not be used to evade the requirement for network interface <li>must not be used to evade the requirement for network interface
vendors to obtain their own block of identifiers from the IEEE, and vendors to obtain their own block of identifiers from the IEEE, and
</li> </li>
<li>must be documented in an Internet-Draft or RFC. </li> <li>must be documented in an Internet-Draft or RFC. </li>
</ul> </ul>
<t>In addition, approval must be obtained as follows (see the <t>In addition, approval must be obtained as follows (see the
procedure in Section 5.1):</t> procedure in <xref target="ex-rev-iesg-rat"/>):</t>
<ul> <ul>
<li>Small to medium assignments of a block of 1, 2, 4, ..., <li>Small to medium assignments of a block of 1, 2, 4, ...,
134217728, 268435456 (2**0, 2**1, 2**2, ..., 2**27, 2**28) 134217728, 268435456 (2**0, 2**1, 2**2, ..., 2**27, 2**28)
EUI&nbhy;64 identifiers require Expert Review (see Section EUI&nbhy;64 identifiers require Expert Review (see <xref target="ex-rev-iesg-r
5.1).</li> at"/>).</li>
<li>Large assignments of 536870912 (2**29) or more EUI&nbhy;64 <li>Large assignments of 536870912 (2**29) or more EUI&nbhy;64
identifiers require IESG Ratification (see Section 5.1).</li> identifiers require IESG Ratification (see <xref target="ex-rev-iesg-rat"/>).< /li>
</ul> </ul>
</section> </section>
<section> <section>
<name>EUI&nbhy;64 Documentation Values</name> <name>EUI&nbhy;64 Documentation Values</name>
<t>The following blocks of unmodified 64-bit MAC addresses are for <t>The following blocks of unmodified 64-bit MAC addresses are for
documentation use. The IPv4-derived addresses are based on the IPv4 documentation use. The IPv4-derived addresses are based on the IPv4
documentation addresses <xref target="RFC5737"/>, and the MAC-derived documentation addresses <xref target="RFC5737"/>, and the MAC-derived
addresses are based on the EUI&nbhy;48 documentation addresses addresses are based on the EUI&nbhy;48 documentation addresses
above.</t> above.</t>
<t>Unicast values for Documentation Use:</t> <t>Unicast values for documentation use:</t>
<t <t
indent="3">00&nbhy;00&nbhy;5E&nbhy;EF&nbhy;10&nbhy;00&nbhy;00&nbhy;00 indent="3">00&nbhy;00&nbhy;5E&nbhy;EF&nbhy;10&nbhy;00&nbhy;00&nbhy;00
to 00&nbhy;00&nbhy;5E&nbhy;EF&nbhy;10&nbhy;00&nbhy;00&nbhy;FF to 00&nbhy;00&nbhy;5E&nbhy;EF&nbhy;10&nbhy;00&nbhy;00&nbhy;FF
general</t> general</t>
<t <t
indent="3">00&nbhy;00&nbhy;5E&nbhy;FE&nbhy;C0&nbhy;00&nbhy;02&nbhy;00 indent="3">00&nbhy;00&nbhy;5E&nbhy;FE&nbhy;C0&nbhy;00&nbhy;02&nbhy;00
to 00&nbhy;00&nbhy;5E&nbhy;FE&nbhy;C0&nbhy;00&nbhy;02&nbhy;FF and to 00&nbhy;00&nbhy;5E&nbhy;FE&nbhy;C0&nbhy;00&nbhy;02&nbhy;FF and
00&nbhy;00&nbhy;5E&nbhy;FE&nbhy;C6&nbhy;33&nbhy;64&nbhy;00 to 00&nbhy;00&nbhy;5E&nbhy;FE&nbhy;C6&nbhy;33&nbhy;64&nbhy;00 to
skipping to change at line 867 skipping to change at line 852
indent="3">00&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FE&nbhy;00&nbhy;53&nbhy;00 indent="3">00&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FE&nbhy;00&nbhy;53&nbhy;00
to 00&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FE&nbhy;00&nbhy;53&nbhy;FF to 00&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FE&nbhy;00&nbhy;53&nbhy;FF
EUI&nbhy;48 derived</t> EUI&nbhy;48 derived</t>
<t <t
indent="3">00&nbhy;00&nbhy;5E&nbhy;FE&nbhy;EA&nbhy;C0&nbhy;00&nbhy;02 indent="3">00&nbhy;00&nbhy;5E&nbhy;FE&nbhy;EA&nbhy;C0&nbhy;00&nbhy;02
and 00&nbhy;00&nbhy;5E&nbhy;FE&nbhy;EA&nbhy;C6&nbhy;33&nbhy;64 and and 00&nbhy;00&nbhy;5E&nbhy;FE&nbhy;EA&nbhy;C6&nbhy;33&nbhy;64 and
00&nbhy;00&nbhy;5E&nbhy;FE&nbhy;EA&nbhy;CB&nbhy;00&nbhy;71 IPv4 00&nbhy;00&nbhy;5E&nbhy;FE&nbhy;EA&nbhy;CB&nbhy;00&nbhy;71 IPv4
multicast derived from IPv4 unicast <xref target="RFC6034"/></t> multicast derived from IPv4 unicast <xref target="RFC6034"/></t>
<t>Multicast values for Documentation Use:</t> <t>Multicast values for documentation use:</t>
<t <t
indent="3">01&nbhy;00&nbhy;5E&nbhy;EF&nbhy;10&nbhy;00&nbhy;00&nbhy;00 indent="3">01&nbhy;00&nbhy;5E&nbhy;EF&nbhy;10&nbhy;00&nbhy;00&nbhy;00
to 01&nbhy;00&nbhy;5E&nbhy;EF&nbhy;10&nbhy;00&nbhy;00&nbhy;FF to 01&nbhy;00&nbhy;5E&nbhy;EF&nbhy;10&nbhy;00&nbhy;00&nbhy;FF
general</t> general</t>
<t <t
indent="3">01&nbhy;00&nbhy;5E&nbhy;FE&nbhy;C0&nbhy;00&nbhy;02&nbhy;00 indent="3">01&nbhy;00&nbhy;5E&nbhy;FE&nbhy;C0&nbhy;00&nbhy;02&nbhy;00
to 01&nbhy;00&nbhy;5E&nbhy;FE&nbhy;C0&nbhy;00&nbhy;02&nbhy;FF and to 01&nbhy;00&nbhy;5E&nbhy;FE&nbhy;C0&nbhy;00&nbhy;02&nbhy;FF and
01&nbhy;00&nbhy;5E&nbhy;FE&nbhy;C6&nbhy;33&nbhy;64&nbhy;00 to 01&nbhy;00&nbhy;5E&nbhy;FE&nbhy;C6&nbhy;33&nbhy;64&nbhy;00 to
skipping to change at line 898 skipping to change at line 883
<t <t
indent="3">01&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FE&nbhy;90&nbhy;10&nbhy;00 indent="3">01&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FE&nbhy;90&nbhy;10&nbhy;00
to 01&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FE&nbhy;90&nbhy;10&nbhy;FF to 01&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FE&nbhy;90&nbhy;10&nbhy;FF
EUI&nbhy;48 derived</t> EUI&nbhy;48 derived</t>
</section> </section>
</section> <!-- 2.2 --> </section> <!-- 2.2 -->
<section> <section anchor="bit-48-ietf">
<name>Other 48-bit MAC Identifiers Used by the IETF</name> <name>Other 48-Bit MAC Identifiers Used by the IETF</name>
<t>There are two other blocks of 48-bit MAC identifiers that are used <t>There are two other blocks of 48-bit MAC identifiers that are used
by the IETF as described below.</t> by the IETF as described below.</t>
<section> <section anchor="id-33-33">
<name>Identifiers with a '33-33' Prefix</name> <name>Identifiers with a '33-33' Prefix</name>
<t>All 48-bit multicast MAC identifiers prefixed "33-33" (that is, the <t>All 48-bit multicast MAC identifiers prefixed with "33-33" (that is, the
2**32 multicast MAC identifiers in the range from 33-33-00-00-00-00 to 2**32 multicast MAC identifiers in the range from 33-33-00-00-00-00 to
33-33-FF-FF-FF-FF) are used as specified in <xref target="RFC2464"/> 33-33-FF-FF-FF-FF) are used as specified in <xref target="RFC2464"/>
for IPv6 multicast. In all of these identifiers, the Group bit (the for IPv6 multicast. In all of these identifiers, the Group bit (the
bottom bit of the first octet) is on, as is required to work properly bottom bit of the first octet) is on, as is required to work properly
with existing hardware as a multicast identifier. They also have the with existing hardware as a multicast identifier. They also have the
Local bit on but any Ethernet using standard IPv6 multicast should Local bit on, but any Ethernet using standard IPv6 multicast should
note that these addresses will be used for that purpose. These note that these addresses will be used for that purpose. These
multicast MAC addresses fall into the Administratively Assigned SLAP multicast MAC addresses fall into the Administratively Assigned SLAP
quadrant (see Section 2.1.1).</t> quadrant (see <xref target="first-oct-bit"/>).</t>
<t indent="3">Historical notes: It was the custom during IPv6 design <aside>
to use "3" for unknown or example values and 3333 Coyote Hill Road, <t>Historical Notes: It was the custom during IPv6 design
Palo Alto, California, is the address of PARC (Palo Alto Research to use "3" for unknown or example values, and 3333 Coyote Hill Road,
Center, formerly "Xerox PARC"). Ethernet was originally specified by Palo Alto, California is the address of PARC (Palo Alto Research
Center), formerly "Xerox PARC." Ethernet was originally specified by
the Digital Equipment Corporation, Intel Corporation, and Xerox the Digital Equipment Corporation, Intel Corporation, and Xerox
Corporation. The pre-IEEE <xref target="IEEE.802.3_2012"/> Ethernet Corporation. The pre-IEEE <xref target="IEEE.802.3_2012"/> Ethernet
protocol has sometimes been known as "DIX" Ethernet from the first protocol has sometimes been known as "DIX" Ethernet from the first
letters of the names of these companies.</t> letters of the names of these companies.</t>
</aside>
</section> </section>
<section> <section>
<name>The 'CF Series'</name>
<name>The CF Series</name>
<t>The Informational <xref target="RFC2153"/> declared the 3-octet <t>The Informational <xref target="RFC2153"/> declared the 3-octet
values from CF&nbhy;00&nbhy;00 through CF&nbhy;FF&nbhy;FF to be "OUIs" values from CF&nbhy;00&nbhy;00 through CF&nbhy;FF&nbhy;FF to be "OUIs"
available for assignment by IANA to software vendors for use in PPP available for assignment by IANA to software vendors for use in PPP
<xref target="RFC1661"/> or for other uses where vendors do not <xref target="RFC1661"/> or for other uses where vendors do not
otherwise need an IEEE-assigned OUI. When used as 48-bit MAC prefixes, otherwise need an IEEE-assigned OUI. When used as 48-bit MAC prefixes,
these values have all of the Z, Y, X (Local), and M (Group) special these values have all of the Z, Y, X (Local) and M (Group) special
bits at the bottom of the first octet equal to one, while all bits at the bottom of the first octet equal to one, while all
IEEE-assigned OUIs thus far have the X and M bits zero and all CIDs IEEE-assigned OUIs thus far have the X and M bits as zero and all CIDs
have bits Y and M zero; thus, there can be no conflict between CF have the Y and M bits as zero; thus, there can be no conflict between CF
Series "OUI"s and IEEE assigned OUI/CIDs. Multicast MAC addresses series "OUIs" and IEEE-assigned OUIs/CIDs. Multicast MAC addresses
constructed with a "CF" series OUI would fall into the Standard constructed with a CF series OUI would fall into the Standard
Assigned SLAP quadrant (see Section 2.1.1). The Group bit is Assigned SLAP quadrant (see <xref target="first-oct-bit"/>). The Group bit is
meaningless in PPP. To quote <xref target="RFC2153"/>: "The 'CF0000' meaningless in PPP. To quote <xref target="RFC2153"/>: "The 'CF0000'
series was arbitrarily chosen to match the PPP NLPID 'CF', as a matter series was arbitrarily chosen to match the PPP NLPID 'CF', as a matter
of mnemonic convenience." (For further information on NLPIDs, see of mnemonic convenience." (For further information on Network Layer Protocol Id entifiers (NLPIDs), see
<xref target="RFC6328"/>.)</t> <xref target="RFC6328"/>.)</t>
<t indent="3">CF&nbhy;00&nbhy;00 is reserved, and IANA lists <t indent="3">CF&nbhy;00&nbhy;00 is reserved. CF&nbhy;00&nbhy;00&nbhy;00&nbhy;0
multicast identifier</t> 0&nbhy;00 is a multicast identifier
listed by IANA as used for Ethernet loopback tests.</t>
<t indent="3">CF&nbhy;00&nbhy;00&nbhy;00&nbhy;00&nbhy;00 as
used for Ethernet loopback tests.</t>
<t>In over a decade of availability, only a handful of values in the <t>In over a decade of availability, only a handful of values in the
CF Series have been assigned. (See "IANA OUI Ethernet Numbers" <xref CF series have been assigned. (See the "IANA OUI Ethernet Numbers" <xref
target="EthernetNum"/> and "PPP Numbers" <xref target="PPPNum"/> target="EthernetNum"/> and "Point-to-Point (PPP) Protocol Field Assignments" <xr
).</t> ef target="PPPNum"/> registry groups.)</t>
<section> <section>
<name>Changes to RFC 2153</name> <name>Changes to RFC 2153</name>
<t>The IANA Considerations in <xref target="RFC2153"/> were updated as <t>The IANA Considerations in <xref target="RFC2153"/> were updated as
follows by the approval of <xref target="RFC5342"/> and remain so updated (no follows by the approval of <xref target="RFC5342"/> and remain so updated (no
technical changes have been made):</t> technical changes have been made):</t>
<ul> <ul>
<li>Use of these 'CF Series' identifiers based on IANA assignment was <li>Use of these CF series identifiers based on IANA assignment was
deprecated.</li> deprecated.</li>
<li>IANA was instructed not to assign any further values in the 'CF <li>IANA was instructed not to assign any further values in the CF
Series'.</li> series.</li>
</ul> </ul>
</section> </section>
</section> </section>
</section> <!-- 2.3 --> </section> <!-- 2.3 -->
<section> <section anchor="cbor-tags">
<name>CBOR Tags</name> <name>CBOR Tags</name>
<t>The Concise Binary Object Representation (CBOR <xref <t>The Concise Binary Object Representation (CBOR) <xref
target="RFC8949"/>) is a data format whose design goals include the target="RFC8949"/> is a data format whose design goals include the
possibility of very small code size, fairly small message size, and possibility of very small code size, fairly small message size, and
extensibility. In CBOR, a data item can be enclosed by a CBOR tag to extensibility. In CBOR, a data item can be enclosed by a CBOR tag to
give it some additional semantics identified by that tag. CBOR tagged give it some additional semantics identified by that tag. CBOR-tagged
data items (fields) are not used in actual IEEE 802 address fields but data items (fields) are not used in actual IEEE 802 address fields but
may be used in CBOR encoded parts of protocol messages.</t> may be used in CBOR-encoded parts of protocol messages.</t>
<t>IANA has assigned TBD1 as the CBOR tag to indicate a MAC <t>IANA has assigned 48 as the CBOR tag to indicate a MAC
address. The enclosed data item is an octet string. The length of the address. The enclosed data item is an octet string. The length of the
octet string indicates whether a 48-bit (6 octet) or 64-bit (8 octet) MAC octet string indicates whether a 48-bit (6 octet) or 64-bit (8 octet) MAC
address is encoded. Should some other multiple of 8 bits length MAC address is encoded. Should some other multiple of 8 bits be used in the
addresses be used in the future, such as a 128-bit (16 octet) MAC future for the length of MAC addresses, such as a 128-bit (16-octet) MAC
address, the TBD1 tag will be used.</t> address, the 48 tag will be used.</t>
<t>IANA has assigned TDB2 as the CBOR tag to indicate an OUI, CID, or <t>IANA has assigned 1048 as the CBOR tag to indicate an OUI, CID, or
"CF" series organizational identifier. The enclosed data item is an CF series organizational identifier. The enclosed data item is an
octet string of length 3 to hold the 24-bit OUI or CID (see Section octet string of length 3 to hold the 24-bit OUI or CID (see <xref target="oui-ci
2.1.2).</t> d"/>).</t>
</section> <!-- 2.4 --> </section> <!-- 2.4 -->
</section> <!-- 2. Ethernet Identifier Parameters --> </section> <!-- 2. Ethernet Identifier Parameters -->
<section> <!-- 3. --> <section anchor="eth-pro-param"> <!-- 3. -->
<name>Ethernet Protocol Parameters</name> <name>Ethernet Protocol Parameters</name>
<t>Ethernet protocol parameters provide a means of indicating, near <t>Ethernet protocol parameters provide a means of indicating, near
the beginning of a frame, the contents of that frame -- for example, the beginning of a frame, the contents of that frame -- for example,
that it contains IPv4 or IPv6.</t> that it contains IPv4 or IPv6.</t>
<t>There are two types of protocol identifier parameters (See <xref <t>There are two types of protocol identifier parameters (see <xref
target="EthernetNum"/>) that can occur in Ethernet frames as target="EthernetNum"/>) that can occur in Ethernet frames:</t>
follows:</t>
<dl> <dl newline="true">
<dt>EtherTypes:</dt> <dt>EtherTypes:</dt>
<dd>These are 16-bit identifiers which, when considered as an <dd>These are 16-bit identifiers that, when considered as an
unsigned integer, are equal to or larger than 0x0600. <xref unsigned integer, are equal to or larger than 0x0600. <xref
target="EtherType"/> shows the simplest case where the EtherType of the target="EtherType"/> shows the simplest case where the EtherType of the
protocol data in the frame appears immediately after the destination protocol data in the frame appears immediately after the destination
and source MAC addresses. <xref target="IEEE802_OandA"/> specifies and source MAC addresses. <xref target="IEEE802_OandA"/> specifies
two EtherTypes for local, experimental use: 0x88B5 and 0x88B6.</dd> two EtherTypes for local, experimental use: 0x88B5 and 0x88B6.</dd>
<dt>LSAPs:</dt> <dt>LSAPs:</dt>
<dd>These are 8-bit protocol identifiers that occur in pairs after a <dd>These are 8-bit protocol identifiers that occur in pairs after a
field that gives the frame length. Such a length must, when field that gives the frame length. Such a length must, when
considered as an unsigned integer, be less than 0x5DD, or it could considered as an unsigned integer, be less than 0x5DD, or it could
be mistaken as an EtherType. However, the LLC encapsulation be mistaken as an EtherType. However, the LLC encapsulation
EtherType 0x8870 <xref target="IEEE802.1AC"/> may also be used in EtherType 0x8870 <xref target="IEEE802.1AC"/> may also be used in
place of such a length as a "length indication" of nonspecific place of such a length as a "length indication" of nonspecific
length. LSAPs occur in pairs where one is intended to indicate the length. LSAPs occur in pairs, where one is intended to indicate the
source protocol handler (SSAP) and one the destination protocol source protocol handler (SSAP) and the other the destination protocol
handler (DSAP); however, use cases where the two are different have handler (DSAP); however, use cases where the two are different have
been relatively rare. See <xref target="LSAP"/> for the simplest been relatively rare. See <xref target="LSAP"/> for the simplest
case where the length field appears immediately after the case where the length field appears immediately after the
destination and source MAC addresses. In that figure, the CTL destination and source MAC addresses. In that figure, the CTL
(control) field value of 3 indicates datagram service. This type of (control) field value of 3 indicates datagram service. This type of
protocol identification is sometimes called "LLC" (Logical Link protocol identification is sometimes called "LLC" (Logical Link
Control).</dd> Control).</dd>
</dl> </dl>
<figure anchor="EtherType"> <figure anchor="EtherType">
skipping to change at line 1084 skipping to change at line 1066
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CTL = 0x03 | Protocol Data /// | CTL = 0x03 | Protocol Data ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]> ]]>
</artwork> </artwork>
</figure> </figure>
<t>The concept of EtherType labeling has been extended to labeling by <t>The concept of EtherType labeling has been extended to labeling by
Ethernet "tags". An Ethernet tag in this sense is a prefix whose type Ethernet "tags". An Ethernet tag in this sense is a prefix whose type
is identified by an EtherType that is then followed by either another is identified by an EtherType that is then followed by either another
tag, an EtherType, or an LLC LSAP (Link-Layer Service Access Point) tag, an EtherType, or an LLC Link-Layer Service Access Point (LSAP)
protocol indicator for the "main" body of the frame. Customarily, protocol indicator for the "main" body of the frame. Customarily,
in the <xref target="IEEE802_OandA"/> world, tags are a fixed length in the world of <xref target="IEEE802_OandA"/>, tags are a fixed length
and do not include any encoding of their own length. An example is and do not include any encoding of their own length. An example is
the C-Tag (formerly the Q-Tag) <xref target="IEEE.802.1Q_2014"/>. It the C-Tag (formerly the Q-Tag) <xref target="IEEE.802.1Q_2014"/>. It
provides customer VLAN and priority information for a frame. Any provides customer VLAN and priority information for a frame. Any
device that is processing a frame cannot, in general, safely process device that is processing a frame cannot, in general, safely process
anything in the frame past an EtherType it does not understand. </t> anything in the frame past an EtherType it does not understand. </t>
<t>Neither EtherTypes nor LSAPs are assigned by IANA; they are <t>Neither EtherTypes nor LSAPs are assigned by IANA; they are
assigned by the IEEE Registration Authority <xref target="IEEE_RA"/> assigned by the IEEE Registration Authority <xref target="IEEE_RA"/>
(see <xref target="IEEEregAuth"/> above and Appendix B). However, (see <xref target="IEEEregAuth"/> and <xref target="ethertypes"/>). However,
both LSAPs and EtherTypes have extension mechanisms so that they can both LSAPs and EtherTypes have extension mechanisms so that they can
be used with five-octet Ethernet protocol identifiers under an OUI, be used with five-octet Ethernet protocol identifiers under an OUI,
including those assigned by IANA under the IANA OUI.</t> including those assigned by IANA under the IANA OUI.</t>
<t>When using the IEEE 802 Logical Link Control (LLC) format <t>When using the IEEE 802 Logical Link Control (LLC) format
(Subnetwork Access Protocol (SNAP)) <xref target="IEEE802_OandA"/> for (Subnetwork Access Protocol (SNAP)) <xref target="IEEE802_OandA"/> for
a frame, an OUI-based protocol identifier can be expressed as a frame, an OUI-based protocol identifier can be expressed as
follows:</t> follows:</t>
<t <t
skipping to change at line 1140 skipping to change at line 1122
EtherType. Putting the EtherType as the zz&nbhy;zz field after an EtherType. Putting the EtherType as the zz&nbhy;zz field after an
all-zeros OUI (00&nbhy;00&nbhy;00) does this. It looks like </t> all-zeros OUI (00&nbhy;00&nbhy;00) does this. It looks like </t>
<t <t
indent="3">xx&nbhy;xx&nbhy;AA&nbhy;AA&nbhy;03&nbhy;00&nbhy;00&nbhy;00&nbhy;zz&nb hy;zz indent="3">xx&nbhy;xx&nbhy;AA&nbhy;AA&nbhy;03&nbhy;00&nbhy;00&nbhy;00&nbhy;zz&nb hy;zz
</t> </t>
<t>where zz&nbhy;zz is the EtherType.</t> <t>where zz&nbhy;zz is the EtherType.</t>
<t>As well as labeling frame contents, IEEE 802 protocol types appear <t>As well as labeling frame contents, IEEE 802 protocol types appear
within NBMA (Non-Broadcast Multi-Access) Next Hop Resolution Protocol within Non-Broadcast Multi-Access (NBMA) Next Hop Resolution Protocol
<xref target="RFC2332"/> messages. Such messages have provisions for <xref target="RFC2332"/> messages. Such messages have provisions for
both two-octet EtherTypes and OUI-based protocol types. 16-bit both two-octet EtherTypes and OUI-based protocol types. 16-bit
EtherTypes also occur in the Generic Router Encapsulation (GRE <xref EtherTypes also occur in the Generic Routing Encapsulation (GRE) <xref
target="RFC2784"/>) header and in the GENEVE (Generic Network target="RFC2784"/> header and in the Generic Network
Virtualization Encapsulation <xref target="RFC8926"/>) encapsulation Virtualization Encapsulation (Geneve) <xref target="RFC8926"/> encapsulation
header.</t> header.</t>
<section> <section anchor="eth-pro-iana-oui">
<name>Ethernet Protocol Assignment under the IANA OUI</name> <name>Ethernet Protocol Assignment under the IANA OUI</name>
<t>Two-octet protocol numbers under the IANA OUI are available, as in <t>Two-octet protocol numbers under the IANA OUI are available, as in
</t> </t>
<t indent="3">88&nbhy;B7&nbhy;00&nbhy;00&nbhy;5E&nbhy;qq&nbhy;qq </t> <t indent="3">88&nbhy;B7&nbhy;00&nbhy;00&nbhy;5E&nbhy;qq&nbhy;qq </t>
<t>or</t> <t>or</t>
<t <t
indent="3">xx&nbhy;xx&nbhy;AA&nbhy;AA&nbhy;03&nbhy;00&nbhy;00&nbhy;5E&nbhy;qq&nb hy;qq indent="3">xx&nbhy;xx&nbhy;AA&nbhy;AA&nbhy;03&nbhy;00&nbhy;00&nbhy;5E&nbhy;qq&nb hy;qq
</t> </t>
<t>where qq&nbhy;qq is the protocol number. </t> <t>where qq&nbhy;qq is the protocol number. </t>
<t>A number of such assignments have been made out of the 2**16 <t>A number of such assignments have been made out of the 2**16
protocol numbers available from 00&nbhy;00&nbhy;5E&nbhy;00&nbhy;00 to protocol numbers available from 00&nbhy;00&nbhy;5E&nbhy;00&nbhy;00 to
00&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FF (see <xref target="EthernetNum"/>). 00&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FF (see <xref target="EthernetNum"/>).
The extreme values of this range, 00&nbhy;00&nbhy;5E&nbhy;00&nbhy;00 The extreme values of this range, 00&nbhy;00&nbhy;5E&nbhy;00&nbhy;00
and 00&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FF, are reserved and require IESG and 00&nbhy;00&nbhy;5E&nbhy;FF&nbhy;FF, are reserved and require IESG
Ratification for assignment (see Section 5.1). New assignments of Ratification for assignment (see <xref target="ex-rev-iesg-rat"/>). New assignm ents of
protocol numbers (qq&nbhy;qq) under the IANA OUI must meet the protocol numbers (qq&nbhy;qq) under the IANA OUI must meet the
following requirements: </t> following requirements: </t>
<ul> <ul>
<li>the assignment must be for standards use (either for an IETF <li>the assignment must be for standards use (either for an IETF
Standard or other standard related to IETF work), </li> Standard or other standard related to IETF work), </li>
<li>the protocol must include a version field at a fixed offset or <li>the protocol must include a version field at a fixed offset or
an equivalent marking such that later version can be indicated in a an equivalent marking such that later versions can be indicated in a
way recognizable by earlier versions, </li> way recognizable by earlier versions, </li>
<li>it must be documented in an Internet-Draft or RFC, and </li> <li>the protocol must be documented in an Internet-Draft or RFC, and </li>
<li>such protocol numbers are not to be assigned for any protocol <li>such protocol numbers are not to be assigned for any protocol
that has an EtherType. (Either that EtherType can be used directly that has an EtherType. (That EtherType can be used directly, or
or, in the LSAPs case, using the SNAP SAP and putting an all-zeros -- in the LSAPs case -- it can be used with the SNAP SAP by putting
"OUI" before the EtherType as described above.) </li> an all-zero "OUI" before the EtherType as described above.)</li>
</ul> </ul>
<t>In addition, the Expert Review (or IESG Ratification for the two <t>In addition, the Expert Review (or IESG Ratification for the two
reserved values) must be obtained using the procedure specified in reserved values) must be obtained using the procedure specified in
Section 5.1.</t> <xref target="ex-rev-iesg-rat"/>.</t>
</section> <!-- 3.1 --> </section> <!-- 3.1 -->
<section> <section>
<name>Documentation Protocol Number</name> <name>Documentation Protocol Number</name>
<t>0x0042 is a protocol number under the IANA OUI (that is, <t>0x0042 is a protocol number under the IANA OUI (that is,
00&nbhy;00&nbhy;5E&nbhy;00&nbhy;42) to be used as an example for 00&nbhy;00&nbhy;5E&nbhy;00&nbhy;42) to be used as an example for
documentation purposes.</t> documentation purposes.</t>
</section> <!-- 3.2 --> </section> <!-- 3.2 -->
</section> <!-- 3. Ethernet Protocol Paraeeters --> </section> <!-- 3. Ethernet Protocol Paraeeters -->
<section> <!-- 4. --> <section> <!-- 4. -->
<name>Other OUI/CID-Based Parameters</name> <name>Other OUI/CID-Based Parameters</name>
<t>Some IEEE 802 and other protocols provide for parameters based on <t>Some IEEE 802 and other protocols provide for parameters based on
an OUI or CID beyond those discussed above. Such parameters commonly an OUI or CID beyond those discussed above. Such parameters commonly
consist of an OUI or CID plus one octet of additional value. They are consist of an OUI or CID plus one octet of additional value. They are
called Organizationally-Specific parameters (sometimes informally and called Organizationally Specific parameters (sometimes informally and
less accurately referred to as "vendor specific"). They would look less accurately referred to as "vendor specific"). They would look
like</t> like</t>
<t indent="3">yy&nbhy;yy&nbhy;yy&nbhy;zz</t> <t indent="3">yy&nbhy;yy&nbhy;yy&nbhy;zz</t>
<t>where yy&nbhy;yy&nbhy;yy is the OUI/CID and zz is the additional <t>where yy&nbhy;yy&nbhy;yy is the OUI/CID and zz is the additional
specifier. An example is the Cipher Suite Selector in <xref specifier. An example is the Cipher Suite Selector in <xref
target="IEEE.802.11_2012"/>.</t> target="IEEE.802.11_2012"/>.</t>
<t>Values may be assigned under the IANA OUI for such other OUI-based <t>Values may be assigned under the IANA OUI for other OUI-based
parameter usage by Expert Review except that, for each use, the parameter usage by Expert Review, except that, for each use, the
additional specifier values consisting of all zero bits and all one additional specifier values consisting of all zero bits and all one
bits (0x00 (00&nbhy;00&nbhy;5E&nbhy;00) and 0xFF bits (0x00 (00&nbhy;00&nbhy;5E&nbhy;00) and 0xFF
(00&nbhy;00&nbhy;5E&nbhy;FF) for a one-octet specifier) are reserved (00&nbhy;00&nbhy;5E&nbhy;FF) for a one-octet specifier) are reserved
and require IESG Ratification (see Section 5.1) for assignment; also, and require IESG Ratification (see <xref target="ex-rev-iesg-rat"/>) for assignm ent; also,
the additional specifier value 0x42 (00&nbhy;00&nbhy;5E&nbhy;42 for a the additional specifier value 0x42 (00&nbhy;00&nbhy;5E&nbhy;42 for a
one octet specifier, right justified and filled with zeros on the left one octet specifier, right justified and filled with zeros on the left
if the specifier is more than one octet) is assigned for use as an if the specifier is more than one octet) is assigned for use as an
example in documentation.</t> example in documentation.</t>
<t>Assignments of such other IANA OUI-based parameters must be for <t>Assignments of other IANA OUI-based parameters must be for
standards use (either for an IETF Standard or other standard related standards use (either for an IETF Standard or other standard related
to IETF work) and be documented in an Internet-Draft or RFC. The to IETF work) and be documented in an Internet-Draft or RFC. The
first time a value is assigned for a particular parameter of this first time a value is assigned for a particular parameter of this
type, an IANA registry will be created to contain that assignment and type, an IANA registry will be created to contain that assignment and
any subsequent assignments of values for that parameter under the IANA any subsequent assignments of values for that parameter under the IANA
OUI. The Expert may specify the name of the registry.</t> OUI. The Expert may specify the name of the registry.</t>
<t>If different policies from those above are required for such a <t>If different policies from those above are required for such a
parameter, a BCP or Standards Track RFC should be adopted to update parameter, a BCP or Standards Track RFC should be adopted to update
this BCP and specify the new policy and parameter.</t> this BCP and specify the new policy and parameter.</t>
<section> <section anchor="lldp-ietf-tlv">
<name>LLDP IETF Organizationally-Specific TLV Type</name> <name>LLDP IETF Organizationally Specific TLV Type</name>
<t>An example of such an "other IANA OUI based parameter" is specified <t>An example of an "other IANA OUI-based parameter" is specified
in <xref target="RFC8520"/>. This provides for an in <xref target="RFC8520"/>. This provides for an
Organizationally-Specific TLV type for announcing a Manufacturer Usage Organizationally Specific TLV type for announcing a Manufacturer Usage
Description (MUD) Uniform Resource Locator (URL) in the IEEE Link Description (MUD) Uniform Resource Locator (URL) in the IEEE Link
Local Discovery Protocol (LLDP <xref Local Discovery Protocol (LLDP) <xref
target="IEEE802.1AB"/>). Additional IETF use of code points in this target="IEEE802.1AB"/>. Additional IETF use of code points in this
space have been proposed <xref target="BGP11dp"/>. (See also Section space have been proposed <xref target="I-D.acee-idr-lldp-peer-discovery"/>. (See
5.8.)</t> also <xref target="lldp-tlv"/>.)</t>
</section> <!-- 4.1 --> </section> <!-- 4.1 -->
</section> <!-- 4. Other OUI-Based Parameters --> </section> <!-- 4. Other OUI-Based Parameters -->
<section> <!-- 5. --> <section> <!-- 5. -->
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document concerns IANA considerations for the assignment of <t>This document concerns IANA considerations for the assignment of
Ethernet parameters in connection with the IANA OUI and related Ethernet parameters in connection with the IANA OUI and related
matters.</t> matters.</t>
<t indent="3">Note: The "IETF OUI Ethernet Numbers" IANA Registry <t indent="3">Note: The "IANA OUI Ethernet Numbers" registry
Group (web page) is for registries of numbers assigned under the IANA group (web page) is for registries of numbers assigned under the IANA
OUI while the "IEEE 802 Numbers" IANA Registry Group has informational OUI, while the "IEEE 802 Numbers" registry group has informational
lists of numbers assigned by the IEEE Registration Authority.</t> lists of numbers assigned by the IEEE Registration Authority.</t>
<t>This document does not create any new IANA registries.</t> <t>This document does not create any new IANA registries.</t>
<t>The MAC address values assigned for documentation and the protocol <t>The MAC address values assigned for documentation and the protocol
number for documentation were both assigned by <xref number for documentation were both assigned by <xref
target="RFC7042"/>. </t> target="RFC7042"/>. </t>
<t>No existing assignment is changed by this document.</t> <t>No existing assignment is changed by this document.</t>
<section> <!-- 5.1 --> <section anchor="ex-rev-iesg-rat"> <!-- 5.1 -->
<name>Expert Review and IESG Ratification</name> <name>Expert Review and IESG Ratification</name>
<t>This section specifies the procedures for Expert Review and IESG <t>This section specifies the procedures for Expert Review and IESG
Ratification of MAC, protocol, and other IANA OUI-based identifiers. Ratification of MAC, protocol, and other IANA OUI-based identifiers.
The Expert(s) referred to in this document shall consist of one or The Expert(s) referred to in this document shall consist of one or
more persons appointed by and serving at the pleasure of the more persons appointed by and serving at the pleasure of the
IESG. </t> IESG. </t>
<section> <!-- 5.1.1 --> <section> <!-- 5.1.1 -->
<name>Expert Review Guidance</name> <name>Expert Review Guidance</name>
<t>The procedure described for Expert Review assignments in this <t>The procedure described for Expert Review assignments in this
document is consistent with the IANA Expert Review policy described in document is consistent with the IANA Expert Review policy described in
<xref target="RFC8126"/>. </t> <xref target="RFC8126"/>. </t>
<t>While finite, the universe of MAC code points from which <t>While finite, the universe of MAC code points from which
Expert-judged assignments will be made is felt to be large enough that Expert-judged assignments will be made is considered to be large enough that
the requirements given in this document and the Experts' good judgment the requirements given in this document and the Experts' good judgment
are sufficient guidance. The idea is for the Expert to provide a are sufficient guidance. The idea is for the Expert to provide a
light sanity check for small assignments of MAC identifiers, with light reasonableness check for small assignments of MAC identifiers, with
increased scrutiny by the Expert for medium-sized assignments of MAC increased scrutiny by the Expert for medium-sized assignments of MAC
identifiers and assignments of protocol identifiers and other IANA identifiers and assignments of protocol identifiers and other IANA
OUI-based parameters.</t> OUI-based parameters.</t>
</section> </section>
<section> <!-- 5.1.2 --> <section> <!-- 5.1.2 -->
<name>Expert Review and IESG Ratification Procedure</name> <name>Expert Review and IESG Ratification Procedure</name>
<t>It can make sense to assign very large portions of the MAC <t>It can make sense to assign very large portions of the MAC
identifier code point space. (Note that existing assignments include identifier code point space. (Note that existing assignments include
one for half of the entire multicast IANA 48&nbhy;bit code point space one for half of the entire multicast IANA 48&nbhy;bit code point space
and one for a sixteenth of that multicast code point space.) In those and one for a sixteenth of that multicast code point space.) In those
cases, and in cases of the assignment of "reserved" values, IESG cases, and in cases of the assignment of "reserved" values, IESG
Ratification of an Expert Review approval recommendation is required Ratification of an Expert Review approval recommendation is required
as described below. This can be viewed as a combination of Expert as described below. This can be viewed as a combination of Expert
Review and IESG Approval as defined in <xref target="RFC8126"/>. IESG Review and IESG Approval as defined in <xref target="RFC8126"/>. IESG
Approval is required only when the Expert does not reject the Approval is required only when the Expert does not reject the
request. The procedure is as follows: </t> request. The procedure is as follows: </t>
<t indent="3">The applicant always completes the appropriate template <t indent="3">The applicant always completes the appropriate template
from Appendix A below and sends it to IANA &lt;iana@iana.org&gt;.</t> from <xref target="templates"/> below and sends it to IANA &lt;iana@iana.org&gt; .</t>
<t indent="3">IANA always sends the template to an appointed Expert. <t indent="3">IANA always sends the template to an appointed Expert.
If the Expert recuses themselves or is non-responsive, IANA may choose If the Expert recuses themselves or is non-responsive, IANA may choose
an alternative appointed Expert or, if none is available, will contact an alternative appointed Expert or, if none is available, will contact
the IESG.</t> the IESG.</t>
<t indent="3">In all cases, if IANA receives a disapproval from an <t indent="3">In all cases, if IANA receives a disapproval from an
Expert selected to review an application template, the application Expert selected to review an application template, the application
will be denied. The Expert should provide a reason for refusal which will be denied. The Expert should provide a reason for refusal, which
IANA will communicate back to the applicant.</t> IANA will communicate back to the applicant.</t>
<t indent="3">If the assignment is based on Expert Review:</t> <t indent="3">If the assignment is based on Expert Review:</t>
<t indent="9">If IANA receives approval and code points are available, <t indent="6">If IANA receives approval and code points are available,
IANA will make the requested assignment.</t> IANA will make the requested assignment.</t>
<t indent="3">If the assignment is based on IESG Ratification:</t> <t indent="3">If the assignment is based on IESG Ratification:</t>
<t indent="9">The procedure starts with the first steps above for <t indent="6">The procedure starts with the first steps above for
Expert Review. If the Expert disapproves the application, they simply Expert Review. If the Expert disapproves the application, they simply
inform IANA who in turn informs the applicant that their request is inform IANA, who in turn informs the applicant that their request is
denied; however, if the Expert believes the application should be denied; however, if the Expert believes the application should be
approved, or is uncertain and believes that the circumstances warrant approved or is uncertain and believes that the circumstances warrant
the attention of the IESG, the Expert will inform IANA about their the attention of the IESG, the Expert will inform IANA about their
advice, and IANA will forward the application, together with the advice, and IANA will forward the application, together with the
reasons provided by the Expert for approval or uncertainty, to the reasons provided by the Expert for approval or uncertainty, to the
IESG. The IESG must decide whether the assignment will be granted. IESG. The IESG must decide whether the assignment will be granted.
This can be accomplished by a management item in an IESG telechat as This can be accomplished by a management item in an IESG telechat, as
is done for other types of requests. If the IESG decides not to is done for other types of requests. If the IESG decides not to
ratify a favorable opinion by the Expert or decides against an ratify a favorable opinion by the Expert or decides against an
application where the Expert is uncertain, the application is denied; application where the Expert is uncertain, the application is denied;
otherwise, it is granted. The IESG will communicate its decision to otherwise, it is granted. The IESG will communicate its decision to
the Expert and to IANA. In case of refusal, the IESG should provide a the Expert and to IANA. In case of refusal, the IESG should provide a
reason which IANA will communicate to the applicant.</t> reason, which IANA will communicate to the applicant.</t>
</section> <!-- 5.1.2 --> </section> <!-- 5.1.2 -->
</section> <!-- 5.1 --> </section> <!-- 5.1 -->
<section> <!-- 5.2 --> <section anchor="iana-name-changes"> <!-- 5.2 -->
<name>IANA Registry Group (Web Page) Name Changes</name> <name>IANA Registry Group (Web Page) Name Changes</name>
<t>For clarity and parallelism with the IANA "IEEE 802 Numbers" <t>For clarity and parallelism with the IANA "IEEE 802 Numbers"
registry group, the IANA "Ethernet Numbers" registry group is re-named registry group, the IANA "Ethernet Numbers" registry group has been
the "IANA OUI Ethernet Numbers" web page. </t> renamed the "IANA OUI Ethernet Numbers" registry. </t>
<t>As this document replaces <xref target="RFC7042"/>, references to <t>As this document replaces <xref target="RFC7042"/>, references to
<xref target="RFC7042"/> in IANA registries in both the IANA IEEE 802 <xref target="RFC7042"/> in IANA registries in both the "IEEE 802
Numbers and the IANA IETF OUI Ethernet Numbers registry groups will Numbers" and the "IANA OUI Ethernet Numbers" registry groups have
be replaced by references to [this document]. Other IANA registry been replaced by references to this document. Other IANA registry
references to <xref target="RFC7042"/> are not changed. </t> references to <xref target="RFC7042"/> are not changed. </t>
</section> <!-- 5.2 --> </section> <!-- 5.2 -->
<section> <!-- 5.3 --> <section anchor="mac-addresses"> <!-- 5.3 -->
<name>MAC Address AFNs and RRTYPEs</name> <name>MAC Address AFNs and RRTYPEs</name>
<t>IANA has assigned Address Family Numbers (AFNs) for MAC addresses <t>IANA has assigned Address Family Numbers (AFNs) for MAC addresses
as follows:</t> as follows:</t>
<table> <table>
<thead> <thead>
<tr><th>AFN</th><th>Decimal</th><th>Hex</th><th>Reference</th></tr> <tr><th>AFN</th><th>Decimal</th><th>Hex</th><th>Reference</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td>48-bit MAC</td><td>16389</td><td>0x4005</td><td><xref <tr><td>48-bit MAC</td><td>16389</td><td>0x4005</td><td><xref
target="RFC7042"/></td></tr> target="RFC7042"/></td></tr>
<tr><td>64-bit MAC</td><td>16390</td><td>0x4006</td><td><xref <tr><td>64-bit MAC</td><td>16390</td><td>0x4006</td><td><xref
target="RFC7042"/></td></tr> target="RFC7042"/></td></tr>
<tr><td>24-bit OUI</td><td>16391</td><td>0x4007</td><td><xref <tr><td>OUI</td><td>16391</td><td>0x4007</td><td><xref
target="RFC7961"/></td></tr> target="RFC7961"/></td></tr>
<tr><td colspan="4"></td></tr> <tr><th colspan="4">Lower 24 bits of a 48-bit MAC address:</th></tr>
<tr><td colspan="4">Lower 24 bits of a 48-bit MAC address:</td></tr>
<tr><td>MAC/24</td><td>16392</td><td>0x4008</td><td><xref <tr><td>MAC/24</td><td>16392</td><td>0x4008</td><td><xref
target="RFC7961"/></td></tr> target="RFC7961"/></td></tr>
<tr><td colspan="4"></td></tr> <tr><th colspan="4">Lower 40 bits of a 64-bit MAC address:</th></tr>
<tr><td colspan="4">Lower 40 bits of a 64-bit MAC address:</td></tr>
<tr><td>MAC/40</td><td>16393</td><td>0x4009</td><td><xref <tr><td>MAC/40</td><td>16393</td><td>0x4009</td><td><xref
target="RFC7961"/></td></tr> target="RFC7961"/></td></tr>
</tbody> </tbody>
</table> </table>
<t>IANA has assigned DNS RRTYPEs <xref target="RFC6895"/> for MAC <t>IANA has assigned DNS RRTYPEs <xref target="RFC6895"/> for MAC
addresses as follows:</t> addresses as follows:</t>
<table> <table>
<thead> <thead>
skipping to change at line 1434 skipping to change at line 1412
target="RFC7043"/></td></tr> target="RFC7043"/></td></tr>
<tr><td>64-bit MAC</td><td align="center">EUI64</td><td <tr><td>64-bit MAC</td><td align="center">EUI64</td><td
align="center">109</td><td>0x006D</td><td><xref align="center">109</td><td>0x006D</td><td><xref
target="RFC7043"/></td></tr> target="RFC7043"/></td></tr>
</tbody> </tbody>
</table> </table>
</section> <!-- 5.3 --> </section> <!-- 5.3 -->
<section> <!-- 5.4 --> <section anchor="info-iana"> <!-- 5.4 -->
<name>Informational IANA Registry Group Material</name> <name>Informational IANA Registry Group Material</name>
<t>IANA maintains an informational registry group, currently <t>IANA maintains an informational registry group, currently
implemented as a webpage, concerning EtherTypes, OUIs, and multicast implemented as a web page, concerning EtherTypes, OUIs, and multicast
addresses assigned under OUIs other than the IANA OUI. The title of addresses assigned under OUIs other than the IANA OUI. The title of
this informational registry group is "IEEE 802 Numbers". IANA will this informational registry group is "IEEE 802 Numbers". IANA
update that informational registry group when changes are provided by updates that informational registry group when changes are provided by
or approved by the Expert(s).</t> or approved by the Expert(s).</t>
</section> <!-- 5.4 --> </section> <!-- 5.4 -->
<section> <!-- 5.5 --> <section anchor="ethertype-assign-pro"> <!-- 5.5 -->
<name>EtherType Assignment Process</name> <name>EtherType Assignment Process</name>
<t>Applying to the IEEE Registration Authority for an EtherType needed <t>Applying to the IEEE Registration Authority for an EtherType needed
by an IETF protocol requires IESG approval as stated in Appendix B. To by an IETF protocol requires IESG Approval, as stated in <xref target="ethertype s"/>. To
minimize confusion, this process will normally be done by the primary minimize confusion, this process will normally be done by the primary
expert for the informational IANA 802 Numbers EtherType registry as expert for the informational "EtherType" registry within the "IEEE 802 Numbers"
described below (see also Section 5.4).</t> registry group, as
described below (see also <xref target="info-iana"/>).</t>
<t>After IESG approval of the requirement for an EtherType, the IESG <t>After IESG Approval of the requirement for an EtherType, the IESG
should refer the matter to IANA. In any case, IANA will ask the IANA should refer the matter to IANA. In any case, IANA will ask the "EtherType" regi
IEEE 802 Numbers EtherType registry expert to execute the IEEE stry expert to execute the IEEE
Registration Authority <xref target="IEEE_RA"/> EtherType request Registration Authority <xref target="IEEE_RA"/> EtherType request
process. This path is specified because the IESG usually deals with process. This path is specified because the IESG usually deals with
IANA for assignment actions and because IANA should be aware of which IANA for assignment actions and because IANA should be aware of which
IANA IEEE 802 Numbers EtherType registry expert(s) are available, "EtherType" registry expert(s) are available,
normally refering the making of the Ethertype assignment request to normally referring the making of the EtherType assignment request to
the primary expert.</t> the primary expert.</t>
<t>Here is sample text for an Internet Draft where both IANA and IEEE <t>Here is sample text for an Internet-Draft where both IANA and IEEE
assignments are required, where "YYY" would be replaced by an assignments are required, where "YYY" would be replaced by an
explanation of for what/why the EtherType is needed in whatever level explanation of for what/why the EtherType is needed in whatever level
of detail is necessary and would normally include a reference or of detail is necessary and would normally include a reference or
references to other appropriate parts of the Internet Draft:</t> references to other appropriate parts of the Internet-Draft:</t>
<blockquote> <blockquote>
<t>X. Assignment Considerations</t> <t>X. Assignment Considerations</t>
<t>X.1. IEEE Assignment Considerations</t> <t>X.1. IEEE Assignment Considerations</t>
<t indent="3">The IESG is requested to approve applying to the IEEE <t indent="3">The IESG is requested to approve applying to the IEEE
Registration Authority for an EtherType for YYY. (The IESG should Registration Authority for an EtherType for YYY. (The IESG should
communicate its approval to IANA and to those concerned with this communicate its approval to IANA and to those concerned with this
document. IANA will forward the IESG approval to the IANA IEEE 802 document. IANA will forward the IESG Approval to the
Numbers EtherType registry expert who will make the application to registry expert of the "EtherType" registry from the "IEEE 802 Numbers" regist
the IEEE Registration authority, keeping IANA informed.)</t> ry group who will make the application to
the IEEE Registration Authority, keeping IANA informed.)</t>
<t>X.2. IANA Considerations</t> <t>X.2. IANA Considerations</t>
<t indent="3">...</t> <t indent="3">...</t>
</blockquote> </blockquote>
</section> <!-- 5.5 --> </section> <!-- 5.5 -->
<section> <!-- 5.6 --> <section anchor="oui-ex"> <!-- 5.6 -->
<name>OUI Exhaustion</name> <name>OUI Exhaustion</name>
<t>When the available space for either multicast or unicast <t>When the available space for either multicast or unicast
EUI&nbhy;48 identifiers under OUI 00&nbhy;00&nbhy;5E has been 90% or EUI&nbhy;48 identifiers under OUI 00&nbhy;00&nbhy;5E has been 90% or
more exhausted, IANA should request an additional OUI from the IEEE more exhausted, IANA should request an additional OUI from the IEEE
Registration Authority for further IANA assignment. The appointed Registration Authority for further IANA assignment. The appointed
Expert(s) should monitor for this condition and notify IANA.</t> Expert(s) should monitor for this condition and notify IANA.</t>
</section> <!-- 5.6 --> </section> <!-- 5.6 -->
<section> <!-- 5.7 --> <section> <!-- 5.7 -->
<name>IANA OUI MAC Address Table</name> <name>IANA OUI MAC Address Table</name>
<t>The following changes are made by this document to the Notes for <t>The following changes are made by this document to the Notes for
the "IANA Unicast 48-bit MAC Addresses", the "IANA Multicast 48-bit the "IANA Unicast 48-bit MAC Addresses", the "IANA Multicast 48-bit
MAC Addresses", and the "IANA 64-bit MAC Addresses" registries. In MAC Addresses", and the "IANA 64-bit MAC Addresses" registries. In
addition, the references in those registries are updated as specified addition, the references in those registries are updated, as specified
in Section 5.2.</t> in <xref target="iana-name-changes"/>.</t>
<t>The Notes for the IANA Unicast 48-bit MAC Addresses registry and <t>The Notes for the "IANA Unicast 48-bit MAC Addresses" registry and
for the IANA Multicast 48-bit MAC Addresses registry are changed to for the "IANA Multicast 48-bit MAC Addresses" registry are changed to
the following:</t> the following:</t>
<t indent="3">"These values are prefixed with 00-00-5E. See Section <blockquote>
2.1.5 of [this document]."</t> <t>These values are prefixed with 00-00-5E. See <xref target="bit-48-MAC"/> of R
FC 9542.</t>
</blockquote>
<t>The Note for the IANA 64-bit MAC Addresses registry is changed to <t>The Note for the "IANA 64-bit MAC Addresses" registry is changed to
the following:</t> the following:</t>
<t indent="3">"These values are prefixed with 00-00-5E to form unicast <blockquote>
<t>These values are prefixed with 00-00-5E to form unicast
MAC addresses, with 01-00-5E to form multicast MAC addresses, with MAC addresses, with 01-00-5E to form multicast MAC addresses, with
02-00-5E to form unicast modified EUI-64 addresses, and with 03-00-5E 02-00-5E to form unicast modified EUI-64 addresses, and with 03-00-5E
to form multicast modified EUI-64 addresses. See [this document], to form multicast modified EUI-64 addresses. See RFC 9542,
particularly Section 2.2.2, for more details."</t> particularly <xref target="eui-64-assign-con"/>, for more details.</t>
</blockquote>
</section> <!-- 5.7 --> </section> <!-- 5.7 -->
<section> <section anchor="lldp-tlv">
<name>IANA LLDP TLV Subtypes</name> <name>IANA LLDP TLV Subtypes</name>
<t>IANA is requested to move the "IANA Link Layer Discovery Protocol <t>IANA has moved the "IANA Link Layer Discovery Protocol
(LLDP) TLV Subtypes" Registry from the IANA IEEE 802 Numbers registry (LLDP) TLV Subtypes" registry from the "IEEE 802 Numbers" registry
group to the IANA OUI Ethernet Numbers registry group, since code group to the "IANA OUI Ethernet Numbers" registry group, since code
points within it are assigned by IANA, and to add [this document] as points within it are assigned by IANA, and has added RFC 9542 as
an additional reference for that registry.</t> an additional reference for that registry.</t>
<t>In addition, IANA is requested to update three entries in that <t>In addition, IANA has updated three entries in that
Registry as follows:</t> registry as follows:</t>
<table> <table>
<thead> <thead>
<tr><th>Value</th><th>Description</th><th>Reference</th></tr> <tr><th>Value</th><th>Description</th><th>Reference</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align="right">0</td><td>Reserved</td><td>[this <tr><td align="right">0</td><td>Reserved</td><td>RFC 9542</td></tr>
document]</td></tr>
<tr><td align="right">42</td><td>Example for use in <tr><td align="right">42</td><td>Example for use in
documentation</td><td>[this document]</td></tr> documentation</td><td>RFC 9542</td></tr>
<tr><td align="right">255</td><td>Reserved</td><td>[this <tr><td align="right">255</td><td>Reserved</td><td>RFC 9542</td></tr>
document]</td></tr>
</tbody> </tbody>
</table> </table>
<t>The entries for 1 (MUD), 2-41 (unassigned), and 43-254 (unassigned) <t>The entries for 1 (MUD), 2-41 (unassigned), and 43-254 (unassigned)
are unchanged.</t> are unchanged.</t>
</section> <!-- 5.8 --> </section> <!-- 5.8 -->
<section> <section anchor="cbor-tag-assign">
<name>CBOR Tag Assignments</name> <name>CBOR Tag Assignments</name>
<t>IANA is requested to assign two CBOR Tags as shown below in the <t>IANA has assigned two CBOR Tags as shown below in the
Concise Binary Object Representation (CBOR) Tags registry. [The "Concise Binary Object Representation (CBOR) Tags" registry.</t>
values of 48 and 49 are requested for TBD1 and TBD2 respectively.]</t>
<table> <table>
<thead> <thead>
<tr><th>Tag</th><th>Data <tr><th>Tag</th><th>Data
Item</th><th>Semantics</th><th>Reference</th></tr> Item</th><th>Semantics</th><th>Reference</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td>TBD1</td><td>byte string</td><td>IEEE MAC <tr><td>48</td><td>byte string</td><td>IEEE MAC
Address</td><td>[this document]</td></tr> Address</td><td>RFC 9542</td></tr>
<tr><td>TBD2</td><td>byte string</td><td>IEEE OUI/CID</td><td>[this <tr><td>1048</td><td>byte string</td><td>IEEE OUI/CID</td><td>RFC 9542</td></tr>
document]</td></tr>
</tbody> </tbody>
</table> </table>
</section> <!-- 5.9 --> </section> <!-- 5.9 -->
</section> <!-- 5. IANA Considerations --> </section> <!-- 5. IANA Considerations -->
<section> <!-- 6. --> <section> <!-- 6. -->
<name>Security Considerations</name> <name>Security Considerations</name>
skipping to change at line 1599 skipping to change at line 1575
<t indent="3">Confusion and conflict can be caused by the use of MAC <t indent="3">Confusion and conflict can be caused by the use of MAC
addresses or other OUI-derived protocol parameters as examples in addresses or other OUI-derived protocol parameters as examples in
documentation. Examples that are "only" to be used in documentation documentation. Examples that are "only" to be used in documentation
can end up being coded and released or cause conflicts due to later can end up being coded and released or cause conflicts due to later
real use and the possible acquisition of intellectual property rights real use and the possible acquisition of intellectual property rights
in such addresses or parameters. The reservation herein of MAC in such addresses or parameters. The reservation herein of MAC
addresses and parameters for documentation purposes will minimize such addresses and parameters for documentation purposes will minimize such
confusion and conflict.</t> confusion and conflict.</t>
<t>MAC addresses are an identifier provided by a device to the <t>MAC addresses are identifiers provided by a device to the
network. On certain devices, MAC addresses are not static, and can be network. On certain devices, MAC addresses are not static and can be
configured. The network should exercise caution when using these configured. The network should exercise caution when using these
addresses to enforce policy because addresses can be spoofed and addresses to enforce policy because addresses can be spoofed and
previously seen devices can return to the network with a new previously seen devices can return to the network with a new
address.</t> address.</t>
<t>MAC addresses identify a physical or virtual interface and can be <t>MAC addresses identify a physical or virtual interface and can be
used for tracking the device with that interface. Thus, they can be used for tracking the device with that interface. Thus, they can be
used to track users asociated with that device. See <xref used to track users associated with that device. See <xref
target="madinas"/> for related privacy considerations and a discussion target="I-D.ietf-madinas-mac-address-randomization"/> for related privacy consid
erations and a discussion
of MAC address randomization to partially mitigate this threat. Also, of MAC address randomization to partially mitigate this threat. Also,
see <xref target="RFC7043"/> for the security and privacy see <xref target="RFC7043"/> for the security and privacy
considerations of publishing MAC addresses in DNS.</t> considerations of publishing MAC addresses in DNS.</t>
</section> <!-- end 6. Security Considerations --> </section> <!-- end 6. Security Considerations -->
</middle> </middle>
<!-- ____________________BACK_MATTER____________________ -->
<back> <back>
<displayreference target="I-D.acee-idr-lldp-peer-discovery" to="BGP11dp"/>
<displayreference target="I-D.ietf-madinas-mac-address-randomization" to="madina
s"/>
<displayreference target="I-D.ieee-rac-oui-restructuring" to="RAC_OUI"/>
<references> <references>
<name>References</name>
<references>
<name>Normative References</name> <name>Normative References</name>
<referencegroup anchor="IEEE802_OandA"> <referencegroup anchor="IEEE802_OandA">
<reference anchor="x"> <reference anchor="x">
<front> <front>
<title>IEEE Standard for Local and Metropolitan Area Networks: <title>IEEE Standard for Local and Metropolitan Area Networks:
Overview and Architecture</title> Overview and Architecture</title>
<author> <author>
<organization>IEEE 802</organization> <organization>IEEE</organization>
</author> </author>
<date year="2014" month="June" day="12"/> <date year="2014" month="June"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802-2014"/> <seriesInfo name="IEEE Std" value="802-2014"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6847097"/>
</reference> </reference>
<reference anchor="y"> <reference anchor="y">
<front> <front>
<title>IEEE Standard for Local and Metropolitan Area Networks: <title>IEEE Standard for Local and Metropolitan Area Networks:
Overview and Architecture - Amendment 2: Local Medium Access Overview and Architecture -- Amendment 2: Local Medium Access
Control (MAC) Address Usage</title> Control (MAC) Address Usage</title>
<author> <author>
<organization>IEEE 802</organization> <organization>IEEE</organization>
</author> </author>
<date year="2017" month="April"/> <date year="2017" month="August"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802c-2017"/> <seriesInfo name="IEEE Std" value="802c-2017"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8016709"/>
</reference> </reference>
</referencegroup> </referencegroup>
<reference anchor="IEEE802.1AB"> <reference anchor="IEEE802.1AB">
<front> <front>
<title>IEEE Standard for Local and metropolitan area networks - <title>IEEE Standard for Local and metropolitan area networks -
Statin and Media Access Control Connectivity Discovery</title> Station and Media Access Control Connectivity Discovery</title>
<author> <author>
<organization>IEEE 802</organization> <organization>IEEE</organization>
</author> </author>
<date year="2016" month="January" day="29"/> <date year="2016" month="March"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.1AB-2016"/> <seriesInfo name="IEEE Std" value="802.1AB-2016"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7433915"/>
</reference> </reference>
<xi:include <xi:include
href="https://www.rfc-editor.org/refs/bibxml6/reference.IEEE.802.1Q_2014.xml "/> href="https://www.rfc-editor.org/refs/bibxml6/reference.IEEE.802.1Q_2014.xml "/>
<xi:include <xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8126.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="BGP11dp" <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.acee-id
target="https://datatracker.ietf.org/doc/draft-acee-idr-lldp-peer-dis r-lldp-peer-discovery.xml"/>
covery/">
<front>
<title>BGP Logical Link Discovery Protocol (LLDP) Peer
Discovery</title>
<author initials="A." surname="Lindem"/>
<author initials="K." surname="Patel"/>
<author initials="S." surname="Zandi"/>
<author initials="J." surname="Haas"/>
<author initials="X." surname="Xu"/>
<date year="2022" month="December" day="6"/>
</front>
<seriesInfo name="work"
value="in Progress"/>
</reference>
<reference anchor="EthernetNum" <reference anchor="EthernetNum" target="https://www.iana.org/assignments/etherne
target="https://www.iana.org/assignments/ethernet-numbers"> t-numbers">
<front> <front>
<title>Ethernet Numbers</title> <title>IANA OUI Ethernet Numbers</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor="IANA" <reference anchor="IANA" target="https://www.iana.org">
target="https://www.iana.org">
<front> <front>
<title>Internet Assigned Numbers Authority</title> <title>Internet Assigned Numbers Authority</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor="IEEE" <reference anchor="IEEE" target="https://www.ieee.org">
target="https://www.ieee.org">
<front> <front>
<title>Institute for Electrical and Electronics Engineers</title> <title>Institute of Electrical and Electronics Engineers</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor="IEEE1394"> <reference anchor="IEEE1394">
<front> <front>
<title>IEEE Standard for a High-Performance Serial Bus</title> <title>IEEE Standard for a High-Performance Serial Bus</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date year="2008" month="10" day="21"/> <date year="2008" month="October"/>
</front> </front>
<seriesInfo name="IEEE Std" value="1394-2008"/> <seriesInfo name="IEEE Std" value="1394-2008"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4659233"/>
</reference> </reference>
<reference anchor="IEEE802" <reference anchor="IEEE802" target="https://www.ieee802.org">
target="https://www.ieee802.org">
<front> <front>
<title>IEEE 802 LAN/MAN Standards Committee</title> <title>IEEE 802 LMSC</title>
<author> <author>
<organization>IEEE 802</organization> <organization>IEEE 802</organization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor="IEEE802.15.4"> <reference anchor="IEEE802.15.4">
<front> <front>
<title>IEEE Standard for Low-Rate Wireless Networks</title> <title>IEEE Standard for Low-Rate Wireless Networks</title>
<author> <author>
<organization>IEEE 802</organization> <organization>IEEE</organization>
</author> </author>
<date year="2020"/> <date year="2020" month="July"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.14.4"/> <seriesInfo name="IEEE Std" value="802.15.4-2020"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9144691"/>
</reference> </reference>
<reference anchor="IEEE802.1AC"> <reference anchor="IEEE802.1AC">
<front> <front>
<title>IEEE Standard for Local and Metropolitan Area Networks - <title>IEEE Standard for Local and metropolitan area networks --
Media Access Control (MAC) Service Definition</title> Media Access Control (MAC) Service Definition</title>
<author> <author>
<organization>IEEE 802</organization> <organization>IEEE 802</organization>
</author> </author>
<date year="2016" month="December" day="7"/> <date year="2017" month="March"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.1AC-2016"/> <seriesInfo name="IEEE Std" value="802.1AC-2016"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2017.7875381"/>
</reference> </reference>
<reference anchor="IEEE802.1CQ"> <reference anchor="IEEE802.1CQ">
<front> <front>
<title>IEEE Standard for Local and Metropolitan Area Networks - <title>Draft Standard for Local and Metropolitan Area Networks: Multicast an
Multicast and Local Address Assignment</title> d Local Address Assignment</title>
<author> <author>
<organization>IEEE 802</organization> <organization>IEEE</organization>
</author> </author>
<date year="2022" month="July" day="31"/> <date year="2022" month="July"/>
</front> </front>
<seriesInfo name="draft" value="0.8"/> <refcontent>draft 0.8</refcontent>
<seriesInfo name="IEEE Std" value="802.1CQ/D0.8"/> <seriesInfo name="IEEE Std" value="802.1CQ/D0.8"/>
</reference> </reference>
<xi:include <xi:include href="https://www.rfc-editor.org/refs/bibxml6/reference.IEEE.802.11_
href="https://www.rfc-editor.org/refs/bibxml6/reference.IEEE.802.11_2012.xml 2012.xml"/>
"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml6/reference.IEEE.802.3_2012.xml"
/>
<reference anchor="IEEE_RA" <reference anchor="IEEE.802.3_2012" target="http://ieeexplore.ieee.org/servlet/o
target="https://standards.ieee.org/products-programs/regauth/"> pac?punumber=6419733">
<front>
<title>IEEE Standard for Ethernet</title>
<author>
<organization>IEEE</organization>
</author>
<date day="24" month="January" year="2013"/>
</front>
<seriesInfo name="IEEE" value="802.3-2012"/>
<seriesInfo name="DOI" value="10.1109/ieeestd.2012.6419735"/>
</reference>
<reference anchor="IEEE_RA" target="https://standards.ieee.org/products-programs
/regauth/">
<front> <front>
<title>IEEE Standards Association Registration Authority</title> <title>Registration Authority</title>
<author> <author>
<organization>IEEE RA</organization> <organization>IEEE</organization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor="IEEE_SA" <reference anchor="IEEE_SA" target="https://standards.ieee.org">
target="https://standards.ieee.org">
<front> <front>
<title>IEEE Standards Association</title> <title>IEEE Standards Association</title>
<author> <author>
<organization>IEEE SA</organization> <organization>IEEE</organization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor="IEEEtutorials" <reference anchor="IEEEtutorials" target="https://standards.ieee.org/wp-content/
target="https://standards.ieee.org/wp-content/uploads/import/documents uploads/import/documents/tutorials/eui.pdf">
/tutorials/eui.pdf">
<front> <front>
<title>Guidelines for Use of Extended Unique Identifier (EUI), <title>Guidelines for Use of Extended Unique Identifier (EUI),
Organizationally Unique Identifier (OUI), and Company ID Organizationally Unique Identifier (OUI), and Company ID
(CID)</title> (CID)</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date year="2017" month="August" day="3"/> <date year="2017" month="August"/>
</front> </front>
</reference> </reference>
<reference anchor="InfiniBand" target="https://www.infinibandta.org/"> <reference anchor="InfiniBand" target="https://www.infinibandta.org/">
<front> <front>
<title>InfiniBand Architecture Specification Volume 1</title> <title>InfiniBand Architecture Specification Volume 1</title>
<author> <author>
<organization>InfiniBand Trade Association</organization> <organization>InfiniBand Trade Association</organization>
</author> </author>
<date year="2007" month="November"/> <date year="2007" month="November"/>
</front> </front>
</reference> </reference>
<reference anchor="madinas" <reference anchor="I-D.ietf-madinas-mac-address-randomization" target="https://d
target="https://datatracker.ietf.org/doc/draft-ietf-madinas-mac-addres atatracker.ietf.org/doc/html/draft-ietf-madinas-mac-address-randomization-12">
s-randomization/"> <front>
<front> <title>Randomized and Changing MAC Address state of affairs</title>
<title>Randomized and Changing MAC Address</title> <author initials="JC." surname="Zúñiga" fullname="Juan-Carlos Zúñiga">
<author initials="JC." surname="Zuniga"/> <organization>CISCO</organization>
<author initials="CJ." surname="Bernardos"/> </author>
<author initials="A" surname="Andersdotter"/> <author initials="CJ." surname="Bernardos" fullname="Carlos J. Bernardos"
<date year="2023" month="September" day="13"/> role="editor">
</front> <organization>Universidad Carlos III de Madrid</organization>
<seriesInfo name="work" value="in Progress"/> </author>
<author initials="A." surname="Andersdotter" fullname="Amelia Andersdotter
">
<organization>Safespring AB</organization>
</author>
<date month="February" day="28" year="2024" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-madinas-mac-address-rando
mization-12" />
</reference> </reference>
<reference anchor="PPPNum" <reference anchor="PPPNum" target="https://www.iana.org/assignments/ppp-numbers"
target="https://www.iana.org/assignments/ppp-numbers"> >
<front> <front>
<title>PPP Numbers</title> <title>Point-to-Point (PPP) Protocol Field Assignments</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor="RAC_OUI" <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ieee-ra
target="https://www.ietf.org/archive/id/draft-ieee-rac-oui-restructuri c-oui-restructuring.xml"/>
ng-01.txt">
<front>
<title>OUI Registry Restructuring</title>
<author fullname="Glenn Parsons"
initials="G."
surname="Parsons"/>
<date year="2013" month="September"/>
</front>
<seriesInfo name="work in" value="Progress"/>
</reference>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.1112.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.1661.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2153.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2332.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2464.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2606.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2784.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3092.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4291.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4760.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5214.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5332.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5342.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5737.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5798.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6034.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6328.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6895.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7042.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7043.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7319.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7961.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8064.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8415.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8520.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8926.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8947.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8948.xml"/>
<xi:include
href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8949.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1112.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1661.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2153.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2332.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2464.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2606.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3092.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5214.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5332.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5342.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5737.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5798.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6034.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6328.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7042.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7043.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7319.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7961.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8064.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8520.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8926.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8947.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8948.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"
/>
</references>
</references> </references>
<section> <section anchor="templates">
<name>Templates</name> <name>Templates</name>
<t>This appendix provides the specific templates for IANA assignments <t>This appendix provides the specific templates for IANA assignments
of parameters. Explanatory words in parentheses in the templates of parameters. Explanatory words in parentheses in the templates
below may be deleted in a completed template as submitted to IANA.</t> below may be deleted in a completed template as submitted to IANA.</t>
<section> <section>
<name>EUI&nbhy;48/EUI&nbhy;64 Identifier or Identifier Block <name>EUI&nbhy;48/EUI&nbhy;64 Identifier or Identifier Block
Template</name> Template</name>
<t>Applicant Name:</t> <t>Applicant Name:</t>
<t>Applicant Email: </t> <t>Applicant Email: </t>
<t>Applicant Telephone: (starting with country code) </t> <t>Applicant Telephone: (starting with the country code) </t>
<t>Use Name: (brief name of Parameter use such as "Foo Protocol" <t>Use Name: (brief name of Parameter use, such as "Foo Protocol"
<xref target="RFC3092"/>)</t> <xref target="RFC3092"/>)</t>
<t>Document: (ID or RFC specifying use to which the identifier or block <t>Document: (I-D or RFC specifying use to which the identifier or block
of identifiers will be put.)</t> of identifiers will be put)</t>
<t>Specify whether this is an application for EUI&nbhy;48 or EUI&nbhy;64 <t>Specify whether this is an application for EUI&nbhy;48 or EUI&nbhy;64
identifiers:</t> identifiers:</t>
<t>Size of Block requested: (must be a power-of-two-sized block, can be <t>Size of Block requested: (must be a power-of-two-sized block, can be
a block of size one (2**0))</t> a block of size one (2**0))</t>
<t>Specify multicast, unicast, or both:</t> <t>Specify multicast, unicast, or both:</t>
</section> </section>
<section> <section>
<name>IANA OUI/CID-Based Protocol Number Template</name> <name>IANA OUI/CID-Based Protocol Number Template</name>
<t>Applicant Name: </t> <t>Applicant Name: </t>
<t>Applicant Email: </t> <t>Applicant Email: </t>
<t>Applicant Telephone: (starting with country code) </t> <t>Applicant Telephone: (starting with the country code) </t>
<t>Use Name: (brief name of use of code point such as "Foo Protocol") </t> <t>Use Name: (brief name of use of code point, such as "Foo Protocol") </t>
<t>Document: (ID or RFC specifying use to which the protocol identifier <t>Document: (I-D or RFC specifying use to which the protocol identifier
will be put.) </t> will be put) </t>
<t>Note: (any additional note) </t> <t>Note: (any additional note) </t>
</section> </section>
<section> <section>
<name>Other IANA OUI/CID-Based Parameter Template</name> <name>Other IANA OUI/CID-Based Parameter Template</name>
<t>Applicant Name: </t> <t>Applicant Name: </t>
<t>Applicant Email: </t> <t>Applicant Email: </t>
<t>Applicant Telephone: (starting with country code) </t> <t>Applicant Telephone: (starting with the country code) </t>
<t>Protocol where the OUI/CID-Based Parameter for which a value is being <t>Protocol where the OUI/CID-Based Parameter for which a value is being
requested appears: (such as: Cipher Suite selection in IEEE 802.11) </t> requested appears: (such as Cipher Suite selection in IEEE 802.11) </t>
<t>Use Name: (brief name of use of code point to be assigned, such as <t>Use Name: (brief name of use of code point to be assigned, such as
"Foo Cipher Suite" [RFC3092]) </t> "Foo Cipher Suite" <xref target="RFC3092"/>) </t>
<t>Document: (ID or RFC specifying use to which the other IANA OUI-based <t>Document: (I-D or RFC specifying use to which the other IANA OUI-based
parameter value will be put.) </t> parameter value will be put) </t>
<t>Note: (any additional note) </t> <t>Note: (any additional note) </t>
</section> </section>
</section> <!-- Appendix A --> </section> <!-- Appendix A -->
<section> <section anchor="ethertypes">
<name>EtherTypes</name> <name>EtherTypes</name>
<t>This appendix provides a copy of the IESG Statement issued in May <t>This appendix provides a copy of the IESG Statement issued in May
2023 on obtaining new IETF EtherTypes in Section B.1. Note that there 2023 on obtaining new IETF EtherTypes in <xref target="iesg-ethertypes"/>. Note that there
is an informational IANA registry of some important EtherTypes is an informational IANA registry of some important EtherTypes
specified for IETF protocols or by IEEE 802 available, currently at specified for IETF protocols or by IEEE 802 available, currently at
<xref target="IANA"/>. The IEEE Registration Authority page of <xref target="IANA"/>. The IEEE Registration Authority page on
EtherTypes, https://standards.ieee.org/regauth/ethertype/eth.txt, may EtherTypes <eref target="https://standards.ieee.org/regauth/ethertype/eth.txt" b
also be useful. See Section 3 above. </t> rackets="angle"/> may
also be useful. See <xref target="eth-pro-param"/> above. </t>
<section> <section anchor="iesg-ethertypes">
<name>IESG Statement on Ethertypes</name> <name>IESG Statement on EtherTypes</name>
<t>From: IESG <dl newline="false" spacing="compact">
Date: 1 May 2023</t> <dt>From:</dt>
<dd>IESG</dd>
<dt>Date:</dt>
<dd>1 May 2023</dd>
</dl>
<t>The IEEE Registration Authority (IEEE RA) assigns EtherTypes with <t>The IEEE Registration Authority (IEEE RA) assigns EtherTypes with
oversight from the IEEE Registration Authority Committee (IEEE oversight from the IEEE Registration Authority Committee (IEEE RAC).</t>
RAC)</t>
<t>(See <t>(See
https://standards.ieee.org/products-programs/regauth/ethertype/.) Some <eref target="https://standards.ieee.org/products-programs/regauth/ethertype/"/> .) Some
IETF protocol specifications make use of EtherTypes. All EtherType IETF protocol specifications make use of EtherTypes. All EtherType
applications are subject to IEEE RA technical review for consistency applications are subject to IEEE RA technical review for consistency
with policy.</t> with policy.</t>
<t>Since EtherTypes are a fairly scarce resource, the IEEE RAC has let <t>Since EtherTypes are a fairly scarce resource, the IEEE RAC has let
us know that they will not assign a new EtherType to a new IETF us know that they will not assign a new EtherType to a new IETF
protocol specification until the IESG has approved the protocol protocol specification until the IESG has approved the protocol
specification for publication as an RFC. In exceptional cases, the specification for publication as an RFC. In exceptional cases, the
IEEE RA is willing to consider "early allocation" of an EtherType for IEEE RA is willing to consider "early allocation" of an EtherType for
an IETF protocol that is still under development as long as the an IETF protocol that is still under development as long as the
request comes from and has been vetted by the IESG.</t> request comes from and has been vetted by the IESG.</t>
<t>To let the IEEE RAC know that the IESG has approved the request for <t>To let the IEEE RAC know that the IESG has approved the request for
an Ethernet assignment for an IETF protocol, all future requests for an Ethernet assignment for an IETF protocol, all future requests for
assignment of EtherTypes for IETF protocols will be made by the assignment of EtherTypes for IETF protocols will be made by the
IESG.</t> IESG.</t>
<t>Note that Local Experimental ("playpen") EtherTypes have been <t>Note that Local Experimental ("playpen") EtherTypes have been
assigned in IEEE 802 [1] for use during protocol development and assigned in IEEE 802 [1] use during protocol development and
experimentation.</t> experimentation.</t>
<t indent="4"> <t>[1] IEEE Std 802. IEEE standard for Local and Metropolitan Area Networks: Ov
[1] IEEE Std 802. IEEE standard for Local and Metropolitan Area erview and Architecture.</t>
Networks: Overview and Architecture.</t>
</section> </section>
</section> <!-- Appendix B --> </section> <!-- Appendix B -->
<section> <!-- Appendix C --> <section> <!-- Appendix C -->
<name>Changes from RFC 7042</name> <name>Changes from RFC 7042</name>
<t>This document obsoletes <xref target="RFC7042"/> and makes the <t>This document obsoletes <xref target="RFC7042"/> and makes the
changes listed below. However, the completed application template changes listed below. However, the completed application template
based upon which an IANA OUI-based protocol number value was assigned based upon which an IANA OUI-based protocol number value was assigned
for document use remains that in Appendix C of RFC 7042.</t> for document use remains that in <xref target="RFC7042" sectionFormat="of" secti on="C"/>.</t>
<ul> <ul>
<li>Add information on MA-M (28-bit) and MA-S (36-bit) EUI prefixes <li>Add information on MA-M (28-bit) and MA-S (36-bit) EUI prefixes
that the IEEE Registration Authority assigns.</li> that the IEEE Registration Authority assigns.</li>
<li>Add information on the restructuring of the "local" MAC address <li>Add information on the restructuring of the "local" MAC address
space into four quadrants under the Structured Local Address Plan space into four quadrants under the Structured Local Address Plan
(SLAP <xref target="IEEE802_OandA"/>).</li> (SLAP) <xref target="IEEE802_OandA"/>.</li>
<li>Include the IESG Statement on EtherTypes (See Appendix B.1) and <li>Include the IESG Statement on EtherTypes (see <xref target="iesg-ethertypes" />) and
more detailed IETF procedures for applying to the IEEE Registration more detailed IETF procedures for applying to the IEEE Registration
Authority for an EtherType for use in an IETF protocol (see Section Authority for an EtherType for use in an IETF protocol (see <xref target="ethert
5.5). </li> ype-assign-pro"/>). </li>
<li>Mention that IEEE 802 CFM Codepoints that have been allocated to <li>Mention that IEEE 802 CFM code points have been allocated to
the IETF (see <xref target="CFM"/>).</li> the IETF (see <xref target="CFM"/>).</li>
<li>Mention the organizationally specific LLDP data element that has <li>Mention the Organizationally Specific LLDP data element that has
been assigned under the IANA OUI and the registry set up for future been assigned under the IANA OUI and the registry set up for future
such assignments (see Section 4.1).</li> such assignments (see <xref target="lldp-ietf-tlv"/>).</li>
<li>Clarify minor details in Section 5.1 on Expert Review and IESG <li>Clarify minor details in <xref target="ex-rev-iesg-rat"/> on Expert Review a nd IESG
Ratification.</li> Ratification.</li>
<li>Specify CBOR tags for MAC addresses and OUI/CIDs (see <li>Specify CBOR tags for MAC addresses and OUIs/CIDs (see
Section 2.4).</li> <xref target="cbor-tags"/>).</li>
<li>Add a version field requirement for the allocation of protocol <li>Add a version field requirement for the allocation of protocol
numbers under the IANA OUI (see Section 3.1).</li> numbers under the IANA OUI (see <xref target="eth-pro-iana-oui"/>).</li>
<li>Mention that EtherTypes are used in the GENEVE <xref <li>Mention that EtherTypes are used in the Geneve <xref
target="RFC8926"/> encapsulation header (see Section 3).</li> target="RFC8926"/> encapsulation header (see <xref target="eth-pro-param"/>).</l
i>
<li>Add "a combination of Expert Review and IESG Approal" as part of <li>Add "a combination of Expert Review and IESG Approval" as part of
the specification for "IESG Ratification".</li> the specification for "IESG Ratification".</li>
</ul> </ul>
</section> </section>
<section anchor="Acknowledgements" numbered="false"> <section anchor="Acknowledgements" numbered="false">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The comments and suggestions of the following people persons and <t>The comments and suggestions of the following persons and
organizations are gratefully acknowledged:</t> organizations are gratefully acknowledged:</t>
<t indent="3">Comments and suggestions leading to this <t indent="3">Comments and suggestions leading to this
Document:</t> document:</t>
<t indent="6">Carsten Bormann, Bob Hinden, The IEEE 802.1 <t indent="6"><contact fullname="Carsten Bormann"/>, <contact fullname="Bo
Working Group, &#201;ric Vyncke, Dale Worley, and Amanda b Hinden"/>, the IEEE 802.1
Baber</t> Working Group, <contact fullname="Éric Vyncke"/>, <contact fullname="Dale
Worley"/>, and <contact fullname="Amanda Baber"/></t>
<t indent="3">Comments and suggestions leading to RFC 7042 (which <t indent="3">Comments and suggestions leading to <xref target="RFC7042"/> ( which
is obsoleted by this document):</t> is obsoleted by this document):</t>
<t indent="6">David Black, Adrian Farrel, Bob Grow, Joel <t indent="6"><contact fullname="David Black"/>, <contact fullname="Adrian
Jaeggli, Pearl Liang, Glenn Parsons, Pete Resnick, and Dan Farrel"/>, <contact fullname="Bob Grow"/>, <contact fullname="Joel
Romascanu.</t> Jaeggli"/>, <contact fullname="Pearl Liang"/>, <contact fullname="Glenn Pa
rsons"/>, <contact fullname="Pete Resnick"/>, and <contact fullname="Dan Romasca
nu"/></t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 290 change blocks. 
579 lines changed or deleted 591 lines changed or added

This html diff was produced by rfcdiff 1.48.