idnits 2.17.1 draft-ietf-snmpv2-tm-ds-04.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-04-20) 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 24 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 89 has weird spacing: '... octets cont...' == Line 117 has weird spacing: '... octets cont...' == Line 166 has weird spacing: '... octets cont...' == Line 168 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 10445 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' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 10 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 25 September 1995 | 9 draft-ietf-snmpv2-tm-ds-04.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), as described in [11]. | 64 2. Definitions 66 SNMPv2-TM DEFINITIONS ::= BEGIN 68 IMPORTS 69 OBJECT-IDENTITY, snmpDomains, snmpProxys 70 FROM SNMPv2-SMI 71 TEXTUAL-CONVENTION 72 FROM SNMPv2-TC; 74 -- SNMPv2 over UDP over IPv4 76 snmpUDPDomain OBJECT-IDENTITY 77 STATUS current 78 DESCRIPTION 79 "The SNMPv2 over UDP transport domain. The corresponding 80 transport address is of type SnmpUDPAddress." 81 ::= { snmpDomains 1 } 83 SnmpUDPAddress ::= TEXTUAL-CONVENTION 84 DISPLAY-HINT "1d.1d.1d.1d/2d" 85 STATUS current 86 DESCRIPTION 87 "Represents a UDP address: 89 octets contents encoding 90 1-4 IP-address network-byte order 91 5-6 UDP-port network-byte order 92 " 93 SYNTAX OCTET STRING (SIZE (6)) 95 -- SNMPv2 over OSI 97 snmpCLNSDomain OBJECT-IDENTITY 98 STATUS current 99 DESCRIPTION 100 "The SNMPv2 over CLNS transport domain. The corresponding 101 transport address is of type SnmpOSIAddress." 102 ::= { snmpDomains 2 } 104 snmpCONSDomain OBJECT-IDENTITY 105 STATUS current 106 DESCRIPTION 107 "The SNMPv2 over CONS transport domain. The corresponding 108 transport address is of type SnmpOSIAddress." 109 ::= { snmpDomains 3 } 111 SnmpOSIAddress ::= TEXTUAL-CONVENTION 112 DISPLAY-HINT "*1x:/1x:" 113 STATUS current 114 DESCRIPTION 115 "Represents an OSI transport-address: 117 octets contents encoding 118 1 length of NSAP 'n' as an unsigned-integer 119 (either 0 or from 3 to 20) 120 2..(n+1) NSAP concrete binary representation 121 (n+2)..m TSEL string of (up to 64) octets 122 " 123 SYNTAX OCTET STRING (SIZE (1 | 4..85)) 125 -- SNMPv2 over DDP 127 snmpDDPDomain OBJECT-IDENTITY 128 STATUS current 129 DESCRIPTION 130 "The SNMPv2 over DDP transport domain. The corresponding 131 transport address is of type SnmpNBPAddress." 132 ::= { snmpDomains 4 } 134 SnmpNBPAddress ::= TEXTUAL-CONVENTION 135 STATUS current 136 DESCRIPTION 137 "Represents an NBP name: 139 octets contents encoding 140 1 length of object 'n' as an unsigned integer 141 2..(n+1) object string of (up to 32) octets 142 n+2 length of type 'p' as an unsigned integer 143 (n+3)..(n+2+p) type string of (up to 32) octets 144 n+3+p length of zone 'q' as an unsigned integer 145 (n+4+p)..(n+3+p+q) zone string of (up to 32) octets 147 For comparison purposes, strings are case-insensitive All 148 strings may contain any octet other than 255 (hex ff)." 149 SYNTAX OCTET STRING (SIZE (3..99)) 151 -- SNMPv2 over IPX 153 snmpIPXDomain OBJECT-IDENTITY 154 STATUS current 155 DESCRIPTION 156 "The SNMPv2 over IPX transport domain. The corresponding 157 transport address is of type SnmpIPXAddress." 158 ::= { snmpDomains 5 } 160 SnmpIPXAddress ::= TEXTUAL-CONVENTION 161 DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" 162 STATUS current 163 DESCRIPTION 164 "Represents an IPX address: 166 octets contents encoding 167 1-4 network-number network-byte order 168 5-10 physical-address network-byte order 169 11-12 socket-number network-byte order 170 " 171 SYNTAX OCTET STRING (SIZE (12)) 173 -- for proxy to SNMPv1 (RFC 1157) 175 rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } 177 rfc1157Domain OBJECT-IDENTITY 178 STATUS current 179 DESCRIPTION 180 "The transport domain for SNMPv1 over UDP. The 181 corresponding transport address is of type SnmpUDPAddress." 182 ::= { rfc1157Proxy 1 } 184 -- ::= { rfc1157Proxy 2 } this OID is obsolete 186 END 187 3. SNMPv2 over UDP 189 This is the preferred transport mapping. 191 3.1. Serialization 193 Each instance of a message is serialized (i.e., encoded according to the 194 convention of [1]) onto a single UDP[2] datagram, using the algorithm 195 specified in Section 8. 197 3.2. Well-known Values 199 It is suggested that administrators configure their SNMPv2 entities 200 acting in an agent role to listen on UDP port 161. Further, it is 201 suggested that notification sinks be configured to listen on UDP port 202 162. 204 When an SNMPv2 entity uses this transport mapping, it must be capable of 205 accepting messages that are at least 484 octets in size. Implementation 206 of larger values is encouraged whenever possible. 208 4. SNMPv2 over OSI 210 This is an optional transport mapping. 212 4.1. Serialization 214 Each instance of a message is serialized onto a single TSDU [3,4] for 215 the OSI Connectionless-mode Transport Service (CLTS), using the 216 algorithm specified in Section 8. 218 4.2. Well-known Values 220 It is suggested that administrators configure their SNMPv2 entities 221 acting in an agent role to listen on transport selector "snmp-l" (which 222 consists of six ASCII characters), when using a CL-mode network service 223 to realize the CLTS. Further, it is suggested that notification sinks 224 be configured to listen on transport selector "snmpt-l" (which consists 225 of seven ASCII characters, six letters and a hyphen) when using a CL- 226 mode network service to realize the CLTS. Similarly, when using a CO- 227 mode network service to realize the CLTS, the suggested transport 228 selectors are "snmp-o" and "snmpt-o", for agent and notification sink, 229 respectively. 231 When an SNMPv2 entity uses this transport mapping, it must be capable of 232 accepting messages that are at least 484 octets in size. Implementation 233 of larger values is encouraged whenever possible. 235 5. SNMPv2 over DDP 237 This is an optional transport mapping. 239 5.1. Serialization 241 Each instance of a message is serialized onto a single DDP datagram [5], 242 using the algorithm specified in Section 8. 244 5.2. Well-known Values 246 SNMPv2 messages are sent using DDP protocol type 8. SNMPv2 entities 247 acting in an agent role listens on DDP socket number 8, whilst 248 notification sinks listen on DDP socket number 9. 250 Administrators must configure their SNMPv2 entities acting in an agent 251 role to use NBP type "SNMP Agent" (which consists of ten ASCII 252 characters), whilst notification sinks must be configured to use NBP 253 type "SNMP Trap Handler" (which consists of seventeen ASCII characters). 255 The NBP name for agents and notification sinks should be stable - NBP 256 names should not change any more often than the IP address of a typical 257 TCP/IP node. It is suggested that the NBP name be stored in some form 258 of stable storage. 260 When an SNMPv2 entity uses this transport mapping, it must be capable of 261 accepting messages that are at least 484 octets in size. Implementation 262 of larger values is encouraged whenever possible. 264 5.3. Discussion of AppleTalk Addressing 266 The AppleTalk protocol suite has certain features not manifest in the 267 TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of 268 address assignment can cause problems for SNMPv2 entities that wish to 269 manage AppleTalk networks. TCP/IP nodes have an associated IP address 270 which distinguishes each from the other. In contrast, AppleTalk nodes 271 generally have no such characteristic. The network-level address, while 272 often relatively stable, can change at every reboot (or more 273 frequently). 275 Thus, when SNMPv2 is mapped over DDP, nodes are identified by a "name", 276 rather than by an "address". Hence, all AppleTalk nodes that implement 277 this mapping are required to respond to NBP lookups and confirms (e.g., 278 implement the NBP protocol stub), which guarantees that a mapping from 279 NBP name to DDP address will be possible. 281 In determining the SNMP identity to register for an SNMPv2 entity, it is 282 suggested that the SNMP identity be a name which is associated with 283 other network services offered by the machine. 285 NBP lookups, which are used to map NBP names into DDP addresses, can 286 cause large amounts of network traffic as well as consume CPU resources. 287 It is also the case that the ability to perform an NBP lookup is 288 sensitive to certain network disruptions (such as zone table 289 inconsistencies) which would not prevent direct AppleTalk communications 290 between two SNMPv2 entities. 292 Thus, it is recommended that NBP lookups be used infrequently, primarily 293 to create a cache of name-to-address mappings. These cached mappings 294 should then be used for any further SNMP traffic. It is recommended 295 that SNMPv2 entities acting in a manager role should maintain this cache 296 between reboots. This caching can help minimize network traffic, reduce 297 CPU load on the network, and allow for (some amount of) network trouble 298 shooting when the basic name-to-address translation mechanism is broken. 300 5.3.1. How to Acquire NBP names 302 An SNMPv2 entity acting in a manager role may have a pre-configured list 303 of names of "known" SNMPv2 entities acting in an agent role. Similarly, 304 an SNMPv2 entity acting in a manager role might interact with an 305 operator. Finally, an SNMPv2 entity acting in a manager role might 306 communicate with all SNMPv2 entities acting in an agent role in a set of 307 zones or networks. 309 5.3.2. When to Turn NBP names into DDP addresses 311 When an SNMPv2 entity uses a cache entry to address an SNMP packet, it 312 should attempt to confirm the validity mapping, if the mapping hasn't 313 been confirmed within the last T1 seconds. This cache entry lifetime, 314 T1, has a minimum, default value of 60 seconds, and should be 315 configurable. 317 An SNMPv2 entity acting in a manager role may decide to prime its cache 318 of names prior to actually communicating with another SNMPv2 entity. In 319 general, it is expected that such an entity may want to keep certain 320 mappings "more current" than other mappings, e.g., those nodes which 321 represent the network infrastructure (e.g., routers) may be deemed "more 322 important". 324 Note that an SNMPv2 entity acting in a manager role should not prime its 325 entire cache upon initialization - rather, it should attempt resolutions 326 over an extended period of time (perhaps in some pre-determined or 327 configured priority order). Each of these resolutions might, in fact, 328 be a wildcard lookup in a given zone. 330 An SNMPv2 entity acting in an agent role must never prime its cache. 331 Such an entity should do NBP lookups (or confirms) only when it needs to 332 send an SNMP trap. When generating a response, such an entity does not 333 need to confirm a cache entry. 335 5.3.3. How to Turn NBP names into DDP addresses 337 If the only piece of information available is the NBP name, then an NBP 338 lookup should be performed to turn that name into a DDP address. 339 However, if there is a piece of stale information, it can be used as a 340 hint to perform an NBP confirm (which sends a unicast to the network 341 address which is presumed to be the target of the name lookup) to see if 342 the stale information is, in fact, still valid. 344 An NBP name to DDP address mapping can also be confirmed implicitly 345 using only SNMP transactions. For example, an SNMPv2 entity acting in a 346 manager role issuing a retrieval operation could also retrieve the 347 relevant objects from the NBP group [6] for the SNMPv2 entity acting in 348 an agent role. This information can then be correlated with the source 349 DDP address of the response. 351 5.3.4. What if NBP is broken 353 Under some circumstances, there may be connectivity between two SNMPv2 354 entities, but the NBP mapping machinery may be broken, e.g., 356 o the NBP FwdReq (forward NBP lookup onto local attached network) 357 mechanism might be broken at a router on the other entity's 358 network; or, 360 o the NBP BrRq (NBP broadcast request) mechanism might be broken at a 361 router on the entity's own network; or, 363 o NBP might be broken on the other entity's node. 365 An SNMPv2 entity acting in a manager role which is dedicated to 366 AppleTalk management might choose to alleviate some of these failures by 367 directly implementing the router portion of NBP. For example, such an 368 entity might already know all the zones on the AppleTalk internet and 369 the networks on which each zone appears. Given an NBP lookup which 370 fails, the entity could send an NBP FwdReq to the network in which the 371 agent was last located. If that failed, the station could then send an 372 NBP LkUp (NBP lookup packet) as a directed (DDP) multicast to each 373 network number on that network. Of the above (single) failures, this 374 combined approach will solve the case where either the local router's 375 BrRq-to-FwdReq mechanism is broken or the remote router's FwdReq-to-LkUp 376 mechanism is broken. 378 6. SNMPv2 over IPX 380 This is an optional transport mapping. 382 6.1. Serialization 384 Each instance of a message is serialized onto a single IPX datagram [7], 385 using the algorithm specified in Section 8. 387 6.2. Well-known Values 389 SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet Exchange 390 Protocol). 392 It is suggested that administrators configure their SNMPv2 entities 393 acting in an agent role to listen on IPX socket 36879 (900f 394 hexadecimal). Further, it is suggested that notification sinks be 395 configured to listen on IPX socket 36880 (9010 hexadecimal) 397 When an SNMPv2 entity uses this transport mapping, it must be capable of 398 accepting messages that are at least 546 octets in size. Implementation 399 of larger values is encouraged whenever possible. 401 7. Proxy to SNMPv1 403 In order to provide proxy to SNMPv1 [8], it may be useful to define a 404 transport domain, rfc1157Domain, which indicates the transport mapping 405 for SNMP messages as defined in RFC 1157. Section 3.1 of [9] specifies 406 the behavior of the proxy agent. 408 8. Serialization using the Basic Encoding Rules 410 When the Basic Encoding Rules [10] are used for serialization: 412 (1) When encoding the length field, only the definite form is used; use 413 of the indefinite form encoding is prohibited. Note that when 414 using the definite-long form, it is permissible to use more than 415 the minimum number of length octets necessary to encode the length 416 field. 418 (2) When encoding the value field, the primitive form shall be used for 419 all simple types, i.e., INTEGER, OCTET STRING, and OBJECT 420 IDENTIFIER (either IMPLICIT or explicit). The constructed form of 421 encoding shall be used only for structured types, i.e., a SEQUENCE 422 or an IMPLICIT SEQUENCE. 424 (3) When encoding an object whose syntax is described using the BITS 425 construct, the value is encoded as an OCTET STRING, in which all 426 the named bits in (the definition of) the bitstring, commencing 427 with the first bit and proceeding to the last bit, are placed in 428 bits 8 to 1 of the first octet, followed by bits 8 to 1 of each 429 subsequent octet in turn, followed by as many bits as are needed of 430 the final subsequent octet, commencing with bit 8. Remaining bits, 431 if any, of the final octet are set to zero on generation and 432 ignored on receipt. 434 These restrictions apply to all aspects of ASN.1 encoding, including the 435 message wrappers, protocol data units, and the data objects they 436 contain. 438 8.1. Usage Example 440 As an example of applying the Basic Encoding Rules, suppose one wanted 441 to encode an instance of the GetBulkRequest-PDU [1]: 443 [5] IMPLICIT SEQUENCE { 444 request-id 1414684022, 445 non-repeaters 1, 446 max-repetitions 2, 447 variable-bindings { 448 { name sysUpTime, 449 value { unspecified NULL } }, 450 { name ipNetToMediaPhysAddress, 451 value { unspecified NULL } }, 452 { name ipNetToMediaType, 453 value { unspecified NULL } } 454 } 455 } 457 Applying the BER, this would be encoded (in hexadecimal) as: 459 [5] IMPLICIT SEQUENCE a5 82 00 39 460 INTEGER 02 04 52 54 5d 76 461 INTEGER 02 01 01 462 INTEGER 02 01 02 463 SEQUENCE 30 2b 464 SEQUENCE 30 0b 465 OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03 466 NULL 05 00 467 SEQUENCE 30 0d 468 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02 469 NULL 05 00 470 SEQUENCE 30 0d 471 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 472 NULL 05 00 474 Note that the initial SEQUENCE is not encoded using the minimum number 475 of length octets. (The first octet of the length, 82, indicates that 476 the length of the content is encoded in the next two octets.) 477 9. Acknowledgements 479 This document is the result of significant work by the four major 480 contributors: 482 Jeffrey Case (SNMP Research, case@snmp.com) 483 Keith McCloghrie (Cisco Systems, kzm@cisco.com) 484 Marshall Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) 485 Steven Waldbusser (International Network Services, stevew@uni.ins.com) 487 In addition, the contributions of the SNMPv2 Working Group are 488 acknowledged. In particular, a special thanks is extended for the 489 contributions of: 491 Alexander I. Alten (Novell) 492 Dave Arneson (Cabletron) 493 Uri Blumenthal (IBM) 494 Doug Book (Chipcom) 495 Kim Curran (Bell-Northern Research) 496 Jim Galvin (Trusted Information Systems) 497 Maria Greene (Ascom Timeplex) 498 Iain Hanson (Digital) 499 Dave Harrington (Cabletron) 500 Nguyen Hien (IBM) 501 Jeff Johnson (Cisco Systems) 502 Michael Kornegay (Object Quest) 503 Deirdre Kostick (AT&T Bell Labs) 504 David Levi (SNMP Research) 505 Daniel Mahoney (Cabletron) 506 Bob Natale (ACE*COMM) 507 Brian O'Keefe (Hewlett Packard) 508 Andrew Pearson (SNMP Research) 509 Dave Perkins (Peer Networks) 510 Randy Presuhn (Peer Networks) 511 Aleksey Romanov (Quality Quorum) 512 Shawn Routhier (Epilogue) 513 Jon Saperia (BGS Systems) 514 Bob Stewart (Cisco Systems, bstewart@cisco.com), chair 515 Kaj Tesink (Bellcore) 516 Glenn Waters (Bell-Northern Research) 517 Bert Wijnen (IBM) 519 10. References 521 [1] McCloghrie, K., Editor, | 522 "Protocol Operations for Version 2 of the Simple Network Management 523 Protocol (SNMPv2)", Internet Draft, Cisco Systems, September 1995. | 525 [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 526 USC/Information Sciences Institute, August 1980. 528 [3] Information processing systems - Open Systems Interconnection - 529 Transport Service Definition, International Organization for 530 Standardization. International Standard 8072, (June, 1986). 532 [4] Information processing systems - Open Systems Interconnection - 533 Transport Service Definition - Addendum 1: Connectionless-mode 534 Transmission, International Organization for Standardization. 535 International Standard 8072/AD 1, (December, 1986). 537 [5] G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk (second 538 edition). Addison-Wesley, 1990. 540 [6] Waldbusser, S., "AppleTalk Management Information Base", RFC 1243, 541 Carnegie Mellon University, July 1991. 543 [7] Network System Technical Interface Overview. Novell, Inc, (June, 544 1989). 546 [8] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network 547 Management Protocol", STD 15, RFC 1157, SNMP Research, Performance 548 Systems International, MIT Laboratory for Computer Science, May 549 1990. 551 [9] McCloghrie, K., Editor, | 552 "Coexistence between Version 1 and Version 2 of the Internet- 553 standard Network Management Framework", Internet Draft, Cisco | 554 Systems, September 1995. | 556 [10] Information processing systems - Open Systems Interconnection - 557 Specification of Basic Encoding Rules for Abstract Syntax Notation 558 One (ASN.1), International Organization for Standardization. 559 International Standard 8825, December 1987. 561 [11] McCloghrie, K., Editor, "Introduction to Version 2 of the + 562 Internet-standard Network Management Framework", Internet Draft, + 563 Cisco Systems, September 1995. + 565 11. Security Considerations 567 Security issues are not discussed in this memo. 569 12. Editor's Address 571 Keith McCloghrie - 572 Cisco Systems, Inc. 573 170 West Tasman Drive 574 San Jose, CA 95134-1706 575 US 577 Phone: +1 408 526 5260 578 Email: kzm@cisco.com 580 Table of Contents - 582 1 Introduction .................................................... 2 583 1.1 A Note on Terminology ......................................... 2 584 2 Definitions ..................................................... 3 585 3 SNMPv2 over UDP ................................................. 7 586 3.1 Serialization ................................................. 7 587 3.2 Well-known Values ............................................. 7 588 4 SNMPv2 over OSI ................................................. 8 589 4.1 Serialization ................................................. 8 590 4.2 Well-known Values ............................................. 8 591 5 SNMPv2 over DDP ................................................. 9 592 5.1 Serialization ................................................. 9 593 5.2 Well-known Values ............................................. 9 594 5.3 Discussion of AppleTalk Addressing ............................ 9 595 5.3.1 How to Acquire NBP names .................................... 10 596 5.3.2 When to Turn NBP names into DDP addresses ................... 10 597 5.3.3 How to Turn NBP names into DDP addresses .................... 11 598 5.3.4 What if NBP is broken ....................................... 11 599 6 SNMPv2 over IPX ................................................. 13 600 6.1 Serialization ................................................. 13 601 6.2 Well-known Values ............................................. 13 602 7 Proxy to SNMPv1 ................................................. 14 603 8 Serialization using the Basic Encoding Rules .................... 15 604 8.1 Usage Example ................................................. 16 605 9 Acknowledgements ................................................ 17 606 10 References ..................................................... 18 607 11 Security Considerations ........................................ 19 608 12 Editor's Address ............................................... 19