Internet Draft Coexistence between SNMP versions 10 Feb 1999
INTERNET-DRAFT Rob Frye
MCI Communications Corp.
David B. Levi
SNMP Research, Inc.
Shawn A. Routhier
Integrated Systems Inc.
Bert Wijnen
IBM T.J. Watson Research
10 Feb 1999
Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework
<draft-ietf-snmpv3-coex-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
SNMPv3 Working Group Expires August 1999 [Page 1]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
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 RFC 1908 [13]
and RFC2089 [14].
SNMPv3 Working Group Expires August 1999 [Page 2]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
Table Of Contents
1 Overview ..................................................... 4
1.1 SNMPv1 ..................................................... 4
1.2 SNMPv2 ..................................................... 5
1.3 SNMPv3 ..................................................... 6
1.4 SNMPv1 and SNMPv2 MIB Instrumentation ...................... 6
2 SMI and Management Information Mappings ...................... 8
2.1 Object Definitions ......................................... 8
2.2 Trap and Notification Definitions .......................... 10
2.3 Compliance Statements ...................................... 11
2.4 Capabilities Statements .................................... 11
3 Translating Notifications Parameters ......................... 13
3.1 Translating SNMPv1 Notification Parameters to SNMPv2 No-
tification Parameters ..................................... 14
3.2 Translating SNMPv2 Notification Parameters to SNMPv1 No-
tification Parameters ..................................... 15
4 Approaches to Coexistence in a Multi-lingual Network ......... 18
4.1 Multi-lingual implementations .............................. 18
4.1.1 Command Generator ........................................ 18
4.1.2 Command Responder ........................................ 18
4.1.2.1 Handling Counter64 ..................................... 19
4.1.2.2 Mapping SNMPv2 Exceptions .............................. 20
4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 20
4.1.2.2.2 Mapping endOfMibView ................................. 21
4.1.2.3 Processing An SNMPv1 GetRequest ........................ 21
4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 22
4.1.3 Notification Originator .................................. 23
4.1.4 Notification Receiver .................................... 24
4.2 Proxy Implementations ...................................... 24
4.3 Error Status Mappings ...................................... 26
5 Message Processing Models and Security Models ................ 27
5.1 Mappings ................................................... 27
5.2 The SNMPv1 Message Processing Model ........................ 27
5.2.1 Processing An Incoming Request ........................... 28
5.2.2 Generating An Outgoing Response .......................... 30
5.2.3 Generating An Outgoing Notification ...................... 30
5.3 The SNMP Community MIB Module .............................. 31
6 Intellectual Property ........................................ 41
7 Acknowledgments .............................................. 42
8 Security Considerations ...................................... 43
9 References ................................................... 44
10 Editor's Address ............................................ 46
A. Full Copyright Statement .................................... 47
SNMPv3 Working Group Expires August 1999 [Page 3]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
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 16, RFC 1155 [1] which defines the Structure of Management
Information (SMIv1), the mechanisms used for describing and
naming objects for the purpose of management.
- STD 16, RFC 1212 [3] which defines a more concise description
mechanism, which is wholly consistent with the SMIv1.
SNMPv3 Working Group Expires August 1999 [Page 4]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
- STD 15, RFC 1157 [2] which defines the Simple Network
Management Protocol (SNMPv1), the protocol used for network
access to managed objects.
- RFC 1215 [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 RFC 1155, RFC
1212, and RFC 1215.
1.2. SNMPv2
SNMPv2 is defined by these documents:
- RFC 1902 which defines Version 2 of the Structure of
Management Information (SMIv2) [7].
- RFC 1903 which defines common MIB "Textual Conventions" [8].
- RFC 1904 which defines Conformance Statements and requirements
for defining agent and manager capabilities [9].
- RFC 1905 which defines the Protocol Operations used in
processing [10].
- RFC 1906 which defines the Transport Mappings used "on the
wire" [11].
- RFC 1907 which defines the basic Management Information Base
upon which other MIBs can be built [12].
Note that SMIv2 as used throughout this document refers to the first
three documents listed above (RFCs 1902, 1903, and 1904).
The following document augments the definition of SNMPv2:
- RFC 1901 [6] is an Experimental definition for using SNMPv2
PDUs within a community-based message wrapper. This is
referred to throughout this document as SNMPv2c.
SNMPv3 Working Group Expires August 1999 [Page 5]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
1.3. SNMPv3
SNMPv3 is defined by these documents:
- RFC 2271 which defines an Architecture for Describing SNMP
Management Frameworks [16].
- RFC 2272 which defines Message Processing and Dispatching
[17].
- RFC 2273 which defines various SNMP Applications [18].
- RFC 2274 which defines the User-based Security Model (USM),
providing for both Authenticated and Private (encrypted) SNMP
messages [19].
- RFC 2275 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 1902 through 1907
described above.
1.4. SNMPv1 and SNMPv2 MIB Instrumentation
In several places, this document refers to 'SNMPv1 MIB
Instrumentation' and 'SNMPv2 MIB Instrumentation'. These terms refer
to the part of an SNMP agent which actually implements MIB objects,
and which actually initiates generation of notifications.
Differences between the two types of MIB instrumentation 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 MIB instrumentation will 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 MIB instrumentation will
actually never generate a readOnly error (a noSuchName error would
SNMPv3 Working Group Expires August 1999 [Page 6]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
always occur in the situation where one would expect a readOnly
error).
SNMPv2 MIB instrumentation will generate SNMPv2 error-status values,
will generate exception codes, will use the Counter64 data type, and
will provide SNMPv2 format parameters for generating notifications.
Note that SNMPv2 MIB instrumentation will never generate readOnly,
noSuchName, or badValue errors.
Note that a particular multi-lingual implementation may choose to
implement all MIB instrumentation as SNMPv2 MIB instrumentation.
SNMPv3 Working Group Expires August 1999 [Page 7]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
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.
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. Object Definitions
In general, conversion of a MIB module does not require the
deprecation of the objects contained therein. If the semantics of an
object truly changes, the object SHALL be deprecated, 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.
(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.
(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
SNMPv3 Working Group Expires August 1999 [Page 8]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
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.
(7) For all objects, if the value of the STATUS clause is "mandatory",
the value MUST be replaced with "current".
(8) For all objects, if the value of the STATUS clause is "optional",
the value MUST be replaced with "obsolete".
(9) For any object not containing a DESCRIPTION clause, the object MUST
have a DESCRIPTION clause defined.
(10) 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.
(11) For any object with an INDEX clause that references an object with
a syntax of NetworkAddress, the value of the STATUS clause of both
objects MUST be changed to "obsolete".
(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 objects in order to define the
single ASN.1 identifier.
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 new approach can
be found in section 7 of RFC1902 [7], and the RowStatus and
StorageType TEXTUAL-CONVENTIONs are described in section 2 of
RFC1903 [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.
SNMPv3 Working Group Expires August 1999 [Page 9]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
(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.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) The STATUS clause MUST be added, with a value of 'current'.
(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'
SNMPv3 Working Group Expires August 1999 [Page 10]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
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.
(6) The DESCRIPTION clause MUST be added, if not already present.
(7) One or more NOTIFICATION-GROUPs SHOULD be defined, and related
notifications SHOULD be collected into those groups.
2.3. Compliance Statements
For those information modules which are "standard", a corresponding
invocation of the MODULE-COMPLIANCE macro and related OBJECT-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.
2.4. Capabilities Statements
In the SMIv1, 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 SHOULD either be
omitted if appropriate, or be changed such that the semantics are
consistent with RFC1904 [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
SNMPv3 Working Group Expires August 1999 [Page 11]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
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.)
SNMPv3 Working Group Expires August 1999 [Page 12]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
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 SMI version used to define a notification will usually determine
which type of notification parameters are provided by MIB
instrumentation when a notification is generated.
The situations where notification parameters MUST be translated are:
- When MIB instrumentation in 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).
SNMPv3 Working Group Expires August 1999 [Page 13]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
- 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.
SNMPv3 Working Group Expires August 1999 [Page 14]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
(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 variable binding SHALL contain
snmpTrapAddress.0, and the value SHALL contain the SNMPv1 agent-
addr parameter. The name portion of the second 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 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].
SNMPv3 Working Group Expires August 1999 [Page 15]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
- If the SNMPv2 snmpTrapOID parameter is not one of the standard
traps as defined in RFC1907 [12], then the SNMPv1 enterprise
parameter SHALL be set to the SNMPv2 snmpTrapOID parameter as
follows:
- If the next-to-last sub-identifier of the snmpTrapOID is
zero, then the SMIv1 enterprise SHALL be the SMIv2
snmpTrapOID with the last 2 sub-identifiers removed,
otherwise
- If the next-to-last sub-identifier of the snmpTrapOID is
non-zero, then the SMIv1 enterprise SHALL be the SMIv2
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 determine the original source of the
notification. 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, 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.
SNMPv3 Working Group Expires August 1999 [Page 16]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
(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
with the following exceptions:
- Any variable-binding whose type is Counter64 which exists in
the SNMPv2 variable-bindings SHALL be removed.
SNMPv3 Working Group Expires August 1999 [Page 17]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
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 should 'downgrade' GetBulk requests
to GetNext requests when selecting SNMPv1 as the message version for
an outgoing request.
4.1.2. Command Responder
A command responder must be able to deal with MIB instrumentation
that is written using both the SNMPv1 and SNMPv2. There are three
aspects to dealing with this. A command responder must:
SNMPv3 Working Group Expires August 1999 [Page 18]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
- Deal correctly with SNMPv2 MIB instrumentation that returns a
Counter64 value while processing an SNMPv1 message,
- Deal correctly with SNMPv2 MIB instrumentation that returns
one of the three exception values while processing an SNMPv1
message, and
- Map SNMPv2 error codes returned from SNMPv2 MIB
instrumentation into SNMPv1 error code when processing an
SNMPv1 message.
Note that SNMPv1 error codes can be used without any change when
processing SNMPv2c or SNMPv3 messages.
The following sections describe the behaviour of a command responder
application which supports multiple SNMP message versions, and which
has access to some combination of SNMPv1 and SNMPv2 MIB
instrumentation.
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 an SNMPv1 GET request, an error-status of noSuchName SHALL
be returned, and the error-index SHALL be set to the variable
binding that caused this error.
- On an SNMPv1 GetNext request, any object instance which
contains a syntax of Counter64 shall be skipped, and the next
object instance that follows the one with a syntax of
Counter64 SHALL be fetched. This step may need to be repeated
several times in order to find an object whose syntax is not
Counter64.
SNMPv3 Working Group Expires August 1999 [Page 19]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
- Any SET request that has a variable binding with a Counter64
value must have come from a SNMPv2 manager, and so it should
not cause a problem. However, if an object with SYNTAX of
Counter64 is received in an SNMPv1 SET packet, it SHALL result
in an ASN.1 parse error since Counter64 is not valid in the
SNMPv1 protocol. When an ASN.1 parse error occurs, the counter
snmpInASNParseErrs SHALL be incremented and no response is
returned.
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 from SNMPv2 MIB instrumentation for
exception values, and convert these exception values into SNMPv1
error codes.
The type of exception that can be returned from MIB instrumentation
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.
4.1.2.2.1. Mapping noSuchObject and noSuchInstance
A noSuchObject or noSuchInstance exception generated by SNMPv2 MIB
instrumentation 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
SNMPv3 Working Group Expires August 1999 [Page 20]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
the variable binding for which an exception occurred, and the
variable binding list from the original request SHALL be returned
with the response PDU.
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.2. Mapping endOfMibView
When SNMPv2 MIB instrumentation 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,
and the variable binding list from the original request SHALL be
returned with the response PDU.
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.3. Processing An SNMPv1 GetRequest
When processing an SNMPv1 GetRequest, the following procedures MUST
be followed when calling SNMPv2 MIB instrumentation.
When such MIB instrumentation 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.
SNMPv3 Working Group Expires August 1999 [Page 21]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
(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 MIB instrumentation.
4.1.2.4. Processing An SNMPv1 GetNextRequest
When processing an SNMPv1 GetNextRequest, the following procedures
MUST be followed when SNMPv2 MIB instrumentation is called as part of
processing the request. There may be repetitive calls to (possibly
different pieces of) MIB instrumentation 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 from SNMPv2 MIB instrumentation.
Data returned from SNMPv1 MIB instrumentation may be treated in the
normal manner for an SNMPv1 request.
First, if the MIB instrumentation 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".
SNMPv3 Working Group Expires August 1999 [Page 22]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
(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 MIB instrumentation 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 the MIB instrumentation
SHALL be called as often 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 MIB instrumentation.
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
MIB instrumentation presents a notification using SNMPv1 notification
parameters, and configuration information specifies that
SNMPv3 Working Group Expires August 1999 [Page 23]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
notifications be sent using SNMPv2c or SNMPv3, the notification
parameters must be translated to SNMPv2 notification parameters.
Likewise, if MIB instrumentation presents a notification using SNMPv2
notification parameters, and configuration information specifies that
notifications be sent using SNMPv1, the notification parameters must
be translated to SNMPv1 notification parameters.
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 a PDU in the following situations:
SNMPv3 Working Group Expires August 1999 [Page 24]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
- 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', and the message will be forwarded using
the SNMPv2c or SNMPv3 message version, the proxy forwarder
SHALL remove the contents of the variable-bindings field
before forwarding the response.
- If a GetResponse-PDU is received which contains variable-
bindings of type Counter64 or which contain an SNMPv2
exception code, and the message would be forwarded using the
SNMPv1 message version, the proxy MUST generate an alternate
response PDU consisting of the request-id and variable
bindings from the original SNMPv1 request, containing a
noSuchName error-status value, and containing an error-index
value indicating the position of the variable-binding
containing the Counter64 type or exception code.
- 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 using the mappings in section 4.3.
- 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.
- If an SNMPv2-Trap-PDU is received, and will be forwarded using
the SNMPv1 message version, the proxy SHALL apply the
translation rules described in section 3, and SHALL forward
the notification as a Trap-PDU.
- If an InformRequest-PDU is received, any configuration
information indicating that it would be forwarded using the
SNMPv1 message version SHALL be ignored. An InformRequest-PDU
can only be forwarded using the SNMPv2c or SNMPv3 message
version.
- In all other cases, the proxy SHALL forward a received PDU
without change.
SNMPv3 Working Group Expires August 1999 [Page 25]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
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 objects.
4.3. Error Status Mappings
The following tables shows the mappings of SNMPv1 error-status values
into SNMPv2 error-status values, and the mappings of SNMPv2 error-
status values into SNMPv1 error-status values.
SNMPv1 error-status SNMPv2 error-status
=================== ===================
noError noError
tooBig tooBig
noSuchName noSuchName
badValue badValue
genErr genErr
SNMPv2 error-status SNMPv1 error-status
=================== ===================
noError noError
tooBig tooBig
genErr genErr
wrongValue badValue
wrongEncoding badValue
wrongType badValue
wrongLength badValue
inconsistentValue badValue
noAccess noSuchName
notWritable noSuchName
noCreation noSuchName
inconsistentName noSuchName
resourceUnavailable genErr
commitFailed genErr
undoFailed genErr
authorizationError noSuchName
SNMPv3 Working Group Expires August 1999 [Page 26]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
5. Message Processing Models and Security Models
In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture,
the following models are defined in this document:
- The SNMPv1 Message Processing Model
- The SNMPv1 Community-Based Security Model
The following models are also described in this document:
- The SNMPv2c Message Processing Model
- The SNMPv2c Community-Based Security Model
In most respects, the SNMPv1 Message Processing Model and the
SNMPv2c Message Processing Model are identical, and so these
are not discussed independently in this document. Differences
between the two models are described as required.
Similarly, the SNMPv1 Community-Based Security Model and the
SNMPv2c Community-Based Security Model are nearly identical,
and so are not discussed independently. Differences between
these two models are also described as required.
5.1. Mappings
The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model
require mappings between parameters used in SNMPv1 (and SNMPv2c)
messages, and the version independent parameters used in the SNMP
architecture [16]. The parameters which MUST be mapped consist of the
SNMPv1 (and SNMPv2c) community name, and the SNMP securityName and
contextEngineID/contextName pair. A MIB module (the SNMP-COMMUNITY-MIB)
is provided in this document in order to perform these mappings. This
MIB provides mappings in both directions, that is, a community name may
be mapped to a securityName, contextEngineID, and contextName, or the
combination of securityName, contextEngineID, and contextName may be
mapped to a community name.
5.2. The SNMPv1 Message Processing Model
The SNMPv1 Message Processing Model handles processing of SNMPv1
messages. The processing of messages is handled generally in the
same manner as described in RFC1157 [2], with differences and
clarifications as described in the following sections. The
SNMPv3 Working Group Expires August 1999 [Page 27]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for
SNMPv2c is 1).
5.2.1. Processing An Incoming Request
In RFC1157 [2], section 4.1, item (3) for an entity which receives a
message, states that various parameters are passed to the 'desired
authentication scheme.' The desired authentication scheme in this
case is the SNMPv1 Community-Based Security Model, which will be
called using the processIncomingMsg ASI. The parameters passed to
this ASI are:
- The messageProcessingModel, which will be 0 (or 1 for
SNMPv2c).
- The maxMessageSize, which should be the maximum size of a
message that the receiving entity can generate (since there is
no such value in the received message).
- The securityParameters, which consist of the community string
and the message's source and destination transport 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 in
the snmpCommunityTable. This is done by performing a search through
the snmpCommunityTable in lexicographic order. The first entry for
which the following matching criteria are satisfied will be selected:
- The community string is equal to the snmpCommunityName value.
- If the snmpCommunityTransportTag is not an empty string, the
transportDomain and transportAddress from which the message
was received must match one of the entries in the
snmpTargetAddrTable selected by the snmpCommunityTransportTag
value. If the snmpCommunityTransportTag is an empty string,
it is ignored for the purpose of matching.
If no such entry can be found, an authentication failure occurs as
described in RFC1157 [2].
SNMPv3 Working Group Expires August 1999 [Page 28]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
The parameters returned from the Community-Based Security Model are:
- The securityEngineID, which will always be the local value of
snmpEngineID.0.
- The securityName.
- The scopedPDU. Note that this parameter will actually consist
of three values, the contextSnmpEngineID, the contextName, and
the PDU. These must be separate values, since the first two
do not actually appear in the message.
- The maxSizeResponseScopedPDU.
- The securityStateReference.
The appropriate SNMP application will then be called (depending on
the value of the contextEngineID and the request type in the PDU)
using the processPdu ASI. The parameters passed to this ASI are:
- The messageProcessingModel, which will be 0 (or 1 for
SNMPv2c).
- The securityModel, which will be 1 (or 2 for SNMPv2c).
- The securityName, which was returned from the call to
processIncomingMsg.
- The securityLevel, which is noAuthNoPriv.
- The contextEngineID, which was returned as part of the
ScopedPDU from the call to processIncomingMsg.
- The contextName, which was returned as part of the ScopedPDU
from the call to processIncomingMsg.
- The pduVersion, which should indicate an SNMPv1 version PDU
(if the message version was SNMPv2c, this would be an SNMPv2
version PDU).
- The PDU, which was returned as part of the ScopedPDU from the
call to processIncomingMsg.
- The maxSizeResponseScopedPDU which was returned from the call
to processIncomingMsg.
SNMPv3 Working Group Expires August 1999 [Page 29]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
- The stateReference which was returned from the call to
processIncomingMsg.
The SNMP application should process the request as described
previously in this document. Note that access control is applied by
an SNMPv3 command responder application as usual. The parameters as
passed to the processPdu ASI will be used in calls to the
isAccessAllowed ASI.
5.2.2. Generating An Outgoing Response
There is no special processing required for generating an outgoing
response. However, the community string used in an outgoing response
must be the same as the community string from the original request.
The original community string MUST be present in the stateReference
information of the original request.
5.2.3. Generating An Outgoing Notification
In a multi-lingual SNMP entity, the parameters used for generating
notifications will be obtained by examining the SNMP-TARGET-MIB and
SNMP-NOTIFICATION-MIB. These parameters will be passed to the SNMPv1
Message Processing Model using the sendPdu ASI. The SNMPv1 Message
Processing Model will attempt to locate an appropriate community
string in the snmpCommunityTable based on the parameters passed to
the sendPdu ASI. This is done by performing a search through the
snmpCommunityTable in lexicographic order. The first entry for which
the following matching criteria are satisfied will be selected:
- The securityName must be equal to the
snmpCommunitySecurityName value.
- The contextEngineID must be equal to the
snmpCommunityContextEngineID value.
- The contextName must be equal to the snmpCommunityContextName
value.
- If the snmpCommunityTransportTag is not an empty string, the
transportDomain and transportAddress must match one of the
entries in the snmpTargetAddrTable selected by the
snmpCommunityTransportTag value. If the
snmpCommunityTransportTag is an empty string, it is ignored
SNMPv3 Working Group Expires August 1999 [Page 30]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
for the purpose of matching.
If no such entry can be found, the notification is not sent.
Otherwise, the community string used in the outgoing notification
will be the value of the snmpCommunityName column of the selected
row.
5.3. The SNMP Community MIB Module
The SNMP-COMMUNITY-MIB contains objects for mapping between community
strings and version-independent SNMP message parameters. In
addition, this MIB provides a mechanism for performing source address
validation on incoming requests, and for selecting community strings
based on target addresses for outgoing notifications. These two
features are accomplished by providing a tag in the
snmpCommunityTable which selects sets of entries in the
snmpTargetAddrTable [18]. In addition, the SNMP-COMMUNITY-MIB
augments the snmpTargetAddrTable with a transport address mask value
and a maximum message size value. These values are used only where
explicitly stated. In cases where the snmpTargetAddrTable is used
without mention of these augmenting values, the augmenting values
should be ignored.
The mask value, snmpTargetAddrTMask, allows selected entries in the
snmpTargetAddrTable to specify multiple addresses (rather than just a
single address per entry). This would typically be used to specify a
subnet in an snmpTargetAddrTable rather than just a single address.
The mask value is used to select which bits of a transport address
must match bits of the corresponding instance of
snmpTargetAddrTAddress, in order for the transport address to match a
particular entry in the snmpTargetAddrTable. The value of an
instance of snmpTargetAddrTMask must always be an OCTET STRING whose
length is either zero or the same as that of the corresponding
instance of snmpTargetAddrTAddress.
When checking whether a transport address matches an entry in the
snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero-
length OCTET STRING, the mask value is ignored, and the value of
snmpTargetAddrTAddress must exactly match a transport address.
Otherwise, each bit of each octet in the snmpTargetAddrTMask value
corresponds to the same bit of the same octet in the
snmpTargetAddrTAddress value. For bits that are set in the
snmpTargetAddrTMask value (i.e. bits equal to 1), the corresponding
bits in the snmpTargetAddrTAddress value must match the bits in a
SNMPv3 Working Group Expires August 1999 [Page 31]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
transport address. If all such bits match, the transport address is
matched by that snmpTargetAddrTable entry. Otherwise, the transport
address is not matched.
The maximum message size value, snmpTargetAddrMMS, is used to
determine the maximum message size acceptable to another SNMP entity
when the value cannot be determined from the protocol.
SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN
IMPORTS
IpAddress
FROM RFC1155-SMI
MODULE-IDENTITY,
OBJECT-TYPE,
Integer32,
FROM SNMPv2-SMI
RowStatus,
TestAndIncr,
StorageType
FROM SNMPv2-TC
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
SnmpTagValue
FROM SNMP-TARGET-MIB
MODULE-COMPLIANCE,
OBJECT-GROUP
FROM SNMPv2-CONF;
snmpCommunityMIB MODULE-IDENTITY
LAST-UPDATED "9805110000Z" -- 11 May 1998, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@tis.com
Subscribe: majordomo@tis.com
In msg body: subscribe snmpv3
Chair: Russ Mundy
Trusted Information Systems
postal: 3060 Washington Rd
Glenwood MD 21738
USA
email: mundy@tis.com
phone: +1-301-854-6889
Co-editor: Rob Frye
MCI Communications Corp.
Postal: 2100 Reston Parkway, Suite 600
SNMPv3 Working Group Expires August 1999 [Page 32]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
Reston, VA 20191
USA
E-mail: Rob.Frye@mci.com
Phone: +1 703 715 7225
Co-editor: David B. Levi
SNMP Research, Inc.
Postal: 3001 Kimberlin Heights Road
Knoxville, TN 37920-9716
E-mail: levi@snmp.com
Phone: +1 423 573 1434
Co-editor: Shawn A. Routhier
Integrated Systems Inc.
Postal: 333 North Ave 4th Floor
Wakefield, MA 01880
E-mail: sar@epilogue.com
Phone: +1 781 245 0804
Co-editor: Bert Wijnen
IBM T. J. Watson Research
postal: Schagen 33
3461 GL Linschoten
Netherlands
email: wijnen@vnet.ibm.com
phone: +31-348-432-794
"
DESCRIPTION
"This MIB module defines objects to help support coexistence
between SNMPv1, SNMPv2, and SNMPv3."
::= { snmpModules 18 }
-- Administrative assignments ****************************************
snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 }
snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 }
--
-- The snmpCommunityTable contains a database of community strings.
-- This table provides mappings between community strings, and the
-- parameters required for View-based Access Control.
--
snmpCommunityTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpCommunityEntry
MAX-ACCESS not-accessible
SNMPv3 Working Group Expires August 1999 [Page 33]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
STATUS current
DESCRIPTION
"The table of community strings configured in the SNMP
engine's Local Configuration Datastore (LCD)."
::= { snmpCommunityMIBObjects 1 }
snmpCommunityEntry OBJECT-TYPE
SYNTAX SnmpCommunityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular community string."
INDEX { IMPLIED snmpCommunityIndex }
::= { snmpCommunityTable 1 }
SnmpCommunityEntry ::= SEQUENCE {
snmpCommunityIndex SnmpAdminString,
snmpCommunityName OCTET STRING,
snmpCommunitySecurityName SnmpAdminString,
snmpCommunityContextEngineID SnmpEngineID,
snmpCommunityContextName SnmpAdminString,
snmpCommunityTransportTag SnmpTagValue,
snmpCommunityStorageType StorageType,
snmpCommunityStatus RowStatus
}
snmpCommunityIndex OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique index value of a row in this table."
::= { snmpCommunityEntry 1 }
snmpCommunityName OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1..64))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The community string for which a row in this table
represents a configuration."
::= { snmpCommunityEntry 2 }
snmpCommunitySecurityName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
SNMPv3 Working Group Expires August 1999 [Page 34]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
DESCRIPTION
"A human readable string representing the corresponding
value of snmpCommunityName in a Security Model
independent format."
::= { snmpCommunityEntry 3 }
snmpCommunityContextEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The contextEngineID indicating the location of the
context in which management information is accessed
when using the community string specified by the
corresponding instance of snmpCommunityName.
The default value is the snmpEngineID of the entity in
which this object is instantiated."
::= { snmpCommunityEntry 4 }
snmpCommunityContextName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The context in which management information is accessed
when using the community string specified by the corresponding
instance of snmpCommunityName."
DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 5 }
snmpCommunityTransportTag OBJECT-TYPE
SYNTAX SnmpTagValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies a set of transport endpoints
from which an agent will accept management requests.
If a management request containing this community
is received on a transport endpoint other than the
transport endpoints identified by this object, the
request is deemed unauthentic.
The transports identified by this object are specified
in the snmpTargetAddrTable. Entries in that table
whose snmpTargetAddrTagList contains this tag value
are identified.
SNMPv3 Working Group Expires August 1999 [Page 35]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
If the value of this object has zero-length, transport
endpoints are not checked when authenticating messages
containing this community string."
DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 6 }
snmpCommunityStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row in the
snmpCommunityTable. Conceptual rows having the value
'permanent' need not allow write-access to any
columnar object in the row."
::= { snmpCommunityEntry 7 }
snmpCommunityStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row in the snmpCommunityTable.
An entry in this table is not qualified for activation
until instances of all corresponding columns have been
initialized, either through default values, or through
Set operations. The snmpCommunityName and
snmpCommunitySecurityName objects must be explicitly set."
::= { snmpCommunityEntry 8 }
--
-- The snmpTargetAddrExtTable augments the snmpTargetAddrTable with
-- a transport address mask value and a maximum message size value.
-- The transport address mask allows entries in the
-- snmpTargetAddrTable to define a set of addresses instead of just
-- a single address. The maximum message size value allows the
-- maximum message size of another SNMP entity to be configured
-- for use in SNMPv1 (and SNMPv2c) transactions, where the message
-- format does not specify a maximum message size.
--
snmpTargetAddrExtTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
SNMPv3 Working Group Expires August 1999 [Page 36]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
"The table of mask and mms values associated with the
snmpTargetAddrTable."
::= { snmpCommunityMIBObjects 2 }
snmpTargetAddrExtEntry OBJECT-TYPE
SYNTAX SnmpTargetAddrExtEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular mask and mms value."
AUGMENTS { snmpTargetAddrEntry }
::= { snmpTargetAddrExtTable 1 }
SnmpTargetAddrExtEntry ::= SEQUENCE {
snmpTargetAddrTMask OCTET STRING,
snmpTargetAddrMMS Integer32
}
snmpTargetAddrTMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The mask value associated with an entry in the
snmpTargetAddrTable. The value of this object must
have the same length as the corresponding instance of
snmpTargetAddrTAddress, or must have length 0."
DEFVAL { ''H }
::= { snmpTargetAddrExtEntry 1 }
snmpTargetAddrMMS OBJECT-TYPE
SYNTAX Integer32 (484..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum message size value associated with an entry
in the snmpTargetAddrTable."
DEFVAL { 2048 }
::= { snmpTargetAddrExtEntry 2 }
--
-- The snmpTrapAddress and snmpTrapCommunity objects are included
-- in notifications that are forwarded by a proxy, which were
-- originally received as SNMPv1 Trap messages.
--
snmpTrapAddress OBJECT-TYPE
SNMPv3 Working Group Expires August 1999 [Page 37]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
SYNTAX IpAddress
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The value of the agent-addr field of a Trap PDU which
is forwarded by a proxy forwarder application using
an SNMP version other than SNMPv1. The value of this
object SHOULD contain the value of the agent-addr field
from the original Trap PDU as generated by an SNMPv1
agent."
::= { snmpCommunityMIBObjects 3 }
snmpTrapCommunity OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The value of the community string field of an SNMPv1
message containing a Trap PDU which is forwarded by a
a proxy forwarder application using an SNMP version
other than SNMPv1. The value of this object SHOULD
contain the value of the community string field from
the original SNMPv1 message containing a Trap PDU as
generated by an SNMPv1 agent."
::= { snmpCommunityMIBObjects 4 }
-- Conformance Information *******************************************
snmpCommunityMIBCompliances OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 1 }
snmpCommunityMIBGroups OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 2 }
-- Compliance statements
snmpCommunityMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines which
implement the SNMP-COMMUNITY-MIB."
MODULE -- this module
MANDATORY-GROUPS { snmpCommunityGroup }
OBJECT snmpCommunityName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
SNMPv3 Working Group Expires August 1999 [Page 38]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
OBJECT snmpCommunitySecurityName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunitySecurityLevel
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityContextEngineID
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityContextName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityTransportTag
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityStatus
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
::= { snmpCommunityMIBCompliances 1 }
snmpCommunityGroup OBJECT-GROUP
OBJECTS {
snmpCommunityIndex,
snmpCommunityName,
snmpCommunitySecurityName,
snmpCommunityContextEngineID,
snmpCommunityContextName,
snmpCommunityTransportTag,
snmpCommunityStorageType,
snmpCommunityStatus,
snmpTargetAddrTMask,
snmpTargetAddrMMS
}
STATUS current
DESCRIPTION
"A collection of objects providing for configuration
of community strings for SNMPv1 (and SNMPv2c) usage."
SNMPv3 Working Group Expires August 1999 [Page 39]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
::= { snmpCommunityMIBGroups 1 }
END
SNMPv3 Working Group Expires August 1999 [Page 40]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
6. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
SNMPv3 Working Group Expires August 1999 [Page 41]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
7. Acknowledgments
This document is the result of the efforts of the SNMPv3 Working
Group. The design of the SNMP-COMMUNITY-MIB incorporates work done
by the authors of SNMPv2*:
Jeff Case (SNMP Research, Inc.)
David Harrington (Cabletron Systems Inc.)
David Levi (SNMP Research, Inc.)
Brian O'Keefe (Hewlett Packard)
Jon Saperia (BGS Systems Inc.)
Steve Waldbusser (International Network Services)
SNMPv3 Working Group Expires August 1999 [Page 42]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
8. Security Considerations
Although SNMPv1 and SNMPv2 do not provide any security, allowing
community names to be mapped into securityName/contextName provides
the ability to use view-based access control to limit the access of
unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for
network administrators to make use of this capability in order to
avoid unauthorized access to MIB data that would otherwise be secure.
Further, the SNMP-COMMUNITY-MIB has the potential to expose community
strings which provide access to more information than that which is
available using the usual 'public' community string. For this
reason, a security administrator may wish to limit accessibility to
the SNMP-COMMUNITY-MIB, and in particular, to make it inaccessible
when using the 'public' community string.
When a proxy implementation translates messages between SNMPv1 (or
SNMPv2c) and SNMPv3, there may be a loss of security. For example,
an SNMPv3 message received using authentication and privacy which is
subsequently forwarded using SNMPv1 will lose the security benefits
of using authentication and privacy. Careful configuration of
proxies is required to address such situations. One approach to deal
with such situations might be to use an encrypted tunnel.
SNMPv3 Working Group Expires August 1999 [Page 43]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
9. References
[1] Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets"", STD16, RFC
1155, May 1990.
[2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
Management Protocol", STD15, RFC 1157, SNMP Research, Performance
Systems International, Performance Systems International, MIT
Laboratory for Computer Science, May 1990.
[3] McCloghrie, K., and M. Rose, Editors, "Concise MIB Definitions",
STD 16, RFC 1212, Hughes LAN Systems, Performance Systems
International, March 1991.
[4] Rose, M. T., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[5] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP-
based Agents", RFC 1303, Hughes LAN Systems, Dover Beach
Consulting, Inc., February 1992.
[6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Introduction to Community-based SNMPv2", RFC1901, SNMP
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Structure of Management Information for Version 2 of
the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc.,
Cisco Systems, Inc., Dover Beach Consulting, Inc., International
Network Services, January 1996.
[9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Conformance Statements for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
[10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc.,
Cisco Systems, Inc., Dover Beach Consulting, Inc., International
SNMPv3 Working Group Expires August 1999 [Page 44]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
Network Services, January 1996.
[11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, January 1996.
[12] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC1907, SNMP
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework", RFC1908, SNMP
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[14] Levi, D., Wijnen, B., "Mapping SNMPv2 onto SNMPv1 within a bi-
lingual SNMP agent", RFC2089, SNMP Research, Inc., IBM, January
1997.
[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[16] The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An
Architecture for Describing SNMP Management Frameworks", draft-
ietf-snmpv3-arch-05.txt, February 1999.
[17] The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B.,
"Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)", draft-ietf-snmpv3-mpc-05.txt, February
1999.
[18] The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMP
Applications", draft-ietf-snmpv3-appl-v2-03.txt, February 1999.
[19] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User-
Based Security Model for Version 3 of the Simple Network Management
Protocol (SNMP)", draft-ietf-snmpv3-usm-v2-05.txt, February 1999.
[20] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K.,
"View-based Access Control Model for the Simple Network Management
Protocol (SNMP)", draft-ietf-snmpv3-vacm-04.txt, February 1999.
SNMPv3 Working Group Expires August 1999 [Page 45]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
10. Editor's Address
Rob Frye
MCI Communications Corp.
2100 Reston Parkway, Suite 600
Reston, VA 20191
U.S.A.
Phone: +1 703 715 7225
EMail: Rob.Frye@mci.com
David B. Levi
SNMP Research, Inc.
3001 Kimberlin Heights Road
Knoxville, TN 37920-9716
U.S.A.
Phone: +1 423 573 1434
EMail: levi@snmp.com
Shawn A. Routhier
Integrated Systems Inc.
333 North Ave 4th Floor
Wakefield MA 01880
U.S.A.
Phone: + 1 781 245 0804
EMail: sar@epilogue.com
Bert Wijnen
IBM T. J. Watson Research
Schagen 33
3461 GL Linschoten
Netherlands
Phone: +31 348 432 794
EMail: wijnen@vnet.ibm.com
SNMPv3 Working Group Expires August 1999 [Page 46]
Internet Draft Coexistence between SNMP versions 10 Feb 1999
A. Full Copyright Statement
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
SNMPv3 Working Group Expires August 1999 [Page 47]