initial commit of ebook 39HEADmain

2 files changed, 1339 insertions, 0 deletions

diff --git a/old/hhgi10.txt b/old/hhgi10.txt
new file mode 100644
index 0000000..d96cc79
--- /dev/null
+++ b/old/hhgi10.txt
@@ -0,0 +1,1339 @@
+A Project Gutenberg Etext of Hitchhiker's Guide to the Internet.
+*******This file should be named hhgi10.txt or hhgi10.zip*******
+
+Corrected EDITIONS of our etexts get a new NUMBER, xxxxx11.txt.
+VERSIONS based on separate sources get new LETTER, xxxxx10a.txt.
+
+Project Gutenberg is working on creating a simple, childlike (if
+you will) network guide, "A Child's Garden of the Internet."  If
+you have any suggestions for inclusions, and/or could take a few
+minutes to write a "Ten Minute Tuturial" on any subject you feel
+worthwhile.  These should be directed at the absolute novices of
+the networks, and should presume little or no previous knowledge
+(we are even including how to control-c in each tutorial, as the
+tutorials are each supposed to be a stand alone event taking the
+nominal "Ten Minutes" to expose the novices to a particular part
+of the networks, or to a particular resource. . .even if that is
+a resource directed at other resources, such as Gopher, Prospero
+and others.  This could be an easy way to get your name in print
+in both etext and paper publishing, as we had hardly announced A
+Child's Garden before we were approached for paper publishing.
+
+Information about Project Gutenberg (one page)
+
+We produce about one million dollars for each hour we work.  One
+hundred hours is a conservative estimate for how long it we take
+to get any etext selected, entered, proofread, edited, copyright
+searched and analyzed, the copyright letters written, etc.  This
+projected audience is one hundred million readers.  If our value
+per text is nominally estimated at one dollar, then we produce a
+million dollars per hour; next year we will have to do four text
+files per month, thus upping our productivity to two million/hr.
+The Goal of Project Gutenberg is to Give Away One Trillion Etext
+Files by the December 31, 2001.  [10,000 x 100,000,000=Trillion]
+This is ten thousand titles each to one hundred million readers.
+
+
+Send to:
+
+David Turner, Project Gutenberg
+Illinois  Benedictine  College
+5700  College  Road
+Lisle, IL 60532-0900
+
+All communication to Project Gutenberg should be carried out via
+Illinois Benedictine College unless via email.  This is for help
+in keeping me from being swept under by paper mail as follows:
+
+1.  Too many people say they are including SASLE's and aren't.
+
+2.  Paper communication just takes too long when compared to the
+    thousands of lines of email I receive every day.  Even then,
+    I can't communicate with people who take too long to respond
+    as I just can't keep their trains of thought alive for those
+    extended periods of time.  Even quick responses should reply
+    with the text of the messages they are answering (reply text
+    option in RiceMail).  This is more difficult with paper.
+
+3.  People request disks without specifying which kind of disks,
+    it can be very difficult to read an Apple disk on an IBM.  I
+    have also received too many disks that cannot be formatted.
+
+My apologies.
+
+We would strongly prefer to send you this information by email
+(Internet,  Bitnet, Compuserve, ATTMAIL or MCImail).
+Email requests to:
+
+Internet:    hart@vmd.cso.uiuc.edu 
+Bitnet:      hart@uiucvmd or hart@uiucvmd.bitnet
+Compuserve:  >internet:hart@vmd.cso.uiuc.edu  
+Attmail:     internet!vmd.cso.uiuc.edu!HART   
+MCImail:  ADDRESS TYPE: MCI / EMS: INTERNET / MBX:
+hart@vmd.cso.uiuc.edu
+******
+If you have an FTP program (or emulator), please:
+
+FTP directly to the Project Gutenberg archives:
+ftp mrcnext.cso.uiuc.edu
+login:  anonymous
+password:  your@login
+cd etext/etext91
+or cd etext92 [for new books]  [now also cd etext/etext92]
+or cd etext/articles [get suggest gut for more information]
+dir [to see files]
+get or mget [to get files. . .set bin for zip files]
+GET INDEX and AAINDEX (or any file containing "index"
+for a list of books
+and
+GET NEW GUT for general information
+and
+MGET GUT* for newsletters.
+
+**Information prepared by the Project Gutenberg legal advisor**
+
+*START** SMALL PRINT! for ** Hitchhiker's Guide to the Internet
+
+This etext was distributed by Professor Michael S. Hart through
+the Project Gutenberg Association (the "Project").  As with
+other Project Gutenberg-tm etexts, you can (and are encouraged!)
+to copy and distribute it in the United States.  We tell you how
+below.
+
+*BEFORE!* YOU USE OR READ THIS ETEXT
+
+Why is this "Small Print!" statement here?  You know: lawyers.
+They tell us you might sue us if there is something wrong with
+your copy of this etext, even if you got it for free from
+someone other than us, and even if what's wrong is not our
+fault.  So, among other things, this "Small Print!" statement
+disclaims most of our liability to you.
+
+By using or reading any part of this PROJECT GUTENBERG-tm etext,
+you indicate that you understand, agree to and accept this
+"Small Print!" statement.  If you do not, you may receive a
+refund of the money (if any) you paid for this etext by sending
+a request within 30 days of receiving it to the person you got
+it from.  If you received this etext on a physical medium (such
+as a disk), you must return it with your request.
+
+As used in this "Small Print!" statement, the word "Defect"
+includes incomplete, inaccurate or corrupt data, transcription
+errors, a copyright or other intellectual property infringement,
+a defective or damaged disk or other etext medium, a computer
+virus, and computer codes that damage or cannot be read by your
+equipment.
+
+DISCLAIMER
+
+But for the "Right of Replacement or Refund" described below,
+[1] the Project (and any other party you may receive this etext
+from as a PROJECT GUTENBERG-tm etext) disclaims all liability to
+you for damages, costs and expenses, including legal fees, and
+[2] YOU HAVE NO REMEDIES FOR NEGLIGENCE OR UNDER STRICT LIABILI-
+TY, OR FOR BREACH OF WARRANTY OR CONTRACT, INCLUDING BUT NOT
+LIMITED TO INDIRECT, CONSEQUENTIAL, PUNITIVE OR INCIDENTAL
+DAMAGES, EVEN IF YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH
+DAMAGES.
+
+If you discover a Defect in this etext within 90 days of
+receiving it, you will receive a refund of the money (if any)
+you paid for it by sending an explanatory note within that time
+to the person you received it from.  If you received it on a
+physical medium, you must return the Defective copy with your
+note, and such person may choose to alternatively give you a
+replacement copy.  If you received it electronically, such
+person may alternatively give you a second opportunity to
+receive it electronically.
+
+THIS ETEXT IS OTHERWISE PROVIDED TO YOU "AS-IS".  NO OTHER
+WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, ARE MADE TO YOU AS
+TO THE ETEXT OR ANY MEDIUM IT MAY BE ON, INCLUDING BUT NOT
+LIMITED TO WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
+PARTICULAR PURPOSE.
+
+Some states do not allow disclaimers of implied warranties or
+the exclusion or limitation of consequential damages, so the
+above disclaimers and exclusions may not apply to you, and you
+may have other legal rights.
+
+INDEMNITY
+
+You will indemnify and hold the Project, its officers, members
+and agents harmless from all liability, cost and expense, in-
+cluding legal fees, that arise from both [1] distribution of
+this etext for which you are responsible, and [2] any Defect, or
+any alteration, modification or addition to the etext for which
+you are responsible.
+
+LICENSE
+
+Except for modifications in formatting, this is a verbatim copy
+of revision 25 August 1987:
+
+            The Hitchhikers Guide to the Internet
+                        25 August 1987
+
+
+
+                           Ed Krol
+                    krol@uxc.cso.uiuc.edu
+
+
+
+
+ This document was produced through funding of the National
+ Science Foundation.
+
+ Copyright (C) 1987, by the Board of Trustees of The University
+ of Illinois.  Permission to duplicate this document, in whole
+ or part, is granted provided reference is made to the source
+ and this copyright is included in whole copies.
+
+DISTRIBUTION UNDER "PROJECT GUTENBERG-tm"
+
+You may distribute copies of this etext electronically, or by
+disk, book or any other medium if you either delete this "Small
+Print!" statement except for 
+
+The original copyright notice, or:
+
+[1]  Only give exact copies of it.  Among other things, this re-
+     quires that you do not remove or modify the etext or this
+     "Small Print!" statement.  You may however, if you wish,
+     distribute this etext in machine readable binary, com-
+     pressed, mark-up, or proprietary form, including any form
+     resulting from conversion by word processing or hypertext
+     software, but only so long as *EITHER*:
+
+     [*]  The etext, when displayed, is clearly readable.  We
+          consider an etext *not* clearly readable if it
+          contains characters other than those intended by the
+          author of the work, although tilde (~), asterisk (*)
+          and underline (_) characters may be used to convey
+          punctuation intended by the author, and additional
+          characters may be used to indicate hypertext links.
+
+     [*]  The etext may be readily converted by the reader at no
+          expense into in plain ASCII, EBCDIC or equivalent form
+          by the program that displays the etext (as is the
+          case, for instance, with most word processors).
+
+     [*]  You provide, or agree to also provide on request at no
+          additional cost, fee or expense, a copy of the etext
+          in its original plain ASCII form (or in EBCDIC or
+          other equivalent proprietary form).
+
+[2]  Honor the etext refund and replacement provisions of this
+     "Small Print!" statement.
+
+WRITE TO US! We can be reached at:
+
+Internet:     hart@vmd.cso.uiuc.edu
+Bitnet:       hart@uiucvmd
+CompuServe:   >internet:hart@.vmd.cso.uiuc.edu
+Attmail:      internet!vmd.cso.uiuc.edu!Hart
+
+or
+Prof. Michael Hart, Project Gutenberg
+Illinois Benedictine College 
+5700 College Road 
+Lisle, IL 60532-0900 
+
+Drafted by CHARLES B. KRAMER, Attorney
+CompuServe:  72600,2026
+  Internet:  72600.2026@compuserve.com
+       Tel:  (212) 254-5093
+*SMALL PRINT! Ver.06.28.92* Zen and the Art of the Internet*END*
+
+
+There are several versions of this text with printing commands
+included for .xxx and most other publishing formats.  This one
+is strictly intended for etext uses, and has had hyphens at an
+end of line position removed to facilitate searching the text.
+***************************************************************
+ 
+            The Hitchhikers Guide to the Internet
+                        25 August 1987
+
+
+
+                           Ed Krol
+                    krol@uxc.cso.uiuc.edu
+
+
+
+
+ This document was produced through funding of the National
+ Science Foundation.
+
+ Copyright (C) 1987, by the Board of Trustees of The University
+ of Illinois.  Permission to duplicate this document, in whole
+ or part, is granted provided reference is made to the source
+ and this copyright is included in whole copies.
+
+
+ This document assumes that one is familiar with the workings
+ of a non-connected simple IP network (e.g. a few 4.2 BSD
+ systems on an Ethernet not connected to anywhere else).
+ Appendix A contains remedial information to get one to this
+ point.  Its purpose is to get that person, familiar with a
+ simple net, versed in the "oral tradition" of the Internet
+ to the point that that net can be connected to the Internet
+ with little danger to either.  It is not a tutorial, it 
+ consists of pointers to other places, literature, and hints
+ which are not normally documented.  Since the Internet is a
+ dynamic environment, changes to this document will be made
+ regularly.  The author welcomes comments and suggestions.
+ This is especially true of terms for the glossary (definitions
+ are not necessary).
+
+
+
+
+ In the beginning there was the ARPAnet, a wide area
+ experimental network connecting hosts and terminal servers
+ together.  Procedures were set up to regulate the allocation
+ of addresses and to create voluntary standards for the network.
+ As local area networks became more pervasive, many hosts became
+ gateways to local networks.  A network layer to allow the
+ interoperation of these networks was developed and called IP
+ (Internet Protocol).  Over time other groups created long haul
+ IP based networks (NASA, NSF, states...).  These nets, too,
+ interoperate because of IP.  The collection of all of these
+ interoperating networks is the Internet.
+
+ Two groups do much of the research and information work of
+ the Internet (ISI and SRI).  ISI (the Informational Sciences
+ Institute) does much of the research, standardization, and
+ allocation work of the Internet.  SRI International provides
+ information services for the Internet.  In fact, after you
+ are connected to the Internet most of the information in
+ this document can be retrieved from the Network Information
+ Center (NIC) run by SRI.
+
+
+
+ Operating the Internet
+
+ Each network, be it the ARPAnet, NSFnet or a regional network,
+ has its own operations center.  The ARPAnet is run by
+ BBN, Inc. under contract from DARPA.  Their facility is
+ called the Network Operations Center or NOC.  Cornell
+ University temporarily operates NSFnet (called the Network
+ Information Service Center, NISC).  It goes on to the
+
+                             -2-
+
+ regionals having similar facilities to monitor and keep
+ watch over the goings on of their portion of the Internet.
+ In addition, they all should have some knowledge of what is
+ happening to the Internet in total. If a problem comes up,
+ it is suggested that a campus network liaison should contact
+ the network operator to which he is directly connected. That
+ is, if you are connected to a regional network (which is
+ gatewayed to the NSFnet, which is connected to the
+ ARPAnet...)  and have a problem, you should contact your
+ regional network operations center.
+
+
+ RFCs
+
+ The internal workings of the Internet are defined by a set
+ of documents called RFCs (Request for Comments).  The general
+ process for creating an RFC is for someone wanting something
+ formalized to write a document describing the issue and mailing
+ it to Jon Postel (postel@isi.edu).  He acts as a referee for
+ the proposal.  It is then commented upon by all those wishing
+ to take part in the discussion (electronically of course).
+ It may go through multiple revisions.  Should it be generally
+ accepted as a good idea, it will be assigned a number and
+ filed with the RFCs.
+
+ The RFCs can be divided into five groups: required, suggested,
+ directional, informational and obsolete.  Required RFC's (e.g.
+ RFC-791, The Internet Protocol) must be implemented on any host
+ connected to the Internet.  Suggested RFCs are generally
+ implemented by network hosts.  Lack of them does not preclude
+ access to the Internet, but may impact its usability.  RFC-793
+ (Transmission Control Protocol) is a suggested RFC.  Directional
+ RFCs were discussed and agreed to, but their application has never
+ come into wide use.  This may be due to the lack of wide need for
+ the specific application (RFC-937 The Post Office Protocol) or
+ that, although technically superior, ran against other pervasive
+ approaches (RFC-891 Hello).  It is suggested that should the
+ facility be required by a particular site, animplementation
+ be done in accordance with the RFC.  This insures that, should
+ the idea be one whose time has come, the implementation will be
+ in accordance with some standard and will be generally usable.
+ Informational RFCs contain factual information about the
+ Internet and its operation (RFC-990, Assigned Numbers).
+ Finally, as the Internet and technology have grown, some
+ RFCs have become unnecessary.  These obsolete RFCs cannot
+ be ignored, however.  Frequently when a change is made to
+ some RFC that causes a new one to be issued obsoleting others,
+ the new RFC only contains explanations and motivations for the
+ change.  Understanding the model on which the whole facility
+ is based may involve reading the original and subsequent RFCs
+ on the topic.
+
+                             -3-
+
+ (Appendix B contains a list of what are considered to be the
+ major RFCs necessary for understanding the Internet).
+
+
+
+ The Network Information Center
+
+ The NIC is a facility available to all Internet users which
+ provides information to the community.  There are three
+ means of NIC contact: network, telephone, and mail.  The
+ network accesses are the most prevalent.  Interactive access
+ is frequently used to do queries of NIC service overviews,
+ look up user and host names, and scan lists of NIC documents.
+ It is available by using
+
+      %telnet sri-nic.arpa
+
+ on a BSD system and following the directions provided by a
+ user friendly prompter.  From poking around in the databases
+ provided one might decide that a document named NETINFO:NUG.DOC
+ (The Users Guide to the ARPAnet) would be worth having.  It could
+ be retrieved via an anonymous FTP.  An anonymous FTP would proceed
+ something like the following.  (The dialogue may vary slightly
+ depending on the implementation of FTP you are using).
+
+      %ftp sri-nic.arpa
+      Connected to sri-nic.arpa.
+      220 SRI_NIC.ARPA FTP Server Process 5Z(47)-6 at Wed
+17-Jun-87 12:00 PDT
+      Name (sri-nic.arpa:myname): anonymous
+      331 ANONYMOUS user ok, send real ident as password.
+      Password: myname
+      230 User ANONYMOUS logged in at Wed 17-Jun-87 12:01 PDT,
+job 15.
+      ftp> get netinfo:nug.doc
+      200 Port 18.144 at host 128.174.5.50 accepted.
+      150 ASCII retrieve of <NETINFO>NUG.DOC.11 started.
+      226 Transfer Completed 157675 (8) bytes transferred
+      local: netinfo:nug.doc  remote:netinfo:nug.doc
+      157675 bytes in 4.5e+02 seconds (0.34 Kbytes/s)
+      ftp> quit
+      221 QUIT command received. Goodbye.
+
+ (Another good initial document to fetch is
+ NETINFO:WHAT-THE-NIC-DOES.TXT)!
+
+ Questions of the NIC or problems with services can be asked
+ of or reported to using electronic mail.  The following
+ addresses can be used:
+
+      NIC@SRI-NIC.ARPA         General user assistance, document requests
+      REGISTRAR@SRI-NIC.ARPA   User registration and WHOIS updates
+      HOSTMASTER@SRI-NIC.ARPA  Hostname and domain changes and updates
+      ACTION@SRI-NIC.ARPA      SRI-NIC computer operations
+      SUGGESTIONS@SRI-NIC.ARPA Comments on NIC publications and services
+
+                             -4-
+
+ For people without network access, or if the number of documents
+ is large, many of the NIC documents are available in printed
+ form for a small charge.  One frequently ordered document for
+ starting sites is a compendium of major RFCs.  Telephone access is
+ used primarily for questions or problems with network access.
+ (See appendix B for mail/telephone contact numbers).
+
+
+
+ The NSFnet Network Service Center
+
+ The NSFnet Network Service Center (NNSC) is funded by NSF to
+ provide a first level of aid to users of NSFnet should they
+ have questions or encounter problems traversing the network.
+ It is run by BBN Inc.  Karen Roubicek
+ (roubicek@nnsc.nsf.net) is the NNSC user liaison.
+
+ The NNSC, which currently has information and documents
+ online and in printed form, plans to distribute news through
+ network mailing lists, bulletins, newsletters, and online
+ reports.  The NNSC also maintains a database of contact
+ points and sources of additional information about NSFnet
+ component networks and supercomputer centers.
+
+ Prospective or current users who do not know whom to call
+ concerning questions about NSFnet use, should contact the
+ NNSC.  The NNSC will answer general questions, and, for
+ detailed information relating to specific components of the
+ Internet, will help users find the appropriate contact for
+ further assistance.  (Appendix B)
+
+
+
+ Mail Reflectors
+
+ The way most people keep up to date on network news is
+ through subscription to a number of mail reflectors.  Mail
+ reflectors are special electronic mailboxes which, when they
+ receive a message, resend it to a list of other mailboxes.
+ This in effect creates a discussion group on a particular
+ topic.  Each subscriber sees all the mail forwarded by the
+ reflector, and if one wants to put his "two cents" in sends
+ a message with the comments to the reflector....
+
+ The general format to subscribe to a mail list is to find
+ the address reflector and append the string -REQUEST to the
+ mailbox name (not the host name).  For example, if you
+ wanted to take part in the mailing list for NSFnet reflected
+ by NSFNET@NNSC.NSF.NET, one sends a request to
+
+                             -5-
+
+ NSFNET-REQUEST@NNSC.NSF.NET.  This may be a wonderful scheme,
+ but the problem is that you must know the list exists in the
+ first place.  It is suggested that, if you are interested,
+ you read the mail from one list (like NSFNET) and you will
+ probably become familiar with the existence of others.
+ A registration service for mail reflectors is provided by
+ the NIC in the files NETINFO:INTEREST-GROUPS-1.TXT,
+ NETINFO:INTEREST-GROUPS-2.TXT, and NETINFO:INTEREST-GROUPS-
+ 3.TXT.
+
+ The NSFNET mail reflector is targeted at those people who
+ have a day to day interest in the news of the NSFnet (the
+ backbone, regional network, and Internet inter-connection
+ site workers).  The messages are reflected by a central
+ location and are sent as separate messages to each subscriber.
+ This creates hundreds of messages on the wide area networks
+ where bandwidth is the scarcest.
+
+ There are two ways in which a campus could spread the news
+ and not cause these messages to inundate the wide area
+ networks.  One is to re-reflect the message on the campus.
+ That is, set up a reflector on a local machine which forwards
+ the message to a campus distribution list.  The other is
+ to create an alias on a campus machine which places the
+ messages into a notesfile on the topic.  Campus users who
+ want the information could access the notesfile and see the
+ messages that have been sent since their last access.  One
+ might also elect to have the campus wide area network
+ liaison screen the messages in either case and only forward
+ those which are considered of merit.  Either of these
+ schemes allows one message to be sent to the campus, while
+ allowing wide distribution within.
+
+
+ Address Allocation
+
+ Before a local network can be connected to the Internet it
+ must be allocated a unique IP address.  These addresses are
+ allocated by ISI.  The allocation process consists of getting
+ an application form received from ISI.  (Send a message
+ to hostmaster@sri-nic.arpa and ask for the template for a
+ connected address).  This template is filled out and mailed
+ back to hostmaster.  An address is allocated and e-mailed back
+ to you.  This can also be done by postal mail (Appendix B).
+
+ IP addresses are 32 bits long.  It is usually written as
+ four decimal numbers separated by periods (e.g., 192.17.5.100).
+ Each number is the value of an octet of the 32 bits.  It was
+ seen from the beginning that some networks might choose to
+ organize themselves as very flat (one net with a lot of nodes)
+ and some might organize hierarchically
+
+                             -6-
+
+ (many interconnected nets with fewer nodes each and a backbone).
+ To provide for these cases, addresses were differentiated into
+ class A, B, and C networks.  This classification had to with the
+ interpretation of the octets.  Class A networks have the first
+ octet as a network address and the remaining three as a host
+ address on that network.  Class C addresses have three octets of
+ network address and one of host.  Class B is split two and two.
+ Therefore, there is an address space for a few large nets, a
+ reasonable number of medium nets and a large number of small nets.
+ The top two bits in the first octet are coded to tell the address
+ format.  All of the class A nets have been allocated.  So one
+ has to choose between Class B and Class C when placing an order.
+ (There are also class D (Multicast) and E (Experimental) formats.
+ Multicast addresses will likely come into greater use in the near
+ future, but are not frequently used now).
+
+ In the past sites requiring multiple network addresses
+ requested multiple discrete addresses (usually Class C).
+ This was done because much of the software available
+ (not ably 4.2BSD) could not deal with subnetted addresses.
+ Information on how to reach a particular network (routing
+ information) must be stored in Internet gateways and packet
+ switches.  Some of these nodes have a limited capability to
+ store and exchange routing information (limited to about 300
+ networks).  Therefore, it is suggested that any campus
+ announce (make known to the Internet) no more than two
+ discrete network numbers.
+
+ If a campus expects to be constrained by this, it should
+ consider subnetting.  Subnetting (RFC-932) allows one to
+ announce one address to the Internet and use a  set of
+ addresses on the campus.  Basically, one defines a mask
+ which allows the network to differentiate between the
+ network portion and host portion of the address.  By using a
+ different mask on the Internet and the campus, the address
+ can be interpreted in multiple ways.  For example, if a
+ campus requires two networks internally and has the 32,000
+ addresses beginning 128.174.X.X (a Class B address) allocated
+ to it,  the campus could allocate 128.174.5.X to one part
+ of campus and 128.174.10.X to another.  By advertising
+ 128.174 to the Internet with a subnet mask of FF.FF.00.00,
+ the Internet would treat these two addresses as one. Within
+ the campus a mask of FF.FF.FF.00 would be used, allowing the
+ campus to treat the addresses as separate entities. (In reality
+ you don't pass the subnet mask of FF.FF.00.00 to the Internet,
+ the octet meaning is implicit in its being a class B address).
+ A word of warning is necessary.  Not all systems know how to
+ do subnetting.  Some 4.2BSD systems require additional
+ software.  4.3BSD systems subnet as released.  Other devices
+
+                             -7-
+
+ and operating systems vary in the problems they have dealing
+ with subnets.  Frequently these machines can be used as a
+ leaf on a network but not as a gateway within the subnetted
+ portion of the network.  As time passes and more systems
+ become 4.3BSD based, these problems should disappear.
+
+ There has been some confusion in the past over the format of
+ an IP broadcast address.  Some machines used an address of
+ all zeros to mean broadcast and some all ones.  This was
+ confusing when machines of both type were connected to the
+ same network. The broadcast address of all ones has been
+ adopted to end the grief.  Some systems (e.g. 4.2 BSD) allow
+ one to choose the format of the broadcast address.  If a
+ system does allow this choice, care should be taken that the
+ all ones format is chosen.  (This is explained in RFC-1009
+ and RFC-1010).
+
+
+ Internet Problems
+
+ There are a number of problems with the Internet.  Solutions
+ to the problems range from software changes to long term
+ research projects. Some of the major ones are detailed
+ below:
+
+ Number of Networks
+
+      When the Internet was designed it was to have about 50
+      connected networks.  With the explosion of networking,
+      the number is now approaching 300.  The software in a
+      group of critical gateways (called the core gateways of
+      the ARPAnet) are not able to pass or store much more
+      than that number.  In the short term, core reallocation
+      and recoding has raised the number slightly.  By the
+      summer of '88 the current PDP-11 core gateways will be
+      replaced with BBN Butterfly gateways which will solve
+      the problem.
+
+ Routing Issues
+
+      Along with sheer mass of the data necessary to route
+      packets to a large number of networks, there are many
+      problems with the updating, stability, and optimality
+      of the routing algorithms.  Much research is being done
+      in the area, but the optimal solution to these routing
+      problems is still years away.  In most cases the the
+      routing we have today works, but sub-optimally and
+      sometimes unpredictably.
+
+                             -8-
+
+
+ Trust Issues
+
+      Gateways exchange network routing information.
+      Currently, most gateways accept on faith that the
+      information provided about the state of the network is
+      correct.  In the past this was not a big problem since
+      most of the gateways belonged to a single administrative
+      entity (DARPA).  Now with multiple wide area networks
+      under different administrations, a rogue gateway
+      somewhere in the net could cripple the Internet.
+      There is design work going on to solve both the problem of
+      a gateway doing unreasonable things and providing enough
+      information to reasonably route data between multiply
+      connected networks (multi-homed networks).
+
+ Capacity & Congestion
+
+      Many portions of the ARPAnet are very congested during
+      the busy part of the day.  Additional links are planned
+      to alleviate this congestion, but the implementation
+      will take a few months.
+
+
+ These problems and the future direction of the Internet are
+ determined by the Internet Architect (Dave Clark of MIT)
+ being advised by the Internet Activities Board (IAB).  This
+ board is composed of chairmen of a number of committees with
+ responsibility for various specialized areas of the Internet.
+ The committees composing the IAB and their chairmen are:
+
+         Committee                            Chair
+      Autonomous Networks                  Deborah Estrin
+      End-to-End Services                  Bob Braden
+      Internet Architecture                Dave Mills
+      Internet Engineering                 Phil Gross
+           EGP2                            Mike Petry
+           Name Domain Planning            Doug Kingston
+           Gateway Monitoring              Craig Partridge
+           Internic                        Jake Feinler
+           Performance & Congestion ControlRobert Stine
+           NSF Routing                     Chuck Hedrick
+           Misc. MilSup Issues             Mike St. Johns
+      Privacy                              Steve Kent
+      IRINET Requirements                  Vint Cerf
+      Robustness & Survivability           Jim Mathis
+      Scientific Requirements              Barry Leiner
+
+ Note that under Internet Engineering, there are a set of
+ task forces and chairs to look at short term concerns.  The
+ chairs of these task forces are not part of the IAB.
+
+                             -9-
+ Routing
+
+
+ Routing is the algorithm by which a network directs a packet
+ from its source to its destination.  To appreciate the problem,
+ watch a small child trying to find a table in a restaurant.
+ From the adult point of view the structure of the dining room
+ is seen and an optimal route easily chosen.  The child, however,
+ is presented with a set of paths between tables where a good path,
+ let alone the optimal one to the goal is not discernible.***
+
+ A little more background might be appropriate.  IP gateways
+ (more correctly routers) are boxes which have connections to
+ multiple networks and pass traffic  between these nets.  They
+ decide how the packet is to be sent based on the information
+ in the IP header of the packet and the state of the network.
+ Each interface on a router has an unique address appropriate
+ to the network to which it is connected.  The information in
+ the IP header which is used is primarily the destination address.
+ Other information (e.g. type of service) is largely ignored at this
+ time.  The state of the network is determined by the routers passing
+ information among themselves.  The distribution of the database
+ (what each node knows), the form of the updates, and metrics used
+ to measure the value of a connection, are the parameters
+ which determine the characteristics of a routing protocol.
+
+ Under some algorithms each node in the network has complete
+ knowledge of the state of the network (the adult algorithm).
+ This implies the nodes must have larger amounts of local
+ storage and enough CPU to search the large tables in a short
+ enough time (remember this must be done for each packet).
+ Also, routing updates usually contain only changes to the
+ existing information (or you spend a large amount of the
+ network capacity passing around megabyte routing updates).
+ This type of algorithm has several problems.  Since the only
+ way the routing information can be passed around is across
+ the network and the propagation time is non-trivial, the
+ view of the network at each node is a correct historical
+ view of the network at varying times in the past.  (The
+ adult algorithm, but rather than looking directly at the
+ dining area, looking at a photograph of the dining room.
+ One is likely to pick the optimal route and find a bus-cart
+ has moved in to block the path after the photo was taken).
+ These inconsistencies can cause circular routes (called
+ routing loops) where once a packet enters it is routed in a
+ closed path until its time to live (TTL) field expires and
+ it is discarded.
+
+ Other algorithms may know about only a subset of the network.
+ To prevent loops in these protocols, they are usually used in
+ a hierarchical network.  They know completely about their
+ own area, but to leave that area they go to one particular
+ place (the default gateway).  Typically these are used in
+ smaller networks (campus, regional...).
+
+                             -10-
+
+ Routing protocols in current use:
+
+ Static (no protocol-table/default routing)
+
+      Don't laugh.  It is probably the most reliable, easiest
+      to implement, and least likely to get one into trouble
+      for a small network or a leaf on the Internet.  This is,
+      also, the only method available on some CPU-operating
+      system combinations. If a host is connected to an Ethernet
+      which has only one gateway off of it, one should make that
+      the default gateway for the host and do no other routing.
+      (Of course that gateway may pass the reachablity
+      information somehow on the other side of itself).
+
+      One word of warning, it is only with extreme caution that
+      one should use static routes in the middle of a network
+      which is also using dynamic routing.  The routers passing
+      dynamic information are sometimes confused by conflicting
+      dynamic and static routes.  If your host is on an ethernet
+      with multiple routers to other networks on it and the
+      routers are doing dynamic routing among themselves,
+      it is usually better to take part in the dynamic routing
+      than to use static routes.
+
+
+ RIP
+
+      RIP is a routing protocol based on XNS (Xerox Network
+      System) adapted for IP networks.  It is used by many
+      routers (Proteon, cisco, UB...) and many BSD Unix systems 
+      BSD systems typically run a program called "routed" to
+      exchange information with other systems running
+      RIP.  RIP works best for nets of small diameter
+      where the links are of equal speed.  The reason for
+      this is that the metric used to determine which path is
+      best is the hop-count.  A hop is a traversal across a
+      gateway.  So, all machines on the same Ethernet are
+      zero hops away.  If a router connects connects two net-
+      works directly, a machine on the other side of the
+      router is one hop away....  As the routing information
+      is passed through a gateway, the gateway adds one to
+      the hop counts to keep them consistent across the net-
+      work.  The diameter of a network is defined as the
+      largest hop-count possible within a network.  Unfor-
+      tunately, a hop count of 16 is defined as infinity in
+      RIP meaning the link is down. Therefore, RIP will not
+      allow hosts separated by more than 15 gateways in the
+      RIP space to communicate.
+
+      The other problem with hop-count metrics is that if
+      links have different speeds, that difference is not
+
+                             -11-
+
+      reflected in the hop-count. So a one hop satellite link
+      (with a .5 sec delay) at 56kb would be used instead of
+      a two hop T1 connection. Congestion can be viewed as a
+      decrease in the efficacy of a link. So, as a link gets
+      more congested, RIP will still know it is the best
+      hop-count route and congest it even more by throwing
+      more packets on the queue for that link.
+
+      The protocol is not well documented.  A group of people
+      are working on producing an RFC to both define the
+      current RIP and to do some extensions to it to allow it
+      to better cope with larger networks.  Currently, the
+      best documentation for RIP appears to be the code to
+      BSD "routed".
+
+
+ Routed
+
+      The ROUTED program, which does RIP for 4.2BSD systems,
+      has many options. One of the most frequently used is:
+      "routed -q" (quiet mode) which means listen to RIP infor-
+      mation but never broadcast it.  This would be used by a
+      machine on a network with multiple RIP speaking gate-
+      ways.  It allows the host to determine which gateway is
+      best (hopwise) to use to reach a distant network.  (Of
+      course you might want to have a default gateway to
+      prevent having to pass all the addresses known to the
+      Internet around with RIP).
+
+      There are two ways to insert static routes into "routed",
+      the "/etc/gateways" file and the "route add" command.
+      Static routes are useful if you know how to reach a
+      distant network, but you are not receiving that route
+      using RIP.  For the most part the "route add" command is
+      preferable to use.  The reason for this is that the
+      command adds the route to that machine's routing table
+      but does not export it through RIP.  The "/etc/gateways"
+      file takes precedence over any routing information
+      received through a RIP update.  It is also broadcast as
+      fact in RIP updates produced by the host without question,
+      so if a mistake is made in the "/etc/gateways" file,
+      that mistake will soon permeate the RIP space and
+      may bring the network to its knees.
+
+      One of the problems with "routed" is that you have very
+      little control over what gets broadcast and what
+      doesn't.  Many times in larger networks where various
+      parts of the network are under different administrative
+      controls, you would like to pass on through RIP only nets
+      which you receive from RIP and you know are reasonable.
+      This prevents people from adding IP addresses to
+      the network which may be illegal and you being
+      responsible for passing them on to the Internet.  This
+
+                             -12-
+
+      type of reasonability checks are not available with "routed"
+      and leave it usable, but inadequate for large networks.
+
+
+ Hello (RFC-891)
+
+      Hello is a routing protocol which was designed and
+      implemented in a experimental software router called a
+      "Fuzzball" which runs on a PDP-11. It does not have
+      wide usage, but is the routing protocol currently used
+      on the NSFnet backbone.  The data transferred between
+      nodes is similar to RIP (a list of networks and their
+      metrics).  The metric, however, is milliseconds of delay.
+      This allows Hello to be used over nets of various link
+      speeds and performs better in congestive situations.
+
+      One of the most interesting side effects of Hello based
+      networks is their great timekeeping ability.  If you
+      consider the problem of measuring delay on a link for
+      the metric, you find that it is not an easy thing to
+      do.  You cannot measure round trip time since the
+      return link may be more congested, of a different
+      speed, or even not there.  It is not really feasible
+      for each node on the network to have a builtin WWV
+      (nationwide radio time standard) receiver.  So, you
+      must design an algorithm to pass around time between
+      nodes over the network links where the delay in
+      transmission can only be approximated.  Hello routers
+      do this and in a nationwide network maintain synchronized
+      time within milliseconds.
+
+
+ Exterior Gateway Protocol (EGP RFC-904)
+
+      EGP is not strictly a routing protocol, it is a reacha-
+      bility protocol. It tells only if nets can be reached
+      through a particular gateway, not how good the connec-
+      tion is.  It is the standard by which gateways to local
+      nets inform the ARPAnet of the nets they can reach.
+      There is a metric passed around by EGP but its usage is
+      not standardized formally.  Its typical value is value
+      is 1 to 8 which are arbitrary goodness of link values
+      understood by the internal DDN gateways. The smaller
+      the value the better and a value of 8 being unreach-
+      able.  A quirk of the protocol prevents distinguishing
+      between 1 and 2, 3 and 4..., so the usablity of this as
+      a metric is as three values and unreachable.  Within
+      NSFnet the values used are 1, 3, and unreachable.  Many
+      routers talk EGP so they can be used for ARPAnet gateways.
+
+                             -13-
+
+ Gated
+
+      So we have regional and campus networks talking RIP
+      among   themselves,  the  NSFnet  backbone  talking
+      Hello, and the DDN speaking EGP.
+      How do they interoperate?  In the beginning there was
+      static routing, assembled into the Fuzzball software
+      configured for each site.  The problem with doing
+      static routing in the middle of the network is that it
+      is broadcast to the Internet whether it is usable or
+      not.  Therefore, if a net becomes unreachable and you
+      try to get there, dynamic routing will immediately
+      issue a net unreachable to you.  Under static routing
+      the routers would think the net could be reached and
+      would continue trying until the application gave up (in
+      2 or more minutes).  Mark Fedor of Cornell
+      (fedor@devvax.tn.cornell.edu) attempted to solve these
+      problems with a replacement for "routed" called "gated".
+
+      "Gated" talks RIP to RIP speaking hosts, EGP to EGP
+      speakers, and Hello to Hello'ers.  These speakers
+      frequently all live on one Ethernet, but luckily (or
+      unluckily) cannot understand each others ruminations.
+      In addition, under configuration file control it can
+      filter the conversion.  For example, one can produce a
+      configuration saying announce RIP nets via Hello only
+      if they are specified in a list and are reachable by
+      way of a RIP broadcast as well.  This means that if a
+      rogue network appears in your local site's RIP space,
+      it won't be passed through to the Hello side of the
+      world.  There are also configuration options to do
+      static routing and name trusted gateways.
+
+      This may sound like the greatest thing since sliced
+      bread, but there is a catch called metric conversion.
+      You have RIP measuring in hops, Hello measuring in
+      milliseconds, and EGP using arbitrary small numbers.
+      The big questions is how many hops to a millisecond,
+      how many milliseconds in the EGP number 3....  Also,
+      remember that infinity (unreachability) is 16 to RIP,
+      30000 or so to Hello, and 8 to the DDN with EGP.
+      Getting all these metrics to work well together is no
+      small feat.  If done incorrectly and you translate an
+      RIP of 16 into an EGP of 6, everyone in the ARPAnet
+      will still think your gateway can reach the unreachable
+      and will send every packet in the world your way.  For
+      these reasons, Mark requests that you consult closely
+      with him when configuring and using "gated".
+
+                             -14-
+
+ "Names"
+
+ All routing across the network is done by means of the IP
+ address associated with a packet. Since humans find it 
+ difficult to remember addresses like 128.174.5.50, a symbolic
+ name register was set up at the NIC where people would say
+ "I would like my host to be named 'uiucuxc'".  Machines
+ connected to the Internet across the nation would connect to
+ the NIC in the middle of the night, check modification dates
+ on the hosts file, and if modified move it to their local
+ machine.  With the advent of workstations and micros,
+ changes to the host file would have to be made nightly.  It
+ would also be very labor intensive and consume a lot of
+ network bandwidth. RFC-882 and a number of others describe
+ domain name service, a distributed data base system for
+ mapping names into addresses.
+
+ We must look a little more closely into what's in a name.
+ First, note that an address specifies a particular connec-
+ tion on a specific network.  If the machine moves, the
+ address changes.  Second, a machine can have one or more
+ names and one or more network addresses (connections) to
+ different networks.  Names point to a something which does
+ useful work (i.e. the machine) and IP addresses point to an
+ interface on that provider.  A name is a purely symbolic
+ representation of a list of addresses on the network.  If a
+ machine moves to a different network, the addresses will
+ change but the name could remain the same.
+
+ Domain names are tree structured names with the root of the
+ tree at the right.  For example:
+
+                       uxc.cso.uiuc.edu
+
+ is a machine called 'uxc' (purely arbitrary), within the
+ subdomains method of allocation of the U of I) and 'uiuc'
+ (the University of Illinois at Urbana), registered with
+ 'edu' (the set of educational institutions).
+
+ A simplified model of how a name is resolved is that on the
+ user's machine there is a resolver.  The resolver knows how
+ to contact across the network a root name server. Root
+ servers are the base of the tree structured data retrieval
+ system.  They know who is responsible for handling first
+ level domains (e.g. 'edu').  What root servers to use is an
+ installation parameter. From the root server the resolver
+ finds out who provides 'edu' service.  It contacts the 'edu'
+ name server which supplies it with a list of addresses of
+ servers for the subdomains (like 'uiuc').  This action is
+ repeated with the subdomain servers until the final sub-
+ domain returns a list of addresses of interfaces on the host
+ in question.  The user's machine then has its choice of
+ which of these addresses to use for communication.
+
+                             -15-
+
+ A group may apply for its own domain name (like 'uiuc'
+ above).  This is done in a manner similar to the IP address
+ allocation.  The only requirements are that the requestor
+ have two machines reachable from the Internet, which will
+ act as name servers for that domain.  Those servers could
+ also act as servers for subdomains or other servers could be
+ designated as such.  Note that the servers need not be
+ located in any particular place, as long as they are reach-
+ able for name resolution.  (U of I could ask Michigan State
+ to act on its behalf and that would be fine).  The biggest
+ problem is that someone must do maintenance on the database.
+ If the machine is not convenient, that might not be done in
+ a timely fashion.  The other thing to note is that once the
+ domain is allocated to an administrative entity, that entity
+ can freely allocate subdomains using what ever manner it
+ sees fit.
+
+ The Berkeley Internet Name Domain (BIND) Server implements
+ the Internet name server for UNIX systems.  The name server
+ is a distributed data base system that allows clients to
+ name resources and to share that information with other net-
+ work hosts.  BIND is integrated with 4.3BSD and is used to
+ lookup and store host names, addresses, mail agents, host
+ information, and more.  It replaces the "/etc/hosts" file for
+ host name lookup.  BIND is still an evolving program.  To
+ keep up with reports on operational problems, future design
+ decisions, etc, join the BIND mailing list by sending a
+ request to "bind-request@ucbarp.Berkeley.EDU".  BIND can also
+ be obtained via anonymous FTP from ucbarpa.berkley.edu.
+
+ There are several advantages in using BIND.  One of the most
+ important is that it frees a host from relying on "/etc/hosts"
+ being up to date and complete.  Within the .uiuc.edu domain,
+ only a few hosts are included in the host table distributed
+ by SRI.  The remainder are listed locally within the BIND
+ tables on uxc.cso.uiuc.edu (the server machine for most of
+ the .uiuc.edu domain).  All are equally reachable from any
+ other Internet host running BIND.
+
+ BIND can also provide mail forwarding information for inte-
+ rior hosts not directly reachable from the Internet.  These
+ hosts can either be on non-advertised networks, or not con-
+ nected to a network at all, as in the case of UUCP-reachable
+ hosts.  More information on BIND is available in the "Name
+ Server Operations Guide for BIND" in "UNIX System Manager's
+ Manual", 4.3BSD release.
+
+ There are a few special domains on the network, like SRI-
+ NIC.ARPA.  The 'arpa' domain is historical, referring to
+ hosts registered in the old hosts database at the NIC.
+ There are others of the form NNSC.NSF.NET.  These special
+ domains are used sparingly and require ample justification.
+ They refer to servers under the administrative control of
+
+                             -16-
+
+ the network rather than any single organization.  This
+ allows for the actual server to be moved around the net
+ while the user interface to that machine remains constant.
+ That is, should BBN relinquish control of the NNSC, the new
+ provider would be pointed to by that name.
+
+ In actuality, the domain system is a much more general and
+ complex system than has been described.  Resolvers and some
+ servers cache information to allow steps in the resolution
+ to be skipped.  Information provided by the servers can be
+ arbitrary, not merely IP addresses.  This allows the system
+ to be used both by non-IP networks and for mail, where it
+ may be necessary to give information on intermediate mail
+ bridges.
+
+
+ What's wrong with Berkeley Unix
+
+ University of California at Berkeley has been funded by
+ DARPA to modify the Unix system in a number of ways.
+ Included in these modifications is support for the Internet
+ protocols.  In earlier versions (e.g. BSD 4.2) there was
+ good support for the basic Internet protocols (TCP, IP,
+ SMTP, ARP) which allowed it to perform nicely on IP ether-
+ nets and smaller Internets.  There were deficiencies, how-
+ ever, when it was connected to complicated networks.  Most
+ of these problems have been resolved under the newest
+ release (BSD 4.3).  Since it is the springboard from which
+ many vendors have launched Unix implementations (either by
+ porting the existing code or by using it as a model), many
+ implementations (e.g. Ultrix) are still based on BSD 4.2.
+ Therefore, many implementations still exist with the BSD 4.2
+ problems.  As time goes on, when BSD 4.3 trickles through
+ vendors as new release, many of the problems will be
+ resolved.  Following is a list of some problem scenarios and
+ their handling under each of these releases.
+
+ ICMP redirects
+
+      Under the Internet model, all a system needs to know to
+      get anywhere in the Internet is its own address, the
+      address of where it wants to go, and how to reach a
+      gateway which knows about the Internet.  It doesn't
+      have to be the best gateway.  If the system is on a
+      network with multiple gateways, and a host sends a
+      packet for delivery to a gateway which feels another
+      directly connected gateway is more appropriate, the
+      gateway sends the sender a message.  This message is an
+      ICMP redirect, which politely says "I'll deliver this
+      message for you, but you really ought to use that gate-
+      way over there to reach this host".  BSD 4.2 ignores
+      these messages.  This creates more stress on the gate-
+      ways and the local network, since for every packet
+
+                             -17-
+
+      sent, the gateway sends a packet to the originator.
+      BSD 4.3 uses the redirect to update its routing tables,
+      will use the route until it times out, then revert to
+      the use of the route it thinks is should use.  The
+      whole process then repeats, but it is far better than
+      one per packet.
+
+ Trailers
+
+      An application (like FTP) sends a string of octets to
+      TCP which breaks it into chunks, and adds a TCP header.
+      TCP then sends blocks of data to IP which adds its own
+      headers and ships the packets over the network.  All
+      this prepending of the data with headers causes memory
+      moves in both the sending and the receiving machines.
+      Someone got the bright idea that if packets were long
+      and they stuck the headers on the end (they became
+      trailers), the receiving machine could put the packet
+      on the beginning of a page boundary and if the trailer
+      was OK merely delete it and transfer control of the
+      page with no memory moves involved.  The problem is
+      that trailers were never standardized and most gateways
+      don't know to look for the routing information at the
+      end of the block.  When trailers are used, the machine
+      typically works fine on the local network (no gateways
+      involved) and for short blocks through gateways (on
+      which trailers aren't used).  So TELNET and FTP's of
+      very short files work just fine and FTP's of long files
+      seem to hang.  On BSD 4.2 trailers are a boot option
+      and one should make sure they are off when using the
+      Internet.  BSD 4.3 negotiates trailers, so it uses them
+      on its local net and doesn't use them when going across
+      the network.
+
+ Retransmissions
+
+      TCP fires off blocks to its partner at the far end of
+      the connection.  If it doesn't receive an acknowledge-
+      ment in a reasonable amount of time it retransmits the
+      blocks.  The determination of what is reasonable is
+      done by TCP's retransmission algorithm.  There is no
+      correct algorithm but some are better than others,
+      where better is measured by the number of retransmis-
+      sions done unnecessarily.  BSD 4.2 had a retransmission
+      algorithm which retransmitted quickly and often.  This
+      is exactly what you would want if you had a bunch of
+      machines on an ethernet (a low delay network of large
+      bandwidth).  If you have a network of relatively longer
+      delay and scarce bandwidth (e.g. 56kb lines), it tends
+      to retransmit too aggressively.  Therefore, it makes
+      the networks and gateways pass more traffic than is
+      really necessary for a given conversation.  Retransmis-
+      sion algorithms do adapt to the delay of the network
+
+                             -18-
+
+      after a few packets, but 4.2's adapts slowly in delay
+      situations.  BSD 4.3 does a lot better and tries to do
+      the best for both worlds.  It fires off a few
+      retransmissions really quickly assuming it is on a low
+      delay network, and then backs off very quickly.  It
+      also allows the delay to be about 4 minutes before it
+      gives up and declares the connection broken.
+
+                             -19-
+                            Appendix A
+                References to Remedial Information
+
+
+      Quaterman and Hoskins, "Notable Computer Networks",
+      Communications of the ACM, Vol 29, #10, pp. 932-971
+      (October, 1986).
+
+      Tannenbaum, Andrew S., Computer Networks, Prentice
+      Hall, 1981.
+
+      Hedrick, Chuck, Introduction to the Internet Protocols,
+      Anonymous FTP from topaz.rutgers.edu, directory
+      pub/tcp-ip-docs, file tcp-ip-intro.doc.
+
+                             -20-
+
+                            Appendix B
+                        List of Major RFCs
+
+
+RFC-768        User Datagram Protocol (UDP)
+RFC-791        Internet Protocol (IP)
+RFC-792        Internet Control Message Protocol (ICMP)
+RFC-793        Transmission Control Protocol (TCP)
+RFC-821        Simple Mail Transfer Protocol (SMTP)
+RFC-822        Standard for the Format of ARPA Internet Text Messages
+RFC-854        Telnet Protocol
+RFC-917 *      Internet Subnets
+RFC-919 *      Broadcasting Internet Datagrams
+RFC-922 *      Broadcasting Internet Datagrams in the Presence of Subnets
+RFC-940 *      Toward an Internet Standard Scheme for Subnetting
+RFC-947 *      Multi-network Broadcasting within the Internet
+RFC-950 *      Internet Standard Subnetting Procedure
+RFC-959        File Transfer Protocol (FTP)
+RFC-966 *      Host Groups: A Multicast Extension to the Internet Protocol
+RFC-988 *      Host Extensions for IP Multicasting
+RFC-997 *      Internet Numbers
+RFC-1010 *     Assigned Numbers
+RFC-1011 *     Official ARPA-Internet Protocols
+
+      RFC's marked with the asterisk (*) are not included in
+      the 1985 DDN Protocol Handbook.
+
+      Note: This list is a portion of a list of RFC's by
+      topic retrieved from the NIC under NETINFO:RFC-SETS.TXT
+      (anonymous FTP of course).
+
+      The following list is not necessary for connection to
+      the Internet, but is useful in understanding the domain
+      system, mail system, and gateways:
+
+RFC-882        Domain Names - Concepts and Facilities
+RFC-883        Domain Names - Implementation
+RFC-973        Domain System Changes and Observations
+RFC-974        Mail Routing and the Domain System
+RFC-1009       Requirements for Internet Gateways
+
+                              -21-
+
+                            Appendix C
+              Contact Points for Network Information
+
+
+ Network Information Center (NIC)
+
+      DDN Network Information Center
+      SRI International, Room EJ291
+      333 Ravenswood Avenue
+      Menlo Park, CA 94025
+      (800) 235-3155 or (415) 859-3695
+      NIC@SRI-NIC.ARPA
+
+
+ NSF Network Service Center (NNSC)
+
+      NNSC
+      BBN Laboratories Inc.
+      10 Moulton St.
+      Cambridge, MA 02238
+      (617) 497-3400
+      NNSC@NNSC.NSF.NET
+
+                             -22-
+
+                           Glossary
+
+ core gateway
+
+The innermost gateways of the ARPAnet.  These
+gateways have a total picture of the reacha-
+bility to all networks known to the ARPAnet
+with EGP.  They then redistribute reachabil-
+ity information to all those gateways speak-
+ing EGP.  It is from them your EGP agent
+(there is one acting for you somewhere if you
+can reach the ARPAnet) finds out it can reach
+all the nets on the ARPAnet. Which is then
+passed to you via Hello, gated, RIP....
+
+ count to infinity
+
+The symptom of a routing problem where
+routing information is passed in a circular
+manner through multiple gateways.  Each gate-
+way increments the metric appropriately and
+passes it on.  As the metric is passed around
+the loop, it increments to ever increasing
+values til it reaches the maximum for the
+routing protocol being used, which typically
+denotes a link outage.
+
+ hold down
+
+When a router discovers a path in the network
+has gone down announcing that that path is
+down for a minimum amount of time (usually at
+least two minutes).  This allows for the pro-
+pagation of the routing information across
+the network and prevents the formation of
+routing loops.
+
+ split horizon
+
+When a router (or group of routers working in
+consort) accept routing information from mul-
+tiple external networks, but do not pass on
+information learned from one external network
+to any others.  This is an attempt to prevent
+bogus routes to a network from being propagated
+because of gossip or counting to infinity.
+
+                             -23-
+
+
\ No newline at end of file
diff --git a/old/hhgi10.zip b/old/hhgi10.zip
new file mode 100644
index 0000000..e6be0e8
--- /dev/null
+++ b/old/hhgi10.zip