| 
 | Please Whitelist This Site?I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
 If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles KozierokAuthor and Publisher, The TCP/IP Guide
 | 
 
 
   
  
    | 
  
| NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.
 |  |  | 
| 
 
 
 | 
 
 TCP/IP Internet Standard Management Framework and SNMP Versions (SNMPv1, SNMPv2 Variants, SNMPv3)
 (Page 3 of 4)
 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.SNMPv2 Variants 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 SNMPv2pthe 
enhancements to the SNMP protocol and SMIwhile 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 dont 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. 
 
 | 
 | If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support! |  
|  | 
 | 
 
 
 Home - 
Table Of Contents - Contact Us
 
 The TCP/IP Guide (http://www.TCPIPGuide.com)
 Version 3.0 - Version Date: September 20, 2005
 
 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
 Not responsible for any loss resulting from the use of this site.
 |