Summary

  • Trailer encapsulation moved variable higher-level headers behind data within a link packet, giving a suitable receiver an opportunity to exploit page-aligned memory. The receiver reconstructed the normal packet before higher-level processing.
  • Avoiding copies was conditional on the receiver's architecture and costs. Delayed headers also meant buffering the whole packet before using information that another implementation might examine early.
  • Optional use required positive knowledge of the link peer's support. By 1989, host requirements specified per-destination negotiation and required the default to be off when dynamic negotiation was absent.

The awkward bytes before the useful block

Suppose a network receiver can make data available to a program by changing page mappings instead of copying every byte. That possibility depends on where the data begins. A block starting halfway through a memory page is not interchangeable with a block arranged for page-granularity protection and remapping.

Now put a header of variable length before it. Even if the link prefix has a predictable size, the changing higher-level headers keep shifting the useful data. Copying the data into alignment may consume the very work the receiver hoped to avoid.

RFC 893, published in April 1984, described a way around this obstruction. Move the variable headers after the data on the link. The receiving system could then handle the large data block under more favourable alignment conditions and put the smaller headers back where higher-level protocols expected them.

The document described a format used by 4.2BSD UNIX and other systems at the time. It was explicitly informational, not an official ARPA Internet protocol. Its subject was a conditional improvement to a receiving implementation, not a compulsory rearrangement of Internet traffic.

Arrival was not the end of the copying bill

Network data could be copied between a device and memory, or between operating-system and user address spaces. On a suitable virtual-memory architecture, changing page tables offered an alternative to moving the contents again.

RFC 893's discussion normally required page-aligned data and a size that was a multiple of the page size, or filled to a page boundary, under page-granularity protection. It also recognised that the hardware architecture could change the prerequisites. The format did not promise universal zero-copy reception.

Moving headers out of the way made this opportunity easier to exploit. It did not make Ethernet transmit faster, abolish every header copy or prove that the cost of remapping was negligible. The document's VAX example involving 512 data bytes belongs to that architectural setting. It is neither a rule for modern page sizes nor a claim that IP and TCP headers always have a fixed combined length.

This distinction matters because a historical implementation report can easily become a timeless performance claim in retelling. The authors reported benefits for their implementation. This account supplies no new benchmark, percentage improvement or measurement on current hardware.

A tail inside the same packet

The trailer was not a second packet carrying instructions that arrived later. Nor was it a footer appended by an application to a file. It was part of the same link-level packet, with data placed ahead of headers that logically preceded it at the higher layer.

Link-type information identified the special form and allowed the receiver to find the trailer's position. The trailing portion included information about the original protocol and header length, followed by the original higher-level headers. The receiver removed encapsulation-specific material and reconstructed the ordinary header-and-data relationship.

TCP therefore did not acquire a different sequence meaning. An application did not receive permission to consume unprocessed data merely because those bytes had arrived earlier on the wire. Correct reconstruction kept the local rearrangement out of the higher protocols' view.

The baseline in RFC 894, also published in April 1984, was straightforward IP over Ethernet: the IP header was followed immediately by IP data. A host able to read that arrangement was not automatically able to interpret the alternative one. Carrying the same protocol did not eliminate the difference in representation.

Nor did rearrangement enlarge the link. The verified technical erratum 570 corrects RFC 894's description of 1500 octets from a minimum to a maximum. Padding to Ethernet's minimum data length is separately excluded from the IP total length. Memory alignment, padding and link capacity should not be collapsed into one number.

The price of finding the header late

RFC 893 set out conditions for the bargain. The receiver had to be willing and able to use trailers. Achieving alignment should not cost more than it saved. The trailing headers should be small relative to the data, and avoided copying should be valuable enough to justify additional software complexity.

There was also a timing cost. A receiver had to buffer the whole packet before processing information now located at its end. An implementation that inspected headers early could lose an opportunity to reject unwanted traffic or choose resources before the entire packet arrived.

The document acknowledged delayed type recognition as a valid criticism. Its answer was limited: in the DMA case it discussed, the complete packet was already received before that processing began. This explains why the trade could make sense there. It does not establish that all DMA hardware, especially current hardware, has the same reception path.

