Minimal Encapsulation within IP
RFC 2004

 
Document Type RFC - Proposed Standard (October 1996; Errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2004 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         C. Perkins
Request for Comments: 2004                                           IBM
Category: Standards Track                                   October 1996

                    Minimal Encapsulation within IP

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   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 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.  Encapsulation may be serve a variety of
   purposes, such as delivery of a datagram to a mobile node using
   Mobile 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. Motivation

   The 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.

   See [4] for a discussion concerning the advantages of encapsulation
   versus use of the IP loose source routing option.  Using IP headers
   to encapsulate IP datagrams requires the unnecessary duplication of
   several fields within the inner IP header; it is possible to save
   some additional space by specifying a new encapsulation mechanism
   that eliminates the duplication.  The scheme outlined here comes from
   the Mobile IP Working Group (in earlier Internet Drafts), and is
   similar to that which had been defined in [2].

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        |       |                           |
     |                           |       |                           |
Show full document text