idnits 2.17.1 draft-ietf-ippm-storetraceroutes-06.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 2140. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2151. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2158. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2164. 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 1861 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 (November 19, 2007) is 6004 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 812, but not defined == Missing Reference: '0-9' is mentioned on line 813, but not defined == Missing Reference: '0-4' is mentioned on line 813, but not defined == Missing Reference: '0-5' is mentioned on line 813, 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: May 22, 2008 NEC 6 M. Swany 7 UDel 8 November 19, 2007 10 Information Model and XML Data Model for Traceroute Measurements 11 draft-ietf-ippm-storetraceroutes-06 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 May 22, 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 . . . . . . . . . . . . . . . . . . . 15 67 5.2.4. Information Elements to compare traceroute 68 measurements results one with each other . . . . . . . 15 69 6. Data Model for Storing Traceroute Measurements . . . . . . . . 16 70 7. XML Schema for traceroute Measurements . . . . . . . . . . . . 17 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 72 8.1. Conducting Traceroute Measurements . . . . . . . . . . . . 35 73 8.2. Securing Traceroute Measurements Information . . . . . . . 36 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 37 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 37 78 Appendix A. Traceroute Default Configuration Parameters . . . . . 38 79 A.1. Alternative Traceroute Implementations . . . . . . . . . . 42 80 Appendix B. Known Problems with Traceroute . . . . . . . . . . . 42 81 B.1. Compatibility between traceroute measurements results 82 and IPPM metrics . . . . . . . . . . . . . . . . . . . . . 42 83 Appendix C. Differences to DISMAN-TRACEROUTE-MIB . . . . . . . . 43 84 C.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 44 85 C.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 44 86 C.3. Additional Information Elements . . . . . . . . . . . . . 45 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 88 Intellectual Property and Copyright Statements . . . . . . . . . . 47 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. 226 o default value - The default value for the element (where 227 applicable). 229 5.1. Data Types 231 This section describes the set of valid data types of the information 232 model. 234 o String - The type "String" represents a finite length string of 235 valid characters from the Unicode character encoding set. Unicode 236 allows for ASCII and many other international character sets to be 237 used. It is expected that strings will be encoded in UTF-8 238 format, which is identical in encoding for USASCII characters, but 239 also accommodates other Unicode multi-byte characters. 240 o InetAddressType - The type "InetAddressType" represents a type of 241 Internet address. The allowed values are to be intended as 242 imported from [RFC4001]; an additional allowed value is 243 "asnumber". 244 o InetAddress - The type "InetAddress" denotes a generic Internet 245 address. The allowed values are to be intended as imported from 246 [RFC4001]; an additional allowed value is the AS number to be 247 indicated as the actual number plus the indication how the mapping 248 from IP address to AS number was performed. 249 o TruthValue - The type "TruthValue" represents a Boolean value. 250 The allowed values are to be intended as imported from [RFC2579]. 251 o Unsigned32 - The type "Unsigned32" represents a value in the range 252 (0..4294967295). 253 o Unsigned16 - The type "Unsigned16" represents a value in the range 254 (0..65535). 255 o Unsigned8 - The type "Unsigned32" represents a value in the range 256 (0..255). 257 o InterfaceIndexOrZero - The type "InterfaceIndexOrZero" is an 258 extension of the InterfaceIndex convention. The latter defines a 259 greater than zero value used to identify an interface or interface 260 sub-layer in the system. This extension permits the additional 261 value of zero. Examples of the usage of zero might include 262 situations where interface was unknown, or when none or all 263 interfaces need to be referenced. The allowed values are to be 264 intended as imported from [RFC2863]. 265 o ProbesType - The type "ProbesType" represents a way of indicating 266 the protocol used for the traceroute probes. Allowed values are 267 UDP, TCP, ICMP. 268 o DateAndTime - The type "DateAndTime" represents a date-time 269 specification. The allowed values are to be intended as imported 270 from [RFC2579] apart from the fact that in this document there is 271 the need to use a millisecond resolution instead a decisecond one. 272 o OperationResponseStatus - The type "OperationResponseStatus" is 273 used to report the result of an operation. The allowed values are 274 to be intended as imported from [RFC4560]. 276 5.2. Information Elements 278 This section describes the elements related to the storing of a 279 traceroute measurement. The elements are grouped in two groups 280 (Configuration and Results) according to their semantics. In order 281 to relate configuration and results elements by means of a common 282 unique identifier, an additional element is defined belonging to both 283 the two groups. The default values are reported (where applicable) 284 in the configuration information elements as reference to BCP 285 recommendations and are not enforced in the data model (e.g. XML 286 schema). Configuration information elements with default values are 287 anyway optional elements and are going to be absent in the XML data 288 if the user did not set such parameter whereas they are going to be 289 set by the specific implementation according to specific dafaults 290 that are not common among different versions of the traceroute tool. 292 5.2.1. Configuration Information Elements 294 This section describes the elements specific to the configuration of 295 the traceroute measurement. 297 5.2.1.1. CtlTargetAddressType 299 o name - CtlTargetAddressType 300 o description - Specifies the type of destination address used in 301 the traceroute measurement. 302 o dataType - InetAddressType 303 o units - N/A 304 o default value - N/A 306 5.2.1.2. CtlTargetAddress 308 o name - CtlTargetAddress 309 o description - Specifies the host address used in the traceroute 310 measurement. The host address type can be determined by the 311 examining the value of the corresponding CtlTargetAddressType. 312 o dataType - InetAddress 313 o units - N/A 314 o default value - N/A 316 5.2.1.3. CtlBypassRouteTable 318 o name - CtlBypassRouteTable 319 o description - Specifies if the optional bypassing of the route 320 table was enabled or not. If enabled, the normal routing tables 321 will be bypassed and the probes will be sent directly to a host on 322 an attached network. If the host is not on a directly-attached 323 network, an error is returned. This option can be used to perform 324 the traceroute measurement to a local host through an interface 325 that has no route defined. 326 o dataType - TruthValue 327 o units - N/A 328 o default value - false 330 5.2.1.4. CtlProbeDataSize 332 o name - CtlProbeDataSize 333 o description - Specifies the size of the probes of a traceroute 334 measurement in octets. If UDP datagrams are used as probes, then 335 the value contained in this object is exact. If another protocol 336 is used to transmit probes (i.e. TCP or ICMP) for which the 337 specified size is not appropriate, then the implementation can use 338 whatever size (appropriate to the method) is closest to the 339 specified size. The maximum value for this object was computed by 340 subtracting the smallest possible IP header size of 20 octets 341 (IPv4 header with no options) and the UDP header size of 8 octets 342 from the maximum IP packet size. An IP packet has a maximum size 343 of 65535 octets (excluding IPv6 Jumbograms). 344 o dataType - Unsigned32 345 o units - octets 346 o default value - 0 348 5.2.1.5. CtlTimeOut 350 o name - CtlTimeOut 351 o description - Specifies the time-out value, in seconds, for each 352 probe of a traceroute measurement. 353 o dataType - Unsigned32 354 o units - seconds 355 o default value - 3 357 5.2.1.6. CtlProbesPerHop 359 o name - CtlProbesPerHop 360 o description - Specifies the number of probes with the same time- 361 to-live (TTL) value that are sent for each host. 362 o dataType - Unsigned32 363 o units - probes 364 o default value - 3 366 5.2.1.7. CtlPort 368 o name - CtlPort 369 o description - Specifies the base UDP port used by the traceroute 370 measurement. A port that is not in use at the destination 371 (target) host needs to be specified. The default value for this 372 object is the IANA assigned port, 33434, for the traceroute 373 measurement. 374 o dataType - Unsigned32 375 o units - UDP Port 376 o default value - 33434 378 5.2.1.8. CtlMaxTtl 380 o name - CtlMaxTtl 381 o description - Specifies the maximum TTL value for the traceroute 382 measurement. 383 o dataType - Unsigned32 384 o units - time-to-live value 385 o default value - 30 387 5.2.1.9. CtlDSField 389 o name - CtlDSField 390 o description - Specifies the value that was stored in the 391 Differentiated Services (DS) field in the traceroute probe. The 392 DS Field is defined as the Type of Service (TOS) octet in a IPv4 393 header or as the Traffic Class octet in a IPv6 header. The value 394 of this object must be a decimal integer in the range from 0 to 395 255. This option can be used to determine what effect an explicit 396 DS field setting has on a traceroute measurement and its probes. 397 Not all values are legal or meaningful. Useful TOS octet values 398 are probably '16' (low delay) and '8' (high throughput). Further 399 references can be found in [RFC2474] for the definition of the 400 Differentiated Services (DS) field and to [RFC1812] Section 5.3.2 401 for Type of Service (TOS). 402 o dataType - Unsigned32 403 o units - N/A 404 o default value - 0 406 5.2.1.10. CtlSourceAddressType 408 o name - CtlSourceAddressType 409 o description - Specifies the type of the source address, 410 CtlSourceAddress, used in the traceroute measurement. 411 o dataType - InetAddressType 412 o units - N/A 413 o default value - N/A 415 5.2.1.11. CtlSourceAddress 417 o name - CtlSourceAddress 418 o description - Specifies the IP address (which has to be given as 419 an IP number, not a hostname) as the source address used in 420 traceroute probes. On hosts with more than one IP address, this 421 option can be used to force the source address to be something 422 other than the primary IP address of the interface the probe is 423 sent on. A zero length octet string value for this object means 424 that source address specification was disabled. The address type 425 (InetAddressType) that relates to this object is specified by the 426 corresponding value of CtlSourceAddressType. 427 o dataType - InetAddress 428 o units - N/A 429 o default value - N/A 431 5.2.1.12. CtlIfIndex 433 o name - CtlIfIndex 434 o description - Specifies the interface index used in the traceroute 435 measurement for sending the traceroute probes. A value of zero 436 for this object implies that the interface was unknown. 437 o dataType - InterfaceIndexOrZero 438 o units - N/A 439 o default value - 0 441 5.2.1.13. CtlMiscOptions 443 o name - CtlMiscOptions 444 o description - Specifies implementation dependent options. 445 o dataType - String 446 o units - N/A 447 o default value - N/A 449 5.2.1.14. CtlMaxFailures 451 o name - CtlMaxFailures 452 o description - Specifies the maximum number of consecutive timeouts 453 allowed before terminating a traceroute measurement. A value of 454 either 255 (maximum hop count/possible TTL value) or a 0 indicates 455 that the function of terminating a remote traceroute measurement 456 when a specific number of consecutive timeouts are detected was 457 disabled. This element is included to give full compatibility 458 with [RFC4560]. No known implementation of traceroute currently 459 supports it. 460 o dataType - Unsigned32 461 o units - timeouts 462 o default value - 5 464 5.2.1.15. CtlDontFragment 466 o name - CtlDontFragment 467 o description - Specifies if the don't fragment flag (DF) in the IP 468 header for a probe was enabled or not. Setting the DF flag can be 469 used for performing a manual PATH MTU test. 470 o dataType - TruthValue 471 o units - N/A 472 o default value - false 474 5.2.1.16. CtlInitialTtl 476 o name - CtlInitialTtl 477 o description - Specifies the initial TTL value used in a traceroute 478 measurement. Such TTL setting is intended to bypass the initial 479 (often well known) portion of a path. 480 o dataType - Unsigned32 481 o units - N/A 482 o default value - 1 484 5.2.1.17. CtlDescr 486 o name - CtlDescr 487 o description - The purpose of this element is to provide a 488 description of the traceroute measurement. 489 o dataType - String 490 o units - N/A 491 o default value - N/A 493 5.2.1.18. CtlType 495 o name - CtlType 496 o description - Specifies the implementation method used for the 497 traceroute measurement. It specifies if the traceroute is using 498 TCP, UDP or ICMP probes. 499 o dataType - ProbesType 500 o units - N/A 501 o default value - UDP 503 5.2.2. Results Information Elements 505 This section describes the elements specific to the results of the 506 traceroute measurement. 508 5.2.2.1. ResultsStartDateAndTime 509 o name - ResultsStartDateAndTime 510 o description - Specifies the date and start time of the traceroute 511 measurement. This is the time when the first probe was seen at 512 the sending interface. 513 o dataType - DateAndTime 514 o units - N/A 515 o default value - N/A 517 5.2.2.2. ResultsIpTgtAddrType 519 o name - ResultsIpTgtAddrType 520 o description - Specifies the type of address stored in the 521 corresponding ResultsIpTgtAddr element. 522 o dataType - InetAddressType 523 o units - N/A 524 o default value - N/A 526 5.2.2.3. ResultsIpTgtAddr 528 o name - ResultsIpTgtAddr 529 o description - Specifies the IP address associated with a 530 CtlTargetAddress value when the destination address is specified 531 as a DNS name. The value of this object should be a zero length 532 octet string when a DNS name is not specified or when a specified 533 DNS name fails to resolve. 534 o dataType - InetAddress 535 o units - N/A 536 o default value - N/A 538 5.2.2.4. Index 540 o name - Index 541 o description - Specifies an index that consecutively numbers all 542 probes for which a reply was received in the sequential order in 543 which the replies were received. The maximum value for this 544 object is CtlMaxTtl*CtlProbesPerHop. 545 o dataType - Unsigned32 546 o units - N/A 547 o default value - N/A 549 5.2.2.5. HopIndex 551 o name - HopIndex 552 o description - Specifies which hop in a traceroute measurement path 553 the probe's results are for. 554 o dataType - Unsigned32 555 o units - N/A 556 o default value - N/A 558 5.2.2.6. IndexPerHop 560 o name - IndexPerHop 561 o description - Specifies the index of a probe for a particular hop 562 in a traceroute measurement path. The number of probes per hop is 563 determined by the value of the corresponding CtlProbesPerHop 564 element. 565 o dataType - Unsigned32 566 o units - N/A 567 o default value - N/A 569 5.2.2.7. HopAddrType 571 o name - HopAddrType 572 o description - Specifies the type of address stored in the 573 corresponding HopAddr element. 574 o dataType - InetAddressType 575 o units - N/A 576 o default value - N/A 578 5.2.2.8. HopAddr 580 o name - HopAddr 581 o description - Specifies the address of a hop in the traceroute 582 measurement path. This object is not allowed to be a DNS name. 583 The value of the corresponding object, HopAddrType, indicates this 584 object's IP address type. 585 o dataType - InetAddress 586 o units - N/A 587 o default value - N/A 589 5.2.2.9. HopGeoLocation 591 o name - HopGeoLocation 592 o description - Specifies the geo location of a hop in the 593 traceroute measurement path. 594 o dataType - String 595 o units - N/A 596 o default value - N/A 598 5.2.2.10. MPLSTopLabel 600 o name - MPLSTopLabel 601 o description - Specifies the top entry of the MPLS label stack of a 602 probe observed when the probe arrived at the hop that replied to 603 the probe. This object contains the top MPLS label stack entry as 604 32 bit value as it is observed on the MPLS label stack. Contained 605 in this single number are the MPLS label, the Exp field, the S 606 flag, and the MPLS TTL value as specified in RFC 3032. 607 o dataType - Unsigned32 608 o units - N/A 609 o default value - N/A 611 5.2.2.11. RoundTripTime 613 o name - RoundTripTime 614 o description - Specifies the amount of time measured in 615 milliseconds from when a probe was sent to when its response was 616 received or when it timed out. The value of this element is 617 reported as the truncation of the number reported by the 618 traceroute tool (the output "< 1 ms" is therefore encoded as 0 619 ms). A string with the value of "RoundTripTimeNotAvailable" means 620 either the probe was lost because of a timeout or it was not 621 possible to transmit a probe. 622 o dataType - Unsigned32 or String 623 o units - milliseconds or N/A 624 o default value - N/A 626 5.2.2.12. ResponseStatus 628 o name - ResponseStatus 629 o description - Specifies the result of a traceroute measurement 630 made by the host for a particular probe. 631 o dataType - OperationResponseStatus 632 o units - N/A 633 o default value - N/A 635 5.2.2.13. Time 637 o name - Time 638 o description - Specifies the timestamp for when the response to the 639 probe was received at the interface. 640 o dataType - DateAndTime 641 o units - N/A 642 o default value - N/A 644 5.2.2.14. ResultsHopRawOutputData 646 o name - ResultsHopRawOutputData 647 o description - Specifies the raw output data returned by the 648 traceroute measurement for a certain hop in a traceroute 649 measurement path. 650 o dataType - String 651 o units - N/A 652 o default value - N/A 654 5.2.2.15. ResultsEndDateAndTime 656 o name - ResultsEndDateAndTime 657 o description - Specifies the date and end time of the traceroute 658 measurement. It is either the time when the response to the last 659 probe of the traceroute measurement was received or the time when 660 the last probe of the traceroute measurement was sent plus the 661 relative timeout (in case of missing response). 662 o dataType - DateAndTime 663 o units - N/A 664 o default value - N/A 666 5.2.3. Information Element Correlating Configuration and Results 667 Elements 669 This section defines an additional element belonging to both the two 670 previous groups (configuration elements and result elements) named 671 TestName. This element is defined in order to relate configuration 672 elements and results ones by means of a common unique identifier. 674 5.2.3.1. TestName 676 o name - TestName 677 o description - Specifies the name of a traceroute measurement. 678 This is locally unique. 679 o dataType - String 680 o units - N/A 681 o default value - N/A 683 5.2.4. Information Elements to compare traceroute measurements results 684 one with each other 686 This section defines additional elements belonging to both the two 687 previous groups (configuration elements and result elements); these 688 elements were defined in order to allow traceroute measurements 689 results comparison among different traceroute measurements. 691 5.2.4.1. OSName 692 o name - OSName 693 o description - Specifies the name of the operating system on which 694 the traceroute measurement was launched. 695 o dataType - String 696 o units - N/A 697 o default value - N/A 699 5.2.4.2. OSVersion 701 o name - OSVersion 702 o description - Specifies the OS version on which the traceroute 703 measurement was launched. 704 o dataType - String 705 o units - N/A 706 o default value - N/A 708 5.2.4.3. ToolVersion 710 o name - ToolVersion 711 o description - Specifies the version of the traceroute tool used. 712 o dataType - String 713 o units - N/A 714 o default value - N/A 716 6. Data Model for Storing Traceroute Measurements 718 For storing and transmitting information according to the information 719 model defined in the previous section, a data model is required that 720 specifies how to encode the elements of the information model. 722 There are several design choices for a data model. It can use a 723 binary or textual representation and it can be defined from scratch 724 or use already existing frameworks and data models. In general, the 725 use of already existing frameworks and models should be preferred. 727 Binary and textual representation both have advantages and 728 disadvantages. Textual representations are (with some limitations) 729 human readable while a binary representation consumes less resources 730 for storing, transmitting and parsing data. 732 An already existing and closely related data model is the DISMAN- 733 TRACEROUTE-MIB module [RFC4560], that specifies a BER encoding 734 [RFC3417] used by the Simple Network Management Protocol (SNMP) 735 [RFC3410] for transmitting traceroute measurement information 736 (configuration and results). This data model is well suited and 737 supported within network management systems, but as a general format 738 for storing and transmitting traceroute results it is not easily 739 applicable. 741 Another binary representation would be an extension of traffic flow 742 information encodings as specified for the IPFIX protocol 743 [I-D.ietf-ipfix-protocol], [I-D.ietf-ipfix-info]. The IPFIX protocol 744 is extensible. However, the architecture behind this protocol 745 [I-D.ietf-ipfix-architecture] is targeted at exporting passively 746 measured flow information. Therefore, some obstacles are expected 747 when trying to use it for transmitting traceroute measurements 748 information. 750 For textual representations, using the eXtensible Markup Language 751 (XML) [XML] is an obvious choice. XML supports clean structuring of 752 data and syntax checking of records. With some limitations it is 753 human readable. It is supported well by a huge pool of tools and 754 standards for generating, transmitting, parsing and converting it to 755 other data formats. Its disadvantages is the resource consumption 756 for processing, storing, and transmitting information. Since the 757 expected data volumes related to traceroute measurements in network 758 operation and maintenance is not expected to be extremely high, the 759 inefficient usage of resources is not a significant disadvantage. 760 Therefore, XML was chosen as basis for the traceroute measurements 761 information model that is specified in this section. 763 Section 7 contains the XML schema to be used as a template for 764 storing and/or exchanging traceroute measurements information. The 765 schema was designed in order to use an extensible approach based on 766 templates (pretty similar to how IPFIX protocol is designed) where 767 the traceroute configuration elements (both the requested parameters, 768 Request, and the actual parameters used, MeasurementMetadata) are 769 metadata to be referenced by results information elements (data) by 770 means of the TestName element (used as unique identifier). Currently 771 Open Grid Forum (OGF) is also using this approach and cross- 772 requirements have been analyzed. As a result of this analysis the 773 XML schema contained in Section 7 is compatible with OGF schema since 774 it was designed in a way that both limits the unnecessary redundancy 775 and a simple one-to-one transformation between the two exist. 777 7. XML Schema for traceroute Measurements 779 780 783 784 785 786 787 788 789 790 791 793 794 795 796 797 798 799 800 801 803 804 805 806 807 809 810 811 814 815 817 818 819 821 822 824 825 826 827 828 830 831 832 833 834 835 836 837 838 839 840 841 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 859 860 861 863 864 865 866 867 869 870 871 Specifies the name of a 872 traceroute measurement. This is locally unique. 873 874 875 876 877 878 880 881 882 Specifies the name of the operating 883 system on which the traceroute measurement was 884 launched. 885 886 887 888 889 890 892 893 894 Specifies the OS version on which the 895 traceroute measurement was launched. 896 897 898 899 900 901 903 904 905 Specifies the version of the traceroute 906 tool used. 907 908 909 910 911 912 914 915 916 Specifies if the optional bypassing 917 of the route table was enabled or not. If enabled, 918 the normal routing tables will be bypassed and the 919 probes will be sent directly to a host on an attached 920 network. If the host is not on a directly-attached 921 network, an error is returned. This option can be 922 used to perform the traceroute measurement to a 923 local host through an interface that has no route 924 defined. 925 926 927 928 929 930 931 Specifies the size of the probes 932 of a traceroute measurement in octets. If UDP 933 datagrams are used as probes, then the value 934 contained in this object is exact. If another 935 protocol is used to transmit probes (i.e. TCP or 936 ICMP) for which the specified size is not 937 appropriate, then the implementation can use 938 whatever size (appropriate to the method) is 939 closest to the specified size. The maximum value 940 for this object was computed by subtracting the 941 smallest possible IP header size of 20 octets (IPv4 942 header with no options) and the UDP header size of 943 8 octets from the maximum IP packet size. An IP 944 packet has a maximum size of 65535 octets (excluding 945 IPv6 Jumbograms). 946 947 948 949 950 951 953 954 955 Specifies the time-out value, in 956 seconds, for each probe of a traceroute measurement. 957 958 959 960 961 962 963 965 966 967 Specifies the number of probes 968 with the same time-to-live (TTL) value that are 969 sent for each host. 970 971 972 973 974 975 976 977 978 979 Specifies the base UDP port used 980 by the traceroute measurement. A port that is not 981 in use at the destination (target) host needs to be 982 specified. The default value for this object is the 983 IANA assigned port, 33434, for the traceroute 984 measurement. 985 986 987 988 989 990 992 993 994 Specifies the maximum TTL value 995 for the traceroute measurement. 996 997 998 999 1000 1001 1003 1004 1005 Specifies the value that was 1006 stored in the Differentiated Services (DS) field 1007 in the traceroute probe. The DS Field is defined 1008 as the Type of Service (TOS) octet in a IPv4 header 1009 or as the Traffic Class octet in a IPv6 header. 1010 The value of this object must be a decimal integer 1011 in the range from 0 to 255. This option can be 1012 used to determine what effect an explicit DS field 1013 setting has on a traceroute measurement and its 1014 probes. Not all values are legal or meaningful. 1015 Useful TOS octet values are probably '16' (low 1016 delay) and '8' (high throughput). Further references 1017 can be found in RFC 2474 for the definition of the 1018 Differentiated Services (DS) field and to RFC 1812 1019 Section 5.3.2 for Type of Service (TOS). 1020 1021 1022 1023 1024 1025 1026 Specifies the interface index 1027 used in the traceroute measurement for sending 1028 the traceroute probes. A value of zero for this 1029 object implies that the interface was unknown. 1030 1031 1032 1033 1035 1036 1037 Specifies implementation dependent 1038 options. 1039 1040 1041 1042 1043 1045 1046 1047 Specifies the maximum number 1048 of consecutive timeouts allowed before terminating 1049 a traceroute measurement. A value of either 255 1050 (maximum hop count/possible TTL value) or a 0 1051 indicates that the function of terminating a 1052 remote traceroute measurement when a specific 1053 number of consecutive timeouts are detected was 1054 disabled. This element is included to give full 1055 compatibility with RFC 4560. No known implementation 1056 of traceroute currently supports it. 1057 1058 1059 1060 1062 1063 1064 Specifies if the don't fragment 1065 flag (DF) in the IP header for a probe was enabled 1066 or not. Setting the DF flag can be used for 1067 performing a manual PATH MTU test. 1068 1069 1070 1071 1072 1073 1074 Specifies the initial TTL 1075 value used in a traceroute measurement. Such 1076 TTL setting is intended to bypass the initial 1077 (often well known) portion of a path. 1078 1079 1080 1081 1082 1083 1085 1086 1087 The purpose of this element 1088 is to provide a description of the traceroute 1089 measurement. 1090 1091 1092 1093 1094 1095 1097 1098 1099 Specifies the implementation 1100 method used for the traceroute measurement. 1101 It specifies if the traceroute is using TCP, 1102 UDP or ICMP probes. 1103 1104 1105 1106 1107 1108 1109 1110 1112 1113 1114 Specifies an index that 1115 consecutively numbers all probes for which 1116 a reply was received in the sequential order 1117 in which the replies were received. The 1118 maximum value for this object is 1119 CtlMaxTtl*CtlProbesPerHop. 1121 1122 1123 1124 1125 1126 1127 1129 1130 1131 Specifies which hop in a 1132 traceroute measurement path the probe's 1133 results are for. 1134 1135 1136 1137 1138 1139 1141 1142 1143 Specifies the index of a 1144 probe for a particular hop in a traceroute 1145 measurement path. The number of probes per hop 1146 is determined by the value of the corresponding 1147 CtlProbesPerHop element. 1148 1149 1150 1151 1152 1153 1154 1156 1157 1158 Specifies the geo location of a 1159 hop in the traceroute measurement path. 1160 1161 1162 1163 1164 1165 1167 1168 1169 Specifies the top entry of the 1170 MPLS label stack of a probe observed when the probe 1171 arrived at the hop that replied to the probe. 1172 This object contains the top MPLS label stack 1173 entry as 32 bit value as it is observed on the MPLS 1174 label stack. Contained in this single number are the 1175 MPLS label, the Exp field, the S flag, and the MPLS 1176 TTL value as specified in RFC 3032. 1177 1178 1179 1180 1181 1182 1184 1185 1186 1187 1188 1190 1191 1192 1193 1194 1196 1197 1198 Specifies the raw output data 1199 returned by the traceroute measurement for a certain 1200 hop in a traceroute measurement path. 1201 1202 1203 1204 1205 1206 1208 1209 1210 Specifies the AS number of a hop in the 1211 traceroute path as a 24 bit number and the indication how 1212 the mapping from IP address to AS number was performed. 1213 1214 1215 1216 1218 1220 1221 1223 1224 1225 1227 1229 1231 1233 1235 1236 1238 1239 1240 1242 1244 1246 1248 1250 1251 1253 1254 1255 1257 1259 1260 1262 1263 1264 Specifies the type of destination 1265 address used in the traceroute measurement. 1266 1267 1268 1269 1271 1272 1274 1275 1276 Specifies the host address 1277 used in the traceroute measurement. The host 1278 address type can be determined by the examining 1279 the value of the corresponding CtlTargetAddressType. 1280 1281 1282 1283 1284 1285 1287 1288 1289 Specifies the type of the source 1290 address, CtlSourceAddress, used in the traceroute 1291 measurement. 1292 1293 1294 1295 1297 1298 1300 1301 1302 Specifies the IP address (which 1303 has to be given as an IP number, not a hostname) 1304 as the source address used in traceroute probes. 1305 On hosts with more than one IP address, this option 1306 can be used to force the source address to be 1307 something other than the primary IP address of the 1308 interface the probe is sent on. A zero length 1309 octet string value for this object means that 1310 source address specification was disabled. The 1311 address type (InetAddressType) that relates to 1312 this object is specified by the corresponding 1313 value of CtlSourceAddressType. 1314 1315 1316 1317 1319 1320 1322 1323 1324 Specifies the date and start 1325 time of the traceroute measurement. This is the 1326 time when the first probe was seen at the sending 1327 interface. 1328 1329 1330 1331 1332 1333 1335 1336 1337 Specifies the type of address stored 1338 in the corresponding ResultsIpTgtAddr element. 1339 1340 1341 1342 1344 1345 1347 1348 1349 Specifies the IP address associated 1350 with a CtlTargetAddress value when the destination 1351 address is specified as a DNS name. The value of 1352 this object should be a zero length octet string 1353 when a DNS name is not specified or when a specified 1354 DNS name fails to resolve. 1355 1356 1357 1358 1360 1362 1364 1365 1366 Specifies the type of address stored 1367 in the corresponding HopAddr element. 1368 1369 1370 1371 1373 1374 1376 1377 1378 Specifies the address of a 1379 hop in the traceroute measurement path. This 1380 object is not allowed to be a DNS name. The 1381 value of the corresponding object, HopAddrType, 1382 indicates this object's IP address type. 1383 1384 1385 1386 1388 1389 1391 1392 1393 Specifies the amount of 1394 time measured in milliseconds from when a 1395 probe was sent to when its response was 1396 received or when it timed out. The value of 1397 this element is reported as the truncation 1398 of the number reported by the traceroute 1399 tool (the output "< 1 ms" is therefore 1400 encoded as 0 ms). A string with the value of 1401 "RoundTripTimeNotAvailable" means either the 1402 probe was lost because of a timeout or it 1403 was not possible to transmit a probe. 1404 1405 1406 1407 1409 1411 1412 1414 1415 1416 Specifies the result of a traceroute 1417 measurement made by the host for a particular probe. 1418 1419 1420 1421 1423 1424 1426 1427 1428 Specifies the timestamp for 1429 when the response to the probe was received at the 1430 interface. 1431 1432 1433 1434 1435 1436 1438 1439 1440 1442 1444 1446 1448 1450 1453 1456 1459 1461 1463 1464 1466 1467 1468 Specifies the date and end time 1469 of the traceroute measurement. It is either the 1470 time when the response to the last probe of the 1471 traceroute measurement was received or the time 1472 when the last probe of the traceroute measurement 1473 was sent plus the relative timeout (in case of 1474 missing response). 1475 1476 1477 1478 1479 1480 1482 1483 1484 Specifies the metadata for a 1485 traceroute operation. In a request, these are the 1486 requested parameters. In a response, they are the 1487 actual parameters used. 1488 1489 1490 1491 1493 1496 1499 1502 1504 1506 1509 1512 1515 1518 1521 1524 1527 1529 1531 1534 1537 1540 1543 1546 1549 1552 1553 1554 1555 1556 1557 Contains the actual traceroute measurement 1558 results. 1559 1560 1561 1562 1564 1566 1568 1570 1573 1576 1578 1579 1581 1582 1583 1584 1586 1587 1588 1590 1591 1592 1594 1595 1596 1598 1600 1601 1602 1604 1606 1607 1608 1610 1612 1613 1614 1616 1618 1620 1621 1622 1624 1625 1629 1631 8. Security Considerations 1633 Security considerations in this section discuss are grouped into 1634 considerations related to conducting traceroute measurements and 1635 considerations related to storing and transmitting traceroute 1636 measurements information. 1638 This memo does not specify an implementation of a traceroute tool. 1639 Neither does it specify a certain procedure for storing traceroute 1640 measurements information. Still it is considered desirable to 1641 discuss related security issues below. 1643 8.1. Conducting Traceroute Measurements 1645 Conducting Internet measurements can raise both security and privacy 1646 concerns. Traceroute measurements, in which traffic is injected into 1647 the network, can be abused for denial-of-service attacks disguised as 1648 legitimate measurement activity. 1650 Measurement parameters MUST be carefully selected so that the 1651 measurements inject trivial amounts of additional traffic into the 1652 networks they measure. If they inject "too much" traffic, they can 1653 skew the results of the measurement, and in extreme cases cause 1654 congestion and denial of service. 1656 The measurements themselves could be harmed by routers giving 1657 measurement traffic a different priority than "normal" traffic, or by 1658 an attacker injecting artificial measurement traffic. If routers can 1659 recognize measurement traffic and treat it separately, the 1660 measurements will not reflect actual user traffic. If an attacker 1661 injects artificial traffic that is accepted as legitimate, the loss 1662 rate will be artificially lowered. Therefore, the measurement 1663 methodologies SHOULD include appropriate techniques to reduce the 1664 probability measurement traffic can be distinguished from "normal" 1665 traffic. 1667 Authentication techniques, such as digital signatures, may be used 1668 where appropriate to guard against injected traffic attacks. 1670 8.2. Securing Traceroute Measurements Information 1672 Traceroute measurement information are not considered highly 1673 sensitive. Still, they may contain sensitive information on network 1674 paths, routing states, use IP addresses, and roundtrip times, that 1675 the operator a networks may want to detect for business or security 1676 reasons. 1678 It is thus important to control access to Information acquired by 1679 conducting traceroute measurements, particularly when transmitting it 1680 over a networks but also when storing it. It is RECOMMENDED that 1681 transmission of traceroute measurement information over a network 1682 uses appropriate protection mechanisms for preserving privacy, 1683 integrity and authenticity. It is further RECOMMENDED that secure 1684 authentication and authorization are used for protecting stored 1685 traceroute measurement information. 1687 9. IANA Considerations 1689 This document uses URNs to describe an XML namespace and an XML 1690 schema for traceroute measurements information storing and 1691 transmission conforming to a registry mechanism described in 1692 [RFC3688]. Two URI assignments are requested. 1694 1. Registration request for the IPPM traceroute measurements 1695 namespace 1696 * URI: urn:ietf:params:xml:ns:traceroute-1.0 1697 * Registrant Contact: IESG 1698 * XML: None. Namespace URIs do not represent an XML 1699 2. Registration request for the IPPM traceroute measurements schema 1700 * URI: urn:ietf:params:xml:schema:traceroute-1.0 1701 * Registrant Contact: IESG 1702 * XML: See the section Section 7 of this document. 1704 10. References 1706 10.1. Normative References 1708 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1709 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1710 STD 58, RFC 2579, April 1999. 1712 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1713 MIB", RFC 2863, June 2000. 1715 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1716 Schoenwaelder, "Textual Conventions for Internet Network 1717 Addresses", RFC 4001, February 2005. 1719 [RFC4560] Quittek, J. and K. White, "Definitions of Managed Objects 1720 for Remote Ping, Traceroute, and Lookup Operations", 1721 RFC 4560, June 2006. 1723 10.2. Informative References 1725 [I-D.ietf-ipfix-architecture] 1726 Sadasivan, G., "Architecture for IP Flow Information 1727 Export", draft-ietf-ipfix-architecture-12 (work in 1728 progress), September 2006. 1730 [I-D.ietf-ipfix-info] 1731 Quittek, J., "Information Model for IP Flow Information 1732 Export", draft-ietf-ipfix-info-15 (work in progress), 1733 February 2007. 1735 [I-D.ietf-ipfix-protocol] 1736 Claise, B., "Specification of the IPFIX Protocol for the 1737 Exchange of IP Traffic Flow Information", 1738 draft-ietf-ipfix-protocol-26 (work in progress), 1739 September 2007. 1741 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1742 RFC 1812, June 1995. 1744 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1745 "Definition of the Differentiated Services Field (DS 1746 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1747 December 1998. 1749 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1750 Schoenwaelder, Ed., "Structure of Management Information 1751 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1753 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1754 "Introduction and Applicability Statements for Internet- 1755 Standard Management Framework", RFC 3410, December 2002. 1757 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 1758 Management Protocol (SNMP)", STD 62, RFC 3417, 1759 December 2002. 1761 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1762 January 2004. 1764 [XML] Yergeau et al., F., "Extensible Markup Language (XML) 1.0 1765 (Third Edition)", W3C Recommendation, February 2004. 1767 Appendix A. Traceroute Default Configuration Parameters 1769 This section lists traceroute measurement configuration parameters as 1770 well as their defaults on various platforms and illustrates how 1771 widely they may vary. This document considered four major traceroute 1772 tool implementations and compared them based on configurable 1773 parameters and default values. The LINUX (SUSE 9.1), BSD (FreeBSD 1774 7.0) and UNIX (SunOS 5.9) implementations are based on UDP datagrams, 1775 while the WINDOWS (XP SP2) one uses ICMP Echos. The comparison is 1776 summarized in the following table, where an N/A in the option column, 1777 means that such parameter is not configurable for the specific 1778 implementation. A comprehensive comparison of available 1779 implementations is outside the scope of this document; however, 1780 already by sampling a few different implementations, it can be 1781 observed that they can differ quite significantly in terms of 1782 configurable parameters and also default values. Note that in the 1783 following table only those options which are available in at least 1784 two of the considered implementations are reported. 1786 +---------------------------------------------------------+ 1787 | OS |Option| Description | Default | 1788 +--------+------+-------------------------------+---------+ 1789 | LINUX | -m |Specify the maximum TTL used | 30 | 1790 |--------+------|in traceroute probes. |---------| 1791 | FreeBSD| -m | | OS var | 1792 |--------+------| |---------| 1793 | UNIX | -m | | 30 | 1794 |--------+------| |---------| 1795 | WINDOWS| -h | | 30 | 1796 +--------+------+-------------------------------+---------+ 1797 | LINUX | -n |Display hop addresses | - | 1798 |--------+------|numerically rather than |---------| 1799 | FreeBSD| -n |symbolically. | - | 1800 |--------+------| |---------| 1801 | UNIX | -n | | - | 1802 |--------+------| |---------| 1803 | WINDOWS| -d | | - | 1804 +--------+------+-------------------------------+---------+ 1805 | LINUX | -w |Set the time to wait for a | 3 sec | 1806 |--------+------|response to a probe. |---------| 1807 | FreeBSD| -w | | 5 sec | 1808 |--------+------| |---------| 1809 | UNIX | -w | | 5 sec | 1810 |--------+------| |---------| 1811 | WINDOWS| -w | | 4 sec | 1812 +--------+------+-------------------------------+---------+ 1813 | LINUX | N/A |Specify a loose source route | - | 1814 |--------+------|gateway (to direct the |---------| 1815 | FreeBSD| -g |traceroute probes through | - | 1816 |--------+------|routers not necessarily in |---------| 1817 | UNIX | -g | the path). | - | 1818 |--------+------| |---------| 1819 | WINDOWS| -g | | - | 1820 +--------+------+-------------------------------+---------+ 1821 | LINUX | -p |Set the base UDP port number | 33434 | 1822 |------- +------|used in traceroute probes |---------| 1823 | FreeBSD| -p |(UDP port = base + nhops - 1). | 33434 | 1824 |--------+------| |---------| 1825 | UNIX | -p | | 33434 | 1826 |--------+------| |---------| 1827 | WINDOWS| N/A | | - | 1828 +--------+------+-------------------------------+---------+ 1829 | LINUX | -q |Set the number of probes per | 3 | 1830 |--------+------|TTL. |---------| 1831 | FreeBSD| -q | | 3 | 1832 |--------+------| |---------| 1833 | UNIX | -q | | 3 | 1834 |--------+------| |---------| 1835 | WINDOWS| N/A | | 3 | 1836 +--------+------+-------------------------------+---------+ 1837 | LINUX | -S |Set the IP source address in |IP | 1838 |--------+------|outgoing probes to the |address | 1839 | FreeBSD| -s |specified value. |of the | 1840 |--------+------| |out | 1841 | UNIX | -s | |interface| 1842 |--------+------| | | 1843 | WINDOWS| N/A | | | 1844 +--------+------+-------------------------------+---------+ 1845 | LINUX | -t |Set the type-of-service (TOS) | 0 | 1846 |--------+------|in the probes to the specified |---------| 1847 | FreeBSD| -t |value. | 0 | 1848 |--------+------| |---------| 1849 | UNIX | -t | | 0 | 1850 |--------+------| |---------| 1851 | WINDOWS| N/A | | 0 | 1852 +--------+------+-------------------------------+---------+ 1853 | LINUX | -v |Verbose output: received ICMP | - | 1854 |--------+------|packets other than |---------| 1855 | FreeBSD| -v |TIME_EXCEEDED and | - | 1856 |--------+------|UNREACHABLE are listed. |---------| 1857 | UNIX | -v | | - | 1858 |--------+------| |---------| 1859 | WINDOWS| N/A | | - | 1860 +--------+------+-------------------------------+---------+ 1861 | LINUX | N/A |Set the time (in msec) to | - | 1862 |--------+------|pause between probes. |---------| 1863 | FreeBSD| -z | | 0 | 1864 |--------+------| |---------| 1865 | UNIX | -P | | 0 | 1866 |--------+------| |---------| 1867 | WINDOWS| N/A | | - | 1868 +--------+------+-------------------------------+---------+ 1869 | LINUX | -r |Bypass the normal routing | - | 1870 |--------+------|tables and send directly to a |---------| 1871 | FreeBSD| -r |host on attached network. | - | 1872 |--------+------| |---------| 1873 | UNIX | -r | | - | 1874 |--------+------| |---------| 1875 | WINDOWS| N/A | | - | 1876 +--------+------+-------------------------------+---------+ 1877 | LINUX | -f |Set the initial TTL for the | 1 | 1878 |--------+------|first probe. |---------| 1879 | FreeBSD| -f | | 1 | 1880 |--------+------| |---------| 1881 | UNIX | -f | | 1 | 1882 |--------+------| |---------| 1883 | WINDOWS| N/A | | 1 | 1884 +--------+------+-------------------------------+---------+ 1885 | LINUX | -F |Set the "don't fragment" bit. | - | 1886 |--------+------| |---------| 1887 | FreeBSD| -F | | - | 1888 |--------+------| |---------| 1889 | UNIX | -F | | - | 1890 |--------+------| |---------| 1891 | WINDOWS| N/A | | - | 1892 +--------+------+-------------------------------+---------+ 1893 | LINUX | N/A |Enables socket level debugging.| - | 1894 |--------+------| |---------| 1895 | FreeBSD| -d | | - | 1896 |--------+------| |---------| 1897 | UNIX | -d | | - | 1898 |--------+------| |---------| 1899 | WINDOWS| N/A | | - | 1900 +--------+------+-------------------------------+---------+ 1901 | LINUX | N/A |Use ICMP ECHO instead of UDP | - | 1902 |--------+------|datagrams. |---------| 1903 | FreeBSD| -I | | - | 1904 |--------+------| |---------| 1905 | UNIX | -I | | - | 1906 |--------+------| |---------| 1907 | WINDOWS| N/A | | - | 1908 +--------+------+-------------------------------+---------+ 1909 | LINUX | -I |Specify a network interface to | - | 1910 |--------+------|obtain the IP address for |---------| 1911 | FreeBSD| -i |outgoing IP packets | - | 1912 |--------+------|(alternative to option -s). |---------| 1913 | UNIX | -i | | - | 1914 |--------+------| |---------| 1915 | WINDOWS| N/A | | - | 1916 +--------+------+-------------------------------+---------+ 1917 | LINUX | N/A |Toggle checksum. | - | 1918 |--------+------| |---------| 1919 | FreeBSD| -x | | - | 1920 |--------+------| |---------| 1921 | UNIX | -x | | - | 1922 |--------+------| |---------| 1923 | WINDOWS| N/A | | - | 1924 +--------+------+-------------------------------+---------+ 1925 | LINUX | - |As optional last parameter, |Depends | 1926 |--------+------|LINUX, FreeBSD and UNIX |on | 1927 | FreeBSD| - |implementations allow |implement| 1928 |--------+------|specifying the probe datagram |ation. | 1929 | UNIX | - |length for outgoing probes. | | 1930 |--------+------| | | 1931 | WINDOWS| N/A | | | 1932 +--------+------+-------------------------------+---------+ 1934 A.1. Alternative Traceroute Implementations 1936 As stated above, the widespread use of firewalls might prevent UDP or 1937 ICMP based traceroutes to completely trace the path to a destination, 1938 since traceroute probes might end up being filtered. In some cases, 1939 such limitation might be overcome by sending instead TCP packets to 1940 specific ports that hosts located behind the firewall are listening 1941 for connections on. TCP based implementations use TCP SYN or FIN 1942 probes and listen for TIME_EXCEEDED messages, TCP RESET and other 1943 messages from firewalls and gateways on the path. On the other hand, 1944 some firewalls filter out TCP SYN packets to prevent denial of 1945 service attacks, therefore the actual advantage of using TCP instead 1946 of UDP traceroute depends mainly on firewall configurations, which 1947 are not known in advance. A detailed analysis of TCP-based 1948 traceroute tools and measurements was outside the scope of this 1949 document, anyway for completeness reasons the information model 1950 supports the storing of TCP-based traceroute measurements, too. 1952 Appendix B. Known Problems with Traceroute 1954 B.1. Compatibility between traceroute measurements results and IPPM 1955 metrics 1957 Because of implementation choices, a known inconsistency exists 1958 between the round-trip delay metric defined by the IPPM working group 1959 in RFC 2681 and the results returned by the current traceroute tool 1960 implementations. Unfortunately, it is unlikely that the traceroute 1961 tool implementations will implement the standard definition in the 1962 near future. The only possibility is therefore to compare results of 1963 different traceroute measurements one with each other; in order to do 1964 this, specifications both of the operating system (name and version) 1965 and of the traceroute tool version used were added to the metadata 1966 elements in order to help in comparing metrics between two different 1967 traceroute measurements results (if run using the same operating 1968 system and the same version of the tool). Moreover, the traceroute 1969 tool has built-in configurable mechanisms like time-outs and can 1970 experience problems related to the crossing of firewalls; therefore 1971 some of the packets that traceroute sends out end up being time-out 1972 or filtered. As a consequence, it might not be possible to trace the 1973 path to a node or there might not be a complete set of probes 1974 describing the RTT to reach it. 1976 Appendix C. Differences to DISMAN-TRACEROUTE-MIB 1978 For performing remote traceroute operations at managed node, the IETF 1979 has standardized the DISMAN-TRACEROUTE-MIB module in [RFC4560]. This 1980 module allows: 1982 o retrieving capability information of the traceroute tool 1983 implementation at the managed node, 1984 o configuring traceroute measurements to be performed, 1985 o retrieving information about ongoing and completed traceroute 1986 measurements, 1987 o retrieving traceroute measurement statistics. 1989 The traceroute storage format described in this document has 1990 significant overlaps with this MIB module. Particularly, the models 1991 for the traceroute measurement configuration and for the result from 1992 completed measurements are almost identical. But for other pats of 1993 the DISMAN-TRACEROUTE MIB module there is no need to model them in a 1994 traceroute measurements storage format. Particularly, the capability 1995 information, information about ongoing measurements and measurement 1996 statistics are not covered by the DISMAN traceroute storage model. 1998 Concerning traceroute measurements and their results, there are 1999 structural differences between the two models caused by the different 2000 choices for the encoding of the specification. For DISMAN- 2001 TRACEROUTE-MIB, the Structure of Management Information (SMIv2, STD 2002 58, RFC 2578 [RFC2578]) was used, while the IPPM traceroute 2003 measurements data model is encoded using XML. 2005 This difference in structure implies that the DISMAN-TRACEROUTE-MIB 2006 module contains SMI-specific information element (managed objects) 2007 that concern tables of managed objects (specification, entry creation 2008 and deletion, status retrieval) that are not required for the XML- 2009 encoded traceroute measurements data model. 2011 But for most of the remaining information elements that concern 2012 configuration of traceroute measurements and results of completed 2013 measurements, the semantics is identical between the DISMAN- 2014 TRACEROUTE-MIB module and the traceroute measurements data model. 2015 There are very few exceptions to this which are listed below. Also 2016 naming of information elements is identical between both models with 2017 a few exceptions. For the traceroute measurements data model, a few 2018 information elements have been added, some because of the different 2019 structure and some to provide additional information on completed 2020 measurements. 2022 C.1. Naming 2024 Basically, names in both models are chosen using the same naming 2025 conventions. 2027 For the traceroute measurement configuration information all names, 2028 such as CtlProbesPerHop, are identical in both models except for the 2029 traceRoute prefix that was removed to avoid unnecessary redundancy in 2030 the XML file and for CtlDataSize which was renamed to 2031 CtlProbeDataSize for clarification in the traceroute measurements 2032 data model. 2034 Results of measurements in the DISMAN-TRACEROUTE-MIB modules are 2035 distributed over two tables, the traceRouteResultsTable containing 2036 mainly information about ongoing measurements and the 2037 traceRouteProbeHistoryTable containing only information about 2038 completed measurements. According to the SMIv2 naming conventions 2039 names of information elements in these tables have different prefixes 2040 (traceRouteResults and traceRouteProbeHistory). Since the traceroute 2041 measurements data model only reports on completed measurements, this 2042 separation is not needed anymore and the prefix "Results" is used for 2043 all related information elements. 2045 Beyond that, there are only a few changes in element names. The 2046 renaming actions include: 2048 o traceRouteProbeHistoryProbeIndex to IndexPerHop, 2049 o traceRouteProbeHistoryResponse to RoundTripTime, 2050 o traceRouteProbeHistoryTime to ResultsEndDateAndTime, 2051 o traceRouteProbeHistoryLastRC to ResultsHopRawOutputData. 2053 C.2. Semantics 2055 The semantics was changed for two information elements only. 2057 For traceRouteProbeHistoryResponse in the DISMAN-TRACEROUTE-MIB, a 2058 value of 0 indicated, that it was not possible to transmit a probe. 2059 For the traceroute measurements data model, a value of 0 for element 2060 RoundTripTime indicates that the measured time was less than one 2061 millisecond, while for the case that it was not possible to transmit 2062 a probe a string is used that indicates the problem. 2064 For traceRouteCtlIfIndex in the DISMAN-TRACEROUTE-MIB, a value of 0 2065 indicated, that it the option to set the index is not available. 2066 This was translated to the traceroute measurements data model, such 2067 that a value of 0 for this element indicates that the used interface 2068 is unknown. 2070 The element traceRouteProbeHistoryLastRC in the DISMAN-TRACEROUTE-MIB 2071 was replaced by element ResultsHopRawOutputData. While 2072 traceRouteProbeHistoryLastRC just reports a reply code, 2073 ResultsHopRawOutputData reports the full raw output data produced by 2074 the traceroute measurements that was used. 2076 C.3. Additional Information Elements 2078 Only a few information elements have been added to the model of the 2079 DISMAN-TRACEROUTE-MIB module. 2081 o For providing geographical information about hops in the 2082 traceroute measurement path, HopGeoLocation was added. 2083 o For providing the top MPLS label stack entry of a probe in the 2084 traceroute measurement path MPLSTopLabel was added. 2085 o For providing additional timestamp beyond ResultsEndDateAndTime, 2086 ResultsStartDateAndTime and Time were added. 2088 Authors' Addresses 2090 Saverio Niccolini 2091 Network Laboratories, NEC Europe Ltd. 2092 Kurfuersten-Anlage 36 2093 Heidelberg 69115 2094 Germany 2096 Phone: +49 (0) 6221 4342 118 2097 Email: saverio.niccolini@netlab.nec.de 2098 URI: http://www.netlab.nec.de 2100 Sandra Tartarelli 2101 Network Laboratories, NEC Europe Ltd. 2102 Kurfuersten-Anlage 36 2103 Heidelberg 69115 2104 Germany 2106 Phone: +49 (0) 6221 4342 132 2107 Email: sandra.tartarelli@netlab.nec.de 2108 URI: http://www.netlab.nec.de 2109 Juergen Quittek 2110 Network Laboratories, NEC Europe Ltd. 2111 Kurfuersten-Anlage 36 2112 Heidelberg 69115 2113 Germany 2115 Phone: +49 (0) 6221 4342 115 2116 Email: quittek@netlab.nec.de 2117 URI: http://www.netlab.nec.de 2119 Martin Swany 2120 Dept. of Computer and Information Sciences, University of Delaware 2121 Newark DE 19716 2122 U.S.A. 2124 Email: swany@UDel.Edu 2126 Full Copyright Statement 2128 Copyright (C) The IETF Trust (2007). 2130 This document is subject to the rights, licenses and restrictions 2131 contained in BCP 78, and except as set forth therein, the authors 2132 retain all their rights. 2134 This document and the information contained herein are provided on an 2135 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2136 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2137 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2138 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2139 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2140 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2142 Intellectual Property 2144 The IETF takes no position regarding the validity or scope of any 2145 Intellectual Property Rights or other rights that might be claimed to 2146 pertain to the implementation or use of the technology described in 2147 this document or the extent to which any license under such rights 2148 might or might not be available; nor does it represent that it has 2149 made any independent effort to identify any such rights. Information 2150 on the procedures with respect to rights in RFC documents can be 2151 found in BCP 78 and BCP 79. 2153 Copies of IPR disclosures made to the IETF Secretariat and any 2154 assurances of licenses to be made available, or the result of an 2155 attempt made to obtain a general license or permission for the use of 2156 such proprietary rights by implementers or users of this 2157 specification can be obtained from the IETF on-line IPR repository at 2158 http://www.ietf.org/ipr. 2160 The IETF invites any interested party to bring to its attention any 2161 copyrights, patents or patent applications, or other proprietary 2162 rights that may cover technology that may be required to implement 2163 this standard. Please address the information to the IETF at 2164 ietf-ipr@ietf.org. 2166 Acknowledgment 2168 Funding for the RFC Editor function is provided by the IETF 2169 Administrative Support Activity (IASA).