Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4560

Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations

Pages: 100
Proposed Standard
Obsoletes:  2925
Part 1 of 5 – Pages 1 to 13
None   None   Next

Top   ToC   RFC4560 - Page 1
Network Working Group                                    J. Quittek, Ed.
Request for Comments: 4560                                           NEC
Obsoletes: 2925                                            K. White, Ed.
Category: Standards Track                                      IBM Corp.
                                                               June 2006


                    Definitions of Managed Objects
           for Remote Ping, Traceroute, and Lookup Operations

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

This memo defines Management Information Bases (MIBs) for performing ping, traceroute, and lookup operations at a host. When managing a network, it is useful to be able to initiate and retrieve the results of ping or traceroute operations when they are performed at a remote host. A lookup capability is defined in order to enable resolution of either an IP address to an DNS name or a DNS name to an IP address at a remote host. Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability.
Top   ToC   RFC4560 - Page 2

Table of Contents

1. Introduction ....................................................3 1.1. Ping .......................................................3 1.2. Traceroute .................................................4 1.3. Lookup .....................................................5 1.4. Remote Operations ..........................................5 2. The Internet-Standard Management Framework ......................5 3. Structure of the MIBs ...........................................6 3.1. Ping MIB ...................................................6 3.1.1. pingMaxConcurrentRequests ...........................7 3.1.2. pingCtlTable ........................................7 3.1.3. pingResultsTable ....................................7 3.1.4. pingProbeHistoryTable ...............................8 3.2. Traceroute MIB .............................................8 3.2.1. traceRouteMaxConcurrentRequests .....................8 3.2.2. traceRouteCtlTable ..................................8 3.2.3. traceRouteResultsTable ..............................9 3.2.4. traceRouteProbeHistoryTable ........................10 3.2.5. traceRouteHopsTable ................................10 3.3. Lookup MIB ................................................10 3.3.1. lookupMaxConcurrentRequests and lookupPurgeTime ....11 3.3.2. lookupCtlTable .....................................11 3.3.3. lookupResultsTable .................................12 3.4. Conformance ...............................................12 4. Definitions ....................................................13 4.1. DISMAN-PING-MIB ...........................................13 4.2. DISMAN-TRACEROUTE-MIB .....................................46 4.3. DISMAN-NSLOOKUP-MIB .......................................84 5. Security Considerations ........................................95 6. Acknowledgements ...............................................97 7. References .....................................................97 7.1. Normative References ......................................97 7.2. Informative References ....................................98
Top   ToC   RFC4560 - Page 3

1. Introduction

This document defines standards-based MIB modules for performing specific remote operations. The remote operations defined by this document consist of the ping, traceroute, and lookup functions. Ping and traceroute are two very useful functions for managing networks. Ping is typically used to determine whether a path exists between two hosts, whereas traceroute shows an actual path. Both ping and traceroute yield round-trip times measured in milliseconds. These times can be used as a rough approximation for network transit time. The lookup functions considered in this document are the equivalents of name to address conversion functions such as gethostbyname()/gethostbyaddr() and getaddrinfo()/getnameinfo(). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

1.1. Ping

Ping is usually implemented using the Internet Control Message Protocol (ICMP) "ECHO" facility. It is also possible to implement a ping capability using alternate methods, including the following: o Using the UDP echo port (7), if supported. This is defined by RFC 862 [RFC862]. o Timing a Simple Network Management Protocol (SNMP) query. o Timing a TCP connect attempt. In general, almost any request/response flow can be used to generate a round-trip time. Often, many of the non-ICMP ECHO facility methods stand a better chance of yielding a good response (not timing out, for example) since some routers don't honor Echo Requests (timeout situation) or are handled at lower priority, thus possibly giving false indications of round trip times.
Top   ToC   RFC4560 - Page 4
   Note that almost any of the various methods used for generating a
   round-trip time can be considered a form of system attack when used
   excessively.  Sending a system request too often can negatively
   effect its performance.  Attempting to connect to what is supposed to
   be an unused port can be very unpredictable.  There are tools that
   attempt to connect to a range of TCP ports to test that any receiving
   server can handle erroneous connection attempts.

   It is also important to a management application using a remote ping
   capability to know which method is being used.  Different methods
   will yield different response times, since the protocol and resulting
   processing will be different.  It is RECOMMENDED that the ping
   capability defined within this memo be implemented using the ICMP
   Echo Facility.

