on a BSD system and following the directions provided by a user friendly prompter. From poking around in the databases provided one might decide that a document named NETINFO:NUG.DOC (The Users Guide to the ARPAnet) would be worth having. It could be retrieved via an anonymous FTP. An anonymous FTP would proceed something like the following. (The dialogue may vary slightly depending on the implementation of FTP you are using).

      %ftp sri-nic.arpa
      Connected to sri-nic.arpa.
      220 SRI_NIC.ARPA FTP Server Process 5Z(47)-6 at Wed
17-Jun-87 12:00 PDT
      Name (sri-nic.arpa:myname): anonymous
      331 ANONYMOUS user ok, send real ident as password.
      Password: myname
      230 User ANONYMOUS logged in at Wed 17-Jun-87 12:01 PDT,
job 15.
      ftp> get netinfo:nug.doc
      200 Port 18.144 at host 128.174.5.50 accepted.
      150 ASCII retrieve of <NETINFO>NUG.DOC.11 started.
      226 Transfer Completed 157675 (8) bytes transferred
      local: netinfo:nug.doc remote:netinfo:nug.doc
      157675 bytes in 4.5e+02 seconds (0.34 Kbytes/s)
      ftp> quit
      221 QUIT command received. Goodbye.

 (Another good initial document to fetch is
 NETINFO:WHAT-THE-NIC-DOES.TXT)!

 Questions of the NIC or problems with services can be asked
 of or reported to using electronic mail. The following
 addresses can be used:

      [email protected] General user assistance, document requests
      [email protected] User registration and WHOIS updates
      [email protected] Hostname and domain changes and updates
      [email protected] SRI-NIC computer operations
      [email protected] Comments on NIC publications and services

-4-

For people without network access, or if the number of documents is large, many of the NIC documents are available in printed form for a small charge. One frequently ordered document for starting sites is a compendium of major RFCs. Telephone access is used primarily for questions or problems with network access. (See appendix B for mail/telephone contact numbers).

The NSFnet Network Service Center

The NSFnet Network Service Center (NNSC) is funded by NSF to provide a first level of aid to users of NSFnet should they have questions or encounter problems traversing the network. It is run by BBN Inc. Karen Roubicek ([email protected]) is the NNSC user liaison.

The NNSC, which currently has information and documents online and in printed form, plans to distribute news through network mailing lists, bulletins, newsletters, and online reports. The NNSC also maintains a database of contact points and sources of additional information about NSFnet component networks and supercomputer centers.

 Prospective or current users who do not know whom to call
 concerning questions about NSFnet use, should contact the
 NNSC. The NNSC will answer general questions, and, for
 detailed information relating to specific components of the
 Internet, will help users find the appropriate contact for
 further assistance. (Appendix B)

Mail Reflectors

The way most people keep up to date on network news is through subscription to a number of mail reflectors. Mail reflectors are special electronic mailboxes which, when they receive a message, resend it to a list of other mailboxes. This in effect creates a discussion group on a particular topic. Each subscriber sees all the mail forwarded by the reflector, and if one wants to put his "two cents" in sends a message with the comments to the reflector….

The general format to subscribe to a mail list is to find the address reflector and append the string -REQUEST to the mailbox name (not the host name). For example, if you wanted to take part in the mailing list for NSFnet reflected by [email protected], one sends a request to

-5-

[email protected]. This may be a wonderful scheme, but the problem is that you must know the list exists in the first place. It is suggested that, if you are interested, you read the mail from one list (like NSFNET) and you will probably become familiar with the existence of others. A registration service for mail reflectors is provided by the NIC in the files NETINFO:INTEREST-GROUPS-1.TXT, NETINFO:INTEREST-GROUPS-2.TXT, and NETINFO:INTEREST-GROUPS- 3.TXT.

The NSFNET mail reflector is targeted at those people who have a day to day interest in the news of the NSFnet (the backbone, regional network, and Internet inter-connection site workers). The messages are reflected by a central location and are sent as separate messages to each subscriber. This creates hundreds of messages on the wide area networks where bandwidth is the scarcest.

There are two ways in which a campus could spread the news and not cause these messages to inundate the wide area networks. One is to re-reflect the message on the campus. That is, set up a reflector on a local machine which forwards the message to a campus distribution list. The other is to create an alias on a campus machine which places the messages into a notesfile on the topic. Campus users who want the information could access the notesfile and see the messages that have been sent since their last access. One might also elect to have the campus wide area network liaison screen the messages in either case and only forward those which are considered of merit. Either of these schemes allows one message to be sent to the campus, while allowing wide distribution within.

Address Allocation

Before a local network can be connected to the Internet it must be allocated a unique IP address. These addresses are allocated by ISI. The allocation process consists of getting an application form received from ISI. (Send a message to [email protected] and ask for the template for a connected address). This template is filled out and mailed back to hostmaster. An address is allocated and e-mailed back to you. This can also be done by postal mail (Appendix B).

IP addresses are 32 bits long. It is usually written as four decimal numbers separated by periods (e.g., 192.17.5.100). Each number is the value of an octet of the 32 bits. It was seen from the beginning that some networks might choose to organize themselves as very flat (one net with a lot of nodes) and some might organize hierarchically

-6-

(many interconnected nets with fewer nodes each and a backbone). To provide for these cases, addresses were differentiated into class A, B, and C networks. This classification had to with the interpretation of the octets. Class A networks have the first octet as a network address and the remaining three as a host address on that network. Class C addresses have three octets of network