RFC 5388

Information Model and XML Data Model for Traceroute Measurements

📅 published December 2008, from ietf

RFC 5388: Information Model and XML Data Model for Traceroute Measurements 🦋

Okay bestie, here's the header info, so you know who made this and what kind of doc it is 💅

  • RFC number: 5388
  • Series: Network Working Group
  • Category: Standards Track
  • Date: December 2008
  • Authors: S. Niccolini, S. Tartarelli, J. Quittek, and T. Dietz (all from NEC), plus M. Swany (from UDel)
  • Obsoletes/Updates: The title block doesn't name any RFC that this one obsoletes or updates.

Status of This Memo 💖

So this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 If you want the official standardization state and status, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so go share it 🌸

Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stand on the date this document was published. Read those carefully, because they spell out your rights and restrictions for this doc 📜

Abstract ✨

Okay, the big picture: this doc gives us a standard way to store the configuration and the results of traceroute measurements 🦋 It starts by explaining the terminology and how the traceroute tool works. Then it defines a common information model that splits the information elements into two semantically separate groups, configuration elements and results elements. There's also an extra element that ties the configuration and results together with a common unique identifier 🔗 Finally, based on that information model, it defines an XML-based data model for storing traceroute results. Iconic 💅

Table of Contents 🌈

1. Introduction ....................................................3
2. Terminology Used in This Document ...............................3
3. The Traceroute Tool and Its Operations ..........................4
4. Results of Traceroute Measurements ..............................5
5. Information Model for Traceroute Measurements ...................5
   5.1. Data Types .................................................6
   5.2. Information Elements .......................................7
        5.2.1. Relationships between the Information Elements ......7
        5.2.2. Configuration Information Elements .................12
        5.2.3. Results Information Elements .......................17
        5.2.4. Information Element Correlating
               Configuration and Results ..........................21
        5.2.5. Information Elements to Compare Traceroute
               Measurement Results ................................22
6. Data Model for Storing Traceroute Measurements .................23
7. XML Schema for Traceroute Measurements .........................24
8. Security Considerations ........................................38
   8.1. Conducting Traceroute Measurements ........................39
   8.2. Securing Traceroute Measurement Information ...............39
9. IANA Considerations ............................................40
10. References ....................................................40
   10.1. Normative References .....................................40
   10.2. Informative References ...................................41
Appendix A. Traceroute Default Configuration Parameters ...........43
   A.1. Alternative Traceroute Implementations ....................46
Appendix B. Known Problems with Traceroute ........................47
   B.1. Compatibility between Traceroute Measurement Results
        and IPPM Metrics ..........................................47
Appendix C. Differences to DISMAN-TRACEROUTE-MIB ..................47
   C.1. Scope .....................................................48
   C.2. Naming ....................................................49
   C.3. Semantics .................................................49
   C.4. Additional Information Elements ...........................50
Appendix D. Traceroute Examples with XML Representation ...........50

1. Introduction ✨

Traceroutes are everywhere in measurement work, whether they're running on their own or giving path info to help other measurement projects 🗺️ That's exactly why we need a standard way to store the configuration and results of traceroute measurements. The standard IPPM metrics for delay, connectivity, and losses don't apply to what traceroute returns, so if you want to compare traceroute results, the only option is to save the operating system details along with the name and version of the traceroute tool you used 🤓 This doc sets up a standard way to store results so they can be compared, and it does that with an XML schema 💖

Here's the roadmap. Section 2 covers terminology. Section 3 explains the traceroute tool. Section 4 covers the results as they show up on the screen of the host where the tool was launched. Sections 5 and 6 cover the information model and the data model for storing configuration and results. Section 7 has the XML schema, which you can use as a template for storing and exchanging traceroute measurement info. The doc wraps up with security considerations in Section 8 and IANA considerations in Section 9 🎀

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 [RFC2119].

2. Terminology Used in This Document 💅

Here's the terminology the doc uses, so everyone's on the same page 📖

  • traceroute tool: a software tool for network diagnostic that behaves as described in Section 3;
  • traceroute measurement: an instance of the traceroute tool launched, with specific configuration parameters (traceroute measurement configuration parameters), from a specific host (initiator of the traceroute measurement) giving as output specific traceroute measurement results;
  • traceroute probe: one of many IP packets sent out by the traceroute tool during a traceroute measurement;
  • traceroute measurement configuration parameters: the configuration parameters of a traceroute measurement;
  • traceroute measurement results: the results of a traceroute measurement;
  • traceroute measurement information: both the results and the configuration parameters of a traceroute measurement;
  • traceroute measurement path: a sequence of hosts transited in order by traceroute probes during a traceroute measurement.

3. The Traceroute Tool and Its Operations 🔥

Okay so traceroute is a network diagnostic tool that figures out the hop-by-hop path from a source to a destination, plus the Round Trip Time (RTT) from the source to each hop 🛤️ It's how you can find stuff like hop counts and delays along the path between the initiator of the measurement and other hosts.

Usually, the traceroute tool tries to find the path to a destination by sending UDP probes with specific time-to-live (TTL) values in the IP packet header. The goal is to get an ICMP TIME_EXCEEDED response back from each gateway along the way to some host 🪄

Here's how it plays out. The first set of probes has TTL equal to 1 and gets sent from the host that starts the measurement. (Some implementations let you set the initial TTL to a value "n" that's different from 1, so the first "n-1" hops get skipped and the first hop that actually gets traced is the "n-th" one in the path 🙈) When the first hop receives a probe, it lowers the TTL value by one or more. When the TTL hits zero, the host throws out the probe and usually sends back an ICMP message with a TIME_EXCEEDED value. From the header of that ICMP message, the traceroute tool can work out the IP address of the first hop and figure out the RTT between the initiating host and that first hop. The next hops get found the same way, and the tool makes sure to raise the TTL of the probes by one each step. The TTL keeps going up until either an ICMP PORT_UNREACHABLE message comes back, which means the destination host was reached, or the maximum configured number of hops gets hit 🎯

Some implementations use ICMP Echoes instead of UDP datagrams. The catch is that many routers don't send ICMP messages about ICMP messages, so no ICMP TIME_EXCEEDED comes back for an ICMP Echo 😭

So this document recommends basing implementations on UDP datagrams. Considerations on TCP-based implementations of the traceroute tool are in Appendix A.1 🦋

4. Results of Traceroute Measurements 🎀

Here's the list of information fields that every traceroute tool implementation considered provides as results. The order they're listed in doesn't matter, and different implementations change it up anyway 💁‍♀️ For each hop, the following info is reported:

  • the hop index;
  • the host symbolic address, provided that at least one of the probes received a response, the symbolic address could be resolved at the corresponding host, and the option to display only numerical addresses was not set;
  • the host IP address, provided that at least one of the probes received a response;
  • the RTT for each response to a probe.

Depending on the implementation, the output might show extra info, like MPLS-related details 👀

Sometimes probes don't get a response before the configured timeout. For example, a firewall might filter the probe out 🧱 When that happens, the screen shows an "*" where the RTT should be. The information model handles this with a string whose value is "RoundTripTimeNotAvailable", which means either the probe was lost because of a timeout or it wasn't possible to send the probe at all 💀

It may also happen that some implementations print the same line multiple times when a router decreases the TTL by more than one, which makes it look like there are extra hops. The information model isn't affected by this, because each line gets handled separately. It's up to the applications that handle the XML file to decide how to deal with it 🧐 Last thing: for delays below 1 ms, some implementations report 0 ms (UNIX and LINUX do this, for example), while WINDOWS reports "< 1 ms" ⚡

5. Information Model for Traceroute Measurements ✨

okay so the information model is basically built out of information elements 🧩, and every single one gets described with the same template 💅. here's the template:

  • name: a unique, meaningful name for the element. the preferred style is mixed case for compound names, starting with a lowercase letter, like sourceIpAddress 🎀
  • description: what the element actually means 💭
  • dataType: one of the types from Section 5.1 of this document, or from an extension of the information model. the type space for attributes is constrained on purpose so it's easier to implement 🛠️
  • units: if the element measures something, the units tell you what that thing is 📏

5.1. Data Types

this section lists the basic valid data types for the information model 🍓

  • string: a finite-length string of valid characters from the Unicode character set. Unicode lets you use ASCII plus tons of international character sets 🌍. strings are expected to be encoded in UTF-8, which matches US-ASCII exactly for ASCII characters and also handles the multi-byte Unicode characters 🫶
  • string255: same as string, just capped at 255 characters 💖
  • inetAddressType: a type of Internet address. the allowed values are imported from [RFC4001] (where the intent was to import only some of them). on top of those, the extra allowed values are asnumber and noSpecification 🦋
  • inetAddress: a generic Internet address 🌐. the allowed values are imported from [RFC4001], and the imported values are unknown, ipv4, ipv6, and dns. non-global IPv4/IPv6 addresses (like ipv4z and ipv6z) are excluded 🙅‍♀️. there's one extra allowed value too: an AS number, written as the actual number plus an indication of how the IP-address-to-AS-number mapping was done. unknown is used when the address doesn't match any of the formats defined 🤷‍♀️
  • ipASNumberMappingType: the type that describes how an IP-to-AS-number mapping was obtained 🗺️. the allowed values are bgptables, routingregistries, nslookup, others, or unknown ✨
  • boolean: a boolean value according to the XML standards [W3C.REC-xmlschema-2-20041028] 💜
  • unsignedInt: a value in the range (0..4294967295) 🔢
  • unsignedShort: a value in the range (0..65535) 🔢
  • unsignedByte: a value in the range (0..255) 🔢
  • u8nonzero: a value in the range (1..255). it's basically a byte but zero is not allowed 🙈
  • probesType: says which protocol was used for the traceroute probes 🛰️. the values defined in this document are UDP, TCP, and ICMP 🌸
  • operationResponseStatus: used to report the result of an operation 📬. the allowed values are imported from [RFC4560] 💅
  • dateTime: a date-time specification according to the XML standards [W3C.REC-xmlschema-2-20041028], but restricted to the values defined in [RFC3339] 🕰️

5.2. Information Elements

this section covers the elements that store a traceroute measurement 📦. they're split into two groups based on their meaning: configuration and results 🎀. to connect configuration and results through a shared unique identifier, there's one extra element that belongs to both groups. it's the glue 🫶

5.2.1. Relationships between the Information Elements

every traceroute measurement is represented by an instance of the traceRoute element 👑. this class gives a standardized way to represent traceroute measurement data. the traceRoute element can be made up of the following (depending on what kind of measurement it is) 🧚:

  • 1 optional RequestMetadata element;
  • 0..2147483647 Measurement elements.

each Measurement element contains:

  • 1 optional MeasurementMetadata element;
  • 0..2147483647 MeasurementResult elements.

the RequestMetadata element is for specifying the parameters of a traceroute measurement that should be run at one or more nodes by one or more traceroute implementations 🚀. depending on what a traceroute implementation can do, not every requested parameter can necessarily be applied 🤷‍♀️. the parameters that were actually applied to a specific measurement are recorded in a MeasurementMetadata element 📝.

the RequestMetadata element is a sequence that contains:

  • 1 TestName element;
  • 1 optional ToolVersion element;
  • 1 optional ToolName element;
  • 1 CtlTargetAddress element;
  • 1 optional CtlBypassRouteTable element;
  • 1 optional CtlProbeDataSize element;
  • 1 optional CtlTimeOut element;
  • 1 optional CtlProbesPerHop element;
  • 1 optional CtlPort element;
  • 1 optional CtlMaxTtl element;
  • 1 optional CtlDSField element;
  • 1 optional CtlSourceAddress element;
  • 1 optional CtlIfIndex element;
  • 1 optional CtlMiscOptions element;
  • 1 optional CtlMaxFailures element;
  • 1 optional CtlDontFragment element;
  • 1 optional CtlInitialTtl element;
  • 1 optional CtlDescr element;
  • 1 CtlType element.

if the RequestMetadata element is left out of an XML file, it means all the requested configuration parameters were used, and the MeasurementMetadata element lists them in detail 🙌.

the MeasurementMetadata element is a sequence that contains:

  • 1 TestName element;
  • 1 OSName element;
  • 1 OSVersion element;
  • 1 ToolVersion element;
  • 1 ToolName element;
  • 1 CtlTargetAddressType element;
  • 1 CtlTargetAddress element;
  • 1 CtlBypassRouteTable element;
  • 1 CtlProbeDataSize element;
  • 1 CtlTimeOut element;
  • 1 CtlProbesPerHop element;
  • 1 CtlPort element;
  • 1 CtlMaxTtl element;
  • 1 CtlDSField element;
  • 1 CtlSourceAddressType element;
  • 1 CtlSourceAddress element;
  • 1 CtlIfIndex element;
  • 1 optional CtlMiscOptions element;
  • 1 CtlMaxFailures element;
  • 1 CtlDontFragment element;
  • 1 CtlInitialTtl element;
  • 1 optional CtlDescr element;
  • 1 CtlType element.

