Ethernet Frame Layout and the 64-Byte Minimum

A frame on an Ethernet link is a byte string with a fixed-shape header, a variable payload, and a trailer that carries nothing but a checksum. Everything above the link layer rests on that shape. The fourteen-byte header is what lets a receiver demultiplex traffic with no negotiation and no per-link state, and the sixty-four-byte floor is what made collision detection possible on a shared cable. Both rules survive in modern full-duplex switched networks, where the collisions are gone but the frame format is unchanged.

The bytes before the destination address

Transmission begins with a preamble of seven bytes, each holding the bit pattern 10101010, followed by a one-byte start frame delimiter, 10101011. The preamble is not counted as part of the frame by the MAC layer, but it is on the wire ahead of every frame. Its purpose is physical: it gives the receiver’s clock recovery circuitry a known transition pattern to lock onto before the meaningful bits arrive. On a modern point-to-point link the preamble still exists because the line encoding is defined at the physical layer and every PHY expects it.

The frame proper starts at the destination address. Its fields are:

Field	Bytes	Meaning
Destination address	6	MAC address of the intended receiver
Source address	6	MAC address of the transmitter
Type or length	2	Protocol identifier, or payload length in 802.3
Payload	46 to 1500	Data supplied by the network layer
Frame check sequence	4	CRC-32 over the preceding fields

Between frames the transmitter idles for an interframe gap of 96 bit times, twelve byte times at any speed. That gap gives the receiver time to process the trailer and reset for the next frame; it is not optional politeness but part of the specification.

Type, length, and the ambiguity in one field

The two bytes after the source address carry two different meanings depending on their value. Values of 0x0600 and above are EtherTypes, identifying the protocol inside the payload: 0x0800 for IPv4, 0x0806 for ARP, 0x86DD for IPv6, 0x8100 for a VLAN tag. Values at or below 0x05DC are lengths, the 802.3 interpretation, in which the payload begins with an LLC header that names the protocol instead. No legal length exceeds 1500, so the two ranges do not overlap and a receiver can classify a frame from this one field.

The split matters because the two formats put different things in the payload. An Ethernet II frame hands the payload directly to IPv4, which reads its own version field from the first nibble. An 802.3 frame hands it to LLC, whose header carries destination and source service access points. Mixing them produces frames that parse as garbage at the next layer, which is why the EtherType registry is the authoritative namespace for the modern format and why RFC 1042 specifies an encapsulation for the 802.3 side rather than reusing the type field.

There is no field for the payload length in Ethernet II. The receiver learns the frame’s extent from the physical layer, which delimits it, and learns the meaningful payload length from the encapsulated protocol’s own header. IPv4 carries a sixteen-bit total length; ARP’s payload is a fixed twenty-eight bytes for IPv4-over-Ethernet. This is a deliberate economy: one fewer field in a header carried by every frame, at the cost of requiring every upper protocol to describe its own size.

Why the frame cannot be shorter than 64 bytes

The minimum frame size, counted from the destination address through the frame check sequence, is 64 bytes. With eighteen bytes of header and trailer, the payload floor is 46 bytes.

The number comes from the original shared-medium design. A station on a coaxial segment must be able to detect that its transmission collided with another station’s before it finishes sending. If it finishes first, it will believe the frame was delivered while the frame was in fact destroyed, and the retransmission logic above it will never be triggered. The worst case is a station at one end of the cable sending to a station at the other end, whose signal must travel the full length and a collision indication must travel back. At 10 Mbit/s the maximum collision domain of 2500 metres was budgeted at 512 bit times for the round trip, which is 64 bytes. A frame shorter than that could be fully transmitted before the collision returned, so the standard forbids it.

Padding is applied by the MAC layer, not by the protocol above it. An IPv4 datagram of 20 bytes of header and 1 byte of payload arrives at the MAC as 21 bytes and leaves as 46 bytes of payload, the last 25 of which are zero bytes that no layer above the MAC ever asked for. The padding is not distinguishable by inspection: it is zeroes, but a legitimate payload can also end in zeroes.

Recovering the real payload length

Because padding is invisible in the frame itself, the receiver must use the encapsulated protocol’s length to decide where data ends. For IPv4 the total length field covers header and payload and excludes padding, so the receiver compares that value with the received payload size. If the total length is larger than what arrived, the frame was truncated, which on a switched link usually means a transmitter that underran its buffer or a receiver ring that dropped the tail; the frame is discarded rather than partially delivered. If the total length is smaller, the difference is padding and is dropped silently.

The failure mode to watch for is a stack that passes the full padded payload upward. An IPv4 receiver that trusts the frame length will include 25 bytes of padding in the transport checksum it computes, and the checksum fails. A UDP receiver that trusts it will deliver trailing zeroes to the application. Both bugs appear only for small packets, which is why they survive testing that uses bulk transfers.

/* Parse an Ethernet II frame whose FCS has already been checked and removed. */
struct eth_view {
    const uint8_t *dst, *src;
    uint16_t type;
    const uint8_t *payload;   /* may include padding */
    size_t len;
};

static int eth_parse(const uint8_t *f, size_t n, struct eth_view *v)
{
    if (n < 14)                 /* runt: shorter than the header itself */
        return -1;
    v->dst = f;
    v->src = f + 6;
    v->type = (uint16_t)((f[12] << 8) | f[13]);
    v->payload = f + 14;
    v->len = n - 14;
    if (v->type < 0x0600)       /* 802.3 length field, not an EtherType */
        return -1;
    return 0;
}

The comment on payload is the important one. A caller that needs the true length of an IPv4 datagram must read the total length from the payload’s own header and cap len at that value. The MAC layer will not do it, because the MAC layer does not know which protocol it is carrying.

What the header does not provide

An Ethernet header has no time-to-live, no sequence number, no acknowledgement, and no fragmentation mechanism. A frame either arrives intact or does not arrive. Duplicates are possible: a link that retransmits at a higher layer can produce two copies of the same datagram, and the link layer offers nothing to suppress the second. Reordering is possible on aggregated links, which is why the aggregation standards require that frames belonging to one conversation stay on one physical link.

There is also no authentication. The frame check sequence detects accidental corruption and nothing else. Any station with access to the segment can rewrite the source address, and a receiver has no cryptographic way to know. Port security features on switches and authentication at higher layers exist precisely because the frame format provides no such guarantee.

The maximum payload of 1500 bytes is not a physical limit but a standard one, chosen to bound the latency of a single frame at low speeds and to fit the buffer sizes of early controllers. Frames carrying more are not illegal on the wire if both ends agree, and the rules for doing so are a separate subject covered in link MTU and jumbo frames. The 46-byte floor, by contrast, cannot be relaxed: it is tied to the collision round-trip budget, and it stays in the standard even where no collisions can occur.

A frame’s addresses are read by the receiving MAC before any protocol above sees it. What counts as “for this station” depends on the structure of the address itself, which is the subject of MAC address structure and group addressing, and the trailer’s checksum has properties that determine what class of corruption it can catch, covered in the frame check sequence.