Network Working Group                                          R. Bonica
Request for Comments: 3609                                           MCI
Category: Informational                                      K. Kompella
                                                       Juniper Networks
                                                               D. Meyer
                                                                 Sprint
                                                         September 2003


               Tracing Requirements for Generic Tunnels

Status of this Memo

  This memo provides information for the Internet community.  It does
  not specify an Internet standard of any kind.  Distribution of this
  memo is unlimited.

Copyright Notice

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

Abstract

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

  The generic route-tracing application, specified herein, supports a
  superset of the functionality that "traceroute" currently offers.
  Like traceroute, the generic route-tracing application can discover
  the forwarding path between two interfaces that are contained by an
  IP network.  Unlike traceroute, this application can reveal details
  regarding tunnels that support the IP forwarding path.

1.  Introduction

  IP networks utilize several tunneling technologies.  Although these
  tunneling technologies provide operators with many useful features,
  they also present management challenges.  Network operators require a
  generic route-tracing application that they can use to verify the
  correct operation of the IP forwarding plane.  The generic
  route-tracing application must be capable of detecting tunnels and
  revealing tunnel details.  The application also must be useful in
  diagnosing tunnel faults.




Bonica, et al.               Informational                      [Page 1]

RFC 3609        Tracing Requirements for Generic Tunnels  September 2003


  Implementors also require a new protocol that will support the
  generic-route tracing application.  This document specifies
  requirements for that protocol.  It specifies requirements,
  primarily, by detailing the desired capabilities of the generic
  route-tracing application.  A particular version of generic
  route-tracing application may implement some subset of the desired
  capabilities.  It may also implement a superset of those
  capabilities.  However, protocol designers are not required to
  consider the additional capabilities when designing the new protocol.

  This document also specifies a few protocol requirements, stated as
  such.  These requirements are driven by desired characteristics of
  the generic route-tracing application.  Whenever a protocol
  requirement is stated, it is mapped to the desired characteristic of
  the route-tracing application.

2.  Review of Existing Functionality

  Currently, network operators use "traceroute" to trace through the
  forwarding path of 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 the tunnel as a collection of
  IP hops, without indicating that they are part of a tunnel.

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

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









Bonica, et al.               Informational                      [Page 2]

RFC 3609        Tracing Requirements for Generic Tunnels  September 2003


3.  Application Requirements

  Network operators require a new route-tracing application.  The new
  application must support all functionality that traceroute currently
  offers.  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), (6), (8), (10), (13), and (14).

     Justification: Operators may need to discover network forwarding
     details, while concealing those details from unauthorized parties.

     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.

     Justification: Operators need to discover how the network would
     forward a datagram between any two IP interfaces.

     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.

     Justification: Operators need to discover how the network would
     forward a datagram between any two IP interfaces.

     4) Support partial traces through broken paths or tunnels.

     Justification: Operators need to identify the root cause of
     forwarding plane failures.

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




Bonica, et al.               Informational                      [Page 3]

RFC 3609        Tracing Requirements for Generic Tunnels  September 2003


     Justification: As they discover IP forwarding details, operators
     may need to reveal or mask tunneling details.

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

     Justification: As they discover IP forwarding details, operators
     may need to reveal tunneling details.

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

     Justification: Operators will use the generic route-tracing
     application to discover how an IP network forwards datagrams.  As
     many tunnel types may support the IP network, the generic
     route-tracing application must detect and reveal details
     concerning multiple tunnel types.

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

     Justification: Operators will use the generic route-tracing
     application to discover how an IP network forwards datagrams.  As
     nested, heterogeneous tunnels may support the IP network, the
     generic route-tracing application must detect and reveal details
     concerning nested, heterogeneous tunnels.

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

     Justification: Operators need to identify the root cause of
     forwarding plane failures.  Control plane information is sometimes
     useful in determining the cause of forwarding plane failure.

     10) Support control plane tracing for all tunnel types.  When
     tracing through the control plane, the hop ingress device reports
     hop details.  The hop ingress device is the device that originates
     the hop.

     Justification: Control plane information is available regarding
     all tunnel types.






Bonica, et al.               Informational                      [Page 4]

