Ethernet and the Frame Format

Ethernet is a link-layer technology: a set of rules for framing, addressing, and (historically) medium access on a local network segment. Its job sits strictly between the physical layer, which delivers raw bits, and the network layer, which assumes a working point-to-point or broadcast delivery abstraction. A frame is the unit of transfer at this layer — analogous to a packet at the network layer, but scoped to a single physical or logical link rather than an end-to-end path. The central object of study is the Ethernet frame format, a fixed-structure header-payload-trailer arrangement that every Ethernet-compliant device, from a 1980s 10BASE5 transceiver to a modern 100 Gbps switch ASIC, must produce and parse identically. Complementing the frame is the MAC address (Media Access Control address), a 48-bit identifier burned into (or configured on) every network interface. Unlike IP addresses, MAC addresses are flat: there is no notion of a "MAC subnet," no aggregation, no relationship between an address's numeric value and its owner's location on the network. This flatness is a deliberate simplicity tradeoff — it makes addresses portable across any physical location, at the cost of not scaling to global routing (which is exactly why the network layer exists above it). A third concept threading through the frame format is the historical entanglement between framing and medium access. Early Ethernet (10BASE5, 10BASE2, and 10BASE-T hubs) was a genuine shared broadcast medium using CSMA/CD, described under Multiple Access Protocols. The frame format bears permanent scars from that era — most visibly the 64-byte minimum frame size — even though virtually all Ethernet deployed today is switched, full-duplex, and collision-free.

The frame, field by field

An Ethernet II frame (the dominant format in modern use, as opposed to the older, rarely-seen IEEE 802.3 length-field variant) has the following layout, transmitted left-to-right, most-significant-byte first within each field: ``` +-----------+---------+---------+------+------------------+----------+-----+ | Preamble | SFD | Dest | Src | Type/Length | Payload | FCS | | 7 bytes | 1 byte | 6 bytes |6 byte| 2 bytes | 46-1500 |4byte| +-----------+---------+---------+------+------------------+----------+-----+ ```