configuration info can describe traceroute measurements that have already happened (MeasurementMetadata elements), but it can also describe the configuration you want used when you request a new measurement (RequestMetadata element) 🔮. semantically those are super different, even though the individual elements look alike 👀. because they're so similar, RequestMetadata and MeasurementMetadata are both represented by the same type in the XML schema 🫠. every element that's missing from RequestMetadata, or is optional there but mandatory in MeasurementMetadata, must be specified as an empty element. an empty element means "use the default value" 🎀. CtlType could have been optional in RequestMetadata, but XML schemas can't specify default values for complex types, so it's mandatory in RequestMetadata instead 💀.

the MeasurementResult element is a sequence that contains:

  • 1 TestName element;
  • 1 ResultsStartDateAndTime element;
  • 1 ResultsIpTgtAddrType element;
  • 1 ResultsIpTgtAddr element;
  • 1 ProbeResults elements;
  • 1 ResultsEndDateAndTime element.

it's also important to say that each ProbeResults element is a sequence that contains:

  • 1..255 hop elements.

each hop element is a sequence that contains:

  • 1..10 probe elements;
  • 1 optional HopRawOutputData element.

each probe element contains:

  • 1 HopAddrType element;
  • 1 HopAddr element;
  • 1 optional HopName element;
  • 0..255 optional MPLSLabelStackEntry elements;
  • 1 ProbedRoundTripTime element;
  • 1 ResponseStatus element;
  • 1 Time element.

the different counts of the three basic elements in an XML file are meant for different scopes 🧁:

  • a file with only 1 RequestMetadata element holds the configuration parameters of a traceroute measurement 📄. you can use it to hand the same configuration out to multiple nodes that are supposed to run the same measurement 📤;
  • a file with 1 Measurement element containing 1 MeasurementMetadata and 1 MeasurementResult element holds the info for a single traceroute measurement 🎯;
  • a file with 1 Measurement element containing 1 MeasurementMetadata and n MeasurementResult elements holds the info for a set of traceroute measurements run at different times, all with the exact same configuration parameters ⏰;
  • a file with 1 RequestMetadata and 1 Measurement element, where the Measurement contains 1 MeasurementMetadata and 1 Measurement element, holds the info for one traceroute measurement. it includes both the configuration parameters that were requested and the ones that were actually used 🧾;
  • other combinations are possible if you want to store multiple traceroute measurements in one XML file 🌈.

5.2.2. Configuration Information Elements

this section covers the elements specific to configuring a traceroute measurement. they belong to both RequestMetadata and MeasurementMetadata elements 🎀.

5.2.2.1. CtlTargetAddressType

  • name: CtlTargetAddressType
  • description: says what type of address is in the matching CtlTargetAddress element 🏷️. this element isn't directly reflected in the XML schema of Section 7. you can figure out the host address type by looking at the inetAddress type name and the matching element value 🔍
  • dataType: inetAddressType
  • units: N/A

5.2.2.2. CtlTargetAddress

  • name: CtlTargetAddress
  • description: in the RequestMetadata element, it's the host address you want used in the traceroute measurement 🎯. in the MeasurementMetadata element, it's the host address that was actually used in the traceroute measurement 📍
  • dataType: inetAddress
  • units: N/A

5.2.2.3. CtlBypassRouteTable 🛣️

  • name - CtlBypassRouteTable
  • description - Okay so, in the RequestMetadata element, this one tells you whether the optional bypassing of the route table was enabled or not. In the MeasurementMetadata element, it tells you the same thing 💅 If it's enabled, the normal routing tables get skipped and the probes go straight to a host on an attached network. If the host isn't on a directly attached network, an error comes back 🙅‍♀️ This option is iconic for timing a traceroute to a local host through an interface that has no route defined. You can use this object when the setsockopt SOL_SOCKET SO_DONTROUTE option is supported and set (see [IEEE.1003-1G.1997]) 🦋
  • dataType - boolean
  • units - N/A

5.2.2.4. CtlProbeDataSize 📦

  • name - CtlProbeDataSize
  • description - This one specifies the size of the probes in a traceroute measurement, in octets 🎀 It's requested if it's in the RequestMetadata element, and it's the size actually used if it's in the MeasurementMetadata element. If UDP datagrams are the probes, the value in this object is exact, no cap. If another protocol sends the probes instead (TCP or ICMP), and the specified size doesn't work for it, the implementation can use whatever size makes the most sense for that method, as long as it's closest to the specified size ✨ The maximum value for this object is found by taking the maximum IP packet size and subtracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets. An IP packet has a maximum size of 65535 octets, not counting IPv6 jumbograms 🌈
  • dataType - unsignedShort
  • units - octets

5.2.2.5. CtlTimeOut ⏰

  • name - CtlTimeOut
  • description - This is the timeout value, in seconds, for each probe in a traceroute measurement 🫶 It's requested if it's in the RequestMetadata element, and it's the value actually used if it's in the MeasurementMetadata element.
  • dataType - unsignedByte
  • units - seconds

5.2.2.6. CtlProbesPerHop 🔁

  • name - CtlProbesPerHop
  • description - This one specifies how many probes with the same time-to-live (TTL) value get sent for each host 💜 It's requested if it's in the RequestMetadata element, and it's the number actually used if it's in the MeasurementMetadata element.
  • dataType - unsignedByte
  • units - probes

5.2.2.7. CtlPort 🚪

  • name - CtlPort
  • description - This specifies the base port the traceroute measurement uses 🍓 It's requested if it's in the RequestMetadata element, and it's the port actually used if it's in the MeasurementMetadata element.
  • dataType - unsignedShort
  • units - port number

5.2.2.8. CtlMaxTtl 🔝

  • name - CtlMaxTtl
  • description - This is the maximum TTL value for the traceroute measurement, so it's basically the ceiling 🧗‍♀️ It's requested if it's in the RequestMetadata element, and it's the value actually used if it's in the MeasurementMetadata element.
  • dataType - u8nonzero
  • units - time-to-live value

5.2.2.9. CtlDSField 💅

  • name - CtlDSField
  • description - Here's the vibe check on the Differentiated Services (DS) field 💖 In the RequestMetadata element, this specifies the value that was requested to be stored in the DS field in the traceroute probe. In the MeasurementMetadata element, it specifies the value that was actually stored in the DS field in the traceroute probe. The DS field is the Type of Service (TOS) octet in an IPv4 header, or the Traffic Class octet in an IPv6 header (see Section 7 of [RFC2460]). The value of this object must be a decimal integer from 0 to 255. Not every value is legal or meaningful, so be careful bestie 🙈 This option helps you figure out what effect an explicit DS field setting has on a traceroute measurement and its probes. Useful TOS octet values are probably 16 (low delay) and 8 (high throughput) 🧚 You can find more on the DS field in [RFC2474], and on TOS in [RFC1812] Section 5.3.2.
  • dataType - unsignedByte
  • units - N/A

5.2.2.10. CtlSourceAddressType 🏷️

  • name - CtlSourceAddressType
  • description - This specifies the type of address in the matching CtlSourceAddress element 🦄 This element isn't directly reflected in the XML schema of Section 7. You can tell the host address type by checking the inetAddress type name and the matching element value. DNS names are not allowed for CtlSourceAddress, so don't even try 🙅‍♀️
  • dataType - inetAddressType
  • units - N/A

5.2.2.11. CtlSourceAddress 🎯

  • name - CtlSourceAddress
  • description - This is the IP address used as the source address in traceroute probes 💫 It has to be an IP number, not a hostname. It's requested if it's in the RequestMetadata element, and actually used if it's in the MeasurementMetadata element. On hosts with more than one IP address, you can use this option in the RequestMetadata element to force the source address to be something other than the primary IP address of the interface the probe is sent on. The value unknown means the default address gets used 🌸
  • dataType - inetAddress
  • units - N/A

5.2.2.12. CtlIfIndex 🔌

  • name - CtlIfIndex
  • description - This is the interface index, as defined in [RFC2863], that is requested to be used for sending the traceroute probes (if it's in the RequestMetadata element) 🪄 A value of 0 means no specific interface is requested. In the MeasurementMetadata element, it specifies the interface index actually used.
  • dataType - unsignedInt
  • units - N/A

5.2.2.13. CtlMiscOptions 🧁

  • name - CtlMiscOptions
  • description - This specifies implementation-dependent options 🎪 They're requested if they're in the RequestMetadata element, and actually used if they're in the MeasurementMetadata element.
  • dataType - string255
  • units - N/A

5.2.2.14. CtlMaxFailures 🚫

  • name - CtlMaxFailures
  • description - This is the maximum number of consecutive timeouts allowed before a traceroute measurement gets terminated 😭 It's requested if it's in the RequestMetadata element, and actually used if it's in the MeasurementMetadata element. A value of either 255 (the maximum hop count/possible TTL value) or 0 means the function of terminating a remote traceroute measurement when a specific number of consecutive timeouts are detected is disabled. This element is here for full compatibility with [RFC4560]. No known implementation of traceroute supports it right now 💀
  • dataType - Unsigned8
  • units - timeouts

5.2.2.15. CtlDontFragment 🧷

  • name - CtlDontFragment
  • description - This tells you if the don't fragment (DF) flag in the IP header for a probe was enabled or not (if it's in the MeasurementMetadata element) 🌟 If it's in the RequestMetadata element, it tells you whether enabling the flag was requested. Setting the DF flag can be used for performing a manual PATH MTU test, which is a total power move 💪
  • dataType - boolean
  • units - N/A

5.2.2.16. CtlInitialTtl 🚀

  • name - CtlInitialTtl
  • description - This specifies the initial TTL value for a traceroute measurement 🌙 It's requested if it's in the RequestMetadata element, and actually used if it's in the MeasurementMetadata element. This TTL setting is meant to skip over the initial (often well-known) part of a path, so you don't waste time there 🙌
  • dataType - u8nonzero
  • units - N/A

5.2.2.17. CtlDescr 📝

  • name - CtlDescr
  • description - This one gives you a description of the traceroute measurement 🎀
  • dataType - string255
  • units - N/A

5.2.2.18. CtlType 🧩

  • name - CtlType
  • description - This specifies the implementation method used for the traceroute measurement 🛠️ It's requested if it's in the RequestMetadata element, and actually used if it's in the MeasurementMetadata element. It tells you whether the traceroute uses TCP, UDP, ICMP, or other types of probes. You can also specify other types of probes by using an element defined in another schema with a different namespace, which is giving flexibility 🌈
  • dataType - probesType
  • units - N/A

5.2.3. Results Information Elements 📊

This section is all about the elements that are specific to the results of the traceroute measurement 🦋

5.2.3.1. ResultsStartDateAndTime 🗓️

  • name - ResultsStartDateAndTime
  • description - This specifies the date and start time of the traceroute measurement ⏱️ It's the time when the first probe was seen at the sending interface.
  • dataType - DateTime
  • units - N/A

5.2.3.2. ResultsIpTgtAddrType 🏷️

  • name - ResultsIpTgtAddrType
  • description - This specifies the type of address in the matching ResultsIpTgtAddr element 💕 This element isn't directly reflected in the XML schema of Section 7. You can tell the host address type by checking the inetAddress type name and the matching element value.
  • dataType - inetAddressType
  • units - N/A

5.2.3.3. ResultsIpTgtAddr 🎯

  • name - ResultsIpTgtAddr
  • description - This specifies the IP address associated with a CtlTargetAddress value when the destination address is given as a DNS name 🌐 The value of this object should be unknown if a DNS name isn't specified, or if a specified DNS name fails to resolve 🫠
  • dataType - inetAddress
  • units - N/A

5.2.3.4. HopAddrType 🧭

  • name - HopAddrType
  • description - This specifies the type of address in the matching HopAddr element ✨ This element isn't directly reflected in the XML schema of Section 7. You can tell the host address type by checking the inetAddress type name and the matching element value. DNS names are not allowed for HopAddr, so no DNS names here, babe 🙅‍♀️
  • dataType - inetAddressType
  • units - N/A

5.2.3.5. HopAddr 📍

  • name - HopAddr
  • description - This is the address of a hop in the traceroute measurement path 🛤️ This object is not allowed to be a DNS name.
  • dataType - inetAddress
  • units - N/A

5.2.3.6. HopName 🏠

  • name - HopName
  • description - This specifies the DNS name of the HopAddr, if one is available 🪪 If it isn't available, the element is omitted.
  • dataType - inetAddress
  • units - N/A

5.2.3.7. MPLSLabelStackEntry 🏷️

  • name - MPLSLabelStackEntry
  • description - This one specifies entries of the MPLS label stack of a probe, observed when the probe arrived at the hop that replied to it 🧠 It holds one MPLS label stack entry as a 32-bit value, exactly as it's observed on the MPLS label stack. Packed into that single number are the MPLS label, the Exp field, the S flag, and the MPLS TTL value, as specified in [RFC3032] 🌷 If more than one MPLS label stack entry is reported, you use multiple instances of this element. They must be ordered in the same order as on the label stack, with the top label stack entry reported first. Order matters, no cap 👑
  • dataType - unsignedInt
  • units - N/A

5.2.3.8. ProbeRoundTripTime ⏱️

  • name - ProbeRoundTripTime
  • description - okay so if this element holds the element roundTripTime, it tells you how many milliseconds passed from when a probe got sent to when its response came back, or when it timed out. ⏱️ The value is the truncation of the number the traceroute tool reports, so the output < 1 ms gets encoded as 0 ms. 🤏 If it holds roundTripTimeNotAvailable instead, that means either the probe was lost to a timeout or it couldn't be transmitted at all 💀
  • dataType - unsignedShort or string
  • units - milliseconds or N/A

