idnits 2.17.1 draft-ietf-snmpv3-update-transmap-06.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. 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 37 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 209 has weird spacing: '... octets cont...' == Line 238 has weird spacing: '... octets cont...' == Line 288 has weird spacing: '... octets cont...' == Line 290 has weird spacing: '...address net...' == Line 368 has weird spacing: '... Each insta...' == (1 more instance...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (2 July 2001) is 8305 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ASN1' is mentioned on line 318, but not defined -- Looks like a reference, but probably isn't: '5' on line 596 == Unused Reference: 'RFC-TMM' is defined on line 824, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'APPLETALK' -- Possible downref: Non-RFC (?) normative reference: ref. 'BER' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS8072' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS8072A' -- Possible downref: Non-RFC (?) normative reference: ref. 'NOVELL' ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1742 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-ARC' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-MPD' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-APL' ** Obsolete normative reference: RFC 2574 (ref. 'RFC-USM') (Obsoleted by RFC 3414) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-ACM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-COEX' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-TMM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-PRO' Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Editor of this version: 2 Request for Comments: -TMM R. Presuhn 3 STD: XXX BMC Software, Inc. 4 Obsoletes: 1906 Authors of previous version: 5 Category: Standards Track J. Case 6 SNMP Research, Inc. 7 K. McCloghrie 8 Cisco Systems, Inc. 9 M. Rose 10 Dover Beach Consulting, Inc. 11 S. Waldbusser 12 International Network Services 13 2 July 2001 15 Transport Mappings for 16 the Simple Network Management Protocol 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright Notice 40 Copyright (C) The Internet Society (2001). All Rights Reserved. 42 Abstract 44 This document defines the transport of SNMP messages over various 45 protocols. This document obsoletes RFC 1906. 47 Table of Contents 49 1. Introduction ................................................ 3 50 2. Definitions ................................................. 4 51 3. SNMP over UDP over IPv4 ..................................... 8 52 3.1. Serialization ............................................. 8 53 3.2. Well-known Values ......................................... 8 54 4. SNMP over OSI ............................................... 8 55 4.1. Serialization ............................................. 8 56 4.2. Well-known Values ......................................... 9 57 5. SNMP over DDP ............................................... 9 58 5.1. Serialization ............................................. 9 59 5.2. Well-known Values ......................................... 9 60 5.3. Discussion of AppleTalk Addressing ........................ 10 61 5.3.1. How to Acquire NBP names ................................ 10 62 5.3.2. When to Turn NBP names into DDP addresses ............... 11 63 5.3.3. How to Turn NBP names into DDP addresses ................ 11 64 5.3.4. What if NBP is broken ................................... 11 65 6. SNMP over IPX ............................................... 12 66 6.1. Serialization ............................................. 12 67 6.2. Well-known Values ......................................... 12 68 7. Proxy to SNMPv1 ............................................. 13 69 8. Serialization using the Basic Encoding Rules ................ 13 70 8.1. Usage Example ............................................. 13 71 9. Notice on Intellectual Property ............................. 14 72 10. Acknowledgments ............................................ 15 73 11. Security Considerations .................................... 16 74 12. References ................................................. 17 75 13. Editor's Address ........................................... 19 76 14. Changes from RFC 1906 ...................................... 19 77 15. Issues ..................................................... 20 78 16. Full Copyright Statement ................................... 21 80 1. Introduction 82 The SNMP Management Framework at the time of this writing consists of 83 five major components: 85 - An overall architecture, described in RFC -ARC [RFC-ARC]. 87 - Mechanisms for describing and naming objects and events for 88 the purpose of management. The first version of this 89 Structure of Management Information (SMI) is called SMIv1 90 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 91 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, 92 called SMIv2, is described in STD 58, RFC 2578 [RFC2578], 93 STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 95 - Message protocols for transferring management information. 96 The first version of the SNMP message protocol is called 97 SNMPv1 and is described in STD 15, RFC 1157 [RFC1157]. A 98 second version of the SNMP message protocol, which is not 99 an Internet standards track protocol, is called SNMPv2c and 100 is described in RFC 1901 [RFC1901] and this document. The 101 third version of the message protocol is called SNMPv3 and 102 described in this document, RFC -MPD [RFC-MPD] and RFC -USM 103 [RFC-USM]. 105 - Protocol operations for accessing management information. 106 The first set of protocol operations and associated PDU 107 formats is described in STD 15, RFC 1157 [RFC1157]. A 108 second set of protocol operations and associated PDU 109 formats is described RFC -PRO [RFC-PRO]. 111 - A set of fundamental applications described in RFC -APL 112 [RFC-APL] and the view-based access control mechanism 113 described in RFC -ACM [RFC-ACM]. 115 A more detailed introduction to the SNMP Management Framework at the 116 time of this writing can be found in RFC 2570 [RFC2570]. 118 Managed objects are accessed via a virtual information store, termed 119 the Management Information Base or MIB. Objects in the MIB are 120 defined using the mechanisms defined in the SMI. 122 This document, Transport Mappings for the Simple Network Management 123 Protocol, defines how the management protocol [RFC-PRO] may be 124 carried over a variety of protocol suites. It is the purpose of this 125 document to define how the SNMP maps onto an initial set of transport 126 domains. Other mappings may be defined in the future. 128 Although several mappings are defined, the mapping onto UDP over IPv4 ! 129 is the preferred mapping for systems supporting IPv4. Systems ! 130 implementing IPv4 MUST implement the mapping onto UDP over IPv4. To ! 131 maximize interoperability, systems supporting other mappings SHOULD ! 132 also provide for access via the UDP over IPv4 mapping. ! 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", ! 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this ! 136 document are to be interpreted as described in RFC 2119 [RFC2119]. ! 138 2. Definitions 140 SNMPv2-TM DEFINITIONS ::= BEGIN 142 IMPORTS ! 143 MODULE-IDENTITY, OBJECT-IDENTITY, ! 144 snmpModules, snmpDomains, snmpProxys 145 FROM SNMPv2-SMI 146 TEXTUAL-CONVENTION 147 FROM SNMPv2-TC; 149 snmpv2tm MODULE-IDENTITY ! 150 LAST-UPDATED "200107021829Z" ! 151 ORGANIZATION "IETF SNMPv3 Working Group" ! 152 CONTACT-INFO ! 153 "WG-EMail: snmpv3@lists.tislabs.com 154 Subscribe: snmpv3-request@lists.tislabs.com 156 Co-Chair: Russ Mundy 157 NAI Labs, 158 Network Associates, Inc. 159 postal: 3060 Washington Rd. 160 Glenwood, MD 21738 161 USA 162 EMail: mundy@tislabs.com 163 phone: +1 301 854-6889 165 Co-Chair: David Harrington 166 Enterasys Networks 167 postal: 35 Industrial Way 168 P. O. Box 5005 169 Rochester, NH 03866-5005 170 USA 171 EMail: dbh@enterasys.com 172 phone: +1 603 337-2614 173 Editor: Randy Presuhn 174 BMC Software, Inc. 175 postal: 2141 North First Street 176 San Jose, CA 95131 177 USA 178 EMail: randy_presuhn@bmc.com 179 phone: +1 408 546-1006" 180 DESCRIPTION 181 "The MIB module for SNMP transport mappings." 182 REVISION "200107021829Z" 183 DESCRIPTION 184 "Clarifications, published as RFC -TMM." 185 REVISION "199601010000Z" 186 DESCRIPTION 187 "Clarifications, published as RFC 1906." 188 REVISION "199304010000Z" 189 DESCRIPTION 190 "The initial version, published as RFC 1449." 191 ::= { snmpModules ?? } -- to be assigned by IANA?? 193 -- SNMP over UDP over IPv4 195 snmpUDPDomain OBJECT-IDENTITY 196 STATUS current 197 DESCRIPTION 198 "The SNMP over UDP over IPv4 transport domain. ! 199 The corresponding transport address is of type 200 SnmpUDPAddress." 201 ::= { snmpDomains 1 } 203 SnmpUDPAddress ::= TEXTUAL-CONVENTION 204 DISPLAY-HINT "1d.1d.1d.1d/2d" 205 STATUS current 206 DESCRIPTION 207 "Represents a UDP over IPv4 address: ! 209 octets contents encoding 210 1-4 IP-address network-byte order 211 5-6 UDP-port network-byte order 212 " 213 SYNTAX OCTET STRING (SIZE (6)) 215 -- SNMP over OSI 216 snmpCLNSDomain OBJECT-IDENTITY 217 STATUS current 218 DESCRIPTION 219 "The SNMP over CLNS transport domain. 220 The corresponding transport address is of type 221 SnmpOSIAddress." 222 ::= { snmpDomains 2 } 224 snmpCONSDomain OBJECT-IDENTITY 225 STATUS current 226 DESCRIPTION 227 "The SNMP over CONS transport domain. 228 The corresponding transport address is of type 229 SnmpOSIAddress." 230 ::= { snmpDomains 3 } 232 SnmpOSIAddress ::= TEXTUAL-CONVENTION 233 DISPLAY-HINT "*1x:/1x:" 234 STATUS current 235 DESCRIPTION 236 "Represents an OSI transport-address: 238 octets contents encoding 239 1 length of NSAP 'n' as an unsigned-integer 240 (either 0 or from 3 to 20) 241 2..(n+1) NSAP concrete binary representation 242 (n+2)..m TSEL string of (up to 64) octets 243 " 244 SYNTAX OCTET STRING (SIZE (1 | 4..85)) 246 -- SNMP over DDP 248 snmpDDPDomain OBJECT-IDENTITY 249 STATUS current 250 DESCRIPTION 251 "The SNMP over DDP transport domain. The corresponding 252 transport address is of type SnmpNBPAddress." 253 ::= { snmpDomains 4 } 255 SnmpNBPAddress ::= TEXTUAL-CONVENTION 256 STATUS current 257 DESCRIPTION 258 "Represents an NBP name: 260 octets contents encoding 261 1 length of object 'n' as an unsigned integer 262 2..(n+1) object string of (up to 32) octets 263 n+2 length of type 'p' as an unsigned integer 264 (n+3)..(n+2+p) type string of (up to 32) octets 265 n+3+p length of zone 'q' as an unsigned integer 266 (n+4+p)..(n+3+p+q) zone string of (up to 32) octets 268 For comparison purposes, strings are 269 case-insensitive. All strings may contain any octet 270 other than 255 (hex ff)." 271 SYNTAX OCTET STRING (SIZE (3..99)) 273 -- SNMP over IPX 275 snmpIPXDomain OBJECT-IDENTITY 276 STATUS current 277 DESCRIPTION 278 "The SNMP over IPX transport domain. The corresponding 279 transport address is of type SnmpIPXAddress." 280 ::= { snmpDomains 5 } 282 SnmpIPXAddress ::= TEXTUAL-CONVENTION 283 DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" 284 STATUS current 285 DESCRIPTION 286 "Represents an IPX address: 288 octets contents encoding 289 1-4 network-number network-byte order 290 5-10 physical-address network-byte order 291 11-12 socket-number network-byte order 292 " 293 SYNTAX OCTET STRING (SIZE (12)) 295 -- for proxy to SNMPv1 (RFC 1157) 297 rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } 299 rfc1157Domain OBJECT-IDENTITY 300 STATUS deprecated ! 301 DESCRIPTION 302 "The transport domain for SNMPv1 over UDP over IPv4. ! 303 The corresponding transport address is of type 304 SnmpUDPAddress." 305 ::= { rfc1157Proxy 1 } 307 -- ::= { rfc1157Proxy 2 } this OID is obsolete 309 END 311 3. SNMP over UDP over IPv4 313 This is the preferred transport mapping. 315 3.1. Serialization 317 Each instance of a message is serialized (i.e., encoded according to 318 the convention of [ASN1]) onto a single UDP [RFC768] over IPv4 319 [RFC791] datagram, using the algorithm specified in Section 8. 321 3.2. Well-known Values 323 It is suggested that administrators configure their SNMP entities 324 supporting command responder applications to listen on UDP port 161. 325 Further, it is suggested that SNMP entities supporting notification 326 receiver applications be configured to listen on UDP port 162. 328 When an SNMP entity uses this transport mapping, it must be capable 329 of accepting messages up to and including 484 octets in size. It is ! 330 recommended that implementations be capable of accepting messages of ! 331 up to 1472 octets in size. Implementation of larger values is ! 332 encouraged whenever possible. 334 4. SNMP over OSI 336 This is an optional transport mapping. 338 4.1. Serialization 340 Each instance of a message is serialized onto a single TSDU [IS8072] 341 [IS8072A] for the OSI Connectionless-mode Transport Service (CLTS), 342 using the algorithm specified in Section 8. 344 4.2. Well-known Values 346 It is suggested that administrators configure their SNMP entities 347 supporting command responder applications to listen on transport 348 selector "snmp-l" (which consists of six ASCII characters), when 349 using a CL-mode network service to realize the CLTS. Further, it is 350 suggested that SNMP entities supporting notification receiver 351 applications be configured to listen on transport selector "snmpt-l" 352 (which consists of seven ASCII characters, six letters and a hyphen) 353 when using a CL-mode network service to realize the CLTS. Similarly, 354 when using a CO-mode network service to realize the CLTS, the 355 suggested transport selectors are "snmp-o" and "snmpt-o", for command 356 responders and notification receivers, respectively. 358 When an SNMP entity uses this transport mapping, it must be capable 359 of accepting messages that are at least 484 octets in size. 360 Implementation of larger values is encouraged whenever possible. 362 5. SNMP over DDP 364 This is an optional transport mapping. 366 5.1. Serialization 368 Each instance of a message is serialized onto a single DDP datagram 369 [APPLETALK], using the algorithm specified in Section 8. 371 5.2. Well-known Values 373 SNMP messages are sent using DDP protocol type 8. SNMP entities 374 supporting command responder applications listen on DDP socket number 375 8, while SNMP entities supporting notification receiver applications 376 listen on DDP socket number 9. 378 Administrators must configure their SNMP entities supporting command 379 responder applications to use NBP type "SNMP Agent" (which consists 380 of ten ASCII characters) while those supporting notification receiver 381 applications must be configured to use NBP type "SNMP Trap Handler" 382 (which consists of seventeen ASCII characters). 384 The NBP name for SNMP entities supporting command responders and 385 notification receivers should be stable - NBP names should not change 386 any more often than the IP address of a typical TCP/IP node. It is 387 suggested that the NBP name be stored in some form of stable storage. 389 When an SNMP entity uses this transport mapping, it must be capable 390 of accepting messages that are at least 484 octets in size. 391 Implementation of larger values is encouraged whenever possible. 393 5.3. Discussion of AppleTalk Addressing 395 The AppleTalk protocol suite has certain features not manifest in the 396 TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of 397 address assignment can cause problems for SNMP entities that wish to 398 manage AppleTalk networks. TCP/IP nodes have an associated IP 399 address which distinguishes each from the other. In contrast, 400 AppleTalk nodes generally have no such characteristic. The network- 401 level address, while often relatively stable, can change at every 402 reboot (or more frequently). 404 Thus, when SNMP is mapped over DDP, nodes are identified by a "name", 405 rather than by an "address". Hence, all AppleTalk nodes that 406 implement this mapping are required to respond to NBP lookups and 407 confirms (e.g., implement the NBP protocol stub), which guarantees 408 that a mapping from NBP name to DDP address will be possible. 410 In determining the SNMP identity to register for an SNMP entity, it 411 is suggested that the SNMP identity be a name which is associated 412 with other network services offered by the machine. 414 NBP lookups, which are used to map NBP names into DDP addresses, can 415 cause large amounts of network traffic as well as consume CPU 416 resources. It is also the case that the ability to perform an NBP 417 lookup is sensitive to certain network disruptions (such as zone 418 table inconsistencies) which would not prevent direct AppleTalk 419 communications between two SNMP entities. 421 Thus, it is recommended that NBP lookups be used infrequently, 422 primarily to create a cache of name-to-address mappings. These 423 cached mappings should then be used for any further SNMP traffic. It 424 is recommended that SNMP entities supporting command generator 425 applications should maintain this cache between reboots. This 426 caching can help minimize network traffic, reduce CPU load on the 427 network, and allow for (some amount of) network trouble shooting when 428 the basic name-to-address translation mechanism is broken. 430 5.3.1. How to Acquire NBP names 432 An SNMP entity supporting command generator applications may have a 433 pre-configured list of names of "known" SNMP entities supporting 434 command responder applications. Similarly, an SNMP entity supporting 435 command generator or notification receiver applications might 436 interact with an operator. Finally, an SNMP entity supporting 437 command generator or notification receiver applications might 438 communicate with all SNMP entities supporting command responder or 439 notification originator applications in a set of zones or networks. 441 5.3.2. When to Turn NBP names into DDP addresses 443 When an SNMP entity uses a cache entry to address an SNMP packet, it 444 should attempt to confirm the validity mapping, if the mapping hasn't 445 been confirmed within the last T1 seconds. This cache entry 446 lifetime, T1, has a minimum, default value of 60 seconds, and should 447 be configurable. 449 An SNMP entity supporting a command generator application may decide 450 to prime its cache of names prior to actually communicating with 451 another SNMP entity. In general, it is expected that such an entity 452 may want to keep certain mappings "more current" than other mappings, 453 e.g., those nodes which represent the network infrastructure (e.g., 454 routers) may be deemed "more important". 456 Note that an SNMP entity supporting command generator applications 457 should not prime its entire cache upon initialization - rather, it 458 should attempt resolutions over an extended period of time (perhaps 459 in some pre- determined or configured priority order). Each of these 460 resolutions might, in fact, be a wildcard lookup in a given zone. 462 An SNMP entity supporting command responder applications must never 463 prime its cache. When generating a response, such an entity does not 464 need to confirm a cache entry. An SNMP entity supporting 465 notification originator applications should do NBP lookups (or 466 confirms) only when it needs to send an SNMP trap or inform. 468 5.3.3. How to Turn NBP names into DDP addresses 470 If the only piece of information available is the NBP name, then an 471 NBP lookup should be performed to turn that name into a DDP address. 472 However, if there is a piece of stale information, it can be used as 473 a hint to perform an NBP confirm (which sends a unicast to the 474 network address which is presumed to be the target of the name 475 lookup) to see if the stale information is, in fact, still valid. 477 An NBP name to DDP address mapping can also be confirmed implicitly 478 using only SNMP transactions. For example, an SNMP entity supporting 479 command generator applications issuing a retrieval operation could 480 also retrieve the relevant objects from the NBP group [RFC1742] for 481 the SNMP entity supporting the command responder application. This 482 information can then be correlated with the source DDP address of the 483 response. 485 5.3.4. What if NBP is broken 487 Under some circumstances, there may be connectivity between two SNMP 488 entities, but the NBP mapping machinery may be broken, e.g., 489 o the NBP FwdReq (forward NBP lookup onto local attached network) 490 mechanism might be broken at a router on the other entity's 491 network; or, 493 o the NBP BrRq (NBP broadcast request) mechanism might be broken 494 at a router on the entity's own network; or, 496 o NBP might be broken on the other entity's node. 498 An SNMP entity supporting command generator applications which is 499 dedicated to AppleTalk management might choose to alleviate some of 500 these failures by directly implementing the router portion of NBP. 501 For example, such an entity might already know all the zones on the 502 AppleTalk internet and the networks on which each zone appears. 503 Given an NBP lookup which fails, the entity could send an NBP FwdReq 504 to the network in which the SNMP entity supporting the command 505 responder or notification originator application was last located. 506 If that failed, the station could then send an NBP LkUp (NBP lookup 507 packet) as a directed (DDP) multicast to each network number on that 508 network. Of the above (single) failures, this combined approach will 509 solve the case where either the local router's BrRq-to-FwdReq 510 mechanism is broken or the remote router's FwdReq-to-LkUp mechanism 511 is broken. 513 6. SNMP over IPX 515 This is an optional transport mapping. 517 6.1. Serialization 519 Each instance of a message is serialized onto a single IPX datagram 520 [NOVELL], using the algorithm specified in Section 8. 522 6.2. Well-known Values 524 SNMP messages are sent using IPX packet type 4 (i.e., Packet Exchange 525 Protocol). 527 It is suggested that administrators configure their SNMP entities 528 supporting command responder applications to listen on IPX socket 529 36879 (900f hexadecimal). Further, it is suggested that those 530 supporting notification receiver applications be configured to listen 531 on IPX socket 36880 (9010 hexadecimal). 533 When an SNMP entity uses this transport mapping, it must be capable 534 of accepting messages that are at least 546 octets in size. 535 Implementation of larger values is encouraged whenever possible. 537 7. Proxy to SNMPv1 539 Historically, in order to support proxy to SNMPv1, as defined in 540 [RFC-COEX], it was deemed useful to define a transport domain, 541 rfc1157Domain, which indicates the transport mapping for SNMP 542 messages as defined in [RFC1157]. 544 8. Serialization using the Basic Encoding Rules 546 When the Basic Encoding Rules [BER] are used for serialization: 548 (1) When encoding the length field, only the definite form is used; 549 use of the indefinite form encoding is prohibited. Note that 550 when using the definite-long form, it is permissible to use more 551 than the minimum number of length octets necessary to encode the 552 length field. 554 (2) When encoding the value field, the primitive form shall be used 555 for all simple types, i.e., INTEGER, OCTET STRING, and OBJECT 556 IDENTIFIER (either IMPLICIT or explicit). The constructed form 557 of encoding shall be used only for structured types, i.e., a 558 SEQUENCE or an IMPLICIT SEQUENCE. 560 (3) When encoding an object whose syntax is described using the BITS 561 construct, the value is encoded as an OCTET STRING, in which all 562 the named bits in (the definition of) the bitstring, commencing 563 with the first bit and proceeding to the last bit, are placed in 564 bits 8 (high order bit) to 1 (low order bit) of the first octet, 565 followed by bits 8 to 1 of each subsequent octet in turn, 566 followed by as many bits as are needed of the final subsequent 567 octet, commencing with bit 8. Remaining bits, if any, of the 568 final octet are set to zero on generation and ignored on 569 receipt. 571 These restrictions apply to all aspects of ASN.1 encoding, including 572 the message wrappers, protocol data units, and the data objects they 573 contain. 575 8.1. Usage Example 577 As an example of applying the Basic Encoding Rules, suppose one 578 wanted to encode an instance of the GetBulkRequest-PDU [RFC-PRO]: 580 [5] IMPLICIT SEQUENCE { 581 request-id 1414684022, 582 non-repeaters 1, 583 max-repetitions 2, 584 variable-bindings { 585 { name sysUpTime, ! 586 value { unSpecified NULL } }, 587 { name ipNetToMediaPhysAddress, ! 588 value { unSpecified NULL } }, 589 { name ipNetToMediaType, ! 590 value { unSpecified NULL } } 591 } 592 } 594 Applying the BER, this may be encoded (in hexadecimal) as: 596 [5] IMPLICIT SEQUENCE a5 82 00 39 597 INTEGER 02 04 54 52 5d 76 598 INTEGER 02 01 01 599 INTEGER 02 01 02 600 SEQUENCE (OF) 30 2b 601 SEQUENCE 30 0b 602 OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03 603 NULL 05 00 604 SEQUENCE 30 0d 605 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02 606 NULL 05 00 607 SEQUENCE 30 0d 608 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 609 NULL 05 00 611 Note that the initial SEQUENCE in this example was not encoded using 612 the minimum number of length octets. (The first octet of the length, 613 82, indicates that the length of the content is encoded in the next 614 two octets.) 616 9. Notice on Intellectual Property 618 The IETF takes no position regarding the validity or scope of any 619 intellectual property or other rights that might be claimed to 620 pertain to the implementation or use of the technology described in 621 this document or the extent to which any license under such rights 622 might or might not be available; neither does it represent that it 623 has made any effort to identify any such rights. Information on the 624 IETF's procedures with respect to rights in standards-track and 625 standards-related documentation can be found in BCP-11. Copies of 626 claims of rights made available for publication and any assurances of 627 licenses to be made available, or the result of an attempt made to 628 obtain a general license or permission for the use of such 629 proprietary rights by implementors or users of this specification can 630 be obtained from the IETF Secretariat. 632 The IETF invites any interested party to bring to its attention any 633 copyrights, patents or patent applications, or other proprietary 634 rights which may cover technology that may be required to practice 635 this standard. Please address the information to the IETF Executive 636 Director. 638 10. Acknowledgments 640 This document is the product of the SNMPv3 Working Group. Some 641 special thanks are in order to the following Working Group members: 643 Randy Bush 644 Jeffrey D. Case 645 Mike Daniele 646 Rob Frye 647 Lauren Heintz 648 Keith McCloghrie 649 Russ Mundy 650 David T. Perkins 651 Randy Presuhn 652 Aleksey Romanov 653 Juergen Schoenwaelder 654 Bert Wijnen 656 This version of the document, edited by Randy Presuhn, was initially 657 based on the work of a design team whose members were: 659 Jeffrey D. Case 660 Keith McCloghrie 661 David T. Perkins 662 Randy Presuhn 663 Juergen Schoenwaelder 665 The previous versions of this document, edited by Keith McCloghrie, 666 was the result of significant work by four major contributors: 668 Jeffrey D. Case 669 Keith McCloghrie 670 Marshall T. Rose 671 Steven Waldbusser 673 Additionally, the contributions of the SNMPv2 Working Group to the 674 previous versions are also acknowledged. In particular, a special 675 thanks is extended for the contributions of: 677 Alexander I. Alten 678 Dave Arneson 679 Uri Blumenthal 680 Doug Book 681 Kim Curran 682 Jim Galvin 683 Maria Greene 684 Iain Hanson 685 Dave Harrington 686 Nguyen Hien 687 Jeff Johnson 688 Michael Kornegay 689 Deirdre Kostick 690 David Levi 691 Daniel Mahoney 692 Bob Natale 693 Brian O'Keefe 694 Andrew Pearson 695 Dave Perkins 696 Randy Presuhn 697 Aleksey Romanov 698 Shawn Routhier 699 Jon Saperia 700 Juergen Schoenwaelder 701 Bob Stewart 702 Kaj Tesink 703 Glenn Waters 704 Bert Wijnen 706 11. Security Considerations 708 SNMPv1 by itself is not a secure environment. Even if the network ! 709 itself is secure (for example by using IPSec), even then, there is no ! 710 control as to who on the secure network is allowed to access and ! 711 GET/SET (read/change) the objects accessible through a command ! 712 responder application. ! 714 It is recommended that the implementors consider the security ! 715 features as provided by the SNMPv3 framework. Specifically, the use ! 716 of the User-based Security Model RFC -USM [RFC-USM] and the ! 717 View-based Access Control Model RFC -ACM [RFC-ACM] is recommended. ! 719 It is then a customer/user responsibility to ensure that the SNMP ! 720 entity giving access to a MIB is properly configured to give access ! 721 to the objects only to those principals (users) that have legitimate ! 722 rights to indeed GET or SET (change) them. ! 724 12. References 726 [APPLETALK] Sidhu, G., Andrews, R., and A. Oppenheimer, Inside 727 AppleTalk (second edition). Addison-Wesley, 1990. 729 [BER] Information processing systems - Open Systems 730 Interconnection - Specification of Basic Encoding Rules 731 for Abstract Syntax Notation One (ASN.1), International 732 Organization for Standardization. International Standard 733 8825, December 1987. 735 [IS8072] Information processing systems - Open Systems 736 Interconnection - Transport Service Definition, 737 International Organization for Standardization. 738 International Standard 8072, June 1986. 740 [IS8072A] Information processing systems - Open Systems 741 Interconnection - Transport Service Definition - Addendum 742 1: Connectionless-mode Transmission, International 743 Organization for Standardization. International Standard 744 8072/AD 1, December 1986. 746 [NOVELL] Network System Technical Interface Overview. Novell, 747 Inc, June 1989. 749 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 750 August 1980. 752 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 753 September 1981. 755 [RFC1155] Rose, M., and K. McCloghrie, "Structure and 756 Identification of Management Information for TCP/IP-based 757 Internets", STD 16, RFC 1155, May 1990. 759 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 760 "Simple Network Management Protocol", STD 15, RFC 1157, 761 May 1990. 763 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 764 STD 16, RFC 1212, March 1991. 766 [RFC1215] Rose, M., "A Convention for Defining Traps for use with 767 the SNMP", RFC 1215, March 1991. 769 [RFC1742] Waldbusser, S. and K. Frisa, "AppleTalk Management 770 Information Base II", RFC 1742, January 1995. 772 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 773 "Introduction to Community-based SNMPv2", RFC 1901, 774 January 1996. 776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 777 Requirement Levels", BCP 14, RFC 2119, March 1997. 779 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 780 "Introduction to Version 3 of the Internet-standard 781 Network Management Framework", RFC 2570, April 1999. 783 [RFC-ARC] Harrington, D., Presuhn, R. and B. Wijnen, "An 784 Architecture for describing SNMP Management Frameworks", 785 , July 2001. 787 [RFC-MPD] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, 788 "Message Processing and Dispatching for the Simple 789 Network Management Protocol (SNMP)", 790 , July 2001. 792 [RFC-APL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", 793 , July 2001. 795 [RFC-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security 796 Model for Version 3 of the Simple Network Management 797 Protocol (SNMPv3)", 798 , July 2001. 800 [RFC-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 801 Access Control Model for the Simple Network Management 802 Protocol (SNMP)", , 803 February 1999. , July 804 2001. 806 [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 807 "Coexistence between Version 1, Version 2, and Version 3 808 of the Internet-standard Network Management Framework", 809 , July 2001. 811 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 812 Rose, M., and S. Waldbusser, "Structure of Management 813 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 814 1999. 816 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 817 Rose, M., and S. Waldbusser, "Textual Conventions for 818 SMIv2", STD 58, RFC 2579, April 1999. 820 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 821 Rose, M., and S. Waldbusser, "Conformance Statements for 822 SMIv2", STD 58, RFC 2580, April 1999. 824 [RFC-TMM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 825 Waldbusser, "Transport Mappings for the Simple Network 826 Management Protocol", 827 , July 2001. 829 [RFC-PRO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 830 Waldbusser, "Protocol Operations for the Simple Network 831 Management Protocol", 832 , July 2001. 834 13. Editor's Address 836 Randy Presuhn 837 BMC Software, Inc. 838 2141 North First Street 839 San Jose, CA 95131 840 USA 842 Phone: +1 408 546-1006 843 EMail: randy_presuhn@bmc.com 845 14. Changes from RFC 1906 847 These are the changes from RFC 1906: 849 - Corrected typo in IPR statement; 851 - Updated copyright date; 853 - Updated with new editor's name and contact information; 855 - Cosmetic fixes to layout and typography; 857 - Changed title, headers and footers; 859 - Fixed typo in SnmpNBPAddress; 861 - Clarified that one of the BER SEQUENCEs in the example is 862 generated from the ASN.1 SEQUENCE OF construct; 864 - Updated acknowledgements section; 866 - Filled in the Security Considerations section; 867 - Replaced manager/agent terminology with terms from 868 architecture; 870 - Updated references section; 872 - Added MODULE-IDENTITY; 874 - Re-wrote introduction section using current boilerplate; 876 - Added recommendation for larger message size support; 878 - Added historical background on use of rfc1157Domain with 879 proxy and changed status to "deprecated"; 881 - Added an abstract; 883 - Strengthened conformance requirement for support of the UDP 884 over IPv4 mapping; 886 - Updated working group mailing list address; 888 - Added address of working group co-chair; 890 - Corrected error in BER example. 892 15. Issues 894 This section is to be deleted when it is time to publish this 895 document as an RFC. The issue labels are the same as those used in 896 the on-line issues list at 897 ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1906/index.html 899 1906-01 Done; title changed. 901 1906-02 Done; introduction clause replaced. 903 1906-03 Done; no action taken. 905 1906-04 Done; resolution required no changes. 907 1906-05 Done; typo in SnmpNBPAddress fixed. 909 1906-06 See issue 1906-10. 911 1906-07 Done; use of manager/agent terminology replaced with 912 terms from architecture. 914 1906-08 Done; added recommendation for support of 1472 byte 915 messages. 917 1906-09 Done; resolution required no changes. 919 1906-10 Done; resolved by deprecating the definition. 921 1906-11 Done; resolution required no changes. 923 1906-12 Done; resolution required no changes. 925 1906-13 Done; resolution required no changes. 927 1906-14 Done; clarified that BER SEQUENCE comes from ASN.1 928 SEQUENCE OF. 930 1906-15 Done; security considerations text added. 932 1906-16 Done; references and acknowledgments updated. 934 1906-17 Done; IPR and copyright notices updated. 936 1906-18 Done; resolution required no changes. 938 1906-19 Done; MODULE-IDENTITY added. 940 1906-20 Done; resolution was to the mapping onto UDP over IPv4 941 mandatory for systems which support IPv4. 943 1906-21 Done; resolution was to make no change. 945 1906-22 Done; resolution was to make no change. 947 1906-23 Done; added abstract. 949 16. Full Copyright Statement 951 Copyright (C) The Internet Society (2001). All Rights Reserved. 953 This document and translations of it may be copied and furnished to 954 others, and derivative works that comment on or otherwise explain it 955 or assist in its implementation may be prepared, copied, published 956 and distributed, in whole or in part, without restriction of any 957 kind, provided that the above copyright notice and this paragraph are 958 included on all such copies and derivative works. However, this 959 document itself may not be modified in any way, such as by removing 960 the copyright notice or references to the Internet Society or other 961 Internet organizations, except as needed for the purpose of 962 developing Internet standards in which case the procedures for 963 copyrights defined in the Internet Standards process must be 964 followed, or as required to translate it into languages other than 965 English. 967 The limited permissions granted above are perpetual and will not be 968 revoked by the Internet Society or its successors or assigns. 970 This document and the information contained herein is provided on an 971 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 972 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 973 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 974 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 975 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.