Summary

  • RFC 894 made EtherType 0800 select IPv4, required zero padding when an Ethernet data field would otherwise be shorter than 46 octets, and kept those added bytes outside both the IP packet and the IPv4 Total Length field.
  • The separation created two valid measurements at once: a receiver had to store the link payload actually delivered, but IP parsing had to stop at Total Length. RFC 6274 later made the nesting explicit and required a drop when the link delivered fewer bytes than IP claimed.
  • Bytes without IP meaning were not without risk. CERT/CC documented drivers that reused stale buffer contents as padding, so a suffix excluded from the datagram could still disclose memory on the wire. The RFC's own “minimum 1500” typo likewise shows why original text and verified correction must remain distinguishable evidence.

The carrier needed bytes that IP had not created

Consider the smallest ordinary IPv4 header: twenty octets and no payload. Ethernet's 46-octet minimum data field still leaves twenty-six octets to account for. They cannot be invented application data, because no application supplied them. They cannot enlarge the IP datagram, because the sender wrote twenty into the IP Total Length field. Yet the link cannot simply omit them if it is to meet the minimum frame size.

RFC 894, published in April 1984, settled the ownership question directly. An IP datagram travelled in a standard Ethernet frame whose type field held hexadecimal 0800. The data field began with the IP header and continued immediately with IP data. If that field would be shorter than 46 octets, the sender added zero octets. The text then denied the added suffix membership in IP and excluded it from Total Length.

That is a stronger design than pretending one observed length must be the truth for every layer. Ethernet reported a physical container. IPv4 described a protocol object inside it. The container could be longer without altering the object.

RFC 791 had already defined the inner ruler. Total Length measures the datagram in octets, including the IP header and IP data. IHL separately measures the header in 32-bit words and therefore locates the start of the data. The two fields define a bounded object before Ethernet padding is considered: the header must fit inside the datagram, and the datagram can then fit inside a larger link payload.

0800 selected a grammar; it did not count octets

The outer two-octet field acquired another historical burden when Ethernet and IEEE 802.3 frames shared a cable. The field occupied the same position, but one framing treated it as a protocol type and the other as a length.

RFC 1122 described the numerical distinction in 1989. An 802.3 length was at or below 1500; valid EtherType values were above 1500. Hexadecimal 0800 is decimal 2048. It therefore told a receiver to interpret the following bytes as IPv4. It did not announce a 2048-octet frame.

The sequence of authority matters. The outer value first selects the grammar. Once IPv4 is selected, the Total Length field inside the IPv4 header locates the end of that datagram. The receiver does not use the end of its link buffer as a substitute merely because more bytes arrived.

RFC 1122 also turned the coexistence policy into a host requirement. A host on a 10 Mb/s Ethernet cable had to send and receive the RFC 894 form. It should receive the IEEE 802 form specified in RFC 1042, and could send it. A dual sender needed a configuration choice whose default was RFC 894. The common physical medium did not make the representations interchangeable; the receiver needed enough evidence to choose correctly.

Eight outer octets changed the MTU, not the datagram's constitution

RFC 1042 carried IP over IEEE 802.2 LLC and SNAP. The LLC and SNAP headers together occupied eight octets, with the final sixteen SNAP bits retaining the familiar EtherType: 2048 for IP and 2054 for ARP. Minimum-size padding remained zero-filled and remained outside IP Total Length.

The document described a minimum IP packet in that context as 28 octets: a twenty-octet minimum IP header plus eight octets of LLC and SNAP, excluding the MAC header. That number is not Ethernet's 46-octet minimum data field. They answer different accounting questions.

RFC 1122 later gave an Ethernet MTU of 1500 and an 802.3 MTU of 1492. The eight-octet difference reflected the extra LLC/SNAP carriage. It did not authorize an implementation to remove eight octets from the IPv4 header, include link padding in Total Length or treat an outer overhead as application data.

