| RFC 9542 | IANA/IETF and IEEE 802 Parameters | April 2024 |
| Eastlake 3rd, et al. | Best Current Practice | [Page] |
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.¶
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 athttps://www.rfc-editor.org/info/rfc9542.¶
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.¶
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 inSection 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].¶
This document uses hexadecimal notation. Each octet (that is,8-bit byte) is represented by two hexadecimal digits giving the valueof the octet as an unsigned integer. Successive octets are separatedby a hyphen. This document consistently uses IETF ("network") bitordering although the physical order of bit transmission within anoctet on an IEEE[IEEE.802.3_2012] link is from the lowestorder bit to the highest order bit (i.e., the reverse of the IETF'sordering).¶
In this document:¶
Originally the responsibility of the Xerox Corporation, theregistration authority for Ethernet parameters since 1986 has been theIEEE Registration Authority, available on the Web at[IEEE_RA].¶
The IEEE Registration Authority operates under the direction of theIEEE Standards Association (IEEE SA) Board of Governors, withoversight by the IEEE Registration Authority Committee (IEEE RAC). The IEEERAC is a committee of the Board of Governors.¶
Anyone may apply to that authority for parameter assignments. TheIEEE Registration Authority may impose fees or other requirements butcommonly waives fees for applications from standards developmentorganizations. Lists of assignments and their holders are downloadablefrom the IEEE Registration Authority site.¶
The Organizationally Unique Identifier (OUI) 00‑00‑5E hasbeen assigned to IANA by the IEEE Registration Authority.¶
There is no OUI value reserved at this time for documentation, butthere are documentation code points under the IANA OUI specifiedbelow.¶
IEEE Std 802.1Q[IEEE.802.1Q_2014] allocates twoblocks of 802 Connectivity Fault Management (CFM) code points to theIETF, one for CFM OpCodes and one for CFM TLV Types. For furtherinformation, see[RFC7319]. The IANA "Connectivity FaultManagement (CFM) OAM IETF Parameters" registry has subregistries forthese code points. This document does not further discuss theseblocks of code points.¶
This section includes information summarized from[IEEE802_OandA] that is being provided for context. Thedefinitive information, which prevails in case of any discrepancy, isin[IEEE802_OandA].¶
Section 2.1 discusses 48-bit MAC identifiers, their relationship toOUIs and other prefixes, and assignment under the IANA OUI.Section 2.2 extends this to 64-bit identifiers.Section 2.3 discusses otherIETF MAC identifier uses not under the IANA OUI.Section 2.4 specifiesCBOR tags for MAC addresses and OUIs/CIDs.¶
Historical Note:[RAC_OUI] is an expiredInternet-Draft that provides additional historic information on[IEEE802] registries.¶
48-bit MAC "addresses" are the most commonly used Ethernetinterface identifiers. Those that are globally unique are also calledEUI‑48 identifiers (Extended Unique Identifier 48). AnEUI‑48 is structured into an initial prefix assigned by the IEEERegistration Authority and additional bits assigned by the prefixowner. As of 2024, there are three lengths of prefixes assigned, asshown in the table below; however, some prefix bits can have specialmeaning, as shown inFigure 1.¶
| Prefix Length in Bits | Name | Owner SuppliedBits for 48‑bit MAC Addresses |
|---|---|---|
| 24 | MA-L | 24 |
| 28 | MA-M | 20 |
| 36 | MA-S | 12 |
The bottom (least significant) four bits of the first octet of the6-octet 48-bit MAC have special meaning, as shown inFigure 1, and are referred to below as the M, X, Y, and Zbits.¶
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+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
For global addresses, X = 0 and a MAC address begins with 3 octets ora larger initial prefix indicating the assignee of the block of MACaddresses. This prefix is followed by a sequence of additional octetsso as to add up to the total MAC address length. For example, theIEEE assigns MAC Address Block Small (MA-S), where the first four anda half octets (36 bits) are assigned, giving the holder of the MA-Sone and a half octets (12 bits) they can control in constructing48-bit MAC addresses; other prefix lengths are also available[IEEEtutorials].¶
An AFN, a DNS RRTYPE, and a CBOR tag have been assigned for 48-bitMAC addresses, as discussed in Sections2.4,5.3, and5.9.¶
IEEE Std 802 describes assignment procedures and policies foridentifiers related to IEEE 802[IEEE802_OandA]. IEEE RAdocumentation on EUIs, OUIs, and CIDs is available at[IEEEtutorials].¶
There are bits within the initial octet of an IEEE MAC address thathave special significance[IEEE802_OandA], as described asfollows:¶
| Y bit | Z bit | Quadrant |
|---|---|---|
| 0 | 0 | Administratively Assigned |
| 0 | 1 | ExtendedLocal |
| 1 | 0 | Reserved |
| 1 | 1 | StandardAssigned |
While a local network administrator can assign any addresses withthe X bit a one, the optional SLAP characterizes the four quadrants ofthe "local" address space using the Y and Z bits as follows:¶
NOTE: While the SLAP has MAC addresses assigned througha local protocol in the SAI quadrant and assigned by a protocolspecified in an IEEE 802 standard, the SLAP is optional. Local networkadministrators may use the IETF protocol provisions in[RFC8947] and[RFC8948], which supportassignment of a MAC address in the local MAC address space usingDHCPv6[RFC8415] or other protocol methods.¶
NOTE: There isn't any automated way to determine if orto what extent a local network is configured for and/or operatingaccording to SLAP.¶
MA-L, MA-M, and MA-S MAC prefixes are assigned with the Local bitzero. The assignee of an OUI is exclusively authorized to assigngroup MAC addresses by extending a modified version of the assignedOUI in which the M bit (seeFigure 1) is set to 1[IEEEtutorials].¶
The Local bit is zero for globally unique EUI‑48 identifiersassigned by the owner of a MAC-L or owner of a longer prefix. If theLocal bit is a one, the identifier has historically been a localidentifier under the control of the local network administrator;however, there are now recommendations on optional management of thelocal address space, as discussed inSection 2.1.1. If the Local bitis a one, the holder of an OUI has no special authority over MACidentifiers whose first 3 octets correspond to their OUI or thebeginning of their longer prefix.¶
A CID is a 24-bit Company Identifier. It is assigned fororganizations that need such an identifier that can be used in placeof an OUI but do not need to assign subsidiary global MACaddresses. A CID has X and Z bits equal to 1 and its Y bit equal to 0(seeFigure 1).¶
An AFN and a CBOR tag have been assigned for OUIs/CIDs, as discussedin Sections2.4,5.3, and5.9.¶
The OUI 00‑00‑5E has been assigned to IANA, as stated inSection 1.3 above. This includes 2**24 48‑bitmulticast identifiers from 01‑00‑5E‑00‑00‑00to 01‑00‑5E‑FF‑FF‑FF and 2**24 EUI‑48unicast identifiers from 00‑00‑5E‑00‑00‑00 to00‑00‑5E‑FF‑FF‑FF.¶
Of these identifiers, the sub-blocks reserved or thus far assignedare as follows:¶
For more detailed and up-to-date information, see the "IANA OUI Ethernet Numbers" registry at[EthernetNum].¶
The following values have been assigned for use indocumentation:¶
48-bit assignments under the current or a future IANA OUI (seeSection 5.6) must meet the following requirements:¶
In addition, approval must be obtained as follows (see theprocedure inSection 5.1):¶
IEEE also defines a system of 64-bit MAC identifiers, includingEUI‑64s. EUI‑64 identifiers are used as follows:¶
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‑64identifier under that OUI or longer prefix. As with EUI‑48identifiers, the first octet has the same special low-order bits.¶
An AFN, a DNS RRTYPE, and CBOR tag have been assigned for 64-bitMAC addresses, as discussed in Sections2.4,5.3, and5.9.¶
The discussion below is almost entirely in terms of the "Modified"form of EUI‑64 identifiers; however, anyone assigned such anidentifier can also use the unmodified form as a MAC identifier on anylink that uses such 64-bit identifiers for interfaces.¶
The approach described below for constructing IPv6 InterfaceIdentifiers is now deprecated, and the method specified in[RFC8064] is recommended.¶
EUI‑64 identifiers have been used to form the lower 64 bits ofsome IPv6 addresses (Section2.5.1 and AppendixA of[RFC4291] andAppendix A of [RFC5214]). Whenso used, the EUI‑64 is modified by inverting the X (universal/local)bit to form an IETF "Modified EUI‑64 identifier". Below is anillustration of a Modified EUI‑64 unicast identifier under theIANA 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 ModifiedEUI‑64 identifiers, the sense of the X bit is inverted comparedwith EUI‑48 identifiers. It is the globally unique values(universal scope) that have the 0x02 bit (also known as the X oruniversal/local bit) on in the first octet, while those with this bitoff are typically locally assigned and out of scope for globalassignment.¶
The X (universal/local) bit was inverted to make it easier for networkoperators to type in local-scope identifiers. Thus, such ModifiedEUI‑64 identifiers as 1, 2, etc. (ignoring leading zeros) arelocal. Without the modification, they would have to be02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02, etc. to belocal.¶
As with 48-bit MAC identifiers, the M bit (0x01) on in the firstoctet indicates a group identifier (multicast or broadcast).¶
When the first two octets of the extension of a ModifiedEUI‑64 identifier are FF-FE, the remainder of the extension is a24-bit value, as assigned by the OUI owner for an EUI‑48. Forexample:¶
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 ormulticast identifier) that is assigned by the OUI owner (IANA in thiscase). Thus, any holder of one or more EUI‑48 identifiers underthe IANA OUI also has an equal number of Modified EUI‑64identifiers that can be formed by inserting FF-FE in the middle oftheir EUI‑48 identifiers and inverting the universal/local bit.¶
In addition, certain Modified EUI‑64 identifiers under theIANA 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 IPv4address 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 "ClassE" addresses[RFC1112]. However, for ModifiedEUI‑64 identifiers based on an IPv4 address, the universal/local bitshould be set to correspond to whether the IPv4 address is local orglobal. (Keep in mind that the sense of the Modified EUI‑64identifier universal/local bit is reversed from that in (unmodified)EUI‑64 identifiers.)¶
The following table shows which Modified EUI‑64 identifiersunder the IANA OUI are reserved, assigned, or available as indicated.As noted above, the corresponding MAC addresses can be determined bycomplementing the 02 bit in the first octet. In all cases, thecorresponding multicast 64-bit MAC addresses formed by complementingthe 01 bit in the first octet have the same status as the modified64-bit unicast address blocks listed below. These values are prefixed with02-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 Holders | RFC 9542 |
| FF-FF-00-00-00 to FF-FF-FF-FF-FF | Reserved | RFC 9542 |
The reserved identifiers above require IESG Ratification (seeSection 5.1) for assignment. IANA EUI‑64 identifier assignmentsunder the IANA OUI must meet the following requirements:¶
In addition, approval must be obtained as follows (see theprocedure inSection 5.1):¶
The following blocks of unmodified 64-bit MAC addresses are fordocumentation use. The IPv4-derived addresses are based on the IPv4documentation addresses[RFC5737], and the MAC-derivedaddresses are based on the EUI‑48 documentation addressesabove.¶
Unicast values for documentation use:¶
00‑00‑5E‑EF‑10‑00‑00‑00to 00‑00‑5E‑EF‑10‑00‑00‑FFgeneral¶
00‑00‑5E‑FE‑C0‑00‑02‑00to 00‑00‑5E‑FE‑C0‑00‑02‑FF and00‑00‑5E‑FE‑C6‑33‑64‑00 to00‑00‑5E‑FE‑C6‑33‑64‑FF and00‑00‑5E‑FE‑CB‑00‑71‑00 to00‑00‑5E‑FE‑CB‑00‑71‑FF IPv4derived¶
00‑00‑5E‑FF‑FE‑00‑53‑00to 00‑00‑5E‑FF‑FE‑00‑53‑FFEUI‑48 derived¶
00‑00‑5E‑FE‑EA‑C0‑00‑02and 00‑00‑5E‑FE‑EA‑C6‑33‑64 and00‑00‑5E‑FE‑EA‑CB‑00‑71 IPv4multicast derived from IPv4 unicast[RFC6034]¶
Multicast values for documentation use:¶
01‑00‑5E‑EF‑10‑00‑00‑00to 01‑00‑5E‑EF‑10‑00‑00‑FFgeneral¶
01‑00‑5E‑FE‑C0‑00‑02‑00to 01‑00‑5E‑FE‑C0‑00‑02‑FF and01‑00‑5E‑FE‑C6‑33‑64‑00 to01‑00‑5E‑FE‑C6‑33‑64‑FF and01‑00‑5E‑FE‑CB‑00‑71‑00 to01‑00‑5E‑FE‑CB‑00‑71‑FF IPv4derived¶
01‑00‑5E‑FE‑EA‑C0‑00‑02and 01‑00‑5E‑FE‑EA‑C6‑33‑64 and01‑00‑5E‑FE‑EA‑CB‑00‑71 IPv4multicast derived from IPv4 unicast[RFC6034]¶
01‑00‑5E‑FF‑FE‑90‑10‑00to 01‑00‑5E‑FF‑FE‑90‑10‑FFEUI‑48 derived¶
There are two other blocks of 48-bit MAC identifiers that are usedby the IETF as described below.¶
All 48-bit multicast MAC identifiers prefixed with "33-33" (that is, the2**32 multicast MAC identifiers in the range from 33-33-00-00-00-00 to33-33-FF-FF-FF-FF) are used as specified in[RFC2464]for IPv6 multicast. In all of these identifiers, the Group bit (thebottom bit of the first octet) is on, as is required to work properlywith existing hardware as a multicast identifier. They also have theLocal bit on, but any Ethernet using standard IPv6 multicast shouldnote that these addresses will be used for that purpose. Thesemulticast MAC addresses fall into the Administratively Assigned SLAPquadrant (seeSection 2.1.1).¶
Historical Notes: It was the custom during IPv6 designto use "3" for unknown or example values, and 3333 Coyote Hill Road,Palo Alto, California is the address of PARC (Palo Alto ResearchCenter), formerly "Xerox PARC." Ethernet was originally specified bythe Digital Equipment Corporation, Intel Corporation, and XeroxCorporation. The pre-IEEE[IEEE.802.3_2012] Ethernetprotocol has sometimes been known as "DIX" Ethernet from the firstletters of the names of these companies.¶
The Informational[RFC2153] declared the 3-octetvalues 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 nototherwise 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) specialbits at the bottom of the first octet equal to one, while allIEEE-assigned OUIs thus far have the X and M bits as zero and all CIDshave the Y and M bits as zero; thus, there can be no conflict between CFseries "OUIs" and IEEE-assigned OUIs/CIDs. Multicast MAC addressesconstructed with a CF series OUI would fall into the StandardAssigned SLAP quadrant (seeSection 2.1.1). The Group bit ismeaningless in PPP. To quote[RFC2153]: "The 'CF0000'series was arbitrarily chosen to match the PPP NLPID 'CF', as a matterof 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 identifierlisted by IANA as used for Ethernet loopback tests.¶
In over a decade of availability, only a handful of values in theCF series have been assigned. (See the "IANA OUI Ethernet Numbers"[EthernetNum] and "Point-to-Point (PPP) Protocol Field Assignments"[PPPNum] registry groups.)¶
The IANA Considerations in[RFC2153] were updated asfollows by the approval of[RFC5342] and remain so updated (notechnical changes have been made):¶
The Concise Binary Object Representation (CBOR)[RFC8949] is a data format whose design goals include thepossibility of very small code size, fairly small message size, andextensibility. In CBOR, a data item can be enclosed by a CBOR tag togive it some additional semantics identified by that tag. CBOR-taggeddata items (fields) are not used in actual IEEE 802 address fields butmay be used in CBOR-encoded parts of protocol messages.¶
IANA has assigned 48 as the CBOR tag to indicate a MACaddress. The enclosed data item is an octet string. The length of theoctet string indicates whether a 48-bit (6 octet) or 64-bit (8 octet) MACaddress is encoded. Should some other multiple of 8 bits be used in thefuture for the length of MAC addresses, such as a 128-bit (16-octet) MACaddress, the 48 tag will be used.¶
IANA has assigned 1048 as the CBOR tag to indicate an OUI, CID, orCF series organizational identifier. The enclosed data item is anoctet string of length 3 to hold the 24-bit OUI or CID (seeSection 2.1.2).¶
Ethernet protocol parameters provide a means of indicating, nearthe 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:¶
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 ///+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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 ///+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The concept of EtherType labeling has been extended to labeling byEthernet "tags". An Ethernet tag in this sense is a prefix whose typeis identified by an EtherType that is then followed by either anothertag, 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 lengthand do not include any encoding of their own length. An example isthe C-Tag (formerly the Q-Tag)[IEEE.802.1Q_2014]. Itprovides customer VLAN and priority information for a frame. Anydevice that is processing a frame cannot, in general, safely processanything in the frame past an EtherType it does not understand.¶
Neither EtherTypes nor LSAPs are assigned by IANA; they areassigned by the IEEE Registration Authority[IEEE_RA](seeSection 1.2 andAppendix B). However,both LSAPs and EtherTypes have extension mechanisms so that they canbe 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] fora frame, an OUI-based protocol identifier can be expressed asfollows:¶
xx‑xx‑AA‑AA‑03‑yy‑yy‑yy‑zz‑zz¶
where xx‑xx is the frame length and, as above, must be smallenough not to be confused with an EtherType; "AA" is the LSAP thatindicates this use and is sometimes referred to as the SNAP ServiceAccess Point (SNAP SAP); "03" is the LLC control octet indicatingdatagram service; yy‑yy‑yy is an OUI; and zz‑zz is aprotocol number, under that OUI, assigned by the OUI owner. Thefive-octet length for such OUI-based protocol identifiers results,with the LLC control octet ("0x03"), in the preservation of 16-bitalignment.¶
When using an EtherType to indicate the main type for a frame body,the special "OUI Extended EtherType" 0x88B7 is available. Using thisEtherType, 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 inthe SNAP format described above; however, this format with EtherType0x88B7 does not preserve 16-bit alignment.¶
It is also possible, within the SNAP format, to use an arbitraryEtherType. Putting the EtherType as the zz‑zz field after anall-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 appearwithin Non-Broadcast Multi-Access (NBMA) Next Hop Resolution Protocol[RFC2332] messages. Such messages have provisions forboth two-octet EtherTypes and OUI-based protocol types. 16-bitEtherTypes also occur in the Generic Routing Encapsulation (GRE)[RFC2784] header and in the Generic NetworkVirtualization Encapsulation (Geneve)[RFC8926] encapsulationheader.¶
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**16protocol numbers available from 00‑00‑5E‑00‑00 to00‑00‑5E‑FF‑FF (see[EthernetNum]).The extreme values of this range, 00‑00‑5E‑00‑00and 00‑00‑5E‑FF‑FF, are reserved and require IESGRatification for assignment (seeSection 5.1). New assignments ofprotocol numbers (qq‑qq) under the IANA OUI must meet thefollowing requirements:¶
In addition, the Expert Review (or IESG Ratification for the tworeserved values) must be obtained using the procedure specified inSection 5.1.¶
0x0042 is a protocol number under the IANA OUI (that is,00‑00‑5E‑00‑42) to be used as an example fordocumentation purposes.¶
Some IEEE 802 and other protocols provide for parameters based onan OUI or CID beyond those discussed above. Such parameters commonlyconsist of an OUI or CID plus one octet of additional value. They arecalled Organizationally Specific parameters (sometimes informally andless accurately referred to as "vendor specific"). They would looklike¶
yy‑yy‑yy‑zz¶
where yy‑yy‑yy is the OUI/CID and zz is the additionalspecifier. An example is the Cipher Suite Selector in[IEEE.802.11_2012].¶
Values may be assigned under the IANA OUI for other OUI-basedparameter usage by Expert Review, except that, for each use, theadditional specifier values consisting of all zero bits and all onebits (0x00 (00‑00‑5E‑00) and 0xFF(00‑00‑5E‑FF) for a one-octet specifier) are reservedand require IESG Ratification (seeSection 5.1) for assignment; also,the additional specifier value 0x42 (00‑00‑5E‑42 for aone octet specifier, right justified and filled with zeros on the leftif the specifier is more than one octet) is assigned for use as anexample in documentation.¶
Assignments of other IANA OUI-based parameters must be forstandards use (either for an IETF Standard or other standard relatedto IETF work) and be documented in an Internet-Draft or RFC. Thefirst time a value is assigned for a particular parameter of thistype, an IANA registry will be created to contain that assignment andany subsequent assignments of values for that parameter under the IANAOUI. The Expert may specify the name of the registry.¶
If different policies from those above are required for such aparameter, a BCP or Standards Track RFC should be adopted to updatethis BCP and specify the new policy and parameter.¶
An example of an "other IANA OUI-based parameter" is specifiedin[RFC8520]. This provides for anOrganizationally Specific TLV type for announcing a Manufacturer UsageDescription (MUD) Uniform Resource Locator (URL) in the IEEE LinkLocal Discovery Protocol (LLDP)[IEEE802.1AB]. Additional IETF use of code points in thisspace have been proposed[BGP11dp]. (See alsoSection 5.8.)¶
This document concerns IANA considerations for the assignment ofEthernet parameters in connection with the IANA OUI and relatedmatters.¶
Note: The "IANA OUI Ethernet Numbers" registrygroup (web page) is for registries of numbers assigned under the IANAOUI, while the "IEEE 802 Numbers" registry group has informationallists 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 protocolnumber for documentation were both assigned by[RFC7042].¶
No existing assignment is changed by this document.¶
This section specifies the procedures for Expert Review and IESGRatification of MAC, protocol, and other IANA OUI-based identifiers.The Expert(s) referred to in this document shall consist of one ormore persons appointed by and serving at the pleasure of theIESG.¶
The procedure described for Expert Review assignments in thisdocument is consistent with the IANA Expert Review policy described in[RFC8126].¶
While finite, the universe of MAC code points from whichExpert-judged assignments will be made is considered to be large enough thatthe requirements given in this document and the Experts' good judgmentare sufficient guidance. The idea is for the Expert to provide alight reasonableness check for small assignments of MAC identifiers, withincreased scrutiny by the Expert for medium-sized assignments of MACidentifiers and assignments of protocol identifiers and other IANAOUI-based parameters.¶
It can make sense to assign very large portions of the MACidentifier code point space. (Note that existing assignments includeone for half of the entire multicast IANA 48‑bit code point spaceand one for a sixteenth of that multicast code point space.) In thosecases, and in cases of the assignment of "reserved" values, IESGRatification of an Expert Review approval recommendation is requiredas described below. This can be viewed as a combination of ExpertReview and IESG Approval as defined in[RFC8126]. IESGApproval is required only when the Expert does not reject therequest. The procedure is as follows:¶
The applicant always completes the appropriate templatefromAppendix 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 choosean alternative appointed Expert or, if none is available, will contactthe IESG.¶
In all cases, if IANA receives a disapproval from anExpert selected to review an application template, the applicationwill be denied. The Expert should provide a reason for refusal, whichIANA 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 forExpert Review. If the Expert disapproves the application, they simplyinform IANA, who in turn informs the applicant that their request isdenied; however, if the Expert believes the application should beapproved or is uncertain and believes that the circumstances warrantthe attention of the IESG, the Expert will inform IANA about theiradvice, and IANA will forward the application, together with thereasons provided by the Expert for approval or uncertainty, to theIESG. The IESG must decide whether the assignment will be granted.This can be accomplished by a management item in an IESG telechat, asis done for other types of requests. If the IESG decides not toratify a favorable opinion by the Expert or decides against anapplication where the Expert is uncertain, the application is denied;otherwise, it is granted. The IESG will communicate its decision tothe Expert and to IANA. In case of refusal, the IESG should provide areason, which IANA will communicate to the applicant.¶
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 802Numbers" and the "IANA OUI Ethernet Numbers" registry groups havebeen replaced by references to this document. Other IANA registryreferences to[RFC7042] are not changed.¶
IANA has assigned Address Family Numbers (AFNs) for MAC addressesas 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] |
IANA has assigned DNS RRTYPEs[RFC6895] for MACaddresses as follows:¶
| RRTYPECode | ||||
|---|---|---|---|---|
| Data | Mnemonic | Decimal | Hex | Reference |
| 48-bit MAC | EUI48 | 108 | 0x006C | [RFC7043] |
| 64-bit MAC | EUI64 | 109 | 0x006D | [RFC7043] |
IANA maintains an informational registry group, currentlyimplemented as a web page, concerning EtherTypes, OUIs, and multicastaddresses assigned under OUIs other than the IANA OUI. The title ofthis informational registry group is "IEEE 802 Numbers". IANA updates that informational registry group when changes are provided byor approved by the Expert(s).¶
Applying to the IEEE Registration Authority for an EtherType neededby an IETF protocol requires IESG Approval, as stated inAppendix B. Tominimize confusion, this process will normally be done by the primaryexpert for the informational "EtherType" registry within the "IEEE 802 Numbers" registry group, asdescribed below (see alsoSection 5.4).¶
After IESG Approval of the requirement for an EtherType, the IESGshould refer the matter to IANA. In any case, IANA will ask the "EtherType" registry expert to execute the IEEERegistration Authority[IEEE_RA] EtherType requestprocess. This path is specified because the IESG usually deals withIANA 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 tothe primary expert.¶
Here is sample text for an Internet-Draft where both IANA and IEEEassignments are required, where "YYY" would be replaced by anexplanation of for what/why the EtherType is needed in whatever levelof detail is necessary and would normally include a reference orreferences 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¶
...¶
When the available space for either multicast or unicastEUI‑48 identifiers under OUI 00‑00‑5E has been 90% ormore exhausted, IANA should request an additional OUI from the IEEERegistration Authority for further IANA assignment. The appointedExpert(s) should monitor for this condition and notify IANA.¶
The following changes are made by this document to the Notes forthe "IANA Unicast 48-bit MAC Addresses", the "IANA Multicast 48-bitMAC Addresses", and the "IANA 64-bit MAC Addresses" registries. Inaddition, the references in those registries are updated, as specifiedinSection 5.2.¶
The Notes for the "IANA Unicast 48-bit MAC Addresses" registry andfor the "IANA Multicast 48-bit MAC Addresses" registry are changed tothe following:¶
These values are prefixed with 00-00-5E. SeeSection 2.1.3 of RFC 9542.¶
The Note for the "IANA 64-bit MAC Addresses" registry is changed tothe following:¶
These values are prefixed with 00-00-5E to form unicastMAC addresses, with 01-00-5E to form multicast MAC addresses, with02-00-5E to form unicast modified EUI-64 addresses, and with 03-00-5Eto form multicast modified EUI-64 addresses. See RFC 9542,particularlySection 2.2.2, for more details.¶
IANA has moved the "IANA Link Layer Discovery Protocol(LLDP) TLV Subtypes" registry from the "IEEE 802 Numbers" registrygroup to the "IANA OUI Ethernet Numbers" registry group, since codepoints within it are assigned by IANA, and has added RFC 9542 asan additional reference for that registry.¶
In addition, IANA has updated three entries in thatregistry as follows:¶
| Value | Description | Reference |
|---|---|---|
| 0 | Reserved | RFC 9542 |
| 42 | Example for use indocumentation | RFC 9542 |
| 255 | Reserved | RFC 9542 |
The entries for 1 (MUD), 2-41 (unassigned), and 43-254 (unassigned)are unchanged.¶
IANA has assigned two CBOR Tags as shown below in the"Concise Binary Object Representation (CBOR) Tags" registry.¶
| Tag | DataItem | Semantics | Reference |
|---|---|---|---|
| 48 | byte string | IEEE MACAddress | RFC 9542 |
| 1048 | byte string | IEEE OUI/CID | RFC 9542 |
This document is concerned with assignment of IEEE 802 parametersallocated to IANA, particularly those under the IANA OUI, and closelyrelated matters. It is not directly concerned with security except asfollows:¶
Confusion and conflict can be caused by the use of MACaddresses or other OUI-derived protocol parameters as examples indocumentation. Examples that are "only" to be used in documentationcan end up being coded and released or cause conflicts due to laterreal use and the possible acquisition of intellectual property rightsin such addresses or parameters. The reservation herein of MACaddresses and parameters for documentation purposes will minimize suchconfusion and conflict.¶
MAC addresses are identifiers provided by a device to thenetwork. On certain devices, MAC addresses are not static and can beconfigured. The network should exercise caution when using theseaddresses to enforce policy because addresses can be spoofed andpreviously seen devices can return to the network with a newaddress.¶
MAC addresses identify a physical or virtual interface and can beused for tracking the device with that interface. Thus, they can beused to track users associated with that device. See[madinas] for related privacy considerations and a discussionof MAC address randomization to partially mitigate this threat. Also,see[RFC7043] for the security and privacyconsiderations of publishing MAC addresses in DNS.¶
This appendix provides the specific templates for IANA assignmentsof parameters. Explanatory words in parentheses in the templatesbelow may be deleted in a completed template as submitted to IANA.¶
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 blockof identifiers will be put)¶
Specify whether this is an application for EUI‑48 or EUI‑64identifiers:¶
Size of Block requested: (must be a power-of-two-sized block, can bea block of size one (2**0))¶
Specify multicast, unicast, or both:¶
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 identifierwill be put)¶
Note: (any additional note)¶
Applicant Name:¶
Applicant Email:¶
Applicant Telephone: (starting with the country code)¶
Protocol where the OUI/CID-Based Parameter for which a value is beingrequested 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-basedparameter value will be put)¶
Note: (any additional note)¶
This appendix provides a copy of the IESG Statement issued in May2023 on obtaining new IETF EtherTypes inAppendix B.1. Note that thereis an informational IANA registry of some important EtherTypesspecified for IETF protocols or by IEEE 802 available, currently at[IANA]. The IEEE Registration Authority page onEtherTypes<https://standards.ieee.org/regauth/ethertype/eth.txt> mayalso be useful. SeeSection 3 above.¶
The IEEE Registration Authority (IEEE RA) assigns EtherTypes withoversight from the IEEE Registration Authority Committee (IEEE RAC).¶
(Seehttps://standards.ieee.org/products-programs/regauth/ethertype/.) SomeIETF protocol specifications make use of EtherTypes. All EtherTypeapplications are subject to IEEE RA technical review for consistencywith policy.¶
Since EtherTypes are a fairly scarce resource, the IEEE RAC has letus know that they will not assign a new EtherType to a new IETFprotocol specification until the IESG has approved the protocolspecification for publication as an RFC. In exceptional cases, theIEEE RA is willing to consider "early allocation" of an EtherType foran IETF protocol that is still under development as long as therequest comes from and has been vetted by the IESG.¶
To let the IEEE RAC know that the IESG has approved the request foran Ethernet assignment for an IETF protocol, all future requests forassignment of EtherTypes for IETF protocols will be made by theIESG.¶
Note that Local Experimental ("playpen") EtherTypes have beenassigned in IEEE 802 [1] use during protocol development andexperimentation.¶
[1] IEEE Std 802. IEEE standard for Local and Metropolitan Area Networks: Overview and Architecture.¶
This document obsoletes[RFC7042] and makes thechanges listed below. However, the completed application templatebased upon which an IANA OUI-based protocol number value was assignedfor document use remains that inAppendix C of [RFC7042].¶
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, andAmanda 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, andDan Romascanu¶