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 and Vint Cerf 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 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 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 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 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 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 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 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 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 Subject: Administrivia TCP-IP@BRL (36a) From: Mike Muuss 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 To: TCP-IP@BRL ------------------------------ 21-Apr-83 09:37:50-PST,11733;000000000001 Return-path: 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 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 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 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 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: 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: 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 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: 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 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: 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 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 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: 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 (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 . -Mike ] (46) 11-Oct-83 08:34:41-PDT,22342;000000000001 Return-Path: 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 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 To: tcp-ip@brl-bmd Subject: The MILNET Split: One Perspective (47)11-Oct-83 08:34:41-PDT,22342;000000000001 Return-Path: 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 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 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: 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 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