idnits 2.17.1 draft-ietf-ippm-storetraceroutes-12.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 3357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3381. 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 1875 has weird spacing: '...A |Set the t...' == Line 2862 has weird spacing: '... <1 ms r1.pr...' == Line 2863 has weird spacing: '... <1 ms rtr8....' == Line 2864 has weird spacing: '... 1 ms hop11...' == Line 2865 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 23, 2008) is 5626 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 26, 2009 T. Dietz 6 NEC 7 M. Swany 8 UDel 9 October 23, 2008 11 Information Model and XML Data Model for Traceroute Measurements 12 draft-ietf-ippm-storetraceroutes-12 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 26, 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 . . . . . . . . . . 42 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 . . . . . . . . 43 83 C.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 44 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 . . . . . 46 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 [W3C.REC-xmlschema-2-20041028]. 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 280 [W3C.REC-xmlschema-2-20041028] but restricted to the values 281 defined in [RFC3339]. 283 5.2. Information Elements 285 This section describes the elements related to the storing of a 286 traceroute measurement. The elements are grouped in two groups 287 (Configuration and Results) according to their semantics. In order 288 to relate configuration and results elements by means of a common 289 unique identifier, an additional element is defined belonging to both 290 the two groups. 292 5.2.1. Relationship between the Information Elements 294 Every traceroute measurement is represented by an instance of the 295 "traceRoute" element. This class provides a standardized 296 representation for traceroute measurement data. The "traceroute" 297 element is an element that can be composed of (depending on the 298 nature of the traceroute measurement): 300 o 1 optional "RequestMetadata" element; 301 o 0..4294967295 "Measurement" elements; 303 Each "Measurement" element contains: 305 o 1 optional "MeasurementMetadata" element; 306 o 0..4294967295 "MeasurementResult" elements; 308 The "RequestMetadata" element can be used for specifying parameters 309 of a traceroute measurement to be performed at one or more nodes by 310 one or more traceroute implementations. Depending on the 311 capabilities of a traceroute implementation, not all requested 312 parameters can be applied. Which parameters have actually been 313 applied by for specific traceroute measurement is specified in a 314 "MeasurementMetadata" element. 316 The "RequestMetadata" element is a sequence that contains: 318 o 1 "TestName" element; 319 o 1 optional "ToolVersion" element; 320 o 1 optional "ToolName" element; 321 o 1 "CtlTargetAddress" element; 322 o 1 optional "CtlBypassRouteTable" element; 323 o 1 optional "CtlProbeDataSize" element; 324 o 1 optional "CtlTimeOut" element; 325 o 1 optional "CtlProbesPerHop" element; 326 o 1 optional "CtlPort" element; 327 o 1 optional "CtlMaxTtl" element; 328 o 1 optional "CtlDSField" element; 329 o 1 optional "CtlSourceAddress" element; 330 o 1 optional "CtlIfIndex" element; 331 o 1 optional "CtlMiscOptions" element; 332 o 1 optional "CtlMaxFailures" element; 333 o 1 optional "CtlDontFragment" element; 334 o 1 optional "CtlInitialTtl" element; 335 o 1 optional "CtlDescr" element; 336 o 1 "CtlType" element; 338 If the "RequestMetadata" element is omitted from an XML file then it 339 means that the traceroute measurement configuration parameters 340 requested were all used and the "MeasurementMetadata" element list 341 them in detail. 343 The "MeasurementMetadata" element is a sequence that contains: 345 o 1 "TestName" element; 346 o 1 "OSName" element; 347 o 1 "OSVersion" element; 348 o 1 "ToolVersion" element; 349 o 1 "ToolName" element; 350 o 1 "CtlTargetAddressType" element; 351 o 1 "CtlTargetAddress" element; 352 o 1 "CtlBypassRouteTable" element; 353 o 1 "CtlProbeDataSize" element; 354 o 1 "CtlTimeOut" element; 355 o 1 "CtlProbesPerHop" element; 356 o 1 "CtlPort" element; 357 o 1 "CtlMaxTtl" element; 358 o 1 "CtlDSField" element; 359 o 1 "CtlSourceAddressType" element; 360 o 1 "CtlSourceAddress" element; 361 o 1 "CtlIfIndex" element; 362 o 1 optional "CtlMiscOptions" element; 363 o 1 "CtlMaxFailures" element; 364 o 1 "CtlDontFragment" element; 365 o 1 "CtlInitialTtl" element; 366 o 1 optional "CtlDescr" element; 367 o 1 "CtlType" element; 369 Configuration Information Elements can describe not just traceroute 370 measurements that have already happened ("MeasurementMetadata" 371 elements), but also configuration to be used when requesting a 372 measurement to be made ("RequestMetadata" element). This is quite 373 different semantically, even if the individual information elements 374 are similar. Due to this similarity both "RequestMetadata" as well 375 as "MeasurementMetadata" are represented by the same type in the XML 376 schema. All elements that are missing from the "RequestMetadata" or 377 marked as optional in the "RequestMetadata" but mandatory in the 378 "MeasurementMetadata" must be specified as empty elements. 379 Specifying them as empty elements means use the default value. The 380 "CtlType" element could have been optional in the "RequestMetadata" 381 but since default values cannot be specified for complex types in an 382 XML schema the element is mandatory also in the "RequestMetadata". 384 The "MeasurementResult" element is a sequence that contains: 386 o 1 "TestName" element; 387 o 1 "ResultsStartDateAndTime" element; 388 o 1 "ResultsIpTgtAddrType" element; 389 o 1 "ResultsIpTgtAddr" element; 390 o 1 "ProbeResults" elements; 391 o 1 "ResultsEndDateAndTime" element; 393 Additionally it is important to say that each "ProbeResults" element 394 is a sequence that contains: 396 o 1..255 "hop" elements; 398 Each "hop" element is a sequence that contains 400 o 1..10 "probe" elements; 401 o 1 optional "HopRawOutputData" element; 403 Each "probe" element contains: 405 o 1 "HopAddrType" element; 406 o 1 "HopAddr" element; 407 o 1 optional "HopName" element; 408 o 0..255 optional "MPLSLabelStackEntry" elements; 409 o 1 "ProbedRoundTripTime" element; 410 o 1 "ResponseStatus" element; 411 o 1 "Time" element; 413 Different numbers of appearances of the three basic elements in the 414 XML file are meant for different scopes: 416 o a file with only 1 "RequestMetadata" element represents a file 417 containing the traceroute measurement configuration parameters of 418 a traceroute measurement, it can be used to distribute the 419 traceroute measurement configuration parameters over multiple 420 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) [W3C.REC-xml-20060816] is an obvious choice. XML supports 901 clean structuring of data and syntax checking of records. With some 902 limitations it is human readable. It is supported well by a huge 903 pool of tools and standards for generating, transmitting, parsing and 904 converting it to other data formats. Its disadvantages is the 905 resource consumption for processing, storing, and transmitting 906 information. Since the expected data volumes related to traceroute 907 measurements in network operation and maintenance is not expected to 908 be extremely high, the inefficient usage of resources is not a 909 significant disadvantage. Therefore, XML was chosen as basis for the 910 traceroute measurements information model that is specified in this 911 section. 913 Section 7 contains the XML schema to be used as a template for 914 storing and/or exchanging traceroute measurements information. The 915 schema was designed in order to use an extensible approach based on 916 templates (pretty similar to how IPFIX protocol is designed) where 917 the traceroute configuration elements (both the requested parameters, 918 Request, and the actual parameters used, MeasurementMetadata) are 919 meta data to be referenced by results information elements (data) by 920 means of the TestName element (used as unique identifier, chosen in 921 accordance to the specification of [RFC4560]). Currently Open Grid 922 Forum (OGF) is also using this approach and cross-requirements have 923 been analyzed. As a result of this analysis the XML schema contained 924 in Section 7 is compatible with OGF schema since it was designed in a 925 way that both limits the unnecessary redundancy and a simple one-to- 926 one transformation between the two exist. 928 7. XML Schema for traceroute Measurements 930 This section presents the XML schema to be used as a template for 931 storing and/or exchanging traceroute measurements information. The 932 schema uses UTF-8 encoding defined in [RFC3629]. In documents 933 conforming to the format presented here an XML declaration SHOULD be 934 present specifying the version and the character encoding of the XML 935 document. The document should be encoded using UTF-8. Since some of 936 the strings can span multiple lines [RFC5198] applies. XML 937 processing instructions and comments MUST be ignored. Mind that 938 whitespace is significant in XML when writing documents conforming to 939 this schema. Documents using the presented format must be valid 940 according to the XML schema shown in this section. This includes all 941 elements. Since elements of type _CtlType may contain elements from 942 unknown namespaces those elements MUST be ignored if their namespace 943 is unknown to the processor. Values for elements using the XML 944 schema type dateTime MUST be restricted to values defined in 945 [RFC3339]. Future versions of this format MAY extend this schema by 946 creating a new schema that redefines all or parts of the data types 947 and elements defined in this version or by establishing a complete 948 new schema. 950 Due to the limited line length some lines appear wrapped. 952 953 957 958 959 String restricted to 255 960 characters. 961 963 964 965 966 968 969 970 usginedByte with non zero 971 value. 972 974 975 976 977 979 980 981 982 983 984 985 987 988 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 [W3C.REC-xml-20060816] 1769 Paoli, J., Yergeau, F., Sperberg-McQueen, C., Bray, T., 1770 and E. Maler, "Extensible Markup Language (XML) 1.0 1771 (Fourth Edition)", World Wide Web Consortium 1772 Recommendation REC-xml-20060816, August 2006, 1773 . 1775 [W3C.REC-xmlschema-2-20041028] 1776 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1777 Second Edition", World Wide Web Consortium 1778 Recommendation REC-xmlschema-2-20041028, October 2004, 1779 . 1781 Appendix A. Traceroute Default Configuration Parameters 1783 This section lists traceroute measurement configuration parameters as 1784 well as their defaults on various platforms and illustrates how 1785 widely they may vary. This document considered four major traceroute 1786 tool implementations and compared them based on configurable 1787 parameters and default values. The LINUX (SUSE 9.1), BSD (FreeBSD 1788 7.0) and UNIX (SunOS 5.9) implementations are based on UDP datagrams, 1789 while the WINDOWS (XP SP2) one uses ICMP Echoes. The comparison is 1790 summarized in the following table, where an N/A in the option column, 1791 means that such parameter is not configurable for the specific 1792 implementation. A comprehensive comparison of available 1793 implementations is outside the scope of this document; however, 1794 already by sampling a few different implementations, it can be 1795 observed that they can differ quite significantly in terms of 1796 configurable parameters and also default values. Note that in the 1797 following table only those options which are available in at least 1798 two of the considered implementations are reported. 1800 +---------------------------------------------------------+ 1801 | OS |Option| Description | Default | 1802 +--------+------+-------------------------------+---------+ 1803 | LINUX | -m |Specify the maximum TTL used | 30 | 1804 |--------+------|in traceroute probes. |---------| 1805 | FreeBSD| -m | | OS var | 1806 |--------+------| |---------| 1807 | UNIX | -m | | 30 | 1808 |--------+------| |---------| 1809 | WINDOWS| -h | | 30 | 1810 +--------+------+-------------------------------+---------+ 1811 | LINUX | -n |Display hop addresses | - | 1812 |--------+------|numerically rather than |---------| 1813 | FreeBSD| -n |symbolically. | - | 1814 |--------+------| |---------| 1815 | UNIX | -n | | - | 1816 |--------+------| |---------| 1817 | WINDOWS| -d | | - | 1818 +--------+------+-------------------------------+---------+ 1819 | LINUX | -w |Set the time to wait for a | 3 sec | 1820 |--------+------|response to a probe. |---------| 1821 | FreeBSD| -w | | 5 sec | 1822 |--------+------| |---------| 1823 | UNIX | -w | | 5 sec | 1824 |--------+------| |---------| 1825 | WINDOWS| -w | | 4 sec | 1826 +--------+------+-------------------------------+---------+ 1827 | LINUX | N/A |Specify a loose source route | - | 1828 |--------+------|gateway (to direct the |---------| 1829 | FreeBSD| -g |traceroute probes through | - | 1830 |--------+------|routers not necessarily in |---------| 1831 | UNIX | -g | the path). | - | 1832 |--------+------| |---------| 1833 | WINDOWS| -g | | - | 1834 +--------+------+-------------------------------+---------+ 1835 | LINUX | -p |Set the base UDP port number | 33434 | 1836 |------- +------|used in traceroute probes |---------| 1837 | FreeBSD| -p |(UDP port = base + nhops - 1). | 33434 | 1838 |--------+------| |---------| 1839 | UNIX | -p | | 33434 | 1840 |--------+------| |---------| 1841 | WINDOWS| N/A | | - | 1842 +--------+------+-------------------------------+---------+ 1843 | LINUX | -q |Set the number of probes per | 3 | 1844 |--------+------|TTL. |---------| 1845 | FreeBSD| -q | | 3 | 1846 |--------+------| |---------| 1847 | UNIX | -q | | 3 | 1848 |--------+------| |---------| 1849 | WINDOWS| N/A | | 3 | 1850 +--------+------+-------------------------------+---------+ 1851 | LINUX | -S |Set the IP source address in |IP | 1852 |--------+------|outgoing probes to the |address | 1853 | FreeBSD| -s |specified value. |of the | 1854 |--------+------| |out | 1855 | UNIX | -s | |interface| 1856 |--------+------| | | 1857 | WINDOWS| N/A | | | 1858 +--------+------+-------------------------------+---------+ 1859 | LINUX | -t |Set the type-of-service (TOS) | 0 | 1860 |--------+------|in the probes to the specified |---------| 1861 | FreeBSD| -t |value. | 0 | 1862 |--------+------| |---------| 1863 | UNIX | -t | | 0 | 1864 |--------+------| |---------| 1865 | WINDOWS| N/A | | 0 | 1866 +--------+------+-------------------------------+---------+ 1867 | LINUX | -v |Verbose output: received ICMP | - | 1868 |--------+------|packets other than |---------| 1869 | FreeBSD| -v |TIME_EXCEEDED and | - | 1870 |--------+------|UNREACHABLE are listed. |---------| 1871 | UNIX | -v | | - | 1872 |--------+------| |---------| 1873 | WINDOWS| N/A | | - | 1874 +--------+------+-------------------------------+---------+ 1875 | LINUX | N/A |Set the time (in msec) to | - | 1876 |--------+------|pause between probes. |---------| 1877 | FreeBSD| -z | | 0 | 1878 |--------+------| |---------| 1879 | UNIX | -P | | 0 | 1880 |--------+------| |---------| 1881 | WINDOWS| N/A | | - | 1882 +--------+------+-------------------------------+---------+ 1883 | LINUX | -r |Bypass the normal routing | - | 1884 |--------+------|tables and send directly to a |---------| 1885 | FreeBSD| -r |host on attached network. | - | 1886 |--------+------| |---------| 1887 | UNIX | -r | | - | 1888 |--------+------| |---------| 1889 | WINDOWS| N/A | | - | 1890 +--------+------+-------------------------------+---------+ 1891 | LINUX | -f |Set the initial TTL for the | 1 | 1892 |--------+------|first probe. |---------| 1893 | FreeBSD| -f | | 1 | 1894 |--------+------| |---------| 1895 | UNIX | -f | | 1 | 1896 |--------+------| |---------| 1897 | WINDOWS| N/A | | 1 | 1898 +--------+------+-------------------------------+---------+ 1899 | LINUX | -F |Set the "don't fragment" bit. | - | 1900 |--------+------| |---------| 1901 | FreeBSD| -F | | - | 1902 |--------+------| |---------| 1903 | UNIX | -F | | - | 1904 |--------+------| |---------| 1905 | WINDOWS| N/A | | - | 1906 +--------+------+-------------------------------+---------+ 1907 | LINUX | N/A |Enables socket level debugging.| - | 1908 |--------+------| |---------| 1909 | FreeBSD| -d | | - | 1910 |--------+------| |---------| 1911 | UNIX | -d | | - | 1912 |--------+------| |---------| 1913 | WINDOWS| N/A | | - | 1914 +--------+------+-------------------------------+---------+ 1915 | LINUX | N/A |Use ICMP ECHO instead of UDP | - | 1916 |--------+------|datagrams. |---------| 1917 | FreeBSD| -I | | - | 1918 |--------+------| |---------| 1919 | UNIX | -I | | - | 1920 |--------+------| |---------| 1921 | WINDOWS| N/A | | - | 1922 +--------+------+-------------------------------+---------+ 1923 | LINUX | -I |Specify a network interface to | - | 1924 |--------+------|obtain the IP address for |---------| 1925 | FreeBSD| -i |outgoing IP packets | - | 1926 |--------+------|(alternative to option -s). |---------| 1927 | UNIX | -i | | - | 1928 |--------+------| |---------| 1929 | WINDOWS| N/A | | - | 1930 +--------+------+-------------------------------+---------+ 1931 | LINUX | N/A |Toggle checksum. | - | 1932 |--------+------| |---------| 1933 | FreeBSD| -x | | - | 1934 |--------+------| |---------| 1935 | UNIX | -x | | - | 1936 |--------+------| |---------| 1937 | WINDOWS| N/A | | - | 1938 +--------+------+-------------------------------+---------+ 1939 | LINUX | - |As optional last parameter, |Depends | 1940 |--------+------|LINUX, FreeBSD and UNIX |on | 1941 | FreeBSD| - |implementations allow |implement| 1942 |--------+------|specifying the probe datagram |ation. | 1943 | UNIX | - |length for outgoing probes. | | 1944 |--------+------| | | 1945 | WINDOWS| N/A | | | 1946 +--------+------+-------------------------------+---------+ 1948 A.1. Alternative Traceroute Implementations 1950 As stated above, the widespread use of firewalls might prevent UDP or 1951 ICMP based traceroutes to completely trace the path to a destination, 1952 since traceroute probes might end up being filtered. In some cases, 1953 such limitation might be overcome by sending instead TCP packets to 1954 specific ports that hosts located behind the firewall are listening 1955 for connections on. TCP based implementations use TCP SYN or FIN 1956 probes and listen for TIME_EXCEEDED messages, TCP RESET and other 1957 messages from firewalls and gateways on the path. On the other hand, 1958 some firewalls filter out TCP SYN packets to prevent denial of 1959 service attacks, therefore the actual advantage of using TCP instead 1960 of UDP traceroute depends mainly on firewall configurations, which 1961 are not known in advance. A detailed analysis of TCP-based 1962 traceroute tools and measurements was outside the scope of this 1963 document, anyway for completeness reasons the information model 1964 supports the storing of TCP-based traceroute measurements, too. 1966 Appendix B. Known Problems with Traceroute 1968 B.1. Compatibility between traceroute measurements results and IPPM 1969 metrics 1971 Because of implementation choices, a known inconsistency exists 1972 between the round-trip delay metric defined by the IPPM working group 1973 in RFC 2681 and the results returned by the current traceroute tool 1974 implementations. Unfortunately, it is unlikely that the traceroute 1975 tool implementations will implement the standard definition in the 1976 near future. The only possibility is therefore to compare results of 1977 different traceroute measurements one with each other; in order to do 1978 this, specifications both of the operating system (name and version) 1979 and of the traceroute tool version used were added to the metadata 1980 elements in order to help in comparing metrics between two different 1981 traceroute measurements results (if run using the same operating 1982 system and the same version of the tool). Moreover, the traceroute 1983 tool has built-in configurable mechanisms like time-outs and can 1984 experience problems related to the crossing of firewalls; therefore 1985 some of the packets that traceroute sends out end up being time-out 1986 or filtered. As a consequence, it might not be possible to trace the 1987 path to a node or there might not be a complete set of probes 1988 describing the RTT to reach it. 1990 Appendix C. Differences to DISMAN-TRACEROUTE-MIB 1992 For performing remote traceroute operations at managed node, the IETF 1993 has standardized the DISMAN-TRACEROUTE-MIB module in [RFC4560]. This 1994 module allows: 1996 o retrieving capability information of the traceroute tool 1997 implementation at the managed node, 1998 o configuring traceroute measurements to be performed, 1999 o retrieving information about ongoing and completed traceroute 2000 measurements, 2001 o retrieving traceroute measurement statistics. 2003 The traceroute storage format described in this document has 2004 significant overlaps with this MIB module. Particularly, the models 2005 for the traceroute measurement configuration and for the result from 2006 completed measurements are almost identical. But for other pats of 2007 the DISMAN-TRACEROUTE MIB module there is no need to model them in a 2008 traceroute measurements storage format. Particularly, the capability 2009 information, information about ongoing measurements and measurement 2010 statistics are not covered by the DISMAN traceroute storage model. 2012 Concerning traceroute measurements and their results, there are 2013 structural differences between the two models caused by the different 2014 choices for the encoding of the specification. For DISMAN- 2015 TRACEROUTE-MIB, the Structure of Management Information (SMIv2, STD 2016 58, RFC 2578 [RFC2578]) was used, while the IPPM traceroute 2017 measurements data model is encoded using XML. 2019 This difference in structure implies that the DISMAN-TRACEROUTE-MIB 2020 module contains SMI-specific information element (managed objects) 2021 that concern tables of managed objects (specification, entry creation 2022 and deletion, status retrieval) that are not required for the XML- 2023 encoded traceroute measurements data model. 2025 But for most of the remaining information elements that concern 2026 configuration of traceroute measurements and results of completed 2027 measurements, the semantics is identical between the DISMAN- 2028 TRACEROUTE-MIB module and the traceroute measurements data model. 2029 There are very few exceptions to this which are listed below. Also 2030 naming of information elements is identical between both models with 2031 a few exceptions. For the traceroute measurements data model, a few 2032 information elements have been added, some because of the different 2033 structure and some to provide additional information on completed 2034 measurements. 2036 C.1. Scope 2038 There are some basic differences in nature and application between 2039 MIB modules and XML documents. This results in two major differences 2040 of Scope between the DISMAN-TRACEROUTE-MIB module and the traceroute 2041 measurements data model. 2043 The first difference is the traceRouteResultsTable contained in the 2044 DISMAN-TRACEROUTE-MIB module. This table allows online observation 2045 of status and progress of an ongoing traceroute measurement. This 2046 highly dynamic information is not included in the traceroute 2047 measurements data model, because it has not been envisioned to use 2048 the model for dynamically reporting progress of individual traceroute 2049 measurements. The traceroute measurements data model is rather 2050 intended to be used for reporting completed traceroute measurements. 2052 The second difference is due to the fact that information in a MIB is 2053 typically tied to a local node hosting the MIB instance. The 2054 "RequestMetadata" element specified in the traceroute measurements 2055 data model can be used for specifying a measurement request that may 2056 be applied to several probes in a network. This concept does not 2057 exist in the DISMAN-TRACEROUTE-MIB module. 2059 For the remaining elements in the DISMAN-TRACEROUTE-MIB module and in 2060 the traceroute measurements data model there is a very good match 2061 between the two worlds. The traceRouteCtlTable corresponds to the 2062 "MeasurementMetadata" element and the combination of the 2063 traceRouteProbeHistoryTable and the traceRouteHopsTable corresponds 2064 to a collection of "MeasurementResult" elements. 2066 C.2. Naming 2068 Basically, names in both models are chosen using the same naming 2069 conventions. 2071 For the traceroute measurement configuration information all names, 2072 such as CtlProbesPerHop, are identical in both models except for the 2073 traceRoute prefix that was removed to avoid unnecessary redundancy in 2074 the XML file and for CtlDataSize which was renamed to 2075 CtlProbeDataSize for clarification in the traceroute measurements 2076 data model. 2078 Results of measurements in the DISMAN-TRACEROUTE-MIB modules are 2079 distributed over two tables, the traceRouteResultsTable containing 2080 mainly information about ongoing measurements and the 2081 traceRouteProbeHistoryTable containing only information about 2082 completed measurements. According to the SMIv2 naming conventions 2083 names of information elements in these tables have different prefixes 2084 (traceRouteResults and traceRouteProbeHistory). Since the traceroute 2085 measurements data model only reports on completed measurements, this 2086 separation is not needed anymore and the prefix "Results" is used for 2087 all related information elements. 2089 Beyond that, there are only a few changes in element names. The 2090 renaming actions include: 2092 o traceRouteProbeHistoryResponse to ProbeRoundTripTime, 2093 o traceRouteProbeHistoryHAddr to HopAddr, 2094 o traceRouteProbeHistoryTime to ResultsEndDateAndTime, 2095 o traceRouteProbeHistoryLastRC to ResultsHopRawOutputData. 2097 C.3. Semantics 2099 The semantics was changed for two information elements only. 2101 For traceRouteProbeHistoryResponse in the DISMAN-TRACEROUTE-MIB, a 2102 value of 0 indicated, that it was not possible to transmit a probe. 2103 For the traceroute measurements data model, a value of 0 for element 2104 RoundTripTime indicates that the measured time was less than one 2105 millisecond, while for the case that it was not possible to transmit 2106 a probe a string is used that indicates the problem. 2108 For traceRouteCtlIfIndex in the DISMAN-TRACEROUTE-MIB, a value of 0 2109 indicated, that it the option to set the index is not available. 2110 This was translated to the traceroute measurements data model, such 2111 that a value of 0 for this element indicates that the used interface 2112 is unknown. 2114 The element traceRouteProbeHistoryLastRC in the DISMAN-TRACEROUTE-MIB 2115 was replaced by element ResultsHopRawOutputData. While 2116 traceRouteProbeHistoryLastRC just reports a reply code, 2117 ResultsHopRawOutputData reports the full raw output data (per hop) 2118 produced by the traceroute measurements that was used. 2120 C.4. Additional Information Elements 2122 Only a few information elements have been added to the model of the 2123 DISMAN-TRACEROUTE-MIB module. 2125 o For providing information on the MPLS label stack entries of a 2126 probe in the traceroute measurement path MPLSLabelStackEntry was 2127 added. 2128 o For providing additional timestamp beyond ResultsEndDateAndTime, 2129 ResultsStartDateAndTime and Time were added. 2131 o For providing DNS names at the time of the execution of the 2132 traceroute for each HopAddr (which may change over time) HopName 2133 was added. 2135 Appendix D. Traceroute Examples with XML representation 2137 This Section shows some examples of traceroute applications. In 2138 addition the encoding of requests and results is shown for some of 2139 those examples. Note that also in these XML examples some lines 2140 appear wrapped due to the limited length of line. 2142 A typical traceroute on a linux system looks like the following: 2143 # traceroute -f 4 www.example 1500 2144 traceroute to ww.example (192.0.2.42), 30 hops max, 1500 byte packets 2145 5 out.host1.example (192.0.2.254) 6.066 ms 5.625 ms 6.095 ms 2146 6 rtr4.host6.example (192.0.2.142) 6.979 ms 6.221 ms 7.368 ms 2147 7 hop7.rtr9.example (192.0.2.11) 16.165 ms 15.347 ms 15.514 ms 2148 8 192.0.2.222 (192.0.2.222) 32.796 ms 28.723 ms 26.988 ms 2149 9 in.example (192.0.2.123) 15.861 ms 16.262 ms 17.610 ms 2150 10 in.example (192.0.2.123)(N!) 17.391 ms * * 2152 This traceroute ignores the first 4 hops and uses 1500 byte packets. 2153 It does not reach its goal since the last listed hop says that the 2154 network is not reachable (N!). The XML representation for this trace 2155 follows: 2156 2157 2158 2159 Example 1 2160 2161 2162 2163 2164 2165 www.example 2166 2167 2168 1500 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 4 2182 Show how it encodes in XML 2183 2184 2185 2186 2187 Example 1 2188 Linux 2189 2.6.16.54-0.2.5-smp i386 2190 1.0 2191 traceroute 2192 2193 www.example 2194 2195 2196 1500 2197 2198 2199 2200 2201 2202 2203 192.0.2.1 2204 2205 2 2206 2207 2208 2209 4 2210 Show how it encodes in XML 2211 2212 2213 2214 Example 1 2215 2008-05-16T14:22:34+02:00 2217 2218 192.0.2.42 2219 2220 2221 2222 2223 2224 192.0.2.254 2225 2226 out.host1.example 2227 2228 6 2229 2230 responseReceived 2231 2232 2233 2234 2235 192.0.2.254 2236 2237 out.host1.example 2238 5 2240 responseReceived 2241 2242 2243 2244 2245 192.0.2.254 2246 2247 out.host1.example 2248 2249 6 2250 2251 responseReceived 2252 2253 2254 5 out.host1.example (192.0.2.254) 6.06 2255 6 ms 5.625 ms 6.095 ms 2256 2257 2258 2259 2260 192.0.2.142 2261 2262 rtr4.host6.example 2263 2264 6 2265 2266 responseReceived 2267 2268 2269 2270 2271 192.0.2.142 2272 2273 rtr4.host6.example 2274 2275 6 2276 2277 responseReceived 2278 2279 2280 2281 2282 192.0.2.142 2283 2284 rtr4.host6.example 2285 2286 7 2287 2288 responseReceived 2289 2290 2291 6 rtr4.host6.example (192.0.2.142) 6.9 2292 79 ms 6.221 ms 7.368 ms 2293 2294 2295 2296 2297 192.0.2.11 2298 2299 hop7.rtr9.example 2300 2301 16 2302 2303 responseReceived 2304 2305 2306 2307 2308 192.0.2.11 2309 2310 hop7.rtr9.example 2311 2312 15 2313 2314 responseReceived 2315 2316 2317 2318 2319 192.0.2.11 2320 2321 hop7.rtr9.example 2322 2323 15 2324 2325 responseReceived 2326 2327 2328 7 hop7.rtr9.example (192.0.2.11) 16.16 2329 5 ms 15.347 ms 15.514 ms 2330 2331 2332 2333 2334 192.0.2.222 2335 2336 2337 32 2338 2339 responseReceived 2340 2341 2342 2343 2344 192.0.2.222 2345 2346 2347 38 2348 2349 responseReceived 2350 2351 2352 2353 2354 192.0.2.222 2355 2356 2357 26 2358 2359 responseReceived 2360 2361 2362 8 192.0.2.222 (192.0.2.222) 32.796 ms 2363 28.723 ms 26.988 ms 2364 2365 2366 2367 2368 192.0.2.123 2369 2370 in.example 2371 2372 15 2373 2374 responseReceived 2375 2376 2377 2378 2379 192.0.2.123 2380 2381 in.example 2382 2383 16 2384 2385 responseReceived 2386 2387 2388 2389 2390 192.0.2.123 2391 2392 in.example 2393 2394 17 2395 2396 responseReceived 2397 2398 2399 9 in.example (192.0.2.123) 15.861 ms 2400 16.262 ms 17.610 ms 2401 2402 2403 2404 2405 192.0.2.123 2406 2407 in.example 2408 2409 17 2410 2411 noRouteToTarget 2412 2413 2414 2415 2416 192.0.2.123 2417 2418 in.example 2419 2420 2421 2422 requestTimedOut 2423 2424 2425 2426 2427 192.0.2.123 2428 2429 in.example 2430 2431 2432 2433 requestTimedOut 2434 2435 2436 10 in.example (192.0.2.123)(N!) 17.391 2437 ms * * 2438 2439 2440 2008-05-16T14:22:44+02:00 2442 2443 2444 2446 The second example was generated on an OpenBSD system. On that 2447 system the traceroute looks the following: 2448 # traceroute -P tcp w2.example 128 2450 traceroute to w2.example (192.0.2.254), 64 hops max, 160 byte packets 2451 1 router1.example.org (192.0.2.22) 0.486 ms 0.486 ms 0.482 ms 2452 2 router7.example.org (192.0.2.1) 3.27 ms 1.420 ms 1.873 ms 2453 3 hop0.c.example (192.0.2.105) 3.177 ms 3.258 ms 3.859 ms 2454 4 hop6.c.example (192.0.2.107) 5.994 ms 4.607 ms 5.678 ms 2455 5 hop3.c.example (192.0.2.111) 20.341 ms 20.732 ms 19.505 ms 2456 6 in.example.net (192.0.2.222) 20.333 ms 19.174 ms 19.856 ms 2457 7 egress.example.net (192.0.2.227) 20.268 ms 21.79 ms 19.992 ms 2458 8 routerin.example (192.0.2.253) 19.983 ms 19.931 ms 19.894 ms 2459 9 routerdmz.example (192.0.2.249) 20.943 ms !X * 19.829 ms !X 2461 It was executed with the TCP protocol and 128 byte packets (plus 2462 header). The traceroute ended at hop 9 because the packets are 2463 administratively filtered (!X). A corresponding XML representation 2464 follows: 2465 2466 2467 2468 Example 2 2469 2470 2471 2472 2473 2474 w2.example 2475 2476 2477 128 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 Show how it encodes in XML 2492 2493 2494 2495 2496 Example 2 2497 OpenBSD 2498 4.1 i386 2499 2500 traceroute 2501 2502 w2.example 2503 2504 2505 128 2506 2507 2508 2509 2510 2511 2512 192.0.2.42 2513 2514 1 2515 2516 2517 2518 2519 Show how it encodes in XML 2520 2521 2522 2523 Example 2 2524 2008-05-14T09:57:11+02:00 2526 2527 192.0.2.254 2528 2529 2530 2531 2532 2533 192.0.2.22 2534 2535 router1.example.org 2536 2537 0 2538 2539 responseReceived 2540 2541 2542 2543 2544 192.0.2.22 2545 2546 router1.example.org 2547 2548 0 2549 2550 responseReceived 2551 2552 2553 2554 2555 192.0.2.22 2556 2557 router1.example.org 2558 2559 0 2560 2561 responseReceived 2562 2563 2564 2565 2566 2567 2568 192.0.2.1 2569 2570 router7.example.org 2571 2572 3 2573 2574 responseReceived 2575 2576 2577 2578 2579 192.0.2.1 2580 2581 router7.example.org 2582 2583 1 2584 2585 responseReceived 2586 2587 2588 2589 2590 192.0.2.1 2591 2592 router7.example.org 2593 2594 1 2595 2596 responseReceived 2597 2598 2599 2600 2601 2602 2603 192.0.2.105 2604 2605 hop0.c.example 2606 2607 3 2608 2609 responseReceived 2610 2611 2612 2613 2614 192.0.2.105 2615 2616 hop0.c.example 2617 2618 3 2619 2620 responseReceived 2621 2622 2623 2624 2625 192.0.2.105 2626 2627 hop0.c.example 2628 2629 3 2630 2631 responseReceived 2632 2633 2634 2635 2636 2637 2638 192.0.2.107 2639 2640 hop6.c.example 2641 2642 5 2643 2644 responseReceived 2645 2646 2647 2648 2649 192.0.2.107 2650 2651 hop6.c.example 2652 2653 4 2654 2655 responseReceived 2656 2657 2658 2659 2660 192.0.2.107 2661 2662 hop6.c.example 2663 2664 5 2665 2666 responseReceived 2667 2668 2669 2670 2671 2672 2673 192.0.2.111 2674 2675 hop3.c.example 2676 2677 20 2678 2679 responseReceived 2680 2681 2682 2683 2684 192.0.2.111 2685 2686 hop3.c.example 2687 2688 20 2689 2690 responseReceived 2691 2692 2693 2694 2695 192.0.2.111 2696 2697 hop3.c.example 2698 2699 19 2700 2701 responseReceived 2702 2703 2704 2705 2706 2707 2708 192.0.2.222 2709 2710 in.example.net 2711 2712 20 2713 2714 responseReceived 2715 2716 2717 2718 2719 192.0.2.222 2720 2721 in.example.net 2722 2723 19 2724 2725 responseReceived 2726 2727 2728 2729 2730 192.0.2.222 2731 2732 in.example.net 2733 2734 19 2735 2736 responseReceived 2737 2738 2739 2740 2741 2742 2743 192.0.2.227 2744 2745 egress.example.net 2746 2747 20 2748 2749 responseReceived 2750 2751 2752 2753 2754 192.0.2.227 2755 2756 egress.example.net 2757 2758 21 2759 2760 responseReceived 2761 2762 2763 2764 2765 192.0.2.227 2766 2767 egress.example.net 2768 2769 19 2770 2771 responseReceived 2772 2773 2774 2775 2776 2777 2778 192.0.2.253 2779 2780 routerin.example 2781 2782 19 2783 2784 responseReceived 2785 2786 2787 2788 2789 192.0.2.253 2790 2791 routerin.example 2792 2793 19 2794 2795 responseReceived 2796 2797 2798 2799 2800 192.0.2.253 2801 2802 routerin.example 2803 2804 19 2805 2806 responseReceived 2807 2808 2809 2810 2811 2812 2813 192.0.2.249 2814 2815 routerdmz.example 2816 2817 20 2818 2819 unknown 2820 2821 2822 2823 2824 192.0.2.249 2825 2826 routerdmz.example 2827 2828 2829 2830 requestTimedOut 2831 2832 2833 2834 2835 192.0.2.249 2836 2837 routerdmz.example 2838 2839 19 2840 2841 unknown 2842 2843 2844 2845 2846 2008-05-14T09:57:30+02:00 2848 2849 2851 2853 The third and last example is based on the Microsoft Windows pendant 2854 of traceroute. On a MS Windows system the command is called 2855 "tracert" and typically looks as follows: 2856 # tracert -h 10 www.example.org 2858 Tracing route to www.example.org [192.0.2.11] 2859 over a maximum of 10 hops: 2861 1 1 ms 1 ms 8 ms 192.0.2.99 2862 2 <1 ms <1 ms <1 ms r1.provider4.example [192.0.2.102] 2863 3 <1 ms <1 ms <1 ms rtr8.provider8.example [192.0.2.254] 2864 4 1 ms 1 ms 1 ms hop11.hoster7.example [192.0.2.4] 2865 5 2 ms 3 ms 1 ms sw6.provider2.example [192.0.2.201] 2866 6 3 ms 3 ms 3 ms out.provider2.example [192.0.2.111] 2867 7 * 6 ms 5 ms 192.0.2.123 2868 8 5 ms 5 ms 5 ms 192.0.2.42 2869 9 94 ms 95 ms 95 ms ingress.example.org [192.0.2.199] 2870 10 168 ms 169 ms 169 ms 192.0.2.44 2872 Trace complete. 2874 In this example the trace was limited to 10 hops. So, the tenth and 2875 last hop of this example was not the final destination. Applying the 2876 XML schema defined in this document the trace could look as follows: 2877 2878 2879 2880 Example 3 2881 2882 2883 2884 2885 2886 www.example.org 2887 2888 2889 2890 2891 2892 2893 10 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 Show how it encodes in XML 2904 2905 2906 2907 2908 Example 3 2909 Windows 2910 XP SP2 32-bit 2911 2912 tracert 2913 2914 www.example.org 2915 2916 2917 2918 2919 2920 2921 10 2922 2923 2924 192.0.2.142 2925 2926 3 2927 2928 2929 2930 2931 Show how it encodes in XML 2932 2933 2934 2935 Example 3 2936 2008-05-14T11:03:09+02:00 2938 2939 192.0.2.11 2940 2941 2942 2943 2944 2945 192.0.2.99 2946 2947 2948 1 2949 2950 responseReceived 2951 2952 2953 2954 2955 192.0.2.99 2956 2957 2958 1 2959 2960 responseReceived 2961 2962 2963 2964 2965 192.0.2.99 2966 2967 2968 8 2969 2970 responseReceived 2971 2972 2973 2974 2975 2976 2977 192.0.2.102 2978 2979 r1.provider4.example 2980 2981 0 2982 2983 responseReceived 2984 2985 2986 2987 2988 192.0.2.102 2989 2990 r1.provider4.example 2991 2992 0 2993 2994 responseReceived 2995 2996 2997 2998 2999 192.0.2.102 3000 3001 r1.provider4.example 3002 3003 0 3004 3005 responseReceived 3006 3007 3008 3009 3010 3011 3012 192.0.2.254 3013 3014 rtr8.provider8.example 3015 3016 0 3017 3018 responseReceived 3019 3020 3021 3022 3023 192.0.2.254 3024 3025 rtr8.provider8.example 3026 3027 0 3028 3029 responseReceived 3030 3031 3032 3033 3034 192.0.2.254 3035 3036 rtr8.provider8.example 3037 3038 0 3039 3040 responseReceived 3041 3042 3044 3045 3046 3047 3048 192.0.2.4 3049 3050 hop11.hoster7.example 3051 3052 1 3053 3054 responseReceived 3055 3056 3057 3058 3059 192.0.2.4 3060 3061 hop11.hoster7.example 3062 3063 1 3064 3065 responseReceived 3066 3067 3068 3069 3070 192.0.2.4 3071 3072 hop11.hoster7.example 3073 3074 1 3075 3076 responseReceived 3077 3078 3079 3080 3081 3082 3083 192.0.2.201 3084 3085 sw6.provider2.example 3086 3087 2 3088 3089 responseReceived 3090 3091 3092 3093 3094 192.0.2.201 3095 3096 sw6.provider2.example 3097 3098 3 3099 3100 responseReceived 3101 3102 3103 3104 3105 192.0.2.201 3106 3107 sw6.provider2.example 3108 3109 1 3110 3111 responseReceived 3112 3113 3114 3115 3116 3117 3118 192.0.2.111 3119 3120 out.provider2.example 3121 3122 3 3123 3124 responseReceived 3125 3126 3127 3128 3129 192.0.2.111 3130 3131 out.provider2.example 3132 3133 3 3134 3135 responseReceived 3136 3137 3138 3139 3140 192.0.2.111 3141 3142 out.provider2.example 3143 3144 3 3145 3146 responseReceived 3147 3148 3149 3150 3151 3152 3153 192.0.2.123 3154 3155 3156 3157 3158 requestTimedOut 3159 3160 3161 3162 3163 192.0.2.123 3164 3165 3166 6 3167 3168 responseReceived 3169 3170 3171 3172 3173 192.0.2.123 3174 3175 3176 5 3177 3178 responseReceived 3179 3180 3181 3182 3183 3184 3185 192.0.2.42 3186 3187 3188 5 3189 3190 responseReceived 3191 3192 3193 3194 3195 192.0.2.42 3196 3197 3198 5 3199 3200 responseReceived 3201 3202 3203 3204 3205 192.0.2.42 3206 3207 3208 5 3209 3210 responseReceived 3211 3212 3213 3214 3215 3216 3217 192.0.2.199 3218 3219 ingress.example.org 3220 3221 94 3222 3223 responseReceived 3224 3225 3226 3227 3228 192.0.2.199 3229 3230 ingress.example.org 3231 3232 95 3233 3234 responseReceived 3235 3237 3238 3239 3240 192.0.2.199 3241 3242 ingress.example.org 3243 3244 95 3245 3246 responseReceived 3247 3248 3249 3250 3251 3252 3253 192.0.2.44 3254 3255 3256 168 3257 3258 responseReceived 3259 3260 3261 3262 3263 192.0.2.44 3264 3265 3266 169 3267 3268 responseReceived 3269 3270 3271 3272 3273 192.0.2.44 3274 3275 3276 169 3277 3278 responseReceived 3279 3280 3281 3282 3283 2008-05-14T11:03:23+02:00 3285 3286 3287 3289 The three examples given in this section are intended to give an 3290 impression on how a trace could be represented in XML. The 3291 representation generated by an implementation may differ from the 3292 examples here dependent on the system and the capabilities of the 3293 traceroute implementation. 3295 Authors' Addresses 3297 Saverio Niccolini 3298 NEC Laboratories Europe, NEC Europe Ltd. 3299 Kurfuersten-Anlage 36 3300 Heidelberg 69115 3301 Germany 3303 Phone: +49 (0) 6221 4342 118 3304 Email: saverio.niccolini@nw.neclab.eu 3305 URI: http://www.nw.neclab.eu 3307 Sandra Tartarelli 3308 NEC Laboratories Europe, NEC Europe Ltd. 3309 Kurfuersten-Anlage 36 3310 Heidelberg 69115 3311 Germany 3313 Phone: +49 (0) 6221 4342 132 3314 Email: sandra.tartarelli@nw.neclab.eu 3315 URI: http://www.nw.neclab.eu 3317 Juergen Quittek 3318 NEC Laboratories Europe, NEC Europe Ltd. 3319 Kurfuersten-Anlage 36 3320 Heidelberg 69115 3321 Germany 3323 Phone: +49 (0) 6221 4342 115 3324 Email: quittek@nw.neclab.eu 3325 URI: http://www.nw.neclab.eu 3326 Thomas Dietz 3327 NEC Laboratories Europe, NEC Europe Ltd. 3328 Kurfuersten-Anlage 36 3329 Heidelberg 69115 3330 Germany 3332 Phone: +49 (0) 6221 4342 128 3333 Email: thomas.dietz@nw.neclab.eu 3334 URI: http://www.nw.neclab.eu 3336 Martin Swany 3337 Dept. of Computer and Information Sciences, University of Delaware 3338 Newark DE 19716 3339 U.S.A. 3341 Email: swany@UDel.Edu 3343 Full Copyright Statement 3345 Copyright (C) The IETF Trust (2008). 3347 This document is subject to the rights, licenses and restrictions 3348 contained in BCP 78, and except as set forth therein, the authors 3349 retain all their rights. 3351 This document and the information contained herein are provided on an 3352 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3353 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3354 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3355 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3356 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3357 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3359 Intellectual Property 3361 The IETF takes no position regarding the validity or scope of any 3362 Intellectual Property Rights or other rights that might be claimed to 3363 pertain to the implementation or use of the technology described in 3364 this document or the extent to which any license under such rights 3365 might or might not be available; nor does it represent that it has 3366 made any independent effort to identify any such rights. Information 3367 on the procedures with respect to rights in RFC documents can be 3368 found in BCP 78 and BCP 79. 3370 Copies of IPR disclosures made to the IETF Secretariat and any 3371 assurances of licenses to be made available, or the result of an 3372 attempt made to obtain a general license or permission for the use of 3373 such proprietary rights by implementers or users of this 3374 specification can be obtained from the IETF on-line IPR repository at 3375 http://www.ietf.org/ipr. 3377 The IETF invites any interested party to bring to its attention any 3378 copyrights, patents or patent applications, or other proprietary 3379 rights that may cover technology that may be required to implement 3380 this standard. Please address the information to the IETF at 3381 ietf-ipr@ietf.org.