1.2. Traceroute

Traceroute is usually implemented by transmitting a series of probe packets with increasing time-to-live values. A probe packet is a UDP datagram encapsulated into an IP packet. Each hop in a path to the target (destination) host rejects the probe packet (probe's TTL too small) until its time-to-live value becomes large enough for the probe to be forwarded. Each hop in a traceroute path returns an ICMP message that is used to discover the hop and to calculate a round trip time. Some systems use ICMP probes (ICMP Echo request packets) instead of UDP ones to implement traceroute. In both cases traceroute relies on the probes being rejected via an ICMP message to discover the hops taken along a path to the final destination. Both probe types, UDP and ICMP, are encapsulated into an IP packet and thus have a TTL field that can be used to cause a path rejection. Implementations of the remote traceroute capability as defined within this memo SHOULD be done using UDP packets to a (hopefully) unused port. ICMP probes (ICMP Echo Request packets) SHOULD NOT be used. Many PC implementations of traceroute use the ICMP probe method, which they should not, since this implementation method has been known to have a high probability of failure. Intermediate hops become invisible when a router either refuses to send an ICMP TTL expired message in response to an incoming ICMP packet or simply tosses ICMP echo requests altogether. The behavior of some routers not to return a TTL expired message in response to an ICMP Echo request is due in part to the following text extracted from RFC 792 [RFC792]: "The ICMP messages typically report errors in the processing of datagrams. To avoid the infinite regress of messages about messages etc., no ICMP messages are sent about ICMP messages."
Top   ToC   RFC4560 - Page 5

1.3. Lookup

The Lookup operation enables remote lookup of addresses for a symbolic name as it is, for example, performed by functions getnameinfo() or gethostbyaddr() and lookup of symbolic names for an address as it is, for example, performed by functions getaddrinfo() or gethostbyname(). Note that whatever lookup function is chosen, results are not necessarily consistent with the results of a pure Domain Name Service (DNS) lookup, but may be influenced by local lookup tables or other sources of information. The lookup capability can be used to determine the symbolic name of a hop in a traceroute path. Also, the reverse lookup can be used, for example, for analyzing name lookup problems.

1.4. Remote Operations

The MIB modules defined in this document allow a management station to initiate ping, traceroute, and lookup operations remotely. The basic scenario is illustrated by the following diagram. +-------+ +-------+ +-------+ | |---------->| | | | | | initiate | |---------->| | | Mgmt. | operation |Managed| perform |Target | |Station| remotely | Node | operation | Host | | | | | | | | |<----------| | | | +-------+ receive +-------+ +-------+ result of operation A management station is the local host from which the remote ping, traceroute, or Lookup operation is initiated using an SNMP request. The managed node is a remote host where the MIBs defined by this memo are implemented. It receives the remote operation via SNMP and performs the actual ping, traceroute, or lookup function.

2. The Internet-Standard Management Framework

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
Top   ToC   RFC4560 - Page 6
   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

3. Structure of the MIBs

This document defines three MIB modules: o DISMAN-PING-MIB Defines a ping MIB. o DISMAN-TRACEROUTE-MIB Defines a traceroute MIB. o DISMAN-NSLOOKUP-MIB Provides access to lookup functions for symbolic names and addresses at a remote host provided, for example, by functions getaddrinfo()/getnameinfo() and gethostbyname()/gethostbyaddr(). The ping and traceroute MIBs are structured to allow creation of ping or traceroute tests that can be set up to issue a series of operations periodically and to generate NOTIFICATIONs to report on test results. Many network administrators have in the past written UNIX shell scripts or command batch files to operate in a fashion similar to the functionality provided by the ping and traceroute MIBs defined within this memo. The intent of this document is to acknowledge the importance of these functions and to provide a standards-based solution.

3.1. Ping MIB

The DISMAN-PING-MIB consists of the following components: o pingMaxConcurrentRequests o pingCtlTable o pingResultsTable o pingProbeHistoryTable
Top   ToC   RFC4560 - Page 7

3.1.1. pingMaxConcurrentRequests

The object pingMaxConcurrentRequests enables control of the maximum number of concurrent active requests that an agent implementation supports. It is permissible for an agent either to limit the maximum upper range allowed for this object or to implement this object as read-only with an implementation limit expressed as its value.

3.1.2. pingCtlTable

A remote ping test is started by setting pingCtlAdminStatus to enabled(1). The corresponding pingCtlEntry MUST have been created, and its pingCtlRowStatus set to active(1), prior to starting the test. A single SNMP PDU can be used to create and start a remote ping test. Within the PDU, pingCtlTargetAddress should be set to the target host's address (pingCtlTargetAddressType will default to ipv4(1)), pingCtlAdminStatus to enabled(1), and pingCtlRowStatus to createAndGo(4). The first index element, pingCtlOwnerIndex, is of type SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-Based Access Control Model (RFC 3415 [RFC3415], VACM) and that allows a management application to identify its entries. The second index, pingCtlTestName (also an SnmpAdminString), enables the same management application to have multiple requests outstanding. Using the maximum value for the parameters defined within a pingEntry can result in a single remote ping test's taking at most 15 minutes (pingCtlTimeOut times pingCtlProbeCount), plus whatever time it takes to send the ping request and to receive its response over the network from the target host. Use of the defaults for pingCtlTimeOut and pingCtlProbeCount yields a maximum of 3 seconds to perform a "normal" ping test. A management application can delete an active remote ping request by setting the corresponding pingCtlRowStatus object to destroy(6). The contents of the pingCtlTable are preserved across reIPLs (Initial Program Loads) of its agent according the values of each of the pingCtlStorageType objects.

3.1.3. pingResultsTable

An entry in the pingResultsTable is created for a corresponding pingCtlEntry once the test defined by this entry is started.
Top   ToC   RFC4560 - Page 8

3.1.4. pingProbeHistoryTable

The results of past ping probes are stored in this table on a per- pingCtlEntry basis. This table is initially indexed by pingCtlOwnerIndex and pingCtlTestName so that the results of a probe relate to the pingCtlEntry that caused it. The maximum number of entries stored in this table per pingCtlEntry is determined by the value of pingCtlMaxRows. An implementation of this MIB will remove the oldest entry in the pingProbeHistoryTable of the corresponding entry in the pingCtlTable to allow the addition of a new entry once the number of rows in the pingProbeHistoryTable reaches the value specified by pingCtlMaxRows for the corresponding entry in the pingCtlTable. An implementation MUST start assigning pingProbeHistoryIndex values at 1 and wrap after exceeding the maximum possible value, as defined by the limit of this object ('ffffffff'h).

3.2. Traceroute MIB

The DISMAN-TRACEROUTE-MIB consists of the following components: o traceRouteMaxConcurrentRequests o traceRouteCtlTable o traceRouteResultsTable o traceRouteProbeHistoryTable o traceRouteHopsTable

3.2.1. traceRouteMaxConcurrentRequests

The object traceRouteMaxConcurrentRequests enables control of the maximum number of concurrent active requests that an agent implementation supports. It is permissible for an agent either to limit the maximum upper range allowed for this object or to implement this object as read-only with an implementation limit expressed as its value.

3.2.2. traceRouteCtlTable

A remote traceroute test is started by setting traceRouteCtlAdminStatus to enabled(1). The corresponding traceRouteCtlEntry MUST have been created, and its traceRouteCtlRowStatus set to active(1), prior to starting the test. A single SNMP PDU can be used to create and start a remote traceroute
Top   ToC   RFC4560 - Page 9
   test.  Within the PDU, traceRouteCtlTargetAddress should be set to
   the target host's address (traceRouteCtlTargetAddressType will
   default to ipv4(1)), traceRouteCtlAdminStatus to enabled(1), and
   traceRouteCtlRowStatus to createAndGo(4).

   The first index element, traceRouteCtlOwnerIndex, is of type
   SnmpAdminString, a textual convention that allows for use of the
   SNMPv3 View-Based Access Control Model (RFC 3415 [RFC3415], VACM) and
   that allows a management application to identify its entries.  The
   second index, traceRouteCtlTestName (also an SnmpAdminString),
   enables the same management application to have multiple requests
   outstanding.

   Traceroute has a much longer theoretical maximum time for completion
   than ping: basically, 42 hours and 30 minutes (the product of
   traceRouteCtlTimeOut, traceRouteCtlProbesPerHop, and
   traceRouteCtlMaxTtl) plus some network transit time!  Use of the
   defaults defined within an traceRouteCtlEntry yields a maximum of 4
   minutes and 30 seconds for a default traceroute operation.  Clearly,
   42 plus hours is too long to wait for a traceroute operation to be
   completed.

   The maximum Time to Live (TTL) value in effect for traceroute
   determines how long the traceroute function will keep increasing the
   TTL value in the probe it transmits, hoping to reach the target host.
   The function ends whenever the maximum TTL is exceeded or the target
   host is reached.  The object traceRouteCtlMaxFailures was created in
   order to impose a throttle for how long traceroute continues to
   increase the TTL field in a probe without receiving any kind of
   response (timeouts).  It is RECOMMENDED that agent implementations
   impose a time limit for how long it allows a traceroute operation to
   take, relative to how the function is implemented.  For example, an
   implementation that can't process multiple traceroute operations at
   the same time SHOULD impose a shorter maximum allowed time period.

   A management application can delete an active remote traceroute
   request by setting the corresponding traceRouteCtlRowStatus object to
   destroy(6).

   The contents of the traceRouteCtlTable are preserved across reIPLs
   (Initial Program Loads) of its agent according to the values of each
   of the traceRouteCtlStorageType objects.

