Internet Engineering Task Force                                  RSVP WG
INTERNET-DRAFT                        J. Krawczyk/J. Wroclawski/L. Zhang
draft-ietf-rsvp-tunnel-00.txt                  UCLA/Bay Networks/MIT LCS
                                                              June, 1996
                                                          Expires: 12/96

                     RSVP Operation Over IP Tunnels

Status of this Memo

   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 (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).

   This document is a product of the RSVP working group of the Internet
   Engineering Task Force. Comments are solicited and should be
   addressed to the working group's mailing list at and/or
   the author(s).


      This memo describes an approach for providing RSVP protocol
      services over IP tunnels. We briefly describe the problem, the
      characteristics of possible solutions, and the design goals of our
      approach. We then present the details of an implementation which
      meets our design goals.

1. Introduction

   IP "tunnels" have become a widespread mechanism to transport
   datagrams in the Internet. Typically, a tunnel is used to route
   packets through portions of the network which do not directly

Krawczyk/Wroclawski/ZhangExpires December, 1996                 [Page 1]

INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996

   implement the desired service (e.g. IPv6), or to augment and modify
   the behavior of the deployed routing architecture (e.g. multicast
   routing, mobile IP).

   Many IP-in-IP tunneling protocols exist today.  [IP4INIP4] details a
   method of tunneling using an additional IP4 header.  [MINENC]
   describes a way to reduce the size of the "inner" IP header used in
   [IP4INIP4] when the original datagram is not fragmented.  The generic
   tunneling method in [IPV6GEN] can be used to tunnel either IPv4 or
   IPv6 packets within IPv6.  [RFC1933] describes how to tunnel IPv6
   datagrams through IPv4 networks.  [RFC1701] describes a generic
   routing encapsulation, while [RFC1702] applies this encapsulation to
   IPv4.  Finally, [ESP] describes a mechanism that can be used to
   tunnel an encrypted IP datagram.

   From the perspective of traditional best-effort IP packet delivery, a
   tunnel behaves as would any other link. Packets enter one end of the
   tunnel, and are delivered to the other end unless resource overload
   or error causes them to be lost.

   The RSVP setup protocol [RSVP] is one component of a framework
   designed to extend IP to support multiple, controlled classes of
   service over a wide variety of link-level technologies. To deploy
   this technology with maximum flexibility, it is desirable for tunnels
   to act as RSVP-controllable links within the network.

   A tunnel, and in fact any sort of link, may participate in an RSVP-
   aware network in one of three ways, depending on the capabilities of
   the equipment from which the it is constructed and the desires of the

     1) The link may not support resource reservation or quality-of-
     service control at all. This is a best-effort link. We refer to
     this as a best-effort or type 1 tunnel in this note.

     2) The link may be able to promise that some overall level of
     resources is available to carry traffic, but not to allocate
     resources specifically to subsets of that traffic. A simple fixed-
     bandwidth wire is an example of this. We refer to this case as a
     type 2 tunnel in this note.

     3) The link may be able to reserve different sets of resources for
     different classes of traffic. An ATM cloud does this by assigning
     bandwidth to different virtual circuits. We refer to this case as a
     type 3 tunnel in this note.

   For the case of RSVP and IP tunnels, the first type exists when some
   of the routers or links comprising the tunnel do not support RSVP or

Krawczyk/Wroclawski/ZhangExpires December, 1996                 [Page 2]

INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996

   integrated services. In this case, the tunnel acts as a best-effort
   link. Our goal is simply to make sure that RSVP messages traverse the
   link correctly, and the the presence of the non-controlled link is
   detected, as required by the integrated services framework.

   When the intermediate routers along the tunnel are capable of
   supporting RSVP, we would like to have proper resources reserved
   along the tunnel to meet application QoS control requests.  Depending
   on the reqirements of the situation, this might mean that an
   application's data flow is placed into a larger aggregate reservation
   (type 2 tunnels) or that a new, separate reservation is made for the
   data flow (type 3 tunnels).

   Currently, however, such reservations are not possible.  Because RSVP
   control messages are carried as regular IP packets, they are
   encapsulated when crossing the tunnel and become invisible to the
   intermediate routers within the tunnel. Because IP packets within the
   tunnel are encapsulated in varying ways, they would fail to be
   recognized and classified correctly by RSVP-aware routers even if the
   necessary RSVP information was available. Together these problems
   eliminate the ability to support both type 2 and type 3 tunnels.

   Furthermore, most the current IP-in-IP encapsulations add only an IP
   header as the external wrapper. In this case it is impossible to
   distinguish between packets belonging to different RSVP sessions
   while they are in the tunnel, because no distinguishing information
   such as a UDP port is available in the encapsulation. This eliminates
   the ability to support type 3 tunnels unless each intermediate router
   is prepared to decapsulate and examine all packets traversing the

   One approach to solving this problem is to define a separate solution
   for each existing tunneling protocol, based on the details of that
   protocol. We considered this solution, but rejected it as impractical
   and non-extensible.

   Instead we propose a new tunneling mechanism that allows RSVP to make
   reservations across all IP-in-IP tunnels. This mechanism is capable
   of supporting both type 2 and type 3 tunnels, as described above, and
   requires minimal changes to both RSVP and other parts of the
   integrated services framework.

      NOTE: A specific RSVP extensions to support tunnels as described
      in [ESP] is contained in [RSVPESP].

