Tracing Requirements for Generic Tunnels
draft-bonica-tunneltrace-03

Versions: 00 01 02 03                                                   
Internet Draft                                                R. Bonica
Expiration Date: August 2001                                   WorldCom
                                                            K. Kompella
                                                       Juniper Networks
                                                               D. Meyer
                                                          Cisco Systems
                                                          February 2001

                Tracing Requirements for Generic Tunnels
                    draft-bonica-tunneltrace-01.txt


1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC-2026].

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


2. Abstract

   This document specifies requirements for a generic route tracing
   application.  The application must provide all functionality that
   "traceroute" [RFC 2151] currently provides.  It also must provide
   enhanced capabilities with regard to tracing through tunnels (e.g.,
   IP-in-IP, MPLS).


3. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC-2119].


4. Introduction

   Currently, the IETF supports the following tunneling technologies:

           Generic Routing Encapsulation (GRE)
           Multiprotocol Label Switching (MPLS)
           IP over Optical (IPO)
           IP Security Protocol (IPSEC)
           IP in IP
           Layer 2 Tunneling Protocol (L2TP)

   Although these tunneling technologies provide operators with many
   useful features, they also present management challenges.
   Specifically, operators require a generic route tracing application
   that they can use to verify tunnel paths and diagnose tunnel faults.

   This document specifies requirements for that generic route tracing
   application.  It also specifies requirements the protocol that will
   support it.


5. Review of Existing Functionality

   Currently, network operators use "traceroute" to identify the path
   toward any destination in an IP network.  Section 3.4 of [RFC-2151]
   provides a thorough description of traceroute.  Although traceroute
   is very reliable and very widely deployed, it is deficient with
   regard to tunnels.

   Depending upon tunnel type, traceroute may display an entire tunnel
   as a single IP hop, or it may display a tunnel as a collection of IP
   hops, without indicating that they are part of a tunnel.

   For example, assume that engineers are using IP tunnels in an IP
   network.  Assume also that they configure a tunnel so that the head-
   end router does not copy the TTL value from the inner IP header to
   outer IP header.  Instead, the head-end router always sets the outer
   TTL value to its maximum permitted value.  When engineers trace
   routes through the network, traceroute will always display the tunnel
   as a single IP hop, hiding all components except the tail-end
   interface.

   Now assume that engineers are using MPLS to support an IP network.
   Assume also that engineers configure an MPLS LSP so that the LSP
   ingress router copies the TTL value from the IP header to the MPLS
   header.  When engineers trace routes through the network, traceroute
   will always display the LSP as a series of IP hops, without
   indicating that they are part of a tunnel.



6. Application Requirements

   Network operators require a new route-tracing application.  The new
   application must provide all functionality that is currently provided
   by traceroute.  It also must provide enhanced tunnel tracing
   capabilities.

   The following list provides specific requirements for the new route-
   tracing application:

      1) Support in-line traces.  An in-line trace reveals the path
      between the host upon which the route-tracing application executes
      and any interface in an IP network.

      2) Support third party traces.  A third party trace reveals the
      path between any two points on a network.  The application that
      initiates a third party trace need not execute upon a host or
      router that is part of the revealed path.

      3) When tracing through a tunnel, either as part of an in-line
      trace or a third party trace, display the tunnel either as a single
      IP hop or in detail. The user's request determines how the application
      displays tunnels.

      4) When displaying a tunnel in detail, include the tunnel type
      (e.g., GRE, MPLS), the tunnel name (if applicable) and the tunnel
      identifier (if applicable).  Also, include tunnel components and
      round trip delay across each component.

      5) Permit the application user to specify whether the application
      should yield tunnel details or not.

      6) If the user requests tunnel details, also allow the user to
      specify a security token.  Network elements will use this security
      token to determine whether they will return tunnel details to that
      user.

      7) Support the following tunneling technologies: GRE, MPLS, IPSEC,
      IP/O, IP-in-IP, L2TP.

      8) Be easily extensible to support new tunnel technologies.

      9) When the tunneling technology isolates the user-plane from the
      control-plane, do not rely upon the control plane to discover the
      path.

      10) Support multiple levels of heterogeneous tunneling (e.g.,
      IP-in-IP over MPLS).

      11) Support tracing through unidirectional tunnels.

      12) Terminate gracefully when tracing through a path that exceeds
      a configurable maximum number of hops.


