idnits 2.17.1 draft-ietf-ccamp-tracereq-04.txt: 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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 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 2003) is 7592 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2925 (Obsoleted by RFC 4560) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Bonica 3 Category: Informational MCI 4 Expiration Date: December 2003 K. Kompella 5 Juniper Networks 6 D. Meyer 7 Sprint 8 June 2003 10 Tracing Requirements for Generic Tunnels 11 draft-ietf-ccamp-tracereq-04 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC-2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document specifies requirements for a generic route-tracing 35 application. It also specifies requirements for a protocol that will 36 support that application. Network operators will use the generic 37 route-tracing application to verify proper operation of the IP 38 forwarding plane. They will also use the application to discover 39 details regarding tunnels that support IP forwarding. 41 The generic route-tracing application, specified herein, supports a 42 superset of the functionality that "traceroute" currently offers. 43 Like traceroute, the generic route-tracing application can discover 44 the forwarding path between two interfaces that are contained by an 45 IP network. Unlike traceroute, this application can reveal details 46 regarding tunnels that support the IP forwarding path. 48 1. Introduction 50 IP networks utilize several tunneling technologies. Although these 51 tunneling technologies provide operators with many useful features, 52 they also present management challenges. Network operators require a 53 generic route-tracing application that they can use to verify the 54 correct operation of the IP forwarding plane. The generic route- 55 tracing application must be capable of detecting tunnels and 56 revealing tunnel details. The application also must be useful in 57 diagnosing tunnel faults. 59 Implementors also require a new protocol that will support the 60 generic-route tracing application. This document specifies 61 requirements for that protocol. It specifies requirements, primarily, 62 by detailing the desired capabilities of the generic route-tracing 63 application. A particular version of generic route-tracing 64 application may implement some subset of the desired capabilities. It 65 may also implement a superset of those capabilities. However, 66 protocol designers are not required to consider the additional 67 capabilities when designing the new protocol. 69 This document also specifies a few protocol requirements, stated as 70 such. These requirements are driven by desired characteristics of the 71 generic route-tracing application. Whenever a protocol requirement is 72 stated, it is mapped to desired characteristic of the route-tracing 73 application. 75 2. Review of Existing Functionality 77 Currently, network operators use "traceroute" to trace through the 78 forwarding path of an IP network. Section 3.4 of [RFC-2151] provides 79 a thorough description of traceroute. Although traceroute is very 80 reliable and very widely deployed, it is deficient with regard to 81 tunnel tracing. 83 Depending upon tunnel type, traceroute may display an entire tunnel 84 as a single IP hop, or it may display the tunnel as a collection of 85 IP hops, without indicating that they are part of a tunnel. 87 For example, assume that engineers deploy an IP tunnel in an IP 88 network. Assume also that they configure the tunnel so that the 89 ingress router does not copy the TTL value from the inner IP header 90 to outer IP header. Instead, the ingress router always sets the 91 outer TTL value to its maximum permitted value. When engineers trace 92 through the network, traceroute will always display the tunnel as a 93 single IP hop, hiding all components except the egress interface. 95 Now assume that engineers deploy an MPLS LSP in an IP network. 96 Assume also that engineers configure the MPLS LSP so that the ingress 97 router propagates the TTL value from the IP header to the MPLS 98 header. When engineers trace through the network, traceroute will 99 display the LSP as a series of IP hops, without indicating that they 100 are part of a tunnel. 102 3. Application Requirements 104 Network operators require a new route-tracing application. The new 105 application must support all functionality that traceroute currently 106 offers. It also must provide enhanced tunnel tracing capabilities. 108 The following list provides specific requirements for the new route- 109 tracing application: 111 1) Support the notion of a security token as part of the tunnel 112 trace request. The security token identifies the tracer's 113 privileges in tracing tunnels. Network elements will use this 114 security token to determine whether or not to return the requested 115 information to the tracer. In particular, appropriate privileges 116 are required for items (2), (3), (6), (8), (10), (13), and (14). 118 Justification: Operators may need to discover network forwarding 119 details, while concealing those details from unauthorized parties. 121 2) Support in-line traces. An in-line trace reveals the path 122 between the host upon which the route-tracing application executes 123 and any interface in an IP network. 125 Justification: Operators need to discover how the network would 126 forward a datagram between any two IP interfaces. 128 3) Support third-party traces. A third-party trace reveals the 129 path between any two points in an IP network. The application 130 that initiates a third-party trace need not execute upon a host or 131 router that is part of the traced path. Unlike existing solutions 132 [RFC-2151] [RFC-2925], the application will not rely upon IP 133 options or require access to the SNMP agent in order to support 134 third-party traces. 136 Justification: Operators need to discover how the network would 137 forward a datagram between any two IP interfaces. 139 4) Support partial traces through broken paths or tunnels. 141 Justification: Operators need to identify the root cause of 142 forwarding plane failures. 144 5) When tracing through a tunnel, either as part of an in-line 145 trace or a third-party trace, display the tunnel either as a 146 single IP hop or in detail. The user's request determines how the 147 application displays tunnels, subject to the user having 148 permission to do this. 150 Justification: As they discover IP forwarding details, operators 151 may need to reveal or mask tunneling details. 153 6) When displaying a tunnel in detail, include the tunnel type 154 (e.g., GRE, MPLS), the tunnel name (if applicable), the tunnel 155 identifier (if applicable) and tunnel endpoint addresses. Also, 156 include tunnel components and round trip delay across each 157 component. 159 Justification: As they discover IP forwarding details, operators 160 may need to reveal tunneling details. 162 7) Support the following tunneling technologies: GRE, MPLS, IPSEC, 163 GMPLS, IP-in-IP, L2TP. Be easily extensible to support new tunnel 164 technologies. 166 Justification: Operators will use the generic route-tracing 167 application to discover how an IP network forwards datagrams. As 168 many tunnel types may support the IP network, the generic route- 169 tracing application must detect and reveal details concerning 170 multiple tunnel types. 172 8) Trace through nested, heterogeneous tunnels (e.g., IP-in-IP 173 over MPLS). 175 Justification: Operators will use the generic route-tracing 176 application to discover how an IP network forwards datagrams. As 177 nested, heterogeneous tunnels may support the IP network, the 178 generic route-tracing application must detect and reveal details 179 concerning nested, heterogeneous tunnels. 181 9) At the users request, trace through the forwarding plane, the 182 control plane or both. 184 Justification: Operators need to identify the root cause of 185 forwarding plane failures. Control plane information is sometimes 186 useful in determining the cause of forwarding plane failure. 188 10) Support control plane tracing for all tunnel types. When 189 tracing through the control plane, the hop ingress device reports 190 hop details. The hop ingress device is the device that originates 191 the hop. 193 Justification: Control plane information is available regarding 194 all tunnel types. 196 11) Support tracing through forwarding plane for all tunnel types 197 that implement TTL decrement (or some similar mechanism). When 198 tracing through the forwarding plane, the hop egress device 199 reports hop details. The hop egress devices is the device that 200 terminates the hop. 202 Justification: Forwarding plane information may not be available 203 regarding tunnels that do not support TTL decrement. 205 12) Support tracing through the forwarding plane for all tunnel 206 types that implement TTL decrement, regardless of whether the 207 tunnel engages in TTL propagation. (That is, support tunnel 208 tracing regardless of whether the TTL value is copied from an 209 inner header to an outer header at tunnel ingress). 211 Justification: Forwarding plane information is always available, 212 regardless of whether the tunnel engages in TTL propagation. 214 13) When tracing through the control plane, display the MTU 215 associated with interface that forwards datagrams through the 216 traced path. 218 Justification: MTU information is sometimes useful in identifying 219 the root cause of forwarding and control plane failures. 221 14) When tracing through the forwarding plane, display the MTU 222 associated with each interface that receives datagtrams along the 223 traced path. 225 Justification: MTU information is sometimes useful in identifying 226 the root cause of forwarding and control plane failures. 228 15) Support partial traces through paths containing devices that 229 do not provide protocol support for generic route tracing. When 230 the application encounters such a device, it should inform the 231 user and attempt to discover details regarding the next interface 232 downstream. 234 Justification: The application must provide useful information 235 even if the supporting protocol is not universally deployed. 237 4. Protocol Requirements 239 Implementors require a new protocol that supports the generic route- 240 tracing application. This protocol reveals the path between two 241 points in an IP network. When access policy permits, the protocol 242 also reveals tunnel details. 244 4.1. Information Requirements 246 The protocol consists of probes and probe responses. Each probe 247 elicits exactly one response. Each response represents a hop that 248 that contributes to the path between two interfaces. A hop can be 249 either a top-level IP hop or lower-level hop that is contained by a 250 tunnel. 252 Justification: Because the generic route-tracing application must 253 trace through broken paths, the required protocol must use a separate 254 response message to deliver details regarding each hop. The protocol 255 must use a separate probe to elicit each response because the 256 alternative approach, using the single probe with the IP Router Alert 257 Option, is unacceptable. Many networks forward datagrams that specify 258 IP options differently than they would forward datagrams that do not 259 specify IP options. Therefore, the introductions of IP options would 260 cause the application to trace a forwarding path other than the path 261 that its user intended to trace. 263 4.2. Transport Layer Requirements 265 UDP carries all protocol messages to their destinations. 267 Justification: Because the probe/response scheme described above is 268 stateless, a stateless transport is required. Candidate transports 269 included UDP over IP, IP and ICMP. ICMP was disqualified because 270 carrying MPLS information in an ICMP datagram would constitute a 271 layer violation. IP was disqualified in order to conserve protocol 272 identifiers. 274 4.3. Stateless Protocol 276 The protocol must be stateless. That is, nodes should not have to 277 maintain state between successive traceroute messages. 279 Justification: Statelessness is required to support scaling and to 280 prevent denial of service attacks. 282 4.4. Routing Requirements 284 The device that hosts the route-tracing application must maintain an 285 IP route to the ingress of the traced path. It must also maintain an 286 IP route to the ingress of each tunnel for which it is requesting 287 tunnel details. The device that hosts the tunnel tracing application 288 need not maintain a route to any other device that supports the 289 traced path. 291 All of the devices to which the route-tracing application must 292 maintain a route must maintain a route back to the route-tracing 293 application. 295 In order for the protocol to provide tunnel details, all devices 296 contained by a tunnel must maintain an IP route to the tunnel 297 ingress. 299 Justification: The protocol must be sufficiently robust to operate 300 when tunnel interior devices do not maintain a route back to the 301 device that hosts the route tracing application. 303 5. Security Considerations 305 A configurable access control policy determines the degree to which 306 features described herein are delivered. The access control policy 307 requires user identification and authorization. 309 The new protocol must not introduce security holes nor consume 310 excessive resources (e.g., CPU, bandwidth). It also must not be 311 exploitable by those launching DoS attacks or replaying messages. 313 6. Informative References 315 [RFC-2151], Kessler, G., Shepard, S., A Primer On Internet and TCP/IP 316 Tools and Ut ilities, RFC 2151, Hill Associates, Inc., June 1997 318 [RFC-2925], White, K., "Definitions of Managed Objects for Remote 319 Ping, Traceroute, and Lookup Operations", RFC 2925, September, 2000. 321 7. Acknowledgements 323 Thanks to Randy Bush and Steve Bellovin for their comments. 325 8. Authors' Addresses 327 Ronald P. Bonica 328 MCI 329 22001 Loudoun County Pkwy 330 Ashburn, Virginia, 20147 331 Email: ronald.p.bonica@mci.com 333 Kireeti Kompella 334 Juniper Networks, Inc. 335 1194 N. Mathilda Ave. 336 Sunnyvale, California 94089 337 Email: kireeti@juniper.net 339 David Meyer 340 Email: dmm@maoz.com 342 9. Full Copyright Statement 344 Copyright (C) The Internet Society (2003). All Rights Reserved. 346 This document and translations of it may be copied and furnished to 347 others, and derivative works that comment on or otherwise explain it 348 or assist in its implementation may be prepared, copied, published 349 and distributed, in whole or in part, without restriction of any 350 kind, provided that the above copyright notice and this paragraph are 351 included on all such copies and derivative works. However, this 352 document itself may not be modified in any way, such as by removing 353 the copyright notice or references to the Internet Society or other 354 Internet organizations, except as needed for the purpose of 355 developing Internet standards in which case the procedures for 356 copyrights defined in the Internet Standards process must be 357 followed, or as required to translate it into languages other than 358 English. 360 The limited permissions granted above are perpetual and will not be 361 revoked by the Internet Society or its successors or assigns. 363 This document and the information contained herein is provided on an 364 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 365 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 366 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 367 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 368 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.