Network Working Group C. Perkins
Request for Comments: 2004 IBM
Category: Standards Track October 1996
Minimal Encapsulation within IP
1. Introduction
This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than "conventional" IP encapsulation [4] that adds a second IP header to each encapsulated 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 by the (network part of the) IP Destination Address field in the original IP header. The process 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 the "endpoints" of the tunnel; the encapsulator node is refered to as the "entry point" of the tunnel, and the decapsulator node is refered to as the "exit point" of the tunnel.
Perkins Standards Track [Page 1]
RFC 2004 Minimal Encapsulation for IP October 1996 2. MotivationThe Mobile IP working group has specified the use of encapsulation as a way to deliver packets from a mobile node's "home network" to an agent that can deliver datagrams locally by conventional means to the mobile node at its current location away from home [5]. The use of encapsulation may also be indicated 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.
3. Minimal Encapsulation
A minimal forwarding header is defined for datagrams which are not fragmented prior to encapsulation. Use of this encapsulating method is optional. Minimal encapsulation MUST NOT be used when an original datagram is already fragmented, since there is no room in the minimal forwarding header to store fragmentation information. To encapsulate an IP datagram using minimal encapsulation, the minimal forwarding header is inserted into the datagram, as follows:
+---------------------------+ +---------------------------+
| | | |
| IP Header | | Modified IP Header |
| | | |
+---------------------------+ ====> +---------------------------+
| | | Minimal Forwarding Header |
| | +---------------------------+
| IP Payload | | |
| | | |
| | | IP Payload |
+---------------------------+ | |
| |
+---------------------------+
Perkins Standards Track [Page 2]
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.
Perkins Standards Track [Page 3]
RFC 2004 Minimal Encapsulation for IP October 1996
The format of the minimal forwarding header is as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |S| reserved | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (if present) Original Source Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol
Perkins Standards Track [Page 4]
RFC 2004 Minimal Encapsulation for IP October 1996
The encapsulator may use existing IP mechanisms appropriate for delivery of the encapsulated payload to the tunnel exit point. In particular, use of IP options are allowed, and use of fragmentation is allowed unless the "Don't Fragment" bit is set in the IP header. This restriction on fragmentation is required so that nodes employing Path MTU Discovery [3] can obtain the information they seek.
4. Routing Failures
The use of any encapsulation method for routing purposes brings with it increased susceptibility to routing loops. To cut down the danger, a router should follow the same procedures outlined in [4].
5. ICMP Messages from within the Tunnel
ICMP messages are to be handled as specified in [4], including the maintenance of tunnel "soft state".
6. Security Considerations
Security considerations are not addressed in this document, but are generally similar to those outlined in [4].
7. Acknowledgements
The original text for much of Section 3 was taken from the Mobile IP draft [1]. Thanks to David Johnson for improving consistency and making many other improvements to the draft.
Perkins Standards Track [Page 5]
RFC 2004 Minimal Encapsulation for IP October 1996
References