Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!GATEWAY.MITRE.ORG!barns
From: barns@GATEWAY.MITRE.ORG (Bill Barns)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  IP over X.25 (request for info)
Message-ID: <8902031652.AA12780@gateway.mitre.org>
Date: 3 Feb 89 16:52:15 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 40

Paul,

If you have not made the acquaintance of the Defense Data Network (DDN)
X.25 Standard Service, it would probably be a good idea to do so.  It
will NOT answer your immediate question, but considering the type of
product you are developing, it seems to me that it would be rather
silly not to support the DDN Standard Service as a configuration
option.  That may be the largest single market for IP over X.25.  I
will not describe it in detail as there are documents for that, but
very briefly, it uses an algorithmic transformation between IP
addresses and X.121 addresses.  This transformation has some
limitations which make it undesirable or unusable in many other
situations, but it seems like it would be worth implementing, or at
least leaving hooks for.

DDN Standard X.25 has a couple of other twists which involve
network-specific X.25 facilities at SVC initiation, as well as the CUD
which is essentially as described in the RFC.  Also, it imposes some
implicit restrictions on the assignment of IP datagrams to X.25 VCs, so
that Precedence will work.  If you code it right to start with, the
extra work is minimal; retrofitting may or may not be easy, "depending."

The common method of address handling (that I know of) involves keeping
static address mapping tables in all the X.25 endpoints involved.  These
tables associate IP addresses with X.121 DTE addresses.  This method has
the advantage of providing the basis for some security checking.  Since
the static configuration table lists all the DTE's that are expected to
call and talk IP with you, you can clear calls from impostors.  You would
also have the IP layer do its routing based on this information, which
prevents a legitimate DTE address from acquiring packets destined to an
IP address properly belonging to some other DTE.  The utility of this
depends on the validity of the DTE address, but there is some validation
of this in most public data networks, I believe.  I would certainly want
such a feature to be available in any box that I used on a public data
network in this way.

Send mail if you would like to chat about this further...  this seems
like enough for the public wire.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org