RFC 3609        Tracing Requirements for Generic Tunnels  September 2003


     11) Support tracing through forwarding plane for all tunnel types
     that implement TTL decrement (or some similar mechanism).  When
     tracing through the forwarding plane, the hop egress device
     reports hop details.  The hop egress device is the device that
     terminates the hop.

     Justification: Forwarding plane information may not be available
     for tunnels that do not support TTL decrement.

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

     Justification: Forwarding plane information is always available,
     regardless of whether the tunnel engages in TTL propagation.

     13) When tracing through the control plane, display the MTU
     associated with each interface that forwards datagrams through the
     traced path.

     Justification: MTU information is sometimes useful in identifying
     the root cause of forwarding and control plane failures.

     14) When tracing through the forwarding plane, display the MTU
     associated with each interface that receives datagrams along the
     traced path.

     Justification: MTU information is sometimes useful in identifying
     the root cause of forwarding and control plane failures.

     15) Support partial traces through paths containing devices that
     do not provide protocol support for generic route tracing.  When
     the application encounters such a device, it should inform the
     user and attempt to discover details regarding the next interface
     downstream.

     Justification: The application must provide useful information
     even if the supporting protocol is not universally deployed.

4.  Protocol Requirements

  Implementors require a new protocol that supports the generic
  route-tracing application.  This protocol reveals the path between
  two points in an IP network.  When access policy permits, the
  protocol also reveals tunnel details.




Bonica, et al.               Informational                      [Page 5]

RFC 3609        Tracing Requirements for Generic Tunnels  September 2003


4.1.  Information Requirements

  The protocol consists of probes and probe responses.  Each probe
  elicits exactly one response.  Each response represents a hop that
  contributes to the path between two interfaces.  A hop can be either
  a top-level IP hop or lower-level hop that is contained by a tunnel.

  Justification: Because the generic route-tracing application must
  trace through broken paths, the required protocol must use a separate
  response message to deliver details regarding each hop.  The protocol
  must use a separate probe to elicit each response because the
  alternative approach, using the single probe with the IP Router Alert
  Option, is unacceptable.  Many networks forward datagrams that
  specify IP options differently than they would forward datagrams that
  do not specify IP options.  Therefore, the introduction of IP options
  would cause the application to trace a forwarding path other than the
  path that its user intended to trace.

4.2.  Transport Layer Requirements

  UDP should carry all protocol messages to their destinations.  Other
  transport mechanisms may be considered when protocol details are
  specified.

  Justification: Because the probe/response scheme described above is
  stateless, a stateless transport is required.  Candidate transports
  included UDP over IP, IP and ICMP.  ICMP was disqualified because
  carrying MPLS information in an ICMP datagram would constitute a
  layer violation.  IP was disqualified in order to conserve protocol
  identifiers.

4.3.  Stateless Protocol

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

  Justification: Statelessness is required to support scaling and to
  prevent denial of service attacks.

4.4.  Routing Requirements

  The device that hosts the route-tracing application must maintain an
  IP route to the ingress of the traced path.  It must also maintain an
  IP route to the ingress 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.




Bonica, et al.               Informational                      [Page 6]

RFC 3609        Tracing Requirements for Generic Tunnels  September 2003


  All of the devices to which the route-tracing application must
  maintain a route must maintain a route back to 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.

  Justification: The protocol must be sufficiently robust to operate
  when tunnel interior devices do not maintain a route back to the
  device that hosts the route tracing application.

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

  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.

6.  Informative References

  [RFC-2151]  Kessler, G. and S. Shepard, "A Primer On Internet and
              TCP/IP Tools and Utilities", FYI 30, RFC 2151, June 1997.

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

7.  Acknowledgements

  Thanks to Randy Bush and Steve Bellovin for their comments.

















Bonica, et al.               Informational                      [Page 7]

RFC 3609        Tracing Requirements for Generic Tunnels  September 2003


8.  Authors' Addresses

  Ronald P. Bonica
  MCI
  22001 Loudoun County Pkwy
  Ashburn, Virginia, 20147

  EMail: [email protected]


  Kireeti Kompella
  Juniper Networks, Inc.
  1194 N. Mathilda Ave.
  Sunnyvale, California 94089

  EMail: [email protected]


  David Meyer

  EMail: [email protected]






























Bonica, et al.               Informational                      [Page 8]

RFC 3609        Tracing Requirements for Generic Tunnels  September 2003


9.  Full Copyright Statement

  Copyright (C) The Internet Society (2003).  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 assignees.

  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.

Acknowledgement

  Funding for the RFC Editor function is currently provided by the
  Internet Society.



















Bonica, et al.               Informational                      [Page 9]


You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.