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

                       IP Encapsulation within IP
                    draft-ietf-mobileip-ip4inip4-02.txt
                  draft-ietf-mobileip-ip4inip4-03.txt

Status of This Memo

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

   Distribution of this memo is unlimited.

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

   Internet Drafts Internet-Drafts.

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

   To learn the current status of any Internet-Draft, please check
   the ``1id-abstracts.txt'' "1id-abstracts.txt" listing contained in the internet-drafts 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), nic.nordu.net
   (Europe), or
   ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim). Coast).

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 alter the normal IP routing
   for datagrams, by delivering them to an intermediate destination
   which
   that would otherwise not be otherwise selected by the (network part of the) IP destination field.  This
   Destination Address field in the original IP header.  Encapsulation
   may be done for any of serve a variety of
   reasons, but is particular useful for adherence purposes, such as delivery of a datagram to the mobile-IP
   specification. 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.
   Encapsulation is suggested as a means to alter the normal IP routing
   for datagrams, by delivering them to an intermediate destination
   which that
   would otherwise not be otherwise selected based on the (network part of the)
   IP Destination Address field in the original IP header.  Once the
   encapsulated datagram arrives at this intermediate destination node,
   it is decapsulated, yielding the original IP datagram, which is then
   delivered to the destination indicated by the original Destination
   Address field.  The process  This use 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.

   In the most general encapsulation tunneling case we have

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

   with these the source, encapsulator, decapsulator, and destination being
   separate machines. nodes.  The encapsulator node is considered the "entry
   point" of the tunnel, and the decapsulator node is considered
   the "exit point" of the tunnel.  There may in general may be multiple
   source-destination pairs using the same tunnel. tunnel between the
   encapsulator and decapsulator.

2. Motivation

   The mobile-IP Mobile IP working group has specified the use of encapsulation
   as a way to deliver datagrams from a mobile host's node's "home network" to
   an agent which that can deliver datagrams to the mobile host locally by conventional means [7].
   to the mobile node at its current location away from home [8].  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 of encapsulation include multicasting,
   preferential billing, choice of routes with selected security
   attributes, and general policy routing.

   It is generally true that encapsulation and the IP loose source
   routing techniques option [10] can be used in similar ways to 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
       the IP source routing. routing options.

    -  Current internet Internet routers exhibit performance problems when
       forwarding datagrams which use that contain IP options, including the IP
       source routing option. options.

    -  Too many internet hosts  Many current Internet nodes process IP source routing options
       incorrectly.

    -  Firewalls may exclude IP source-routed 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 datagrams which they did not originate.

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

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

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

   Since the majority of internet hosts Internet nodes 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

   To encapsulate an IP datagram using IP in IP encapsulation, an outer
   IP header [10] is inserted before the datagram's existing IP header: header,
   as follows:

                                         +---------------------------+
                                         |                           |
                                         |      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 Source Address and destination addresses Destination Address identify
   the "endpoints" of the tunnel.  The inner IP header source Source Address
   and destination addresses Destination Addresses identify the original sender and recipient
   of the datagram. datagram, respectively.  The inner IP header is not changed
   by the node which encapsulates it, encapsulator, except to decrement the TTL before delivery.  The inner header as noted below, and
   remains unchanged during its delivery to the tunnel endpoint. exit point.  No
   change to IP options in the inner header occurs during delivery of
   the encapsulated 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). header.  Note
   that the security options of the inner IP header MAY affect the
   choice of security options for the encapsulating (outer) IP header.

