Request for Comments: 2576 CoSine Communications
Category: Standards Track D. Levi
Nortel Networks
S. Routhier
Integrated Systems Inc.
B. Wijnen
Lucent Technologies
March 2000
Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
The purpose of this document is to describe coexistence between
version 3 of the Internet-standard Network Management Framework,
(SNMPv3), version 2 of the Internet-standard Network Management
Framework (SNMPv2), and the original Internet-standard Network
Management Framework (SNMPv1). This document obsoletes RFC1908 [13]
and RFC2089 [14].
Table Of Contents
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
3 Translating Notifications Parameters ......................... 10
3.1 Translating SNMPv1 Notification Parameters to SNMPv2
Notification Parameters ................................... 12
3.2 Translating SNMPv2 Notification Parameters to SNMPv1
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 Security
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. Overview
The purpose of this document is to describe coexistence between
version 3 of the Internet-standard Network Management Framework,
termed the SNMP version 3 framework (SNMPv3), version 2 of the
Internet-standard Network Management Framework, termed the SNMP
version 2 framework (SNMPv2), and the original Internet-standard
Network Management Framework (SNMPv1).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [15].
There are four general aspects of coexistence described in this
document. Each of these is described in a separate section:
- Conversion of MIB documents between SMIv1 and SMIv2 formats is
documented in section 2.
- Mapping of notification parameters is documented in section 3.
- Approaches to coexistence between entities which support the
various versions of SNMP in a multi-lingual network is
documented in section 4. This section addresses the processing
of protocol operations in multi-lingual implementations, as
well as behaviour of proxy implementations.
- The SNMPv1 Message Processing Model and Community-Based
Security Model, which provides mechanisms for adapting SNMPv1
into the View-Based Access Control Model (VACM) [20], is
documented in section 5 (this section also addresses the
SNMPv2c Message Processing Model and Community-Based Security
Model).
1.1. SNMPv1
SNMPv1 is defined by these documents:
- STD 15, RFC1157 [2] which defines the Simple Network
Management Protocol (SNMPv1), the protocol used for network
access to managed objects.
- STD 16, RFC1155 [1] which defines the Structure of Management
Information (SMIv1), the mechanisms used for describing and
naming objects for the purpose of management.
- STD 16, RFC1212 [3] which defines a more concise description
mechanism, which is wholly consistent with the SMIv1.
- RFC1215 [4] which defines a convention for defining Traps for
use with the SMIv1.
Note that throughout this document, the term 'SMIv1' is used. This
term generally refers to the information presented in RFC1155, RFC
1212, and RFC1215.
1.2. SNMPv2
SNMPv2 is defined by these documents:
- STD 58, RFC2578 which defines Version 2 of the Structure of
Management Information (SMIv2) [7].
- STD 58, RFC2579 which defines common MIB "Textual Conventions"
[8].
- STD 58, RFC2580 which defines Conformance Statements and
requirements for defining agent and manager capabilities [9].
- RFC1905 which defines the Protocol Operations used in
processing [10].
- RFC1906 which defines the Transport Mappings used "on the
wire" [11].
- RFC1907 which defines the basic Management Information Base
for monitoring and controlling some basic common functions of
SNMP entities [12].
Note that SMIv2 as used throughout this document refers to the first
three documents listed above (RFCs 2578, 2579, and 2580).
The following document augments the definition of SNMPv2:
- RFC1901 [6] is an Experimental definition for using SNMPv2
PDUs within a community-based message wrapper. This is
referred to throughout this document as SNMPv2c.
1.3. SNMPv3
SNMPv3 is defined by these documents:
- RFC2571 which defines an Architecture for Describing SNMP
Management Frameworks [16].
- RFC2572 which defines Message Processing and Dispatching [17].
- RFC2573 which defines various SNMP Applications [18].
- RFC2574 which defines the User-based Security Model (USM),
providing for both Authenticated and Private (encrypted) SNMP
messages [19].
- RFC2575 which defines the View-based Access Control Model
(VACM), providing the ability to limit access to different MIB
objects on a per-user basis [20].
SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 and
the SMIv2 definitions of 2578 through 2580 described above.
1.4. SNMPv1 and SNMPv2 Access to MIB Data
In several places, this document refers to 'SNMPv1 Access to MIB
Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the part
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 is
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 generating
notifications. Note also that SNMPv1 access to MIB data will
actually never generate a readOnly error (a noSuchName error would
always occur in the situation where one would expect a readOnly
error).
SNMPv2 access to MIB data may generate SNMPv2 error-status values,
may generate exception codes, may use the Counter64 data type, and
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 to
implement all access to MIB data as SNMPv2 access to MIB data, and
perform the translations described herein for SNMPv1-based
transactions.
2. SMI and Management Information Mappings
The SMIv2 approach towards describing collections of managed objects
is nearly a proper superset of the approach defined in the SMIv1.
For example, both approaches use an adapted subset of ASN.1 (1988)
[11] as the basis for a formal descriptive notation. Indeed, one
might note that the SMIv2 approach largely codifies the existing
practice for defining MIB modules, based on extensive experience with
the SMIv1.
The following sections consider the three areas: MIB modules,
compliance statements, and capabilities statements.
2.1. MIB Modules
MIB modules defined using the SMIv1 may continue to be used with
protocol versions which use SNMPv2 PDUs. However, for the MIB
modules to conform to the SMIv2, the following changes SHALL be made:
2.1.1. Object Definitions
In general, conversion of a MIB module does not require the
deprecation of the objects contained therein. If the definition of
an object is truly inadequate for its intended purpose, the object
SHALL be deprecated or obsoleted, otherwise deprecation is not
required.
(1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of
RFC1155-SMI and RFC-1212.
(2) The MODULE-IDENTITY macro MUST be invoked immediately after any
IMPORTs statement.
(3) For any object with an integer-valued SYNTAX clause, in which
the corresponding INTEGER does not have a range restriction
(i.e., the INTEGER has neither a defined set of named-number
enumerations nor an assignment of lower- and upper-bounds on its
value), the object MUST have the value of its SYNTAX clause
changed to Integer32, or have an appropriate range specified.
(4) For any object with a SYNTAX clause value of Counter, the object
MUST have the value of its SYNTAX clause changed to Counter32.
(5) For any object with a SYNTAX clause value of Gauge, the object
MUST have the value of its SYNTAX clause changed to Gauge32, or
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 the
same as that of the ACCESS clause unless some other value makes
"protocol sense" as the maximal level of access for the object.
In particular, object types for which instances can be
explicitly created by a protocol set operation, SHALL have a
MAX-ACCESS clause of "read-create". If the value of the ACCESS
clause is "write-only", then the value of the MAX-ACCESS clause
MUST be "read-write", and the DESCRIPTION clause SHALL note that
reading this object will result in implementation-specific
results. Note that in SMIv1, the ACCESS clause specifies the
minimal required access, while in SMIv2, the MAX-ACCESS clause
specifies the maximum allowed access. This should be considered
when converting an ACCESS clause to a MAX-ACCESS clause.
(7) For all objects, if the value of the STATUS clause is
"mandatory" or "optional", the value MUST be replaced with
"current", "deprecated", or "obsolete" depending on the current
usage of such objects.
(8) For any object not containing a DESCRIPTION clause, the object
MUST have a DESCRIPTION clause defined.
(9) For any object corresponding to a conceptual row which does not
have an INDEX clause, the object MUST have either an INDEX
clause or an AUGMENTS clause defined.
(10) If any INDEX clause contains a reference to an object with a
syntax of NetworkAddress, then a new object MUST be created and
placed in this INDEX clause immediately preceding the object
whose syntax is NetworkAddress. This new object MUST have a
syntax of INTEGER, it MUST be not-accessible, and its value MUST
always be 1. This approach allows one to convert a MIB module
in SMIv1 format to one in SMIv2 format, and then use it with the
SNMPv1 protocol with no impact to existing SNMPv1 agents and
managers.
(11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST
be changed to IpAddress. Note that the use of NetworkAddress in
new MIB documents is strongly discouraged (in fact, new MIB
documents should be written using SMIv2, which does not define
NetworkAddress).
(12) For any object containing a DEFVAL clause with an OBJECT
IDENTIFIER value which is expressed as a collection of sub-
identifiers, the value MUST be changed to reference a single
ASN.1 identifier. This may require defining a series of new
administrative assignments (OBJECT IDENTIFIERS) in order to
define the single ASN.1 identifier.
(13) One or more OBJECT-GROUPS MUST be defined, and related objects
SHOULD be collected into appropriate groups. Note that SMIv2
requires all OBJECT-TYPEs to be a member of at least one
OBJECT-GROUP.
Other changes are desirable, but not necessary:
(1) Creation and deletion of conceptual rows is inconsistent using
the SMIv1. The SMIv2 corrects this. As such, if the MIB module
undergoes review early in its lifetime, and it contains
conceptual tables which allow creation and deletion of
conceptual rows, then the objects relating to those tables MAY
be deprecated and replaced with objects defined using the new
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 the
corresponding OCTET STRING does not have a size restriction
(i.e., the OCTET STRING has no assignment of lower- and upper-
bounds on its length), the bounds for the size of the object
SHOULD be defined.
(3) All textual conventions informally defined in the MIB module
SHOULD be redefined using the TEXTUAL-CONVENTION macro. Such a
change would not necessitate deprecating objects previously
defined using an informal textual convention.
(4) For any object which represents a measurement in some kind of
units, a UNITS clause SHOULD be added to the definition of that
object.
(5) For any conceptual row which is an extension of another
conceptual row, i.e., for which subordinate columnar objects
both exist and are identified via the same semantics as the
other conceptual row, an AUGMENTS clause SHOULD be used in place
of the INDEX clause for the object corresponding to the
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 were
immediately subordinate to a conceptual row, the value of the
STATUS clause of that object MUST be changed to "obsolete".
(2) For any conceptual row object that is not contained immediately
subordinate to a conceptual table, the value of the STATUS
clause of that object (and all subordinate objects) MUST be
changed to "obsolete".
2.1.2. Trap and Notification Definitions
If a MIB module is changed to conform to the SMIv2, then each
occurrence of the TRAP-TYPE macro MUST be changed to a corresponding
invocation of the NOTIFICATION-TYPE macro:
(1) The IMPORTS statement MUST NOT reference RFC-1215 [4], and MUST
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' or
'obsolete' may be used as needed.
(5) The value of an invocation of the NOTIFICATION-TYPE macro is an
OBJECT IDENTIFIER, not an INTEGER, and MUST be changed
accordingly. Specifically, if the value of the ENTERPRISE
clause is not 'snmp' then the value of the invocation SHALL be
the value of the ENTERPRISE clause extended with two sub-
identifiers, the first of which has the value 0, and the second
has the value of the invocation of the TRAP-TYPE. If the value
of the ENTERPRISE clause is 'snmp', then the value of the
invocation of the NOTIFICATION-TYPE macro SHALL be mapped in the
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 related
notifications MUST be collected into those groups. Note that
SMIv2 requires that all NOTIFICATION-TYPEs be a member of at
least one NOTIFICATION-GROUP.
2.2. Compliance Statements
For those information modules which are "standards track", a
corresponding invocation of the MODULE-COMPLIANCE macro and related
OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included within
the information module (or in a companion information module), and
any commentary text in the information module which relates to
compliance SHOULD be removed. Typically this editing can occur when
the information module undergoes review.
Note that a MODULE-COMPLIANCE statement is not required for a MIB
document that is not on the standards track (for example, an
enterprise MIB), though it may be useful in some circumstances to
define a MODULE-COMPLIANCE statement for such a MIB document.
2.3. Capabilities Statements
RFC1303 [5] uses the MODULE-CONFORMANCE macro to describe an agent's
capabilities with respect to one or more MIB modules. Converting
such a description for use with the SMIv2 requires these changes:
(1) The macro name AGENT-CAPABILITIES SHOULD be used instead of
MODULE-CONFORMANCE.
(2) The STATUS clause SHOULD be added, with a value of 'current'.
(3) All occurrences of the CREATION-REQUIRES clause MUST either be
omitted if appropriate, or be changed such that the semantics
are consistent with RFC2580 [9].
In order to ease coexistence, object groups defined in an SMIv1
compliant MIB module may be referenced by the INCLUDES clause of an
invocation of the AGENT-CAPABILITIES macro: upon encountering a
reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB
module, all leaf objects which are subordinate to the subtree and
have a STATUS clause value of mandatory are deemed to be INCLUDED.
(Note that this method is ambiguous when different revisions of an
SMIv1 MIB have different sets of mandatory objects under the same
subtree; in such cases, the only solution is to rewrite the MIB using
the SMIv2 in order to define the object groups unambiguously.)
3. Translating Notifications Parameters
This section describes how parameters used for generating
notifications are translated between the format used for SNMPv1
notification protocol operations and the format used for SNMPv2
notification protocol operations. The parameters used to generate a
notification are called 'notification parameters'. The format of
parameters used for SNMPv1 notification protocol operations is
refered to in this document as 'SNMPv1 notification parameters'. The
format of parameters used for SNMPv2 notification protocol operations
is refered to in this document as 'SNMPv2 notification parameters'.
The situations where notification parameters MUST be translated are:
- When an entity generates a set of notification parameters in a
particular format, and the configuration of the entity
indicates that the notification must be sent using an SNMP
message version that requires the other format for notification
parameters.
- When a proxy receives a notification that was sent using an
SNMP message version that requires one format of notification
parameters, and must forward the notification using an SNMP
message version that requires the other format of notification
parameters.
In addition, it MAY be desirable to translate notification parameters
in a notification receiver application in order to present
notifications to the end user in a consistent format.
Note that for the purposes of this section, the set of notification
parameters is independent of whether the notification is to be sent
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 first
variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU.
- An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in
the second variable-binding in an SNMPv2-Trap-PDU or
InformRequest-PDU.
- A list of variable-bindings (VarBindList). This refers to all
but the first two variable-bindings in an SNMPv2-Trap-PDU or
InformRequest-PDU.
3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification
Parameters
The following procedure describes how to translate SNMPv1
notification parameters into SNMPv2 notification parameters:
(1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the
SNMPv1 time-stamp parameter.
(2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)',
the SNMPv2 snmpTrapOID parameter SHALL be the concatentation of
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 SHALL
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 by
a proxy in order to forward a received trap, three additional
variable-bindings will be appended, if these three additional
variable-bindings do not already exist in the SNMPv1 variable-
bindings. The name portion of the first additional variable
binding SHALL contain snmpTrapAddress.0, and the value SHALL
contain the SNMPv1 agent-addr parameter. The name portion of
the second additional variable binding SHALL contain
snmpTrapCommunity.0, and the value SHALL contain the value of
the community-string field from the received SNMPv1 message
which contained the SNMPv1 Trap-PDU. The name portion of the
third additional variable binding SHALL contain
snmpTrapEnterprise.0 [12], and the value SHALL be the SNMPv1
enterprise parameter.
3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification
Parameters
The following procedure describes how to translate SNMPv2
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 standard
traps as defined in RFC1907 [12], then the SNMPv1 enterprise
parameter SHALL be set to the value of the variable-binding in
the SNMPv2 variable-bindings whose name is snmpTrapEnterprise.0
if that variable-binding exists. If it does not exist, the
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 standard
traps as defined in RFC1907 [12], then the SNMPv1 enterprise
parameter SHALL be determined from the SNMPv2 snmpTrapOID
parameter as follows:
- If the next-to-last sub-identifier of the snmpTrapOID is
zero, then the SNMPv1 enterprise SHALL be the SNMPv2
snmpTrapOID with the last 2 sub-identifiers removed,
otherwise
- If the next-to-last sub-identifier of the snmpTrapOID is
non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2
snmpTrapOID with the last sub-identifier removed.
(2) The SNMPv1 agent-addr parameter SHALL be determined based on the
situation in which the translation occurs.
- If the translation occurs within a notification originator
application, and the notification is to be sent over IP, the
SNMPv1 agent-addr parameter SHALL be set to the IP address of
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 proxy
must attempt to extract the original source of the notification
from the variable-bindings. If the SNMPv2 variable-bindings
contains a variable binding whose name is snmpTrapAddress.0,
the agent-addr parameter SHALL be set to the value of that
variable binding. Otherwise, the SNMPv1 agent-addr parameter
SHALL be set to 0.0.0.0.
(3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps
as defined in RFC1907 [12], the SNMPv1 generic-trap parameter
SHALL be set as follows:
snmpTrapOID.0 parameter generic-trap
=============================== ============
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 traps
as defined in RFC1907 [12], the SNMPv1 specific-trap parameter
SHALL be set to zero. Otherwise, the SNMPv1 specific-trap
parameter SHALL be set to the last sub-identifier of the SNMPv2
snmpTrapOID parameter.
(5) The SNMPv1 time-stamp parameter SHALL be taken directly from the
SNMPv2 sysUpTime parameter.
(6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-
bindings. Note, however, that if the SNMPv2 variable-bindings
contain any objects whose type is Counter64, the translation to
SNMPv1 notification parameters cannot be performed. In this
case, the notification cannot be encoded in an SNMPv1 packet
(and so the notification cannot be sent using SNMPv1, see
section 4.1.3 and section 4.2).
4. Approaches to Coexistence in a Multi-lingual Network
There are two basic approaches to coexistence in a multi-lingual
network, multi-lingual implementations and proxy implementations.
Multi-lingual implementations allow elements in a network to
communicate with each other using an SNMP version which both elements
support. This allows a multi-lingual implementation to communicate
with any mono-lingual implementation, regardless of the SNMP version
supported by the mono-lingual implementation.
Proxy implementations provide a mechanism for translating between
SNMP versions using a third party network element. This allows
network elements which support only a single, but different, SNMP
version to communicate with each other. Proxy implementations are
also useful for securing communications over an insecure link between
two locally secure networks.
4.1. Multi-lingual implementations
This approach requires an entity to support multiple SNMP message
versions. Typically this means supporting SNMPv1, SNMPv2c, and
SNMPv3 message versions. The behaviour of various types of SNMP
applications which support multiple message versions is described in
the following sections. This approach allows entities which support
multiple SNMP message versions to coexist with and communicate with
entities which support only a single SNMP message version.
4.1.1. Command Generator
A command generator must select an appropriate message version when
sending requests to another entity. One way to achieve this is to
consult a local database to select the appropriate message version.
In addition, a command generator MUST 'downgrade' GetBulk requests to
GetNext requests when selecting SNMPv1 as the message version for an
outgoing request. This is done by simply changing the operation type
to GetNext, ignoring any non-repeaters and max-repetitions values,
and setting error-status and error-index to zero.
4.1.2. Command Responder
A command responder must be able to deal with both SNMPv1 and SNMPv2
access to MIB data. There are three aspects to dealing with this. A
command responder must:
- Deal correctly with SNMPv2 access to MIB data that returns a
Counter64 value while processing an SNMPv1 message,
- Deal correctly with SNMPv2 access to MIB data that returns one
of the three exception values while processing an SNMPv1
message, and
- Map SNMPv2 error codes returned from SNMPv2 access to MIB data
into SNMPv1 error codes when processing an SNMPv1 message.
Note that SNMPv1 error codes SHOULD NOT be used without any change
when processing SNMPv2c or SNMPv3 messages, except in the case of
proxy forwarding. In the case of proxy forwarding, for backwards
compatibility, SNMPv1 error codes may be used without any change in a
forwarded SNMPv2c or SNMPv3 message.
The following sections describe the behaviour of a command responder
application which supports multiple SNMP message versions, and which
uses some combination of SNMPv1 and SNMPv2 access to MIB data.
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 are
compatible with SMIv1.
The impact on multi-lingual command responders is that they MUST NOT
ever return a variable binding containing a Counter64 value in a
response to a request that was received using the SNMPv1 message
version.
Multi-lingual command responders SHALL take the approach that object
instances whose type is Counter64 are implicitly excluded from view
when processing an SNMPv1 message. So:
- On receipt of an SNMPv1 GetRequest-PDU containing a variable
binding whose name field points to an object instance of type
Counter64, a GetResponsePDU SHALL be returned, with an error-
status of noSuchName and the error-index set to the variable
binding that caused this error.
- On an SNMPv1 GetNextRequest-PDU, any object instance which
contains a syntax of Counter64 SHALL be skipped, and the next
accessible object instance that does not have the syntax of
Counter64 SHALL be retrieved. If no such object instance
exists, then an error-status of noSuchName SHALL be returned,
and the error-index SHALL be set to the variable binding that
caused this error.
- Any SNMPv1 request which contains a variable binding with a
Counter64 value is ill-formed, so the foregoing rules do not
apply. If that error is detected, a response SHALL NOT be
returned, since it would contain a copy of the ill-formed
variable binding. Instead, the offending PDU SHALL be
discarded and the counter snmpInASNParseErrs SHALL be
incremented.
4.1.2.2. Mapping SNMPv2 Exceptions
SNMPv2 provides a feature called exceptions, which allow an SNMPv2
Response PDU to return as much management information as possible,
even when an error occurs. However, SNMPv1 does not support
exceptions, and so an SNMPv1 Response PDU cannot return any
management information, and can only return an error-status and
error-index value.
When an SNMPv1 request is received, a command responder MUST check
any variable bindings returned using SNMPv2 access to MIB data for
exception values, and convert these exception values into SNMPv1
error codes.
The type of exception that can be returned when accessing MIB data
and the action taken depends on the type of SNMP request.
- For a GetRequest, a noSuchObject or noSuchInstance exception
may be returned.
- For a GetNextRequest, an endOfMibView exception may be
returned.
- No exceptions will be returned for a SetRequest, and a
GetBulkRequest should only be received in an SNMPv2c or SNMPv3
message, so these request types may be ignored when mapping
exceptions.
Note that when a response contains multiple exceptions, it is an
implementation choice as to which variable binding the error-index
should reference.
4.1.2.2.1. Mapping noSuchObject and noSuchInstance
A noSuchObject or noSuchInstance exception generated by an SNMPv2
access to MIB data indicates that the requested object instance can
not be returned. The SNMPv1 error code for this condition is
noSuchName, and so the error-status field of the response PDU SHALL
be set to noSuchName. Also, the error-index field SHALL be set to
the index of the variable binding for which an exception occurred
(there may be more than one and it is an implementation decision as
to which is used), and the variable binding list from the original
request SHALL be returned with the response PDU.
4.1.2.2.2. Mapping endOfMibView
When an SNMPv2 access to MIB data returns a variable binding
containing an endOfMibView exception, it indicates that there are no
object instances available which lexicographically follow the object
in the request. In an SNMPv1 agent, this condition normally results
in a noSuchName error, and so the error-status field of the response
PDU SHALL be set to noSuchName. Also, the error-index field SHALL be
set to the index of the variable binding for which an exception
occurred (there may be more than one and it is an implementation
decision as to which is used), and the variable binding list from the
original request SHALL be returned with the response PDU.
4.1.2.3. Processing An SNMPv1 GetRequest
When processing an SNMPv1 GetRequest, the following procedures MUST
be followed when using an SNMPv2 access to MIB data.
When such an access to MIB data returns response data using SNMPv2
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-status
using the table in section 4.3, "Error Status Mappings".
- The error-index SHALL be set to the position (in the original
request) of the variable binding that caused the error-status.
- The variable binding list of the response PDU SHALL be made
exactly the same as the variable binding list that was received
in the original request.
(2) If the error-status is noError, the variable bindings SHALL be
checked for any SNMPv2 exception (noSuchObject or
noSuchInstance) or an SNMPv2 syntax that is unknown to SNMPv1
(Counter64). If there are any such variable bindings, one of
those variable bindings SHALL be selected (it is an
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 variable
binding list of the original request) of the selected variable
binding, and
- The variable binding list of the response PDU SHALL be exactly
the same as the variable binding list that was received in the
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, and
- The variable binding list of the response SHALL be composed
from the data as it is returned by the access to MIB data.
4.1.2.4. Processing An SNMPv1 GetNextRequest
When processing an SNMPv1 GetNextRequest, the following procedures
MUST be followed when an SNMPv2 access to MIB data is called as part
of processing the request. There may be repetitive accesses to MIB
data to try to find the first object which lexicographically follows
each of the objects in the request. This is implementation specific.
These procedures are followed only for data returned when using
SNMPv2 access to MIB data. Data returned using SNMPv1 access to MIB
data may be treated in the normal manner for an SNMPv1 request.
First, if the access to MIB data returns an error-status of anything
other than noError:
(1) The error status SHALL be translated to an SNMPv1 error-status
using the table in section 4.3, "Error Status Mappings".
(2) The error-index SHALL be set to the position (in the original
request) of the variable binding that caused the error-status.
(3) The variable binding list of the response PDU SHALL be exactly
the same as the variable binding list that was received in the
original request.
Otherwise, if the access to MIB data returns an error-status of
noError:
(1) Any variable bindings containing an SNMPv2 syntax of Counter64
SHALL be considered to be not in view, and MIB data SHALL be
accessed as many times as is required until either a value other
than Counter64 is returned, or an error occurs.
(2) If there is any variable binding that contains an SNMPv2
exception endOfMibView (there may be more than one, it is an
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 variable
binding list of the original request) of the variable binding
that returned such an SNMPv2 exception, and
- The variable binding list of the response PDU SHALL be exactly
the same as the variable binding list that was received in the
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, and
- The variable binding list of the response SHALL be composed
from the data as it is returned by the access to MIB data.
4.1.2.5. Processing An SNMPv1 SetRequest
When processing an SNMPv1 SetRequest, the following procedures MUST
be followed when calling SNMPv2 MIB access routines.
When such MIB access routines return response data using SNMPv2
syntax and error-status values, and the error-status is anything
other than noError, then:
- The error status SHALL be translated to an SNMPv1 error-status
using the table in section 4.3, "Error Status Mappings".
- The error-index SHALL be set to the position (in the original
request) of the variable binding that caused the error-status.
- The variable binding list of the response PDU SHALL be made
exactly the same as the variable binding list that was received
in the original request.
4.1.3. Notification Originator
A notification originator must be able to translate between SNMPv1
notifications parameters and SNMPv2 notification parameters in order
to send a notification using a particular SNMP message version. If a
notification is generated using SNMPv1 notification parameters, and
configuration information specifies that notifications be sent using
SNMPv2c or SNMPv3, the notification parameters must be translated to
SNMPv2 notification parameters. Likewise, if a notification is
generated using SNMPv2 notification parameters, and configuration
information specifies that notifications be sent using SNMPv1, the
notification parameters must be translated to SNMPv1 notification
parameters. In this case, if the notification cannot be translated
(due to the presence of a Counter64 type), it will not be sent using
SNMPv1.
When a notification originator generates a notification, using
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 the
value of snmpNotifyType is trap(1) or inform(2).
Note also that access control and notification filtering are
performed in the usual manner for notifications, regardless of the
SNMP message version to be used when sending a notification. The
parameters for performing access control are found in the usual
manner (i.e., from inspecting the SNMP-TARGET-MIB and SNMP-
NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in
order to perform the access check specified in [18], section 3.3,
bullet (3), the notification originator may need to generate a value
for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of
this document. If the SNMPv1 notification parameters being used were
previously translated from a set of SNMPv2 notification parameters,
this value may already be known, in which case it need not be
generated.
4.1.4. Notification Receiver
There are no special requirements of a notification receiver.
However, an implementation may find it useful to allow a higher level
application to request whether notifications should be delivered to a
higher level application using SNMPv1 notification parameter or
SNMPv2 notification parameters. The notification receiver would then
translate notification parameters when required in order to present a
notification using the desired set of parameters.
4.2. Proxy Implementations
A proxy implementation may be used to enable communication between
entities which support different SNMP message versions. This is
accomplished in a proxy forwarder application by performing
translations on PDUs. These translations depend on the PDU type, the
SNMP version of the packet containing a received PDU, and the SNMP
version to be used to forward a received PDU. The following sections
describe these translations. In all cases other than those described
below, the proxy SHALL forward a received PDU without change, subject
to size constraints as defined in section 5.3 (Community MIB) of this
document. Note that in the following sections, the 'Upstream
Version' refers to the version used between the command generator and
the proxy, and the 'Downstream Version' refers to the version used
between the proxy and the command responder, regardless of the PDU
type or direction.
4.2.1. Upstream Version Greater Than Downstream Version
- If a GetBulkRequest-PDU is received and must be forwarded using
the SNMPv1 message version, the proxy forwarder SHALL set the
non-repeaters and max-repetitions fields to 0, and SHALL set the
tag of the PDU to GetNextRequest-PDU.
- If a GetResponse-PDU is received whose error-status field has a
value of 'tooBig', the message will be forwarded using the SNMPv2c
or SNMPv3 message version, and the original request received by
the proxy was not a GetBulkRequest-PDU, the proxy forwarder SHALL
remove the contents of the variable-bindings field before
forwarding the response.
- If a GetResponse-PDU is received whose error-status field has a
value of 'tooBig,' and the message will be forwarded using the
SNMPv2c or SNMPv3 message version, and the original request
received by the proxy was a GetBulkRequest-PDU, the proxy
forwarder SHALL re-send the forwarded request (which would have
been altered to be a GetNextRequest-PDU) with all but the first
variable-binding removed. The proxy forwarder SHALL only re-send
such a request a single time. If the resulting GetResponse-PDU
also contains an error-status field with a value of 'tooBig,' then
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 request
only contained a single variable-binding, the proxy may skip re-
sending the request and simply remove the variable-bindings and
change the error-status to 'noError.'
- If a Trap-PDU is received, and will be forwarded using the SNMPv2c
or SNMPv3 message version, the proxy SHALL apply the translation
rules described in section 3, and SHALL forward the notification
as an SNMPv2-Trap-PDU.
Note that when an SNMPv1 agent generates a message containing a
Trap-PDU which is subsequently forwarded by one or more proxy
forwarders using SNMP versions other than SNMPv1, the community
string and agent-addr fields from the original message generated
by the SNMPv1 agent will be preserved through the use of the
snmpTrapAddress and snmpTrapCommunity nobjects.
4.2.2. Upstream Version Less Than Downstream Version