











Network Working Group                                            E. Krol

Request for Comments: 1118                 University of Illinois Urbana

                                                          September 1989





                 The Hitchhikers Guide to the Internet



Status of this Memo



   This RFC is being distributed to members of the Internet community in

   order to make available some "hints" which will allow new network

   participants to understand how the direction of the Internet is set,

   how to acquire online information and how to be a good Internet

   neighbor.  While the information discussed may not be relevant to the

   research problems of the Internet, it may be interesting to a number

   of researchers and implementors.  No standards are defined or

   specified in this memo.  Distribution of this memo is unlimited.



NOTICE:



   The hitchhikers guide to the Internet is a very unevenly edited memo

   and contains many passages which simply seemed to its editors like a

   good idea at the time.  It is an indispensable companion to all those

   who are keen to make sense of life in an infinitely complex and

   confusing Internet, for although it cannot hope to be useful or

   informative on all matters, it does make the reassuring claim that

   where it is inaccurate, it is at least definitively inaccurate.  In

   cases of major discrepancy it is always reality that's got it wrong.

   And remember, DON'T PANIC.  (Apologies to Douglas Adams.)



Purpose and Audience



   This document assumes that one is familiar with the workings of a

   non-connected simple IP network (e.g., a few 4.3 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).















Krol                                                            [Page 1]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





What is the Internet?



   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 Internet Protocol (IP).  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.



   A few groups provide much of the information services on the

   Internet.  Information Sciences Institute (ISI) does much of the

   standardization and allocation work of the Internet acting as the

   Internet Assigned Numbers Authority (IANA).  SRI International

   provides the principal information services for the Internet by

   operating the Network Information Center (NIC).  In fact, after you

   are connected to the Internet most of the information in this

   document can be retrieved from the SRI-NIC.  Bolt Beranek and Newman

   (BBN) provides information services for CSNET (the CIC) and NSFNET

   (the NNSC), and Merit provides information services for NSFNET (the

   NIS).



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 DCA (on behalf of DARPA).  Their facility is called the

   Network Operations Center or NOC.  Merit, Inc. operates NSFNET from

   yet another and completely seperate NOC.  It goes on to the 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







Krol                                                            [Page 2]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





   (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.



   There are two independent categorizations of protocols.  The first is

   the state of standardization which is one of "standard", "draft

   standard", "proposed", "experimental", or "historic".  The second is

   the status of this protocol which is one of "required",

   "recommended", "elective", or "not recommended".  One could expect a

   particular protocol to move along the scale of status from elective

   to required at the same time as it moves along the scale of

   standardization from proposed to standard.



   A Required Standard protocol (e.g., RFC-791, The Internet Protocol)

   must be implemented on any host connected to the Internet.

   Recommended Standard protocols 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 Recommended Standard protocol.  Elective Proposed protocols 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.  It is

   suggested that should the facility be required by a particular site,

   an implementation 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-1010, 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 may 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.  (Appendix B contains a list of what are considered to be the

   major RFCs necessary for understanding the Internet).



   Only a few RFCs actually specify standards, most RFCs are for

   information or discussion purposes.  To find out what the current

   standards are see the RFC titled "IAB Official Protocol Standards"

   (most recently published as RFC-1100).











Krol                                                            [Page 3]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





The Network Information Center (NIC)



   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 nic.ddn.mil



   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 nic.ddn.mil

     Connected to nic.ddn.mil

     220 NIC.DDN.MIL FTP Server 5Z(47)-6 at Wed 17-Jun-87 12:00 PDT

     Name (nic.ddn.mil: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@NIC.DDN.MIL         General user assistance, document requests

     REGISTRAR@NIC.DDN.MIL   User registration and WHOIS updates

     HOSTMASTER@NIC.DDN.MIL  Hostname and domain changes and updates

     ACTION@NIC.DDN.MIL      SRI-NIC computer operations

     SUGGESTIONS@NIC.DDN.MIL Comments on NIC publications and services









Krol                                                            [Page 4]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





   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), located at BBN Systems and

   Technologies Corp., is a project of the University Corporation for

   Atmospheric Research under agreement with the National Science

   Foundation.  The NNSC provides support to end-users of NSFNET should

   they have questions or encounter problems traversing the network.



   The NNSC, which has information and documents online and in printed

   form, distributes news through network mailing lists, bulletins, and

   online reports.  NNSC publications include a hardcopy newsletter, the

   NSF Network News, which contains articles of interest to network

   users and the Internet Resource Guide, which lists facilities (such

   as supercomputer centers and on-line library catalogues) accessible

   from the Internet.  The Resource Guide can be obtained via anonymous

   ftp to nnsc.nsf.net in the directory resource-guide, or by joining

   the resource guide mailing list (send a subscription request to

   Resource-Guide-Request@NNSC.NSF.NET.)



Mail Reflectors



   The way most people keep up to date on network news is through

   subscription to a number of mail reflectors (also known as mail

   exploders).  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-INFO@MERIT.EDU, one sends a

   request to NSFNET-INFO-REQUEST@MERIT.EDU.  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-INFO) 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,







