draft-ietf-snmpv3-coex-00.txt   draft-ietf-snmpv3-coex-01.txt 
INTERNET-DRAFT Rob Frye INTERNET-DRAFT Rob Frye
MCI Communications Corp. MCI Communications Corp.
David B. Levi David B. Levi
SNMP Research, Inc. SNMP Research, Inc.
Shawn A. Routhier
Integrated Systems Inc.
Bert Wijnen Bert Wijnen
IBM T.J. Watson Research IBM T.J. Watson Research
Coexistence between Version 1, Version 2, and Version 3 Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework of the Internet-standard Network Management Framework
<draft-ietf-snmpv3-coex-00.txt> <draft-ietf-snmpv3-coex-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 8 skipping to change at page 2, line 8
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). Rim).
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (date). All Rights Reserved.
Abstract Abstract
The purpose of this document is to describe coexistence between The purpose of this document is to describe coexistence between
version 3 of the Internet-standard Network Management Framework version 3 of the Internet-standard Network Management Framework,
[RFC2271], termed the SNMP version 3 framework (SNMPv3), version 2 of (SNMPv3), version 2 of the Internet-standard Network Management
the Internet-standard Network Management Framework [RFC1901], termed Framework (SNMPv2), and the original Internet-standard Network
the SNMP version 2 framework (SNMPv2), and the original Internet- Management Framework (SNMPv1). This document obsoletes RFC 1908 [13]
standard Network Management Framework (SNMPv1) [RFC1157]. and RFC2089 [14].
Table Of Contents Table Of Contents
1 Overview ..................................................... 4 1 Overview ..................................................... 4
1.1 SNMPv1 ..................................................... 4 1.1 SNMPv1 ..................................................... 4
1.2 SNMPv2 ..................................................... 5 1.2 SNMPv2 ..................................................... 5
1.3 SNMPv3 ..................................................... 5 1.3 SNMPv3 ..................................................... 6
2 SMI and Management Information Mappings ...................... 7 1.4 SNMPv1 and SNMPv2 MIB Instrumentation ...................... 6
2.1 Object Definitions ......................................... 7 2 SMI and Management Information Mappings ...................... 8
2.2 Trap Definitions ........................................... 9 2.1 Object Definitions ......................................... 8
2.3 Compliance Statements ...................................... 10 2.2 Trap and Notification Definitions .......................... 10
2.4 Capabilities Statements .................................... 10 2.3 Compliance Statements ...................................... 11
3 SNMPv1 and SNMPv2 MIB Instrumentation ........................ 12 2.4 Capabilities Statements .................................... 11
4 Translating Notifications Between SNMP Formats ............... 13 3 Translating Notifications Parameters ......................... 13
4.1 Translating SNMPv1 Format to SNMPv2 Format ................. 14 3.1 Translating SNMPv1 Notification Parameters to SNMPv2 No-
4.2 Translating SNMPv2 Format to SNMPv1 Format ................. 15 tification Parameters ..................................... 14
4.3 Notification Translation Failure ........................... 16 3.2 Translating SNMPv2 Notification Parameters to SNMPv1 No-
4.3.1 discussion about additional varbinds (agent_addr, com- tification Parameters ..................................... 15
munity) ................................................... 17 4 Approaches to Coexistence in a Multi-lingual Network ......... 18
5 Approaches to Coexistence in a Multi-lingual Network ......... 18 4.1 Multi-lingual implementations .............................. 18
5.1 Multi-lingual implementations .............................. 18 4.1.1 Command Generator ........................................ 18
5.1.1 Command Generator ........................................ 18 4.1.2 Command Responder ........................................ 18
5.1.2 Command Responder ........................................ 18 4.1.2.1 Handling Counter64 ..................................... 19
5.1.3 Notification Originator .................................. 19 4.1.2.2 Mapping SNMPv2 Exceptions .............................. 20
5.1.4 Notification Receiver .................................... 19 4.1.2.2.1 Mapping nosuchObject and noSuchInstance .............. 20
5.2 Proxy Implementations ...................................... 19 4.1.2.2.2 Mapping endOfMibView ................................. 21
6 Multi-Lingual Command Responder Behaviour .................... 21 4.1.2.3 Processing An SNMPv1 GetRequest ........................ 21
6.1 Mapping SMIv2 into SMIv1 ................................... 21 4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 22
6.2 Mapping SNMPv2 Exceptions .................................. 21 4.1.3 Notification Originator .................................. 23
6.2.1 Mapping nosuchObject and noSuchInstance .................. 22 4.1.4 Notification Receiver .................................... 24
6.2.2 Mapping endOfMibView ..................................... 22 4.2 Proxy Implementations ...................................... 24
6.3 Processing An SNMPv1 GetRequest ............................ 23 4.3 Error Status Mappings ...................................... 26
6.4 Processing An SNMPv1 GetNextRequest ........................ 24 5 Message Processing Models and Security Models ................ 27
7 Error Status Mappings ........................................ 26 5.1 Mappings ................................................... 27
8 Message Processing Models and Security Models ................ 27 5.2 The SNMPv1 Message Processing Model ........................ 27
8.1 Mappings ................................................... 27 5.2.1 Processing An Incoming Request ........................... 28
8.2 Elements Of Procedure ...................................... 27 5.2.2 Generating An Outgoing Response .......................... 30
8.2.1 Processing An Incoming Request ........................... 28 5.2.3 Generating An Outgoing Notification ...................... 30
8.2.2 Processing An Outgoing Response .......................... 28 5.3 The SNMP Community MIB Module .............................. 31
8.2.3 Processing An Incoming Notification ...................... 28 6 Intellectual Property ........................................ 40
8.2.4 Processing An Outgoing Notification ...................... 28 7 Acknowledgments .............................................. 41
8.3 Community MIB .............................................. 28 8 Security Considerations ...................................... 42
9 Intellectual Property ........................................ 35 9 References ................................................... 43
10 Acknowledgments ............................................. 36 10 Editor's Address ............................................ 45
11 Security Considerations ..................................... 38 A. Full Copyright Statement .................................... 46
12 References .................................................. 39
13 Editor's Address ............................................ 41
A. Full Copyright Statement .................................... 42
1. Overview 1. Overview
The purpose of this document is to describe coexistence between The purpose of this document is to describe coexistence between
version 3 of the Internet-standard Network Management Framework version 3 of the Internet-standard Network Management Framework,
[RFC2271], termed the SNMP version 3 framework (SNMPv3), version 2 of termed the SNMP version 3 framework (SNMPv3), version 2 of the
the Internet-standard Network Management Framework [RFC1901], termed Internet-standard Network Management Framework, termed the SNMP
the SNMP version 2 framework (SNMPv2), and the original Internet- version 2 framework (SNMPv2), and the original Internet-standard
standard Network Management Framework (SNMPv1) [RFC1157]. Network Management Framework (SNMPv1).
There are five general aspects of coexistence described in this 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: document. Each of these is described in a separate section:
- Conversion of MIB documents between SMIv1 and SMIv2 formats is - Conversion of MIB documents between SMIv1 and SMIv2 formats is
documented in section 2. documented in section 2.
- Mapping of notifications between SMIv1 and SMIv2 formats is - Mapping of notification parameters is documented in section 3.
documented in section 4.
- Approaches to coexistence between SNMPv1, SNMPv2, and SNMPv3 - Approaches to coexistence between entities which support the
entities in a multi-lingual network is documented in section various versions of SNMP in a multi-lingual network is
5. documented in section 4. This section addresses the
processing of protocol operations in multi-lingual
implementations, as well as behaviour of proxy
implementations.
- Processing of protocol operations in multi-lingual - The SNMPv1 Message Processing Model and Community-Based
implementations is documented in section 6. 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).
- The Community-Based Security Model, which provides mechanisms 1.1. SNMPv1
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: SNMPv1 is defined by these documents:
- STD 16, RFC 1155 [RFC1155] which defines the Structure of - STD 16, RFC 1155 [1] which defines the Structure of Management
Management Information (SMI), the mechanisms used for Information (SMIv1), the mechanisms used for describing and
describing and naming objects for the purpose of management. naming objects for the purpose of management.
- STD 16, RFC 1212 [RFC1212] which defines a more concise - STD 16, RFC 1212 [3] which defines a more concise description
description mechanism, which is wholly consistent with the mechanism, which is wholly consistent with the SMIv1.
SMI.
- STD 15, RFC 1157 [RFC1157] which defines the Simple Network - STD 15, RFC 1157 [2] which defines the Simple Network
Management Protocol (SNMP), the protocol used for network Management Protocol (SNMPv1), the protocol used for network
access to managed objects. access to managed objects.
- (NOTE: Rob had suggested adding rfcs 1213, 2011, 2012, 2013, - RFC 1215 [4] which defines a convention for defining Traps for
1215. Which, if any, of these should we add?) 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 1.2. SNMPv2
SNMPv2 is defined by these six documents: SNMPv2 is defined by these documents:
- RFC 1902 which defines Version 2 of the Structure of - RFC 1902 which defines Version 2 of the Structure of
Management Information (SMI) [RFC1902]. Management Information (SMIv2) [7].
- RFC 1903 which defines common MIB "Textual Conventions" - RFC 1903 which defines common MIB "Textual Conventions" [8].
[RFC1903].
- RFC 1904 which defines Conformance Statements and requirements - RFC 1904 which defines Conformance Statements and requirements
for defining agent and manager capabilities [RFC1904]. for defining agent and manager capabilities [9].
- RFC 1905 which defines the Protocol Operations used in - RFC 1905 which defines the Protocol Operations used in
processing [RFC1905]. processing [10].
- RFC 1906 which defines the Transport Mappings used "on the - RFC 1906 which defines the Transport Mappings used "on the
wire" [RFC1906]. wire" [11].
- RFC 1907 which defines the basic Management Information Base - RFC 1907 which defines the basic Management Information Base
upon which other MIBs can be built [RFC1907]. upon which other MIBs can be built [12].
In addition, the following three documents augment the definition of Note that SMIv2 as used throughout this document refers to the first
SNMPv2: three documents listed above (RFCs 1902, 1903, and 1904).
- RFC 1901 is an Experimental definition for using SNMPv2 format The following document augments the definition of SNMPv2:
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. - 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.
1.3. SNMPv3 SNMPv3 is defined by the these five documents: 1.3. SNMPv3
- RFC 2271 which defines the v3 Architecture for Describing SNMP SNMPv3 is defined by these documents:
Management Frameworks [RFC2271].
- RFC 2271 which defines an Architecture for Describing SNMP
Management Frameworks [16].
- RFC 2272 which defines Message Processing and Dispatching - RFC 2272 which defines Message Processing and Dispatching
[RFC2272]. [17].
- RFC 2273 which defines various SNMPv3 Applications [RFC2273]. - RFC 2273 which defines various SNMP Applications [18].
- RFC 2274 which defines the User-based Security Model (USM), - RFC 2274 which defines the User-based Security Model (USM),
providing for both Authenticated and Private (encrypted) SNMP providing for both Authenticated and Private (encrypted) SNMP
transactions [RFC2274]. messages [19].
- RFC 2275 which defines the View-based Access Control Model - RFC 2275 which defines the View-based Access Control Model
(VACM), providing the ability to limit access to different MIB (VACM), providing the ability to limit access to different MIB
objects on a per-user basis [RFC2275]. objects on a per-user basis [20].
SNMPv3 also uses the SNMPv2 definitions of RFCs 1902 through 1907 SNMPv3 also uses the SNMPv2 definitions of RFCs 1902 through 1907
described above. 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
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.
2. SMI and Management Information Mappings 2. SMI and Management Information Mappings
The SNMPv2 approach towards describing collections of managed objects The SMIv2 approach towards describing collections of managed objects
is nearly a proper superset of the approach defined in the Internet- is nearly a proper superset of the approach defined in the SMIv1.
standard SNMPv1 Network Management Framework. For example, both For example, both approaches use an adapted subset of ASN.1 (1988)
approaches use ASN.1 [10] as the basis for a formal descriptive [11] as the basis for a formal descriptive notation. Indeed, one
notation. Indeed, one might note that the SNMPv2 approach largely might note that the SMIv2 approach largely codifies the existing
codifies the existing practice for defining MIB modules, based on practice for defining MIB modules, based on extensive experience with
extensive experience with the SNMPv1 framework. the SMIv1.
The following sections consider the three areas: MIB modules, The following sections consider the three areas: MIB modules,
compliance statements, and capabilities statements. compliance statements, and capabilities statements.
MIB modules defined using the SNMPv1 framework may continue to be MIB modules defined using the SMIv1 may continue to be used with
used with the SNMPv2 protocol. However, for the MIB modules to protocol versions which use SNMPv2 PDUs. However, for the MIB
conform to the SNMPv2 framework, the following changes are required: modules to conform to the SMIv2, the following changes SHALL be made:
2.1. Object Definitions 2.1. Object Definitions
In general, conversion of a MIB module does not require the In general, conversion of a MIB module does not require the
deprecation of the objects contained therein. Only if the semantics deprecation of the objects contained therein. If the semantics of an
of an object truly changes should deprecation be performed. object truly changes, the object SHALL be deprecated, otherwise
deprecation is not required.
(1) The IMPORTS statement must reference SNMPv2-SMI, instead of (1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of
RFC1155-SMI and RFC-1212. RFC1155-SMI and RFC-1212.
(2) The MODULE-IDENTITY macro must be invoked immediately after any (2) The MODULE-IDENTITY macro MUST be invoked immediately after any
IMPORTs statement. IMPORTs statement.
(3) For any descriptor which contains the hyphen character, the hyphen (3) For any object with an integer-valued SYNTAX clause, in which the
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 corresponding INTEGER does not have a range restriction (i.e., the
INTEGER has neither a defined set of named-number enumerations nor INTEGER has neither a defined set of named-number enumerations nor
an assignment of lower- and upper-bounds on its value), the object an assignment of lower- and upper-bounds on its value), the object
must have the value of its SYNTAX clause changed to Integer32. 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.
(7) For any object with a SYNTAX clause value of Counter, the object (4) For any object with a SYNTAX clause value of Counter, the object
must have the value of its SYNTAX clause changed to Counter32. 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 (5) For any object with a SYNTAX clause value of Gauge, the object MUST
have the value of its SYNTAX clause changed to Gauge32. have the value of its SYNTAX clause changed to Gauge32.
(9) For all objects, the ACCESS clause must be replaced by a MAX-ACCESS (6) 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 clause. The value of the MAX-ACCESS clause SHALL be the same as
the ACCESS clause unless some other value makes "protocol sense" as that of the ACCESS clause unless some other value makes "protocol
the maximal level of access for the object. In particular, object sense" as the maximal level of access for the object. In
types for which instances can be explicitly created by a protocol particular, object types for which instances can be explicitly
set operation, will have a MAX-ACCESS clause of "read-create". If created by a protocol set operation, SHALL have a MAX-ACCESS clause
the value of the ACCESS clause is "write-only", then the value of of "read-create". If the value of the ACCESS clause is "write-
the MAX-ACCESS clause is "read-write", and the DESCRIPTION clause only", then the value of the MAX-ACCESS clause MUST be "read-
notes that reading this object will result implementation-specific write", and the DESCRIPTION clause SHALL note that reading this
results. object will result in implementation-specific results.
(10) For all objects, if the value of the STATUS clause is "mandatory", (7) For all objects, if the value of the STATUS clause is "mandatory",
the value must be replaced with "current". the value MUST be replaced with "current".
(11) For all objects, if the value of the STATUS clause is "optional", (8) For all objects, if the value of the STATUS clause is "optional",
the value must be replaced with "obsolete". the value MUST be replaced with "obsolete".
(12) For any object not containing a DESCRIPTION clause, the object must (9) For any object not containing a DESCRIPTION clause, the object MUST
have a DESCRIPTION clause defined. have a DESCRIPTION clause defined.
(13) For any object corresponding to a conceptual row which does not (10) For any object corresponding to a conceptual row which does not
have an INDEX clause, the object must have either an INDEX clause have an INDEX clause, the object MUST have either an INDEX clause
or an AUGMENTS clause defined. or an AUGMENTS clause defined.
(14) For any object with an INDEX clause that references an object with (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 a syntax of NetworkAddress, the value of the STATUS clause of both
objects is changed to "obsolete". objects MUST be changed to "obsolete".
(15) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER (12) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER
value which is expressed as a collection of sub-identifiers, change value which is expressed as a collection of sub-identifiers, the
the value to reference a single ASN.1 identifier. This may require value MUST be changed to reference a single ASN.1 identifier. This
defining a series of new objects in order to define the single may require defining a series of new objects in order to define the
ASN.1 identifier. single ASN.1 identifier.
Other changes are desirable, but not necessary: Other changes are desirable, but not necessary:
(1) Creation and deletion of conceptual rows is inconsistent using the (1) Creation and deletion of conceptual rows is inconsistent using the
SNMPv1 framework. The SNMPv2 and SNMPv3 frameworks correct this. SMIv1. The SMIv2 corrects this. As such, if the MIB module
As such, if the MIB module undergoes review early in its lifetime, undergoes review early in its lifetime, and it contains conceptual
and it contains conceptual tables which allow creation and deletion tables which allow creation and deletion of conceptual rows, then
of conceptual rows, then it may be worthwhile to deprecate the the objects relating to those tables MAY be deprecated and replaced
objects relating to those tables and replace them with objects with objects defined using the new approach. The new approach can
defined using the new approach. 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 (2) For any object with a string-valued SYNTAX clause, in which the
corresponding OCTET STRING does not have a size restriction (i.e., corresponding OCTET STRING does not have a size restriction (i.e.,
the OCTET STRING has no assignment of lower- and upper-bounds on 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 its length), the bounds for the size of the object SHOULD be
object be defined. defined.
(3) For all textual conventions informally defined in the MIB module, (3) All textual conventions informally defined in the MIB module SHOULD
it is recommended that those conventions using the TEXTUAL- be redefined using the TEXTUAL-CONVENTION macro. Such a change
CONVENTION macro be redefined. Such a change would not necessitate would not necessitate deprecating objects previously defined using
deprecating objects previously defined using an informal textual an informal textual convention.
convention.
(4) For any object which represents a measurement in some kind of (4) For any object which represents a measurement in some kind of
units, it is recommended that a UNITS clause be added to the units, a UNITS clause SHOULD be added to the definition of that
definition of that object. object.
(5) For any conceptual row which is an extension of another conceptual (5) For any conceptual row which is an extension of another conceptual
row, i.e., for which subordinate columnar objects both exist and row, i.e., for which subordinate columnar objects both exist and
are identified via the same semantics as the other conceptual row, are identified via the same semantics as the other conceptual row,
it is recommended that an AUGMENTS clause be used in place of the an AUGMENTS clause SHOULD be used in place of the INDEX clause for
INDEX clause for the object corresponding to the conceptual row the object corresponding to the conceptual row which is an
which is an extension. extension.
Finally, when encountering common errors in SNMPv1 MIB modules: Finally, to avoid common errors in SMIv1 MIB modules:
(1) For any non-columnar object that is instanced as if it were (1) For any non-columnar object that is instanced as if it were
immediately subordinate to a conceptual row, the value of the immediately subordinate to a conceptual row, the value of the
STATUS clause of that object is changed to "obsolete". STATUS clause of that object MUST be changed to "obsolete".
(2) For any conceptual row object that is not contained immediately (2) For any conceptual row object that is not contained immediately
subordinate to a conceptual table, the value of the STATUS clause subordinate to a conceptual table, the value of the STATUS clause
of that object (and all subordinate objects) is changed to of that object (and all subordinate objects) MUST be changed to
"obsolete". "obsolete".
2.2. Trap Definitions 2.2. Trap and Notification Definitions
If a MIB module is changed to conform to the SNMPv2 framework, then If a MIB module is changed to conform to the SMIv2, then each
each occurrence of the TRAP-TYPE macro must be changed to a occurrence of the TRAP-TYPE macro MUST be changed to a corresponding
corresponding invocation of the NOTIFICATION-TYPE macro: invocation of the NOTIFICATION-TYPE macro:
(1) The IMPORTS statement must not reference RFC-1215, and should (1) The IMPORTS statement MUST NOT reference RFC-1215 [4], and MUST
reference SNMPv2-SMI instead. reference SNMPv2-SMI instead.
(2) The ENTERPRISE clause must be removed. (2) The ENTERPRISE clause MUST be removed.
(3) The VARIABLES clause must be renamed to the OBJECTS clause. (3) The VARIABLES clause MUST be renamed to the OBJECTS clause.
(4) The STATUS clause must be added, with a value of 'current'. (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 (5) The value of an invocation of the NOTIFICATION-TYPE macro is an
OBJECT IDENTIFIER, not an INTEGER, and must be changed accordingly. OBJECT IDENTIFIER, not an INTEGER, and MUST be changed accordingly.
Specifically, if the value of the ENTERPRISE clause is not 'snmp' Specifically, if the value of the ENTERPRISE clause is not 'snmp'
then the value of the invocation is the value of the ENTERPRISE then the value of the invocation SHALL be the value of the
clause extended with two sub-identifiers, the first of which has ENTERPRISE clause extended with two sub-identifiers, the first of
the value 0, and the second has the value of the invocation of the which has the value 0, and the second has the value of the
TRAP-TYPE. invocation of the TRAP-TYPE.
(6) The DESCRIPTION clause must be added, if not already present. (6) The DESCRIPTION clause MUST be added, if not already present.
(7) One or more NOTIFICATION-GROUPs should be defined, and related (7) One or more NOTIFICATION-GROUPs SHOULD be defined, and related
notifications should be collected into those groups. notifications SHOULD be collected into those groups.
2.3. Compliance Statements 2.3. Compliance Statements
For those information modules which are "standard", a corresponding For those information modules which are "standard", a corresponding
invocation of the MODULE-COMPLIANCE macro must be included within the invocation of the MODULE-COMPLIANCE macro and related OBJECT-GROUP
information module (or in a companion information module), and any macros MUST be included within the information module (or in a
commentary text in the information module which relates to compliance companion information module), and any commentary text in the
must be removed. Typically this editing can occur when the information module which relates to compliance SHOULD be removed.
information module undergoes review. Typically this editing can occur when the information module
undergoes review.
2.4. Capabilities Statements 2.4. Capabilities Statements
In the SNMPv1 framework, the informational document [11] uses the In the SMIv1, RFC1303 [5] uses the MODULE-CONFORMANCE macro to
MODULE-CONFORMANCE macro to describe an agent's capabilities with describe an agent's capabilities with respect to one or more MIB
respect to one or more MIB modules. Converting such a description modules. Converting such a description for use with the SMIv2
for use with the SNMPv2 framework requires these changes: requires these changes:
(1) Use the macro name AGENT-CAPABILITIES instead of MODULE- (1) The macro name AGENT-CAPABILITIES MUST be used instead of MODULE-
CONFORMANCE. CONFORMANCE.
(2) The STATUS clause must be added, with a value of 'current'. (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.
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.)
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 (3) All occurrences of the CREATION-REQUIRES clause MUST either be
generated. omitted if appropriate, or be changed such that the semantics are
consistent with RFC1904 [9].
SNMPv1 MIB instrumentation will generate SNMPv1 error-status values, In order to ease coexistence, object groups defined in an SMIv1
will never generate exception codes nor use the Counter64 data type, compliant MIB module may be referenced by the INCLUDES clause of an
and will provide SNMPv1 format parameters for generating invocation of the AGENT-CAPABILITIES macro: upon encountering a
notifications. reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB
module, all leaf objects which are subordinate to the subtree and
have a STATUS clause value of mandatory are deemed to be INCLUDEd.
(Note that this method is ambiguous when different revisions of an
SMIv1 MIB have different sets of mandatory objects under the same
subtree; in such cases, the only solution is to rewrite the MIB using
the SMIv2 in order to define the object groups unambiguously.)
SNMPv2 MIB instrumentation will generate SNMPv2 error-status values, 3. Translating Notifications Parameters
will generate exception codes, will use the Counter64 data type, and
will provide SNMPv2 format parameters for generating notifications.
4. Translating Notifications Between SNMP Formats 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.'
This section describes how data contained in a notification is The SMI version used to define a notification will usually determine
translated between the SNMPv1 format and the SNMPv2 format. There which type of notification parameters are provided by MIB
are two parts to the format of a notification, the SMI version used instrumentation when a notification is generated.
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 The situations where notification parameters MUST be translated are:
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 - When MIB instrumentation in an entity generates a set of
notification parameters using one SNMP format, and the notification parameters in a particular format, and the
configuration of the entity indicates that the notification configuration of the entity indicates that the notification
must be sent using a protocol version that requires must be sent using an SNMP message version that requires the
notification parameters in the other SNMP format. other format for notification parameters.
- When a proxy receives a notification in one SNMP format, and - When a proxy receives a notification that was sent using an
must forward the notification using a protocol version that SNMP message version that requires one format of notification
requires a different SNMP format. 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 addition, it MAY be desirable to translate notification parameters
in a notification receiver application in order to present in a notification receiver application in order to present
notifications to the end user in a consistent format. notifications to the end user in a consistent format.
Note that for the purposes of this section, the format of Note that for the purposes of this section, the set of notification
notification parameters is independent of whether the notification is parameters is independent of whether the notification is to be sent
to be sent as a trap or an inform. as a trap or an inform.
SNMPv1 notification parameters consist of: SNMPv1 notification parameters consist of:
- An enterprise value (OBJECT IDENTIFIER). - An enterprise value (OBJECT IDENTIFIER).
- An agent-addr value (NetworkAddress). - An agent-addr value (NetworkAddress).
- A generic-trap value (INTEGER). - A generic-trap value (INTEGER).
- A specific-trap value (INTEGER). - A specific-trap value (INTEGER).
- A time-stamp value (TimeTicks). - A time-stamp value (TimeTicks).
- A list of variable-bindings (VarBindList). - A list of variable-bindings (VarBindList).
SNMPv2 notification parameters consist of: SNMPv2 notification parameters consist of:
- A sysUpTime value (TimeTicks). This appears in the first - A sysUpTime value (TimeTicks). This appears in the first
variable-binding in an SNMPv2 notification. variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU.
- An snmpTrapOID value (OBJECT IDENTIFIER). This appears in the - An snmpTrapOID value (OBJECT IDENTIFIER). This appears in the
second variable-binding in an SNMPv2 notification. second variable-binding in an SNMPv2-Trap-PDU or
InformRequest-PDU.
- A list of variable-bindings (VarBindList). This refers to all - A list of variable-bindings (VarBindList). This refers to all
but the first two variable-bindings in an SNMPv2 notification. but the first two variable-bindings in an SNMPv2-Trap-PDU or
InformRequest-PDU.
4.1. Translating SNMPv1 Format to SNMPv2 Format 3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification
Parameters
The following procedure describes how to translate SNMPv1 The following procedure describes how to translate SNMPv1
notification parameters into SNMPv2 notification parameters: notification parameters into SNMPv2 notification parameters:
(1) The SNMPv2 sysUpTime value is taken directly from the SNMPv1 time- (1) The SNMPv2 sysUpTime value SHALL be taken directly from the SNMPv1
stamp value. time-stamp value.
(2) If the SNMPv1 generic-trap value is 'enterpriseSpecific(6)', the (2) If the SNMPv1 generic-trap value is 'enterpriseSpecific(6)', the
SNMPv2 snmpTrapOID value is the concatentation of the SNMPv1 SNMPv2 snmpTrapOID value SHALL be the concatentation of the SNMPv1
enterprise value and two additional sub-identifiers, '0', and the enterprise value and two additional sub-identifiers, '0', and the
SNMPv1 specific-trap value. SNMPv1 specific-trap value.
(3) If the SNMPv1 generic-trap value is not 'enterpriseSpecific(6)', (3) If the SNMPv1 generic-trap value is not 'enterpriseSpecific(6)',
the SNMPv2 snmpTrapOID value is the corresponding trap as defined the SNMPv2 snmpTrapOID value SHALL be the corresponding trap as
in [RFC1907]. defined in section 2 of RFC1907 [12]:
(4) The SNMPv2 variable-bindings is the SNMPv1 variable-bindings with a generic-trap value snmpTrapOID.0
single variable-binding appended. The name portion of this ================== =============
variable binding contains snmpTrapEnterprise.0 [RFC1907], and the 0 1.3.6.1.6.3.1.1.5.1 (coldStart)
value is the SNMPv1 enterprise value. 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)
(5) The value of the agent-addr field is lost when converting (4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-bindings.
notification parameters from SNMPv1 to SNMPv2. 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 value. 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 value.
4.2. Translating SNMPv2 Format to SNMPv1 Format 3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification
Parameters
The following procedure describes how to translate SNMPv2 The following procedure describes how to translate SNMPv2
notification parameters into SNMPv1 notification parameters: notification parameters into SNMPv1 notification parameters:
(1) The SNMPv1 enterprise value is determined as follows: (1) The SNMPv1 enterprise value SHALL be determined as follows:
- If the SNMPv2 snmpTrapOID value is one of the standard traps - If the SNMPv2 snmpTrapOID value is one of the standard traps
as defined in [RFC1907], then the SNMPv1 enterprise value is as defined in RFC1907 [12], then the SNMPv1 enterprise value
set to the value of the variable-binding in the SNMPv2 SHALL be set to the value of the variable-binding in the
variable-bindings whose name is snmpTrapEnterprise.0 if that SNMPv2 variable-bindings whose name is snmpTrapEnterprise.0 if
variable-binding exists. If it does not exist, the SNMPv1 that variable-binding exists. If it does not exist, the
enterprise value is set to the value 'snmpTraps' as defined in SNMPv1 enterprise value SHALL be set to the value 'snmpTraps'
RFC1907 [RFC1907]. as defined in RFC1907 [12].
- If the SNMPv2 snmpTrapOID value is not one of the standard - If the SNMPv2 snmpTrapOID value is not one of the standard
traps as defined in [RFC1907], then the SNMPv1 enterprise traps as defined in RFC1907 [12], then the SNMPv1 enterprise
value is set to the SNMPv2 snmpTrapOID value as follows: value SHALL be set to the SNMPv2 snmpTrapOID value as follows:
- If the next-to-last sub-identifier of the snmpTrapOID is - If the next-to-last sub-identifier of the snmpTrapOID is
zero, then the SMIv1 enterprise is the SMIv2 snmpTrapOID zero, then the SMIv1 enterprise SHALL be the SMIv2
with the last 2 sub-identifiers removed, otherwise snmpTrapOID with the last 2 sub-identifiers removed,
otherwise
- If the next-to-last sub-identifier of the snmpTrapOID is - If the next-to-last sub-identifier of the snmpTrapOID is
non-zero, then the SMIv1 enterprise is the SMIv2 non-zero, then the SMIv1 enterprise SHALL be the SMIv2
snmpTrapOID with the last sub-identifier removed. snmpTrapOID with the last sub-identifier removed.
(2) The SNMPv1 agent-addr value is determined based on the situation in (2) The SNMPv1 agent-addr value SHALL be determined based on the
which the translation occurs. situation in which the translation occurs.
- If the translation occurs within a notification originator - If the translation occurs within a notification originator
application, and the notification is to be sent over UDP, the application, and the notification is to be sent over UDP, the
SNMPv1 agent-addr value is set to the IP address of the SNMP SNMPv1 agent-addr value SHALL be set to the IP address of the
entity in which the notification originator resides. If the SNMP entity in which the notification originator resides. If
notification is to be sent over some other transport, the the notification is to be sent over some other transport, the
SNMPv1 agent-addr value is set to 0.0.0.0. SNMPv1 agent-addr value SHALL be set to 0.0.0.0.
- If the translation occurs within a proxy application, the - If the translation occurs within a proxy application, the
proxy must attempt to determine the original source of the proxy must attempt to determine the original source of the
notification. If this source was an IP or UDP address, that notification. If the SNMPv2 variable-bindings contains a
address is used for the SNMPv1 agent-addr value. Otherwise, variable binding whose name is snmpTrapAddress.0, the agent-
the SNMPv1 agent-addr value is set to 0.0.0.0. addr value SHALL be set to the value of that variable binding.
Otherwise, If this source was an IP or UDP address, that
address SHALL be used for the SNMPv1 agent-addr value.
Otherwise, the SNMPv1 agent-addr value SHALL be set to
0.0.0.0.
(3) If the SNMPv2 snmpTrapOID value is one of the standard traps as (3) If the SNMPv2 snmpTrapOID value is one of the standard traps as
defined in [RFC1907], the SNMPv1 generic-trap value is set as defined in RFC1907 [12], the SNMPv1 generic-trap value SHALL be set
follows: as follows:
value of snmpTrapOID.0 generic-trap 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.1 (coldStart) 0
1.3.6.1.6.3.1.1.5.2 (warmStart) 1 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.3 (linkDown) 2
1.3.6.1.6.3.1.1.5.4 (linkUp) 3 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.5 (authenticationFailure) 4
1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5
Otherwise, the SNMPv1 generic-trap value is set to 6. Otherwise, the SNMPv1 generic-trap value SHALL be set to 6.
(4) If the SNMPv2 snmpTrapOID value is one of the standard traps as (4) If the SNMPv2 snmpTrapOID value is one of the standard traps as
defined in [RFC1907], the SNMPv1 specific-trap value is set to defined in RFC1907 [12], the SNMPv1 specific-trap value SHALL be
zero. Otherwise, the SNMPv1 specific-trap value is set to the last set to zero. Otherwise, the SNMPv1 specific-trap value SHALL be
sub-identifier of the SNMPv2 snmpTrapOID value. set to the last sub-identifier of the SNMPv2 snmpTrapOID value.
(5) The SNMPv1 time-stamp value is taken directly from the SNMPv2 (5) The SNMPv1 time-stamp value SHALL be taken directly from the SNMPv2
sysUpTime value. sysUpTime value.
(6) The SNMPv1 variable-bindings is the SNMPv2 variable-bindings with (6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-bindings
the following exceptions: 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
using other SNMP versions.
4.3.1. discussion about additional varbinds (agent_addr, community) - Any variable-binding whose type is Counter64 which exists in
the SNMPv2 variable-bindings SHALL be removed.
5. Approaches to Coexistence in a Multi-lingual Network 4. Approaches to Coexistence in a Multi-lingual Network
There are two basic approaches to coexistence in a multi-lingual There are two basic approaches to coexistence in a multi-lingual
network, multi-lingual implementations, and proxy implementations. network, multi-lingual implementations, and proxy implementations.
Multi-lingual implementations allow elements in a network to Multi-lingual implementations allow elements in a network to
communicate with each other using an SNMP version which both elements communicate with each other using an SNMP version which both elements
support. This allows a multi-lingual implentation to communicate support. This allows a multi-lingual implentation to communicate
with any mono-lingual implementation, regardless of the SNMP version with any mono-lingual implementation, regardless of the SNMP version
supported by the mono-lingual implementation. supported by the mono-lingual implementation.
Proxy implementations provide a mechanism for translating between Proxy implementations provide a mechanism for translating between
SNMP versions using a third party network element. This allows SNMP versions using a third party network element. This allows
network elements which support only a single, but different, SNMP network elements which support only a single, but different, SNMP
version to communicate with each other. Proxy implementations are version to communicate with each other. Proxy implementations are
also useful for securing communications over an insecure link between also useful for securing communications over an insecure link between
two locally secure networks. two locally secure networks.
5.1. Multi-lingual implementations 4.1. Multi-lingual implementations
This approach requires an entity to support multiple SNMP message This approach requires an entity to support multiple SNMP message
formats. Typically this means supporting SNMPv1, SNMPv2c, and SNMPv3 versions. Typically this means supporting SNMPv1, SNMPv2c, and
message formats. The behaviour of various types of SNMPv3 SNMPv3 message versions. The behaviour of various types of SNMP
applications which support multiple message formats is described in applications which support multiple message versions is described in
the following sections. This approach allows entities which support the following sections. This approach allows entities which support
multiple SNMP message formats to coexist with and communicate with multiple SNMP message versions to coexist with and communicate with
entities which support only a single SNMP message format. entities which support only a single SNMP message version.
5.1.1. Command Generator 4.1.1. Command Generator
A command generator must select an appropriate message format when A command generator must select an appropriate message version when
sending requests to another entity. One way to achieve this is to sending requests to another entity. One way to achieve this is to
consult a local database to select the appropriate message format. consult a local database to select the appropriate message version.
In addition, a command generator should 'downgrade' GetBulk requests In addition, a command generator should 'downgrade' GetBulk requests
to GetNext requests when selecting SNMPv1 as the message format for to GetNext requests when selecting SNMPv1 as the message version for
an outgoing request. an outgoing request.
5.1.2. Command Responder 4.1.2. Command Responder
A command responder must be able to deal with MIB instrumentation A command responder must be able to deal with MIB instrumentation
that is written using both the SNMPv1 and SNMPv2. There are three that is written using both the SNMPv1 and SNMPv2. There are three
aspects to dealing with this. A command responder must: aspects to dealing with this. A command responder must:
- Deal correctly with SNMPv2 MIB instrumentation that returns a - Deal correctly with SNMPv2 MIB instrumentation that returns a
Counter64 value while processing an SNMPv1 message, Counter64 value while processing an SNMPv1 message,
- Deal correctly with SNMPv2 instrumentation that returns one of - Deal correctly with SNMPv2 MIB instrumentation that returns
the three exception values while processing an SNMPv1 message, one of the three exception values while processing an SNMPv1
message, and
- Map SNMPv2 error codes returned from SNMPv2 instrumentation - Map SNMPv2 error codes returned from SNMPv2 MIB
into SNMPv1 error code when processing an SNMPv1 message, and instrumentation into SNMPv1 error code when processing an
SNMPv1 message.
Note that SNMPv1 error codes can be used without any change when Note that SNMPv1 error codes can be used without any change when
processing SNMPv2c or SNMPv3 messages. 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
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.
6. Multi-Lingual Command Responder Behaviour
The following sections describe the behaviour of a command responder The following sections describe the behaviour of a command responder
application which supports multiple SNMP message formats, and which application which supports multiple SNMP message versions, and which
has access to some combination of SNMPv1 and SNMPv2 MIB has access to some combination of SNMPv1 and SNMPv2 MIB
instrumentation. instrumentation.
6.1. Mapping SMIv2 into SMIv1 4.1.2.1. Handling Counter64
The SMIv2 [RFC1902] defines one new syntax that is incompatible with The SMIv2 [7] defines one new syntax that is incompatible with SMIv1.
SMIv1. This syntax is Counter64. All other syntaxes defined by This syntax is Counter64. All other syntaxes defined by SMIv2 are
SMIv2 are compatible with SMIv1. compatible with SMIv1.
The impact on multi-lingual command responders is that they should The impact on multi-lingual command responders is that they MUST NOT
make sure that they never return a variable binding containing a ever return a variable binding containing a Counter64 value in a
Counter64 value in a response to a request that was received using response to a request that was received using the SNMPv1 message
the SNMPv1 message format. version.
Multi-lingual command responders should take the approach that object Multi-lingual command responders SHALL take the approach that object
instances whose type is Counter64 are implicitly excluded from view instances whose type is Counter64 are implicitly excluded from view
when processing an SNMPv1 message. So: when processing an SNMPv1 message. So:
- On an SNMPv1 GET request, we return an error-status of - On an SNMPv1 GET request, an error-status of noSuchName SHALL
noSuchName and the error-index is set to the variable binding be returned, and the error-index SHALL be set to the variable
that causes this error. binding that caused this error.
- On an SNMPv1 GETNEXT request, we skip the object instance and - On an SNMPv1 GETNEXT request, any object instance which
fetch the next object instance that follows the one with a contains a syntax of Counter64 shall be skipped, and the next
syntax of Counter64. 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.
- Any SET request that has a variable binding with a Counter64 - Any SET request that has a variable binding with a Counter64
value must have come from a SNMPv2 manager, and so it should 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 not cause a problem. However, if an object with SYNTAX of
SNMPv1 SET packet, it should result in an ASN.1 parse error Counter64 is received in an SNMPv1 SET packet, it SHALL result
since Counter64 is not valid in the SNMPv1 protocol. When an in an ASN.1 parse error since Counter64 is not valid in the
ASN.1 parse error occurs, the counter snmpInASNParseErrs is SNMPv1 protocol. When an ASN.1 parse error occurs, the counter
incremented and no response is returned. snmpInASNParseErrs SHALL be incremented and no response is
returned.
6.2. Mapping SNMPv2 Exceptions 4.1.2.2. Mapping SNMPv2 Exceptions
SNMPv2 provides a feature called exceptions, which allow an SNMPv2 SNMPv2 provides a feature called exceptions, which allow an SNMPv2
Response PDU to return as much management information as possible, Response PDU to return as much management information as possible,
even when an error occurs. However, SNMPv1 does not support even when an error occurs. However, SNMPv1 does not support
exceptions, and so an SNMPv1 Response PDU cannot return any exceptions, and so an SNMPv1 Response PDU cannot return any
management information, and can only return an error-status and management information, and can only return an error-status and
error-index value. error-index value.
When an SNMPv1 request is received, a command responder must check When an SNMPv1 request is received, a command responder MUST check
any variable bindings returned from SNMPv2 compliant instrumentation any variable bindings returned from SNMPv2 MIB instrumentation for
for exception values, and convert these exception values into SNMPv1 exception values, and convert these exception values into SNMPv1
error codes. error codes.
The type of exception that can be returned from instrumentation and The type of exception that can be returned from MIB instrumentation
the action taken depends on the type of SNMP request. and the action taken depends on the type of SNMP request.
- For a GetRequest, a noSuchObject or noSuchInstance exception - For a GetRequest, a noSuchObject or noSuchInstance exception
may be returned. may be returned.
- For a GetNextRequest, an endOfMibView exception may be - For a GetNextRequest, an endOfMibView exception may be
returned. returned.
- No exceptions will be returned for a SetRequest, and a - No exceptions will be returned for a SetRequest, and a
GetBulkRequest should only be received in an SNMPv2c or SNMPv3 GetBulkRequest should only be received in an SNMPv2c or SNMPv3
message, so these request types may be ignored when mapping message, so these request types may be ignored when mapping
exceptions. exceptions.
6.2.1. Mapping nosuchObject and noSuchInstance 4.1.2.2.1. Mapping nosuchObject and noSuchInstance
A noSuchObject or noSuchInstance exception generated by SNMPv2 A noSuchObject or noSuchInstance exception generated by SNMPv2 MIB
compliant instrumentation indicates that the requested object instrumentation indicates that the requested object instance can not
instance can not be returned. The SNMPv1 error code for this be returned. The SNMPv1 error code for this condition is noSuchName,
condition is noSuchName, and so the error-status field of the and so the error-status field of the response PDU SHALL be set to
response PDU should be set to noSuchName. Also, the error-index noSuchName. Also, the error-index field SHALL be set to the index of
field is set to the index of the variable binding for which an the variable binding for which an exception occurred, and the
exception occurred, and the variable binding list from the original variable binding list from the original request SHALL be returned
request is returned with the response PDU. with the response PDU.
Note that when a response contains multiple exceptions, it is an Note that when a response contains multiple exceptions, it is an
implementation choice as to which variable binding the error-index implementation choice as to which variable binding the error-index
should reference. should reference.
6.2.2. Mapping endOfMibView 4.1.2.2.2. Mapping endOfMibView
When SNMPv2 compliant instrumentation returns a variable binding When SNMPv2 MIB instrumentation returns a variable binding containing
containing an endOfMibView exception, it indicates that there are no an endOfMibView exception, it indicates that there are no object
object instances available which lexicographically follow the object instances available which lexicographically follow the object in the
in the request. In an SNMPv1 agent, this condition normally results request. In an SNMPv1 agent, this condition normally results in a
in a noSuchName error, and so the error-status field of the response noSuchName error, and so the error-status field of the response PDU
PDU should be set to noSuchName. Also, the error- index field is set 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, to the index of the variable binding for which an exception occurred,
and the variable binding list from the original request is returned and the variable binding list from the original request SHALL be
with the response PDU. returned with the response PDU.
Note that when a response contains multiple exceptions, it is an Note that when a response contains multiple exceptions, it is an
implementation choice as to which variable binding the error-index implementation choice as to which variable binding the error-index
should reference. should reference.
6.3. Processing An SNMPv1 GetRequest 4.1.2.3. Processing An SNMPv1 GetRequest
When processing an SNMPv1 GetRequest, the following procedures should When processing an SNMPv1 GetRequest, the following procedures MUST
be followed when calling SNMPv2 MIB instrumentation. be followed when calling SNMPv2 MIB instrumentation.
When such instrumentation returns response data using SNMPv2 syntax When such MIB instrumentation returns response data using SNMPv2
and error-status values, then: syntax and error-status values, then:
(1) If the error-status is anything other than noError, (1) If the error-status is anything other than noError,
- The error status is translated to an SNMPv1 error-status using - The error status SHALL be translated to an SNMPv1 error-status
the table in section 7, "Mapping SNMPv2 error-status into using the table in section 4.3, "Error Status Mappings".
SNMPv1 error-status"
- The error-index is set to the position (in the original - The error-index SHALL be set to the position (in the original
request) of the variable binding that caused the error-status. request) of the variable binding that caused the error-status.
- The variable binding list of the response PDU is made exactly - The variable binding list of the response PDU SHALL be made
the same as the variable binding list that was received in the exactly the same as the variable binding list that was
original request. received in the original request.
(2) If the error-status is noError, then find any variable binding that (2) If the error-status is noError, the variable bindings SHALL be
contains an SNMPv2 exception (noSuchObject or noSuchInstance) or an checked for any SNMPv2 exception (noSuchObject or noSuchInstance)
SNMPv2 syntax that is unknown to SNMPv1 (Counter64). (Note that if or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64). If
there are more than one, the agent may choose any such variable there are any such variable bindings, one of those variable
binding.) If there are any such variable bindings, then for the bindings SHALL be selected (it is an implementation choice as to
one chosen: which is selected), and:
- Set the error-status to noSuchName - The error-status SHALL be set to noSuchName,
- Set the error-index to the position (in the variable binding - The error-index SHALL be set to the position (in the variable
list of the original request) of the variable binding that binding list of the original request) of the selected variable
returned such an SNMPv2 exception or syntax. binding, and
- Make the variable binding list of the response PDU exactly the - The variable binding list of the response PDU SHALL be exactly
same as the variable binding list that was received in the the same as the variable binding list that was received in the
original request. original request.
(3) If there are no such variable bindings, then: (3) If there are no such variable bindings, then:
- Set the error-status to noError - The error-status SHALL be set to noError,
- Set the error-index to zero - The error-index SHALL be set to zero, and
- Compose the variable binding list of the response, using the - The variable binding list of the response SHALL be composed
data as it is returned by the instrumentation code. from the data as it is returned by the MIB instrumentation.
6.4. Processing An SNMPv1 GetNextRequest 4.1.2.4. Processing An SNMPv1 GetNextRequest
When processing an SNMPv1 GetNextRequest, the following procedures When processing an SNMPv1 GetNextRequest, the following procedures
should be followed when SNMPv2 MIB instrumentation is called as part MUST be followed when SNMPv2 MIB instrumentation is called as part of
of processing the request. There may be repetitive calls to processing the request. There may be repetitive calls to (possibly
(possibly different pieces of) instrumentation code to try to find different pieces of) MIB instrumentation to try to find the first
the first object which lexicographically follows each of the objects object which lexicographically follows each of the objects in the
in the request. This is implementation specific. These procedures request. This is implementation specific. These procedures are
are followed only for data returned from SNMPv2 instrumentation. followed only for data returned from SNMPv2 MIB instrumentation.
Data returned from SNMPv1 instrumentation may be treated in the Data returned from SNMPv1 MIB instrumentation may be treated in the
normal manner for an SNMPv1 request. normal manner for an SNMPv1 request.
First, if the instrumentation returns an error-status of anything First, if the MIB instrumentation returns an error-status of anything
other than noError: other than noError:
(1) The error status is translated to an SNMPv1 error-status using the (1) The error status SHALL be translated to an SNMPv1 error-status
table in section 7, "Mapping SNMPv2 error-status into SNMPv1 using the table in section 4.3, "Error Status Mappings".
error-status"
(2) The error-index is set to the position (in the original request) of (2) The error-index SHALL be set to the position (in the original
the variable binding that caused the error-status. request) of the variable binding that caused the error-status.
(3) The variable binding list of the response PDU is made exactly the (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 same as the variable binding list that was received in the original
request. request.
Otherwise, if the instrumentation returns an error-status of noError: Otherwise, if the MIB instrumentation returns an error-status of
noError:
(1) If there are any variable bindings containing an SNMPv2 syntax of (1) Any variable bindings containing an SNMPv2 syntax of Counter64
Counter64, then consider these variable bindings to be not in view SHALL be considered to be not in view, and the MIB instrumentation
and repeat the call to the instrumentation code as often as needed SHALL be called as often as is required until either a value other
until a value other than Counter64 is returned. than Counter64 is returned, or an error occurs.
(2) Find any variable binding that contains an SNMPv2 exception (2) If there is any variable binding that contains an SNMPv2 exception
endOfMibView. (Note that if there are more than one, the agent may endOfMibView (there may be more than one, it is an implementation
choose any such variable binding.) If there are any such variable decision as to which is chosen):
bindings, then for the one chosen:
- Set the error-status to noSuchName - The error-status SHALL be set to noSuchName,
- Set the error-index to the position (in the variable binding - The error-index SHALL be set to the position (in the variable
list of the original request) of the variable binding that binding list of the original request) of the variable binding
returned such an SNMPv2 exception. that returned such an SNMPv2 exception, and
- Make the variable binding list of the response PDU exactly the - The variable binding list of the response PDU SHALL be exactly
same as the variable binding list that was received in the the same as the variable binding list that was received in the
original request. original request.
(3) If there are no such variable bindings, then: (3) If there are no such variable bindings, then:
- Set the error-status to noError - The error-status SHALL be set to noError,
- Set the error-index to zero - The error-index SHALL be set to zero, and
- Compose the variable binding list of the response, using the - The variable binding list of the response SHALL be composed
data as it is returned by the instrumentation code. from the data as it is returned by the MIB instrumentation.
7. Error Status Mappings 4.1.3. Notification Originator
The following table shows the mappings of SNMPv2 error-status values A notification originator must be able to translate between SNMPv1
into SNMPv1 error-status values. 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
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.
SNMPv2 error-status SNMPv1 error-status 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 notificaton 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:
- 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.
- 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.
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 noError noError
tooBig tooBig tooBig tooBig
noSuchName noSuchName noSuchName noSuchName
badValue badValue badValue badValue
readOnly readOnly genErr genErr
SNMPv2 error-status SNMPv1 error-status
=================== ===================
noError noError
tooBig tooBig
genErr genErr genErr genErr
wrongValue badValue wrongValue badValue
wrongEncoding badValue wrongEncoding badValue
wrongType badValue wrongType badValue
wrongLength badValue wrongLength badValue
inconsistentValue badValue inconsistentValue badValue
noAccess noSuchName noAccess noSuchName
notWritable noSuchName notWritable noSuchName
noCreation noSuchName noCreation noSuchName
inconsistentName noSuchName inconsistentName noSuchName
resourceUnavailable genErr resourceUnavailable genErr
commitFailed genErr commitFailed genErr
undoFailed genErr undoFailed genErr
authorizationError noSuchName authorizationError noSuchName
8. Message Processing Models and Security Models 5. Message Processing Models and Security Models
In order to adapt SNMPv1 and SNMPv2c into the SNMPv3 architecture, four In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture, the
additional models must be defined: following models must be defined:
- The SNMPv1 Message Processing Model - The SNMPv1 Message Processing Model
- The SNMPv2c Message Processing Model
- The SNMPv1 Community-Based Security 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 - The SNMPv2c Community-Based Security Model
In most respects, the SNMPv1 Message Processing Model and the In most respects, the SNMPv1 Message Processing Model and the
SNMPv2c Message Processing Model are identical, and so these SNMPv2c Message Processing Model are identical, and so these
are not discussed independently in this document. Differences are not discussed independently in this document. Differences
between the two models are described as required. between the two models are described as required.
Similarly, the SNMPv1 Community-Based Security Model and the Similarly, the SNMPv1 Community-Based Security Model and the
SNMPv2c Community-Based Security Model are nearly identical, SNMPv2c Community-Based Security Model are nearly identical,
and so are not discussed independently. Differences between and so are not discussed independently. Differences between
these two models are also described as required. these two models are also described as required.
8.1. Mappings 5.1. Mappings
The SNMPv1 and SNMPv2c Message Processing Models and Security Models The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model
require mappings between parameters used in SNMPv1 and SNMPv2c messages, require mappings between parameters used in SNMPv1 (and SNMPv2c)
and those use in SNMPv3 messages. The parameters which must be mapped messages, and the version independent parameters used in the SNMP
consist of the SNMPv1 and SNMPv2c community name, and the SNMPv3 architecture [16]. The parameters which MUST be mapped consist of the
securityName and contextEngineID/contextName pair. A MIB module (the SNMPv1 (and SNMPv2c) community name, and the SNMP securityName and
SNMP-COMMUNITY-MIB) is provided in this document in order to perform contextEngineID/contextName pair. A MIB module (the SNMP-COMMUNITY-MIB)
these mappings. This MIB provides mappings in both directions, that is, is provided in this document in order to perform these mappings. This
a community name may be mapped to a securityName, contextEngineID, and MIB provides mappings in both directions, that is, a community name may
contextName, or the combination of securityName, contextEngineID, and be mapped to a securityName, contextEngineID, and contextName, or the
contextName may be mapped to a community name. combination of securityName, contextEngineID, and contextName may be
mapped to a community name.
8.2. Elements Of Procedure 5.2. The SNMPv1 Message Processing Model
The following sections describe the procedures for processing various The SNMPv1 Message Processing Model handles processing of SNMPv1
types of SNMPv1 and SNMPv2c messages. 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
SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for
SNMPv2c is 1).
8.2.1. Processing An Incoming Request 5.2.1. Processing An Incoming Request
8.2.2. Processing An Outgoing Response 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:
8.2.3. Processing An Incoming Notification - The messageProcessingModel, which will be 0 (or 1 for
SNMPv2c).
8.2.4. Processing An Outgoing Notification - 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).
8.3. Community MIB - 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].
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.
- 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
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.
This 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, snmpTargetAddrTMask, 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
snmpTargetAddrTMask must always be an OCTET STRING of the same length
as the snmpTargetAddrTAddress.
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 transport
address. If all such bits match, the transport address is matched by
that snmpTargetAddrTable entry. Otherwise, the transport address is
not matched.
SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
IpAddress
FROM RFC1155-SMI
MODULE-IDENTITY, MODULE-IDENTITY,
OBJECT-TYPE, OBJECT-TYPE,
Integer32, Integer32,
Counter32, Counter32,
UInteger32 UInteger32
FROM SNMPv2-SMI FROM SNMPv2-SMI
RowStatus, RowStatus,
TestAndIncr, TestAndIncr,
StorageType StorageType
FROM SNMPv2-TC FROM SNMPv2-TC
skipping to change at page 29, line 19 skipping to change at page 33, line 6
E-mail: Rob.Frye@mci.com E-mail: Rob.Frye@mci.com
Phone: +1 703 715 7225 Phone: +1 703 715 7225
Co-editor: David B. Levi Co-editor: David B. Levi
SNMP Research, Inc. SNMP Research, Inc.
Postal: 3001 Kimberlin Heights Road Postal: 3001 Kimberlin Heights Road
Knoxville, TN 37920-9716 Knoxville, TN 37920-9716
E-mail: levi@snmp.com E-mail: levi@snmp.com
Phone: +1 423 573 1434 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 Co-editor: Bert Wijnen
IBM T. J. Watson Research IBM T. J. Watson Research
postal: Schagen 33 postal: Schagen 33
3461 GL Linschoten 3461 GL Linschoten
Netherlands Netherlands
email: wijnen@vnet.ibm.com email: wijnen@vnet.ibm.com
phone: +31-348-432-794 phone: +31-348-432-794
" "
DESCRIPTION DESCRIPTION
"This MIB module defines objects to help support coexistence "This MIB module defines objects to help support coexistence
between SNMPv1, SNMPv2, and SNMPv3." between SNMPv1, SNMPv2, and SNMPv3."
::= { snmpModules xxx } -- get assignment from IANA ::= { snmpModules 18 }
-- Administrative assignments **************************************** -- Administrative assignments ****************************************
snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 } snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 }
snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 } snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 }
-- --
-- The snmpCommunityTable contains a database of community strings. -- The snmpCommunityTable contains a database of community strings.
-- This table provides mappings between community strings, and the -- This table provides mappings between community strings, and the
-- parameters required for View-based Access Control. -- parameters required for View-based Access Control.
skipping to change at page 30, line 16 skipping to change at page 34, line 10
snmpCommunityEntry OBJECT-TYPE snmpCommunityEntry OBJECT-TYPE
SYNTAX SnmpCommunityEntry SYNTAX SnmpCommunityEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Information about a particular community string." "Information about a particular community string."
INDEX { snmpCommunityIndex } INDEX { snmpCommunityIndex }
::= { snmpCommunityTable 1 } ::= { snmpCommunityTable 1 }
SnmpCommunityEntry ::= SEQUENCE { SnmpCommunityEntry ::= SEQUENCE {
snmpCommunityIndex Integer32, snmpCommunityIndex SnmpAdminString,
snmpCommunityName OCTET STRING, snmpCommunityName OCTET STRING,
snmpCommunitySecurityName SnmpAdminString, snmpCommunitySecurityName SnmpAdminString,
snmpCommunityContextEngineID SnmpEngineID, snmpCommunityContextEngineID SnmpEngineID,
snmpCommunityContextName SnmpAdminString, snmpCommunityContextName SnmpAdminString,
snmpCommunityTransportTag SnmpTagValue, snmpCommunityTransportTag SnmpTagValue,
snmpCommunityStorageType StorageType, snmpCommunityStorageType StorageType,
snmpCommunityStatus RowStatus snmpCommunityStatus RowStatus
} }
snmpCommunityIndex OBJECT-TYPE snmpCommunityIndex OBJECT-TYPE
SYNTAX Integer32 SYNTAX SnmpAdminString (SIZE(1..128))
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The unique index value of a row in this table." "The unique index value of a row in this table."
::= { snmpCommunityEntry 1 } ::= { snmpCommunityEntry 1 }
snmpCommunityName OBJECT-TYPE snmpCommunityName OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(1..64)) SYNTAX OCTET STRING (SIZE(1..64))
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
skipping to change at page 31, line 31 skipping to change at page 35, line 25
SYNTAX SnmpAdminString SYNTAX SnmpAdminString
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The context in which management information is accessed "The context in which management information is accessed
when using the community string specified by the corresponding when using the community string specified by the corresponding
instance of snmpCommunityName." instance of snmpCommunityName."
DEFVAL { ''H } -- the empty string DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 5 } ::= { 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 snmpCommunityTransportTag OBJECT-TYPE
SYNTAX SnmpTagValue SYNTAX SnmpTagValue
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This object specifies a set of transport endpoints "This object specifies a set of transport endpoints
from which an agent will accept management requests. from which an agent will accept management requests.
If a management request containing this community If a management request containing this community
is received on a transport endpoint other than the is received on a transport endpoint other than the
transport endpoints identified by this object, the transport endpoints identified by this object, the
request is deemed unauthentic. request is deemed unauthentic.
The transports identified by this object are specified The transports identified by this object are specified
in the snmpTargteAddrTable. Entries in that table in the snmpTargetAddrTable. Entries in that table
whose snmpTargetAddrTagList contains this tag value whose snmpTargetAddrTagList contains this tag value
are identified. are identified.
If the value of this object has zero-length, transport If the value of this object has zero-length, transport
endpoints are not checked when authenticating messages endpoints are not checked when authenticating messages
containing this community string." containing this community string."
DEFVAL { ''H } -- the empty string DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 6 } ::= { snmpCommunityEntry 6 }
snmpCommunityStorageType OBJECT-TYPE snmpCommunityStorageType OBJECT-TYPE
skipping to change at page 32, line 39 skipping to change at page 36, line 26
DESCRIPTION DESCRIPTION
"The status of this conceptual row in the snmpCommunityTable. "The status of this conceptual row in the snmpCommunityTable.
An entry in this table is not qualified for activation An entry in this table is not qualified for activation
until instances of all corresponding columns have been until instances of all corresponding columns have been
initialized, either through default values, or through initialized, either through default values, or through
Set operations. The snmpCommunityName and Set operations. The snmpCommunityName and
snmpCommunitySecurityName objects must be explicitly set." snmpCommunitySecurityName objects must be explicitly set."
::= { snmpCommunityEntry 8 } ::= { snmpCommunityEntry 8 }
--
-- The snmpTargetAddrMaskTable augments the snmpTargetAddrTable with
-- a transport address mask value. This allows entries in the
-- snmpTargetAddrTable to define a set of addresses instead of just
-- a single address.
--
snmpTargetAddrMaskTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpTargetAddrMaskEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of mask values associated with the
snmpTargetAddrTable."
::= { snmpCommunityMIBObjects 2 }
snmpTargetAddrMaskEntry OBJECT-TYPE
SYNTAX SnmpTargetAddrMaskEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular mask value."
AUGMENTS { snmpTargetAddrEntry }
::= { snmpTargetAddrMaskTable 1 }
SnmpTargetAddrMaskEntry ::= SEQUENCE {
snmpTargetAddrTMask OCTET STRING
}
snmpTargetAddrTMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (1..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The mask value associated with an entry in the
snmpTargetAddrTable. The value of this object must
be the same length as the corresponding instance of
snmpTargetAddrTAddress.
The value of this object must be set before the
corresponding value of snmpTargetAddrRowStatus may
be set to active(1).
This object may not be set while the value of the
corresponding instance of snmpTargetAddrRowStatus
is active(1)."
::= { snmpTargetAddrMaskEntry 1 }
--
-- 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
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 ******************************************* -- Conformance Information *******************************************
snmpCommunityMIBCompliances OBJECT IDENTIFIER snmpCommunityMIBCompliances OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 1 } ::= { snmpCommunityMIBConformance 1 }
snmpCommunityMIBGroups OBJECT IDENTIFIER snmpCommunityMIBGroups OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 2 } ::= { snmpCommunityMIBConformance 2 }
-- Compliance statements -- Compliance statements
snmpCommunityMIBCompliance MODULE-COMPLIANCE snmpCommunityMIBCompliance MODULE-COMPLIANCE
skipping to change at page 33, line 29 skipping to change at page 39, line 4
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
OBJECT snmpCommunityContextEngineID OBJECT snmpCommunityContextEngineID
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
OBJECT snmpCommunityContextName OBJECT snmpCommunityContextName
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
OBJECT snmpCommunityTransportTag
OBJECT snmpCommunityTransportLabel
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
OBJECT snmpCommunityStorageType OBJECT snmpCommunityStorageType
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
OBJECT snmpCommunityStatus OBJECT snmpCommunityStatus
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
::= { usmMIBCompliances 1 } ::= { snmpCommunityMIBCompliances 1 }
snmpCommunityGroup OBJECT-GROUP snmpCommunityGroup OBJECT-GROUP
OBJECTS { OBJECTS {
snmpCommunityIndex, snmpCommunityIndex,
snmpCommunityName, snmpCommunityName,
snmpCommunitySecurityName, snmpCommunitySecurityName,
snmpCommunityContextEngineID, snmpCommunityContextEngineID,
snmpCommunityContextName, snmpCommunityContextName,
snmpCommunityTransportLabel, snmpCommunityTransportTag,
snmpCommunityStorageType, snmpCommunityStorageType,
snmpCommunityStatus snmpCommunityStatus,
snmpTargetAddrTMask
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A collection of objects providing for configuration "A collection of objects providing for configuration
of community strings for SNMPv1 or SNMPv2c usage." of community strings for SNMPv1 (and SNMPv2c) usage."
::= { snmpCommunityMIBGroups 1 } ::= { snmpCommunityMIBGroups 1 }
END END
9. Intellectual Property 6. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
skipping to change at page 36, line 5 skipping to change at page 41, line 5
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
10. Acknowledgments 7. Acknowledgments
This document is the result of the efforts of the SNMPv3 Working This document is the result of the efforts of the SNMPv3 Working
Group. Some special thanks are in order to the following SNMPv3 WG Group. The design of the SNMP-COMMUNITY-MIB incorporates work done
members: by the authors of SNMPv2*:
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*:
Jeff Case (SNMP Research, Inc.) Jeff Case (SNMP Research, Inc.)
David Harrington (Cabletron Systems Inc.) David Harrington (Cabletron Systems Inc.)
David Levi (SNMP Research, Inc.) David Levi (SNMP Research, Inc.)
Keith McCloghrie (Cisco Systems)
Brian O'Keefe (Hewlett Packard) Brian O'Keefe (Hewlett Packard)
Marshall T. Rose (Dover Beach Consulting)
Jon Saperia (BGS Systems Inc.) Jon Saperia (BGS Systems Inc.)
Steve Waldbusser (International Network Services) Steve Waldbusser (International Network Services)
Glenn W. Waters (Bell-Northern Research Ltd.)
11. Security Considerations 8. Security Considerations
Although SNMPv1 and SNMPv2 do not provide any security, allowing Although SNMPv1 and SNMPv2 do not provide any security, allowing
community names to be mapped into securityName/contextName provides community names to be mapped into securityName/contextName provides
the ability to use view-based access control to limit the access of the ability to use view-based access control to limit the access of
unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for
network administrators to make use of this capability in order to network administrators to make use of this capability in order to
avoid unauthorized access to MIB data that would otherwise be secure. avoid unauthorized access to MIB data that would otherwise be secure.
12. References 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 in inaccessible
when using the 'public' community string.
[RFC1155] When a proxy implementation translates messages between SNMPv1 (or
Rose, M. and K. McCloghrie, "Structure and Identification of 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.
9. References
[1] Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets"", STD16, RFC Management Information for TCP/IP-based internets"", STD16, RFC
1155, May 1990. 1155, May 1990.
[RFC1157] [2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
Management Protocol", STD15, RFC 1157, SNMP Research, Performance Management Protocol", STD15, RFC 1157, SNMP Research, Performance
Systems International, Performance Systems International, MIT Systems International, Performance Systems International, MIT
Laboratory for Computer Science, May 1990. Laboratory for Computer Science, May 1990.
[RFC1212] [3] McCloghrie, K., and M. Rose, Editors, "Concise MIB Definitions",
McCloghrie, K., and M. Rose, Editors, "Concise MIB Definitions.nr STD 16, RFC 1212, Hughes LAN Systems, Performance Systems
_F 1 q, STD 16, RFC 1212, Hughes LAN Systems, Performance Systems
International, March 1991. International, March 1991.
[RFC1213] [4] Rose, M. T., "A Convention for Defining Traps for use with the
McCloghrie, K., and M. Rose, Editors, "Management Information Base SNMP", RFC 1215, March 1991.
for Network Management of TCP/IP-based internets: MIB-II", STD 17,
RFC 1213, Hughes LAN Systems, Performance Systems International,
March 1991.
[RFC1901] [5] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP-
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. based Agents", RFC 1303, Hughes LAN Systems, Dover Beach
Waldbusser, "Introduction to Community-based SNMPv2", RFC1902, SNMP 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., Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996. International Network Services, January 1996.
[RFC1902] [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Structure of Management Information for Version 2 of Waldbusser, "Structure of Management Information for Version 2 of
the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996. International Network Services, January 1996.
[RFC1903] [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Textual Conventions for Version 2 of the Simple Waldbusser, "Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc., Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc.,
Cisco Systems, Inc., Dover Beach Consulting, Inc., International Cisco Systems, Inc., Dover Beach Consulting, Inc., International
Network Services, January 1996. Network Services, January 1996.
[RFC1905] [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
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 Waldbusser, "Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc.,
Cisco Systems, Inc., Dover Beach Consulting, Inc., International Cisco Systems, Inc., Dover Beach Consulting, Inc., International
Network Services, January 1996. Network Services, January 1996.
[RFC1907] [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 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 Waldbusser, "Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC1905, SNMP Simple Network Management Protocol (SNMPv2)", RFC1907, SNMP
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996. International Network Services, January 1996.
[RFC1908] [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Coexistence between Version 1 and Version 2 of the Waldbusser, "Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework", RFC1905, SNMP Internet-standard Network Management Framework", RFC1908, SNMP
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996. International Network Services, January 1996.
[RFC2271] [14] Levi, D., Wijnen, B., "Mapping SNMPv2 onto SNMPv1 within a bi-
The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An lingual SNMP agent", RFC2089, SNMP Research, Inc., IBM, January
Architecture for Describing SNMP Management Frameworks", RFC2271, 1997.
January 1998.
[RFC2272] [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B., 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-01.txt, September 1998.
[17] The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B.,
"Message Processing and Dispatching for the Simple Network "Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)", RFC2272, January 1998. Management Protocol (SNMP)", draft-ietf-snmpv3-mpc-01.txt,
September 1998.
[RFC2273] [18] The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMP
The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMPv3 Applications", draft-ietf-snmpv3-appl-v2-01.txt, September 1998.
Applications", RFC2273, January 1998.
[RFC2274] [19] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User-
The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User-
Based Security Model for Version 3 of the Simple Network Management Based Security Model for Version 3 of the Simple Network Management
Protocol (SNMP)", RFC2274, January 1998. Protocol (SNMP)", draft-ietf-snmpv3-usm-v2-02.txt, September 1998.
[RFC2275] [20] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K.,
The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K.,
"View-based Access Control Model for the Simple Network Management "View-based Access Control Model for the Simple Network Management
Protocol (SNMP)", RFC2275, January 1998. Protocol (SNMP)", draft-ietf-snmpv3-vacm-01.txt, September 1998.
13. Editor's Address 10. Editor's Address
Rob Frye Rob Frye
MCI Communications Corp. MCI Communications Corp.
2100 Reston Parkway, Suite 600 2100 Reston Parkway, Suite 600
Reston, VA 20191 Reston, VA 20191
U.S.A. U.S.A.
Phone: +1 703 715 7225 Phone: +1 703 715 7225
EMail: Rob.Frye@mci.com EMail: Rob.Frye@mci.com
David B. Levi David B. Levi
SNMP Research, Inc. SNMP Research, Inc.
3001 Kimberlin Heights Road 3001 Kimberlin Heights Road
Knoxville, TN 37920-9716 Knoxville, TN 37920-9716
U.S.A. U.S.A.
Phone: +1 423 573 1434 Phone: +1 423 573 1434
EMail: levi@snmp.com 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 Bert Wijnen
IBM T. J. Watson Research IBM T. J. Watson Research
Schagen 33 Schagen 33
3461 GL Linschoten 3461 GL Linschoten
Netherlands Netherlands
Phone: +31 348 432 794 Phone: +31 348 432 794
EMail: wijnen@vnet.ibm.com EMail: wijnen@vnet.ibm.com
A. Full Copyright Statement A. Full Copyright Statement
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
 End of changes. 222 change blocks. 
655 lines changed or deleted 948 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/