Ethernet Frame Format: The Complete Structure

All the preceding fields—Preamble, SFD, MAC addresses, Type/Length—exist to serve one purpose: reliably delivering the Payload from source to destination. The payload is where the actual data lives—the IP packets, ARP requests, DHCP messages, and all other upper-layer protocol information that applications and network services need to exchange.

The payload field is the heart of the Ethernet frame. Understanding its size constraints, padding requirements, and relationship to MTU (Maximum Transmission Unit) is essential for network design, troubleshooting fragmentation issues, and optimizing throughput.

The Ethernet payload has well-defined minimum and maximum size limits that have remained essentially unchanged since original Ethernet.

The Fundamental Limits:

Where the Numbers Come From:

Minimum MAC Frame (64 bytes):
  Destination MAC:  6 bytes
  Source MAC:       6 bytes
  Type/Length:      2 bytes
  Payload:          46 bytes (minimum)
  FCS:              4 bytes
  ─────────────────────────
  Total:            64 bytes

Maximum MAC Frame (1518 bytes):
  Destination MAC:  6 bytes
  Source MAC:       6 bytes
  Type/Length:      2 bytes
  Payload:          1500 bytes (maximum)
  FCS:              4 bytes
  ─────────────────────────
  Total:            1518 bytes

The 64-byte minimum frame size (requiring 46 bytes minimum payload) isn't arbitrary—it's a fundamental requirement of CSMA/CD (Carrier Sense Multiple Access with Collision Detection), the medium access control method used in half-duplex Ethernet.

The Collision Detection Requirement

In CSMA/CD, a transmitting station must be able to detect a collision while it's still transmitting. If a collision occurs, both stations will see corrupted signals and initiate the backoff-retry procedure. But if the transmitter finishes its frame before the collision signal propagates back from the far end of the cable, it won't know a collision occurred.

The Physics:

Station A ─────────── Maximum cable length ─────────── Station B
           ◀───────────── 2500 meters ──────────────▶
                      (10BASE5 maximum)

1. Station A begins transmitting
2. Station B (at maximum distance) begins transmitting just before A's signal arrives
3. Collision occurs near Station B
4. Collision signal must propagate back to Station A
5. Station A must still be transmitting when collision signal arrives

Calculating Minimum Frame Size:

The round-trip time for a signal to travel the maximum cable distance and back (accounting for repeaters, delays, etc.) is called the slot time. For 10 Mbps Ethernet:

• Slot time = 51.2 µs
• At 10 Mbps, 51.2 µs = 512 bits = 64 bytes

Therefore, a frame must be at least 64 bytes to ensure the transmitter is still sending when a worst-case collision signal returns.

*Note on Gigabit Ethernet: Gigabit Ethernet in half-duplex mode would require a 512-byte minimum frame for proper collision detection. To maintain backward compatibility with 64-byte minimums, Gigabit Ethernet introduced carrier extension—padding the transmission time (not the frame) to 512 bytes. In practice, virtually all Gigabit Ethernet runs full-duplex where CSMA/CD is disabled and minimum frame size is purely for compatibility.

Full-Duplex Operation

Modern Ethernet networks operate almost exclusively in full-duplex mode, where:

• Transmit and receive paths are completely separate
• No collision is possible (point-to-point connections)
• CSMA/CD is disabled

Despite this, the 64-byte minimum frame size is preserved for:

• Backward compatibility with legacy equipment
• Consistent framing across all Ethernet speeds
• Simplified receiver hardware design

When the upper-layer payload is smaller than 46 bytes, the transmitting NIC must add padding to reach the minimum frame size. This padding is transparent to higher layers—the receiver's network stack removes it before delivering data to protocols.

Padding Rules:

1. Padding is added after the actual payload data
2. Padding bytes are typically zeros (0x00)
3. Padding is included in the FCS calculation
4. The total payload + padding must be at least 46 bytes

Example: ARP Request

ARP (Address Resolution Protocol) messages are always 28 bytes for IPv4:

How Does the Receiver Know Where Data Ends and Padding Begins?

The Ethernet frame itself provides no explicit padding indicator. Instead, upper-layer protocols include their own length information:

• IP packets: IP header contains 'Total Length' field specifying exact packet size
• ARP: Fixed 28-byte format for IPv4
• IEEE 802.3: Length field specifies payload size (excluding padding)
• Other protocols: Each protocol defines its own length or fixed format

The receiving network stack:

1. Reads the Ethernet payload (including padding)
2. Examines the upper-layer protocol header for length
3. Discards bytes beyond the specified length as padding

Example: 10-byte IP packet (theoretical minimum):

Ethernet payload received: 46 bytes
IP header 'Total Length': 10 bytes
Protocol stack action: Process 10 bytes, discard 36 bytes padding

Padding Security Consideration

Padding bytes should be zeros, but the standard doesn't strictly require this. Some implementations have leaked memory contents in padding bytes (a security vulnerability). Modern NICs typically ensure padding is zeroed to prevent information leakage.

The Maximum Transmission Unit (MTU) is the largest amount of data (in bytes) that can be encapsulated in a single frame's payload. For standard Ethernet, MTU = 1500 bytes.

Why 1500 Bytes?

The 1500-byte limit was established in the original Ethernet specification (DIX Ethernet, 1980). The exact rationale involved:

1. Memory costs: 1980s buffer memory was expensive; 1500 bytes was a reasonable balance between efficiency and cost
2. Processing latency: Larger frames increase latency for small-packet traffic waiting in queues
3. Error probability: Larger frames have higher probability of bit errors, reducing effective throughput
4. Shared medium fairness: Large frames monopolize the medium longer, increasing access delay for other stations

