From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5388.txt | 4203 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 4203 insertions(+) create mode 100644 doc/rfc/rfc5388.txt (limited to 'doc/rfc/rfc5388.txt') diff --git a/doc/rfc/rfc5388.txt b/doc/rfc/rfc5388.txt new file mode 100644 index 0000000..8a13c13 --- /dev/null +++ b/doc/rfc/rfc5388.txt @@ -0,0 +1,4203 @@ + + + + + + +Network Working Group S. Niccolini +Request for Comments: 5388 S. Tartarelli +Category: Standards Track J. Quittek + T. Dietz + NEC + M. Swany + UDel + December 2008 + + + Information Model and XML Data Model for Traceroute Measurements + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + 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) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + This document describes a standard way to store the configuration and + the results of traceroute measurements. This document first + describes the terminology used in this document and the traceroute + tool itself; afterwards, the common information model is defined, + dividing the information elements into two semantically separated + groups (configuration elements and results elements). Moreover, an + additional element is defined to relate configuration elements and + results elements by means of a common unique identifier. On the + basis of the information model, a data model based on XML is defined + to store the results of traceroute measurements. + + + + + + + + +Niccolini, et al. Standards Track [Page 1] + +RFC 5388 Traceroute Storage Format December 2008 + + +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 + + + + + + + + + + + + + + + +Niccolini, et al. Standards Track [Page 2] + +RFC 5388 Traceroute Storage Format December 2008 + + +1. Introduction + + Traceroutes are used by lots of measurement efforts, either as + independent measurements or as a means of getting path information to + support other measurement efforts. That is why there is the need to + standardize the way the configuration and the results of traceroute + measurements are stored. The standard metrics defined by the IPPM + group in matters of delay, connectivity, and losses do not apply to + the metrics returned by the traceroute tool. Therefore, in order to + compare results of traceroute measurements, the only possibility is + to add to the stored results a specification of the operating system + as well as the name and version for the traceroute tool used. This + document, in order to store results of traceroute measurements and + allow comparison of them, defines a standard way to store them using + an XML schema. + + The document is organized as follows: Section 2 defines the + terminology used in this document; Section 3 describes the traceroute + tool; Section 4 describes the results of a traceroute measurement as + displayed to the screen from which the traceroute tool was launched; + Section 5 and Section 6, respectively, describe the information model + and data model for storing configuration and results of the + traceroute measurements; Section 7 contains the XML schema to be used + as a template for storing and/or exchanging traceroute measurement + information; the document ends with security considerations and IANA + considerations in Section 8 and Section 9 respectively. + + 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 + + The terminology used in this document is defined as follows: + + o traceroute tool: a software tool for network diagnostic that + behaves as described in Section 3; + + o 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; + + o traceroute probe: one of many IP packets sent out by the + traceroute tool during a traceroute measurement; + + + + + +Niccolini, et al. Standards Track [Page 3] + +RFC 5388 Traceroute Storage Format December 2008 + + + o traceroute measurement configuration parameters: the configuration + parameters of a traceroute measurement; + + o traceroute measurement results: the results of a traceroute + measurement; + + o traceroute measurement information: both the results and the + configuration parameters of a traceroute measurement; + + o traceroute measurement path: a sequence of hosts transited in + order by traceroute probes during a traceroute measurement. + +3. The Traceroute Tool and Its Operations + + Traceroute is a network diagnostic tool used to determine the hop-by- + hop path from a source to a destination and the Round Trip Time (RTT) + from the source to each hop. Traceroute can be therefore used to + discover some information (hop counts, delays, etc.) about the path + between the initiator of the traceroute measurement and other hosts. + + Typically, the traceroute tool attempts to discover the path to a + destination by sending UDP probes with specific time-to-live (TTL) + values in the IP packet header and trying to elicit an ICMP + TIME_EXCEEDED response from each gateway along the path to some host. + + In more detail, a first set of probes with TTL equal to 1 is sent by + the traceroute tool from the host initiating the traceroute + measurement (some tool implementations allow setting the initial TTL + to a value equal to "n" different from 1, so that the first "n-1" + hops are skipped and the first hop that will be traced is the "n-th" + in the path). Upon receiving a probe, the first hop host decreases + the TTL value (by one or more). By observing a TTL value equal to + zero, the host rejects the probe and typically returns an ICMP + message with a TIME_EXCEEDED value. The traceroute tool can + therefore derive the IP address of the first hop from the header of + the ICMP message and evaluate the RTT between the host initiating the + traceroute measurement and the first hop. The next hops are + discovered following the same procedure, taking care to increase at + each step the TTL value of the probes by one. The TTL value is + increased until either an ICMP PORT_UNREACHABLE message is received, + meaning that the destination host has been reached, or the maximum + configured number of hops has been hit. + + Some implementations use ICMP Echoes, instead of UDP datagrams. + However, many routers do not return ICMP messages about ICMP + messages, i.e., no ICMP TIME_EXCEEDED is returned for an ICMP Echo. + + + + + +Niccolini, et al. Standards Track [Page 4] + +RFC 5388 Traceroute Storage Format December 2008 + + + Therefore, this document recommends to base implementations on UDP + datagrams. Considerations on TCP-based implementations of the + traceroute tool are reported in Appendix A.1. + +4. Results of Traceroute Measurements + + The following list reports the information fields provided as results + by all traceroute tool implementations considered. The order in + which they are reported here is not relevant and changes in different + implementations. For each hop, the following information is + reported: + + o the hop index; + + o 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; + + o the host IP address, provided that at least one of the probes + received a response; + + o the RTT for each response to a probe. + + Depending on the traceroute tool implementation, additional + information might be displayed in the output (for instance, MPLS- + related information). + + It might happen that some probes do not receive a response within the + configured timeout (for instance, if the probe is filtered out by a + firewall). In this case, an "*" is displayed in place of the RTT. + The information model reflects this using a string with the value of + "RoundTripTimeNotAvailable", meaning either the probe was lost + because of a timeout or it was not possible to transmit a probe. It + may also happen that some implementations print the same line + multiple times when a router decreases the TTL by more than one, thus + looking like multiple hops. The information model is not impacted by + this since each line is handled separately; it is left to the + applications handling the XML file how to deal with it. Moreover, + for delays below 1 ms, some implementations report 0 ms (e.g., UNIX + and LINUX), while WINDOWS reports "< 1 ms". + +5. Information Model for Traceroute Measurements + + The information model is composed of information elements; for + defining these information elements, a template is used. Such + template is specified in the list below: + + + + +Niccolini, et al. Standards Track [Page 5] + +RFC 5388 Traceroute Storage Format December 2008 + + + o name - A unique and meaningful name for the information element. + The preferred spelling for the name is to use mixed case if the + name is compound, with an initial lower-case letter, e.g., + "sourceIpAddress". + + o description - The semantics of this information element. + + o dataType - One of the types listed in Section 5.1 of this document + or in an extension of the information model. The type space for + attributes is constrained to facilitate implementation. + + o units - If the element is a measure of some kind, the units + identify what the measure is. + +5.1. Data Types + + This section describes the set of basic valid data types of the + information model. + + o string - The type "string" represents a finite-length string of + valid characters from the Unicode character encoding set. Unicode + allows for ASCII and many other international character sets to be + used. It is expected that strings will be encoded in UTF-8 + format, which is identical in encoding for US-ASCII characters but + which also accommodates other Unicode multi-byte characters. + + o string255 - Same type as "string" but with the restriction of 255 + characters. + + o inetAddressType - The type "inetAddressType" represents a type of + Internet address. The allowed values are imported from [RFC4001] + (where the intent was to import only some of the values); + additional allowed values are "asnumber" and "noSpecification". + + o inetAddress - The type "inetAddress" denotes a generic Internet + address. The allowed values are imported from [RFC4001] (the + values imported are unknown, ipv4, ipv6, and dns), while non- + global IPv4/IPv6 addresses (e.g., ipv4z and ipv6z) are excluded; + an additional allowed value is the AS number, indicated as the + actual number plus the indication of how the mapping from IP + address to AS number was performed. "Unknown" is used to indicate + an IP address that is not in one of the formats defined. + + o ipASNumberMappingType - The type "ipASNumberMappingType" + represents a type of mapping from IP to AS number, it indicates + the method that was used to do get the mapping (allowed values are + "bgptables", "routingregistries", "nslookup", "others" or + "unknown"). + + + +Niccolini, et al. Standards Track [Page 6] + +RFC 5388 Traceroute Storage Format December 2008 + + + o boolean - The type "boolean" represents a boolean value according + to XML standards [W3C.REC-xmlschema-2-20041028]. + + o unsignedInt - The type "unsignedInt" represents a value in the + range (0..4294967295). + + o unsignedShort - The type "unsignedShort" represents a value in the + range (0..65535). + + o unsignedByte - The type "unsignedByte" represents a value in the + range (0..255). + + o u8nonzero - The type "u8nonzero" represents a value in the range + (1..255). + + o probesType - The type "probesType" represents a way of indicating + the protocol used for the traceroute probes. Values defined in + this document are UDP, TCP, and ICMP. + + o operationResponseStatus - The type "operationResponseStatus" is + used to report the result of an operation. The allowed values are + imported from [RFC4560]. + + o dateTime - The type "dateTime" represents a date-time + specification according to XML standards + [W3C.REC-xmlschema-2-20041028] but is restricted to the values + defined in [RFC3339]. + +5.2. Information Elements + + This section describes the elements related to the storing of a + traceroute measurement. The elements are grouped in two groups + (configuration and results) according to their semantics. In order + to relate configuration and results elements by means of a common + unique identifier, an additional element is defined belonging to both + groups. + +5.2.1. Relationships between the Information Elements + + Every traceroute measurement is represented by an instance of the + "traceRoute" element. This class provides a standardized + representation for traceroute measurement data. The "traceroute" + element is an element that can be composed of (depending on the + nature of the traceroute measurement): + + o 1 optional "RequestMetadata" element; + + o 0..2147483647 "Measurement" elements. + + + +Niccolini, et al. Standards Track [Page 7] + +RFC 5388 Traceroute Storage Format December 2008 + + + Each "Measurement" element contains: + + o 1 optional "MeasurementMetadata" element; + + o 0..2147483647 "MeasurementResult" elements. + + The "RequestMetadata" element can be used for specifying parameters + of a traceroute measurement to be performed at one or more nodes by + one or more traceroute implementations. Depending on the + capabilities of a traceroute implementation, not all requested + parameters can be applied. Which parameters have actually been + applied for a specific traceroute measurement is specified in a + "MeasurementMetadata" element. + + The "RequestMetadata" element is a sequence that contains: + + o 1 "TestName" element; + + o 1 optional "ToolVersion" element; + + o 1 optional "ToolName" element; + + o 1 "CtlTargetAddress" element; + + o 1 optional "CtlBypassRouteTable" element; + + o 1 optional "CtlProbeDataSize" element; + + o 1 optional "CtlTimeOut" element; + + o 1 optional "CtlProbesPerHop" element; + + o 1 optional "CtlPort" element; + + o 1 optional "CtlMaxTtl" element; + + o 1 optional "CtlDSField" element; + + o 1 optional "CtlSourceAddress" element; + + o 1 optional "CtlIfIndex" element; + + o 1 optional "CtlMiscOptions" element; + + o 1 optional "CtlMaxFailures" element; + + o 1 optional "CtlDontFragment" element; + + + + +Niccolini, et al. Standards Track [Page 8] + +RFC 5388 Traceroute Storage Format December 2008 + + + o 1 optional "CtlInitialTtl" element; + + o 1 optional "CtlDescr" element; + + o 1 "CtlType" element. + + If the "RequestMetadata" element is omitted from an XML file, it + means that the traceroute measurement configuration parameters + requested were all used and the "MeasurementMetadata" element lists + them in detail. + + The "MeasurementMetadata" element is a sequence that contains: + + o 1 "TestName" element; + + o 1 "OSName" element; + + o 1 "OSVersion" element; + + o 1 "ToolVersion" element; + + o 1 "ToolName" element; + + o 1 "CtlTargetAddressType" element; + + o 1 "CtlTargetAddress" element; + + o 1 "CtlBypassRouteTable" element; + + o 1 "CtlProbeDataSize" element; + + o 1 "CtlTimeOut" element; + + o 1 "CtlProbesPerHop" element; + + o 1 "CtlPort" element; + + o 1 "CtlMaxTtl" element; + + o 1 "CtlDSField" element; + + o 1 "CtlSourceAddressType" element; + + o 1 "CtlSourceAddress" element; + + o 1 "CtlIfIndex" element; + + o 1 optional "CtlMiscOptions" element; + + + +Niccolini, et al. Standards Track [Page 9] + +RFC 5388 Traceroute Storage Format December 2008 + + + o 1 "CtlMaxFailures" element; + + o 1 "CtlDontFragment" element; + + o 1 "CtlInitialTtl" element; + + o 1 optional "CtlDescr" element; + + o 1 "CtlType" element. + + Configuration information elements can describe not just traceroute + measurements that have already happened ("MeasurementMetadata" + elements), but also the configuration to be used when requesting a + measurement to be made ("RequestMetadata" element). This is quite + different semantically, even if the individual information elements + are similar. Due to this similarity, both "RequestMetadata" and + "MeasurementMetadata" are represented by the same type in the XML + schema. All elements that are missing from the "RequestMetadata" or + marked as optional in the "RequestMetadata" but mandatory in the + "MeasurementMetadata" must be specified as empty elements. + Specifying them as empty elements means use the default value. The + "CtlType" element could have been optional in the "RequestMetadata", + but since default values cannot be specified for complex types in an + XML schema, the element is mandatory in the "RequestMetadata". + + The "MeasurementResult" element is a sequence that contains: + + o 1 "TestName" element; + + o 1 "ResultsStartDateAndTime" element; + + o 1 "ResultsIpTgtAddrType" element; + + o 1 "ResultsIpTgtAddr" element; + + o 1 "ProbeResults" elements; + + o 1 "ResultsEndDateAndTime" element. + + Additionally, it is important to say that each "ProbeResults" element + is a sequence that contains: + + o 1..255 "hop" elements. + + Each "hop" element is a sequence that contains: + + o 1..10 "probe" elements; + + + + +Niccolini, et al. Standards Track [Page 10] + +RFC 5388 Traceroute Storage Format December 2008 + + + o 1 optional "HopRawOutputData" element. + + Each "probe" element contains: + + o 1 "HopAddrType" element; + + o 1 "HopAddr" element; + + o 1 optional "HopName" element; + + o 0..255 optional "MPLSLabelStackEntry" elements; + + o 1 "ProbedRoundTripTime" element; + + o 1 "ResponseStatus" element; + + o 1 "Time" element. + + Different numbers of appearances of the three basic elements in the + XML file are meant for different scopes: + + o a file with only 1 "RequestMetadata" element represents a file + containing the traceroute measurement configuration parameters of + a traceroute measurement; it can be used to distribute the + traceroute measurement configuration parameters over multiple + nodes asked to run the same traceroute measurement; + + o a file with 1 "Measurement" element containing 1 + "MeasurementMetadata" and 1 "MeasurementResult" element represents + a file containing the traceroute measurement information of a + traceroute measurement; + + o a file with 1 "Measurement" element containing 1 + "MeasurementMetadata" and n "MeasurementResult" elements + represents a file containing the traceroute measurement + information of a set of traceroute measurements run over different + times with always the same traceroute measurement configuration + parameters; + + o a file with 1 "RequestMetadata" and 1 "Measurement" element + containing 1 "MeasurementMetadata" and 1 "Measurement" element + represents a file containing the traceroute measurement + information of a traceroute measurement (containing both the + requested traceroute measurement configuration parameters and the + ones actually used); + + o other combinations are possible to store multiple traceroute + measurements all in one XML file. + + + +Niccolini, et al. Standards Track [Page 11] + +RFC 5388 Traceroute Storage Format December 2008 + + +5.2.2. Configuration Information Elements + + This section describes the elements specific to the configuration of + the traceroute measurement (belonging to both the "RequestMetadata" + and "MeasurementMetadata" elements). + +5.2.2.1. CtlTargetAddressType + + o name - CtlTargetAddressType + + o description - Specifies the type of address in the corresponding + "CtlTargetAddress" element. This element is not directly + reflected in the XML schema of Section 7. The host address type + can be determined by examining the inetAddress type name and the + corresponding element value. + + o dataType - inetAddressType + + o units - N/A + +5.2.2.2. CtlTargetAddress + + o name - CtlTargetAddress + + o description - 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. + + o dataType - inetAddress + + o units - N/A + +5.2.2.3. CtlBypassRouteTable + + o name - CtlBypassRouteTable + + o description - 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 [IEEE.1003-1G.1997]). + + + +Niccolini, et al. Standards Track [Page 12] + +RFC 5388 Traceroute Storage Format December 2008 + + + o dataType - boolean + + o units - N/A + +5.2.2.4. CtlProbeDataSize + + o name - CtlProbeDataSize + + o description - 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). + + o dataType - unsignedShort + + o units - octets + +5.2.2.5. CtlTimeOut + + o name - CtlTimeOut + + o description - 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). + + o dataType - unsignedByte + + o units - seconds + +5.2.2.6. CtlProbesPerHop + + o name - CtlProbesPerHop + + o description - 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). + + + + +Niccolini, et al. Standards Track [Page 13] + +RFC 5388 Traceroute Storage Format December 2008 + + + o dataType - unsignedByte + + o units - probes + +5.2.2.7. CtlPort + + o name - CtlPort + + o description - Specifies the base port used by the traceroute + measurement (requested if in the "RequestMetadata" element, + actually used if in the "MeasurementMetadata" element). + + o dataType - unsignedShort + + o units - port number + +5.2.2.8. CtlMaxTtl + + o name - CtlMaxTtl + + o description - Specifies the maximum TTL value for the traceroute + measurement (requested if in the "RequestMetadata" element, + actually used if in the "MeasurementMetadata" element). + + o dataType - u8nonzero + + o units - time-to-live value + +5.2.2.9. CtlDSField + + o name - CtlDSField + + o description - 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). + + + +Niccolini, et al. Standards Track [Page 14] + +RFC 5388 Traceroute Storage Format December 2008 + + + o dataType - unsignedByte + + o units - N/A + +5.2.2.10. CtlSourceAddressType + + o name - CtlSourceAddressType + + o description - Specifies the type of address in the corresponding + "CtlSourceAddress" element. This element is not directly + reflected in the XML schema of Section 7. The host address type + can be determined by examining the "inetAddress" type name and the + corresponding element value. DNS names are not allowed for the + "CtlSourceAddress". + + o dataType - inetAddressType + + o units - N/A + +5.2.2.11. CtlSourceAddress + + o name - CtlSourceAddress + + o description - 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. + + o dataType - inetAddress + + o units - N/A + +5.2.2.12. CtlIfIndex + + o name - CtlIfIndex + + o description - 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). + + + + +Niccolini, et al. Standards Track [Page 15] + +RFC 5388 Traceroute Storage Format December 2008 + + + o dataType - unsignedInt + + o units - N/A + +5.2.2.13. CtlMiscOptions + + o name - CtlMiscOptions + + o description - Specifies implementation-dependent options + (requested if in the "RequestMetadata" element, actually used if + in the "MeasurementMetadata" element). + + o dataType - string255 + + o units - N/A + +5.2.2.14. CtlMaxFailures + + o name - CtlMaxFailures + + o description - 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. + + o dataType - Unsigned8 + + o units - timeouts + +5.2.2.15. CtlDontFragment + + o name - CtlDontFragment + + o description - 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. + + o dataType - boolean + + o units - N/A + + + + +Niccolini, et al. Standards Track [Page 16] + +RFC 5388 Traceroute Storage Format December 2008 + + +5.2.2.16. CtlInitialTtl + + o name - CtlInitialTtl + + o description - 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. + + o dataType - u8nonzero + + o units - N/A + +5.2.2.17. CtlDescr + + o name - CtlDescr + + o description - Provides a description of the traceroute + measurement. + + o dataType - string255 + + o units - N/A + +5.2.2.18. CtlType + + o name - CtlType + + o description - 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. + + o dataType - probesType + + o units - N/A + +5.2.3. Results Information Elements + + This section describes the elements specific to the results of the + traceroute measurement. + + + + + + +Niccolini, et al. Standards Track [Page 17] + +RFC 5388 Traceroute Storage Format December 2008 + + +5.2.3.1. ResultsStartDateAndTime + + o name - ResultsStartDateAndTime + + o description - Specifies the date and start time of the traceroute + measurement. This is the time when the first probe was seen at + the sending interface. + + o dataType - DateTime + + o units - N/A + +5.2.3.2. ResultsIpTgtAddrType + + o name - ResultsIpTgtAddrType + + o description - Specifies the type of address in the corresponding + "ResultsIpTgtAddr" element. This element is not directly + reflected in the XML schema of Section 7. The host address type + can be determined by examining the "inetAddress" type name and the + corresponding element value. + + o dataType - inetAddressType + + o units - N/A + +5.2.3.3. ResultsIpTgtAddr + + o name - ResultsIpTgtAddr + + o description - 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. + + o dataType - inetAddress + + o units - N/A + +5.2.3.4. HopAddrType + + o name - HopAddrType + + o description - Specifies the type of address in the corresponding + "HopAddr" element. This element is not directly reflected in the + XML schema of Section 7. The host address type can be determined + + + + +Niccolini, et al. Standards Track [Page 18] + +RFC 5388 Traceroute Storage Format December 2008 + + + by examining the "inetAddress" type name and the corresponding + element value. DNS names are not allowed for "HopAddr". + + o dataType - inetAddressType + + o units - N/A + +5.2.3.5. HopAddr + + o name - HopAddr + + o description - Specifies the address of a hop in the traceroute + measurement path. This object is not allowed to be a DNS name. + + o dataType - inetAddress + + o units - N/A + +5.2.3.6. HopName + + o name - HopName + + o description - Specifies the DNS name of the "HopAddr" if it is + available. If it is not available, the element is omitted. + + o dataType - inetAddress + + o units - N/A + +5.2.3.7. MPLSLabelStackEntry + + o name - MPLSLabelStackEntry + + o description - 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. + + o dataType - unsignedInt + + o units - N/A + + + + +Niccolini, et al. Standards Track [Page 19] + +RFC 5388 Traceroute Storage Format December 2008 + + +5.2.3.8. ProbeRoundTripTime + + o name - ProbeRoundTripTime + + o description - 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 "< 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. + + o dataType - unsignedShort or string + + o units - milliseconds or N/A + +5.2.3.9. ResponseStatus + + o name - ResponseStatus + + o description - Specifies the result of a traceroute measurement + made by the host for a particular probe. + + o dataType - operationResponseStatus + + o units - N/A + +5.2.3.10. Time + + o name - Time + + o description - Specifies the timestamp for the time the response to + the probe was received at the interface. + + o dataType - DateTime + + o units - N/A + +5.2.3.11. ResultsEndDateAndTime + + o name - ResultsEndDateAndTime + + o description - 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 + + + + +Niccolini, et al. Standards Track [Page 20] + +RFC 5388 Traceroute Storage Format December 2008 + + + the last probe of the traceroute measurement was sent plus the + relative timeout (in case of a missing response). + + o dataType - DateTime + + o units - N/A + +5.2.3.12. HopRawOutputData + + o name - HopRawOutputData + + o description - 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. + + o dataType - string + + o units - N/A + +5.2.4. Information Element Correlating Configuration and Results + Elements + + This section defines an additional element belonging to both previous + groups (configuration elements and results elements) named + "TestName". This element is defined in order to relate configuration + and results elements by means of a common unique identifier (to be + chosen in accordance to the specification of [RFC4560]). + +5.2.4.1. TestName + + o name - TestName + + o description - 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). + + o dataType - string255 + + o units - N/A + + + + + + + + + + +Niccolini, et al. Standards Track [Page 21] + +RFC 5388 Traceroute Storage Format December 2008 + + +5.2.5. Information Elements to Compare Traceroute Measurement Results + with Each Other + + This section defines additional elements belonging to both previous + groups (configuration elements and results elements); these elements + were defined in order to allow traceroute measurement results + comparison among different traceroute measurements. + +5.2.5.1. OSName + + o name - OSName + + o description - Specifies the name of the operating system on which + the traceroute measurement was launched. This element is ignored + if used in the "RequestMetadata". + + o dataType - string255 + + o units - N/A + +5.2.5.2. OSVersion + + o name - OSVersion + + o description - Specifies the OS version on which the traceroute + measurement was launched. This element is ignored if used in the + "RequestMetadata". + + o dataType - string255 + + o units - N/A + +5.2.5.3. ToolVersion + + o name - ToolVersion + + o description - Specifies the version of the traceroute tool + (requested to be used if in the "RequestMetadata" element, + actually used if in the "MeasurementMetadata" element). + + o dataType - string255 + + o units - N/A + + + + + + + + +Niccolini, et al. Standards Track [Page 22] + +RFC 5388 Traceroute Storage Format December 2008 + + +5.2.5.4. ToolName + + o name - ToolName + + o description - Specifies the name of the traceroute tool (requested + to be used if in the "RequestMetadata" element, actually used if + in the "MeasurementMetadata" element). + + o dataType - string255 + + o units - N/A + +6. Data Model for Storing Traceroute Measurements + + For storing and transmitting information according to the information + model defined in the previous section, a data model is required that + specifies how to encode the elements of the information model. + + There are several design choices for a data model. It can use a + binary or textual representation and it can be defined from scratch + or use already existing frameworks and data models. In general, the + use of already existing frameworks and models should be preferred. + + Binary and textual representations both have advantages and + disadvantages. Textual representations are (with some limitations) + human-readable, while a binary representation consumes less resources + for storing, transmitting, and parsing data. + + An already existing and closely related data model is the DISMAN- + TRACEROUTE-MIB module [RFC4560], which specifies a Structure of + Management Information version 2 (SMIv2) encoding [RFC2578], + [RFC2579], and [RFC2580] for transmitting traceroute measurement + information (configuration and results). This data model is well + suited and supported within network management systems, but as a + general format for storing and transmitting traceroute results, it is + not easily applicable. + + Another binary representation would be an extension of traffic-flow + information encodings as specified for the IP Flow Information Export + (IPFIX) protocol [RFC5101], [RFC5102]. The IPFIX protocol is + extensible. However, the architecture behind this protocol [IPFIX] + is targeted at exporting passively measured flow information. + Therefore, some obstacles are expected when trying to use it for + transmitting traceroute measurement information. + + For textual representations, using 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 + + + +Niccolini, et al. Standards Track [Page 23] + +RFC 5388 Traceroute Storage Format December 2008 + + + limitations, it is human-readable. It is supported well by a huge + pool of tools and standards for generating, transmitting, parsing, + and converting it to other data formats. Its disadvantages are the + resource consumption for processing, storing, and transmitting + information. Since the expected data volumes related to traceroute + measurement in network operation and maintenance are not expected to + be extremely high, the inefficient usage of resources is not a + significant disadvantage. Therefore, XML was chosen as a basis for + the traceroute measurement information model that is 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 was designed in order to use an extensible approach based on + templates (pretty similar to how the IPFIX protocol is designed) + where the traceroute configuration elements (both the requested + parameters, "RequestMetadata", and the actual parameters used, + "MeasurementMetadata") are metadata to be referenced by results + information elements (data) by means of the "TestName" element (used + as a unique identifier, chosen in accordance to the specification of + [RFC4560]). Currently Open Grid Forum (OGF) is also using this + approach and cross-requirements have been analyzed. As a result of + this analysis, the XML schema contained in Section 7 is compatible + with the OGF schema since both were designed in a way that limits the + 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 presented 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 of + the 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. + + + + +Niccolini, et al. Standards Track [Page 24] + +RFC 5388 Traceroute Storage Format December 2008 + + + Due to the limited line length some lines appear wrapped. + + + + + + String restricted to 255 + characters. + + + + + + + + + + unsignedByte with non zero + value. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Niccolini, et al. Standards Track [Page 26] + +RFC 5388 Traceroute Storage Format December 2008 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Niccolini, et al. Standards Track [Page 27] + +RFC 5388 Traceroute Storage Format December 2008 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 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. + + + + + + +Niccolini, et al. Standards Track [Page 28] + +RFC 5388 Traceroute Storage Format December 2008 + + + + + Specifies the DNS name of + the "HopAddr" if it is available. If it is + not available, the element is + omitted. + + + + + + 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. + + + + + + + + + + + + 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 "< 1 ms" is therefore encoded as 0 ms). + If it contains the element + + + +Niccolini, et al. Standards Track [Page 29] + +RFC 5388 Traceroute Storage Format December 2008 + + + "roundTripTimeNotAvailable", it means either + the probe was lost because of a timeout or it + was not possible to transmit a probe. + + + + + + + Specifies the result of a + traceroute measurement made by the host for a + particular probe. + + + + + + Specifies the timestamp for + the time the response to the probe was + received at the interface. + + + + + + + + + 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. + + + + + + + + + + + Specifies the metadata for a traceroute + operation -- the parameters requested if used in + + + +Niccolini, et al. Standards Track [Page 30] + +RFC 5388 Traceroute Storage Format December 2008 + + + "RequestMetadata" or the actual parameters used if used in + "MeasurementMetadata". + + + + + + 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). + + + + + + Specifies the name of the operating + system on which the traceroute measurement was launched. + This element is ignored if used in the + "RequestMetadata". + + + + + + Specifies the OS version on which the + traceroute measurement was launched. This element is + ignored if used in the + "RequestMetadata". + + + + + + Specifies the version of the traceroute + tool (requested to be used if in the "RequestMetadata" + element, actually used if in the "MeasurementMetadata" + element). + + + + + + Specifies the name of the traceroute + tool (requested to be used if in the "RequestMetadata" + element, actually used if in the "MeasurementMetadata" + element). + + + + +Niccolini, et al. Standards Track [Page 31] + +RFC 5388 Traceroute Storage Format December 2008 + + + + + + + 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. + + + + + + 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). + + + + + + + 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 + + + +Niccolini, et al. Standards Track [Page 32] + +RFC 5388 Traceroute Storage Format December 2008 + + + 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). + + + + + + + + + + + + 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). + + + + + + + + + + + + + + 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). + + + + + + + + + + + + + + +Niccolini, et al. Standards Track [Page 33] + +RFC 5388 Traceroute Storage Format December 2008 + + + + + Specifies the base port used by the + traceroute measurement (requested if in the + "RequestMetadata" element, actually used if in the + "MeasurementMetadata" element). + + + + + + + + + + + + Specifies the maximum TTL value for the + traceroute measurement (requested if in the + "RequestMetadata" element, actually used if in the + "MeasurementMetadata" element). + + + + + + 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). + + + + + + +Niccolini, et al. Standards Track [Page 34] + +RFC 5388 Traceroute Storage Format December 2008 + + + + + 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. + + + + + + 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). + + + + + + Specifies implementation-dependent + options (requested if in the "RequestMetadata" element, + actually used if in the "MeasurementMetadata" + element). + + + + + + Specifies the maximum number of + consecutive timeouts allowed before terminating a + traceroute measurement (requested if in the + "RequestMetadata" element, actually used if in the + + + +Niccolini, et al. Standards Track [Page 35] + +RFC 5388 Traceroute Storage Format December 2008 + + + "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. + + + + + + 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. + + + + + + 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. + + + + + + Provides a description of the traceroute + measurement. + + + + + + Specifies the implementation method + used for the traceroute measurement (requested if in the + "RequestMetadata" element, actually used if in the + + + +Niccolini, et al. Standards Track [Page 36] + +RFC 5388 Traceroute Storage Format December 2008 + + + "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. + + + + + + + + Contains the actual traceroute measurement + results. + + + + + + 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). + + + + + + Specifies the date and start time of + the traceroute measurement. This is the time when the + first probe was seen at the sending + interface. + + + + + + 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. + + + + + +Niccolini, et al. Standards Track [Page 37] + +RFC 5388 Traceroute Storage Format December 2008 + + + + + + + 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). + + + + + + + + + + + + + + + + + + + + + + + + +8. Security Considerations + + Security considerations discussed in this section are grouped into + considerations related to conducting traceroute measurements and + considerations related to storing and transmitting traceroute + measurement information. + + + + + + +Niccolini, et al. Standards Track [Page 38] + +RFC 5388 Traceroute Storage Format December 2008 + + + This memo does not specify an implementation of a traceroute tool. + Neither does it specify a certain procedure for storing traceroute + measurement information. Still, it is considered desirable to + discuss related security issues below. + +8.1. Conducting Traceroute Measurements + + Conducting Internet measurements can raise both security and privacy + concerns. Traceroute measurements, in which traffic is injected into + the network, can be abused for denial-of-service attacks disguised as + legitimate measurement activity. + + Measurement parameters MUST be carefully selected so that the + measurements inject trivial amounts of additional traffic into the + networks they measure. If they inject "too much" traffic, they can + skew the results of the measurement, and in extreme cases cause + congestion and denial of service. + + The measurements themselves could be harmed by routers giving + measurement traffic a different priority than "normal" traffic, or by + an attacker injecting artificial measurement traffic. If routers can + recognize measurement traffic and treat it separately, the + measurements will not reflect actual user traffic. If an attacker + injects artificial traffic that is accepted as legitimate, the loss + rate will be artificially lowered. Therefore, the measurement + methodologies SHOULD include appropriate techniques to reduce the + probability that measurement traffic can be distinguished from + "normal" traffic. + + Authentication techniques, such as digital signatures, may be used + where appropriate to guard against injected traffic attacks. + +8.2. Securing Traceroute Measurement Information + + Traceroute measurement information is not considered highly + sensitive. Still, it may contain sensitive information on network + paths, routing states, used IP addresses, and roundtrip times that + operators of networks may want to protect for business or security + reasons. + + It is thus important to control access to information acquired by + conducting traceroute measurements, particularly when transmitting it + over a networks but also when storing it. 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. + + + +Niccolini, et al. Standards Track [Page 39] + +RFC 5388 Traceroute Storage Format December 2008 + + +9. IANA Considerations + + This document uses URNs to describe an XML namespace and an XML + schema for traceroute measurement information storing and + transmission, conforming to a 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. + + + + + + +Niccolini, et al. Standards Track [Page 40] + +RFC 5388 Traceroute Storage Format December 2008 + + + [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. + + + + +Niccolini, et al. Standards Track [Page 41] + +RFC 5388 Traceroute Storage Format December 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, + . + + [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, + . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Niccolini, et al. Standards Track [Page 42] + +RFC 5388 Traceroute Storage Format December 2008 + + +Appendix A. Traceroute Default Configuration Parameters + + This section lists traceroute measurement configuration parameters as + well as their defaults on various platforms and illustrates how + widely they may vary. This document considers four major traceroute + tool implementations and compares them based on configurable + parameters and default values. The LINUX (SUSE 9.1), BSD (FreeBSD + 7.0), and UNIX (SunOS 5.9) implementations are based on UDP + datagrams, while the WINDOWS (XP SP2) one uses ICMP Echoes. The + comparison is summarized in the following table, where an N/A in the + option column means that such parameter is not configurable for the + specific implementation. A comprehensive comparison of available + implementations is outside the scope of this document; however, by + sampling a few different implementations, it can be observed that + they can differ quite significantly in terms of configurable + parameters and also default values. Note that in the following table + only those options that are available in at least two of the + considered implementations are reported. + + +---------------------------------------------------------+ + | 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 | + + + + + + +Niccolini, et al. Standards Track [Page 43] + +RFC 5388 Traceroute Storage Format December 2008 + + + +--------+------+-------------------------------+---------+ + | 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 | | - | + + + +Niccolini, et al. Standards Track [Page 44] + +RFC 5388 Traceroute Storage Format December 2008 + + + +--------+------+-------------------------------+---------+ + | 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 | | - | + + + +Niccolini, et al. Standards Track [Page 45] + +RFC 5388 Traceroute Storage Format December 2008 + + + +--------+------+-------------------------------+---------+ + | 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 + + As stated above, the widespread use of firewalls might prevent UDP- + or ICMP-based traceroutes to completely trace the path to a + destination since traceroute probes might end up being filtered. In + some cases, such limitation might be overcome by sending instead TCP + packets to specific ports that hosts located behind the firewall are + listening for connections 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 on the path. On the + other hand, some firewalls filter out TCP SYN packets to prevent + denial-of-service attacks; therefore, the actual advantage of using + TCP instead of UDP traceroute depends mainly on firewall + configurations, which are not known in advance. A detailed analysis + of TCP-based traceroute tools and measurements is outside the scope + of this document; regardless, for completeness reasons, the + information model also supports the storing of TCP-based traceroute + measurements. + + + + + + + +Niccolini, et al. Standards Track [Page 46] + +RFC 5388 Traceroute Storage Format December 2008 + + +Appendix B. Known Problems with Traceroute + +B.1. Compatibility between Traceroute Measurement Results and IPPM + Metrics + + Because of implementation choices, a known inconsistency exists + between the round-trip delay metric defined by the IPPM working group + in RFC 2681 and the results returned by the current traceroute tool + implementations. Unfortunately, it is unlikely that the traceroute + tool implementations will implement the standard definition in the + near future. The only possibility is therefore to compare results of + different traceroute measurements with each other; in order to do + this, specifications both of the operating system (name and version) + and of the traceroute tool version used were added to the metadata + elements in order to help in comparing metrics between two different + traceroute measurement results (if run using the same operating + system and the same version of the tool). Moreover, the traceroute + tool has built-in configurable mechanisms like timeouts and can + experience problems related to the crossing of firewalls; therefore, + some of the packets that traceroute sends out end up being timeout or + filtered. As a consequence, it might not be possible to trace the + path to a node or there might not be a complete enough set of probes + describing the RTT to reach it. + +Appendix C. Differences to DISMAN-TRACEROUTE-MIB + + For performing remote traceroute operations at managed node, the IETF + has standardized the DISMAN-TRACEROUTE-MIB module in [RFC4560]. This + module allows: + + o retrieving capability information of the traceroute tool + implementation at the managed node; + + o configuring traceroute measurements to be performed; + + o retrieving information about ongoing and completed traceroute + measurements; + + o retrieving traceroute measurement statistics. + + The traceroute storage format described in this document has + significant overlaps with this MIB module. Particularly, the models + for the traceroute measurement configuration and for the results from + completed measurements are almost identical. But for other parts of + the DISMAN-TRACEROUTE MIB module there is no need to model them in a + traceroute measurement storage format. Particularly, the capability + information, information about ongoing measurements, and measurement + statistics are not covered by the DISMAN traceroute storage model. + + + +Niccolini, et al. Standards Track [Page 47] + +RFC 5388 Traceroute Storage Format December 2008 + + + Concerning traceroute measurements and their results, there are + structural differences between the two models caused by the different + choices for the encoding of the specification. For DISMAN- + TRACEROUTE-MIB, the Structure of Management Information (SMIv2, STD + 58, RFC 2578 [RFC2578]) was used, while the IPPM traceroute + measurement data model is encoded using XML. + + This difference in structure implies that the DISMAN-TRACEROUTE-MIB + module contains SMI-specific information elements (managed objects) + that concern tables of managed objects (specification, entry creation + and deletion, status retrieval) that are not required for the XML- + encoded traceroute measurement data model. + + But for most of the remaining information elements that concern + configuration of 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 to this; these are listed below. Also, + naming of information elements is identical between both models with + a few exceptions. For the traceroute measurement data model, a few + information elements have been added, some because of the different + structure and some to provide additional information on completed + measurements. + +C.1. Scope + + There are some basic differences in nature and application between + MIB modules and XML documents. This results in two major differences + of scope between the DISMAN-TRACEROUTE-MIB module and the traceroute + measurement data model. + + The first difference is the "traceRouteResultsTable" contained in the + DISMAN-TRACEROUTE-MIB module. This table allows online observation + of status and progress of an ongoing traceroute measurement. This + highly dynamic information is not included in the traceroute + measurement data model because it has not been envisioned to use the + model for dynamically reporting progress of individual traceroute + measurements. The traceroute measurement data model is rather + intended to be used for reporting completed traceroute measurements. + + The second difference is due to the fact that information in a MIB is + typically tied to a local node hosting the MIB instance. The + "RequestMetadata" element specified in the traceroute measurement + data model can be used for specifying a measurement request that may + be applied to several probes in a network. This concept does not + exist in the DISMAN-TRACEROUTE-MIB module. + + + + + +Niccolini, et al. Standards Track [Page 48] + +RFC 5388 Traceroute Storage Format December 2008 + + + For the remaining elements in the DISMAN-TRACEROUTE-MIB module and in + the traceroute measurement data model, there is a very good match + between the two worlds. The "traceRouteCtlTable" corresponds to the + "MeasurementMetadata" element, and the combination of the + "traceRouteProbeHistoryTable" and the "traceRouteHopsTable" + corresponds to a collection of "MeasurementResult" elements. + +C.2. Naming + + Basically, names in both models are chosen using the same naming + conventions. + + For the traceroute measurement configuration information, all names, + such as "CtlProbesPerHop", are identical in both models except for + the traceRoute prefix that was removed to avoid unnecessary + redundancy in the XML file and for "CtlDataSize", which was renamed + to "CtlProbeDataSize" for clarification in the traceroute measurement + data model. + + Results of measurements in the DISMAN-TRACEROUTE-MIB modules are + distributed over two tables, the "traceRouteResultsTable" contains + mainly information about ongoing measurements and the + "traceRouteProbeHistoryTable" contains only information about + completed measurements. According to the SMIv2 naming conventions, + names of information elements in these tables have different prefixes + ("traceRouteResults" and "traceRouteProbeHistory"). Since the + traceroute measurement data model only reports on completed + measurements, this separation is not needed anymore and the prefix + "Results" is used for all related information elements. + + Beyond that, there are only a few changes in element names. The + renaming actions include: + + o "traceRouteProbeHistoryResponse" to "ProbeRoundTripTime"; + + o "traceRouteProbeHistoryHAddr" to "HopAddr"; + + o "traceRouteProbeHistoryTime" to "ResultsEndDateAndTime"; + + o "traceRouteProbeHistoryLastRC" to "ResultsHopRawOutputData". + +C.3. Semantics + + The semantics were changed for two information elements only. + + For "traceRouteProbeHistoryResponse" in the DISMAN-TRACEROUTE-MIB, a + value of 0 indicates that it is not possible to transmit a probe. + For the traceroute measurement data model, a value of 0 for element + + + +Niccolini, et al. Standards Track [Page 49] + +RFC 5388 Traceroute Storage Format December 2008 + + + "RoundTripTime" indicates that the measured time was less than one + millisecond. For the case that it was not possible to transmit a + probe, a string is used that indicates the problem. + + For "traceRouteCtlIfIndex" in the DISMAN-TRACEROUTE-MIB, a value of 0 + indicates that the option to set the index is not available. This + was translated to the traceroute measurement data model, such that a + value of 0 for this element indicates that the used interface is + unknown. + + The element "traceRouteProbeHistoryLastRC" in the DISMAN-TRACEROUTE- + MIB was replaced by element "ResultsHopRawOutputData". While + "traceRouteProbeHistoryLastRC" just reports a reply code, + "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 have been added to the model of the + DISMAN-TRACEROUTE-MIB module. + + o For providing information on the MPLS label stack entries of a + probe in the traceroute measurement path, "MPLSLabelStackEntry" + was added. + + o For providing additional timestamp beyond "ResultsEndDateAndTime", + "ResultsStartDateAndTime" and "Time" were added. + + o For providing DNS names at the time of the execution of the + traceroute for each "HopAddr" (which may change over time), + "HopName" was added. + +Appendix D. Traceroute Examples with XML Representation + + This section shows some examples of traceroute applications. In + addition, the encoding of requests and results is shown for some of + those examples. Also, note that in these XML examples some lines + appear wrapped due to the limited length of line. + + A typical traceroute on a LINUX system looks like the following: + # 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 * * + + + +Niccolini, et al. Standards Track [Page 50] + +RFC 5388 Traceroute Storage Format December 2008 + + + This traceroute ignores the first 4 hops and uses 1500-byte packets + including the header. It does not reach its goal since the last + listed hop says that the network is not reachable (N!). The XML + representation for this trace follows: + + + + Example 1 + + + + + + www.example + + + 1472 + + + + + + + + + + + + + 4 + Show how it encodes in XML + + + + + Example 1 + Linux + 2.6.16.54-0.2.5-smp i386 + 1.0 + traceroute + + www.example + + + 1472 + + + + + + +Niccolini, et al. Standards Track [Page 51] + +RFC 5388 Traceroute Storage Format December 2008 + + + + + + 192.0.2.1 + + 2 + + + + 4 + Show how it encodes in XML + + + + Example 1 + 2008-05-16T14:22:34+02:00 + + 192.0.2.42 + + + + + + 192.0.2.254 + + out.host1.example + + 6 + + responseReceived + + + + + 192.0.2.254 + + out.host1.example + 5 + responseReceived + + + + + 192.0.2.254 + + out.host1.example + + + +Niccolini, et al. Standards Track [Page 52] + +RFC 5388 Traceroute Storage Format December 2008 + + + + 6 + + responseReceived + + + 5 out.host1.example (192.0.2.254) 6.06 + 6 ms 5.625 ms 6.095 ms + + + + + 192.0.2.142 + + rtr4.host6.example + + 6 + + responseReceived + + + + + 192.0.2.142 + + rtr4.host6.example + + 6 + + responseReceived + + + + + 192.0.2.142 + + rtr4.host6.example + + 7 + + responseReceived + + + 6 rtr4.host6.example (192.0.2.142) 6.9 + 79 ms 6.221 ms 7.368 ms + + + + + + +Niccolini, et al. Standards Track [Page 53] + +RFC 5388 Traceroute Storage Format December 2008 + + + + 192.0.2.11 + + hop7.rtr9.example + + 16 + + responseReceived + + + + + 192.0.2.11 + + hop7.rtr9.example + + 15 + + responseReceived + + + + + 192.0.2.11 + + hop7.rtr9.example + + 15 + + responseReceived + + + 7 hop7.rtr9.example (192.0.2.11) 16.16 + 5 ms 15.347 ms 15.514 ms + + + + + 192.0.2.222 + + + 32 + + responseReceived + + + + + + + +Niccolini, et al. Standards Track [Page 54] + +RFC 5388 Traceroute Storage Format December 2008 + + + 192.0.2.222 + + + 38 + + responseReceived + + + + + 192.0.2.222 + + + 26 + + responseReceived + + + 8 192.0.2.222 (192.0.2.222) 32.796 ms + 28.723 ms 26.988 ms + + + + + 192.0.2.123 + + in.example + + 15 + + responseReceived + + + + + 192.0.2.123 + + in.example + + 16 + + responseReceived + + + + + 192.0.2.123 + + + + +Niccolini, et al. Standards Track [Page 55] + +RFC 5388 Traceroute Storage Format December 2008 + + + in.example + + 17 + + responseReceived + + + 9 in.example (192.0.2.123) 15.861 ms + 16.262 ms 17.610 ms + + + + + 192.0.2.123 + + in.example + + 17 + + noRouteToTarget + + + + + 192.0.2.123 + + in.example + + + + requestTimedOut + + + + + 192.0.2.123 + + in.example + + + + requestTimedOut + + + 10 in.example (192.0.2.123)(N!) 17.391 + ms * * + + + + + +Niccolini, et al. Standards Track [Page 56] + +RFC 5388 Traceroute Storage Format December 2008 + + + 2008-05-16T14:22:44+02:00 + + + + + The second example was generated on an OpenBSD system. On that + system, the traceroute looks like the following: + # 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 + + It was executed with the TCP protocol and 128-byte packets (plus + header). The traceroute ended at hop 9 because the packets are + administratively filtered (!X). A corresponding XML representation + follows: + + + + Example 2 + + + + + + w2.example + + + 128 + + + + + + + + + + + + + +Niccolini, et al. Standards Track [Page 57] + +RFC 5388 Traceroute Storage Format December 2008 + + + + + + Show how it encodes in XML + + + + + Example 2 + OpenBSD + 4.1 i386 + + traceroute + + w2.example + + + 128 + + + + + + + 192.0.2.42 + + 1 + + + + + Show how it encodes in XML + + + + Example 2 + 2008-05-14T09:57:11+02:00 + + 192.0.2.254 + + + + + + 192.0.2.22 + + router1.example.org + + + +Niccolini, et al. Standards Track [Page 58] + +RFC 5388 Traceroute Storage Format December 2008 + + + + 0 + + responseReceived + + + + + 192.0.2.22 + + router1.example.org + + 0 + + responseReceived + + + + + 192.0.2.22 + + router1.example.org + + 0 + + responseReceived + + + + + + + 192.0.2.1 + + router7.example.org + + 3 + + responseReceived + + + + + 192.0.2.1 + + router7.example.org + + 1 + + + +Niccolini, et al. Standards Track [Page 59] + +RFC 5388 Traceroute Storage Format December 2008 + + + + responseReceived + + + + + 192.0.2.1 + + router7.example.org + + 1 + + responseReceived + + + + + + + 192.0.2.105 + + hop0.c.example + + 3 + + responseReceived + + + + + 192.0.2.105 + + hop0.c.example + + 3 + + responseReceived + + + + + 192.0.2.105 + + hop0.c.example + + 3 + + responseReceived + + + +Niccolini, et al. Standards Track [Page 60] + +RFC 5388 Traceroute Storage Format December 2008 + + + + + + + + + 192.0.2.107 + + hop6.c.example + + 5 + + responseReceived + + + + + 192.0.2.107 + + hop6.c.example + + 4 + + responseReceived + + + + + 192.0.2.107 + + hop6.c.example + + 5 + + responseReceived + + + + + + + 192.0.2.111 + + hop3.c.example + + 20 + + responseReceived + + + +Niccolini, et al. Standards Track [Page 61] + +RFC 5388 Traceroute Storage Format December 2008 + + + + + + + 192.0.2.111 + + hop3.c.example + + 20 + + responseReceived + + + + + 192.0.2.111 + + hop3.c.example + + 19 + + responseReceived + + + + + + + 192.0.2.222 + + in.example.net + + 20 + + responseReceived + + + + + 192.0.2.222 + + in.example.net + + 19 + + responseReceived + + + + + +Niccolini, et al. Standards Track [Page 62] + +RFC 5388 Traceroute Storage Format December 2008 + + + + + 192.0.2.222 + + in.example.net + + 19 + + responseReceived + + + + + + + 192.0.2.227 + + egress.example.net + + 20 + + responseReceived + + + + + 192.0.2.227 + + egress.example.net + + 21 + + responseReceived + + + + + 192.0.2.227 + + egress.example.net + + 19 + + responseReceived + + + + + + + +Niccolini, et al. Standards Track [Page 63] + +RFC 5388 Traceroute Storage Format December 2008 + + + + + 192.0.2.253 + + routerin.example + + 19 + + responseReceived + + + + + 192.0.2.253 + + routerin.example + + 19 + + responseReceived + + + + + 192.0.2.253 + + routerin.example + + 19 + + responseReceived + + + + + + + 192.0.2.249 + + routerdmz.example + + 20 + + unknown + + + + + + + +Niccolini, et al. Standards Track [Page 64] + +RFC 5388 Traceroute Storage Format December 2008 + + + 192.0.2.249 + + routerdmz.example + + + + requestTimedOut + + + + + 192.0.2.249 + + routerdmz.example + + 19 + + unknown + + + + + 2008-05-14T09:57:30+02:00 + + + + + The third and last example is based on the Microsoft Windows pendant + of traceroute. On an MS Windows system, the command is called + "tracert" and typically looks as follows: + + # tracert -h 10 www.example.org + + 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 + + + + +Niccolini, et al. Standards Track [Page 65] + +RFC 5388 Traceroute Storage Format December 2008 + + + Trace complete. + + In this example, the trace was limited to 10 hops, so the tenth and + last hop of this example was not the final destination. Applying the + XML schema defined in this document, the trace could look as follows: + + + + Example 3 + + + + + + www.example.org + + + + + + + 10 + + + + + + + + + + Show how it encodes in XML + + + + + Example 3 + Windows + XP SP2 32-bit + + tracert + + www.example.org + + + + + + + + +Niccolini, et al. Standards Track [Page 66] + +RFC 5388 Traceroute Storage Format December 2008 + + + + 10 + + + 192.0.2.142 + + 3 + + + + + Show how it encodes in XML + + + + Example 3 + 2008-05-14T11:03:09+02:00 + + 192.0.2.11 + + + + + + 192.0.2.99 + + + 1 + + responseReceived + + + + + 192.0.2.99 + + + 1 + + responseReceived + + + + + 192.0.2.99 + + + + + +Niccolini, et al. Standards Track [Page 67] + +RFC 5388 Traceroute Storage Format December 2008 + + + 8 + + responseReceived + + + + + + + 192.0.2.102 + + r1.provider4.example + + 0 + + responseReceived + + + + + 192.0.2.102 + + r1.provider4.example + + 0 + + responseReceived + + + + + 192.0.2.102 + + r1.provider4.example + + 0 + + responseReceived + + + + + + + 192.0.2.254 + + rtr8.provider8.example + + + + +Niccolini, et al. Standards Track [Page 68] + +RFC 5388 Traceroute Storage Format December 2008 + + + 0 + + responseReceived + + + + + 192.0.2.254 + + rtr8.provider8.example + + 0 + + responseReceived + + + + + 192.0.2.254 + + rtr8.provider8.example + + 0 + + responseReceived + + + + + + + 192.0.2.4 + + hop11.hoster7.example + + 1 + + responseReceived + + + + + 192.0.2.4 + + hop11.hoster7.example + + 1 + + + + +Niccolini, et al. Standards Track [Page 69] + +RFC 5388 Traceroute Storage Format December 2008 + + + responseReceived + + + + + 192.0.2.4 + + hop11.hoster7.example + + 1 + + responseReceived + + + + + + + 192.0.2.201 + + sw6.provider2.example + + 2 + + responseReceived + + + + + 192.0.2.201 + + sw6.provider2.example + + 3 + + responseReceived + + + + + 192.0.2.201 + + sw6.provider2.example + + 1 + + responseReceived + + + + +Niccolini, et al. Standards Track [Page 70] + +RFC 5388 Traceroute Storage Format December 2008 + + + + + + + + 192.0.2.111 + + out.provider2.example + + 3 + + responseReceived + + + + + 192.0.2.111 + + out.provider2.example + + 3 + + responseReceived + + + + + 192.0.2.111 + + out.provider2.example + + 3 + + responseReceived + + + + + + + 192.0.2.123 + + + + + requestTimedOut + + + + + +Niccolini, et al. Standards Track [Page 71] + +RFC 5388 Traceroute Storage Format December 2008 + + + + + 192.0.2.123 + + + 6 + + responseReceived + + + + + 192.0.2.123 + + + 5 + + responseReceived + + + + + + + 192.0.2.42 + + + 5 + + responseReceived + + + + + 192.0.2.42 + + + 5 + + responseReceived + + + + + 192.0.2.42 + + + 5 + + + +Niccolini, et al. Standards Track [Page 72] + +RFC 5388 Traceroute Storage Format December 2008 + + + + responseReceived + + + + + + + 192.0.2.199 + + ingress.example.org + + 94 + + responseReceived + + + + + 192.0.2.199 + + ingress.example.org + + 95 + + responseReceived + + + + + 192.0.2.199 + + ingress.example.org + + 95 + + responseReceived + + + + + + + 192.0.2.44 + + + 168 + + + + +Niccolini, et al. Standards Track [Page 73] + +RFC 5388 Traceroute Storage Format December 2008 + + + responseReceived + + + + + 192.0.2.44 + + + 169 + + responseReceived + + + + + 192.0.2.44 + + + 169 + + responseReceived + + + + + 2008-05-14T11:03:23+02:00 + + + + + The three examples given in this section are intended to give an + impression of how a trace could be represented in XML. The + representation generated by an implementation may differ from the + examples here depending on the system and the capabilities of the + traceroute implementation. + + + + + + + + + + + + + + + +Niccolini, et al. Standards Track [Page 74] + +RFC 5388 Traceroute Storage Format December 2008 + + +Authors' Addresses + + 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 + + + +Niccolini, et al. Standards Track [Page 75] + -- cgit v1.2.3