Internet Area John Veizades Internet-Draft Apple Computer, Inc. February 1991 A Standard for the Transmission of Internet Packets Over AppleTalk Networks Introduction This document describes a protocol, called MacIP, that is used to transport IP datagrams on AppleTalk networks. This protocol was developed in order to connect Macintosh computers on AppleTalk networks to hosts on TCP/IP networks. Using the AppleTalk network layer protocol, IP datagrams can be transmitted through AppleTalk networks to gateways that decapsulate the IP datagrams and act as front-end protocol processors Macintosh hosts on AppleTalk internets This protocol is elective but is required by all hosts that need to encapsulate IP datagrams over AppleTalk networks. Macintosh computers historically have been equipped with a built-in network connector to LocalTalk, AppleUs medium speed network specification, and software that implements the AppleTalk protocols. To enable AppleTalk clients to connect to the Internet, software was written that encapsulates IP datagrams in DDP packets (the Datagram Delivery Protocol, DDP, is AppleTalkUs network layer protocol). Gateways were designed to forward these encapsulated packets from AppleTalk to Ethernet networks. The protocol that was used to accomplish these tasks was documented in the code and placed in the public domain. Several developers have made this functionality commercially available. Terminology Some of the AppleTalk terms that will be used in this document are described below. Refer to [1] for more comprehensive explanations. Name Binding Protocol (NBP) Q The transport-level protocol that translates a character string name into the internet address of the corresponding socket client. Apple Transaction Protocol (ATP) Q A transport protocol that ensures the loss- free delivery of DDP client packets from source to destination. Datagram Delivery Protocol (DDP) Q The network-layer protocol that is responsible for the socket-to-socket deliver of datagrams over an AppleTalk internet. MacIP - A method for encapsulation of IP packets in AppleTalk DDP for transport on AppleTalk internets, as well as related services such as address assignment. Veizades [Page 1] Internet Draft MacIP February 1991 Architecture MacIP provides three services: 1) it assigns and allocates IP addresses for hosts in an AppleTalk internet, and 2) it allows for the tunneling of IP datagrams from an AppleTalk internet to a TCP/IP internet 3) it proxy ARPs for AppleTalk supported hosts on the IP internet. The first service was developed because a TCP/IP node that is embedded in an AppleTalk network could not participate in the details required to be a fullfledged IP citizen. Specifically, it could not respond to ARP requests for its IP address. A gateway acts on behalf of the imbedded IP node and responds to ARP requests with the machineUs hardware address, much like proxy ARP. This method differs from proxy ARP in that the gateway has prior knowledge of the hosts IP address through the address allocation protocol. The AppleTalk host finds the gateway that is supporting its connection and either registers its IP address with the gateway or asks the gateway to allocate an IP address for its use out of the gateways cache of IP addresses. Once a host has acquired an IP address and is communicating with its gateway, the second service provided by this protocol comes into play. Datagrams that are destined to some IP host in the IP Internet are encapsulated in DDP and sent to the gateway for delivery to the IP Internet. The gateway strips the DDP encapsulation and retransmits the datagram using the encapsulatation method of its attached IP network. The MacIP protocol uses three AppleTalk protocols. NBP to register, confirm, and finds network entities; ATP to acquire and transmit gateway information; and DDP to transmit datagrams in AppleTalk networks. NBP is essentially a broadcast-based resource location protocol which translates resources named with ASCII strings. The MacIP protocol uses NBP to find the protocol gateway and to respond to address queries in a fashion similar to ARP. ATP is used by MacIP to obtain IP specific information from the protocol gateway to the waiting end system. ATP is used much like BootP to acquire DNS, gateways, and broadcast addresses. DDP is the packet transmission protocol for AppleTalk. Once the protocol gateway has been found by the end host, DDP is used to transport encapsulated IP packets. Veizades [Page 2] Internet Draft MacIP February 1991 Protocol Details - NBP The gateway host acts as a protocol translator, taking IP packets encapsulated in DDP and placing them on the IP media in the standard media encapsulation. It also acts as a configuration server, giving out configuration information to requesting hosts. The configuration process starts with the host registering itself on the connected AppleTalk network using NBP. NBP has a provision for registering service providers on a network. The gateway registers itself as a Network Visible Entity (NVE) of type "IPGATEWAY." This allows hosts needing the services provided by the gateway to discover the gateway using NBP. NBP lookups are made by specifying the zone name and type of the entity being searched for. The type of a MacIP gateway is "IPGATEWAY". The zone can be specified in one of two ways: - if the AppleTalk network consists of only one zone then the zone field should be set to R*S. - if there is more than one zone in the AppleTalk network the zone name of where the MacIP gateway is being searched for should be specified (the list of zones can be acquired using the GetZoneList call which is part of the Zone Information Protocol [ZIP]). The object name should be set to "=" meaning that any service provider will be accepted. The gateways respond by placing the ASCII representation of its IP address in the object name field and filling out the appropriate AppleTalk network number, node ID, and socket number. Once a host connected to an AppleTalk network has acquired an IP address, it registers itself using NBP with a NVE of type IPADDRESS and with an object name of its IP address in ASCII representation. The host responds to NBP queries for its object name, that is, it provides its IP address. This is NBP ARP. After a host acquires an IP address it queries the network for entities with the same IP address, verifying that it is the sole user of this address. MacIP gateways can be used from outside the zone in which they are registered since a host can do a directed NBP request into a zone. Since NBP queries are zone specific and an IP address can only be unique in the zone specified, it is possible for an indentical IP address to exist in another zone. This is an administrative issue since the protocol cannot prevent this from occurring. A gateway sends an NBP confirms to verify the continued accessibility of a configured host. If a host does not respond to an NBP confirm Veizades [Page 3] Internet Draft MacIP February 1991 after some interval (recommended to be 5 minutes and to be adjustable by the network administrator) the address mapping is discarded and the IP address can be reused. If a host cannot respond to NBP confirms for some period of time it should assume that the AppleTalk to IP address binding is no longer valid and it should reinitialize itself. All object names, entity types and zone names are specified as 8-bit ASCII strings as specified in Appendix D of Inside AppleTalk. Protocol Details - ATP To acquire configuration information the AppleTalk Transaction Protocol (ATP) is used. Once a MacIP gateway is discovered, the host can query the gateway for configuration information. The format of an ATP packet is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Data Link Header / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / DDP Header (DDP) / | | - -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A | Control Info | Sequence # | Transaction ID | / b T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/u y P | Mac IP Version number | always zero | s t - -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r e | Request Code | \ s +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address (only for STATIC and RELEASE) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first word of the user bytes field of the ATP header is the MacIP protocol version number. The protocol defined in this document is version 1. Previous versions all have the value 0. There are several requests that an end host can make of a gateway. The type of request is set by specifying the appropriate request code. The following are the allowable requests: ASSIGN 1 Ask the server to assign an IP address NAME 2 Obsolete SERVER 3 Get server information Veizades [Page 4] Internet Draft MacIP February 1991 RELEASE 4 Notify the server that the hosts IP address is no longer in use STATIC 5 Notify the server of the use of a statically assigned IP address The RELEASE and STATIC request are extensions to this protocol. A server, upon reception of an ATP at least once request, returns the following packet: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ATP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DNS Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Broadcast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused Always Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subnet Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused Always Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused Always Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused Always Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128 byte error message or response code = -1 zero terminated | / / / otherwise / / / | Domain Name Extension | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The response code can have one of two values: either it is equal to the value of the corresponding request code or it is a negative number when interpreted as a 32-bit signed number. When an error is encountered the packet may contain an error message of up to 128 characters (The error string is terminated by a byte of value zero.) Veizades [Page 5] Internet Draft MacIP February 1991 The following is a list of errors returned by the MacIP gateway: -1 some error occur look at error string for more details -2 command out of range -3 no addresses available -4 address already assigned -5 address not currently assigned to you Packets that are returned without error have the following semantics. For responses to requests of type ASSIGN, the IP address field will contain the hostUs assigned IP address. None of the other fields have defined semantics. For responses to requests of type SERVER, the name server field will contain the address of the default domain name server. The broadcast address will contain the broadcast address for the network and the file server address . All the other addresses are undefined and will always contain the null address 0.0.0.0. until defined bt a later protocol definition. The RELEASE and STATIC ATP requests contain the IP address being released or being used in the long word after the request code. There is no MacIP response to a RELEASE packet. A response packet maybe sent in response to a STATIC request indicating that the gateway is willing to respond for that address. The format of the STATIC response is identical to the IP address assignment response. Operational Details In an AppleTalk network, an IP address can be assigned in two ways. The server can assign addresses using the ATP protocol specified above or an administrator can assign addresses. These address assignment techniques can take place in concert on an internet. The address assigned by the server must not overlap the addresses assigned by the administrator. Addresses assigned by the server are assigned out of a range of addresses that has been allocated to the server. Addresses assigned by the server may or may not be assigned to the same host for each assignment request that the host makes; these addresses are called dynamic addresses. A host must not cache any of its assignment information from a previous assignment since the uniqueness of an IP address assignment cannot be guaranteed without the hostUs ability to defend this address. Hosts addresses may also be assigned statically. When a host uses a statically assigned address it sends out an NBP query to find its gateway and then issues an ATP request of type STATIC this allows the gateway to record Veizades [Page 6] Internet Draft MacIP February 1991 information as to who is using the statically assigned address. Hosts that try to register themselves with a static address that is already in use should receive the "address not currently assigned to you" message from the gateway. When a gateway is brought on line, either after it has been shutdown or when it is being brought on line for the first time, it must send out a NBP query specifying R=S as the object identifier and IPADDRESS as the object type to all its connected zones. This will allow the gateway to acquire address mapping (AppleTalk node ID to IP addresses) for all hosts that have already been initialized. Protocol Details - DDP Once a host has been properly configured, it can begin operating as an IP host in an Appletalk network. IP packets are transmitted on an AppleTalk network by first deciding what the destination address is using NBP ARP, and then transmitting the IP packet in its DDP wrapper. A host can either send an IP packet directly or through a gateway to the IP host with which it is communicating. When sending a packet, the host issues an NBP ARP request for the host with which it wishes to communicate. Either the host itself responds to the query or the gateway responds. Packets are then sent to the host or the gateway using DDP, encapsulating the full IP packet as the DDP data and using the DDP packet type of 22 (decimal) and port number 72 (decimal). The above holds true for packets transmitted by the gateway to the waiting host Gateways should send ICMP error messages when appropriate [4]. DDP limits the data size of a DDP packet to 586 bytes. This is the MTU for IP datagrams encapsulated in AppleTalk internets. Other networking medias have larger MTUs. The smaller MTU size of AppleTalk implies that gateways must fragment packets bound for AppleTalk network which are larger than the AppleTalk MTU [3]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Layer Header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Layer Header (DDP) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Header | / / IP Packet Encapsulated in DDP Packet Veizades [Page 7] Internet Draft MacIP February 1991 A Sample Transaction Stream Below is a sample transaction stream designed to illustrate the use of the gateway, ATP, and NBP to perform the ARP function on AppleTalk. Overview: An AppleTalk host wishes to find a MacIP gateway, obtain an IP address from that gateway, and open a TCP session with a host on Ethernet. AppleTalk Host Gateway Step 1 Perform NBP lookup for object Answers lookup with "=" (wildcard), type . object 90.70.0.1, the IPGATEWAY gatewayUs IP address. Step 2 Send gateway ATP Look in table of assigned transaction ASSIGN to addresses, using source gsteway AppleTalk address as key. If entry found, respond with previously assigned address. If no entry found, create new entry and assign new IP address. Respond. Step 3 Send gateway ATP transaction Respond with IP addresses as SERVER to gateway. configured. Step 4 Register assigned address as an NBP NVE, the object being the IP address in dot-notation with type IPADDRESS. Step 5 IP code wants to send TCP Respond to ARP for either SYN to IP address 136.25.2.4 gatewayUs IP address or proxy either default to 136.25.2.4 ARP for true destination as destination IP or decide address. that gateway is destination IP. Perform NBP ARP for destination address, type IPADDRESS. Step 6 Encapsulate TCP SYN in DDP Remove DDP header, add Ethernet packet and send to gateway. header, perform Ethernet ARP function, if appropriate, and send packet on Ethernet. Veizades [Page 8] Internet Draft MacIP February 1991 AppleTalk Host Gateway Step 6 (cont.) Destination host (136.25.2.4) responds with SYN. Remove Ethernet header, add DDP header, perform ARP function for destination address. Send DDP header. Step 7 When the host will no longer Remove the IP address from use the IP address the host the in uses list and allow it sends the gateway the ATP to be reassigned. transaction RELEASE. Step 6 is performed repeatedly. Veizades [Page 9] Internet Draft MacIP February 1991 AppleTalk Protocol Constants MacIP MTU 586 bytes DDP constants MacIP packet type 22(decimal) NBP constants gateway object type IPGATEWAY registered IP address object type IPADDRESS Gateway ATP Protocol Constants ATP request command codes ASSIGNQassign IP address 1 NAMEQname server 2 (obsolete) SERVERQget server info 3 RELEASEQrelease IP address 4 STATICQregister fixed address 5 ATP response codes SUCCESS same as request code ERROR -1 command out of range -2 no addresses available -3 address already assigned -4 address not currently assigned to you -5 References [1] Sidhu, G., Andrews, R., and Oppenheimer, A., Apple Computer, Inside AppleTalk, Addison-Wesley Publishing Company, Inc., Reading, MA, 1989. [2] Plummer, D., RAn Ethernet Address Resolution Protocol,S RFC-826, Symbolics, September 1982. [3] Postel J., RInternet Protocol,S RFC-791, USC Information Sciences Institute, September 1981. [4] Brandon, R., and Postel, J., RRequirements for Internet Gateways,S RFC-1009, USC Information Sciences Institute, June 1987. [5] Mogul, J., RInternet Subnets,S RFC-917, Stanford University, October 1984. [6] Mogul, J., and Postel, J., RInternet Standard Subnetting Procedure,S RFC-950, Stanford University, August 1985. Veizades [Page 10] Internet Draft MacIP February 1991 Acknowledgements Many people contributed to this document the author would like to acknowledge some of the primary contributors. Brad Parker and Josh Littlefield for writing a version of this protocol document. Greg Minshall for also putting down his thoughts on what this protocol should look like and giving the document a title. Bill Croft for getting us into all of this by first implementing the protocol in the Seagate box at Stanford University. Veizades [Page 11]