Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!munnari.oz.au!ditmela!smart From: smart@ditmela.oz (Robert Smart) Newsgroups: comp.protocols.tcp-ip.domains Subject: Re: in-addr.arpa domains outside the USA. Message-ID: <11716@ditmela.oz> Date: 30 May 90 00:56:09 GMT References: <9005281622.AA00948@Gipsi.Gipsi.Fr> <21626@boulder.Colorado.EDU> Reply-To: smart@ditmela.oz.au (Robert Smart) Distribution: inet Organization: CSIRO, Division of Information Technology, Australia Lines: 45 In article <21626@boulder.Colorado.EDU> huntting@sel.bldrdoc.gov (Brad Huntting) writes: > > This would distribute some of the load of the in-addr.arpa domain > away from the root, and cut down on unnecessary long haul queries. > It may be a bit late for Brad's scheme. I have an alternative. Context: We are all familiar with schemes which tunnel IP packets through other networks: DECNET, LU 6.2, and many more. Recently someone (Phil Karn?) proposed a scheme for tunnelling IP packets over an IP network. The objective in that case was to reconnect a Class A network which had multiple links to the Internet and had become internally partitioned. I have an alternative use for such a scheme. There are many situations where we would like to contact the nearest host with property X. X might be "holds the GNU software" or "is an e-mail gateway to BITNET" or "is a nameserver for IN-ADDR.ARPA". Now one thing the Internet already knows how to do is find the shortest route from us to a particular network. So I propose that we create logical networks which are actually spread across the Internet and are internally connected by IP over IP tunneling. Let's suppose that all BITNET gateways are on network 193.1.1. There are various ways we could find the nearest host in this network. We could send an echo request to 193.1.1.255 but that might be unfriendly. We could try to contact 193.1.1.0 assuming that that means any host in 193.1.1. We could set it up so that clients contact 193.1.1.1 and the first host that that arrives at will pretend to be 193.1.1.1 -- but having multiple hosts pretending to be the same host seems unwise. Use of host number 0 to mean "any host in this network" seems like the best idea to me, but I could well be ignorant of problems that this would cause. You need a mechanism for the caller to convert the 193.1.1.0 destination address to the address of the actual destination once a response has been received: it mustn't keep using 193.1.1.0 or subsequent packets might go to a different host. Incidentally it would be nice if IP in IP tunneling could be done at the IP level, and not have to go up to the UDP level. This can be achieved if we add a new IP type field (alongside TCP and UDP) for IP-IN-IP. Actually for some of the proposed applications there would be no need for these logical networks to be internally connected, but breaking IP semantics to that extent seems dubious. Bob Smart