Following the 12 bytes of MAC addresses, the Ethernet frame contains a 2-byte (16-bit) field that serves a crucial function: it tells the receiver either what protocol is encapsulated within the payload (in Ethernet II framing) or how long the payload is (in IEEE 802.3 framing).

This dual interpretation arises from the historical coexistence of two Ethernet frame formats. Understanding when to interpret this field as a Type versus a Length is essential for network engineers working with diverse network equipment and protocol analyzers.

The ambiguity of the Type/Length field stems from two parallel Ethernet standardization efforts in the early 1980s.

DIX Ethernet (Ethernet II)

The original Ethernet specification was developed by Digital Equipment Corporation (DEC), Intel, and Xerox (forming the "DIX" consortium) in 1980. DIX Ethernet used the 2-byte field after the source MAC address as a Type field—a protocol identifier indicating what upper-layer protocol was encapsulated.

IEEE 802.3

The IEEE standardized Ethernet as 802.3 in 1983-1985, but with a different interpretation. IEEE 802.3 used the same 2-byte field as a Length field—indicating the size of the payload in bytes. This approach aligned with other IEEE 802 standards (Token Ring, Token Bus) that used LLC (Logical Link Control) headers to identify protocols.

The Incompatibility Problem

These two interpretations are mutually exclusive for any given frame:

• DIX: Field = EtherType identifying protocol
• IEEE 802.3: Field = Payload length, protocol identified by LLC header in payload

Both formats carried identical data on the wire, but receivers needed to know which interpretation applied to correctly demultiplex the encapsulated payload.

The key insight that enables coexistence of both frame formats is a numerical boundary built into the field's interpretation:

The Rule:

If field value ≤ 1500 (0x05DC)  →  Interpret as Length
If field value ≥ 1536 (0x0600)  →  Interpret as EtherType
If 1501 ≤ value ≤ 1535         →  Undefined/Invalid

Why These Specific Values?

The Ethernet maximum payload is defined as 1500 bytes. Any legitimate Length value cannot exceed 1500. The DIX consortium deliberately assigned EtherType values starting at 1536 (0x0600) and above, creating a gap that ensures no collision between the two interpretations.

The 35-byte gap (1501-1535) acts as a buffer zone, guarding against off-by-one errors and providing room for future expansion.

Implementation in Network Stacks

Every Ethernet device implements this disambiguation logic:

// Pseudocode for Type/Length field processing
uint16_t type_length = read_big_endian_16(frame + 12);

if (type_length <= 1500) {
    // IEEE 802.3 frame with Length field
    payload_length = type_length;
    protocol = parse_llc_snap_header(frame + 14);
} else if (type_length >= 1536) {
    // Ethernet II frame with EtherType
    ethertype = type_length;
    payload = frame + 14;  // Payload starts immediately after
    demux_to_protocol(ethertype, payload);
} else {
    // Invalid frame (1501-1535 range)
    drop_frame(frame);
}

Byte Ordering

The Type/Length field is transmitted in network byte order (big-endian): the most significant byte is transmitted first. A Type value of 0x0800 (IPv4) is transmitted as byte 0x08 followed by byte 0x00.

EtherType values are assigned and maintained by the IEEE Registration Authority. The most commonly encountered values in modern networks include:

The Big Three: IPv4, ARP, IPv6

In a typical enterprise or home network, three EtherTypes dominate traffic:

1. 0x0800 (IPv4) — The workhorse of modern networking. Nearly all application traffic (HTTP, HTTPS, DNS, email, streaming) is carried over IPv4.

2. 0x0806 (ARP) — Essential for IPv4 operation. Before any IPv4 communication can occur, ARP resolves IP addresses to MAC addresses.

3. 0x86DD (IPv6) — Increasingly common as IPv6 adoption grows. Many networks run dual-stack, generating both IPv4 and IPv6 traffic.

VLAN Tagging: 0x8100

The EtherType 0x8100 is special—it indicates that a VLAN tag follows. This effectively inserts a 4-byte 802.1Q header between the source MAC and the 'real' EtherType:

Without VLAN tag:
┌────────┬────────┬──────────┬─────────┬─────┐
│Dst MAC │Src MAC │EtherType │ Payload │ FCS │
│ 6B     │ 6B     │  2B      │46-1500B │ 4B  │
└────────┴────────┴──────────┴─────────┴─────┘

