RFC 3609

Tracing Requirements for Generic Tunnels

📅 published October 2003, from ietf

RFC 3609: Tracing Requirements for Generic Tunnels 🎀

Okay bestie, here's the tea on the title block so you don't have to squint at the columns 🫶

  • Stream: Network Working Group
  • Number and title: RFC 3609, Tracing Requirements for Generic Tunnels 🦋
  • Authors: R. Bonica (MCI), K. Kompella (Juniper Networks), and D. Meyer (Sprint) 👑
  • Category: Informational (so it's info, not a standard) 💜
  • Date: September 2003 📅
  • Obsoletes and updates: the title block doesn't list any RFCs it obsoletes or updates 🌸

Status of This Memo ✨

This memo is here to give the Internet community information. It is NOT a specification for an Internet standard of any kind, and anyone can share it freely because distribution is unlimited 💅

The copyright line says Copyright (C) The Internet Society (2003). All Rights Reserved. and that's all the legal stuff we need 🤍

Abstract 🔮

Okay so this document lays out what a generic route-tracing application needs to do, plus what a protocol needs to do to back that app up. Network operators are gonna use this app to check that the IP forwarding plane is actually working right, and to dig into the tunnels that help IP forwarding happen 🕵️‍♀️

The generic route-tracing app is literally a superset of what "traceroute" can do 😭 Like traceroute, it can find the forwarding path between two interfaces inside an IP network. The difference is that this app can also reveal details about the tunnels sitting on that path, which traceroute basically can't do. Iconic glow-up 💖

1. Introduction ✨

IP networks run on a bunch of tunneling technologies. These bring operators lots of useful features, but ngl they also bring management headaches 🙈 Operators need a generic route-tracing app to check that the IP forwarding plane is running correctly. That app MUST be able to detect tunnels and reveal tunnel details. It MUST ALSO be useful for figuring out what's going wrong with a tunnel 🔧

Implementors also need a new protocol to support the generic route-tracing app. This document spells out the requirements for that protocol, and it mostly does that by describing what the app should be able to do. A particular version of the app MAY implement only some of those capabilities, and it MAY also go beyond them and implement a superset. However, protocol designers are NOT REQUIRED to think about those extra capabilities when they design the new protocol. Main character energy for the app, zero pressure for the designers 🧚

This document also lists a few protocol requirements and labels them as such. Those requirements come from what the route-tracing app needs, and every time a protocol requirement shows up, it's tied back to the app characteristic it serves 🦋

2. Review of Existing Functionality 🔍

Right now, network operators use "traceroute" to follow the forwarding path through an IP network. Section 3.4 of [RFC-2151] has a thorough description of traceroute. It's super reliable and everybody uses it, but it's kinda deficient when it comes to tunnel tracing 😬

Depending on the tunnel type, traceroute might show an entire tunnel as one single IP hop. Or it might show the tunnel as a bunch of IP hops, without saying that those hops are part of a tunnel at all. Chaotic 💀

Here's an example. Say engineers deploy an IP tunnel in an IP network, and they set it up so the ingress router does NOT copy the TTL value from the inner IP header to the outer IP header. Instead, the ingress router always sets the outer TTL value to its maximum permitted value. When engineers trace through the network, traceroute will ALWAYS show the tunnel as a single IP hop, hiding every component except the egress interface. Sneaky sneaky 🙃

Now say engineers deploy an MPLS LSP in an IP network, and they configure it so the ingress router propagates the TTL value from the IP header to the MPLS header. When engineers trace through the network, traceroute shows the LSP as a series of IP hops and doesn't mention that they're part of a tunnel 🫠

3. Application Requirements 💅

Network operators need a brand-new route-tracing app. This new app MUST support everything traceroute can currently do, and it MUST ALSO give better tunnel tracing 🎀

Here is the list of specific requirements for the new route-tracing app:

  1. Support the idea of a security token as part of a tunnel trace request. The security token shows what the tracer is allowed to do when tracing tunnels. Network elements will use this token to decide whether or not to send back the requested information to the tracer. In particular, appropriate privileges are REQUIRED for items (2), (3), (6), (8), (10), (13), and (14). 🔐

Justification: Operators might need to find out forwarding details about the network while keeping those details hidden from people who aren't authorized 🙊

  1. Support in-line traces. An in-line trace reveals the path between the host where the route-tracing app is running and any interface in an IP network. 🪞

Justification: Operators need to know how the network would forward a datagram between any two IP interfaces 🛣️

  1. Support third-party traces. A third-party trace reveals the path between any two points in an IP network. The app that starts a third-party trace doesn't have to be running on a host or router that's part of the traced path. Unlike existing solutions [RFC-2151] [RFC-2925], the app will NOT rely on IP options or need access to the SNMP agent to pull off third-party traces 👀

Justification: Operators need to know how the network would forward a datagram between any two IP interfaces 🛣️

  1. Support partial traces through broken paths or tunnels. 🧩

Justification: Operators need to pinpoint the root cause of forwarding plane failures 🎯

  1. When tracing through a tunnel, whether as part of an in-line trace or a third-party trace, display the tunnel either as a single IP hop or in detail. The user's request decides how the app shows tunnels, as long as the user has permission to do this 🎛️

Justification: As they uncover IP forwarding details, operators might need to reveal or hide tunneling details 🫣

  1. When displaying a tunnel in detail, include the tunnel type (for example, GRE or MPLS), the tunnel name (if applicable), the tunnel identifier (if applicable), and the tunnel endpoint addresses. Also include the tunnel components and the round trip delay across each component 📊

Justification: As they uncover IP forwarding details, operators might need to reveal tunneling details 🔍

  1. Support the following tunneling technologies: GRE, MPLS, IPSEC, GMPLS, IP-in-IP, and L2TP. It should also be easy to extend the app to support new tunnel technologies. 🧚‍♀️

Justification: Operators will use the generic route-tracing app to find out how an IP network forwards datagrams. Since many tunnel types might be supporting the IP network at once, the app MUST detect and reveal details about multiple tunnel types 🌈

  1. Trace through nested, heterogeneous tunnels (for example, IP-in-IP over MPLS). 🪆

Justification: Operators will use the generic route-tracing app to find out how an IP network forwards datagrams. Since nested, heterogeneous tunnels might be supporting the IP network, the app MUST detect and reveal details about those nested, heterogeneous tunnels 💜

  1. At the user's request, trace through the forwarding plane, the control plane, or both. 🎚️

Justification: Operators need to pinpoint the root cause of forwarding plane failures. Control plane information is sometimes useful for figuring out what caused a forwarding plane failure 🕰️

  1. Support control plane tracing for all tunnel types. When tracing through the control plane, the hop ingress device reports the hop details. The hop ingress device is the device that originates the hop. 🚪

Justification: Control plane information is available for all tunnel types 🌸

  1. Support tracing through the forwarding plane for all tunnel types that implement TTL decrement (or some similar mechanism). When tracing through the forwarding plane, the hop egress device reports the hop details. The hop egress device is the device that terminates the hop. 🚦

Justification: Forwarding plane information might not be available for tunnels that don't support TTL decrement 🫥

  1. Support tracing through the forwarding plane for all tunnel types that implement TTL decrement, whether or not the tunnel engages in TTL propagation. (In other words, support tunnel tracing whether or not the TTL value gets copied from an inner header to an outer header at tunnel ingress.) 🔁

Justification: Forwarding plane information is always available, whether or not the tunnel engages in TTL propagation 🌟

  1. When tracing through the control plane, display the MTU associated with each interface that forwards datagrams along the traced path. 📏

Justification: MTU information is sometimes useful for figuring out the root cause of forwarding and control plane failures 🧠

  1. When tracing through the forwarding plane, display the MTU associated with each interface that receives datagrams along the traced path. 📐

Justification: MTU information is sometimes useful for figuring out the root cause of forwarding and control plane failures 🧠

  1. Support partial traces through paths that contain devices which don't provide protocol support for generic route tracing. When the app runs into one of these devices, it SHOULD inform the user and try to discover details about the next interface downstream. 🫶

Justification: The app has to give useful information even when the supporting protocol isn't deployed everywhere 🌍

4. Protocol Requirements 🦋

Implementors need a new protocol that supports the generic route-tracing app. This protocol reveals the path between two points in an IP network. When access policy allows it, the protocol also reveals tunnel details 🔓

4.1. Information Requirements ✨

okay so the protocol is all about probes and probe responses 🦋 each probe gets exactly one response back, and every response is basically a little postcard about one hop on the path between two interfaces. a hop can be a top-level IP hop, or a lower-level hop tucked inside a tunnel 🧚

Justification: the generic route-tracing app has to be able to trace through broken paths, so the protocol needs its own separate response message to spill the details on each hop 💅 and each probe has to elicit its response on its own, because the other option, one probe with the IP Router Alert Option, is a no-go. bestie, lots of networks forward datagrams that carry IP options differently than datagrams that don't 🙈 so adding options would make the app trace some other path than the one the user actually wanted to trace. not it 💀

4.2. Transport Layer Requirements 🌸

UDP should carry all protocol messages to their destinations. other transport mechanisms may be considered once the protocol details get specified 🫶

Justification: the probe/response scheme is stateless, so the transport has to be stateless too 🎀 the candidates were UDP over IP, IP and ICMP. ICMP got cancelled because stuffing MPLS info into an ICMP datagram would be a layer violation (super messy 😭). plain IP got cancelled too, to save protocol identifiers 🍓

4.3. Stateless Protocol 🧚

the protocol must be stateless. like, nodes should not have to hold onto state between successive traceroute messages 💜

Justification: statelessness is needed so things can scale and so denial of service attacks don't get a foothold 🔥

4.4. Routing Requirements 🗺️

the device hosting 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 each tunnel it's asking for tunnel details on. the device hosting the tunnel tracing application need not maintain a route to any other device that supports the traced path, so it doesn't have to stress about those 🌈

all the devices the route-tracing application must keep a route to must also keep a route back to the route-tracing application 🔁

for the protocol to give tunnel details, every device contained by a tunnel must maintain an IP route to the tunnel ingress 🎀

Justification: the protocol has to be robust enough to keep working when tunnel interior devices don't keep a route back to the device hosting the route tracing application. it's giving resilience ✨

5. Security Considerations 🔐

⚠️ this part is seriously important, so read it slowly bestie 💖

a configurable access control policy decides how far the features described here get delivered 🔑 and that policy requires user identification and authorization. no free passes.

the new protocol must not introduce security holes, and it must not consume excessive resources (think CPU and bandwidth) 🔥 it also must not be exploitable by anyone launching DoS attacks or replaying messages. absolutely zero tolerance energy 💀💅

6. Informative References 📚

[RFC-2151]  Kessler, G. and S. Shepard, "A Primer On Internet and
            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.

7. Acknowledgements 🫶

thanks to Randy Bush and Steve Bellovin for their comments 💜

8. Authors' Addresses 🎀

Ronald P. Bonica
MCI
22001 Loudoun County Pkwy
Ashburn, Virginia, 20147

EMail: ronald.p.bonica@mci.com


Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, California 94089

EMail: kireeti@juniper.net


David Meyer

EMail: dmm@maoz.com

Copyright (C) The Internet Society (2003). 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 assignees.

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.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈

📦 where this page comes from