• Preamble (7 bytes): the pattern `10101010` repeated seven times. It exists purely so the receiver's clock-recovery circuitry can lock onto the sender's bit rate before real data arrives. It is a physical-layer synchronization aid, not logically part of the addressed frame.
• Start-of-Frame Delimiter, SFD (1 byte): the fixed pattern `10101011`. The final `11` breaks the alternating pattern, telling the receiver "the next bit is byte 0 of the actual frame."
• Destination address (6 bytes / 48 bits): the MAC address of the intended recipient, or a broadcast/multicast address.
• Source address (6 bytes / 48 bits): the MAC address of the sender's interface.
• Type/Length field (2 bytes): if the value is ≥ 1536 (0x0600), it is interpreted as an EtherType, identifying the encapsulated protocol (0x0800 for IPv4, 0x0806 for ARP, 0x86DD for IPv6). If the value is ≤ 1500, it is interpreted as a length field (the older 802.3 convention). Because valid Ethernet payloads never exceed 1500 bytes, these two interpretations never collide — a deliberate, elegant disambiguation.
• Payload / data (46–1500 bytes): the encapsulated network-layer packet. If the actual data is shorter than 46 bytes, the sender inserts padding to reach the minimum; the receiver strips it using length information from the upper-layer protocol (e.g., the IP header's own length field) or an explicit length subfield.
• Frame Check Sequence, FCS (4 bytes): a CRC-32 computed over the destination, source, type/length, and payload+padding fields (everything except the preamble/SFD). The receiver recomputes the CRC and discards the frame silently if it does not match.

The preamble and SFD are sometimes omitted from diagrams of "the frame" because they are stripped by the physical-layer interface before the frame reaches the MAC sublayer logically — but they are genuinely transmitted on the wire and are essential to synchronization.

Sending a frame — the sender's algorithm

``` function SEND_FRAME(dest_mac, src_mac, ethertype, data): if length(data) > 1500: error("payload exceeds MTU; caller must fragment upstream") if length(data) < 46: pad_len = 46 - length(data) data = data + ZERO_BYTES(pad_len) # pad to minimum payload header = dest_mac || src_mac || ethertype # 14 bytes body = header || data # header + payload fcs = CRC32(body) # 4-byte trailer frame = PREAMBLE || SFD || body || fcs TRANSMIT_ON_MEDIUM(frame) # physical layer handles bit encoding,

# and (historically) CSMA/CD arbitration ```

Receiving a frame — the receiver's algorithm

``` function RECEIVE_FRAME(bitstream): LOCK_CLOCK(bitstream.preamble) # physical-layer sync SKIP(bitstream, PREAMBLE_AND_SFD_BYTES) dest_mac = READ(bitstream, 6) src_mac = READ(bitstream, 6) type_or_len = READ(bitstream, 2) remaining = READ_UNTIL_FCS(bitstream) # payload + padding received_fcs = READ(bitstream, 4) body = dest_mac || src_mac || type_or_len || remaining if CRC32(body) != received_fcs: DISCARD_FRAME() # silent drop, no NACK sent return if dest_mac != MY_MAC and dest_mac != BROADCAST_MAC and not IS_MULTICAST_JOINED(dest_mac): DISCARD_FRAME() # not addressed to me return if type_or_len >= 1536: DELIVER_TO_PROTOCOL(type_or_len, remaining) # EtherType dispatch else: DELIVER_TO_PROTOCOL(LENGTH_MODE, remaining[0 .. type_or_len]) ``` Two design points deserve emphasis. First, address filtering happens in hardware, comparing the 48-bit destination field against the interface's own address (and any joined multicast groups) at line rate, so that frames not addressed to a host are dropped before consuming CPU cycles — historically essential on a shared bus where every host sees every frame. Second, error detection triggers silent discard, not retransmission: Ethernet provides no acknowledgment or automatic-repeat-request mechanism at this layer (contrast with link-layer protocols that do, discussed under Error Detection and Correction); reliability, if needed, is the responsibility of a transport-layer protocol running above IP.

The 64-byte minimum and why it existed

In classic CSMA/CD Ethernet, a transmitting station must be able to detect a collision while it is still transmitting, because that is the only way it knows to abort and retransmit later. If the frame were too short, the sender could finish transmitting and release the medium before a collision signal, propagating from the far end of the cable, had time to return. The station would then falsely believe its frame was delivered cleanly. Given a maximum round-trip propagation delay (bounded by the maximum cable length and number of repeaters allowed in a collision domain) and a fixed transmission rate, engineers derived a minimum frame time, called the slot time, and from it a minimum frame size:

For original 10 Mbps Ethernet, the slot time was set to 512 bit-times, giving a minimum frame size of 512 bits = 64 bytes. This is why the payload minimum is 46 bytes: 64 bytes total, minus 6 (dest) + 6 (src) + 2 (type/length) + 4 (FCS) = 18 bytes of overhead, leaves 46 bytes for data (padded if the real payload is shorter). When Ethernet speeds increased to 100 Mbps and beyond, this arithmetic became a genuine engineering problem: at ten times the bit rate, a 64-byte frame occupies one-tenth the time on the wire, so either the maximum collision-domain diameter would have to shrink by 10× (impractically small), or the frame size would have to grow (breaking compatibility with all deployed software and hardware). The actual solution, adopted for Fast Ethernet and Gigabit Ethernet, was different and more durable: switched, full-duplex Ethernet eliminated shared collision domains altogether. Each link between a host and a switch port is a dedicated point-to-point connection with no contention, so CSMA/CD and its slot-time derivation became vestigial. The 64-byte minimum frame size was kept anyway, purely for backward compatibility with the enormous installed base of frame-parsing hardware and software — a beautiful example of a constraint outliving its original cause. (Gigabit Ethernet in half-duplex, shared-medium mode — rarely deployed — instead used "carrier extension" to artificially lengthen short frames to preserve the timing math; full-duplex switched deployments never needed this.)

Framing overhead. Each frame carries 18 bytes of addressing/type/checksum overhead (6+6+2+4) plus 8 bytes of preamble/SFD, for 26 bytes of non-payload transmission per frame. For a maximum-size 1500-byte payload, this is roughly a 1.7% bandwidth overhead; for a minimum-size 46-byte payload, the overhead (26 bytes on top of 64) is over 40%. This is a direct efficiency argument for why protocols try to batch data into larger frames when possible, and why the standard defines a maximum transmission unit (MTU) of 1500 bytes: larger frames amortize fixed overhead better, but risk longer transmission-time blocking of the shared medium (in the old shared model) and larger buffers/latency (in the switched model) — a classic latency-vs-throughput tradeoff, revisited whenever Multiple Access Protocols designs choose a maximum packet size.

Address lookup and filtering. Comparing a 48-bit destination address against the interface's own address is $O(1)$ — a fixed-width hardware comparator, not a search. This is central to Ethernet's design philosophy: every operation a network interface performs on a frame (synchronization, address match, CRC check) must complete in time proportional to frame length at line rate, with no data-dependent branching that could stall a hardware pipeline.

CRC-32 computation. Computing (or verifying) the Frame Check Sequence is $O(n)$ in the number of bits in the frame, since a CRC is computed via repeated polynomial-division steps, one per bit (or one per byte with a lookup-table optimization), each doing constant work. In practice, CRC hardware processes 8, 32, or 64 bits per clock cycle using precomputed tables, keeping pace with multi-gigabit line rates.

Correctness of the CRC check (why errors are almost always caught). A CRC-$n$ (here $n = 32$) treats the frame's bits as the coefficients of a binary polynomial $M(x)$, and appends a remainder $R(x)$ such that the resulting polynomial $M(x)\cdot x^{n} + R(x)$ is exactly divisible by a fixed generator polynomial $G(x)$ of degree $n$. The receiver divides the received bits by $G(x)$ and accepts the frame only if the remainder is zero. The correctness argument has two parts: 1. Any single-bit error is always detected. A single-bit flip changes the transmitted polynomial by adding $x^{i}$ for some position $i$. Since $G(x)$ (for standard Ethernet CRC-32) has more than one term and is not a factor of $x^i$ for any $i$ within the frame length, $x^i \bmod G(x) \neq 0$, so the received remainder cannot be zero — the corruption is caught with certainty. 2. Burst errors up to length $n$ are always detected, because a burst of length $\le n$ can be written as $x^{j}\cdot B(x)$ where $B(x)$ has degree $< n$; as long as $G(x)$ does not divide $x^j B(x)$ — guaranteed by choosing $G(x)$ irreducible or with no small-degree factors matching the burst pattern — detection is certain. For error patterns longer than $n$ bits, or a small fraction of random multi-bit errors, there is a nonzero but tiny probability ($2^{-32}$ for random independent bit errors, under standard assumptions) that a corrupted frame produces a zero remainder and is falsely accepted — an inherent, quantifiable, and in practice negligible limitation, not a design flaw.

Why silent discard, not retransmission, is the correct layering choice. Ethernet has no notion of end-to-end session state; a switch or NIC that discards a corrupted frame has no reliable way to know who to notify or whether the sender is even still reachable via the same path. Reliability is therefore explicitly pushed to the transport layer (e.g., TCP's sequence numbers and retransmission timers), which does have end-to-end session state. This is a deliberate application of the end-to-end argument: a function (reliable delivery) should be implemented at the layer where it can be done completely and correctly, and Ethernet is not that layer.

Tradeoffs made explicit. The frame format buys hardware-speed processing and universal interoperability at the cost of (a) fixed, non-negotiable overhead per frame, (b) an MTU that forces upper layers to fragment larger data, and (c) no delivery guarantee — pure best-effort framing. These are the same tradeoffs revisited, at a different granularity, in Link-Layer Switches and Bridging, where per-frame forwarding decisions must also complete at line rate.

Consider a host with MAC address `AA:BB:CC:11:22:33` sending an IPv4 packet of 28 bytes (a small UDP datagram) to a host with MAC address `DD:EE:FF:44:55:66`.

Step 1 — assemble header fields.

Step 2 — check minimum size. Header (14) + payload (28) = 42 bytes, before the FCS. The minimum required is 60 bytes (64-byte frame minus 4-byte FCS). We must pad:

Now header (14) + payload (28) + padding (18) = 60 bytes.

Step 3 — compute the FCS. Let's illustrate the mechanism (not the actual 32-bit polynomial, which is impractical by hand) with a toy CRC over a short bit sequence, to make the division concrete. Suppose our "frame body" bits (a stand-in for the 60 real bytes) are:

and our generator is $G = 10011$ (degree 4, so we append 4 zero bits before dividing): ``` Dividend: 1101011011 0000 Generator: 10011 1101011011 0000 10011 ----- 0000111011 0000 (XOR first 5 bits: 11010 ^ 10011 = 01001, bring down...) ``` Carrying out binary long division (XOR-based, no borrow) of `11010110110000` by `10011` to completion yields a 4-bit remainder — call it `1110` for this toy example. The sender appends this remainder as the checksum:

Step 4 — receiver verifies. The receiver divides the entire received bit sequence (data + received remainder) by the same generator `10011`. If no bits were corrupted in transit, the division yields a remainder of exactly zero, and the frame is accepted. If even one bit flipped, the remainder is (with certainty, per the correctness argument above) nonzero, and the frame is silently dropped.

Step 5 — real Ethernet uses this same principle with $G(x)$ fixed by the IEEE 802.3 standard as a specific degree-32 polynomial, applied over the 60-byte body computed above (address fields, type, payload, and padding), producing a 4-byte FCS appended as the frame's final field. The complete frame on the wire is:

of which 64 bytes constitute the logical minimum Ethernet frame (excluding preamble/SFD).

This example deliberately used a small, asymmetric payload (28 bytes, not a round or trivially-padded number) to show padding arithmetic that a symmetric 46-byte example would hide entirely.

Ethernet emerged from a research culture at Xerox PARC dedicated to building the first networked personal-computing environment, years before "local area network" was a standard term. The original design borrowed its channel-access idea from ALOHAnet, a radio-based packet network developed at the University of Hawaii, but reworked it for a shared coaxial cable with carrier sensing and collision detection — the mechanism formalized as CSMA/CD.

Nearly every wired local-area network in existence — corporate offices, data centers, university campuses, home routers' LAN ports — runs Ethernet framing today, and Wi-Fi (802.11) borrows the same MAC address format and largely the same frame semantics to maintain compatibility with wired Ethernet segments it bridges to. Data center networks built on 10, 25, 40, and 100 Gbps Ethernet links carry the traffic of every major cloud provider, with the same 1500-byte-MTU frame format (or jumbo-frame variants) underlying it. Network interface cards, switch ASICs, and virtualization hypervisors (which must emulate virtual NICs presenting valid Ethernet frames to guest operating systems) all implement the exact byte layout described here. Understanding this frame format is the direct prerequisite for Link-Layer Switches and Bridging, where a switch's forwarding table is built entirely from observed source MAC addresses, and for the Address Resolution Protocol, which exists solely to map an IP address to the flat 48-bit MAC address that Ethernet framing requires for delivery on the local segment.

Ask the tutor: How does a switch use the source MAC address of an incoming frame to build its forwarding table, and what happens when it sees an unknown destination address?