3.1. IP Header Fields and Handling

   The fields in the outer IP header are set by the encapsulator as
   follows:

      Version

         4
      IHL

         The Internet Header Length measures (IHL) is the length (in bytes) of the outer IP
         header exclusive of its payload, but including any
         options which the encapsulating agent may insert. measured in 32-bit words [10].

      TOS

         The type Type of service Service (TOS) is copied from the inner IP header.

      Total Length

         The length Total Length measures the length of the entire encapsulated
         IP datagram, including the outer IP header along
         with its payload, that is to say (typically) header, the inner IP
         header
         header, and the original datagram. its payload.

      Identification, Flags, Fragment Offset

         These three fields are set in accordance with the procedures as specified in [9].  The [10].  However, if
         the "Don't Fragment" bit is set in the inner IP header, it MUST
         be set in the outer IP
         header is copied from header; if the corresponding flag "Don't Fragment" bit is
         not set in the inner IP
         header. header, it MAY be set in the outer IP
         header, as described in Section 5.1.

      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. exit point.

      Protocol

         The protocol field in the outer IP header is set to protocol
         number

         4 for the encapsulation protocol.

      Header Checksum

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

      Source Address

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

      Destination Address

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

      Options

         not copied from

         Any options present in the inner IP header are in general NOT
         copied to the outer IP header.  However, new options
         particular specific
         to the tunnel path MAY be added.  In particular, any supported flavors
         types of security options of the inner IP header MAY affect the
         choice of security options for the tunnel. outer header.  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

   When encapsulating a datagram, the TTL in the inner IP header
   is decremented by one. one if the tunneling is being done as part of
   forwarding the datagram; otherwise, the inner header TTL is not
   changed during encapsulation.  If the resulting TTL in the inner IP
   header is 0, the datagram is not tunneled. discarded and an ICMP Time Exceeded
   message SHOULD be returned to the sender.  An encapsulating agent encapsulator MUST NOT
   encapsulate a datagram with TTL = 0 for delivery to a tunnel
   endpoint. 0.

   The TTL in the inner IP header is not changed when decapsulating.
   If, after decapsulation, the inner datagram has TTL zero, a tunnel endpoint = 0, the
   decapsulator MUST discard the datagram.  If  If, after decapsulation, the
   decapsulator forwards the datagram to some network interface, it one of its network interfaces,
   it will decrement the TTL as a result of doing normal IP forwarding.
   See also subsection Section 4.4.

   The encapsulating agent is free to encapsulator may use any existing IP mechanisms appropriate for
   delivery of the encapsulated payload to the tunnel
   endpoint. exit point.  In
   particular, this means that use of IP options is allowed, and use of fragmentation are allowed,
   is allowed unless the "Don't Fragment" bit is set in the inner IP
   header.  This restriction on fragmentation is required so that hosts nodes
   employing Path MTU discovery [6] Discovery [7] 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.  Suppose
   a datagram arrives at a router for forwarding, and the router
   determines that the datagram has to be encapsulated before further
   delivery.  Then:

    -  If the IP Source Address of the datagram matches the router's own
       IP address on any of its network interfaces, an implementation the router MUST NOT further encapsulate.
       tunnel the datagram; instead, the datagram SHOULD be discarded.

    -  If the IP Source Address of the datagram matches the IP address
       of the tunnel
   destination, an implementation SHOULD destination (the tunnel exit point is typically
       chosen by the router based on the Destination Address in the
       datagram's IP header), the router MUST NOT further encapsulate. tunnel the datagram;
       instead, the datagram SHOULD be discarded.

   See also subsection Section 4.4.

4. ICMP messages Messages from within the tunnel Tunnel

   After an encapsulated datagram has been sent, the encapsulating
   agent encapsulator may
   receive an ICMP [8] [9] message from any intermediate router within the tunnel, except for
   tunnel other than the tunnel endpoint. exit point.  The action taken by the encapsulating agent
   encapsulator depends on the type of ICMP message received.  When the
   received message contains enough information, the
   encapsulating agent may encapsulator MAY
   use the incoming message to create a similar ICMP message, to be sent
   to the originator of the inner original unencapsulated IP datagram. datagram (the
   original sender).  This process will be referred to as "relaying" the
   ICMP message to from the source tunnel.

   ICMP messages indicating an error in processing a datagram include a
   copy of (a portion of) the original unencapsulated datagram. datagram causing the error.  Relaying an
   ICMP message requires that the encapsulator must strip off the outer IP
   header which it receives from the sender this returned copy of the ICMP message. original datagram.  For cases where
   in which the received ICMP message does not contain enough data, data to
   relay the message, see
   section Section 5.

4.1. Destination Unreachable (Type 3)

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

      Network Unreachable (Code 0)

         A

         An ICMP Destination Unreachable message may SHOULD be returned
         to the original sender.  If the original destination in
         the unencapsulated datagram is on the same network as the encapsulating agent,
         encapsulator, the newly generated Destination Unreachable
         message sent by the encapsulating agent encapsulator MAY have
         code Code 1 (Host
         Unreachable), since presumably the datagram arrived to at the
         correct network and the encapsulating agent encapsulator is trying to create the
         appearance that the original destination is local to that
         network even if it's it is not.  Otherwise, if the encapsulating agent
         must return encapsulator
         returns a Destination Unreachable with code 0 message to message, the original sender. Code field MUST
         be set to 0 (Network Unreachable).

      Host Unreachable (Code 1)

         The encapsulating agent must encapsulator SHOULD relay Host Unreachable messages to the source
         sender of the original unencapsulated datagram. datagram, if possible.

      Protocol Unreachable (Code 2)

         When the encapsulating agent encapsulator receives a an ICMP Protocol Unreachable
         ICMP
         message, it should SHOULD send a Destination Unreachable message with code
         Code 0 or 1 (see the discussion for code Code 0) to the sender of
         the original unencapsulated datagram.  Since the original
         sender might only rarely did not use protocol 4, it would be usually 4 in sending the datagram, it would
         be meaningless to return code Code 2 to that sender.

      Port Unreachable (Code 3)

         This code Code should never be received by the encapsulating
         agent, encapsulator, since
         the outer IP header does not refer to any port number.  It must not MUST
         NOT be relayed to the source sender of the original unencapsulated
         datagram.

      Datagram Too Big (Code 4)

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

      Source Route Failed (Code 5)

         This code should Code SHOULD be treated handled by the encapsulating agent encapsulator itself.
         It must not MUST NOT be relayed to the source sender of the original
         unencapsulated datagram.

4.2. Source Quench (Type 4)

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

4.3. Redirect (Type 5)

   The encapsulating agent may act on encapsulator MAY handle the ICMP Redirect message if it is
   possible, but it should messages itself.
   It MUST NOT not relay the Redirect back to the source sender of the datagram which was encapsulated. original
   unencapsulated datagram.

4.4. Time Exceeded (Type 11)

   ICMP Time Exceeded messages report (presumed) routing loops
   within the tunnel itself.  Reception of Time Exceeded messages by
   the encapsulator MUST be reported to the originator sender of the original
   unencapsulated datagram as Host Unreachable (Type 3 3, Code 1).  Host
   Unreachable is preferable to Network Unreachable; since the 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 datagram, then the datagram is considered
   to have reached the correct network, but not the correct destination
   host
   node within that network.

4.5. Parameter Problem (Type 12)

   If the parameter problem Parameter Problem message points to a field copied from the
   original unencapsulated datagram, the encapsulating agent may encapsulator MAY relay the
   ICMP message to the source; sender of the original unencapsulated datagram;
   otherwise, if the problem occurs with an IP option inserted by
   the encapsulating agent, encapsulator, then the encapsulating
   agent must not encapsulator MUST NOT relay the ICMP
   message to the source. original sender.  Note that an
   encapsulating agent encapsulator following
   prevalent current practice will never insert any IP options into the
   encapsulated datagram, except possibly for security reasons.

4.6. Other messages ICMP Messages

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

5. Tunnel Management

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

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

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

   The router encapsulator 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 encapsulator checks the soft state for the tunnel.  If the
   datagram would violate the state of the tunnel (such as, (for example, the TTL
   of the new datagram is less than the tunnel "soft state" TTL) the router
   encapsulator sends an ICMP error message back to the
   source, sender of the
   original datagram, but also forwards encapsulates the datagram and forwards it
   into the tunnel.

   Using this technique, the ICMP error messages sent by encapsulating
   routers the
   encapsulator 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 Address
   Encapsulation (IPAE) specification [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 Datagram Too Big (Type 3 3, Code 4) "Datagram Too Big" errors messages reported to
   the encapsulator.  To support originating hosts sending nodes which use this capability, Path MTU
   Discovery, all encapsulator implementations MUST support Path MTU
   Discovery [5, 6] 7] soft state within their tunnels.  In this particular
   application
   application, there are several advantages:

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

    -  If the source of the unencapsulated datagram is doing Path MTU
       discovery
       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 of the outer datagram; however, if that
       triggers tunnel.  Any ICMP Datagram Too Big messages from
       within the tunnel (and hence are returned to the encapsulator) encapsulator, and as noted
       in Section 5, it is not always possible for the encapsulator cannot always
       return a correct to
       relay ICMP response messages to the source unless it has kept
       state information about recently sent datagrams.  If of the original unencapsulated
       datagram.  By maintaining "soft state" about the tunnel MTU is returned to of the source by
       tunnel, the encapsulator in a can return correct ICMP Datagram Too Big message,
       messages to the original sender of the unencapsulated datagram to
       support its own Path MTU Discovery.  In this case, the MTU that
       is conveyed to the original sender by the encapsulator 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. encapsulator.

    -  If the source of the original unencapsulated datagram is
       not doing Path MTU discovery Discovery, it is still desirable for the
       encapsulator to know the MTU to of the decapsulator. tunnel.  In
       particular particular, it is
       much better to fragment the inner original datagram when encapsulating,
       than to allow the outer encapsulated datagram to be fragmented.
       Fragmenting the
       inner original datagram can be done by the encapsulator
       without special buffer requirements and without the need to
       keep reassembly state in the decapsulator.  By contrast contrast, if
       the outer encapsulated datagram is fragmented fragmented, then the decapsulator needs to keep
       must reassemble the fragmented (encapsulated) datagram before
       decapsulating it, requiring reassembly state and buffer space on behalf of
       within the decapsulator.

   Thus, the destination.

   The encapsulator SHOULD in normal circumstances normally do Path MTU discovery
   and try Discovery,
   requiring it to send all datagrams into the tunnel with the DF "Don't
   Fragment" bit set. set in the outer IP header.  However there are
   problems with this approach.  When the source original sender sets the DF bit it
   "Don't Fragment" bit, the sender can react quickly to resend the information if it gets a any returned
   ICMP Datagram Too Big.  When Big error message by retransmitting the original
   datagram.  On the other hand, suppose that the encapsulator gets a receives
   an ICMP Datagram Too Big, but Big message from within the
   source tunnel.  In that
   case, if the original sender of the unencapsulated datagram had
   not set the DF "Don't Fragment" bit, then there is nothing sensible that
   the encapsulator can do to let the source know. original sender know of the
   error.  The encapsulator MAY keep a copy of the sent datagram
   whenever it tries increasing the MTU
   - this will tunnel MTU, in order to allow it
   to fragment and resend the datagram fragmented if it gets a
   datagram too big Datagram Too Big
   response.  Alternatively the encapsulator MAY be configured for
   certain classes types of input to datagrams not to set the DF "Don't Fragment" bit when
   the source original sender of the unencapsulated datagram has not set the DF
   "Don't Fragment" bit.

5.2. Congestion

   Tunnel soft state will collect

   An encapsulator might receive indications of congestion, such as
   an congestion from the
   tunnel, for example, by receiving ICMP (Type 4) Source Quench or messages from
   nodes within the tunnel.  In addition, certain link layers and
   various protocols not related to the Internet suite of protocols
   might provide such indications in the form of a Congestion
   Experienced flag [6] flag.  The encapsulator SHOULD reflect conditions of
   congestion in
   datagrams from its "soft state" for the decapsulator (tunnel peer).  When tunnel, and when subsequently
   forwarding
   another datagram datagrams into the tunnel, it is appropriate to the encapsulator SHOULD use approved
   appropriate means for controlling congestion [3]; However, the
   encapsulator SHOULD NOT send ICMP Source Quench messages SHOULD
   NOT be sent to the originator.
   original sender of the unencapsulated datagram.

6. Security Considerations

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

   Assume an organization has good physical control deployment of a secure subset
   of its network.  Assume that the
   IP encapsulation.  For example, IP encapsulation makes it difficult
   for border routers connecting that secure
   network do not allow in datagrams with source addresses belonging to
   interfaces filter datagrams based on that secure network. header fields.  In that situation it is possible
   to safely deploy protocols within that network which depend on
   particular, the
   source address original values of 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 datagram filtering.

   IP encapsulation protocols may allow datagrams to bypass the checks Source Address, Destination
   Address, and Protocol fields 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 datagrams such as port 53 UDP datagrams (i.e.,
   apparently DNS datagrams).  So there is a strong case for placing
   the security controls at the host rather than header, and the router.  However, port numbers
   used in situations where the administrative control of any transport header within the inner machine
   is cooperative but lacks thoroughness or competence, security can be
   enhanced by also putting protection datagram, are not located
   in their normal positions within the datagram after encapsulation.
   Since any IP datagram can be encapsulated and passed through a
   tunnel, such filtering border routers. routers need to carefully examine all
   datagrams.

6.1. Router Considerations

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

   Beyond that it  It is desirable that
   such filtering be integrated with IP authentication [1].  In the case of  Where IP encapsulation this can have
   2 forms:  Encapsulation
   authentication is used, encapsulated packets might be allowed (in some cases) as long
   as to
   enter an organization when the encapsulating datagrams authentically come from an expected
   encapsulator.  Alternatively encapsulation might be allowed if (outer) packet or the
   encapsulated (inner) packet is sent by an authenticated, trusted
   source.  Encapuslated packets containing no such authentication
   represent a potentially large security risk.

   IP datagrams have authentication.

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

6.2. Host Considerations

   Receiving

   Host implementations that are capable of receiving encapsulated IP encapsulation software SHOULD classify incoming
   datagrams and SHOULD admit only allow those datagrams fitting into one or more
   of the following categories:

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

    -  The encapsulating (outer) datagram can be comes from an authentically
       identified, trusted because source.  The authenticity of trust in the authentically
       identified encapsulating host.  That authentic identification source could come from
       be established by relying on physical security plus in addition to
       border router
       configuration configuration, but is more likely to come from AH authentication. use
       of the IP Authentication header [1].

    -  The inner encapuslated (inner) datagram includes an IP Authentication
       header.

    -  The encapsulated (inner) datagram is addressed to a network
       interface belonging to the decapsulator, or to a node with which
       the decapsulator has AH authentication. entered into a special relationship for
       delivering such encapsulated datagrams.

   Some or all of this checking could be done in border routers rather
   than the receiving host node, but it is better if border router checks are
   used as backup 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 Sections 3 and 5 of this document were taken from sections portions
   (authored by Bill Simpson) of earlier versions of the mobile-IP Mobile IP
   Internet Draft [7]. [8].  The original text for section 6 (Security
   Considerations) was contributed by Bob Smart.  Good ideas have also
   been included from RFC 1853 [10], [11], 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
   improvements to the draft.  Finally, thanks to David Johnson for
   going over the draft with a fine-toothed comb, finding mistakes,
   improving consistency, and making many other 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.

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

    [6] A. Mankin and K. Ramakrishnan.   Gateway Congestion Control
        Survey.  RFC 1254, August 1991.

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

    [7]

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

    [8]

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

    [9]

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

   [10]

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

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 chairs: chair:

          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-847-576-2753           Work:   +1-408-526-8186
          E-mail: solomon@comm.mot.com      E-mail: tli@cisco.com