Minimal Encapsulation within IP
Extracted elements (15)
Minimal encapsulation was designed to save overhead compared to conventional IP-in-IP encapsulation by avoiding the duplication of several fields (Protocol, Source/Destination Address, etc.) that would otherwise appear in a redundant inner IP header.
The minimal forwarding header is inserted between the (modified) outer IP header and the original IP payload rather than prepending a full second IP header, enabling the original transport header and data to remain unmodified while still redirecting delivery.
Unlike IP-in-IP encapsulation (RFC 2003), the TTL field is not modified during minimal encapsulation. This means hops within the tunnel are visible to tools such as traceroute, and the encapsulator decrements TTL only as a side effect of normal IP forwarding.
ICMP messages generated from within a minimal encapsulation tunnel are to be handled as specified in RFC 2003, including the maintenance of tunnel 'soft state'.
To reduce the danger of routing loops introduced by encapsulation-based routing, a router using minimal encapsulation should follow the same anti-loop procedures outlined in RFC 2003 (IP Encapsulation within IP).
Fragmentation of the encapsulated datagram is allowed by the encapsulator unless the 'Don't Fragment' (DF) bit is set in the IP header; this restriction is required so that nodes employing Path MTU Discovery (RFC 1191) can obtain the information they seek.
Minimal encapsulation MUST NOT be used when an original datagram is already fragmented, because there is no room in the minimal forwarding header to store fragmentation information.
Decapsulation restores the Protocol, Destination Address, and (if S=1) Source Address fields from the minimal forwarding header back into the IP header, removes the forwarding header, decrements Total Length by the forwarding header size, and recomputes the IP Header Checksum.
During encapsulation the original IP header is modified in-place: Protocol field is replaced with 55 (minimal encapsulation), Destination Address is replaced with the tunnel exit point address, Source Address is replaced with the encapsulator's address if the encapsulator is not the original source, Total Length is incremented by 8 or 12 octets, and Header Checksum is recomputed.
Protocol number 55 is assigned to identify the minimal encapsulation protocol in the IP Protocol field of the encapsulating datagram.
The encapsulator may use existing IP mechanisms for delivery to the tunnel exit point, including IP options and fragmentation (subject to the DF-bit constraint), making minimal encapsulation compatible with standard IP forwarding infrastructure.
The Original Source Address Present (S) bit controls both header size and semantics: S=0 means the original source address field is absent and the header is 8 octets; S=1 means the field is present and the header is 12 octets, carrying the original source IP address.
Security considerations are not addressed in detail in this document; they are described as generally similar to those outlined for IP-in-IP encapsulation in RFC 2003.
The Header Checksum in the minimal forwarding header is the 16-bit one's complement of the one's complement sum of all 16-bit words in the minimal forwarding header only; the IP header and IP payload are excluded from this checksum computation.
The minimal forwarding header consists of: Protocol (8 bits, copied from original IP header), S bit (1 bit, Original Source Address Present flag), reserved (7 bits, sent as zero), Header Checksum (16 bits, one's complement), Original Destination Address (32 bits), and optional Original Source Address (32 bits if S=1). Total size is 8 octets (S=0) or 12 octets (S=1).