RFC 2004 (rfc2004) - Page 3 of 6

Minimal Encapsulation within IP

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