[comp.protocols.iso.x400] Implementing generic service in the Internet

smart@manta.mel.dit.csiro.au (Robert Smart) (05/24/91)

[Sorry for posting this twice. It is also posted to comp.protocols.tcp-ip
but I am also posting it here since it is a followup to Christian
Huitema's proposal.]

In a recent message in comp.protocols.iso.x400, Christian Huitema
has suggested that it would be desirable if internet users could
address mail to the X.400 world in the form

	/C=us/.../@x400.net

I.e. specify a generic "@gateway" instead of users having to know
specific gateways. This arose from the plan to do the converse on
the X.400 side.

This brings up a recurring theme. We want to connect to the nearest
machine offering some particular service: the nearest BITNET gateway;
the nearest root nameserver; the nearest font server for some font;
the nearest ftp server for gnu software.

A while ago there was a fascinating suggestion posted on how to do
this sort of thing using IP distance servers. That suggestion has
not been taken up and I would like to suggest an alternative that is
much simpler.

The layer that understands distance in IP is the IP routing layer.
So this is the only layer (currently) which can be used to discover
"closeness". The idea is to create generic addresses to go with
the generic names.

Let us suppose that subnets 192.255.x are used for this purpose.
If the generic X.400 gateway is given 192.255.17 then the entry
in the DNS will be:

   x400.net.	IN	A	192.255.17.1

All the hosts which provide this service will have at least two IP
interfaces: their "real" interface to the IP network and a fake
interface with network number 192.255.17.1. That interface will be
"up" whenever the indicated service is available. [This is
actually quite nice: you can take a service down temporarily
and requests for the service will automatically go to the next
nearer server.]

This technique will work well as-is for stateless UDP services.
For other services there may be occasions where the nearest server
changes in the middle of a conversation and the TCP connection
gets blown away. For protocols that retry like e-mail this is not
a great disaster but it is undesirable even there.

So all the servers advertising the route to 192.255.x services
should provide a new service on a new well-known-port: that service
will be a UDP query with the response being the servers "real"
domain name and real IP addresses. This service could be used in
various ways, but the most obvious is for the subroutine which
is equivalent to unix's "gethostbyname" (and other subroutines
which discover IP addresses) to say "this is a 192.255.x number;
therefore I shouldn't just return it: I should ask it for its
real IP address and return that".

Though the full use of these generic IP addresses should be restricted
to hosts that implement the real-IP-discovery protocol, they will
still work fine for existing software where the service is a stateless
UDP service. They can also be used where the users make a conscious
choice to put up with the reliability problems which are likely to be
very mild: probably no worse than we see from my edge of the
Internet galaxy already.

----------------------------------------------------------------

It is very easy to implement these false IP addresses: you can
do it today in unix by ifconfiging some unused device like a
pty. It would also be easy to write a fake interface that gives
host unreachable ICMPs for host numbers other than .1.

Bob Smart <smart@mel.dit.csiro.au>

hta@isolde.er.sintef.no (Harald Tveit Alvestrand) (05/28/91)

In article <1991May24.013826.7713@mel.dit.csiro.au>, smart@manta.mel.dit.csiro.au (Robert Smart) writes up an idea for a new way to handle "generic services"
by making a specific IP subnet the "place to be" for generic services, and
adding a "discovery protocol".

Question:
How is this different from adding multiple service records to the DNS
(in the mail instance, multiple MX records for x400.net) and making
the users of this calculate the IP distance?

Yes, I know......stupid machines will go on using the first one.
But still, guaranteeing IP-address collisions and using the routing protocols
to carry service information seems rather a strange path to me.


                   Harald Tveit Alvestrand
Harald.Alvestrand@delab.sintef.no
C=no;PRMD=uninett;O=sintef;OU=delab;S=alvestrand;G=harald
+47 7 59 70 94