Internet Draft R. Bonica Expiration Date: June 2001 WorldCom K. Kompella Juniper Networks D. Meyer Cisco Systems December 2000 Tracing Requirements for Generic Tunnels draft-bonica-tunneltrace-00.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 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. Existing traceroute applications are also deficient in that they do not support third party traces. A third party trace is a trace that is initiated by a device other than the device at the head end of the traced path. As many of the tunneling technologies listed above implement unidirectional tunnels only, third party traces become increasingly valuable. 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. 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. 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 routing loop. 13) 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 <> 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. Network Layer Requirements The Internet Protocol (IP) carries trace-response messages to the route-tracing application. 7.3. Transport Layer Requirements As the new protocol does not require reliable transport services, UDP may carry trace-response messages to the route-tracing application. Trace-response messages may also ride directly over IP. 7.4. 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.5. Maintaining State Because of the requirements specified in Section 7.3, 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. 7.6. Trace-Stimulus A trace-stimulus message elicits trace-response messages. The trace-stimulus 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-stimulus 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.7. Trace-Stimulus Processing The route-tracing application emits a series of trace-stimulus messages. Each trace-stimulus messages elicits exactly one trace- response message that represents a top-level IP hop. It may also elicit additional trace-response messages that represent intermediate hops along tunnels that connect the top-level IP hop to the subsequent top-level IP hop. The route tracing application encapsulates the trace-stimulus message in an IP header and sends it to the device that supports the head-end of the traced path. The head-end device strips off the IP header and replaces it with a new one. The following rules govern new IP header specification: 1) Source address = trace-stimulus.head-end 2) Destination address = trace-stimulus.tail-end 3) TTL = trace-stimulus.sequence-number The trace-stimulus either reaches the tail-end of the traced path or times out due to TTL expiration. In either case, the head-end device receives a trace-response message and relays that message to the device that hosts the route-tracing application. Having received the trace-response message, the route-tracing application determines whether that message is from the tail-end of the traced path. If so, the route-tracing application terminates. If not, the route tracing application increments the trace-stimulus sequence number and sends another trace-stimulus message. If any device receives a trace-stimulus message with TTL equal to 1, and that device determines that the next hop is supported by a tunnel, the device exercises access control procedures to determine whether it should reveal tunnel details. If it should, it executes tunnel specific procedures to discover tunnel details and sends an additional trace-response message representing each hop along the tunnel. Tunnel specific procedures are deferred for protocol specification. 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. Bonica, Kompella, Meyer [Page 11]