Ravinder.Chandhok@CS.CMU.EDU (Rob Chandhok) (04/20/88)
**********************************************************************
The following numbers have been assigned by the NIC for use by encapsulated
AppleTalk (Using the Columbia AppleTalk Package).
Now that these numbers are assigned, there will have to be a new release of
the KIP and CAP code which reflect this mapping. But this will alleviate
any problems/conflicts with mapping UDP<->DDP ports that we have had.
The request to the NIC was sponsored by Charlie Kim (columbia),
Bill Croft (stanford), Dan Tappan (bbn),and myself(cmu).
Those of you getting this message who are not interested in appletalk, you
might want to put those numbers in your /etc/services or whatever.
I imagine Charlie Kim will post a message to info-appletalk when this is all
sorted out.
The actual request made to the NIC follows the assignments.
Rob
- - ------- Forwarded Message
Date: Wed, 13 Apr 88 11:47:37 -0800
From: jkrey@venera.isi.edu
To: chandhok@gnome.cs.cmu.edu
Subject: UDP port number assignments
Rob,
We have assigned the following port numbers for AppleTalk:
201 - AT-RMTP - AppleTalk Routing Maintenance
202 - AT-NBP - AppleTalk Name Binding
203 - AT-3 - AppleTalk Unused
204 - AT-ECHO - AppleTalk Echo
205 - AT-5 - AppleTalk Unused
206 - AT-ZIS - AppleTalk Zone Information
207 - AT-7 - AppleTalk Unused
208 - AT-8 - AppleTalk Unused
Cheers, Joyce
**********************************************************************
AppleTalk Encapsulated in IP
March 1988
C. Kim, Columbia (cck@cunixc.columbia.edu)
D. Tappan, BBN (tappan@g.bbn.com)
B. Croft, Stanford (croft@csli.stanford.edu)
R. Chandhok, CMU (chandhok@gnome.cs.cmu.edu)
This note describes a system for providing AppleTalk(R) [1] services in the
DARPA Internet. In particular, the assignment of one or more well known UDP
[2] ports to provide key services is proposed. Such an assignment would
help structure and strengthen an IP service that has been in use at internet
sites for over 2 years now.
1. Introduction
The AppleTalk protocol family is primarily used by Apple computers.
However, it is also a built in networking protocol for print, file and other
services that can be used by other computers. In the last three to four
years a number of groups have cooperated in standards to connect AppleTalk
hosts into an IP environment [3,4]. Indeed, Apple Computer itself has
announced support for IP in addition to AppleTalk.
Another outgrowth of this standard is the ability for IP hosts to
communicate to AppleTalk hosts and peripherals. This is accomplished by
encapsulating (or tunneling) AppleTalk packets inside of UDP packets which
in turn calls on the Internet Protocol (IP) [5] to deliver the datagrams.
The reasons for using encapsulation are twofold. First, many sites do not
have the time or the ability to add another protocol family to their OS
kernel. Second, most sites have IP routers that would not forward AppleTalk
packets - using encapsulation allows the exploitation of existing network
management facilities. It is beyond the scope of this document to describe
the routing and gateway arrangements between the two protocol families. It
is also beyond this document to fully describe the AppleTalk protocol
family.
It is the point of this document to codify and standardize a mapping between
ports in the AppleTalk domain (specifically sockets in the Datagram Delivery
Protocol layer of AppleTalk [1]) to ports and port ranges in the domain of
UDP. This is particularly necessary as there is a need for a small number
of well know ports in order to providing this service in a reliable and
secure fashion. It is desirable that these ports be set aside [6] as to
avoid conflict with other local service.
Unless otherwise indicated, all numeric quantities in this document are
decimal numbers.
2. Required AppleTalk Services
In the AppleTalk protocol family, services are provided by advertisement of
a name consisting of an object name, a type name, and a zone. This naming
triple is usually written in the form "object:type@zone". The object name
is an arbitrary string (up to 31 characters), the type name is a descriptive
string up to 31 characters, and the zone name is also a string of up to 31
characters. Zones are logical partitions of an AppleTalk internet, and that
name space is managed by gateways and bridges. The service providers
themselves manage the type and object name space, and the "Name Binding
Protocol" (NBP) specifications outlines ways to register services, remove
services, and resolve conflicts. For reference, the NBP protocol bears
similarity to the Resource Naming Protocol [7].
Registration of a service via the Name Binding Protocol provides a mapping
from named services to AppleTalk addresses (net,node,port). Thus, it is at
the core of the AppleTalk protocol family. When such services are provided
by servers on an IP host, it is required that there be a mapping from the
AppleTalk port numbers to actual UDP ports. An alternative would be to
multiplex all encapsulated AppleTalk packets through a single UDP port, but
this approach has too many drawbacks to be practical.
To provide a reasonable level of reliability when running on an IP host, NBP
is usually implemented on a priviliged and well known UDP port. It is
essential that this continue. It is also important that the AppleTalk Echo
Protocol handler be running on a privileged WKS, to allow other AppleTalk
hosts to determine quantities like round trip time (indeed, to discover if
the host is on the net at all).
3. Summary
The following is requested of the NIC.
In the best case, the assignment of eight (8) contiguous UDP ports in the
range 0..1024. This would allow for future growth and the following mapping
to AppleTalk well known ports:
0 invalid, not used (not assigned by NIC)
1 RTMP (Routing Table Maintenance Protocol)
2 NBP (Name Binding Protocol)
3 'reserved'
4 ECHO (Echo Protocol)
5 'reserved'
6 ZIS (Zone Information Service)
7 'reserved'
8 'reserved'
As stated before, these services will use UDP and IP as a transport layer.
The socket to port mapping will then be accomplished as follows by the
IP/AppleTalk Gateway:
IF the packet's AppleTalk address is on the AppleTalk cable THEN
route normally over appletalk
ELSE if the packet' AppleTalk address is on the IP (ethernet) cable THEN
find a route (IP address) to the host
convert the AppleTalk socket to a UDP port with:
if the socket is in the reserved range (1..8) map to a WKS+socket
else map to a non-reserved range BASE+socket
route over the IP network
These ports will be used to replace arbitrary and de facto port numbers that
are currently in use. The user community of encapsulated AppleTalk is
growing, and this is the first step toward full integration into the IP
internet.
REFERENCES
[1] Inside AppleTalk, Apple Computer.
[2] Postel, J.
User Datagram Protocol.
RFC 768, USC/Information Sciences Institute, August, 1980.
[3] Croft, B., Kim, C, Tappan, D.,
AppleTalk / Ethernet Gateway - IP Version (KIP), Release Notes.
October 1986 and January 1988
[4] Kim, C., Schilit, B.,
Columbia AppleTalk Package (for use with AppleTalk/Ethernet Gateway),
Release Notes,
March 1987 and March 1988
[5] Postel, J.
Internet Protocol - DARPA Internet Program Protocol Specification.
RFC 791, USC/Information Sciences Institute, September, 1981.
[6] Reynolds, J., and J. Postel.
Assigned Numbers.
RFC 870, USC/Information Sciences Institute, October, 1983.
[7] Accetta, M.
Resource Location Protocol.
RFC 887, USC/Information Sciences Institute, December 1983.