SNMP over AppleTalk
RFC 1419

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                       G. Minshall
Request for Comments: 1419                                 Novell, Inc.
                                                              M. Ritter
                                                   Apple Computer, Inc.
                                                             March 1993

                          SNMP over AppleTalk

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Introduction

   This memo describes the method by which the Simple Network Management
   Protocol (SNMP) as specified in [1] can be used over AppleTalk
   protocols [2] instead of the Internet UDP/IP protocol stack.  This
   specification is useful for network elements which have AppleTalk
   support but lack TCP/IP support.  It should be noted that if  a
   network element supports multiple protocol stacks, and UDP is
   available, it is the preferred network layer to use.

   SNMP has been successful in managing Internet capable network
   elements which support the protocol stack at least through UDP, the
   connectionless Internet transport layer protocol.  As originally
   designed, SNMP is capable of running over any reasonable transport
   mechanism (not necessarily a transport protocol) that supports bi-
   directional flow and addressability.

   Many non-Internet capable network elements are present in networks.
   Some of these elements are equipped with the AppleTalk protocols.
   One method of using SNMP to manage these elements is to define a
   method of transmitting an SNMP message inside an AppleTalk protocol
   data unit.

   This RFC is the product of the SNMP over a Multi-protocol Internet
   Working Group of the Internet Engineering Task Force (IETF).

1. Background

   The AppleTalk equivalent of UDP (and IP) is DDP (Datagram Delivery
   Protocol).  The header field of a DDP datagram includes (at least
   conceptually) source and destination network numbers, source and

Minshall & Ritter                                               [Page 1]
RFC 1419                  SNMP over AppleTalk                 March 1993

   destination node numbers, and source and destination socket numbers.
   Additionally, DDP datagrams include a "protocol type" in the header
   field which may be used to further demultiplex packets.  The data
   portion of a DDP datagram may contain from zero to 586 octets.

   AppleTalk's Name Binding Protocol (NBP) is a distributed name-to-
   address mapping protocol.  NBP names are logically of the form
   "object:type@zone", where "zone" is determined, loosely, by the
   network on which the named entity resides; "type" is the kind of
   entity being named; and "object" is any string which causes
   "object:type@zone" to be unique in the AppleTalk internet.
   Generally, "object" also helps an end-user determine which instance
   of a specific type of service is being accessed.  NBP names are not
   case sensitive.  Each field of the NBP name ("object", "type", and
   "zone") is  limited to 32 octets.  The octets usually consist of
   human-readable ascii characters.

2. Specification

   SNMP REQUESTS encapsulated according to this standard will be sent to
   DDP socket number 8; they will contain a DDP protocol type of 8.  The
   data octets of the DDP datagram will be a standard SNMP message as
   defined in [1].

   SNMP RESPONSES encapsulated according to this standard will be sent
   to the DDP socket number which originated the corresponding SNMP
   request; they will contain a DDP protocol type of 8.  The data octets
   of the DDP datagram will be a standard SNMP message as defined in
   [1].  (Note:  as stated in [1], section 4.1, the *source* address of
   a RESPONSE PDU will be the same as the *destination* address of the
   corresponding REQUEST PDU.)

   A network element which is capable of responding to SNMP REQUESTS
   over AppleTalk must advertise this capability via the AppleTalk Name
   Binding Protocol using an NBP type of "SNMP Agent" (hex 53, 4E, 4D,
   50, 20, 41,  67, 65, 6E, 74).

   A network management station which is capable of receiving an SNMP
   TRAP must advertise this capability via the AppleTalk Name Binding
   Protocol using an NBP type of "SNMP Trap Handler" (hex 53, 4E, 4D,
   50, 20, 54, 72, 61, 70, 20, 48, 61, 6E, 64, 6C, 65, 72).

   SNMP TRAPS encapsulated according to this standard will be sent to
   DDP socket number 9; they will contain a DDP protocol type of 8.  The
   data octets of the DDP datagram will be a standard SNMP message as
   defined in [1].  The agent-addr field of the Trap-PDU must be filled
   with a NetworkAddress of all zeros (the unknown IP address). Thus, to