Internet Engineering Task Force                               C. Perkins
INTERNET DRAFT                                                       IBM
                                                         21 October 1995
                                                             10 May 1996

                       IP Encapsulation within IP
                   draft-ietf-mobileip-ip4inip4-01.txt
                    draft-ietf-mobileip-ip4inip4-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@tadpole.com 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 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., alter the normal IP routing
   for datagrams, by delivering them to an intermediate destination
   other than that specified in
   which would not be otherwise selected by the (network part of the)
   IP destination field) field.  This may be done for any of a variety of
   reasons, but particularly those is particular useful for adherence to the mobile-IP
   specification.

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, alter the normal IP routing
   for datagrams, by delivering them to an intermediate destination
   other than that specified in
   which would not be otherwise selected based the (network part of 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.

   In the most general encapsulation case we have

      source ----> ---> encapsulator --------> decapsulator ----> ---> destination

   with these being separate machines.  There may in general be multiple
   source-destination pairs using the same tunnel.

2. Motivation

   The mobile-IP working group has specified the use of encapsulation
   as a way to deliver packets datagrams from a mobile host's "home network"
   to an agent which can deliver packets datagrams to the mobile host by
   conventional means [4]. [7].  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 in similar ways to re-address datagrams whenever that is necessary, affect the routing of a datagram, 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 datagrams which use the IP source routing option.

    -  Too many internet hosts process source routing options
       incorrectly.

    -  Firewalls may exclude source-routed packets. datagrams.

    -  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 datagrams which they did not originate.

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

    -  Encapsulated packets datagrams typically are longer than source routed
       packets.
       datagrams.

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

   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[9].  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, except
   to decrement the TTL before delivery.  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 datagram through the tunnel.  If need be, other protocol
   headers such as the IP Authentication header [1] may be inserted
   between the outer IP header and the inner IP header (also see
   section 6.3).

3.1. IP Header Fields and Handling

      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 (typically) the inner IP
         header and the original datagram.

      Identification

      Flags

      Identification, Flags, Fragment Offset

         These three fields are set in accordance with the procedures
         specified in [9].  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 a
         value appropriate for delivery of the encapsulated datagram to
         the tunnel endpoint.

      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.

      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.

      Options

         not copied from the inner IP header.  However, new options
         particular to the path MAY be added.  In particular, any
         supported flavors of security options of the inner IP header
         MAY affect the choice of security options for the tunnel.  It
         is not expected that there be a one-to-one mapping of such
         options to the options or security headers selected for the
         tunnel.

   The inner TTL is decremented by one.  If the resulting TTL is
   0, the datagram is not tunneled.  An encapsulating agent MUST
   NOT encapsulate a packet datagram with TTL = 0 for delivery to a tunnel
   endpoint.  The TTL is not changed when decapsulating.  If, after
   decapsulation, the inner packet datagram has TTL zero, a tunnel endpoint
   MUST discard the
   packet. datagram.  If the decapsulator forwards the datagram
   to some network interface, it will decrement the TTL as a result of
   doing normal IP forwarding.  See also subsection 4.4.

   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 [7] [6] can obtain the information they seek.

3.2. Routing Failures

   Routing loops within a tunnel are particularly dangerous when
   they cause datagrams to arrive again at the encapsulator.  If the
   IP Source matches any of its interfaces, an implementation MUST
   NOT further encapsulate.  If the IP Source matches the tunnel
   destination, an implementation SHOULD NOT further encapsulate.  See
   also subsection 4.4.

4. ICMP messages from within the tunnel

   After an encapsulated datagram has been sent, the encapsulating
   agent may receive an ICMP [8] 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.  When the received message contains enough information, the
   encapsulating agent may use the incoming message to create a similar
   ICMP message, to be 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 unencapsulated datagram.  Relaying an ICMP
   message requires that the encapsulator must strip off the outer IP
   header which it receives from the sender of the ICMP message.  For
   cases where the received message does not contain enough data, see
   section 5.

4.1. Destination Unreachable (Type 3)

   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.

      Network Unreachable (Code 0)

         A Destination Unreachable message may be returned to
         the original sender.  If the original destination in
         the unencapsulated datagram is on the same network as
         the encapsulating agent, the newly generated Destination
         Unreachable message sent by the encapsulating agent can MAY have
         code 1 (Host Unreachable), since presumably the packet datagram
         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.

      Host Unreachable (Code 1)

         The encapsulating agent must relay Host Unreachable messages to
         the source of the original unencapsulated datagram.

      Protocol Unreachable (Code 2)

         When the encapsulating agent receives a Protocol Unreachable
         ICMP message, 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 might only rarely use protocol 4, it would be usually be
         meaningless to return code 2 to that sender.

      Port Unreachable (Code 3)

         This code 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.

      Datagram Too Big (Code 4)

         The encapsulating agent must relay Datagram Too Big messages to
         the source of the original unencapsulated datagram.

      Source Route Failed (Code 5)

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

4.2. Source Quench (Type 4)

   The encapsulating agent may SHOULD NOT relay Source Quench messages to
   the source of the original unencapsulated datagram. datagram, but instead
   activate whatever congestion control mechanisms it implements to
   alleviate the congestion detected within the tunnel.

4.3. Redirect (Type 5)

   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.

4.4. Time Exceeded (Type 11)

   ICMP Time Exceeded messages report routing loops within the tunnel
   itself.  Reception of Time Exceeded messages by the encapsulator MUST
   be reported to the originator as Host Unreachable (Type 3 Code 1).
   Host Unreachable is preferable to Network Unreachable; since the
   packet
   datagram was handled by the encapsulator, and the encapsulator is
   often considered to be on the same network as the destination address
   in the original unencapsulated packet, datagram, the packet datagram is considered
   to have reached the correct network, but not the correct destination
   host within that network.

4.5. Parameter Problem (Type 12)

   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, except possibly
   for security reasons.

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

5. Tunnel Management

   Unfortunately, ICMP only requires IP routers to return 8 bytes (64
   bits) of the datagram beyond the IP header.  This is not enough to
   include the encapsulated header, so it is not always possible for the
   home agent to immediately reflect the ICMP message from the interior
   of a tunnel back to the source originating host.

   However, by carefully maintaining "soft state" about its tunnels,
   the encapsulating router can return accurate ICMP messages in most
   cases.  The router SHOULD maintain at least the following soft state
   information about each tunnel:

    - MTU of the tunnel (subsection 5.1)
    - TTL (path length) of the tunnel
    - Reachability of the end of the tunnel

   The router uses the ICMP messages it receives from the interior of a
   tunnel to update the soft state information for that tunnel.  ICMP
   errors that could be received from one of the routers along the
   tunnel interior include:

    - Datagram Too Big
    - Time Exceeded
    - Destination Unreachable
    - Source Quench

   When subsequent datagrams arrive that would transit the tunnel,
   the router checks the soft state for the tunnel.  If the datagram
   would violate the state of the tunnel (such as, the TTL is less than
   the tunnel TTL) the router sends an ICMP error message back to the
   source, but also forwards the datagram into the tunnel.

   Using this technique, the ICMP error messages sent by encapsulating
   routers will not always match up one-to-one with errors encountered
   within the tunnel, but they will accurately reflect the state of the
   network.

   Tunnel soft state was originally developed for the IP address
   encapsulation (IPAE) specification [3]. [4].

5.1. Tunnel MTU Discovery

   When the Don't Fragment bit is set by the originator and copied
   into the outer IP header, the proper MTU of the tunnel will
   be learned from ICMP (Type 3 Code 4) "Datagram Too Big" errors
   reported to the encapsulator.  To support originating hosts
   which use this capability, all implementations MUST support Path
   MTU Discovery([6, 7]) Discovery [5, 6] within their tunnels.  In this particular
   application there are several advantages:

    -  As a benefit of Tunnel MTU Discovery, any fragmentation which
       occurs because of the size of the encapsulation header is done
       performed only once after encapsulation.  This prevents more than one multiple
       fragmentation of a single datagram, which improves processing
       efficiency of the path routers and tunnel decapsulator.

    -  If the source of the unencapsulated packet datagram is doing MTU
       discovery then it is desirable for the encapsulator to know the
       MTU to the decapsulator.  If it doesn't know the MTU then it
       can transfer the DF bit to the outer packet; datagram; however, if that
       triggers ICMP Datagram Too Big from within the tunnel (and hence
       returned to the encapsulator) the encapsulator cannot always
       return a correct ICMP response to the source unless it has kept
       state information about recently sent packets. datagrams.  If the tunnel
       MTU is returned to the source by the encapsulator in a Datagram
       Too Big message, the MTU that is conveyed SHOULD be the MTU of
       the tunnel minus the size of the encapsulating IP header.  This
       will avoid fragmentation of the original IP datagram by the
       encapsulator, something that is otherwise certain to occur.

    -  If the source is not doing MTU discovery it is still desirable
       for the encapsulator to know the MTU to the decapsulator.  In
       particular it is much better to fragment the inner packet datagram than
       to allow the outer packet datagram to be fragmented.  Fragmenting the
       inner packet datagram can be done without special buffer requirements
       and without the need to keep state in the decapsulator.
       By contrast if the outer packet datagram is fragmented then the
       decapsulator needs to keep state and buffer space on behalf of
       the destination.

   The encapsulator SHOULD in normal circumstances do MTU discovery
   and try to send packets datagrams with the DF bit set.  However there are
   problems with this approach.  When the source sets the DF bit it can
   react quickly to resend the information if it gets a ICMP Datagram
   Too Big.  When the encapsulator gets a ICMP Datagram Too Big, but the
   source had not set the DF bit, then there is nothing sensible that
   the encapsulator can do to let the source know.  The encapsulator MAY
   keep a copy of the sent packet datagram whenever it tries increasing the MTU
   - this will allow it to resend the packet datagram fragmented if it gets a packet
   datagram too big response.  Alternatively the encapsulator MAY be
   configured for certain classes of input to not set the DF bit when
   the source has not set the DF bit.

5.2. Congestion

   Tunnel soft state will collect indications of congestion, such as
   an ICMP (Type 4) Source Quench or a Congestion Experienced flag in
   datagrams from the decapsulator (tunnel peer).  When forwarding
   another datagram into the tunnel, it is appropriate to send use approved
   means for controlling congestion [3]; Source Quench messages SHOULD
   NOT be sent to the originator.

6. Security Considerations

   IP encapsulation potentially reduces the security of the Internet.
   For this reason care needs to be taken in the implementation and
   deployment.

   Assume an organization has good physical control of a secure subset
   of its network.  Assume that the routers connecting that secure
   network do not allow in packets datagrams with source addresses belonging to
   interfaces on that secure network.  In that situation it is possible
   to safely deploy protocols within that network which depend on the
   source address of packets datagrams for authentication purposes.

   Networks with physical security can still be used to run protocols
   which are convenient, but which have implementation or protocol bugs
   which would make them dangerous to use if external sources have
   access to the protocol.  The external sources can be excluded using
   router packet datagram filtering.

   IP encapsulation protocols may allow packets datagrams to bypass the checks
   in the border routers.  There are two cases to consider:

    -  The case where the people controlling the border routers are
       trying to protect inner machines from themselves.

    -  The case where the inner machine is looking after its own
       defense.

   An uncooperative inner machine cannot be protected by the border
   router except by barring all packets to that machine.  There is
   nothing to stop encapsulated IP coming in to that inner machine in
   otherwise harmless packets datagrams such as port 53 UDP packets datagrams (i.e.,
   apparently DNS packets). datagrams).  So there is a strong case for placing
   the security controls at the host rather than the router.  However,
   in situations where the administrative control of the inner machine
   is cooperative but lacks thoroughness or competence, security can be
   enhanced by also putting protection in the border routers.

