[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 rfc2003                                           
Internet Engineering Task Force                               C. Perkins
INTERNET DRAFT                                                       IBM
                                                            05 July 1995


                       IP Encapsulation within IP
                   draft-ietf-mobileip-ip4inip4-00.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.
   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 05 January 1996                 [Page i]


Internet Draft                 IP-within-IP                 05 July 1995


1. Introduction

   This document specifies a method by which an IP datagram may
   be encapsulated (carried as payload) within an IP datagram.
   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.

   It is generally true that encapsulation and source routing techniques
   can both be used to re-address datagrams whenever that is necessary,
   but there are several technical reasons to prefer encapsulation:

    -  There are unsolved security problems associated with the use of
       source routing.

    -  Current internet routers exhibit performance problems when
       forwarding packets which use the IP source routing option.

    -  Too many internet hosts process source routing options
       incorrectly.

    -  Firewalls may exclude source-routed packets.

    -  Insertion of an IP source route option may complicate the
       processing of authentication information by the source and/or
       destination of a datagram, depending on how the authentication is
       specified to be performed.

    -  It is considered impolite for intermediate routers to make
       modifications to the packets which they did not originate.





Perkins                 Expires 05 January 1996                 [Page 1]


Internet Draft                 IP-within-IP                 05 July 1995


   These technical advantages must be weighed against the disadvantages
   posed by the use of encapsulation:

    -  Encapsulated packets typically are longer than source routed
       packets.

    -  Encapsulation cannot be used unless it is known in advance that
       the tunnel endpoint for the encapsulated datagram can decapsulate
       the packet.

   Since the majority of internet hosts today do not perform well
   when IP loose source route options are used, the second technical
   disadvantage of encapsulation is not as serious as it might seem at
   first.


3. IP in IP Encapsulation

   An outer IP header is inserted before the datagram's IP header:

                                          +---------------------------+
                                          |      Outer IP Header      |
      +---------------------------+       +---------------------------+
      |         IP Header         |       |         IP Header         |
      +---------------------------+ ====> +---------------------------+
      |                           |       |                           |
      |         IP Payload        |       |         IP Payload        |
      |                           |       |                           |
      +---------------------------+       +---------------------------+

   The format of the IP header is described in RFC 791[4].  The outer
   IP header source and destination addresses identify the "endpoints"
   of the tunnel.  The inner IP header source and destination addresses
   identify the sender and recipient of the datagram.  The inner IP
   header is not changed by the node which encapsulates it inside the
   outer IP header, and the inner header remains unchanged during its
   delivery to the tunnel endpoint.  No change to IP options in the
   inner header occurs during delivery of the encapsulated packet
   through the tunnel.












Perkins                 Expires 05 January 1996                 [Page 2]


Internet Draft                 IP-within-IP                 05 July 1995


      Version

         4

      IHL

         The Internet Header Length measures the length (in bytes) of
         the outer IP header exclusive of its payload, but including any
         options which the encapsulating agent may insert.

      TOS

         The type of service is copied from the inner IP header.

      Total Length

         The length measures the length of the outer IP header along
         with its payload, that is to say the inner IP header and the
         original datagram.

      Identification

      Flags

      Fragment Offset

         These three fields are set in accordance with the procedures
         specified in [4].  The "Don't Fragment" bit in the outer IP
         header is copied from the corresponding flag in the inner IP
         header.

      Time to Live

         The Time To Live (TTL) field in the outer IP header is set to
         be the same as the original datagram.

      Protocol

         The protocol field in the outer IP header is set to protocol
         number 4 for the encapsulation protocol.

      Header Checksum

         The Header Checksum is computed over the length (in bytes) of
         the outer IP header exclusive of its payload, but including any
         options which the encapsulating endpoint may insert.





Perkins                 Expires 05 January 1996                 [Page 3]


Internet Draft                 IP-within-IP                 05 July 1995


      Source Address

         The IP address of the encapsulating agent, that is, the tunnel
         starting point.

      Destination Address

         The IP address of the decapsulating agent, that is, the tunnel
         completion point.

   When decapsulating, the outer TTL minus one is inserted into the
   inner IP TTL. Thus, hops are counted, but the actual routers interior
   to the tunnel are not identified.  This provides loop protection.

   The encapsulating agent is free to use any 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 [2] can obtain the information they seek.


4. ICMP messages from within the tunnel

   After an encapsulated datagram has been sent, the encapsulating
   agent may receive an ICMP message from any intermediate router
   within the tunnel, except for the tunnel endpoint.  The action taken
   by the encapsulating agent depends on the type of ICMP message
   received.  In many cases, the encapsulating agent will use the
   incoming message to create a similar ICMP message, which then is
   sent to the originator of the inner IP datagram.  This process will
   be referred to as "relaying" the ICMP message to the source of the
   original uncapsulated datagram.


4.1. Destination Unreachable

   Destination Unreachable messages are handled depending upon their
   type.  The model suggested here allows the tunnel to "extend" a
   network to include non-local (e.g, mobile) hosts.  Thus, if the
   original destination in the unencapsulated datagram is on the same
   network as the encapsulating agent, certain Destination Unreachable
   codes may be modified to conform to the suggested model.

      Code 0

         A Destination Unreachable message may be returned to
         the original sender.  If the original destination in



Perkins                 Expires 05 January 1996                 [Page 4]


Internet Draft                 IP-within-IP                 05 July 1995


         the unencapsulated datagram is on the same network as
         the encapsulating agent, the newly generated Destination
         Unreachable message sent by the encapsulating agent can have
         type 1, since presumably the packet arrived to the correct
         network and the encapsulating agent is trying to create the
         appearance that the original destination is local even if
         it's not.  Otherwise, the encapsulating agent must return a
         Destination Unreachable with code 0 message to the original
         sender.

      Code 1

         The encapsulating agent must relay Destination Unreachable
         messages of code 1 (host unreachable) to the source of the
         original unencapsulated datagram.

      Code 2

         When the encapsulating agent receives a Destination Unreachable
         ICMP message with code 2 (protocol unreachable) it should
         send a Destination Unreachable message with code 0 or 1 (see
         the discussion for code 0) to the sender of the original
         unencapsulated datagram.  Since the original sender did not
         necessarily use protocol 4, it would be meaningless to return
         code 2 to that sender.

      Code 3

         This code (port unreachable) should never be received by the
         encapsulating agent, since the outer IP header does not refer
         to any port number.  It must not be relayed to the source of
         the original unencapsulated datagram.

      Code 4

         The encapsulating agent must relay Destination Unreachable
         messages of code 4 (fragmentation needed and DF set) to the
         source of the original unencapsulated datagram.

      Code 5

         This code (source route failed) should be treated by the
         encapsulating agent itself.  It must not be relayed to the
         source of the original unencapsulated datagram.







Perkins                 Expires 05 January 1996                 [Page 5]


Internet Draft                 IP-within-IP                 05 July 1995


4.2. Time Exceeded

   The encapsulating agent may relay Time Exceeded messages to the
   source of the original unencapsulated datagram.


4.3. Parameter Problem

   If the parameter problem points to a field copied from the original
   unencapsulated datagram, the encapsulating agent may relay the ICMP
   message to the source; otherwise, if the problem occurs with an IP
   option inserted by the encapsulating agent, then the encapsulating
   agent must not relay the ICMP message to the source.  Note that an
   encapsulating agent following prevalent current practice will never
   insert any IP options into the encapsulated datagram.


4.4. Redirect

   The encapsulating agent may act on the Redirect message if it is
   possible, but it should not relay the Redirect back to the source
   of the datagram which was encapsulated.  Acting upon the Redirect
   message would require that the encapsulating agent maintain storage
   for encapsulated packets, and this may be an unpopular design choice
   for many purposes.


4.5. Source Quench

   The encapsulating agent may relay Source Quench messages to the
   source of the original unencapsulated datagram.


4.6. Other messages

   Other ICMP messages are not related to the encapsulation operations
   described within this protocol specification, and should be acted on
   as specified in [3].


5. Security Considerations

   Security considerations are not addressed in this document.








Perkins                 Expires 05 January 1996                 [Page 6]


Internet Draft                 IP-within-IP                 05 July 1995


6. Acknowledgements

   The text for parts of section 3 was taken from the mobile-IP
   draft([1]).


References

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

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

   [3] J. Postel.  Internet Control Message Protocol.  RFC 792,
       September 1981.

   [4] J. Postel.  Internet Protocol.  RFC 791, September 1981.


Author's Address

   Questions about this memo can also 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

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






Perkins                 Expires 05 January 1996                 [Page 7]