SNMP Standards & RFCs
Every part of SNMP traces back to a numbered document. The relevant SNMP RFC set is small once you sort it: a few define the protocol versions, one defines how MIBs are written, and a handful define the MIBs themselves. Knowing which is which — that RFC 1157 is v1 while RFC 3411 opens the v3 framework — turns a wall of numbers into a map. This page lays out the SNMP standards landscape as a reference table plus plain answers, so you can cite the right RFC without second-guessing.
Overview
There are two kinds of document here, and confusing them is the usual stumble. Protocol RFCs define how SNMP talks — the versions, the message formats, the security model. MIB RFCs define what it talks about — the managed objects and their OIDs. SMIv2 sits between them as the grammar for writing MIBs. Below, the table gathers the core SNMP standards in one place; the questions then explain what each actually governs and when you'd reach for it. This is a reference page, not a tutorial, so if you want the beginner model of how these pieces interact, read common SNMP questions first, then come back here to pin down the exact RFC 1157 3411 lineage.
When you need to find the right document fast, work in this order:
- Decide whether your question is about how SNMP talks (a protocol RFC) or what it reports (a MIB RFC).
- For protocol, pick the version — 1157 for v1, the 1901/3416/3417 trio for v2c, the 3411–3418 range for v3.
- For data, pick the MIB — 1213, 2790, 2863, or 3433 depending on the metric.
- If you're writing or reading a MIB definition itself, that's SMIv2, RFC 2578.
| Standard | RFC(s) | What it defines |
|---|---|---|
| SNMPv1 | RFC 1157 | The original protocol operations and message format |
| SNMPv2c | RFC 1901, 3416, 3417 | Community-based v2: intro, protocol operations, transport |
| SNMPv3 | RFC 3411–3418 | Architecture, USM (auth/priv), VACM (access control) |
| SMIv2 | RFC 2578 | How MIB modules and objects are written |
| MIB-II | RFC 1213 | Core managed objects (system, interfaces, IP) |
| Host Resources MIB | RFC 2790 | CPU, memory, storage, processes, uptime |
| IF-MIB | RFC 2863 | Network interface objects and counters |
| Entity Sensor MIB | RFC 3433 | Physical sensor values (temperature, fan, voltage) |
Questions & answers
Which RFC defines SNMPv1? RFC 1157. It specifies the first version of the protocol — the GET, GETNEXT, SET, and TRAP operations, the community-based access model, and the message format that everything since has built on. Plenty of older hardware still speaks only v1, so it's far from a museum piece. If you're citing the origin of SNMP itself, RFC 1157 is the document. Its weakness is age-appropriate: no encryption, minimal error reporting, and a community string in the clear. Everything that came after was, in one way or another, an attempt to shore up those gaps without breaking the simplicity that made v1 spread in the first place.
Which RFCs cover SNMPv2c? Three work together. RFC 1901 introduces the community-based variant known as v2c. RFC 3416 defines the version-2 protocol operations, including the GETBULK request that makes large table transfers efficient. RFC 3417 covers the transport mappings — how the messages ride over UDP. Together they describe the version most read-only monitoring runs today, with the well-known caveat that its community string is unencrypted.
What does the RFC 3411–3418 range define? That's SNMPv3, and it's a set rather than a single document because v3 is modular. RFC 3411 lays out the overall architecture. The rest fill in the pieces — most importantly the User-based Security Model (USM) for authentication and privacy, and the View-based Access Control Model (VACM) for deciding who can read which OIDs. When people say "SNMPv3 for security," this is the RFC 3411-through-3418 family they mean.
What is SMIv2 and why does it get its own RFC?
SMIv2 — the Structure of Management Information, version 2 — is RFC 2578. It isn't a protocol; it's the language MIBs are written in. It defines what an object type looks like, the allowed data types, how tables are structured, and how OIDs get assigned. Every modern MIB, from Host Resources to IF-MIB, is written to SMIv2. You rarely invoke it directly, but it's the grammar underneath every managed object you poll. Because it standardizes how objects and tables are described, a tool written to SMIv2 can load a MIB it has never seen before and still make sense of it — that's what lets a MIB browser or snmptranslate interpret a vendor MIB without special-casing every device.
What's the difference between a protocol RFC and a MIB RFC? A protocol RFC (1157, 3416, the 3411 range) defines the conversation — how a manager and agent exchange messages and secure them. A MIB RFC (1213, 2790, 2863, 3433) defines the vocabulary — the specific objects, their OIDs, and their meaning. You need one of each to do anything useful: the protocol to move data, the MIB to interpret it. Mixing the two categories is the most common source of RFC confusion.
Which MIB RFCs do I need for server monitoring?
Mostly two. The Host Resources MIB (RFC 2790) is where server vitals live — CPU load, memory, storage, processes, uptime — for example hrStorageUsed at 1.3.6.1.2.1.25.2.3.1.6. The IF-MIB (RFC 2863) covers network interfaces, including 64-bit traffic counters. MIB-II (RFC 1213) underpins both with core system objects. For physical environment readings — temperature, fans, voltage — the Entity Sensor MIB (RFC 3433) is the standard, though many devices expose those through vendor MIBs instead.
Are these SNMP standards actual IETF standards? Yes — they're published by the IETF as RFCs, and the core ones carry standards-track status. That's what makes SNMP genuinely interoperable: a v2c agent from one vendor and a poller from another agree because both implement the same RFC 3416 operations. The MIBs are standardized the same way, which is why an OID like host uptime means the same thing on wildly different hardware.
What ports do the standards assign to SNMP? By convention, UDP 161 for the agent (queries) and UDP 162 for traps. These are the well-known assignments the tooling defaults to. Nothing in the standard forbids moving the agent to another port for safety — and doing so cuts a lot of automated scanning — but 161 and 162 are what you'll find unless someone changed them. Because both are UDP rather than TCP, there's no connection to establish and no handshake to observe, which is part of why a misconfigured port looks identical to a dropped packet: the request simply goes unanswered. Keep that in mind when a poll fails silently against a host you know is otherwise healthy.
Related reading
- SNMP FAQ — the parent hub linking every quick answer.
- SNMP monitoring home — the top of the knowledge base.
- Common SNMP questions — the beginner model these standards formalize.
- SNMP diagnostics — testing agents that implement these RFCs.
- SNMP error messages — how version and MIB mismatches surface as errors.
- SNMP glossary — USM, VACM, SMIv2, and other standard terms defined.
- Sensor & OID catalog — the MIB objects from these RFCs, in practice.
Standards make SNMP interoperable; they don't watch it for you. ostr.io Monitoring implements the practical end — it polls a standards-compliant SNMPv2c agent from outside your network and sends real-time email and SMS alerts, the external layer that gives you double durability when the monitored host itself goes quiet.