6.1. Router Considerations

   Routers need to be aware of IP encapsulation protocols so they can
   correctly filter incoming packets. datagrams.

   Beyond that it is desirable that filtering be integrated with IP
   authentication [1].  In the case of IP encapsulation this can have
   2 forms:  Encapsulation might be allowed (in some cases) as long
   as the encapsulating packets datagrams authentically come from an expected
   encapsulator.  Alternatively encapsulation might be allowed if the
   encapsulated packets datagrams have authentication.

   The next problem is with packets

   Data which are is encapsulated and encrypted [2]. [2] may also pose a problem.
   In this case the router can only filter the packet datagram if it knows
   the security association.  To allow this sort of encryption in
   environments where all packets need to be filtered (or at least
   accounted for) a mechanism must be in place for the receiving host
   to securely communicate the association to the border router.  This
   might, more rarely, also apply to the association used for outgoing
   packets.
   datagrams.

6.2. Host Considerations

   Receiving IP encapsulation software SHOULD classify incoming packets
   datagrams and only allow packets datagrams fitting one of the following
   categories:

    -  The protocol is harmless:  source address based authentication is
       not needed.

    -  The packet datagram can be trusted because of trust in the authentically
       identified encapsulating host.  That authentic identification
       could come from physical security plus border router
       configuration but is more likely to come from AH authentication.

    -  The inner packet datagram has AH authentication.

   Some or all of this checking could be done in border routers rather
   than the receiving host but it is better if border router checks are
   used as backup rather than being the only check.

