SNMP History

SNMP was not the first network management protocol, and its early years were shaped by a standards dispute between the Internet community and the International Organization for Standardization (ISO). This guide covers that dispute and the version history that followed: SGMP, the three competing 1988 proposals, SNMPv1, the fragmented SNMPv2 effort, and SNMPv3's eventual standardization of security.

Origins: SGMP and the 1988 decision

By the mid-1980s, the growing number of routers on the early Internet created a practical problem: there was no standard way to ask a router for its status. Operators relied on ad hoc, vendor-specific methods. In November 1987, a group of engineers - Jeffrey Case, Mark Fedor, Craig Davin, and Marshall Schoffstall - published RFC 1028, defining the Simple Gateway Monitoring Protocol (SGMP). SGMP used a basic manager-agent model over UDP: a management station could send a Get Request or Set Request to a gateway, which would reply with a Get Response. A separate mechanism, SGMP-TRAPS, let a gateway send unsolicited notifications. SGMP was deliberately minimal and saw some production use.

By early 1988, three competing approaches to Internet network management had gained enough support that the Internet Activities Board (IAB) needed to choose a direction:

• HEMS (High-Level Entity Management System) - technically ambitious, with experimental implementations, but not widely deployed.
• SGMP - simple and already running on production networks, but not designed for long-term extensibility.
• CMIS/CMIP (Common Management Information Services/Protocol) - the network management framework being developed by ISO as part of the OSI model, extensively specified but with almost no working implementations.

An ad hoc Network Management Review Committee, chaired by Vint Cerf, convened on February 29, 1988, to resolve the impasse. Its findings were published in RFC 1052 (April 1988), which recommended a two-track approach: SNMP - SGMP renamed, with revisions - would be adopted as the basis for network management in the short term, since it already worked, while the ISO CMIS/CMIP framework would be pursued for the longer term. A working group would develop a shared Management Information Base (MIB) intended to be compatible with both frameworks.

SNMPv1 (1988-1990)

Following RFC 1052, the SNMP working group revised SGMP into the Simple Network Management Protocol. Early definitions appeared in RFC 1067 (1988) and RFC 1098, before SNMP reached full Internet Standard status with RFC 1157 in May 1990, authored by Case, Fedor, Davin, and Schoffstall - the same authors as the original SGMP specification. RFC 1157 was notably short, around 36 pages, and this simplicity - implicit in the protocol's name - is generally credited as a major factor in its rapid, widespread adoption. SNMP took over UDP ports 161 and 162 (for traps) in 1988, superseding SGMP's ports 153 and 160.

SNMPv1's security model was minimal: a plain-text community string sent with every request, functioning as a shared password with no encryption and no per-user accountability. This was a deliberate simplification, not an oversight - the priority was getting a working, adoptable protocol deployed quickly. The security question would resurface, unresolved, for over a decade.

MIB-II and the end of dual compatibility (1991)

The original goal of keeping the MIB compatible with both the SNMP and OSI frameworks proved harder than expected. RFC 1213 (March 1991), which defined MIB-II and became STD 17, states this directly: the requirements of the two frameworks turned out to be more different than anticipated, and the requirement for dual compatibility was formally suspended. This let SNMP's own MIB structure evolve independently rather than remain constrained by OSI's parallel framework. In practice, CMIP never achieved significant deployment outside of telecommunications contexts, and SNMP became the de facto standard for Internet network management by default rather than through a formal declaration that it had "won."

SNMPv2 and its fragmentation (1992-1996)

Work on a second version began in the early 1990s, aiming to address SNMPv1's limitations: 32-bit counters that wrapped too quickly on faster links, no efficient way to retrieve large amounts of table data, and no real security. The initial SNMPv2 specification grew to more than 400 pages, a significant departure from SNMPv1's original simplicity, and this complexity slowed adoption and drew criticism from parts of the industry.

The bigger problem was security. Several incompatible proposals emerged, each defining its own answer to "how should SNMPv2 authenticate requests":

• SNMPv2p - the original SNMPv2 proposal, using a party-based security model (RFC 1441, 1445, 1446, 1448, 1449; April 1993). It did not gain significant adoption and was later reclassified as Historic.
• SNMPv2c - retained SNMPv1's simple community-string security while adopting SNMPv2's protocol improvements, such as GETBULK (RFC 1901, 1905, 1906). Despite never advancing past Experimental status, SNMPv2c became the most widely deployed version of SNMPv2 in practice.
• SNMPv2u - added user-based security without community strings (RFC 1905, 1906, 1909, 1910).
• SNMPv2* - a vendor-developed attempt (by SNMP Research) to combine the better features of SNMPv2p and SNMPv2u, distributed outside the standard RFC process.

This fragmentation meant that for several years, "SNMPv2" did not refer to one interoperable protocol. In practice, the market settled on SNMPv2c - GETBULK and the other protocol operations improvements, still secured with a plain-text community string - as the pragmatic middle ground, even though it left the original security problem unsolved.

SNMPv3 and standardized security (1997-2002)

SNMPv3 was developed to resolve the security fragmentation directly, combining ideas from the competing SNMPv2 proposals into a single standard: the User-based Security Model (USM), drawing on SNMPv2u and SNMPv2*, for authentication and encryption, and the View-based Access Control Model (VACM) for controlling which parts of the MIB tree a given user could access. Initial specifications were published as RFC 2571-2575 in 1999. The architecture was finalized as RFC 3411 through RFC 3418 in December 2002, collectively designated STD 62.

SNMPv3 introduced three security levels - noAuthNoPriv, authNoPriv, and authPriv - letting a deployment choose between username-only identification, authenticated-but-unencrypted requests, or fully authenticated and encrypted ones. As part of finalizing SNMPv3, the IESG reclassified RFC 1157 (SNMPv1) and RFC 1901 (the SNMPv2c introduction) as Historic in 2002. In practice, both SNMPv1 and SNMPv2c have continued to see widespread real-world use well after that formal reclassification, since a protocol's standards-track status does not by itself remove it from deployed hardware.

SNMP since 2002

The core SNMP framework has been stable since STD 62. Later RFCs have added specific MIBs and minor protocol clarifications rather than revising the base architecture. SNMP remains in widespread use across networking hardware, and the version landscape described above - v1, v2c, and v3 all still active in different deployments - is largely unchanged from the early 2000s; see the SNMP Fundamentals guide for how the three versions compare in practice today. Newer network management approaches, including NETCONF/YANG and streaming telemetry protocols, have been developed since and are used alongside SNMP on modern equipment, particularly for configuration management rather than monitoring - but SNMP's specific role, polling and receiving traps from a very large installed base of existing hardware, has kept it in active, ordinary use rather than displaced.