diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc9542.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc9542.txt')
| -rw-r--r-- | doc/rfc/rfc9542.txt | 1753 |
1 files changed, 1753 insertions, 0 deletions
diff --git a/doc/rfc/rfc9542.txt b/doc/rfc/rfc9542.txt new file mode 100644 index 0000000..b9b9204 --- /dev/null +++ b/doc/rfc/rfc9542.txt @@ -0,0 +1,1753 @@ + + + + +Internet Engineering Task Force (IETF) D. Eastlake 3rd +Request for Comments: 9542 Independent +BCP: 141 J. Abley +Obsoletes: 7042 Cloudflare +Category: Best Current Practice Y. Li +ISSN: 2070-1721 Huawei Technologies + April 2024 + + + IANA Considerations and IETF Protocol and Documentation Usage for IEEE + 802 Parameters + +Abstract + + Some IETF protocols make use of Ethernet frame formats and IEEE 802 + parameters. This document discusses several aspects of such + parameters and their use in IETF protocols, specifies IANA + considerations for assignment of points under the IANA + Organizationally Unique Identifier (OUI), and provides some values + for use in documentation. This document obsoletes RFC 7042. + +Status of This Memo + + This memo documents an Internet Best Current Practice. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + BCPs is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9542. + +Copyright Notice + + Copyright (c) 2024 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 1.1. Notations Used in This Document + 1.2. The IEEE Registration Authority + 1.3. The IANA Organizationally Unique Identifier + 1.4. CFM Code Points + 2. Ethernet Identifier Parameters + 2.1. 48-Bit MAC Identifiers, OUIs, and Other Prefixes + 2.1.1. Special First Octet Bits + 2.1.2. OUIs and CIDs + 2.1.3. 48-Bit MAC Assignments under the IANA OUI + 2.1.4. 48-Bit MAC Documentation Values + 2.1.5. 48-Bit IANA MAC Assignment Considerations + 2.2. 64-Bit MAC Identifiers + 2.2.1. IPv6 Use of Modified EUI-64 Identifiers + 2.2.2. EUI-64 IANA Assignment Considerations + 2.2.3. EUI-64 Documentation Values + 2.3. Other 48-Bit MAC Identifiers Used by the IETF + 2.3.1. Identifiers with a '33-33' Prefix + 2.3.2. The CF Series + 2.4. CBOR Tags + 3. Ethernet Protocol Parameters + 3.1. Ethernet Protocol Assignment under the IANA OUI + 3.2. Documentation Protocol Number + 4. Other OUI/CID-Based Parameters + 4.1. LLDP IETF Organizationally Specific TLV Type + 5. IANA Considerations + 5.1. Expert Review and IESG Ratification + 5.1.1. Expert Review Guidance + 5.1.2. Expert Review and IESG Ratification Procedure + 5.2. IANA Registry Group (Web Page) Name Changes + 5.3. MAC Address AFNs and RRTYPEs + 5.4. Informational IANA Registry Group Material + 5.5. EtherType Assignment Process + 5.6. OUI Exhaustion + 5.7. IANA OUI MAC Address Table + 5.8. IANA LLDP TLV Subtypes + 5.9. CBOR Tag Assignments + 6. Security Considerations + 7. References + 7.1. Normative References + 7.2. Informative References + Appendix A. Templates + A.1. EUI-48/EUI-64 Identifier or Identifier Block Template + A.2. IANA OUI/CID-Based Protocol Number Template + A.3. Other IANA OUI/CID-Based Parameter Template + Appendix B. EtherTypes + B.1. IESG Statement on EtherTypes + Appendix C. Changes from RFC 7042 + Acknowledgements + Authors' Addresses + +1. Introduction + + Some IETF protocols use Ethernet or other communication frame formats + and parameters related to IEEE 802 [IEEE802]. These include Media + Access Control (MAC) addresses and protocol identifiers. The IEEE + Registration Authority [IEEE_RA] manages the assignment of + identifiers used in IEEE 802 networks, in some cases assigning blocks + of such identifiers whose sub-assignment is managed by the entity to + which the block is assigned. The IEEE RA also provides a number of + tutorials concerning these parameters [IEEEtutorials]. + + IANA has been assigned an Organizationally Unique Identifier (OUI) by + the IEEE RA and an associated set of MAC addresses and other + organizationally unique code points based on that OUI. This document + specifies IANA considerations for the assignment of code points under + that IANA OUI, including MAC addresses and protocol identifiers, and + provides some values for use in documentation. As noted in [RFC2606] + and [RFC5737], the use of designated code values reserved for + documentation and examples reduces the likelihood of conflicts and + confusion arising from such code points conflicting with code points + assigned for some deployed use. This document also discusses several + other uses by the IETF of IEEE 802 code points, including IEEE 802 + Connectivity Fault Management (CFM) code points [RFC7319] and IEEE + 802 Link Local Discovery Protocol (LLDP) [IEEE802.1AB] Vendor- + Specific TLV Sub-Types [RFC8520]. It also specifies Concise Binary + Object Representation (CBOR) tags for MAC addresses and OUIs / + Company Identifiers (CIDs). + + Descriptions herein of [IANA] policies and procedures are + authoritative, but descriptions of IEEE registration policies, + procedures, and standards are only informative; for authoritative + IEEE information, consult the IEEE sources. + + [RFC8126] is incorporated herein except where there are contrary + provisions in this document. In this document, "IESG Ratification", + specified in Section 5.1, refers to a combination of Expert Review + and IESG Approval as those are defined in [RFC8126], where IESG + Approval is required only if the Expert does not reject the request. + It is NOT the same as just "IESG Approval" in [RFC8126]. + +1.1. Notations Used in This Document + + This document uses hexadecimal notation. Each octet (that is, 8-bit + byte) is represented by two hexadecimal digits giving the value of + the octet as an unsigned integer. Successive octets are separated by + a hyphen. This document consistently uses IETF ("network") bit + ordering although the physical order of bit transmission within an + octet on an IEEE [IEEE.802.3_2012] link is from the lowest order bit + to the highest order bit (i.e., the reverse of the IETF's ordering). + + In this document: + + "AFN" Address Family Number [RFC4760]. + + "CBOR" Concise Binary Object Representation [RFC8949]. + + "CFM" Connectivity Fault Management [RFC7319]. + + "CID" Company Identifier. See Section 2.1.2. + + "DSAP" Destination Service Access Point. See Section 3. + + "EUI" Extended Unique Identifier. + + "EUI-48" 48-bit EUI + + "IEEE" Institute of Electrical and Electronics Engineers [IEEE]. + + "IEEE 802" The LAN/MAN Standards Committee [IEEE802]. + + "IEEE RA" IEEE Registration Authority [IEEE_RA]. + + "IEEE SA" IEEE Standards Association [IEEE_SA]. + + "LLC" Logical Link Control. The type of frame header where the + protocol is identified by source and destination LSAP + fields. See Section 3. + + "LSAP" Link-Layer Service Access Point. See Section 3. + + "MA-L" MAC Address Block Large. + + "MA-M" MAC Address Block Medium. + + "MA-S" MAC Address Block Small. + + "MAC" Media Access Control, not Message Authentication Code. + + "MAC-48" A 48-bit MAC address. This term is obsolete. If + globally unique, use EUI-48. + + "OUI" Organizationally Unique Identifier. See Section 2.1.2. + + "RRTYPE" A DNS Resource Record type [RFC6895]. + + "SLAP" IEEE 802 Structured Local Address Plan [IEEE802_OandA]. + See Section 2.1.1. + + "SNAP" Subnetwork Access Protocol. See Section 3. + + "SSAP" Source Service Access Point. See Section 3. + + "tag" "Tag" is used in two contexts in this document. For + "Ethernet tag", see Section 3. For "CBOR tag", see + Section 2.4. + + "TLV" Type-Length-Value. + + "**" The double asterisk symbol indicates exponentiation. For + example, 2**24 is two to the twenty-fourth power. + +1.2. The IEEE Registration Authority + + Originally the responsibility of the Xerox Corporation, the + registration authority for Ethernet parameters since 1986 has been + the IEEE Registration Authority, available on the Web at [IEEE_RA]. + + The IEEE Registration Authority operates under the direction of the + IEEE Standards Association (IEEE SA) Board of Governors, with + oversight by the IEEE Registration Authority Committee (IEEE RAC). + The IEEE RAC is a committee of the Board of Governors. + + Anyone may apply to that authority for parameter assignments. The + IEEE Registration Authority may impose fees or other requirements but + commonly waives fees for applications from standards development + organizations. Lists of assignments and their holders are + downloadable from the IEEE Registration Authority site. + +1.3. The IANA Organizationally Unique Identifier + + The Organizationally Unique Identifier (OUI) 00-00-5E has been + assigned to IANA by the IEEE Registration Authority. + + There is no OUI value reserved at this time for documentation, but + there are documentation code points under the IANA OUI specified + below. + +1.4. CFM Code Points + + IEEE Std 802.1Q [IEEE.802.1Q_2014] allocates two blocks of 802 + Connectivity Fault Management (CFM) code points to the IETF, one for + CFM OpCodes and one for CFM TLV Types. For further information, see + [RFC7319]. The IANA "Connectivity Fault Management (CFM) OAM IETF + Parameters" registry has subregistries for these code points. This + document does not further discuss these blocks of code points. + +2. Ethernet Identifier Parameters + + This section includes information summarized from [IEEE802_OandA] + that is being provided for context. The definitive information, + which prevails in case of any discrepancy, is in [IEEE802_OandA]. + + Section 2.1 discusses 48-bit MAC identifiers, their relationship to + OUIs and other prefixes, and assignment under the IANA OUI. + Section 2.2 extends this to 64-bit identifiers. Section 2.3 + discusses other IETF MAC identifier uses not under the IANA OUI. + Section 2.4 specifies CBOR tags for MAC addresses and OUIs/CIDs. + + | Historical Note: [RAC_OUI] is an expired Internet-Draft that + | provides additional historic information on [IEEE802] + | registries. + +2.1. 48-Bit MAC Identifiers, OUIs, and Other Prefixes + + 48-bit MAC "addresses" are the most commonly used Ethernet interface + identifiers. Those that are globally unique are also called EUI-48 + identifiers (Extended Unique Identifier 48). An EUI-48 is structured + into an initial prefix assigned by the IEEE Registration Authority + and additional bits assigned by the prefix owner. As of 2024, there + are three lengths of prefixes assigned, as shown in the table below; + however, some prefix bits can have special meaning, as shown in + Figure 1. + + +=======================+======+=========================+ + | Prefix Length in Bits | Name | Owner Supplied Bits for | + | | | 48-bit MAC Addresses | + +=======================+======+=========================+ + | 24 | MA-L | 24 | + +-----------------------+------+-------------------------+ + | 28 | MA-M | 20 | + +-----------------------+------+-------------------------+ + | 36 | MA-S | 12 | + +-----------------------+------+-------------------------+ + + Table 1 + + The bottom (least significant) four bits of the first octet of the + 6-octet 48-bit MAC have special meaning, as shown in Figure 1, and + are referred to below as the M, X, Y, and Z bits. + + 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | . . . . Z Y X M| . . . . . . . .| octets 0+1 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | . . . . . . . .| . . . . . . . .| octets 2+3 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | . . . . . . . .| . . . . . . . .| octets 4+5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + Figure 1: 48-Bit MAC Address Structure + + 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 + 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 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 one and a half octets (12 bits) they can control in constructing + 48-bit MAC addresses; other prefix lengths are also available + [IEEEtutorials]. + + 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. + + IEEE Std 802 describes assignment procedures and policies for + identifiers related to IEEE 802 [IEEE802_OandA]. IEEE RA + documentation on EUIs, OUIs, and CIDs is available at + [IEEEtutorials]. + +2.1.1. Special First Octet Bits + + There are bits within the initial octet of an IEEE MAC address that + have special significance [IEEE802_OandA], as described as follows: + + M bit - 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 one, the address is groupcast (multicast or broadcast). + This meaning is independent of the values of the X, Y, and Z bits. + + X bit - This bit is also called the "universal/local" bit (formerly + called the Local/Global bit). If it is zero, the MAC address is a + 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 assignment and control of the + local network operator (but see Section 2.3). 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 determined by the Y + and Z bits, as described below. + + Y&Z bits - These two bits have no special meaning if the X 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 + formerly uniform "local" MAC address space into four quadrants as + follows and further described below: + + +=======+=======+===========================+ + | Y bit | Z bit | Quadrant | + +=======+=======+===========================+ + | 0 | 0 | Administratively Assigned | + +-------+-------+---------------------------+ + | 0 | 1 | Extended Local | + +-------+-------+---------------------------+ + | 1 | 0 | Reserved | + +-------+-------+---------------------------+ + | 1 | 1 | Standard Assigned | + +-------+-------+---------------------------+ + + Table 2 + + While a local network administrator can assign any addresses with 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: + + Administratively Assigned - MAC addresses in this quadrant are + called Administratively Assigned Identifiers. This is intended + for arbitrary local assignment, such as random assignment; + however, see Section 2.3.1. + + Extended Local - MAC addresses in this quadrant are called Extended + Local Identifiers. These addresses are not actually "local" under + 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 24-bit prefix with X, Y, and Z bits having the values 1, 0, + and 1, respectively. + + Reserved - MAC addresses in this quadrant are reserved for future + use under the SLAP. Until such future use, they could be locally + assigned as Administratively Assigned Identifiers are assigned, + but there is a danger that future SLAP use would conflict with + such local assignments. + + Standard Assigned - MAC addresses in this quadrant are called + Standard Assigned Identifiers (SAIs). An SAI is assigned by a + protocol specified in an IEEE 802 standard, for example, + [IEEE802.1CQ] (but see the first NOTE below). + + NOTE: While the SLAP has MAC addresses assigned through a local + protocol in the SAI quadrant and assigned by a protocol + specified in an IEEE 802 standard, the SLAP is optional. Local + network administrators may use the IETF protocol provisions in + [RFC8947] and [RFC8948], which support assignment of a MAC + address in the local MAC address space using DHCPv6 [RFC8415] + or other protocol methods. + + NOTE: There isn't any automated way to determine if or to what extent + a local network is configured for and/or operating according to SLAP. + +2.1.2. OUIs and CIDs + + 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 + group MAC addresses by extending a modified version of the assigned + OUI in which the M bit (see Figure 1) is set to 1 [IEEEtutorials]. + + The Local bit is zero for globally unique EUI-48 identifiers 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 identifier + under the control of the local network administrator; however, there + are now recommendations on optional management of the local address + space, as discussed in Section 2.1.1. If the Local bit 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 beginning of their + longer prefix. + + A CID is a 24-bit Company Identifier. It is assigned for + organizations that need such an identifier that can be used in place + 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 (see + Figure 1). + + An AFN and a CBOR tag have been assigned for OUIs/CIDs, as discussed + in Sections 2.4, 5.3, and 5.9. + +2.1.3. 48-Bit MAC Assignments under the IANA OUI + + The OUI 00-00-5E has been assigned to IANA, as stated in Section 1.3 + above. This includes 2**24 48-bit multicast identifiers from + 01-00-5E-00-00-00 to 01-00-5E-FF-FF-FF and 2**24 EUI-48 unicast + identifiers from 00-00-5E-00-00-00 to 00-00-5E-FF-FF-FF. + + Of these identifiers, the sub-blocks reserved or thus far assigned + are as follows: + + Unicast, all blocks of 2**8 addresses thus far: + 00-00-5E-00-00-00 through 00-00-5E-00-00-FF: reserved and require + IESG Ratification for assignment (see Section 5.1). + + 00-00-5E-00-01-00 through 00-00-5E-00-01-FF: assigned for the + Virtual Router Redundancy Protocol (VRRP) [RFC5798]. + + 00-00-5E-00-02-00 through 00-00-5E-00-02-FF: assigned for the + IPv6 Virtual Router Redundancy Protocol (IPv6 VRRP) [RFC5798]. + + 00-00-5E-00-52-00 through 00-00-5E-00-52-FF: used for very small + assignments. As of 2024, 4 out of these 256 values have been + assigned. See [EthernetNum]. + + 00-00-5E-00-53-00 through 00-00-5E-00-53-FF: assigned for use in + documentation by this document. + + 00-00-5E-90-01-00 through 00-00-5E-90-01-FF: used for very small + assignments that need parallel unicast and multicast MAC + addresses. As of 2024, 1 out of these 256 values has been + assigned. See [EthernetNum]. + + Multicast: + 01-00-5E-00-00-00 through 01-00-5E-7F-FF-FF: 2**23 addresses + assigned for IPv4 multicast [RFC1112]. + + 01-00-5E-80-00-00 through 01-00-5E-8F-FF-FF: 2**20 addresses + assigned for MPLS multicast [RFC5332]. + + 01-00-5E-90-00-00 through 01-00-5E-90-00-FF: 2**8 addresses being + used for very small assignments. As of 2024, 4 out of these + 256 values have been assigned. See [EthernetNum]. + + 01-00-5E-90-01-00 through 01-00-5E-90-01-FF: used for very small + assignments that need parallel unicast and multicast MAC + addresses. As of 2024, 1 out of these 256 values has been + assigned. See [EthernetNum]. + + 01-00-5E-90-10-00 through 01-00-5E-90-10-FF: 2**8 addresses + assigned for use in documentation by this document. + + For more detailed and up-to-date information, see the "IANA OUI + Ethernet Numbers" registry at [EthernetNum]. + +2.1.4. 48-Bit MAC Documentation Values + + The following values have been assigned for use in documentation: + + * 00-00-5E-00-53-00 through 00-00-5E-00-53-FF for unicast and + + * 01-00-5E-90-10-00 through 01-00-5E-90-10-FF for multicast. + +2.1.5. 48-Bit IANA MAC Assignment Considerations + + 48-bit assignments under the current or a future IANA OUI (see + Section 5.6) must meet the following requirements: + + * must be for standards purposes (either for an IETF Standard or + other standard related to IETF work), + + * 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 + assignment of one (2**0) identifier, + + * must not be used to evade the requirement for network interface + vendors to obtain their own block of identifiers from the IEEE, + and + + * must be documented in an Internet-Draft or RFC. + + In addition, approval must be obtained as follows (see the procedure + in Section 5.1): + + * Small to medium assignments of a block of 1, 2, 4, ..., 32768, + 65536 (2**0, 2**1, 2**2, ..., 2**15, 2**16) EUI-48 identifiers + require Expert Review (see Section 5.1). + + * Large assignments of 131072 (2**17) or more EUI-48 identifiers + require IESG Ratification (see Section 5.1). + +2.2. 64-Bit MAC Identifiers + + IEEE also defines a system of 64-bit MAC identifiers, including + EUI-64s. EUI-64 identifiers are used as follows: + + * In IEEE Std 1394 [IEEE1394] (also known as FireWire and i.Link) + + * In IEEE Std 802.15.4 [IEEE802.15.4] (also known as Zigbee) + + * In [InfiniBand] + + * In a modified form to construct some IPv6 Interface Identifiers, + as described in Section 2.2.1, although this use is now deprecated + + Adding a 5-octet (40-bit) extension to a 3-octet (24-bit) assignment, + or a shorter extension to longer assigned prefixes [RAC_OUI] so as to + total 64 bits, produces an EUI-64 identifier under that OUI or longer + prefix. As with EUI-48 identifiers, the first octet has the same + special low-order bits. + + 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. + + The discussion below is almost entirely in terms of the "Modified" + form of EUI-64 identifiers; however, anyone assigned such an + identifier can also use the unmodified form as a MAC identifier on + any link that uses such 64-bit identifiers for interfaces. + +2.2.1. IPv6 Use of Modified EUI-64 Identifiers + + The approach described below for constructing IPv6 Interface + Identifiers is now deprecated, and the method specified in [RFC8064] + is recommended. + + EUI-64 identifiers have been used to form the lower 64 bits of some + IPv6 addresses (Section 2.5.1 and Appendix A of [RFC4291] and + Appendix A of [RFC5214]). When so used, the EUI-64 is modified by + inverting the X (universal/local) bit to form an IETF "Modified + EUI-64 identifier". Below is an illustration of a Modified EUI-64 + unicast identifier under the IANA OUI, where aa-bb-cc-dd-ee is the + extension. + + 02-00-5E-aa-bb-cc-dd-ee + + The first octet is shown as 02 rather than 00 because, in Modified + EUI-64 identifiers, the sense of the X bit is inverted compared with + EUI-48 identifiers. It is the globally unique values (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 off are + typically locally assigned and out of scope for global assignment. + + The X (universal/local) bit was inverted to make it easier for + network operators to type in local-scope identifiers. Thus, such + Modified EUI-64 identifiers as 1, 2, etc. (ignoring leading zeros) + are 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 local. + + As with 48-bit MAC identifiers, the M bit (0x01) on in the first + octet indicates a group identifier (multicast or broadcast). + + When the first two octets of the extension of a Modified EUI-64 + identifier are FF-FE, the remainder of the extension is a 24-bit + value, as assigned by the OUI owner for an EUI-48. For example: + + 02-00-5E-FF-FE-yy-yy-yy + + or + + 03-00-5E-FF-FE-yy-yy-yy + + where yy-yy-yy is the portion (of an EUI-48 global unicast or + multicast identifier) that is assigned by the OUI owner (IANA in this + case). Thus, any holder of one or more EUI-48 identifiers under the + IANA OUI also has an equal number of Modified EUI-64 identifiers that + can be formed by inserting FF-FE in the middle of their EUI-48 + identifiers and inverting the universal/local bit. + + In addition, certain Modified EUI-64 identifiers under the IANA OUI + are reserved for holders of IPv4 addresses as follows: + + 02-00-5E-FE-xx-xx-xx-xx + + 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-64 address. + Modified EUI-64 identifiers from + + 02-00-5E-FE-F0-00-00-00 to 02-00-5E-FE-FF-FF-FF-FF + + are effectively reserved pending the specification of IPv4 "Class E" + addresses [RFC1112]. However, for Modified EUI-64 identifiers based + on an IPv4 address, the universal/local bit should be set to + correspond to whether the IPv4 address is local or global. (Keep in + mind that the sense of the Modified EUI-64 identifier universal/local + bit is reversed from that in (unmodified) EUI-64 identifiers.) + +2.2.2. EUI-64 IANA Assignment Considerations + + The following table shows which Modified EUI-64 identifiers under the + IANA OUI are reserved, assigned, or available as indicated. As noted + above, the corresponding MAC addresses can be determined by + complementing the 02 bit in the first octet. In all cases, the + corresponding multicast 64-bit MAC addresses formed by complementing + the 01 bit in the first octet have the same status as the modified + 64-bit unicast address blocks listed below. These values are + prefixed with 02-00-5E to form unicast modified EUI-64 addresses. + + +==================================+===================+===========+ + | Addresses | Usage | Reference | + +==================================+===================+===========+ + | 00-00-00-00-00 to 0F-FF-FF-FF-FF | Reserved | RFC 9542 | + +----------------------------------+-------------------+-----------+ + | 10-00-00-00-00 to 10-00-00-00-FF | Documentation | RFC 9542 | + +----------------------------------+-------------------+-----------+ + | 10-00-00-01-00 to EF-FF-FF-FF-FF | Unassigned | | + +----------------------------------+-------------------+-----------+ + | FD-00-00-00-00 to FD-FF-FF-FF-FF | Reserved | RFC 9542 | + +----------------------------------+-------------------+-----------+ + | FE-00-00-00-00 to FE-FF-FF-FF-FF | IPv4 Addr Holders | RFC 9542 | + +----------------------------------+-------------------+-----------+ + | FF-00-00-00-00 to FF-FD-FF-FF-FF | Reserved | RFC 9542 | + +----------------------------------+-------------------+-----------+ + | FF-FE-00-00-00 to FF-FE-FF-FF-FF | IANA EUI-48 | RFC 9542 | + | | Holders | | + +----------------------------------+-------------------+-----------+ + | FF-FF-00-00-00 to FF-FF-FF-FF-FF | Reserved | RFC 9542 | + +----------------------------------+-------------------+-----------+ + + Table 3: IANA 64-bit MAC Addresses + + The reserved identifiers above require IESG Ratification (see + Section 5.1) for assignment. IANA EUI-64 identifier assignments + under the IANA OUI must meet the following requirements: + + * must be for standards purposes (either for an IETF Standard or + other standard related to IETF work), + + * 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 + assignment of one (2**0) identifier, + + * must not be used to evade the requirement for network interface + vendors to obtain their own block of identifiers from the IEEE, + and + + * must be documented in an Internet-Draft or RFC. + + In addition, approval must be obtained as follows (see the procedure + in Section 5.1): + + * Small to medium assignments of a block of 1, 2, 4, ..., 134217728, + 268435456 (2**0, 2**1, 2**2, ..., 2**27, 2**28) EUI-64 identifiers + require Expert Review (see Section 5.1). + + * Large assignments of 536870912 (2**29) or more EUI-64 identifiers + require IESG Ratification (see Section 5.1). + +2.2.3. EUI-64 Documentation Values + + The following blocks of unmodified 64-bit MAC addresses are for + documentation use. The IPv4-derived addresses are based on the IPv4 + documentation addresses [RFC5737], and the MAC-derived addresses are + based on the EUI-48 documentation addresses above. + + Unicast values for documentation use: + + 00-00-5E-EF-10-00-00-00 to 00-00-5E-EF-10-00-00-FF general + + 00-00-5E-FE-C0-00-02-00 to 00-00-5E-FE-C0-00-02-FF and + 00-00-5E-FE-C6-33-64-00 to 00-00-5E-FE-C6-33-64-FF and + 00-00-5E-FE-CB-00-71-00 to 00-00-5E-FE-CB-00-71-FF IPv4 derived + + 00-00-5E-FF-FE-00-53-00 to 00-00-5E-FF-FE-00-53-FF EUI-48 derived + + 00-00-5E-FE-EA-C0-00-02 and 00-00-5E-FE-EA-C6-33-64 and + 00-00-5E-FE-EA-CB-00-71 IPv4 multicast derived from IPv4 unicast + [RFC6034] + + Multicast values for documentation use: + + 01-00-5E-EF-10-00-00-00 to 01-00-5E-EF-10-00-00-FF general + + 01-00-5E-FE-C0-00-02-00 to 01-00-5E-FE-C0-00-02-FF and + 01-00-5E-FE-C6-33-64-00 to 01-00-5E-FE-C6-33-64-FF and + 01-00-5E-FE-CB-00-71-00 to 01-00-5E-FE-CB-00-71-FF IPv4 derived + + 01-00-5E-FE-EA-C0-00-02 and 01-00-5E-FE-EA-C6-33-64 and + 01-00-5E-FE-EA-CB-00-71 IPv4 multicast derived from IPv4 unicast + [RFC6034] + + 01-00-5E-FF-FE-90-10-00 to 01-00-5E-FF-FE-90-10-FF EUI-48 derived + +2.3. Other 48-Bit MAC Identifiers Used by the IETF + + There are two other blocks of 48-bit MAC identifiers that are used by + the IETF as described below. + +2.3.1. Identifiers with a '33-33' Prefix + + 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 33-33-FF-FF-FF-FF) are used as specified in + [RFC2464] 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 with existing hardware as a multicast identifier. They also + have the Local bit on, but any Ethernet using standard IPv6 multicast + should note that these addresses will be used for that purpose. + These multicast MAC addresses fall into the Administratively Assigned + SLAP quadrant (see Section 2.1.1). + + | Historical Notes: It was the custom during IPv6 design to use + | "3" for unknown or example values, and 3333 Coyote Hill Road, + | 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 Corporation. The pre-IEEE + | [IEEE.802.3_2012] Ethernet protocol has sometimes been known as + | "DIX" Ethernet from the first letters of the names of these + | companies. + +2.3.2. The CF Series + + The Informational [RFC2153] declared the 3-octet values from CF-00-00 + through CF-FF-FF to be "OUIs" available for assignment by IANA to + software vendors for use in PPP [RFC1661] or for other uses where + vendors do not 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 bits at the bottom of the first octet equal to one, + while all IEEE-assigned OUIs thus far have the X and M bits as zero + and all CIDs have the Y and M bits as zero; thus, there can be no + conflict between CF series "OUIs" and IEEE-assigned OUIs/CIDs. + Multicast MAC addresses constructed with a CF series OUI would fall + into the Standard Assigned SLAP quadrant (see Section 2.1.1). The + Group bit is meaningless in PPP. To quote [RFC2153]: "The 'CF0000' + series was arbitrarily chosen to match the PPP NLPID 'CF', as a + matter of mnemonic convenience." (For further information on Network + Layer Protocol Identifiers (NLPIDs), see [RFC6328].) + + CF-00-00 is reserved. CF-00-00-00-00-00 is a multicast identifier + listed by IANA as used for Ethernet loopback tests. + + In over a decade of availability, only a handful of values in the CF + series have been assigned. (See the "IANA OUI Ethernet Numbers" + [EthernetNum] and "Point-to-Point (PPP) Protocol Field Assignments" + [PPPNum] registry groups.) + +2.3.2.1. Changes to RFC 2153 + + The IANA Considerations in [RFC2153] were updated as follows by the + approval of [RFC5342] and remain so updated (no technical changes + have been made): + + * Use of these CF series identifiers based on IANA assignment was + deprecated. + + * IANA was instructed not to assign any further values in the CF + series. + +2.4. CBOR Tags + + The Concise Binary Object Representation (CBOR) [RFC8949] is a data + format whose design goals include the 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 give it some additional + semantics identified by that tag. CBOR-tagged data items (fields) + are not used in actual IEEE 802 address fields but may be used in + CBOR-encoded parts of protocol messages. + + 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 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 be used in + the future for the length of MAC addresses, such as a 128-bit + (16-octet) MAC address, the 48 tag will be used. + + IANA has assigned 1048 as the CBOR tag to indicate an OUI, CID, or 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 2.1.2). + +3. Ethernet Protocol Parameters + + Ethernet protocol parameters provide a means of indicating, near the + beginning of a frame, the contents of that frame -- for example, that + it contains IPv4 or IPv6. + + There are two types of protocol identifier parameters (see + [EthernetNum]) that can occur in Ethernet frames: + + EtherTypes: + These are 16-bit identifiers that, when considered as an unsigned + integer, are equal to or larger than 0x0600. Figure 2 shows the + simplest case where the EtherType of the protocol data in the + frame appears immediately after the destination and source MAC + addresses. [IEEE802_OandA] specifies two EtherTypes for local, + experimental use: 0x88B5 and 0x88B6. + + LSAPs: + These are 8-bit protocol identifiers that occur in pairs after a + field that gives the frame length. Such a length must, when + considered as an unsigned integer, be less than 0x5DD, or it could + be mistaken as an EtherType. However, the LLC encapsulation + EtherType 0x8870 [IEEE802.1AC] may also be used in place of such a + length as a "length indication" of nonspecific length. LSAPs + occur in pairs, where one is intended to indicate the source + protocol handler (SSAP) and the other the destination protocol + handler (DSAP); however, use cases where the two are different + have been relatively rare. See Figure 3 for the simplest case + where the length field appears immediately after the destination + and source MAC addresses. In that figure, the CTL (control) field + value of 3 indicates datagram service. This type of protocol + identification is sometimes called "LLC" (Logical Link Control). + + 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | Destination MAC Address /// + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | Source MAC Address /// + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | EtherType, greater than or equal to 0x0600 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | Protocol Data /// + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + Figure 2: EtherType Frame Protocol Labeling + + 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | Destination MAC Address /// + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | Source MAC Address /// + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | Frame length (or 0x8870) | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | DSAP | SSAP | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | CTL = 0x03 | Protocol Data /// + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + Figure 3: LSAP Frame Protocol Labeling + + The concept of EtherType labeling has been extended to labeling by + 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 tag, an EtherType, or an LLC Link-Layer Service Access Point + (LSAP) protocol indicator for the "main" body of the frame. + Customarily, in the world of [IEEE802_OandA], tags are a fixed length + and do not include any encoding of their own length. An example is + the C-Tag (formerly the Q-Tag) [IEEE.802.1Q_2014]. It provides + customer VLAN and priority information for a frame. Any device that + is processing a frame cannot, in general, safely process anything in + the frame past an EtherType it does not understand. + + Neither EtherTypes nor LSAPs are assigned by IANA; they are assigned + by the IEEE Registration Authority [IEEE_RA] (see Section 1.2 and + Appendix B). However, both LSAPs and EtherTypes have extension + mechanisms so that they can be used with five-octet Ethernet protocol + identifiers under an OUI, including those assigned by IANA under the + IANA OUI. + + When using the IEEE 802 Logical Link Control (LLC) format (Subnetwork + Access Protocol (SNAP)) [IEEE802_OandA] for a frame, an OUI-based + protocol identifier can be expressed as follows: + + xx-xx-AA-AA-03-yy-yy-yy-zz-zz + + where xx-xx is the frame length and, as above, must be small enough + not to be confused with an EtherType; "AA" is the LSAP that indicates + this use and is sometimes referred to as the SNAP Service Access + Point (SNAP SAP); "03" is the LLC control octet indicating datagram + service; yy-yy-yy is an OUI; and zz-zz is a protocol number, under + that OUI, assigned by the OUI owner. The five-octet length for such + OUI-based protocol identifiers results, with the LLC control octet + ("0x03"), in the preservation of 16-bit alignment. + + When using an EtherType to indicate the main type for a frame body, + the special "OUI Extended EtherType" 0x88B7 is available. Using this + EtherType, a frame body can begin with + + 88-B7-yy-yy-yy-zz-zz + + where yy-yy-yy and zz-zz have the same meaning as in the SNAP format + described above; however, this format with EtherType 0x88B7 does not + preserve 16-bit alignment. + + It is also possible, within the SNAP format, to use an arbitrary + EtherType. Putting the EtherType as the zz-zz field after an all- + zeros OUI (00-00-00) does this. It looks like + + xx-xx-AA-AA-03-00-00-00-zz-zz + + where zz-zz is the EtherType. + + As well as labeling frame contents, IEEE 802 protocol types appear + within Non-Broadcast Multi-Access (NBMA) Next Hop Resolution Protocol + [RFC2332] messages. Such messages have provisions for both two-octet + EtherTypes and OUI-based protocol types. 16-bit EtherTypes also occur + in the Generic Routing Encapsulation (GRE) [RFC2784] header and in + the Generic Network Virtualization Encapsulation (Geneve) [RFC8926] + encapsulation header. + +3.1. Ethernet Protocol Assignment under the IANA OUI + + Two-octet protocol numbers under the IANA OUI are available, as in + + 88-B7-00-00-5E-qq-qq + + or + + xx-xx-AA-AA-03-00-00-5E-qq-qq + + where qq-qq is the protocol number. + + A number of such assignments have been made out of the 2**16 protocol + numbers available from 00-00-5E-00-00 to 00-00-5E-FF-FF (see + [EthernetNum]). The extreme values of this range, 00-00-5E-00-00 and + 00-00-5E-FF-FF, are reserved and require IESG Ratification for + assignment (see Section 5.1). New assignments of protocol numbers + (qq-qq) under the IANA OUI must meet the following requirements: + + * the assignment must be for standards use (either for an IETF + Standard or other standard related to IETF work), + + * the protocol must include a version field at a fixed offset or an + equivalent marking such that later versions can be indicated in a + way recognizable by earlier versions, + + * the protocol must be documented in an Internet-Draft or RFC, and + + * such protocol numbers are not to be assigned for any protocol that + has an EtherType. (That EtherType can be used directly, or -- in + the LSAPs case -- it can be used with the SNAP SAP by putting an + all-zero "OUI" before the EtherType as described above.) + + In addition, the Expert Review (or IESG Ratification for the two + reserved values) must be obtained using the procedure specified in + Section 5.1. + +3.2. Documentation Protocol Number + + 0x0042 is a protocol number under the IANA OUI (that is, + 00-00-5E-00-42) to be used as an example for documentation purposes. + +4. Other OUI/CID-Based Parameters + + Some IEEE 802 and other protocols provide for parameters based on 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 called Organizationally Specific parameters (sometimes informally + and less accurately referred to as "vendor specific"). They would + look like + + yy-yy-yy-zz + + where yy-yy-yy is the OUI/CID and zz is the additional specifier. An + example is the Cipher Suite Selector in [IEEE.802.11_2012]. + + Values may be assigned under the IANA OUI for other OUI-based + parameter usage by Expert Review, except that, for each use, the + additional specifier values consisting of all zero bits and all one + bits (0x00 (00-00-5E-00) and 0xFF (00-00-5E-FF) for a one-octet + specifier) are reserved and require IESG Ratification (see + Section 5.1) for assignment; also, the additional specifier value + 0x42 (00-00-5E-42 for a 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 example in documentation. + + Assignments of other IANA OUI-based parameters must be for standards + use (either for an IETF Standard or other standard related 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 type, an IANA + registry will be created to contain that assignment and any + subsequent assignments of values for that parameter under the IANA + OUI. The Expert may specify the name of the registry. + + If different policies from those above are required for such a + parameter, a BCP or Standards Track RFC should be adopted to update + this BCP and specify the new policy and parameter. + +4.1. LLDP IETF Organizationally Specific TLV Type + + An example of an "other IANA OUI-based parameter" is specified in + [RFC8520]. This provides for an Organizationally Specific TLV type + for announcing a Manufacturer Usage Description (MUD) Uniform + Resource Locator (URL) in the IEEE Link Local Discovery Protocol + (LLDP) [IEEE802.1AB]. Additional IETF use of code points in this + space have been proposed [BGP11dp]. (See also Section 5.8.) + +5. IANA Considerations + + This document concerns IANA considerations for the assignment of + Ethernet parameters in connection with the IANA OUI and related + matters. + + Note: The "IANA OUI Ethernet Numbers" registry group (web page) is + for registries of numbers assigned under the IANA OUI, while the + "IEEE 802 Numbers" registry group has informational lists of + numbers assigned by the IEEE Registration Authority. + + This document does not create any new IANA registries. + + The MAC address values assigned for documentation and the protocol + number for documentation were both assigned by [RFC7042]. + + No existing assignment is changed by this document. + +5.1. Expert Review and IESG Ratification + + This section specifies the procedures for Expert Review and IESG + Ratification of MAC, protocol, and other IANA OUI-based identifiers. + The Expert(s) referred to in this document shall consist of one or + more persons appointed by and serving at the pleasure of the IESG. + +5.1.1. Expert Review Guidance + + The procedure described for Expert Review assignments in this + document is consistent with the IANA Expert Review policy described + in [RFC8126]. + + While finite, the universe of MAC code points from which Expert- + judged assignments will be made is considered to be large enough that + the requirements given in this document and the Experts' good + judgment are sufficient guidance. The idea is for the Expert to + provide a light reasonableness check for small assignments of MAC + identifiers, with increased scrutiny by the Expert for medium-sized + assignments of MAC identifiers and assignments of protocol + identifiers and other IANA OUI-based parameters. + +5.1.2. Expert Review and IESG Ratification Procedure + + It can make sense to assign very large portions of the MAC identifier + code point space. (Note that existing assignments include one for + half of the entire multicast IANA 48-bit code point space and one for + a sixteenth of that multicast code point space.) In those cases, and + in cases of the assignment of "reserved" values, IESG Ratification of + an Expert Review approval recommendation is required as described + below. This can be viewed as a combination of Expert Review and IESG + Approval as defined in [RFC8126]. IESG Approval is required only + when the Expert does not reject the request. The procedure is as + follows: + + The applicant always completes the appropriate template from + Appendix A below and sends it to IANA <iana@iana.org>. + + IANA always sends the template to an appointed Expert. If the + Expert recuses themselves or is non-responsive, IANA may choose an + alternative appointed Expert or, if none is available, will + contact the IESG. + + In all cases, if IANA receives a disapproval from an Expert + selected to review an application template, the application will + be denied. The Expert should provide a reason for refusal, which + IANA will communicate back to the applicant. + + If the assignment is based on Expert Review: + + If IANA receives approval and code points are available, IANA + will make the requested assignment. + + If the assignment is based on IESG Ratification: + + The procedure starts with the first steps above for Expert + Review. If the Expert disapproves the application, they simply + inform IANA, who in turn informs the applicant that their + request is denied; however, if the Expert believes the + application should be approved or is uncertain and believes + that the circumstances warrant the attention of the IESG, the + Expert will inform IANA about their advice, and IANA will + forward the application, together with the reasons provided by + the Expert for approval or uncertainty, to the IESG. The IESG + must decide whether the assignment will be granted. 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 + ratify a favorable opinion by the Expert or decides against an + application where the Expert is uncertain, the application is + denied; 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 reason, which IANA will communicate + to the applicant. + +5.2. IANA Registry Group (Web Page) Name Changes + + For clarity and parallelism with the IANA "IEEE 802 Numbers" registry + group, the IANA "Ethernet Numbers" registry group has been renamed + the "IANA OUI Ethernet Numbers" registry. + + As this document replaces [RFC7042], references to [RFC7042] in IANA + registries in both the "IEEE 802 Numbers" and the "IANA OUI Ethernet + Numbers" registry groups have been replaced by references to this + document. Other IANA registry references to [RFC7042] are not + changed. + +5.3. MAC Address AFNs and RRTYPEs + + IANA has assigned Address Family Numbers (AFNs) for MAC addresses as + follows: + + +============+=========+========+===========+ + | AFN | Decimal | Hex | Reference | + +============+=========+========+===========+ + | 48-bit MAC | 16389 | 0x4005 | [RFC7042] | + +------------+---------+--------+-----------+ + | 64-bit MAC | 16390 | 0x4006 | [RFC7042] | + +------------+---------+--------+-----------+ + | OUI | 16391 | 0x4007 | [RFC7961] | + +============+=========+========+===========+ + | Lower 24 bits of a 48-bit MAC address: | + +============+=========+========+===========+ + | MAC/24 | 16392 | 0x4008 | [RFC7961] | + +============+=========+========+===========+ + | Lower 40 bits of a 64-bit MAC address: | + +============+=========+========+===========+ + | MAC/40 | 16393 | 0x4009 | [RFC7961] | + +------------+---------+--------+-----------+ + + Table 4 + + IANA has assigned DNS RRTYPEs [RFC6895] for MAC addresses as follows: + + +============+==========+==================+===========+ + | | | RRTYPE Code | | + +============+==========+=========+========+===========+ + | Data | Mnemonic | Decimal | Hex | Reference | + +============+==========+=========+========+===========+ + | 48-bit MAC | EUI48 | 108 | 0x006C | [RFC7043] | + +------------+----------+---------+--------+-----------+ + | 64-bit MAC | EUI64 | 109 | 0x006D | [RFC7043] | + +------------+----------+---------+--------+-----------+ + + Table 5 + +5.4. Informational IANA Registry Group Material + + IANA maintains an informational registry group, currently implemented + as a web page, concerning EtherTypes, OUIs, and multicast addresses + assigned under OUIs other than the IANA OUI. The title of this + informational registry group is "IEEE 802 Numbers". IANA updates + that informational registry group when changes are provided by or + approved by the Expert(s). + +5.5. EtherType Assignment Process + + Applying to the IEEE Registration Authority for an EtherType needed + by an IETF protocol requires IESG Approval, as stated in Appendix B. + To minimize confusion, this process will normally be done by the + primary expert for the informational "EtherType" registry within the + "IEEE 802 Numbers" registry group, as described below (see also + Section 5.4). + + After IESG Approval of the requirement for an EtherType, the IESG + should refer the matter to IANA. In any case, IANA will ask the + "EtherType" registry expert to execute the IEEE Registration + Authority [IEEE_RA] EtherType request process. This path is + specified because the IESG usually deals with IANA for assignment + actions and because IANA should be aware of which "EtherType" + registry expert(s) are available, normally referring the making of + the EtherType assignment request to the primary expert. + + Here is sample text for an Internet-Draft where both IANA and IEEE + assignments are required, where "YYY" would be replaced by an + explanation of for what/why the EtherType is needed in whatever level + of detail is necessary and would normally include a reference or + references to other appropriate parts of the Internet-Draft: + + | X. Assignment Considerations + | + | X.1. IEEE Assignment Considerations + | + | The IESG is requested to approve applying to the IEEE + | Registration Authority for an EtherType for YYY. (The IESG + | should communicate its approval to IANA and to those concerned + | with this document. IANA will forward the IESG Approval to the + | registry expert of the "EtherType" registry from the "IEEE 802 + | Numbers" registry group who will make the application to the + | IEEE Registration Authority, keeping IANA informed.) + | + | X.2. IANA Considerations + | + | ... + +5.6. OUI Exhaustion + + When the available space for either multicast or unicast EUI-48 + identifiers under OUI 00-00-5E has been 90% or more exhausted, IANA + should request an additional OUI from the IEEE Registration Authority + for further IANA assignment. The appointed Expert(s) should monitor + for this condition and notify IANA. + +5.7. IANA OUI MAC Address Table + + The following changes are made by this document to the Notes for the + "IANA Unicast 48-bit MAC Addresses", the "IANA Multicast 48-bit MAC + Addresses", and the "IANA 64-bit MAC Addresses" registries. In + addition, the references in those registries are updated, as + specified in Section 5.2. + + The Notes for the "IANA Unicast 48-bit MAC Addresses" registry and + for the "IANA Multicast 48-bit MAC Addresses" registry are changed to + the following: + + | These values are prefixed with 00-00-5E. See Section 2.1.3 of RFC + | 9542. + + The Note for the "IANA 64-bit MAC Addresses" registry is changed to + the following: + + | These values are prefixed with 00-00-5E to form unicast 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 to form multicast modified EUI-64 addresses. See RFC + | 9542, particularly Section 2.2.2, for more details. + +5.8. IANA LLDP TLV Subtypes + + IANA has moved the "IANA Link Layer Discovery Protocol (LLDP) TLV + Subtypes" registry from the "IEEE 802 Numbers" registry group to the + "IANA OUI Ethernet Numbers" registry group, since code points within + it are assigned by IANA, and has added RFC 9542 as an additional + reference for that registry. + + In addition, IANA has updated three entries in that registry as + follows: + + +=======+==================================+===========+ + | Value | Description | Reference | + +=======+==================================+===========+ + | 0 | Reserved | RFC 9542 | + +-------+----------------------------------+-----------+ + | 42 | Example for use in documentation | RFC 9542 | + +-------+----------------------------------+-----------+ + | 255 | Reserved | RFC 9542 | + +-------+----------------------------------+-----------+ + + Table 6 + + The entries for 1 (MUD), 2-41 (unassigned), and 43-254 (unassigned) + are unchanged. + +5.9. CBOR Tag Assignments + + IANA has assigned two CBOR Tags as shown below in the "Concise Binary + Object Representation (CBOR) Tags" registry. + + +======+=============+==================+===========+ + | Tag | Data Item | Semantics | Reference | + +======+=============+==================+===========+ + | 48 | byte string | IEEE MAC Address | RFC 9542 | + +------+-------------+------------------+-----------+ + | 1048 | byte string | IEEE OUI/CID | RFC 9542 | + +------+-------------+------------------+-----------+ + + Table 7 + +6. Security Considerations + + This document is concerned with assignment of IEEE 802 parameters + allocated to IANA, particularly those under the IANA OUI, and closely + related matters. It is not directly concerned with security except + as follows: + + Confusion and conflict can be caused by the use of MAC addresses + or other OUI-derived protocol parameters as examples in + documentation. Examples that are "only" to be used in + documentation can end up being coded and released or cause + conflicts due to later real use and the possible acquisition of + intellectual property rights in such addresses or parameters. The + reservation herein of MAC addresses and parameters for + documentation purposes will minimize such confusion and conflict. + + MAC addresses are identifiers provided by a device to the network. + On certain devices, MAC addresses are not static and can be + configured. The network should exercise caution when using these + addresses to enforce policy because addresses can be spoofed and + previously seen devices can return to the network with a new address. + + MAC addresses identify a physical or virtual interface and can be + used for tracking the device with that interface. Thus, they can be + used to track users associated with that device. See [madinas] for + related privacy considerations and a discussion of MAC address + randomization to partially mitigate this threat. Also, see [RFC7043] + for the security and privacy considerations of publishing MAC + addresses in DNS. + +7. References + +7.1. Normative References + + [IEEE.802.1Q_2014] + IEEE, "IEEE Standard for Local and metropolitan area + networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, + DOI 10.1109/ieeestd.2014.6991462, 18 December 2014, + <http://ieeexplore.ieee.org/servlet/ + opac?punumber=6991460>. + + [IEEE802.1AB] + IEEE, "IEEE Standard for Local and metropolitan area + networks - Station and Media Access Control Connectivity + Discovery", IEEE Std 802.1AB-2016, + DOI 10.1109/IEEESTD.2016.7433915, March 2016, + <https://doi.org/10.1109/IEEESTD.2016.7433915>. + + [IEEE802_OandA] + IEEE, "IEEE Standard for Local and Metropolitan Area + Networks: Overview and Architecture", IEEE Std 802-2014, + DOI 10.1109/IEEESTD.2014.6847097, June 2014, + <https://doi.org/10.1109/IEEESTD.2014.6847097>. + + IEEE, "IEEE Standard for Local and Metropolitan Area + Networks: Overview and Architecture -- Amendment 2: Local + Medium Access Control (MAC) Address Usage", IEEE Std 802c- + 2017, DOI 10.1109/IEEESTD.2017.8016709, August 2017, + <https://doi.org/10.1109/IEEESTD.2017.8016709>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + +7.2. Informative References + + [BGP11dp] Lindem, A., Patel, K., Zandi, S., Haas, J., and X. Xu, + "BGP Logical Link Discovery Protocol (LLDP) Peer + Discovery", Work in Progress, Internet-Draft, draft-acee- + idr-lldp-peer-discovery-17, 4 January 2024, + <https://datatracker.ietf.org/doc/html/draft-acee-idr- + lldp-peer-discovery-17>. + + [EthernetNum] + IANA, "IANA OUI Ethernet Numbers", + <https://www.iana.org/assignments/ethernet-numbers>. + + [IANA] IANA, "Internet Assigned Numbers Authority", + <https://www.iana.org>. + + [IEEE] IEEE, "Institute of Electrical and Electronics Engineers", + <https://www.ieee.org>. + + [IEEE.802.11_2012] + IEEE, "IEEE Standard for Information technology-- + Telecommunications and information exchange between + systems Local and metropolitan area networks--Specific + requirements Part 11: Wireless LAN Medium Access Control + (MAC) and Physical Layer (PHY) Specifications", + IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, 5 + April 2012, <http://ieeexplore.ieee.org/servlet/ + opac?punumber=6178209>. + + [IEEE.802.3_2012] + IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2012, + DOI 10.1109/ieeestd.2012.6419735, 24 January 2013, + <http://ieeexplore.ieee.org/servlet/ + opac?punumber=6419733>. + + [IEEE1394] IEEE, "IEEE Standard for a High-Performance Serial Bus", + IEEE Std 1394-2008, DOI 10.1109/IEEESTD.2008.4659233, + October 2008, + <https://doi.org/10.1109/IEEESTD.2008.4659233>. + + [IEEE802] IEEE 802, "IEEE 802 LMSC", <https://www.ieee802.org>. + + [IEEE802.15.4] + IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE + Std 802.15.4-2020, DOI 10.1109/IEEESTD.2020.9144691, July + 2020, <https://doi.org/10.1109/IEEESTD.2020.9144691>. + + [IEEE802.1AC] + IEEE 802, "IEEE Standard for Local and metropolitan area + networks -- Media Access Control (MAC) Service + Definition", IEEE Std 802.1AC-2016, + DOI 10.1109/IEEESTD.2017.7875381, March 2017, + <https://doi.org/10.1109/IEEESTD.2017.7875381>. + + [IEEE802.1CQ] + IEEE, "Draft Standard for Local and Metropolitan Area + Networks: Multicast and Local Address Assignment", draft + 0.8, IEEE Std 802.1CQ/D0.8, July 2022. + + [IEEEtutorials] + IEEE, "Guidelines for Use of Extended Unique Identifier + (EUI), Organizationally Unique Identifier (OUI), and + Company ID (CID)", August 2017, + <https://standards.ieee.org/wp- + content/uploads/import/documents/tutorials/eui.pdf>. + + [IEEE_RA] IEEE, "Registration Authority", + <https://standards.ieee.org/products-programs/regauth/>. + + [IEEE_SA] IEEE, "IEEE Standards Association", + <https://standards.ieee.org>. + + [InfiniBand] + InfiniBand Trade Association, "InfiniBand Architecture + Specification Volume 1", November 2007, + <https://www.infinibandta.org/>. + + [madinas] Zúñiga, JC., Bernardos, CJ., Ed., and A. Andersdotter, + "Randomized and Changing MAC Address state of affairs", + Work in Progress, Internet-Draft, draft-ietf-madinas-mac- + address-randomization-12, 28 February 2024, + <https://datatracker.ietf.org/doc/html/draft-ietf-madinas- + mac-address-randomization-12>. + + [PPPNum] IANA, "Point-to-Point (PPP) Protocol Field Assignments", + <https://www.iana.org/assignments/ppp-numbers>. + + [RAC_OUI] Parsons, G., "OUI Registry Restructuring", Work in + Progress, Internet-Draft, draft-ieee-rac-oui- + restructuring-01, 9 September 2013, + <https://datatracker.ietf.org/doc/html/draft-ieee-rac-oui- + restructuring-01>. + + [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, + RFC 1112, DOI 10.17487/RFC1112, August 1989, + <https://www.rfc-editor.org/info/rfc1112>. + + [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", + STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, + <https://www.rfc-editor.org/info/rfc1661>. + + [RFC2153] Simpson, W., "PPP Vendor Extensions", RFC 2153, + DOI 10.17487/RFC2153, May 1997, + <https://www.rfc-editor.org/info/rfc2153>. + + [RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. + Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", + RFC 2332, DOI 10.17487/RFC2332, April 1998, + <https://www.rfc-editor.org/info/rfc2332>. + + [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet + Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, + <https://www.rfc-editor.org/info/rfc2464>. + + [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS + Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, + <https://www.rfc-editor.org/info/rfc2606>. + + [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. + Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, + DOI 10.17487/RFC2784, March 2000, + <https://www.rfc-editor.org/info/rfc2784>. + + [RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology + of "Foo"", RFC 3092, DOI 10.17487/RFC3092, April 2001, + <https://www.rfc-editor.org/info/rfc3092>. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, DOI 10.17487/RFC4291, February + 2006, <https://www.rfc-editor.org/info/rfc4291>. + + [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, + "Multiprotocol Extensions for BGP-4", RFC 4760, + DOI 10.17487/RFC4760, January 2007, + <https://www.rfc-editor.org/info/rfc4760>. + + [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site + Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, + DOI 10.17487/RFC5214, March 2008, + <https://www.rfc-editor.org/info/rfc5214>. + + [RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, + "MPLS Multicast Encapsulations", RFC 5332, + DOI 10.17487/RFC5332, August 2008, + <https://www.rfc-editor.org/info/rfc5332>. + + [RFC5342] Eastlake 3rd, D., "IANA Considerations and IETF Protocol + Usage for IEEE 802 Parameters", RFC 5342, + DOI 10.17487/RFC5342, September 2008, + <https://www.rfc-editor.org/info/rfc5342>. + + [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks + Reserved for Documentation", RFC 5737, + DOI 10.17487/RFC5737, January 2010, + <https://www.rfc-editor.org/info/rfc5737>. + + [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) + Version 3 for IPv4 and IPv6", RFC 5798, + DOI 10.17487/RFC5798, March 2010, + <https://www.rfc-editor.org/info/rfc5798>. + + [RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast + Addresses", RFC 6034, DOI 10.17487/RFC6034, October 2010, + <https://www.rfc-editor.org/info/rfc6034>. + + [RFC6328] Eastlake 3rd, D., "IANA Considerations for Network Layer + Protocol Identifiers", BCP 164, RFC 6328, + DOI 10.17487/RFC6328, July 2011, + <https://www.rfc-editor.org/info/rfc6328>. + + [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA + Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, + April 2013, <https://www.rfc-editor.org/info/rfc6895>. + + [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and + IETF Protocol and Documentation Usage for IEEE 802 + Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, + October 2013, <https://www.rfc-editor.org/info/rfc7042>. + + [RFC7043] Abley, J., "Resource Records for EUI-48 and EUI-64 + Addresses in the DNS", RFC 7043, DOI 10.17487/RFC7043, + October 2013, <https://www.rfc-editor.org/info/rfc7043>. + + [RFC7319] Eastlake 3rd, D., "IANA Considerations for Connectivity + Fault Management (CFM) Code Points", BCP 191, RFC 7319, + DOI 10.17487/RFC7319, July 2014, + <https://www.rfc-editor.org/info/rfc7319>. + + [RFC7961] Eastlake 3rd, D. and L. Yizhou, "Transparent + Interconnection of Lots of Links (TRILL): Interface + Addresses APPsub-TLV", RFC 7961, DOI 10.17487/RFC7961, + August 2016, <https://www.rfc-editor.org/info/rfc7961>. + + [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, + "Recommendation on Stable IPv6 Interface Identifiers", + RFC 8064, DOI 10.17487/RFC8064, February 2017, + <https://www.rfc-editor.org/info/rfc8064>. + + [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., + Richardson, M., Jiang, S., Lemon, T., and T. Winters, + "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", + RFC 8415, DOI 10.17487/RFC8415, November 2018, + <https://www.rfc-editor.org/info/rfc8415>. + + [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage + Description Specification", RFC 8520, + DOI 10.17487/RFC8520, March 2019, + <https://www.rfc-editor.org/info/rfc8520>. + + [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., + "Geneve: Generic Network Virtualization Encapsulation", + RFC 8926, DOI 10.17487/RFC8926, November 2020, + <https://www.rfc-editor.org/info/rfc8926>. + + [RFC8947] Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer + Address Assignment Mechanism for DHCPv6", RFC 8947, + DOI 10.17487/RFC8947, December 2020, + <https://www.rfc-editor.org/info/rfc8947>. + + [RFC8948] Bernardos, CJ. and A. Mourad, "Structured Local Address + Plan (SLAP) Quadrant Selection Option for DHCPv6", + RFC 8948, DOI 10.17487/RFC8948, December 2020, + <https://www.rfc-editor.org/info/rfc8948>. + + [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object + Representation (CBOR)", STD 94, RFC 8949, + DOI 10.17487/RFC8949, December 2020, + <https://www.rfc-editor.org/info/rfc8949>. + +Appendix A. Templates + + This appendix provides the specific templates for IANA assignments of + parameters. Explanatory words in parentheses in the templates below + may be deleted in a completed template as submitted to IANA. + +A.1. EUI-48/EUI-64 Identifier or Identifier Block Template + + Applicant Name: + + Applicant Email: + + Applicant Telephone: (starting with the country code) + + Use Name: (brief name of Parameter use, such as "Foo Protocol" + [RFC3092]) + + Document: (I-D or RFC specifying use to which the identifier or block + of identifiers will be put) + + Specify whether this is an application for EUI-48 or EUI-64 + identifiers: + + Size of Block requested: (must be a power-of-two-sized block, can be + a block of size one (2**0)) + + Specify multicast, unicast, or both: + +A.2. IANA OUI/CID-Based Protocol Number Template + + Applicant Name: + + Applicant Email: + + Applicant Telephone: (starting with the country code) + + Use Name: (brief name of use of code point, such as "Foo Protocol") + + Document: (I-D or RFC specifying use to which the protocol identifier + will be put) + + Note: (any additional note) + +A.3. Other IANA OUI/CID-Based Parameter Template + + Applicant Name: + + Applicant Email: + + Applicant Telephone: (starting with the country code) + + Protocol where the OUI/CID-Based Parameter for which a value is being + requested appears: (such as Cipher Suite selection in IEEE 802.11) + + Use Name: (brief name of use of code point to be assigned, such as + "Foo Cipher Suite" [RFC3092]) + + Document: (I-D or RFC specifying use to which the other IANA OUI- + based parameter value will be put) + + Note: (any additional note) + +Appendix B. EtherTypes + + This appendix provides a copy of the IESG Statement issued in May + 2023 on obtaining new IETF EtherTypes in Appendix B.1. Note that + there is an informational IANA registry of some important EtherTypes + specified for IETF protocols or by IEEE 802 available, currently at + [IANA]. The IEEE Registration Authority page on EtherTypes + <https://standards.ieee.org/regauth/ethertype/eth.txt> may also be + useful. See Section 3 above. + +B.1. IESG Statement on EtherTypes + + From: IESG + Date: 1 May 2023 + + The IEEE Registration Authority (IEEE RA) assigns EtherTypes with + oversight from the IEEE Registration Authority Committee (IEEE RAC). + + (See https://standards.ieee.org/products-programs/regauth/ + ethertype/.) Some IETF protocol specifications make use of + EtherTypes. All EtherType applications are subject to IEEE RA + technical review for consistency with policy. + + 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 + protocol specification until the IESG has approved the protocol + specification for publication as an RFC. In exceptional cases, the + IEEE RA is willing to consider "early allocation" of an EtherType for + an IETF protocol that is still under development as long as the + request comes from and has been vetted by the IESG. + + 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 + assignment of EtherTypes for IETF protocols will be made by the IESG. + + Note that Local Experimental ("playpen") EtherTypes have been + assigned in IEEE 802 [1] use during protocol development and + experimentation. + + [1] IEEE Std 802. IEEE standard for Local and Metropolitan Area + Networks: Overview and Architecture. + +Appendix C. Changes from RFC 7042 + + This document obsoletes [RFC7042] and makes the changes listed below. + However, the completed application template based upon which an IANA + OUI-based protocol number value was assigned for document use remains + that in Appendix C of [RFC7042]. + + * Add information on MA-M (28-bit) and MA-S (36-bit) EUI prefixes + that the IEEE Registration Authority assigns. + + * Add information on the restructuring of the "local" MAC address + space into four quadrants under the Structured Local Address Plan + (SLAP) [IEEE802_OandA]. + + * Include the IESG Statement on EtherTypes (see Appendix B.1) and + more detailed IETF procedures for applying to the IEEE + Registration Authority for an EtherType for use in an IETF + protocol (see Section 5.5). + + * Mention that IEEE 802 CFM code points have been allocated to the + IETF (see Section 1.4). + + * Mention the Organizationally Specific LLDP data element that has + been assigned under the IANA OUI and the registry set up for + future such assignments (see Section 4.1). + + * Clarify minor details in Section 5.1 on Expert Review and IESG + Ratification. + + * Specify CBOR tags for MAC addresses and OUIs/CIDs (see + Section 2.4). + + * Add a version field requirement for the allocation of protocol + numbers under the IANA OUI (see Section 3.1). + + * Mention that EtherTypes are used in the Geneve [RFC8926] + encapsulation header (see Section 3). + + * Add "a combination of Expert Review and IESG Approval" as part of + the specification for "IESG Ratification". + +Acknowledgements + + The comments and suggestions of the following persons and + organizations are gratefully acknowledged: + + Comments and suggestions leading to this document: + + Carsten Bormann, Bob Hinden, the IEEE 802.1 Working Group, Éric + Vyncke, Dale Worley, and Amanda Baber + + Comments and suggestions leading to [RFC7042] (which is obsoleted + by this document): + + David Black, Adrian Farrel, Bob Grow, Joel Jaeggli, Pearl + Liang, Glenn Parsons, Pete Resnick, and Dan Romascanu + +Authors' Addresses + + Donald E. Eastlake 3rd + Independent + 2386 Panoramic Circle + Apopka, Florida 32703 + United States of America + Phone: +1-508-333-2270 + Email: d3e3e3@gmail.com, donald.eastlake@futurewei.com + + + Joe Abley + Cloudflare + Amsterdam + The Netherlands + Phone: +31 45 56 36 34 + Email: jabley@strandkip.nl + + + Yizhou Li + Huawei Technologies + 101 Software Avenue + Nanjing + Jiangsu, 210012 + China + Phone: +86-13809002299 + Email: liyizhou@huawei.com |