Keep historical trailers behind a compatibility gate
05RFC 894 also records an optional historical trailer encapsulation used by cooperating systems. It changes link-level ordering and requires positive knowledge of receiver support.
Separate case: the recipient’s trailer support is positively known and both peers consent. The optional compatibility gate allows the alternative; it does not make trailer implementation mandatory.
Source for this drawing: RFC 894 · Read RFC source: Trailer Formats (unnumbered) ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A historical optional format must not be sent to a peer whose support is unknown.
- Ordinary RFC 894 framing puts the IP header before the IP data. A trailer encapsulation is a different link format, described separately in RFC 893.
- RFC 894 says no host is required to implement trailers, and no trailer-format datagram should be sent unless the sender positively knows the receiver can interpret it.
- Consent and positive knowledge allow cooperating peers to use the historical alternative; they do not require its use. Normal encapsulation remains available.
- The word trailer here is not Ethernet padding or the frame’s FCS. This is a historical compatibility explanation, not advice to enable an old 4.2BSD optimization today.
The order diagrams are schematic and omit the trailer prefix fields; there is no trailer-wire serializer or performance benchmark. RFC 893 explains the original memory-alignment motivation. No formal update/obsoletion relationship is inferred from a companion reference.
Read the RFC section ↗