idnits 2.17.1 draft-ietf-ippm-storetraceroutes-01.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 on line 2061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2079. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2085. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 506: '... octets. If the RECOMMENDED tracerout...' RFC 2119 keyword, line 1070: '... RECOMMENDED traceroute method...' RFC 2119 keyword, line 1891: '...ement parameters MUST be carefully sel...' RFC 2119 keyword, line 1904: '... methodologies SHOULD include approp...' RFC 2119 keyword, line 1920: '...en storing it. It is RECOMMENDED that...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 257 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 (August 30, 2006) is 6442 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '1-9' is mentioned on line 949, but not defined == Missing Reference: '0-9' is mentioned on line 950, but not defined == Missing Reference: '0-4' is mentioned on line 950, but not defined == Missing Reference: '0-5' is mentioned on line 950, but not defined == Unused Reference: 'I-D.ietf-disman-remops-mib-v2' is defined on line 1951, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-ipfix-architecture-11 == Outdated reference: A later version (-15) exists of draft-ietf-ipfix-info-12 == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-22 Summary: 4 errors (**), 0 flaws (~~), 10 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: Informational J. Quittek 5 Expires: March 3, 2007 NEC 6 M. Swany 7 UDel 8 August 30, 2006 10 Traceroute Measurements Information Model and XML Data Model 11 draft-ietf-ippm-storetraceroutes-01 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 March 3, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This memo describes a standard way to store traceroute measurements. 45 To better address the traceroute measurements storing issue, the 46 authors first of all give a definition of the traceroute tool, 47 describe the tool itself as well as its parameters and the default 48 values on the most common operating systems and the output results 49 that can be stored. Afterwards, the common information model with 50 the base elements of the traceroute measurement storing is defined 51 dividing the information elements in two semantically separated 52 groups (configuration elements and results ones). Moreover an 53 additional element is defined to relate configuration elements and 54 results ones by means of a common unique identifier. On the basis of 55 the information model a data model is then proposed in order to 56 actually store the traceroute measurements. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Definition of Traceroute . . . . . . . . . . . . . . . . . . . 3 62 2.1. Traceroute Configuration Parameters . . . . . . . . . . . 4 63 3. Known Problems with Traceroute . . . . . . . . . . . . . . . . 8 64 3.1. Accuracy of Results . . . . . . . . . . . . . . . . . . . 8 65 3.2. Alternative traceroute Implementations . . . . . . . . . . 8 66 4. Reports/results . . . . . . . . . . . . . . . . . . . . . . . 8 67 5. Information Model for Storing Traceroute Measurements . . . . 9 68 5.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.2. Information Elements . . . . . . . . . . . . . . . . . . . 10 70 5.2.1. Configuration Information Elements . . . . . . . . . . 10 71 5.2.2. Results Information Elements . . . . . . . . . . . . . 15 72 5.2.3. Information Element Correlating Configuration and 73 Results Elements . . . . . . . . . . . . . . . . . . . 18 74 6. Data Model for Storing Traceroute Measurements . . . . . . . . 19 75 7. XML Schema for traceroute Measurements . . . . . . . . . . . . 20 76 8. Differences to DISMAN-TRACEROUTE-MIB . . . . . . . . . . . . . 38 77 8.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 39 78 8.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 39 79 8.3. Additional Information Elements . . . . . . . . . . . . . 40 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 81 9.1. Conducting Traceroute Measurements . . . . . . . . . . . . 40 82 9.2. Securing Traceroute Measurement Results . . . . . . . . . 41 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 42 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 42 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 88 Intellectual Property and Copyright Statements . . . . . . . . . . 45 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 traceroute measurements are stored and the 96 related metrics associated with such measurements. Since traceroute 97 is a tool that has built-in configurable mechanisms like time-outs 98 and can experience problems related to the crossing of firewalls thus 99 experiencing fake losses or incomplete delay information. The 100 standard metrics defined by IPPM working group in matter of delay, 101 connectivity and losses do not apply to the metrics returned by the 102 traceroute tool; therefore, in order to compare results of traceroute 103 measurements, the solution is to add to the stored results a 104 specification of the operating system and version for the tool used. 105 Moreover there is a need to better define the traceroute tool as well 106 as its parameters and the results it outputs since, to the authors' 107 knowledge, there is so far no standard describing these. These are 108 the motivations that moved the authors to write this draft in the 109 context of the IPPM working group even if other working groups (like 110 DISMAN) have already addressed similar issues related to the 111 definition of the MIB for configuring and retrieving traceroute 112 measurements results. This draft, in order to store traceroute 113 results and allow comparison of them, defines a standard way to store 114 traceroute measurements using a XML schema. The draft is organised 115 as follows: Section 2 gives the definition of traceroute used as 116 reference in the rest of the draft as well as the traceroute 117 configurable parameters and their default values for the most common 118 operating systems. Section 3 reports on both traceroute accuracy of 119 results and existing alternatives for traceroute implementations. 120 Section 4 describes the results available from the traceroute output 121 screen. Section 5 and Section 6 respectively describe our proposed 122 Information model and Data model for storing traceroute measurements. 123 Section 8 reports the differences to [RFC4560]. The draft ends with 124 security considerations and IANA considerations in Section 9 and 125 Section 10 respectively. 127 2. Definition of Traceroute 129 Traceroute is a network diagnostic tool used to determine the hop by 130 hop path from a source to a destination and the Round Trip Time (RTT) 131 from the source to each hop. Traceroute can therefore be used to 132 discover where and how a host is connected to the Internet and can be 133 usefully employed to troubleshoot network connections. 135 Typically, traceroute attemps to discover the path to a destination 136 by sending UDP probes with specific time-to-live (TTL) values in the 137 IP packet header and trying to elicit an ICMP TIME_EXCEEDED response 138 from each gateway along the path to some host. 140 More in detail, the host running the traceroute sends the first set 141 of probes with TTL equal to one (some implementations allow setting 142 the initial TTL to a value equal to "n" different from one, so that 143 the first "n-1" hops are skipped and the first hop that will be 144 traced is the "n-th" in the path). Upon receiving a probe, the first 145 hop host decreases the TTL value by one. By observing a TTL value 146 equal to zero, the host rejects the probe and typically returns an 147 ICMP message with a TIME_EXCEEDED value. Traceroute can therefore 148 derive the IP address of the first hop from the header of the ICMP 149 message and evaluate the RTT between the source and the first hop. 150 The next hops are discovered following the same procedure, taking 151 care of increasing at each step the TTL value of the outgoing probes 152 by one. The TTL value is increased until either an ICMP 153 PORT_UNREACHABLE message is received, meaning that the destination 154 has been reached, or the maximum configured number of hops has been 155 hit. 157 Some implementations, use ICMP Echos, instead of UDP datagrams. 158 However, many routers do not return ICMP messages about ICMP 159 messages, i.e. no ICMP TIME_EXCEEDED is returned for an ICMP Echo. 160 Therefore, in this draft we RECOMMEND to base implementations on UDP 161 datagrams. 163 2.1. Traceroute Configuration Parameters 165 In order to define an information model for storing traceroutes, we 166 first investigated which configuration parameters are relevant when 167 running traceroute. We considered four major traceroute 168 implementations and compared them based on configurable parameters 169 and default values. The LINUX (SUSE 9.1), BSD (FreeBSD 7.0) and UNIX 170 (SunOS 5.9) implemetations are based on UDP datagrams, while the 171 WINDOWS (XP SP2) one uses ICMP Echos. The comparison is summarized 172 in the following table, where an N/A in the option column, means that 173 such parameter is not configurable for the specific implementation. 174 A comprehensive comparison of available implementations is outside 175 the scope of this draft; however, already by sampling a few different 176 implementations, we can observe that they can differ quite 177 significantly in terms of configurable parameters and also default 178 values. Note that in the following table we reported only those 179 options which are available in at least two of the considered 180 implementations. 182 +---------------------------------------------------------+ 183 | OS |Option| Description | Default | 184 +--------+------+-------------------------------+---------+ 185 | LINUX | -m |Specify the maximum TTL used | 30 | 186 |--------+------|in outgoing probes. |---------| 187 | FreeBSD| -m | | OS var | 188 |--------+------| |---------| 189 | UNIX | -m | | 30 | 190 |--------+------| |---------| 191 | WINDOWS| -h | | 30 | 192 +--------+------+-------------------------------+---------+ 193 | LINUX | -n |Display hop addresses | - | 194 |--------+------|numerically rather than |---------| 195 | FreeBSD| -n |simbolically. | - | 196 |--------+------| |---------| 197 | UNIX | -n | | - | 198 |--------+------| |---------| 199 | WINDOWS| -d | | - | 200 +--------+------+-------------------------------+---------+ 201 | LINUX | -w |Set the time to wait for a | 3 sec | 202 |--------+------|response to a probe. |---------| 203 | FreeBSD| -w | | 5 sec | 204 |--------+------| |---------| 205 | UNIX | -w | | 5 sec | 206 |--------+------| |---------| 207 | WINDOWS| -w | | 4 sec | 208 +--------+------+-------------------------------+---------+ 209 | LINUX | N/A |Specify a loose source route | - | 210 |--------+------|gateway (to direct the |---------| 211 | FreeBSD| -g |traceroute through routers not | - | 212 |--------+------|necessarily in the path). |---------| 213 | UNIX | -g | | - | 214 |--------+------| |---------| 215 | WINDOWS| -g | | - | 216 +--------+------+-------------------------------+---------+ 217 | LINUX | -p |Set the base UDP port number | 33434 | 218 |------- +------|used in probes |---------| 219 | FreeBSD| -p |(UDP port = base + nhops - 1). | 33434 | 220 |--------+------| |---------| 221 | UNIX | -p | | 33434 | 222 |--------+------| |---------| 223 | WINDOWS| N/A | | - | 224 +--------+------+-------------------------------+---------+ 225 | LINUX | -q |Set the number of probes per | 3 | 226 |--------+------|TTL. |---------| 227 | FreeBSD| -q | | 3 | 228 |--------+------| |---------| 229 | UNIX | -q | | 3 | 230 |--------+------| |---------| 231 | WINDOWS| N/A | | 3 | 232 +--------+------+-------------------------------+---------+ 233 | LINUX | -S |Set the IP source address in |IP | 234 |--------+------|outgoing probes to the |address | 235 | FreeBSD| -s |specified value. |of the | 236 |--------+------| |out | 237 | UNIX | -s | |interface| 238 |--------+------| | | 239 | WINDOWS| N/A | | | 240 +--------+------+-------------------------------+---------+ 241 | LINUX | -t |Set the type-of-service (TOS) | 0 | 242 |--------+------|in the probes to the specified |---------| 243 | FreeBSD| -t |value. | 0 | 244 |--------+------| |---------| 245 | UNIX | -t | | 0 | 246 |--------+------| |---------| 247 | WINDOWS| N/A | | 0 | 248 +--------+------+-------------------------------+---------+ 249 | LINUX | -v |Verbose output: received ICMP | - | 250 |--------+------|packets other than |---------| 251 | FreeBSD| -v |TIME_EXCEEDED and | - | 252 |--------+------|UNREACHABLE are listed. |---------| 253 | UNIX | -v | | - | 254 |--------+------| |---------| 255 | WINDOWS| N/A | | - | 256 +--------+------+-------------------------------+---------+ 257 | LINUX | N/A |Set the time (in msec) to | - | 258 |--------+------|pause between probes. |---------| 259 | FreeBSD| -z | | 0 | 260 |--------+------| |---------| 261 | UNIX | -P | | 0 | 262 |--------+------| |---------| 263 | WINDOWS| N/A | | - | 264 +--------+------+-------------------------------+---------+ 265 | LINUX | -r |Bypass the normal routing | - | 266 |--------+------|tables and send directly to a |---------| 267 | FreeBSD| -r |host on attached network. | - | 268 |--------+------| |---------| 269 | UNIX | -r | | - | 270 |--------+------| |---------| 271 | WINDOWS| N/A | | - | 272 +--------+------+-------------------------------+---------+ 273 | LINUX | -f |Set the initial TTL for the | 1 | 274 |--------+------|first probe. |---------| 275 | FreeBSD| -f | | 1 | 276 |--------+------| |---------| 277 | UNIX | -f | | 1 | 278 |--------+------| |---------| 279 | WINDOWS| N/A | | 1 | 280 +--------+------+-------------------------------+---------+ 281 | LINUX | -F |Set the "don't fragment" bit. | - | 282 |--------+------| |---------| 283 | FreeBSD| -F | | - | 284 |--------+------| |---------| 285 | UNIX | -F | | - | 286 |--------+------| |---------| 287 | WINDOWS| N/A | | - | 288 +--------+------+-------------------------------+---------+ 289 | LINUX | N/A |Enables socket level debugging.| - | 290 |--------+------| |---------| 291 | FreeBSD| -d | | - | 292 |--------+------| |---------| 293 | UNIX | -d | | - | 294 |--------+------| |---------| 295 | WINDOWS| N/A | | - | 296 +--------+------+-------------------------------+---------+ 297 | LINUX | N/A |Use ICMP ECHO instead of UDP | - | 298 |--------+------|datagrams. |---------| 299 | FreeBSD| -I | | - | 300 |--------+------| |---------| 301 | UNIX | -I | | - | 302 |--------+------| |---------| 303 | WINDOWS| N/A | | - | 304 +--------+------+-------------------------------+---------+ 305 | LINUX | -I |Specify a network interface to | - | 306 |--------+------|obtain the IP address for |---------| 307 | FreeBSD| -i |outgoing IP packets | - | 308 |--------+------|(alternative to option -s). |---------| 309 | UNIX | -i | | - | 310 |--------+------| |---------| 311 | WINDOWS| N/A | | - | 312 +--------+------+-------------------------------+---------+ 313 | LINUX | N/A |Toggle checksum. | - | 314 |--------+------| |---------| 315 | FreeBSD| -x | | - | 316 |--------+------| |---------| 317 | UNIX | -x | | - | 318 |--------+------| |---------| 319 | WINDOWS| N/A | | - | 320 +--------+------+-------------------------------+---------+ 321 | LINUX | - |As optional last paramater, |Depends | 322 |--------+------|LINUX, FreeBSD and UNIX |on | 323 | FreeBSD| - |implementations allow |implement| 324 |--------+------|specifying the probe datagram |ation. | 325 | UNIX | - |length for outgoing probes. | | 326 |--------+------| | | 327 | WINDOWS| N/A | | | 328 +--------+------+-------------------------------+---------+ 330 3. Known Problems with Traceroute 332 3.1. Accuracy of Results 334 A known inconsistency exists between the round-trip delay metric 335 defined by the IPPM working group and the results returned by the 336 current traceroute implementations. Unfortunately, it is unlikely 337 that the traceroute implementations will implement the standard 338 definition in the near future. In order to compare results of 339 different traceroute measurements, specifications both of the 340 operating system (name and version) and of the traceroute tool 341 version used are added to the metadata elements in order to help in 342 comparing metrics. Moreover, the traceroute has built-in 343 configurable mechanisms like time-outs and can experience problems 344 related to the crossing of firewalls; therefore some of the packets 345 that traceroute sends out end up being time-out or filtered. As a 346 consequence, it might not be possible to trace the path to a node or 347 there might not be a complete set of probes describing the RTT to 348 reach it. 350 3.2. Alternative traceroute Implementations 352 As stated above, the widespred use of firewalls might prevent UDP or 353 ICMP based traceroutes to completely trace the path to a destination, 354 since traceroute probes might end up being filtered. In some cases, 355 such limitation might be overcome by sending instead TCP packets to 356 specific ports that hosts located behind the firewall are listening 357 for connections on. TCP based implementations use TCP SYN or FYN 358 probes and listen for TIME_EXCEEDED messages, TCP RESET and other 359 messages from firewalls and gateways on the path. On the other hand, 360 some firewalls filter out TCP SYN packets to prevent denial of 361 service attacks, therefore the actual advantage of using TCP instead 362 of UDP traceroute depends mainly on firewall configurations, which 363 are not known in adavance. A detailed analysis of TCP based 364 traceroutes is outside the scope of this draft, therefore in the 365 sequel, we will restrict our focus to the most commonly implemented 366 UDP based traceroute. 368 4. Reports/results 370 The following list reports the information fields provided by all 371 traceroute implementations considered. The order in which they are 372 reported here is not relevant and it changes in different 373 implementations. For each hop the information reported is: 374 o the hop index; 375 o the host symbolical address, provided that at least one of the 376 probes received a response, the symbolic address could be resolved 377 at the correponding host and that the option to display only 378 numerical addresses was not set; 379 o the host IP address, provided that at least one of the probes 380 received a response; 381 o the RTT for each response to a probe. 382 Depending on the traceroute implementation, additional information 383 might be displayed in the output (for instance MPLS-related 384 information). 386 It might happen that some probes do not receive a response within the 387 configured time-out (for instance if the probe is filtered out by a 388 firewall). In this case, an "*" is displayed in place of the RTT. 389 Besides, for delays below 1 ms, some implementations reports 0 ms 390 (f.i. UNIX and LINUX) while WINDOWS tracert reports "< 1 ms". 392 5. Information Model for Storing Traceroute Measurements 394 This section describes the information model for the traceroute 395 measurements data storing. The information model is composed of 396 information elements; for defining these information elements, a 397 template is used. Such template is specified in the list below: 399 o name - A unique and meaningful name for the information element. 400 The preferred spelling for the name is to use mixed case if the 401 name is compound, with an initial lower case letter, e.g., 402 "sourceIpAddress". 403 o description - The semantics of this information element. 404 o dataType - One of the types listed in Section 5.1 of this document 405 or in an extension of the information model. The type space for 406 attributes is constrained to facilitate implementation. 407 o units - If the element is a measure of some kind, the units 408 identify what the measure is. 409 o default value - The default value for the element (where 410 applicable). 412 5.1. Data Types 414 This section describes the set of valid data types of the information 415 model. 417 o String - The type "String" represents a finite length string of 418 valid characters from the Unicode character encoding set. Unicode 419 allows for ASCII and many other international character sets to be 420 used. It is expected that strings will be encoded in UTF-8 421 format, which is identical in encoding for USASCII characters, but 422 also accomodates other Unicode multibyte characters. 423 o InetAddressType - The type "InetAddressType" represents a type of 424 Internet address. The allowed values are to be intended as 425 imported from [RFC4001]; an additional allowed value is 426 "asnumber". 427 o InetAddress - The type "InetAddress" denotes a generic Internet 428 address. The allowed values are to be intended as imported from 429 [RFC4001]; an additional allowed value is the AS number to be 430 indicated as the actual number plus the indication how the mapping 431 from IP address to AS number was performed. 432 o TruthValue - The type "TruthValue" represents a boolean value. 433 The allowed values are to be intended as imported from [RFC2579]. 434 o Unsigned32 - The type "Unsigned32" represents a value in the range 435 (0..4294967295). 436 o InterfaceIndexOrZero - The type "InterfaceIndexOrZero" is an 437 extension of the InterfaceIndex convention. The latter defines a 438 greater than zero value used to identify an interface or interface 439 sub-layer in the system. This extension permits the additional 440 value of zero. Examples of the usage of zero might include 441 situations where interface was unknown, or when none or all 442 interfaces need to be referenced. The allowed values are to be 443 intended as imported from [RFC2863]. 444 o ProbesType - The type "ProbesType" represents a way of indicating 445 the protocol used for the traceroute probes. Allowed values are 446 UDP, TCP, ICMP. 447 o DateAndTime - The type "DateAndTime" represents a date-time 448 specification. The allowed values are to be intended as imported 449 from [RFC2579] apart from the fact that in this document there is 450 the need to use a milli-second resolution instead a deci-second 451 one. 452 o OperationResponseStatus - The type "OperationResponseStatus" is 453 used to report the result of an operation. The allowed values are 454 to be intended as imported from [RFC4560]. 456 5.2. Information Elements 458 This section describes the elements of the traceroute measurement. 459 The elements are grouped in two groups (Configuration and Results) 460 according to their semantics. In order to relate configuration and 461 results elements by means of a common unique identifier, an 462 additional element is defined belonging to both the two groups. 464 5.2.1. Configuration Information Elements 466 This section describes the elements of the traceroute measurement 467 that are specific to traceroute configuration. 469 5.2.1.1. traceRouteCtlTargetAddressType 471 o name - traceRouteCtlTargetAddressType 472 o description - Specifies the type of host address used in the 473 traceroute command. 474 o dataType - InetAddressType 475 o units - N/A 476 o default value - N/A 478 5.2.1.2. traceRouteCtlTargetAddress 480 o name - traceRouteCtlTargetAddress 481 o description - Specifies the host address used in the traceroute 482 command. The host address type can be determined by the examining 483 the value of the corresponding traceRouteCtlTargetAddressType. 484 o dataType - InetAddress 485 o units - N/A 486 o default value - N/A 488 5.2.1.3. traceRouteCtlByPassRouteTable 490 o name - traceRouteCtlByPassRouteTable 491 o description - Specifies if the optional bypassing of the route 492 table was enabled or not. If enabled, the traceroute will bypass 493 the normal routing tables and send directly to a host on an 494 attached network. If the host is not on a directly-attached 495 network, an error is returned. This option can be used to perform 496 the traceroute operation to a local host through an interface that 497 has no route defined. 498 o dataType - TruthValue 499 o units - N/A 500 o default value - false 502 5.2.1.4. traceRouteCtlProbeDataSize 504 o name - traceRouteCtlProbeDataSize 505 o description - Specifies the size of the data portion of a 506 traceroute operation in octets. If the RECOMMENDED traceroute 507 method (UDP datagrams as probes) is used, then the value contained 508 in this object is exact. If another traceroute method is used for 509 which the specified size is not appropriate, then the 510 implementation should have used whatever size (appropriate to the 511 method) is closest to the specified size. The maximum value for 512 this object was computed by substracting the smallest possible IP 513 header size of 20 octets (IPv4 header with no options) and the UDP 514 header size of 8 octets from the maximum IP packet size. An IP 515 packet has a maximum size of 65535 octets (excluding IPv6 516 Jumbograms). 518 o dataType - Unsigned32 519 o units - octects 520 o default value - 0 522 5.2.1.5. traceRouteCtlTimeOut 524 o name - traceRouteCtlTimeOut 525 o description - Specifies the time-out value, in seconds, for the 526 traceroute operation. 527 o dataType - Unsigned32 528 o units - seconds 529 o default value - 3 531 5.2.1.6. traceRouteCtlProbesPerHop 533 o name - traceRouteCtlProbesPerHop 534 o description - Specifies the number of times to reissue a 535 traceroute request with the same time-to-live (TTL) value. 536 o dataType - Unsigned32 537 o units - probes 538 o default value - 3 540 5.2.1.7. traceRouteCtlPort 542 o name - traceRouteCtlPort 543 o description - Specifies the base UDP port used by the traceroute 544 operation. Need to specify a port that is not in use at the 545 destination (target) host. The default value for this object is 546 the IANA assigned port, 33434, for the traceroute function. 547 o dataType - Unsigned32 548 o units - UDP Port 549 o default value - 33434 551 5.2.1.8. traceRouteCtlMaxTtl 553 o name - traceRouteCtlMaxTtl 554 o description - Specifies the maximum TTL value for the traceroute 555 operation. 556 o dataType - Unsigned32 557 o units - time-to-live value 558 o default value - 30 560 5.2.1.9. traceRouteCtlDSField 562 o name - traceRouteCtlDSField 563 o description - Specifies the value that was stored in the 564 Differentiated Services (DS) field in the IP packet used to 565 encapsulate the traceroute probe. The DS Field is defined as the 566 Type of Service (TOS) octet in a IPv4 header or as the Traffic 567 Class octet in a IPv6 header. The value of this object must be a 568 decimal integer in the range from 0 to 255. This option can be 569 used to determine what effect an explicit DS field setting has on 570 a traceroute response. Not all values are legal or meaningful. 571 Useful TOS octet values are probably '16' (low delay) and '8' 572 (high throughput). Further references can be found in [RFC2474] 573 for the definition of the Differentiated Services (DS) field and 574 to [RFC1812] Section 5.3.2 for Type of Service (TOS). 575 o dataType - Unsigned32 576 o units - N/A 577 o default value - 0 579 5.2.1.10. traceRouteCtlSourceAddressType 581 o name - traceRouteCtlSourceAddressType 582 o description - Specifies the type of the source address, 583 traceRouteCtlSourceAddress, used when performing the traceroute 584 operation. 585 o dataType - InetAddressType 586 o units - N/A 587 o default value - N/A 589 5.2.1.11. traceRouteCtlSourceAddress 591 o name - traceRouteCtlSourceAddress 592 o description - Specifies the IP address (which has to be given as 593 an IP number, not a hostname) as the source address used in 594 outgoing probe packets. On hosts with more than one IP address, 595 this option can be used to force the source address to be 596 something other than the primary IP address of the interface the 597 probe packet is sent on. A zero length octet string value for 598 this object means that source address specification was disabled. 599 The address type (InetAddressType) that relates to this object is 600 specified by the corresponding value of 601 traceRouteCtlSourceAddressType. 602 o dataType - InetAddress 603 o units - N/A 604 o default value - N/A 606 5.2.1.12. traceRouteCtlIfIndex 608 o name - traceRouteCtlIfIndex 609 o description - Specifies the inferface index used in the traceroute 610 operation for sending the traceroute probes. A value of zero for 611 this object implies that the interface was unknown. 613 o dataType - InterfaceIndexOrZero 614 o units - N/A 615 o default value - 0 617 5.2.1.13. traceRouteCtlMiscOptions 619 o name - traceRouteCtlMiscOptions 620 o description - Specifies implementation dependent options. 621 o dataType - String 622 o units - N/A 623 o default value - N/A 625 5.2.1.14. traceRouteCtlMaxFailures 627 o name - traceRouteCtlMaxFailures 628 o description - Specifies the maximum number of consecutive timeouts 629 allowed before terminating a traceroute operation. A value of 630 either 255 (maximum hop count/possible TTL value) or a 0 indicates 631 that the function of terminating a remote traceroute operation 632 when a specific number of consecutive timeouts are detected was 633 disabled. This element is included to give full compatibility 634 with [RFC4560]. No known implementation of traceroute currently 635 supports it. 636 o dataType - Unsigned32 637 o units - timeouts 638 o default value - 5 640 5.2.1.15. traceRouteCtlDontFragment 642 o name - traceRouteCtlDontFragment 643 o description - Specifies if the don't fragment flag (DF) in the IP 644 header for a probe was enabled or not. Setting the DF flag can be 645 used for performing a manual PATH MTU test. 646 o dataType - TruthValue 647 o units - N/A 648 o default value - false 650 5.2.1.16. traceRouteCtlInitialTtl 652 o name - traceRouteCtlInitialTtl 653 o description - Specifies the initial TTL value used in a traceroute 654 operation. Such TTL setting is intended to bypass the initial 655 (often well known) portion of a path. 656 o dataType - Unsigned32 657 o units - N/A 658 o default value - 1 660 5.2.1.17. traceRouteCtlDescr 662 o name - traceRouteCtlDescr 663 o description - The purpose of this element is to provide a 664 description of the traceroute test. 665 o dataType - String 666 o units - N/A 667 o default value - N/A 669 5.2.1.18. traceRouteCtlType 671 o name - traceRouteCtlType 672 o description - Specifies the implementation method used for the 673 traceroute operation. It specifies if the traceroute is using 674 TCP, UDP or ICMP probes. 675 o dataType - ProbesType 676 o units - N/A 677 o default value - UDP 679 5.2.2. Results Information Elements 681 This section describes the elements of the traceroute measurement 682 that are specific to the results of a traceroute operation. 684 5.2.2.1. traceRouteResultsStartDateAndTime 686 o name - traceRouteResultsStartDateAndTime 687 o description - Specifies the date and start time of the traceroute 688 operation. This is the time when the first probe was seen at the 689 sending interface. 690 o dataType - DateAndTime 691 o units - N/A 692 o default value - N/A 694 5.2.2.2. traceRouteResultsIpTgtAddrType 696 o name - traceRouteResultsIpTgtAddrType 697 o description - Specifies the type of address stored in the 698 corresponding traceRouteResultsIpTgtAddr element. 699 o dataType - InetAddressType 700 o units - N/A 701 o default value - N/A 703 5.2.2.3. traceRouteResultsIpTgtAddr 705 o name - traceRouteResultsIpTgtAddr 706 o description - Specifies the IP address associated with a 707 traceRouteCtlTargetAddress value when the destination address is 708 specified as a DNS name. The value of this object should be a 709 zero length octet string when a DNS name is not specified or when 710 a specified DNS name fails to resolve. 711 o dataType - InetAddress 712 o units - N/A 713 o default value - N/A 715 5.2.2.4. traceRouteResultsProbeIndex 717 o name - traceRouteResultsProbeIndex 718 o description - Specifies the progressive index of a probe within 719 the traceroute operation. The maximum value here is the number 720 resulting from the operation 721 traceRouteCtlMaxTtl*traceRouteCtlProbesPerHop. 722 o dataType - Unsigned32 723 o units - N/A 724 o default value - N/A 726 5.2.2.5. traceRouteResultsProbeHopIndex 728 o name - traceRouteResultsProbeHopIndex 729 o description - Specifies which hop in a traceroute path that the 730 probe's results are for. 731 o dataType - Unsigned32 732 o units - N/A 733 o default value - N/A 735 5.2.2.6. traceRouteResultsProbeIndexPerHop 737 o name - traceRouteResultsProbeIndexPerHop 738 o description - Specifies the index of a probe for a particular hop 739 in a traceroute path. The number of probes per hop is determined 740 by the value of the corresponding traceRouteCtlProbesPerHop 741 element. 742 o dataType - Unsigned32 743 o units - N/A 744 o default value - N/A 746 5.2.2.7. traceRouteResultsProbeHopAddrType 748 o name - traceRouteResultsProbeHopAddrType 749 o description - Specifies the type of address stored in the 750 corresponding traceRouteResultsProbeHopAddr element. 751 o dataType - InetAddressType 752 o units - N/A 753 o default value - N/A 755 5.2.2.8. traceRouteResultsProbeHopAddr 757 o name - traceRouteResultsProbeHopAddr 758 o description - Specifies the address of a hop in the traceroute 759 path. This object is not allowed to be a DNS name. The value of 760 the corresponding object, traceRouteResultsProbeHopAddrType, 761 indicates this object's IP address type. 762 o dataType - InetAddress 763 o units - N/A 764 o default value - N/A 766 5.2.2.9. traceRouteResultsProbeHopGeoLocation 768 o name - traceRouteResultsProbeHopGeoLocation 769 o description - Specifies the geo location of a hop in the 770 traceroute path. 771 o dataType - String 772 o units - N/A 773 o default value - N/A 775 5.2.2.10. traceRouteResultsProbeMPLSLabelStack 777 o name - traceRouteResultsProbeMPLSLabelStack 778 o description - Specifies the MPLS label stack of a probe in the 779 traceroute path. This object contains the "label stack entries" 780 Label, Exp and S as a single 24 bit number. 781 o dataType - Unsigned32 782 o units - N/A 783 o default value - N/A 785 5.2.2.11. traceRouteResultsProbeRoundTripTime 787 o name - traceRouteResultsProbeRoundTripTime 788 o description - Specifies the amount of time measured in 789 milliseconds from when a probe was sent to when its response was 790 received or when it timed out. The value of this element is 791 reported as the truncation of the number reported by the 792 traceroute tool (the output "< 1 ms" is therefore encoded as 0 793 ms). A string with the value of "RoundTripTimeNotAvailable" means 794 either the probe was lost because of a timeout or it was not 795 possible to transmit a probe. 796 o dataType - Unsigned32 or String 797 o units - milliseconds or N/A 798 o default value - N/A 800 5.2.2.12. traceRouteResultsProbeResponseStatus 802 o name - traceRouteResultsProbeResponseStatus 803 o description - Specifies the result of a traceroute operation made 804 by the host for a particular probe. 805 o dataType - OperationResponseStatus 806 o units - N/A 807 o default value - N/A 809 5.2.2.13. traceRouteResultsProbeTime 811 o name - traceRouteResultsProbeTime 812 o description - Specifies the timestamp for when the response to the 813 probe was received interface. 814 o dataType - DateAndTime 815 o units - N/A 816 o default value - N/A 818 5.2.2.14. traceRouteResultsHopRawOutputData 820 o name - traceRouteResultsHopRawOutputData 821 o description - Specifies the raw output data returned by the 822 traceroute operation for a certain hop in a traceroute path. 823 o dataType - String 824 o units - N/A 825 o default value - N/A 827 5.2.2.15. traceRouteResultsEndDateAndTime 829 o name - traceRouteResultsEndDateAndTime 830 o description - Specifies the date and end time of the traceroute 831 operation. It is either the time when the response to the last 832 probe of the traceroute operation was received or the time when 833 the last probe of the traceroute operation was sent plus the 834 relative timeout (in case of missing response). 835 o dataType - DateAndTime 836 o units - N/A 837 o default value - N/A 839 5.2.3. Information Element Correlating Configuration and Results 840 Elements 842 This section defines an additional element belonging to both the two 843 previous groups. This element is defined in order to relate 844 configuration elements and results ones by means of a common unique 845 identifier. 847 5.2.3.1. traceRouteTestName 849 o name - traceRouteTestName 850 o description - Specifies the name of a traceroute test. This is 851 locally unique. 852 o dataType - String 853 o units - N/A 854 o default value - N/A 856 6. Data Model for Storing Traceroute Measurements 858 For storing and transmitting information according to the information 859 model defined in the previous section, a data model is required that 860 specifies how to encode the elements of the information model. 862 There are several design choices for a data model. It can use a 863 binary or textual representation and it can be defined from scratch 864 or use already existing frameworks and data models. In general, the 865 use of already existing frameworks and models should be preferred. 867 Binary and textual representation both have advantages and 868 disadvantages. Textual representions are (with some limitations) 869 human readable while a binary representation consumes less resources 870 for storing, transmitting and parsing data. 872 An already existing and closely related data model is the DISMAN- 873 TRACEROUTE-MIB module [RFC4560], that specifies a BER encoding 874 [RFC3417] used by the Simple Network Management Protocol (SNMP) 875 [RFC3410] for transmitting traceroute information. This data model 876 is well suited and supported within network management systems, but 877 as a general format for storing and transmitting traceroute results 878 it is not easily applicable. 880 Another binary representation would be an extension of traffic flow 881 information encodings as specified for the IPFIX protocol 882 [I-D.ietf-ipfix-protocol], [I-D.ietf-ipfix-info]. The IPFIX protocol 883 is extensible. However, the architecture behind this protocol 884 [I-D.ietf-ipfix-architecture] is targeted at exporting passively 885 measured flow information. Therefore, some obstacles are expected 886 when trying to use it for transmitting traceroute measurement 887 results. 889 For textual representations, using the eXtensible Markup Language 890 (XML) [XML] is an obvious choice. XML supports clean structuring of 891 data and syntax checking of records. With some limitations it is 892 human readable. It is supported well by a huge pool of tools and 893 standards for generating, transmitting, parsing and converting it to 894 other data formats. Its disadvantages is the resource comsumption 895 for processing, storing, and transmitting information. Since the 896 expected data volumes of traceroute data in network operation and 897 maintenance is not expected to be extremly high, the inefficient 898 usage of resources is not a significant disadvantage. Therefore, XML 899 was chosen as basis for the traceroute information model that is 900 specified in this section. 902 Section 7 contains the XML schema to be used as a template for 903 storing and/or exchanging traceroute measurements. The schema was 904 designed in order to use an extensible approach based on templates 905 (pretty similar to how IPFIX protocol is designed) where the 906 traceroute configuration elements (both the requested parameters, 907 traceRouteRequest, and the actual parameters used, 908 traceRouteMeasurementMetadata) are metadata to be referenced by 909 results information elements (data) by means of the 910 traceRouteTestName element (used as unique identifier). Currently 911 Global Grid Forum (GGF) is also using this approach and cross- 912 requirements have been analyzed as well as standardization 913 opportunities of a joint work. 915 7. XML Schema for traceroute Measurements 917 918 921 922 923 924 925 926 927 928 929 931 932 933 934 935 936 937 938 939 940 941 942 943 944 946 947 948 951 952 954 955 956 958 959 961 962 963 964 965 967 968 969 971 972 973 974 975 976 977 978 979 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 997 998 999 1001 1002 1003 1004 1005 1007 1008 1009 Specifies the name of a traceroute 1010 test. This is locally unique. 1011 1012 1013 1014 1015 1016 1018 1019 1020 Specifies the name of the operating 1021 system on which the traceroute was launched. 1022 1023 1024 1025 1026 1027 1029 1030 1031 Specifies the OS version on which the 1032 traceroute was launched. 1033 1034 1035 1036 1037 1038 1040 1041 1042 Specifies the version of the traceroute 1043 tool used. 1044 1045 1046 1047 1048 1049 1051 1052 1053 Specifies if the optional bypassing 1054 of the route table was enabled or not. If enabled, 1055 the traceroute will bypass the normal routing tables 1056 and send directly to a host on an attached network. 1057 If the host is not on a directly-attached network, 1058 an error is returned. This option can be used to 1059 perform the traceroute operation to a local host 1060 through an interface that has no route defined. 1061 1062 1063 1064 1066 1067 1068 Specifies the size of the data 1069 portion of a traceroute operation in octets. If the 1070 RECOMMENDED traceroute method (UDP datagrams as probes) 1071 is used, then the value contained in this object is 1072 exact. If another traceroute method is used for which 1073 the specified size is not appropriate, then the 1074 implementation should have used whatever size (appropriate 1075 to the method) is closest to the specified size. 1076 The maximum value for this object was computed by 1077 substracting the smallest possible IP header size of 20 1078 octets (IPv4 header with no options) and the UDP header 1079 size of 8 octets from the maximum IP packet size. An IP 1080 packet has a maximum size of 65535 octets (excluding IPv6 1081 jumbograms). Units are: octects. 1082 1083 1084 1085 1086 1087 1089 1090 1091 Specifies the time-out value, in 1092 seconds, for the traceroute operation. 1093 Units are: seconds. 1094 1095 1096 1097 1098 1099 1100 1102 1103 1104 Specifies the number of times to 1105 reissue a traceroute request with the same time-to-live 1106 (TTL) value. Units are: probes. 1107 1108 1109 1110 1111 1112 1113 1115 1116 1117 Specifies the base UDP port used by 1118 the traceroute operation. Need to specify a port that 1119 is not in use at the destination (target) host. 1120 The default value for this object is the IANA assigned 1121 port, 33434, for the traceroute function. 1122 Units are: UDP port. 1123 1124 1125 1126 1127 1128 1130 1131 1132 Specifies the maximum TTL value for 1133 the traceroute operation. 1134 Units are: time-to-live value. 1135 1136 1137 1138 1139 1140 1142 1143 1144 Specifies the value that was stored in 1145 the Differentiated Services (DS) field in the IP packet 1146 used to encapsulate the traceroute probe. The DS Field 1147 is defined as the Type of Service (TOS) octet in a IPv4 1148 header or as the Traffic Class octet in a IPv6 header. 1149 The value of this object must be a decimal integer in the 1150 range from 0 to 255. This option can be used to determine 1151 what effect an explicit DS field setting has on a 1152 traceroute response. Not all values are legal or 1153 meaningful. Useful TOS octet values are probably 1154 '16' (low delay) and '8' (high throughput). 1155 Further references can be found in the 1156 RFC 2474 for the definition of the Differentiated 1157 Services (DS) field and to the RFC 1812 Section 5.3.2 1158 for Type of Service (TOS). 1159 1160 1161 1162 1164 1165 1166 Specifies the inferface index used in the 1167 traceroute operation for sending the traceroute 1168 probes. A value of zero for this object implies 1169 that the interface was unknown. 1170 1171 1172 1173 1175 1176 1177 Specifies implementation dependent 1178 options. 1179 1180 1181 1182 1183 1185 1186 1187 Specifies the maximum number of 1188 consecutive timeouts allowed before terminating a 1189 traceroute operation. A value of either 255 1190 (maximum hop count/possible TTL value) or a 0 indicates 1191 that the function of terminating a remote traceroute 1192 operation when a specific number of consecutive 1193 timeouts are detected was disabled. This element is 1194 included to give full compatibility with DISMAN working 1195 group documents. No known implementation of traceroute 1196 currently supports it. 1197 Units are: timeouts. 1198 1199 1200 1201 1203 1204 1205 Specifies if the don't fragment flag 1206 (DF) in the IP header for a probe was enabled or not. 1207 Setting the DF flag can be used for performing 1208 a manual PATH MTU test. 1209 1210 1211 1212 1214 1215 1216 Specifies the initial TTL value 1217 used in a traceroute operation. Such 1218 TTL setting is intended to bypass the initial 1219 (often well known) portion of a path. 1220 1221 1222 1223 1224 1225 1227 1228 1229 The purpose of this element is to 1230 provide a description of the traceroute test. 1231 1232 1233 1234 1235 1236 1238 1239 1240 Specifies the implementation method 1241 used for the traceroute operation. It specifies if 1242 the traceroute is using TCP, UDP or ICMP probes. 1243 1244 1245 1246 1247 1248 1249 1250 1252 1253 1254 Specifies the progressive index of 1255 a probe within the traceroute operation. The maximum 1256 value here is the number resulting from the operation 1257 traceRouteCtlMaxTtl*traceRouteCtlProbesPerHop. 1258 1259 1260 1261 1262 1263 1264 1266 1267 1268 Specifies which hop in a traceroute 1269 path that the probe's results are for. The value of 1270 this element is initially determined by the value of 1271 traceRouteCtlInitialTtl. 1272 1273 1274 1275 1277 1278 1280 1281 1282 Specifies the index of a probe for 1283 a particular hop in a traceroute path. The number of 1284 probes per hop is determined by the value of the 1285 corresponding traceRouteCtlProbesPerHop element. 1286 1287 1288 1289 1290 1291 1292 1294 1295 1296 Specifies the geo location of a hop 1297 in the traceroute path. 1298 1299 1300 1301 1302 1303 1305 1306 1307 Specifies the MPLS label stack of a 1308 probe in the traceroute path. This object contains the 1309 "label stack entries" Label, Exp and S as a single 1310 24 bit number. 1311 1312 1313 1314 1315 1316 1318 1319 1320 1321 1322 1324 1325 1326 1327 1328 1330 1331 1332 Specifies the raw output data returned 1333 by the traceroute operation for a certain hop in a 1334 traceroute path. 1335 1336 1337 1338 1339 1340 1342 1343 1344 Specifies the AS number of a hop in the 1345 traceroute path as a 24 bit number and the indication how 1346 the mapping from IP address to AS number was performed. 1347 1348 1349 1351 1353 1354 1356 1357 1358 1360 1362 1364 1366 1368 1369 1371 1372 1373 1375 1377 1379 1381 1383 1384 1386 1387 1388 1390 1392 1393 1395 1396 1397 Specifies the type of host address 1398 used in the traceroute command. 1399 1400 1401 1402 1404 1405 1407 1408 1409 Specifies the host address used in 1410 the traceroute command. The host address type can be 1411 determined by the examining the value of the 1412 corresponding traceRouteCtlTargetAddressType. 1413 1414 1415 1416 1417 1418 1420 1421 1422 Specifies the type of the source address, 1423 traceRouteCtlSourceAddress, used when performing the 1424 traceroute operation. 1425 1426 1427 1428 1430 1431 1433 1434 1435 Specifies the IP address (which has 1436 to be given as an IP number, not a hostname) as the 1437 source address used in outgoing probe packets. On hosts 1438 with more than one IP address, this option can be used 1439 to force the source address to be something other than 1440 the primary IP address of the interface the probe packet 1441 is sent on. A zero length octet string value for this 1442 object means that source addres specification was disabled. 1443 The address type (InetAddressType) that relates to this 1444 object is specified by the corresponding value of 1445 traceRouteCtlSourceAddressType. 1446 1447 1448 1449 1451 1452 1454 1455 1456 Specifies the date and start time of the 1457 traceroute operation. This is the time when the first probe 1458 was sent. 1459 1460 1461 1462 1463 1464 1466 1467 1468 Specifies the type of address stored 1469 in the corresponding traceRouteResultsIpTgtAddr element. 1470 1471 1472 1473 1475 1476 1478 1479 1480 Specifies the IP address associated 1481 with a traceRouteCtlTargetAddress value when the 1482 destination address is specified as a DNS name. 1483 The value of this object should be a zero length octet 1484 string when a DNS name is not specified or when a 1485 specified DNS name fails to resolve. 1486 1487 1488 1489 1491 1492 1494 1495 1496 Specifies the type of address stored 1497 in the corresponding traceRouteResultsProbeHopAddr 1498 element. 1499 1500 1501 1502 1504 1505 1507 1508 1509 Specifies the address of a hop in 1510 the traceroute path. This object is not allowed to 1511 be a DNS name. The value of the corresponding object, 1512 traceRouteResultsProbeHopAddrType, indicates this 1513 object's IP address type. 1514 1515 1516 1517 1519 1520 1522 1523 1524 Specifies the amount of time measured 1525 in milliseconds from when a probe was sent to when its 1526 response was received or when it timed out. The value 1527 of this element is reported as the truncation of the 1528 number reported by the traceroute tool (the output 1529 "<1 ms" is therefore encoded as 0 ms). 1530 A string with the value of "RoundTripTimeNotAvailable" 1531 means either the probe was lost because of a timeout 1532 or it was not possible to transmit a probe. 1533 Units are: milliseconds. 1534 1535 1536 1537 1539 1541 1542 1544 1545 1546 Specifies the result of a traceroute 1547 operation made by the host for a particular probe. 1548 1549 1550 1551 1553 1554 1556 1557 1558 Specifies the timestamp when the 1559 response to the probe was received. 1560 1561 1562 1563 1564 1566 1568 1569 1570 1572 1574 1576 1578 1580 1583 1586 1588 1590 1592 1593 1595 1596 1597 Specifies the date and end time of 1598 the traceroute operation. It is either the time when 1599 the response to the last probe of the traceroute 1600 operation was received or the time when the last 1601 probe of the traceroute operation was sent plus the 1602 relative timeout (in case of missing response). 1603 1604 1605 1606 1607 1608 1610 1611 1612 Specifies the metadata for a 1613 traceroute operation. In a request, these are the 1614 requested parameters. In a response, they are the 1615 actual parameters used. 1616 1617 1618 1619 1621 1624 1627 1630 1632 1634 1638 1641 1644 1647 1650 1653 1656 1658 1660 1663 1666 1669 1672 1675 1678 1682 1683 1685 1686 1687 1688 Contains the actual traceroute measurement. 1689 1690 1691 1692 1694 1696 1698 1700 1703 1706 1708 1709 1710 1711 1712 1713 1715 1716 1717 1719 1720 1721 1723 1724 1725 1727 1729 1730 1731 1733 1735 1736 1737 1739 1741 1742 1743 1745 1747 1749 1750 1751 1753 1754 1756 1758 8. Differences to DISMAN-TRACEROUTE-MIB 1760 For performing remote traceroute operations at managed node, the IETF 1761 has standardized the DISMAN-TRACEROUTE-MIB module in RFC 4560 1762 [RFC4560]. This module allows: 1764 o retrieving capability information of the traceroute implementation 1765 at the managed node, 1766 o configuring traceroute operations to be prformed, 1767 o retrieving information about ongoing and completed traceroute 1768 measurements, 1769 o retrieving traceroute measurement statistics. 1771 The traceroute storage format described in this document has 1772 significant overlaps with this MIB module. Particularly, the models 1773 for the traceroute measurement configuration and for the result from 1774 completed measurements are almost identical. But for other pats of 1775 the DISMAN-TRACEROUTE MIB module there is no need to model them in a 1776 traceroute storage format. Particularly, the capability information, 1777 information about ongoing measurements and measurement statistics are 1778 not covered by the traceroute storage model. 1780 Concerning traceroute measurements and results, there are structural 1781 differences between the two models caused by the different choices 1782 for the encoding of the specification. For DISMAN-TRACEROUTE-MIB, 1783 the Structure of Management Information (SMIv2, STD 58, RFC 2578 1784 [RFC2578]) was used, while for the traceroute storage format is 1785 encoded using XML. 1787 This difference in structure implies that the DISMAN-TRACEROUTE-MIB 1788 module contains SMI-specific information element (managed objects) 1789 that concern tables of managed objects (specification, entry creation 1790 and delection, status retrieval) that are not required for the XML- 1791 encoded traceroute storage format. 1793 But for most of the remaining information elements that concern 1794 configuration of traceroute measurements and results of completed 1795 measurements, the semantics is identical between the DISMAN- 1796 TRACEROUTE-MIB module and the traceroute storage format. There are 1797 very few exceptions to this which are listed below. Also naming of 1798 information elements is identical between both models with a few 1799 exceptions. For the traceroute storage model, a few information 1800 elements have been added, some because of the different structure and 1801 some to provide additional information on completed measurements. 1803 8.1. Naming 1805 Basically, names in both models are chosen using the same naming 1806 conventions. 1808 For the traceroute measurement configuration information all names, 1809 such as traceRouteCtlProbesPerHop, are identical in both models, 1810 except for traceRouteCtlDataSize which was renamed to 1811 traceRouteCtlProbeDataSize for clarification in the traceroute 1812 storage model. 1814 Results of measurements in the DISMAN-TRACEROUTE-MIB modules are 1815 distributed over two tables, the traceRouteResultsTable containing 1816 mainly information about ongoing measurements and the 1817 traceRouteProbeHistoryTable containing only information about 1818 completed measurements. According to the SMIv2 naming conventions 1819 names of information elements in these tables have different prefixes 1820 (traceRouteResults and traceRouteProbeHistory). since the traceroute 1821 storage format only reports on completed measurements, this 1822 separation is not needed anymore and the prefix "traceRouteResults" 1823 is used for all related information elelments. 1825 Beyond that, there are only a few changes in element names. The 1826 renaming actions include: 1828 o traceRouteProbeHistoryProbeIndex to 1829 traceRouteResultsProbeIndexPerHop, 1830 o traceRouteProbeHistoryResponse to 1831 traceRouteResultsProbeRoundTripTime, 1832 o traceRouteProbeHistoryTime to traceRouteResultsEndDateAndTime, 1833 o traceRouteProbeHistoryLastRC to traceRouteResultsHopRawOutputData. 1835 8.2. Semantics 1837 The semantics was changed for two information elements only. 1839 For traceRouteProbeHistoryResponse in the DISMAN-TRACEROUTE-MIB, a 1840 value of 0 indicated, that it was not possible to transmit a probe. 1841 For the traceroute strorage format, a value of 0 for element 1842 traceRouteResultsProbeRoundTripTime indicates that the measured time 1843 was less than one millisecond, while for the case that it was not 1844 possible to transmit a probe a string is used that indicates the 1845 problem. 1847 For traceRouteCtlIfIndex in the DISMAN-TRACEROUTE-MIB, a value of 0 1848 indicated, that it the option to set the index is not available. 1849 This was translated to the traceroute strorage format, such that a 1850 value of 0 for this element indicates that the used interface is 1851 unknown. 1853 The element traceRouteProbeHistoryLastRC in the DISMAN-TRACEROUTE-MIB 1854 was replaced by element traceRouteResultsHopRawOutputData. While 1855 traceRouteProbeHistoryLastRC just reports a reply code, 1856 traceRouteResultsHopRawOutputData reports the full raw output data 1857 produced by the traceroute instance that was used. 1859 8.3. Additional Information Elements 1861 Only a few information elements have been added to the model of the 1862 DISMAN-TRACEROUTE-MIB module. 1864 o For providing geographical information about hops in the 1865 traceroute path, traceRouteResultsProbeHopGeoLocation was added. 1866 o For providing the complete MPLS label stack of a probe in the 1867 traceroute path traceRouteResultsProbeMPLSLabelStack was added. 1868 o For providing additional timestamp beyond 1869 traceRouteResultsEndDateAndTime, traceRouteResultsStartDateAndTime 1870 and traceRouteResultsProbeTime were added. 1872 9. Security Considerations 1874 Security considerations in this section discuss are grouped into 1875 considerartions related to conducting traceroute measurements and 1876 considerations related to storing and transmitting results of 1877 measurements. 1879 This memo does not specify an implementation of a traceroute 1880 measurements. Neither does it specify a certain procedure for 1881 storing traceroute measurement results. Still it is considered 1882 desirable to discuss related security issues below. 1884 9.1. Conducting Traceroute Measurements 1886 Conducting Internet measurements can raise both security and privacy 1887 concerns. Traceroute measurements, in which traffic is injected into 1888 the network, can be abused for denial-of-service attacks disguised as 1889 legitimate measurement activity. 1891 Measurement parameters MUST be carefully selected so that the 1892 measurements inject trivial amounts of additional traffic into the 1893 networks they measure. If they inject "too much" traffic, they can 1894 skew the results of the measurement, and in extreme cases cause 1895 congestion and denial of service. 1897 The measurements themselves could be harmed by routers giving 1898 measurement traffic a different priority than "normal" traffic, or by 1899 an attacker injecting artificial measurement traffic. If routers can 1900 recognize measurement traffic and treat it separately, the 1901 measurements will not reflect actual user traffic. If an attacker 1902 injects artificial traffic that is accepted as legitimate, the loss 1903 rate will be artificially lowered. Therefore, the measurement 1904 methodologies SHOULD include appropriate techniques to reduce the 1905 probability measurement traffic can be distinguished from "normal" 1906 traffic. 1908 Authentication techniques, such as digital signatures, may be used 1909 where appropriate to guard against injected traffic attacks. 1911 9.2. Securing Traceroute Measurement Results 1913 Traceroute results are not considered highly sensible. Still, they 1914 may contain sensible information on network paths, routing states, 1915 use IP addresses, and roundtrip times, that the operator a networks 1916 may want to detect for business or security reasons. 1918 It is thus important to control access to Information acquired by 1919 conducting traceroute measurement, particularly when transmitting it 1920 over a networks but also when storing it. It is RECOMMENDED that 1921 transmission of traceroute measurement results over a network uses 1922 appropriate protection mechanisms for preserving privacy, integrity 1923 and authenticity. It is further RECOMMENDED that secure 1924 authentication and authorization are used for protecting stored 1925 traceroute results. 1927 10. IANA Considerations 1929 This document uses URNs to describe an XML namespace and an XML 1930 schema for traceroute measurements conforming to a registry mechanism 1931 described in [RFC3688]. Two URI assignments are requested. 1932 1. Registration request for the IPPM traceroute measurements 1933 namespace 1934 * URI: urn:ietf:params:xml:ns:traceroute-1.0 1935 * Registrant Contact: TBD. 1936 * XML: None. Namespace URIs do not represent an XML 1937 2. Registration request for the IPPM traceroute measurements schema 1938 * URI: urn:ietf:params:xml:schema:traceroute-1.0 1939 * Registrant Contact: TBD. 1940 * XML: See the section Section 7 of this document. 1942 11. References 1943 11.1. Normative References 1945 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1946 Schoenwaelder, "Textual Conventions for Internet Network 1947 Addresses", RFC 4001, February 2005. 1949 11.2. Informative References 1951 [I-D.ietf-disman-remops-mib-v2] 1952 Quittek, J. and K. White, "Definitions of Managed Objects 1953 for Remote Ping, Traceroute, and Lookup Operations", 1954 draft-ietf-disman-remops-mib-v2-09 (work in progress), 1955 February 2006. 1957 [I-D.ietf-ipfix-architecture] 1958 Sadasivan, G., "Architecture for IP Flow Information 1959 Export", draft-ietf-ipfix-architecture-11 (work in 1960 progress), June 2006. 1962 [I-D.ietf-ipfix-info] 1963 Quittek, J., "Information Model for IP Flow Information 1964 Export", draft-ietf-ipfix-info-12 (work in progress), 1965 June 2006. 1967 [I-D.ietf-ipfix-protocol] 1968 Claise, B., "IPFIX Protocol Specification", 1969 draft-ietf-ipfix-protocol-22 (work in progress), 1970 June 2006. 1972 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1973 RFC 1812, June 1995. 1975 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1976 "Definition of the Differentiated Services Field (DS 1977 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1978 December 1998. 1980 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1981 Schoenwaelder, Ed., "Structure of Management Information 1982 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1984 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1985 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1986 STD 58, RFC 2579, April 1999. 1988 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1989 MIB", RFC 2863, June 2000. 1991 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1992 "Introduction and Applicability Statements for Internet- 1993 Standard Management Framework", RFC 3410, December 2002. 1995 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 1996 Management Protocol (SNMP)", STD 62, RFC 3417, 1997 December 2002. 1999 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2000 January 2004. 2002 [RFC4560] Quittek, J. and K. White, "Definitions of Managed Objects 2003 for Remote Ping, Traceroute, and Lookup Operations", 2004 RFC 4560, June 2006. 2006 [XML] Yergeau et al., F., "Extensible Markup Language (XML) 1.0 2007 (Third Edition)", W3C Recommendation, February 2004. 2009 Authors' Addresses 2011 Saverio Niccolini 2012 Network Laboratories, NEC Europe Ltd. 2013 Kurfuersten-Anlage 36 2014 Heidelberg 69115 2015 Germany 2017 Phone: +49 (0) 6221 4342 118 2018 Email: saverio.niccolini@netlab.nec.de 2019 URI: http://www.netlab.nec.de 2021 Sandra Tartarelli 2022 Network Laboratories, NEC Europe Ltd. 2023 Kurfuersten-Anlage 36 2024 Heidelberg 69115 2025 Germany 2027 Phone: +49 (0) 6221 4342 132 2028 Email: sandra.tartarelli@netlab.nec.de 2029 URI: http://www.netlab.nec.de 2030 Juergen Quittek 2031 Network Laboratories, NEC Europe Ltd. 2032 Kurfuersten-Anlage 36 2033 Heidelberg 69115 2034 Germany 2036 Phone: +49 (0) 6221 4342 115 2037 Email: quittek@netlab.nec.de 2038 URI: http://www.netlab.nec.de 2040 Martin Swany 2041 Dept. of Computer and Information Sciences, University of Delaware 2042 Newark DE 19716 2043 U.S.A. 2045 Email: swany@UDel.Edu 2047 Full Copyright Statement 2049 Copyright (C) The Internet Society (2006). 2051 This document is subject to the rights, licenses and restrictions 2052 contained in BCP 78, and except as set forth therein, the authors 2053 retain all their rights. 2055 This document and the information contained herein are provided on an 2056 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2057 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2058 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2059 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2060 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2061 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2063 Intellectual Property 2065 The IETF takes no position regarding the validity or scope of any 2066 Intellectual Property Rights or other rights that might be claimed to 2067 pertain to the implementation or use of the technology described in 2068 this document or the extent to which any license under such rights 2069 might or might not be available; nor does it represent that it has 2070 made any independent effort to identify any such rights. Information 2071 on the procedures with respect to rights in RFC documents can be 2072 found in BCP 78 and BCP 79. 2074 Copies of IPR disclosures made to the IETF Secretariat and any 2075 assurances of licenses to be made available, or the result of an 2076 attempt made to obtain a general license or permission for the use of 2077 such proprietary rights by implementers or users of this 2078 specification can be obtained from the IETF on-line IPR repository at 2079 http://www.ietf.org/ipr. 2081 The IETF invites any interested party to bring to its attention any 2082 copyrights, patents or patent applications, or other proprietary 2083 rights that may cover technology that may be required to implement 2084 this standard. Please address the information to the IETF at 2085 ietf-ipr@ietf.org. 2087 Acknowledgment 2089 Funding for the RFC Editor function is provided by the IETF 2090 Administrative Support Activity (IASA).