Henk Smit conscientiously pointed out a major omission I made when summarizing Peter Paluch’s excellent description of how bits get parsed in network headers:

EtherType? What do you mean EtherType? There are/were 4 types of Ethernet encapsulation. Only one of them (ARPA encapsulation) has an EtherType. The other 3 encapsulations do not have an EtherType field.

What is he talking about? Time for another history lesson¹.

Ethernet started as a bit of a science project² at the center of “just good enough” mentality sometimes known as Silicon Valley. To keep things simple, it used:

• A preamble (to synchronize sender’s and receivers’ clocks)
• A start frame delimiter (to tell everyone to really start listening)
• Source and destination MAC addresses
• 2-byte field identifying higher-layer³ protocol
• Payload
• Frame Check Sequence

The 2-byte field I mentioned above is called EtherType. ARPA encapsulation is a Cisco-speak for original Ethernet encapsulation, which could also be called DIX⁴ Ethernet, or (probably most correctly) Ethernet II framing because the latest version of DIX Ethernet specification was Version 2, published in November 1982. After that, IEEE finally got their act together – it took them almost four years to “standardize” a shipping technology.

Anyway, you might have noticed there’s something missing in the above list of Ethernet frame parts – there’s no end-of-frame delimiter. How do we know we got a valid frame? Remember the “just good enough” approach? Here’s how it works:

• Original shared-medium Ethernet (10BASE5 and 10BASE2) uses Manchester coding with a transition at the middle of each bit. If there’s no transition, the sender obviously stopped sending.
• As the receiver is collecting bits into an incoming frame, it’s continuously calculating the Frame Check Sequence.
• If the receiver perceives the sender stopping at a byte boundary, and the calculated FCS matches the “verify value”, the receiver believes it got a valid frame.

That was obviously not good enough for IEEE purists⁵, but it’s hard to argue with shipping products when a competing standards body starts to standardize what you’ve been pondering for years, so they reached a “compromise”⁶:

• Ethernet will retain it’s good-enough physical layer
• IEEE version of the Ethernet will have a belt-and-braces length field after the MAC addresses to verify that the frame truly has the right length.
• EtherTypes will use values above 1500, so it will be evident whether we’re dealing with IEEE encapsulation or Ethernet II encapsulation⁷.

To be fair, there’s a better reason for the length field. Ethernet frames have a minimum length of 64 bytes⁸. Not a big deal – add padding to your protocol. Well, IBM didn’t like that argument; they wanted to keep sending SDLC/HDLC frames over LAN networks⁹.

Anyway, at that point we still had a simple decision to make:

• Is the 16-bit value after MAC addresses higher than 1536¹⁰? Must be an EtherType.
• Otherwise, it’s an IEEE 802.2 packet.

OK, but what’s riding on top of an IEEE 802.2 packet? IEEE’s first idea was to take the OSI stack and put it on top of LAN networks – every packet would have a Source Service Access Point (SSAP) and Destination Service Access Point (DSAP). Why would you need two? Would IP stack ever send a packet to OSI stack? Of course not, but that’s what you get with an academic layered approach.

There was just a bit of a hurdle: tons of companies were interested in Ethernet connectivity in those days, and all of them had proprietary protocols (just look at the reservation ranges for IANA IEEE 802 numbers), but there were only 128 available SAP numbers¹¹. In a wonderful application of RFC 1925 Rule 6a, IEEE reserved SAP value 0xAA to mean SNAP Extension which really means we just wasted 6 bytes to tell you to look at the EtherType that follows.¹²

So far we have three different Ethernet encapsulation. Hank mentioned four. Welcome to Novell IPX Raw Encapsulation SNAFU. They believed in the magic powers of IEEE (or needed a length field) but couldn’t be bothered waiting for IEEE to agree on LLC2 frame format – IPX payload directly follows the length field without any indication of what higher-layer protocol is riding in the Ethernet packet¹³.

Fortunately (for everyone else who had to parse their stupidity) IPX packet header format included a checksum as the first two bytes of the packet, and Novell never implemented a proper checksum for IPX, so every IPX packet always started with 0xFFFF¹⁴, which would be understood as global broadcast by anyone complying with 802.2 standards, but who’s counting.

Does all of this matter? Not really unless you’re an Ethernet history addict, but it resulted in a nice consulting project for my company in 1990s¹⁵.

Local experts in IBM connectivity couldn’t make an IBM AIX server talk to a Cisco router. They were also too thrifty to invest in a protocol analyzer (that thing could cost around $10K in those days) and wanted to borrow ours. In the end we agreed we’d charge them a day of consulting services, come over with the Sniffer and figure out what’s going on. It took me a few moments to realize AIX used SNAP encapsulation, and a few minutes to figure out how to configure that on Cisco routers¹⁶. Problem solved.

Just in case you’ll ever have to work with a 30-year-old IBM Unix server: the command to use is arp snap. Cisco IOS constructs layer-2 headers for individual IP next-hops from ARP entries, and the encapsulation used toward a next hop depends on the what encapsulation that next hop used in ARP request/reply. You cannot specify what encapsulation you want to use for IP, but you can specify which encapsulation(s) ARP requests will use. For some other gory details, see RFC 1042.