5.2.3.9. ResponseStatus 💅

  • name - ResponseStatus
  • description - this is the result of a traceroute measurement made by the host for a particular probe. The host's verdict on each probe, basically 👑
  • dataType - operationResponseStatus
  • units - N/A

5.2.3.10. Time 🕰️

  • name - Time
  • description - this is the timestamp for when the response to the probe was received at the interface. 🎀
  • dataType - DateTime
  • units - N/A

5.2.3.11. ResultsEndDateAndTime 🏁

  • name - ResultsEndDateAndTime
  • description - this specifies the date and end time of the traceroute measurement. It's either the time when the response to the last probe came in, or the time when the last probe got sent plus the relative timeout (for when there's no response). ✨
  • dataType - DateTime
  • units - N/A

5.2.3.12. HopRawOutputData 🌸

  • name - HopRawOutputData
  • description - this is the raw output data returned by the traceroute measurement for a certain hop in a traceroute measurement path. It's an implementation-dependent, printable string, and it's expected to be useful for a human interpreting the traceroute results. 🧚
  • dataType - string
  • units - N/A

5.2.4. Information Element Correlating Configuration and Results Elements 🔗

Okay bestie, this section adds one more element that belongs to both groups (configuration elements and results elements), called TestName. Its whole job is to connect configuration and results through a common unique identifier 🫶 (which is chosen in accordance to the specification of [RFC4560]).

5.2.4.1. TestName 🏷️

  • name - TestName
  • description - this is the name of a traceroute measurement. It's not necessarily unique within any well-defined scope (for example, a specific host or the initiator of the traceroute measurement). 💜
  • dataType - string255
  • units - N/A

5.2.5. Information Elements to Compare Traceroute Measurement Results with Each Other 🆚

These are more extra elements that belong to both previous groups (configuration elements and results elements). They exist so you can compare traceroute measurement results across different traceroute measurements. Main character energy for data analysis 📊✨

5.2.5.1. OSName 🖥️

  • name - OSName
  • description - this is the name of the operating system the traceroute measurement was launched on. This element is ignored if it's used in the RequestMetadata. 🙈
  • dataType - string255
  • units - N/A

5.2.5.2. OSVersion 🧁

  • name - OSVersion
  • description - this is the OS version the traceroute measurement was launched on. This element is ignored if it's used in the RequestMetadata. 🍓
  • dataType - string255
  • units - N/A

5.2.5.3. ToolVersion 🛠️

  • name - ToolVersion
  • description - this is the version of the traceroute tool. It's the version requested to be used if it's in the RequestMetadata element, and the version actually used if it's in the MeasurementMetadata element. 🦋
  • dataType - string255
  • units - N/A

5.2.5.4. ToolName 🔧

  • name - ToolName
  • description - this is the name of the traceroute tool. It's the tool requested to be used if it's in the RequestMetadata element, and the tool actually used if it's in the MeasurementMetadata element. 💅
  • dataType - string255
  • units - N/A

6. Data Model for Storing Traceroute Measurements 🗂️

Okay so to store and transmit the info from the information model we just went over, you need a data model that says how to encode the elements. 🫶

There are a bunch of design choices here. The data model can be binary or textual, and it can be built from scratch or use frameworks and data models that already exist. Generally speaking, already existing frameworks and models should be preferred. 👑

Binary and textual both have their pros and cons. Textual stuff is (with some limitations) human-readable, while binary eats up fewer resources when it comes to storing, transmitting, and parsing data. 🤓

There's an already existing and closely related data model: the DISMAN-TRACEROUTE-MIB module [RFC4560]. It specifies a Structure of Management Information version 2 (SMIv2) encoding [RFC2578], [RFC2579], and [RFC2580] for transmitting traceroute measurement information (configuration and results). It's super well suited and supported within network management systems 🖥️, but as a general format for storing and transmitting traceroute results, it's not easily applicable. 🙃

Another binary option would be an extension of traffic-flow information encodings, as specified for the IP Flow Information Export (IPFIX) protocol [RFC5101], [RFC5102]. IPFIX is extensible, which is great. However, the architecture behind this protocol [IPFIX] is targeted at exporting passively measured flow information, so some obstacles are expected if you try to use it for transmitting traceroute measurement information. 🚧

For textual representations, the eXtensible Markup Language (XML) [W3C.REC-xml-20060816] is an obvious choice. XML supports clean structuring of data and syntax checking of records. With some limitations, it's human-readable, and it's supported by a huge pool of tools and standards for generating, transmitting, parsing, and converting to other data formats. 🌈 The downside is the resource consumption for processing, storing, and transmitting information. But since the expected data volumes for traceroute measurement in network operation and maintenance aren't expected to be extremely high, that inefficient use of resources isn't a significant disadvantage. ✨ So XML was chosen as the basis for the traceroute measurement information model specified in this memo. 💖

Section 7 contains the XML schema to be used as a template for storing and/or exchanging traceroute measurement information. The schema uses an extensible, template-based approach (pretty similar to how IPFIX is designed). The traceroute configuration elements, both the requested parameters (RequestMetadata) and the actual parameters used (MeasurementMetadata), are metadata that results information elements (data) reference by means of the TestName element. TestName is used as a unique identifier, chosen in accordance to the specification of [RFC4560]. 🔗

Open Grid Forum (OGF) is also using this approach, and cross-requirements have been analyzed. As a result, the XML schema in Section 7 is compatible with the OGF schema, since both were designed to limit unnecessary redundancy, and a simple one-to-one transformation between the two exists. 🤝🌸

7. XML Schema for Traceroute Measurements 📜

This section presents the XML schema to be used as a template for storing and/or exchanging traceroute measurement information. The schema uses UTF-8 encoding as defined in [RFC3629]. In documents conforming to the format here, an XML declaration SHOULD be present, specifying the version and the character encoding of the XML document. The document should be encoded using UTF-8. Since some strings can span multiple lines, [RFC5198] applies. XML processing instructions and comments MUST be ignored. Mind that whitespace is significant in XML when writing documents conforming to this schema. 🫠 Documents using the presented format must be valid according to the XML schema shown in this section. Since elements of type _CtlType may contain elements from unknown namespaces, those elements MUST be ignored if their namespace is unknown to the processor. Values for elements using the XML schema type dateTime MUST be restricted to values defined in [RFC3339]. Future versions of this format MAY extend this schema by creating a new schema that redefines all or some of the data types and elements defined in this version, or by establishing a complete new schema. 🦋

Due to the limited line length, some lines appear wrapped. 📏

 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema elementFormDefault="qualified"
            targetNamespace="urn:ietf:params:xml:ns:traceroute-1.0"
            xmlns:xs="http://www.w3.org/2001/XMLSchema"
            xmlns:tr="urn:ietf:params:xml:ns:traceroute-1.0">
   <xs:simpleType name="string255">
     <xs:annotation>
       <xs:documentation>String restricted to 255
       characters.</xs:documentation>
     </xs:annotation>

     <xs:restriction base="xs:string">
       <xs:maxLength value="255"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:simpleType name="u8nonzero">
     <xs:annotation>
       <xs:documentation>unsignedByte with non zero
       value.</xs:documentation>
     </xs:annotation>

     <xs:restriction base="xs:unsignedByte">
       <xs:minInclusive value="1"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:complexType name="_roundTripTime">
     <xs:choice>
       <xs:element name="roundTripTime">
         <xs:simpleType>
           <xs:restriction base="xs:unsignedInt"/>
         </xs:simpleType>
       </xs:element>

       <xs:element name="roundTripTimeNotAvailable">
         <xs:complexType/>
       </xs:element>
     </xs:choice>
   </xs:complexType>

   <xs:complexType name="_inetAddressUnknown"/>

   <xs:simpleType name="_inetAddressIpv4">
     <xs:restriction base="xs:string">
       <xs:pattern value="(([1-9]?[0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5

 ]).){3}([1-9]?[0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:simpleType name="_inetAddressIpv6">
     <xs:restriction base="xs:string">
       <xs:pattern value="(([\dA-Fa-f]{1,4}:){7}[\dA-Fa-f]{1,4})(:([\d
 ]{1,3}.){3}[\d]{1,3})?"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:simpleType name="_inetAddressDns">
     <xs:restriction base="xs:string">
       <xs:maxLength value="256"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:complexType name="_inetAddressASNumber">
     <xs:annotation>
       <xs:documentation>Specifies the AS number of a hop in the
       traceroute path as a 32-bit number and indicates how the
       mapping from IP address to AS number was
       performed.</xs:documentation>
     </xs:annotation>

     <xs:sequence>
       <xs:element name="asNumber" type="xs:unsignedInt"/>

       <xs:element name="ipASNumberMappingType">
         <xs:simpleType>
           <xs:restriction base="xs:string">
             <xs:enumeration value="bgptables"/>

             <xs:enumeration value="routingregistries"/>

             <xs:enumeration value="nslookup"/>

             <xs:enumeration value="others"/>

             <xs:enumeration value="unknown"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:element>
     </xs:sequence>
   </xs:complexType>

   <xs:complexType name="inetAddress">
     <xs:choice>

Okay bestie, the schema keeps going and it's giving chaotic but organized 🎀✨ Here are the address choice types, where the DNS name is optional and the no-DNS version is stricter 💅

       <xs:element name="inetAddressUnknown"
                   type="tr:_inetAddressUnknown"/>

       <xs:element name="inetAddressIpv4" type="tr:_inetAddressIpv4"/>

       <xs:element name="inetAddressIpv6" type="tr:_inetAddressIpv6"/>

       <xs:element name="inetAddressASNumber"
                   type="tr:_inetAddressASNumber"/>

       <xs:element minOccurs="0" name="inetAddressDns"
                   type="tr:_inetAddressDns"/>
     </xs:choice>
   </xs:complexType>

Next up is the no-DNS version, inetAddressWithoutDns 🌸 It's the same set of options minus the DNS one, so a HopAddr can never be a name. Iconic restraint 🙈

   <xs:complexType name="inetAddressWithoutDns">
     <xs:sequence>
       <xs:choice>
         <xs:element name="inetAddressUnknown"
                     type="tr:_inetAddressUnknown"/>

         <xs:element name="inetAddressIpv4"
                     type="tr:_inetAddressIpv4"/>

         <xs:element name="inetAddressIpv6"
                     type="tr:_inetAddressIpv6"/>

         <xs:element name="inetAddressASNumber"
                     type="tr:_inetAddressASNumber"/>
       </xs:choice>
     </xs:sequence>
   </xs:complexType>

   <xs:simpleType name="operationResponseStatus">
     <xs:restriction base="xs:string">
       <xs:enumeration value="responseReceived"/>

       <xs:enumeration value="unknown"/>

       <xs:enumeration value="internalError"/>

       <xs:enumeration value="requestTimedOut"/>

       <xs:enumeration value="unknownDestinationAddress"/>

       <xs:enumeration value="noRouteToTarget"/>

       <xs:enumeration value="interfaceInactiveToTarget"/>
       <xs:enumeration value="arpFailure"/>

       <xs:enumeration value="maxConcurrentLimitReached"/>

       <xs:enumeration value="unableToResolveDnsName"/>

       <xs:enumeration value="invalidHostAddress"/>
     </xs:restriction>
   </xs:simpleType>

Now the operationResponseStatus enum, which is the list of every outcome a probe can have 🦋 Each value is a fixed string, so no freestyling allowed 💀

