The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Network Configuration and Management Protocols (BOOTP, DHCP, SNMP and RMON)            9  TCP/IP Network Management Framework and Protocols (SNMP and RMON)                 9  TCP/IP Internet Standard Management Framework Overview, Architecture, Components and Concepts

TCP/IP Internet Standard Management Framework Architecture and Protocol Components 1 2 3 4 TCP/IP Internet Standard Management Framework and SNMP Standards

SNMPv2

While SNMPsec went away, the idea of party-based security it introduced never did. It was used as the basis of the definition of the first full revision of SNMP, when SNMP Version 2 (SNMPv2) was published in RFCs 1441 through 1452 in April 1993. This new version incorporated the new security model, as well as making changes to the actual SNMP protocol operations, changes to the Structure of Management Information (SMI) standard (defining version 2 of SMI, SMIv2), and formalizing the concept of the Internet Standard Management Framework.

Unfortunately, this new standard too was never universally accepted. Some people thought the whole new version was a great advance, but others took issue with the party-based security, claiming it was too complex. I am not familiar with all the details, but from what I understand, a great deal of debate and discussion took place over the next couple of years, as an attempt was made to get everyone “on board” with the new version.

Acceptance of SNMPv2 never happened. Instead, different “splinter groups” broke off and began work on variants of SNMPv2. To prevent confusion, the original SNMPv2 became known as either SNMPv2 classic (reminiscent of the name a particular soft drink) or SNMPv2p, with the “p” referring to “party-based” security. Things got very interesting (and confusing) when the following were proposed and/or developed:

• SNMPv1.5: I can tell immediately that an idea is probably going to be a problem when it proposes a version number lower than a number already standardized. SNMPv1.5 was an attempt to retain the “uncontroversial” elements in SNMPv2p—the enhancements to the SNMP protocol and SMI—while going back to community-based security as in SNMPv1. It never became a standard itself, but became the basis of…
  
  
• Community-Based SNMPv2 (SNMPv2c): This is SNMPv2p modified to use community strings instead of party-based security; in essence, the same idea as SNMPv1.5 but with a more “official-sounding” name and a few changes. Interestingly, the standard that defines this, RFC 1901, still has an “experimental” status, despite the fact that SNMPv2c actually achieved some degree of commercial success where the “standard” SNMPv2p did not.
  
  SNMPv2c was defined by standards RFC 1902 through 1908, which incorporate other changes including a new version of SMI (SMIv2).
  
  
• User-Based SNMPv2 (SNMPv2u): This is an alternative security method for SNMPv2c, which is based on users rather than community strings. It is considered simpler than party-based but more secure than community-string security. It is defined by RFC 1909 and RFC 1910. It too is formally considered “experimental”.
  
  
• SNMPv2*: As if all of the above was not enough, a well-known vendor decided to define another variant called SNMPv2* that combined elements of SNMPv2p and SNMPv2u. This was never formally standardized. (Yes, that's an asterisk in the name. No, there's no footnote at the bottom of this topic, so don’t bother looking for one. Yes, putting an asterisk in a name is extremely confusing. No, I don't know how it is that marketing people get paid good money to come up with names like that. J)

Now, imagine that you were a network administrator in the mid-1990s and were faced with SNMPv2p, SNMPv2c, SNMPv2u and SNMPv2*. Which one would you choose? Well, if you are like most people, you'd choose “none of the above”, saying “I think I'll stick with SNMPv1 until these version 2 folks get their act together”. And that's basically what happened. Some proponents of these variations promoted them, but there was never any agreement and the result was that the success of all of the various and sundry SNMPv2's was limited. As I said, a classic illustration of how important universal standardization is.

TCP/IP Internet Standard Management Framework Architecture and Protocol Components 1 2 3 4 TCP/IP Internet Standard Management Framework and SNMP Standards