RFC 2004 (rfc2004) - Page 3 of 6
Minimal Encapsulation within IP
Alternative Format: Original Text Document
RFC 2004 Minimal Encapsulation for IP October 1996
The IP header of the original datagram is modified, and the minimal
forwarding header is inserted into the datagram after the IP header,
followed by the unmodified IP payload of the original datagram (e.g.,
transport header and transport data). No additional IP header is
added to the datagram.
In encapsulating the datagram, the original IP header [6] is modified
as follows:
- The Protocol field in the IP header is replaced by protocol
number 55 for the minimal encapsulation protocol.
- The Destination Address field in the IP header is replaced by the
IP address of the exit point of the tunnel.
- If the encapsulator is not the original source of the datagram,
the Source Address field in the IP header is replaced by the IP
address of the encapsulator.
- The Total Length field in the IP header is incremented by the
size of the minimal forwarding header added to the datagram.
This incremental size is either 12 or 8 octets, depending on
whether or not the Original Source Address Present (S) bit is set
in the forwarding header.
- The Header Checksum field in the IP header is recomputed [6] or
updated to account for the changes in the IP header described
here for encapsulation.
Note that unlike IP-in-IP encapsulation [4], the Time to Live
(TTL) field in the IP header is not modified during encapsulation;
if the encapsulator is forwarding the datagram, it will decrement
the TTL as a result of doing normal IP forwarding. Also, since
the original TTL remains in the IP header after encapsulation,
hops taken by the datagram within the tunnel are visible, for
example, to "traceroute".
Perkins Standards Track