idnits 2.17.1 draft-ietf-mpsnmp-appletalk-02.txt: ** The Status of Memo section seems to be numbered 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-26) 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. ** 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. ** Missing revision: the document name given in the document, 'draft-ietf-mpsnmp-appletalk', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-mpsnmp-appletalk', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-mpsnmp-appletalk', but the file name used is 'draft-ietf-mpsnmp-appletalk-02' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 369 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations 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 143 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 44 has weird spacing: '...that if a net...' == Line 74 has weird spacing: '...ne") is limit...' -- 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 (22 January 1993) is 11417 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) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1243 (ref. '3') (Obsoleted by RFC 1742) ** Obsolete normative reference: RFC 1089 (ref. '4') (Obsoleted by RFC 4789) ** Obsolete normative reference: RFC 1298 (ref. '5') (Obsoleted by RFC 1420) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 17 errors (**), 1 flaw (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Minshall & Ritter IETF Draft: SNMP over AppleTalk expires 22 January 1993 3 SNMP over a Multi-protocol Internet Working Group 4 Internet Draft: draft-ietf-mpsnmp-appletalk 6 Greg Minshall 7 Novell, Inc. 8 Mike Ritter 9 Apple Computer, Inc. 11 22 July 1992 (version 2.5) 13 SNMP over AppleTalk 15 1. Status of This Memo 17 This document is an Internet Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted 24 by other documents at any time. It is not appropriate to use 25 Internet Drafts as reference material or to cite them other than 26 as a "working draft" or "work in progress." 28 Please check the I-D abstract listing contained in each Internet 29 Draft directory to learn the current status of this or any 30 other Internet Draft. 32 This draft document is being circulated for comment. The changes recommended 33 by consensus in the IETF's "SNMP over a Multi-protocol Internet" working 34 group are incorporated, and after review it will be submitted to the RFC editor 35 as a Proposed Standard protocol specification. Distribution of this memo is 36 unlimited. 38 2. Introduction 40 This memo describes the method by which the Simple Network Management Protocol 41 (SNMP) as specified in [1] can be used over AppleTalk protocols [2] instead of 42 the Internet UDP/IP protocol stack. This specification is useful for network 43 elements which have AppleTalk support but lack TCP/IP support. It should be 44 noted that if a network element supports multiple protocol stacks, and UDP is 45 available, it is the preferred network layer to use. 47 SNMP has been successful in managing Internet capable network elements which 48 support the protocol stack at least through UDP, the connectionless Internet 49 transport layer protocol. As originally designed, SNMP is capable of running 50 over any reasonable transport mechanism (not necessarily a transport protocol) 51 that supports bi-directional flow and addressability. 53 Many non-Internet capable network elements are present in networks. Some of 54 these elements are equipped with the AppleTalk protocols. One method of using 55 SNMP to manage these elements is to define a method of transmitting an SNMP 56 message inside an AppleTalk protocol data unit. 58 3. Background 60 The AppleTalk equivalent of UDP (and IP) is DDP (Datagram Delivery Protocol). 61 The header field of a DDP datagram includes (at least conceptually) source and 62 destination network numbers, source and destination node numbers, and source 63 and destination socket numbers. Additionally, DDP datagrams include a "protocol 64 type" in the header field which may be used to further demultiplex packets. 65 The data portion of a DDP datagram may contain from zero to 586 octets. 67 AppleTalk's Name Binding Protocol (NBP) is a distributed name-to-address 68 mapping protocol. NBP names are logically of the form "object:type@zone", 69 where "zone" is determined, loosely, by the network on which the named entity 70 resides; "type" is the kind of entity being named; and "object" is any string 71 which causes "object:type@zone" to be unique in the AppleTalk internet. 72 Generally, "object" also helps an end-user determine which instance of a 73 specific type of service is being accessed. NBP names are not case sensitive. 74 Each field of the NBP name ("object", "type", and "zone") is limited to 32 75 octets. The octets usually consist of human-readable ascii characters. 77 4. Specification 79 SNMP REQUESTS encapsulated according to this standard will be sent to DDP 80 socket number 8; they will contain a DDP protocol type of 8. The data octets 81 of the DDP datagram will be a standard SNMP message as defined in [1]. 83 SNMP RESPONSES encapsulated according to this standard will be sent to the DDP 84 socket number which originated the corresponding SNMP request; they will 85 contain a DDP protocol type of 8. The data octets of the DDP datagram will be 86 a standard SNMP message as defined in [1]. (Note: as stated in [1], section 87 4.1, the *source* address of a RESPONSE PDU will be the same as the 88 *destination* address of the corresponding REQUEST PDU.) 90 A network element which is capable of responding to SNMP REQUESTS over 91 AppleTalk must advertise this capability via the AppleTalk Name Binding 92 Protocol using an NBP type of "SNMP Agent" (hex 53, 4E, 4D, 50, 20, 41, 67, 93 65, 6E, 74). 95 A network management station which is capable of receiving an SNMP TRAP must 96 advertise this capability via the AppleTalk Name Binding Protocol using an NBP 97 type of "SNMP Trap Handler" (hex 53, 4E, 4D, 50, 20, 54, 72, 61, 70, 20, 48, 98 61, 6E, 64, 6C, 65, 72). 100 SNMP TRAPS encapsulated according to this standard will be sent to DDP socket 101 number 9; they will contain a DDP protocol type of 8. The data octets of the 102 DDP datagram will be a standard SNMP message as defined in [1]. The agent-addr 103 field of the Trap-PDU must be filled with a NetworkAddress of all zeros (the 104 unknown IP address). Thus, to identify the trap sender, the name and value of 105 the nbpObject and nbpZone corresponding to the nbpEntry with the nbpType equal 106 to "SNMP Agent" should be included in the variable-bindings of any trap that is 107 sent [3]. 109 The NBP name for both an agent and a trap handler should be stable - it should 110 not change any more often than the IP address of a typical TCP/IP end system 111 changes. It is suggested that the NBP name be stored in some form of stable 112 storage (PRAM, local disk, etc.). 114 6. Discussion of AppleTalk Addressing 116 6.1 Introduction 118 The AppleTalk protocol suite has certain features not manifest in the standard 119 TCP/IP suite. Its unique naming strategy and the dynamic nature of address 120 assignment can cause problems for SNMP management stations that wish to manage 121 AppleTalk networks. TCP/IP end nodes, as of this writing, have an associated 122 IP address which distinguishes each from the other. AppleTalk end nodes, in 123 general, have no such characteristic. The network level address, while often 124 relatively stable, can change at every reboot (or more frequently). 126 Thus, a thrust of this proposal is that a "name" (as opposed to an "address") 127 for an end system be used as the identifying attribute. This is the 128 equivalent, when dealing with TCP/IP end nodes, of using the domain name. 129 While the mapping (DNS name, IP address) is more stable than the mapping (NBP 130 name, DDP address), the mapping (DNS name, IP address) is not required to exist 131 (eg, hosts with no host name, only an IP address). In contrast, all AppleTalk 132 nodes that implement this specification are required to respond to NBP lookups 133 and confirms (eg., implement the NBP protocol stub), which guarantees that the 134 mapping (NBP name, DDP address) will exist. 136 In determining the SNMP name to register for an agent, it is suggested that the 137 SNMP name be a name which is associated with other network services offered by 138 the machine. On a Macintosh system, for example, it is suggested that the 139 system name (the "Macintosh Name" for System 7.0 which is used to advertise 140 file sharing, program-to-program communication, and possibly other services) be 141 used as the "object" field of the NBP name. This name has AppleTalk 142 significance, and is tightly bound to the network's concept of a given system's 143 identity. 145 NBP lookups, which are used to turn NBP names into DDP addresses, can cause 146 large amounts of network traffic as well as consume CPU resources. It is also 147 the case that the ability to perform an NBP lookup is sensitive to certain 148 network disruptions (such as zone table inconsistencies, etc.) which would not 149 prevent direct AppleTalk communications between a management station and an 150 agent. 152 Thus, it is recommended that NBP lookups be used infrequently with the primary 153 purpose being to create a cache of name-to-address mappings. These cached 154 mappings should then be used for any further SNMP requests. It is recommended 155 that SNMP management stations maintain this cache between reboots. This 156 caching can help minimize network traffic, reduce CPU load on the network, and 157 allow for (some amount of) network trouble shooting when the basic 158 name-to-address translation mechanism is broken. 160 6.2 How To Acquire NBP names: 162 A management station may have a pre-configured list of names of agents to 163 manage. A management station may allow for an interaction with an operator in 164 which a list of manageable agents is acquired (via NBP) and presented for the 165 operator to choose which agents should be managed by that management station. 166 Finally, a management station may manage all manageable agents in a set of 167 zones or networks. 169 An agent must be configured with the name of a specific management station or 170 group of management stations before sending SNMP traps. In the absence of any 171 such configured information, an agent is NOT to generate any SNMP traps. In 172 particular, an agent is NEVER to initiate a wildcard NBP lookup to find a 173 management station to receive a trap. All NBP lookups generated by an agent 174 must be fully specified. Note, however, that this does not apply to a 175 configuration utility that might be associated with such an agent. Such a 176 utility may well allow a user to navigate around the network to select a 177 management station or stations to receive SNMP traps from the agent. 179 6.3 When To Turn NBP Names Into Addresses: 181 When SNMP agents or management stations use a cache entry to address an SNMP 182 packet, they should attempt to confirm the mapping if it hasn't been confirmed 183 in T1 seconds. This cache entry lifetime, T1, has a minimum, default value of 184 60 seconds. This value should be configurable. 186 A management station may decide to prime its cache of names prior to actually 187 sending any SNMP requests to any given agent. In general, it is expected that 188 a management station may want to keep certain mappings "more current" than 189 other mappings. In particular, those nodes which represent the network 190 infrastructure (routers, etc.) may be deemed "more important" by the management 191 station. 193 Note, however, that a long-running management station starting up and reading a 194 configuration file containing a number of NBP names should not attempt to prime 195 its cache all at once. It should, instead, issue the resolutions over an 196 extended period of time (perhaps in some pre-determined or configured priority 197 order). Each resolution might, in fact, be a wildcard lookup in a given zone. 199 An agent should NEVER prime its cache. It should do NBP lookups (or confirms) 200 only when it needs to send an SNMP trap to a given management station. An 201 agent does not need to confirm a cache entry to reply to a request. 203 6.4 How To Turn NBP Names Into Addresses: 205 If the only piece of information available is the NBP name, then an NBP lookup 206 should be performed to turn that name into a DDP address. 208 However, if there is a piece of stale information, it can be used as a hint to 209 perform an NBP confirm (which sends a unicast to the network address which is 210 presumed to be the target of the name lookup) to see if the stale information 211 is, in fact, still valid. 213 An NBP name to DDP address mapping can also be confirmed implicitly using only 214 SNMP transactions. If a management station is sending a get-request, it can 215 add a request, in the same packet, for the destination's nbpObject and nbpZone 216 corresponding to the nbpEntry with the nbpType equal to "SNMP Agent" [3]. 217 The source DDP address can be gleaned from the reply and used with the 218 nbpObject and nbpZone returned to confirm the cache entry. 220 The above notwithstanding, for set-requests, there is a race condition that can 221 occur where an SNMP request may go to the wrong agent (because the old node 222 went down and a new node came up with the same DDP address.) This is 223 problematic becase the wrong agent might generate a response packet that the 224 management station could not distinguish from a reply from the intended agent. 225 In the future, when SNMP security is implemented, each packet is authenticated 226 at the destination, and the reply should implicitly confirm the validity of the 227 cache entry used and prevent this race condition. 229 6.5 What if NBP is broken: 231 Under some circumstances, there may be connectivity between a management 232 station and an agent, but the NBP machinery required to turn an NBP name into a 233 DDP address may be broken. Examples of failures which would cause this 234 include: NBP FwdReq (forward NBP lookup onto locally attached network) broken 235 at a router on the network containing the agent; NBP BrRq (NBP broadcast 236 request) mechanism broken at a router on the network containing the managment 237 station (because of a zone table mis-configuration, for example); or NBP broken 238 in the target node. 240 A management station which is dedicated to AppleTalk management might choose to 241 alleviate some of these failures by implementing the router portion of NBP 242 within the management station itself. For example, the management station 243 might already know all the zones on the AppleTalk internet and the networks on 244 which each zone appears. Given an NBP lookup which fails, the management 245 station could send an NBP FwdReq to the network in which the agent was last 246 located. If that failed, the station could then send an NBP LkUp (an NBP 247 lookup packet) as a directed (DDP) multicast to each network number on that 248 network. Of the above (single) failures, this combined approach will solve the 249 case where either the local router's BrRq to NBP FwdReq mechanism is broken or 250 the remote router's NBP FwdReq to NBP LkUp mechanism is broken. 252 6.6 How to Represent NBP Names in MIBs 254 There are occasions when it is necessary to represent a transport 255 service address in a MIB. For instance, the SNMP party MIB [6] uses 256 an OBJECT IDENTIFIER to define the transport domain (IP, AppleTalk, etc.) 257 and an OCTET STRING to represent an address within that domain. The 258 following definitions are provided for use in such a scheme. 260 RFC-yyyy DEFINITIONS ::= BEGIN 262 IMPORTS 263 experimental 264 FROM RFC1155-SMI; 266 snmpOverAppleTalk 267 OBJECT IDENTIFIER ::= { experimental xx } -- xx TBD -- 269 snmpOverAppleTalkDomain 270 OBJECT IDENTIFIER ::= { snmpOverAppleTalk 1} 272 -- An ATAddress is an octet string with a maximum length of 99 octets. The 273 -- layout of an NBP name as an ATaddress is similar to a `packed Pascal string' 274 -- format: It consists of six fields: three length fields a single octet 275 -- long, and three fields, up to thirty-two octets in length each, in the 276 -- following order: length field, object field, length field, type field, 277 -- length field, zone field. The layout of the octet string for the ATAddress 278 -- of an SNMP Agent on the machine named `theDragon' in the zone 279 -- `DA3/Nets-R-Us' would be: 280 -- 0x09`theDragon'0x0A`SNMP Agent'0x0D`DA3/Nets-R-Us', 281 -- where 0xNN implies a length octet in hexidecimal and the quoted strings 282 -- represent ascii characters. The object, type, and zone fields may contain 283 -- any octet except 0xFF and are case-insensitive [3]. 284 -- 285 -- When devices are installed, they need to be configured with an 286 -- initial set of SNMP parties. The configuration of SNMP parties 287 -- requires (among other things) the assignment of several OBJECT 288 -- IDENTIFIERs. Any local network administration can obtain the 289 -- delegated authority necessary to assign its own OBJECT IDENTIFIERs. 290 -- However, to cater for those administrations who have not obtained 291 -- the necessary authority, this document allocates a branch of the 292 -- naming tree for use with the following conventions. 294 initialAppleTalkPartyId OBJECT IDENTIFIER ::= 295 { snmpOverAppleTalk 2 } 297 -- This prefix is used in an analogous fashion as 298 -- 299 -- initialPartyId 300 -- 301 -- as defined in [6]. For an SNMP protocol entity residing at 302 -- AppleTalk transport address 'N', the identities of its six initial 303 -- parties are formed by appending a subidentifier for each octet in the 304 -- AppleTalk TransportAddress, to 305 -- 306 -- initialAppleTalkPartyId 307 -- 308 END 310 7. Acknowledgements 312 Some of the boilerplate in this memo is copied from [4], [5], and [7]. The 313 Apple-IP Working Group was instrumental in defining this document. 314 Their support and work was greatly appreciated. 316 8. References 318 [1] Case, J., M. Fedor, M. Schoffstall, M., and J. Davin, "A Simple Network 319 Management Protocol (SNMP)", RFC 1157, May 1990. 321 [2] Sidhu, G., R. Andrews, and A. Oppenheimer, "Inside AppleTalk (Second 322 Edition)", Addison-Wesley, 1990. 324 [3] Waldbusser, Steven, "AppleTalk Management Information Base", RFC 1243, 325 August 1991. 327 [4] Schoffstall, M., C. Davin, M. Fedor, and J. Case, "SNMP over Ethernet", RFC 328 1089, February 1989. 330 [5] Bostock , Steve, "SNMP over IPX" (draft to replace RFC 1298) 332 [6] McCloghrie, K., Davin, J., and J. Galvin, "Definitions of Managed Objects 333 for Administration of SNMP Parties", RFC in preparation. 335 [7] Piscitello, Dave, "Guidelines for the Specification of Protocol Support of 336 the SNMP", RFC in preparation. 338 10. Authors' Addresses 340 Greg Minshall 341 Novell, Inc. 342 1340 Treat Blvd, ste. 500 343 Walnut Creek, CA 94596 345 Phone: 510 947-0998 346 Fax: 510 947-1238 347 EMail: minshall@wc.novell.com 349 Mike Ritter 350 Apple Computer, Inc. 351 10500 North De Anza Boulevard, MS: 35-K 352 Cupertino, California 95014 354 Phone: 408 862-8088 355 Fax: 408 862-1159 356 EMail: MWRITTER@applelink.apple.com 358 Minshall & Ritter IETF Draft: SNMP over AppleTalk expires 22 January 1993