rfc2576.txt

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

      -  A list of variable-bindings (VarBindList).  This refers to all
         but the first two variable-bindings in an SNMPv2-Trap-PDU or
         InformRequest-PDU.



Frye, et al.                Standards Track                    [Page 11]

RFC 2576           Coexistence between SNMP versions          March 2000


3.1.  Translating SNMPv1 Notification Parameters to SNMPv2 Notification
      Parameters

   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.

   (2)  If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)',
        the SNMPv2 snmpTrapOID parameter SHALL be the concatentation 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 RFC1907
        [12]:

    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 [12], and the value SHALL be the SNMPv1
        enterprise parameter.







Frye, et al.                Standards Track                    [Page 12]

RFC 2576           Coexistence between SNMP versions          March 2000


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 RFC1907 [12], then the SNMPv1 enterprise
         parameter SHALL be set to the value of the variable-binding in
         the SNMPv2 variable-bindings whose name is 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 RFC1907 [12].

      -  If the SNMPv2 snmpTrapOID parameter is not one of the standard
         traps as defined in RFC1907 [12], 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 is
            zero, then the SNMPv1 enterprise SHALL be the SNMPv2
            snmpTrapOID with the last 2 sub-identifiers removed,
            otherwise

         -  If the next-to-last sub-identifier of the snmpTrapOID is
            non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2
            snmpTrapOID 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.




Frye, et al.                Standards Track                    [Page 13]

RFC 2576           Coexistence between SNMP versions          March 2000


   (3)  If the SNMPv2 snmpTrapOID parameter is one of the standard traps
        as defined in RFC1907 [12], 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

        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 RFC1907 [12], 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.  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.1.3 and section 4.2).

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.



Frye, et al.                Standards Track                    [Page 14]

RFC 2576           Coexistence between SNMP versions          March 2000


4.1.  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.1.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
   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.1.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.  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 some combination of SNMPv1 and SNMPv2 access to MIB data.




Frye, et al.                Standards Track                    [Page 15]

RFC 2576           Coexistence between SNMP versions          March 2000


4.1.2.1.  Handling Counter64

   The SMIv2 [7] 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-
         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, then an error-status of noSuchName SHALL be returned,
         and the error-index SHALL be set to the variable binding that
         caused this error.

      -  Any SNMPv1 request which contains a variable binding with a
         Counter64 value is ill-formed, so the foregoing rules do not
         apply.  If that error is detected, a response SHALL NOT be
         returned, since it would contain a copy of the ill-formed
         variable binding.  Instead, the offending PDU SHALL be
         discarded and the counter snmpInASNParseErrs SHALL be
         incremented.

4.1.2.2.  Mapping SNMPv2 Exceptions

   SNMPv2 provides a feature called exceptions, which allow an SNMPv2
   Response PDU to return as much management information as possible,
   even when an error occurs.  However, SNMPv1 does not support
   exceptions, and so an SNMPv1 Response PDU cannot return any
   management information, and can only return an error-status and
   error-index value.






Frye, et al.                Standards Track                    [Page 16]

RFC 2576           Coexistence between SNMP versions          March 2000


   When an SNMPv1 request is received, a command responder MUST check
   any variable bindings returned using SNMPv2 access to MIB data for
   exception values, and convert these exception values into SNMPv1
   error codes.

   The type of exception that can be returned when accessing MIB data
   and the action taken depends on the type of SNMP request.

      -  For a GetRequest, a noSuchObject or noSuchInstance exception
         may be returned.

      -  For a GetNextRequest, an endOfMibView exception may be
         returned.