When an application sends data, the operating system eventually needs to place that data onto a physical network. On a wired local network, Ethernet commonly provides the rules for doing so.

Ethernet defines how a network interface packages data into a frame, identifies the sender and intended receiver on the local link, indicates what the frame carries, and detects damage introduced during transmission.

The word local defines the scope. An Ethernet frame carries data across the current Layer 2 network. A packet that crosses multiple networks uses the link-layer framing appropriate to each part of its path.

This chapter develops a precise model of Ethernet framing: what a frame contains, how large it can be, how a receiver processes it, and why packet captures do not always show every byte transmitted on the wire.

Ethernet is a family of wired networking technologies standardized primarily by IEEE 802.3. Over time, it has used different copper and fiber media and has grown from megabits to hundreds of gigabits per second. Despite those physical changes, its core link-layer service remains recognizable.

For each transmission, Ethernet provides:

Ethernet does not interpret an HTTP request, identify an application process, or choose an internet route. It usually treats an IP packet as an opaque sequence of payload bytes. Its responsibility is narrower: carry that payload in a frame across the current Ethernet network.

Ethernet preserves the boundary between frames. If an interface transmits three frames, a receiver processes three separate frames rather than one continuous stream of bytes. Each frame has its own header, payload, and integrity check.

An IP packet and an Ethernet frame solve different delivery problems.

The IP packet identifies network-layer endpoints and can be forwarded across many networks. The Ethernet frame carries data across one local Layer 2 path. Its destination identifies the next local receiver, which may be the final host or a device that can move the packet toward another network.

A laptop sending a request to a remote server first creates an Ethernet frame for its local network. When the enclosed IP packet later enters a different Layer 2 network, the interface at that boundary creates a new frame suitable for the next link.

This local scope explains why an Ethernet integrity check protects one frame transmission rather than an entire multi-network journey. If a packet crosses another Ethernet link, that link uses its own frame and Frame Check Sequence.

Ethernet II is the frame format most commonly seen carrying IPv4, IPv6, and other network-layer protocols.

An untagged Ethernet II frame has the following logical structure:

The physical interface transmits the preamble and Start Frame Delimiter before the MAC frame. The interpacket gap represents required idle time after a transmission and sits outside the stored frame. For that reason, the conventional Ethernet frame size counts from the destination address through the FCS.

The next sections examine the fields in the order in which they are transmitted.

The receiver needs to synchronize its clock with the incoming signal before interpreting address and payload bits.

The preamble is a 7-byte alternating bit pattern. It gives the physical receiver enough transitions to establish synchronization. The Start Frame Delimiter, or SFD, is one byte that ends with a distinct bit pattern and marks the beginning of the MAC frame.

Conceptually:

Ethernet transmits each byte least-significant bit first, which is why tools and documentation can display these patterns in a different-looking hexadecimal form. The important behavior is the same: the preamble establishes synchronization, and the SFD identifies where frame fields begin.

Network interface hardware normally creates and consumes these eight bytes. A packet captured by the operating system therefore rarely includes them.

The first field in the MAC frame is the 6-byte destination address, followed by the 6-byte source address.

Addresses are usually written as six hexadecimal octets:

The destination comes first so receiving hardware can determine early whether the frame is relevant. The source tells the local network which interface transmitted the frame.

The destination field supports three delivery forms:

Unicast targets one interface address.

Multicast targets a group of interested interfaces.

Broadcast targets every interface in the local broadcast scope and uses:

A normal source address represents one sender. The all-ones broadcast address must not be used as a source.

These addresses are link-layer identifiers. They do not contain an internet route, transport port, or application identity. Ethernet uses them only to support delivery within the current Layer 2 network.

The 2-byte EtherType tells the receiver how to interpret the Ethernet payload. Common values include:

If a frame contains an IPv4 packet, for example, the sender writes 0x0800. After accepting the frame, the receiver uses that value to pass the payload to its IPv4 implementation.

EtherType is an example of protocol multiplexing. The same Ethernet interface can carry several higher-layer protocols because every frame identifies the kind of payload it contains.

