rfc3584.txt

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

   -  If a GetResponse-PDU is received whose error-status field has a
      value of 'tooBig', and the message will be forwarded using the
      SNMPv2c or SNMPv3 message version, and the original request
      received by the proxy was not a GetBulkRequest-PDU, the proxy
      forwarder SHALL remove the contents of the variable-bindings field
      and ensure that the error-index field is set to 0 before
      forwarding the response.

   -  If a GetResponse-PDU is received whose error-status field has a
      value of 'tooBig', and the message will be forwarded using the
      SNMPv2c or SNMPv3 message version, and the original request
      received by the proxy was a GetBulkRequest-PDU, the proxy
      forwarder SHALL re-send the forwarded request (which would have
      been altered to be a GetNextRequest-PDU) with all but the first
      variable-binding removed.  The proxy forwarder SHALL only re-send
      such a request a single time.  If the resulting GetResponse-PDU
      also contains an error-status field with a value of 'tooBig', then
      the proxy forwarder SHALL remove the contents of the variable-



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


      bindings field, and change the error-status field to 'noError',
      and ensure that the error-index field is set to 0 before
      forwarding the response.  Note that if the original request only
      contained a single variable-binding, the proxy may skip re-sending
      the request and simply remove the variable-bindings and change the
      error-status to 'noError'.  Further note that, while it might have
      been possible to fit more variable bindings if the proxy only re-
      sent the request multiple times, and stripped only a single
      variable binding from the request at a time, this is deemed too
      expensive.  The approach described here preserves the behaviour of
      a GetBulkRequest as closely as possible, without incurring the
      cost of re-sending the request multiple times.

   -  If a Trap-PDU is received, and will be forwarded using the SNMPv2c
      or SNMPv3 message version, the proxy SHALL apply the translation
      rules described in section 3, and SHALL forward the notification
      as an SNMPv2-Trap-PDU.

      Note that when an SNMPv1 agent generates a message containing a
      Trap-PDU which is subsequently forwarded by one or more proxy
      forwarders using SNMP versions other than SNMPv1, the community
      string and agent-addr fields from the original message generated
      by the SNMPv1 agent will be preserved through the use of the
      snmpTrapAddress and snmpTrapCommunity objects.

4.3.2.  Upstream Version Less Than Downstream Version

   -  If a GetResponse-PDU is received in response to a GetRequest-PDU
      (previously generated by the proxy) which contains variable-
      bindings of type Counter64 or which contain an SNMPv2 exception
      code, and the message would be forwarded using the SNMPv1 message
      version, the proxy MUST generate an alternate response PDU
      consisting of the request-id and variable bindings from the
      original SNMPv1 request, containing a noSuchName error-status
      value, and containing an error-index value indicating the position
      of the variable-binding containing the Counter64 type or exception
      code.

   -  If a GetResponse-PDU is received in response to a GetNextRequest-
      PDU (previously generated by the proxy) which contains variable-
      bindings that contain an SNMPv2 exception code, and the message
      would be forwarded using the SNMPv1 message version, the proxy
      MUST generate an alternate response PDU consisting of the
      request-id and variable bindings from the original SNMPv1 request,
      containing a noSuchName error-status value, and containing an
      error-index value indicating the position of the variable-binding
      containing the exception code.




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


   -  If a GetResponse-PDU is received in response to a GetNextRequest-
      PDU (previously generated by the proxy) which contains variable-
      bindings of type Counter64, the proxy MUST re-send the entire
      GetNextRequest-PDU, with the following modifications.  For any
      variable bindings in the received GetResponse which contained
      Counter64 types, the proxy substitutes the object names of these
      variable bindings for the corresponding object names in the
      previously-sent GetNextRequest.  The proxy MUST repeat this
      process until no Counter64 objects are returned.  Note that an
      implementation may attempt to optimize this process of skipping
      Counter64 objects.  One approach to such an optimization would be
      to replace the last sub-identifier of the object names of varbinds
      containing a Counter64 type with 65535 if that sub-identifier is
      less than 65535, or with 4294967295 if that sub-identifier is
      greater than 65535.  This approach should skip multiple instances
      of the same Counter64 object, while maintaining compatibility with
      some broken agent implementations (which only use 16-bit integers
      for sub-identifiers).

      Deployment Hint:  The process of repeated GetNext requests used by
      a proxy when Counter64 types are returned can be expensive.  When
      deploying a proxy, this can be avoided by configuring the target
      agents to which the proxy forwards requests in a manner such that
      any objects of type Counter64 are in fact not-in-view for the
      principal that the proxy is using when communicating with these
      agents.  However, when using such a configuration, one should be
      careful to use a different principal for communicating with the
      target agent when an incoming SNMPv2c or SNMPv3 request is
      received, to ensure that objects of type Counter64 are properly
      returned.

   -  If a GetResponse-PDU is received which contains an SNMPv2 error-
      status value of wrongValue, wrongEncoding, wrongType, wrongLength,
      inconsistentValue, noAccess, notWritable, noCreation,
      inconsistentName, resourceUnavailable, commitFailed, undoFailed,
      or authorizationError, and the message would be forwarded using
      the SNMPv1 message version, the error-status value is modified
      using the mappings in section 4.4.

   -  If an SNMPv2-Trap-PDU is received, and will be forwarded using the
      SNMPv1 message version, the proxy SHALL apply the translation
      rules described in section 3, and SHALL forward the notification
      as a Trap-PDU.  Note that if the translation fails due to the
      existence of a Counter64 data-type in the received SNMPv2-Trap-
      PDU, the trap cannot be forwarded using SNMPv1.






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


   -  If an InformRequest-PDU is received, any configuration information
      indicating that it would be forwarded using the SNMPv1 message
      version SHALL be ignored.  An InformRequest-PDU can only be
      forwarded using the SNMPv2c or SNMPv3 message version.  The
      InformRequest-PDU may still be forwarded if there is other
      configuration information indicating that it should be forwarded
      using SNMPv2c or SNMPv3.

