Summary

  • RFC 2003 puts a complete IPv4 datagram behind a new IPv4 header: outer addresses identify the tunnel entry and exit, while inner addresses retain the original communication endpoints.
  • Forwarding into the tunnel spends one unit of inner TTL before encapsulation, while the outer TTL is chosen independently for the path to the exit.
  • DF, tunnel MTU, outer fragmentation, exit reassembly and ICMP translation create separate responsibilities. Seeing Protocol 4 or a successful decapsulation proves neither sender identity nor final delivery.

Two address pairs describe two journeys

RFC 2003 defines a deliberately simple operation. An encapsulator inserts a new IPv4 header before an existing IPv4 datagram. The outer source is an address of the encapsulator; the outer destination is the decapsulator. The old packet remains inside. Its source and destination still identify the original sender and recipient.

This separation is the point of the tunnel. Ordinary routing between entry and exit follows the outer destination, which may be an intermediate node the inner destination would not have selected. Once the exit removes the wrapper, the inner destination governs the remaining journey again. One capture therefore contains two routing statements, not one expanded identity claim.

The outer Protocol value is 4 when the next header is IPv4. RFC 1853 explains the useful contrast with earlier schemes: plain IP-in-IP needs no special glue header. The unadorned inner IP header is simply wrapped by another standard IP header. Protocol 4 declares the payload type. It does not authenticate either header, authorize the inner source or confirm that the decapsulator admitted the packet.

Encapsulation does not stop the inner clock

The inner header remains unchanged while it crosses the tunnel, with one important condition. If the encapsulator is forwarding the datagram, it decrements the inner TTL before wrapping it. If that makes the value zero, it discards the packet and should return ICMP Time Exceeded. It must never encapsulate a datagram whose TTL is zero. If the encapsulator originated the datagram itself, encapsulation alone does not spend that forwarding hop.

The outer TTL is different. The encapsulator chooses a value suitable for reaching the tunnel exit. Decapsulation does not decrement the inner TTL, although ordinary forwarding after decapsulation does. Thus an outer packet with ample TTL says nothing conclusive about the inner packet's remaining budget. The two clocks belong to different paths and processing events.

The narrow RFC 2003 question is who spends each lifetime in an ordinary tunnel. A useful record must preserve the inner TTL before entry, the value after the forwarding decrement, the outer initial TTL, the outer observed TTL and the post-exit forwarding event separately.

DF is inherited in only one direction

The outer header has its own Identification, Flags and Fragment Offset. If inner Don't Fragment is set, outer DF must also be set. If inner DF is clear, the encapsulator may still set outer DF as part of tunnel MTU discovery. The first rule protects the originator's request; the second gives the tunnel operator a separate policy choice.

That choice determines where state accumulates. If the outer datagram fragments, the decapsulator must reassemble those outer fragments before it can expose the inner packet. Buffers, timers and fragment identity now terminate at the tunnel exit. By contrast, if an eligible inner IPv4 datagram is fragmented before encapsulation, each inner fragment can be wrapped and the final destination performs the eventual inner reassembly.

RFC 2003 prefers learning the tunnel MTU and avoiding repeated outer fragmentation. All encapsulators must support Path MTU Discovery soft state for their tunnels. When an interior router reports Datagram Too Big, the encapsulator learns the outer constraint. The useful MTU reported toward an original sender doing PMTU discovery should be the tunnel MTU minus the encapsulating header.

RFC 1191 supplies the underlying IPv4 feedback rule: a router that cannot forward a DF packet returns Destination Unreachable, code 4, with the next-hop MTU. The tunnel complicates the recipient. The interior router sends the error to the outer source—the encapsulator—not directly to the inner source.

If the original sender left DF clear but the encapsulator chose outer DF, RFC 2003 admits an awkward result: there may be nothing sensible to tell the original sender about that particular failure. The encapsulator can keep a copy while probing a larger tunnel MTU, so it can fragment and resend after an error, or it can avoid setting outer DF for configured packet types. This is operational responsibility, not a property conveyed by Protocol 4.

ICMP must cross an interpretation boundary

RFC 2003 does not treat every tunnel ICMP message alike. Network or host unreachable may be relayed when enough information exists. Protocol Unreachable is translated to network or host unreachable because the original sender did not send Protocol 4. Port Unreachable must not be relayed: the outer IP header names no port. Datagram Too Big must be relayed. Redirect and Source Route Failed remain matters for the encapsulator. Tunnel Time Exceeded is reported to the original sender as Host Unreachable.

Parameter Problem can cross the boundary only when it points to a field copied from the inner packet rather than an option inserted by the encapsulator.

The historic RFC 792 quotation requirement exposes the evidentiary gap. An ICMP error needed to return only the outer header and the first eight octets after it—too little to include the inner IPv4 header. The encapsulator may be unable to identify the exact inner datagram from the returned bytes.

RFC 2003 answers with soft state: at least tunnel MTU, tunnel TTL or path length, and exit reachability. ICMP from the tunnel updates that model. A later packet that violates the model may cause an error toward its original sender even while it is still encapsulated and forwarded. The document is explicit that generated errors need not correspond one-to-one with interior failures. Soft state can describe a recent path condition; it is not a forensic receipt for a particular packet.

The field list has not stood still

The 1996 text says the outer TOS is copied from the inner header. RFC 3168 later updated tunnel treatment of the ECN bits inside that octet. A limited-functionality tunnel disables ECN in the outer header; a full-functionality tunnel carries congestion semantics across ingress and egress. Simply discarding an outer congestion mark at the exit would lose a signal intended for the endpoints.

RFC 6864 separately updated RFC 2003's outer IPv4 Identification rule. Required uniqueness now follows whether fragmentation is possible or present, rather than treating the ID as a universally meaningful packet serial number. A diagnostic that correlates unrelated atomic packets by IPv4 ID is making a claim the current specification no longer guarantees.

The IETF Datatracker record lists RFC 2003 as a Proposed Standard and names both updates. That status proves publication and standards history. It does not inventory implementations or show that any observed tunnel follows the full current rule set.

A valid envelope is still not a trusted letter

RFC 2003 warns that encapsulation can reduce security because the original addresses, protocol and transport ports no longer appear in their normal locations for border filtering. It distinguishes trust in the outer source from authentication inside the wrapped packet. A filter may need to inspect both layers and apply an admission relationship at the exit.

The evidence chain should therefore stay modest. A specification proves a rule. A configuration proves intended endpoints and policy. An ingress capture can bind an inner fingerprint to an outer tuple. Outer fragments prove treatment on that observed path. Exit reassembly proves the wrapper was reconstructed. Decapsulation proves local parsing. A post-exit capture proves further forwarding. An application acknowledgement proves something later still.

Lu Heng's Running-Code Primacy keeps publication from impersonating execution. Minimum Initial Specification clarifies why a common format need not decide every future tunnel policy. Reality Layers supplies the final discipline: header, configuration, observation and outcome are related records, not interchangeable proof.

RFC 791 defines the underlying IPv4 fields, while RFC 4459 later confirms that tunnel packet-size handling remained a common, non-trivial problem. Neither turns this article into a census of current products. The safe conclusion is narrower. Protocol 4 tells an observer what envelope to open. Only correlated evidence can say what happened to the letter.

Sources