RFC relevance of networks

As per Relevance of the word networks, we have this rfc below:

Network Working Group E.
Request for Comments: 1118 University of Illinois
September 1989

The Hitchhikers Guide to the

Status of this

This RFC is being distributed to members of the Internet community
order to make available some "hints" which will allow new
participants to understand how the direction of the Internet is set
how to acquire online information and how to be a good
neighbor. While the information discussed may not be relevant to
research problems of the Internet, it may be interesting to a
of researchers and implementors. No standards are defined
specified in this memo. Distribution of this memo is unlimited

NOTICE

The hitchhikers guide to the Internet is a very unevenly edited
and contains many passages which simply seemed to its editors like
good idea at the time. It is an indispensable companion to all
who are keen to make sense of life in an infinitely complex
confusing Internet, for although it cannot hope to be useful
informative on all matters, it does make the reassuring claim
where it is inaccurate, it is at least definitively inaccurate.
cases of major discrepancy it is always reality that's got it wrong
And remember, DON'T PANIC. (Apologies to Douglas Adams.)

Purpose and

This document assumes that one is familiar with the workings of
non-connected simple IP network (e.g., a few 4.3 BSD systems on
Ethernet not connected to anywhere else). Appendix A
remedial information to get one to this point. Its purpose is to
that person, familiar with a simple net, versed in the "
tradition" of the Internet to the point that that net can
connected to the Internet with little danger to either. It is not
tutorial, it consists of pointers to other places, literature,
hints which are not normally documented. Since the Internet is
dynamic environment, changes to this document will be made regularly
The author welcomes comments and suggestions. This is
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
network connecting hosts and terminal servers together.
were set up to regulate the allocation of addresses and to
voluntary standards for the network. As local area networks
more pervasive, many hosts became gateways to local networks.
network layer to allow the interoperation of these networks
developed and called Internet Protocol (IP). Over time other
created long haul IP based networks (NASA, NSF, states...).
nets, too, interoperate because of IP. The collection of all
these interoperating networks is the Internet

A few groups provide much of the information services on
Internet. Information Sciences Institute (ISI) does much of
standardization and allocation work of the Internet acting as
Internet Assigned Numbers Authority (IANA). SRI
provides the principal information services for the Internet
operating the Network Information Center (NIC). In fact, after
are connected to the Internet most of the information in
document can be retrieved from the SRI-NIC. Bolt Beranek and
(BBN) provides information services for CSNET (the CIC) and
(the NNSC), and Merit provides information services for NSFNET (
NIS).

Operating the

Each network, be it the ARPANET, NSFNET or a regional network,
its own operations center. The ARPANET is run by BBN, Inc.
contract from DCA (on behalf of DARPA). Their facility is called
Network Operations Center or NOC. Merit, Inc. operates NSFNET
yet another and completely seperate NOC. It goes on to the
having similar facilities to monitor and keep watch over the
on of their portion of the Internet. In addition, they all
have some knowledge of what is happening to the Internet in total
If a problem comes up, it is suggested that a campus network
should contact the network operator to which he is
connected. That is, if you are connected to a regional
(which is gatewayed to the NSFNET, which is connected to
ARPANET...) and have a problem, you should contact your
network operations center

The internal workings of the Internet are defined by a set
documents called RFCs (Request for Comments). The general
for creating an RFC is for someone wanting something formalized
write a document describing the issue and mailing it to Jon

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
commented upon by all those wishing to take part in the
(electronically of course). It may go through multiple revisions
Should it be generally accepted as a good idea, it will be assigned
number and filed with the RFCs

There are two independent categorizations of protocols. The first
the state of standardization which is one of "standard", "
standard", "proposed", "experimental", or "historic". The second
the status of this protocol which is one of "required",
"recommended", "elective", or "not recommended". One could expect
particular protocol to move along the scale of status from
to required at the same time as it moves along the scale
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
hosts. Lack of them does not preclude access to the Internet,
may impact its usability. RFC-793 (Transmission Control Protocol)
a Recommended Standard protocol. Elective Proposed protocols
discussed and agreed to, but their application has never come
wide use. This may be due to the lack of wide need for the
application (RFC-937, The Post Office Protocol) or that,
technically superior, ran against other pervasive approaches. It
suggested that should the facility be required by a particular site
an implementation be done in accordance with the RFC. This
that, should the idea be one whose time has come, the
will be in accordance with some standard and will be
usable

Informational RFCs contain factual information about the Internet
its operation (RFC-1010, Assigned Numbers). Finally, as the
and technology have grown, some RFCs have become unnecessary.
obsolete RFCs cannot be ignored, however. Frequently when a
is made to some RFC that causes a new one to be issued
others, the new RFC may only contains explanations and
for the change. Understanding the model on which the whole
is based may involve reading the original and subsequent RFCs on
topic. (Appendix B contains a list of what are considered to be
major RFCs necessary for understanding the Internet).

