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