rfc1118.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,347 行 · 第 1/5 页

   list for NSFNET reflected by [e-mail], one sends a
   request to [e-mail].  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 [e-mail] 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