3.2.3. traceRouteResultsTable

An entry in the traceRouteResultsTable is created upon determining the results of a specific traceroute operation. Entries in this table relate back to the traceRouteCtlEntry that caused the
Top   ToC   RFC4560 - Page 10
   corresponding traceroute operation to occur.  The objects
   traceRouteResultsCurHopCount and traceRouteResultsCurProbeCount can
   be examined to determine how far the current remote traceroute
   operation has reached.

3.2.4. traceRouteProbeHistoryTable

The results of past traceroute probes can be stored in this table on a per-traceRouteCtlEntry basis. This table is initially indexed by traceRouteCtlOwnerIndex and traceRouteCtlTestName so that the results of a probe relate to the traceRouteCtlEntry that caused it. The number of entries stored in this table per traceRouteCtlEntry is determined by the value of traceRouteCtlMaxRows. An implementation of this MIB will remove the oldest entry in the traceRouteProbeHistoryTable of the corresponding entry in the traceRouteCtlTable to allow the addition of an new entry once the number of rows in the traceRouteProbeHistoryTable reaches the value of traceRouteCtlMaxRows for the corresponding entry in the traceRouteCtlTable. An implementation MUST start assigning traceRouteProbeHistoryIndex values at 1 and wrap after exceeding the maximum possible value, as defined by the limit of this object ('ffffffff'h).

