RFC 5388
Information Model and XML Data Model for Traceroute Measurements
Pages: 75
Proposed Standard
Proposed Standard
Part 2 of 3 – Pages 23 to 46
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
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.
Due to the limited line length some lines appear wrapped.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema elementFormDefault="qualified"
targetNamespace="urn:ietf:params:xml:ns:traceroute-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tr="urn:ietf:params:xml:ns:traceroute-1.0">
<xs:simpleType name="string255">
<xs:annotation>
<xs:documentation>String restricted to 255
characters.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:maxLength value="255"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="u8nonzero">
<xs:annotation>
<xs:documentation>unsignedByte with non zero
value.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedByte">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="_roundTripTime">
<xs:choice>
<xs:element name="roundTripTime">
<xs:simpleType>
<xs:restriction base="xs:unsignedInt"/>
</xs:simpleType>
</xs:element>
<xs:element name="roundTripTimeNotAvailable">
<xs:complexType/>
</xs:element>
</xs:choice>
</xs:complexType>
<xs:complexType name="_inetAddressUnknown"/>
<xs:simpleType name="_inetAddressIpv4">
<xs:restriction base="xs:string">
<xs:pattern value="(([1-9]?[0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5
]).){3}([1-9]?[0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_inetAddressIpv6">
<xs:restriction base="xs:string">
<xs:pattern value="(([\dA-Fa-f]{1,4}:){7}[\dA-Fa-f]{1,4})(:([\d
]{1,3}.){3}[\d]{1,3})?"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_inetAddressDns">
<xs:restriction base="xs:string">
<xs:maxLength value="256"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="_inetAddressASNumber">
<xs:annotation>
<xs:documentation>Specifies the AS number of a hop in the
traceroute path as a 32-bit number and indicates how the
mapping from IP address to AS number was
performed.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="asNumber" type="xs:unsignedInt"/>
<xs:element name="ipASNumberMappingType">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="bgptables"/>
<xs:enumeration value="routingregistries"/>
<xs:enumeration value="nslookup"/>
<xs:enumeration value="others"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="inetAddress">
<xs:choice>
<xs:element name="inetAddressUnknown"
type="tr:_inetAddressUnknown"/>
<xs:element name="inetAddressIpv4" type="tr:_inetAddressIpv4"/>
<xs:element name="inetAddressIpv6" type="tr:_inetAddressIpv6"/>
<xs:element name="inetAddressASNumber"
type="tr:_inetAddressASNumber"/>
<xs:element minOccurs="0" name="inetAddressDns"
type="tr:_inetAddressDns"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="inetAddressWithoutDns">
<xs:sequence>
<xs:choice>
<xs:element name="inetAddressUnknown"
type="tr:_inetAddressUnknown"/>
<xs:element name="inetAddressIpv4"
type="tr:_inetAddressIpv4"/>
<xs:element name="inetAddressIpv6"
type="tr:_inetAddressIpv6"/>
<xs:element name="inetAddressASNumber"
type="tr:_inetAddressASNumber"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="operationResponseStatus">
<xs:restriction base="xs:string">
<xs:enumeration value="responseReceived"/>
<xs:enumeration value="unknown"/>
<xs:enumeration value="internalError"/>
<xs:enumeration value="requestTimedOut"/>
<xs:enumeration value="unknownDestinationAddress"/>
<xs:enumeration value="noRouteToTarget"/>
<xs:enumeration value="interfaceInactiveToTarget"/>
<xs:enumeration value="arpFailure"/>
<xs:enumeration value="maxConcurrentLimitReached"/>
<xs:enumeration value="unableToResolveDnsName"/>
<xs:enumeration value="invalidHostAddress"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="_CtlType">
<xs:choice>
<xs:element name="TCP">
<xs:complexType/>
</xs:element>
<xs:element name="UDP">
<xs:complexType/>
</xs:element>
<xs:element name="ICMP">
<xs:complexType/>
</xs:element>
<xs:any namespace="##other"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="_ProbeResults">
<xs:sequence>
<xs:element maxOccurs="255" name="hop">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="10" name="probe">
<xs:complexType>
<xs:sequence>
<xs:element name="HopAddr"
type="tr:inetAddressWithoutDns">
<xs:annotation>
<xs:documentation>Specifies the address of a
hop in the traceroute measurement path. This
object is not allowed to be a DNS name. The
address type can be determined by examining the
"inetAddress" type name and the corresponding
element value.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element minOccurs="0" name="HopName"
type="tr:_inetAddressDns">
<xs:annotation>
<xs:documentation>Specifies the DNS name of
the "HopAddr" if it is available. If it is
not available, the element is
omitted.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element maxOccurs="255" minOccurs="0"
name="MPLSLabelStackEntry">
<xs:annotation>
<xs:documentation>Specifies entries of the
MPLS label stack of a probe observed when the
probe arrived at the hop that replied to the
probe. This object contains one MPLS label stack
entry as a 32-bit value as it is observed on the
MPLS label stack. Contained in this single
number are the MPLS label, the Exp field, the S
flag, and the MPLS TTL value as specified in
[RFC3032]. If more than one MPLS label stack
entry is reported, then multiple instances of
elements of this type are used. They must be
ordered in the same order as on the label stack
with the top label stack entry being reported
first.</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:unsignedInt">
<xs:maxInclusive value="4294967295"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="ProbeRoundTripTime"
type="tr:_roundTripTime">
<xs:annotation>
<xs:documentation>If this element contains the
element "roundTripTime", this specifies the
amount of time measured in milliseconds from
when a probe was sent to when its response was
received or when it timed out. The value of
this element is reported as the truncation of
the number reported by the traceroute tool (the
output "< 1 ms" is therefore encoded as 0 ms).
If it contains the element
"roundTripTimeNotAvailable", it means either
the probe was lost because of a timeout or it
was not possible to transmit a probe.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="ResponseStatus"
type="tr:operationResponseStatus">
<xs:annotation>
<xs:documentation>Specifies the result of a
traceroute measurement made by the host for a
particular probe.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="Time" type="xs:dateTime">
<xs:annotation>
<xs:documentation>Specifies the timestamp for
the time the response to the probe was
received at the interface.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="HopRawOutputData"
type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies the raw output data
returned by the traceroute measurement for a
certain hop in a traceroute measurement path. It is
an implementation-dependent, printable string,
expected to be useful for a human interpreting the
traceroute results.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="_Metadata">
<xs:annotation>
<xs:documentation>Specifies the metadata for a traceroute
operation -- the parameters requested if used in
"RequestMetadata" or the actual parameters used if used in
"MeasurementMetadata".</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="TestName" type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies the name of a traceroute
measurement. This is not necessarily unique within any
well-defined scope (e.g., a specific host, initiator of
the traceroute measurement).</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="" name="OSName" type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies the name of the operating
system on which the traceroute measurement was launched.
This element is ignored if used in the
"RequestMetadata".</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="" name="OSVersion" type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies the OS version on which the
traceroute measurement was launched. This element is
ignored if used in the
"RequestMetadata".</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="" name="ToolVersion" type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies the version of the traceroute
tool (requested to be used if in the "RequestMetadata"
element, actually used if in the "MeasurementMetadata"
element).</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="" name="ToolName" type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies the name of the traceroute
tool (requested to be used if in the "RequestMetadata"
element, actually used if in the "MeasurementMetadata"
element).</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="CtlTargetAddress" type="tr:inetAddress">
<xs:annotation>
<xs:documentation>In the "RequestMetadata" element, it
specifies the host address requested to be used in the
traceroute measurement. In the "MeasurementMetadata"
element, it specifies the host address used in the
traceroute measurement. The host address type can be
determined by examining the "inetAddress" type name and
the corresponding element value.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="false" name="CtlBypassRouteTable"
type="xs:boolean">
<xs:annotation>
<xs:documentation>In the "RequestMetadata" element
specifies if the optional bypassing of the route
table was enabled or not. In the "MeasurementMetadata"
element, specifies if the optional bypassing of the route
table was enabled or not. If enabled, the normal routing
tables will be bypassed and the probes will be sent
directly to a host on an attached network. If the host is
not on a directly attached network, an error is returned.
This option can be used to perform the traceroute
measurement to a local host through an interface that has
no route defined. This object can be used when the
setsockopt SOL_SOCKET SO_DONTROUTE option is supported and
set (see the POSIX standard IEEE.1003-1G.1997).
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="0" name="CtlProbeDataSize">
<xs:annotation>
<xs:documentation>Specifies the size of the probes of a
traceroute measurement in octets (requested if in the
"RequestMetadata" element, actually used if in the
"MeasurementMetadata" element). If UDP datagrams are used
as probes, then the value contained in this object is
exact. If another protocol is used to transmit probes
(i.e., TCP or ICMP) for which the specified size is not
appropriate, then the implementation can use whatever
size (appropriate to the method) is closest to the
specified size. The maximum value for this object is
computed by subtracting the smallest possible IP header
size of 20 octets (IPv4 header with no options) and the
UDP header size of 8 octets from the maximum IP packet
size. An IP packet has a maximum size of 65535 octets
(excluding IPv6 jumbograms).</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:unsignedShort">
<xs:maxInclusive value="65507"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element default="3" name="CtlTimeOut">
<xs:annotation>
<xs:documentation>Specifies the timeout value, in
seconds, for each probe of a traceroute measurement
(requested if in the "RequestMetadata" element, actually
used if in the "MeasurementMetadata"
element).</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:unsignedByte">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="60"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element default="3" name="CtlProbesPerHop">
<xs:annotation>
<xs:documentation>Specifies the number of probes with the
same time-to-live (TTL) value that are sent for each host
(requested if in the "RequestMetadata" element, actually
used if in the "MeasurementMetadata"
element).</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:unsignedByte">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="10"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element default="33434" name="CtlPort">
<xs:annotation>
<xs:documentation>Specifies the base port used by the
traceroute measurement (requested if in the
"RequestMetadata" element, actually used if in the
"MeasurementMetadata" element).</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:unsignedShort">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element default="30" name="CtlMaxTtl" type="tr:u8nonzero">
<xs:annotation>
<xs:documentation>Specifies the maximum TTL value for the
traceroute measurement (requested if in the
"RequestMetadata" element, actually used if in the
"MeasurementMetadata" element).</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="0" name="CtlDSField"
type="xs:unsignedByte">
<xs:annotation>
<xs:documentation>Specifies the value that was requested
to be stored in the Differentiated Services (DS) field in
the traceroute probe (if in the "RequestMetadata"
element). Specifies the value that was stored in the
Differentiated Services (DS) field in the traceroute
probe (if in the "MeasurementMetadata" element). The DS
field is defined as the Type of Service (TOS) octet in an
IPv4 header or as the Traffic Class octet in an IPv6
header (see Section 7 of [RFC2460]). The value of this
object must be a decimal integer in the range from 0 to
255. This option can be used to determine what effect an
explicit DS field setting has on a traceroute measurement
and its probes. Not all values are legal or meaningful.
Useful TOS octet values are probably 16 (low delay) and
8 (high throughput). Further references can be found in
[RFC2474] for the definition of the Differentiated
Services (DS) field and in [RFC1812] Section 5.3.2 for
Type of Service (TOS).</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="CtlSourceAddress"
type="tr:inetAddressWithoutDns">
<xs:annotation>
<xs:documentation>Specifies the IP address (which has to
be given as an IP number, not a hostname) as the source
address in traceroute probes (requested if in the
"RequestMetadata" element, actually used if in the
"MeasurementMetadata" element). On hosts with more than
one IP address, this option can be used in the
"RequestMetadata" element to force the source address to
be something other than the primary IP address of the
interface the probe is sent on; the value "unknown" means
the default address will be used. The address type can be
determined by examining the "inetAddress" type name and the
corresponding element value.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="0" name="CtlIfIndex"
type="xs:unsignedInt">
<xs:annotation>
<xs:documentation>Specifies the interface index as
defined in [RFC2863] that is requested to be used in the
traceroute measurement for sending the traceroute probes
(if in the "RequestMetadata" element). A value of 0
indicates that no specific interface is requested.
Specifies the interface index actually used (if in the
"MeasurementMetadata" element).</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element minOccurs="0" name="CtlMiscOptions"
type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies implementation-dependent
options (requested if in the "RequestMetadata" element,
actually used if in the "MeasurementMetadata"
element).</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="5" name="CtlMaxFailures"
type="xs:unsignedByte">
<xs:annotation>
<xs:documentation>Specifies the maximum number of
consecutive timeouts allowed before terminating a
traceroute measurement (requested if in the
"RequestMetadata" element, actually used if in the
"MeasurementMetadata" element). A value of either 255
(maximum hop count/possible TTL value) or 0 indicates
that the function of terminating a remote traceroute
measurement when a specific number of consecutive
timeouts are detected was disabled. This element is
included to give full compatibility with [RFC4560]. No
known implementation of traceroute currently supports
it.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="false" name="CtlDontFragment"
type="xs:boolean">
<xs:annotation>
<xs:documentation>Specifies if the don't fragment (DF)
flag in the IP header for a probe was enabled or not (if
in the "MeasurementMetadata" element). If in the
"RequestMetadata", it specifies if the flag was requested
to be enabled or not. Setting the DF flag can be used for
performing a manual PATH MTU test.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="1" name="CtlInitialTtl"
type="tr:u8nonzero">
<xs:annotation>
<xs:documentation>Specifies the initial TTL value for a
traceroute measurement (requested if in the
"RequestMetadata" element, actually used if in the
"MeasurementMetadata" element). Such TTL setting is
intended to bypass the initial (often well-known) portion
of a path.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element maxOccurs="1" minOccurs="0" name="CtlDescr"
type="tr:string255">
<xs:annotation>
<xs:documentation>Provides a description of the traceroute
measurement.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="CtlType" type="tr:_CtlType">
<xs:annotation>
<xs:documentation>Specifies the implementation method
used for the traceroute measurement (requested if in the
"RequestMetadata" element, actually used if in the
"MeasurementMetadata" element). It specifies if the
traceroute is using TCP, UDP, ICMP, or other types of
probes. It is possible to specify other types of probes
by using an element specified in another schema with a
different namespace.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="_Measurement">
<xs:annotation>
<xs:documentation>Contains the actual traceroute measurement
results.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="TestName" type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies the name of a traceroute
measurement. This is not necessarily unique within any
well-defined scope (e.g., a specific host, initiator of
the traceroute measurement).</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="ResultsStartDateAndTime" type="xs:dateTime">
<xs:annotation>
<xs:documentation>Specifies the date and start time of
the traceroute measurement. This is the time when the
first probe was seen at the sending
interface.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="ResultsIpTgtAddr"
type="tr:inetAddressWithoutDns">
<xs:annotation>
<xs:documentation>Specifies the IP address associated
with a "CtlTargetAddress" value when the destination
address is specified as a DNS name. The value of this
object should be "unknown" if a DNS name is not specified
or if a specified DNS name fails to resolve. The
address type can be determined by examining the "inetAddress"
type name and the corresponding element
value.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="ProbeResults" type="tr:_ProbeResults"/>
<xs:element name="ResultsEndDateAndTime" type="xs:dateTime">
<xs:annotation>
<xs:documentation>Specifies the date and end time of the
traceroute measurement. It is either the time when the
response to the last probe of the traceroute measurement
was received or the time when the last probe of the
traceroute measurement was sent plus the relative timeout
(in case of a missing response).</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="traceRoute">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="RequestMetadata"
type="tr:_Metadata"/>
<xs:element maxOccurs="2147483647" minOccurs="0"
name="Measurement">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="MeasurementMetadata"
type="tr:_Metadata"/>
<xs:element maxOccurs="2147483647" minOccurs="0"
name="MeasurementResult"
type="tr:_Measurement"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
8. Security Considerations
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.
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.
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.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4560] Quittek, J. and K. White, "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", RFC 4560, June 2006. [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.10.2. Informative References
[IEEE.1003-1G.1997] Institute of Electrical and Electronics Engineers, "Protocol Independent Interfaces", IEEE Standard 1003.1G, March 1997. [IPFIX] Sadasivan, G., "Architecture for IP Flow Information Export", Work in Progress, September 2006. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008. [W3C.REC-xml-20060816] Bray, T., Paoli, J., Maler, E., Sperberg-McQueen, C., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium FirstEdition REC-xml- 20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816>. [W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
Appendix A. Traceroute Default Configuration Parameters
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 |
+--------+------+-------------------------------+---------+
| LINUX | N/A |Specify a loose source route | - |
|--------+------|gateway (to direct the |---------|
| FreeBSD| -g |traceroute probes through | - |
|--------+------|routers not necessarily in |---------|
| UNIX | -g | the path). | - |
|--------+------| |---------|
| WINDOWS| -g | | - |
+--------+------+-------------------------------+---------+
| LINUX | -p |Set the base UDP port number | 33434 |
|------- +------|used in traceroute probes |---------|
| FreeBSD| -p |(UDP port = base + nhops - 1). | 33434 |
|--------+------| |---------|
| UNIX | -p | | 33434 |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | -q |Set the number of probes per | 3 |
|--------+------|TTL. |---------|
| FreeBSD| -q | | 3 |
|--------+------| |---------|
| UNIX | -q | | 3 |
|--------+------| |---------|
| WINDOWS| N/A | | 3 |
+--------+------+-------------------------------+---------+
| LINUX | -S |Set the IP source address in |IP |
|--------+------|outgoing probes to the |address |
| FreeBSD| -s |specified value. |of the |
|--------+------| |out |
| UNIX | -s | |interface|
|--------+------| | |
| WINDOWS| N/A | | |
+--------+------+-------------------------------+---------+
| LINUX | -t |Set the Type of Service (TOS) | 0 |
|--------+------|in the probes to the specified |---------|
| FreeBSD| -t |value. | 0 |
|--------+------| |---------|
| UNIX | -t | | 0 |
|--------+------| |---------|
| WINDOWS| N/A | | 0 |
+--------+------+-------------------------------+---------+
| LINUX | -v |Verbose output: received ICMP | - |
|--------+------|packets other than |---------|
| FreeBSD| -v |TIME_EXCEEDED and | - |
|--------+------|UNREACHABLE are listed. |---------|
| UNIX | -v | | - |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | N/A |Set the time (in msec) to | - |
|--------+------|pause between probes. |---------|
| FreeBSD| -z | | 0 |
|--------+------| |---------|
| UNIX | -P | | 0 |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | -r |Bypass the normal routing | - |
|--------+------|tables and send directly to a |---------|
| FreeBSD| -r |host on attached network. | - |
|--------+------| |---------|
| UNIX | -r | | - |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | -f |Set the initial TTL for the | 1 |
|--------+------|first probe. |---------|
| FreeBSD| -f | | 1 |
|--------+------| |---------|
| UNIX | -f | | 1 |
|--------+------| |---------|
| WINDOWS| N/A | | 1 |
+--------+------+-------------------------------+---------+
| LINUX | -F |Set the "don't fragment" bit. | - |
|--------+------| |---------|
| FreeBSD| -F | | - |
|--------+------| |---------|
| UNIX | -F | | - |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | N/A |Enable socket level debugging. | - |
|--------+------| |---------|
| FreeBSD| -d | | - |
|--------+------| |---------|
| UNIX | -d | | - |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | N/A |Use ICMP Echoes instead of UDP | - |
|--------+------|datagrams. |---------|
| FreeBSD| -I | | - |
|--------+------| |---------|
| UNIX | -I | | - |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | -I |Specify a network interface to | - |
|--------+------|obtain the IP address for |---------|
| FreeBSD| -i |outgoing IP packets | - |
|--------+------|(alternative to option -s). |---------|
| UNIX | -i | | - |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | N/A |Toggle checksum. | - |
|--------+------| |---------|
| FreeBSD| -x | | - |
|--------+------| |---------|
| UNIX | -x | | - |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | - |As optional last parameter, |Depends |
|--------+------|LINUX, FreeBSD, and UNIX |on |
| FreeBSD| - |implementations allow |implement|
|--------+------|specifying the probe datagram |ation. |
| UNIX | - |length for outgoing probes. | |
|--------+------| | |
| WINDOWS| N/A | | |
+--------+------+-------------------------------+---------+
A.1. Alternative Traceroute Implementations
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.
(next page on part 3)