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.
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
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.
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."
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].
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
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.
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
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
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
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.
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