Description

Glossary

RFCs

Publications

Obsolete RFCs

Description:

This protocol provides a mechanism to encapsulate an IP header with an outer IP header for tunneling.

RFC 1853:

The encapsulation technique is fairly simple. An outer IP header is added before the original IP header. Between them are any other headers for the path, such as security headers specific to the tunnel configuration.

The outer IP header Source and Destination identify the "endpoints" of the tunnel. The inner IP header Source and Destination identify the original sender and recipient of the datagram.

Each header chains to the next using IP Protocol values.

RFC 2003, pages 1, 2 and 3:

This document specifies a method by which 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.

To encapsulate an IP datagram using IP in IP encapsulation, an outer IP header is inserted before the datagram's 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 inner IP header is not changed by the encapsulator, except to decrement the TTL as noted below, 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.

Inner IPv4 header:

Version. 4 bits. Always set to 4.
IPv4 version number.

IHL, Internet Header Length. 4 bits.
The length of the outer IP header measured in 32-bit words.

TOS, Type of Service. 8 bits.
The Type of Service (TOS) is copied from the inner IP header.

Optionally, another TOS may be used between cooperating peers. This is in keeping with the transparency principle that if the user was expecting a given level of service, then the tunnel should provide the same service. However, some tunnels may be constructed specifically to provide a different level of service as a matter of policy.

TOS specifies the parameters for the type of service requested. The parameters may be utilized by networks to define the handling of the datagram during transport. The M bit was added to this field in RFC 1349.

Precedence. 3 bits.

Value	Description
0	Routine.
1	Priority.
2	Immediate.
3	Flash.
4	Flash override.
5	CRITIC/ECP.
6	Internetwork control.
7	Network control.

D. 1 bit.
Minimize delay.

Value	Description
0	Normal delay.
1	Low delay.

T. 1 bit.
Maximize throughput.

Value	Description
0	Normal throughput.
1	High throughput.

R. 1 bit.
Maximize reliability.

Value	Description
0	Normal reliability.
1	High reliability.

M. 1 bit.
Minimize monetary cost.

Value	Description
0	Normal monetary cost.
1	Minimize monetary cost.

Total Length. 16 bits.
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. 16 bits.
A new number is generated for each outer IP header.

The encapsulated datagram may have already been fragmented, and another level of fragmentation may occur due to the tunnel encapsulation. These tunnel fragments will be reassembled by the decapsulator, rather than the final destination.

Flags. 3 bits.

R, Reserved. 1 bit.
This bit is reserved and should be cleared to 0. This unofficial flag has seen experimental use, and while it remains in the inner IP header, does not affect the tunnel.

DF, Don't fragment. 1 bit.
This bit controls the fragmentation of the datagram. This is copied from the inner IP header. This allows the originator to control the level of performance trade offs.

However, if the DF bit is set in the inner IP header, it MUST be set in the outer IP header; if the DF bit is not set in the inner IP header, it MAY be set in the outer IP header.

Value	Description
0	Fragment if necessary.
1	Do not fragment.

MF, More fragments. 1 bit.
This is set as required when fragmenting. The flag is not copied for the same reason that a separate Identification is used.

Value	Description
0	This is the last fragment.
1	More fragments follow this fragment.

Fragment Offset. 13 bits.
Used to direct the reassembly of a fragmented datagram.

TTL, Time to Live. 8 bits.
The default value is specified in the most recent "Assigned Numbers". This ensures that long unanticipated tunnels do not interrupt the flow of datagrams between endpoints.

The inner Time To Live (TTL) field is decremented once before encapsulation, and is not affected by decapsulation.

The Time To Live (TTL) field in the outer IP header is set to a value appropriate for delivery of the encapsulated datagram to the tunnel exit point.

Protocol. 8 bits.
Set to 4. The next header; 4 for the inner IP header, when no intervening tunnel headers are in use.

Header Checksum. 16 bits.
The IP checksum of the outer IP header.

Source Address. 32 bits.
The IP address of the encapsulator, that is, the tunnel entry point.

Destination Address. 32 bits.
The IP address of the decapsulator, that is, the tunnel exit point.

Options. Variable length.
Any options present in the inner IP header are in general NOT copied to the outer IP header. However, new options specific to the tunnel path MAY be added. In particular, any supported types of security options of the inner IP header MAY affect the choice of security options for the outer header. It is not expected that there be a one-to-one mapping of such options to the options or security headers selected for the tunnel.

Padding. Variable length.
Used as a filler to guarantee that the data starts on a 32 bit boundary.

Glossary:

RFCs:

[RFC 1853] IP in IP Tunneling.

• Category: Informational.

[RFC 2003] IP Encapsulation within IP.

• Category: Standards Track.

[RFC 3884] Use of IPsec Transport Mode for Dynamic Routing.

• Category: Informational.

Publications:

Obsolete RFCs:

Description

Glossary

RFCs

Publications

Obsolete RFCs