GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1118

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1118.txt · Last modified: 1989/10/03 23:05 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki