Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)
obsoletes
- rfc-1905 — Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)
also
- std-62
Extracted elements (25)
SNMP requires only an unreliable datagram service, with each message entirely and independently contained in a single transport datagram. The preferred transport is UDP. Retransmission policy is intentionally left to the application, which must act responsibly per BCP 41 congestion control principles.
The GetBulkRequest-PDU was designed to minimize the number of protocol exchanges required to retrieve large amounts of management information, particularly for efficient table retrieval. However, senders must set max-repetitions conservatively under network stress to reduce fragmentation risk, since maximum-sized responses may exceed path MTU.
The request-id field serves dual purposes: correlating potentially multiple outstanding requests with incoming responses, and identifying messages duplicated by the unreliable datagram network. Using the same request-id on retransmission allows either the original or retransmitted response to satisfy the request, but a different request-id is recommended for RTT calculation.
The error-status values noSuchName (2), badValue (3), and readOnly (4) are marked 'for proxy compatibility' in the ASN.1 definition and are not generated by SNMPv2 command responders. Command generator applications must nonetheless handle them correctly when operating as proxies to SNMPv1 agents, per RFC 2576.
A compliant implementation must support as many variable bindings in a PDU or BulkPDU as fit into the overall maximum message size limit of the SNMP engine, but no more than 2147483647 (max-bindings) variable bindings.
A compliant SNMP entity supporting a command generator application must be able to properly receive and handle a Response-PDU with error-status equal to noSuchName, badValue, or readOnly, for SNMPv1 proxy compatibility.
A conformant implementation must never generate messages larger than allowed by the receiving SNMP entity. When a response would exceed either the local constraint or the originator's maximum message size, an alternate Response-PDU with error-status tooBig and empty variable-bindings must be generated instead.
A GetBulkRequest response may be truncated to fewer than N + (M * R) bindings for three reasons: (1) message size exceeds local or originator constraint; (2) all bindings for some iteration i are endOfMibView; (3) processing requires significantly more time than normal, provided at least one repetition completes.
All components of a PDU, including those whose values are ignored by the receiving entity, must have valid ASN.1 syntax and encoding. The unSpecified NULL value is defined for use as the value portion of variable bindings in retrieval requests where the value is not relevant.
If any assignment in the SetRequest second phase fails, all other assignments must be undone and error-status is set to commitFailed. If undo is not possible, error-status is set to undoFailed with error-index zero. Implementations are strongly encouraged to avoid both of these conditions.
If the tooBig Response-PDU itself cannot fit within message size constraints, the snmpSilentDrops counter (RFC 3418) is incremented and the message is discarded. This applies to GetRequest, GetNextRequest, GetBulkRequest, SetRequest, and InformRequest processing.
SNMP limits OBJECT IDENTIFIER values to a maximum of 128 sub-identifiers, where each sub-identifier has a maximum value of 2^32-1.
The first two variable bindings in an SNMPv2-Trap-PDU must be sysUpTime.0 and snmpTrapOID.0, in that order. Additional variables from the NOTIFICATION-TYPE OBJECTS clause are appended in order, followed by any optional extra variables chosen by the generating entity.
GetBulkRequest-PDU retrieves up to N + (M * R) variable bindings, where N = min(non-repeaters, count of bindings), M = max-repetitions, and R = max(count-of-bindings - N, 0). The first N bindings are GetNext-style; the remaining R bindings are each repeated M times via iterated lexicographic successors.
GetNextRequest-PDU returns the lexicographically next variable accessible by the request for each binding. If no lexicographic successor exists, the binding's value is set to endOfMibView and its name is set to the requested name. This enables MIB table traversal without prior knowledge of instance identifiers.
GetRequest-PDU processing maps each variable binding to one of three outcomes: (1) exact OID match returns the variable's value; (2) no matching OID prefix returns noSuchObject; (3) matching prefix but no instance returns noSuchInstance. Any other failure returns genErr with the failing binding's index.
SetRequest-PDU processing is a two-phase operation: Phase 1 validates all variable bindings (checking access, writability, type, length, encoding, value, and resource availability); Phase 2 assigns all values simultaneously only if all validations succeed. Assignments occur as if simultaneous with respect to each other.
SNMPv2 defines eight PDU types: GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, Response-PDU, SetRequest-PDU, InformRequest-PDU, SNMPv2-Trap-PDU, and Report-PDU. Each is an ASN.1 IMPLICIT encoding tagged [0] through [8] respectively (tag [4] is obsolete). The Report-PDU semantics are not defined in this document and must be defined by the administrative framework using it.
SNMPv2-Trap-PDU is an unconfirmed notification mechanism: there is no Response-PDU generated upon receipt. InformRequest-PDU is a confirmed notification mechanism that requires a Response-PDU reply with the same request-id, error-status noError, and same variable-bindings.
The SNMPv2 protocol operations defined in this document do not themselves provide a secure environment. Even on a network secured with IPsec, there is no inherent control over which principals on that network can access management information. Implementors are recommended to use the User-based Security Model (RFC 3414) and the View-based Access Control Model (RFC 3415).
ApplicationSyntax types use APPLICATION-tagged encodings: IpAddress is [APPLICATION 0] IMPLICIT OCTET STRING (SIZE 4); Counter32 is [APPLICATION 1]; Unsigned32/Gauge32 are [APPLICATION 2]; TimeTicks is [APPLICATION 3]; Opaque is [APPLICATION 4]; Counter64 is [APPLICATION 6] (all IMPLICIT INTEGER with appropriate ranges).
The BulkPDU (used by GetBulkRequest-PDU) is a SEQUENCE structurally identical to PDU but replaces error-status with non-repeaters INTEGER (0..max-bindings) and error-index with max-repetitions INTEGER (0..max-bindings). The variable-bindings values are ignored in the request.
The SMIv2 BITS construct is encoded as an OCTET STRING with named bits placed from bit 8 (high order) to bit 1 (low order) of the first octet, continuing through subsequent octets. Remaining bits in the final octet are set to zero on generation and ignored on receipt.
The standard PDU (GetRequest, GetNextRequest, Response, SetRequest, InformRequest, SNMPv2-Trap, Report) is a SEQUENCE containing: request-id INTEGER (-214783648..214783647), error-status INTEGER with 19 defined values (noError through inconsistentName), error-index INTEGER (0..max-bindings), and variable-bindings VarBindList.
VarBind is a SEQUENCE containing a name (ObjectName, i.e., OBJECT IDENTIFIER) and a CHOICE of: value (ObjectSyntax), unSpecified (NULL for retrieval requests), noSuchObject [0] IMPLICIT NULL, noSuchInstance [1] IMPLICIT NULL, or endOfMibView [2] IMPLICIT NULL for exception responses.