By the SNMP Monitoring team · Reviewed July 2026
SNMP isn't a product; it's a stack of IETF standards, and knowing which RFC defines what turns vague familiarity into real authority. When a vendor's docs say "compliant with RFC 2863," you want to know that's the IF-MIB and therefore interfaces read the standard way. When someone claims a metric, you want to know whether it's defined in a standards-track MIB or a private one. This page maps the RFCs that matter — the protocol versions, the data-model rules, the core MIBs, and the security and transport specs — accurately. Every number here is a real, published RFC; where you need to confirm one yourself, the IETF datatracker is the authority.
Parent: FAQ & reference. Related: SNMP history, versions, standard MIBs.
Protocol RFCs
The versions of SNMP itself, and the documents that define them:
| Version | Defining RFCs | Note |
|---|---|---|
| SNMPv1 | RFC 1157 | The original, 1990; cleartext community |
| SNMPv2c | RFC 1901, 1905, 1906 | Community-based v2; adds GetBulk |
| SNMPv3 | RFC 3411–3418 (STD 62) | Adds authentication & encryption |
The one to internalize is STD 62: SNMPv3 is defined across the set RFC 3411 through 3418, and the IETF designates that whole set as Internet Standard 62 — the mark of a mature, full standard rather than a proposal. Within it, the pieces divide cleanly: RFC 3411 is the architecture, RFC 3414 the User-based Security Model (USM), RFC 3415 the View-based Access Control Model (VACM), RFC 3416 the protocol operations, and RFC 3417 the transport mappings. That modular split is why you can talk about "USM" or "VACM" as distinct things — each has its own RFC. Version background is on versions and the story on history.
Structure of Management Information (SMI)
Before any MIB can define objects, there has to be a grammar for how objects are defined — that's the SMI. SMIv1 is RFC 1155; SMIv2, the current version, is RFC 2578, with textual conventions in RFC 2579 and conformance statements in RFC 2580. SMI is the rulebook that says what a managed object looks like: its syntax, its access, its status, its OID. Every MIB you load is written in SMI, which is why a MIB compiler can parse a Cisco MIB and a printer MIB with the same machinery. Understanding SMI is understanding why the whole ecosystem interoperates — the data-model structure is covered on MIB structure.
Core MIB RFCs
These are the standard MIBs behind the metrics you poll most, each an IETF standard so it reads the same across vendors:
| MIB | RFC | Coverage |
|---|---|---|
| MIB-II | RFC 1213 | The base system/interface objects (sysDescr, sysUpTime…) |
| IF-MIB | RFC 2863 | Interfaces — traffic, status, high-capacity counters |
| HOST-RESOURCES-MIB | RFC 2790 | CPU, storage, memory, processes on hosts |
| TCP-MIB / UDP-MIB / IP-MIB | RFC 4022 / 4113 / 4293 | Transport and network-layer statistics |
MIB-II (RFC 1213) is the bedrock — the system and interface groups every agent implements. IF-MIB (RFC 2863) modernized and extended the interface objects, adding the 64-bit high-capacity counters that fast links need. HOST-RESOURCES-MIB (RFC 2790) is the cross-platform server MIB behind CPU, disk, and memory. Reach for these standard MIBs before any vendor MIB — the objects mean the same thing everywhere, which the standard MIBs page expands on.
Device and sensor MIB RFCs
Beyond the general-purpose MIBs, several standards-track MIBs cover specific device classes — and because they're standard, they work across vendors that implement them. ENTITY-SENSOR-MIB (RFC 3433) defines physical sensor readings — temperature, voltage, fan speed, and more — in a uniform structure. UPS-MIB (RFC 1628) covers uninterruptible power supplies: battery charge, runtime, load, on-battery status. Printer-MIB (RFC 3805) standardizes printer supplies, page counts, and status across makers. These are the reason a temperature sensor, a UPS, and a printer from different vendors can all be monitored with one approach — the sensor detail lives on all sensors.
Security and transport RFCs
SNMPv3's security is itself split across specific RFCs, and there are modern transport options too:
- USM — RFC 3414: the User-based Security Model, providing authentication and privacy for v3.
- VACM — RFC 3415: the View-based Access Control Model, controlling which OIDs a user may see.
- TLS transport — RFC 6353: SNMP over TLS (TCP) for transport-layer security.
- DTLS transport — RFC 5953: SNMP over DTLS (UDP) for datagram transport security.
USM and VACM are the heart of v3 security and are worth knowing by number, since agent configs and docs reference them directly. The TLS/DTLS transport RFCs are a separate, transport-based security model — less common than USM in practice, but standardized. Hardening guidance is on security.
How to read an RFC
RFCs come in maturity levels, and the label matters. A document can be a Proposed Standard, advance to Internet Standard (given an STD number, like STD 62 for SNMPv3), or be Obsoleted by a newer RFC that replaces it. To read one correctly:
- Look it up on the datatracker by number to get the authoritative text.
- Check its status — Proposed, Internet Standard (STD), or Obsoleted.
- Follow the "obsoleted by" pointer if there is one, to reach the current document.
An obsoleted RFC has been superseded, and you want the document that obsoletes it. The authoritative place to verify any of this — status, which RFC obsoletes which, the full text — is the IETF datatracker at datatracker.ietf.org. When a number is ever in doubt, look it up there rather than trusting a secondhand citation; the standards themselves are the ground truth.
Frequently asked questions
What RFC defines SNMP?
It depends on the version. SNMPv1 is defined by RFC 1157. SNMPv2c is defined across RFC 1901, 1905, and 1906. SNMPv3 is defined by the set RFC 3411 through 3418, collectively designated Internet Standard 62 (STD 62). There's no single "SNMP RFC" — the protocol evolved across these documents, with v3 being the current, secure standard.
What is STD 62?
STD 62 is the IETF's Internet Standard designation for SNMPv3 — the label applied to the set of RFCs 3411 through 3418 that define the version. An STD number signals a full Internet Standard rather than a proposal, marking SNMPv3 as a mature, stable specification. Within STD 62, RFC 3414 defines USM (security) and RFC 3415 defines VACM (access control).
What RFC is MIB-II?
MIB-II is defined by RFC 1213. It's the foundational standard MIB, providing the base system group (sysDescr, sysName, sysUpTime) and the original interface objects that essentially every SNMP agent implements. The interface objects were later modernized and extended by the IF-MIB (RFC 2863), which added the 64-bit high-capacity counters, but MIB-II remains the common baseline.
Where do I read SNMP RFCs?
The authoritative source is the IETF datatracker at datatracker.ietf.org, which hosts every RFC with its current status — whether it's a Proposed Standard, an Internet Standard with an STD number, or obsoleted by a newer document. Always check status there: an obsoleted RFC has been replaced, and the datatracker tells you which document supersedes it. Treat it as the ground truth over any secondhand citation.
Key takeaways
- SNMPv1 = RFC 1157; SNMPv2c = RFC 1901/1905/1906; SNMPv3 = RFC 3411–3418 = STD 62.
- Within v3: USM = RFC 3414, VACM = RFC 3415, protocol ops 3416, transport 3417.
- SMIv2 (RFC 2578) is the grammar every MIB is written in; MIB-II = RFC 1213.
- Core MIBs: IF-MIB 2863, HOST-RESOURCES 2790, ENTITY-SENSOR 3433, UPS-MIB 1628, Printer-MIB 3805.
- TLS/DTLS transport = RFC 6353 / 5953; verify any RFC's status at the IETF datatracker.
- Prefer standards-track MIBs over vendor MIBs — the objects mean the same thing everywhere.