idnits 2.17.1 draft-ietf-ippm-storetraceroutes-02.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 2086. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2097. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2104. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2110. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 261 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 (October 22, 2006) is 6396 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '1-9' is mentioned on line 956, but not defined == Missing Reference: '0-9' is mentioned on line 957, but not defined == Missing Reference: '0-4' is mentioned on line 957, but not defined == Missing Reference: '0-5' is mentioned on line 957, but not defined == Unused Reference: 'RFC2119' is defined on line 1962, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-disman-remops-mib-v2' is defined on line 1971, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-ipfix-info-13 == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-22 Summary: 3 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: April 25, 2007 NEC 6 M. Swany 7 UDel 8 October 22, 2006 10 Traceroute Measurements Information Model and XML Data Model 11 draft-ietf-ippm-storetraceroutes-02 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 April 25, 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 . . . . . . . . . . 11 71 5.2.2. Results Information Elements . . . . . . . . . . . . . 15 72 5.2.3. Information Element Correlating Configuration and 73 Results Elements . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . . 40 79 8.3. Additional Information Elements . . . . . . . . . . . . . 40 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 81 9.1. Conducting Traceroute Measurements . . . . . . . . . . . . 41 82 9.2. Securing Traceroute Measurement Results . . . . . . . . . 41 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119. 131 2. Definition of Traceroute 133 Traceroute is a network diagnostic tool used to determine the hop by 134 hop path from a source to a destination and the Round Trip Time (RTT) 135 from the source to each hop. Traceroute can therefore be used to 136 discover where and how a host is connected to the Internet and can be 137 usefully employed to troubleshoot network connections. 139 Typically, traceroute attemps to discover the path to a destination 140 by sending UDP probes with specific time-to-live (TTL) values in the 141 IP packet header and trying to elicit an ICMP TIME_EXCEEDED response 142 from each gateway along the path to some host. 144 More in detail, the host running the traceroute sends the first set 145 of probes with TTL equal to one (some implementations allow setting 146 the initial TTL to a value equal to "n" different from one, so that 147 the first "n-1" hops are skipped and the first hop that will be 148 traced is the "n-th" in the path). Upon receiving a probe, the first 149 hop host decreases the TTL value by one. By observing a TTL value 150 equal to zero, the host rejects the probe and typically returns an 151 ICMP message with a TIME_EXCEEDED value. Traceroute can therefore 152 derive the IP address of the first hop from the header of the ICMP 153 message and evaluate the RTT between the source and the first hop. 154 The next hops are discovered following the same procedure, taking 155 care of increasing at each step the TTL value of the outgoing probes 156 by one. The TTL value is increased until either an ICMP 157 PORT_UNREACHABLE message is received, meaning that the destination 158 has been reached, or the maximum configured number of hops has been 159 hit. 161 Some implementations, use ICMP Echos, instead of UDP datagrams. 162 However, many routers do not return ICMP messages about ICMP 163 messages, i.e. no ICMP TIME_EXCEEDED is returned for an ICMP Echo. 164 Therefore, in this draft we RECOMMEND to base implementations on UDP 165 datagrams. 167 2.1. Traceroute Configuration Parameters 169 In order to define an information model for storing traceroutes, we 170 first investigated which configuration parameters are relevant when 171 running traceroute. We considered four major traceroute 172 implementations and compared them based on configurable parameters 173 and default values. The LINUX (SUSE 9.1), BSD (FreeBSD 7.0) and UNIX 174 (SunOS 5.9) implemetations are based on UDP datagrams, while the 175 WINDOWS (XP SP2) one uses ICMP Echos. The comparison is summarized 176 in the following table, where an N/A in the option column, means that 177 such parameter is not configurable for the specific implementation. 178 A comprehensive comparison of available implementations is outside 179 the scope of this draft; however, already by sampling a few different 180 implementations, we can observe that they can differ quite 181 significantly in terms of configurable parameters and also default 182 values. Note that in the following table we reported only those 183 options which are available in at least two of the considered 184 implementations. 186 +---------------------------------------------------------+ 187 | OS |Option| Description | Default | 188 +--------+------+-------------------------------+---------+ 189 | LINUX | -m |Specify the maximum TTL used | 30 | 190 |--------+------|in outgoing probes. |---------| 191 | FreeBSD| -m | | OS var | 192 |--------+------| |---------| 193 | UNIX | -m | | 30 | 194 |--------+------| |---------| 195 | WINDOWS| -h | | 30 | 196 +--------+------+-------------------------------+---------+ 197 | LINUX | -n |Display hop addresses | - | 198 |--------+------|numerically rather than |---------| 199 | FreeBSD| -n |simbolically. | - | 200 |--------+------| |---------| 201 | UNIX | -n | | - | 202 |--------+------| |---------| 203 | WINDOWS| -d | | - | 204 +--------+------+-------------------------------+---------+ 205 | LINUX | -w |Set the time to wait for a | 3 sec | 206 |--------+------|response to a probe. |---------| 207 | FreeBSD| -w | | 5 sec | 208 |--------+------| |---------| 209 | UNIX | -w | | 5 sec | 210 |--------+------| |---------| 211 | WINDOWS| -w | | 4 sec | 212 +--------+------+-------------------------------+---------+ 213 | LINUX | N/A |Specify a loose source route | - | 214 |--------+------|gateway (to direct the |---------| 215 | FreeBSD| -g |traceroute through routers not | - | 216 |--------+------|necessarily in the path). |---------| 217 | UNIX | -g | | - | 218 |--------+------| |---------| 219 | WINDOWS| -g | | - | 220 +--------+------+-------------------------------+---------+ 221 | LINUX | -p |Set the base UDP port number | 33434 | 222 |------- +------|used in probes |---------| 223 | FreeBSD| -p |(UDP port = base + nhops - 1). | 33434 | 224 |--------+------| |---------| 225 | UNIX | -p | | 33434 | 226 |--------+------| |---------| 227 | WINDOWS| N/A | | - | 228 +--------+------+-------------------------------+---------+ 229 | LINUX | -q |Set the number of probes per | 3 | 230 |--------+------|TTL. |---------| 231 | FreeBSD| -q | | 3 | 232 |--------+------| |---------| 233 | UNIX | -q | | 3 | 234 |--------+------| |---------| 235 | WINDOWS| N/A | | 3 | 236 +--------+------+-------------------------------+---------+ 237 | LINUX | -S |Set the IP source address in |IP | 238 |--------+------|outgoing probes to the |address | 239 | FreeBSD| -s |specified value. |of the | 240 |--------+------| |out | 241 | UNIX | -s | |interface| 242 |--------+------| | | 243 | WINDOWS| N/A | | | 244 +--------+------+-------------------------------+---------+ 245 | LINUX | -t |Set the type-of-service (TOS) | 0 | 246 |--------+------|in the probes to the specified |---------| 247 | FreeBSD| -t |value. | 0 | 248 |--------+------| |---------| 249 | UNIX | -t | | 0 | 250 |--------+------| |---------| 251 | WINDOWS| N/A | | 0 | 252 +--------+------+-------------------------------+---------+ 253 | LINUX | -v |Verbose output: received ICMP | - | 254 |--------+------|packets other than |---------| 255 | FreeBSD| -v |TIME_EXCEEDED and | - | 256 |--------+------|UNREACHABLE are listed. |---------| 257 | UNIX | -v | | - | 258 |--------+------| |---------| 259 | WINDOWS| N/A | | - | 260 +--------+------+-------------------------------+---------+ 261 | LINUX | N/A |Set the time (in msec) to | - | 262 |--------+------|pause between probes. |---------| 263 | FreeBSD| -z | | 0 | 264 |--------+------| |---------| 265 | UNIX | -P | | 0 | 266 |--------+------| |---------| 267 | WINDOWS| N/A | | - | 268 +--------+------+-------------------------------+---------+ 269 | LINUX | -r |Bypass the normal routing | - | 270 |--------+------|tables and send directly to a |---------| 271 | FreeBSD| -r |host on attached network. | - | 272 |--------+------| |---------| 273 | UNIX | -r | | - | 274 |--------+------| |---------| 275 | WINDOWS| N/A | | - | 276 +--------+------+-------------------------------+---------+ 277 | LINUX | -f |Set the initial TTL for the | 1 | 278 |--------+------|first probe. |---------| 279 | FreeBSD| -f | | 1 | 280 |--------+------| |---------| 281 | UNIX | -f | | 1 | 282 |--------+------| |---------| 283 | WINDOWS| N/A | | 1 | 284 +--------+------+-------------------------------+---------+ 285 | LINUX | -F |Set the "don't fragment" bit. | - | 286 |--------+------| |---------| 287 | FreeBSD| -F | | - | 288 |--------+------| |---------| 289 | UNIX | -F | | - | 290 |--------+------| |---------| 291 | WINDOWS| N/A | | - | 292 +--------+------+-------------------------------+---------+ 293 | LINUX | N/A |Enables socket level debugging.| - | 294 |--------+------| |---------| 295 | FreeBSD| -d | | - | 296 |--------+------| |---------| 297 | UNIX | -d | | - | 298 |--------+------| |---------| 299 | WINDOWS| N/A | | - | 300 +--------+------+-------------------------------+---------+ 301 | LINUX | N/A |Use ICMP ECHO instead of UDP | - | 302 |--------+------|datagrams. |---------| 303 | FreeBSD| -I | | - | 304 |--------+------| |---------| 305 | UNIX | -I | | - | 306 |--------+------| |---------| 307 | WINDOWS| N/A | | - | 308 +--------+------+-------------------------------+---------+ 309 | LINUX | -I |Specify a network interface to | - | 310 |--------+------|obtain the IP address for |---------| 311 | FreeBSD| -i |outgoing IP packets | - | 312 |--------+------|(alternative to option -s). |---------| 313 | UNIX | -i | | - | 314 |--------+------| |---------| 315 | WINDOWS| N/A | | - | 316 +--------+------+-------------------------------+---------+ 317 | LINUX | N/A |Toggle checksum. | - | 318 |--------+------| |---------| 319 | FreeBSD| -x | | - | 320 |--------+------| |---------| 321 | UNIX | -x | | - | 322 |--------+------| |---------| 323 | WINDOWS| N/A | | - | 324 +--------+------+-------------------------------+---------+ 325 | LINUX | - |As optional last paramater, |Depends | 326 |--------+------|LINUX, FreeBSD and UNIX |on | 327 | FreeBSD| - |implementations allow |implement| 328 |--------+------|specifying the probe datagram |ation. | 329 | UNIX | - |length for outgoing probes. | | 330 |--------+------| | | 331 | WINDOWS| N/A | | | 332 +--------+------+-------------------------------+---------+ 334 3. Known Problems with Traceroute 336 3.1. Accuracy of Results 338 A known inconsistency exists between the round-trip delay metric 339 defined by the IPPM working group and the results returned by the 340 current traceroute implementations. Unfortunately, it is unlikely 341 that the traceroute implementations will implement the standard 342 definition in the near future. In order to compare results of 343 different traceroute measurements, specifications both of the 344 operating system (name and version) and of the traceroute tool 345 version used are added to the metadata elements in order to help in 346 comparing metrics. Moreover, the traceroute has built-in 347 configurable mechanisms like time-outs and can experience problems 348 related to the crossing of firewalls; therefore some of the packets 349 that traceroute sends out end up being time-out or filtered. As a 350 consequence, it might not be possible to trace the path to a node or 351 there might not be a complete set of probes describing the RTT to 352 reach it. 354 3.2. Alternative traceroute Implementations 356 As stated above, the widespred use of firewalls might prevent UDP or 357 ICMP based traceroutes to completely trace the path to a destination, 358 since traceroute probes might end up being filtered. In some cases, 359 such limitation might be overcome by sending instead TCP packets to 360 specific ports that hosts located behind the firewall are listening 361 for connections on. TCP based implementations use TCP SYN or FYN 362 probes and listen for TIME_EXCEEDED messages, TCP RESET and other 363 messages from firewalls and gateways on the path. On the other hand, 364 some firewalls filter out TCP SYN packets to prevent denial of 365 service attacks, therefore the actual advantage of using TCP instead 366 of UDP traceroute depends mainly on firewall configurations, which 367 are not known in adavance. A detailed analysis of TCP based 368 traceroutes is outside the scope of this draft, therefore in the 369 sequel, we will restrict our focus to the most commonly implemented 370 UDP based traceroute. 372 4. Reports/results 374 The following list reports the information fields provided by all 375 traceroute implementations considered. The order in which they are 376 reported here is not relevant and it changes in different 377 implementations. For each hop the information reported is: 378 o the hop index; 379 o the host symbolical address, provided that at least one of the 380 probes received a response, the symbolic address could be resolved 381 at the correponding host and that the option to display only 382 numerical addresses was not set; 383 o the host IP address, provided that at least one of the probes 384 received a response; 385 o the RTT for each response to a probe. 386 Depending on the traceroute implementation, additional information 387 might be displayed in the output (for instance MPLS-related 388 information). 390 It might happen that some probes do not receive a response within the 391 configured time-out (for instance if the probe is filtered out by a 392 firewall). In this case, an "*" is displayed in place of the RTT. 393 Besides, for delays below 1 ms, some implementations reports 0 ms 394 (f.i. UNIX and LINUX) while WINDOWS tracert reports "< 1 ms". 396 5. Information Model for Storing Traceroute Measurements 398 This section describes the information model for the traceroute 399 measurements data storing. The information model is composed of 400 information elements; for defining these information elements, a 401 template is used. Such template is specified in the list below: 403 o name - A unique and meaningful name for the information element. 404 The preferred spelling for the name is to use mixed case if the 405 name is compound, with an initial lower case letter, e.g., 406 "sourceIpAddress". 407 o description - The semantics of this information element. 408 o dataType - One of the types listed in Section 5.1 of this document 409 or in an extension of the information model. The type space for 410 attributes is constrained to facilitate implementation. 411 o units - If the element is a measure of some kind, the units 412 identify what the measure is. 413 o default value - The default value for the element (where 414 applicable). 416 5.1. Data Types 418 This section describes the set of valid data types of the information 419 model. 421 o String - The type "String" represents a finite length string of 422 valid characters from the Unicode character encoding set. Unicode 423 allows for ASCII and many other international character sets to be 424 used. It is expected that strings will be encoded in UTF-8 425 format, which is identical in encoding for USASCII characters, but 426 also accomodates other Unicode multibyte characters. 427 o InetAddressType - The type "InetAddressType" represents a type of 428 Internet address. The allowed values are to be intended as 429 imported from [RFC4001]; an additional allowed value is 430 "asnumber". 431 o InetAddress - The type "InetAddress" denotes a generic Internet 432 address. The allowed values are to be intended as imported from 433 [RFC4001]; an additional allowed value is the AS number to be 434 indicated as the actual number plus the indication how the mapping 435 from IP address to AS number was performed. 436 o TruthValue - The type "TruthValue" represents a boolean value. 437 The allowed values are to be intended as imported from [RFC2579]. 438 o Unsigned32 - The type "Unsigned32" represents a value in the range 439 (0..4294967295). 440 o InterfaceIndexOrZero - The type "InterfaceIndexOrZero" is an 441 extension of the InterfaceIndex convention. The latter defines a 442 greater than zero value used to identify an interface or interface 443 sub-layer in the system. This extension permits the additional 444 value of zero. Examples of the usage of zero might include 445 situations where interface was unknown, or when none or all 446 interfaces need to be referenced. The allowed values are to be 447 intended as imported from [RFC2863]. 448 o ProbesType - The type "ProbesType" represents a way of indicating 449 the protocol used for the traceroute probes. Allowed values are 450 UDP, TCP, ICMP. 451 o DateAndTime - The type "DateAndTime" represents a date-time 452 specification. The allowed values are to be intended as imported 453 from [RFC2579] apart from the fact that in this document there is 454 the need to use a milli-second resolution instead a deci-second 455 one. 456 o OperationResponseStatus - The type "OperationResponseStatus" is 457 used to report the result of an operation. The allowed values are 458 to be intended as imported from [RFC4560]. 460 5.2. Information Elements 462 This section describes the elements of the traceroute measurement. 463 The elements are grouped in two groups (Configuration and Results) 464 according to their semantics. In order to relate configuration and 465 results elements by means of a common unique identifier, an 466 additional element is defined belonging to both the two groups. 468 5.2.1. Configuration Information Elements 470 This section describes the elements of the traceroute measurement 471 that are specific to traceroute configuration. 473 5.2.1.1. traceRouteCtlTargetAddressType 475 o name - traceRouteCtlTargetAddressType 476 o description - Specifies the type of host address used in the 477 traceroute command. 478 o dataType - InetAddressType 479 o units - N/A 480 o default value - N/A 482 5.2.1.2. traceRouteCtlTargetAddress 484 o name - traceRouteCtlTargetAddress 485 o description - Specifies the host address used in the traceroute 486 command. The host address type can be determined by the examining 487 the value of the corresponding traceRouteCtlTargetAddressType. 488 o dataType - InetAddress 489 o units - N/A 490 o default value - N/A 492 5.2.1.3. traceRouteCtlByPassRouteTable 494 o name - traceRouteCtlByPassRouteTable 495 o description - Specifies if the optional bypassing of the route 496 table was enabled or not. If enabled, the traceroute will bypass 497 the normal routing tables and send directly to a host on an 498 attached network. If the host is not on a directly-attached 499 network, an error is returned. This option can be used to perform 500 the traceroute operation to a local host through an interface that 501 has no route defined. 502 o dataType - TruthValue 503 o units - N/A 504 o default value - false 506 5.2.1.4. traceRouteCtlProbeDataSize 508 o name - traceRouteCtlProbeDataSize 509 o description - Specifies the size of the data portion of a 510 traceroute operation in octets. If the RECOMMENDED traceroute 511 method (UDP datagrams as probes) is used, then the value contained 512 in this object is exact. If another traceroute method is used for 513 which the specified size is not appropriate, then the 514 implementation should have used whatever size (appropriate to the 515 method) is closest to the specified size. The maximum value for 516 this object was computed by substracting the smallest possible IP 517 header size of 20 octets (IPv4 header with no options) and the UDP 518 header size of 8 octets from the maximum IP packet size. An IP 519 packet has a maximum size of 65535 octets (excluding IPv6 520 Jumbograms). 521 o dataType - Unsigned32 522 o units - octects 523 o default value - 0 525 5.2.1.5. traceRouteCtlTimeOut 527 o name - traceRouteCtlTimeOut 528 o description - Specifies the time-out value, in seconds, for the 529 traceroute operation. 530 o dataType - Unsigned32 531 o units - seconds 532 o default value - 3 534 5.2.1.6. traceRouteCtlProbesPerHop 536 o name - traceRouteCtlProbesPerHop 537 o description - Specifies the number of times to reissue a 538 traceroute request with the same time-to-live (TTL) value. 539 o dataType - Unsigned32 540 o units - probes 541 o default value - 3 543 5.2.1.7. traceRouteCtlPort 545 o name - traceRouteCtlPort 546 o description - Specifies the base UDP port used by the traceroute 547 operation. Need to specify a port that is not in use at the 548 destination (target) host. The default value for this object is 549 the IANA assigned port, 33434, for the traceroute function. 550 o dataType - Unsigned32 551 o units - UDP Port 552 o default value - 33434 554 5.2.1.8. traceRouteCtlMaxTtl 556 o name - traceRouteCtlMaxTtl 557 o description - Specifies the maximum TTL value for the traceroute 558 operation. 559 o dataType - Unsigned32 560 o units - time-to-live value 561 o default value - 30 563 5.2.1.9. traceRouteCtlDSField 565 o name - traceRouteCtlDSField 566 o description - Specifies the value that was stored in the 567 Differentiated Services (DS) field in the IP packet used to 568 encapsulate the traceroute probe. The DS Field is defined as the 569 Type of Service (TOS) octet in a IPv4 header or as the Traffic 570 Class octet in a IPv6 header. The value of this object must be a 571 decimal integer in the range from 0 to 255. This option can be 572 used to determine what effect an explicit DS field setting has on 573 a traceroute response. Not all values are legal or meaningful. 574 Useful TOS octet values are probably '16' (low delay) and '8' 575 (high throughput). Further references can be found in [RFC2474] 576 for the definition of the Differentiated Services (DS) field and 577 to [RFC1812] Section 5.3.2 for Type of Service (TOS). 578 o dataType - Unsigned32 579 o units - N/A 580 o default value - 0 582 5.2.1.10. traceRouteCtlSourceAddressType 584 o name - traceRouteCtlSourceAddressType 585 o description - Specifies the type of the source address, 586 traceRouteCtlSourceAddress, used when performing the traceroute 587 operation. 588 o dataType - InetAddressType 589 o units - N/A 590 o default value - N/A 592 5.2.1.11. traceRouteCtlSourceAddress 594 o name - traceRouteCtlSourceAddress 595 o description - Specifies the IP address (which has to be given as 596 an IP number, not a hostname) as the source address used in 597 outgoing probe packets. On hosts with more than one IP address, 598 this option can be used to force the source address to be 599 something other than the primary IP address of the interface the 600 probe packet is sent on. A zero length octet string value for 601 this object means that source address specification was disabled. 602 The address type (InetAddressType) that relates to this object is 603 specified by the corresponding value of 604 traceRouteCtlSourceAddressType. 605 o dataType - InetAddress 606 o units - N/A 607 o default value - N/A 609 5.2.1.12. traceRouteCtlIfIndex 611 o name - traceRouteCtlIfIndex 612 o description - Specifies the inferface index used in the traceroute 613 operation for sending the traceroute probes. A value of zero for 614 this object implies that the interface was unknown. 615 o dataType - InterfaceIndexOrZero 616 o units - N/A 617 o default value - 0 619 5.2.1.13. traceRouteCtlMiscOptions 621 o name - traceRouteCtlMiscOptions 622 o description - Specifies implementation dependent options. 623 o dataType - String 624 o units - N/A 625 o default value - N/A 627 5.2.1.14. traceRouteCtlMaxFailures 629 o name - traceRouteCtlMaxFailures 630 o description - Specifies the maximum number of consecutive timeouts 631 allowed before terminating a traceroute operation. A value of 632 either 255 (maximum hop count/possible TTL value) or a 0 indicates 633 that the function of terminating a remote traceroute operation 634 when a specific number of consecutive timeouts are detected was 635 disabled. This element is included to give full compatibility 636 with [RFC4560]. No known implementation of traceroute currently 637 supports it. 638 o dataType - Unsigned32 639 o units - timeouts 640 o default value - 5 642 5.2.1.15. traceRouteCtlDontFragment 644 o name - traceRouteCtlDontFragment 645 o description - Specifies if the don't fragment flag (DF) in the IP 646 header for a probe was enabled or not. Setting the DF flag can be 647 used for performing a manual PATH MTU test. 648 o dataType - TruthValue 649 o units - N/A 650 o default value - false 652 5.2.1.16. traceRouteCtlInitialTtl 654 o name - traceRouteCtlInitialTtl 655 o description - Specifies the initial TTL value used in a traceroute 656 operation. Such TTL setting is intended to bypass the initial 657 (often well known) portion of a path. 658 o dataType - Unsigned32 659 o units - N/A 660 o default value - 1 662 5.2.1.17. traceRouteCtlDescr 664 o name - traceRouteCtlDescr 665 o description - The purpose of this element is to provide a 666 description of the traceroute test. 667 o dataType - String 668 o units - N/A 669 o default value - N/A 671 5.2.1.18. traceRouteCtlType 673 o name - traceRouteCtlType 674 o description - Specifies the implementation method used for the 675 traceroute operation. It specifies if the traceroute is using 676 TCP, UDP or ICMP probes. 677 o dataType - ProbesType 678 o units - N/A 679 o default value - UDP 681 5.2.2. Results Information Elements 683 This section describes the elements of the traceroute measurement 684 that are specific to the results of a traceroute operation. 686 5.2.2.1. traceRouteResultsStartDateAndTime 688 o name - traceRouteResultsStartDateAndTime 689 o description - Specifies the date and start time of the traceroute 690 operation. This is the time when the first probe was seen at the 691 sending interface. 692 o dataType - DateAndTime 693 o units - N/A 694 o default value - N/A 696 5.2.2.2. traceRouteResultsIpTgtAddrType 698 o name - traceRouteResultsIpTgtAddrType 699 o description - Specifies the type of address stored in the 700 corresponding traceRouteResultsIpTgtAddr element. 702 o dataType - InetAddressType 703 o units - N/A 704 o default value - N/A 706 5.2.2.3. traceRouteResultsIpTgtAddr 708 o name - traceRouteResultsIpTgtAddr 709 o description - Specifies the IP address associated with a 710 traceRouteCtlTargetAddress value when the destination address is 711 specified as a DNS name. The value of this object should be a 712 zero length octet string when a DNS name is not specified or when 713 a specified DNS name fails to resolve. 714 o dataType - InetAddress 715 o units - N/A 716 o default value - N/A 718 5.2.2.4. traceRouteResultsProbeIndex 720 o name - traceRouteResultsProbeIndex 721 o description - Specifies an index that consecutively numbers all 722 probes for which a reply was received in the sequential order in 723 which the replies were received. The maximum value for this 724 object is traceRouteCtlMaxTtl*traceRouteCtlProbesPerHop. 725 o dataType - Unsigned32 726 o units - N/A 727 o default value - N/A 729 5.2.2.5. traceRouteResultsProbeHopIndex 731 o name - traceRouteResultsProbeHopIndex 732 o description - Specifies which hop in a traceroute path that the 733 probe's results are for. 734 o dataType - Unsigned32 735 o units - N/A 736 o default value - N/A 738 5.2.2.6. traceRouteResultsProbeIndexPerHop 740 o name - traceRouteResultsProbeIndexPerHop 741 o description - Specifies the index of a probe for a particular hop 742 in a traceroute path. The number of probes per hop is determined 743 by the value of the corresponding traceRouteCtlProbesPerHop 744 element. 745 o dataType - Unsigned32 746 o units - N/A 747 o default value - N/A 749 5.2.2.7. traceRouteResultsProbeHopAddrType 751 o name - traceRouteResultsProbeHopAddrType 752 o description - Specifies the type of address stored in the 753 corresponding traceRouteResultsProbeHopAddr element. 754 o dataType - InetAddressType 755 o units - N/A 756 o default value - N/A 758 5.2.2.8. traceRouteResultsProbeHopAddr 760 o name - traceRouteResultsProbeHopAddr 761 o description - Specifies the address of a hop in the traceroute 762 path. This object is not allowed to be a DNS name. The value of 763 the corresponding object, traceRouteResultsProbeHopAddrType, 764 indicates this object's IP address type. 765 o dataType - InetAddress 766 o units - N/A 767 o default value - N/A 769 5.2.2.9. traceRouteResultsProbeHopGeoLocation 771 o name - traceRouteResultsProbeHopGeoLocation 772 o description - Specifies the geo location of a hop in the 773 traceroute path. 774 o dataType - String 775 o units - N/A 776 o default value - N/A 778 5.2.2.10. traceRouteResultsProbeMPLSTopLabel 780 o name - traceRouteResultsProbeMPLSTopLabel 781 o description - Specifies the top entry of the MPLS label stack of a 782 probe observed when the probe arrived at the hop that replied to 783 the probe. This object contains the top MPLS label stack entry as 784 32 bit value as it is observed on the MPLS label stack. Contained 785 in this single number are the MPLS label, the Exp field, the S 786 flag, and the MPLS TTL value as specified in RFC 3032 [RFC3032]. 787 o dataType - Unsigned32 788 o units - N/A 789 o default value - N/A 791 5.2.2.11. traceRouteResultsProbeRoundTripTime 793 o name - traceRouteResultsProbeRoundTripTime 794 o description - Specifies the amount of time measured in 795 milliseconds from when a probe was sent to when its response was 796 received or when it timed out. The value of this element is 797 reported as the truncation of the number reported by the 798 traceroute tool (the output "< 1 ms" is therefore encoded as 0 799 ms). A string with the value of "RoundTripTimeNotAvailable" means 800 either the probe was lost because of a timeout or it was not 801 possible to transmit a probe. 802 o dataType - Unsigned32 or String 803 o units - milliseconds or N/A 804 o default value - N/A 806 5.2.2.12. traceRouteResultsProbeResponseStatus 808 o name - traceRouteResultsProbeResponseStatus 809 o description - Specifies the result of a traceroute operation made 810 by the host for a particular probe. 811 o dataType - OperationResponseStatus 812 o units - N/A 813 o default value - N/A 815 5.2.2.13. traceRouteResultsProbeTime 817 o name - traceRouteResultsProbeTime 818 o description - Specifies the timestamp for when the response to the 819 probe was received interface. 820 o dataType - DateAndTime 821 o units - N/A 822 o default value - N/A 824 5.2.2.14. traceRouteResultsHopRawOutputData 826 o name - traceRouteResultsHopRawOutputData 827 o description - Specifies the raw output data returned by the 828 traceroute operation for a certain hop in a traceroute path. 829 o dataType - String 830 o units - N/A 831 o default value - N/A 833 5.2.2.15. traceRouteResultsEndDateAndTime 835 o name - traceRouteResultsEndDateAndTime 836 o description - Specifies the date and end time of the traceroute 837 operation. It is either the time when the response to the last 838 probe of the traceroute operation was received or the time when 839 the last probe of the traceroute operation was sent plus the 840 relative timeout (in case of missing response). 841 o dataType - DateAndTime 842 o units - N/A 843 o default value - N/A 845 5.2.3. Information Element Correlating Configuration and Results 846 Elements 848 This section defines an additional element belonging to both the two 849 previous groups. This element is defined in order to relate 850 configuration elements and results ones by means of a common unique 851 identifier. 853 5.2.3.1. traceRouteTestName 855 o name - traceRouteTestName 856 o description - Specifies the name of a traceroute test. This is 857 locally unique. 858 o dataType - String 859 o units - N/A 860 o default value - N/A 862 6. Data Model for Storing Traceroute Measurements 864 For storing and transmitting information according to the information 865 model defined in the previous section, a data model is required that 866 specifies how to encode the elements of the information model. 868 There are several design choices for a data model. It can use a 869 binary or textual representation and it can be defined from scratch 870 or use already existing frameworks and data models. In general, the 871 use of already existing frameworks and models should be preferred. 873 Binary and textual representation both have advantages and 874 disadvantages. Textual representions are (with some limitations) 875 human readable while a binary representation consumes less resources 876 for storing, transmitting and parsing data. 878 An already existing and closely related data model is the DISMAN- 879 TRACEROUTE-MIB module [RFC4560], that specifies a BER encoding 880 [RFC3417] used by the Simple Network Management Protocol (SNMP) 881 [RFC3410] for transmitting traceroute information. This data model 882 is well suited and supported within network management systems, but 883 as a general format for storing and transmitting traceroute results 884 it is not easily applicable. 886 Another binary representation would be an extension of traffic flow 887 information encodings as specified for the IPFIX protocol 888 [I-D.ietf-ipfix-protocol], [I-D.ietf-ipfix-info]. The IPFIX protocol 889 is extensible. However, the architecture behind this protocol 891 [I-D.ietf-ipfix-architecture] is targeted at exporting passively 892 measured flow information. Therefore, some obstacles are expected 893 when trying to use it for transmitting traceroute measurement 894 results. 896 For textual representations, using the eXtensible Markup Language 897 (XML) [XML] is an obvious choice. XML supports clean structuring of 898 data and syntax checking of records. With some limitations it is 899 human readable. It is supported well by a huge pool of tools and 900 standards for generating, transmitting, parsing and converting it to 901 other data formats. Its disadvantages is the resource comsumption 902 for processing, storing, and transmitting information. Since the 903 expected data volumes of traceroute data in network operation and 904 maintenance is not expected to be extremly high, the inefficient 905 usage of resources is not a significant disadvantage. Therefore, XML 906 was chosen as basis for the traceroute information model that is 907 specified in this section. 909 Section 7 contains the XML schema to be used as a template for 910 storing and/or exchanging traceroute measurements. The schema was 911 designed in order to use an extensible approach based on templates 912 (pretty similar to how IPFIX protocol is designed) where the 913 traceroute configuration elements (both the requested parameters, 914 traceRouteRequest, and the actual parameters used, 915 traceRouteMeasurementMetadata) are metadata to be referenced by 916 results information elements (data) by means of the 917 traceRouteTestName element (used as unique identifier). Currently 918 Global Grid Forum (GGF) is also using this approach and cross- 919 requirements have been analyzed as well as standardization 920 opportunities of a joint work. 922 7. XML Schema for traceroute Measurements 924 925 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 947 948 949 950 951 953 954 955 958 959 961 962 963 965 966 968 969 970 971 972 974 975 976 978 979 980 981 982 983 984 986 987 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1005 1006 1007 1009 1010 1011 1012 1013 1015 1016 1017 Specifies the name of a traceroute 1018 test. This is locally unique. 1019 1020 1021 1022 1023 1024 1026 1027 1028 Specifies the name of the operating 1029 system on which the traceroute was launched. 1030 1031 1032 1033 1035 1036 1038 1039 1040 Specifies the OS version on which the 1041 traceroute was launched. 1042 1043 1044 1045 1046 1047 1049 1050 1051 Specifies the version of the traceroute 1052 tool used. 1053 1054 1055 1056 1057 1058 1060 1061 1062 Specifies if the optional bypassing 1063 of the route table was enabled or not. If enabled, 1064 the traceroute will bypass the normal routing tables 1065 and send directly to a host on an attached network. 1066 If the host is not on a directly-attached network, 1067 an error is returned. This option can be used to 1068 perform the traceroute operation to a local host 1069 through an interface that has no route defined. 1070 1071 1072 1073 1075 1076 1077 Specifies the size of the data 1078 portion of a traceroute operation in octets. If the 1079 RECOMMENDED traceroute method (UDP datagrams as probes) 1080 is used, then the value contained in this object is 1081 exact. If another traceroute method is used for which 1082 the specified size is not appropriate, then the 1083 implementation should have used whatever size (appropriate 1084 to the method) is closest to the specified size. 1085 The maximum value for this object was computed by 1086 substracting the smallest possible IP header size of 20 1087 octets (IPv4 header with no options) and the UDP header 1088 size of 8 octets from the maximum IP packet size. An IP 1089 packet has a maximum size of 65535 octets (excluding IPv6 1090 jumbograms). Units are: octects. 1091 1092 1093 1094 1095 1096 1098 1099 1100 Specifies the time-out value, in 1101 seconds, for the traceroute operation. 1102 Units are: seconds. 1103 1104 1105 1106 1107 1108 1109 1111 1112 1113 Specifies the number of times to 1114 reissue a traceroute request with the same time-to-live 1115 (TTL) value. Units are: probes. 1116 1117 1118 1119 1120 1121 1122 1124 1125 1126 Specifies the base UDP port used by 1127 the traceroute operation. Need to specify a port that 1128 is not in use at the destination (target) host. 1129 The default value for this object is the IANA assigned 1130 port, 33434, for the traceroute function. 1132 Units are: UDP port. 1133 1134 1135 1136 1137 1138 1140 1141 1142 Specifies the maximum TTL value for 1143 the traceroute operation. 1144 Units are: time-to-live value. 1145 1146 1147 1148 1149 1150 1152 1153 1154 Specifies the value that was stored in 1155 the Differentiated Services (DS) field in the IP packet 1156 used to encapsulate the traceroute probe. The DS Field 1157 is defined as the Type of Service (TOS) octet in a IPv4 1158 header or as the Traffic Class octet in a IPv6 header. 1159 The value of this object must be a decimal integer in the 1160 range from 0 to 255. This option can be used to determine 1161 what effect an explicit DS field setting has on a 1162 traceroute response. Not all values are legal or 1163 meaningful. Useful TOS octet values are probably 1164 '16' (low delay) and '8' (high throughput). 1165 Further references can be found in the 1166 RFC 2474 for the definition of the Differentiated 1167 Services (DS) field and to the RFC 1812 Section 5.3.2 1168 for Type of Service (TOS). 1169 1170 1171 1172 1174 1175 1176 Specifies the inferface index used in the 1177 traceroute operation for sending the traceroute 1178 probes. A value of zero for this object implies 1179 that the interface was unknown. 1181 1182 1183 1184 1186 1187 1188 Specifies implementation dependent 1189 options. 1190 1191 1192 1193 1194 1196 1197 1198 Specifies the maximum number of 1199 consecutive timeouts allowed before terminating a 1200 traceroute operation. A value of either 255 1201 (maximum hop count/possible TTL value) or a 0 indicates 1202 that the function of terminating a remote traceroute 1203 operation when a specific number of consecutive 1204 timeouts are detected was disabled. This element is 1205 included to give full compatibility with DISMAN working 1206 group documents. No known implementation of traceroute 1207 currently supports it. 1208 Units are: timeouts. 1209 1210 1211 1212 1214 1215 1216 Specifies if the don't fragment flag 1217 (DF) in the IP header for a probe was enabled or not. 1218 Setting the DF flag can be used for performing 1219 a manual PATH MTU test. 1220 1221 1222 1223 1225 1226 1227 Specifies the initial TTL value 1228 used in a traceroute operation. Such 1229 TTL setting is intended to bypass the initial 1230 (often well known) portion of a path. 1231 1232 1233 1234 1235 1236 1238 1239 1240 The purpose of this element is to 1241 provide a description of the traceroute test. 1242 1243 1244 1245 1246 1247 1249 1250 1251 Specifies the implementation method 1252 used for the traceroute operation. It specifies if 1253 the traceroute is using TCP, UDP or ICMP probes. 1254 1255 1256 1257 1258 1259 1260 1261 1263 1264 1265 Specifies an index that consecutively 1266 numbers all probes for which a reply was received in the 1267 sequential order in which the replies were received. 1268 The maximum value for this object is 1269 traceRouteCtlMaxTtl*traceRouteCtlProbesPerHop. 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 Specifies which hop in a traceroute 1280 path that the probe's results are for. The value of 1281 this element is initially determined by the value of 1282 traceRouteCtlInitialTtl. 1283 1284 1285 1286 1287 1288 1290 1291 1292 Specifies the index of a probe for 1293 a particular hop in a traceroute path. The number of 1294 probes per hop is determined by the value of the 1295 corresponding traceRouteCtlProbesPerHop element. 1296 1297 1298 1299 1300 1301 1302 1304 1305 1306 Specifies the geo location of a hop 1307 in the traceroute path. 1308 1309 1310 1311 1312 1313 1315 1316 1317 Specifies the top entry of the MPLS label 1318 stack of a probe observed when the probe arrived at the hop 1319 that replied to the probe. This object contains the top 1320 MPLS label stack entry as 32 bit value as it is observed on 1321 the MPLS label stack. Contained in this single number are 1322 the MPLS label, the Exp field, the S flag, and the MPLS TTL 1323 value as specified in RFC 3032 [RFC3032]. 1324 1326 1327 1328 1329 1330 1332 1333 1334 1335 1336 1338 1339 1340 1341 1342 1344 1345 1346 Specifies the raw output data returned 1347 by the traceroute operation for a certain hop in a 1348 traceroute path. 1349 1350 1351 1352 1353 1354 1356 1357 1358 Specifies the AS number of a hop in the 1359 traceroute path as a 24 bit number and the indication how 1360 the mapping from IP address to AS number was performed. 1361 1362 1363 1365 1367 1368 1370 1371 1372 1375 1377 1379 1381 1383 1384 1386 1387 1388 1390 1392 1394 1396 1398 1399 1401 1402 1403 1405 1407 1408 1410 1411 1412 Specifies the type of host address 1413 used in the traceroute command. 1414 1415 1416 1417 1419 1420 1422 1423 1424 Specifies the host address used in 1425 the traceroute command. The host address type can be 1426 determined by the examining the value of the 1427 corresponding traceRouteCtlTargetAddressType. 1428 1429 1430 1431 1432 1433 1435 1436 1437 Specifies the type of the source address, 1438 traceRouteCtlSourceAddress, used when performing the 1439 traceroute operation. 1440 1441 1442 1443 1445 1446 1448 1449 1450 Specifies the IP address (which has 1451 to be given as an IP number, not a hostname) as the 1452 source address used in outgoing probe packets. On hosts 1453 with more than one IP address, this option can be used 1454 to force the source address to be something other than 1455 the primary IP address of the interface the probe packet 1456 is sent on. A zero length octet string value for this 1457 object means that source addres specification was disabled. 1458 The address type (InetAddressType) that relates to this 1459 object is specified by the corresponding value of 1460 traceRouteCtlSourceAddressType. 1461 1462 1463 1464 1466 1467 1469 1470 1471 Specifies the date and start time of the 1472 traceroute operation. This is the time when the first probe 1473 was sent. 1474 1475 1476 1477 1478 1479 1481 1482 1483 Specifies the type of address stored 1484 in the corresponding traceRouteResultsIpTgtAddr element. 1485 1486 1487 1488 1490 1491 1493 1494 1495 Specifies the IP address associated 1496 with a traceRouteCtlTargetAddress value when the 1497 destination address is specified as a DNS name. 1498 The value of this object should be a zero length octet 1499 string when a DNS name is not specified or when a 1500 specified DNS name fails to resolve. 1501 1502 1503 1504 1506 1507 1509 1510 1511 Specifies the type of address stored 1512 in the corresponding traceRouteResultsProbeHopAddr 1513 element. 1514 1515 1516 1517 1520 1521 1523 1524 1525 Specifies the address of a hop in 1526 the traceroute path. This object is not allowed to 1527 be a DNS name. The value of the corresponding object, 1528 traceRouteResultsProbeHopAddrType, indicates this 1529 object's IP address type. 1530 1531 1532 1533 1535 1536 1538 1539 1540 Specifies the amount of time measured 1541 in milliseconds from when a probe was sent to when its 1542 response was received or when it timed out. The value 1543 of this element is reported as the truncation of the 1544 number reported by the traceroute tool (the output 1545 "<1 ms" is therefore encoded as 0 ms). 1546 A string with the value of "RoundTripTimeNotAvailable" 1547 means either the probe was lost because of a timeout 1548 or it was not possible to transmit a probe. 1549 Units are: milliseconds. 1550 1551 1552 1553 1555 1557 1558 1560 1561 1562 Specifies the result of a traceroute 1563 operation made by the host for a particular probe. 1564 1565 1566 1567 1569 1570 1572 1573 1574 Specifies the timestamp when the 1575 response to the probe was received. 1576 1577 1578 1579 1580 1581 1583 1584 1585 1587 1589 1591 1593 1595 1598 1601 1603 1605 1607 1608 1610 1611 1612 Specifies the date and end time of 1613 the traceroute operation. It is either the time when 1614 the response to the last probe of the traceroute 1615 operation was received or the time when the last 1616 probe of the traceroute operation was sent plus the 1617 relative timeout (in case of missing response). 1618 1619 1620 1621 1622 1623 1625 1626 1627 Specifies the metadata for a 1628 traceroute operation. In a request, these are the 1629 requested parameters. In a response, they are the 1630 actual parameters used. 1631 1632 1633 1634 1636 1639 1642 1645 1647 1649 1653 1656 1659 1662 1665 1668 1671 1673 1675 1678 1681 1684 1687 1690 1693 1697 1698 1700 1701 1702 1703 Contains the actual traceroute measurement. 1704 1705 1706 1707 1709 1711 1713 1715 1718 1721 1723 1724 1726 1727 1728 1729 1731 1732 1733 1735 1736 1737 1739 1740 1741 1743 1745 1746 1747 1749 1751 1752 1753 1755 1757 1758 1759 1761 1763 1765 1766 1767 1769 1770 1772 1774 8. Differences to DISMAN-TRACEROUTE-MIB 1776 For performing remote traceroute operations at managed node, the IETF 1777 has standardized the DISMAN-TRACEROUTE-MIB module in RFC 4560 1778 [RFC4560]. This module allows: 1780 o retrieving capability information of the traceroute implementation 1781 at the managed node, 1782 o configuring traceroute operations to be prformed, 1783 o retrieving information about ongoing and completed traceroute 1784 measurements, 1785 o retrieving traceroute measurement statistics. 1787 The traceroute storage format described in this document has 1788 significant overlaps with this MIB module. Particularly, the models 1789 for the traceroute measurement configuration and for the result from 1790 completed measurements are almost identical. But for other pats of 1791 the DISMAN-TRACEROUTE MIB module there is no need to model them in a 1792 traceroute storage format. Particularly, the capability information, 1793 information about ongoing measurements and measurement statistics are 1794 not covered by the traceroute storage model. 1796 Concerning traceroute measurements and results, there are structural 1797 differences between the two models caused by the different choices 1798 for the encoding of the specification. For DISMAN-TRACEROUTE-MIB, 1799 the Structure of Management Information (SMIv2, STD 58, RFC 2578 1800 [RFC2578]) was used, while for the traceroute storage format is 1801 encoded using XML. 1803 This difference in structure implies that the DISMAN-TRACEROUTE-MIB 1804 module contains SMI-specific information element (managed objects) 1805 that concern tables of managed objects (specification, entry creation 1806 and delection, status retrieval) that are not required for the XML- 1807 encoded traceroute storage format. 1809 But for most of the remaining information elements that concern 1810 configuration of traceroute measurements and results of completed 1811 measurements, the semantics is identical between the DISMAN- 1812 TRACEROUTE-MIB module and the traceroute storage format. There are 1813 very few exceptions to this which are listed below. Also naming of 1814 information elements is identical between both models with a few 1815 exceptions. For the traceroute storage model, a few information 1816 elements have been added, some because of the different structure and 1817 some to provide additional information on completed measurements. 1819 8.1. Naming 1821 Basically, names in both models are chosen using the same naming 1822 conventions. 1824 For the traceroute measurement configuration information all names, 1825 such as traceRouteCtlProbesPerHop, are identical in both models, 1826 except for traceRouteCtlDataSize which was renamed to 1827 traceRouteCtlProbeDataSize for clarification in the traceroute 1828 storage model. 1830 Results of measurements in the DISMAN-TRACEROUTE-MIB modules are 1831 distributed over two tables, the traceRouteResultsTable containing 1832 mainly information about ongoing measurements and the 1833 traceRouteProbeHistoryTable containing only information about 1834 completed measurements. According to the SMIv2 naming conventions 1835 names of information elements in these tables have different prefixes 1836 (traceRouteResults and traceRouteProbeHistory). since the traceroute 1837 storage format only reports on completed measurements, this 1838 separation is not needed anymore and the prefix "traceRouteResults" 1839 is used for all related information elelments. 1841 Beyond that, there are only a few changes in element names. The 1842 renaming actions include: 1844 o traceRouteProbeHistoryProbeIndex to 1845 traceRouteResultsProbeIndexPerHop, 1846 o traceRouteProbeHistoryResponse to 1847 traceRouteResultsProbeRoundTripTime, 1848 o traceRouteProbeHistoryTime to traceRouteResultsEndDateAndTime, 1849 o traceRouteProbeHistoryLastRC to traceRouteResultsHopRawOutputData. 1851 8.2. Semantics 1853 The semantics was changed for two information elements only. 1855 For traceRouteProbeHistoryResponse in the DISMAN-TRACEROUTE-MIB, a 1856 value of 0 indicated, that it was not possible to transmit a probe. 1857 For the traceroute strorage format, a value of 0 for element 1858 traceRouteResultsProbeRoundTripTime indicates that the measured time 1859 was less than one millisecond, while for the case that it was not 1860 possible to transmit a probe a string is used that indicates the 1861 problem. 1863 For traceRouteCtlIfIndex in the DISMAN-TRACEROUTE-MIB, a value of 0 1864 indicated, that it the option to set the index is not available. 1865 This was translated to the traceroute strorage format, such that a 1866 value of 0 for this element indicates that the used interface is 1867 unknown. 1869 The element traceRouteProbeHistoryLastRC in the DISMAN-TRACEROUTE-MIB 1870 was replaced by element traceRouteResultsHopRawOutputData. While 1871 traceRouteProbeHistoryLastRC just reports a reply code, 1872 traceRouteResultsHopRawOutputData reports the full raw output data 1873 produced by the traceroute instance that was used. 1875 8.3. Additional Information Elements 1877 Only a few information elements have been added to the model of the 1878 DISMAN-TRACEROUTE-MIB module. 1880 o For providing geographical information about hops in the 1881 traceroute path, traceRouteResultsProbeHopGeoLocation was added. 1882 o For providing the top MPLS label stack entry of a probe in the 1883 traceroute path traceRouteResultsProbeMPLSTopLabel was added. 1884 o For providing additional timestamp beyond 1885 traceRouteResultsEndDateAndTime, traceRouteResultsStartDateAndTime 1886 and traceRouteResultsProbeTime were added. 1888 9. Security Considerations 1890 Security considerations in this section discuss are grouped into 1891 considerartions related to conducting traceroute measurements and 1892 considerations related to storing and transmitting results of 1893 measurements. 1895 This memo does not specify an implementation of a traceroute 1896 measurements. Neither does it specify a certain procedure for 1897 storing traceroute measurement results. Still it is considered 1898 desirable to discuss related security issues below. 1900 9.1. Conducting Traceroute Measurements 1902 Conducting Internet measurements can raise both security and privacy 1903 concerns. Traceroute measurements, in which traffic is injected into 1904 the network, can be abused for denial-of-service attacks disguised as 1905 legitimate measurement activity. 1907 Measurement parameters MUST be carefully selected so that the 1908 measurements inject trivial amounts of additional traffic into the 1909 networks they measure. If they inject "too much" traffic, they can 1910 skew the results of the measurement, and in extreme cases cause 1911 congestion and denial of service. 1913 The measurements themselves could be harmed by routers giving 1914 measurement traffic a different priority than "normal" traffic, or by 1915 an attacker injecting artificial measurement traffic. If routers can 1916 recognize measurement traffic and treat it separately, the 1917 measurements will not reflect actual user traffic. If an attacker 1918 injects artificial traffic that is accepted as legitimate, the loss 1919 rate will be artificially lowered. Therefore, the measurement 1920 methodologies SHOULD include appropriate techniques to reduce the 1921 probability measurement traffic can be distinguished from "normal" 1922 traffic. 1924 Authentication techniques, such as digital signatures, may be used 1925 where appropriate to guard against injected traffic attacks. 1927 9.2. Securing Traceroute Measurement Results 1929 Traceroute results are not considered highly sensible. Still, they 1930 may contain sensible information on network paths, routing states, 1931 use IP addresses, and roundtrip times, that the operator a networks 1932 may want to detect for business or security reasons. 1934 It is thus important to control access to Information acquired by 1935 conducting traceroute measurement, particularly when transmitting it 1936 over a networks but also when storing it. It is RECOMMENDED that 1937 transmission of traceroute measurement results over a network uses 1938 appropriate protection mechanisms for preserving privacy, integrity 1939 and authenticity. It is further RECOMMENDED that secure 1940 authentication and authorization are used for protecting stored 1941 traceroute results. 1943 10. IANA Considerations 1945 This document uses URNs to describe an XML namespace and an XML 1946 schema for traceroute measurements conforming to a registry mechanism 1947 described in [RFC3688]. Two URI assignments are requested. 1948 1. Registration request for the IPPM traceroute measurements 1949 namespace 1950 * URI: urn:ietf:params:xml:ns:traceroute-1.0 1951 * Registrant Contact: TBD. 1952 * XML: None. Namespace URIs do not represent an XML 1953 2. Registration request for the IPPM traceroute measurements schema 1954 * URI: urn:ietf:params:xml:schema:traceroute-1.0 1955 * Registrant Contact: TBD. 1956 * XML: See the section Section 7 of this document. 1958 11. References 1960 11.1. Normative References 1962 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1963 Requirement Levels", BCP 14, RFC 2119, March 1997. 1965 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1966 Schoenwaelder, "Textual Conventions for Internet Network 1967 Addresses", RFC 4001, February 2005. 1969 11.2. Informative References 1971 [I-D.ietf-disman-remops-mib-v2] 1972 Quittek, J. and K. White, "Definitions of Managed Objects 1973 for Remote Ping, Traceroute, and Lookup Operations", 1974 draft-ietf-disman-remops-mib-v2-09 (work in progress), 1975 February 2006. 1977 [I-D.ietf-ipfix-architecture] 1978 Sadasivan, G., "Architecture for IP Flow Information 1979 Export", draft-ietf-ipfix-architecture-12 (work in 1980 progress), September 2006. 1982 [I-D.ietf-ipfix-info] 1983 Quittek, J., "Information Model for IP Flow Information 1984 Export", draft-ietf-ipfix-info-13 (work in progress), 1985 September 2006. 1987 [I-D.ietf-ipfix-protocol] 1988 Claise, B., "IPFIX Protocol Specification", 1989 draft-ietf-ipfix-protocol-22 (work in progress), 1990 June 2006. 1992 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1993 RFC 1812, June 1995. 1995 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1996 "Definition of the Differentiated Services Field (DS 1997 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1998 December 1998. 2000 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2001 Schoenwaelder, Ed., "Structure of Management Information 2002 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2004 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2005 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 2006 STD 58, RFC 2579, April 1999. 2008 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 2009 MIB", RFC 2863, June 2000. 2011 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 2012 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 2013 Encoding", RFC 3032, January 2001. 2015 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 2016 "Introduction and Applicability Statements for Internet- 2017 Standard Management Framework", RFC 3410, December 2002. 2019 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 2020 Management Protocol (SNMP)", STD 62, RFC 3417, 2021 December 2002. 2023 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2024 January 2004. 2026 [RFC4560] Quittek, J. and K. White, "Definitions of Managed Objects 2027 for Remote Ping, Traceroute, and Lookup Operations", 2028 RFC 4560, June 2006. 2030 [XML] Yergeau et al., F., "Extensible Markup Language (XML) 1.0 2031 (Third Edition)", W3C Recommendation, February 2004. 2033 Authors' Addresses 2035 Saverio Niccolini 2036 Network Laboratories, NEC Europe Ltd. 2037 Kurfuersten-Anlage 36 2038 Heidelberg 69115 2039 Germany 2041 Phone: +49 (0) 6221 4342 118 2042 Email: saverio.niccolini@netlab.nec.de 2043 URI: http://www.netlab.nec.de 2045 Sandra Tartarelli 2046 Network Laboratories, NEC Europe Ltd. 2047 Kurfuersten-Anlage 36 2048 Heidelberg 69115 2049 Germany 2051 Phone: +49 (0) 6221 4342 132 2052 Email: sandra.tartarelli@netlab.nec.de 2053 URI: http://www.netlab.nec.de 2055 Juergen Quittek 2056 Network Laboratories, NEC Europe Ltd. 2057 Kurfuersten-Anlage 36 2058 Heidelberg 69115 2059 Germany 2061 Phone: +49 (0) 6221 4342 115 2062 Email: quittek@netlab.nec.de 2063 URI: http://www.netlab.nec.de 2065 Martin Swany 2066 Dept. of Computer and Information Sciences, University of Delaware 2067 Newark DE 19716 2068 U.S.A. 2070 Email: swany@UDel.Edu 2072 Full Copyright Statement 2074 Copyright (C) The Internet Society (2006). 2076 This document is subject to the rights, licenses and restrictions 2077 contained in BCP 78, and except as set forth therein, the authors 2078 retain all their rights. 2080 This document and the information contained herein are provided on an 2081 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2082 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2083 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2084 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2085 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2086 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2088 Intellectual Property 2090 The IETF takes no position regarding the validity or scope of any 2091 Intellectual Property Rights or other rights that might be claimed to 2092 pertain to the implementation or use of the technology described in 2093 this document or the extent to which any license under such rights 2094 might or might not be available; nor does it represent that it has 2095 made any independent effort to identify any such rights. Information 2096 on the procedures with respect to rights in RFC documents can be 2097 found in BCP 78 and BCP 79. 2099 Copies of IPR disclosures made to the IETF Secretariat and any 2100 assurances of licenses to be made available, or the result of an 2101 attempt made to obtain a general license or permission for the use of 2102 such proprietary rights by implementers or users of this 2103 specification can be obtained from the IETF on-line IPR repository at 2104 http://www.ietf.org/ipr. 2106 The IETF invites any interested party to bring to its attention any 2107 copyrights, patents or patent applications, or other proprietary 2108 rights that may cover technology that may be required to implement 2109 this standard. Please address the information to the IETF at 2110 ietf-ipr@ietf.org. 2112 Acknowledgment 2114 Funding for the RFC Editor function is provided by the IETF 2115 Administrative Support Activity (IASA).