Summary

  • RFC 1241 put an unmodified “Clear Datagram” inside an outer IP header and an eight-octet protocol header, then routed it through a separate Encapsulation Space.
  • Its 32-bit Flow IDs were local rather than global, and a higher layer—not the protocol—had to create and maintain the mappings that made forwarding and error return possible.
  • An ICMP error from inside the tunnel quoted the outer header and the complete encapsulation header, but none of the Clear Datagram. Outer failure evidence could therefore lose the original cause.

Transparency created a second place where truth had to live

Published in July 1991, RFC 1241 proposed an Experimental Internet encapsulation protocol. Robert Woodburn and David Mills gave its two worlds deliberate names. The packet before encapsulation was the Clear Datagram, living in User Space. The outer addresses and routing belonged to an Encapsulation Space. An encapsulator mapped the clear packet into that second space; a decapsulator removed the wrapper and returned the original packet to ordinary IP forwarding.

The motivation was practical. Encapsulation could detour around a routing failure, a broken gateway or an entire domain. It could support experiments whose routing logic should not require every source host to learn a new topology. Unlike source routing, the sender did not have to name the intervening path. Unlike a replacement IP design, the scheme could travel inside the installed IP network.

That was the intended transparency: the source could know nothing about the tunnel. Yet ignorance at the source meant knowledge had to move elsewhere. The encapsulator had to decide which clear packets entered which tunnel. The decapsulator had to know where they went next. If a flow crossed several encapsulator/decapsulator pairs, every pair needed enough local state to keep the same logical path intact.

RFC 1241 called that path a Flow. Its Flow ID was 32 bits, but it was unique only within one encapsulator or decapsulator. It was explicitly not a global identifier. The same Flow could have a different number at the next hop. Returning an error therefore required the address and local Flow ID of the previous encapsulator, followed by another translation at the next step backward.

The protocol did not define how those tables were built or kept current. A higher-layer entity owned them; the memo even suggested that ASCII files could be sufficient in an experimental setting. A successful lookup consequently proved a narrow fact: this node had a matching local entry at that moment. It did not prove that the entry was fresh, that the next node used the intended mapping or that the reverse chain needed for an error still existed.

The wrapper changed the packet it was meant to hide

The encapsulation header contained a new outer IP header followed by an eight-octet protocol header. The latter carried a version, message type, reason code, checksum and Flow ID. The Clear Datagram followed it unchanged. “Unchanged,” however, described the inner bytes, not the packet's treatment by the network.

Most fields in the inner IP header were ignored when the outer header was built. Outer source and destination became the encapsulator and decapsulator. Precedence and quality-of-service bits were copied. Timestamp, record-route and source-route options were not. The inner TTL was not copied, although ordinary forwarding had to decrement it before encapsulation; a decapsulator that bypassed normal IP forwarding also inherited that duty before sending the packet into another Flow.

Fragmentation exposed the deeper cost. The new headers made the outer datagram larger. A clear packet that fit the source interface's MTU could become too large after encapsulation. RFC 1241 allowed outer IP fragmentation, but noted that fragmentation was inefficient. If the encapsulator prohibited it, the effective MTU of the encapsulation path became smaller and the source needed a meaningful ICMP response.

Classification could split too. The mapping table was allowed to inspect TCP ports or even distinguish a connection. If a User Space gateway had already fragmented the IP datagram, only the first fragment carried the TCP header. A port-based rule could match that first fragment while the remaining fragments exposed only IP fields. The memo did not claim a measured failure; it identified why a classification rule that looked exact on a complete header ceased to be exact across the packet's fragments.

RFC 1191, published the previous year, had made the feedback loop explicit for Path MTU Discovery: set Don't Fragment, receive an ICMP “fragmentation needed” message, then lower the assumed path MTU. RFC 1241 could not simply copy that loop through the wrapper. The source of the outer packet was the encapsulator, so the network quite correctly returned the error there.

ICMP brought back the envelope and discarded the letter

The decisive passage appears in RFC 1241's appendix on ICMP. Under RFC 792, an ICMP error carried the offending IP header and at least the first 64 bits of data after it. For RFC 1241, those 64 bits were precisely the eight-octet Encapsulation Protocol Header. The quotation stopped before the Clear Datagram began.

The encapsulator could see which outer destination and local Flow had encountered trouble. It could not see the original inner IP header, the original source or any TCP header from the failed packet. Reconstructing the exact Clear Header from the Flow ID was impossible because several different headers could map to the same Flow. The packet had been transparent on the way forward by hiding the tunnel from its source. The resulting error was opaque on the way back because the tunnel had hidden the source packet from its own diagnostic quotation.

RFC 1241 separated two built-in error paths. An unknown Flow ID could be reported to the previous encapsulator and to the higher-layer table manager. Other ICMP messages could be wrapped and carried backward along the Flow, with the Flow ID translated at each hop. But moving an ICMP object backward did not regenerate the missing inner bytes. And if an error occurred while sending an error, the protocol generated no further error.

The memo considered compromises. An ICMP event could mark a Flow so that the next matching clear packet caused the encapsulator to originate a new error toward the source. That made the next packet a probe for the previous packet's condition. It was not one-to-one attribution, and RFC 1241 judged the approach probably safe only for some message classes. A later notification could describe current Flow state; it could not serve as a byte-for-byte receipt for the earlier failure.

Later tunnel documents kept the observability problem visible

Later RFCs should not be read as proof that RFC 1241 was widely deployed or as a simple linear succession. They do show that the boundary it described remained structural. RFC 1853 documented IP-in-IP practice in 1995, distinguished its lack of a special glue header from RFC 1241, and acknowledged that its organization and some text were derived from the earlier memo.

RFC 2003, a 1996 standards-track treatment of IP encapsulation within IP, stated the same diagnostic constraint: eight quoted octets were not enough to include the inner IP header. Its answer included tunnel soft state for MTU, TTL and reachability, so later packets could be checked against what the encapsulator had learned. That state made better error generation possible in many cases, but it still did not turn every outer error into a one-to-one record of an inner packet.

RFC 4459 later described packet-size handling in network tunnels as a common, non-trivial problem. Fragment outside, signal a lower MTU, guarantee spare capacity or fragment the inner packet: each choice moves cost and evidence to a different place. The enduring lesson is not that one tunnel format won. It is that adding a transparent layer creates a new authority over size, identity and failure interpretation.

What can be proved must remain smaller than what can be inferred

From RFC 1241, an observer can prove the format of the proposed wrapper, the local scope of Flow IDs, the required backward translation and the loss of the Clear Datagram from the ordinary ICMP quotation. The document cannot prove that a named implementation used the protocol, that a tunnel carried production traffic, that an inner packet arrived, or that an original sender received an equivalent error.

Operational records have to preserve both worlds. A packet capture at the tunnel entrance can bind a Clear Header to an outer header and local Flow ID. A capture at the exit can show decapsulation. A versioned table snapshot can show how a node intended to translate the Flow. An ICMP capture can show the exact quoted bytes. Only a correlated chain can support a claim about the inner packet's outcome, and missing links must remain missing rather than being filled by the word “tunnel.”

The historical importance of RFC 1241 lies in that restraint. It proposed a virtual routing surface, then documented where the surface stopped being transparent. The tunnel could carry the packet. The error could carry the Flow. Neither fact, alone, carried the original question home.

Sources