idnits 2.17.1 draft-bonica-tunneltrace-03.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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC2151]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (June 2002) is 7985 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) == Missing Reference: 'RFC 2151' is mentioned on line 35, but not defined == Unused Reference: 'RFC-2434' is defined on line 223, but no explicit reference was found in the text == Unused Reference: 'RFC-2637' is defined on line 226, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2151 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2637 Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft R. Bonica 2 Expiration Date: November 2002 WorldCom 3 K. Kompella 4 Juniper Networks 5 D. Meyer 6 Cisco Systems 7 June 2002 9 Tracing Requirements for Generic Tunnels 10 draft-bonica-tunneltrace-03.txt 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. The application must provide all functionality that 35 "traceroute" [RFC 2151] currently provides. It also must provide 36 enhanced capabilities with regard to tunnel tracing (e.g., tracing 37 through IP-in-IP tunnels, tracing through MPLS LSPs). 39 3. Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in [RFC-2119]. 45 4. Introduction 47 Currently, the IETF supports the following tunneling technologies: 49 Generic Routing Encapsulation (GRE) 50 Multiprotocol Label Switching (MPLS) 51 IP over Optical (IPO) 52 IP Security Protocol (IPSEC) 53 IP in IP 54 Layer 2 Tunneling Protocol (L2TP) 56 Although these tunneling technologies provide operators with many 57 useful features, they also present management challenges. Operators 58 require a generic route tracing application that they can use to 59 verify tunnel paths and diagnose tunnel faults. 61 This document specifies requirements for that generic route tracing 62 application. It also specifies requirements for a protocol that will 63 support that application. 65 5. Review of Existing Functionality 67 Currently, network operators use "traceroute" to identify the path 68 toward any destination in an IP network. Section 3.4 of [RFC-2151] 69 provides a thorough description of traceroute. Although traceroute 70 is very reliable and very widely deployed, it is deficient with 71 regard to tunnel tracing. 73 Depending upon tunnel type, traceroute may display an entire tunnel 74 as a single IP hop, or it may display a tunnel as a collection of IP 75 hops, without indicating that they are part of a tunnel. 77 For example, assume that engineers are using IP tunnels in an IP 78 network. Assume also that they configure a tunnel so that the head- 79 end router does not copy the TTL value from the inner IP header to 80 outer IP header. Instead, the head-end router always sets the outer 81 TTL value to its maximum permitted value. When engineers trace 82 routes through the network, traceroute will always display the tunnel 83 as a single IP hop, hiding all components except the tail-end 84 interface. 86 Now assume that engineers are using MPLS to support an IP network. 87 Assume also that engineers configure an MPLS LSP so that the ingress 88 router propagates the TTL value from the IP header to the MPLS 89 header. When engineers trace routes through the network, traceroute 90 will display the LSP as a series of IP hops, without indicating that 91 they are part of a tunnel. 93 6. Application Requirements 95 Network operators require a new route-tracing application. The new 96 application must provide all functionality that traceroute currently 97 provides. It also must provide enhanced tunnel tracing capabilities. 99 The following list provides specific requirements for the new route- 100 tracing application: 102 1) Support the notion of a security token as part of the tunnel 103 trace request. The security token identifies the tracer's 104 privileges in tracing tunnels. Network elements will use this 105 security token to determine whether or not to return the requested 106 information to the tracer. In particular, appropriate privileges 107 are required for items (2), (3), (5), (8), (12), and (13). 109 2) Support in-line traces. An in-line trace reveals the path 110 between the host upon which the route-tracing application executes 111 and any interface in an IP network. 113 3) Support third party traces. A third party trace reveals the 114 path between any two points in an IP network. The application that 115 initiates a third party trace need not execute upon a host or 116 router that is part of the traced path. 118 4) When tracing through a tunnel, either as part of an in-line 119 trace or a third party trace, display the tunnel either as a single 120 IP hop or in detail. The user's request determines how the application 121 displays tunnels, subject to the user having permission to do this. 123 5) When displaying a tunnel in detail, include the tunnel type 124 (e.g., GRE, MPLS), the tunnel name (if applicable) and the tunnel 125 identifier (if applicable). Also, include tunnel components and 126 round trip delay across each component. 128 6) Support the following tunneling technologies: GRE, MPLS, IPSEC, 129 IP/O, IP-in-IP, L2TP. Be easily extensible to suppport new tunnel 130 technologies. 132 7) Trace through nested, heterogeneous tunnels (e.g., IP-in-IP 133 over MPLS). 135 8) At the users request, trace either through the forwarding 136 plane or the control plane. 138 9) Support control plane tracing for all tunnel types. When 139 tracing through the control plane, the device at the head-end 140 of a hop reports hop details. 142 10) Support tracing through forwarding plane for all tunnel types 143 that implement TTL decrement (or some similar mechanism). When tracing 144 through the forwarding plane, the device at the tail-end of a hop 145 reports hop details. 147 11) Support tracing through the forwarding plane for all tunnel types 148 that implement TTL decrement, regardless of whether the tunnel engages 149 in TTL propagation. (That is, support tunnel tracing regardless of 150 whether the TTL value is copied from an inner header to an outer 151 header at tunnel ingress). 153 12) When tracing through the control plane, display the MTU 154 associated with each hop. 156 13) When tracing through the forwarding plane, display the 157 MTU associated with each hop in the reverse direction. 159 7. Protocol Requirements 161 Implementers require a new protocol that supports the application 162 described above. This protocol reveals the path between two points 163 in an IP network. When access policy permits, the protocol also 164 reveals tunnel details. 166 7.1. Information Requirements 168 The protocol elicits a series of traceResponse messages. Each 169 traceResponse message represents a hop that connects the head-end of 170 the traced path to the tail-end of the traced path. A hop can be 171 either a top-level IP hop or lower-level hop that is contained by a 172 tunnel. 174 The protocol also supports a traceProbe message. Each traceProbe 175 message elicits exactly one traceResponse message. 177 7.2. Transport Layer Requirements 179 UDP carries traceProbe and traceResponse messages to their 180 destinations. 182 7.3. Routing Requirements 184 The device that hosts the route tracing application must maintain an 185 IP route to the head end of the traced path. It must also maintain an 186 IP route to the head end of each tunnel for which it is requesting 187 tunnel details. The device that hosts the tunnel tracing application 188 need not maintain a route to any other device that supports the 189 traced path. 191 All of the devices mentioned above must maintain an IP route back to 192 the device that hosts the route tracing application. 194 In order for the protocol to provide tunnel details, all devices 195 contained by a tunnel must maintain an IP route to the device that 196 hosts the tunnel ingress. 198 7.4. Maintaining State 200 The protocol must be stateless. 202 8. Security Considerations 204 A configurable access control policy determines the degree to which 205 features described herein are delivered. The access control policy 206 requires user identification and authorization. 208 As stated above, the new protocol must not introduce security holes 209 nor consume excessive resources (e.g., CPU, bandwidth). It also must 210 not be exploitable by those launching DoS attacks. 212 9. References 214 [RFC-2026], Bradner, S., "Internet Standards Process Revision 3", RFC 215 2026, Harvard University, October 1996. 217 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", RFC 2119, Harvard University, March 1997 220 [RFC-2151], Kessler, G., Shepard, S., A Primer On Internet and TCP/IP 221 Tools and Utilities, RFC 2151, Hill Associates, Inc., June 1997 223 [RFC-2434] T. Narten and H. Alvestrand, "Guidelines for Writing an 224 IANA Considerations Section in RFCs", RFC 2434, October, 1998. 226 [RFC-2637] Hamzeh, K. et. al., "Point-to-Point Tunneling Protocol 227 (PPTP)", RFC 2637, July, 1999. 229 10. Acknowledgements 231 Thanks to Randy Bush and Steve Bellovin for their comments. 233 11. Author's Addresses 235 Ronald P. Bonica 236 WorldCom 237 22001 Loudoun County Pkwy 238 Ashburn, Virginia, 20147 239 Phone: 703 886 1681 240 Email: rbonica@mci.net 242 Kireeti Kompella 243 Juniper Networks, Inc. 244 1194 N. Mathilda Ave. 245 Sunnyvale, California 94089 246 Email: kireeti@juniper.net 248 Dave Myers 249 Cisco Systems 250 170 Tasman Drive 251 San Jose, California 94025 252 Email: dmm@cisco.com 254 12. Full Copyright Statement 256 Copyright (C) The Internet Society (2000). All Rights Reserved. 258 This document and translations of it may be copied and furnished to 259 others, and derivative works that comment on or otherwise explain it 260 or assist in its implementation may be prepared, copied, published 261 and distributed, in whole or in part, without restriction of any 262 kind, provided that the above copyright notice and this paragraph are 263 included on all such copies and derivative works. However, this 264 document itself may not be modified in any way, such as by removing 265 the copyright notice or references to the Internet Society or other 266 Internet organizations, except as needed for the purpose of 267 developing Internet standards in which case the procedures for 268 copyrights defined in the Internet Standards process must be 269 followed, or as required to translate it into languages other than 270 English. 272 The limited permissions granted above are perpetual and will not be 273 revoked by the Internet Society or its successors or assigns. 275 This document and the information contained herein is provided on an 276 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 277 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 278 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 279 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 280 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.