Ethernet frame analysis (Ethernet II, Ethernet 802.3 raw, IEEE 802.3, Ethernet IEEE 802.3 SNAP)

Keywords: Network Protocol Ethernet TCP/IP

The data link layer (layer 2) of OSI model is actually composed of two sublayers: media access control (MAC) sublayer and logical link control (LLC) sublayer. MAC sublayer controls device interaction. The LLC sublayer handles addressing and multiplexing.

The physical addressing of the network connection exists at the data link layer. The protocol unit transmitted at the data link layer is called a frame. The data link layer combines data bits into entities called frames. Network topologies such as Ethernet exist in the data link layer. Network switch is the most common network equipment in data link layer.

Ethernet frame overview

In Ethernet, devices share data using packets. They contain, among other things, Ethernet frames, which are divided into multiple data sets. These records consist of binary codes that provide important information, such as address, control information, payload data, and checksum.

According to the Ethernet standard, Ethernet frames have different structures and may contain more or fewer data fields, depending on the network protocol.

Although the IEEE 802.3 standard claims to replace Ethernet II, due to their similarity and the fact that Ethernet II is the basis of IEEE 802.3, they are usually regarded as Ethernet.

What are the types of Ethernet frames

At present, there are four types of Ethernet frame formats:

  • Ethernet II

DIX 2.0, the Ethernet standard frame format formulated by Xerox, DEC and Intel in 1982, has become the de facto Ethernet frame standard.

  • RAW 802.3

Dedicated Ethernet standard frame format published by Novell in 1983. The format is based on the 802.3 standard that has not been officially released at that time, and is not compatible with the 802.3 standard officially released by IEEE later. It only supports IPX/SPX protocol and can only be used in IPX network.

  • IEEE 802.3/802.2 LLC

This is the 802.3 standard officially released by IEEE in 1985 and developed from Ethernet V2

  • IEEE 802.3/802.2 SNAP

This is a standard issued by IEEE in 1985 to ensure that more upper layer protocols are supported on 802.2 LLC and better support IP protocols

Ethernet frame length and MTU

The minimum Ethernet frame length is 64 bytes. The maximum Ethernet frame length is 1518 bytes. The driver shall ensure that the frame meets the requirements of the minimum frame length specification. If a frame cannot meet the requirements of the minimum frame length of 64 bytes, the driver must fill in the corresponding data field.

Ethernet II and IEEE 802.3/802.2 SNAP have a limit on the length of data packets to be transmitted, and their maximum values are 1500 and 1492 bytes respectively.

This feature of the link layer is called the maximum transmission unit (MTU). Most networks of different types have an upper limit. If the IP layer has a datagram to transmit and the data length is larger than the MTU of the link layer, the IP layer needs to divide the datagram into several pieces so that each piece is smaller than the MTU.

When transmitting data through Ethernet, Ethernet frame is mainly responsible for correctly formulating rules and successfully transmitting data packets. In essence, data sent over Ethernet is carried by frames. The size of Ethernet frame is between 64 bytes and 1518 bytes, depending on the size of data to be transmitted.

Ethernet II frame format

In the OSI model, the frame is located in the data link layer, which is responsible for error free transmission and dividing the bit stream into blocks.

Ethernet II frame is relatively simple and consists of the following five fields:

Destination address: it is 6 bytes long and specifies the data link address of the destination host.
Source address: it is 6 bytes long and specifies the hardware address of the sender. This field only contains unicast addresses, not broadcast or multicast addresses.
Type: the length is 2 bytes, indicating that the frame type protocol is being used. This is the assigned protocol Ethernet type number managed by IANA.

