RFC849 - Suggestions for improved host table distribution

Network Working Group                                       Mark CrispinRequest for Comments: 849                                       Stanford                                                                May 1983            SUGGESTIONS FOR IMPROVED HOST TABLE DISTRIBUTION     This RFCmay be something unique among modern-day RFC's, an RFCthat actually is a request for comments.  The issue dealt with is thatof a naming registry update procedure, both as exists currently and whatcould exist in the future.  None of the proposed solutions are intendedas standards at this time; rather it is hoped that a general consensuswill emerge as the appropriate solution, leaving eventually to theadoption of standards.                                THE PROBLEM     I am somewhat dissatisfied with the current level of Internet nameservice and name registry updating.  Each site is eXPected toindividually maintain a copy of the [SRI-NIC]<NETINFO>HOSTS.TXT file,and in fact has to, since SRI-NIC is simply not reliable enough todepend upon as a name server.  Neither the Tenex Operating system northe Foonly computer are known for exceptional reliability orperformance.  Probably they serve the NIC's internal operations well;that is not at issue.  What is needed is a name service that isavailable at all times.  Only then could a site sacrifice maintainingits own local copy of "the host table".     The NIC indirectly acknowledges this, by providing a service bywhich the entire Internet name registry can be dumped, as well asANONYMOUS FTP access to the <NETINFO>HOSTS.TXT file.  The problem is,some individual has to know to retrieve the latest version of the filefrom the NIC.  The NIC has not always been careful to announce updatesto the name registry.  My experience with maintaining an independentname registry from the NIC's in the past leads me to appreciate theNIC's problems.     There also seems to be no good automated way to cross-check theversion at the local site with the NIC's.  It is clearly inefficient togo to the effort of retrieving the same version of the host table thatalready has been installed on site.                             SOME SOLUTIONS     One could argue that a solution is to replace or augment thepresent SRI-NIC system with VAX Unix system(s) dedicated to name serviceand network information.  A reliable and highly-responsive name servicewould ultimately lead to the elimination of the necessity to maintaincopies of the registry locally.  This solution requires money, time, andeffort, which may or may not be immediately available; it must therefore
                         be considered a longer-term solution.Crispin                                                         [Page 1]     A more short-term solution is to make possible faster and morethorough updating of the various local copies of the name tables.  Ihave several suggestions in this area, and would like to hear comments(I said this was an RFCthat requested comments!):     (1) a new protocol by which the NIC could ship updated nameregistries to the hosts itself.  This would take the form of a serverprocess on each site listening on a registered port for updates fromcertain "trusted" sites (specifically SRI-NIC but possibly other sitesas well).  This would allow for nearly immediate updates for cooperatingsites, provided that the hosts in question are up.  There should be somesort of checksum applied to the updated name registry, to make sure itarrived 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 useof the file generation number natural.  I presently maintain aSYSTEM:HOSTS.TXT with the same generation as it existed on the NIC, andjust check at the NIC from time to time to see if the generation numberchanged there.  I would like to automate this.     (3) A variation on (1), whereby the NIC would mail the updated hosttable to a mailing list of "host table update" recepients and each sitewould establish its own update procedures.  This is the simplest toimplement for the NIC, but is fraught with all sorts of problems.  Mailis 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 guaranteeimmediate updating without a local necessity to periodically poll theNIC.  That does place the burden on the NIC to make sure all sitesreceive the update, and also requires that the NIC remember which sitesare dead to retry the update later.  This leads me to what I think isthe best solution, which is:     (4) A combination of (1) and (2).  The NIC will ship updates to allhosts which are registered with it to receive the updates, and will tryonly once.  Each site, as part of its system startup procedure, will runa program to poll the NIC for a possible update and if one is availableretrieve it.  As a backup, there could also be a periodic poll on, say,a daily basis.