rfc3584.txt

开发snmp的开发包有两个开放的SNMP开发库

   The following procedure describes how to translate SNMPv1
   notification parameters into SNMPv2 notification parameters:

   (1)  The SNMPv2 sysUpTime parameter SHALL be taken directly from the
        SNMPv1 time-stamp parameter.






Frye, et al.             Best Current Practice                 [Page 11]

RFC 3584           Coexistence between SNMP versions         August 2003


   (2)  If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)',
        the SNMPv2 snmpTrapOID parameter SHALL be the concatenation of
        the SNMPv1 enterprise parameter and two additional sub-
        identifiers, '0', and the SNMPv1 specific-trap parameter.

   (3)  If the SNMPv1 generic-trap parameter is not
        'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL
        be the corresponding trap as defined in section 2 of RFC 3418
        [RFC3418]:

        generic-trap
        parameter      snmpTrapOID.0
        ============   =============
        0              1.3.6.1.6.3.1.1.5.1 (coldStart)
        1              1.3.6.1.6.3.1.1.5.2 (warmStart)
        2              1.3.6.1.6.3.1.1.5.3 (linkDown)
        3              1.3.6.1.6.3.1.1.5.4 (linkUp)
        4              1.3.6.1.6.3.1.1.5.5 (authenticationFailure)
        5              1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)

   (4)  The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-
        bindings.  In addition, if the translation is being performed by
        a proxy in order to forward a received trap, three additional
        variable-bindings will be appended, if these three additional
        variable-bindings do not already exist in the SNMPv1 variable-
        bindings.  The name portion of the first additional variable
        binding SHALL contain snmpTrapAddress.0, and the value SHALL
        contain the SNMPv1 agent-addr parameter.  The name portion of
        the second additional variable binding SHALL contain
        snmpTrapCommunity.0, and the value SHALL contain the value of
        the community-string field from the received SNMPv1 message
        which contained the SNMPv1 Trap-PDU.  The name portion of the
        third additional variable binding SHALL contain
        snmpTrapEnterprise.0 [RFC3418], and the value SHALL be the
        SNMPv1 enterprise parameter.

3.2.  Translating SNMPv2 Notification Parameters to SNMPv1 Notification
      Parameters

   The following procedure describes how to translate SNMPv2
   notification parameters into SNMPv1 notification parameters:

   (1)  The SNMPv1 enterprise parameter SHALL be determined as follows:

      -   If the SNMPv2 snmpTrapOID parameter is one of the standard
          traps as defined in RFC 3418 [RFC3418], then the SNMPv1
          enterprise parameter SHALL be set to the value of the
          variable-binding in the SNMPv2 variable-bindings whose name is



Frye, et al.             Best Current Practice                 [Page 12]

RFC 3584           Coexistence between SNMP versions         August 2003


          snmpTrapEnterprise.0 if that variable-binding exists.  If it
          does not exist, the SNMPv1 enterprise parameter SHALL be set
          to the value 'snmpTraps' as defined in RFC 3418 [RFC3418].

      -   If the SNMPv2 snmpTrapOID parameter is not one of the standard
          traps as defined in RFC 3418 [RFC3418], then the SNMPv1
          enterprise parameter SHALL be determined from the SNMPv2
          snmpTrapOID parameter as follows:

          -  If the next-to-last sub-identifier of the snmpTrapOID value
             is zero, then the SNMPv1 enterprise SHALL be the SNMPv2
             snmpTrapOID value with the last 2 sub-identifiers removed,
             otherwise

          -  If the next-to-last sub-identifier of the snmpTrapOID value
             is non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2
             snmpTrapOID value with the last sub-identifier removed.

   (2)  The SNMPv1 agent-addr parameter SHALL be determined based on the
        situation in which the translation occurs.

      -   If the translation occurs within a notification originator
          application, and the notification is to be sent over IP, the
          SNMPv1 agent-addr parameter SHALL be set to the IP address of
          the SNMP entity in which the notification originator resides.
          If the notification is to be sent over some other transport,
          the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0.

      -   If the translation occurs within a proxy application, the
          proxy must attempt to extract the original source of the
          notification from the variable-bindings.  If the SNMPv2
          variable-bindings contains a variable binding whose name is
          snmpTrapAddress.0, the agent-addr parameter SHALL be set to
          the value of that variable binding.  Otherwise, the SNMPv1
          agent-addr parameter SHALL be set to 0.0.0.0.

   (3)  If the SNMPv2 snmpTrapOID parameter is one of the standard traps
        as defined in RFC 3418 [RFC3418], the SNMPv1 generic-trap
        parameter SHALL be set as follows:

        snmpTrapOID.0 parameter               generic-trap
        ===============================       ============
        1.3.6.1.6.3.1.1.5.1 (coldStart)                  0
        1.3.6.1.6.3.1.1.5.2 (warmStart)                  1
        1.3.6.1.6.3.1.1.5.3 (linkDown)                   2
        1.3.6.1.6.3.1.1.5.4 (linkUp)                     3
        1.3.6.1.6.3.1.1.5.5 (authenticationFailure)      4
        1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)            5



