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.

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

   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.