Internet Engineering Task Force                               C. Perkins
INTERNET DRAFT                                                       IBM
                                                         25 October 1995


                    Minimal Encapsulation within IP
                   draft-ietf-mobileip-minenc-01.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@tadpole.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 not appropriate to use Internet Drafts as
   reference material, or to cite them other than as a ``working draft''
   or ``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 ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).


Abstract

   This document specifies a method by which an IP datagram may
   be encapsulated (carried as payload) within an IP datagram,
   without incurring all the overhead of using a standard IP header.
   Encapsulation is suggested as a means to effect "re-addressing"
   datagrams (i.e, delivering them to an intermediate destination other
   than that specified in the IP destination field) for any of a variety
   of reasons, but particularly those useful for adherence to the
   mobile-IP specification.









Perkins                  Expires 25 April 1996                  [Page i]


Internet Draft       Minimal Encapsulation for IP        25 October 1995


1. Introduction

   This document specifies a method by which an IP datagram may
   be encapsulated (carried as payload) within an IP datagram,
   without incurring all the overhead of using a standard IP header,
   as specified in [5], Encapsulation is suggested as a means to
   effect "re-addressing" datagrams -- that is, delivering them to
   an intermediate destination other than that specified in the IP
   destination field.  The process of encapsulation and decapsulation 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.


2. Motivation

   The mobile-IP working group has specified the use of encapsulation as
   a way to deliver packets from a mobile host's "home network" to an
   agent which can deliver packets to the mobile host by conventional
   means [1].  The use of encapsulation may also be desirable 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 include
   preferential billing, choice of routes with selected security
   attributes, and general policy routing.

   See [5] for a discussion concerning the advantages of encapsulation
   versus source routing.  Since using IP headers to encapsulate IP
   datagrams requires the unwarranted 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 in this protocol specification
   comes from the mobile-IP working group (in earlier Internet Drafts),
   and is similar to that which had been outlined in [3].


3. Minimal Encapsulation

   A minimal forwarding header is defined for datagrams which are not
   fragmented prior to encapsulating.  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 inner
   header to store fragmentation information.








Perkins                  Expires 25 April 1996                  [Page 1]


Internet Draft       Minimal Encapsulation for IP        25 October 1995


   The minimal encapsulation process produces a datagram structured as
   shown below; the IP header of the original datagram is modified, then
   followed by the minimal forwarding header, followed by the unmodified
   IP payload of the original datagram.

      +---------------------------+       +---------------------------+
      |         IP Header         |       |     Modified IP Header    |
      +---------------------------+ ====> +---------------------------+
      |                           |       | Minimal Forwarding Header |
      |         IP Payload        |       +---------------------------+
      |                           |       |                           |
      +---------------------------+       |         IP Payload        |
                                          |                           |
                                          +---------------------------+

   Encapsulation is performed as follows.  The protocol field in
   the IP header is replaced by protocol number 55 for the minimal
   encapsulation protocol.  The destination field in the IP header
   is replaced by the care-of address of the mobile node.  If the
   encapsulating agent is not the original source of the datagram, the
   source field in the IP header is replaced by the IP address of the
   encapsulating agent.

   When decapsulating a datagram, the fields in the forwarding header
   are restored to the IP header, and the forwarding header is removed
   from the datagram.

   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                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                   Original Source Address                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Protocol

         Copied from the protocol field in the original IP header.









Perkins                  Expires 25 April 1996                  [Page 2]


Internet Draft       Minimal Encapsulation for IP        25 October 1995


      S

         Source field present bit, which indicates whether the Original
         Source Address field is present.

          0 not present.
          1 present.

      reserved

         Sent as zero; ignored on reception.

      Header Checksum

         The 16-bit one's complement of the one's complement sum of the
         encapsulation header.  For computing the checksum, the checksum
         field is set to 0.

      Original Destination Address

         Copied from the destination field in the original IP header.

      Original Source Address

         Copied from the source field in the original IP header.
         Present only if the S-bit is set.

   The encapsulating agent is free to use existing IP mechanisms
   appropriate for delivery of the encapsulated payload to the tunnel
   endpoint.  In particular, this means that use of IP options and
   fragmentation are allowed, unless the "Don't Fragment" bit is set in
   the inner IP header.  This is required so that hosts employing Path
   MTU discovery [4] can obtain the information they seek.


4. ICMP messages from within the tunnel

   ICMP messages are to be handled as specified in [5], including the
   maintenance of soft state.


5. Security Considerations

   Security considerations are not addressed in this document, but are
   generally thought to be similar to those outlined in [5].






Perkins                  Expires 25 April 1996                  [Page 3]


Internet Draft       Minimal Encapsulation for IP        25 October 1995


6. Acknowledgements

   The text for most of section 3 was taken from the mobile-IP
   draft [2].


References

   [1] IETF Mobile-IP Working Group.  IPv4 Mobility Support.
       ietf-draft-mobileip-protocol-12.txt - work in progress, September
       1995.

   [2] IETF Mobile-IP Working Group.  IPv4 Mobility Support.
       ietf-draft-mobileip-protocol-10.txt -- outdated draft, May 1995.

   [3] 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.

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

   [5] C. Perkins.  IP Encapsulation within IP.  Internet Draft -- work
       in progress, October 1995.


Author's Address

   Questions about this memo can be directed to:

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

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

   The working group can be contacted via the current chairs:

        Jim Solomon                       Tony Li
        Motorola, Inc.                    cisco systems
        1301 E. Algonquin Rd.             170 W. Tasman Dr.
        Schaumburg, IL  60196             San Jose, CA  95134



Perkins                  Expires 25 April 1996                  [Page 4]


Internet Draft       Minimal Encapsulation for IP        25 October 1995



        Work:   +1-708-576-2753           Work:   +1-408-526-8186
        E-mail: solomon@comm.mot.com      E-mail: tli@cisco.com
















































Perkins                  Expires 25 April 1996                  [Page 5]