Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework
obsoleted by
- rfc-2576 — Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework
obsoletes
- rfc-1452 — Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework
Extracted elements (23)
Deprecation of existing SNMPv1 objects is not required during MIB conversion to SNMPv2; only objects whose semantics truly change should be deprecated. This preserves backward compatibility and avoids unnecessary churn in deployed MIBs.
Object groups defined in SNMPv1 MIB modules may be referenced by the INCLUDES clause of AGENT-CAPABILITIES; all leaf objects subordinate to the referenced subtree with STATUS 'mandatory' are implicitly included. This method is acknowledged as ambiguous when different revisions of a MIB have different mandatory objects under the same subtree.
The snmpTrapOID.0 value in the SNMPv2-Trap-PDU is calculated from the SNMPv1 Trap-PDU: if generic-trap is 'enterpriseSpecific', the value is the enterprise OID concatenated with sub-identifiers '0' and the specific-trap value; otherwise, the corresponding standard trap OID from the SNMPv2 MIB is used.
The SNMPv2 approach to describing managed objects is described as nearly a proper superset of SNMPv1, largely codifying existing practice based on extensive operational experience. This design choice means most SNMPv1 MIBs require only mechanical conversion rather than semantic redesign.
MIB modules defined using the SNMPv1 framework may continue to be used with the SNMPv2 protocol. However, specific changes are required for the modules to fully conform to the SNMPv2 framework.
SNMPv1 error-status values 'noSuchName', 'badValue', and 'readOnly' are preserved unmodified in proxy responses so the SNMPv2 manager can interpret them correctly, even though a native SNMPv2 entity would never generate these values.
Any object lacking a DESCRIPTION clause must have one added. Any conceptual row object without an INDEX clause must have either an INDEX or AUGMENTS clause defined.
For all objects, if the STATUS clause value is 'mandatory' it must be replaced with 'current'; if the value is 'optional' it must be replaced with 'obsolete'.
For all objects, the ACCESS clause must be replaced by a MAX-ACCESS clause. If the ACCESS clause value is 'write-only', the MAX-ACCESS clause value must be 'read-write' and the DESCRIPTION clause must note that reading the object produces implementation-specific results.
For any object with an INDEX clause referencing an object with a syntax of NetworkAddress, the STATUS clause of both objects must be changed to 'obsolete'.
For any object with an integer-valued SYNTAX clause where the INTEGER has no range restriction, the SYNTAX clause value must be changed to Integer32. Similarly, Counter must be changed to Counter32 and Gauge must be changed to Gauge32.
For standard information modules, a corresponding invocation of the MODULE-COMPLIANCE macro must be included within the module (or a companion module), and any commentary text relating to compliance must be removed.
Hyphens must be removed from any descriptor or named-number enumeration label that contains them when converting to SNMPv2.
If a proxy agent receives a SNMPv1 GetResponse-PDU with error-status 'tooBig', it must remove the contents of the variable-bindings field before propagating the response to the SNMPv2 manager.
When a proxy agent converts a SNMPv2 GetBulkRequest-PDU to SNMPv1, it must set the non-repeaters and max-repetitions fields to zero and change the PDU tag to GetNextRequest-PDU. GetRequest-PDU, GetNextRequest-PDU, and SetRequest-PDU are passed unaltered.
When a proxy agent forwards a SNMPv1 GetResponse-PDU to a SNMPv2 manager, it must pass the PDU unaltered, including preserving error-status values such as 'noSuchName', 'badValue', or 'readOnly' that SNMPv2 would never generate natively.
When converting an SNMPv1 MIB module to SNMPv2, the IMPORTS statement must reference SNMPv2-SMI instead of RFC1155-SMI and RFC-1212, and the MODULE-IDENTITY macro must be invoked immediately after any IMPORTS statement.
When converting capabilities statements from SNMPv1 to SNMPv2, the macro name must change from MODULE-CONFORMANCE to AGENT-CAPABILITIES, and a STATUS clause must be added.
When converting trap definitions, the TRAP-TYPE macro must be replaced with NOTIFICATION-TYPE: the ENTERPRISES clause removed, VARIABLES renamed to OBJECTS, STATUS clause added, and the OID value recalculated by appending sub-identifiers '0' and the specific-trap value to the enterprise OID.
A bi-lingual manager supports both SNMPv1 and SNMPv2 protocols. When contacting an agent, it consults a local database to select the correct protocol version, and must map operations as if acting as a proxy agent to provide transparency to management applications.
A proxy agent mechanism enables coexistence at the protocol level. A SNMPv2 entity acting in an agent role may be configured to act as a proxy agent, forwarding requests to SNMPv1 agents and translating responses back to SNMPv2 managers.
When a SNMPv1 Trap-PDU is received by a proxy agent, it is mapped to a SNMPv2-Trap-PDU by prepending sysUpTime.0 (from the timestamp field) and snmpTrapOID.0 (derived from the generic-trap and enterprise fields), and appending snmpTrapEnterprise.0 (from the enterprise field).
Security issues are explicitly not discussed in this memo. Implementers must consult other documents in the SNMPv2 framework for security guidance.