FrontPage FromTheArpanetToTheInternet
@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

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2012-05-08 14:16:15
Processing time 0.1453 sec