Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)
obsoleted by
- rfc-1905 — Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)
Extracted elements (28)
GetBulkRequest-PDU was introduced to minimize protocol exchanges when retrieving large amounts of data, particularly for table traversal. Under network stress, only small values should be used for max-repetitions to reduce the risk of fragmentation, which is considered harmful as it reduces transfer reliability.
SNMPv2 requires only an unreliable datagram service, with every message entirely and independently contained in a single transport datagram. The preferred transport mapping is UDP. Retransmission of unanswered requests is left to the discretion of the requesting application, which must act responsibly regarding frequency and duration.
The request-id field allows a SNMPv2 application to correlate incoming responses with outstanding requests and identify messages duplicated by the unreliable datagram transport. Using the same request-id on retransmission lets either the original or retransmitted response satisfy the request, but a different request-id is recommended when RTT calculation is needed.
The SetRequest two-phase design (validate-then-assign) was chosen to ensure consistency: all-or-nothing semantics mean that either all variables are set or none are, with commitFailed and undoFailed providing a last-resort indication when atomicity could not be maintained. The RFC explicitly discourages using these codes as an easy implementation shortcut.
Three SNMPv1 error codes (noSuchName, badValue, readOnly) are retained in the SNMPv2 error-status enumeration solely for proxy compatibility, allowing SNMPv2 managers to handle responses forwarded through SNMPv1 proxies without failure.
A compliant SNMPv2 entity acting in a manager role must be able to properly receive and handle a Response-PDU with error-status field equal to 'noSuchName', 'badValue', or 'readOnly', which are SNMPv1 error codes retained for proxy compatibility.
A conformant SNMPv2 implementation MUST never generate messages larger than allowed by the receiving SNMPv2 entity, as indicated by partyMaxMessageSize of the destination party.
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 value is defined for use as the value portion of bindings in request PDUs where the value is not 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.
SNMPv2 limits OBJECT IDENTIFIER values to a maximum of 128 sub-identifiers, where each sub-identifier has a maximum value of 2**32-1.
GetBulkRequest-PDU uses non-repeaters (N) and max-repetitions (M) fields: the first N bindings are retrieved as single GetNext operations, while the remaining R bindings are each retrieved M times lexicographically. The total requested bindings is N + (M * R).
GetNextRequest-PDU retrieves the lexicographic successor of each named variable in the accessible MIB. If no successor exists, the variable binding in the Response-PDU has its value set to 'endOfMibView' and its name set to the requested name, signaling the end of the MIB view.
GetRequest-PDU processing returns noSuchObject in the variable binding if the OID prefix does not match any accessible variable, or noSuchInstance if the prefix matches but the exact instance is not found. On any other processing failure, a genErr response with the error-index set to the failed binding is returned.
If any SetRequest assignment fails after all validations pass, all other assignments MUST be undone and the error-status is set to 'commitFailed'. If it is not possible to undo all assignments, error-status is set to 'undoFailed' and error-index is set to zero. Implementations are strongly encouraged to avoid these error codes.
If the GetBulkRequest Response-PDU would exceed the message size limit, the response is generated with fewer variable bindings (those at the end are removed) such that the message size is approximately but not greater than the constraint. If all bindings in an iteration return endOfMibView, the response may be truncated at that iteration.
InformRequest-PDU is a confirmed manager-to-manager notification. The first two variable bindings MUST be sysUpTime.0 and snmpEventID.i. Upon receipt, the receiving entity responds with a Response-PDU echoing the same request-id and variable-bindings with error-status noError.
SetRequest-PDU processing uses a conceptual two-phase operation: first all variable bindings are validated (checks for noAccess, noCreation, notWritable, wrongType, wrongLength, wrongEncoding, wrongValue, inconsistentName, inconsistentValue, resourceUnavailable in that order), then if all validations succeed all assignments are made simultaneously.
SNMPv2 defines seven PDU types: GetRequest-PDU [0], GetNextRequest-PDU [1], Response-PDU [2], SetRequest-PDU [3], GetBulkRequest-PDU [5], InformRequest-PDU [6], and SNMPv2-Trap-PDU [7]. Tag [4] is explicitly marked obsolete.
SNMPv2-Trap-PDU variable-bindings MUST include as the first variable sysUpTime.0 and as the second variable snmpTrapOID.0 (the notification's administratively assigned name). Additional variables from the NOTIFICATION-TYPE OBJECTS clause follow, with optional additional variables at agent discretion.
The Response-PDU's request-id field takes the same value as the request PDU to which it responds. If error-status is non-zero, the error-index field identifies the variable binding (1-based index) that caused the failure; the value fields of all variable bindings are ignored when error-status is non-zero.
Trap destinations are determined by consulting the aclTable: entries where aclSubject refers to the SNMPv2 entity, aclPrivileges allows SNMPv2-Trap-PDU, and aclResources refers to a context whose MIB view contains the notification's name. The snmpTrapNumbers instance for each target is incremented and used as the request-id.
When a GetRequest, GetNextRequest, SetRequest, or InformRequest response would exceed the message size limit, an alternate Response-PDU with error-status 'tooBig', error-index zero, and empty variable-bindings is sent. If even the tooBig response exceeds the size limit, it is silently discarded.
When processing SetRequest-PDU, if the same variable is named more than once with different values, the actual assignment is implementation-specific. All assignments in a single request occur as if simultaneously with respect to each other.
Security issues are explicitly not discussed in this memo. Authentication and authorization policies are defined in the SNMPv2 Administrative Model (RFC 1445), which governs the message wrapper that encapsulates the PDUs defined here.
The BulkPDU SEQUENCE, used only for GetBulkRequest-PDU, replaces error-status and error-index with non-repeaters (INTEGER 0..max-bindings) and max-repetitions (INTEGER 0..max-bindings), and is specified to be identical in structure to PDU.
The standard PDU SEQUENCE contains: request-id (Integer32), error-status (INTEGER enumeration with 19 named values from noError(0) to inconsistentName(18)), error-index (INTEGER 0..max-bindings), and variable-bindings (VarBindList). max-bindings is defined as 2147483647.
VarBind is a SEQUENCE of name (ObjectName) and a CHOICE among: value (ObjectSyntax), unSpecified (NULL for retrieval requests), noSuchObject [0] IMPLICIT NULL, noSuchInstance [1] IMPLICIT NULL, and endOfMibView [2] IMPLICIT NULL. The three exception values are new in SNMPv2.