RFC 2925
Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations
Network Working Group K. White Request for Comments: 2925 IBM Corp. Category: Standards Track September 2000 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 (2000). All Rights Reserved.Abstract
This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an 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.Table of Contents
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2.0 The SNMP Network Management Framework . . . . . . . . . . . 4 3.0 Structure of the MIBs . . . . . . . . . . . . . . . . . . . 5 3.1 Ping MIB . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1 pingMaxConcurrentRequests . . . . . . . . . . . . . . . 6 3.1.2 pingCtlTable . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3 pingResultsTable . . . . . . . . . . . . . . . . . . . . 7 3.1.4 pingProbeHistoryTable . . . . . . . . . . . . . . . . . 7 3.2 Traceroute MIB . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1 traceRouteMaxConcurrentRequests . . . . . . . . . . . . 8 3.2.2 traceRouteCtlTable . . . . . . . . . . . . . . . . . . . 8 3.2.3 traceRouteResultsTable . . . . . . . . . . . . . . . . . 9
3.2.4 traceRouteProbeHistoryTable . . . . . . . . . . . . . . 9
3.2.5 traceRouteHopsTable . . . . . . . . . . . . . . . . . . 10
3.3 Lookup MIB . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1 lookupMaxConcurrentRequests and lookupPurgeTime . . . . 10
3.3.2 lookupCtlTable . . . . . . . . . . . . . . . . . . . . . 10
3.3.3 lookupResultsTable . . . . . . . . . . . . . . . . . . . 11
4.0 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 DISMAN-PING-MIB . . . . . . . . . . . . . . . . . . . . . . 12
4.2 DISMAN-TRACEROUTE-MIB . . . . . . . . . . . . . . . . . . . 36
4.3 DISMAN-NSLOOKUP-MIB . . . . . . . . . . . . . . . . . . . . 63
5.0 Security Considerations . . . . . . . . . . . . . . . . . . 73
6.0 Intellectual Property . . . . . . . . . . . . . . . . . . . 74
7.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 74
8.0 References . . . . . . . . . . . . . . . . . . . . . . . . . 74
9.0 Author's Address . . . . . . . . . . . . . . . . . . . . . . 76
10.0 Full Copyright Statement . . . . . . . . . . . . . . . . . 77
1.0 Introduction
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, reference
[13].
This document is a product of the Distributed Management (DISMAN)
Working Group. Its purpose is to define 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 if a path exists
between two hosts while traceroute shows an actual path. 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, some of which are:
o Using the UDP echo port (7), if supported.
This is defined by RFC 862 [2].
o Timing an 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 they are handled at lower priority, hence possibly giving false indications of round trip times. It must be noted 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 requests 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 also is important to the 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. 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 [20]:
"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." 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 operation enables the equivalent of either a gethostbyname() or a gethostbyaddr() call being performed at a remote host. The Lookup gethostbyname() capability can be used to determine the symbolic name of a hop in a traceroute path. Consider the following diagram: +--------------------------------------------------------------------+ | | | Remote ping, traceroute, Actual ping, traceroute, | | +-----+or Lookup op. +------+or Lookup op. +------+ | | |Local|---------------->|Remote|---------------->|Target| | | | Host| | Host | | Host | | | +-----+ +------+ +------+ | | | | | +--------------------------------------------------------------------+ A local host is the host from which the remote ping, traceroute, or Lookup operation is initiated using an SNMP request. The remote host is a host where the MIBs defined by this memo are implemented that receives the remote operation via SNMP and performs the actual ping, traceroute, or lookup function.2.0 The SNMP Network Management Framework
The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [7]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [14], STD 16, RFC 1212 [15] and RFC 1215 [16]. The second version, called SMIv2, is described in STD 58, RFC 2578 [3], STD 58, RFC 2579 [4] and STD 58, RFC 2580 [5].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [1]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [17] and
RFC 1906 [18]. The third version of the message protocol is
called SNMPv3 and described in RFC 1906 [18], RFC 2572 [8] and
RFC 2574 [10].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [1]. A second set of protocol
operations and associated PDU formats is described in RFC 1905
[6].
o A set of fundamental applications described in RFC 2573 [9] and
the view-based access control mechanism described in RFC 2575
[11].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
This memo specifies MIB modules that are compliant to the SMIv2. A
MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the
MIB.
3.0 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 the resolver gethostbyname() and
gethostbyaddr() functions at a remote host.
The ping and traceroute MIBs are structured to allow creation of ping
or traceroute tests that can be set up to periodically issue a series
of operations and 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 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
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 2575 [11], VACM) and allows a management application to identify its entries. The send 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 taking at most 15 minutes (pingCtlTimeOut times pingCtlProbeCount) plus whatever time it takes to send the ping request and 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 is 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.3.1.4 pingProbeHistoryTable
The results of past ping probes can be stored in this table on a per pingCtlEntry basis. This table is initially indexed by pingCtlOwnerIndex and pingCtlTestName in order for the results of a probe to 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 to allow the addition of an new entry once the number of rows in the pingProbeHistoryTable reaches the value specified by pingCtlMaxRows. 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 traceRouteHopsTable3.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 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 2575 [11], VACM) and 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 complete. The maximum 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 is 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 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 in order for the results of a probe to 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 to allow the addition of an new entry once the number of rows in the traceRouteProbeHistoryTable reaches the value of traceRouteCtlMaxRows. 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 in order for a
traceroute path to relate 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
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 completes.
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 an 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 of type SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-Based Access Control Model (RFC 2575 [11], VACM) and 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 the gethostbyname function 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 the gethostbyaddr function should be performed to determine the symbolic name(s) associated with a numeric address at a remote host.3.3.3 lookupResultsTable
The lookupResultsTable is used to store the results of lookup operations. 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. Both the gethostbyname and gethostbyaddr functions typically return a pointer to a hostent structure after being called. The hostent structure is defined as: struct hostent { char *h_name; /* official host name */ char *h_aliases[]; /* list of other aliases */ int h_addrtype; /* host address type */ int h_length; /* length of host address */ char **h_addr_list; /* list of address for host */ }; The hostent structure is listed here in order to address the fact that a remote host can be multi-homed and can have multiple symbolic (DNS) names. It is not intended to imply that implementations of the DISMAN-LOOKUP-MIB are limited to systems where the hostent structure is supported.
The gethostbyaddr function is called with a host address as its parameter and is used primarily to determine a symbolic name to associate with the host address. Entries in the lookupResultsTable MUST be made for each host name returned. The official host name MUST be assigned a lookupResultsIndex of 1. The gethostbyname function is called with a symbolic host name and is used primarily to retrieve a host address. Normally, the first h_addr_list host address is considered to be the primary address and as such is associated with the symbolic name passed on the call. Entries MUST be stored in the lookupResultsTable 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 lookupTable 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.
(page 12 continued on part 2)