The field has a historical second interpretation. In IEEE 802.3 framing, a value of 1500 or less represents payload length rather than a protocol type. Values of 1536 (0x0600) or greater represent EtherTypes. Modern packet captures carrying IP commonly display the frame as Ethernet II and interpret this field as EtherType.

An optional IEEE 802.1Q tag can appear between the source address and EtherType. It adds four bytes to the frame. The untagged Ethernet II format remains the basis for the size calculations in this chapter.

The payload carries the higher-layer unit, most often an IP packet. In a conventional untagged Ethernet frame, the payload field is at most 1500 bytes.

That maximum is the familiar Ethernet Maximum Transmission Unit, or MTU:

The MTU does not include the 14-byte Ethernet header or the 4-byte FCS. Therefore, a frame with a full 1500-byte payload has this size:

Ethernet also has a minimum frame size. From the destination field through the FCS, an untagged frame must be at least 64 bytes. The header and FCS consume 18 bytes, leaving at least 46 bytes between EtherType and FCS:

If the higher-layer payload is shorter than 46 bytes, the sender adds padding. Padding belongs to the Ethernet frame, not to the enclosed packet.

Consider an IPv4 packet containing a 20-byte IPv4 header and a 20-byte TCP header with no TCP payload. The IP packet is only 40 bytes, so Ethernet adds 6 bytes of padding:

The receiver can distinguish real payload from padding using length information in the higher-layer protocol. For example, an IPv4 header contains the total length of its packet. Ethernet itself does not add a field saying that the last six bytes are padding.

The minimum size is a legacy of shared, half-duplex Ethernet, where a sender needed to remain transmitting long enough to detect a collision at the farthest supported distance. Modern full-duplex Ethernet does not use collision detection, but the minimum frame size remains part of the format.

The final four bytes are the Frame Check Sequence, or FCS. The sender computes this value from the destination address, source address, EtherType, payload, and padding. Ethernet uses a 32-bit cyclic redundancy check, commonly called CRC-32.

The receiver performs the same calculation. If its result does not match the received FCS, the frame was damaged in transit and is discarded.

The FCS provides error detection. It cannot reconstruct damaged bits. Standard Ethernet also does not acknowledge the frame or retransmit it at the data link layer. If reliable delivery is required, another protocol or the application must provide the appropriate recovery behavior.

CRC-32 targets common transmission errors. It provides no protection against malicious modification because an attacker who can change a frame can calculate a new valid FCS. The FCS provides neither cryptographic integrity nor authentication.

Ethernet size statements can appear inconsistent because engineers count different parts of the transmission.

For an untagged frame with a 1500-byte payload:

The interpacket gap is time during which no frame data is transmitted. Expressing it as 12 byte-times makes link-capacity calculations convenient.

For the minimum frame:

Small frames spend a larger fraction of link capacity on headers, synchronization, integrity checking, and the interpacket gap. Large frames carry payload more efficiently. That does not make small frames invalid; many control messages are naturally small and need low latency more than bulk efficiency.

An IEEE 802.1Q tag adds four bytes, so a full-size tagged frame can be 1522 bytes from destination address through FCS. Networks may also support jumbo frames, often with an MTU near 9000 bytes, but there is no single universal jumbo-frame size. Every relevant interface and link must support the selected size. A 1500-byte MTU remains the safe conventional assumption for standard Ethernet.

The receiving path can be understood as a short sequence:

Frames with an invalid FCS, an unsupported size, or an unacceptable destination are normally discarded before an application sees them.

Ethernet provides best-effort local delivery. A valid transmitted frame can still be lost because of corruption, congestion, a disconnected link, or a device failure. The absence of a frame-level acknowledgment means the sender does not learn from Ethernet alone whether a particular receiver processed the frame.

Early Ethernet connected multiple devices to a shared medium. Only one device could transmit successfully at a time. A device listened before sending and monitored the medium for a collision. If a collision occurred, the participants stopped, waited for randomized intervals, and tried again. This mechanism is called CSMA/CD: Carrier Sense Multiple Access with Collision Detection.