With VLAN tag:
┌────────┬────────┬────────┬────────┬──────────┬─────────┬─────┐
│Dst MAC │Src MAC │ 0x8100 │VLAN Tag│EtherType │ Payload │ FCS │
│ 6B     │ 6B     │   2B   │  2B    │   2B     │42-1500B │ 4B  │
└────────┴────────┴────────┴────────┴──────────┴─────────┴─────┘

When the Type/Length field contains a value of 1500 or less, it indicates an IEEE 802.3 frame where the field represents the payload length in bytes.

Why Specify Length?

Ethernet has a minimum frame size of 64 bytes (excluding Preamble/SFD). For payloads smaller than 46 bytes, padding is required to reach the minimum. The Length field tells the receiver exactly how many bytes constitute actual data versus padding:

Example: 20-byte payload in IEEE 802.3 frame

Type/Length field: 0x0014 (20 in decimal)
Payload:          20 bytes of actual data + 26 bytes of padding
Receiver:         Uses Length field to discard 26 padding bytes

The Protocol Identification Problem

With the Length field occupied by a byte count, how does the receiver know which protocol is encapsulated? IEEE 802.3 uses the Logical Link Control (LLC) header, defined in IEEE 802.2, as the first bytes of the payload:

SNAP Extension

The basic LLC SAP values provide limited protocol identification (only 128 unique values, as SAP values are 7 bits). To carry EtherType-identified protocols over 802.2, the Sub-Network Access Protocol (SNAP) extension was added.

SNAP uses DSAP=0xAA, SSAP=0xAA, Control=0x03, followed by a 5-byte SNAP header:

SNAP Header (5 bytes):
┌─────────────────────┬────────────────┐
│   OUI (3 bytes)     │ EtherType (2B) │
├─────────────────────┼────────────────┤
│ 00:00:00 (standard) │   Protocol     │
└─────────────────────┴────────────────┘

The OUI of 00:00:00 indicates the standard EtherType space. The EtherType field then carries the same values as in Ethernet II frames (0x0800 for IPv4, etc.).

Complete IEEE 802.3 + LLC/SNAP Frame:

┌────────┬────────┬────────┬────────────────────┬────────────────────┬─────────┬─────┐
│Dst MAC │Src MAC │ Length │ LLC (3B)           │ SNAP (5B)          │ Payload │ FCS │
│ 6B     │ 6B     │  2B    │DSAP,SSAP,Control   │OUI,EtherType       │ Data    │ 4B  │
└────────┴────────┴────────┴────────────────────┴────────────────────┴─────────┴─────┘

This adds 8 bytes of overhead (3 LLC + 5 SNAP) compared to Ethernet II, reducing maximum payload to 1492 bytes.

Ethernet II framing (also called DIX Ethernet) is the dominant format in modern networks. When the Type/Length field contains a value ≥ 1536, the receiver interprets it as an EtherType and demultiplexes the payload accordingly.

Complete Ethernet II Frame Structure:

┌─────────┬─────┬────────────┬────────────┬──────────┬───────────────┬─────────┐
│Preamble │ SFD │ Dst MAC    │ Src MAC    │EtherType │ Payload       │   FCS   │
│ 7 bytes │ 1B  │ 6 bytes    │ 6 bytes    │ 2 bytes  │ 46-1500 bytes │ 4 bytes │
└─────────┴─────┴────────────┴────────────┴──────────┴───────────────┴─────────┘
          │                   MAC Frame (64-1518 bytes)                        │
          └───────────────────────────────────────────────────────────────────┘

Byte Positions (relative to MAC frame start):
  0-5:   Destination MAC
  6-11:  Source MAC
  12-13: EtherType
  14+:   Payload

Frame Size Constraints

Ethernet II frames must comply with size requirements:

Payload Padding

If the upper-layer protocol provides fewer than 46 bytes, padding is added to meet the minimum frame size:

Example: ARP packet (28 bytes) in Ethernet II frame

EtherType:  0x0806 (ARP)
ARP Data:   28 bytes
Padding:    18 bytes (zeroes)
Frame:      6 + 6 + 2 + 28 + 18 + 4 = 64 bytes ✓

In Ethernet II framing, the receiver determines the end of valid data by examining the upper-layer protocol headers (IP total length, ARP fixed size, etc.) rather than relying on a Length field.

The Type/Length field position becomes more complex when VLAN tags are present. IEEE 802.1Q VLAN tagging inserts a 4-byte tag between the source MAC and the original Type/Length field.

802.1Q VLAN Tag Structure:

