idnits 2.17.1 draft-ietf-snmpv2-tm-ds-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 44 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 90 has weird spacing: '... octets cont...' == Line 118 has weird spacing: '... octets cont...' == Line 167 has weird spacing: '... octets cont...' == Line 169 has weird spacing: '...address net...' -- 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 (September 1995) is 10422 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1243 (ref. '6') (Obsoleted by RFC 1742) -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Transport Mappings for SNMPv2 September 1995 4 Transport Mappings for Version 2 of the 5 Simple Network Management Protocol (SNMPv2) 7 20 September 1995 | 9 draft-ietf-snmpv2-tm-ds-03.txt | 11 Keith McCloghrie 12 Editor + 13 Cisco Systems, Inc. 14 kzm@cisco.com 16 Status of this Memo - 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, and 20 its working groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference material 26 or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 30 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 31 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 33 1. Introduction 35 A management system contains: several (potentially many) nodes, each 36 with a processing entity, termed an agent, which has access to 37 management instrumentation; at least one management station; and, a 38 management protocol, used to convey management information between the 39 agents and management stations. Operations of the protocol are carried 40 out under an administrative framework which defines authentication, 41 authorization, access control, and privacy policies. 43 Management stations execute management applications which monitor and 44 control managed elements. Managed elements are devices such as hosts, 45 routers, terminal servers, etc., which are monitored and controlled via 46 access to their management information. 48 The management protocol, version 2 of the Simple Network Management 49 Protocol [1], may be used over a variety of protocol suites. It is the 50 purpose of this document to define how the SNMPv2 maps onto an initial 51 set of transport domains. Other mappings may be defined in the future. 53 Although several mappings are defined, the mapping onto UDP is the 54 preferred mapping. As such, to provide for the greatest level of 55 interoperability, systems which choose to deploy other mappings should 56 also provide for proxy service to the UDP mapping. 58 1.1. A Note on Terminology 60 For the purpose of exposition, the original Internet-standard Network 61 Management Framework, as described in RFCs 1155, 1157, and 1212, is 62 termed the SNMP version 1 framework (SNMPv1). The current framework is 63 termed the SNMP version 2 framework (SNMPv2). 65 2. Definitions 67 SNMPv2-TM DEFINITIONS ::= BEGIN 69 IMPORTS 70 OBJECT-IDENTITY, snmpDomains, snmpProxys 71 FROM SNMPv2-SMI 72 TEXTUAL-CONVENTION 73 FROM SNMPv2-TC; 75 -- SNMPv2 over UDP over IPv4 77 snmpUDPDomain OBJECT-IDENTITY 78 STATUS current 79 DESCRIPTION 80 "The SNMPv2 over UDP transport domain. The corresponding 81 transport address is of type SnmpUDPAddress." 82 ::= { snmpDomains 1 } 84 SnmpUDPAddress ::= TEXTUAL-CONVENTION 85 DISPLAY-HINT "1d.1d.1d.1d/2d" 86 STATUS current 87 DESCRIPTION 88 "Represents a UDP address: 90 octets contents encoding 91 1-4 IP-address network-byte order 92 5-6 UDP-port network-byte order 93 " 94 SYNTAX OCTET STRING (SIZE (6)) 96 -- SNMPv2 over OSI 98 snmpCLNSDomain OBJECT-IDENTITY 99 STATUS current 100 DESCRIPTION 101 "The SNMPv2 over CLNS transport domain. The corresponding 102 transport address is of type SnmpOSIAddress." 103 ::= { snmpDomains 2 } 105 snmpCONSDomain OBJECT-IDENTITY 106 STATUS current 107 DESCRIPTION 108 "The SNMPv2 over CONS transport domain. The corresponding 109 transport address is of type SnmpOSIAddress." 110 ::= { snmpDomains 3 } 112 SnmpOSIAddress ::= TEXTUAL-CONVENTION 113 DISPLAY-HINT "*1x:/1x:" 114 STATUS current 115 DESCRIPTION 116 "Represents an OSI transport-address: 118 octets contents encoding 119 1 length of NSAP 'n' as an unsigned-integer 120 (either 0 or from 3 to 20) 121 2..(n+1) NSAP concrete binary representation 122 (n+2)..m TSEL string of (up to 64) octets 123 " 124 SYNTAX OCTET STRING (SIZE (1 | 4..85)) 126 -- SNMPv2 over DDP 128 snmpDDPDomain OBJECT-IDENTITY 129 STATUS current 130 DESCRIPTION 131 "The SNMPv2 over DDP transport domain. The corresponding 132 transport address is of type SnmpNBPAddress." 133 ::= { snmpDomains 4 } 135 SnmpNBPAddress ::= TEXTUAL-CONVENTION 136 STATUS current 137 DESCRIPTION 138 "Represents an NBP name: 140 octets contents encoding 141 1 length of object 'n' as an unsigned integer 142 2..(n+1) object string of (up to 32) octets 143 n+2 length of type 'p' as an unsigned integer 144 (n+3)..(n+2+p) type string of (up to 32) octets 145 n+3+p length of zone 'q' as an unsigned integer 146 (n+4+p)..(n+3+p+q) zone string of (up to 32) octets 148 For comparison purposes, strings are case-insensitive All 149 strings may contain any octet other than 255 (hex ff)." 150 SYNTAX OCTET STRING (SIZE (3..99)) 152 -- SNMPv2 over IPX 154 snmpIPXDomain OBJECT-IDENTITY 155 STATUS current 156 DESCRIPTION 157 "The SNMPv2 over IPX transport domain. The corresponding 158 transport address is of type SnmpIPXAddress." 159 ::= { snmpDomains 5 } 161 SnmpIPXAddress ::= TEXTUAL-CONVENTION 162 DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" 163 STATUS current 164 DESCRIPTION 165 "Represents an IPX address: 167 octets contents encoding 168 1-4 network-number network-byte order 169 5-10 physical-address network-byte order 170 11-12 socket-number network-byte order 171 " 172 SYNTAX OCTET STRING (SIZE (12)) 174 -- for proxy to SNMPv1 (RFC 1157) | 176 rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } 178 rfc1157Domain OBJECT-IDENTITY 179 STATUS current 180 DESCRIPTION 181 "The transport domain for SNMPv1 over UDP. The 182 corresponding transport address is of type SnmpUDPAddress." 183 ::= { rfc1157Proxy 1 } 185 -- ::= { rfc1157Proxy 2 } this OID is obsolete + 187 END - 188 3. SNMPv2 over UDP 190 This is the preferred transport mapping. 192 3.1. Serialization 194 Each instance of a message is serialized (i.e., encoded according to the 195 convention of [1]) onto a single UDP[2] datagram, using the algorithm 196 specified in Section 8. 198 3.2. Well-known Values 200 It is suggested that administrators configure their SNMPv2 entities | 201 acting in an agent role to listen on UDP port 161. Further, it is 202 suggested that notification sinks be configured to listen on UDP port 203 162. 205 When an SNMPv2 entity uses this transport mapping, it must be capable of | 206 accepting messages that are at least 484 octets in size. | 207 Implementation of larger values is encouraged whenever possible. 209 4. SNMPv2 over OSI 211 This is an optional transport mapping. 213 4.1. Serialization 215 Each instance of a message is serialized onto a single TSDU [3,4] for 216 the OSI Connectionless-mode Transport Service (CLTS), using the 217 algorithm specified in Section 8. 219 4.2. Well-known Values 221 It is suggested that administrators configure their SNMPv2 entities | 222 acting in an agent role to listen on transport selector "snmp-l" (which 223 consists of six ASCII characters), when using a CL-mode network service 224 to realize the CLTS. Further, it is suggested that notification sinks 225 be configured to listen on transport selector "snmpt-l" (which consists 226 of seven ASCII characters, six letters and a hyphen) when using a CL- 227 mode network service to realize the CLTS. Similarly, when using a CO- 228 mode network service to realize the CLTS, the suggested transport 229 selectors are "snmp-o" and "snmpt-o", for agent and notification sink, 230 respectively. 232 When an SNMPv2 entity uses this transport mapping, it must be capable of | 233 accepting messages that are at least 484 octets in size. | 234 Implementation of larger values is encouraged whenever possible. 236 5. SNMPv2 over DDP 238 This is an optional transport mapping. 240 5.1. Serialization 242 Each instance of a message is serialized onto a single DDP datagram [5], 243 using the algorithm specified in Section 8. 245 5.2. Well-known Values 247 SNMPv2 messages are sent using DDP protocol type 8. SNMPv2 entities 248 acting in an agent role listens on DDP socket number 8, whilst 249 notification sinks listen on DDP socket number 9. 251 Administrators must configure their SNMPv2 entities | 252 acting in an agent role to use NBP type "SNMP Agent" (which consists of 253 ten ASCII characters), whilst notification sinks must be configured to 254 use NBP type "SNMP Trap Handler" (which consists of seventeen ASCII 255 characters). 257 The NBP name for agents and notification sinks should be stable - NBP 258 names should not change any more often than the IP address of a typical 259 TCP/IP node. It is suggested that the NBP name be stored in some form 260 of stable storage. 262 When an SNMPv2 entity uses this transport mapping, it must be capable of | 263 accepting messages that are at least 484 octets in size. | 264 Implementation of larger values is encouraged whenever possible. 266 5.3. Discussion of AppleTalk Addressing 268 The AppleTalk protocol suite has certain features not manifest in the 269 TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of 270 address assignment can cause problems for SNMPv2 entities that wish to 271 manage AppleTalk networks. TCP/IP nodes have an associated IP address 272 which distinguishes each from the other. In contrast, AppleTalk nodes 273 generally have no such characteristic. The network-level address, while 274 often relatively stable, can change at every reboot (or more 275 frequently). 277 Thus, when SNMPv2 is mapped over DDP, nodes are identified by a "name", 278 rather than by an "address". Hence, all AppleTalk nodes that implement 279 this mapping are required to respond to NBP lookups and confirms (e.g., 280 implement the NBP protocol stub), which guarantees that a mapping from 281 NBP name to DDP address will be possible. 283 In determining the SNMP identity to register for an SNMPv2 entity, it is 284 suggested that the SNMP identity be a name which is associated with 285 other network services offered by the machine. 287 NBP lookups, which are used to map NBP names into DDP addresses, can 288 cause large amounts of network traffic as well as consume CPU resources. 289 It is also the case that the ability to perform an NBP lookup is 290 sensitive to certain network disruptions (such as zone table 291 inconsistencies) which would not prevent direct AppleTalk communications 292 between two SNMPv2 entities. 294 Thus, it is recommended that NBP lookups be used infrequently, primarily 295 to create a cache of name-to-address mappings. These cached mappings 296 should then be used for any further SNMP traffic. It is recommended 297 that SNMPv2 entities acting in a manager role should maintain this cache 298 between reboots. This caching can help minimize network traffic, reduce 299 CPU load on the network, and allow for (some amount of) network trouble 300 shooting when the basic name-to-address translation mechanism is broken. 302 5.3.1. How to Acquire NBP names 304 An SNMPv2 entity acting in a manager role may have a pre-configured list 305 of names of "known" SNMPv2 entities acting in an agent role. Similarly, 306 an SNMPv2 entity acting in a manager role might interact with an 307 operator. Finally, an SNMPv2 entity acting in a manager role might 308 communicate with all SNMPv2 entities acting in an agent role in a set of 309 zones or networks. 311 5.3.2. When to Turn NBP names into DDP addresses 313 When an SNMPv2 entity uses a cache entry to address an SNMP packet, it 314 should attempt to confirm the validity mapping, if the mapping hasn't 315 been confirmed within the last T1 seconds. This cache entry lifetime, 316 T1, has a minimum, default value of 60 seconds, and should be 317 configurable. 319 An SNMPv2 entity acting in a manager role may decide to prime its cache 320 of names prior to actually communicating with another SNMPv2 entity. In 321 general, it is expected that such an entity may want to keep certain 322 mappings "more current" than other mappings, e.g., those nodes which 323 represent the network infrastructure (e.g., routers) may be deemed "more 324 important". 326 Note that an SNMPv2 entity acting in a manager role should not prime its 327 entire cache upon initialization - rather, it should attempt resolutions 328 over an extended period of time (perhaps in some pre-determined or 329 configured priority order). Each of these resolutions might, in fact, 330 be a wildcard lookup in a given zone. 332 An SNMPv2 entity acting in an agent role must never prime its cache. 333 Such an entity should do NBP lookups (or confirms) only when it needs to 334 send an SNMP trap. When generating a response, such an entity does not 335 need to confirm a cache entry. 337 5.3.3. How to Turn NBP names into DDP addresses 339 If the only piece of information available is the NBP name, then an NBP 340 lookup should be performed to turn that name into a DDP address. 341 However, if there is a piece of stale information, it can be used as a 342 hint to perform an NBP confirm (which sends a unicast to the network 343 address which is presumed to be the target of the name lookup) to see if 344 the stale information is, in fact, still valid. 346 An NBP name to DDP address mapping can also be confirmed implicitly 347 using only SNMP transactions. For example, an SNMPv2 entity acting in a 348 manager role issuing a retrieval operation could also retrieve the 349 relevant objects from the NBP group [6] for the SNMPv2 entity acting in 350 an agent role. This information can then be correlated with the source 351 DDP address of the response. 353 5.3.4. What if NBP is broken 355 Under some circumstances, there may be connectivity between two SNMPv2 356 entities, but the NBP mapping machinery may be broken, e.g., 358 o the NBP FwdReq (forward NBP lookup onto local attached network) 359 mechanism might be broken at a router on the other entity's 360 network; or, 362 o the NBP BrRq (NBP broadcast request) mechanism might be broken at a 363 router on the entity's own network; or, 365 o NBP might be broken on the other entity's node. 367 An SNMPv2 entity acting in a manager role which is dedicated to 368 AppleTalk management might choose to alleviate some of these failures by 369 directly implementing the router portion of NBP. For example, such an 370 entity might already know all the zones on the AppleTalk internet and 371 the networks on which each zone appears. Given an NBP lookup which 372 fails, the entity could send an NBP FwdReq to the network in which the 373 agent was last located. If that failed, the station could then send an 374 NBP LkUp (NBP lookup packet) as a directed (DDP) multicast to each 375 network number on that network. Of the above (single) failures, this 376 combined approach will solve the case where either the local router's 377 BrRq-to-FwdReq mechanism is broken or the remote router's FwdReq-to-LkUp 378 mechanism is broken. 380 6. SNMPv2 over IPX 382 This is an optional transport mapping. 384 6.1. Serialization 386 Each instance of a message is serialized onto a single IPX datagram [7], 387 using the algorithm specified in Section 8. 389 6.2. Well-known Values 391 SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet Exchange 392 Protocol). 394 It is suggested that administrators configure their SNMPv2 entities | 395 acting in an agent role to listen on IPX socket 36879 (900f 396 hexadecimal). Further, it is suggested that notification sinks be 397 configured to listen on IPX socket 36880 (9010 hexadecimal) 399 When an SNMPv2 entity uses this transport mapping, it must be capable of | 400 accepting messages that are at least 546 octets in size. | 401 Implementation of larger values is encouraged whenever possible. 403 7. Proxy to SNMPv1 + 405 In order to provide proxy to SNMPv1 [8], it may be useful to define a | 406 transport domain, rfc1157Domain, which indicates the transport mapping | 407 for SNMP messages as defined in RFC 1157. | 408 Section 3.1 of [9] specifies the behavior of the proxy agent. 410 8. Serialization using the Basic Encoding Rules - 412 When the Basic Encoding Rules [10] are used for serialization: | 414 (1) When encoding the length field, only the definite form is used; use 415 of the indefinite form encoding is prohibited. Note that when 416 using the definite-long form, it is permissible to use more than 417 the minimum number of length octets necessary to encode the length 418 field. 420 (2) When encoding the value field, the primitive form shall be used for 421 all simple types, i.e., INTEGER, OCTET STRING, and OBJECT 422 IDENTIFIER (either IMPLICIT or explicit). The constructed form of 423 encoding shall be used only for structured types, i.e., a SEQUENCE 424 or an IMPLICIT SEQUENCE. 426 (3) When encoding an object whose syntax is described using the BITS 427 construct, the value is encoded as an OCTET STRING, in which all 428 the named bits in (the definition of) the bitstring, commencing 429 with the first bit and proceeding to the last bit, are placed in 430 bits 8 to 1 of the first octet, followed by bits 8 to 1 of each 431 subsequent octet in turn, followed by as many bits as are needed of 432 the final subsequent octet, commencing with bit 8. Remaining bits, 433 if any, of the final octet are set to zero on generation and 434 ignored on receipt. 436 These restrictions apply to all aspects of ASN.1 encoding, including the 437 message wrappers, protocol data units, and the data objects they 438 contain. 440 8.1. Usage Example 442 As an example of applying the Basic Encoding Rules, suppose one wanted 443 to encode an instance of the GetBulkRequest-PDU [1]: 445 [5] IMPLICIT SEQUENCE { 446 request-id 1414684022, 447 non-repeaters 1, 448 max-repetitions 2, 449 variable-bindings { 450 { name sysUpTime, 451 value { unspecified NULL } }, 452 { name ipNetToMediaPhysAddress, 453 value { unspecified NULL } }, 454 { name ipNetToMediaType, 455 value { unspecified NULL } } 456 } 457 } 459 Applying the BER, this would be encoded (in hexadecimal) as: 461 [5] IMPLICIT SEQUENCE a5 82 00 39 462 INTEGER 02 04 52 54 5d 76 463 INTEGER 02 01 01 464 INTEGER 02 01 02 465 SEQUENCE 30 2b 466 SEQUENCE 30 0b 467 OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03 468 NULL 05 00 469 SEQUENCE 30 0d 470 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02 471 NULL 05 00 472 SEQUENCE 30 0d 473 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 474 NULL 05 00 476 Note that the initial SEQUENCE is not encoded using the minimum number 477 of length octets. (The first octet of the length, 82, indicates that 478 the length of the content is encoded in the next two octets.) 479 9. Acknowledgements 481 This document is the result of significant work by the four major 482 contributors: 484 Jeffrey Case (SNMP Research, case@snmp.com) 485 Keith McCloghrie (Cisco Systems, kzm@cisco.com) 486 Marshall Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) 487 Steven Waldbusser (International Network Services, stevew@uni.ins.com) 489 In addition, the contributions of the SNMPv2 Working Group are 490 acknowledged. In particular, a special thanks is extended for the 491 contributions of: 493 Alexander I. Alten (Novell) 494 Dave Arneson (Cabletron) 495 Uri Blumenthal (IBM) 496 Doug Book (Chipcom) 497 Kim Curran (Bell-Northern Research) 498 Jim Galvin (Trusted Information Systems) 499 Maria Greene (Ascom Timeplex) 500 Iain Hanson (Digital) 501 Dave Harrington (Cabletron) 502 Nguyen Hien (IBM) 503 Jeff Johnson (Cisco Systems) 504 Michael Kornegay (Object Quest) 505 Deirdre Kostick (AT&T Bell Labs) 506 David Levi (SNMP Research) 507 Daniel Mahoney (Cabletron) 508 Bob Natale (ACE*COMM) 509 Brian O'Keefe (Hewlett Packard) 510 Andrew Pearson (SNMP Research) 511 Dave Perkins (Peer Networks) 512 Randy Presuhn (Peer Networks) 513 Aleksey Romanov (Quality Quorum) 514 Shawn Routhier (Epilogue) 515 Jon Saperia (BGS Systems) 516 Bob Stewart (Cisco Systems, bstewart@cisco.com), chair 517 Kaj Tesink (Bellcore) 518 Glenn Waters (Bell-Northern Research) 519 Bert Wijnen (IBM) 521 10. References 523 [1] McCloghrie, K., Editor, | 524 "Protocol Operations for Version 2 of the Simple Network Management 525 Protocol (SNMPv2)", Internet Draft, Cisco Systems, September 1995. | 527 [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 528 USC/Information Sciences Institute, August 1980. 530 [3] Information processing systems - Open Systems Interconnection - 531 Transport Service Definition, International Organization for 532 Standardization. International Standard 8072, (June, 1986). 534 [4] Information processing systems - Open Systems Interconnection - 535 Transport Service Definition - Addendum 1: Connectionless-mode 536 Transmission, International Organization for Standardization. 537 International Standard 8072/AD 1, (December, 1986). 539 [5] G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk (second 540 edition). Addison-Wesley, 1990. 542 [6] Waldbusser, S., "AppleTalk Management Information Base", RFC 1243, 543 Carnegie Mellon University, July 1991. 545 [7] Network System Technical Interface Overview. Novell, Inc, (June, 546 1989). 548 [8] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network 549 Management Protocol", STD 15, RFC 1157, SNMP Research, Performance 550 Systems International, MIT Laboratory for Computer Science, May 551 1990. 553 [9] McCloghrie, K., Editor, | 554 "Coexistence between Version 1 and Version 2 of the Internet- 555 standard Network Management Framework", Internet Draft, Cisco | 556 Systems, September 1995. | 558 [10] - 559 Information processing systems - Open Systems Interconnection - 560 Specification of Basic Encoding Rules for Abstract Syntax Notation 561 One (ASN.1), International Organization for Standardization. 562 International Standard 8825, December 1987. 564 11. Security Considerations 566 Security issues are not discussed in this memo. 568 12. Editor's Address 570 Keith McCloghrie - 571 Cisco Systems, Inc. 572 170 West Tasman Drive | 573 San Jose, CA 95134-1706 | 574 US | 576 Phone: +1 408 526 5260 577 Email: kzm@cisco.com 579 Table of Contents - 581 1 Introduction .................................................... 2 582 1.1 A Note on Terminology ......................................... 2 583 2 Definitions ..................................................... 3 584 3 SNMPv2 over UDP ................................................. 7 585 3.1 Serialization ................................................. 7 586 3.2 Well-known Values ............................................. 7 587 4 SNMPv2 over OSI ................................................. 8 588 4.1 Serialization ................................................. 8 589 4.2 Well-known Values ............................................. 8 590 5 SNMPv2 over DDP ................................................. 9 591 5.1 Serialization ................................................. 9 592 5.2 Well-known Values ............................................. 9 593 5.3 Discussion of AppleTalk Addressing ............................ 9 594 5.3.1 How to Acquire NBP names .................................... 10 595 5.3.2 When to Turn NBP names into DDP addresses ................... 10 596 5.3.3 How to Turn NBP names into DDP addresses .................... 11 597 5.3.4 What if NBP is broken ....................................... 11 598 6 SNMPv2 over IPX ................................................. 13 599 6.1 Serialization ................................................. 13 600 6.2 Well-known Values ............................................. 13 601 7 Proxy to SNMPv1 ................................................. 14 602 8 Serialization using the Basic Encoding Rules .................... 15 603 8.1 Usage Example ................................................. 16 604 9 Acknowledgements ................................................ 17 605 10 References ..................................................... 18 606 11 Security Considerations ........................................ 19 607 12 Editor's Address ............................................... 19