idnits 2.17.1 draft-ietf-snmpv3-update-transmap-04.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 198 has weird spacing: '... octets cont...' == Line 228 has weird spacing: '... octets cont...' == Line 278 has weird spacing: '... octets cont...' == Line 280 has weird spacing: '...address net...' == Line 656 has weird spacing: '... The previo...' -- 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 (14 July 2000) is 8686 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 308, but not defined -- Looks like a reference, but probably isn't: '5' on line 587 == Unused Reference: 'RFC-TM' is defined on line 809, 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) ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2576 (Obsoleted by RFC 3584) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-TM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-PROTO' Summary: 15 errors (**), 0 flaws (~~), 8 warnings (==), 10 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: -TM 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 14 July 2000 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 (2000). 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 ..................................... 7 52 3.1. Serialization ............................................. 7 53 3.2. Well-known Values ......................................... 8 54 4. SNMP over OSI ............................................... 8 55 4.1. Serialization ............................................. 8 56 4.2. Well-known Values ......................................... 8 57 5. SNMP over DDP ............................................... 8 58 5.1. Serialization ............................................. 8 59 5.2. Well-known Values ......................................... 9 60 5.3. Discussion of AppleTalk Addressing ........................ 9 61 5.3.1. How to Acquire NBP names ................................ 10 62 5.3.2. When to Turn NBP names into DDP addresses ............... 10 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 ............................................. 12 69 8. Serialization using the Basic Encoding Rules ................ 12 70 8.1. Usage Example ............................................. 13 71 9. Notice on Intellectual Property ............................. 14 72 10. Acknowledgments ............................................ 14 73 11. Security Considerations .................................... 16 74 12. References ................................................. 16 75 13. Editor's Address ........................................... 18 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 2571 [RFC2571]. 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 2572 [RFC2572] and RFC 2574 103 [RFC2574]. 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 -PROTO [RFC-PROTO]. 111 - A set of fundamental applications described in RFC 2573 112 [RFC2573] and the view-based access control mechanism 113 described in RFC 2575 [RFC2575]. 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-PROTO] 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. As such, to provide for the greatest level 130 of interoperability, systems which choose to deploy other mappings 131 should also provide for access via UDP over IPv4 mapping. 133 2. Definitions 135 SNMPv2-TM DEFINITIONS ::= BEGIN 137 IMPORTS 138 MODULE-IDENTITY, OBJECT-IDENTITY, 139 snmpModules, snmpDomains, snmpProxys 140 FROM SNMPv2-SMI 141 TEXTUAL-CONVENTION 142 FROM SNMPv2-TC; 144 snmpv2tm MODULE-IDENTITY 145 LAST-UPDATED "200007141725Z" 146 ORGANIZATION "IETF SNMPv3 Working Group" 147 CONTACT-INFO 148 "WG-EMail: snmpv3@tis.com 149 Subscribe: majordomo@tis.com 150 In message body: subscribe snmpv3 152 Chair: Russ Mundy 153 TIS Labs at Network Associates 154 postal: 3060 Washington Rd 155 Glenwood MD 21738 156 USA 157 EMail: mundy@tislabs.com 158 phone: +1 301 854-6889 160 Editor: Randy Presuhn 161 BMC Software, Inc. 162 postal: 2141 North First Street 163 San Jose, CA 95131 164 USA 165 EMail: randy_presuhn@bmc.com 166 phone: +1 408 546-1006" 167 DESCRIPTION 168 "The MIB module for SNMP transport mappings." 169 REVISION "200007141725Z" 170 DESCRIPTION 171 "Clarifications, published as 172 " 173 REVISION "199601010000Z" 174 DESCRIPTION 175 "Clarifications, published as RFC 1906." 177 REVISION "199304010000Z" 178 DESCRIPTION 179 "The initial version, published as RFC 1449." 180 ::= { snmpModules ?? } -- to be assigned by IANA?? 182 -- SNMP over UDP over IPv4 184 snmpUDPDomain OBJECT-IDENTITY 185 STATUS current 186 DESCRIPTION 187 "The SNMP over UDP over IPv4 transport domain. 188 The corresponding transport address is of type 189 SnmpUDPAddress." 190 ::= { snmpDomains 1 } 192 SnmpUDPAddress ::= TEXTUAL-CONVENTION 193 DISPLAY-HINT "1d.1d.1d.1d/2d" 194 STATUS current 195 DESCRIPTION 196 "Represents a UDP over IPv4 address: 198 octets contents encoding 199 1-4 IP-address network-byte order 200 5-6 UDP-port network-byte order 201 " 202 SYNTAX OCTET STRING (SIZE (6)) 204 -- SNMP over OSI 206 snmpCLNSDomain OBJECT-IDENTITY 207 STATUS current 208 DESCRIPTION 209 "The SNMP over CLNS transport domain. 210 The corresponding transport address is of type 211 SnmpOSIAddress." 212 ::= { snmpDomains 2 } 214 snmpCONSDomain OBJECT-IDENTITY 215 STATUS current 216 DESCRIPTION 217 "The SNMP over CONS transport domain. 218 The corresponding transport address is of type 219 SnmpOSIAddress." 220 ::= { snmpDomains 3 } 222 SnmpOSIAddress ::= TEXTUAL-CONVENTION 223 DISPLAY-HINT "*1x:/1x:" 224 STATUS current 225 DESCRIPTION 226 "Represents an OSI transport-address: 228 octets contents encoding 229 1 length of NSAP 'n' as an unsigned-integer 230 (either 0 or from 3 to 20) 231 2..(n+1) NSAP concrete binary representation 232 (n+2)..m TSEL string of (up to 64) octets 233 " 234 SYNTAX OCTET STRING (SIZE (1 | 4..85)) 236 -- SNMP over DDP 238 snmpDDPDomain OBJECT-IDENTITY 239 STATUS current 240 DESCRIPTION 241 "The SNMP over DDP transport domain. The corresponding 242 transport address is of type SnmpNBPAddress." 243 ::= { snmpDomains 4 } 245 SnmpNBPAddress ::= TEXTUAL-CONVENTION 246 STATUS current 247 DESCRIPTION 248 "Represents an NBP name: 250 octets contents encoding 251 1 length of object 'n' as an unsigned integer 252 2..(n+1) object string of (up to 32) octets 253 n+2 length of type 'p' as an unsigned integer 254 (n+3)..(n+2+p) type string of (up to 32) octets 255 n+3+p length of zone 'q' as an unsigned integer 256 (n+4+p)..(n+3+p+q) zone string of (up to 32) octets 258 For comparison purposes, strings are 259 case-insensitive. All strings may contain any octet 260 other than 255 (hex ff)." 261 SYNTAX OCTET STRING (SIZE (3..99)) 263 -- SNMP over IPX 265 snmpIPXDomain OBJECT-IDENTITY 266 STATUS current 267 DESCRIPTION 268 "The SNMP over IPX transport domain. The corresponding 269 transport address is of type SnmpIPXAddress." 270 ::= { snmpDomains 5 } 272 SnmpIPXAddress ::= TEXTUAL-CONVENTION 273 DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" 274 STATUS current 275 DESCRIPTION 276 "Represents an IPX address: 278 octets contents encoding 279 1-4 network-number network-byte order 280 5-10 physical-address network-byte order 281 11-12 socket-number network-byte order 282 " 283 SYNTAX OCTET STRING (SIZE (12)) 285 -- for proxy to SNMPv1 (RFC 1157) 287 rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } 289 rfc1157Domain OBJECT-IDENTITY 290 STATUS deprecated 291 DESCRIPTION 292 "The transport domain for SNMPv1 over UDP over IPv4. 293 The corresponding transport address is of type 294 SnmpUDPAddress." 295 ::= { rfc1157Proxy 1 } 297 -- ::= { rfc1157Proxy 2 } this OID is obsolete 299 END 301 3. SNMP over UDP over IPv4 303 This is the preferred transport mapping. 305 3.1. Serialization 307 Each instance of a message is serialized (i.e., encoded according to 308 the convention of [ASN1]) onto a single UDP [RFC768] over IPv4 309 [RFC791] datagram, using the algorithm specified in Section 8. 311 3.2. Well-known Values 313 It is suggested that administrators configure their SNMP entities 314 supporting command responder applications to listen on UDP port 161. 315 Further, it is suggested that SNMP entities supporting notification 316 receiver applications be configured to listen on UDP port 162. 318 When an SNMP entity uses this transport mapping, it must be capable 319 of accepting messages up to and including 484 octets in size. It is 320 recommended that implementations be capable of accepting messages of 321 up to 1472 octets in size. Implementation of larger values is 322 encouraged whenever possible. 324 4. SNMP over OSI 326 This is an optional transport mapping. 328 4.1. Serialization 330 Each instance of a message is serialized onto a single TSDU [IS8072] 331 [IS8072A] for the OSI Connectionless-mode Transport Service (CLTS), 332 using the algorithm specified in Section 8. 334 4.2. Well-known Values 336 It is suggested that administrators configure their SNMP entities 337 supporting command responder applications to listen on transport 338 selector "snmp-l" (which consists of six ASCII characters), when 339 using a CL-mode network service to realize the CLTS. Further, it is 340 suggested that SNMP entities supporting notification receiver 341 applications be configured to listen on transport selector "snmpt-l" 342 (which consists of seven ASCII characters, six letters and a hyphen) 343 when using a CL-mode network service to realize the CLTS. Similarly, 344 when using a CO-mode network service to realize the CLTS, the 345 suggested transport selectors are "snmp-o" and "snmpt-o", for command 346 responders and notification receivers, respectively. 348 When an SNMP entity uses this transport mapping, it must be capable 349 of accepting messages that are at least 484 octets in size. 350 Implementation of larger values is encouraged whenever possible. 352 5. SNMP over DDP 354 This is an optional transport mapping. 356 5.1. Serialization 358 Each instance of a message is serialized onto a single DDP datagram 359 [APPLETALK], using the algorithm specified in Section 8. 361 5.2. Well-known Values 363 SNMP messages are sent using DDP protocol type 8. SNMP entities 364 supporting command responder applications listen on DDP socket number 365 8, while SNMP entities supporting notification receiver applications 366 listen on DDP socket number 9. 368 Administrators must configure their SNMP entities supporting command 369 responder applications to use NBP type "SNMP Agent" (which consists 370 of ten ASCII while those supporting notification receiver 371 applications must be configured to use NBP type "SNMP Trap Handler" 372 (which consists of seventeen ASCII characters). 374 The NBP name for SNMP entities supporting command responders and 375 notification receivers should be stable - NBP names should not change 376 any more often than the IP address of a typical TCP/IP node. It is 377 suggested that the NBP name be stored in some form of stable storage. 379 When an SNMP entity uses this transport mapping, it must be capable 380 of accepting messages that are at least 484 octets in size. 381 Implementation of larger values is encouraged whenever possible. 383 5.3. Discussion of AppleTalk Addressing 385 The AppleTalk protocol suite has certain features not manifest in the 386 TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of 387 address assignment can cause problems for SNMP entities that wish to 388 manage AppleTalk networks. TCP/IP nodes have an associated IP 389 address which distinguishes each from the other. In contrast, 390 AppleTalk nodes generally have no such characteristic. The network- 391 level address, while often relatively stable, can change at every 392 reboot (or more frequently). 394 Thus, when SNMP is mapped over DDP, nodes are identified by a "name", 395 rather than by an "address". Hence, all AppleTalk nodes that 396 implement this mapping are required to respond to NBP lookups and 397 confirms (e.g., implement the NBP protocol stub), which guarantees 398 that a mapping from NBP name to DDP address will be possible. 400 In determining the SNMP identity to register for an SNMP entity, it 401 is suggested that the SNMP identity be a name which is associated 402 with other network services offered by the machine. 404 NBP lookups, which are used to map NBP names into DDP addresses, can 405 cause large amounts of network traffic as well as consume CPU 406 resources. It is also the case that the ability to perform an NBP 407 lookup is sensitive to certain network disruptions (such as zone 408 table inconsistencies) which would not prevent direct AppleTalk 409 communications between two SNMP entities. 411 Thus, it is recommended that NBP lookups be used infrequently, 412 primarily to create a cache of name-to-address mappings. These 413 cached mappings should then be used for any further SNMP traffic. It 414 is recommended that SNMP entities supporting command generator 415 applications should maintain this cache between reboots. This 416 caching can help minimize network traffic, reduce CPU load on the 417 network, and allow for (some amount of) network trouble shooting when 418 the basic name-to-address translation mechanism is broken. 420 5.3.1. How to Acquire NBP names 422 An SNMP entity supporting command generator applications may have a 423 pre-configured list of names of "known" SNMP entities supporting 424 command responder applications. Similarly, an SNMP entity supporting 425 command generator or notification receiver applications might 426 interact with an operator. Finally, an SNMP entity supporting 427 command generator or notification receiver applications might 428 communicate with all SNMP entities supporting command responder or 429 notification originator applications in a set of zones or networks. 431 5.3.2. When to Turn NBP names into DDP addresses 433 When an SNMP entity uses a cache entry to address an SNMP packet, it 434 should attempt to confirm the validity mapping, if the mapping hasn't 435 been confirmed within the last T1 seconds. This cache entry 436 lifetime, T1, has a minimum, default value of 60 seconds, and should 437 be configurable. 439 An SNMP entity supporting a command generator application may decide 440 to prime its cache of names prior to actually communicating with 441 another SNMP entity. In general, it is expected that such an entity 442 may want to keep certain mappings "more current" than other mappings, 443 e.g., those nodes which represent the network infrastructure (e.g., 444 routers) may be deemed "more important". 446 Note that an SNMP entity supporting command generator applications 447 should not prime its entire cache upon initialization - rather, it 448 should attempt resolutions over an extended period of time (perhaps 449 in some pre- determined or configured priority order). Each of these 450 resolutions might, in fact, be a wildcard lookup in a given zone. 452 An SNMP entity supporting command responder applications must never 453 prime its cache. When generating a response, such an entity does not 454 need to confirm a cache entry. An SNMP entity supporting 455 notification originator applications should do NBP lookups (or 456 confirms) only when it needs to send an SNMP trap or inform. 458 5.3.3. How to Turn NBP names into DDP addresses 460 If the only piece of information available is the NBP name, then an 461 NBP lookup should be performed to turn that name into a DDP address. 462 However, if there is a piece of stale information, it can be used as 463 a hint to perform an NBP confirm (which sends a unicast to the 464 network address which is presumed to be the target of the name 465 lookup) to see if the stale information is, in fact, still valid. 467 An NBP name to DDP address mapping can also be confirmed implicitly 468 using only SNMP transactions. For example, an SNMP entity supporting 469 command generator applications issuing a retrieval operation could 470 also retrieve the relevant objects from the NBP group [RFC1742] for 471 the SNMP entity supporting the command responder application. This 472 information can then be correlated with the source DDP address of the 473 response. 475 5.3.4. What if NBP is broken 477 Under some circumstances, there may be connectivity between two SNMP 478 entities, but the NBP mapping machinery may be broken, e.g., 480 o the NBP FwdReq (forward NBP lookup onto local attached network) 481 mechanism might be broken at a router on the other entity's 482 network; or, 484 o the NBP BrRq (NBP broadcast request) mechanism might be broken 485 at a router on the entity's own network; or, 487 o NBP might be broken on the other entity's node. 489 An SNMP entity supporting command generator applications which is 490 dedicated to AppleTalk management might choose to alleviate some of 491 these failures by directly implementing the router portion of NBP. 492 For example, such an entity might already know all the zones on the 493 AppleTalk internet and the networks on which each zone appears. 494 Given an NBP lookup which fails, the entity could send an NBP FwdReq 495 to the network in which the SNMP entity supporting the command 496 responder or notification originator application was last located. 497 If that failed, the station could then send an NBP LkUp (NBP lookup 498 packet) as a directed (DDP) multicast to each network number on that 499 network. Of the above (single) failures, this combined approach will 500 solve the case where either the local router's BrRq-to-FwdReq 501 mechanism is broken or the remote router's FwdReq-to-LkUp mechanism 502 is broken. 504 6. SNMP over IPX 506 This is an optional transport mapping. 508 6.1. Serialization 510 Each instance of a message is serialized onto a single IPX datagram 511 [NOVELL], using the algorithm specified in Section 8. 513 6.2. Well-known Values 515 SNMP messages are sent using IPX packet type 4 (i.e., Packet Exchange 516 Protocol). 518 It is suggested that administrators configure their SNMP entities 519 supporting command responder applications to listen on IPX socket 520 36879 (900f hexadecimal). Further, it is suggested that those 521 supporting notification receiver applications be configured to listen 522 on IPX socket 36880 (9010 hexadecimal). 524 When an SNMP entity uses this transport mapping, it must be capable 525 of accepting messages that are at least 546 octets in size. 526 Implementation of larger values is encouraged whenever possible. 528 7. Proxy to SNMPv1 530 Historically, in order to support proxy to SNMPv1, as defined in 531 [RFC2576], it was deemed useful to define a transport domain, 532 rfc1157Domain, which indicates the transport mapping for SNMP 533 messages as defined in [RFC1157]. 535 8. Serialization using the Basic Encoding Rules 537 When the Basic Encoding Rules [BER] are used for serialization: 539 (1) When encoding the length field, only the definite form is used; 540 use of the indefinite form encoding is prohibited. Note that 541 when using the definite-long form, it is permissible to use more 542 than the minimum number of length octets necessary to encode the 543 length field. 545 (2) When encoding the value field, the primitive form shall be used 546 for all simple types, i.e., INTEGER, OCTET STRING, and OBJECT 547 IDENTIFIER (either IMPLICIT or explicit). The constructed form 548 of encoding shall be used only for structured types, i.e., a 549 SEQUENCE or an IMPLICIT SEQUENCE. 551 (3) When encoding an object whose syntax is described using the BITS 552 construct, the value is encoded as an OCTET STRING, in which all 553 the named bits in (the definition of) the bitstring, commencing 554 with the first bit and proceeding to the last bit, are placed in 555 bits 8 (high order bit) to 1 (low order bit) of the first octet, 556 followed by bits 8 to 1 of each subsequent octet in turn, 557 followed by as many bits as are needed of the final subsequent 558 octet, commencing with bit 8. Remaining bits, if any, of the 559 final octet are set to zero on generation and ignored on 560 receipt. 562 These restrictions apply to all aspects of ASN.1 encoding, including 563 the message wrappers, protocol data units, and the data objects they 564 contain. 566 8.1. Usage Example 568 As an example of applying the Basic Encoding Rules, suppose one 569 wanted to encode an instance of the GetBulkRequest-PDU [RFC-PROTO]: 571 [5] IMPLICIT SEQUENCE { 572 request-id 1414684022, 573 non-repeaters 1, 574 max-repetitions 2, 575 variable-bindings { 576 { name sysUpTime, 577 value { unspecified NULL } }, 578 { name ipNetToMediaPhysAddress, 579 value { unspecified NULL } }, 580 { name ipNetToMediaType, 581 value { unspecified NULL } } 582 } 583 } 585 Applying the BER, this would be encoded (in hexadecimal) as: 587 [5] IMPLICIT SEQUENCE a5 82 00 39 588 INTEGER 02 04 52 54 5d 76 589 INTEGER 02 01 01 590 INTEGER 02 01 02 591 SEQUENCE (OF) 30 2b 592 SEQUENCE 30 0b 593 OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03 594 NULL 05 00 595 SEQUENCE 30 0d 596 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02 597 NULL 05 00 598 SEQUENCE 30 0d 599 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 600 NULL 05 00 602 Note that the initial SEQUENCE is not encoded using the minimum 603 number of length octets. (The first octet of the length, 82, 604 indicates that the length of the content is encoded in the next two 605 octets.) 607 9. Notice on Intellectual Property 609 The IETF takes no position regarding the validity or scope of any 610 intellectual property or other rights that might be claimed to 611 pertain to the implementation or use of the technology described in 612 this document or the extent to which any license under such rights 613 might or might not be available; neither does it represent that it 614 has made any effort to identify any such rights. Information on the 615 IETF's procedures with respect to rights in standards-track and 616 standards-related documentation can be found in BCP-11. Copies of 617 claims of rights made available for publication and any assurances of 618 licenses to be made available, or the result of an attempt made to 619 obtain a general license or permission for the use of such 620 proprietary rights by implementors or users of this specification can 621 be obtained from the IETF Secretariat. 623 The IETF invites any interested party to bring to its attention any 624 copyrights, patents or patent applications, or other proprietary 625 rights which may cover technology that may be required to practice 626 this standard. Please address the information to the IETF Executive 627 Director. 629 10. Acknowledgments 631 This document is the product of the SNMPv3 Working Group. Some 632 special thanks are in order to the following Working Group members: 634 Randy Bush 635 Jeffrey D. Case 636 Mike Daniele 637 Rob Frye 638 Lauren Heintz 639 Keith McCloghrie 640 Russ Mundy 641 David T. Perkins 642 Randy Presuhn 643 Aleksey Romanov 644 Juergen Schoenwaelder 645 Bert Wijnen 647 This version of the document, edited by Randy Presuhn, was initially 648 based on the work of a design team whose members were: 650 Jeffrey D. Case 651 Keith McCloghrie 652 David T. Perkins 653 Randy Presuhn 654 Juergen Schoenwaelder 656 The previous versions of this document, edited by Keith McCloghrie, 657 was the result of significant work by four major contributors: 659 Jeffrey D. Case 660 Keith McCloghrie 661 Marshall T. Rose 662 Steven Waldbusser 664 Additionally, the contributions of the SNMPv2 Working Group to the 665 previous versions are also acknowledged. In particular, a special 666 thanks is extended for the contributions of: 668 Alexander I. Alten 669 Dave Arneson 670 Uri Blumenthal 671 Doug Book 672 Kim Curran 673 Jim Galvin 674 Maria Greene 675 Iain Hanson 676 Dave Harrington 677 Nguyen Hien 678 Jeff Johnson 679 Michael Kornegay 680 Deirdre Kostick 681 David Levi 682 Daniel Mahoney 683 Bob Natale 684 Brian O'Keefe 685 Andrew Pearson 686 Dave Perkins 687 Randy Presuhn 688 Aleksey Romanov 689 Shawn Routhier 690 Jon Saperia 691 Juergen Schoenwaelder 692 Bob Stewart 693 Kaj Tesink 694 Glenn Waters 695 Bert Wijnen 697 11. Security Considerations 699 SNMPv1 by itself is not a secure environment. Even if the network 700 itself is secure (for example by using IPSec), even then, there is no 701 control as to who on the secure network is allowed to access and 702 GET/SET (read/change) the objects accessible through a command 703 responder application. 705 It is recommended that the implementors consider the security 706 features as provided by the SNMPv3 framework. Specifically, the use 707 of the User-based Security Model RFC 2574 [RFC2574] and the 708 View-based Access Control Model RFC 2575 [RFC2575] is recommended. 710 It is then a customer/user responsibility to ensure that the SNMP 711 entity giving access to a MIB is properly configured to give access 712 to the objects only to those principals (users) that have legitimate 713 rights to indeed GET or SET (change) them. 715 12. References 717 [APPLETALK] Sidhu, G., Andrews, R., and A. Oppenheimer, Inside 718 AppleTalk (second edition). Addison-Wesley, 1990. 720 [BER] Information processing systems - Open Systems 721 Interconnection - Specification of Basic Encoding Rules 722 for Abstract Syntax Notation One (ASN.1), International 723 Organization for Standardization. International Standard 724 8825, December 1987. 726 [IS8072] Information processing systems - Open Systems 727 Interconnection - Transport Service Definition, 728 International Organization for Standardization. 729 International Standard 8072, June 1986. 731 [IS8072A] Information processing systems - Open Systems 732 Interconnection - Transport Service Definition - Addendum 733 1: Connectionless-mode Transmission, International 734 Organization for Standardization. International Standard 735 8072/AD 1, December 1986. 737 [NOVELL] Network System Technical Interface Overview. Novell, 738 Inc, June 1989. 740 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 741 August 1980. 743 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 744 September 1981. 746 [RFC1155] Rose, M., and K. McCloghrie, "Structure and 747 Identification of Management Information for TCP/IP-based 748 Internets", STD 16, RFC 1155, May 1990. 750 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 751 "Simple Network Management Protocol", STD 15, RFC 1157, 752 May 1990. 754 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 755 STD 16, RFC 1212, March 1991. 757 [RFC1215] Rose, M., "A Convention for Defining Traps for use with 758 the SNMP", RFC 1215, March 1991. 760 [RFC1742] Waldbusser, S. and K. Frisa, "AppleTalk Management 761 Information Base II", RFC 1742, January 1995. 763 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 764 "Introduction to Community-based SNMPv2", RFC 1901, 765 January 1996. 767 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 768 "Introduction to Version 3 of the Internet-standard 769 Network Management Framework", RFC 2570, April 1999. 771 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An 772 Architecture for Describing SNMP Management Frameworks", 773 RFC 2571, April 1999. 775 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, 776 "Message Processing and Dispatching for the Simple 777 Network Management Protocol (SNMP)", RFC 2572, April 778 1999. 780 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 781 Applications", RFC 2573, April 1999. 783 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 784 (USM) for version 3 of the Simple Network Management 785 Protocol (SNMPv3)", RFC 2574, April 1999. 787 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 788 Access Control Model (VACM) for the Simple Network 789 Management Protocol (SNMP)", RFC 2575, April 1999. 791 [RFC2576] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 792 "Coexistence between Version 1, Version 2, and Version 3 793 of the Internet-standard Network Management Framework", 794 RFC 2576, March, 2000. 796 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 797 Rose, M., and S. Waldbusser, "Structure of Management 798 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 799 1999. 801 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 802 Rose, M., and S. Waldbusser, "Textual Conventions for 803 SMIv2", STD 58, RFC 2579, April 1999. 805 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 806 Rose, M., and S. Waldbusser, "Conformance Statements for 807 SMIv2", STD 58, RFC 2580, April 1999. 809 [RFC-TM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 810 Waldbusser, "Transport Mappings for the Simple Network 811 Management Protocol", 812 , July 2000. 814 [RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 815 Waldbusser, "Protocol Operations for the Simple Network 816 Management Protocol", 817 , July 2000. 819 13. Editor's Address 821 Randy Presuhn 822 BMC Software, Inc. 823 2141 North First Street 824 San Jose, CA 95131 825 USA 827 Phone: +1 408 546-1006 828 EMail: randy_presuhn@bmc.com 830 14. Changes from RFC 1906 832 These are the changes from RFC 1906: 834 - Corrected typo in IPR statement; 836 - Updated copyright date; 838 - Updated with new editor's name and contact information; 840 - Cosmetic fixes to layout and typography; 842 - Changed title, headers and footers; 844 - Fixed typo in SnmpNBPAddress; 846 - Clarified that one of the BER SEQUENCEs in the example is 847 generated from the ASN.1 SEQUENCE OF construct; 849 - Updated acknowledgements section; 851 - Filled in the Security Considerations section; 853 - Replaced manager/agent terminology with terms from 854 architecture; 856 - Updated references section; 858 - Added MODULE-IDENTITY; 860 - Re-wrote introduction section using current boilerplate; 862 - Added recommendation for larger message size support; 864 - Added historical background on use of rfc1157Domain with 865 proxy and changed status to "deprecated". 867 - Added an abstract. 869 15. Issues 871 This section is to be deleted when it is time to publish this 872 document as an RFC. The issue labels are the same as those used in 873 the on-line issues list at 874 ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1906/index.html 876 1906-01 Done; title changed. 878 1906-02 Done; introduction clause replaced. 880 1906-03 882 1906-04 Done; resolution required no changes. 884 1906-05 Done; typo in SnmpNBPAddress fixed. 886 1906-06 See issue 1906-10. 888 1906-07 Done; use of manager/agent terminology replaced with 889 terms from architecture. 891 1906-08 Done; added recommendation for support of 1472 byte 892 messages. 894 1906-09 Done; resolution required no changes. 896 1906-10 Done; resolved by deprecating the definition. 898 1906-11 Done; resolution required no changes. 900 1906-12 Done; resolution required no changes. 902 1906-13 Done; resolution required no changes. 904 1906-14 Done; clarified that BER SEQUENCE comes from ASN.1 905 SEQUENCE OF. 907 1906-15 Done; security considerations text added. 909 1906-16 Done; references and acknowledgments updated. 911 1906-17 Done; IPR and copyright notices updated. 913 1906-18 Done; resolution required no changes. 915 1906-19 Done; MODULE-IDENTITY added. 917 1906-20 Done; resolution was to make no change. 919 1906-21 Done; resolution was to make no change. 921 1906-22 Done; resolution was to make no change. 923 1906-23 Done; added abstract. 925 16. Full Copyright Statement 927 Copyright (C) The Internet Society (2000). All Rights Reserved. 929 This document and translations of it may be copied and furnished to 930 others, and derivative works that comment on or otherwise explain it 931 or assist in its implementation may be prepared, copied, published 932 and distributed, in whole or in part, without restriction of any 933 kind, provided that the above copyright notice and this paragraph are 934 included on all such copies and derivative works. However, this 935 document itself may not be modified in any way, such as by removing 936 the copyright notice or references to the Internet Society or other 937 Internet organizations, except as needed for the purpose of 938 developing Internet standards in which case the procedures for 939 copyrights defined in the Internet Standards process must be 940 followed, or as required to translate it into languages other than 941 English. 943 The limited permissions granted above are perpetual and will not be 944 revoked by the Internet Society or its successors or assigns. 946 This document and the information contained herein is provided on an 947 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 948 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 949 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 950 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 951 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.