6.3. Using Security Options

   The security options of the inner IP header MAY affect the choice of
   security options for the encapsulating IP header.

7. Acknowledgements

   Parts of sections 3 and 5 of this document were taken from sections
   (authored by Bill Simpson) of earlier versions of the mobile-IP draft [5].
   Internet Draft [7].  Good ideas have also been included from RFC
   1853 [10]. [10], also authored by Bill Simpson.  "Security Considerations"
   (section 6) was largely contributed by Bob Smart.  Thanks also to
   Anders Klemets for finding mistakes and suggesting many improvements
   to the draft.

References

    [1] R. Atkinson.  IP Authentication Header.  RFC 1826, August 1995.

    [2] R. Atkinson.  IP Encapsulating Security Payload.  RFC 1827,
        August 1995.

    [3] F. Baker, Editor.  Requirements for IP Version 4 Routers.  RFC
        1812, June 1995.

    [4] R. Gilligan, E. Nordmark, and B. Hinden.  IPAE: The SIPP
        Interoperability and Transition Mechanism.  Internet Draft --
        work in progress, March 1994.

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

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

    [6] S. Knowles.  IESG Advice from Experience with Path MTU
        Discovery.  RFC 1435, March 1993.

    [7]

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

    [7] C. Perkins, Editor.  ietf-draft-mobileip-protocol-16.txt - work
        in progress.  IPv4 Mobility Support, April 1996.

    [8] J. Postel. B. Postel, Editor.  Internet Control Message Protocol.  RFC
        792, September 1981.

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

   [10] W. Simpson.  IP in IP Tunneling.  RFC 1853, October 1995.

Author's Address

   Questions about this memo can also be directed to:

          Charles Perkins
          Room J1-A25 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-7007    +1-914-784-6205
          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   +1-847-576-2753           Work:   +1-408-526-8186
        E-mail: solomon@comm.mot.com      E-mail: tli@cisco.com