idnits 2.17.1 draft-ietf-snmpv3-coex-v2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 18 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([13], [14]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 6 instances 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 RFC1908, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 503 has weird spacing: '...rameter snmp...' == Line 1099 has weird spacing: '...ailable gen...' == Line 2037 has weird spacing: '...for the purpo...' == Line 2112 has weird spacing: '...ameters to S...' == Line 2114 has weird spacing: '...ameters to S...' -- 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 (18 Apr 2001) is 8408 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 1303 (ref. '5') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '6') ** Obsolete normative reference: RFC 1905 (ref. '10') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (ref. '11') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1907 (ref. '12') (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1908 (ref. '13') (Obsoleted by RFC 2576) ** Obsolete normative reference: RFC 2089 (ref. '14') (Obsoleted by RFC 2576) ** Obsolete normative reference: RFC 2571 (ref. '16') (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 2572 (ref. '17') (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2573 (ref. '18') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2574 (ref. '19') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2575 (ref. '20') (Obsoleted by RFC 3415) Summary: 21 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Coexistence between SNMP versions 18 Apr 2001 4 INTERNET-DRAFT Rob Frye 5 Longitude Systems, Inc. 6 David B. Levi 7 Nortel Networks 8 Shawn A. Routhier 9 Integrated Systems Inc. 10 Bert Wijnen 11 Lucent Technologies 12 18 Apr 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 1908 [13] 48 and RFC2089 [14]. 50 Table Of Contents 52 1. Overview 54 The purpose of this document is to describe coexistence between 55 version 3 of the Internet-standard Network Management Framework, 56 termed the SNMP version 3 framework (SNMPv3), version 2 of the 57 Internet-standard Network Management Framework, termed the SNMP 58 version 2 framework (SNMPv2), and the original Internet-standard 59 Network Management Framework (SNMPv1). 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC2119 [15]. 65 There are four general aspects of coexistence described in this 66 document. Each of these is described in a separate section: 68 - Conversion of MIB documents between SMIv1 and SMIv2 formats is 69 documented in section 2. 71 - Mapping of notification parameters is documented in section 3. 73 - Approaches to coexistence between entities which support the 74 various versions of SNMP in a multi-lingual network is 75 documented in section 4. This section addresses the 76 processing of protocol operations in multi-lingual 77 implementations, as well as behaviour of proxy 78 implementations. 80 - The SNMPv1 Message Processing Model and Community-Based 81 Security Model, which provides mechanisms for adapting SNMPv1 82 into the View-Based Access Control Model (VACM) [20], is 83 documented in section 5 (this section also addresses the 84 SNMPv2c Message Processing Model and Community-Based Security 85 Model). 87 1.1. SNMPv1 89 SNMPv1 is defined by these documents: 91 - STD 15, RFC 1157 [2] which defines the Simple Network 92 Management Protocol (SNMPv1), the protocol used for network 93 access to managed objects. 95 - STD 16, RFC 1155 [1] which defines the Structure of Management 96 Information (SMIv1), the mechanisms used for describing and 97 naming objects for the purpose of management. 99 - STD 16, RFC 1212 [3] which defines a more concise description 100 mechanism, which is wholly consistent with the SMIv1. 102 - RFC 1215 [4] which defines a convention for defining Traps for 103 use with the SMIv1. 105 Note that throughout this document, the term 'SMIv1' is used. This 106 term generally refers to the information presented in RFC 1155, RFC 107 1212, and RFC 1215. 109 1.2. SNMPv2 111 SNMPv2 is defined by these documents: 113 - STD 58, RFC 2578 which defines Version 2 of the Structure of 114 Management Information (SMIv2) [7]. 116 - STD 58, RFC 2579 which defines common MIB "Textual 117 Conventions" [8]. 119 - STD 58, RFC 2580 which defines Conformance Statements and 120 requirements for defining agent and manager capabilities [9]. 122 - RFC 1905 which defines the Protocol Operations used in 123 processing [10]. 125 - RFC 1906 which defines the Transport Mappings used "on the 126 wire" [11]. 128 - RFC 1907 which defines the basic Management Information Base 129 for monitoring and controlling some basic common functions of 130 SNMP entities [12]. 132 Note that SMIv2 as used throughout this document refers to the first 133 three documents listed above (RFCs 2578, 2579, and 2580). 135 The following document augments the definition of SNMPv2: 137 - RFC 1901 [6] is an Experimental definition for using SNMPv2 138 PDUs within a community-based message wrapper. This is 139 referred to throughout this document as SNMPv2c. 141 1.3. SNMPv3 143 SNMPv3 is defined by these documents: 145 - RFC 2571 which defines an Architecture for Describing SNMP 146 Management Frameworks [16]. 148 - RFC 2572 which defines Message Processing and Dispatching 149 [17]. 151 - RFC 2573 which defines various SNMP Applications [18]. 153 - RFC 2574 which defines the User-based Security Model (USM), 154 providing for both Authenticated and Private (encrypted) SNMP 155 messages [19]. 157 - RFC 2575 which defines the View-based Access Control Model 158 (VACM), providing the ability to limit access to different MIB 159 objects on a per-user basis [20]. 161 SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 and 162 the SMIv2 definitions of 2578 through 2580 described above. 164 1.4. SNMPv1 and SNMPv2 Access to MIB Data 166 In several places, this document refers to 'SNMPv1 Access to MIB 167 Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the part 168 of an SNMP agent which actually accesses instances of MIB objects, 169 and which actually initiates generation of notifications. 170 Differences between the two types of access to MIB data are: 172 - Error-status values generated. 174 - Generation of exception codes. 176 - Use of the Counter64 data type. 178 - The format of parameters provided when a notification is 179 generated. 181 SNMPv1 access to MIB data may generate SNMPv1 error-status values, 182 will never generate exception codes nor use the Counter64 data type, 183 and will provide SNMPv1 format parameters for generating 184 notifications. Note also that SNMPv1 access to MIB data will 185 actually never generate a readOnly error (a noSuchName error would 186 always occur in the situation where one would expect a readOnly 187 error). 189 SNMPv2 access to MIB data may generate SNMPv2 error-status values, 190 may generate exception codes, may use the Counter64 data type, and 191 will provide SNMPv2 format parameters for generating notifications. 192 Note that SNMPv2 access to MIB data will never generate readOnly, 193 noSuchName, or badValue errors. 195 Note that a particular multi-lingual implementation may choose to 196 implement all access to MIB data as SNMPv2 access to MIB data, and 197 perform the translations described herein for SNMPv1-based 198 transactions. 200 2. SMI and Management Information Mappings 202 The SMIv2 approach towards describing collections of managed objects 203 is nearly a proper superset of the approach defined in the SMIv1. 204 For example, both approaches use an adapted subset of ASN.1 (1988) 205 [11] as the basis for a formal descriptive notation. Indeed, one 206 might note that the SMIv2 approach largely codifies the existing 207 practice for defining MIB modules, based on extensive experience with 208 the SMIv1. 210 The following sections consider the three areas: MIB modules, 211 compliance statements, and capabilities statements. 213 2.1. MIB Modules 215 MIB modules defined using the SMIv1 may continue to be used with 216 protocol versions which use SNMPv2 PDUs. However, for the MIB 217 modules to conform to the SMIv2, the following changes SHALL be made: 219 2.1.1. Object Definitions 221 In general, conversion of a MIB module does not require the 222 deprecation of the objects contained therein. If the definition of 223 an object is truly inadequate for its intended purpose, the object 224 SHALL be deprecated or obsoleted, otherwise deprecation is not 225 required. 227 (1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of 228 RFC1155-SMI and RFC-1212. 230 (2) The MODULE-IDENTITY macro MUST be invoked immediately after any 231 IMPORTs statement. 233 (3) For any object with an integer-valued SYNTAX clause, in which the 234 corresponding INTEGER does not have a range restriction (i.e., the 235 INTEGER has neither a defined set of named-number enumerations nor 236 an assignment of lower- and upper-bounds on its value), the object 237 MUST have the value of its SYNTAX clause changed to Integer32, or 238 have an appropriate range specified. 240 (4) For any object with a SYNTAX clause value of Counter, the object 241 MUST have the value of its SYNTAX clause changed to Counter32. 243 (5) For any object with a SYNTAX clause value of Gauge, the object MUST 244 have the value of its SYNTAX clause changed to Gauge32, or 245 Unsigned32 where appropriate. 247 (6) For all objects, the ACCESS clause MUST be replaced by a MAX-ACCESS 248 clause. The value of the MAX-ACCESS clause SHALL be the same as 249 that of the ACCESS clause unless some other value makes "protocol 250 sense" as the maximal level of access for the object. In 251 particular, object types for which instances can be explicitly 252 created by a protocol set operation, SHALL have a MAX-ACCESS clause 253 of "read-create". If the value of the ACCESS clause is "write- 254 only", then the value of the MAX-ACCESS clause MUST be "read- 255 write", and the DESCRIPTION clause SHALL note that reading this 256 object will result in implementation-specific results. Note that 257 in SMIv1, the ACCESS clause specifies the minimal required access, 258 while in SMIv2, the MAX-ACCESS clause specifies the maximum allowed 259 access. This should be considered when converting an ACCESS clause 260 to a MAX-ACCESS clause. 262 (7) For all objects, if the value of the STATUS clause is "mandatory" 263 or "optional", the value MUST be replaced with "current", 264 "deprecated", or "obsolete" depending on the current usage of such 265 objects. 267 (8) For any object not containing a DESCRIPTION clause, the object MUST 268 have a DESCRIPTION clause defined. 270 (9) For any object corresponding to a conceptual row which does not 271 have an INDEX clause, the object MUST have either an INDEX clause 272 or an AUGMENTS clause defined. 274 (10) If any INDEX clause contains a reference to an object with a syntax 275 of NetworkAddress, then a new object MUST be created and placed in 276 this INDEX clause immediately preceding the object whose syntax is 277 NetworkAddress. This new object MUST have a syntax of INTEGER, it 278 MUST be not-accessible, and its value MUST always be 1. This 279 approach allows one to convert a MIB module in SMIv1 format to one 280 in SMIv2 format, and then use it with the SNMPv1 protocol with no 281 impact to existing SNMPv1 agents and managers. 283 (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be 284 changed to IpAddress. Note that the use of NetworkAddress in new 285 MIB documents is strongly discouraged (in fact, new MIB documents 286 should be written using SMIv2, which does not define 287 NetworkAddress). 289 (12) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER 290 value which is expressed as a collection of sub-identifiers, the 291 value MUST be changed to reference a single ASN.1 identifier. This 292 may require defining a series of new administrative assignments 293 (OBJECT IDENTIFIERS) in order to define the single ASN.1 294 identifier. 296 (13) One or more OBJECT-GROUPS MUST be defined, and related objects 297 SHOULD be collected into appropriate groups. Note that SMIv2 298 requires all OBJECT-TYPEs to be a member of at least one OBJECT- 299 GROUP. 301 Other changes are desirable, but not necessary: 303 (1) Creation and deletion of conceptual rows is inconsistent using the 304 SMIv1. The SMIv2 corrects this. As such, if the MIB module 305 undergoes review early in its lifetime, and it contains conceptual 306 tables which allow creation and deletion of conceptual rows, then 307 the objects relating to those tables MAY be deprecated and replaced 308 with objects defined using the new approach. The approach based on 309 SMIv2 can be found in section 7 of RFC2578 [7], and the RowStatus 310 and StorageType TEXTUAL-CONVENTIONs are described in section 2 of 311 RFC2579 [8]. 313 (2) For any object with a string-valued SYNTAX clause, in which the 314 corresponding OCTET STRING does not have a size restriction (i.e., 315 the OCTET STRING has no assignment of lower- and upper-bounds on 316 its length), the bounds for the size of the object SHOULD be 317 defined. 319 (3) All textual conventions informally defined in the MIB module SHOULD 320 be redefined using the TEXTUAL-CONVENTION macro. Such a change 321 would not necessitate deprecating objects previously defined using 322 an informal textual convention. 324 (4) For any object which represents a measurement in some kind of 325 units, a UNITS clause SHOULD be added to the definition of that 326 object. 328 (5) For any conceptual row which is an extension of another conceptual 329 row, i.e., for which subordinate columnar objects both exist and 330 are identified via the same semantics as the other conceptual row, 331 an AUGMENTS clause SHOULD be used in place of the INDEX clause for 332 the object corresponding to the conceptual row which is an 333 extension. 335 Finally, to avoid common errors in SMIv1 MIB modules: 337 (1) For any non-columnar object that is instanced as if it were 338 immediately subordinate to a conceptual row, the value of the 339 STATUS clause of that object MUST be changed to "obsolete". 341 (2) For any conceptual row object that is not contained immediately 342 subordinate to a conceptual table, the value of the STATUS clause 343 of that object (and all subordinate objects) MUST be changed to 344 "obsolete". 346 2.1.2. Trap and Notification Definitions 348 If a MIB module is changed to conform to the SMIv2, then each 349 occurrence of the TRAP-TYPE macro MUST be changed to a corresponding 350 invocation of the NOTIFICATION-TYPE macro: 352 (1) The IMPORTS statement MUST NOT reference RFC-1215 [4], and MUST 353 reference SNMPv2-SMI instead. 355 (2) The ENTERPRISE clause MUST be removed. 357 (3) The VARIABLES clause MUST be renamed to the OBJECTS clause. 359 (4) A STATUS clause MUST be added, with an appropriate value. Normally 360 the value should be 'current,' although 'deprecated' or 'obsolete' 361 may be used as needed. 363 (5) The value of an invocation of the NOTIFICATION-TYPE macro is an 364 OBJECT IDENTIFIER, not an INTEGER, and MUST be changed accordingly. 365 Specifically, if the value of the ENTERPRISE clause is not 'snmp' 366 then the value of the invocation SHALL be the value of the 367 ENTERPRISE clause extended with two sub-identifiers, the first of 368 which has the value 0, and the second has the value of the 369 invocation of the TRAP-TYPE. If the value of the ENTERPRISE clause 370 is 'snmp', then the value of the invocation of the NOTIFICATION- 371 TYPE macro SHALL be mapped in the same manner as described in 372 section 3.1 in this document. 374 (6) A DESCRIPTION clause MUST be added, if not already present. 376 (7) One or more NOTIFICATION-GROUPs MUST be defined, and related 377 notifications MUST be collected into those groups. Note that SMIv2 378 requires that all NOTIFICATION-TYPEs be a member of at least one 379 NOTIFICATION-GROUP. 381 2.2. Compliance Statements 383 For those information modules which are "standards track", a 384 corresponding invocation of the MODULE-COMPLIANCE macro and related 385 OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included within 386 the information module (or in a companion information module), and 387 any commentary text in the information module which relates to 388 compliance SHOULD be removed. Typically this editing can occur when 389 the information module undergoes review. 391 Note that a MODULE-COMPLIANCE statement is not required for a MIB 392 document that is not on the standards track (for example, an 393 enterprise MIB), though it may be useful in some circumstances to 394 define a MODULE-COMPLIANCE statement for such a MIB document. 396 2.3. Capabilities Statements 398 RFC1303 [5] uses the MODULE-CONFORMANCE macro to describe an agent's 399 capabilities with respect to one or more MIB modules. Converting 400 such a description for use with the SMIv2 requires these changes: 402 (1) The macro name AGENT-CAPABILITIES SHOULD be used instead of MODULE- 403 CONFORMANCE. 405 (2) The STATUS clause SHOULD be added, with a value of 'current'. 407 (3) All occurrences of the CREATION-REQUIRES clause MUST either be 408 omitted if appropriate, or be changed such that the semantics are 409 consistent with RFC2580 [9]. 411 In order to ease coexistence, object groups defined in an SMIv1 412 compliant MIB module may be referenced by the INCLUDES clause of an 413 invocation of the AGENT-CAPABILITIES macro: upon encountering a 414 reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB 415 module, all leaf objects which are subordinate to the subtree and 416 have a STATUS clause value of mandatory are deemed to be INCLUDEd. 417 (Note that this method is ambiguous when different revisions of an 418 SMIv1 MIB have different sets of mandatory objects under the same 419 subtree; in such cases, the only solution is to rewrite the MIB using 420 the SMIv2 in order to define the object groups unambiguously.) 422 3. Translating Notifications Parameters 424 This section describes how parameters used for generating 425 notifications are translated between the format used for SNMPv1 426 notification protocol operations and the format used for SNMPv2 427 notification protocol operations. The parameters used to generate a 428 notification are called 'notification parameters.' The format of 429 parameters used for SNMPv1 notification protocol operations is 430 refered to in this document as 'SNMPv1 notification parameters.' The 431 format of parameters used for SNMPv2 notification protocol operations 432 is refered to in this document as 'SNMPv2 notification parameters.' 434 The situations where notification parameters MUST be translated are: 436 - When an entity generates a set of notification parameters in a 437 particular format, and the configuration of the entity 438 indicates that the notification must be sent using an SNMP 439 message version that requires the other format for 440 notification parameters. 442 - When a proxy receives a notification that was sent using an 443 SNMP message version that requires one format of notification 444 parameters, and must forward the notification using an SNMP 445 message version that requires the other format of notification 446 parameters. 448 In addition, it MAY be desirable to translate notification parameters 449 in a notification receiver application in order to present 450 notifications to the end user in a consistent format. 452 Note that for the purposes of this section, the set of notification 453 parameters is independent of whether the notification is to be sent 454 as a trap or an inform. 456 SNMPv1 notification parameters consist of: 458 - An enterprise parameter (OBJECT IDENTIFIER). 460 - An agent-addr parameter (NetworkAddress). 462 - A generic-trap parameter (INTEGER). 464 - A specific-trap parameter (INTEGER). 466 - A time-stamp parameter (TimeTicks). 468 - A list of variable-bindings (VarBindList). 470 SNMPv2 notification parameters consist of: 472 - A sysUpTime parameter (TimeTicks). This appears in the first 473 variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU. 475 - An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in 476 the second variable-binding in an SNMPv2-Trap-PDU or 477 InformRequest-PDU, and is equal to the value portion of that 478 variable-binding (not the name portion, as both the name and 479 value are OBJECT IDENTIFIERs). 481 - A list of variable-bindings (VarBindList). This refers to all 482 but the first two variable-bindings in an SNMPv2-Trap-PDU or 483 InformRequest-PDU. 485 3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification 486 Parameters 488 The following procedure describes how to translate SNMPv1 489 notification parameters into SNMPv2 notification parameters: 491 (1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the 492 SNMPv1 time-stamp parameter. 494 (2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)', 495 the SNMPv2 snmpTrapOID parameter SHALL be the concatentation of the 496 SNMPv1 enterprise parameter and two additional sub-identifiers, 497 '0', and the SNMPv1 specific-trap parameter. 499 (3) If the SNMPv1 generic-trap parameter is not 500 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be 501 the corresponding trap as defined in section 2 of RFC1907 [12]: 503 generic-trap parameter snmpTrapOID.0 504 ====================== ============= 505 0 1.3.6.1.6.3.1.1.5.1 (coldStart) 506 1 1.3.6.1.6.3.1.1.5.2 (warmStart) 507 2 1.3.6.1.6.3.1.1.5.3 (linkDown) 508 3 1.3.6.1.6.3.1.1.5.4 (linkUp) 509 4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 510 5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 512 (4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-bindings. 513 In addition, if the translation is being performed by a proxy in 514 order to forward a received trap, three additional variable- 515 bindings will be appended, if these three additional variable- 516 bindings do not already exist in the SNMPv1 variable-bindings. The 517 name portion of the first additional variable binding SHALL contain 518 snmpTrapAddress.0, and the value SHALL contain the SNMPv1 agent- 519 addr parameter. The name portion of the second additional variable 520 binding SHALL contain snmpTrapCommunity.0, and the value SHALL 521 contain the value of the community-string field from the received 522 SNMPv1 message which contained the SNMPv1 Trap-PDU. The name 523 portion of the third additional variable binding SHALL contain 524 snmpTrapEnterprise.0 [12], and the value SHALL be the SNMPv1 525 enterprise parameter. 527 3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification 528 Parameters 530 The following procedure describes how to translate SNMPv2 531 notification parameters into SNMPv1 notification parameters: 533 (1) The SNMPv1 enterprise parameter SHALL be determined as follows: 535 - If the SNMPv2 snmpTrapOID parameter is one of the standard 536 traps as defined in RFC1907 [12], then the SNMPv1 enterprise 537 parameter SHALL be set to the value of the variable-binding in 538 the SNMPv2 variable-bindings whose name is 539 snmpTrapEnterprise.0 if that variable-binding exists. If it 540 does not exist, the SNMPv1 enterprise parameter SHALL be set 541 to the value 'snmpTraps' as defined in RFC1907 [12]. 543 - If the SNMPv2 snmpTrapOID parameter is not one of the standard 544 traps as defined in RFC1907 [12], then the SNMPv1 enterprise 545 parameter SHALL be determined from the SNMPv2 snmpTrapOID 546 parameter as follows: 548 - If the next-to-last sub-identifier of the snmpTrapOID 549 value is zero, then the SNMPv1 enterprise SHALL be the 550 SNMPv2 snmpTrapOID value with the last 2 sub-identifiers 551 removed, otherwise 553 - If the next-to-last sub-identifier of the snmpTrapOID 554 value is non-zero, then the SNMPv1 enterprise SHALL be the 555 SNMPv2 snmpTrapOID value with the last sub-identifier 556 removed. 558 (2) The SNMPv1 agent-addr parameter SHALL be determined based on the 559 situation in which the translation occurs. 561 - If the translation occurs within a notification originator 562 application, and the notification is to be sent over IP, the 563 SNMPv1 agent-addr parameter SHALL be set to the IP address of 564 the SNMP entity in which the notification originator resides. 565 If the notification is to be sent over some other transport, 566 the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0. 568 - If the translation occurs within a proxy application, the 569 proxy must attempt to extract the original source of the 570 notification from the variable-bindings. If the SNMPv2 571 variable-bindings contains a variable binding whose name is 572 snmpTrapAddress.0, the agent-addr parameter SHALL be set to 573 the value of that variable binding. Otherwise, the SNMPv1 574 agent-addr parameter SHALL be set to 0.0.0.0. 576 (3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as 577 defined in RFC1907 [12], the SNMPv1 generic-trap parameter SHALL be 578 set as follows: 580 snmpTrapOID.0 parameter generic-trap 581 =============================== ============ 582 1.3.6.1.6.3.1.1.5.1 (coldStart) 0 583 1.3.6.1.6.3.1.1.5.2 (warmStart) 1 584 1.3.6.1.6.3.1.1.5.3 (linkDown) 2 585 1.3.6.1.6.3.1.1.5.4 (linkUp) 3 586 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4 587 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5 589 Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6. 591 (4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as 592 defined in RFC1907 [12], the SNMPv1 specific-trap parameter SHALL 593 be set to zero. Otherwise, the SNMPv1 specific-trap parameter 594 SHALL be set to the last sub-identifier of the SNMPv2 snmpTrapOID 595 parameter. 597 (5) The SNMPv1 time-stamp parameter SHALL be taken directly from the 598 SNMPv2 sysUpTime parameter. 600 (6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-bindings, 601 with the variable-bindings containing sysUpTime.0, snmpTrapOID.0, 602 and snmpTrapAddress.0 removed. Note, however, that if the SNMPv2 603 variable-bindings contain any objects whose type is Counter64, the 604 translation to SNMPv1 notification parameters cannot be performed. 605 In this case, the notification cannot be encoded in an SNMPv1 606 packet (and so the notification cannot be sent using SNMPv1, see 607 section 4.1.3 and section 4.2). 609 4. Approaches to Coexistence in a Multi-lingual Network 611 There are two basic approaches to coexistence in a multi-lingual 612 network, multi-lingual implementations and proxy implementations. 613 Multi-lingual implementations allow elements in a network to 614 communicate with each other using an SNMP version which both elements 615 support. This allows a multi-lingual implementation to communicate 616 with any mono-lingual implementation, regardless of the SNMP version 617 supported by the mono-lingual implementation. 619 Proxy implementations provide a mechanism for translating between 620 SNMP versions using a third party network element. This allows 621 network elements which support only a single, but different, SNMP 622 version to communicate with each other. Proxy implementations are 623 also useful for securing communications over an insecure link between 624 two locally secure networks. 626 4.1. Multi-lingual implementations 628 This approach requires an entity to support multiple SNMP message 629 versions. Typically this means supporting SNMPv1, SNMPv2c, and 630 SNMPv3 message versions. The behaviour of various types of SNMP 631 applications which support multiple message versions is described in 632 the following sections. This approach allows entities which support 633 multiple SNMP message versions to coexist with and communicate with 634 entities which support only a single SNMP message version. 636 4.1.1. Command Generator 638 A command generator must select an appropriate message version when 639 sending requests to another entity. One way to achieve this is to 640 consult a local database to select the appropriate message version. 642 In addition, a command generator MUST 'downgrade' GetBulk requests to 643 GetNext requests when selecting SNMPv1 as the message version for an 644 outgoing request. This is done by simply changing the operation type 645 to GetNext, ignoring any non-repeaters and max-repetitions values, 646 and setting error-status and error-index to zero. 648 4.1.2. Command Responder 650 A command responder must be able to deal with both SNMPv1 and SNMPv2 651 access to MIB data. There are three aspects to dealing with this. A 652 command responder must: 654 - Deal correctly with SNMPv2 access to MIB data that returns a 655 Counter64 value while processing an SNMPv1 message, 657 - Deal correctly with SNMPv2 access to MIB data that returns one 658 of the three exception values while processing an SNMPv1 659 message, and 661 - Map SNMPv2 error codes returned from SNMPv2 access to MIB data 662 into SNMPv1 error codes when processing an SNMPv1 message. 664 Note that SNMPv1 error codes SHOULD NOT be used without any change 665 when processing SNMPv2c or SNMPv3 messages, except in the case of 666 proxy forwarding. In the case of proxy forwarding, for backwards 667 compatibility, SNMPv1 error codes may be used without any change in a 668 forwarded SNMPv2c or SNMPv3 message. 670 The following sections describe the behaviour of a command responder 671 application which supports multiple SNMP message versions, and which 672 uses some combination of SNMPv1 and SNMPv2 access to MIB data. 674 4.1.2.1. Handling Counter64 676 The SMIv2 [7] defines one new syntax that is incompatible with SMIv1. 677 This syntax is Counter64. All other syntaxes defined by SMIv2 are 678 compatible with SMIv1. 680 The impact on multi-lingual command responders is that they MUST NOT 681 ever return a variable binding containing a Counter64 value in a 682 response to a request that was received using the SNMPv1 message 683 version. 685 Multi-lingual command responders SHALL take the approach that object 686 instances whose type is Counter64 are implicitly excluded from view 687 when processing an SNMPv1 message. So: 689 - On receipt of an SNMPv1 GetRequest-PDU containing a variable 690 binding whose name field points to an object instance of type 691 Counter64, a GetResponsePDU SHALL be returned, with an error- 692 status of noSuchName and the error-index set to the variable 693 binding that caused this error. 695 - On an SNMPv1 GetNextRequest-PDU, any object instance which 696 contains a syntax of Counter64 SHALL be skipped, and the next 697 accessible object instance that does not have the syntax of 698 Counter64 SHALL be retrieved. If no such object instance 699 exists, then an error-status of noSuchName SHALL be returned, 700 and the error-index SHALL be set to the variable binding that 701 caused this error. 703 - Any SNMPv1 request which contains a variable binding with a 704 Counter64 value is ill-formed, so the foregoing rules do not 705 apply. If that error is detected, a response SHALL NOT be 706 returned, since it would contain a copy of the ill-formed 707 variable binding. Instead, the offending PDU SHALL be 708 discarded and the counter snmpInASNParseErrs SHALL be 709 incremented. 711 4.1.2.2. Mapping SNMPv2 Exceptions 713 SNMPv2 provides a feature called exceptions, which allow an SNMPv2 714 Response PDU to return as much management information as possible, 715 even when an error occurs. However, SNMPv1 does not support 716 exceptions, and so an SNMPv1 Response PDU cannot return any 717 management information, and can only return an error-status and 718 error-index value. 720 When an SNMPv1 request is received, a command responder MUST check 721 any variable bindings returned using SNMPv2 access to MIB data for 722 exception values, and convert these exception values into SNMPv1 723 error codes. 725 The type of exception that can be returned when accessing MIB data 726 and the action taken depends on the type of SNMP request. 728 - For a GetRequest, a noSuchObject or noSuchInstance exception 729 may be returned. 731 - For a GetNextRequest, an endOfMibView exception may be 732 returned. 734 - No exceptions will be returned for a SetRequest, and a 735 GetBulkRequest should only be received in an SNMPv2c or SNMPv3 736 message, so these request types may be ignored when mapping 737 exceptions. 739 Note that when a response contains multiple exceptions, it is an 740 implementation choice as to which variable binding the error-index 741 should reference. 743 4.1.2.2.1. Mapping noSuchObject and noSuchInstance 745 A noSuchObject or noSuchInstance exception generated by an SNMPv2 746 access to MIB data indicates that the requested object instance can 747 not be returned. The SNMPv1 error code for this condition is 748 noSuchName, and so the error-status field of the response PDU SHALL 749 be set to noSuchName. Also, the error-index field SHALL be set to 750 the index of the variable binding for which an exception occurred 751 (there may be more than one and it is an implementation decision as 752 to which is used), and the variable binding list from the original 753 request SHALL be returned with the response PDU. 755 4.1.2.2.2. Mapping endOfMibView 757 When an SNMPv2 access to MIB data returns a variable binding 758 containing an endOfMibView exception, it indicates that there are no 759 object instances available which lexicographically follow the object 760 in the request. In an SNMPv1 agent, this condition normally results 761 in a noSuchName error, and so the error-status field of the response 762 PDU SHALL be set to noSuchName. Also, the error-index field SHALL be 763 set to the index of the variable binding for which an exception 764 occurred (there may be more than one and it is an implementation 765 decision as to which is used), and the variable binding list from the 766 original request SHALL be returned with the response PDU. 768 4.1.2.3. Processing An SNMPv1 GetRequest 770 When processing an SNMPv1 GetRequest, the following procedures MUST 771 be followed when using an SNMPv2 access to MIB data. 773 When such an access to MIB data returns response data using SNMPv2 774 syntax and error-status values, then: 776 (1) If the error-status is anything other than noError, 778 - The error status SHALL be translated to an SNMPv1 error-status 779 using the table in section 4.3, "Error Status Mappings". 781 - The error-index SHALL be set to the position (in the original 782 request) of the variable binding that caused the error-status. 784 - The variable binding list of the response PDU SHALL be made 785 exactly the same as the variable binding list that was 786 received in the original request. 788 (2) If the error-status is noError, the variable bindings SHALL be 789 checked for any SNMPv2 exception (noSuchObject or noSuchInstance) 790 or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64). If 791 there are any such variable bindings, one of those variable 792 bindings SHALL be selected (it is an implementation choice as to 793 which is selected), and: 795 - The error-status SHALL be set to noSuchName, 797 - The error-index SHALL be set to the position (in the variable 798 binding list of the original request) of the selected variable 799 binding, and 801 - The variable binding list of the response PDU SHALL be exactly 802 the same as the variable binding list that was received in the 803 original request. 805 (3) If there are no such variable bindings, then: 807 - The error-status SHALL be set to noError, 809 - The error-index SHALL be set to zero, and 811 - The variable binding list of the response SHALL be composed 812 from the data as it is returned by the access to MIB data. 814 4.1.2.4. Processing An SNMPv1 GetNextRequest 816 When processing an SNMPv1 GetNextRequest, the following procedures 817 MUST be followed when an SNMPv2 access to MIB data is called as part 818 of processing the request. There may be repetitive accesses to MIB 819 data to try to find the first object which lexicographically follows 820 each of the objects in the request. This is implementation specific. 821 These procedures are followed only for data returned when using 822 SNMPv2 access to MIB data. Data returned using SNMPv1 access to MIB 823 data may be treated in the normal manner for an SNMPv1 request. 825 First, if the access to MIB data returns an error-status of anything 826 other than noError: 828 (1) The error status SHALL be translated to an SNMPv1 error-status 829 using the table in section 4.3, "Error Status Mappings". 831 (2) The error-index SHALL be set to the position (in the original 832 request) of the variable binding that caused the error-status. 834 (3) The variable binding list of the response PDU SHALL be exactly the 835 same as the variable binding list that was received in the original 836 request. 838 Otherwise, if the access to MIB data returns an error-status of 839 noError: 841 (1) Any variable bindings containing an SNMPv2 syntax of Counter64 842 SHALL be considered to be not in view, and MIB data SHALL be 843 accessed as many times as is required until either a value other 844 than Counter64 is returned, or an error occurs. 846 (2) If there is any variable binding that contains an SNMPv2 exception 847 endOfMibView (there may be more than one, it is an implementation 848 decision as to which is chosen): 850 - The error-status SHALL be set to noSuchName, 852 - The error-index SHALL be set to the position (in the variable 853 binding list of the original request) of the variable binding 854 that returned such an SNMPv2 exception, and 856 - The variable binding list of the response PDU SHALL be exactly 857 the same as the variable binding list that was received in the 858 original request. 860 (3) If there are no such variable bindings, then: 862 - The error-status SHALL be set to noError, 864 - The error-index SHALL be set to zero, and 866 - The variable binding list of the response SHALL be composed 867 from the data as it is returned by the access to MIB data. 869 4.1.2.5. Processing An SNMPv1 SetRequest 871 When processing an SNMPv1 SetRequest, the following procedures MUST 872 be followed when calling SNMPv2 MIB access routines. 874 When such MIB access routines return response data using SNMPv2 875 syntax and error-status values, and the error-status is anything 876 other than noError, then: 878 - The error status SHALL be translated to an SNMPv1 error-status 879 using the table in section 4.3, "Error Status Mappings". 881 - The error-index SHALL be set to the position (in the original 882 request) of the variable binding that caused the error-status. 884 - The variable binding list of the response PDU SHALL be made 885 exactly the same as the variable binding list that was 886 received in the original request. 888 4.1.3. Notification Originator 890 A notification originator must be able to translate between SNMPv1 891 notifications parameters and SNMPv2 notification parameters in order 892 to send a notification using a particular SNMP message version. If a 893 notification is generated using SNMPv1 notification parameters, and 894 configuration information specifies that notifications be sent using 895 SNMPv2c or SNMPv3, the notification parameters must be translated to 896 SNMPv2 notification parameters. Likewise, if a notification is 897 generated using SNMPv2 notification parameters, and configuration 898 information specifies that notifications be sent using SNMPv1, the 899 notification parameters must be translated to SNMPv1 notification 900 parameters. In this case, if the notification cannot be translated 901 (due to the presence of a Counter64 type), it will not be sent using 902 SNMPv1. 904 When a notification originator generates a notification, using 905 parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION- 906 MIB, if the SNMP version used to generate the notification is SNMPv1, 907 the PDU type used will always be a TrapPDU, regardless of whether the 908 value of snmpNotifyType is trap(1) or inform(2). 910 Note also that access control and notification filtering are 911 performed in the usual manner for notifications, regardless of the 912 SNMP message version to be used when sending a notification. The 913 parameters for performing access control are found in the usual 914 manner (i.e., from inspecting the SNMP-TARGET-MIB and SNMP- 915 NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in 916 order to perform the access check specified in [18], section 3.3, 917 bullet (3), the notification originator may need to generate a value 918 for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of 919 this document. If the SNMPv1 notification parameters being used were 920 previously translated from a set of SNMPv2 notification parameters, 921 this value may already be known, in which case it need not be 922 generated. 924 4.1.4. Notification Receiver 926 There are no special requirements of a notification receiver. 927 However, an implementation may find it useful to allow a higher level 928 application to request whether notifications should be delivered to a 929 higher level application using SNMPv1 notification parameter or 930 SNMPv2 notification parameters. The notification receiver would then 931 translate notification parameters when required in order to present a 932 notification using the desired set of parameters. 934 4.2. Proxy Implementations 936 A proxy implementation may be used to enable communication between 937 entities which support different SNMP message versions. This is 938 accomplished in a proxy forwarder application by performing 939 translations on PDUs. These translations depend on the PDU type, the 940 SNMP version of the packet containing a received PDU, and the SNMP 941 version to be used to forward a received PDU. The following sections 942 describe these translations. In all cases other than those described 943 below, the proxy SHALL forward a received PDU without change, subject 944 to size contraints as defined in section 5.3 (Community MIB) of this 945 document. Note that in the following sections, the 'Upstream 946 Version' refers to the version used between the command generator and 947 the proxy, and the 'Downstream Version' refers to the version used 948 between the proxy and the command responder, regardless of the PDU 949 type or direction. 951 4.2.1. Upstream Version Greater Than Downstream Version 953 - If a GetBulkRequest-PDU is received and must be forwarded 954 using the SNMPv1 message version, the proxy forwarder SHALL 955 set the non-repeaters and max-repetitions fields to 0, and 956 SHALL set the tag of the PDU to GetNextRequest-PDU. 958 - If a GetResponse-PDU is received whose error-status field has 959 a value of 'tooBig', the message will be forwarded using the 960 SNMPv2c or SNMPv3 message version, and the original request 961 received by the proxy was not a GetBulkRequest-PDU, the proxy 962 forwarder SHALL remove the contents of the variable-bindings 963 field before forwarding the response. 965 - If a GetResponse-PDU is received whose error-status field has 966 a value of 'tooBig,' and the message will be forwarded using 967 the SNMPv2c or SNMPv3 message version, and the original 968 request received by the proxy was a GetBulkRequest-PDU, the 969 proxy forwarder SHALL re-send the forwarded request (which 970 would have been altered to be a GetNextRequest-PDU) with all 971 but the first variable-binding removed. The proxy forwarder 972 SHALL only re-send such a request a single time. If the 973 resulting GetResponse-PDU also contains an error-status field 974 with a value of 'tooBig,' then the proxy forwarder SHALL 975 remove the contents of the variable-bindings field, and change 976 the error-status field to 'noError' before forwarding the 977 response. Note that if the original request only contained a 978 single variable-binding, the proxy may skip re-sending the 979 request and simply remove the variable-bindings and change the 980 error-status to 'noError.' 982 - If a Trap-PDU is received, and will be forwarded using the 983 SNMPv2c or SNMPv3 message version, the proxy SHALL apply the 984 translation rules described in section 3, and SHALL forward 985 the notification as an SNMPv2-Trap-PDU. 987 Note that when an SNMPv1 agent generates a message containing 988 a Trap-PDU which is subsequently forwarded by one or more 989 proxy forwarders using SNMP versions other than SNMPv1, the 990 community string and agent-addr fields from the original 991 message generated by the SNMPv1 agent will be preserved 992 through the use of the snmpTrapAddress and snmpTrapCommunity 993 objects. 995 4.2.2. Upstream Version Less Than Downstream Version 997 - If a GetResponse-PDU is received in response to a GetRequest- 998 PDU (previously generated by the proxy) which contains 999 variable-bindings of type Counter64 or which contain an SNMPv2 1000 exception code, and the message would be forwarded using the 1001 SNMPv1 message version, the proxy MUST generate an alternate 1002 response PDU consisting of the request-id and variable 1003 bindings from the original SNMPv1 request, containing a 1004 noSuchName error-status value, and containing an error-index 1005 value indicating the position of the variable-binding 1006 containing the Counter64 type or exception code. 1008 - If a GetResponse-PDU is received in response to a 1009 GetNextRequest-PDU (previously generated by the proxy) which 1010 contains variable-bindings that contain an SNMPv2 exception 1011 code, and the message would be forwarded using the SNMPv1 1012 message version, the proxy MUST generate an alternate response 1013 PDU consisting of the request-id and variable bindings from 1014 the original SNMPv1 request, containing a noSuchName error- 1015 status value, and containing an error-index value indicating 1016 the position of the variable-binding containing the exception 1017 code. 1019 - If a GetResponse-PDU is received in response to a 1020 GetNextRequest-PDU (previously generated by the proxy) which 1021 contains variable-bindings of type Counter64, the proxy MUST 1022 re-send the entire GetNextRequest-PDU, with the following 1023 modifications. For any variable bindings in the received 1024 GetResponse which contained Counter64 types, the proxy 1025 substitutes the object names of these variable bindings for 1026 the corresponding object names in the previously-sent 1027 GetNextRequest. The proxy MUST repeat this process until no 1028 Counter64 objects are returned. Note that an implementation 1029 may attempt to optimize this process of skipping Counter64 1030 objects. One approach to such an optimization would be to 1031 replace the last sub-identifier of the object names of 1032 varbinds containing a Counter64 type with 65535 if that sub- 1033 identifier is less than 65535, or with 4294967295 if that 1034 sub-identifier is greater than 65535. This approach should 1035 skip multiple instances of the same Counter64 object, while 1036 maintaining compatibility with some broken agent 1037 implementations (which only use 16-bit integers for sub- 1038 identifiers). 1040 Deployment Hint: The process of repeated GetNext requests 1041 used by a proxy when Counter64 types are returned can be 1042 expensive. When deploying a proxy, this can be avoided by 1043 configuring the target agents to which the proxy forwards 1044 requests in a manner such that any objects of type Counter64 1045 are in fact not-in-view for the principal that the proxy is 1046 using when communicating with these agents. 1048 - If a GetResponse-PDU is received which contains an SNMPv2 1049 error-status value of wrongValue, wrongEncoding, wrongType, 1050 wrongLength, inconsistentValue, noAccess, notWritable, 1051 noCreation, inconsistentName, resourceUnavailable, 1052 commitFailed, undoFailed, or authorizationError, the error- 1053 status value is modified using the mappings in section 4.3. 1055 - If an SNMPv2-Trap-PDU is received, and will be forwarded using 1056 the SNMPv1 message version, the proxy SHALL apply the 1057 translation rules described in section 3, and SHALL forward 1058 the notification as a Trap-PDU. Note that if the translation 1059 fails due to the existence of a Counter64 data-type in the 1060 received SNMPv2-Trap-PDU, the trap cannot be forwarded using 1061 SNMPv1. 1063 - If an InformRequest-PDU is received, any configuration 1064 information indicating that it would be forwarded using the 1065 SNMPv1 message version SHALL be ignored. An InformRequest-PDU 1066 can only be forwarded using the SNMPv2c or SNMPv3 message 1067 version. The InformRequest-PDU may still be forwarded if 1068 there is other configuration information indicating that it 1069 should be forwarded using SNMPv2c or SNMPv3. 1071 4.3. Error Status Mappings 1073 The following tables shows the mappings of SNMPv1 error-status values 1074 into SNMPv2 error-status values, and the mappings of SNMPv2 error- 1075 status values into SNMPv1 error-status values. 1077 SNMPv1 error-status SNMPv2 error-status 1078 =================== =================== 1079 noError noError 1080 tooBig tooBig 1081 noSuchName noSuchName 1082 badValue badValue 1083 genErr genErr 1085 SNMPv2 error-status SNMPv1 error-status 1086 =================== =================== 1087 noError noError 1088 tooBig tooBig 1089 genErr genErr 1090 wrongValue badValue 1091 wrongEncoding badValue 1092 wrongType badValue 1093 wrongLength badValue 1094 inconsistentValue badValue 1095 noAccess noSuchName 1096 notWritable noSuchName 1097 noCreation noSuchName 1098 inconsistentName noSuchName 1099 resourceUnavailable genErr 1100 commitFailed genErr 1101 undoFailed genErr 1102 authorizationError noSuchName 1104 Whenever the SNMPv2 error-status value of authorizationError is 1105 translated to an SNMPv1 error-status value of noSuchName, the value 1106 of snmpInBadCommunityUses MUST be incremented. 1108 5. Message Processing Models and Security Models 1110 In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture, 1111 the following models are defined in this document: 1113 - The SNMPv1 Message Processing Model 1115 - The SNMPv1 Community-Based Security Model 1117 The following models are also described in this document: 1119 - The SNMPv2c Message Processing Model 1121 - The SNMPv2c Community-Based Security Model 1123 In most respects, the SNMPv1 Message Processing Model and the 1124 SNMPv2c Message Processing Model are identical, and so these 1125 are not discussed independently in this document. Differences 1126 between the two models are described as required. 1128 Similarly, the SNMPv1 Community-Based Security Model and the 1129 SNMPv2c Community-Based Security Model are nearly identical, 1130 and so are not discussed independently. Differences between 1131 these two models are also described as required. 1133 5.1. Mappings 1135 The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model 1136 require mappings between parameters used in SNMPv1 (and SNMPv2c) 1137 messages, and the version independent parameters used in the SNMP 1138 architecture [16]. The parameters which MUST be mapped consist of the 1139 SNMPv1 (and SNMPv2c) community name, and the SNMP securityName and 1140 contextEngineID/contextName pair. A MIB module (the SNMP-COMMUNITY-MIB) 1141 is provided in this document in order to perform these mappings. This 1142 MIB provides mappings in both directions, that is, a community name may 1143 be mapped to a securityName, contextEngineID, and contextName, or the 1144 combination of securityName, contextEngineID, and contextName may be 1145 mapped to a community name. 1147 5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model 1149 The SNMPv1 Message Processing Model handles processing of SNMPv1 1150 messages. The processing of messages is handled generally in the 1151 same manner as described in RFC1157 [2], with differences and 1152 clarifications as described in the following sections. The 1153 SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for 1154 SNMPv2c is 1). 1156 5.2.1. Processing An Incoming Request 1158 In RFC1157 [2], section 4.1, item (3) for an entity which receives a 1159 message, states that various parameters are passed to the 'desired 1160 authentication scheme.' The desired authentication scheme in this 1161 case is the SNMPv1 Community-Based Security Model, which will be 1162 called using the processIncomingMsg ASI. The parameters passed to 1163 this ASI are: 1165 - The messageProcessingModel, which will be 0 (or 1 for 1166 SNMPv2c). 1168 - The maxMessageSize, which should be the maximum size of a 1169 message that the receiving entity can generate (since there is 1170 no such value in the received message). 1172 - The securityParameters, which consist of the community string 1173 and the message's source and destination transport domains and 1174 addresses. 1176 - The securityModel, which will be 1 (or 2 for SNMPv2c). 1178 - The securityLevel, which will be noAuthNoPriv. 1180 - The wholeMsg and wholeMsgLength. 1182 The Community-Based Security Model will attempt to select a row in 1183 the snmpCommunityTable. This is done by performing a search through 1184 the snmpCommunityTable in lexicographic order. The first entry for 1185 which the following matching criteria are satisfied will be selected: 1187 - The community string is equal to the snmpCommunityName value. 1189 - If the snmpCommunityTransportTag is an empty string, it is 1190 ignored for the purpose of matching. If the 1191 snmpCommunityTransportTag is not an empty string, the 1192 transportDomain and transportAddress from which the message 1193 was received must match one of the entries in the 1194 snmpTargetAddrTable selected by the snmpCommunityTransportTag 1195 value. The snmpTargetAddrTMask object is used as described in 1196 section 5.3 when checking whether the transportDomain and 1197 transportAddress matches a entry in the snmpTargetAddrTable. 1199 If no such entry can be found, an authentication failure occurs as 1200 described in RFC1157 [2], and the snmpInBadCommunityNames counter is 1201 incremented. 1203 The parameters returned from the Community-Based Security Model are: 1205 - The securityEngineID, which will always be the local value of 1206 snmpEngineID.0. 1208 - The securityName. 1210 - The scopedPDU. Note that this parameter will actually consist 1211 of three values, the contextSnmpEngineID (which will be the 1212 value of snmpCommunityContextEngineID from the selected entry 1213 in the snmpCommunityTable), the contextName (which will be the 1214 value of snmpCommunityContextName from the selected entry in 1215 the snmpCommunityTable), and the PDU. These must be separate 1216 values, since the first two do not actually appear in the 1217 message. 1219 - The maxSizeResponseScopedPDU. 1221 - The securityStateReference. 1223 The appropriate SNMP application will then be called (depending on 1224 the value of the contextEngineID and the request type in the PDU) 1225 using the processPdu ASI. The parameters passed to this ASI are: 1227 - The messageProcessingModel, which will be 0 (or 1 for 1228 SNMPv2c). 1230 - The securityModel, which will be 1 (or 2 for SNMPv2c). 1232 - The securityName, which was returned from the call to 1233 processIncomingMsg. 1235 - The securityLevel, which is noAuthNoPriv. 1237 - The contextEngineID, which was returned as part of the 1238 ScopedPDU from the call to processIncomingMsg. 1240 - The contextName, which was returned as part of the ScopedPDU 1241 from the call to processIncomingMsg. 1243 - The pduVersion, which should indicate an SNMPv1 version PDU 1244 (if the message version was SNMPv2c, this would be an SNMPv2 1245 version PDU). 1247 - The PDU, which was returned as part of the ScopedPDU from the 1248 call to processIncomingMsg. 1250 - The maxSizeResponseScopedPDU which was returned from the call 1251 to processIncomingMsg. 1253 - The stateReference which was returned from the call to 1254 processIncomingMsg. 1256 The SNMP application should process the request as described 1257 previously in this document. Note that access control is applied by 1258 an SNMPv3 command responder application as usual. The parameters as 1259 passed to the processPdu ASI will be used in calls to the 1260 isAccessAllowed ASI. 1262 5.2.2. Generating An Outgoing Response 1264 There is no special processing required for generating an outgoing 1265 response. However, the community string used in an outgoing response 1266 must be the same as the community string from the original request. 1267 The original community string MUST be present in the stateReference 1268 information of the original request. 1270 5.2.3. Generating An Outgoing Notification 1272 In a multi-lingual SNMP entity, the parameters used for generating 1273 notifications will be obtained by examining the SNMP-TARGET-MIB and 1274 SNMP-NOTIFICATION-MIB. These parameters will be passed to the SNMPv1 1275 Message Processing Model using the sendPdu ASI. The SNMPv1 Message 1276 Processing Model will attempt to locate an appropriate community 1277 string in the snmpCommunityTable based on the parameters passed to 1278 the sendPdu ASI. This is done by performing a search through the 1279 snmpCommunityTable in lexicographic order. The first entry for which 1280 the following matching criteria are satisfied will be selected: 1282 - The securityName must be equal to the 1283 snmpCommunitySecurityName value. 1285 - The contextEngineID must be equal to the 1286 snmpCommunityContextEngineID value. 1288 - The contextName must be equal to the snmpCommunityContextName 1289 value. 1291 - If the snmpCommunityTransportTag is an empty string, it is 1292 ignored for the purpose of matching. If the 1293 snmpCommunityTransportTag is not an empty string, the 1294 transportDomain and transportAddress must match one of the 1295 entries in the snmpTargetAddrTable selected by the 1296 snmpCommunityTransportTag value. 1298 If no such entry can be found, the notification is not sent. 1299 Otherwise, the community string used in the outgoing notification 1300 will be the value of the snmpCommunityName column of the selected 1301 row. 1303 5.2.4. Proxy Forwarding Of Requests 1305 In a proxy forwarding application, when a received request is to be 1306 forwarded using the SNMPv1 Message Processing Model, the parameters 1307 used for forwarding will be obtained by examining the SNMP-PROXY-MIB 1308 and the SNMP-TARGET-MIB. These parameters will be passed to the 1309 SNMPv1 Message Processing Model using the sendPdu ASI. The SNMPv1 1310 Message Processing Model will attempt to locate an appropriate 1311 community string in the snmpCommunityTable based on the parameters 1312 passed to the sendPdu ASI. This is done by performing a search 1313 through the snmpCommunityTable in lexicographic order. The first 1314 entry for which the following matching criteria are satisfied will be 1315 selected: 1317 - The securityName must be equal to the 1318 snmpCommunitySecurityName value. 1320 - The contextEngineID must be equal to the 1321 snmpCommunityContextEngineID value. 1323 - The contextName must be equal to the snmpCommunityContextName 1324 value. 1326 - If the snmpCommunityTransportTag is an empty string, it is 1327 ignored for the purpose of matching. If the 1328 snmpCommunityTransportTag is not an empty string, the 1329 transportDomain and transportAddress must match one of the 1330 entries in the snmpTargetAddrTable selected by the 1331 snmpCommunityTransportTag value. 1333 If no such entry can be found, the proxy forwarding application 1334 should follow the procedure described in RFC 2573 [18], section 1335 3.5.1.1, item (2). This procedure states that the snmpProxyDrops 1336 counter [12] is incremented, and that a Response-PDU is generated by 1337 calling the Dispatcher using the returnResponsePdu abstract service 1338 interface. 1340 5.3. The SNMP Community MIB Module 1342 The SNMP-COMMUNITY-MIB contains objects for mapping between community 1343 strings and version-independent SNMP message parameters. In 1344 addition, this MIB provides a mechanism for performing source address 1345 validation on incoming requests, and for selecting community strings 1346 based on target addresses for outgoing notifications. These two 1347 features are accomplished by providing a tag in the 1348 snmpCommunityTable which selects sets of entries in the 1349 snmpTargetAddrTable [18]. In addition, the SNMP-COMMUNITY-MIB 1350 augments the snmpTargetAddrTable with a transport address mask value 1351 and a maximum message size value. These values are used only where 1352 explicitly stated. In cases where the snmpTargetAddrTable is used 1353 without mention of these augmenting values, the augmenting values 1354 should be ignored. 1356 The mask value, snmpTargetAddrTMask, allows selected entries in the 1357 snmpTargetAddrTable to specify multiple addresses (rather than just a 1358 single address per entry). This would typically be used to specify a 1359 subnet in an snmpTargetAddrTable rather than just a single address. 1360 The mask value is used to select which bits of a transport address 1361 must match bits of the corresponding instance of 1362 snmpTargetAddrTAddress, in order for the transport address to match a 1363 particular entry in the snmpTargetAddrTable. The value of an 1364 instance of snmpTargetAddrTMask must always be an OCTET STRING whose 1365 length is either zero or the same as that of the corresponding 1366 instance of snmpTargetAddrTAddress. 1368 Note that the snmpTargetAddrTMask object is only used where 1369 explicitly stated. In particular, it is not used when generating 1370 notifications (i.e., when generating notifications, entries in the 1371 snmpTargetAddrTable only specify individual addresses). 1373 When checking whether a transport address matches an entry in the 1374 snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero- 1375 length OCTET STRING, the mask value is ignored, and the value of 1376 snmpTargetAddrTAddress must exactly match a transport address. 1377 Otherwise, each bit of each octet in the snmpTargetAddrTMask value 1378 corresponds to the same bit of the same octet in the 1379 snmpTargetAddrTAddress value. For bits that are set in the 1380 snmpTargetAddrTMask value (i.e., bits equal to 1), the corresponding 1381 bits in the snmpTargetAddrTAddress value must match the bits in a 1382 transport address. If all such bits match, the transport address is 1383 matched by that snmpTargetAddrTable entry. Otherwise, the transport 1384 address is not matched. 1386 The maximum message size value, snmpTargetAddrMMS, is used to 1387 determine the maximum message size acceptable to another SNMP entity 1388 when the value cannot be determined from the protocol. 1390 SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN 1392 IMPORTS 1393 IpAddress, 1394 MODULE-IDENTITY, 1395 OBJECT-TYPE, 1396 Integer32, 1397 snmpModules 1398 FROM SNMPv2-SMI 1399 RowStatus, 1400 StorageType 1401 FROM SNMPv2-TC 1402 SnmpAdminString, 1403 SnmpEngineID 1404 FROM SNMP-FRAMEWORK-MIB 1405 SnmpTagValue, 1406 snmpTargetAddrEntry 1407 FROM SNMP-TARGET-MIB 1408 MODULE-COMPLIANCE, 1409 OBJECT-GROUP 1410 FROM SNMPv2-CONF; 1412 snmpCommunityMIB MODULE-IDENTITY 1413 LAST-UPDATED "199910050000Z" -- 5 Oct 1999, midnight 1414 ORGANIZATION "SNMPv3 Working Group" 1415 CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com 1416 Subscribe: majordomo@lists.tislabs.com 1417 In msg body: subscribe snmpv3 1419 Co-Chair: Russ Mundy 1420 Trusted Information Systems 1421 Postal: 3060 Washington Rd 1422 Glenwood, Maryland 21738 1423 USA 1424 EMail: mundy@tislabs.com 1425 Phone: +1-301-854-6889 1426 Co-Chair: David Harrington 1427 Enterasys Networks 1428 Postal: 35 Industrial Way 1429 P. O. Box 5004 1430 Rochester, New Hampshire 03866-5005 1431 USA 1432 EMail: dbh@enterasys.com 1433 Phone: +1 603-337-2614 1435 Co-editor: Rob Frye 1436 Longitude Systems, Inc. 1437 Postal: 15000 Conference Center Drive 1438 Chantilly, Virginia 20151 1439 USA 1440 E-mail: rfrye@longsys.com 1441 Phone: +1-703-818-5426 1443 Co-editor: David B. Levi 1444 Nortel Networks 1445 Postal: 3505 Kesterwood Drive 1446 Knoxville, Tennessee 37918 1447 E-mail: dlevi@nortelnetworks.com 1448 Phone: +1 423 686 0432 1450 Co-editor: Shawn A. Routhier 1451 Integrated Systems Inc. 1452 Postal: 333 North Ave 4th Floor 1453 Wakefield, Massachusetts 01880 1454 E-mail: sar@epilogue.com 1455 Phone: +1 781 245 0804 1457 Co-editor: Bert Wijnen 1458 Lucent Technologies 1459 Postal: Schagen 33 1460 3461 GL Linschoten 1461 Netherlands 1462 Email: bwijnen@lucent.com 1463 Phone: +31-348-680-485 1464 " 1466 DESCRIPTION 1467 "This MIB module defines objects to help support coexistence 1468 between SNMPv1, SNMPv2c, and SNMPv3." 1469 REVISION "199905130000Z" -- 13 May 1999 1470 DESCRIPTION "The Initial Revision" 1471 REVISION "199910050000Z" -- 5 Oct 1999 (same as LAST-UPDATED) 1472 DESCRIPTION "This version published as RFC xxxx" 1473 -- RFC-editor assigns xxxx 1474 ::= { snmpModules 18 } 1476 -- Administrative assignments **************************************** 1478 snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 } 1479 snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 } 1481 -- 1482 -- The snmpCommunityTable contains a database of community strings. 1483 -- This table provides mappings between community strings, and the 1484 -- parameters required for View-based Access Control. 1485 -- 1487 snmpCommunityTable OBJECT-TYPE 1488 SYNTAX SEQUENCE OF SnmpCommunityEntry 1489 MAX-ACCESS not-accessible 1490 STATUS current 1491 DESCRIPTION 1492 "The table of community strings configured in the SNMP 1493 engine's Local Configuration Datastore (LCD)." 1494 ::= { snmpCommunityMIBObjects 1 } 1496 snmpCommunityEntry OBJECT-TYPE 1497 SYNTAX SnmpCommunityEntry 1498 MAX-ACCESS not-accessible 1499 STATUS current 1500 DESCRIPTION 1501 "Information about a particular community string." 1502 INDEX { IMPLIED snmpCommunityIndex } 1503 ::= { snmpCommunityTable 1 } 1505 SnmpCommunityEntry ::= SEQUENCE { 1506 snmpCommunityIndex SnmpAdminString, 1507 snmpCommunityName OCTET STRING, 1508 snmpCommunitySecurityName SnmpAdminString, 1509 snmpCommunityContextEngineID SnmpEngineID, 1510 snmpCommunityContextName SnmpAdminString, 1511 snmpCommunityTransportTag SnmpTagValue, 1512 snmpCommunityStorageType StorageType, 1513 snmpCommunityStatus RowStatus 1514 } 1516 snmpCommunityIndex OBJECT-TYPE 1517 SYNTAX SnmpAdminString (SIZE(1..32)) 1518 MAX-ACCESS not-accessible 1519 STATUS current 1520 DESCRIPTION 1521 "The unique index value of a row in this table." 1522 ::= { snmpCommunityEntry 1 } 1524 snmpCommunityName OBJECT-TYPE 1525 SYNTAX OCTET STRING 1526 MAX-ACCESS read-create 1527 STATUS current 1528 DESCRIPTION 1529 "The community string for which a row in this table 1530 represents a configuration." 1531 ::= { snmpCommunityEntry 2 } 1533 snmpCommunitySecurityName OBJECT-TYPE 1534 SYNTAX SnmpAdminString (SIZE(1..32)) 1535 MAX-ACCESS read-create 1536 STATUS current 1537 DESCRIPTION 1538 "A human readable string representing the corresponding 1539 value of snmpCommunityName in a Security Model 1540 independent format." 1541 ::= { snmpCommunityEntry 3 } 1543 snmpCommunityContextEngineID OBJECT-TYPE 1544 SYNTAX SnmpEngineID 1545 MAX-ACCESS read-create 1546 STATUS current 1547 DESCRIPTION 1548 "The contextEngineID indicating the location of the 1549 context in which management information is accessed 1550 when using the community string specified by the 1551 corresponding instance of snmpCommunityName. 1553 The default value is the snmpEngineID of the entity in 1554 which this object is instantiated." 1555 ::= { snmpCommunityEntry 4 } 1557 snmpCommunityContextName OBJECT-TYPE 1558 SYNTAX SnmpAdminString (SIZE(0..32)) 1559 MAX-ACCESS read-create 1560 STATUS current 1561 DESCRIPTION 1562 "The context in which management information is accessed 1563 when using the community string specified by the corresponding 1564 instance of snmpCommunityName." 1565 DEFVAL { ''H } -- the empty string 1566 ::= { snmpCommunityEntry 5 } 1568 snmpCommunityTransportTag OBJECT-TYPE 1569 SYNTAX SnmpTagValue 1570 MAX-ACCESS read-create 1571 STATUS current 1572 DESCRIPTION 1573 "This object specifies a set of transport endpoints which 1574 are associated with a community string. The community string 1575 is only valid when found in an SNMPv1 (or SNMPv2c) message 1576 received from one of these transport endpoints, or when 1577 used in an SNMPv1 (or SNMPv2c) message to be sent to one 1578 of these transport endpoints. 1580 The value of this object identifies a set of entries in 1581 the snmpTargetAddrTable. Entries in that table whose 1582 snmpTargetAddrTagList contains a tag matching the value 1583 of this object are identified. 1585 When the SNMPv1 (or SNMPv2c) message processing model is 1586 attempting to choose an entry from the snmpCommunityTable 1587 for the purpose of processing a received SNMPv1 (or SNMPv2c) 1588 message, the transport endpoint from which the message was 1589 received must match one of the transport endpoints 1590 identified by this object. 1592 Likewise, when the SNMPv1 (or SNMPv2c) message processing 1593 model is attempting to choose an entry from the 1594 snmpCommunityTable for the purpose of generating an outgoing 1595 SNMPv1 (or SNMPv2c) message, the transport endpoint to which 1596 the message is to be sent must match one of the transport 1597 endpoints identified by this object. 1599 If the value of this object has zero-length, transport 1600 endpoints are not checked when attempting to choose an 1601 entry in the snmpCommunityTable (e.g., the community string 1602 is valid for use with any transport endpoint)." 1603 DEFVAL { ''H } -- the empty string 1604 ::= { snmpCommunityEntry 6 } 1606 snmpCommunityStorageType OBJECT-TYPE 1607 SYNTAX StorageType 1608 MAX-ACCESS read-create 1609 STATUS current 1610 DESCRIPTION 1611 "The storage type for this conceptual row in the 1612 snmpCommunityTable. Conceptual rows having the value 1613 'permanent' need not allow write-access to any 1614 columnar object in the row." 1616 ::= { snmpCommunityEntry 7 } 1618 snmpCommunityStatus OBJECT-TYPE 1619 SYNTAX RowStatus 1620 MAX-ACCESS read-create 1621 STATUS current 1622 DESCRIPTION 1623 "The status of this conceptual row in the snmpCommunityTable. 1625 An entry in this table is not qualified for activation 1626 until instances of all corresponding columns have been 1627 initialized, either through default values, or through 1628 Set operations. The snmpCommunityName and 1629 snmpCommunitySecurityName objects must be explicitly set. 1631 There is no restriction on setting columns in this table 1632 when the value of snmpCommunityStatus is active(1)." 1633 ::= { snmpCommunityEntry 8 } 1635 -- 1636 -- The snmpTargetAddrExtTable 1637 -- 1639 snmpTargetAddrExtTable OBJECT-TYPE 1640 SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry 1641 MAX-ACCESS not-accessible 1642 STATUS current 1643 DESCRIPTION 1644 "The table of mask and mms values associated with the 1645 snmpTargetAddrTable. 1647 The snmpTargetAddrExtTable augments the 1648 snmpTargetAddrTable with a transport address mask value 1649 and a maximum message size value. The transport address 1650 mask allows entries in the snmpTargetAddrTable to define 1651 a set of addresses instead of just a single address. 1652 The maximum message size value allows the maximum 1653 message size of another SNMP entity to be configured for 1654 use in SNMPv1 (and SNMPv2c) transactions, where the 1655 message format does not specify a maximum message size." 1656 ::= { snmpCommunityMIBObjects 2 } 1658 snmpTargetAddrExtEntry OBJECT-TYPE 1659 SYNTAX SnmpTargetAddrExtEntry 1660 MAX-ACCESS not-accessible 1661 STATUS current 1662 DESCRIPTION 1663 "Information about a particular mask and mms value." 1664 AUGMENTS { snmpTargetAddrEntry } 1665 ::= { snmpTargetAddrExtTable 1 } 1667 SnmpTargetAddrExtEntry ::= SEQUENCE { 1668 snmpTargetAddrTMask OCTET STRING, 1669 snmpTargetAddrMMS Integer32 1670 } 1672 snmpTargetAddrTMask OBJECT-TYPE 1673 SYNTAX OCTET STRING (SIZE (0..255)) 1674 MAX-ACCESS read-create 1675 STATUS current 1676 DESCRIPTION 1677 "The mask value associated with an entry in the 1678 snmpTargetAddrTable. The value of this object must 1679 have the same length as the corresponding instance of 1680 snmpTargetAddrTAddress, or must have length 0. An 1681 attempt to set it to any other value will result in 1682 an inconsistentValue error. 1684 The value of this object allows an entry in the 1685 snmpTargetAddrTable to specify multiple addresses. 1686 The mask value is used to select which bits of 1687 a transport address must match bits of the corresponding 1688 instance of snmpTargetAddrTAddress, in order for the 1689 transport address to match a particular entry in the 1690 snmpTargetAddrTable. Bits which are 1 in the mask 1691 value indicate bits in the transport address which 1692 must match bits in the snmpTargetAddrTAddress value. 1693 Bits which are 0 in the mask indicate bits in the 1694 transport address which need not match. If the 1695 length of the mask is 0, the mask should be treated 1696 as if all its bits were 1 and its length were equal 1697 to the length of the corresponding value of 1698 snmpTargetAddrTable. 1700 This object may not be modified while the value of the 1701 corresponding instance of snmpTargetAddrRowStatus is 1702 active(1). An attempt to set this object in this case 1703 will result in an inconsistentValue error." 1704 DEFVAL { ''H } 1705 ::= { snmpTargetAddrExtEntry 1 } 1707 snmpTargetAddrMMS OBJECT-TYPE 1708 SYNTAX Integer32 (0|484..2147483647) 1709 MAX-ACCESS read-create 1710 STATUS current 1711 DESCRIPTION 1712 "The maximum message size value associated with an entry 1713 in the snmpTargetAddrTable. Note that a value of 0 means 1714 that the maximum message size is unknown." 1715 DEFVAL { 484 } 1716 ::= { snmpTargetAddrExtEntry 2 } 1718 -- 1719 -- The snmpTrapAddress and snmpTrapCommunity objects are included 1720 -- in notifications that are forwarded by a proxy, which were 1721 -- originally received as SNMPv1 Trap messages. 1722 -- 1724 snmpTrapAddress OBJECT-TYPE 1725 SYNTAX IpAddress 1726 MAX-ACCESS accessible-for-notify 1727 STATUS current 1728 DESCRIPTION 1729 "The value of the agent-addr field of a Trap PDU which 1730 is forwarded by a proxy forwarder application using 1731 an SNMP version other than SNMPv1. The value of this 1732 object SHOULD contain the value of the agent-addr field 1733 from the original Trap PDU as generated by an SNMPv1 1734 agent." 1735 ::= { snmpCommunityMIBObjects 3 } 1737 snmpTrapCommunity OBJECT-TYPE 1738 SYNTAX OCTET STRING 1739 MAX-ACCESS accessible-for-notify 1740 STATUS current 1741 DESCRIPTION 1742 "The value of the community string field of an SNMPv1 1743 message containing a Trap PDU which is forwarded by a 1744 a proxy forwarder application using an SNMP version 1745 other than SNMPv1. The value of this object SHOULD 1746 contain the value of the community string field from 1747 the original SNMPv1 message containing a Trap PDU as 1748 generated by an SNMPv1 agent." 1749 ::= { snmpCommunityMIBObjects 4 } 1751 -- Conformance Information ******************************************* 1753 snmpCommunityMIBCompliances OBJECT IDENTIFIER 1754 ::= { snmpCommunityMIBConformance 1 } 1755 snmpCommunityMIBGroups OBJECT IDENTIFIER 1756 ::= { snmpCommunityMIBConformance 2 } 1758 -- Compliance statements 1760 snmpCommunityMIBCompliance MODULE-COMPLIANCE 1761 STATUS current 1762 DESCRIPTION 1763 "The compliance statement for SNMP engines which 1764 implement the SNMP-COMMUNITY-MIB." 1766 MODULE -- this module 1767 MANDATORY-GROUPS { snmpCommunityTableGroup } 1769 OBJECT snmpCommunityName 1770 MIN-ACCESS read-only 1771 DESCRIPTION "Write access is not required." 1773 OBJECT snmpCommunitySecurityName 1774 MIN-ACCESS read-only 1775 DESCRIPTION "Write access is not required." 1777 OBJECT snmpCommunityContextEngineID 1778 MIN-ACCESS read-only 1779 DESCRIPTION "Write access is not required." 1781 OBJECT snmpCommunityContextName 1782 MIN-ACCESS read-only 1783 DESCRIPTION "Write access is not required." 1785 OBJECT snmpCommunityTransportTag 1786 MIN-ACCESS read-only 1787 DESCRIPTION "Write access is not required." 1789 OBJECT snmpCommunityStorageType 1790 MIN-ACCESS read-only 1791 DESCRIPTION "Write access is not required." 1793 OBJECT snmpCommunityStatus 1794 MIN-ACCESS read-only 1795 DESCRIPTION "Write access is not required." 1797 ::= { snmpCommunityMIBCompliances 1 } 1799 snmpProxyTrapForwardCompliance MODULE-COMPLIANCE 1800 STATUS current 1801 DESCRIPTION 1802 "The compliance statement for SNMP engines which 1803 contain a proxy forwarding application which is 1804 capable of forwarding SNMPv1 traps using SNMPv2c 1805 or SNMPv3." 1806 MODULE -- this module 1807 MANDATORY-GROUPS { snmpProxyTrapForwardGroup } 1808 ::= { snmpCommunityMIBCompliances 2 } 1810 snmpCommunityTableGroup OBJECT-GROUP 1811 OBJECTS { 1812 snmpCommunityName, 1813 snmpCommunitySecurityName, 1814 snmpCommunityContextEngineID, 1815 snmpCommunityContextName, 1816 snmpCommunityTransportTag, 1817 snmpCommunityStorageType, 1818 snmpCommunityStatus, 1819 snmpTargetAddrTMask, 1820 snmpTargetAddrMMS 1821 } 1822 STATUS current 1823 DESCRIPTION 1824 "A collection of objects providing for configuration 1825 of community strings for SNMPv1 (and SNMPv2c) usage." 1826 ::= { snmpCommunityMIBGroups 1 } 1828 snmpProxyTrapForwardGroup OBJECT-GROUP 1829 OBJECTS { 1830 snmpTrapAddress, 1831 snmpTrapCommunity 1832 } 1833 STATUS current 1834 DESCRIPTION 1835 "Objects which are used by proxy forwarding applications 1836 when translating traps between SNMP versions. These are 1837 used to preserve SNMPv1-specific information when 1838 translating to SNMPv2c or SNMPv3." 1839 ::= { snmpCommunityMIBGroups 3 } 1841 END 1843 6. Intellectual Property 1845 The IETF takes no position regarding the validity or scope of any 1846 intellectual property or other rights that might be claimed to 1847 pertain to the implementation or use of the technology described in 1848 this document or the extent to which any license under such rights 1849 might or might not be available; neither does it represent that it 1850 has made any effort to identify any such rights. Information on the 1851 IETF's procedures with respect to rights in standards-track and 1852 standards-related documentation can be found in BCP-11. Copies of 1853 claims of rights made available for publication and any assurances of 1854 licenses to be made available, or the result of an attempt made to 1855 obtain a general license or permission for the use of such 1856 proprietary rights by implementors or users of this specification can 1857 be obtained from the IETF Secretariat. 1859 The IETF invites any interested party to bring to its attention any 1860 copyrights, patents or patent applications, or other proprietary 1861 rights which may cover technology that may be required to practice 1862 this standard. Please address the information to the IETF Executive 1863 Director. 1865 7. Acknowledgments 1867 This document is the result of the efforts of the SNMPv3 Working 1868 Group. The design of the SNMP-COMMUNITY-MIB incorporates work done 1869 by the authors of SNMPv2*: 1871 Jeff Case (SNMP Research, Inc.) 1872 David Harrington (Enterasys Networks) 1873 David Levi (Nortel Networks) 1874 Brian O'Keefe (Hewlett Packard) 1875 Jon Saperia (IronBridge Networks, Inc.) 1876 Steve Waldbusser (International Network Services) 1878 8. Security Considerations 1880 Although SNMPv1 and SNMPv2 do not provide any security, allowing 1881 community names to be mapped into securityName/contextName provides 1882 the ability to use view-based access control to limit the access of 1883 unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for 1884 network administrators to make use of this capability in order to 1885 avoid unauthorized access to MIB data that would otherwise be secure. 1887 Further, the SNMP-COMMUNITY-MIB has the potential to expose community 1888 strings which provide access to more information than that which is 1889 available using the usual 'public' community string. For this 1890 reason, a security administrator may wish to limit accessibility to 1891 the SNMP-COMMUNITY-MIB, and in particular, to make it inaccessible 1892 when using the 'public' community string. 1894 When a proxy implementation translates messages between SNMPv1 (or 1895 SNMPv2c) and SNMPv3, there may be a loss of security. For example, 1896 an SNMPv3 message received using authentication and privacy which is 1897 subsequently forwarded using SNMPv1 will lose the security benefits 1898 of using authentication and privacy. Careful configuration of 1899 proxies is required to address such situations. One approach to deal 1900 with such situations might be to use an encrypted tunnel. 1902 9. References 1904 [1] Rose, M. and K. McCloghrie, "Structure and Identification of 1905 Management Information for TCP/IP-based internets"", STD16, RFC 1906 1155, May 1990. 1908 [2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1909 Management Protocol", STD15, RFC 1157, SNMP Research, Performance 1910 Systems International, Performance Systems International, MIT 1911 Laboratory for Computer Science, May 1990. 1913 [3] McCloghrie, K., and M. Rose, Editors, "Concise MIB Definitions", 1914 STD 16, RFC 1212, Hughes LAN Systems, Performance Systems 1915 International, March 1991. 1917 [4] Rose, M. T., "A Convention for Defining Traps for use with the 1918 SNMP", RFC 1215, March 1991. 1920 [5] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP- 1921 based Agents", RFC 1303, Hughes LAN Systems, Dover Beach 1922 Consulting, Inc., February 1992. 1924 [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1925 Waldbusser, "Introduction to Community-based SNMPv2", RFC1901, SNMP 1926 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1927 International Network Services, January 1996. 1929 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1930 and S. Waldbusser, "Structure of Management Information Version 2 1931 (SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU 1932 Braunschweig, SNMP Research, First Virtual Holdings, International 1933 Network Services, April 1999. 1935 [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1936 and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 1937 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First 1938 Virtual Holdings, International Network Services, April 1999. 1940 [9] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1941 and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, 1942 STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, 1943 First Virtual Holdings, International Network Services, April 1999. 1945 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1946 Waldbusser, "Protocol Operations for Version 2 of the Simple 1947 Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., 1948 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 1949 Network Services, January 1996. 1951 [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport 1952 Mappings for Version 2 of the Simple Network Management Protocol 1953 (SNMPv2)", RFC 1906, January 1996. 1955 [12] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1956 Waldbusser, "Management Information Base for Version 2 of the 1957 Simple Network Management Protocol (SNMPv2)", RFC1907, SNMP 1958 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1959 International Network Services, January 1996. 1961 [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1962 Waldbusser, "Coexistence between Version 1 and Version 2 of the 1963 Internet-standard Network Management Framework", RFC1908, SNMP 1964 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1965 International Network Services, January 1996. 1967 [14] Levi, D., Wijnen, B., "Mapping SNMPv2 onto SNMPv1 within a bi- 1968 lingual SNMP agent", RFC2089, SNMP Research, Inc., IBM, January 1969 1997. 1971 [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1972 Levels", BCP 14, RFC 2119, March 1997. 1974 [16] The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An 1975 Architecture for Describing SNMP Management Frameworks", RFC 2571, 1976 May 1999. 1978 [17] The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B., 1979 "Message Processing and Dispatching for the Simple Network 1980 Management Protocol (SNMP)", RFC 2572, May 1999. 1982 [18] The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMP 1983 Applications", RFC2573, May 1999. 1985 [19] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User- 1986 Based Security Model for Version 3 of the Simple Network Management 1987 Protocol (SNMP)", RFC 2574, May 1999. 1989 [20] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K., 1990 "View-based Access Control Model for the Simple Network Management 1991 Protocol (SNMP)", RFC 2575, May 1999. 1993 10. Editor's Addresses 1995 Rob Frye 1996 Longitude Systems, Inc. 1997 15000 Conference Cneter Drive 1998 Chantilly, VA 20151 1999 U.S.A. 2000 Phone: +1 703 818 5426 2001 EMail: rfrye@longsys.com 2003 David B. Levi 2004 Nortel Networks 2005 3505 Kesterwood Drive 2006 Knoxville, TN 37918 2007 U.S.A. 2008 Phone: +1 423 686 0432 2009 EMail: dlevi@nortelnetworks.com 2011 Shawn A. Routhier 2012 Integrated Systems Inc. 2013 333 North Ave 4th Floor 2014 Wakefield MA 01880 2015 U.S.A. 2016 Phone: + 1 781 245 0804 2017 EMail: sar@epilogue.com 2019 Bert Wijnen 2020 Lucent Technologies 2021 Schagen 33 2022 3461 GL Linschoten 2023 Netherlands 2024 Phone: +31 348 680 485 2025 EMail: bwijnen@lucent.com 2027 A. Full Copyright Statement 2029 This document and translations of it may be copied and furnished to 2030 others, and derivative works that comment on or otherwise explain it 2031 or assist in its implementation may be prepared, copied, published 2032 and distributed, in whole or in part, without restriction of any 2033 kind, provided that the above copyright notice and this paragraph are 2034 included on all such copies and derivative works. However, this 2035 document itself may not be modified in any way, such as by removing 2036 the copyright notice or references to the Internet Society or other 2037 Internet organizations, except as needed for the purpose of 2038 developing Internet standards in which case the procedures for 2039 copyrights defined in the Internet Standards process must be 2040 followed, or as required to translate it into languages other than 2041 English. 2043 The limited permissions granted above are perpetual and will not be 2044 revoked by the Internet Society or its successors or assigns. 2046 This document and the information contained herein is provided on an 2047 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2048 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2049 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2050 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2051 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2053 B. Changes From RFC1908 2055 - Editorial changes to comply with current RFC requirements. 2057 - Added/updated copyright statements. 2059 - Added Intellectual Property section. 2061 - Replaced old introduction with complete new 2062 introduction/overview. 2064 - Added content for the Security Considerations Section. 2066 - Updated References to current documents. 2068 - Updated text to use current SNMP terminology. 2070 - Added coexistence for/with SNMPv3. 2072 - Added description for SNMPv1 and SNMPv2c Message Processing 2073 Models and SNMPv1 and SNMPv2c Community-based Security Models. 2075 - Added snmpCommunityMIB so that SNMPv1 and SNMPv2 community 2076 strings can be mapped into the SNMP Version Independent 2077 paramaters which can then be used for access control using the 2078 standard SNMPv3 View-based Access Control Model and the 2079 snmpVacmMIB. 2081 - Added two MIB objects such that when an SNMPv1 notification 2082 (trap) must be converted into an SNMPv2 notification we add 2083 those two objects in order to preserve information about the 2084 address and community of the originating SNMPv1 agent. 2086 - Included (and extended) from RFC2089 the SNMPv2 to SNMPv1 2087 mapping within a multi-lingual SNMP Engine. 2089 - Use keywords from RFC 2119 to describe requirements for 2090 compliance. 2092 - Changed/added some rules for converting a MIB module from 2093 SMIv1 to SMIv2. 2095 - Extended and improved the description of Proxy Forwarder 2096 behaviour when multiple SNMP versions are involved. 2098 Table of Contents 2100 1 Overview ..................................................... 4 2101 1.1 SNMPv1 ..................................................... 4 2102 1.2 SNMPv2 ..................................................... 5 2103 1.3 SNMPv3 ..................................................... 6 2104 1.4 SNMPv1 and SNMPv2 Access to MIB Data ....................... 6 2105 2 SMI and Management Information Mappings ...................... 8 2106 2.1 MIB Modules ................................................ 8 2107 2.1.1 Object Definitions ....................................... 8 2108 2.1.2 Trap and Notification Definitions ........................ 11 2109 2.2 Compliance Statements ...................................... 12 2110 2.3 Capabilities Statements .................................... 12 2111 3 Translating Notifications Parameters ......................... 13 2112 3.1 Translating SNMPv1 Notification Parameters to SNMPv2 2113 Notification Parameters ................................... 14 2114 3.2 Translating SNMPv2 Notification Parameters to SNMPv1 2115 Notification Parameters ................................... 15 2116 4 Approaches to Coexistence in a Multi-lingual Network ......... 18 2117 4.1 Multi-lingual implementations .............................. 18 2118 4.1.1 Command Generator ........................................ 18 2119 4.1.2 Command Responder ........................................ 19 2120 4.1.2.1 Handling Counter64 ..................................... 19 2121 4.1.2.2 Mapping SNMPv2 Exceptions .............................. 20 2122 4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 21 2123 4.1.2.2.2 Mapping endOfMibView ................................. 21 2124 4.1.2.3 Processing An SNMPv1 GetRequest ........................ 21 2125 4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 22 2126 4.1.2.5 Processing An SNMPv1 SetRequest ........................ 24 2127 4.1.3 Notification Originator .................................. 24 2128 4.1.4 Notification Receiver .................................... 25 2129 4.2 Proxy Implementations ...................................... 25 2130 4.2.1 Upstream Version Greater Than Downstream Version ......... 25 2131 4.2.2 Upstream Version Less Than Downstream Version ............ 26 2132 4.3 Error Status Mappings ...................................... 29 2133 5 Message Processing Models and Security Models ................ 30 2134 5.1 Mappings ................................................... 30 2135 5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security 2136 Model ..................................................... 30 2137 5.2.1 Processing An Incoming Request ........................... 31 2138 5.2.2 Generating An Outgoing Response .......................... 33 2139 5.2.3 Generating An Outgoing Notification ...................... 33 2140 5.2.4 Proxy Forwarding Of Requests ............................. 34 2141 5.3 The SNMP Community MIB Module .............................. 35 2142 6 Intellectual Property ........................................ 46 2143 7 Acknowledgments .............................................. 47 2144 8 Security Considerations ...................................... 48 2145 9 References ................................................... 49 2146 10 Editor's Addresses .......................................... 51 2147 A. Full Copyright Statement .................................... 52 2148 B. Changes From RFC1908 ........................................ 53