Modern Ethernet links are normally full duplex. Each endpoint has an independent transmit and receive path, so both can send simultaneously. There is no shared collision domain on such a link, and CSMA/CD is not used.

The distinction is useful when reading documentation or capture statistics. Collisions describe shared, half-duplex Ethernet behavior. On a correctly configured full-duplex link, collision counters should not be part of normal operation. Errors that remain relevant include damaged frames, invalid sizes, physical signal problems, and dropped frames.

Packet analysis tools decode link-layer fields before showing the enclosed protocols. On macOS or Linux, a short tcpdump capture can include the Ethernet header:

Replace en0 with the active Ethernet interface. The options mean:

Adding -XX includes a hexadecimal and ASCII dump:

A summarized line may resemble:

This reveals the source address, destination address, EtherType, and captured length. A graphical analyzer presents the same nesting as expandable Frame, Ethernet II, and payload-protocol sections.

Captures made on a host commonly omit the preamble, SFD, and interpacket gap because those belong to physical transmission. They also commonly omit the FCS because the network interface validates and removes it before passing the frame to the operating system.

This produces a frequent size surprise: a minimum 64-byte frame may appear as only 60 bytes when the 4-byte FCS is absent. A full untagged frame may appear as 1514 bytes rather than 1518 for the same reason.

Whether the FCS is visible depends on the capture point, interface hardware, driver, and capture configuration. A network tap or specialized capture adapter can expose information that an ordinary host capture does not.

Consider the first 14 bytes of a captured Ethernet II frame:

Split them according to the frame format:

The EtherType 0x0800 says that the next byte begins an IPv4 packet. If the value were 0x86DD, the payload would begin with an IPv6 header.

Multi-byte EtherType values use network byte order, with the most significant byte first. The bytes 08 00 therefore form 0x0800, not 0x0008.

This 14-byte split is the first step when decoding an ordinary untagged Ethernet II frame manually. After identifying the EtherType, the remaining bytes must be interpreted according to that payload protocol rather than as more Ethernet header fields.

Assume an interface needs to transmit a 100-byte IPv4 packet in an untagged Ethernet II frame.

The sender:

The resulting frame size is:

On the physical link, the transmission also uses 8 bytes for the preamble and SFD, followed by an interpacket gap of 12 byte-times:

The receiver synchronizes, accepts the destination, verifies the FCS, reads 0x0800, removes the Ethernet framing, and passes the original 100-byte packet to IPv4. Ethernet does not need to understand the addresses, options, or transport data inside that packet.

Frames and packets are different protocol units. A frame is a Layer 2 unit for local delivery. An IP packet is commonly the frame's payload.

The Ethernet MTU measures the higher-layer payload. The conventional 1500-byte MTU excludes the Ethernet header, FCS, preamble, and interpacket gap.

A valid FCS confirms one corruption check. It proves that the received frame passed Ethernet's CRC calculation. Application delivery and processing require separate evidence.

The FCS detects accidental transmission errors. An attacker can modify a frame and calculate a matching FCS, so security requires cryptographic protection.

The capture point determines which frame components appear. Hardware can remove the preamble and FCS before capture, so displayed lengths and bytes can differ from the physical transmission.

Wi-Fi uses its own frame format over radio. Systems can translate or bridge data between Wi-Fi and Ethernet, which can cause an operating system or analyzer to present a simplified Ethernet-like view.

Ethernet carries higher-layer data across a wired local network in frames. An Ethernet II frame contains destination and source addresses, an EtherType, a payload with possible padding, and a Frame Check Sequence. Untagged frames are normally 64 to 1518 bytes from the destination address through the FCS; the usual MTU is 1500 bytes, and payloads below 46 bytes require padding.

The preamble and SFD synchronize the receiver, the interpacket gap separates transmissions, and EtherType identifies the enclosed protocol. CRC-32 detects damage, but Ethernet does not correct, acknowledge, or retransmit frames.

Frames have local rather than end-to-end scope. Host captures often omit the preamble and FCS, making captured frames appear smaller than their on-wire form.

An Ethernet frame is a local delivery envelope with explicit boundaries, local addresses, a typed payload, and an integrity check.