SNMP Protocol Versions:

Note that IETF standards-track documents have status of "proposed", "draft", "full", "experimental", or "historic".

There currently exists the following versions of the SNMP protocol:

• SNMPv1 - (full) the original version, defined by RFC 1157.
• SNMPsec - (historic) the first attempt to add strong security to SNMPv1, defined by RFCs 1351, 1352, and 1353.
• SNMPv2p - (historic) party-based SNMP, which was another attempt to add strong security to SNMP, defined by RFCs 1441, 1445, 1446, 1448, and 1449.
• SNMPv2c - (experimental) community string-based SNMPv2, which was an attempt to combine the protocol operations of SNMPv2 with the security of SNMPv1, defined by RFCs 1901, 1905, and 1906.
• SNMPv2u - (experimental) user-based SNMPv2, which provided security based on user names and protocol operations of SNMPv2, defined by RFCs 1905, 1906, 1909, and 1910.
• SNMPv2* (or SNMPv2star) - (experimental) an attempt to add the best features of SNMPv2p and SNMPv2u, defined by unpublished documents found at WEB site owned by SNMP Research (a leading SNMP vendor)
• SNMPv3 - (to be proposed) another attempt to add strong security to SNMP, defined by not yet published documents of the IETF SNMPv3 WG.

The SNMPv1, SNMPv2c, SNMPv2u, and SNMPv3 protocol messages have a common form, which is an ASN.1 sequence containing a message version field, followed by version dependent fields.

The SNMPsec, SNMPv2p, and SNMPv2* protocol messages have a common form, which is a tagged ASN.1 context specific sequence containing message dependent fields.

SNMP SMI Versions:

The SMI defines the format for defining managed objects that are accesses via the SNMP protocol, and contains a few administrative assignments.

• SMIv1 (also called concise) - (full+informational) this is defined by RFCs 1155, 1212, and 1215. An earlier version defined by RFC 1065 is historic.
• SMIv2 - (draft) this is defined by RFC 1902, 1903, and 1904. An earlier version is defined by RFCs 1442, 1443, and 1444 and is historic. This earlier version, which has no widely recognized name, defined a few data types which are not supported in the current version. These are "BIT STRING", "UInteger32", and "NsapAddress".

SMIv2 is a backward compatable update of SMIv1, in all cases except for data type Counter64. That is, it is possible to mechanically create a definition of managed objects in the SMIv1 format from a definition in the SMIv2 format except for objects whose data type is Counter64. There is no complete mechanical conversion from definitions of managed objects in the SMIv1 format to the SMIv2 format, since the SMIv2 format contains fields for additional information that must be provided by the designer of the definitions. Also, the SMIv2 format contains contructs to define requrement specifications and to define implementation specifications, not found in the SMIv1 format.

The definition of managed objects is independent of the protocol to access them except for objects with data type of Counter64. That data type does not exist in the SNMPv1 and SNMPsec protocols. A conforming SNMPv1/SNMPsec entity will generate an ASN.1 parse error when parsing a message containing containing a Counter64 data type. RFC 2089 defines the behavior of a conforming bi-lingual agent that has access to objects with Counter64 data type.

At this time there is widespead use and support of both versions of the SMI. This is due in part to the policy in the IETF that new versions of RFCs must specify MIBs in the SMIv2 format.

-Dave T. Perkins