bmug@garnet.berkeley.edu (BMUG) (08/26/89)
Has anyone heard whether someone is actively working on software
which will encapsulate LocalTalk packets in IP packets?
I know a K-box will do this, but we're more interested in
a software implementation. Will Apple's internet router do
this? Or anything from InfoSphere?
I asked several people at MacWorld Boston the encapsulation
question, and got replies such as, "Hmmm, that'd be a good idea;
I really don't know."
Netters? Email would be fine, and I'll summarize if there's
interest. I'm also available to sign non-disclosure agreements :-).
John Heckendorn
/\
BMUG ARPA: bmug@garnet.berkeley.EDU A__A
1442A Walnut St., #62 BITNET: bmug@ucbgarne |()|
Berkeley, CA 94709 Phone: (415) 549-2684 | |Ravinder.Chandhok@CS.CMU.EDU (Rob Chandhok) (08/28/89)
I broached this subject a while ago on info-appletalk, and the only people (company) that seems to be interested is Kinetics, a division of someone, a wholly owned subsidary of someone else. If you can get past their name, the people there are quite knowlegable about the implications of a software based "IPTalk" driver for the Mac. Problems arise when you consider using MacTCP, however, since you have to listen to 256 UDP ports. It would be a lot easier if Apple would let you open listeners for a range of ports, since MacTCP currently has a limit of 64 ports. In addition, I think the actual specs of "IPTalk" should be committed to RFC form, so that the KBOX can talk to IPTalk can talk to CAP, without arguing whose hack is the right hack. I'll help do it, if I get enough committe members. That's the way we did the NIC assigned port numbers for "IPTalk" (the dreaded 200 range). Rob Chandhok
tjh+@ANDREW.CMU.EDU (Tom Holodnik) (08/28/89)
From: Rob Chandhok <Ravinder.Chandhok@CS.CMU.EDU>
To: BMUG <agate!garnet.berkeley.edu!bmug@ucbvax.berkeley.edu>
Cc: info-appletalk@ANDREW.CMU.EDU
Subject: Re: Encapsulated LocalTalk in IP Packets (query)
In-Reply-To: Your message of 26 Aug 89 00:41:23 +0000.
<1989Aug26.004123.29350@agate.uucp>
Date: Mon, 28 Aug 89 09:04:48 EDT
Message-Id: <538.620312688@GNOME.CS.CMU.EDU>
Sender: Ravinder.Chandhok@GNOME.CS.CMU.EDU
I broached this subject a while ago on info-appletalk, and the only
people
(company) that seems to be interested is Kinetics, a division of
someone, a
wholly owned subsidary of someone else. If you can get past their name,
the
people there are quite knowlegable about the implications of a software
based "IPTalk" driver for the Mac. Problems arise when you consider
using
MacTCP, however, since you have to listen to 256 UDP ports. It would be
a
lot easier if Apple would let you open listeners for a range of ports,
since
MacTCP currently has a limit of 64 ports.
In addition, I think the actual specs of "IPTalk" should be committed to
RFC
form, so that the KBOX can talk to IPTalk can talk to CAP, without
arguing
whose hack is the right hack. I'll help do it, if I get enough committe
members. That's the way we did the NIC assigned port numbers for
"IPTalk"
(the dreaded 200 range).
Rob Chandhokamanda@intercon.uu.net (Amanda Walker) (08/31/89)
Well, we don't have any commercial interest in AppleTalk-over-IP, but I am personally interested enough that I will volunteer to start a mailing list and start working up an RFC, unless someone at Kinetics would rather do it... If no one else pipes up in the next week or so, I'll set up the list and get things started. -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
amanda@intercon.uu.net (Amanda Walker) (09/01/89)
In article <RICH.89Aug31093708@sendai.sendai.ann-arbor.mi.us>, rich@sendai.sendai.ann-arbor.mi.us (K. Richard Magill) writes: > Why is this an issue? From the IP side, this is just another packet. > from the ddp side, IP is just another lap. arp for your ether > addresses, aarp for your appletalk addresses, where's the grief? > assigning a protocol number to ddp-in-IP? > > Conceptually simple. Those parts, yeah. Then we get to things like: - Broadcasts: AppleTalk likes broadcasts, TCP/IP networks don't. It would be nice to have some kind of standardized ZIP to DNS mapping so that every time someone on the Internet brings up the Chooser, the rest of us aren't swamped with directed broadcasts from all of the gateways. - Routing: It's stupid to duplicate connectivity information; mapping RTMP to RIP (or whatever), even if only partially, would be a big win. In short, except for trivial cases (like an IP "tunnel" between two parts of an organization's AppleTalk internet), what we need is more along the lines of a transport-level gateway, rather than simple encapsulation. -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
liam@cs.qmc.ac.uk (William Roberts) (09/05/89)
I wrote this some while ago and got absolutely NO RESPONSE.
Undaunted, I offer it again as a starting point for an RFC for
IPTalk, KIP, call it what you will.
Things I can currently see wrong with it are:
* Doesn't deal with RTMP or ZIP in any way
* Doesn't specify the significance (if any) attributed to the
UDP port number used by the sender of a packet; I think that
the KIP0688 gateway code is doing something with this...
* It seems too short :-)
I suggest that the person who offered to organise an RFC be the
person who combines this and any responses into a workable RFC
document; I am about to be snowed under with setting up a new
teaching lab (90 A/UX Mac IIcxs) so I won't have the time to do
the job properly.
William Roberts ARPA: liam@cs.qmc.ac.uk
Queen Mary College UUCP: liam@qmc-cs.UUCP AppleLink: UK0087
190 Mile End Road Tel: 01-975 5250
LONDON, E1 4NS, UK Fax: 01-980 6533
--------------------------------------------------------------
1. The KIP Protocol
1.1 The KIP protocol specifies a way of transporting AppleTalk
packets, including LAP headers, using UDP/IP packets. It
also defines the UDP port numbers to be used on an IP host
that wishes to emulate the AppleTalk socket mechanism.
1.2 KIP does not define anything to do with the interpretation
of the contents of the AppleTalk packet, nor does it deal
with the routing of AppleTalk packets using KIP as a
transport mechanism. KIP does not specify how the AppleTalk
packets are obtained, nor what happens to them after the
UDP/IP protocol has delivered them.
1.3 Every instance of KIP has associated with it an AppleTalk
node and network number for the purposes of the AppleTalk
protocols transported via KIP.
1.3 KIP does not address the problem of associating AppleTalk
node and network numbers to IP hosts and networks, other
than to require a mechanism whereby broadcast AppleTalk
packets (addressed to node 255) are sent to all known
KIP implementations which have the appropriate AppleTalk
network number.
1.4 It is suggested that IP broadcast be used to implement
AppleTalk broadcast, that a single IP network correspond to a
single AppleTalk network and individual IP hosts correspond
to individual AppleTalk nodes. This may not be practical
or desirable in all circumstances, especially when KIP is
used to transport AppleTalk packets through an IP Internet
that is being used solely to connect AppleTalk gateways.
1.5 KIP does not address the problem of locating AppleTalk
gateways that respond to KIP: it is suggested that KIP
implementations be configured at runtime with the IP
address of a known gateway that implements KIP.
2. The KIP Encapsulation
2.1 A KIP packet consists of a UDP/IP packet whose data field
contains:
Bytes 0-2: an AppleTalk LAP header
Bytes 3+ : an AppleTalk DDP packet and contents in
accordance with the LAP header and the
specification of the AppleTalk protocols.
A KIP packet may be larger than is strictly necessary to
hold the AppleTalk packet, and may use all of the facilities
implied by the UDP/IP specification. The LAP-only headers used
for contention on the LocalTalk medium are not required by
KIP and should not be encapsulated.
2.2 The KIP protocol associates a UDP port number with the
available AppleTalk socket numbers, for the convenience of
hosts wishing to use UDP/IP port contention to simulate
contention for AppleTalk sockets between host programs
implementing AppleTalk protocols.
2.3 KIP associates the UDP port numbers as follows:
AppleTalk Socket UDP Port
1-127 768 + (AppleTalk socket)
128-254 16384 + (AppleTalk socket)
The NIC has registered UDP port numbers 201-208 for
AppleTalk services: a conforming KIP implementation may
use UDP port numbers 201-327 as the values corresponding to
AppleTalk sockets 1-127 by using 200 instead of 768 as the
"translation factor".
2.4 Any implementation which uses either port numbers starting
from 200 or port numbers staring from 768 is deemed to be
a conforming implementation of KIP: if it is necessary to
distinguish then the name "KIP" without qualification refers
to the use of port numbers in the 768 range. It is expected
that implementations of KIP will be able to use either
scheme, either by runtime configuration or compile time
options.
2.5 KIP implementations are not required to cope with both
schemes at once, though they may choose to do so. Packets
accepted under one scheme should probably have KIP replies
addressed in the same manner.
2.6 KIP implementors are requested (in the tradition of IP) to
be generous in what their implementation accepts; in
particular if the content of an AppleTalk packet contained
inside a KIP packet imply that it is addressed to an AppleTalk
socket that does not correspond to the UDP port through
which it was received, the KIP implementation should
forward it to the appropriate UDP port.
--------------------------------------------------------------
--
William Roberts ARPA: liam@cs.qmc.ac.uk
Queen Mary College UUCP: liam@qmc-cs.UUCP AppleLink: UK0087
190 Mile End Road Tel: 01-975 5250
LONDON, E1 4NS, UK Fax: 01-980 6533