3.2.5. traceRouteHopsTable

The current traceroute path can be stored in this table on a per- traceRouteCtlEntry basis. This table is initially indexed by traceRouteCtlOwnerIndex and traceRouteCtlTestName so that a traceroute path relates to the traceRouteCtlEntry that caused it. A third index, traceRouteHopsHopIndex, enables keeping one traceRouteHopsEntry per traceroute hop. Creation of traceRouteHopsTable entries is enabled by setting the corresponding traceRouteCtlCreateHopsEntries object to true(1).

3.3. Lookup MIB

The DISMAN-NSLOOKUP-MIB consists of the following components: o lookupMaxConcurrentRequests and lookupPurgeTime o lookupCtlTable o lookupResultsTable
Top   ToC   RFC4560 - Page 11

3.3.1. lookupMaxConcurrentRequests and lookupPurgeTime

The object lookupMaxConcurrentRequests enables control of the maximum number of concurrent active requests that an agent implementation is structured to support. It is permissible for an agent either to limit the maximum upper range allowed for this object or to implement this object as read-only with an implementation limit expressed as its value. The object lookupPurgeTime provides a method for entries in the lookupCtlTable and lookupResultsTable to be automatically deleted after the corresponding operation is completed.

3.3.2. lookupCtlTable

A remote lookup operation is initiated by performing an SNMP SET request on lookupCtlRowStatus. A single SNMP PDU can be used to create and start a remote lookup operation. Within the PDU, lookupCtlTargetAddress should be set to the entity to be resolved (lookupCtlTargetAddressType will default to ipv4(1)) and lookupCtlRowStatus to createAndGo(4). The object lookupCtlOperStatus can be examined to determine the state of a lookup operation. A management application can delete an active remote lookup request by setting the corresponding lookupCtlRowStatus object to destroy(6). An lookupCtlEntry is initially indexed by lookupCtlOwnerIndex, which is a type of SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-Based Access Control Model (RFC 3415 [RFC3415], VACM) and that also allows for a management application to identify its entries. The lookupCtlOwnerIndex portion of the index is then followed by lookupCtlOperationName. The lookupCtlOperationName index enables the same lookupCtlOwnerIndex entity to have multiple outstanding requests. The value of lookupCtlTargetAddressType determines which lookup function to perform. Specification of dns(16) as the value of this index implies that a function such as getaddrinfo() or gethostbyname() should be performed to determine the numeric addresses associated with a symbolic name via lookupResultsTable entries. Use of a value of either ipv4(1) or ipv6(2) implies that a function such as getnameinfo() or gethostbyaddr() should be performed to determine the symbolic name(s) associated with a numeric address at a remote host.
Top   ToC   RFC4560 - Page 12

