From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1118.txt | 1347 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1347 insertions(+) create mode 100644 doc/rfc/rfc1118.txt (limited to 'doc/rfc/rfc1118.txt') diff --git a/doc/rfc/rfc1118.txt b/doc/rfc/rfc1118.txt new file mode 100644 index 0000000..8861be8 --- /dev/null +++ b/doc/rfc/rfc1118.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group E. Krol +Request for Comments: 1118 University of Illinois Urbana + September 1989 + + + The Hitchhikers Guide to the Internet + +Status of this Memo + + This RFC is being distributed to members of the Internet community in + order to make available some "hints" which will allow new network + participants to understand how the direction of the Internet is set, + how to acquire online information and how to be a good Internet + neighbor. While the information discussed may not be relevant to the + research problems of the Internet, it may be interesting to a number + of researchers and implementors. No standards are defined or + specified in this memo. Distribution of this memo is unlimited. + +NOTICE: + + The hitchhikers guide to the Internet is a very unevenly edited memo + and contains many passages which simply seemed to its editors like a + good idea at the time. It is an indispensable companion to all those + who are keen to make sense of life in an infinitely complex and + confusing Internet, for although it cannot hope to be useful or + informative on all matters, it does make the reassuring claim that + where it is inaccurate, it is at least definitively inaccurate. In + cases of major discrepancy it is always reality that's got it wrong. + And remember, DON'T PANIC. (Apologies to Douglas Adams.) + +Purpose and Audience + + This document assumes that one is familiar with the workings of a + non-connected simple IP network (e.g., a few 4.3 BSD systems on an + Ethernet not connected to anywhere else). Appendix A contains + remedial information to get one to this point. Its purpose is to get + that person, familiar with a simple net, versed in the "oral + tradition" of the Internet to the point that that net can be + connected to the Internet with little danger to either. It is not a + tutorial, it consists of pointers to other places, literature, and + hints which are not normally documented. Since the Internet is a + dynamic environment, changes to this document will be made regularly. + The author welcomes comments and suggestions. This is especially + true of terms for the glossary (definitions are not necessary). + + + + + + + +Krol [Page 1] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + +What is the Internet? + + In the beginning there was the ARPANET, a wide area experimental + network connecting hosts and terminal servers together. Procedures + were set up to regulate the allocation of addresses and to create + voluntary standards for the network. As local area networks became + more pervasive, many hosts became gateways to local networks. A + network layer to allow the interoperation of these networks was + developed and called Internet Protocol (IP). Over time other groups + created long haul IP based networks (NASA, NSF, states...). These + nets, too, interoperate because of IP. The collection of all of + these interoperating networks is the Internet. + + A few groups provide much of the information services on the + Internet. Information Sciences Institute (ISI) does much of the + standardization and allocation work of the Internet acting as the + Internet Assigned Numbers Authority (IANA). SRI International + provides the principal information services for the Internet by + operating the Network Information Center (NIC). In fact, after you + are connected to the Internet most of the information in this + document can be retrieved from the SRI-NIC. Bolt Beranek and Newman + (BBN) provides information services for CSNET (the CIC) and NSFNET + (the NNSC), and Merit provides information services for NSFNET (the + NIS). + +Operating the Internet + + Each network, be it the ARPANET, NSFNET or a regional network, has + its own operations center. The ARPANET is run by BBN, Inc. under + contract from DCA (on behalf of DARPA). Their facility is called the + Network Operations Center or NOC. Merit, Inc. operates NSFNET from + yet another and completely seperate NOC. It goes on to the regionals + having similar facilities to monitor and keep watch over the goings + on of their portion of the Internet. In addition, they all should + have some knowledge of what is happening to the Internet in total. + If a problem comes up, it is suggested that a campus network liaison + should contact the network operator to which he is directly + connected. That is, if you are connected to a regional network + (which is gatewayed to the NSFNET, which is connected to the + ARPANET...) and have a problem, you should contact your regional + network operations center. + +RFCs + + The internal workings of the Internet are defined by a set of + documents called RFCs (Request for Comments). The general process + for creating an RFC is for someone wanting something formalized to + write a document describing the issue and mailing it to Jon Postel + + + +Krol [Page 2] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + (Postel@ISI.EDU). He acts as a referee for the proposal. It is then + commented upon by all those wishing to take part in the discussion + (electronically of course). It may go through multiple revisions. + Should it be generally accepted as a good idea, it will be assigned a + number and filed with the RFCs. + + There are two independent categorizations of protocols. The first is + the state of standardization which is one of "standard", "draft + standard", "proposed", "experimental", or "historic". The second is + the status of this protocol which is one of "required", + "recommended", "elective", or "not recommended". One could expect a + particular protocol to move along the scale of status from elective + to required at the same time as it moves along the scale of + standardization from proposed to standard. + + A Required Standard protocol (e.g., RFC-791, The Internet Protocol) + must be implemented on any host connected to the Internet. + Recommended Standard protocols are generally implemented by network + hosts. Lack of them does not preclude access to the Internet, but + may impact its usability. RFC-793 (Transmission Control Protocol) is + a Recommended Standard protocol. Elective Proposed protocols were + discussed and agreed to, but their application has never come into + wide use. This may be due to the lack of wide need for the specific + application (RFC-937, The Post Office Protocol) or that, although + technically superior, ran against other pervasive approaches. It is + suggested that should the facility be required by a particular site, + an implementation be done in accordance with the RFC. This insures + that, should the idea be one whose time has come, the implementation + will be in accordance with some standard and will be generally + usable. + + Informational RFCs contain factual information about the Internet and + its operation (RFC-1010, Assigned Numbers). Finally, as the Internet + and technology have grown, some RFCs have become unnecessary. These + obsolete RFCs cannot be ignored, however. Frequently when a change + is made to some RFC that causes a new one to be issued obsoleting + others, the new RFC may only contains explanations and motivations + for the change. Understanding the model on which the whole facility + is based may involve reading the original and subsequent RFCs on the + topic. (Appendix B contains a list of what are considered to be the + major RFCs necessary for understanding the Internet). + + Only a few RFCs actually specify standards, most RFCs are for + information or discussion purposes. To find out what the current + standards are see the RFC titled "IAB Official Protocol Standards" + (most recently published as RFC-1100). + + + + + +Krol [Page 3] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + +The Network Information Center (NIC) + + The NIC is a facility available to all Internet users which provides + information to the community. There are three means of NIC contact: + network, telephone, and mail. The network accesses are the most + prevalent. Interactive access is frequently used to do queries of + NIC service overviews, look up user and host names, and scan lists of + NIC documents. It is available by using + + %telnet nic.ddn.mil + + on a BSD system, and following the directions provided by a user + friendly prompter. From poking around in the databases provided, one + might decide that a document named NETINFO:NUG.DOC (The Users Guide + to the ARPANET) would be worth having. It could be retrieved via an + anonymous FTP. An anonymous FTP would proceed something like the + following. (The dialogue may vary slightly depending on the + implementation of FTP you are using). + + %ftp nic.ddn.mil + Connected to nic.ddn.mil + 220 NIC.DDN.MIL FTP Server 5Z(47)-6 at Wed 17-Jun-87 12:00 PDT + Name (nic.ddn.mil:myname): anonymous + 331 ANONYMOUS user ok, send real ident as password. + Password: myname + 230 User ANONYMOUS logged in at Wed 17-Jun-87 12:01 PDT, job 15. + ftp> get netinfo:nug.doc + 200 Port 18.144 at host 128.174.5.50 accepted. + 150 ASCII retrieve of NUG.DOC.11 started. + 226 Transfer Completed 157675 (8) bytes transferred + local: netinfo:nug.doc remote:netinfo:nug.doc + 157675 bytes in 4.5e+02 seconds (0.34 Kbytes/s) + ftp> quit + 221 QUIT command received. Goodbye. + + (Another good initial document to fetch is NETINFO:WHAT-THE-NIC- + DOES.TXT). + + Questions of the NIC or problems with services can be asked of or + reported to using electronic mail. The following addresses can be + used: + + NIC@NIC.DDN.MIL General user assistance, document requests + REGISTRAR@NIC.DDN.MIL User registration and WHOIS updates + HOSTMASTER@NIC.DDN.MIL Hostname and domain changes and updates + ACTION@NIC.DDN.MIL SRI-NIC computer operations + SUGGESTIONS@NIC.DDN.MIL Comments on NIC publications and services + + + + +Krol [Page 4] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + For people without network access, or if the number of documents is + large, many of the NIC documents are available in printed form for a + small charge. One frequently ordered document for starting sites is + a compendium of major RFCs. Telephone access is used primarily for + questions or problems with network access. (See appendix B for + mail/telephone contact numbers). + +The NSFNET Network Service Center + + The NSFNET Network Service Center (NNSC), located at BBN Systems and + Technologies Corp., is a project of the University Corporation for + Atmospheric Research under agreement with the National Science + Foundation. The NNSC provides support to end-users of NSFNET should + they have questions or encounter problems traversing the network. + + The NNSC, which has information and documents online and in printed + form, distributes news through network mailing lists, bulletins, and + online reports. NNSC publications include a hardcopy newsletter, the + NSF Network News, which contains articles of interest to network + users and the Internet Resource Guide, which lists facilities (such + as supercomputer centers and on-line library catalogues) accessible + from the Internet. The Resource Guide can be obtained via anonymous + ftp to nnsc.nsf.net in the directory resource-guide, or by joining + the resource guide mailing list (send a subscription request to + Resource-Guide-Request@NNSC.NSF.NET.) + +Mail Reflectors + + The way most people keep up to date on network news is through + subscription to a number of mail reflectors (also known as mail + exploders). Mail reflectors are special electronic mailboxes which, + when they receive a message, resend it to a list of other mailboxes. + This in effect creates a discussion group on a particular topic. + Each subscriber sees all the mail forwarded by the reflector, and if + one wants to put his "two cents" in sends a message with the comments + to the reflector. + + The general format to subscribe to a mail list is to find the address + reflector and append the string -REQUEST to the mailbox name (not the + host name). For example, if you wanted to take part in the mailing + list for NSFNET reflected by NSFNET-INFO@MERIT.EDU, one sends a + request to NSFNET-INFO-REQUEST@MERIT.EDU. This may be a wonderful + scheme, but the problem is that you must know the list exists in the + first place. It is suggested that, if you are interested, you read + the mail from one list (like NSFNET-INFO) and you will probably + become familiar with the existence of others. A registration service + for mail reflectors is provided by the NIC in the files + NETINFO:INTEREST-GROUPS-1.TXT, NETINFO:INTEREST-GROUPS-2.TXT, + + + +Krol [Page 5] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + NETINFO:INTEREST-GROUPS-3.TXT, through NETINFO:INTEREST-GROUPS-9.TXT. + + The NSFNET-INFO mail reflector is targeted at those people who have a + day to day interest in the news of the NSFNET (the backbone, regional + network, and Internet inter-connection site workers). The messages + are reflected by a central location and are sent as separate messages + to each subscriber. This creates hundreds of messages on the wide + area networks where bandwidth is the scarcest. + + There are two ways in which a campus could spread the news and not + cause these messages to inundate the wide area networks. One is to + re-reflect the message on the campus. That is, set up a reflector on + a local machine which forwards the message to a campus distribution + list. The other is to create an alias on a campus machine which + places the messages into a notesfile on the topic. Campus users who + want the information could access the notesfile and see the messages + that have been sent since their last access. One might also elect to + have the campus wide area network liaison screen the messages in + either case and only forward those which are considered of merit. + Either of these schemes allows one message to be sent to the campus, + while allowing wide distribution within. + +Address Allocation + + Before a local network can be connected to the Internet it must be + allocated a unique IP address. These addresses are allocated by + SRI-NIC. The allocation process consists of getting an application + form. Send a message to Hostmaster@NIC.DDN.MIL and ask for the + template for a connected address. This template is filled out and + mailed back to the hostmaster. An address is allocated and e-mailed + back to you. This can also be done by postal mail (Appendix B). + + IP addresses are 32 bits long. It is usually written as four decimal + numbers separated by periods (e.g., 192.17.5.100). Each number is + the value of an octet of the 32 bits. Some networks might choose to + organize themselves as very flat (one net with a lot of nodes) and + some might organize hierarchically (many interconnected nets with + fewer nodes each and a backbone). To provide for these cases, + addresses were differentiated into class A, B, and C networks. This + classification had to with the interpretation of the octets. Class A + networks have the first octet as a network address and the remaining + three as a host address on that network. Class C addresses have + three octets of network address and one of host. Class B is split + two and two. Therefore, there is an address space for a few large + nets, a reasonable number of medium nets and a large number of small + nets. The high order bits in the first octet are coded to tell the + address format. There are very few unallocated class A nets, so a + very good case must be made for them. So as a practical matter, one + + + +Krol [Page 6] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + has to choose between Class B and Class C when placing an order. + (There are also class D (Multicast) and E (Experimental) formats. + Multicast addresses will likely come into greater use in the near + future, but are not frequently used yet). + + In the past, sites requiring multiple network addresses requested + multiple discrete addresses (usually Class C). This was done because + much of the software available (notably 4.2BSD) could not deal with + subnetted addresses. Information on how to reach a particular + network (routing information) must be stored in Internet gateways and + packet switches. Some of these nodes have a limited capability to + store and exchange routing information (limited to about 700 + networks). Therefore, it is suggested that any campus announce (make + known to the Internet) no more than two discrete network numbers. + + If a campus expects to be constrained by this, it should consider + subnetting. Subnetting (RFC-950) allows one to announce one address + to the Internet and use a set of addresses on the campus. Basically, + one defines a mask which allows the network to differentiate between + the network portion and host portion of the address. By using a + different mask on the Internet and the campus, the address can be + interpreted in multiple ways. For example, if a campus requires two + networks internally and has the 32,000 addresses beginning + 128.174.X.X (a Class B address) allocated to it, the campus could + allocate 128.174.5.X to one part of campus and 128.174.10.X to + another. By advertising 128.174 to the Internet with a subnet mask + of FF.FF.00.00, the Internet would treat these two addresses as one. + Within the campus a mask of FF.FF.FF.00 would be used, allowing the + campus to treat the addresses as separate entities. (In reality, you + don't pass the subnet mask of FF.FF.00.00 to the Internet, the octet + meaning is implicit in its being a class B address). + + A word of warning is necessary. Not all systems know how to do + subnetting. Some 4.2BSD systems require additional software. 4.3BSD + systems subnet as released. Other devices and operating systems vary + in the problems they have dealing with subnets. Frequently, these + machines can be used as a leaf on a network but not as a gateway + within the subnetted portion of the network. As time passes and more + systems become 4.3BSD based, these problems should disappear. + + There has been some confusion in the past over the format of an IP + broadcast address. Some machines used an address of all zeros to + mean broadcast and some all ones. This was confusing when machines + of both type were connected to the same network. The broadcast + address of all ones has been adopted to end the grief. Some systems + (e.g., 4.3 BSD) allow one to choose the format of the broadcast + address. If a system does allow this choice, care should be taken + that the all ones format is chosen. (This is explained in RFC-1009 + + + +Krol [Page 7] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + and RFC-1010). + +Internet Problems + + There are a number of problems with the Internet. Solutions to the + problems range from software changes to long term research projects. + Some of the major ones are detailed below: + + Number of Networks + + When the Internet was designed it was to have about 50 connected + networks. With the explosion of networking, the number is now + approaching 1000. The software in a group of critical gateways + (called the core gateways) are not able to pass or store much more + than that number. In the short term, core reallocation and + recoding has raised the number slightly. + + Routing Issues + + Along with sheer mass of the data necessary to route packets to a + large number of networks, there are many problems with the + updating, stability, and optimality of the routing algorithms. + Much research is being done in the area, but the optimal solution + to these routing problems is still years away. In most cases, the + the routing we have today works, but sub-optimally and sometimes + unpredictably. The current best hope for a good routing protocol + is something known as OSPFIGP which will be generally available + from many router manufacturers within a year. + + Trust Issues + + Gateways exchange network routing information. Currently, most + gateways accept on faith that the information provided about the + state of the network is correct. In the past this was not a big + problem since most of the gateways belonged to a single + administrative entity (DARPA). Now, with multiple wide area + networks under different administrations, a rogue gateway + somewhere in the net could cripple the Internet. There is design + work going on to solve both the problem of a gateway doing + unreasonable things and providing enough information to reasonably + route data between multiply connected networks (multi-homed + networks). + + Capacity & Congestion + + Some portions of the Internet are very congested during the busy + part of the day. Growth is dramatic with some networks + experiencing growth in traffic in excess of 20% per month. + + + +Krol [Page 8] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + Additional bandwidth is planned, but delivery and budgets might + not allow supply to keep up. + +Setting Direction and Priority + + The Internet Activities Board (IAB), currently chaired by Vint Cerf + of NRI, is responsible for setting the technical direction, + establishing standards, and resolving problems in the Internet. + + The current IAB members are: + + Vinton Cerf - Chairman + David Clark - IRTF Chairman + Phillip Gross - IETF Chairman + Jon Postel - RFC Editor + Robert Braden - Executive Director + Hans-Werner Braun - NSFNET Liaison + Barry Leiner - CCIRN Liaison + Daniel Lynch - Vendor Liaison + Stephen Kent - Internet Security + + This board is supported by a Research Task Force (chaired by Dave + Clark of MIT) and an Engineering Task Force (chaired by Phill Gross + of NRI). + + The Internet Research Task Force has the following Research Groups: + + Autonomous Networks Deborah Estrin + End-to-End Services Bob Braden + Privacy Steve Kent + User Interfaces Keith Lantz + + The Internet Engineering Task Force has the following technical + areas: + + Applications TBD + Host Protocols Craig Partridge + Internet Protocols Noel Chiappa + Routing Robert Hinden + Network Management David Crocker + OSI Interoperability Ross Callon, Robert Hagen + Operations TBD + Security TBD + + The Internet Engineering Task Force has the following Working Groups: + + ALERTMAN Louis Steinberg + Authentication Jeff Schiller + + + +Krol [Page 9] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + CMIP over TCP Lee LaBarre + Domain Names Paul Mockapetris + Dynamic Host Config Ralph Droms + Host Requirements Bob Braden + Interconnectivity Guy Almes + Internet MIB Craig Partridge + Joint Management Susan Hares + LAN Mgr MIB Amatzia Ben-Artzi + NISI Karen Bowers + NM Serial Interface Jeff Case + NOC Tools Bob Enger + OSPF Mike Petry + Open Systems Routing Marianne Lepp + OSI Interoperability Ross Callon + PDN Routing Group CH Rokitansky + Performance and CC Allison Mankin + Point - Point IP Drew Perkins + ST and CO-IP Claudio Topolcic + Telnet Dave Borman + User Documents Karen Roubicek + User Services Karen Bowers + +Routing + + Routing is the algorithm by which a network directs a packet from its + source to its destination. To appreciate the problem, watch a small + child trying to find a table in a restaurant. From the adult point + of view, the structure of the dining room is seen and an optimal + route easily chosen. The child, however, is presented with a set of + paths between tables where a good path, let alone the optimal one to + the goal is not discernible. + + A little more background might be appropriate. IP gateways (more + correctly routers) are boxes which have connections to multiple + networks and pass traffic between these nets. They decide how the + packet is to be sent based on the information in the IP header of the + packet and the state of the network. Each interface on a router has + an unique address appropriate to the network to which it is + connected. The information in the IP header which is used is + primarily the destination address. Other information (e.g., type of + service) is largely ignored at this time. The state of the network + is determined by the routers passing information among themselves. + The distribution of the database (what each node knows), the form of + the updates, and metrics used to measure the value of a connection, + are the parameters which determine the characteristics of a routing + protocol. + + Under some algorithms, each node in the network has complete + + + +Krol [Page 10] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + knowledge of the state of the network (the adult algorithm). This + implies the nodes must have larger amounts of local storage and + enough CPU to search the large tables in a short enough time + (remember, this must be done for each packet). Also, routing updates + usually contain only changes to the existing information (or you + spend a large amount of the network capacity passing around megabyte + routing updates). This type of algorithm has several problems. + Since the only way the routing information can be passed around is + across the network and the propagation time is non-trivial, the view + of the network at each node is a correct historical view of the + network at varying times in the past. (The adult algorithm, but + rather than looking directly at the dining area, looking at a + photograph of the dining room. One is likely to pick the optimal + route and find a bus-cart has moved in to block the path after the + photo was taken). These inconsistencies can cause circular routes + (called routing loops) where once a packet enters it is routed in a + closed path until its time to live (TTL) field expires and it is + discarded. + + Other algorithms may know about only a subset of the network. To + prevent loops in these protocols, they are usually used in a + hierarchical network. They know completely about their own area, but + to leave that area they go to one particular place (the default + gateway). Typically these are used in smaller networks (campus or + regional). + + Routing protocols in current use: + + Static (no protocol-table/default routing) + + Don't laugh. It is probably the most reliable, easiest to + implement, and least likely to get one into trouble for a small + network or a leaf on the Internet. This is, also, the only method + available on some CPU-operating system combinations. If a host is + connected to an Ethernet which has only one gateway off of it, one + should make that the default gateway for the host and do no other + routing. (Of course, that gateway may pass the reachability + information somehow on the other side of itself.) + + One word of warning, it is only with extreme caution that one + should use static routes in the middle of a network which is also + using dynamic routing. The routers passing dynamic information + are sometimes confused by conflicting dynamic and static routes. + If your host is on an ethernet with multiple routers to other + networks on it and the routers are doing dynamic routing among + themselves, it is usually better to take part in the dynamic + routing than to use static routes. + + + + +Krol [Page 11] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + RIP + + RIP is a routing protocol based on XNS (Xerox Network System) + adapted for IP networks. It is used by many routers (Proteon, + cisco, UB...) and many BSD Unix systems. BSD systems typically + run a program called "routed" to exchange information with other + systems running RIP. RIP works best for nets of small diameter + (few hops) where the links are of equal speed. The reason for + this is that the metric used to determine which path is best is + the hop-count. A hop is a traversal across a gateway. So, all + machines on the same Ethernet are zero hops away. If a router + connects connects two networks directly, a machine on the other + side of the router is one hop away. As the routing information is + passed through a gateway, the gateway adds one to the hop counts + to keep them consistent across the network. The diameter of a + network is defined as the largest hop-count possible within a + network. Unfortunately, a hop count of 16 is defined as infinity + in RIP meaning the link is down. Therefore, RIP will not allow + hosts separated by more than 15 gateways in the RIP space to + communicate. + + The other problem with hop-count metrics is that if links have + different speeds, that difference is not reflected in the hop- + count. So a one hop satellite link (with a .5 sec delay) at 56kb + would be used instead of a two hop T1 connection. Congestion can + be viewed as a decrease in the efficacy of a link. So, as a link + gets more congested, RIP will still know it is the best hop-count + route and congest it even more by throwing more packets on the + queue for that link. + + RIP was originally not well documented in the community and people + read BSD code to find out how RIP really worked. Finally, it was + documented in RFC-1058. + + Routed + + The routed program, which does RIP for 4.2BSD systems, has many + options. One of the most frequently used is: "routed -q" (quiet + mode) which means listen to RIP information, but never broadcast + it. This would be used by a machine on a network with multiple + RIP speaking gateways. It allows the host to determine which + gateway is best (hopwise) to use to reach a distant network. (Of + course, you might want to have a default gateway to prevent having + to pass all the addresses known to the Internet around with RIP.) + + There are two ways to insert static routes into routed; the + /etc/gateways file, and the "route add" command. Static routes + are useful if you know how to reach a distant network, but you are + + + +Krol [Page 12] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + not receiving that route using RIP. For the most part the "route + add" command is preferable to use. The reason for this is that + the command adds the route to that machine's routing table but + does not export it through RIP. The /etc/gateways file takes + precedence over any routing information received through a RIP + update. It is also broadcast as fact in RIP updates produced by + the host without question, so if a mistake is made in the + /etc/gateways file, that mistake will soon permeate the RIP space + and may bring the network to its knees. + + One of the problems with routed is that you have very little + control over what gets broadcast and what doesn't. Many times in + larger networks where various parts of the network are under + different administrative controls, you would like to pass on + through RIP only nets which you receive from RIP and you know are + reasonable. This prevents people from adding IP addresses to the + network which may be illegal and you being responsible for passing + them on to the Internet. This type of reasonability checks are + not available with routed and leave it usable, but inadequate for + large networks. + + Hello (RFC-891) + + Hello is a routing protocol which was designed and implemented in + a experimental software router called a "Fuzzball" which runs on a + PDP-11. It does not have wide usage, but is the routing protocol + formerly used on the initial NSFNET backbone. The data + transferred between nodes is similar to RIP (a list of networks + and their metrics). The metric, however, is milliseconds of + delay. This allows Hello to be used over nets of various link + speeds and performs better in congestive situations. + + One of the most interesting side effects of Hello based networks + is their great timekeeping ability. If you consider the problem + of measuring delay on a link for the metric, you find that it is + not an easy thing to do. You cannot measure round trip time since + the return link may be more congested, of a different speed, or + even not there. It is not really feasible for each node on the + network to have a builtin WWV (nationwide radio time standard) + receiver. So, you must design an algorithm to pass around time + between nodes over the network links where the delay in + transmission can only be approximated. Hello routers do this and + in a nationwide network maintain synchronized time within + milliseconds. (See also the Network Time Protocol, RFC-1059.) + + + + + + + +Krol [Page 13] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + Gateway Gateway Protocol (GGP RFC-823) + + The core gateways originally used GGP to exchange information + among themselves. This is a "distance-vector" algorithm. The new + core gateways use a "link-state" algorithm. + + NSFNET SPF (RFC-1074) + + The current NSFNET Backbone routers use a version of the ANSI IS- + IS and ISO ES-IS routing protocol. This is a "shortest path + first" (SPF) algorithm which is in the class of "link-state" + algorithms. + + Exterior Gateway Protocol (EGP RFC-904) + + EGP is not strictly a routing protocol, it is a reachability + protocol. It tells what nets can be reached through what gateway, + but not how good the connection is. It is the standard by which + gateways exchange network reachability information with the core + gateways. It is generally used between autonomous systems. There + is a metric passed around by EGP, but its usage is not + standardized formally. The metric's value ranges from 0 to 255 + with smaller values considered "better". Some implementations + consider the value 255 to mean unreachable. Many routers talk EGP + so they can be used to interface to routers of different + manufacture or operated by different administrations. For + example, when a router of the NSFNET Backbone exchanges routing or + reachability information with a gateway of a regional network EGP + is used. + + Gated + + So we have regional and campus networks talking RIP among + themselves and the DDN and NSFNET speaking EGP. How do they + interoperate? In the beginning, there was static routing. The + problem with doing static routing in the middle of the network is + that it is broadcast to the Internet whether it is usable or not. + Therefore, if a net becomes unreachable and you try to get there, + dynamic routing will immediately issue a net unreachable to you. + Under static routing the routers would think the net could be + reached and would continue trying until the application gave up + (in 2 or more minutes). Mark Fedor, then of Cornell, attempted to + solve these problems with a replacement for routed called gated. + + Gated talks RIP to RIP speaking hosts, EGP to EGP speakers, and + Hello to Hello'ers. These speakers frequently all live on one + Ethernet, but luckily (or unluckily) cannot understand each others + ruminations. In addition, under configuration file control it can + + + +Krol [Page 14] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + filter the conversion. For example, one can produce a + configuration saying announce RIP nets via Hello only if they are + specified in a list and are reachable by way of a RIP broadcast as + well. This means that if a rogue network appears in your local + site's RIP space, it won't be passed through to the Hello side of + the world. There are also configuration options to do static + routing and name trusted gateways. + + This may sound like the greatest thing since sliced bread, but + there is a catch called metric conversion. You have RIP measuring + in hops, Hello measuring in milliseconds, and EGP using arbitrary + small numbers. The big questions is how many hops to a + millisecond, how many milliseconds in the EGP number 3.... Also, + remember that infinity (unreachability) is 16 to RIP, 30000 or so + to Hello, and 8 to the DDN with EGP. Getting all these metrics to + work well together is no small feat. If done incorrectly and you + translate an RIP of 16 into an EGP of 6, everyone in the ARPANET + will still think your gateway can reach the unreachable and will + send every packet in the world your way. Gated is available via + anonymous FTP from devvax.tn.cornell.edu in directory pub/gated. + +Names + + All routing across the network is done by means of the IP address + associated with a packet. Since humans find it difficult to remember + addresses like 128.174.5.50, a symbolic name register was set up at + the NIC where people would say, "I would like my host to be named + uiucuxc". Machines connected to the Internet across the nation would + connect to the NIC in the middle of the night, check modification + dates on the hosts file, and if modified, move it to their local + machine. With the advent of workstations and micros, changes to the + host file would have to be made nightly. It would also be very labor + intensive and consume a lot of network bandwidth. RFC-1034 and a + number of others describe Domain Name Service (DNS), a distributed + data base system for mapping names into addresses. + + We must look a little more closely into what's in a name. First, + note that an address specifies a particular connection on a specific + network. If the machine moves, the address changes. Second, a + machine can have one or more names and one or more network addresses + (connections) to different networks. Names point to a something + which does useful work (i.e., the machine) and IP addresses point to + an interface on that provider. A name is a purely symbolic + representation of a list of addresses on the network. If a machine + moves to a different network, the addresses will change but the name + could remain the same. + + Domain names are tree structured names with the root of the tree at + + + +Krol [Page 15] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + the right. For example: + + uxc.cso.uiuc.edu + + is a machine called "uxc" (purely arbitrary), within the subdomains + of the U of I, and "uiuc" (the University of Illinois at Urbana), + registered with "edu" (the set of educational institutions). + + A simplified model of how a name is resolved is that on the user's + machine there is a resolver. The resolver knows how to contact + across the network a root name server. Root servers are the base of + the tree structured data retrieval system. They know who is + responsible for handling first level domains (e.g., 'edu'). What + root servers to use is an installation parameter. From the root + server the resolver finds out who provides 'edu' service. It + contacts the 'edu' name server which supplies it with a list of + addresses of servers for the subdomains (like 'uiuc'). This action + is repeated with the sub-domain servers until the final subdomain + returns a list of addresses of interfaces on the host in question. + The user's machine then has its choice of which of these addresses to + use for communication. + + A group may apply for its own domain name (like 'uiuc' above). This + is done in a manner similar to the IP address allocation. The only + requirements are that the requestor have two machines reachable from + the Internet, which will act as name servers for that domain. Those + servers could also act as servers for subdomains or other servers + could be designated as such. Note that the servers need not be + located in any particular place, as long as they are reachable for + name resolution. (U of I could ask Michigan State to act on its + behalf and that would be fine.) The biggest problem is that someone + must do maintenance on the database. If the machine is not + convenient, that might not be done in a timely fashion. The other + thing to note is that once the domain is allocated to an + administrative entity, that entity can freely allocate subdomains + using what ever manner it sees fit. + + The Berkeley Internet Name Domain (BIND) Server implements the + Internet name server for UNIX systems. The name server is a + distributed data base system that allows clients to name resources + and to share that information with other network hosts. BIND is + integrated with 4.3BSD and is used to lookup and store host names, + addresses, mail agents, host information, and more. It replaces the + /etc/hosts file or host name lookup. BIND is still an evolving + program. To keep up with reports on operational problems, future + design decisions, etc., join the BIND mailing list by sending a + request to Bind-Request@UCBARPA.BERKELEY.EDU. BIND can also be + obtained via anonymous FTP from ucbarpa.berkeley.edu. + + + +Krol [Page 16] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + There are several advantages in using BIND. One of the most + important is that it frees a host from relying on /etc/hosts being up + to date and complete. Within the .uiuc.edu domain, only a few hosts + are included in the host table distributed by SRI. The remainder are + listed locally within the BIND tables on uxc.cso.uiuc.edu (the server + machine for most of the .uiuc.edu domain). All are equally reachable + from any other Internet host running BIND, or any DNS resolver. + + BIND can also provide mail forwarding information for interior hosts + not directly reachable from the Internet. These hosts an either be + on non-advertised networks, or not connected to an IP network at all, + as in the case of UUCP-reachable hosts (see RFC-974). More + information on BIND is available in the "Name Server Operations Guide + for BIND" in UNIX System Manager's Manual, 4.3BSD release. + + There are a few special domains on the network, like NIC.DDN.MIL. + The hosts database at the NIC. There are others of the form + NNSC.NSF.NET. These special domains are used sparingly, and require + ample justification. They refer to servers under the administrative + control of the network rather than any single organization. This + allows for the actual server to be moved around the net while the + user interface to that machine remains constant. That is, should BBN + relinquish control of the NNSC, the new provider would be pointed to + by that name. + + In actuality, the domain system is a much more general and complex + system than has been described. Resolvers and some servers cache + information to allow steps in the resolution to be skipped. + Information provided by the servers can be arbitrary, not merely IP + addresses. This allows the system to be used both by non-IP networks + and for mail, where it may be necessary to give information on + intermediate mail bridges. + +What's wrong with Berkeley Unix + + University of California at Berkeley has been funded by DARPA to + modify the Unix system in a number of ways. Included in these + modifications is support for the Internet protocols. In earlier + versions (e.g., BSD 4.2) there was good support for the basic + Internet protocols (TCP, IP, SMTP, ARP) which allowed it to perform + nicely on IP Ethernets and smaller Internets. There were + deficiencies, however, when it was connected to complicated networks. + Most of these problems have been resolved under the newest release + (BSD 4.3). Since it is the springboard from which many vendors have + launched Unix implementations (either by porting the existing code or + by using it as a model), many implementations (e.g., Ultrix) are + still based on BSD 4.2. Therefore, many implementations still exist + with the BSD 4.2 problems. As time goes on, when BSD 4.3 trickles + + + +Krol [Page 17] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + through vendors as new release, many of the problems will be + resolved. Following is a list of some problem scenarios and their + handling under each of these releases. + + ICMP redirects + + Under the Internet model, all a system needs to know to get + anywhere in the Internet is its own address, the address of where + it wants to go, and how to reach a gateway which knows about the + Internet. It doesn't have to be the best gateway. If the system + is on a network with multiple gateways, and a host sends a packet + for delivery to a gateway which feels another directly connected + gateway is more appropriate, the gateway sends the sender a + message. This message is an ICMP redirect, which politely says, + "I'll deliver this message for you, but you really ought to use + that gateway over there to reach this host". BSD 4.2 ignores + these messages. This creates more stress on the gateways and the + local network, since for every packet sent, the gateway sends a + packet to the originator. BSD 4.3 uses the redirect to update its + routing tables, will use the route until it times out, then revert + to the use of the route it thinks is should use. The whole + process then repeats, but it is far better than one per packet. + + Trailers + + An application (like FTP) sends a string of octets to TCP which + breaks it into chunks, and adds a TCP header. TCP then sends + blocks of data to IP which adds its own headers and ships the + packets over the network. All this prepending of the data with + headers causes memory moves in both the sending and the receiving + machines. Someone got the bright idea that if packets were long + and they stuck the headers on the end (they became trailers), the + receiving machine could put the packet on the beginning of a page + boundary and if the trailer was OK merely delete it and transfer + control of the page with no memory moves involved. The problem is + that trailers were never standardized and most gateways don't know + to look for the routing information at the end of the block. When + trailers are used, the machine typically works fine on the local + network (no gateways involved) and for short blocks through + gateways (on which trailers aren't used). So TELNET and FTP's of + very short files work just fine and FTP's of long files seem to + hang. On BSD 4.2 trailers are a boot option and one should make + sure they are off when using the Internet. BSD 4.3 negotiates + trailers, so it uses them on its local net and doesn't use them + when going across the network. + + + + + + +Krol [Page 18] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + Retransmissions + + TCP fires off blocks to its partner at the far end of the + connection. If it doesn't receive an acknowledgement in a + reasonable amount of time it retransmits the blocks. The + determination of what is reasonable is done by TCP's + retransmission algorithm. + + There is no correct algorithm but some are better than others, + where worse is measured by the number of retransmissions done + unnecessarily. BSD 4.2 had a retransmission algorithm which + retransmitted quickly and often. This is exactly what you would + want if you had a bunch of machines on an Ethernet (a low delay + network of large bandwidth). If you have a network of relatively + longer delay and scarce bandwidth (e.g., 56kb lines), it tends to + retransmit too aggressively. Therefore, it makes the networks and + gateways pass more traffic than is really necessary for a given + conversation. Retransmission algorithms do adapt to the delay of + the network after a few packets, but 4.2's adapts slowly in delay + situations. BSD 4.3 does a lot better and tries to do the best + for both worlds. It fires off a few retransmissions really + quickly assuming it is on a low delay network, and then backs off + very quickly. It also allows the delay to be about 4 minutes + before it gives up and declares the connection broken. + + Even better than the original 4.3 code is a version of TCP with a + retransmission algorithm developed by Van Jacobson of LBL. He did + a lot of research into how the algorithm works on real networks + and modified it to get both better throughput and be friendlier to + the network. This code has been integrated into the later + releases of BSD 4.3 and can be fetched anonymously from + ucbarpa.berkeley.edu in directory 4.3. + + Time to Live + + The IP packet header contains a field called the time to live + (TTL) field. It is decremented each time the packet traverses a + gateway. TTL was designed to prevent packets caught in routing + loops from being passed forever with no hope of delivery. Since + the definition bears some likeness to the RIP hop count, some + misguided systems have set the TTL field to 15 because the + unreachable flag in RIP is 16. Obviously, no networks could have + more than 15 hops. The RIP space where hops are limited ends when + RIP is not used as a routing protocol any more (e.g., when NSFnet + starts transporting the packet). Therefore, it is quite easy for + a packet to require more than 15 hops. These machines will + exhibit the behavior of being able to reach some places but not + others even though the routing information appears correct. + + + +Krol [Page 19] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + Solving the problem typically requires kernel patches so it may be + difficult if source is not available. + +Appendix A - References to Remedial Information +----------------------------------------------- + + [1] Quarterman and Hoskins, "Notable Computer Networks", + Communications of the ACM, Vol. 29, No. 10, pp. 932-971, October + 1986. + + [2] Tannenbaum, A., "Computer Networks", Prentice Hall, 1981. + + [3] Hedrick, C., "Introduction to the Internet Protocols", Via + Anonymous FTP from topaz.rutgers.edu, directory pub/tcp-ip-docs, + file tcp-ip-intro.doc. + + [4] Comer, D., "Internetworking with TCP/IP: Principles, Protocols, + and Architecture", Copyright 1988, by Prentice-Hall, Inc., + Englewood Cliffs, NJ, 07632 ISBN 0-13-470154-2. + +Appendix B - List of Major RFCs +------------------------------- + +This list of key "Basic Beige" RFCs was compiled by J.K. Reynolds. This +is the 30 August 1989 edition of the list. + +RFC-768 User Datagram Protocol (UDP) +RFC-791 Internet Protocol (IP) +RFC-792 Internet Control Message Protocol (ICMP) +RFC-793 Transmission Control Protocol (TCP) +RFC-821 Simple Mail Transfer Protocol (SMTP) +RFC-822 Standard for the Format of ARPA Internet Text Messages +RFC-826 Ethernet Address Resolution Protocol +RFC-854 Telnet Protocol +RFC-862 Echo Protocol +RFC-894 A Standard for the Transmission of IP + Datagrams over Ethernet Networks +RFC-904 Exterior Gateway Protocol +RFC-919 Broadcasting Internet Datagrams +RFC-922 Broadcasting Internet Datagrams in the Presence of Subnets +RFC-950 Internet Standard Subnetting Procedure +RFC-951 Bootstrap Protocol (BOOTP) +RFC-959 File Transfer Protocol (FTP) +RFC-966 Host Groups: A Multicast Extension to the Internet Protocol +RFC-974 Mail Routing and the Domain System +RFC-1000 The Request for Comments Reference Guide +RFC-1009 Requirements for Internet Gateways +RFC-1010 Assigned Numbers + + + +Krol [Page 20] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + +RFC-1011 Official Internet Protocols +RFC-1012 Bibliography of Request for Comments 1 through 999 +RFC-1034 Domain Names - Concepts and Facilities +RFC-1035 Domain Names - Implementation +RFC-1042 A Standard for the Transmission of IP + Datagrams over IEEE 802 Networks +RFC-1048 BOOTP Vendor Information Extensions +RFC-1058 Routing Information Protocol +RFC-1059 Network Time Protocol (NTP) +RFC-1065 Structure and Identification of + Management Information for TCP/IP-based internets +RFC-1066 Management Information Base for Network + Management of TCP/IP-based internets +RFC-1084 BOOTP Vendor Information Extensions +RFC-1087 Ethics and the Internet +RFC-1095 The Common Management Information + Services and Protocol over TCP/IP (CMOT) +RFC-1098 A Simple Network Management Protocol (SNMP) +RFC-1100 IAB Official Protocol Standards +RFC-1101 DNS Encoding of Network Names and Other Types +RFC-1112 Host Extensions for IP Multicasting +RFC-1117 Internet Numbers + +Note: This list is a portion of a list of RFC's by topic that may be +retrieved from the NIC under NETINFO:RFC-SETS.TXT (anonymous FTP, of +course). + +The following list is not necessary for connection to the Internet, +but is useful in understanding the domain system, mail system, and +gateways: + +RFC-974 Mail Routing and the Domain System +RFC-1009 Requirements for Internet Gateways +RFC-1034 Domain Names - Concepts and Facilities +RFC-1035 Domain Names - Implementation and Specification +RFC-1101 DNS Encoding of Network Names and Other Types + + + + + + + + + + + + + + + +Krol [Page 21] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + +Appendix C - Contact Points for Network Information +--------------------------------------------------- + +Network Information Center (NIC) + + DDN Network Information Center + SRI International, Room EJ291 + 333 Ravenswood Avenue + Menlo Park, CA 94025 + (800) 235-3155 or (415) 859-3695 + + NIC@NIC.DDN.MIL + +NSF Network Service Center (NNSC) + + NNSC + BBN Systems and Technology Corporation + 10 Moulton St. + Cambridge, MA 02238 + (617) 873-3400 + + NNSC@NNSC.NSF.NET + +NSF Network Information Service (NIS) + + NIS + Merit Inc. + University of Michigan + 1075 Beal Avenue + Ann Arbor, MI 48109 + (313) 763-4897 + + INFO@NIS.NSF.NET + +CIC + + CSNET Coordination and Information Center + Bolt Beranek and Newman Inc. + 10 Moulton Street + Cambridge, MA 02238 + (617) 873-2777 + + INFO@SH.CS.NET + + + + + + + + +Krol [Page 22] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + +Glossary +-------- + + autonomous system + + A set of gateways under a single administrative control and using + compatible and consistent routing procedures. Generally speaking, + the gateways run by a particular organization. Since a gateway is + connected to two (or more) networks it is not usually correct to + say that a gateway is in a network. For example, the gateways + that connect regional networks to the NSF Backbone network are run + by Merit and form an autonomous system. Another example, the + gateways that connect campuses to NYSERNET are run by NYSER and + form an autonomous system. + + core gateway + + The innermost gateways of the Internet. These gateways have a + total picture of the reachability to all networks known to the + Internet. They then redistribute reachability information to + their neighbor gateways speaking EGP. It is from them your EGP + agent (there is one acting for you somewhere if you can reach the + core of the Internet) finds out it can reach all the nets on the + Internet. Which is then passed to you via Hello, gated, RIP. The + core gateways mostly connect campuses to the ARPANET, or + interconnect the ARPANET and the MILNET, and are run by BBN. + + count to infinity + + The symptom of a routing problem where routing information is + passed in a circular manner through multiple gateways. Each + gateway increments the metric appropriately and passes it on. As + the metric is passed around the loop, it increments to ever + increasing values until it reaches the maximum for the routing + protocol being used, which typically denotes a link outage. + + hold down + + When a router discovers a path in the network has gone down + announcing that that path is down for a minimum amount of time + (usually at least two minutes). This allows for the propagation + of the routing information across the network and prevents the + formation of routing loops. + + split horizon + + When a router (or group of routers working in consort) accept + routing information from multiple external networks, but do not + + + +Krol [Page 23] + +RFC 1118 The Hitchhikers Guide to the Internet September 1989 + + + pass on information learned from one external network to any + others. This is an attempt to prevent bogus routes to a network + from being propagated because of gossip or counting to infinity. + + DDN + + Defense Data Network the collective name for the ARPANET and + MILNET. Used frequently because although they are seperate + networks the operational and informational foci are the same. + +Security Considerations + + Security and privacy protection is a serious matter and too often + nothing is done about it. There are some known security bugs + (especially in access control) in BSD Unix and in some + implementations of network services. The hitchhikers guide does not + discuss these issues (too bad). + +Author's Address + + Ed Krol + University of Illinois + 195 DCL + 1304 West Springfield Avenue + Urbana, IL 61801-4399 + + Phone: (217) 333-7886 + + EMail: Krol@UXC.CSO.UIUC.EDU + + + + + + + + + + + + + + + + + + + + + + +Krol [Page 24] + \ No newline at end of file -- cgit v1.2.3