So we have regional and campus networks talking RIP
among themselves, the NSFnet backbone talking
Hello, and the DDN speaking EGP.
How do they interoperate? In the beginning there was
static routing, assembled into the Fuzzball software
configured for each site. The problem with doing
static routing in the middle of the network is that it
is broadcast to the Internet whether it is usable or
not. Therefore, if a net becomes unreachable and you
try to get there, dynamic routing will immediately
issue a net unreachable to you. Under static routing
the routers would think the net could be reached and
would continue trying until the application gave up (in
2 or more minutes). Mark Fedor of Cornell
(fedor@devvax.tn.cornell.edu) attempted to solve these
problems with a replacement for "routed" called "gated".
"Gated" talks RIP to RIP speaking hosts, EGP to EGP
speakers, and Hello to Hello'ers. These speakers
frequently all live on one Ethernet, but luckily (or
unluckily) cannot understand each others ruminations.
In addition, under configuration file control it can
filter the conversion. For example, one can produce a
configuration saying announce RIP nets via Hello only
if they are specified in a list and are reachable by
way of a RIP broadcast as well. This means that if a
rogue network appears in your local site's RIP space,
it won't be passed through to the Hello side of the
world. There are also configuration options to do
static routing and name trusted gateways.
This may sound like the greatest thing since sliced
bread, but there is a catch called metric conversion.
You have RIP measuring in hops, Hello measuring in
milliseconds, and EGP using arbitrary small numbers.
The big questions is how many hops to a millisecond,
how many milliseconds in the EGP number 3.... Also,
remember that infinity (unreachability) is 16 to RIP,
30000 or so to Hello, and 8 to the DDN with EGP.
Getting all these metrics to work well together is no
small feat. If done incorrectly and you translate an
RIP of 16 into an EGP of 6, everyone in the ARPAnet
will still think your gateway can reach the unreachable
and will send every packet in the world your way. For
these reasons, Mark requests that you consult closely
with him when configuring and using "gated".
-14-
"Names"
All routing across the network is done by means of the IP
address associated with a packet. Since humans find it
difficult to remember addresses like 128.174.5.50, a symbolic
name register was set up at the NIC where people would say
"I would like my host to be named 'uiucuxc'". Machines
connected to the Internet across the nation would connect to
the NIC in the middle of the night, check modification dates
on the hosts file, and if modified move it to their local
machine. With the advent of workstations and micros,
changes to the host file would have to be made nightly. It
would also be very labor intensive and consume a lot of
network bandwidth. RFC-882 and a number of others describe
domain name service, a distributed data base system for
mapping names into addresses.
We must look a little more closely into what's in a name.
First, note that an address specifies a particular connec-
tion on a specific network. If the machine moves, the
address changes. Second, a machine can have one or more
names and one or more network addresses (connections) to
different networks. Names point to a something which does
useful work (i.e. the machine) and IP addresses point to an
interface on that provider. A name is a purely symbolic
representation of a list of addresses on the network. If a
machine moves to a different network, the addresses will
change but the name could remain the same.
Domain names are tree structured names with the root of the
tree at the right. For example:
uxc.cso.uiuc.edu
is a machine called 'uxc' (purely arbitrary), within the
subdomains method of allocation of the U of I) and 'uiuc'
(the University of Illinois at Urbana), registered with
'edu' (the set of educational institutions).
A simplified model of how a name is resolved is that on the
user's machine there is a resolver. The resolver knows how
to contact across the network a root name server. Root
servers are the base of the tree structured data retrieval
system. They know who is responsible for handling first
level domains (e.g. 'edu'). What root servers to use is an
installation parameter. From the root server the resolver
finds out who provides 'edu' service. It contacts the 'edu'
name server which supplies it with a list of addresses of
servers for the subdomains (like 'uiuc'). This action is
repeated with the subdomain servers until the final sub-
domain returns a list of addresses of interfaces on the host
in question. The user's machine then has its choice of
which of these addresses to use for communication.
-15-
A group may apply for its own domain name (like 'uiuc'
above). This is done in a manner similar to the IP address
allocation. The only requirements are that the requestor
have two machines reachable from the Internet, which will
act as name servers for that domain. Those servers could
also act as servers for subdomains or other servers could be
designated as such. Note that the servers need not be
located in any particular place, as long as they are reach-
able for name resolution. (U of I could ask Michigan State
to act on its behalf and that would be fine). The biggest
problem is that someone must do maintenance on the database.
If the machine is not convenient, that might not be done in
a timely fashion. The other thing to note is that once the
domain is allocated to an administrative entity, that entity
can freely allocate subdomains using what ever manner it
sees fit.
The Berkeley Internet Name Domain (BIND) Server implements
the Internet name server for UNIX systems. The name server
is a distributed data base system that allows clients to
name resources and to share that information with other net-
work hosts. BIND is integrated with 4.3BSD and is used to
lookup and store host names, addresses, mail agents, host
information, and more. It replaces the "/etc/hosts" file for
host name lookup. BIND is still an evolving program. To
keep up with reports on operational problems, future design
decisions, etc, join the BIND mailing list by sending a
request to "bind-request@ucbarp.Berkeley.EDU". BIND can also
be obtained via anonymous FTP from ucbarpa.berkley.edu.
There are several advantages in using BIND. One of the most
important is that it frees a host from relying on "/etc/hosts"
being up to date and complete. Within the .uiuc.edu domain,
only a few hosts are included in the host table distributed
by SRI. The remainder are listed locally within the BIND
tables on uxc.cso.uiuc.edu (the server machine for most of
the .uiuc.edu domain). All are equally reachable from any
other Internet host running BIND.
BIND can also provide mail forwarding information for inte-
rior hosts not directly reachable from the Internet. These
hosts can either be on non-advertised networks, or not con-
nected to a network at all, as in the case of UUCP-reachable
hosts. More information on BIND is available in the "Name
Server Operations Guide for BIND" in "UNIX System Manager's
Manual", 4.3BSD release.
There are a few special domains on the network, like SRI-
NIC.ARPA. The 'arpa' domain is historical, referring to
hosts registered in the old hosts database at the NIC.
There are others of the form NNSC.NSF.NET. These special
domains are used sparingly and require ample justification.
They refer to servers under the administrative control of
-16-
the network rather than any single organization. This
allows for the actual server to be moved around the net
while the user interface to that machine remains constant.
That is, should BBN relinquish control of the NNSC, the new
provider would be pointed to by that name.
In actuality, the domain system is a much more general and
complex system than has been described. Resolvers and some
servers cache information to allow steps in the resolution
to be skipped. Information provided by the servers can be
arbitrary, not merely IP addresses. This allows the system
to be used both by non-IP networks and for mail, where it
may be necessary to give information on intermediate mail
bridges.