3.3.3. lookupResultsTable

The lookupResultsTable is used to store the results of lookup operations. Results to be reported here SHOULD be results of a lookup function that is commonly used by applications at the managed node. This implies that results are not necessarily consistent with the results of a pure DNS lookup at the managed node, but may be influenced by local lookup tables or other sources of information, depending on the configuration of the managed node. The lookupResultsTable is initially indexed by the same index elements that the lookupCtlTable contains (lookupCtlOwnerIndex and lookupCtlOperationName) but has a third index element, lookupResultsIndex (Unsigned32 textual convention), in order to associate multiple results with the same lookupCtlEntry. A remote host can be multi-homed and can have multiple symbolic (DNS) names. Therefore, a lookup operation can return multiple IP addresses and multiple symbolic names. If the lookup operation was performed for a certain address by using getnameinfo() or gethostbyaddr(), for example, then entries in the lookupResultsTable MUST be made for each host name returned. If the lookup operation identifies one hostname as the host's 'official host name', then this name MUST be assigned a lookupResultsIndex of 1. If a lookup operation was performed for a certain symbolic name by using getaddrinfo() or gethostbyname(), for example, then entries in the lookupResultsTable MUST be made for each address returned. The entries MUST be stored in the order that they are retrieved. Values assigned to lookupResultsIndex MUST start at 1 and increase in order. An implementation SHOULD NOT retain SNMP-created entries in the lookupResultsTable across reIPLs (Initial Program Loads) of its agent, since management applications need to see consistent behavior with respect to the persistence of the table entries that they create.

3.4. Conformance

Each of the three MIB modules defined in this document has two current compliance statements, one for full compliance and one for minimum compliance. The minimum compliance statements are intended to be applied to implementation for devices with very limited resources. The main difference between full and minimum compliance is that for minimum compliance, dynamic creation and deletion of table entries is not required, whereas it is required for full compliance.
Top   ToC   RFC4560 - Page 13
   In addition, the DISMAN-PING-MIB module and the DISMAN-TRACEROUTE-MIB
   modules each have a deprecated compliance statement that was current
   in RFC 2925.  Semantically, the new full compliance statements are
   identical to the deprecated ones.  But some of the object groups used
   in the old compliance statements needed to be split in order to
   support the new minimal compliance statements.



(page 13 continued on part 2)

Next Section