Internet Area Tom Evans Internet Draft Webster Computer Expires May 1993 Christopher Ranch Novell, Inc. November 1992 A Method for the Transmission of Internet Packets Over AppleTalk Networks [MacIP] Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id- abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract This Internet Draft describes an existing protocol for transporting IP packets over AppleTalk networks. It is intended to specify, standardize, and enhance existing implementations. Distribution of this memo is unlimited. This Internet Draft is a product of the Apple-IP Working Group of the Internet Engineering Task Force (IETF). Table of Contents (To be generated and inserted later) Overview There is much confusion over what MacIP really is, as it has grown by many small increments designed and implemented by at least as many people. There has been no central or formal design document, so each of the protocol additions and their effects are not well understood. We hope to dissect the anatomy of the current state of the art, and recommend a functional subset of the protocol features and a new Evans and Ranch November 11, 1992 Page 1 MacIP November 1992 gateway architecture that will help provide services to multiple zones more reliably. The MacIP protocol is used to transport IP packets across AppleTalk networks. There are many existing host and gateway implementations of this protocol, and most of them have many slight differences. We'll call the functional subset MacIP-1. It is our intention that it is compatible with as many of the current implementations as is practically possible. It also describes a set of existing features that will not work except in specific topologies. A future document, MacIP-2, will describe a protocol that provides the intended features, but does so for all AppleTalk topologies. The new proposed gateway architecture describes an Internal Virtual MacIP (VIM) , which requires a gateway to maintain an internal virtual network that has all zones that are supported in its zones list. This does not require any modifications on existing MacIP host implementations, and existing gateways will have a simple single- point modification. 1. Introduction The goal of the MacIP architecture is to provide TCP/IP services and connectivity to computers that are not directly connected to an IP network, but are connected indirectly via an AppleTalk network. Typically these are Apple Macintosh computers, but the use of MacIP is not restricted to them. IP hosts must be connected directly to appropriate media in order to communicate with other IP hosts or gateways. All Macintosh computers come equipped with LocalTalk, Apple Computer's medium speed network media. LocalTalk is not capable of carrying IP directly. Thus, MacIP gateways have been developed to provide IP front-end forwarding agents on behalf of IP hosts embedded in AppleTalk networks. It is recommended that hosts use this protocol only if they do not have a direct connection; that is their network media does not support IP. The details IP hosts directly connected to IP networks are covered in other well known RFCs. 1.1. Terminology and Topology In this document, the term "MacIP" refers to the encapsulation protocol and associated services. Specific parts of the protocol are given more specific names as appropriate. In a "MacIP internet" there are two distinct types of devices. Evans and Ranch November 11, 1992 Page 2 MacIP November 1992 The first are termed "MacIP hosts", and are usually Apple Macintosh computers. They are running applications over TCP/IP, and can use MacIP to communicate between themselves within the confines of their AppleTalk internet. When communication is desired with common IP devices on IP supported networks (hereafter called "IP hosts"), the services of the second MacIP device, a "MacIP gateway", is required. A MacIP gateway forwards IP datagrams between IP supported networks and MacIP devices on AppleTalk networks, as well as provides other server-type functions. The term "MacIP Packets" specifically refers to IP datagrams encapsulated in AppleTalk packets that are sent between the forwarding modules in MacIP hosts and gateways. The term "MacIP Range" refers to the set of IP addresses configured into a MacIP gateway that are considered to belong to the MacIP hosts being serviced by that MacIP gateway. Other terms will be defined as they are used, and most appear in the Glossary. The AppleTalk protocols used by MacIP are detailed in section 8 which describes DDP (Datagram Delivery Protocol), ATP (AppleTalk Transaction Protocol) and NBP (Name Binding Protocol). If you are not familiar with AppleTalk, then please read the relevant sections in Inside AppleTalk [1]. 1.2. Intended Audience It is expected that there are five different groups of people likely to be reading this document: MacIP host implementors, MacIP gateway implementors, system managers in trouble, the terminally curious, and Jon Postel. 1.3. Assumptions This document assumes the reader is familiar with the AppleTalk suite of protocols. AppleTalk is documented in "Inside AppleTalk" [1]. It is also assumed that the reader is familiar with the IP suite of protocols, particularly IP [2], IP over Ethernet [4], Ethernet ARP [3], RIP [9], subnetting and routing [6], IP host requirements [10], and as documented in other various RFC's. This document is purposefully confined to the description of the two port gateway, where one port is connected to an AppleTalk network and one port is connected to a Ethernet IP network. This is for Evans and Ranch November 11, 1992 Page 3 MacIP November 1992 descriptive simplicity and should not restrict implementations in any way. The described AppleTalk port of the gateway and of the host does not need to be restricted to LocalTalk as AppleTalk may be transmitted over other media, such as Ethernet (EtherTalk), Token Ring (TokenTalk), a Serial connection (ARAP), or anything else. 1.4. Structure of this Document MacIP is a complex protocol; there are multiple modules in both the gateway and the host. Some of them operate in a client/server mode. Others operate peer-to- peer and/or peer-to-proxy. The original protocol specification, MacIP-1 is described in sections 2 and 3. It begins with a description of the whole system, moves on to detailed descriptions of the individual modules, then describes the protocols used. Section 4 discusses MacIP limitation, and recommends a subset of features and the Virtual Internal MacIP architecture. These limitations and recommendations are for informational purposes. Section 5 provides a brief synopsis of AppleTalk, and discusses MacIP required variations of the AppleTalk Name Binding Protocol, NBP. Sections 6 and 7 provide protocol constant definitions and a glossary. Section 8 provides implementation notes on many of the previous sections. Its section numbering is discontiguous, and follows which previous section the note applies to. These notes are for informational purposes. 2. MacIP Protocol Overview MacIP must satisfy requirements imposed by IP, AppleTalk (except where noted), the Macintosh, and the MacIP gateway. 2.1. Required Functionality 2.1.1. Basic Requirements IP connectivity is required between MacIP hosts embedded in an AppleTalk network, and IP hosts elsewhere on an IP internet. Evans and Ranch November 11, 1992 Page 4 MacIP November 1992 [ H1 ] [ H2 ] MacIP Hosts | | +-------+--------+ AppleTalk Net | MacIP GW [ GW1 ] [ IP3 ] IP Host || || ++=======++=====++ IP Ethernet || MacIP Host[ H4 ] [ GW2 ] MacIP GW | | +----------------+ AppleTalk Net Figure 1. Example MacIP Internet There are four different cases to consider in the internet shown in Figure 1. 1. Between a MacIP host and an IP Host (H1 and IP3 via GW1). 2. Between MacIP hosts on different AppleTalk networks via intervening MacIP gateways (H1 and H4 via GW1 and GW2 ). 3. Between MacIP hosts in the same zone connected to the same MacIP gateway (H1 and H2 via GW1). 4. Between MacIP hosts in the same zone without a MacIP gateway being present (H1 and H2 directly). Cases 1 and 2 are very similar. Given that MacIP to IP connectivity is established, there is no difficulty supporting MacIP to IP to MacIP. Cases 3 and 4 may appear identical, but are not. Traditional implementations require that MacIP packets must follow the most "efficient" route, and not go through the gateway when the hosts are on the same network. The following is a simple requirement matrix. Local with From/To Local Remote IP Host No Gateway --------------------------------------------- Local | Yes | Yes | Yes | Yes | Remote | Yes | Yes | Yes | - | IP Host | Yes | Yes | - | - | Table 1. MacIP-1 Requirement Matrix Evans and Ranch November 11, 1992 Page 5 MacIP November 1992 2.1.2. IP Requirements In order to function as an IP host, a minimum of two things are required: 1. An IP Address for the host. 2. A means by which to forward packets to the host. With these, an IP host can function on a point-to-point link. In order to function on a broadcast network (such as Ethernet or LocalTalk) the following is also required: 3. An Address Resolution scheme (ARP) to resolve IP addresses to native network addresses. 4. A subnet mask to allow local and remote routing decisions to be made. 5. Gateway address to send off-subnet packets to (more sophisticated routing is sometimes desirable, but not essential). The MacIP protocol can provide all five, although the last two add significant complexity. A variation on ARP provides this functionality. 2.1.3. Macintosh Considerations Macintoshes are mobile, and are often moved from one network to another. The AppleTalk protocol handles this automatically without requiring any user reconfiguration of the Macintosh. It would be inconvenient to have to reconfigure the IP Protocol stack under these circumstances. The MacIP protocol provides an automatic IP Address Assignment protocol that can be used to circumvent the requirement for reconfiguration when moved. IP addresses so assigned are called "Dynamic" Addresses. Because Macintoshes often are connected directly to Ethernet, the IP protocol stacks usually support both direct Ethernet and MacIP modes of connection. The MacIP protocol is modular and designed to attach simply to an existing Ethernet implementation. 2.2. Protocol Relationships In order to provide the required functions, MacIP has the following relationship to the other protocols in MacIP hosts and gateways: Evans and Ranch November 11, 1992 Page 6 MacIP November 1992 MacIP Host MacIP Gateway ------- ------- | TCP | | UDP | +-----+-----+-----+ ---------------------------- | IP |<---->| IP | +-----------------+ +--------------------------+ | MacIP |<---->| MacIP | | Ethernet | +-----------------+ +-----------+ ------------- | AppleTalk |<====>| AppleTalk | ------------------- ------------- Figure 2. MacIP Host and Gateway Connections MacIP acts as a Link-layer protocol to IP, while acting as a client of all the session, transport and network layers of AppleTalk. This should serve to warn readers of the complexities ahead: Layer Name Protocol ------- ------- 4 - Transport | TCP | | UDP | +-----+-----+-----+ 3 - Network | IP | +-----------------+ 2 - Link to IP |.................| 5 - Session to | MacIP | AppleTalk +-----+-----. | 4 - Transport | ATP | NBP |_____| 3 - Network | AppleTalk - DDP | 2 - Link | AppleTalk - LAP | ------------------- Figure 3. Relation Between IP and MacIP [Phil doesn't like the above diagram. Shall it go in the appendix?] 2.3. Protocol Mapping MacIP uses the zone-wide protocol NBP to perform the ARP function. This makes for a very simple ARP implementation on a Macintosh as most of the code is already built in to the operating system. It does lead to the following unfortunate restrictions: 1. There has to be one MacIP gateway per zone, Evans and Ranch November 11, 1992 Page 7 MacIP November 1992 2. There can't be more than one MacIP gateway per zone, and 3. MacIP hosts can't use a MacIP gateway in a "remote" zone. There have been many attempts to overcome the above restrictions, but they are all "outside" of MacIP-1 and cause problems of their own. 2.4. MacIP Functions and Services MacIP provides address assignment, address resolution and packet transport services. 2.4.1. Address Assignment The MacIP gateway contains an Address-Assignment module which is configured with a set of IP addresses to assign to MacIP hosts. The module advertises its presence on the network with NBP registration, lookup, and confirmation. The MacIP gateway is discovered by a MacIP host during the initialization of the MacIP host's protocol stack, then an IP address can be requested and granted. MacIP also allows for a MacIP host to be assigned a fixed or "Static" IP address within a range of addresses known to the MacIP gateway. 2.4.2. Address Resolution Ethernet-connected IP hosts use the Ethernet Address Resolution Protocol (ARP) to discover the hardware address corresponding to a required IP address. The AppleTalk NBP protocol provides similar capabilities and is used to implement the address resolution function in MacIP. This is referred to as NBP ARP. When any device supporting MacIP acquires an IP address, it registers it through its local NBP process. It is then visible to NBP ARP requests from other MacIP devices. There is the added advantage of possibly discovering configuration errors caused by duplicate IP addresses, as NBP guarantees unique registration within the local zone. With Ethernet ARP, the "working range" of an ARP request is the IP subnet, which corresponds to the "reach" of the Ethernet broadcast packet. With NBP ARP, the "broadcast reach" corresponds to an AppleTalk construct called a "Zone". A zone consists of one or more AppleTalk networks, the actual topology of which is controlled by the network administrator. The zone that the MacIP gateway and the hosts are in is referred to as the "MacIP zone". The zone that a particular device is in is Evans and Ranch November 11, 1992 Page 8 MacIP November 1992 referred to as its "local zone". Therefore there is a direct correspondence between an IP Subnet and an AppleTalk Zone for NBP ARP. Unfortunately the same does not apply for the delivery of any other sort of AppleTalk or MacIP packet, as the "broadcast reach" corresponds to a single AppleTalk network. 2.4.3. Transport Transport of IP datagrams over LocalTalk is achieved by encapsulating them in Datagram Delivery Protocol (DDP) packets and sending them over an AppleTalk internet. The destination device can be another Macintosh computer supporting MacIP or a gateway. The latter can either be explicitly selected or discovered through a proxy-based process. 3. MacIP Protocol Specifics This section describes the MacIP protocol as originally implemented and documented in the Stanford KIP gateway code. This forms the simplest possible version of MacIP, and one which should be supported by all host and gateway implementations. 3.1. Gateway Addressing Styles There are two alternative approaches to integrating an AppleTalk network into an IP network. One approach involves treating the AppleTalk network as an IP subnet, with the MacIP gateway assuming the role of an IP router. The alternative is to allocate to the AppleTalk network a small range of addresses "stolen" from the Ethernet IP subnetwork that the MacIP gateway is connected to. In this case, the MacIP gateway forwards IP packets to and from AppleTalk. The forwarding method is conceptually easier, and thus easier to configure. No large range of subnet addresses needs to be calculated and allocated to the AppleTalk network, and no changes need to be made to the rest of the network. The routing method is more difficult conceptually and, hence, harder for an administrator to configure. It is, however, more consistent with the requirements of many large sites, and can be more practical in complicated networks. This is especially true if the MacIP gateway will emit Routing Information Protocol (RIP, [9]) packets to inform the Ethernet network of the MacIP AppleTalk subnet. MacIP gateways conforming to MacIP-1 MAY implement either or both of these styles. This doesn't affect MacIP hosts as they should not be Evans and Ranch November 11, 1992 Page 9 MacIP November 1992 able to tell the difference. 3.1.1. MacIP Forwarding When forwarding with the MacIP architecture, the AppleTalk network is treated as an extension of the Ethernet IP network. This is done by situating the "MacIP Range" within the range of IP addresses defined by the Ethernet IP network. When a host on the Ethernet ARPs for an IP address which is in the MacIP range, the gateway will answer, performing the proxy ARP function [8]. For example, if the Ethernet has the IP subnet "192.9.200.0", then the MacIP gateway might be configured to assign the addresses "192.9.200.100" through "192.9.200.150" to MacIP hosts. The gateway will respond to ARP requests on Ethernet to all these addresses, plus its own IP address. 3.1.2. MacIP Routing Routing via the MacIP protocol is straightforward from the perspective of IP routing. The gateway is configured with two IP addresses and subnet masks, one for the Ethernet and one for the AppleTalk networks. As the MacIP gateway is acting as an IP Gateway (and is thus performing IP routing), it is necessary for the TCP/IP hosts on the Ethernet side of the gateway be informed of the existence of the subnet corresponding to the MacIP Range, and that the MacIP gateway is the gateway to this subnet. This can be done via static routing tables or via the RIP protocol. MacIP gateways MAY provide either a full or conservative (the latter only advertises the MacIP subnet) RIP implementation in the MacIP gateway. 3.2. MacIP Initialization 3.2.1. Configuration Required For MacIP Hosts The MacIP host requires an IP address for configuration. "Dynamic" or "Static" addresses refer to the method by which the address is acquired. A dynamic address is assigned from the MacIP gateway's address range. A static address is assigned at the MacIP host, then confirmed through the MacIP gateway. 3.2.2. MacIP Host Initialization The initialization code is responsible for finding the MacIP gateway's Address Assignment server using NBP, requesting "server" information, acquiring an IP address, either from the address Evans and Ranch November 11, 1992 Page 10 MacIP November 1992 assignment service or from a statically-configured address, and registering the MacIP host's IP address with NBP. 3.2.2.1. Locating the MacIP gateway's Address Assignment Server The Address Assignment Service in the MacIP gateway [Server] is assumed to have registered itself with NBP with a type of "IPGATEWAY". The MacIP host initialization process uses NBP to search for "=:IPGATEWAY@*", which performs a search for all Servers in the same zone that the MacIP host is in. Under MacIP-1 the implementation assumes that it will only receive one response from one gateway. Multiple gateways in one zone are not covered in MacIP- 1. 3.2.2.2. Requesting Server Information The MacIP host and the Server exchange information using a protocol called "MacIPGP", described later. The MacIP host can optionally send a MacIPGP SERVER request to the Server, and SHOULD then receive a response packet. The information in the response packet is mainly obsolete and not very useful, although the returned IP Broadcast address might be usable from some gateways. 3.2.2.3. Requesting a Dynamic IP Address If the MacIP host is not configured to use a Static IP address, it sends a MacIPGP ASSIGN request to the Server. It will either respond with an appropriate IP address or an error status and optional message which should be displayed to the user. Errors at this point are non-recoverable. 3.2.2.4. Registering the IP Address The MacIP host registers its IP address through NBP. It MUST use its IP address in dotted decimal notation as its NBP Name. This representation is the four bytes of the IP address, in network order, in decimal with no leading zeros and separated by periods. For its NBP Type, the string "IPADDRESS" MUST be used. For example, to register the IP address 131.161.1.2, the NBP registration would be "131.161.1.2:IPADDRESS@*". If the registration fails then it is an indication of a duplicate IP address, a gateway, or a network misconfiguration. The failed address MUST NOT be used. This SHOULD be clearly reported to the user. The MacIP host MUST register on DDP socket 72. Some current MacIP gateway implementations assume that the MacIP host is using socket 72 Evans and Ranch November 11, 1992 Page 11 MacIP November 1992 whether it is or not, so using anything else is not advisable. 3.2.2.5 Closing Down When the MacIP protocol stack closes down, it must remove its IP address registration from NBP. 3.2.3. Configuration Required For MacIP Gateways A MacIP gateway has to be configured with an IP address, a subnet mask and (possibly) a default gateway. It also needs to be configured with the "range" of IP addresses that are to be allocated to the MacIP hosts so that the gateway can provide address assignment and forwarding service to its MacIP hosts.. The "union of all IP addresses that can be assigned to MacIP hosts and that the MacIP gateway is required to forward packets to" is called the "MacIP Range". Historically, this is a single contiguous range, but implementations are not confined to this. This range contains a "Dynamic" and a "Static" range, either of which may be empty. The "Dynamic" range consists of IP addresses that can be allocated to MacIP hosts on request. The "Static" range consists of IP addresses that can be configured into MacIP hosts that require the same IP addresses all the time. The MacIP gateway will not forward packets to a MacIP host that has an IP address outside of this MacIP range. 3.2.4. MacIP Gateway Initialization The initialization code in a MacIP gateway is responsible for setting up certain data structures used by other modules, registering the Address Assignment server and certain IP addresses with NBP, and performing an initial search for already- registered MacIP hosts. 3.2.4.1. Proxy ARP Initialization If the MacIP gateway is configured in "forwarding" mode , then the ARP module is initialized to respond to the "MacIP range" of IP addresses in addition to other MacIP gateway addresses. 3.2.4.2. Registration of Address Assignment Server The MacIP gateway MUST register itself through NBP, using the type "IPGATEWAY", on DDP socket 72. It is necessary for the registration to be unique in the zone, and early implementations guarantied this by using as the NBP name field (which has to be unique), the dotted decimal representation of their IP address. Evans and Ranch November 11, 1992 Page 12 MacIP November 1992 3.2.4.3. Registration of IP Addresses The IP addresses that the MacIP gateway has that are within the MacIP Range SHOULD be registered with the NBP protocol on the gateway in the same way that IP addresses are registered on MacIP hosts. This guarantees that MacIP hosts will not succeed in registering the same address in the same zone. Also, this makes the IP addresses visible to both MacIP hosts (that may wish to send datagrams to these IP addresses) and to network management software. If the registration fails then MacIP MAY not be able to function on the gateway, and appropriate actions should be taken. "Passive Registration" (section 5.3.2.1) SHOULD not be used. 3.2.4.4. Reregistration Function The MacIP gateway is responsible for assigning unique IP addresses to MacIP hosts. If the gateway has been running, has assigned addresses and is then restarted (or crashes), it is in danger of reassigning the same addresses to other MacIP hosts. In order to recover the previous assignments, the MacIP gateway uses NBP to search for "=:IPADDRESS@*", which will locate all IP addresses registered with NBP ARP in the zone. The NBP responses are directed back to the Initialization module. Those discovered IP addresses that are within the dynamic range assignable by the gateway can be used to initialize the assignment table. It is important that the MacIP gateway attempts to use the same AppleTalk node address after a restart that it had before, as the MacIP hosts will have the node address of the gateway stored in NBP ARP tables and elsewhere. The gateway should not use a "random" node address on restart. 3.3. Proxy ARP As mentioned in 4.1.1, when configured to act as a "Forwarding Gateway", the MacIP gateway must perform Proxy ARP for the MacIP Range of addresses. This is simply implemented by adding the MacIP Range to the IP Address(es) that the MacIP gateway's Ethernet ARP process will respond to. All IP addresses in the MacIP range are proxied for, whether there are MacIP hosts using these IP addresses or not as this simplifies the implementation. Proxy ARP MUST be disabled when the MacIP gateway is configured to act as a "Routing Gateway". 3.4. NBP ARP - Address Resolution Any MacIP device (host or gateway) can resolve an IP address to an Evans and Ranch November 11, 1992 Page 13 MacIP November 1992 AppleTalk address by using NBP to search for the device that has that IP address registered. The name is the requested IP address in "dotted decimal" notation and the type is "IPADDRESS". NBP requires repeat and delay specifications (the number of retries and the delay between them). These should be set particularly leniently, especially considering that MacIP may be running over WANs and/or ARAP (Apple Remote Access Protocol). Recommended values are given in section 10, "Definitions". NBP ARP is functionally very similar to Ethernet ARP, and can often be implemented by using the host or gateway Ethernet ARP code and data structures. Both the MacIP host and gateway are assumed to implement a cache for the addresses resolved by NBP ARP. With Ethernet ARP, the "working range" of an ARP request is the IP subnet, which corresponds to the "reach" of the Ethernet broadcast packet. With NBP ARP, the "reach" corresponds to an AppleTalk construct called a "Zone". A Zone consists of one or more AppleTalk networks, the actual topology of which is controlled by the network administrator. There is therefore a direct correspondence between an IP Subnet and an AppleTalk Zone, but ONLY when performing NBP ARP, and not when routing certain packets such as those to an IP broadcast address, such as might be used by RIP or RWHO. 3.4.1. NBP ARP - Details The NBP ARP module is passed an IP address to resolve by the delivery module. Resolution is first attempted by searching for a matching IP address in the local ARP cache. A successful match should reset any usage timers. If a no match is found, then the address has to be searched for. The search on the network is made by using NBP to send an NBP LookUp to all devices in the MacIP zone. The entity-name in the LookUp is the dotted-decimal representation of the IP address (see section 6.2.8). The entity type is "IPADDRESS". The entity zone is the MacIP zone. The retry count and time is as specified in section 10. The NBP ARP response carries the AppleTalk address of the destination. The full AppleTalk address (net, node and socket - socket 72 is not to be assumed) must be stored in the ARP cache together with the IP address. 3.5. Delivery IP packets including the full IP header MUST be encapsulated in DDP Evans and Ranch November 11, 1992 Page 14 MacIP November 1992 packets of type 22 (decimal). The source and destination sockets of the packet are 72 (decimal) by convention. The AppleTalk DDP protocol limits the data size of a DDP packet to 586 bytes, which is then the maximum possible Maximum Transmission Unit (MTU) of the AppleTalk network when transporting IP datagrams. The MTU of 576 is more commonly used so as to conform to the minimum IP MTU. The Ethernet network has an MTU size of 1486 bytes. The smaller MTU size of AppleTalk requires that gateways must fragment Ethernet packets bound for AppleTalk which are larger than the AppleTalk MTU [3]. Packets received by the MacIP host MUST be dropped (not processed) if the destination IP address does not match the IP address of the MacIP host. No "IP Broadcast" destination addresses are allowed. This function can be performed either by the Delivery or IP modules. 3.6. MacIP Routing Decisions MacIP's design imposes restrictions that renders MacIP hosts incapable of correctly performing IP Broadcasts and of correctly interpreting ICMP Redirects. Both of these features are required in IP implementations. However, current MacIP host implementations do attempt this, so the feature described in the following section was developed. 3.7. Gateway NBP Proxy ARP In order to support the simple routing method used by the MacIP client, it is necessary for there to be a service in the MacIP gateway that performs the equivalent of a "Proxy ARP" service, but for all of its MacIP clients. The NBP Proxy ARP service must respond to all NBP ARP requests for all IP addresses EXCEPT for the ones in the MacIP range (those allocated to the MacIP clients). NBP Proxy ARP MUST respond to NBP requests with the IP address being requested, the type "IPADDRESS" and the AppleTalk net, node and socket (72) address of the "Delivery" module. The NBP Proxy ARP module MUST NOT respond to "wildcard" lookups for type "IPADDRESS". NBP Proxy ARP has to be implemented on a "non-standard" NBP implementation described in section 5.3 as "Conditional NBP" (CNBP).. 3.8. MacIP Gateway Protocol MacIPGP is a simple request-response protocol based on ATP (AppleTalk Transaction Protocol) ALO (at-least-once) transactions. Evans and Ranch November 11, 1992 Page 15 MacIP November 1992 The MacIP host sends an ATP TREQ (ATP Request) packet to the AppleTalk address of the Address Assignment Server, and the MacIP gateway responds with an ATP TRSP (ATP Response) packet. There are two defined functions which MacIP-1 uses. These are "get server info" (SERVER) and "assign IP address" (ASSIGN). 3.8.1. SERVER Function The SERVER function returns a list of common server IP addresses, such as name server, file server and the broadcast address. These are usually defined as part of the gateway's configuration and simply passed on via the protocol without interpretation, so their specific contents is not part of the MacIP protocol. Most of these can be considered "obsolete". Their "usual" designation is detailed below. 3.8.2. ASSIGN Function The ASSIGN function returns an IP address which can be used by the MacIP host to communicate with other IP hosts. The following is the description of the implementation in the December 1986 KIP code in the "ip.at" document. The gateway is configured with a "Dynamic Range" range of IP addresses and maintains a table of these containing the fields: IP address; timer; flags; AppleTalk address (including socket); When the MacIP Client sends an ASSIGN request to the gateway, the gateway searches the table described above. The service tries to reassign the same IP address to the same AppleTalk address if possible. Otherwise any free IP address is used. If an IP address is available, it is sent in an ASSIGN Reply packet, and the timer field of that table entry will be started. Thereafter, every "Confirm Period" (60 seconds if not configurable), an "echo command"(NBP ARP Confirm) is sent to the client and the timer bumped. Echo replies received will restart the timer. If 5 periods pass with no replies received, that table entry will be available for potential reassignment. In making "new" table assignments the timer field is used to locate the oldest unused table entry. This increases the chances of a given MacIP host to keep reusing its previous IP address assignment. It is important to note that IP addresses assigned via the gateway ATP protocol must be registered and resolved using the NBP ARP technique. Evans and Ranch November 11, 1992 Page 16 MacIP November 1992 3.8.3. ERROR Response The MacIPGP protocol request return an error if a request other than ASSIGN or SERVER is made. The ASSIGN response may return an error if there are no Dynamic addresses available. 3.8.4. MacIPGP Packet Definitions The complete MacIPGP packets consists of: 1. Data-link Header, 2. DDP Header, 3. ATP Header, 4. MacIPGP Header, 5. MacIPGP Data Packet (only on MacIPGP Response packets). It has the format: 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 / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ATP Control | ATP Seq. No | ATP Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ATP User Bytes - Ignored | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MacIPGP Request or Response Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / MacIPGP Data (variable length) / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6. MacIPGP Packet Evans and Ranch November 11, 1992 Page 17 MacIP November 1992 3.8.5. ATP Control Fields The Control Info, Sequence Number and Transaction ID fields are documented in Inside AppleTalk. The MacIP gateway returns these fields as-is to the MacIP host except that the Control Info field is changed from a TREQ to a TRSP. 3.8.6. ATP User Bytes These four bytes are unused in MacIP-1 and can be expected to contain random data. 3.8.7. MacIPGP Request and Response If the ATP Control info is TREQ, then this is a packet from the MacIP host to the gateway. The MacIPGP Data field is empty (zero length). The defined values of the MacIPGP Request field are: Val. Name Meaning 1 ASSIGN Request assignment of Dynamic address. 3 SERVER Return Server Information. -1 ERROR Only valid in MacIPGP Response packet. ASSIGN is a request for the MacIP gateway to assign an IP address from its configured "Dynamic Range" to the MacIP host. SERVER is a request for the "Server Information" to be returned. The MacIP gateway normally returns the packet as-is with the MacIPGP Response field in the returned packet set to the MacIPGP Request field in the received packet. If an error occurred, then the Response field is set to "-1" (hex FFFFFFFF) with an optional zero-terminated error string returned in the "Error Message" field. The length of the data field of the returned ATP packet is 64 bytes plus the length of the terminated error string. If the string is empty then 65 bytes are returned. 3.8.8. MacIPGP Data Field The MacIPGP Data Field is returned in MacIPGP Response packets. The format is: Evans and Ranch November 11, 1992 Page 18 MacIP November 1992 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Assigned IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name Server IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Broadcast IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | File Server IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |_ Other IP Addresses (16 octets) _| |_ _| |_ _| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Message (NULL terminated) | / 128 bytes maximum / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7. MacIPGP Data Field Originally the Name-server, Broadcast, File-server and Other fields were simply copies of configuration data transferred to the MacIP gateway by the AppleTalk Administrative Daemon (atalkad). Their meaning was thus a "private matter" between the administrator and the MacIP host code in use, and did not involve the MacIP gateway at all. It did not interpret or generate the data (except for the Broadcast field which the MacIP gateway does use), it only transferred it. Some manufacturers have changed this simple relationship by using the atalkatab fields for gateway configuration and/or having the gateway generate the data transferred to the MacIP host. Thus, the meaning is unclear, and thus for MacIP-1, undefined. 3.8.8.1. Assigned IP Address This is the IP address assigned by the MacIP gateway to the MacIP host. It is only returned in ASSIGN response packets. This field is only valid in ASSIGN response packets. 3.8.8.2. Name Server IP Address This historically has been used to contain the IP address of an IEN- 116 Domain Name Server. Evans and Ranch November 11, 1992 Page 19 MacIP November 1992 3.8.8.3. Broadcast IP Address This may be the Ethernet IP broadcast address which is only "appropriate" for the MacIP hosts if the MacIP gateway is configured in "Forwarding" mode. If it is in "Routing" mode, this field could be anything. MacIP hosts MUST not rely on this data. 3.8.8.4. File Server IP Address Originally the address of EFS (Electronic File Server) included with CAP v4 (Columbia AppleTalk Package). Obsoleted by AUFS. 3.8.8.5. Other IP Addresses Available for "private" use between consenting MacIP hosts and MacIP gateway configurations. These may contain the "IPOTHER" fields from the "atalkatab" file, but they may not. 3.8.8.6. Error Message If the returned MacIPGP Response code is -1, this may contain a 128- byte maximum null-terminated error message. Otherwise it is a zero- length null-terminated string (one byte of null). 3.8.9. Delivery Packets If the Address Assignment Service does not have the same AppleTalk address as the Delivery Module (as returned by NBP Proxy ARP), then it may still receive delivery packets (IP packets of DDP type 22) sent by MacIP hosts disobeying MacIP-1. For backward compatibility, these packets SHOULD be forwarded to the Delivery module. 4. MacIP Limitations and Recommendations The specification of MacIP imposes certain basic restrictions on operations of both hosts and gateways, particularly on the allowable network topology. Most MacIP gateway vendors have found different, incompatible, and incomplete methods ways to work around these basic protocol limitations. This specification recommends methods for managing the restrictions on both hosts and gateways. The host recommendations focus on the routing decisions hosts are attempting, and the gateway recommends that MacIP gateways reside on a virtual internal network. This network's zones list contains all zones supported by the MacIP gateway, and provides a more reliable mechanism for NBP ARP. This gateway and topology architecture is referred to as Virtual Internal MacIP (VIM). Evans and Ranch November 11, 1992 Page 20 MacIP November 1992 4.1. MacIP Routing Decisions MacIP 1 recommends that the MacIP host perform no IP routing decisions whatsoever. There are many advantages to this requirement: 1. It simplifies the MacIP host implementation, 2. It minimizes the network-specific information that has to be sent to or configured into the MacIP host, 3. It allows for MacIP to be extended so that Hosts can use the services of a MacIP gateway from "out of zone". Because of restrictions imposed by the design of MacIP, MacIP hosts are incapable of performing IP Broadcasts and of correctly interpreting ICMP Redirects, both of which would be expected of a full IP implementation. To be specific, it is mandatory that MacIP 1 Hosts should not do any routing-related operations and should obey the following: 1. They must use NBP ARP to resolve all IP addresses, no matter what they are, even IP addresses that may be, or are manifestly in another IP subnet or network, and includes any possible broadcast IP addresses. 2. They must ignore all subnet masks, network and subnet numbers and all possible "default gateway" addresses. 3. They should not send IP Datagrams to either the AppleTalk or IP address of the Address Assignment Server (received as the "name" field of the NBP LookUp). 4. They should ignore all ICMP Redirect messages and RIP packets that they may receive. The simplest way to disable all off-host routing decisions in an existing IP (or MacIP) implementation is to set the subnet mask to "0.0.0.0", and to disable any other "special-case" or error-checking code that may defeat the intention of this. The MacIP host code should not assume that the Address Assignment server and the NBP Proxy ARP module have the same socket address, or even the same AppleTalk address, as it is permissible for them to be implemented on different hardware and even on different networks. 4.2. Multiple Gateways in One Zone Limitation Evans and Ranch November 11, 1992 Page 21 MacIP November 1992 As detailed in section 3.7 (Gateway NBP Proxy ARP), having multiple MacIP gateways in the same zone will completely prevent MacIP hosts in that zone from working. The following hacks have been invented to get around this: 4.2.1. NBP Proxy ARP Directed Port With this method, the MacIP gateway restricts the operation of NBP Proxy ARP to requests received from networks connected via particular physical ports, (usually the LocalTalk port, where the majority of MacIP hosts usually are). This allows multiple MacIP gateways to exist in the same zone as long as the network topology guarantees that there is never more than one MacIP gateway's directed port on one AppleTalk network. This approach also requires NBP (CNBP) in the gateway to not answer NBP LookUps for "IPGATEWAY" unless they originate from the same port that NBP Proxy ARP is enabled on. This asymmetry plays havoc with network management; devices will be visible depending on where in the AppleTalk topology devices are looking from. 4.2.2. NBP Proxy ARP Hop Limit The DDP Hop Count is available to the NBP Proxy ARP process. It can refuse to answer any requests from MacIP hosts that aren't zero hops away (directly connected). This solves some problems at the expense of restricting the topology. It also will not work if two gateways share a common network. 4.2.3. Friendly Requests - Dynamic In this method, the NBP Proxy ARP module will only answer requests from the SAME MacIP hosts that the Address Assignment module knows about. The source AppleTalk address of the incoming NBP ARP is compared against all entries in the Assigned Address table. If the AppleTalk address is present (and the MacIP host is not registering its own address), then the NBP Proxy ARP module responds. This fails completely with MacIP hosts that have Static IP addresses, as they aren't in the in the table. 4.2.4. Friendly Requests - Static Various methods have been used to force friendly requests to work with static hosts. In all cases the gateway has to somehow record the AppleTalk addresses of MacIP hosts with static addresses. This table has to be filled with periodic "Reregistration" calls (3.3.4.4), or "directed wildcard NBP ARP" calls have to be issued to "suspected hosts". VIM provides a superior solution. Evans and Ranch November 11, 1992 Page 22 MacIP November 1992 4.2.5. NBP Proxy ARP Not Required If the MacIP host disobeys MacIP-1 and sends all packets to the MacIP gateway then NBP Proxy ARP may not be required, but MacTCP (Apple's MacIP driver for the Macintosh) doesn't allow this. 4.2.6. Other Multiple Gateway Problems Given a choice of multiple MacIP gateways, MacIP hosts will invariably pick the worst possible one - the one "furthest away". To date, MacIP hosts cannot select which MacIP gateway to attach themselves to. Thus, it is a race condition for NBP responses to return to the MacIP host. Generally, the first response received is used. See section y.y.y "Out-of-order NBP" for a discussion. 4.3. Out-of-Zone Limitation NBP ARP can only work between devices that are in the same zone. In spite of this, most MacIP implementations try to allow the MacIP hosts to be in a zone different to that of the MacIP gateway (the MacIP zone). The problems for the MacIP host in the wrong zone are: 1. Its NBP ARP Registration won't find duplicate IP addresses, 2. It can't answer NBP ARPs from other MacIP hosts, 3. It can't answer NBP ARPs from the MacIP gateway, 4. The gateway "reregistration" function can't find this host. The following "Out-of-Zone-Hacks" have been used in existing implementations. We none of them, and suggest VIM instead (described in the next sub-section). 4.3.1. Ask Address Assignment - Dynamic MacIP hosts that have requested Dynamic IP addresses have their AppleTalk and IP addresses in the Address Assignment Module's table. NBP ARP can be modified to check this table. This is a very incomplete solution as it only solves problem (3) above, while ignoring (1), (2) and (4). It can't work with Statically-addressed hosts at all. 4.3.2. NBP ARP Reverse Resolution To allow Static-IP address MacIP hosts to operate out-of-zone, it is Evans and Ranch November 11, 1992 Page 23 MacIP November 1992 possible for the MacIP gateway to "listen" for NBP ARPs (as it does in 4.1.2 Friendly Requests). These may be the Static hosts attempting to "register" their IP addresses in the zone of the MacIP gateway (they should do this in order to discover duplicate registration, but none do). It may be the Static hosts performing NBP ARP in the MacIP gateway's zone. In either case, if the MacIP gateway doesn't find the source AppleTalk address in the table, it then sends a "directed wildcard NBP ARP" to the source AppleTalk address. Any response will be directed by CNBP to the "reregistration" part of the Initialization Module, and will serve to register the address for the next time. This fails to work for statically addressed hosts that are running an IP service application. IP service applications tend not to send unsolicited packets, and thus no address mapping exists, preventing address resolution. It still doesn't solve problems (1) and (2) either. 4.3.3. Glean From MacIP Packets Some Static hosts may default to sending MacIP packets to the MacIP gateway. The IP to AppleTalk address mapping can be "gleaned" from these packets. There are two problems here. Firstly it is computationally expensive to "glean" every MacIP packet. Secondly it relies on the host sending the packet to the gateway, and not all do. It doesn't work with hosts running a server application, as they don't send any gleanable MacIP packets. Gleaning can partly solve the problem that reregistration can't work with out-of- zone hosts - the next MacIP packet from the MacIP host after a gateway restart will update the table. 4.4. Virtual Internal MacIP Recommendation We recommend that MacIP gateways implement a virtual internal network that has no physical port associated with it, but has a network range and zones list. The zone list contains all the zones that MacIP hosts are going to reside. Then, the MacIP gateway is made visible in all of those zones by registering itself through NBP to all MacIP hosts in those zones. If the MacIP Host is not in the same zone as the MacIP Gateway, then you don't get in. This simplifies everything back to "Classic 1986 MacIP" which we all have code for. All existing MacIP host code works, both "in" and "out-of" zone (because there aren't any out-of-zones). Pretty much all of the existing MacIP Gateway code should be able to remain "as- is" as well, and should be straight-forward to document and instrument. Evans and Ranch November 11, 1992 Page 24 MacIP November 1992 It is possible to make the "VIM zone list acquisition" automatic. When a new "MacIP Zone" is found (by a MacIP host trying to register), the gateway uses RTMP to "poison" the old VIM network range (let's say it was AppleTalk network 10-10), creates a new VIM network that overlaps the old one (say network 10-11) with all the old zones and the new one in it, and then advertises that with RTMP. Disabling "automatic zone list acquisition" counts as a marketable "security feature". We could then optionally add Phil Budne's idea of having MacIP Gateways search for other MacIP Gateways (using NBP to look for "=:IPGATEWAY@zzz"), and then send RIP packets to them - we've just solved all of the tricky "RIP-in-MacIP" problems too. For the "efficiency purists" who demand "minimum path" delivery between MacIP hosts that are in different zones, that's now easy to support too. In this case, NBP Proxy ARP would look in its mapping table for the IP address in question, and use the mapped AppleTalk address in the NBP Response's Entity address fields. This effectivley provides an address translation service, or could be considered NBP Proxy ARP redirect. 5. AppleTalk Basics and Variations For those not familiar with AppleTalk, this section gives a very brief summary of the parts of AppleTalk used by MacIP. The reference for AppleTalk is "Inside AppleTalk, Second Edition", published by Addison Wesley. 5.1. AppleTalk Addresses Devices on an AppleTalk Internet are uniquely identified by a 16-bit network number combined with an 8-bit node number. These addresses are handled very similarly to the net and host part of a Class C IP address. MacIP has no special requirements on AppleTalk addresses. 5.2. AppleTalk Zones AppleTalk networks are grouped together into named collections called Zones. This is implemented in the routers responsible for the network numbers by associating a Zone Name (or list of zones for extended networks) with each network. Zone names form the user- visible topology of AppleTalk Internets, hiding the actual network- level topology. 5.3. Name Binding Protocol NBP provides registration and location services for named entities Evans and Ranch November 11, 1992 Page 25 MacIP November 1992 within zones. A service entity begins by attempting to register a "name" and a "type" with the local NBP software. NBP places the name:type combination into a local registry, so their nodes may locate it, and then (with the cooperation of the local router) broadcasts "LookUp" packets on every network that is associated with the host's zone. If the name:type is already registered in that or some other host, a "LookUp Reply" packet will be received by NBP and the registration attempt fails. Generally, the service will modify the its name, and re-attempt registration. If no LookUp Replies are received, then the registration is considered successful. Once a name:type is registered, NBP will answer searches made by other devices for that name:type, and will supply the AppleTalk address (net:node:socket) of the registered entity. Wildcard LookUps are permitted on both the name and type fields. 5.3.1. Strict NBP The previously-described NBP is the type implemented by the Macintosh Computer OS. It is characterized by "Active NBP Registration" where NBP always performing a "uniqueness-search" on registration, and "Unconditional NBP Replies" where NBP unconditionally answers all NBP LookUps that match registered entities. 5.3.2. Loose NBP There are a lot of ways to abuse NBP and to step outside the purposes for which it was written. The following are some of the ways that have been found to abuse it, collectively called "Loose NBP". The problems caused are mainly those of confusion, both to network managers and to network management software. 5.3.2.1. Passive NBP Registration Some NBP implementations perform "Passive NBP Registration" by skipping the "uniqueness search". For the case of registering single unique entities this can only be described as poor practice, as it will fail to detect duplicate registration. It may also confuse network managers who are monitoring the device to see if it is working properly. In the case of implementing NBP Proxy ARP it is impractical to "Actively Register" the 4,261,412,864 IP addresses that the MacIP gateway is proxying for. 5.3.2.2. Conditional NBP Replies NBP can also be abused to allow "Conditional NBP Replies" (CNBP) Evans and Ranch November 11, 1992 Page 26 MacIP November 1992 where the generation of the NBP LookUp Reply does not depend solely on the contents of the local NBP Registry, but depends on the requesting device, or the particulars on what is being asked for. This isn't possible on a Macintosh as NBP is built into the OS. Again NBP Proxy ARP requires this. 5.3.2.3. Out-of-order NBP A packet monitor observing an NBP transaction would expect to see the following operations in the following order, and may in fact depend on the order to correctly report the operation: 1. MacIP host wishing to search for a particular named entity within its own zone sends NBP BrRq (Broadcast Request) to a local AppleTalk router, 2. The router rebroadcasts the NBP Query as an NBP LkUp (LookUp) on all networks in the requested zone, 3. One or more LkUp Replies are sent from the searched-for entity to the requesting host. In the case of a MacIP host searching for a MacIP gateway there exists a serious problem. The router that the MacIP host sent the NBP BrRq to is likely to be the most appropriate MacIP gateway. However while this router/gateway is busy performing step (2) above, other MacIP gateways in the same zone are likely to be on step (3). Current MacIP host code will use the first LkUp Reply and will thus select the inappropriately "remote" gateway. If the first router reverses steps (2) and (3) above, replying to the request before rebroadcasting it, then the MacIP host will select it. It looks weird on a packet monitor though. 5.3.2.4. Port Hopping NBP is intended to allow a client to search for a service by name, and to discover the network address which will be used for the delivery of subsequent datagrams. In the case of a multi-port service-provider, it is sensible to return the "nearest" AppleTalk address to the client, in this case the address of the port that the NBP Reply was returned to the client through. Unfortunately this port (and address) may not be in the zone that the request was originally made in. This causes no problems apart from confusion to network managers again, and should probably be avoided for this reason. 5.4. DDP Evans and Ranch November 11, 1992 Page 27 MacIP November 1992 The Datagram Delivery Protocol is close to the AppleTalk equivalent of UDP/IP. It implements an "unreliable" Datagram Delivery service, with the destination address being a socket at a specific net:node address. DDP packets also have a "type" field which permits another level of multiplexing on top of the socket multiplexor, but is often used redundantly with the socket. 5.5. ATP The AppleTalk Transaction Protocol adds a request/response/timeout and retry mechanism on top of DDP packet delivery. Transactions commence with an ATP Request packet (TREQ) and must be answered by an ATP Response (TRSP) or the requestor will retry and eventually time out and report back an error to the client. 6. Definitions 6.1. AppleTalk Protocol constants MacIP MTU 576 bytes DDP constants MacIP packet type 22 (decimal) DDP ARP packet type 23 (decimal) DDP ARP constants AppleTalk address type 3 (decimal) NBP constants gateway object type IPGATEWAY registered IP address object type IPADDRESS LookUp retransmit count 4 tries LookUp retransmit interval 5 seconds 6.2. Gateway ATP Protocol Constants ATP Protocol Constants ATP retransmit count 4 tries ATP retransmit interval 5 seconds ATP request command codes ASSIGN assign IP address 1 NAME name server 2 (obsolete) SERVER get server info 3 ATP response codes SUCCESS same as request code ERROR -1 Evans and Ranch November 11, 1992 Page 28 MacIP November 1992 7. Glossary MacIP The encapsulation protocol and associated services. MacIP-1 The original MacIP specification as implemented in the KIP code. MacIP-2 A future version of MacIP that will allow out-of-zone and multiple-gateway operation. MacIP Host A device implementing the host-side of the MacIP protocol, usually an Apple Macintosh computer. MacIP Gateway A device implementing the gateway-functions of the MacIP protocol. It converts between the MacIP transport-layer and those used by the other IP hosts, as well as provides other server-type functions. IP Host An IP host on an IP internet, usually not using MacIP, but with which MacIP hosts can communicate. MacIP Packets IP datagrams encapsulated in AppleTalk packets that are sent between the "Delivery" modules in MacIP hosts and gateways. MacIP Network The collection of MacIP hosts and the MacIP gateway that are in direct communication with each other - similar to the concept of an IP Subnet. MacIP Range The range of IP addresses configured into a MacIP gateway that are considered to belong to the MacIP hosts. MacIP Dynamic Range The IP addresses in the MacIP range that are available for automatic assignment to MacIP hosts by the gateway MacIPGP module. Dynamic Address An IP address assigned by a MacIP gateway from its Dynamic range for the use of a MacIP host. Evans and Ranch November 11, 1992 Page 29 MacIP November 1992 MacIP Static Range The IP addresses in the MacIP range that are available for permanent assignment to MacIP hosts by the system administrator. Static Address A fixed IP address assigned by the system administrator to a MacIP host. This address must be in the MacIP Static range of the host's MacIP gateway. MacIP Zone The AppleTalk zone that the MacIP gateway is situated in, and which corresponds to the "reach" of the NBP ARP function. Local Zone The AppleTalk zone that a MacIP host is in. MacIP Routing Mode The MacIP gateway configuration where the MacIP network IP addresses are in a different subnet to that of the IP backbone, and where the MacIP gateway is acting as an IP router. MacIP Forwarding Mode The MacIP gateway configuration where the MacIP network IP addresses are in the same subnet as the IP backbone, and where the MacIP gateway is performing Proxy ARP for the MacIP hosts. In-Zone Mode The MacIP host configuration where the host is in the same zone as the MacIP gateway (the MacIP zone is the same as the Local zone). Out-of-Zone Mode The MacIP host configuration where the host is in a different zone to the MacIP gateway (the MacIP zone is not the same as the Local zone). MacIPGP The MacIP Gateway Protocol. Used to implement the address assignment service, and to forward other information. NBP ARP Method for resolving an IP address into an AppleTalk address. Equivalent to Ethernet ARP. NBP Proxy ARP Method by which the MacIP gateway answers NBP ARP requests for IP addresses of IP hosts. Evans and Ranch November 11, 1992 Page 30 MacIP November 1992 NBP ARP Forwarding Method by which the MacIP gateway forward NBP ARP requests to MacIP hosts that ore located outside of the MacIP zone. Proxy ARP Method by which the MacIP gateway responds to Ethernet ARP requests from IP hosts for IP addresses in the MacIP range. VIM Virtual Internal MacIP. This refers to the proposed new MacIP gateway architcture. The gatweway implements an internal, virtual network, and associates itself with it. If the internal network's zones list contain more than one zone name, the MacIP gateway registers itself on all of them, providing gateway services to all MacIP hosts in those zones. 8. Implementation Notes This section provides notes and insights to the reader. Its sections numbers are organized to follow the preceding section numbers. 8.1.2 Intended Audience It should be noted that members from the various groups mentioned (host implementors, gateway implementors, system managers, and the curious) have different preconceived notions about what comprises a MacIP protocol system. Also, what is acceptable functionality in undocumented limitations will differ between these groups, and between members of the groups themselves. Careful attention must be paid to the fact that TCP/IP is not AppleTalk, and AppleTalk is not TCP/IP. There are some similarities that are close enough to conceal the important differences. NBP is nothing like DNS. RIP is different from RTMP. UDP isn't DDP. Mapping one protocol system to another presents a significant challenge, and that is what we're attempting with MacIP. It is very easy for things to go very wrong. 8.2.1.1 Basic Requirements Implementing MacIP so as to fulfill this requirement as well as the local with no gateway requirement (which is very rarely used in practice) is one of the things that makes the protocol so complex. 8.2.3. Protocol Mapping MacIP follows NBP ARP. The following are two obvious ways to "map" IP onto AppleTalk at the transport level, but are not followed. NBP ARP is used instead. This combines some of the worst features of Evans and Ranch November 11, 1992 Page 31 MacIP November 1992 "Direct Mapping" and "Server Client" without sufficient advantages to offset it. It also complicates implementation, documentation and installation. But we're stuck with it. 8.2.3.1. Direct Mapping MacIP provides very similar capabilities to Ethernet and Ethernet ARP, so one possible protocol mapping would be to treat each AppleTalk network as an IP subnet, with IP addresses within each subnet being resolved by an equivalent network-wide broadcast protocol to Ethernet ARP. All routing would be performed by the MacIP gateways, although the hosts would be required to perform "this- subnet" type routing decisions. This was actually implemented early on in the history of MacIP. It has many advantages. It satisfies the "requirement matrix" of 2.1.1 and its similarity to IP makes it easily understandable and documentable. The downside is that it requires every AppleTalk router in an Internet to also be an IP router This complicates the configuration of an Internet and also consumes IP address space at an alarming rate. This isn't MacIP-1. 8.2.3.2. Client-Server An approach leading to a very simple implementation would be a strict client- server one, such as the protocols that are already used to implement DECnet, LAT and SNA services over AppleTalk. MacIP hosts would use NBP to find the gateway(s) and then establish a "session" which would allow the gateway to record the AppleTalk address of the host so it would know how to route a packet back to them. Advantages would be the ease of implementation, documentation and debugging. The MacIP hosts wouldn't have to know anything about routing - they would send all packets to the gateway. It would also allow MacIP hosts that are anywhere on a large and complex AppleTalk Internet to use a gateway no matter where it was - there would only need to be one gateway. It would allow operation across AppleTalk zones. The downside is that all traffic between two MacIP hosts on the same network would have to pass through the gateway, and that the gateway would be required for the protocol. This isn't MacIP-1 either, much the pity. 8.2.4.4. MacIP Routing Decisions 8.2.4.4.1. Routing in Standard IP Hosts An IP host on a single point-to-point link only has one simple routing decision to make when presented with an IP packet to forward: Evans and Ranch November 11, 1992 Page 32 MacIP November 1992 1. Is the destination IP address equal to my IP address? If it is, the packet is sent "inwards". If not, it is sent out the link. An IP host connected to single broadcast medium has another two questions to answer: 2. Is the destination address within "this" network/subnet? If it is, the packet can be sent "directly" to the destination. If it isn't, then the packet has to be sent via a gateway, often a single "default gateway", the IP address of which is known. 3. Is the destination address a Broadcast address? In all cases ARP is used to resolve the selected IP address to a hardware address. In case (3), ARP will substitute the appropriate configured hardware broadcast address. 8.2.4.4.2. Routing in MacIP Hosts This "broadcast medium behavior" is insufficient for MacIP, as the Address Assignment protocol sensibly and deliberately provides neither the subnet mask nor default gateway information. This behavior should not be defeated (by allowing manual entry of the data) as it defeats the Macintosh "plug and play" requirement. Even if Address Assignment did provide this information, the disparity between the "reach" of NBP ARP and normal DDP broadcast datagrams prevents a MacIP host from broadcasting an IP datagram to all hosts in the zone. This is strictly not "required" by IP, but it is certainly "expected" by some applications. MacIP hosts SHOULD never perform any routing. This includes anything to do with subnet masks, broadcast addresses, default gateways, RIP or ICMP redirects. 8.3.2. MacIP Modules - Introduction MacIP can be best understood and described if the various functions are categorized into functional modules. The following gives the relationship between the IP , MacIP and AppleTalk modules in the MacIP host: Evans and Ranch November 11, 1992 Page 33 MacIP November 1992 ...................................... : IP Protocol Layer : :.......... | ............. | .......: | | ........... | ............. | ........ : ---------+-------- ------+------ : : | Initialization | | Delivery | : : ----+---------+--- -+--+-------- : : | | | | : : ----+---- ---+-----+- | MacIP : : | MIPGP*| | NBP ARP | | Protocol : : ----+---- -----+----- | : :..... | ......... | .... | .........: | | | ...... | ......... | .... | .......... : ----+---- -----+---- | : : | ATP | | NBP | | AppleTalk: : ----+---- -----+---- | Protocol : : | | | : : ----+-----------+------+-------- : : | DDP (Datagram Delivery Proto)| : : ----------------+--------------- : : | : : ----------------+--------------- : : | LAP (Link Access Protocol) | : : ----------------+--------------- : :................. | ................: | .................. | ................. : AppleTalk Hardware : :....................................: (*) "MIPGP" is short for "MacIPGP". Figure 4. MacIP Host Implementation The following gives the relationship between the IP , MacIP and AppleTalk modules in the MacIP gateway: Evans and Ranch November 11, 1992 Page 34 MacIP November 1992 ......................................................... : IP Protocol Layer +-----( IP Router )----+ : :.......... | ............. | .................... | ...: | | | ........... | ............. | .................. | : | | : | : ---------+-------- ------+------ MacIP : | : | Initialization | | Delivery | Protocol : | : ----+------+------ --------+-+-- : | : | | | | : | : ----+----- | ------------- | | --------- : | : | Assign | | | NBP Proxy | | | | Proxy | : | : ----+--+-- | ------+------ | | | ARP | : | : | \__|___ | | | ----+---- : | : | | \ | / | | : | : ----+---- | ---+--+-----+-- | \ : | : | MIPGP | | | NBP ARP | | | : | : ----+---- | ---+----------- | | : | : | | | | | : | :..... | .... | .. | .......... | ........ | ..: | | | | | | | ...... | ..... \ . | .......... | .... .. | ..... | .... : | | | | : : | | : : ----+---- --+--+---- Apple- | : : | ------+-- : : | ATP | | CNBP * | Talk | : : | | Ether | : : ----+---- -----+---- | : : | | Proto | : : | | | : : | --+--+--- : : ----+-----------+------------+-- : : \ | \ E : : | DDP (Datagram Delivery Proto)| : : --+-+-- | t : : ----------------+--------------- : : | ARP | | h : : | : : ---+--- | e : : ----------------+--------------- : : | | r : : | LAP (Link Access Protocol) | : : | | n : : ----------------+--------------- : : | | e : : | : : | | t : :................. | ................: :.... | ... | ..: | | | .................. | ................. ..... | ... | ... : AppleTalk Hardware : : Ether Hardware: ...................................... ................. (*) "CNBP" is "Conditional NBP". See section 8.3 for details. Figure 5. MacIP Gateway Implementation 8.3.2.1. Configuration Required For MacIP Hosts Evans and Ranch November 11, 1992 Page 35 MacIP November 1992 The terms static and dynamic SHOULD be used consistently in the user interface. If the host has multiple MacIP and/or IP interfaces, then a mechanism is required to allow selection between them. It is important to distinguish plainly between MacIP- based and "Native" IP connections. 8.3.2.2.1. Locating the MacIP gateway's Address Assignment Server The implementation SHOULD not take any notice of the returned NVE name field in the NBP response. However, it should be noted that many implementations expect to find the IP address corresponding to the Server in dotted decimal format. The implementation SHOULD record the full AppleTalk address returned in the NBP response (including the returned socket) and use it in subsequent transactions with the Server. It SHOULD not simply assume that the Server is on DDP socket 72. However, there are many existing implementations that make this assumption. 8.3.2.4.2. Registration of Address Assignment Server Unfortunately many MacIP host implementations wrongly rely on the name being an IP address, so for compatibility with these the use of the IP address as the name is "recommended". A simple two-port MacIP gateway configured in "forwarding" mode may only have one IP address to use for this purpose, but a multi-IP-port MacIP gateway may suffer an embarrassment of choices, so the question arises as to which IP address to use for this purpose. Fortunately this choice can be narrowed by the existence of bugs in some MacIP host implementations that can require the name of the Server to be an IP address in the same "subnet" as the IP address of the MacIP host. Good luck! 8.3.4.1. NBP ARP - Details The aging of ARP cache entries is required. The mobility of Macintoshes makes this particularly important. Any algorithm may be used as long it is at least as good as the following. Each use of the ARP cache entry should reset a "usage" timer. When a new entry is to be put into the cache, it might be full (or the bucket associated with the hashing function might be full). The entry with the oldest "usage" timer should be the one chosen to be replaced. ARP cache entries should be "confirmed" by sending a single NBP Confirm directly to the AppleTalk address in the cache entry once a minute. If no response is received after five requests the entry Evans and Ranch November 11, 1992 Page 36 MacIP November 1992 should be deleted. The NBP Cache should be capable of being flushed on request by other modules. 8.3.5. Delivery If the "Delivery" module experiences a hard error (the packet transport code cannot transmit the packet, and returns an error) when attempting to transmit a MacIP packet, then it is recommended that the NBP ARP cache entry for the destination IP address should be flushed and the transmit retried. This is to recover from MacIP gateway restarts where the gateway has picked a different node address to the one it previously had. 8.3.6. MacIP Routing Decisions The requirement in section 3.6 that MacIP hosts should always use NBP ARP for all destination IP addresses is widely disobeyed in actual practice. Most MacIP host implementations disobey this fundamental specification, as the requirements of being an IP host were not well understood at the time. It is thus expected that some MacIP-1 hosts will send some or all packets directly to the AppleTalk address of the discovered MacIP gateway for delivery. However it should be noted that if the MacIP gateway restarts, it may acquire a different AppleTalk node address to the one it had prior to the restart. If the host is sending MacIP packets to the old gateway address, they will not be delivered. The MacIP host SHOULD take measures to recover from this by following address cache aging and updating algorithms as discussed in the Host Requirements RFC [10]. This applies to NBP ARP caches as well. 8.3.7. Gateway NBP Proxy ARP It is the implementation of this service that causes the most problems in MacIP. If the NBP Proxy ARP module wrongly responds to an IP addresses that is assigned to a MacIP host, then the response from the gateway will look to the host attempting to register its address as a duplicate registration. This results in the restriction that with MacIP-1 there must never be multiple MacIP gateways in the one zone configured with different MacIP Ranges, as they will defeat registration attempts by MacIP hosts that have been assigned addresses by another gateway. Then again, two MacIP gateways can't be configured with the same MacIP range, as normal IP routing (Routing case) and Proxy ARP (Forwarding case) would fail to route packets under these circumstances. Therefore there can't be more than one MacIP gateway in any one zone. Evans and Ranch November 11, 1992 Page 37 MacIP November 1992 This is the "Multiple Gateways in the One Zone" problems, and will be addressed later. 8.5.3. Name Binding Protocol NBP can be though of implementing a form of "zone-wide broadcast". The only thing that can be broadcast is a search for a named entity - it is not possible to broadcast data-containing packets. This is important when considering mapping one network protocol (such as IP) onto an AppleTalk Internet. It is not possible to discriminate a "registration attempt" NBP LookUp from a "searching for" one. This makes the implementation of NBP Proxy ARP far more difficult than you would first suspect. 9. Issues 9.1 IP Routing Issues Phil pointed out that we didn't discuss IP hop count or checksum issues. Since we are subject to rfc1122 (naturally), should we still discuss it? Furthermore, what do y'all think of bumping [or not bumping] the hop count if we are just in 'forwarding mode'? Also, Phil asked if forwarding gateways need to intercept ICMP redirects. IP routers must ignore all ICMP redirects, as they're meant to have their routing tables updated by a "more reliable" method. Thus, all ICMP redirects MUST be ignored by the gateway, and MacIP hosts SHOULD ignore all ICMP redirects too. Should this go into this document? Where? 9.2 More Hacks Jonathan described the following additional 'hacks'. Should they be in this document, and if so, where? (1) The EtherGate has one ethernet port and 2 localtalk ports. We doclient IP address assignment out of a single range of addresses for both localtalk ports. This means that besides it's usual weirdnesses, we had to make NBP-proxy-ARP work across both localtalk ports if they're in different zones. When a Mac tries to confirm that it can use its IPADDRESS the EtherGate forwards the NBP Lookup to the other port and changes the zone name. Yuck. (2) When the EtherGate receives an NBP-ARP for an IPADDRESS not in its client range and on the same (sub)net as the EtherGate itself, it IP ARPs on the ethernet side to see if it can reach the IP host before responding on the NBP side. Evans and Ranch November 11, 1992 Page 38 MacIP November 1992 Would someone with a good familiarity of Proxy ARP routers like to contribute - there may be some good practice in existing Proxy ARP routers that we can adopt, copy, steal documentation from etc. One last note, I assume the implementation notes will include hints for the host (Mac client) implementor as well as the gateway implementor? We should clearly point out pitfalls and suggestions for both! Any host-implementors like to contribute a few paragraphs? 9.3 MacIP Host Recommendations - Another Idea From: Tom Evans The MacIP _HOST_ doesn't need a "session" with anything. Q. What is this "session" actually FOR? A. It is established at MacIP Host startup for the sole purpose of getting a Dynamic IP Address assigned. Q. Does the MacIP Host have to MAINTAIN the "session" with the Address Assignment Service? A. NO. Q. What is the ADDRESS of the IPGATEWAY? A. I've been reading Radia's "Interconnections" too. By her definition in section 2.3, an AppleTalk "address" doesn't fit her definition of an "address". The node-part of an AppleTalk address CHANGES. So the "address" of the IPGATEWAY starts out as its NAME, which is initially "=:IPGATEWAY@*" ("any gateway"). The MacIP Host picks a particular one (which is now "aa.bb.cc.dd:IPGATEWAY@*"), which fits the definition of a NAME (but has an IP ADDRESS embedded in it). This is the only real "fixed" representation of the "address". The AppleTalk address MAY CHANGE, so it shouldn't be stored. If the IPGATEWAY is required for some reason, it should probably be searched for again at the time that it is needed. The IP Address ("aa.bb.cc.dd" above) is a better "fixed address" than the AppleTalk address is. It can be resolved to an AppleTalk address when required by existing (NBP ARP) code. Q. "My code treats IPGATEWAY as a "default IP gateway", so I have to Evans and Ranch November 11, 1992 Page 39 MacIP November 1992 keep its address". A. XXXXXXXXXXX (removed by censors). Nothing else that I know of in a Mac stores AppleTalk addresses - they're too volatile. The LaserWriter driver stores the NAME of the printer. The AppleTalk address "A_Router" stored by any Mac is never more than 40 seconds old. ASP sessions store the AppleTalk address, but they're continuously maintained sessions that tell you when they break. The logical thing to do is to store the MacIP Gateway's IP Address and NOT its AppleTalk Address. This will make a lot more sense in the host's existing IP Routing table after all. No "special case MacIP code" required in the IP layer. Use NBP ARP to resolve ALL IP addresses passed down from the IP layer, including the one for the Default Gateway. The ARP/NBP-ARP code should have timeouts and confirmation. This will recover nicely if the IPGATEWAY changes its AppleTalk address, which it is "allowed" to do. Q. How does the MacIP Gateway keep ITS session information (required for NBP Proxy ARP)? A. By REREGISTRATION at gateway startup, by answering MacIPGP requests, by "tickling" them thereafter and by "probing" suspected "clients" that it receives NBP ARP requests from. It isn't the MacIP Host's problem. So the MacIP Host shouldn't keep any information that it doesn't need to, and thus it shouldn't be in the MIB. If it is, then it should be the IP address that is stored and not the AppleTalk address. Of course the above seems to be contradicted in the MacIP doc in sections 5.2.5 and 6.2 where it says that the MacIP Host should be able to receive multiple IPGATEWAY responses and then choose the "best" one. However, once the MacIP Host HAS an IP address, it doesn't need the Address Assignment Server anymore, and it should probably throw all the information away. So if the multiple gateway's addresses WERE accessible via SNMP, then they'd only be there for less than a second. 10. Acknowledgments Bill Croft, for the initial implementation of this protocol in the SEAGATE gateway at Stanford University and for the documents provided with the KIP code. Gaige Paulson and Tim K., for the NCSA Telnet source code. Evans and Ranch November 11, 1992 Page 40 MacIP November 1992 John Romkey, for the original PC/IP source code. Tim Maroney and ?, for the port of PC/IP to Macintosh. Jeannine Smith for TCP and UDP in MacTCP, and John Veizades and his team for the rest. Brad Parker and Josh Littlefield. This document is directly based on theirs written in February 1990. John Veizades, for a version of this document and for being the Chair of the Apple- IP working group. 11. References [1] Sidhu, G., Andrews, R., and Oppenheimer, A., Apple Computer, "Inside AppleTalk, 2nd. Edition" Addison-Wesley Publishing Company, Inc., Reading, MA, May, 1990. [2] Postel J., "Internet Protocol", RFC-791, USC Information Sciences Institute, September 1981. [3] Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826, Symbolics, September 1982. [4] Hornig, C., "Standard for the transmission of IP datagrams over Ethernet", RFC-894, Symbolics, April 1984. [5] Mogul, J., "Internet Subnets", RFC-917, Stanford University, October 1984. [6] Mogul, J., and Postel, J., "Internet Standard Subnetting Procedure", RFC-950, Stanford University, August 1985. [7] Brandon, R., and Postel, J., "Requirements for Internet Gateways", RFC-1009, USC Information Sciences Institute, June 1987. [8] Carl-Mitchell, S., Quarterman, J.S., "Using ARP to Implement Transparent Subnet Gateways", RFC-1027, October 1987. [9] Hendrick, C., "Routing Information Protocol", RFC-1058, June 1988. [10] Braden, R.T., ed, "Requirements for Internet Hosts", RFC- 1122, October 1989. Evans and Ranch November 11, 1992 Page 41 MacIP November 1992 12. Expiration Date This Internet Draft will expire in May 1993. 13. Security This document does not discuss security in any manner. 14. Contact Points The Apple-IP working group can be contacted by emailing the following address: apple-ip@cayman.com The Apple-IP Working Group Chairperson is: John Veizades Apple Computer Cupertino, CA (408)974-2672 EMail: veizades@apple.com The author's addresses are: Tom Evans Webster Computer Corporation 1270 Ferntree Gully Rd Scoresby Melbourne 3179 Victoria, Australia 61-3-764-1100 EMail: tom@wcc.oz.au Christopher S. Ranch Novell, Inc. 2180 Fortune Drive San Jose, CA 95131 (408)473-8667 EMail: cranch@novell.com Evans and Ranch November 11, 1992 Page 42