Frye, et al.             Best Current Practice                 [Page 13]

RFC 3584           Coexistence between SNMP versions         August 2003


        Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6.

   (4)  If the SNMPv2 snmpTrapOID parameter is one of the standard traps
        as defined in RFC 3418 [RFC3418], the SNMPv1 specific-trap
        parameter SHALL be set to zero.  Otherwise, the SNMPv1
        specific-trap parameter SHALL be set to the last sub-identifier
        of the SNMPv2 snmpTrapOID parameter.

   (5)  The SNMPv1 time-stamp parameter SHALL be taken directly from the
        SNMPv2 sysUpTime parameter.

   (6)  The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-
        bindings (and note that the SNMPv2 variable-bindings do not
        include the variable-bindings containing sysUpTime.0,
        snmpTrapOID.0).  Note, however, that if the SNMPv2 variable-
        bindings contain any objects whose type is Counter64, the
        translation to SNMPv1 notification parameters cannot be
        performed.  In this case, the notification cannot be encoded in
        an SNMPv1 packet (and so the notification cannot be sent using
        SNMPv1, see section 4.2.3 and section 4.3).

4.  Approaches to Coexistence in a Multi-lingual Network

   There are two basic approaches to coexistence in a multi-lingual
   network, multi-lingual implementations and proxy implementations.
   Multi-lingual implementations allow elements in a network to
   communicate with each other using an SNMP version which both elements
   support.  This allows a multi-lingual implementation to communicate
   with any mono-lingual implementation, regardless of the SNMP version
   supported by the mono-lingual implementation.

   Proxy implementations provide a mechanism for translating between
   SNMP versions using a third party network element.  This allows
   network elements which support only a single, but different, SNMP
   version to communicate with each other.  Proxy implementations are
   also useful for securing communications over an insecure link between
   two locally secure networks.

4.1.  SNMPv1 and SNMPv2 Access to MIB Data

   Throughout section 4., this document refers to 'SNMPv1 Access to MIB
   Data' and 'SNMPv2 Access to MIB Data'.  These terms refer to the part
   of an SNMP agent which actually accesses instances of MIB objects,
   and which actually initiates generation of notifications.
   Differences between the two types of access to MIB data are:

   -  Error-status values generated.




Frye, et al.             Best Current Practice                 [Page 14]

RFC 3584           Coexistence between SNMP versions         August 2003


   -  Generation of exception codes.

   -  Use of the Counter64 data type.

   -  The format of parameters provided when a notification is
      generated.

   SNMPv1 access to MIB data may generate SNMPv1 error-status values,
   will never generate exception codes nor use the Counter64 data type,
   and will provide SNMPv1 format parameters for generating
   notifications.  Note also that SNMPv1 access to MIB data will
   actually never generate a readOnly error (a noSuchName error would
   always occur in the situation where one would expect a readOnly
   error).

   SNMPv2 access to MIB data may generate SNMPv2 error-status values,
   may generate exception codes, may use the Counter64 data type, and
   will provide SNMPv2 format parameters for generating notifications.
   Note that SNMPv2 access to MIB data will never generate readOnly,
   noSuchName, or badValue errors.

   Note that a particular multi-lingual implementation may choose to
   implement all access to MIB data as SNMPv2 access to MIB data, and
   perform the translations described herein for SNMPv1-based
   transactions.

   Further, note that there is no mention of 'SNMPv3 access to MIB data'
   in this document, as SNMPv3 uses SNMPv2 PDU types and protocol
   operations.

