Summary

  • The IEEE Registration Authority assigns EtherTypes and LSAPs; it also assigned OUI 00-00-5E to IANA, which administers a narrower subspace beneath that prefix.
  • A two-octet protocol number after the IANA OUI is not an EtherType. The carrier, OUI and inner value must remain together before an assignment claim can be made.
  • RFC 9542 turns the distinction into an operational discipline: preserve byte position, namespace, authoritative registry, approval path, specification and implementation as separate receipts.

The packet capture looked simple. After the MAC addresses came 88-B7, then 00-00-5E, then 00-42. A hurried incident note called the last pair “EtherType 0042,” looked it up on an IANA page and concluded that IANA had assigned the type.

Every part of that sentence was plausible. Almost every part was wrong.

0x88B7 is the EtherType. It is the OUI Extended EtherType assigned through the IEEE Registration Authority. 00-00-5E is the Organizationally Unique Identifier that IEEE assigned to IANA. 0x0042 is a protocol number inside IANA's OUI and is reserved for documentation. The two octets do identify something, but their meaning comes from the five-octet identifier that contains them. Removing the three bytes before them removes the namespace owner.

RFC 9542 is a Best Current Practice about this kind of boundary. Published as BCP 141 in April 2024, it replaced RFC 7042 without creating a new registry or changing an existing assignment. Its deeper value is not another table of numbers. It is a map of who may assign which number, under which delegation, and what a displayed registry can honestly prove.

The first question is not what the value means

The first question is where the value sits.

In an ordinary Ethernet II frame, a sixteen-bit value at or above 0x0600 may be an EtherType immediately after the source and destination addresses, subject to intervening tags. IEEE RA assigns that number. In IEEE 802 LLC, a length field is followed by paired link-layer service access points. The SNAP form then uses AA-AA-03, a three-octet OUI and a two-octet protocol number. The OUI owner assigns that trailing number.

A third form begins with EtherType 0x88B7. It then carries an OUI and a two-octet protocol number. With IANA's OUI, the bytes are:

88-B7-00-00-5E-qq-qq

The outer field and inner field can both be sixteen bits. That visual symmetry is not an authority relationship. IEEE assigned the carrier; IEEE delegated one OUI to IANA; IANA assigns values inside its delegated subspace. The assignment chain is nested, not interchangeable.

SNAP adds one more trap. An all-zero OUI followed by two octets means that the trailing value is an arbitrary EtherType. Replace the zeros with 00-00-5E, and the same two-byte position is now a protocol number controlled by IANA. A parser that stores only qq-qq cannot later recover which claim was valid.

A website is not automatically the authority

IANA publishes two relevant registry groups. “IANA OUI Ethernet Numbers” contains the assignments IANA makes under 00-00-5E. Its SNAP registry records protocol number 0x0042 for documentation and reserves the edge values. That is an IANA assignment ledger.

IANA also hosts “IEEE 802 Numbers.” Its EtherType section says that EtherTypes are not assigned by IANA. It calls the displayed list contributed, unverified information and points readers to IEEE RA. The page remains useful for discovery and history. It does not become the originating authority because it is served from an IANA hostname.

This distinction matters in automation. A collector that treats every table on iana.org as an IANA allocation can manufacture false provenance at scale. A compliance report can be internally consistent, cryptographically signed and still answer the wrong institutional question. The source URL proves where the copy was found. The registry's declared responsibility proves what the copy is allowed to say.

The review rule reveals the purpose of the namespace

IANA cannot place any convenient protocol into the two-octet space under its OUI. RFC 9542 requires standards use, documentation in an Internet-Draft or RFC, and a version field at a fixed offset or an equivalent marker that older versions can recognize. Ordinary requests receive Expert Review. The extreme values 0x0000 and 0xFFFF require IESG Ratification.

The rule also refuses duplication. A protocol that already has an EtherType must not receive an IANA-OUI protocol number for the same purpose. It can use its EtherType directly or carry that EtherType after the all-zero OUI in SNAP. The refusal is not bureaucratic tidiness. It prevents two authority paths from appearing to certify the same identifier while accumulating different histories.

The same economy appears in address assignments under the IANA OUI. Blocks must serve standards purposes, follow power-of-two alignment and must not be used to evade the requirement that interface vendors obtain their own IEEE blocks. Delegation gives IANA room to coordinate IETF needs. It does not turn the delegated prefix into a substitute IEEE Registration Authority.

Documentation is not experimentation

The hexadecimal value 42 is memorable, but its policy changes with its namespace. Under the IANA OUI, protocol number 0x0042 is for documentation examples. For other one-octet organizationally specific parameters under the same OUI, 0x42 is also the designated example value. Those reservations let specifications show concrete bytes without colliding with deployed allocations.

IEEE, by contrast, designates EtherTypes 0x88B5 and 0x88B6 for local experimental use. These are free-standing EtherTypes in a different registry with a different purpose. Calling 00-00-5E-00-42 an experimental EtherType combines a documentation reservation, an OUI subspace and an IEEE type category into a single false label.

That error can escape the lab. Example packets can be copied into test harnesses, firewall rules or dissector fixtures and then treated as a provisional production allocation. Local experimental EtherTypes can be allowed beyond their intended domain. The correction is not to ban examples or experiments. It is to carry their scope with the value.

The evidence chain is longer than the registry row

A complete identifier receipt begins with the captured bytes and their offsets. It records tags and frame length so that the interpreter knows whether it is looking at an EtherType, an LLC field or an inner protocol number. It preserves the OUI, not just the last two octets. It names the authoritative registry and saves the assignment's effective record.

Then the chain changes character. The governing specification explains how an implementation should parse the identifier. Software inventory, version and configuration show what a named device actually did. Packet evidence shows what crossed one observation point. Endpoint evidence shows whether the intended action occurred. A registry entry cannot replace those later receipts.

That separation prevents a subtle form of mandate laundering. A registration authority can establish uniqueness in a namespace. It cannot certify that every implementation recognizes the value, that a frame contained the claimed payload, or that an application accepted it. Coordination is strongest when it refuses to impersonate execution.

What should appear in an operational record

For every unknown or controlled Ethernet identifier, retain the outer carrier, the full OUI-based value, the registry owner, the registry URL and snapshot date, the policy class, the specification and the parser result. If the field came from a capture, retain the exact bytes and offsets. If a system took action, retain the rule version and outcome separately.

This makes disagreements diagnosable. IEEE RA may show a current EtherType assignment while an informational IANA mirror is stale. IANA may show a valid sub-assignment under 00-00-5E while a dissector flattens it into an EtherType label. A vendor may parse a reserved documentation value in production. None of these conditions is solved by choosing the most convenient table. Each is solved by preserving the authority edge that generated the claim.

RFC 9542 is therefore not merely about numbers. It is about keeping coordination thin. The field is real, the registry is real and the delegation is real. Their mandates remain bounded. When the full identifier survives, the boundary is visible. When the prefix disappears, institutional authority can be invented from two innocent octets.

Sources