idnits 2.17.1 draft-ietf-ippm-storetraceroutes-00.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 1974. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1951. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1958. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1964. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 502: '... octets. If the RECOMMENDED tracerout...' RFC 2119 keyword, line 1073: '... RECOMMENDED traceroute method...' RFC 2119 keyword, line 1784: '...ement parameters MUST be carefully sel...' RFC 2119 keyword, line 1797: '... methodologies SHOULD include approp...' RFC 2119 keyword, line 1813: '...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 253 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 (June 14, 2006) is 6525 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '1-9' is mentioned on line 951, but not defined == Missing Reference: '0-9' is mentioned on line 952, but not defined == Missing Reference: '0-4' is mentioned on line 952, but not defined == Missing Reference: '0-5' is mentioned on line 952, but not defined == Unused Reference: 'I-D.ietf-ipfix-protocol' is defined on line 1869, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-ipfix-architecture-10 == Outdated reference: A later version (-15) exists of draft-ietf-ipfix-info-11 == Outdated reference: A later version (-26) exists of draft-ietf-ipfix-protocol-21 Summary: 4 errors (**), 0 flaws (~~), 11 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 Expires: December 16, 2006 J. Quittek 5 NEC 6 M. Swany 7 UDel 8 June 14, 2006 10 Traceroute Measurements Information Model and XML Data Model 11 draft-ietf-ippm-storetraceroutes-00 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 December 16, 2006. 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. Security Considerations . . . . . . . . . . . . . . . . . . . 38 77 8.1. Conducting Traceroute Measurements . . . . . . . . . . . . 38 78 8.2. Securing Traceroute Measurement Results . . . . . . . . . 38 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 80 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 39 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 82 11.1. Normative References . . . . . . . . . . . . . . . . . . . 39 83 11.2. Informative References . . . . . . . . . . . . . . . . . . 40 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 85 Intellectual Property and Copyright Statements . . . . . . . . . . 43 87 1. Introduction 89 Traceroutes are being used by lots of measurement efforts, either as 90 an independent measurement or to get path information to support 91 other measurement efforts. That is why there is the need to 92 standardize the way traceroute measurements are stored and the 93 related metrics associated with such measurements. Since traceroute 94 is a tool that has built-in configurable mechanisms like time-outs 95 and can experience problems related to the crossing of firewalls thus 96 experiencing fake losses or incomplete delay information. The 97 standard metrics defined by IPPM working group in matter of delay, 98 connectivity and losses do not apply to the metrics returned by the 99 traceroute tool; therefore, in order to compare results of traceroute 100 measurements, the solution is to add to the stored results a 101 specification of the operating system and version for the tool used. 102 Moreover there is a need to better define the traceroute tool as well 103 as its parameters and the results it outputs since, to the authors' 104 knowledge, there is so far no standard describing these. These are 105 the motivations that moved the authors to write this draft in the 106 context of the IPPM working group even if other working groups (like 107 DISMAN) have already addressed similar issues related to the 108 definition of the MIB for configuring and retrieving traceroute 109 measurements results. This draft, in order to store traceroute 110 results and allow comparison of them, defines a standard way to store 111 traceroute measurements using a XML schema. The draft is organised 112 as follows: Section 2 gives the definition of traceroute used as 113 reference in the rest of the draft as well as the traceroute 114 configurable parameters and their default values for the most common 115 operating systems. Section 3 reports on both traceroute accuracy of 116 results and existing alternatives for traceroute implementations. 117 Section 4 describes the results available from the traceroute output 118 screen. Section 5 and Section 6 respectively describe our proposed 119 Information model and Data model for storing traceroute measurements. 120 The draft ends with security considerations, IANA considerations and 121 open issues in Section 8, Section 9 and Section 10 respectively. 123 2. Definition of Traceroute 125 Traceroute is a network diagnostic tool used to determine the hop by 126 hop path from a source to a destination and the Round Trip Time (RTT) 127 from the source to each hop. Traceroute can therefore be used to 128 discover where and how a host is connected to the Internet and can be 129 usefully employed to troubleshoot network connections. 131 Typically, traceroute attemps to discover the path to a destination 132 by sending UDP probes with specific time-to-live (TTL) values in the 133 IP packet header and trying to elicit an ICMP TIME_EXCEEDED response 134 from each gateway along the path to some host. 136 More in detail, the host running the traceroute sends the first set 137 of probes with TTL equal to one (some implementations allow setting 138 the initial TTL to a value equal to "n" different from one, so that 139 the first "n-1" hops are skipped and the first hop that will be 140 traced is the "n-th" in the path). Upon receiving a probe, the first 141 hop host decreases the TTL value by one. By observing a TTL value 142 equal to zero, the host rejects the probe and typically returns an 143 ICMP message with a TIME_EXCEEDED value. Traceroute can therefore 144 derive the IP address of the first hop from the header of the ICMP 145 message and evaluate the RTT between the source and the first hop. 146 The next hops are discovered following the same procedure, taking 147 care of increasing at each step the TTL value of the outgoing probes 148 by one. The TTL value is increased until either an ICMP 149 PORT_UNREACHABLE message is received, meaning that the destination 150 has been reached, or the maximum configured number of hops has been 151 hit. 153 Some implementations, use ICMP Echos, instead of UDP datagrams. 154 However, many routers do not return ICMP messages about ICMP 155 messages, i.e. no ICMP TIME_EXCEEDED is returned for an ICMP Echo. 156 Therefore, in this draft we RECOMMEND to base implementations on UDP 157 datagrams. 159 2.1. Traceroute Configuration Parameters 161 In order to define an information model for storing traceroutes, we 162 first investigated which configuration parameters are relevant when 163 running traceroute. We considered four major traceroute 164 implementations and compared them based on configurable parameters 165 and default values. The LINUX (SUSE 9.1), BSD (FreeBSD 7.0) and UNIX 166 (SunOS 5.9) implemetations are based on UDP datagrams, while the 167 WINDOWS (XP SP2) one uses ICMP Echos. The comparison is summarized 168 in the following table, where an N/A in the option column, means that 169 such parameter is not configurable for the specific implementation. 170 A comprehensive comparison of available implementations is outside 171 the scope of this draft; however, already by sampling a few different 172 implementations, we can observe that they can differ quite 173 significantly in terms of configurable parameters and also default 174 values. Note that in the following table we reported only those 175 options which are available in at least two of the considered 176 implementations. 178 +---------------------------------------------------------+ 179 | OS |Option| Description | Default | 180 +--------+------+-------------------------------+---------+ 181 | LINUX | -m |Specify the maximum TTL used | 30 | 182 |--------+------|in outgoing probes. |---------| 183 | FreeBSD| -m | | OS var | 184 |--------+------| |---------| 185 | UNIX | -m | | 30 | 186 |--------+------| |---------| 187 | WINDOWS| -h | | 30 | 188 +--------+------+-------------------------------+---------+ 189 | LINUX | -n |Display hop addresses | - | 190 |--------+------|numerically rather than |---------| 191 | FreeBSD| -n |simbolically. | - | 192 |--------+------| |---------| 193 | UNIX | -n | | - | 194 |--------+------| |---------| 195 | WINDOWS| -d | | - | 196 +--------+------+-------------------------------+---------+ 197 | LINUX | -w |Set the time to wait for a | 3 sec | 198 |--------+------|response to a probe. |---------| 199 | FreeBSD| -w | | 5 sec | 200 |--------+------| |---------| 201 | UNIX | -w | | 5 sec | 202 |--------+------| |---------| 203 | WINDOWS| -w | | 4 sec | 204 +--------+------+-------------------------------+---------+ 205 | LINUX | N/A |Specify a loose source route | - | 206 |--------+------|gateway (to direct the |---------| 207 | FreeBSD| -g |traceroute through routers not | - | 208 |--------+------|necessarily in the path). |---------| 209 | UNIX | -g | | - | 210 |--------+------| |---------| 211 | WINDOWS| -g | | - | 212 +--------+------+-------------------------------+---------+ 213 | LINUX | -p |Set the base UDP port number | 33434 | 214 |------- +------|used in probes |---------| 215 | FreeBSD| -p |(UDP port = base + nhops - 1). | 33434 | 216 |--------+------| |---------| 217 | UNIX | -p | | 33434 | 218 |--------+------| |---------| 219 | WINDOWS| N/A | | - | 220 +--------+------+-------------------------------+---------+ 221 | LINUX | -q |Set the number of probes per | 3 | 222 |--------+------|TTL. |---------| 223 | FreeBSD| -q | | 3 | 224 |--------+------| |---------| 225 | UNIX | -q | | 3 | 226 |--------+------| |---------| 227 | WINDOWS| N/A | | 3 | 228 +--------+------+-------------------------------+---------+ 229 | LINUX | -S |Set the IP source address in |IP | 230 |--------+------|outgoing probes to the |address | 231 | FreeBSD| -s |specified value. |of the | 232 |--------+------| |out | 233 | UNIX | -s | |interface| 234 |--------+------| | | 235 | WINDOWS| N/A | | | 236 +--------+------+-------------------------------+---------+ 237 | LINUX | -t |Set the type-of-service (TOS) | 0 | 238 |--------+------|in the probes to the specified |---------| 239 | FreeBSD| -t |value. | 0 | 240 |--------+------| |---------| 241 | UNIX | -t | | 0 | 242 |--------+------| |---------| 243 | WINDOWS| N/A | | 0 | 244 +--------+------+-------------------------------+---------+ 245 | LINUX | -v |Verbose output: received ICMP | - | 246 |--------+------|packets other than |---------| 247 | FreeBSD| -v |TIME_EXCEEDED and | - | 248 |--------+------|UNREACHABLE are listed. |---------| 249 | UNIX | -v | | - | 250 |--------+------| |---------| 251 | WINDOWS| N/A | | - | 252 +--------+------+-------------------------------+---------+ 253 | LINUX | N/A |Set the time (in msec) to | - | 254 |--------+------|pause between probes. |---------| 255 | FreeBSD| -z | | 0 | 256 |--------+------| |---------| 257 | UNIX | -P | | 0 | 258 |--------+------| |---------| 259 | WINDOWS| N/A | | - | 260 +--------+------+-------------------------------+---------+ 261 | LINUX | -r |Bypass the normal routing | - | 262 |--------+------|tables and send directly to a |---------| 263 | FreeBSD| -r |host on attached network. | - | 264 |--------+------| |---------| 265 | UNIX | -r | | - | 266 |--------+------| |---------| 267 | WINDOWS| N/A | | - | 268 +--------+------+-------------------------------+---------+ 269 | LINUX | -f |Set the initial TTL for the | 1 | 270 |--------+------|first probe. |---------| 271 | FreeBSD| -f | | 1 | 272 |--------+------| |---------| 273 | UNIX | -f | | 1 | 274 |--------+------| |---------| 275 | WINDOWS| N/A | | 1 | 276 +--------+------+-------------------------------+---------+ 277 | LINUX | -F |Set the "don't fragment" bit. | - | 278 |--------+------| |---------| 279 | FreeBSD| -F | | - | 280 |--------+------| |---------| 281 | UNIX | -F | | - | 282 |--------+------| |---------| 283 | WINDOWS| N/A | | - | 284 +--------+------+-------------------------------+---------+ 285 | LINUX | N/A |Enables socket level debugging.| - | 286 |--------+------| |---------| 287 | FreeBSD| -d | | - | 288 |--------+------| |---------| 289 | UNIX | -d | | - | 290 |--------+------| |---------| 291 | WINDOWS| N/A | | - | 292 +--------+------+-------------------------------+---------+ 293 | LINUX | N/A |Use ICMP ECHO instead of UDP | - | 294 |--------+------|datagrams. |---------| 295 | FreeBSD| -I | | - | 296 |--------+------| |---------| 297 | UNIX | -I | | - | 298 |--------+------| |---------| 299 | WINDOWS| N/A | | - | 300 +--------+------+-------------------------------+---------+ 301 | LINUX | -I |Specify a network interface to | - | 302 |--------+------|obtain the IP address for |---------| 303 | FreeBSD| -i |outgoing IP packets | - | 304 |--------+------|(alternative to option -s). |---------| 305 | UNIX | -i | | - | 306 |--------+------| |---------| 307 | WINDOWS| N/A | | - | 308 +--------+------+-------------------------------+---------+ 309 | LINUX | N/A |Toggle checksum. | - | 310 |--------+------| |---------| 311 | FreeBSD| -x | | - | 312 |--------+------| |---------| 313 | UNIX | -x | | - | 314 |--------+------| |---------| 315 | WINDOWS| N/A | | - | 316 +--------+------+-------------------------------+---------+ 317 | LINUX | - |As optional last paramater, |Depends | 318 |--------+------|LINUX, FreeBSD and UNIX |on | 319 | FreeBSD| - |implementations allow |implement| 320 |--------+------|specifying the probe datagram |ation. | 321 | UNIX | - |length for outgoing probes. | | 322 |--------+------| | | 323 | WINDOWS| N/A | | | 324 +--------+------+-------------------------------+---------+ 326 3. Known Problems with Traceroute 328 3.1. Accuracy of Results 330 A known inconsistency exists between the round-trip delay metric 331 defined by the IPPM working group and the results returned by the 332 current traceroute implementations. Unfortunately, it is unlikely 333 that the traceroute implementations will implement the standard 334 definition in the near future. In order to compare results of 335 different traceroute measurements, specifications both of the 336 operating system (name and version) and of the traceroute tool 337 version used are added to the metadata elements in order to help in 338 comparing metrics. Moreover, the traceroute has built-in 339 configurable mechanisms like time-outs and can experience problems 340 related to the crossing of firewalls; therefore some of the packets 341 that traceroute sends out end up being time-out or filtered. As a 342 consequence, it might not be possible to trace the path to a node or 343 there might not be a complete set of probes describing the RTT to 344 reach it. 346 3.2. Alternative traceroute Implementations 348 As stated above, the widespred use of firewalls might prevent UDP or 349 ICMP based traceroutes to completely trace the path to a destination, 350 since traceroute probes might end up being filtered. In some cases, 351 such limitation might be overcome by sending instead TCP packets to 352 specific ports that hosts located behind the firewall are listening 353 for connections on. TCP based implementations use TCP SYN or FYN 354 probes and listen for TIME_EXCEEDED messages, TCP RESET and other 355 messages from firewalls and gateways on the path. On the other hand, 356 some firewalls filter out TCP SYN packets to prevent denial of 357 service attacks, therefore the actual advantage of using TCP instead 358 of UDP traceroute depends mainly on firewall configurations, which 359 are not known in adavance. A detailed analysis of TCP based 360 traceroutes is outside the scope of this draft, therefore in the 361 sequel, we will restrict our focus to the most commonly implemented 362 UDP based traceroute. 364 4. Reports/results 366 The following list reports the information fields provided by all 367 traceroute implementations considered. The order in which they are 368 reported here is not relevant and it changes in different 369 implementations. For each hop the information reported is: 370 o the hop index; 371 o the host symbolical address, provided that at least one of the 372 probes received a response, the symbolic address could be resolved 373 at the correponding host and that the option to display only 374 numerical addresses was not set; 375 o the host IP address, provided that at least one of the probes 376 received a response; 377 o the RTT for each response to a probe. 378 Depending on the traceroute implementation, additional information 379 might be displayed in the output (for instance MPLS-related 380 information). 382 It might happen that some probes do not receive a response within the 383 configured time-out (for instance if the probe is filtered out by a 384 firewall). In this case, an "*" is displayed in place of the RTT. 385 Besides, for delays below 1 ms, some implementations reports 0 ms 386 (f.i. UNIX and LINUX) while WINDOWS tracert reports "< 1 ms". 388 5. Information Model for Storing Traceroute Measurements 390 This section describes the information model for the traceroute 391 measurements data storing. The information model is composed of 392 information elements; for defining these information elements, a 393 template is used. Such template is specified in the list below: 395 o name - A unique and meaningful name for the information element. 396 The preferred spelling for the name is to use mixed case if the 397 name is compound, with an initial lower case letter, e.g., 398 "sourceIpAddress". 399 o description - The semantics of this information element. 400 o dataType - One of the types listed in Section 5.1 of this document 401 or in an extension of the information model. The type space for 402 attributes is constrained to facilitate implementation. 403 o units - If the element is a measure of some kind, the units 404 identify what the measure is. 405 o default value - The default value for the element (where 406 applicable). 408 5.1. Data Types 410 This section describes the set of valid data types of the information 411 model. 413 o String - The type "String" represents a finite length string of 414 valid characters from the Unicode character encoding set. Unicode 415 allows for ASCII and many other international character sets to be 416 used. It is expected that strings will be encoded in UTF-8 417 format, which is identical in encoding for USASCII characters, but 418 also accomodates other Unicode multibyte characters. 419 o InetAddressType - The type "InetAddressType" represents a type of 420 Internet address. The allowed values are to be intended as 421 imported from [RFC4001]; an additional allowed value is 422 "asnumber". 423 o InetAddress - The type "InetAddress" denotes a generic Internet 424 address. The allowed values are to be intended as imported from 425 [RFC4001]; an additional allowed value is the AS number to be 426 indicated as the actual number plus the indication how the mapping 427 from IP address to AS number was performed. 428 o TruthValue - The type "TruthValue" represents a boolean value. 429 The allowed values are to be intended as imported from [RFC2579]. 430 o Unsigned32 - The type "Unsigned32" represents a value in the range 431 (0..4294967295). 432 o InterfaceIndexOrZero - The type "InterfaceIndexOrZero" is an 433 extension of the InterfaceIndex convention. The latter defines a 434 greater than zero value used to identify an interface or interface 435 sub-layer in the system. This extension permits the additional 436 value of zero. Examples of the usage of zero might include 437 situations where interface was unknown, or when none or all 438 interfaces need to be referenced. The allowed values are to be 439 intended as imported from [RFC2863]. 440 o ProbesType - The type "ProbesType" represents a way of indicating 441 the protocol used for the traceroute probes. Allowed values are 442 UDP, TCP, ICMP. 443 o DateAndTime - The type "DateAndTime" represents a date-time 444 specification. The allowed values are to be intended as imported 445 from [RFC2579] apart from the fact that in this document there is 446 the need to use a milli-second resolution instead a deci-second 447 one. 448 o OperationResponseStatus - The type "OperationResponseStatus" is 449 used to report the result of an operation. The allowed values are 450 to be intended as imported from [I-D.ietf-disman-remops-mib-v2]. 452 5.2. Information Elements 454 This section describes the elements of the traceroute measurement. 455 The elements are grouped in two groups (Configuration and Results) 456 according to their semantics. In order to relate configuration and 457 results elements by means of a common unique identifier, an 458 additional element is defined belonging to both the two groups. 460 5.2.1. Configuration Information Elements 462 This section describes the elements of the traceroute measurement 463 that are specific to traceroute configuration. 465 5.2.1.1. traceRouteCtlTargetAddressType 467 o name - traceRouteCtlTargetAddressType 468 o description - Specifies the type of host address used in the 469 traceroute command. 470 o dataType - InetAddressType 471 o units - N/A 472 o default value - N/A 474 5.2.1.2. traceRouteCtlTargetAddress 476 o name - traceRouteCtlTargetAddress 477 o description - Specifies the host address used in the traceroute 478 command. The host address type can be determined by the examining 479 the value of the corresponding traceRouteCtlTargetAddressType. 480 o dataType - InetAddress 481 o units - N/A 482 o default value - N/A 484 5.2.1.3. traceRouteCtlByPassRouteTable 486 o name - traceRouteCtlByPassRouteTable 487 o description - Specifies if the optional bypassing of the route 488 table was enabled or not. If enabled, the traceroute will bypass 489 the normal routing tables and send directly to a host on an 490 attached network. If the host is not on a directly-attached 491 network, an error is returned. This option can be used to perform 492 the traceroute operation to a local host through an interface that 493 has no route defined. 494 o dataType - TruthValue 495 o units - N/A 496 o default value - false 498 5.2.1.4. traceRouteCtlProbeDataSize 500 o name - traceRouteCtlProbeDataSize 501 o description - Specifies the size of the data portion of a 502 traceroute operation in octets. If the RECOMMENDED traceroute 503 method (UDP datagrams as probes) is used, then the value contained 504 in this object is exact. If another traceroute method is used for 505 which the specified size is not appropriate, then the 506 implementation should have used whatever size (appropriate to the 507 method) is closest to the specified size. The maximum value for 508 this object was computed by substracting the smallest possible IP 509 header size of 20 octets (IPv4 header with no options) and the UDP 510 header size of 8 octets from the maximum IP packet size. An IP 511 packet has a maximum size of 65535 octets (excluding IPv6 512 Jumbograms). 514 o dataType - Unsigned32 515 o units - octects 516 o default value - 0 518 5.2.1.5. traceRouteCtlTimeOut 520 o name - traceRouteCtlTimeOut 521 o description - Specifies the time-out value, in seconds, for the 522 traceroute operation. 523 o dataType - Unsigned32 524 o units - seconds 525 o default value - 3 527 5.2.1.6. traceRouteCtlProbesPerHop 529 o name - traceRouteCtlProbesPerHop 530 o description - Specifies the number of times to reissue a 531 traceroute request with the same time-to-live (TTL) value. 532 o dataType - Unsigned32 533 o units - probes 534 o default value - 3 536 5.2.1.7. traceRouteCtlPort 538 o name - traceRouteCtlPort 539 o description - Specifies the base UDP port used by the traceroute 540 operation. Need to specify a port that is not in use at the 541 destination (target) host. The default value for this object is 542 the IANA assigned port, 33434, for the traceroute function. 543 o dataType - Unsigned32 544 o units - UDP Port 545 o default value - 33434 547 5.2.1.8. traceRouteCtlMaxTtl 549 o name - traceRouteCtlMaxTtl 550 o description - Specifies the maximum TTL value for the traceroute 551 operation. 552 o dataType - Unsigned32 553 o units - time-to-live value 554 o default value - 30 556 5.2.1.9. traceRouteCtlDSField 558 o name - traceRouteCtlDSField 559 o description - Specifies the value that was stored in the 560 Differentiated Services (DS) field in the IP packet used to 561 encapsulate the traceroute probe. The DS Field is defined as the 562 Type of Service (TOS) octet in a IPv4 header or as the Traffic 563 Class octet in a IPv6 header. The value of this object must be a 564 decimal integer in the range from 0 to 255. This option can be 565 used to determine what effect an explicit DS field setting has on 566 a traceroute response. Not all values are legal or meaningful. 567 DS field usage is often not supported by IP implementations. A 568 value of 0 means that the function represented by this option is 569 not supported. Useful TOS octet values are probably '16' (low 570 delay) and '8' (high throughput). Further references can be found 571 in [RFC2474] for the definition of the Differentiated Services 572 (DS) field and to [RFC1812] Section 5.3.2 for Type of Service 573 (TOS). 574 o dataType - Unsigned32 575 o units - N/A 576 o default value - 0 578 5.2.1.10. traceRouteCtlSourceAddressType 580 o name - traceRouteCtlSourceAddressType 581 o description - Specifies the type of the source address, 582 traceRouteCtlSourceAddress, used when performing the traceroute 583 operation. 584 o dataType - InetAddressType 585 o units - N/A 586 o default value - N/A 588 5.2.1.11. traceRouteCtlSourceAddress 590 o name - traceRouteCtlSourceAddress 591 o description - Specifies the IP address (which has to be given as 592 an IP number, not a hostname) as the source address used in 593 outgoing probe packets. On hosts with more than one IP address, 594 this option can be used to force the source address to be 595 something other than the primary IP address of the interface the 596 probe packet is sent on. A zero length octet string value for 597 this object means that source address specification was disabled. 598 The address type (InetAddressType) that relates to this object is 599 specified by the corresponding value of 600 traceRouteCtlSourceAddressType. 601 o dataType - InetAddress 602 o units - N/A 603 o default value - N/A 605 5.2.1.12. traceRouteCtlIfIndex 607 o name - traceRouteCtlIfIndex 608 o description - Specifies the inferface index used in the traceroute 609 operation for sending the traceroute probes. A value of zero for 610 this object implies that the interface was unknown. 611 o dataType - InterfaceIndexOrZero 612 o units - N/A 613 o default value - 0 615 5.2.1.13. traceRouteCtlMiscOptions 617 o name - traceRouteCtlMiscOptions 618 o description - Specifies implementation dependent options. 619 o dataType - String 620 o units - N/A 621 o default value - N/A 623 5.2.1.14. traceRouteCtlMaxFailures 625 o name - traceRouteCtlMaxFailures 626 o description - Specifies the maximum number of consecutive timeouts 627 allowed before terminating a traceroute operation. A value of 628 either 255 (maximum hop count/possible TTL value) or a 0 indicates 629 that the function of terminating a remote traceroute operation 630 when a specific number of consecutive timeouts are detected was 631 disabled. This element is included to give full compatibility 632 with [I-D.ietf-disman-remops-mib-v2]. No known implementation of 633 traceroute currently supports it. 634 o dataType - Unsigned32 635 o units - timeouts 636 o default value - 5 638 5.2.1.15. traceRouteCtlDontFragment 640 o name - traceRouteCtlDontFragment 641 o description - Specifies if the don't fragment flag (DF) in the IP 642 header for a probe was enabled or not. The use of the DF flag is 643 intended to be relative to a manual PATH MTU test. 644 o dataType - TruthValue 645 o units - N/A 646 o default value - false 648 5.2.1.16. traceRouteCtlInitialTtl 650 o name - traceRouteCtlInitialTtl 651 o description - Specifies the initial TTL value uses in a traceroute 652 operation. The use of initial TTL setting is intended to be used 653 when bypassing the initial (often well known) portion of a path is 654 to be achieved. 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. 674 o dataType - ProbesType 675 o units - N/A 676 o default value - UDP 678 5.2.2. Results Information Elements 680 This section describes the elements of the traceroute measurement 681 that are specific to the results of a traceroute operation. 683 5.2.2.1. traceRouteResultsStartDateAndTime 685 o name - traceRouteResultsStartDateAndTime 686 o description - Specifies the date and start time of the traceroute 687 operation. This is the time when the first probe was seen at the 688 sending interface. 689 o dataType - DateAndTime 690 o units - N/A 691 o default value - N/A 693 5.2.2.2. traceRouteResultsIpTgtAddrType 695 o name - traceRouteResultsIpTgtAddrType 696 o description - Specifies the type of address stored in the 697 corresponding traceRouteResultsIpTgtAddr element. 698 o dataType - InetAddressType 699 o units - N/A 700 o default value - N/A 702 5.2.2.3. traceRouteResultsIpTgtAddr 704 o name - traceRouteResultsIpTgtAddr 705 o description - Specifies the IP address associated with a 706 traceRouteCtlTargetAddress value when the destination address is 707 specified as a DNS name. The value of this object should be a 708 zero length octet string when a DNS name is not specified or when 709 a specified DNS name fails to resolve. 710 o dataType - InetAddress 711 o units - N/A 712 o default value - N/A 714 5.2.2.4. traceRouteResultsProbeIndex 716 o name - traceRouteResultsProbeIndex 717 o description - Specifies the progressive index of a probe within 718 the traceroute operation. The maximum value here is the number 719 resulting from the operation 720 traceRouteCtlMaxTtl*traceRouteCtlProbesPerHop. 721 o dataType - Unsigned32 722 o units - N/A 723 o default value - N/A 725 5.2.2.5. traceRouteResultsProbeHopIndex 727 o name - traceRouteResultsProbeHopIndex 728 o description - Specifies which hop in a traceroute path that the 729 probe's results are for. 730 o dataType - Unsigned32 731 o units - N/A 732 o default value - N/A 734 5.2.2.6. traceRouteResultsProbeIndexPerHop 736 o name - traceRouteResultsProbeIndexPerHop 737 o description - Specifies the index of a probe for a particular hop 738 in a traceroute path. The number of probes per hop is determined 739 by the value of the corresponding traceRouteCtlProbesPerHop 740 element. 741 o dataType - Unsigned32 742 o units - N/A 743 o default value - N/A 745 5.2.2.7. traceRouteResultsProbeHopAddrType 747 o name - traceRouteResultsProbeHopAddrType 748 o description - Specifies the type of address stored in the 749 corresponding traceRouteResultsProbeHopAddr element. 750 o dataType - InetAddressType 751 o units - N/A 752 o default value - N/A 754 5.2.2.8. traceRouteResultsProbeHopAddr 756 o name - traceRouteResultsProbeHopAddr 757 o description - Specifies the address of a hop in the traceroute 758 path. This object is not allowed to be a DNS name. The value of 759 the corresponding object, traceRouteResultsProbeHopAddrType, 760 indicates this object's IP address type. 761 o dataType - InetAddress 762 o units - N/A 763 o default value - N/A 765 5.2.2.9. traceRouteResultsProbeHopGeoLocation 767 o name - traceRouteResultsProbeHopGeoLocation 768 o description - Specifies the geo location of a hop in the 769 traceroute path. 770 o dataType - String 771 o units - N/A 772 o default value - N/A 774 5.2.2.10. traceRouteResultsProbeMPLSLabelStack 776 o name - traceRouteResultsProbeMPLSLabelStack 777 o description - Specifies the MPLS label stack of a probe in the 778 traceroute path. This object contains the "label stack entries" 779 Label, Exp and S as a single number. 780 o dataType - Unsigned32 781 o units - N/A 782 o default value - N/A 784 5.2.2.11. traceRouteResultsProbeRoundTripTime 786 o name - traceRouteResultsProbeRoundTripTime 787 o description - Specifies the amount of time measured in 788 milliseconds from when a probe was sent to when its response was 789 received or when it timed out. The value of this element is 790 reported as the truncation of the number reported by the 791 traceroute tool (the output "< 1 ms" is therefore encoded as 0 792 ms). A string with the value of "RoundTripTimeNotAvailable" means 793 either the probe was lost because of a timeout or it was not 794 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 [I-D.ietf-disman-remops-mib-v2], that specifies 874 a BER encoding [RFC3417] used by the Simple Network Management 875 Protocol (SNMP) [RFC3410] for transmitting traceroute information. 876 This data model is well suited and supported within network 877 management systems, but as a general format for storing and 878 transmitting traceroute results 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 [I-D.ietf- 882 ipfix-protocol], [I-D.ietf-ipfix-info]. The IPFIX protocol is 883 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 939 940 942 943 944 945 946 948 949 950 953 954 956 957 958 960 961 963 964 965 966 967 969 970 971 973 974 975 976 977 978 979 980 981 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 999 1000 1001 1003 1004 1005 1006 1007 1009 1010 1011 Specifies the name of a traceroute 1012 test. This is locally unique. 1013 1014 1015 1016 1017 1018 1020 1021 1022 Specifies the name of the operating 1023 system on which the traceroute was launched. 1024 1025 1026 1027 1028 1029 1031 1032 1033 Specifies the OS version on which the 1034 traceroute was launched. 1036 1037 1038 1039 1040 1041 1043 1044 1045 Specifies the version of the traceroute 1046 tool used. 1047 1048 1049 1050 1051 1052 1054 1055 1056 Specifies if the optional bypassing 1057 of the route table was enabled or not. If enabled, 1058 the traceroute will bypass the normal routing tables 1059 and send directly to a host on an attached network. 1060 If the host is not on a directly-attached network, 1061 an error is returned. This option can be used to 1062 perform the traceroute operation to a local host 1063 through an interface that has no route defined. 1064 1065 1066 1067 1069 1070 1071 Specifies the size of the data 1072 portion of a traceroute operation in octets. If the 1073 RECOMMENDED traceroute method (UDP datagrams as probes) 1074 is used, then the value contained in this object is 1075 exact. If another traceroute method is used for which 1076 the specified size is not appropriate, then the 1077 implementation should have used whatever size (appropriate 1078 to the method) is closest to the specified size. 1079 The maximum value for this object was computed by 1080 substracting the smallest possible IP header size of 20 1081 octets (IPv4 header with no options) and the UDP header 1082 size of 8 octets from the maximum IP packet size. An IP 1083 packet has a maximum size of 65535 octets (excluding IPv6 1084 jumbograms). Units are: octects. 1085 1086 1087 1088 1089 1090 1092 1093 1094 Specifies the time-out value, in 1095 seconds, for the traceroute operation. 1096 Units are: seconds. 1097 1098 1099 1100 1101 1102 1103 1105 1106 1107 Specifies the number of times to 1108 reissue a traceroute request with the same time-to-live 1109 (TTL) value. Units are: probes. 1110 1111 1112 1113 1114 1115 1116 1118 1119 1120 Specifies the base UDP port used by 1121 the traceroute operation. Need to specify a port that 1122 is not in use at the destination (target) host. 1123 The default value for this object is the IANA assigned 1124 port, 33434, for the traceroute function. 1125 Units are: UDP port. 1126 1127 1128 1129 1130 1131 1132 1133 1134 Specifies the maximum TTL value for 1135 the traceroute operation. 1136 Units are: time-to-live value. 1137 1138 1139 1140 1141 1142 1144 1145 1146 Specifies the value that was stored in 1147 the Differentiated Services (DS) field in the IP packet 1148 used to encapsulate the traceroute probe. The DS Field 1149 is defined as the Type of Service (TOS) octet in a IPv4 1150 header or as the Traffic Class octet in a IPv6 header. 1151 The value of this object must be a decimal integer in the 1152 range from 0 to 255. This option can be used to determine 1153 what effect an explicit DS field setting has on a 1154 traceroute response. Not all values are legal or 1155 meaningful. DS field usage is often not supported by IP 1156 implementations. A value of 0 means that the function 1157 represented by this option is not supported. Useful TOS 1158 octet values are probably '16' (low delay) and '8' (high 1159 throughput). Further references can be found in the 1160 RFC 2474 for the definition of the Differentiated 1161 Services (DS) field and to the RFC 1812 Section 5.3.2 1162 for Type of Service (TOS). 1163 1164 1165 1166 1168 1169 1170 Specifies the inferface index used in the 1171 traceroute operation for sending the traceroute 1172 probes. A value of zero for this object implies 1173 that the interface was unknown. 1174 1175 1176 1177 1179 1180 1181 Specifies implementation dependent 1182 options. 1183 1184 1185 1186 1187 1189 1190 1191 Specifies the maximum number of 1192 consecutive timeouts allowed before terminating a 1193 traceroute operation. A value of either 255 1194 (maximum hop count/possible TTL value) or a 0 indicates 1195 that the function of terminating a remote traceroute 1196 operation when a specific number of consecutive 1197 timeouts are detected was disabled. This element is 1198 included to give full compatibility with DISMAN working 1199 group documents. No known implementation of traceroute 1200 currently supports it. 1201 Units are: timeouts. 1202 1203 1204 1205 1207 1208 1209 Specifies if the don't fragment flag 1210 (DF) in the IP header for a probe was enabled or not. 1211 The use of the DF flag is intended to be relative to a 1212 manual PATH MTU test. 1213 1214 1215 1216 1218 1219 1220 Specifies the initial TTL value uses 1221 in a traceroute operation. The use of initial TTL 1222 setting is intended to be used when bypassing the 1223 initial (often well known) portion of a path is to be 1224 achieved. 1225 1226 1227 1228 1229 1230 1232 1233 1234 The purpose of this element is to 1235 provide a description of the traceroute test. 1236 1237 1238 1239 1240 1241 1243 1244 1245 Specifies the implementation method 1246 used for the traceroute operation. 1247 1248 1249 1250 1251 1252 1253 1254 1256 1257 1258 Specifies the progressive index of 1259 a probe within the traceroute operation. The maximum 1260 value here is the number resulting from the operation 1261 traceRouteCtlMaxTtl*traceRouteCtlProbesPerHop. 1262 1263 1264 1265 1266 1267 1268 1270 1271 1272 Specifies which hop in a traceroute 1273 path that the probe's results are for. The value of 1274 this element is initially determined by the value of 1275 traceRouteCtlInitialTtl. 1277 1278 1279 1280 1281 1282 1284 1285 1286 Specifies the index of a probe for 1287 a particular hop in a traceroute path. The number of 1288 probes per hop is determined by the value of the 1289 corresponding traceRouteCtlProbesPerHop element. 1290 1291 1292 1293 1294 1295 1296 1298 1299 1300 Specifies the geo location of a hop 1301 in the traceroute path. 1302 1303 1304 1305 1306 1307 1309 1310 1311 Specifies the MPLS label stack of a 1312 probe in the traceroute path. This object contains the 1313 "label stack entries" Label, Exp and S as a single 1314 24 bit number. 1315 1316 1317 1318 1319 1320 1322 1323 1324 1326 1327 1329 1330 1331 1332 1333 1335 1336 1337 Specifies the raw output data returned 1338 by the traceroute operation for a certain hop in a 1339 traceroute path. 1340 1341 1342 1343 1344 1345 1347 1348 1349 Specifies the AS number of a hop in the 1350 traceroute path as a 24 bit number and the indication how 1351 the mapping from IP address to AS number was performed. 1352 1353 1354 1356 1358 1359 1361 1362 1363 1365 1367 1369 1371 1373 1375 1377 1378 1379 1381 1383 1385 1387 1389 1390 1392 1393 1394 1396 1398 1399 1401 1402 1403 Specifies the type of host address 1404 used in the traceroute command. 1405 1406 1407 1408 1410 1411 1413 1414 1415 Specifies the host address used in 1416 the traceroute command. The host address type can be 1417 determined by the examining the value of the 1418 corresponding traceRouteCtlTargetAddressType. 1419 1420 1421 1422 1424 1425 1427 1428 1429 Specifies the type of the source address, 1430 traceRouteCtlSourceAddress, used when performing the 1431 traceroute operation. 1432 1433 1434 1435 1437 1438 1440 1441 1442 Specifies the IP address (which has 1443 to be given as an IP number, not a hostname) as the 1444 source address used in outgoing probe packets. On hosts 1445 with more than one IP address, this option can be used 1446 to force the source address to be something other than 1447 the primary IP address of the interface the probe packet 1448 is sent on. A zero length octet string value for this 1449 object means that source addres specification was disabled. 1450 The address type (InetAddressType) that relates to this 1451 object is specified by the corresponding value of 1452 traceRouteCtlSourceAddressType. 1453 1454 1455 1456 1458 1459 1461 1462 1463 Specifies the date and start time of the 1464 traceroute operation. This is the time when the first probe 1465 was sent. 1466 1467 1468 1469 1470 1471 1472 1473 1474 Specifies the type of address stored 1475 in the corresponding traceRouteResultsIpTgtAddr element. 1476 1477 1478 1479 1481 1482 1484 1485 1486 Specifies the IP address associated 1487 with a traceRouteCtlTargetAddress value when the 1488 destination address is specified as a DNS name. 1489 The value of this object should be a zero length octet 1490 string when a DNS name is not specified or when a 1491 specified DNS name fails to resolve. 1492 1493 1494 1495 1497 1498 1500 1501 1502 Specifies the type of address stored 1503 in the corresponding traceRouteResultsProbeHopAddr 1504 element. 1505 1506 1507 1508 1510 1511 1513 1514 1515 Specifies the address of a hop in 1516 the traceroute path. This object is not allowed to 1517 be a DNS name. The value of the corresponding object, 1518 traceRouteResultsProbeHopAddrType, indicates this 1519 object's IP address type. 1521 1522 1523 1524 1526 1527 1529 1530 1531 Specifies the amount of time measured 1532 in milliseconds from when a probe was sent to when its 1533 response was received or when it timed out. The value 1534 of this element is reported as the truncation of the 1535 number reported by the traceroute tool (the output 1536 "<1 ms" is therefore encoded as 0 ms). 1537 A string with the value of "RoundTripTimeNotAvailable" 1538 means either the probe was lost because of a timeout 1539 or it was not possible to transmit a probe. 1540 Units are: milliseconds. 1541 1542 1543 1544 1546 1548 1549 1551 1552 1553 Specifies the result of a traceroute 1554 operation made by the host for a particular probe. 1555 1556 1557 1558 1560 1561 1563 1564 1565 Specifies the timestamp when the 1566 response to the probe was received. 1567 1568 1569 1570 1571 1572 1574 1575 1576 1578 1580 1582 1584 1586 1589 1592 1594 1596 1598 1599 1601 1602 1603 Specifies the date and end time of 1604 the traceroute operation. It is either the time when 1605 the response to the last probe of the traceroute 1606 operation was received or the time when the last 1607 probe of the traceroute operation was sent plus the 1608 relative timeout (in case of missing response). 1609 1610 1611 1612 1613 1614 1616 1617 1618 Specifies the metadata for a 1619 traceroute operation. In a request, these are the 1620 requested parameters. In a response, they are the 1621 actual parameters used. 1622 1623 1624 1625 1627 1630 1633 1636 1638 1640 1644 1647 1650 1653 1656 1659 1662 1664 1666 1669 1672 1675 1678 1681 1684 1688 1689 1691 1692 1693 1694 Contains the actual traceroute measurement. 1695 1696 1697 1698 1700 1702 1704 1706 1709 1712 1714 1715 1717 1718 1719 1720 1722 1723 1724 1726 1727 1728 1730 1731 1732 1734 1736 1737 1738 1740 1742 1743 1744 1746 1748 1749 1750 1752 1754 1756 1757 1758 1760 1761 1763 1765 8. Security Considerations 1767 Security considerations in this section discuss are grouped into 1768 considerartions related to conducting traceroute measurements and 1769 considerations related to storing and transmitting results of 1770 measurements. 1772 This memo does not specify an implementation of a traceroute 1773 measurements. Neither does it specify a certain procedure for 1774 storing traceroute measurement results. Still it is considered 1775 desirable to discuss related security issues below. 1777 8.1. Conducting Traceroute Measurements 1779 Conducting Internet measurements can raise both security and privacy 1780 concerns. Traceroute measurements, in which traffic is injected into 1781 the network, can be abused for denial-of-service attacks disguised as 1782 legitimate measurement activity. 1784 Measurement parameters MUST be carefully selected so that the 1785 measurements inject trivial amounts of additional traffic into the 1786 networks they measure. If they inject "too much" traffic, they can 1787 skew the results of the measurement, and in extreme cases cause 1788 congestion and denial of service. 1790 The measurements themselves could be harmed by routers giving 1791 measurement traffic a different priority than "normal" traffic, or by 1792 an attacker injecting artificial measurement traffic. If routers can 1793 recognize measurement traffic and treat it separately, the 1794 measurements will not reflect actual user traffic. If an attacker 1795 injects artificial traffic that is accepted as legitimate, the loss 1796 rate will be artificially lowered. Therefore, the measurement 1797 methodologies SHOULD include appropriate techniques to reduce the 1798 probability measurement traffic can be distinguished from "normal" 1799 traffic. 1801 Authentication techniques, such as digital signatures, may be used 1802 where appropriate to guard against injected traffic attacks. 1804 8.2. Securing Traceroute Measurement Results 1806 Traceroute results are not considered highly sensible. Still, they 1807 may contain sensible information on network paths, routing states, 1808 use IP addresses, and roundtrip times, that the operator a networks 1809 may want to detect for business or security reasons. 1811 It is thus important to control access to Information acquired by 1812 conducting traceroute measurement, particularly when transmitting it 1813 over a networks but also when storing it. It is RECOMMENDED that 1814 transmission of traceroute measurement results over a network uses 1815 appropriate protection mechanisms for preserving privacy, integrity 1816 and authenticity. It is further RECOMMENDED that secure 1817 authentication and authorization are used for protecting stored 1818 traceroute results. 1820 9. IANA Considerations 1822 This document uses URNs to describe an XML namespace and an XML 1823 schema for trceroute measurements conforming to a registry mechanism 1824 described in [RFC3688]. Two URI assignments are requested. 1825 1. Registration request for the IPPM traceroute measurements 1826 namespace 1827 * URI: urn:ietf:params:xml:ns:traceroute-1.0 1828 * Registrant Contact: TBD. 1829 * XML: None. Namespace URIs do not represent an XML 1830 2. Registration request for the IPPM traceroute measurements schema 1831 * URI: urn:ietf:params:xml:schema:traceroute-1.0 1832 * Registrant Contact: TBD. 1833 * XML: See the section Section 7 of this document. 1835 10. Open Issues 1837 This section is intended to keep track of the open issues that are to 1838 be discussed in the IPPM working group. 1840 o Create a section where conflicts and differences to [I-D.ietf- 1841 disman-remops-mib-v2] are listed. 1843 11. References 1845 11.1. Normative References 1847 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1848 Schoenwaelder, "Textual Conventions for Internet Network 1849 Addresses", RFC 4001, February 2005. 1851 11.2. Informative References 1853 [I-D.ietf-disman-remops-mib-v2] 1854 Quittek, J. and K. White, "Definitions of Managed Objects 1855 for Remote Ping, Traceroute, and Lookup Operations", 1856 draft-ietf-disman-remops-mib-v2-09 (work in progress), 1857 February 2006. 1859 [I-D.ietf-ipfix-architecture] 1860 Sadasivan, G., "Architecture for IP Flow Information 1861 Export", draft-ietf-ipfix-architecture-10 (work in 1862 progress), May 2006. 1864 [I-D.ietf-ipfix-info] 1865 Quittek, J., "Information Model for IP Flow Information 1866 Export", draft-ietf-ipfix-info-11 (work in progress), 1867 September 2005. 1869 [I-D.ietf-ipfix-protocol] 1870 Claise, B., "IPFIX Protocol Specification", 1871 draft-ietf-ipfix-protocol-21 (work in progress), 1872 April 2006. 1874 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1875 RFC 1812, June 1995. 1877 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1878 "Definition of the Differentiated Services Field (DS 1879 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1880 December 1998. 1882 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1883 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1884 STD 58, RFC 2579, April 1999. 1886 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1887 MIB", RFC 2863, June 2000. 1889 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1890 "Introduction and Applicability Statements for Internet- 1891 Standard Management Framework", RFC 3410, December 2002. 1893 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 1894 Management Protocol (SNMP)", STD 62, RFC 3417, 1895 December 2002. 1897 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1898 January 2004. 1900 [XML] Yergeau et al., F., "Extensible Markup Language (XML) 1.0 1901 (Third Edition)", W3C Recommendation, February 2004. 1903 Authors' Addresses 1905 Saverio Niccolini 1906 Network Laboratories, NEC Europe Ltd. 1907 Kurfuersten-Anlage 36 1908 Heidelberg 69115 1909 Germany 1911 Phone: +49 (0) 6221 4342 118 1912 Email: saverio.niccolini@netlab.nec.de 1913 URI: http://www.netlab.nec.de 1915 Sandra Tartarelli 1916 Network Laboratories, NEC Europe Ltd. 1917 Kurfuersten-Anlage 36 1918 Heidelberg 69115 1919 Germany 1921 Phone: +49 (0) 6221 4342 132 1922 Email: sandra.tartarelli@netlab.nec.de 1923 URI: http://www.netlab.nec.de 1925 Juergen Quittek 1926 Network Laboratories, NEC Europe Ltd. 1927 Kurfuersten-Anlage 36 1928 Heidelberg 69115 1929 Germany 1931 Phone: +49 (0) 6221 4342 115 1932 Email: quittek@netlab.nec.de 1933 URI: http://www.netlab.nec.de 1935 Martin Swany 1936 Dept. of Computer and Information Sciences, University of Delaware 1937 Newark DE 19716 1938 U.S.A. 1940 Email: swany@UDel.Edu 1942 Intellectual Property Statement 1944 The IETF takes no position regarding the validity or scope of any 1945 Intellectual Property Rights or other rights that might be claimed to 1946 pertain to the implementation or use of the technology described in 1947 this document or the extent to which any license under such rights 1948 might or might not be available; nor does it represent that it has 1949 made any independent effort to identify any such rights. Information 1950 on the procedures with respect to rights in RFC documents can be 1951 found in BCP 78 and BCP 79. 1953 Copies of IPR disclosures made to the IETF Secretariat and any 1954 assurances of licenses to be made available, or the result of an 1955 attempt made to obtain a general license or permission for the use of 1956 such proprietary rights by implementers or users of this 1957 specification can be obtained from the IETF on-line IPR repository at 1958 http://www.ietf.org/ipr. 1960 The IETF invites any interested party to bring to its attention any 1961 copyrights, patents or patent applications, or other proprietary 1962 rights that may cover technology that may be required to implement 1963 this standard. Please address the information to the IETF at 1964 ietf-ipr@ietf.org. 1966 Disclaimer of Validity 1968 This document and the information contained herein are provided on an 1969 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1970 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1971 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1972 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1973 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1974 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1976 Copyright Statement 1978 Copyright (C) The Internet Society (2006). This document is subject 1979 to the rights, licenses and restrictions contained in BCP 78, and 1980 except as set forth therein, the authors retain all their rights. 1982 Acknowledgment 1984 Funding for the RFC Editor function is currently provided by the 1985 Internet Society.