[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 RFC 2004

Internet Engineering Task Force                               C. Perkins
INTERNET DRAFT                                                       IBM
                                                             31 May 1996


                    Minimal Encapsulation within IP
                   draft-ietf-mobileip-minenc-02.txt


Status of This Memo

   This document is a submission by the Mobile IP Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the mobile-ip@SmallWorks.COM mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check
   the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


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.








Perkins                Expires 30 November 1996                 [Page i]

Internet Draft         Minimal Encapsulation for IP          31 May 1996


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.


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.




Perkins                Expires 30 November 1996                 [Page 1]

Internet Draft         Minimal Encapsulation for IP          31 May 1996


   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        |
     +---------------------------+       |                           |
                                         |                           |
                                         +---------------------------+

   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.

   In encapsulating the datagram, the original IP header [6] is modified
   as follows:

    -  The Protocol field in the IP header is replaced by protocol
       number 55 for the minimal encapsulation protocol.

    -  The Destination Address field in the IP header is replaced by the
       IP address of the exit point of the tunnel.

    -  If the encapsulator is not the original source of the datagram,
       the Source Address field in the IP header is replaced by the IP
       address of the encapsulator.

    -  The Total Length field in the IP header is incremented by the
       size of the minimal forwarding header added to the datagram.
       This incremental size is either 12 or 8 octets, depending on
       whether or not the Original Source Address Present (S) bit is set
       in the forwarding header.

    -  The Header Checksum field in the IP header is recomputed [6] or
       updated to account for the changes in the IP header described
       here for encapsulation.






Perkins                Expires 30 November 1996                 [Page 2]

Internet Draft         Minimal Encapsulation for IP          31 May 1996


   The format of the minimal forwarding header is as follows:

    0                   1                   2                   3
    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

         Copied from the Protocol field in the original IP header.

      Original Source Address Present (S)

            0  The Original Source Address field is not present.  The
               length of the minimal tunneling header in this case is
               8 octets.

            1  The Original Source Address field is present.  The
               length of the minimal tunneling header in this case is
               12 octets.

      reserved

         Sent as zero; ignored on reception.

      Header Checksum

         The 16-bit one's complement of the one's complement sum of all
         16-bit words in the minimal forwarding header.  For purposes of
         computing the checksum, the value of the checksum field is 0.
         The IP header and IP payload (after the minimal forwarding
         header) are not included in this checksum computation.

      Original Destination Address

         Copied from the Destination Address field in the original IP
         header.

      Original Source Address

         Copied from the Source Address field in the original IP header.
         This field is present only if the Original Source Address
         Present (S) bit is set.



Perkins                Expires 30 November 1996                 [Page 3]

Internet Draft         Minimal Encapsulation for IP          31 May 1996


   When decapsulating a datagram, the fields in the minimal forwarding
   header are restored to the IP header, and the forwarding header is
   removed from the datagram.  In addition, the Total Length field in
   the IP header is decremented by the size of the minimal forwarding
   header removed from the datagram, and the Header Checksum field in
   the IP header is recomputed [6] or updated to account for the changes
   to the IP header described here for decapsulation.

   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                Expires 30 November 1996                 [Page 4]

Internet Draft         Minimal Encapsulation for IP          31 May 1996


References

   [1] IPv4 Mobility Support.  ietf-draft-mobileip-protocol-10.txt --
       outdated draft, May 1995.

   [2] David B. Johnson.  Scalable and Robust Internetwork Routing
       for Mobile Hosts.  In Proceedings of the 14th International
       Conference on Distributed Computing Systems, pages 2--11, June
       1994.

   [3] J. Mogul and S. Deering.  Path MTU Discovery.  RFC 1191, November
       1990.

   [4] Charles Perkins.  IP Encapsulation within IP.
       draft-ietf-ip4inip4-01.txt (work in progress), May 1996.

   [5] C. Perkins, Editor.  IPv4 Mobility Support.
       ietf-draft-mobileip-protocol-17.txt (work in progress), May 1996.

   [6] J. B. Postel, Editor.  Internet Protocol.  RFC 791, September
       1981.


Author's Address

   Questions about this memo can be directed to:

          Charles Perkins
          Room H3-D34
          T. J. Watson Research Center
          IBM Corporation
          30 Saw Mill River Rd.
          Hawthorne, NY  10532

          Work:   +1-914-784-7350
          Fax:    +1-914-784-6205
          E-mail: perk@watson.ibm.com

   The working group can be contacted via the current chair:

          Jim Solomon
          Motorola, Inc.
          1301 E. Algonquin Rd.
          Schaumburg, IL  60196

          Work:   +1-847-576-2753
          E-mail: solomon@comm.mot.com




Perkins                Expires 30 November 1996                 [Page 5]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/