Internet Draft Coexistence between SNMP versions 7 Aug 1998 INTERNET-DRAFT Rob Frye MCI Communications Corp. David B. Levi SNMP Research, Inc. Bert Wijnen IBM T.J. Watson Research 7 Aug 1998 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Copyright Notice Copyright (C) The Internet Society (date). All Rights Reserved. SNMPv3 Working Group Expires February 1999 [Page 1] Internet Draft Coexistence between SNMP versions 7 Aug 1998 Abstract The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework [RFC2271], termed the SNMP version 3 framework (SNMPv3), version 2 of the Internet-standard Network Management Framework [RFC1901], termed the SNMP version 2 framework (SNMPv2), and the original Internet- standard Network Management Framework (SNMPv1) [RFC1157]. SNMPv3 Working Group Expires February 1999 [Page 2] Internet Draft Coexistence between SNMP versions 7 Aug 1998 Table Of Contents 1 Overview ..................................................... 4 1.1 SNMPv1 ..................................................... 4 1.2 SNMPv2 ..................................................... 5 1.3 SNMPv3 ..................................................... 5 2 SMI and Management Information Mappings ...................... 7 2.1 Object Definitions ......................................... 7 2.2 Trap Definitions ........................................... 9 2.3 Compliance Statements ...................................... 10 2.4 Capabilities Statements .................................... 10 3 SNMPv1 and SNMPv2 MIB Instrumentation ........................ 12 4 Translating Notifications Between SNMP Formats ............... 13 4.1 Translating SNMPv1 Format to SNMPv2 Format ................. 14 4.2 Translating SNMPv2 Format to SNMPv1 Format ................. 15 4.3 Notification Translation Failure ........................... 16 4.3.1 discussion about additional varbinds (agent_addr, com- munity) ................................................... 17 5 Approaches to Coexistence in a Multi-lingual Network ......... 18 5.1 Multi-lingual implementations .............................. 18 5.1.1 Command Generator ........................................ 18 5.1.2 Command Responder ........................................ 18 5.1.3 Notification Originator .................................. 19 5.1.4 Notification Receiver .................................... 19 5.2 Proxy Implementations ...................................... 19 6 Multi-Lingual Command Responder Behaviour .................... 21 6.1 Mapping SMIv2 into SMIv1 ................................... 21 6.2 Mapping SNMPv2 Exceptions .................................. 21 6.2.1 Mapping nosuchObject and noSuchInstance .................. 22 6.2.2 Mapping endOfMibView ..................................... 22 6.3 Processing An SNMPv1 GetRequest ............................ 23 6.4 Processing An SNMPv1 GetNextRequest ........................ 24 7 Error Status Mappings ........................................ 26 8 Message Processing Models and Security Models ................ 27 8.1 Mappings ................................................... 27 8.2 Elements Of Procedure ...................................... 27 8.2.1 Processing An Incoming Request ........................... 28 8.2.2 Processing An Outgoing Response .......................... 28 8.2.3 Processing An Incoming Notification ...................... 28 8.2.4 Processing An Outgoing Notification ...................... 28 8.3 Community MIB .............................................. 28 9 Intellectual Property ........................................ 35 10 Acknowledgments ............................................. 36 11 Security Considerations ..................................... 38 12 References .................................................. 39 13 Editor's Address ............................................ 41 A. Full Copyright Statement .................................... 42 SNMPv3 Working Group Expires February 1999 [Page 3] Internet Draft Coexistence between SNMP versions 7 Aug 1998 1. Overview The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework [RFC2271], termed the SNMP version 3 framework (SNMPv3), version 2 of the Internet-standard Network Management Framework [RFC1901], termed the SNMP version 2 framework (SNMPv2), and the original Internet- standard Network Management Framework (SNMPv1) [RFC1157]. There are five 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 notifications between SMIv1 and SMIv2 formats is documented in section 4. - Approaches to coexistence between SNMPv1, SNMPv2, and SNMPv3 entities in a multi-lingual network is documented in section 5. - Processing of protocol operations in multi-lingual implementations is documented in section 6. - The Community-Based Security Model, which provides mechanisms for adapting SNMPv1 and SNMPv2 into the SNMPv3 view-based access control, is documented in section 8. 1.1. SNMPv1 SNMPv1 is defined by these three documents: - STD 16, RFC 1155 [RFC1155] which defines the Structure of Management Information (SMI), 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 SMI. - STD 15, RFC 1157 [RFC1157] which defines the Simple Network Management Protocol (SNMP), the protocol used for network access to managed objects. - (NOTE: Rob had suggested adding rfcs 1213, 2011, 2012, 2013, 1215. Which, if any, of these should we add?) SNMPv3 Working Group Expires February 1999 [Page 4] Internet Draft Coexistence between SNMP versions 7 Aug 1998 1.2. SNMPv2 SNMPv2 is defined by these six documents: - RFC 1902 which defines Version 2 of the Structure of Management Information (SMI) [RFC1902]. - RFC 1903 which defines common MIB "Textual Conventions" [RFC1903]. - RFC 1904 which defines Conformance Statements and requirements for defining agent and manager capabilities [RFC1904]. - RFC 1905 which defines the Protocol Operations used in processing [RFC1905]. - RFC 1906 which defines the Transport Mappings used "on the wire" [RFC1906]. - RFC 1907 which defines the basic Management Information Base upon which other MIBs can be built [RFC1907]. In addition, the following three documents augment the definition of SNMPv2: - RFC 1901 is an Experimental definition for using SNMPv2 format PDUs within a community-based message format. This is referred to throughout this document as SNMPv2c [RFC1901]. - RFC 2011 defines the IP MIB using SMIv2. 1.3. SNMPv3 SNMPv3 is defined by the these five documents: - RFC 2271 which defines the v3 Architecture for Describing SNMP Management Frameworks [RFC2271]. - RFC 2272 which defines Message Processing and Dispatching [RFC2272]. - RFC 2273 which defines various SNMPv3 Applications [RFC2273]. - RFC 2274 which defines the User-based Security Model (USM), providing for both Authenticated and Private (encrypted) SNMP transactions [RFC2274]. SNMPv3 Working Group Expires February 1999 [Page 5] Internet Draft Coexistence between SNMP versions 7 Aug 1998 - RFC 2275 which defines the View-based Access Control Model (VACM), providing the ability to limit access to different MIB objects on a per-user basis [RFC2275]. SNMPv3 also uses the SNMPv2 definitions of RFCs 1902 through 1907 described above. SNMPv3 Working Group Expires February 1999 [Page 6] Internet Draft Coexistence between SNMP versions 7 Aug 1998 2. SMI and Management Information Mappings The SNMPv2 approach towards describing collections of managed objects is nearly a proper superset of the approach defined in the Internet- standard SNMPv1 Network Management Framework. For example, both approaches use ASN.1 [10] as the basis for a formal descriptive notation. Indeed, one might note that the SNMPv2 approach largely codifies the existing practice for defining MIB modules, based on extensive experience with the SNMPv1 framework. The following sections consider the three areas: MIB modules, compliance statements, and capabilities statements. MIB modules defined using the SNMPv1 framework may continue to be used with the SNMPv2 protocol. However, for the MIB modules to conform to the SNMPv2 framework, the following changes are required: 2.1. Object Definitions In general, conversion of a MIB module does not require the deprecation of the objects contained therein. Only if the semantics of an object truly changes should deprecation be performed. (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 descriptor which contains the hyphen character, the hyphen character is removed. (4) For any label for a named-number enumeration which contains the hyphen character, the hyphen character is removed. (5) For any object with an integer-valued SYNTAX clause, in which the corresponding INTEGER does not have a range restriction (i.e., the INTEGER has neither a defined set of named-number enumerations nor an assignment of lower- and upper-bounds on its value), the object must have the value of its SYNTAX clause changed to Integer32. (6) For any object with a SYNTAX clause value of an enumerated INTEGER, the hyphen character is removed from any named-number labels which contain the hyphen character. SNMPv3 Working Group Expires February 1999 [Page 7] Internet Draft Coexistence between SNMP versions 7 Aug 1998 (7) For any object with a SYNTAX clause value of Counter, the object must have the value of its SYNTAX clause changed to Counter32. (8) For any object with a SYNTAX clause value of Gauge, the object must have the value of its SYNTAX clause changed to Gauge32. (9) For all objects, the ACCESS clause must be replaced by a MAX-ACCESS clause. The value of the MAX-ACCESS clause is the same as that of 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, will 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 is "read-write", and the DESCRIPTION clause notes that reading this object will result implementation-specific results. (10) For all objects, if the value of the STATUS clause is "mandatory", the value must be replaced with "current". (11) For all objects, if the value of the STATUS clause is "optional", the value must be replaced with "obsolete". (12) For any object not containing a DESCRIPTION clause, the object must have a DESCRIPTION clause defined. (13) 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. (14) For any object with an INDEX clause that references an object with a syntax of NetworkAddress, the value of the STATUS clause of both objects is changed to "obsolete". (15) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER value which is expressed as a collection of sub-identifiers, change the value to reference a single ASN.1 identifier. This may require defining a series of new objects in order to define the single ASN.1 identifier. Other changes are desirable, but not necessary: (1) Creation and deletion of conceptual rows is inconsistent using the SNMPv1 framework. The SNMPv2 and SNMPv3 frameworks correct 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 it may be worthwhile to deprecate the SNMPv3 Working Group Expires February 1999 [Page 8] Internet Draft Coexistence between SNMP versions 7 Aug 1998 objects relating to those tables and replace them with objects defined using the new approach. (2) For any object with a string-valued SYNTAX clause, in which the corresponding OCTET STRING does not have a size restriction (i.e., the OCTET STRING has no assignment of lower- and upper-bounds on its length), it is recommended that the bounds for the size of the object be defined. (3) For all textual conventions informally defined in the MIB module, it is recommended that those conventions using the TEXTUAL- CONVENTION macro be redefined. Such a change would not necessitate deprecating objects previously defined using an informal textual convention. (4) For any object which represents a measurement in some kind of units, it is recommended that a UNITS clause be added to the definition of that object. (5) For any conceptual row which is an extension of another conceptual row, i.e., for which subordinate columnar objects both exist and are identified via the same semantics as the other conceptual row, it is recommended that an AUGMENTS clause be used in place of the INDEX clause for the object corresponding to the conceptual row which is an extension. Finally, when encountering common errors in SNMPv1 MIB modules: (1) For any non-columnar object that is instanced as if it were immediately subordinate to a conceptual row, the value of the STATUS clause of that object is changed to "obsolete". (2) For any conceptual row object that is not contained immediately subordinate to a conceptual table, the value of the STATUS clause of that object (and all subordinate objects) is changed to "obsolete". 2.2. Trap Definitions If a MIB module is changed to conform to the SNMPv2 framework, then each occurrence of the TRAP-TYPE macro must be changed to a corresponding invocation of the NOTIFICATION-TYPE macro: (1) The IMPORTS statement must not reference RFC-1215, and should reference SNMPv2-SMI instead. SNMPv3 Working Group Expires February 1999 [Page 9] Internet Draft Coexistence between SNMP versions 7 Aug 1998 (2) The ENTERPRISE clause must be removed. (3) The VARIABLES clause must be renamed to the OBJECTS clause. (4) The STATUS clause must be added, with a value of 'current'. (5) The value of an invocation of the NOTIFICATION-TYPE macro is an 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 is 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. (6) The DESCRIPTION clause must be added, if not already present. (7) One or more NOTIFICATION-GROUPs should be defined, and related notifications should be collected into those groups. 2.3. Compliance Statements For those information modules which are "standard", a corresponding invocation of the MODULE-COMPLIANCE macro 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 must be removed. Typically this editing can occur when the information module undergoes review. 2.4. Capabilities Statements In the SNMPv1 framework, the informational document [11] uses the MODULE-CONFORMANCE macro to describe an agent's capabilities with respect to one or more MIB modules. Converting such a description for use with the SNMPv2 framework requires these changes: (1) Use the macro name AGENT-CAPABILITIES instead of MODULE- CONFORMANCE. (2) The STATUS clause must be added, with a value of 'current'. (3) For all occurrences of the CREATION-REQUIRES clause, note the slight change in semantics, and omit this clause if appropriate. SNMPv3 Working Group Expires February 1999 [Page 10] Internet Draft Coexistence between SNMP versions 7 Aug 1998 In order to ease the coexistence between SNMPv1, SNMPv2, and SNMPv3, object groups defined in an SMIv1 compliant MIB module may be referenced by the INCLUDES clause of an invocation of the AGENT- CAPABILITIES macro: upon encountering a reference to an OBJECT IDENTIFIER subtree defined in an SNMPv1 MIB module, all leaf objects which are subordinate to the subtree and have a STATUS clause value of mandatory are deemed to be INCLUDEd. (Note that this method is ambiguous when different revisions of a SNMPv1 MIB have different sets of mandatory objects under the same subtree; in such cases, the only solution is to rewrite the MIB using the SMIv2 in order to define the object groups unambiguously.) SNMPv3 Working Group Expires February 1999 [Page 11] Internet Draft Coexistence between SNMP versions 7 Aug 1998 3. SNMPv1 and SNMPv2 MIB Instrumentation In several places, this document refers to SNMPv1 MIB Instrumentation and SNMPv2 MIB Instrumentation. This refers to the part of an SNMP agent which actually implements MIB objects, and which actually initiates generation of notifications. Differences between the two types of MIB instrumentation are: - Error-status values generated. - Generation of exception codes. - Use of the Counter64 data type. - The format of parameters provided when a notification is generated. SNMPv1 MIB instrumentation will generate SNMPv1 error-status values, will never generate exception codes nor use the Counter64 data type, and will provide SNMPv1 format parameters for generating notifications. SNMPv2 MIB instrumentation will generate SNMPv2 error-status values, will generate exception codes, will use the Counter64 data type, and will provide SNMPv2 format parameters for generating notifications. SNMPv3 Working Group Expires February 1999 [Page 12] Internet Draft Coexistence between SNMP versions 7 Aug 1998 4. Translating Notifications Between SNMP Formats This section describes how data contained in a notification is translated between the SNMPv1 format and the SNMPv2 format. There are two parts to the format of a notification, the SMI version used to define the notification, and the format of parameters used to represent a generated notification. The SMI version used to define a notification will generally determine the format of parameters used when a notification is generated by MIB instrumentation. There are two formats for parameters, those used in an SNMPv1 notification, and those used in an SNMPv2 notification. These set of information are refered to in this section as 'notification parameters format'. There are two formats, the SNMPv1 notification parameter format and the SNMPv2 notification parameter format. There are two situations where notification parameters must be translated between SNMP formats: - When instrumentation in an entity generates a set of notification parameters using one SNMP format, and the configuration of the entity indicates that the notification must be sent using a protocol version that requires notification parameters in the other SNMP format. - When a proxy receives a notification in one SNMP format, and must forward the notification using a protocol version that requires a different SNMP format. 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 format 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 value (OBJECT IDENTIFIER). - An agent-addr value (NetworkAddress). - A generic-trap value (INTEGER). - A specific-trap value (INTEGER). SNMPv3 Working Group Expires February 1999 [Page 13] Internet Draft Coexistence between SNMP versions 7 Aug 1998 - A time-stamp value (TimeTicks). - A list of variable-bindings (VarBindList). SNMPv2 notification parameters consist of: - A sysUpTime value (TimeTicks). This appears in the first variable-binding in an SNMPv2 notification. - An snmpTrapOID value (OBJECT IDENTIFIER). This appears in the second variable-binding in an SNMPv2 notification. - A list of variable-bindings (VarBindList). This refers to all but the first two variable-bindings in an SNMPv2 notification. 4.1. Translating SNMPv1 Format to SNMPv2 Format The following procedure describes how to translate SNMPv1 notification parameters into SNMPv2 notification parameters: (1) The SNMPv2 sysUpTime value is taken directly from the SNMPv1 time- stamp value. (2) If the SNMPv1 generic-trap value is 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID value is the concatentation of the SNMPv1 enterprise value and two additional sub-identifiers, '0', and the SNMPv1 specific-trap value. (3) If the SNMPv1 generic-trap value is not 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID value is the corresponding trap as defined in [RFC1907]. (4) The SNMPv2 variable-bindings is the SNMPv1 variable-bindings with a single variable-binding appended. The name portion of this variable binding contains snmpTrapEnterprise.0 [RFC1907], and the value is the SNMPv1 enterprise value. (5) The value of the agent-addr field is lost when converting notification parameters from SNMPv1 to SNMPv2. SNMPv3 Working Group Expires February 1999 [Page 14] Internet Draft Coexistence between SNMP versions 7 Aug 1998 4.2. Translating SNMPv2 Format to SNMPv1 Format The following procedure describes how to translate SNMPv2 notification parameters into SNMPv1 notification parameters: (1) The SNMPv1 enterprise value is determined as follows: - If the SNMPv2 snmpTrapOID value is one of the standard traps as defined in [RFC1907], then the SNMPv1 enterprise value is set to the value of the variable-binding in the SNMPv2 variable-bindings whose name is snmpTrapEnterprise.0 if that variable-binding exists. If it does not exist, the SNMPv1 enterprise value is set to the value 'snmpTraps' as defined in RFC1907 [RFC1907]. - If the SNMPv2 snmpTrapOID value is not one of the standard traps as defined in [RFC1907], then the SNMPv1 enterprise value is set to the SNMPv2 snmpTrapOID value as follows: - If the next-to-last sub-identifier of the snmpTrapOID is zero, then the SMIv1 enterprise is the SMIv2 snmpTrapOID with the last 2 sub-identifiers removed, otherwise - If the next-to-last sub-identifier of the snmpTrapOID is non-zero, then the SMIv1 enterprise is the SMIv2 snmpTrapOID with the last sub-identifier removed. (2) The SNMPv1 agent-addr value is 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 UDP, the SNMPv1 agent-addr value is 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 value is set to 0.0.0.0. - If the translation occurs within a proxy application, the proxy must attempt to determine the original source of the notification. If this source was an IP or UDP address, that address is used for the SNMPv1 agent-addr value. Otherwise, the SNMPv1 agent-addr value is set to 0.0.0.0. (3) If the SNMPv2 snmpTrapOID value is one of the standard traps as defined in [RFC1907], the SNMPv1 generic-trap value is set as follows: SNMPv3 Working Group Expires February 1999 [Page 15] Internet Draft Coexistence between SNMP versions 7 Aug 1998 value of snmpTrapOID.0 generic-trap =============================== ============ 1.3.6.1.6.3.1.1.5.1 (coldStart) 0 1.3.6.1.6.3.1.1.5.2 (warmStart) 1 1.3.6.1.6.3.1.1.5.3 (linkDown) 2 1.3.6.1.6.3.1.1.5.4 (linkUp) 3 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5 Otherwise, the SNMPv1 generic-trap value is set to 6. (4) If the SNMPv2 snmpTrapOID value is one of the standard traps as defined in [RFC1907], the SNMPv1 specific-trap value is set to zero. Otherwise, the SNMPv1 specific-trap value is set to the last sub-identifier of the SNMPv2 snmpTrapOID value. (5) The SNMPv1 time-stamp value is taken directly from the SNMPv2 sysUpTime value. (6) The SNMPv1 variable-bindings is the SNMPv2 variable-bindings with the following exceptions: - If a variable-binding whose name is snmpTrapEnterprise.0 exists in the SNMPv2 variable-bindings, that variable-binding is removed. - If a variable-binding whose type is Counter64 exists in the SNMPv2 variable-bindings, the translation fails. The consequences of a failed translation depend on the situation in which the translation is being performed. 4.3. Notification Translation Failure If translation of a notification from SNMPv2 to SNMPv1 fails due to the existence of a variable-binding with a type of Counter64, the result is as follows: - If the translation is being performed within a notification originator in order to send an SNMPv1 Trap-PDU, the Trap-PDU is simply not sent. The notification may still be sent using other SNMP versions. - If the translation is being performed within a proxy in order to forward the notification as an SNMPv1 Trap-PDU, the Trap- PDU is not sent. The notification may still be forwarded SNMPv3 Working Group Expires February 1999 [Page 16] Internet Draft Coexistence between SNMP versions 7 Aug 1998 using other SNMP versions. 4.3.1. discussion about additional varbinds (agent_addr, community) SNMPv3 Working Group Expires February 1999 [Page 17] Internet Draft Coexistence between SNMP versions 7 Aug 1998 5. 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 implentation 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. 5.1. Multi-lingual implementations This approach requires an entity to support multiple SNMP message formats. Typically this means supporting SNMPv1, SNMPv2c, and SNMPv3 message formats. The behaviour of various types of SNMPv3 applications which support multiple message formats is described in the following sections. This approach allows entities which support multiple SNMP message formats to coexist with and communicate with entities which support only a single SNMP message format. 5.1.1. Command Generator A command generator must select an appropriate message format when sending requests to another entity. One way to achieve this is to consult a local database to select the appropriate message format. In addition, a command generator should 'downgrade' GetBulk requests to GetNext requests when selecting SNMPv1 as the message format for an outgoing request. 5.1.2. Command Responder A command responder must be able to deal with MIB instrumentation that is written using both the SNMPv1 and SNMPv2. There are three aspects to dealing with this. A command responder must: SNMPv3 Working Group Expires February 1999 [Page 18] Internet Draft Coexistence between SNMP versions 7 Aug 1998 - Deal correctly with SNMPv2 MIB instrumentation that returns a Counter64 value while processing an SNMPv1 message, - Deal correctly with SNMPv2 instrumentation that returns one of the three exception values while processing an SNMPv1 message, - Map SNMPv2 error codes returned from SNMPv2 instrumentation into SNMPv1 error code when processing an SNMPv1 message, and Note that SNMPv1 error codes can be used without any change when processing SNMPv2c or SNMPv3 messages. Details about how a command responder handles these requirements are provided in section 6. 5.1.3. Notification Originator A notification originator must be able to translate notifications between SNMPv1 and SNMPv2 formats in order to send a notification using a particular SNMP message format. If instrumentation presents a notification in the SMIv1 format and configuration information specifies that notifications be sent using SNMPv2c or SNMPv3, the notification must be translated to the SNMPv2 format. Likewise, if instrumentation presents a notification in the SNMPv2 format and configuration information specifies that notifications be sent using SNMPv1, the notification must be translated to the SNMPv1 format. 5.1.4. Notification Receiver There are no special requirements of a notification receiver. However, an implementation may find it useful to allow a higher level application to request which SNMP format should be used when delivering notifications to that higher level application. The notification receiver would then translate between SNMP formats when required in order to present a notification using the desired format. 5.2. Proxy Implementations A proxy implementation may be used to enable communication between entities which support different SNMP message formats. This is accomplished in a proxy forwarding application by performing SNMPv3 Working Group Expires February 1999 [Page 19] Internet Draft Coexistence between SNMP versions 7 Aug 1998 translations on a PDU in the following situations: - If a GetBulkRequest-PDU is received and must be forwarded using the SNMPv1 message format, the proxy forwarder sets the non-repeaters and max-repetitions fields to 0, and sets the tag of the PDU to GetNextRequest-PDU. - If a GetResponse-PDU is received whose error-status field has a value of 'tooBig', and the message will be forwarded using the SNMPv2c or SNMPv3 message format, the proxy forwarder will remove the contents of the variable-bindings field before forwarding the response. - If a Trap-PDU is received, and will be forwarded using the SNMPv2c or SNMPv3 message format, the proxy will apply the translation rules described in section 4, and will forward the notification as an SNMPv2-Trap-PDU. - If an SNMPv2-Trap-PDU is received, and will be forwarded using the SNMPv1 message format, the proxy will apply the translation rules described in section 4, and will forward the notification as a Trap-PDU. - If an InformRequest-PDU is received, any configuration information indicating that it would be forwarded using the SNMPv1 message format, is ignored. An InformRequest-PDU can only be forwarded using the SNMPv2c or SNMPv3 message format. SNMPv3 Working Group Expires February 1999 [Page 20] Internet Draft Coexistence between SNMP versions 7 Aug 1998 6. Multi-Lingual Command Responder Behaviour The following sections describe the behaviour of a command responder application which supports multiple SNMP message formats, and which has access to some combination of SNMPv1 and SNMPv2 MIB instrumentation. 6.1. Mapping SMIv2 into SMIv1 The SMIv2 [RFC1902] 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 should make sure that they never return a variable binding containing a Counter64 value in a response to a request that was received using the SNMPv1 message format. Multi-lingual command responders should take the approach that object instances whose type is Counter64 are implicitly excluded from view when processing an SNMPv1 message. So: - On an SNMPv1 GET request, we return an error-status of noSuchName and the error-index is set to the variable binding that causes this error. - On an SNMPv1 GETNEXT request, we skip the object instance and fetch the next object instance that follows the one with a syntax of Counter64. - Any SET request that has a variable binding with a Counter64 value must have come from a SNMPv2 manager, and so it should not cause a problem. If we do receive a Counter64 value in an SNMPv1 SET packet, it should result in an ASN.1 parse error since Counter64 is not valid in the SNMPv1 protocol. When an ASN.1 parse error occurs, the counter snmpInASNParseErrs is incremented and no response is returned. 6.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 SNMPv3 Working Group Expires February 1999 [Page 21] Internet Draft Coexistence between SNMP versions 7 Aug 1998 management information, and can only return an error-status and error-index value. When an SNMPv1 request is received, a command responder must check any variable bindings returned from SNMPv2 compliant instrumentation for exception values, and convert these exception values into SNMPv1 error codes. The type of exception that can be returned from instrumentation 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. 6.2.1. Mapping nosuchObject and noSuchInstance A noSuchObject or noSuchInstance exception generated by SNMPv2 compliant instrumentation 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 should be set to noSuchName. Also, the error-index field is set to the index of the variable binding for which an exception occurred, and the variable binding list from the original request is returned with the response PDU. Note that when a response contains multiple exceptions, it is an implementation choice as to which variable binding the error-index should reference. 6.2.2. Mapping endOfMibView When SNMPv2 compliant instrumentation 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 SNMPv3 Working Group Expires February 1999 [Page 22] Internet Draft Coexistence between SNMP versions 7 Aug 1998 in a noSuchName error, and so the error-status field of the response PDU should be set to noSuchName. Also, the error- index field is set to the index of the variable binding for which an exception occurred, and the variable binding list from the original request is returned with the response PDU. Note that when a response contains multiple exceptions, it is an implementation choice as to which variable binding the error-index should reference. 6.3. Processing An SNMPv1 GetRequest When processing an SNMPv1 GetRequest, the following procedures should be followed when calling SNMPv2 MIB instrumentation. When such instrumentation returns response data using SNMPv2 syntax and error-status values, then: (1) If the error-status is anything other than noError, - The error status is translated to an SNMPv1 error-status using the table in section 7, "Mapping SNMPv2 error-status into SNMPv1 error-status" - The error-index is 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 is made exactly the same as the variable binding list that was received in the original request. (2) If the error-status is noError, then find any variable binding that contains an SNMPv2 exception (noSuchObject or noSuchInstance) or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64). (Note that if there are more than one, the agent may choose any such variable binding.) If there are any such variable bindings, then for the one chosen: - Set the error-status to noSuchName - Set the error-index to the position (in the variable binding list of the original request) of the variable binding that returned such an SNMPv2 exception or syntax. SNMPv3 Working Group Expires February 1999 [Page 23] Internet Draft Coexistence between SNMP versions 7 Aug 1998 - Make the variable binding list of the response PDU exactly the same as the variable binding list that was received in the original request. (3) If there are no such variable bindings, then: - Set the error-status to noError - Set the error-index to zero - Compose the variable binding list of the response, using the data as it is returned by the instrumentation code. 6.4. Processing An SNMPv1 GetNextRequest When processing an SNMPv1 GetNextRequest, the following procedures should be followed when SNMPv2 MIB instrumentation is called as part of processing the request. There may be repetitive calls to (possibly different pieces of) instrumentation code 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 from SNMPv2 instrumentation. Data returned from SNMPv1 instrumentation may be treated in the normal manner for an SNMPv1 request. First, if the instrumentation returns an error-status of anything other than noError: (1) The error status is translated to an SNMPv1 error-status using the table in section 7, "Mapping SNMPv2 error-status into SNMPv1 error-status" (2) The error-index is set to the position (in the original request) of the variable binding that caused the error-status. (3) The variable binding list of the response PDU is made exactly the same as the variable binding list that was received in the original request. Otherwise, if the instrumentation returns an error-status of noError: (1) If there are any variable bindings containing an SNMPv2 syntax of Counter64, then consider these variable bindings to be not in view and repeat the call to the instrumentation code as often as needed until a value other than Counter64 is returned. SNMPv3 Working Group Expires February 1999 [Page 24] Internet Draft Coexistence between SNMP versions 7 Aug 1998 (2) Find any variable binding that contains an SNMPv2 exception endOfMibView. (Note that if there are more than one, the agent may choose any such variable binding.) If there are any such variable bindings, then for the one chosen: - Set the error-status to noSuchName - Set the error-index to the position (in the variable binding list of the original request) of the variable binding that returned such an SNMPv2 exception. - Make the variable binding list of the response PDU exactly the same as the variable binding list that was received in the original request. (3) If there are no such variable bindings, then: - Set the error-status to noError - Set the error-index to zero - Compose the variable binding list of the response, using the data as it is returned by the instrumentation code. SNMPv3 Working Group Expires February 1999 [Page 25] Internet Draft Coexistence between SNMP versions 7 Aug 1998 7. Error Status Mappings The following table shows the mappings of SNMPv2 error-status values into SNMPv1 error-status values. SNMPv2 error-status SNMPv1 error-status =================== =================== noError noError tooBig tooBig noSuchName noSuchName badValue badValue readOnly readOnly 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 SNMPv3 Working Group Expires February 1999 [Page 26] Internet Draft Coexistence between SNMP versions 7 Aug 1998 8. Message Processing Models and Security Models In order to adapt SNMPv1 and SNMPv2c into the SNMPv3 architecture, four additional models must be defined: - The SNMPv1 Message Processing Model - The SNMPv2c Message Processing Model - The SNMPv1 Community-Based Security 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. 8.1. Mappings The SNMPv1 and SNMPv2c Message Processing Models and Security Models require mappings between parameters used in SNMPv1 and SNMPv2c messages, and those use in SNMPv3 messages. The parameters which must be mapped consist of the SNMPv1 and SNMPv2c community name, and the SNMPv3 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. 8.2. Elements Of Procedure The following sections describe the procedures for processing various types of SNMPv1 and SNMPv2c messages. SNMPv3 Working Group Expires February 1999 [Page 27] Internet Draft Coexistence between SNMP versions 7 Aug 1998 8.2.1. Processing An Incoming Request 8.2.2. Processing An Outgoing Response 8.2.3. Processing An Incoming Notification 8.2.4. Processing An Outgoing Notification 8.3. Community MIB SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, UInteger32 FROM SNMPv2-SMI RowStatus, TestAndIncr, StorageType FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB SnmpTagValue FROM SNMP-TARGET-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; snmpCommunityMIB MODULE-IDENTITY LAST-UPDATED "9805110000Z" -- 11 May 1998, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@tis.com Subscribe: majordomo@tis.com In msg body: subscribe snmpv3 Chair: Russ Mundy Trusted Information Systems postal: 3060 Washington Rd Glenwood MD 21738 USA email: mundy@tis.com phone: +1-301-854-6889 SNMPv3 Working Group Expires February 1999 [Page 28] Internet Draft Coexistence between SNMP versions 7 Aug 1998 Co-editor: Rob Frye MCI Communications Corp. Postal: 2100 Reston Parkway, Suite 600 Reston, VA 20191 USA E-mail: Rob.Frye@mci.com Phone: +1 703 715 7225 Co-editor: David B. Levi SNMP Research, Inc. Postal: 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 E-mail: levi@snmp.com Phone: +1 423 573 1434 Co-editor: Bert Wijnen IBM T. J. Watson Research postal: Schagen 33 3461 GL Linschoten Netherlands email: wijnen@vnet.ibm.com phone: +31-348-432-794 " DESCRIPTION "This MIB module defines objects to help support coexistence between SNMPv1, SNMPv2, and SNMPv3." ::= { snmpModules xxx } -- get assignment from IANA -- 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)." SNMPv3 Working Group Expires February 1999 [Page 29] Internet Draft Coexistence between SNMP versions 7 Aug 1998 ::= { snmpCommunityMIBObjects 1 } snmpCommunityEntry OBJECT-TYPE SYNTAX SnmpCommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular community string." INDEX { snmpCommunityIndex } ::= { snmpCommunityTable 1 } SnmpCommunityEntry ::= SEQUENCE { snmpCommunityIndex Integer32, snmpCommunityName OCTET STRING, snmpCommunitySecurityName SnmpAdminString, snmpCommunityContextEngineID SnmpEngineID, snmpCommunityContextName SnmpAdminString, snmpCommunityTransportTag SnmpTagValue, snmpCommunityStorageType StorageType, snmpCommunityStatus RowStatus } snmpCommunityIndex OBJECT-TYPE SYNTAX Integer32 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 (SIZE(1..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "The community string for which a row in this table represents a configuration." ::= { snmpCommunityEntry 2 } snmpCommunitySecurityName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A human readable string representing the corresponding value of snmpCommunityName in a Security Model independent format." SNMPv3 Working Group Expires February 1999 [Page 30] Internet Draft Coexistence between SNMP versions 7 Aug 1998 ::= { snmpCommunityEntry 3 } snmpCommunityContextEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-create STATUS current DESCRIPTION "The contextEngineID indicating the location of the context in which management information is accessed when using the community string specified by the corresponding instance of snmpCommunityName. The default value is the snmpEngineID of the entity in which this object is instantiated." ::= { snmpCommunityEntry 4 } snmpCommunityContextName OBJECT-TYPE SYNTAX SnmpAdminString 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 } -- Comments on TransportTag -- based on this tag we can limit the use of an entry to a defined -- set of transport end-points. Maybe we want to augemnt the -- snmpTargetAddrTable to also contain a snmpTargetAddrTMask -- of type TAddress which we can use as a mask. -- Opinions are welcome. snmpCommunityTransportTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies a set of transport endpoints from which an agent will accept management requests. If a management request containing this community is received on a transport endpoint other than the transport endpoints identified by this object, the request is deemed unauthentic. The transports identified by this object are specified SNMPv3 Working Group Expires February 1999 [Page 31] Internet Draft Coexistence between SNMP versions 7 Aug 1998 in the snmpTargteAddrTable. Entries in that table whose snmpTargetAddrTagList contains this tag value are identified. If the value of this object has zero-length, transport endpoints are not checked when authenticating messages containing this community string." DEFVAL { ''H } -- the empty string ::= { snmpCommunityEntry 6 } snmpCommunityStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the snmpCommunityTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar object in the row." ::= { snmpCommunityEntry 7 } snmpCommunityStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the snmpCommunityTable. An entry in this table is not qualified for activation until instances of all corresponding columns have been initialized, either through default values, or through Set operations. The snmpCommunityName and snmpCommunitySecurityName objects must be explicitly set." ::= { snmpCommunityEntry 8 } -- Conformance Information ******************************************* snmpCommunityMIBCompliances OBJECT IDENTIFIER ::= { snmpCommunityMIBConformance 1 } snmpCommunityMIBGroups OBJECT IDENTIFIER ::= { snmpCommunityMIBConformance 2 } -- Compliance statements snmpCommunityMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION SNMPv3 Working Group Expires February 1999 [Page 32] Internet Draft Coexistence between SNMP versions 7 Aug 1998 "The compliance statement for SNMP engines which implement the SNMP-COMMUNITY-MIB." MODULE -- this module MANDATORY-GROUPS { snmpCommunityGroup } OBJECT snmpCommunityName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunitySecurityName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunitySecurityLevel MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunityContextEngineID MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunityContextName MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT snmpCommunityTransportLabel 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." ::= { usmMIBCompliances 1 } snmpCommunityGroup OBJECT-GROUP OBJECTS { snmpCommunityIndex, snmpCommunityName, snmpCommunitySecurityName, snmpCommunityContextEngineID, snmpCommunityContextName, SNMPv3 Working Group Expires February 1999 [Page 33] Internet Draft Coexistence between SNMP versions 7 Aug 1998 snmpCommunityTransportLabel, snmpCommunityStorageType, snmpCommunityStatus } STATUS current DESCRIPTION "A collection of objects providing for configuration of community strings for SNMPv1 or SNMPv2c usage." ::= { snmpCommunityMIBGroups 1 } END SNMPv3 Working Group Expires February 1999 [Page 34] Internet Draft Coexistence between SNMP versions 7 Aug 1998 9. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. SNMPv3 Working Group Expires February 1999 [Page 35] Internet Draft Coexistence between SNMP versions 7 Aug 1998 10. Acknowledgments This document is the result of the efforts of the SNMPv3 Working Group. Some special thanks are in order to the following SNMPv3 WG members: Dave Battle (SNMP Research, Inc.) Uri Blumenthal (IBM T.J. Watson Research Center) Jeff Case (SNMP Research, Inc.) John Curran (BBN) T. Max Devlin (Hi-TECH Connections) John Flick (Hewlett Packard) David Harrington (Cabletron Systems Inc.) N.C. Hien (IBM T.J. Watson Research Center) Dave Levi (SNMP Research, Inc.) Louis A Mamakos (UUNET Technologies Inc.) Paul Meyer (Secure Computing Corporation) Keith McCloghrie (Cisco Systems) Russ Mundy (Trusted Information Systems, Inc.) Bob Natale (ACE*COMM Corporation) Mike O'Dell (UUNET Technologies Inc.) Dave Perkins (DeskTalk) Peter Polkinghorne (Brunel University) Randy Presuhn (BMC Software, Inc.) David Reid (SNMP Research, Inc.) Shawn Routhier (Epilogue) Juergen Schoenwaelder (TU Braunschweig) Bob Stewart (Cisco Systems) Bert Wijnen (IBM T.J. Watson Research Center) The document is based on recommendations of the IETF Security and Administrative Framework Evolution for SNMP Advisory Team. Members of that Advisory Team were: David Harrington (Cabletron Systems Inc.) Jeff Johnson (Cisco Systems) David Levi (SNMP Research Inc.) John Linn (Openvision) Russ Mundy (Trusted Information Systems) chair Shawn Routhier (Epilogue) Glenn Waters (Nortel) Bert Wijnen (IBM T. J. Watson Research Center) As recommended by the Advisory Team and the SNMPv3 Working Group Charter, the design incorporates as much as practical from previous RFCs and drafts. As a result, special thanks are due to the authors of previous designs known as SNMPv2u and SNMPv2*: SNMPv3 Working Group Expires February 1999 [Page 36] Internet Draft Coexistence between SNMP versions 7 Aug 1998 Jeff Case (SNMP Research, Inc.) David Harrington (Cabletron Systems Inc.) David Levi (SNMP Research, Inc.) Keith McCloghrie (Cisco Systems) Brian O'Keefe (Hewlett Packard) Marshall T. Rose (Dover Beach Consulting) Jon Saperia (BGS Systems Inc.) Steve Waldbusser (International Network Services) Glenn W. Waters (Bell-Northern Research Ltd.) SNMPv3 Working Group Expires February 1999 [Page 37] Internet Draft Coexistence between SNMP versions 7 Aug 1998 11. 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. SNMPv3 Working Group Expires February 1999 [Page 38] Internet Draft Coexistence between SNMP versions 7 Aug 1998 12. References [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets"", STD16, RFC 1155, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [RFC1212] McCloghrie, K., and M. Rose, Editors, "Concise MIB Definitions.nr _F 1 q, STD 16, RFC 1212, Hughes LAN Systems, Performance Systems International, March 1991. [RFC1213] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [RFC1901] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [RFC1902] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [RFC1903] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [RFC1905] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple SNMPv3 Working Group Expires February 1999 [Page 39] Internet Draft Coexistence between SNMP versions 7 Aug 1998 Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [RFC1907] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [RFC1908] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC1905, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [RFC2271] The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An Architecture for Describing SNMP Management Frameworks", RFC2271, January 1998. [RFC2272] The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B., "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC2272, January 1998. [RFC2273] The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMPv3 Applications", RFC2273, January 1998. [RFC2274] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User- Based Security Model for Version 3 of the Simple Network Management Protocol (SNMP)", RFC2274, January 1998. [RFC2275] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K., "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC2275, January 1998. SNMPv3 Working Group Expires February 1999 [Page 40] Internet Draft Coexistence between SNMP versions 7 Aug 1998 13. Editor's Address Rob Frye MCI Communications Corp. 2100 Reston Parkway, Suite 600 Reston, VA 20191 U.S.A. Phone: +1 703 715 7225 EMail: Rob.Frye@mci.com David B. Levi SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 U.S.A. Phone: +1 423 573 1434 EMail: levi@snmp.com Bert Wijnen IBM T. J. Watson Research Schagen 33 3461 GL Linschoten Netherlands Phone: +31 348 432 794 EMail: wijnen@vnet.ibm.com SNMPv3 Working Group Expires February 1999 [Page 41] Internet Draft Coexistence between SNMP versions 7 Aug 1998 A. Full Copyright Statement This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SNMPv3 Working Group Expires February 1999 [Page 42]