summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3584.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc3584.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc3584.txt')
-rw-r--r--doc/rfc/rfc3584.txt2859
1 files changed, 2859 insertions, 0 deletions
diff --git a/doc/rfc/rfc3584.txt b/doc/rfc/rfc3584.txt
new file mode 100644
index 0000000..402c12f
--- /dev/null
+++ b/doc/rfc/rfc3584.txt
@@ -0,0 +1,2859 @@
+
+
+
+
+
+
+Network Working Group R. Frye
+Request for Comments: 3584 Vibrant Solutions
+BCP: 74 D. Levi
+Obsoletes: 2576 Nortel Networks
+Category: Best Current Practice S. Routhier
+ Wind River Systems, Inc.
+ B. Wijnen
+ Lucent Technologies
+ August 2003
+
+
+ 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 Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). 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 also describes how to
+ convert MIB modules from SMIv1 format to SMIv2 format. This document
+ obsoletes RFC 2576.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 1]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+Table Of Contents
+
+ 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. SNMPv1 . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.2. SNMPv2 . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3. SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . 8
+ 2.2. Compliance Statements. . . . . . . . . . . . . . . . . 9
+ 2.3. Capabilities Statements. . . . . . . . . . . . . . . . 9
+ 3. Translating Notification Parameters. . . . . . . . . . . . . 10
+ 3.1. Translating SNMPv1 Notification Parameters to
+ SNMPv2 Notification Parameters . . . . . . . . . . . . 11
+ 3.2. Translating SNMPv2 Notification Parameters to
+ SNMPv1 Notification Parameters . . . . . . . . . . . . 12
+ 4. Approaches to Coexistence in a Multi-lingual Network . . . . 14
+ 4.1. SNMPv1 and SNMPv2 Access to MIB Data . . . . . . . . . 14
+ 4.2. Multi-lingual implementations. . . . . . . . . . . . . 15
+ 4.2.1. Command Generator. . . . . . . . . . . . . . . 15
+ 4.2.2. Command Responder. . . . . . . . . . . . . . . 16
+ 4.2.2.1. Handling Counter64 . . . . . . . . . 16
+ 4.2.2.2. Mapping SNMPv2 Exceptions. . . . . . 17
+ 4.2.2.2.1. Mapping noSuchObject
+ and noSuchInstance. . . . 18
+ 4.2.2.2.2. Mapping endOfMibView. . . 18
+ 4.2.2.3. Processing An SNMPv1 GetReques . . . 18
+ 4.2.2.4. Processing An SNMPv1 GetNextRequest. 19
+ 4.2.2.5. Processing An SNMPv1 SetRequest. . . 20
+ 4.2.3. Notification Originator. . . . . . . . . . . . 21
+ 4.2.4. Notification Receiver. . . . . . . . . . . . . 21
+ 4.3. Proxy Implementations. . . . . . . . . . . . . . . . . 22
+ 4.3.1. Upstream Version Greater Than Downstream
+ Version. . . . . . . . . . . . . . . . . . . . 22
+ 4.3.2. Upstream Version Less Than Downstream Version. 23
+ 4.4. Error Status Mappings. . . . . . . . . . . . . . . . . 25
+ 5. Message Processing Models and Security Models. . . . . . . . 26
+ 5.1. Mappings . . . . . . . . . . . . . . . . . . . . . . . 26
+ 5.2. The SNMPv1 MP Model and SNMPv1 Community-based
+ Security Model . . . . . . . . . . . . . . . . . . . . 26
+ 5.2.1. Processing An Incoming Request . . . . . . . . 27
+ 5.2.2. Generating An Outgoing Response. . . . . . . . 29
+ 5.2.3. Generating An Outgoing Notification. . . . . . 29
+ 5.2.4. Proxy Forwarding Of Requests . . . . . . . . . 30
+ 5.3. The SNMP Community MIB Module. . . . . . . . . . . . . 30
+ 6. Intellectual Property Statement. . . . . . . . . . . . . . . 42
+ 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 43
+
+
+
+Frye, et al. Best Current Practice [Page 2]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ 8. Security Considerations. . . . . . . . . . . . . . . . . . . 43
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
+ 9.1. Normative References . . . . . . . . . . . . . . . . . 44
+ 9.2. Informative References . . . . . . . . . . . . . . . . 46
+ Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 47
+ A.1. Changes From RFC 2576 . . . . . . . . . . . . . . . . . 47
+ A.2. Changes Between RFC 1908 and RFC 2576 . . . . . . . . . 49
+ Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 51
+
+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).
+
+ 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 RFC 2119 [RFC2119].
+
+ 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).
+
+
+
+
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 3]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+1.1. SNMPv1
+
+ SNMPv1 is defined by these documents:
+
+ - STD 15, RFC 1157 [RFC1157] which defines the Simple Network
+ Management Protocol (SNMPv1), the protocol used for network access
+ to managed objects.
+
+ - STD 16, RFC 1155 [RFC1155] 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 [RFC1212] which defines a more concise
+ description mechanism, which is wholly consistent with the SMIv1.
+
+ - RFC 1215 [RFC1215] 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.
+
+1.2. SNMPv2
+
+ SNMPv2 is defined by these documents:
+
+ - STD 58, RFC 2578 which defines Version 2 of the Structure of
+ Management Information (SMIv2) [RFC2578].
+
+ - STD 58, RFC 2579 which defines common MIB "Textual Conventions"
+ [RFC2579].
+
+ - STD 58, RFC 2580 which defines Conformance Statements and
+ requirements for defining agent and manager capabilities
+ [RFC2580].
+
+ - STD 62, RFC 3416 which defines the Protocol Operations used in
+ processing [RFC3416].
+
+ - STD 62, RFC 3417 which defines the Transport Mappings used "on the
+ wire" [RFC3417].
+
+ - STD 62, RFC 3418 which defines the basic Management Information
+ Base for monitoring and controlling some basic common functions of
+ SNMP entities [RFC3418].
+
+ Note that SMIv2 as used throughout this document refers to the first
+ three documents listed above (RFCs 2578, 2579, and 2580).
+
+
+
+Frye, et al. Best Current Practice [Page 4]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ The following document augments the definition of SNMPv2:
+
+ - RFC 1901 [RFC1901] 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:
+
+ - STD 62, RFC 3411 which defines an Architecture for Describing SNMP
+ Management Frameworks [RFC3411].
+
+ - STD 62, RFC 3412 which defines Message Processing and Dispatching
+ [RFC3412].
+
+ - STD 62, RFC 3413 which defines various SNMP Applications
+ [RFC3413].
+
+ - STD 62, RFC 3414 which defines the User-based Security Model
+ (USM), providing for both Authenticated and Private (encrypted)
+ SNMP messages [RFC3414].
+
+ - STD 62, RFC 3415 which defines the View-based Access Control Model
+ (VACM), providing the ability to limit access to different MIB
+ objects on a per-user basis [RFC3415].
+
+ SNMPv3 also uses the SNMPv2 definitions of RFCs 3416 through 3418 and
+ the SMIv2 definitions of 2578 through 2580 described above. Note
+ that text throughout this document that refers to SNMPv2 PDU types
+ and protocol operations applies to both SNMPv2c and SNMPv3.
+
+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 [ASN1] 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.
+
+
+
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 5]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+2.1. MIB Modules
+
+ MIB modules defined using the SMIv1 may continue to be used with
+ protocol versions which use SNMPv2 PDUs. However, for SMIv1 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 a SYNTAX clause value of Counter, the object
+ MUST have the value of its SYNTAX clause changed to Counter32.
+
+ (4) 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.
+
+ (5) 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
+ 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.
+
+ (6) 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.
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 6]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ (7) For any object not containing a DESCRIPTION clause, the object
+ MUST have a DESCRIPTION clause defined.
+
+ (8) 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.
+
+ (9) 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. The effect of this, and the preceding bullet, is
+ to allow 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.
+
+ (10) 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).
+
+ (11) 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.
+
+ (12) One or more OBJECT-GROUPS MUST be defined, and related objects
+ MUST be collected into appropriate groups. Note that SMIv2
+ requires all OBJECT-TYPEs to be a member of at least one
+ OBJECT-GROUP.
+
+ (13) 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".
+
+ (14) For any conceptual row object that is not 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. Best Current Practice [Page 7]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ 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 RFC 2578 [RFC2578], and the RowStatus and StorageType
+ TEXTUAL-CONVENTIONs are described in section 2 of RFC 2579
+ [RFC2579].
+
+ (2) 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 SHOULD have the value of its SYNTAX clause
+ changed to Integer32, or have an appropriate range specified.
+
+ (3) 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.
+
+ (4) 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.
+
+ (5) For any object which represents a measurement in some kind of
+ units, a UNITS clause SHOULD be added to the definition of that
+ object.
+
+ (6) 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.
+
+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:
+
+
+
+
+Frye, et al. Best Current Practice [Page 8]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ (1) The IMPORTS statement MUST NOT reference RFC-1215 [RFC1215], 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.
+
+ 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
+
+ RFC 1303 [RFC1303] uses the MODULE-CONFORMANCE macro to describe an
+ agent's capabilities with respect to one or more MIB modules.
+
+
+
+Frye, et al. Best Current Practice [Page 9]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ Converting such a description for use with the SMIv2 requires these
+ changes:
+
+ (1) The macro name AGENT-CAPABILITIES MUST be used instead of
+ MODULE-CONFORMANCE.
+
+ (2) The STATUS clause MUST 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 RFC 2580 [RFC2580].
+
+ 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 Notification 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
+ referred to in this document as 'SNMPv1 notification parameters'.
+ The format of parameters used for SNMPv2 notification protocol
+ operations is referred to in this document as 'SNMPv2 notification
+ parameters'.
+
+ 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.
+
+
+
+Frye, et al. Best Current Practice [Page 10]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ 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, and is equal to the value portion of that variable-binding
+ (not the name portion, as both the name and value are OBJECT
+ IDENTIFIERs).
+
+ - A list of variable-bindings (VarBindList). This refers to all but
+ the first two variable-bindings in an SNMPv2-Trap-PDU or
+ InformRequest-PDU.
+
+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.
+
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 11]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ (2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)',
+ the SNMPv2 snmpTrapOID parameter SHALL be the concatenation 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 RFC 3418
+ [RFC3418]:
+
+ 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 [RFC3418], and the value SHALL be the
+ SNMPv1 enterprise parameter.
+
+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 RFC 3418 [RFC3418], then the SNMPv1
+ enterprise parameter SHALL be set to the value of the
+ variable-binding in the SNMPv2 variable-bindings whose name is
+
+
+
+Frye, et al. Best Current Practice [Page 12]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ 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 RFC 3418 [RFC3418].
+
+ - If the SNMPv2 snmpTrapOID parameter is not one of the standard
+ traps as defined in RFC 3418 [RFC3418], 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 value
+ is zero, then the SNMPv1 enterprise SHALL be the SNMPv2
+ snmpTrapOID value with the last 2 sub-identifiers removed,
+ otherwise
+
+ - If the next-to-last sub-identifier of the snmpTrapOID value
+ is non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2
+ snmpTrapOID value 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.
+
+ (3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps
+ as defined in RFC 3418 [RFC3418], 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
+
+
+
+Frye, et al. Best Current Practice [Page 13]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ 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 RFC 3418 [RFC3418], 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 (and note that the SNMPv2 variable-bindings do not
+ include the variable-bindings containing sysUpTime.0,
+ snmpTrapOID.0). 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.2.3 and section 4.3).
+
+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.
+
+4.1. SNMPv1 and SNMPv2 Access to MIB Data
+
+ Throughout section 4., 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.
+
+
+
+
+Frye, et al. Best Current Practice [Page 14]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ - 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.
+
+ Further, note that there is no mention of 'SNMPv3 access to MIB data'
+ in this document, as SNMPv3 uses SNMPv2 PDU types and protocol
+ operations.
+
+4.2. 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.2.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
+
+
+
+Frye, et al. Best Current Practice [Page 15]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ 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.2.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. Also, SNMPv1 access to MIB data SHOULD NOT be used
+ when processing SNMPv2c or SNMPv3 messages. 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 SNMPv2 access to MIB data when processing an SNMPv1 message.
+
+4.2.2.1. Handling Counter64
+
+ The SMIv2 [RFC2578] 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-
+
+
+
+Frye, et al. Best Current Practice [Page 16]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ 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.2.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 an
+ error-index value.
+
+ 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.
+
+
+
+Frye, et al. Best Current Practice [Page 17]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+4.2.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 (if
+ there is more than one then 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.2.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 (if there is more than one then 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.2.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.4, "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.
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 18]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ (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.
+
+4.2.2.4. Processing An SNMPv1 GetNextRequest
+
+ When processing an SNMPv1 GetNextRequest, the following procedures
+ MUST be followed when SNMPv2 access to MIB data is used 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.4, "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.
+
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 19]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ (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 or endOfMibView
+ exception occurs.
+
+ (2) If there is any variable binding that contains an SNMPv2
+ exception endOfMibView (if there is more than one then 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:
+
+ - 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.2.2.5. Processing An SNMPv1 SetRequest
+
+ When processing an SNMPv1 SetRequest, the following procedures MUST
+ be followed when using SNMPv2 access to MIB data.
+
+ When such MIB access returns 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.4, "Error Status Mappings".
+
+
+
+
+Frye, et al. Best Current Practice [Page 20]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ - 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.2.3. Notification Originator
+
+ A notification originator must be able to translate between SNMPv1
+ notification 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).
+
+ 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 [RFC3413], 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.2.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
+
+
+
+Frye, et al. Best Current Practice [Page 21]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ 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.3. 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 or
+ notification receiver and the proxy, and the 'Downstream Version'
+ refers to the version used between the proxy and the command
+ responder or notification originator, regardless of the PDU type or
+ direction.
+
+4.3.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 act as if
+ the non-repeaters and max-repetitions fields were both set to 0,
+ and SHALL set the tag of the PDU to GetNextRequest-PDU.
+
+ - If a GetResponse-PDU is received whose error-status field has a
+ value of 'tooBig', and the message will be forwarded using the
+ SNMPv2c or SNMPv3 message version, 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
+ and ensure that the error-index field is set to 0 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-
+
+
+
+Frye, et al. Best Current Practice [Page 22]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ bindings field, and change the error-status field to 'noError',
+ and ensure that the error-index field is set to 0 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'. Further note that, while it might have
+ been possible to fit more variable bindings if the proxy only re-
+ sent the request multiple times, and stripped only a single
+ variable binding from the request at a time, this is deemed too
+ expensive. The approach described here preserves the behaviour of
+ a GetBulkRequest as closely as possible, without incurring the
+ cost of re-sending the request multiple times.
+
+ - If a Trap-PDU is received, and will be forwarded using the SNMPv2c
+ or SNMPv3 message version, the proxy SHALL apply the translation
+ rules described in section 3, and SHALL forward the notification
+ as an SNMPv2-Trap-PDU.
+
+ Note that when an SNMPv1 agent generates a message containing a
+ Trap-PDU which is subsequently forwarded by one or more proxy
+ forwarders using SNMP versions other than SNMPv1, the community
+ string and agent-addr fields from the original message generated
+ by the SNMPv1 agent will be preserved through the use of the
+ snmpTrapAddress and snmpTrapCommunity objects.
+
+4.3.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.
+
+ - 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.
+
+
+
+
+Frye, et al. Best Current Practice [Page 23]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ - 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. However, when using such a configuration, one should be
+ careful to use a different principal for communicating with the
+ target agent when an incoming SNMPv2c or SNMPv3 request is
+ received, to ensure that objects of type Counter64 are properly
+ returned.
+
+ - 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, and the message would be forwarded using
+ the SNMPv1 message version, the error-status value is modified
+ using the mappings in section 4.4.
+
+ - If an SNMPv2-Trap-PDU is received, and will be forwarded using the
+ SNMPv1 message version, the proxy SHALL apply the translation
+ rules described in section 3, and SHALL forward the notification
+ as a Trap-PDU. 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.
+
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 24]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ - 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.4. 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
+
+ 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.
+
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 25]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+5. Message Processing Models and Security Models
+
+ In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture,
+ the following Message Processing (MP) models are defined in this
+ document:
+
+ - The SNMPv1 Message Processing Model
+
+ - The SNMPv1 Community-Based Security Model
+
+ - 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 [RFC3411]. 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.
+
+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 RFC 1157 [RFC1157], with differences and
+ clarifications as described in the following sections. The
+ SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for
+ SNMPv2c is 1).
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 26]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+5.2.1. Processing An Incoming Request
+
+ In RFC 1157 [RFC1157], 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
+ 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 RFC 1157 [RFC1157], and the snmpInBadCommunityNames
+ counter is incremented.
+
+
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 27]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ The parameters returned from the Community-Based Security Model are:
+
+ - The securityEngineID, which will always be the local value of
+ snmpEngineID.0.
+
+ - The securityName, which will be the value of
+ snmpCommunitySecurityName from the selected row in the
+ snmpCommunityTable.
+
+ - The scopedPDU. Note that this parameter will actually consist of
+ three values, the contextSnmpEngineID (which will be the value of
+ snmpCommunityContextEngineID from the selected entry in the
+ snmpCommunityTable), the contextName (which will be the value of
+ snmpCommunityContextName from the selected entry in the
+ snmpCommunityTable), and the PDU. These must be separate values,
+ since the first two do not actually appear in the message.
+
+ - The maxSizeResponseScopedPDU, which will be derived using the
+ minimum of the maxMessageSize above, and the value of
+ snmpTargetAddrMMS of the selected row in the snmpTargetAddrTable.
+ If no such entry was selected, then this value will be derived
+ from the maxMessageSize only.
+
+ - The securityStateReference, which MUST contain the community
+ string from the original request.
+
+ 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. Best Current Practice [Page 28]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ - 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
+ securityStateReference 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.
+
+
+
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 29]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ - 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 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.2.4. Proxy Forwarding Of Requests
+
+ In a proxy forwarding application, when a received request is to be
+ forwarded using the SNMPv1 Message Processing Model, the parameters
+ used for forwarding will be obtained by examining the SNMP-PROXY-MIB
+ and the SNMP-TARGET-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 no such entry can be found, the proxy forwarding application
+ should follow the procedure described in RFC 3413 [RFC3413], section
+ 3.5.1.1, item (2). This procedure states that the snmpProxyDrops
+ counter [RFC3418] is incremented, and that a Response-PDU is
+ generated by calling the Dispatcher using the returnResponsePdu
+ abstract service interface.
+
+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
+
+
+
+Frye, et al. Best Current Practice [Page 30]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ features are accomplished by providing a tag in the
+ snmpCommunityTable which selects sets of entries in the
+ snmpTargetAddrTable [RFC3413]. 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). If use of
+ the snmpTargetAddrTMask object is not mentioned in text describing
+ matching addresses in the snmpTargetAddrTable, then its value MUST be
+ ignored.
+
+ 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
+ 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.
+
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 31]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ 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 "200308060000Z" -- 06 Aug 2003, midnight
+ ORGANIZATION "SNMPv3 Working Group"
+ CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com
+ Subscribe: majordomo@lists.tislabs.com
+ In msg body: subscribe snmpv3
+
+ Co-Chair: Russ Mundy
+ SPARTA, Inc
+ Postal: 7075 Samuel Morse Drive
+ Columbia, MD 21045
+ USA
+ EMail: mundy@tislabs.com
+ Phone: +1 410-872-1515
+
+ Co-Chair: David Harrington
+ Enterasys Networks
+ Postal: 35 Industrial Way
+ P. O. Box 5005
+ Rochester, New Hampshire 03866-5005
+ USA
+ EMail: dbh@enterasys.com
+ Phone: +1 603-337-2614
+
+ Co-editor: Rob Frye
+ Vibrant Solutions
+
+
+
+Frye, et al. Best Current Practice [Page 32]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ Postal: 2711 Prosperity Ave
+ Fairfax, Virginia 22031
+ USA
+ E-mail: rfrye@vibrant-1.com
+ Phone: +1-703-270-2000
+
+ Co-editor: David B. Levi
+ Nortel Networks
+ Postal: 3505 Kesterwood Drive
+ Knoxville, Tennessee 37918
+ E-mail: dlevi@nortelnetworks.com
+ Phone: +1 865 686 0432
+
+ Co-editor: Shawn A. Routhier
+ Wind River Systems, Inc.
+ Postal: 500 Wind River Way
+ Alameda, CA 94501
+ E-mail: sar@epilogue.com
+ Phone: +1 510 749 2095
+
+ 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.
+
+ Copyright (C) The Internet Society (2003) This
+ version of this MIB module is part of RFC 3584;
+ see the RFC itself for full legal notices."
+
+ REVISION "200308060000Z" -- 06 Aug 2003
+ DESCRIPTION
+ "Updated the LAST-UPDATED, CONTACT-INFO, and REVISION
+ clauses and added a copyright notice to the
+ DESCRIPTION clause of the MIB module's
+ MODULE-IDENTITY invocation.
+
+ Updated the description of snmpCommunityTransportTag
+ to make it consistent with the rest of the document.
+
+ Updated the description of `snmpTargetAddrMMS' to
+
+
+
+Frye, et al. Best Current Practice [Page 33]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ clarify that a value of 0 means that the maximum
+ message size is unknown.
+
+ Changed the name of 'snmpCommunityGroup' to
+ snmpCommunityTableGroup to avoid a name conflict
+ with the SNMPv2-MIB.
+
+ Updated DESCRIPTION of snmpCommunityName.
+
+ Updated DESCRIPTION of snmpTrapCommunity.
+
+ Added snmpCommunityMIBFullCompliance.
+
+ This version published as RFC 3584."
+
+ REVISION "200003060000Z" -- 6 Mar 2000
+ DESCRIPTION "This version published as RFC 2576."
+
+ ::= { 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 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
+
+
+
+Frye, et al. Best Current Practice [Page 34]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ 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. There is no SIZE constraint
+ specified for this object because RFC 1157 does not
+ impose any explicit limitation on the length of community
+ strings (their size is constrained indirectly by the
+ SNMP message size)."
+ ::= { snmpCommunityEntry 2 }
+
+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
+
+
+
+Frye, et al. Best Current Practice [Page 35]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ 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
+ which are used in two ways:
+ - to specify the transport endpoints from which an
+ SNMP entity will accept management requests, and
+ - to specify the transport endpoints to which a
+ notification may be sent using the community
+ string matching the corresponding instance of
+ snmpCommunityName.
+ In either case, if the value of this object has
+ zero-length, transport endpoints are not checked when
+ either authenticating messages containing this community
+ string, nor when generating notifications.
+
+ The transports identified by this object are specified
+ in the snmpTargetAddrTable. Entries in that table
+ whose snmpTargetAddrTagList contains this tag value
+ are identified.
+
+ If a management request containing a community string
+
+
+
+Frye, et al. Best Current Practice [Page 36]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ that matches the corresponding instance of
+ snmpCommunityName is received on a transport endpoint
+ other than the transport endpoints identified by this
+ object the request is deemed unauthentic.
+
+ When a notification is to be sent using an entry in
+ this table, if the destination transport endpoint of
+ the notification does not match one of the transport
+ endpoints selected by this object, the notification
+ is not sent."
+ 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
+
+
+
+Frye, et al. Best Current Practice [Page 37]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The table of mask and maximum message size (mms) values
+ associated with the 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
+
+
+
+Frye, et al. Best Current Practice [Page 38]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ 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.
+
+ 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. Note that a value of 0 means
+ that the maximum message size is unknown."
+ 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 }
+
+
+
+
+Frye, et al. Best Current Practice [Page 39]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+snmpTrapCommunity OBJECT-TYPE
+ SYNTAX OCTET STRING
+ MAX-ACCESS accessible-for-notify
+ STATUS current
+ DESCRIPTION
+ "The value of the community string field of an SNMPv1
+ message containing a Trap PDU which is forwarded by a
+ a proxy forwarder application using an SNMP version
+ other than SNMPv1. The value of this object SHOULD
+ contain the value of the community string field from
+ the original SNMPv1 message containing a Trap PDU as
+ generated by an SNMPv1 agent. There is no SIZE
+ constraint specified for this object because RFC 1157
+ does not impose any explicit limitation on the length
+ of community strings (their size is constrained
+ indirectly by the SNMP message size)."
+ ::= { 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 { snmpCommunityTableGroup }
+
+ 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."
+
+
+
+
+Frye, et al. Best Current Practice [Page 40]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ 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
+ 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 }
+
+snmpCommunityMIBFullCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for SNMP engines which
+ implement the SNMP-COMMUNITY-MIB with full read-create
+ access."
+
+ MODULE -- this module
+ MANDATORY-GROUPS { snmpCommunityTableGroup }
+ ::= { snmpCommunityMIBCompliances 3 }
+
+snmpCommunityTableGroup OBJECT-GROUP
+ OBJECTS {
+ snmpCommunityName,
+ snmpCommunitySecurityName,
+ snmpCommunityContextEngineID,
+ snmpCommunityContextName,
+ snmpCommunityTransportTag,
+ snmpCommunityStorageType,
+
+
+
+Frye, et al. Best Current Practice [Page 41]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ 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
+ translating to SNMPv2c or SNMPv3."
+ ::= { snmpCommunityMIBGroups 3 }
+
+END
+
+6. Intellectual Property Statement
+
+ 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.
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 42]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+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 (Enterasys Networks)
+ David Levi (Nortel Networks)
+ Brian O'Keefe (Hewlett Packard)
+ Jon Saperia (IronBridge Networks, Inc.)
+ Steve Waldbusser (International Network Services)
+
+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.
+
+ 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 (also known as confidentiality).
+ Careful configuration of proxies is required to address such
+ situations. One approach to deal with such situations might be to
+ use an encrypted tunnel.
+
+ There are a number of management objects defined in this MIB module
+ with a MAX-ACCESS clause of read-write and/or read-create. Such
+ objects may be considered sensitive or vulnerable in some network
+ environments. The support for SET operations in a non-secure
+ environment without proper protection can have a negative effect on
+ network operations. These are the tables and objects and their
+ sensitivity/vulnerability:
+
+ - The snmpCommunityTable allows creation and deletion of community
+ strings, which is potentially a serious security hole. Access to
+ this table should be greatly restricted, preferably by only
+ allowing write access using SNMPv3 VACM and USM, with
+ authentication and privacy.
+
+ - The snmpTargetAddrExtTable contains write-able objects which may
+ also be considered sensitive, and so access to it should be
+ restricted as well.
+
+
+
+Frye, et al. Best Current Practice [Page 43]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ Some of the readable objects in this MIB module (i.e., objects with a
+ MAX-ACCESS other than not-accessible) may be considered sensitive or
+ vulnerable in some network environments. It is thus important to
+ control even GET and/or NOTIFY access to these objects and possibly
+ to even encrypt the values of these objects when sending them over
+ the network via SNMP. These are the tables and objects and their
+ sensitivity/vulnerability:
+
+ - The snmpCommunityTable 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 objects in the snmpCommunityTable, and in particular, to make
+ it inaccessible when using the 'public' community string.
+
+ SNMP versions prior to SNMPv3 did not include adequate security.
+ Even if the network itself is secure (for example by using IPSec),
+ even then, there is no control as to who on the secure network is
+ allowed to access and GET/SET (read/change/create/delete) the objects
+ in this MIB module.
+
+ It is RECOMMENDED that implementers consider the security features as
+ provided by the SNMPv3 framework (see [RFC3410], section 8),
+ including full support for the SNMPv3 cryptographic mechanisms (for
+ authentication and privacy).
+
+ Further, deployment of SNMP versions prior to SNMPv3 is NOT
+ RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
+ enable cryptographic security. It is then a customer/operator
+ responsibility to ensure that the SNMP entity giving access to an
+ instance of this MIB module is properly configured to give access to
+ the objects only to those principals (users) that have legitimate
+ rights to indeed GET or SET (change/create/delete) them.
+
+9. References
+
+9.1. Normative References
+
+ [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
+ of Management Information for TCP/IP-based internets",
+ STD 16, RFC 1155, May 1990.
+
+ [RFC1157] Case, J., Fedor, M., Schoffstall, M. and C. Davin,
+ "Simple Network Management Protocol (SNMP)", STD 15, RFC
+ 1157, May 1990.
+
+ [RFC1212] Rose, M. and K. McCloghrie, Eds., "Concise MIB
+ Definitions", STD 16, RFC 1212, March 1991.
+
+
+
+Frye, et al. Best Current Practice [Page 44]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ [RFC1215] Rose, M., "A Convention for Defining Traps for use with
+ the SNMP", RFC 1215, March 1991.
+
+ [RFC1303] McCloghrie, K. and M. Rose, "A Convention for Describing
+ SNMP-based Agents", RFC 1303, February 1992.
+
+ [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+ "Introduction to Community-based SNMPv2", RFC 1901,
+ January 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
+ "Structure of Management Information Version 2 (SMIv2)",
+ RFC 2578, STD 58, April 1999.
+
+ [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
+ "Textual Conventions for SMIv2", STD 58, RFC 2579, April
+ 1999.
+
+ [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
+ "Conformance Statements for SMIv2", STD 58, RFC 2580,
+ April 1999.
+
+ [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An
+ Architecture for Describing Simple Network Management
+ Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
+ December 2002.
+
+ [RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
+ "Message Processing and Dispatching for the Simple
+ Network Management Protocol (SNMP)", STD 62, RFC 3412,
+ December 2002.
+
+ [RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network
+ Management Protocol (SNMP) Applications", STD 62, RFC
+ 3413, December 2002.
+
+ [RFC3414] Blumenthal, U. and B. Wijnen, "The User-Based Security
+ Model (USM) for Version 3 of the Simple Network
+ Management Protocol (SNMP)", STD 62, RFC 3414, December
+ 2002.
+
+ [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
+ Access Control Model (VACM) for the Simple Network
+ Management Protocol (SNMP)", STD 62, RFC 3415, December
+ 2002.
+
+
+
+Frye, et al. Best Current Practice [Page 45]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations
+ for the Simple Network Management Protocol (SNMPv2)", STD
+ 62, RFC 3416, December 2002.
+
+ [RFC3417] Presuhn, R., Ed., "Transport Mappings for Version 2 of
+ the Simple Network Management Protocol (SNMPv2)", STD 62,
+ RFC 3417, December 2002.
+
+ [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for
+ Version 2 of the Simple Network Management Protocol
+ (SNMP)", STD 62, RFC 3418, December 2002.
+
+ [ASN1] Information processing systems - Open Systems
+ Interconnection - Specification of Abstract Syntax
+ Notation One (ASN.1), International Organization for
+ Standardization. International Standard 8824, (December,
+ 1987).
+
+9.2. Informative References
+
+ [RFC1908] 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.
+
+ [RFC2089] Levi, D. and B. Wijnen, "Mapping SNMPv2 onto SNMPv1
+ within a bilingual SNMP agent", RFC 2089, January 1997.
+
+ [RFC2576] Frye, R., Levi, D., Routhier, S. and B. Wijnen,
+ "Coexistence between Version 1, Version 2, and Version 3
+ of the Internet-standard Network Management Framework",
+ RFC 2576, March 2000.
+
+ [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
+ "Introduction and Applicability Statements for Internet-
+ Standard Management Framework", RFC 3410, December 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 46]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+Appendix A. Change Log
+
+A.1. Changes From RFC 2576
+
+ Section numbers below refer to the old section numbers from RFC 2576.
+ Some section numbers have changed since RFC 2576.
+
+ - Added text to abstract about conversion of MIBs from SMIv1 to
+ SMIv2.
+
+ - Added note at end of section 1.3 that all discussion of SNMPv2 PDU
+ types and protocol operations applies to both SNMPv2c and SNMPv3.
+
+ - Added text at end of section 1.4 to clarify that there is no such
+ thing as 'SNMPv3 access to MIB data', as SNMPv3 just uses SNMPv2
+ PDU types and protocol operations.
+
+ - Moved section 1.4 to the beginning of section 4.
+
+ - Changed "MUST" to "SHOULD" in item (3) of the first list in
+ Section 2.1.1 to since unconstrained INTEGER is not actually
+ illegal in SMIv2.
+
+ - Changed "SHOULD" to "MUST" in item (13) of the first list in
+ Section 2.1.1 to clarify that collecting related objects into
+ groups is required when translating a MIB module from SMIv1 to
+ SMIv2.
+
+ - Re-organized bullets in section 2.1.1 to improve clarity.
+
+ - Changed "SHOULD" to "MUST" in items (1) and (2) of Section 2.3
+ since those updates are indeed required when translating a
+ capabilities statement from the language defined by RFC 1303 into
+ SMIv2.
+
+ - In the second bullet of the last part of Section 3 listing the
+ SNMPv2 notification parameters, clarified that the snmpTrapOID
+ parameter refers to the value portion (not the name portion) of
+ the second variable-binding, and changed the wording in the text
+ under bullet (1) of Section 3.2 from "the snmpTrapOID" to "the
+ snmpTrapOID value" to emphasize this point.
+
+ - In bullet (6) of Section 3.2 emphasized that the SNMPv2 variable-
+ bindings do not include sysUpTime.0 an snmpTrapOID.0.
+
+ - In Section 4.2 clarified that the 'Upstream Version' refers to the
+ version used between the command generator or notification
+ receiver and the proxy, and the 'Downstream Version' refers to the
+
+
+
+Frye, et al. Best Current Practice [Page 47]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ version used between the proxy and the command responder or
+ notification originator. RFC 2576 neglected to mention the
+ notification receiver and notification originator.
+
+ - In Section 4.1.2 added text noting that SNMPv1 access to MIB data
+ SHOULD NOT be used when processing SNMPv2c or SNMPv3 messages and
+ re-worded final paragraph to note that the sub-sections that
+ follow are concerned solely with command responders that use
+ SNMPv2 access to MIB data while processing an SNMPv1 request.
+
+ - Re-worded first bullet, section 4.2.1, to make it more readable.
+
+ - In Section 4.2.1 clarified that the error-index field must be set
+ to zero in a translated GetResponse-PDU with an error-status of
+ 'tooBig' and made explicit the rationale for retrying a
+ GetBulkRequest-PDU only once.
+
+ - Added text to the Deployment Hint in Section 4.2.2 to clarify that
+ different principals should be used for SNMPv1 requests and
+ SNMPv2/v3c requests if for SNMPv1 requests a principal for which
+ Counter64 objects are not-in-view is used.
+
+ - In Section 5.2.1 clarified that the securityName value and the
+ scopedPDU's contextSnmpEngineID and contextName values come from
+ the selected entry in the snmpCommunityTable. Also clarified how
+ maxSizeResponseScopedPDU is determined and that
+ securityStateReference must contain the community string of the
+ original request.
+
+ - Added Section 5.2.4 on Proxy Forwarding Of Requests.
+
+ - In Section 5.3 clarified that snmpTargetAddrTMask is to be ignored
+ whenever its use is not explicitly called for.
+
+ - Updated the LAST-UPDATED, CONTACT-INFO, and REVISION clauses and
+ added a copyright notice to the DESCRIPTION clause of the MIB
+ module's MODULE-IDENTITY invocation.
+
+ - Added text to DESCRIPTION of snmpCommunityName and
+ snmpTrapCommunity to clarify why the object has no size
+ restriction.
+
+ - Updated the description of snmpCommunityTransportTag to make it
+ consistent with the rest of the document.
+
+ - Updated the description of 'snmpTargetAddrMMS' to clarify that a
+ value of 0 means that the maximum message size is unknown.
+
+
+
+
+Frye, et al. Best Current Practice [Page 48]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ - Changed the name of 'snmpCommunityGroup' to
+ 'snmpCommunityTableGroup' in order to resolve a name conflict with
+ the SNMPv2-MIB.
+
+ - Added compliance statement to SNMP-COMMUNITY-MIB for full read-
+ create compliance.
+
+ - Divided references into Normative References and Informative
+ Reference and updated them to point to current documents.
+
+ - Inserted current year into all copyright notices.
+
+ - Corrected various typographical and grammatical errors.
+
+A.2. Changes Between RFC 1908 and RFC 2576
+
+ - 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 parameters 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 RFC 2089 the SNMPv2 to SNMPv1 mapping
+ within a multi-lingual SNMP Engine.
+
+
+
+
+Frye, et al. Best Current Practice [Page 49]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+ - 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.
+
+Editors' Addresses
+
+ Rob Frye
+ Vibrant Solutions
+ 2711 Prosperity Ave
+ Fairfax, Virginia 22031
+ U.S.A.
+
+ Phone: +1 703 270 2000
+ EMail: rfrye@vibrant-1.com
+
+ David B. Levi
+ Nortel Networks
+ 3505 Kesterwood Drive
+ Knoxville, TN 37918
+ U.S.A.
+
+ Phone: +1 865 686 0432
+ EMail: dlevi@nortelnetworks.com
+
+ Shawn A. Routhier
+ Wind River Systems, Inc.
+ 500 Wind River Way
+ Alameda, CA 94501
+ U.S.A.
+
+ Phone: + 1 510 749 2095
+ EMail: sar@epilogue.com
+
+ Bert Wijnen
+ Lucent Technologies
+ Schagen 33
+ 3461 GL Linschoten
+ Netherlands
+
+ Phone: +31 348 407 775
+ EMail: bwijnen@lucent.com
+
+
+
+
+
+Frye, et al. Best Current Practice [Page 50]
+
+RFC 3584 Coexistence between SNMP versions August 2003
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). 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 assignees.
+
+ 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. Best Current Practice [Page 51]
+