Oh SNAP! There is more to Wi-Fi ↔︎ Ethernet than I thought

▼ The tag line for World IPv6 Launch ten years ago was "the future is forever". You know what else seems to be forever? The past. Let's talk about IEEE 802 LLC/SNAP encapsulation.

I always thought when you send IP packets over Wi-Fi, the IP packet would go inside an Ethernet frame, and then the Ethernet frame inside an 802.11 frame. Turns out this is not how it works: there is no Ethernet header inside IEEE 802.11 packets/frames¹.

What actually happens is that packets are bridged between Ethernet and Wi-Fi. Surprising. But the real shock is that the bridging between Ethernet and Wi-Fi is exactly the same as bridging between Ethernet and FDDI. (An old 100 Mbps fiber ring technology from when Ethernet was still stuck at 10 Mbps.) It's all laid out in this ancient RFC from 1988: RFC 1042.

Bridging is the process of translating one OSI layer 2 frame format to another. In this case, a Wi-Fi access point translates between the Wi-Fi 802.11 header and the Ethernet II header.

Most of the stuff in a Wi-Fi header or Ethernet header is only relevant on the Wi-Fi and Ethernet drivers, respectively. But higher layers in the networking stack do need to interact with two things from the Ethernet header: the MAC addresses and the ethertype. So bridging between two network protocols is possible if the MAC addresses and ethertype are compatible.

Which creates a bit of a problem, as the 802.x family, including 802.11, doesn't do ethertypes. So how do they make sure different packets, such as IP, ARP, IPX, AppleTalk, Wake-on-LAN, et cetera are interpreted correctly by the receiver? Their first try was the LLC header. But that didn't accommodate a sufficiently large number of possible protocols. So add to LLC the SNAP header. The ethertype goes inside the SNAP header. So now we have all the information we need to translate between 802.x protocols (such as 802.11 Wi-Fi) and Ethernet II. The slide below that I copied from this presentation shows how that works:

(Where DEST and SRC are the MAC addresses, type is the ethertype, and AA AA 03 00.00.00 are the values in the LLC and SNAP headers preceding the ethertype. P is the IP packet. Also see the last image here for an actual packet dump.)

But wait... isn't Ethernet IEEE 802.3, so shouldn't it use LLC/SNAP, too?

Well, kinda-sorta-but-not-really. Remember that Ethernet was developed by the DIX consortium (DEC, Intel, Xerox) and then handed off to the IEEE for further tinkering and standardization. As a result, there is a difference between the old Ethernet II header, which has the ethertype, and the 802.3 header, where the same place in the header is actually a length field. (Which we don't need, the Ethernet hardware can tell how long packets are just fine by itself.)

So for IP over actual IEEE 802.3 you need at least the LLC header (which supports IPv4 and ARP) but in practice IP over 802.x always uses LLC+SNAP.

So IP over Ethernet II is actually a relic from the past. But still quite alive. Novell did move to LLC and SNAP, but this just meant that there were now four different frame formats to choose from in your IPX network, and having four incompatible ways to do the exact same thing is never helpful when running a network.

¹ Remember, OSI layer 2 has frames, OSI layer 3 packets and OSI layer 4 segments. So the TCP segment goes inside an IP packet and the IP packet inside an Ethernet frame, each layer adding a header and sometimes a trailer with information relevant to that layer.

Permalink - posted 2022-07-21