Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)
obsoleted by
- rfc-3416 — Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)
obsoletes
- rfc-1448 — Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)
Extracted elements (29)
GetBulkRequest-PDU was designed to minimize the number of protocol exchanges needed to retrieve large amounts of management information, particularly large tables. It allows the manager to request the largest possible response within message size constraints.
SNMPv2 requires only an unreliable datagram service, with every message entirely contained in a single transport datagram. Retransmission of requests is left to the discretion of the requesting application depending on urgency, but applications must act responsibly regarding frequency and duration of retransmissions.
Using a different request-id on retransmission is recommended when the round-trip time needs to be calculated. Using the same request-id allows either response to satisfy the request, which is preferred in most situations for simplicity.
SNMPv1 proxy compatibility requires agents to return legacy error codes noSuchName (2), badValue (3), and readOnly (4) in specific situations. SNMPv2 managers MUST be able to handle these codes as specified in RFC 1908 coexistence rules.
A compliant SNMPv2 entity acting in a manager role MUST be able to properly receive and handle a Response-PDU with error-status equal to noSuchName, badValue, or readOnly, which are legacy codes used for SNMPv1 proxy compatibility.
A conformant implementation MUST never generate messages larger than allowed by the receiving SNMPv2 entity. Each transport mapping specifies the minimum message size an implementation must be able to produce or consume.
A SNMPv2 entity sending a GetBulkRequest-PDU MUST take care to set its parameters to reduce the risk of IP fragmentation, particularly by using only small values for max-repetitions under conditions of network stress.
All PDU components, including fields whose values are ignored by the receiver, MUST have valid ASN.1 syntax and encoding. The unSpecified NULL value is defined for use in retrieval request bindings where only the name is relevant.
All SNMPv2 entities acting in a manager role MUST be able to generate GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, InformRequest-PDU, and Response-PDU, and MUST be able to receive Response-PDU, SNMPv2-Trap-PDU, and InformRequest-PDU.
All SNMPv2 entities acting in an agent role MUST be able to generate Response-PDU and SNMPv2-Trap-PDU, and MUST be able to receive GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, and SetRequest-PDU.
If a GetRequest response would exceed the local constraint or originator's maximum message size, an alternate Response-PDU with error-status tooBig, error-index zero, and empty variable-bindings MUST be sent. If that too exceeds size limits, snmpSilentDrops is incremented and the message is discarded.
If non-repeaters or max-repetitions values in a GetBulkRequest-PDU are less than zero, they MUST be treated as zero. The response may contain fewer bindings than requested if size constraints are exceeded, all repetitions are endOfMibView, or processing time is excessive (with at least one repetition completed).
In SetRequest-PDU Phase 2, all variable assignments occur as if simultaneously. If the same variable is named more than once with different values, the actual assignment is implementation-specific. Implementations are strongly encouraged to avoid commitFailed and undoFailed.
SNMPv2 limits OBJECT IDENTIFIER values to a maximum of 128 sub-identifiers, where each sub-identifier has a maximum value of 2^32-1 (4294967295).
A SNMPv2 entity may operate in agent role (responds to requests, sends traps), manager role (initiates requests, receives traps/informs), or both. It may also act as a proxy agent, appearing to be an agent while satisfying requests by acting as a manager toward a remote entity.
GetBulkRequest-PDU uses non-repeaters (N) and max-repetitions (M) to request N single lexicographic successors for the first N bindings, plus M successive lexicographic successors for each of the remaining R bindings. Total requested bindings = N + (M * R).
GetNextRequest-PDU returns the lexicographic successor of each named variable in the accessible MIB view. If no successor exists for a binding, the value field is set to endOfMibView with the name from the request, signaling the end of the MIB.
GetRequest-PDU processing returns noSuchObject if the variable's OID prefix does not match any accessible variable, or noSuchInstance if the prefix matches but the exact instance does not exist. These per-binding exceptions allow partial success in a single response.
SNMPv2 defines eight PDU types: GetRequest-PDU [0], GetNextRequest-PDU [1], Response-PDU [2], SetRequest-PDU [3], GetBulkRequest-PDU [5], InformRequest-PDU [6], SNMPv2-Trap-PDU [7], and Report-PDU [8]. Tag [4] is obsolete. GetBulkRequest uses BulkPDU structure; all others use the common PDU structure.
The error-status field in a Response-PDU encodes 19 distinct values (0=noError through 18=inconsistentName), including legacy SNMPv1 codes (noSuchName=2, badValue=3, readOnly=4) retained for proxy compatibility.
The InformRequest-PDU is sent manager-to-manager to notify of MIB information remote to the receiver. Like SNMPv2-Trap-PDU, its first two bindings must be sysUpTime.0 and snmpTrapOID.0. The receiver MUST respond with a Response-PDU echoing the request-id and variable-bindings.
The Report-PDU [8] has no presently defined usage or semantics in this document. Any SNMP administrative framework making use of this PDU must define its usage and semantics.
The request-id field is an Integer32 used to correlate requests with responses and to identify duplicated messages in unreliable datagram transport. Using the same request-id on retransmission allows either the original or retransmitted response to satisfy the request.
The SNMPv2-Trap-PDU must always have sysUpTime.0 as the first variable binding and snmpTrapOID.0 as the second. If the NOTIFICATION-TYPE macro includes an OBJECTS clause, corresponding variable instances are appended in order.
Security issues are explicitly not discussed in this memo. Authentication, authorization, access control, and privacy policies are defined by the administrative framework in use, which is referenced but not specified here.
SetRequest-PDU processing is a two-phase operation. Phase 1: validate all variable bindings (access, writability, type, length, encoding, value, existence). If all succeed, Phase 2: assign all values atomically. If any assignment fails in Phase 2, all assignments are undone (commitFailed); if undo is impossible, undoFailed is returned.
BulkPDU is 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). Variable-binding values are ignored in the request.
The common PDU structure is a SEQUENCE containing: request-id (Integer32), error-status (INTEGER enumeration 0–18), error-index (INTEGER 0..max-bindings), and variable-bindings (VarBindList). max-bindings is defined as 2147483647.
VarBind is a SEQUENCE of name (ObjectName/OBJECT IDENTIFIER) paired with a CHOICE of: value (ObjectSyntax), unSpecified (NULL), noSuchObject [0] IMPLICIT NULL, noSuchInstance [1] IMPLICIT NULL, or endOfMibView [2] IMPLICIT NULL.