Krol                                                            [Page 5]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





   NETINFO:INTEREST-GROUPS-3.TXT, through NETINFO:INTEREST-GROUPS-9.TXT.



   The NSFNET-INFO 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

   SRI-NIC.  The allocation process consists of getting an application

   form.  Send a message to Hostmaster@NIC.DDN.MIL and ask for the

   template for a connected address.  This template is filled out and

   mailed back to the 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.  Some networks might choose to

   organize themselves as very flat (one net with a lot of nodes) and

   some might organize hierarchically (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 high order bits in the first octet are coded to tell the

   address format.  There are very few unallocated class A nets, so a

   very good case must be made for them.  So as a practical matter, one







Krol                                                            [Page 6]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





   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 yet).



   In the past, sites requiring multiple network addresses requested

   multiple discrete addresses (usually Class C).  This was done because

   much of the software available (notably 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 700

   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-950) 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 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.3 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







Krol                                                            [Page 7]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





   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 1000.  The software in a group of critical gateways

      (called the core gateways) 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.



   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.  The current best hope for a good routing protocol

      is something known as OSPFIGP which will be generally available

      from many router manufacturers within a year.



   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



      Some portions of the Internet are very congested during the busy

      part of the day.  Growth is dramatic with some networks

      experiencing growth in traffic in excess of 20% per month.







Krol                                                            [Page 8]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





      Additional bandwidth is planned, but delivery and budgets might

      not allow supply to keep up.



Setting Direction and Priority



   The Internet Activities Board (IAB), currently chaired by Vint Cerf

   of NRI, is responsible for setting the technical direction,

   establishing standards, and resolving problems in the Internet.



   The current IAB members are:



           Vinton Cerf          - Chairman

           David Clark          - IRTF Chairman

           Phillip Gross        - IETF Chairman

           Jon Postel           - RFC Editor

           Robert Braden        - Executive Director

           Hans-Werner Braun    - NSFNET Liaison

           Barry Leiner         - CCIRN Liaison

           Daniel Lynch         - Vendor Liaison

           Stephen Kent         - Internet Security



   This board is supported by a Research Task Force (chaired by Dave

   Clark of MIT) and an Engineering Task Force (chaired by Phill Gross

   of NRI).



   The Internet Research Task Force has the following Research Groups:



            Autonomous Networks            Deborah Estrin

            End-to-End Services            Bob Braden

            Privacy                        Steve Kent

            User Interfaces                Keith Lantz



   The Internet Engineering Task Force has the following technical

   areas:



           Applications                    TBD

           Host Protocols                  Craig Partridge

           Internet Protocols              Noel Chiappa

           Routing                         Robert Hinden

           Network Management              David Crocker

           OSI Interoperability            Ross Callon, Robert Hagen

           Operations                      TBD

           Security                        TBD



   The Internet Engineering Task Force has the following Working Groups:



            ALERTMAN                       Louis Steinberg

            Authentication                 Jeff Schiller







