skip to content

What fields make up an Ethernet II frame, and why is an untagged frame between 64 and 1,518 bytes long?

level: middleimportance: must knowfreq 46%

answer

  1. addresses first, checksum last
  2. two bytes name the payload
  3. 46 bytes of data at least
  4. preamble is not counted

basics

~20 s

An Ethernet II frame is destination MAC (6 bytes), source MAC (6), EtherType (2), payload (46-1,500) and a 4-byte CRC: 64 to 1,518 bytes. The preamble and start delimiter precede it on the wire and are not counted.

solid answer

~50 s

On the wire a frame starts with a 7-byte **preamble** and a 1-byte **start frame delimiter**, which synchronise the receiver and are not counted in frame size. Then come the **destination MAC** (6 bytes), **source MAC** (6), the 2-byte **EtherType** naming the payload (`0x0800` IPv4, `0x0806` ARP, `0x86DD` IPv6), the **payload**, and a 4-byte **frame check sequence**, a CRC over everything from the destination address on. The payload must be 46 to 1,500 bytes (RFC 894), so 14 + 46 + 4 = **64** and 14 + 1,500 + 4 = **1,518**. The 64-byte floor comes from half-duplex collision detection; a shorter payload is padded with zeros that are not part of the IP packet. A value of 1,500 or less in the type position is an IEEE 802.3 length, not an EtherType, and a frame whose CRC fails is silently discarded.

go deeper

for a junior

Recall the order: destination MAC, source MAC, type, payload, CRC. Know that the payload holds the IP packet and that 1,500 bytes is its usual limit.

for a middle

Derive 64 and 1,518 from the field sizes, explain padding to 46 bytes, and state the 0x0600 rule that separates an EtherType from an 802.3 length. Say what the FCS covers.

for a senior

Use the layout to reason about traffic: small-packet rates from the 84-byte wire cost, silent FCS drops as a link-health signal, and why padding never shows up in the IP length.

for a principal

Treat the frame format as a compatibility contract: the collision-era minimum and the historical 1,500 maximum survive because every device on a segment must agree, and changing them costs more than the overhead they impose.

## The layout on the wire An **Ethernet II** frame (the format IP uses, RFC 894 for IPv4 and RFC 2464 for IPv6) is a short header, a payload and a trailer. Two fields go before the frame proper: | Field | Size | Purpose | |---|---|---| | Preamble | 7 bytes | alternating bits that let the receiver lock on to the signal | | Start frame delimiter (SFD) | 1 byte | marks where the frame begins | | **Destination MAC** | 6 bytes | who should accept the frame | | **Source MAC** | 6 bytes | the interface that sent it | | **EtherType** | 2 bytes | which protocol the payload holds | | **Payload** | 46-1,500 bytes | the IP packet, ARP message or other data | | **Frame check sequence (FCS)** | 4 bytes | a 32-bit CRC over destination through payload | The preamble and SFD belong to the physical signalling, so frame sizes count from the first byte of the destination address to the last byte of the FCS (RFC 1042 states the 1,518 maximum that way). After a frame, IEEE 802.3 also requires an idle **interframe gap** of 12 byte times. The destination comes first for a reason: a receiver can decide whether the frame is for it after six bytes, before the rest has arrived. ## Where 64 and 1,518 come from 1. Header: 6 + 6 + 2 = **14 bytes**; trailer: **4 bytes**; together 18 bytes of overhead (RFC 1042). 2. Minimum payload **46 bytes** (RFC 894): 14 + 46 + 4 = **64 bytes**. 3. Maximum payload **1,500 bytes** (RFC 894): 14 + 1,500 + 4 = **1,518 bytes**. 4. A 4-byte 802.1Q VLAN tag, which belongs to the VLAN material, raises the maximum to 1,522. The **64-byte minimum** is a relic of shared, half-duplex Ethernet. A sender detects a collision only while it is still transmitting, so every frame had to last long enough for a collision at the far end of the longest allowed cable to come back before the sender finished; for 10 and 100 Mb/s IEEE 802.3 fixed that slot time at 512 bit times, which is 64 bytes. Full-duplex links have no collisions, but the minimum stayed for compatibility. The **1,500-byte maximum** was a historical compromise in the original Ethernet specification among buffer memory, how long one station could hold a shared cable, and header overhead; no formula derives it. RFC 894's text contains a well-known slip: its second size sentence says the "minimum" data length is 1,500 octets, and the same sentence then calls 1,500 the maximum IP datagram, which is the intended meaning. ## Short payloads and padding When the payload is under 46 bytes, the sender pads it with zero bytes. RFC 894 says that padding "is not part of the IP packet and is not included in the total length field of the IP header", so the receiver uses the upper layer's own length field to find where the real data ends. An ARP message for IPv4 over Ethernet is 28 bytes, so it always travels with 18 bytes of padding. ## EtherType or length The two bytes after the source address can mean two things, and the value decides which (RFC 9542 section 3): - **0x0600 (1,536) or above**: an **EtherType**. Common ones: `0x0800` IPv4 (RFC 894), `0x0806` ARP (2054, RFC 1042), `0x86DD` IPv6 (RFC 2464). - **1,500 (0x05DC) or below**: an IEEE 802.3 **length**. The payload then begins with an LLC header: two service access points and a control byte. With the SNAP form (`AA-AA-03`, RFC 1042) the LLC header is followed by an OUI and a two-byte EtherType, eight bytes of extra header in all. - Values from 1,501 to 1,535 are neither and should not appear. Ethernet II has no length field at all: the physical layer marks where a frame ends. ## The FCS and what a receiver does with a bad frame The sender computes a 32-bit CRC over destination, source, type and payload (padding included) and appends it. The receiver recomputes it; on a mismatch it **discards the frame silently**. Ethernet sends no negative acknowledgement and never retransmits; recovering lost data is the job of a higher layer such as TCP. ## Mistakes interviewers listen for - Counting the preamble in the 64-byte minimum. - Saying the 1,500 limit covers the whole frame; it is the payload, the IP packet. - Assuming the type field is always an EtherType. - Believing Ethernet retransmits a corrupted frame.

  • At 10 Gb/s, how many minimum-size frames per second can one link carry?
    A 64-byte frame also needs its 8 bytes of preamble and start delimiter and a 12-byte interframe gap, so it occupies 84 byte times, or 672 bits. 10,000,000,000 / 672 is about 14.88 million frames per second. That is the packet rate a device must sustain for line rate at small sizes, and why small-packet throughput is quoted separately from bandwidth.
  • What share of the wire carries payload when frames are full-size?
    A full frame is 1,518 bytes plus 20 bytes of preamble, delimiter and interframe gap, 1,538 byte times in all, of which 1,500 are payload: about 97.5 percent. At the 46-byte minimum, 46 of 84 byte times carry payload, about 55 percent, which is why per-frame overhead matters most for small messages.
  • What does a receiver do with a frame shorter than 64 bytes?
    It treats the frame as invalid and discards it. On shared, half-duplex Ethernet such runts were usually the remains of a collision; on a full-duplex link they point to a faulty sender or a damaged link. No error is sent back; a growing count of runts is a hardware or cabling clue, not a protocol event.

saying these in an interview costs you the question

  • The preamble counts towards the 64-byte minimum frame size.
  • The 1,500-byte limit covers the whole frame, MAC addresses and FCS included.
  • Ethernet retransmits a frame whose FCS check fails.
  • Padding bytes become part of the IP packet and its Total Length.
  • The two bytes after the source MAC are always an EtherType.
  • An Ethernet II frame carries a length field telling the receiver where it ends.