Next is the protocol choice, _CtlType. It's a pick-one between TCP, UDP, and ICMP, plus a wildcard for anything from another namespace 🧚

   <xs:complexType name="_CtlType">
     <xs:choice>
       <xs:element name="TCP">
         <xs:complexType/>
       </xs:element>

       <xs:element name="UDP">
         <xs:complexType/>
       </xs:element>

       <xs:element name="ICMP">
         <xs:complexType/>
       </xs:element>

       <xs:any namespace="##other"/>
     </xs:choice>
   </xs:complexType>

   <xs:complexType name="_ProbeResults">
     <xs:sequence>
       <xs:element maxOccurs="255" name="hop">
         <xs:complexType>
           <xs:sequence>
             <xs:element maxOccurs="10" name="probe">
               <xs:complexType>
                 <xs:sequence>
                   <xs:element name="HopAddr"
                               type="tr:inetAddressWithoutDns">
                     <xs:annotation>
                       <xs:documentation>Specifies the address of a
                       hop in the traceroute measurement path.  This
                       object is not allowed to be a DNS name.  The
                       address type can be determined by examining the
                       "inetAddress" type name and the corresponding
                       element value.</xs:documentation>
                     </xs:annotation>
                   </xs:element>
                   <xs:element minOccurs="0" name="HopName"
                               type="tr:_inetAddressDns">
                     <xs:annotation>
                       <xs:documentation>Specifies the DNS name of
                       the "HopAddr" if it is available.  If it is
                       not available, the element is
                       omitted.</xs:documentation>
                     </xs:annotation>
                   </xs:element>

                   <xs:element maxOccurs="255" minOccurs="0"
                               name="MPLSLabelStackEntry">
                     <xs:annotation>
                       <xs:documentation>Specifies entries of the
                       MPLS label stack of a probe observed when the
                       probe arrived at the hop that replied to the
                       probe.  This object contains one MPLS label stack
                       entry as a 32-bit value as it is observed on the
                       MPLS label stack.  Contained in this single
                       number are the MPLS label, the Exp field, the S
                       flag, and the MPLS TTL value as specified in
                       [RFC3032].  If more than one MPLS label stack
                       entry is reported, then multiple instances of
                       elements of this type are used.  They must be
                       ordered in the same order as on the label stack
                       with the top label stack entry being reported
                       first.</xs:documentation>
                     </xs:annotation>

                     <xs:simpleType>
                       <xs:restriction base="xs:unsignedInt">
                         <xs:maxInclusive value="4294967295"/>
                       </xs:restriction>
                     </xs:simpleType>
                   </xs:element>

                   <xs:element name="ProbeRoundTripTime"
                               type="tr:_roundTripTime">
                     <xs:annotation>
                       <xs:documentation>If this element contains the
                       element "roundTripTime", this specifies the
                       amount of time measured in milliseconds from
                       when a probe was sent to when its response was
                       received or when it timed out.  The value of
                       this element is reported as the truncation of
                       the number reported by the traceroute tool (the
                       output "&lt; 1 ms" is therefore encoded as 0 ms).
                       If it contains the element
                       "roundTripTimeNotAvailable", it means either
                       the probe was lost because of a timeout or it
                       was not possible to transmit a probe.
                       </xs:documentation>
                     </xs:annotation>
                   </xs:element>

                   <xs:element name="ResponseStatus"
                               type="tr:operationResponseStatus">
                     <xs:annotation>
                       <xs:documentation>Specifies the result of a
                       traceroute measurement made by the host for a
                       particular probe.</xs:documentation>
                     </xs:annotation>
                   </xs:element>

                   <xs:element name="Time" type="xs:dateTime">
                     <xs:annotation>
                       <xs:documentation>Specifies the timestamp for
                       the time the response to the probe was
                       received at the interface.</xs:documentation>
                     </xs:annotation>
                   </xs:element>
                 </xs:sequence>
               </xs:complexType>
             </xs:element>

             <xs:element minOccurs="0" name="HopRawOutputData"
                         type="tr:string255">
               <xs:annotation>
                 <xs:documentation>Specifies the raw output data
                 returned by the traceroute measurement for a
                 certain hop in a traceroute measurement path.  It is
                 an implementation-dependent, printable string,
                 expected to be useful for a human interpreting the
                 traceroute results.</xs:documentation>
               </xs:annotation>
             </xs:element>
           </xs:sequence>
         </xs:complexType>
       </xs:element>
     </xs:sequence>
   </xs:complexType>

Now for _ProbeResults 💖 This is the big one. Up to 255 hops, each with up to 10 probes, and every probe reports its address, optional name, MPLS label stack, round trip time, status, and timestamp. It's a whole organized diary of the trip 🍓 Also, the MPLS label stack entries have to go in the order they appear on the stack, top one first. Very particular, very valid 👑

Last stop is the metadata block, _Metadata 🌈 It holds the test's name, the OS details, the tool name and version, the target address, and the route table bypass flag. Some fields only count in the request, some only in the measurement, and some ignore themselves depending on which one they're in. Main character energy 😭

   <xs:complexType name="_Metadata">
     <xs:annotation>
       <xs:documentation>Specifies the metadata for a traceroute
       operation -- the parameters requested if used in
       "RequestMetadata" or the actual parameters used if used in
       "MeasurementMetadata".</xs:documentation>
     </xs:annotation>

     <xs:sequence>
       <xs:element name="TestName" type="tr:string255">
         <xs:annotation>
           <xs:documentation>Specifies the name of a traceroute
           measurement.  This is not necessarily unique within any
           well-defined scope (e.g., a specific host, initiator of
           the traceroute measurement).</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="" name="OSName" type="tr:string255">
         <xs:annotation>
           <xs:documentation>Specifies the name of the operating
           system on which the traceroute measurement was launched.
           This element is ignored if used in the
           "RequestMetadata".</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="" name="OSVersion" type="tr:string255">
         <xs:annotation>
           <xs:documentation>Specifies the OS version on which the
           traceroute measurement was launched.  This element is
           ignored if used in the
           "RequestMetadata".</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="" name="ToolVersion" type="tr:string255">
         <xs:annotation>
           <xs:documentation>Specifies the version of the traceroute
           tool (requested to be used if in the "RequestMetadata"
           element, actually used if in the "MeasurementMetadata"
           element).</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="" name="ToolName" type="tr:string255">
         <xs:annotation>
           <xs:documentation>Specifies the name of the traceroute
           tool (requested to be used if in the "RequestMetadata"
           element, actually used if in the "MeasurementMetadata"
           element).</xs:documentation>
         </xs:annotation>

       </xs:element>

       <xs:element name="CtlTargetAddress" type="tr:inetAddress">
         <xs:annotation>
           <xs:documentation>In the "RequestMetadata" element, it
           specifies the host address requested to be used in the
           traceroute measurement.  In the "MeasurementMetadata"
           element, it specifies the host address used in the
           traceroute measurement.  The host address type can be
           determined by examining the "inetAddress" type name and
           the corresponding element value.</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="false" name="CtlBypassRouteTable"
                   type="xs:boolean">
         <xs:annotation>
           <xs:documentation>In the "RequestMetadata" element
           specifies if the optional bypassing of the route
           table was enabled or not.  In the "MeasurementMetadata"
           element, specifies if the optional bypassing of the route
           table was enabled or not.  If enabled, the normal routing
           tables will be bypassed and the probes will be sent
           directly to a host on an attached network.  If the host is
           not on a directly attached network, an error is returned.
           This option can be used to perform the traceroute
           measurement to a local host through an interface that has
           no route defined.  This object can be used when the
           setsockopt SOL_SOCKET SO_DONTROUTE option is supported and
           set (see the POSIX standard IEEE.1003-1G.1997).
           </xs:documentation>
         </xs:annotation>
       </xs:element>

okay the schema is where it gets SO detailed 💅🎀 every single tag and default value matters, so this part is pure exact copy. no cap 🫶

       <xs:element default="0" name="CtlProbeDataSize">
         <xs:annotation>
           <xs:documentation>Specifies the size of the probes of a
           traceroute measurement in octets (requested if in the
           "RequestMetadata" element, actually used if in the
           "MeasurementMetadata" element).  If UDP datagrams are used
           as probes, then the value contained in this object is
           exact.  If another protocol is used to transmit probes
           (i.e., TCP or ICMP) for which the specified size is not
           appropriate, then the implementation can use whatever
           size (appropriate to the method) is closest to the
           specified size.  The maximum value for this object is
           computed by subtracting the smallest possible IP header
           size of 20 octets (IPv4 header with no options) and the
           UDP header size of 8 octets from the maximum IP packet
           size.  An IP packet has a maximum size of 65535 octets
           (excluding IPv6 jumbograms).</xs:documentation>
         </xs:annotation>

         <xs:simpleType>
           <xs:restriction base="xs:unsignedShort">
             <xs:maxInclusive value="65507"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:element>

       <xs:element default="3" name="CtlTimeOut">
         <xs:annotation>
           <xs:documentation>Specifies the timeout value, in
           seconds, for each probe of a traceroute measurement
           (requested if in the "RequestMetadata" element, actually
           used if in the "MeasurementMetadata"
           element).</xs:documentation>
         </xs:annotation>

         <xs:simpleType>
           <xs:restriction base="xs:unsignedByte">
             <xs:minInclusive value="1"/>

             <xs:maxInclusive value="60"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:element>

       <xs:element default="3" name="CtlProbesPerHop">
         <xs:annotation>
           <xs:documentation>Specifies the number of probes with the
           same time-to-live (TTL) value that are sent for each host
           (requested if in the "RequestMetadata" element, actually
           used if in the "MeasurementMetadata"
           element).</xs:documentation>
         </xs:annotation>

         <xs:simpleType>
           <xs:restriction base="xs:unsignedByte">
             <xs:minInclusive value="1"/>

             <xs:maxInclusive value="10"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:element>
       <xs:element default="33434" name="CtlPort">
         <xs:annotation>
           <xs:documentation>Specifies the base port used by the
           traceroute measurement (requested if in the
           "RequestMetadata" element, actually used if in the
           "MeasurementMetadata" element).</xs:documentation>
         </xs:annotation>

         <xs:simpleType>
           <xs:restriction base="xs:unsignedShort">
             <xs:minInclusive value="1"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:element>

       <xs:element default="30" name="CtlMaxTtl" type="tr:u8nonzero">
         <xs:annotation>
           <xs:documentation>Specifies the maximum TTL value for the
           traceroute measurement (requested if in the
           "RequestMetadata" element, actually used if in the
           "MeasurementMetadata" element).</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="0" name="CtlDSField"
                   type="xs:unsignedByte">
         <xs:annotation>
           <xs:documentation>Specifies the value that was requested
           to be stored in the Differentiated Services (DS) field in
           the traceroute probe (if in the "RequestMetadata"
           element).  Specifies the value that was stored in the
           Differentiated Services (DS) field in the traceroute
           probe (if in the "MeasurementMetadata" element).  The DS
           field is defined as the Type of Service (TOS) octet in an
           IPv4 header or as the Traffic Class octet in an IPv6
           header (see Section 7 of [RFC2460]).  The value of this
           object must be a decimal integer in the range from 0 to
           255.  This option can be used to determine what effect an
           explicit DS field setting has on a traceroute measurement
           and its probes.  Not all values are legal or meaningful.
           Useful TOS octet values are probably 16 (low delay) and
           8 (high throughput).  Further references can be found in
           [RFC2474] for the definition of the Differentiated
           Services (DS) field and in [RFC1812] Section 5.3.2 for
           Type of Service (TOS).</xs:documentation>
         </xs:annotation>
       </xs:element>
       <xs:element name="CtlSourceAddress"
                   type="tr:inetAddressWithoutDns">
         <xs:annotation>
           <xs:documentation>Specifies the IP address (which has to
           be given as an IP number, not a hostname) as the source
           address in traceroute probes (requested if in the
           "RequestMetadata" element, actually used if in the
           "MeasurementMetadata" element).  On hosts with more than
           one IP address, this option can be used in the
           "RequestMetadata" element to force the source address to
           be something other than the primary IP address of the
           interface the probe is sent on; the value "unknown" means
           the default address will be used.  The address type can be
           determined by examining the "inetAddress" type name and the
           corresponding element value.</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="0" name="CtlIfIndex"
                   type="xs:unsignedInt">
         <xs:annotation>
           <xs:documentation>Specifies the interface index as
           defined in [RFC2863] that is requested to be used in the
           traceroute measurement for sending the traceroute probes
           (if in the "RequestMetadata" element).  A value of 0
           indicates that no specific interface is requested.
           Specifies the interface index actually used (if in the
           "MeasurementMetadata" element).</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element minOccurs="0" name="CtlMiscOptions"
                   type="tr:string255">
         <xs:annotation>
           <xs:documentation>Specifies implementation-dependent
           options (requested if in the "RequestMetadata" element,
           actually used if in the "MeasurementMetadata"
           element).</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="5" name="CtlMaxFailures"
                   type="xs:unsignedByte">
         <xs:annotation>
           <xs:documentation>Specifies the maximum number of
           consecutive timeouts allowed before terminating a
           traceroute measurement (requested if in the
           "RequestMetadata" element, actually used if in the
           "MeasurementMetadata" element).  A value of either 255
           (maximum hop count/possible TTL value) or 0 indicates
           that the function of terminating a remote traceroute
           measurement when a specific number of consecutive
           timeouts are detected was disabled.  This element is
           included to give full compatibility with [RFC4560].  No
           known implementation of traceroute currently supports
           it.</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="false" name="CtlDontFragment"
                   type="xs:boolean">
         <xs:annotation>
           <xs:documentation>Specifies if the don't fragment (DF)
           flag in the IP header for a probe was enabled or not (if
           in the "MeasurementMetadata" element).  If in the
           "RequestMetadata", it specifies if the flag was requested
           to be enabled or not.  Setting the DF flag can be used for
           performing a manual PATH MTU test.</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="1" name="CtlInitialTtl"
                   type="tr:u8nonzero">
         <xs:annotation>
           <xs:documentation>Specifies the initial TTL value for a
           traceroute measurement (requested if in the
           "RequestMetadata" element, actually used if in the
           "MeasurementMetadata" element).  Such TTL setting is
           intended to bypass the initial (often well-known) portion
           of a path.</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element maxOccurs="1" minOccurs="0" name="CtlDescr"
                   type="tr:string255">
         <xs:annotation>
           <xs:documentation>Provides a description of the traceroute
           measurement.</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element name="CtlType" type="tr:_CtlType">
         <xs:annotation>
           <xs:documentation>Specifies the implementation method
           used for the traceroute measurement (requested if in the
           "RequestMetadata" element, actually used if in the
           "MeasurementMetadata" element).  It specifies if the
           traceroute is using TCP, UDP, ICMP, or other types of
           probes.  It is possible to specify other types of probes
           by using an element specified in another schema with a
           different namespace.</xs:documentation>
         </xs:annotation>
       </xs:element>
     </xs:sequence>
   </xs:complexType>

   <xs:complexType name="_Measurement">
     <xs:annotation>
       <xs:documentation>Contains the actual traceroute measurement
       results.</xs:documentation>
     </xs:annotation>

     <xs:sequence>
       <xs:element name="TestName" type="tr:string255">
         <xs:annotation>
           <xs:documentation>Specifies the name of a traceroute
           measurement.  This is not necessarily unique within any
           well-defined scope (e.g., a specific host, initiator of
           the traceroute measurement).</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element name="ResultsStartDateAndTime" type="xs:dateTime">
         <xs:annotation>
           <xs:documentation>Specifies the date and start time of
           the traceroute measurement.  This is the time when the
           first probe was seen at the sending
           interface.</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element name="ResultsIpTgtAddr"
                   type="tr:inetAddressWithoutDns">
         <xs:annotation>
           <xs:documentation>Specifies the IP address associated
           with a "CtlTargetAddress" value when the destination
           address is specified as a DNS name.  The value of this
           object should be "unknown" if a DNS name is not specified
           or if a specified DNS name fails to resolve.  The
           address type can be determined by examining the "inetAddress"
           type name and the corresponding element
           value.</xs:documentation>
         </xs:annotation>
       </xs:element>
       <xs:element name="ProbeResults" type="tr:_ProbeResults"/>

       <xs:element name="ResultsEndDateAndTime" type="xs:dateTime">
         <xs:annotation>
           <xs:documentation>Specifies the date and end time of the
           traceroute measurement.  It is either the time when the
           response to the last probe of the traceroute measurement
           was received or the time when the last probe of the
           traceroute measurement was sent plus the relative timeout
           (in case of a missing response).</xs:documentation>
         </xs:annotation>
       </xs:element>
     </xs:sequence>
   </xs:complexType>

