Network Working Group R. Frye Request for Comments: 3584 Vibrant Solutions BCP: 74 D. Levi Obsoletes: 2576 Nortel Networks Category: Best Current Practice S. Routhier Wind River Systems, Inc. B. Wijnen Lucent Technologies August 2003 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.
AbstractThe purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576.
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. SNMPv1 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. SNMPv2 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . 5 2. SMI and Management Information Mappings. . . . . . . . . . . 5 2.1. MIB Modules. . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Object Definitions . . . . . . . . . . . . . . 6 2.1.2. Trap and Notification Definitions . . . . . . 8 2.2. Compliance Statements. . . . . . . . . . . . . . . . . 9 2.3. Capabilities Statements. . . . . . . . . . . . . . . . 9 3. Translating Notification Parameters. . . . . . . . . . . . . 10 3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification Parameters . . . . . . . . . . . . 11 3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification Parameters . . . . . . . . . . . . 12 4. Approaches to Coexistence in a Multi-lingual Network . . . . 14 4.1. SNMPv1 and SNMPv2 Access to MIB Data . . . . . . . . . 14 4.2. Multi-lingual implementations. . . . . . . . . . . . . 15 4.2.1. Command Generator. . . . . . . . . . . . . . . 15 4.2.2. Command Responder. . . . . . . . . . . . . . . 16 126.96.36.199. Handling Counter64 . . . . . . . . . 16 188.8.131.52. Mapping SNMPv2 Exceptions. . . . . . 17 184.108.40.206.1. Mapping noSuchObject and noSuchInstance. . . . 18 220.127.116.11.2. Mapping endOfMibView. . . 18 18.104.22.168. Processing An SNMPv1 GetReques . . . 18 22.214.171.124. Processing An SNMPv1 GetNextRequest. 19 126.96.36.199. Processing An SNMPv1 SetRequest. . . 20 4.2.3. Notification Originator. . . . . . . . . . . . 21 4.2.4. Notification Receiver. . . . . . . . . . . . . 21 4.3. Proxy Implementations. . . . . . . . . . . . . . . . . 22 4.3.1. Upstream Version Greater Than Downstream Version. . . . . . . . . . . . . . . . . . . . 22 4.3.2. Upstream Version Less Than Downstream Version. 23 4.4. Error Status Mappings. . . . . . . . . . . . . . . . . 25 5. Message Processing Models and Security Models. . . . . . . . 26 5.1. Mappings . . . . . . . . . . . . . . . . . . . . . . . 26 5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model . . . . . . . . . . . . . . . . . . . . 26 5.2.1. Processing An Incoming Request . . . . . . . . 27 5.2.2. Generating An Outgoing Response. . . . . . . . 29 5.2.3. Generating An Outgoing Notification. . . . . . 29 5.2.4. Proxy Forwarding Of Requests . . . . . . . . . 30 5.3. The SNMP Community MIB Module. . . . . . . . . . . . . 30 6. Intellectual Property Statement. . . . . . . . . . . . . . . 42 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 43
8. Security Considerations. . . . . . . . . . . . . . . . . . . 43 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 9.1. Normative References . . . . . . . . . . . . . . . . . 44 9.2. Informative References . . . . . . . . . . . . . . . . 46 Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 47 A.1. Changes From RFC 2576 . . . . . . . . . . . . . . . . . 47 A.2. Changes Between RFC 1908 and RFC 2576 . . . . . . . . . 49 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 51 RFC2119]. There are four general aspects of coexistence described in this document. Each of these is described in a separate section: - Conversion of MIB documents between SMIv1 and SMIv2 formats is documented in section 2. - Mapping of notification parameters is documented in section 3. - Approaches to coexistence between entities which support the various versions of SNMP in a multi-lingual network is documented in section 4. This section addresses the processing of protocol operations in multi-lingual implementations, as well as behaviour of proxy implementations. - The SNMPv1 Message Processing Model and Community-Based Security Model, which provides mechanisms for adapting SNMPv1 into the View-Based Access Control Model (VACM) , is documented in section 5 (this section also addresses the SNMPv2c Message Processing Model and Community-Based Security Model).
RFC1157] which defines the Simple Network Management Protocol (SNMPv1), the protocol used for network access to managed objects. - STD 16, RFC 1155 [RFC1155] which defines the Structure of Management Information (SMIv1), the mechanisms used for describing and naming objects for the purpose of management. - STD 16, RFC 1212 [RFC1212] which defines a more concise description mechanism, which is wholly consistent with the SMIv1. - RFC 1215 [RFC1215] which defines a convention for defining Traps for use with the SMIv1. Note that throughout this document, the term 'SMIv1' is used. This term generally refers to the information presented in RFC 1155, RFC 1212, and RFC 1215. STD 58, RFC 2578 which defines Version 2 of the Structure of Management Information (SMIv2) [RFC2578]. - STD 58, RFC 2579 which defines common MIB "Textual Conventions" [RFC2579]. - STD 58, RFC 2580 which defines Conformance Statements and requirements for defining agent and manager capabilities [RFC2580]. - STD 62, RFC 3416 which defines the Protocol Operations used in processing [RFC3416]. - STD 62, RFC 3417 which defines the Transport Mappings used "on the wire" [RFC3417]. - STD 62, RFC 3418 which defines the basic Management Information Base for monitoring and controlling some basic common functions of SNMP entities [RFC3418]. Note that SMIv2 as used throughout this document refers to the first three documents listed above (RFCs 2578, 2579, and 2580).
The following document augments the definition of SNMPv2: - RFC 1901 [RFC1901] is an Experimental definition for using SNMPv2 PDUs within a community-based message wrapper. This is referred to throughout this document as SNMPv2c. STD 62, RFC 3411 which defines an Architecture for Describing SNMP Management Frameworks [RFC3411]. - STD 62, RFC 3412 which defines Message Processing and Dispatching [RFC3412]. - STD 62, RFC 3413 which defines various SNMP Applications [RFC3413]. - STD 62, RFC 3414 which defines the User-based Security Model (USM), providing for both Authenticated and Private (encrypted) SNMP messages [RFC3414]. - STD 62, RFC 3415 which defines the View-based Access Control Model (VACM), providing the ability to limit access to different MIB objects on a per-user basis [RFC3415]. SNMPv3 also uses the SNMPv2 definitions of RFCs 3416 through 3418 and the SMIv2 definitions of 2578 through 2580 described above. Note that text throughout this document that refers to SNMPv2 PDU types and protocol operations applies to both SNMPv2c and SNMPv3. ASN1] as the basis for a formal descriptive notation. Indeed, one might note that the SMIv2 approach largely codifies the existing practice for defining MIB modules, based on extensive experience with the SMIv1. The following sections consider the three areas: MIB modules, compliance statements, and capabilities statements.
RFC1155-SMI and RFC-1212. (2) The MODULE-IDENTITY macro MUST be invoked immediately after any IMPORTs statement. (3) For any object with a SYNTAX clause value of Counter, the object MUST have the value of its SYNTAX clause changed to Counter32. (4) For any object with a SYNTAX clause value of Gauge, the object MUST have the value of its SYNTAX clause changed to Gauge32, or Unsigned32 where appropriate. (5) For all objects, the ACCESS clause MUST be replaced by a MAX- ACCESS clause. The value of the MAX-ACCESS clause SHALL be the same as that of the ACCESS clause unless some other value makes "protocol sense" as the maximal level of access for the object. In particular, object types for which instances can be explicitly created by a protocol set operation, SHALL have a MAX-ACCESS clause of "read-create". If the value of the ACCESS clause is "write-only", then the value of the MAX-ACCESS clause MUST be "read-write", and the DESCRIPTION clause SHALL note that reading this object will result in implementation-specific results. Note that in SMIv1, the ACCESS clause specifies the minimal required access, while in SMIv2, the MAX-ACCESS clause specifies the maximum allowed access. This should be considered when converting an ACCESS clause to a MAX-ACCESS clause. (6) For all objects, if the value of the STATUS clause is "mandatory" or "optional", the value MUST be replaced with "current", "deprecated", or "obsolete" depending on the current usage of such objects.
(7) For any object not containing a DESCRIPTION clause, the object MUST have a DESCRIPTION clause defined. (8) For any object corresponding to a conceptual row which does not have an INDEX clause, the object MUST have either an INDEX clause or an AUGMENTS clause defined. (9) If any INDEX clause contains a reference to an object with a syntax of NetworkAddress, then a new object MUST be created and placed in this INDEX clause immediately preceding the object whose syntax is NetworkAddress. This new object MUST have a syntax of INTEGER, it MUST be not-accessible, and its value MUST always be 1. The effect of this, and the preceding bullet, is to allow one to convert a MIB module in SMIv1 format to one in SMIv2 format, and then use it with the SNMPv1 protocol with no impact to existing SNMPv1 agents and managers. (10) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be changed to IpAddress. Note that the use of NetworkAddress in new MIB documents is strongly discouraged (in fact, new MIB documents should be written using SMIv2, which does not define NetworkAddress). (11) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER value which is expressed as a collection of sub- identifiers, the value MUST be changed to reference a single ASN.1 identifier. This may require defining a series of new administrative assignments (OBJECT IDENTIFIERS) in order to define the single ASN.1 identifier. (12) One or more OBJECT-GROUPS MUST be defined, and related objects MUST be collected into appropriate groups. Note that SMIv2 requires all OBJECT-TYPEs to be a member of at least one OBJECT-GROUP. (13) For any non-columnar object that is instanced as if it were immediately subordinate to a conceptual row, the value of the STATUS clause of that object MUST be changed to "obsolete". (14) For any conceptual row object that is not immediately subordinate to a conceptual table, the value of the STATUS clause of that object (and all subordinate objects) MUST be changed to "obsolete".
Other changes are desirable, but not necessary: (1) Creation and deletion of conceptual rows is inconsistent using the SMIv1. The SMIv2 corrects this. As such, if the MIB module undergoes review early in its lifetime, and it contains conceptual tables which allow creation and deletion of conceptual rows, then the objects relating to those tables MAY be deprecated and replaced with objects defined using the new approach. The approach based on SMIv2 can be found in section 7 of RFC 2578 [RFC2578], and the RowStatus and StorageType TEXTUAL-CONVENTIONs are described in section 2 of RFC 2579 [RFC2579]. (2) For any object with an integer-valued SYNTAX clause, in which the corresponding INTEGER does not have a range restriction (i.e., the INTEGER has neither a defined set of named-number enumerations nor an assignment of lower- and upper-bounds on its value), the object SHOULD have the value of its SYNTAX clause changed to Integer32, or have an appropriate range specified. (3) For any object with a string-valued SYNTAX clause, in which the corresponding OCTET STRING does not have a size restriction (i.e., the OCTET STRING has no assignment of lower- and upper- bounds on its length), the bounds for the size of the object SHOULD be defined. (4) All textual conventions informally defined in the MIB module SHOULD be redefined using the TEXTUAL-CONVENTION macro. Such a change would not necessitate deprecating objects previously defined using an informal textual convention. (5) For any object which represents a measurement in some kind of units, a UNITS clause SHOULD be added to the definition of that object. (6) For any conceptual row which is an extension of another conceptual row, i.e., for which subordinate columnar objects both exist and are identified via the same semantics as the other conceptual row, an AUGMENTS clause SHOULD be used in place of the INDEX clause for the object corresponding to the conceptual row which is an extension.
(1) The IMPORTS statement MUST NOT reference RFC-1215 [RFC1215], and MUST reference SNMPv2-SMI instead. (2) The ENTERPRISE clause MUST be removed. (3) The VARIABLES clause MUST be renamed to the OBJECTS clause. (4) A STATUS clause MUST be added, with an appropriate value. Normally the value should be 'current', although 'deprecated' or 'obsolete' may be used as needed. (5) The value of an invocation of the NOTIFICATION-TYPE macro is an OBJECT IDENTIFIER, not an INTEGER, and MUST be changed accordingly. Specifically, if the value of the ENTERPRISE clause is not 'snmp' then the value of the invocation SHALL be the value of the ENTERPRISE clause extended with two sub- identifiers, the first of which has the value 0, and the second has the value of the invocation of the TRAP-TYPE. If the value of the ENTERPRISE clause is 'snmp', then the value of the invocation of the NOTIFICATION-TYPE macro SHALL be mapped in the same manner as described in section 3.1 in this document. (6) A DESCRIPTION clause MUST be added, if not already present. (7) One or more NOTIFICATION-GROUPs MUST be defined, and related notifications MUST be collected into those groups. Note that SMIv2 requires that all NOTIFICATION-TYPEs be a member of at least one NOTIFICATION-GROUP. RFC1303] uses the MODULE-CONFORMANCE macro to describe an agent's capabilities with respect to one or more MIB modules.
Converting such a description for use with the SMIv2 requires these changes: (1) The macro name AGENT-CAPABILITIES MUST be used instead of MODULE-CONFORMANCE. (2) The STATUS clause MUST be added, with a value of 'current'. (3) All occurrences of the CREATION-REQUIRES clause MUST either be omitted if appropriate, or be changed such that the semantics are consistent with RFC 2580 [RFC2580]. In order to ease coexistence, object groups defined in an SMIv1 compliant MIB module may be referenced by the INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro: upon encountering a reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB module, all leaf objects which are subordinate to the subtree and have a STATUS clause value of mandatory are deemed to be INCLUDEd. (Note that this method is ambiguous when different revisions of an SMIv1 MIB have different sets of mandatory objects under the same subtree; in such cases, the only solution is to rewrite the MIB using the SMIv2 in order to define the object groups unambiguously.)
In addition, it MAY be desirable to translate notification parameters in a notification receiver application in order to present notifications to the end user in a consistent format. Note that for the purposes of this section, the set of notification parameters is independent of whether the notification is to be sent as a trap or an inform. SNMPv1 notification parameters consist of: - An enterprise parameter (OBJECT IDENTIFIER). - An agent-addr parameter (NetworkAddress). - A generic-trap parameter (INTEGER). - A specific-trap parameter (INTEGER). - A time-stamp parameter (TimeTicks). - A list of variable-bindings (VarBindList). SNMPv2 notification parameters consist of: - A sysUpTime parameter (TimeTicks). This appears in the first variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU. - An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in the second variable-binding in an SNMPv2-Trap-PDU or InformRequest- PDU, and is equal to the value portion of that variable-binding (not the name portion, as both the name and value are OBJECT IDENTIFIERs). - A list of variable-bindings (VarBindList). This refers to all but the first two variable-bindings in an SNMPv2-Trap-PDU or InformRequest-PDU.
(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 188.8.131.52.184.108.40.206.5.1 (coldStart) 1 220.127.116.11.18.104.22.168.5.2 (warmStart) 2 22.214.171.124.126.96.36.199.5.3 (linkDown) 3 188.8.131.52.184.108.40.206.5.4 (linkUp) 4 220.127.116.11.18.104.22.168.5.5 (authenticationFailure) 5 22.214.171.124.126.96.36.199.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. RFC3418], 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 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 =============================== ============ 188.8.131.52.184.108.40.206.5.1 (coldStart) 0 220.127.116.11.18.104.22.168.5.2 (warmStart) 1 22.214.171.124.126.96.36.199.5.3 (linkDown) 2 188.8.131.52.184.108.40.206.5.4 (linkUp) 3 220.127.116.11.18.104.22.168.5.5 (authenticationFailure) 4 22.214.171.124.126.96.36.199.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 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). 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.
- 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.
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. 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-
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.
section 4.4, "Error Status Mappings". - The error-index SHALL be set to the position (in the original request) of the variable binding that caused the error-status. - The variable binding list of the response PDU SHALL be made exactly the same as the variable binding list that was received in the original request.
(2) If the error-status is noError, the variable bindings SHALL be checked for any SNMPv2 exception (noSuchObject or noSuchInstance) or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64). If there are any such variable bindings, one of those variable bindings SHALL be selected (it is an implementation choice as to which is selected), and: - The error-status SHALL be set to noSuchName, - The error-index SHALL be set to the position (in the variable binding list of the original request) of the selected variable binding, and - The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request. (3) If there are no such variable bindings, then: - The error-status SHALL be set to noError, - The error-index SHALL be set to zero, and - The variable binding list of the response SHALL be composed from the data as it is returned by the access to MIB data. section 4.4, "Error Status Mappings". (2) The error-index SHALL be set to the position (in the original request) of the variable binding that caused the error-status.
(3) The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request. Otherwise, if the access to MIB data returns an error-status of noError: (1) Any variable bindings containing an SNMPv2 syntax of Counter64 SHALL be considered to be not in view, and MIB data SHALL be accessed as many times as is required until either a value other than Counter64 is returned, or an error or endOfMibView exception occurs. (2) If there is any variable binding that contains an SNMPv2 exception endOfMibView (if there is more than one then it is an implementation decision as to which is chosen): - The error-status SHALL be set to noSuchName, - The error-index SHALL be set to the position (in the variable binding list of the original request) of the variable binding that returned such an SNMPv2 exception, and - The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request. (3) If there are no such variable bindings, then: - The error-status SHALL be set to noError, - The error-index SHALL be set to zero, and - The variable binding list of the response SHALL be composed from the data as it is returned by the access to MIB data. section 4.4, "Error Status Mappings".
- The error-index SHALL be set to the position (in the original request) of the variable binding that caused the error-status. - The variable binding list of the response PDU SHALL be made exactly the same as the variable binding list that was received in the original request. RFC3413], section 3.3, bullet (3), the notification originator may need to generate a value for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of this document. If the SNMPv1 notification parameters being used were previously translated from a set of SNMPv2 notification parameters, this value may already be known, in which case it need not be generated.
higher level application using SNMPv1 notification parameter or SNMPv2 notification parameters. The notification receiver would then translate notification parameters when required in order to present a notification using the desired set of parameters. section 5.3 (Community MIB) of this document. Note that in the following sections, the 'Upstream Version' refers to the version used between the command generator or notification receiver and the proxy, and the 'Downstream Version' refers to the version used between the proxy and the command responder or notification originator, regardless of the PDU type or direction.
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.
- 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.
- 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.