rfc2576.txt

RFC 的详细文档！

      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 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-
      bindings field, and change the error-status field to 'noError'
      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.'

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

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




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


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

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

   -  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, the error-status value is modified using
      the mappings in section 4.3.

   -  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




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


      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.

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






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


   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.

5.  Message Processing Models and Security Models

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

      -  The SNMPv1 Message Processing Model

      -  The SNMPv1 Community-Based Security Model

   The following models are also described in this document:

      -  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 [16].  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.









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


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 RFC1157 [2], with differences and
   clarifications as described in the following sections.  The
   SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for
   SNMPv2c is 1).

5.2.1.  Processing An Incoming Request

   In RFC1157 [2], 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




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


         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 RFC1157 [2], and the snmpInBadCommunityNames counter is
   incremented.

   The parameters returned from the Community-Based Security Model are:

      -  The securityEngineID, which will always be the local value of
         snmpEngineID.0.

      -  The securityName.

      -  The scopedPDU.  Note that this param