The companion RFC 895 makes the durable rule clearer. Its subject was the older 3 Mb/s Experimental Ethernet with 8-bit addresses. Its type value and 1536-octet maximum differed from RFC 894. Its padding rule did not: bytes needed for the link minimum remained outside IP Total Length. The invariant belonged to the handoff between layers, not to one magic Ethernet size.

A typo put the evidence boundary inside the standard

RFC 894's original text contains a sentence that calls 1500 octets the “minimum” length of the Ethernet data field and then, in the same sentence, derives a maximum IP datagram of 1500. The preceding paragraph had already given the actual minimum as 46. The word is technically consequential and internally impossible.

The RFC Editor's verified technical erratum 570 changes “minimum” to “maximum”. It was reported in 2001. Erratum 5141, reported in 2017 and verified in 2024, records the same correction. The later date does not mark a new Ethernet limit. It marks another reviewed entry in the correction ledger.

Current RFC Editor errata policy preserves both sides of the evidence. Published RFCs do not change. Verified errata are considered accurate, but are not incorporated into the TXT, PDF or XML publication formats. A reader needs the immutable record to know what was printed and the verified erratum to know how the sentence should be interpreted.

Silently repairing a local copy would make the paragraph smoother while weakening provenance. Treating the printed mistake as binding physical truth would preserve provenance while abandoning engineering sense. The proper answer is not to choose one record and destroy the other. It is to keep the original and correction linked.

Padding was not trailer encapsulation

The distinction is easy to lose because another April 1984 memo also discussed bytes near the end of an Ethernet packet. RFC 893 described trailer encapsulation, in which variable higher-level headers were deliberately moved after data to improve alignment for suitable receivers. That was an alternate link representation requiring receiver support and later per-peer discipline.

RFC 894 padding did none of those things. The IPv4 header remained first. The IP data followed it. A zero suffix was added only when the link needed more physical length. A receiver did not reconstruct reordered headers; it simply respected the earlier end named by Total Length.

This article therefore does not treat a pad as a trailer, an IP option or an FCS. Each can appear near an end boundary, but each belongs to a different grammar and carries different authority.

A receiver needed two lengths at the same time

By 2011, RFC 6274 expressed the security consequence of the original boundary. An IP module could be handed a link payload larger than IP Total Length. Legitimate link padding was a usual reason, but malicious activity was also possible.

The document advised allocating the memory buffer according to the payload size reported by the link layer, not according to the smaller IP Total Length. This did not promote the suffix into IP. It prevented the program from receiving a container larger than the storage reserved for it.

Parsing required the opposite discipline. IHL multiplied by four had to be no greater than Total Length. The number of bytes passed by the link had to be at least Total Length. If the outer payload was shorter than the enclosed IP claim, the packet should be dropped and the event logged.

The resulting relation is asymmetric:

IHL × 4 <= IP Total Length <= link-layer payload size

Equality at the first boundary is possible for a datagram with no IP payload. Equality at the second is possible when no padding remains visible. Neither equality is mandatory. What is mandatory is that the inner object fit inside its container.

Meaningless to IP did not mean empty of information

The zero requirement was also a confidentiality control. In January 2003, CERT/CC Vulnerability Note VU#412115 reported that many network device drivers reused old frame-buffer data to pad short frames instead of writing null octets. Depending on the implementation, the exposed material could come from kernel memory, static driver memory or a hardware buffer.

The leaked bytes did not become valid IP payload. A correct IP parser would still stop at Total Length. But a peer observing the Ethernet frame could read them. The protocol had denied the suffix semantic membership, not physical visibility.

This is the sharpest test of the 1984 design. The layer that creates padding owns what it emits even when the next layer refuses to interpret it. Clearing the suffix is not cosmetic conformance. It prevents a carrier requirement from turning unrelated memory into network output.

CERT's record does not prove that every driver was vulnerable. Its vendor material distinguishes affected, not-affected and unknown systems. The warranted historical claim is narrower: the failure occurred across reported implementations, and stale padding created a remote information-disclosure mechanism.

Sources