----MESSAGE-BEGIN---- <1984080308010000> Return-Path: Received: from CMU-CS-A.ARPA by SRI-NIC.ARPA with TCP; Fri 3 Aug 84 11:04:50-PDT Date: 3 Aug 84 1201 EDT (Friday) From: don.provan@CMU-CS-A.ARPA To: info-nets@MIT-MC.ARPA Subject: OSI CC: tcp-ip@SRI-NIC.ARPA Message-Id: <03Aug84.120136.DP0N@CMU-CS-A.ARPA> I'm not sure info-nets is the proper forum for this, but does anyone know how ISO and NBS are getting along with the OSI? Is there any kind of ground swell of support for using it? I'm reading a lot of articles about it, but they all date from '82. My impression from these articles is that it's being designed using political negotiations and compromise, something that usually leads to something noone wants to use. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984080308470000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC.ARPA with TCP; Fri 3 Aug 84 15:46:47-PDT Date: 3 Aug 1984 1547 PDT From: Eric P. Scott Subject: IP on Ungermann-Bass Net/One To: TCP-IP@SRI-NIC.ARPA Reply-To: EPS@JPL-VLSI.ARPA Greetings, standards-lovers! Recently a number of RFCs have been issued specifying standards for implementing Internet protocols on Ethernet(-like) networks. I am in need of such a standard for Net/One (registered trademark of Ungermann-Bass, Inc.). Net/One Network Interface Units (NIUs) can provide two services of interest to us, Ethernet Data Link Service (EDLS), and Net/One Datagram Service (SDS). EDLS is fully Ethernet compatible (i.e. "this problem has already been solved"). SDS (an "ethernoid") is capable of sending datagrams across Net/One Bridges. Bridges connect Net/One Networks (Ethernet segment, Broadband channel- pair, etc.). SDS provides the interface to Net/One protocols that handle routing, etc. as well as actual delivery. This option is considered cost-effective (less IP networks, less IP gateways). All NIUs have Ethernet-compatible 48-bit addresses. SDP (Simple Datagram Protocol) uses 80-bit addresses; 16 bits are reserved (must be zero), 16 bits are used for the "Network ID" and the remaining 48 are the original "Host ID." Network numbers range from 1-7FFF (hex) and are assigned by the customer. Each Network must have a unique Network ID. "Network 0" is defined to be the directly-connected network. FFFF (hex) (=broadcast) indicates that the datagram should be sent to all networks. Note that to send a datagram to all NIUs both the Network and Host addresses must be set to broadcast values. Instead of a single "Ethernet type" field, SDP has a source and a destination type. If you request (destination) type filtering only the first byte is examined. Legal values for SDP types are 0100-0DFF (hex); 0100-0BFF are reserved for Net/One protocols leaving 0C00-0DFF available for use. SDP (SDS/MDS) Frame Format +---------------+---------------+ | | \ 01 DD 00 multi FF +- -+ | 00 00 ii ii 00 DD 00 nn nn pb | | | \__ Ethernet ___/ +- -+ | iiii = Network ID | DESTINATION ADDRESS | | nnnn = NIU serial # +- -+ | p = port (always 1 for | | | SDS, 1-6 for MDS) +- -+ | b = board (0-3) | | | All bits on in any field +-------------------------------+ | matches any (broadcast) | DESTINATION TYPE | | 0C 00 through 0D FF +-------------------------------+ | | | > SDP HEADER +- -+ | | | | +- -+ | | SOURCE ADDRESS | | 00 00 ii ii 00 DD 00 nn nn pb +- -+ | | | | +- -+ | | | | +-------------------------------+ | | SOURCE TYPE | | 0C 00 through 0D FF +-------------------------------+ | | LENGTH OF DATA FIELD | / +-------------------------------+ | | : DATA : : 0-600 BYTES : | | +-------------------------------+ Issue 1: What to use for type values? Suggestion: set the destination type to 0D 00 + LSB\/of the RFC 900 source type to 0D 00 + MSB/\Ethernet type Issue 2: How to do address resolution? Suggestion: The "Host IDs" are in 10 Meg Ethernet space; adapt existing ARP. Consider embedding Network ID in 32-bit IP address (a la Stanford PUP subnets). Issue 3: Datagrams max out at 600 bytes. Suggestion: Use 576 as the MTU and hope for the best. Issue 4: Trailer encapsulation See issue 3. Feedback is encouraged; assistance drafting an RFC is welcome. Eric P. Scott Networked Computer Systems Group Computer Science and Applications Section Jet Propulsion Laboratory California Institute of Technology P.S. The "un" driver in BSD Unix is for an earlier, incompatible incarnation of Net/One. No one else to my knowledge has attempted this. ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984080602265900> Return-Path: Received: from wisc-rsch.arpa by SRI-NIC.ARPA with TCP; Mon 6 Aug 84 05:26:36-PDT Date: Mon, 6 Aug 84 07:26:59 cdt Message-Id: <8408061226.AA13560@wisc-rsch.arpa> Received: by wisc-rsch.arpa; Mon, 6 Aug 84 07:26:59 cdt To: don.provan@CMU-CS-A.ARPA Subject: Re: OSI Cc: info-nets@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA Sender: forwarder@wisc-rsch.arpa From: herb@wisc-rsch.arpa There's a Committee of the National Academy of Sciences and Engineering which is advising the Department of Defense and the NBS (under their sponsorship) what they should do about Transfer and Internet Protocols. I'm a member of the committee. There has been much OSI progress in the past two years -- much of it resulting from efforts of NBS in collaboration with US industry. There is a transport protocol which is functionally similar to but not interoperable with TCP. The DoD and OSI IP's are much more similar with the Specs on OSI IP just about firmed up. The OSI tranport -- TP4 -- is viewed as good as or slightly better than TCP. The quality of the specs and the validation facilities are better for TP4 than for TCP but there has been much more experience in implementing and operating TCP (though many feel that not all of that experience was performed with high engineering standards). This past month thirteen companies demonstrated interoperating TP4's at the NCC. All went smoothly andd there was much favorable professional and popular press -- articles in the Wall Street Journal and Business Week. I believe that, at most, only two of the demonstrated TP4's were vendor supported products. The big question is how much market demand exists for OSI concept and how soon will products be announced. All agree that ISO has made surprising progress, particularly in the past several years. There has been politics but it has had very little detrimental effect on the evolving standards. The question is: what next? I've spent much time on this is the past year, coming in as a novice. I would be glad to address more specific points. I'd also appreciate a sketch of the kind of response that you get. Herb Benington at System Development Corporation. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984080607200100> Return-Path: Received: from ddn1 by SRI-NIC.ARPA with TCP; Mon 6 Aug 84 08:30:34-PDT Date: 6 Aug 84 11:20:01 EDT From: snively @ DDN1.ARPA Subject: TCP-IP Distribution List To: tcp-ip @ sri-nic.arpa CC: snively @ DDN1.ARPA, mlewis @ DDN1.ARPA, dcab645 @ DDN1.ARPA Please remove DCAB645 at DDN1 from subject distribution and add MLEWIS at DDN1. Thanks much, Jack Snively, DCA/B646 703-285-5230 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984080608030000> Return-Path: Received: from CMU-CS-A.ARPA by SRI-NIC.ARPA with TCP; Mon 6 Aug 84 09:06:19-PDT Date: 6 Aug 84 1203 EDT (Monday) From: don.provan@CMU-CS-A.ARPA To: info-nets%mit-oz@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA Subject: re: OSI Message-Id: <06Aug84.120305.DP0N@CMU-CS-A.ARPA> first, let me clarify what i'm asking for. i've gotten two responses from my note so far. one said "here are the people working on OSI. Ask them." the other you all saw, and said "this is where we are." i appreciate the input and it's information i can use, but what i really want to know is what do people think about it that aren't personally involved? is anyone planning to use this once it does start to hit the streets? one thing that's always worried me was exacerbated when Herb Benington used the word "inoperable." i assume if he meant "compatible," he would have said that, so it sounds to me like we're going to have lots of ISO compatible, NBS approved products that can't talk to each other. i've always been told that the ISO stuff is more of a guideline than a protocol specification, and this seems to bear that out. a protocol does me no good if i can't plug in an IBM machine and network it to my DEC machine. it doesn't help any that they both agree with ISO if they can talk. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984080608103700> Return-Path: Received: from wisc-rsch.arpa by SRI-NIC.ARPA with TCP; Mon 6 Aug 84 11:10:22-PDT Date: Mon, 6 Aug 84 13:10:37 cdt Message-Id: <8408061810.AA17822@wisc-rsch.arpa> Received: by wisc-rsch.arpa; Mon, 6 Aug 84 13:10:37 cdt To: don.provan@CMU-CS-A.ARPA Subject: re: OSI Cc: info-nets%mit-oz@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA Sender: forwarder@wisc-rsch.arpa From: herb@wisc-rsch.arpa First let me start with an assertion or hypothesis. To wit: TP4 is a very well specified protocol. It is not only a guideline. It is not an early or mid X.25 which has so many options that it's unlikely that two implementations will be able to talk to each other. There are important options in implementing TP4 but they represent vertical features (assuming a model of heterogenous processors talking to each other horizontally). Two examples: There is an option for a "graceful close" (which DoD would very like to have in its implementations) but it isn't essential for minimum operations. Security is a well defined interface but design of security specifics is left up to the implementation (which is the way DoD would wan't it). Next, two different implementations of TP4 should talk to each other if they follow the specifications and understand which options are being followed. The best example of this is the development of the implementations for the NCC demonstration just successfully completed. It took about an hour and a half for fifteen vendors to agree on all details that would be implemented. Once a vendor had his (or her) implementation completed, they would subject it to a battery of tests that have been prepared over the past two years. These NBS tests have been described in Data Communications and received very good professional reviews. If they passed those tests, then it turned out that invariably they could talk to the other vendors at the transport level. (There were some less well specified and testable functions at the File and Applications level that had to be worked out but these ended up causing no problems.) Not all TP4 vertical functions were demonstrated in Las Vegas; for example, graceful close was omitted. In my previous message I had meant to say that TCP and TP4 are functionally similar but won't interoperate with each other. Some people are looking at translating gateways but there's little optimism that these will be easy to achieve or will be functionally powerful. The Committee which I referred to has just about completed its report. Academy protocols urge silence until the Academy issues the report. The intention is to issue the report as an RFC. Several members compared TCP/IP and TP4/IP in some detail; this comparison is in the report. The conclusions are, I think, consistent with the above thoughts. Carl Sunshine at Sytek and Tony Lauck at DEC did the most homework. Almost completely independent of the above analysis but very much related to the market is the work represented in General Motors' Manufacturing Automation Program. The MAP specifications call for ISO as represented in NBS documents and there is a considerable movement to have this become a standard for industrial automation. Similar trends are developing in banking, domestically and internationally. GM has done alot of homework with six vendors including IBM which, I believe, has indicated that it will have ISO gateway products. Pardon the mild pun: this subject is no longer academic. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984080610211300> Return-Path: Received: from RUTGERS.ARPA by SRI-NIC.ARPA with TCP; Mon 6 Aug 84 11:21:08-PDT Date: 6 Aug 84 14:21:13 EDT From: Charles Hedrick Subject: re: OSI To: don.provan@CMU-CS-A.ARPA cc: info-nets%mit-oz@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "don.provan@CMU-CS-A.ARPA" of 6 Aug 84 12:03:00 EDT I am enclosing a reply that I originally sent only to Herb Benington. But first, I can't keep from responding to your comment about interoperability. The term interoperable is viewed as being less ambiguous that compatible. We all know there are various types of compatibility. Interoperable says that the whatever level of compatibility they may or may not have, they have to be able to talk to each other. I think that is what you were asking for. The comment that I assume you are responding to said that the ISO equivalent of TCP would not be interoperable with TCP. I saw nothing in his message to suggest that various ISO implementations would have any problem talking to each other. Indeed he indicated that facilities for validating implementations would be better than on TCP. As I understand it, the people who did the ISO demonstration had to do some of their own protocol-defining, but this was simply because not all the protocols are finished, not because the ISO folks plan to leave holes in their protocols. Now for my actual feelings on the subject. Note that I am sending this because both you and Herb indicated that you wanted to hear from people who aren't involved in the efforts, not because I claim to know anything in particular about networking. ------------------ My problem with the OSI effect is that I am in the process of trying to build up networking locally. I am concerned that the OSI effort is going to detract from our ability to implement TCP. As you probably know, TCP is now available on a very wide variety of machines, and a variety of commercial hardware is becoming available for it. However there are still some serious omissions from the list. Universities are now beginning to press the vendors that are not on the list, and are having some success. However some critical vendors (e.g. IBM, DEC, Apple) keep saying they are waiting for OSI. Unless OSI is going to be markedly superior to TCP, I would rather have the effort vanish. As as example of the effect, consider the trade press coverage of networking. It is almost as if the trade press were in a conspiracy to ignore TCP. All the articles on networking mention the OSI model, and there has been lots of press for the demo that you described. They always manage to give the impression that TCP is used and usable only by a few Arpanet sites. If OSI were really here and available widely, it would be great. I would also be able to understand the attention if OSI were really going to have seriously superior facilities to TCP. But neither of these seems to be the case. So why are we splitting the effort? In my opinion (again, unless something is going on that I don't know), those people who are pushing OSI (e.g. GM) are doing a very serious disservice to the industry. By far the best approach would be to modify the OSI standards to be close to TCP. By close I mean that the changes would either be upward-compatible, or at least of a nature that it would be plausible to believe that all TCP implementations would follow them. Then we would view it as a second-generation TCP. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984080616141800> Return-Path: Received: from MIT-XX.ARPA by SRI-NIC.ARPA with TCP; Mon 6 Aug 84 17:15:19-PDT Date: Mon 6 Aug 84 20:14:18-EDT From: J. Noel Chiappa Subject: Ignorance (sic) of TCP/IP in trade press To: HEDRICK@RUTGERS.ARPA, don.provan@CMU-CS-A.ARPA cc: info-nets%mit-oz@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA, JNC@MIT-XX.ARPA In-Reply-To: Message from "Charles Hedrick " of Mon 6 Aug 84 14:21:13-EDT Hear, hear! ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984080704445600> Mail-From: HSS created at 7-Aug-84 11:53:22 Return-Path: Received: from nosc.ARPA by SRI-NIC.ARPA with TCP; Tue 7 Aug 84 11:45:04-PDT Received: from cod.ARPA by nosc.ARPA (4.12/4.7) id AA24937; Tue, 7 Aug 84 11:44:18 pdt Received: by cod.ARPA (4.12/4.7) id AA13681; Tue, 7 Aug 84 11:44:56 pdt Date: Tue, 7 Aug 84 11:44:56 pdt From: Janet M. Walker Message-Id: <8408071844.AA13681@cod.ARPA> To: tcp-ip-request@sri-nic Subject: Request for info ReSent-date: Tue 7 Aug 84 11:53:22-PDT ReSent-from: Harry Sameshima ReSent-to: tcp-ip@SRI-NIC.ARPA ------- I am trying to find if anyone has ever worked on, or implemented, TCP/IP for a PDP-11 with an IAS operating system. I would appreciate any help you could give me in this matter. walker@nosc ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984080804491000> Mail-From: SAUER created at 8-Aug-84 11:49:10 Date: Wed 8 Aug 84 11:49:10-PDT From: Anne Sauer Subject: Re: Request for info To: walker%cod@NOSC.ARPA cc: SAUER@SRI-NIC.ARPA, perillo@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "Janet M. Walker " of Tue 7 Aug 84 11:54:00-PDT Janet, I am somewhat familiar with the tcp-ip-implementations.txt file where we keep information about implementations of tcp-ip. In that file, there are vendors of various systems. I did a search on the file and found no IAS operating system there. However, I suggest that you ftp the file to your system to look at it because there are several implementations on pdp-11's. The file name is tcp-ip-implementations.txt and by connecting to nic@sri-nic, you may ftp the file over to you. The new Vendor's Guide will be out in hard copy in the near future. If you wish, I could add your name to the distribution list. Also, if you find out more information, we would like to include it in this collection. Thanks for contacting us and I will keep you updated if I learn anything more. Sincerely, Anne for the NIC ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984080806551000> Mail-From: HSS created at 8-Aug-84 13:55:31 Date: Wed 8 Aug 84 13:55:10-PDT From: Harry Sameshima Subject: Error messages To: tcp-ip@SRI-NIC.ARPA cc: postel@USC-ISI.ARPA, mike@BRL-TGR.ARPA, rogers@USC-ISI.ARPA, roode@SRI-NIC.ARPA, satz@SRI-NIC.ARPA This is a test. If it works, TCP-IP list messages will now specify a return path of TCP-IP-RELAY@SRI-NIC so as to funnel downline error messages to be processed at SRI-NIC rather than returning them to the originator of the message. Continue to send contributions to TCP-IP@SRI-NIC and list addition and deletion requests to TCP-IP-REQUEST@SRI-NIC. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984080913261600> Received: from seismo.ARPA by SRI-NIC.ARPA with TCP; Thu 9 Aug 84 15:33:17-PDT Return-Path: Received: from cadmus.UUCP by seismo.ARPA with UUCP; Thu, 9 Aug 84 18:32:34 EDT Message-Id: <8408092232.AA00887@seismo.ARPA> Date: Thu Aug 9 18:26:16 1984 From: Martin Lee Schoffstall Subject: EXCELAN and class A networks To: seismo!tcp-ip@sri-nic.ARPA Is anyone trying to run an EXCELAN board in the DDN/ARPA internet world. Do you have a Class A network or are you doing something in your gateway that you don't want to talk about? marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984081303130000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Mon 13 Aug 84 04:14:29-PDT Date: 13 Aug 1984 07:13-EDT Sender: CERF@USC-ISI.ARPA Subject: Re: OSI From: CERF@USC-ISI.ARPA To: don.provan@CMU-CS-A.ARPA Cc: info-nets@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]13-Aug-84 07:13:22.CERF> In-Reply-To: <03Aug84.120136.DP0N@CMU-CS-A.ARPA> My impression is that the OSI model and the protocols which are developing around it are getting a fair amount of support from the vendors but it is a slow process. Demo's at NCC 84 of the level 4 TP4 and File Transfer protocols on DEC, HPand other gear seem to show serious intent on the part of vendors. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984081317175600> Received: from seismo.ARPA by SRI-NIC.ARPA with TCP; Mon 13 Aug 84 19:37:14-PDT Return-Path: Received: from cadmus.UUCP by seismo.ARPA with UUCP; Mon, 13 Aug 84 22:36:55 EDT Message-Id: <8408140236.AA19184@seismo.ARPA> Date: Mon Aug 13 22:17:56 1984 From: Martin Lee Schoffstall Subject: OSI/NCC thoughts To: seismo!tcp-ip@sri-nic.ARPA I was at NCC specifically to get a feel for what the rest world was going to commit to. Of most interest to me in the short term is that DEC stated that they were going to mold DECNET to follow NBS and friends. IBM Industrial Systems has committed as has HP. Note that IBM was there with Series1's, a 43xx/30xx implementation would be incredibly significant. It would be nice if SNA was put to sleep but given the ECC's settlement, marketing and politics will continue to defeat engineering and architecture. Also rumored was that IBM Corp. was going to commit to OSI through a fabled OSI/NBS <-> SNA bridge. It would seem that this is definitely the coupe de grace on XNS and from other DCA signals an omen for TCP/IP. marty {wivax,bbncca,harvard,seismo}!cadmus!schoff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984081404261900> Received: from ddn1 by SRI-NIC.ARPA with TCP; Tue 14 Aug 84 05:51:06-PDT Date: 14 Aug 84 08:26:19 EDT From: ddn-usaf @ DDN1.ARPA Subject: tcp-ip newsletter mailing list To: tcp-ip @ sri-nic.arpa CC: ddn-usaf @ DDN1.ARPA please add my name to the distribution list for your tcp-ip newsletter. also add jyoung@ddn1. thank you. major allen ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984081513360000> Received: from SU-AI.ARPA by SRI-NIC.ARPA with TCP; Wed 15 Aug 84 20:38:21-PDT Date: 15 Aug 84 2036 PDT From: Joe Weening Subject: Data General TCP implementation? To: tcp-ip@SRI-NIC.ARPA Does anyone know of any IP/TCP implementation for the Data General Eclipse, running RDOS? Joe ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984082104550000> Received: from MIT-MC by SRI-NIC.ARPA with TCP; Tue 21 Aug 84 05:54:27-PDT Date: 21 August 1984 08:55-EDT From: Charles Hornig Subject: bad TCP implementations To: tcp-ip @ SRI-NIC, postmaster @ AIDS-UNIX, postmaster @ UW-VLSI Over the last few months, I have noticed that there are many Internet hosts with defective TCP implementations. The common problem with them is that they do not properly process an incoming segment which contains both acknowledged and unqcknowledged data. Instead of ignoring the acknowledged part and processing the unacknowledged part, they ignore the whole segment. Since the TCP for the Symbolics 3600 sends these segments (for performance reasons), we are unable to communicate with such hosts. The two hosts I have seen this in most recently are UW-VLSI and AIDS-UNIX. These are (I believe) both 4.1bsd Unix hosts. It is really unacceptable that at this late date there are still TCP implementations with such fundamental flaws. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984082312410000> Received: from csnet-relay by SRI-NIC.ARPA with TCP; Fri 24 Aug 84 01:18:31-PDT Received: From vpi.csnet by csnet-relay; 24 Aug 84 4:02 EDT Date: Thu, 23 Aug 84 17:41 EST From: Ed Fox To: info-unix@brl-vgr.arpa, tcp-ip@sri-nic.arpa cc: fox%vpi.csnet@csnet-relay.arpa, kafura%vpi.csnet@csnet-relay.arpa Subject: AT&T IS ISN use with ULTRIX? Does anyone know if it is possible, and if so how, to attach a VAX 11/780 running ULTRIX to the new AT&T Information Systems Network packet controller through KMC front end via fiber? They have hardware to do it into System V and I believe AT&T Technologies has software to go along, but wonder if their URP can work with our TCP/IP or come in through special driver. I know that they have not announced such a product but wonder if it might be possible for us to develop here or get from elsewhere. We eventually will have LAN with several machines, including VAXen running VMS and ULTRIX and some machine running System V, and if we can use KMC instead of DH on ULTRIX machine would then be interested in using ISN for the LAN. Does anyone have other comments about the new ISN? Thank you for your assistance! Please reply directly to fox.vpi@csnet-relay.arpa. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984082313380200> Received: from BRL-TGR by SRI-NIC.ARPA with TCP; Thu 23 Aug 84 14:47:51-PDT Date: Thu, 23 Aug 84 17:38:02 EDT From: Ron Natalie To: gurus@BRL-TGR.ARPA cc: tcp-ip@sri-nic.ARPA Subject: AMES-NAS-GW These people send mail (and want to be on INFO-MICRO) but their host is not listed as a HOST but only as a GATEWAY. MMDF won't send to things that aren't hosts. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984082710380000> Received: from JPL-VLSI.ARPA by SRI-NIC.ARPA with TCP; Mon 27 Aug 84 17:41:47-PDT Date: 27 Aug 1984 1738 PDT From: Ron Tencati Subject: Arpanet User Needs Help... To: TCP-IP@SRI-NIC Cc: TCP-IP-VMS@SRI-NIC Reply-To: TENCATI@JPL-VLSI.ARPA Our Arpanet Guru has left JPL. I was given the dubious title "Keeper of the Net". I am not new to the ARPANET, but I am new to maintaining a computer that is on the Net. My first priority is updating my host tables. Our Guru left no documentation whatsoever. I desire to know how to update my host tables. We have a program called ROUTE that the sytem executes during startup, but I don't know what it does or why (is it documented anywhere?). I don't know how to get the host table at SRI to look like the host table we have here. Our Guru was also able to add hosts not in SRI's table to our local table without rebooting the system (Do I just add a line?). We have a "Field Test Site Agreement" with SRI which I am told is equivalent to a "license" to run the software. We do not have EUNICE here, nor do we do we have The Wollongong Group's stuff. We are currently running (I was told) Kashtan's implementaion of TCP/IP on our 11/780 under VMS V3.6. Apparently, we just FTP the new stuff from SRI when there is an update or such and run it here. We have little or no source (is this normal?). We have RSTAT, NETSTAT, ROUTE, and some other programs that we don't know what they do. We never asked WHY or HOW until now... Outside of the RFCs, is there any documentation (written or known about) that addresses these kinds of implimentations? If anyone out there could give me some advice, it would be appreciably recieved. Thanks in advance, Ron Tencati (TENCATI@JPL-VLSI) ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984082716382900> Received: from CORNELL.ARPA by SRI-NIC.ARPA with TCP; Mon 27 Aug 84 17:38:34-PDT Date: Mon, 27 Aug 84 20:38:29 edt From: cu-arpa.bill@Cornell.ARPA (William A. Nesheim) Message-Id: <8408280038.AA21659@CORNELL.ARPA> Received: by CORNELL.ARPA (4.30/4.30) id AA21659; Mon, 27 Aug 84 20:38:29 edt To: tcp-ip@sri-nic.ARPA Subject: RDP implementation Has anyone implemented the Reliable Data Protocol for 4.2 yet? I am interested in useing it as a basis for a reliable data path between our 4.2 VAX hosts and our pdp11 front-end processors, useing the ethernet as a transport layer. Thanks, Bill Nesheim Cornell U. Dept. of Computer Science bill@Cornell.ARPA {vax135,ihnp4,uw-beaver}!cornell!bill bill@CRNLCS.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984082906470000> Received: from nprdc.ARPA by SRI-NIC.ARPA with TCP; Wed 29 Aug 84 13:52:44-PDT Received: by nprdc.ARPA (4.12/4.7) id AA13931; Wed, 29 Aug 84 13:48:04 pdt Message-Id: <8408292048.AA13931@nprdc.ARPA> Date: 29 August 1984 1347-PDT (Wednesday) From: stanonik@nprdc Reply-To: stanonik@NPRDC To: tcp-ip@sri-nic Subject: 4.2bsd gatewaying Cc: info-unix@brl-tgr We're thinking about running rick@seismo's serial line ip code to a machine, sdcsla, at a local university, ucsd. Our aim is to communicate with sdcsla, but not to gateway between ucsd's relatively large local network and the milnet. (sdcsla is on ucsd's local network and we're on the milnet). My reasoning, or lack thereof, runs as follows. 1) 4.2bsd assumes packets should be forwarded between network interfaces; ie, packets will be forwarded between ucsd's local network and the milnet, given the appropriate routing information. 2) routed on our machine will inform sdcsla that we are a gateway to the milnet, and routed on sdcsla will in turn inform every machine on ucsd's local network. 3) egp (kirton@usc-isif's egp) on our machine will inform every machine on the milnet that we are a gateway to ucsd's local network. 4) Has anyone else had to deal with keeping networks disjoint, both speaking IP? Any ideas on controlling 4.2bsd packet forwarding, or routed/egp routing information? Thanks, Ron Stanonik stanonik@nprdc ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984082911310000> Received: from merlin.ARPA by SRI-NIC.ARPA with TCP; Wed 29 Aug 84 14:32:02-PDT From: Christopher A Kent Message-Id: <8408292131.AA02371@merlin.ARPA> Received: by merlin.ARPA; Wed, 29 Aug 84 16:31:30 est Date: 29 Aug 1984 1631-EST (Wednesday) To: stanonik@NPRDC.ARPA Cc: info-unix@brl-tgr.ARPA, tcp-ip@sri-nic.ARPA Subject: Re: 4.2bsd gatewaying In-Reply-To: Your message of 29 August 1984 1347-PDT (Wednesday). <8408292048.AA13931@nprdc.ARPA> The straightforward way to avoid this is to make sure that sdcsla does not have a route to milnet; then people might send to them, but the reply packets will not be able to get out. If both ends run routed, this might be a problem -- I'm not familiar enough with routed to judge. We axed it a long time ago because it causes more trouble than it's worth. You might be able to do without running routed on the two endpoint machines. chris ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984082916070000> Received: from merlin.ARPA by SRI-NIC.ARPA with TCP; Wed 29 Aug 84 19:07:34-PDT From: Christopher A Kent Message-Id: <8408300207.AA06585@merlin.ARPA> Received: by merlin.ARPA; Wed, 29 Aug 84 21:07:58 est Date: 29 Aug 1984 2107-EST (Wednesday) To: tcp-ip@sri-nic.ARPA Cc: dbg@Purdue.ARPA Subject: TCP/IP on HP 9836? We have just taken delivery of several HP 9836 workstations running HP-UX, and would like to connect them to our local network. I have received several reports of Ethernet cards that connect to the HP-IB bus, and one report of a TCP offering from HP, but "it may not talk to *your* TCP" (why do they call it TCP, then?). Does anyone have positive experience in this arena? Thanks, chris ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984083002180000> Received: from su-shasta.arpa by SRI-NIC.ARPA with TCP; Thu 30 Aug 84 17:23:15-PDT Received: from imagen by Shasta with UUCP; Thu, 30 Aug 84 14:09 PDT Date: Thursday, 30 Aug 1984 09:18-PDT To: shasta!CERF@USC-ISI.ARPA Cc: shasta!cak@PURDUE.ARPA, shasta!tcp-ip@SRI-NIC.ARPA, shasta!dbg@PURDUE.ARPA, geof@su-shasta.arpa Reply-To: imagen!geof@shasta Phone: (408) 986-9400 (work) Postal-Address: IMAGEN, 2650 San Thomas Expressway, Santa Clara, CA 95052 Subject: Re: TCP/IP on HP 9836? In-Reply-To: Your message of 30 Aug 1984 07:08-EDT. <[USC-ISI.ARPA]30-Aug-84 07:08:10.CERF> From: imagen!geof@su-shasta.arpa When I was at NCC I spoke to the engineer who had brought up the TP4 demonstration. I asked whether HP had a networking product based on it. He replied that HP had no immediate plans to use the ISO protocols in a product, but did have a network offering based on TCP-IP. As to whether they believe in general systems interconnection with their TCP and whether they have made this work, I have no idea. - Geof Cooper Imagen ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984083003010000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Thu 30 Aug 84 04:02:23-PDT Date: 30 Aug 1984 07:01-EDT Sender: CERF@USC-ISI.ARPA Subject: Re: 4.2bsd gatewaying From: CERF@USC-ISI.ARPA To: stanonik@NPRDC.ARPA Cc: tcp-ip@SRI-NIC.ARPA, info-unix@BRL-TGR.ARPA Message-ID: <[USC-ISI.ARPA]30-Aug-84 07:01:29.CERF> In-Reply-To: <8408292048.AA13931@nprdc.ARPA> Ron, Along time ago, BBN had to introduce similar fire walls between their commercial Telenet system and the ARPANET (you may recall that BBN started Telenet and sold it to GTE later). They were concerned at that time with TOPS-20 or Tenex systems which were on both Telenet and ARPANET. At that time there was no IP and no host gateway, so they only had to block user access from one net via the host to the other. What happens if you use two hardware interfaces (one to the local net and one to the Milnet) and two copies of IP. The two copies of IP need not know about each other's existence. Users of the IP layer would need to know to route (select) IP services based on destination network. Sounds awful, but it looks to me as if you need to bifurcate the view of the world at about the gateway level if you are to maintain the fiction that your machine is a host on two system which is not, accidently, a gateway between them as well. As to actual code availability to achieve this - I dunno. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984083003080000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Thu 30 Aug 84 04:09:03-PDT Date: 30 Aug 1984 07:08-EDT Sender: CERF@USC-ISI.ARPA Subject: Re: TCP/IP on HP 9836? From: CERF@USC-ISI.ARPA To: cak@PURDUE.ARPA Cc: tcp-ip@SRI-NIC.ARPA, dbg@PURDUE.ARPA Message-ID: <[USC-ISI.ARPA]30-Aug-84 07:08:10.CERF> In-Reply-To: <8408300207.AA06585@merlin.ARPA> Chris, My understanding is that the HP9836's were used to demonstrate something called TP4/IP at the NCC 84. TP4 is the level 4 protocol from ISO. the IP is very similar to the DOD version, considering it was based on the DOD spec. I rather doubt the HP TP4 will work with the DOD TCP. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984083004330000> Received: from USC-ISIE.ARPA by SRI-NIC.ARPA with TCP; Thu 30 Aug 84 07:34:21-PDT Date: 30 Aug 1984 09:33-CDT Sender: SLONG@USC-ISIE.ARPA Subject: New Addition to Mailing List From: SLONG@USC-ISIE.ARPA To: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISIE.ARPA]30-Aug-84 09:33:57.SLONG> Please add SAC.Long@USC-ISIE to your distribution list. Thank you. -- Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984083005263400> Received: from ddn1 by SRI-NIC.ARPA with TCP; Thu 30 Aug 84 06:36:56-PDT Date: Thu, 30 Aug 84 9:26:34 EDT From: dca-pgs Subject: TCP/IP for HP 9836? To: tcp-ip@sri-nic.arpa Cc: cerf@usc-isi.arpa I have heard that HP's adaptation of Unix, "HP-UX", is based upon Berkeley 4.2 and does include TCP/IP + Arpanet applications. Does anyone know anything more? Best, -Pat Sullivan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984083006254000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Thu 30 Aug 84 07:26:24-PDT Date: 30 Aug 1984 10:25:40 EDT From: ECI-ACCAT@USC-ISI.ARPA Subject: HDH To: TCP-IP@SRI-NIC.ARPA cc: ECI-ACCAT@USC-ISI.ARPA, DECKELMAN@USC-ISI.ARPA ECI IS IMPLEMENTING THE HDH HOST INTERFACE. I AM LOOKING FOR ANY EXPERIENCE AND/OR ADVICE OTHERS MIGHT HAVE ENCOUNTERED IN DEVELOPING THIS INTERFACE. THANKS, BOB RICE JR ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984083009582300> Received: from csnet-sh by SRI-NIC.ARPA with TCP; Thu 30 Aug 84 11:06:54-PDT Date: Thu, 30 Aug 84 13:58:23 EDT To: stanonik@nprdc.arpa cc: tcp-ip@sri-nic.arpa, info-unix@brl-tgr.arpa Subject: Re: 4.2bsd gatewaying In-reply-to: Your message of 29 August 1984 1347-PDT (Wednesday). <8408292048.AA13931@nprdc.ARPA> From: Dennis Rockwell From: stanonik@nprdc Subject: 4.2bsd gatewaying Date: 29 August 1984 1347-PDT (Wednesday) We're thinking about running rick@seismo's serial line ip code to a machine, sdcsla, at a local university, ucsd. Our aim is to communicate with sdcsla, but not to gateway between ucsd's relatively large local network and the milnet. (sdcsla is on ucsd's local network and we're on the milnet). My reasoning, or lack thereof, runs as follows. 1) 4.2bsd assumes packets should be forwarded between network interfaces; ie, packets will be forwarded between ucsd's local network and the milnet, given the appropriate routing information. There is a flag (ipforwarding) that you can set to 0 to prevent packet forwarding. You can either change it in your source, or run an adb script from rc.local to turn off the forwarding. Packets which would have been forwarded are then answered with an ICMP UNREACHABLE message. 2) routed on our machine will inform sdcsla that we are a gateway to the milnet, and routed on sdcsla will in turn inform every machine on ucsd's local network. Don't run routed unless you have to (for a local net, perhaps). In any case, turning off forwarding will stop the traffic. 3) egp (kirton@usc-isif's egp) on our machine will inform every machine on the milnet that we are a gateway to ucsd's local network. Why are you running EGP if you don't want to be a gateway? If you run it because you want to keep your routes up to date, then you should use the "egpnetsreachable" config command (in the file etc-egp) to restrict the nets that are advertised by EGP. If you are a gateway between MILNET and some local net you don't mention in your message, then you will have to hack ip_forward in netinet/ip_input.c to exclude the point-to-point net plus all the nets behind sdcsla. 4) Has anyone else had to deal with keeping networks disjoint, both speaking IP? Any ideas on controlling 4.2bsd packet forwarding, or routed/egp routing information? In addition to the above, we (CSNET) have to restrict our non-domestic X.25 sites from sending or receiving packets from the Internet. The solution in this case is (unfortunately) to hack ip_forward as mentioned above. Thanks, Ron Stanonik stanonik@nprdc Good luck! Let me know what you finally do. Dennis Rockwell CSNET Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984083012202000> Received: from wisc-rsch.arpa by SRI-NIC.ARPA with TCP; Thu 30 Aug 84 15:19:33-PDT Date: Thu, 30 Aug 84 17:20:20 cdt Message-Id: <8408302220.AA15496@wisc-rsch.arpa> Received: by wisc-rsch.arpa; Thu, 30 Aug 84 17:20:20 cdt To: cak@Purdue.ARPA Subject: Re: TCP/IP on HP 9836? Cc: dbg@Purdue.ARPA, tcp-ip@sri-nic.ARPA Sender: forwarder@UWVAX From: herb@wisc-rsch.arpa The National Academy panel that has been looking into potential use of ISO's TP4/IP by DoD has unanimously concluded that TP4 can't talk to TCP and that a translating gateway may or may not turn out to be cost-effective. Herb Benington ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984083015211200> Received: from DCN6.ARPA by SRI-NIC.ARPA with TCP; Thu 30 Aug 84 08:28:14-PDT Date: 30-Aug-84 15:21:12-UT From: mills@dcn6 Subject: Backdoor address filters To: stanonic@nprdc cc: tcp-ip@nic Ron, It took me a while to cross-check your presumed connectivity with the NIC tables, from which it is apparent that there are no advertised gateways now between UCSD (128.54), NPRDC-ETHER (192.5.65) and any other net in the Internet system, nor any advertised hosts on these local nets. Thus, it would seem you can protect the UCSD - MILNET path by the simple mechanism of dropping packets (a) with destination address UCSD and source address other than NPRDC-ETHER and (b) with source address UCSD and destination address other than NPRDC-ETHER. This is similar to the mechanism now used on the MARYLAND (University of Maryland) 4.2bsd, which is a gateway between MILNET and UMDNET, which in turn includes a gateway to DCNET, itself gatewayed to ARPANET (!). For further information, I suggest you contact Mark Weiser (weiser@maryland). This mechanism protects only the raw-datagram flow, of course, leaving the IP source-route and Telnet double-login paths open. So far as I know, 4.2bsd does NOT support source-route and Telnet double-login can be prevented by the usual password mechanism. Maryland has not yet brought up the Kirton EGP code, so some fine-tuning may be necessary to prevent UCSD being broadcast in EGP updates. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984083017442200> Received: from RUTGERS.ARPA by SRI-NIC.ARPA with TCP; Thu 30 Aug 84 18:44:50-PDT Date: 30 Aug 84 21:44:22 EDT From: Charles Hedrick Subject: Re: TCP/IP for HP 9836? To: dca-pgs@DDN1.ARPA cc: tcp-ip@SRI-NIC.ARPA, cerf@USC-ISI.ARPA In-Reply-To: Message from "dca-pgs " of 30 Aug 84 09:26:34 EDT The HP/UX that we have is System III with few Berkeley enhancements. The documentation acknowleges Berkeley, but we haven't noticed very many Berkeley features. We have heard rumors that there will be TCP over Ethernet "Real Soon Now", but it does not seem to be available to us yet. They have put a lot of work into documentation, and into graphics support. However System III is a primitive system by today's standards. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984083018330700> Received: from RUTGERS.ARPA by SRI-NIC.ARPA with TCP; Thu 30 Aug 84 19:51:52-PDT Date: 30 Aug 84 22:33:07 EDT From: Charles Hedrick Subject: need for a protocol To: tcp-ip@SRI-NIC.ARPA We are about to start using TCP for our local networking. We need to add a feature that we have been using in PUP. We have a number of batch control files that transfer files among our systems. We prefer to avoid having passwords to privileged user id's in control files. Thus we have implemented a "same name same user" bit on our DEC-20's. If I have that bit set, it asserts that Hedrick is the same on the systems. PUPFTP is able to use this to avoid asking for passwords. I need to do something similar in TCP FTP. I didn't do the PUP implementation, but I think what happens is that the remote FTP server sends the equivalent of a UDP packet to the miscellaneous server asking who the user is on the local machine. As we use "job-relative" socket numbers for FTP connections, the server knows the job number. So it just asks "who is the user for this job number?" We would like to do something similar for TCP. We also need a way for our mail servers to know when they are talking to another server and when to a normal user. We have to prevent a user from convincing one of our servers to forward his message onto the Arpanet when he does not have the right to do so. Both of these problems share something in common: Our server needs to know who it is talking to on the other end. Does anyone know whether there is something in the protocols that will allow this? If not, can anyone suggest a way to add it that will be consistent with the overall philosophies of TCP/IP? The cleanest way is probably to have a server to whom we can send a query: "what is the user name of the job that has the following socket number open?" PUP's method of encoding things in the socket number involves less coding, but is probably not a good idea in the long run. Obviously we will combine this protocol with a list of "trusted hosts". Users on hosts that are not trusted will always have to type a password, and will never be able to get mail forwarded to the Arpanet. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984083104370000> Received: from merlin.ARPA by SRI-NIC.ARPA with TCP; Fri 31 Aug 84 07:36:41-PDT From: Christopher A Kent Message-Id: <8408311437.AA02303@merlin.ARPA> Received: by merlin.ARPA; Fri, 31 Aug 84 09:37:10 est Date: 31 Aug 1984 0937-EST (Friday) To: tcp-ip@nic.ARPA Subject: More info about HP's "TCP" Simply unbelievable. How can they call it TCP? Is there, by some chance, a mechanism for preventing them from using the name TCP, since it really isn't? chris ------- Forwarded Message From: djb@cbosgd.UUCP (David J. Bryant) Subject: Re: HP's TCP/IP implementation Message-ID: <260@cbosgd.UUCP> Date: Wed, 29-Aug-84 08:53:25 EST Date-Received: Thu, 30-Aug-84 01:12:10 EST Organization: AT&T Bell Laboratories, Columbus We have had several meetings with a variety of HP people about this issue recently. You are quite right - the HP implementation of TCP/IP is different from the standard TCP/IP, and it's intentional on HP's part. As far as I understand the situation the differences are that HP's version does not provide/support the following: 1) Urgent Data 2) Graceful Release 3) Option Fields 4) Segmentation and Reassembly of IP packets. 5) Checksumming. (HP figures that this is done adequately in layer 2, so they left it out to improve performance) 6) Address-Resolution Protocol. HP uses a custom-designed "probe" mechanism. The bottom line is that an HP TCP/IP system can ONLY talk to another HP TCP/IP product! We found this to be an incredible design decision, and one that is totally incompatible with our requirements. Further, HP supports only file transfer and remote file access. Virtual terminal and IPC applications are planned for the future. Yet another problem area we're having to work out... According to HP, they have had "several people" question their lack of support for standard TCP/IP. They are clearly aware of the problem, and are considering fixing things up, but we have not had any detailed committment from them. For some reason they are determined to support their "version" of TCP/IP, but they are talking about some mechanism that will make it possible to talk both their version and the standard version with the same software. Regardless, I expect that things will get fixed eventually - the HP folks have been amazingly receptive to our requests so far - but it will take time. Still, we see this as a silly situation, and have yet to understand HP's reasoning on this one. I'd like to personally encourage every HP owner/user (and anyone else that can get HP's ear) to strongly "suggest" to their HP contact that HP get their TCP/IP version in line with the standard, for innumerable obvious reasons. As our discussions with HP progress and new things happen, I'll keep you posted. David Bryant AT&T Bell Laboratories Columbus, OH (614) 860-4516 (cbosgd!djb) ------- End of Forwarded Message ---------- ----MESSAGE-END----