idnits 2.17.1 draft-ietf-snmpv3-coex-07.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 51 pages 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 11 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([13], [14]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document obsoletes RFC1908, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 61 has weird spacing: '...ameters to S...' == Line 63 has weird spacing: '...ameters to S...' == Line 546 has weird spacing: '...rameter snmp...' == Line 1140 has weird spacing: '...ailable gen...' == Line 2012 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 (10 Jan 2000) is 8871 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) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 1303 (ref. '5') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '6') ** Obsolete normative reference: RFC 1905 (ref. '10') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (ref. '11') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1907 (ref. '12') (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1908 (ref. '13') (Obsoleted by RFC 2576) ** Obsolete normative reference: RFC 2089 (ref. '14') (Obsoleted by RFC 2576) ** Obsolete normative reference: RFC 2571 (ref. '16') (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 2572 (ref. '17') (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2573 (ref. '18') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2574 (ref. '19') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2575 (ref. '20') (Obsoleted by RFC 3415) Summary: 20 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Rob Frye 2 CoSine Communications 3 David B. Levi 4 Nortel Networks 5 Shawn A. Routhier 6 Integrated Systems Inc. 7 Bert Wijnen 8 IBM T.J. Watson Research 9 10 Jan 2000 11 Coexistence between Version 1, Version 2, and Version 3 12 of the Internet-standard Network Management Framework 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 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 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The Internet Society (1999). 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 (SNMPv3), version 2 of the Internet-standard Network Management 43 Framework (SNMPv2), and the original Internet-standard Network 44 Management Framework (SNMPv1). This document obsoletes RFC 1908 [13] 45 and RFC2089 [14]. 47 Table Of Contents 49 1 Overview ..................................................... 4 50 1.1 SNMPv1 ..................................................... 4 51 1.2 SNMPv2 ..................................................... 5 52 1.3 SNMPv3 ..................................................... 6 53 1.4 SNMPv1 and SNMPv2 Access to MIB Data ....................... 6 54 2 SMI and Management Information Mappings ...................... 8 55 2.1 MIB Modules ................................................ 8 56 2.1.1 Object Definitions ....................................... 8 57 2.1.2 Trap and Notification Definitions ........................ 11 58 2.2 Compliance Statements ...................................... 12 59 2.3 Capabilities Statements .................................... 12 60 3 Translating Notifications Parameters ......................... 13 61 3.1 Translating SNMPv1 Notification Parameters to SNMPv2 62 Notification Parameters ................................... 14 63 3.2 Translating SNMPv2 Notification Parameters to SNMPv1 64 Notification Parameters ................................... 15 65 4 Approaches to Coexistence in a Multi-lingual Network ......... 18 66 4.1 Multi-lingual implementations .............................. 18 67 4.1.1 Command Generator ........................................ 18 68 4.1.2 Command Responder ........................................ 19 69 4.1.2.1 Handling Counter64 ..................................... 19 70 4.1.2.2 Mapping SNMPv2 Exceptions .............................. 20 71 4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 21 72 4.1.2.2.2 Mapping endOfMibView ................................. 21 73 4.1.2.3 Processing An SNMPv1 GetRequest ........................ 21 74 4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 22 75 4.1.2.5 Processing An SNMPv1 SetRequest ........................ 24 76 4.1.3 Notification Originator .................................. 24 77 4.1.4 Notification Receiver .................................... 25 78 4.2 Proxy Implementations ...................................... 25 79 4.2.1 Upstream Version Greater Than Downstream Version ......... 25 80 4.2.2 Upstream Version Less Than Downstream Version ............ 26 81 4.3 Error Status Mappings ...................................... 28 82 5 Message Processing Models and Security Models ................ 30 83 5.1 Mappings ................................................... 30 84 5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security 85 Model ..................................................... 30 86 5.2.1 Processing An Incoming Request ........................... 31 87 5.2.2 Generating An Outgoing Response .......................... 33 88 5.2.3 Generating An Outgoing Notification ...................... 33 89 5.3 The SNMP Community MIB Module .............................. 34 90 6 Intellectual Property ........................................ 45 91 7 Acknowledgments .............................................. 46 92 8 Security Considerations ...................................... 47 93 9 References ................................................... 48 94 10 Editor's Addresses .......................................... 50 95 A. Full Copyright Statement .................................... 51 97 1. Overview 99 The purpose of this document is to describe coexistence between 100 version 3 of the Internet-standard Network Management Framework, 101 termed the SNMP version 3 framework (SNMPv3), version 2 of the 102 Internet-standard Network Management Framework, termed the SNMP 103 version 2 framework (SNMPv2), and the original Internet-standard 104 Network Management Framework (SNMPv1). 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC2119 [15]. 110 There are four general aspects of coexistence described in this 111 document. Each of these is described in a separate section: 113 - Conversion of MIB documents between SMIv1 and SMIv2 formats is 114 documented in section 2. 116 - Mapping of notification parameters is documented in section 3. 118 - Approaches to coexistence between entities which support the 119 various versions of SNMP in a multi-lingual network is 120 documented in section 4. This section addresses the 121 processing of protocol operations in multi-lingual 122 implementations, as well as behaviour of proxy 123 implementations. 125 - The SNMPv1 Message Processing Model and Community-Based 126 Security Model, which provides mechanisms for adapting SNMPv1 127 into the View-Based Access Control Model (VACM) [20], is 128 documented in section 5 (this section also addresses the 129 SNMPv2c Message Processing Model and Community-Based Security 130 Model). 132 1.1. SNMPv1 134 SNMPv1 is defined by these documents: 136 - STD 15, RFC 1157 [2] which defines the Simple Network 137 Management Protocol (SNMPv1), the protocol used for network 138 access to managed objects. 140 - STD 16, RFC 1155 [1] which defines the Structure of Management 141 Information (SMIv1), the mechanisms used for describing and 142 naming objects for the purpose of management. 144 - STD 16, RFC 1212 [3] which defines a more concise description 145 mechanism, which is wholly consistent with the SMIv1. 147 - RFC 1215 [4] which defines a convention for defining Traps for 148 use with the SMIv1. 150 Note that throughout this document, the term 'SMIv1' is used. This 151 term generally refers to the information presented in RFC 1155, RFC 152 1212, and RFC 1215. 154 1.2. SNMPv2 156 SNMPv2 is defined by these documents: 158 - STD 58, RFC 2578 which defines Version 2 of the Structure of 159 Management Information (SMIv2) [7]. 161 - STD 58, RFC 2579 which defines common MIB "Textual 162 Conventions" [8]. 164 - STD 58, RFC 2580 which defines Conformance Statements and 165 requirements for defining agent and manager capabilities [9]. 167 - RFC 1905 which defines the Protocol Operations used in 168 processing [10]. 170 - RFC 1906 which defines the Transport Mappings used "on the 171 wire" [11]. 173 - RFC 1907 which defines the basic Management Information Base 174 for monitoring and controlling some basic common functions of 175 SNMP entities [12]. 177 Note that SMIv2 as used throughout this document refers to the first 178 three documents listed above (RFCs 2578, 2579, and 2580). 180 The following document augments the definition of SNMPv2: 182 - RFC 1901 [6] is an Experimental definition for using SNMPv2 183 PDUs within a community-based message wrapper. This is 184 referred to throughout this document as SNMPv2c. 186 1.3. SNMPv3 188 SNMPv3 is defined by these documents: 190 - RFC 2571 which defines an Architecture for Describing SNMP 191 Management Frameworks [16]. 193 - RFC 2572 which defines Message Processing and Dispatching 194 [17]. 196 - RFC 2573 which defines various SNMP Applications [18]. 198 - RFC 2574 which defines the User-based Security Model (USM), 199 providing for both Authenticated and Private (encrypted) SNMP 200 messages [19]. 202 - RFC 2575 which defines the View-based Access Control Model 203 (VACM), providing the ability to limit access to different MIB 204 objects on a per-user basis [20]. 206 SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 and 207 the SMIv2 definitions of 2578 through 2580 described above. 209 1.4. SNMPv1 and SNMPv2 Access to MIB Data 211 In several places, this document refers to 'SNMPv1 Access to MIB 212 Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the part 213 of an SNMP agent which actually accesses instances of MIB objects, 214 and which actually initiates generation of notifications. 215 Differences between the two types of access to MIB data are: 217 - Error-status values generated. 219 - Generation of exception codes. 221 - Use of the Counter64 data type. 223 - The format of parameters provided when a notification is 224 generated. 226 SNMPv1 access to MIB data may generate SNMPv1 error-status values, 227 will never generate exception codes nor use the Counter64 data type, 228 and will provide SNMPv1 format parameters for generating 229 notifications. Note also that SNMPv1 access to MIB data will 230 actually never generate a readOnly error (a noSuchName error would 231 always occur in the situation where one would expect a readOnly 232 error). 234 SNMPv2 access to MIB data may generate SNMPv2 error-status values, 235 may generate exception codes, may use the Counter64 data type, and 236 will provide SNMPv2 format parameters for generating notifications. 237 Note that SNMPv2 access to MIB data will never generate readOnly, 238 noSuchName, or badValue errors. 240 Note that a particular multi-lingual implementation may choose to 241 implement all access to MIB data as SNMPv2 access to MIB data, and 242 perform the translations described herein for SNMPv1-based 243 transactions. 245 2. SMI and Management Information Mappings 247 The SMIv2 approach towards describing collections of managed objects 248 is nearly a proper superset of the approach defined in the SMIv1. 249 For example, both approaches use an adapted subset of ASN.1 (1988) 250 [11] as the basis for a formal descriptive notation. Indeed, one 251 might note that the SMIv2 approach largely codifies the existing 252 practice for defining MIB modules, based on extensive experience with 253 the SMIv1. 255 The following sections consider the three areas: MIB modules, 256 compliance statements, and capabilities statements. 258 2.1. MIB Modules 260 MIB modules defined using the SMIv1 may continue to be used with 261 protocol versions which use SNMPv2 PDUs. However, for the MIB 262 modules to conform to the SMIv2, the following changes SHALL be made: 264 2.1.1. Object Definitions 266 In general, conversion of a MIB module does not require the 267 deprecation of the objects contained therein. If the definition of 268 an object is truly inadequate for its intended purpose, the object 269 SHALL be deprecated or obsoleted, otherwise deprecation is not 270 required. 272 (1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of 273 RFC1155-SMI and RFC-1212. 275 (2) The MODULE-IDENTITY macro MUST be invoked immediately after any 276 IMPORTs statement. 278 (3) For any object with an integer-valued SYNTAX clause, in which the 279 corresponding INTEGER does not have a range restriction (i.e., the 280 INTEGER has neither a defined set of named-number enumerations nor 281 an assignment of lower- and upper-bounds on its value), the object 282 MUST have the value of its SYNTAX clause changed to Integer32, or 283 have an appropriate range specified. 285 (4) For any object with a SYNTAX clause value of Counter, the object 286 MUST have the value of its SYNTAX clause changed to Counter32. 288 (5) For any object with a SYNTAX clause value of Gauge, the object MUST 289 have the value of its SYNTAX clause changed to Gauge32, or 290 Unsigned32 where appropriate. 292 (6) For all objects, the ACCESS clause MUST be replaced by a MAX-ACCESS 293 clause. The value of the MAX-ACCESS clause SHALL be the same as 294 that of the ACCESS clause unless some other value makes "protocol 295 sense" as the maximal level of access for the object. In 296 particular, object types for which instances can be explicitly 297 created by a protocol set operation, SHALL have a MAX-ACCESS clause 298 of "read-create". If the value of the ACCESS clause is "write- 299 only", then the value of the MAX-ACCESS clause MUST be "read- 300 write", and the DESCRIPTION clause SHALL note that reading this 301 object will result in implementation-specific results. Note that 302 in SMIv1, the ACCESS clause specifies the minimal required access, 303 while in SMIv2, the MAX-ACCESS clause specifies the maximum allowed 304 access. This should be considered when converting an ACCESS clause 305 to a MAX-ACCESS clause. 307 (7) For all objects, if the value of the STATUS clause is "mandatory" 308 or "optional", the value MUST be replaced with "current", 309 "deprecated", or "obsolete" depending on the current usage of such 310 objects. 312 (8) For any object not containing a DESCRIPTION clause, the object MUST 313 have a DESCRIPTION clause defined. 315 (9) For any object corresponding to a conceptual row which does not 316 have an INDEX clause, the object MUST have either an INDEX clause 317 or an AUGMENTS clause defined. 319 (10) If any INDEX clause contains a reference to an object with a syntax 320 of NetworkAddress, then a new object MUST be created and placed in 321 this INDEX clause immediately preceding the object whose syntax is 322 NetworkAddress. This new object MUST have a syntax of INTEGER, it 323 MUST be not-accessible, and its value MUST always be 1. This 324 approach allows one to convert a MIB module in SMIv1 format to one 325 in SMIv2 format, and then use it wih the SNMPv1 protocol with no 326 impact to existing SNMPv1 agents and managers. 328 (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be 329 changed to IpAddress. Note that the use of NetworkAddress in new 330 MIB documents is strongly discouraged (in fact, new MIB documents 331 should be written using SMIv2, which does not define 332 NetworkAddress). 334 (12) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER 335 value which is expressed as a collection of sub-identifiers, the 336 value MUST be changed to reference a single ASN.1 identifier. This 337 may require defining a series of new administrative assignments 338 (OBJECT IDENTIFIERS) in order to define the single ASN.1 339 identifier. 341 (13) One or more OBJECT-GROUPS MUST be defined, and related objects 342 SHOULD be collected into appropriate groups. Note that SMIv2 343 requires all OBJECT-TYPEs to be a member of at least one OBJECT- 344 GROUP. 346 Other changes are desirable, but not necessary: 348 (1) Creation and deletion of conceptual rows is inconsistent using the 349 SMIv1. The SMIv2 corrects this. As such, if the MIB module 350 undergoes review early in its lifetime, and it contains conceptual 351 tables which allow creation and deletion of conceptual rows, then 352 the objects relating to those tables MAY be deprecated and replaced 353 with objects defined using the new approach. The approach based on 354 SMIv2 can be found in section 7 of RFC2578 [7], and the RowStatus 355 and StorageType TEXTUAL-CONVENTIONs are described in section 2 of 356 RFC2579 [8]. 358 (2) For any object with a string-valued SYNTAX clause, in which the 359 corresponding OCTET STRING does not have a size restriction (i.e., 360 the OCTET STRING has no assignment of lower- and upper-bounds on 361 its length), the bounds for the size of the object SHOULD be 362 defined. 364 (3) All textual conventions informally defined in the MIB module SHOULD 365 be redefined using the TEXTUAL-CONVENTION macro. Such a change 366 would not necessitate deprecating objects previously defined using 367 an informal textual convention. 369 (4) For any object which represents a measurement in some kind of 370 units, a UNITS clause SHOULD be added to the definition of that 371 object. 373 (5) For any conceptual row which is an extension of another conceptual 374 row, i.e., for which subordinate columnar objects both exist and 375 are identified via the same semantics as the other conceptual row, 376 an AUGMENTS clause SHOULD be used in place of the INDEX clause for 377 the object corresponding to the conceptual row which is an 378 extension. 380 Finally, to avoid common errors in SMIv1 MIB modules: 382 (1) For any non-columnar object that is instanced as if it were 383 immediately subordinate to a conceptual row, the value of the 384 STATUS clause of that object MUST be changed to "obsolete". 386 (2) For any conceptual row object that is not contained immediately 387 subordinate to a conceptual table, the value of the STATUS clause 388 of that object (and all subordinate objects) MUST be changed to 389 "obsolete". 391 2.1.2. Trap and Notification Definitions 393 If a MIB module is changed to conform to the SMIv2, then each 394 occurrence of the TRAP-TYPE macro MUST be changed to a corresponding 395 invocation of the NOTIFICATION-TYPE macro: 397 (1) The IMPORTS statement MUST NOT reference RFC-1215 [4], and MUST 398 reference SNMPv2-SMI instead. 400 (2) The ENTERPRISE clause MUST be removed. 402 (3) The VARIABLES clause MUST be renamed to the OBJECTS clause. 404 (4) A STATUS clause MUST be added, with an appropriate value. Normally 405 the value should be 'current,' although 'deprecated' or 'obsolete' 406 may be used as needed. 408 (5) The value of an invocation of the NOTIFICATION-TYPE macro is an 409 OBJECT IDENTIFIER, not an INTEGER, and MUST be changed accordingly. 410 Specifically, if the value of the ENTERPRISE clause is not 'snmp' 411 then the value of the invocation SHALL be the value of the 412 ENTERPRISE clause extended with two sub-identifiers, the first of 413 which has the value 0, and the second has the value of the 414 invocation of the TRAP-TYPE. If the value of the ENTERPRISE clause 415 is 'snmp', then the value of the invocation of the NOTIFICATION- 416 TYPE macro SHALL be mapped in the same manner as described in 417 section 3.1 in this document. 419 (6) A DESCRIPTION clause MUST be added, if not already present. 421 (7) One or more NOTIFICATION-GROUPs MUST be defined, and related 422 notifications MUST be collected into those groups. Note that SMIv2 423 requires that all NOTIFICATION-TYPEs be a member of at least one 424 NOTIFICATION-GROUP. 426 2.2. Compliance Statements 428 For those information modules which are "standards track", a 429 corresponding invocation of the MODULE-COMPLIANCE macro and related 430 OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included within 431 the information module (or in a companion information module), and 432 any commentary text in the information module which relates to 433 compliance SHOULD be removed. Typically this editing can occur when 434 the information module undergoes review. 436 Note that a MODULE-COMPLIANCE statement is not required for a MIB 437 document that is not on the standards track (for example, an 438 enterprise MIB), though it may be useful in some circumstances to 439 define a MODULE-COMPLIANCE statement for such a MIB document. 441 2.3. Capabilities Statements 443 RFC1303 [5] uses the MODULE-CONFORMANCE macro to describe an agent's 444 capabilities with respect to one or more MIB modules. Converting 445 such a description for use with the SMIv2 requires these changes: 447 (1) The macro name AGENT-CAPABILITIES SHOULD be used instead of MODULE- 448 CONFORMANCE. 450 (2) The STATUS clause SHOULD be added, with a value of 'current'. 452 (3) All occurrences of the CREATION-REQUIRES clause MUST either be 453 omitted if appropriate, or be changed such that the semantics are 454 consistent with RFC2580 [9]. 456 In order to ease coexistence, object groups defined in an SMIv1 457 compliant MIB module may be referenced by the INCLUDES clause of an 458 invocation of the AGENT-CAPABILITIES macro: upon encountering a 459 reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB 460 module, all leaf objects which are subordinate to the subtree and 461 have a STATUS clause value of mandatory are deemed to be INCLUDEd. 462 (Note that this method is ambiguous when different revisions of an 463 SMIv1 MIB have different sets of mandatory objects under the same 464 subtree; in such cases, the only solution is to rewrite the MIB using 465 the SMIv2 in order to define the object groups unambiguously.) 467 3. Translating Notifications Parameters 469 This section describes how parameters used for generating 470 notifications are translated between the format used for SNMPv1 471 notification protocol operations and the format used for SNMPv2 472 notification protocol operations. The parameters used to generate a 473 notification are called 'notification parameters.' The format of 474 parameters used for SNMPv1 notification protocol operations is 475 refered to in this document as 'SNMPv1 notification parameters.' The 476 format of parameters used for SNMPv2 notification protocol operations 477 is refered to in this document as 'SNMPv2 notification parameters.' 479 The situations where notification parameters MUST be translated are: 481 - When an entity generates a set of notification parameters in a 482 particular format, and the configuration of the entity 483 indicates that the notification must be sent using an SNMP 484 message version that requires the other format for 485 notification parameters. 487 - When a proxy receives a notification that was sent using an 488 SNMP message version that requires one format of notification 489 parameters, and must forward the notification using an SNMP 490 message version that requires the other format of notification 491 parameters. 493 In addition, it MAY be desirable to translate notification parameters 494 in a notification receiver application in order to present 495 notifications to the end user in a consistent format. 497 Note that for the purposes of this section, the set of notification 498 parameters is independent of whether the notification is to be sent 499 as a trap or an inform. 501 SNMPv1 notification parameters consist of: 503 - An enterprise parameter (OBJECT IDENTIFIER). 505 - An agent-addr parameter (NetworkAddress). 507 - A generic-trap parameter (INTEGER). 509 - A specific-trap parameter (INTEGER). 511 - A time-stamp parameter (TimeTicks). 513 - A list of variable-bindings (VarBindList). 515 SNMPv2 notification parameters consist of: 517 - A sysUpTime parameter (TimeTicks). This appears in the first 518 variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU. 520 - An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in 521 the second variable-binding in an SNMPv2-Trap-PDU or 522 InformRequest-PDU. 524 - A list of variable-bindings (VarBindList). This refers to all 525 but the first two variable-bindings in an SNMPv2-Trap-PDU or 526 InformRequest-PDU. 528 3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification 529 Parameters 531 The following procedure describes how to translate SNMPv1 532 notification parameters into SNMPv2 notification parameters: 534 (1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the 535 SNMPv1 time-stamp parameter. 537 (2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)', 538 the SNMPv2 snmpTrapOID parameter SHALL be the concatentation of the 539 SNMPv1 enterprise parameter and two additional sub-identifiers, 540 '0', and the SNMPv1 specific-trap parameter. 542 (3) If the SNMPv1 generic-trap parameter is not 543 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be 544 the corresponding trap as defined in section 2 of RFC1907 [12]: 546 generic-trap parameter snmpTrapOID.0 547 ====================== ============= 548 0 1.3.6.1.6.3.1.1.5.1 (coldStart) 549 1 1.3.6.1.6.3.1.1.5.2 (warmStart) 550 2 1.3.6.1.6.3.1.1.5.3 (linkDown) 551 3 1.3.6.1.6.3.1.1.5.4 (linkUp) 552 4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 553 5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 555 (4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-bindings. 556 In addition, if the translation is being performed by a proxy in 557 order to forward a received trap, three additional variable- 558 bindings will be appended, if these three additional variable- 559 bindings do not already exist in the SNMPv1 variable-bindings. The 560 name portion of the first additional variable binding SHALL contain 561 snmpTrapAddress.0, and the value SHALL contain the SNMPv1 agent- 562 addr parameter. The name portion of the second additional variable 563 binding SHALL contain snmpTrapCommunity.0, and the value SHALL 564 contain the value of the community-string field from the received 565 SNMPv1 message which contained the SNMPv1 Trap-PDU. The name 566 portion of the third additional variable binding SHALL contain 567 snmpTrapEnterprise.0 [12], and the value SHALL be the SNMPv1 568 enterprise parameter. 570 3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification 571 Parameters 573 The following procedure describes how to translate SNMPv2 574 notification parameters into SNMPv1 notification parameters: 576 (1) The SNMPv1 enterprise parameter SHALL be determined as follows: 578 - If the SNMPv2 snmpTrapOID parameter is one of the standard 579 traps as defined in RFC1907 [12], then the SNMPv1 enterprise 580 parameter SHALL be set to the value of the variable-binding in 581 the SNMPv2 variable-bindings whose name is 582 snmpTrapEnterprise.0 if that variable-binding exists. If it 583 does not exist, the SNMPv1 enterprise parameter SHALL be set 584 to the value 'snmpTraps' as defined in RFC1907 [12]. 586 - If the SNMPv2 snmpTrapOID parameter is not one of the standard 587 traps as defined in RFC1907 [12], then the SNMPv1 enterprise 588 parameter SHALL be determined from the SNMPv2 snmpTrapOID 589 parameter as follows: 591 - If the next-to-last sub-identifier of the snmpTrapOID is 592 zero, then the SNMPv1 enterprise SHALL be the SNMPv2 593 snmpTrapOID with the last 2 sub-identifiers removed, 594 otherwise 596 - If the next-to-last sub-identifier of the snmpTrapOID is 597 non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2 598 snmpTrapOID with the last sub-identifier removed. 600 (2) The SNMPv1 agent-addr parameter SHALL be determined based on the 601 situation in which the translation occurs. 603 - If the translation occurs within a notification originator 604 application, and the notification is to be sent over IP, the 605 SNMPv1 agent-addr parameter SHALL be set to the IP address of 606 the SNMP entity in which the notification originator resides. 607 If the notification is to be sent over some other transport, 608 the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0. 610 - If the translation occurs within a proxy application, the 611 proxy must attempt to extract the original source of the 612 notification from the variable-bindings. If the SNMPv2 613 variable-bindings contains a variable binding whose name is 614 snmpTrapAddress.0, the agent-addr parameter SHALL be set to 615 the value of that variable binding. Otherwise, the SNMPv1 616 agent-addr parameter SHALL be set to 0.0.0.0. 618 (3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as 619 defined in RFC1907 [12], the SNMPv1 generic-trap parameter SHALL be 620 set as follows: 622 snmpTrapOID.0 parameter generic-trap 623 =============================== ============ 624 1.3.6.1.6.3.1.1.5.1 (coldStart) 0 625 1.3.6.1.6.3.1.1.5.2 (warmStart) 1 626 1.3.6.1.6.3.1.1.5.3 (linkDown) 2 627 1.3.6.1.6.3.1.1.5.4 (linkUp) 3 628 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4 629 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5 631 Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6. 633 (4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as 634 defined in RFC1907 [12], the SNMPv1 specific-trap parameter SHALL 635 be set to zero. Otherwise, the SNMPv1 specific-trap parameter 636 SHALL be set to the last sub-identifier of the SNMPv2 snmpTrapOID 637 parameter. 639 (5) The SNMPv1 time-stamp parameter SHALL be taken directly from the 640 SNMPv2 sysUpTime parameter. 642 (6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-bindings. 643 Note, however, that if the SNMPv2 variable-bindings contain any 644 objects whose type is Counter64, the translation to SNMPv1 645 notification parameters cannot be performed. In this case, the 646 notification cannot be encoded in an SNMPv1 packet (and so the 647 notification cannot be sent using SNMPv1, see section 4.1.3 and 648 section 4.2). 650 4. Approaches to Coexistence in a Multi-lingual Network 652 There are two basic approaches to coexistence in a multi-lingual 653 network, multi-lingual implementations and proxy implementations. 654 Multi-lingual implementations allow elements in a network to 655 communicate with each other using an SNMP version which both elements 656 support. This allows a multi-lingual implementation to communicate 657 with any mono-lingual implementation, regardless of the SNMP version 658 supported by the mono-lingual implementation. 660 Proxy implementations provide a mechanism for translating between 661 SNMP versions using a third party network element. This allows 662 network elements which support only a single, but different, SNMP 663 version to communicate with each other. Proxy implementations are 664 also useful for securing communications over an insecure link between 665 two locally secure networks. 667 4.1. Multi-lingual implementations 669 This approach requires an entity to support multiple SNMP message 670 versions. Typically this means supporting SNMPv1, SNMPv2c, and 671 SNMPv3 message versions. The behaviour of various types of SNMP 672 applications which support multiple message versions is described in 673 the following sections. This approach allows entities which support 674 multiple SNMP message versions to coexist with and communicate with 675 entities which support only a single SNMP message version. 677 4.1.1. Command Generator 679 A command generator must select an appropriate message version when 680 sending requests to another entity. One way to achieve this is to 681 consult a local database to select the appropriate message version. 683 In addition, a command generator MUST 'downgrade' GetBulk requests to 684 GetNext requests when selecting SNMPv1 as the message version for an 685 outgoing request. This is done by simply changing the operation type 686 to GetNext, ignoring any non-repeaters and max-repetitions values, 687 and setting error-status and error-index to zero. 689 4.1.2. Command Responder 691 A command responder must be able to deal with both SNMPv1 and SNMPv2 692 access to MIB data. There are three aspects to dealing with this. A 693 command responder must: 695 - Deal correctly with SNMPv2 access to MIB data that returns a 696 Counter64 value while processing an SNMPv1 message, 698 - Deal correctly with SNMPv2 access to MIB data that returns one 699 of the three exception values while processing an SNMPv1 700 message, and 702 - Map SNMPv2 error codes returned from SNMPv2 access to MIB data 703 into SNMPv1 error codes when processing an SNMPv1 message. 705 Note that SNMPv1 error codes SHOULD NOT be used without any change 706 when processing SNMPv2c or SNMPv3 messages, except in the case of 707 proxy forwarding. In the case of proxy forwarding, for backwards 708 compatibility, SNMPv1 error codes may be used without any change in a 709 forwarded SNMPv2c or SNMPv3 message. 711 The following sections describe the behaviour of a command responder 712 application which supports multiple SNMP message versions, and which 713 uses some combination of SNMPv1 and SNMPv2 access to MIB data. 715 4.1.2.1. Handling Counter64 717 The SMIv2 [7] defines one new syntax that is incompatible with SMIv1. 718 This syntax is Counter64. All other syntaxes defined by SMIv2 are 719 compatible with SMIv1. 721 The impact on multi-lingual command responders is that they MUST NOT 722 ever return a variable binding containing a Counter64 value in a 723 response to a request that was received using the SNMPv1 message 724 version. 726 Multi-lingual command responders SHALL take the approach that object 727 instances whose type is Counter64 are implicitly excluded from view 728 when processing an SNMPv1 message. So: 730 - On receipt of an SNMPv1 GetRequest-PDU containing a variable 731 binding whose name field points to an object instance of type 732 Counter64, a GetResponsePDU SHALL be returned, with an error- 733 status of noSuchName and the error-index set to the variable 734 binding that caused this error. 736 - On an SNMPv1 GetNextRequest-PDU, any object instance which 737 contains a syntax of Counter64 SHALL be skipped, and the next 738 accessible object instance that does not have the syntax of 739 Counter64 SHALL be retrieved. If no such object instance 740 exists, then an error-status of noSuchName SHALL be returned, 741 and the error-index SHALL be set to the variable binding that 742 caused this error. 744 - Any SNMPv1 request which contains a variable binding with a 745 Counter64 value is ill-formed, so the foregoing rules do not 746 apply. If that error is detected, a response SHALL NOT be 747 returned, since it would contain a copy of the ill-formed 748 variable binding. Instead, the offending PDU SHALL be 749 discarded and the counter snmpInASNParseErrs SHALL be 750 incremented. 752 4.1.2.2. Mapping SNMPv2 Exceptions 754 SNMPv2 provides a feature called exceptions, which allow an SNMPv2 755 Response PDU to return as much management information as possible, 756 even when an error occurs. However, SNMPv1 does not support 757 exceptions, and so an SNMPv1 Response PDU cannot return any 758 management information, and can only return an error-status and 759 error-index value. 761 When an SNMPv1 request is received, a command responder MUST check 762 any variable bindings returned using SNMPv2 access to MIB data for 763 exception values, and convert these exception values into SNMPv1 764 error codes. 766 The type of exception that can be returned when accessing MIB data 767 and the action taken depends on the type of SNMP request. 769 - For a GetRequest, a noSuchObject or noSuchInstance exception 770 may be returned. 772 - For a GetNextRequest, an endOfMibView exception may be 773 returned. 775 - No exceptions will be returned for a SetRequest, and a 776 GetBulkRequest should only be received in an SNMPv2c or SNMPv3 777 message, so these request types may be ignored when mapping 778 exceptions. 780 Note that when a response contains multiple exceptions, it is an 781 implementation choice as to which variable binding the error-index 782 should reference. 784 4.1.2.2.1. Mapping noSuchObject and noSuchInstance 786 A noSuchObject or noSuchInstance exception generated by an SNMPv2 787 access to MIB data indicates that the requested object instance can 788 not be returned. The SNMPv1 error code for this condition is 789 noSuchName, and so the error-status field of the response PDU SHALL 790 be set to noSuchName. Also, the error-index field SHALL be set to 791 the index of the variable binding for which an exception occurred 792 (there may be more than one and it is an implementation decision as 793 to which is used), and the variable binding list from the original 794 request SHALL be returned with the response PDU. 796 4.1.2.2.2. Mapping endOfMibView 798 When an SNMPv2 access to MIB data returns a variable binding 799 containing an endOfMibView exception, it indicates that there are no 800 object instances available which lexicographically follow the object 801 in the request. In an SNMPv1 agent, this condition normally results 802 in a noSuchName error, and so the error-status field of the response 803 PDU SHALL be set to noSuchName. Also, the error-index field SHALL be 804 set to the index of the variable binding for which an exception 805 occurred (there may be more than one and it is an implementation 806 decision as to which is used), and the variable binding list from the 807 original request SHALL be returned with the response PDU. 809 4.1.2.3. Processing An SNMPv1 GetRequest 811 When processing an SNMPv1 GetRequest, the following procedures MUST 812 be followed when using an SNMPv2 access to MIB data. 814 When such an access to MIB data returns response data using SNMPv2 815 syntax and error-status values, then: 817 (1) If the error-status is anything other than noError, 819 - The error status SHALL be translated to an SNMPv1 error-status 820 using the table in section 4.3, "Error Status Mappings". 822 - The error-index SHALL be set to the position (in the original 823 request) of the variable binding that caused the error-status. 825 - The variable binding list of the response PDU SHALL be made 826 exactly the same as the variable binding list that was 827 received in the original request. 829 (2) If the error-status is noError, the variable bindings SHALL be 830 checked for any SNMPv2 exception (noSuchObject or noSuchInstance) 831 or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64). If 832 there are any such variable bindings, one of those variable 833 bindings SHALL be selected (it is an implementation choice as to 834 which is selected), and: 836 - The error-status SHALL be set to noSuchName, 838 - The error-index SHALL be set to the position (in the variable 839 binding list of the original request) of the selected variable 840 binding, and 842 - The variable binding list of the response PDU SHALL be exactly 843 the same as the variable binding list that was received in the 844 original request. 846 (3) If there are no such variable bindings, then: 848 - The error-status SHALL be set to noError, 850 - The error-index SHALL be set to zero, and 852 - The variable binding list of the response SHALL be composed 853 from the data as it is returned by the access to MIB data. 855 4.1.2.4. Processing An SNMPv1 GetNextRequest 857 When processing an SNMPv1 GetNextRequest, the following procedures 858 MUST be followed when an SNMPv2 access to MIB data is called as part 859 of processing the request. There may be repetitive accesses to MIB 860 data to try to find the first object which lexicographically follows 861 each of the objects in the request. This is implementation specific. 862 These procedures are followed only for data returned when using 863 SNMPv2 access to MIB data. Data returned using SNMPv1 access to MIB 864 data may be treated in the normal manner for an SNMPv1 request. 866 First, if the access to MIB data returns an error-status of anything 867 other than noError: 869 (1) The error status SHALL be translated to an SNMPv1 error-status 870 using the table in section 4.3, "Error Status Mappings". 872 (2) The error-index SHALL be set to the position (in the original 873 request) of the variable binding that caused the error-status. 875 (3) The variable binding list of the response PDU SHALL be exactly the 876 same as the variable binding list that was received in the original 877 request. 879 Otherwise, if the access to MIB data returns an error-status of 880 noError: 882 (1) Any variable bindings containing an SNMPv2 syntax of Counter64 883 SHALL be considered to be not in view, and MIB data SHALL be 884 accessed as many times as is required until either a value other 885 than Counter64 is returned, or an error occurs. 887 (2) If there is any variable binding that contains an SNMPv2 exception 888 endOfMibView (there may be more than one, it is an implementation 889 decision as to which is chosen): 891 - The error-status SHALL be set to noSuchName, 893 - The error-index SHALL be set to the position (in the variable 894 binding list of the original request) of the variable binding 895 that returned such an SNMPv2 exception, and 897 - The variable binding list of the response PDU SHALL be exactly 898 the same as the variable binding list that was received in the 899 original request. 901 (3) If there are no such variable bindings, then: 903 - The error-status SHALL be set to noError, 905 - The error-index SHALL be set to zero, and 907 - The variable binding list of the response SHALL be composed 908 from the data as it is returned by the access to MIB data. 910 4.1.2.5. Processing An SNMPv1 SetRequest 912 When processing an SNMPv1 SetRequest, the following procedures MUST 913 be followed when calling SNMPv2 MIB access routines. 915 When such MIB access routines return response data using SNMPv2 916 syntax and error-status values, and the error-status is anything 917 other than noError, then: 919 - The error status SHALL be translated to an SNMPv1 error-status 920 using the table in section 4.3, "Error Status Mappings". 922 - The error-index SHALL be set to the position (in the original 923 request) of the variable binding that caused the error-status. 925 - The variable binding list of the response PDU SHALL be made 926 exactly the same as the variable binding list that was 927 received in the original request. 929 4.1.3. Notification Originator 931 A notification originator must be able to translate between SNMPv1 932 notifications parameters and SNMPv2 notification parameters in order 933 to send a notification using a particular SNMP message version. If a 934 notification is generated using SNMPv1 notification parameters, and 935 configuration information specifies that notifications be sent using 936 SNMPv2c or SNMPv3, the notification parameters must be translated to 937 SNMPv2 notification parameters. Likewise, if a notification is 938 generated using SNMPv2 notification parameters, and configuration 939 information specifies that notifications be sent using SNMPv1, the 940 notification parameters must be translated to SNMPv1 notification 941 parameters. In this case, if the notification cannot be translated 942 (due to the presence of a Counter64 type), it will not be sent using 943 SNMPv1. 945 When a notification originator generates a notification, using 946 parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION- 947 MIB, if the SNMP version used to generate the notification is SNMPv1, 948 the PDU type used will always be a TrapPDU, regardless of whether the 949 value of snmpNotifyType is trap(1) or inform(2). 951 Note also that access control and notification filtering are 952 performed in the usual manner for notifications, regardless of the 953 SNMP message version to be used when sending a notification. The 954 parameters for performing access control are found in the usual 955 manner (i.e., from inspecting the SNMP-TARGET-MIB and SNMP- 956 NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in 957 order to perform the access check specified in [18], section 3.3, 958 bullet (3), the notification originator may need to generate a value 959 for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of 960 this document. If the SNMPv1 notification parameters being used were 961 previously translated from a set of SNMPv2 notification parameters, 962 this value may already be known, in which case it need not be 963 generated. 965 4.1.4. Notification Receiver 967 There are no special requirements of a notification receiver. 968 However, an implementation may find it useful to allow a higher level 969 application to request whether notifications should be delivered to a 970 higher level application using SNMPv1 notification parameter or 971 SNMPv2 notification parameters. The notification receiver would then 972 translate notification parameters when required in order to present a 973 notification using the desired set of parameters. 975 4.2. Proxy Implementations 977 A proxy implementation may be used to enable communication between 978 entities which support different SNMP message versions. This is 979 accomplished in a proxy forwarder application by performing 980 translations on PDUs. These translations depend on the PDU type, the 981 SNMP version of the packet containing a received PDU, and the SNMP 982 version to be used to forward a received PDU. The following sections 983 describe these translations. In all cases other than those described 984 below, the proxy SHALL forward a received PDU without change, subject 985 to size contraints as defined in section 5.3 (Community MIB) of this 986 document. Note that in the following sections, the 'Upstream 987 Version' refers to the version used between the command generator and 988 the proxy, and the 'Downstream Version' refers to the version used 989 between the proxy and the command responder, regardless of the PDU 990 type or direction. 992 4.2.1. Upstream Version Greater Than Downstream Version 994 - If a GetBulkRequest-PDU is received and must be forwarded 995 using the SNMPv1 message version, the proxy forwarder SHALL 996 set the non-repeaters and max-repetitions fields to 0, and 997 SHALL set the tag of the PDU to GetNextRequest-PDU. 999 - If a GetResponse-PDU is received whose error-status field has 1000 a value of 'tooBig', the message will be forwarded using the 1001 SNMPv2c or SNMPv3 message version, and the original request 1002 received by the proxy was not a GetBulkRequest-PDU, the proxy 1003 forwarder SHALL remove the contents of the variable-bindings 1004 field before forwarding the response. 1006 - If a GetResponse-PDU is received whose error-status field has 1007 a value of 'tooBig,' and the message will be forwarded using 1008 the SNMPv2c or SNMPv3 message version, and the original 1009 request received by the proxy was a GetBulkRequest-PDU, the 1010 proxy forwarder SHALL re-send the forwarded request (which 1011 would have been altered to be a GetNextRequest-PDU) with all 1012 but the first variable-binding removed. The proxy forwarder 1013 SHALL only re-send such a request a single time. If the 1014 resulting GetResponse-PDU also contains an error-status field 1015 with a value of 'tooBig,' then the proxy forwarder SHALL 1016 remove the contents of the variable-bindings field, and change 1017 the error-status field to 'noError' before forwarding the 1018 response. Note that if the original request only contained a 1019 single variable-binding, the proxy may skip re-sending the 1020 request and simply remove the variable-bindings and change the 1021 error-status to 'noError.' 1023 - If a Trap-PDU is received, and will be forwarded using the 1024 SNMPv2c or SNMPv3 message version, the proxy SHALL apply the 1025 translation rules described in section 3, and SHALL forward 1026 the notification as an SNMPv2-Trap-PDU. 1028 Note that when an SNMPv1 agent generates a message containing 1029 a Trap-PDU which is subsequently forwarded by one or more 1030 proxy forwarders using SNMP versions other than SNMPv1, the 1031 community string and agent-addr fields from the original 1032 message generated by the SNMPv1 agent will be preserved 1033 through the use of the snmpTrapAddress and snmpTrapCommunity 1034 objects. 1036 4.2.2. Upstream Version Less Than Downstream Version 1038 - If a GetResponse-PDU is received in response to a GetRequest- 1039 PDU (previously generated by the proxy) which contains 1040 variable-bindings of type Counter64 or which contain an SNMPv2 1041 exception code, and the message would be forwarded using the 1042 SNMPv1 message version, the proxy MUST generate an alternate 1043 response PDU consisting of the request-id and variable 1044 bindings from the original SNMPv1 request, containing a 1045 noSuchName error-status value, and containing an error-index 1046 value indicating the position of the variable-binding 1047 containing the Counter64 type or exception code. 1049 - If a GetResponse-PDU is received in response to a 1050 GetNextRequest-PDU (previously generated by the proxy) which 1051 contains variable-bindings that contain an SNMPv2 exception 1052 code, and the message would be forwarded using the SNMPv1 1053 message version, the proxy MUST generate an alternate response 1054 PDU consisting of the request-id and variable bindings from 1055 the original SNMPv1 request, containing a noSuchName error- 1056 status value, and containing an error-index value indicating 1057 the position of the variable-binding containing the exception 1058 code. 1060 - If a GetResponse-PDU is received in response to a 1061 GetNextRequest-PDU (previously generated by the proxy) which 1062 contains variable-bindings of type Counter64, the proxy MUST 1063 re-send the entire GetNextRequest-PDU, with the following 1064 modifications. For any variable bindings in the received 1065 GetResponse which contained Counter64 types, the proxy 1066 substitutes the object names of these variable bindings for 1067 the corresponding object names in the previously-sent 1068 GetNextRequest. The proxy MUST repeat this process until no 1069 Counter64 objects are returned. Note that an implementation 1070 may attempt to optimize this process of skipping Counter64 1071 objects. One approach to such an optimization would be to 1072 replace the last sub-identifier of the object names of 1073 varbinds containing a Counter64 type with 65535 if that sub- 1074 identifier is less than 65535, or with 4294967295 if that 1075 sub-identifier is greater than 65535. This approach should 1076 skip multiple instances of the same Counter64 object, while 1077 maintaining compatibility with some broken agent 1078 implementations (which only use 16-bit integers for sub- 1079 identifiers). 1081 Deployment Hint: The process of repeated GetNext requests 1082 used by a proxy when Counter64 types are returned can be 1083 expensive. When deploying a proxy, this can be avoided by 1084 configuring the target agents to which the proxy forwards 1085 requests in a manner such that any objects of type Counter64 1086 are in fact not-in-view for the principal that the proxy is 1087 using when communicating with these agents. 1089 - If a GetResponse-PDU is received which contains an SNMPv2 1090 error-status value of wrongValue, wrongEncoding, wrongType, 1091 wrongLength, inconsistentValue, noAccess, notWritable, 1092 noCreation, inconsistentName, resourceUnavailable, 1093 commitFailed, undoFailed, or authorizationError, the error- 1094 status value is modified using the mappings in section 4.3. 1096 - If an SNMPv2-Trap-PDU is received, and will be forwarded using 1097 the SNMPv1 message version, the proxy SHALL apply the 1098 translation rules described in section 3, and SHALL forward 1099 the notification as a Trap-PDU. Note that if the translation 1100 fails due to the existence of a Counter64 data-type in the 1101 received SNMPv2-Trap-PDU, the trap cannot be forwarded using 1102 SNMPv1. 1104 - If an InformRequest-PDU is received, any configuration 1105 information indicating that it would be forwarded using the 1106 SNMPv1 message version SHALL be ignored. An InformRequest-PDU 1107 can only be forwarded using the SNMPv2c or SNMPv3 message 1108 version. The InformRequest-PDU may still be forwarded if 1109 there is other configuration information indicating that it 1110 should be forwarded using SNMPv2c or SNMPv3. 1112 4.3. Error Status Mappings 1114 The following tables shows the mappings of SNMPv1 error-status values 1115 into SNMPv2 error-status values, and the mappings of SNMPv2 error- 1116 status values into SNMPv1 error-status values. 1118 SNMPv1 error-status SNMPv2 error-status 1119 =================== =================== 1120 noError noError 1121 tooBig tooBig 1122 noSuchName noSuchName 1123 badValue badValue 1124 genErr genErr 1126 SNMPv2 error-status SNMPv1 error-status 1127 =================== =================== 1128 noError noError 1129 tooBig tooBig 1130 genErr genErr 1131 wrongValue badValue 1132 wrongEncoding badValue 1133 wrongType badValue 1134 wrongLength badValue 1135 inconsistentValue badValue 1136 noAccess noSuchName 1137 notWritable noSuchName 1138 noCreation noSuchName 1139 inconsistentName noSuchName 1140 resourceUnavailable genErr 1141 commitFailed genErr 1142 undoFailed genErr 1143 authorizationError noSuchName 1145 Whenever the SNMPv2 error-status value of authorizationError is 1146 translated to an SNMPv1 error-status value of noSuchName, the value 1147 of snmpInBadCommunityUses MUST be incremented. 1149 5. Message Processing Models and Security Models 1151 In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture, 1152 the following models are defined in this document: 1154 - The SNMPv1 Message Processing Model 1156 - The SNMPv1 Community-Based Security Model 1158 The following models are also described in this document: 1160 - The SNMPv2c Message Processing Model 1162 - The SNMPv2c Community-Based Security Model 1164 In most respects, the SNMPv1 Message Processing Model and the 1165 SNMPv2c Message Processing Model are identical, and so these 1166 are not discussed independently in this document. Differences 1167 between the two models are described as required. 1169 Similarly, the SNMPv1 Community-Based Security Model and the 1170 SNMPv2c Community-Based Security Model are nearly identical, 1171 and so are not discussed independently. Differences between 1172 these two models are also described as required. 1174 5.1. Mappings 1176 The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model 1177 require mappings between parameters used in SNMPv1 (and SNMPv2c) 1178 messages, and the version independent parameters used in the SNMP 1179 architecture [16]. The parameters which MUST be mapped consist of the 1180 SNMPv1 (and SNMPv2c) community name, and the SNMP securityName and 1181 contextEngineID/contextName pair. A MIB module (the SNMP-COMMUNITY-MIB) 1182 is provided in this document in order to perform these mappings. This 1183 MIB provides mappings in both directions, that is, a community name may 1184 be mapped to a securityName, contextEngineID, and contextName, or the 1185 combination of securityName, contextEngineID, and contextName may be 1186 mapped to a community name. 1188 5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model 1190 The SNMPv1 Message Processing Model handles processing of SNMPv1 1191 messages. The processing of messages is handled generally in the 1192 same manner as described in RFC1157 [2], with differences and 1193 clarifications as described in the following sections. The 1194 SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for 1195 SNMPv2c is 1). 1197 5.2.1. Processing An Incoming Request 1199 In RFC1157 [2], section 4.1, item (3) for an entity which receives a 1200 message, states that various parameters are passed to the 'desired 1201 authentication scheme.' The desired authentication scheme in this 1202 case is the SNMPv1 Community-Based Security Model, which will be 1203 called using the processIncomingMsg ASI. The parameters passed to 1204 this ASI are: 1206 - The messageProcessingModel, which will be 0 (or 1 for 1207 SNMPv2c). 1209 - The maxMessageSize, which should be the maximum size of a 1210 message that the receiving entity can generate (since there is 1211 no such value in the received message). 1213 - The securityParameters, which consist of the community string 1214 and the message's source and destination transport domains and 1215 addresses. 1217 - The securityModel, which will be 1 (or 2 for SNMPv2c). 1219 - The securityLevel, which will be noAuthNoPriv. 1221 - The wholeMsg and wholeMsgLength. 1223 The Community-Based Security Model will attempt to select a row in 1224 the snmpCommunityTable. This is done by performing a search through 1225 the snmpCommunityTable in lexicographic order. The first entry for 1226 which the following matching criteria are satisfied will be selected: 1228 - The community string is equal to the snmpCommunityName value. 1230 - If the snmpCommunityTransportTag is an empty string, it is 1231 ignored for the purpose of matching. If the 1232 snmpCommunityTransportTag is not an empty string, the 1233 transportDomain and transportAddress from which the message 1234 was received must match one of the entries in the 1235 snmpTargetAddrTable selected by the snmpCommunityTransportTag 1236 value. The snmpTargetAddrTMask object is used as described in 1237 section 5.3 when checking whether the transportDomain and 1238 transportAddress matches a entry in the snmpTargetAddrTable. 1240 If no such entry can be found, an authentication failure occurs as 1241 described in RFC1157 [2], and the snmpInBadCommunityNames counter is 1242 incremented. 1244 The parameters returned from the Community-Based Security Model are: 1246 - The securityEngineID, which will always be the local value of 1247 snmpEngineID.0. 1249 - The securityName. 1251 - The scopedPDU. Note that this parameter will actually consist 1252 of three values, the contextSnmpEngineID, the contextName, and 1253 the PDU. These must be separate values, since the first two 1254 do not actually appear in the message. 1256 - The maxSizeResponseScopedPDU. 1258 - The securityStateReference. 1260 The appropriate SNMP application will then be called (depending on 1261 the value of the contextEngineID and the request type in the PDU) 1262 using the processPdu ASI. The parameters passed to this ASI are: 1264 - The messageProcessingModel, which will be 0 (or 1 for 1265 SNMPv2c). 1267 - The securityModel, which will be 1 (or 2 for SNMPv2c). 1269 - The securityName, which was returned from the call to 1270 processIncomingMsg. 1272 - The securityLevel, which is noAuthNoPriv. 1274 - The contextEngineID, which was returned as part of the 1275 ScopedPDU from the call to processIncomingMsg. 1277 - The contextName, which was returned as part of the ScopedPDU 1278 from the call to processIncomingMsg. 1280 - The pduVersion, which should indicate an SNMPv1 version PDU 1281 (if the message version was SNMPv2c, this would be an SNMPv2 1282 version PDU). 1284 - The PDU, which was returned as part of the ScopedPDU from the 1285 call to processIncomingMsg. 1287 - The maxSizeResponseScopedPDU which was returned from the call 1288 to processIncomingMsg. 1290 - The stateReference which was returned from the call to 1291 processIncomingMsg. 1293 The SNMP application should process the request as described 1294 previously in this document. Note that access control is applied by 1295 an SNMPv3 command responder application as usual. The parameters as 1296 passed to the processPdu ASI will be used in calls to the 1297 isAccessAllowed ASI. 1299 5.2.2. Generating An Outgoing Response 1301 There is no special processing required for generating an outgoing 1302 response. However, the community string used in an outgoing response 1303 must be the same as the community string from the original request. 1304 The original community string MUST be present in the stateReference 1305 information of the original request. 1307 5.2.3. Generating An Outgoing Notification 1309 In a multi-lingual SNMP entity, the parameters used for generating 1310 notifications will be obtained by examining the SNMP-TARGET-MIB and 1311 SNMP-NOTIFICATION-MIB. These parameters will be passed to the SNMPv1 1312 Message Processing Model using the sendPdu ASI. The SNMPv1 Message 1313 Processing Model will attempt to locate an appropriate community 1314 string in the snmpCommunityTable based on the parameters passed to 1315 the sendPdu ASI. This is done by performing a search through the 1316 snmpCommunityTable in lexicographic order. The first entry for which 1317 the following matching criteria are satisfied will be selected: 1319 - The securityName must be equal to the 1320 snmpCommunitySecurityName value. 1322 - The contextEngineID must be equal to the 1323 snmpCommunityContextEngineID value. 1325 - The contextName must be equal to the snmpCommunityContextName 1326 value. 1328 - If the snmpCommunityTransportTag is an empty string, it is 1329 ignored for the purpose of matching. If the 1330 snmpCommunityTransportTag is not an empty string, the 1331 transportDomain and transportAddress must match one of the 1332 entries in the snmpTargetAddrTable selected by the 1333 snmpCommunityTransportTag value. 1335 If no such entry can be found, the notification is not sent. 1336 Otherwise, the community string used in the outgoing notification 1337 will be the value of the snmpCommunityName column of the selected 1338 row. 1340 5.3. The SNMP Community MIB Module 1342 The SNMP-COMMUNITY-MIB contains objects for mapping between community 1343 strings and version-independent SNMP message parameters. In 1344 addition, this MIB provides a mechanism for performing source address 1345 validation on incoming requests, and for selecting community strings 1346 based on target addresses for outgoing notifications. These two 1347 features are accomplished by providing a tag in the 1348 snmpCommunityTable which selects sets of entries in the 1349 snmpTargetAddrTable [18]. In addition, the SNMP-COMMUNITY-MIB 1350 augments the snmpTargetAddrTable with a transport address mask value 1351 and a maximum message size value. These values are used only where 1352 explicitly stated. In cases where the snmpTargetAddrTable is used 1353 without mention of these augmenting values, the augmenting values 1354 should be ignored. 1356 The mask value, snmpTargetAddrTMask, allows selected entries in the 1357 snmpTargetAddrTable to specify multiple addresses (rather than just a 1358 single address per entry). This would typically be used to specify a 1359 subnet in an snmpTargetAddrTable rather than just a single address. 1360 The mask value is used to select which bits of a transport address 1361 must match bits of the corresponding instance of 1362 snmpTargetAddrTAddress, in order for the transport address to match a 1363 particular entry in the snmpTargetAddrTable. The value of an 1364 instance of snmpTargetAddrTMask must always be an OCTET STRING whose 1365 length is either zero or the same as that of the corresponding 1366 instance of snmpTargetAddrTAddress. 1368 Note that the snmpTargetAddrTMask object is only used where 1369 explicitly stated. In particular, it is not used when generating 1370 notifications (i.e., when generating notifications, entries in the 1371 snmpTargetAddrTable only specify individual addresses). 1373 When checking whether a transport address matches an entry in the 1374 snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero- 1375 length OCTET STRING, the mask value is ignored, and the value of 1376 snmpTargetAddrTAddress must exactly match a transport address. 1377 Otherwise, each bit of each octet in the snmpTargetAddrTMask value 1378 corresponds to the same bit of the same octet in the 1379 snmpTargetAddrTAddress value. For bits that are set in the 1380 snmpTargetAddrTMask value (i.e., bits equal to 1), the corresponding 1381 bits in the snmpTargetAddrTAddress value must match the bits in a 1382 transport address. If all such bits match, the transport address is 1383 matched by that snmpTargetAddrTable entry. Otherwise, the transport 1384 address is not matched. 1386 The maximum message size value, snmpTargetAddrMMS, is used to 1387 determine the maximum message size acceptable to another SNMP entity 1388 when the value cannot be determined from the protocol. 1390 SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN 1392 IMPORTS 1393 IpAddress, 1394 MODULE-IDENTITY, 1395 OBJECT-TYPE, 1396 Integer32, 1397 snmpModules 1398 FROM SNMPv2-SMI 1399 RowStatus, 1400 StorageType 1401 FROM SNMPv2-TC 1402 SnmpAdminString, 1403 SnmpEngineID 1404 FROM SNMP-FRAMEWORK-MIB 1405 SnmpTagValue, 1406 snmpTargetAddrEntry 1407 FROM SNMP-TARGET-MIB 1408 MODULE-COMPLIANCE, 1409 OBJECT-GROUP 1410 FROM SNMPv2-CONF; 1412 snmpCommunityMIB MODULE-IDENTITY 1413 LAST-UPDATED "199910050000Z" -- 5 Oct 1999, midnight 1414 ORGANIZATION "SNMPv3 Working Group" 1415 CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com 1416 Subscribe: majordomo@lists.tislabs.com 1417 In msg body: subscribe snmpv3 1419 Chair: Russ Mundy 1420 TIS Labs at Network Associates 1422 Postal: 3060 Washington Rd 1423 Glenwood MD 21738 1424 USA 1425 Email: mundy@tislabs.com 1426 Phone: +1-301-854-6889 1428 Co-editor: Rob Frye 1429 CoSine Communications 1430 Postal: 1200 Bridge Parkway 1431 Redwood City, CA 94065 1432 USA 1433 E-mail: rfrye@cosinecom.com 1434 Phone: +1 650 637 4777 1436 Co-editor: David B. Levi 1437 Nortel Networks 1438 Postal: 3505 Kesterwood Drive 1439 Knoxville, TN 37918 1440 E-mail: dlevi@nortelnetworks.com 1441 Phone: +1 423 686 0432 1443 Co-editor: Shawn A. Routhier 1444 Integrated Systems Inc. 1445 Postal: 333 North Ave 4th Floor 1446 Wakefield, MA 01880 1447 E-mail: sar@epilogue.com 1448 Phone: +1 781 245 0804 1450 Co-editor: Bert Wijnen 1451 IBM T. J. Watson Research 1452 Postal: Schagen 33 1453 3461 GL Linschoten 1454 Netherlands 1455 Email: wijnen@vnet.ibm.com 1456 Phone: +31-348-432-794 1457 " 1459 DESCRIPTION 1460 "This MIB module defines objects to help support coexistence 1461 between SNMPv1, SNMPv2c, and SNMPv3." 1462 REVISION "199905130000Z" -- 13 May 1999 1463 DESCRIPTION "The Initial Revision" 1464 REVISION "199910050000Z" -- 5 Oct 1999 (same as LAST-UPDATED) 1465 DESCRIPTION "This version published as RFC xxxx" 1466 -- RFC-editor assigns xxxx 1467 ::= { snmpModules 18 } 1469 -- Administrative assignments **************************************** 1471 snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 } 1472 snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 } 1474 -- 1475 -- The snmpCommunityTable contains a database of community strings. 1476 -- This table provides mappings between community strings, and the 1477 -- parameters required for View-based Access Control. 1478 -- 1480 snmpCommunityTable OBJECT-TYPE 1481 SYNTAX SEQUENCE OF SnmpCommunityEntry 1482 MAX-ACCESS not-accessible 1483 STATUS current 1484 DESCRIPTION 1485 "The table of community strings configured in the SNMP 1486 engine's Local Configuration Datastore (LCD)." 1487 ::= { snmpCommunityMIBObjects 1 } 1489 snmpCommunityEntry OBJECT-TYPE 1490 SYNTAX SnmpCommunityEntry 1491 MAX-ACCESS not-accessible 1492 STATUS current 1493 DESCRIPTION 1494 "Information about a particular community string." 1495 INDEX { IMPLIED snmpCommunityIndex } 1496 ::= { snmpCommunityTable 1 } 1498 SnmpCommunityEntry ::= SEQUENCE { 1499 snmpCommunityIndex SnmpAdminString, 1500 snmpCommunityName OCTET STRING, 1501 snmpCommunitySecurityName SnmpAdminString, 1502 snmpCommunityContextEngineID SnmpEngineID, 1503 snmpCommunityContextName SnmpAdminString, 1504 snmpCommunityTransportTag SnmpTagValue, 1505 snmpCommunityStorageType StorageType, 1506 snmpCommunityStatus RowStatus 1507 } 1509 snmpCommunityIndex OBJECT-TYPE 1510 SYNTAX SnmpAdminString (SIZE(1..32)) 1511 MAX-ACCESS not-accessible 1512 STATUS current 1513 DESCRIPTION 1514 "The unique index value of a row in this table." 1515 ::= { snmpCommunityEntry 1 } 1517 snmpCommunityName OBJECT-TYPE 1518 SYNTAX OCTET STRING 1519 MAX-ACCESS read-create 1520 STATUS current 1521 DESCRIPTION 1522 "The community string for which a row in this table 1523 represents a configuration." 1524 ::= { snmpCommunityEntry 2 } 1526 snmpCommunitySecurityName OBJECT-TYPE 1527 SYNTAX SnmpAdminString (SIZE(1..32)) 1528 MAX-ACCESS read-create 1529 STATUS current 1530 DESCRIPTION 1531 "A human readable string representing the corresponding 1532 value of snmpCommunityName in a Security Model 1533 independent format." 1534 ::= { snmpCommunityEntry 3 } 1536 snmpCommunityContextEngineID OBJECT-TYPE 1537 SYNTAX SnmpEngineID 1538 MAX-ACCESS read-create 1539 STATUS current 1540 DESCRIPTION 1541 "The contextEngineID indicating the location of the 1542 context in which management information is accessed 1543 when using the community string specified by the 1544 corresponding instance of snmpCommunityName. 1546 The default value is the snmpEngineID of the entity in 1547 which this object is instantiated." 1548 ::= { snmpCommunityEntry 4 } 1550 snmpCommunityContextName OBJECT-TYPE 1551 SYNTAX SnmpAdminString (SIZE(0..32)) 1552 MAX-ACCESS read-create 1553 STATUS current 1554 DESCRIPTION 1555 "The context in which management information is accessed 1556 when using the community string specified by the corresponding 1557 instance of snmpCommunityName." 1558 DEFVAL { ''H } -- the empty string 1559 ::= { snmpCommunityEntry 5 } 1561 snmpCommunityTransportTag OBJECT-TYPE 1562 SYNTAX SnmpTagValue 1563 MAX-ACCESS read-create 1564 STATUS current 1565 DESCRIPTION 1566 "This object specifies a set of transport endpoints 1567 from which a command responder application will accept 1568 management requests. If a management request containing 1569 this community is received on a transport endpoint other 1570 than the transport endpoints identified by this object, 1571 the request is deemed unauthentic. 1573 The transports identified by this object are specified 1574 in the snmpTargetAddrTable. Entries in that table 1575 whose snmpTargetAddrTagList contains this tag value 1576 are identified. 1578 If the value of this object has zero-length, transport 1579 endpoints are not checked when authenticating messages 1580 containing this community string." 1581 DEFVAL { ''H } -- the empty string 1582 ::= { snmpCommunityEntry 6 } 1584 snmpCommunityStorageType OBJECT-TYPE 1585 SYNTAX StorageType 1586 MAX-ACCESS read-create 1587 STATUS current 1588 DESCRIPTION 1589 "The storage type for this conceptual row in the 1590 snmpCommunityTable. Conceptual rows having the value 1591 'permanent' need not allow write-access to any 1592 columnar object in the row." 1593 ::= { snmpCommunityEntry 7 } 1595 snmpCommunityStatus OBJECT-TYPE 1596 SYNTAX RowStatus 1597 MAX-ACCESS read-create 1598 STATUS current 1599 DESCRIPTION 1600 "The status of this conceptual row in the snmpCommunityTable. 1602 An entry in this table is not qualified for activation 1603 until instances of all corresponding columns have been 1604 initialized, either through default values, or through 1605 Set operations. The snmpCommunityName and 1606 snmpCommunitySecurityName objects must be explicitly set. 1608 There is no restriction on setting columns in this table 1609 when the value of snmpCommunityStatus is active(1)." 1610 ::= { snmpCommunityEntry 8 } 1612 -- 1613 -- The snmpTargetAddrExtTable 1614 -- 1616 snmpTargetAddrExtTable OBJECT-TYPE 1617 SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry 1618 MAX-ACCESS not-accessible 1619 STATUS current 1620 DESCRIPTION 1621 "The table of mask and mms values associated with the 1622 snmpTargetAddrTable. 1624 The snmpTargetAddrExtTable augments the 1625 snmpTargetAddrTable with a transport address mask value 1626 and a maximum message size value. The transport address 1627 mask allows entries in the snmpTargetAddrTable to define 1628 a set of addresses instead of just a single address. 1629 The maximum message size value allows the maximum 1630 message size of another SNMP entity to be configured for 1631 use in SNMPv1 (and SNMPv2c) transactions, where the 1632 message format does not specify a maximum message size." 1633 ::= { snmpCommunityMIBObjects 2 } 1635 snmpTargetAddrExtEntry OBJECT-TYPE 1636 SYNTAX SnmpTargetAddrExtEntry 1637 MAX-ACCESS not-accessible 1638 STATUS current 1639 DESCRIPTION 1640 "Information about a particular mask and mms value." 1641 AUGMENTS { snmpTargetAddrEntry } 1642 ::= { snmpTargetAddrExtTable 1 } 1644 SnmpTargetAddrExtEntry ::= SEQUENCE { 1645 snmpTargetAddrTMask OCTET STRING, 1646 snmpTargetAddrMMS Integer32 1647 } 1649 snmpTargetAddrTMask OBJECT-TYPE 1650 SYNTAX OCTET STRING (SIZE (0..255)) 1651 MAX-ACCESS read-create 1652 STATUS current 1653 DESCRIPTION 1654 "The mask value associated with an entry in the 1655 snmpTargetAddrTable. The value of this object must 1656 have the same length as the corresponding instance of 1657 snmpTargetAddrTAddress, or must have length 0. An 1658 attempt to set it to any other value will result in 1659 an inconsistentValue error. 1661 The value of this object allows an entry in the 1662 snmpTargetAddrTable to specify multiple addresses. 1663 The mask value is used to select which bits of 1664 a transport address must match bits of the corresponding 1665 instance of snmpTargetAddrTAddress, in order for the 1666 transport address to match a particular entry in the 1667 snmpTargetAddrTable. Bits which are 1 in the mask 1668 value indicate bits in the transport address which 1669 must match bits in the snmpTargetAddrTAddress value. 1670 Bits which are 0 in the mask indicate bits in the 1671 transport address which need not match. If the 1672 length of the mask is 0, the mask should be treated 1673 as if all its bits were 1 and its length were equal 1674 to the length of the corresponding value of 1675 snmpTargetAddrTable. 1677 This object may not be modified while the value of the 1678 corresponding instance of snmpTargetAddrRowStatus is 1679 active(1). An attempt to set this object in this case 1680 will result in an inconsistentValue error." 1681 DEFVAL { ''H } 1682 ::= { snmpTargetAddrExtEntry 1 } 1684 snmpTargetAddrMMS OBJECT-TYPE 1685 SYNTAX Integer32 (0|484..2147483647) 1686 MAX-ACCESS read-create 1687 STATUS current 1688 DESCRIPTION 1689 "The maximum message size value associated with an entry 1690 in the snmpTargetAddrTable." 1691 DEFVAL { 484 } 1692 ::= { snmpTargetAddrExtEntry 2 } 1694 -- 1695 -- The snmpTrapAddress and snmpTrapCommunity objects are included 1696 -- in notifications that are forwarded by a proxy, which were 1697 -- originally received as SNMPv1 Trap messages. 1698 -- 1700 snmpTrapAddress OBJECT-TYPE 1701 SYNTAX IpAddress 1702 MAX-ACCESS accessible-for-notify 1703 STATUS current 1704 DESCRIPTION 1705 "The value of the agent-addr field of a Trap PDU which 1706 is forwarded by a proxy forwarder application using 1707 an SNMP version other than SNMPv1. The value of this 1708 object SHOULD contain the value of the agent-addr field 1709 from the original Trap PDU as generated by an SNMPv1 1710 agent." 1711 ::= { snmpCommunityMIBObjects 3 } 1713 snmpTrapCommunity OBJECT-TYPE 1714 SYNTAX OCTET STRING 1715 MAX-ACCESS accessible-for-notify 1716 STATUS current 1717 DESCRIPTION 1718 "The value of the community string field of an SNMPv1 1719 message containing a Trap PDU which is forwarded by a 1720 a proxy forwarder application using an SNMP version 1721 other than SNMPv1. The value of this object SHOULD 1722 contain the value of the community string field from 1723 the original SNMPv1 message containing a Trap PDU as 1724 generated by an SNMPv1 agent." 1725 ::= { snmpCommunityMIBObjects 4 } 1727 -- Conformance Information ******************************************* 1729 snmpCommunityMIBCompliances OBJECT IDENTIFIER 1730 ::= { snmpCommunityMIBConformance 1 } 1731 snmpCommunityMIBGroups OBJECT IDENTIFIER 1732 ::= { snmpCommunityMIBConformance 2 } 1734 -- Compliance statements 1736 snmpCommunityMIBCompliance MODULE-COMPLIANCE 1737 STATUS current 1738 DESCRIPTION 1739 "The compliance statement for SNMP engines which 1740 implement the SNMP-COMMUNITY-MIB." 1742 MODULE -- this module 1743 MANDATORY-GROUPS { snmpCommunityGroup } 1745 OBJECT snmpCommunityName 1746 MIN-ACCESS read-only 1747 DESCRIPTION "Write access is not required." 1749 OBJECT snmpCommunitySecurityName 1750 MIN-ACCESS read-only 1751 DESCRIPTION "Write access is not required." 1752 OBJECT snmpCommunityContextEngineID 1753 MIN-ACCESS read-only 1754 DESCRIPTION "Write access is not required." 1756 OBJECT snmpCommunityContextName 1757 MIN-ACCESS read-only 1758 DESCRIPTION "Write access is not required." 1760 OBJECT snmpCommunityTransportTag 1761 MIN-ACCESS read-only 1762 DESCRIPTION "Write access is not required." 1764 OBJECT snmpCommunityStorageType 1765 MIN-ACCESS read-only 1766 DESCRIPTION "Write access is not required." 1768 OBJECT snmpCommunityStatus 1769 MIN-ACCESS read-only 1770 DESCRIPTION "Write access is not required." 1772 ::= { snmpCommunityMIBCompliances 1 } 1774 snmpProxyTrapForwardCompliance MODULE-COMPLIANCE 1775 STATUS current 1776 DESCRIPTION 1777 "The compliance statement for SNMP engines which 1778 contain a proxy forwarding application which is 1779 capable of forwarding SNMPv1 traps using SNMPv2c 1780 or SNMPv3." 1781 MODULE -- this module 1782 MANDATORY-GROUPS { snmpProxyTrapForwardGroup } 1783 ::= { snmpCommunityMIBCompliances 2 } 1785 snmpCommunityGroup OBJECT-GROUP 1786 OBJECTS { 1787 snmpCommunityName, 1788 snmpCommunitySecurityName, 1789 snmpCommunityContextEngineID, 1790 snmpCommunityContextName, 1791 snmpCommunityTransportTag, 1792 snmpCommunityStorageType, 1793 snmpCommunityStatus, 1794 snmpTargetAddrTMask, 1795 snmpTargetAddrMMS 1796 } 1797 STATUS current 1798 DESCRIPTION 1799 "A collection of objects providing for configuration 1800 of community strings for SNMPv1 (and SNMPv2c) usage." 1801 ::= { snmpCommunityMIBGroups 1 } 1803 snmpProxyTrapForwardGroup OBJECT-GROUP 1804 OBJECTS { 1805 snmpTrapAddress, 1806 snmpTrapCommunity 1807 } 1808 STATUS current 1809 DESCRIPTION 1810 "Objects which are used by proxy forwarding applications 1811 when translating traps between SNMP versions. These are 1812 used to preserve SNMPv1-specific information when 1813 translating to SNMPv2c or SNMPv3." 1814 ::= { snmpCommunityMIBGroups 3 } 1816 END 1818 6. Intellectual Property 1820 The IETF takes no position regarding the validity or scope of any 1821 intellectual property or other rights that might be claimed to 1822 pertain to the implementation or use of the technology described in 1823 this document or the extent to which any license under such rights 1824 might or might not be available; neither does it represent that it 1825 has made any effort to identify any such rights. Information on the 1826 IETF's procedures with respect to rights in standards-track and 1827 standards-related documentation can be found in BCP-11. Copies of 1828 claims of rights made available for publication and any assurances of 1829 licenses to be made available, or the result of an attempt made to 1830 obtain a general license or permission for the use of such 1831 proprietary rights by implementors or users of this specification can 1832 be obtained from the IETF Secretariat. 1834 The IETF invites any interested party to bring to its attention any 1835 copyrights, patents or patent applications, or other proprietary 1836 rights which may cover technology that may be required to practice 1837 this standard. Please address the information to the IETF Executive 1838 Director. 1840 7. Acknowledgments 1842 This document is the result of the efforts of the SNMPv3 Working 1843 Group. The design of the SNMP-COMMUNITY-MIB incorporates work done 1844 by the authors of SNMPv2*: 1846 Jeff Case (SNMP Research, Inc.) 1847 David Harrington (Cabletron Systems Inc.) 1848 David Levi (SNMP Research, Inc.) 1849 Brian O'Keefe (Hewlett Packard) 1850 Jon Saperia (IronBridge Networks, Inc.) 1851 Steve Waldbusser (International Network Services) 1853 8. Security Considerations 1855 Although SNMPv1 and SNMPv2 do not provide any security, allowing 1856 community names to be mapped into securityName/contextName provides 1857 the ability to use view-based access control to limit the access of 1858 unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for 1859 network administrators to make use of this capability in order to 1860 avoid unauthorized access to MIB data that would otherwise be secure. 1862 Further, the SNMP-COMMUNITY-MIB has the potential to expose community 1863 strings which provide access to more information than that which is 1864 available using the usual 'public' community string. For this 1865 reason, a security administrator may wish to limit accessibility to 1866 the SNMP-COMMUNITY-MIB, and in particular, to make it inaccessible 1867 when using the 'public' community string. 1869 When a proxy implementation translates messages between SNMPv1 (or 1870 SNMPv2c) and SNMPv3, there may be a loss of security. For example, 1871 an SNMPv3 message received using authentication and privacy which is 1872 subsequently forwarded using SNMPv1 will lose the security benefits 1873 of using authentication and privacy. Careful configuration of 1874 proxies is required to address such situations. One approach to deal 1875 with such situations might be to use an encrypted tunnel. 1877 9. References 1879 [1] Rose, M. and K. McCloghrie, "Structure and Identification of 1880 Management Information for TCP/IP-based internets"", STD16, RFC 1881 1155, May 1990. 1883 [2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1884 Management Protocol", STD15, RFC 1157, SNMP Research, Performance 1885 Systems International, Performance Systems International, MIT 1886 Laboratory for Computer Science, May 1990. 1888 [3] McCloghrie, K., and M. Rose, Editors, "Concise MIB Definitions", 1889 STD 16, RFC 1212, Hughes LAN Systems, Performance Systems 1890 International, March 1991. 1892 [4] Rose, M. T., "A Convention for Defining Traps for use with the 1893 SNMP", RFC 1215, March 1991. 1895 [5] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP- 1896 based Agents", RFC 1303, Hughes LAN Systems, Dover Beach 1897 Consulting, Inc., February 1992. 1899 [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1900 Waldbusser, "Introduction to Community-based SNMPv2", RFC1901, SNMP 1901 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1902 International Network Services, January 1996. 1904 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1905 and S. Waldbusser, "Structure of Management Information Version 2 1906 (SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU 1907 Braunschweig, SNMP Research, First Virtual Holdings, International 1908 Network Services, April 1999. 1910 [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1911 and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 1912 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First 1913 Virtual Holdings, International Network Services, April 1999. 1915 [9] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1916 and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, 1917 STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, 1918 First Virtual Holdings, International Network Services, April 1999. 1920 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1921 Waldbusser, "Protocol Operations for Version 2 of the Simple 1922 Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., 1923 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 1924 Network Services, January 1996. 1926 [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport 1927 Mappings for Version 2 of the Simple Network Management Protocol 1928 (SNMPv2)", RFC 1906, January 1996. 1930 [12] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1931 Waldbusser, "Management Information Base for Version 2 of the 1932 Simple Network Management Protocol (SNMPv2)", RFC1907, SNMP 1933 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1934 International Network Services, January 1996. 1936 [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1937 Waldbusser, "Coexistence between Version 1 and Version 2 of the 1938 Internet-standard Network Management Framework", RFC1908, SNMP 1939 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1940 International Network Services, January 1996. 1942 [14] Levi, D., Wijnen, B., "Mapping SNMPv2 onto SNMPv1 within a bi- 1943 lingual SNMP agent", RFC2089, SNMP Research, Inc., IBM, January 1944 1997. 1946 [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1947 Levels", BCP 14, RFC 2119, March 1997. 1949 [16] The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An 1950 Architecture for Describing SNMP Management Frameworks", RFC 2571, 1951 May 1999. 1953 [17] The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B., 1954 "Message Processing and Dispatching for the Simple Network 1955 Management Protocol (SNMP)", RFC 2572, May 1999. 1957 [18] The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMP 1958 Applications", RFC2573, May 1999. 1960 [19] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User- 1961 Based Security Model for Version 3 of the Simple Network Management 1962 Protocol (SNMP)", RFC 2574, May 1999. 1964 [20] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K., 1965 "View-based Access Control Model for the Simple Network Management 1966 Protocol (SNMP)", RFC 2575, May 1999. 1968 10. Editor's Addresses 1970 Rob Frye 1971 MCI WorldCom 1972 2100 Reston Parkway, Suite 600 1973 Reston, VA 20191 1974 U.S.A. 1975 Phone: +1 703 715 7225 1976 EMail: Rob.Frye@wcom.com 1978 David B. Levi 1979 Nortel Networks 1980 3505 Kesterwood Drive 1981 Knoxville, TN 37918 1982 U.S.A. 1983 Phone: +1 423 686 0432 1984 EMail: dlevi@nortelnetworks.com 1986 Shawn A. Routhier 1987 Integrated Systems Inc. 1988 333 North Ave 4th Floor 1989 Wakefield MA 01880 1990 U.S.A. 1991 Phone: + 1 781 245 0804 1992 EMail: sar@epilogue.com 1994 Bert Wijnen 1995 IBM T. J. Watson Research 1996 Schagen 33 1997 3461 GL Linschoten 1998 Netherlands 1999 Phone: +31 348 432 794 2000 EMail: wijnen@vnet.ibm.com 2002 A. Full Copyright Statement 2004 This document and translations of it may be copied and furnished to 2005 others, and derivative works that comment on or otherwise explain it 2006 or assist in its implementation may be prepared, copied, published 2007 and distributed, in whole or in part, without restriction of any 2008 kind, provided that the above copyright notice and this paragraph are 2009 included on all such copies and derivative works. However, this 2010 document itself may not be modified in any way, such as by removing 2011 the copyright notice or references to the Internet Society or other 2012 Internet organizations, except as needed for the purpose of 2013 developing Internet standards in which case the procedures for 2014 copyrights defined in the Internet Standards process must be 2015 followed, or as required to translate it into languages other than 2016 English. 2018 The limited permissions granted above are perpetual and will not be 2019 revoked by the Internet Society or its successors or assigns. 2021 This document and the information contained herein is provided on an 2022 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2023 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2024 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2025 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2026 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.