Internet Draft Coexistence between SNMP versions 7 Aug 1998
INTERNET-DRAFT Rob Frye
MCI Communications Corp.
David B. Levi
SNMP Research, Inc.
Bert Wijnen
IBM T.J. Watson Research
7 Aug 1998
Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework
<draft-ietf-snmpv3-coex-00.txt>
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Copyright Notice
Copyright (C) The Internet Society (date). All Rights Reserved.
SNMPv3 Working Group Expires February 1999 [Page 1]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
Abstract
The purpose of this document is to describe coexistence between
version 3 of the Internet-standard Network Management Framework
[RFC2271], termed the SNMP version 3 framework (SNMPv3), version 2 of
the Internet-standard Network Management Framework [RFC1901], termed
the SNMP version 2 framework (SNMPv2), and the original Internet-
standard Network Management Framework (SNMPv1) [RFC1157].
SNMPv3 Working Group Expires February 1999 [Page 2]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
Table Of Contents
1 Overview ..................................................... 4
1.1 SNMPv1 ..................................................... 4
1.2 SNMPv2 ..................................................... 5
1.3 SNMPv3 ..................................................... 5
2 SMI and Management Information Mappings ...................... 7
2.1 Object Definitions ......................................... 7
2.2 Trap Definitions ........................................... 9
2.3 Compliance Statements ...................................... 10
2.4 Capabilities Statements .................................... 10
3 SNMPv1 and SNMPv2 MIB Instrumentation ........................ 12
4 Translating Notifications Between SNMP Formats ............... 13
4.1 Translating SNMPv1 Format to SNMPv2 Format ................. 14
4.2 Translating SNMPv2 Format to SNMPv1 Format ................. 15
4.3 Notification Translation Failure ........................... 16
4.3.1 discussion about additional varbinds (agent_addr, com-
munity) ................................................... 17
5 Approaches to Coexistence in a Multi-lingual Network ......... 18
5.1 Multi-lingual implementations .............................. 18
5.1.1 Command Generator ........................................ 18
5.1.2 Command Responder ........................................ 18
5.1.3 Notification Originator .................................. 19
5.1.4 Notification Receiver .................................... 19
5.2 Proxy Implementations ...................................... 19
6 Multi-Lingual Command Responder Behaviour .................... 21
6.1 Mapping SMIv2 into SMIv1 ................................... 21
6.2 Mapping SNMPv2 Exceptions .................................. 21
6.2.1 Mapping nosuchObject and noSuchInstance .................. 22
6.2.2 Mapping endOfMibView ..................................... 22
6.3 Processing An SNMPv1 GetRequest ............................ 23
6.4 Processing An SNMPv1 GetNextRequest ........................ 24
7 Error Status Mappings ........................................ 26
8 Message Processing Models and Security Models ................ 27
8.1 Mappings ................................................... 27
8.2 Elements Of Procedure ...................................... 27
8.2.1 Processing An Incoming Request ........................... 28
8.2.2 Processing An Outgoing Response .......................... 28
8.2.3 Processing An Incoming Notification ...................... 28
8.2.4 Processing An Outgoing Notification ...................... 28
8.3 Community MIB .............................................. 28
9 Intellectual Property ........................................ 35
10 Acknowledgments ............................................. 36
11 Security Considerations ..................................... 38
12 References .................................................. 39
13 Editor's Address ............................................ 41
A. Full Copyright Statement .................................... 42
SNMPv3 Working Group Expires February 1999 [Page 3]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
1. Overview
The purpose of this document is to describe coexistence between
version 3 of the Internet-standard Network Management Framework
[RFC2271], termed the SNMP version 3 framework (SNMPv3), version 2 of
the Internet-standard Network Management Framework [RFC1901], termed
the SNMP version 2 framework (SNMPv2), and the original Internet-
standard Network Management Framework (SNMPv1) [RFC1157].
There are five 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 notifications between SMIv1 and SMIv2 formats is
documented in section 4.
- Approaches to coexistence between SNMPv1, SNMPv2, and SNMPv3
entities in a multi-lingual network is documented in section
5.
- Processing of protocol operations in multi-lingual
implementations is documented in section 6.
- The Community-Based Security Model, which provides mechanisms
for adapting SNMPv1 and SNMPv2 into the SNMPv3 view-based
access control, is documented in section 8.
1.1. SNMPv1 SNMPv1 is defined by these three documents:
- STD 16, RFC 1155 [RFC1155] which defines the Structure of
Management Information (SMI), the mechanisms used for
describing and naming objects for the purpose of management.
- STD 16, RFC 1212 [RFC1212] which defines a more concise
description mechanism, which is wholly consistent with the
SMI.
- STD 15, RFC 1157 [RFC1157] which defines the Simple Network
Management Protocol (SNMP), the protocol used for network
access to managed objects.
- (NOTE: Rob had suggested adding rfcs 1213, 2011, 2012, 2013,
1215. Which, if any, of these should we add?)
SNMPv3 Working Group Expires February 1999 [Page 4]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
1.2. SNMPv2
SNMPv2 is defined by these six documents:
- RFC 1902 which defines Version 2 of the Structure of
Management Information (SMI) [RFC1902].
- RFC 1903 which defines common MIB "Textual Conventions"
[RFC1903].
- RFC 1904 which defines Conformance Statements and requirements
for defining agent and manager capabilities [RFC1904].
- RFC 1905 which defines the Protocol Operations used in
processing [RFC1905].
- RFC 1906 which defines the Transport Mappings used "on the
wire" [RFC1906].
- RFC 1907 which defines the basic Management Information Base
upon which other MIBs can be built [RFC1907].
In addition, the following three documents augment the definition of
SNMPv2:
- RFC 1901 is an Experimental definition for using SNMPv2 format
PDUs within a community-based message format. This is
referred to throughout this document as SNMPv2c [RFC1901].
- RFC 2011 defines the IP MIB using SMIv2.
1.3. SNMPv3 SNMPv3 is defined by the these five documents:
- RFC 2271 which defines the v3 Architecture for Describing SNMP
Management Frameworks [RFC2271].
- RFC 2272 which defines Message Processing and Dispatching
[RFC2272].
- RFC 2273 which defines various SNMPv3 Applications [RFC2273].
- RFC 2274 which defines the User-based Security Model (USM),
providing for both Authenticated and Private (encrypted) SNMP
transactions [RFC2274].
SNMPv3 Working Group Expires February 1999 [Page 5]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
- 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 [RFC2275].
SNMPv3 also uses the SNMPv2 definitions of RFCs 1902 through 1907
described above.
SNMPv3 Working Group Expires February 1999 [Page 6]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
2. SMI and Management Information Mappings
The SNMPv2 approach towards describing collections of managed objects
is nearly a proper superset of the approach defined in the Internet-
standard SNMPv1 Network Management Framework. For example, both
approaches use ASN.1 [10] as the basis for a formal descriptive
notation. Indeed, one might note that the SNMPv2 approach largely
codifies the existing practice for defining MIB modules, based on
extensive experience with the SNMPv1 framework.
The following sections consider the three areas: MIB modules,
compliance statements, and capabilities statements.
MIB modules defined using the SNMPv1 framework may continue to be
used with the SNMPv2 protocol. However, for the MIB modules to
conform to the SNMPv2 framework, the following changes are required:
2.1. Object Definitions
In general, conversion of a MIB module does not require the
deprecation of the objects contained therein. Only if the semantics
of an object truly changes should deprecation be performed.
(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 descriptor which contains the hyphen character, the hyphen
character is removed.
(4) For any label for a named-number enumeration which contains the
hyphen character, the hyphen character is removed.
(5) 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.
(6) For any object with a SYNTAX clause value of an enumerated INTEGER,
the hyphen character is removed from any named-number labels which
contain the hyphen character.
SNMPv3 Working Group Expires February 1999 [Page 7]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
(7) For any object with a SYNTAX clause value of Counter, the object
must have the value of its SYNTAX clause changed to Counter32.
(8) For any object with a SYNTAX clause value of Gauge, the object must
have the value of its SYNTAX clause changed to Gauge32.
(9) For all objects, the ACCESS clause must be replaced by a MAX-ACCESS
clause. The value of the MAX-ACCESS clause is 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, will 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 is "read-write", and the DESCRIPTION clause
notes that reading this object will result implementation-specific
results.
(10) For all objects, if the value of the STATUS clause is "mandatory",
the value must be replaced with "current".
(11) For all objects, if the value of the STATUS clause is "optional",
the value must be replaced with "obsolete".
(12) For any object not containing a DESCRIPTION clause, the object must
have a DESCRIPTION clause defined.
(13) 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.
(14) 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 is changed to "obsolete".
(15) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER
value which is expressed as a collection of sub-identifiers, change
the value 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
SNMPv1 framework. The SNMPv2 and SNMPv3 frameworks correct 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 it may be worthwhile to deprecate the
SNMPv3 Working Group Expires February 1999 [Page 8]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
objects relating to those tables and replace them with objects
defined using the new approach.
(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), it is recommended that the bounds for the size of the
object be defined.
(3) For all textual conventions informally defined in the MIB module,
it is recommended that those conventions using the TEXTUAL-
CONVENTION macro be redefined. 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, it is recommended that a UNITS clause 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,
it is recommended that an AUGMENTS clause be used in place of the
INDEX clause for the object corresponding to the conceptual row
which is an extension.
Finally, when encountering common errors in SNMPv1 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 is 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) is changed to
"obsolete".
2.2. Trap Definitions
If a MIB module is changed to conform to the SNMPv2 framework, 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, and should
reference SNMPv2-SMI instead.
SNMPv3 Working Group Expires February 1999 [Page 9]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
(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'
then the value of the invocation is 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 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
must be removed. Typically this editing can occur when the
information module undergoes review.
2.4. Capabilities Statements
In the SNMPv1 framework, the informational document [11] 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 SNMPv2 framework requires these changes:
(1) Use the macro name AGENT-CAPABILITIES instead of MODULE-
CONFORMANCE.
(2) The STATUS clause must be added, with a value of 'current'.
(3) For all occurrences of the CREATION-REQUIRES clause, note the
slight change in semantics, and omit this clause if appropriate.
SNMPv3 Working Group Expires February 1999 [Page 10]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
In order to ease the coexistence between SNMPv1, SNMPv2, and SNMPv3,
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 SNMPv1 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 a SNMPv1 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 February 1999 [Page 11]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
3. SNMPv1 and SNMPv2 MIB Instrumentation
In several places, this document refers to SNMPv1 MIB Instrumentation
and SNMPv2 MIB Instrumentation. This refers 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.
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.
SNMPv3 Working Group Expires February 1999 [Page 12]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
4. Translating Notifications Between SNMP Formats
This section describes how data contained in a notification is
translated between the SNMPv1 format and the SNMPv2 format. There
are two parts to the format of a notification, the SMI version used
to define the notification, and the format of parameters used to
represent a generated notification.
The SMI version used to define a notification will generally
determine the format of parameters used when a notification is
generated by MIB instrumentation. There are two formats for
parameters, those used in an SNMPv1 notification, and those used in
an SNMPv2 notification. These set of information are refered to in
this section as 'notification parameters format'. There are two
formats, the SNMPv1 notification parameter format and the SNMPv2
notification parameter format. There are two situations where
notification parameters must be translated between SNMP formats:
- When instrumentation in an entity generates a set of
notification parameters using one SNMP format, and the
configuration of the entity indicates that the notification
must be sent using a protocol version that requires
notification parameters in the other SNMP format.
- When a proxy receives a notification in one SNMP format, and
must forward the notification using a protocol version that
requires a different SNMP format.
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 format 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 value (OBJECT IDENTIFIER).
- An agent-addr value (NetworkAddress).
- A generic-trap value (INTEGER).
- A specific-trap value (INTEGER).
SNMPv3 Working Group Expires February 1999 [Page 13]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
- A time-stamp value (TimeTicks).
- A list of variable-bindings (VarBindList).
SNMPv2 notification parameters consist of:
- A sysUpTime value (TimeTicks). This appears in the first
variable-binding in an SNMPv2 notification.
- An snmpTrapOID value (OBJECT IDENTIFIER). This appears in the
second variable-binding in an SNMPv2 notification.
- A list of variable-bindings (VarBindList). This refers to all
but the first two variable-bindings in an SNMPv2 notification.
4.1. Translating SNMPv1 Format to SNMPv2 Format
The following procedure describes how to translate SNMPv1
notification parameters into SNMPv2 notification parameters:
(1) The SNMPv2 sysUpTime value is taken directly from the SNMPv1 time-
stamp value.
(2) If the SNMPv1 generic-trap value is 'enterpriseSpecific(6)', the
SNMPv2 snmpTrapOID value is the concatentation of the SNMPv1
enterprise value and two additional sub-identifiers, '0', and the
SNMPv1 specific-trap value.
(3) If the SNMPv1 generic-trap value is not 'enterpriseSpecific(6)',
the SNMPv2 snmpTrapOID value is the corresponding trap as defined
in [RFC1907].
(4) The SNMPv2 variable-bindings is the SNMPv1 variable-bindings with a
single variable-binding appended. The name portion of this
variable binding contains snmpTrapEnterprise.0 [RFC1907], and the
value is the SNMPv1 enterprise value.
(5) The value of the agent-addr field is lost when converting
notification parameters from SNMPv1 to SNMPv2.
SNMPv3 Working Group Expires February 1999 [Page 14]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
4.2. Translating SNMPv2 Format to SNMPv1 Format
The following procedure describes how to translate SNMPv2
notification parameters into SNMPv1 notification parameters:
(1) The SNMPv1 enterprise value is determined as follows:
- If the SNMPv2 snmpTrapOID value is one of the standard traps
as defined in [RFC1907], then the SNMPv1 enterprise value is
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 value is set to the value 'snmpTraps' as defined in
RFC1907 [RFC1907].
- If the SNMPv2 snmpTrapOID value is not one of the standard
traps as defined in [RFC1907], then the SNMPv1 enterprise
value is set to the SNMPv2 snmpTrapOID value as follows:
- If the next-to-last sub-identifier of the snmpTrapOID is
zero, then the SMIv1 enterprise is 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 is the SMIv2
snmpTrapOID with the last sub-identifier removed.
(2) The SNMPv1 agent-addr value is 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 UDP, the
SNMPv1 agent-addr value is 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 value is 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 this source was an IP or UDP address, that
address is used for the SNMPv1 agent-addr value. Otherwise,
the SNMPv1 agent-addr value is set to 0.0.0.0.
(3) If the SNMPv2 snmpTrapOID value is one of the standard traps as
defined in [RFC1907], the SNMPv1 generic-trap value is set as
follows:
SNMPv3 Working Group Expires February 1999 [Page 15]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
value of snmpTrapOID.0 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 value is set to 6.
(4) If the SNMPv2 snmpTrapOID value is one of the standard traps as
defined in [RFC1907], the SNMPv1 specific-trap value is set to
zero. Otherwise, the SNMPv1 specific-trap value is set to the last
sub-identifier of the SNMPv2 snmpTrapOID value.
(5) The SNMPv1 time-stamp value is taken directly from the SNMPv2
sysUpTime value.
(6) The SNMPv1 variable-bindings is the SNMPv2 variable-bindings with
the following exceptions:
- If a variable-binding whose name is snmpTrapEnterprise.0
exists in the SNMPv2 variable-bindings, that variable-binding
is removed.
- If a variable-binding whose type is Counter64 exists in the
SNMPv2 variable-bindings, the translation fails. The
consequences of a failed translation depend on the situation
in which the translation is being performed.
4.3. Notification Translation Failure
If translation of a notification from SNMPv2 to SNMPv1 fails due to
the existence of a variable-binding with a type of Counter64, the
result is as follows:
- If the translation is being performed within a notification
originator in order to send an SNMPv1 Trap-PDU, the Trap-PDU
is simply not sent. The notification may still be sent using
other SNMP versions.
- If the translation is being performed within a proxy in order
to forward the notification as an SNMPv1 Trap-PDU, the Trap-
PDU is not sent. The notification may still be forwarded
SNMPv3 Working Group Expires February 1999 [Page 16]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
using other SNMP versions.
4.3.1. discussion about additional varbinds (agent_addr, community)
SNMPv3 Working Group Expires February 1999 [Page 17]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
5. 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 implentation 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.
5.1. Multi-lingual implementations
This approach requires an entity to support multiple SNMP message
formats. Typically this means supporting SNMPv1, SNMPv2c, and SNMPv3
message formats. The behaviour of various types of SNMPv3
applications which support multiple message formats is described in
the following sections. This approach allows entities which support
multiple SNMP message formats to coexist with and communicate with
entities which support only a single SNMP message format.
5.1.1. Command Generator
A command generator must select an appropriate message format when
sending requests to another entity. One way to achieve this is to
consult a local database to select the appropriate message format.
In addition, a command generator should 'downgrade' GetBulk requests
to GetNext requests when selecting SNMPv1 as the message format for
an outgoing request.
5.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 February 1999 [Page 18]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
- Deal correctly with SNMPv2 MIB instrumentation that returns a
Counter64 value while processing an SNMPv1 message,
- Deal correctly with SNMPv2 instrumentation that returns one of
the three exception values while processing an SNMPv1 message,
- Map SNMPv2 error codes returned from SNMPv2 instrumentation
into SNMPv1 error code when processing an SNMPv1 message, and
Note that SNMPv1 error codes can be used without any change when
processing SNMPv2c or SNMPv3 messages.
Details about how a command responder handles these requirements are
provided in section 6.
5.1.3. Notification Originator
A notification originator must be able to translate notifications
between SNMPv1 and SNMPv2 formats in order to send a notification
using a particular SNMP message format. If instrumentation presents
a notification in the SMIv1 format and configuration information
specifies that notifications be sent using SNMPv2c or SNMPv3, the
notification must be translated to the SNMPv2 format. Likewise, if
instrumentation presents a notification in the SNMPv2 format and
configuration information specifies that notifications be sent using
SNMPv1, the notification must be translated to the SNMPv1 format.
5.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 which SNMP format should be used when
delivering notifications to that higher level application. The
notification receiver would then translate between SNMP formats when
required in order to present a notification using the desired format.
5.2. Proxy Implementations
A proxy implementation may be used to enable communication between
entities which support different SNMP message formats. This is
accomplished in a proxy forwarding application by performing
SNMPv3 Working Group Expires February 1999 [Page 19]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
translations on a PDU in the following situations:
- If a GetBulkRequest-PDU is received and must be forwarded
using the SNMPv1 message format, the proxy forwarder sets the
non-repeaters and max-repetitions fields to 0, and sets 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 format, the proxy forwarder will
remove the contents of the variable-bindings field before
forwarding the response.
- If a Trap-PDU is received, and will be forwarded using the
SNMPv2c or SNMPv3 message format, the proxy will apply the
translation rules described in section 4, and will forward the
notification as an SNMPv2-Trap-PDU.
- If an SNMPv2-Trap-PDU is received, and will be forwarded using
the SNMPv1 message format, the proxy will apply the
translation rules described in section 4, and will 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 format, is ignored. An InformRequest-PDU can
only be forwarded using the SNMPv2c or SNMPv3 message format.
SNMPv3 Working Group Expires February 1999 [Page 20]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
6. Multi-Lingual Command Responder Behaviour
The following sections describe the behaviour of a command responder
application which supports multiple SNMP message formats, and which
has access to some combination of SNMPv1 and SNMPv2 MIB
instrumentation.
6.1. Mapping SMIv2 into SMIv1
The SMIv2 [RFC1902] 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 should
make sure that they never return a variable binding containing a
Counter64 value in a response to a request that was received using
the SNMPv1 message format.
Multi-lingual command responders should 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, we return an error-status of
noSuchName and the error-index is set to the variable binding
that causes this error.
- On an SNMPv1 GETNEXT request, we skip the object instance and
fetch the next object instance that follows the one with a
syntax of Counter64.
- 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. If we do receive a Counter64 value in an
SNMPv1 SET packet, it should 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 is
incremented and no response is returned.
6.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
SNMPv3 Working Group Expires February 1999 [Page 21]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
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 compliant instrumentation
for exception values, and convert these exception values into SNMPv1
error codes.
The type of exception that can be returned from 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.
6.2.1. Mapping nosuchObject and noSuchInstance
A noSuchObject or noSuchInstance exception generated by SNMPv2
compliant 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 should be set to noSuchName. Also, the error-index
field is set to the index of the variable binding for which an
exception occurred, and the variable binding list from the original
request is 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.
6.2.2. Mapping endOfMibView
When SNMPv2 compliant 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
SNMPv3 Working Group Expires February 1999 [Page 22]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
in a noSuchName error, and so the error-status field of the response
PDU should be set to noSuchName. Also, the error- index field is set
to the index of the variable binding for which an exception occurred,
and the variable binding list from the original request is 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.
6.3. Processing An SNMPv1 GetRequest
When processing an SNMPv1 GetRequest, the following procedures should
be followed when calling SNMPv2 MIB instrumentation.
When such 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 is translated to an SNMPv1 error-status using
the table in section 7, "Mapping SNMPv2 error-status into
SNMPv1 error-status"
- The error-index is 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 is made exactly
the same as the variable binding list that was received in the
original request.
(2) If the error-status is noError, then find any variable binding that
contains an SNMPv2 exception (noSuchObject or noSuchInstance) or an
SNMPv2 syntax that is unknown to SNMPv1 (Counter64). (Note that if
there are more than one, the agent may choose any such variable
binding.) If there are any such variable bindings, then for the
one chosen:
- Set the error-status to noSuchName
- Set the error-index to the position (in the variable binding
list of the original request) of the variable binding that
returned such an SNMPv2 exception or syntax.
SNMPv3 Working Group Expires February 1999 [Page 23]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
- Make the variable binding list of the response PDU exactly the
same as the variable binding list that was received in the
original request.
(3) If there are no such variable bindings, then:
- Set the error-status to noError
- Set the error-index to zero
- Compose the variable binding list of the response, using the
data as it is returned by the instrumentation code.
6.4. Processing An SNMPv1 GetNextRequest
When processing an SNMPv1 GetNextRequest, the following procedures
should be followed when SNMPv2 MIB instrumentation is called as part
of processing the request. There may be repetitive calls to
(possibly different pieces of) instrumentation code 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 instrumentation.
Data returned from SNMPv1 instrumentation may be treated in the
normal manner for an SNMPv1 request.
First, if the instrumentation returns an error-status of anything
other than noError:
(1) The error status is translated to an SNMPv1 error-status using the
table in section 7, "Mapping SNMPv2 error-status into SNMPv1
error-status"
(2) The error-index is 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 is made exactly the
same as the variable binding list that was received in the original
request.
Otherwise, if the instrumentation returns an error-status of noError:
(1) If there are any variable bindings containing an SNMPv2 syntax of
Counter64, then consider these variable bindings to be not in view
and repeat the call to the instrumentation code as often as needed
until a value other than Counter64 is returned.
SNMPv3 Working Group Expires February 1999 [Page 24]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
(2) Find any variable binding that contains an SNMPv2 exception
endOfMibView. (Note that if there are more than one, the agent may
choose any such variable binding.) If there are any such variable
bindings, then for the one chosen:
- Set the error-status to noSuchName
- Set the error-index to the position (in the variable binding
list of the original request) of the variable binding that
returned such an SNMPv2 exception.
- Make the variable binding list of the response PDU exactly the
same as the variable binding list that was received in the
original request.
(3) If there are no such variable bindings, then:
- Set the error-status to noError
- Set the error-index to zero
- Compose the variable binding list of the response, using the
data as it is returned by the instrumentation code.
SNMPv3 Working Group Expires February 1999 [Page 25]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
7. Error Status Mappings
The following table shows the mappings of SNMPv2 error-status values
into SNMPv1 error-status values.
SNMPv2 error-status SNMPv1 error-status
=================== ===================
noError noError
tooBig tooBig
noSuchName noSuchName
badValue badValue
readOnly readOnly
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 February 1999 [Page 26]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
8. Message Processing Models and Security Models
In order to adapt SNMPv1 and SNMPv2c into the SNMPv3 architecture, four
additional models must be defined:
- The SNMPv1 Message Processing Model
- The SNMPv2c Message Processing Model
- The SNMPv1 Community-Based Security 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.
8.1. Mappings
The SNMPv1 and SNMPv2c Message Processing Models and Security Models
require mappings between parameters used in SNMPv1 and SNMPv2c messages,
and those use in SNMPv3 messages. The parameters which must be mapped
consist of the SNMPv1 and SNMPv2c community name, and the SNMPv3
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.
8.2. Elements Of Procedure
The following sections describe the procedures for processing various
types of SNMPv1 and SNMPv2c messages.
SNMPv3 Working Group Expires February 1999 [Page 27]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
8.2.1. Processing An Incoming Request
8.2.2. Processing An Outgoing Response
8.2.3. Processing An Incoming Notification
8.2.4. Processing An Outgoing Notification
8.3. Community MIB
SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
Integer32,
Counter32,
UInteger32
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
SNMPv3 Working Group Expires February 1999 [Page 28]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
Co-editor: Rob Frye
MCI Communications Corp.
Postal: 2100 Reston Parkway, Suite 600
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: 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 xxx } -- get assignment from IANA
-- 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
STATUS current
DESCRIPTION
"The table of community strings configured in the SNMP
engine's Local Configuration Datastore (LCD)."
SNMPv3 Working Group Expires February 1999 [Page 29]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
::= { snmpCommunityMIBObjects 1 }
snmpCommunityEntry OBJECT-TYPE
SYNTAX SnmpCommunityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular community string."
INDEX { snmpCommunityIndex }
::= { snmpCommunityTable 1 }
SnmpCommunityEntry ::= SEQUENCE {
snmpCommunityIndex Integer32,
snmpCommunityName OCTET STRING,
snmpCommunitySecurityName SnmpAdminString,
snmpCommunityContextEngineID SnmpEngineID,
snmpCommunityContextName SnmpAdminString,
snmpCommunityTransportTag SnmpTagValue,
snmpCommunityStorageType StorageType,
snmpCommunityStatus RowStatus
}
snmpCommunityIndex OBJECT-TYPE
SYNTAX Integer32
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
DESCRIPTION
"A human readable string representing the corresponding
value of snmpCommunityName in a Security Model
independent format."
SNMPv3 Working Group Expires February 1999 [Page 30]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
::= { 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 }
-- Comments on TransportTag
-- based on this tag we can limit the use of an entry to a defined
-- set of transport end-points. Maybe we want to augemnt the
-- snmpTargetAddrTable to also contain a snmpTargetAddrTMask
-- of type TAddress which we can use as a mask.
-- Opinions are welcome.
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
SNMPv3 Working Group Expires February 1999 [Page 31]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
in the snmpTargteAddrTable. Entries in that table
whose snmpTargetAddrTagList contains this tag value
are identified.
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 }
-- Conformance Information *******************************************
snmpCommunityMIBCompliances OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 1 }
snmpCommunityMIBGroups OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 2 }
-- Compliance statements
snmpCommunityMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
SNMPv3 Working Group Expires February 1999 [Page 32]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
"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."
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 snmpCommunityTransportLabel
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."
::= { usmMIBCompliances 1 }
snmpCommunityGroup OBJECT-GROUP
OBJECTS {
snmpCommunityIndex,
snmpCommunityName,
snmpCommunitySecurityName,
snmpCommunityContextEngineID,
snmpCommunityContextName,
SNMPv3 Working Group Expires February 1999 [Page 33]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
snmpCommunityTransportLabel,
snmpCommunityStorageType,
snmpCommunityStatus
}
STATUS current
DESCRIPTION
"A collection of objects providing for configuration
of community strings for SNMPv1 or SNMPv2c usage."
::= { snmpCommunityMIBGroups 1 }
END
SNMPv3 Working Group Expires February 1999 [Page 34]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
9. 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 February 1999 [Page 35]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
10. Acknowledgments
This document is the result of the efforts of the SNMPv3 Working
Group. Some special thanks are in order to the following SNMPv3 WG
members:
Dave Battle (SNMP Research, Inc.)
Uri Blumenthal (IBM T.J. Watson Research Center)
Jeff Case (SNMP Research, Inc.)
John Curran (BBN)
T. Max Devlin (Hi-TECH Connections)
John Flick (Hewlett Packard)
David Harrington (Cabletron Systems Inc.)
N.C. Hien (IBM T.J. Watson Research Center)
Dave Levi (SNMP Research, Inc.)
Louis A Mamakos (UUNET Technologies Inc.)
Paul Meyer (Secure Computing Corporation)
Keith McCloghrie (Cisco Systems)
Russ Mundy (Trusted Information Systems, Inc.)
Bob Natale (ACE*COMM Corporation)
Mike O'Dell (UUNET Technologies Inc.)
Dave Perkins (DeskTalk)
Peter Polkinghorne (Brunel University)
Randy Presuhn (BMC Software, Inc.)
David Reid (SNMP Research, Inc.)
Shawn Routhier (Epilogue)
Juergen Schoenwaelder (TU Braunschweig)
Bob Stewart (Cisco Systems)
Bert Wijnen (IBM T.J. Watson Research Center)
The document is based on recommendations of the IETF Security and
Administrative Framework Evolution for SNMP Advisory Team. Members of
that Advisory Team were:
David Harrington (Cabletron Systems Inc.)
Jeff Johnson (Cisco Systems)
David Levi (SNMP Research Inc.)
John Linn (Openvision)
Russ Mundy (Trusted Information Systems) chair
Shawn Routhier (Epilogue)
Glenn Waters (Nortel)
Bert Wijnen (IBM T. J. Watson Research Center)
As recommended by the Advisory Team and the SNMPv3 Working Group
Charter, the design incorporates as much as practical from previous
RFCs and drafts. As a result, special thanks are due to the authors
of previous designs known as SNMPv2u and SNMPv2*:
SNMPv3 Working Group Expires February 1999 [Page 36]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
Jeff Case (SNMP Research, Inc.)
David Harrington (Cabletron Systems Inc.)
David Levi (SNMP Research, Inc.)
Keith McCloghrie (Cisco Systems)
Brian O'Keefe (Hewlett Packard)
Marshall T. Rose (Dover Beach Consulting)
Jon Saperia (BGS Systems Inc.)
Steve Waldbusser (International Network Services)
Glenn W. Waters (Bell-Northern Research Ltd.)
SNMPv3 Working Group Expires February 1999 [Page 37]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
11. 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.
SNMPv3 Working Group Expires February 1999 [Page 38]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
12. References
[RFC1155]
Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets"", STD16, RFC
1155, May 1990.
[RFC1157]
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.
[RFC1212]
McCloghrie, K., and M. Rose, Editors, "Concise MIB Definitions.nr
_F 1 q, STD 16, RFC 1212, Hughes LAN Systems, Performance Systems
International, March 1991.
[RFC1213]
McCloghrie, K., and M. Rose, Editors, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II", STD 17,
RFC 1213, Hughes LAN Systems, Performance Systems International,
March 1991.
[RFC1901]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Introduction to Community-based SNMPv2", RFC1902, SNMP
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[RFC1902]
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.
[RFC1903]
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.
[RFC1905]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for Version 2 of the Simple
SNMPv3 Working Group Expires February 1999 [Page 39]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc.,
Cisco Systems, Inc., Dover Beach Consulting, Inc., International
Network Services, January 1996.
[RFC1907]
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)", RFC1905, SNMP
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[RFC1908]
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", RFC1905, SNMP
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[RFC2271]
The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An
Architecture for Describing SNMP Management Frameworks", RFC2271,
January 1998.
[RFC2272]
The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B.,
"Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)", RFC2272, January 1998.
[RFC2273]
The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMPv3
Applications", RFC2273, January 1998.
[RFC2274]
The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User-
Based Security Model for Version 3 of the Simple Network Management
Protocol (SNMP)", RFC2274, January 1998.
[RFC2275]
The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K.,
"View-based Access Control Model for the Simple Network Management
Protocol (SNMP)", RFC2275, January 1998.
SNMPv3 Working Group Expires February 1999 [Page 40]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
13. 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
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 February 1999 [Page 41]
Internet Draft Coexistence between SNMP versions 7 Aug 1998
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 February 1999 [Page 42]