What looked like a small rearrangement to the sender could therefore have different consequences for different recipients. One might avoid substantial copying. Another might inherit extra buffering or complexity without a comparable gain. Receiver consent was part of the engineering because the receiver owned that side of the calculation.

An interface could not speak for every neighbour

RFC 894 allowed consenting systems on the same Ethernet to use trailers, while requiring no host to implement them. A sender needed positive knowledge that its recipient could interpret the form. The ordinary encapsulation remained the compatible baseline.

The 1984 descriptions exposed a practical limitation. The then-described 4.2BSD choice was made per interface at boot: use trailers with the required cooperation on the shared medium, or never transmit them through that interface. A per-host negotiation using ARP was discussed as a possible or expected improvement.

By October 1989, RFC 1122, section 2.3.1, specified a more tightly bounded arrangement. Both entities in the link exchange, host or gateway, had to be verified as supporting trailers. If there was no dynamic per-destination negotiation, the default configuration had to disable their use.

These documents show a described interface-wide assumption followed by a specified per-destination exchange. They do not establish the first shipping date of every implementation, or show that all BSD releases remained unchanged until 1989. The defensible historical comparison is between the documented requirements and mechanisms.

Address knowledge was not format knowledge

ARP's ordinary success did not answer the new compatibility question. RFC 826 mapped a protocol address to a hardware address on a selected link, after the next-hop decision. Knowing where to send a frame did not prove that the neighbour could interpret every optional form it might contain.

The fields also had distinct jobs. The outer Ethernet type indicating ARP, the protocol-address-space field inside ARP and the operation code for request or reply were not one interchangeable type value. Trailer negotiation depended on keeping those meanings separate.

The implementation described in RFC 1122 left the ordinary IP ARP exchange intact. A system willing to receive trailers sent an additional Trailer ARP reply, using the ordinary reply format but identifying the trailer protocol within ARP. This did not replace the basic IP reply and did not require a preceding Trailer ARP request.

Both roles could announce reception capability. A recipient of a normal ARP request could send the extra reply alongside its IP reply. The original requester could announce its own ability when the matching normal IP reply arrived. Each announcement described its sender as a potential receiver of trailers.

A host configured to use the form could record the neighbour's capability, for example as a flag in an ARP entry. This was not an application delivery receipt, a performance guarantee or cryptographic authentication. It was a particular piece of link-peer knowledge.

The gateway context makes that scope important. RFC 1009, published in June 1987, explains proxy ARP cases in which a gateway answers with its own interface address for a reachable off-link destination. The link peer learned through that exchange need not be the application's final correspondent. Its capability could not certify the entire route.

A reply needed an unfinished question

An extra reply introduced a small but consequential state problem. A misbehaving host could answer a Trailer ARP reply with an ordinary IP ARP reply. If its neighbour answered every IP reply with another trailer announcement, replies could keep generating replies.

RFC 1122 limited that branch of the exchange. A Trailer ARP reply sent in response to an IP reply should occur only when the latter answered an outstanding request: the hardware address was still unresolved before processing that reply. Sending the extra announcement alongside a normal answer to an incoming request was a separate permitted case.

The guard did not require an invented retry count, timer or authentication scheme. It depended on local history. Was there still a question that this response resolved? Once the work was no longer outstanding, an incoming reply did not by itself justify continuing the conversation.

This was a second boundary on inference. Ordinary ARP did not prove trailer support, and an arbitrary IP ARP reply did not prove that another trailer reply was needed. The implementation had to preserve the reasons behind its actions, not merely recognise familiar packet shapes.

Some traffic could conceal the disagreement

RFC 1122 warned that trailers were selected only for packets with particular size attributes, typically a small fraction in its discussion. A mismatch could therefore pass some packets while blackholing others. A short successful exchange might not test the special receiving path at all.

This is not a claim that all large packets failed, or that any size-related loss demonstrates trailer encapsulation. Evidence of the actual format and the peer's state would be needed. The historical failure mechanism was conditional selection of a representation the recipient could not read, not necessarily an MTU shortage.

The warning completes the case for per-peer knowledge. A coarse observation that a neighbour was reachable could conceal a fine-grained incompatibility. The exceptional format needed its own evidence, even when the ordinary network appeared to work.