Summary

  • RFC 3378 recorded EtherIP, a deliberately tiny mechanism that placed an Ethernet frame behind a 16-bit header and carried it in an IPv4 datagram using protocol number 97.
  • The header carried no peer authentication, inner integrity check, sequencing, tunnel control or loop prevention. Successful decapsulation proved that bytes reached a gateway, not that one safe LAN now spanned the IP path.

Ethernet normally encourages local reasoning. A destination address appears on a segment, a frame check sequence protects one link transmission, and protocols designed for nearby peers may assume a boundary enforced by switches, cabling and a firewall. EtherIP allowed an operator to preserve the frame while removing that locality.

RFC 3378, published in September 2002, documented a protocol designed and implemented in 1991 and 1992. Its status was Informational. The authors described it for historical context and to explain IANA’s assignment of IP protocol number 97. They explicitly pointed readers toward standards-track work from the L2 tunneling and pseudowire communities instead of presenting EtherIP as the preferred future.

The format was almost austere. An IPv4 header identified protocol 97. A 16-bit EtherIP header followed: four bits of version, set to three, and twelve reserved bits, set to zero. The complete Ethernet or IEEE 802.3 frame came next, except for its frame check sequence. A receiver discarded packets with the wrong version or nonzero reserved bits, extracted the frame, calculated a fresh FCS and transmitted it on the remote LAN.

Those checks established syntax, not trust. Version three and twelve zeros did not identify the sender. They did not authorize a source MAC address, verify the remote segment or explain why a particular frame should cross. EtherIP had no native tunnel identifier, sequence space, replay signal, peer negotiation or inner-frame integrity field.

The missing FCS created a subtle evidence break. The original Ethernet FCS ended at the ingress. RFC 3378 noted that the IPv4 header checksum did not protect the encapsulated frame and expected a higher-layer protocol inside the frame to provide integrity. At egress, the gateway calculated a new FCS for the new local transmission. That new check could be perfectly valid even if corruption had occurred before it was calculated. It was evidence about the final link, not a receipt for the entire tunnel.

An end station could decide which of its own frames to tunnel. A bridge-like station could listen promiscuously to a LAN, inspect source or destination addresses, EtherType and sometimes VLAN information, and choose frames for encapsulation. If the destination was local, or a local router could handle the layer-three protocol, tunneling was unnecessary. These rules were environmental policy, not information encoded by the tiny header.

The sender also needed the IP address of the remote EtherIP station, usually derived somehow from the destination MAC address. RFC 3378 did not define a universal discovery or mapping service. A successfully formatted packet therefore depended on prior configuration that answered two questions the wire format could not: which frames belong in the tunnel, and which remote gateway represents their destination.

Bridge-like operation exposed the largest hazard. If several gateways captured and reinjected the same traffic, one MAC frame could circulate indefinitely. Broadcast and multicast destination addresses made the danger especially acute. The RFC said the topology needed to be restricted to a tree, then left construction of that tree to the human configuring the stations. EtherIP did not run a spanning-tree protocol or carry a hop count that would rescue a bad arrangement.

This made a loop a control-plane failure expressed as data-plane repetition. Every gateway could be following its local rule correctly while the combined rules returned the frame to an earlier segment. Encapsulation success would make the failure faster, not safer. Packet counters might rise at every hop while no application made useful progress.

Security boundaries moved as well. The document warned that a firewall allowing EtherIP could enable arbitrary communications. A protocol whose weak protection was tolerable among machines believed to share one local segment could become exposed when that segment was emulated across an IP network. RFC 3378 cited the contemporary VRRP specification as an example of local assumptions that became more dangerous at distance.

IPsec was offered as one possible protection for the outer datagrams. RFC 2401 described the period architecture, and RFC 4301 later replaced it. Outer protection could authenticate peers and protect traffic in transit according to policy. It still could not decide whether the capture rule selected the right frame, whether the remote bridge should inject it, whether a loop-free tree existed, or whether the receiving application accepted the payload.

Other tunneling documents clarify what EtherIP omitted. RFC 2003 described IP within IP. RFC 2784 specified GRE with a more general encapsulation model. RFC 3931 later gave L2TPv3 an explicit control connection and sessions, while RFC 3985 set a pseudowire architecture and RFC 4448 specified Ethernet pseudowires. These are historical comparisons, not retroactive upgrades to EtherIP and not proof of any deployment.

RFC 2119’s normative vocabulary must be read within the document’s modest scope. MUST set the header bits or discard invalid values; it did not establish that protocol 97 crossed a firewall, that a peer was trusted or that an operator had built a tree. The IANA registry records the number’s assignment. Registration makes packets interpretable, not necessarily permitted, prevalent or safe.

Lu Heng’s minimum-initial-specification lens explains the design’s attraction: a very small common format could unlock an immediate use without settling a larger architecture. His reality-layers lens shows the audit cost. Frame selection, encapsulation, peer admission, routed carriage, inner integrity, decapsulation, FCS regeneration, remote injection and endpoint outcome are connected stages, not one fact.

EtherIP proved that a frame could be made portable with only sixteen new bits. It also proved how much the frame did not contain. A LAN is more than its frame format: it is topology, administration, trust, timing and a set of local consequences. The tunnel moved the envelope. Everything that made the envelope safe still had to be rebuilt around it.

Sources