Krol                                                            [Page 9]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





            CMIP over TCP                  Lee LaBarre

            Domain Names                   Paul Mockapetris

            Dynamic Host Config            Ralph Droms

            Host Requirements              Bob Braden

            Interconnectivity              Guy Almes

            Internet MIB                   Craig Partridge

            Joint Management               Susan Hares

            LAN Mgr MIB                    Amatzia Ben-Artzi

            NISI                           Karen Bowers

            NM Serial Interface            Jeff Case

            NOC Tools                      Bob Enger

            OSPF                           Mike Petry

            Open Systems Routing           Marianne Lepp

            OSI Interoperability           Ross Callon

            PDN Routing Group              CH Rokitansky

            Performance and CC             Allison Mankin

            Point - Point IP               Drew Perkins

            ST and CO-IP                   Claudio Topolcic

            Telnet                         Dave Borman

            User Documents                 Karen Roubicek

            User Services                  Karen Bowers



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







Krol                                                           [Page 10]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





   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 or

   regional).



   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 reachability

      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.









Krol                                                           [Page 11]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





   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

      (few hops) 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 networks 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 network.  The diameter of a

      network is defined as the largest hop-count possible within a

      network.  Unfortunately, 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 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.



      RIP was originally not well documented in the community and people

      read BSD code to find out how RIP really worked.  Finally, it was

      documented in RFC-1058.



   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 information, but never broadcast

      it.  This would be used by a machine on a network with multiple

      RIP speaking gateways.  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







Krol                                                           [Page 12]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





      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 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

      formerly used on the initial 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. (See also the Network Time Protocol, RFC-1059.)















Krol                                                           [Page 13]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





   Gateway Gateway Protocol (GGP RFC-823)



      The core gateways originally used GGP to exchange information

      among themselves.  This is a "distance-vector" algorithm.  The new

      core gateways use a "link-state" algorithm.



   NSFNET SPF (RFC-1074)



      The current NSFNET Backbone routers use a version of the ANSI IS-

      IS and ISO ES-IS routing protocol.  This is a "shortest path

      first" (SPF) algorithm which is in the class of "link-state"

      algorithms.



   Exterior Gateway Protocol (EGP RFC-904)



      EGP is not strictly a routing protocol, it is a reachability

      protocol.  It tells what nets can be reached through what gateway,

      but not how good the connection is.  It is the standard by which

      gateways exchange network reachability information with the core

      gateways.  It is generally used between autonomous systems.  There

      is a metric passed around by EGP, but its usage is not

      standardized formally.  The metric's value ranges from 0 to 255

      with smaller values considered "better".  Some implementations

      consider the value 255 to mean unreachable.  Many routers talk EGP

      so they can be used to interface to routers of different

      manufacture or operated by different administrations.  For

      example, when a router of the NSFNET Backbone exchanges routing or

      reachability information with a gateway of a regional network EGP

      is used.



   Gated



      So we have regional and campus networks talking RIP among

      themselves and the DDN and NSFNET speaking EGP.  How do they

      interoperate?  In the beginning, there was static routing.  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, then of Cornell, 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







Krol                                                           [Page 14]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





      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.  Gated is available via

      anonymous FTP from devvax.tn.cornell.edu in directory pub/gated.



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-1034 and a

   number of others describe Domain Name Service (DNS), 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 connection 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







Krol                                                           [Page 15]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





   the right.  For example:



                             uxc.cso.uiuc.edu



   is a machine called "uxc" (purely arbitrary), within the subdomains

   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 sub-domain servers until the final subdomain

   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.



   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 reachable 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 network 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 or 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@UCBARPA.BERKELEY.EDU.  BIND can also be

   obtained via anonymous FTP from ucbarpa.berkeley.edu.







Krol                                                           [Page 16]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





   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, or any DNS resolver.



   BIND can also provide mail forwarding information for interior hosts

   not directly reachable from the Internet.  These hosts an either be

   on non-advertised networks, or not connected to an IP network at all,

   as in the case of UUCP-reachable hosts (see RFC-974).  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 NIC.DDN.MIL.

   The 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 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 Ethernets and smaller Internets.  There were

   deficiencies, however, 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







