idnits 2.17.1 draft-ietf-ccamp-tracereq-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 363 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2002) is 7924 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC-2434' is defined on line 213, but no explicit reference was found in the text == Unused Reference: 'RFC-2637' is defined on line 216, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft R. Bonica 2 Expiration Date: February 2003 WorldCom 3 K. Kompella 4 Juniper Networks 5 D. Meyer 6 Sprint 7 August 2002 9 Tracing Requirements for Generic Tunnels 10 draft-ietf-ccamp-tracereq-00 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of [RFC-2026]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Abstract 33 This document specifies requirements for a generic route-tracing 34 application. It also specifies requirements for a protocol that will 35 support the generic route-tracing application. 37 3. Conventions used in this document 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in [RFC-2119]. 43 4. Introduction 45 Currently, the IETF supports several tunneling technologies. 46 Although these tunneling technologies provide operators with many 47 useful features, they also present management challenges. Operators 48 require a generic route-tracing application that they can use to 49 verify tunnel paths and diagnose tunnel faults. 51 This document specifies requirements for that generic route-tracing 52 application. It also specifies requirements for a protocol that will 53 support the generic route-tracing application. 55 5. Review of Existing Functionality 57 Currently, network operators use "traceroute" to identify the path 58 toward any destination in an IP network. Section 3.4 of [RFC-2151] 59 provides a thorough description of traceroute. Although traceroute 60 is very reliable and very widely deployed, it is deficient with 61 regard to tunnel tracing. 63 Depending upon tunnel type, traceroute may display an entire tunnel 64 as a single IP hop, or it may display a tunnel as a collection of IP 65 hops, without indicating that they are part of a tunnel. 67 For example, assume that engineers deploy IP tunnels in an IP 68 network. Assume also that they configure a tunnel so that the head- 69 end router does not copy the TTL value from the inner IP header to 70 outer IP header. Instead, the head-end router always sets the outer 71 TTL value to its maximum permitted value. When engineers trace 72 routes through the network, traceroute will always display the tunnel 73 as a single IP hop, hiding all components except the tail-end 74 interface. 76 Now assume that engineers deploy MPLS in an IP network. Assume also 77 that engineers configure an MPLS LSP so that the ingress router 78 propagates the TTL value from the IP header to the MPLS header. When 79 engineers trace routes through the network, traceroute will display 80 the LSP as a series of IP hops, without indicating that they are part 81 of a tunnel. 83 6. Application Requirements 85 Network operators require a new route-tracing application. The new 86 application must provide all functionality that traceroute currently 87 provides. It also must provide enhanced tunnel tracing capabilities. 89 The following list provides specific requirements for the new route- 90 tracing application: 92 1) Support the notion of a security token as part of the tunnel 93 trace request. The security token identifies the tracer's 94 privileges in tracing tunnels. Network elements will use this 95 security token to determine whether or not to return the requested 96 information to the tracer. In particular, appropriate privileges 97 are required for items (2), (3), (5), (8), (12), and (13). 99 2) Support in-line traces. An in-line trace reveals the path 100 between the host upon which the route-tracing application executes 101 and any interface in an IP network. 103 3) Support third party traces. A third party trace reveals the 104 path between any two points in an IP network. The application 105 that initiates a third party trace need not execute upon a host or 106 router that is part of the traced path. 108 4) When tracing through a tunnel, either as part of an in-line 109 trace or a third party trace, display the tunnel either as a 110 single IP hop or in detail. The user's request determines how the 111 application displays tunnels, subject to the user having 112 permission to do this. 114 5) When displaying a tunnel in detail, include the tunnel type 115 (e.g., GRE, MPLS), the tunnel name (if applicable) and the tunnel 116 identifier (if applicable). Also, include tunnel components and 117 round trip delay across each component. 119 6) Support the following tunneling technologies: GRE, MPLS, IPSEC, 120 GMPLS, IP-in-IP, L2TP. Be easily extensible to suppport new tunnel 121 technologies. 123 7) Trace through nested, heterogeneous tunnels (e.g., IP-in-IP 124 over MPLS). 126 8) At the users request, trace through the forwarding plane, the 127 control plane or both. 129 9) Support control plane tracing for all tunnel types. When 130 tracing through the control plane, the device at the head-end of a 131 hop reports hop details. 133 10) Support tracing through forwarding plane for all tunnel types 134 that implement TTL decrement (or some similar mechanism). When 135 tracing through the forwarding plane, the device at the tail-end 136 of a hop reports hop details. 138 11) Support tracing through the forwarding plane for all tunnel 139 types that implement TTL decrement, regardless of whether the 140 tunnel engages in TTL propagation. (That is, support tunnel 141 tracing regardless of whether the TTL value is copied from an 142 inner header to an outer header at tunnel ingress). 144 12) When tracing through the control plane, display the MTU 145 associated with each hop. 147 13) When tracing through the forwarding plane, display the MTU 148 associated with each hop in the reverse direction. 150 7. Protocol Requirements 152 Implementers require a new protocol that supports the application 153 described above. This protocol reveals the path between two points 154 in an IP network. When access policy permits, the protocol also 155 reveals tunnel details. 157 7.1. Information Requirements 159 The protocol consists of probes and probe responses. Each probe 160 elicits exactly one response. Each response represents a hop that 161 connects the head-end of the traced path to the tail-end of the 162 traced path. A hop can be either a top-level IP hop or lower-level 163 hop that is contained by a tunnel. 165 7.2. Transport Layer Requirements 167 UDP carries all protocol messages to their destinations. 169 7.3. Routing Requirements 171 The device that hosts the route-tracing application must maintain an 172 IP route to the head-end of the traced path. It must also maintain an 173 IP route to the head-end of each tunnel for which it is requesting 174 tunnel details. The device that hosts the tunnel tracing application 175 need not maintain a route to any other device that supports the 176 traced path. 178 All of the devices mentioned above must maintain an IP route back to 179 the device that hosts the route tracing application. 181 In order for the protocol to provide tunnel details, all devices 182 contained by a tunnel must maintain an IP route to the device that 183 hosts the tunnel ingress. 185 7.4. Maintaining State 187 The protocol must be stateless. That is, no node should have to 188 maintain state between successive traceroute messages. 190 8. Security Considerations 192 A configurable access control policy determines the degree to which 193 features described herein are delivered. The access control policy 194 requires user identification and authorization. 196 As stated above, the new protocol must not introduce security holes 197 nor consume excessive resources (e.g., CPU, bandwidth). It also must 198 not be exploitable by those launching DoS attacks. 200 9. Normative References 202 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", RFC 2119, Harvard University, March 1997 205 10. Informative References 207 [RFC-2026], Bradner, S., "Internet Standards Process Revision 3", RFC 208 2026, Harvard University, October 1996. 210 [RFC-2151], Kessler, G., Shepard, S., A Primer On Internet and TCP/IP 211 Tools and Ut ilities, RFC 2151, Hill Associates, Inc., June 1997 213 [RFC-2434] T. Narten and H. Alvestrand, "Guidelines for Writing an 214 IANA Considerat ions Section in RFCs", RFC 2434, October, 1998. 216 [RFC-2637] Hamzeh, K. et. al., "Point-to-Point Tunneling Protocol 217 (PPTP)", RFC 263 7, July, 1999. 219 11. Acknowledgements 221 Thanks to Randy Bush and Steve Bellovin for their comments. 223 12. Author's Addresses 225 Ronald P. Bonica 226 WorldCom 227 22001 Loudoun County Pkwy 228 Ashburn, Virginia, 20147 229 Phone: 703 886 1681 230 Email: rbonica@mci.net 232 Kireeti Kompella 233 Juniper Networks, Inc. 234 1194 N. Mathilda Ave. 235 Sunnyvale, California 94089 236 Email: kireeti@juniper.net 238 Dave Myers 239 Email: dmm@sprint.net 241 13. Full Copyright Statement 243 Copyright (C) The Internet Society (2000). All Rights Reserved. 245 This document and translations of it may be copied and furnished to 246 others, and derivative works that comment on or otherwise explain it 247 or assist in its implementation may be prepared, copied, published 248 and distributed, in whole or in part, without restriction of any 249 kind, provided that the above copyright notice and this paragraph are 250 included on all such copies and derivative works. However, this 251 document itself may not be modified in any way, such as by removing 252 the copyright notice or references to the Internet Society or other 253 Internet organizations, except as needed for the purpose of 254 developing Internet standards in which case the procedures for 255 copyrights defined in the Internet Standards process must be 256 followed, or as required to translate it into languages other than 257 English. 259 The limited permissions granted above are perpetual and will not be 260 revoked by the Internet Society or its successors or assigns. 262 This document and the information contained herein is provided on an 263 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 264 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 265 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 266 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 267 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.