4.4.  Error Status Mappings

   The following tables shows the mappings of SNMPv1 error-status values
   into SNMPv2 error-status values, and the mappings of SNMPv2 error-
   status values into SNMPv1 error-status values.

      SNMPv1 error-status    SNMPv2 error-status
      ===================    ===================
      noError                noError
      tooBig                 tooBig
      noSuchName             noSuchName
      badValue               badValue
      genErr                 genErr


      SNMPv2 error-status    SNMPv1 error-status
      ===================    ===================
      noError                noError
      tooBig                 tooBig
      genErr                 genErr
      wrongValue             badValue
      wrongEncoding          badValue
      wrongType              badValue
      wrongLength            badValue
      inconsistentValue      badValue
      noAccess               noSuchName
      notWritable            noSuchName
      noCreation             noSuchName
      inconsistentName       noSuchName
      resourceUnavailable    genErr
      commitFailed           genErr
      undoFailed             genErr
      authorizationError     noSuchName

   Whenever the SNMPv2 error-status value of authorizationError is
   translated to an SNMPv1 error-status value of noSuchName, the value
   of snmpInBadCommunityUses MUST be incremented.






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


5.  Message Processing Models and Security Models

   In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture,
   the following Message Processing (MP) models are defined in this
   document:

   -  The SNMPv1 Message Processing Model

   -  The SNMPv1 Community-Based Security Model

   -  The SNMPv2c Message Processing Model

   -  The SNMPv2c Community-Based Security Model

   In most respects, the SNMPv1 Message Processing Model and the SNMPv2c
   Message Processing Model are identical, and so these are not
   discussed independently in this document.  Differences between the
   two models are described as required.

   Similarly, the SNMPv1 Community-Based Security Model and the SNMPv2c
   Community-Based Security Model are nearly identical, and so are not
   discussed independently.  Differences between these two models are
   also described as required.

5.1.  Mappings

   The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model
   require mappings between parameters used in SNMPv1 (and SNMPv2c)
   messages, and the version independent parameters used in the SNMP
   architecture [RFC3411].  The parameters which MUST be mapped consist
   of the SNMPv1 (and SNMPv2c) community name, and the SNMP securityName
   and contextEngineID/contextName pair.  A MIB module (the SNMP-
   COMMUNITY-MIB) is provided in this document in order to perform these
   mappings.  This MIB provides mappings in both directions, that is, a
   community name may be mapped to a securityName, contextEngineID, and
   contextName, or the combination of securityName, contextEngineID, and
   contextName may be mapped to a community name.

5.2.  The SNMPv1 MP Model and SNMPv1 Community-based Security Model

   The SNMPv1 Message Processing Model handles processing of SNMPv1
   messages.  The processing of messages is handled generally in the
   same manner as described in RFC 1157 [RFC1157], with differences and
   clarifications as described in the following sections.  The
   SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for
   SNMPv2c is 1).





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


5.2.1.  Processing An Incoming Request

   In RFC 1157 [RFC1157], section 4.1, item (3) for an entity which
   receives a message, states that various parameters are passed to the
   "desired authentication scheme".  The desired authentication scheme
   in this case is the SNMPv1 Community-Based Security Model, which will
   be called using the processIncomingMsg ASI.  The parameters passed to
   this ASI are:

   -  The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).

   -  The maxMessageSize, which should be the maximum size of a message
      that the receiving entity can generate (since there is no such
      value in the received message).

   -  The securityParameters, which consist of the community string and
      the message's source and destination transport domains and
      addresses.

   -  The securityModel, which will be 1 (or 2 for SNMPv2c).

   -  The securityLevel, which will be noAuthNoPriv.

   -  The wholeMsg and wholeMsgLength.

   The Community-Based Security Model will attempt to select a row in
   the snmpCommunityTable.  This is done by performing a search through
   the snmpCommunityTable in lexicographic order.  The first entry for
   which the following matching criteria are satisfied will be selected:

   -  The community string is equal to the snmpCommunityName value.

   -  If the snmpCommunityTransportTag is an empty string, it is ignored
      for the purpose of matching.  If the snmpCommunityTransportTag is
      not an empty string, the transportDomain and transportAddress from
      which the message was received must match one of the entries in
      the snmpTargetAddrTable selected by the snmpCommunityTransportTag
      value.  The snmpTargetAddrTMask object is used as described in
      section 5.3 when checking whether the transportDomain and
      transportAddress matches a entry in the snmpTargetAddrTable.

   If no such entry can be found, an authentication failure occurs as
   described in RFC 1157 [RFC1157], and the snmpInBadCommunityNames
   counter is incremented.







Frye, et al.             Best Current Practice