These constraints were carefully balanced for the technology of the era, and the 1500-byte MTU has remained the default for decades.

MTU in Network Configuration

MTU is configured on network interfaces and must match along a communication path:

# Linux - show interface MTU
ip link show eth0
# Output: ... mtu 1500 ...

# Linux - set interface MTU
ip link set eth0 mtu 9000

# Windows - show MTU
netsh interface ipv4 show interfaces

# Windows - set MTU
netsh interface ipv4 set subinterface "Ethernet" mtu=9000

IP Fragmentation and MTU

When an IP packet is larger than the MTU of an outgoing interface, one of two things happens:

1. Fragmentation (IPv4 default): The packet is broken into smaller fragments that each fit within the MTU. Fragments are reassembled at the destination.

2. Packet Too Big / Fragment Needed (Path MTU Discovery): With Don't Fragment (DF) bit set, the router drops the packet and sends an ICMP error indicating the MTU. The sender then reduces packet size.

Fragmentation should generally be avoided due to:

• Reassembly overhead at destination
• Single lost fragment requires retransmission of all fragments
• State requirements for fragment tracking
• Security concerns (fragment overlap attacks)

Path MTU Discovery (PMTUD)

Modern systems use PMTUD to discover the smallest MTU along the entire path:

1. Send packets with DF bit set at interface MTU
2. If a router has smaller MTU, it sends 'Fragmentation Needed' ICMP
3. Sender records MTU and resends smaller packets
4. Process repeats until packets reach destination
5. Discovered MTU is cached for future connections

Jumbo frames are Ethernet frames with payloads larger than the standard 1500-byte MTU, typically up to 9000 bytes. They are not standardized by IEEE but are widely supported by enterprise and data center equipment.

Common Jumbo Frame Sizes:

Benefits of Jumbo Frames:

Use Cases for Jumbo Frames:

1. Storage Area Networks (iSCSI, NFS) — Large block transfers benefit significantly from reduced overhead.

2. Data Center Interconnects — East-west traffic between servers often involves bulk data movement.

3. High-Performance Computing (HPC) — MPI workloads and parallel file systems transfer large data volumes.

4. Backup and Replication — Nightly backup traffic involves large sequential transfers.

5. Video Production/Streaming — High-bitrate video benefits from fewer packets per second.

Testing Jumbo Frame Configuration:

# Linux - ping with specific packet size (add 28 for ICMP/IP headers)
ping -M do -s 8972 target-host    # Tests 9000 MTU

# If successful: jumbo frames work end-to-end
# If 'Message too long': MTU too small somewhere in path

The 1500-byte MTU is the maximum Ethernet payload, but encapsulated protocols consume part of this space for their own headers. Understanding overhead is critical for sizing application payloads correctly.

Common Protocol Header Sizes:

Calculating Effective Payload:

Example: TCP over IPv4

Ethernet MTU:         1500 bytes
IPv4 header (min):    - 20 bytes
TCP header (min):     - 20 bytes
─────────────────────────────────
Maximum TCP payload:  1460 bytes (MSS - Maximum Segment Size)

Example: TCP over IPv4 with VXLAN encapsulation

Ethernet MTU:          1500 bytes
VXLAN outer IP:        - 20 bytes
VXLAN outer UDP:       - 8 bytes
VXLAN header:          - 8 bytes
Inner Ethernet:        - 14 bytes
Inner IPv4:            - 20 bytes
Inner TCP:             - 20 bytes
──────────────────────────────────
Maximum TCP payload:   1410 bytes

This 50-byte reduction in effective payload demonstrates why overlay networks often require jumbo frames to maintain standard 1500-byte inner MTU.

Different Ethernet frame variants have slightly different payload capacities based on header requirements.

Ethernet II (DIX)

The simplest and most common format:

• Header: 14 bytes (6 + 6 + 2)
• Maximum payload: 1500 bytes
• FCS: 4 bytes
• Total: 1518 bytes

IEEE 802.3 with LLC/SNAP

Adds 8 bytes of LLC/SNAP header inside the payload:

• Header: 14 bytes
• LLC/SNAP: 8 bytes (counted as payload)
• Maximum user data: 1492 bytes
• FCS: 4 bytes
• Total: 1518 bytes

802.1Q VLAN Tagged

Adds 4-byte VLAN tag:

• Header: 18 bytes (6 + 6 + 4 + 2)
• Maximum payload: 1500 bytes
• FCS: 4 bytes
• Total: 1522 bytes

WiFi Frame Encapsulation

Wireless frames (802.11) have different header structures and additional addressing fields for wireless operation. When WiFi traffic is bridged to Ethernet:

• WiFi frames are converted to Ethernet II format
• Maximum payload becomes 1500 bytes (Ethernet MTU)
• WiFi supports larger frames internally (up to 7935 bytes with 802.11n/ac A-MSDU aggregation)

Special Payload Types

Some Ethernet frames carry non-data payloads:

These control frames typically use minimum-size payloads with padding.

The payload is the purpose of every Ethernet frame—delivering upper-layer data between nodes on the same network segment. Understanding payload constraints enables proper network design and troubleshooting.

What's Next

With the payload delivered, the receiver must verify that the frame arrived intact. The next page examines the Frame Check Sequence (FCS)—the 32-bit CRC that provides error detection for the entire MAC frame, ensuring data integrity across the physical medium.