summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2576.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2576.txt')
-rw-r--r--doc/rfc/rfc2576.txt2467
1 files changed, 2467 insertions, 0 deletions
diff --git a/doc/rfc/rfc2576.txt b/doc/rfc/rfc2576.txt
new file mode 100644
index 0000000..37c10c5
--- /dev/null
+++ b/doc/rfc/rfc2576.txt
@@ -0,0 +1,2467 @@
+
+
+
+
+
+
+Network Working Group R. Frye
+Request for Comments: 2576 CoSine Communications
+Category: Standards Track D. Levi
+ Nortel Networks
+ S. Routhier
+ Integrated Systems Inc.
+ B. Wijnen
+ Lucent Technologies
+ March 2000
+
+
+ Coexistence between Version 1, Version 2, and Version 3
+ of the Internet-standard Network Management Framework
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ The purpose of this document is to describe coexistence between
+ version 3 of the Internet-standard Network Management Framework,
+ (SNMPv3), version 2 of the Internet-standard Network Management
+ Framework (SNMPv2), and the original Internet-standard Network
+ Management Framework (SNMPv1). This document obsoletes RFC 1908 [13]
+ and RFC2089 [14].
+
+Table Of Contents
+
+ 1 Overview ..................................................... 2
+ 1.1 SNMPv1 ..................................................... 3
+ 1.2 SNMPv2 ..................................................... 4
+ 1.3 SNMPv3 ..................................................... 4
+ 1.4 SNMPv1 and SNMPv2 Access to MIB Data ....................... 5
+ 2 SMI and Management Information Mappings ...................... 5
+ 2.1 MIB Modules ................................................ 6
+ 2.1.1 Object Definitions ....................................... 6
+ 2.1.2 Trap and Notification Definitions ........................ 9
+ 2.2 Compliance Statements ...................................... 9
+ 2.3 Capabilities Statements .................................... 10
+
+
+
+Frye, et al. Standards Track [Page 1]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ 3 Translating Notifications Parameters ......................... 10
+ 3.1 Translating SNMPv1 Notification Parameters to SNMPv2
+ Notification Parameters ................................... 12
+ 3.2 Translating SNMPv2 Notification Parameters to SNMPv1
+ Notification Parameters ................................... 13
+ 4 Approaches to Coexistence in a Multi-lingual Network ......... 14
+ 4.1 Multi-lingual implementations .............................. 15
+ 4.1.1 Command Generator ........................................ 15
+ 4.1.2 Command Responder ........................................ 15
+ 4.1.2.1 Handling Counter64 ..................................... 16
+ 4.1.2.2 Mapping SNMPv2 Exceptions .............................. 16
+ 4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 17
+ 4.1.2.2.2 Mapping endOfMibView ................................. 17
+ 4.1.2.3 Processing An SNMPv1 GetRequest ........................ 18
+ 4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 19
+ 4.1.2.5 Processing An SNMPv1 SetRequest ........................ 20
+ 4.1.3 Notification Originator .................................. 20
+ 4.1.4 Notification Receiver .................................... 21
+ 4.2 Proxy Implementations ...................................... 21
+ 4.2.1 Upstream Version Greater Than Downstream Version ......... 21
+ 4.2.2 Upstream Version Less Than Downstream Version ............ 22
+ 4.3 Error Status Mappings ...................................... 24
+ 5 Message Processing Models and Security Models ................ 25
+ 5.1 Mappings ................................................... 25
+ 5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security
+ Model ..................................................... 26
+ 5.2.1 Processing An Incoming Request ........................... 26
+ 5.2.2 Generating An Outgoing Response .......................... 28
+ 5.2.3 Generating An Outgoing Notification ...................... 28
+ 5.3 The SNMP Community MIB Module .............................. 29
+ 6 Intellectual Property ........................................ 39
+ 7 Acknowledgments .............................................. 39
+ 8 Security Considerations ...................................... 40
+ 9 References ................................................... 40
+ 10 Editor's Addresses .......................................... 42
+ A. Changes From RFC1908 ........................................ 43
+ Full Copyright Statement ....................................... 44
+
+1. Overview
+
+ The purpose of this document is to describe coexistence between
+ version 3 of the Internet-standard Network Management Framework,
+ termed the SNMP version 3 framework (SNMPv3), version 2 of the
+ Internet-standard Network Management Framework, termed the SNMP
+ version 2 framework (SNMPv2), and the original Internet-standard
+ Network Management Framework (SNMPv1).
+
+
+
+
+
+Frye, et al. Standards Track [Page 2]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC2119 [15].
+
+ There are four general aspects of coexistence described in this
+ document. Each of these is described in a separate section:
+
+ - Conversion of MIB documents between SMIv1 and SMIv2 formats is
+ documented in section 2.
+
+ - Mapping of notification parameters is documented in section 3.
+
+ - Approaches to coexistence between entities which support the
+ various versions of SNMP in a multi-lingual network is
+ documented in section 4. This section addresses the processing
+ of protocol operations in multi-lingual implementations, as
+ well as behaviour of proxy implementations.
+
+ - The SNMPv1 Message Processing Model and Community-Based
+ Security Model, which provides mechanisms for adapting SNMPv1
+ into the View-Based Access Control Model (VACM) [20], is
+ documented in section 5 (this section also addresses the
+ SNMPv2c Message Processing Model and Community-Based Security
+ Model).
+
+1.1. SNMPv1
+
+ SNMPv1 is defined by these documents:
+
+ - STD 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
+ Information (SMIv1), the mechanisms used for describing and
+ naming objects for the purpose of management.
+
+ - STD 16, RFC 1212 [3] which defines a more concise description
+ mechanism, which is wholly consistent with the SMIv1.
+
+ - RFC 1215 [4] which defines a convention for defining Traps for
+ use with the SMIv1.
+
+ Note that throughout this document, the term 'SMIv1' is used. This
+ term generally refers to the information presented in RFC 1155, RFC
+ 1212, and RFC 1215.
+
+
+
+
+
+Frye, et al. Standards Track [Page 3]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+1.2. SNMPv2
+
+ SNMPv2 is defined by these documents:
+
+ - STD 58, RFC 2578 which defines Version 2 of the Structure of
+ Management Information (SMIv2) [7].
+
+ - STD 58, RFC 2579 which defines common MIB "Textual Conventions"
+ [8].
+
+ - STD 58, RFC 2580 which defines Conformance Statements and
+ requirements for defining agent and manager capabilities [9].
+
+ - RFC 1905 which defines the Protocol Operations used in
+ processing [10].
+
+ - RFC 1906 which defines the Transport Mappings used "on the
+ wire" [11].
+
+ - RFC 1907 which defines the basic Management Information Base
+ for monitoring and controlling some basic common functions of
+ SNMP entities [12].
+
+ Note that SMIv2 as used throughout this document refers to the first
+ three documents listed above (RFCs 2578, 2579, and 2580).
+
+ The following document augments the definition of SNMPv2:
+
+ - RFC 1901 [6] is an Experimental definition for using SNMPv2
+ PDUs within a community-based message wrapper. This is
+ referred to throughout this document as SNMPv2c.
+
+1.3. SNMPv3
+
+ SNMPv3 is defined by these documents:
+
+ - RFC 2571 which defines an Architecture for Describing SNMP
+ Management Frameworks [16].
+
+ - RFC 2572 which defines Message Processing and Dispatching [17].
+
+ - RFC 2573 which defines various SNMP Applications [18].
+
+ - RFC 2574 which defines the User-based Security Model (USM),
+ providing for both Authenticated and Private (encrypted) SNMP
+ messages [19].
+
+
+
+
+
+Frye, et al. Standards Track [Page 4]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ - RFC 2575 which defines the View-based Access Control Model
+ (VACM), providing the ability to limit access to different MIB
+ objects on a per-user basis [20].
+
+ SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 and
+ the SMIv2 definitions of 2578 through 2580 described above.
+
+1.4. SNMPv1 and SNMPv2 Access to MIB Data
+
+ In several places, this document refers to 'SNMPv1 Access to MIB
+ Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the part
+ of an SNMP agent which actually accesses instances of MIB objects,
+ and which actually initiates generation of notifications.
+ Differences between the two types of access to MIB data are:
+
+ - Error-status values generated.
+
+ - Generation of exception codes.
+
+ - Use of the Counter64 data type.
+
+ - The format of parameters provided when a notification is
+ generated.
+
+ SNMPv1 access to MIB data may generate SNMPv1 error-status values,
+ will never generate exception codes nor use the Counter64 data type,
+ and will provide SNMPv1 format parameters for generating
+ notifications. Note also that SNMPv1 access to MIB data will
+ actually never generate a readOnly error (a noSuchName error would
+ always occur in the situation where one would expect a readOnly
+ error).
+
+ SNMPv2 access to MIB data may generate SNMPv2 error-status values,
+ may generate exception codes, may use the Counter64 data type, and
+ will provide SNMPv2 format parameters for generating notifications.
+ Note that SNMPv2 access to MIB data will never generate readOnly,
+ noSuchName, or badValue errors.
+
+ Note that a particular multi-lingual implementation may choose to
+ 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
+
+ The SMIv2 approach towards describing collections of managed objects
+ is nearly a proper superset of the approach defined in the SMIv1.
+ For example, both approaches use an adapted subset of ASN.1 (1988)
+
+
+
+Frye, et al. Standards Track [Page 5]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ [11] as the basis for a formal descriptive notation. Indeed, one
+ might note that the SMIv2 approach largely codifies the existing
+ practice for defining MIB modules, based on extensive experience with
+ the SMIv1.
+
+ The following sections consider the three areas: MIB modules,
+ compliance statements, and capabilities statements.
+
+2.1. MIB Modules
+
+ MIB modules defined using the SMIv1 may continue to be used with
+ protocol versions which use SNMPv2 PDUs. However, for the MIB
+ modules to conform to the SMIv2, the following changes SHALL be made:
+
+2.1.1. Object Definitions
+
+ In general, conversion of a MIB module does not require the
+ deprecation of the objects contained therein. If the definition of
+ an object is truly inadequate for its intended purpose, the object
+ SHALL be deprecated or obsoleted, otherwise deprecation is not
+ required.
+
+ (1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of
+ RFC1155-SMI and RFC-1212.
+
+ (2) The MODULE-IDENTITY macro MUST be invoked immediately after any
+ IMPORTs statement.
+
+ (3) For any object with an integer-valued SYNTAX clause, in which
+ the corresponding INTEGER does not have a range restriction
+ (i.e., the INTEGER has neither a defined set of named-number
+ enumerations nor an assignment of lower- and upper-bounds on its
+ value), the object MUST have the value of its SYNTAX clause
+ changed to Integer32, or have an appropriate range specified.
+
+ (4) For any object with a SYNTAX clause value of Counter, the object
+ MUST have the value of its SYNTAX clause changed to Counter32.
+
+ (5) For any object with a SYNTAX clause value of Gauge, the object
+ MUST have the value of its SYNTAX clause changed to Gauge32, or
+ Unsigned32 where appropriate.
+
+ (6) For all objects, the ACCESS clause MUST be replaced by a MAX-
+ ACCESS clause. The value of the MAX-ACCESS clause SHALL be the
+ same as that of the ACCESS clause unless some other value makes
+ "protocol sense" as the maximal level of access for the object.
+ In particular, object types for which instances can be
+ explicitly created by a protocol set operation, SHALL have a
+
+
+
+Frye, et al. Standards Track [Page 6]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ MAX-ACCESS clause of "read-create". If the value of the ACCESS
+ clause is "write-only", then the value of the MAX-ACCESS clause
+ MUST be "read-write", and the DESCRIPTION clause SHALL note that
+ reading this object will result in implementation-specific
+ results. 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" or "optional", the value MUST be replaced with
+ "current", "deprecated", or "obsolete" depending on the current
+ usage of such objects.
+
+ (8) For any object not containing a DESCRIPTION clause, the object
+ MUST have a DESCRIPTION clause defined.
+
+ (9) For any object corresponding to a conceptual row which does not
+ have an INDEX clause, the object MUST have either an INDEX
+ clause or an AUGMENTS clause defined.
+
+ (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 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. This approach allows one to convert a MIB module
+ in SMIv1 format to one in SMIv2 format, and then use it with the
+ SNMPv1 protocol with no impact to existing SNMPv1 agents and
+ managers.
+
+ (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST
+ be 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 value which is expressed as a collection of sub-
+ identifiers, the value MUST be changed to reference a single
+ ASN.1 identifier. This may require defining a series of new
+ administrative assignments (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.
+
+
+
+Frye, et al. Standards Track [Page 7]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ Other changes are desirable, but not necessary:
+
+ (1) Creation and deletion of conceptual rows is inconsistent using
+ the SMIv1. The SMIv2 corrects this. As such, if the MIB module
+ undergoes review early in its lifetime, and it contains
+ conceptual tables which allow creation and deletion of
+ conceptual rows, then the objects relating to those tables MAY
+ be deprecated and replaced with objects defined using the new
+ approach. The approach based on SMIv2 can be found in section 7
+ of RFC2578 [7], and the RowStatus and StorageType TEXTUAL-
+ CONVENTIONs are described in section 2 of RFC2579 [8].
+
+ (2) For any object with a string-valued SYNTAX clause, in which the
+ corresponding OCTET STRING does not have a size restriction
+ (i.e., the OCTET STRING has no assignment of lower- and upper-
+ bounds on its length), the bounds for the size of the object
+ SHOULD be defined.
+
+ (3) All textual conventions informally defined in the MIB module
+ SHOULD be redefined using the TEXTUAL-CONVENTION macro. Such a
+ change would not necessitate deprecating objects previously
+ defined using an informal textual convention.
+
+ (4) For any object which represents a measurement in some kind of
+ units, a UNITS clause SHOULD be added to the definition of that
+ object.
+
+ (5) For any conceptual row which is an extension of another
+ conceptual row, i.e., for which subordinate columnar objects
+ both exist and are identified via the same semantics as the
+ other conceptual row, an AUGMENTS clause SHOULD be used in place
+ of the INDEX clause for the object corresponding to the
+ conceptual row which is an extension.
+
+ Finally, to avoid common errors in SMIv1 MIB modules:
+
+ (1) For any non-columnar object that is instanced as if it were
+ immediately subordinate to a conceptual row, the value of the
+ STATUS clause of that object MUST be changed to "obsolete".
+
+ (2) For any conceptual row object that is not contained immediately
+ subordinate to a conceptual table, the value of the STATUS
+ clause of that object (and all subordinate objects) MUST be
+ changed to "obsolete".
+
+
+
+
+
+
+
+Frye, et al. Standards Track [Page 8]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+2.1.2. Trap and Notification Definitions
+
+ If a MIB module is changed to conform to the SMIv2, then each
+ occurrence of the TRAP-TYPE macro MUST be changed to a corresponding
+ invocation of the NOTIFICATION-TYPE macro:
+
+ (1) The IMPORTS statement MUST NOT reference RFC-1215 [4], and MUST
+ reference SNMPv2-SMI instead.
+
+ (2) The ENTERPRISE clause MUST be removed.
+
+ (3) The VARIABLES clause MUST be renamed to the OBJECTS clause.
+
+ (4) 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
+ OBJECT IDENTIFIER, not an INTEGER, and MUST be changed
+ accordingly. Specifically, if the value of the ENTERPRISE
+ clause is not 'snmp' then the value of the invocation SHALL be
+ the value of the ENTERPRISE clause extended with two sub-
+ identifiers, the first of which has the value 0, and the second
+ has the value of the invocation of the TRAP-TYPE. 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) A DESCRIPTION clause MUST be added, if not already present.
+
+ (7) One or more NOTIFICATION-GROUPs MUST be defined, and related
+ 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
+
+ For those information modules which are "standards track", a
+ corresponding invocation of the MODULE-COMPLIANCE macro and related
+ OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included within
+ the information module (or in a companion information module), and
+ any commentary text in the information module which relates to
+ compliance SHOULD be removed. Typically this editing can occur when
+ the information module undergoes review.
+
+
+
+
+
+
+
+Frye, et al. Standards Track [Page 9]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ Note that a MODULE-COMPLIANCE statement is not required for a MIB
+ 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
+
+ RFC1303 [5] uses the MODULE-CONFORMANCE macro to describe an agent's
+ capabilities with respect to one or more MIB modules. Converting
+ such a description for use with the SMIv2 requires these changes:
+
+ (1) The macro name AGENT-CAPABILITIES SHOULD be used instead of
+ MODULE-CONFORMANCE.
+
+ (2) The STATUS clause SHOULD be added, with a value of 'current'.
+
+ (3) All occurrences of the CREATION-REQUIRES clause MUST either be
+ omitted if appropriate, or be changed such that the semantics
+ are consistent with RFC2580 [9].
+
+ In order to ease coexistence, object groups defined in an SMIv1
+ compliant MIB module may be referenced by the INCLUDES clause of an
+ invocation of the AGENT-CAPABILITIES macro: upon encountering a
+ reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB
+ module, all leaf objects which are subordinate to the subtree and
+ have a STATUS clause value of mandatory are deemed to be INCLUDED.
+ (Note that this method is ambiguous when different revisions of an
+ SMIv1 MIB have different sets of mandatory objects under the same
+ subtree; in such cases, the only solution is to rewrite the MIB using
+ the SMIv2 in order to define the object groups unambiguously.)
+
+3. Translating Notifications Parameters
+
+ This section describes how parameters used for generating
+ notifications are translated between the format used for SNMPv1
+ notification protocol operations and the format used for SNMPv2
+ notification protocol operations. The parameters used to generate a
+ notification are called 'notification parameters'. The format of
+ parameters used for SNMPv1 notification protocol operations is
+ refered to in this document as 'SNMPv1 notification parameters'. The
+ format of parameters used for SNMPv2 notification protocol operations
+ is refered to in this document as 'SNMPv2 notification parameters'.
+
+
+
+
+
+
+
+
+
+Frye, et al. Standards Track [Page 10]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ The situations where notification parameters MUST be translated are:
+
+ - When an entity generates a set of notification parameters in a
+ particular format, and the configuration of the entity
+ indicates that the notification must be sent using an SNMP
+ message version that requires the other format for notification
+ parameters.
+
+ - When a proxy receives a notification that was sent using an
+ SNMP message version that requires one format of notification
+ parameters, and must forward the notification using an SNMP
+ message version that requires the other format of notification
+ parameters.
+
+ In addition, it MAY be desirable to translate notification parameters
+ in a notification receiver application in order to present
+ notifications to the end user in a consistent format.
+
+ Note that for the purposes of this section, the set of notification
+ parameters is independent of whether the notification is to be sent
+ as a trap or an inform.
+
+ SNMPv1 notification parameters consist of:
+
+ - An enterprise parameter (OBJECT IDENTIFIER).
+
+ - An agent-addr parameter (NetworkAddress).
+
+ - A generic-trap parameter (INTEGER).
+
+ - A specific-trap parameter (INTEGER).
+
+ - A time-stamp parameter (TimeTicks).
+
+ - A list of variable-bindings (VarBindList).
+
+ SNMPv2 notification parameters consist of:
+
+ - A sysUpTime parameter (TimeTicks). This appears in the first
+ variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU.
+
+ - An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in
+ the second variable-binding in an SNMPv2-Trap-PDU or
+ InformRequest-PDU.
+
+ - A list of variable-bindings (VarBindList). This refers to all
+ but the first two variable-bindings in an SNMPv2-Trap-PDU or
+ InformRequest-PDU.
+
+
+
+Frye, et al. Standards Track [Page 11]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification
+ Parameters
+
+ The following procedure describes how to translate SNMPv1
+ notification parameters into SNMPv2 notification parameters:
+
+ (1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the
+ SNMPv1 time-stamp parameter.
+
+ (2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)',
+ the SNMPv2 snmpTrapOID parameter SHALL be the concatentation of
+ the SNMPv1 enterprise parameter and two additional sub-
+ identifiers, '0', and the SNMPv1 specific-trap parameter.
+
+ (3) If the SNMPv1 generic-trap parameter is not '
+ enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL
+ be the corresponding trap as defined in section 2 of RFC1907
+ [12]:
+
+ generic-trap parameter snmpTrapOID.0
+ ====================== =============
+ 0 1.3.6.1.6.3.1.1.5.1 (coldStart)
+ 1 1.3.6.1.6.3.1.1.5.2 (warmStart)
+ 2 1.3.6.1.6.3.1.1.5.3 (linkDown)
+ 3 1.3.6.1.6.3.1.1.5.4 (linkUp)
+ 4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)
+ 5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)
+
+
+ (4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-
+ bindings. In addition, if the translation is being performed by
+ a proxy in order to forward a received trap, three additional
+ variable-bindings will be appended, if these three additional
+ variable-bindings do not already exist in the SNMPv1 variable-
+ bindings. The name portion of the first additional variable
+ binding SHALL contain snmpTrapAddress.0, and the value SHALL
+ contain the SNMPv1 agent-addr parameter. The name portion of
+ the second additional variable binding SHALL contain
+ snmpTrapCommunity.0, and the value SHALL contain the value of
+ the community-string field from the received SNMPv1 message
+ which contained the SNMPv1 Trap-PDU. The name portion of the
+ third additional variable binding SHALL contain
+ snmpTrapEnterprise.0 [12], and the value SHALL be the SNMPv1
+ enterprise parameter.
+
+
+
+
+
+
+
+Frye, et al. Standards Track [Page 12]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification
+ Parameters
+
+ The following procedure describes how to translate SNMPv2
+ notification parameters into SNMPv1 notification parameters:
+
+ (1) The SNMPv1 enterprise parameter SHALL be determined as follows:
+
+ - If the SNMPv2 snmpTrapOID parameter is one of the standard
+ traps as defined in RFC1907 [12], then the SNMPv1 enterprise
+ parameter SHALL be set to the value of the variable-binding in
+ the SNMPv2 variable-bindings whose name is snmpTrapEnterprise.0
+ if that variable-binding exists. If it does not exist, the
+ SNMPv1 enterprise parameter SHALL be set to the value '
+ snmpTraps' as defined in RFC1907 [12].
+
+ - If the SNMPv2 snmpTrapOID parameter is not one of the standard
+ traps as defined in RFC1907 [12], then the SNMPv1 enterprise
+ parameter SHALL be determined from the SNMPv2 snmpTrapOID
+ parameter as follows:
+
+ - If the next-to-last sub-identifier of the snmpTrapOID is
+ zero, then the SNMPv1 enterprise SHALL be the SNMPv2
+ snmpTrapOID with the last 2 sub-identifiers removed,
+ otherwise
+
+ - If the next-to-last sub-identifier of the snmpTrapOID is
+ non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2
+ snmpTrapOID with the last sub-identifier removed.
+
+ (2) The SNMPv1 agent-addr parameter SHALL be determined based on the
+ situation in which the translation occurs.
+
+ - If the translation occurs within a notification originator
+ application, and the notification is to be sent over IP, the
+ SNMPv1 agent-addr parameter SHALL be set to the IP address of
+ the SNMP entity in which the notification originator resides.
+ If the notification is to be sent over some other transport,
+ the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0.
+
+ - If the translation occurs within a proxy application, the proxy
+ must attempt to extract the original source of the notification
+ from the variable-bindings. If the SNMPv2 variable-bindings
+ contains a variable binding whose name is snmpTrapAddress.0,
+ the agent-addr parameter SHALL be set to the value of that
+ variable binding. Otherwise, the SNMPv1 agent-addr parameter
+ SHALL be set to 0.0.0.0.
+
+
+
+
+Frye, et al. Standards Track [Page 13]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ (3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps
+ as defined in RFC1907 [12], the SNMPv1 generic-trap parameter
+ SHALL be set as follows:
+
+ snmpTrapOID.0 parameter generic-trap
+ =============================== ============
+ 1.3.6.1.6.3.1.1.5.1 (coldStart) 0
+ 1.3.6.1.6.3.1.1.5.2 (warmStart) 1
+ 1.3.6.1.6.3.1.1.5.3 (linkDown) 2
+ 1.3.6.1.6.3.1.1.5.4 (linkUp) 3
+ 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4
+ 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5
+
+ Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6.
+
+ (4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps
+ as defined in RFC1907 [12], the SNMPv1 specific-trap parameter
+ SHALL be set to zero. Otherwise, the SNMPv1 specific-trap
+ parameter SHALL be set to the last sub-identifier of the SNMPv2
+ snmpTrapOID parameter.
+
+ (5) The SNMPv1 time-stamp parameter SHALL be taken directly from the
+ SNMPv2 sysUpTime parameter.
+
+ (6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-
+ bindings. Note, however, that if the SNMPv2 variable-bindings
+ contain any objects whose type is Counter64, the translation to
+ SNMPv1 notification parameters cannot be performed. In this
+ case, the 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
+
+ There are two basic approaches to coexistence in a multi-lingual
+ network, multi-lingual implementations and proxy implementations.
+ Multi-lingual implementations allow elements in a network to
+ communicate with each other using an SNMP version which both elements
+ support. This allows a multi-lingual implementation to communicate
+ with any mono-lingual implementation, regardless of the SNMP version
+ supported by the mono-lingual implementation.
+
+ Proxy implementations provide a mechanism for translating between
+ SNMP versions using a third party network element. This allows
+ network elements which support only a single, but different, SNMP
+ version to communicate with each other. Proxy implementations are
+ also useful for securing communications over an insecure link between
+ two locally secure networks.
+
+
+
+Frye, et al. Standards Track [Page 14]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+4.1. Multi-lingual implementations
+
+ This approach requires an entity to support multiple SNMP message
+ versions. Typically this means supporting SNMPv1, SNMPv2c, and
+ SNMPv3 message versions. The behaviour of various types of SNMP
+ applications which support multiple message versions is described in
+ the following sections. This approach allows entities which support
+ multiple SNMP message versions to coexist with and communicate with
+ entities which support only a single SNMP message version.
+
+4.1.1. Command Generator
+
+ A command generator must select an appropriate message version when
+ sending requests to another entity. One way to achieve this is to
+ consult a local database to select the appropriate message version.
+
+ In addition, a command generator MUST 'downgrade' GetBulk requests to
+ GetNext requests when selecting SNMPv1 as the message version for 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
+
+ A command responder must be able to deal with both SNMPv1 and SNMPv2
+ access to MIB data. There are three aspects to dealing with this. A
+ command responder must:
+
+ - Deal correctly with SNMPv2 access to MIB data that returns a
+ Counter64 value while processing an SNMPv1 message,
+
+ - Deal correctly with SNMPv2 access to MIB data that returns one
+ of the three exception values while processing an SNMPv1
+ message, and
+
+ - Map SNMPv2 error codes returned from SNMPv2 access to MIB data
+ into SNMPv1 error codes when processing an SNMPv1 message.
+
+ Note that SNMPv1 error codes SHOULD NOT be used without any change
+ 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
+ application which supports multiple SNMP message versions, and which
+ uses some combination of SNMPv1 and SNMPv2 access to MIB data.
+
+
+
+
+Frye, et al. Standards Track [Page 15]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+4.1.2.1. Handling Counter64
+
+ The SMIv2 [7] defines one new syntax that is incompatible with SMIv1.
+ This syntax is Counter64. All other syntaxes defined by SMIv2 are
+ compatible with SMIv1.
+
+ The impact on multi-lingual command responders is that they MUST NOT
+ ever return a variable binding containing a Counter64 value in a
+ response to a request that was received using the SNMPv1 message
+ version.
+
+ Multi-lingual command responders SHALL take the approach that object
+ instances whose type is Counter64 are implicitly excluded from view
+ when processing an SNMPv1 message. So:
+
+ - On receipt of an SNMPv1 GetRequest-PDU containing a 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.
+
+ - On an SNMPv1 GetNextRequest-PDU, any object instance which
+ contains a syntax of Counter64 SHALL be skipped, and the next
+ accessible object instance that does not have the syntax of
+ Counter64 SHALL be retrieved. If no such object instance
+ exists, then an error-status of noSuchName SHALL be returned,
+ and the error-index SHALL be set to the variable binding that
+ caused this error.
+
+ - Any SNMPv1 request which contains a variable binding with a
+ Counter64 value is ill-formed, so the foregoing rules do not
+ apply. If that error is detected, a response SHALL NOT be
+ returned, since it would contain a copy of the ill-formed
+ variable binding. Instead, the offending PDU SHALL be
+ discarded and the counter snmpInASNParseErrs SHALL be
+ incremented.
+
+4.1.2.2. Mapping SNMPv2 Exceptions
+
+ SNMPv2 provides a feature called exceptions, which allow an SNMPv2
+ Response PDU to return as much management information as possible,
+ even when an error occurs. However, SNMPv1 does not support
+ exceptions, and so an SNMPv1 Response PDU cannot return any
+ management information, and can only return an error-status and
+ error-index value.
+
+
+
+
+
+
+Frye, et al. Standards Track [Page 16]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ When an SNMPv1 request is received, a command responder MUST check
+ any variable bindings returned using SNMPv2 access to MIB data for
+ exception values, and convert these exception values into SNMPv1
+ error codes.
+
+ The type of exception that can be returned when accessing MIB data
+ and the action taken depends on the type of SNMP request.
+
+ - For a GetRequest, a noSuchObject or noSuchInstance exception
+ may be returned.
+
+ - For a GetNextRequest, an endOfMibView exception may be
+ returned.
+
+ - No exceptions will be returned for a SetRequest, and a
+ GetBulkRequest should only be received in an SNMPv2c or SNMPv3
+ message, so these request types may be ignored when mapping
+ exceptions.
+
+ 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
+
+ A noSuchObject or noSuchInstance exception generated by an SNMPv2
+ access to MIB data indicates that the requested object instance can
+ not be returned. The SNMPv1 error code for this condition is
+ noSuchName, and so the error-status field of the response PDU SHALL
+ be set to noSuchName. Also, the error-index field SHALL be set to
+ the index of the variable binding for which an exception occurred
+ (there may be more than one and it is an implementation 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.2.2. Mapping endOfMibView
+
+ When an SNMPv2 access to MIB data returns a variable binding
+ containing an endOfMibView exception, it indicates that there are no
+ object instances available which lexicographically follow the object
+ in the request. In an SNMPv1 agent, this condition normally results
+ in a noSuchName error, and so the error-status field of the response
+ PDU SHALL be set to noSuchName. Also, the error-index field SHALL be
+ set to the index of the variable binding for which an exception
+ occurred (there may be more than one and it is an implementation
+ decision as to which is used), and the variable binding list from the
+ original request SHALL be returned with the response PDU.
+
+
+
+
+Frye, et al. Standards Track [Page 17]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+4.1.2.3. Processing An SNMPv1 GetRequest
+
+ When processing an SNMPv1 GetRequest, the following procedures MUST
+ be followed when using an SNMPv2 access to MIB data.
+
+ When such an access to MIB data returns response data using SNMPv2
+ syntax and error-status values, then:
+
+ (1) If the error-status is anything other than noError,
+
+ - The error status SHALL be translated to an SNMPv1 error-status
+ using the table in section 4.3, "Error Status Mappings".
+
+ - The error-index SHALL be set to the position (in the original
+ request) of the variable binding that caused the error-status.
+
+ - The variable binding list of the response PDU SHALL be made
+ exactly the same as the variable binding list that was received
+ in the original request.
+
+ (2) If the error-status is noError, the variable bindings SHALL be
+ checked for any SNMPv2 exception (noSuchObject or
+ noSuchInstance) or an SNMPv2 syntax that is unknown to SNMPv1
+ (Counter64). If there are any such variable bindings, one of
+ those variable bindings SHALL be selected (it is an
+ implementation choice as to which is selected), and:
+
+ - The error-status SHALL be set to noSuchName,
+
+ - The error-index SHALL be set to the position (in the variable
+ binding list of the original request) of the selected variable
+ binding, and
+
+ - The variable binding list of the response PDU SHALL be exactly
+ the same as the variable binding list that was received in the
+ original request.
+
+ (3) If there are no such variable bindings, then:
+
+ - The error-status SHALL be set to noError,
+
+ - The error-index SHALL be set to zero, and
+
+ - The variable binding list of the response SHALL be composed
+ from the data as it is returned by the access to MIB data.
+
+
+
+
+
+
+Frye, et al. Standards Track [Page 18]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+4.1.2.4. Processing An SNMPv1 GetNextRequest
+
+ When processing an SNMPv1 GetNextRequest, the following procedures
+ MUST be followed when an SNMPv2 access to MIB data is called as part
+ of processing the request. There may be repetitive accesses to MIB
+ data to try to find the first object which lexicographically follows
+ each of the objects in the request. This is implementation specific.
+ These procedures are followed only for data returned when using
+ SNMPv2 access to MIB data. Data returned using SNMPv1 access to MIB
+ data may be treated in the normal manner for an SNMPv1 request.
+
+ First, if the access to MIB data returns an error-status of anything
+ other than noError:
+
+ (1) The error status SHALL be translated to an SNMPv1 error-status
+ using the table in section 4.3, "Error Status Mappings".
+
+ (2) The error-index SHALL be set to the position (in the original
+ request) of the variable binding that caused the error-status.
+
+ (3) The variable binding list of the response PDU SHALL be exactly
+ the same as the variable binding list that was received in the
+ original request.
+
+ Otherwise, if the access to MIB data returns an error-status of
+ noError:
+
+ (1) Any variable bindings containing an SNMPv2 syntax of Counter64
+ SHALL be considered to be not in view, and MIB data SHALL be
+ accessed as many times as is required until either a value other
+ than Counter64 is returned, or an error occurs.
+
+ (2) If there is any variable binding that contains an SNMPv2
+ exception endOfMibView (there may be more than one, it is an
+ implementation decision as to which is chosen):
+
+ - The error-status SHALL be set to noSuchName,
+
+ - The error-index SHALL be set to the position (in the variable
+ binding list of the original request) of the variable binding
+ that returned such an SNMPv2 exception, and
+
+ - The variable binding list of the response PDU SHALL be exactly
+ the same as the variable binding list that was received in the
+ original request.
+
+ (3) If there are no such variable bindings, then:
+
+
+
+
+Frye, et al. Standards Track [Page 19]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ - The error-status SHALL be set to noError,
+
+ - The error-index SHALL be set to zero, and
+
+ - The variable binding list of the response SHALL be composed
+ from the data as it is returned by the 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.
+
+4.1.3. Notification Originator
+
+ A notification originator must be able to translate between SNMPv1
+ notifications parameters and SNMPv2 notification parameters in order
+ to send a notification using a particular SNMP message version. If a
+ notification is generated using SNMPv1 notification parameters, and
+ configuration information specifies that notifications be sent using
+ SNMPv2c or SNMPv3, the notification parameters must be translated to
+ SNMPv2 notification parameters. Likewise, if a notification is
+ generated using SNMPv2 notification parameters, and configuration
+ information specifies that notifications be sent using SNMPv1, the
+ notification parameters must 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
+ parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION-
+ MIB, if the SNMP version used to generate the notification is SNMPv1,
+ the PDU type used will always be a TrapPDU, regardless of whether the
+ value of snmpNotifyType is trap(1) or inform(2).
+
+
+
+
+Frye, et al. Standards Track [Page 20]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ Note also that access control and notification filtering are
+ performed in the usual manner for notifications, regardless of the
+ SNMP message version to be used when sending a notification. The
+ parameters for performing access control are found in the usual
+ manner (i.e., from inspecting the SNMP-TARGET-MIB and SNMP-
+ NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in
+ order to perform the access check specified in [18], section 3.3,
+ bullet (3), the notification originator may need to generate a value
+ for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of
+ this document. If the SNMPv1 notification parameters being used were
+ previously translated from a set of SNMPv2 notification parameters,
+ this value may already be known, in which case it need not be
+ generated.
+
+4.1.4. Notification Receiver
+
+ There are no special requirements of a notification receiver.
+ However, an implementation may find it useful to allow a higher level
+ application to request whether notifications should be delivered to a
+ higher level application using SNMPv1 notification parameter or
+ SNMPv2 notification parameters. The notification receiver would then
+ translate notification parameters when required in order to present a
+ notification using the desired set of parameters.
+
+4.2. Proxy Implementations
+
+ A proxy implementation may be used to enable communication between
+ entities which support different SNMP message versions. This is
+ accomplished in a proxy forwarder application by performing
+ translations on 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 constraints 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, regardless of the PDU
+ type or direction.
+
+4.2.1. Upstream Version Greater Than Downstream Version
+
+ - If a GetBulkRequest-PDU is received and must be forwarded using
+ the SNMPv1 message version, the proxy forwarder SHALL set the
+ non-repeaters and max-repetitions fields to 0, and SHALL set the
+ tag of the PDU to GetNextRequest-PDU.
+
+
+
+
+Frye, et al. Standards Track [Page 21]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ - If a GetResponse-PDU is received whose error-status field has a
+ value of 'tooBig', the message will be forwarded using the SNMPv2c
+ or SNMPv3 message version, and the original request received by
+ the proxy was not a GetBulkRequest-PDU, the proxy 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 nobjects.
+
+4.2.2. Upstream Version Less Than Downstream Version
+
+ - If a GetResponse-PDU is received in response to a GetRequest-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 SNMPv1 message
+ version, the proxy MUST generate an alternate response PDU
+ consisting of the request-id and variable bindings from the
+ original SNMPv1 request, containing a noSuchName error-status
+ value, and containing an error-index value indicating the position
+ of the variable-binding containing the Counter64 type or exception
+ code.
+
+
+
+
+Frye, et al. Standards Track [Page 22]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ - 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).
+
+ 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 error-
+ status value of wrongValue, wrongEncoding, wrongType, wrongLength,
+ inconsistentValue, noAccess, notWritable, noCreation,
+ inconsistentName, resourceUnavailable, commitFailed, undoFailed,
+ or authorizationError, the error-status value is modified using
+ the mappings in section 4.3.
+
+ - If an SNMPv2-Trap-PDU is received, and will be forwarded using the
+ SNMPv1 message version, the proxy SHALL apply the translation
+ rules described in section 3, and SHALL forward the notification
+
+
+
+
+Frye, et al. Standards Track [Page 23]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ as a Trap-PDU. Note that if the translation fails due 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 information
+ indicating that it would be forwarded using the SNMPv1 message
+ version SHALL be ignored. An InformRequest-PDU can only be
+ forwarded using the SNMPv2c or SNMPv3 message version. The
+ InformRequest-PDU may still be forwarded if there is other
+ configuration information indicating that it should be forwarded
+ using SNMPv2c or SNMPv3.
+
+4.3. Error Status Mappings
+
+ The following tables shows the mappings of SNMPv1 error-status values
+ into SNMPv2 error-status values, and the mappings of SNMPv2 error-
+ status values into SNMPv1 error-status values.
+
+ SNMPv1 error-status SNMPv2 error-status
+ =================== ===================
+ noError noError
+ tooBig tooBig
+ noSuchName noSuchName
+ badValue badValue
+ genErr genErr
+
+
+ SNMPv2 error-status SNMPv1 error-status
+ =================== ===================
+ noError noError
+ tooBig tooBig
+ genErr genErr
+ wrongValue badValue
+ wrongEncoding badValue
+ wrongType badValue
+ wrongLength badValue
+ inconsistentValue badValue
+ noAccess noSuchName
+ notWritable noSuchName
+ noCreation noSuchName
+ inconsistentName noSuchName
+ resourceUnavailable genErr
+ commitFailed genErr
+ undoFailed genErr
+ authorizationError noSuchName
+
+
+
+
+
+
+Frye, et al. Standards Track [Page 24]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ 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.
+
+5. Message Processing Models and Security Models
+
+ In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture,
+ the following models are defined in this document:
+
+ - The SNMPv1 Message Processing Model
+
+ - The SNMPv1 Community-Based Security Model
+
+ The following models are also described in this document:
+
+ - The SNMPv2c Message Processing Model
+
+ - The SNMPv2c Community-Based Security Model
+
+ In most respects, the SNMPv1 Message Processing Model and the
+ SNMPv2c Message Processing Model are identical, and so these
+ are not discussed independently in this document. Differences
+ between the two models are described as required.
+
+ Similarly, the SNMPv1 Community-Based Security Model and the
+ SNMPv2c Community-Based Security Model are nearly identical,
+ and so are not discussed independently. Differences between
+ these two models are also described as required.
+
+5.1. Mappings
+
+ The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model
+ require mappings between parameters used in SNMPv1 (and SNMPv2c)
+ messages, and the version independent parameters used in the SNMP
+ architecture [16]. The parameters which MUST be mapped consist of
+ the SNMPv1 (and SNMPv2c) community name, and the SNMP securityName
+ and contextEngineID/contextName pair. A MIB module (the SNMP-
+ COMMUNITY-MIB) is provided in this document in order to perform these
+ mappings. This MIB provides mappings in both directions, that is, a
+ community name may be mapped to a securityName, contextEngineID, and
+ contextName, or the combination of securityName, contextEngineID, and
+ contextName may be mapped to a community name.
+
+
+
+
+
+
+
+
+
+Frye, et al. Standards Track [Page 25]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model
+
+ The SNMPv1 Message Processing Model handles processing of SNMPv1
+ messages. The processing of messages is handled generally in the
+ same manner as described in RFC1157 [2], with differences and
+ clarifications as described in the following sections. The
+ SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for
+ SNMPv2c is 1).
+
+5.2.1. Processing An Incoming Request
+
+ In RFC1157 [2], section 4.1, item (3) for an entity which receives a
+ message, states that various parameters are passed to the 'desired
+ authentication scheme.' The desired authentication scheme in this
+ case is the SNMPv1 Community-Based Security Model, which will be
+ called using the processIncomingMsg ASI. The parameters passed to
+ this ASI are:
+
+ - The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).
+
+ - The maxMessageSize, which should be the maximum size of a
+ message that the receiving entity can generate (since there is
+ no such value in the received message).
+
+ - The securityParameters, which consist of the community string
+ and the message's source and destination transport domains and
+ addresses.
+
+ - The securityModel, which will be 1 (or 2 for SNMPv2c).
+
+ - The securityLevel, which will be noAuthNoPriv.
+
+ - The wholeMsg and wholeMsgLength.
+
+ The Community-Based Security Model will attempt to select a row in
+ the snmpCommunityTable. This is done by performing a search through
+ the snmpCommunityTable in lexicographic order. The first entry for
+ which the following matching criteria are satisfied will be selected:
+
+ - The community string is equal to the snmpCommunityName value.
+
+ - If the snmpCommunityTransportTag is 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 was
+ received must match one of the entries in the
+ snmpTargetAddrTable selected by the snmpCommunityTransportTag
+
+
+
+
+Frye, et al. Standards Track [Page 26]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ 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
+ described in RFC1157 [2], and the snmpInBadCommunityNames counter is
+ incremented.
+
+ The parameters returned from the Community-Based Security Model are:
+
+ - The securityEngineID, which will always be the local value of
+ snmpEngineID.0.
+
+ - The securityName.
+
+ - The scopedPDU. Note that this parameter will actually consist
+ of three values, the contextSnmpEngineID, the contextName, and
+ the PDU. These must be separate values, since the first two do
+ not actually appear in the message.
+
+ - The maxSizeResponseScopedPDU.
+
+ - The securityStateReference.
+
+ The appropriate SNMP application will then be called (depending on
+ the value of the contextEngineID and the request type in the PDU)
+ using the processPdu ASI. The parameters passed to this ASI are:
+
+ - The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).
+
+ - The securityModel, which will be 1 (or 2 for SNMPv2c).
+
+ - The securityName, which was returned from the call to
+ processIncomingMsg.
+
+ - The securityLevel, which is noAuthNoPriv.
+
+ - The contextEngineID, which was returned as part of the
+ ScopedPDU from the call to processIncomingMsg.
+
+ - The contextName, which was returned as part of the ScopedPDU
+ from the call to processIncomingMsg.
+
+ - The pduVersion, which should indicate an SNMPv1 version PDU (if
+ the message version was SNMPv2c, this would be an SNMPv2
+ version PDU).
+
+
+
+
+
+Frye, et al. Standards Track [Page 27]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ - The PDU, which was returned as part of the ScopedPDU from the
+ call to processIncomingMsg.
+
+ - The maxSizeResponseScopedPDU which was returned from the call
+ to processIncomingMsg.
+
+ - The stateReference which was returned from the call to
+ processIncomingMsg.
+
+ The SNMP application should process the request as described
+ previously in this document. Note that access control is applied by
+ an SNMPv3 command responder application as usual. The parameters as
+ passed to the processPdu ASI will be used in calls to the
+ isAccessAllowed ASI.
+
+5.2.2. Generating An Outgoing Response
+
+ There is no special processing required for generating an outgoing
+ response. However, the community string used in an outgoing response
+ must be the same as the community string from the original request.
+ The original community string MUST be present in the stateReference
+ information of the original request.
+
+5.2.3. Generating An Outgoing Notification
+
+ In a multi-lingual SNMP entity, the parameters used for generating
+ notifications will be obtained by examining the SNMP-TARGET-MIB and
+ SNMP-NOTIFICATION-MIB. These parameters will be passed to the SNMPv1
+ Message Processing Model using the sendPdu ASI. The SNMPv1 Message
+ Processing Model will attempt to locate an appropriate community
+ string in the snmpCommunityTable based on the parameters passed to
+ the sendPdu ASI. This is done by performing a search through the
+ snmpCommunityTable in lexicographic order. The first entry for which
+ the following matching criteria are satisfied will be selected:
+
+ - The securityName must be equal to the snmpCommunitySecurityName
+ value.
+
+ - The contextEngineID must be equal to the
+ snmpCommunityContextEngineID value.
+
+ - The contextName must be equal to the snmpCommunityContextName
+ value.
+
+ - If the snmpCommunityTransportTag is an empty string, it is
+ ignored for the purpose of matching. If the
+ snmpCommunityTransportTag is not an empty string, the
+
+
+
+
+Frye, et al. Standards Track [Page 28]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ transportDomain and transportAddress must match one of the
+ entries in the snmpTargetAddrTable selected by the
+ snmpCommunityTransportTag value.
+
+ If no such entry can be found, the notification is not sent.
+ Otherwise, the community string used in the outgoing notification
+ will be the value of the snmpCommunityName column of the selected
+ row.
+
+5.3. The SNMP Community MIB Module
+
+ The SNMP-COMMUNITY-MIB contains objects for mapping between community
+ strings and version-independent SNMP message parameters. In
+ addition, this MIB provides a mechanism for performing source address
+ validation on incoming requests, and for selecting community strings
+ based on target addresses for outgoing notifications. These two
+ features are accomplished by providing a tag in the
+ snmpCommunityTable which selects sets of entries in the
+ snmpTargetAddrTable [18]. In addition, the SNMP-COMMUNITY-MIB
+ augments the snmpTargetAddrTable with a transport address mask value
+ and a maximum message size value. These values are used only where
+ explicitly stated. In cases where the snmpTargetAddrTable is used
+ without mention of these augmenting values, the augmenting values
+ should be ignored.
+
+ The mask value, snmpTargetAddrTMask, allows selected entries in the
+ snmpTargetAddrTable to specify multiple addresses (rather than just a
+ single address per entry). This would typically be used to specify a
+ subnet in an snmpTargetAddrTable rather than just a single address.
+ The mask value is used to select which bits of a transport address
+ must match bits of the corresponding instance of
+ snmpTargetAddrTAddress, in order for the transport address to match a
+ particular entry in the snmpTargetAddrTable. The value of an
+ instance of snmpTargetAddrTMask must always be an OCTET STRING whose
+ length is either zero or the same as that of the corresponding
+ instance of snmpTargetAddrTAddress.
+
+ Note that the snmpTargetAddrTMask object is only used where
+ explicitly stated. In particular, it is not used when generating
+ notifications (i.e., when generating notifications, entries in the
+ snmpTargetAddrTable only specify individual addresses).
+
+ When checking whether a transport address matches an entry in the
+ snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero-
+ length OCTET STRING, the mask value is ignored, and the value of
+ snmpTargetAddrTAddress must exactly match a transport address.
+ Otherwise, each bit of each octet in the snmpTargetAddrTMask value
+ corresponds to the same bit of the same octet in the
+
+
+
+Frye, et al. Standards Track [Page 29]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ snmpTargetAddrTAddress value. For bits that are set in the
+ snmpTargetAddrTMask value (i.e., bits equal to 1), the corresponding
+ bits in the snmpTargetAddrTAddress value must match the bits in a
+ transport address. If all such bits match, the transport address is
+ matched by that snmpTargetAddrTable entry. Otherwise, the transport
+ address is not matched.
+
+ The maximum message size value, snmpTargetAddrMMS, is used to
+ determine the maximum message size acceptable to another SNMP entity
+ when the value cannot be determined from the protocol.
+
+SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN
+
+IMPORTS
+ IpAddress,
+ MODULE-IDENTITY,
+ OBJECT-TYPE,
+ Integer32,
+ snmpModules
+ FROM SNMPv2-SMI
+ RowStatus,
+ StorageType
+ FROM SNMPv2-TC
+ SnmpAdminString,
+ SnmpEngineID
+ FROM SNMP-FRAMEWORK-MIB
+ SnmpTagValue,
+ snmpTargetAddrEntry
+ FROM SNMP-TARGET-MIB
+ MODULE-COMPLIANCE,
+ OBJECT-GROUP
+ FROM SNMPv2-CONF;
+
+snmpCommunityMIB MODULE-IDENTITY
+ LAST-UPDATED "200003060000Z" -- 6 Mar 2000, midnight
+ ORGANIZATION "SNMPv3 Working Group"
+ CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com
+ Subscribe: majordomo@lists.tislabs.com
+ In msg body: subscribe snmpv3
+
+ Chair: Russ Mundy
+ TIS Labs at Network Associates
+ Postal: 3060 Washington Rd
+ Glenwood MD 21738
+ USA
+ Email: mundy@tislabs.com
+ Phone: +1-301-854-6889
+
+
+
+
+Frye, et al. Standards Track [Page 30]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ Co-editor: Rob Frye
+ CoSine Communications
+ Postal: 1200 Bridge Parkway
+ Redwood City, CA 94065
+ USA
+ E-mail: rfrye@cosinecom.com
+ Phone: +1 703 725 1130
+
+ Co-editor: David B. Levi
+ Nortel Networks
+ Postal: 3505 Kesterwood Drive
+ Knoxville, TN 37918
+ E-mail: dlevi@nortelnetworks.com
+ Phone: +1 423 686 0432
+
+ Co-editor: Shawn A. Routhier
+ Integrated Systems Inc.
+ Postal: 333 North Ave 4th Floor
+ Wakefield, MA 01880
+ E-mail: sar@epilogue.com
+ Phone: +1 781 245 0804
+
+ Co-editor: Bert Wijnen
+ Lucent Technologies
+ Postal: Schagen 33
+ 3461 GL Linschoten
+ Netherlands
+ Email: bwijnen@lucent.com
+ Phone: +31-348-407-775
+ "
+
+ DESCRIPTION
+ "This MIB module defines objects to help support coexistence
+ between SNMPv1, SNMPv2c, and SNMPv3."
+ REVISION "200003060000Z" -- 6 Mar 2000
+ DESCRIPTION "This version published as RFC 2576."
+ REVISION "199905130000Z" -- 13 May 1999
+ DESCRIPTION "The Initial Revision"
+ ::= { snmpModules 18 }
+
+-- Administrative assignments ****************************************
+
+snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 }
+snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 }
+
+--
+-- The snmpCommunityTable contains a database of community strings.
+-- This table provides mappings between community strings, and the
+
+
+
+Frye, et al. Standards Track [Page 31]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+-- parameters required for View-based Access Control.
+--
+
+snmpCommunityTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF SnmpCommunityEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The table of community strings configured in the SNMP
+ engine's Local Configuration Datastore (LCD)."
+ ::= { snmpCommunityMIBObjects 1 }
+
+snmpCommunityEntry OBJECT-TYPE
+ SYNTAX SnmpCommunityEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Information about a particular community string."
+ INDEX { IMPLIED snmpCommunityIndex }
+ ::= { snmpCommunityTable 1 }
+
+SnmpCommunityEntry ::= SEQUENCE {
+ snmpCommunityIndex SnmpAdminString,
+ snmpCommunityName OCTET STRING,
+ snmpCommunitySecurityName SnmpAdminString,
+ snmpCommunityContextEngineID SnmpEngineID,
+ snmpCommunityContextName SnmpAdminString,
+ snmpCommunityTransportTag SnmpTagValue,
+ snmpCommunityStorageType StorageType,
+ snmpCommunityStatus RowStatus
+}
+
+snmpCommunityIndex OBJECT-TYPE
+ SYNTAX SnmpAdminString (SIZE(1..32))
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The unique index value of a row in this table."
+ ::= { snmpCommunityEntry 1 }
+
+snmpCommunityName OBJECT-TYPE
+ SYNTAX OCTET STRING
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The community string for which a row in this table
+ represents a configuration."
+ ::= { snmpCommunityEntry 2 }
+
+
+
+Frye, et al. Standards Track [Page 32]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+snmpCommunitySecurityName OBJECT-TYPE
+ SYNTAX SnmpAdminString (SIZE(1..32))
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "A human readable string representing the corresponding
+ value of snmpCommunityName in a Security Model
+ independent format."
+ ::= { snmpCommunityEntry 3 }
+
+snmpCommunityContextEngineID OBJECT-TYPE
+ SYNTAX SnmpEngineID
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The contextEngineID indicating the location of the
+ context in which management information is accessed
+ when using the community string specified by the
+ corresponding instance of snmpCommunityName.
+
+ The default value is the snmpEngineID of the entity in
+ which this object is instantiated."
+ ::= { snmpCommunityEntry 4 }
+
+snmpCommunityContextName OBJECT-TYPE
+ SYNTAX SnmpAdminString (SIZE(0..32))
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The context in which management information is accessed
+ when using the community string specified by the corresponding
+ instance of snmpCommunityName."
+ DEFVAL { ''H } -- the empty string
+ ::= { snmpCommunityEntry 5 }
+
+snmpCommunityTransportTag OBJECT-TYPE
+ SYNTAX SnmpTagValue
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object specifies a set of transport endpoints
+ from which a command responder application will accept
+ management requests. If a management request containing
+ this community is received on a transport endpoint other
+ than the transport endpoints identified by this object,
+ the request is deemed unauthentic.
+
+ The transports identified by this object are specified
+
+
+
+Frye, et al. Standards Track [Page 33]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ in the snmpTargetAddrTable. Entries in that table
+ whose snmpTargetAddrTagList contains this tag value
+ are identified.
+
+ If the value of this object has zero-length, transport
+ endpoints are not checked when authenticating messages
+ containing this community string."
+ DEFVAL { ''H } -- the empty string
+ ::= { snmpCommunityEntry 6 }
+
+snmpCommunityStorageType OBJECT-TYPE
+ SYNTAX StorageType
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The storage type for this conceptual row in the
+ snmpCommunityTable. Conceptual rows having the value
+ 'permanent' need not allow write-access to any
+ columnar object in the row."
+ ::= { snmpCommunityEntry 7 }
+
+snmpCommunityStatus OBJECT-TYPE
+ SYNTAX RowStatus
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The status of this conceptual row in the snmpCommunityTable.
+
+ An entry in this table is not qualified for activation
+ until instances of all corresponding columns have been
+ initialized, either through default values, or through
+ Set operations. The snmpCommunityName and
+ snmpCommunitySecurityName objects must be explicitly set.
+
+ There is no restriction on setting columns in this table
+ when the value of snmpCommunityStatus is active(1)."
+ ::= { snmpCommunityEntry 8 }
+
+--
+-- The snmpTargetAddrExtTable
+--
+
+snmpTargetAddrExtTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The table of mask and mms values associated with the
+
+
+
+Frye, et al. Standards Track [Page 34]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ 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 }
+
+snmpTargetAddrExtEntry OBJECT-TYPE
+ SYNTAX SnmpTargetAddrExtEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Information about a particular mask and mms value."
+ AUGMENTS { snmpTargetAddrEntry }
+ ::= { snmpTargetAddrExtTable 1 }
+
+SnmpTargetAddrExtEntry ::= SEQUENCE {
+ snmpTargetAddrTMask OCTET STRING,
+ snmpTargetAddrMMS Integer32
+}
+
+snmpTargetAddrTMask OBJECT-TYPE
+ SYNTAX OCTET STRING (SIZE (0..255))
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The mask value associated with an entry in the
+ snmpTargetAddrTable. The value of this object must
+ have the same length as the corresponding instance of
+ snmpTargetAddrTAddress, or must have length 0. 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.
+
+
+
+Frye, et al. Standards Track [Page 35]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ 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.
+
+ 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 }
+ ::= { snmpTargetAddrExtEntry 1 }
+
+snmpTargetAddrMMS OBJECT-TYPE
+ SYNTAX Integer32 (0|484..2147483647)
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The maximum message size value associated with an entry
+ in the snmpTargetAddrTable."
+ DEFVAL { 484 }
+ ::= { snmpTargetAddrExtEntry 2 }
+
+--
+-- The snmpTrapAddress and snmpTrapCommunity objects are included
+-- in notifications that are forwarded by a proxy, which were
+-- originally received as SNMPv1 Trap messages.
+--
+
+snmpTrapAddress OBJECT-TYPE
+ SYNTAX IpAddress
+ MAX-ACCESS accessible-for-notify
+ STATUS current
+ DESCRIPTION
+ "The value of the agent-addr field of a Trap PDU which
+ is forwarded by a proxy forwarder application using
+ an SNMP version other than SNMPv1. The value of this
+ object SHOULD contain the value of the agent-addr field
+ from the original Trap PDU as generated by an SNMPv1
+ agent."
+ ::= { snmpCommunityMIBObjects 3 }
+
+snmpTrapCommunity OBJECT-TYPE
+ SYNTAX OCTET STRING
+ MAX-ACCESS accessible-for-notify
+ STATUS current
+ DESCRIPTION
+
+
+
+Frye, et al. Standards Track [Page 36]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ "The value of the community string field of an SNMPv1
+ message containing a Trap PDU which is forwarded by a
+ a proxy forwarder application using an SNMP version
+ other than SNMPv1. The value of this object SHOULD
+ contain the value of the community string field from
+ the original SNMPv1 message containing a Trap PDU as
+ generated by an SNMPv1 agent."
+ ::= { snmpCommunityMIBObjects 4 }
+
+-- Conformance Information *******************************************
+
+snmpCommunityMIBCompliances OBJECT IDENTIFIER
+ ::= { snmpCommunityMIBConformance 1 }
+snmpCommunityMIBGroups OBJECT IDENTIFIER
+ ::= { snmpCommunityMIBConformance 2 }
+
+-- Compliance statements
+
+snmpCommunityMIBCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for SNMP engines which
+ implement the SNMP-COMMUNITY-MIB."
+
+ MODULE -- this module
+ MANDATORY-GROUPS { snmpCommunityGroup }
+
+ OBJECT snmpCommunityName
+ MIN-ACCESS read-only
+ DESCRIPTION "Write access is not required."
+
+ OBJECT snmpCommunitySecurityName
+ MIN-ACCESS read-only
+ DESCRIPTION "Write access is not required."
+
+ OBJECT snmpCommunityContextEngineID
+ MIN-ACCESS read-only
+ DESCRIPTION "Write access is not required."
+
+ OBJECT snmpCommunityContextName
+ MIN-ACCESS read-only
+ DESCRIPTION "Write access is not required."
+
+ OBJECT snmpCommunityTransportTag
+ MIN-ACCESS read-only
+ DESCRIPTION "Write access is not required."
+
+ OBJECT snmpCommunityStorageType
+
+
+
+Frye, et al. Standards Track [Page 37]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ MIN-ACCESS read-only
+ DESCRIPTION "Write access is not required."
+
+ OBJECT snmpCommunityStatus
+ MIN-ACCESS read-only
+ DESCRIPTION "Write access is not required."
+
+ ::= { 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
+ OBJECTS {
+ snmpCommunityName,
+ snmpCommunitySecurityName,
+ snmpCommunityContextEngineID,
+ snmpCommunityContextName,
+ snmpCommunityTransportTag,
+ snmpCommunityStorageType,
+ snmpCommunityStatus,
+ snmpTargetAddrTMask,
+ snmpTargetAddrMMS
+ }
+ STATUS current
+ DESCRIPTION
+ "A collection of objects providing for configuration
+ of community strings for SNMPv1 (and SNMPv2c) usage."
+ ::= { 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
+
+
+
+Frye, et al. Standards Track [Page 38]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ translating to SNMPv2c or SNMPv3."
+ ::= { snmpCommunityMIBGroups 3 }
+
+END
+
+6. Intellectual Property
+
+The IETF takes no position regarding the validity or scope of any
+intellectual property or other rights that might be claimed to pertain
+to the implementation or use of the technology described in this
+document or the extent to which any license under such rights might or
+might not be available; neither does it represent that it has made any
+effort to identify any such rights. Information on the IETF's
+procedures with respect to rights in standards-track and standards-
+related documentation can be found in BCP-11. Copies of claims of
+rights made available for publication and any assurances of licenses to
+be made available, or the result of an attempt made to obtain a general
+license or permission for the use of such proprietary rights by
+implementors or users of this specification can be obtained from the
+IETF Secretariat.
+
+The IETF invites any interested party to bring to its attention any
+copyrights, patents or patent applications, or other proprietary rights
+which may cover technology that may be required to practice this
+standard. Please address the information to the IETF Executive
+Director.
+
+7. Acknowledgments
+
+This document is the result of the efforts of the SNMPv3 Working Group.
+The design of the SNMP-COMMUNITY-MIB incorporates work done by the
+authors of SNMPv2*:
+
+ Jeff Case (SNMP Research, Inc.)
+ David Harrington (Cabletron Systems Inc.)
+ David Levi (SNMP Research, Inc.)
+ Brian O'Keefe (Hewlett Packard)
+ Jon Saperia (IronBridge Networks, Inc.)
+ Steve Waldbusser (International Network Services)
+
+
+
+
+
+
+
+
+
+
+
+
+Frye, et al. Standards Track [Page 39]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+8. Security Considerations
+
+ Although SNMPv1 and SNMPv2 do not provide any security, allowing
+ community names to be mapped into securityName/contextName provides
+ the ability to use view-based access control to limit the access of
+ unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for
+ network administrators to make use of this capability in order to
+ avoid unauthorized access to MIB data that would otherwise be secure.
+
+ Further, the SNMP-COMMUNITY-MIB has the potential to expose community
+ strings which provide access to more information than that which is
+ available using the usual 'public' community string. For this
+ reason, a security administrator may wish to limit accessibility to
+ the SNMP-COMMUNITY-MIB, and in particular, to make it inaccessible
+ when using the 'public' community string.
+
+ When a proxy implementation translates messages between SNMPv1 (or
+ SNMPv2c) and SNMPv3, there may be a loss of security. For example,
+ an SNMPv3 message received using authentication and privacy which is
+ subsequently forwarded using SNMPv1 will lose the security benefits
+ of using authentication and privacy. Careful configuration of
+ proxies is required to address such situations. One approach to deal
+ with such situations might be to use an encrypted tunnel.
+
+9. References
+
+ [1] Rose, M. and K. McCloghrie, "Structure and Identification of
+ Management Information for TCP/IP-based internets", STD 16, RFC
+ 1155, May 1990.
+
+ [2] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
+ Network Management Protocol", STD 15, RFC 1157, May 1990.
+
+ [3] McCloghrie, K. and M. Rose, Editors, "Concise MIB Definitions",
+ STD 16, RFC 1212, March 1991.
+
+ [4] Rose, M., "A Convention for Defining Traps for use with the
+ SNMP", RFC 1215, March 1991.
+
+ [5] McCloghrie, K. and M. Rose, "A Convention for Describing SNMP-
+ based Agents", RFC 1303, February 1992.
+
+ [6] Case, J., McCloghrie, K., Rose, M. and S.Waldbusser,
+ "Introduction to Community-based SNMPv2", RFC 1901, January
+ 1996.
+
+
+
+
+
+
+Frye, et al. Standards Track [Page 40]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
+ M. and S. Waldbusser, "Structure of Management Information
+ Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
+
+ [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
+ M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
+ RFC 2579, April 1999.
+
+ [9] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
+ M. and S. Waldbusser, "Conformance Statements for SMIv2", STD
+ 58, RFC 2580, April 1999.
+
+ [10] Case, J., McCloghrie, K., Rose, M. and S.Waldbusser, "Protocol
+ Operations for Version 2 of the Simple Network Management
+ Protocol (SNMPv2)", RFC 1905, January 1996.
+
+ [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
+ Mappings for Version 2 of the Simple Network Management Protocol
+ (SNMPv2)", RFC 1906, January 1996.
+
+ [12] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+ "Management Information Base for Version 2 of the Simple Network
+ Management Protocol (SNMPv2)", RFC 1907, January 1996.
+
+ [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+ "Coexistence between Version 1 and Version 2 of the Internet-
+ standard Network Management Framework", RFC 1908, January 1996.
+
+ [14] Levi, D. and B. Wijnen, "Mapping SNMPv2 onto SNMPv1 within a
+ bi-lingual SNMP agent", RFC 2089, January 1997.
+
+ [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [16] Harrington, D. and B. Wijnen, "An Architecture for Describing
+ SNMP Management Frameworks", RFC 2571, May 1999.
+
+ [17] Case, J., Harrington, D. and B. Wijnen, "Message Processing and
+ Dispatching for the Simple Network Management Protocol (SNMP)",
+ RFC 2572, May 1999.
+
+ [18] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC
+ 2573, May 1999.
+
+ [19] Blumenthal, U. and Wijnen, B., "The User-Based Security Model
+ for Version 3 of the Simple Network Management Protocol (SNMP)",
+ RFC 2574, May 1999.
+
+
+
+
+Frye, et al. Standards Track [Page 41]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+ [20] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
+ Control Model for the Simple Network Management Protocol
+ (SNMP)", RFC 2575, May 1999.
+
+10. Editor's Addresses
+
+ Rob Frye
+ CoSine Communications
+ 1200 Bridge Parkway
+ Redwood City, CA 94065
+ U.S.A.
+
+ Phone: +1 703 725 1130
+ EMail: rfrye@cosinecom.com
+
+
+ David B. Levi
+ Nortel Networks
+ 3505 Kesterwood Drive
+ Knoxville, TN 37918
+ U.S.A.
+
+ Phone: +1 423 686 0432
+ EMail: dlevi@nortelnetworks.com
+
+
+ Shawn A. Routhier
+ Integrated Systems Inc.
+ 333 North Ave 4th Floor
+ Wakefield MA 01880
+ U.S.A.
+
+ Phone: + 1 781 245 0804
+ EMail: sar@epilogue.com
+
+
+ Bert Wijnen
+ Lucent Technologies
+ Schagen 33
+ 3461 GL Linschoten
+ Netherlands
+
+ Phone: +31 348 407-775
+ EMail: wijnen@lucent.com
+
+
+
+
+
+
+
+Frye, et al. Standards Track [Page 42]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+A. Changes From RFC1908
+
+ - Editorial changes to comply with current RFC requirements.
+
+ - Added/updated copyright statements.
+
+ - Added Intellectual Property section.
+
+ - Replaced old introduction with complete new introduction/overview.
+
+ - Added content for the Security Considerations Section.
+
+ - Updated References to current documents.
+
+ - Updated text to use current SNMP terminology.
+
+ - Added coexistence for/with SNMPv3.
+
+ - Added description for SNMPv1 and SNMPv2c Message Processing
+ Models and SNMPv1 and SNMPv2c Community-based Security
+ Models.
+
+ - Added snmpCommunityMIB so that SNMPv1 and SNMPv2 community
+ strings can be mapped into the SNMP Version Independent
+ paramaters which can then be used for access control using the
+ standard SNMPv3 View-based Access Control Model and the
+ snmpVacmMIB.
+
+ - Added two MIB objects such that when an SNMPv1 notification
+ (trap) must be converted into an SNMPv2 notification we add
+ those two objects in order to preserve information about the
+ address and community of the originating SNMPv1 agent.
+
+ - Included (and extended) from RFC2089 the SNMPv2 to SNMPv1
+ mapping within a multi-lingual SNMP Engine.
+
+ - Use keywords from RFC 2119 to describe requirements for
+ compliance.
+
+ - Changed/added some rules for converting a MIB module from
+ SMIv1 to SMIv2.
+
+ - Extended and improved the description of Proxy Forwarder
+ behaviour when multiple SNMP versions are involved.
+
+
+
+
+
+
+
+Frye, et al. Standards Track [Page 43]
+
+RFC 2576 Coexistence between SNMP versions March 2000
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Frye, et al. Standards Track [Page 44]
+