📄 rfc2576.txt
字号:
Network Working Group R. FryeRequest for Comments: 2576 CoSine CommunicationsCategory: Standards Track D. Levi Nortel Networks S. Routhier Integrated Systems Inc. B. Wijnen Lucent Technologies March 2000 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management FrameworkStatus of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved.Abstract The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document obsoletes RFC 1908 [13] and RFC2089 [14].Table Of Contents 1 Overview ..................................................... 2 1.1 SNMPv1 ..................................................... 3 1.2 SNMPv2 ..................................................... 4 1.3 SNMPv3 ..................................................... 4 1.4 SNMPv1 and SNMPv2 Access to MIB Data ....................... 5 2 SMI and Management Information Mappings ...................... 5 2.1 MIB Modules ................................................ 6 2.1.1 Object Definitions ....................................... 6 2.1.2 Trap and Notification Definitions ........................ 9 2.2 Compliance Statements ...................................... 9 2.3 Capabilities Statements .................................... 10Frye, et al. Standards Track [Page 1]RFC 2576 Coexistence between SNMP versions March 2000 3 Translating Notifications Parameters ......................... 10 3.1 Translating SNMPv1 Notification Parameters to SNMPv2 Notification Parameters ................................... 12 3.2 Translating SNMPv2 Notification Parameters to SNMPv1 Notification Parameters ................................... 13 4 Approaches to Coexistence in a Multi-lingual Network ......... 14 4.1 Multi-lingual implementations .............................. 15 4.1.1 Command Generator ........................................ 15 4.1.2 Command Responder ........................................ 15 4.1.2.1 Handling Counter64 ..................................... 16 4.1.2.2 Mapping SNMPv2 Exceptions .............................. 16 4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 17 4.1.2.2.2 Mapping endOfMibView ................................. 17 4.1.2.3 Processing An SNMPv1 GetRequest ........................ 18 4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 19 4.1.2.5 Processing An SNMPv1 SetRequest ........................ 20 4.1.3 Notification Originator .................................. 20 4.1.4 Notification Receiver .................................... 21 4.2 Proxy Implementations ...................................... 21 4.2.1 Upstream Version Greater Than Downstream Version ......... 21 4.2.2 Upstream Version Less Than Downstream Version ............ 22 4.3 Error Status Mappings ...................................... 24 5 Message Processing Models and Security Models ................ 25 5.1 Mappings ................................................... 25 5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security Model ..................................................... 26 5.2.1 Processing An Incoming Request ........................... 26 5.2.2 Generating An Outgoing Response .......................... 28 5.2.3 Generating An Outgoing Notification ...................... 28 5.3 The SNMP Community MIB Module .............................. 29 6 Intellectual Property ........................................ 39 7 Acknowledgments .............................................. 39 8 Security Considerations ...................................... 40 9 References ................................................... 40 10 Editor's Addresses .......................................... 42 A. Changes From RFC1908 ........................................ 43 Full Copyright Statement ....................................... 441. Overview The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, termed the SNMP version 3 framework (SNMPv3), version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1).Frye, et al. Standards Track [Page 2]RFC 2576 Coexistence between SNMP versions March 2000 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [15]. There are four general aspects of coexistence described in this document. Each of these is described in a separate section: - Conversion of MIB documents between SMIv1 and SMIv2 formats is documented in section 2. - Mapping of notification parameters is documented in section 3. - Approaches to coexistence between entities which support the various versions of SNMP in a multi-lingual network is documented in section 4. This section addresses the processing of protocol operations in multi-lingual implementations, as well as behaviour of proxy implementations. - The SNMPv1 Message Processing Model and Community-Based Security Model, which provides mechanisms for adapting SNMPv1 into the View-Based Access Control Model (VACM) [20], is documented in section 5 (this section also addresses the SNMPv2c Message Processing Model and Community-Based Security Model).1.1. SNMPv1 SNMPv1 is defined by these documents: - STD 15, RFC 1157 [2] which defines the Simple Network Management Protocol (SNMPv1), the protocol used for network access to managed objects. - STD 16, RFC 1155 [1] which defines the Structure of Management Information (SMIv1), the mechanisms used for describing and naming objects for the purpose of management. - STD 16, RFC 1212 [3] which defines a more concise description mechanism, which is wholly consistent with the SMIv1. - RFC 1215 [4] which defines a convention for defining Traps for use with the SMIv1. Note that throughout this document, the term 'SMIv1' is used. This term generally refers to the information presented in RFC 1155, RFC 1212, and RFC 1215.Frye, et al. Standards Track [Page 3]RFC 2576 Coexistence between SNMP versions March 20001.2. SNMPv2 SNMPv2 is defined by these documents: - STD 58, RFC 2578 which defines Version 2 of the Structure of Management Information (SMIv2) [7]. - STD 58, RFC 2579 which defines common MIB "Textual Conventions" [8]. - STD 58, RFC 2580 which defines Conformance Statements and requirements for defining agent and manager capabilities [9]. - RFC 1905 which defines the Protocol Operations used in processing [10]. - RFC 1906 which defines the Transport Mappings used "on the wire" [11]. - RFC 1907 which defines the basic Management Information Base for monitoring and controlling some basic common functions of SNMP entities [12]. Note that SMIv2 as used throughout this document refers to the first three documents listed above (RFCs 2578, 2579, and 2580). The following document augments the definition of SNMPv2: - RFC 1901 [6] is an Experimental definition for using SNMPv2 PDUs within a community-based message wrapper. This is referred to throughout this document as SNMPv2c.1.3. SNMPv3 SNMPv3 is defined by these documents: - RFC 2571 which defines an Architecture for Describing SNMP Management Frameworks [16]. - RFC 2572 which defines Message Processing and Dispatching [17]. - RFC 2573 which defines various SNMP Applications [18]. - RFC 2574 which defines the User-based Security Model (USM), providing for both Authenticated and Private (encrypted) SNMP messages [19].Frye, et al. Standards Track [Page 4]RFC 2576 Coexistence between SNMP versions March 2000 - RFC 2575 which defines the View-based Access Control Model (VACM), providing the ability to limit access to different MIB objects on a per-user basis [20]. SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 and the SMIv2 definitions of 2578 through 2580 described above.1.4. SNMPv1 and SNMPv2 Access to MIB Data In several places, this document refers to 'SNMPv1 Access to MIB Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the part of an SNMP agent which actually accesses instances of MIB objects, and which actually initiates generation of notifications. Differences between the two types of access to MIB data are: - Error-status values generated. - Generation of exception codes. - Use of the Counter64 data type. - The format of parameters provided when a notification is generated. SNMPv1 access to MIB data may generate SNMPv1 error-status values, will never generate exception codes nor use the Counter64 data type, and will provide SNMPv1 format parameters for generating notifications. Note also that SNMPv1 access to MIB data will actually never generate a readOnly error (a noSuchName error would always occur in the situation where one would expect a readOnly error). SNMPv2 access to MIB data may generate SNMPv2 error-status values, may generate exception codes, may use the Counter64 data type, and will provide SNMPv2 format parameters for generating notifications. Note that SNMPv2 access to MIB data will never generate readOnly, noSuchName, or badValue errors. Note that a particular multi-lingual implementation may choose to implement all access to MIB data as SNMPv2 access to MIB data, and perform the translations described herein for SNMPv1-based transactions.2. SMI and Management Information Mappings The SMIv2 approach towards describing collections of managed objects is nearly a proper superset of the approach defined in the SMIv1. For example, both approaches use an adapted subset of ASN.1 (1988)Frye, et al. Standards Track [Page 5]RFC 2576 Coexistence between SNMP versions March 2000 [11] as the basis for a formal descriptive notation. Indeed, one might note that the SMIv2 approach largely codifies the existing practice for defining MIB modules, based on extensive experience with the SMIv1. The following sections consider the three areas: MIB modules, compliance statements, and capabilities statements.2.1. MIB Modules MIB modules defined using the SMIv1 may continue to be used with protocol versions which use SNMPv2 PDUs. However, for the MIB modules to conform to the SMIv2, the following changes SHALL be made:2.1.1. Object Definitions In general, conversion of a MIB module does not require the deprecation of the objects contained therein. If the definition of an object is truly inadequate for its intended purpose, the object
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -