smart@manta.mel.dit.csiro.au (Robert Smart) (05/24/91)
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 because there is a 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>