4.2.  Multi-lingual implementations

   This approach requires an entity to support multiple SNMP message
   versions.  Typically this means supporting SNMPv1, SNMPv2c, and
   SNMPv3 message versions.  The behaviour of various types of SNMP
   applications which support multiple message versions is described in
   the following sections.  This approach allows entities which support
   multiple SNMP message versions to coexist with and communicate with
   entities which support only a single SNMP message version.

4.2.1.  Command Generator

   A command generator must select an appropriate message version when
   sending requests to another entity.  One way to achieve this is to
   consult a local database to select the appropriate message version.

   In addition, a command generator MUST 'downgrade' GetBulk requests to
   GetNext requests when selecting SNMPv1 as the message version for an



Frye, et al.             Best Current Practice                 [Page 15]

RFC 3584           Coexistence between SNMP versions         August 2003


   outgoing request.  This is done by simply changing the operation type
   to GetNext, ignoring any non-repeaters and max-repetitions values,
   and setting error-status and error-index to zero.

4.2.2.  Command Responder

   A command responder must be able to deal with both SNMPv1 and SNMPv2
   access to MIB data.  There are three aspects to dealing with this.  A
   command responder must:

   -  Deal correctly with SNMPv2 access to MIB data that returns a
      Counter64 value while processing an SNMPv1 message,

   -  Deal correctly with SNMPv2 access to MIB data that returns one of
      the three exception values while processing an SNMPv1 message, and

   -  Map SNMPv2 error codes returned from SNMPv2 access to MIB data
      into SNMPv1 error codes when processing an SNMPv1 message.

   Note that SNMPv1 error codes SHOULD NOT be used without any change
   when processing SNMPv2c or SNMPv3 messages, except in the case of
   proxy forwarding.  Also, SNMPv1 access to MIB data SHOULD NOT be used
   when processing SNMPv2c or SNMPv3 messages.  In the case of proxy
   forwarding, for backwards compatibility, SNMPv1 error codes may be
   used without any change in a forwarded SNMPv2c or SNMPv3 message.

   The following sections describe the behaviour of a command responder
   application which supports multiple SNMP message versions, and which
   uses SNMPv2 access to MIB data when processing an SNMPv1 message.

4.2.2.1.  Handling Counter64

   The SMIv2 [RFC2578] defines one new syntax that is incompatible with
   SMIv1.  This syntax is Counter64.  All other syntaxes defined by
   SMIv2 are compatible with SMIv1.

   The impact on multi-lingual command responders is that they MUST NOT
   ever return a variable binding containing a Counter64 value in a
   response to a request that was received using the SNMPv1 message
   version.

   Multi-lingual command responders SHALL take the approach that object
   instances whose type is Counter64 are implicitly excluded from view
   when processing an SNMPv1 message.  So:

   -  On receipt of an SNMPv1 GetRequest-PDU containing a variable
      binding whose name field points to an object instance of type
      Counter64, a GetResponsePDU SHALL be returned, with an error-



Frye, et al.             Best Current Practice                 [Page 16]

RFC 3584           Coexistence between SNMP versions         August 2003


      status of noSuchName and the error-index set to the variable
      binding that caused this error.

   -  On an SNMPv1 GetNextRequest-PDU, any object instance which
      contains a syntax of Counter64 SHALL be skipped, and the next
      accessible object instance that does not have the syntax of
      Counter64 SHALL be retrieved.  If no such object instance exists,