Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework
obsoleted by
- rfc-3584 — Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework
obsoletes
Extracted elements (30)
The SNMP-COMMUNITY-MIB uses a transport tag mechanism (snmpCommunityTransportTag) referencing the snmpTargetAddrTable rather than embedding addresses directly in the community table, allowing community strings to be accepted only from specific subnets without duplicating address configuration.
Two coexistence approaches are provided: multi-lingual implementations (a single entity supports multiple SNMP versions and selects the appropriate one per peer) and proxy implementations (a forwarder translates between versions on behalf of mono-lingual entities). The proxy approach is also useful for securing communications over insecure links between locally secure networks.
Counter64 is the only SMIv2 syntax incompatible with SMIv1; all other SMIv2 syntaxes are compatible. This incompatibility requires special handling in multi-lingual command responders and proxy forwarders and prevents transmission of Counter64 values over SNMPv1.
In SMIv1, the ACCESS clause specifies the minimum required access, while in SMIv2, the MAX-ACCESS clause specifies the maximum allowed access — this semantic inversion must be carefully considered during MIB module conversion.
SNMPv1 error codes SHOULD NOT be forwarded unchanged in SNMPv2c or SNMPv3 messages, except in proxy forwarding scenarios where backwards compatibility permits reuse of SNMPv1 error codes without translation.
When a proxy forwards an SNMPv1 Trap as an SNMPv2 notification, three additional variable bindings (snmpTrapAddress.0, snmpTrapCommunity.0, snmpTrapEnterprise.0) are appended to preserve the original SNMPv1 agent-addr, community string, and enterprise OID.
A command generator MUST downgrade GetBulkRequest PDUs to GetNextRequest PDUs when SNMPv1 is selected as the message version, by changing the operation type to GetNext and ignoring non-repeaters and max-repetitions values.
For SMIv1-to-SMIv2 conversion, the ACCESS clause MUST be replaced by MAX-ACCESS. A write-only ACCESS value MUST become read-write with a DESCRIPTION noting implementation-specific read results. STATUS values of 'mandatory' or 'optional' MUST be replaced with 'current', 'deprecated', or 'obsolete'.
For SMIv1-to-SMIv2 MIB conversion: the IMPORTS statement MUST reference SNMPv2-SMI; MODULE-IDENTITY MUST be invoked immediately after IMPORTS; unbounded INTEGER MUST become Integer32; Counter MUST become Counter32; Gauge MUST become Gauge32 or Unsigned32.
If an SNMPv2-Trap-PDU received by a proxy contains Counter64 objects, the trap cannot be forwarded using SNMPv1. An InformRequest-PDU configuration indicating SNMPv1 forwarding SHALL be ignored; InformRequest-PDUs can only be forwarded using SNMPv2c or SNMPv3.
Multi-lingual command responders MUST NOT return a variable binding containing a Counter64 value in response to an SNMPv1 request. Counter64 object instances are treated as implicitly excluded from view when processing SNMPv1 messages.
The community string used in an outgoing SNMPv1 response MUST be the same as the community string from the original request; the original community string MUST be present in the stateReference of the original request.
When a proxy receives a GetBulkRequest-PDU and must forward it using SNMPv1, the proxy forwarder SHALL set non-repeaters and max-repetitions to 0 and change the PDU tag to GetNextRequest-PDU.
When a proxy receives a GetResponse containing Counter64 variable bindings that must be forwarded via SNMPv1, the proxy MUST generate an alternate response with noSuchName error-status using the original SNMPv1 request's variable bindings.
When an SNMPv1 GetNextRequest triggers an endOfMibView exception from SNMPv2 MIB access, the error-status SHALL be set to noSuchName with the error-index pointing to the offending binding and the original variable binding list returned.
When an SNMPv1 GetRequest returns a noSuchObject or noSuchInstance exception from SNMPv2 MIB access, the error-status SHALL be set to noSuchName, the error-index set to the offending variable binding, and the original request's variable binding list returned.
When converting a TRAP-TYPE macro to NOTIFICATION-TYPE for SMIv2 conformance, the ENTERPRISE clause MUST be removed, VARIABLES renamed to OBJECTS, a STATUS clause MUST be added, and one or more NOTIFICATION-GROUPs MUST be defined.
When processing an SNMPv1 GetNextRequest using SNMPv2 MIB access, any Counter64 variable bindings SHALL be treated as not-in-view and MIB data accessed repeatedly until a non-Counter64 value or an error is returned.
When processing an SNMPv1 GetRequest using SNMPv2 MIB access, if error-status is noError but variable bindings contain Counter64 or SNMPv2 exceptions, one such binding SHALL be selected, error-status set to noSuchName, and the original request's variable binding list returned.
Whenever the SNMPv2 error-status authorizationError is translated to the SNMPv1 error-status noSuchName, the counter snmpInBadCommunityUses MUST be incremented.
Error status mapping from SNMPv2 to SNMPv1: wrongValue/wrongEncoding/wrongType/wrongLength/inconsistentValue map to badValue; noAccess/notWritable/noCreation/inconsistentName/authorizationError map to noSuchName; resourceUnavailable/commitFailed/undoFailed map to genErr.
SNMPv1 notification parameters consist of: enterprise (OBJECT IDENTIFIER), agent-addr (NetworkAddress), generic-trap (INTEGER), specific-trap (INTEGER), time-stamp (TimeTicks), and a variable-bindings list.
SNMPv1-to-SNMPv2 notification translation: sysUpTime is taken from time-stamp; for generic-trap 6 (enterpriseSpecific), snmpTrapOID is formed by concatenating the enterprise OID with '.0' and the specific-trap value; for standard traps 0-5, snmpTrapOID maps to the corresponding RFC1907 OID.
SNMPv2 notification parameters consist of: sysUpTime (TimeTicks) as first variable-binding, snmpTrapOID (OBJECT IDENTIFIER) as second variable-binding, and the remaining variable-bindings list in an SNMPv2-Trap-PDU or InformRequest-PDU.
The snmpCommunityTable maps each community string (snmpCommunityName) to a securityName, contextEngineID, contextName, and optional transport tag (snmpCommunityTransportTag) for source address validation. Rows are indexed by snmpCommunityIndex (SnmpAdminString, 1..32 octets).
The SNMP-COMMUNITY-MIB (snmpModules 18) is defined, containing the snmpCommunityTable for mapping community strings to SNMPv3 securityName/contextEngineID/contextName, and the snmpTargetAddrExtTable augmenting SNMP-TARGET-MIB with transport address mask and maximum message size.
SNMPv1 and SNMPv2c provide no security mechanisms (no authentication or encryption). The SNMP-COMMUNITY-MIB enables view-based access control (VACM) to limit SNMPv1/v2c access; administrators MUST employ this and restrict community-based access to read-only where possible to mitigate risk from unauthenticated operations.
The snmpCommunityTransportTag object provides source address validation for incoming SNMPv1/SNMPv2c requests, allowing administrators to restrict which transport endpoints may use a given community string. A zero-length tag disables this check, accepting requests from any source.
snmpTargetAddrMMS is an Integer32 (0 | 484..2147483647) representing the maximum message size for an SNMP peer; the default value is 484. It is used for SNMPv1/SNMPv2c transactions where the message format does not carry a max message size.
snmpTargetAddrTMask is an OCTET STRING (SIZE 0..255) whose length must be zero or equal to the corresponding snmpTargetAddrTAddress length. Bits set to 1 in the mask indicate address bits that must match; zero-length mask means exact address match required.