7. Protocol Requirements

   Implementers require a new protocol that supports the application
   described above.  This protocol reveals the path between two points
   in an IP network.  When access policy permits, the protocol also
   reveals tunnel details.


7.1. Trace-Response Information Requirements

   The protocol elicits a series of trace-response messages.  Each trace
   response message represents a hop that connects the head-end of the
   traced path to the tail-end of the traced path.  A hop can be either
   a top-level IP hop or lower-level hop along a tunnel.

   Each trace-response message contains the following information:

      1) Session Number - identifies the route-trace to which the
      current trace-response is part

      2) Requestor - identifies the device that hosts the route-tracing
      application by IP address

      3) Head-end - identifies the head-end of the traced path by IP
      address

      4) Responder - identifies the responding interface by IP address

      5) Distance - specifies the number of top-level IP hops from the
      head-end of the traced path to the Responder.

      6) Timestamp - A timestamp copied from the message that elicited
      the current trace response.  The route-tracing application uses this
      value to calculate round trip delay.

   If the trace response represents a lower-level hop along a tunnel
   path, the <<Responder>> field specifies the IP address of the top-
   level IP hop that is directly upstream of the tunnel.  The trace-
   response message also contains one or more tunnel objects, with each
   tunnel object representing a layer in the tunnel stack.  For example,
   assume that the trace-response represents an IP hop inside two nested
   IP-in-IP tunnels.  The trace-response would include two tunnel
   objects, with one tunnel object representing each of the nested IP-
   in-IP tunnels.

   Each tunnel object contains the following information:

      1) Depth - specifies depth in the tunnel stack.

      2) Type - specifies technology that implements the tunnel (e.g.,
      MPLS, IP-in-IP)

      3) Name - specifies a potentially non-unique name that is
      associated with the tunnel (e.g., LSP Name, tunnel name)

      4) Identifier - specifies a unique identifier that is associated
      with the tunnel (e.g., IP address, MPLS label).  The identifier may
      have local significance only.

      5) Head-end - identifies the device that supports the head-end of
      the tunnel by IP address

      6) Responder - identifies the device that supports the tunnel hop
      by IP address

      7) Distance - Number of tunnel hops from the head-end of the tunnel.


7.2. Trace-Probe Information Requirements

   A trace-probe message elicits trace-response messages.

   The trace-probe message contains the following information:

      1) Session Number - identifies the route trace to which the
      current trace-response is part

      2) Sequence Number - orders trace-probe messages within a
      session

      3) Requestor - identifies the device that hosts the route-tracing
      application by IP address

      4) Head-end - identifies the head-end of the traced path by IP
      address

      5) Tail-end - identifies the tail-end of the traced path by IP
      address

      6) Access control information - used by network elements to
      determine whether or not tunnel details should be revealed.

      7) Timestamp - a timestamp used to calculate round trip delay.


7.3. Network Layer Requirements

   The Internet Protocol (IP) carries trace-probe and trace-response
   messages to their destinations. IP datagrams that carry trace-probe
   and trace-probe and trace-response response messages MUST NOT include
   the loose source route, strict source route, or record route IP
   Options.


7.4. Transport Layer Requirements

   As the new protocol does not require reliable transport services, UDP
   may carry trace-probe and trace-response messages to their
   destinations.  Trace-probe and trace-response messages may also ride
   directly over IP.


