Suggestions for improved host table distribution

M.R. Crispin

doi:10.17487/RFC0849

[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

This is a modified version of the Internet RFC suitable for machine-translating. Original version is available here: RFC849

UNKNOWN

Network Working Group                                       Mark Crispin
Request for Comments: 849                                       Stanford
                                                                May 1983

SUGGESTIONS FOR IMPROVED HOST TABLE DISTRIBUTION

This RFC may be something unique among modern-day RFC's, an RFC
that actually is a request for comments. The issue dealt with is that of a naming registry update procedure, both as exists currently and what could exist in the future. None of the proposed solutions are intended as standards at this time; rather it is hoped that a general consensus will emerge as the appropriate solution, leaving eventually to the adoption of standards.

THE PROBLEM

I am somewhat dissatisfied with the current level of Internet name
service and name registry updating. Each site is expected to individually maintain a copy of the [SRI-NIC]<NETINFO>HOSTS.TXT file, and in fact has to, since SRI-NIC is simply not reliable enough to depend upon as a name server. Neither the Tenex operating system nor the Foonly computer are known for exceptional reliability or performance. Probably they serve the NIC's internal operations well; that is not at issue. What is needed is a name service that is available at all times. Only then could a site sacrifice maintaining its own local copy of "the host table".

The NIC indirectly acknowledges this, by providing a service by
which the entire Internet name registry can be dumped, as well as ANONYMOUS FTP access to the <NETINFO>HOSTS.TXT file. The problem is, some individual has to know to retrieve the latest version of the file from the NIC. The NIC has not always been careful to announce updates to the name registry. My experience with maintaining an independent name registry from the NIC's in the past leads me to appreciate the NIC's problems.

There also seems to be no good automated way to cross-check the
version at the local site with the NIC's. It is clearly inefficient to go to the effort of retrieving the same version of the host table that already has been installed on site.

SOME SOLUTIONS

One could argue that a solution is to replace or augment the
present SRI-NIC system with VAX Unix system(s) dedicated to name service and network information. A reliable and highly-responsive name service would ultimately lead to the elimination of the necessity to maintain copies of the registry locally. This solution requires money, time, and effort, which may or may not be immediately available; it must therefore be considered a longer-term solution. thorough updating of the various local copies of the name tables. I have several suggestions in this area, and would like to hear comments (I said this was an RFC that requested comments!):

Crispin                                                         [Page 1]


     A more short-term solution is to make possible faster and more

(1) a new protocol by which the NIC could ship updated name
registries to the hosts itself. This would take the form of a server process on each site listening on a registered port for updates from certain "trusted" sites (specifically SRI-NIC but possibly other sites as well). This would allow for nearly immediate updates for cooperating sites, provided that the hosts in question are up. There should be some sort of checksum applied to the updated name registry, to make sure it arrived complete and intact.

(2) a new protocol by which the NIC will report the current
"version" of the host table. Tenex and TOPS-20 sites would find the use of the file generation number natural. I presently maintain a SYSTEM:HOSTS.TXT with the same generation as it existed on the NIC, and just check at the NIC from time to time to see if the generation number changed there. I would like to automate this.

(3) A variation on (1), whereby the NIC would mail the updated host
table to a mailing list of "host table update" recepients and each site would establish its own update procedures. This is the simplest to implement for the NIC, but is fraught with all sorts of problems. Mail is not a good means for bulk-shipping files to many recepients, especially when the files are likely to become hugh.

I like (1) best of these three, because that would guarantee
immediate updating without a local necessity to periodically poll the NIC. That does place the burden on the NIC to make sure all sites receive the update, and also requires that the NIC remember which sites are dead to retry the update later. This leads me to what I think is the best solution, which is:

(4) A combination of (1) and (2). The NIC will ship updates to all
hosts which are registered with it to receive the updates, and will try only once. Each site, as part of its system startup procedure, will run a program to poll the NIC for a possible update and if one is available retrieve it. As a backup, there could also be a periodic poll on, say, a daily basis.

Crispin [Page 2]

Translate documents to 日本語, svenska, Nederlands, Deutsch, français, русский, italiano, español, Tiếng Việt, polski, português, 中文, українська, català, norsk, فارسی, suomi, Bahasa Indonesia, العربية, čeština, 한국어, Bahasa Melayu, magyar, română, српски and other languages.