const value_string etype_vals[] = {
	{ 0x0800,                   "IPv4" },
	{ 0x86DD,                 "IPv6" },
	{ 0x8100,                 "802.1Q Virtual LAN" },
	{ 0x0806,                  "ARP" },
	{ 0x872D,                "Cisco Wireless Lan Context Control Protocol" },
	{ 0x8783,                 "Motorola Media Independent Network Transport" },
	{ 0x2452,     "IEEE 802.11 (Centrino promiscuous)" },
	{ 0x0600,              "XNS Internet Datagram Protocol" },
	{ 0x0805,                "X.25 Layer 3" },
	{ 0x0842,                  "Wake on LAN" },
	{ 0x08F0,              "WiMax Mac-to-Mac" },
	{ 0x3E3F,               "EPL_V1" },
	{ 0x8035,               "RARP" },
	{ 0x8038,               "DEC LanBridge" },
	{ 0x809B,                "AppleTalk LLAP bridging" },
	{ 0x80D5,                  "SNA-over-Ethernet" },
	{ 0x80E1,                  "EtherNet/IP Device Level Ring" },
	{ 0x80F3,                 "AARP" },
	{ 0x8137,                  "Netware IPX/SPX" },
	{ 0x0BAD,             "Vines IP" },
	{ 0x0BAF,           "Vines Echo" },
	{ 0x1984,                "Netmon Train" },
	/* Ethernet Loopback */
	{ 0x9000,                 "Loopback" },
	{ 0x885A,              "Foundry proprietary" },
	{ 0x80FF,                  "Wellfleet Compression Protocol" },
	{ 0x8181,                  "Spanning Tree Protocol" },
	/* for ISMP, see RFC 2641, RFC 2642, RFC 2643 */
	{ 0x81FD,                 "Cabletron Interswitch Message Protocol" },
	{ 0x81FF,         "Cabletron SFVLAN 1.8 Tag-Based Flood" },
	/* In, 8203-8205 description is
	 * Quantum Software.  Now the company is called QNX Software Systems. */
	{ 0x8204,            "QNX 6 QNET protocol" },
	{ 0x8863,               "PPPoE Discovery" },
	{ 0x8864,               "PPPoE Session" },
	{ 0x886C,             "HomePNA, wlan link local tunnel" },
	{ 0x886D,            "Intel ANS probe" },
	{ 0x886F,     "MS NLB heartbeat" },
	{ 0x8870,            "Jumbo LLC" },
	{ 0x8874,            "Broadcom tag" },
	{ 0x887B,             "Homeplug" },
	{ 0x88E1,          "Homeplug AV" },
	{ 0x88E3,                  "MRP" },
	{ 0x88A8,         "802.1ad Provider Bridge (Q-in-Q)" },
	{ 0x88E5,               "802.1AE (MACsec)" },
	{ 0x893A,            "1905.1a Convergent Digital Home Network for Heterogenous Technologies" },
	{ 0x88E7,         "802.1ah Provider Backbone Bridge (mac-in-mac)" },
	{ 0x893F,         "802.1br Bridge Port Extension E-Tag" },
	{ 0x888E,                "802.1X Authentication" },
	{ 0x88C7,          "802.11i Pre-Authentication" },
	{ 0x8847,                 "MPLS label switched packet" },
	{ 0x8848,           "MPLS multicast label switched packet" },
	{ 0x3C07,         "3Com NBP Datagram" },
	{ 0x6000,                  "DEC proto" },
	{ 0x6001,               "DEC DNA Dump/Load" },
	{ 0x6002,               "DEC DNA Remote Console" },
	{ 0x6003,               "DEC DNA Routing" },
	{ 0x6004,                  "DEC LAT" },
	{ 0x6005,             "DEC Diagnostics" },
	{ 0x6006,             "DEC Customer use" },
	{ 0x6007,              "DEC LAVC/SCA" },
	{ 0x8041,             "DEC LAST" },
	{ 0x6558,            "Transparent Ethernet bridging" },
	{ 0x2001,                 "Cisco Group Management Protocol" },
	{ 0x22E5,              "Gigamon Header" },
	{ 0x22EA,                 "802.1Qat Multiple Stream Reservation Protocol" },
	{ 0x88F6,                 "802.1ak Multiple Mac Registration Protocol" },
	{ 0x894F,                  "Network Service Header" },
	{ 0x8988,          "PA HB Backup" },
	{ 0x22F0,                "IEEE 1722 Audio Video Bridging Transport Protocol" },
	{ 0x22F1,                 "Robust Header Compression(RoHC)" },
	{ 0x22F3,                "Transparent Interconnection of Lots of Links" },
	{ 0x22F4,               "Intermediate System to Intermediate System" },
	{ 0x8808,          "MAC Control" },
	{ 0x8809,       "Slow Protocols" },
	{ 0x9021,                "Real-Time Media Access Control" },
	{ 0x9022,                "Real-Time Configuration Protocol" },
	{ 0x8881,     "CDMA2000 A10 Unstructured byte stream" },
	{ 0x8884,                "ATM over Ethernet" },
	{ 0x8892,             "PROFINET" },
	{ 0x8899,              "Realtek Layer 2 Protocols" },
	{ 0x88A2,                  "ATA over Ethernet" },
	{ 0x88A4,                "EtherCAT frame" },
	{ 0x88A1,             "Telkonet powerline" },
	{ 0x88AB,               "ETHERNET Powerlink v2" },
	{ 0x88AD,               "XiMeta Technology" },
	{ 0x889B,           "CSM_ENCAPS Protocol" },
	{ 0x88B5,    "Local Experimental Ethertype 1" },
	{ 0x88B6,    "Local Experimental Ethertype 2" },
	{ 0x88B7, "IEEE 802a OUI Extended Ethertype" },
	{ 0x88B8,       "IEC 61850/GOOSE" },
	{ 0x88B9,         "IEC 61850/GSE management services" },
	{ 0x88BA,          "IEC 61850/SV (Sampled Value Transmission" },
	{ 0x88CA,                 "Transparent Inter Process Communication" },
	{ 0x88CC,                 "802.1 Link Layer Discovery Protocol (LLDP)" },
	{ 0x88D2,                "CDMA2000 A10 3GPP2 Packet" },
	{ 0x891D,              "TTEthernet Protocol Control Frame" },
	{ 0x88D8,              "Circuit Emulation Services over Ethernet (MEF8)" },
	{ 0x88D9,                 "Link Layer Topology Discovery (LLTD)" },
	{ 0x88DC,                 "(WAVE) Short Message Protocol (WSM)" },
	{ 0x88DE,                "VMware Lab Manager" },
	{ 0x8819,             "Cirrus Cobranet Packet" },
	{ 0x8133,                 "Juniper Netscreen Redundant Protocol" },
	{ 0x9104,                 "EERO Broadcast Packet" },
	 * NDISWAN on Windows translates Ethernet frames from higher-level
	 * protocols into PPP frames to hand to the PPP driver, and translates
	 * PPP frames from the PPP driver to hand to the higher-level protocols.
	 * Apparently the PPP driver, on at least some versions of Windows,
	 * passes frames for internal-to-PPP protocols up through NDISWAN;
	 * the protocol type field appears to be passed through unchanged
	 * (unlike what's done with, for example, the protocol type field
	 * for IP, which is mapped from its PPP value to its Ethernet value).
	 * This means that we may see, on Ethernet captures, frames for
	 * protocols internal to PPP, so we list as "Ethernet" protocol
	 * types the PPP protocol types we've seen.
	{ 0x8021,                       "PPP IP Control Protocol" },
	{ 0xc021,                        "PPP Link Control Protocol" },
	{ 0xc023,                        "PPP Password Authentication Protocol" },
	{ 0x80fd,                        "PPP Compression Control Protocol" },
	{ 0xCAFE,                  "Veritas Low Latency Transport (not officially registered)" },
	{ 0x8902,                  "IEEE 802.1ag Connectivity Fault Management (CFM) protocol" },
	{ 0x8903,                  "Data Center Ethernet (DCE) protocol(Cisco)" },
	{ 0x8906,                 "Fibre Channel over Ethernet" },
	{ 0x890d, "IEEE 802.11 data encapsulation" },
	{ 0x8911,                 "LINX IPC Protocol" },
	{ 0x8914,                  "FCoE Initialization Protocol" },
	{ 0x8917,                  "Media Independent Handover Protocol" },
	{ 0x88EE,                 "Ethernet Local Management Interface (MEF16)" },
	{ 0x88F7,                  "PTPv2 over Ethernet (IEEE1588)" },
	{ 0x88F8,                 "Network Controller Sideband Interface" },
	{ 0x88FB,                  "Parallel Redundancy Protocol (PRP) and HSR Supervision (IEC62439 Part 3)" },
	{ 0x8901,                 "Flow Layer Internal Protocol" },
	{ 0x8915,                 "RDMA over Converged Ethernet" },
	{ 0xD00D,                "Digium TDM over Ethernet Protocol" },
	{ 0x88B4,                  "WAI Authentication Protocol" },
	{ 0x8926,                "VN-Tag" },
	{ 0x892B,               "Schweitzer Engineering Labs Layer 2 Protocol" },
	{ 0x892F,                  "High-availability Seamless Redundancy (IEC62439 Part 3)" },
	{ 0x08FF,                  "AX.25" },
	{ 0x8909,                  "CiscoMetaData" },
	{ 0x8947,        "GeoNetworking" },
	{ 0xC0DE,                  "eXpressive Internet Protocol" },
	{ 0xC0DF,                  "Neighborhood Watch Protocol" },
	{ 0x892D,              "bluecom Protocol" },
	{ 0x9100,             "QinQ: old non-standard 802.1ad" },
	{ 0x99FE,                "Technically Enhanced Capture Module Protocol (TECMP)" },
	{ 0xA0ED,              "6LoWPAN" },
	{ 0xD28B,                 "Arista Timestamp" },
	{ 0xAEFE,                "eCPRI" },
	{ 0xB4E3,            "CableLabs Layer-3 Protocol" },
	{ 0xFFF2,             "Cisco ACI ARP gleaning" },
	{ 0xF1C1,         "802.1CB Frame Replication and Elimination for Reliability" },
	{ 0, NULL }

Ethernet type is an important field in Ethernet frame, which is used to indicate the protocol applied to the frame data segment, that is, the upper layer protocol type to be encapsulated.
Data: store encapsulated upper layer data, with a length between 46 bytes and 1500 bytes.
Frame Check Sequence: referred to as FCS for short, with a length of 4 bytes, including the results of CRC calculation.

Ethernet 802.3 raw frame format

Ethernet 802.3 raw, also known as Novell Ethernet, turns the type field in the header of Ethernet II frame into a length field, which is then used to identify Novell Ethernet type with a hexadecimal number 0xFFFF field, and the data field is reduced to 44 ~ 1498 bytes.

This rough version of 802.3 packet, named "Ethernet 802.3", was proposed by Novell before the IEEE 802.3 standard and the popular IPX/SPX protocol were widely established. Unfortunately, it is often confused with IEEE standard. Therefore, Novell added "raw" to the name.

Ethernet IEEE 802.3

Ethernet IEEE 802.3 is the most popular and widely used LAN frame structure. However, some networks and protocols require more space to store specific information. Therefore, there are variants of IEEE 802.3 frames that provide additional data blocks for specific information, including SNAP extensions and VLAN tagging.

Destination Service Access Point: referred to as DSAP, it is used to identify the destination protocol. For example, the hexadecimal number 0x06 represents IP protocol data, and the hexadecimal number 0xE0 represents Novell type protocol data.
Source Service Access Point: referred to as SSAP, it is used to specify the source protocol (usually the same as the destination protocol)
Control: indicates whether the frame is in no number format or information / supervision format, which is generally set to 0x03. Indicates that the connectionless service 802.2 unnumbered data format is adopted.

Ethernet IEEE 802.3 SNAP

The biggest difference between Ethernet IEEE 802.3 SNAP frame format and the above 802.3 frame is the addition of a 5-byte SNAP ID. In addition, the contents of these two bytes DSAP and SSAP fields are fixed, and their values are 0xAA. The content of the control field is also fixed and saved, and its value is hexadecimal 0x03


For the four existing Ethernet frame formats, the network equipment identifies the Ethernet II frame according to the above provisions. If the value of two bytes (length and type fields) behind the source address at the head of the frame is greater than 1500, the frame format is Ethernet II format. Otherwise, it is in another format.

Next, we are distinguishing the other three formats. If the length field and type field are 0xFFFF, they are Novell Ether(Ethernet 802.3 raw) frames, if the value is 0xAAAA, they are Ethernet IEEE 802.3 SNAP, and the rest are IEEE 802.3 frames.

Welcome to WeChat official account encoding program. Welcome to add c17865354792 to exchange learning.

Reference: RFC 894, RFC 1042

Posted by austenr on Tue, 21 Sep 2021 16:48:31 -0700