7.5. Routing Requirements

   The device that hosts the route-tracing application must maintain a
   route to the head-end of the traced path.  It need not maintain
   routes to any other interface along the traced path.

   In order for the trace-response message to reach its destination, the
   device at the head-end of the traced path must maintain a route to
   the device that hosts route-tracing application.  No other device
   along the traced path need maintain a route to that device.

   Devices contained by tunnels must maintain routes to the head-end of
   the tunnel in which they are contained.  They need not maintain
   routes to all devices upstream or downstream along the traced path.

   Devices contained by the traced path, but not contained by tunnels,
   must maintain a route to the head-end of the traced path.


7.6. Maintaining State

   Because of the requirements specified in Section 7.5, devices that
   support the head-end of a tunnel must relay trace-response messages
   upstream through the traced path.  Furthermore, devices that support
   the head-end of a traced path must relay trace-response messages to
   the device that hosts the route-tracing application.

   The protocol may not require these devices to maintain any state
   information.





8. Path MTU Discovery (PMTU) [RFC-1191]

   Existing network layer tunneling protocols, such as GRE [RFC-], may
   not implement Path MTU discovery and hence may not set the Don't
   Fragment bit in the encapsulating header.  This can cause large
   packets to become fragmented within the tunnel and reassembled at the
   tunnel exit (independent of whether the payload packet is using
   PMTU).  This may or may not be a problem for some higher level
   protocols, but the behavior of the packet network itself is not
   incorrect in this case.  However, if a tunnel entry point were to use
   Path MTU discovery, that tunnel entry point would also need to relay
   ICMP unreachable error messages (in particular the "fragmentation
   needed and DF set" code) back to the originator of the packet, which
   is not in general a requirement for network layer tunneling protocols
   (and may in practice be difficult, as in the case of nested tunnels).
   Note however that failure to properly relay Path MTU information to
   an originator can result in the following behavior: the originator
   sets the don't fragment bit, the packet gets dropped within the
   tunnel, but since the originator doesn't receive proper feedback, it
   retransmits with the same PMTU, causing subsequently transmitted
   packets to be dropped.  In this case the packet network does not
   operate correctly.  How do we want to handle this? Make this
   protocol's tunnel ingress points maintain tunnel MTU?


9. IANA Guidelines

   Protocol code points [RFC-2434].


10. Security Considerations

   A configurable access control policy determines the degree to which
   features described herein are delivered.  The access control policy
   requires user identification and authorization.

   As stated above, the new protocol must not introduce security holes
   nor consume excessive resources (e.g., CPU, bandwidth).  It also must
   not be exploitable by those launching DoS attacks.


11. References

   [RFC-2026], Bradner, S., "Internet Standards Process Revision 3", RFC
   2026, Harvard University, October 1996.

   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997

   [RFC-2151], Kessler, G., Shepard, S., A Primer On Internet and TCP/IP
   Tools and Utilities, RFC 2151, Hill Associates, Inc., June 1997

   [RFC-2434] T. Narten and H. Alvestrand, "Guidelines for Writing an
   IANA Considerations Section in RFCs", RFC 2434, October, 1998.

   [RFC-2637] Hamzeh, K. et. al., "Point-to-Point Tunneling Protocol
   (PPTP)", RFC 2637, July, 1999.



12. Acknowledgements

   Thanks to Randy Bush and Steve Bellovin for their comments.


13. Author's Addresses

      Ronald P. Bonica
      WorldCom
      22001 Loudoun County Pkwy
      Ashburn, Virginia, 20147
      Phone: 703 886 1681
      Email: rbonica@mci.net

      Kireeti Kompella
      Juniper Networks, Inc.
      1194 N. Mathilda Ave.
      Sunnyvale, California 94089
      Email: kireeti@juniper.net

      Dave Myers
      Cisco Systems
      170 Tasman Drive
      San Jose, California 94025
      Email: dmm@cisco.com


14. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.