rfc2925.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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



White                       Standards Track                     [Page 1]

RFC 2925           Ping, Traceroute, and Lookup MIBs      September 2000


     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



White                       Standards Track                     [Page 2]

RFC 2925           Ping, Traceroute, and Lookup MIBs      September 2000


   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]:





White                       Standards Track                     [Page 3]

RFC 2925           Ping, Traceroute, and Lookup MIBs      September 2000


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






White                       Standards Track                     [Page 4]

RFC 2925           Ping, Traceroute, and Lookup MIBs      September 2000


   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.







White                       Standards Track                     [Page 5]

RFC 2925           Ping, Traceroute, and Lookup MIBs      September 2000


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






White                       Standards Track                     [Page 6]

RFC 2925           Ping, Traceroute, and Lookup MIBs      September 2000


   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.