Krawczyk/Wroclawski/ZhangExpires December, 1996                 [Page 3]

INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996

2. The Design

2.1 Design Goals

   Our design choices are motivated by several goals.

     * Co-existing with most, if not all, current IP-in-IP tunneling

     * Limiting the changes to the RSVP spec to the minimum possible.

     * Limiting the necessary changes to only the two end points of a
     tunnel.  This requirement leads to simpler deployment, lower
     overhead in the intermediate routers, and less chance of failure
     when the set of intermediate routers is modified due to routing

     * Supporting correct interoperation with RSVP routers that have not
     been upgraded to handle RSVP over tunnels and with non-RSVP tunnel
     endpoint routers. In these cases, the tunnel is treated as an
     unreliable, non-RSVP link.

2.2 Basic Approach

   The design works by recursively applying RSVP. The original, end-to-
   end RSVP views the tunnel as a single (logical) link on the path
   between the source(s) and destination(s).  The recursive RSVP manages
   resource reservations on this logical link. This second RSVP views
   the two tunnel endpoints as two end hosts, and make a unicast Fixed-
   Filter style reservation to reserve resource between them.

   To accomplish this it is necessary to coordinate the actions of the
   two RSVP's, to determine when the recursive RSVP should create and
   tear down sessions, and to correctly transfer error and adspec
   information between the two RSVP's.

   We made the following design decisions:

     * Packets that do not require reservations are encapsulated in the
     normal way, e. g. being wrapped with an IP header only, specifying
     the tunnel entry point as source and the exit point as destination.

     * RSVP control messages being forwarded through a tunnel are
     encapsulated in the same was as normal IP packets, e. g. being
     wrapped with an IP header only, specifying the tunnel entry point
     as source and the exit point as destination.

     * Data packets that require resource reservations within a tunnel

Krawczyk/Wroclawski/ZhangExpires December, 1996                 [Page 4]

INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996

     must have some per-session attribute visible to the intermediate
     routers, so that the routers may distinguish between RSVP sessions
     within a type 3 tunnel.  We choose to encapsulate such data packets
     by prepending an IP and a UDP header, and to use UDP port numbers
     to distinguish packets of different RSVP sessions. This allows
     intermediate routers to use standard RSVP filterspec handling. We
     rejected the alternative approach of teaching RSVP-aware
     intermediate routers to look "inside" every possible tunnel-
     specific encapsulation as inconsistant with design goals 2 and 3,

     Note that this does not imply that the end-to-end packets are
     directly contained in IP and UDP. Mappings between our tunneling
     encapsulation and other end-to-end encapsulations are possible.
     Further, most of the mechanism of this note could be reused with a
     different tunneling encapsulation, if desired.

   Figure 1 shows the topology of an end-to-end path, including a
   tunnel, between two hosts. The sending host, H1, may be multiple IP
   hops from the tunnel entry router Rentry, which encapsulates data
   into the tunnel.  Some number of intermediate routers forward the
   data along the tunnel based upon the encapsulating IP header added by
   Rentry.  Rexit is the endpoint of the tunnel.  It decapsulates the
   data and forwards it based upon the original, "inner" IP header.  The
   receiving host, H2, may be multiple IP hops from Rexit.

             H1                                          H2
             :                                            :
             :                                            :
         +--------+     +---+     +---+     +---+     +-------+
         |        |     |   |     |   |     |   |     |       |
         | Rentry |===================================| Rexit |
         |        |     |   |     |   |     |   |     |       |
         +--------+     +---+     +---+     +---+     +-------+

                          Figure 1: Example Topology

   An RSVP session may be in place between endpoints at hosts H1 and H2.
   We refer to this session as the "end-to-end" or "original" session,
   and to its PATH and RESV messages as the end-to-end messages.  A
   recursive RSVP session may be in place between Rentry and Rexit to
   provide resource reservation over the tunnel. We refer to this as the
   tunnel RSVP session, and to its PATH and RESV messages as the tunnel
   or tunneling messages.