the CtlMaxFailures bit is lowkey wild 💀 "no known implementation of traceroute currently supports it" 🙈 the spec literally said that out loud

and the DS field note mentions Traffic Class octets in IPv6 🧚 that's the bit where the TOS and DS stuff all lines up ✨

   <xs:element name="traceRoute">
     <xs:complexType>
       <xs:sequence>
         <xs:element minOccurs="0" name="RequestMetadata"
                     type="tr:_Metadata"/>

         <xs:element maxOccurs="2147483647" minOccurs="0"
                     name="Measurement">
           <xs:complexType>
             <xs:sequence>
               <xs:element minOccurs="0" name="MeasurementMetadata"
                           type="tr:_Metadata"/>

               <xs:element maxOccurs="2147483647" minOccurs="0"
                           name="MeasurementResult"
                           type="tr:_Measurement"/>
             </xs:sequence>
           </xs:complexType>
         </xs:element>
       </xs:sequence>
     </xs:complexType>
   </xs:element>
 </xs:schema>

8. Security Considerations 🔐

Okay bestie, the security stuff splits into two vibes: the risks of actually running traceroute measurements, and the risks of storing and sending the measurement info around 🫶. Quick tea: this doc doesn't define a traceroute tool 🔧, and it doesn't pick one specific way to store the measurement info either 📦. Still, it's considered desirable to talk through the related security issues below 👀.

8.1. Conducting Traceroute Measurements 🚀

Running Internet measurements can raise both security AND privacy concerns 😬. Traceroute measurements inject traffic into the network, and that traffic can get abused for denial-of-service attacks that are dressed up as totally legit measurement activity 💀.

Measurement parameters MUST be carefully selected 🎯 so the measurements only inject trivial amounts of extra traffic into the networks they measure. If they inject "too much" traffic, they can skew the results, and in extreme cases cause congestion and denial of service 🚨.

The measurements themselves can get messed up if routers treat measurement traffic with a different priority than "normal" traffic 🙅, or if some sneaky attacker injects fake measurement traffic 🥷. If routers can spot measurement traffic and handle it differently, the results won't reflect what real users are actually getting. And if an attacker's fake traffic gets accepted as legit, the loss rate gets artificially lowered 📉. So the measurement methodologies SHOULD include appropriate techniques to reduce the probability that measurement traffic can be distinguished from "normal" traffic 🕵️.

Authentication techniques, like digital signatures, may be used where appropriate to guard against injected traffic attacks 🔏.

8.2. Securing Traceroute Measurement Information 🔒

Traceroute measurement info isn't considered highly sensitive 🙂. Still, it may contain sensitive info on network paths, routing states, used IP addresses, and roundtrip times, and network operators may want to protect that stuff for business or security reasons 🏢.

It's thus important to control access to information acquired by conducting traceroute measurements, especially when it's being transmitted over a network, but also when it's stored 🗝️. It is RECOMMENDED that a transmission of traceroute measurement information over a network uses appropriate protection mechanisms for preserving privacy, integrity, and authenticity. It is further RECOMMENDED that secure authentication and authorization are used for protecting stored traceroute measurement information 🛡️.

9. IANA Considerations 📋

So this doc uses URNs to name an XML namespace and an XML schema for storing and transmitting traceroute measurement info 🧾, following the registry mechanism described in [RFC3688]. Two URI assignments have been made ✨.

  1. Registration for the IPPM traceroute measurements namespace
    • URI: urn:ietf:params:xml:ns:traceroute-1.0
    • Registrant Contact: IESG
    • XML: None. Namespace URIs do not represent an XML.
  2. Registration for the IPPM traceroute measurements schema
    • URI: urn:ietf:params:xml:schema:traceroute-1.0
    • Registrant Contact: IESG
    • XML: See Section 7 of this document.

10. References 📚

