An IP datagram may be encapsulated (carried as payload) within an IP datagram.  Encapsulation is suggested as a means to alter the normal IP routing for datagrams,

 by delivering them to an intermediate destination that would otherwise not be selected based on the (network part of the) IP Destination Address field in the original IP header.  
Once the encapsulated datagram arrives at this intermediate destination node,
It is decapsulated, yielding the original IP datagram, which is then delivered to the destination indicated by the original Destination Address field.
This use of encapsulation and decapsulation of a datagram is frequently referred to as "tunneling" the datagram, and the encapsulator and decapsulator are then

considered to be the  "endpoints" of the tunnel. In the most general tunneling case we have


      Source ---> encapsulator --------> decapsulator ---> destination

With the source, encapsulator, decapsulator, and destination being separate nodes.  The encapsulator node is considered the "entry point" of the tunnel, and the

decapsulator node is considered the "exit point" of the tunnel.

There in general may be multiple source-destination pairs using the same tunnel between the encapsulator and decapsulator.

IP in IP Encapsulation:

To encapsulate an IP datagram using IP in IP encapsulation, an outer IP header is inserted before the datagrams existing IP header.
The outer IP header Source Address and Destination Address identify the "endpoints" of the tunnel.  The inner IP header Source Address and Destination Addresses

 identify the original sender and recipient of the datagram, respectively.

The encapsulator, except to decrement the TTL (time to live), does not change the inner IP header and remains unchanged during its delivery to the tunnel exit point.

 No change to IP options in the inner header occurs during delivery of the encapsulated datagram through the tunnel.

If need be, other protocol headers such as the IP Authentication header may be inserted between the outer IP header

 and the inner IP header.  Note that the security options of the inner IP header MAY affect the choice of security options for the encapsulating (outer) IP header.

IP Header Fields and Handling

The encapsulator sets the fields in the outer IP header as follows:

Version: The value is always 4, in the encapsulation header

IHL:  The Internet Header Length (IHL) is the length of the outer IP header measured in 32-bit words.
TOS: The Type of Service (TOS) is copied from the inner IP header.
Total Length: The Total Length measures the length of the entire encapsulated
IP datagram, including the outer IP header, the inner IP header, and its payload.
Identification, Flags, Fragment Offset:
These three fields are set as specified in [10].  However, if the "Don't Fragment" bit is set in the inner IP header, it MUST be set in the outer IP header; if the "Don't Fragment"

bit is not set in the inner IP header, it MAY be set in the outer IP header, as described in Section 5.1.
Time to Live: The Time To Live (TTL) field in the outer IP header is set to a
Value appropriates for delivery of the encapsulated datagram to the tunnel exit point.
Protocol: The value is always 4, in the encapsulation header
Header Checksum:
The Internet Header checksum of the outer IP header.
Source Address: 
The IP address of the encapsulator, that is, the tunnel entry point.
Destination Address: 
The IP address of the decapsulator, that is, the tunnel exit point.

Technical Advantage:

    -  There are unsolved security problems associated with the use of the IP source routing options.

    -  Current Internet routers exhibit performance problems when forwarding datagrams that contain IP options, including the IP source routing options.

    -  Many current Internet nodes process IP source routing options incorrectly.

    -  Firewalls may exclude IP source-routed datagrams.

    -  Insertion of an IP source route option may complicate the processing of authentication information by the source and/or destination of a datagram, depending on

       how the authentication is specified to be performed.

    -  It is considered impolite for intermediate routers to make modifications to datagrams, which they did not originate.

Technical Disadvantage:

    -  Encapsulated datagrams typically are larger than source routed datagrams.

    -  Encapsulation cannot be used unless it is known in advance that the node at the tunnel exit point cans decapsulated the datagram.

Since the majority of Internet nodes today do not perform well when IP loose source route options are used, the second technical disadvantage of encapsulation is not

as serious as it might seem at first.

Congestion:

An encapsulator might receive indications of congestion from the tunnel, for example, by receiving ICMP Source Quench messages from nodes within the tunnel.

  In addition, certain link layers and various protocols not related to the Internet suite of protocols might provide such indications in the form of a Congestion flag.

The encapsulator SHOULD reflect conditions of congestion in its "soft state" for the tunnel, and when subsequently forwarding datagrams into the tunnel, the encapsulator

 SHOULD use appropriate means for controlling congestion; However, the encapsulator SHOULD NOT send ICMP Source Quench messages to the original sender of the

 unencapsulated datagram.

Security Considerations

 IP encapsulation potentially reduces the security of the Internet, and care needs to be taken in the implementation and deployment of IP encapsulation.  For example,

IP encapsulation makes it difficult for border routers to filter datagrams based on header fields.  In particular, the original values of the Source Address, Destination Address,

 and Protocol fields in the IP header, and the port numbers 
Used in any transport header within the datagram, are not located in their normal positions within the datagram after encapsulation.
Since any IP datagram can be encapsulated and passed through a tunnel, such filtering border routers need to carefully examine all datagrams.

Application:

- The use of encapsulation is desirable whenever the source (or an intermediate router) of an IP datagram must influence the route by which a datagram is to be delivered to its ultimate destination.

- Other possible applications of encapsulation include multicasting, preferential billing, choice of routes with selected security attributes, and general policy routing.