This article is from the Ethernet FAQ, by James Messer James@NetworkUptime.com with numerous contributions by others.
[4.1] What are the different Ethernet frame formats? (Ethernet Data Link Layer)
Ethernet Version 2 and IEEE 802.3 Frame Formats
-----------------------------------------------
The Ethernet Version 2 frame format was designed before the IEEE
specifications, but is almost identical to the 802.3 frame type.
With the Ethernet Version 2 frame type, a two-byte Type field
follows the source station's six-byte MAC address. In the 802.3
frame type, this two-byte field after the source address is a length
field specifying the number of bytes in the LLC and data fields. If
these two bytes are greater than 05DC hex (1500 decimal), the frame
is a Version 2 frame. Since all type fields are greater than 1500
decimal (the maximum Ethernet frame size), both frame types can
easily coexist on the same network. Some network protocol analyzers
call a Version 2 frame an Ethertype frame because of this two-byte
Type field.
This is an Ethernet Version 2 frame:
+--------------+ | | The preamble consists of 62 bits of alternating | Preamble | ones and zeros that allows the Ethernet card to | 7 bytes | synchronize with the beginning of a frame. | | +--------------+ The Start Frame Delimiter is the sequence | SFD - 1 byte | 10101011, and indicates the start of a frame. +--------------+ | | The destination address is a six byte Media Access | Destination | Control (MAC) address, usually burned into the | 6 bytes | ROM of the Ethernet card. +--------------+ | | The source address is a six byte MAC address, and | Source | can signify a physical station or a broadcast. | 6 bytes | +--------------+ | Type | The Type field (see explanation above). | 2 bytes | +--------------+ | | Any higher layer information is placed in the | Data | data field, which could contain protocol | | information or user data. ~ ~ ~ ~ | 46 to 1500 | | bytes | | | +--------------+ | FCS | The Frame Check Sequence is a cyclic redundancy | 4 bytes | check used by the sending and receiving stations +--------------+ to verify a successful transmission. The FCS is based on the contents of the destination address, source address, type, and data.
The 802.2 Logical Link Control (LLC) Information
------------------------------------------------
The IEEE 802.3 Ethernet specification was intended to be used with
the 802.2 Logical Link Control (LLC) specification. The LLC
information envelops the data of the frame, and the 802.3 headers
envelop this 802.2 LLC protocol data unit (PDU).
This is the frame structure for an 802.3 Ethernet frame that
contains the 802.2 LLC information:
+----------------+ | | | Preamble | | 7 bytes | | | +----------------+ | SFD - 1 byte | +----------------+ | | | Destination | | 6 bytes | +----------------+ | | | Source | | 6 bytes | +----------------+ | Frame Length | | 2 bytes | +----------------+ | DSAP - 1 byte | The Destination and Source Service Access Point +----------------+ fields determine the protocol used for the upper | SSAP - 1 byte | protocol type of the frame. +----------------+ |Control - 1 byte| The Control field is used for administration by +----------------+ certain protocols. | Data | | | ~ ~ ~ ~ | 46 to 1500 | | bytes | | | +----------------+ | FCS | | 4 bytes | +----------------+
The 802.2 Sub-Network Access Protocol (SNAP)
--------------------------------------------
After the 802.2 frame type was defined, many people felt that a
single byte for DSAP and SSAP would not be sufficient to handle the
growth of protocols into the future. A single byte DSAP or SSAP can
only specify 256 separate protocols, and many of those were
predefined from the beginning of the 802.2 specification.
To provide future growth, the Sub-Network Access Protocol (SNAP) was
created as an extension to the 802.2 specification. To differentiate
this protocol from the original 802.2 specification, 802.2 SNAP uses
the DSAP and SSAP of 0xAA.
This is an 802.2 SNAP frame encapsulated in an 802.3 frame:
+----------------+ | | | Preamble | | 7 bytes | | | +----------------+ | SFD - 1 byte | +----------------+ | | | Destination | | 6 bytes | +----------------+ | | | Source | | 6 bytes | +----------------+ | Frame Length | | 2 bytes | +----------------+ | DSAP - 1 byte | +----------------+ | SSAP - 1 byte | +----------------+ |Control - 1 byte| +----------------+ The Organizationally Unique ID (OUI) is assigned | OUI - 3 bytes | to unique vendors to help differentiate protocols | | from different manufacturers. +----------------+ | Type - 2 bytes | The two-byte protocol type defines a specific +----------------+ protocol in the SNAP. This also maintains a | | compatibility with Ethernet v2. | Data | | | ~ ~ ~ ~ | 46 to 1500 | | bytes | | | +----------------+ | FCS | | 4 bytes | +----------------+
Novell 802.3 'Raw' Frame Format
-------------------------------
Before the final 802.2 LLC specifications were finalized, Novell
implemented IPX/SPX over Ethernet. For this reason, Novell
originally utilized 802.3 Ethernet without using 802.2 LLC. Because
of this lack of LLC header, this frame type was nicknamed 802.3
'raw'. Since Novell created this proprietary frame type for their
own use, no other manufacturer uses this frame type.
To implement their 'raw' frame type, Novell used the first two bytes
of the 802.3 data field as 0xFFFF. Since the DSAP and SSAP values of
0xFF do not exist, it becomes easy to differentiate between the
802.3 and 802.3 'raw' frame types.
Encapsulation of Higher-Layer Protocols Within 802.11
Like all other 802 link layers, 802.11 can transport any network-layer protocol. Unlike Ethernet, 802.11 relies on 802.2 logical-link control (LLC) encapsulation to carry higher-level protocols. Figure 3-13 shows how 802.2 LLC encapsulation is used to carry an IP packet. In the figure, the "MAC headers" for 802.1H and RFC 1042 might be the 12 bytes of source and destination MAC address information on Ethernet or the long 802.11 MAC header from the previous section.
Two different methods can be used to encapsulate LLC data for transmission. One is described in RFC 1042, and the other in 802.1H. Both standards may go by other names. RFC 1042 is sometimes referred to asIETF encapsulation, while 802.1H is sometimes calledtunnel encapsulation.
As you can see in Figure 3-13, though, the two methods are quite similar. An Ethernet frame is shown in the top line ofFigure 3-13. It has a MAC header composed of source and destination MAC addresses, a type code, the embedded packet, and a frame check field. In the IP world, the Type code is either 0x0800 (2048 decimal) for IP itself, or 0x0806 (2054 decimal) for the Address Resolution Protocol (ARP).
Both RFC 1042 and 802.1H are derivatives of 802.2's sub-network access protocol (SNAP). The MAC addresses are copied into the beginning of the encapsulation frame, and then a SNAP header is inserted. SNAP headers begin with adestination service access point (DSAP) and asource service access point (SSAP). After the addresses, SNAP includes a Control header. Like high-level data link control (HDLC) and its progeny, the Control field is set to 0x03 to denote unnumbered information (UI), a category that maps well to the best-effort delivery of IP datagrams. The last field inserted by SNAP is an organizationally unique identifier (OUI). Initially, the IEEE hoped that the 1-byte service access points would be adequate to handle the number of network protocols, but this proved to be an overly optimistic assessment of the state of the world. As a result, SNAP copies the type code from the original Ethernet frame. The only difference between 802.1H and RFC 1042 is the OUI used.
At one point, many products offered the option to switch between the two encapsulation standards, though this option is much less common. Microsoft operating systems default to using 802.1H for the AppleTalk protocol suite and IPX, and use RFC 1042 for all other protocols. Most access points now conform to the Microsoft behavior, and no longer have an option to switch encapsulation type. In fact, the Microsoft encapsulation selection is so widely supported that it was part of the Wi-Fi Alliance's certification test suite at one point.