Krawczyk/Wroclawski/ZhangExpires December, 1996                 [Page 5]

INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996

2.3 Major Issues

   One major design decision is whether to support type 2 (single-
   reservation) tunnels, type 3 (per-session reservation) tunnels, or
   both.  We consider this a policy issue that should be left open.  Our
   design supports both cases.

   A second design issue is how the association, or binding, between an
   original RSVP reservation and a tunnel reservation is created and
   conveyed from one end of the tunnel to the other. The entry router
   Rentry and the exit router Rexit must agree on these associations so
   so that changes in the original reservation state can be correctly
   mapped into changes in the tunnel reservation state and so that
   errors reported by intermediate routers to the tunnel RSVP can be
   correctly transformed into errors reported at the tunnel endpoints to
   the original RSVP.

   We require that this association mechanism work for both the case of
   one-to-one mapping between original and tunnel reservations, and the
   case of bundled reservation over a tunnel.

   In our scheme the association is created when a tunnel entry point
   first sees an end-to-end session's PATH message and sets up or
   modifies tunnel session PATH state. The existance of this new
   association must be conveyed to Rexit, so that Rexit will know how to
   process arriving RESV messages from the original reservation.

   The information which must be conveyed from Rentry to Rexit includes
   the identifier and certain parameters of the tunnel session, and the
   identifier of the end-to-end session to which the tunnel session is
   being bound. In our scheme, tunnel sessions are identified primarily
   by source port. For all tunnel sessions on the same path between two
   routers Rentry and Rexit, the source IP address, destination IP
   address, and destination UDP port values are identical.

   We identified three possible choices for a binding mechanism:

     1) Define a new RSVP message that is exchanged only between two
     tunnel end points to convey the binding information.  This approach
     costs extra packets but handles both cases well.

     2) Define a new RSVP object to be attached to PATH messages
     generated for the tunnel session at Rentry. This unknown object is
     ignored by the intermediate routers but interpreted by Rexit.

     3) Apply the same UDP encapsulation to PATH messages as to data
     packets of the session.  When Rexit decapsulates the PATH message,
     it deduces the relation between the source UDP port used in the

Krawczyk/Wroclawski/ZhangExpires December, 1996                 [Page 6]

INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996

     encapsulation and the RSVP session that is specified in the
     original PATH message.  This approach does not require any new
     design. However it limits the information that can be transmitted
     beween Rentry and Rexit, and requires additional resources to be
     reserved for PATH messages (since they are now subject to the
     tunnel reservation).

        NOTES [due to jj]: Approach (3) requires a priori knowledge of
        which tunnels support the UDP encapsulation.  If Rentry
        encapsulates all tunneled PATH messages with the UDP
        encapsulation, but Rexit does not understand this encapsulation,
        the encapsulated PATH messages will be lost at Rexit.

        Option (2) is more transparent. It allows Rexit to pass on end-
        to-end PATHs received via the tunnel (because they are
        decapsulated normally), while throwing away the tunnel PATHs
        (because they are sent to a well-known, but unused by Rexit, UDP
        port), all without any additional configuration.

     [jtw: I basically agree with this idea, but there is a larger
     problem - data packets. You have to make them transparent too. You
     can do this by specifying that the UDP encap is used only if an
     actual reservation is in place for the tunnel session.

     Now the handshake is:

     - Rentry sends PATH messages in a format which will be caught by an
     RSVP-tunneling aware router, but just decapsulated and forwarded by
     a non-RSVP or non-RSVP-tunneling Rexit router.

     - Rexit sends tunnel session RESV messages only if tunnel-session
     PATH state is present

     - Rentry udp-encapsulates data only if a tunnel session reservation
     is present.

     I repeated this text in section 3.4, below.

     I think we should turn jj's NOTE in to a paragraph explaining that
     we reject option 3 because it connot be implemented transparently,
     explain that options 1 and 2 can, and forward-reference 3.4 to
     explain how transparent data handling works. RESV's are already
     covered by explanation elsewhere. ]

Krawczyk/Wroclawski/ZhangExpires December, 1996                 [Page 7]

INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996

3. Implementation