Only a few RFCs actually specify standards, most RFCs are
information or discussion purposes. To find out what the
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
information to the community. There are three means of NIC contact
network, telephone, and mail. The network accesses are the
prevalent. Interactive access is frequently used to do queries
NIC service overviews, look up user and host names, and scan lists
NIC documents. It is available by

%telnet nic.ddn.

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

%ftp nic.ddn.
Connected to nic.ddn.
220 NIC.DDN.MIL FTP Server 5Z(47)-6 at Wed 17-Jun-87 12:00
Name (nic.ddn.mil:myname):
331 ANONYMOUS user ok, send real ident as password
Password:
230 User ANONYMOUS logged in at Wed 17-Jun-87 12:01 PDT, job 15.
ftp> get netinfo:nug.
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
local: netinfo:nug.doc remote:netinfo:nug.
157675 bytes in 4.5e+02 seconds (0.34 Kbytes/s
ftp>
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
reported to using electronic mail. The following addresses can
used

NIC@NIC.DDN.MIL General user assistance, document
REGISTRAR@NIC.DDN.MIL User registration and WHOIS
HOSTMASTER@NIC.DDN.MIL Hostname and domain changes and
ACTION@NIC.DDN.MIL SRI-NIC computer
SUGGESTIONS@NIC.DDN.MIL Comments on NIC publications and

Krol [Page 4]

RFC 1118 The Hitchhikers Guide to the Internet September 1989

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

The NSFNET Network Service

The NSFNET Network Service Center (NNSC), located at BBN Systems
Technologies Corp., is a project of the University Corporation
Atmospheric Research under agreement with the National
Foundation. The NNSC provides support to end-users of NSFNET
they have questions or encounter problems traversing the network

The NNSC, which has information and documents online and in
form, distributes news through network mailing lists, bulletins,
online reports. NNSC publications include a hardcopy newsletter,
NSF Network News, which contains articles of interest to
users and the Internet Resource Guide, which lists facilities (
as supercomputer centers and on-line library catalogues)
from the Internet. The Resource Guide can be obtained via
ftp to nnsc.nsf.net in the directory resource-guide, or by
the resource guide mailing list (send a subscription request
Resource-Guide-Request@NNSC.NSF.NET.)

Mail

The way most people keep up to date on network news is
subscription to a number of mail reflectors (also known as
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
one wants to put his "two cents" in sends a message with the
to the reflector

The general format to subscribe to a mail list is to find the
reflector and append the string -REQUEST to the mailbox name (not
host name). For example, if you wanted to take part in the
list for NSFNET reflected by NSFNET-INFO@MERIT.EDU, one sends
request to NSFNET-INFO-REQUEST@MERIT.EDU. This may be a
scheme, but the problem is that you must know the list exists in
first place. It is suggested that, if you are interested, you
the mail from one list (like NSFNET-INFO) and you will
become familiar with the existence of others. A registration
for mail reflectors is provided by the NIC in the
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
day to day interest in the news of the NSFNET (the backbone,
network, and Internet inter-connection site workers). The
are reflected by a central location and are sent as separate
to each subscriber. This creates hundreds of messages on the
area networks where bandwidth is the scarcest

There are two ways in which a campus could spread the news and
cause these messages to inundate the wide area networks. One is
re-reflect the message on the campus. That is, set up a reflector
a local machine which forwards the message to a campus
list. The other is to create an alias on a campus machine
places the messages into a notesfile on the topic. Campus users
want the information could access the notesfile and see the
that have been sent since their last access. One might also elect
have the campus wide area network liaison screen the messages
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

Before a local network can be connected to the Internet it must
allocated a unique IP address. These addresses are allocated
SRI-NIC. The allocation process consists of getting an
form. Send a message to Hostmaster@NIC.DDN.MIL and ask for
template for a connected address. This template is filled out
mailed back to the hostmaster. An address is allocated and e-
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
numbers separated by periods (e.g., 192.17.5.100). Each number
the value of an octet of the 32 bits. Some networks might choose
organize themselves as very flat (one net with a lot of nodes)
some might organize hierarchically (many interconnected nets
fewer nodes each and a backbone). To provide for these cases
addresses were differentiated into class A, B, and C networks.
classification had to with the interpretation of the octets. Class
networks have the first octet as a network address and the
three as a host address on that network. Class C addresses
three octets of network address and one of host. Class B is
two and two. Therefore, there is an address space for a few
nets, a reasonable number of medium nets and a large number of
nets. The high order bits in the first octet are coded to tell
address format. There are very few unallocated class A nets, so
very good case must be made for them. So as a practical matter,

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
future, but are not frequently used yet).

In the past, sites requiring multiple network addresses
multiple discrete addresses (usually Class C). This was done
much of the software available (notably 4.2BSD) could not deal
subnetted addresses. Information on how to reach a
network (routing information) must be stored in Internet gateways
packet switches. Some of these nodes have a limited capability
store and exchange routing information (limited to about 700
networks). Therefore, it is suggested that any campus announce (
known to the Internet) no more than two discrete network numbers

If a campus expects to be constrained by this, it should
subnetting. Subnetting (RFC-950) allows one to announce one
to the Internet and use a set of addresses on the campus. Basically
one defines a mask which allows the network to differentiate
the network portion and host portion of the address. By using
different mask on the Internet and the campus, the address can
interpreted in multiple ways. For example, if a campus requires
networks internally and has the 32,000 addresses
128.174.X.X (a Class B address) allocated to it, the campus
allocate 128.174.5.X to one part of campus and 128.174.10.X
another. By advertising 128.174 to the Internet with a subnet
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
campus to treat the addresses as separate entities. (In reality,
don't pass the subnet mask of FF.FF.00.00 to the Internet, the
meaning is implicit in its being a class B address).

A word of warning is necessary. Not all systems know how to
subnetting. Some 4.2BSD systems require additional software. 4.3
systems subnet as released. Other devices and operating systems
in the problems they have dealing with subnets. Frequently,
machines can be used as a leaf on a network but not as a
within the subnetted portion of the network. As time passes and
systems become 4.3BSD based, these problems should disappear

There has been some confusion in the past over the format of an
broadcast address. Some machines used an address of all zeros
mean broadcast and some all ones. This was confusing when
of both type were connected to the same network. The
address of all ones has been adopted to end the grief. Some
(e.g., 4.3 BSD) allow one to choose the format of the
address. If a system does allow this choice, care should be
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

There are a number of problems with the Internet. Solutions to
problems range from software changes to long term research projects
Some of the major ones are detailed below

Number of

When the Internet was designed it was to have about 50
networks. With the explosion of networking, the number is
approaching 1000. The software in a group of critical
(called the core gateways) are not able to pass or store much
than that number. In the short term, core reallocation
recoding has raised the number slightly

Routing

Along with sheer mass of the data necessary to route packets to
large number of networks, there are many problems with
updating, stability, and optimality of the routing algorithms
Much research is being done in the area, but the optimal
to these routing problems is still years away. In most cases,
the routing we have today works, but sub-optimally and
unpredictably. The current best hope for a good routing
is something known as OSPFIGP which will be generally
from many router manufacturers within a year

Trust

Gateways exchange network routing information. Currently,
gateways accept on faith that the information provided about
state of the network is correct. In the past this was not a
problem since most of the gateways belonged to a
administrative entity (DARPA). Now, with multiple wide
networks under different administrations, a rogue
somewhere in the net could cripple the Internet. There is
work going on to solve both the problem of a gateway
unreasonable things and providing enough information to
route data between multiply connected networks (multi-
networks).

Capacity &

Some portions of the Internet are very congested during the
part of the day. Growth is dramatic with some
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
not allow supply to keep up

Setting Direction and

The Internet Activities Board (IAB), currently chaired by Vint
of NRI, is responsible for setting the technical direction
establishing standards, and resolving problems in the Internet

The current IAB members are

Vinton Cerf -
David Clark - IRTF
Phillip Gross - IETF
Jon Postel - RFC
Robert Braden - Executive
Hans-Werner Braun - NSFNET
Barry Leiner - CCIRN
Daniel Lynch - Vendor
Stephen Kent - Internet

This board is supported by a Research Task Force (chaired by
Clark of MIT) and an Engineering Task Force (chaired by Phill
of NRI).

The Internet Research Task Force has the following Research Groups

Autonomous Networks Deborah
End-to-End Services Bob
Privacy Steve
User Interfaces Keith

The Internet Engineering Task Force has the following
areas

Applications
Host Protocols Craig
Internet Protocols Noel
Routing Robert
Network Management David
OSI Interoperability Ross Callon, Robert
Operations
Security

The Internet Engineering Task Force has the following Working Groups

ALERTMAN Louis
Authentication Jeff

Krol [Page 9]

RFC 1118 The Hitchhikers Guide to the Internet September 1989

CMIP over TCP Lee
Domain Names Paul
Dynamic Host Config Ralph
Host Requirements Bob
Interconnectivity Guy
Internet MIB Craig
Joint Management Susan
LAN Mgr MIB Amatzia Ben-
NISI Karen
NM Serial Interface Jeff
NOC Tools Bob
OSPF Mike
Open Systems Routing Marianne
OSI Interoperability Ross
PDN Routing Group CH
Performance and CC Allison
Point - Point IP Drew
ST and CO-IP Claudio
Telnet Dave
User Documents Karen
User Services Karen

Routing is the algorithm by which a network directs a packet from
source to its destination. To appreciate the problem, watch a
child trying to find a table in a restaurant. From the adult
of view, the structure of the dining room is seen and an
route easily chosen. The child, however, is presented with a set
paths between tables where a good path, let alone the optimal one
the goal is not discernible

A little more background might be appropriate. IP gateways (
correctly routers) are boxes which have connections to
networks and pass traffic between these nets. They decide how
packet is to be sent based on the information in the IP header of
packet and the state of the network. Each interface on a router
an unique address appropriate to the network to which it
connected. The information in the IP header which is used
primarily the destination address. Other information (e.g., type
service) is largely ignored at this time. The state of the
is determined by the routers passing information among themselves
The distribution of the database (what each node knows), the form
the updates, and metrics used to measure the value of a connection
are the parameters which determine the characteristics of a
protocol

Under some algorithms, each node in the network has

Krol [Page 10]

RFC 1118 The Hitchhikers Guide to the Internet September 1989

knowledge of the state of the network (the adult algorithm).
implies the nodes must have larger amounts of local storage
enough CPU to search the large tables in a short enough
(remember, this must be done for each packet). Also, routing
usually contain only changes to the existing information (or
spend a large amount of the network capacity passing around
routing updates). This type of algorithm has several problems
Since the only way the routing information can be passed around
across the network and the propagation time is non-trivial, the
of the network at each node is a correct historical view of
network at varying times in the past. (The adult algorithm,
rather than looking directly at the dining area, looking at
photograph of the dining room. One is likely to pick the
route and find a bus-cart has moved in to block the path after
photo was taken). These inconsistencies can cause circular
(called routing loops) where once a packet enters it is routed in
closed path until its time to live (TTL) field expires and it
discarded

Other algorithms may know about only a subset of the network.
prevent loops in these protocols, they are usually used in
hierarchical network. They know completely about their own area,
to leave that area they go to one particular place (the
gateway). Typically these are used in smaller networks (campus
regional).

Routing protocols in current use

Static (no protocol-table/default routing

Don't laugh. It is probably the most reliable, easiest
implement, and least likely to get one into trouble for a
network or a leaf on the Internet. This is, also, the only
available on some CPU-operating system combinations. If a host
connected to an Ethernet which has only one gateway off of it,
should make that the default gateway for the host and do no
routing. (Of course, that gateway may pass the
information somehow on the other side of itself.)

One word of warning, it is only with extreme caution that
should use static routes in the middle of a network which is
using dynamic routing. The routers passing dynamic
are sometimes confused by conflicting dynamic and static routes
If your host is on an ethernet with multiple routers to
networks on it and the routers are doing dynamic routing
themselves, it is usually better to take part in the
routing than to use static routes

Krol [Page 11]

RFC 1118 The Hitchhikers Guide to the Internet September 1989

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
run a program called "routed" to exchange information with
systems running RIP. RIP works best for nets of small
(few hops) where the links are of equal speed. The reason
this is that the metric used to determine which path is best
the hop-count. A hop is a traversal across a gateway. So,
machines on the same Ethernet are zero hops away. If a
connects connects two networks directly, a machine on the
side of the router is one hop away. As the routing information
passed through a gateway, the gateway adds one to the hop
to keep them consistent across the network. The diameter of
network is defined as the largest hop-count possible within
network. Unfortunately, a hop count of 16 is defined as
in RIP meaning the link is down. Therefore, RIP will not
hosts separated by more than 15 gateways in the RIP space
communicate

The other problem with hop-count metrics is that if links
different speeds, that difference is not reflected in the hop
count. So a one hop satellite link (with a .5 sec delay) at 56
would be used instead of a two hop T1 connection. Congestion
be viewed as a decrease in the efficacy of a link. So, as a
gets more congested, RIP will still know it is the best hop-
route and congest it even more by throwing more packets on
queue for that link

RIP was originally not well documented in the community and
read BSD code to find out how RIP really worked. Finally, it
documented in RFC-1058.

The routed program, which does RIP for 4.2BSD systems, has
options. One of the most frequently used is: "routed -q" (
mode) which means listen to RIP information, but never
it. This would be used by a machine on a network with
RIP speaking gateways. It allows the host to determine
gateway is best (hopwise) to use to reach a distant network. (
course, you might want to have a default gateway to prevent
to pass all the addresses known to the Internet around with RIP.)

There are two ways to insert static routes into routed;
/etc/gateways file, and the "route add" command. Static
are useful if you know how to reach a distant network, but you

Krol [Page 12]

RFC 1118 The Hitchhikers Guide to the Internet September 1989

not receiving that route using RIP. For the most part the "
add" command is preferable to use. The reason for this is
the command adds the route to that machine's routing table
does not export it through RIP. The /etc/gateways file
precedence over any routing information received through a
update. It is also broadcast as fact in RIP updates produced
the host without question, so if a mistake is made in
/etc/gateways file, that mistake will soon permeate the RIP
and may bring the network to its knees

One of the problems with routed is that you have very
control over what gets broadcast and what doesn't. Many times
larger networks where various parts of the network are
different administrative controls, you would like to pass
through RIP only nets which you receive from RIP and you know
reasonable. This prevents people from adding IP addresses to
network which may be illegal and you being responsible for
them on to the Internet. This type of reasonability checks
not available with routed and leave it usable, but inadequate
large networks

Hello (RFC-891)

Hello is a routing protocol which was designed and implemented
a experimental software router called a "Fuzzball" which runs on
PDP-11. It does not have wide usage, but is the routing
formerly used on the initial NSFNET backbone. The
transferred between nodes is similar to RIP (a list of
and their metrics). The metric, however, is milliseconds
delay. This allows Hello to be used over nets of various
speeds and performs better in congestive situations

One of the most interesting side effects of Hello based
is their great timekeeping ability. If you consider the
of measuring delay on a link for the metric, you find that it
not an easy thing to do. You cannot measure round trip time
the return link may be more congested, of a different speed,
even not there. It is not really feasible for each node on
network to have a builtin WWV (nationwide radio time standard
receiver. So, you must design an algorithm to pass around
between nodes over the network links where the delay
transmission can only be approximated. Hello routers do this
in a nationwide network maintain synchronized time
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
among themselves. This is a "distance-vector" algorithm. The
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
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
protocol. It tells what nets can be reached through what gateway
but not how good the connection is. It is the standard by
gateways exchange network reachability information with the
gateways. It is generally used between autonomous systems.
is a metric passed around by EGP, but its usage is
standardized formally. The metric's value ranges from 0 to 255
with smaller values considered "better". Some
consider the value 255 to mean unreachable. Many routers talk
so they can be used to interface to routers of
manufacture or operated by different administrations.
example, when a router of the NSFNET Backbone exchanges routing
reachability information with a gateway of a regional network
is used

So we have regional and campus networks talking RIP
themselves and the DDN and NSFNET speaking EGP. How do
interoperate? In the beginning, there was static routing.
problem with doing static routing in the middle of the network
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
reached and would continue trying until the application gave
(in 2 or more minutes). Mark Fedor, then of Cornell, attempted
solve these problems with a replacement for routed called gated

Gated talks RIP to RIP speaking hosts, EGP to EGP speakers,
Hello to Hello'ers. These speakers frequently all live on
Ethernet, but luckily (or unluckily) cannot understand each
ruminations. In addition, under configuration file control it

Krol [Page 14]

RFC 1118 The Hitchhikers Guide to the Internet September 1989

filter the conversion. For example, one can produce
configuration saying announce RIP nets via Hello only if they
specified in a list and are reachable by way of a RIP broadcast
well. This means that if a rogue network appears in your
site's RIP space, it won't be passed through to the Hello side
the world. There are also configuration options to do
routing and name trusted gateways

This may sound like the greatest thing since sliced bread,
there is a catch called metric conversion. You have RIP
in hops, Hello measuring in milliseconds, and EGP using
small numbers. The big questions is how many hops to
millisecond, how many milliseconds in the EGP number 3.... Also
remember that infinity (unreachability) is 16 to RIP, 30000 or
to Hello, and 8 to the DDN with EGP. Getting all these metrics
work well together is no small feat. If done incorrectly and
translate an RIP of 16 into an EGP of 6, everyone in the
will still think your gateway can reach the unreachable and
send every packet in the world your way. Gated is available
anonymous FTP from devvax.tn.cornell.edu in directory pub/gated

All routing across the network is done by means of the IP
associated with a packet. Since humans find it difficult to
addresses like 128.174.5.50, a symbolic name register was set up
the NIC where people would say, "I would like my host to be
uiucuxc". Machines connected to the Internet across the nation
connect to the NIC in the middle of the night, check
dates on the hosts file, and if modified, move it to their
machine. With the advent of workstations and micros, changes to
host file would have to be made nightly. It would also be very
intensive and consume a lot of network bandwidth. RFC-1034 and
number of others describe Domain Name Service (DNS), a
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
network. If the machine moves, the address changes. Second,
machine can have one or more names and one or more network
(connections) to different networks. Names point to a
which does useful work (i.e., the machine) and IP addresses point
an interface on that provider. A name is a purely
representation of a list of addresses on the network. If a
moves to a different network, the addresses will change but the
could remain the same

Domain names are tree structured names with the root of the tree

Krol [Page 15]

RFC 1118 The Hitchhikers Guide to the Internet September 1989

the right. For example

uxc.cso.uiuc.

is a machine called "uxc" (purely arbitrary), within the
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'
machine there is a resolver. The resolver knows how to
across the network a root name server. Root servers are the base
the tree structured data retrieval system. They know who
responsible for handling first level domains (e.g., 'edu').
root servers to use is an installation parameter. From the
server the resolver finds out who provides 'edu' service.
contacts the 'edu' name server which supplies it with a list
addresses of servers for the subdomains (like 'uiuc'). This
is repeated with the sub-domain servers until the final
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
use for communication

A group may apply for its own domain name (like 'uiuc' above).
is done in a manner similar to the IP address allocation. The
requirements are that the requestor have two machines reachable
the Internet, which will act as name servers for that domain.
servers could also act as servers for subdomains or other
could be designated as such. Note that the servers need not
located in any particular place, as long as they are reachable
name resolution. (U of I could ask Michigan State to act on
behalf and that would be fine.) The biggest problem is that
must do maintenance on the database. If the machine is
convenient, that might not be done in a timely fashion. The
thing to note is that once the domain is allocated to
administrative entity, that entity can freely allocate
using what ever manner it sees fit

The Berkeley Internet Name Domain (BIND) Server implements
Internet name server for UNIX systems. The name server is
distributed data base system that allows clients to name
and to share that information with other network hosts. BIND
integrated with 4.3BSD and is used to lookup and store host names
addresses, mail agents, host information, and more. It replaces
/etc/hosts file or host name lookup. BIND is still an
program. To keep up with reports on operational problems,
design decisions, etc., join the BIND mailing list by sending
request to Bind-Request@UCBARPA.BERKELEY.EDU. BIND can also
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
important is that it frees a host from relying on /etc/hosts being
to date and complete. Within the .uiuc.edu domain, only a few
are included in the host table distributed by SRI. The remainder
listed locally within the BIND tables on uxc.cso.uiuc.edu (the
machine for most of the .uiuc.edu domain). All are equally
from any other Internet host running BIND, or any DNS resolver

BIND can also provide mail forwarding information for interior
not directly reachable from the Internet. These hosts an either
on non-advertised networks, or not connected to an IP network at all
as in the case of UUCP-reachable hosts (see RFC-974).
information on BIND is available in the "Name Server Operations
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
NNSC.NSF.NET. These special domains are used sparingly, and
ample justification. They refer to servers under the
control of the network rather than any single organization.
allows for the actual server to be moved around the net while
user interface to that machine remains constant. That is, should
relinquish control of the NNSC, the new provider would be pointed
by that name

In actuality, the domain system is a much more general and
system than has been described. Resolvers and some servers
information to allow steps in the resolution to be skipped
Information provided by the servers can be arbitrary, not merely
addresses. This allows the system to be used both by non-IP
and for mail, where it may be necessary to give information
intermediate mail bridges

What's wrong with Berkeley

University of California at Berkeley has been funded by DARPA
modify the Unix system in a number of ways. Included in
modifications is support for the Internet protocols. In
versions (e.g., BSD 4.2) there was good support for the
Internet protocols (TCP, IP, SMTP, ARP) which allowed it to
nicely on IP Ethernets and smaller Internets. There
deficiencies, however, when it was connected to complicated networks
Most of these problems have been resolved under the newest
(BSD 4.3). Since it is the springboard from which many vendors
launched Unix implementations (either by porting the existing code
by using it as a model), many implementations (e.g., Ultrix)
still based on BSD 4.2. Therefore, many implementations still
with the BSD 4.2 problems. As time goes on, when BSD 4.3

Krol [Page 17]

RFC 1118 The Hitchhikers Guide to the Internet September 1989

through vendors as new release, many of the problems will
resolved. Following is a list of some problem scenarios and
handling under each of these releases

ICMP

Under the Internet model, all a system needs to know to
anywhere in the Internet is its own address, the address of
it wants to go, and how to reach a gateway which knows about
Internet. It doesn't have to be the best gateway. If the
is on a network with multiple gateways, and a host sends a
for delivery to a gateway which feels another directly
gateway is more appropriate, the gateway sends the sender
message. This message is an ICMP redirect, which politely says
"I'll deliver this message for you, but you really ought to
that gateway over there to reach this host". BSD 4.2
these messages. This creates more stress on the gateways and
local network, since for every packet sent, the gateway sends
packet to the originator. BSD 4.3 uses the redirect to update
routing tables, will use the route until it times out, then
to the use of the route it thinks is should use. The
process then repeats, but it is far better than one per packet

An application (like FTP) sends a string of octets to TCP
breaks it into chunks, and adds a TCP header. TCP then
blocks of data to IP which adds its own headers and ships
packets over the network. All this prepending of the data
headers causes memory moves in both the sending and the
machines. Someone got the bright idea that if packets were
and they stuck the headers on the end (they became trailers),
receiving machine could put the packet on the beginning of a
boundary and if the trailer was OK merely delete it and
control of the page with no memory moves involved. The problem
that trailers were never standardized and most gateways don't
to look for the routing information at the end of the block.
trailers are used, the machine typically works fine on the
network (no gateways involved) and for short blocks
gateways (on which trailers aren't used). So TELNET and FTP's
very short files work just fine and FTP's of long files seem
hang. On BSD 4.2 trailers are a boot option and one should
sure they are off when using the Internet. BSD 4.3
trailers, so it uses them on its local net and doesn't use
when going across the network

Krol [Page 18]

RFC 1118 The Hitchhikers Guide to the Internet September 1989

TCP fires off blocks to its partner at the far end of
connection. If it doesn't receive an acknowledgement in
reasonable amount of time it retransmits the blocks.
determination of what is reasonable is done by TCP'
retransmission algorithm

There is no correct algorithm but some are better than others
where worse is measured by the number of retransmissions
unnecessarily. BSD 4.2 had a retransmission algorithm
retransmitted quickly and often. This is exactly what you
want if you had a bunch of machines on an Ethernet (a low
network of large bandwidth). If you have a network of
longer delay and scarce bandwidth (e.g., 56kb lines), it tends
retransmit too aggressively. Therefore, it makes the networks
gateways pass more traffic than is really necessary for a
conversation. Retransmission algorithms do adapt to the delay
the network after a few packets, but 4.2's adapts slowly in
situations. BSD 4.3 does a lot better and tries to do the
for both worlds. It fires off a few retransmissions
quickly assuming it is on a low delay network, and then backs
very quickly. It also allows the delay to be about 4
before it gives up and declares the connection broken

Even better than the original 4.3 code is a version of TCP with
retransmission algorithm developed by Van Jacobson of LBL. He
a lot of research into how the algorithm works on real
and modified it to get both better throughput and be friendlier
the network. This code has been integrated into the
releases of BSD 4.3 and can be fetched anonymously
ucbarpa.berkeley.edu in directory 4.3.

Time to

The IP packet header contains a field called the time to
(TTL) field. It is decremented each time the packet traverses
gateway. TTL was designed to prevent packets caught in
loops from being passed forever with no hope of delivery.
the definition bears some likeness to the RIP hop count,
misguided systems have set the TTL field to 15 because
unreachable flag in RIP is 16. Obviously, no networks could
more than 15 hops. The RIP space where hops are limited ends
RIP is not used as a routing protocol any more (e.g., when
starts transporting the packet). Therefore, it is quite easy
a packet to require more than 15 hops. These machines
exhibit the behavior of being able to reach some places but
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
difficult if source is not available

Appendix A - References to Remedial
-----------------------------------------------

[1] Quarterman and Hoskins, "Notable Computer Networks",
Communications of the ACM, Vol. 29, No. 10, pp. 932-971,
1986.

[2] Tannenbaum, A., "Computer Networks", Prentice Hall, 1981.

[3] Hedrick, C., "Introduction to the Internet Protocols",
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
-------------------------------

This list of key "Basic Beige" RFCs was compiled by J.K. Reynolds.
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
RFC-826 Ethernet Address Resolution
RFC-854 Telnet
RFC-862 Echo
RFC-894 A Standard for the Transmission of
Datagrams over Ethernet
RFC-904 Exterior Gateway
RFC-919 Broadcasting Internet
RFC-922 Broadcasting Internet Datagrams in the Presence of
RFC-950 Internet Standard Subnetting
RFC-951 Bootstrap Protocol (BOOTP
RFC-959 File Transfer Protocol (FTP
RFC-966 Host Groups: A Multicast Extension to the Internet
RFC-974 Mail Routing and the Domain
RFC-1000 The Request for Comments Reference
RFC-1009 Requirements for Internet
RFC-1010 Assigned

Krol [Page 20]

RFC 1118 The Hitchhikers Guide to the Internet September 1989

RFC-1011 Official Internet
RFC-1012 Bibliography of Request for Comments 1 through 999
RFC-1034 Domain Names - Concepts and
RFC-1035 Domain Names -
RFC-1042 A Standard for the Transmission of
Datagrams over IEEE 802
RFC-1048 BOOTP Vendor Information
RFC-1058 Routing Information
RFC-1059 Network Time Protocol (NTP
RFC-1065 Structure and Identification
Management Information for TCP/IP-based
RFC-1066 Management Information Base for
Management of TCP/IP-based
RFC-1084 BOOTP Vendor Information
RFC-1087 Ethics and the
RFC-1095 The Common Management
Services and Protocol over TCP/IP (CMOT
RFC-1098 A Simple Network Management Protocol (SNMP
RFC-1100 IAB Official Protocol
RFC-1101 DNS Encoding of Network Names and Other
RFC-1112 Host Extensions for IP
RFC-1117 Internet

Note: This list is a portion of a list of RFC's by topic that may
retrieved from the NIC under NETINFO:RFC-SETS.TXT (anonymous FTP,
course).

The following list is not necessary for connection to the Internet
but is useful in understanding the domain system, mail system,
gateways

RFC-974 Mail Routing and the Domain
RFC-1009 Requirements for Internet
RFC-1034 Domain Names - Concepts and
RFC-1035 Domain Names - Implementation and
RFC-1101 DNS Encoding of Network Names and Other

Krol [Page 21]

RFC 1118 The Hitchhikers Guide to the Internet September 1989

Appendix C - Contact Points for Network
---------------------------------------------------

Network Information Center (NIC

DDN Network Information
SRI International, Room EJ291
333 Ravenswood
Menlo Park, CA 94025
(800) 235-3155 or (415) 859-3695

NIC@NIC.DDN.

NSF Network Service Center (NNSC

BBN Systems and Technology
10 Moulton St
Cambridge, MA 02238
(617) 873-3400

NNSC@NNSC.NSF.

NSF Network Information Service (NIS

Merit Inc
University of
1075 Beal
Ann Arbor, MI 48109
(313) 763-4897

INFO@NIS.NSF.

CSNET Coordination and Information
Bolt Beranek and Newman Inc
10 Moulton
Cambridge, MA 02238
(617) 873-2777

INFO@SH.CS.

Krol [Page 22]

RFC 1118 The Hitchhikers Guide to the Internet September 1989

--------

autonomous

A set of gateways under a single administrative control and
compatible and consistent routing procedures. Generally speaking
the gateways run by a particular organization. Since a gateway
connected to two (or more) networks it is not usually correct
say that a gateway is in a network. For example, the
that connect regional networks to the NSF Backbone network are
by Merit and form an autonomous system. Another example,
gateways that connect campuses to NYSERNET are run by NYSER
form an autonomous system

core

The innermost gateways of the Internet. These gateways have
total picture of the reachability to all networks known to
Internet. They then redistribute reachability information
their neighbor gateways speaking EGP. It is from them your
agent (there is one acting for you somewhere if you can reach
core of the Internet) finds out it can reach all the nets on
Internet. Which is then passed to you via Hello, gated, RIP.
core gateways mostly connect campuses to the ARPANET,
interconnect the ARPANET and the MILNET, and are run by BBN

count to

The symptom of a routing problem where routing information
passed in a circular manner through multiple gateways.
gateway increments the metric appropriately and passes it on.
the metric is passed around the loop, it increments to
increasing values until it reaches the maximum for the
protocol being used, which typically denotes a link outage

hold

When a router discovers a path in the network has gone
announcing that that path is down for a minimum amount of
(usually at least two minutes). This allows for the
of the routing information across the network and prevents
formation of routing loops

split

When a router (or group of routers working in consort)
routing information from multiple external networks, but do

Krol [Page 23]

RFC 1118 The Hitchhikers Guide to the Internet September 1989

pass on information learned from one external network to
others. This is an attempt to prevent bogus routes to a
from being propagated because of gossip or counting to infinity

Defense Data Network the collective name for the ARPANET
MILNET. Used frequently because although they are
networks the operational and informational foci are the same

Security

Security and privacy protection is a serious matter and too
nothing is done about it. There are some known security
(especially in access control) in BSD Unix and in
implementations of network services. The hitchhikers guide does
discuss these issues (too bad).

Author's

Ed
University of
195
1304 West Springfield
Urbana, IL 61801-4399

Phone: (217) 333-7886

EMail: Krol@UXC.CSO.UIUC.

Krol [Page 24]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX