idnits 2.17.1
draft-niccolini-ippm-storetraceroutes-03.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 1975.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1952.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1959.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1965.
** 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 476: '... octets. If the RECOMMENDED tracerout...'
RFC 2119 keyword, line 1095: '... RECOMMENDED traceroute me...'
RFC 2119 keyword, line 1779: '...asurement parameters MUST be carefully...'
RFC 2119 keyword, line 1791: '... SHOULD include appropriate techniqu...'
RFC 2119 keyword, line 1804: '...being registered MUST have been throug...'
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- 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 (March 5, 2006) is 6599 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)
-- Looks like a reference, but probably isn't: '1-9' on line 1020
-- Looks like a reference, but probably isn't: '0-9' on line 1021
-- Looks like a reference, but probably isn't: '0-4' on line 1021
-- Looks like a reference, but probably isn't: '0-5' on line 1021
** Obsolete normative reference: RFC 3291 (ref. '1') (Obsoleted by RFC 4001)
** Obsolete normative reference: RFC 2925 (ref. '6') (Obsoleted by RFC 4560)
== Outdated reference: A later version (-09) exists of
draft-ietf-disman-remops-mib-v2-06
** Downref: Normative reference to an Informational RFC: RFC 3410 (ref.
'10')
** Downref: Normative reference to an Informational RFC: RFC 3954 (ref.
'11')
== Outdated reference: A later version (-26) exists of
draft-ietf-ipfix-protocol-17
== Outdated reference: A later version (-15) exists of
draft-ietf-ipfix-info-09
== Outdated reference: A later version (-01) exists of
draft-stephan-isp-templates-00
-- Possible downref: Normative reference to a draft: ref. '14'
-- Possible downref: Non-RFC (?) normative reference: ref. '15'
Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 13 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: September 6, 2006 J. Quittek
5 NEC
6 M. Swany
7 UDel
8 March 5, 2006
10 How to store traceroute measurements and related metrics
11 draft-niccolini-ippm-storetraceroutes-03
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 September 6, 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 and related metrics. To better address the traceroute measurements
46 storing issue, the authors first of all give a definition of the
47 traceroute tool, describe the tool itself as well as its parameters
48 and the default values on the most common operating systems and the
49 output results that can be stored. Afterwards, the common
50 information model with the base elements of the traceroute
51 measurement storing is defined dividing the information elements in
52 two semantically separated groups (configuration elements and results
53 ones). Moreover an additional element is defined to relate
54 configuration elements and results ones by means of a common unique
55 identifier. On the basis of the information model a data model is
56 then proposed in order to actually store the traceroute measurements.
57 Finally considerations on how to extract relevant metrics related to
58 traceroute measurements are given.
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
64 2. Definition of traceroute . . . . . . . . . . . . . . . . . . . 5
65 2.1. Traceroute configuration parameters . . . . . . . . . . . 5
67 3. Known problems with traceroute . . . . . . . . . . . . . . . . 9
69 4. Reports/results . . . . . . . . . . . . . . . . . . . . . . . 10
71 5. Information model for storing traceroutes measurements . . . . 11
72 5.1. Data types . . . . . . . . . . . . . . . . . . . . . . . . 11
73 5.2. Information Elements . . . . . . . . . . . . . . . . . . . 12
74 5.2.1. Configuration Information Elements . . . . . . . . . . 12
75 5.2.2. Results Information Elements . . . . . . . . . . . . . 18
76 5.2.3. Information Element correlating configuration and
77 results elements . . . . . . . . . . . . . . . . . . . 23
79 6. Data model for storing traceroutes measurements . . . . . . . 24
80 6.1. XML schema for traceroute measurements . . . . . . . . . . 25
81 6.2. Design considerations . . . . . . . . . . . . . . . . . . 40
83 7. Metrics considerations for traceroute measurements . . . . . . 41
85 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 42
87 9. Security considerations . . . . . . . . . . . . . . . . . . . 43
89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
91 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 45
93 12. Normative References . . . . . . . . . . . . . . . . . . . . . 45
95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
96 Intellectual Property and Copyright Statements . . . . . . . . . . 48
98 1. Introduction
100 Traceroutes are being used by lots of measurement efforts, either as
101 an independent measurement or to get path information to support
102 other measurement efforts. That is why there is the need to
103 standardize the way traceroute measurements are stored and the
104 related metrics associated with such measurements. Since traceroute
105 is a tool that has built-in configurable mechanisms like time-outs
106 and can experience problems related to the crossing of firewalls thus
107 experiencing fake losses or incomplete delay information, the
108 standard metrics defined by IPPM working group in matter of delay,
109 connectivity and losses may not be complete enough to define
110 univocally the metrics retrieved by the traceroute tool. In such a
111 context, already standardized metrics have to be closely examined in
112 order to check for their applicability. Moreover there is a need to
113 better define the traceroute tool as well as its parameters and the
114 results it outputs since, to the authors' knowledge, there is so far
115 no standard describing these. These are the motivations that moved
116 the authors to write this draft in the context of the IPPM working
117 group even if other working groups (like DISMAN) have already
118 addressed similar issues related to the definition of the MIB for
119 configuring and retrieving traceroute measurements results. The rest
120 of the draft is organised as follows: Section 2 gives the definition
121 of traceroute used as reference in the rest of the draft as well as
122 the traceroute configurable parameters and their default values for
123 the most common operating systems. Section 3 reports on both known
124 problems of traceroute and existing alternatives. Section 4
125 describes the results available from the traceroute output screen.
126 Section 5 and Section 6 respectively describe our proposed
127 Information model and Data model for storing traceroute measurements.
128 Section 7 reports on considerations on how to extract relevant
129 metrics related to traceroute measurements while Section 8 gives our
130 conclusions. The draft ends with security considerations, IANA
131 considerations and open issues in Section 9, Section 10 and
132 Section 11 respectively.
134 2. Definition of traceroute
136 Traceroute is a network diagnostic tool used to determine the hop by
137 hop path from a source to a destination and the Round Trip Time (RTT)
138 from the source to each hop. Traceroute can therefore be used to
139 discover where and how a host is connected to the Internet and can be
140 usefully employed to troubleshoot network connections.
142 Typically, traceroute attemps to discover the path to a destination
143 by sending UDP probes with specific time-to-live (TTL) values in the
144 IP packet header and trying to elicit an ICMP TIME_EXCEEDED response
145 from each gateway along the path to some host.
147 More in detail, the host running the traceroute sends the first set
148 of probes with TTL equal to one (some implementations allow setting
149 the initial TTL to a value equal to "n" different from one, so that
150 the first "n-1" hops are skipped and the first hop that will be
151 traced is the "n-th" in the path). Upon receiving a probe, the first
152 hop host decreases the TTL value by one. By observing a TTL value
153 equal to zero, the host rejects the probe and typically returns an
154 ICMP message with a TIME_EXCEEDED value. Traceroute can therefore
155 derive the IP address of the first hop from the header of the ICMP
156 message and evaluate the RTT between the source and the first hop.
157 The next hops are discovered following the same procedure, taking
158 care of increasing at each step the TTL value of the outgoing probes
159 by one. The TTL value is increased until either an ICMP
160 PORT_UNREACHABLE message is received, meaning that the destination
161 has been reached, or the maximum configured number of hops has been
162 hit.
164 Some implementations, use ICMP Echos, instead of UDP datagrams.
165 However, many routers do not return ICMP messages about ICMP
166 messages, i.e. no ICMP TIME_EXCEEDED is returned for an ICMP Echo.
167 Therefore, in this draft we RECOMMEND to base implementations on UDP
168 datagrams.
170 2.1. Traceroute configuration parameters
172 In order to define an information model for storing traceroutes, we
173 first investigated which configuration parameters are relevant when
174 running traceroute. We considered three major traceroute
175 implementations and compared them based on configurable parameters
176 and default values. The LINUX (SUSE 9.1) and UNIX (multiple
177 platform) implemetations are based on UDP datagrams, while the
178 WINDOWS (XP SP2) one uses ICMP Echos. The following table summarizes
179 such comparison. A N/A in the option column, means that such option
180 is not configurable for the specific implementation.
182 +---------------------------------------------------------+
183 | OS |Option| Description | Default |
184 +-------+------+--------------------------------+---------+
185 | LINUX | -m |Specify the maximum TTL used | 30 |
186 |-------+------|in outgoing probes. |---------|
187 | UNIX | -m | | 30 |
188 |-------+------| |---------|
189 |WINDOWS| -h | | 30 |
190 +-------+------+--------------------------------+---------+
191 | LINUX | -n |Display hop addresses | - |
192 |-------+------|numerically rather than |---------|
193 | UNIX | -n |simbolically. | - |
194 |-------+------| |---------|
195 |WINDOWS| -d | | - |
196 +-------+------+--------------------------------+---------+
197 | LINUX | -w |Set the time to wait for a | 3 sec |
198 |-------+------|response to a probe. |---------|
199 | UNIX | -w | | 5 sec |
200 |-------+------| |---------|
201 |WINDOWS| -w | | 4 sec |
202 +-------+------+--------------------------------+---------+
203 | LINUX | N/A |Specify a loose source route | - |
204 |-------+------|gateway (to direct the |---------|
205 | UNIX | -g |traceroute through routers not | - |
206 |-------+------|necessarily in the path). |---------|
207 |WINDOWS| -g | | - |
208 +-------+------+--------------------------------+---------+
209 | LINUX | -p |Set the base UDP port number | 33434 |
210 |-------+------|used in probes |---------|
211 | UNIX | -p |(UDP port = base + nhops - 1). | 33434 |
212 |-------+------| |---------|
213 |WINDOWS| N/A | | - |
214 +-------+------+--------------------------------+---------+
215 | LINUX | -q |Set the number of probes per | 3 |
216 |-------+------|TTL. |---------|
217 | UNIX | -q | | 3 |
218 |-------+------| |---------|
219 |WINDOWS| N/A | | 3 |
220 +-------+------+--------------------------------+---------+
221 | LINUX | -s |Set the IP source address in |IP |
222 |-------+------|outgoing probes to the specified|address |
223 | UNIX | -s |value. |of the |
224 |-------+------| |out |
225 |WINDOWS| N/A | |interface|
226 +-------+------+--------------------------------+---------+
227 | LINUX | -t |Set the type-of-service (TOS) | 0 |
228 |-------+------|in the probes to the specified |---------|
229 | UNIX | -t |value. | 0 |
230 |-------+------| |---------|
231 |WINDOWS| N/A | | 0 |
232 +-------+------+--------------------------------+---------+
233 | LINUX | -v |Verbose output: received ICMP | - |
234 |-------+------|packets other than TIME_EXCEEDED|---------|
235 | UNIX | -v |and UNREACHABLE are listed. | - |
236 |-------+------| |---------|
237 |WINDOWS| N/A | | - |
238 +-------+------+--------------------------------+---------+
239 | LINUX | -l |Display the TTL value of | - |
240 |-------+------|returned packets. This is useful|---------|
241 | UNIX | N/A |for checking for asymmetric | - |
242 |-------+------|routing. |---------|
243 |WINDOWS| N/A | | - |
244 +-------+------+--------------------------------+---------+
245 | LINUX | -r |Bypass the normal routing tables| - |
246 |-------+------|and send directly to a host on |---------|
247 | UNIX | -r |attached network. | - |
248 |-------+------| |---------|
249 |WINDOWS| N/A | | - |
250 +-------+------+--------------------------------+---------+
251 | LINUX | N/A |Set the initial TTL for the | 1 |
252 |-------+------|first probe. |---------|
253 | UNIX | -f | | 1 |
254 |-------+------| |---------|
255 |WINDOWS| N/A | | 1 |
256 +-------+------+--------------------------------+---------+
257 | LINUX | N/A |Set the "don't fragment" bit. | - |
258 |-------+------| |---------|
259 | UNIX | -F | | - |
260 |-------+------| |---------|
261 |WINDOWS| N/A | | - |
262 +-------+------+--------------------------------+---------+
263 | LINUX | N/A |Enables socket level debugging. | - |
264 |-------+------| |---------|
265 | UNIX | -d | | - |
266 |-------+------| |---------|
267 |WINDOWS| N/A | | - |
268 +-------+------+--------------------------------+---------+
269 | LINUX | N/A |Use ICMP ECHO instead of UDP | - |
270 |-------+------|datagrams. |---------|
271 | UNIX | -I | | - |
272 |-------+------| |---------|
273 |WINDOWS| N/A | | - |
274 +-------+------+--------------------------------+---------+
275 | LINUX | N/A |Specify a network interface to | - |
276 |-------+------|obtain the IP address for |---------|
277 | UNIX | -i |outgoing IP packets (alternative| - |
278 |-------+------|to option -s). |---------|
279 |WINDOWS| N/A | | - |
280 +-------+------+--------------------------------+---------+
281 | LINUX | N/A |Toggle checksum. | - |
282 |-------+------| |---------|
283 | UNIX | -x | | - |
284 |-------+------| |---------|
285 |WINDOWS| N/A | | - |
286 +-------+------+--------------------------------+---------+
287 | LINUX | - |As optional last paramater, |Depends |
288 |-------+------|LINUX and UNIX implementations |on |
289 | UNIX | - |allow specifying the probe |implement|
290 |-------+------|datagram length for outgoing |ation. |
291 |WINDOWS| N/A |probes. | |
292 +-------+------+--------------------------------+---------+
294 3. Known problems with traceroute
296 The widespred use of firewalls might prevent UDP or ICMP based
297 traceroutes to completely trace the path to a destination, since
298 traceroute probes might end up being filtered. In some cases, such
299 limitation might be overcome by sending instead TCP packets to
300 specific ports that hosts located behind the firewall are listening
301 for connections on. TCP based implementations use TCP SYN or FYN
302 probes and listen for TIME_EXCEEDED messages, TCP RESET and other
303 messages from firewalls and gateways on the path. On the other hand,
304 some firewalls filter out TCP SYN packets to prevent denial of
305 service attacks, therefore the actual advantage of using TCP instead
306 of UDP traceroute depends mainly on firewall configurations, which
307 are not known in adavance. A detailed analysis of TCP based
308 traceroutes is outside the scope of this draft, therefore in the
309 sequel, we will restrict our focus to the most commonly implemented
310 UDP based traceroute.
312 4. Reports/results
314 The following list reports the information fields provided by all
315 traceroute implementations considered. The order in which they are
316 reported here is not relevant and it changes in different
317 implementations. For each hop the information reported is:
319 o the hop index;
321 o the host symbolical address, provided that at least one of the
322 probes received a response, the symbolic address could be resolved
323 at the correponding host and that the option to display only
324 numerical addresses was not set;
326 o the host IP address, provided that at least one of the probes
327 received a response;
329 o the RTT for each response to a probe.
331 Depending on the traceroute implementation, additional information
332 might be displayed in the output (for instance MPLS-related
333 information).
335 It might happen that some probes do not receive a response within the
336 configured time-out (for instance if the probe is filtered out by a
337 firewall). In this case, an "*" is displayed in place of the RTT.
338 Besides, for delays below 1 ms, some implementations reports 0 ms
339 (f.i. UNIX and LINUX) while WINDOWS tracert reports "< 1 ms".
341 5. Information model for storing traceroutes measurements
343 This section describes the information model for the traceroute
344 measurements data storing. The information model is composed of
345 information elements; for defining these information elements, a
346 template is used. Such template is specified in the list below:
348 o name - A unique and meaningful name for the information element.
349 The preferred spelling for the name is to use mixed case if the
350 name is compound, with an initial lower case letter, e.g.,
351 "sourceIpAddress".
353 o description - The semantics of this information element.
355 o dataType - One of the types listed in Section 5.1 of this document
356 or in an extension of the information model. The type space for
357 attributes is constrained to facilitate implementation.
359 o units - If the element is a measure of some kind, the units
360 identify what the measure is.
362 o default value - The default value for the element (where
363 applicable).
365 5.1. Data types
367 This section describes the set of valid data types of the information
368 model.
370 o String - The type "String" represents a finite length string of
371 valid characters from the Unicode character encoding set. Unicode
372 allows for ASCII and many other international character sets to be
373 used. It is expected that strings will be encoded in UTF-8
374 format, which is identical in encoding for USASCII characters, but
375 also accomodates other Unicode multibyte characters.
377 o InetAddressType - The type "InetAddressType" represents a type of
378 Internet address. The allowed values are to be intended as
379 imported from [1].
381 o InetAddress - The type "InetAddress" denotes a generic Internet
382 address. The allowed values are to be intended as imported from
383 [1].
385 o TruthValue - The type "TruthValue" represents a boolean value.
386 The allowed values are to be intended as imported from [2].
388 o Unsigned32 - The type "Unsigned32" represents a value in the range
389 (0..4294967295).
391 o InterfaceIndexOrZero - The type "InterfaceIndexOrZero" is an
392 extension of the InterfaceIndex convention. The latter defines a
393 greater than zero value used to identify an interface or interface
394 sub-layer in the system. This extension permits the additional
395 value of zero. Examples of the usage of zero might include
396 situations where interface was unknown, or when none or all
397 interfaces need to be referenced. The allowed values are to be
398 intended as imported from [5].
400 o ProbesType - The type "ProbesType" represents a way of indicating
401 the protocol used for the traceroute probes. Allowed values are
402 UDP, TCP, ICMP.
404 o DateAndTime - The type "DateAndTime" represents a date-time
405 specification. The allowed values are to be intended as imported
406 from [2] apart from the fact that in this document there is the
407 need to use a milli-second resolution instead a deci-second one.
409 o OperationResponseStatus - The type "OperationResponseStatus" is
410 used to report the result of an operation. The allowed values are
411 to be intended as imported from [6] or from its recent update
412 ([8]).
414 5.2. Information Elements
416 This section describes the elements of the traceroute measurement.
417 The elements are grouped in two groups (Configuration and Results)
418 according to their semantics. In order to relate configuration and
419 results elements by means of a common unique identifier, an
420 additional element is defined belonging to both the two groups.
422 5.2.1. Configuration Information Elements
424 This section describes the elements of the traceroute measurement
425 that are specific to traceroute configuration.
427 5.2.1.1. traceRouteCtlTargetAddressType
429 o name - traceRouteCtlTargetAddressType
431 o description - Specifies the type of host address used in the
432 traceroute command.
434 o dataType - InetAddressType
435 o units - N/A
437 o default value - N/A
439 5.2.1.2. traceRouteCtlTargetAddress
441 o name - traceRouteCtlTargetAddress
443 o description - Specifies the host address used in the traceroute
444 command. The host address type can be determined by the examining
445 the value of the corresponding traceRouteCtlTargetAddressType.
447 o dataType - InetAddress
449 o units - N/A
451 o default value - N/A
453 5.2.1.3. traceRouteCtlByPassRouteTable
455 o name - traceRouteCtlByPassRouteTable
457 o description - Specifies if the optional bypassing of the route
458 table was enabled or not. If enabled, the traceroute will bypass
459 the normal routing tables and send directly to a host on an
460 attached network. If the host is not on a directly-attached
461 network, an error is returned. This option can be used to perform
462 the traceroute operation to a local host through an interface that
463 has no route defined.
465 o dataType - TruthValue
467 o units - N/A
469 o default value - false
471 5.2.1.4. traceRouteCtlProbeDataSize
473 o name - traceRouteCtlProbeDataSize
475 o description - Specifies the size of the data portion of a
476 traceroute operation in octets. If the RECOMMENDED traceroute
477 method (UDP datagrams as probes) is used, then the value contained
478 in this object is exact. If another traceroute method is used for
479 which the specified size is not appropriate, then the
480 implementation should have used whatever size (appropriate to the
481 method) is closest to the specified size. The maximum value for
482 this object was computed by substracting the smallest possible IP
483 header size of 20 octets (IPv4 header with no options) and the UDP
484 header size of 8 octets from the maximum IP packet size. An IP
485 packet has a maximum size of 65535 octets (excluding IPv6
486 Jumbograms).
488 o dataType - Unsigned32
490 o units - octects
492 o default value - 0
494 5.2.1.5. traceRouteCtlTimeOut
496 o name - traceRouteCtlTimeOut
498 o description - Specifies the time-out value, in seconds, for the
499 traceroute operation.
501 o dataType - Unsigned32
503 o units - seconds
505 o default value - 3
507 5.2.1.6. traceRouteCtlProbesPerHop
509 o name - traceRouteCtlProbesPerHop
511 o description - Specifies the number of times to reissue a
512 traceroute request with the same time-to-live (TTL) value.
514 o dataType - Unsigned32
516 o units - probes
518 o default value - 3
520 5.2.1.7. traceRouteCtlPort
522 o name - traceRouteCtlPort
524 o description - Specifies the base UDP port used by the traceroute
525 operation. Need to specify a port that is not in use at the
526 destination (target) host. The default value for this object is
527 the IANA assigned port, 33434, for the traceroute function.
529 o dataType - Unsigned32
530 o units - UDP Port
532 o default value - 33434
534 5.2.1.8. traceRouteCtlMaxTtl
536 o name - traceRouteCtlMaxTtl
538 o description - Specifies the maximum TTL value for the traceroute
539 operation.
541 o dataType - Unsigned32
543 o units - time-to-live value
545 o default value - 30
547 5.2.1.9. traceRouteCtlDSField
549 o name - traceRouteCtlDSField
551 o description - Specifies the value that was stored in the
552 Differentiated Services (DS) field in the IP packet used to
553 encapsulate the traceroute probe. The DS Field is defined as the
554 Type of Service (TOS) octet in a IPv4 header or as the Traffic
555 Class octet in a IPv6 header. The value of this object must be a
556 decimal integer in the range from 0 to 255. This option can be
557 used to determine what effect an explicit DS field setting has on
558 a traceroute response. Not all values are legal or meaningful.
559 DS field usage is often not supported by IP implementations. A
560 value of 0 means that the function represented by this option is
561 not supported. Useful TOS octet values are probably '16' (low
562 delay) and '8' (high throughput). Further references can be found
563 in [3] for the definition of the Differentiated Services (DS)
564 field and to [4] Section 5.3.2 for Type of Service (TOS).
566 o dataType - Unsigned32
568 o units - N/A
570 o default value - 0
572 5.2.1.10. traceRouteCtlSourceAddressType
574 o name - traceRouteCtlSourceAddressType
576 o description - Specifies the type of the source address,
577 traceRouteCtlSourceAddress, used when performing the traceroute
578 operation.
580 o dataType - InetAddressType
582 o units - N/A
584 o default value - N/A
586 5.2.1.11. traceRouteCtlSourceAddress
588 o name - traceRouteCtlSourceAddress
590 o description - Specifies the IP address (which has to be given as
591 an IP number, not a hostname) as the source address used in
592 outgoing probe packets. On hosts with more than one IP address,
593 this option can be used to force the source address to be
594 something other than the primary IP address of the interface the
595 probe packet is sent on. A zero length octet string value for
596 this object means that source address specification was disabled.
597 The address type (InetAddressType) that relates to this object is
598 specified by the corresponding value of
599 traceRouteCtlSourceAddressType.
601 o dataType - InetAddress
603 o units - N/A
605 o default value - N/A
607 5.2.1.12. traceRouteCtlIfIndex
609 o name - traceRouteCtlIfIndex
611 o description - Specifies the inferface index used in the traceroute
612 operation for sending the traceroute probes. A value of zero for
613 this object implies that the interface was unknown.
615 o dataType - InterfaceIndexOrZero
617 o units - N/A
619 o default value - 0
621 5.2.1.13. traceRouteCtlMiscOptions
623 o name - traceRouteCtlMiscOptions
624 o description - Specifies implementation dependent options.
626 o dataType - String
628 o units - N/A
630 o default value - N/A
632 5.2.1.14. traceRouteCtlMaxFailures
634 o name - traceRouteCtlMaxFailures
636 o description - Specifies the maximum number of consecutive timeouts
637 allowed before terminating a traceroute operation. A value of
638 either 255 (maximum hop count/possible TTL value) or a 0 indicates
639 that the function of terminating a remote traceroute operation
640 when a specific number of consecutive timeouts are detected was
641 disabled. This element is included to give full compatibility
642 with [6] and with its recent update ([8]). No known
643 implementation of traceroute currently supports it.
645 o dataType - Unsigned32
647 o units - timeouts
649 o default value - 5
651 5.2.1.15. traceRouteCtlDontFragment
653 o name - traceRouteCtlDontFragment
655 o description - Specifies if the don't fragment flag (DF) in the IP
656 header for a probe was enabled or not. The use of the DF flag is
657 intended to be relative to a manual PATH MTU test.
659 o dataType - TruthValue
661 o units - N/A
663 o default value - false
665 5.2.1.16. traceRouteCtlInitialTtl
667 o name - traceRouteCtlInitialTtl
669 o description - Specifies the initial TTL value uses in a traceroute
670 operation. The use of initial TTL setting is intended to be used
671 when bypassing the initial (often well known) portion of a path is
672 to be achieved.
674 o dataType - Unsigned32
676 o units - N/A
678 o default value - 1
680 5.2.1.17. traceRouteCtlDescr
682 o name - traceRouteCtlDescr
684 o description - The purpose of this element is to provide a
685 description of the traceroute test.
687 o dataType - String
689 o units - N/A
691 o default value - N/A
693 5.2.1.18. traceRouteCtlType
695 o name - traceRouteCtlType
697 o description - Specifies the implementation method used for the
698 traceroute operation.
700 o dataType - ProbesType
702 o units - N/A
704 o default value - UDP
706 5.2.2. Results Information Elements
708 This section describes the elements of the traceroute measurement
709 that are specific to the results of a traceroute operation.
711 5.2.2.1. traceRouteResultsStartDateAndTime
713 o name - traceRouteResultsStartDateAndTime
715 o description - Specifies the date and start time of the traceroute
716 operation. This is the time when the first probe was seen at the
717 sending interface.
719 o dataType - DateAndTime
721 o units - N/A
723 o default value - N/A
725 5.2.2.2. traceRouteResultsIpTgtAddrType
727 o name - traceRouteResultsIpTgtAddrType
729 o description - Specifies the type of address stored in the
730 corresponding traceRouteResultsIpTgtAddr element.
732 o dataType - InetAddressType
734 o units - N/A
736 o default value - N/A
738 5.2.2.3. traceRouteResultsIpTgtAddr
740 o name - traceRouteResultsIpTgtAddr
742 o description - Specifies the IP address associated with a
743 traceRouteCtlTargetAddress value when the destination address is
744 specified as a DNS name. The value of this object should be a
745 zero length octet string when a DNS name is not specified or when
746 a specified DNS name fails to resolve.
748 o dataType - InetAddress
750 o units - N/A
752 o default value - N/A
754 5.2.2.4. traceRouteResultsProbeIndex
756 o name - traceRouteResultsProbeIndex
758 o description - Specifies the progressive index of a probe within
759 the traceroute operation. The maximum value here is the number
760 resulting from the operation
761 traceRouteCtlMaxTtl*traceRouteCtlProbesPerHop.
763 o dataType - Unsigned32
765 o units - N/A
766 o default value - N/A
768 5.2.2.5. traceRouteResultsProbeHopIndex
770 o name - traceRouteResultsProbeHopIndex
772 o description - Specifies which hop in a traceroute path that the
773 probe's results are for. The value of this element is initially
774 determined by the value of traceRouteCtlInitialTtl.
776 o dataType - Unsigned32
778 o units - N/A
780 o default value - N/A
782 5.2.2.6. traceRouteResultsProbeIndexPerHop
784 o name - traceRouteResultsProbeIndexPerHop
786 o description - Specifies the index of a probe for a particular hop
787 in a traceroute path. The number of probes per hop is determined
788 by the value of the corresponding traceRouteCtlProbesPerHop
789 element.
791 o dataType - Unsigned32
793 o units - N/A
795 o default value - N/A
797 5.2.2.7. traceRouteResultsProbeHopAddrType
799 o name - traceRouteResultsProbeHopAddrType
801 o description - Specifies the type of address stored in the
802 corresponding traceRouteResultsProbeHopAddr element.
804 o dataType - InetAddressType
806 o units - N/A
808 o default value - N/A
810 5.2.2.8. traceRouteResultsProbeHopAddr
811 o name - traceRouteResultsProbeHopAddr
813 o description - Specifies the address of a hop in the traceroute
814 path. This object is not allowed to be a DNS name. The value of
815 the corresponding object, traceRouteResultsProbeHopAddrType,
816 indicates this object's IP address type.
818 o dataType - InetAddress
820 o units - N/A
822 o default value - N/A
824 5.2.2.9. traceRouteResultsProbeHopASNumber
826 o name - traceRouteResultsProbeHopASNumber
828 o description - Specifies the AS number of a hop in the traceroute
829 path.
831 o dataType - Unsigned32
833 o units - N/A
835 o default value - N/A
837 5.2.2.10. traceRouteResultsProbeHopGeoLocation
839 o name - traceRouteResultsProbeHopGeoLocation
841 o description - Specifies the geo location of a hop in the
842 traceroute path.
844 o dataType - String
846 o units - N/A
848 o default value - N/A
850 5.2.2.11. traceRouteResultsProbeRoundTripTime
852 o name - traceRouteResultsProbeRoundTripTime
854 o description - Specifies the amount of time measured in
855 milliseconds from when a probe was sent to when its response was
856 received or when it timed out. The value of this element is
857 reported as 0 when it was not possible to transmit a probe.
859 o dataType - Unsigned32
861 o units - milliseconds
863 o default value - N/A
865 5.2.2.12. traceRouteResultsProbeResponseStatus
867 o name - traceRouteResultsProbeResponseStatus
869 o description - Specifies the result of a traceroute operation made
870 by the host for a particular probe.
872 o dataType - OperationResponseStatus
874 o units - N/A
876 o default value - N/A
878 5.2.2.13. traceRouteResultsProbeTime
880 o name - traceRouteResultsProbeTime
882 o description - Specifies the timestamp for when the response to the
883 probe was received interface.
885 o dataType - DateAndTime
887 o units - N/A
889 o default value - N/A
891 5.2.2.14. traceRouteResultsHopRawOutputData
893 o name - traceRouteResultsHopRawOutputData
895 o description - Specifies the raw output data returned by the
896 traceroute operation for a certain hop in a traceroute path.
898 o dataType - String
900 o units - N/A
902 o default value - N/A
904 5.2.2.15. traceRouteResultsEndDateAndTime
906 o name - traceRouteResultsEndDateAndTime
908 o description - Specifies the date and end time of the traceroute
909 operation. It is either the time when the response to the last
910 probe of the traceroute operation was received or the time when
911 the last probe of the traceroute operation was sent plus the
912 relative timeout (in case of missing response).
914 o dataType - DateAndTime
916 o units - N/A
918 o default value - N/A
920 5.2.3. Information Element correlating configuration and results
921 elements
923 This section defines an additional element belonging to both the two
924 previous groups. This element is defined in order to relate
925 configuration elements and results ones by means of a common unique
926 identifier.
928 5.2.3.1. traceRouteTestName
930 o name - traceRouteTestName
932 o description - Specifies the name of a traceroute test. This is
933 locally unique.
935 o dataType - String
937 o units - N/A
939 o default value - N/A
941 6. Data model for storing traceroutes measurements
943 For storing and transmitting information according to the information
944 model defined in the previous section, a data model is required that
945 specifies how to encode the elements of the information model.
947 There are several design choices for a data model. It can use a
948 binary or textual representation and it can be defined from scratch
949 or use already existing frameworks and data models. In general, the
950 use of already existing frameworks and models should be preferred.
952 Binary and textual representation both have advantages and
953 disadvantages. Textual representions are (with some limitations)
954 human readable while a binary representation consumes less resources
955 for storing, transmitting and parsing data.
957 An already existing and closely related data model is the DISMAN-
958 TRACEROUTE-MIB module [6], that specifies a BER encoding [9] used by
959 the Simple Network Management Protocol (SNMP) [10] for transmitting
960 traceroute information. This data model is well suited and supported
961 within network management systems, but as a general format for
962 storing and transmitting traceroute results it is not easily
963 applicable.
965 Another binary representation would be an extension of traffic flow
966 information encodings specified for the NetFlow version 9 [11]
967 protocol and the IPFIX protocol [12], [13]. For these protocols
968 standard templates could be defined as it has been done for another
969 purpose in [14]. The architectures behind these protocols have been
970 designed for the export of passively measured flow information. For
971 following this approach, it needs to be investigated whether or not
972 the respective architectures can be extended to active route
973 measurement.
975 For textual representations, using the eXtensible Markup Language
976 (XML) [15] is an obvious choice. XML supports clean structuring of
977 data and syntax checking of records. With some limitations it is
978 human readable. It is supported well by a huge pool of tools and
979 standards for generating, transmitting, parsing and converting it to
980 other data formats. Its disadvantages is the resource comsumption
981 for processing, storing, and transmitting information. Since the
982 expected data volumes of traceroute data in network operation and
983 maintenance is not expected to be extremly high, the inefficient
984 usage of resources is not a significant disadvantage. Therefore, XML
985 was chosen as basis for the traceroute information model that is
986 specified in this section.
988 6.1. XML schema for traceroute measurements
990
991
993
994
995
996
997
998
999
1000
1002
1003
1004
1005
1006
1007
1008
1009
1011
1012
1013
1014
1015
1017
1018
1019
1022
1023
1025
1026
1027
1029
1030
1032
1033
1034
1036
1037
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1055
1056
1057
1059
1060
1061
1062
1063
1065
1066
1067 Specifies the name of a traceroute
1068 test. This is locally unique.
1069
1070
1071
1072
1073
1074
1076
1077
1078 Specifies if the optional bypassing
1079 of the route table was enabled or not. If enabled,
1080 the traceroute will bypass the normal routing tables
1081 and send directly to a host on an attached network.
1082 If the host is not on a directly-attached network,
1083 an error is returned. This option can be used to
1084 perform the traceroute operation to a local host
1085 through an interface that has no route defined.
1086
1087
1088
1089
1091
1092
1093 Specifies the size of the data
1094 portion of a traceroute operation in octets. If the
1095 RECOMMENDED traceroute method (UDP datagrams as probes)
1096 is used, then the value contained in this object is
1097 exact. If another traceroute method is used for which
1098 the specified size is not appropriate, then the
1099 implementation should have used whatever size (appropriate
1100 to the method) is closest to the specified size.
1101 The maximum value for this object was computed by
1102 substracting the smallest possible IP header size of 20
1103 octets (IPv4 header with no options) and the UDP header
1104 size of 8 octets from the maximum IP packet size. An IP
1105 packet has a maximum size of 65535 octets (excluding IPv6
1106 jumbograms). Units are: octects.
1107
1108
1109
1110
1111
1112
1114
1115
1116 Specifies the time-out value, in
1117 seconds, for the traceroute operation.
1118 Units are: seconds.
1119
1120
1121
1122
1123
1124
1125
1127
1128
1129 Specifies the number of times to
1130 reissue a traceroute request with the same time-to-live
1131 (TTL) value. Units are: probes.
1133
1134
1135
1136
1137
1138
1139
1141
1142
1143 Specifies the base UDP port used by
1144 the traceroute operation. Need to specify a port that
1145 is not in use at the destination (target) host.
1146 The default value for this object is the IANA assigned
1147 port, 33434, for the traceroute function.
1148 Units are: UDP port.
1149
1150
1151
1152
1153
1154
1156
1157
1158 Specifies the maximum TTL value for
1159 the traceroute operation.
1160 Units are: time-to-live value.
1161
1162
1163
1164
1165
1166
1168
1169
1170 Specifies the value that was stored in
1171 the Differentiated Services (DS) field in the IP packet
1172 used to encapsulate the traceroute probe. The DS Field
1173 is defined as the Type of Service (TOS) octet in a IPv4
1174 header or as the Traffic Class octet in a IPv6 header.
1175 The value of this object must be a decimal integer in the
1176 range from 0 to 255. This option can be used to determine
1177 what effect an explicit DS field setting has on a
1178 traceroute response. Not all values are legal or
1179 meaningful. DS field usage is often not supported by IP
1180 implementations. A value of 0 means that the function
1181 represented by this option is not supported. Useful TOS
1182 octet values are probably '16' (low delay) and '8' (high
1183 throughput). Further references can be found in the
1184 RFC 2474 for the definition of the Differentiated
1185 Services (DS) field and to the RFC 1812 Section 5.3.2
1186 for Type of Service (TOS).
1187
1188
1189
1190
1192
1194
1195 Specifies the inferface index used in the
1196 traceroute operation for sending the traceroute
1197 probes. A value of zero for this object implies
1198 that the interface was unknown.
1199
1200
1201
1202
1204
1205
1206 Specifies implementation dependent
1207 options.
1208
1209
1210
1211
1212
1214
1215
1216 Specifies the maximum number of
1217 consecutive timeouts allowed before terminating a
1218 traceroute operation. A value of either 255
1219 (maximum hop count/possible TTL value) or a 0 indicates
1220 that the function of terminating a remote traceroute
1221 operation when a specific number of consecutive
1222 timeouts are detected was disabled. This element is
1223 included to give full compatibility with DISMAN working
1224 group documents. No known implementation of traceroute
1225 currently supports it.
1226 Units are: timeouts.
1227
1229
1230
1231
1233
1234
1235 Specifies if the don't fragment flag
1236 (DF) in the IP header for a probe was enabled or not.
1237 The use of the DF flag is intended to be relative to a
1238 manual PATH MTU test.
1239
1240
1241
1242
1244
1245
1246 Specifies the initial TTL value uses
1247 in a traceroute operation. The use of initial TTL
1248 setting is intended to be used when bypassing the
1249 initial (often well known) portion of a path is to be
1250 achieved.
1251
1252
1253
1254
1255
1256
1258
1259
1260 The purpose of this element is to
1261 provide a description of the traceroute test.
1262
1263
1264
1265
1266
1267
1269
1270
1271 Specifies the implementation method
1272 used for the traceroute operation.
1273
1274
1275
1276
1277
1278
1279
1280
1282
1283
1284 Specifies the progressive index of
1285 a probe within the traceroute operation. The maximum
1286 value here is the number resulting from the operation
1287 traceRouteCtlMaxTtl*traceRouteCtlProbesPerHop.
1288
1289
1290
1291
1292
1293
1294
1296
1297
1298 Specifies which hop in a traceroute
1299 path that the probe's results are for. The value of
1300 this element is initially determined by the value of
1301 traceRouteCtlInitialTtl.
1302
1303
1304
1305
1306
1307
1309
1310
1311 Specifies the index of a probe for
1312 a particular hop in a traceroute path. The number of
1313 probes per hop is determined by the value of the
1314 corresponding traceRouteCtlProbesPerHop element.
1315
1316
1317
1318
1319
1320
1321
1323
1324
1325 Specifies the AS number of a hop in
1326 the traceroute path.
1327
1328
1329
1330
1332
1333
1334 Specifies the geo location of a hop
1335 in the traceroute path.
1336
1337
1338
1339
1340
1341
1343
1344
1345 Specifies the amount of time measured
1346 in milliseconds from when a probe was sent to when its
1347 response was received or when it timed out. The value
1348 of this element is reported as 0 when it was not possible
1349 to transmit a probe.
1350 Units are: milliseconds.
1351
1352
1353
1354
1355
1356
1358
1359
1360 Specifies the raw output data returned
1361 by the traceroute operation for a certain hop in a
1362 traceroute path.
1363
1364
1365
1366
1367
1368
1370
1371
1372
1374
1376
1378
1380
1381
1383
1384
1385
1387
1389
1391
1393
1394
1396
1397
1398
1400
1402
1403
1405
1406
1407 Specifies the type of host address
1408 used in the traceroute command.
1409
1410
1411
1412
1414
1415
1417
1418
1419 Specifies the host address used in
1420 the traceroute command. The host address type can be
1421 determined by the examining the value of the
1422 corresponding traceRouteCtlTargetAddressType.
1423
1424
1425
1426
1427
1428
1430
1431
1432 Specifies the type of the source address,
1433 traceRouteCtlSourceAddress, used when performing the
1434 traceroute operation.
1435
1436
1437
1438
1440
1441
1443
1444
1445 Specifies the IP address (which has
1446 to be given as an IP number, not a hostname) as the
1447 source address used in outgoing probe packets. On hosts
1448 with more than one IP address, this option can be used
1449 to force the source address to be something other than
1450 the primary IP address of the interface the probe packet
1451 is sent on. A zero length octet string value for this
1452 object means that source addres specification was disabled.
1453 The address type (InetAddressType) that relates to this
1454 object is specified by the corresponding value of
1455 traceRouteCtlSourceAddressType.
1456
1457
1458
1459
1461
1462
1464
1465
1466 Specifies the date and start time of the
1467 traceroute operation. This is the time when the first probe
1468 was sent.
1470
1471
1472
1473
1474
1475
1477
1478
1479 Specifies the type of address stored
1480 in the corresponding traceRouteResultsIpTgtAddr element.
1481
1482
1483
1484
1486
1487
1489
1490
1491 Specifies the IP address associated
1492 with a traceRouteCtlTargetAddress value when the
1493 destination address is specified as a DNS name.
1494 The value of this object should be a zero length octet
1495 string when a DNS name is not specified or when a
1496 specified DNS name fails to resolve.
1497
1498
1499
1500
1502
1503
1505
1506
1507 Specifies the type of address stored
1508 in the corresponding traceRouteResultsProbeHopAddr
1509 element.
1510
1511
1512
1513
1515
1516
1517
1518
1519 Specifies the address of a hop in
1520 the traceroute path. This object is not allowed to
1521 be a DNS name. The value of the corresponding object,
1522 traceRouteResultsProbeHopAddrType, indicates this
1523 object's IP address type.
1524
1525
1526
1527
1529
1530
1532
1533
1534 Specifies the result of a traceroute
1535 operation made by the host for a particular probe.
1536
1537
1538
1539
1541
1542
1544
1545
1546 Specifies the timestamp when the
1547 response to the probe was received.
1548
1549
1550
1551
1552
1553
1555
1556
1557
1559
1561
1563
1566
1568
1571
1574
1576
1578
1580
1581
1583
1584
1585 Specifies the date and end time of
1586 the traceroute operation. It is either the time when
1587 the response to the last probe of the traceroute
1588 operation was received or the time when the last
1589 probe of the traceroute operation was sent plus the
1590 relative timeout (in case of missing response).
1591
1592
1593
1594
1595
1596
1598
1599
1600 Specifies the metadata for a
1601 traceroute operation. In a request, these are the
1602 requested parameters. In a response, they are the
1603 actual parameters used.
1604
1605
1606
1607
1609
1611
1613
1617
1620
1623
1626
1629
1632
1635
1637
1639
1642
1645
1648
1651
1654
1657
1661
1663
1665
1666
1667
1668 Contains the actual traceroute measurement.
1669
1670
1671
1672
1674
1676
1678
1680
1683
1686
1688
1689
1691
1692
1693
1695
1697
1699
1700
1702
1703
1705
1707 6.2. Design considerations
1709 In Section 6.1 we proposed an example of a possible XML schema as a
1710 template for storing and/or exchanging traceroute measurements. We
1711 designed the schema in order to use an extensible approach based on
1712 templates (pretty similar to how IPFIX protocol is designed) where
1713 the traceroute configuration elements (both the requested parameters,
1714 traceRouteRequest, and the actual parameters used,
1715 traceRouteMeasurementMetadata) are metadata to be referenced by
1716 results information elements (data) by means of the
1717 traceRouteTestName element (used as unique identifier). Currently
1718 Global Grid Forum (GGF) is also using this approach and cross-
1719 requirements have been analyzed as well as standardization
1720 opportunities of a joint work.
1722 Looking at the state of the art of the XML schema design, it is
1723 likely that naming issues will have to be solved in order to have a
1724 common work shared among the IETF and the GGF. A possibility on how
1725 to solve this is to standardize a common XML schema with different
1726 naming instances making possible a one-to-one name conversion that
1727 could be used for IETF-GGF interoperability purposes.
1729 7. Metrics considerations for traceroute measurements
1731 The previous sections of this draft have been dealing with the
1732 traceroute tool description, its parameters and the output that is
1733 going to be stored; in this section we want to highlight the relevant
1734 metrics that are of interest when storing traceroute measurements.
1736 Since the traceroute has built-in configurable mechanisms like time-
1737 outs and can experience problems related to the crossing of
1738 firewalls, some of the packets that traceroute sends out end up being
1739 time-out or filtered. Sometimes it is impossible to trace the path
1740 to a node or there is not a complete set of probes describing the RTT
1741 to reach it. Moreover, a known inconsistency exists between the
1742 round-trip delay metric defined by the IPPM working group and the
1743 results returned by the current traceroute implementations.
1744 Unfortunately, it is unlikely that the traceroute implementations
1745 will change accordingly in the near future therefore. In order to
1746 compare results of traceroute measurements, a possible solution would
1747 consist in adding to the metadata elements a specification of the
1748 operating system and version for the tool used in order to help in
1749 comparing metrics.
1751 8. Conclusions
1753 This draft attempts to define a standard way to store traceroute
1754 measurementsand related metrics. The document starts by examining a
1755 set of traceroute tools from the most common operatying systems and
1756 provides a summary of configurable and default input parameters.
1757 This investigation served as base for the definition of an
1758 information model and related data model. Furthermore, this draft
1759 tackles the issue of metrics resulting from traceroute measurements.
1760 Metrics already standardized by the IPPM are indeed not directly
1761 applicable to traceroute results because of how traceroute tools are
1762 currently implemented and where it is necessary to take into account,
1763 for instance, for missing responses. A number of open issues that
1764 still need to be discussed in the IPPM mailing list was also drafted.
1766 9. Security considerations
1768 Conducting Internet measurements can raise both security and privacy
1769 concerns. Traceroute measurements, in which traffic is injected into
1770 the network, can be abused for denial-of-service attacks disguised as
1771 legitimate measurement activity. This memo does not specify an
1772 implementation of the metrics, so it does not directly affect the
1773 security of the Internet nor of applications which run on the
1774 Internet. However, implementations of these metrics must be mindful
1775 of security and privacy concerns. Since traceroute measurements
1776 involve metrics of different types, each of the metric defined for
1777 storing traceroute measurments needs separate security considerations
1778 that are basically already covedered in the related RFCs published by
1779 the IPPM working group. The measurement parameters MUST be carefully
1780 selected so that the measurements inject trivial amounts of
1781 additional traffic into the networks they measure. If they inject
1782 "too much" traffic, they can skew the results of the measurement, and
1783 in extreme cases cause congestion and denial of service. The
1784 measurements themselves could be harmed by routers giving measurement
1785 traffic a different priority than "normal" traffic, or by an attacker
1786 injecting artificial measurement traffic. If routers can recognize
1787 measurement traffic and treat it separately, the measurements will
1788 not reflect actual user traffic. If an attacker injects artificial
1789 traffic that is accepted as legitimate, the loss rate will be
1790 artificially lowered. Therefore, the measurement methodologies
1791 SHOULD include appropriate techniques to reduce the probability
1792 measurement traffic can be distinguished from "normal" traffic.
1793 Authentication techniques, such as digital signatures, may be used
1794 where appropriate to guard against injected traffic attacks.
1796 10. IANA Considerations
1798 This document will need to register a new XML schema according to the
1799 guidelines in [7].
1801 The URN Sub-Namespace Registration will be for
1802 urn:ietf:params:xml:schema:. Where id has to be provided by
1803 IANA. NOTE: in order for a URN of this type to be assigned, the item
1804 being registered MUST have been through the IETF consensus process.
1805 Basically, this means that it must be documented in a RFC.
1807 URI: The URI for this schema will be urn:ietf:params:xml:schema:.
1809 Registrant Contact: TBD.
1811 XML: TBD.
1813 11. Open Issues
1815 This section is intended to keep track of the open issues that are to
1816 be discussed in the IPPM working group.
1818 o Consider improving section on metrics considerations.
1820 o Consider improving section on security considerations.
1822 o Complete IANA considerations.
1824 o Consider rewriting the description for ResultsProbeHopIndex, right
1825 now it is written in pure SNMP language and might be not clear.
1827 o Consider encoding the traceroute output when the delay is less
1828 than 1 ms or when the host was not reachable (update element
1829 traceRouteResultsProbeRoundTripTime). Right now a 0 is inserted
1830 when it was not possible to transmit a probe. Think a better
1831 encoding.
1833 o Consider keeping into account different versions of the traceroute
1834 tool instead of just UNIX, LINUX, WINDOWS. Update table in
1835 Section 2 accordingly.
1837 o Consider adding another probe result with the MPLS label
1838 clarifying if it is per hop or per probe and keeping it optional.
1840 o Consider including the AS number in the address type definition.
1842 o Double check references and divide them in normative and
1843 informational.
1845 o Consider updating the title and the text of the draft referring to
1846 the fact that the actual schema can be used not only to store
1847 traceroute measurements but also to request/configure a
1848 measurement.
1850 o Check metadata/data separation in the traceRoute element, right
1851 now it is exclusive but metadata and data could also be stored
1852 together.
1854 12. Normative References
1856 [1] Daniele et al., M., "Textual Conventions for Internet Network
1857 Addresses", RFC 3291, May 2002.
1859 [2] McCloghrie et al., K., "Textual Conventions for SMIv2",
1860 RFC 2579, April 1999.
1862 [3] Nichols et al., K., "Definition of the Differentiated Services
1863 Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
1864 December 1998.
1866 [4] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
1867 June 1995.
1869 [5] McCloghrie et al., K., "The Interfaces Group MIB", RFC 2863,
1870 June 2000.
1872 [6] White, K., "Definitions of Managed Objects for Remote Ping,
1873 Traceroute, and Lookup Operations", RFC 2925, September 2000.
1875 [7] Mealling, M., "The IETF XML registry", RFC 3688, January 2004.
1877 [8] Quittek, J., "Definitions of Managed Objects for Remote Ping,
1878 Traceroute, and Lookup Operations",
1879 DRAFT draft-ietf-disman-remops-mib-v2-06.txt, December 2004.
1881 [9] Presuhn et al., R., "Transport Mappings for the Simple Network
1882 Management Protocol (SNMP)", RFC 3417, December 2002.
1884 [10] Case et al., J., "Introduction and Applicability Statements for
1885 Internet Standard Management Framework", RFC 3410,
1886 December 2002.
1888 [11] Claise, B., "Cisco Systems NetFlow Services Export Version 9",
1889 RFC 3954, October 2004.
1891 [12] Claise, B., "Definitions of Managed Objects for Remote Ping,
1892 Traceroute, and Lookup Operations",
1893 DRAFT draft-ietf-ipfix-protocol-17.txt, July 2005.
1895 [13] Quittek et al., J., "Information Model for IP Flow Information
1896 Export", DRAFT draft-ietf-ipfix-info-09.txt, July 2005.
1898 [14] Stephan et al., E., "IPFIX templates for common ISP usages",
1899 DRAFT draft-stephan-isp-templates-00.txt, July 2005.
1901 [15] Yergeau et al., F., "Extensible Markup Language (XML) 1.0
1902 (Third Edition)", W3C Recommendation, February 2004.
1904 Authors' Addresses
1906 Saverio Niccolini
1907 Network Laboratories, NEC Europe Ltd.
1908 Kurfuersten-Anlage 36
1909 Heidelberg 69115
1910 Germany
1912 Phone: +49 (0) 6221 905 11 18
1913 Email: saverio.niccolini@netlab.nec.de
1914 URI: http://www.netlab.nec.de
1916 Sandra Tartarelli
1917 Network Laboratories, NEC Europe Ltd.
1918 Kurfuersten-Anlage 36
1919 Heidelberg 69115
1920 Germany
1922 Phone: +49 (0) 6221 905 11 32
1923 Email: sandra.tartarelli@netlab.nec.de
1924 URI: http://www.netlab.nec.de
1926 Juergen Quittek
1927 Network Laboratories, NEC Europe Ltd.
1928 Kurfuersten-Anlage 36
1929 Heidelberg 69115
1930 Germany
1932 Phone: +49 (0) 6221 905 11 15
1933 Email: quittek@netlab.nec.de
1934 URI: http://www.netlab.nec.de
1936 Martin Swany
1937 Dept. of Computer and Information Sciences, University of Delaware
1938 Newark DE 19716
1939 U.S.A.
1941 Email: swany@UDel.Edu
1943 Intellectual Property Statement
1945 The IETF takes no position regarding the validity or scope of any
1946 Intellectual Property Rights or other rights that might be claimed to
1947 pertain to the implementation or use of the technology described in
1948 this document or the extent to which any license under such rights
1949 might or might not be available; nor does it represent that it has
1950 made any independent effort to identify any such rights. Information
1951 on the procedures with respect to rights in RFC documents can be
1952 found in BCP 78 and BCP 79.
1954 Copies of IPR disclosures made to the IETF Secretariat and any
1955 assurances of licenses to be made available, or the result of an
1956 attempt made to obtain a general license or permission for the use of
1957 such proprietary rights by implementers or users of this
1958 specification can be obtained from the IETF on-line IPR repository at
1959 http://www.ietf.org/ipr.
1961 The IETF invites any interested party to bring to its attention any
1962 copyrights, patents or patent applications, or other proprietary
1963 rights that may cover technology that may be required to implement
1964 this standard. Please address the information to the IETF at
1965 ietf-ipr@ietf.org.
1967 Disclaimer of Validity
1969 This document and the information contained herein are provided on an
1970 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1971 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1972 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1973 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1974 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1975 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1977 Copyright Statement
1979 Copyright (C) The Internet Society (2006). This document is subject
1980 to the rights, licenses and restrictions contained in BCP 78, and
1981 except as set forth therein, the authors retain all their rights.
1983 Acknowledgment
1985 Funding for the RFC Editor function is currently provided by the
1986 Internet Society.