idnits 2.17.1 draft-ietf-ippm-storetraceroutes-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3378. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1865 has weird spacing: '...A |Set the t...' == Line 2857 has weird spacing: '... <1 ms r1.pr...' == Line 2858 has weird spacing: '... <1 ms rtr8....' == Line 2859 has weird spacing: '... 1 ms hop11...' == Line 2860 has weird spacing: '... 1 ms sw6.p...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 8, 2008) is 5672 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '1-9' is mentioned on line 998, but not defined == Missing Reference: '0-9' is mentioned on line 998, but not defined == Missing Reference: '0-4' is mentioned on line 998, but not defined == Missing Reference: '0-5' is mentioned on line 998, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group S. Niccolini 3 Internet-Draft S. Tartarelli 4 Intended status: Standards Track J. Quittek 5 Expires: April 11, 2009 T. Dietz 6 NEC 7 M. Swany 8 UDel 9 October 8, 2008 11 Information Model and XML Data Model for Traceroute Measurements 12 draft-ietf-ippm-storetraceroutes-11 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 11, 2009. 39 Abstract 41 This document describes a standard way to store the configuration and 42 the results of traceroute measurements. This document first of all 43 describes the terminology used in this document and the traceroute 44 tool itself; afterwards, the common information model is defined 45 dividing the information elements in two semantically separated 46 groups (configuration elements and results elements). Moreover an 47 additional element is defined to relate configuration elements and 48 results elements by means of a common unique identifier. On the 49 basis of the information model a data model based on XML is defined 50 to store the results of traceroute measurements. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology used in this document . . . . . . . . . . . . . . 3 56 3. The Traceroute tool and its operations . . . . . . . . . . . . 4 57 4. Results of traceroute measurements . . . . . . . . . . . . . . 4 58 5. Information Model for Traceroute Measurements . . . . . . . . 5 59 5.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.2. Information Elements . . . . . . . . . . . . . . . . . . . 7 61 5.2.1. Relationship between the Information Elements . . . . 7 62 5.2.2. Configuration Information Elements . . . . . . . . . . 10 63 5.2.3. Results Information Elements . . . . . . . . . . . . . 15 64 5.2.4. Information Element Correlating Configuration and 65 Results Elements . . . . . . . . . . . . . . . . . . . 18 66 5.2.5. Information Elements to compare traceroute 67 measurements results one with each other . . . . . . . 18 68 6. Data Model for Storing Traceroute Measurements . . . . . . . . 19 69 7. XML Schema for traceroute Measurements . . . . . . . . . . . . 20 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 71 8.1. Conducting Traceroute Measurements . . . . . . . . . . . . 35 72 8.2. Securing Traceroute Measurements Information . . . . . . . 36 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 36 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 37 77 Appendix A. Traceroute Default Configuration Parameters . . . . . 38 78 A.1. Alternative Traceroute Implementations . . . . . . . . . . 41 79 Appendix B. Known Problems with Traceroute . . . . . . . . . . . 42 80 B.1. Compatibility between traceroute measurements results 81 and IPPM metrics . . . . . . . . . . . . . . . . . . . . . 42 82 Appendix C. Differences to DISMAN-TRACEROUTE-MIB . . . . . . . . 42 83 C.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 43 84 C.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 44 85 C.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 45 86 C.4. Additional Information Elements . . . . . . . . . . . . . 45 87 Appendix D. Traceroute Examples with XML representation . . . . . 45 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 89 Intellectual Property and Copyright Statements . . . . . . . . . . 72 91 1. Introduction 93 Traceroutes are being used by lots of measurement efforts, either as 94 an independent measurement or to get path information to support 95 other measurement efforts. That is why there is the need to 96 standardize the way the configuration and the results of traceroute 97 measurements are stored. The standard metrics defined by the IPPM 98 working group in matter of delay, connectivity and losses do not 99 apply to the metrics returned by the traceroute tool; therefore, in 100 order to compare results of traceroute measurements, the only 101 possibility is to add to the stored results a specification of the 102 operating system as well as name and version for the traceroute tool 103 used. This document, in order to store results of traceroute 104 measurements and allow comparison of them, defines a standard way to 105 store them using a XML schema. The document is organized as follows: 106 Section 2 defines the terminology used in this document, Section 3 107 describes the traceroute tool, Section 4 describes the results of a 108 traceroute measurement as displayed to the screen from which the 109 traceroute tool was launched. Section 5 and Section 6 respectively 110 describe the information model and data model for storing 111 configuration and results of the traceroute measurements. Section 7 112 contains the XML schema to be used as a template for storing and/or 113 exchanging traceroute measurements information. The document ends 114 with security considerations and IANA considerations in Section 8 and 115 Section 9 respectively. 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2. Terminology used in this document 123 The terminology used in this document is defined as follow: 124 o traceroute tool: a software tool for network diagnostic behaving 125 as described in Section 3; 126 o traceroute measurement: an instance of the traceroute tool 127 launched, with specific configuration parameters (traceroute 128 measurement configuration parameters), from a specific host 129 (initiator of the traceroute measurement) giving as output 130 specific traceroute measurement results; 131 o traceroute probe: one of many IP packets send out by the 132 traceroute tool during a traceroute measurement; 133 o traceroute measurement configuration parameters: the configuration 134 parameters of a traceroute measurement; 135 o traceroute measurement results: the results of a traceroute 136 measurement; 138 o traceroute measurement information: both the results and the 139 configuration parameters of a traceroute measurement; 140 o traceroute measurement path: a sequence of hosts transited in 141 order by traceroute probes during a traceroute measurement; 143 3. The Traceroute tool and its operations 145 Traceroute is a network diagnostic tool used to determine the hop by 146 hop path from a source to a destination and the Round Trip Time (RTT) 147 from the source to each hop. Traceroute can be therefore used to 148 discover some information (hop counts, delays, etc.) about the path 149 between the initiator of the traceroute measurement and other hosts. 151 Typically, the traceroute tool attempts to discover the path to a 152 destination by sending UDP probes with specific time-to-live (TTL) 153 values in the IP packet header and trying to elicit an ICMP 154 TIME_EXCEEDED response from each gateway along the path to some host. 156 More in detail, a first set of probes with TTL equal to 1 are sent by 157 the traceroute tool from the host initiating the traceroute 158 measurement (some tool implementations allow setting the initial TTL 159 to a value equal to "n" different from 1, so that the first "n-1" 160 hops are skipped and the first hop that will be traced is the "n-th" 161 in the path). Upon receiving a probe, the first hop host decreases 162 the TTL value (by one or more). By observing a TTL value equal to 163 zero, the host rejects the probe and typically returns an ICMP 164 message with a TIME_EXCEEDED value. The traceroute tool can 165 therefore derive the IP address of the first hop from the header of 166 the ICMP message and evaluate the RTT between the host initiating the 167 traceroute measurement and the first hop. The next hops are 168 discovered following the same procedure, taking care of increasing at 169 each step the TTL value of the probes by one. The TTL value is 170 increased until either an ICMP PORT_UNREACHABLE message is received, 171 meaning that the destination host has been reached, or the maximum 172 configured number of hops has been hit. 174 Some implementations, use ICMP Echoes, instead of UDP datagrams. 175 However, many routers do not return ICMP messages about ICMP 176 messages, i.e. no ICMP TIME_EXCEEDED is returned for an ICMP Echo. 177 Therefore, this document recommends to base implementations on UDP 178 datagrams. Considerations on TCP-based implementations of the 179 traceroute tool are reported in Appendix A.1. 181 4. Results of traceroute measurements 183 The following list reports the information fields provided as results 184 by all traceroute tool implementations considered. The order in 185 which they are reported here is not relevant and it changes in 186 different implementations. For each hop the information reported is: 187 o the hop index; 188 o the host symbolic address, provided that at least one of the 189 probes received a response, the symbolic address could be resolved 190 at the corresponding host and that the option to display only 191 numerical addresses was not set; 192 o the host IP address, provided that at least one of the probes 193 received a response; 194 o the RTT for each response to a probe. 195 Depending on the traceroute tool implementation, additional 196 information might be displayed in the output (for instance MPLS- 197 related information). 199 It might happen that some probes do not receive a response within the 200 configured time-out (for instance if the probe is filtered out by a 201 firewall). In this case, an "*" is displayed in place of the RTT. 202 The information model reflects this using a string with the value of 203 "RoundTripTimeNotAvailable" meaning either the probe was lost because 204 of a time-out or it was not possible to transmit a probe. It may 205 also happen that some implementations print the same line multiple 206 times when a router decreases the TTL by more than one looking like 207 multiple hops, the information model is not impacted by this since 208 each line is handled separately and it is left to the applications 209 handling the XML file how to deal with it. Moreover, for delays 210 below 1 ms, some implementations reports 0 ms (e.g. UNIX and LINUX) 211 while WINDOWS tracert reports "< 1 ms". 213 5. Information Model for Traceroute Measurements 215 The information model is composed of information elements; for 216 defining these information elements, a template is used. Such 217 template is specified in the list below: 219 o name - A unique and meaningful name for the information element. 220 The preferred spelling for the name is to use mixed case if the 221 name is compound, with an initial lower case letter, e.g., 222 "sourceIpAddress". 223 o description - The semantics of this information element. 224 o dataType - One of the types listed in Section 5.1 of this document 225 or in an extension of the information model. The type space for 226 attributes is constrained to facilitate implementation. 227 o units - If the element is a measure of some kind, the units 228 identify what the measure is. 230 5.1. Data Types 232 This section describes the set of basic valid data types of the 233 information model. 235 o String - The type "String" represents a finite length string of 236 valid characters from the Unicode character encoding set. Unicode 237 allows for ASCII and many other international character sets to be 238 used. It is expected that strings will be encoded in UTF-8 239 format, which is identical in encoding for USASCII characters, but 240 also accommodates other Unicode multi-byte characters. 241 o String255 - Same type as "String" but with the restriction to 255 242 characters. 243 o InetAddressType - The type "InetAddressType" represents a type of 244 Internet address. The allowed values are to be intended as 245 imported from [RFC4001] (where the intent was to import only some 246 of the values); additional allowed value are "asnumber" and 247 "noSpecification". 248 o InetAddress - The type "InetAddress" denotes a generic Internet 249 address. The allowed values are imported from [RFC4001] (the 250 values imported are unknown, ipv4, ipv6 and dns), while non-global 251 IPv4/IPv6 addresses (e.g. ipv4z and ipv6z) were excluded; an 252 additional allowed value is the AS number to be indicated as the 253 actual number plus the indication how the mapping from IP address 254 to AS number was performed. "unknown" is used to indicate an IP 255 address that is not in one of the formats defined. 256 o ipASNumberMappingType - The type "ipASNumberMappingType" 257 represents a type of mapping from IP to AS number, it indicated 258 the method that was used to do get the mapping (allowed values are 259 "bgptables", "routingregistries", "nslookup", "others" or 260 "unknown"). 261 o Boolean - The type "boolean" represents a Boolean value according 262 to XML standards [XML]. 263 o UnsignedInt - The type "UnsignedInt" represents a value in the 264 range (0..4294967295). 265 o UnsignedShort - The type "UnsignedShort" represents a value in the 266 range (0..65535). 267 o UnsignedByte - The type "UnsignedByte" represents a value in the 268 range (0..255). 269 o u8nonzero - The type "u8nonzero" represents a value in the range 270 (1..255). 271 o ProbesType - The type "ProbesType" represents a way of indicating 272 the protocol used for the traceroute probes. Values defined in 273 this document are UDP, TCP and ICMP. 274 o OperationResponseStatus - The type "OperationResponseStatus" is 275 used to report the result of an operation. The allowed values are 276 to be intended as imported from [RFC4560]. 278 o dateTime - The type "dateTime" represents a date-time 279 specification according to XML standards [XML] but restricted to 280 the values defined in [RFC3339]. 282 5.2. Information Elements 284 This section describes the elements related to the storing of a 285 traceroute measurement. The elements are grouped in two groups 286 (Configuration and Results) according to their semantics. In order 287 to relate configuration and results elements by means of a common 288 unique identifier, an additional element is defined belonging to both 289 the two groups. 291 5.2.1. Relationship between the Information Elements 293 Every traceroute measurement is represented by an instance of the 294 "traceRoute" element. This class provides a standardized 295 representation for traceroute measurement data. The "traceroute" 296 element is an element that can be composed of (depending on the 297 nature of the traceroute measurement): 299 o 1 optional "RequestMetadata" element; 300 o 0..4294967295 "Measurement" elements; 302 Each "Measurement" element contains: 304 o 1 optional "MeasurementMetadata" element; 305 o 0..4294967295 "MeasurementResult" elements; 307 The "RequestMetadata" element can be used for specifying parameters 308 of a traceroute measurement to be performed at one or more nodes by 309 one or more traceroute implementations. Depending on the 310 capabilities of a traceroute implementation, not all requested 311 parameters can be applied. Which parameters have actually been 312 applied by for specific traceroute measurement is specified in a 313 "MeasurementMetadata" element. 315 The "RequestMetadata" element is a sequence that contains: 317 o 1 "TestName" element; 318 o 1 optional "ToolVersion" element; 319 o 1 optional "ToolName" element; 320 o 1 "CtlTargetAddress" element; 321 o 1 optional "CtlBypassRouteTable" element; 322 o 1 optional "CtlProbeDataSize" element; 323 o 1 optional "CtlTimeOut" element; 324 o 1 optional "CtlProbesPerHop" element; 325 o 1 optional "CtlPort" element; 326 o 1 optional "CtlMaxTtl" element; 327 o 1 optional "CtlDSField" element; 328 o 1 optional "CtlSourceAddress" element; 329 o 1 optional "CtlIfIndex" element; 330 o 1 optional "CtlMiscOptions" element; 331 o 1 optional "CtlMaxFailures" element; 332 o 1 optional "CtlDontFragment" element; 333 o 1 optional "CtlInitialTtl" element; 334 o 1 optional "CtlDescr" element; 335 o 1 "CtlType" element; 337 If the "RequestMetadata" element is omitted from an XML file then it 338 means that the traceroute measurement configuration parameters 339 requested were all used and the "MeasurementMetadata" element list 340 them in detail. 342 The "MeasurementMetadata" element is a sequence that contains: 344 o 1 "TestName" element; 345 o 1 "OSName" element; 346 o 1 "OSVersion" element; 347 o 1 "ToolVersion" element; 348 o 1 "ToolName" element; 349 o 1 "CtlTargetAddressType" element; 350 o 1 "CtlTargetAddress" element; 351 o 1 "CtlBypassRouteTable" element; 352 o 1 "CtlProbeDataSize" element; 353 o 1 "CtlTimeOut" element; 354 o 1 "CtlProbesPerHop" element; 355 o 1 "CtlPort" element; 356 o 1 "CtlMaxTtl" element; 357 o 1 "CtlDSField" element; 358 o 1 "CtlSourceAddressType" element; 359 o 1 "CtlSourceAddress" element; 360 o 1 "CtlIfIndex" element; 361 o 1 optional "CtlMiscOptions" element; 362 o 1 "CtlMaxFailures" element; 363 o 1 "CtlDontFragment" element; 364 o 1 "CtlInitialTtl" element; 365 o 1 optional "CtlDescr" element; 366 o 1 "CtlType" element; 368 Configuration Information Elements can describe not just traceroute 369 measurements that have already happened ("MeasurementMetadata" 370 elements), but also configuration to be used when requesting a 371 measurement to be made ("RequestMetadata" element). This is quite 372 different semantically, even if the individual information elements 373 are similar. Due to this similarity both "RequestMetadata" as well 374 as "MeasurementMetadata" are represented by the same type in the XML 375 schema. All elements that are missing from the "RequestMetadata" or 376 marked as optional in the "RequestMetadata" but mandatory in the 377 "MeasurementMetadata" must be specified as empty elements. 378 Specifying them as empty elements means use the default value. The 379 "CtlType" element could have been optional in the "RequestMetadata" 380 but since default values cannot be specified for complex types in an 381 XML schema the element is mandatory also in the "RequestMetadata". 383 The "MeasurementResult" element is a sequence that contains: 385 o 1 "TestName" element; 386 o 1 "ResultsStartDateAndTime" element; 387 o 1 "ResultsIpTgtAddrType" element; 388 o 1 "ResultsIpTgtAddr" element; 389 o 1 "ProbeResults" elements; 390 o 1 "ResultsEndDateAndTime" element; 392 Additionally it is important to say that each "ProbeResults" element 393 is a sequence that contains: 395 o 1..255 "hop" elements; 397 Each "hop" element is a sequence that contains 399 o 1..10 "probe" elements; 400 o 1 optional "HopRawOutputData" element; 402 Each "probe" element contains: 404 o 1 "HopAddrType" element; 405 o 1 "HopAddr" element; 406 o 1 optional "HopName" element; 407 o 0..255 optional "MPLSLabelStackEntry" elements; 408 o 1 "ProbedRoundTripTime" element; 409 o 1 "ResponseStatus" element; 410 o 1 "Time" element; 412 Different numbers of appearances of the three basic elements in the 413 XML file are meant for different scopes: 415 o a file with only 1 "RequestMetadata" element represents a file 416 containing the traceroute measurement configuration parameters of 417 a traceroute measurement, it can be used to distribute the 418 traceroute measurement configuration parameters over multiple 419 nodes asked to run the same traceroute measurement; 421 o a file with 1 "Measurement element containing 1 422 "MeasurementMetadata" and 1 "MeasurementResult" element represents 423 a file containing the traceroute measurement information of a 424 traceroute measurement; 425 o a file with 1 "Measurement element containing 1 426 "MeasurementMetadata" and n "MeasurementResult" elements 427 represents a file containing the traceroute measurement 428 information of a set of traceroute measurements run over different 429 times with always the same traceroute measurement configuration 430 parameters; 431 o a file with 1 "RequestMetadata" and 1 "Measurement element 432 containing 1 "MeasurementMetadata" and 1 "Measurement" element 433 represents a file containing the traceroute measurement 434 information of a traceroute measurement (containing both the 435 requested traceroute measurement configuration parameters and the 436 ones actually used); 437 o other combinations are possible to store multiple traceroute 438 measurements all in one XML file. 440 5.2.2. Configuration Information Elements 442 This section describes the elements specific to the configuration of 443 the traceroute measurement (belonging to both "RequestMetadata" and 444 "MeasurementMetadata" elements). 446 5.2.2.1. CtlTargetAddressType 448 o name - CtlTargetAddressType 449 o description - Specifies the type of address in the corresponding 450 CtlTargetAddress element. This element is not directly reflected 451 in the XML Schema of Section 7. The host address type can be 452 determined by examining the inetAddress type name and the 453 corresponding element value. 454 o dataType - InetAddressType 455 o units - N/A 457 5.2.2.2. CtlTargetAddress 459 o name - CtlTargetAddress 460 o description - In the "RequestMetadata" element it specifies the 461 host address requested to be used in the traceroute measurement. 462 In the "MeasurementMetadata" element it specifies the host address 463 used in the traceroute measurement. 464 o dataType - InetAddress 465 o units - N/A 467 5.2.2.3. CtlBypassRouteTable 469 o name - CtlBypassRouteTable 470 o description - In the "RequestMetadata" element specifies if it is 471 requested to enable the optional bypassing of the route table or 472 not. In the "MeasurementMetadata" element, specifies if the 473 optional bypassing of the route table was enabled or not. If 474 enabled, the normal routing tables will be bypassed and the probes 475 will be sent directly to a host on an attached network. If the 476 host is not on a directly-attached network, an error is returned. 477 This option can be used to perform the traceroute measurement to a 478 local host through an interface that has no route defined. This 479 object can be used when the setsockopt SOL_SOCKET SO_DONTROUTE 480 option is supported and set (see [IEEE.1003-1G.1997]). 481 o dataType - Boolean 482 o units - N/A 484 5.2.2.4. CtlProbeDataSize 486 o name - CtlProbeDataSize 487 o description - Specifies the size of the probes of a traceroute 488 measurement in octets (requested if in the "RequestMetadata" 489 element, actually used if in the "MeasurementMetadata" element). 490 If UDP datagrams are used as probes, then the value contained in 491 this object is exact. If another protocol is used to transmit 492 probes (i.e. TCP or ICMP) for which the specified size is not 493 appropriate, then the implementation can use whatever size 494 (appropriate to the method) is closest to the specified size. The 495 maximum value for this object was computed by subtracting the 496 smallest possible IP header size of 20 octets (IPv4 header with no 497 options) and the UDP header size of 8 octets from the maximum IP 498 packet size. An IP packet has a maximum size of 65535 octets 499 (excluding IPv6 Jumbograms). 500 o dataType - UnsignedShort 501 o units - octets 503 5.2.2.5. CtlTimeOut 505 o name - CtlTimeOut 506 o description - Specifies the time-out value, in seconds, for each 507 probe of a traceroute measurement (requested if in the 508 "RequestMetadata" element, actually used if in the 509 "MeasurementMetadata" element). 510 o dataType - UnsignedByte 511 o units - seconds 513 5.2.2.6. CtlProbesPerHop 515 o name - CtlProbesPerHop 516 o description - Specifies the number of probes with the same time- 517 to-live (TTL) value that are sent for each host (requested if in 518 the "RequestMetadata" element, actually used if in the 519 "MeasurementMetadata" element). 520 o dataType - UnsignedByte 521 o units - probes 523 5.2.2.7. CtlPort 525 o name - CtlPort 526 o description - Specifies the base port used by the traceroute 527 measurement (requested if in the "RequestMetadata" element, 528 actually used if in the "MeasurementMetadata" element). 529 o dataType - UnsignedShort 530 o units - port number 532 5.2.2.8. CtlMaxTtl 534 o name - CtlMaxTtl 535 o description - Specifies the maximum TTL value for the traceroute 536 measurement (requested if in the "RequestMetadata" element, 537 actually used if in the "MeasurementMetadata" element). 538 o dataType - u8nonzero 539 o units - time-to-live value 541 5.2.2.9. CtlDSField 543 o name - CtlDSField 544 o description - Specifies the value that was requested to be stored 545 in the Differentiated Services (DS) field in the traceroute probe 546 (if in the "RequestMetadata" element). Specifies the value that 547 was stored in the Differentiated Services (DS) field in the 548 traceroute probe (if in the "MeasurementMetadata" element). The 549 DS Field is defined as the Type of Service (TOS) octet in a IPv4 550 header or as the Traffic Class octet in a IPv6 header (see section 551 7 of [RFC2460]). The value of this object must be a decimal 552 integer in the range from 0 to 255. This option can be used to 553 determine what effect an explicit DS field setting has on a 554 traceroute measurement and its probes. Not all values are legal 555 or meaningful. Useful TOS octet values are probably '16' (low 556 delay) and '8' (high throughput). Further references can be found 557 in [RFC2474] for the definition of the Differentiated Services 558 (DS) field and to [RFC1812] Section 5.3.2 for Type of Service 559 (TOS). 561 o dataType - UnsignedByte 562 o units - N/A 564 5.2.2.10. CtlSourceAddressType 566 o name - CtlSourceAddressType 567 o description - Specifies the type of address in the corresponding 568 CtlSourceAddress element. This element is not directly reflected 569 in the XML Schema of Section 7. The host address type can be 570 determined by examining the inetAddress type name and the 571 corresponding element value. DNS names are not allowed for the 572 CtlSourceAddress. 573 o dataType - InetAddressType 574 o units - N/A 576 5.2.2.11. CtlSourceAddress 578 o name - CtlSourceAddress 579 o description - Specifies the IP address (which has to be given as 580 an IP number, not a hostname) as the source address in traceroute 581 probes (requested if in the "RequestMetadata" element, actually 582 used if in the "MeasurementMetadata" element). On hosts with more 583 than one IP address, this option can be used in "RequestMetadata" 584 element to force the source address to be something other than the 585 primary IP address of the interface the probe is sent on; the 586 value "unknown" means the default address will be used. 587 o dataType - InetAddress 588 o units - N/A 590 5.2.2.12. CtlIfIndex 592 o name - CtlIfIndex 593 o description - Specifies the interface index as defined in 594 [RFC2863] that is requested to be used in the traceroute 595 measurement for sending the traceroute probes (if in the 596 "RequestMetadata" element). A value of 0 in the "RequestMetadata" 597 indicates that no specific interface is requested. Specifies the 598 one actually used if in the "MeasurementMetadata" element. 599 o dataType - UnsignedInt 600 o units - N/A 602 5.2.2.13. CtlMiscOptions 604 o name - CtlMiscOptions 605 o description - Specifies implementation dependent options 606 (requested if in the "RequestMetadata" element, actually used if 607 in the "MeasurementMetadata" element). 609 o dataType - String255 610 o units - N/A 612 5.2.2.14. CtlMaxFailures 614 o name - CtlMaxFailures 615 o description - Specifies the maximum number of consecutive timeouts 616 allowed before terminating a traceroute measurement (requested if 617 in the "RequestMetadata" element, actually used if in the 618 "MeasurementMetadata" element). A value of either 255 (maximum 619 hop count/possible TTL value) or a 0 indicates that the function 620 of terminating a remote traceroute measurement when a specific 621 number of consecutive timeouts are detected was disabled. This 622 element is included to give full compatibility with [RFC4560]. No 623 known implementation of traceroute currently supports it. 624 o dataType - Unsigned8 625 o units - timeouts 627 5.2.2.15. CtlDontFragment 629 o name - CtlDontFragment 630 o description - Specifies if the don't fragment flag (DF) in the IP 631 header for a probe was enabled or not (if in the 632 "MeasurementMetadata" element). If in the "RequestMetadata", it 633 specifies if the flag was requested to be enable or not. Setting 634 the DF flag can be used for performing a manual PATH MTU test. 635 o dataType - Boolean 636 o units - N/A 638 5.2.2.16. CtlInitialTtl 640 o name - CtlInitialTtl 641 o description - Specifies the initial TTL value for a traceroute 642 measurement (requested if in the "RequestMetadata" element, 643 actually used if in the "MeasurementMetadata" element). Such TTL 644 setting is intended to bypass the initial (often well known) 645 portion of a path. 646 o dataType - u8nonzero 647 o units - N/A 649 5.2.2.17. CtlDescr 651 o name - CtlDescr 652 o description - The purpose of this element is to provide a 653 description of the traceroute measurement. 654 o dataType - String255 655 o units - N/A 657 5.2.2.18. CtlType 659 o name - CtlType 660 o description - Specifies the implementation method used for the 661 traceroute measurement (requested if in the "RequestMetadata" 662 element, actually used if in the "MeasurementMetadata" element). 663 It specifies if the traceroute is using TCP, UDP, ICMP or other 664 type of probes. It is possible to specify other types of probes 665 by using an element specified in another schema with a different 666 namespace. 667 o dataType - ProbesType 668 o units - N/A 670 5.2.3. Results Information Elements 672 This section describes the elements specific to the results of the 673 traceroute measurement. 675 5.2.3.1. ResultsStartDateAndTime 677 o name - ResultsStartDateAndTime 678 o description - Specifies the date and start time of the traceroute 679 measurement. This is the time when the first probe was seen at 680 the sending interface. 681 o dataType - DateTime 682 o units - N/A 684 5.2.3.2. ResultsIpTgtAddrType 686 o name - ResultsIpTgtAddrType 687 o description - Specifies the type of address in the corresponding 688 ResultsIpTgtAddr element. This element is not directly reflected 689 in the XML Schema of Section 7. The host address type can be 690 determined by examining the inetAddress type name and the 691 corresponding element value. 692 o dataType - InetAddressType 693 o units - N/A 695 5.2.3.3. ResultsIpTgtAddr 697 o name - ResultsIpTgtAddr 698 o description - Specifies the IP address associated with a 699 CtlTargetAddress value when the destination address is specified 700 as a DNS name. The value of this object should be "unknown" if a 701 DNS name is not specified or when a specified DNS name fails to 702 resolve. 704 o dataType - InetAddress 705 o units - N/A 707 5.2.3.4. HopAddrType 709 o name - HopAddrType 710 o description - Specifies the type of address in the corresponding 711 HopAddr element. This element is not directly reflected in the 712 XML Schema of Section 7. The host address type can be determined 713 by examining the inetAddress type name and the corresponding 714 element value. DNS names are not allowed for HopAddr. 715 o dataType - InetAddressType 716 o units - N/A 718 5.2.3.5. HopAddr 720 o name - HopAddr 721 o description - Specifies the address of a hop in the traceroute 722 measurement path. This object is not allowed to be a DNS name. 723 o dataType - InetAddress 724 o units - N/A 726 5.2.3.6. HopName 728 o name - HopName 729 o description - Specifies the DNS name of the HopAddr if it is 730 available. If it is not available the element is omitted. 731 o dataType - InetAddress 732 o units - N/A 734 5.2.3.7. MPLSLabelStackEntry 736 o name - MPLSLabelStackEntry 737 o description - Specifies entries of the MPLS label stack of a probe 738 observed when the probe arrived at the hop that replied to the 739 probe. This object contains one MPLS label stack entry as 32 bit 740 value as it is observed on the MPLS label stack. Contained in 741 this single number are the MPLS label, the Exp field, the S flag, 742 and the MPLS TTL value as specified in [RFC3032]. If more than 743 one MPLS label stack entry is reported then multiple instances of 744 elements of this type are used. They must be ordered in the same 745 order as on the label stack with the top label stack entry being 746 reported first. 747 o dataType - UnsignedInt 748 o units - N/A 750 5.2.3.8. ProbeRoundTripTime 752 o name - ProbeRoundTripTime 753 o description - If this element contains the element roundTripTime 754 this specifies the amount of time measured in milliseconds from 755 when a probe was sent to when its response was received or when it 756 timed out. The value of this element is reported as the 757 truncation of the number reported by the traceroute tool (the 758 output "< 1 ms" is therefore encoded as 0 ms). If it contains the 759 element "roundTripTimeNotAvaiable" it means either the probe was 760 lost because of a timeout or it was not possible to transmit a 761 probe. 762 o dataType - UnsignedShort or String 763 o units - milliseconds or N/A 765 5.2.3.9. ResponseStatus 767 o name - ResponseStatus 768 o description - Specifies the result of a traceroute measurement 769 made by the host for a particular probe. 770 o dataType - OperationResponseStatus 771 o units - N/A 773 5.2.3.10. Time 775 o name - Time 776 o description - Specifies the timestamp for the time the response to 777 the probe was received at the interface. 778 o dataType - DateTime 779 o units - N/A 781 5.2.3.11. ResultsEndDateAndTime 783 o name - ResultsEndDateAndTime 784 o description - Specifies the date and end time of the traceroute 785 measurement. It is either the time when the response to the last 786 probe of the traceroute measurement was received or the time when 787 the last probe of the traceroute measurement was sent plus the 788 relative timeout (in case of missing response). 789 o dataType - DateTime 790 o units - N/A 792 5.2.3.12. HopRawOutputData 794 o name - HopRawOutputData 795 o description - Specifies the raw output data returned by the 796 traceroute measurement for a certain hop in a traceroute 797 measurement path. It is an implementation-dependant printable 798 string, expected to be useful for a human interpreting the 799 traceroute results. 800 o dataType - String 801 o units - N/A 803 5.2.4. Information Element Correlating Configuration and Results 804 Elements 806 This section defines an additional element belonging to both the two 807 previous groups (configuration elements and result elements) named 808 TestName. This element is defined in order to relate configuration 809 elements and results ones by means of a common unique identifier (to 810 be chosen in accordance to the specification of [RFC4560]). 812 5.2.4.1. TestName 814 o name - TestName 815 o description - Specifies the name of a traceroute measurement. 816 This is not necessarily unique, within any well-defined scope 817 (e.g. a specific host, initiator of the traceroute measurement). 818 o dataType - String255 819 o units - N/A 821 5.2.5. Information Elements to compare traceroute measurements results 822 one with each other 824 This section defines additional elements belonging to both the two 825 previous groups (configuration elements and result elements); these 826 elements were defined in order to allow traceroute measurements 827 results comparison among different traceroute measurements. 829 5.2.5.1. OSName 831 o name - OSName 832 o description - Specifies the name of the operating system on which 833 the traceroute measurement was launched. This element is ignored 834 if used in the "RequestMetadata". 835 o dataType - String255 836 o units - N/A 838 5.2.5.2. OSVersion 840 o name - OSVersion 841 o description - Specifies the OS version on which the traceroute 842 measurement was launched. This element is ignored if used in the 843 "RequestMetadata". 845 o dataType - String255 846 o units - N/A 848 5.2.5.3. ToolVersion 850 o name - ToolVersion 851 o description - Specifies the version of the traceroute tool 852 (requested to be used if in the "RequestMetadata" element, 853 actually used if in the "MeasurementMetadata" element). 854 o dataType - String255 855 o units - N/A 857 5.2.5.4. ToolName 859 o name - ToolName 860 o description - Specifies the name of the traceroute tool (requested 861 to be used if in the "RequestMetadata" element, actually used if 862 in the "MeasurementMetadata" element). 863 o dataType - String255 864 o units - N/A 866 6. Data Model for Storing Traceroute Measurements 868 For storing and transmitting information according to the information 869 model defined in the previous section, a data model is required that 870 specifies how to encode the elements of the information model. 872 There are several design choices for a data model. It can use a 873 binary or textual representation and it can be defined from scratch 874 or use already existing frameworks and data models. In general, the 875 use of already existing frameworks and models should be preferred. 877 Binary and textual representation both have advantages and 878 disadvantages. Textual representations are (with some limitations) 879 human readable while a binary representation consumes less resources 880 for storing, transmitting and parsing data. 882 An already existing and closely related data model is the DISMAN- 883 TRACEROUTE-MIB module [RFC4560], that specifies a SMIv2 encoding of 884 [RFC2578], [RFC2579] and [RFC2580] for transmitting traceroute 885 measurement information (configuration and results). This data model 886 is well suited and supported within network management systems, but 887 as a general format for storing and transmitting traceroute results 888 it is not easily applicable. 890 Another binary representation would be an extension of traffic flow 891 information encodings as specified for the IPFIX protocol [RFC5101], 893 [RFC5102]. The IPFIX protocol is extensible. However, the 894 architecture behind this protocol [I-D.ietf-ipfix-architecture] is 895 targeted at exporting passively measured flow information. 896 Therefore, some obstacles are expected when trying to use it for 897 transmitting traceroute measurements information. 899 For textual representations, using the eXtensible Markup Language 900 (XML) [XML] is an obvious choice. XML supports clean structuring of 901 data and syntax checking of records. With some limitations it is 902 human readable. It is supported well by a huge pool of tools and 903 standards for generating, transmitting, parsing and converting it to 904 other data formats. Its disadvantages is the resource consumption 905 for processing, storing, and transmitting information. Since the 906 expected data volumes related to traceroute measurements in network 907 operation and maintenance is not expected to be extremely high, the 908 inefficient usage of resources is not a significant disadvantage. 909 Therefore, XML was chosen as basis for the traceroute measurements 910 information model that is specified in this section. 912 Section 7 contains the XML schema to be used as a template for 913 storing and/or exchanging traceroute measurements information. The 914 schema was designed in order to use an extensible approach based on 915 templates (pretty similar to how IPFIX protocol is designed) where 916 the traceroute configuration elements (both the requested parameters, 917 Request, and the actual parameters used, MeasurementMetadata) are 918 meta data to be referenced by results information elements (data) by 919 means of the TestName element (used as unique identifier, chosen in 920 accordance to the specification of [RFC4560]). Currently Open Grid 921 Forum (OGF) is also using this approach and cross-requirements have 922 been analyzed. As a result of this analysis the XML schema contained 923 in Section 7 is compatible with OGF schema since it was designed in a 924 way that both limits the unnecessary redundancy and a simple one-to- 925 one transformation between the two exist. 927 7. XML Schema for traceroute Measurements 929 This section presents the XML schema to be used as a template for 930 storing and/or exchanging traceroute measurements information. The 931 schema uses UTF-8 encoding defined in [RFC3629]. In documents 932 conforming to the format presented here an XML declaration SHOULD be 933 present specifying the version and the character encoding of the XML 934 document. The document should be encoded using UTF-8. Since some of 935 the strings can span multiple lines [RFC5198] applies. XML 936 processing instructions and comments MUST be ignored. Mind that 937 whitespace is significant in XML when writing documents conforming to 938 this schema. Documents using the presented format must be valid 939 according to the XML schema shown in this section. This includes all 940 elements. Since elements of type _CtlType may contain elements from 941 unknown namespaces those elements MUST be ignored if their namespace 942 is unknown to the processor. Values for elements using the XML 943 schema type dateTime MUST be restricted to values defined in 944 [RFC3339]. Future versions of this format MAY extend this schema by 945 creating a new schema that redefines all or parts of the data types 946 and elements defined in this version or by establishing a complete 947 new schema. 949 Due to the limited line length some lines appear wrapped. 951 952 956 957 958 String restricted to 255 959 characters. 960 962 963 964 965 967 968 969 usginedByte with non zero 970 value. 971 973 974 975 976 978 979 980 981 982 983 984 986 987 989 990 991 993 995 996 997 999 1000 1002 1003 1004 1006 1007 1009 1010 1011 1012 1013 1015 1016 1017 Specifies the AS number of a hop in the 1018 traceroute path as a 32 bit number and the indication how the 1019 mapping from IP address to AS number was 1020 performed. 1021 1023 1024 1026 1027 1028 1029 1031 1033 1035 1036 1037 1038 1039 1040 1041 1043 1044 1045 1048 1050 1052 1055 1057 1058 1060 1061 1062 1063 1066 1069 1072 1074 1075 1076 1078 1079 1080 1082 1083 1085 1087 1089 1091 1093 1095 1097 1099 1100 1101 1103 1104 1105 1106 1107 1109 1110 1111 1113 1114 1115 1117 1118 1119 1121 1122 1123 1124 1125 1126 1127 1128 1129 1132 1133 Specifies the address of a 1134 hop in the traceroute measurement path. This 1135 object is not allowed to be a DNS name. The 1136 address type can be determined by examining the 1137 inetAddress type name and the corresponding 1138 element value. 1139 1140 1142 1144 1145 Specifies the DNS name of 1146 the HopAddress if it is available. If it is 1147 not available the element is 1148 omitted. 1149 1150 1152 1154 1155 Specifies entries of the 1156 MPLS label stack of a probe observed when the 1157 probe arrived at the hop that replied to the 1158 probe. This object contains one MPLS label 1159 stack entry as 32 bit value as it is observed 1160 on the MPLS label stack. Contained in this 1161 single number are the MPLS label, the Exp 1162 field, the S flag, and the MPLS TTL value as 1163 specified in [RFC3032]. If more than one MPLS 1164 label stack entry is reported then multiple 1165 instances of elements of this type are used. 1166 They must be ordered in the same order as on 1167 the label stack with the top label stack 1168 entry being reported 1169 first. 1170 1172 1173 1174 1175 1176 1177 1179 1181 1182 If this element contains 1183 the element roundTripTime this specifies the 1184 amount of time measured in milliseconds from 1185 when a probe was sent to when its response 1186 was received or when it timed out. The value 1187 of this element is reported as the truncation 1188 of the number reported by the traceroute tool 1189 (the output "< 1 ms" is therefore encoded 1190 as 0 ms). If it contains the element 1191 "roundTripTimeNotAvaiable" it means either 1192 the probe was lost because of a timeout or it 1193 was not possible to transmit a 1194 probe. 1195 1196 1198 1200 1201 Specifies the result of a 1202 traceroute measurement made by the host for a 1203 particular probe. 1204 1205 1207 1208 1209 Specifies the timestamp for 1210 the time the response to the probe was 1211 received at the interface. 1212 1213 1214 1215 1216 1218 1220 1221 Specifies the raw output data 1222 returned by the traceroute measurement for a 1223 certain hop in a traceroute measurement path. It is 1224 an implementation-dependant printable string, 1225 expected to be useful for a human interpreting the 1226 traceroute results. 1227 1229 1230 1231 1232 1233 1234 1236 1237 1238 Specifies the metadata for a traceroute 1239 operation. The parameters requested if used in 1240 "RequestMetadata" or the actual parameters used if used in 1241 "MeasurementMetadata". 1242 1244 1245 1246 1247 Specifies the name of a traceroute 1248 measurement. This is not necessarily unique, within any 1249 well-defined scope (e.g. a specific host, initiator of 1250 the traceroute measurement). 1251 1252 1254 1255 1256 Specifies the name of the operating 1257 system on which the traceroute measurement was launched. 1258 This element is ignored if used in the 1259 "RequestMetadata". 1260 1261 1263 1264 1265 Specifies the OS version on which the 1266 traceroute measurement was launched. This element is 1267 ignored if used in the 1268 "RequestMetadata". 1269 1270 1272 1273 1274 Specifies the version of the traceroute 1275 tool (requested to be used if in the "RequestMetadata" 1276 element, actually used if in the "MeasurementMetadata" 1277 element). 1278 1279 1281 1282 1283 Specifies the name of the traceroute 1284 tool (requested to be used if in the "RequestMetadata" 1285 element, actually used if in the "MeasurementMetadata" 1286 element). 1287 1288 1290 1291 1292 In the "RequestMetadata" element it 1293 specifies the host address requested to be used in the 1294 traceroute measurement. In the "MeasurementMetadata" 1295 element it specifies the host address used in the 1296 traceroute measurement. The host address type can be 1297 determined by the examining the inetAddress type name and 1298 the corresponding element value. 1299 1300 1302 1304 1305 In the "RequestMetadata" element 1306 specifies if it is requested to enable the optional 1307 bypassing of the route table or not. In the 1308 "MeasurementMetadata" element, specifies if the optional 1309 bypassing of the route table was enabled or not.If 1310 enabled, the normal routing tables will be bypassed and 1311 the probes will be sent directly to a host on an attached 1312 network. If the host is not on a directly-attached 1313 network, an error is returned. This option can be used to 1314 perform the traceroute measurement to a local host 1315 through an interface that has no route defined. This 1316 object can be used when the setsockopt SOL_SOCKET 1317 SO_DONTROUTE option is supported and set (see the POSIX 1318 standard IEEE.1003-1G.1997). 1319 1320 1322 1323 1324 Specifies the size of the probes of a 1325 traceroute measurement in octets (requested if in the 1326 "RequestMetadata" element, actually used if in the 1327 "MeasurementMetadata" element). If UDP datagrams are used 1328 as probes, then the value contained in this object is 1329 exact. If another protocol is used to transmit probes 1330 (i.e. TCP or ICMP) for which the specified size is not 1331 appropriate, then the implementation can use whatever 1332 size (appropriate to the method) is closest to the 1333 specified size. The maximum value for this object was 1334 computed by subtracting the smallest possible IP header 1335 size of 20 octets (IPv4 header with no options) and the 1336 UDP header size of 8 octets from the maximum IP packet 1337 size. An IP packet has a maximum size of 65535 octets 1338 (excluding IPv6 Jumbograms). 1339 1341 1342 1343 1344 1345 1346 1348 1349 1350 Specifies the time-out value, in 1351 seconds, for each probe of a traceroute measurement 1352 (requested if in the "RequestMetadata" element, actually 1353 used if in the "MeasurementMetadata" 1354 element). 1355 1357 1358 1359 1361 1362 1363 1364 1366 1367 1368 Specifies the number of probes with the 1369 same time-to-live (TTL) value that are sent for each host 1370 (requested if in the "RequestMetadata" element, actually 1371 used if in the "MeasurementMetadata" 1372 element). 1374 1376 1377 1378 1380 1381 1382 1383 1385 1386 1387 Specifies the base port used by the 1388 traceroute measurement (requested if in the 1389 "RequestMetadata" element, actually used if in the 1390 "MeasurementMetadata" element). 1391 1393 1394 1395 1396 1397 1398 1400 1401 1402 Specifies the maximum TTL value for the 1403 traceroute measurement (requested if in the 1404 "RequestMetadata" element, actually used if in the 1405 "MeasurementMetadata" element). 1406 1407 1409 1411 1412 Specifies the value that was requested 1413 to be stored in the Differentiated Services (DS) field in 1414 the traceroute probe (if in the "RequestMetadata" 1415 element). Specifies the value that was stored in the 1416 Differentiated Services (DS) field in the traceroute 1417 probe (if in the "MeasurementMetadata" element). The DS 1418 Field is defined as the Type of Service (TOS) octet in a 1419 IPv4 header or as the Traffic Class octet in a IPv6 1420 header (see section 7 of [RFC2460]). The value of this 1421 object must be a decimal integer in the range from 0 to 1422 255. This option can be used to determine what effect an 1423 explicit DS field setting has on a traceroute measurement 1424 and its probes. Not all values are legal or meaningful. 1425 Useful TOS octet values are probably '16' (low delay) and 1426 '8' (high throughput). Further references can be found in 1427 [RFC2474] for the definition of the Differentiated 1428 Services (DS) field and to [RFC1812] Section 5.3.2 for 1429 Type of Service (TOS). 1430 1431 1433 1435 1436 Specifies the IP address (which has to 1437 be given as an IP number, not a hostname) as the source 1438 address in traceroute probes (requested if in the 1439 "RequestMetadata" element, actually used if in the 1440 "MeasurementMetadata" element). On hosts with more than 1441 one IP address, this option can be used in 1442 "RequestMetadata" element to force the source address to 1443 be something other than the primary IP address of the 1444 interface the probe is sent on; the value "unknown" means 1445 the default address will be used. The address type can be 1446 determined by examining the inetAddress type name and the 1447 corresponding element value. 1448 1449 1451 1453 1454 Specifies the interface index as 1455 defined in [RFC2863] that is requested to be used in the 1456 traceroute measurement for sending the traceroute probes 1457 (if in the "RequestMetadata" element). A value of 0 in 1458 the "RequestMetadata" indicates that no specific 1459 interface is requested. Specifies the one actually used 1460 if in the "MeasurementMetadata" 1461 element. 1462 1463 1465 1467 1468 Specifies implementation dependent 1469 options (requested if in the "RequestMetadata" element, 1470 actually used if in the "MeasurementMetadata" 1471 element). 1472 1473 1475 1477 1478 Specifies the maximum number of 1479 consecutive timeouts allowed before terminating a 1480 traceroute measurement (requested if in the 1481 "RequestMetadata" element, actually used if in the 1482 "MeasurementMetadata" element). A value of either 255 1483 (maximum hop count/possible TTL value) or a 0 indicates 1484 that the function of terminating a remote traceroute 1485 measurement when a specific number of consecutive 1486 timeouts are detected was disabled. This element is 1487 included to give full compatibility with [RFC4560]. No 1488 known implementation of traceroute currently supports 1489 it. 1490 1491 1493 1495 1496 Specifies if the don't fragment flag 1497 (DF) in the IP header for a probe was enabled or not (if 1498 in the "MeasurementMetadata" element). If in the 1499 "RequestMetadata", it specifies if the flag was requested 1500 to be enable or not. Setting the DF flag can be used for 1501 performing a manual PATH MTU test. 1502 1503 1505 1507 1508 Specifies the initial TTL value for a 1509 traceroute measurement (requested if in the 1510 "RequestMetadata" element, actually used if in the 1511 "MeasurementMetadata" element). Such TTL setting is 1512 intended to bypass the initial (often well known) portion 1513 of a path. 1514 1515 1517 1519 1520 The purpose of this element is to 1521 provide a description of the traceroute 1522 measurement. 1523 1524 1526 1527 1528 Specifies the implementation method 1529 used for the traceroute measurement (requested if in the 1530 "RequestMetadata" element, actually used if in the 1531 "MeasurementMetadata" element). It specifies if the 1532 traceroute is using TCP, UDP, ICMP or other type of 1533 probes. It is possible to specify other types of probes 1534 by using an element specified in another schema with a 1535 different namespace. 1536 1537 1538 1539 1541 1542 1543 Contains the actual traceroute measurement 1544 results. 1545 1547 1548 1549 1550 Specifies the name of a traceroute 1551 measurement. This is not necessarily unique, within any 1552 well-defined scope (e.g. a specific host, initiator of 1553 the traceroute measurement). 1554 1555 1557 1558 1559 Specifies the date and start time of 1560 the traceroute measurement. This is the time when the 1561 first probe was seen at the sending 1562 interface. 1563 1564 1565 1567 1568 Specifies the IP address associated 1569 with a CtlTargetAddress value when the destination 1570 address is specified as a DNS name. The value of this 1571 object should be "unknown" if a DNS name is not specified 1572 or when a specified DNS name fails to resolve. The 1573 address type can be determined by examining the inetAddress 1574 type name and the corresponding element 1575 value. 1576 1577 1579 1581 1582 1583 Specifies the date and end time of the 1584 traceroute measurement. It is either the time when the 1585 response to the last probe of the traceroute measurement 1586 was received or the time when the last probe of the 1587 traceroute measurement was sent plus the relative timeout 1588 (in case of missing response). 1589 1590 1591 1592 1594 1595 1596 1597 1600 1602 1603 1604 1607 1610 1611 1612 1614 1615 1616 1617 1619 8. Security Considerations 1621 Security considerations discussed in this section are grouped into 1622 considerations related to conducting traceroute measurements and 1623 considerations related to storing and transmitting traceroute 1624 measurements information. 1626 This memo does not specify an implementation of a traceroute tool. 1627 Neither does it specify a certain procedure for storing traceroute 1628 measurements information. Still it is considered desirable to 1629 discuss related security issues below. 1631 8.1. Conducting Traceroute Measurements 1633 Conducting Internet measurements can raise both security and privacy 1634 concerns. Traceroute measurements, in which traffic is injected into 1635 the network, can be abused for denial-of-service attacks disguised as 1636 legitimate measurement activity. 1638 Measurement parameters MUST be carefully selected so that the 1639 measurements inject trivial amounts of additional traffic into the 1640 networks they measure. If they inject "too much" traffic, they can 1641 skew the results of the measurement, and in extreme cases cause 1642 congestion and denial of service. 1644 The measurements themselves could be harmed by routers giving 1645 measurement traffic a different priority than "normal" traffic, or by 1646 an attacker injecting artificial measurement traffic. If routers can 1647 recognize measurement traffic and treat it separately, the 1648 measurements will not reflect actual user traffic. If an attacker 1649 injects artificial traffic that is accepted as legitimate, the loss 1650 rate will be artificially lowered. Therefore, the measurement 1651 methodologies SHOULD include appropriate techniques to reduce the 1652 probability measurement traffic can be distinguished from "normal" 1653 traffic. 1655 Authentication techniques, such as digital signatures, may be used 1656 where appropriate to guard against injected traffic attacks. 1658 8.2. Securing Traceroute Measurements Information 1660 Traceroute measurement information are not considered highly 1661 sensitive. Still, they may contain sensitive information on network 1662 paths, routing states, used IP addresses, and roundtrip times, that 1663 operators of networks may want to protect for business or security 1664 reasons. 1666 It is thus important to control access to Information acquired by 1667 conducting traceroute measurements, particularly when transmitting it 1668 over a networks but also when storing it. It is RECOMMENDED that 1669 transmission of traceroute measurement information over a network 1670 uses appropriate protection mechanisms for preserving privacy, 1671 integrity and authenticity. It is further RECOMMENDED that secure 1672 authentication and authorization are used for protecting stored 1673 traceroute measurement information. 1675 9. IANA Considerations 1677 This document uses URNs to describe an XML namespace and an XML 1678 schema for traceroute measurements information storing and 1679 transmission conforming to a registry mechanism described in 1680 [RFC3688]. Two URI assignments are requested. 1681 1. Registration request for the IPPM traceroute measurements 1682 namespace 1683 * URI: urn:ietf:params:xml:ns:traceroute-1.0 1684 * Registrant Contact: IESG 1685 * XML: None. Namespace URIs do not represent an XML 1686 2. Registration request for the IPPM traceroute measurements schema 1687 * URI: urn:ietf:params:xml:schema:traceroute-1.0 1688 * Registrant Contact: IESG 1689 * XML: See the section Section 7 of this document. 1691 10. References 1693 10.1. Normative References 1695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1696 Requirement Levels", BCP 14, RFC 2119, March 1997. 1698 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1699 (IPv6) Specification", RFC 2460, December 1998. 1701 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1702 MIB", RFC 2863, June 2000. 1704 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1705 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1706 Encoding", RFC 3032, January 2001. 1708 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1709 Internet: Timestamps", RFC 3339, July 2002. 1711 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1712 10646", STD 63, RFC 3629, November 2003. 1714 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1715 Schoenwaelder, "Textual Conventions for Internet Network 1716 Addresses", RFC 4001, February 2005. 1718 [RFC4560] Quittek, J. and K. White, "Definitions of Managed Objects 1719 for Remote Ping, Traceroute, and Lookup Operations", 1720 RFC 4560, June 2006. 1722 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 1723 Interchange", RFC 5198, March 2008. 1725 10.2. Informative References 1727 [I-D.ietf-ipfix-architecture] 1728 Sadasivan, G., "Architecture for IP Flow Information 1729 Export", draft-ietf-ipfix-architecture-12 (work in 1730 progress), September 2006. 1732 [IEEE.1003-1G.1997] 1733 Institute of Electrical and Electronics Engineers, 1734 "Protocol Independent Interfaces", IEEE Standard 1003.1G, 1735 March 1997. 1737 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1738 RFC 1812, June 1995. 1740 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1741 "Definition of the Differentiated Services Field (DS 1742 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1743 December 1998. 1745 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1746 Schoenwaelder, Ed., "Structure of Management Information 1747 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1749 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1750 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1751 STD 58, RFC 2579, April 1999. 1753 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1754 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1755 April 1999. 1757 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1758 January 2004. 1760 [RFC5101] Claise, B., "Specification of the IP Flow Information 1761 Export (IPFIX) Protocol for the Exchange of IP Traffic 1762 Flow Information", RFC 5101, January 2008. 1764 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 1765 Meyer, "Information Model for IP Flow Information Export", 1766 RFC 5102, January 2008. 1768 [XML] Yergeau et al., F., "Extensible Markup Language (XML) 1.0 1769 (Third Edition)", W3C Recommendation, February 2004. 1771 Appendix A. Traceroute Default Configuration Parameters 1773 This section lists traceroute measurement configuration parameters as 1774 well as their defaults on various platforms and illustrates how 1775 widely they may vary. This document considered four major traceroute 1776 tool implementations and compared them based on configurable 1777 parameters and default values. The LINUX (SUSE 9.1), BSD (FreeBSD 1778 7.0) and UNIX (SunOS 5.9) implementations are based on UDP datagrams, 1779 while the WINDOWS (XP SP2) one uses ICMP Echoes. The comparison is 1780 summarized in the following table, where an N/A in the option column, 1781 means that such parameter is not configurable for the specific 1782 implementation. A comprehensive comparison of available 1783 implementations is outside the scope of this document; however, 1784 already by sampling a few different implementations, it can be 1785 observed that they can differ quite significantly in terms of 1786 configurable parameters and also default values. Note that in the 1787 following table only those options which are available in at least 1788 two of the considered implementations are reported. 1790 +---------------------------------------------------------+ 1791 | OS |Option| Description | Default | 1792 +--------+------+-------------------------------+---------+ 1793 | LINUX | -m |Specify the maximum TTL used | 30 | 1794 |--------+------|in traceroute probes. |---------| 1795 | FreeBSD| -m | | OS var | 1796 |--------+------| |---------| 1797 | UNIX | -m | | 30 | 1798 |--------+------| |---------| 1799 | WINDOWS| -h | | 30 | 1800 +--------+------+-------------------------------+---------+ 1801 | LINUX | -n |Display hop addresses | - | 1802 |--------+------|numerically rather than |---------| 1803 | FreeBSD| -n |symbolically. | - | 1804 |--------+------| |---------| 1805 | UNIX | -n | | - | 1806 |--------+------| |---------| 1807 | WINDOWS| -d | | - | 1808 +--------+------+-------------------------------+---------+ 1809 | LINUX | -w |Set the time to wait for a | 3 sec | 1810 |--------+------|response to a probe. |---------| 1811 | FreeBSD| -w | | 5 sec | 1812 |--------+------| |---------| 1813 | UNIX | -w | | 5 sec | 1814 |--------+------| |---------| 1815 | WINDOWS| -w | | 4 sec | 1816 +--------+------+-------------------------------+---------+ 1817 | LINUX | N/A |Specify a loose source route | - | 1818 |--------+------|gateway (to direct the |---------| 1819 | FreeBSD| -g |traceroute probes through | - | 1820 |--------+------|routers not necessarily in |---------| 1821 | UNIX | -g | the path). | - | 1822 |--------+------| |---------| 1823 | WINDOWS| -g | | - | 1824 +--------+------+-------------------------------+---------+ 1825 | LINUX | -p |Set the base UDP port number | 33434 | 1826 |------- +------|used in traceroute probes |---------| 1827 | FreeBSD| -p |(UDP port = base + nhops - 1). | 33434 | 1828 |--------+------| |---------| 1829 | UNIX | -p | | 33434 | 1830 |--------+------| |---------| 1831 | WINDOWS| N/A | | - | 1832 +--------+------+-------------------------------+---------+ 1833 | LINUX | -q |Set the number of probes per | 3 | 1834 |--------+------|TTL. |---------| 1835 | FreeBSD| -q | | 3 | 1836 |--------+------| |---------| 1837 | UNIX | -q | | 3 | 1838 |--------+------| |---------| 1839 | WINDOWS| N/A | | 3 | 1840 +--------+------+-------------------------------+---------+ 1841 | LINUX | -S |Set the IP source address in |IP | 1842 |--------+------|outgoing probes to the |address | 1843 | FreeBSD| -s |specified value. |of the | 1844 |--------+------| |out | 1845 | UNIX | -s | |interface| 1846 |--------+------| | | 1847 | WINDOWS| N/A | | | 1848 +--------+------+-------------------------------+---------+ 1849 | LINUX | -t |Set the type-of-service (TOS) | 0 | 1850 |--------+------|in the probes to the specified |---------| 1851 | FreeBSD| -t |value. | 0 | 1852 |--------+------| |---------| 1853 | UNIX | -t | | 0 | 1854 |--------+------| |---------| 1855 | WINDOWS| N/A | | 0 | 1856 +--------+------+-------------------------------+---------+ 1857 | LINUX | -v |Verbose output: received ICMP | - | 1858 |--------+------|packets other than |---------| 1859 | FreeBSD| -v |TIME_EXCEEDED and | - | 1860 |--------+------|UNREACHABLE are listed. |---------| 1861 | UNIX | -v | | - | 1862 |--------+------| |---------| 1863 | WINDOWS| N/A | | - | 1864 +--------+------+-------------------------------+---------+ 1865 | LINUX | N/A |Set the time (in msec) to | - | 1866 |--------+------|pause between probes. |---------| 1867 | FreeBSD| -z | | 0 | 1868 |--------+------| |---------| 1869 | UNIX | -P | | 0 | 1870 |--------+------| |---------| 1871 | WINDOWS| N/A | | - | 1872 +--------+------+-------------------------------+---------+ 1873 | LINUX | -r |Bypass the normal routing | - | 1874 |--------+------|tables and send directly to a |---------| 1875 | FreeBSD| -r |host on attached network. | - | 1876 |--------+------| |---------| 1877 | UNIX | -r | | - | 1878 |--------+------| |---------| 1879 | WINDOWS| N/A | | - | 1880 +--------+------+-------------------------------+---------+ 1881 | LINUX | -f |Set the initial TTL for the | 1 | 1882 |--------+------|first probe. |---------| 1883 | FreeBSD| -f | | 1 | 1884 |--------+------| |---------| 1885 | UNIX | -f | | 1 | 1886 |--------+------| |---------| 1887 | WINDOWS| N/A | | 1 | 1888 +--------+------+-------------------------------+---------+ 1889 | LINUX | -F |Set the "don't fragment" bit. | - | 1890 |--------+------| |---------| 1891 | FreeBSD| -F | | - | 1892 |--------+------| |---------| 1893 | UNIX | -F | | - | 1894 |--------+------| |---------| 1895 | WINDOWS| N/A | | - | 1896 +--------+------+-------------------------------+---------+ 1897 | LINUX | N/A |Enables socket level debugging.| - | 1898 |--------+------| |---------| 1899 | FreeBSD| -d | | - | 1900 |--------+------| |---------| 1901 | UNIX | -d | | - | 1902 |--------+------| |---------| 1903 | WINDOWS| N/A | | - | 1904 +--------+------+-------------------------------+---------+ 1905 | LINUX | N/A |Use ICMP ECHO instead of UDP | - | 1906 |--------+------|datagrams. |---------| 1907 | FreeBSD| -I | | - | 1908 |--------+------| |---------| 1909 | UNIX | -I | | - | 1910 |--------+------| |---------| 1911 | WINDOWS| N/A | | - | 1912 +--------+------+-------------------------------+---------+ 1913 | LINUX | -I |Specify a network interface to | - | 1914 |--------+------|obtain the IP address for |---------| 1915 | FreeBSD| -i |outgoing IP packets | - | 1916 |--------+------|(alternative to option -s). |---------| 1917 | UNIX | -i | | - | 1918 |--------+------| |---------| 1919 | WINDOWS| N/A | | - | 1920 +--------+------+-------------------------------+---------+ 1921 | LINUX | N/A |Toggle checksum. | - | 1922 |--------+------| |---------| 1923 | FreeBSD| -x | | - | 1924 |--------+------| |---------| 1925 | UNIX | -x | | - | 1926 |--------+------| |---------| 1927 | WINDOWS| N/A | | - | 1928 +--------+------+-------------------------------+---------+ 1929 | LINUX | - |As optional last parameter, |Depends | 1930 |--------+------|LINUX, FreeBSD and UNIX |on | 1931 | FreeBSD| - |implementations allow |implement| 1932 |--------+------|specifying the probe datagram |ation. | 1933 | UNIX | - |length for outgoing probes. | | 1934 |--------+------| | | 1935 | WINDOWS| N/A | | | 1936 +--------+------+-------------------------------+---------+ 1938 A.1. Alternative Traceroute Implementations 1940 As stated above, the widespread use of firewalls might prevent UDP or 1941 ICMP based traceroutes to completely trace the path to a destination, 1942 since traceroute probes might end up being filtered. In some cases, 1943 such limitation might be overcome by sending instead TCP packets to 1944 specific ports that hosts located behind the firewall are listening 1945 for connections on. TCP based implementations use TCP SYN or FIN 1946 probes and listen for TIME_EXCEEDED messages, TCP RESET and other 1947 messages from firewalls and gateways on the path. On the other hand, 1948 some firewalls filter out TCP SYN packets to prevent denial of 1949 service attacks, therefore the actual advantage of using TCP instead 1950 of UDP traceroute depends mainly on firewall configurations, which 1951 are not known in advance. A detailed analysis of TCP-based 1952 traceroute tools and measurements was outside the scope of this 1953 document, anyway for completeness reasons the information model 1954 supports the storing of TCP-based traceroute measurements, too. 1956 Appendix B. Known Problems with Traceroute 1958 B.1. Compatibility between traceroute measurements results and IPPM 1959 metrics 1961 Because of implementation choices, a known inconsistency exists 1962 between the round-trip delay metric defined by the IPPM working group 1963 in RFC 2681 and the results returned by the current traceroute tool 1964 implementations. Unfortunately, it is unlikely that the traceroute 1965 tool implementations will implement the standard definition in the 1966 near future. The only possibility is therefore to compare results of 1967 different traceroute measurements one with each other; in order to do 1968 this, specifications both of the operating system (name and version) 1969 and of the traceroute tool version used were added to the metadata 1970 elements in order to help in comparing metrics between two different 1971 traceroute measurements results (if run using the same operating 1972 system and the same version of the tool). Moreover, the traceroute 1973 tool has built-in configurable mechanisms like time-outs and can 1974 experience problems related to the crossing of firewalls; therefore 1975 some of the packets that traceroute sends out end up being time-out 1976 or filtered. As a consequence, it might not be possible to trace the 1977 path to a node or there might not be a complete set of probes 1978 describing the RTT to reach it. 1980 Appendix C. Differences to DISMAN-TRACEROUTE-MIB 1982 For performing remote traceroute operations at managed node, the IETF 1983 has standardized the DISMAN-TRACEROUTE-MIB module in [RFC4560]. This 1984 module allows: 1986 o retrieving capability information of the traceroute tool 1987 implementation at the managed node, 1989 o configuring traceroute measurements to be performed, 1990 o retrieving information about ongoing and completed traceroute 1991 measurements, 1992 o retrieving traceroute measurement statistics. 1994 The traceroute storage format described in this document has 1995 significant overlaps with this MIB module. Particularly, the models 1996 for the traceroute measurement configuration and for the result from 1997 completed measurements are almost identical. But for other pats of 1998 the DISMAN-TRACEROUTE MIB module there is no need to model them in a 1999 traceroute measurements storage format. Particularly, the capability 2000 information, information about ongoing measurements and measurement 2001 statistics are not covered by the DISMAN traceroute storage model. 2003 Concerning traceroute measurements and their results, there are 2004 structural differences between the two models caused by the different 2005 choices for the encoding of the specification. For DISMAN- 2006 TRACEROUTE-MIB, the Structure of Management Information (SMIv2, STD 2007 58, RFC 2578 [RFC2578]) was used, while the IPPM traceroute 2008 measurements data model is encoded using XML. 2010 This difference in structure implies that the DISMAN-TRACEROUTE-MIB 2011 module contains SMI-specific information element (managed objects) 2012 that concern tables of managed objects (specification, entry creation 2013 and deletion, status retrieval) that are not required for the XML- 2014 encoded traceroute measurements data model. 2016 But for most of the remaining information elements that concern 2017 configuration of traceroute measurements and results of completed 2018 measurements, the semantics is identical between the DISMAN- 2019 TRACEROUTE-MIB module and the traceroute measurements data model. 2020 There are very few exceptions to this which are listed below. Also 2021 naming of information elements is identical between both models with 2022 a few exceptions. For the traceroute measurements data model, a few 2023 information elements have been added, some because of the different 2024 structure and some to provide additional information on completed 2025 measurements. 2027 C.1. Scope 2029 There are some basic differences in nature and application between 2030 MIB modules and XML documents. This results in two major differences 2031 of Scope between the DISMAN-TRACEROUTE-MIB module and the traceroute 2032 measurements data model. 2034 The first difference is the traceRouteResultsTable contained in the 2035 DISMAN-TRACEROUTE-MIB module. This table allows online observation 2036 of status and progress of an ongoing traceroute measurement. This 2037 highly dynamic information is not included in the traceroute 2038 measurements data model, because it has not been envisioned to use 2039 the model for dynamically reporting progress of individual traceroute 2040 measurements. The traceroute measurements data model is rather 2041 intended to be used for reporting completed traceroute measurements. 2043 The second difference is due to the fact that information in a MIB is 2044 typically tied to a local node hosting the MIB instance. The 2045 "RequestMetadata" element specified in the traceroute measurements 2046 data model can be used for specifying a measurement request that may 2047 be applied to several probes in a network. This concept does not 2048 exist in the DISMAN-TRACEROUTE-MIB module. 2050 For the remaining elements in the DISMAN-TRACEROUTE-MIB module and in 2051 the traceroute measurements data model there is a very good match 2052 between the two worlds. The traceRouteCtlTable corresponds to the 2053 "MeasurementMetadata" element and the combination of the 2054 traceRouteProbeHistoryTable and the traceRouteHopsTable corresponds 2055 to a collection of "MeasurementResult" elements. 2057 C.2. Naming 2059 Basically, names in both models are chosen using the same naming 2060 conventions. 2062 For the traceroute measurement configuration information all names, 2063 such as CtlProbesPerHop, are identical in both models except for the 2064 traceRoute prefix that was removed to avoid unnecessary redundancy in 2065 the XML file and for CtlDataSize which was renamed to 2066 CtlProbeDataSize for clarification in the traceroute measurements 2067 data model. 2069 Results of measurements in the DISMAN-TRACEROUTE-MIB modules are 2070 distributed over two tables, the traceRouteResultsTable containing 2071 mainly information about ongoing measurements and the 2072 traceRouteProbeHistoryTable containing only information about 2073 completed measurements. According to the SMIv2 naming conventions 2074 names of information elements in these tables have different prefixes 2075 (traceRouteResults and traceRouteProbeHistory). Since the traceroute 2076 measurements data model only reports on completed measurements, this 2077 separation is not needed anymore and the prefix "Results" is used for 2078 all related information elements. 2080 Beyond that, there are only a few changes in element names. The 2081 renaming actions include: 2083 o traceRouteProbeHistoryResponse to ProbeRoundTripTime, 2084 o traceRouteProbeHistoryHAddr to HopAddr, 2085 o traceRouteProbeHistoryTime to ResultsEndDateAndTime, 2086 o traceRouteProbeHistoryLastRC to ResultsHopRawOutputData. 2088 C.3. Semantics 2090 The semantics was changed for two information elements only. 2092 For traceRouteProbeHistoryResponse in the DISMAN-TRACEROUTE-MIB, a 2093 value of 0 indicated, that it was not possible to transmit a probe. 2094 For the traceroute measurements data model, a value of 0 for element 2095 RoundTripTime indicates that the measured time was less than one 2096 millisecond, while for the case that it was not possible to transmit 2097 a probe a string is used that indicates the problem. 2099 For traceRouteCtlIfIndex in the DISMAN-TRACEROUTE-MIB, a value of 0 2100 indicated, that it the option to set the index is not available. 2101 This was translated to the traceroute measurements data model, such 2102 that a value of 0 for this element indicates that the used interface 2103 is unknown. 2105 The element traceRouteProbeHistoryLastRC in the DISMAN-TRACEROUTE-MIB 2106 was replaced by element ResultsHopRawOutputData. While 2107 traceRouteProbeHistoryLastRC just reports a reply code, 2108 ResultsHopRawOutputData reports the full raw output data (per hop) 2109 produced by the traceroute measurements that was used. 2111 C.4. Additional Information Elements 2113 Only a few information elements have been added to the model of the 2114 DISMAN-TRACEROUTE-MIB module. 2116 o For providing information on the MPLS label stack entries of a 2117 probe in the traceroute measurement path MPLSLabelStackEntry was 2118 added. 2119 o For providing additional timestamp beyond ResultsEndDateAndTime, 2120 ResultsStartDateAndTime and Time were added. 2121 o For providing DNS names at the time of the execution of the 2122 traceroute for each HopAddr (which may change over time) HopName 2123 was added. 2125 Appendix D. Traceroute Examples with XML representation 2127 This Section shows some examples of traceroute applications. In 2128 addition the encoding of requests and results is shown for some of 2129 those examples. Note that also in these XML examples some lines 2130 appear wrapped due to the limited length of line. 2132 A typical traceroute on a linux system looks like the following: 2133 # traceroute -f 4 www.example 1500 2134 traceroute to ww.example (192.0.2.42), 30 hops max, 1500 byte packets 2135 5 out.host1.example (192.0.2.254) 6.066 ms 5.625 ms 6.095 ms 2136 6 rtr4.host6.example (192.0.2.142) 6.979 ms 6.221 ms 7.368 ms 2137 7 hop7.rtr9.example (192.0.2.11) 16.165 ms 15.347 ms 15.514 ms 2138 8 192.0.2.222 (192.0.2.222) 32.796 ms 28.723 ms 26.988 ms 2139 9 in.example (192.0.2.123) 15.861 ms 16.262 ms 17.610 ms 2140 10 in.example (192.0.2.123)(N!) 17.391 ms * * 2142 This traceroute ignores the first 4 hops and uses 1500 byte packets. 2143 It does not reach its goal since the last listed hop says that the 2144 network is not reachable (N!). The XML representation for this trace 2145 follows: 2146 2147 2148 2149 Example 1 2150 2151 2152 2153 2154 2155 www.example 2156 2157 2158 1500 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 4 2172 Show how it encodes in XML 2173 2174 2175 2176 2177 Example 1 2178 Linux 2179 2.6.16.54-0.2.5-smp i386 2180 1.0 2181 traceroute 2182 2183 www.example 2184 2185 2186 1500 2187 2188 2189 2190 2191 2192 2193 192.0.2.1 2194 2195 2 2196 2197 2198 2199 4 2200 Show how it encodes in XML 2201 2202 2203 2204 Example 1 2205 2008-05-16T14:22:34+02:00 2207 2208 192.0.2.42 2209 2210 2211 2212 2213 2214 192.0.2.254 2215 2216 out.host1.example 2217 2218 6 2219 2220 responseReceived 2221 2222 2223 2224 2225 192.0.2.254 2227 2228 out.host1.example 2229 5 2231 responseReceived 2232 2233 2234 2235 2236 192.0.2.254 2237 2238 out.host1.example 2239 2240 6 2241 2242 responseReceived 2243 2244 2245 5 out.host1.example (192.0.2.254) 6.06 2246 6 ms 5.625 ms 6.095 ms 2247 2248 2249 2250 2251 192.0.2.142 2252 2253 rtr4.host6.example 2254 2255 6 2256 2257 responseReceived 2258 2259 2260 2261 2262 192.0.2.142 2263 2264 rtr4.host6.example 2265 2266 6 2267 2268 responseReceived 2269 2270 2271 2272 2273 192.0.2.142 2274 2275 rtr4.host6.example 2276 2277 7 2278 2279 responseReceived 2280 2281 2282 6 rtr4.host6.example (192.0.2.142) 6.9 2283 79 ms 6.221 ms 7.368 ms 2284 2285 2286 2287 2288 192.0.2.11 2289 2290 hop7.rtr9.example 2291 2292 16 2293 2294 responseReceived 2295 2296 2297 2298 2299 192.0.2.11 2300 2301 hop7.rtr9.example 2302 2303 15 2304 2305 responseReceived 2306 2307 2308 2309 2310 192.0.2.11 2311 2312 hop7.rtr9.example 2313 2314 15 2315 2316 responseReceived 2317 2318 2319 7 hop7.rtr9.example (192.0.2.11) 16.16 2320 5 ms 15.347 ms 15.514 ms 2321 2322 2323 2324 2325 192.0.2.222 2326 2327 2328 32 2329 2330 responseReceived 2331 2332 2333 2334 2335 192.0.2.222 2336 2337 2338 38 2339 2340 responseReceived 2341 2342 2343 2344 2345 192.0.2.222 2346 2347 2348 26 2349 2350 responseReceived 2351 2352 2353 8 192.0.2.222 (192.0.2.222) 32.796 ms 2354 28.723 ms 26.988 ms 2355 2356 2357 2358 2359 192.0.2.123 2360 2361 in.example 2362 2363 15 2364 2365 responseReceived 2366 2367 2368 2369 2370 192.0.2.123 2372 2373 in.example 2374 2375 16 2376 2377 responseReceived 2378 2379 2380 2381 2382 192.0.2.123 2383 2384 in.example 2385 2386 17 2387 2388 responseReceived 2389 2390 2391 9 in.example (192.0.2.123) 15.861 ms 2392 16.262 ms 17.610 ms 2393 2394 2395 2396 2397 192.0.2.123 2398 2399 in.example 2400 2401 17 2402 2403 noRouteToTarget 2404 2405 2406 2407 2408 192.0.2.123 2409 2410 in.example 2411 2412 2413 2414 requestTimedOut 2415 2416 2417 2418 2419 192.0.2.123 2421 2422 in.example 2423 2424 2425 2426 requestTimedOut 2427 2428 2429 10 in.example (192.0.2.123)(N!) 17.391 2430 ms * * 2431 2432 2433 2008-05-16T14:22:44+02:00 2435 2436 2437 2439 The second example was generated on an OpenBSD system. On that 2440 system the traceroute looks the following: 2441 # traceroute -P tcp w2.example 128 2443 traceroute to w2.example (192.0.2.254), 64 hops max, 160 byte packets 2444 1 router1.example.org (192.0.2.22) 0.486 ms 0.486 ms 0.482 ms 2445 2 router7.example.org (192.0.2.1) 3.27 ms 1.420 ms 1.873 ms 2446 3 hop0.c.example (192.0.2.105) 3.177 ms 3.258 ms 3.859 ms 2447 4 hop6.c.example (192.0.2.107) 5.994 ms 4.607 ms 5.678 ms 2448 5 hop3.c.example (192.0.2.111) 20.341 ms 20.732 ms 19.505 ms 2449 6 in.example.net (192.0.2.222) 20.333 ms 19.174 ms 19.856 ms 2450 7 egress.example.net (192.0.2.227) 20.268 ms 21.79 ms 19.992 ms 2451 8 routerin.example (192.0.2.253) 19.983 ms 19.931 ms 19.894 ms 2452 9 routerdmz.example (192.0.2.249) 20.943 ms !X * 19.829 ms !X 2454 It was executed with the TCP protocol and 128 byte packets (plus 2455 header). The traceroute ended at hop 9 because the packets are 2456 administratively filtered (!X). A corresponding XML representation 2457 follows: 2458 2459 2460 2461 Example 2 2462 2463 2464 2465 2466 2467 w2.example 2468 2469 2470 128 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 Show how it encodes in XML 2485 2486 2487 2488 2489 Example 2 2490 OpenBSD 2491 4.1 i386 2492 2493 traceroute 2494 2495 w2.example 2496 2497 2498 128 2499 2500 2501 2502 2503 2504 2505 192.0.2.42 2506 2507 1 2508 2509 2510 2511 2512 Show how it encodes in XML 2513 2514 2515 2516 Example 2 2517 2008-05-14T09:57:11+02:00 2519 2520 192.0.2.254 2521 2522 2523 2524 2525 2526 192.0.2.22 2527 2528 router1.example.org 2529 2530 0 2531 2532 responseReceived 2533 2534 2535 2536 2537 192.0.2.22 2538 2539 router1.example.org 2540 2541 0 2542 2543 responseReceived 2544 2545 2546 2547 2548 192.0.2.22 2549 2550 router1.example.org 2551 2552 0 2553 2554 responseReceived 2555 2556 2557 2558 2559 2560 2561 192.0.2.1 2562 2563 router7.example.org 2564 2565 3 2566 2567 responseReceived 2568 2569 2570 2571 2572 192.0.2.1 2573 2574 router7.example.org 2575 2576 1 2577 2578 responseReceived 2579 2580 2581 2582 2583 192.0.2.1 2584 2585 router7.example.org 2586 2587 1 2588 2589 responseReceived 2590 2591 2592 2593 2594 2595 2596 192.0.2.105 2597 2598 hop0.c.example 2599 2600 3 2601 2602 responseReceived 2603 2604 2605 2606 2607 192.0.2.105 2608 2609 hop0.c.example 2610 2611 3 2612 2613 responseReceived 2614 2615 2616 2617 2618 192.0.2.105 2619 2620 hop0.c.example 2621 2622 3 2623 2624 responseReceived 2625 2626 2627 2628 2629 2630 2631 192.0.2.107 2632 2633 hop6.c.example 2634 2635 5 2636 2637 responseReceived 2638 2639 2640 2641 2642 192.0.2.107 2643 2644 hop6.c.example 2645 2646 4 2647 2648 responseReceived 2649 2650 2651 2652 2653 192.0.2.107 2654 2655 hop6.c.example 2656 2657 5 2658 2659 responseReceived 2660 2662 2663 2664 2665 2666 2667 192.0.2.111 2668 2669 hop3.c.example 2670 2671 20 2672 2673 responseReceived 2674 2675 2676 2677 2678 192.0.2.111 2679 2680 hop3.c.example 2681 2682 20 2683 2684 responseReceived 2685 2686 2687 2688 2689 192.0.2.111 2690 2691 hop3.c.example 2692 2693 19 2694 2695 responseReceived 2696 2697 2698 2699 2700 2701 2702 192.0.2.222 2703 2704 in.example.net 2705 2706 20 2707 2708 responseReceived 2709 2711 2712 2713 2714 192.0.2.222 2715 2716 in.example.net 2717 2718 19 2719 2720 responseReceived 2721 2722 2723 2724 2725 192.0.2.222 2726 2727 in.example.net 2728 2729 19 2730 2731 responseReceived 2732 2733 2734 2735 2736 2737 2738 192.0.2.227 2739 2740 egress.example.net 2741 2742 20 2743 2744 responseReceived 2745 2746 2747 2748 2749 192.0.2.227 2750 2751 egress.example.net 2752 2753 21 2754 2755 responseReceived 2756 2757 2758 2759 2760 192.0.2.227 2761 2762 egress.example.net 2763 2764 19 2765 2766 responseReceived 2767 2768 2769 2770 2771 2772 2773 192.0.2.253 2774 2775 routerin.example 2776 2777 19 2778 2779 responseReceived 2780 2781 2782 2783 2784 192.0.2.253 2785 2786 routerin.example 2787 2788 19 2789 2790 responseReceived 2791 2792 2793 2794 2795 192.0.2.253 2796 2797 routerin.example 2798 2799 19 2800 2801 responseReceived 2802 2803 2804 2805 2806 2807 2808 192.0.2.249 2809 2810 routerdmz.example 2811 2812 20 2813 2814 unknown 2815 2816 2817 2818 2819 192.0.2.249 2820 2821 routerdmz.example 2822 2823 2824 2825 requestTimedOut 2826 2827 2828 2829 2830 192.0.2.249 2831 2832 routerdmz.example 2833 2834 19 2835 2836 unknown 2837 2838 2839 2840 2841 2008-05-14T09:57:30+02:00 2843 2844 2845 2847 The third and last example is based on the Microsoft Windows pendant 2848 of traceroute. On a MS Windows system the command is called 2849 "tracert" and typically looks as follows: 2851 # tracert -h 10 www.example.org 2853 Tracing route to www.example.org [192.0.2.11] 2854 over a maximum of 10 hops: 2856 1 1 ms 1 ms 8 ms 192.0.2.99 2857 2 <1 ms <1 ms <1 ms r1.provider4.example [192.0.2.102] 2858 3 <1 ms <1 ms <1 ms rtr8.provider8.example [192.0.2.254] 2859 4 1 ms 1 ms 1 ms hop11.hoster7.example [192.0.2.4] 2860 5 2 ms 3 ms 1 ms sw6.provider2.example [192.0.2.201] 2861 6 3 ms 3 ms 3 ms out.provider2.example [192.0.2.111] 2862 7 * 6 ms 5 ms 192.0.2.123 2863 8 5 ms 5 ms 5 ms 192.0.2.42 2864 9 94 ms 95 ms 95 ms ingress.example.org [192.0.2.199] 2865 10 168 ms 169 ms 169 ms 192.0.2.44 2867 Trace complete. 2869 In this example the trace was limited to 10 hops. So, the tenth and 2870 last hop of this example was not the final destination. Applying the 2871 XML schema defined in this document the trace could look as follows: 2872 2873 2874 2875 Example 3 2876 2877 2878 2879 2880 2881 www.example.org 2882 2883 2884 2885 2886 2887 2888 10 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 Show how it encodes in XML 2899 2900 2901 2902 2903 Example 3 2904 Windows 2905 XP SP2 32-bit 2906 2907 tracert 2908 2909 www.example.org 2910 2911 2912 2913 2914 2915 2916 10 2917 2918 2919 192.0.2.142 2920 2921 3 2922 2923 2924 2925 2926 Show how it encodes in XML 2927 2928 2929 2930 Example 3 2931 2008-05-14T11:03:09+02:00 2933 2934 192.0.2.11 2935 2936 2937 2938 2939 2940 192.0.2.99 2941 2942 2943 1 2944 2945 responseReceived 2946 2948 2949 2950 2951 192.0.2.99 2952 2953 2954 1 2955 2956 responseReceived 2957 2958 2959 2960 2961 192.0.2.99 2962 2963 2964 8 2965 2966 responseReceived 2967 2968 2969 2970 2971 2972 2973 192.0.2.102 2974 2975 r1.provider4.example 2976 2977 0 2978 2979 responseReceived 2980 2981 2982 2983 2984 192.0.2.102 2985 2986 r1.provider4.example 2987 2988 0 2989 2990 responseReceived 2991 2992 2993 2994 2995 192.0.2.102 2997 2998 r1.provider4.example 2999 3000 0 3001 3002 responseReceived 3003 3004 3005 3006 3007 3008 3009 192.0.2.254 3010 3011 rtr8.provider8.example 3012 3013 0 3014 3015 responseReceived 3016 3017 3018 3019 3020 192.0.2.254 3021 3022 rtr8.provider8.example 3023 3024 0 3025 3026 responseReceived 3027 3028 3029 3030 3031 192.0.2.254 3032 3033 rtr8.provider8.example 3034 3035 0 3036 3037 responseReceived 3038 3039 3040 3041 3042 3043 3044 192.0.2.4 3046 3047 hop11.hoster7.example 3048 3049 1 3050 3051 responseReceived 3052 3053 3054 3055 3056 192.0.2.4 3057 3058 hop11.hoster7.example 3059 3060 1 3061 3062 responseReceived 3063 3064 3065 3066 3067 192.0.2.4 3068 3069 hop11.hoster7.example 3070 3071 1 3072 3073 responseReceived 3074 3075 3076 3077 3078 3079 3080 192.0.2.201 3081 3082 sw6.provider2.example 3083 3084 2 3085 3086 responseReceived 3087 3088 3089 3090 3091 192.0.2.201 3092 3093 sw6.provider2.example 3094 3095 3 3096 3097 responseReceived 3098 3099 3100 3101 3102 192.0.2.201 3103 3104 sw6.provider2.example 3105 3106 1 3107 3108 responseReceived 3109 3110 3111 3112 3113 3114 3115 192.0.2.111 3116 3117 out.provider2.example 3118 3119 3 3120 3121 responseReceived 3122 3123 3124 3125 3126 192.0.2.111 3127 3128 out.provider2.example 3129 3130 3 3131 3132 responseReceived 3133 3134 3135 3136 3137 192.0.2.111 3138 3139 out.provider2.example 3140 3141 3 3143 3144 responseReceived 3145 3146 3147 3148 3149 3150 3151 192.0.2.123 3152 3153 3154 3155 3156 requestTimedOut 3157 3158 3159 3160 3161 192.0.2.123 3162 3163 3164 6 3165 3166 responseReceived 3167 3168 3169 3170 3171 192.0.2.123 3172 3173 3174 5 3175 3176 responseReceived 3177 3178 3179 3180 3181 3182 3183 192.0.2.42 3184 3185 3186 5 3187 3188 responseReceived 3189 3190 3191 3192 3193 192.0.2.42 3194 3195 3196 5 3197 3198 responseReceived 3199 3200 3201 3202 3203 192.0.2.42 3204 3205 3206 5 3207 3208 responseReceived 3209 3210 3211 3212 3213 3214 3215 192.0.2.199 3216 3217 ingress.example.org 3218 3219 94 3220 3221 responseReceived 3222 3223 3224 3225 3226 192.0.2.199 3227 3228 ingress.example.org 3229 3230 95 3231 3232 responseReceived 3233 3234 3235 3236 3237 192.0.2.199 3238 3239 ingress.example.org 3240 3241 95 3242 3243 responseReceived 3244 3245 3246 3247 3248 3249 3250 192.0.2.44 3251 3252 3253 168 3254 3255 responseReceived 3256 3257 3258 3259 3260 192.0.2.44 3261 3262 3263 169 3264 3265 responseReceived 3266 3267 3268 3269 3270 192.0.2.44 3271 3272 3273 169 3274 3275 responseReceived 3276 3277 3278 3279 3280 2008-05-14T11:03:23+02:00 3282 3283 3284 3286 The three examples given in this section are intended to give an 3287 impression on how a trace could be represented in XML. The 3288 representation generated by an implementation may differ from the 3289 examples here dependent on the system and the capabilities of the 3290 traceroute implementation. 3292 Authors' Addresses 3294 Saverio Niccolini 3295 NEC Laboratories Europe, NEC Europe Ltd. 3296 Kurfuersten-Anlage 36 3297 Heidelberg 69115 3298 Germany 3300 Phone: +49 (0) 6221 4342 118 3301 Email: saverio.niccolini@nw.neclab.eu 3302 URI: http://www.nw.neclab.eu 3304 Sandra Tartarelli 3305 NEC Laboratories Europe, NEC Europe Ltd. 3306 Kurfuersten-Anlage 36 3307 Heidelberg 69115 3308 Germany 3310 Phone: +49 (0) 6221 4342 132 3311 Email: sandra.tartarelli@nw.neclab.eu 3312 URI: http://www.nw.neclab.eu 3314 Juergen Quittek 3315 NEC Laboratories Europe, NEC Europe Ltd. 3316 Kurfuersten-Anlage 36 3317 Heidelberg 69115 3318 Germany 3320 Phone: +49 (0) 6221 4342 115 3321 Email: quittek@nw.neclab.eu 3322 URI: http://www.nw.neclab.eu 3323 Thomas Dietz 3324 NEC Laboratories Europe, NEC Europe Ltd. 3325 Kurfuersten-Anlage 36 3326 Heidelberg 69115 3327 Germany 3329 Phone: +49 (0) 6221 4342 128 3330 Email: thomas.dietz@nw.neclab.eu 3331 URI: http://www.nw.neclab.eu 3333 Martin Swany 3334 Dept. of Computer and Information Sciences, University of Delaware 3335 Newark DE 19716 3336 U.S.A. 3338 Email: swany@UDel.Edu 3340 Full Copyright Statement 3342 Copyright (C) The IETF Trust (2008). 3344 This document is subject to the rights, licenses and restrictions 3345 contained in BCP 78, and except as set forth therein, the authors 3346 retain all their rights. 3348 This document and the information contained herein are provided on an 3349 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3350 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3351 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3352 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3353 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3354 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3356 Intellectual Property 3358 The IETF takes no position regarding the validity or scope of any 3359 Intellectual Property Rights or other rights that might be claimed to 3360 pertain to the implementation or use of the technology described in 3361 this document or the extent to which any license under such rights 3362 might or might not be available; nor does it represent that it has 3363 made any independent effort to identify any such rights. Information 3364 on the procedures with respect to rights in RFC documents can be 3365 found in BCP 78 and BCP 79. 3367 Copies of IPR disclosures made to the IETF Secretariat and any 3368 assurances of licenses to be made available, or the result of an 3369 attempt made to obtain a general license or permission for the use of 3370 such proprietary rights by implementers or users of this 3371 specification can be obtained from the IETF on-line IPR repository at 3372 http://www.ietf.org/ipr. 3374 The IETF invites any interested party to bring to its attention any 3375 copyrights, patents or patent applications, or other proprietary 3376 rights that may cover technology that may be required to implement 3377 this standard. Please address the information to the IETF at 3378 ietf-ipr@ietf.org.