RFC 2003 (rfc2003) - Page 3 of 14
IP Encapsulation within IP
Alternative Format: Original Text Document
RFC 2003 IP-within-IP October 1996
- Encapsulation cannot be used unless it is known in advance that
the node at the tunnel exit point can decapsulate 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.
3. IP in IP Encapsulation
To encapsulate an IP datagram using IP in IP encapsulation, an outer
IP header [10] is inserted before the datagram's existing IP header,
as follows:
+---------------------------+
| |
| Outer IP Header |
| |
+---------------------------+ +---------------------------+
| | | |
| IP Header | | IP Header |
| | | |
+---------------------------+ ====> +---------------------------+
| | | |
| | | |
| IP Payload | | IP Payload |
| | | |
| | | |
+---------------------------+ +---------------------------+
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 [1] 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.
Perkins Standards Track