Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!wuarchive!wugate!uunet!intercon!amanda@intercon.uu.net From: amanda@intercon.uu.net (Amanda Walker) Newsgroups: comp.protocols.appletalk Subject: Re: Encapsulated LocalTalk in IP Packets (query) Message-ID: <1427@intercon.UUCP> Date: 31 Aug 89 17:35:54 GMT References: <8908310220.AA14928@cuba.Cayman.COM> Sender: news@intercon.UUCP Reply-To: amanda@intercon.uu.net (Amanda Walker) Organization: InterCon Systems Corporation Lines: 28 In article , 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