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]