3.1 Handling PATH messages at Rentry

   When forwarding an end-to-end PATH message, a router acting as the
   tunnel entry point Rentry takes the following actions.  First, it
   encapsulates the PATH message using the normal encapsulation and
   forwards the message into the tunnel. Second, it considers the
   corresponding tunnel session PATH state.  If the end-to-end session
   is new, it may either (1) establish a new tunnel session for the
   end-to-end session, or (2) bind the end-to-end session to an existing
   tunnel session.  Let us discuss each of the two cases below.

   In the case where the end-to-end session should be bound to a
   specific tunnel session, Rentry first checks to see if tunnel session
   PATH state already exists for the end-to-end session. If so, nothing
   needs be done at this time; refreshment of the tunnel session's PATH
   state is controlled by the RSVP refresh timer at Rentry.

   If the end-to-end PATH message represents an unknown session, Rentry
   sets up tunnel session PATH state as if it were a source of data by
   starting to send tunnel-session PATH messages to Rexit, which is
   treated as the unicast destination of the data.  The Tspec in this
   new PATH message is computed from the original PATH message by
   adjusting the Tspec parameters to include the tunnel overhead of the
   encapsulation of data packets, and perhaps also PATH messages (if
   binding mechanism 3, above, is selected) in this session.

   In the case that the state for the end-to-end session is to be
   aggregated with an existing tunnel session, if the PATH message is a
   refresh of a previously known end-to-end session, then nothing needs
   to be done.  If the PATH message represents an unknown end-to-end
   session, Rentry adjusts the existing tunnel session PATH state by
   adding the Tspec to the aggregate Tspec and send a refresh message
   with the new parameters.

3.2 Handling PATH Messages at Rexit

   The tunnel session PATH messages generated by Rentry are addressed to
   Rexit, where they are processed and deleted.  When a new end-to-end
   session is recognized at Rentry, information is passed to Rexit by
   one of the mechanisms described above. Rexit records the association
   of the tunnel session with that of the end-to-end session, and sets
   the PHOP to Rentry. Rexit also notes the state of non-RSVP flag in
   the tunnel session PATH messages.

   Encapsulated end-to-end PATH messages are decapsulated at Rexit and
   further forwarded to the next hop along the path to the session

Krawczyk/Wroclawski/ZhangExpires December, 1996                 [Page 8]

INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996

   destination address.  Rexit's action at this time depends on whether
   Rentry implements RSVP control of the tunnel as described in this

   If Rentry does not perform RSVP tunnel control, then Rexit will have
   no PATH state for the tunnel.  In this case Rexit simply turns on the
   non-RSVP bit in the decapsulated end-to-end PATH message and forwards

   If Rentry is performing RSVP tunneling, Rexit finds the corresponding
   tunnel session's recorded state and turns on the end-to-end PATH
   message's non-RSVP bit if it was turned on for the tunnel session.

   [jtw: the bit is actually an IS general characterizaton parameter?]

   Rexit then performs composition of the characterization parameters
   contained in the end-to-end PATH message's adspec. It does this by
   considering the tunnel session's overall (composed) characterization
   parameters as the local parameters for the logical link implemented
   by the tunnel, and composing these parameters with those in the end-
   to-end adspec by executing each parameter's defined composition

   The computation of composed characterization parameters for the
   tunnel session is handled in the normal manner.

3.3 Handling RESV messages

   When forwarding a RESV message upstream, a router serving as the exit
   router Rexit may discover that one of the upstream interfaces is a
   tunnel.  In this case the router performs a number of tests.

   Step 1: Rexit must determine if there is a tunnel session bound to
   the end-to-end session given in the RESV message. If not, the tunnel
   is treated as a non-RSVP-controlled best effort link, and Rexit
   simply encapsulates and forwards the RESV message as a normal IP

   Step 2: If a bound tunnel sesson is found, Rexit checks to see if a
   reservation is already in place for the tunnel session bound to the
   end-to-end session given in the RESV message.

   Step 2a: If not, it creates and sends a fixed-filter RESV, including
   a RESV_CONFIRM object, using Rentry as the source IP address, the
   local interface as the destination IP address, the well-known
   destination UDP port, and the source UDP port received in the
   SENDER_TEMPLATE of Rentry's PATH message. See section 4.1 for details
   of UDP port selection.

Krawczyk/Wroclawski/ZhangExpires December, 1996                 [Page 9]

INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996

   If a RESV CONFIRM arrives for this request, the tunnel-session
   reservation is in place. The original RESV is now sent through the
   tunnel.  If the tunnel reservation fails, Rexit must send a RESV ERR
   for the original RESV error, using the error code and value fields
   for the ERROR_SPEC object received in response to the tunnel RESV
   message.  In this case, the RESV is not forwarded.

   Step 2b: If a reservation is already in place for the bound tunnel
   session, and the arriving end-to-end RESV message is a refresh of
   existing RESV state, the Rexit marks the tunnel session RESV state as
   refreshed, and sends the original RESV through the tunnel.

   If the arriving end-to-end RESV causes a change in the end-to-end
   RESV flowspec parameters (either a new or changed end-to-end flow),
   Rexit updates the tunnel session's flowspec parameters to include the
   newly encapsulated flow and refreshes the tunnel session RESV,
   including a RESV_CONFIRM object.

   If a RESV CONFIRM response arrives, the original RESV is sent through
   the tunnel.  If the updated tunnel reservation fails, Rexit must send
   a RESV ERR for the original RESV message, using the error code and
   value fields from the ERROR_SPEC object of the received RESV ERR
   message.  Note that the pre-existing reservations through the tunnel
   stay in place.  Rexit continues refreshing the tunnel RESV using the
   old flowspec.

   Tunnel session state must also be adjusted when an end-to-end
   reservation is deleted. The tunnel session gets reduced whenever one
   of the end-to-end sessions using the tunnel goes away (or gets
   reduced itself).  When the last RESV on the end-to-end session bound
   to that tunnel goes away, a RESV TEAR is sent for the tunnel.  [jj: I
   think this works....]

3.4 Forwarding Data

   When data packets arrive at the tunnel entry point Rentry, the router
   must decide whether to forward the packets using the normal tunnel
   encapsulation or the IP/UDP encapsulation expected by the tunnel
   session. This decision is made by determining whether there is a
   resoruce reservation (not just PATH state) actually in place for the
   tunnel session bound to the arriving packet's end-to-end state.

   If a reservation is in place, it means that a handshake has occurred
   indicating that both Rentry and Rexit are RSVP-tunneling aware
   routers, and the data will be correctly decapsulated at RExit. This
   handshake works as follows:

     1) Router Rentry detects end-to-end PATH messages and generates

Krawczyk/Wroclawski/ZhangExpires December, 1996                [Page 10]

INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996

     tunnel PATH messages in a format which will be recognized specially
     by a RSVP-tunneling aware router at Rexit, but just decapsulated
     and forwarded by a non-RSVP or non-RSVP-tunneling Rexit router.

     2) Rexit sends tunnel session RESV messages in response to the
     arrival of end-to-end RESV messages only if tunnel-session PATH
     state is present

     3) Rentry udp-encapsulates arriving data only if a corresponding
     tunnel session reservation is actually in place for the data.

   If no tunnel session reservation is in place, the data should be
   encapsulated in the tunnels normal format, regardless of whether
   end-to-end PATH state covering the data is present.

4. Details

4.1 Selecting UDP port numbers

   Within a type 3 tunnel there may be multiple RSVP sessions between
   the two end points Rentry and Rexit. These sessions are distinguished
   by the source UDP port. Other components of the session ID, the
   source and destination IP addresses and the destination UDP port, are
   identical for all such sessions.

   The source UDP port is chosen by the tunnel entry point Rentry when
   it establishes the initial PATH state for a new tunnel session. The
   source UDP port associated with the new session is then conveyed to
   Rexit by the binding mechanism.

   Note that this limits the number of concurrent tunnel sessions to
   65535. In some circumstances this may prove to be a significant
   limitation, but we do not currently have a proposal for avoiding it.

   The destination UDP port used in tunnel sessions is to be assigned.

4.2 Error Reporting

   When a tunnel session PATH message encounters an error, it is
   reported back to Rentry. Rentry must relay the error report back to
   the original source of the end-to-end session.

   When a tunnel session RESV request fails, an error message is
   returned to Rexit.  Rexit must treat this as an error in crossing the
   logical link (the tunnel) and forward the error message back to the
   end host.

4.3 Security Issues

Krawczyk/Wroclawski/ZhangExpires December, 1996                [Page 11]

INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996

   It is possible for a node other than the encapsulating router
   (Rentry) to "spoof" a reserved tunnel session's encapsulation,
   thereby giving its traffic a better-than-best-effort ride through the
   intermediate tunnel routers. To discourage this practice, the
   decapsulating router Rexit must examine each tunneled packet which
   arrives in an encapsulation matching a tunnel session to ensure that
   it matches one of the end-to-end sessions bound to that tunnel
   session.  If not, the packet must be discarded.

   This technique eliminates the end-to-end connectivity of the
   "spoofer", but still allows for a denial of service attach along the
   tunnel.  However, this is also a problem for RSVP without tunnels.

      [jtw: the above is a more verbose version of jj's text, but his
      idea is ghastly expensive. I may be asleep (3AM, OK) but doesn't
      it work for Rentry to just check that things aren't arriving from
      outside with its source address?]

      [jj: Yeah, it's not cheap, but no more expensive than the
      classification done on the outbound port.  The idea came from
      DVMRP, which does a much simpler check (dest IP is multicast).

      The Rentry check doesn't work if the packet is injected in the
      middle of the tunnel.  For example, suppose I knew that you had a
      tunnel between MIT and UCLA that happened to pass through a router
      at Nearnet.  Suppose if I sent a packet to the same UCLA router
      address, it would hit that same Nearnet router.  Further suppose
      that I figured out that you had some excess capacity on that
      reserved path and if I encapsulated my audio and video destined to
      someone else on the west coast, they would get a better quality
      signal.  That's the case I'm worried about.]

   To implement a type 3 (separate reservation) tunnel, it is necessary
   for the tunneling encapsulation to allow classification of the
   traffic by data flow. This allows for a type of traffic pattern
   analysis. The required level of exposure may be acceptable in many
   situations because the actual source and destination of the traffic
   will not be visible if the end-to-end packet format does not make it
   so. If this exposure is unacceptable, only a type 2 tunnel can be
   provided, although much of our mechanism can be reused.

4.4 ICMP messages

   When a router implements UDP encapsulation for RSVP, it must be able
   to convert ICMP messages generated within the tunnel into ICMP
   messages for the original sender in a manner compatible with the
   default tunneling scheme.

Krawczyk/Wroclawski/ZhangExpires December, 1996                [Page 12]

INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996

   [jtw: but only some of them, I think. Others should only go to the
   tunnel endpoints. e.g. a host-unreachable for an encap packet should
   not turn into a host-unreachable to the original end-point. Or are
   you saying something else completely?]

   In addition, since the UDP encapsulated packets cannot be fragmented,
   tunnel entry routers must support tunnel MTU discovery as discussed
   in section 5.1 of [IP4INIP4].


   [ESP] R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC
   1827, August, 1995.

   [IP4INIP4] C. Perkins, "IP Encapsulation within IP", Internet Draft
   draft-ietf-mobileip-ip4inip4-03.txt, May, 1996.

   [IPV6GEN] A. Conta, S, Deering, "Generic Packet Tunneling in IPv6
   Specification", Internet Draft draft-ietf-ipngwg-ipv6-tunnel-01.txt,
   February, 1996.

   [MINENC] C. Perkins, "Minimal Encapsulation within IP", Internet
   Draft draft-ietf-mobileip-minenc-02.txt, May, 1996.

   [RFC1701] S. Hanks, T. LI, D. Farinacci, P. Traina, "Generic Routing
   Encapsulation (GRE)", RFC 1701, October, 1994.

   [RFC1702] S. Hanks, T. LI, D. Farinacci, P. Traina, "Generic Routing
   Encapsulation over IPv4 Networks", RFC 1702, October, 1994.

   [RFC1933] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6
   Hosts and Routers", RFC 1933, April, 1996.

   [RSVP] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
   ReSerVation Protocol (RSVP) -- Version 1 Functional Specification",
   Internet Draft draft-ietf-rsvp-spec-12.txt, May, 1996.

   [RSVPESP] L. Berger, T. O'Malley, "RSVP Extensions for IPSEC Data
   Flows", Internet Draft draft-berger-rsvp-ext-03.txt, April, 1996.

Author's Address:

   John J. Krawczyk
   Bay Networks, Inc.
   2 Federal Street
   Billerica, MA  01821

Krawczyk/Wroclawski/ZhangExpires December, 1996                [Page 13]

INTERNET-DRAFT      draft-ietf-intserv-charac-01.txt          June, 1996

   John Wroclawski
   MIT Laboratory for Computer Science
   545 Technology Sq.
   Cambridge, MA  02139
   +1-617-253-2673 (FAX)

   Lixia Zhang
   Computer Science Department
   4531G Boelter Hall
   Los Angeles, CA 90095

Krawczyk/Wroclawski/ZhangExpires December, 1996                [Page 14]