802.1Q Tag (4 bytes):
┌──────────────────┬──────────────────────────────────────────┐
│ TPID (2 bytes)   │ TCI (2 bytes)                            │
│     0x8100       │  PCP (3b) │ DEI (1b) │ VLAN ID (12b)     │
└──────────────────┴──────────────────────────────────────────┘

TPID = Tag Protocol Identifier (0x8100 for 802.1Q)
TCI  = Tag Control Information
PCP  = Priority Code Point (QoS, 0-7)
DEI  = Drop Eligible Indicator
VLAN ID = VLAN identifier (0-4095, with 0 and 4095 reserved)

Position in Frame:

Untagged frame:
┌────────┬────────┬──────────┬─────────┬─────┐
│Dst MAC │Src MAC │EtherType │ Payload │ FCS │
└────────┴────────┴──────────┴─────────┴─────┘
                    ^ Position 12-13

VLAN-tagged frame:
┌────────┬────────┬────────────┬──────────┬─────────┬─────┐
│Dst MAC │Src MAC │ 802.1Q Tag │EtherType │ Payload │ FCS │
│        │        │  (4B)      │          │         │     │
└────────┴────────┴────────────┴──────────┴─────────┴─────┘
                    ^ TPID 0x8100   ^ Position 16-17

How VLAN Parsing Works

The receiver follows this logic:

1. Read bytes 12-13 as Type/Length field
2. If value is 0x8100, this is a VLAN tag:
   • Extract VLAN ID and priority from tag
   • Read bytes 16-17 as the actual EtherType
3. Continue parsing based on actual EtherType

Double Tagging (Q-in-Q / 802.1ad)

Service providers use double tagging to encapsulate customer VLANs within provider VLANs. IEEE 802.1ad defines Q-in-Q with an additional "S-Tag" (Service Tag):

Double-tagged frame (Q-in-Q):
┌────────┬────────┬───────────────┬─────────────┬──────────┬─────────┬─────┐
│Dst MAC │Src MAC │ S-Tag (0x88A8)│C-Tag (8100) │EtherType │ Payload │ FCS │
│        │        │  Provider     │ Customer    │          │         │     │
└────────┴────────┴───────────────┴─────────────┴──────────┴─────────┴─────┘

S-Tag TPID: 0x88A8 (indicates provider/service tag)
C-Tag TPID: 0x8100 (customer VLAN tag)

This nesting allows providers to transport customer VLANs 1-4094 across a provider network while maintaining full VLAN isolation between customers.

Understanding the Type/Length field is essential for packet analysis and network troubleshooting.

Reading the Field in Wireshark

Wireshark automatically interprets the Type/Length field:

Ethernet II, Src: Dell_3c:4d:5e, Dst: Cisco_aa:bb:cc
    Destination: Cisco_aa:bb:cc (00:00:0c:aa:bb:cc)
    Source: Dell_3c:4d:5e (00:1a:2b:3c:4d:5e)
    Type: IPv4 (0x0800)    ← Displayed as Type for EtherType values

-- OR for IEEE 802.3 --

IEEE 802.3 Ethernet
    Destination: ...
    Source: ...
    Length: 42             ← Displayed as Length for values ≤ 1500
    Logical-Link Control
        DSAP: SNAP (0xaa)
        SSAP: SNAP (0xaa)
        Control: UI (0x03)
        Organization: 00:00:00
        Type: IPv4 (0x0800)

Filtering by EtherType

Network devices can filter traffic based on EtherType, enabling protocol-specific policies:

Switch EtherType ACLs (Cisco example):

mac access-list extended BLOCK-IPX
  deny any any 0x8137 0x0000
  permit any any

interface GigabitEthernet0/1
  mac access-group BLOCK-IPX in

Linux iptables/ebtables:

ebtables -A FORWARD -p 0x8137 -j DROP   # Block IPX
ebtables -A FORWARD -p 0x0806 -j LOG    # Log ARP

Wireshark display filter:

eth.type == 0x0800         # IPv4 only
eth.type == arp            # ARP only
eth.type != 0x86dd         # Exclude IPv6
llc.type == 0x0800         # IPv4 over LLC/SNAP

The Type/Length field represents a pragmatic compromise between two Ethernet standardization approaches. Its dual interpretation has worked seamlessly for decades, enabling transparent coexistence of different frame formats.

What's Next

With addressing and protocol identification in place, the frame's core purpose—carrying user data—comes into focus. The next page examines the Payload field in detail, covering its size constraints, padding requirements, and the relationship between MTU and Ethernet frame capacity.