Krol                                                           [Page 17]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





   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 gateway over there to reach this host".  BSD 4.2 ignores

      these messages.  This creates more stress on the gateways and the

      local network, since for every packet 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.













Krol                                                           [Page 18]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





   Retransmissions



      TCP fires off blocks to its partner at the far end of the

      connection.  If it doesn't receive an acknowledgement 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 worse is measured by the number of retransmissions 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.  Retransmission algorithms do adapt to the delay of

      the network 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.



      Even better than the original 4.3 code is a version of TCP with a

      retransmission algorithm developed by Van Jacobson of LBL.  He did

      a lot of research into how the algorithm works on real networks

      and modified it to get both better throughput and be friendlier to

      the network.  This code has been integrated into the later

      releases of BSD 4.3 and can be fetched anonymously from

      ucbarpa.berkeley.edu in directory 4.3.



   Time to Live



      The IP packet header contains a field called the time to live

      (TTL) field.  It is decremented each time the packet traverses a

      gateway.  TTL was designed to prevent packets caught in routing

      loops from being passed forever with no hope of delivery.  Since

      the definition bears some likeness to the RIP hop count, some

      misguided systems have set the TTL field to 15 because the

      unreachable flag in RIP is 16.  Obviously, no networks could have

      more than 15 hops.  The RIP space where hops are limited ends when

      RIP is not used as a routing protocol any more (e.g., when NSFnet

      starts transporting the packet).  Therefore, it is quite easy for

      a packet to require more than 15 hops.  These machines will

      exhibit the behavior of being able to reach some places but not

      others even though the routing information appears correct.







Krol                                                           [Page 19]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





      Solving the problem typically requires kernel patches so it may be

      difficult if source is not available.



Appendix A - References to Remedial Information

-----------------------------------------------



  [1]  Quarterman and Hoskins, "Notable Computer Networks",

       Communications of the ACM, Vol. 29, No. 10, pp. 932-971, October

       1986.



  [2]  Tannenbaum, A., "Computer Networks", Prentice Hall, 1981.



  [3]  Hedrick, C., "Introduction to the Internet Protocols", Via

       Anonymous FTP from topaz.rutgers.edu, directory pub/tcp-ip-docs,

       file tcp-ip-intro.doc.



  [4]  Comer, D., "Internetworking with TCP/IP: Principles, Protocols,

       and Architecture", Copyright 1988,  by Prentice-Hall, Inc.,

       Englewood Cliffs, NJ,  07632 ISBN 0-13-470154-2.



Appendix B - List of Major RFCs

-------------------------------



This list of key "Basic Beige" RFCs was compiled by J.K. Reynolds.  This

is the 30 August 1989 edition of the list.



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-826       Ethernet Address Resolution Protocol

RFC-854       Telnet Protocol

RFC-862       Echo Protocol

RFC-894       A Standard for the Transmission of IP

              Datagrams over Ethernet Networks

RFC-904       Exterior Gateway Protocol

RFC-919       Broadcasting Internet Datagrams

RFC-922       Broadcasting Internet Datagrams in the Presence of Subnets

RFC-950       Internet Standard Subnetting Procedure

RFC-951       Bootstrap Protocol (BOOTP)

RFC-959       File Transfer Protocol (FTP)

RFC-966       Host Groups: A Multicast Extension to the Internet Protocol

RFC-974       Mail Routing and the Domain System

RFC-1000      The Request for Comments Reference Guide

RFC-1009      Requirements for Internet Gateways

RFC-1010      Assigned Numbers







Krol                                                           [Page 20]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





RFC-1011      Official Internet Protocols

RFC-1012      Bibliography of Request for Comments 1 through 999

RFC-1034      Domain Names - Concepts and Facilities

RFC-1035      Domain Names - Implementation

RFC-1042      A Standard for the Transmission of IP

              Datagrams over IEEE 802 Networks

