draft-ietf-ccamp-tracereq-04.txt   rfc3609.txt 
Internet Draft R. Bonica Network Working Group R. Bonica
Category: Informational MCI Request for Comments: 3609 MCI
Expiration Date: December 2003 K. Kompella Category: Informational K. Kompella
Juniper Networks Juniper Networks
D. Meyer D. Meyer
Sprint Sprint
June 2003 September 2003
Tracing Requirements for Generic Tunnels Tracing Requirements for Generic Tunnels
draft-ietf-ccamp-tracereq-04
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC-2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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 Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2003). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This document specifies requirements for a generic route-tracing This document specifies requirements for a generic route-tracing
application. It also specifies requirements for a protocol that will application. It also specifies requirements for a protocol that will
support that application. Network operators will use the generic support that application. Network operators will use the generic
route-tracing application to verify proper operation of the IP route-tracing application to verify proper operation of the IP
forwarding plane. They will also use the application to discover forwarding plane. They will also use the application to discover
details regarding tunnels that support IP forwarding. details regarding tunnels that support IP forwarding.
The generic route-tracing application, specified herein, supports a The generic route-tracing application, specified herein, supports a
superset of the functionality that "traceroute" currently offers. superset of the functionality that "traceroute" currently offers.
Like traceroute, the generic route-tracing application can discover Like traceroute, the generic route-tracing application can discover
the forwarding path between two interfaces that are contained by an the forwarding path between two interfaces that are contained by an
IP network. Unlike traceroute, this application can reveal details IP network. Unlike traceroute, this application can reveal details
regarding tunnels that support the IP forwarding path. regarding tunnels that support the IP forwarding path.
Bonica, Kompella, Meyer [Page 1]
1. Introduction 1. Introduction
IP networks utilize several tunneling technologies. Although these IP networks utilize several tunneling technologies. Although these
tunneling technologies provide operators with many useful features, tunneling technologies provide operators with many useful features,
they also present management challenges. Network operators require a they also present management challenges. Network operators require a
generic route-tracing application that they can use to verify the generic route-tracing application that they can use to verify the
correct operation of the IP forwarding plane. The generic route- correct operation of the IP forwarding plane. The generic
tracing application must be capable of detecting tunnels and route-tracing application must be capable of detecting tunnels and
revealing tunnel details. The application also must be useful in revealing tunnel details. The application also must be useful in
diagnosing tunnel faults. diagnosing tunnel faults.
Implementors also require a new protocol that will support the Implementors also require a new protocol that will support the
generic-route tracing application. This document specifies generic-route tracing application. This document specifies
requirements for that protocol. It specifies requirements, primarily, requirements for that protocol. It specifies requirements,
by detailing the desired capabilities of the generic route-tracing primarily, by detailing the desired capabilities of the generic
application. A particular version of generic route-tracing route-tracing application. A particular version of generic
application may implement some subset of the desired capabilities. It route-tracing application may implement some subset of the desired
may also implement a superset of those capabilities. However, capabilities. It may also implement a superset of those
protocol designers are not required to consider the additional capabilities. However, protocol designers are not required to
capabilities when designing the new protocol. consider the additional capabilities when designing the new protocol.
This document also specifies a few protocol requirements, stated as This document also specifies a few protocol requirements, stated as
such. These requirements are driven by desired characteristics of the such. These requirements are driven by desired characteristics of
generic route-tracing application. Whenever a protocol requirement is the generic route-tracing application. Whenever a protocol
stated, it is mapped to desired characteristic of the route-tracing requirement is stated, it is mapped to the desired characteristic of
application. the route-tracing application.
2. Review of Existing Functionality 2. Review of Existing Functionality
Currently, network operators use "traceroute" to trace through the Currently, network operators use "traceroute" to trace through the
forwarding path of an IP network. Section 3.4 of [RFC-2151] provides forwarding path of an IP network. Section 3.4 of [RFC-2151] provides
a thorough description of traceroute. Although traceroute is very a thorough description of traceroute. Although traceroute is very
reliable and very widely deployed, it is deficient with regard to reliable and very widely deployed, it is deficient with regard to
tunnel tracing. tunnel tracing.
Depending upon tunnel type, traceroute may display an entire tunnel Depending upon tunnel type, traceroute may display an entire tunnel
skipping to change at line 97 skipping to change at page 2, line 41
IP hops, without indicating that they are part of a tunnel. IP hops, without indicating that they are part of a tunnel.
For example, assume that engineers deploy an IP tunnel in an IP For example, assume that engineers deploy an IP tunnel in an IP
network. Assume also that they configure the tunnel so that the network. Assume also that they configure the tunnel so that the
ingress router does not copy the TTL value from the inner IP header ingress router does not copy the TTL value from the inner IP header
to outer IP header. Instead, the ingress router always sets the to outer IP header. Instead, the ingress router always sets the
outer TTL value to its maximum permitted value. When engineers trace outer TTL value to its maximum permitted value. When engineers trace
through the network, traceroute will always display the tunnel as a through the network, traceroute will always display the tunnel as a
single IP hop, hiding all components except the egress interface. single IP hop, hiding all components except the egress interface.
Bonica, Kompella, Meyer [Page 2]
Now assume that engineers deploy an MPLS LSP in an IP network. Now assume that engineers deploy an MPLS LSP in an IP network.
Assume also that engineers configure the MPLS LSP so that the ingress Assume also that engineers configure the MPLS LSP so that the ingress
router propagates the TTL value from the IP header to the MPLS router propagates the TTL value from the IP header to the MPLS
header. When engineers trace through the network, traceroute will header. When engineers trace through the network, traceroute will
display the LSP as a series of IP hops, without indicating that they display the LSP as a series of IP hops, without indicating that they
are part of a tunnel. are part of a tunnel.
3. Application Requirements 3. Application Requirements
Network operators require a new route-tracing application. The new Network operators require a new route-tracing application. The new
application must support all functionality that traceroute currently application must support all functionality that traceroute currently
offers. It also must provide enhanced tunnel tracing capabilities. offers. It also must provide enhanced tunnel tracing capabilities.
The following list provides specific requirements for the new route- The following list provides specific requirements for the new
tracing application: route-tracing application:
1) Support the notion of a security token as part of the tunnel 1) Support the notion of a security token as part of the tunnel
trace request. The security token identifies the tracer's trace request. The security token identifies the tracer's
privileges in tracing tunnels. Network elements will use this privileges in tracing tunnels. Network elements will use this
security token to determine whether or not to return the requested security token to determine whether or not to return the requested
information to the tracer. In particular, appropriate privileges information to the tracer. In particular, appropriate privileges
are required for items (2), (3), (6), (8), (10), (13), and (14). are required for items (2), (3), (6), (8), (10), (13), and (14).
Justification: Operators may need to discover network forwarding Justification: Operators may need to discover network forwarding
details, while concealing those details from unauthorized parties. details, while concealing those details from unauthorized parties.
skipping to change at line 144 skipping to change at page 3, line 44
router that is part of the traced path. Unlike existing solutions router that is part of the traced path. Unlike existing solutions
[RFC-2151] [RFC-2925], the application will not rely upon IP [RFC-2151] [RFC-2925], the application will not rely upon IP
options or require access to the SNMP agent in order to support options or require access to the SNMP agent in order to support
third-party traces. third-party traces.
Justification: Operators need to discover how the network would Justification: Operators need to discover how the network would
forward a datagram between any two IP interfaces. forward a datagram between any two IP interfaces.
4) Support partial traces through broken paths or tunnels. 4) Support partial traces through broken paths or tunnels.
Bonica, Kompella, Meyer [Page 3]
Justification: Operators need to identify the root cause of Justification: Operators need to identify the root cause of
forwarding plane failures. forwarding plane failures.
5) When tracing through a tunnel, either as part of an in-line 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 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 single IP hop or in detail. The user's request determines how the
application displays tunnels, subject to the user having application displays tunnels, subject to the user having
permission to do this. permission to do this.
Justification: As they discover IP forwarding details, operators Justification: As they discover IP forwarding details, operators
skipping to change at line 172 skipping to change at page 4, line 23
Justification: As they discover IP forwarding details, operators Justification: As they discover IP forwarding details, operators
may need to reveal tunneling details. may need to reveal tunneling details.
7) Support the following tunneling technologies: GRE, MPLS, IPSEC, 7) Support the following tunneling technologies: GRE, MPLS, IPSEC,
GMPLS, IP-in-IP, L2TP. Be easily extensible to support new tunnel GMPLS, IP-in-IP, L2TP. Be easily extensible to support new tunnel
technologies. technologies.
Justification: Operators will use the generic route-tracing Justification: Operators will use the generic route-tracing
application to discover how an IP network forwards datagrams. As application to discover how an IP network forwards datagrams. As
many tunnel types may support the IP network, the generic route- many tunnel types may support the IP network, the generic
tracing application must detect and reveal details concerning route-tracing application must detect and reveal details
multiple tunnel types. concerning multiple tunnel types.
8) Trace through nested, heterogeneous tunnels (e.g., IP-in-IP 8) Trace through nested, heterogeneous tunnels (e.g., IP-in-IP
over MPLS). over MPLS).
Justification: Operators will use the generic route-tracing Justification: Operators will use the generic route-tracing
application to discover how an IP network forwards datagrams. As application to discover how an IP network forwards datagrams. As
nested, heterogeneous tunnels may support the IP network, the nested, heterogeneous tunnels may support the IP network, the
generic route-tracing application must detect and reveal details generic route-tracing application must detect and reveal details
concerning nested, heterogeneous tunnels. concerning nested, heterogeneous tunnels.
9) At the users request, trace through the forwarding plane, the 9) At the users request, trace through the forwarding plane, the
control plane or both. control plane or both.
Justification: Operators need to identify the root cause of Justification: Operators need to identify the root cause of
forwarding plane failures. Control plane information is sometimes forwarding plane failures. Control plane information is sometimes
useful in determining the cause of forwarding plane failure. useful in determining the cause of forwarding plane failure.
10) Support control plane tracing for all tunnel types. When 10) Support control plane tracing for all tunnel types. When
Bonica, Kompella, Meyer [Page 4]
tracing through the control plane, the hop ingress device reports tracing through the control plane, the hop ingress device reports
hop details. The hop ingress device is the device that originates hop details. The hop ingress device is the device that originates
the hop. the hop.
Justification: Control plane information is available regarding Justification: Control plane information is available regarding
all tunnel types. all tunnel types.
11) Support tracing through forwarding plane for all tunnel types 11) Support tracing through forwarding plane for all tunnel types
that implement TTL decrement (or some similar mechanism). When that implement TTL decrement (or some similar mechanism). When
tracing through the forwarding plane, the hop egress device tracing through the forwarding plane, the hop egress device
reports hop details. The hop egress devices is the device that reports hop details. The hop egress device is the device that
terminates the hop. terminates the hop.
Justification: Forwarding plane information may not be available Justification: Forwarding plane information may not be available
regarding tunnels that do not support TTL decrement. for tunnels that do not support TTL decrement.
12) Support tracing through the forwarding plane for all tunnel 12) Support tracing through the forwarding plane for all tunnel
types that implement TTL decrement, regardless of whether the types that implement TTL decrement, regardless of whether the
tunnel engages in TTL propagation. (That is, support tunnel tunnel engages in TTL propagation. (That is, support tunnel
tracing regardless of whether the TTL value is copied from an tracing regardless of whether the TTL value is copied from an
inner header to an outer header at tunnel ingress). inner header to an outer header at tunnel ingress.)
Justification: Forwarding plane information is always available, Justification: Forwarding plane information is always available,
regardless of whether the tunnel engages in TTL propagation. regardless of whether the tunnel engages in TTL propagation.
13) When tracing through the control plane, display the MTU 13) When tracing through the control plane, display the MTU
associated with interface that forwards datagrams through the associated with each interface that forwards datagrams through the
traced path. traced path.
Justification: MTU information is sometimes useful in identifying Justification: MTU information is sometimes useful in identifying
the root cause of forwarding and control plane failures. the root cause of forwarding and control plane failures.
14) When tracing through the forwarding plane, display the MTU 14) When tracing through the forwarding plane, display the MTU
associated with each interface that receives datagtrams along the associated with each interface that receives datagrams along the
traced path. traced path.
Justification: MTU information is sometimes useful in identifying Justification: MTU information is sometimes useful in identifying
the root cause of forwarding and control plane failures. the root cause of forwarding and control plane failures.
15) Support partial traces through paths containing devices that 15) Support partial traces through paths containing devices that
do not provide protocol support for generic route tracing. When do not provide protocol support for generic route tracing. When
the application encounters such a device, it should inform the the application encounters such a device, it should inform the
user and attempt to discover details regarding the next interface user and attempt to discover details regarding the next interface
downstream. downstream.
Justification: The application must provide useful information Justification: The application must provide useful information
even if the supporting protocol is not universally deployed. even if the supporting protocol is not universally deployed.
Bonica, Kompella, Meyer [Page 5]
4. Protocol Requirements 4. Protocol Requirements
Implementors require a new protocol that supports the generic route- Implementors require a new protocol that supports the generic
tracing application. This protocol reveals the path between two route-tracing application. This protocol reveals the path between
points in an IP network. When access policy permits, the protocol two points in an IP network. When access policy permits, the
also reveals tunnel details. protocol also reveals tunnel details.
4.1. Information Requirements 4.1. Information Requirements
The protocol consists of probes and probe responses. Each probe The protocol consists of probes and probe responses. Each probe
elicits exactly one response. Each response represents a hop that elicits exactly one response. Each response represents a hop that
that contributes to the path between two interfaces. A hop can be contributes to the path between two interfaces. A hop can be either
either a top-level IP hop or lower-level hop that is contained by a a top-level IP hop or lower-level hop that is contained by a tunnel.
tunnel.
Justification: Because the generic route-tracing application must Justification: Because the generic route-tracing application must
trace through broken paths, the required protocol must use a separate trace through broken paths, the required protocol must use a separate
response message to deliver details regarding each hop. The protocol response message to deliver details regarding each hop. The protocol
must use a separate probe to elicit each response because the must use a separate probe to elicit each response because the
alternative approach, using the single probe with the IP Router Alert alternative approach, using the single probe with the IP Router Alert
Option, is unacceptable. Many networks forward datagrams that specify Option, is unacceptable. Many networks forward datagrams that
IP options differently than they would forward datagrams that do not specify IP options differently than they would forward datagrams that
specify IP options. Therefore, the introductions of IP options would do not specify IP options. Therefore, the introduction of IP options
cause the application to trace a forwarding path other than the path would cause the application to trace a forwarding path other than the
that its user intended to trace. path that its user intended to trace.
4.2. Transport Layer Requirements 4.2. Transport Layer Requirements
UDP carries all protocol messages to their destinations. 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 Justification: Because the probe/response scheme described above is
stateless, a stateless transport is required. Candidate transports stateless, a stateless transport is required. Candidate transports
included UDP over IP, IP and ICMP. ICMP was disqualified because included UDP over IP, IP and ICMP. ICMP was disqualified because
carrying MPLS information in an ICMP datagram would constitute a carrying MPLS information in an ICMP datagram would constitute a
layer violation. IP was disqualified in order to conserve protocol layer violation. IP was disqualified in order to conserve protocol
identifiers. identifiers.
4.3. Stateless Protocol 4.3. Stateless Protocol
The protocol must be stateless. That is, nodes should not have to The protocol must be stateless. That is, nodes should not have to
maintain state between successive traceroute messages. maintain state between successive traceroute messages.
Justification: Statelessness is required to support scaling and to Justification: Statelessness is required to support scaling and to
prevent denial of service attacks. prevent denial of service attacks.
Bonica, Kompella, Meyer [Page 6]
4.4. Routing Requirements 4.4. Routing Requirements
The device that hosts the route-tracing application must maintain an 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 the traced path. It must also maintain an
IP route to the ingress of each tunnel for which it is requesting IP route to the ingress of each tunnel for which it is requesting
tunnel details. The device that hosts the tunnel tracing application tunnel details. The device that hosts the tunnel tracing application
need not maintain a route to any other device that supports the need not maintain a route to any other device that supports the
traced path. traced path.
All of the devices to which the route-tracing application must All of the devices to which the route-tracing application must
skipping to change at line 325 skipping to change at page 7, line 29
A configurable access control policy determines the degree to which A configurable access control policy determines the degree to which
features described herein are delivered. The access control policy features described herein are delivered. The access control policy
requires user identification and authorization. requires user identification and authorization.
The new protocol must not introduce security holes nor consume The new protocol must not introduce security holes nor consume
excessive resources (e.g., CPU, bandwidth). It also must not be excessive resources (e.g., CPU, bandwidth). It also must not be
exploitable by those launching DoS attacks or replaying messages. exploitable by those launching DoS attacks or replaying messages.
6. Informative References 6. Informative References
[RFC-2151], Kessler, G., Shepard, S., A Primer On Internet and TCP/IP [RFC-2151] Kessler, G. and S. Shepard, "A Primer On Internet and
Tools and Ut ilities, RFC 2151, Hill Associates, Inc., June 1997 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.
Bonica, Kompella, Meyer [Page 7] [RFC-2925] White, K., "Definitions of Managed Objects for Remote
Ping, Traceroute, and Lookup Operations", RFC 2925,
September 2000.
7. Acknowledgements 7. Acknowledgements
Thanks to Randy Bush and Steve Bellovin for their comments. Thanks to Randy Bush and Steve Bellovin for their comments.
8. Authors' Addresses 8. Authors' Addresses
Ronald P. Bonica Ronald P. Bonica
MCI MCI
22001 Loudoun County Pkwy 22001 Loudoun County Pkwy
Ashburn, Virginia, 20147 Ashburn, Virginia, 20147
Email: ronald.p.bonica@mci.com
EMail: ronald.p.bonica@mci.com
Kireeti Kompella Kireeti Kompella
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, California 94089 Sunnyvale, California 94089
Email: kireeti@juniper.net
EMail: kireeti@juniper.net
David Meyer David Meyer
Email: dmm@maoz.com
EMail: dmm@maoz.com
9. Full Copyright Statement 9. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
Bonica, Kompella, Meyer [Page 8]
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Bonica, Kompella, Meyer [Page 9] Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/