rfc2576.txt

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

      (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 parameter will actually consist
         of three values, the contextSnmpEngineID, the contextName, and
         the PDU.  These must be separate values, since the first two do
         not actually appear in the message.

      -  The maxSizeResponseScopedPDU.

      -  The securityStateReference.

   The appropriate SNMP application will then be called (depending on
   the value of the contextEngineID and the request type in the PDU)
   using the processPdu ASI.  The parameters passed to this ASI are:

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

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

      -  The securityName, which was returned from the call to
         processIncomingMsg.

      -  The securityLevel, which is noAuthNoPriv.

      -  The contextEngineID, which was returned as part of the
         ScopedPDU from the call to processIncomingMsg.

      -  The contextName, which was returned as part of the ScopedPDU
         from the call to processIncomingMsg.

      -  The pduVersion, which should indicate an SNMPv1 version PDU (if
         the message version was SNMPv2c, this would be an SNMPv2
         version PDU).





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


      -  The PDU, which was returned as part of the ScopedPDU from the
         call to processIncomingMsg.

      -  The maxSizeResp