RFC-1048      BOOTP Vendor Information Extensions

RFC-1058      Routing Information Protocol

RFC-1059      Network Time Protocol (NTP)

RFC-1065      Structure and Identification of

              Management Information for TCP/IP-based internets

RFC-1066      Management Information Base for Network

              Management of TCP/IP-based internets

RFC-1084      BOOTP Vendor Information Extensions

RFC-1087      Ethics and the Internet

RFC-1095      The Common Management Information

              Services and Protocol over TCP/IP (CMOT)

RFC-1098      A Simple Network Management Protocol (SNMP)

RFC-1100      IAB Official Protocol Standards

RFC-1101      DNS Encoding of Network Names and Other Types

RFC-1112      Host Extensions for IP Multicasting

RFC-1117      Internet Numbers



Note:  This list is a portion of a list of RFC's by topic that may be

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-974        Mail Routing and the Domain System

RFC-1009       Requirements for Internet Gateways

RFC-1034       Domain Names - Concepts and Facilities

RFC-1035       Domain Names - Implementation and Specification

RFC-1101       DNS Encoding of Network Names and Other Types































Krol                                                           [Page 21]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





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@NIC.DDN.MIL



NSF Network Service Center (NNSC)



      NNSC

      BBN Systems and Technology Corporation

      10 Moulton St.

      Cambridge, MA 02238

      (617) 873-3400



      NNSC@NNSC.NSF.NET



NSF Network Information Service (NIS)



      NIS

      Merit Inc.

      University of Michigan

      1075 Beal Avenue

      Ann Arbor, MI 48109

      (313) 763-4897



      INFO@NIS.NSF.NET



CIC



      CSNET Coordination and Information Center

      Bolt Beranek and Newman Inc.

      10 Moulton Street

      Cambridge, MA 02238

      (617) 873-2777



      INFO@SH.CS.NET

















Krol                                                           [Page 22]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





Glossary

--------



   autonomous system



      A set of gateways under a single administrative control and using

      compatible and consistent routing procedures.  Generally speaking,

      the gateways run by a particular organization.  Since a gateway is

      connected to two (or more) networks it is not usually correct to

      say that a gateway is in a network.  For example, the gateways

      that connect regional networks to the NSF Backbone network are run

      by Merit and form an autonomous system.  Another example, the

      gateways that connect campuses to NYSERNET are run by NYSER and

      form an autonomous system.



   core gateway



      The innermost gateways of the Internet.  These gateways have a

      total picture of the reachability to all networks known to the

      Internet.  They then redistribute reachability information to

      their neighbor gateways speaking EGP.  It is from them your EGP

      agent (there is one acting for you somewhere if you can reach the

      core of the Internet) finds out it can reach all the nets on the

      Internet.  Which is then passed to you via Hello, gated, RIP.  The

      core gateways mostly connect campuses to the ARPANET, or

      interconnect the ARPANET and the MILNET, and are run by BBN.



   count to infinity



      The symptom of a routing problem where routing information is

      passed in a circular manner through multiple gateways.  Each

      gateway increments the metric appropriately and passes it on.  As

      the metric is passed around the loop, it increments to ever

      increasing values until 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 propagation

      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 multiple external networks, but do not







Krol                                                           [Page 23]





RFC 1118         The Hitchhikers Guide to the Internet    September 1989





      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.



   DDN



      Defense Data Network the collective name for the ARPANET and

      MILNET.  Used frequently because although they are seperate

      networks the operational and informational foci are the same.



Security Considerations



   Security and privacy protection is a serious matter and too often

   nothing is done about it.  There are some known security bugs

   (especially in access control) in BSD Unix and in some

   implementations of network services.  The hitchhikers guide does not

   discuss these issues (too bad).



Author's Address



   Ed Krol

   University of Illinois

   195 DCL

   1304 West Springfield Avenue

   Urbana, IL  61801-4399



   Phone: (217) 333-7886



   EMail: Krol@UXC.CSO.UIUC.EDU













































Krol                                                           [Page 24]





