· 7 years ago · Dec 28, 2018, 09:42 PM
1
2
3
4
5
6
7Network Working Group E. Krol
8Request for Comments: 1118 University of Illinois Urbana
9 September 1989
10
11
12 The Hitchhikers Guide to the Internet
13
14Status of this Memo
15
16 This RFC is being distributed to members of the Internet community in
17 order to make available some "hints" which will allow new network
18 participants to understand how the direction of the Internet is set,
19 how to acquire online information and how to be a good Internet
20 neighbor. While the information discussed may not be relevant to the
21 research problems of the Internet, it may be interesting to a number
22 of researchers and implementors. No standards are defined or
23 specified in this memo. Distribution of this memo is unlimited.
24
25NOTICE:
26
27 The hitchhikers guide to the Internet is a very unevenly edited memo
28 and contains many passages which simply seemed to its editors like a
29 good idea at the time. It is an indispensable companion to all those
30 who are keen to make sense of life in an infinitely complex and
31 confusing Internet, for although it cannot hope to be useful or
32 informative on all matters, it does make the reassuring claim that
33 where it is inaccurate, it is at least definitively inaccurate. In
34 cases of major discrepancy it is always reality that's got it wrong.
35 And remember, DON'T PANIC. (Apologies to Douglas Adams.)
36
37Purpose and Audience
38
39 This document assumes that one is familiar with the workings of a
40 non-connected simple IP network (e.g., a few 4.3 BSD systems on an
41 Ethernet not connected to anywhere else). Appendix A contains
42 remedial information to get one to this point. Its purpose is to get
43 that person, familiar with a simple net, versed in the "oral
44 tradition" of the Internet to the point that that net can be
45 connected to the Internet with little danger to either. It is not a
46 tutorial, it consists of pointers to other places, literature, and
47 hints which are not normally documented. Since the Internet is a
48 dynamic environment, changes to this document will be made regularly.
49 The author welcomes comments and suggestions. This is especially
50 true of terms for the glossary (definitions are not necessary).
51
52
53
54
55
56
57
58Krol [Page 1]
59
60RFC 1118 The Hitchhikers Guide to the Internet September 1989
61
62
63What is the Internet?
64
65 In the beginning there was the ARPANET, a wide area experimental
66 network connecting hosts and terminal servers together. Procedures
67 were set up to regulate the allocation of addresses and to create
68 voluntary standards for the network. As local area networks became
69 more pervasive, many hosts became gateways to local networks. A
70 network layer to allow the interoperation of these networks was
71 developed and called Internet Protocol (IP). Over time other groups
72 created long haul IP based networks (NASA, NSF, states...). These
73 nets, too, interoperate because of IP. The collection of all of
74 these interoperating networks is the Internet.
75
76 A few groups provide much of the information services on the
77 Internet. Information Sciences Institute (ISI) does much of the
78 standardization and allocation work of the Internet acting as the
79 Internet Assigned Numbers Authority (IANA). SRI International
80 provides the principal information services for the Internet by
81 operating the Network Information Center (NIC). In fact, after you
82 are connected to the Internet most of the information in this
83 document can be retrieved from the SRI-NIC. Bolt Beranek and Newman
84 (BBN) provides information services for CSNET (the CIC) and NSFNET
85 (the NNSC), and Merit provides information services for NSFNET (the
86 NIS).
87
88Operating the Internet
89
90 Each network, be it the ARPANET, NSFNET or a regional network, has
91 its own operations center. The ARPANET is run by BBN, Inc. under
92 contract from DCA (on behalf of DARPA). Their facility is called the
93 Network Operations Center or NOC. Merit, Inc. operates NSFNET from
94 yet another and completely seperate NOC. It goes on to the regionals
95 having similar facilities to monitor and keep watch over the goings
96 on of their portion of the Internet. In addition, they all should
97 have some knowledge of what is happening to the Internet in total.
98 If a problem comes up, it is suggested that a campus network liaison
99 should contact the network operator to which he is directly
100 connected. That is, if you are connected to a regional network
101 (which is gatewayed to the NSFNET, which is connected to the
102 ARPANET...) and have a problem, you should contact your regional
103 network operations center.
104
105RFCs
106
107 The internal workings of the Internet are defined by a set of
108 documents called RFCs (Request for Comments). The general process
109 for creating an RFC is for someone wanting something formalized to
110 write a document describing the issue and mailing it to Jon Postel
111
112
113
114Krol [Page 2]
115
116RFC 1118 The Hitchhikers Guide to the Internet September 1989
117
118
119 (Postel@ISI.EDU). He acts as a referee for the proposal. It is then
120 commented upon by all those wishing to take part in the discussion
121 (electronically of course). It may go through multiple revisions.
122 Should it be generally accepted as a good idea, it will be assigned a
123 number and filed with the RFCs.
124
125 There are two independent categorizations of protocols. The first is
126 the state of standardization which is one of "standard", "draft
127 standard", "proposed", "experimental", or "historic". The second is
128 the status of this protocol which is one of "required",
129 "recommended", "elective", or "not recommended". One could expect a
130 particular protocol to move along the scale of status from elective
131 to required at the same time as it moves along the scale of
132 standardization from proposed to standard.
133
134 A Required Standard protocol (e.g., RFC-791, The Internet Protocol)
135 must be implemented on any host connected to the Internet.
136 Recommended Standard protocols are generally implemented by network
137 hosts. Lack of them does not preclude access to the Internet, but
138 may impact its usability. RFC-793 (Transmission Control Protocol) is
139 a Recommended Standard protocol. Elective Proposed protocols were
140 discussed and agreed to, but their application has never come into
141 wide use. This may be due to the lack of wide need for the specific
142 application (RFC-937, The Post Office Protocol) or that, although
143 technically superior, ran against other pervasive approaches. It is
144 suggested that should the facility be required by a particular site,
145 an implementation be done in accordance with the RFC. This insures
146 that, should the idea be one whose time has come, the implementation
147 will be in accordance with some standard and will be generally
148 usable.
149
150 Informational RFCs contain factual information about the Internet and
151 its operation (RFC-1010, Assigned Numbers). Finally, as the Internet
152 and technology have grown, some RFCs have become unnecessary. These
153 obsolete RFCs cannot be ignored, however. Frequently when a change
154 is made to some RFC that causes a new one to be issued obsoleting
155 others, the new RFC may only contains explanations and motivations
156 for the change. Understanding the model on which the whole facility
157 is based may involve reading the original and subsequent RFCs on the
158 topic. (Appendix B contains a list of what are considered to be the
159 major RFCs necessary for understanding the Internet).
160
161 Only a few RFCs actually specify standards, most RFCs are for
162 information or discussion purposes. To find out what the current
163 standards are see the RFC titled "IAB Official Protocol Standards"
164 (most recently published as RFC-1100).
165
166
167
168
169
170Krol [Page 3]
171
172RFC 1118 The Hitchhikers Guide to the Internet September 1989
173
174
175The Network Information Center (NIC)
176
177 The NIC is a facility available to all Internet users which provides
178 information to the community. There are three means of NIC contact:
179 network, telephone, and mail. The network accesses are the most
180 prevalent. Interactive access is frequently used to do queries of
181 NIC service overviews, look up user and host names, and scan lists of
182 NIC documents. It is available by using
183
184 %telnet nic.ddn.mil
185
186 on a BSD system, and following the directions provided by a user
187 friendly prompter. From poking around in the databases provided, one
188 might decide that a document named NETINFO:NUG.DOC (The Users Guide
189 to the ARPANET) would be worth having. It could be retrieved via an
190 anonymous FTP. An anonymous FTP would proceed something like the
191 following. (The dialogue may vary slightly depending on the
192 implementation of FTP you are using).
193
194 %ftp nic.ddn.mil
195 Connected to nic.ddn.mil
196 220 NIC.DDN.MIL FTP Server 5Z(47)-6 at Wed 17-Jun-87 12:00 PDT
197 Name (nic.ddn.mil:myname): anonymous
198 331 ANONYMOUS user ok, send real ident as password.
199 Password: myname
200 230 User ANONYMOUS logged in at Wed 17-Jun-87 12:01 PDT, job 15.
201 ftp> get netinfo:nug.doc
202 200 Port 18.144 at host 128.174.5.50 accepted.
203 150 ASCII retrieve of <NETINFO>NUG.DOC.11 started.
204 226 Transfer Completed 157675 (8) bytes transferred
205 local: netinfo:nug.doc remote:netinfo:nug.doc
206 157675 bytes in 4.5e+02 seconds (0.34 Kbytes/s)
207 ftp> quit
208 221 QUIT command received. Goodbye.
209
210 (Another good initial document to fetch is NETINFO:WHAT-THE-NIC-
211 DOES.TXT).
212
213 Questions of the NIC or problems with services can be asked of or
214 reported to using electronic mail. The following addresses can be
215 used:
216
217 NIC@NIC.DDN.MIL General user assistance, document requests
218 REGISTRAR@NIC.DDN.MIL User registration and WHOIS updates
219 HOSTMASTER@NIC.DDN.MIL Hostname and domain changes and updates
220 ACTION@NIC.DDN.MIL SRI-NIC computer operations
221 SUGGESTIONS@NIC.DDN.MIL Comments on NIC publications and services
222
223
224
225
226Krol [Page 4]
227
228RFC 1118 The Hitchhikers Guide to the Internet September 1989
229
230
231 For people without network access, or if the number of documents is
232 large, many of the NIC documents are available in printed form for a
233 small charge. One frequently ordered document for starting sites is
234 a compendium of major RFCs. Telephone access is used primarily for
235 questions or problems with network access. (See appendix B for
236 mail/telephone contact numbers).
237
238The NSFNET Network Service Center
239
240 The NSFNET Network Service Center (NNSC), located at BBN Systems and
241 Technologies Corp., is a project of the University Corporation for
242 Atmospheric Research under agreement with the National Science
243 Foundation. The NNSC provides support to end-users of NSFNET should
244 they have questions or encounter problems traversing the network.
245
246 The NNSC, which has information and documents online and in printed
247 form, distributes news through network mailing lists, bulletins, and
248 online reports. NNSC publications include a hardcopy newsletter, the
249 NSF Network News, which contains articles of interest to network
250 users and the Internet Resource Guide, which lists facilities (such
251 as supercomputer centers and on-line library catalogues) accessible
252 from the Internet. The Resource Guide can be obtained via anonymous
253 ftp to nnsc.nsf.net in the directory resource-guide, or by joining
254 the resource guide mailing list (send a subscription request to
255 Resource-Guide-Request@NNSC.NSF.NET.)
256
257Mail Reflectors
258
259 The way most people keep up to date on network news is through
260 subscription to a number of mail reflectors (also known as mail
261 exploders). Mail reflectors are special electronic mailboxes which,
262 when they receive a message, resend it to a list of other mailboxes.
263 This in effect creates a discussion group on a particular topic.
264 Each subscriber sees all the mail forwarded by the reflector, and if
265 one wants to put his "two cents" in sends a message with the comments
266 to the reflector.
267
268 The general format to subscribe to a mail list is to find the address
269 reflector and append the string -REQUEST to the mailbox name (not the
270 host name). For example, if you wanted to take part in the mailing
271 list for NSFNET reflected by NSFNET-INFO@MERIT.EDU, one sends a
272 request to NSFNET-INFO-REQUEST@MERIT.EDU. This may be a wonderful
273 scheme, but the problem is that you must know the list exists in the
274 first place. It is suggested that, if you are interested, you read
275 the mail from one list (like NSFNET-INFO) and you will probably
276 become familiar with the existence of others. A registration service
277 for mail reflectors is provided by the NIC in the files
278 NETINFO:INTEREST-GROUPS-1.TXT, NETINFO:INTEREST-GROUPS-2.TXT,
279
280
281
282Krol [Page 5]
283
284RFC 1118 The Hitchhikers Guide to the Internet September 1989
285
286
287 NETINFO:INTEREST-GROUPS-3.TXT, through NETINFO:INTEREST-GROUPS-9.TXT.
288
289 The NSFNET-INFO mail reflector is targeted at those people who have a
290 day to day interest in the news of the NSFNET (the backbone, regional
291 network, and Internet inter-connection site workers). The messages
292 are reflected by a central location and are sent as separate messages
293 to each subscriber. This creates hundreds of messages on the wide
294 area networks where bandwidth is the scarcest.
295
296 There are two ways in which a campus could spread the news and not
297 cause these messages to inundate the wide area networks. One is to
298 re-reflect the message on the campus. That is, set up a reflector on
299 a local machine which forwards the message to a campus distribution
300 list. The other is to create an alias on a campus machine which
301 places the messages into a notesfile on the topic. Campus users who
302 want the information could access the notesfile and see the messages
303 that have been sent since their last access. One might also elect to
304 have the campus wide area network liaison screen the messages in
305 either case and only forward those which are considered of merit.
306 Either of these schemes allows one message to be sent to the campus,
307 while allowing wide distribution within.
308
309Address Allocation
310
311 Before a local network can be connected to the Internet it must be
312 allocated a unique IP address. These addresses are allocated by
313 SRI-NIC. The allocation process consists of getting an application
314 form. Send a message to Hostmaster@NIC.DDN.MIL and ask for the
315 template for a connected address. This template is filled out and
316 mailed back to the hostmaster. An address is allocated and e-mailed
317 back to you. This can also be done by postal mail (Appendix B).
318
319 IP addresses are 32 bits long. It is usually written as four decimal
320 numbers separated by periods (e.g., 192.17.5.100). Each number is
321 the value of an octet of the 32 bits. Some networks might choose to
322 organize themselves as very flat (one net with a lot of nodes) and
323 some might organize hierarchically (many interconnected nets with
324 fewer nodes each and a backbone). To provide for these cases,
325 addresses were differentiated into class A, B, and C networks. This
326 classification had to with the interpretation of the octets. Class A
327 networks have the first octet as a network address and the remaining
328 three as a host address on that network. Class C addresses have
329 three octets of network address and one of host. Class B is split
330 two and two. Therefore, there is an address space for a few large
331 nets, a reasonable number of medium nets and a large number of small
332 nets. The high order bits in the first octet are coded to tell the
333 address format. There are very few unallocated class A nets, so a
334 very good case must be made for them. So as a practical matter, one
335
336
337
338Krol [Page 6]
339
340RFC 1118 The Hitchhikers Guide to the Internet September 1989
341
342
343 has to choose between Class B and Class C when placing an order.
344 (There are also class D (Multicast) and E (Experimental) formats.
345 Multicast addresses will likely come into greater use in the near
346 future, but are not frequently used yet).
347
348 In the past, sites requiring multiple network addresses requested
349 multiple discrete addresses (usually Class C). This was done because
350 much of the software available (notably 4.2BSD) could not deal with
351 subnetted addresses. Information on how to reach a particular
352 network (routing information) must be stored in Internet gateways and
353 packet switches. Some of these nodes have a limited capability to
354 store and exchange routing information (limited to about 700
355 networks). Therefore, it is suggested that any campus announce (make
356 known to the Internet) no more than two discrete network numbers.
357
358 If a campus expects to be constrained by this, it should consider
359 subnetting. Subnetting (RFC-950) allows one to announce one address
360 to the Internet and use a set of addresses on the campus. Basically,
361 one defines a mask which allows the network to differentiate between
362 the network portion and host portion of the address. By using a
363 different mask on the Internet and the campus, the address can be
364 interpreted in multiple ways. For example, if a campus requires two
365 networks internally and has the 32,000 addresses beginning
366 128.174.X.X (a Class B address) allocated to it, the campus could
367 allocate 128.174.5.X to one part of campus and 128.174.10.X to
368 another. By advertising 128.174 to the Internet with a subnet mask
369 of FF.FF.00.00, the Internet would treat these two addresses as one.
370 Within the campus a mask of FF.FF.FF.00 would be used, allowing the
371 campus to treat the addresses as separate entities. (In reality, you
372 don't pass the subnet mask of FF.FF.00.00 to the Internet, the octet
373 meaning is implicit in its being a class B address).
374
375 A word of warning is necessary. Not all systems know how to do
376 subnetting. Some 4.2BSD systems require additional software. 4.3BSD
377 systems subnet as released. Other devices and operating systems vary
378 in the problems they have dealing with subnets. Frequently, these
379 machines can be used as a leaf on a network but not as a gateway
380 within the subnetted portion of the network. As time passes and more
381 systems become 4.3BSD based, these problems should disappear.
382
383 There has been some confusion in the past over the format of an IP
384 broadcast address. Some machines used an address of all zeros to
385 mean broadcast and some all ones. This was confusing when machines
386 of both type were connected to the same network. The broadcast
387 address of all ones has been adopted to end the grief. Some systems
388 (e.g., 4.3 BSD) allow one to choose the format of the broadcast
389 address. If a system does allow this choice, care should be taken
390 that the all ones format is chosen. (This is explained in RFC-1009
391
392
393
394Krol [Page 7]
395
396RFC 1118 The Hitchhikers Guide to the Internet September 1989
397
398
399 and RFC-1010).
400
401Internet Problems
402
403 There are a number of problems with the Internet. Solutions to the
404 problems range from software changes to long term research projects.
405 Some of the major ones are detailed below:
406
407 Number of Networks
408
409 When the Internet was designed it was to have about 50 connected
410 networks. With the explosion of networking, the number is now
411 approaching 1000. The software in a group of critical gateways
412 (called the core gateways) are not able to pass or store much more
413 than that number. In the short term, core reallocation and
414 recoding has raised the number slightly.
415
416 Routing Issues
417
418 Along with sheer mass of the data necessary to route packets to a
419 large number of networks, there are many problems with the
420 updating, stability, and optimality of the routing algorithms.
421 Much research is being done in the area, but the optimal solution
422 to these routing problems is still years away. In most cases, the
423 the routing we have today works, but sub-optimally and sometimes
424 unpredictably. The current best hope for a good routing protocol
425 is something known as OSPFIGP which will be generally available
426 from many router manufacturers within a year.
427
428 Trust Issues
429
430 Gateways exchange network routing information. Currently, most
431 gateways accept on faith that the information provided about the
432 state of the network is correct. In the past this was not a big
433 problem since most of the gateways belonged to a single
434 administrative entity (DARPA). Now, with multiple wide area
435 networks under different administrations, a rogue gateway
436 somewhere in the net could cripple the Internet. There is design
437 work going on to solve both the problem of a gateway doing
438 unreasonable things and providing enough information to reasonably
439 route data between multiply connected networks (multi-homed
440 networks).
441
442 Capacity & Congestion
443
444 Some portions of the Internet are very congested during the busy
445 part of the day. Growth is dramatic with some networks
446 experiencing growth in traffic in excess of 20% per month.
447
448
449
450Krol [Page 8]
451
452RFC 1118 The Hitchhikers Guide to the Internet September 1989
453
454
455 Additional bandwidth is planned, but delivery and budgets might
456 not allow supply to keep up.
457
458Setting Direction and Priority
459
460 The Internet Activities Board (IAB), currently chaired by Vint Cerf
461 of NRI, is responsible for setting the technical direction,
462 establishing standards, and resolving problems in the Internet.
463
464 The current IAB members are:
465
466 Vinton Cerf - Chairman
467 David Clark - IRTF Chairman
468 Phillip Gross - IETF Chairman
469 Jon Postel - RFC Editor
470 Robert Braden - Executive Director
471 Hans-Werner Braun - NSFNET Liaison
472 Barry Leiner - CCIRN Liaison
473 Daniel Lynch - Vendor Liaison
474 Stephen Kent - Internet Security
475
476 This board is supported by a Research Task Force (chaired by Dave
477 Clark of MIT) and an Engineering Task Force (chaired by Phill Gross
478 of NRI).
479
480 The Internet Research Task Force has the following Research Groups:
481
482 Autonomous Networks Deborah Estrin
483 End-to-End Services Bob Braden
484 Privacy Steve Kent
485 User Interfaces Keith Lantz
486
487 The Internet Engineering Task Force has the following technical
488 areas:
489
490 Applications TBD
491 Host Protocols Craig Partridge
492 Internet Protocols Noel Chiappa
493 Routing Robert Hinden
494 Network Management David Crocker
495 OSI Interoperability Ross Callon, Robert Hagen
496 Operations TBD
497 Security TBD
498
499 The Internet Engineering Task Force has the following Working Groups:
500
501 ALERTMAN Louis Steinberg
502 Authentication Jeff Schiller
503
504
505
506Krol [Page 9]
507
508RFC 1118 The Hitchhikers Guide to the Internet September 1989
509
510
511 CMIP over TCP Lee LaBarre
512 Domain Names Paul Mockapetris
513 Dynamic Host Config Ralph Droms
514 Host Requirements Bob Braden
515 Interconnectivity Guy Almes
516 Internet MIB Craig Partridge
517 Joint Management Susan Hares
518 LAN Mgr MIB Amatzia Ben-Artzi
519 NISI Karen Bowers
520 NM Serial Interface Jeff Case
521 NOC Tools Bob Enger
522 OSPF Mike Petry
523 Open Systems Routing Marianne Lepp
524 OSI Interoperability Ross Callon
525 PDN Routing Group CH Rokitansky
526 Performance and CC Allison Mankin
527 Point - Point IP Drew Perkins
528 ST and CO-IP Claudio Topolcic
529 Telnet Dave Borman
530 User Documents Karen Roubicek
531 User Services Karen Bowers
532
533Routing
534
535 Routing is the algorithm by which a network directs a packet from its
536 source to its destination. To appreciate the problem, watch a small
537 child trying to find a table in a restaurant. From the adult point
538 of view, the structure of the dining room is seen and an optimal
539 route easily chosen. The child, however, is presented with a set of
540 paths between tables where a good path, let alone the optimal one to
541 the goal is not discernible.
542
543 A little more background might be appropriate. IP gateways (more
544 correctly routers) are boxes which have connections to multiple
545 networks and pass traffic between these nets. They decide how the
546 packet is to be sent based on the information in the IP header of the
547 packet and the state of the network. Each interface on a router has
548 an unique address appropriate to the network to which it is
549 connected. The information in the IP header which is used is
550 primarily the destination address. Other information (e.g., type of
551 service) is largely ignored at this time. The state of the network
552 is determined by the routers passing information among themselves.
553 The distribution of the database (what each node knows), the form of
554 the updates, and metrics used to measure the value of a connection,
555 are the parameters which determine the characteristics of a routing
556 protocol.
557
558 Under some algorithms, each node in the network has complete
559
560
561
562Krol [Page 10]
563
564RFC 1118 The Hitchhikers Guide to the Internet September 1989
565
566
567 knowledge of the state of the network (the adult algorithm). This
568 implies the nodes must have larger amounts of local storage and
569 enough CPU to search the large tables in a short enough time
570 (remember, this must be done for each packet). Also, routing updates
571 usually contain only changes to the existing information (or you
572 spend a large amount of the network capacity passing around megabyte
573 routing updates). This type of algorithm has several problems.
574 Since the only way the routing information can be passed around is
575 across the network and the propagation time is non-trivial, the view
576 of the network at each node is a correct historical view of the
577 network at varying times in the past. (The adult algorithm, but
578 rather than looking directly at the dining area, looking at a
579 photograph of the dining room. One is likely to pick the optimal
580 route and find a bus-cart has moved in to block the path after the
581 photo was taken). These inconsistencies can cause circular routes
582 (called routing loops) where once a packet enters it is routed in a
583 closed path until its time to live (TTL) field expires and it is
584 discarded.
585
586 Other algorithms may know about only a subset of the network. To
587 prevent loops in these protocols, they are usually used in a
588 hierarchical network. They know completely about their own area, but
589 to leave that area they go to one particular place (the default
590 gateway). Typically these are used in smaller networks (campus or
591 regional).
592
593 Routing protocols in current use:
594
595 Static (no protocol-table/default routing)
596
597 Don't laugh. It is probably the most reliable, easiest to
598 implement, and least likely to get one into trouble for a small
599 network or a leaf on the Internet. This is, also, the only method
600 available on some CPU-operating system combinations. If a host is
601 connected to an Ethernet which has only one gateway off of it, one
602 should make that the default gateway for the host and do no other
603 routing. (Of course, that gateway may pass the reachability
604 information somehow on the other side of itself.)
605
606 One word of warning, it is only with extreme caution that one
607 should use static routes in the middle of a network which is also
608 using dynamic routing. The routers passing dynamic information
609 are sometimes confused by conflicting dynamic and static routes.
610 If your host is on an ethernet with multiple routers to other
611 networks on it and the routers are doing dynamic routing among
612 themselves, it is usually better to take part in the dynamic
613 routing than to use static routes.
614
615
616
617
618Krol [Page 11]
619
620RFC 1118 The Hitchhikers Guide to the Internet September 1989
621
622
623 RIP
624
625 RIP is a routing protocol based on XNS (Xerox Network System)
626 adapted for IP networks. It is used by many routers (Proteon,
627 cisco, UB...) and many BSD Unix systems. BSD systems typically
628 run a program called "routed" to exchange information with other
629 systems running RIP. RIP works best for nets of small diameter
630 (few hops) where the links are of equal speed. The reason for
631 this is that the metric used to determine which path is best is
632 the hop-count. A hop is a traversal across a gateway. So, all
633 machines on the same Ethernet are zero hops away. If a router
634 connects connects two networks directly, a machine on the other
635 side of the router is one hop away. As the routing information is
636 passed through a gateway, the gateway adds one to the hop counts
637 to keep them consistent across the network. The diameter of a
638 network is defined as the largest hop-count possible within a
639 network. Unfortunately, a hop count of 16 is defined as infinity
640 in RIP meaning the link is down. Therefore, RIP will not allow
641 hosts separated by more than 15 gateways in the RIP space to
642 communicate.
643
644 The other problem with hop-count metrics is that if links have
645 different speeds, that difference is not reflected in the hop-
646 count. So a one hop satellite link (with a .5 sec delay) at 56kb
647 would be used instead of a two hop T1 connection. Congestion can
648 be viewed as a decrease in the efficacy of a link. So, as a link
649 gets more congested, RIP will still know it is the best hop-count
650 route and congest it even more by throwing more packets on the
651 queue for that link.
652
653 RIP was originally not well documented in the community and people
654 read BSD code to find out how RIP really worked. Finally, it was
655 documented in RFC-1058.
656
657 Routed
658
659 The routed program, which does RIP for 4.2BSD systems, has many
660 options. One of the most frequently used is: "routed -q" (quiet
661 mode) which means listen to RIP information, but never broadcast
662 it. This would be used by a machine on a network with multiple
663 RIP speaking gateways. It allows the host to determine which
664 gateway is best (hopwise) to use to reach a distant network. (Of
665 course, you might want to have a default gateway to prevent having
666 to pass all the addresses known to the Internet around with RIP.)
667
668 There are two ways to insert static routes into routed; the
669 /etc/gateways file, and the "route add" command. Static routes
670 are useful if you know how to reach a distant network, but you are
671
672
673
674Krol [Page 12]
675
676RFC 1118 The Hitchhikers Guide to the Internet September 1989
677
678
679 not receiving that route using RIP. For the most part the "route
680 add" command is preferable to use. The reason for this is that
681 the command adds the route to that machine's routing table but
682 does not export it through RIP. The /etc/gateways file takes
683 precedence over any routing information received through a RIP
684 update. It is also broadcast as fact in RIP updates produced by
685 the host without question, so if a mistake is made in the
686 /etc/gateways file, that mistake will soon permeate the RIP space
687 and may bring the network to its knees.
688
689 One of the problems with routed is that you have very little
690 control over what gets broadcast and what doesn't. Many times in
691 larger networks where various parts of the network are under
692 different administrative controls, you would like to pass on
693 through RIP only nets which you receive from RIP and you know are
694 reasonable. This prevents people from adding IP addresses to the
695 network which may be illegal and you being responsible for passing
696 them on to the Internet. This type of reasonability checks are
697 not available with routed and leave it usable, but inadequate for
698 large networks.
699
700 Hello (RFC-891)
701
702 Hello is a routing protocol which was designed and implemented in
703 a experimental software router called a "Fuzzball" which runs on a
704 PDP-11. It does not have wide usage, but is the routing protocol
705 formerly used on the initial NSFNET backbone. The data
706 transferred between nodes is similar to RIP (a list of networks
707 and their metrics). The metric, however, is milliseconds of
708 delay. This allows Hello to be used over nets of various link
709 speeds and performs better in congestive situations.
710
711 One of the most interesting side effects of Hello based networks
712 is their great timekeeping ability. If you consider the problem
713 of measuring delay on a link for the metric, you find that it is
714 not an easy thing to do. You cannot measure round trip time since
715 the return link may be more congested, of a different speed, or
716 even not there. It is not really feasible for each node on the
717 network to have a builtin WWV (nationwide radio time standard)
718 receiver. So, you must design an algorithm to pass around time
719 between nodes over the network links where the delay in
720 transmission can only be approximated. Hello routers do this and
721 in a nationwide network maintain synchronized time within
722 milliseconds. (See also the Network Time Protocol, RFC-1059.)
723
724
725
726
727
728
729
730Krol [Page 13]
731
732RFC 1118 The Hitchhikers Guide to the Internet September 1989
733
734
735 Gateway Gateway Protocol (GGP RFC-823)
736
737 The core gateways originally used GGP to exchange information
738 among themselves. This is a "distance-vector" algorithm. The new
739 core gateways use a "link-state" algorithm.
740
741 NSFNET SPF (RFC-1074)
742
743 The current NSFNET Backbone routers use a version of the ANSI IS-
744 IS and ISO ES-IS routing protocol. This is a "shortest path
745 first" (SPF) algorithm which is in the class of "link-state"
746 algorithms.
747
748 Exterior Gateway Protocol (EGP RFC-904)
749
750 EGP is not strictly a routing protocol, it is a reachability
751 protocol. It tells what nets can be reached through what gateway,
752 but not how good the connection is. It is the standard by which
753 gateways exchange network reachability information with the core
754 gateways. It is generally used between autonomous systems. There
755 is a metric passed around by EGP, but its usage is not
756 standardized formally. The metric's value ranges from 0 to 255
757 with smaller values considered "better". Some implementations
758 consider the value 255 to mean unreachable. Many routers talk EGP
759 so they can be used to interface to routers of different
760 manufacture or operated by different administrations. For
761 example, when a router of the NSFNET Backbone exchanges routing or
762 reachability information with a gateway of a regional network EGP
763 is used.
764
765 Gated
766
767 So we have regional and campus networks talking RIP among
768 themselves and the DDN and NSFNET speaking EGP. How do they
769 interoperate? In the beginning, there was static routing. The
770 problem with doing static routing in the middle of the network is
771 that it is broadcast to the Internet whether it is usable or not.
772 Therefore, if a net becomes unreachable and you try to get there,
773 dynamic routing will immediately issue a net unreachable to you.
774 Under static routing the routers would think the net could be
775 reached and would continue trying until the application gave up
776 (in 2 or more minutes). Mark Fedor, then of Cornell, attempted to
777 solve these problems with a replacement for routed called gated.
778
779 Gated talks RIP to RIP speaking hosts, EGP to EGP speakers, and
780 Hello to Hello'ers. These speakers frequently all live on one
781 Ethernet, but luckily (or unluckily) cannot understand each others
782 ruminations. In addition, under configuration file control it can
783
784
785
786Krol [Page 14]
787
788RFC 1118 The Hitchhikers Guide to the Internet September 1989
789
790
791 filter the conversion. For example, one can produce a
792 configuration saying announce RIP nets via Hello only if they are
793 specified in a list and are reachable by way of a RIP broadcast as
794 well. This means that if a rogue network appears in your local
795 site's RIP space, it won't be passed through to the Hello side of
796 the world. There are also configuration options to do static
797 routing and name trusted gateways.
798
799 This may sound like the greatest thing since sliced bread, but
800 there is a catch called metric conversion. You have RIP measuring
801 in hops, Hello measuring in milliseconds, and EGP using arbitrary
802 small numbers. The big questions is how many hops to a
803 millisecond, how many milliseconds in the EGP number 3.... Also,
804 remember that infinity (unreachability) is 16 to RIP, 30000 or so
805 to Hello, and 8 to the DDN with EGP. Getting all these metrics to
806 work well together is no small feat. If done incorrectly and you
807 translate an RIP of 16 into an EGP of 6, everyone in the ARPANET
808 will still think your gateway can reach the unreachable and will
809 send every packet in the world your way. Gated is available via
810 anonymous FTP from devvax.tn.cornell.edu in directory pub/gated.
811
812Names
813
814 All routing across the network is done by means of the IP address
815 associated with a packet. Since humans find it difficult to remember
816 addresses like 128.174.5.50, a symbolic name register was set up at
817 the NIC where people would say, "I would like my host to be named
818 uiucuxc". Machines connected to the Internet across the nation would
819 connect to the NIC in the middle of the night, check modification
820 dates on the hosts file, and if modified, move it to their local
821 machine. With the advent of workstations and micros, changes to the
822 host file would have to be made nightly. It would also be very labor
823 intensive and consume a lot of network bandwidth. RFC-1034 and a
824 number of others describe Domain Name Service (DNS), a distributed
825 data base system for mapping names into addresses.
826
827 We must look a little more closely into what's in a name. First,
828 note that an address specifies a particular connection on a specific
829 network. If the machine moves, the address changes. Second, a
830 machine can have one or more names and one or more network addresses
831 (connections) to different networks. Names point to a something
832 which does useful work (i.e., the machine) and IP addresses point to
833 an interface on that provider. A name is a purely symbolic
834 representation of a list of addresses on the network. If a machine
835 moves to a different network, the addresses will change but the name
836 could remain the same.
837
838 Domain names are tree structured names with the root of the tree at
839
840
841
842Krol [Page 15]
843
844RFC 1118 The Hitchhikers Guide to the Internet September 1989
845
846
847 the right. For example:
848
849 uxc.cso.uiuc.edu
850
851 is a machine called "uxc" (purely arbitrary), within the subdomains
852 of the U of I, and "uiuc" (the University of Illinois at Urbana),
853 registered with "edu" (the set of educational institutions).
854
855 A simplified model of how a name is resolved is that on the user's
856 machine there is a resolver. The resolver knows how to contact
857 across the network a root name server. Root servers are the base of
858 the tree structured data retrieval system. They know who is
859 responsible for handling first level domains (e.g., 'edu'). What
860 root servers to use is an installation parameter. From the root
861 server the resolver finds out who provides 'edu' service. It
862 contacts the 'edu' name server which supplies it with a list of
863 addresses of servers for the subdomains (like 'uiuc'). This action
864 is repeated with the sub-domain servers until the final subdomain
865 returns a list of addresses of interfaces on the host in question.
866 The user's machine then has its choice of which of these addresses to
867 use for communication.
868
869 A group may apply for its own domain name (like 'uiuc' above). This
870 is done in a manner similar to the IP address allocation. The only
871 requirements are that the requestor have two machines reachable from
872 the Internet, which will act as name servers for that domain. Those
873 servers could also act as servers for subdomains or other servers
874 could be designated as such. Note that the servers need not be
875 located in any particular place, as long as they are reachable for
876 name resolution. (U of I could ask Michigan State to act on its
877 behalf and that would be fine.) The biggest problem is that someone
878 must do maintenance on the database. If the machine is not
879 convenient, that might not be done in a timely fashion. The other
880 thing to note is that once the domain is allocated to an
881 administrative entity, that entity can freely allocate subdomains
882 using what ever manner it sees fit.
883
884 The Berkeley Internet Name Domain (BIND) Server implements the
885 Internet name server for UNIX systems. The name server is a
886 distributed data base system that allows clients to name resources
887 and to share that information with other network hosts. BIND is
888 integrated with 4.3BSD and is used to lookup and store host names,
889 addresses, mail agents, host information, and more. It replaces the
890 /etc/hosts file or host name lookup. BIND is still an evolving
891 program. To keep up with reports on operational problems, future
892 design decisions, etc., join the BIND mailing list by sending a
893 request to Bind-Request@UCBARPA.BERKELEY.EDU. BIND can also be
894 obtained via anonymous FTP from ucbarpa.berkeley.edu.
895
896
897
898Krol [Page 16]
899
900RFC 1118 The Hitchhikers Guide to the Internet September 1989
901
902
903 There are several advantages in using BIND. One of the most
904 important is that it frees a host from relying on /etc/hosts being up
905 to date and complete. Within the .uiuc.edu domain, only a few hosts
906 are included in the host table distributed by SRI. The remainder are
907 listed locally within the BIND tables on uxc.cso.uiuc.edu (the server
908 machine for most of the .uiuc.edu domain). All are equally reachable
909 from any other Internet host running BIND, or any DNS resolver.
910
911 BIND can also provide mail forwarding information for interior hosts
912 not directly reachable from the Internet. These hosts an either be
913 on non-advertised networks, or not connected to an IP network at all,
914 as in the case of UUCP-reachable hosts (see RFC-974). More
915 information on BIND is available in the "Name Server Operations Guide
916 for BIND" in UNIX System Manager's Manual, 4.3BSD release.
917
918 There are a few special domains on the network, like NIC.DDN.MIL.
919 The hosts database at the NIC. There are others of the form
920 NNSC.NSF.NET. These special domains are used sparingly, and require
921 ample justification. They refer to servers under the administrative
922 control of the network rather than any single organization. This
923 allows for the actual server to be moved around the net while the
924 user interface to that machine remains constant. That is, should BBN
925 relinquish control of the NNSC, the new provider would be pointed to
926 by that name.
927
928 In actuality, the domain system is a much more general and complex
929 system than has been described. Resolvers and some servers cache
930 information to allow steps in the resolution to be skipped.
931 Information provided by the servers can be arbitrary, not merely IP
932 addresses. This allows the system to be used both by non-IP networks
933 and for mail, where it may be necessary to give information on
934 intermediate mail bridges.
935
936What's wrong with Berkeley Unix
937
938 University of California at Berkeley has been funded by DARPA to
939 modify the Unix system in a number of ways. Included in these
940 modifications is support for the Internet protocols. In earlier
941 versions (e.g., BSD 4.2) there was good support for the basic
942 Internet protocols (TCP, IP, SMTP, ARP) which allowed it to perform
943 nicely on IP Ethernets and smaller Internets. There were
944 deficiencies, however, when it was connected to complicated networks.
945 Most of these problems have been resolved under the newest release
946 (BSD 4.3). Since it is the springboard from which many vendors have
947 launched Unix implementations (either by porting the existing code or
948 by using it as a model), many implementations (e.g., Ultrix) are
949 still based on BSD 4.2. Therefore, many implementations still exist
950 with the BSD 4.2 problems. As time goes on, when BSD 4.3 trickles
951
952
953
954Krol [Page 17]
955
956RFC 1118 The Hitchhikers Guide to the Internet September 1989
957
958
959 through vendors as new release, many of the problems will be
960 resolved. Following is a list of some problem scenarios and their
961 handling under each of these releases.
962
963 ICMP redirects
964
965 Under the Internet model, all a system needs to know to get
966 anywhere in the Internet is its own address, the address of where
967 it wants to go, and how to reach a gateway which knows about the
968 Internet. It doesn't have to be the best gateway. If the system
969 is on a network with multiple gateways, and a host sends a packet
970 for delivery to a gateway which feels another directly connected
971 gateway is more appropriate, the gateway sends the sender a
972 message. This message is an ICMP redirect, which politely says,
973 "I'll deliver this message for you, but you really ought to use
974 that gateway over there to reach this host". BSD 4.2 ignores
975 these messages. This creates more stress on the gateways and the
976 local network, since for every packet sent, the gateway sends a
977 packet to the originator. BSD 4.3 uses the redirect to update its
978 routing tables, will use the route until it times out, then revert
979 to the use of the route it thinks is should use. The whole
980 process then repeats, but it is far better than one per packet.
981
982 Trailers
983
984 An application (like FTP) sends a string of octets to TCP which
985 breaks it into chunks, and adds a TCP header. TCP then sends
986 blocks of data to IP which adds its own headers and ships the
987 packets over the network. All this prepending of the data with
988 headers causes memory moves in both the sending and the receiving
989 machines. Someone got the bright idea that if packets were long
990 and they stuck the headers on the end (they became trailers), the
991 receiving machine could put the packet on the beginning of a page
992 boundary and if the trailer was OK merely delete it and transfer
993 control of the page with no memory moves involved. The problem is
994 that trailers were never standardized and most gateways don't know
995 to look for the routing information at the end of the block. When
996 trailers are used, the machine typically works fine on the local
997 network (no gateways involved) and for short blocks through
998 gateways (on which trailers aren't used). So TELNET and FTP's of
999 very short files work just fine and FTP's of long files seem to
1000 hang. On BSD 4.2 trailers are a boot option and one should make
1001 sure they are off when using the Internet. BSD 4.3 negotiates
1002 trailers, so it uses them on its local net and doesn't use them
1003 when going across the network.
1004
1005
1006
1007
1008
1009
1010Krol [Page 18]
1011
1012RFC 1118 The Hitchhikers Guide to the Internet September 1989
1013
1014
1015 Retransmissions
1016
1017 TCP fires off blocks to its partner at the far end of the
1018 connection. If it doesn't receive an acknowledgement in a
1019 reasonable amount of time it retransmits the blocks. The
1020 determination of what is reasonable is done by TCP's
1021 retransmission algorithm.
1022
1023 There is no correct algorithm but some are better than others,
1024 where worse is measured by the number of retransmissions done
1025 unnecessarily. BSD 4.2 had a retransmission algorithm which
1026 retransmitted quickly and often. This is exactly what you would
1027 want if you had a bunch of machines on an Ethernet (a low delay
1028 network of large bandwidth). If you have a network of relatively
1029 longer delay and scarce bandwidth (e.g., 56kb lines), it tends to
1030 retransmit too aggressively. Therefore, it makes the networks and
1031 gateways pass more traffic than is really necessary for a given
1032 conversation. Retransmission algorithms do adapt to the delay of
1033 the network after a few packets, but 4.2's adapts slowly in delay
1034 situations. BSD 4.3 does a lot better and tries to do the best
1035 for both worlds. It fires off a few retransmissions really
1036 quickly assuming it is on a low delay network, and then backs off
1037 very quickly. It also allows the delay to be about 4 minutes
1038 before it gives up and declares the connection broken.
1039
1040 Even better than the original 4.3 code is a version of TCP with a
1041 retransmission algorithm developed by Van Jacobson of LBL. He did
1042 a lot of research into how the algorithm works on real networks
1043 and modified it to get both better throughput and be friendlier to
1044 the network. This code has been integrated into the later
1045 releases of BSD 4.3 and can be fetched anonymously from
1046 ucbarpa.berkeley.edu in directory 4.3.
1047
1048 Time to Live
1049
1050 The IP packet header contains a field called the time to live
1051 (TTL) field. It is decremented each time the packet traverses a
1052 gateway. TTL was designed to prevent packets caught in routing
1053 loops from being passed forever with no hope of delivery. Since
1054 the definition bears some likeness to the RIP hop count, some
1055 misguided systems have set the TTL field to 15 because the
1056 unreachable flag in RIP is 16. Obviously, no networks could have
1057 more than 15 hops. The RIP space where hops are limited ends when
1058 RIP is not used as a routing protocol any more (e.g., when NSFnet
1059 starts transporting the packet). Therefore, it is quite easy for
1060 a packet to require more than 15 hops. These machines will
1061 exhibit the behavior of being able to reach some places but not
1062 others even though the routing information appears correct.
1063
1064
1065
1066Krol [Page 19]
1067
1068RFC 1118 The Hitchhikers Guide to the Internet September 1989
1069
1070
1071 Solving the problem typically requires kernel patches so it may be
1072 difficult if source is not available.
1073
1074Appendix A - References to Remedial Information
1075-----------------------------------------------
1076
1077 [1] Quarterman and Hoskins, "Notable Computer Networks",
1078 Communications of the ACM, Vol. 29, No. 10, pp. 932-971, October
1079 1986.
1080
1081 [2] Tannenbaum, A., "Computer Networks", Prentice Hall, 1981.
1082
1083 [3] Hedrick, C., "Introduction to the Internet Protocols", Via
1084 Anonymous FTP from topaz.rutgers.edu, directory pub/tcp-ip-docs,
1085 file tcp-ip-intro.doc.
1086
1087 [4] Comer, D., "Internetworking with TCP/IP: Principles, Protocols,
1088 and Architecture", Copyright 1988, by Prentice-Hall, Inc.,
1089 Englewood Cliffs, NJ, 07632 ISBN 0-13-470154-2.
1090
1091Appendix B - List of Major RFCs
1092-------------------------------
1093
1094This list of key "Basic Beige" RFCs was compiled by J.K. Reynolds. This
1095is the 30 August 1989 edition of the list.
1096
1097RFC-768 User Datagram Protocol (UDP)
1098RFC-791 Internet Protocol (IP)
1099RFC-792 Internet Control Message Protocol (ICMP)
1100RFC-793 Transmission Control Protocol (TCP)
1101RFC-821 Simple Mail Transfer Protocol (SMTP)
1102RFC-822 Standard for the Format of ARPA Internet Text Messages
1103RFC-826 Ethernet Address Resolution Protocol
1104RFC-854 Telnet Protocol
1105RFC-862 Echo Protocol
1106RFC-894 A Standard for the Transmission of IP
1107 Datagrams over Ethernet Networks
1108RFC-904 Exterior Gateway Protocol
1109RFC-919 Broadcasting Internet Datagrams
1110RFC-922 Broadcasting Internet Datagrams in the Presence of Subnets
1111RFC-950 Internet Standard Subnetting Procedure
1112RFC-951 Bootstrap Protocol (BOOTP)
1113RFC-959 File Transfer Protocol (FTP)
1114RFC-966 Host Groups: A Multicast Extension to the Internet Protocol
1115RFC-974 Mail Routing and the Domain System
1116RFC-1000 The Request for Comments Reference Guide
1117RFC-1009 Requirements for Internet Gateways
1118RFC-1010 Assigned Numbers
1119
1120
1121
1122Krol [Page 20]
1123
1124RFC 1118 The Hitchhikers Guide to the Internet September 1989
1125
1126
1127RFC-1011 Official Internet Protocols
1128RFC-1012 Bibliography of Request for Comments 1 through 999
1129RFC-1034 Domain Names - Concepts and Facilities
1130RFC-1035 Domain Names - Implementation
1131RFC-1042 A Standard for the Transmission of IP
1132 Datagrams over IEEE 802 Networks
1133RFC-1048 BOOTP Vendor Information Extensions
1134RFC-1058 Routing Information Protocol
1135RFC-1059 Network Time Protocol (NTP)
1136RFC-1065 Structure and Identification of
1137 Management Information for TCP/IP-based internets
1138RFC-1066 Management Information Base for Network
1139 Management of TCP/IP-based internets
1140RFC-1084 BOOTP Vendor Information Extensions
1141RFC-1087 Ethics and the Internet
1142RFC-1095 The Common Management Information
1143 Services and Protocol over TCP/IP (CMOT)
1144RFC-1098 A Simple Network Management Protocol (SNMP)
1145RFC-1100 IAB Official Protocol Standards
1146RFC-1101 DNS Encoding of Network Names and Other Types
1147RFC-1112 Host Extensions for IP Multicasting
1148RFC-1117 Internet Numbers
1149
1150Note: This list is a portion of a list of RFC's by topic that may be
1151retrieved from the NIC under NETINFO:RFC-SETS.TXT (anonymous FTP, of
1152course).
1153
1154The following list is not necessary for connection to the Internet,
1155but is useful in understanding the domain system, mail system, and
1156gateways:
1157
1158RFC-974 Mail Routing and the Domain System
1159RFC-1009 Requirements for Internet Gateways
1160RFC-1034 Domain Names - Concepts and Facilities
1161RFC-1035 Domain Names - Implementation and Specification
1162RFC-1101 DNS Encoding of Network Names and Other Types
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178Krol [Page 21]
1179
1180RFC 1118 The Hitchhikers Guide to the Internet September 1989
1181
1182
1183Appendix C - Contact Points for Network Information
1184---------------------------------------------------
1185
1186Network Information Center (NIC)
1187
1188 DDN Network Information Center
1189 SRI International, Room EJ291
1190 333 Ravenswood Avenue
1191 Menlo Park, CA 94025
1192 (800) 235-3155 or (415) 859-3695
1193
1194 NIC@NIC.DDN.MIL
1195
1196NSF Network Service Center (NNSC)
1197
1198 NNSC
1199 BBN Systems and Technology Corporation
1200 10 Moulton St.
1201 Cambridge, MA 02238
1202 (617) 873-3400
1203
1204 NNSC@NNSC.NSF.NET
1205
1206NSF Network Information Service (NIS)
1207
1208 NIS
1209 Merit Inc.
1210 University of Michigan
1211 1075 Beal Avenue
1212 Ann Arbor, MI 48109
1213 (313) 763-4897
1214
1215 INFO@NIS.NSF.NET
1216
1217CIC
1218
1219 CSNET Coordination and Information Center
1220 Bolt Beranek and Newman Inc.
1221 10 Moulton Street
1222 Cambridge, MA 02238
1223 (617) 873-2777
1224
1225 INFO@SH.CS.NET
1226
1227
1228
1229
1230
1231
1232
1233
1234Krol [Page 22]
1235
1236RFC 1118 The Hitchhikers Guide to the Internet September 1989
1237
1238
1239Glossary
1240--------
1241
1242 autonomous system
1243
1244 A set of gateways under a single administrative control and using
1245 compatible and consistent routing procedures. Generally speaking,
1246 the gateways run by a particular organization. Since a gateway is
1247 connected to two (or more) networks it is not usually correct to
1248 say that a gateway is in a network. For example, the gateways
1249 that connect regional networks to the NSF Backbone network are run
1250 by Merit and form an autonomous system. Another example, the
1251 gateways that connect campuses to NYSERNET are run by NYSER and
1252 form an autonomous system.
1253
1254 core gateway
1255
1256 The innermost gateways of the Internet. These gateways have a
1257 total picture of the reachability to all networks known to the
1258 Internet. They then redistribute reachability information to
1259 their neighbor gateways speaking EGP. It is from them your EGP
1260 agent (there is one acting for you somewhere if you can reach the
1261 core of the Internet) finds out it can reach all the nets on the
1262 Internet. Which is then passed to you via Hello, gated, RIP. The
1263 core gateways mostly connect campuses to the ARPANET, or
1264 interconnect the ARPANET and the MILNET, and are run by BBN.
1265
1266 count to infinity
1267
1268 The symptom of a routing problem where routing information is
1269 passed in a circular manner through multiple gateways. Each
1270 gateway increments the metric appropriately and passes it on. As
1271 the metric is passed around the loop, it increments to ever
1272 increasing values until it reaches the maximum for the routing
1273 protocol being used, which typically denotes a link outage.
1274
1275 hold down
1276
1277 When a router discovers a path in the network has gone down
1278 announcing that that path is down for a minimum amount of time
1279 (usually at least two minutes). This allows for the propagation
1280 of the routing information across the network and prevents the
1281 formation of routing loops.
1282
1283 split horizon
1284
1285 When a router (or group of routers working in consort) accept
1286 routing information from multiple external networks, but do not
1287
1288
1289
1290Krol [Page 23]
1291
1292RFC 1118 The Hitchhikers Guide to the Internet September 1989
1293
1294
1295 pass on information learned from one external network to any
1296 others. This is an attempt to prevent bogus routes to a network
1297 from being propagated because of gossip or counting to infinity.
1298
1299 DDN
1300
1301 Defense Data Network the collective name for the ARPANET and
1302 MILNET. Used frequently because although they are seperate
1303 networks the operational and informational foci are the same.
1304
1305Security Considerations
1306
1307 Security and privacy protection is a serious matter and too often
1308 nothing is done about it. There are some known security bugs
1309 (especially in access control) in BSD Unix and in some
1310 implementations of network services. The hitchhikers guide does not
1311 discuss these issues (too bad).
1312
1313Author's Address
1314
1315 Ed Krol
1316 University of Illinois
1317 195 DCL
1318 1304 West Springfield Avenue
1319 Urbana, IL 61801-4399
1320
1321 Phone: (217) 333-7886
1322
1323 EMail: Krol@UXC.CSO.UIUC.EDU
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346Krol [Page 24]
1347