10.1. Normative References 🧷

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
  • [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
  • [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
  • [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
  • [RFC4560] Quittek, J. and K. White, "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", RFC 4560, June 2006.
  • [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.

10.2. Informative References 🦋

  • [IEEE.1003-1G.1997] Institute of Electrical and Electronics Engineers, "Protocol Independent Interfaces", IEEE Standard 1003.1G, March 1997.
  • [IPFIX] Sadasivan, G., "Architecture for IP Flow Information Export", Work in Progress, September 2006.
  • [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
  • [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
  • [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
  • [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
  • [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
  • [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
  • [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
  • [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
  • [W3C.REC-xml-20060816] Bray, T., Paoli, J., Maler, E., Sperberg-McQueen, C., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium FirstEdition REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.
  • [W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

Appendix A. Traceroute Default Configuration Parameters ✨

okay so this section is basically a cheat sheet 🧚 It lists the traceroute knobs you can turn, plus what the defaults are on different platforms, and shows how wildly they can differ. We're looking at four big traceroute tools. LINUX (SUSE 9.1), BSD (FreeBSD 7.0), and UNIX (SunOS 5.9) all send UDP datagrams, but WINDOWS (XP SP2) uses ICMP Echoes instead 🫶 The table below compares them. If an option cell says N/A, that parameter just isn't configurable on that implementation 💅

Obviously this isn't a full survey of every traceroute out there. It's outside the scope of this doc. Still, sampling a few different ones shows they can be super different when it comes to both the settings you can change and the defaults they ship with 👑 Also, the table only includes options that at least two of the four implementations support, so you won't see everything 🙈

         +---------------------------------------------------------+
         |  OS    |Option|           Description         | Default |
         +--------+------+-------------------------------+---------+
         | LINUX  | -m   |Specify the maximum TTL used   |   30    |
         |--------+------|in traceroute probes.          |---------|
         | FreeBSD| -m   |                               |  OS var |
         |--------+------|                               |---------|
         | UNIX   | -m   |                               |   30    |
         |--------+------|                               |---------|
         | WINDOWS| -h   |                               |   30    |
         +--------+------+-------------------------------+---------+
         | LINUX  | -n   |Display hop addresses          |    -    |
         |--------+------|numerically rather than        |---------|
         | FreeBSD| -n   |symbolically.                  |    -    |
         |--------+------|                               |---------|
         | UNIX   | -n   |                               |    -    |
         |--------+------|                               |---------|
         | WINDOWS| -d   |                               |    -    |
         +--------+------+-------------------------------+---------+
         | LINUX  | -w   |Set the time to wait for a     |  3 sec  |
         |--------+------|response to a probe.           |---------|
         | FreeBSD| -w   |                               |  5 sec  |
         |--------+------|                               |---------|
         | UNIX   | -w   |                               |  5 sec  |
         |--------+------|                               |---------|
         | WINDOWS| -w   |                               |  4 sec  |
         +--------+------+-------------------------------+---------+
         | LINUX  | N/A  |Specify a loose source route   |    -    |
         |--------+------|gateway (to direct the         |---------|
         | FreeBSD| -g   |traceroute probes through      |    -    |
         |--------+------|routers not necessarily in     |---------|
         | UNIX   | -g   | the path).                    |    -    |
         |--------+------|                               |---------|
         | WINDOWS| -g   |                               |    -    |
         +--------+------+-------------------------------+---------+
         | LINUX  | -p   |Set the base UDP port number   |  33434  |
         |------- +------|used in traceroute probes      |---------|
         | FreeBSD| -p   |(UDP port = base + nhops - 1). |  33434  |
         |--------+------|                               |---------|
         | UNIX   | -p   |                               |  33434  |
         |--------+------|                               |---------|
         | WINDOWS| N/A  |                               |    -    |
         +--------+------+-------------------------------+---------+
         | LINUX  | -q   |Set the number of probes per   |    3    |
         |--------+------|TTL.                           |---------|
         | FreeBSD| -q   |                               |    3    |
         |--------+------|                               |---------|
         | UNIX   | -q   |                               |    3    |
         |--------+------|                               |---------|
         | WINDOWS| N/A  |                               |    3    |
         +--------+------+-------------------------------+---------+
         | LINUX  | -S   |Set the IP source address in   |IP       |
         |--------+------|outgoing probes to the         |address  |
         | FreeBSD| -s   |specified value.               |of the   |
         |--------+------|                               |out      |
         | UNIX   | -s   |                               |interface|
         |--------+------|                               |         |
         | WINDOWS| N/A  |                               |         |
         +--------+------+-------------------------------+---------+
         | LINUX  | -t   |Set the Type of Service (TOS)  |    0    |
         |--------+------|in the probes to the specified |---------|
         | FreeBSD| -t   |value.                         |    0    |
         |--------+------|                               |---------|
         | UNIX   | -t   |                               |    0    |
         |--------+------|                               |---------|
         | WINDOWS| N/A  |                               |    0    |
         +--------+------+-------------------------------+---------+
         | LINUX  | -v   |Verbose output: received ICMP  |    -    |
         |--------+------|packets other than             |---------|
         | FreeBSD| -v   |TIME_EXCEEDED and              |    -    |
         |--------+------|UNREACHABLE are listed.        |---------|
         | UNIX   | -v   |                               |    -    |
         |--------+------|                               |---------|
         | WINDOWS| N/A  |                               |    -    |
         +--------+------+-------------------------------+---------+
         | LINUX  | N/A  |Set  the time (in msec) to     |    -    |
         |--------+------|pause between probes.          |---------|
         | FreeBSD| -z   |                               |    0    |
         |--------+------|                               |---------|
         | UNIX   | -P   |                               |    0    |
         |--------+------|                               |---------|
         | WINDOWS| N/A  |                               |    -    |
         +--------+------+-------------------------------+---------+
         | LINUX  | -r   |Bypass the normal routing      |    -    |
         |--------+------|tables and send directly to a  |---------|
         | FreeBSD| -r   |host on attached network.      |    -    |
         |--------+------|                               |---------|
         | UNIX   | -r   |                               |    -    |
         |--------+------|                               |---------|
         | WINDOWS| N/A  |                               |    -    |
         +--------+------+-------------------------------+---------+
         | LINUX  | -f   |Set the initial TTL for the    |    1    |
         |--------+------|first probe.                   |---------|
         | FreeBSD| -f   |                               |    1    |
         |--------+------|                               |---------|
         | UNIX   | -f   |                               |    1    |
         |--------+------|                               |---------|
         | WINDOWS| N/A  |                               |    1    |
         +--------+------+-------------------------------+---------+
         | LINUX  | -F   |Set the "don't fragment" bit.  |    -    |
         |--------+------|                               |---------|
         | FreeBSD| -F   |                               |    -    |
         |--------+------|                               |---------|
         | UNIX   | -F   |                               |    -    |
         |--------+------|                               |---------|
         | WINDOWS| N/A  |                               |    -    |
         +--------+------+-------------------------------+---------+
         | LINUX  | N/A  |Enable socket level debugging. |    -    |
         |--------+------|                               |---------|
         | FreeBSD| -d   |                               |    -    |
         |--------+------|                               |---------|
         | UNIX   | -d   |                               |    -    |
         |--------+------|                               |---------|
         | WINDOWS| N/A  |                               |    -    |
         +--------+------+-------------------------------+---------+
         | LINUX  | N/A  |Use ICMP Echoes instead of UDP |    -    |
         |--------+------|datagrams.                     |---------|
         | FreeBSD| -I   |                               |    -    |
         |--------+------|                               |---------|
         | UNIX   | -I   |                               |    -    |
         |--------+------|                               |---------|
         | WINDOWS| N/A  |                               |    -    |
         +--------+------+-------------------------------+---------+
         | LINUX  | -I   |Specify a network interface to |    -    |
         |--------+------|obtain the IP address for      |---------|
         | FreeBSD| -i   |outgoing IP packets            |    -    |
         |--------+------|(alternative to option -s).    |---------|
         | UNIX   | -i   |                               |    -    |
         |--------+------|                               |---------|
         | WINDOWS| N/A  |                               |    -    |
         +--------+------+-------------------------------+---------+
         | LINUX  | N/A  |Toggle checksum.               |    -    |
         |--------+------|                               |---------|
         | FreeBSD| -x   |                               |    -    |
         |--------+------|                               |---------|
         | UNIX   | -x   |                               |    -    |
         |--------+------|                               |---------|
         | WINDOWS| N/A  |                               |    -    |
         +--------+------+-------------------------------+---------+
         | LINUX  |  -   |As optional last parameter,    |Depends  |
         |--------+------|LINUX, FreeBSD, and UNIX       |on       |
         | FreeBSD|  -   |implementations allow          |implement|
         |--------+------|specifying the probe datagram  |ation.   |
         | UNIX   |  -   |length for outgoing probes.    |         |
         |--------+------|                               |         |
         | WINDOWS| N/A  |                               |         |
         +--------+------+-------------------------------+---------+

A.1. Alternative Traceroute Implementations 🦋

okay so, as we said earlier, firewalls are kind of a menace 🙄 because they can be so picky that UDP- or ICMP-based traceroutes can't fully trace the path to a destination. the probes just get filtered out and vanish. 💀 but there's a workaround that can sometimes help: send TCP packets instead, aimed at specific ports that hosts behind the firewall are listening on. TCP-based implementations use TCP, SYN, or FIN probes and listen for TIME_EXCEEDED messages, TCP RESET, and other messages from firewalls and gateways along the path. 🫶

BUT (and this is the tea ☕) some firewalls filter out TCP SYN packets to prevent denial-of-service attacks. so whether TCP beats UDP traceroute really depends on how the firewalls are configured, and you can't know that ahead of time. 🙃 A detailed analysis of TCP-based traceroute tools and measurements is outside the scope of this document. still, for completeness, the information model also supports storing TCP-based traceroute measurements. ✨

Appendix B. Known Problems with Traceroute 🔥

B.1. Compatibility between Traceroute Measurement Results and IPPM Metrics 💅

so this one is giving "known issue, no fix in sight" 😭. because of implementation choices, there's an inconsistency between the round-trip delay metric the IPPM working group defined in RFC 2681 and the results returned by current traceroute tool implementations. and it's unlikely the traceroute tools will implement the standard definition anytime soon. 💀

so the only real option is to compare results from different traceroute measurements with each other. to make that possible, the operating system (name and version) and the traceroute tool version were added to the metadata elements. that way you can compare metrics between two measurement results, as long as they were run on the same operating system and the same tool version. 🧚

and there's more 😩. the traceroute tool has built-in configurable mechanisms like timeouts, and it can run into trouble when crossing firewalls. so some of the packets traceroute sends out end up timing out or getting filtered. as a result, it might not be possible to trace the path to a node, or there might not be a complete enough set of probes to describe the RTT to reach it. 🙈

Appendix C. Differences to DISMAN-TRACEROUTE-MIB 🎀

okay so for remote traceroute operations at a managed node, the IETF has standardized the DISMAN-TRACEROUTE-MIB module in [RFC4560]. 🌸 this module lets you:

  • retrieve capability information about the traceroute tool implementation at the managed node;
  • configure traceroute measurements to be performed;
  • retrieve information about ongoing and completed traceroute measurements;
  • retrieve traceroute measurement statistics.

the traceroute storage format in this document overlaps a lot with this MIB module 👯‍♀️. especially, the models for traceroute measurement configuration and for results from completed measurements are almost identical. but the other parts of the DISMAN-TRACEROUTE MIB module don't need to be modeled in a traceroute measurement storage format. the capability information, info about ongoing measurements, and measurement statistics are not covered by the DISMAN traceroute storage model. 🙅‍♀️

there are structural differences too, caused by different choices of encoding. the DISMAN-TRACEROUTE-MIB uses the Structure of Management Information (SMIv2, STD 58, RFC 2578 [RFC2578]), while the IPPM traceroute measurement data model is encoded using XML. 🍓

this difference in structure means the DISMAN-TRACEROUTE-MIB module has SMI-specific information elements (managed objects) that deal with tables of managed objects (specification, entry creation and deletion, status retrieval). those aren't required for the XML-encoded traceroute measurement data model. 🧠

but for most of the remaining elements about configuring traceroute measurements and results of completed measurements, the semantics are identical between the DISMAN-TRACEROUTE-MIB module and the traceroute measurement data model. there are very few exceptions, which are listed below. naming is also identical between both models, with a few exceptions. the traceroute measurement data model adds a few information elements, some because of the different structure and some to give extra info on completed measurements. ✨

C.1. Scope 🔭

MIB modules and XML documents are basically different in nature and application. this leads to two major differences in scope between the DISMAN-TRACEROUTE-MIB module and the traceroute measurement data model. 💜

the first difference is the "traceRouteResultsTable" in the DISMAN-TRACEROUTE-MIB module. this table allows online observation of the status and progress of an ongoing traceroute measurement. that highly dynamic info isn't in the traceroute measurement data model, because the model was never meant to report the progress of individual measurements as they happen. it's really meant for reporting completed traceroute measurements. 🏁

the second difference is that info in a MIB is usually tied to the local node hosting the MIB instance. the "RequestMetadata" element in the traceroute measurement data model can be used to specify a measurement request that may be applied to several probes in a network. that concept doesn't exist in the DISMAN-TRACEROUTE-MIB module. 🌐

for the remaining elements in both the DISMAN-TRACEROUTE-MIB module and the traceroute measurement data model, the two line up really well. the "traceRouteCtlTable" corresponds to the "MeasurementMetadata" element, and the combo of the "traceRouteProbeHistoryTable" and the "traceRouteHopsTable" corresponds to a collection of "MeasurementResult" elements. 🫶

C.2. Naming 🏷️

basically, both models pick names using the same naming conventions. 💅

for the traceroute measurement configuration info, all names, like "CtlProbesPerHop", are identical in both models. the exceptions are that the traceRoute prefix was dropped to avoid unnecessary redundancy in the XML file, and "CtlDataSize" was renamed to "CtlProbeDataSize" for clarity in the traceroute measurement data model. ✨

results of measurements in the DISMAN-TRACEROUTE-MIB module are split across two tables. the "traceRouteResultsTable" mostly holds info about ongoing measurements, and the "traceRouteProbeHistoryTable" only holds info about completed measurements. because of SMIv2 naming conventions, the element names in these tables have different prefixes ("traceRouteResults" and "traceRouteProbeHistory"). since the traceroute measurement data model only reports completed measurements, that split isn't needed anymore, so the prefix "Results" is used for all related info elements. 🌈

beyond that, only a few element names changed. the renames are:

  • "traceRouteProbeHistoryResponse" to "ProbeRoundTripTime";
  • "traceRouteProbeHistoryHAddr" to "HopAddr";
  • "traceRouteProbeHistoryTime" to "ResultsEndDateAndTime";
  • "traceRouteProbeHistoryLastRC" to "ResultsHopRawOutputData".

C.3. Semantics 🧐

only two information elements had their semantics changed. this is the part where things get a little spicy 🌶️.

for "traceRouteProbeHistoryResponse" in the DISMAN-TRACEROUTE-MIB, a value of 0 means it's not possible to transmit a probe. in the traceroute measurement data model, a value of 0 for the element "RoundTripTime" means the measured time was less than one millisecond. for the case where a probe couldn't be transmitted, a string is used to indicate the problem instead. 😮

for "traceRouteCtlIfIndex" in the DISMAN-TRACEROUTE-MIB, a value of 0 means the option to set the index isn't available. this was translated into the traceroute measurement data model so that a value of 0 for this element means the interface used is unknown. 🤷‍♀️

the element "traceRouteProbeHistoryLastRC" in the DISMAN-TRACEROUTE-MIB was replaced by the element "ResultsHopRawOutputData". "traceRouteProbeHistoryLastRC" just reports a reply code, but "ResultsHopRawOutputData" reports the full raw output data (per hop) produced by the traceroute measurement that was used. 🧾

C.4. Additional Information Elements ➕

only a few information elements were added to the model compared to the DISMAN-TRACEROUTE-MIB module. 🎁

  • for providing info on the MPLS label stack entries of a probe in the traceroute measurement path, "MPLSLabelStackEntry" was added;
  • for providing additional timestamps beyond "ResultsEndDateAndTime", "ResultsStartDateAndTime" and "Time" were added;
  • for providing DNS names at the time the traceroute was executed for each "HopAddr" (which may change over time), "HopName" was added.

Appendix D. Traceroute Examples with XML Representation 🧚‍♀️

okay bestie, this section shows some examples of traceroute applications 🌷. it also shows how requests and results are encoded for some of those examples. and heads up: in these XML examples, some lines look wrapped because of the limited line length 📏. don't panic, it's just formatting 🫶.

Okay bestie, so here's what a typical traceroute looks like on a LINUX system 💻✨

# traceroute  -f 4 www.example 1500
traceroute to ww.example (192.0.2.42), 30 hops max, 1500-byte packets
 5  out.host1.example (192.0.2.254)  6.066 ms   5.625 ms   6.095 ms
 6  rtr4.host6.example (192.0.2.142)  6.979 ms   6.221 ms   7.368 ms
 7  hop7.rtr9.example (192.0.2.11)  16.165 ms   15.347 ms   15.514 ms
 8  192.0.2.222 (192.0.2.222)  32.796 ms   28.723 ms   26.988 ms
 9  in.example (192.0.2.123)  15.861 ms   16.262 ms   17.610 ms
10  in.example (192.0.2.123)(N!)  17.391 ms * *

Obsessed with how clean this is 😭🎀. This traceroute skips the first 4 hops and sends 1500-byte packets, header included 📦. It never actually reaches its goal, because the last listed hop says the network is not reachable (N!) 💀.

Here's how the same trace looks encoded in XML, no cap it's giving main character energy 👑🦋:

<?xml version="1.0" encoding="UTF-8"?>
<traceRoute xmlns="urn:ietf:params:xml:ns:traceroute-1.0">
  <RequestMetadata>
    <TestName>Example 1</TestName>
    <OSName/>
    <OSVersion/>
    <ToolVersion/>
    <ToolName/>
    <CtlTargetAddress>
      <inetAddressDns>www.example</inetAddressDns>
    </CtlTargetAddress>
    <CtlBypassRouteTable/>
    <CtlProbeDataSize>1472</CtlProbeDataSize>
    <CtlTimeOut/>
    <CtlProbesPerHop/>
    <CtlPort/>
    <CtlMaxTtl/>
    <CtlDSField/>
    <CtlSourceAddress>
      <inetAddressUnknown/>
    </CtlSourceAddress>
    <CtlIfIndex/>
    <CtlMiscOptions/>
    <CtlMaxFailures/>
    <CtlDontFragment/>
    <CtlInitialTtl>4</CtlInitialTtl>
    <CtlDescr>Show how it encodes in XML</CtlDescr>
    <CtlType><UDP/></CtlType>
  </RequestMetadata>
  <Measurement>
    <MeasurementMetadata>
      <TestName>Example 1</TestName>
      <OSName>Linux</OSName>
      <OSVersion>2.6.16.54-0.2.5-smp i386</OSVersion>
      <ToolVersion>1.0</ToolVersion>
      <ToolName>traceroute</ToolName>
      <CtlTargetAddress>
        <inetAddressDns>www.example</inetAddressDns>
      </CtlTargetAddress>
      <CtlBypassRouteTable/>
      <CtlProbeDataSize>1472</CtlProbeDataSize>
      <CtlTimeOut/>
      <CtlProbesPerHop/>
      <CtlPort/>
      <CtlMaxTtl/>
      <CtlDSField/>
      <CtlSourceAddress>
        <inetAddressIpv4>192.0.2.1</inetAddressIpv4>
      </CtlSourceAddress>
      <CtlIfIndex>2</CtlIfIndex>
      <CtlMiscOptions/>
      <CtlMaxFailures/>
      <CtlDontFragment/>
      <CtlInitialTtl>4</CtlInitialTtl>
      <CtlDescr>Show how it encodes in XML</CtlDescr>
      <CtlType><UDP/></CtlType>
    </MeasurementMetadata>
    <MeasurementResult>
      <TestName>Example 1</TestName>
      <ResultsStartDateAndTime>2008-05-16T14:22:34+02:00</ResultsStar
tDateAndTime>
      <ResultsIpTgtAddr>
        <inetAddressIpv4>192.0.2.42</inetAddressIpv4>
      </ResultsIpTgtAddr>
      <ProbeResults>
        <hop>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.254</inetAddressIpv4>
            </HopAddr>
            <HopName>out.host1.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>6</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-16T14:22:35+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.254</inetAddressIpv4>
            </HopAddr>
            <HopName>out.host1.example</HopName>
            <ProbeRoundTripTime><roundTripTime>5</roundTripTime></Pro
beRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-16T14:22:35+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.254</inetAddressIpv4>
            </HopAddr>
            <HopName>out.host1.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>6</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-16T14:22:35+02:00</Time>
          </probe>
          <HopRawOutputData> 5  out.host1.example (192.0.2.254)  6.06
6 ms   5.625 ms   6.095 ms</HopRawOutputData>
        </hop>
        <hop>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.142</inetAddressIpv4>
            </HopAddr>
            <HopName>rtr4.host6.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>6</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-16T14:22:36+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.142</inetAddressIpv4>
            </HopAddr>
            <HopName>rtr4.host6.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>6</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-16T14:22:36+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.142</inetAddressIpv4>
            </HopAddr>
            <HopName>rtr4.host6.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>7</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-16T14:22:37+02:00</Time>
          </probe>
          <HopRawOutputData> 6  rtr4.host6.example (192.0.2.142)  6.9
79 ms   6.221 ms   7.368 ms</HopRawOutputData>
        </hop>
        <hop>
          <probe>

            <HopAddr>
              <inetAddressIpv4>192.0.2.11</inetAddressIpv4>
            </HopAddr>
            <HopName>hop7.rtr9.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>16</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-16T14:22:37+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.11</inetAddressIpv4>
            </HopAddr>
            <HopName>hop7.rtr9.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>15</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-16T14:22:38+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.11</inetAddressIpv4>
            </HopAddr>
            <HopName>hop7.rtr9.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>15</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-16T14:22:38+02:00</Time>
          </probe>
          <HopRawOutputData> 7  hop7.rtr9.example (192.0.2.11)  16.16
5 ms   15.347 ms   15.514 ms</HopRawOutputData>
        </hop>
        <hop>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.222</inetAddressIpv4>
            </HopAddr>
            <ProbeRoundTripTime>
              <roundTripTime>32</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-16T14:22:39+02:00</Time>
          </probe>
          <probe>
            <HopAddr>

              <inetAddressIpv4>192.0.2.222</inetAddressIpv4>
            </HopAddr>
            <ProbeRoundTripTime>
              <roundTripTime>38</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-16T14:22:39+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.222</inetAddressIpv4>
            </HopAddr>
            <ProbeRoundTripTime>
              <roundTripTime>26</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-16T14:22:39+02:00</Time>
          </probe>
          <HopRawOutputData> 8  192.0.2.222 (192.0.2.222)  32.796 ms
   28.723 ms   26.988 ms</HopRawOutputData>
        </hop>
        <hop>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.123</inetAddressIpv4>
            </HopAddr>
            <HopName>in.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>15</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-16T14:22:40+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.123</inetAddressIpv4>
            </HopAddr>
            <HopName>in.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>16</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-16T14:22:40+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.123</inetAddressIpv4>
            </HopAddr>
            <HopName>in.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>17</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-16T14:22:40+02:00</Time>
          </probe>
          <HopRawOutputData> 9  in.example (192.0.2.123)  15.861 ms
  16.262 ms   17.610 ms</HopRawOutputData>
        </hop>
        <hop>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.123</inetAddressIpv4>
            </HopAddr>
            <HopName>in.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>17</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>noRouteToTarget</ResponseStatus>
            <Time>2008-05-16T14:22:41+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.123</inetAddressIpv4>
            </HopAddr>
            <HopName>in.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTimeNotAvailable/>
            </ProbeRoundTripTime>
            <ResponseStatus>requestTimedOut</ResponseStatus>
            <Time>2008-05-16T14:22:44+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.123</inetAddressIpv4>
            </HopAddr>
            <HopName>in.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTimeNotAvailable/>
            </ProbeRoundTripTime>
            <ResponseStatus>requestTimedOut</ResponseStatus>
            <Time>2008-05-16T14:22:44+02:00</Time>
          </probe>
          <HopRawOutputData>10  in.example (192.0.2.123)(N!)  17.391
ms * *</HopRawOutputData>
        </hop>
      </ProbeResults>
      <ResultsEndDateAndTime>2008-05-16T14:22:44+02:00</ResultsEndDat
eAndTime>
    </MeasurementResult>
  </Measurement>
</traceRoute>

Okay bestie, the second example was run on an OpenBSD box 💻🎀 Here's what the traceroute looks like there:

# traceroute -P tcp w2.example 128

traceroute to w2.example (192.0.2.254), 64 hops max, 160-byte packets
 1  router1.example.org (192.0.2.22)  0.486 ms  0.486 ms  0.482 ms
 2  router7.example.org (192.0.2.1)  3.27 ms  1.420 ms  1.873 ms
 3  hop0.c.example (192.0.2.105)  3.177 ms  3.258 ms  3.859 ms
 4  hop6.c.example (192.0.2.107)  5.994 ms  4.607 ms  5.678 ms
 5  hop3.c.example (192.0.2.111)  20.341 ms  20.732 ms  19.505 ms
 6  in.example.net (192.0.2.222)  20.333 ms  19.174 ms  19.856 ms
 7  egress.example.net (192.0.2.227)  20.268 ms  21.79 ms  19.992 ms
 8  routerin.example (192.0.2.253)  19.983 ms  19.931 ms  19.894 ms
 9  routerdmz.example (192.0.2.249)  20.943 ms !X *  19.829 ms !X

This one used the TCP protocol and 128-byte packets (plus header) 🌸 The traceroute stopped at hop 9 because the packets got administratively filtered, which is why you see the !X marks 🙈 Lowkey iconic output, ngl 💅

Here's the XML version of that same run, showing how it encodes 🦋

<?xml version="1.0" encoding="UTF-8"?>
<traceRoute xmlns="urn:ietf:params:xml:ns:traceroute-1.0">
  <RequestMetadata>
    <TestName>Example 2</TestName>
    <OSName/>
    <OSVersion/>
    <ToolVersion/>
    <ToolName/>
    <CtlTargetAddress>
      <inetAddressDns>w2.example</inetAddressDns>
    </CtlTargetAddress>
    <CtlBypassRouteTable/>
    <CtlProbeDataSize>128</CtlProbeDataSize>
    <CtlTimeOut/>
    <CtlProbesPerHop/>
    <CtlPort/>
    <CtlMaxTtl/>
    <CtlDSField/>
    <CtlSourceAddress>
      <inetAddressUnknown/>
    </CtlSourceAddress>
    <CtlIfIndex/>
    <CtlMiscOptions/>
    <CtlMaxFailures/>
    <CtlDontFragment/>
    <CtlInitialTtl/>
    <CtlDescr>Show how it encodes in XML</CtlDescr>
    <CtlType><TCP/></CtlType>
  </RequestMetadata>
  <Measurement>
    <MeasurementMetadata>
      <TestName>Example 2</TestName>
      <OSName>OpenBSD</OSName>
      <OSVersion>4.1 i386</OSVersion>
      <ToolVersion></ToolVersion>
      <ToolName>traceroute</ToolName>
      <CtlTargetAddress>
        <inetAddressDns>w2.example</inetAddressDns>
      </CtlTargetAddress>
      <CtlBypassRouteTable/>
      <CtlProbeDataSize>128</CtlProbeDataSize>
      <CtlTimeOut/>
      <CtlProbesPerHop/>
      <CtlPort/>
      <CtlMaxTtl/>
      <CtlDSField/>
      <CtlSourceAddress>
        <inetAddressIpv4>192.0.2.42</inetAddressIpv4>
      </CtlSourceAddress>
      <CtlIfIndex>1</CtlIfIndex>
      <CtlMiscOptions/>
      <CtlMaxFailures/>
      <CtlDontFragment/>
      <CtlInitialTtl/>
      <CtlDescr>Show how it encodes in XML</CtlDescr>
      <CtlType><TCP/></CtlType>
    </MeasurementMetadata>
    <MeasurementResult>
      <TestName>Example 2</TestName>
      <ResultsStartDateAndTime>2008-05-14T09:57:11+02:00</ResultsStar
tDateAndTime>
      <ResultsIpTgtAddr>
        <inetAddressIpv4>192.0.2.254</inetAddressIpv4>
      </ResultsIpTgtAddr>
      <ProbeResults>
        <hop>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.22</inetAddressIpv4>
            </HopAddr>
            <HopName>router1.example.org</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>0</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T09:57:13+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.22</inetAddressIpv4>
            </HopAddr>
            <HopName>router1.example.org</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>0</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T09:57:13+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.22</inetAddressIpv4>
            </HopAddr>
            <HopName>router1.example.org</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>0</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T09:57:13+02:00</Time>
          </probe>
        </hop>
        <hop>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.1</inetAddressIpv4>
            </HopAddr>
            <HopName>router7.example.org</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>3</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T09:57:13+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.1</inetAddressIpv4>
            </HopAddr>
            <HopName>router7.example.org</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>1</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:13+02:00</Time>
             </probe>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.1</inetAddressIpv4>
               </HopAddr>
               <HopName>router7.example.org</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>1</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:14+02:00</Time>
             </probe>
           </hop>
           <hop>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.105</inetAddressIpv4>
               </HopAddr>
               <HopName>hop0.c.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>3</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:14+02:00</Time>
             </probe>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.105</inetAddressIpv4>
               </HopAddr>
               <HopName>hop0.c.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>3</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:14+02:00</Time>
             </probe>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.105</inetAddressIpv4>
               </HopAddr>
               <HopName>hop0.c.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>3</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:14+02:00</Time>
             </probe>
           </hop>
           <hop>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.107</inetAddressIpv4>
               </HopAddr>
               <HopName>hop6.c.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>5</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:15+02:00</Time>
             </probe>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.107</inetAddressIpv4>
               </HopAddr>
               <HopName>hop6.c.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>4</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:16+02:00</Time>
             </probe>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.107</inetAddressIpv4>
               </HopAddr>
               <HopName>hop6.c.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>5</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:16+02:00</Time>
             </probe>
           </hop>
           <hop>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.111</inetAddressIpv4>
               </HopAddr>
               <HopName>hop3.c.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>20</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:17+02:00</Time>
             </probe>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.111</inetAddressIpv4>
               </HopAddr>
               <HopName>hop3.c.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>20</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:18+02:00</Time>
             </probe>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.111</inetAddressIpv4>
               </HopAddr>
               <HopName>hop3.c.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>19</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:19+02:00</Time>
             </probe>
           </hop>
           <hop>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.222</inetAddressIpv4>
               </HopAddr>
               <HopName>in.example.net</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>20</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:20+02:00</Time>
             </probe>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.222</inetAddressIpv4>
               </HopAddr>
               <HopName>in.example.net</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>19</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:20+02:00</Time>
             </probe>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.222</inetAddressIpv4>
               </HopAddr>
               <HopName>in.example.net</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>19</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:21+02:00</Time>
             </probe>
           </hop>
           <hop>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.227</inetAddressIpv4>
               </HopAddr>
               <HopName>egress.example.net</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>20</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:22+02:00</Time>
             </probe>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.227</inetAddressIpv4>
               </HopAddr>
               <HopName>egress.example.net</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>21</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:22+02:00</Time>
             </probe>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.227</inetAddressIpv4>
               </HopAddr>
               <HopName>egress.example.net</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>19</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:23+02:00</Time>
             </probe>
           </hop>
           <hop>

             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.253</inetAddressIpv4>
               </HopAddr>
               <HopName>routerin.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>19</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:24+02:00</Time>
             </probe>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.253</inetAddressIpv4>
               </HopAddr>
               <HopName>routerin.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>19</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:24+02:00</Time>
             </probe>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.253</inetAddressIpv4>
               </HopAddr>
               <HopName>routerin.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>19</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:25+02:00</Time>
             </probe>
           </hop>
           <hop>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.249</inetAddressIpv4>
               </HopAddr>
               <HopName>routerdmz.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>20</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>unknown</ResponseStatus>
               <Time>2008-05-14T09:57:26+02:00</Time>
             </probe>
             <probe>
               <HopAddr>

                 <inetAddressIpv4>192.0.2.249</inetAddressIpv4>
               </HopAddr>
               <HopName>routerdmz.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTimeNotAvailable/>
               </ProbeRoundTripTime>
               <ResponseStatus>requestTimedOut</ResponseStatus>
               <Time>2008-05-14T09:57:26+02:00</Time>
             </probe>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.249</inetAddressIpv4>
               </HopAddr>
               <HopName>routerdmz.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>19</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>unknown</ResponseStatus>
               <Time>2008-05-14T09:57:30+02:00</Time>
             </probe>
           </hop>
         </ProbeResults>
         <ResultsEndDateAndTime>2008-05-14T09:57:30+02:00</ResultsEndDat
   eAndTime>
       </MeasurementResult>
     </Measurement>
   </traceRoute>

Okay so for the third and last example we're going over the Microsoft Windows version of traceroute 💻🎀. On a Windows machine the command is called "tracert", and it usually gets typed in like this:

# tracert -h 10 www.example.org

And the output looks something like this 👀✨:

Tracing route to www.example.org [192.0.2.11]
over a maximum of 10 hops:

  1     1 ms     1 ms     8 ms  192.0.2.99
  2    <1 ms    <1 ms    <1 ms  r1.provider4.example [192.0.2.102]
  3    <1 ms    <1 ms    <1 ms  rtr8.provider8.example [192.0.2.254]
  4     1 ms     1 ms     1 ms  hop11.hoster7.example [192.0.2.4]
  5     2 ms     3 ms     1 ms  sw6.provider2.example [192.0.2.201]
  6     3 ms     3 ms     3 ms  out.provider2.example [192.0.2.111]
  7     *        6 ms     5 ms  192.0.2.123
  8     5 ms     5 ms     5 ms  192.0.2.42
  9    94 ms    95 ms    95 ms  ingress.example.org [192.0.2.199]
 10   168 ms   169 ms   169 ms  192.0.2.44

Trace complete.

Okay so in this example the trace was capped at 10 hops, which means hop 10 wasn't the final destination yet 🧚 Now let's see how the XML schema from this document would actually encode it 💅

<?xml version="1.0" encoding="UTF-8"?>
<traceRoute xmlns="urn:ietf:params:xml:ns:traceroute-1.0">
  <RequestMetadata>
    <TestName>Example 3</TestName>
    <OSName/>
    <OSVersion/>
    <ToolVersion/>
    <ToolName/>
    <CtlTargetAddress>
      <inetAddressDns>www.example.org</inetAddressDns>
    </CtlTargetAddress>
    <CtlBypassRouteTable/>
    <CtlProbeDataSize/>
    <CtlTimeOut/>
    <CtlProbesPerHop/>
    <CtlPort/>
    <CtlMaxTtl>10</CtlMaxTtl>
    <CtlDSField/>
    <CtlSourceAddress>
      <inetAddressUnknown/>
    </CtlSourceAddress>
    <CtlIfIndex/>
    <CtlMiscOptions/>
    <CtlMaxFailures/>
    <CtlDontFragment/>
    <CtlInitialTtl/>
    <CtlDescr>Show how it encodes in XML</CtlDescr>
    <CtlType><TCP/></CtlType>
  </RequestMetadata>
  <Measurement>
    <MeasurementMetadata>
      <TestName>Example 3</TestName>
      <OSName>Windows</OSName>
      <OSVersion>XP SP2 32-bit</OSVersion>
      <ToolVersion></ToolVersion>
      <ToolName>tracert</ToolName>
      <CtlTargetAddress>
        <inetAddressDns>www.example.org</inetAddressDns>
      </CtlTargetAddress>
      <CtlBypassRouteTable/>
      <CtlProbeDataSize/>
      <CtlTimeOut/>
      <CtlProbesPerHop/>
      <CtlPort/>
      <CtlMaxTtl>10</CtlMaxTtl>
      <CtlDSField/>
      <CtlSourceAddress>
        <inetAddressIpv4>192.0.2.142</inetAddressIpv4>
      </CtlSourceAddress>
      <CtlIfIndex>3</CtlIfIndex>
      <CtlMiscOptions/>
      <CtlMaxFailures/>
      <CtlDontFragment/>
      <CtlInitialTtl/>
      <CtlDescr>Show how it encodes in XML</CtlDescr>
      <CtlType><TCP/></CtlType>
    </MeasurementMetadata>
    <MeasurementResult>
      <TestName>Example 3</TestName>
      <ResultsStartDateAndTime>2008-05-14T11:03:09+02:00</ResultsStar
tDateAndTime>
      <ResultsIpTgtAddr>
        <inetAddressIpv4>192.0.2.11</inetAddressIpv4>
      </ResultsIpTgtAddr>
      <ProbeResults>
        <hop>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.99</inetAddressIpv4>
            </HopAddr>
            <ProbeRoundTripTime>
              <roundTripTime>1</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T11:03:09+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.99</inetAddressIpv4>
            </HopAddr>
            <ProbeRoundTripTime>
              <roundTripTime>1</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T11:03:09+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.99</inetAddressIpv4>
            </HopAddr>
            <ProbeRoundTripTime>

              <roundTripTime>8</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T11:03:09+02:00</Time>
          </probe>
        </hop>
        <hop>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.102</inetAddressIpv4>
            </HopAddr>
            <HopName>r1.provider4.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>0</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T11:03:09+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.102</inetAddressIpv4>
            </HopAddr>
            <HopName>r1.provider4.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>0</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T11:03:09+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.102</inetAddressIpv4>
            </HopAddr>
            <HopName>r1.provider4.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>0</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T11:03:09+02:00</Time>
          </probe>
        </hop>
        <hop>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.254</inetAddressIpv4>
            </HopAddr>
            <HopName>rtr8.provider8.example</HopName>
            <ProbeRoundTripTime>

              <roundTripTime>0</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T11:03:09+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.254</inetAddressIpv4>
            </HopAddr>
            <HopName>rtr8.provider8.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>0</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T11:03:09+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.254</inetAddressIpv4>
            </HopAddr>
            <HopName>rtr8.provider8.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>0</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T11:03:09+02:00</Time>
          </probe>
        </hop>
        <hop>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.4</inetAddressIpv4>
            </HopAddr>
            <HopName>hop11.hoster7.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>1</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T11:03:09+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.4</inetAddressIpv4>
            </HopAddr>
            <HopName>hop11.hoster7.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>1</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T11:03:10+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.4</inetAddressIpv4>
            </HopAddr>
            <HopName>hop11.hoster7.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>1</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T11:03:10+02:00</Time>
          </probe>
        </hop>
        <hop>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.201</inetAddressIpv4>
            </HopAddr>
            <HopName>sw6.provider2.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>2</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T11:03:10+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.201</inetAddressIpv4>
            </HopAddr>
            <HopName>sw6.provider2.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>3</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T11:03:11+02:00</Time>
          </probe>
          <probe>
            <HopAddr>
              <inetAddressIpv4>192.0.2.201</inetAddressIpv4>
            </HopAddr>
            <HopName>sw6.provider2.example</HopName>
            <ProbeRoundTripTime>
              <roundTripTime>1</roundTripTime>
            </ProbeRoundTripTime>
            <ResponseStatus>responseReceived</ResponseStatus>
            <Time>2008-05-14T11:03:11+02:00</Time>

</probe> </hop> <hop> <probe> <HopAddr> <inetAddressIpv4>192.0.2.111</inetAddressIpv4> </HopAddr> <HopName>out.provider2.example</HopName> <ProbeRoundTripTime> <roundTripTime>3</roundTripTime> </ProbeRoundTripTime> <ResponseStatus>responseReceived</ResponseStatus> <Time>2008-05-14T11:03:11+02:00</Time> </probe> <probe> <HopAddr> <inetAddressIpv4>192.0.2.111</inetAddressIpv4> </HopAddr> <HopName>out.provider2.example</HopName> <ProbeRoundTripTime> <roundTripTime>3</roundTripTime> </ProbeRoundTripTime> <ResponseStatus>responseReceived</ResponseStatus> <Time>2008-05-14T11:03:11+02:00</Time> </probe> <probe> <HopAddr> <inetAddressIpv4>192.0.2.111</inetAddressIpv4> </HopAddr> <HopName>out.provider2.example</HopName> <ProbeRoundTripTime> <roundTripTime>3</roundTripTime> </ProbeRoundTripTime> <ResponseStatus>responseReceived</ResponseStatus> <Time>2008-05-14T11:03:12+02:00</Time> </probe> </hop> <hop> <probe> <HopAddr> <inetAddressIpv4>192.0.2.123</inetAddressIpv4> </HopAddr> <ProbeRoundTripTime> <roundTripTimeNotAvailable/> </ProbeRoundTripTime> <ResponseStatus>requestTimedOut</ResponseStatus> <Time>2008-05-14T11:03:14+02:00</Time> </probe> <probe> <HopAddr> <inetAddressIpv4>192.0.2.123</inetAddressIpv4> </HopAddr> <ProbeRoundTripTime> <roundTripTime>6</roundTripTime> </ProbeRoundTripTime> <ResponseStatus>responseReceived</ResponseStatus> <Time>2008-05-14T11:03:15+02:00</Time> </probe> <probe> <HopAddr> <inetAddressIpv4>192.0.2.123</inetAddressIpv4> </HopAddr> <ProbeRoundTripTime> <roundTripTime>5</roundTripTime> </ProbeRoundTripTime> <ResponseStatus>responseReceived</ResponseStatus> <Time>2008-05-14T11:03:16+02:00</Time> </probe> </hop> <hop> <probe> <HopAddr> <inetAddressIpv4>192.0.2.42</inetAddressIpv4> </HopAddr> <ProbeRoundTripTime> <roundTripTime>5</roundTripTime> </ProbeRoundTripTime> <ResponseStatus>responseReceived</ResponseStatus> <Time>2008-05-14T11:03:17+02:00</Time> </probe> <probe> <HopAddr> <inetAddressIpv4>192.0.2.42</inetAddressIpv4> </HopAddr> <ProbeRoundTripTime> <roundTripTime>5</roundTripTime> </ProbeRoundTripTime> <ResponseStatus>responseReceived</ResponseStatus> <Time>2008-05-14T11:03:17+02:00</Time> </probe> <probe> <HopAddr> <inetAddressIpv4>192.0.2.42</inetAddressIpv4> </HopAddr> <ProbeRoundTripTime> <roundTripTime>5</roundTripTime>

</ProbeRoundTripTime> <ResponseStatus>responseReceived</ResponseStatus> <Time>2008-05-14T11:03:17+02:00</Time> </probe> </hop> <hop> <probe> <HopAddr> <inetAddressIpv4>192.0.2.199</inetAddressIpv4> </HopAddr> <HopName>ingress.example.org</HopName> <ProbeRoundTripTime> <roundTripTime>94</roundTripTime> </ProbeRoundTripTime> <ResponseStatus>responseReceived</ResponseStatus> <Time>2008-05-14T11:03:19+02:00</Time> </probe> <probe> <HopAddr> <inetAddressIpv4>192.0.2.199</inetAddressIpv4> </HopAddr> <HopName>ingress.example.org</HopName> <ProbeRoundTripTime> <roundTripTime>95</roundTripTime> </ProbeRoundTripTime> <ResponseStatus>responseReceived</ResponseStatus> <Time>2008-05-14T11:03:19+02:00</Time> </probe> <probe> <HopAddr> <inetAddressIpv4>192.0.2.199</inetAddressIpv4> </HopAddr> <HopName>ingress.example.org</HopName> <ProbeRoundTripTime> <roundTripTime>95</roundTripTime> </ProbeRoundTripTime> <ResponseStatus>responseReceived</ResponseStatus> <Time>2008-05-14T11:03:19+02:00</Time> </probe> </hop> <hop> <probe> <HopAddr> <inetAddressIpv4>192.0.2.44</inetAddressIpv4> </HopAddr> <ProbeRoundTripTime> <roundTripTime>168</roundTripTime> </ProbeRoundTripTime> <ResponseStatus>responseReceived</ResponseStatus> <Time>2008-05-14T11:03:20+02:00</Time> </probe> <probe> <HopAddr> <inetAddressIpv4>192.0.2.44</inetAddressIpv4> </HopAddr> <ProbeRoundTripTime> <roundTripTime>169</roundTripTime> </ProbeRoundTripTime> <ResponseStatus>responseReceived</ResponseStatus> <Time>2008-05-14T11:03:21+02:00</Time> </probe> <probe> <HopAddr> <inetAddressIpv4>192.0.2.44</inetAddressIpv4> </HopAddr> <ProbeRoundTripTime> <roundTripTime>169</roundTripTime> </ProbeRoundTripTime> <ResponseStatus>responseReceived</ResponseStatus> <Time>2008-05-14T11:03:23+02:00</Time> </probe> </hop> </ProbeResults> <ResultsEndDateAndTime>2008-05-14T11:03:23+02:00</ResultsEndDat eAndTime> </MeasurementResult> </Measurement> </traceRoute>

okay so that's the last of the three examples, bestie 🎀 and i know that's a LOT of XML to scroll through, but the whole point is just to give you a vibe for what a trace looks like once it's been turned into XML 💅 the way every hop has its probes lined up, each with its own address, round trip time and status, is honestly so satisfying 😭 and the thing to remember is that the output your implementation makes might look different from these, because it depends on the system and what the traceroute tool can actually do 🦋

Authors' Addresses ✨

The authors are the NEC Laboratories Europe crew (plus one from the University of Delaware), and here are their contact details, copied exactly as they were written 💜

Saverio Niccolini
NEC Laboratories Europe, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg  69115
Germany
Phone: +49 (0) 6221 4342 118
EMail: saverio.niccolini@nw.neclab.eu
URI:   http://www.nw.neclab.eu
Sandra Tartarelli
NEC Laboratories Europe, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg  69115
Germany
Phone: +49 (0) 6221 4342 132
EMail: sandra.tartarelli@nw.neclab.eu
URI:   http://www.nw.neclab.eu
Juergen Quittek
NEC Laboratories Europe, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg  69115
Germany
Phone: +49 (0) 6221 4342 115
EMail: quittek@nw.neclab.eu
URI:   http://www.nw.neclab.eu
Thomas Dietz
NEC Laboratories Europe, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg  69115
Germany
Phone: +49 (0) 6221 4342 128
EMail: thomas.dietz@nw.neclab.eu
URI:   http://www.nw.neclab.eu
Martin Swany
Dept. of Computer and Information Sciences
University of Delaware
Newark  DE 19716
U.S.A.
EMail: swany@UDel.Edu
📦 where this page comes from