Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ulysses!smb
From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: IP over X.25 (request for info)
Message-ID: <11194@ulysses.homer.nj.att.com>
Date: 8 Feb 89 03:49:05 GMT
References: <8902071459.AA22881@redrump.spider.co.uk>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 31

In article <8902071459.AA22881@redrump.spider.co.uk>, keith@SPIDER.CO.UK (Keith Mitchell) writes:
> Address mapping for this stuff is something of an issue. At present
> we use a lookup table, which is the only way of really doing the
> job, but if you have a lot of WAN destinations to talk to then there
> is a danger of guzzling up lots of kernel memory.

I have an implementation of IP over Datakit(r) VCS circuits that I did
for 4.3bsd; I had the same problems.  One thing I did was to do call
setup from user-level.  If a circuit to a destination is needed, but none
is available, the IP address is passed to a daemon process; this process
looks up the dialstring, makes the call, and hands the circuit back to
the dkip driver.  Because I'm using a user-level process, the mappings
can reside in a file.

The problem, though, is that *lots* of IP drivers need this sort of lookup,
especially for wide-area non-broadcast nets.  Dkip has one version, assorted
X.25 implementations have their own, dial-up SLIP needs analogous data,
etc.  Perhaps we can find some way to store the information via the
Domain Name System.  What we'd need, more or less, is a new record type
PHYSADDR in class IN; its data field would contain a type code (Datakit VCS,
X.25, etc., and a type-dependent set of dialing instructions.  The inverse
mapping, or -- more likely -- the equivalent to the INADDR.ARPA records would
be useful as well, for validation of incoming calls.

I'm not entirely happy with this idea, though; the format of the dialing
instructions is rather too variable for a single record type.  But the
PHYSADDR record needs to be tied to the IN class, since IP is the primary
client for the information.  Suggestions, anyone?

		--Steve Bellovin
		smb@ulysses.att.com