FromTheArpanetToTheInternet.txt (93.15 KB)
From the ARPANET to the Internet
A Study of the ARPANET TCP/IP Digest
and of the Role of Online Communication
in the Transition from the ARPANET to the Internet
by Ronda Hauben
rh120@columbia.edu
"Large-system programming has over the past decade been such a
tar pit, and many great and powerful beasts have thrashed
violently in it. Most have emerged with running systems -- few
have met goals, schedules, and budgets. Large and small, massive
or wiry, team after team has become entangled in the tar. No one
thing seems to cause the difficulty -- any particular paw can be
pulled away. But the accumulation of simultaneous and interacting
factors brings slower and slower motion. Everyone seems to have
been surprised by the stickiness of the problem, and it is hard
to discern the nature of it. But we must try to understand it if
we are to solve it."
Frederick P. Brooks, Jr.
"I am looking for implementations of TCP/IP for UNIX systems,
including an interface for an IMP."
Mike Muuss
"People participating in this transition of the ARPANET into the
internet environment are participating in an event as exciting as
the construction of the ARPANET and I am very proud to be a part
of it."
Vint Cerf
"To get anything done in any highly articulated organization, you
have got to carry people at all sorts of levels. It is their
decisions, their acquiescence or enthusiasm (above all, the
absence of their passive resistance) which are going to decide
whether a strategy goes through in time."
C. P. Snow
Introduction
In the development of large scale engineering projects,
communication among the different people working on the project
becomes a significant and often unsolvable problem. The same is
true in particular in the development of computers, and
especially of computer software.
The development of the ARPANET, including the research and
practical work which set the basis for the current Internet, had
the advantage of the network to facilitate the needed
communication. In the process of developing the ARPANET,
networking pioneers built a communication process, first by
utilizing email and then mailing lists. In a similar way,
participants in the UNIX community built Usenet and UUCPnet to
facilitate communication among those in the UNIX community.
By 1980, the U.S. Department of Defense (DoD) decided that
the ARPANET technology, which utilized a hardware subnet of mini
computers called Interface Message Processors (IMPs), was
becoming obsolete. Recognizing the need to update
this technology, they proposed new hardware to replace the IMP
backbone of the ARPANET. Even more importantly, they decided to
have networking capability built into software that would be used
to connect different and hitherto otherwise incompatible
computers. This new software would make it possible to connect
different networks of computers rather than just connecting
different computers. A date of January 1, 1983 was set for the
cutover to make the transition from the hardware based IMP subnet
backbone for the ARPANET, to the new form of network that would
connect different networks. The new network of networks would be
based on using a set of common protocols known as the TCP/IP
protocol suite.
This networking research was funded by the U.S. Department
of Defense and there was a simultaneous process ongoing to link
the computers within the DoD. Rather than a set of isolated and
secret activities, the work was done collaboratively under DoD
contracts and by ARPA funded university researchers doing ARPA
related research. Usenet, also developing in the early 1980s,
was a network developed by the Unix community, who were in many
instances university graduate students and researchers at the
Bell Telephone Laboratories of AT&T.
First the transition had to be made from the ARPANET
protocol NCP to the Internet protocols TCP and IP.
Communication among the different sites which had to make this
transition was facilitated by the ARPANET and Usenet themselves,
and in particular by a mailing list which was available to those
on the ARPANET or on Usenet.
This paper will examine how the transformation was documented
and supported via the communication that was made possible on the
ARPANET mailing list "TCP/IP Digest".(1a) This mailing list
documents the transition not only from NCP to TPC/IP, but also
from the single network of the ARPANET to the split of the
ARPANET into two separate networks connected via IP gateways (or
routers), and thus into an Internet made up of two separate
networks, the ARPANET and MILNET.
The Beginning of the TCP/IP Digest
The TCP/IP Digest was started by Mike Muuss a research
computer scientist at the U.S. Army Ballistics Research
Laboratory (BRL). Active on the ARPANET UNIX-Wizards mailing
list, Muuss wrote to that mailing list on October 2, 1981 asking
what implementations for TCP/IP existed for UNIX systems.
In a message dated October 2, 1981, Muuss wrote:
I am looking for implementations of TCP/IP for UNIX systems,
including an interface for an IMP.
I already know of the 3Com version. Anybody with comments?
I would be most interested in hearing them!
If there is interest, I will forward a summary to the list.
-Mike(1)
A year earlier, in July of 1980, a report by the Defense
Communications Agency (DCA) which administered the ARPANET during
this period, documented that the ARPANET had grown to over 66
nodes and included 4000-5000 users.(2)
Though the report noted the success of the ARPANET project,
there were problems developing, since, as the report explained,
"The basic hardware and software are becoming obsolete." It
described how the nodes used minicomputers developed in the 1960s
which no longer had sufficient memory and other capabilities to
support the technical requirements of the network. The ultimate
goal, "of our planning," the report explained, "is to provide for
an ARPANET II which will be a virtual network and will make use
of several different networks."
The report described how in the next 3 years the ARPANET
Host Protocols Network Control Program (NCP) would be replaced
with a new DoD Standard Protocol Set. The new protocols were DoD
Standard Transmission Control Protocol (TCP) and the Internet
Protocol (IP). Also, new computers would replace the IMPs and
TIPs that formed the IMP subnetwork administered by BBN. All
Honeywell equipment used for the IMPs was to be replaced with the
BBN C/30 costing $20,000 - $35,000 each (depending on the
configuration) if funding could be obtained, and the software
communication programs would run in a virtual mode.
Mike Muuss was at one of the DARPA sites charged with making
this transition. In a similar way the NAVY had decided to adopt
the VAX 11/750s to replace their PDP 11/40 minicomputers and to
go with Berkeley TCP/IP software that would be distributed with
the 4.2BSD UNIX distribution. (3)
Describing this period, Kirk McKusick, a researcher at the U
of C Berkeley explained that for DARPA, choosing a single
hardware vendor was impractical because of the widely varying
computing needs of the research groups and the undesirability of
depending on a single manufacturer. Thus, "the planners at DARPA
decided that the best solution was to unify at the operating
systems level. After much discussion UNIX was chosen as a
standard because of its proven portability." (4)
A memorandum published by the DoD in March 1982 declared
that the adoption of TCP/IP as the DoD standard host-to-host
protocol was mandatory and would provide for "host-to-host
connectivity across network or subnetwork boundaries."
Military requirements for interoperability, security,
reliability and survability are sufficiently pressing to
have justified the development and adoption of TCP and IP in
the absence of satisfactory nongovernment protocol
standards.(5)
Muuss describes how he had just recovered from an mandated
earlier deadline(6):
After having just about gotten over the 3-month mad dash to
switch to long leader LAST winter, I am not really looking
forwards to rushing into the conversion to TCP/IP, because
of the work involved. However, all up and down the line
within the ranks of DoD management inside both the Army and
the Navy, everybody is backing up the decision to stand firm
with 1-Jan-83 for the conversion. This is putting the heat
on those of us who actually try to make these things happen,
and the pressure is uncomfortable, but we will probably be
able to make it.
This type of edict is not uncommon when working for the DoD;
some manager will stipulate that something will happen
"absolutely" by a certain date. All the technical people
start worrying, and screaming, and carrying on, claiming that
"it can't be done in time". Management usually dumps some
enormous amount of money onto the project, and wait and see.
By this time, all the tech people have lost about 20 lbs
(all brown), and are running around going crazy. Management
usually gets what it wants. Of course, there are the
occasional projects where things got cut just a bit too
tight, and eveything falls down in flames....
I happen to feel that TCP and IP are *good* protocols, and
certainly much better than what we are using now. It seems
something of a miracle that they have been adopted as a
standard; usually standards are things like COBOL that
people go out of their way to avoid. It is merely
unfortunate that the conversion timetable is so optimistic.
There exists AT LEAST one choice of software for UNIX
systems (all machines), T(w)enexes, Multics, and IBMs, so the
majority of the "ordinary" systems will at least be able to
talk, even if not conveniently. How we will get to MACSYMA
on MIT-MC remains a mystery, unless some briliant MIT
student with a lot of time on his hands decides to power-
code a TCP/IP implementation for the ITS machines....
In another post he had made to the UNIX-Wizards mailing
list, Muuss explains that his site the BRL "has a strong
commitment to UNIX, and we encourage discussions about UNIX." He
also expresses concern to maintain contact with those on the list
who were getting access to the list through Usenet, rather than
via the ARPANET.(7)
I am also concerned about the USENET participants. We
really need to be able to interact with them in a better
way, yet UUCP gateways to the ArpaNet are VERBOTEN. The
only umbrella I know of is CSNET...
In response to his query put out on the ARPANET UNIX-Wizards
mailing list, Muusss begins the TCP/IP Digest. He announces the
new mailing list on the UNIX Wizards mailing list. He writes(8):
Announcing the first issue of a new digest which purports to
discuss TCP (Transmission Control Protocol) and IP (Internet
Protocol), the "DoD Standard Networking Protocols for the
Eighties". Submissions will probably center around UNIX
implementations, but ANY networking protocol or
implementation discussions too specific for HUMAN-NETS
is fair game here. Please send submissions to "TCP-IP @
BRL", requests to "TCP-REQUEST @ BRL" or "TCP-IP-REQUEST @ BRL".
This is sort of a spur-of-the-moment thing; it started with
our trying to find out about TCP/IP implementations, and
wound up with dozens of letters asking for a report of what
I found. This list may die stillborn, or it may flourish.
Only time will tell!
Cheers,
-Mike
The first issue of TCP/IP Digest was also sent to the UNIX-
WIZARDS Mailing List and it lists a number of reports on UNIX
implementations of TCP/IP.
Also various questions and offers of help in preparing for
the transition are included. Muuss notes that his site has a
new BBN C/30 computer to function as an IMP. Asking for help from
others with experience with this computer, he writes(9):
Just out of curiosity, I have some questions about our nice
shiney new C/30.
1) How difficult is it to change a DISTANT host interface
to a LOCAL host interface. It it a switch, a board, or a
big deal? Could you estimate the cost of doing this? Our
liason's crystal ball must have been a little cloudy...
2) Just for kicks, is it possible for a C/30 to support
either (a) more than 4 modem lines, and/or (b) run the trunk
lines at more than 50Kb?
3) Is there any provision for more than one trunk to
connect between two C/30's to improve transmission between
them?
We are doing a lot of planning here on networking, and are
strongly considering using TCP/IP. What can you tell me
about (or point me to) how BBN plans to proceed with TCP,
and how will this affect the ArpaNet?
Cheers,
-Mike
Forum for Internetworking Problems
Progress with networking implementations other than
TCP/IP are also included in the Digest. In the first message of
the second issue of the Digest Muuss writes(10):
The scope of the Digest will probably exceed the rather
specific "TCP-IP Digest" title, but that is OK by me. I see
this as a forum for discussing implementation and design
problems relating to large scale networks, and
internetworking....I would hope that discussion will focus
on IP and TCP, because this is where much of the real action
seems to be.
However, in a later issue, a post from GREG at the Navy
Personnel Research and Development Center (NPRDC) reminds Muuss
that the original purpose for the mailing list was to
particularly focus on implementations of TCP/IP to be used with
UNIX. He writes(11):
Now that all the special interest groups have spoken, can we
get back to the original subject? In case you've forgotten,
it was "Unix/ARPAnet TCP problems and solutions." Although
I'm interested in the various problems/possibilities of
using TCP on other operating systems or other ethers, at
a minimum, our mutual interest is getting our machines
running TCP before the deadline. (Probabally this list goes
a little farther than that; to those people, I apologize.
But we are the ones with the deadline fast approaching.)
Maybe we can discuss theoretical issues later, but I am
more interested in the practical issues -- namely, who has
TCP up? How is it connected to the ARPAnet (or even another
ether, if the problems/solutions are similar)? What
problems were encountered? How fast is it? How does it
compare in simplicity/performance/transparancy/completeness/
functionality/limitations/etc. with the other possibilities?
So far, we have heard of two real choices (assuming that
we're not going to have to buy any additional hardware): BBN
and 3COM. Who's got them up? How connected? (I am VDH, so
solutions that don't have a VDH driver are uninteresting.)
Speak up; now's your chance to brag, and you can do the rest
of us a real service.
Muuss responds, maintaining his commitment for a broad focus
for the Digest(12):
Actually, I had hoped that this digest could serve as a
forum for technical discussion of networking for ALL
systems, but clearly the transition to TCP for current
ArpaNet Hosts is the primary motivator I hope that this
list will not restrict itself just to UNIX, though.
Another comment to the list was from Bill Joy who was
working with the Computer Systems Research Group at Berkeley. He
writes(13):
The Computer Systems Research Group at Berkeley is
enhancing the UNIX operating system with DARPA support.
We are improving UNIX memory management facilities, working
on extensions to UNIX to support better inter-process
communication, and incorporating support for both local and
long haul networks. In particular, we expect to try using
the INTERNET protocols on a number of different commercially
available local network interfaces....We have just finished
about three weeks of tuning of the BBN TCP/IP for our 3
Megabaud prototype Ethernet. We had previously brought
TCP/IP up on the Ethernet and were interested in learning
more about the internals of TCP and discovering whether the
protocol would be a bottleneck when running on a local
network. The results we have obtained suggest that this is
not the case.
Steve Bellovin, active in the UNIX community and a Usenet
pioneer who wrote the first shell script for Usenet, writes that
he was working on the extension and development of the UUCP
network. Posting to the TCP/IP digest from Usenet, he writes(14):
I just read RFC754 and RFC799, and it's becoming apparent
that the ARPAnuts are setting standards which we'll have
to adhere to if we're to talk to them. And the whole uucp
addressing mess is getting out of hand -- and that says
nothing of changing topologies....Add in ARPA, CSnet, and
maybe Berknet among the duke machines, and you have a royal
mess. I'm inclined to start a new net newsgroup to discuss
mail, networking, addressing, etc., from a UNIX/uucp point
of view -- say, net.net (fa.tcp-ip appears to be too
specialized, though I'll route a copy of this to the
moderator).
Mark Horton, another UNIX and Usenet pioneer, agreed with
him(16).
Having a newsgroup to discuss nets is different than
discussing mail. I propose net.net and net.mail. I'm not
sure net.net is needed - does fa.tcp-ip subsume it? There
will probably soon be a net.csnet, too.
Mark
Answering Bellovin's concern, Muuss maintained his
commitment to welcome broad discussion of networking issues. Also
he assured Bellovin that he could directly send his comments to
the Digest using UUCP, rather than having to depend on a gateway
to the ARPANET. Muuss wrote(17):
Steve -
While the masthead "TCP-IP Digest" is really rather
specialized, I had intended the Digest as more of a
discussion on IMPLEMENTATION issues of networking (as
opposed to Philosophical discussions as get found in HUMAN-
NETS). The troubles with multiple networks, and the variety
of message formats (for mail), and routing problems in
general are all fair game for the TCP-IP digest. You are
welcome to have this networking discussion in the TCP digest
-- if the volume becomes too great I would be willing to
clone a new digest later on.
BRL polls Duke via UUCP, so messages addressed to
...!duke!bmd70!tcp-ip should make it to the digest (no need
to go through Berkeley). Give it a try. Our RMAIL is smart
enough to prevent accidental gatewaying; sorry.
Cheers,
-Mike
Converting to TCP/IP
A conversion table appearing in the Digest outlines the
schedule for NCP-only hosts to begin and then complete their
conversion to tcp-ip. Included in the milestones listed were the
following(18):
NCP/TCP Transition Plan
MilestonesWhen
--------------
Last NCP Conversion Begins Jan 82
The last NCP-only host begins conversion to TCP.
Mail Relay Service Jan 82
The SMTP (RFC 788) mail service begins to operate and at least one
mail relay host is operational, and at least one special forwarder
is operational to provide NCP-only host to TCP-only host mail
connectivity.
Normal Internet Service Jul 82
Most hosts are TCP-capable and use TCP-based services.
Last NCP Conversion Completed Nov 82
The last NCP-only host completes conversion to TCP.
Full Internet Service Jan 83
All hosts are TCP-capable and use TCP-based services. NCP is
removed from service, relay services end, all services are
TCP-based.
Along with the general discussion of implementation questions
for the cutover, problems regarding the implementation
of TCP/IP on particular machines and operating systems were
raised. One such situation occurred when Mark Crispin, a
computer science researcher at Stanford University explained the
difficulty of meeting the anticipated January 1983 conversion
from NCP to TCP/IP for the "general multi-network TELNET for
TOPS-20."(19) TOPS-20 was one of Digital Equipment Corporation's
operating systems for its DEC-20 computer. Crispin lists several
reasons why his site had found the BBN implementation for TOPS-20
unacceptable.
He proposes rewriting the code and questions how
"ARPA/DCA/whomever intends to enforce the non-use of NCP." He
writes, "The NCP/TCP conversion is of far greater complexity
than conversion from 32-bit to 96-bit leaders which took a few
days in 1978." Crispin notes that "It will be technically
difficult to enforce the non-use of NCP unless the IMPs are
somehow modified to intercept and disallow NCP messages."
Cautioning that, "There are a lot of PDP-10's on the ARPANET
right now, and they aren't about to vanish in a corner," he
observes that "To my knowledge, there is no project at all to
implement TCP on WAITS, ITS, or TOPS-10; and the Tenex/TOPS-20
implementation has significant problems for a site which wants to
implement it. (19a)
In the same issue of the Digest, Jon Postel an ARPANET
pioneer and researcher at the University of Southern California
(USC-ISI) who maintained the RFCs explains the background of the
tcp-ip protocols. Postel writes (20):
In recent years the ARPA Network Research Program has had as
one concern the interconnection of networks. In the course
of this research a family of protocols suitable for an
internetwork environment has emerged. The major internet
protocol documents have been issued as RFCs.
He writes that "the situation has evolved to the point that
it is appropriate for the internet family of protocols to replace
the old ARPANET protocols." Therefore an Internet Protocol
Handbook is being prepared by the Network Information Center
(NIC).
In a later message to the Digest, Crispin explains that he
was not opposed to TCP/IP. He is opposed to the pressure to
implement TCP/IP, not to the protocol. He writes (21):
I'd like to answer a few confusions about my position
regarding the TOPS-20 implementation of TCP available from
BBN. I am not, nor have I ever been, opposed to the TCP
protocol. I was very impressed with the work done at the
DoD Protocol Standards conference a year ago. I've been
urging the managers of the Stanford local network effort to
adopt TCP/IP as the local network protocol for the past two
years now. It is the software that is presently available
for TOPS-20 that I find distasteful.
He cautions that "If the product DEC releases is less than
what we would like, it is because of their rush to meet the
deadline."
He continues, "It's a safe assumption that there is
no way that DEC can possibly have a rewritten TCP implementation
for TOPS-20 out in the field by the deadline date." He
recommends that other "DEC's customers are probably best off
encouraging the current project but being firm in stating that we
must have a rewrite which addresses the performance problems of
BBN's TCP."
Explaining his opposition to the pressure of the January
1983 deadline, Crispin writes:
So far as the comments on how to "help/force people [to]
implement TCP/IP" go:
The whole tone of "forcing" is itself inane. The intent of
my message was to discuss getting things moving towards
solving the software situation, not to create an anti-TCP/IP
lobby. The present TCP/IP software for TOPS-20 is
unpalatable for most sites; if "forced" to implement TCP/IP
on our systems we will probably have to write the software
ourselves. Of course that would keep us from completing the
projects our Network Sponsors are supporting us to do...
-- Mark --
In response, Postel describes how the move to TCP/IP from
NCP could be made mandatory. He describes how the IMPs could
technically be made to reject NCP protocols. Postel writes(22):
There has been some talk of "forcing" the move to TCP by
various administrative and policy measures. There was also
a claim that there was no technical way to force the
abandonment of NCP. It should be pointed out that a quite
simple modification to the IMP program would enable the IMPs
to filter out and discard all NCP traffic.
"As far as I know," he concludes, "there has been no
decision to do this, but you should be aware that it is
technically feasible."
Asking for other opinions on the criticisms of the TOPS-20
TCP/IP implementation, another contributor to the Digest
writes(23):
I have often heard criticisms of TOPS 20 TCP/IP
implementation, but never a defense. Does anyone from BBN
or ARPA care to defend their implementation or do they agree
with the criticisms?
Urging all to respond to the list, Muuss often sent out
notices welcoming contributions. One such notice reads (24):
Nearly a week has passed since the last issue, so I am
publishing the three letters that have arrived in the
interim. Considering the size of the mailing list, I can
hardly immagine that we have heard from everybody who is
working on networking implementations. C'mon! Lets hear
from everybody.
Cheers
Mike
Along with reports on various implementations of TCP/IP,
the TCP/IP Digest included a report about work being done on the
TOPS-20 TCP implementations. The report explains(25):
Most of our efforts during November have been directed at
TOPS-20 TCP/IP performance. In our timing experiments, we are
employing techniques such as PC sampling, control stack
sampling, and packet tracing....
We are also investigating another problem area that could
add significantly to the cpu-utilization of the TCP/IP: use
of 1822 interfaces that transfer all 36 bits of the PDP-10
word to/from the net, necessitating a (possibly) expensive
bit-shuffle in behalf of the 8-bit-oriented TCP. We are
presently performing experiments to determine the precise
cpu-cost of this bit-rearranging, and will publish the
results when available.
Article in ComputerWorld on Cutover
A notice appeared in the December 23, 1981 issue of the
TCP/IP Digest that an article on the TCP/IP cutover had appeared
in the trade magazine ComputerWorld. The notice explains(26):
Mike
The 14 Dec issue of ComputerWorld has an interesting
article on the ARPAnet TCP/IP cutover and it's commercial
impact. It might be of interest to TCP-IP Digest readers.
Raleigh
Also in this issue of the Digest were excerpts from the
ComputerWorld article. Bellovin includes his comments on the
ComputerWorld article in the margin of the copy. The
ComputerWorld article described the planned transition to TCP/IP,
explaining that (27):
Considered the world's first packet network, Arpanet is
expected to become an internet -- a network of networks --
... said an informed source, who revealed the cutover date.
Though the article noted that computer scientists were
confident in the TCP/IP protocols, "An Arpanet crash would
seriously disrupt American research and development in many
fields of science and technology, one expert maintained."
It went on to explain that many TCP/IP developers believed
the ARPANET cutover could be achieved on Jan. 1, 1983,
"but not all of them, [an] Arpanet correspondence revealed."
The ComputerWorld article quoted some of the questions
raised in the Digest about the TOPS-20 TCP/IP Implementation,
explaining that, "This critic wrote, in his Arpanet communique,"
that "the TCP process consumes between 40% and 60% of the CPU.
We simply cannot sacrifice that much of an already-loaded CPU to
implement a network."
The next issue of TCP/IP Digest included discussion about
the dilemma for the mailing list of having articles published
elsewhere about issues raised in the Digest. Muuss writes (28):
Folks -
It looks like somebody on this list is feeding copies of the
TCP/IP Digest to ComputerWorld magazine, which seems
delighted with this newfound source of "inside" information.
While it is my intention that this list receive as broad a
distribution as possible, several tightropes must be
carefully traversed:
He explains why he believes that such press coverage of
ARPANET discussions will cause a problem and then opens the issue
for further discussion, writing
This digest was intended as an open forum? Is a direct
pipeline to the outside world too open? I solicit
discussion on this matter. Maybe we can reach a consensus?
Happy New Year!
-Mike Muuss
FA.digest-people Discussion
A discussion describing this issue developed on FA.digest-
people available as an ARPANET mailing list and on Usenet. "My
temporary solution to this issue," Muuss proposed, "is to add the
following notice to the Masthead:
TCP/IP Digest Thursday, 8 Oct 1981 Volume 1 : Issue 1
----------------------------------------------------------------------
LIMITED DISTRIBUTION
For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------
At least this ensures that anybody who gets fed a copy knows that
it is not supposed to be shouted to the treetops. Comments (29)?
A post from Christopher C Stacy at MIT disagreed with such a
publication identifier. Stacy wrote (30):
I think that the explicit banner on the masthead of the
Digest is a bad idea, because this will cause many people to
think that if such a banner is NOT present (ie., on any
other Digests or on future TCP Digests) that it is alright
to redistribute the material.
Others disagreed. Another article in the Digest
explained (31):
I don't agree. If SOMEONE uses the banner, then at least
those people who see it may stop and think about the issue,
and other digests may choose to use such a banner as well.
If NO ONE uses it, then I think we are more likely to
perpetuate the kinds of problems CStacy mentioned earlier in
his note. I think elucidating by example is a fine thing,
and one usually doesn't wait for others to be consistent
with one's good idea.
The problem of ensuring that ARPANET mail is not distributed
outside of the network community," wrote C Stacy, "is a
perpetual one because many of the users of the network are
unaware of the restrictions on the material."(32)
He pointed to an incident that had occurred when MIT had to
fight for its continued existence on the ARPANET after an article
in the journal Datamation about the WINE-TASTERS mailing list
appeared. He also cautioned of the possible liability problems
when evaluating and discussing various commercial products, as
with the INFO-TERMS mailing list which evaluated terminals.
He quoted a Defense Communications Agency (DCA) memo
restricting who could ftp files from ARPANET sites. "But laying
down the law," he wrote, "is a fairly useless way of solving this
sort of problem. The problem is one of awareness, cooperation and
trust. Only if people understand and care, will they take steps
to protect a fragile institution like the ARPANET," he writes.
Another post noted that the mailing list digests "do not
exist as authorized publications." He felt that they
should be considered "internal communications between research
project members authorized to use the net. (33)"
A message asking about the implications of the Ellsberg case to
this issue by Mike Muuse was answered by Paul Karger. Karger
writes (34):
While putting a restricted distrution statement on a digest
may be a psychological limitation on distribution, there are
a couple of problems. First, since ARPA and DCA are part of
the DoD, there are specific regulations on what may or may
not be marked as FOR OFFICIAL USE ONLY.
The regulations are in part designed to not let people
invent other kinds of markings. This dates back to the
Ellsberg case and the desire to limit the ability of
government people to conceal information from the "public"
(whoever that is).
Karger noted that his familiarity with the regulations was
a little stale, but cautioned, "I would be very careful about
developing new ways to restrict distribution of government
information."
Horton, however, pointed out that Usenet was a public
bulletin board system and thus that posts to it were considered
to be public. He writes (35):
I just want to make sure the people on this list are aware
that each TCP digest is fed into USENET on newsgroup fa.tcp-
ip. This is sent to (currently) about 120 machines across
the US and Canada. (For those who don't know about USENET,
it's a distributed bulletin board system.) USENET
specifically has a policy that anything posted to net and fa
newsgroups is public information that can be redistributed
to whoever wants it. The point is that if you have anything
you consider secret, it probably shouldn't be mailed to the
list.
While I am under the impression that this policy is
consistent with the intent of the TCP-IP digest, if I'm
wrong, it may be necessary to remove the USENET feed from
the mailing list.
Horton continues:
It is possible that ComputerWorld got their information from
USENET, but from the wording of the article, they seem to
have gotten it from somewhere on the Arpanet.
It is easy to confuse private mail and public mailing
lists/newsgroups, and it seems clear that the quote from the
digest was written in a "I'm talking privately to friends"
frame of mind. Clearly he didn't intend his words to be
printed in ComputerWorld. But it is important to remember
that anything which is mass-mailed is effectively published.
Through this discussion, concerns for limiting access to
ARPANET mailing list discussions were raised, and answered. The
limitations that the current state of relevant law would allow US
government officials to impose on access to ARPANET mailing list
discussions were considered.
This discussion demonstrates how the more limited
circulation of ARPANET mailing lists was challenged not only by
the prohibitions against government secrecy, but also by the
connection with Usenet, as it represented making them available
to broader participation and to a broader and more open public
forum.
TCP/IP Digest adds Banner
Despite the many concerns raised in the Digest-people
discussion, the following issue of the TCP/IP Digest had a new banner
added to the issue.
----------------------------------------------------------------------
LIMITED DISTRIBUTION
For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------
Explaining the reason for the banner, Muuss writes (36):
Folks -
You probably noticed the new banner on the front of this
issue of the digest. While a copyright would be even
better, the Government can not hold a copyright, and the
mechanics of having somebody else copyright the Digest were
just too much. So, the notice on the front. The intention
here is to warn readers of the digest that the material
contained herein is not for publication or other forms of
public distribution. At least this will ensure that if
copies get to the outside world (and they undoubtably will),
at least they will think twice before printing it. Authors
of letters to the digest who want to make a public statement
may mark their submissions accordingly. If this seems
unnecessary, we can always be more informal later.
Also, Muuss noted that though the previous Digest issue had
carried a copy of InterNet Monthly that had been submitted to
him, he would "try and filter submissions from [such] unexpected
sources" like that. He explained "The intentions were all
good, but things didn't work out so well. Politics. Alas."
He then noted that though the next issue or two might
contain discussion of issues raised by the ComputerWorld article,
he hoped soon to get back to the focus of the Digest. He writes:
In summary, then, I hope to wrap up discussion of the
administrative side of the digest in the next issue or two,
and resume our devoted discussion of Networking!
Also he asked that those receiving the Digest at Usenet
sites contact him. He writes:
I am interested in hearing from each USENET site which is
presently receiving the digest, to try and judge the size of
the readership. (Also from any other "multi-level indirect"
network which may be distributing the digest). Let's start
hearing more about networking concerns from the non-ArpaNet
sites, too.
Press Packet Proposed
Along with placing a notice on the header of the Digest, the
proposal was made to have an official press package to distribute
about TCP/IP. Muuss explains (36a):
Einar Stefferud <Stef@KA> and Vint Cerf <Cerf@usc-isi> have
come up with the idea of putting together a TCP/IP "Press
Package" which we could feed to Datamation and IBM and
everybody else who ought to hear about TCP/IP, but maybe
hasn't. This would be mostly a cut-and-paste job done to
some of the existing RFCs and IENs, along with descriptive
text from previous digests, and new contributions.
Muuss asked that those who wanted their Digest submissions
to be included in the press pack, indicate that to him. "Only
clearly marked letters will be added to the press package file;
all others will go to the digest only," he notes.
TOPS-20 TCP/IP Implementaton
In the November 23, 1982 digest, less than two months before
the cutover day, a description by Joel Golderger@USC-ISIB of the
efforts to locate the problems with the TOPS-20 TCP/IP
implementation appears in the digest. Goldberger explains (37):
I can tell you what the situation is regarding IP/TCP
implementations on most DEC equipment. There are basically
four operating systems that people run on DEC 10/20's and
two operating systems that are run on Vaxes.
On the 10/20's people are running:
TOPS-10
TENEX
TOPS-20
and ITS (The MIT Incompatible Timesharing System)
BBN has had an implementation of IP/TCP for TENEX and TOPS-
20 for some time and that is what we are running. Very few
other sites were willing to run this software though.
He described how DEC had proposed a better user-interface
for the TOPS-20 sites which "most of the TOPS-20 sites decided to
wait for." Also, he notes that although the original date the
software was expected was July, the date was delayed and it was
now promised for December 1. However, this would make it
difficult for the code to be debugged in time for the cutover. He
explains:
Obviously once the code is delivered there will be some lag
before the support software gets written and debugged, and I
seriously doubt that all of that can be accomplished in the
one month before the switchover.
Other TCP/IP Implementations
Goldberger also notes that the BBN implementation of the
IP/TCP was being used by most of the TENEX sites on the ARPANET.
And that work was needed to get support programs to run under
TENEX. This work was being done at the NIC. Also, he notes that
Ken Harrenstein had been hired by MIT to implement IP/TCP on the
ITS machines (MIT AI/DM/ML/MC). However, Goldberger explains that
he knows of no other TCP/IP implementation for TOPS-10 (or WAITS)
that was either already available or in development.
For VAXes, he reports that people either run VMS or Berkeley
UNIX. For VMS there was a commercial product in binary with all
the usual servers and user programs (FTP/TELNET/SMTP) and a
library for establishing and controlling IP and TCP corrections.
His site at UCS-ISI had had trouble using the program, but
reported the problems and would be testing the new version.
For TCP/IP for Berkeley UNIX, there were two choices, one from
BBN and another from the University of California Berkeley. His
site had found both of them stable.
Preparing for the TCP/IP Cutover
In preparing for the cutover, the November 29, 1982 issue of
the TCP/IP Digest reports that ARPA held a 24-hour TCP-only test
on November 15, 1982. The test results reported were that 62% of
the packets that had been passed on the previous Monday, were
transported during the test. (Nov. 8, 15,283,672 packets, Nov.
15, 9,466,256 packets). The test provided a list of packets
passed on 97 nodes on the ARPANET.(38)
The December 17, 1982 issue of the Digest reports the
results of the TCP-only tests on December 13 and 14. 89% of the
packets passed when compared with the packets passed the same two
weekdays the previous week. (Dec. 13 and 14, 28,446,350 packets,
Dec 6 and 7, 31,802,350 packets) (39)
The test results show the sites, but not the computers or
operating systems that were used by the hosts at those sites. A
test done a year later, on Oct 4, 1983 lists 190 hosts on the
ARPANET and reports how effective was their use of TCP/IP. This
report shows the varied computers and operating systems using the
TCP/IP protocol to communicate with each other. Several tests
were carried out, but hosts which failed the simplest test and
failed to communicate within the ARPANET using TCP/IP scored a 4.
Scores 1-3 showed varying abilities to communicate both within
the ARPANET and through gateways.(40) (See Appendix A for chart)
After the Cutover
The first issue of the TCP/IP Digest which appeared after
the TCP Jan 1 1983 cutover was vol 2 Issue 1. It is dated
Saturday February 26, 1983. Muuss reports(41):
While BRL's hosts started passing TCP traffic about 6-Jan,
we were not able to overcome all our mail difficulties until
just recently, so there have been no TCP Digest
transmissions since 17-Dec-82. At this time, it should be
"business as normal" once again.
Crispin describes how the problems he had drawn attention to
were impacted by the cutover. He explains (41a):
DEC largely ignored the ARPANET at that time. There were a
few members of the TOPS-20 development team at DEC who
talked with us, but for the most part DEC was a separate
world.
DEC did not take the problem seriously until the fall of
1982. Pretty much everybody in the TOPS-20 world worked on
TCP, and nothing else, between then and the end of the year.
I wrote the Telnet client and the SMTP client and server for
TOPS-20. There were other Telnet and mailer programs for
TOPS-20 prior to that time, but afterwards mine had more or
less a monopoly.
In terms of other PDP-10 operating systems: some dedicated
people implemented TCP on TOPS-10, and that implementation
presently was ported to WAITS as well. TCP was also
implemented for ITS eventually. TOPS-20 had pretty much
replaced TENEX by this time, and the TCP transition was the
final blow. Most TENEX systems were shut down.
DEC got the file system interfaced working in time. Barely.
I helped debug it, and wrote some portions of it, but the
actual author was Kevin Paetzold at DEC.
The cutover happened on January 1, 1983 as scheduled.
As I speculated, DCA enforced the switchover from NCP to TCP
by modifying the IMPs (the equivalent of routers) to
disallow NCP messages. For about 6 months afterward the
changeover there was "reclama" which re-allowed NCP messages
for certain sites -- but they could only talk NCP to other
sites with "reclama".
In May of 1983, DEC cancelled the PDP-10 hardware. This was
a devastating blow. It shifted the focus of subsequent
software work from "develop new and cool things" to "keep it
working as long as possible." Consequently, the effort for
"new and cool things" shifted to UNIX.
The performance problems were never fixed in TOPS-20 TCP.
Nor were various bugs that caused periodic system crashes.
It probably would have been fixed, but as I said, DEC
cancelled the PDP-10 computer 5 months after the TCP
transition.
The TOPS-20 TCP never was a very good performer. There was
some effort to retrofit some of the lessons learned from TCP
on UNIX, but it was never as thorough as it could be. PDP-
10 systems started being shut down in 1985, and this
accellerated throughout the 1980s. A couple of holdouts
existed into the 1990s, but most of those are gone as well.
One aborted project due to the PDP-10 cancellation was a
rewrite of TOPS-20 TCP.
Inevitable. Nobody would sink the funds for a TOPS-20 TCP
rewrite given that the machine had been killed.
The network changed forever as a result of the cutover.
Several well-known systems died as a result. However, most
systems made the transition; and by the summer of 1983 the
transition was largely spoken of in the past tense. There
were, at that time, only a couple of hundred systems in
total on the network.
Broadening the Focus of the Digest
After the Jan 1983 cutover, Muuss went on to broaden the
topic of the TCP/IP Digest to "Inter-Net Networking -- Design and
Implementation Issues." A new concern became the need for
updating the ARPANET host tables and the Internet gateway entries.
Explaining the need to get updated versions of the ARPAnet host
tables, David Roode at SRI-NIC writes (42):
With the cutover to TCP/IP on January 1, many more hosts now
have Internet capability. Besides the entries always
present in the ARPAnet host table, you now will have use for
Internet Gateway entries. These are included as part of the
standardized DoD Internet Host Table originally described in
RFC 810, dated 1 March 1982.
He explains that the NIC Hostnames Server (RFC 811) would
provide updated copies of the complete table. He also describes
how to TCP telnet to the NIC on the Hostname Server port to
retrieve the copies.
Muuss adds (43):
[ Hosts are strongly encouraged to reload their host tables
frequently. Either when booting the system, or at certain
times during the week seems to be the best approach. -Mike ]
Preparing for the ARPANET-MILNET Split
Subsequent issues of the TCP/IP Digest began to take up the
planned split between the ARPANET and MILNET into two separate
networks to create an Internet. The split would allow the MILNET
to be devoted to the operational activities of the Department of
Defense. And those on the ARPANET would be able to continue to
pursue network research activities. Gateways between the two
networks would provide internetworking communication.
The Dec 3 1982 issue of the Digest carried a letter from
Heidi Heinden the DDN Program manager. It announced(44):
The existing ARPANET will be split into a network for
operational traffic (MILNET) and an experimental network
which will retain the name ARPANET.
MILNET was to have the Class A network number 26 and the
ARPANET would retain the Class A network number 10. The first stage
of the split was to take place around July 1983 utilizing a
feature of the IMPs which made it possible to create a logical
network and logically partition those on one network from having
access to those on another network. The second stage of the
split, to "involve an actual reconversion of backbone circuits,
making the separation of the networks a physical partioning," was
targetted for Jan 1984. At that time all the MILNET IMPs would
have to be relocated to "restricted locations."
In an article titled "My Own Personal Opinion", Muuss
explains that the "InterNet concept makes this split an easily
accomplished thing thanks to the InterNet gateways. However, the
`special' gateway is a thing which tends to dimish the value of
the split by only allowing mail traffic across it. I invite the
readers of the digest to discuss this issue."
Explaining his concerns about the restriction of traffic
between the two networks after the split, Muuss writes: "Seems
like many of the military people are scared of having University
students `at large' on their network. There are some serious
loss-of-service issues which properly concern users of MILNET.
Discussion?"
In the June 21, 1983 Digest (Vol 2 Issue 10), further
details of the ARPANET/MILNET planned split were provided in an
excerpt from the DDN Newsletter 27. The excerpt explained(45):
The existing ARPANET will soon be split into two
separate networks - the experimental ARPANET and the
operational MILNET. Hosts on the two networks will
intercommunicate via mail bridges, using the internet
gateway mechanisms to pass mail traffic between hosts on
the two networks. The mail bridges will, on a controlled
basis, provide full internet gateway services for MILNET
hosts that request it.
The excerpt went on to announce how the logical split which
would take place on October 4, 1983 would transform the ARPANET
into an Internet. The excerpt explained:
Because it takes a large amount of time and effort to
physically split a network in a coherent manner, the
ARPANET will initially, on 4 October 1983, be
logically partitioned by the use of existing mechanisms
in the IMPs to enforce segregation of hosts and
TACs into separate communities of interest. Each
community of interest (COI) becomes a virtual network,
i.e., hosts (including TACS) in the same community can
fully interoperate as is currently the case, while hosts
in different communities cannot directly intercommunicate.
This, in effect, transforms the ARPANET into an Internet
in which the MILNET will assume a new class A network
number, network 26, while the ARPANET remains network 10.
The memo went on to explain that only hosts that had fully
working TCP/IP implementations (including ICMP, the host-gateway
protocol) would continue to have full service as only they would
be able to send (or receive) mail traffic through the mail
bridges to the hosts in the other networks. Thus the memo noted
how important it was for hosts to convert from NCP to TCP for
those who hadn't yet completed the conversion.
Also the memo described the physical split that would occur.
The goal was to complete the split was in the first quarter of
1984.
Writing in the Oct 11, 1983 issue of the Digest (Vol 2 Issue
18), Muuss describes the previous week and the initiation of the
MILNET split. Reporting on some of the problems, Muuss writes(46):
I write this letter almost a full week from the initiation
of the MILNET split, after having spent yet another night
riding shotgun on the mail queues, trying to make sure that
we re-establish connectivity before our 11-day "failed mail"
timer goes off. Most of the effort lies in running endless
series of tests to determine which hosts STILL have non-
functional routing tables between them and us.
"Sadly," he noted, "this digest will only be received by
people who are doing things right, so I have to resort to other
techniques for getting routing tables updated. Perhaps if we all
apply enough gentle persuasion, things can get tidied up in a
hurry."
"The problem," he explained, "you see, is that we at BRL
have really, truly *believed* in the viability of the InterNet
concept. Of course, we still do," he continued, "although we
certainly have felt rather lonely in our little corner of the
InterNet here, only being able to communicate with a `select
few'."
He describes how one of their machines was still connected
to the backbone, but to the MILNET backbone. All their other
machines were safely tucked away behind a local gateway, so that
they could develop "our own solutions to our communications
difficulties. And, therein lies the rub."
He gives credit to the PRIME gateway crew at BBN for their
work. "Pop a packet for BRLNET off to a BBN Prime gateway, and
things work perfectly (except for the MILARPA IMP blowing up
unexpectedly, but that's another story)."
He explains that the problem occurred even though only 5
Gateways had moved from the ARPANET to MILNET, and the BRL-
GATEWAY was probably one of the more noticable ones. Many
sites had remembered to diligently update their host tables, but
"not so many sites remembered to (usually manually) extract the
current network topology from the GATEWAY section of the NIC
tables and to reflect those changes in their routing tables."
Reporting on some of the cries of distress he heard because
of the problems with the split, he writes:
"Where did our UNIX-Wizards mail go? ...."
"We heard the cries, and noticed the megabytes of
accumulation in our mail queues."
Muuss reports that his group spent the week:
Phoning and writing to host administrators, trying to help
them figure out how to update their routing tables (a
startling number needed a good deal of help to discover what
to change). Running tests: Can we hit them from BRLNET2?
BRLNET? A MILNET host? A MILNET TAC? How about an ARPA
host? Humbug.
And he adds that they observed their packet counts were down
by more than 50%.
Muuss concludes:
TCP and IP work. We know that, it's a fact. But, there seems to
be an almost totally manual mechanism involved when it comes
time to "program" the IP routings. Disappointing. (I'd like
to note in passing that, except for loading new host tables
into all our hosts, the only thing Ron had to do was pop a
new routing table into our Gateway. Our part was easy). If
somebody ever 'nukes the InterNet until it glows, nothing
will work. Not unless we all take a serious look at
improving the IP routing mechanisms that exist in each and
every host.
And he goes on to propose:
I'd like to see the next few issues of the digest
concentrate on how the InterNet as an integrated
communications system should "become aware" of changes in
the underlying communications configuration, so that in the
future the configuration of the network can undergo rapid
changes (planned and unplanned) and still continue
operating. Think of the flexability this affords: responding
to administrative edicts. Government foolishness. Natural
disaster. And yes, even *war*.
Recognizing the Integrity of the Infrastructure
An article in a later issue of the Digest by Muuss is titled
"On the Undesirability of "Mail Bridges" as a Security Measure."
He writes(47):
Seeing the last few messages brings back to mind the ugly
prospect looming ever larger: that we will not have ONE
InterNet, and we will not have TWO InterNets, but we will in
fact have One-and-a-Half InterNets, stuck together with
mail-only "bridges" (ie Data Fences), which will prevent the
ARPA EXPNET and the MILNET communities from exchanging data
with each other. In my nightmares, I see things
degenerating to much the same level of service as where the
InterNet touches on "foreign" (non-TCP) networks today.
Unable to retrieve files, important data will be shipped as
mail, and will suffer the indelicacies of having headers and
trailers slapped on it, spaces and dots and tabs munged
with, etc. Reprehensible kludges like UUENCODE/UUDECODE
will have to become commonplace again. It's bad enough
having to mail files to USENET, CSNET, etc; but between the
EXPNET and MILNET? Come on!
Continuing, he explains:
I'm entirely in favor of separating the backbones of the two
networks; in addition to giving DCA a much greater degree of
control over engineering the MILNET portion, it also permits
the ARPANET portion to do horrible things to their IMPs, to
play partitioning experiments, and generally have enough of
a reprieve from operational considerations to be able to do
meaningful experiments again. All this is good.
He also describes how it was good that the split happened as
it ended the use of NCP:
Forcing the split was a good thing, too. It polished off
NCP once-and-for-all, and it demonstrated that the IP
protocol really *does* operate as claimed. Funneling all IP
communications through ``n'' gateways (n=5 at present) is
good, too. Gets people thinking about multi-path routing
algorithms, and provides a good "safety valve", just in case
there should ever be valid military reasons for separating
the networks.
He describes other benefits of having made the change.
Then he explains his concern with what is happening. He writes:
Hiding ourselves behind mail-only bridges is only asking for
trouble, later on. Being on the MILNET isn't significantly
different from offering commercial (or AUTOVON or FTS) dial-
up service, in terms of the threat posed by an outsider
trying to get in. Now the CLASSIFIED community, that's
different. But there's none of that sort of information on
the MILNET, right?
So, here is a loud plea from one (military) researcher who
says "Don't cut the lines of communication!" An emphatic
YES to security. Do it by the regulations! But don't
depend on partial network connectivity as a security measure
-- it won't help, and it sure can hurt. (Ouch!).
Your (Civil) Servant,
-Mike Muuss
Leader, Advanced Computer Systems Team
U. S. Army Ballistic Research Laboratory
Conclusion
Vol 2 Issue 18 with this plea by Muuss is the last issue of
TCP/IP Digest that this researcher has been able to locate. But
the concerns it raises have great importance even today, 15
years later. This last message by Muuss raises the importance of
maintaining the integrity and constructive development of the
Internet. The U.S. government is currently planning to transfer
the Domain Name System routing tables and directory functions
from the control and oversight of the U.S. government into
an association controlled by private corporate interests. The
difficulties encountered by Muuss in transferring his site from
the ARPANET to MILNET show how important the proper functioning
of the routing tables and directory structure is to the integrity
of the Internet. Also Muuss's final plea to keep connectivity
flowing between those working for the U.S. government and the
rest of the world, is an important precaution to the U.S.
government, and the governments of other countries around the
world as well, to increase the access of government employees to
those on the public side of the Internet. Also, the important
role played by Muuss in this mailing list and the subsequent
accomplishment of a large scale engineering achievement,
demonstrates that communication in general, and communication
between government employees and citizens, in particular, is
crucial to the successful achievement of social and engineering
goals.
But most importantly, Muuss 's plea emphasizes that there is
a crucial role for open and functioning lines of communication.
They make possible engineering achievements involving a large
number of people, as did the conversion from NCP to TCP/IP and
later the split between the ARPANET and MILNET to create two
separate networks linked as part of the Internet. It is important
that such communication in successful projects be the subject of
research and study, just as the technological achievements made
possible should be the focus of study.
An even more significant reason for the need for research
into the early days of networking and into the vision that guided
the development of the Internet, however, is that the early
vision of an Internet connecting different networks, networks
with different purposes such as the research orientation of the
early ARPANET (EXPNET) and the operational orientation of MILNET,
presents an important model for the development of the Internet.
This early model recognized the integrity of the different
participating networks, not allowing either one to overcome the
other, but providing a way for the different networks to maintain
communication while pursuing their own purposes. The requirement
on both networks was that they recognize and support the
integrity of the Internet as a means of communication. This would
suggest that in the future there could be RESEARCHNETs,
SCHOOLNETs, different CITYNETS, MILNETS, COMMERCIALNETS etc and
that no one net would dominate or determine what happens on all
the other nets. Instead all would recognize the importance of
maintaining internetworking communication and of protecting the
integrity of that communication by guarding the accuracy and
integrity of crucial components, like the routing tables. Thus
research into the history and development of the Internet
provides a means of understanding the vision and practice that
has given birth to the current Internet, and the principles to
consider when planning and implementing future developments.
Footnotes
(I still have some work to do on the footnotes part of the paper-rh)
(1a) The issues located included Vol. 1 Issue 1, dated October
8, 1981 to Vol 2 Issue 18 dated October 11, 1983.
(1) >From mike.bmd70@BRL Fri Oct 2 00:26:05 1981
fa.unix-wizards utzoo!decvax!ucbvax!unix-wizards
Fri Oct 2 00:29:54 1981
TCP/IP for UNIX
(2) (see f/n 39)
(3) From: ron at NOSC-CC (Ronald L. Broersma)
Subject: NAVY no longer attempting plan #1
To: tcp-ip at brl
19-Apr-82 21:29:56-PST,8146;000000000001
Mail-from: ARPANET host BRL rcvd at 19-Apr-82 2129-PST
Sender: Mike Muuss <TCP-IP@Brl>
From: TCP-IP at Brl
To: TCP-IP at Brl
Date: 19 Apr 1982
Subject: TCP-IP Digest, Vol 1 #19
Via: Brl-Bmd; 19 Apr 82 19:43-EST
(4) Funding was provided to the University of California
Berkeley to develop tcp/ip that for BSD, the version of
UNIX that they were working. McKusick, p. 3
(5)From: Michael Muuss <mike@brl-bmd>
To: Tcp-ip at Brl
Subject: TCP/IP made Mandatory -- IEN 207
[ This copy of IEN207 is included here for those who were not aware of where
the mandate to use TCP/IP for all DoD networking. -Mike]
(6) -Mike
digest.033
Aucbvax.5779
fa.digest-p
utcsrgv!utzoo!decvax!ucbvax!digest-people
Thu Jan 14 04:50:57 1982
To TCP or not to TCP?
>From mike@BRL Thu Jan 14 01:26:47 1982
(7) Usenet was a UNIX based network that was transported via
UUCP to a growing number of UNIX systems.
Aucbvax.2946
fa.unix-wizards
utzoo!decvax!ucbvax!unix-wizards
Fri Sep 4 15:04:28 1981
Re: PROPER FORUM
>From mike.bmd70@BRL Fri Sep 4 14:55:10 1981
(8) ***Aucbvax.4473
fa.unix-wizards
utzoo!decvax!ucbvax!unix-wizards
Thu Oct 15 23:23:01 1981
TCP/IP Digest, V1 #1
>From mike@brl Thu Oct 15 20:38:39 1981
(9) TCP/IP vol 1 Issue 1
(10) 14-Oct-81 02:17:54-PDT,9234;000000000001
Mail-from: ARPANET host BRL rcvd at 14-Oct-81 0217-PDT
Date: 14 Oct 81 2:47:30-EDT (Wed)
From: Mike Muuss <tcp-ip@brl>
To: tcp-ip at Brl
Subject: TCP-IP Digest, Vol 1 #2
(11) Aucbvax.5236
fa.tcp-ip
utzoo!decvax!ucbvax!tcp-ip
Wed Nov 18 05:50:19 1981
TCP-IP Digest, Vol 1 #6
>From tcp-ip@brl Wed Nov 18 05:33:31 1981
(12) From: ARPAVAX .wnj at Berkeley
Subject: tcp-ip digest contribution
Aucbvax.5236
fa.tcp-ip
utzoo!decvax!ucbvax!tcp-ip
Wed Nov 18 05:50:19 1981
TCP-IP Digest, Vol 1 #6
>From tcp-ip@brl Wed Nov 18 05:33:31 1981
(13)From: chico!duke!unc!smb at Berkeley
In-real-life: Steven M. Bellovin
Subject: Re: systems news articles
From duke!dbl Wed Nov 18 14:01:41 1981
Date-Sent: Wed Nov 18 13:57:35 1981
To: unc!smb
Subject: systems news articles
Aucbvax.5333
fa.tcp-ip
utzoo!decvax!ucbvax!tcp-ip
Sun Nov 29 11:19:56 1981
TCP-IP Digest, Vol 1 #7
>From tcp-ip@brl Sun Nov 29 10:12:00 1981
(14) footnote needed
(15) footnote needed
(16) Date: 19 Nov 1981 07:40:13-PST
From: cbosgd!mark at Berkeley
Subject: Re: systems news articles
(17) footnote needed
(18) Michael Muuss <mike@brl>
TCP-IP Conversion Timetable & Documents, from RFC801
RFC 801 November 1981
Aucbvax.5448
fa.tcp-ip
utzoo!decvax!ucbvax!tcp-ip
Fri Dec 11 18:33:30 1981
TCP-IP Digest, Vol 1 #8
>From tcp-ip@brl Fri Dec 11 18:15:56 1981
(19) Aucbvax.4552
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: TOPS-20 TCP Implementation
fa.tcp-ip
utzoo!decvax!ucbvax!tcp-ip
Mon Oct 19 22:25:42 1981
TCP-IP Digest, Vol 1 #3
>From tcp-ip@brl Mon Oct 19 21:38:29 1981
(19a) Crispin explains that "some people feel that a `network
front end' is the right long-term solution for this problem," he
warns "we can't just go and build a network front end in 14
months."
(20) From: POSTEL at USC-ISIF
Subject: Protocol Documents
To: TCP-IP-Digest at BRL
Aucbvax.4552
fa.tcp-ip
utzoo!decvax!ucbvax!tcp-ip
Mon Oct 19 22:25:42 1981
TCP-IP Digest, Vol 1 #3
>From tcp-ip@brl Mon Oct 19 21:38:29 1981
(21) Date: 26 Oct 1981 0013-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: Re: TCP-IP Digest, Vol 1 #4
Aucbvax.4889
fa.tcp-ip
utzoo!decvax!ucbvax!tcp-ip
Sun Nov 1 22:16:27 1981
TCP-IP Digest, Vol 1 #5
>From tcp-ip@brl Sun Nov 1 21:56:45 1981
(22) From: POSTEL at USC-ISIF
Subject: Disabling NCPs
Aucbvax.5236
fa.tcp-ip
utzoo!decvax!ucbvax!tcp-ip
Wed Nov 18 05:50:19 1981
TCP-IP Digest, Vol 1 #6
>From tcp-ip@brl Wed Nov 18 05:33:31 1981
(23) Subject: Re: TOPS 20 TCP/IP
From: mike at RAND-UNIX
Aucbvax.5236
fa.tcp-ip
utzoo!decvax!ucbvax!tcp-ip
Wed Nov 18 05:50:19 1981
TCP-IP Digest, Vol 1 #6
>From tcp-ip@brl Wed Nov 18 05:33:31 1981
(24) From: Mike Muuss
Reply-to: tcp-ip@brl
Subject: More Contributions?
Wed Nov 18 05:50:19 1981
TCP-IP Digest, Vol 1 #6
>From tcp-ip@brl Wed Nov 18 05:33:31 1981
(25) Charles Lynn
ESTINE at USC-ISIF
November Internet Report, BBN INFORMATION SCIENCES DIVISION
Aucbvax.5534
fa.tcp-ip
utzoo!decvax!ucbvax!tcp-ip
Wed Dec 23 22:40:01 1981
TCP-IP Digest, Vol 1 #9
>From tcp-ip@brl Wed Dec 23 22:21:05 1981
(26) From: Raleigh F Romine <romine@SRC-Unix>
Subject: ComputerWorld TCP Article
(27)From: chico!duke!unc!grumpy.smb at Berkeley
Subject: Computerworld on the TCP/IP cutover
Aucbvax.5690
fa.tcp-ip
utzoo!decvax!ucbvax!tcp-ip
Tue Jan 5 03:01:41 1982
TCP-IP Digest, Vol 1 #10
>From tcp-ip@brl Tue Jan 5 02:51:29 1982
(28) Aucbvax.5690
fa.tcp-ip
utzoo!decvax!ucbvax!tcp-ip
Tue Jan 5 03:01:41 1982
TCP-IP Digest, Vol 1 #10
>From tcp-ip@brl Tue Jan 5 02:51:29 1982
Also Muuss explains:
Networking plays a vital part in the Mission of the
Ballistic Research Laboratory (BRL), which fully supports
the distribution of the TCP/IP Digest. However, the ArpaNet
is intended for U.S. Government business, and is not
supposed to compete with commercial packet networks. This
has a rather limiting effect on the group of people who can
freely use the ArpaNet.
More importantly, though, is a question of content. If it
becomes known that contributions to the TCP/IP Digest will
appear in ComputerWorld, possibly verbatim, or perhaps cast
in the wrong light, then I suspect that there will be a
marked decrease in the quantity of information that is
offered. Few of us expect our net mail to wind up published
in the commercial press, and only the brave will knowingly
open themselves up to this kind of direct, external
exposure. And the cost? Those readers who desperately need
the information on what is happening may find their
information sources again reduced to RFC's and official
notices, carefully worded for public scrutiny.
(29) Aucbvax.5744
fa.digest-p
utcsrgv!utzoo!decvax!ucbvax!digest-people
Tue Jan 12 18:54:24 1982
TCP-IP Digest Frolic
>From tcp-ip@brl Tue Jan 12 18:51:37 1982
-Mike
(30) Date: 14 January 1982 00:48-EST
From: Christopher C. Stacy <CStacy at MIT-AI>
Subject: For Research Use Only --- Not for Public Distribution
To: Tcp-IP at BRL, Mike at BRL
cc: DIGEST-PEOPLE at MIT-AI
(31) Aucbvax.5776 (check)
fa.digest-p
utcsrgv!utzoo!decvax!ucbvax!digest-people
Thu Jan 14 04:01:50 1982
For Research Use Only etc.
>From JPG@MIT-MC Thu Jan 14 00:03:34 1982
(32) Stacy, Ibid (digest.035)
(33) (Digest-people.043)
(34) (digest.0044)
(35)From: cbosgd!mark at Berkeley
To: ucbvax!tcp-ip@Berkeley
Subject: TCP digest as a public forum
(36) From: Mike Muuss <tcp-ip@brl>
Subject: Administrivia
TCP-IP@BRL
(36a) From: Mike Muuss <Mike@BRL>
Subject: TCP/IP "Press Package"
------------------------------
Aucbvax.6079
fa.tcp-ip
utcsrgv!utzoo!decvax!ucbvax!tcp-ip
Fri Feb 5 02:12:22 1982
TCP-IP Digest, Vol 1 #14
>From TCP-IP@BRL Fri Feb 5 00:32:33 1982
(37)Date: 23 Nov 1982 1653-PST
Subject: DEC equipment and IP/TCP
From: Joel Goldberger <JGoldberger@USC-ISIB>
To: TCP-IP@BRL
------------------------------
21-Apr-83 09:37:50-PST,11733;000000000001
Return-path: <tcp-ip@Brl-Vgr.ARPA>
Mail-From: SMTP created at 20-Apr-83 19:11:48
Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 20 Apr 83 19:12:05 PST
Received: From Brl-Vgr.ARPA by BRL-VGR via smtp; 20 Apr 83 6:56 EST
Sender: Mike Muuss <TCP-IP@Brl.ARPA>
From: TCP-IP@Brl.ARPA
To: TCP-IP@Brl.ARPA
Date: 20 Apr 1983 00:00 EST
Subject: TCP-IP Digest, Vol 2 #4
(38)Subject: TCP-IP Digest, Vol 1 #26
Via: Brl-Bmd; 29 Nov 82 20:31-EST
TCP/IP Digest Monday, 29 Nov 1982 Volume 1 : Issue 26
Date: 25 Nov 1982 9:25:11 EST (Thursday)
From: Andrew Malis <malis@Bbn-Unix>
Subject: Host throughput results for 11/15/82 TCP-only test
To: tcp-ip at BRL
(39)Date: 15 Dec 1982 11:56:33 EST (Wednesday)
From: Andrew Malis <malis@Bbn-Unix>
Subject: TCP-only results, 12/13-14
To: DCAcodeB627 at Bbnb, DCAcode252 at Usc-Isi
Cc: Cerf at Usc-Isi, tcp-ip at Sri-Nic, tcp-ip at BRL
18-Dec-82 10:42:55-PST,33336;000000000001
Mail-from: ARPANET host BRL rcvd at 18-Dec-82 1039-PST
UUCP-From: decvax!brl-bmd!tcp-ip
Sender: Mike Muuss <TCP-IP@BRL>
From: TCP-IP at BRL
To: TCP-IP at BRL
Date: 17 Dec 1982
Subject: TCP-IP Digest, Vol 1 #28
Via: Brl-Bmd; 17 Dec 82 23:48-EST
(40)31-Aug-83 10:57:37-PDT,19245;000000000000
Return-Path: <NIC@SRI-NIC.ARPA>
Received: FROM SRI-NIC BY USC-ISIF.ARPA WITH TCP ; 30 Aug 83 10:04:31 PDT
Date: Tue 30 Aug 83 09:18:18-PDT
From: NIC@SRI-NIC.ARPA
Subject: DDN Newsletter No. 30
To: DDN-NEWS-LIST4: ;
======================================================================
DDN-NEWS 30 NETWORK INFO CENTER for
30 Aug 1983 DCA DDN Program Mgmt Office
NIC@SRI-NIC (415) 859-3695
(41) 26-Feb-83 06:00:24-PST,16211;000000000001
Return-path: <tcp-ip@brl-bmd.arpa>
Mail-From: SMTP created at 26-Feb-83 05:57:03
Received: FROM BRL-BMD BY USC-ISIF.ARPA WITH TCP ; 26 Feb 83 05:57:10 PST
Sender: Mike Muuss <TCP-IP@Brl.ARPA>
From: TCP-IP@Brl.ARPA
To: TCP-IP@Brl.ARPA
Date: 26 Feb 1983
Subject: TCP-IP Digest, Vol 2 #1
Received: From brl-gateway.ARPA via smtptcp; 26 Feb 83 5:12 EST
(41a) From emails from Mark Crispin April-May 1998.
(42) Return-path: ROODE@SRI-NIC
Date: 5 Jan 1983 2340-PST
From: ROODE at SRI-NIC (David Roode)
Subject: obtaining gateway table
To: tcp-ip@BRL
Location: EJ296 Phone: (415) 859-2774
26-Feb-83 06:00:24-PST,16211;000000000001
Return-path: <tcp-ip@brl-bmd.arpa>
Mail-From: SMTP created at 26-Feb-83 05:57:03
Received: FROM BRL-BMD BY USC-ISIF.ARPA WITH TCP ; 26 Feb 83 05:57:10 PST
Sender: Mike Muuss <TCP-IP@Brl.ARPA>
From: TCP-IP@Brl.ARPA
To: TCP-IP@Brl.ARPA
Date: 26 Feb 1983
Subject: TCP-IP Digest, Vol 2 #1
Received: From brl-gateway.ARPA via smtptcp; 26 Feb 83 5:12 EST
(43) 26-Feb-83 06:00:24-PST,16211;000000000001
Return-path: <tcp-ip@brl-bmd.arpa>
Mail-From: SMTP created at 26-Feb-83 05:57:03
Received: FROM BRL-BMD BY USC-ISIF.ARPA WITH TCP ; 26 Feb 83 05:57:10 PST
Sender: Mike Muuss <TCP-IP@Brl.ARPA>
From: TCP-IP@Brl.ARPA
To: TCP-IP@Brl.ARPA
Date: 26 Feb 1983
Subject: TCP-IP Digest, Vol 2 #1
Received: From brl-gateway.ARPA via smtptcp; 26 Feb 83 5:12 EST
[ Hosts are strongly encouraged to reload their host tables frequently.
Either when booting the system, or at certain times during the week
seems to be the best approach. -Mike ]
(44) 5-Dec-82 15:36:40-PST,14373;000000000000
Mail-from: ARPANET host BRL rcvd at 5-Dec-82 1532-PST
UUCP-From: decvax!brl-bmd!tcp-ip
Sender: Mike Muuss <TCP-IP@BRL>
From: TCP-IP at BRL
To: TCP-IP at BRL
Date: 5 Dec 1982
Subject: TCP-IP Digest, Vol 1 #27
Via: Brl-Bmd; 5 Dec 82 12:04-EST
(45) 22-Jun-83 08:51:21-PDT,13169;000000000001
Return-Path: <tcp-ip@brl-vgr>
Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 21 Jun 83 20:02:00 PDT
Received: From Brl-Vgr.ARPA by BRL-VGR via smtp; 21 Jun 83 21:51 EDT
Sender: Mike Muuss <TCP-IP@brl>
(45)
From: TCP-IP@brl
To: TCP-IP@brl
Date: 21 June 1983 00:00 EST
Subject: TCP-IP Digest, Vol 2 #10
TCP/IP Digest Tuesday, 21 June 1983 Volume 2 : Issue 10
Date: 17 Jun 1983 2012-PDT
From: NIC@sri-nic
Subject: FURTHER DETAILS ON THE ARPANET/MILNET SPLIT
[ This message is an excerpt from DDN Newsletter 27, concerning the
MILNET/EXPNET split. For more information, contact <NIC@NIC>. -Mike ]
(46) 11-Oct-83 08:34:41-PDT,22342;000000000001
Return-Path: <tcp-ip@brl-vgr>
Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 11 Oct 83 05:41:03 PDT
Received: From Brl-Vgr.ARPA by BRL-VGR via smtp; 11 Oct 83 6:09 EDT
Sender: Mike Muuss <TCP-IP@brl>
From: TCP-IP@brl
To: TCP-IP@brl
Date: 11 Oct 1983 00:00 EST
Subject: TCP-IP Digest, Vol 2 #18
TCP/IP Digest Tuesday, 11 Oct 1983 Volume 2 : Issue 18
------------------------------
Date: Tue, 11 Oct 83 4:30:44 EDT
From: Mike Muuss <mike@brl-bmd>
To: tcp-ip@brl-bmd
Subject: The MILNET Split: One Perspective
(47)11-Oct-83 08:34:41-PDT,22342;000000000001
Return-Path: <tcp-ip@brl-vgr>
Received: FROM BRL-VGR BY USC-ISIF.ARPA WITH TCP ; 11 Oct 83 05:41:03 PDT
Received: From Brl-Vgr.ARPA by BRL-VGR via smtp; 11 Oct 83 6:09 EDT
Sender: Mike Muuss <TCP-IP@brl>
From: TCP-IP@brl
To: TCP-IP@brl
Date: 11 Oct 1983 00:00 EST
Subject: TCP-IP Digest, Vol 2 #18
TCP/IP Digest Tuesday, 11 Oct 1983 Volume 2 : Issue 18
From: Mike Muuss <Mike@BRL>
To: TCP-IP@BRL
Subject: On the Undesirability of "Mail Bridges" as a Security Measure
Appendix A
31-Aug-83 10:57:37-PDT,19245;000000000000
Return-Path: <NIC@SRI-NIC.ARPA>
Received: FROM SRI-NIC BY USC-ISIF.ARPA WITH TCP ; 30 Aug 83 10:04:31 PDT
Date: Tue 30 Aug 83 09:18:18-PDT
From: NIC@SRI-NIC.ARPA
Subject: DDN Newsletter No. 30
To: DDN-NEWS-LIST4: ;
======================================================================
DDN-NEWS 30 NETWORK INFO CENTER for
30 Aug 1983 DCA DDN Program Mgmt Office
NIC@SRI-NIC (415) 859-3695
DEFENSE DATA NETWORK NEWSLETTER
(Maximum Distribution Requested. The DDN Newsletter is published by
the Network Information Center under DCA contract. For subscription,
contact NIC@SRI-NIC. Back issues obtainable by FTP from the directory
<DDN-NEWS> at SRI-NIC [10.0.0.73].)
======================================================================
Section I. OFFICIAL
Topic: TCP/IP Host Implementations - Results of
Testing for Upcoming Network Split
======================================================================
The following report was prepared by BBN after extensive testing of
host implementations of TCP/IP. The manner of testing is described
herein. While the results are not conclusive, they indicate that some
hosts and the users of those hosts will be adversely affected by the
October 4th split of the ARPANET into the MILNET/ARPANET. In
particular, hosts that currently communicate on a regular basis may
find themselves in different networks on October 4. Thus, they will
have to use a gateway to reach each other. If either host has a
faulty implementation of TCP/IP, this may be impossible.
Two things need to be stressed:
1. Only communication to or from a host with a bad TCP/IP
implementation should be affected in any way.
2. Communication through gateways (mail bridges) may be impossible
for hosts with bad TCP/IP implementations.
-----------------------------------------------------------------------
Over the last month, several experiments were run at BBN to determine
the correctness of ARPANET host TCP/IP implementations. Each test was
run several times to minimize the probability that a host was down
during each test; however, it is possible that some hosts scored lower
than they deserved because they were off the network during all tests.
The first experiment was conducted entirely within the ARPANET. The
second and third experiments, however, required another network
attached to the ARPANET by more than one gateway (since the purpose of
the experiments was to test hosts' abilities to talk through gateways;
see below). BBN has its own ARPANET-like network called the "BBNNET"
which is currently connected to the ARPANET by three gateways. One of
these gateways, the BBN-GATEWAY, is known to the rest of the internet;
it is the gateway which is normally used by traffic between the BBNNET
and the ARPANET. The combination of the ARPANET, the BBNNET, and the
three gateways was used as the testbed for these inter-network
experiments.
There were three experiments. The purpose of the first, Experiment A,
was to determine which hosts are unable to talk TCP even in the
simplest circumstances. From an ARPANET host, an FTP connection was
opened to every ARPANET host (not including TACs, gateways, or secure
hosts). The remote FTP server was then asked for "help", which causes
half a screen or so of text to be sent from the remote host to the
testing host. The purpose of this was simply to cause a little
traffic to flow on the FTP connection. Then the connection was
closed. This test is the simplest possible in that it does not
require the hosts to talk through a gateway or to use ICMP. Hosts
which failed this test are labelled "4" in the following list. These
hosts were excluded from other experiments.
The purpose of Experiment B was to determine which hosts are unable to
talk TCP to a host in another network. From a BBNNET host, the same
FTP experiment was repeated. Hosts failing to sustain the FTP
conversation required by this test are labelled "3" in the following
list. These hosts can talk to hosts in their own network, but not to
hosts in other networks. These hosts were excluded from Experiment C.
The purpose of Experiment C was to determine which hosts deal
incorrectly with redirect messages. This experiment was just like
Experiment B, with one complication. The BBN gateway was told to
redirect all ARPANET hosts to another gateway, "Bridge", that also
connects the ARPANET and the BBNNET. A program called "HTM" (Host
Traffic Matrix) was run in the Bridge during this experiment. HTM
records the source and destination of every datagram that passes
through the gateway. Thus, after running Experiment C, the HTM
results in the Bridge listed every host that obeyed the redirects.
HTM was also run in the BBN gateway during this experiment, and the
results were used as further proof that some hosts disregarded the
redirects altogether. Some hosts failed this test because even though
they did not "choke" on the redirects and could carry the FTP exchange
to completion, they did not pass any traffic through the Bridge (they
ignored the redirects). Other hosts failed this test because they
died or hung the FTP connection after receiving one or more redirects.
Hosts failing this experiment are labelled "2". Hosts passing this
experiment are labelled "1".
In summary, of 190 hosts tested, 98 scored "1" (51%), 28 scored "2"
(15%), 23 scored "3" (12%), and 41 scored "4" (22%). Since these
tests were very simple and did not exercise all capabilities of TCP
(for example, retransmission of lost datagrams) these results are in
no way proof that all "1" hosts have perfectly correct TCP
implementations.
10.0.0.1 UCLA-CS VAX-11/750 LOCUS 1
10.1.0.1 UCLA-CCN IBM-370/3033 OS/MVS 1
10.2.0.1 UCLA-LOCUS VAX-11/750 LOCUS 1
10.3.0.1 UCLA-ATS VAX-11/750 LOCUS 1
10.0.0.2 SRI-NSC11 PDP-11/40 UNIX 4
10.1.0.2 SRI-KL DEC-1090T TOPS20 1
10.2.0.2 SRI-CSL FOONLY-F2 TENEX 1
10.3.0.2 SRI-TSC PDP-11/44 UNIX 2
10.0.0.3 NOSC-CC VAX-11/750 UNIX 1
10.2.0.3 LOGICON PDP-11/45 UNIX 4
10.3.0.3 NPRDC VAX-11/780 UNIX 1
10.0.0.4 UTAH-CS VAX-11/750 UNIX 2
10.3.0.4 UTAH-20 DEC-2060T TOPS20 1
10.0.0.5 BBNF DEC-2040T TOPS20 1
10.1.0.5 BBNG DEC-2060T TOPS20 1
10.3.0.5 BBNA DEC-2050T TOPS20 1
10.0.0.6 MIT-MULTICS HONEYWELL-DPS MULTICS 1
10.1.0.6 MIT-DMS DEC-1040 ITS 1
10.2.0.6 MIT-AI-RESERVED 4
10.3.0.6 MIT-ML DEC-10 ITS 1
10.1.0.7 RAND-RELAY VAX-11/750 UNIX 1
10.3.0.7 RAND-UNIX VAX-11/750 UNIX 1
10.0.0.8 NRL VAX-11/750 UNIX 2
10.1.0.8 NRL-AIC VAX-11/780 UNIX 1
10.2.0.8 NSWC-WO VAX-11/750 UNIX 1
10.3.0.8 NRL-TOPS10 DEC-10 TOPS10 4
10.6.0.8 NRL-ARCTAN PDP-11/40 RSX11 4
10.7.0.8 NRL-CSS VAX-11/780 UNIX 1
10.0.0.9 HARV-10 DEC-10 TOPS10 1
10.2.0.9 YALE VAX-11/750 UNIX 1
10.0.0.10 LL PDP-11/44 UNIX 1
10.1.0.10 LL-VLSI VAX-11/780 UNIX 1
10.2.0.10 LL-XN PDP-11/70 UNIX 3
10.3.0.10 LL-11 PDP-11/45 UNIX 4
10.4.0.10 LL-EN PDP-11/44 UNIX 2
10.0.0.11 SU-AI DEC-1080 WAITS 1
10.3.0.11 SU-SCORE DEC-2060 TOPS20 1
10.0.0.12 COMPION-VMS VAX-11/750 VMS 2
10.1.0.13 GUNTER-ADAM DEC-2060 TOPS20 1
10.0.0.14 CMU-CS-B DEC-1050 TOPS10 1
10.1.0.14 CMU-CS-A DEC-1080 TOPS10 1
10.3.0.14 CMU-CS-C DEC-2060 TOPS20 1
10.0.0.15 ROCHESTER VAX-11/750 UNIX 3
10.0.0.16 AMES-TSS IBM-360/67 TSS/360 2
10.2.0.16 AMES-VMSA VAX-11/780 VMS 2
10.3.0.16 AMES-VMSB VAX-11/780 VMS 2
10.4.0.16 AMES-UNIXA VAX-11/780 UNIX 4
10.5.0.16 AMES-UNIXB VAX-11/780 UNIX 4
10.0.0.17 MITRE BBN-C/70 UNIX 1
10.4.0.17 MITRE-LAN 3
10.0.0.18 RADC-MULTICS HONEYWELL-DPS MULTICS 1
10.3.0.18 RADC-TOPS20 DEC-2040T TOPS20 1
10.5.0.18 RADC-UNIX PDP-11/45 UNIX 4
10.0.0.19 NBS-VMS VAX-11/780 VMS 2
10.1.0.19 NBS-SDC VAX-11/780 VMS 2
10.2.0.19 NBS-UNIX PDP-11/45 UNIX 4
10.3.0.19 NBS-PL PDP-11/70 UNIX 4
10.0.0.20 CCTC PDP-11/70 UNIX 4
10.3.0.20 EDN-UNIX PDP-11/70 UNIX 2
10.4.0.20 DCA-EMS BBN-C/70 UNIX 1
10.0.0.21 LLL-TIS PDP-11/70 UNIX 4
10.1.0.21 LLL-MFE DEC-1090 TOPS10 1
10.2.0.21 LLL-ZDIVISION 4
10.0.0.22 ISI-SPEECH11 PDP-11/45 EPOS 4
10.1.0.22 USC-ISI DEC-1090T TOPS20 1
10.2.0.22 USC-ISIC DEC-2060 TOPS20 1
10.0.0.23 USC-ECLB DEC-1090B TOPS20 1
10.1.0.23 USC-ECLC DEC-1090B TOPS20 1
10.3.0.23 USC-ECL DEC-1090B TOPS20 1
10.0.0.24 NADC VAX-11/780 UNIX 1
10.3.0.24 WHARTON-10 PLURIBUS VDA 4
10.0.0.25 SEISMO VAX-11/780 UNIX 2
10.0.0.27 USC-ISID DEC-2060T TOPS20 1
10.1.0.27 ISI-PNG11 PDP-11/40 ELF 4
10.2.0.27 ISI-VAXA VAX-11/780 UNIX 1
10.0.0.28 ARPA-DMS LSI-11/3 MOS 2
10.3.0.28 ARPA-PNG11 PDP-11/34 EPOS 4
10.0.0.29 BRL PDP-11/70 UNIX 2
10.1.0.29 APG-1 BBN-C/70 UNIX 1
10.0.0.31 CCA-UNIX VAX-11/780 UNIX 3
10.1.0.31 CCA-VMS VAX-11/780 VMS 3
10.0.0.32 PARC-MAXC MAXC TENEX 1
10.3.0.32 KESTREL FOONLY-F3 TENEX 3
10.0.0.34 LBL-NMM VAX-11/780 VMS 2
10.1.0.34 LBL-CSAM VAX-11/780 UNIX 2
10.1.0.35 NOSC-TECR VAX-11/780 VMS/EUNICE 4
10.4.0.35 NOSC-F4 FOONLY-F4 FOONEX 4
10.0.0.37 PURDUE VAX-11/780 UNIX 1
10.1.0.38 BRAGG-STA1 PDP-11/34 ELF 4
10.0.0.43 OFFICE-1 FOONLY-F4 TENEX 1
10.1.0.43 OFFICE-2 FOONLY-F4 TENEX 1
10.2.0.43 OFFICE-3 FOONLY-F3 TENEX 3
10.3.0.43 OFFICE-7 FOONLY-F3 TENEX 3
10.0.0.44 MIT-XX DEC-2060T TOPS20 1
10.2.0.44 MIT-TSTGW PDP-11 MOS 4
10.3.0.44 MIT-MC DEC-1080 ITS 1
10.1.0.45 PICA VAX-11/780 UNIX 2
10.0.0.46 COLLINS-PR PDP-11/34 ELF 4
10.3.0.46 OKC-UNIX PDP-11/70 UNIX 4
10.0.0.47 WPAFB PDP-11/50 RSX11M 3
10.1.0.47 WPAFB-AFWAL PLURIBUS VDA 1
10.1.0.48 AFWL PDP-11/50 RSX11M 3
10.0.0.49 BBNB DEC-10 TENEX 1
10.3.0.49 BBNC DEC-10 TENEX 1
10.4.0.49 BBN-CLXX BBN-C/70 UNIX 1
10.2.0.51 SRI-UNIX PDP-11/70 UNIX 2
10.0.0.52 ADA-VAX VAX-11/780 VMS 3
10.1.0.52 USC-ISIE DEC-1090T TOPS20 1
10.2.0.52 USC-ISIF DEC-1090T TOPS20 1
10.3.0.52 USC-ISIB DEC-1090T TOPS20 1
10.0.0.53 AFSC-AD PDP-11/45 RSX11M 3
10.2.0.53 AFSC-DEV PDP-11/44 RSX11M 3
10.4.0.53 NCSC VAX-11/780 UNIX 3
10.5.0.53 MARTIN PDP-11/45 RSX 4
10.0.0.54 CIT-20 DEC-2060 TOPS20 1
10.1.0.54 CIT-VAX VAX-11/780 UNIX 1
10.2.0.54 ACC PDP-11/70 UNIX 4
10.3.0.54 JPL-VAX VAX-11/780 VMS 2
10.1.0.55 ANL-MCS VAX-11/780 UNIX 3
10.0.0.56 SUMEX-AIM DEC-2060 TOPS20 1
10.1.0.56 SU-DSN VAX-11/780 UNIX 4
10.2.0.56 AIDS-UNIX VAX-11/750 UNIX 1
10.0.0.57 TYCHO PDP-11/34 UNIX 4
10.0.0.58 NYU VAX-11/780 UNIX 1
10.1.0.58 BNL PDP-11/44 UNIX 2
10.2.0.58 RUTGERS DEC-2060T TOPS20 1
10.0.0.61 STL-HOST1 DEC-2040 TOPS20 1
10.1.0.61 ALMSA-1 VAX-11/750 UNIX 4
10.0.0.62 UTEXAS-11 PDP-11/70 UNIX 2
10.1.0.62 UTEXAS-20 DEC-2060 TOPS20 1
10.2.0.62 UTEXAS-780 VAX-11/780 4
10.1.0.64 MARTIN-B VAX-11/750 VMS 3
10.3.0.64 ROBINS-UNIX PDP-11/45 UNIX 4
10.0.0.65 AFSC-SD DEC-2020T TOPS20 4
10.2.0.65 AEROSPACE VAX-11/780 UNIX 1
10.1.0.66 AFGL PDP-11/50 RSX11M 3
10.3.0.66 MITRE-BEDFORD VAX-11/780 UNIX 1
10.0.0.67 AFSC-HQ DEC-2040T TOPS20 1
10.0.0.68 USGS1-MULTICS H-60/68 MULTICS 1
10.2.0.68 USGS1-AMDAHL AMDAHL-V7 IBM/VMS 4
10.0.0.69 USGS2-MULTICS H-60/68 MULTICS 2
10.0.0.70 USGS3-MULTICS H-6880 MULTICS 4
10.2.0.70 USGS3-VMS VAX-11/780 VMS 4
10.1.0.72 BBN-UNIX BBN-C/70 UNIX 1
10.0.0.73 SRI-NIC FOONLY-F4 TENEX 1
10.2.0.73 SRI-AI DEC-2060 TOPS20 1
10.3.0.73 SRI-IU VAX-11/780 VMS 2
10.4.0.73 SRI-SPAM-TEST VAX-11/780 UNIX 4
10.0.0.74 SIMTEL20 DEC-2040T TOPS20 1
10.1.0.74 WSMR70A BBN-C/70 UNIX 1
10.3.0.74 WSMR70B BBN-C/70 UNIX 1
10.3.0.75 YUMA 1
10.1.0.77 MIT-DEVMULTICS H-68/80 MULTICS 2
10.3.0.77 MIT-OZ DEC-2060 TOPS20 4
10.0.0.78 UCB-ARPA VAX-11/780 UNIX 1
10.2.0.78 UCB-VAX VAX-11/750 UNIX 1
10.3.0.78 MCCLELLAN PDP-11/70 UNIX 4
10.0.0.79 DEC-2136 DEC-2060T TOPS20 2
10.1.0.79 DEC-MARLBORO DEC-2060T TOPS20 1
10.0.0.80 HI-MULTICS H68/80 MULTICS 2
10.0.0.81 NEMS VAX-11/750 UNIX 1
10.1.0.81 NALCON VAX-11/750 UNIX 1
10.3.0.81 NSRDCOA VAX-11/780 UNIX 1
10.0.0.82 BBNT BBN-C/70 UNIX 1
10.1.0.82 BBN-VAX VAX-11/780 UNIX 1
10.3.0.82 DDN1 BBN-C/70 UNIX 1
10.6.0.82 BBN-NOC2 BBN-C/70 UNIX 1
10.0.0.83 MINET-LON BBN-C/70 UNIX 1
10.0.0.84 NSWC-DL PDP-11/40 RSX11M 3
10.1.0.84 NSWC-G VAX-11/750 UNIX 3
10.0.0.85 NWC-387A VAX-11/750 VMS 2
10.3.0.85 NWC-387B VAX-11/780 VMS 2
10.0.0.87 SANDIA DEC-2060T TOPS20 1
10.0.0.88 NLM-MCS DEC-2060T TOPS20 1
10.0.0.90 LANL VAX-11/750 UNIX 1
10.0.0.91 WASHINGTON DEC-2060 TOPS20 1
10.3.0.91 UW-VLSI VAX-11/780 UNIX 1
10.2.0.92 NUSC-NPT PDP-11/70 UNIX 4
10.3.0.92 NUSC PDP-11/40 ELF 3
10.0.0.93 OFFICE-8 FOONLY-F4 TENEX 3
10.1.0.93 OFFICE-10 FOONLY-F3 TENEX 1
10.2.0.93 OFFICE-15 FOONLY-F4 TENEX 1
10.1.0.94 UWISC VAX-11/750 UNIX 1
10.1.0.95 S1-A FOONLY-F2 WAITS 1
10.2.0.95 S1-B VAX-11/750 UNIX 4
10.3.0.95 S1-C VAX-11/750 UNIX 1
10.0.0.96 UDEL-RELAY VAX-11/750 UNIX 1
10.1.0.96 UDEL-TCP VAX-11/750 UNIX 4
10.2.0.96 UDEL-EE VAX-11/780 UNIX 3
10.3.0.96 CORNELL VAX-11/780 UNIX 3
Last Updated: June 23, 1998
Draft for Comment
