idnits 2.17.1 draft-ietf-snmpv3-coex-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC1157], [RFC2271], [RFC1901]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 928 has weird spacing: '...ailable gen...' == Line 1482 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (7 Aug 1998) is 9393 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1904' is mentioned on line 152, but not defined ** Obsolete undefined reference: RFC 1904 (Obsoleted by RFC 2580) == Missing Reference: 'RFC1906' is mentioned on line 158, but not defined ** Obsolete undefined reference: RFC 1906 (Obsoleted by RFC 3417) -- Looks like a reference, but probably isn't: '10' on line 198 -- Looks like a reference, but probably isn't: '11' on line 361 == Unused Reference: 'RFC1213' is defined on line 1375, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 1415, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Obsolete normative reference: RFC 1902 (ref. 'RFC1901') (Obsoleted by RFC 2578) -- Duplicate reference: RFC1902, mentioned in 'RFC1902', was also mentioned in 'RFC1901'. ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) -- Duplicate reference: RFC1905, mentioned in 'RFC1907', was also mentioned in 'RFC1905'. ** Obsolete normative reference: RFC 1905 (ref. 'RFC1907') (Obsoleted by RFC 3416) -- Duplicate reference: RFC1905, mentioned in 'RFC1908', was also mentioned in 'RFC1907'. ** Obsolete normative reference: RFC 1905 (ref. 'RFC1908') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2271 (Obsoleted by RFC 2571) ** Obsolete normative reference: RFC 2272 (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2273 (Obsoleted by RFC 2573) ** Obsolete normative reference: RFC 2274 (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 2275 (Obsoleted by RFC 2575) Summary: 24 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Coexistence between SNMP versions 7 Aug 1998 4 INTERNET-DRAFT Rob Frye 5 MCI Communications Corp. 6 David B. Levi 7 SNMP Research, Inc. 8 Bert Wijnen 9 IBM T.J. Watson Research 10 7 Aug 1998 12 Coexistence between Version 1, Version 2, and Version 3 13 of the Internet-standard Network Management Framework 14 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 30 Directories on ds.internic.net (US East Coast), nic.nordu.net 31 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 32 Rim). 34 Copyright Notice 36 Copyright (C) The Internet Society (date). All Rights Reserved. 38 Abstract 40 The purpose of this document is to describe coexistence between 41 version 3 of the Internet-standard Network Management Framework 42 [RFC2271], termed the SNMP version 3 framework (SNMPv3), version 2 of 43 the Internet-standard Network Management Framework [RFC1901], termed 44 the SNMP version 2 framework (SNMPv2), and the original Internet- 45 standard Network Management Framework (SNMPv1) [RFC1157]. 47 Table Of Contents 49 1 Overview ..................................................... 4 50 1.1 SNMPv1 ..................................................... 4 51 1.2 SNMPv2 ..................................................... 5 52 1.3 SNMPv3 ..................................................... 5 53 2 SMI and Management Information Mappings ...................... 7 54 2.1 Object Definitions ......................................... 7 55 2.2 Trap Definitions ........................................... 9 56 2.3 Compliance Statements ...................................... 10 57 2.4 Capabilities Statements .................................... 10 58 3 SNMPv1 and SNMPv2 MIB Instrumentation ........................ 12 59 4 Translating Notifications Between SNMP Formats ............... 13 60 4.1 Translating SNMPv1 Format to SNMPv2 Format ................. 14 61 4.2 Translating SNMPv2 Format to SNMPv1 Format ................. 15 62 4.3 Notification Translation Failure ........................... 16 63 4.3.1 discussion about additional varbinds (agent_addr, com- 64 munity) ................................................... 17 65 5 Approaches to Coexistence in a Multi-lingual Network ......... 18 66 5.1 Multi-lingual implementations .............................. 18 67 5.1.1 Command Generator ........................................ 18 68 5.1.2 Command Responder ........................................ 18 69 5.1.3 Notification Originator .................................. 19 70 5.1.4 Notification Receiver .................................... 19 71 5.2 Proxy Implementations ...................................... 19 72 6 Multi-Lingual Command Responder Behaviour .................... 21 73 6.1 Mapping SMIv2 into SMIv1 ................................... 21 74 6.2 Mapping SNMPv2 Exceptions .................................. 21 75 6.2.1 Mapping nosuchObject and noSuchInstance .................. 22 76 6.2.2 Mapping endOfMibView ..................................... 22 77 6.3 Processing An SNMPv1 GetRequest ............................ 23 78 6.4 Processing An SNMPv1 GetNextRequest ........................ 24 79 7 Error Status Mappings ........................................ 26 80 8 Message Processing Models and Security Models ................ 27 81 8.1 Mappings ................................................... 27 82 8.2 Elements Of Procedure ...................................... 27 83 8.2.1 Processing An Incoming Request ........................... 28 84 8.2.2 Processing An Outgoing Response .......................... 28 85 8.2.3 Processing An Incoming Notification ...................... 28 86 8.2.4 Processing An Outgoing Notification ...................... 28 87 8.3 Community MIB .............................................. 28 88 9 Intellectual Property ........................................ 35 89 10 Acknowledgments ............................................. 36 90 11 Security Considerations ..................................... 38 91 12 References .................................................. 39 92 13 Editor's Address ............................................ 41 93 A. Full Copyright Statement .................................... 42 95 1. Overview 97 The purpose of this document is to describe coexistence between 98 version 3 of the Internet-standard Network Management Framework 99 [RFC2271], termed the SNMP version 3 framework (SNMPv3), version 2 of 100 the Internet-standard Network Management Framework [RFC1901], termed 101 the SNMP version 2 framework (SNMPv2), and the original Internet- 102 standard Network Management Framework (SNMPv1) [RFC1157]. 104 There are five general aspects of coexistence described in this 105 document. Each of these is described in a separate section: 107 - Conversion of MIB documents between SMIv1 and SMIv2 formats is 108 documented in section 2. 110 - Mapping of notifications between SMIv1 and SMIv2 formats is 111 documented in section 4. 113 - Approaches to coexistence between SNMPv1, SNMPv2, and SNMPv3 114 entities in a multi-lingual network is documented in section 115 5. 117 - Processing of protocol operations in multi-lingual 118 implementations is documented in section 6. 120 - The Community-Based Security Model, which provides mechanisms 121 for adapting SNMPv1 and SNMPv2 into the SNMPv3 view-based 122 access control, is documented in section 8. 124 1.1. SNMPv1 SNMPv1 is defined by these three documents: 126 - STD 16, RFC 1155 [RFC1155] which defines the Structure of 127 Management Information (SMI), the mechanisms used for 128 describing and naming objects for the purpose of management. 130 - STD 16, RFC 1212 [RFC1212] which defines a more concise 131 description mechanism, which is wholly consistent with the 132 SMI. 134 - STD 15, RFC 1157 [RFC1157] which defines the Simple Network 135 Management Protocol (SNMP), the protocol used for network 136 access to managed objects. 138 - (NOTE: Rob had suggested adding rfcs 1213, 2011, 2012, 2013, 139 1215. Which, if any, of these should we add?) 141 1.2. SNMPv2 143 SNMPv2 is defined by these six documents: 145 - RFC 1902 which defines Version 2 of the Structure of 146 Management Information (SMI) [RFC1902]. 148 - RFC 1903 which defines common MIB "Textual Conventions" 149 [RFC1903]. 151 - RFC 1904 which defines Conformance Statements and requirements 152 for defining agent and manager capabilities [RFC1904]. 154 - RFC 1905 which defines the Protocol Operations used in 155 processing [RFC1905]. 157 - RFC 1906 which defines the Transport Mappings used "on the 158 wire" [RFC1906]. 160 - RFC 1907 which defines the basic Management Information Base 161 upon which other MIBs can be built [RFC1907]. 163 In addition, the following three documents augment the definition of 164 SNMPv2: 166 - RFC 1901 is an Experimental definition for using SNMPv2 format 167 PDUs within a community-based message format. This is 168 referred to throughout this document as SNMPv2c [RFC1901]. 170 - RFC 2011 defines the IP MIB using SMIv2. 172 1.3. SNMPv3 SNMPv3 is defined by the these five documents: 174 - RFC 2271 which defines the v3 Architecture for Describing SNMP 175 Management Frameworks [RFC2271]. 177 - RFC 2272 which defines Message Processing and Dispatching 178 [RFC2272]. 180 - RFC 2273 which defines various SNMPv3 Applications [RFC2273]. 182 - RFC 2274 which defines the User-based Security Model (USM), 183 providing for both Authenticated and Private (encrypted) SNMP 184 transactions [RFC2274]. 186 - RFC 2275 which defines the View-based Access Control Model 187 (VACM), providing the ability to limit access to different MIB 188 objects on a per-user basis [RFC2275]. 190 SNMPv3 also uses the SNMPv2 definitions of RFCs 1902 through 1907 191 described above. 193 2. SMI and Management Information Mappings 195 The SNMPv2 approach towards describing collections of managed objects 196 is nearly a proper superset of the approach defined in the Internet- 197 standard SNMPv1 Network Management Framework. For example, both 198 approaches use ASN.1 [10] as the basis for a formal descriptive 199 notation. Indeed, one might note that the SNMPv2 approach largely 200 codifies the existing practice for defining MIB modules, based on 201 extensive experience with the SNMPv1 framework. 203 The following sections consider the three areas: MIB modules, 204 compliance statements, and capabilities statements. 206 MIB modules defined using the SNMPv1 framework may continue to be 207 used with the SNMPv2 protocol. However, for the MIB modules to 208 conform to the SNMPv2 framework, the following changes are required: 210 2.1. Object Definitions 212 In general, conversion of a MIB module does not require the 213 deprecation of the objects contained therein. Only if the semantics 214 of an object truly changes should deprecation be performed. 216 (1) The IMPORTS statement must reference SNMPv2-SMI, instead of 217 RFC1155-SMI and RFC-1212. 219 (2) The MODULE-IDENTITY macro must be invoked immediately after any 220 IMPORTs statement. 222 (3) For any descriptor which contains the hyphen character, the hyphen 223 character is removed. 225 (4) For any label for a named-number enumeration which contains the 226 hyphen character, the hyphen character is removed. 228 (5) For any object with an integer-valued SYNTAX clause, in which the 229 corresponding INTEGER does not have a range restriction (i.e., the 230 INTEGER has neither a defined set of named-number enumerations nor 231 an assignment of lower- and upper-bounds on its value), the object 232 must have the value of its SYNTAX clause changed to Integer32. 234 (6) For any object with a SYNTAX clause value of an enumerated INTEGER, 235 the hyphen character is removed from any named-number labels which 236 contain the hyphen character. 238 (7) For any object with a SYNTAX clause value of Counter, the object 239 must have the value of its SYNTAX clause changed to Counter32. 241 (8) For any object with a SYNTAX clause value of Gauge, the object must 242 have the value of its SYNTAX clause changed to Gauge32. 244 (9) For all objects, the ACCESS clause must be replaced by a MAX-ACCESS 245 clause. The value of the MAX-ACCESS clause is the same as that of 246 the ACCESS clause unless some other value makes "protocol sense" as 247 the maximal level of access for the object. In particular, object 248 types for which instances can be explicitly created by a protocol 249 set operation, will have a MAX-ACCESS clause of "read-create". If 250 the value of the ACCESS clause is "write-only", then the value of 251 the MAX-ACCESS clause is "read-write", and the DESCRIPTION clause 252 notes that reading this object will result implementation-specific 253 results. 255 (10) For all objects, if the value of the STATUS clause is "mandatory", 256 the value must be replaced with "current". 258 (11) For all objects, if the value of the STATUS clause is "optional", 259 the value must be replaced with "obsolete". 261 (12) For any object not containing a DESCRIPTION clause, the object must 262 have a DESCRIPTION clause defined. 264 (13) For any object corresponding to a conceptual row which does not 265 have an INDEX clause, the object must have either an INDEX clause 266 or an AUGMENTS clause defined. 268 (14) For any object with an INDEX clause that references an object with 269 a syntax of NetworkAddress, the value of the STATUS clause of both 270 objects is changed to "obsolete". 272 (15) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER 273 value which is expressed as a collection of sub-identifiers, change 274 the value to reference a single ASN.1 identifier. This may require 275 defining a series of new objects in order to define the single 276 ASN.1 identifier. 278 Other changes are desirable, but not necessary: 280 (1) Creation and deletion of conceptual rows is inconsistent using the 281 SNMPv1 framework. The SNMPv2 and SNMPv3 frameworks correct this. 282 As such, if the MIB module undergoes review early in its lifetime, 283 and it contains conceptual tables which allow creation and deletion 284 of conceptual rows, then it may be worthwhile to deprecate the 285 objects relating to those tables and replace them with objects 286 defined using the new approach. 288 (2) For any object with a string-valued SYNTAX clause, in which the 289 corresponding OCTET STRING does not have a size restriction (i.e., 290 the OCTET STRING has no assignment of lower- and upper-bounds on 291 its length), it is recommended that the bounds for the size of the 292 object be defined. 294 (3) For all textual conventions informally defined in the MIB module, 295 it is recommended that those conventions using the TEXTUAL- 296 CONVENTION macro be redefined. Such a change would not necessitate 297 deprecating objects previously defined using an informal textual 298 convention. 300 (4) For any object which represents a measurement in some kind of 301 units, it is recommended that a UNITS clause be added to the 302 definition of that object. 304 (5) For any conceptual row which is an extension of another conceptual 305 row, i.e., for which subordinate columnar objects both exist and 306 are identified via the same semantics as the other conceptual row, 307 it is recommended that an AUGMENTS clause be used in place of the 308 INDEX clause for the object corresponding to the conceptual row 309 which is an extension. 311 Finally, when encountering common errors in SNMPv1 MIB modules: 313 (1) For any non-columnar object that is instanced as if it were 314 immediately subordinate to a conceptual row, the value of the 315 STATUS clause of that object is changed to "obsolete". 317 (2) For any conceptual row object that is not contained immediately 318 subordinate to a conceptual table, the value of the STATUS clause 319 of that object (and all subordinate objects) is changed to 320 "obsolete". 322 2.2. Trap Definitions 324 If a MIB module is changed to conform to the SNMPv2 framework, then 325 each occurrence of the TRAP-TYPE macro must be changed to a 326 corresponding invocation of the NOTIFICATION-TYPE macro: 328 (1) The IMPORTS statement must not reference RFC-1215, and should 329 reference SNMPv2-SMI instead. 331 (2) The ENTERPRISE clause must be removed. 333 (3) The VARIABLES clause must be renamed to the OBJECTS clause. 335 (4) The STATUS clause must be added, with a value of 'current'. 337 (5) The value of an invocation of the NOTIFICATION-TYPE macro is an 338 OBJECT IDENTIFIER, not an INTEGER, and must be changed accordingly. 339 Specifically, if the value of the ENTERPRISE clause is not 'snmp' 340 then the value of the invocation is the value of the ENTERPRISE 341 clause extended with two sub-identifiers, the first of which has 342 the value 0, and the second has the value of the invocation of the 343 TRAP-TYPE. 345 (6) The DESCRIPTION clause must be added, if not already present. 347 (7) One or more NOTIFICATION-GROUPs should be defined, and related 348 notifications should be collected into those groups. 350 2.3. Compliance Statements 352 For those information modules which are "standard", a corresponding 353 invocation of the MODULE-COMPLIANCE macro must be included within the 354 information module (or in a companion information module), and any 355 commentary text in the information module which relates to compliance 356 must be removed. Typically this editing can occur when the 357 information module undergoes review. 359 2.4. Capabilities Statements 361 In the SNMPv1 framework, the informational document [11] uses the 362 MODULE-CONFORMANCE macro to describe an agent's capabilities with 363 respect to one or more MIB modules. Converting such a description 364 for use with the SNMPv2 framework requires these changes: 366 (1) Use the macro name AGENT-CAPABILITIES instead of MODULE- 367 CONFORMANCE. 369 (2) The STATUS clause must be added, with a value of 'current'. 371 (3) For all occurrences of the CREATION-REQUIRES clause, note the 372 slight change in semantics, and omit this clause if appropriate. 374 In order to ease the coexistence between SNMPv1, SNMPv2, and SNMPv3, 375 object groups defined in an SMIv1 compliant MIB module may be 376 referenced by the INCLUDES clause of an invocation of the AGENT- 377 CAPABILITIES macro: upon encountering a reference to an OBJECT 378 IDENTIFIER subtree defined in an SNMPv1 MIB module, all leaf objects 379 which are subordinate to the subtree and have a STATUS clause value 380 of mandatory are deemed to be INCLUDEd. (Note that this method is 381 ambiguous when different revisions of a SNMPv1 MIB have different 382 sets of mandatory objects under the same subtree; in such cases, the 383 only solution is to rewrite the MIB using the SMIv2 in order to 384 define the object groups unambiguously.) 386 3. SNMPv1 and SNMPv2 MIB Instrumentation 388 In several places, this document refers to SNMPv1 MIB Instrumentation 389 and SNMPv2 MIB Instrumentation. This refers to the part of an SNMP 390 agent which actually implements MIB objects, and which actually 391 initiates generation of notifications. Differences between the two 392 types of MIB instrumentation are: 394 - Error-status values generated. 396 - Generation of exception codes. 398 - Use of the Counter64 data type. 400 - The format of parameters provided when a notification is 401 generated. 403 SNMPv1 MIB instrumentation will generate SNMPv1 error-status values, 404 will never generate exception codes nor use the Counter64 data type, 405 and will provide SNMPv1 format parameters for generating 406 notifications. 408 SNMPv2 MIB instrumentation will generate SNMPv2 error-status values, 409 will generate exception codes, will use the Counter64 data type, and 410 will provide SNMPv2 format parameters for generating notifications. 412 4. Translating Notifications Between SNMP Formats 414 This section describes how data contained in a notification is 415 translated between the SNMPv1 format and the SNMPv2 format. There 416 are two parts to the format of a notification, the SMI version used 417 to define the notification, and the format of parameters used to 418 represent a generated notification. 420 The SMI version used to define a notification will generally 421 determine the format of parameters used when a notification is 422 generated by MIB instrumentation. There are two formats for 423 parameters, those used in an SNMPv1 notification, and those used in 424 an SNMPv2 notification. These set of information are refered to in 425 this section as 'notification parameters format'. There are two 426 formats, the SNMPv1 notification parameter format and the SNMPv2 427 notification parameter format. There are two situations where 428 notification parameters must be translated between SNMP formats: 430 - When instrumentation in an entity generates a set of 431 notification parameters using one SNMP format, and the 432 configuration of the entity indicates that the notification 433 must be sent using a protocol version that requires 434 notification parameters in the other SNMP format. 436 - When a proxy receives a notification in one SNMP format, and 437 must forward the notification using a protocol version that 438 requires a different SNMP format. 440 In addition, it may be desirable to translate notification parameters 441 in a notification receiver application in order to present 442 notifications to the end user in a consistent format. 444 Note that for the purposes of this section, the format of 445 notification parameters is independent of whether the notification is 446 to be sent as a trap or an inform. 448 SNMPv1 notification parameters consist of: 450 - An enterprise value (OBJECT IDENTIFIER). 452 - An agent-addr value (NetworkAddress). 454 - A generic-trap value (INTEGER). 456 - A specific-trap value (INTEGER). 458 - A time-stamp value (TimeTicks). 460 - A list of variable-bindings (VarBindList). 462 SNMPv2 notification parameters consist of: 464 - A sysUpTime value (TimeTicks). This appears in the first 465 variable-binding in an SNMPv2 notification. 467 - An snmpTrapOID value (OBJECT IDENTIFIER). This appears in the 468 second variable-binding in an SNMPv2 notification. 470 - A list of variable-bindings (VarBindList). This refers to all 471 but the first two variable-bindings in an SNMPv2 notification. 473 4.1. Translating SNMPv1 Format to SNMPv2 Format 475 The following procedure describes how to translate SNMPv1 476 notification parameters into SNMPv2 notification parameters: 478 (1) The SNMPv2 sysUpTime value is taken directly from the SNMPv1 time- 479 stamp value. 481 (2) If the SNMPv1 generic-trap value is 'enterpriseSpecific(6)', the 482 SNMPv2 snmpTrapOID value is the concatentation of the SNMPv1 483 enterprise value and two additional sub-identifiers, '0', and the 484 SNMPv1 specific-trap value. 486 (3) If the SNMPv1 generic-trap value is not 'enterpriseSpecific(6)', 487 the SNMPv2 snmpTrapOID value is the corresponding trap as defined 488 in [RFC1907]. 490 (4) The SNMPv2 variable-bindings is the SNMPv1 variable-bindings with a 491 single variable-binding appended. The name portion of this 492 variable binding contains snmpTrapEnterprise.0 [RFC1907], and the 493 value is the SNMPv1 enterprise value. 495 (5) The value of the agent-addr field is lost when converting 496 notification parameters from SNMPv1 to SNMPv2. 498 4.2. Translating SNMPv2 Format to SNMPv1 Format 500 The following procedure describes how to translate SNMPv2 501 notification parameters into SNMPv1 notification parameters: 503 (1) The SNMPv1 enterprise value is determined as follows: 505 - If the SNMPv2 snmpTrapOID value is one of the standard traps 506 as defined in [RFC1907], then the SNMPv1 enterprise value is 507 set to the value of the variable-binding in the SNMPv2 508 variable-bindings whose name is snmpTrapEnterprise.0 if that 509 variable-binding exists. If it does not exist, the SNMPv1 510 enterprise value is set to the value 'snmpTraps' as defined in 511 RFC1907 [RFC1907]. 513 - If the SNMPv2 snmpTrapOID value is not one of the standard 514 traps as defined in [RFC1907], then the SNMPv1 enterprise 515 value is set to the SNMPv2 snmpTrapOID value as follows: 517 - If the next-to-last sub-identifier of the snmpTrapOID is 518 zero, then the SMIv1 enterprise is the SMIv2 snmpTrapOID 519 with the last 2 sub-identifiers removed, otherwise 521 - If the next-to-last sub-identifier of the snmpTrapOID is 522 non-zero, then the SMIv1 enterprise is the SMIv2 523 snmpTrapOID with the last sub-identifier removed. 525 (2) The SNMPv1 agent-addr value is determined based on the situation in 526 which the translation occurs. 528 - If the translation occurs within a notification originator 529 application, and the notification is to be sent over UDP, the 530 SNMPv1 agent-addr value is set to the IP address of the SNMP 531 entity in which the notification originator resides. If the 532 notification is to be sent over some other transport, the 533 SNMPv1 agent-addr value is set to 0.0.0.0. 535 - If the translation occurs within a proxy application, the 536 proxy must attempt to determine the original source of the 537 notification. If this source was an IP or UDP address, that 538 address is used for the SNMPv1 agent-addr value. Otherwise, 539 the SNMPv1 agent-addr value is set to 0.0.0.0. 541 (3) If the SNMPv2 snmpTrapOID value is one of the standard traps as 542 defined in [RFC1907], the SNMPv1 generic-trap value is set as 543 follows: 545 value of snmpTrapOID.0 generic-trap 546 =============================== ============ 547 1.3.6.1.6.3.1.1.5.1 (coldStart) 0 548 1.3.6.1.6.3.1.1.5.2 (warmStart) 1 549 1.3.6.1.6.3.1.1.5.3 (linkDown) 2 550 1.3.6.1.6.3.1.1.5.4 (linkUp) 3 551 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4 552 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5 554 Otherwise, the SNMPv1 generic-trap value is set to 6. 556 (4) If the SNMPv2 snmpTrapOID value is one of the standard traps as 557 defined in [RFC1907], the SNMPv1 specific-trap value is set to 558 zero. Otherwise, the SNMPv1 specific-trap value is set to the last 559 sub-identifier of the SNMPv2 snmpTrapOID value. 561 (5) The SNMPv1 time-stamp value is taken directly from the SNMPv2 562 sysUpTime value. 564 (6) The SNMPv1 variable-bindings is the SNMPv2 variable-bindings with 565 the following exceptions: 567 - If a variable-binding whose name is snmpTrapEnterprise.0 568 exists in the SNMPv2 variable-bindings, that variable-binding 569 is removed. 571 - If a variable-binding whose type is Counter64 exists in the 572 SNMPv2 variable-bindings, the translation fails. The 573 consequences of a failed translation depend on the situation 574 in which the translation is being performed. 576 4.3. Notification Translation Failure 578 If translation of a notification from SNMPv2 to SNMPv1 fails due to 579 the existence of a variable-binding with a type of Counter64, the 580 result is as follows: 582 - If the translation is being performed within a notification 583 originator in order to send an SNMPv1 Trap-PDU, the Trap-PDU 584 is simply not sent. The notification may still be sent using 585 other SNMP versions. 587 - If the translation is being performed within a proxy in order 588 to forward the notification as an SNMPv1 Trap-PDU, the Trap- 589 PDU is not sent. The notification may still be forwarded 590 using other SNMP versions. 592 4.3.1. discussion about additional varbinds (agent_addr, community) 593 5. Approaches to Coexistence in a Multi-lingual Network 595 There are two basic approaches to coexistence in a multi-lingual 596 network, multi-lingual implementations, and proxy implementations. 597 Multi-lingual implementations allow elements in a network to 598 communicate with each other using an SNMP version which both elements 599 support. This allows a multi-lingual implentation to communicate 600 with any mono-lingual implementation, regardless of the SNMP version 601 supported by the mono-lingual implementation. 603 Proxy implementations provide a mechanism for translating between 604 SNMP versions using a third party network element. This allows 605 network elements which support only a single, but different, SNMP 606 version to communicate with each other. Proxy implementations are 607 also useful for securing communications over an insecure link between 608 two locally secure networks. 610 5.1. Multi-lingual implementations 612 This approach requires an entity to support multiple SNMP message 613 formats. Typically this means supporting SNMPv1, SNMPv2c, and SNMPv3 614 message formats. The behaviour of various types of SNMPv3 615 applications which support multiple message formats is described in 616 the following sections. This approach allows entities which support 617 multiple SNMP message formats to coexist with and communicate with 618 entities which support only a single SNMP message format. 620 5.1.1. Command Generator 622 A command generator must select an appropriate message format when 623 sending requests to another entity. One way to achieve this is to 624 consult a local database to select the appropriate message format. 626 In addition, a command generator should 'downgrade' GetBulk requests 627 to GetNext requests when selecting SNMPv1 as the message format for 628 an outgoing request. 630 5.1.2. Command Responder 632 A command responder must be able to deal with MIB instrumentation 633 that is written using both the SNMPv1 and SNMPv2. There are three 634 aspects to dealing with this. A command responder must: 636 - Deal correctly with SNMPv2 MIB instrumentation that returns a 637 Counter64 value while processing an SNMPv1 message, 639 - Deal correctly with SNMPv2 instrumentation that returns one of 640 the three exception values while processing an SNMPv1 message, 642 - Map SNMPv2 error codes returned from SNMPv2 instrumentation 643 into SNMPv1 error code when processing an SNMPv1 message, and 645 Note that SNMPv1 error codes can be used without any change when 646 processing SNMPv2c or SNMPv3 messages. 648 Details about how a command responder handles these requirements are 649 provided in section 6. 651 5.1.3. Notification Originator 653 A notification originator must be able to translate notifications 654 between SNMPv1 and SNMPv2 formats in order to send a notification 655 using a particular SNMP message format. If instrumentation presents 656 a notification in the SMIv1 format and configuration information 657 specifies that notifications be sent using SNMPv2c or SNMPv3, the 658 notification must be translated to the SNMPv2 format. Likewise, if 659 instrumentation presents a notification in the SNMPv2 format and 660 configuration information specifies that notifications be sent using 661 SNMPv1, the notification must be translated to the SNMPv1 format. 663 5.1.4. Notification Receiver 665 There are no special requirements of a notification receiver. 666 However, an implementation may find it useful to allow a higher level 667 application to request which SNMP format should be used when 668 delivering notifications to that higher level application. The 669 notification receiver would then translate between SNMP formats when 670 required in order to present a notification using the desired format. 672 5.2. Proxy Implementations 674 A proxy implementation may be used to enable communication between 675 entities which support different SNMP message formats. This is 676 accomplished in a proxy forwarding application by performing 677 translations on a PDU in the following situations: 679 - If a GetBulkRequest-PDU is received and must be forwarded 680 using the SNMPv1 message format, the proxy forwarder sets the 681 non-repeaters and max-repetitions fields to 0, and sets the 682 tag of the PDU to GetNextRequest-PDU. 684 - If a GetResponse-PDU is received whose error-status field has 685 a value of 'tooBig', and the message will be forwarded using 686 the SNMPv2c or SNMPv3 message format, the proxy forwarder will 687 remove the contents of the variable-bindings field before 688 forwarding the response. 690 - If a Trap-PDU is received, and will be forwarded using the 691 SNMPv2c or SNMPv3 message format, the proxy will apply the 692 translation rules described in section 4, and will forward the 693 notification as an SNMPv2-Trap-PDU. 695 - If an SNMPv2-Trap-PDU is received, and will be forwarded using 696 the SNMPv1 message format, the proxy will apply the 697 translation rules described in section 4, and will forward the 698 notification as a Trap-PDU. 700 - If an InformRequest-PDU is received, any configuration 701 information indicating that it would be forwarded using the 702 SNMPv1 message format, is ignored. An InformRequest-PDU can 703 only be forwarded using the SNMPv2c or SNMPv3 message format. 705 6. Multi-Lingual Command Responder Behaviour 707 The following sections describe the behaviour of a command responder 708 application which supports multiple SNMP message formats, and which 709 has access to some combination of SNMPv1 and SNMPv2 MIB 710 instrumentation. 712 6.1. Mapping SMIv2 into SMIv1 714 The SMIv2 [RFC1902] defines one new syntax that is incompatible with 715 SMIv1. This syntax is Counter64. All other syntaxes defined by 716 SMIv2 are compatible with SMIv1. 718 The impact on multi-lingual command responders is that they should 719 make sure that they never return a variable binding containing a 720 Counter64 value in a response to a request that was received using 721 the SNMPv1 message format. 723 Multi-lingual command responders should take the approach that object 724 instances whose type is Counter64 are implicitly excluded from view 725 when processing an SNMPv1 message. So: 727 - On an SNMPv1 GET request, we return an error-status of 728 noSuchName and the error-index is set to the variable binding 729 that causes this error. 731 - On an SNMPv1 GETNEXT request, we skip the object instance and 732 fetch the next object instance that follows the one with a 733 syntax of Counter64. 735 - Any SET request that has a variable binding with a Counter64 736 value must have come from a SNMPv2 manager, and so it should 737 not cause a problem. If we do receive a Counter64 value in an 738 SNMPv1 SET packet, it should result in an ASN.1 parse error 739 since Counter64 is not valid in the SNMPv1 protocol. When an 740 ASN.1 parse error occurs, the counter snmpInASNParseErrs is 741 incremented and no response is returned. 743 6.2. Mapping SNMPv2 Exceptions 745 SNMPv2 provides a feature called exceptions, which allow an SNMPv2 746 Response PDU to return as much management information as possible, 747 even when an error occurs. However, SNMPv1 does not support 748 exceptions, and so an SNMPv1 Response PDU cannot return any 749 management information, and can only return an error-status and 750 error-index value. 752 When an SNMPv1 request is received, a command responder must check 753 any variable bindings returned from SNMPv2 compliant instrumentation 754 for exception values, and convert these exception values into SNMPv1 755 error codes. 757 The type of exception that can be returned from instrumentation and 758 the action taken depends on the type of SNMP request. 760 - For a GetRequest, a noSuchObject or noSuchInstance exception 761 may be returned. 763 - For a GetNextRequest, an endOfMibView exception may be 764 returned. 766 - No exceptions will be returned for a SetRequest, and a 767 GetBulkRequest should only be received in an SNMPv2c or SNMPv3 768 message, so these request types may be ignored when mapping 769 exceptions. 771 6.2.1. Mapping nosuchObject and noSuchInstance 773 A noSuchObject or noSuchInstance exception generated by SNMPv2 774 compliant instrumentation indicates that the requested object 775 instance can not be returned. The SNMPv1 error code for this 776 condition is noSuchName, and so the error-status field of the 777 response PDU should be set to noSuchName. Also, the error-index 778 field is set to the index of the variable binding for which an 779 exception occurred, and the variable binding list from the original 780 request is returned with the response PDU. 782 Note that when a response contains multiple exceptions, it is an 783 implementation choice as to which variable binding the error-index 784 should reference. 786 6.2.2. Mapping endOfMibView 788 When SNMPv2 compliant instrumentation returns a variable binding 789 containing an endOfMibView exception, it indicates that there are no 790 object instances available which lexicographically follow the object 791 in the request. In an SNMPv1 agent, this condition normally results 792 in a noSuchName error, and so the error-status field of the response 793 PDU should be set to noSuchName. Also, the error- index field is set 794 to the index of the variable binding for which an exception occurred, 795 and the variable binding list from the original request is returned 796 with the response PDU. 798 Note that when a response contains multiple exceptions, it is an 799 implementation choice as to which variable binding the error-index 800 should reference. 802 6.3. Processing An SNMPv1 GetRequest 804 When processing an SNMPv1 GetRequest, the following procedures should 805 be followed when calling SNMPv2 MIB instrumentation. 807 When such instrumentation returns response data using SNMPv2 syntax 808 and error-status values, then: 810 (1) If the error-status is anything other than noError, 812 - The error status is translated to an SNMPv1 error-status using 813 the table in section 7, "Mapping SNMPv2 error-status into 814 SNMPv1 error-status" 816 - The error-index is set to the position (in the original 817 request) of the variable binding that caused the error-status. 819 - The variable binding list of the response PDU is made exactly 820 the same as the variable binding list that was received in the 821 original request. 823 (2) If the error-status is noError, then find any variable binding that 824 contains an SNMPv2 exception (noSuchObject or noSuchInstance) or an 825 SNMPv2 syntax that is unknown to SNMPv1 (Counter64). (Note that if 826 there are more than one, the agent may choose any such variable 827 binding.) If there are any such variable bindings, then for the 828 one chosen: 830 - Set the error-status to noSuchName 832 - Set the error-index to the position (in the variable binding 833 list of the original request) of the variable binding that 834 returned such an SNMPv2 exception or syntax. 836 - Make the variable binding list of the response PDU exactly the 837 same as the variable binding list that was received in the 838 original request. 840 (3) If there are no such variable bindings, then: 842 - Set the error-status to noError 844 - Set the error-index to zero 846 - Compose the variable binding list of the response, using the 847 data as it is returned by the instrumentation code. 849 6.4. Processing An SNMPv1 GetNextRequest 851 When processing an SNMPv1 GetNextRequest, the following procedures 852 should be followed when SNMPv2 MIB instrumentation is called as part 853 of processing the request. There may be repetitive calls to 854 (possibly different pieces of) instrumentation code to try to find 855 the first object which lexicographically follows each of the objects 856 in the request. This is implementation specific. These procedures 857 are followed only for data returned from SNMPv2 instrumentation. 858 Data returned from SNMPv1 instrumentation may be treated in the 859 normal manner for an SNMPv1 request. 861 First, if the instrumentation returns an error-status of anything 862 other than noError: 864 (1) The error status is translated to an SNMPv1 error-status using the 865 table in section 7, "Mapping SNMPv2 error-status into SNMPv1 866 error-status" 868 (2) The error-index is set to the position (in the original request) of 869 the variable binding that caused the error-status. 871 (3) The variable binding list of the response PDU is made exactly the 872 same as the variable binding list that was received in the original 873 request. 875 Otherwise, if the instrumentation returns an error-status of noError: 877 (1) If there are any variable bindings containing an SNMPv2 syntax of 878 Counter64, then consider these variable bindings to be not in view 879 and repeat the call to the instrumentation code as often as needed 880 until a value other than Counter64 is returned. 882 (2) Find any variable binding that contains an SNMPv2 exception 883 endOfMibView. (Note that if there are more than one, the agent may 884 choose any such variable binding.) If there are any such variable 885 bindings, then for the one chosen: 887 - Set the error-status to noSuchName 889 - Set the error-index to the position (in the variable binding 890 list of the original request) of the variable binding that 891 returned such an SNMPv2 exception. 893 - Make the variable binding list of the response PDU exactly the 894 same as the variable binding list that was received in the 895 original request. 897 (3) If there are no such variable bindings, then: 899 - Set the error-status to noError 901 - Set the error-index to zero 903 - Compose the variable binding list of the response, using the 904 data as it is returned by the instrumentation code. 906 7. Error Status Mappings 908 The following table shows the mappings of SNMPv2 error-status values 909 into SNMPv1 error-status values. 911 SNMPv2 error-status SNMPv1 error-status 912 =================== =================== 913 noError noError 914 tooBig tooBig 915 noSuchName noSuchName 916 badValue badValue 917 readOnly readOnly 918 genErr genErr 919 wrongValue badValue 920 wrongEncoding badValue 921 wrongType badValue 922 wrongLength badValue 923 inconsistentValue badValue 924 noAccess noSuchName 925 notWritable noSuchName 926 noCreation noSuchName 927 inconsistentName noSuchName 928 resourceUnavailable genErr 929 commitFailed genErr 930 undoFailed genErr 931 authorizationError noSuchName 933 8. Message Processing Models and Security Models 935 In order to adapt SNMPv1 and SNMPv2c into the SNMPv3 architecture, four 936 additional models must be defined: 938 - The SNMPv1 Message Processing Model 940 - The SNMPv2c Message Processing Model 942 - The SNMPv1 Community-Based Security Model 944 - The SNMPv2c Community-Based Security Model 946 In most respects, the SNMPv1 Message Processing Model and the 947 SNMPv2c Message Processing Model are identical, and so these 948 are not discussed independently in this document. Differences 949 between the two models are described as required. 951 Similarly, the SNMPv1 Community-Based Security Model and the 952 SNMPv2c Community-Based Security Model are nearly identical, 953 and so are not discussed independently. Differences between 954 these two models are also described as required. 956 8.1. Mappings 958 The SNMPv1 and SNMPv2c Message Processing Models and Security Models 959 require mappings between parameters used in SNMPv1 and SNMPv2c messages, 960 and those use in SNMPv3 messages. The parameters which must be mapped 961 consist of the SNMPv1 and SNMPv2c community name, and the SNMPv3 962 securityName and contextEngineID/contextName pair. A MIB module (the 963 SNMP-COMMUNITY-MIB) is provided in this document in order to perform 964 these mappings. This MIB provides mappings in both directions, that is, 965 a community name may be mapped to a securityName, contextEngineID, and 966 contextName, or the combination of securityName, contextEngineID, and 967 contextName may be mapped to a community name. 969 8.2. Elements Of Procedure 971 The following sections describe the procedures for processing various 972 types of SNMPv1 and SNMPv2c messages. 974 8.2.1. Processing An Incoming Request 976 8.2.2. Processing An Outgoing Response 978 8.2.3. Processing An Incoming Notification 980 8.2.4. Processing An Outgoing Notification 982 8.3. Community MIB 984 SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN 986 IMPORTS 987 MODULE-IDENTITY, 988 OBJECT-TYPE, 989 Integer32, 990 Counter32, 991 UInteger32 992 FROM SNMPv2-SMI 993 RowStatus, 994 TestAndIncr, 995 StorageType 996 FROM SNMPv2-TC 997 SnmpAdminString 998 FROM SNMP-FRAMEWORK-MIB 999 SnmpTagValue 1000 FROM SNMP-TARGET-MIB 1001 MODULE-COMPLIANCE, 1002 OBJECT-GROUP 1003 FROM SNMPv2-CONF; 1005 snmpCommunityMIB MODULE-IDENTITY 1006 LAST-UPDATED "9805110000Z" -- 11 May 1998, midnight 1007 ORGANIZATION "SNMPv3 Working Group" 1008 CONTACT-INFO "WG-email: snmpv3@tis.com 1009 Subscribe: majordomo@tis.com 1010 In msg body: subscribe snmpv3 1012 Chair: Russ Mundy 1013 Trusted Information Systems 1014 postal: 3060 Washington Rd 1015 Glenwood MD 21738 1016 USA 1017 email: mundy@tis.com 1018 phone: +1-301-854-6889 1019 Co-editor: Rob Frye 1020 MCI Communications Corp. 1021 Postal: 2100 Reston Parkway, Suite 600 1022 Reston, VA 20191 1023 USA 1024 E-mail: Rob.Frye@mci.com 1025 Phone: +1 703 715 7225 1027 Co-editor: David B. Levi 1028 SNMP Research, Inc. 1029 Postal: 3001 Kimberlin Heights Road 1030 Knoxville, TN 37920-9716 1031 E-mail: levi@snmp.com 1032 Phone: +1 423 573 1434 1034 Co-editor: Bert Wijnen 1035 IBM T. J. Watson Research 1036 postal: Schagen 33 1037 3461 GL Linschoten 1038 Netherlands 1039 email: wijnen@vnet.ibm.com 1040 phone: +31-348-432-794 1041 " 1043 DESCRIPTION 1044 "This MIB module defines objects to help support coexistence 1045 between SNMPv1, SNMPv2, and SNMPv3." 1046 ::= { snmpModules xxx } -- get assignment from IANA 1048 -- Administrative assignments **************************************** 1050 snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 } 1051 snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 } 1053 -- 1054 -- The snmpCommunityTable contains a database of community strings. 1055 -- This table provides mappings between community strings, and the 1056 -- parameters required for View-based Access Control. 1057 -- 1059 snmpCommunityTable OBJECT-TYPE 1060 SYNTAX SEQUENCE OF SnmpCommunityEntry 1061 MAX-ACCESS not-accessible 1062 STATUS current 1063 DESCRIPTION 1064 "The table of community strings configured in the SNMP 1065 engine's Local Configuration Datastore (LCD)." 1067 ::= { snmpCommunityMIBObjects 1 } 1069 snmpCommunityEntry OBJECT-TYPE 1070 SYNTAX SnmpCommunityEntry 1071 MAX-ACCESS not-accessible 1072 STATUS current 1073 DESCRIPTION 1074 "Information about a particular community string." 1075 INDEX { snmpCommunityIndex } 1076 ::= { snmpCommunityTable 1 } 1078 SnmpCommunityEntry ::= SEQUENCE { 1079 snmpCommunityIndex Integer32, 1080 snmpCommunityName OCTET STRING, 1081 snmpCommunitySecurityName SnmpAdminString, 1082 snmpCommunityContextEngineID SnmpEngineID, 1083 snmpCommunityContextName SnmpAdminString, 1084 snmpCommunityTransportTag SnmpTagValue, 1085 snmpCommunityStorageType StorageType, 1086 snmpCommunityStatus RowStatus 1087 } 1089 snmpCommunityIndex OBJECT-TYPE 1090 SYNTAX Integer32 1091 MAX-ACCESS not-accessible 1092 STATUS current 1093 DESCRIPTION 1094 "The unique index value of a row in this table." 1095 ::= { snmpCommunityEntry 1 } 1097 snmpCommunityName OBJECT-TYPE 1098 SYNTAX OCTET STRING (SIZE(1..64)) 1099 MAX-ACCESS read-create 1100 STATUS current 1101 DESCRIPTION 1102 "The community string for which a row in this table 1103 represents a configuration." 1104 ::= { snmpCommunityEntry 2 } 1106 snmpCommunitySecurityName OBJECT-TYPE 1107 SYNTAX SnmpAdminString 1108 MAX-ACCESS read-create 1109 STATUS current 1110 DESCRIPTION 1111 "A human readable string representing the corresponding 1112 value of snmpCommunityName in a Security Model 1113 independent format." 1115 ::= { snmpCommunityEntry 3 } 1117 snmpCommunityContextEngineID OBJECT-TYPE 1118 SYNTAX SnmpEngineID 1119 MAX-ACCESS read-create 1120 STATUS current 1121 DESCRIPTION 1122 "The contextEngineID indicating the location of the 1123 context in which management information is accessed 1124 when using the community string specified by the 1125 corresponding instance of snmpCommunityName. 1127 The default value is the snmpEngineID of the entity in 1128 which this object is instantiated." 1129 ::= { snmpCommunityEntry 4 } 1131 snmpCommunityContextName OBJECT-TYPE 1132 SYNTAX SnmpAdminString 1133 MAX-ACCESS read-create 1134 STATUS current 1135 DESCRIPTION 1136 "The context in which management information is accessed 1137 when using the community string specified by the corresponding 1138 instance of snmpCommunityName." 1139 DEFVAL { ''H } -- the empty string 1140 ::= { snmpCommunityEntry 5 } 1142 -- Comments on TransportTag 1143 -- based on this tag we can limit the use of an entry to a defined 1144 -- set of transport end-points. Maybe we want to augemnt the 1145 -- snmpTargetAddrTable to also contain a snmpTargetAddrTMask 1146 -- of type TAddress which we can use as a mask. 1147 -- Opinions are welcome. 1149 snmpCommunityTransportTag OBJECT-TYPE 1150 SYNTAX SnmpTagValue 1151 MAX-ACCESS read-create 1152 STATUS current 1153 DESCRIPTION 1154 "This object specifies a set of transport endpoints 1155 from which an agent will accept management requests. 1156 If a management request containing this community 1157 is received on a transport endpoint other than the 1158 transport endpoints identified by this object, the 1159 request is deemed unauthentic. 1161 The transports identified by this object are specified 1162 in the snmpTargteAddrTable. Entries in that table 1163 whose snmpTargetAddrTagList contains this tag value 1164 are identified. 1166 If the value of this object has zero-length, transport 1167 endpoints are not checked when authenticating messages 1168 containing this community string." 1169 DEFVAL { ''H } -- the empty string 1170 ::= { snmpCommunityEntry 6 } 1172 snmpCommunityStorageType OBJECT-TYPE 1173 SYNTAX StorageType 1174 MAX-ACCESS read-create 1175 STATUS current 1176 DESCRIPTION 1177 "The storage type for this conceptual row in the 1178 snmpCommunityTable. Conceptual rows having the value 1179 'permanent' need not allow write-access to any 1180 columnar object in the row." 1181 ::= { snmpCommunityEntry 7 } 1183 snmpCommunityStatus OBJECT-TYPE 1184 SYNTAX RowStatus 1185 MAX-ACCESS read-create 1186 STATUS current 1187 DESCRIPTION 1188 "The status of this conceptual row in the snmpCommunityTable. 1190 An entry in this table is not qualified for activation 1191 until instances of all corresponding columns have been 1192 initialized, either through default values, or through 1193 Set operations. The snmpCommunityName and 1194 snmpCommunitySecurityName objects must be explicitly set." 1195 ::= { snmpCommunityEntry 8 } 1197 -- Conformance Information ******************************************* 1199 snmpCommunityMIBCompliances OBJECT IDENTIFIER 1200 ::= { snmpCommunityMIBConformance 1 } 1201 snmpCommunityMIBGroups OBJECT IDENTIFIER 1202 ::= { snmpCommunityMIBConformance 2 } 1204 -- Compliance statements 1206 snmpCommunityMIBCompliance MODULE-COMPLIANCE 1207 STATUS current 1208 DESCRIPTION 1209 "The compliance statement for SNMP engines which 1210 implement the SNMP-COMMUNITY-MIB." 1212 MODULE -- this module 1213 MANDATORY-GROUPS { snmpCommunityGroup } 1215 OBJECT snmpCommunityName 1216 MIN-ACCESS read-only 1217 DESCRIPTION "Write access is not required." 1219 OBJECT snmpCommunitySecurityName 1220 MIN-ACCESS read-only 1221 DESCRIPTION "Write access is not required." 1223 OBJECT snmpCommunitySecurityLevel 1224 MIN-ACCESS read-only 1225 DESCRIPTION "Write access is not required." 1227 OBJECT snmpCommunityContextEngineID 1228 MIN-ACCESS read-only 1229 DESCRIPTION "Write access is not required." 1231 OBJECT snmpCommunityContextName 1232 MIN-ACCESS read-only 1233 DESCRIPTION "Write access is not required." 1235 OBJECT snmpCommunityTransportLabel 1236 MIN-ACCESS read-only 1237 DESCRIPTION "Write access is not required." 1239 OBJECT snmpCommunityStorageType 1240 MIN-ACCESS read-only 1241 DESCRIPTION "Write access is not required." 1243 OBJECT snmpCommunityStatus 1244 MIN-ACCESS read-only 1245 DESCRIPTION "Write access is not required." 1247 ::= { usmMIBCompliances 1 } 1249 snmpCommunityGroup OBJECT-GROUP 1250 OBJECTS { 1251 snmpCommunityIndex, 1252 snmpCommunityName, 1253 snmpCommunitySecurityName, 1254 snmpCommunityContextEngineID, 1255 snmpCommunityContextName, 1256 snmpCommunityTransportLabel, 1257 snmpCommunityStorageType, 1258 snmpCommunityStatus 1259 } 1260 STATUS current 1261 DESCRIPTION 1262 "A collection of objects providing for configuration 1263 of community strings for SNMPv1 or SNMPv2c usage." 1264 ::= { snmpCommunityMIBGroups 1 } 1266 END 1268 9. Intellectual Property 1270 The IETF takes no position regarding the validity or scope of any 1271 intellectual property or other rights that might be claimed to 1272 pertain to the implementation or use of the technology described in 1273 this document or the extent to which any license under such rights 1274 might or might not be available; neither does it represent that it 1275 has made any effort to identify any such rights. Information on the 1276 IETF's procedures with respect to rights in standards-track and 1277 standards-related documentation can be found in BCP-11. Copies of 1278 claims of rights made available for publication and any assurances of 1279 licenses to be made available, or the result of an attempt made to 1280 obtain a general license or permission for the use of such 1281 proprietary rights by implementors or users of this specification can 1282 be obtained from the IETF Secretariat. 1284 The IETF invites any interested party to bring to its attention any 1285 copyrights, patents or patent applications, or other proprietary 1286 rights which may cover technology that may be required to practice 1287 this standard. Please address the information to the IETF Executive 1288 Director. 1290 10. Acknowledgments 1292 This document is the result of the efforts of the SNMPv3 Working 1293 Group. Some special thanks are in order to the following SNMPv3 WG 1294 members: 1296 Dave Battle (SNMP Research, Inc.) 1297 Uri Blumenthal (IBM T.J. Watson Research Center) 1298 Jeff Case (SNMP Research, Inc.) 1299 John Curran (BBN) 1300 T. Max Devlin (Hi-TECH Connections) 1301 John Flick (Hewlett Packard) 1302 David Harrington (Cabletron Systems Inc.) 1303 N.C. Hien (IBM T.J. Watson Research Center) 1304 Dave Levi (SNMP Research, Inc.) 1305 Louis A Mamakos (UUNET Technologies Inc.) 1306 Paul Meyer (Secure Computing Corporation) 1307 Keith McCloghrie (Cisco Systems) 1308 Russ Mundy (Trusted Information Systems, Inc.) 1309 Bob Natale (ACE*COMM Corporation) 1310 Mike O'Dell (UUNET Technologies Inc.) 1311 Dave Perkins (DeskTalk) 1312 Peter Polkinghorne (Brunel University) 1313 Randy Presuhn (BMC Software, Inc.) 1314 David Reid (SNMP Research, Inc.) 1315 Shawn Routhier (Epilogue) 1316 Juergen Schoenwaelder (TU Braunschweig) 1317 Bob Stewart (Cisco Systems) 1318 Bert Wijnen (IBM T.J. Watson Research Center) 1320 The document is based on recommendations of the IETF Security and 1321 Administrative Framework Evolution for SNMP Advisory Team. Members of 1322 that Advisory Team were: 1324 David Harrington (Cabletron Systems Inc.) 1325 Jeff Johnson (Cisco Systems) 1326 David Levi (SNMP Research Inc.) 1327 John Linn (Openvision) 1328 Russ Mundy (Trusted Information Systems) chair 1329 Shawn Routhier (Epilogue) 1330 Glenn Waters (Nortel) 1331 Bert Wijnen (IBM T. J. Watson Research Center) 1333 As recommended by the Advisory Team and the SNMPv3 Working Group 1334 Charter, the design incorporates as much as practical from previous 1335 RFCs and drafts. As a result, special thanks are due to the authors 1336 of previous designs known as SNMPv2u and SNMPv2*: 1338 Jeff Case (SNMP Research, Inc.) 1339 David Harrington (Cabletron Systems Inc.) 1340 David Levi (SNMP Research, Inc.) 1341 Keith McCloghrie (Cisco Systems) 1342 Brian O'Keefe (Hewlett Packard) 1343 Marshall T. Rose (Dover Beach Consulting) 1344 Jon Saperia (BGS Systems Inc.) 1345 Steve Waldbusser (International Network Services) 1346 Glenn W. Waters (Bell-Northern Research Ltd.) 1348 11. Security Considerations 1350 Although SNMPv1 and SNMPv2 do not provide any security, allowing 1351 community names to be mapped into securityName/contextName provides 1352 the ability to use view-based access control to limit the access of 1353 unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for 1354 network administrators to make use of this capability in order to 1355 avoid unauthorized access to MIB data that would otherwise be secure. 1357 12. References 1359 [RFC1155] 1360 Rose, M. and K. McCloghrie, "Structure and Identification of 1361 Management Information for TCP/IP-based internets"", STD16, RFC 1362 1155, May 1990. 1364 [RFC1157] 1365 Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1366 Management Protocol", STD15, RFC 1157, SNMP Research, Performance 1367 Systems International, Performance Systems International, MIT 1368 Laboratory for Computer Science, May 1990. 1370 [RFC1212] 1371 McCloghrie, K., and M. Rose, Editors, "Concise MIB Definitions.nr 1372 _F 1 q, STD 16, RFC 1212, Hughes LAN Systems, Performance Systems 1373 International, March 1991. 1375 [RFC1213] 1376 McCloghrie, K., and M. Rose, Editors, "Management Information Base 1377 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 1378 RFC 1213, Hughes LAN Systems, Performance Systems International, 1379 March 1991. 1381 [RFC1901] 1382 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1383 Waldbusser, "Introduction to Community-based SNMPv2", RFC1902, SNMP 1384 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1385 International Network Services, January 1996. 1387 [RFC1902] 1388 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1389 Waldbusser, "Structure of Management Information for Version 2 of 1390 the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP 1391 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1392 International Network Services, January 1996. 1394 [RFC1903] 1395 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1396 Waldbusser, "Textual Conventions for Version 2 of the Simple 1397 Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc., 1398 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 1399 Network Services, January 1996. 1401 [RFC1905] 1402 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1403 Waldbusser, "Protocol Operations for Version 2 of the Simple 1404 Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., 1405 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 1406 Network Services, January 1996. 1408 [RFC1907] 1409 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1410 Waldbusser, "Management Information Base for Version 2 of the 1411 Simple Network Management Protocol (SNMPv2)", RFC1905, SNMP 1412 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1413 International Network Services, January 1996. 1415 [RFC1908] 1416 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1417 Waldbusser, "Coexistence between Version 1 and Version 2 of the 1418 Internet-standard Network Management Framework", RFC1905, SNMP 1419 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1420 International Network Services, January 1996. 1422 [RFC2271] 1423 The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An 1424 Architecture for Describing SNMP Management Frameworks", RFC2271, 1425 January 1998. 1427 [RFC2272] 1428 The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B., 1429 "Message Processing and Dispatching for the Simple Network 1430 Management Protocol (SNMP)", RFC2272, January 1998. 1432 [RFC2273] 1433 The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMPv3 1434 Applications", RFC2273, January 1998. 1436 [RFC2274] 1437 The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User- 1438 Based Security Model for Version 3 of the Simple Network Management 1439 Protocol (SNMP)", RFC2274, January 1998. 1441 [RFC2275] 1442 The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K., 1443 "View-based Access Control Model for the Simple Network Management 1444 Protocol (SNMP)", RFC2275, January 1998. 1446 13. Editor's Address 1448 Rob Frye 1449 MCI Communications Corp. 1450 2100 Reston Parkway, Suite 600 1451 Reston, VA 20191 1452 U.S.A. 1453 Phone: +1 703 715 7225 1454 EMail: Rob.Frye@mci.com 1456 David B. Levi 1457 SNMP Research, Inc. 1458 3001 Kimberlin Heights Road 1459 Knoxville, TN 37920-9716 1460 U.S.A. 1461 Phone: +1 423 573 1434 1462 EMail: levi@snmp.com 1464 Bert Wijnen 1465 IBM T. J. Watson Research 1466 Schagen 33 1467 3461 GL Linschoten 1468 Netherlands 1469 Phone: +31 348 432 794 1470 EMail: wijnen@vnet.ibm.com 1472 A. Full Copyright Statement 1474 This document and translations of it may be copied and furnished to 1475 others, and derivative works that comment on or otherwise explain it 1476 or assist in its implementation may be prepared, copied, published 1477 and distributed, in whole or in part, without restriction of any 1478 kind, provided that the above copyright notice and this paragraph are 1479 included on all such copies and derivative works. However, this 1480 document itself may not be modified in any way, such as by removing 1481 the copyright notice or references to the Internet Society or other 1482 Internet organizations, except as needed for the purpose of 1483 developing Internet standards in which case the procedures for 1484 copyrights defined in the Internet Standards process must be 1485 followed, or as required to translate it into languages other than 1486 English. 1488 The limited permissions granted above are perpetual and will not be 1489 revoked by the Internet Society or its successors or assigns. 1491 This document and the information contained herein is provided on an 1492 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1493 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1494 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1495 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1496 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.