Summary

  • RFC 1089 let a standard SNMP message travel directly in the data field of an Ethernet frame identified by EtherType decimal 33100, hexadecimal 0x814C. A repeater or wiring concentrator could therefore be managed without implementing IP and UDP.
  • RFC 4789 later retained the type code and made the operating boundary explicit: the optional mapping reaches only one logical IEEE 802 LAN, bridged LAN or VLAN, and only one SNMP engine can be addressed on a given interface.
  • A MAC address locates the transport endpoint. It does not authenticate a principal, grant access to a MIB view or prove that a SET changed the physical device. SNMP security, access control and outcome evidence remain separate.

The equipment was on the wire but not in the Internet

An Ethernet repeater could affect every packet on a segment. A wiring concentrator could become the common physical point for many hosts. In 1989, such equipment increasingly contained programmable intelligence and a MAC address, yet it might carry no Internet protocol above the MAC sublayer. From an IP management station, the device was important and invisible at the same time.

RFC 1089 treated that mismatch as a transport problem. SNMP had been designed around addressability and bidirectional message flow, not around an irrevocable attachment to UDP/IP. If the network element already lived on the same Ethernet, the management message could be delivered in a frame without asking the element to become an IP host first.

The proposal was deliberately experimental. It did not redesign the MIB, add new management operations or define a universal management network. It took the SNMP message already specified at the time and changed the envelope beneath it.

That narrowness is the historical contribution. A management protocol could preserve the meaning of its request while changing the carrier. The benefit and the limitation both came from the same subtraction.

One frame replaced an upper stack

The wire rule in RFC 1089 fit into a few lines. Xerox assigned Ethernet Type 33100, hexadecimal 814C, for SNMP. The Ethernet data field then contained a standard SNMP message. There was no IP header between the Ethernet frame and that message and no UDP port selecting the agent.

This was not a compressed IP packet. The MAC destination selected the interface, and the type field selected the payload grammar. The device could decode ASN.1/BER and implement the SNMP agent without also implementing IP addressing, routing, fragmentation and UDP demultiplexing for this path.

RFC 1157 explains why the arrangement fitted SNMP’s philosophy. The architecture tried to minimize the functions and complexity inside a managed agent. Each message was independently represented, and although the specification used UDP, its mechanisms were described as suitable for varied transport services. Direct Ethernet was one concrete test of that separation.

Removing headers did not remove state everywhere. A manager still needed to know which MAC destination represented the device, which logical LAN contained it, which SNMP version and security parameters to use, and how to correlate a reply with the request. Simplicity inside the element transferred discovery and boundary knowledge to the operator.

0x814C named a grammar, not a principal

EtherType answered one exact parsing question: what protocol should receive the bytes that follow the Ethernet header? It prevented an SNMP message from being mistaken for an IP datagram or another link payload.

It did not answer who sent the message. It did not say which organization controlled the source interface, whether the request belonged to a permitted operator, which MIB objects the sender might read or alter, or whether a requested change was safe. A correct type value is evidence about serialization, not a credential.

The same distinction applies to the destination MAC address. It is useful because the frame must reach an interface. In the later transport-domain model, it becomes the transport address associated with the IEEE 802 mapping. But an address is not a mandate. Delivering bytes to an endpoint does not authorize the operation described by those bytes.

That difference is easy to lose when the path is physically local. “Only on this LAN” can sound like a trust policy. The RFC record does not make it one. Locality narrows who can reach the channel under a particular topology; it does not define the principals entitled to use it.

The 2006 revision drew the island

Seventeen years later, RFC 4789 obsoleted the experimental memo with a standards-track mapping for IEEE 802 networks. It kept the essential decision: serialize the SNMP message and carry it in the MAC-frame data field under EtherType 0x814C.

The revision also dealt with the wider 802 family. Where a LAN used LLC for protocol identification, including the case it gave for 802.11, the mapping used SNAP encapsulation. The exact link envelope could vary while the assigned Ethernet type and serialized SNMP message remained recognizable.

More importantly, the document stated the reach boundary. Direct SNMP over IEEE 802 is restricted to a single logical IEEE 802 LAN, bridged LAN or VLAN. A bridge can extend the local domain. A router does not turn the frame into a general Internet path. A VLAN reconfiguration can therefore change management reach even when the device and its MAC address have not moved.

This was a genuine design trade. A simple element could be managed below IP, but the manager had to share the relevant logical LAN or reach it through an explicitly controlled local bridge. The mapping did not compete with routed management on distance. It solved a different admission problem: how little stack could a directly attached element need?

A shared interface had one engine-shaped aperture

RFC 4789 added another limit that UDP ports would otherwise obscure. Only one SNMP engine can be addressed on a given IEEE 802 network interface. Command generators and notification receivers share the endpoint with command responders and notification originators.

Under UDP, port and address combinations help distinguish listening roles. The direct mapping had a MAC address and a protocol type, but no transport port. The specification consequently compressed the roles into one interface destination.

That does not mean every message has the same function. SNMP’s message processing still distinguishes requests, responses and notifications. It means the link-layer envelope cannot choose among multiple engines behind the same interface. If an implementation needs internal demultiplexing, that is its private arrangement, not a second standardized endpoint exposed by the mapping.

The size contract was also explicit. An entity had to accept messages through 484 octets and was recommended to accept through 1472 octets, with larger values encouraged. RFC 3417 used the same receive thresholds for SNMP transport mappings and made UDP over IPv4 the preferred mapping for IPv4 systems. Direct IEEE 802 stayed optional; it did not erase the interoperability value of the ordinary IP path.

Transport domains kept coordinates honest

The later SNMP framework needed generic MIB modules to refer to endpoints without assuming every endpoint was IPv4 plus a UDP port. RFC 4789 therefore registered snmpIeee802Domain. Its corresponding transport address is a MacAddress.

The pair is more informative than an unqualified byte string. The domain says how to interpret the address. Six octets under an IEEE 802 domain are not silently converted into an IP address, a user name or a globally routed service. The coordinate remains scoped to the transport that gives it meaning.

That discipline matters in logs and configuration. Recording only a MAC value loses which VLAN or bridged LAN made it reachable. Recording only an SNMP engine identifier loses which interface carried it. Recording only a user name loses the transport observation. Each identifier answers a different question and needs its own lifetime.

Security began after the frame arrived

RFC 4789 did not treat physical adjacency as protection. Its security section says SNMPv1 and SNMPv2c messages are not considered secure and recommends SNMPv3’s User-based Security Model and View-based Access Control Model.

RFC 3414 supplies the machinery for authenticated and timely SNMPv3 messages and, where selected, privacy. RFC 3415 asks a different question: may this security name, under this model and context, perform this operation on this MIB view?

Neither decision belongs to EtherType. The link layer delivers a candidate message. The security model evaluates its protection and principal. Access control evaluates the requested object and operation. The instrumentation then decides what a permitted operation means for the device.

A response is also bounded evidence. It can show that an SNMP engine processed a request and returned a value or status under the applicable model. It does not by itself prove that a relay changed state, that packets followed a new path, or that the effect persisted after restart. Those claims require a later read, an independent counter, a physical observation or another outcome-specific signal.

The small 1989 experiment therefore exposed a large rule. Lowering the transport requirement can widen the set of manageable equipment while narrowing the scope of the management channel. Reachability, message authenticity, permission and effect do not collapse merely because fewer protocol layers sit between them.

Sources