Internet Draft                                                R. Bonica
Expiration Date: October 2003                                 WorldCom
                                                            K. Kompella
                                                       Juniper Networks
                                                               D. Meyer
                                                                 Sprint
                                                             April 2003

                Tracing Requirements for Generic Tunnels
                     draft-ietf-ccamp-tracereq-01

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.

Abstract

   This document specifies requirements for a generic route-tracing
   application.  It also specifies requirements for a protocol that will
   support the generic route-tracing application. Network operators will
   use the generic route-tracing application to verify proper operation
   of the IP forwarding plane. They also use the generic route-tracing
   application to discover details regarding tunnels that support IP
   forwarding.


. Introduction

   Currently, the IETF supports several tunneling technologies.
   Although these tunneling technologies provide operators with many
   useful features, they also present management challenges.  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 for a protocol that will
   support the generic route-tracing application. Network operators will
   use the generic route-tracing application to verify proper operation
   of the IP forwarding plane. They also use the generic route-tracing
   application to discover details regarding tunnels that support IP
   forwarding.




. 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 tunnel tracing.

   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 deploy 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 deploy MPLS in an IP network.  Assume also
   that engineers configure an MPLS LSP so that the ingress router
   propagates the TTL value from the IP header to the MPLS header.  When
   engineers trace routes through the network, traceroute will display
   the LSP as a series of IP hops, without indicating that they are part
   of a tunnel.



. Application Requirements

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

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

      1) Support the notion of a security token as part of the tunnel
      trace request.  The security token identifies the tracer's
      privileges in tracing tunnels.  Network elements will use this
      security token to determine whether or not to return the requested
      information to the tracer.  In particular, appropriate privileges
      are required for items (2), (3), (5), (8), (9), (12), and (13).

      2) 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.

      3) Support third party traces.  A third party trace reveals the
      path between any two points in an IP network.  The application
      that initiates a third party trace need not execute upon a host or
      router that is part of the traced path. Unlike existing solutions
      [RFC-2151] [RFC-2925], the application will not rely upon IP
      options or require access to the SNMP agent in order to support
      third-party traces.

      4) 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, subject to the user having
      permission to do this.

      5) 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.

      6) Support the following tunneling technologies: GRE, MPLS, IPSEC,
      GMPLS, IP-in-IP, L2TP. Be easily extensible to suppport new tunnel
      technologies.

      7) Trace through nested, heterogeneous tunnels (e.g., IP-in-IP
      over MPLS).

      8) At the users request, trace through the forwarding plane, the
      control plane or both.

      9) Support control plane tracing for all tunnel types. When
      tracing through the control plane, the device at the head-end of a
      hop reports hop details.

      10) Support tracing through forwarding plane for all tunnel types
      that implement TTL decrement (or some similar mechanism). When
      tracing through the forwarding plane, the device at the tail-end
      of a hop reports hop details.

      11) Support tracing through the forwarding plane for all tunnel
      types that implement TTL decrement, regardless of whether the
      tunnel engages in TTL propagation. (That is, support tunnel
      tracing regardless of whether the TTL value is copied from an
      inner header to an outer header at tunnel ingress).

      12) When tracing through the control plane, display the MTU
      associated with each hop.

      13) When tracing through the forwarding plane, display the MTU
      associated with each hop in the reverse direction.



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


4.1. Information Requirements

   The protocol consists of probes and probe responses. Each probe
   elicits exactly one response. Each response 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 that is contained by a tunnel.



4.2. Transport Layer Requirements

   UDP carries all protocol messages to their destinations.


4.3. Routing Requirements

   The device that hosts the route-tracing application must maintain an
   IP route to the head-end of the traced path. It must also maintain an
   IP route to the head-end of each tunnel for which it is requesting
   tunnel details. The device that hosts the tunnel tracing application
   need not maintain a route to any other device that supports the
   traced path.

   All of the devices mentioned above must maintain an IP route back to
   the device that hosts the route-tracing application.

   In order for the protocol to provide tunnel details, all devices
   contained by a tunnel must maintain an IP route to the tunnel
   ingress.


4.4. Stateless Protocol

   The protocol must be stateless. That is, no node should have to
   maintain state between successive traceroute messages.


. 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 or replaying
   messages.


. Informative References

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

   [RFC-2925], White, K., "Definitions of Managed Objects for Remote
   Ping, Traceroute, and Lookup Operations", RFC 2925, September, 2000.













. Acknowledgements

   Thanks to Randy Bush and Steve Bellovin for their comments.


. 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
      Email: dmm@sprint.net



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