As per Relevance of the word existence, we have this rfc below:
Network Working Group R.
Request for Comments: 2576 CoSine
Category: Standards Track D.
Nortel
S.
Integrated Systems Inc
B.
Lucent
March 2000
Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
The purpose of this document is to describe coexistence
version 3 of the Internet-standard Network Management Framework
(SNMPv3), version 2 of the Internet-standard Network
Framework (SNMPv2), and the original Internet-standard
Management Framework (SNMPv1). This document obsoletes RFC 1908 [13]
and RFC2089 [14].
Table Of
1 Overview ..................................................... 2
1.1 SNMPv1 ..................................................... 3
1.2 SNMPv2 ..................................................... 4
1.3 SNMPv3 ..................................................... 4
1.4 SNMPv1 and SNMPv2 Access to MIB Data ....................... 5
2 SMI and Management Information Mappings ...................... 5
2.1 MIB Modules ................................................ 6
2.1.1 Object Definitions ....................................... 6
2.1.2 Trap and Notification Definitions ........................ 9
2.2 Compliance Statements ...................................... 9
2.3 Capabilities Statements .................................... 10
Frye, et al. Standards Track [Page 1]
RFC 2576 Coexistence between SNMP versions March 2000
3 Translating Notifications Parameters ......................... 10
3.1 Translating SNMPv1 Notification Parameters to SNMPv
Notification Parameters ................................... 12
3.2 Translating SNMPv2 Notification Parameters to SNMPv
Notification Parameters ................................... 13
4 Approaches to Coexistence in a Multi-lingual Network ......... 14
4.1 Multi-lingual implementations .............................. 15
4.1.1 Command Generator ........................................ 15
4.1.2 Command Responder ........................................ 15
4.1.2.1 Handling Counter64 ..................................... 16
4.1.2.2 Mapping SNMPv2 Exceptions .............................. 16
4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 17
4.1.2.2.2 Mapping endOfMibView ................................. 17
4.1.2.3 Processing An SNMPv1 GetRequest ........................ 18
4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 19
4.1.2.5 Processing An SNMPv1 SetRequest ........................ 20
4.1.3 Notification Originator .................................. 20
4.1.4 Notification Receiver .................................... 21
4.2 Proxy Implementations ...................................... 21
4.2.1 Upstream Version Greater Than Downstream Version ......... 21
4.2.2 Upstream Version Less Than Downstream Version ............ 22
4.3 Error Status Mappings ...................................... 24
5 Message Processing Models and Security Models ................ 25
5.1 Mappings ................................................... 25
5.2 The SNMPv1 MP Model and SNMPv1 Community-based
Model ..................................................... 26
5.2.1 Processing An Incoming Request ........................... 26
5.2.2 Generating An Outgoing Response .......................... 28
5.2.3 Generating An Outgoing Notification ...................... 28
5.3 The SNMP Community MIB Module .............................. 29
6 Intellectual Property ........................................ 39
7 Acknowledgments .............................................. 39
8 Security Considerations ...................................... 40
9 References ................................................... 40
10 Editor's Addresses .......................................... 42
A. Changes From RFC1908 ........................................ 43
Full Copyright Statement ....................................... 44
1.
The purpose of this document is to describe coexistence
version 3 of the Internet-standard Network Management Framework
termed the SNMP version 3 framework (SNMPv3), version 2 of
Internet-standard Network Management Framework, termed the
version 2 framework (SNMPv2), and the original Internet-
Network Management Framework (SNMPv1).
Frye, et al. Standards Track [Page 2]
RFC 2576 Coexistence between SNMP versions March 2000
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC2119 [15].
There are four general aspects of coexistence described in
document. Each of these is described in a separate section
- Conversion of MIB documents between SMIv1 and SMIv2 formats
documented in section 2.
- Mapping of notification parameters is documented in section 3.
- Approaches to coexistence between entities which support
various versions of SNMP in a multi-lingual network
documented in section 4. This section addresses the
of protocol operations in multi-lingual implementations,
well as behaviour of proxy implementations
- The SNMPv1 Message Processing Model and Community-
Security Model, which provides mechanisms for adapting SNMPv
into the View-Based Access Control Model (VACM) [20],
documented in section 5 (this section also addresses
SNMPv2c Message Processing Model and Community-Based
Model).
1.1. SNMPv
SNMPv1 is defined by these documents
- STD 15, RFC 1157 [2] which defines the Simple
Management Protocol (SNMPv1), the protocol used for
access to managed objects
- STD 16, RFC 1155 [1] which defines the Structure of
Information (SMIv1), the mechanisms used for describing
naming objects for the purpose of management
- STD 16, RFC 1212 [3] which defines a more concise
mechanism, which is wholly consistent with the SMIv1.
- RFC 1215 [4] which defines a convention for defining Traps
use with the SMIv1.
Note that throughout this document, the term 'SMIv1' is used.
term generally refers to the information presented in RFC 1155,
1212, and RFC 1215.
Frye, et al. Standards Track [Page 3]
RFC 2576 Coexistence between SNMP versions March 2000
1.2. SNMPv
SNMPv2 is defined by these documents
- STD 58, RFC 2578 which defines Version 2 of the Structure
Management Information (SMIv2) [7].
- STD 58, RFC 2579 which defines common MIB "Textual Conventions
[8].
- STD 58, RFC 2580 which defines Conformance Statements
requirements for defining agent and manager capabilities [9].
- RFC 1905 which defines the Protocol Operations used
processing [10].
- RFC 1906 which defines the Transport Mappings used "on
wire" [11].
- RFC 1907 which defines the basic Management Information
for monitoring and controlling some basic common functions
SNMP entities [12].
Note that SMIv2 as used throughout this document refers to the
three documents listed above (RFCs 2578, 2579, and 2580).
The following document augments the definition of SNMPv2:
- RFC 1901 [6] is an Experimental definition for using SNMPv
PDUs within a community-based message wrapper. This
referred to throughout this document as SNMPv2c
1.3. SNMPv
SNMPv3 is defined by these documents
- RFC 2571 which defines an Architecture for Describing
Management Frameworks [16].
- RFC 2572 which defines Message Processing and Dispatching [17].
- RFC 2573 which defines various SNMP Applications [18].
- RFC 2574 which defines the User-based Security Model (USM),
providing for both Authenticated and Private (encrypted)
messages [19].
Frye, et al. Standards Track [Page 4]
RFC 2576 Coexistence between SNMP versions March 2000
- RFC 2575 which defines the View-based Access Control
(VACM), providing the ability to limit access to different
objects on a per-user basis [20].
SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907
the SMIv2 definitions of 2578 through 2580 described above
1.4. SNMPv1 and SNMPv2 Access to MIB
In several places, this document refers to 'SNMPv1 Access to
Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the
of an SNMP agent which actually accesses instances of MIB objects
and which actually initiates generation of notifications
Differences between the two types of access to MIB data are
- Error-status values generated
- Generation of exception codes
- Use of the Counter64 data type
- The format of parameters provided when a notification
generated
SNMPv1 access to MIB data may generate SNMPv1 error-status values
will never generate exception codes nor use the Counter64 data type
and will provide SNMPv1 format parameters for
notifications. Note also that SNMPv1 access to MIB data
actually never generate a readOnly error (a noSuchName error
always occur in the situation where one would expect a
error).
SNMPv2 access to MIB data may generate SNMPv2 error-status values
may generate exception codes, may use the Counter64 data type,
will provide SNMPv2 format parameters for generating notifications
Note that SNMPv2 access to MIB data will never generate readOnly
noSuchName, or badValue errors
Note that a particular multi-lingual implementation may choose
implement all access to MIB data as SNMPv2 access to MIB data,
perform the translations described herein for SNMPv1-
transactions
2. SMI and Management Information
The SMIv2 approach towards describing collections of managed
is nearly a proper superset of the approach defined in the SMIv1.
For example, both approaches use an adapted subset of ASN.1 (1988)
Frye, et al. Standards Track [Page 5]
RFC 2576 Coexistence between SNMP versions March 2000
[11] as the basis for a formal descriptive notation. Indeed,
might note that the SMIv2 approach largely codifies the
practice for defining MIB modules, based on extensive experience
the SMIv1.
The following sections consider the three areas: MIB modules
compliance statements, and capabilities statements
2.1. MIB
MIB modules defined using the SMIv1 may continue to be used
protocol versions which use SNMPv2 PDUs. However, for the
modules to conform to the SMIv2, the following changes SHALL be made
2.1.1. Object
In general, conversion of a MIB module does not require
deprecation of the objects contained therein. If the definition
an object is truly inadequate for its intended purpose, the
SHALL be deprecated or obsoleted, otherwise deprecation is
required
(1) The IMPORTS statement MUST reference SNMPv2-SMI, instead
RFC1155-SMI and RFC-1212.
(2) The MODULE-IDENTITY macro MUST be invoked immediately after
IMPORTs statement
(3) For any object with an integer-valued SYNTAX clause, in
the corresponding INTEGER does not have a range
(i.e., the INTEGER has neither a defined set of named-
enumerations nor an assignment of lower- and upper-bounds on
value), the object MUST have the value of its SYNTAX
changed to Integer32, or have an appropriate range specified
(4) For any object with a SYNTAX clause value of Counter, the
MUST have the value of its SYNTAX clause changed to Counter32.
(5) For any object with a SYNTAX clause value of Gauge, the
MUST have the value of its SYNTAX clause changed to Gauge32,
Unsigned32 where appropriate
(6) For all objects, the ACCESS clause MUST be replaced by a MAX
ACCESS clause. The value of the MAX-ACCESS clause SHALL be
same as that of the ACCESS clause unless some other value
"protocol sense" as the maximal level of access for the object
In particular, object types for which instances can
explicitly created by a protocol set operation, SHALL have
Frye, et al. Standards Track [Page 6]
RFC 2576 Coexistence between SNMP versions March 2000
MAX-ACCESS clause of "read-create". If the value of the
clause is "write-only", then the value of the MAX-ACCESS
MUST be "read-write", and the DESCRIPTION clause SHALL note
reading this object will result in implementation-
results. Note that in SMIv1, the ACCESS clause specifies
minimal required access, while in SMIv2, the MAX-ACCESS
specifies the maximum allowed access. This should be
when converting an ACCESS clause to a MAX-ACCESS clause
(7) For all objects, if the value of the STATUS clause
"mandatory" or "optional", the value MUST be replaced
"current", "deprecated", or "obsolete" depending on the
usage of such objects
(8) For any object not containing a DESCRIPTION clause, the
MUST have a DESCRIPTION clause defined
(9) For any object corresponding to a conceptual row which does
have an INDEX clause, the object MUST have either an
clause or an AUGMENTS clause defined
(10) If any INDEX clause contains a reference to an object with
syntax of NetworkAddress, then a new object MUST be created
placed in this INDEX clause immediately preceding the
whose syntax is NetworkAddress. This new object MUST have
syntax of INTEGER, it MUST be not-accessible, and its value
always be 1. This approach allows one to convert a MIB
in SMIv1 format to one in SMIv2 format, and then use it with
SNMPv1 protocol with no impact to existing SNMPv1 agents
managers
(11) For any object with a SYNTAX of NetworkAddress, the SYNTAX
be changed to IpAddress. Note that the use of NetworkAddress
new MIB documents is strongly discouraged (in fact, new
documents should be written using SMIv2, which does not
NetworkAddress).
(12) For any object containing a DEFVAL clause with an
IDENTIFIER value which is expressed as a collection of sub
identifiers, the value MUST be changed to reference a
ASN.1 identifier. This may require defining a series of
administrative assignments (OBJECT IDENTIFIERS) in order
define the single ASN.1 identifier
(13) One or more OBJECT-GROUPS MUST be defined, and related
SHOULD be collected into appropriate groups. Note that SMIv
requires all OBJECT-TYPEs to be a member of at least
OBJECT-GROUP
Frye, et al. Standards Track [Page 7]
RFC 2576 Coexistence between SNMP versions March 2000
Other changes are desirable, but not necessary
(1) Creation and deletion of conceptual rows is inconsistent
the SMIv1. The SMIv2 corrects this. As such, if the MIB
undergoes review early in its lifetime, and it
conceptual tables which allow creation and deletion
conceptual rows, then the objects relating to those tables
be deprecated and replaced with objects defined using the
approach. The approach based on SMIv2 can be found in section 7
of RFC2578 [7], and the RowStatus and StorageType TEXTUAL
CONVENTIONs are described in section 2 of RFC2579 [8].
(2) For any object with a string-valued SYNTAX clause, in which
corresponding OCTET STRING does not have a size
(i.e., the OCTET STRING has no assignment of lower- and upper
bounds on its length), the bounds for the size of the
SHOULD be defined
(3) All textual conventions informally defined in the MIB
SHOULD be redefined using the TEXTUAL-CONVENTION macro. Such
change would not necessitate deprecating objects
defined using an informal textual convention
(4) For any object which represents a measurement in some kind
units, a UNITS clause SHOULD be added to the definition of
object
(5) For any conceptual row which is an extension of
conceptual row, i.e., for which subordinate columnar
both exist and are identified via the same semantics as
other conceptual row, an AUGMENTS clause SHOULD be used in
of the INDEX clause for the object corresponding to
conceptual row which is an extension
Finally, to avoid common errors in SMIv1 MIB modules
(1) For any non-columnar object that is instanced as if it
immediately subordinate to a conceptual row, the value of
STATUS clause of that object MUST be changed to "obsolete".
(2) For any conceptual row object that is not contained
subordinate to a conceptual table, the value of the
clause of that object (and all subordinate objects) MUST
changed to "obsolete".
Frye, et al. Standards Track [Page 8]
RFC 2576 Coexistence between SNMP versions March 2000
2.1.2. Trap and Notification
If a MIB module is changed to conform to the SMIv2, then
occurrence of the TRAP-TYPE macro MUST be changed to a
invocation of the NOTIFICATION-TYPE macro
(1) The IMPORTS statement MUST NOT reference RFC-1215 [4], and
reference SNMPv2-SMI instead
(2) The ENTERPRISE clause MUST be removed
(3) The VARIABLES clause MUST be renamed to the OBJECTS clause
(4) A STATUS clause MUST be added, with an appropriate value
Normally the value should be 'current,' although 'deprecated'
'obsolete' may be used as needed
(5) The value of an invocation of the NOTIFICATION-TYPE macro is
OBJECT IDENTIFIER, not an INTEGER, and MUST be
accordingly. Specifically, if the value of the
clause is not 'snmp' then the value of the invocation SHALL
the value of the ENTERPRISE clause extended with two sub
identifiers, the first of which has the value 0, and the
has the value of the invocation of the TRAP-TYPE. If the
of the ENTERPRISE clause is 'snmp', then the value of
invocation of the NOTIFICATION-TYPE macro SHALL be mapped in
same manner as described in section 3.1 in this document
(6) A DESCRIPTION clause MUST be added, if not already present
(7) One or more NOTIFICATION-GROUPs MUST be defined, and
notifications MUST be collected into those groups. Note
SMIv2 requires that all NOTIFICATION-TYPEs be a member of
least one NOTIFICATION-GROUP
2.2. Compliance
For those information modules which are "standards track",
corresponding invocation of the MODULE-COMPLIANCE macro and
OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included
the information module (or in a companion information module),
any commentary text in the information module which relates
compliance SHOULD be removed. Typically this editing can occur
the information module undergoes review
Frye, et al. Standards Track [Page 9]
RFC 2576 Coexistence between SNMP versions March 2000
Note that a MODULE-COMPLIANCE statement is not required for a
document that is not on the standards track (for example,
enterprise MIB), though it may be useful in some circumstances
define a MODULE-COMPLIANCE statement for such a MIB document
2.3. Capabilities
RFC1303 [5] uses the MODULE-CONFORMANCE macro to describe an agent'
capabilities with respect to one or more MIB modules.
such a description for use with the SMIv2 requires these changes
(1) The macro name AGENT-CAPABILITIES SHOULD be used instead
MODULE-CONFORMANCE
(2) The STATUS clause SHOULD be added, with a value of 'current'.
(3) All occurrences of the CREATION-REQUIRES clause MUST either
omitted if appropriate, or be changed such that the
are consistent with RFC2580 [9].
In order to ease coexistence, object groups defined in an SMIv
compliant MIB module may be referenced by the INCLUDES clause of
invocation of the AGENT-CAPABILITIES macro: upon encountering
reference to an OBJECT IDENTIFIER subtree defined in an SMIv1
module, all leaf objects which are subordinate to the subtree
have a STATUS clause value of mandatory are deemed to be INCLUDED
(Note that this method is ambiguous when different revisions of
SMIv1 MIB have different sets of mandatory objects under the
subtree; in such cases, the only solution is to rewrite the MIB
the SMIv2 in order to define the object groups unambiguously.)
3. Translating Notifications
This section describes how parameters used for
notifications are translated between the format used for SNMPv
notification protocol operations and the format used for SNMPv
notification protocol operations. The parameters used to generate
notification are called 'notification parameters'. The format
parameters used for SNMPv1 notification protocol operations
refered to in this document as 'SNMPv1 notification parameters'.
format of parameters used for SNMPv2 notification protocol
is refered to in this document as 'SNMPv2 notification parameters'.
Frye, et al. Standards Track [Page 10]
RFC 2576 Coexistence between SNMP versions March 2000
The situations where notification parameters MUST be translated are
- When an entity generates a set of notification parameters in
particular format, and the configuration of the
indicates that the notification must be sent using an
message version that requires the other format for
parameters
- When a proxy receives a notification that was sent using
SNMP message version that requires one format of
parameters, and must forward the notification using an
message version that requires the other format of
parameters
In addition, it MAY be desirable to translate notification
in a notification receiver application in order to
notifications to the end user in a consistent format
Note that for the purposes of this section, the set of
parameters is independent of whether the notification is to be
as a trap or an inform
SNMPv1 notification parameters consist of
- An enterprise parameter (OBJECT IDENTIFIER).
- An agent-addr parameter (NetworkAddress).
- A generic-trap parameter (INTEGER).
- A specific-trap parameter (INTEGER).
- A time-stamp parameter (TimeTicks).
- A list of variable-bindings (VarBindList).
SNMPv2 notification parameters consist of
- A sysUpTime parameter (TimeTicks). This appears in the
variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU
- An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears
the second variable-binding in an SNMPv2-Trap-PDU
InformRequest-PDU
- A list of variable-bindings (VarBindList). This refers to
but the first two variable-bindings in an SNMPv2-Trap-PDU
InformRequest-PDU
Frye, et al. Standards Track [Page 11]
RFC 2576 Coexistence between SNMP versions March 2000
3.1. Translating SNMPv1 Notification Parameters to SNMPv2
The following procedure describes how to translate SNMPv
notification parameters into SNMPv2 notification parameters
(1) The SNMPv2 sysUpTime parameter SHALL be taken directly from
SNMPv1 time-stamp parameter
(2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)',
the SNMPv2 snmpTrapOID parameter SHALL be the concatentation
the SNMPv1 enterprise parameter and two additional sub
identifiers, '0', and the SNMPv1 specific-trap parameter
(3) If the SNMPv1 generic-trap parameter is not '
enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter
be the corresponding trap as defined in section 2 of RFC1907
[12]:
generic-trap parameter snmpTrapOID.0
====================== =============
0 1.3.6.1.6.3.1.1.5.1 (coldStart
1 1.3.6.1.6.3.1.1.5.2 (warmStart
2 1.3.6.1.6.3.1.1.5.3 (linkDown
3 1.3.6.1.6.3.1.1.5.4 (linkUp
4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure
5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss
(4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable
bindings. In addition, if the translation is being performed
a proxy in order to forward a received trap, three
variable-bindings will be appended, if these three
variable-bindings do not already exist in the SNMPv1 variable
bindings. The name portion of the first additional
binding SHALL contain snmpTrapAddress.0, and the value
contain the SNMPv1 agent-addr parameter. The name portion
the second additional variable binding SHALL
snmpTrapCommunity.0, and the value SHALL contain the value
the community-string field from the received SNMPv1
which contained the SNMPv1 Trap-PDU. The name portion of
third additional variable binding SHALL
snmpTrapEnterprise.0 [12], and the value SHALL be the SNMPv
enterprise parameter
Frye, et al. Standards Track [Page 12]
RFC 2576 Coexistence between SNMP versions March 2000
3.2. Translating SNMPv2 Notification Parameters to SNMPv1
The following procedure describes how to translate SNMPv
notification parameters into SNMPv1 notification parameters
(1) The SNMPv1 enterprise parameter SHALL be determined as follows
- If the SNMPv2 snmpTrapOID parameter is one of the
traps as defined in RFC1907 [12], then the SNMPv1
parameter SHALL be set to the value of the variable-binding
the SNMPv2 variable-bindings whose name is snmpTrapEnterprise.0
if that variable-binding exists. If it does not exist,
SNMPv1 enterprise parameter SHALL be set to the value '
snmpTraps' as defined in RFC1907 [12].
- If the SNMPv2 snmpTrapOID parameter is not one of the
traps as defined in RFC1907 [12], then the SNMPv1
parameter SHALL be determined from the SNMPv2
parameter as follows
- If the next-to-last sub-identifier of the snmpTrapOID
zero, then the SNMPv1 enterprise SHALL be the SNMPv
snmpTrapOID with the last 2 sub-identifiers removed
- If the next-to-last sub-identifier of the snmpTrapOID
non-zero, then the SNMPv1 enterprise SHALL be the SNMPv
snmpTrapOID with the last sub-identifier removed
(2) The SNMPv1 agent-addr parameter SHALL be determined based on
situation in which the translation occurs
- If the translation occurs within a notification
application, and the notification is to be sent over IP,
SNMPv1 agent-addr parameter SHALL be set to the IP address
the SNMP entity in which the notification originator resides
If the notification is to be sent over some other transport
the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0.
- If the translation occurs within a proxy application, the
must attempt to extract the original source of the
from the variable-bindings. If the SNMPv2 variable-
contains a variable binding whose name is snmpTrapAddress.0,
the agent-addr parameter SHALL be set to the value of
variable binding. Otherwise, the SNMPv1 agent-addr
SHALL be set to 0.0.0.0.
Frye, et al. Standards Track [Page 13]
RFC 2576 Coexistence between SNMP versions March 2000
(3) If the SNMPv2 snmpTrapOID parameter is one of the standard
as defined in RFC1907 [12], the SNMPv1 generic-trap
SHALL be set as follows
snmpTrapOID.0 parameter generic-
=============================== ============
1.3.6.1.6.3.1.1.5.1 (coldStart) 0
1.3.6.1.6.3.1.1.5.2 (warmStart) 1
1.3.6.1.6.3.1.1.5.3 (linkDown) 2
1.3.6.1.6.3.1.1.5.4 (linkUp) 3
1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4
1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5
Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6.
(4) If the SNMPv2 snmpTrapOID parameter is one of the standard
as defined in RFC1907 [12], the SNMPv1 specific-trap
SHALL be set to zero. Otherwise, the SNMPv1 specific-
parameter SHALL be set to the last sub-identifier of the SNMPv
snmpTrapOID parameter
(5) The SNMPv1 time-stamp parameter SHALL be taken directly from
SNMPv2 sysUpTime parameter
(6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable
bindings. Note, however, that if the SNMPv2 variable-
contain any objects whose type is Counter64, the translation
SNMPv1 notification parameters cannot be performed. In
case, the notification cannot be encoded in an SNMPv1
(and so the notification cannot be sent using SNMPv1,
section 4.1.3 and section 4.2).
4. Approaches to Coexistence in a Multi-lingual
There are two basic approaches to coexistence in a multi-
network, multi-lingual implementations and proxy implementations
Multi-lingual implementations allow elements in a network
communicate with each other using an SNMP version which both
support. This allows a multi-lingual implementation to
with any mono-lingual implementation, regardless of the SNMP
supported by the mono-lingual implementation
Proxy implementations provide a mechanism for translating
SNMP versions using a third party network element. This
network elements which support only a single, but different,
version to communicate with each other. Proxy implementations
also useful for securing communications over an insecure link
two locally secure networks
Frye, et al. Standards Track [Page 14]
RFC 2576 Coexistence between SNMP versions March 2000
4.1. Multi-lingual
This approach requires an entity to support multiple SNMP
versions. Typically this means supporting SNMPv1, SNMPv2c,
SNMPv3 message versions. The behaviour of various types of
applications which support multiple message versions is described
the following sections. This approach allows entities which
multiple SNMP message versions to coexist with and communicate
entities which support only a single SNMP message version
4.1.1. Command
A command generator must select an appropriate message version
sending requests to another entity. One way to achieve this is
consult a local database to select the appropriate message version
In addition, a command generator MUST 'downgrade' GetBulk requests
GetNext requests when selecting SNMPv1 as the message version for
outgoing request. This is done by simply changing the operation
to GetNext, ignoring any non-repeaters and max-repetitions values
and setting error-status and error-index to zero
4.1.2. Command
A command responder must be able to deal with both SNMPv1 and SNMPv
access to MIB data. There are three aspects to dealing with this.
command responder must
- Deal correctly with SNMPv2 access to MIB data that returns
Counter64 value while processing an SNMPv1 message
- Deal correctly with SNMPv2 access to MIB data that returns
of the three exception values while processing an SNMPv
message,
- Map SNMPv2 error codes returned from SNMPv2 access to MIB
into SNMPv1 error codes when processing an SNMPv1 message
Note that SNMPv1 error codes SHOULD NOT be used without any
when processing SNMPv2c or SNMPv3 messages, except in the case
proxy forwarding. In the case of proxy forwarding, for
compatibility, SNMPv1 error codes may be used without any change in
forwarded SNMPv2c or SNMPv3 message
The following sections describe the behaviour of a command
application which supports multiple SNMP message versions, and
uses some combination of SNMPv1 and SNMPv2 access to MIB data
Frye, et al. Standards Track [Page 15]
RFC 2576 Coexistence between SNMP versions March 2000
4.1.2.1. Handling Counter64
The SMIv2 [7] defines one new syntax that is incompatible with SMIv1.
This syntax is Counter64. All other syntaxes defined by SMIv2
compatible with SMIv1.
The impact on multi-lingual command responders is that they MUST
ever return a variable binding containing a Counter64 value in
response to a request that was received using the SNMPv1
version
Multi-lingual command responders SHALL take the approach that
instances whose type is Counter64 are implicitly excluded from
when processing an SNMPv1 message. So
- On receipt of an SNMPv1 GetRequest-PDU containing a
binding whose name field points to an object instance of
Counter64, a GetResponsePDU SHALL be returned, with an error
status of noSuchName and the error-index set to the
binding that caused this error
- On an SNMPv1 GetNextRequest-PDU, any object instance
contains a syntax of Counter64 SHALL be skipped, and the
accessible object instance that does not have the syntax
Counter64 SHALL be retrieved. If no such object
exists, then an error-status of noSuchName SHALL be returned
and the error-index SHALL be set to the variable binding
caused this error
- Any SNMPv1 request which contains a variable binding with
Counter64 value is ill-formed, so the foregoing rules do
apply. If that error is detected, a response SHALL NOT
returned, since it would contain a copy of the ill-
variable binding. Instead, the offending PDU SHALL
discarded and the counter snmpInASNParseErrs SHALL
incremented
4.1.2.2. Mapping SNMPv2
SNMPv2 provides a feature called exceptions, which allow an SNMPv
Response PDU to return as much management information as possible
even when an error occurs. However, SNMPv1 does not
exceptions, and so an SNMPv1 Response PDU cannot return
management information, and can only return an error-status
error-index value
Frye, et al. Standards Track [Page 16]
RFC 2576 Coexistence between SNMP versions March 2000
When an SNMPv1 request is received, a command responder MUST
any variable bindings returned using SNMPv2 access to MIB data
exception values, and convert these exception values into SNMPv
error codes
The type of exception that can be returned when accessing MIB
and the action taken depends on the type of SNMP request
- For a GetRequest, a noSuchObject or noSuchInstance
may be returned
- For a GetNextRequest, an endOfMibView exception may
returned
- No exceptions will be returned for a SetRequest, and
GetBulkRequest should only be received in an SNMPv2c or SNMPv
message, so these request types may be ignored when
exceptions
Note that when a response contains multiple exceptions, it is
implementation choice as to which variable binding the error-
should reference
4.1.2.2.1. Mapping noSuchObject and
A noSuchObject or noSuchInstance exception generated by an SNMPv
access to MIB data indicates that the requested object instance
not be returned. The SNMPv1 error code for this condition
noSuchName, and so the error-status field of the response PDU
be set to noSuchName. Also, the error-index field SHALL be set
the index of the variable binding for which an exception
(there may be more than one and it is an implementation decision
to which is used), and the variable binding list from the
request SHALL be returned with the response PDU
4.1.2.2.2. Mapping
When an SNMPv2 access to MIB data returns a variable
containing an endOfMibView exception, it indicates that there are
object instances available which lexicographically follow the
in the request. In an SNMPv1 agent, this condition normally
in a noSuchName error, and so the error-status field of the
PDU SHALL be set to noSuchName. Also, the error-index field SHALL
set to the index of the variable binding for which an
occurred (there may be more than one and it is an
decision as to which is used), and the variable binding list from
original request SHALL be returned with the response PDU
Frye, et al. Standards Track [Page 17]
RFC 2576 Coexistence between SNMP versions March 2000
4.1.2.3. Processing An SNMPv1
When processing an SNMPv1 GetRequest, the following procedures
be followed when using an SNMPv2 access to MIB data
When such an access to MIB data returns response data using SNMPv
syntax and error-status values, then
(1) If the error-status is anything other than noError
- The error status SHALL be translated to an SNMPv1 error-
using the table in section 4.3, "Error Status Mappings".
- The error-index SHALL be set to the position (in the
request) of the variable binding that caused the error-status
- The variable binding list of the response PDU SHALL be
exactly the same as the variable binding list that was
in the original request
(2) If the error-status is noError, the variable bindings SHALL
checked for any SNMPv2 exception (noSuchObject
noSuchInstance) or an SNMPv2 syntax that is unknown to SNMPv
(Counter64). If there are any such variable bindings, one
those variable bindings SHALL be selected (it is
implementation choice as to which is selected), and
- The error-status SHALL be set to noSuchName
- The error-index SHALL be set to the position (in the
binding list of the original request) of the selected
binding,
- The variable binding list of the response PDU SHALL be
the same as the variable binding list that was received in
original request
(3) If there are no such variable bindings, then
- The error-status SHALL be set to noError
- The error-index SHALL be set to zero,
- The variable binding list of the response SHALL be
from the data as it is returned by the access to MIB data
Frye, et al. Standards Track [Page 18]
RFC 2576 Coexistence between SNMP versions March 2000
4.1.2.4. Processing An SNMPv1
When processing an SNMPv1 GetNextRequest, the following
MUST be followed when an SNMPv2 access to MIB data is called as
of processing the request. There may be repetitive accesses to
data to try to find the first object which lexicographically
each of the objects in the request. This is implementation specific
These procedures are followed only for data returned when
SNMPv2 access to MIB data. Data returned using SNMPv1 access to
data may be treated in the normal manner for an SNMPv1 request
First, if the access to MIB data returns an error-status of
other than noError
(1) The error status SHALL be translated to an SNMPv1 error-
using the table in section 4.3, "Error Status Mappings".
(2) The error-index SHALL be set to the position (in the
request) of the variable binding that caused the error-status
(3) The variable binding list of the response PDU SHALL be
the same as the variable binding list that was received in
original request
Otherwise, if the access to MIB data returns an error-status
noError
(1) Any variable bindings containing an SNMPv2 syntax of Counter64
SHALL be considered to be not in view, and MIB data SHALL
accessed as many times as is required until either a value
than Counter64 is returned, or an error occurs
(2) If there is any variable binding that contains an SNMPv
exception endOfMibView (there may be more than one, it is
implementation decision as to which is chosen):
- The error-status SHALL be set to noSuchName
- The error-index SHALL be set to the position (in the
binding list of the original request) of the variable
that returned such an SNMPv2 exception,
- The variable binding list of the response PDU SHALL be
the same as the variable binding list that was received in
original request
(3) If there are no such variable bindings, then
Frye, et al. Standards Track [Page 19]
RFC 2576 Coexistence between SNMP versions March 2000
- The error-status SHALL be set to noError
- The error-index SHALL be set to zero,
- The variable binding list of the response SHALL be
from the data as it is returned by the access to MIB data
4.1.2.5. Processing An SNMPv1
When processing an SNMPv1 SetRequest, the following procedures
be followed when calling SNMPv2 MIB access routines
When such MIB access routines return response data using SNMPv
syntax and error-status values, and the error-status is
other than noError, then
- The error status SHALL be translated to an SNMPv1 error-
using the table in section 4.3, "Error Status Mappings".
- The error-index SHALL be set to the position (in the
request) of the variable binding that caused the error-status
- The variable binding list of the response PDU SHALL be
exactly the same as the variable binding list that was
in the original request
4.1.3. Notification
A notification originator must be able to translate between SNMPv
notifications parameters and SNMPv2 notification parameters in
to send a notification using a particular SNMP message version. If
notification is generated using SNMPv1 notification parameters,
configuration information specifies that notifications be sent
SNMPv2c or SNMPv3, the notification parameters must be translated
SNMPv2 notification parameters. Likewise, if a notification
generated using SNMPv2 notification parameters, and
information specifies that notifications be sent using SNMPv1,
notification parameters must be translated to SNMPv1
parameters. In this case, if the notification cannot be
(due to the presence of a Counter64 type), it will not be sent
SNMPv1.
When a notification originator generates a notification,
parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION
MIB, if the SNMP version used to generate the notification is SNMPv1,
the PDU type used will always be a TrapPDU, regardless of whether
value of snmpNotifyType is trap(1) or inform(2).
Frye, et al. Standards Track [Page 20]
RFC 2576 Coexistence between SNMP versions March 2000
Note also that access control and notification filtering
performed in the usual manner for notifications, regardless of
SNMP message version to be used when sending a notification.
parameters for performing access control are found in the
manner (i.e., from inspecting the SNMP-TARGET-MIB and SNMP
NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap,
order to perform the access check specified in [18], section 3.3,
bullet (3), the notification originator may need to generate a
for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3)
this document. If the SNMPv1 notification parameters being used
previously translated from a set of SNMPv2 notification parameters
this value may already be known, in which case it need not
generated
4.1.4. Notification
There are no special requirements of a notification receiver
However, an implementation may find it useful to allow a higher
application to request whether notifications should be delivered to
higher level application using SNMPv1 notification parameter
SNMPv2 notification parameters. The notification receiver would
translate notification parameters when required in order to present
notification using the desired set of parameters
4.2. Proxy
A proxy implementation may be used to enable communication
entities which support different SNMP message versions. This
accomplished in a proxy forwarder application by
translations on PDUs. These translations depend on the PDU type,
SNMP version of the packet containing a received PDU, and the
version to be used to forward a received PDU. The following
describe these translations. In all cases other than those
below, the proxy SHALL forward a received PDU without change,
to size constraints as defined in section 5.3 (Community MIB) of
document. Note that in the following sections, the '
Version' refers to the version used between the command generator
the proxy, and the 'Downstream Version' refers to the version
between the proxy and the command responder, regardless of the
type or direction
4.2.1. Upstream Version Greater Than Downstream
- If a GetBulkRequest-PDU is received and must be forwarded
the SNMPv1 message version, the proxy forwarder SHALL set
non-repeaters and max-repetitions fields to 0, and SHALL set
tag of the PDU to GetNextRequest-PDU
Frye, et al. Standards Track [Page 21]
RFC 2576 Coexistence between SNMP versions March 2000
- If a GetResponse-PDU is received whose error-status field has
value of 'tooBig', the message will be forwarded using the SNMPv2
or SNMPv3 message version, and the original request received
the proxy was not a GetBulkRequest-PDU, the proxy forwarder
remove the contents of the variable-bindings field
forwarding the response
- If a GetResponse-PDU is received whose error-status field has
value of 'tooBig,' and the message will be forwarded using
SNMPv2c or SNMPv3 message version, and the original
received by the proxy was a GetBulkRequest-PDU, the
forwarder SHALL re-send the forwarded request (which would
been altered to be a GetNextRequest-PDU) with all but the
variable-binding removed. The proxy forwarder SHALL only re-
such a request a single time. If the resulting GetResponse-
also contains an error-status field with a value of 'tooBig,'
the proxy forwarder SHALL remove the contents of the variable
bindings field, and change the error-status field to 'noError
before forwarding the response. Note that if the original
only contained a single variable-binding, the proxy may skip re
sending the request and simply remove the variable-bindings
change the error-status to 'noError.'
- If a Trap-PDU is received, and will be forwarded using the SNMPv2
or SNMPv3 message version, the proxy SHALL apply the
rules described in section 3, and SHALL forward the
as an SNMPv2-Trap-PDU
Note that when an SNMPv1 agent generates a message containing
Trap-PDU which is subsequently forwarded by one or more
forwarders using SNMP versions other than SNMPv1, the
string and agent-addr fields from the original message
by the SNMPv1 agent will be preserved through the use of
snmpTrapAddress and snmpTrapCommunity nobjects
4.2.2. Upstream Version Less Than Downstream
- If a GetResponse-PDU is received in response to a GetRequest-
(previously generated by the proxy) which contains variable
bindings of type Counter64 or which contain an SNMPv2
code, and the message would be forwarded using the SNMPv1
version, the proxy MUST generate an alternate response
consisting of the request-id and variable bindings from
original SNMPv1 request, containing a noSuchName error-
value, and containing an error-index value indicating the
of the variable-binding containing the Counter64 type or
code
Frye, et al. Standards Track [Page 22]
RFC 2576 Coexistence between SNMP versions March 2000
- If a GetResponse-PDU is received in response to a GetNextRequest
PDU (previously generated by the proxy) which contains variable
bindings that contain an SNMPv2 exception code, and the
would be forwarded using the SNMPv1 message version, the
MUST generate an alternate response PDU consisting of
request-id and variable bindings from the original SNMPv1 request
containing a noSuchName error-status value, and containing
error-index value indicating the position of the variable-
containing the exception code
- If a GetResponse-PDU is received in response to a GetNextRequest
PDU (previously generated by the proxy) which contains variable
bindings of type Counter64, the proxy MUST re-send the
GetNextRequest-PDU, with the following modifications. For
variable bindings in the received GetResponse which
Counter64 types, the proxy substitutes the object names of
variable bindings for the corresponding object names in
previously-sent GetNextRequest. The proxy MUST repeat
process until no Counter64 objects are returned. Note that
implementation may attempt to optimize this process of
Counter64 objects. One approach to such an optimization would
to replace the last sub-identifier of the object names of
containing a Counter64 type with 65535 if that sub-identifier
less than 65535, or with 4294967295 if that sub-identifier
greater than 65535. This approach should skip multiple
of the same Counter64 object, while maintaining compatibility
some broken agent implementations (which only use 16-bit
for sub-identifiers).
Deployment Hint: The process of repeated GetNext requests used
a proxy when Counter64 types are returned can be expensive.
deploying a proxy, this can be avoided by configuring the
agents to which the proxy forwards requests in a manner such
any objects of type Counter64 are in fact not-in-view for
principal that the proxy is using when communicating with
agents
- If a GetResponse-PDU is received which contains an SNMPv2 error
status value of wrongValue, wrongEncoding, wrongType, wrongLength
inconsistentValue, noAccess, notWritable, noCreation
inconsistentName, resourceUnavailable, commitFailed, undoFailed
or authorizationError, the error-status value is modified
the mappings in section 4.3.
- If an SNMPv2-Trap-PDU is received, and will be forwarded using
SNMPv1 message version, the proxy SHALL apply the
rules described in section 3, and SHALL forward the
Frye, et al. Standards Track [Page 23]
RFC 2576 Coexistence between SNMP versions March 2000
as a Trap-PDU. Note that if the translation fails due to
existence of a Counter64 data-type in the received SNMPv2-Trap
PDU, the trap cannot be forwarded using SNMPv1.
- If an InformRequest-PDU is received, any configuration
indicating that it would be forwarded using the SNMPv1
version SHALL be ignored. An InformRequest-PDU can only
forwarded using the SNMPv2c or SNMPv3 message version.
InformRequest-PDU may still be forwarded if there is
configuration information indicating that it should be
using SNMPv2c or SNMPv3.
4.3. Error Status
The following tables shows the mappings of SNMPv1 error-status
into SNMPv2 error-status values, and the mappings of SNMPv2 error
status values into SNMPv1 error-status values
SNMPv1 error-status SNMPv2 error-
=================== ===================
noError
tooBig
noSuchName
badValue
genErr
SNMPv2 error-status SNMPv1 error-
=================== ===================
noError
tooBig
genErr
wrongValue
wrongEncoding
wrongType
wrongLength
inconsistentValue
noAccess
notWritable
noCreation
inconsistentName
resourceUnavailable
commitFailed
undoFailed
authorizationError
Frye, et al. Standards Track [Page 24]
RFC 2576 Coexistence between SNMP versions March 2000
Whenever the SNMPv2 error-status value of authorizationError
translated to an SNMPv1 error-status value of noSuchName, the
of snmpInBadCommunityUses MUST be incremented
5. Message Processing Models and Security
In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture
the following models are defined in this document
- The SNMPv1 Message Processing
- The SNMPv1 Community-Based Security
The following models are also described in this document
- The SNMPv2c Message Processing
- The SNMPv2c Community-Based Security
In most respects, the SNMPv1 Message Processing Model and
SNMPv2c Message Processing Model are identical, and so
are not discussed independently in this document.
between the two models are described as required
Similarly, the SNMPv1 Community-Based Security Model and
SNMPv2c Community-Based Security Model are nearly identical
and so are not discussed independently. Differences
these two models are also described as required
5.1.
The SNMPv1 (and SNMPv2c) Message Processing Model and Security
require mappings between parameters used in SNMPv1 (and SNMPv2c
messages, and the version independent parameters used in the
architecture [16]. The parameters which MUST be mapped consist
the SNMPv1 (and SNMPv2c) community name, and the SNMP
and contextEngineID/contextName pair. A MIB module (the SNMP
COMMUNITY-MIB) is provided in this document in order to perform
mappings. This MIB provides mappings in both directions, that is,
community name may be mapped to a securityName, contextEngineID,
contextName, or the combination of securityName, contextEngineID,
contextName may be mapped to a community name
Frye, et al. Standards Track [Page 25]
RFC 2576 Coexistence between SNMP versions March 2000
5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security
The SNMPv1 Message Processing Model handles processing of SNMPv
messages. The processing of messages is handled generally in
same manner as described in RFC1157 [2], with differences
clarifications as described in the following sections.
SnmpMessageProcessingModel value for SNMPv1 is 0 (the value
SNMPv2c is 1).
5.2.1. Processing An Incoming
In RFC1157 [2], section 4.1, item (3) for an entity which receives
message, states that various parameters are passed to the '
authentication scheme.' The desired authentication scheme in
case is the SNMPv1 Community-Based Security Model, which will
called using the processIncomingMsg ASI. The parameters passed
this ASI are
- The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).
- The maxMessageSize, which should be the maximum size of
message that the receiving entity can generate (since there
no such value in the received message).
- The securityParameters, which consist of the community
and the message's source and destination transport domains
addresses
- The securityModel, which will be 1 (or 2 for SNMPv2c).
- The securityLevel, which will be noAuthNoPriv
- The wholeMsg and wholeMsgLength
The Community-Based Security Model will attempt to select a row
the snmpCommunityTable. This is done by performing a search
the snmpCommunityTable in lexicographic order. The first entry
which the following matching criteria are satisfied will be selected
- The community string is equal to the snmpCommunityName value
- If the snmpCommunityTransportTag is an empty string, it
ignored for the purpose of matching. If
snmpCommunityTransportTag is not an empty string,
transportDomain and transportAddress from which the message
received must match one of the entries in
snmpTargetAddrTable selected by the
Frye, et al. Standards Track [Page 26]
RFC 2576 Coexistence between SNMP versions March 2000
value. The snmpTargetAddrTMask object is used as described
section 5.3 when checking whether the transportDomain
transportAddress matches a entry in the snmpTargetAddrTable
If 