A Field Guide to Wireless LANs for Administrators and Power Users

The frame payload of the IEEE 802.11 MPDU must always start with an LLC sub-layer protocol header, since the IEEE 802.11 MAC sub-layer protocol header has no ability to describe the encapsulated higher layer protocol. The LLC sub-layer protocol identifies its higher layer protocol payloads using assigned Service Access Point (SAP) values. Certain higher layer protocols can be layered directly over the LLC sub-layer protocol header (e.g., Novell's Internetwork Packet Exchange (IPX), NetBEUI, etc.).

Due to the small size of the LLC SAP fields (eight bits each, of which only six bits are really usable^[19] to enumerate higher layer protocols), the LLC sub-layer protocol provides an "escape valve" by defining the IEEE 802.2 SNAP. One DSAP/SSAP value has been reserved to indicate that the five-octet SNAP header is present. Since far more than 64 protocols exist that can operate over IEEE 802 LAN technologies, the SNAP "escape valve" is absolutely necessary. The IEEE 802.2 SNAP header contains a full two-octet Type field, with values used exactly as in Ethernet's Type field. The presence of the five-octet SNAP header is indicated by setting the LLC header's Destination SAP (DSAP) and Source SAP (SSAP) fields to the reserved SAP value of 0xAA.

^[19] To be precise, because the SAP values are structured, not even a full eight bits are available to enumerate higher layer protocols. There is actually a maximum of 64 unique SAP values, rather than the full 256 that one might expect to be supported in an 8-bit field.

The MTU, and thus the payload capacity, of IEEE 802.11 MPDUs is considerably larger than that of Ethernet, which can "only" send 1500 octets of payload at a time.^[20] Either TCP's Maximum Segment Size (MSS) negotiation or Path MTU Discovery will allow wireless stations to send frames to Ethernet-attached stations, without placing an undue packet-level fragmentation and reassembly burden on the AP (even if this were a good idea, which it is not, the purported "IP fragmentation-aware AP" could only be used with Network layer protocols that naturally support packet-level fragmentation through native header structures; an example of such a protocol is IPv4; IPv6 is not such a protocol…).

^[20] In the case of IEEE 802.3, the MTU would be 1492 octets since the higher layer protocol payload must be reduced by eight octets to allow for the eight octets that were consumed by the LLC and SNAP sub-layer headers. The IEEE 802.3 MTU is further reduced to 1488 octets when the IEEE 802.1Q TCIH is present (in addition to the LLC/SNAP headers).

In many early IEEE 802.11 drivers, the interface that the IP stack saw looked a lot like Ethernet (because the OS's IP stack only knew how to talk to an Ethernet-style driver). As a result, most IEEE 802.11 LANs have MPDUs with reduced maximum payload sizes of 1500 octets (including a 1492-octet IP packet, and eight octets of LLC and SNAP headers). Regardless of how large a Data Link layer header set is added here, the total length will still be well less than the maximum IEEE 802.11 MPDU size of 2346 octets.

A "native" driver, in order to be safe, might still want to allow for all possible Data Link header combinations, by limiting the IP packet size to 2250 octets. This size would allow any of the Data Link protocol stacks to be pre-pended to the IP packet, and still remain under the 2346-octet MPDU size limit.

Table 4-1 gives a comparison of the "vital statistics" for IEEE 802.3 versus 802.11 MAC sub-layer framing comparing the MAC sub-layer protocols without the other elements of the Data Link layer stack that might be present.

Table 4-1 may appear to be a bit of an apples-to-oranges comparison, but IEEE 802.3 is not the same as Ethernet, despite their names being used interchangeably in many contexts. Contrary to the case of Ethernet, IEEE 802.3 is a pure^[21] MAC sub-layer protocol, because it also depends on the higher LLC sub-layer's protocol(s) for medium-independent frame control and demultiplexing functions.

^[21] The IEEE 802.3 specification does still permit the "Type" form of "classic Ethernet," even though it does not strictly adhere to the IEEE 802 MAC/LLC abstract sub-layer model.

The IEEE 802.3 form of Ethernet header has no Type field, just as the IEEE 802.11 header lacks a Type field. In a 14-octet IEEE 802.3 frame header, the MAC sub-layer addresses consume 12 octets, and the remaining two octets consist of a "Length" field.

Encapsulation of IP over Ethernet and IEEE 802.11

Although a unique IEEE 802.2 LLC SAP value was assigned to IPv4, IPv4 is rarely (if ever) seen transmitted directly over the IEEE 802.2 LLC sub-layer protocol the recommended practice for transmitting IPv4 and ARP over IEEE 802 LANs is to encapsulate them in both IEEE 802.2 LLC and SNAP, with the OUI in the latter set to 0x000000, and the SNAP Type field set to 0x0800 for IPv4 and 0x0806 for ARP (or 0x86DD for IPv6).

While it is possible to transmit "IPv4 over 'raw' LLC" packets on FDDI or Token Ring LANs, that practice violates RFC-1042, which has been a full Internet Standard for a very long time now. However, note that it is possible for other protocols, such as IPX, NetBEUI, OSI, and others, to be layered directly over LLC without using SNAP. Finally, note that there is no LLC SAP value for IPv6, which also must be encapsulated over non-Ethernet (i.e., IEEE 802) LANs in LLC and SNAP headers.