idnits 2.17.1 draft-ietf-ippm-storetraceroutes-07.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2101. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2112. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2119. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2125. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1822 has weird spacing: '...A |Set the t...' -- 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 (December 17, 2007) is 5973 days in the past. Is this intentional? 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 767, but not defined == Missing Reference: '0-9' is mentioned on line 768, but not defined == Missing Reference: '0-4' is mentioned on line 768, but not defined == Missing Reference: '0-5' is mentioned on line 768, but not defined Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 7 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: June 19, 2008 NEC 6 M. Swany 7 UDel 8 December 17, 2007 10 Information Model and XML Data Model for Traceroute Measurements 11 draft-ietf-ippm-storetraceroutes-07 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on June 19, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document describes a standard way to store the configuration and 45 the results of traceroute measurements. This document first of all 46 describes the tool itself; afterwards, the common information model 47 is defined dividing the information elements in two semantically 48 separated groups (configuration elements and results ones). Moreover 49 an additional element is defined to relate configuration elements and 50 results ones by means of a common unique identifier. On the basis of 51 the information model a data model based on XML is defined to store 52 the results of traceroute measurements. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology used in this document . . . . . . . . . . . . . . 3 58 3. The Traceroute tool and its operations . . . . . . . . . . . . 4 59 4. Results of traceroute measurements . . . . . . . . . . . . . . 4 60 5. Information Model for Traceroute Measurements . . . . . . . . 5 61 5.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.2. Information Elements . . . . . . . . . . . . . . . . . . . 7 63 5.2.1. Configuration Information Elements . . . . . . . . . . 7 64 5.2.2. Results Information Elements . . . . . . . . . . . . . 11 65 5.2.3. Information Element Correlating Configuration and 66 Results Elements . . . . . . . . . . . . . . . . . . . 14 67 5.2.4. Information Elements to compare traceroute 68 measurements results one with each other . . . . . . . 14 69 6. Data Model for Storing Traceroute Measurements . . . . . . . . 15 70 7. XML Schema for traceroute Measurements . . . . . . . . . . . . 16 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 72 8.1. Conducting Traceroute Measurements . . . . . . . . . . . . 35 73 8.2. Securing Traceroute Measurements Information . . . . . . . 35 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 36 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 36 78 Appendix A. Traceroute Default Configuration Parameters . . . . . 37 79 A.1. Alternative Traceroute Implementations . . . . . . . . . . 41 80 Appendix B. Known Problems with Traceroute . . . . . . . . . . . 41 81 B.1. Compatibility between traceroute measurements results 82 and IPPM metrics . . . . . . . . . . . . . . . . . . . . . 41 83 Appendix C. Differences to DISMAN-TRACEROUTE-MIB . . . . . . . . 42 84 C.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 43 85 C.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 43 86 C.3. Additional Information Elements . . . . . . . . . . . . . 44 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 88 Intellectual Property and Copyright Statements . . . . . . . . . . 46 90 1. Introduction 92 Traceroutes are being used by lots of measurement efforts, either as 93 an independent measurement or to get path information to support 94 other measurement efforts. That is why there is the need to 95 standardize the way the configuration and the results of traceroute 96 measurements are stored. The standard metrics defined by IPPM 97 working group in matter of delay, connectivity and losses do not 98 apply to the metrics returned by the traceroute tool; therefore, in 99 order to compare results of traceroute measurements, the only 100 possibility is to add to the stored results a specification of the 101 operating system and version for the traceroute tool used. This 102 document, in order to store results of traceroute measurements and 103 allow comparison of them, defines a standard way to store them using 104 a XML schema. The document is organized as follows: Section 2 105 defines the terminology used in this document, Section 3 describes 106 the traceroute tool, Section 4 describes the results of a traceroute 107 measurement as displayed to the screen from which the traceroute tool 108 was launched. Section 5 and Section 6 respectively describe the 109 information model and data model for storing configuration and 110 results of the traceroute measurements. The document ends with 111 security considerations and IANA considerations in Section 8 and 112 Section 9 respectively. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119. 118 2. Terminology used in this document 120 The terminology used in this document is defined as follow: 121 o traceroute tool: a software tool for network diagnostic behaving 122 like described in Section 3; 123 o traceroute measurement: an instance of the traceroute tool 124 launched, with specific configuration parameters (traceroute 125 measurement configuration parameters), from a specific host 126 (initiator of the traceroute measurement) giving as output 127 specific traceroute measurement results; 128 o traceroute probe: one of many IP packets send out by the 129 traceroute tool during a traceroute measurement; 130 o traceroute measurement configuration parameters: the configuration 131 parameters of a traceroute measurement; 132 o traceroute measurement results: the results of a traceroute 133 measurement; 134 o traceroute measurement information: both the results and the 135 configuration parameters of a traceroute measurement; 137 o traceroute measurement path: a sequence of hosts transited in 138 order by traceroute probes during a traceroute measurement; 140 3. The Traceroute tool and its operations 142 Traceroute is a network diagnostic tool used to determine the hop by 143 hop path from a source to a destination and the Round Trip Time (RTT) 144 from the source to each hop. Traceroute can be therefore used to 145 discover some information (hop counts, delays, etc.) about the path 146 between the initiator of the traceroute measurement and other hosts. 148 Typically, the traceroute tool attempts to discover the path to a 149 destination by sending UDP probes with specific time-to-live (TTL) 150 values in the IP packet header and trying to elicit an ICMP 151 TIME_EXCEEDED response from each gateway along the path to some host. 153 More in detail, a first set of probes with TTL equal to 1 are sent by 154 the traceroute tool from the host initiating the traceroute 155 measurement (some tool implementations allow setting the initial TTL 156 to a value equal to "n" different from 1, so that the first "n-1" 157 hops are skipped and the first hop that will be traced is the "n-th" 158 in the path). Upon receiving a probe, the first hop host decreases 159 the TTL value (by one or more). By observing a TTL value equal to 160 zero, the host rejects the probe and typically returns an ICMP 161 message with a TIME_EXCEEDED value. The traceroute tool can 162 therefore derive the IP address of the first hop from the header of 163 the ICMP message and evaluate the RTT between the host initiating the 164 traceroute measurement and the first hop. The next hops are 165 discovered following the same procedure, taking care of increasing at 166 each step the TTL value of the probes by one. The TTL value is 167 increased until either an ICMP PORT_UNREACHABLE message is received, 168 meaning that the destination host has been reached, or the maximum 169 configured number of hops has been hit. 171 Some implementations, use ICMP Echos, instead of UDP datagrams. 172 However, many routers do not return ICMP messages about ICMP 173 messages, i.e. no ICMP TIME_EXCEEDED is returned for an ICMP Echo. 174 Therefore, this document recommends to base implementations on UDP 175 datagrams. Considerations on TCP-based implementations of the 176 traceroute tool are reported in Appendix A.1. 178 4. Results of traceroute measurements 180 The following list reports the information fields provided as results 181 by all traceroute tool implementations considered. The order in 182 which they are reported here is not relevant and it changes in 183 different implementations. For each hop the information reported is: 184 o the hop index; 185 o the host symbolic address, provided that at least one of the 186 probes received a response, the symbolic address could be resolved 187 at the corresponding host and that the option to display only 188 numerical addresses was not set; 189 o the host IP address, provided that at least one of the probes 190 received a response; 191 o the RTT for each response to a probe. 192 Depending on the traceroute tool implementation, additional 193 information might be displayed in the output (for instance MPLS- 194 related information). 196 It might happen that some probes do not receive a response within the 197 configured time-out (for instance if the probe is filtered out by a 198 firewall). In this case, an "*" is displayed in place of the RTT. 199 The information model reflects this using a string with the value of 200 "RoundTripTimeNotAvailable" meaning either the probe was lost because 201 of a time-out or it was not possible to transmit a probe. It may 202 also happen that some implementations print the same line multiple 203 times when a router decreases the TTL by more than one looking like 204 multiple hops, the information model is not impacted by this since 205 each line is handled separately and it is left to the applications 206 handling the XML file how to deal with it. Moreover, for delays 207 below 1 ms, some implementations reports 0 ms (e.g. UNIX and LINUX) 208 while WINDOWS tracert reports "< 1 ms". 210 5. Information Model for Traceroute Measurements 212 The information model is composed of information elements; for 213 defining these information elements, a template is used. Such 214 template is specified in the list below: 216 o name - A unique and meaningful name for the information element. 217 The preferred spelling for the name is to use mixed case if the 218 name is compound, with an initial lower case letter, e.g., 219 "sourceIpAddress". 220 o description - The semantics of this information element. 221 o dataType - One of the types listed in Section 5.1 of this document 222 or in an extension of the information model. The type space for 223 attributes is constrained to facilitate implementation. 224 o units - If the element is a measure of some kind, the units 225 identify what the measure is. 227 5.1. Data Types 229 This section describes the set of valid data types of the information 230 model. 232 o String - The type "String" represents a finite length string of 233 valid characters from the Unicode character encoding set. Unicode 234 allows for ASCII and many other international character sets to be 235 used. It is expected that strings will be encoded in UTF-8 236 format, which is identical in encoding for USASCII characters, but 237 also accommodates other Unicode multi-byte characters. 238 o InetAddressType - The type "InetAddressType" represents a type of 239 Internet address. The allowed values are to be intended as 240 imported from [RFC4001]; an additional allowed value is 241 "asnumber". 242 o InetAddress - The type "InetAddress" denotes a generic Internet 243 address. The allowed values are to be intended as imported from 244 [RFC4001]; an additional allowed value is the AS number to be 245 indicated as the actual number plus the indication how the mapping 246 from IP address to AS number was performed. 247 o TruthValue - The type "TruthValue" represents a Boolean value. 248 The allowed values are to be intended as imported from [RFC2579]. 249 o Unsigned32 - The type "Unsigned32" represents a value in the range 250 (0..4294967295). 251 o Unsigned16 - The type "Unsigned16" represents a value in the range 252 (0..65535). 253 o Unsigned8 - The type "Unsigned32" represents a value in the range 254 (0..255). 255 o InterfaceIndexOrZero - The type "InterfaceIndexOrZero" is an 256 extension of the InterfaceIndex convention. The latter defines a 257 greater than zero value used to identify an interface or interface 258 sub-layer in the system. This extension permits the additional 259 value of zero. Examples of the usage of zero might include 260 situations where interface was unknown, or when none or all 261 interfaces need to be referenced. The allowed values are to be 262 intended as imported from [RFC2863]. 263 o ProbesType - The type "ProbesType" represents a way of indicating 264 the protocol used for the traceroute probes. Allowed values are 265 UDP, TCP, ICMP. 266 o DateAndTime - The type "DateAndTime" represents a date-time 267 specification. The allowed values are to be intended as imported 268 from [RFC2579] apart from the fact that in this document there is 269 the need to use a millisecond resolution instead a decisecond one. 270 o OperationResponseStatus - The type "OperationResponseStatus" is 271 used to report the result of an operation. The allowed values are 272 to be intended as imported from [RFC4560]. 274 5.2. Information Elements 276 This section describes the elements related to the storing of a 277 traceroute measurement. The elements are grouped in two groups 278 (Configuration and Results) according to their semantics. In order 279 to relate configuration and results elements by means of a common 280 unique identifier, an additional element is defined belonging to both 281 the two groups. 283 5.2.1. Configuration Information Elements 285 This section describes the elements specific to the configuration of 286 the traceroute measurement. 288 5.2.1.1. CtlTargetAddressType 290 o name - CtlTargetAddressType 291 o description - Specifies the type of destination address used in 292 the traceroute measurement. 293 o dataType - InetAddressType 294 o units - N/A 296 5.2.1.2. CtlTargetAddress 298 o name - CtlTargetAddress 299 o description - Specifies the host address used in the traceroute 300 measurement. The host address type can be determined by the 301 examining the value of the corresponding CtlTargetAddressType. 302 o dataType - InetAddress 303 o units - N/A 305 5.2.1.3. CtlBypassRouteTable 307 o name - CtlBypassRouteTable 308 o description - Specifies if the optional bypassing of the route 309 table was enabled or not. If enabled, the normal routing tables 310 will be bypassed and the probes will be sent directly to a host on 311 an attached network. If the host is not on a directly-attached 312 network, an error is returned. This option can be used to perform 313 the traceroute measurement to a local host through an interface 314 that has no route defined. 315 o dataType - TruthValue 316 o units - N/A 318 5.2.1.4. CtlProbeDataSize 319 o name - CtlProbeDataSize 320 o description - Specifies the size of the probes of a traceroute 321 measurement in octets. If UDP datagrams are used as probes, then 322 the value contained in this object is exact. If another protocol 323 is used to transmit probes (i.e. TCP or ICMP) for which the 324 specified size is not appropriate, then the implementation can use 325 whatever size (appropriate to the method) is closest to the 326 specified size. The maximum value for this object was computed by 327 subtracting the smallest possible IP header size of 20 octets 328 (IPv4 header with no options) and the UDP header size of 8 octets 329 from the maximum IP packet size. An IP packet has a maximum size 330 of 65535 octets (excluding IPv6 Jumbograms). 331 o dataType - Unsigned32 332 o units - octets 334 5.2.1.5. CtlTimeOut 336 o name - CtlTimeOut 337 o description - Specifies the time-out value, in seconds, for each 338 probe of a traceroute measurement. 339 o dataType - Unsigned32 340 o units - seconds 342 5.2.1.6. CtlProbesPerHop 344 o name - CtlProbesPerHop 345 o description - Specifies the number of probes with the same time- 346 to-live (TTL) value that are sent for each host. 347 o dataType - Unsigned32 348 o units - probes 350 5.2.1.7. CtlPort 352 o name - CtlPort 353 o description - Specifies the base UDP port used by the traceroute 354 measurement. A port that is not in use at the destination 355 (target) host needs to be specified. 356 o dataType - Unsigned32 357 o units - UDP Port 359 5.2.1.8. CtlMaxTtl 361 o name - CtlMaxTtl 362 o description - Specifies the maximum TTL value for the traceroute 363 measurement. 364 o dataType - Unsigned32 365 o units - time-to-live value 367 5.2.1.9. CtlDSField 369 o name - CtlDSField 370 o description - Specifies the value that was stored in the 371 Differentiated Services (DS) field in the traceroute probe. The 372 DS Field is defined as the Type of Service (TOS) octet in a IPv4 373 header or as the Traffic Class octet in a IPv6 header. The value 374 of this object must be a decimal integer in the range from 0 to 375 255. This option can be used to determine what effect an explicit 376 DS field setting has on a traceroute measurement and its probes. 377 Not all values are legal or meaningful. Useful TOS octet values 378 are probably '16' (low delay) and '8' (high throughput). Further 379 references can be found in [RFC2474] for the definition of the 380 Differentiated Services (DS) field and to [RFC1812] Section 5.3.2 381 for Type of Service (TOS). 382 o dataType - Unsigned32 383 o units - N/A 385 5.2.1.10. CtlSourceAddressType 387 o name - CtlSourceAddressType 388 o description - Specifies the type of the source address, 389 CtlSourceAddress, used in the traceroute measurement. 390 o dataType - InetAddressType 391 o units - N/A 393 5.2.1.11. CtlSourceAddress 395 o name - CtlSourceAddress 396 o description - Specifies the IP address (which has to be given as 397 an IP number, not a hostname) as the source address used in 398 traceroute probes. On hosts with more than one IP address, this 399 option can be used to force the source address to be something 400 other than the primary IP address of the interface the probe is 401 sent on. A zero length octet string value for this object means 402 that source address specification was disabled. The address type 403 (InetAddressType) that relates to this object is specified by the 404 corresponding value of CtlSourceAddressType. 405 o dataType - InetAddress 406 o units - N/A 408 5.2.1.12. CtlIfIndex 410 o name - CtlIfIndex 411 o description - Specifies the interface index used in the traceroute 412 measurement for sending the traceroute probes. A value of zero 413 for this object implies that the interface was unknown. 414 o dataType - InterfaceIndexOrZero 415 o units - N/A 417 5.2.1.13. CtlMiscOptions 419 o name - CtlMiscOptions 420 o description - Specifies implementation dependent options. 421 o dataType - String 422 o units - N/A 424 5.2.1.14. CtlMaxFailures 426 o name - CtlMaxFailures 427 o description - Specifies the maximum number of consecutive timeouts 428 allowed before terminating a traceroute measurement. A value of 429 either 255 (maximum hop count/possible TTL value) or a 0 indicates 430 that the function of terminating a remote traceroute measurement 431 when a specific number of consecutive timeouts are detected was 432 disabled. This element is included to give full compatibility 433 with [RFC4560]. No known implementation of traceroute currently 434 supports it. 435 o dataType - Unsigned32 436 o units - timeouts 438 5.2.1.15. CtlDontFragment 440 o name - CtlDontFragment 441 o description - Specifies if the don't fragment flag (DF) in the IP 442 header for a probe was enabled or not. Setting the DF flag can be 443 used for performing a manual PATH MTU test. 444 o dataType - TruthValue 445 o units - N/A 447 5.2.1.16. CtlInitialTtl 449 o name - CtlInitialTtl 450 o description - Specifies the initial TTL value used in a traceroute 451 measurement. Such TTL setting is intended to bypass the initial 452 (often well known) portion of a path. 453 o dataType - Unsigned32 454 o units - N/A 456 5.2.1.17. CtlDescr 458 o name - CtlDescr 459 o description - The purpose of this element is to provide a 460 description of the traceroute measurement. 461 o dataType - String 462 o units - N/A 464 5.2.1.18. CtlType 466 o name - CtlType 467 o description - Specifies the implementation method used for the 468 traceroute measurement. It specifies if the traceroute is using 469 TCP, UDP or ICMP probes. 470 o dataType - ProbesType 471 o units - N/A 473 5.2.2. Results Information Elements 475 This section describes the elements specific to the results of the 476 traceroute measurement. 478 5.2.2.1. ResultsStartDateAndTime 480 o name - ResultsStartDateAndTime 481 o description - Specifies the date and start time of the traceroute 482 measurement. This is the time when the first probe was seen at 483 the sending interface. 484 o dataType - DateAndTime 485 o units - N/A 487 5.2.2.2. ResultsIpTgtAddrType 489 o name - ResultsIpTgtAddrType 490 o description - Specifies the type of address stored in the 491 corresponding ResultsIpTgtAddr element. 492 o dataType - InetAddressType 493 o units - N/A 495 5.2.2.3. ResultsIpTgtAddr 497 o name - ResultsIpTgtAddr 498 o description - Specifies the IP address associated with a 499 CtlTargetAddress value when the destination address is specified 500 as a DNS name. The value of this object should be a zero length 501 octet string when a DNS name is not specified or when a specified 502 DNS name fails to resolve. 504 o dataType - InetAddress 505 o units - N/A 507 5.2.2.4. Index 509 o name - Index 510 o description - Specifies an index that consecutively numbers all 511 probes for which a reply was received in the sequential order in 512 which the replies were received. The maximum value for this 513 object is CtlMaxTtl*CtlProbesPerHop. 514 o dataType - Unsigned32 515 o units - N/A 517 5.2.2.5. HopIndex 519 o name - HopIndex 520 o description - Specifies which hop in a traceroute measurement path 521 the probe's results are for. 522 o dataType - Unsigned32 523 o units - N/A 525 5.2.2.6. IndexPerHop 527 o name - IndexPerHop 528 o description - Specifies the index of a probe for a particular hop 529 in a traceroute measurement path. The number of probes per hop is 530 determined by the value of the corresponding CtlProbesPerHop 531 element. 532 o dataType - Unsigned32 533 o units - N/A 535 5.2.2.7. HopAddrType 537 o name - HopAddrType 538 o description - Specifies the type of address stored in the 539 corresponding HopAddr element. 540 o dataType - InetAddressType 541 o units - N/A 543 5.2.2.8. HopAddr 545 o name - HopAddr 546 o description - Specifies the address of a hop in the traceroute 547 measurement path. This object is not allowed to be a DNS name. 548 The value of the corresponding object, HopAddrType, indicates this 549 object's IP address type. 551 o dataType - InetAddress 552 o units - N/A 554 5.2.2.9. HopGeoLocation 556 o name - HopGeoLocation 557 o description - Specifies the geo location of a hop in the 558 traceroute measurement path. 559 o dataType - String 560 o units - N/A 562 5.2.2.10. MPLSTopLabel 564 o name - MPLSTopLabel 565 o description - Specifies the top entry of the MPLS label stack of a 566 probe observed when the probe arrived at the hop that replied to 567 the probe. This object contains the top MPLS label stack entry as 568 32 bit value as it is observed on the MPLS label stack. Contained 569 in this single number are the MPLS label, the Exp field, the S 570 flag, and the MPLS TTL value as specified in RFC 3032. 571 o dataType - Unsigned32 572 o units - N/A 574 5.2.2.11. RoundTripTime 576 o name - RoundTripTime 577 o description - Specifies the amount of time measured in 578 milliseconds from when a probe was sent to when its response was 579 received or when it timed out. The value of this element is 580 reported as the truncation of the number reported by the 581 traceroute tool (the output "< 1 ms" is therefore encoded as 0 582 ms). A string with the value of "RoundTripTimeNotAvailable" means 583 either the probe was lost because of a timeout or it was not 584 possible to transmit a probe. 585 o dataType - Unsigned32 or String 586 o units - milliseconds or N/A 588 5.2.2.12. ResponseStatus 590 o name - ResponseStatus 591 o description - Specifies the result of a traceroute measurement 592 made by the host for a particular probe. 593 o dataType - OperationResponseStatus 594 o units - N/A 596 5.2.2.13. Time 598 o name - Time 599 o description - Specifies the timestamp for when the response to the 600 probe was received at the interface. 601 o dataType - DateAndTime 602 o units - N/A 604 5.2.2.14. ResultsHopRawOutputData 606 o name - ResultsHopRawOutputData 607 o description - Specifies the raw output data returned by the 608 traceroute measurement for a certain hop in a traceroute 609 measurement path. 610 o dataType - String 611 o units - N/A 613 5.2.2.15. ResultsEndDateAndTime 615 o name - ResultsEndDateAndTime 616 o description - Specifies the date and end time of the traceroute 617 measurement. It is either the time when the response to the last 618 probe of the traceroute measurement was received or the time when 619 the last probe of the traceroute measurement was sent plus the 620 relative timeout (in case of missing response). 621 o dataType - DateAndTime 622 o units - N/A 624 5.2.3. Information Element Correlating Configuration and Results 625 Elements 627 This section defines an additional element belonging to both the two 628 previous groups (configuration elements and result elements) named 629 TestName. This element is defined in order to relate configuration 630 elements and results ones by means of a common unique identifier. 632 5.2.3.1. TestName 634 o name - TestName 635 o description - Specifies the name of a traceroute measurement. 636 This is locally unique. 637 o dataType - String 638 o units - N/A 640 5.2.4. Information Elements to compare traceroute measurements results 641 one with each other 643 This section defines additional elements belonging to both the two 644 previous groups (configuration elements and result elements); these 645 elements were defined in order to allow traceroute measurements 646 results comparison among different traceroute measurements. 648 5.2.4.1. OSName 650 o name - OSName 651 o description - Specifies the name of the operating system on which 652 the traceroute measurement was launched. 653 o dataType - String 654 o units - N/A 656 5.2.4.2. OSVersion 658 o name - OSVersion 659 o description - Specifies the OS version on which the traceroute 660 measurement was launched. 661 o dataType - String 662 o units - N/A 664 5.2.4.3. ToolVersion 666 o name - ToolVersion 667 o description - Specifies the version of the traceroute tool used. 668 o dataType - String 669 o units - N/A 671 6. Data Model for Storing Traceroute Measurements 673 For storing and transmitting information according to the information 674 model defined in the previous section, a data model is required that 675 specifies how to encode the elements of the information model. 677 There are several design choices for a data model. It can use a 678 binary or textual representation and it can be defined from scratch 679 or use already existing frameworks and data models. In general, the 680 use of already existing frameworks and models should be preferred. 682 Binary and textual representation both have advantages and 683 disadvantages. Textual representations are (with some limitations) 684 human readable while a binary representation consumes less resources 685 for storing, transmitting and parsing data. 687 An already existing and closely related data model is the DISMAN- 688 TRACEROUTE-MIB module [RFC4560], that specifies a BER encoding 689 [RFC3417] used by the Simple Network Management Protocol (SNMP) 690 [RFC3410] for transmitting traceroute measurement information 691 (configuration and results). This data model is well suited and 692 supported within network management systems, but as a general format 693 for storing and transmitting traceroute results it is not easily 694 applicable. 696 Another binary representation would be an extension of traffic flow 697 information encodings as specified for the IPFIX protocol 698 [I-D.ietf-ipfix-protocol], [I-D.ietf-ipfix-info]. The IPFIX protocol 699 is extensible. However, the architecture behind this protocol 700 [I-D.ietf-ipfix-architecture] is targeted at exporting passively 701 measured flow information. Therefore, some obstacles are expected 702 when trying to use it for transmitting traceroute measurements 703 information. 705 For textual representations, using the eXtensible Markup Language 706 (XML) [XML] is an obvious choice. XML supports clean structuring of 707 data and syntax checking of records. With some limitations it is 708 human readable. It is supported well by a huge pool of tools and 709 standards for generating, transmitting, parsing and converting it to 710 other data formats. Its disadvantages is the resource consumption 711 for processing, storing, and transmitting information. Since the 712 expected data volumes related to traceroute measurements in network 713 operation and maintenance is not expected to be extremely high, the 714 inefficient usage of resources is not a significant disadvantage. 715 Therefore, XML was chosen as basis for the traceroute measurements 716 information model that is specified in this section. 718 Section 7 contains the XML schema to be used as a template for 719 storing and/or exchanging traceroute measurements information. The 720 schema was designed in order to use an extensible approach based on 721 templates (pretty similar to how IPFIX protocol is designed) where 722 the traceroute configuration elements (both the requested parameters, 723 Request, and the actual parameters used, MeasurementMetadata) are 724 metadata to be referenced by results information elements (data) by 725 means of the TestName element (used as unique identifier). Currently 726 Open Grid Forum (OGF) is also using this approach and cross- 727 requirements have been analyzed. As a result of this analysis the 728 XML schema contained in Section 7 is compatible with OGF schema since 729 it was designed in a way that both limits the unnecessary redundancy 730 and a simple one-to-one transformation between the two exist. 732 7. XML Schema for traceroute Measurements 734 735 738 739 740 741 742 743 744 745 746 748 749 750 751 752 753 754 755 756 758 759 760 761 762 764 765 766 769 770 772 773 774 776 777 779 780 781 782 783 785 786 787 789 790 791 792 793 794 795 796 797 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 815 816 817 819 820 821 822 823 825 826 827 Specifies the name of a 828 traceroute measurement. This is locally unique. 829 830 831 832 833 835 837 838 839 Specifies the name of the operating 840 system on which the traceroute measurement was 841 launched. 842 843 844 845 846 847 849 850 851 Specifies the OS version on which the 852 traceroute measurement was launched. 853 854 855 856 857 858 860 861 862 Specifies the version of the traceroute 863 tool used. 864 865 866 867 868 869 871 872 873 Specifies if the optional bypassing 874 of the route table was enabled or not. If enabled, 875 the normal routing tables will be bypassed and the 876 probes will be sent directly to a host on an attached 877 network. If the host is not on a directly-attached 878 network, an error is returned. This option can be 879 used to perform the traceroute measurement to a 880 local host through an interface that has no route 881 defined. 882 884 885 886 888 889 890 Specifies the size of the probes 891 of a traceroute measurement in octets. If UDP 892 datagrams are used as probes, then the value 893 contained in this object is exact. If another 894 protocol is used to transmit probes (i.e. TCP or 895 ICMP) for which the specified size is not 896 appropriate, then the implementation can use 897 whatever size (appropriate to the method) is 898 closest to the specified size. The maximum value 899 for this object was computed by subtracting the 900 smallest possible IP header size of 20 octets (IPv4 901 header with no options) and the UDP header size of 902 8 octets from the maximum IP packet size. An IP 903 packet has a maximum size of 65535 octets (excluding 904 IPv6 Jumbograms). 905 906 907 908 909 910 912 913 914 Specifies the time-out value, in 915 seconds, for each probe of a traceroute measurement. 916 917 918 919 920 921 922 924 925 926 Specifies the number of probes 927 with the same time-to-live (TTL) value that are 928 sent for each host. 929 930 931 932 933 934 935 937 938 939 Specifies the base UDP port used 940 by the traceroute measurement. A port that is not 941 in use at the destination (target) host needs to be 942 specified. 943 944 945 946 947 948 950 951 952 Specifies the maximum TTL value 953 for the traceroute measurement. 954 955 956 957 958 959 961 962 963 Specifies the value that was 964 stored in the Differentiated Services (DS) field 965 in the traceroute probe. The DS Field is defined 966 as the Type of Service (TOS) octet in a IPv4 header 967 or as the Traffic Class octet in a IPv6 header. 968 The value of this object must be a decimal integer 969 in the range from 0 to 255. This option can be 970 used to determine what effect an explicit DS field 971 setting has on a traceroute measurement and its 972 probes. Not all values are legal or meaningful. 973 Useful TOS octet values are probably '16' (low 974 delay) and '8' (high throughput). Further references 975 can be found in RFC 2474 for the definition of the 976 Differentiated Services (DS) field and to RFC 1812 977 Section 5.3.2 for Type of Service (TOS). 978 979 980 981 983 984 985 Specifies the interface index 986 used in the traceroute measurement for sending 987 the traceroute probes. A value of zero for this 988 object implies that the interface was unknown. 989 990 991 992 994 995 996 Specifies implementation dependent 997 options. 998 999 1000 1001 1002 1004 1005 1006 Specifies the maximum number 1007 of consecutive timeouts allowed before terminating 1008 a traceroute measurement. A value of either 255 1009 (maximum hop count/possible TTL value) or a 0 1010 indicates that the function of terminating a 1011 remote traceroute measurement when a specific 1012 number of consecutive timeouts are detected was 1013 disabled. This element is included to give full 1014 compatibility with RFC 4560. No known implementation 1015 of traceroute currently supports it. 1016 1017 1018 1019 1021 1022 1023 Specifies if the don't fragment 1024 flag (DF) in the IP header for a probe was enabled 1025 or not. Setting the DF flag can be used for 1026 performing a manual PATH MTU test. 1027 1029 1030 1031 1033 1034 1035 Specifies the initial TTL 1036 value used in a traceroute measurement. Such 1037 TTL setting is intended to bypass the initial 1038 (often well known) portion of a path. 1039 1040 1041 1042 1043 1044 1046 1047 1048 The purpose of this element 1049 is to provide a description of the traceroute 1050 measurement. 1051 1052 1053 1054 1055 1056 1058 1059 1060 Specifies the implementation 1061 method used for the traceroute measurement. 1062 It specifies if the traceroute is using TCP, 1063 UDP or ICMP probes. 1064 1065 1066 1067 1068 1069 1070 1071 1073 1074 1075 Specifies an index that 1076 consecutively numbers all probes for which 1077 a reply was received in the sequential order 1078 in which the replies were received. The 1079 maximum value for this object is 1080 CtlMaxTtl*CtlProbesPerHop. 1081 1082 1083 1084 1085 1086 1087 1089 1090 1091 Specifies which hop in a 1092 traceroute measurement path the probe's 1093 results are for. 1094 1095 1096 1097 1098 1099 1101 1102 1103 Specifies the index of a 1104 probe for a particular hop in a traceroute 1105 measurement path. The number of probes per hop 1106 is determined by the value of the corresponding 1107 CtlProbesPerHop element. 1108 1109 1110 1111 1112 1113 1114 1116 1117 1118 Specifies the geo location of a 1119 hop in the traceroute measurement path. 1120 1121 1122 1123 1124 1126 1128 1129 1130 Specifies the top entry of the 1131 MPLS label stack of a probe observed when the probe 1132 arrived at the hop that replied to the probe. 1133 This object contains the top MPLS label stack 1134 entry as 32 bit value as it is observed on the MPLS 1135 label stack. Contained in this single number are the 1136 MPLS label, the Exp field, the S flag, and the MPLS 1137 TTL value as specified in RFC 3032. 1138 1139 1140 1141 1142 1143 1145 1146 1147 1148 1149 1151 1152 1153 1154 1155 1157 1158 1159 Specifies the raw output data 1160 returned by the traceroute measurement for a certain 1161 hop in a traceroute measurement path. 1162 1163 1164 1165 1166 1167 1169 1170 1171 Specifies the AS number of a hop in the 1172 traceroute path as a 24 bit number and the indication how 1173 the mapping from IP address to AS number was performed. 1175 1176 1177 1178 1180 1182 1183 1185 1186 1187 1189 1191 1193 1195 1197 1198 1200 1201 1202 1204 1206 1208 1210 1212 1213 1215 1216 1217 1219 1221 1222 1223 1224 1225 Specifies the type of destination 1226 address used in the traceroute measurement. 1227 1228 1229 1230 1232 1233 1235 1236 1237 Specifies the host address 1238 used in the traceroute measurement. The host 1239 address type can be determined by the examining 1240 the value of the corresponding CtlTargetAddressType. 1241 1242 1243 1244 1245 1246 1248 1249 1250 Specifies the type of the source 1251 address, CtlSourceAddress, used in the traceroute 1252 measurement. 1253 1254 1255 1256 1258 1259 1261 1262 1263 Specifies the IP address (which 1264 has to be given as an IP number, not a hostname) 1265 as the source address used in traceroute probes. 1266 On hosts with more than one IP address, this option 1267 can be used to force the source address to be 1268 something other than the primary IP address of the 1269 interface the probe is sent on. A zero length 1270 octet string value for this object means that 1271 source address specification was disabled. The 1272 address type (InetAddressType) that relates to 1273 this object is specified by the corresponding 1274 value of CtlSourceAddressType. 1275 1276 1277 1278 1280 1281 1283 1284 1285 Specifies the date and start 1286 time of the traceroute measurement. This is the 1287 time when the first probe was seen at the sending 1288 interface. 1289 1290 1291 1292 1293 1294 1296 1297 1298 Specifies the type of address stored 1299 in the corresponding ResultsIpTgtAddr element. 1300 1301 1302 1303 1305 1306 1308 1309 1310 Specifies the IP address associated 1311 with a CtlTargetAddress value when the destination 1312 address is specified as a DNS name. The value of 1313 this object should be a zero length octet string 1314 when a DNS name is not specified or when a specified 1315 DNS name fails to resolve. 1316 1317 1318 1319 1321 1322 1324 1325 1326 Specifies the type of address stored 1327 in the corresponding HopAddr element. 1328 1329 1330 1331 1333 1334 1336 1337 1338 Specifies the address of a 1339 hop in the traceroute measurement path. This 1340 object is not allowed to be a DNS name. The 1341 value of the corresponding object, HopAddrType, 1342 indicates this object's IP address type. 1343 1344 1345 1346 1348 1349 1351 1352 1353 Specifies the amount of 1354 time measured in milliseconds from when a 1355 probe was sent to when its response was 1356 received or when it timed out. The value of 1357 this element is reported as the truncation 1358 of the number reported by the traceroute 1359 tool (the output "< 1 ms" is therefore 1360 encoded as 0 ms). A string with the value of 1361 "RoundTripTimeNotAvailable" means either the 1362 probe was lost because of a timeout or it 1363 was not possible to transmit a probe. 1364 1365 1366 1367 1369 1371 1372 1374 1375 1376 Specifies the result of a traceroute 1377 measurement made by the host for a particular probe. 1378 1379 1380 1381 1383 1384 1386 1387 1388 Specifies the timestamp for 1389 when the response to the probe was received at the 1390 interface. 1391 1392 1393 1394 1395 1396 1398 1399 1400 1402 1404 1406 1408 1410 1413 1416 1418 1420 1422 1423 1425 1426 1427 Specifies the date and end time 1428 of the traceroute measurement. It is either the 1429 time when the response to the last probe of the 1430 traceroute measurement was received or the time 1431 when the last probe of the traceroute measurement 1432 was sent plus the relative timeout (in case of 1433 missing response). 1434 1435 1436 1437 1438 1439 1441 1442 1443 Specifies the metadata for a 1444 traceroute operation. In a request, these are the 1445 requested parameters. In a response, they are the 1446 actual parameters used. 1447 1448 1449 1450 1452 1455 1458 1461 1464 1466 1469 1472 1475 1478 1481 1484 1487 1489 1491 1494 1497 1500 1503 1506 1509 1513 1514 1516 1517 1518 1519 Contains the actual traceroute measurement 1520 results. 1521 1522 1523 1524 1526 1528 1530 1532 1535 1538 1540 1541 1543 1544 1545 1546 1548 1549 1550 1552 1553 1554 1556 1557 1558 1560 1562 1563 1564 1566 1568 1569 1570 1572 1574 1575 1576 1578 1580 1582 1583 1584 1586 1587 1591 1593 8. Security Considerations 1595 Security considerations in this section discuss are grouped into 1596 considerations related to conducting traceroute measurements and 1597 considerations related to storing and transmitting traceroute 1598 measurements information. 1600 This memo does not specify an implementation of a traceroute tool. 1601 Neither does it specify a certain procedure for storing traceroute 1602 measurements information. Still it is considered desirable to 1603 discuss related security issues below. 1605 8.1. Conducting Traceroute Measurements 1607 Conducting Internet measurements can raise both security and privacy 1608 concerns. Traceroute measurements, in which traffic is injected into 1609 the network, can be abused for denial-of-service attacks disguised as 1610 legitimate measurement activity. 1612 Measurement parameters MUST be carefully selected so that the 1613 measurements inject trivial amounts of additional traffic into the 1614 networks they measure. If they inject "too much" traffic, they can 1615 skew the results of the measurement, and in extreme cases cause 1616 congestion and denial of service. 1618 The measurements themselves could be harmed by routers giving 1619 measurement traffic a different priority than "normal" traffic, or by 1620 an attacker injecting artificial measurement traffic. If routers can 1621 recognize measurement traffic and treat it separately, the 1622 measurements will not reflect actual user traffic. If an attacker 1623 injects artificial traffic that is accepted as legitimate, the loss 1624 rate will be artificially lowered. Therefore, the measurement 1625 methodologies SHOULD include appropriate techniques to reduce the 1626 probability measurement traffic can be distinguished from "normal" 1627 traffic. 1629 Authentication techniques, such as digital signatures, may be used 1630 where appropriate to guard against injected traffic attacks. 1632 8.2. Securing Traceroute Measurements Information 1634 Traceroute measurement information are not considered highly 1635 sensitive. Still, they may contain sensitive information on network 1636 paths, routing states, use IP addresses, and roundtrip times, that 1637 the operator a networks may want to detect for business or security 1638 reasons. 1640 It is thus important to control access to Information acquired by 1641 conducting traceroute measurements, particularly when transmitting it 1642 over a networks but also when storing it. It is RECOMMENDED that 1643 transmission of traceroute measurement information over a network 1644 uses appropriate protection mechanisms for preserving privacy, 1645 integrity and authenticity. It is further RECOMMENDED that secure 1646 authentication and authorization are used for protecting stored 1647 traceroute measurement information. 1649 9. IANA Considerations 1651 This document uses URNs to describe an XML namespace and an XML 1652 schema for traceroute measurements information storing and 1653 transmission conforming to a registry mechanism described in 1654 [RFC3688]. Two URI assignments are requested. 1655 1. Registration request for the IPPM traceroute measurements 1656 namespace 1657 * URI: urn:ietf:params:xml:ns:traceroute-1.0 1658 * Registrant Contact: IESG 1659 * XML: None. Namespace URIs do not represent an XML 1660 2. Registration request for the IPPM traceroute measurements schema 1661 * URI: urn:ietf:params:xml:schema:traceroute-1.0 1662 * Registrant Contact: IESG 1663 * XML: See the section Section 7 of this document. 1665 10. References 1667 10.1. Normative References 1669 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1670 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1671 STD 58, RFC 2579, April 1999. 1673 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1674 MIB", RFC 2863, June 2000. 1676 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1677 Schoenwaelder, "Textual Conventions for Internet Network 1678 Addresses", RFC 4001, February 2005. 1680 [RFC4560] Quittek, J. and K. White, "Definitions of Managed Objects 1681 for Remote Ping, Traceroute, and Lookup Operations", 1682 RFC 4560, June 2006. 1684 10.2. Informative References 1686 [I-D.ietf-ipfix-architecture] 1687 Sadasivan, G., "Architecture for IP Flow Information 1688 Export", draft-ietf-ipfix-architecture-12 (work in 1689 progress), September 2006. 1691 [I-D.ietf-ipfix-info] 1692 Quittek, J., "Information Model for IP Flow Information 1693 Export", draft-ietf-ipfix-info-15 (work in progress), 1694 February 2007. 1696 [I-D.ietf-ipfix-protocol] 1697 Claise, B., "Specification of the IPFIX Protocol for the 1698 Exchange of IP Traffic Flow Information", 1699 draft-ietf-ipfix-protocol-26 (work in progress), 1700 September 2007. 1702 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1703 RFC 1812, June 1995. 1705 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1706 "Definition of the Differentiated Services Field (DS 1707 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1708 December 1998. 1710 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1711 Schoenwaelder, Ed., "Structure of Management Information 1712 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1714 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1715 "Introduction and Applicability Statements for Internet- 1716 Standard Management Framework", RFC 3410, December 2002. 1718 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 1719 Management Protocol (SNMP)", STD 62, RFC 3417, 1720 December 2002. 1722 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1723 January 2004. 1725 [XML] Yergeau et al., F., "Extensible Markup Language (XML) 1.0 1726 (Third Edition)", W3C Recommendation, February 2004. 1728 Appendix A. Traceroute Default Configuration Parameters 1730 This section lists traceroute measurement configuration parameters as 1731 well as their defaults on various platforms and illustrates how 1732 widely they may vary. This document considered four major traceroute 1733 tool implementations and compared them based on configurable 1734 parameters and default values. The LINUX (SUSE 9.1), BSD (FreeBSD 1735 7.0) and UNIX (SunOS 5.9) implementations are based on UDP datagrams, 1736 while the WINDOWS (XP SP2) one uses ICMP Echos. The comparison is 1737 summarized in the following table, where an N/A in the option column, 1738 means that such parameter is not configurable for the specific 1739 implementation. A comprehensive comparison of available 1740 implementations is outside the scope of this document; however, 1741 already by sampling a few different implementations, it can be 1742 observed that they can differ quite significantly in terms of 1743 configurable parameters and also default values.Note that in the 1744 following table only those options which are available in at least 1745 two of the considered implementations are reported. 1747 +---------------------------------------------------------+ 1748 | OS |Option| Description | Default | 1749 +--------+------+-------------------------------+---------+ 1750 | LINUX | -m |Specify the maximum TTL used | 30 | 1751 |--------+------|in traceroute probes. |---------| 1752 | FreeBSD| -m | | OS var | 1753 |--------+------| |---------| 1754 | UNIX | -m | | 30 | 1755 |--------+------| |---------| 1756 | WINDOWS| -h | | 30 | 1757 +--------+------+-------------------------------+---------+ 1758 | LINUX | -n |Display hop addresses | - | 1759 |--------+------|numerically rather than |---------| 1760 | FreeBSD| -n |symbolically. | - | 1761 |--------+------| |---------| 1762 | UNIX | -n | | - | 1763 |--------+------| |---------| 1764 | WINDOWS| -d | | - | 1765 +--------+------+-------------------------------+---------+ 1766 | LINUX | -w |Set the time to wait for a | 3 sec | 1767 |--------+------|response to a probe. |---------| 1768 | FreeBSD| -w | | 5 sec | 1769 |--------+------| |---------| 1770 | UNIX | -w | | 5 sec | 1771 |--------+------| |---------| 1772 | WINDOWS| -w | | 4 sec | 1773 +--------+------+-------------------------------+---------+ 1774 | LINUX | N/A |Specify a loose source route | - | 1775 |--------+------|gateway (to direct the |---------| 1776 | FreeBSD| -g |traceroute probes through | - | 1777 |--------+------|routers not necessarily in |---------| 1778 | UNIX | -g | the path). | - | 1779 |--------+------| |---------| 1780 | WINDOWS| -g | | - | 1781 +--------+------+-------------------------------+---------+ 1782 | LINUX | -p |Set the base UDP port number | 33434 | 1783 |------- +------|used in traceroute probes |---------| 1784 | FreeBSD| -p |(UDP port = base + nhops - 1). | 33434 | 1785 |--------+------| |---------| 1786 | UNIX | -p | | 33434 | 1787 |--------+------| |---------| 1788 | WINDOWS| N/A | | - | 1789 +--------+------+-------------------------------+---------+ 1790 | LINUX | -q |Set the number of probes per | 3 | 1791 |--------+------|TTL. |---------| 1792 | FreeBSD| -q | | 3 | 1793 |--------+------| |---------| 1794 | UNIX | -q | | 3 | 1795 |--------+------| |---------| 1796 | WINDOWS| N/A | | 3 | 1797 +--------+------+-------------------------------+---------+ 1798 | LINUX | -S |Set the IP source address in |IP | 1799 |--------+------|outgoing probes to the |address | 1800 | FreeBSD| -s |specified value. |of the | 1801 |--------+------| |out | 1802 | UNIX | -s | |interface| 1803 |--------+------| | | 1804 | WINDOWS| N/A | | | 1805 +--------+------+-------------------------------+---------+ 1806 | LINUX | -t |Set the type-of-service (TOS) | 0 | 1807 |--------+------|in the probes to the specified |---------| 1808 | FreeBSD| -t |value. | 0 | 1809 |--------+------| |---------| 1810 | UNIX | -t | | 0 | 1811 |--------+------| |---------| 1812 | WINDOWS| N/A | | 0 | 1813 +--------+------+-------------------------------+---------+ 1814 | LINUX | -v |Verbose output: received ICMP | - | 1815 |--------+------|packets other than |---------| 1816 | FreeBSD| -v |TIME_EXCEEDED and | - | 1817 |--------+------|UNREACHABLE are listed. |---------| 1818 | UNIX | -v | | - | 1819 |--------+------| |---------| 1820 | WINDOWS| N/A | | - | 1821 +--------+------+-------------------------------+---------+ 1822 | LINUX | N/A |Set the time (in msec) to | - | 1823 |--------+------|pause between probes. |---------| 1824 | FreeBSD| -z | | 0 | 1825 |--------+------| |---------| 1826 | UNIX | -P | | 0 | 1827 |--------+------| |---------| 1828 | WINDOWS| N/A | | - | 1829 +--------+------+-------------------------------+---------+ 1830 | LINUX | -r |Bypass the normal routing | - | 1831 |--------+------|tables and send directly to a |---------| 1832 | FreeBSD| -r |host on attached network. | - | 1833 |--------+------| |---------| 1834 | UNIX | -r | | - | 1835 |--------+------| |---------| 1836 | WINDOWS| N/A | | - | 1837 +--------+------+-------------------------------+---------+ 1838 | LINUX | -f |Set the initial TTL for the | 1 | 1839 |--------+------|first probe. |---------| 1840 | FreeBSD| -f | | 1 | 1841 |--------+------| |---------| 1842 | UNIX | -f | | 1 | 1843 |--------+------| |---------| 1844 | WINDOWS| N/A | | 1 | 1845 +--------+------+-------------------------------+---------+ 1846 | LINUX | -F |Set the "don't fragment" bit. | - | 1847 |--------+------| |---------| 1848 | FreeBSD| -F | | - | 1849 |--------+------| |---------| 1850 | UNIX | -F | | - | 1851 |--------+------| |---------| 1852 | WINDOWS| N/A | | - | 1853 +--------+------+-------------------------------+---------+ 1854 | LINUX | N/A |Enables socket level debugging.| - | 1855 |--------+------| |---------| 1856 | FreeBSD| -d | | - | 1857 |--------+------| |---------| 1858 | UNIX | -d | | - | 1859 |--------+------| |---------| 1860 | WINDOWS| N/A | | - | 1861 +--------+------+-------------------------------+---------+ 1862 | LINUX | N/A |Use ICMP ECHO instead of UDP | - | 1863 |--------+------|datagrams. |---------| 1864 | FreeBSD| -I | | - | 1865 |--------+------| |---------| 1866 | UNIX | -I | | - | 1867 |--------+------| |---------| 1868 | WINDOWS| N/A | | - | 1869 +--------+------+-------------------------------+---------+ 1870 | LINUX | -I |Specify a network interface to | - | 1871 |--------+------|obtain the IP address for |---------| 1872 | FreeBSD| -i |outgoing IP packets | - | 1873 |--------+------|(alternative to option -s). |---------| 1874 | UNIX | -i | | - | 1875 |--------+------| |---------| 1876 | WINDOWS| N/A | | - | 1877 +--------+------+-------------------------------+---------+ 1878 | LINUX | N/A |Toggle checksum. | - | 1879 |--------+------| |---------| 1880 | FreeBSD| -x | | - | 1881 |--------+------| |---------| 1882 | UNIX | -x | | - | 1883 |--------+------| |---------| 1884 | WINDOWS| N/A | | - | 1885 +--------+------+-------------------------------+---------+ 1886 | LINUX | - |As optional last parameter, |Depends | 1887 |--------+------|LINUX, FreeBSD and UNIX |on | 1888 | FreeBSD| - |implementations allow |implement| 1889 |--------+------|specifying the probe datagram |ation. | 1890 | UNIX | - |length for outgoing probes. | | 1891 |--------+------| | | 1892 | WINDOWS| N/A | | | 1893 +--------+------+-------------------------------+---------+ 1895 A.1. Alternative Traceroute Implementations 1897 As stated above, the widespread use of firewalls might prevent UDP or 1898 ICMP based traceroutes to completely trace the path to a destination, 1899 since traceroute probes might end up being filtered. In some cases, 1900 such limitation might be overcome by sending instead TCP packets to 1901 specific ports that hosts located behind the firewall are listening 1902 for connections on. TCP based implementations use TCP SYN or FIN 1903 probes and listen for TIME_EXCEEDED messages, TCP RESET and other 1904 messages from firewalls and gateways on the path. On the other hand, 1905 some firewalls filter out TCP SYN packets to prevent denial of 1906 service attacks, therefore the actual advantage of using TCP instead 1907 of UDP traceroute depends mainly on firewall configurations, which 1908 are not known in advance. A detailed analysis of TCP-based 1909 traceroute tools and measurements was outside the scope of this 1910 document, anyway for completeness reasons the information model 1911 supports the storing of TCP-based traceroute measurements, too. 1913 Appendix B. Known Problems with Traceroute 1915 B.1. Compatibility between traceroute measurements results and IPPM 1916 metrics 1918 Because of implementation choices, a known inconsistency exists 1919 between the round-trip delay metric defined by the IPPM working group 1920 in RFC 2681 and the results returned by the current traceroute tool 1921 implementations. Unfortunately, it is unlikely that the traceroute 1922 tool implementations will implement the standard definition in the 1923 near future. The only possibility is therefore to compare results of 1924 different traceroute measurements one with each other; in order to do 1925 this, specifications both of the operating system (name and version) 1926 and of the traceroute tool version used were added to the metadata 1927 elements in order to help in comparing metrics between two different 1928 traceroute measurements results (if run using the same operating 1929 system and the same version of the tool). Moreover, the traceroute 1930 tool has built-in configurable mechanisms like time-outs and can 1931 experience problems related to the crossing of firewalls; therefore 1932 some of the packets that traceroute sends out end up being time-out 1933 or filtered. As a consequence, it might not be possible to trace the 1934 path to a node or there might not be a complete set of probes 1935 describing the RTT to reach it. 1937 Appendix C. Differences to DISMAN-TRACEROUTE-MIB 1939 For performing remote traceroute operations at managed node, the IETF 1940 has standardized the DISMAN-TRACEROUTE-MIB module in [RFC4560]. This 1941 module allows: 1943 o retrieving capability information of the traceroute tool 1944 implementation at the managed node, 1945 o configuring traceroute measurements to be performed, 1946 o retrieving information about ongoing and completed traceroute 1947 measurements, 1948 o retrieving traceroute measurement statistics. 1950 The traceroute storage format described in this document has 1951 significant overlaps with this MIB module. Particularly, the models 1952 for the traceroute measurement configuration and for the result from 1953 completed measurements are almost identical. But for other pats of 1954 the DISMAN-TRACEROUTE MIB module there is no need to model them in a 1955 traceroute measurements storage format. Particularly, the capability 1956 information, information about ongoing measurements and measurement 1957 statistics are not covered by the DISMAN traceroute storage model. 1959 Concerning traceroute measurements and their results, there are 1960 structural differences between the two models caused by the different 1961 choices for the encoding of the specification. For DISMAN- 1962 TRACEROUTE-MIB, the Structure of Management Information (SMIv2, STD 1963 58, RFC 2578 [RFC2578]) was used, while the IPPM traceroute 1964 measurements data model is encoded using XML. 1966 This difference in structure implies that the DISMAN-TRACEROUTE-MIB 1967 module contains SMI-specific information element (managed objects) 1968 that concern tables of managed objects (specification, entry creation 1969 and deletion, status retrieval) that are not required for the XML- 1970 encoded traceroute measurements data model. 1972 But for most of the remaining information elements that concern 1973 configuration of traceroute measurements and results of completed 1974 measurements, the semantics is identical between the DISMAN- 1975 TRACEROUTE-MIB module and the traceroute measurements data model. 1976 There are very few exceptions to this which are listed below. Also 1977 naming of information elements is identical between both models with 1978 a few exceptions. For the traceroute measurements data model, a few 1979 information elements have been added, some because of the different 1980 structure and some to provide additional information on completed 1981 measurements. 1983 C.1. Naming 1985 Basically, names in both models are chosen using the same naming 1986 conventions. 1988 For the traceroute measurement configuration information all names, 1989 such as CtlProbesPerHop, are identical in both models except for the 1990 traceRoute prefix that was removed to avoid unnecessary redundancy in 1991 the XML file and for CtlDataSize which was renamed to 1992 CtlProbeDataSize for clarification in the traceroute measurements 1993 data model. 1995 Results of measurements in the DISMAN-TRACEROUTE-MIB modules are 1996 distributed over two tables, the traceRouteResultsTable containing 1997 mainly information about ongoing measurements and the 1998 traceRouteProbeHistoryTable containing only information about 1999 completed measurements. According to the SMIv2 naming conventions 2000 names of information elements in these tables have different prefixes 2001 (traceRouteResults and traceRouteProbeHistory). Since the traceroute 2002 measurements data model only reports on completed measurements, this 2003 separation is not needed anymore and the prefix "Results" is used for 2004 all related information elements. 2006 Beyond that, there are only a few changes in element names. The 2007 renaming actions include: 2009 o traceRouteProbeHistoryProbeIndex to IndexPerHop, 2010 o traceRouteProbeHistoryResponse to RoundTripTime, 2011 o traceRouteProbeHistoryTime to ResultsEndDateAndTime, 2012 o traceRouteProbeHistoryLastRC to ResultsHopRawOutputData. 2014 C.2. Semantics 2016 The semantics was changed for two information elements only. 2018 For traceRouteProbeHistoryResponse in the DISMAN-TRACEROUTE-MIB, a 2019 value of 0 indicated, that it was not possible to transmit a probe. 2020 For the traceroute measurements data model, a value of 0 for element 2021 RoundTripTime indicates that the measured time was less than one 2022 millisecond, while for the case that it was not possible to transmit 2023 a probe a string is used that indicates the problem. 2025 For traceRouteCtlIfIndex in the DISMAN-TRACEROUTE-MIB, a value of 0 2026 indicated, that it the option to set the index is not available. 2027 This was translated to the traceroute measurements data model, such 2028 that a value of 0 for this element indicates that the used interface 2029 is unknown. 2031 The element traceRouteProbeHistoryLastRC in the DISMAN-TRACEROUTE-MIB 2032 was replaced by element ResultsHopRawOutputData. While 2033 traceRouteProbeHistoryLastRC just reports a reply code, 2034 ResultsHopRawOutputData reports the full raw output data produced by 2035 the traceroute measurements that was used. 2037 C.3. Additional Information Elements 2039 Only a few information elements have been added to the model of the 2040 DISMAN-TRACEROUTE-MIB module. 2042 o For providing geographical information about hops in the 2043 traceroute measurement path, HopGeoLocation was added. 2044 o For providing the top MPLS label stack entry of a probe in the 2045 traceroute measurement path MPLSTopLabel was added. 2046 o For providing additional timestamp beyond ResultsEndDateAndTime, 2047 ResultsStartDateAndTime and Time were added. 2049 Authors' Addresses 2051 Saverio Niccolini 2052 Network Laboratories, NEC Europe Ltd. 2053 Kurfuersten-Anlage 36 2054 Heidelberg 69115 2055 Germany 2057 Phone: +49 (0) 6221 4342 118 2058 Email: saverio.niccolini@netlab.nec.de 2059 URI: http://www.netlab.nec.de 2061 Sandra Tartarelli 2062 Network Laboratories, NEC Europe Ltd. 2063 Kurfuersten-Anlage 36 2064 Heidelberg 69115 2065 Germany 2067 Phone: +49 (0) 6221 4342 132 2068 Email: sandra.tartarelli@netlab.nec.de 2069 URI: http://www.netlab.nec.de 2070 Juergen Quittek 2071 Network Laboratories, NEC Europe Ltd. 2072 Kurfuersten-Anlage 36 2073 Heidelberg 69115 2074 Germany 2076 Phone: +49 (0) 6221 4342 115 2077 Email: quittek@netlab.nec.de 2078 URI: http://www.netlab.nec.de 2080 Martin Swany 2081 Dept. of Computer and Information Sciences, University of Delaware 2082 Newark DE 19716 2083 U.S.A. 2085 Email: swany@UDel.Edu 2087 Full Copyright Statement 2089 Copyright (C) The IETF Trust (2007). 2091 This document is subject to the rights, licenses and restrictions 2092 contained in BCP 78, and except as set forth therein, the authors 2093 retain all their rights. 2095 This document and the information contained herein are provided on an 2096 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2097 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2098 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2099 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2100 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2101 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2103 Intellectual Property 2105 The IETF takes no position regarding the validity or scope of any 2106 Intellectual Property Rights or other rights that might be claimed to 2107 pertain to the implementation or use of the technology described in 2108 this document or the extent to which any license under such rights 2109 might or might not be available; nor does it represent that it has 2110 made any independent effort to identify any such rights. Information 2111 on the procedures with respect to rights in RFC documents can be 2112 found in BCP 78 and BCP 79. 2114 Copies of IPR disclosures made to the IETF Secretariat and any 2115 assurances of licenses to be made available, or the result of an 2116 attempt made to obtain a general license or permission for the use of 2117 such proprietary rights by implementers or users of this 2118 specification can be obtained from the IETF on-line IPR repository at 2119 http://www.ietf.org/ipr. 2121 The IETF invites any interested party to bring to its attention any 2122 copyrights, patents or patent applications, or other proprietary 2123 rights that may cover technology that may be required to implement 2124 this standard. Please address the information to the IETF at 2125 ietf-ipr@ietf.org. 2127 Acknowledgment 2129 Funding for the RFC Editor function is provided by the IETF 2130 Administrative Support Activity (IASA).