idnits 2.17.1 draft-ietf-snmpv3-update-transmap-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. == 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 2 instances of too long lines in the document, the longest one being 6 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 201 has weird spacing: '... octets cont...' == Line 231 has weird spacing: '... octets cont...' == Line 281 has weird spacing: '... octets cont...' == Line 283 has weird spacing: '...address net...' == Line 634 has weird spacing: '... The previo...' == (1 more instance...) -- 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 (9 January 2000) is 8873 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 311, but not defined -- Looks like a reference, but probably isn't: '5' on line 590 == Unused Reference: 'RFC-TM' is defined on line 764, but no explicit reference was found in the text == Unused Reference: 'RFC2233' is defined on line 794, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS8072' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS8072A' -- Possible downref: Non-RFC (?) normative reference: ref. 'APPLETALK' ** Downref: Normative reference to an Historic RFC: RFC 1742 -- Possible downref: Non-RFC (?) normative reference: ref. 'NOVELL' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-COEX' -- Possible downref: Non-RFC (?) normative reference: ref. 'BER' ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-TM' ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-PROTO' ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2233 (Obsoleted by RFC 2863) Summary: 16 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Editor of this version: 2 Will Obsolete: 1906 R. Presuhn 3 BMC Software, Inc. 4 9 January 2000 6 Authors of previous version: 7 SNMPv2 Working Group 8 J. Case 9 SNMP Research, Inc. 10 K. McCloghrie 11 Cisco Systems, Inc. 12 M. Rose 13 Dover Beach Consulting, Inc. 14 S. Waldbusser 15 International Network Services 17 Transport Mappings for 18 the Simple Network Management Protocol 19 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. Internet-Drafts are working 25 documents of the Internet Engineering Task Force (IETF), its areas, 26 and its working groups. Note that other groups may also distribute 27 working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright Notice 42 Copyright (C) The Internet Society (2000). All Rights Reserved. 44 Abstract 46 This document is intended to obsolete RFC 1906, Transport Mappings 47 for Version 2 of the Simple Network Management Protocol (SNMPv2). It 48 defines the transport of SNMP messages over various protocols. 50 Table of Contents 52 1. Introduction ................................................ 3 53 2. Definitions ................................................. 4 54 3. SNMP over UDP ............................................... 7 55 3.1. Serialization ............................................. 7 56 3.2. Well-known Values ......................................... 8 57 4. SNMP over OSI ............................................... 8 58 4.1. Serialization ............................................. 8 59 4.2. Well-known Values ......................................... 8 60 5. SNMP over DDP ............................................... 8 61 5.1. Serialization ............................................. 8 62 5.2. Well-known Values ......................................... 9 63 5.3. Discussion of AppleTalk Addressing ........................ 9 64 5.3.1. How to Acquire NBP names ................................ 10 65 5.3.2. When to Turn NBP names into DDP addresses ............... 10 66 5.3.3. How to Turn NBP names into DDP addresses ................ 11 67 5.3.4. What if NBP is broken ................................... 11 68 6. SNMP over IPX ............................................... 12 69 6.1. Serialization ............................................. 12 70 6.2. Well-known Values ......................................... 12 71 7. Proxy to SNMPv1 ............................................. 12 72 8. Serialization using the Basic Encoding Rules ................ 12 73 8.1. Usage Example ............................................. 13 74 9. Notice on Intellectual Property ............................. 14 75 10. Acknowledgments ............................................ 14 76 11. Security Considerations .................................... 15 77 12. References ................................................. 16 78 13. Editor's Address ........................................... 18 79 14. Changes from RFC 1906 ...................................... 18 80 15. Issues ..................................................... 19 81 16. Full Copyright Statement ................................... 20 83 1. Introduction 85 The SNMP Management Framework at the time of this writing consists of 86 five major components: 88 - An overall architecture, described in RFC 2571 [RFC2571]. 90 - Mechanisms for describing and naming objects and events for 91 the purpose of management. The first version of this 92 Structure of Management Information (SMI) is called SMIv1 93 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 94 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, 95 called SMIv2, is described in STD 58, RFC 2578 [RFC2578], 96 STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 98 - Message protocols for transferring management information. 99 The first version of the SNMP message protocol is called 100 SNMPv1 and is described in STD 15, RFC 1157 [RFC1157]. A 101 second version of the SNMP message protocol, which is not 102 an Internet standards track protocol, is called SNMPv2c and 103 is described in RFC 1901 [RFC1901] and this document. The 104 third version of the message protocol is called SNMPv3 and 105 described in this document, RFC 2572 [RFC2572] and RFC 2574 106 [RFC2574]. 108 - Protocol operations for accessing management information. 109 The first set of protocol operations and associated PDU 110 formats is described in STD 15, RFC 1157 [RFC1157]. A 111 second set of protocol operations and associated PDU 112 formats is described RFC -PROTO [RFC-PROTO]. 114 - A set of fundamental applications described in RFC 2573 115 [RFC2573] and the view-based access control mechanism 116 described in RFC 2575 [RFC2575]. 118 A more detailed introduction to the SNMP Management Framework at 119 the time of this writing can be found in RFC 2570 [RFC2570]. 121 Managed objects are accessed via a virtual information store, 122 termed the Management Information Base or MIB. Objects in the 123 MIB are defined using the mechanisms defined in the SMI. 125 This document, Transport Mappings for the Simple Network 126 Management Protocol, defines how the management protocol [RFC- 127 PROTO] may be carried over a variety of protocol suites. It is 128 the purpose of this document to define how the SNMP maps onto an 129 initial set of transport domains. Other mappings may be defined 130 in the future. 132 Although several mappings are defined, the mapping onto UDP is 133 the preferred mapping. As such, to provide for the greatest 134 level of interoperability, systems which choose to deploy other 135 mappings should also provide for proxy service to the UDP 136 mapping. 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 "200001100422Z" 151 ORGANIZATION "IETF SNMPv3 Working Group" 152 CONTACT-INFO 153 "WG-EMail: snmpv3@tis.com 154 Subscribe: majordomo@tis.com 155 In message body: subscribe snmpv3 157 Chair: Russ Mundy 158 TIS Labs at Network Associates 159 postal: 3060 Washington Rd 160 Glenwood MD 21738 161 USA 162 EMail: mundy@tislabs.com 163 phone: +1 301 854-6889 165 Editor: Randy Presuhn 166 BMC Software, Inc. 167 postal: 2141 North First Street 168 San Jose, CA 95131 169 USA 170 EMail: randy_presuhn@bmc.com 171 phone: +1 408 546-1006" 172 DESCRIPTION 173 "The MIB module for SNMP transport mappings." 174 REVISION "200001100422Z" 175 DESCRIPTION 176 "Clarifications, published as RFC 0." 177 REVISION "199601010000Z" 178 DESCRIPTION 179 "Clarifications, published as RFC 1906." 181 REVISION "199304010000Z" 182 DESCRIPTION 183 "The initial version, published as RFC 1449." 184 ::= { snmpModules ?? } -- to be assigned by IANA?? 186 -- SNMP over UDP over IPv4 188 snmpUDPDomain OBJECT-IDENTITY 189 STATUS current 190 DESCRIPTION 191 "The SNMP over UDP transport domain. The corresponding 192 transport address is of type SnmpUDPAddress." 193 ::= { snmpDomains 1 } 195 SnmpUDPAddress ::= TEXTUAL-CONVENTION 196 DISPLAY-HINT "1d.1d.1d.1d/2d" 197 STATUS current 198 DESCRIPTION 199 "Represents a UDP address: 201 octets contents encoding 202 1-4 IP-address network-byte order 203 5-6 UDP-port network-byte order 204 " 205 SYNTAX OCTET STRING (SIZE (6)) 207 -- SNMP over OSI 209 snmpCLNSDomain OBJECT-IDENTITY 210 STATUS current 211 DESCRIPTION 212 "The SNMP over CLNS transport domain. 213 The corresponding transport address is of type 214 SnmpOSIAddress." 215 ::= { snmpDomains 2 } 217 snmpCONSDomain OBJECT-IDENTITY 218 STATUS current 219 DESCRIPTION 220 "The SNMP over CONS transport domain. 221 The corresponding transport address is of type 222 SnmpOSIAddress." 223 ::= { snmpDomains 3 } 225 SnmpOSIAddress ::= TEXTUAL-CONVENTION 226 DISPLAY-HINT "*1x:/1x:" 227 STATUS current 228 DESCRIPTION 229 "Represents an OSI transport-address: 231 octets contents encoding 232 1 length of NSAP 'n' as an unsigned-integer 233 (either 0 or from 3 to 20) 234 2..(n+1) NSAP concrete binary representation 235 (n+2)..m TSEL string of (up to 64) octets 236 " 237 SYNTAX OCTET STRING (SIZE (1 | 4..85)) 239 -- SNMP over DDP 241 snmpDDPDomain OBJECT-IDENTITY 242 STATUS current 243 DESCRIPTION 244 "The SNMP over DDP transport domain. The corresponding 245 transport address is of type SnmpNBPAddress." 246 ::= { snmpDomains 4 } 248 SnmpNBPAddress ::= TEXTUAL-CONVENTION 249 STATUS current 250 DESCRIPTION 251 "Represents an NBP name: 253 octets contents encoding 254 1 length of object 'n' as an unsigned integer 255 2..(n+1) object string of (up to 32) octets 256 n+2 length of type 'p' as an unsigned integer 257 (n+3)..(n+2+p) type string of (up to 32) octets 258 n+3+p length of zone 'q' as an unsigned integer 259 (n+4+p)..(n+3+p+q) zone string of (up to 32) octets 261 For comparison purposes, strings are 262 case-insensitive. All strings may contain any octet 263 other than 255 (hex ff)." 264 SYNTAX OCTET STRING (SIZE (3..99)) 266 -- SNMP over IPX 268 snmpIPXDomain OBJECT-IDENTITY 269 STATUS current 270 DESCRIPTION 271 "The SNMP over IPX transport domain. The corresponding 272 transport address is of type SnmpIPXAddress." 273 ::= { snmpDomains 5 } 275 SnmpIPXAddress ::= TEXTUAL-CONVENTION 276 DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" 277 STATUS current 278 DESCRIPTION 279 "Represents an IPX address: 281 octets contents encoding 282 1-4 network-number network-byte order 283 5-10 physical-address network-byte order 284 11-12 socket-number network-byte order 285 " 286 SYNTAX OCTET STRING (SIZE (12)) 288 -- for proxy to SNMPv1 (RFC 1157) 290 rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } 292 rfc1157Domain OBJECT-IDENTITY 293 STATUS current 294 DESCRIPTION 295 "The transport domain for SNMPv1 over UDP. 296 The corresponding transport address is of type 297 SnmpUDPAddress." 298 ::= { rfc1157Proxy 1 } 300 -- ::= { rfc1157Proxy 2 } this OID is obsolete 302 END 304 3. SNMP over UDP 306 This is the preferred transport mapping. 308 3.1. Serialization 310 Each instance of a message is serialized (i.e., encoded according to 311 the convention of [ASN1]) onto a single UDP [RFC768] 312 datagram, using the algorithm specified in Section 8. 314 3.2. Well-known Values 316 It is suggested that administrators configure their SNMP entities 317 supporting command responder applications to listen on UDP port 161. 318 Further, it is suggested that SNMP entities supporting notification 319 receiver applications be configured to listen on UDP port 162. 321 When an SNMP entity uses this transport mapping, it must be capable 322 of accepting messages up to and including 484 octets in size. It is 323 recommended that implementations be capable of accepting messages of 324 up to 1472 octets in size. Implementation of larger values is 325 encouraged whenever possible. 327 4. SNMP over OSI 329 This is an optional transport mapping. 331 4.1. Serialization 333 Each instance of a message is serialized onto a single TSDU [IS8072] 334 [IS8072A] for the OSI Connectionless-mode Transport Service (CLTS), 335 using the algorithm specified in Section 8. 337 4.2. Well-known Values 339 It is suggested that administrators configure their SNMP entities 340 supporting command responder applications to listen on transport 341 selector "snmp-l" (which consists of six ASCII characters), when 342 using a CL-mode network service to realize the CLTS. Further, it is 343 suggested that SNMP entities supporting notification receiver 344 applications be configured to listen on transport selector "snmpt-l" 345 (which consists of seven ASCII characters, six letters and a hyphen) 346 when using a CL-mode network service to realize the CLTS. Similarly, 347 when using a CO-mode network service to realize the CLTS, the 348 suggested transport selectors are "snmp-o" and "snmpt-o", for command 349 responders and notification receivers, respectively. 351 When an SNMP entity uses this transport mapping, it must be capable 352 of accepting messages that are at least 484 octets in size. 353 Implementation of larger values is encouraged whenever possible. 355 5. SNMP over DDP 357 This is an optional transport mapping. 359 5.1. Serialization 361 Each instance of a message is serialized onto a single DDP datagram 362 [APPLETALK], using the algorithm specified in Section 8. 364 5.2. Well-known Values 366 SNMP messages are sent using DDP protocol type 8. SNMP entities 367 supporting command responder applications listen on DDP socket number 368 8, while SNMP entities supporting notification receiver applications 369 listen on DDP socket number 9. 371 Administrators must configure their SNMP entities supporting command 372 responder applications to use NBP type "SNMP Agent" (which consists 373 of ten ASCII while those supporting notification receiver 374 applications must be configured to use NBP type "SNMP Trap Handler" 375 (which consists of seventeen ASCII characters). 377 The NBP name for SNMP entities supporting command responders and 378 notification receivers should be stable - NBP names should not change 379 any more often than the IP address of a typical TCP/IP node. It is 380 suggested that the NBP name be stored in some form of stable storage. 382 When an SNMP entity uses this transport mapping, it must be capable 383 of accepting messages that are at least 484 octets in size. 384 Implementation of larger values is encouraged whenever possible. 386 5.3. Discussion of AppleTalk Addressing 388 The AppleTalk protocol suite has certain features not manifest in the 389 TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of 390 address assignment can cause problems for SNMP entities that wish to 391 manage AppleTalk networks. TCP/IP nodes have an associated IP 392 address which distinguishes each from the other. In contrast, 393 AppleTalk nodes generally have no such characteristic. The network- 394 level address, while often relatively stable, can change at every 395 reboot (or more frequently). 397 Thus, when SNMP is mapped over DDP, nodes are identified by a "name", 398 rather than by an "address". Hence, all AppleTalk nodes that 399 implement this mapping are required to respond to NBP lookups and 400 confirms (e.g., implement the NBP protocol stub), which guarantees 401 that a mapping from NBP name to DDP address will be possible. 403 In determining the SNMP identity to register for an SNMP entity, it 404 is suggested that the SNMP identity be a name which is associated 405 with other network services offered by the machine. 407 NBP lookups, which are used to map NBP names into DDP addresses, can 408 cause large amounts of network traffic as well as consume CPU 409 resources. It is also the case that the ability to perform an NBP 410 lookup is sensitive to certain network disruptions (such as zone 411 table inconsistencies) which would not prevent direct AppleTalk 412 communications between two SNMP entities. 414 Thus, it is recommended that NBP lookups be used infrequently, 415 primarily to create a cache of name-to-address mappings. These 416 cached mappings should then be used for any further SNMP traffic. It 417 is recommended that SNMP entities supporting command generator 418 applications should maintain this cache between reboots. This 419 caching can help minimize network traffic, reduce CPU load on the 420 network, and allow for (some amount of) network trouble shooting when 421 the basic name-to-address translation mechanism is broken. 423 5.3.1. How to Acquire NBP names 425 An SNMP entity supporting command generator applications may have a 426 pre-configured list of names of "known" SNMP entities supporting 427 command responder applications. Similarly, an SNMP entity supporting 428 command generator or notification receiver applications might 429 interact with an operator. Finally, an SNMP entity supporting 430 command generator or notification receiver applications might 431 communicate with all SNMP entities supporting command responder or 432 notification originator applications in a set of zones or networks. 434 5.3.2. When to Turn NBP names into DDP addresses 436 When an SNMP entity uses a cache entry to address an SNMP packet, it 437 should attempt to confirm the validity mapping, if the mapping hasn't 438 been confirmed within the last T1 seconds. This cache entry 439 lifetime, T1, has a minimum, default value of 60 seconds, and should 440 be configurable. 442 An SNMP entity supporting a command generator application may decide 443 to prime its cache of names prior to actually communicating with 444 another SNMP entity. In general, it is expected that such an entity 445 may want to keep certain mappings "more current" than other mappings, 446 e.g., those nodes which represent the network infrastructure (e.g., 447 routers) may be deemed "more important". 449 Note that an SNMP entity supporting command generator applications 450 should not prime its entire cache upon initialization - rather, it 451 should attempt resolutions over an extended period of time (perhaps 452 in some pre- determined or configured priority order). Each of these 453 resolutions might, in fact, be a wildcard lookup in a given zone. 455 An SNMP entity supporting command responder applications must never 456 prime its cache. When generating a response, such an entity does not 457 need to confirm a cache entry. An SNMP entity supporting 458 notification originator applications should do NBP lookups (or 459 confirms) only when it needs to send an SNMP trap or inform. 461 5.3.3. How to Turn NBP names into DDP addresses 463 If the only piece of information available is the NBP name, then an 464 NBP lookup should be performed to turn that name into a DDP address. 465 However, if there is a piece of stale information, it can be used as 466 a hint to perform an NBP confirm (which sends a unicast to the 467 network address which is presumed to be the target of the name 468 lookup) to see if the stale information is, in fact, still valid. 470 An NBP name to DDP address mapping can also be confirmed implicitly 471 using only SNMP transactions. For example, an SNMP entity acting 472 supporting command generator applications issuing a retrieval 473 operation could also retrieve the relevant objects from the NBP group 474 [RFC1742] for the SNMP entity supporting the command responder 475 application. This information can then be correlated with the source 476 DDP address of the response. 478 5.3.4. What if NBP is broken 480 Under some circumstances, there may be connectivity between two SNMP 481 entities, but the NBP mapping machinery may be broken, e.g., 483 o the NBP FwdReq (forward NBP lookup onto local attached network) 484 mechanism might be broken at a router on the other entity's 485 network; or, 487 o the NBP BrRq (NBP broadcast request) mechanism might be broken 488 at a router on the entity's own network; or, 490 o NBP might be broken on the other entity's node. 492 An SNMP entity supporting command generator applications which is 493 dedicated to AppleTalk management might choose to alleviate some of 494 these failures by directly implementing the router portion of NBP. 495 For example, such an entity might already know all the zones on the 496 AppleTalk internet and the networks on which each zone appears. 497 Given an NBP lookup which fails, the entity could send an NBP FwdReq 498 to the network in which the SNMP entity supporting the command 499 responder or notification originator application was last located. 500 If that failed, the station could then send an NBP LkUp (NBP lookup 501 packet) as a directed (DDP) multicast to each network number on that 502 network. Of the above (single) failures, this combined approach will 503 solve the case where either the local router's BrRq-to-FwdReq 504 mechanism is broken or the remote router's FwdReq-to-LkUp mechanism 505 is broken. 507 6. SNMP over IPX 509 This is an optional transport mapping. 511 6.1. Serialization 513 Each instance of a message is serialized onto a single IPX datagram 514 [NOVELL], using the algorithm specified in Section 8. 516 6.2. Well-known Values 518 SNMP messages are sent using IPX packet type 4 (i.e., Packet Exchange 519 Protocol). 521 It is suggested that administrators configure their SNMP entities 522 supporting command responder applications to listen on IPX socket 523 36879 (900f hexadecimal). Further, it is suggested that those 524 supporting notification receiver applications be configured to listen 525 on IPX socket 36880 (9010 hexadecimal). 527 When an SNMP entity uses this transport mapping, it must be capable 528 of accepting messages that are at least 546 octets in size. 529 Implementation of larger values is encouraged whenever possible. 531 7. Proxy to SNMPv1 533 Historically, in order to support proxy to SNMPv1, as defined in 534 [RFC-COEX], it was deemed useful to define a transport domain, 535 rfc1157Domain, which indicates the transport mapping for SNMP 536 messages as defined in [RFC1157]. Subsequently, this transport 537 domain has proven useful in non-proxy situations. 539 8. Serialization using the Basic Encoding Rules 541 When the Basic Encoding Rules [BER] are used for serialization: 543 (1) When encoding the length field, only the definite form is used; 544 use of the indefinite form encoding is prohibited. Note that 545 when using the definite-long form, it is permissible to use more 546 than the minimum number of length octets necessary to encode the 547 length field. 549 (2) When encoding the value field, the primitive form shall be used 550 for all simple types, i.e., INTEGER, OCTET STRING, and OBJECT 551 IDENTIFIER (either IMPLICIT or explicit). The constructed form 552 of encoding shall be used only for structured types, i.e., a 553 SEQUENCE or an IMPLICIT SEQUENCE. 555 (3) When encoding an object whose syntax is described using the BITS 556 construct, the value is encoded as an OCTET STRING, in which all 557 the named bits in (the definition of) the bitstring, commencing 558 with the first bit and proceeding to the last bit, are placed in 559 bits 8 to 1 of the first octet, followed by bits 8 to 1 of each 560 subsequent octet in turn, followed by as many bits as are needed 561 of the final subsequent octet, commencing with bit 8. Remaining 562 bits, if any, of the final octet are set to zero on generation 563 and ignored on receipt. 565 These restrictions apply to all aspects of ASN.1 encoding, including 566 the message wrappers, protocol data units, and the data objects they 567 contain. 569 8.1. Usage Example 571 As an example of applying the Basic Encoding Rules, suppose one 572 wanted to encode an instance of the GetBulkRequest-PDU [RFC-PROTO]: 574 [5] IMPLICIT SEQUENCE { 575 request-id 1414684022, 576 non-repeaters 1, 577 max-repetitions 2, 578 variable-bindings { 579 { name sysUpTime, 580 value { unspecified NULL } }, 581 { name ipNetToMediaPhysAddress, 582 value { unspecified NULL } }, 583 { name ipNetToMediaType, 584 value { unspecified NULL } } 585 } 586 } 588 Applying the BER, this would be encoded (in hexadecimal) as: 590 [5] IMPLICIT SEQUENCE a5 82 00 39 591 INTEGER 02 04 52 54 5d 76 592 INTEGER 02 01 01 593 INTEGER 02 01 02 594 SEQUENCE (OF) 30 2b 595 SEQUENCE 30 0b 596 OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03 597 NULL 05 00 598 SEQUENCE 30 0d 599 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02 600 NULL 05 00 601 SEQUENCE 30 0d 602 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 603 NULL 05 00 605 Note that the initial SEQUENCE is not encoded using the minimum 606 number of length octets. (The first octet of the length, 82, 607 indicates that the length of the content is encoded in the next two 608 octets.) 610 9. Notice on Intellectual Property 612 The IETF takes no position regarding the validity or scope of any 613 intellectual property or other rights that might be claimed to 614 pertain to the implementation or use of the technology described in 615 this document or the extent to which any license under such rights 616 might or might not be available; neither does it represent that it 617 has made any effort to identify any such rights. Information on the 618 IETF's procedures with respect to rights in standards-track and 619 standards-related documentation can be found in BCP-11. Copies of 620 claims of rights made available for publication and any assurances of 621 licenses to be made available, or the result of an attempt made to 622 obtain a general license or permission for the use of such 623 proprietary rights by implementors or users of this specification can 624 be obtained from the IETF Secretariat. 626 The IETF invites any interested party to bring to its attention any 627 copyrights, patents or patent applications, or other proprietary 628 rights which may cover technology that may be required to practice 629 this standard. Please address the information to the IETF Executive 630 Director. 632 10. Acknowledgments 634 The previous versions of this document, edited by Keith McCloghrie, 635 was the result of significant work by four major contributors: 637 Jeffrey D. Case (SNMP Research, case@snmp.com) 638 Keith McCloghrie (Cisco Systems, kzm@cisco.com) 639 Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) 640 Steven Waldbusser (International Network Services, stevew@uni.ins.com) 642 In addition, the contributions of the SNMPv2 Working Group are 643 acknowledged. In particular, a special thanks is extended for the 644 contributions of: 646 Alexander I. Alten (Novell) 647 Dave Arneson (Cabletron) 648 Uri Blumenthal (IBM) 649 Doug Book (Chipcom) 650 Kim Curran (Bell-Northern Research) 651 Jim Galvin (Trusted Information Systems) 652 Maria Greene (Ascom Timeplex) 653 Iain Hanson (Digital) 654 Dave Harrington (Cabletron) 655 Nguyen Hien (IBM) 656 Jeff Johnson (Cisco Systems) 657 Michael Kornegay (Object Quest) 658 Deirdre Kostick (AT&T Bell Labs) 659 David Levi (SNMP Research) 660 Daniel Mahoney (Cabletron) 661 Russ Mundy (TIS Labs at Network Associates, Chair) 662 Bob Natale (ACE*COMM) 663 Brian O'Keefe (Hewlett Packard) 664 Andrew Pearson (SNMP Research) 665 Dave Perkins (Peer Networks) 666 Aleksey Romanov (Quality Quorum) 667 Shawn Routhier (Epilogue) 668 Jon Saperia (BGS Systems) 669 Juergen Schoenwaelder (TU Braunschweig) 670 Bob Stewart (Cisco Systems) 671 Kaj Tesink (Bellcore) 672 Glenn Waters (Bell-Northern Research) 673 Bert Wijnen (IBM) 675 11. Security Considerations 677 SNMPv1 by itself is not a secure environment. Even if the network 678 itself is secure (for example by using IPSec), even then, there is no 679 control as to who on the secure network is allowed to access and 680 GET/SET (read/change) the objects accessible through a command 681 responder application. 683 It is recommended that the implementors consider the security 684 features as provided by the SNMPv3 framework. Specifically, the use 685 of the User-based Security Model RFC 2574 [RFC2574] and the 686 View-based Access Control Model RFC 2575 [RFC2575] is recommended. 688 It is then a customer/user responsibility to ensure that the SNMP 689 entity giving access to a MIB is properly configured to give access 690 to the objects only to those principals (users) that have legitimate 691 rights to indeed GET or SET (change) them. 693 12. References 695 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 696 USC/Information Sciences Institute, August 1980. 698 [IS8072] Information processing systems - Open Systems 699 Interconnection - Transport Service Definition, 700 International Organization for Standardization. 701 International Standard 8072, June 1986. 703 [IS8072A] Information processing systems - Open Systems 704 Interconnection - Transport Service Definition - Addendum 705 1: Connectionless-mode Transmission, International 706 Organization for Standardization. International Standard 707 8072/AD 1, December 1986. 709 [APPLETALK] Sidhu, G., Andrews, R., and A. Oppenheimer, Inside 710 AppleTalk (second edition). Addison-Wesley, 1990. 712 [RFC1742] Waldbusser, S. and K. Frisa, "AppleTalk Management 713 Information Base II", RFC 1742, January 1995. 715 [NOVELL] Network System Technical Interface Overview. Novell, 716 Inc, June 1989. 718 [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 719 "Coexistence between Version 1, Version 2, and Version 3 720 of the Internet-standard Network Management Framework", 721 , December 1999. 723 [BER] Information processing systems - Open Systems 724 Interconnection - Specification of Basic Encoding Rules 725 for Abstract Syntax Notation One (ASN.1), International 726 Organization for Standardization. International Standard 727 8825, December 1987. 729 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An 730 Architecture for Describing SNMP Management Frameworks", 731 RFC 2571, April 1999. 733 [RFC1155] Rose, M., and K. McCloghrie, "Structure and 734 Identification of Management Information for TCP/IP-based 735 Internets", STD 16, RFC 1155, May 1990. 737 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 738 STD 16, RFC 1212, March 1991. 740 [RFC1215] Rose, M., "A Convention for Defining Traps for use with 741 the SNMP", RFC 1215, March 1991. 743 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 744 Rose, M., and S. Waldbusser, "Structure of Management 745 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 746 1999. 748 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 749 Rose, M., and S. Waldbusser, "Textual Conventions for 750 SMIv2", STD 58, RFC 2579, April 1999. 752 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 753 Rose, M., and S. Waldbusser, "Conformance Statements for 754 SMIv2", STD 58, RFC 2580, April 1999. 756 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 757 "Simple Network Management Protocol", STD 15, RFC 1157, 758 May 1990. 760 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 761 "Introduction to Community-based SNMPv2", RFC 1901, 762 January 1996. 764 [RFC-TM] Presuhn, R., SNMPv2 Working Group, Case, J., McCloghrie, 765 K., Rose, M., and S. Waldbusser, "Transport Mappings for 766 the Simple Network Management Protocol", 767 , January 2000. 769 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, 770 "Message Processing and Dispatching for the Simple 771 Network Management Protocol (SNMP)", RFC 2572, April 772 1999. 774 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 775 (USM) for version 3 of the Simple Network Management 776 Protocol (SNMPv3)", RFC 2574, April 1999. 778 [RFC-PROTO] Presuhn, R., SNMPv2 Working Group, Case, J., McCloghrie, 779 K., Rose, M., and S. Waldbusser, "Protocol Operations for 780 the Simple Network Management Protocol", 781 , January 2000. 783 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 784 Applications", RFC 2573, April 1999. 786 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 787 Access Control Model (VACM) for the Simple Network 788 Management Protocol (SNMP)", RFC 2575, April 1999. 790 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 791 "Introduction to Version 3 of the Internet-standard 792 Network Management Framework", RFC 2570, April 1999. 794 [RFC2233] McCloghrie, K., and F. Kastenholz, "The Interfaces Group 795 MIB using SMIv2", RFC 2233, November 1997. 797 13. Editor's Address 799 Randy Presuhn 800 BMC Software, Inc. 801 2141 North First Street 802 San Jose, CA 95131 803 USA 805 Phone: +1 408 546-1006 806 EMail: randy_presuhn@bmc.com 808 14. Changes from RFC 1906 810 These are the changes from RFC 1906: 812 - Corrected typo in IPR statement; 814 - Updated copyright date; 816 - Updated with new editor's name and contact information; 818 - Cosmetic fixes to layout and typography; 820 - Changed title, headers and footers; 821 - Fixed typo in SnmpNBPAddress; 823 - Clarified that one of the BER SEQUENCEs in the example is 824 generated from the ASN.1 SEQUENCE OF construct; 826 - Updated acknowledgements section; 828 - Filled in the Security Considerations section; 830 - Replaced manager/agent terminology with terms from 831 architecture; 833 - Updated references section; 835 - Added MODULE-IDENTITY; 837 - Re-wrote introduction section using current boilerplate; 839 - Added recommendation for larger message size support; 841 - Added historical background on use of rfc1157Domain with 842 proxy; 844 15. Issues 846 This section is to be deleted when it is time to publish this 847 document as an RFC. The issue labels are the same as those used in 848 the on-line issues list at 849 ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1906/index.html 851 1906-01 Done; title changed. 853 1906-02 Done; introduction clause replaced. 855 1906-03 857 1906-04 Done; resolution required no changes. 859 1906-05 Done; typo in SnmpNBPAddress fixed. 861 1906-06 863 1906-07 Done; use of manager/agent terminology replaced with 864 terms from architecture. 866 1906-08 Done; added recommendation for support of 1472 byte 867 messages. 869 1906-09 Done; resolution required no changes. 871 1906-10 Done; added historical background to material on proxy. 872 Note that some are unhappy with this text; a better 873 replacement would be most welcome. 875 1906-11 Done; resolution required no changes. 877 1906-12 Done; resolution required no changes. 879 1906-13 Done; resolution required no changes. 881 1906-14 Done; clarified that BER SEQUENCE comes from ASN.1 882 SEQUENCE OF. 884 1906-15 Done; security considerations text added. 886 1906-16 PARTIAL; references updated, acknowledgments need work. 888 1906-17 Done; IPR and copyright notices updated. 890 1906-18 Done; resolution required no changes. 892 1906-19 Done; MODULE-IDENTITY added. 894 16. Full Copyright Statement 896 Copyright (C) The Internet Society (2000). All Rights Reserved. 898 This document and translations of it may be copied and furnished to 899 others, and derivative works that comment on or otherwise explain it 900 or assist in its implementation may be prepared, copied, published 901 and distributed, in whole or in part, without restriction of any 902 kind, provided that the above copyright notice and this paragraph are 903 included on all such copies and derivative works. However, this 904 document itself may not be modified in any way, such as by removing 905 the copyright notice or references to the Internet Society or other 906 Internet organizations, except as needed for the purpose of 907 developing Internet standards in which case the procedures for 908 copyrights defined in the Internet Standards process must be 909 followed, or as required to translate it into languages other than 910 English. 912 The limited permissions granted above are perpetual and will not be 913 revoked by the Internet Society or its successors or assigns. 915 This document and the information contained herein is provided on an 916 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 917 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 918 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 919 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 920 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.