idnits 2.17.1 draft-ietf-snmpv3-coex-v2-01.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 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 ([21]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The abstract seems to indicate that this document obsoletes RFC2576, 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 64 has weird spacing: '...ameters to S...' == Line 66 has weird spacing: '...ameters to S...' == Line 552 has weird spacing: '...rameter snmp...' == Line 1151 has weird spacing: '...ailable gen...' == Line 2078 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 (21 Nov 2001) is 8191 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) == Unused Reference: '13' is defined on line 1992, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1998, but no explicit reference was found in the text ** 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) ** Obsolete normative reference: RFC 2576 (ref. '21') (Obsoleted by RFC 3584) -- Possible downref: Non-RFC (?) normative reference: ref. '22' Summary: 21 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Coexistence between SNMP versions 21 Nov 2001 4 INTERNET-DRAFT Rob Frye 5 Vibrant Solutions 6 David B. Levi 7 Nortel Networks 8 Shawn A. Routhier 9 Integrated Systems Inc. 10 Bert Wijnen 11 Lucent Technologies 12 21 Nov 2001 14 Coexistence between Version 1, Version 2, and Version 3 15 of the Internet-standard Network Management Framework 16 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright Notice 39 Copyright (C) The Internet Society (2001). All Rights Reserved. 41 Abstract 43 The purpose of this document is to describe coexistence between 44 version 3 of the Internet-standard Network Management Framework, 45 (SNMPv3), version 2 of the Internet-standard Network Management 46 Framework (SNMPv2), and the original Internet-standard Network 47 Management Framework (SNMPv1). This document obsoletes RFC 2576 48 [21]. 50 Table Of Contents 52 1 Overview ..................................................... 5 53 1.1 SNMPv1 ..................................................... 5 54 1.2 SNMPv2 ..................................................... 6 55 1.3 SNMPv3 ..................................................... 7 56 1.4 SNMPv1 and SNMPv2 Access to MIB Data ....................... 7 57 2 SMI and Management Information Mappings ...................... 9 58 2.1 MIB Modules ................................................ 9 59 2.1.1 Object Definitions ....................................... 9 60 2.1.2 Trap and Notification Definitions ........................ 12 61 2.2 Compliance Statements ...................................... 12 62 2.3 Capabilities Statements .................................... 13 63 3 Translating Notifications Parameters ......................... 14 64 3.1 Translating SNMPv1 Notification Parameters to SNMPv2 65 Notification Parameters ................................... 15 66 3.2 Translating SNMPv2 Notification Parameters to SNMPv1 67 Notification Parameters ................................... 16 68 4 Approaches to Coexistence in a Multi-lingual Network ......... 19 69 4.1 Multi-lingual implementations .............................. 19 70 4.1.1 Command Generator ........................................ 19 71 4.1.2 Command Responder ........................................ 20 72 4.1.2.1 Handling Counter64 ..................................... 20 73 4.1.2.2 Mapping SNMPv2 Exceptions .............................. 21 74 4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 22 75 4.1.2.2.2 Mapping endOfMibView ................................. 22 76 4.1.2.3 Processing An SNMPv1 GetRequest ........................ 22 77 4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 23 78 4.1.2.5 Processing An SNMPv1 SetRequest ........................ 25 79 4.1.3 Notification Originator .................................. 25 80 4.1.4 Notification Receiver .................................... 26 81 4.2 Proxy Implementations ...................................... 26 82 4.2.1 Upstream Version Greater Than Downstream Version ......... 26 83 4.2.2 Upstream Version Less Than Downstream Version ............ 27 84 4.3 Error Status Mappings ...................................... 30 85 5 Message Processing Models and Security Models ................ 31 86 5.1 Mappings ................................................... 31 87 5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security 88 Model ..................................................... 31 89 5.2.1 Processing An Incoming Request ........................... 32 90 5.2.2 Generating An Outgoing Response .......................... 34 91 5.2.3 Generating An Outgoing Notification ...................... 34 92 5.2.4 Proxy Forwarding Of Requests ............................. 35 93 5.3 The SNMP Community MIB Module .............................. 36 94 6 Intellectual Property ........................................ 47 95 7 Acknowledgments .............................................. 48 96 Table Of Contents 98 8 Security Considerations ...................................... 49 99 9 References ................................................... 50 100 10 Editor's Addresses .......................................... 53 101 A. Full Copyright Statement .................................... 54 102 B. Changes From RFC1908 ........................................ 55 104 1. Overview 106 The purpose of this document is to describe coexistence between 107 version 3 of the Internet-standard Network Management Framework, 108 termed the SNMP version 3 framework (SNMPv3), version 2 of the 109 Internet-standard Network Management Framework, termed the SNMP 110 version 2 framework (SNMPv2), and the original Internet-standard 111 Network Management Framework (SNMPv1). 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC2119 [15]. 117 There are four general aspects of coexistence described in this 118 document. Each of these is described in a separate section: 120 - Conversion of MIB documents between SMIv1 and SMIv2 formats is 121 documented in section 2. 123 - Mapping of notification parameters is documented in section 3. 125 - Approaches to coexistence between entities which support the 126 various versions of SNMP in a multi-lingual network is 127 documented in section 4. This section addresses the 128 processing of protocol operations in multi-lingual 129 implementations, as well as behaviour of proxy 130 implementations. 132 - The SNMPv1 Message Processing Model and Community-Based 133 Security Model, which provides mechanisms for adapting SNMPv1 134 into the View-Based Access Control Model (VACM) [20], is 135 documented in section 5 (this section also addresses the 136 SNMPv2c Message Processing Model and Community-Based Security 137 Model). 139 1.1. SNMPv1 141 SNMPv1 is defined by these documents: 143 - STD 15, RFC 1157 [2] which defines the Simple Network 144 Management Protocol (SNMPv1), the protocol used for network 145 access to managed objects. 147 - STD 16, RFC 1155 [1] which defines the Structure of Management 148 Information (SMIv1), the mechanisms used for describing and 149 naming objects for the purpose of management. 151 - STD 16, RFC 1212 [3] which defines a more concise description 152 mechanism, which is wholly consistent with the SMIv1. 154 - RFC 1215 [4] which defines a convention for defining Traps for 155 use with the SMIv1. 157 Note that throughout this document, the term 'SMIv1' is used. This 158 term generally refers to the information presented in RFC 1155, RFC 159 1212, and RFC 1215. 161 1.2. SNMPv2 163 SNMPv2 is defined by these documents: 165 - STD 58, RFC 2578 which defines Version 2 of the Structure of 166 Management Information (SMIv2) [7]. 168 - STD 58, RFC 2579 which defines common MIB "Textual 169 Conventions" [8]. 171 - STD 58, RFC 2580 which defines Conformance Statements and 172 requirements for defining agent and manager capabilities [9]. 174 - RFC 1905 which defines the Protocol Operations used in 175 processing [10]. 177 - RFC 1906 which defines the Transport Mappings used "on the 178 wire" [11]. 180 - RFC 1907 which defines the basic Management Information Base 181 for monitoring and controlling some basic common functions of 182 SNMP entities [12]. 184 Note that SMIv2 as used throughout this document refers to the first 185 three documents listed above (RFCs 2578, 2579, and 2580). 187 The following document augments the definition of SNMPv2: 189 - RFC 1901 [6] is an Experimental definition for using SNMPv2 190 PDUs within a community-based message wrapper. This is 191 referred to throughout this document as SNMPv2c. 193 1.3. SNMPv3 195 SNMPv3 is defined by these documents: 197 - RFC 2571 which defines an Architecture for Describing SNMP 198 Management Frameworks [16]. 200 - RFC 2572 which defines Message Processing and Dispatching 201 [17]. 203 - RFC 2573 which defines various SNMP Applications [18]. 205 - RFC 2574 which defines the User-based Security Model (USM), 206 providing for both Authenticated and Private (encrypted) SNMP 207 messages [19]. 209 - RFC 2575 which defines the View-based Access Control Model 210 (VACM), providing the ability to limit access to different MIB 211 objects on a per-user basis [20]. 213 SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 and 214 the SMIv2 definitions of 2578 through 2580 described above. 216 1.4. SNMPv1 and SNMPv2 Access to MIB Data 218 In several places, this document refers to 'SNMPv1 Access to MIB 219 Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the part 220 of an SNMP agent which actually accesses instances of MIB objects, 221 and which actually initiates generation of notifications. 222 Differences between the two types of access to MIB data are: 224 - Error-status values generated. 226 - Generation of exception codes. 228 - Use of the Counter64 data type. 230 - The format of parameters provided when a notification is 231 generated. 233 SNMPv1 access to MIB data may generate SNMPv1 error-status values, 234 will never generate exception codes nor use the Counter64 data type, 235 and will provide SNMPv1 format parameters for generating 236 notifications. Note also that SNMPv1 access to MIB data will 237 actually never generate a readOnly error (a noSuchName error would 238 always occur in the situation where one would expect a readOnly 239 error). 241 SNMPv2 access to MIB data may generate SNMPv2 error-status values, 242 may generate exception codes, may use the Counter64 data type, and 243 will provide SNMPv2 format parameters for generating notifications. 244 Note that SNMPv2 access to MIB data will never generate readOnly, 245 noSuchName, or badValue errors. 247 Note that a particular multi-lingual implementation may choose to 248 implement all access to MIB data as SNMPv2 access to MIB data, and 249 perform the translations described herein for SNMPv1-based 250 transactions. 252 2. SMI and Management Information Mappings 254 The SMIv2 approach towards describing collections of managed objects 255 is nearly a proper superset of the approach defined in the SMIv1. 256 For example, both approaches use an adapted subset of ASN.1 [22] as 257 the basis for a formal descriptive notation. Indeed, one might note 258 that the SMIv2 approach largely codifies the existing practice for 259 defining MIB modules, based on extensive experience with the SMIv1. 261 The following sections consider the three areas: MIB modules, 262 compliance statements, and capabilities statements. 264 2.1. MIB Modules 266 MIB modules defined using the SMIv1 may continue to be used with 267 protocol versions which use SNMPv2 PDUs. However, for the MIB 268 modules to conform to the SMIv2, the following changes SHALL be made: 270 2.1.1. Object Definitions 272 In general, conversion of a MIB module does not require the 273 deprecation of the objects contained therein. If the definition of 274 an object is truly inadequate for its intended purpose, the object 275 SHALL be deprecated or obsoleted, otherwise deprecation is not 276 required. 278 (1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of 279 RFC1155-SMI and RFC-1212. 281 (2) The MODULE-IDENTITY macro MUST be invoked immediately after any 282 IMPORTs statement. 284 (3) For any object with an integer-valued SYNTAX clause, in which the 285 corresponding INTEGER does not have a range restriction (i.e., the 286 INTEGER has neither a defined set of named-number enumerations nor 287 an assignment of lower- and upper-bounds on its value), the object 288 MUST have the value of its SYNTAX clause changed to Integer32, or 289 have an appropriate range specified. 291 (4) For any object with a SYNTAX clause value of Counter, the object 292 MUST have the value of its SYNTAX clause changed to Counter32. 294 (5) For any object with a SYNTAX clause value of Gauge, the object MUST 295 have the value of its SYNTAX clause changed to Gauge32, or 296 Unsigned32 where appropriate. 298 (6) For all objects, the ACCESS clause MUST be replaced by a MAX-ACCESS 299 clause. The value of the MAX-ACCESS clause SHALL be the same as 300 that of the ACCESS clause unless some other value makes "protocol 301 sense" as the maximal level of access for the object. In 302 particular, object types for which instances can be explicitly 303 created by a protocol set operation, SHALL have a MAX-ACCESS clause 304 of "read-create". If the value of the ACCESS clause is "write- 305 only", then the value of the MAX-ACCESS clause MUST be "read- 306 write", and the DESCRIPTION clause SHALL note that reading this 307 object will result in implementation-specific results. Note that 308 in SMIv1, the ACCESS clause specifies the minimal required access, 309 while in SMIv2, the MAX-ACCESS clause specifies the maximum allowed 310 access. This should be considered when converting an ACCESS clause 311 to a MAX-ACCESS clause. 313 (7) For all objects, if the value of the STATUS clause is "mandatory" 314 or "optional", the value MUST be replaced with "current", 315 "deprecated", or "obsolete" depending on the current usage of such 316 objects. 318 (8) For any object not containing a DESCRIPTION clause, the object MUST 319 have a DESCRIPTION clause defined. 321 (9) For any object corresponding to a conceptual row which does not 322 have an INDEX clause, the object MUST have either an INDEX clause 323 or an AUGMENTS clause defined. 325 (10) If any INDEX clause contains a reference to an object with a syntax 326 of NetworkAddress, then a new object MUST be created and placed in 327 this INDEX clause immediately preceding the object whose syntax is 328 NetworkAddress. This new object MUST have a syntax of INTEGER, it 329 MUST be not-accessible, and its value MUST always be 1. This 330 approach allows one to convert a MIB module in SMIv1 format to one 331 in SMIv2 format, and then use it with the SNMPv1 protocol with no 332 impact to existing SNMPv1 agents and managers. 334 (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be 335 changed to IpAddress. Note that the use of NetworkAddress in new 336 MIB documents is strongly discouraged (in fact, new MIB documents 337 should be written using SMIv2, which does not define 338 NetworkAddress). 340 (12) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER 341 value which is expressed as a collection of sub-identifiers, the 342 value MUST be changed to reference a single ASN.1 identifier. This 343 may require defining a series of new administrative assignments 344 (OBJECT IDENTIFIERS) in order to define the single ASN.1 345 identifier. 347 (13) One or more OBJECT-GROUPS MUST be defined, and related objects MUST 348 be collected into appropriate groups. Note that SMIv2 requires all 349 OBJECT-TYPEs to be a member of at least one OBJECT-GROUP. 351 Other changes are desirable, but not necessary: 353 (1) Creation and deletion of conceptual rows is inconsistent using the 354 SMIv1. The SMIv2 corrects this. As such, if the MIB module 355 undergoes review early in its lifetime, and it contains conceptual 356 tables which allow creation and deletion of conceptual rows, then 357 the objects relating to those tables MAY be deprecated and replaced 358 with objects defined using the new approach. The approach based on 359 SMIv2 can be found in section 7 of RFC2578 [7], and the RowStatus 360 and StorageType TEXTUAL-CONVENTIONs are described in section 2 of 361 RFC2579 [8]. 363 (2) For any object with a string-valued SYNTAX clause, in which the 364 corresponding OCTET STRING does not have a size restriction (i.e., 365 the OCTET STRING has no assignment of lower- and upper-bounds on 366 its length), the bounds for the size of the object SHOULD be 367 defined. 369 (3) All textual conventions informally defined in the MIB module SHOULD 370 be redefined using the TEXTUAL-CONVENTION macro. Such a change 371 would not necessitate deprecating objects previously defined using 372 an informal textual convention. 374 (4) For any object which represents a measurement in some kind of 375 units, a UNITS clause SHOULD be added to the definition of that 376 object. 378 (5) For any conceptual row which is an extension of another conceptual 379 row, i.e., for which subordinate columnar objects both exist and 380 are identified via the same semantics as the other conceptual row, 381 an AUGMENTS clause SHOULD be used in place of the INDEX clause for 382 the object corresponding to the conceptual row which is an 383 extension. 385 Finally, to avoid common errors in SMIv1 MIB modules: 387 (1) For any non-columnar object that is instanced as if it were 388 immediately subordinate to a conceptual row, the value of the 389 STATUS clause of that object MUST be changed to "obsolete". 391 (2) For any conceptual row object that is not immediately subordinate 392 to a conceptual table, the value of the STATUS clause of that 393 object (and all subordinate objects) MUST be changed to "obsolete". 395 2.1.2. Trap and Notification Definitions 397 If a MIB module is changed to conform to the SMIv2, then each 398 occurrence of the TRAP-TYPE macro MUST be changed to a corresponding 399 invocation of the NOTIFICATION-TYPE macro: 401 (1) The IMPORTS statement MUST NOT reference RFC-1215 [4], and MUST 402 reference SNMPv2-SMI instead. 404 (2) The ENTERPRISE clause MUST be removed. 406 (3) The VARIABLES clause MUST be renamed to the OBJECTS clause. 408 (4) A STATUS clause MUST be added, with an appropriate value. Normally 409 the value should be 'current,' although 'deprecated' or 'obsolete' 410 may be used as needed. 412 (5) The value of an invocation of the NOTIFICATION-TYPE macro is an 413 OBJECT IDENTIFIER, not an INTEGER, and MUST be changed accordingly. 414 Specifically, if the value of the ENTERPRISE clause is not 'snmp' 415 then the value of the invocation SHALL be the value of the 416 ENTERPRISE clause extended with two sub-identifiers, the first of 417 which has the value 0, and the second has the value of the 418 invocation of the TRAP-TYPE. If the value of the ENTERPRISE clause 419 is 'snmp', then the value of the invocation of the NOTIFICATION- 420 TYPE macro SHALL be mapped in the same manner as described in 421 section 3.1 in this document. 423 (6) A DESCRIPTION clause MUST be added, if not already present. 425 (7) One or more NOTIFICATION-GROUPs MUST be defined, and related 426 notifications MUST be collected into those groups. Note that SMIv2 427 requires that all NOTIFICATION-TYPEs be a member of at least one 428 NOTIFICATION-GROUP. 430 2.2. Compliance Statements 432 For those information modules which are "standards track", a 433 corresponding invocation of the MODULE-COMPLIANCE macro and related 434 OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included within 435 the information module (or in a companion information module), and 436 any commentary text in the information module which relates to 437 compliance SHOULD be removed. Typically this editing can occur when 438 the information module undergoes review. 440 Note that a MODULE-COMPLIANCE statement is not required for a MIB 441 document that is not on the standards track (for example, an 442 enterprise MIB), though it may be useful in some circumstances to 443 define a MODULE-COMPLIANCE statement for such a MIB document. 445 2.3. Capabilities Statements 447 RFC1303 [5] uses the MODULE-CONFORMANCE macro to describe an agent's 448 capabilities with respect to one or more MIB modules. Converting 449 such a description for use with the SMIv2 requires these changes: 451 (1) The macro name AGENT-CAPABILITIES MUST be used instead of MODULE- 452 CONFORMANCE. 454 (2) The STATUS clause MUST be added, with a value of 'current'. 456 (3) All occurrences of the CREATION-REQUIRES clause MUST either be 457 omitted if appropriate, or be changed such that the semantics are 458 consistent with RFC2580 [9]. 460 In order to ease coexistence, object groups defined in an SMIv1 461 compliant MIB module may be referenced by the INCLUDES clause of an 462 invocation of the AGENT-CAPABILITIES macro: upon encountering a 463 reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB 464 module, all leaf objects which are subordinate to the subtree and 465 have a STATUS clause value of mandatory are deemed to be INCLUDEd. 466 (Note that this method is ambiguous when different revisions of an 467 SMIv1 MIB have different sets of mandatory objects under the same 468 subtree; in such cases, the only solution is to rewrite the MIB using 469 the SMIv2 in order to define the object groups unambiguously.) 471 3. Translating Notifications Parameters 473 This section describes how parameters used for generating 474 notifications are translated between the format used for SNMPv1 475 notification protocol operations and the format used for SNMPv2 476 notification protocol operations. The parameters used to generate a 477 notification are called 'notification parameters.' The format of 478 parameters used for SNMPv1 notification protocol operations is 479 refered to in this document as 'SNMPv1 notification parameters.' The 480 format of parameters used for SNMPv2 notification protocol operations 481 is refered to in this document as 'SNMPv2 notification parameters.' 483 The situations where notification parameters MUST be translated are: 485 - When an entity generates a set of notification parameters in a 486 particular format, and the configuration of the entity 487 indicates that the notification must be sent using an SNMP 488 message version that requires the other format for 489 notification parameters. 491 - When a proxy receives a notification that was sent using an 492 SNMP message version that requires one format of notification 493 parameters, and must forward the notification using an SNMP 494 message version that requires the other format of notification 495 parameters. 497 In addition, it MAY be desirable to translate notification parameters 498 in a notification receiver application in order to present 499 notifications to the end user in a consistent format. 501 Note that for the purposes of this section, the set of notification 502 parameters is independent of whether the notification is to be sent 503 as a trap or an inform. 505 SNMPv1 notification parameters consist of: 507 - An enterprise parameter (OBJECT IDENTIFIER). 509 - An agent-addr parameter (NetworkAddress). 511 - A generic-trap parameter (INTEGER). 513 - A specific-trap parameter (INTEGER). 515 - A time-stamp parameter (TimeTicks). 517 - A list of variable-bindings (VarBindList). 519 SNMPv2 notification parameters consist of: 521 - A sysUpTime parameter (TimeTicks). This appears in the first 522 variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU. 524 - An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in 525 the second variable-binding in an SNMPv2-Trap-PDU or 526 InformRequest-PDU, and is equal to the value portion of that 527 variable-binding (not the name portion, as both the name and 528 value are OBJECT IDENTIFIERs). 530 - A list of variable-bindings (VarBindList). This refers to all 531 but the first two variable-bindings in an SNMPv2-Trap-PDU or 532 InformRequest-PDU. 534 3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification 535 Parameters 537 The following procedure describes how to translate SNMPv1 538 notification parameters into SNMPv2 notification parameters: 540 (1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the 541 SNMPv1 time-stamp parameter. 543 (2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)', 544 the SNMPv2 snmpTrapOID parameter SHALL be the concatenation of the 545 SNMPv1 enterprise parameter and two additional sub-identifiers, 546 '0', and the SNMPv1 specific-trap parameter. 548 (3) If the SNMPv1 generic-trap parameter is not 549 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be 550 the corresponding trap as defined in section 2 of RFC1907 [12]: 552 generic-trap parameter snmpTrapOID.0 553 ====================== ============= 554 0 1.3.6.1.6.3.1.1.5.1 (coldStart) 555 1 1.3.6.1.6.3.1.1.5.2 (warmStart) 556 2 1.3.6.1.6.3.1.1.5.3 (linkDown) 557 3 1.3.6.1.6.3.1.1.5.4 (linkUp) 558 4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 559 5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 561 (4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-bindings. 562 In addition, if the translation is being performed by a proxy in 563 order to forward a received trap, three additional variable- 564 bindings will be appended, if these three additional variable- 565 bindings do not already exist in the SNMPv1 variable-bindings. The 566 name portion of the first additional variable binding SHALL contain 567 snmpTrapAddress.0, and the value SHALL contain the SNMPv1 agent- 568 addr parameter. The name portion of the second additional variable 569 binding SHALL contain snmpTrapCommunity.0, and the value SHALL 570 contain the value of the community-string field from the received 571 SNMPv1 message which contained the SNMPv1 Trap-PDU. The name 572 portion of the third additional variable binding SHALL contain 573 snmpTrapEnterprise.0 [12], and the value SHALL be the SNMPv1 574 enterprise parameter. 576 3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification 577 Parameters 579 The following procedure describes how to translate SNMPv2 580 notification parameters into SNMPv1 notification parameters: 582 (1) The SNMPv1 enterprise parameter SHALL be determined as follows: 584 - If the SNMPv2 snmpTrapOID parameter is one of the standard 585 traps as defined in RFC1907 [12], then the SNMPv1 enterprise 586 parameter SHALL be set to the value of the variable-binding in 587 the SNMPv2 variable-bindings whose name is 588 snmpTrapEnterprise.0 if that variable-binding exists. If it 589 does not exist, the SNMPv1 enterprise parameter SHALL be set 590 to the value 'snmpTraps' as defined in RFC1907 [12]. 592 - If the SNMPv2 snmpTrapOID parameter is not one of the standard 593 traps as defined in RFC1907 [12], then the SNMPv1 enterprise 594 parameter SHALL be determined from the SNMPv2 snmpTrapOID 595 parameter as follows: 597 - If the next-to-last sub-identifier of the snmpTrapOID 598 value is zero, then the SNMPv1 enterprise SHALL be the 599 SNMPv2 snmpTrapOID value with the last 2 sub-identifiers 600 removed, otherwise 602 - If the next-to-last sub-identifier of the snmpTrapOID 603 value is non-zero, then the SNMPv1 enterprise SHALL be the 604 SNMPv2 snmpTrapOID value with the last sub-identifier 605 removed. 607 (2) The SNMPv1 agent-addr parameter SHALL be determined based on the 608 situation in which the translation occurs. 610 - If the translation occurs within a notification originator 611 application, and the notification is to be sent over IP, the 612 SNMPv1 agent-addr parameter SHALL be set to the IP address of 613 the SNMP entity in which the notification originator resides. 614 If the notification is to be sent over some other transport, 615 the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0. 617 - If the translation occurs within a proxy application, the 618 proxy must attempt to extract the original source of the 619 notification from the variable-bindings. If the SNMPv2 620 variable-bindings contains a variable binding whose name is 621 snmpTrapAddress.0, the agent-addr parameter SHALL be set to 622 the value of that variable binding. Otherwise, the SNMPv1 623 agent-addr parameter SHALL be set to 0.0.0.0. 625 (3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as 626 defined in RFC1907 [12], the SNMPv1 generic-trap parameter SHALL be 627 set as follows: 629 snmpTrapOID.0 parameter generic-trap 630 =============================== ============ 631 1.3.6.1.6.3.1.1.5.1 (coldStart) 0 632 1.3.6.1.6.3.1.1.5.2 (warmStart) 1 633 1.3.6.1.6.3.1.1.5.3 (linkDown) 2 634 1.3.6.1.6.3.1.1.5.4 (linkUp) 3 635 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4 636 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5 638 Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6. 640 (4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as 641 defined in RFC1907 [12], the SNMPv1 specific-trap parameter SHALL 642 be set to zero. Otherwise, the SNMPv1 specific-trap parameter 643 SHALL be set to the last sub-identifier of the SNMPv2 snmpTrapOID 644 parameter. 646 (5) The SNMPv1 time-stamp parameter SHALL be taken directly from the 647 SNMPv2 sysUpTime parameter. 649 (6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-bindings, 650 with the variable-bindings containing sysUpTime.0, snmpTrapOID.0, 651 and snmpTrapAddress.0 removed. Note, however, that if the SNMPv2 652 variable-bindings contain any objects whose type is Counter64, the 653 translation to SNMPv1 notification parameters cannot be performed. 654 In this case, the notification cannot be encoded in an SNMPv1 655 packet (and so the notification cannot be sent using SNMPv1, see 656 section 4.1.3 and section 4.2). 658 4. Approaches to Coexistence in a Multi-lingual Network 660 There are two basic approaches to coexistence in a multi-lingual 661 network, multi-lingual implementations and proxy implementations. 662 Multi-lingual implementations allow elements in a network to 663 communicate with each other using an SNMP version which both elements 664 support. This allows a multi-lingual implementation to communicate 665 with any mono-lingual implementation, regardless of the SNMP version 666 supported by the mono-lingual implementation. 668 Proxy implementations provide a mechanism for translating between 669 SNMP versions using a third party network element. This allows 670 network elements which support only a single, but different, SNMP 671 version to communicate with each other. Proxy implementations are 672 also useful for securing communications over an insecure link between 673 two locally secure networks. 675 4.1. Multi-lingual implementations 677 This approach requires an entity to support multiple SNMP message 678 versions. Typically this means supporting SNMPv1, SNMPv2c, and 679 SNMPv3 message versions. The behaviour of various types of SNMP 680 applications which support multiple message versions is described in 681 the following sections. This approach allows entities which support 682 multiple SNMP message versions to coexist with and communicate with 683 entities which support only a single SNMP message version. 685 4.1.1. Command Generator 687 A command generator must select an appropriate message version when 688 sending requests to another entity. One way to achieve this is to 689 consult a local database to select the appropriate message version. 691 In addition, a command generator MUST 'downgrade' GetBulk requests to 692 GetNext requests when selecting SNMPv1 as the message version for an 693 outgoing request. This is done by simply changing the operation type 694 to GetNext, ignoring any non-repeaters and max-repetitions values, 695 and setting error-status and error-index to zero. 697 4.1.2. Command Responder 699 A command responder must be able to deal with both SNMPv1 and SNMPv2 700 access to MIB data. There are three aspects to dealing with this. A 701 command responder must: 703 - Deal correctly with SNMPv2 access to MIB data that returns a 704 Counter64 value while processing an SNMPv1 message, 706 - Deal correctly with SNMPv2 access to MIB data that returns one 707 of the three exception values while processing an SNMPv1 708 message, and 710 - Map SNMPv2 error codes returned from SNMPv2 access to MIB data 711 into SNMPv1 error codes when processing an SNMPv1 message. 713 Note that SNMPv1 error codes SHOULD NOT be used without any change 714 when processing SNMPv2c or SNMPv3 messages, except in the case of 715 proxy forwarding. In the case of proxy forwarding, for backwards 716 compatibility, SNMPv1 error codes may be used without any change in a 717 forwarded SNMPv2c or SNMPv3 message. 719 The following sections describe the behaviour of a command responder 720 application which supports multiple SNMP message versions, and which 721 uses some combination of SNMPv1 and SNMPv2 access to MIB data. 723 4.1.2.1. Handling Counter64 725 The SMIv2 [7] defines one new syntax that is incompatible with SMIv1. 726 This syntax is Counter64. All other syntaxes defined by SMIv2 are 727 compatible with SMIv1. 729 The impact on multi-lingual command responders is that they MUST NOT 730 ever return a variable binding containing a Counter64 value in a 731 response to a request that was received using the SNMPv1 message 732 version. 734 Multi-lingual command responders SHALL take the approach that object 735 instances whose type is Counter64 are implicitly excluded from view 736 when processing an SNMPv1 message. So: 738 - On receipt of an SNMPv1 GetRequest-PDU containing a variable 739 binding whose name field points to an object instance of type 740 Counter64, a GetResponsePDU SHALL be returned, with an error- 741 status of noSuchName and the error-index set to the variable 742 binding that caused this error. 744 - On an SNMPv1 GetNextRequest-PDU, any object instance which 745 contains a syntax of Counter64 SHALL be skipped, and the next 746 accessible object instance that does not have the syntax of 747 Counter64 SHALL be retrieved. If no such object instance 748 exists, then an error-status of noSuchName SHALL be returned, 749 and the error-index SHALL be set to the variable binding that 750 caused this error. 752 - Any SNMPv1 request which contains a variable binding with a 753 Counter64 value is ill-formed, so the foregoing rules do not 754 apply. If that error is detected, a response SHALL NOT be 755 returned, since it would contain a copy of the ill-formed 756 variable binding. Instead, the offending PDU SHALL be 757 discarded and the counter snmpInASNParseErrs SHALL be 758 incremented. 760 4.1.2.2. Mapping SNMPv2 Exceptions 762 SNMPv2 provides a feature called exceptions, which allow an SNMPv2 763 Response PDU to return as much management information as possible, 764 even when an error occurs. However, SNMPv1 does not support 765 exceptions, and so an SNMPv1 Response PDU cannot return any 766 management information, and can only return an error-status and an 767 error-index value. 769 When an SNMPv1 request is received, a command responder MUST check 770 any variable bindings returned using SNMPv2 access to MIB data for 771 exception values, and convert these exception values into SNMPv1 772 error codes. 774 The type of exception that can be returned when accessing MIB data 775 and the action taken depends on the type of SNMP request. 777 - For a GetRequest, a noSuchObject or noSuchInstance exception 778 may be returned. 780 - For a GetNextRequest, an endOfMibView exception may be 781 returned. 783 - No exceptions will be returned for a SetRequest, and a 784 GetBulkRequest should only be received in an SNMPv2c or SNMPv3 785 message, so these request types may be ignored when mapping 786 exceptions. 788 Note that when a response contains multiple exceptions, it is an 789 implementation choice as to which variable binding the error-index 790 should reference. 792 4.1.2.2.1. Mapping noSuchObject and noSuchInstance 794 A noSuchObject or noSuchInstance exception generated by an SNMPv2 795 access to MIB data indicates that the requested object instance can 796 not be returned. The SNMPv1 error code for this condition is 797 noSuchName, and so the error-status field of the response PDU SHALL 798 be set to noSuchName. Also, the error-index field SHALL be set to 799 the index of the variable binding for which an exception occurred 800 (there may be more than one and it is an implementation decision as 801 to which is used), and the variable binding list from the original 802 request SHALL be returned with the response PDU. 804 4.1.2.2.2. Mapping endOfMibView 806 When an SNMPv2 access to MIB data returns a variable binding 807 containing an endOfMibView exception, it indicates that there are no 808 object instances available which lexicographically follow the object 809 in the request. In an SNMPv1 agent, this condition normally results 810 in a noSuchName error, and so the error-status field of the response 811 PDU SHALL be set to noSuchName. Also, the error-index field SHALL be 812 set to the index of the variable binding for which an exception 813 occurred (there may be more than one and it is an implementation 814 decision as to which is used), and the variable binding list from the 815 original request SHALL be returned with the response PDU. 817 4.1.2.3. Processing An SNMPv1 GetRequest 819 When processing an SNMPv1 GetRequest, the following procedures MUST 820 be followed when using an SNMPv2 access to MIB data. 822 When such an access to MIB data returns response data using SNMPv2 823 syntax and error-status values, then: 825 (1) If the error-status is anything other than noError, 827 - The error status SHALL be translated to an SNMPv1 error-status 828 using the table in section 4.3, "Error Status Mappings". 830 - The error-index SHALL be set to the position (in the original 831 request) of the variable binding that caused the error-status. 833 - The variable binding list of the response PDU SHALL be made 834 exactly the same as the variable binding list that was 835 received in the original request. 837 (2) If the error-status is noError, the variable bindings SHALL be 838 checked for any SNMPv2 exception (noSuchObject or noSuchInstance) 839 or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64). If 840 there are any such variable bindings, one of those variable 841 bindings SHALL be selected (it is an implementation choice as to 842 which is selected), and: 844 - The error-status SHALL be set to noSuchName, 846 - The error-index SHALL be set to the position (in the variable 847 binding list of the original request) of the selected variable 848 binding, and 850 - The variable binding list of the response PDU SHALL be exactly 851 the same as the variable binding list that was received in the 852 original request. 854 (3) If there are no such variable bindings, then: 856 - The error-status SHALL be set to noError, 858 - The error-index SHALL be set to zero, and 860 - The variable binding list of the response SHALL be composed 861 from the data as it is returned by the access to MIB data. 863 4.1.2.4. Processing An SNMPv1 GetNextRequest 865 When processing an SNMPv1 GetNextRequest, the following procedures 866 MUST be followed when an SNMPv2 access to MIB data is called as part 867 of processing the request. There may be repetitive accesses to MIB 868 data to try to find the first object which lexicographically follows 869 each of the objects in the request. This is implementation specific. 870 These procedures are followed only for data returned when using 871 SNMPv2 access to MIB data. Data returned using SNMPv1 access to MIB 872 data may be treated in the normal manner for an SNMPv1 request. 874 First, if the access to MIB data returns an error-status of anything 875 other than noError: 877 (1) The error status SHALL be translated to an SNMPv1 error-status 878 using the table in section 4.3, "Error Status Mappings". 880 (2) The error-index SHALL be set to the position (in the original 881 request) of the variable binding that caused the error-status. 883 (3) The variable binding list of the response PDU SHALL be exactly the 884 same as the variable binding list that was received in the original 885 request. 887 Otherwise, if the access to MIB data returns an error-status of 888 noError: 890 (1) Any variable bindings containing an SNMPv2 syntax of Counter64 891 SHALL be considered to be not in view, and MIB data SHALL be 892 accessed as many times as is required until either a value other 893 than Counter64 is returned, or an error occurs. 895 (2) If there is any variable binding that contains an SNMPv2 exception 896 endOfMibView (there may be more than one, it is an implementation 897 decision as to which is chosen): 899 - The error-status SHALL be set to noSuchName, 901 - The error-index SHALL be set to the position (in the variable 902 binding list of the original request) of the variable binding 903 that returned such an SNMPv2 exception, and 905 - The variable binding list of the response PDU SHALL be exactly 906 the same as the variable binding list that was received in the 907 original request. 909 (3) If there are no such variable bindings, then: 911 - The error-status SHALL be set to noError, 913 - The error-index SHALL be set to zero, and 915 - The variable binding list of the response SHALL be composed 916 from the data as it is returned by the access to MIB data. 918 4.1.2.5. Processing An SNMPv1 SetRequest 920 When processing an SNMPv1 SetRequest, the following procedures MUST 921 be followed when calling SNMPv2 MIB access routines. 923 When such MIB access routines return response data using SNMPv2 924 syntax and error-status values, and the error-status is anything 925 other than noError, then: 927 - The error status SHALL be translated to an SNMPv1 error-status 928 using the table in section 4.3, "Error Status Mappings". 930 - The error-index SHALL be set to the position (in the original 931 request) of the variable binding that caused the error-status. 933 - The variable binding list of the response PDU SHALL be made 934 exactly the same as the variable binding list that was 935 received in the original request. 937 4.1.3. Notification Originator 939 A notification originator must be able to translate between SNMPv1 940 notification parameters and SNMPv2 notification parameters in order 941 to send a notification using a particular SNMP message version. If a 942 notification is generated using SNMPv1 notification parameters, and 943 configuration information specifies that notifications be sent using 944 SNMPv2c or SNMPv3, the notification parameters must be translated to 945 SNMPv2 notification parameters. Likewise, if a notification is 946 generated using SNMPv2 notification parameters, and configuration 947 information specifies that notifications be sent using SNMPv1, the 948 notification parameters must be translated to SNMPv1 notification 949 parameters. In this case, if the notification cannot be translated 950 (due to the presence of a Counter64 type), it will not be sent using 951 SNMPv1. 953 When a notification originator generates a notification, using 954 parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION- 955 MIB, if the SNMP version used to generate the notification is SNMPv1, 956 the PDU type used will always be a TrapPDU, regardless of whether the 957 value of snmpNotifyType is trap(1) or inform(2). 959 Note also that access control and notification filtering are 960 performed in the usual manner for notifications, regardless of the 961 SNMP message version to be used when sending a notification. The 962 parameters for performing access control are found in the usual 963 manner (i.e., from inspecting the SNMP-TARGET-MIB and SNMP- 964 NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in 965 order to perform the access check specified in [18], section 3.3, 966 bullet (3), the notification originator may need to generate a value 967 for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of 968 this document. If the SNMPv1 notification parameters being used were 969 previously translated from a set of SNMPv2 notification parameters, 970 this value may already be known, in which case it need not be 971 generated. 973 4.1.4. Notification Receiver 975 There are no special requirements of a notification receiver. 976 However, an implementation may find it useful to allow a higher level 977 application to request whether notifications should be delivered to a 978 higher level application using SNMPv1 notification parameter or 979 SNMPv2 notification parameters. The notification receiver would then 980 translate notification parameters when required in order to present a 981 notification using the desired set of parameters. 983 4.2. Proxy Implementations 985 A proxy implementation may be used to enable communication between 986 entities which support different SNMP message versions. This is 987 accomplished in a proxy forwarder application by performing 988 translations on PDUs. These translations depend on the PDU type, the 989 SNMP version of the packet containing a received PDU, and the SNMP 990 version to be used to forward a received PDU. The following sections 991 describe these translations. In all cases other than those described 992 below, the proxy SHALL forward a received PDU without change, subject 993 to size contraints as defined in section 5.3 (Community MIB) of this 994 document. Note that in the following sections, the 'Upstream 995 Version' refers to the version used between the command generator or 996 notification receiver and the proxy, and the 'Downstream Version' 997 refers to the version used between the proxy and the command 998 responder or notification originator, regardless of the PDU type or 999 direction. 1001 4.2.1. Upstream Version Greater Than Downstream Version 1003 - If a GetBulkRequest-PDU is received and must be forwarded 1004 using the SNMPv1 message version, the proxy forwarder SHALL 1005 set the non-repeaters and max-repetitions fields to 0, and 1006 SHALL set the tag of the PDU to GetNextRequest-PDU. 1008 - If a GetResponse-PDU is received whose error-status field has 1009 a value of 'tooBig', and the message will be forwarded using 1010 the SNMPv2c or SNMPv3 message version, and the original 1011 request received by the proxy was not a GetBulkRequest-PDU, 1012 the proxy forwarder SHALL remove the contents of the 1013 variable-bindings field and ensure that the error-index field 1014 is set to 0 before forwarding the response. 1016 - If a GetResponse-PDU is received whose error-status field has 1017 a value of 'tooBig,' and the message will be forwarded using 1018 the SNMPv2c or SNMPv3 message version, and the original 1019 request received by the proxy was a GetBulkRequest-PDU, the 1020 proxy forwarder SHALL re-send the forwarded request (which 1021 would have been altered to be a GetNextRequest-PDU) with all 1022 but the first variable-binding removed. The proxy forwarder 1023 SHALL only re-send such a request a single time. If the 1024 resulting GetResponse-PDU also contains an error-status field 1025 with a value of 'tooBig,' then the proxy forwarder SHALL 1026 remove the contents of the variable-bindings field, and change 1027 the error-status field to 'noError', and ensure that the 1028 error-index field is set to 0 before forwarding the response. 1029 Note that if the original request only contained a single 1030 variable-binding, the proxy may skip re-sending the request 1031 and simply remove the variable-bindings and change the error- 1032 status to 'noError.' 1034 - If a Trap-PDU is received, and will be forwarded using the 1035 SNMPv2c or SNMPv3 message version, the proxy SHALL apply the 1036 translation rules described in section 3, and SHALL forward 1037 the notification as an SNMPv2-Trap-PDU. 1039 Note that when an SNMPv1 agent generates a message containing 1040 a Trap-PDU which is subsequently forwarded by one or more 1041 proxy forwarders using SNMP versions other than SNMPv1, the 1042 community string and agent-addr fields from the original 1043 message generated by the SNMPv1 agent will be preserved 1044 through the use of the snmpTrapAddress and snmpTrapCommunity 1045 objects. 1047 4.2.2. Upstream Version Less Than Downstream Version 1049 - If a GetResponse-PDU is received in response to a GetRequest- 1050 PDU (previously generated by the proxy) which contains 1051 variable-bindings of type Counter64 or which contain an SNMPv2 1052 exception code, and the message would be forwarded using the 1053 SNMPv1 message version, the proxy MUST generate an alternate 1054 response PDU consisting of the request-id and variable 1055 bindings from the original SNMPv1 request, containing a 1056 noSuchName error-status value, and containing an error-index 1057 value indicating the position of the variable-binding 1058 containing the Counter64 type or exception 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 that contain an SNMPv2 exception 1063 code, and the message would be forwarded using the SNMPv1 1064 message version, the proxy MUST generate an alternate response 1065 PDU consisting of the request-id and variable bindings from 1066 the original SNMPv1 request, containing a noSuchName error- 1067 status value, and containing an error-index value indicating 1068 the position of the variable-binding containing the exception 1069 code. 1071 - If a GetResponse-PDU is received in response to a 1072 GetNextRequest-PDU (previously generated by the proxy) which 1073 contains variable-bindings of type Counter64, the proxy MUST 1074 re-send the entire GetNextRequest-PDU, with the following 1075 modifications. For any variable bindings in the received 1076 GetResponse which contained Counter64 types, the proxy 1077 substitutes the object names of these variable bindings for 1078 the corresponding object names in the previously-sent 1079 GetNextRequest. The proxy MUST repeat this process until no 1080 Counter64 objects are returned. Note that an implementation 1081 may attempt to optimize this process of skipping Counter64 1082 objects. One approach to such an optimization would be to 1083 replace the last sub-identifier of the object names of 1084 varbinds containing a Counter64 type with 65535 if that sub- 1085 identifier is less than 65535, or with 4294967295 if that 1086 sub-identifier is greater than 65535. This approach should 1087 skip multiple instances of the same Counter64 object, while 1088 maintaining compatibility with some broken agent 1089 implementations (which only use 16-bit integers for sub- 1090 identifiers). 1092 Deployment Hint: The process of repeated GetNext requests 1093 used by a proxy when Counter64 types are returned can be 1094 expensive. When deploying a proxy, this can be avoided by 1095 configuring the target agents to which the proxy forwards 1096 requests in a manner such that any objects of type Counter64 1097 are in fact not-in-view for the principal that the proxy is 1098 using when communicating with these agents. 1100 - If a GetResponse-PDU is received which contains an SNMPv2 1101 error-status value of wrongValue, wrongEncoding, wrongType, 1102 wrongLength, inconsistentValue, noAccess, notWritable, 1103 noCreation, inconsistentName, resourceUnavailable, 1104 commitFailed, undoFailed, or authorizationError, the error- 1105 status value is modified using the mappings in section 4.3. 1107 - If an SNMPv2-Trap-PDU is received, and will be forwarded using 1108 the SNMPv1 message version, the proxy SHALL apply the 1109 translation rules described in section 3, and SHALL forward 1110 the notification as a Trap-PDU. Note that if the translation 1111 fails due to the existence of a Counter64 data-type in the 1112 received SNMPv2-Trap-PDU, the trap cannot be forwarded using 1113 SNMPv1. 1115 - If an InformRequest-PDU is received, any configuration 1116 information indicating that it would be forwarded using the 1117 SNMPv1 message version SHALL be ignored. An InformRequest-PDU 1118 can only be forwarded using the SNMPv2c or SNMPv3 message 1119 version. The InformRequest-PDU may still be forwarded if 1120 there is other configuration information indicating that it 1121 should be forwarded using SNMPv2c or SNMPv3. 1123 4.3. Error Status Mappings 1125 The following tables shows the mappings of SNMPv1 error-status values 1126 into SNMPv2 error-status values, and the mappings of SNMPv2 error- 1127 status values into SNMPv1 error-status values. 1129 SNMPv1 error-status SNMPv2 error-status 1130 =================== =================== 1131 noError noError 1132 tooBig tooBig 1133 noSuchName noSuchName 1134 badValue badValue 1135 genErr genErr 1137 SNMPv2 error-status SNMPv1 error-status 1138 =================== =================== 1139 noError noError 1140 tooBig tooBig 1141 genErr genErr 1142 wrongValue badValue 1143 wrongEncoding badValue 1144 wrongType badValue 1145 wrongLength badValue 1146 inconsistentValue badValue 1147 noAccess noSuchName 1148 notWritable noSuchName 1149 noCreation noSuchName 1150 inconsistentName noSuchName 1151 resourceUnavailable genErr 1152 commitFailed genErr 1153 undoFailed genErr 1154 authorizationError noSuchName 1156 Whenever the SNMPv2 error-status value of authorizationError is 1157 translated to an SNMPv1 error-status value of noSuchName, the value 1158 of snmpInBadCommunityUses MUST be incremented. 1160 5. Message Processing Models and Security Models 1162 In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture, 1163 the following models are defined in this document: 1165 - The SNMPv1 Message Processing Model 1167 - The SNMPv1 Community-Based Security Model 1169 The following models are also described in this document: 1171 - The SNMPv2c Message Processing Model 1173 - The SNMPv2c Community-Based Security Model 1175 In most respects, the SNMPv1 Message Processing Model and the 1176 SNMPv2c Message Processing Model are identical, and so these 1177 are not discussed independently in this document. Differences 1178 between the two models are described as required. 1180 Similarly, the SNMPv1 Community-Based Security Model and the 1181 SNMPv2c Community-Based Security Model are nearly identical, 1182 and so are not discussed independently. Differences between 1183 these two models are also described as required. 1185 5.1. Mappings 1187 The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model 1188 require mappings between parameters used in SNMPv1 (and SNMPv2c) 1189 messages, and the version independent parameters used in the SNMP 1190 architecture [16]. The parameters which MUST be mapped consist of the 1191 SNMPv1 (and SNMPv2c) community name, and the SNMP securityName and 1192 contextEngineID/contextName pair. A MIB module (the SNMP-COMMUNITY-MIB) 1193 is provided in this document in order to perform these mappings. This 1194 MIB provides mappings in both directions, that is, a community name may 1195 be mapped to a securityName, contextEngineID, and contextName, or the 1196 combination of securityName, contextEngineID, and contextName may be 1197 mapped to a community name. 1199 5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model 1201 The SNMPv1 Message Processing Model handles processing of SNMPv1 1202 messages. The processing of messages is handled generally in the 1203 same manner as described in RFC1157 [2], with differences and 1204 clarifications as described in the following sections. The 1205 SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for 1206 SNMPv2c is 1). 1208 5.2.1. Processing An Incoming Request 1210 In RFC1157 [2], section 4.1, item (3) for an entity which receives a 1211 message, states that various parameters are passed to the 'desired 1212 authentication scheme.' The desired authentication scheme in this 1213 case is the SNMPv1 Community-Based Security Model, which will be 1214 called using the processIncomingMsg ASI. The parameters passed to 1215 this ASI are: 1217 - The messageProcessingModel, which will be 0 (or 1 for 1218 SNMPv2c). 1220 - The maxMessageSize, which should be the maximum size of a 1221 message that the receiving entity can generate (since there is 1222 no such value in the received message). 1224 - The securityParameters, which consist of the community string 1225 and the message's source and destination transport domains and 1226 addresses. 1228 - The securityModel, which will be 1 (or 2 for SNMPv2c). 1230 - The securityLevel, which will be noAuthNoPriv. 1232 - The wholeMsg and wholeMsgLength. 1234 The Community-Based Security Model will attempt to select a row in 1235 the snmpCommunityTable. This is done by performing a search through 1236 the snmpCommunityTable in lexicographic order. The first entry for 1237 which the following matching criteria are satisfied will be selected: 1239 - The community string is equal to the snmpCommunityName value. 1241 - If the snmpCommunityTransportTag is an empty string, it is 1242 ignored for the purpose of matching. If the 1243 snmpCommunityTransportTag is not an empty string, the 1244 transportDomain and transportAddress from which the message 1245 was received must match one of the entries in the 1246 snmpTargetAddrTable selected by the snmpCommunityTransportTag 1247 value. The snmpTargetAddrTMask object is used as described in 1248 section 5.3 when checking whether the transportDomain and 1249 transportAddress matches a entry in the snmpTargetAddrTable. 1251 If no such entry can be found, an authentication failure occurs as 1252 described in RFC1157 [2], and the snmpInBadCommunityNames counter is 1253 incremented. 1255 The parameters returned from the Community-Based Security Model are: 1257 - The securityEngineID, which will always be the local value of 1258 snmpEngineID.0. 1260 - The securityName. 1262 - The scopedPDU. Note that this parameter will actually consist 1263 of three values, the contextSnmpEngineID (which will be the 1264 value of snmpCommunityContextEngineID from the selected entry 1265 in the snmpCommunityTable), the contextName (which will be the 1266 value of snmpCommunityContextName from the selected entry in 1267 the snmpCommunityTable), and the PDU. These must be separate 1268 values, since the first two do not actually appear in the 1269 message. 1271 - The maxSizeResponseScopedPDU. 1273 - The securityStateReference. 1275 The appropriate SNMP application will then be called (depending on 1276 the value of the contextEngineID and the request type in the PDU) 1277 using the processPdu ASI. The parameters passed to this ASI are: 1279 - The messageProcessingModel, which will be 0 (or 1 for 1280 SNMPv2c). 1282 - The securityModel, which will be 1 (or 2 for SNMPv2c). 1284 - The securityName, which was returned from the call to 1285 processIncomingMsg. 1287 - The securityLevel, which is noAuthNoPriv. 1289 - The contextEngineID, which was returned as part of the 1290 ScopedPDU from the call to processIncomingMsg. 1292 - The contextName, which was returned as part of the ScopedPDU 1293 from the call to processIncomingMsg. 1295 - The pduVersion, which should indicate an SNMPv1 version PDU 1296 (if the message version was SNMPv2c, this would be an SNMPv2 1297 version PDU). 1299 - The PDU, which was returned as part of the ScopedPDU from the 1300 call to processIncomingMsg. 1302 - The maxSizeResponseScopedPDU which was returned from the call 1303 to processIncomingMsg. 1305 - The stateReference which was returned from the call to 1306 processIncomingMsg. 1308 The SNMP application should process the request as described 1309 previously in this document. Note that access control is applied by 1310 an SNMPv3 command responder application as usual. The parameters as 1311 passed to the processPdu ASI will be used in calls to the 1312 isAccessAllowed ASI. 1314 5.2.2. Generating An Outgoing Response 1316 There is no special processing required for generating an outgoing 1317 response. However, the community string used in an outgoing response 1318 must be the same as the community string from the original request. 1319 The original community string MUST be present in the stateReference 1320 information of the original request. 1322 5.2.3. Generating An Outgoing Notification 1324 In a multi-lingual SNMP entity, the parameters used for generating 1325 notifications will be obtained by examining the SNMP-TARGET-MIB and 1326 SNMP-NOTIFICATION-MIB. These parameters will be passed to the SNMPv1 1327 Message Processing Model using the sendPdu ASI. The SNMPv1 Message 1328 Processing Model will attempt to locate an appropriate community 1329 string in the snmpCommunityTable based on the parameters passed to 1330 the sendPdu ASI. This is done by performing a search through the 1331 snmpCommunityTable in lexicographic order. The first entry for which 1332 the following matching criteria are satisfied will be selected: 1334 - The securityName must be equal to the 1335 snmpCommunitySecurityName value. 1337 - The contextEngineID must be equal to the 1338 snmpCommunityContextEngineID value. 1340 - The contextName must be equal to the snmpCommunityContextName 1341 value. 1343 - If the snmpCommunityTransportTag is an empty string, it is 1344 ignored for the purpose of matching. If the 1345 snmpCommunityTransportTag is not an empty string, the 1346 transportDomain and transportAddress must match one of the 1347 entries in the snmpTargetAddrTable selected by the 1348 snmpCommunityTransportTag value. 1350 If no such entry can be found, the notification is not sent. 1351 Otherwise, the community string used in the outgoing notification 1352 will be the value of the snmpCommunityName column of the selected 1353 row. 1355 5.2.4. Proxy Forwarding Of Requests 1357 In a proxy forwarding application, when a received request is to be 1358 forwarded using the SNMPv1 Message Processing Model, the parameters 1359 used for forwarding will be obtained by examining the SNMP-PROXY-MIB 1360 and the SNMP-TARGET-MIB. These parameters will be passed to the 1361 SNMPv1 Message Processing Model using the sendPdu ASI. The SNMPv1 1362 Message Processing Model will attempt to locate an appropriate 1363 community string in the snmpCommunityTable based on the parameters 1364 passed to the sendPdu ASI. This is done by performing a search 1365 through the snmpCommunityTable in lexicographic order. The first 1366 entry for which the following matching criteria are satisfied will be 1367 selected: 1369 - The securityName must be equal to the 1370 snmpCommunitySecurityName value. 1372 - The contextEngineID must be equal to the 1373 snmpCommunityContextEngineID value. 1375 - The contextName must be equal to the snmpCommunityContextName 1376 value. 1378 If no such entry can be found, the proxy forwarding application 1379 should follow the procedure described in RFC 2573 [18], section 1380 3.5.1.1, item (2). This procedure states that the snmpProxyDrops 1381 counter [12] is incremented, and that a Response-PDU is generated by 1382 calling the Dispatcher using the returnResponsePdu abstract service 1383 interface. 1385 5.3. The SNMP Community MIB Module 1387 The SNMP-COMMUNITY-MIB contains objects for mapping between community 1388 strings and version-independent SNMP message parameters. In 1389 addition, this MIB provides a mechanism for performing source address 1390 validation on incoming requests, and for selecting community strings 1391 based on target addresses for outgoing notifications. These two 1392 features are accomplished by providing a tag in the 1393 snmpCommunityTable which selects sets of entries in the 1394 snmpTargetAddrTable [18]. In addition, the SNMP-COMMUNITY-MIB 1395 augments the snmpTargetAddrTable with a transport address mask value 1396 and a maximum message size value. These values are used only where 1397 explicitly stated. In cases where the snmpTargetAddrTable is used 1398 without mention of these augmenting values, the augmenting values 1399 should be ignored. 1401 The mask value, snmpTargetAddrTMask, allows selected entries in the 1402 snmpTargetAddrTable to specify multiple addresses (rather than just a 1403 single address per entry). This would typically be used to specify a 1404 subnet in an snmpTargetAddrTable rather than just a single address. 1405 The mask value is used to select which bits of a transport address 1406 must match bits of the corresponding instance of 1407 snmpTargetAddrTAddress, in order for the transport address to match a 1408 particular entry in the snmpTargetAddrTable. The value of an 1409 instance of snmpTargetAddrTMask must always be an OCTET STRING whose 1410 length is either zero or the same as that of the corresponding 1411 instance of snmpTargetAddrTAddress. 1413 Note that the snmpTargetAddrTMask object is only used where 1414 explicitly stated. In particular, it is not used when generating 1415 notifications (i.e., when generating notifications, entries in the 1416 snmpTargetAddrTable only specify individual addresses). 1418 When checking whether a transport address matches an entry in the 1419 snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero- 1420 length OCTET STRING, the mask value is ignored, and the value of 1421 snmpTargetAddrTAddress must exactly match a transport address. 1422 Otherwise, each bit of each octet in the snmpTargetAddrTMask value 1423 corresponds to the same bit of the same octet in the 1424 snmpTargetAddrTAddress value. For bits that are set in the 1425 snmpTargetAddrTMask value (i.e., bits equal to 1), the corresponding 1426 bits in the snmpTargetAddrTAddress value must match the bits in a 1427 transport address. If all such bits match, the transport address is 1428 matched by that snmpTargetAddrTable entry. Otherwise, the transport 1429 address is not matched. 1431 The maximum message size value, snmpTargetAddrMMS, is used to 1432 determine the maximum message size acceptable to another SNMP entity 1433 when the value cannot be determined from the protocol. 1435 SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN 1437 IMPORTS 1438 IpAddress, 1439 MODULE-IDENTITY, 1440 OBJECT-TYPE, 1441 Integer32, 1442 snmpModules 1443 FROM SNMPv2-SMI 1444 RowStatus, 1445 StorageType 1446 FROM SNMPv2-TC 1447 SnmpAdminString, 1448 SnmpEngineID 1449 FROM SNMP-FRAMEWORK-MIB 1450 SnmpTagValue, 1451 snmpTargetAddrEntry 1452 FROM SNMP-TARGET-MIB 1453 MODULE-COMPLIANCE, 1454 OBJECT-GROUP 1455 FROM SNMPv2-CONF; 1457 snmpCommunityMIB MODULE-IDENTITY 1458 LAST-UPDATED "200111210000Z" -- 21 Nov 2001, midnight 1459 ORGANIZATION "SNMPv3 Working Group" 1460 CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com 1461 Subscribe: majordomo@lists.tislabs.com 1462 In msg body: subscribe snmpv3 1464 Co-Chair: Russ Mundy 1465 Trusted Information Systems 1466 Postal: 3060 Washington Rd 1467 Glenwood, Maryland 21738 1468 USA 1469 EMail: mundy@tislabs.com 1470 Phone: +1-301-854-6889 1472 Co-Chair: David Harrington 1473 Enterasys Networks 1474 Postal: 35 Industrial Way 1475 P. O. Box 5004 1476 Rochester, New Hampshire 03866-5005 1477 USA 1478 EMail: dbh@enterasys.com 1479 Phone: +1 603-337-2614 1481 Co-editor: Rob Frye 1482 Vibrant Solutions 1483 Postal: 2711 Prosperity Ave 1484 Fairfax, Virginia 22031 1485 USA 1486 E-mail: rfrye@vibrant-1.com 1487 Phone: +1-703-270-2000 1489 Co-editor: David B. Levi 1490 Nortel Networks 1491 Postal: 3505 Kesterwood Drive 1492 Knoxville, Tennessee 37918 1493 E-mail: dlevi@nortelnetworks.com 1494 Phone: +1 423 686 0432 1496 Co-editor: Shawn A. Routhier 1497 Integrated Systems Inc. 1498 Postal: 333 North Ave 4th Floor 1499 Wakefield, Massachusetts 01880 1500 E-mail: sar@epilogue.com 1501 Phone: +1 781 245 0804 1503 Co-editor: Bert Wijnen 1504 Lucent Technologies 1505 Postal: Schagen 33 1506 3461 GL Linschoten 1507 Netherlands 1508 Email: bwijnen@lucent.com 1509 Phone: +31-348-680-485 1510 " 1512 DESCRIPTION 1513 "This MIB module defines objects to help support coexistence 1514 between SNMPv1, SNMPv2c, and SNMPv3." 1515 REVISION "200111210000Z" -- 21 Nov 2001 (same as LAST-UPDATED) 1516 DESCRIPTION "This version published as 1517 draft-ietf-snmpv3-coex-v2-01.txt" 1518 REVISION "199910050000Z" -- 5 Oct 1999 1519 DESCRIPTION "This version published as RFC xxxx" 1520 -- RFC-editor assigns xxxx 1521 REVISION "199905130000Z" -- 13 May 1999 1522 DESCRIPTION "The Initial Revision" 1523 ::= { snmpModules 18 } 1525 -- Administrative assignments **************************************** 1526 snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 } 1527 snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 } 1529 -- 1530 -- The snmpCommunityTable contains a database of community strings. 1531 -- This table provides mappings between community strings, and the 1532 -- parameters required for View-based Access Control. 1533 -- 1535 snmpCommunityTable OBJECT-TYPE 1536 SYNTAX SEQUENCE OF SnmpCommunityEntry 1537 MAX-ACCESS not-accessible 1538 STATUS current 1539 DESCRIPTION 1540 "The table of community strings configured in the SNMP 1541 engine's Local Configuration Datastore (LCD)." 1542 ::= { snmpCommunityMIBObjects 1 } 1544 snmpCommunityEntry OBJECT-TYPE 1545 SYNTAX SnmpCommunityEntry 1546 MAX-ACCESS not-accessible 1547 STATUS current 1548 DESCRIPTION 1549 "Information about a particular community string." 1550 INDEX { IMPLIED snmpCommunityIndex } 1551 ::= { snmpCommunityTable 1 } 1553 SnmpCommunityEntry ::= SEQUENCE { 1554 snmpCommunityIndex SnmpAdminString, 1555 snmpCommunityName OCTET STRING, 1556 snmpCommunitySecurityName SnmpAdminString, 1557 snmpCommunityContextEngineID SnmpEngineID, 1558 snmpCommunityContextName SnmpAdminString, 1559 snmpCommunityTransportTag SnmpTagValue, 1560 snmpCommunityStorageType StorageType, 1561 snmpCommunityStatus RowStatus 1562 } 1564 snmpCommunityIndex OBJECT-TYPE 1565 SYNTAX SnmpAdminString (SIZE(1..32)) 1566 MAX-ACCESS not-accessible 1567 STATUS current 1568 DESCRIPTION 1569 "The unique index value of a row in this table." 1570 ::= { snmpCommunityEntry 1 } 1572 snmpCommunityName OBJECT-TYPE 1573 SYNTAX OCTET STRING 1574 MAX-ACCESS read-create 1575 STATUS current 1576 DESCRIPTION 1577 "The community string for which a row in this table 1578 represents a configuration." 1579 ::= { snmpCommunityEntry 2 } 1581 snmpCommunitySecurityName OBJECT-TYPE 1582 SYNTAX SnmpAdminString (SIZE(1..32)) 1583 MAX-ACCESS read-create 1584 STATUS current 1585 DESCRIPTION 1586 "A human readable string representing the corresponding 1587 value of snmpCommunityName in a Security Model 1588 independent format." 1589 ::= { snmpCommunityEntry 3 } 1591 snmpCommunityContextEngineID OBJECT-TYPE 1592 SYNTAX SnmpEngineID 1593 MAX-ACCESS read-create 1594 STATUS current 1595 DESCRIPTION 1596 "The contextEngineID indicating the location of the 1597 context in which management information is accessed 1598 when using the community string specified by the 1599 corresponding instance of snmpCommunityName. 1601 The default value is the snmpEngineID of the entity in 1602 which this object is instantiated." 1603 ::= { snmpCommunityEntry 4 } 1605 snmpCommunityContextName OBJECT-TYPE 1606 SYNTAX SnmpAdminString (SIZE(0..32)) 1607 MAX-ACCESS read-create 1608 STATUS current 1609 DESCRIPTION 1610 "The context in which management information is accessed 1611 when using the community string specified by the corresponding 1612 instance of snmpCommunityName." 1613 DEFVAL { ''H } -- the empty string 1614 ::= { snmpCommunityEntry 5 } 1616 snmpCommunityTransportTag OBJECT-TYPE 1617 SYNTAX SnmpTagValue 1618 MAX-ACCESS read-create 1619 STATUS current 1620 DESCRIPTION 1621 "This object specifies a set of transport endpoints 1622 from which an SNMP entity will accept management 1623 requests. If a management request containing 1624 this community is received on a transport endpoint other 1625 than the transport endpoints identified by this object, 1626 the request is deemed unauthentic. 1628 The transports identified by this object are specified 1629 in the snmpTargetAddrTable. Entries in that table 1630 whose snmpTargetAddrTagList contains this tag value 1631 are identified. 1633 If the value of this object has zero-length, transport 1634 endpoints are not checked when authenticating messages 1635 containing this community string." 1636 DEFVAL { ''H } -- the empty string 1637 ::= { snmpCommunityEntry 6 } 1639 snmpCommunityStorageType OBJECT-TYPE 1640 SYNTAX StorageType 1641 MAX-ACCESS read-create 1642 STATUS current 1643 DESCRIPTION 1644 "The storage type for this conceptual row in the 1645 snmpCommunityTable. Conceptual rows having the value 1646 'permanent' need not allow write-access to any 1647 columnar object in the row." 1648 ::= { snmpCommunityEntry 7 } 1650 snmpCommunityStatus OBJECT-TYPE 1651 SYNTAX RowStatus 1652 MAX-ACCESS read-create 1653 STATUS current 1654 DESCRIPTION 1655 "The status of this conceptual row in the snmpCommunityTable. 1657 An entry in this table is not qualified for activation 1658 until instances of all corresponding columns have been 1659 initialized, either through default values, or through 1660 Set operations. The snmpCommunityName and 1661 snmpCommunitySecurityName objects must be explicitly set. 1663 There is no restriction on setting columns in this table 1664 when the value of snmpCommunityStatus is active(1)." 1665 ::= { snmpCommunityEntry 8 } 1667 -- 1668 -- The snmpTargetAddrExtTable 1669 -- 1671 snmpTargetAddrExtTable OBJECT-TYPE 1672 SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry 1673 MAX-ACCESS not-accessible 1674 STATUS current 1675 DESCRIPTION 1676 "The table of mask and mms values associated with the 1677 snmpTargetAddrTable. 1679 The snmpTargetAddrExtTable augments the 1680 snmpTargetAddrTable with a transport address mask value 1681 and a maximum message size value. The transport address 1682 mask allows entries in the snmpTargetAddrTable to define 1683 a set of addresses instead of just a single address. 1684 The maximum message size value allows the maximum 1685 message size of another SNMP entity to be configured for 1686 use in SNMPv1 (and SNMPv2c) transactions, where the 1687 message format does not specify a maximum message size." 1688 ::= { snmpCommunityMIBObjects 2 } 1690 snmpTargetAddrExtEntry OBJECT-TYPE 1691 SYNTAX SnmpTargetAddrExtEntry 1692 MAX-ACCESS not-accessible 1693 STATUS current 1694 DESCRIPTION 1695 "Information about a particular mask and mms value." 1696 AUGMENTS { snmpTargetAddrEntry } 1697 ::= { snmpTargetAddrExtTable 1 } 1699 SnmpTargetAddrExtEntry ::= SEQUENCE { 1700 snmpTargetAddrTMask OCTET STRING, 1701 snmpTargetAddrMMS Integer32 1702 } 1704 snmpTargetAddrTMask OBJECT-TYPE 1705 SYNTAX OCTET STRING (SIZE (0..255)) 1706 MAX-ACCESS read-create 1707 STATUS current 1708 DESCRIPTION 1709 "The mask value associated with an entry in the 1710 snmpTargetAddrTable. The value of this object must 1711 have the same length as the corresponding instance of 1712 snmpTargetAddrTAddress, or must have length 0. An 1713 attempt to set it to any other value will result in 1714 an inconsistentValue error. 1716 The value of this object allows an entry in the 1717 snmpTargetAddrTable to specify multiple addresses. 1718 The mask value is used to select which bits of 1719 a transport address must match bits of the corresponding 1720 instance of snmpTargetAddrTAddress, in order for the 1721 transport address to match a particular entry in the 1722 snmpTargetAddrTable. Bits which are 1 in the mask 1723 value indicate bits in the transport address which 1724 must match bits in the snmpTargetAddrTAddress value. 1725 Bits which are 0 in the mask indicate bits in the 1726 transport address which need not match. If the 1727 length of the mask is 0, the mask should be treated 1728 as if all its bits were 1 and its length were equal 1729 to the length of the corresponding value of 1730 snmpTargetAddrTable. 1732 This object may not be modified while the value of the 1733 corresponding instance of snmpTargetAddrRowStatus is 1734 active(1). An attempt to set this object in this case 1735 will result in an inconsistentValue error." 1736 DEFVAL { ''H } 1737 ::= { snmpTargetAddrExtEntry 1 } 1739 snmpTargetAddrMMS OBJECT-TYPE 1740 SYNTAX Integer32 (0|484..2147483647) 1741 MAX-ACCESS read-create 1742 STATUS current 1743 DESCRIPTION 1744 "The maximum message size value associated with an entry 1745 in the snmpTargetAddrTable. Note that a value of 0 means 1746 that the maximum message size is unknown." 1747 DEFVAL { 484 } 1748 ::= { snmpTargetAddrExtEntry 2 } 1750 -- 1751 -- The snmpTrapAddress and snmpTrapCommunity objects are included 1752 -- in notifications that are forwarded by a proxy, which were 1753 -- originally received as SNMPv1 Trap messages. 1754 -- 1756 snmpTrapAddress OBJECT-TYPE 1757 SYNTAX IpAddress 1758 MAX-ACCESS accessible-for-notify 1759 STATUS current 1760 DESCRIPTION 1761 "The value of the agent-addr field of a Trap PDU which 1762 is forwarded by a proxy forwarder application using 1763 an SNMP version other than SNMPv1. The value of this 1764 object SHOULD contain the value of the agent-addr field 1765 from the original Trap PDU as generated by an SNMPv1 1766 agent." 1767 ::= { snmpCommunityMIBObjects 3 } 1769 snmpTrapCommunity OBJECT-TYPE 1770 SYNTAX OCTET STRING 1771 MAX-ACCESS accessible-for-notify 1772 STATUS current 1773 DESCRIPTION 1774 "The value of the community string field of an SNMPv1 1775 message containing a Trap PDU which is forwarded by a 1776 a proxy forwarder application using an SNMP version 1777 other than SNMPv1. The value of this object SHOULD 1778 contain the value of the community string field from 1779 the original SNMPv1 message containing a Trap PDU as 1780 generated by an SNMPv1 agent." 1781 ::= { snmpCommunityMIBObjects 4 } 1783 -- Conformance Information ******************************************* 1785 snmpCommunityMIBCompliances OBJECT IDENTIFIER 1786 ::= { snmpCommunityMIBConformance 1 } 1787 snmpCommunityMIBGroups OBJECT IDENTIFIER 1788 ::= { snmpCommunityMIBConformance 2 } 1790 -- Compliance statements 1792 snmpCommunityMIBCompliance MODULE-COMPLIANCE 1793 STATUS current 1794 DESCRIPTION 1795 "The compliance statement for SNMP engines which 1796 implement the SNMP-COMMUNITY-MIB." 1798 MODULE -- this module 1799 MANDATORY-GROUPS { snmpCommunityTableGroup } 1801 OBJECT snmpCommunityName 1802 MIN-ACCESS read-only 1803 DESCRIPTION "Write access is not required." 1805 OBJECT snmpCommunitySecurityName 1806 MIN-ACCESS read-only 1807 DESCRIPTION "Write access is not required." 1808 OBJECT snmpCommunityContextEngineID 1809 MIN-ACCESS read-only 1810 DESCRIPTION "Write access is not required." 1812 OBJECT snmpCommunityContextName 1813 MIN-ACCESS read-only 1814 DESCRIPTION "Write access is not required." 1816 OBJECT snmpCommunityTransportTag 1817 MIN-ACCESS read-only 1818 DESCRIPTION "Write access is not required." 1820 OBJECT snmpCommunityStorageType 1821 MIN-ACCESS read-only 1822 DESCRIPTION "Write access is not required." 1824 OBJECT snmpCommunityStatus 1825 MIN-ACCESS read-only 1826 DESCRIPTION "Write access is not required." 1828 ::= { snmpCommunityMIBCompliances 1 } 1830 snmpProxyTrapForwardCompliance MODULE-COMPLIANCE 1831 STATUS current 1832 DESCRIPTION 1833 "The compliance statement for SNMP engines which 1834 contain a proxy forwarding application which is 1835 capable of forwarding SNMPv1 traps using SNMPv2c 1836 or SNMPv3." 1837 MODULE -- this module 1838 MANDATORY-GROUPS { snmpProxyTrapForwardGroup } 1839 ::= { snmpCommunityMIBCompliances 2 } 1841 snmpCommunityTableGroup OBJECT-GROUP 1842 OBJECTS { 1843 snmpCommunityName, 1844 snmpCommunitySecurityName, 1845 snmpCommunityContextEngineID, 1846 snmpCommunityContextName, 1847 snmpCommunityTransportTag, 1848 snmpCommunityStorageType, 1849 snmpCommunityStatus, 1850 snmpTargetAddrTMask, 1851 snmpTargetAddrMMS 1852 } 1853 STATUS current 1854 DESCRIPTION 1855 "A collection of objects providing for configuration 1856 of community strings for SNMPv1 (and SNMPv2c) usage." 1857 ::= { snmpCommunityMIBGroups 1 } 1859 snmpProxyTrapForwardGroup OBJECT-GROUP 1860 OBJECTS { 1861 snmpTrapAddress, 1862 snmpTrapCommunity 1863 } 1864 STATUS current 1865 DESCRIPTION 1866 "Objects which are used by proxy forwarding applications 1867 when translating traps between SNMP versions. These are 1868 used to preserve SNMPv1-specific information when 1869 translating to SNMPv2c or SNMPv3." 1870 ::= { snmpCommunityMIBGroups 3 } 1872 END 1874 6. Intellectual Property 1876 The IETF takes no position regarding the validity or scope of any 1877 intellectual property or other rights that might be claimed to 1878 pertain to the implementation or use of the technology described in 1879 this document or the extent to which any license under such rights 1880 might or might not be available; neither does it represent that it 1881 has made any effort to identify any such rights. Information on the 1882 IETF's procedures with respect to rights in standards-track and 1883 standards-related documentation can be found in BCP-11. Copies of 1884 claims of rights made available for publication and any assurances of 1885 licenses to be made available, or the result of an attempt made to 1886 obtain a general license or permission for the use of such 1887 proprietary rights by implementors or users of this specification can 1888 be obtained from the IETF Secretariat. 1890 The IETF invites any interested party to bring to its attention any 1891 copyrights, patents or patent applications, or other proprietary 1892 rights which may cover technology that may be required to practice 1893 this standard. Please address the information to the IETF Executive 1894 Director. 1896 7. Acknowledgments 1898 This document is the result of the efforts of the SNMPv3 Working 1899 Group. The design of the SNMP-COMMUNITY-MIB incorporates work done 1900 by the authors of SNMPv2*: 1902 Jeff Case (SNMP Research, Inc.) 1903 David Harrington (Enterasys Networks) 1904 David Levi (Nortel Networks) 1905 Brian O'Keefe (Hewlett Packard) 1906 Jon Saperia (IronBridge Networks, Inc.) 1907 Steve Waldbusser (International Network Services) 1909 8. Security Considerations 1911 Although SNMPv1 and SNMPv2 do not provide any security, allowing 1912 community names to be mapped into securityName/contextName provides 1913 the ability to use view-based access control to limit the access of 1914 unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for 1915 network administrators to make use of this capability in order to 1916 avoid unauthorized access to MIB data that would otherwise be secure. 1918 Further, the SNMP-COMMUNITY-MIB has the potential to expose community 1919 strings which provide access to more information than that which is 1920 available using the usual 'public' community string. For this 1921 reason, a security administrator may wish to limit accessibility to 1922 the SNMP-COMMUNITY-MIB, and in particular, to make it inaccessible 1923 when using the 'public' community string. 1925 When a proxy implementation translates messages between SNMPv1 (or 1926 SNMPv2c) and SNMPv3, there may be a loss of security. For example, 1927 an SNMPv3 message received using authentication and privacy which is 1928 subsequently forwarded using SNMPv1 will lose the security benefits 1929 of using authentication and privacy. Careful configuration of 1930 proxies is required to address such situations. One approach to deal 1931 with such situations might be to use an encrypted tunnel. 1933 9. References 1935 [1] Rose, M. and K. McCloghrie, "Structure and Identification of 1936 Management Information for TCP/IP-based internets"", STD16, RFC 1937 1155, May 1990. 1939 [2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1940 Management Protocol", STD15, RFC 1157, SNMP Research, Performance 1941 Systems International, Performance Systems International, MIT 1942 Laboratory for Computer Science, May 1990. 1944 [3] McCloghrie, K., and M. Rose, Editors, "Concise MIB Definitions", 1945 STD 16, RFC 1212, Hughes LAN Systems, Performance Systems 1946 International, March 1991. 1948 [4] Rose, M. T., "A Convention for Defining Traps for use with the 1949 SNMP", RFC 1215, March 1991. 1951 [5] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP- 1952 based Agents", RFC 1303, Hughes LAN Systems, Dover Beach 1953 Consulting, Inc., February 1992. 1955 [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1956 Waldbusser, "Introduction to Community-based SNMPv2", RFC1901, SNMP 1957 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1958 International Network Services, January 1996. 1960 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1961 and S. Waldbusser, "Structure of Management Information Version 2 1962 (SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU 1963 Braunschweig, SNMP Research, First Virtual Holdings, International 1964 Network Services, April 1999. 1966 [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1967 and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 1968 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First 1969 Virtual Holdings, International Network Services, April 1999. 1971 [9] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1972 and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, 1973 STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, 1974 First Virtual Holdings, International Network Services, April 1999. 1976 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1977 Waldbusser, "Protocol Operations for Version 2 of the Simple 1978 Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., 1979 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 1980 Network Services, January 1996. 1982 [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport 1983 Mappings for Version 2 of the Simple Network Management Protocol 1984 (SNMPv2)", RFC 1906, January 1996. 1986 [12] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1987 Waldbusser, "Management Information Base for Version 2 of the 1988 Simple Network Management Protocol (SNMPv2)", RFC1907, SNMP 1989 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1990 International Network Services, January 1996. 1992 [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1993 Waldbusser, "Coexistence between Version 1 and Version 2 of the 1994 Internet-standard Network Management Framework", RFC1908, SNMP 1995 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1996 International Network Services, January 1996. 1998 [14] Levi, D., Wijnen, B., "Mapping SNMPv2 onto SNMPv1 within a bi- 1999 lingual SNMP agent", RFC2089, SNMP Research, Inc., IBM, January 2000 1997. 2002 [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2003 Levels", BCP 14, RFC 2119, March 1997. 2005 [16] The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An 2006 Architecture for Describing SNMP Management Frameworks", RFC 2571, 2007 May 1999. 2009 [17] The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B., 2010 "Message Processing and Dispatching for the Simple Network 2011 Management Protocol (SNMP)", RFC 2572, May 1999. 2013 [18] The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMP 2014 Applications", RFC2573, May 1999. 2016 [19] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User- 2017 Based Security Model for Version 3 of the Simple Network Management 2018 Protocol (SNMP)", RFC 2574, May 1999. 2020 [20] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K., 2021 "View-based Access Control Model for the Simple Network Management 2022 Protocol (SNMP)", RFC 2575, May 1999. 2024 [21] The SNMPv3 Working Group, Frye, R., Levi, D., Routhier, S., Wijnen, 2025 B., "Coexistence between Version 1, Version 2, and Version 3 of the 2026 Internet-standard Network Management Framework", RFC 2576, May 2027 1999. 2029 [22] Information processing systems - Open Systems Interconnection - 2030 Specification of Abstract Syntax Notation One (ASN.1), 2031 International Organization for Standardization. International 2032 Standard 8824, (December, 1987). 2034 10. Editor's Addresses 2036 Rob Frye 2037 Vibrant Solutions 2038 2711 Prosperity Ave 2039 Fairfax, Virginia 22031 2040 U.S.A. 2041 Phone: +1 703 270 2000 2042 EMail: rfrye@vibrant-1.com 2044 David B. Levi 2045 Nortel Networks 2046 3505 Kesterwood Drive 2047 Knoxville, TN 37918 2048 U.S.A. 2049 Phone: +1 423 686 0432 2050 EMail: dlevi@nortelnetworks.com 2052 Shawn A. Routhier 2053 Integrated Systems Inc. 2054 333 North Ave 4th Floor 2055 Wakefield MA 01880 2056 U.S.A. 2057 Phone: + 1 781 245 0804 2058 EMail: sar@epilogue.com 2060 Bert Wijnen 2061 Lucent Technologies 2062 Schagen 33 2063 3461 GL Linschoten 2064 Netherlands 2065 Phone: +31 348 680 485 2066 EMail: bwijnen@lucent.com 2068 A. Full Copyright Statement 2070 This document and translations of it may be copied and furnished to 2071 others, and derivative works that comment on or otherwise explain it 2072 or assist in its implementation may be prepared, copied, published 2073 and distributed, in whole or in part, without restriction of any 2074 kind, provided that the above copyright notice and this paragraph are 2075 included on all such copies and derivative works. However, this 2076 document itself may not be modified in any way, such as by removing 2077 the copyright notice or references to the Internet Society or other 2078 Internet organizations, except as needed for the purpose of 2079 developing Internet standards in which case the procedures for 2080 copyrights defined in the Internet Standards process must be 2081 followed, or as required to translate it into languages other than 2082 English. 2084 The limited permissions granted above are perpetual and will not be 2085 revoked by the Internet Society or its successors or assigns. 2087 This document and the information contained herein is provided on an 2088 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2089 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2090 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2091 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2092 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2094 B. Changes From RFC1908 2096 - Editorial changes to comply with current RFC requirements. 2098 - Added/updated copyright statements. 2100 - Added Intellectual Property section. 2102 - Replaced old introduction with complete new 2103 introduction/overview. 2105 - Added content for the Security Considerations Section. 2107 - Updated References to current documents. 2109 - Updated text to use current SNMP terminology. 2111 - Added coexistence for/with SNMPv3. 2113 - Added description for SNMPv1 and SNMPv2c Message Processing 2114 Models and SNMPv1 and SNMPv2c Community-based Security Models. 2116 - Added snmpCommunityMIB so that SNMPv1 and SNMPv2 community 2117 strings can be mapped into the SNMP Version Independent 2118 paramaters which can then be used for access control using the 2119 standard SNMPv3 View-based Access Control Model and the 2120 snmpVacmMIB. 2122 - Added two MIB objects such that when an SNMPv1 notification 2123 (trap) must be converted into an SNMPv2 notification we add 2124 those two objects in order to preserve information about the 2125 address and community of the originating SNMPv1 agent. 2127 - Included (and extended) from RFC2089 the SNMPv2 to SNMPv1 2128 mapping within a multi-lingual SNMP Engine. 2130 - Use keywords from RFC 2119 to describe requirements for 2131 compliance. 2133 - Changed/added some rules for converting a MIB module from 2134 SMIv1 to SMIv2. 2136 - Extended and improved the description of Proxy Forwarder 2137 behaviour when multiple SNMP versions are involved.