draft-ietf-snmpv3-coex-03.txt   draft-ietf-snmpv3-coex-04.txt 
INTERNET-DRAFT Rob Frye INTERNET-DRAFT Rob Frye
MCI Communications Corp. MCI WorldCom
David B. Levi David B. Levi
SNMP Research, Inc. 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-03.txt> <draft-ietf-snmpv3-coex-04.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 3, line 7 skipping to change at page 4, line 5
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 MIB Instrumentation ...................... 6
2 SMI and Management Information Mappings ...................... 8
2.1 Object Definitions ......................................... 8
2.2 Trap and Notification Definitions .......................... 10
2.3 Compliance Statements ...................................... 11
2.4 Capabilities Statements .................................... 11
3 Translating Notifications Parameters ......................... 13
3.1 Translating SNMPv1 Notification Parameters to SNMPv2 No-
tification Parameters ..................................... 14
3.2 Translating SNMPv2 Notification Parameters to SNMPv1 No-
tification Parameters ..................................... 15
4 Approaches to Coexistence in a Multi-lingual Network ......... 18
4.1 Multi-lingual implementations .............................. 18
4.1.1 Command Generator ........................................ 18
4.1.2 Command Responder ........................................ 18
4.1.2.1 Handling Counter64 ..................................... 19
4.1.2.2 Mapping SNMPv2 Exceptions .............................. 20
4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 20
4.1.2.2.2 Mapping endOfMibView ................................. 21
4.1.2.3 Processing An SNMPv1 GetRequest ........................ 21
4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 22
4.1.3 Notification Originator .................................. 23
4.1.4 Notification Receiver .................................... 24
4.2 Proxy Implementations ...................................... 24
4.3 Error Status Mappings ...................................... 26
5 Message Processing Models and Security Models ................ 27
5.1 Mappings ................................................... 27
5.2 The SNMPv1 Message Processing Model ........................ 27
5.2.1 Processing An Incoming Request ........................... 28
5.2.2 Generating An Outgoing Response .......................... 30
5.2.3 Generating An Outgoing Notification ...................... 30
5.3 The SNMP Community MIB Module .............................. 31
6 Intellectual Property ........................................ 41
7 Acknowledgments .............................................. 42
8 Security Considerations ...................................... 43
9 References ................................................... 44
10 Editor's Address ............................................ 46
A. Full Copyright Statement .................................... 47
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 4, line 44 skipping to change at page 4, line 44
Security Model, which provides mechanisms for adapting SNMPv1 Security Model, which provides mechanisms for adapting SNMPv1
into the View-Based Access Control Model (VACM) [20], is into the View-Based Access Control Model (VACM) [20], is
documented in section 5 (this section also addresses the documented in section 5 (this section also addresses the
SNMPv2c Message Processing Model and Community-Based Security SNMPv2c Message Processing Model and Community-Based Security
Model). Model).
1.1. SNMPv1 1.1. SNMPv1
SNMPv1 is defined by these documents: SNMPv1 is defined by these documents:
- STD 15, RFC 1157 [2] which defines the Simple Network
Management Protocol (SNMPv1), the protocol used for network
access to managed objects.
- STD 16, RFC 1155 [1] which defines the Structure of Management - STD 16, RFC 1155 [1] which defines the Structure of Management
Information (SMIv1), the mechanisms used for describing and Information (SMIv1), the mechanisms used for describing and
naming objects for the purpose of management. naming objects for the purpose of management.
- STD 16, RFC 1212 [3] which defines a more concise description - STD 16, RFC 1212 [3] which defines a more concise description
mechanism, which is wholly consistent with the SMIv1. mechanism, which is wholly consistent with the SMIv1.
- STD 15, RFC 1157 [2] which defines the Simple Network
Management Protocol (SNMPv1), the protocol used for network
access to managed objects.
- RFC 1215 [4] which defines a convention for defining Traps for - RFC 1215 [4] which defines a convention for defining Traps for
use with the SMIv1. use with the SMIv1.
Note that throughout this document, the term 'SMIv1' is used. This Note that throughout this document, the term 'SMIv1' is used. This
term generally refers to the information presented in RFC 1155, RFC term generally refers to the information presented in RFC 1155, RFC
1212, and RFC 1215. 1212, and RFC 1215.
1.2. SNMPv2 1.2. SNMPv2
SNMPv2 is defined by these documents: SNMPv2 is defined by these documents:
- RFC 1902 which defines Version 2 of the Structure of - STD 58, RFC 2578 which defines Version 2 of the Structure of
Management Information (SMIv2) [7]. Management Information (SMIv2) [7].
- RFC 1903 which defines common MIB "Textual Conventions" [8]. - STD 58, RFC 2579 which defines common MIB "Textual
Conventions" [8].
- RFC 1904 which defines Conformance Statements and requirements - STD 58, RFC 2580 which defines Conformance Statements and
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]. upon which other MIBs can be built [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 1902, 1903, and 1904). 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.
1.3. SNMPv3 1.3. SNMPv3
SNMPv3 is defined by these documents: SNMPv3 is defined by these documents:
- RFC 2271 which defines an Architecture for Describing SNMP - RFC 2571 which defines an Architecture for Describing SNMP
Management Frameworks [16]. Management Frameworks [16].
- RFC 2272 which defines Message Processing and Dispatching - RFC 2572 which defines Message Processing and Dispatching
[17]. [17].
- RFC 2273 which defines various SNMP Applications [18]. - RFC 2573 which defines various SNMP Applications [18].
- RFC 2274 which defines the User-based Security Model (USM), - RFC 2574 which defines the User-based Security Model (USM),
providing for both Authenticated and Private (encrypted) SNMP providing for both Authenticated and Private (encrypted) SNMP
messages [19]. messages [19].
- RFC 2275 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 1902 through 1907 SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 and
described above. the SMIv2 definitions of 2578 through 2580 described above.
1.4. SNMPv1 and SNMPv2 MIB Instrumentation 1.4. SNMPv1 and SNMPv2 MIB Instrumentation
In several places, this document refers to 'SNMPv1 MIB In several places, this document refers to 'SNMPv1 MIB
Instrumentation' and 'SNMPv2 MIB Instrumentation'. These terms refer Instrumentation' and 'SNMPv2 MIB Instrumentation'. These terms refer
to the part of an SNMP agent which actually implements MIB objects, to the part of an SNMP agent which actually implements 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 MIB instrumentation 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 will generate SNMPv1 error-status values, SNMPv1 MIB instrumentation 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 MIB instrumentation 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 will generate SNMPv2 error-status values, SNMPv2 MIB instrumentation may generate SNMPv2 error-status values,
will generate exception codes, will 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 MIB instrumentation 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 MIB instrumentation as SNMPv2 MIB instrumentation.
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.
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.
2.1. MIB Modules
MIB modules defined using the SMIv1 may continue to be used with MIB modules defined using the SMIv1 may continue to be used with
protocol versions which use SNMPv2 PDUs. However, for the MIB protocol versions which use SNMPv2 PDUs. However, for the MIB
modules to conform to the SMIv2, the following changes SHALL be made: modules to conform to the SMIv2, the following changes SHALL be made:
2.1. Object Definitions 2.1.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. If the semantics of an deprecation of the objects contained therein. If the semantics of an
object truly changes, the object SHALL be deprecated, otherwise object truly changes, the object SHALL be deprecated, otherwise
deprecation is not required. 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
skipping to change at page 9, line 11 skipping to change at page 9, line 16
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.
(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"
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
(8) For all objects, if the value of the STATUS clause is "optional", objects.
the value MUST be replaced with "obsolete".
(9) 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.
(10) 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.
(11) For any object with an INDEX clause that references an object with (10) If any INDEX clause contains a reference to an object with a syntax
a syntax of NetworkAddress, the value of the STATUS clause of both of NetworkAddress, then a new object MUST be created and placed in
objects MUST be changed to "obsolete". this INDEX clause immediately preceding the object whose syntax is
NetworkAddress. This new object MUST have a syntax of INTEGER, it
MUST be not-accessible, and its value MUST always be 1.
(11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be
changed to IpAddress.
(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 objects in order to define the
single 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
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 new approach can
be found in section 7 of RFC1902 [7], and the RowStatus and be found in section 7 of RFC2578 [7], and the RowStatus and
StorageType TEXTUAL-CONVENTIONs are described in section 2 of StorageType TEXTUAL-CONVENTIONs are described in section 2 of
RFC1903 [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
would not necessitate deprecating objects previously defined using would not necessitate deprecating objects previously defined using
skipping to change at page 10, line 32 skipping to change at page 10, line 40
(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 MUST be 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) MUST be changed to of that object (and all subordinate objects) MUST be changed to
"obsolete". "obsolete".
2.2. Trap and Notification Definitions 2.1.2. Trap and Notification Definitions
If a MIB module is changed to conform to the SMIv2, then each If a MIB module is changed to conform to the SMIv2, then each
occurrence of the TRAP-TYPE macro MUST be changed to a corresponding 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) 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 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. invocation of the TRAP-TYPE. If the value of the ENTERPRISE clause
is 'snmp', then the value of the invocation of the NOTIFICATION-
TYPE macro SHALL be mapped in the same manner as described in
section 3.1 in this document.
(6) 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.2. Compliance Statements
For those information modules which are "standard", a corresponding For those information modules which are "standards track", a
invocation of the MODULE-COMPLIANCE macro and related OBJECT-GROUP corresponding invocation of the MODULE-COMPLIANCE macro and related
macros MUST be included within the information module (or in a OBJECT-GROUP macros MUST be included within the information module
companion information module), and any commentary text in the (or in a companion information module), and any commentary text in
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.
2.4. Capabilities Statements Note that it is always good practice to add compliance statements to
a MIB document, even if the document is not on the standards track.
In the SMIv1, RFC1303 [5] uses the MODULE-CONFORMANCE macro to 2.3. Capabilities Statements
describe an agent's capabilities with respect to one or more MIB
modules. Converting such a description for use with the SMIv2 RFC1303 [5] uses the MODULE-CONFORMANCE macro to describe an agent's
requires these changes: capabilities with respect to one or more MIB modules. Converting
such a description for use with the SMIv2 requires these changes:
(1) The macro name AGENT-CAPABILITIES SHOULD be used instead of MODULE- (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 SHOULD 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 RFC1904 [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
skipping to change at page 15, line 23 skipping to change at page 15, line 23
2 1.3.6.1.6.3.1.1.5.3 (linkDown) 2 1.3.6.1.6.3.1.1.5.3 (linkDown)
3 1.3.6.1.6.3.1.1.5.4 (linkUp) 3 1.3.6.1.6.3.1.1.5.4 (linkUp)
4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 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 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)
(4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-bindings. (4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-bindings.
In addition, if the translation is being performed by a proxy in In addition, if the translation is being performed by a proxy in
order to forward a received trap, three additional variable- order to forward a received trap, three additional variable-
bindings will be appended, if these three additional variable- bindings will be appended, if these three additional variable-
bindings do not already exist in the SNMPv1 variable-bindings. The bindings do not already exist in the SNMPv1 variable-bindings. The
name portion of the first variable binding SHALL contain name portion of the first additional variable binding SHALL contain
snmpTrapAddress.0, and the value SHALL contain the SNMPv1 agent- snmpTrapAddress.0, and the value SHALL contain the SNMPv1 agent-
addr parameter. The name portion of the second variable binding addr parameter. The name portion of the second additional variable
SHALL contain snmpTrapCommunity.0, and the value SHALL contain the binding SHALL contain snmpTrapCommunity.0, and the value SHALL
value of the community-string field from the received SNMPv1 contain the value of the community-string field from the received
message which contained the SNMPv1 Trap-PDU. The name portion of SNMPv1 message which contained the SNMPv1 Trap-PDU. The name
the third variable binding SHALL contain snmpTrapEnterprise.0 [12], portion of the third additional variable binding SHALL contain
and the value SHALL be the SNMPv1 enterprise parameter. snmpTrapEnterprise.0 [12], and the value SHALL be the SNMPv1
enterprise parameter.
3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification 3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification
Parameters 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 parameter SHALL be determined as follows: (1) The SNMPv1 enterprise parameter SHALL be determined as follows:
- If the SNMPv2 snmpTrapOID parameter is one of the standard - If the SNMPv2 snmpTrapOID parameter is one of the standard
skipping to change at page 16, line 30 skipping to change at page 16, line 30
situation in 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 IP, the application, and the notification is to be sent over IP, the
SNMPv1 agent-addr parameter SHALL be set to the IP address of SNMPv1 agent-addr parameter SHALL be set to the IP address of
the SNMP entity in which the notification originator resides. the SNMP entity in which the notification originator resides.
If the notification is to be sent over some other transport, If the notification is to be sent over some other transport,
the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0. the SNMPv1 agent-addr parameter 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 extract the original source of the
notification. If the SNMPv2 variable-bindings contains a notification from the variable-bindings. If the SNMPv2
variable binding whose name is snmpTrapAddress.0, the agent- variable-bindings contains a variable binding whose name is
addr parameter SHALL be set to the value of that variable snmpTrapAddress.0, the agent-addr parameter SHALL be set to
binding. Otherwise, Otherwise, the SNMPv1 agent-addr the value of that variable binding. Otherwise, the SNMPv1
parameter SHALL be set to 0.0.0.0. agent-addr parameter SHALL be set to 0.0.0.0.
(3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as (3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as
defined in RFC1907 [12], the SNMPv1 generic-trap parameter SHALL be defined in RFC1907 [12], the SNMPv1 generic-trap parameter SHALL be
set as follows: set as follows:
snmpTrapOID.0 parameter generic-trap snmpTrapOID.0 parameter generic-trap
=============================== ============ =============================== ============
1.3.6.1.6.3.1.1.5.1 (coldStart) 0 1.3.6.1.6.3.1.1.5.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
skipping to change at page 17, line 14 skipping to change at page 17, line 14
(4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as (4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as
defined in RFC1907 [12], the SNMPv1 specific-trap parameter SHALL defined in RFC1907 [12], the SNMPv1 specific-trap parameter SHALL
be set to zero. Otherwise, the SNMPv1 specific-trap parameter be set to zero. Otherwise, the SNMPv1 specific-trap parameter
SHALL be set to the last sub-identifier of the SNMPv2 snmpTrapOID SHALL be set to the last sub-identifier of the SNMPv2 snmpTrapOID
parameter. parameter.
(5) The SNMPv1 time-stamp parameter SHALL be taken directly from the (5) The SNMPv1 time-stamp parameter SHALL be taken directly from the
SNMPv2 sysUpTime parameter. SNMPv2 sysUpTime parameter.
(6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-bindings (6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-bindings.
with the following exceptions: Note, however, that if the SNMPv2 variable-bindings contain any
objects whose type is Counter64, the translation to SNMPv1
- Any variable-binding whose type is Counter64 which exists in notification parameters cannot be performed. In this case, the
the SNMPv2 variable-bindings SHALL be removed. notification cannot be encoded in an SNMPv1 packet (and so the
notification cannot be sent using SNMPv1, see section 4.1.3 and
section 4.2).
4. Approaches to Coexistence in a Multi-lingual Network 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 implementation to communicate support. This allows a multi-lingual implementation 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.
skipping to change at page 18, line 40 skipping to change at page 18, line 40
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 should 'downgrade' GetBulk requests
to GetNext requests when selecting SNMPv1 as the message version for to GetNext requests when selecting SNMPv1 as the message version for
an outgoing request. an outgoing request. This is done by simply changing the operation
type to GetNext, ignoring any non-repeaters and max-repetitions
values, and setting error-status and error-index to zero.
4.1.2. Command Responder 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 MIB instrumentation that returns - Deal correctly with SNMPv2 MIB instrumentation that returns
one of the three exception values while processing an SNMPv1 one 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 MIB
instrumentation into SNMPv1 error code when processing an instrumentation 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 can be used without any change when
processing SNMPv2c or SNMPv3 messages. processing SNMPv2c or SNMPv3 messages.
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 has access to some combination of SNMPv1 and SNMPv2 MIB
instrumentation. instrumentation.
skipping to change at page 20, line 42 skipping to change at page 20, line 49
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
implementation choice as to which variable binding the error-index
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 SNMPv2 MIB
instrumentation indicates that the requested object instance can not instrumentation indicates that the requested object instance can not
be returned. The SNMPv1 error code for this condition is noSuchName, be returned. The SNMPv1 error code for this condition is noSuchName,
and so the error-status field of the response PDU SHALL be set to and so the error-status field of the response PDU SHALL be set to
noSuchName. Also, the error-index field SHALL be set to the index of noSuchName. Also, the error-index field SHALL be set to the index of
the variable binding for which an exception occurred, and the the variable binding for which an exception occurred, and the
variable binding list from the original request SHALL be returned variable binding list from the original request SHALL be returned
with the response PDU. with the response PDU.
Note that when a response contains multiple exceptions, it is an
implementation choice as to which variable binding the error-index
should reference.
4.1.2.2.2. Mapping endOfMibView 4.1.2.2.2. Mapping endOfMibView
When SNMPv2 MIB instrumentation returns a variable binding containing When SNMPv2 MIB instrumentation returns a variable binding containing
an endOfMibView exception, it indicates that there are no object an endOfMibView exception, it indicates that there are no object
instances available which lexicographically follow the object in the instances available which lexicographically follow the object in the
request. In an SNMPv1 agent, this condition normally results in a request. In an SNMPv1 agent, this condition normally results in a
noSuchName error, and so the error-status field of the response PDU noSuchName error, and so the error-status field of the response PDU
SHALL be set to noSuchName. Also, the error-index field SHALL be set 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 SHALL be and the variable binding list from the original request SHALL be
returned with the response PDU. returned with the response PDU.
Note that when a response contains multiple exceptions, it is an
implementation choice as to which variable binding the error-index
should reference.
4.1.2.3. Processing An SNMPv1 GetRequest 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 calling SNMPv2 MIB instrumentation.
When such MIB instrumentation returns response data using SNMPv2 When such MIB instrumentation 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,
skipping to change at page 24, line 9 skipping to change at page 24, line 12
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
MIB instrumentation presents a notification using SNMPv1 notification MIB instrumentation presents a notification using SNMPv1 notification
parameters, and configuration information specifies that parameters, and configuration information specifies that
notifications be sent using SNMPv2c or SNMPv3, the notification notifications be sent using SNMPv2c or SNMPv3, the notification
parameters must be translated to SNMPv2 notification parameters. parameters must be translated to SNMPv2 notification parameters.
Likewise, if MIB instrumentation presents a notification using SNMPv2 Likewise, if MIB instrumentation presents a notification using SNMPv2
notification parameters, and configuration information specifies that notification parameters, and configuration information specifies that
notifications be sent using SNMPv1, the notification parameters must notifications be sent using SNMPv1, the notification parameters must
be translated to SNMPv1 notification parameters. be translated to SNMPv1 notification parameters. In this case, if
the notification cannot be translated (due to the presence of a
Counter64 type), it will not be sent using SNMPv1.
When a notification originator generates a notification, using 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
skipping to change at page 25, line 16 skipping to change at page 25, line 23
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', and the message will be forwarded using
the SNMPv2c or SNMPv3 message version, the proxy forwarder the SNMPv2c or SNMPv3 message version, the proxy forwarder
SHALL remove the contents of the variable-bindings field SHALL remove the contents of the variable-bindings field
before forwarding the response. before forwarding the response.
- If a GetResponse-PDU is received which contains variable- - If a GetResponse-PDU is received in response to a GetRequest-
bindings of type Counter64 or which contain an SNMPv2 PDU (previously generated by the proxy) which contains
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
containing the Counter64 type or exception code. containing the Counter64 type or exception code.
- If a GetResponse-PDU is received in response to a
GetNextRequest-PDU (previously generated by the proxy) which
contains variable-bindings that 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 exception
code.
- If a GetResponse-PDU is received in response to a
GetNextRequest-PDU (previously generated by the proxy) which
contains variable-bindings of type Counter64, the proxy MUST
re-send the entire GetNextRequest-PDU, with the following
modifications. For any variable bindings in the received
GetResponse which contained Counter64 types, the proxy
substitutes the object names of these variable bindings for
the corresponding object names in the previously-sent
GetNextRequest. The proxy MUST repeat this process until no
Counter64 objects are returned. Note that an implementation
may attempt to optimize this process of skipping Counter64
objects. One approach to such an optimization would be to
replace the last sub-identifier of the object names of
varbinds containing a Counter64 type with 65535 if that sub-
identifier is less than 65535, or with 4294967295 if that
sub-identifier is greater than 65535. This approach should
skip multiple instances of the same Counter64 object, while
maintaining compatibility with some broken agent
implementations (which only use 16-bit integers for sub-
identifiers).
- 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 - If a Trap-PDU is received, and will be forwarded using the
SNMPv2c or SNMPv3 message version, the proxy SHALL apply the SNMPv2c or SNMPv3 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 an SNMPv2-Trap-PDU. 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. the notification as a Trap-PDU. Note that if the translation
fails dues to the existence of a Counter64 data-type in the
received SNMPv2-Trap-PDU, the trap cannot be forwarded using
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. version. The InformRequest-PDU may still be forwarded if
there is other configuration information indicating that it
should be forwarded using SNMPv2c or SNMPv3.
- In all other cases, the proxy SHALL forward a received PDU - In all other cases, the proxy SHALL forward a received PDU
without change. without change.
Note that when an SNMPv1 agent generates a message containing a Note that when an SNMPv1 agent generates a message containing a
Trap-PDU which is subsequently forwarded by one or more proxy Trap-PDU which is subsequently forwarded by one or more proxy
forwarders using SNMP versions other than SNMPv1, the community forwarders using SNMP versions other than SNMPv1, the community
string and agent-addr fields from the original message generated by string and agent-addr fields from the original message generated by
the SNMPv1 agent will be preserved through the use of the the SNMPv1 agent will be preserved through the use of the
snmpTrapAddress and snmpTrapCommunity objects. 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 27, line 44 skipping to change at page 29, line 44
messages, and the version independent parameters used in the SNMP messages, and the version independent parameters used in the SNMP
architecture [16]. The parameters which MUST be mapped consist of the architecture [16]. The parameters which MUST be mapped consist of the
SNMPv1 (and SNMPv2c) community name, and the SNMP securityName and SNMPv1 (and SNMPv2c) community name, and the SNMP securityName and
contextEngineID/contextName pair. A MIB module (the SNMP-COMMUNITY-MIB) contextEngineID/contextName pair. A MIB module (the SNMP-COMMUNITY-MIB)
is provided in this document in order to perform these mappings. This is provided in this document in order to perform these mappings. This
MIB provides mappings in both directions, that is, a community name may MIB provides mappings in both directions, that is, a community name may
be mapped to a securityName, contextEngineID, and contextName, or the be mapped to a securityName, contextEngineID, and contextName, or the
combination of securityName, contextEngineID, and contextName may be combination of securityName, contextEngineID, and contextName may be
mapped to a community name. mapped to a community name.
5.2. The SNMPv1 Message Processing Model 5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model
The SNMPv1 Message Processing Model handles processing of SNMPv1 The SNMPv1 Message Processing Model handles processing of SNMPv1
messages. The processing of messages is handled generally in the messages. The processing of messages is handled generally in the
same manner as described in RFC1157 [2], with differences and same manner as described in RFC1157 [2], with differences and
clarifications as described in the following sections. The clarifications as described in the following sections. The
SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for
SNMPv2c is 1). SNMPv2c is 1).
5.2.1. Processing An Incoming Request 5.2.1. Processing An Incoming Request
skipping to change at page 28, line 24 skipping to change at page 30, line 24
this ASI are: this ASI are:
- The messageProcessingModel, which will be 0 (or 1 for - The messageProcessingModel, which will be 0 (or 1 for
SNMPv2c). SNMPv2c).
- The maxMessageSize, which should be the maximum size of a - The maxMessageSize, which should be the maximum size of a
message that the receiving entity can generate (since there is message that the receiving entity can generate (since there is
no such value in the received message). no such value in the received message).
- The securityParameters, which consist of the community string - The securityParameters, which consist of the community string
and the message's source and destination transport addresses. and the message's source and destination transport domains and
addresses.
- The securityModel, which will be 1 (or 2 for SNMPv2c). - The securityModel, which will be 1 (or 2 for SNMPv2c).
- The securityLevel, which will be noAuthNoPriv. - The securityLevel, which will be noAuthNoPriv.
- The wholeMsg and wholeMsgLength. - The wholeMsg and wholeMsgLength.
The Community-Based Security Model will attempt to select a row in The Community-Based Security Model will attempt to select a row in
the snmpCommunityTable. This is done by performing a search through the snmpCommunityTable. This is done by performing a search through
the snmpCommunityTable in lexicographic order. The first entry for the snmpCommunityTable in lexicographic order. The first entry for
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 not an empty string, the - If the snmpCommunityTransportTag is an empty string, it is
ignored for the purpose of matching. If 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. If the snmpCommunityTransportTag is an empty string, value.
it is ignored for the purpose of matching.
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].
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.
skipping to change at page 30, line 43 skipping to change at page 32, line 43
- The securityName must be equal to the - The securityName must be equal to the
snmpCommunitySecurityName value. snmpCommunitySecurityName value.
- The contextEngineID must be equal to the - The contextEngineID must be equal to the
snmpCommunityContextEngineID value. snmpCommunityContextEngineID value.
- The contextName must be equal to the snmpCommunityContextName - The contextName must be equal to the snmpCommunityContextName
value. value.
- If the snmpCommunityTransportTag is not an empty string, the - If the snmpCommunityTransportTag is an empty string, it is
ignored for the purpose of matching. If the
snmpCommunityTransportTag is not an empty string, the
transportDomain and transportAddress must match one of the transportDomain and transportAddress must match one of the
entries in the snmpTargetAddrTable selected by the entries in the snmpTargetAddrTable selected by the
snmpCommunityTransportTag value. If the snmpCommunityTransportTag value.
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. If no such entry can be found, the notification is not sent.
Otherwise, the community string used in the outgoing notification Otherwise, the community string used in the outgoing notification
will be the value of the snmpCommunityName column of the selected will be the value of the snmpCommunityName column of the selected
row. row.
5.3. The SNMP Community MIB Module 5.3. The SNMP Community MIB Module
The SNMP-COMMUNITY-MIB contains objects for mapping between community The SNMP-COMMUNITY-MIB contains objects for mapping between community
strings and version-independent SNMP message parameters. In strings and version-independent SNMP message parameters. In
skipping to change at page 32, line 15 skipping to change at page 34, line 15
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
IMPORTS IMPORTS
IpAddress IpAddress,
FROM RFC1155-SMI
MODULE-IDENTITY, MODULE-IDENTITY,
OBJECT-TYPE, OBJECT-TYPE,
Integer32, Integer32,
snmpModules
FROM SNMPv2-SMI FROM SNMPv2-SMI
RowStatus, RowStatus,
TestAndIncr,
StorageType StorageType
FROM SNMPv2-TC FROM SNMPv2-TC
SnmpAdminString SnmpAdminString,
snmpEngineID
FROM SNMP-FRAMEWORK-MIB FROM SNMP-FRAMEWORK-MIB
SnmpTagValue SnmpTagValue,
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 "9805110000Z" -- 11 May 1998, midnight LAST-UPDATED "199905130000Z" -- 13 May 1999, midnight
ORGANIZATION "SNMPv3 Working Group" ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@tis.com CONTACT-INFO "WG-email: snmpv3@lists@tislabs.com.com
Subscribe: majordomo@tis.com Subscribe: majordomo@lists@tislabs.com.com
In msg body: subscribe snmpv3 In msg body: subscribe snmpv3
Chair: Russ Mundy Chair: Russ Mundy
Trusted Information Systems TIS Labs at Network Associates
postal: 3060 Washington Rd Postal: 3060 Washington Rd
Glenwood MD 21738 Glenwood MD 21738
USA USA
email: mundy@tis.com Email: mundy@tislabs.com
phone: +1-301-854-6889 Phone: +1-301-854-6889
Co-editor: Rob Frye Co-editor: Rob Frye
MCI Communications Corp. 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@mci.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
SNMP Research, Inc. Nortel Networks
Postal: 3001 Kimberlin Heights Road Postal: 3505 Kesterwood Drive
Knoxville, TN 37920-9716 Knoxville, TN 37918
E-mail: levi@snmp.com E-mail: dlevi@nortelnetworks.com
Phone: +1 423 573 1434 Phone: +1 423 686 0432
Co-editor: Shawn A. Routhier Co-editor: Shawn A. Routhier
Integrated Systems Inc. Integrated Systems Inc.
Postal: 333 North Ave 4th Floor Postal: 333 North Ave 4th Floor
Wakefield, MA 01880 Wakefield, MA 01880
E-mail: sar@epilogue.com E-mail: sar@epilogue.com
Phone: +1 781 245 0804 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, SNMPv2c, and SNMPv3."
REVISION "199905130000Z" -- 13 May 1999 (same as LAST-UPDATED)
DESCRIPTION "The Initial Revision"
::= { 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 35, line 25 skipping to change at page 37, line 28
"The contextEngineID indicating the location of the "The contextEngineID indicating the location of the
context in which management information is accessed context in which management information is accessed
when using the community string specified by the when using the community string specified by the
corresponding instance of snmpCommunityName. corresponding instance of snmpCommunityName.
The default value is the snmpEngineID of the entity in The default value is the snmpEngineID of the entity in
which this object is instantiated." which this object is instantiated."
::= { snmpCommunityEntry 4 } ::= { snmpCommunityEntry 4 }
snmpCommunityContextName OBJECT-TYPE snmpCommunityContextName OBJECT-TYPE
SYNTAX SnmpAdminString SYNTAX SnmpAdminString (SIZE(0..32))
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 }
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 a command responder application will accept
If a management request containing this community management requests. If a management request containing
is received on a transport endpoint other than the this community is received on a transport endpoint other
transport endpoints identified by this object, the than the transport endpoints identified by this object,
request is deemed unauthentic. the request is deemed unauthentic.
The transports identified by this object are specified The transports identified by this object are specified
in the snmpTargetAddrTable. 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
skipping to change at page 36, line 33 skipping to change at page 38, line 36
SYNTAX RowStatus SYNTAX RowStatus
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
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.
There is no restriction on setting columns in this table
when the value of snmpCommunityStatus is active(1)."
::= { snmpCommunityEntry 8 } ::= { snmpCommunityEntry 8 }
-- --
-- The snmpTargetAddrExtTable augments the snmpTargetAddrTable with -- The snmpTargetAddrExtTable augments the snmpTargetAddrTable with
-- a transport address mask value and a maximum message size value. -- a transport address mask value and a maximum message size value.
-- The transport address mask allows entries in the -- The transport address mask allows entries in the
-- snmpTargetAddrTable to define a set of addresses instead of just -- snmpTargetAddrTable to define a set of addresses instead of just
-- a single address. The maximum message size value allows the -- a single address. The maximum message size value allows the
-- maximum message size of another SNMP entity to be configured -- maximum message size of another SNMP entity to be configured
-- for use in SNMPv1 (and SNMPv2c) transactions, where the message -- for use in SNMPv1 (and SNMPv2c) transactions, where the message
skipping to change at page 37, line 30 skipping to change at page 39, line 38
} }
snmpTargetAddrTMask OBJECT-TYPE snmpTargetAddrTMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255)) SYNTAX OCTET STRING (SIZE (0..255))
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The mask value associated with an entry in the "The mask value associated with an entry in the
snmpTargetAddrTable. The value of this object must snmpTargetAddrTable. The value of this object must
have the same length as the corresponding instance of have the same length as the corresponding instance of
snmpTargetAddrTAddress, or must have length 0." snmpTargetAddrTAddress, or must have length 0. An
attempt to set it to any other value will result in
an inconsistentValue error.
The value of this object allows an entry in the
snmpTargetAddrTable to specify multiple addresses.
The mask value is used to select which bits of
a transport address must match bits of the corresponding
instance of snmpTargetAddrTAddress, in order for the
transport address to match a particular entry in the
snmpTargetAddrTable. Bits which are 1 in the mask
value indicate bits in the transport address which
must match bits in the snmpTargetAddrTAddress value.
Bits which are 0 in the mask indicate bits in the
transport address which need not match. If the
length of the mask is 0, the mask should be treated
as if all its bits were 1 and its length were equal
to the length of the corresponding value of
snmpTargetAddrTable."
DEFVAL { ''H } DEFVAL { ''H }
::= { snmpTargetAddrExtEntry 1 } ::= { snmpTargetAddrExtEntry 1 }
snmpTargetAddrMMS OBJECT-TYPE snmpTargetAddrMMS OBJECT-TYPE
SYNTAX Integer32 (484..65535) SYNTAX Integer32 (0|484..65535)
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." in the snmpTargetAddrTable. The default value of 1472
DEFVAL { 2048 } is the maximum size of the data portion of a UDP packet
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 39, line 4 skipping to change at page 41, line 32
DESCRIPTION DESCRIPTION
"The compliance statement for SNMP engines which "The compliance statement for SNMP engines which
implement the SNMP-COMMUNITY-MIB." implement the SNMP-COMMUNITY-MIB."
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS { snmpCommunityGroup } MANDATORY-GROUPS { snmpCommunityGroup }
OBJECT snmpCommunityName OBJECT snmpCommunityName
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION "Write access is not required." DESCRIPTION "Write access is not required."
OBJECT snmpCommunitySecurityName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunitySecurityLevel OBJECT snmpCommunitySecurityName
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."
skipping to change at page 39, line 34 skipping to change at page 42, line 12
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."
::= { snmpCommunityMIBCompliances 1 } ::= { snmpCommunityMIBCompliances 1 }
snmpProxyTrapForwardCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines which
contain a proxy forwarding application which is
capable of forwarding SNMPv1 traps using SNMPv2c
or SNMPv3."
MODULE -- this module
MANDATORY-GROUPS { snmpProxyTrapForwardGroup }
::= { snmpCommunityMIBCompliances 2 }
snmpCommunityGroup OBJECT-GROUP snmpCommunityGroup OBJECT-GROUP
OBJECTS { OBJECTS {
snmpCommunityIndex,
snmpCommunityName, snmpCommunityName,
snmpCommunitySecurityName, snmpCommunitySecurityName,
snmpCommunityContextEngineID, snmpCommunityContextEngineID,
snmpCommunityContextName, snmpCommunityContextName,
snmpCommunityTransportTag, snmpCommunityTransportTag,
snmpCommunityStorageType, snmpCommunityStorageType,
snmpCommunityStatus, snmpCommunityStatus,
snmpTargetAddrTMask, snmpTargetAddrTMask,
snmpTargetAddrMMS snmpTargetAddrMMS
} }
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 (and SNMPv2c) usage." of community strings for SNMPv1 (and SNMPv2c) usage."
::= { snmpCommunityMIBGroups 1 } ::= { snmpCommunityMIBGroups 1 }
snmpProxyTrapForwardGroup OBJECT-GROUP
OBJECTS {
snmpTrapAddress,
snmpTrapCommunity
}
STATUS current
DESCRIPTION
"Objects which are used by proxy forwarding applications
when translating traps between SNMP versions. These are
used to preserve SNMPv1-specific information when
translating to SNMPv2c or SNMPv3."
::= { snmpCommunityMIBGroups 3 }
END END
6. 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
skipping to change at page 42, line 15 skipping to change at page 45, line 15
7. 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. The design of the SNMP-COMMUNITY-MIB incorporates work done Group. The design of the SNMP-COMMUNITY-MIB incorporates work done
by the authors of SNMPv2*: by the authors of 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.)
Brian O'Keefe (Hewlett Packard) Brian O'Keefe (Hewlett Packard)
Jon Saperia (BGS Systems Inc.) Jon Saperia (IronBridge Networks, Inc.)
Steve Waldbusser (International Network Services) Steve Waldbusser (International Network Services)
8. 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.
skipping to change at page 44, line 32 skipping to change at page 47, line 32
[5] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP- [5] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP-
based Agents", RFC 1303, Hughes LAN Systems, Dover Beach based Agents", RFC 1303, Hughes LAN Systems, Dover Beach
Consulting, Inc., February 1992. Consulting, Inc., February 1992.
[6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Introduction to Community-based SNMPv2", RFC1901, SNMP 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.
[7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
Waldbusser, "Structure of Management Information for Version 2 of and S. Waldbusser, "Structure of Management Information Version 2
the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP (SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU
Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., Braunschweig, SNMP Research, First Virtual Holdings, International
International Network Services, January 1996. Network Services, April 1999.
[8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
Waldbusser, "Textual Conventions for Version 2 of the Simple and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD
Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc., 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First
Cisco Systems, Inc., Dover Beach Consulting, Inc., International Virtual Holdings, International Network Services, April 1999.
Network Services, January 1996.
[9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. [9] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.,
Waldbusser, "Conformance Statements for Version 2 of the Simple and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580,
Network Management Protocol (SNMPv2)", RFC 1904, January 1996. STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research,
First Virtual Holdings, International Network Services, April 1999.
[10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. [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.
[11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
Mappings for Version 2 of the Simple Network Management Protocol Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, January 1996. (SNMPv2)", RFC 1906, January 1996.
skipping to change at page 45, line 30 skipping to change at page 48, line 30
International Network Services, January 1996. International Network Services, January 1996.
[14] Levi, D., Wijnen, B., "Mapping SNMPv2 onto SNMPv1 within a bi- [14] Levi, D., Wijnen, B., "Mapping SNMPv2 onto SNMPv1 within a bi-
lingual SNMP agent", RFC2089, SNMP Research, Inc., IBM, January lingual SNMP agent", RFC2089, SNMP Research, Inc., IBM, January
1997. 1997.
[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[16] The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An [16] The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An
Architecture for Describing SNMP Management Frameworks", draft- Architecture for Describing SNMP Management Frameworks", RFC 2571,
ietf-snmpv3-arch-05.txt, February 1999. May 1999.
[17] The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B., [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)", draft-ietf-snmpv3-mpc-05.txt, February Management Protocol (SNMP)", RFC 2572, May 1999.
1999.
[18] The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMP [18] The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMP
Applications", draft-ietf-snmpv3-appl-v2-03.txt, February 1999. Applications", RFC2573, May 1999.
[19] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User- [19] 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)", draft-ietf-snmpv3-usm-v2-05.txt, February 1999. Protocol (SNMP)", RFC 2574, May 1999.
[20] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K., [20] 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)", draft-ietf-snmpv3-vacm-04.txt, February 1999. Protocol (SNMP)", RFC 2575, May 1999.
10. Editor's Address 10. Editor's Address
Rob Frye Rob Frye
MCI Communications Corp. MCI WorldCom
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@wcom.com
David B. Levi David B. Levi
SNMP Research, Inc. Nortel Networks
3001 Kimberlin Heights Road 3505 Kesterwood Drive
Knoxville, TN 37920-9716 Knoxville, TN 37918
U.S.A. U.S.A.
Phone: +1 423 573 1434 Phone: +1 423 686 0432
EMail: levi@snmp.com EMail: dlevi@nortelnetworks.com
Shawn A. Routhier Shawn A. Routhier
Integrated Systems Inc. Integrated Systems Inc.
333 North Ave 4th Floor 333 North Ave 4th Floor
Wakefield MA 01880 Wakefield MA 01880
U.S.A. U.S.A.
Phone: + 1 781 245 0804 Phone: + 1 781 245 0804
EMail: sar@epilogue.com EMail: sar@epilogue.com
Bert Wijnen Bert Wijnen
skipping to change at line 1814 skipping to change at page 51, line 4
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. 94 change blocks. 
201 lines changed or deleted 268 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/