RFC 1853 (rfc1853) - Page 3 of 8
IP in IP Tunneling
Alternative Format: Original Text Document
RFC 1853 IP Tunnelling October 1995
2. Encapsulation
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-1700].
+---------------------------+
| Outer IP Header |
+---------------------------+
| Tunnel Headers |
+---------------------------+ +---------------------------+
| IP Header | | Inner IP Header |
+---------------------------+ ====> +---------------------------+
| | | |
| IP Payload | | IP Payload |
| | | |
+---------------------------+ +---------------------------+
The format of IP headers is described in [RFC-791].
Type Of Service 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.
Identification 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.
Reserved
ignored (set to zero).
Simpson Informational
