draft-ietf-snmpv3-coex-04.txt   draft-ietf-snmpv3-coex-05.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
INTERNET-DRAFT Rob Frye INTERNET-DRAFT Rob Frye
MCI WorldCom MCI WorldCom
David B. Levi David B. Levi
Nortel Networks Nortel Networks
Shawn A. Routhier Shawn A. Routhier
Integrated Systems Inc. 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-04.txt> <draft-ietf-snmpv3-coex-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. 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
skipping to change at page 4, line 5 skipping to change at page 3, line 7
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,
(SNMPv3), version 2 of the Internet-standard Network Management (SNMPv3), version 2 of the Internet-standard Network Management
Framework (SNMPv2), and the original Internet-standard Network Framework (SNMPv2), and the original Internet-standard Network
Management Framework (SNMPv1). This document obsoletes RFC 1908 [13] Management Framework (SNMPv1). This document obsoletes RFC 1908 [13]
and RFC2089 [14]. and RFC2089 [14].
Table Of Contents Table Of Contents
1 Overview ..................................................... 4
1.1 SNMPv1 ..................................................... 4
1.2 SNMPv2 ..................................................... 5
1.3 SNMPv3 ..................................................... 6
1.4 SNMPv1 and SNMPv2 Access to MIB Data ....................... 6
2 SMI and Management Information Mappings ...................... 8
2.1 MIB Modules ................................................ 8
2.1.1 Object Definitions ....................................... 8
2.1.2 Trap and Notification Definitions ........................ 11
2.2 Compliance Statements ...................................... 11
2.3 Capabilities Statements .................................... 12
3 Translating Notifications Parameters ......................... 13
3.1 Translating SNMPv1 Notification Parameters to SNMPv2
Notification Parameters ................................... 14
3.2 Translating SNMPv2 Notification Parameters to SNMPv1
Notification Parameters ................................... 15
4 Approaches to Coexistence in a Multi-lingual Network ......... 18
4.1 Multi-lingual implementations .............................. 18
4.1.1 Command Generator ........................................ 18
4.1.2 Command Responder ........................................ 19
4.1.2.1 Handling Counter64 ..................................... 19
4.1.2.2 Mapping SNMPv2 Exceptions .............................. 20
4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 21
4.1.2.2.2 Mapping endOfMibView ................................. 21
4.1.2.3 Processing An SNMPv1 GetRequest ........................ 21
4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 22
4.1.2.5 Processing An SNMPv1 SetRequest ........................ 24
4.1.3 Notification Originator .................................. 24
4.1.4 Notification Receiver .................................... 25
4.2 Proxy Implementations ...................................... 25
4.2.1 Upstream Version Greater Than Downstream Version ......... 26
4.2.2 Upstream Version Less Than Downstream Version ............ 27
4.3 Error Status Mappings ...................................... 28
5 Message Processing Models and Security Models ................ 30
5.1 Mappings ................................................... 30
5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security
Model ..................................................... 30
5.2.1 Processing An Incoming Request ........................... 31
5.2.2 Generating An Outgoing Response .......................... 33
5.2.3 Generating An Outgoing Notification ...................... 33
5.3 The SNMP Community MIB Module .............................. 34
6 Intellectual Property ........................................ 45
7 Acknowledgments .............................................. 46
8 Security Considerations ...................................... 47
9 References ................................................... 48
10 Editor's Address ............................................ 50
A. Full Copyright Statement .................................... 51
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,
termed the SNMP version 3 framework (SNMPv3), version 2 of the termed the SNMP version 3 framework (SNMPv3), version 2 of the
Internet-standard Network Management Framework, termed the SNMP Internet-standard Network Management Framework, termed the SNMP
version 2 framework (SNMPv2), and the original Internet-standard version 2 framework (SNMPv2), and the original Internet-standard
Network Management Framework (SNMPv1). Network Management Framework (SNMPv1).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line 36 skipping to change at page 5, line 36
- STD 58, RFC 2580 which defines Conformance Statements and - STD 58, RFC 2580 which defines Conformance Statements and
requirements for defining agent and manager capabilities [9]. requirements 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 [10]. processing [10].
- RFC 1906 which defines the Transport Mappings used "on the - RFC 1906 which defines the Transport Mappings used "on the
wire" [11]. 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 [12]. for monitoring and controlling some basic common functions of
SNMP entities [12].
Note that SMIv2 as used throughout this document refers to the first Note that SMIv2 as used throughout this document refers to the first
three documents listed above (RFCs 2578, 2579, and 2580). three documents listed above (RFCs 2578, 2579, and 2580).
The following document augments the definition of SNMPv2: The following document augments the definition of SNMPv2:
- RFC 1901 [6] is an Experimental definition for using SNMPv2 - RFC 1901 [6] is an Experimental definition for using SNMPv2
PDUs within a community-based message wrapper. This is PDUs within a community-based message wrapper. This is
referred to throughout this document as SNMPv2c. referred to throughout this document as SNMPv2c.
skipping to change at page 6, line 28 skipping to change at page 6, line 28
providing for both Authenticated and Private (encrypted) SNMP providing for both Authenticated and Private (encrypted) SNMP
messages [19]. messages [19].
- RFC 2575 which defines the View-based Access Control Model - RFC 2575 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 [20]. objects on a per-user basis [20].
SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 and SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 and
the SMIv2 definitions of 2578 through 2580 described above. the SMIv2 definitions of 2578 through 2580 described above.
1.4. SNMPv1 and SNMPv2 MIB Instrumentation 1.4. SNMPv1 and SNMPv2 Access to MIB Data
In several places, this document refers to 'SNMPv1 MIB In several places, this document refers to 'SNMPv1 Access to MIB
Instrumentation' and 'SNMPv2 MIB Instrumentation'. These terms refer Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the part
to the part of an SNMP agent which actually implements MIB objects, of an SNMP agent which actually accesses instances of MIB objects,
and which actually initiates generation of notifications. and which actually initiates generation of notifications.
Differences between the two types of MIB instrumentation are: Differences between the two types of access to MIB data are:
- Error-status values generated. - Error-status values generated.
- Generation of exception codes. - Generation of exception codes.
- Use of the Counter64 data type. - Use of the Counter64 data type.
- The format of parameters provided when a notification is - The format of parameters provided when a notification is
generated. generated.
SNMPv1 MIB instrumentation may generate SNMPv1 error-status values, SNMPv1 access to MIB data may generate SNMPv1 error-status values,
will never generate exception codes nor use the Counter64 data type, will never generate exception codes nor use the Counter64 data type,
and will provide SNMPv1 format parameters for generating and will provide SNMPv1 format parameters for generating
notifications. Note also that SNMPv1 MIB instrumentation will notifications. Note also that SNMPv1 access to MIB data will
actually never generate a readOnly error (a noSuchName error would actually never generate a readOnly error (a noSuchName error would
always occur in the situation where one would expect a readOnly always occur in the situation where one would expect a readOnly
error). error).
SNMPv2 MIB instrumentation may generate SNMPv2 error-status values, SNMPv2 access to MIB data may generate SNMPv2 error-status values,
may generate exception codes, may use the Counter64 data type, and may generate exception codes, may use the Counter64 data type, and
will provide SNMPv2 format parameters for generating notifications. will provide SNMPv2 format parameters for generating notifications.
Note that SNMPv2 MIB instrumentation will never generate readOnly, Note that SNMPv2 access to MIB data will never generate readOnly,
noSuchName, or badValue errors. noSuchName, or badValue errors.
Note that a particular multi-lingual implementation may choose to Note that a particular multi-lingual implementation may choose to
implement all MIB instrumentation as SNMPv2 MIB instrumentation. implement all access to MIB data as SNMPv2 access to MIB data, and
perform the translations described herein for SNMPv1-based
transactions.
2. SMI and Management Information Mappings 2. SMI and Management Information Mappings
The SMIv2 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 SMIv1. is nearly a proper superset of the approach defined in the SMIv1.
For example, both approaches use an adapted subset of ASN.1 (1988) For example, both approaches use an adapted subset of ASN.1 (1988)
[11] as the basis for a formal descriptive notation. Indeed, one [11] as the basis for a formal descriptive notation. Indeed, one
might note that the SMIv2 approach largely codifies the existing might note that the SMIv2 approach largely codifies the existing
practice for defining MIB modules, based on extensive experience with practice for defining MIB modules, based on extensive experience with
the SMIv1. the SMIv1.
skipping to change at page 8, line 41 skipping to change at page 8, line 41
(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 object with an integer-valued SYNTAX clause, in which the (3) 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, or
have an appropriate range specified.
(4) 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.
(5) 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, or
Unsigned32 where appropriate.
(6) 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 SHALL be the same as clause. The value of the MAX-ACCESS clause SHALL be the same as
that of the ACCESS clause unless some other value makes "protocol that of the ACCESS clause unless some other value makes "protocol
sense" as the maximal level of access for the object. In sense" as the maximal level of access for the object. In
particular, object types for which instances can be explicitly particular, object types for which instances can be explicitly
created by a protocol set operation, SHALL have a MAX-ACCESS clause created by a protocol set operation, SHALL have a MAX-ACCESS clause
of "read-create". If the value of the ACCESS clause is "write- of "read-create". If the value of the ACCESS clause is "write-
only", then the value of the MAX-ACCESS clause MUST be "read- only", then the value of the MAX-ACCESS clause MUST be "read-
write", and the DESCRIPTION clause SHALL note that reading this write", and the DESCRIPTION clause SHALL note that reading this
object will result in implementation-specific results. object will result in implementation-specific results. Note that
in SMIv1, the ACCESS clause specifies the minimal required access,
while in SMIv2, the MAX-ACCESS clause specifies the maximum allowed
access. This should be considered when converting an ACCESS clause
to a MAX-ACCESS clause.
(7) For all objects, if the value of the STATUS clause is "mandatory" (7) For all objects, if the value of the STATUS clause is "mandatory"
or "optional", the value MUST be replaced with "current", or "optional", the value MUST be replaced with "current",
"deprecated", or "obsolete" depending on the current usage of such "deprecated", or "obsolete" depending on the current usage of such
objects. objects.
(8) For any object not containing a DESCRIPTION clause, the object MUST (8) For any object not containing a DESCRIPTION clause, the object MUST
have a DESCRIPTION clause defined. have a DESCRIPTION clause defined.
(9) For any object corresponding to a conceptual row which does not (9) 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.
(10) If any INDEX clause contains a reference to an object with a syntax (10) If any INDEX clause contains a reference to an object with a syntax
of NetworkAddress, then a new object MUST be created and placed in of NetworkAddress, then a new object MUST be created and placed in
this INDEX clause immediately preceding the object whose syntax is this INDEX clause immediately preceding the object whose syntax is
NetworkAddress. This new object MUST have a syntax of INTEGER, it NetworkAddress. This new object MUST have a syntax of INTEGER, it
MUST be not-accessible, and its value MUST always be 1. MUST be not-accessible, and its value MUST always be 1.
(11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be
changed to IpAddress. changed to IpAddress. Note that the use of NetworkAddress in new
MIB documents is strongly discouraged (in fact, new MIB documents
should be written using SMIv2, which does not define
NetworkAddress).
(12) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER (12) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER
value which is expressed as a collection of sub-identifiers, the value which is expressed as a collection of sub-identifiers, the
value MUST be changed to reference a single ASN.1 identifier. This value MUST be changed to reference a single ASN.1 identifier. This
may require defining a series of new objects in order to define the may require defining a series of new administrative assignments
single ASN.1 identifier. (OBJECT IDENTIFIERS) in order to define the single ASN.1
identifier.
(13) One or more OBJECT-GROUPS MUST be defined, and related objects
SHOULD be collected into appropriate groups. Note that SMIv2
requires all OBJECT-TYPEs to be a member of at least one OBJECT-
GROUP.
Other changes are desirable, but not necessary: 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
SMIv1. The SMIv2 corrects this. As such, if the MIB module SMIv1. The SMIv2 corrects this. As such, if the MIB module
undergoes review early in its lifetime, and it contains conceptual undergoes review early in its lifetime, and it contains conceptual
tables which allow creation and deletion of conceptual rows, then tables which allow creation and deletion of conceptual rows, then
the objects relating to those tables MAY be deprecated and replaced the objects relating to those tables MAY be deprecated and replaced
with objects defined using the new approach. The new approach can with objects defined using the new approach. The approach base on
be found in section 7 of RFC2578 [7], and the RowStatus and SMIv2 can be found in section 7 of RFC2578 [7], and the RowStatus
StorageType TEXTUAL-CONVENTIONs are described in section 2 of and StorageType TEXTUAL-CONVENTIONs are described in section 2 of
RFC2579 [8]. RFC2579 [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), the bounds for the size of the object SHOULD be its length), the bounds for the size of the object SHOULD be
defined. defined.
(3) All textual conventions informally defined in the MIB module SHOULD (3) All textual conventions informally defined in the MIB module SHOULD
be redefined using the TEXTUAL-CONVENTION macro. Such a change be redefined using the TEXTUAL-CONVENTION macro. Such a change
skipping to change at page 11, line 9 skipping to change at page 11, line 20
occurrence of the TRAP-TYPE macro MUST be changed to a corresponding occurrence of the TRAP-TYPE macro MUST be changed to a corresponding
invocation of the NOTIFICATION-TYPE macro: invocation of the NOTIFICATION-TYPE macro:
(1) The IMPORTS statement MUST NOT reference RFC-1215 [4], and MUST (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) A STATUS clause MUST be added, with an appropriate value. Normally
the value should be 'current,' although 'deprecated' or 'obsolete'
may be used as needed.
(5) The value of an invocation of the NOTIFICATION-TYPE macro is an (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 SHALL be the value of the then the value of the invocation SHALL be the value of the
ENTERPRISE clause extended with two sub-identifiers, the first of ENTERPRISE clause extended with two sub-identifiers, the first of
which has the value 0, and the second has the value of the which has the value 0, and the second has the value of the
invocation of the TRAP-TYPE. If the value of the ENTERPRISE clause invocation of the TRAP-TYPE. If the value of the ENTERPRISE clause
is 'snmp', then the value of the invocation of the NOTIFICATION- is 'snmp', then the value of the invocation of the NOTIFICATION-
TYPE macro SHALL be mapped in the same manner as described in TYPE macro SHALL be mapped in the same manner as described in
section 3.1 in this document. section 3.1 in this document.
(6) The DESCRIPTION clause MUST be added, if not already present. (6) A 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 MUST be defined, and related
notifications SHOULD be collected into those groups. notifications MUST be collected into those groups. Note that SMIv2
requires that all NOTIFICATION-TYPEs be a member of at least one
NOTIFICATION-GROUP.
2.2. Compliance Statements 2.2. Compliance Statements
For those information modules which are "standards track", a For those information modules which are "standards track", a
corresponding invocation of the MODULE-COMPLIANCE macro and related corresponding invocation of the MODULE-COMPLIANCE macro and related
OBJECT-GROUP macros MUST be included within the information module OBJECT-GROUP macros MUST be included within the information module
(or in a companion information module), and any commentary text in (or in a companion information module), and any commentary text in
the information module which relates to compliance SHOULD be removed. the information module which relates to compliance SHOULD be removed.
Typically this editing can occur when the information module Typically this editing can occur when the information module
undergoes review. undergoes review.
Note that it is always good practice to add compliance statements to Note that a MODULE-COMPLIANCE statement is not required for a MIB
a MIB document, even if the document is not on the standards track. document that is not on the standards track (for example, an
enterprise MIB), though it may be useful in some circumstances to
define a MODULE-COMPLIANCE statement for such a MIB document.
2.3. Capabilities Statements 2.3. Capabilities Statements
RFC1303 [5] uses the MODULE-CONFORMANCE macro to describe an agent's RFC1303 [5] uses the MODULE-CONFORMANCE macro to describe an agent's
capabilities with respect to one or more MIB modules. Converting capabilities with respect to one or more MIB modules. Converting
such a description for use with the SMIv2 requires these changes: such a description for use with the SMIv2 requires these changes:
(1) The macro name AGENT-CAPABILITIES SHOULD be used instead of MODULE- (1) The macro name AGENT-CAPABILITIES SHOULD be used instead of MODULE-
CONFORMANCE. CONFORMANCE.
(2) The STATUS clause SHOULD be added, with a value of 'current'. (2) The STATUS clause SHOULD be added, with a value of 'current'.
(3) All occurrences of the CREATION-REQUIRES clause SHOULD either be (3) All occurrences of the CREATION-REQUIRES clause MUST either be
omitted if appropriate, or be changed such that the semantics are omitted if appropriate, or be changed such that the semantics are
consistent with RFC2580 [9]. consistent with RFC2580 [9].
In order to ease coexistence, object groups defined in an SMIv1 In order to ease coexistence, object groups defined in an SMIv1
compliant MIB module may be referenced by the INCLUDES clause of an compliant MIB module may be referenced by the INCLUDES clause of an
invocation of the AGENT-CAPABILITIES macro: upon encountering a invocation of the AGENT-CAPABILITIES macro: upon encountering a
reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB
module, all leaf objects which are subordinate to the subtree and module, all leaf objects which are subordinate to the subtree and
have a STATUS clause value of mandatory are deemed to be INCLUDEd. have a STATUS clause value of mandatory are deemed to be INCLUDEd.
(Note that this method is ambiguous when different revisions of an (Note that this method is ambiguous when different revisions of an
SMIv1 MIB have different sets of mandatory objects under the same SMIv1 MIB have different sets of mandatory objects under the same
subtree; in such cases, the only solution is to rewrite the MIB using subtree; in such cases, the only solution is to rewrite the MIB using
the SMIv2 in order to define the object groups unambiguously.) the SMIv2 in order to define the object groups unambiguously.)
3. Translating Notifications Parameters 3. Translating Notifications Parameters
This section describes how parameters used for generating This section describes how parameters used for generating
notifications are translated between the format used for SNMPv1 notifications are translated between the format used for SNMPv1
notification protocol operations and the format used for SNMPv2 notification protocol operations and the format used for SNMPv2
notification protocol operations. The parameters used to generate a notification protocol operations. The parameters used to generate a
notification are called 'notification parameters'. The format of notification are called 'notification parameters.' The format of
parameters used for SNMPv1 notification protocol operations is parameters used for SNMPv1 notification protocol operations is
refered to in this document as 'SNMPv1 notification parameters.' The refered to in this document as 'SNMPv1 notification parameters.' The
format of parameters used for SNMPv2 notification protocol operations format of parameters used for SNMPv2 notification protocol operations
is refered to in this document as 'SNMPv2 notification parameters.' is refered to in this document as 'SNMPv2 notification parameters.'
The SMI version used to define a notification will usually determine
which type of notification parameters are provided by MIB
instrumentation when a notification is generated.
The situations where notification parameters MUST be translated are: The situations where notification parameters MUST be translated are:
- When MIB instrumentation in an entity generates a set of - When an entity generates a set of notification parameters in a
notification parameters in a particular format, and the particular format, and the configuration of the entity
configuration of the entity indicates that the notification indicates that the notification must be sent using an SNMP
must be sent using an SNMP message version that requires the message version that requires the other format for
other format for notification parameters. notification parameters.
- When a proxy receives a notification that was sent using an - When a proxy receives a notification that was sent using an
SNMP message version that requires one format of notification SNMP message version that requires one format of notification
parameters, and must forward the notification using an SNMP parameters, and must forward the notification using an SNMP
message version that requires the other format of notification message version that requires the other format of notification
parameters. 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.
skipping to change at page 18, line 38 skipping to change at page 18, line 38
the following sections. This approach allows entities which support the following sections. This approach allows entities which support
multiple SNMP message versions to coexist with and communicate with multiple SNMP message versions to coexist with and communicate with
entities which support only a single SNMP message version. entities which support only a single SNMP message version.
4.1.1. Command Generator 4.1.1. Command Generator
A command generator must select an appropriate message version 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 version. consult a local database to select the appropriate message version.
In addition, a command generator should 'downgrade' GetBulk requests In addition, a command generator MUST 'downgrade' GetBulk requests to
to GetNext requests when selecting SNMPv1 as the message version for GetNext requests when selecting SNMPv1 as the message version for an
an outgoing request. This is done by simply changing the operation outgoing request. This is done by simply changing the operation type
type to GetNext, ignoring any non-repeaters and max-repetitions to GetNext, ignoring any non-repeaters and max-repetitions values,
values, and setting error-status and error-index to zero. and setting error-status and error-index to zero.
4.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 both SNMPv1 and SNMPv2
that is written using both the SNMPv1 and SNMPv2. There are three access to MIB data. There are three aspects to dealing with this. A
aspects to dealing with this. A command responder must: command responder must:
- Deal correctly with SNMPv2 MIB instrumentation that returns a - Deal correctly with SNMPv2 access to MIB data that returns a
Counter64 value while processing an SNMPv1 message, Counter64 value while processing an SNMPv1 message,
- Deal correctly with SNMPv2 MIB instrumentation that returns - Deal correctly with SNMPv2 access to MIB data that returns one
one of the three exception values while processing an SNMPv1 of the three exception values while processing an SNMPv1
message, and message, and
- Map SNMPv2 error codes returned from SNMPv2 MIB - Map SNMPv2 error codes returned from SNMPv2 access to MIB data
instrumentation into SNMPv1 error codes when processing an into SNMPv1 error codes when processing an SNMPv1 message.
SNMPv1 message.
Note that SNMPv1 error codes can be used without any change when Note that SNMPv1 error codes SHOULD NOT be used without any change
processing SNMPv2c or SNMPv3 messages. when processing SNMPv2c or SNMPv3 messages, except in the case of
proxy forwarding. In the case of proxy forwarding, for backwards
compatibility, SNMPv1 error codes may be used without any change in a
forwarded SNMPv2c or SNMPv3 message.
The following sections describe the behaviour of a command responder The following sections describe the behaviour of a command responder
application which supports multiple SNMP message versions, and which application which supports multiple SNMP message versions, and which
has access to some combination of SNMPv1 and SNMPv2 MIB uses some combination of SNMPv1 and SNMPv2 access to MIB data.
instrumentation.
4.1.2.1. Handling Counter64 4.1.2.1. Handling Counter64
The SMIv2 [7] defines one new syntax that is incompatible with SMIv1. The SMIv2 [7] defines one new syntax that is incompatible with SMIv1.
This syntax is Counter64. All other syntaxes defined by SMIv2 are This syntax is Counter64. All other syntaxes defined by SMIv2 are
compatible with SMIv1. compatible with SMIv1.
The impact on multi-lingual command responders is that they MUST NOT The impact on multi-lingual command responders is that they MUST NOT
ever return a variable binding containing a Counter64 value in a ever return a variable binding containing a Counter64 value in a
response to a request that was received using the SNMPv1 message response to a request that was received using the SNMPv1 message
version. version.
Multi-lingual command responders SHALL 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, an error-status of noSuchName SHALL - On receipt of an SNMPv1 GetRequest-PDU containing a variable
be returned, and the error-index SHALL be set to the variable binding whose name field points to an object instance of type
Counter64, a GetResponsePDU SHALL be returned, with an error-
status of noSuchName and the error-index set to the variable
binding that caused this error. binding that caused this error.
- On an SNMPv1 GetNext request, any object instance which - On an SNMPv1 GetNextRequest-PDU, any object instance which
contains a syntax of Counter64 shall be skipped, and the next contains a syntax of Counter64 SHALL be skipped, and the next
object instance that follows the one with a syntax of accessible object instance that does not have the syntax of
Counter64 SHALL be fetched. This step may need to be repeated Counter64 SHALL be retrieved. If no such object instance
several times in order to find an object whose syntax is not exists, then an error-status of noSuchName SHALL be returned,
Counter64. and the error-index SHALL be set to the variable binding that
caused this error.
- Any SET request that has a variable binding with a Counter64 - Any SNMPv1 request which contains a variable binding with a
value must have come from a SNMPv2 manager, and so it should Counter64 value is ill-formed, so the foregoing rules do not
not cause a problem. However, if an object with SYNTAX of apply. If that error is detected, a response SHALL NOT be
Counter64 is received in an SNMPv1 SET packet, it SHALL result returned, since it would contain a copy of the ill-formed
in an ASN.1 parse error since Counter64 is not valid in the variable binding. Instead, the offending PDU SHALL be
SNMPv1 protocol. When an ASN.1 parse error occurs, the counter discarded and the counter snmpInASNParseErrs SHALL be
snmpInASNParseErrs SHALL be incremented and no response is incremented.
returned.
4.1.2.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 MIB instrumentation for any variable bindings returned using SNMPv2 access to MIB data 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 MIB instrumentation The type of exception that can be returned when accessing MIB data
and 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.
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.
4.1.2.2.1. Mapping noSuchObject and noSuchInstance 4.1.2.2.1. Mapping noSuchObject and noSuchInstance
A noSuchObject or noSuchInstance exception generated by SNMPv2 MIB A noSuchObject or noSuchInstance exception generated by an SNMPv2
instrumentation indicates that the requested object instance can not access to MIB data indicates that the requested object instance can
be returned. The SNMPv1 error code for this condition is noSuchName, not be returned. The SNMPv1 error code for this condition is
and so the error-status field of the response PDU SHALL be set to noSuchName, and so the error-status field of the response PDU SHALL
noSuchName. Also, the error-index field SHALL be set to the index of be set to noSuchName. Also, the error-index field SHALL be set to
the variable binding for which an exception occurred, and the the index of the variable binding for which an exception occurred
variable binding list from the original request SHALL be returned (there may be more than one and it is an implementation decision as
with the response PDU. to which is used), and the variable binding list from the original
request SHALL be returned with the response PDU.
4.1.2.2.2. Mapping endOfMibView 4.1.2.2.2. Mapping endOfMibView
When SNMPv2 MIB instrumentation returns a variable binding containing When an SNMPv2 access to MIB data returns a variable binding
an endOfMibView exception, it indicates that there are no object containing an endOfMibView exception, it indicates that there are no
instances available which lexicographically follow the object in the object instances available which lexicographically follow the object
request. In an SNMPv1 agent, this condition normally results in a in the request. In an SNMPv1 agent, this condition normally results
noSuchName error, and so the error-status field of the response PDU in a noSuchName error, and so the error-status field of the response
SHALL be set to noSuchName. Also, the error-index field SHALL be set PDU SHALL be set to noSuchName. Also, the error-index field SHALL be
to the index of the variable binding for which an exception occurred, set to the index of the variable binding for which an exception
and the variable binding list from the original request SHALL be occurred (there may be more than one and it is an implementation
returned with the response PDU. decision as to which is used), and the variable binding list from the
original request SHALL be returned with the response PDU.
4.1.2.3. Processing An SNMPv1 GetRequest 4.1.2.3. Processing An SNMPv1 GetRequest
When processing an SNMPv1 GetRequest, the following procedures MUST When processing an SNMPv1 GetRequest, the following procedures MUST
be followed when calling SNMPv2 MIB instrumentation. be followed when using an SNMPv2 access to MIB data.
When such MIB instrumentation returns response data using SNMPv2 When such an access to MIB data returns response data using SNMPv2
syntax 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 SHALL be translated to an SNMPv1 error-status - The error status SHALL be translated to an SNMPv1 error-status
using the table in section 4.3, "Error Status Mappings". using the table in section 4.3, "Error Status Mappings".
- The error-index SHALL be 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.
skipping to change at page 22, line 33 skipping to change at page 22, line 36
the 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:
- The error-status SHALL be set to noError, - The error-status SHALL be set to noError,
- The error-index SHALL be set to zero, and - The error-index SHALL be set to zero, and
- The variable binding list of the response SHALL be composed - The variable binding list of the response SHALL be composed
from the data as it is returned by the MIB instrumentation. from the data as it is returned by the access to MIB data.
4.1.2.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
MUST be followed when SNMPv2 MIB instrumentation is called as part of MUST be followed when an SNMPv2 access to MIB data is called as part
processing the request. There may be repetitive calls to (possibly of processing the request. There may be repetitive accesses to MIB
different pieces of) MIB instrumentation to try to find the first data to try to find the first object which lexicographically follows
object which lexicographically follows each of the objects in the each of the objects in the request. This is implementation specific.
request. This is implementation specific. These procedures are These procedures are followed only for data returned when using
followed only for data returned from SNMPv2 MIB instrumentation. SNMPv2 access to MIB data. Data returned using SNMPv1 access to MIB
Data returned from SNMPv1 MIB instrumentation may be treated in the data may be treated in the normal manner for an SNMPv1 request.
normal manner for an SNMPv1 request.
First, if the MIB instrumentation returns an error-status of anything First, if the access to MIB data returns an error-status of anything
other than noError: other than noError:
(1) The error status SHALL be translated to an SNMPv1 error-status (1) The error status SHALL be translated to an SNMPv1 error-status
using the table in section 4.3, "Error Status Mappings". using the table in section 4.3, "Error Status Mappings".
(2) The error-index SHALL be set to the position (in the original (2) 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.
(3) The variable binding list of the response PDU SHALL be 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 MIB instrumentation returns an error-status of Otherwise, if the access to MIB data returns an error-status of
noError: noError:
(1) Any variable bindings containing an SNMPv2 syntax of Counter64 (1) Any variable bindings containing an SNMPv2 syntax of Counter64
SHALL be considered to be not in view, and the MIB instrumentation SHALL be considered to be not in view, and MIB data SHALL be
SHALL be called as often as is required until either a value other accessed as many times as is required until either a value other
than Counter64 is returned, or an error occurs. than Counter64 is returned, or an error occurs.
(2) If there is any variable binding that contains an SNMPv2 exception (2) If there is any variable binding that contains an SNMPv2 exception
endOfMibView (there may be more than one, it is an implementation endOfMibView (there may be more than one, it is an implementation
decision as to which is chosen): decision as to which is chosen):
- The error-status SHALL be set to noSuchName, - The error-status SHALL be set to noSuchName,
- The error-index SHALL be set to the position (in the variable - The error-index SHALL be set to the position (in the variable
binding list of the original request) of the variable binding binding list of the original request) of the variable binding
skipping to change at page 23, line 44 skipping to change at page 23, line 45
the 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:
- The error-status SHALL be set to noError, - The error-status SHALL be set to noError,
- The error-index SHALL be set to zero, and - The error-index SHALL be set to zero, and
- The variable binding list of the response SHALL be composed - The variable binding list of the response SHALL be composed
from the data as it is returned by the MIB instrumentation. from the data as it is returned by the access to MIB data.
4.1.2.5. Processing An SNMPv1 SetRequest
When processing an SNMPv1 SetRequest, the following procedures MUST
be followed when calling SNMPv2 MIB access routines.
When such MIB access routines return response data using SNMPv2
syntax and error-status values, and the error-status is anything
other than noError, then:
- The error status SHALL be translated to an SNMPv1 error-status
using the table in section 4.3, "Error Status Mappings".
- The error-index SHALL be set to the position (in the original
request) of the variable binding that caused the error-status.
- The variable binding list of the response PDU SHALL be made
exactly the same as the variable binding list that was
received in the original request.
In addition, whenever the SNMPv2 error-status value of
authorizationError is translated to an SNMPv1 error-status value of
noSuchName, the value of snmpInBadCommunityUses MUST be incremented.
4.1.3. Notification Originator 4.1.3. Notification Originator
A notification originator must be able to translate between SNMPv1 A notification originator must be able to translate between SNMPv1
notifications parameters and SNMPv2 notification parameters in order notifications parameters and SNMPv2 notification parameters in order
to send a notification using a particular SNMP message version. If to send a notification using a particular SNMP message version. If a
MIB instrumentation presents a notification using SNMPv1 notification notification is generated using SNMPv1 notification parameters, and
parameters, and configuration information specifies that configuration information specifies that notifications be sent using
notifications be sent using SNMPv2c or SNMPv3, the notification SNMPv2c or SNMPv3, the notification parameters must be translated to
parameters must be translated to SNMPv2 notification parameters. SNMPv2 notification parameters. Likewise, if a notification is
Likewise, if MIB instrumentation presents a notification using SNMPv2 generated using SNMPv2 notification parameters, and configuration
notification parameters, and configuration information specifies that information specifies that notifications be sent using SNMPv1, the
notifications be sent using SNMPv1, the notification parameters must notification parameters must be translated to SNMPv1 notification
be translated to SNMPv1 notification parameters. In this case, if parameters. In this case, if the notification cannot be translated
the notification cannot be translated (due to the presence of a (due to the presence of a Counter64 type), it will not be sent using
Counter64 type), it will not be sent using SNMPv1. SNMPv1.
When a notification originator generates a notification, using When a notification originator generates a notification, using
parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION- parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION-
MIB, if the SNMP version used to generate the notification is SNMPv1, 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 the PDU type used will always be a TrapPDU, regardless of whether the
value of snmpNotifyType is trap(1) or inform(2). value of snmpNotifyType is trap(1) or inform(2).
Note also that access control and notification filtering are Note also that access control and notification filtering are
performed in the usual manner for notifications, regardless of the performed in the usual manner for notifications, regardless of the
SNMP message version to be used when sending a notification. The SNMP message version to be used when sending a notification. The
parameters for performing access control are found in the usual parameters for performing access control are found in the usual
manner (i.e. from inspecting the SNMP-TARGET-MIB and SNMP- manner (i.e., from inspecting the SNMP-TARGET-MIB and SNMP-
NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in
order to perform the access check specified in [18], section 3.3, order to perform the access check specified in [18], section 3.3,
bullet (3), the notification originator may need to generate a value 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 for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of
this document. If the SNMPv1 notification parameters being used were this document. If the SNMPv1 notification parameters being used were
previously translated from a set of SNMPv2 notification parameters, previously translated from a set of SNMPv2 notification parameters,
this value may already be known, in which case it need not be this value may already be known, in which case it need not be
generated. generated.
4.1.4. Notification Receiver 4.1.4. Notification Receiver
skipping to change at page 25, line 10 skipping to change at page 25, line 34
higher level application using SNMPv1 notification parameter or higher level application using SNMPv1 notification parameter or
SNMPv2 notification parameters. The notification receiver would then SNMPv2 notification parameters. The notification receiver would then
translate notification parameters when required in order to present a translate notification parameters when required in order to present a
notification using the desired set of parameters. notification using the desired set of parameters.
4.2. Proxy Implementations 4.2. Proxy Implementations
A proxy implementation may be used to enable communication between A proxy implementation may be used to enable communication between
entities which support different SNMP message versions. This is entities which support different SNMP message versions. This is
accomplished in a proxy forwarder application by performing accomplished in a proxy forwarder application by performing
translations on a PDU in the following situations: translations on PDUs. These translations depend on the PDU type, the
SNMP version of the packet containing a received PDU, and the SNMP
version to be used to forward a received PDU. The following sections
describe these translations. In all cases other than those described
below, the proxy SHALL forward a received PDU without change, subject
to size contraints as defined in section 5.3 (Community MIB) of this
document. Note that in the following sections, the 'Upstream
Version' refers to the version used between the command generator and
the proxy, and the 'Downstream Version' refers to the version used
between the proxy and the command responder.
4.2.1. Upstream Version Greater Than Downstream Version
- If a GetBulkRequest-PDU is received and must be forwarded - If a GetBulkRequest-PDU is received and must be forwarded
using the SNMPv1 message version, the proxy forwarder SHALL using the SNMPv1 message version, the proxy forwarder SHALL
set the non-repeaters and max-repetitions fields to 0, and set the non-repeaters and max-repetitions fields to 0, and
SHALL set the tag of the PDU to GetNextRequest-PDU. SHALL set the tag of the PDU to GetNextRequest-PDU.
- If a GetResponse-PDU is received whose error-status field has - If a GetResponse-PDU is received whose error-status field has
a value of 'tooBig', and the message will be forwarded using a value of 'tooBig', the message will be forwarded using the
the SNMPv2c or SNMPv3 message version, the proxy forwarder SNMPv2c or SNMPv3 message version, and the original request
SHALL remove the contents of the variable-bindings field received by the proxy was not a GetBulkRequest-PDU, the proxy
before forwarding the response. forwarder SHALL remove the contents of the variable-bindings
field before forwarding the response.
- If a GetResponse-PDU is received whose error-status field has
a value of 'tooBig,' and the message will be forwarded using
the SNMPv2c or SNMPv3 message version, and the original
request received by the proxy was a GetBulkRequest-PDU, the
proxy forwarder SHALL re-send the forwarded request (which
would have been altered to be a GetNextRequest-PDU) with all
but the first variable-binding removed. The proxy forwarder
SHALL only re-send such a request a single time. If the
resulting GetResponse-PDU also contains an error-status field
with a value of 'tooBig,' then the proxy forwarder SHALL
remove the contents of the variable-bindings field, and change
the error-status field to 'noError' before forwarding the
response. Note that if the original request only contained a
single variable-binding, the proxy may skip re-sending the
request and simply remove the variable-bindings and change the
error-status to 'noError.'
- If a Trap-PDU is received, and will be forwarded using the
SNMPv2c or SNMPv3 message version, the proxy SHALL apply the
translation rules described in section 3, and SHALL forward
the notification as an SNMPv2-Trap-PDU.
Note that when an SNMPv1 agent generates a message containing
a Trap-PDU which is subsequently forwarded by one or more
proxy forwarders using SNMP versions other than SNMPv1, the
community string and agent-addr fields from the original
message generated by the SNMPv1 agent will be preserved
through the use of the snmpTrapAddress and snmpTrapCommunity
objects.
4.2.2. Upstream Version Less Than Downstream Version
- If a GetResponse-PDU is received in response to a GetRequest- - If a GetResponse-PDU is received in response to a GetRequest-
PDU (previously generated by the proxy) which contains PDU (previously generated by the proxy) which contains
variable-bindings of type Counter64 or which contain an SNMPv2 variable-bindings of type Counter64 or which contain an SNMPv2
exception code, and the message would be forwarded using the exception code, and the message would be forwarded using the
SNMPv1 message version, the proxy MUST generate an alternate SNMPv1 message version, the proxy MUST generate an alternate
response PDU consisting of the request-id and variable response PDU consisting of the request-id and variable
bindings from the original SNMPv1 request, containing a bindings from the original SNMPv1 request, containing a
noSuchName error-status value, and containing an error-index noSuchName error-status value, and containing an error-index
value indicating the position of the variable-binding value indicating the position of the variable-binding
skipping to change at page 26, line 18 skipping to change at page 27, line 50
objects. One approach to such an optimization would be to objects. One approach to such an optimization would be to
replace the last sub-identifier of the object names of replace the last sub-identifier of the object names of
varbinds containing a Counter64 type with 65535 if that sub- varbinds containing a Counter64 type with 65535 if that sub-
identifier is less than 65535, or with 4294967295 if that identifier is less than 65535, or with 4294967295 if that
sub-identifier is greater than 65535. This approach should sub-identifier is greater than 65535. This approach should
skip multiple instances of the same Counter64 object, while skip multiple instances of the same Counter64 object, while
maintaining compatibility with some broken agent maintaining compatibility with some broken agent
implementations (which only use 16-bit integers for sub- implementations (which only use 16-bit integers for sub-
identifiers). identifiers).
Deployment Hint: The process of repeated GetNext requests
used by a proxy when Counter64 types are returned can be
expensive. When deploying a proxy, this can be avoided by
configuring the target agents to which the proxy forwards
requests in a manner such that any objects of type Counter64
are in fact not-in-view for the principal that the proxy is
using when communicating with these agents.
- If a GetResponse-PDU is received which contains an SNMPv2 - If a GetResponse-PDU is received which contains an SNMPv2
error-status value of wrongValue, wrongEncoding, wrongType, error-status value of wrongValue, wrongEncoding, wrongType,
wrongLength, inconsistentValue, noAccess, notWritable, wrongLength, inconsistentValue, noAccess, notWritable,
noCreation, inconsistentName, resourceUnavailable, noCreation, inconsistentName, resourceUnavailable,
commitFailed, undoFailed, or authorizationError, the error- commitFailed, undoFailed, or authorizationError, the error-
status value is modified using the mappings in section 4.3. status value is modified using the mappings in section 4.3.
- If a Trap-PDU is received, and will be forwarded using the
SNMPv2c or SNMPv3 message version, the proxy SHALL apply the
translation rules described in section 3, and SHALL forward
the notification as an SNMPv2-Trap-PDU.
- If an SNMPv2-Trap-PDU is received, and will be forwarded using - If an SNMPv2-Trap-PDU is received, and will be forwarded using
the SNMPv1 message version, the proxy SHALL apply the the SNMPv1 message version, the proxy SHALL apply the
translation rules described in section 3, and SHALL forward translation rules described in section 3, and SHALL forward
the notification as a Trap-PDU. Note that if the translation the notification as a Trap-PDU. Note that if the translation
fails dues to the existence of a Counter64 data-type in the fails due to the existence of a Counter64 data-type in the
received SNMPv2-Trap-PDU, the trap cannot be forwarded using received SNMPv2-Trap-PDU, the trap cannot be forwarded using
SNMPv1. SNMPv1.
- If an InformRequest-PDU is received, any configuration - If an InformRequest-PDU is received, any configuration
information indicating that it would be forwarded using the information indicating that it would be forwarded using the
SNMPv1 message version SHALL be ignored. An InformRequest-PDU SNMPv1 message version SHALL be ignored. An InformRequest-PDU
can only be forwarded using the SNMPv2c or SNMPv3 message can only be forwarded using the SNMPv2c or SNMPv3 message
version. The InformRequest-PDU may still be forwarded if version. The InformRequest-PDU may still be forwarded if
there is other configuration information indicating that it there is other configuration information indicating that it
should be forwarded using SNMPv2c or SNMPv3. should be forwarded using SNMPv2c or SNMPv3.
- 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.2.1. Deployment Hint
The process of repeated GetNext requests used by a proxy when
Counter64 types are returned can be expensive. When deploying a
proxy, this can be avoided by configuring the target agents to which
the proxy forwards requests in a manner such that any objects of type
Counter64 are in fact not-in-view for the principal that the proxy is
using when communicating with these agents.
4.3. Error Status Mappings 4.3. Error Status Mappings
The following tables shows the mappings of SNMPv1 error-status values The following tables shows the mappings of SNMPv1 error-status values
into SNMPv2 error-status values, and the mappings of SNMPv2 error- into SNMPv2 error-status values, and the mappings of SNMPv2 error-
status values into SNMPv1 error-status values. status values into SNMPv1 error-status values.
SNMPv1 error-status SNMPv2 error-status SNMPv1 error-status SNMPv2 error-status
=================== =================== =================== ===================
noError noError noError noError
tooBig tooBig tooBig tooBig
skipping to change at page 30, line 46 skipping to change at page 31, line 46
which the following matching criteria are satisfied will be selected: which the following matching criteria are satisfied will be selected:
- The community string is equal to the snmpCommunityName value. - The community string is equal to the snmpCommunityName value.
- If the snmpCommunityTransportTag is an empty string, it is - If the snmpCommunityTransportTag is an empty string, it is
ignored for the purpose of matching. If the ignored for the purpose of matching. If the
snmpCommunityTransportTag is not an empty string, the snmpCommunityTransportTag is not an empty string, the
transportDomain and transportAddress from which the message transportDomain and transportAddress from which the message
was received must match one of the entries in the was received must match one of the entries in the
snmpTargetAddrTable selected by the snmpCommunityTransportTag snmpTargetAddrTable selected by the snmpCommunityTransportTag
value. value. The snmpTargetAddrTMask object is used as described in
section 5.3 when checking whether the transportDomain and
transportAddress matches a entry in the snmpTargetAddrTable.
If no such entry can be found, an authentication failure occurs as If no such entry can be found, an authentication failure occurs as
described in RFC1157 [2]. described in RFC1157 [2], and the snmpInBadCommunityNames counter is
incremented.
The parameters returned from the Community-Based Security Model are: The parameters returned from the Community-Based Security Model are:
- The securityEngineID, which will always be the local value of - The securityEngineID, which will always be the local value of
snmpEngineID.0. snmpEngineID.0.
- The securityName. - The securityName.
- The scopedPDU. Note that this parameter will actually consist - The scopedPDU. Note that this parameter will actually consist
of three values, the contextSnmpEngineID, the contextName, and of three values, the contextSnmpEngineID, the contextName, and
skipping to change at page 33, line 46 skipping to change at page 35, line 5
length is either zero or the same as that of the corresponding length is either zero or the same as that of the corresponding
instance of snmpTargetAddrTAddress. instance of snmpTargetAddrTAddress.
When checking whether a transport address matches an entry in the When checking whether a transport address matches an entry in the
snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero- snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero-
length OCTET STRING, the mask value is ignored, and the value of length OCTET STRING, the mask value is ignored, and the value of
snmpTargetAddrTAddress must exactly match a transport address. snmpTargetAddrTAddress must exactly match a transport address.
Otherwise, each bit of each octet in the snmpTargetAddrTMask value Otherwise, each bit of each octet in the snmpTargetAddrTMask value
corresponds to the same bit of the same octet in the corresponds to the same bit of the same octet in the
snmpTargetAddrTAddress value. For bits that are set in the snmpTargetAddrTAddress value. For bits that are set in the
snmpTargetAddrTMask value (i.e. bits equal to 1), the corresponding snmpTargetAddrTMask value (i.e., bits equal to 1), the corresponding
bits in the snmpTargetAddrTAddress value must match the bits in a bits in the snmpTargetAddrTAddress value must match the bits in a
transport address. If all such bits match, the transport address is transport address. If all such bits match, the transport address is
matched by that snmpTargetAddrTable entry. Otherwise, the transport matched by that snmpTargetAddrTable entry. Otherwise, the transport
address is not matched. address is not matched.
The maximum message size value, snmpTargetAddrMMS, is used to The maximum message size value, snmpTargetAddrMMS, is used to
determine the maximum message size acceptable to another SNMP entity determine the maximum message size acceptable to another SNMP entity
when the value cannot be determined from the protocol. when the value cannot be determined from the protocol.
SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN
skipping to change at page 34, line 25 skipping to change at page 35, line 28
IpAddress, IpAddress,
MODULE-IDENTITY, MODULE-IDENTITY,
OBJECT-TYPE, OBJECT-TYPE,
Integer32, Integer32,
snmpModules snmpModules
FROM SNMPv2-SMI FROM SNMPv2-SMI
RowStatus, RowStatus,
StorageType StorageType
FROM SNMPv2-TC FROM SNMPv2-TC
SnmpAdminString, SnmpAdminString,
snmpEngineID SnmpEngineID
FROM SNMP-FRAMEWORK-MIB FROM SNMP-FRAMEWORK-MIB
SnmpTagValue, SnmpTagValue,
snmpTargetAddrEntry snmpTargetAddrEntry
FROM SNMP-TARGET-MIB FROM SNMP-TARGET-MIB
MODULE-COMPLIANCE, MODULE-COMPLIANCE,
OBJECT-GROUP OBJECT-GROUP
FROM SNMPv2-CONF; FROM SNMPv2-CONF;
snmpCommunityMIB MODULE-IDENTITY snmpCommunityMIB MODULE-IDENTITY
LAST-UPDATED "199905130000Z" -- 13 May 1999, midnight LAST-UPDATED "199910050000Z" -- 5 Oct 1999, midnight
ORGANIZATION "SNMPv3 Working Group" ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@lists@tislabs.com.com CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com
Subscribe: majordomo@lists@tislabs.com.com Subscribe: majordomo@lists.tislabs.com
In msg body: subscribe snmpv3 In msg body: subscribe snmpv3
Chair: Russ Mundy Chair: Russ Mundy
TIS Labs at Network Associates TIS Labs at Network Associates
Postal: 3060 Washington Rd Postal: 3060 Washington Rd
Glenwood MD 21738 Glenwood MD 21738
USA USA
Email: mundy@tislabs.com Email: mundy@tislabs.com
Phone: +1-301-854-6889 Phone: +1-301-854-6889
Co-editor: Rob Frye Co-editor: Rob Frye
MCI WorldCom MCI WorldCom
Postal: 2100 Reston Parkway, Suite 600 Postal: 2100 Reston Parkway, Suite 600
Reston, VA 20191 Reston, VA 20191
USA USA
E-mail: Rob.Frye@wcom.com E-mail: Rob.Frye@wcom.com
Phone: +1 703 715 7225 Phone: +1 703 715 7225
Co-editor: David B. Levi Co-editor: David B. Levi
Nortel Networks Nortel Networks
skipping to change at page 35, line 36 skipping to change at page 36, line 38
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, SNMPv2c, and SNMPv3." between SNMPv1, SNMPv2c, and SNMPv3."
REVISION "199905130000Z" -- 13 May 1999 (same as LAST-UPDATED)
DESCRIPTION "The Initial Revision" DESCRIPTION "The Initial Revision"
REVISION "199910050000Z" -- 5 Oct 1999 (same as LAST-UPDATED)
DESCRIPTION "This version published as RFC xxxx"
-- RFC-editor assigns xxxx
::= { snmpModules 18 } ::= { 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
skipping to change at page 36, line 42 skipping to change at page 37, line 47
snmpCommunityIndex OBJECT-TYPE snmpCommunityIndex OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32)) SYNTAX SnmpAdminString (SIZE(1..32))
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
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The community string for which a row in this table "The community string for which a row in this table
represents a configuration." represents a configuration."
::= { snmpCommunityEntry 2 } ::= { snmpCommunityEntry 2 }
snmpCommunitySecurityName OBJECT-TYPE snmpCommunitySecurityName OBJECT-TYPE
SYNTAX SnmpAdminString SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A human readable string representing the corresponding "A human readable string representing the corresponding
value of snmpCommunityName in a Security Model value of snmpCommunityName in a Security Model
independent format." independent format."
::= { snmpCommunityEntry 3 } ::= { snmpCommunityEntry 3 }
snmpCommunityContextEngineID OBJECT-TYPE snmpCommunityContextEngineID OBJECT-TYPE
SYNTAX SnmpEngineID SYNTAX SnmpEngineID
skipping to change at page 38, line 43 skipping to change at page 39, line 48
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.
There is no restriction on setting columns in this table There is no restriction on setting columns in this table
when the value of snmpCommunityStatus is active(1)." when the value of snmpCommunityStatus is active(1)."
::= { snmpCommunityEntry 8 } ::= { snmpCommunityEntry 8 }
-- --
-- The snmpTargetAddrExtTable augments the snmpTargetAddrTable with -- The snmpTargetAddrExtTable
-- a transport address mask value and a maximum message size value.
-- The transport address mask allows entries in the
-- snmpTargetAddrTable to define a set of addresses instead of just
-- a single address. The maximum message size value allows the
-- maximum message size of another SNMP entity to be configured
-- for use in SNMPv1 (and SNMPv2c) transactions, where the message
-- format does not specify a maximum message size.
-- --
snmpTargetAddrExtTable OBJECT-TYPE snmpTargetAddrExtTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The table of mask and mms values associated with the "The table of mask and mms values associated with the
snmpTargetAddrTable." snmpTargetAddrTable.
The snmpTargetAddrExtTable augments the
snmpTargetAddrTable with a transport address mask value
and a maximum message size value. The transport address
mask allows entries in the snmpTargetAddrTable to define
a set of addresses instead of just a single address.
The maximum message size value allows the maximum
message size of another SNMP entity to be configured for
use in SNMPv1 (and SNMPv2c) transactions, where the
message format does not specify a maximum message size."
::= { snmpCommunityMIBObjects 2 } ::= { snmpCommunityMIBObjects 2 }
snmpTargetAddrExtEntry OBJECT-TYPE snmpTargetAddrExtEntry OBJECT-TYPE
SYNTAX SnmpTargetAddrExtEntry SYNTAX SnmpTargetAddrExtEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Information about a particular mask and mms value." "Information about a particular mask and mms value."
AUGMENTS { snmpTargetAddrEntry } AUGMENTS { snmpTargetAddrEntry }
::= { snmpTargetAddrExtTable 1 } ::= { snmpTargetAddrExtTable 1 }
skipping to change at page 40, line 8 skipping to change at page 41, line 17
instance of snmpTargetAddrTAddress, in order for the instance of snmpTargetAddrTAddress, in order for the
transport address to match a particular entry in the transport address to match a particular entry in the
snmpTargetAddrTable. Bits which are 1 in the mask snmpTargetAddrTable. Bits which are 1 in the mask
value indicate bits in the transport address which value indicate bits in the transport address which
must match bits in the snmpTargetAddrTAddress value. must match bits in the snmpTargetAddrTAddress value.
Bits which are 0 in the mask indicate bits in the Bits which are 0 in the mask indicate bits in the
transport address which need not match. If the transport address which need not match. If the
length of the mask is 0, the mask should be treated length of the mask is 0, the mask should be treated
as if all its bits were 1 and its length were equal as if all its bits were 1 and its length were equal
to the length of the corresponding value of to the length of the corresponding value of
snmpTargetAddrTable." snmpTargetAddrTable.
This object may not be modified while the value of the
corresponding instance of snmpTargetAddrRowStatus is
active(1). An attempt to set this object in this case
will result in an inconsistentValue error."
DEFVAL { ''H } DEFVAL { ''H }
::= { snmpTargetAddrExtEntry 1 } ::= { snmpTargetAddrExtEntry 1 }
snmpTargetAddrMMS OBJECT-TYPE snmpTargetAddrMMS OBJECT-TYPE
SYNTAX Integer32 (0|484..65535) SYNTAX Integer32 (0|484..2147483647)
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The maximum message size value associated with an entry "The maximum message size value associated with an entry
in the snmpTargetAddrTable. The default value of 1472 in the snmpTargetAddrTable."
is the maximum size of the data portion of a UDP packet DEFVAL { 484 }
carried in an ethernet frame (i.e. the maximum size of
an SNMP packet using UDP)."
DEFVAL { 1472 }
::= { snmpTargetAddrExtEntry 2 } ::= { snmpTargetAddrExtEntry 2 }
-- --
-- The snmpTrapAddress and snmpTrapCommunity objects are included -- The snmpTrapAddress and snmpTrapCommunity objects are included
-- in notifications that are forwarded by a proxy, which were -- in notifications that are forwarded by a proxy, which were
-- originally received as SNMPv1 Trap messages. -- originally received as SNMPv1 Trap messages.
-- --
snmpTrapAddress OBJECT-TYPE snmpTrapAddress OBJECT-TYPE
SYNTAX IpAddress SYNTAX IpAddress
skipping to change at page 51, line 4 skipping to change at line 2011
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents
1 Overview ..................................................... 4
1.1 SNMPv1 ..................................................... 4
1.2 SNMPv2 ..................................................... 5
1.3 SNMPv3 ..................................................... 6
1.4 SNMPv1 and SNMPv2 MIB Instrumentation ...................... 6
2 SMI and Management Information Mappings ...................... 8
2.1 MIB Modules ................................................ 8
2.1.1 Object Definitions ....................................... 8
2.1.2 Trap and Notification Definitions ........................ 10
2.2 Compliance Statements ...................................... 11
2.3 Capabilities Statements .................................... 11
3 Translating Notifications Parameters ......................... 13
3.1 Translating SNMPv1 Notification Parameters to SNMPv2
Notification Parameters ................................... 14
3.2 Translating SNMPv2 Notification Parameters to SNMPv1
Notification Parameters ................................... 15
4 Approaches to Coexistence in a Multi-lingual Network ......... 18
4.1 Multi-lingual implementations .............................. 18
4.1.1 Command Generator ........................................ 18
4.1.2 Command Responder ........................................ 19
4.1.2.1 Handling Counter64 ..................................... 19
4.1.2.2 Mapping SNMPv2 Exceptions .............................. 20
4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 21
4.1.2.2.2 Mapping endOfMibView ................................. 21
4.1.2.3 Processing An SNMPv1 GetRequest ........................ 21
4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 22
4.1.3 Notification Originator .................................. 23
4.1.4 Notification Receiver .................................... 24
4.2 Proxy Implementations ...................................... 25
4.2.1 Deployment Hint .......................................... 27
4.3 Error Status Mappings ...................................... 27
5 Message Processing Models and Security Models ................ 29
5.1 Mappings ................................................... 29
5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security
Model ..................................................... 29
5.2.1 Processing An Incoming Request ........................... 30
5.2.2 Generating An Outgoing Response .......................... 32
5.2.3 Generating An Outgoing Notification ...................... 32
5.3 The SNMP Community MIB Module .............................. 33
6 Intellectual Property ........................................ 44
7 Acknowledgments .............................................. 45
8 Security Considerations ...................................... 46
9 References ................................................... 47
10 Editor's Address ............................................ 49
A. Full Copyright Statement .................................... 50
 End of changes. 73 change blocks. 
178 lines changed or deleted 308 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/