----MESSAGE-BEGIN---- [12235651065.18.JNC%40XX.LCS.MIT.EDU] <1986090123184300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JNC@XX.LCS.MIT.EDU ("J. Noel Chiappa") Newsgroups: mod.protocols.tcp-ip Subject: Re: Possible DDN to Ethernet or 802.3 Gateway Vendors Message-ID: <12235651065.18.JNC@XX.LCS.MIT.EDU> Date: Tue, 2-Sep-86 03:18:43 EDT Article-I.D.: XX.12235651065.18.JNC Posted: Tue Sep 2 03:18:43 1986 Date-Received: Tue, 2-Sep-86 20:59:08 EDT References: <8608221327.AA16938@mitre-bedford.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Let me correct some slight errors in that posting about the Proteon entry: a) Proteon does not yet have a DDN X.25 interface, but hope to have one soon; b) for details please *do not* contact me, but call Proteon at 617-655-3340. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860902094524.9.DCP%40KOYAANISQATSI.S4CC.Symbolics.COM] <1986090205450000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) Newsgroups: mod.protocols.tcp-ip Subject: How to IP & ARP on 802 Nets Message-ID: <860902094524.9.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Tue, 2-Sep-86 09:45:00 EDT Article-I.D.: KOYAANIS.860902094524.9.DCP Posted: Tue Sep 2 09:45:00 1986 Date-Received: Tue, 2-Sep-86 21:03:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 Approved: tcp-ip@sri-nic.arpa Date: 29 Aug 1986 19:27:12 PDT From: POSTEL@B.ISI.EDU Hello. Hi. At an ad hoc special session on "IEEE 802 Networks and ARP" held during the recent TCP Vendors Workshop, an approach to a consistent way to sent DOD-IP datagrams and other IP related protocols on 802 networks was developed. [...] A very quick reading of this and a small amount of knowledge about 802.x leads me to believe this looks reasonable. The problem I see is "What happens if ISO blesses DoD IP and then there are two different ways to talk it?" The total length of the SAP Header and the SNAP header is 8-octets, making the 802.2 protocol overhead come out on a nice octet boundary. Good. If we can not quickly resolve the issue of the values for K1 and K2, we will push for the assignment of a sap value (a K1 value) to indicate "IP related protocols" and do our own multiplexing (much like that proposed above). Please don't say "IP related protocols." Only one protocol is IP related and that is IP. Instead say "Ethernet'1980 related protocols" which includes Chaos, PUP, XNS, DECnet, etc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986090209400000> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Wed 3 Sep 86 14:22:15-PDT Received: from (JARRELLR)VTVAX3.BITNET by WISCVM.WISC.EDU on 09/03/86 at 16:22:03 CDT Date: Wed, 3-SEP-1986 17:20 EDT From: Ronald A. Jarrell To: Subject: nsfnet We plan on hooking to nsfnet in the near future, probably through a sattelite link and an imp. We were going to be running Wollongong's WIN on the Vaxes, but I've been told we are going to have a horrible time with it, that it wouldn't work with out a lot of kluding.. Anyone have suggestions as to a good, full-function, tcpip package to use in this situation? It would need ddn protocol support, and be able to talk to unix flavor systems. Please also mention whether or not it would require new hardware, or if we could share the deuna we currently have for decnet and lat. Also, while I'm thinking of it, anyone have PD or non-PD code for domain support for a VMS system? -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609040301.AA14623%40ucbvax.Berkeley.EDU] <1986090210204600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@BRUBECK.PROTEON.COM Newsgroups: mod.protocols.tcp-ip Subject: Re: How to IP & ARP on 802 Nets Message-ID: <8609040301.AA14623@ucbvax.Berkeley.EDU> Date: Tue, 2-Sep-86 14:20:46 EDT Article-I.D.: ucbvax.8609040301.AA14623 Posted: Tue Sep 2 14:20:46 1986 Date-Received: Thu, 4-Sep-86 04:09:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jas@proteon.com Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Your K1 (the SNAP SAP) is '01010101' when presented least signifigant bit first. (First bit to the MAC layer first.) For those of us who think in a forward direction, this is '10101010', or 'AA'hex. While SNAP is only a proposal, I beleive it is de-facto real. I understand that certain proprietary network vendors already plan to use it. By the way, "ethernet types" were handed over by Xerox to the IEEE along with the 24-bit address blocks. There is no list available from IEEE of the allocation of either type of block, they consider that proprietary. I have heard rumors that K2 is '0', and that this 24-bit block belongs to Xerox. Are the Xerox people out there who can confirm this? john shriver proteon ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609040256.AA14578%40ucbvax.Berkeley.EDU] <1986090210272700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@BRUBECK.PROTEON.COM Newsgroups: mod.protocols.tcp-ip Subject: Re: How to IP & ARP on 802 Nets Message-ID: <8609040256.AA14578@ucbvax.Berkeley.EDU> Date: Tue, 2-Sep-86 14:27:27 EDT Article-I.D.: ucbvax.8609040256.AA14578 Posted: Tue Sep 2 14:27:27 1986 Date-Received: Thu, 4-Sep-86 04:09:10 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jas@proteon.com Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa There already was a blessed way to send IP packets over 802.2. The problem was that the powers that be were NEVER going to provide a SAP for ARP, so the IP SAP was useless. Once we had this scheme for ARP, we decided to do IP that way to provide an even-length data-link header, and one the same size as ARP. (DoD Internet is SAP '06'hex.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986090316450000> Received: from LLL-MFE.ARPA by SRI-NIC.ARPA with TCP; Wed 3 Sep 86 23:47:38-PDT Date: Wed, 3 Sep 86 23:45 PDT From: Provan@LLL-MFE.ARPA Subject: re: How to IP & ARP on 802 nets To: tcp-ip@sri-nic.arpa I have two problems with this scheme. Unfortunately, both are caused by the SNAP, which seems to be the part closest to being fully blessed. The first problem is the 24 bit "organization" code. A 24 bit field seems excessively clumsy. (In the immortal words of 1822, it's "not particularly convenient for anyone.") Not too serious, but it fits well with my solution. The second problem is that this plan works great with 802.2 type 1 headers, but 802.2 type 2 messages add an additional byte to the normal 802.2 header. If the SNAP scheme is unchanged in this situation, we find ourselves with the new ethernet type field shifted back to an odd byte and our IP packet gets out of alignment. Does anyone know what happens to the SNAP in type 2? I don't know if it's feasible to send IP packets over type 2 802.2, but if it is we need to worry about this. I have a solution that solves both of these problems. Instead of a 24 bit organization code, break it into an eight bit unused pad field followed by a 16 bit organization code. (Happily, this field is then aligned to an even byte.) In type 2 802.2 packets, this unused eight bits becomes the second byte of the 802.2 control field, but the other four bytes of the SNAP (two for the organization code and two for the new ethernet type field) remain the same. So the 802.2 header would be the same size (eight bytes) for both type 1 and type 2 packets, rather than have the three byte header for type 1 and the four byte header for type 2 in the currently published protocol. Of course, this assumes we have anything to say about this. Since this doesn't appear to be the case, i guess it's too late to avoid these problems. Looking back on this note, i realize that someone without familiarity with 802.2 might be confused. I think i can lessen the confusion by explaining that 802.2 packets, including these three or four (or eight) byte headers, ride inside 802.3 packets, which have the familiar 14 byte ethernet header, with the ethernet type field replaced by the famous 802.3 length field. While i have the floor, at the TCP workshop, i think i heard twice that 802.3 lengths less than 60 are illegal, and, therefore, fall under the famous ethernet footnote, which says that any illegal lengths can be interpreted however the implementation wants (thus allowing previous ethernet implementations to continue to operate on the same network as 802.3 impelmentations). If i heard correctly, i'd like to point out that this is not correct. Lengths less than 60 are legal in 802.3. In fact, it's the need to express a packet smaller than 60 bytes in a hardware environment which doesn't allow transmission of packets less 60 bytes in length that is the justification for the length field in the first place. (A packet can be padded out to 60 bytes while the true length of the packet is preserved via the length field.) don provan provan@lll-mfe.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609040559.AA16708%40ucbvax.Berkeley.EDU] <1986090322015500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JARRELLRA@VTVAX3.BITNET (Ronald A. Jarrell) Newsgroups: mod.protocols.tcp-ip Subject: nsfnet Message-ID: <8609040559.AA16708@ucbvax.Berkeley.EDU> Date: Thu, 4-Sep-86 02:01:55 EDT Article-I.D.: ucbvax.8609040559.AA16708 Posted: Thu Sep 4 02:01:55 1986 Date-Received: Thu, 4-Sep-86 05:20:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa We plan on hooking to nsfnet in the near future, probably through a sattelite link and an imp. We were going to be running Wollongong's WIN on the Vaxes, but I've been told we are going to have a horrible time with it, that it wouldn't work with out a lot of kluding.. Anyone have suggestions as to a good, full-function, tcpip package to use in this situation? It would need ddn protocol support, and be able to talk to unix flavor systems. Please also mention whether or not it would require new hardware, or if we could share the deuna we currently have for decnet and lat. Also, while I'm thinking of it, anyone have PD or non-PD code for domain support for a VMS system? -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4001.526089543%40nrtc-gremlin.northrop.com] <1986090322145600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@NRTC-GREMLIN.ARPA (Marshall Rose) Newsgroups: mod.protocols.tcp-ip Subject: The ISO Development Environment at NRTC Message-ID: <4001.526089543@nrtc-gremlin.northrop.com> Date: Thu, 4-Sep-86 02:14:56 EDT Article-I.D.: nrtc-gre.4001.526089543 Posted: Thu Sep 4 02:14:56 1986 Date-Received: Thu, 4-Sep-86 06:42:20 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: iso-people@nrtc Organization: The ARPA Internet Lines: 64 Approved: tcp-ip@sri-nic.arpa [ multiple appologies for posting this to multiple lists... ] /mtr ----- A N N O U N C E M E N T The first release of the ISO Development Environment at NRTC is available for distribution. This release is called ISODE 1.0 This software supports the development of certain kinds of ISO/CCITT/ECMA protocols and applications. Here are the details: - ISODE is not proprietary, but it is not in the public domain. This was necessary to include a "hold harmless" clause in the release. The upshot of all this is that anyone can get a copy of the release and do anything they want with it, but no one takes any responsibility whatsoever for any (mis)use. - ISODE runs on native 4.2BSD and SVR2 with an Excelan card (Future releases will support VAX/VMS and a variant of PC/IP.) - Current modules include: TSAP - makes TCP look like TP4 SSAP - ISO BCS session PSAP - ASN.1 encoding PEPY - ASN.1 yacc-like facility RoSAP - ECMA Remote Operations Services - Although the ISODE is not "supported" per se, it does have a problem-reporting address, ISO-People@NRTC.NORTHROP.COM. Bug reports (and fixes) are welcome by the way. The primary documentation for this release consists of a User's Manual (approx 150 pages) and a set of UNIX manual pages. The sources to the User's Manual are in LaTeX format. In addition, there are a number of notes, papers, and presentations included in the documentation set, again in either LaTeX or SLiTeX format. There are two ways to get a distribution: 1. If you can FTP to the ARPA Internet, use anonymous FTP to louie.udel.edu [10.0.0.96] and retrieve the file portal/isode-1.tar. This is a tar image (approx 2.0MB). The file portal/isode-1.tar.Z is the tar image after being run through the compress program (approx 0.8MB). 2. Send a magtape and a self-addressed mailing label to: Northrop Research and Technology Center Attn: Automation Sciences Laboratory (0330/T30) One Research Park Palos Verdes Peninsula, CA 90274 USA +1-213/544-5393 We will write the tape in tar format at 1600bpi, and return it with a copy of the User's manual. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609060458.AA27670%40ucbvax.Berkeley.EDU] <1986090322450000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Provan@LLL-MFE.ARPA Newsgroups: mod.protocols.tcp-ip Subject: re: How to IP & ARP on 802 nets Message-ID: <8609060458.AA27670@ucbvax.Berkeley.EDU> Date: Thu, 4-Sep-86 02:45:00 EDT Article-I.D.: ucbvax.8609060458.AA27670 Posted: Thu Sep 4 02:45:00 1986 Date-Received: Sat, 6-Sep-86 05:37:45 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 54 Approved: tcp-ip@sri-nic.arpa I have two problems with this scheme. Unfortunately, both are caused by the SNAP, which seems to be the part closest to being fully blessed. The first problem is the 24 bit "organization" code. A 24 bit field seems excessively clumsy. (In the immortal words of 1822, it's "not particularly convenient for anyone.") Not too serious, but it fits well with my solution. The second problem is that this plan works great with 802.2 type 1 headers, but 802.2 type 2 messages add an additional byte to the normal 802.2 header. If the SNAP scheme is unchanged in this situation, we find ourselves with the new ethernet type field shifted back to an odd byte and our IP packet gets out of alignment. Does anyone know what happens to the SNAP in type 2? I don't know if it's feasible to send IP packets over type 2 802.2, but if it is we need to worry about this. I have a solution that solves both of these problems. Instead of a 24 bit organization code, break it into an eight bit unused pad field followed by a 16 bit organization code. (Happily, this field is then aligned to an even byte.) In type 2 802.2 packets, this unused eight bits becomes the second byte of the 802.2 control field, but the other four bytes of the SNAP (two for the organization code and two for the new ethernet type field) remain the same. So the 802.2 header would be the same size (eight bytes) for both type 1 and type 2 packets, rather than have the three byte header for type 1 and the four byte header for type 2 in the currently published protocol. Of course, this assumes we have anything to say about this. Since this doesn't appear to be the case, i guess it's too late to avoid these problems. Looking back on this note, i realize that someone without familiarity with 802.2 might be confused. I think i can lessen the confusion by explaining that 802.2 packets, including these three or four (or eight) byte headers, ride inside 802.3 packets, which have the familiar 14 byte ethernet header, with the ethernet type field replaced by the famous 802.3 length field. While i have the floor, at the TCP workshop, i think i heard twice that 802.3 lengths less than 60 are illegal, and, therefore, fall under the famous ethernet footnote, which says that any illegal lengths can be interpreted however the implementation wants (thus allowing previous ethernet implementations to continue to operate on the same network as 802.3 impelmentations). If i heard correctly, i'd like to point out that this is not correct. Lengths less than 60 are legal in 802.3. In fact, it's the need to express a packet smaller than 60 bytes in a hardware environment which doesn't allow transmission of packets less 60 bytes in length that is the justification for the length field in the first place. (A packet can be padded out to 60 bytes while the true length of the packet is preserved via the length field.) don provan provan@lll-mfe.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609060636.AA28758%40ucbvax.Berkeley.EDU] <1986090401072200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: steve@BRL.ARPA (Stephen Wolff) Newsgroups: mod.protocols.tcp-ip Subject: Re: nsfnet Message-ID: <8609060636.AA28758@ucbvax.Berkeley.EDU> Date: Thu, 4-Sep-86 05:07:22 EDT Article-I.D.: ucbvax.8609060636.AA28758 Posted: Thu Sep 4 05:07:22 1986 Date-Received: Sat, 6-Sep-86 20:32:08 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 Approved: tcp-ip@sri-nic.arpa I've been told SRI markets a competitive package, but I've lost the reference. Help, someone? -s ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986090401072201> Received: from BRL-SMOKE.ARPA by SRI-NIC.ARPA with TCP; Thu 4 Sep 86 02:17:37-PDT Date: Thu, 4 Sep 86 5:07:22 EDT From: Stephen Wolff To: "Ronald A. Jarrell" cc: tcp-ip@sri-nic.arpa Subject: Re: nsfnet I've been told SRI markets a competitive package, but I've lost the reference. Help, someone? -s ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986090402240000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Thu 4 Sep 86 03:25:27-PDT Date: 4 Sep 1986 06:24-EDT Sender: CERF@A.ISI.EDU Subject: Re: nsfnet From: CERF@A.ISI.EDU To: JARRELLRA%VTVAX3.BITNET@WISCVM.WISC.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 4-Sep-86 06:24:48.CERF> In-Reply-To: The message of Wed, 3-SEP-1986 17:20 EDT from Ronald A. Jarrell Ron, without commenting on the Wollongong software, which I am not qualified to express an opinion about since I have not used it nor reviewed its operation in detail, there is a lengthy publication available from the SRI NIC, and also available on line, I believe, listing quite a number of commercial TCP/IP related products. I don't have the book here with me but urge you to investigate via the NIC. Of course, you should get some interesting replies from the TCP-IP distribution list, too. There is only modest support for VMS, as I recall, as the bulk of the implementations stem from the Berkeley UNIX effort (perhaps 50% are derived in that fashion). Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986090504030000> Mail-From: STJOHNS created at 5-Sep-86 11:04:41 Date: 5 Sep 1986 11:03-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: 1822 vs 1822L Survey From: Mike StJohns To: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA] 5-Sep-86 11:03:12.STJOHNS> I need to know what implementations use what version of the 1822 protocol to talk to their IMPs. If you are an implementer, tell me whether your implementation talks 1822 or 1822L or both. If you have an X25 implementation, I would appreciate knowing about that also. Reply directly to me and I will summarize for the network. Implementers only please.... can you imagine how large my mailbox will be if everyone replied. Thanks, Mike StJohns, DCA B612 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609061149.AA03290%40ucbvax.Berkeley.EDU] <1986090512035900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: klem@BRL.ARPA Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8609061149.AA03290@ucbvax.Berkeley.EDU> Date: Fri, 5-Sep-86 16:03:59 EDT Article-I.D.: ucbvax.8609061149.AA03290 Posted: Fri Sep 5 16:03:59 1986 Date-Received: Sat, 6-Sep-86 20:35:55 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 42 Approved: tcp-ip@sri-nic.arpa Subject: imprecise DDN X.25 specification? Newsgroups: mod.protocols.tcp-ip Distribution: usa To: tcp-ip@sri-nic.arpa Keywords: DDN X.25 CDC We have a contract with CDC to build and install an interface from a CDC Cyber 750 running NOS to a MILNET IMP. The contractors attended a 3-day TCP/IP Vendor Workshop in Monterey last month. They came away from the meeting with lots of questions. Can anyone answer the concerns that were surfaced at the meeting (see below for the contractor's questions)? ------------------------------------------------------------------------- It was stated that the contractor can be implementing X.25 in agreement with the contract specification, pass the DCA Qualification Test and not be able to communicate with the IMP. This is a result of the imprecise DDN X.25 specification and the incompleteness of the X.25 Qualification Testing. One X.25 issue that was discussed was the X.25/1822 incompatibility on the network. It is our understanding that the government has developed hardware and software solutions and has the situation under control. Other issues that could affect the CDC interface to the IMP include: 1) CDC X.25 does not establish a virtual circuit for each and every local network destination host and corresponding precedence. 2) CDC will provide the destination address to the IMP through the IP header, as opposed to the X.25 header. 3) CDC will not map an IP address into X.25 and vice-versa. Is it true that any or all of the above issues will create problems in the CDC interface with the DDN? --------------------------------------------------------------------------- Thanks, George Klem ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986090512035901> Received: from BRL-ADM.ARPA by SRI-NIC.ARPA with TCP; Fri 5 Sep 86 13:01:46-PDT Date: Fri, 5 Sep 86 16:03:59 EDT From: klem@BRL.ARPA Sender: klem@BRL.ARPA To: tcp-ip@sri-nic.arpa Subject: imprecise DDN X.25 specification? Newsgroups: mod.protocols.tcp-ip Distribution: usa To: tcp-ip@sri-nic.arpa Keywords: DDN X.25 CDC We have a contract with CDC to build and install an interface from a CDC Cyber 750 running NOS to a MILNET IMP. The contractors attended a 3-day TCP/IP Vendor Workshop in Monterey last month. They came away from the meeting with lots of questions. Can anyone answer the concerns that were surfaced at the meeting (see below for the contractor's questions)? ------------------------------------------------------------------------- It was stated that the contractor can be implementing X.25 in agreement with the contract specification, pass the DCA Qualification Test and not be able to communicate with the IMP. This is a result of the imprecise DDN X.25 specification and the incompleteness of the X.25 Qualification Testing. One X.25 issue that was discussed was the X.25/1822 incompatibility on the network. It is our understanding that the government has developed hardware and software solutions and has the situation under control. Other issues that could affect the CDC interface to the IMP include: 1) CDC X.25 does not establish a virtual circuit for each and every local network destination host and corresponding precedence. 2) CDC will provide the destination address to the IMP through the IP header, as opposed to the X.25 header. 3) CDC will not map an IP address into X.25 and vice-versa. Is it true that any or all of the above issues will create problems in the CDC interface with the DDN? --------------------------------------------------------------------------- Thanks, George Klem ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609052225.AA14460%40utah-cs.ARPA] <1986090514253100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cetron@UTAH-CS.ARPA (Edward J Cetron) Newsgroups: mod.protocols.tcp-ip Subject: Re: nsfnet Message-ID: <8609052225.AA14460@utah-cs.ARPA> Date: Fri, 5-Sep-86 18:25:31 EDT Article-I.D.: utah-cs.8609052225.AA14460 Posted: Fri Sep 5 18:25:31 1986 Date-Received: Sat, 6-Sep-86 20:48:04 EDT References: <8609040559.AA16708@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: utah-cs!cetron (Edward J Cetron) Organization: Center for Engineering Design, Univ of Utah Lines: 46 Approved: tcp-ip@sri-nic.arpa -------------------------- the standard sacrificial line We have been using the Tektronix tcp/ip package for quite a few months and have found it extremely useful... A quick summary: Advantages (especially vs. WIN/VX) 1. you are given ALL of the source code (albeit in bliss) 2. the code is NATIVE-style NOT a unix port 3. it has proved to be very reliable, easy to modify for local hacks/improvements 4. with very few exceptions, it is very clean, readable code which tends to follow the tcp mil-std very well.... 5. with the software tools message system (public domain from lbl) it also will support smtp as per rfc 822, 821.... 6. it is virtually free for an educational institutional site license. Disadvantages: 1. It is available currently only to educational institutions (but some commercial sites HAVE gotten access to it). 2. it currently only supports telnet, ftp, 3com ftp, and smtp 3. there is no support (but then i understand the Wollongong doesn't support there product either in reality) 4. it does not yet support nameservers, >255 hosts, and anything other than in its fixed host table (however; we are currently fixing these problems and hope to have them resolved within 2 months) All in all, compared to WIN/VX (which i HAVE used) i feel that it is infinitely superior (and much cheaper). While it isn't perfect (yet) you have the code to fix whatever ails it. One of our sites has been using it for 3 months with NO MAJOR COMPLAINTS except when the WIN/VX site that they talk to screws up. I would be happy to answer any further questions or supply details if people would like... -ed cetron center for engineering design Univ. of Utah cetron%utah-cbd@utah-cs.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609041457.AA08219%40mitre.ARPA] <1986090601025400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Gateway Selection Procedure Message-ID: <8609041457.AA08219@mitre.ARPA> Date: Sat, 6-Sep-86 05:02:54 EDT Article-I.D.: mitre.8609041457.AA08219 Posted: Sat Sep 6 05:02:54 1986 Date-Received: Sat, 6-Sep-86 20:33:10 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 49 Approved: tcp-ip@sri-nic.arpa Gentlemen: I solicit advice and document references on how IP should select a particular Gateway when more than one is available. Background My responsibilities include writing communications and network performance requirements for a large military system called the WWMCCS Information System (WIS). The WIS will (initially) consist of about 40 sites. Each site will have: - a 10 Mbps Applitek LAN - 2 or 3 large host processors - 50 to 150 workstations The workstations and hosts are connected to the LAN through Interface Units (IUs). TCP and IP are performed in the IUs. Each LAN has at least one Gateway IU that connects the LAN to the DDN-RVN (DDN-Red Virtual Network, Class A Net 21). All inter-site communications use net 21. For increased throughput and availability, some sites will have 2 or 3 Gateway IUs. Some Gateways will connect to the DDN-RVN at 56 Kbps, others at 9.6 Kbps. Each LAN has a LAN Control Center/Security Monitor (CC/SM). For security and access control, procedures have been established such that the CC/SM is aware of the status of every connection; every TCP active or passive open/close/abort request is routed through the CC/SM. Further, by means of periodic interrogation, the CC/SM knows the health and traffic load of every local IU, including the local Gateways. Questions When IP in a host or workstation IU receives a datagram destined for a remote site, what procedure should be used to select one of the local Gateways? When IP in a Gateway receives a datagram from the LAN, what procedure should be used to select one of the Gateways at the remote site? Any advice or references would be appreciated. H. Craig McKee 'mckee at mitre' (703)883-5505 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860906-231241-2077%40Xerox] <1986090622123700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Murray.pa@XEROX.COM Newsgroups: mod.protocols.tcp-ip Subject: Re: Ethernet between buildings Message-ID: <860906-231241-2077@Xerox> Date: Sun, 7-Sep-86 02:12:37 EDT Article-I.D.: Xerox.860906-231241-2077 Posted: Sun Sep 7 02:12:37 1986 Date-Received: Tue, 9-Sep-86 08:42:49 EDT References: <8608291855.AA07258@ucbjade.Berkeley.Edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa If you can possibly find the $ for the fibers, that's the way to go. If you talk to anybody in the fiber business, this is probably the first application they will mention. I suggest a very cautious, respectful approach when dealing with things as potent as lightning. You may think your buildings are both grounded but at the currents developed near lightning strikes, all sorts of unobvious things will happen. Consider what will happen when your whole net goes down. You may only have a few machines today, but you know that more be running tomorrow. People will be using them for term projects and writing their thesis. Networks are addicting. Remember that it will happen durning the end of term rush. We have one (coax) ethernet under the street to another building. 6 or 7 years ago, a lightning bolt hit the hill a bit beyond that building. It fried the front end transistor in dozen or so transcievers. Each fried transistor was a short accross the coax. That whole net was down until they found the last dead transciever. There were lots of people milling around the halls and grumbling... (At least we could scrounge enough transcievers on short notice to get everybody back on the air.) (That was a long time ago. A simple resistor in the right place will probably provide enough protection. Most transcievers probably include one now.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986090701240000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 7 Sep 86 02:25:10-PDT Date: 7 Sep 1986 05:24-EDT Sender: CERF@A.ISI.EDU Subject: Re: Gateway Selection Procedure From: CERF@A.ISI.EDU To: mckee@MITRE.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 7-Sep-86 05:24:41.CERF> In-Reply-To: <8609041457.AA08219@mitre.ARPA> Mr. McKee - you should be able to "pick any" of the known available gateways - if you picked the wrong one, relative to minimum delay routing, that one will "redirect" you to the right one. However, it is possible the one you picked is dead. If the subnet you use to reach that gateway tells you about dead hosts, as the ARPANET does, then you will be able to detect this mistake and change your tables to select another gateway. There is no existing algorithm for selectively routing traffic across multiple gateways. Dave Mills tried one that resulted in every other packet landing in the Atlantic Ocean (The "Atlantic Two-Step"). It is not even clear that such bifurcation oftraffic across a single TCP logical connection would be a good idea - especially if the two routes have widely differing delay/loss characteristics - the TCP level performance monitoring and feedback control might have a lot of trouble trying to adapt if every other packet, for instance, went a different way with very different parametric profile. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986090701400000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 7 Sep 86 02:41:43-PDT Date: 7 Sep 1986 05:40-EDT Sender: CERF@A.ISI.EDU From: CERF@A.ISI.EDU To: klem@BRL.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 7-Sep-86 05:40:32.CERF> In-Reply-To: The message of Fri, 5 Sep 86 16:03:59 EDT from klem@BRL.ARPA Wow! A fast reading of your message, especially the last part characterizing the DCD X.25, suggest you are in trouble. The IMP does NOT, so far as I know, examine the IP for an address. The host or front end doing the IP has to map the internet address into an appropriate X.25 address (to the destination or to the gateway on the X.25 network). It is not necessarily a requirement that each TCP connection be mapped into a distinct X.25 virtual circuit. Some implementations map all TCP connections into a single X.25 virtual circuit between source and destination or source and gateway. This could result in poorer throughput as the number of TCP connections increases and also result in some interference between the varius communicating processes sharing the common virtual circuit. Since there is no easy way to tell IP that it is handling a new TCP connection, this is an area of performance concern which may have implementation and/or application specific consequences and require specific remedies. BBN has developed software which permits 1822 and X.25 interoperability; however, there are two modes of X.25 interface on the network: standard and basic. The basic mode is incapable of dealing with the X.25/1822 mapping since it is really just an end/end X.25 pipe - the commercial interface to X.25 that BBN sells. The Standard mode (DoD standard) will support 1822/X.25 interfacing. ALL of X.25 is terminated in the IMP at the interface. At the destination, if the interface is also Standard X.25 (not BASIC X.25), the full X.25 is RECREATED. If the destination is 1822, it will see a fabricated 1822 exchange. In the STANDARD case, X.25 and 1822 addresses are mapped back and forth. There was indication at the Monterey meeting that the STANDARD X.25 mode had not necessarily been installed on both the ARPANET and MILNET - the DDN NIC would be a good place to query in this regard. The principle issue is whether the typical commercial implementations of X.25 are compatible with (interoperate with) the DoD Standard X.25. They certainly SHOULD interoperate with BASIC X.25. The reason there are two X.25 style interfaces is that the BASIC mode was readily available and permitted hosts with vendor-specific protocols to use the MILNET for communications, independent of interoperability with other hosts on the system. If all hosts used X.25 interfaces, I believe there would be no need for the Standard X.25 interface with its conversion facility - but this is not the case. I'm sure you'll get other comments on the TCP-IP distribution. Maybe we need an RFC laying all this out... Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609090507.AA17236%40ucbvax.Berkeley.EDU] <1986090713322700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: haverty@CCV.BBN.COM Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway Selection Procedure Message-ID: <8609090507.AA17236@ucbvax.Berkeley.EDU> Date: Sun, 7-Sep-86 17:32:27 EDT Article-I.D.: ucbvax.8609090507.AA17236 Posted: Sun Sep 7 17:32:27 1986 Date-Received: Tue, 9-Sep-86 20:35:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 27 Approved: tcp-ip@sri-nic.arpa Vint et al, A minor clarification. There is no general algorithm in use which spreads traffic across multiple gateways. There is however a special-purpose table-driven algorithm in the Arpanet/Milnet mailbridges, which attempts to spread traffic amongst the seven parallel mailbridges. It is effective only for hosts which are physically connected to the Arpanet or Milnet, but not gateways, because hosts listen (should at least) to redirects but gateways do not. Fortunately this covers a lot of the traffic; without this mechanism, the mailbridge would be a highly reliable bottleneck (more so than it is now), since only one path would be "best", with six !! idle backup gateways at any time. Unfortunately, with more LANs all the time, this interim approach is clearly limited. There is a feature in design stages now for the C/30 family, which will permit multipath routing to occur -- i.e., between points A and B several parallel paths might exist, and all might be in use to carry traffic. With such a mechanism, for example, a network with only 9.6 kilobit/sec trunks could achieve a host-host throughput greater than 9.6 by using the multiple paths. This is a very hard problem, to achieve stability and efficiency and avoid behavior like the Atlantic two-step. Jack Haverty ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609090623.AA18262%40ucbvax.Berkeley.EDU] <1986090714125600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@BRUBECK.PROTEON.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: re: How to IP & ARP on 802 nets Message-ID: <8609090623.AA18262@ucbvax.Berkeley.EDU> Date: Sun, 7-Sep-86 18:12:56 EDT Article-I.D.: ucbvax.8609090623.AA18262 Posted: Sun Sep 7 18:12:56 1986 Date-Received: Tue, 9-Sep-86 20:41:59 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jas@proteon.com Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa SNAP is not 'our' protocol, any more than 802.2 is ours. We don't have any contorl over it. If we had wanted to avoid this mess, we (sigh) should have been on 802.2. AS I noted, vendors are already using SNAP. The reason that the code is 3 bytes of owner, and two of protocol number, is that they can then use the already-allocated 24-bit prefixes that define 48-bit address blocks. Hey, 48-bits is absurdly long, also. I think that running a datagram network protocol like IP over class 2 802.2 is a non-sequitor, so we don't need to worry about it. I will admit that I can't see how SNAP would work with class 2 at all. In the ISO world, class 1 is used with connectionless internet at the network level, and class 2 with a null network layer. john shriver proteon ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986090714125601> Received: from brubeck.proteon.com by SRI-NIC.ARPA with TCP; Sun 7 Sep 86 15:23:39-PDT Date: Sun, 7 Sep 86 18:12:56 EDT From: jas@brubeck.proteon.com Reply-to: jas@proteon.com Subject: Re: re: How to IP & ARP on 802 nets In-reply-to: Your message of Wed, 3 Sep 86 23:45 PDT To: Provan@LLL-MFE.ARPA CC: tcp-ip@sri-nic.arpa SNAP is not 'our' protocol, any more than 802.2 is ours. We don't have any contorl over it. If we had wanted to avoid this mess, we (sigh) should have been on 802.2. AS I noted, vendors are already using SNAP. The reason that the code is 3 bytes of owner, and two of protocol number, is that they can then use the already-allocated 24-bit prefixes that define 48-bit address blocks. Hey, 48-bits is absurdly long, also. I think that running a datagram network protocol like IP over class 2 802.2 is a non-sequitor, so we don't need to worry about it. I will admit that I can't see how SNAP would work with class 2 at all. In the ISO world, class 1 is used with connectionless internet at the network level, and class 2 with a null network layer. john shriver proteon ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12237313497.45.JNC%40XX.LCS.MIT.EDU] <1986090807304300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JNC@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Gateway Selection Procedure Message-ID: <12237313497.45.JNC@XX.LCS.MIT.EDU> Date: Mon, 8-Sep-86 11:30:43 EDT Article-I.D.: XX.12237313497.45.JNC Posted: Mon Sep 8 11:30:43 1986 Date-Received: Tue, 9-Sep-86 20:45:39 EDT References: <8609041457.AA08219@mitre.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa The answer to the first question you ask is contained in two RFC's in the TCP/IP guide; I don't remember which volume they are in in the white books, but they are RFC's 814 and 816, "Names, Addresses, Ports and Routes", and "Fault Isolation and Recovery". I don't want to sound like a broken record, but I wish people would read the documentation provided before asking questions. I am aware that those books contain a lot of material: perhaps the NIC could include a 'Suggested Readings' list in the next printing which would list RFC's 813-817 as 'Required'? The second question is sort of covered by RFC's 904 and 888, which describe the current Internet model for routing packets among gateways. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609090850.AA19964%40ucbvax.Berkeley.EDU] <1986090812480000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MAB@CORNELLC.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Anybody Have Code for an Echo Host? Message-ID: <8609090850.AA19964@ucbvax.Berkeley.EDU> Date: Mon, 8-Sep-86 16:48:00 EDT Article-I.D.: ucbvax.8609090850.AA19964 Posted: Mon Sep 8 16:48:00 1986 Date-Received: Tue, 9-Sep-86 20:46:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa At the TCP/IP Vendor's Workshop in Monterey, mention was made of a beast called an "Echo Host". As I understand it, this is a tool for shaking out a host implementation of TCP/IP. It simply echoes IP datagrams, with controls for delay, bandwidth, and error rate. Does anyone have code for an Echo Host? In particular for an IBM PC? Also, mention was made at the workshop of the existence of a How-To- Build-An-Echo-Host RFC. I can't find it - can someone tell me the number? My Internet address is: mab%cornellc.bitnet@wiscvm.wisc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986090812480001> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Mon 8 Sep 86 14:21:23-PDT Received: from (MAL)CORNELLC.BITNET by WISCVM.WISC.EDU on 09/08/86 at 16:19:32 CDT Received: by CORNELLC (Mailer X1.23b) id 7301; Mon, 08 Sep 86 17:18:02 EDT Date: Mon, 8 Sep 1986 16:48 EDT From: Mark Bodenstein Subject: Anybody Have Code for an Echo Host? To: At the TCP/IP Vendor's Workshop in Monterey, mention was made of a beast called an "Echo Host". As I understand it, this is a tool for shaking out a host implementation of TCP/IP. It simply echoes IP datagrams, with controls for delay, bandwidth, and error rate. Does anyone have code for an Echo Host? In particular for an IBM PC? Also, mention was made at the workshop of the existence of a How-To- Build-An-Echo-Host RFC. I can't find it - can someone tell me the number? My Internet address is: mab%cornellc.bitnet@wiscvm.wisc.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12237409419.38.MDCG.HRD%40OZ.AI.MIT.EDU] <1986090816173800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MDCG.HRD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU ("Hank R. "Jim" Dixon") Newsgroups: mod.protocols.tcp-ip Subject: X25 implementations Message-ID: <12237409419.38.MDCG.HRD@OZ.AI.MIT.EDU> Date: Mon, 8-Sep-86 20:17:38 EDT Article-I.D.: OZ.12237409419.38.MDCG.HRD Posted: Mon Sep 8 20:17:38 1986 Date-Received: Tue, 9-Sep-86 21:53:26 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Hello, does anybody happen to know about any exsisting implkementations for X25 on the VAX under either VMS (preferably) or UNIX?? Thank you. JIM ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609090044.AA00979%40ames-nasb.arpa] <1986090816440400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lekash@AMES-NASB.ARPA (John Lekashman) Newsgroups: mod.protocols.tcp-ip Subject: hyperchannel and IP Message-ID: <8609090044.AA00979@ames-nasb.arpa> Date: Mon, 8-Sep-86 20:44:04 EDT Article-I.D.: ames-nas.8609090044.AA00979 Posted: Mon Sep 8 20:44:04 1986 Date-Received: Wed, 10-Sep-86 01:24:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa Hi there. two things: 1. I've been doing some work on an NSC hyperchannel device driver. I started with what was working on 4.2, and with help from Mike Karels at Berkeley, have got it working on 4.3 unix. Its available on ames-nasb in /usr/ftp, including 4.3 kernel changes, (to support raw access) cray research's cxint (yuk!) and hyroute (also yuk!) 2. While getting this working, I found many things about how it functions in need of repair or improvement. I am interested in starting a mailing list of people who use hyperchannels on IP nets. I want to see some sort of standard about encapsulation, routing, and raw access. We spent a great deal of time wretching about all sorts of things here, and finally everyone just copied what cray research had given us, since getting them to change was the hardest. If no one else is currently running such a list, I will. I have created hy-people, and hy-people-request at ames-nasb.arpa (orville). thank you, john ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609082208.AA21654%40mitre-bedford.ARPA] <1986090902552200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cel@MITRE-BEDFORD.ARPA Newsgroups: mod.protocols.tcp-ip Subject: NETBIOS ISSUE---TCP Handoffs Message-ID: <8609082208.AA21654@mitre-bedford.ARPA> Date: Tue, 9-Sep-86 06:55:22 EDT Article-I.D.: mitre-be.8609082208.AA21654 Posted: Tue Sep 9 06:55:22 1986 Date-Received: Tue, 9-Sep-86 21:53:10 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Bedford, MA Lines: 85 Approved: tcp-ip@sri-nic.arpa At the NETBIOS-TCP/IP Interface Specification Forum held Aug 28 in Monterey, CA two proposals were discussed. A major issue revolved around the capability of some operating systems to support handoff of TCP connections from one process to another. Are there problems in handing a TCP connection from one process to another for some operating systems? Which operating systems have difficulty? Please mail comments to netbios@mitre-bedford.arpa. The problem in the context of the NETBIOS issue is described below. Assume two hosts, one contains a client application program and the other contains a server application program. the problem is to establish a session between the programs (message oriented, no loss or duplication). The hosts contain NETBIOS agents for their respective application programs to interpret the various NETBIOS commands. Also assume that the server host contains a NETBIOS validation program that verifies if two NETBIOS named application programs may communicate. Exchanges may occur between the client and validation programs via UDP messages as in proposal one or over a TCP connection as another proposal. Data passed over a session between application programs occurs over a TCP connection. One proposal (figure A below) calls for passing all session control information via UDP messages between the NETBIOS client program located in the source host and the NETBIOS validation program in the destination host. The NETBIOS Name service has provided the IP address of the server host. The validation pgm is accessed through a TCP well known port (wkp). If the session is valid (a server application has posted a NETBIOS listen for c-name) then the server program does a fully specified TCP passive open using s-port, c-port and the IP addresses. The client program then establishes a TCP connection to the server program using s-port, c-port, and the IP addresses. No handoff of a TCP connection between the validation program and the server program is required. Figure A: NETBIOS Names Passed via UDP CLIENT SERVER Validation pgm does UDP(c-name, s-name, c-port)-------> UDP wkp listen to any (timeout) agent pgm does TCP <--------------UDP(s-port)--------- fully spec passive open on s-port,c-port (timeout) TCP(s-port) SYN ------------------> TCP conn established to NETBIOS agent <---------------------SYN--------- <-------------data----------------> etc. Another proposal (figure B below) calls for the client to determine the server's TCP port (s-port) via the NETBIOS Name service. Meanwhile the NETBIOS validation program posted a TCP partially specified passive open (ppo) open on s-port due to a NETBIOS LISTEN issued by an application program. The client program then establishes a TCP connection to the client validation program and passes session control information (c-name,s-name) over the connection. If the session is valid between the two NETBIOS named applications, then the TCP connection is handed off to the server agent program. If the session is rejected then the TCP connection is broken. Figure B: NETBIOS Names Passed via TCP Connection CLIENT SERVER Validation pgm does TCP ppo on s-port TCP(s-port) SYN-----------------> <---------------------------SYN-- ------data(c-name, s-name)------> Validate and handoff TCP conn to server agent pgm (timeout) <----------data(ack, nack)------- <----------data-----------------> etc. Thanks, ---- Lee LaBarre ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986090904230000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 9 Sep 86 05:24:45-PDT Date: 9 Sep 1986 08:23-EDT Sender: CERF@A.ISI.EDU Subject: Re: X25 implementations From: CERF@A.ISI.EDU To: MDCG.HRD%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Cc: tcp-ip@SRI-NIC.ARPA Cc: jsol%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Message-ID: <[A.ISI.EDU] 9-Sep-86 08:23:25.CERF> In-Reply-To: <12237409419.38.MDCG.HRD@OZ.AI.MIT.EDU> Digital has a package called PSI (Version 4.0) which allows VMS to make use of X.25 networks. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986090904370000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 9 Sep 86 05:37:54-PDT Date: 9 Sep 1986 08:37-EDT Sender: CERF@A.ISI.EDU Subject: Formatting Query From: CERF@A.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 9-Sep-86 08:37:01.CERF> I apologize for the broadcast, but I wonder if I am the only recipient of TCP-IP distribution list messages troubled by receipt of messages containing naked horizontal tabs (control-I characters)? It is generally difficult to properly reconstruct the tab settings for presentation. If this is not just a local problem, perhaps we could agree to expand tabs before submitting messages to TCP-IP distribution to improve matters until someday we have a common document representation format which can include adivce about tab settings automatically. I recognize that such a proposal runs the risk of increasing the total length of messages but perhaps this is a small price to pay for improved communication. Is anyone else out there having similar difficulties? Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609111037.AA24771%40ucbvax.Berkeley.EDU] <1986090910402900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ahill@CC7.BBN.COM ("Alan R. Hill") Newsgroups: mod.protocols.tcp-ip Subject: re: imprecise DDN X.25 specification? Message-ID: <8609111037.AA24771@ucbvax.Berkeley.EDU> Date: Tue, 9-Sep-86 14:40:29 EDT Article-I.D.: ucbvax.8609111037.AA24771 Posted: Tue Sep 9 14:40:29 1986 Date-Received: Thu, 11-Sep-86 21:16:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa George, As Dr. Cerf already pointed out, the concerns you have are valid and will definitely affect the ability of the CDC interface to communicate with the DDN Standard Service. I cannot comment on the relationship between DCA Qualification and an ability to communicate effectively using the DDN but I can offer some information on what the BBN packet switch does during use of Standard Service. Standard Service will process an X.25 call by removing its X.25 transport envelope and using the contents to generate an 1822L envelope. Standard Service allows only one VC per triplet of , , and . Unfortunately, I believe each of your issues will prevent communication with the DDN. I would like to hear suggestions about areas for improvements in the specification or the DCA Qualification. Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986090910402901> Received: from cc7.bbn.com by SRI-NIC.ARPA with TCP; Tue 9 Sep 86 12:56:55-PDT Date: Tue, 9 Sep 86 14:40:29 EDT From: "Alan R. Hill" Subject: re: imprecise DDN X.25 specification? To: klem@brl.arpa Cc: tcp-ip@sri-nic.arpa George, As Dr. Cerf already pointed out, the concerns you have are valid and will definitely affect the ability of the CDC interface to communicate with the DDN Standard Service. I cannot comment on the relationship between DCA Qualification and an ability to communicate effectively using the DDN but I can offer some information on what the BBN packet switch does during use of Standard Service. Standard Service will process an X.25 call by removing its X.25 transport envelope and using the contents to generate an 1822L envelope. Standard  Service allows only one VC per triplet of , , and . Unfortunately, I believe each of your issues will prevent communication with the DDN. I would like to hear suggestions about areas for improvements in the specification or the DCA Qualification. Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609092022.aa18976%40SEM.BRL.ARPA] <1986090916222600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mike@BRL.ARPA (Mike Muuss) Newsgroups: mod.protocols.tcp-ip Subject: Re: Formatting Query Message-ID: <8609092022.aa18976@SEM.BRL.ARPA> Date: Tue, 9-Sep-86 20:22:26 EDT Article-I.D.: SEM.8609092022.aa18976 Posted: Tue Sep 9 20:22:26 1986 Date-Received: Thu, 11-Sep-86 08:42:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa I though there was general agreement that tab stops were every 8 characters? I don't know if this is official NETASCII, but since TOPS-20, UNIX, and VMS all do it this way, most systems go along. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609092103.aa19300%40SEM.BRL.ARPA] <1986090917035700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jcp@BRL.ARPA (Joe Pistritto, JHU|mike) Newsgroups: mod.protocols.tcp-ip Subject: VMS TCP/IP over Ethernet? Message-ID: <8609092103.aa19300@SEM.BRL.ARPA> Date: Tue, 9-Sep-86 21:03:57 EDT Article-I.D.: SEM.8609092103.aa19300 Posted: Tue Sep 9 21:03:57 1986 Date-Received: Thu, 11-Sep-86 08:46:12 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa I'm working on upgrading a site that currently runs VMS on its Vaxen to running 4.3 (at least most of the time), and the issue of communications has come up. Presently, there is nothing, so the slate is clean. I'm thinking of getting some of the Interlan (MICOM) smart ethernet controllers, and running their VMS TCP/IP package on one machine, with 4.3 on the others. Has anyone else come up against the problem of needing hardware that is both VMS and UNIX compatable, (so that either machine can be used for either system), and found a better (more cost effective) solution? The Interlan folks claim to have FTP and TELNET implemented under VMS, I have also checked out Wollongong, any others out there I've missed? Were not Government or educational, so I don't think the Tektronix code is available. -JCP- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12237805685.21.MRC%40SIMTEL20.ARPA] <1986091004342400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC@SIMTEL20.ARPA (Mark Crispin) Newsgroups: mod.protocols.tcp-ip Subject: Re: Formatting Query Message-ID: <12237805685.21.MRC@SIMTEL20.ARPA> Date: Wed, 10-Sep-86 08:34:24 EDT Article-I.D.: SIMTEL20.12237805685.21.MRC Posted: Wed Sep 10 08:34:24 1986 Date-Received: Thu, 11-Sep-86 08:46:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa Vint - So far as I know Multics is the only operating system in common use on the Internet which does not use tab stops at every 8th character. My experience suggests that it is basically hopeless in a true heterogenous environment to use tab stops at any other position due to the large number of terminals which do not offer settable tab stops. I admit that "8 tabs" are hopelessly hacker oriented and probably aren't santioned by any standard, but c'est la vie. Many of the Internet protocols are hopelessly hacker oriented. I'm sure ISO will "improve" this situation; I have no way of telling if ISO will do anything to improve it though. If you read your mail at A.ISI.EDU (as opposed to having some agent pick it up and pass it on to your real mailbox), you should know that A.ISI.EDU is a TOPS-20 system and TOPS-20 uses 8 tabs exclusively. Tenex had programmable tabs, but this functionality was deleted in TOPS-20. Therefore, it is correct that any terminal connected to a TOPS-20 system should use 8 tabs. I think the same is true for Unix and VAX/VMS. If not I'm sure I'll receive 1000 messages telling me what an idiot I am... -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12237885182.55.AI.CLIVE%40MCC.COM] <1986091011510500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AI.CLIVE@MCC.COM (Clive Dawson) Newsgroups: mod.protocols.tcp-ip Subject: DELNI Strangeness Message-ID: <12237885182.55.AI.CLIVE@MCC.COM> Date: Wed, 10-Sep-86 15:51:05 EDT Article-I.D.: MCC.12237885182.55.AI.CLIVE Posted: Wed Sep 10 15:51:05 1986 Date-Received: Thu, 11-Sep-86 21:17:09 EDT Sender: kjd@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Here's a bit of info to add to the general folklore: We moved to a new building last week, and after putting everything back together, we found that TELNET connections from our Sun workstations to our DEC-20 (they're on separate Ethernets, gateway is a Sun) were suffering from horribly poor throughput. Echo delays ranged from 1 to 10 seconds, with no load to speak of on any of the systems or the nets. After being stumped for a couple of days, we finally realized that the only thing that had changed was that the Sun gateway and the DEC-20 were now sharing the same DELNI, whereas before they had been on two different DELNIs. We made a quick switch and put the Sun onto its own transceiver two meters away from the DELNI's transceiver. The results were immediate and dramatic. Echoing delays disappeared completely and users were once again happy. Now the obvious question: Does anybody have an explanation? Is there something fundamentally different about intra-DELNI communication that could cause such enormous performance problems? Thanks, Clive ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609091811.AA19039%40mitre-bedford.ARPA] <1986091012382100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cel@MITRE-BEDFORD.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Postponement of NETBIOS Meeting Message-ID: <8609091811.AA19039@mitre-bedford.ARPA> Date: Wed, 10-Sep-86 16:38:21 EDT Article-I.D.: mitre-be.8609091811.AA19039 Posted: Wed Sep 10 16:38:21 1986 Date-Received: Thu, 11-Sep-86 07:31:47 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Bedford, MA Lines: 9 Approved: tcp-ip@sri-nic.arpa The NETBIOS meeting scheduled for Sept 29 at Stanford has been postponed. A new meeting date has yet to be selected. The package containing the proposals, slide copies and issue discussions is still being prepared. It will be sent to the participants of the Aug 28 meeting in Monterey, CA. Lee LaBarre ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609102019.aa02505%40SEM.BRL.ARPA] <1986091016191700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mike@BRL.ARPA (Mike Muuss) Newsgroups: mod.protocols.tcp-ip Subject: Re: VMS TCP/IP over Ethernet? Message-ID: <8609102019.aa02505@SEM.BRL.ARPA> Date: Wed, 10-Sep-86 20:19:17 EDT Article-I.D.: SEM.8609102019.aa02505 Posted: Wed Sep 10 20:19:17 1986 Date-Received: Thu, 11-Sep-86 21:21:55 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa For VMS, also consider the Excelan board in smart mode, and maybe the CMC people have a VMS offering too? -M ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860911105756.257559%40RADC-MULTICS.ARPA] <1986091102570000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Walker@RADC-MULTICS.ARPA ("Robert K. Walker 'Bob'") Newsgroups: mod.protocols.tcp-ip Subject: Re: Formatting Query Message-ID: <860911105756.257559@RADC-MULTICS.ARPA> Date: Thu, 11-Sep-86 06:57:00 EDT Article-I.D.: RADC-MUL.860911105756.257559 Posted: Thu Sep 11 06:57:00 1986 Date-Received: Thu, 11-Sep-86 21:26:43 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa Date: 9 September 1986 20:22 edt From: Mike Muuss Subject: Re: Formatting Query I though there was general agreement that tab stops were every 8 characters? I don't know if this is official NETASCII, but since TOPS-20, UNIX, and VMS all do it this way, most systems go along. -Mike Tab stops every 8 characters may be the convention for DEC equipment, which was what was mentioned. However, the Multics convention is every 10 characters. I have FTP'ed files from DEC machines with the tab codes present, only to get a very ragged looking format when it is interpretted by Multics. This is a nuisance. -Bob Walker- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609091740.AA17287%40mitre-bedford.ARPA] <1986091107201400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cel@MITRE-BEDFORD.ARPA Newsgroups: mod.protocols.tcp-ip Subject: NETBIOS ISSUES -- Datagram service Message-ID: <8609091740.AA17287@mitre-bedford.ARPA> Date: Thu, 11-Sep-86 11:20:14 EDT Article-I.D.: mitre-be.8609091740.AA17287 Posted: Thu Sep 11 11:20:14 1986 Date-Received: Thu, 11-Sep-86 21:40:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Bedford, MA Lines: 57 Approved: tcp-ip@sri-nic.arpa At the Aug 28 NETBIOS meeting in Monterey, CA two proposals for implementing NETBIOS on TCP/IP were discussed. One of the areas in which these proposals differ pertained to the NETBIOS datagram service. The essence of the differences relative to this area is outlined below. We would appreciate your comments about the relative merits and implementation feasibility/difficulty of the alternative proposals to accomplish datagram service. Please send your comments to: netbios@mitre-bedford.arpa (NOTE: In both proposals IP datagrams are not broadcast out on the internet, i.e. WAN.) First Proposal a) Use NETBIOS Name service to discover target UDP port and IP address Since a name cache is assumed to be at each node, only infrequently would name queries result in traffic on the channel. b) Datagrams sent to a unique name are sent as directed UDP datagrams with control info and data contained within. c) Datagrams sent to a group name or broadcast use IP subnet broadcast Second Proposal a) All NETBIOS datagrams would be IP subnet broadcast UDP datagrams. No name lookup is required. b) UDP datagrams would contain control info and data ISSUES 1. Is the first proposal's assumption of a name cache good? (note: IBM's PC Network uses a cache at each node) NOTE: If a name cache is not used then each NETBIOS datagram would result in a broadcast name query, one or more responses and the directed UDP containing the NETBIOS datagram. All hosts would have to process the name query. 2. Proposal two would require all hosts on the subnet to process the IP datagrams - even those not using NETBIOS. The assumption here is that the NETBIOS datagram service is infrequently used and thus hosts that are not the intended recipient would not be overly burdened. Is infrequent use of directed NETBIOS datagrams a good assumption? Are slow listeners going to miss datagrams? Thanks --- Lee LaBarre ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860911160927.755905%40RADC-MULTICS.ARPA] <1986091108090000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Ata@RADC-MULTICS.ARPA ("John G. Ata") Newsgroups: mod.protocols.tcp-ip Subject: Re: Formatting Query Message-ID: <860911160927.755905@RADC-MULTICS.ARPA> Date: Thu, 11-Sep-86 12:09:00 EDT Article-I.D.: RADC-MUL.860911160927.755905 Posted: Thu Sep 11 12:09:00 1986 Date-Received: Fri, 12-Sep-86 19:50:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa I think the point is being missed here with regard to tab stops. If everyone on the network interpreted tabs the same way, this transaction would never have been started. Since there is variation on tab interpretation, it would seem that if the SMTP mailers expanded the tabs to the appropiate number of spaces, then compatability would be assured. The only negative effect of this might be to people who FTP files via mail, and who might not get exactly the same file on the other side. However, they might wish to to use FTP instead... John G. Ata ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609111837.AA08019%40ucbarpa.Berkeley.EDU] <1986091110371600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes) Newsgroups: mod.protocols.tcp-ip Subject: Re: Formatting Query Message-ID: <8609111837.AA08019@ucbarpa.Berkeley.EDU> Date: Thu, 11-Sep-86 14:37:16 EDT Article-I.D.: ucbarpa.8609111837.AA08019 Posted: Thu Sep 11 14:37:16 1986 Date-Received: Thu, 11-Sep-86 22:42:39 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa From: "John G. Ata" Since there is variation on tab interpretation, it would seem that if the SMTP mailers expanded the tabs to the appropiate number of spaces, then compatability would be assured. Wow, did this come out of left field or am I really missing something? I don't really think you want to do this ... /jordan ps: maybe a better way of looking at tabs is like those stupid vt100 escape sequences that lock up my terminal, but give an vt100'er double width characters ... pss: all you UNIX'ers out there using Mail can do a ~|expand just before hitting ^D to end your message ... I did this for this message -- how does it look to you Multics'ers? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860911192057.769497%40MIT-MULTICS.ARPA] <1986091111200000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JSLove@MIT-MULTICS.ARPA ("J. Spencer Love") Newsgroups: mod.protocols.tcp-ip Subject: Multics TABs Message-ID: <860911192057.769497@MIT-MULTICS.ARPA> Date: Thu, 11-Sep-86 15:20:00 EDT Article-I.D.: MIT-MULT.860911192057.769497 Posted: Thu Sep 11 15:20:00 1986 Date-Received: Fri, 12-Sep-86 07:31:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa Are, as several have noted, every 10 columns. It is the position of the Multics mailer developers that TAB characters should never be sent over the network, since there is no "standard" width. Thus, all outgoing mail is detabbified, at some slight cost in network throughput. Mail coming in is also detabbified, which affects only non-Multics mail, since there are no tabs in mail leaving Multics. This detabbification *ought* to assume tabs every 8 columns, since this is the de-facto standard. That it doesn't is a bug (to be fair, if the mailer developer had agreed with me, this problem would never have arisen). None of this helps FTP users, since FTP does no TAB transformations. There is, however, a Multics command, "canonicalize", which can insert and remove TAB characters assuming any TAB width, which helps out in some situations. There are other TAB widths in use. I think that Magic 6 uses (used?) a width of 5. The width of 8 is pretty consistent across DEC equipment, but there are other manufacturers out there. There didn't seem to be any consistent use of TABs at all in IBM program products, last I checked. Anyone out there using non-DEC and non-Honeywell gear? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12238144422.50.ROODE%40IC2060] <1986091111350800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROODE%BIONET@SUMEX-AIM.STANFORD.EDU (David Roode) Newsgroups: mod.protocols.tcp-ip Subject: DELNI characteristics Message-ID: <12238144422.50.ROODE@IC2060> Date: Thu, 11-Sep-86 15:35:08 EDT Article-I.D.: IC2060.12238144422.50.ROODE Posted: Thu Sep 11 15:35:08 1986 Date-Received: Fri, 12-Sep-86 07:32:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa We have noticed that DELNI's have some non-intuitive limitations on cable length. Could this perhaps have some bearing on your problem? Unlike other multiport transceivers, the rule for DELNI's is that the transceiver cable length limitation of 40m (vs. 50m for other devices) applies to the sum of lengths of the drop to the DELNI and the drop from the DELNI to the host system. It is also against the rules to plug one DELNI into another one unless that DELNI is NOT connected to an Ether. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.leong.0.leong.249.0%40andrew.cmu.edu] <1986091115583600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leong@andrew.cmu.edu (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: Re: DELNI Strangeness Message-ID: Date: Thu, 11-Sep-86 19:58:36 EDT Article-I.D.: andrew.MS.leong.0.leong.249.0 Posted: Thu Sep 11 19:58:36 1986 Date-Received: Fri, 12-Sep-86 08:42:33 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Clive, I don't really know what specifically is your problem with the DELNI. However, one thing you may care to check is this : The DELNI (and for that matter, almost all multiport tranceiver in the market) does not handle "heart beat" correctly. For all practical purposes, heart beat is a kind of acknowledgment from the tranceiver to the station. Within a very short period of time after the tranceiver finished sending the packet into the coax cable, it issue a heart beat signal on the collision pairs of the tranceiver cable - essentially saying "all's well". In the case of the DELNI, this signal is (mistakenly) fanned out to ALL attached stations. The station doing the transmit will know it is a heart beat. However, the other attached stations will treat it as an asynchonous collision notification. Most station will ignore it but I don't know about the DEC-20. However, definitely, do not attached a repeater to a DELNI. Repeater will not toss away heart beat. It will act on it and generate collision reinforcement (jam) on the other side!!! The result is excessive collisions. Very bad news to the overall band width availability. John Leong . ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986091206195700> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Fri 12 Sep 86 20:22:29-PDT Received: from (MAILER)UIUCVMD.BITNET by WISCVM.WISC.EDU on 09/12/86 at 11:32:03 CDT Received: by UIUCVMD (Mailer X1.23) id 3493; Fri, 12 Sep 86 11:23:15 CDT Date: Fri, 12 Sep 86 11:19:57 CDT From: Phil Howard Subject: Tabs every 8 positions To: TCP/IP List Gee, even IBM has acknowledged that tabs belong on every 8 positions. In VM/SP/CMS's XEDIT is the EXPAND subcommand that expands out the tabs to proper positions. There is also COMPRESS with puts tabs in, and in the proper place. I use these commands to handle files received from non-IBM systems with tabs. Everything has worked out fine. Now I just need a way to get square brackets on my IBM 3178 keyboard. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609121532.AA19724%40mitre-bedford.ARPA] <1986091207320500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jtw@mitre-bedford.ARPA (Welch) Newsgroups: mod.protocols.tcp-ip Subject: RFC 912, Auth Service Message-ID: <8609121532.AA19724@mitre-bedford.ARPA> Date: Fri, 12-Sep-86 11:32:05 EDT Article-I.D.: mitre-be.8609121532.AA19724 Posted: Fri Sep 12 11:32:05 1986 Date-Received: Sat, 13-Sep-86 05:00:11 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Bedford, MA Lines: 9 Approved: tcp-ip@sri-nic.arpa I am interested in finding out whether anyone has either implemented or has comments on the authentication protocol outlined in RFC 912, "Authentication Service". Any pointers or info would be appreciated. Jim Welch jtw@mitre-bedford ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986091207481400> Received: from cu-arpa.cs.cornell.edu by SRI-NIC.ARPA with TCP; Fri 12 Sep 86 08:54:16-PDT Received: by cu-arpa.cs.cornell.edu (5.45/4.30) id AA01937; Fri, 12 Sep 86 11:48:38 EDT Date: Fri, 12 Sep 86 11:48:14 EDT From: hurf@tcgould.tn.cornell.edu (Hurf Sheldon) Message-Id: <8609121548.AA14329@tcgould.tn.cornell.edu> Received: by tcgould.tn.cornell.edu (5.31/4.30) id AA14329; Fri, 12 Sep 86 11:48:14 EDT Newsgroups: mod.protocols.tcp-ip,,arpa.protocols.tcp-ip Subject: Ultrix1.2 to HPUX problem Reply-To: batcomputer!hurf@cu-arpa.cs.cornell.edu (Hurf Sheldon) Organization: Theory Center, Cornell University, Ithaca NY Keywords: HP9000/300 Ultrix uVaxII Apparently-To: tcp-ip@sri-nic.arpa We recently connected a VaxstationII & an HP9000/300 via a delni & after getting the uvax setup correctly we then used the network setup program on the HP to set it up. What we get now is complete access from the HP to the uvax but from the uvax to the HP we get "connection refused" under telnet & just "time outs" on ftp & rlogin. We have set up the host tables on the uvax for some more HP's not yet connected & when we try to go to them we get a "host unreachable" so we believe the HP is recognizing it's address correctly but won't answer. We have Ultrix1.2 on the uvax & HPUX on the HP. The uvax is set "broadcast -trailers netmask 0xffffff00" - must be set this way to conform to local cornell net standards. Any & all suggestions appreciated. Hurf Sheldon Arpa.css: Hurf@ionvax.tn.cornell.edu Lab of Plasma Studies 369 Upson Hall phone: 607 255 7267 Cornell University Ithaca, N.Y. 14853 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986091207543600> Received: from cu-arpa.cs.cornell.edu by SRI-NIC.ARPA with TCP; Fri 12 Sep 86 09:56:23-PDT Received: by cu-arpa.cs.cornell.edu (5.45/4.30) id AA01968; Fri, 12 Sep 86 11:55:00 EDT Date: Fri, 12 Sep 86 11:54:36 EDT From: hurf@tcgould.tn.cornell.edu (Hurf Sheldon) Message-Id: <8609121554.AA14544@tcgould.tn.cornell.edu> Received: by tcgould.tn.cornell.edu (5.31/4.30) id AA14544; Fri, 12 Sep 86 11:54:36 EDT Newsgroups: arpa.tcp-ip Subject: Ultrix to HPUX problems Reply-To: batcomputer!hurf@cu-arpa.cs.cornell.edu (Hurf Sheldon) Distribution: na Organization: Theory Center, Cornell University, Ithaca NY Keywords: HP9000/300 Ultrix uVaxII Apparently-To: tcp-ip@sri-nic.arpa We recently connected a VaxstationII & an HP9000/300 via a delni & after getting the uvax setup correctly we then used the network setup program on the HP to set it up. What we get now is complete access from the HP to the uvax but from the uvax to the HP we get "connection refused" under telnet & just "time outs" on ftp & rlogin. We have set up the host tables on the uvax for some more HP's not yet connected & when we try to go to them we get a "host unreachable" so we believe the HP is recognizing it's address correctly but won't answer. We have Ultrix1.2 on the uvax & HPUX on the HP. The uvax is set "broadcast -trailers netmask 0xffffff00" - must be set this way to conform to local cornell net standards. Any & all suggestions appreciated. Hurf Sheldon Arpa.css: Hurf@ionvax.tn.cornell.edu Lab of Plasma Studies 369 Upson Hall phone: 607 255 7267 Cornell University Ithaca, N.Y. 14853 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609132051.AA06983%40ucbvax.Berkeley.EDU] <1986091207580000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Chartoff@DDN2.ARPA Newsgroups: mod.protocols.tcp-ip Subject: DECNET Message-ID: <8609132051.AA06983@ucbvax.Berkeley.EDU> Date: Fri, 12-Sep-86 11:58:00 EDT Article-I.D.: ucbvax.8609132051.AA06983 Posted: Fri Sep 12 11:58:00 1986 Date-Received: Sun, 14-Sep-86 04:07:44 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa I am looking for interface products that would allow DECNET communication across the Arpanet/Milnet or a public data network (PDN). Has anyone had experience with such products and want to give advice? Thanks ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986091207580001> Received: from ddn2 by SRI-NIC.ARPA with TCP; Fri 12 Sep 86 09:16:18-PDT Date: 12 Sep 86 11:58 EDT From: Chartoff @ DDN2 Subject: DECNET To: tcp-ip @ sri-nic.arpa CC: Chartoff @ DDN2 I am looking for interface products that would allow DECNET communication across the Arpanet/Milnet or a public data network (PDN). Has anyone had experience with such products and want to give advice? Thanks ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609132157.AA08382%40ucbvax.Berkeley.EDU] <1986091208195700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PHIL@UIUCVMD.BITNET (Phil Howard) Newsgroups: mod.protocols.tcp-ip Subject: Tabs every 8 positions Message-ID: <8609132157.AA08382@ucbvax.Berkeley.EDU> Date: Fri, 12-Sep-86 12:19:57 EDT Article-I.D.: ucbvax.8609132157.AA08382 Posted: Fri Sep 12 12:19:57 1986 Date-Received: Sun, 14-Sep-86 04:00:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Gee, even IBM has acknowledged that tabs belong on every 8 positions. In VM/SP/CMS's XEDIT is the EXPAND subcommand that expands out the tabs to proper positions. There is also COMPRESS with puts tabs in, and in the proper place. I use these commands to handle files received from non-IBM systems with tabs. Everything has worked out fine. Now I just need a way to get square brackets on my IBM 3178 keyboard. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609121648.AA10394%40utah-cs.ARPA] <1986091208482100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cetron@UTAH-CS.ARPA (Edward J Cetron) Newsgroups: mod.protocols.tcp-ip Subject: Re: DELNI characteristics Message-ID: <8609121648.AA10394@utah-cs.ARPA> Date: Fri, 12-Sep-86 12:48:21 EDT Article-I.D.: utah-cs.8609121648.AA10394 Posted: Fri Sep 12 12:48:21 1986 Date-Received: Sun, 14-Sep-86 04:07:56 EDT References: <12238144422.50.ROODE@IC2060> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: utah-cs!cetron (Edward J Cetron) Organization: Center for Engineering Design, Univ of Utah Lines: 40 Approved: tcp-ip@sri-nic.arpa David Roode writes: >It is also against the rules to plug one DELNI into another one >unless that DELNI is NOT connected to an Ether[net]. WRONG!!!!!!!!!!!!!!!! Nowhere does it say that one DELNI cannot be cascaded to another ethernet connected DELNI! And I've check every manual, tech and sales, Digital has produced.... The above is a very common misconception...the real configuration rule has to do with the fact the propagation delays build through the ethernet having to do with things like cable lengths, numbers of repeaters etc.... The one rule that is most apropos is the 'no more than two repeaters between any two nodes....' This is (among other things) to prevent the propagation delay between any two nodes to be less than the max... For very conservative purposes, the DELNI acts with a propagation delay of 1 repeater and this sort of implies the above misconception. In reality: 1. A DELNI actually appears to introduce the delay of about .6-.7 that of a repeater. 2. I have seen systems with 2, 3, and 4 cascaded DELNI's that work and DO maintain in-spec propagation delays. 3. It has been pointed out that with the appropriate configuration, one could even make 4 repeaters in a row work. 4. The configuration rules (like the rs232 max line length rules) are very conservative to allow 100% probability of a network working when they are strictly adhered to. This means that quite often, for networks not in a very critical area (i.e. hospital ICU's controlling patient therapy) they are only to be considered guidelines BY PEOPLE WHO UNDERSTAND WHY THE RULES ARE THERE. Rules are there for a reason, but should be tested and verified before blindly obeying them without knowing why -ed cetron Center for Engineering Design Univ of Utah cetron%utah-cbd@utah-cs.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609121649.AA05920%40bu-cs.bu.edu] <1986091208490100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: root@BU-CS.BU.EDU (Ra) Newsgroups: mod.protocols.tcp-ip Subject: Re: Formatting Query Message-ID: <8609121649.AA05920@bu-cs.bu.edu> Date: Fri, 12-Sep-86 12:49:01 EDT Article-I.D.: bu-cs.8609121649.AA05920 Posted: Fri Sep 12 12:49:01 1986 Date-Received: Sun, 14-Sep-86 04:02:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 35 Approved: tcp-ip@sri-nic.arpa To add my 2c: 1. I am not sure about the definition of "commonly used" but IBM Mainframes (EBCDIC) generally do not interpret tabs the way full-duplex systems use them (not that you can't simulate them, but it tends to be more variable in interpretation, if at all, software application dependant.) 2. Sending files through mail via heterogenous systems is fraught with peril although it usually works well enough if it's just text meant to be used as text (eg. a fortran program with embedded tabs may not compile at all when sent to an IBM system, I don't remember for sure, but I wouldn't be in the slightest bit shocked, and fixing it wouldn't take that much sophistication on the part of the user.) A solution is the UUENCODE/UUDECODE program distributed with UNIX (there are public domain versions) which encodes files in a very conservative way (more or less 026 character subset, 40 chars/line.) For example, I have a version of it running on our IBM mainframe and it seems to work, particularly for cases as above (yes, I expand tabs to every eight, perhaps that should be an option, but at least it's all at the user level rather than a decision made by the SMTP daemon.) Obviously with binary files there's not much you can do, but you could pass one THROUGH an incompatible system with little risk of problems using an encoding, hey, caveat usor.) In re SMTP, I would vote conservative, change nothing unless you have a good reason to (eg. ASCII->EBCDIC, there is an EBCDIC tab character.) It should be easy enough to provide software to do minor conversions once the the file has arrived (if it is intact, expanding tabs for example discards information which seems to violate some basic principle of design.) -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [556900672.-1445076342%40XV.MIT.EDU] <1986091212490000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Kevin_Crowston@XV.MIT.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: Formatting Query Message-ID: <556900672.-1445076342@XV.MIT.EDU> Date: Fri, 12-Sep-86 16:49:00 EDT Article-I.D.: XV.556900672.-1445076342 Posted: Fri Sep 12 16:49:00 1986 Date-Received: Sun, 14-Sep-86 04:00:22 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Just to add to the confusion... My system (a Xerox Star) displays mail in a proportionally spaced font, making all diagrams hard to read without changing the font. I'm not sure if this is a bug or a feature, however. In general, I think that having the mailer expand the tabs would be a bad idea. There might be reasons for wanting the tabs in the message and it shouldn't be impossible to do this. The user mail agent might do that sort of processing by default, however. For example, if I try to send a message that includes font changes, etc. the mailer asks if I really want to send formatted text, and strips the formatting if I don't. Kevin Crowston MIT Sloan School of Management kevin@xv.mit.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986091311370000> Mail-From: STJOHNS created at 13-Sep-86 18:38:16 Date: 13 Sep 1986 18:37-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: RFC 912, Auth Service From: STJOHNS@SRI-NIC.ARPA To: jtw@MITRE-BEDFORD.ARPA Cc: tcp-ip@SRI-NIC.ARPA, sra@MITRE-BEDFORD.ARPA Cc: tgw@MITRE-BEDFORD.ARPA Message-ID: <[SRI-NIC.ARPA]13-Sep-86 18:37:35.STJOHNS> In-Reply-To: <8609121532.AA19724@mitre-bedford.ARPA> Speaking as the author of rfc912 (actually, see rfc931 which is a revised version of 912) I know of no one who currently implements it. I did a test implementation of it for Multics and did a little playing with implementing the services end of it (i.e. TELNET without having to explicitly login), but that version is lost to obscurity. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12238683559.11.PALLAS%40Sushi.Stanford.EDU] <1986091312564200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PALLAS@SUSHI.STANFORD.EDU (Joseph I. Pallas) Newsgroups: mod.protocols.tcp-ip Subject: Re: Formatting Query Message-ID: <12238683559.11.PALLAS@Sushi.Stanford.EDU> Date: Sat, 13-Sep-86 16:56:42 EDT Article-I.D.: Sushi.12238683559.11.PALLAS Posted: Sat Sep 13 16:56:42 1986 Date-Received: Sun, 14-Sep-86 07:28:36 EDT References: <860911160927.755905@RADC-MULTICS.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa RFC821 says: The mail data may contain any of the 128 ASCII character codes. This clearly makes it illegal for SMTP mailers to expand tabs. On the other hand, RFC822 says: Writers of mail-sending (i.e., header-generating) programs should realize that there is no network-wide definition of the effect of ASCII HT (horizontal-tab) characters on the appear- ance of text at another network host; therefore, the use of tabs in message headers, though permitted, is discouraged. This clearly suggests that mail-agents expand tabs before submitting them to mailers. Meanwhile, if you use tabs in formatting such that the width of a tab stop affects the content of your message (e.g., in drawing pictures), other people will get what you deserve. joe ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609141621.AA09849%40topaz.rutgers.edu] <1986091408215600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@topaz.rutgers.edu (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: Re: RFC 912, Auth Service Message-ID: <8609141621.AA09849@topaz.rutgers.edu> Date: Sun, 14-Sep-86 12:21:56 EDT Article-I.D.: topaz.8609141621.AA09849 Posted: Sun Sep 14 12:21:56 1986 Date-Received: Mon, 15-Sep-86 22:06:45 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa We implemented RFC 912 on our DEC-20's. Our DEC-20 FTP supports the equivalent of Unix's .rhosts file, and uses auth service to verify that the guy at the other end is really who he claims to be. I regard this is slightly more secure than the mechanism used by rcp. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986091502054800> Received: from MIT-MULTICS.ARPA by SRI-NIC.ARPA with TCP; Mon 15 Sep 86 17:20:42-PDT Received: from UMich-MTS.Mailnet by MIT-MULTICS.ARPA with Mailnet id <2704646668922719@MIT-MULTICS.ARPA>; 15 Sep 1986 14:44:28 edt Received: from UQV-MTS by UMich-MTS.Mailnet via MTS-Net; Mon, 15 Sep 86 10:05:21 EDT Received: from ?.UUCP by UQV-MTS via MTS-Net; Mon, 15 Sep 86 07:26:01 MDT Received: by pembina.alberta.UUCP id AA04805; Sun, 14 Sep 86 21:20:21 mdt Date: Mon, 15 Sep 86 08:05:48 MDT From: ncc!lyndon%ALBERTA%UQV-MTS%UMich-MTS.Mailnet@MIT-MULTICS.ARPA To: tcp-ip@SRI-NIC.ARPA, sri-nic.arpa!tcp-ip@ALBERTA From: lyndon@ncc.UUCP (Lyndon Nerenberg) Newsgroups: net.video,mod.protocols.tcp-ip Subject: Re: Ethernet between buildings Message-ID: <722@ncc.UUCP> Date: Sat, 13-Sep-86 19:32:57 MDT References: <611.rbbb.titan@Rice> Organization: Nexus Computing Corp., Edmonton, AB Lines: 35 Summary: Not a wives tale! I am cross-posting as this sort of relates to the discussion in mod.protocols.tcp-ip about grounding ethernet cables... In article <611.rbbb.titan@Rice>, rbbb@rice.edu (David Chase) writes: > ... A sort of old wives tale of lightning protection says that you > should put a tight loop in a wire near a good ground; the lightning sees > that as a great big inductor, and hops over to the good ground. > > David The "signal" introduced into a cable by a lightning strike consists of extremely high frequency radiation. It does not take much inductance to throw up a "brick wall" to it. Many television stations run their feeds through a single loop at the base of the tower, then to the transmitter shack. The RF from a lightning strike will (hopefully :-) take the easier path from the feed line, through the base of the tower, to ground. I handled the transmitter plant installation and setup for a local FM BCST station a couple of years back. The antenna was located on top of a building at the University. We were unable to properly ground the tower, so we threw up a loop inside the roof house for the elevators ( *lots* of metal in there :-) I know a number of amateur radio op's in town who do the same thing - 2 turns of the feedline at the base (approx. 3 feet in diameter) before entering the house. I can't say that any of them have been hit, so I won't guarantee results. Then again, I have watched local TV broadcast towers take direct hits without going off the air. I'm sure a posting to net.ham-radio would provide some further information on practical experiences of dealing with lightning hits. -- Lyndon Nerenberg (VE6BBM) {ihnp4,ubc-vision}!alberta!ncc!lyndon Systems Group - A Div. of Nexus Computing Corp. Envoy_100: Unix ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609152329.AA08944%40ucbvax.Berkeley.EDU] <1986091504371800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckenzie@j.bbn.com (Alex McKenzie) Newsgroups: mod.protocols.tcp-ip Subject: Ethernet Multiplexors Message-ID: <8609152329.AA08944@ucbvax.Berkeley.EDU> Date: Mon, 15-Sep-86 08:37:18 EDT Article-I.D.: ucbvax.8609152329.AA08944 Posted: Mon Sep 15 08:37:18 1986 Date-Received: Tue, 16-Sep-86 09:12:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa We have had various troubles attaching hosts to our BBN Ethernet using DELNIs. We haven't actually tried too hard to diagnose them all - simply noted that there are hosts which don't work when connected to a DELNI. We assume that DEC has probably "improved" or ignored some part of the host to transceiver protocol. We are now using large quantities of an Ethernet multiplexor made by TCL, Inc., 41829 Albrae St., Fremont, CA 94538 (415/657-3800). You buy a chassis with 9 card slots. You buy a "downstream" card and 1 to 8 "upstream" cards. Each upstream card can be either V1 or 802.3; I think this is also true of the downstream card but I'm not so sure. As I recall, a box with a downstream card costs about $400 and each upstream card costs about $100. We have had no troubles with these multiplexors, have successfully cascaded them, and I know of no hosts that can't use them. Regards, Alex McKenzie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986091504371801> Received: from J.BBN.COM by SRI-NIC.ARPA with TCP; Mon 15 Sep 86 07:50:26-PDT Date: Mon, 15 Sep 86 8:37:18 EDT From: Alex McKenzie To: tcp-ip@sri-nic.arpa Subject: Ethernet Multiplexors We have had various troubles attaching hosts to our BBN Ethernet using DELNIs. We haven't actually tried too hard to diagnose them all - simply noted that there are hosts which don't work when connected to a DELNI. We assume that DEC has probably "improved" or ignored some part of the host to transceiver protocol. We are now using large quantities of an Ethernet multiplexor made by TCL, Inc., 41829 Albrae St., Fremont, CA 94538 (415/657-3800). You buy a chassis with 9 card slots. You buy a "downstream" card and 1 to 8 "upstream" cards. Each upstream card can be either V1 or 802.3; I think this is also true of the downstream card but I'm not so sure. As I recall, a box with a downstream card costs about $400 and each upstream card costs about $100. We have had no troubles with these multiplexors, have successfully cascaded them, and I know of no hosts that can't use them. Regards, Alex McKenzie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609160547.AA13541%40ucbvax.Berkeley.EDU] <1986091506054800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: lyndon%ALBERTA%UQV-MTS%UMich-MTS.MAILNET@ncc.UUCP Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8609160547.AA13541@ucbvax.Berkeley.EDU> Date: Mon, 15-Sep-86 10:05:48 EDT Article-I.D.: ucbvax.8609160547.AA13541 Posted: Mon Sep 15 10:05:48 1986 Date-Received: Tue, 16-Sep-86 18:44:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 45 Approved: tcp-ip@sri-nic.arpa From: lyndon@ncc.UUCP (Lyndon Nerenberg) Newsgroups: net.video,mod.protocols.tcp-ip Subject: Re: Ethernet between buildings Message-ID: <722@ncc.UUCP> Date: Sat, 13-Sep-86 19:32:57 MDT References: <611.rbbb.titan@Rice> Organization: Nexus Computing Corp., Edmonton, AB Lines: 35 Summary: Not a wives tale! I am cross-posting as this sort of relates to the discussion in mod.protocols.tcp-ip about grounding ethernet cables... In article <611.rbbb.titan@Rice>, rbbb@rice.edu (David Chase) writes: > ... A sort of old wives tale of lightning protection says that you > should put a tight loop in a wire near a good ground; the lightning sees > that as a great big inductor, and hops over to the good ground. > > David The "signal" introduced into a cable by a lightning strike consists of extremely high frequency radiation. It does not take much inductance to throw up a "brick wall" to it. Many television stations run their feeds through a single loop at the base of the tower, then to the transmitter shack. The RF from a lightning strike will (hopefully :-) take the easier path from the feed line, through the base of the tower, to ground. I handled the transmitter plant installation and setup for a local FM BCST station a couple of years back. The antenna was located on top of a building at the University. We were unable to properly ground the tower, so we threw up a loop inside the roof house for the elevators ( *lots* of metal in there :-) I know a number of amateur radio op's in town who do the same thing - 2 turns of the feedline at the base (approx. 3 feet in diameter) before entering the house. I can't say that any of them have been hit, so I won't guarantee results. Then again, I have watched local TV broadcast towers take direct hits without going off the air. I'm sure a posting to net.ham-radio would provide some further information on practical experiences of dealing with lightning hits. -- Lyndon Nerenberg (VE6BBM) {ihnp4,ubc-vision}!alberta!ncc!lyndon Systems Group - A Div. of Nexus Computing Corp. Envoy_100: Unix ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609151331.AA02125%40mitre.ARPA] <1986091513192700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP Conformance Testing Message-ID: <8609151331.AA02125@mitre.ARPA> Date: Mon, 15-Sep-86 17:19:27 EDT Article-I.D.: mitre.8609151331.AA02125 Posted: Mon Sep 15 17:19:27 1986 Date-Received: Tue, 16-Sep-86 06:46:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 49 Approved: tcp-ip@sri-nic.arpa The following article was published in NETWORK WORLD, by Paul Korzeniowski, 1 Sept. 86, pg 2. Monterey, Calif. - Corporation for Open Systems (COS) supporters beware. Ensuring that devices on a multivendor network really can work together has proven to be a task too complex even for Uncle Sam. Last week at the first Transmission Control Protocol/Internet Protocol (TCP/IP) Vendor Workshop ("TCP/IP future at stake," Network World, Aug. 25), the U.S. Defense Communications Agency announced it is washing its hands of TCP/IP conformance testing. The agency oversees transmission facilities that link government agencies, universities, and corporations into one giant network of networks. The umbrella network grew out of the Advanced Research Projects Agency Network (Arpanet), designed in the late 1960s as the world's first packet-switching net. The original network has expanded so that today it supports more than 30,000 computer systems ranging in size from Cray Research, Inc.'s supercomputers to Apple Computer, Inc.'s Macintoshes. For the last few years, DCA and a number of other government agencies have been developing test suites and creating a center for TCP/IP conformance. The work was similar to that undertaken by COS, which will handle Open Systems Interconnect (OSI) conformance testing and the development to test suites. At the workshop, two government officials told attendees that plans for the center had been dropped. The DCA has developed and continues to design conformance test criteria, but they are not robust enough to ensure that all TCP/IP products can interoperate. "There have been instances where vendors have spent a lot of time and money trying to ensure their products would perform on the government network," said Daniel Lynch, president of Advanced Computing Environments in Cupertino, Calif. "When their product was linked to another company's product, they couldn't communicate." Government officials declined to discuss the decision. But conference attendees speculated the government found the task of supplying comprehensive conformance tests nearly an impossible one. One problem testers faced is that the only way to test a product properly is to attach it to the target network, a procedure that the DCA would not condone. Also, running a testing center requires a great deal of money and engineering talent. Lynch said only a handful of engineers are qualified to develop and run conformance tests. The DCA decision leaves TCP/IP vendors with a number of unappealing options. They could form a COS-like organization. But the consensus seemed to be that fewer rather than more of such standards organizations are needed. Individual companies could develop their own testing procedures. But the resources required for such self-testing could limit the number of vendors able to bring TCP/IP products to market. Attendees formed a task force to explore how vendors should proceed. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609152123.AA19278%40utah-cs.ARPA] <1986091513231200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cetron@UTAH-CS.ARPA (Edward J Cetron) Newsgroups: mod.protocols.tcp-ip Subject: Ultrix 1.2 and unacceptable tcp packets Message-ID: <8609152123.AA19278@utah-cs.ARPA> Date: Mon, 15-Sep-86 17:23:12 EDT Article-I.D.: utah-cs.8609152123.AA19278 Posted: Mon Sep 15 17:23:12 1986 Date-Received: Tue, 16-Sep-86 09:18:13 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: utah-cs!cetron (Edward J Cetron) Organization: Center for Engineering Design, Univ of Utah Lines: 27 Approved: tcp-ip@sri-nic.arpa After hacking with the Tek tcp/ip package to add keep-alive (or probe-alive as the case may be) support, I found the following behaviour from two Ultrix sites: line sits idle for x length of time (so snd.nxt = snd.una = Ultrix rcv.nxt...) Tek tcp/ip sends a packet designed to be unacceptable in order to force a response (as documented in the mil-std and rfc for tcp). This packet has seg.seq = snd.nxt-1 and seg.ack = rcv.nxt-1 which is obviously unacceptable and should force and ack with the proper counters. The Ultrix site receives the packet, and promptly drops it off of the face of the earth (though apparently reading the code it does use it to update the window...) Am I missing something or is this indeed non-compliant? All of the 4.2bsd and 4.3 bsd sites handle this fine... I know what is different between the 4.3bsd and the Ultrix code but before I fix it myself, I want to be sure I haven't overlooked something and/or that other Ultrix sites have noticed this same problem.... thanx ed cetron%utah-cbd@utah-cs.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [MS.leong.0.leong.1221.0%40andrew.cmu.edu] <1986091514493100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leong@ANDREW.CMU.EDU (John Leong) Newsgroups: mod.protocols.tcp-ip Subject: Re: DELNI characteristics Message-ID: Date: Mon, 15-Sep-86 18:49:31 EDT Article-I.D.: andrew.MS.leong.0.leong.1221.0 Posted: Mon Sep 15 18:49:31 1986 Date-Received: Tue, 16-Sep-86 09:21:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa On the subject of cascading DELNI, one has to be careful about one quirk. The Intel 82586 chip has, by default, a check that is not really in conformance of the Ethernet spec. It measures the time between transmit and receiving the signal back from the transceiver and signals whether the round trip time equates roughly to 50 meter of drop cable (nothing to do with the Ethernet slot time of 51.2 micro seconds or roughly 2.5Km). This test is quite bogus but some earlier version of DECNET software actually check for that return code and declares the world is sick accordingly. We have ran into that problem earlier on when we cascaded DELNI's since they introduced roughly 10 meter of cable worth of delay and we ran over the 50 meters. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12239346231.28.ROODE%40IC2060] <1986091601365200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROODE%BIONET@SUMEX-AIM.STANFORD.EDU (David Roode) Newsgroups: mod.protocols.tcp-ip Subject: Re: DELNI characteristics Message-ID: <12239346231.28.ROODE@IC2060> Date: Tue, 16-Sep-86 05:36:52 EDT Article-I.D.: IC2060.12239346231.28.ROODE Posted: Tue Sep 16 05:36:52 1986 Date-Received: Tue, 16-Sep-86 20:43:57 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Reference on DELNI limitation to non-cascaded mode when connected to an Ether cable: EK-ETHV1-IN-002 Ethernet Installation Guide, Digital Equipment Corporation, 1984, Appendix E, p. E1: "If DELNI interconnects are cascaded, the top DELNI interconnect cannot connect to an Ethernet coaxial cable. A maximum of two layers of DELNI interconnects are permitted, with the second layer of DELNI interconnects operating in the global mode." ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609161257.AA06450%40devvax.tn.cornell.edu] <1986091604571600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: swb@DEVVAX.TN.CORNELL.EDU (Scott Brim) Newsgroups: mod.protocols.tcp-ip Subject: DELNI characteristics Message-ID: <8609161257.AA06450@devvax.tn.cornell.edu> Date: Tue, 16-Sep-86 08:57:16 EDT Article-I.D.: devvax.8609161257.AA06450 Posted: Tue Sep 16 08:57:16 1986 Date-Received: Tue, 16-Sep-86 21:59:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Date: Mon, 15 Sep 86 18:49:31 edt From: leong@andrew.cmu.edu (John Leong) ..... The Intel 82586 chip has, by default, a check that is not really in conformance of the Ethernet spec. It measures the time between transmit and receiving the signal back from the transceiver and signals whether the round trip time equates roughly to 50 meter of drop cable (nothing to do with the Ethernet slot time of 51.2 micro seconds or roughly 2.5Km). This test is quite bogus .... You can tell the chip to disable that feature. I think it's *on* at power-up. Gould used to use the round-trip-to-transceiver check; we asked them to disable it and I believe it's now off for all new Gould ethernet boards. Scott ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860916105625.6.DCP%40KOYAANISQATSI.S4CC.Symbolics.COM] <1986091606560000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) Newsgroups: mod.protocols.tcp-ip Subject: Re: Formatting Query Message-ID: <860916105625.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Tue, 16-Sep-86 10:56:00 EDT Article-I.D.: KOYAANIS.860916105625.6.DCP Posted: Tue Sep 16 10:56:00 1986 Date-Received: Wed, 17-Sep-86 06:20:36 EDT References: <12238683559.11.PALLAS@Sushi.Stanford.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa Tabs should be expanded at the source; not by any heuristic in some program that has no chance of guessing right. This is preferably the user's mail composition program, perhaps by a user profile switch, but it should not be done by the SMTP user side, or the SMTP sending side, or any other mail delivery program (SMTP isn't the only one that exists (surprise!!)). If the user's composition program doesn't have this feature, then the user should do the conversion if tabs are significant. You simply cannot send data from one place to the other unless you /know/ that both sides agree on how to interpret the characters. I believe the /only/ set of characters we all agree on are the 95 ascii characters space through tilde, plus NVT newline. I would have italicized /know/ but only other Lisp Machines would be able to see it without garbage characters... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860916153451.710273%40RADC-MULTICS.ARPA] <1986091607340000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Ata@RADC-MULTICS.ARPA ("John G. Ata") Newsgroups: mod.protocols.tcp-ip Subject: Re: Formatting Query Message-ID: <860916153451.710273@RADC-MULTICS.ARPA> Date: Tue, 16-Sep-86 11:34:00 EDT Article-I.D.: RADC-MUL.860916153451.710273 Posted: Tue Sep 16 11:34:00 1986 Date-Received: Sat, 20-Sep-86 00:39:01 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa Yes, you are correct...when I said SMTP mailer, I meant the mail composition program that submits mail to the SMTP mailer. Sorry for the confusion. I strongly believe that mail composition programs, should for the most part, expand tabs to spaces unless overridden by another command or control argument. This is because, in the vast majority of cases, tabs are used to merely position the next character in a particular column, so that tab expanding is then the right thing to do given that there isn't a standard definition of tabstops over the network. Of course, for those cases where tabs mean something else, the user can override this, perhaps with a command/control argument. The bottom line is that, in most cases, tabs will be vastly reduced in SMTP message text. As a matter of record, the standard Multics mail system does not allow tabs at all whether local or network. Therefore, the mail program will expand tabs BEFORE submitting to the SMTP mailer, just like it will expand before submission into another local mailbox. Given that tab characters are not allowed in messages, the server SMTP does also expand tabs to maintain compatability with the rest of the mail system. John G. Ata ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609161618.AA26054%40xios.XIOS.CA] <1986091608184000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: alexp@xios.XIOS.CA (Alex Pepple) Newsgroups: mod.protocols.tcp-ip Subject: X.25 Board Inquiry Message-ID: <8609161618.AA26054@xios.XIOS.CA> Date: Tue, 16-Sep-86 12:18:40 EDT Article-I.D.: xios.8609161618.AA26054 Posted: Tue Sep 16 12:18:40 1986 Date-Received: Fri, 19-Sep-86 07:27:57 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: xios!alexp@seismo.CSS.GOV (Alex Pepple) Distribution: na Organization: XIOS Systems Corporation, Ottawa, Ont. Lines: 13 Keywords: Multibus, VMEbus Approved: tcp-ip@sri-nic.arpa *** BUGS SPRAY *** I'm looking for X.25 boards (Full X.25) for Multibus and VMEbus machines to interface to tcp-ip and other protocols. Would anyone have a list of companies offering QUALITY products of that nature? Please reply directly to me. Sufficient Interest = Net Summary. I'm waiting in anticipation for E-mail bits of your brainwaves! -:) -- Alex ...The bitterness of POOR QUALITY is remembered long after the sweetness of LOW PRICE is forgotten. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609162110.AA01204%40trantor.UMD.EDU] <1986091613103700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: louie@TRANTOR.UMD.EDU (Louis A. Mamakos) Newsgroups: mod.protocols.tcp-ip Subject: Ultrix 1.2 and unacceptable tcp packets Message-ID: <8609162110.AA01204@trantor.UMD.EDU> Date: Tue, 16-Sep-86 17:10:37 EDT Article-I.D.: trantor.8609162110.AA01204 Posted: Tue Sep 16 17:10:37 1986 Date-Received: Wed, 17-Sep-86 12:28:58 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa I've noticed other TCP problems with Ultrix 1.2's TCP. After we installed ULTRIX on a MicroVAX system, we don't seem to be able to send mail to our Sperry 1100 system anymore. The connection just hangs after a bit. This concerned me greatly, being one of the authors of the TCP/IP software on the Sperry host. None of our other systems had any problems, (2.9BSD UNIX, 4.2 BSD UNIX, Wollongong VMS, FUZZBALL, *Ultrix 1.1*). Examination of trace data on the Sperry indicates that it's just waiting for more data on the SMTP connection after sending a window update. (Flame on) Our solution? Very simple. Trash Ultrix and run 4.3 BSD. Not only has DEC managed not to fix broken code, but they've even broken working code! I'll just bet DECNET works though. (Flame off) Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming ----MESSAGE-END---- ----MESSAGE-BEGIN---- [7103.527484229%40nrtc-gremlin.northrop.com] <1986091905322600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@NRTC-GREMLIN.ARPA (Marshall Rose) Newsgroups: mod.protocols.tcp-ip Subject: A new discussion group Message-ID: <7103.527484229@nrtc-gremlin.northrop.com> Date: Fri, 19-Sep-86 09:32:26 EDT Article-I.D.: nrtc-gre.7103.527484229 Posted: Fri Sep 19 09:32:26 1986 Date-Received: Sat, 20-Sep-86 01:20:58 EDT Sender: uucp@ucbvax.BERKELEY.EDU Reply-To: isode-request@nrtc Organization: The ARPA Internet Lines: 32 Approved: tcp-ip@sri-nic.arpa I am pleased to announce the charter of a new discussion group. ISODE@NRTC.NORTHROP.COM ISODE is a discussion group which focuses on the ISO Development Environment, an openly available implementation of some of the higher-level protocols adopted by international organizations (ISO, CCITT, ECMA). These implementations are hosted on top of TCP/IP using the method discussed in RFC983. Appropriate topics are: - questions about how to use ISODE (and announcements of ports to other target environments) - discussion of ISODE as a part of a TCP/IP to ISO migration strategy - exchange of ideas regarding ISO-based applications running in a native TCP/IP environment - debate regarding where ISODE should go next This list naturally has some overlap with the TCP-IP list, the ISO list, and so on. Contributors are urged to use the appropriate list based on their topic of discussion. If there is sufficient demand, new sublists may be formed. All requests to be added to or deleted from this list, along with problems, questions and suggestions, should be sent to ISODE-Request@NRTC.NORTHROP.COM. Coordinator: Marshall T. Rose (MTR) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609192309.AA00342%40braden.isi.edu] <1986091915093300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@VENERA.ISI.EDU (Bob Braden) Newsgroups: mod.protocols.tcp-ip Subject: Internet Multicasting for NETBIOS Message-ID: <8609192309.AA00342@braden.isi.edu> Date: Fri, 19-Sep-86 19:09:33 EDT Article-I.D.: braden.8609192309.AA00342 Posted: Fri Sep 19 19:09:33 1986 Date-Received: Sun, 21-Sep-86 22:14:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 43 Approved: tcp-ip@sri-nic.arpa I would like to comment on the use of Internet multicasting for the implementation of NETBIOS over the DoD protocol suite. Both of the proposed protocols for implementing NETBIOS quite properly restrict the use of NETBIOS broadcast packets to the same local network. This restriction is necessary because the Internet architecure has not provided a reasonable Internet-wide broadcast/multicast mechanism. However, I believe that this can be only a temporary restriction. There is a clear need to extend the Internet architecture to provide a multicasting mechanism, and in fact the NETBIOS application is an excellent example of the requirement for "distributed binding" which multicasting can provide. There is active work on the development and experimental deployment of a Internet multicasting facility, as described in RFC 966 and RFC988. Since (as we proudly proclaim) our work is characterized by trying out something new before writing a standards document, the multicasting extension to the Internet architecture described in these RFC's is not yet in the "proposed standard" stage, although we are moving in that direction. Experimental implementations are now under development. What are the implications for the NETBIOS protocol design effort? **> Make sure your protocol is consistent with the proposed Internet multicasting facility, so that the local-net-only restriction on broadcasting can be removed from a NETBIOS implementation with minimal work when and if Internet multicasting is generally available. At some point, the NETBIOS application could be a good demonstration of the Internet multicasting facility. The vendors developing NETBIOS implementations for the DoD protocol suite are concerned with making a product and selling it, rather than in protocol development. However, if NETBIOS is successful, perhaps customer interest in removing the broadcast restriction will bring about a more active collaboration between vendors and researchers interested in Internet multicasting. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092008163400> Received: from NRL-ACOUSTICS.ARPA by SRI-NIC.ARPA with TCP; Sat 20 Sep 86 15:16:34-PDT Date: Sat 20 Sep 86 15:16:34-PDT From: "Henry Dardy" Subject: RE: Ultrix 1.2 and unacceptable tcp packets To: "tcp-ip" cc: dardy Reply-To: "Henry Dardy" You are right: Decnet works perfectly! ***Cough, ghasp, wheeze***. Sorry, but your (flame on) hadn't cooled yet! Hank ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609212133.AA20831%40ucbvax.Berkeley.EDU] <1986092110175600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tcs@USNA.ARPA (Terry Slattery) Newsgroups: mod.protocols.tcp-ip Subject: Fiber Ethernet problem Message-ID: <8609212133.AA20831@ucbvax.Berkeley.EDU> Date: Sun, 21-Sep-86 14:17:56 EDT Article-I.D.: ucbvax.8609212133.AA20831 Posted: Sun Sep 21 14:17:56 1986 Date-Received: Sun, 21-Sep-86 22:24:26 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 74 Approved: tcp-ip@sri-nic.arpa We have a fiber optic based Ethernet product installed here and are having a problem with a Gould 9050 being attached to the net. DESCRIPTION: We have the Codenoll ethernet on fiber optic product with the following configuration: ----------- ~325M -------------- ~800M --------------- |usna.arpa|-----------|Star Coupler|----------------|usna-gus.arpa| ----------- -------------- --------------- | | ~75M | --------------- |usna-cs1.arpa| --------------- M = meters Both usna.arpa and usna-cs1.arpa can communicate. Usna-gus.arpa can hear some (most?) rwho packets from usna and cs1. Gus cannot send anything out without error. A Gould 6050 which is co-located with usna can communicate over the 325 meter segment without problems. ANALYSIS: Optical power measurements show -15db at usna and -12db at gus (better polished connectors and lower loss cable are the difference). The flux budget is 21db, so we are well within spec there. A recent note to these lists leads me to believe that there is a timing problem. Codenoll supplied the following timing info: Device Delay (ns) Controller encoder 100 Xcvr xmit 300 Fiber cable (1600 meters@4.33ns/m) 6928 Xcvr rcv 650 Xcvr cable (60 meters@5.13ns/m) 308 ----- TOTAL 8386 I have connected the Gould and a Tektronix 6130 to a TCL MP station and they communicate without problems, thus proving that the interface is working correctly. MISC. INFO: The Gould Ethernet Controller Model 8561 Tech. Manual (May 85) says that it tries 16 retransmits before giving up completely. It also mentions a control bit described as: "Transmit even if no arrrier sense signal is detected." The driver doesn't include any code to modify this bit; it is automatically reset upon board power-up. QUESTIONS: Is the timing out of spec with respect to what the Gould ethernet interface is capable of handling? What time delay does most equipment expect? Does anyone else have experience with this or Siecor's product over the distances involved here? Are there more details available on what Gould did w.r.t. the problem reported at Perdue? Please respond directly and I will summarize the responses. Thanks, -tcs Terry Slattery U.S. Naval Academy 301-267-4413 ARPA: tcs@usna.arpa UUCP: decvax!brl-smoke!usna!tcs ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092110175601> Received: from USNA.ARPA by SRI-NIC.ARPA with TCP; Sun 21 Sep 86 11:22:23-PDT Date: Sun, 21 Sep 86 14:17:56 EDT From: Terry Slattery To: tcp-ip@SRI-NIC.ARPA cc: gouldbugs@BRL.ARPA Subject: Fiber Ethernet problem We have a fiber optic based Ethernet product installed here and are having a problem with a Gould 9050 being attached to the net. DESCRIPTION: We have the Codenoll ethernet on fiber optic product with the following configuration: ----------- ~325M -------------- ~800M --------------- |usna.arpa|-----------|Star Coupler|----------------|usna-gus.arpa| ----------- -------------- --------------- | | ~75M | --------------- |usna-cs1.arpa| --------------- M = meters Both usna.arpa and usna-cs1.arpa can communicate. Usna-gus.arpa can hear some (most?) rwho packets from usna and cs1. Gus cannot send anything out without error. A Gould 6050 which is co-located with usna can communicate over the 325 meter segment without problems. ANALYSIS: Optical power measurements show -15db at usna and -12db at gus (better polished connectors and lower loss cable are the difference). The flux budget is 21db, so we are well within spec there. A recent note to these lists leads me to believe that there is a timing problem. Codenoll supplied the following timing info: Device Delay (ns) Controller encoder 100 Xcvr xmit 300 Fiber cable (1600 meters@4.33ns/m) 6928 Xcvr rcv 650 Xcvr cable (60 meters@5.13ns/m) 308 ----- TOTAL 8386 I have connected the Gould and a Tektronix 6130 to a TCL MP station and they communicate without problems, thus proving that the interface is working correctly. MISC. INFO: The Gould Ethernet Controller Model 8561 Tech. Manual (May 85) says that it tries 16 retransmits before giving up completely. It also mentions a control bit described as: "Transmit even if no arrrier sense signal is detected." The driver doesn't include any code to modify this bit; it is automatically reset upon board power-up. QUESTIONS: Is the timing out of spec with respect to what the Gould ethernet interface is capable of handling? What time delay does most equipment expect? Does anyone else have experience with this or Siecor's product over the distances involved here? Are there more details available on what Gould did w.r.t. the problem reported at Perdue? Please respond directly and I will summarize the responses. Thanks, -tcs Terry Slattery U.S. Naval Academy 301-267-4413 ARPA: tcs@usna.arpa UUCP: decvax!brl-smoke!usna!tcs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609211848.AA19049%40ucbvax.Berkeley.EDU] <1986092110500300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dardy@NRL-ACOUSTICS.ARPA ("Henry Dardy") Newsgroups: mod.protocols.tcp-ip Subject: RE: Ultrix 1.2 and unacceptable tcp packets Message-ID: <8609211848.AA19049@ucbvax.Berkeley.EDU> Date: Sun, 21-Sep-86 14:50:03 EDT Article-I.D.: ucbvax.8609211848.AA19049 Posted: Sun Sep 21 14:50:03 1986 Date-Received: Sun, 21-Sep-86 22:20:35 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Henry Dardy" Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa You are right: Decnet works perfectly! ***Cough, ghasp, wheeze***. Sorry, but your (flame on) hadn't cooled yet! Hank ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092203190000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Mon 22 Sep 86 11:22:42-PDT Date: 22 Sep 86 11:19:00 PST From: Subject: Standard X.25 on Arpanet To: "tcp-ip" Reply-To: Hans, I would be extremely interested in what you find out. As it would be germane for this group, could you please publish your findings? Thanks, Gary . ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609221443.AA02569%40MCR.UMICH.EDU] <1986092206434700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hwb@MCR.UMICH.EDU (Hans-Werner Braun) Newsgroups: mod.protocols.tcp-ip Subject: Standard X.25 on the Arpanet. Message-ID: <8609221443.AA02569@MCR.UMICH.EDU> Date: Mon, 22-Sep-86 10:43:47 EDT Article-I.D.: MCR.8609221443.AA02569 Posted: Mon Sep 22 10:43:47 1986 Date-Received: Mon, 22-Sep-86 21:32:53 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Hi: I am wondering about who is using Standard X.25 to connect to an Arpa IMP (PSN) these days. Not HDH, not DH or LH (no 1822 at all), no Basic X.25 and not on the Milnet. Just plain Arpanet Standard X.25 attachments. I would appreciate a note if you are connected like that and would also be interested in what machine/operating_system/interface you use and eventually whether you saw any problems with such a setup. -- Hans-Werner ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609221348.AA14417%40mitre.ARPA] <1986092208005100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Comm. Fault Recognition/Diagnosis Message-ID: <8609221348.AA14417@mitre.ARPA> Date: Mon, 22-Sep-86 12:00:51 EDT Article-I.D.: mitre.8609221348.AA14417 Posted: Mon Sep 22 12:00:51 1986 Date-Received: Mon, 22-Sep-86 21:29:47 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 6 Approved: tcp-ip@sri-nic.arpa For those of you interested in communications network fault recognition and diagnosis, the 15 Sept. issue of Datamation has a survey article by Bill Musgrave; "Sorting Out The Solutions", page 98. H. Craig McKee ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609230046.AA18007%40ucbvax.Berkeley.EDU] <1986092211190000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gary@acc.arpa Newsgroups: mod.protocols.tcp-ip Subject: Standard X.25 on Arpanet Message-ID: <8609230046.AA18007@ucbvax.Berkeley.EDU> Date: Mon, 22-Sep-86 15:19:00 EDT Article-I.D.: ucbvax.8609230046.AA18007 Posted: Mon Sep 22 15:19:00 1986 Date-Received: Mon, 22-Sep-86 23:38:02 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Hans, I would be extremely interested in what you find out. As it would be germane for this group, could you please publish your findings? Thanks, Gary . ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609230206.AA16609%40ACC-SB-UNIX.ARPA] <1986092218065100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rms@ACC-SB-UNIX.ARPA (Ron Stoughton) Newsgroups: mod.protocols.tcp-ip Subject: X.25 on Arpanet Message-ID: <8609230206.AA16609@ACC-SB-UNIX.ARPA> Date: Mon, 22-Sep-86 22:06:51 EDT Article-I.D.: ACC-SB-U.8609230206.AA16609 Posted: Mon Sep 22 22:06:51 1986 Date-Received: Tue, 23-Sep-86 05:58:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Hosts requiring X.25 Standard service must be connected to an IMP running PSN6. I am not certain, but I don't believe many (if any at all) Arpanet IMPs have been converted to run PSN6. Many will require a hardware upgrade (C/30 to C/30E). Maybe someone from BBN can comment on this and give a schedule for upgrading the Arpanet IMPs. Ron Stoughton rms@acc-sb-unix.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092222530000> Mail-From: STJOHNS created at 23-Sep-86 05:54:49 Date: 23 Sep 1986 05:53-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: X.25 on Arpanet From: STJOHNS@SRI-NIC.ARPA To: rms@ACC-SB-UNIX.ARPA Cc: tcp-ip@SRI-NIC.ARPA, gary@BRL-SAGE.ARPA Message-ID: <[SRI-NIC.ARPA]23-Sep-86 05:53:32.STJOHNS> In-Reply-To: <8609230206.AA16609@ACC-SB-UNIX.ARPA> As of this writing and speaking semi-authoritatively I believe that all of the PSNs on the ARPANET have been upgraded to C30E. I am not sure of the status of the PSN software though on that side of the net, but the plan was to field PSN 6 as quickly as possible. Mike StJohns (DDN PMO) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609231825.AA03006%40ucbvax.Berkeley.EDU] <1986092306150800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jseeger@CC5.BBN.COM Newsgroups: mod.protocols.tcp-ip Subject: Re: X.25 on Arpanet Message-ID: <8609231825.AA03006@ucbvax.Berkeley.EDU> Date: Tue, 23-Sep-86 10:15:08 EDT Article-I.D.: ucbvax.8609231825.AA03006 Posted: Tue Sep 23 10:15:08 1986 Date-Received: Tue, 23-Sep-86 23:06:38 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa All, ARPANET nodes have been upgraded hardware-wise to C/30e's. The upgrade to PSN 6.0 software is proceeding now. However, all nodes have been running PSN 5.0 for several months, and x.25 standard service was even possible before that, under PSN 3.0/4.0 (although it required the loading of a separate x.25 package). -Josh Seeger (BBN Communications, Network Analysis) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609231947.AA04632%40ucbvax.Berkeley.EDU] <1986092308501700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: fserr@CC5.BBN.COM (Frederick E Serr BBN 3/176 x2474) Newsgroups: mod.protocols.tcp-ip Subject: re: X.25 on ARPANET Message-ID: <8609231947.AA04632@ucbvax.Berkeley.EDU> Date: Tue, 23-Sep-86 12:50:17 EDT Article-I.D.: ucbvax.8609231947.AA04632 Posted: Tue Sep 23 12:50:17 1986 Date-Received: Tue, 23-Sep-86 23:14:48 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa The hardware upgrade on the ARPANET is complete. PSN 6 has been deployed to a few nodes, and deployment to other nodes in ongoing. I am not certain if a definite schedule has been established for the remaining nodes, but I would expect that all ARPANET nodes would be running PSN 6 within one month. Fred Serr BBNCC Network Analysis ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092308501701> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Tue 23 Sep 86 09:54:31-PDT To: hwb@mcr.umich.edu cc: tcp-ip@sri-nic.ARPA Subject: re: X.25 on ARPANET Date: 23 Sep 86 12:50:17 EDT (Tue) From: Frederick E Serr BBN 3/176 x2474 The hardware upgrade on the ARPANET is complete. PSN 6 has been deployed to a few nodes, and deployment to other nodes in ongoing. I am not certain if a definite schedule has been established for the remaining nodes, but I would expect that all ARPANET nodes would be running PSN 6 within one month. Fred Serr BBNCC Network Analysis ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609250628.AA06441%40ucbvax.Berkeley.EDU] <1986092414070100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tcs@USNA.ARPA (Terry Slattery) Newsgroups: mod.protocols.tcp-ip Subject: Fiber Ethernet problem solved Message-ID: <8609250628.AA06441@ucbvax.Berkeley.EDU> Date: Wed, 24-Sep-86 18:07:01 EDT Article-I.D.: ucbvax.8609250628.AA06441 Posted: Wed Sep 24 18:07:01 1986 Date-Received: Thu, 25-Sep-86 06:16:46 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 220 Approved: tcp-ip@sri-nic.arpa The fiber ethernet problem has been solved. This is rather long (~200 lines) and includes info supplied by various people on the net. If you only are interested in the solution, skip down to "THE SOLUTION". First, a synopsis of the problem. SYNOPSIS A Gould 9050 connected via a Codenoll Ethernet over fiber optic network wouldn't talk to a Vax 780 (or Gould 6050 co-located with the 780). The Goulds run thier UTX Unix product. The fiber's optical power levels checked out to be within spec. The 9050 could hear rwho packets from the 780. The 9050 would report errors on EVERY outgoing packet. Timing estimates showed the 9050 getting receive carrier about 8us after transmit started. The controller manual noted a bit which when set would: "Transmit even if no arrrier sense signal is detected." but the driver didn't contain code to set the bit. A recent note to these lists from Cornell (I hope this is right this time) suggested that the 9050 needed to have this bit set. INPUT FROM OTHERS ON THESE LISTS From: swb@devvax.tn.cornell.edu (Scott Brim) I'm pretty sure I know what that bit is (haven't looked at the Gould ethernet manual for a year) -- and I don't think it's your problem -- but here's an explanation of the bit: The Gould board uses the 82586 controller chip. There's an option in the 82586 to look for its own signal coming back from the transceiver within a certain amount of time. It used to be that you couldn't use a "transceiver cable" more than a certain length (I remember 6 ns, but that seems awfully short). They turned this off for us -- it's just a change to an initialization bit in the PROMs on the Ethernet board. Scott [Ed note: I didn't get any info from Gould on the actual time delay over which the system would break, but our 6050 would work in place of the 780 and the time delay there was ~4us (calculated and measured).] From: Here at McMaster University we have a star coupler with 4 legs of around 1500 ft. . We were using Codelink 2020A modems, we found that we were able to transmit from leg 1 to leg (2,3,4) and leg 2 to leg (1,3,4) we were unable to transmit from leg 3 to leg 4. This problem cleared up after trying several modems on leg 4. Thus the matching of modems IS important. Next, if you are using 2020A's, the echo from the modem (back down the receive line while transmitting) is not done within the modem but at the star coupler. Thus a machine might complain about late echo. We have just installed some 3030A's which do local echo and block out the echo from the coupler and all of our problems and errors (DECNET errors on every packet with 2020's) have gone away. - Carl Beame [Ed note: The 2020 is an old product and is no longer sold. Codenoll told me that the modems (we have 3030 and 3030S) do not do local echo. The measurements with the scope showed delays identical to the calculated delays on the three modems we have.] From: leong@andrew.cmu.edu (John Leong) Looking at your topology, it does not look like you have a distance or propagation time problem. I am assuming GUS is your problem GOULD machine. Have you establish that the GUS interface, fibre transceiver and the fibre are all O.K. ? If it was us, we would have checked it out as follows : disconnected both USNA and USNA-CS from the net and put a portable PC running the Netwatch provided MIT's PCIP to do snooping at the star hub just to make sure that GUS is transmitting fine. I know of a number of problems associated with asymetrical passive star hub network where some spines are much longer than the other, although it doesn't necessary explain you problem. However, you may be interested for future reference just the same. One problem is receiver saturation. The receiver of a station near to the hub can get blasted by the transmitter of a station also near to the hub. Your 75M link to USNA-CS may qualify for such problem, but then again, it may not. Another more obscure problem has to do with collision. Most reciver has an ACG (Automatic Gain Control) which essentially try to pick out signal from background noise. When a station on a long spine transmit to a station on another long spine *at the same time as* one on the short spine started transmitting, it is a normal collision. However, because of the relative signal strength, the ACG of the nearer staion's receiver may view the remote signal as noise and not count it as a collision for retry. On the other hand relative value as seen by the receiving station may not be significant enough for the remote stations signal to be dropped off as noise. In which case, you have an undeteced collision. Ungermann Bass sells the same set up as Codenol. However, for asymetrical network, they strongly recommend the use of an active hub ... but there again, they may just like to make money since the active hub is anything by cheap. John leong leong@andrew.cmu.edu [Ed note: I also thought the problem was optical power levels. I spent a lot of time checking that aspect. Only after I checked the optical signal levels and then got out the scope, opened up the xcvr and checked the transmit and receive signals at the transceiver cable connector did I decide that the optical stuff was indeed ok.] From: "Robert J. Reschly Jr." I don't have any helpful answers for you, but I do have an aside. One of the nicer things that gould has provided is a program called enfunc(8). When invoked with the stats option (/etc/enfunc en0 stats) it displays a nicely formatted summary of the interface's activity. Just thought you may be interested (in case you had not noticed it yet). [Ed note: This program is crucial to the problem solution (at least for us).] From: Preston Mullen On our 9005, Gould had to modify their Ethernet device driver software to turn on that "transmit regardless of carrier sense" bit so that their Ethernet card would work properly here with a DEC DELNI. This was supposedly because of some timing problems, for which I've never had an adequate explanation. (Broadband Ethernet, e.g. DEC DECOM, would supposedly require the same fix.) They also changed the Ethernet board itself in some way (perhaps to implement the "ignore carrier sense" bit?) The work was done in early June; I think the board dated back to November-December. I was told that the ability to set or reset this would eventually be moved into the kernel so that it could be changed dynamically. Caveat: I may have some of this wrong; unfortunately, I never got anything in writing from Gould about this problem and solution. Everything has worked fine since the change was made. Preston Mullen [Ed note: Just like Scott's fix at Cornell.] MISC INFO Lew Law at Harvard University also called me Monday (they have a rather large configuration there). He couldn't offer much in the way of concrete solutions after discussing all the testing I had already done. Bart Brooks at Gould was really prompt; he called EARLY Monday and said that the control bit in the interface was indeed the problem and that there were two solutions (see below). THE SOLUTION Bart Brooks at Gould confirmed that the "Transmit without carrier sense" bit was the problem. There were two solutions: 1. Cornell (and NRL) have a different prom set which turns the bit on at initialization; get a set of those proms for the interface. 2. The UTX 2.0 software driver (and enfunc program mentioned above) contain code to set the bit. Get a copy of this software and use it to set the bit. I made the necessary changes to the ethernet driver to set the "tnosense" bit. Running enfunc (a version that knows about setting tnosense) set the bit (as reported by the driver). However, that didn't make the thing work. The timing measurements showed that the 9050 was only sending 10us long packets - much smaller than a full ethernet packet. Called Gould to ask for help. Bart Brooks emailed me a manual page on enfunc (received this morning). One of the notes was to "re-ifconfig" the interface after running enfunc. Funny, when that procedure is used, it works! We've not seen any errors reported by the interface since this morning when it started working. For those interested, the functionality of the new driver and enfunc will be in UTX 2.0. One bad thing about this interface is that it uses a micro on board which doesn't contain code to allow the user to examine the state of the on-board control bits. The driver tells the board what to do and remembers what has been sent. The people at Codenoll were very patient with my questions during the testing and diagnosis of the problem (which turned out to not be their fault). As an aside, our Tektronix 6130 had the same symptoms when attached to the fiber transceiver. I called Excelan about their interface (which we will be using in a gateway on the fiber net later this year) and was told that there is a jumper on the card to affect the same "transmit with no carrier sense" operation. I have one remaining question: The old December 1982, IEEE 802.3 DRAFT I have (our final is still on order) says under the section on "Transmit Media Access Management": "After the last bit of the passing frame (i.e., when carrierSense changes from true to false), the CSMA/CD Media Access sublayer continues to defer for a proper interframe spacing, interFrameSpacing (see Section 4.2.3.2.2). At the end of the interframe spacing of that time, if it has a frame waiting to be transmitted, transmission is initiated independent of the value of carrierSense. When transmission has completed (or immediately, if there was nothing to transmit) the CSMA/CD Media Access sublayer resumes its original monitoring of carrierSense." This seems to imply that the interface should not monitor carrier during transmit. Could someone more familiar with the spec elaborate? Thanks to everyone for their help; especially Gould who had a bunch of people working on it. -tcs Terry Slattery U.S. Naval Academy 301-267-4413 ARPA: tcs@usna.arpa UUCP: decvax!brl-smoke!usna!tcs ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092414070101> Received: from USNA.ARPA by SRI-NIC.ARPA with TCP; Wed 24 Sep 86 17:17:50-PDT Date: Wed, 24 Sep 86 18:07:01 EDT From: Terry Slattery To: tcp-ip@SRI-NIC.ARPA, gouldbugs@BRL.ARPA cc: tcs@USNA.ARPA, disque@USNA.ARPA Subject: Fiber Ethernet problem solved The fiber ethernet problem has been solved. This is rather long (~200 lines) and includes info supplied by various people on the net. If you only are interested in the solution, skip down to "THE SOLUTION". First, a synopsis of the problem. SYNOPSIS A Gould 9050 connected via a Codenoll Ethernet over fiber optic network wouldn't talk to a Vax 780 (or Gould 6050 co-located with the 780). The Goulds run thier UTX Unix product. The fiber's optical power levels checked out to be within spec. The 9050 could hear rwho packets from the 780. The 9050 would report errors on EVERY outgoing packet. Timing estimates showed the 9050 getting receive carrier about 8us after transmit started. The controller manual noted a bit which when set would: "Transmit even if no arrrier sense signal is detected." but the driver didn't contain code to set the bit. A recent note to these lists from Cornell (I hope this is right this time) suggested that the 9050 needed to have this bit set. INPUT FROM OTHERS ON THESE LISTS From: swb@devvax.tn.cornell.edu (Scott Brim) I'm pretty sure I know what that bit is (haven't looked at the Gould ethernet manual for a year) -- and I don't think it's your problem -- but here's an explanation of the bit: The Gould board uses the 82586 controller chip. There's an option in the 82586 to look for its own signal coming back from the transceiver within a certain amount of time. It used to be that you couldn't use a "transceiver cable" more than a certain length (I remember 6 ns, but that seems awfully short). They turned this off for us -- it's just a change to an initialization bit in the PROMs on the Ethernet board. Scott [Ed note: I didn't get any info from Gould on the actual time delay over which the system would break, but our 6050 would work in place of the 780 and the time delay there was ~4us (calculated and measured).] From: Here at McMaster University we have a star coupler with 4 legs of around 1500 ft. . We were using Codelink 2020A modems, we found that we were able to transmit from leg 1 to leg (2,3,4) and leg 2 to leg (1,3,4) we were unable to transmit from leg 3 to leg 4. This problem cleared up after trying several modems on leg 4. Thus the matching of modems IS important. Next, if you are using 2020A's, the echo from the modem (back down the receive line while transmitting) is not done within the modem but at the star coupler. Thus a machine might complain about late echo. We have just installed some 3030A's which do local echo and block out the echo from the coupler and all of our problems and errors (DECNET errors on every packet with 2020's) have gone away. - Carl Beame [Ed note: The 2020 is an old product and is no longer sold. Codenoll told me that the modems (we have 3030 and 3030S) do not do local echo. The measurements with the scope showed delays identical to the calculated delays on the three modems we have.] From: leong@andrew.cmu.edu (John Leong) Looking at your topology, it does not look like you have a distance or propagation time problem. I am assuming GUS is your problem GOULD machine. Have you establish that the GUS interface, fibre transceiver and the fibre are all O.K. ? If it was us, we would have checked it out as follows : disconnected both USNA and USNA-CS from the net and put a portable PC running the Netwatch provided MIT's PCIP to do snooping at the star hub just to make sure that GUS is transmitting fine. I know of a number of problems associated with asymetrical passive star hub network where some spines are much longer than the other, although it doesn't necessary explain you problem. However, you may be interested for future reference just the same. One problem is receiver saturation. The receiver of a station near to the hub can get blasted by the transmitter of a station also near to the hub. Your 75M link to USNA-CS may qualify for such problem, but then again, it may not. Another more obscure problem has to do with collision. Most reciver has an ACG (Automatic Gain Control) which essentially try to pick out signal from background noise. When a station on a long spine transmit to a station on another long spine *at the same time as* one on the short spine started transmitting, it is a normal collision. However, because of the relative signal strength, the ACG of the nearer staion's receiver may view the remote signal as noise and not count it as a collision for retry. On the other hand relative value as seen by the receiving station may not be significant enough for the remote stations signal to be dropped off as noise. In which case, you have an undeteced collision. Ungermann Bass sells the same set up as Codenol. However, for asymetrical network, they strongly recommend the use of an active hub ... but there again, they may just like to make money since the active hub is anything by cheap. John leong leong@andrew.cmu.edu [Ed note: I also thought the problem was optical power levels. I spent a lot of time checking that aspect. Only after I checked the optical signal levels and then got out the scope, opened up the xcvr and checked the transmit and receive signals at the transceiver cable connector did I decide that the optical stuff was indeed ok.] From: "Robert J. Reschly Jr." I don't have any helpful answers for you, but I do have an aside. One of the nicer things that gould has provided is a program called enfunc(8). When invoked with the stats option (/etc/enfunc en0 stats) it displays a nicely formatted summary of the interface's activity. Just thought you may be interested (in case you had not noticed it yet). [Ed note: This program is crucial to the problem solution (at least for us).] From: Preston Mullen On our 9005, Gould had to modify their Ethernet device driver software to turn on that "transmit regardless of carrier sense" bit so that their Ethernet card would work properly here with a DEC DELNI. This was supposedly because of some timing problems, for which I've never had an adequate explanation. (Broadband Ethernet, e.g. DEC DECOM, would supposedly require the same fix.) They also changed the Ethernet board itself in some way (perhaps to implement the "ignore carrier sense" bit?) The work was done in early June; I think the board dated back to November-December. I was told that the ability to set or reset this would eventually be moved into the kernel so that it could be changed dynamically. Caveat: I may have some of this wrong; unfortunately, I never got anything in writing from Gould about this problem and solution. Everything has worked fine since the change was made. Preston Mullen [Ed note: Just like Scott's fix at Cornell.] MISC INFO Lew Law at Harvard University also called me Monday (they have a rather large configuration there). He couldn't offer much in the way of concrete solutions after discussing all the testing I had already done. Bart Brooks at Gould was really prompt; he called EARLY Monday and said that the control bit in the interface was indeed the problem and that there were two solutions (see below). THE SOLUTION Bart Brooks at Gould confirmed that the "Transmit without carrier sense" bit was the problem. There were two solutions: 1. Cornell (and NRL) have a different prom set which turns the bit on at initialization; get a set of those proms for the interface. 2. The UTX 2.0 software driver (and enfunc program mentioned above) contain code to set the bit. Get a copy of this software and use it to set the bit. I made the necessary changes to the ethernet driver to set the "tnosense" bit. Running enfunc (a version that knows about setting tnosense) set the bit (as reported by the driver). However, that didn't make the thing work. The timing measurements showed that the 9050 was only sending 10us long packets - much smaller than a full ethernet packet. Called Gould to ask for help. Bart Brooks emailed me a manual page on enfunc (received this morning). One of the notes was to "re-ifconfig" the interface after running enfunc. Funny, when that procedure is used, it works! We've not seen any errors reported by the interface since this morning when it started working. For those interested, the functionality of the new driver and enfunc will be in UTX 2.0. One bad thing about this interface is that it uses a micro on board which doesn't contain code to allow the user to examine the state of the on-board control bits. The driver tells the board what to do and remembers what has been sent. The people at Codenoll were very patient with my questions during the testing and diagnosis of the problem (which turned out to not be their fault). As an aside, our Tektronix 6130 had the same symptoms when attached to the fiber transceiver. I called Excelan about their interface (which we will be using in a gateway on the fiber net later this year) and was told that there is a jumper on the card to affect the same "transmit with no carrier sense" operation. I have one remaining question: The old December 1982, IEEE 802.3 DRAFT I have (our final is still on order) says under the section on "Transmit Media Access Management": "After the last bit of the passing frame (i.e., when carrierSense changes from true to false), the CSMA/CD Media Access sublayer continues to defer for a proper interframe spacing, interFrameSpacing (see Section 4.2.3.2.2). At the end of the interframe spacing of that time, if it has a frame waiting to be transmitted, transmission is initiated independent of the value of carrierSense. When transmission has completed (or immediately, if there was nothing to transmit) the CSMA/CD Media Access sublayer resumes its original monitoring of carrierSense." This seems to imply that the interface should not monitor carrier during transmit. Could someone more familiar with the spec elaborate? Thanks to everyone for their help; especially Gould who had a bunch of people working on it. -tcs Terry Slattery U.S. Naval Academy 301-267-4413 ARPA: tcs@usna.arpa UUCP: decvax!brl-smoke!usna!tcs ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609242345.AA00400%40MCR.UMICH.EDU] <1986092415455800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hwb@MCR.UMICH.EDU (Hans-Werner Braun) Newsgroups: mod.protocols.tcp-ip Subject: Standard X.25. Message-ID: <8609242345.AA00400@MCR.UMICH.EDU> Date: Wed, 24-Sep-86 19:45:58 EDT Article-I.D.: MCR.8609242345.AA00400 Posted: Wed Sep 24 19:45:58 1986 Date-Received: Thu, 25-Sep-86 05:01:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa The result of my inquiry some days ago is that Mitre claims to have the only Standard X.25 port on the Arpanet (installed about two weeks ago) with so far nothing connected to it. They intend to connect a host soon, though. I have not heard about any other *installed* Standard X.25 ports on Arpanet PSNs. -- Hans-Werner ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609252223.AA03958%40seismo.CSS.GOV] <1986092514235000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rick@SEISMO.CSS.GOV (Rick Adams) Newsgroups: mod.protocols.tcp-ip Subject: new hostnumber for seismo. Message-ID: <8609252223.AA03958@seismo.CSS.GOV> Date: Thu, 25-Sep-86 18:23:50 EDT Article-I.D.: seismo.8609252223.AA03958 Posted: Thu Sep 25 18:23:50 1986 Date-Received: Fri, 26-Sep-86 20:19:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa As of a few hours ago, seismo.CSS.GOV may ONLY be reached at the host number 192.12.141.25. All other addresses should not be used as they connect to another machine. Please change this in your local host tables until the NIC has incorporated them into the master tables. Of course, if you are using a domain server, you will get the correct address the next time you query the CSS.GOV servers. ---rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860925-201216-4810%40Xerox] <1986092519120500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Murray.pa@XEROX.COM Newsgroups: mod.protocols.tcp-ip Subject: Re: Fiber Ethernet problem solved Message-ID: <860925-201216-4810@Xerox> Date: Thu, 25-Sep-86 23:12:05 EDT Article-I.D.: Xerox.860925-201216-4810 Posted: Thu Sep 25 23:12:05 1986 Date-Received: Fri, 26-Sep-86 20:41:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa "This seems to imply that the interface should not monitor carrier during transmit. Could someone more familiar with the spec elaborate?" The main idea is that there should be a 9.6 microsecond minimum gap between packets so that the receiver can get ready to grab the next packet. Dropping packets can easily have disasterous impact on performance. A bit of time will normaly simplify the hardware design. The fine print is trying to say (I think) that after the transmitter waits 9.6 microseconds, it shouldn't wait again/more (as if it were starting fresh and the middle of a packet was already on the wire) just because it now looks like there is a packet already on the wire. That packet started just a very short while ago, probably less that a bit time, (if everybody is following the rules). If nothing else, the fraction of a bit difference in the phase of the transmit clocks at the two stations could easily provoke this case. When the (second/interesting) transmitter does starts to transmit, it will cause a collision. That's the desired result when two stations try to transmit at the "same" time. Note that the fractional bit race condition actually happens quite often. Consider three stations on an ethernet. Call them left to right A, B, and C. Suppose A is transmitting and B and C are waiting to send. When A finishes, the end of packet will sweep down the wire. When it gets to B, B's 9.6 microsecond clock starts ticking. A while later, C's clock will start too. When B's clock expires, the wire (around B) is empty so B starts transmitting. When C's clock goes off, B's new packet is just about to arrive at C or has just arrived at C. Because the wire delays cancel out in this configuration, fractions of a bit dure to clock synchronization are important. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609261313.AA07678%40mitre.ARPA] <1986092610122900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mckee@MITRE.ARPA Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8609261313.AA07678@mitre.ARPA> Date: Fri, 26-Sep-86 14:12:29 EDT Article-I.D.: mitre.8609261313.AA07678 Posted: Fri Sep 26 14:12:29 1986 Date-Received: Sat, 27-Sep-86 05:16:54 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Washington, D.C. Lines: 247 Approved: tcp-ip@sri-nic.arpa Marshall Abrams, a Security guru here at MITRE, sent me a copy of the following note by Brian Reid. The note has little to do with TCP and IP, but it is instructive to learn how our networks are being used for nefarious purposes, and besides, there is a certain lascivious pleasure in reading about somebody elses troubles. H. C. McKee -------------------------- From: reid@decwrl.DEC.COM (Brian Reid) Date: 16 Sep 1986 1519-PDT (Tuesday) To: Peter G. Neumann [FOR RISKS] Subject: Massive UNIX breakins at Stanford Lessons learned from a recent rash of Unix computer breakins Introduction A number of Unix computers in the San Francisco area have recently been plagued with breakins by reasonably talented intruders. An analysis of the breakins (verified by a telephone conversation with the intruders!) show that the networking philosophy offered by Berkeley Unix, combined with the human nature of systems programmers, creates an environment in which breakins are more likely, and in which the consequences of breakins are more dire than they need to be. People who study the physical security of buildings and military bases believe that human frailty is much more likely than technology to be at fault when physical breakins occur. It is often easier to make friends with the guard, or to notice that he likes to watch the Benny Hill show on TV and then wait for that show to come on, than to try to climb fences or outwit burglar alarms. Summary of Berkeley Unix networking mechanism: The user-level networking features are built around the principles of "remote execution" and "trusted host". For example, if you want to copy a file from computer A to computer B, you type the command rcp A:file B:file If you want to copy the file /tmp/xyz from the computer that you are now using over to computer C where it will be called /usr/spool/breakin, you type the command rcp /tmp/xyz C:/usr/spool/breakin The decision of whether or not to permit these copy commands is based on "permission" files that are stored on computers A, B, and C. The first command to copy from A to B will only work if you have an account on both of those computers, and the permission file stored in your directory on both of those computers authorizes this kind of remote access. Each "permission file" contains a list of computer names and user login names. If the line "score.stanford.edu reid" is in the permission file on computer "B", it means that user "reid" on computer "score.stanford.edu" is permitted to perform remote operations such as rcp, in or out, with the same access privileges that user "reid" has on computer B. How the breakins happened. One of the Stanford campus computers, used primarily as a mail gateway between Unix and IBM computers on campus, had a guest account with user id "guest" and password "guest". The intruder somehow got his hands on this account and guessed the password. There are a number of well-known security holes in early releases of Berkeley Unix, many of which are fixed in later releases. Because this computer is used as a mail gateway, there was no particular incentive to keep it constantly up to date with the latest and greatest system release, so it was running an older version of the system. The intruder instantly cracked "root" on that computer, using the age-old trojan horse trick. (He had noticed that the guest account happened to have write permission into a certain scratch directory, and he had noticed that under certain circumstances, privileged jobs could be tricked into executing versions of programs out of that scratch directory instead of out of the normal system directories). Once the intruder cracked "root" on this computer, he was able to assume the login identity of everybody who had an account on that computer. In particular, he was able to pretend to be user "x" or user "y", and in that guise ask for a remote login on other computers. Sooner or later he found a [user,remote-computer] pair for which there was a permission file on the other end granting access, and now he was logged on to another computer. Using the same kind of trojan horse tricks, he was able to break into root on the new computer, and repeat the process iteratively. In most cases the intruder left trojan-horse traps behind on every computer that he broke into, and in most cases he created login accounts for himself on the computers that he broke into. Because no records were kept, it is difficult to tell exactly how many machines were penetrated, but the number could be as high as 30 to 60 on the Stanford campus alone. An intruder using a similar modus operandi has been reported at other installations. How "human nature" contributed to the problem The three technological entry points that made this intrusion possible were: * The large number of permission files, with entirely too many permissions stored in them, found all over the campus computers (and, for that matter, all over the ARPAnet). * The presence of system directories in which users have write permission. * Very sloppy and undisciplined use of search paths in privileged programs and superuser shell scripts. Permissions: Berkeley networking mechanism encourages carelessness. The Berkeley networking mechanism is very very convenient. I use it all the time. You want to move a file from one place to another? just type "rcp" and it's there. Very fast and very efficient, and quite transparent. But sometimes I need to move a file to a machine that I don't normally use. I'll log on to that machine, quickly create a temporary permission file that lets me copy a file to that machine, then break back to my source machine and type the copy command. However, until I'm quite certain that I am done moving files, I don't want to delete my permission file from the remote end or edit that entry out of it. Most of us use display editors, and oftentimes these file copies are made to remote machines on which the display editors don't always work quite the way we want them to, so there is a large nuisance factor in running the text editor on the remote end. Therefore the effort in removing one entry from a permission file--by running the text editor and editing it out--is high enough that people don't do it as often as they should. And they don't want to *delete* the permission file, because it contains other entries that are still valid. So, more often than not, the permission files on rarely-used remote computers end up with extraneous permissions in them that were installed for a one-time-only operation. Since the Berkeley networking commands have no means of prompting for a password or asking for the name of a temporary permission file, everybody just edits things into the permanent permission file. And then, of course, they forget to take it out when they are done. Write permission in system directories permits trojan horse attacks. All software development is always behind schedule, and programmers are forever looking for ways to do things faster. One convenient trick for reducing the pain of releasing new versions of some program is to have a directory such as /usr/local/bin or /usr/stanford/bin or /usr/new in which new or locally-written versions of programs are kept, and asking users to put that directory on their search paths. The systems programmers then give themselves write access to that directory, so that they can intall a new version just by typing "make install" rather than taking some longer path involving root permissions. Furthermore, it somehow seems more secure to be able to install new software without typing the root password. Therefore it is a nearly-universal practice on computers used by programmers to have program directories in which the development programmers have write permission. However, if a user has write permission in a system directory, and if an intruder breaks into that user's account, then the intruder can trivially break into root by using that write permission to install a trojan horse. Search paths: people usually let convenience dominate caution. Search paths are almost universally misused. For example, many people write shell scripts that do not specify an explicit search path, which makes them vulnerable to inheriting the wrong path. Many people modify the root search path so that it will be convenient for systems programmers to use interactively as the superuser, forgetting that the same search path will be used by system maintenance scripts run automatically during the night. It is so difficult to debug failures that are caused by incorrect search paths in automatically-run scripts that a common "repair" technique is to put every conceivable directory into the search path of automatically-run scripts. Essentially every Unix computer I have ever explored has grievous security leaks caused by underspecified or overlong search paths for privileged users. Summary conclusion: Wizards cause leaks The people who are most likely to be the cause of leaks are the wizards. When something goes wrong on a remote machine, often a call goes in to a wizard for help. The wizard is usually busy or in a hurry, and he often is sloppier than he should be with operations on the remote machine. The people who are most likely to have permission files left behind on stray remote machines are the wizards who once offered help on that machine. But, alas, these same wizards are the people who are most likely to have write access to system directories on their home machines, because it seems to be in the nature of wizards to want to collect as many permissions as possible for their accounts. Maybe that's how they establish what level of wizard that they are. The net result is that there is an abnormally high probability that when an errant permission file is abused by an intruder, that it will lead to the account of somebody who has an unusually large collection of permissions on his own machine, thereby making it easier to break into root on that machine. Conclusions. My conclusions from all this are these: * Nobody, no matter how important, should have write permission into any directory on the system search path. Ever. * Somebody should carefully re-think the user interface of the Berkeley networking mechanisms, to find ways to permit people to type passwords as they are needed, rather than requiring them to edit new permissions into their permissions files. * The "permission file" security access mechanism seems fundamentally vulnerable. It would be quite reasonable for a system manager to forbid the use of them, or to drastically limit the use of them. Mechanized checking is easy. * Programmer convenience is the antithesis of security, because it is going to become intruder convenience if the programmer's account is ever compromised. This is especially true in setting up the search path for the superuser. Lament I mentioned in the introduction that we had talked to the intruders on the telephone. To me the most maddening thing about this intrusion was not that it happened, but that we were unable to convince any authorities that it was a serious problem, and could not get the telephone calls traced. At one point an intruder spent 2 hours talking on the telephone with a Stanford system manager, bragging about how he had done it, but there was no way that the call could be traced to locate him. A few days later, I sat there and watched the intruder log on to one Stanford comptuer, and I watched every keystroke that he typed on his keyboard, and I watched him break in to new directories, but there was nothing that I could do to catch him because he was coming in over the telephone. Naturally as soon as he started to do anything untoward I blasted the account that he was using and logged him off, but sooner or later new intruders will come along, knowing that they will not be caught because what they are doing is not considered serious. It isn't necessarily serious, but it could be. I don't want to throw such people in jail, and I don't want to let them get away either. I just want to catch them and shout at them and tell them that they are being antisocial. Brian Reid DEC Western Research and Stanford University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12242105738.26.BILLW%40Score.Stanford.EDU] <1986092614151700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: BILLW@SU-SCORE.ARPA (William "Chops" Westfield) Newsgroups: mod.protocols.tcp-ip Subject: Why is the ARPANet in such bad shape these days? Message-ID: <12242105738.26.BILLW@Score.Stanford.EDU> Date: Fri, 26-Sep-86 18:15:17 EDT Article-I.D.: Score.12242105738.26.BILLW Posted: Fri Sep 26 18:15:17 1986 Date-Received: Sun, 28-Sep-86 00:45:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Both repsonse and throughput between Stanford and SRi is pretty awful, and they are only one IMP apart. Trying to FTP a file from a host that is further away seems nearly impossible. Is this just a local problem, say with the Stanford IMP, or are other people having similar problems? Note that this is NOT a gateway related problem, since for many of the paths Ive tried, no gateways should be involved. BillW ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092703515200> Received: from CSL.SRI.COM by SRI-NIC.ARPA with TCP; Sat 27 Sep 86 10:46:35-PDT Date: Sat 27 Sep 86 10:51:52-PDT From: Karl Auerbach Subject: SMTP, 2600, and the security of mail To: tcp-ip@SRI-NIC.ARPA A while back I saw a copy of a newsletter titled "2600" which included source code demonstrating how one could pretend to be an SMTP engine and inject false mail into a host. Although the code had a few flaws, its general structure looked plausable (and short -- about 25 lines of C). --karl-- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609280050.AA11782%40ucbvax.Berkeley.EDU] <1986092708520000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: BEAME@MCMASTER.BITNET Newsgroups: mod.protocols.tcp-ip Subject: Re: Peace fullness. Message-ID: <8609280050.AA11782@ucbvax.Berkeley.EDU> Date: Sat, 27-Sep-86 12:52:00 EDT Article-I.D.: ucbvax.8609280050.AA11782 Posted: Sat Sep 27 12:52:00 1986 Date-Received: Sun, 28-Sep-86 00:41:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Speeking as the president of one of those companies out there trying to make a living by selling TCP/IP code for PC's ... As a developer it IS my responcibility to produce a product that my clients desire and to develop new features and approches. I have done just that, but I am afraid to market it. Why ? Because the Universities will produce a public (or very cheap) version and have their name behind it! All my time, effort and MONEY will be wasted. What can I do ? Get a Patent ? That takes years, and the protocols might have changed by than. I ask you, what would you do if you wanted to sell such a product. (Remember were a very small company) - Carl Beame, President Beame & Whiteside Software Ltd. 259 Fiddler's Green Rd. Ancaster, Ontario, Canada. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092708520001> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Sat 27 Sep 86 09:54:00-PDT Received: from (BEAME)MCMASTER.BITNET by WISCVM.WISC.EDU on 09/27/86 at 11:53:17 CDT Date: Sat, 27 Sep 86 12:52 EDT From: Subject: Re: Peace fullness. To: tcp-ip@SRI-nic.arpa X-Original-To: tcp-ip@SRI-nic.arpa, BEAME Speeking as the president of one of those companies out there trying to make a living by selling TCP/IP code for PC's ... As a developer it IS my responcibility to produce a product that my clients desire and to develop new features and approches. I have done just that, but I am afraid to market it. Why ? Because the Universities will produce a public (or very cheap) version and have their name behind it! All my time, effort and MONEY will be wasted. What can I do ? Get a Patent ? That takes years, and the protocols might have changed by than. I ask you, what would you do if you wanted to sell such a product. (Remember were a very small company) - Carl Beame, President Beame & Whiteside Software Ltd. 259 Fiddler's Green Rd. Ancaster, Ontario, Canada. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609280151.AA12210%40ucbvax.Berkeley.EDU] <1986092709515200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: AUERBACH@CSL.SRI.COM (Karl Auerbach) Newsgroups: mod.protocols.tcp-ip Subject: SMTP, 2600, and the security of mail Message-ID: <8609280151.AA12210@ucbvax.Berkeley.EDU> Date: Sat, 27-Sep-86 13:51:52 EDT Article-I.D.: ucbvax.8609280151.AA12210 Posted: Sat Sep 27 13:51:52 1986 Date-Received: Sun, 28-Sep-86 00:42:26 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa A while back I saw a copy of a newsletter titled "2600" which included source code demonstrating how one could pretend to be an SMTP engine and inject false mail into a host. Although the code had a few flaws, its general structure looked plausable (and short -- about 25 lines of C). --karl-- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092711070000> Mail-From: STJOHNS created at 27-Sep-86 18:08:32 Date: 27 Sep 1986 18:07-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Peace fullness. From: STJOHNS@SRI-NIC.ARPA To: BEAME%MCMASTER.BITNET@WISCVM.WISC.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]27-Sep-86 18:07:43.STJOHNS> In-Reply-To: The message of Sat, 27 Sep 86 12:52 EDT from The only thing I can suggest is make your product better than the rest on the market. And be prepared to support it in a timely manner to your customers. You are correct, Universities do produce lots of "cheap" software, but it is usually a one time deal done as part of a thesis. The exceptions being projects funded by the gov't agencies. In the US at least, you can't patent a software product, but you can protect it as a trade secret. I think you can also patent an algorithm (for ex the RSA encryption algorithm) There are risks to any business, no guarantees. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [SRA.12242404326.BABYL%40XX.LCS.MIT.EDU] <1986092717350000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: SRA@XX.LCS.MIT.EDU (Rob Austein) Newsgroups: mod.protocols.tcp-ip Subject: Why is the ARPANet in such bad shape these days? Message-ID: Date: Sat, 27-Sep-86 21:35:00 EDT Article-I.D.: XX.SRA.12242404326.BABYL Posted: Sat Sep 27 21:35:00 1986 Date-Received: Sun, 28-Sep-86 15:59:21 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 33 Approved: tcp-ip@sri-nic.arpa Bill, No, the ARPANET problem is definitely not just at Stanford. MIT has been moderately crippled by this for weeks now (since the start of the fall semester, which is probably -not- a coincidence). MC and XX have a hard time talking to each other and they are on the same IMP. The NOC claims that this is true for pretty much the entire ARPAnet. Apparently MILNET is somewhate better off. The NOC is refering to this mess as a "congestion problem" at the IMP level. The current theory the last few times I talked to the NOC was that we have managed to reach the bandwidth limit of the existing hardware. A somewhat scary thought. If this is in fact the case (and there is circumstancial evidence that it is, such as the fact that the net becomes usable again during off hours), we are in for a long siege, since it is guarenteed to take the DCA and BBN a fair length of time to deploy any new hardware or bring up new trunks. Current thoughts and efforts at MIT are (1) we need more data on the traffic going through the IMPs, and (2) we need to cut down on the amount of traffic going through the IMPs. The two go along with each other to some extent (preliminary results show that roughly 25% of the traffic through the MIT gateway is to or from XX). Some interesting ideas have come up for minimizing load due to email, if that turns out to be a prime offender (surprisingly, the preliminary statistics don't seem to indicate that). If there is anybody else out there doing analysis of network traffic, please share it. Also, if there is anybody from BBN who knows more about the problem and is willing to share it, -please- do. It's hard to make any kind of contingency plans in a vacuum. --Rob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609280249.AA16461%40topaz.rutgers.edu] <1986092718491100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: Re: SMTP, 2600, and the security of mail Message-ID: <8609280249.AA16461@topaz.rutgers.edu> Date: Sat, 27-Sep-86 22:49:11 EDT Article-I.D.: topaz.8609280249.AA16461 Posted: Sat Sep 27 22:49:11 1986 Date-Received: Sun, 28-Sep-86 16:46:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa It is moderately obvious from the protocol that you can spoof SMTP. What we tell our users about mail is the following: - here is how to tell from the headers whether a message was delivered locally or via SMTP. (Details vary per system.) - mail that is delivered locally is probably from the person it claims to be. That depends upon the overall security of the system, which is never perfect, but probably it is OK. But don't stake your life on it. - for mail that came in via network, all you can really be sure of is the identity of the most recent host in the link. The received line will show the name of that host. If the host claimed to be someone other than it was, we will tell you. (This is in the DEC-20 implementation. I'm not sure whether our Unix code does this. But I think it does.) Unfortunately, the protocols are such that even if that machine is secure, a user on it could send mail to us claiming to be absolutely anyone he wanted to be. In general, if you want to be more certain who the mail came from, send a response back, referring to the message. If you get a message "what are you talking about?" you know you have been spoofed. This assumes that the system the author is residing on keeps his mail private. You don't need C code to do this spoofing. Just say "telnet host 25". That will connect you to their SMTP server. You can then type a message claiming to be anybody you like. We use this for debugging. The format of the commands is simple enough that it is perfectly practical for a person to do. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609272345.AA07129%40rsch.wisc.edu] <1986092718544100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: dave@RSCH.WISC.EDU (Dave Cohrs) Newsgroups: mod.protocols.tcp-ip Subject: Re: Why is the ARPANet in such bad shape these days? Message-ID: <8609272345.AA07129@rsch.wisc.edu> Date: Sat, 27-Sep-86 22:54:41 EDT Article-I.D.: rsch.8609272345.AA07129 Posted: Sat Sep 27 22:54:41 1986 Date-Received: Sun, 28-Sep-86 00:43:27 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa I don't know why it's so bad, but no, it is *not* a localized problem. Hosts at UW-Madison are also having problems reaching hosts farther away than our local PSN. The worst problems (of course) are reaching hosts on the east coast, especially Rutgers and CSS.GOV sites. The problem seems to be time/day-of-the-week related, so I assume it's a congestion problem (response time seems pretty good right now), but I'm not a net-watcher, so don't take that as gospel. There also seem to be some severe routing problems. On one occation this past week, the packet turnaround time from our gateway to the CSS gateway (10.0.0.25) was about 1sec, while one hop farther, from a host on our Pronet to 10.0.0.25 was about 8sec with peaks of over 20sec and many packets were lost. Actually, one site in the Bay Area has started setting up new UUCP links (using good ol' dialup connections) to make sure that their mail will get through. dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609280255.AA16730%40topaz.rutgers.edu] <1986092718555200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: Re: Why is the ARPANet in such bad shape these days? Message-ID: <8609280255.AA16730@topaz.rutgers.edu> Date: Sat, 27-Sep-86 22:55:52 EDT Article-I.D.: topaz.8609280255.AA16730 Posted: Sat Sep 27 22:55:52 1986 Date-Received: Sun, 28-Sep-86 16:01:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa We apologize for the problems we have caused other sites. I am well aware that Rutgers is among the hardest places to reach. This is a combination of our 9600 baud line into the IMP, and continual crashes of our gateway. We have now replaced our gateway with a gateway from Cisco. It is based on a 68000. It appears to be more reliable than the old 11/23 code we were using before, and has much better tools to monitor what is going on and adjust things. We think that the reliability problems will largely go away, except for TCP protocol problems with individual hosts on our network. Early results suggest that the 9600 baud line has enough bandwidth to keep mail and news flowing. We have long since given up on telnet, though at some times of the day even that may now be practical. We are also exploring an upgrade of the line speed. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [WANCHO.12242430922.BABYL%40SIMTEL20.ARPA] <1986092720010000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: WANCHO@SIMTEL20.ARPA Newsgroups: mod.protocols.tcp-ip Subject: Do we need another protocol? Message-ID: Date: Sun, 28-Sep-86 00:01:00 EDT Article-I.D.: SIMTEL20.WANCHO.12242430922.BABYL Posted: Sun Sep 28 00:01:00 1986 Date-Received: Sun, 28-Sep-86 16:40:50 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa There is a growing trend in the Army to network Intel 310s running Xenix on a fat Ethernet under OpenNet. When asked why OpenNet instead of TCP/IP, the answer most often heard is because OpenNet provides inter-machine file and record-level access at the application level. At one time, there was a brief discussion of the possibility of extending the FTP definition to allow for record-level access. It seemed to me then that FTP was the wrong place and that an entirely new protcol should be defined. Was this ever done and formally recognized as part of the TCP protocol suite? If not, why not? Would it be possible to provide an OpenNet functionality within the TCP confines so that we don't have to provide two otherwise incompatible services requiring two sets of hardware interfaces for every node that should have both capabilities. --Frank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [WANCHO.12242434551.BABYL%40SIMTEL20.ARPA] <1986092720210000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: WANCHO@SIMTEL20.ARPA Newsgroups: mod.protocols.tcp-ip Subject: ARPANET congestion? Message-ID: Date: Sun, 28-Sep-86 00:21:00 EDT Article-I.D.: SIMTEL20.WANCHO.12242434551.BABYL Posted: Sun Sep 28 00:21:00 1986 Date-Received: Sun, 28-Sep-86 16:42:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Over the past three weeks, we have been able to receive mail from ARPANET hosts but not able to even establish connections, or when a connection has been eventually established, send mail and receive acknowledgements within rather generous timeouts to those same hosts. This one-way performance has also been observed in eventually established TELNET connections to various ARPANET hosts, where single-character echoes may take several *minutes* while continuous output, such as directory listings, appear normally. According to the NOC, this is a known problem which is being investigated. Could we have an intermediate report concerning the problem? Are only certain hosts involved? (Our most persistent and common problems have been with CSNET-RELAY and WISCVM due to the volume of mail they pass.) --Frank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609280452.AA00020%40mouton.bellcore.com] <1986092720523700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: karn@MOUTON.BELLCORE.COM (Phil R. Karn) Newsgroups: mod.protocols.tcp-ip Subject: Re: Peace fullness. Message-ID: <8609280452.AA00020@mouton.bellcore.com> Date: Sun, 28-Sep-86 00:52:37 EDT Article-I.D.: mouton.8609280452.AA00020 Posted: Sun Sep 28 00:52:37 1986 Date-Received: Sun, 28-Sep-86 16:45:06 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa This note reinforces an (only half serious) suggestion somebody around here made a little while ago on how to stop ISO/OSI dead in its tracks. First, write a full-blown implementation of their protocols. Test it, document it, do everything you can to make sure it's the best implementation around. Then give it away. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609280455.AA00068%40mouton.bellcore.com] <1986092720552400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: karn@MOUTON.BELLCORE.COM (Phil R. Karn) Newsgroups: mod.protocols.tcp-ip Subject: Re: Why is the ARPANet in such bad shape these days? Message-ID: <8609280455.AA00068@mouton.bellcore.com> Date: Sun, 28-Sep-86 00:55:24 EDT Article-I.D.: mouton.8609280455.AA00068 Posted: Sun Sep 28 00:55:24 1986 Date-Received: Sun, 28-Sep-86 16:44:03 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa I wonder how much of the existing congestion problems would go away if DARPA banned all 4.2BSD sites from the net until they convert to 4.3? Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609280848.AA26039%40topaz.rutgers.edu] <1986092800483900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) Newsgroups: mod.protocols.tcp-ip Subject: odd routings Message-ID: <8609280848.AA26039@topaz.rutgers.edu> Date: Sun, 28-Sep-86 04:48:39 EDT Article-I.D.: topaz.8609280848.AA26039 Posted: Sun Sep 28 04:48:39 1986 Date-Received: Sun, 28-Sep-86 16:48:06 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 57 Approved: tcp-ip@sri-nic.arpa I have been looking at our EGP routings. I checked a few sites that I know we talk to a lot. Our current EGP peers are yale-gw and css-ring-gw. (We keep a list of possible peers, and the gateway picks 2. It will change if one of them becomes inaccessible. This particular pair seems to be fairly stable.) Here I what I found: CMU: As far as I can see, the only way into CMU is cmu-gateway, 10.2.0.14. The EGP table showed 10.3.0.27, which is gateway.isi.edu. We will hope that ISI would be smart enough to give us a redirect if we actually used this route, but it seems odd none the less. We tried to establish a direct EGP connection with cmu-gateway, but we were unable to acquire them. (In addition to the list of potential peers, our gateway also has a list of secondary gateways, all of which it will acquire. The intent is that these are gateways that are so important to us that we don't want to depend upon the core for information about them.) We have ended up adding a static routing to them. MIT: They seem to have 4 different networks. The ones with direct Arpanet gateways are 18 (using 10.0.0.77) and 128.52 (using 10.3.0.6). EGP was telling us to use 10.3.0.27 (isi) and 10.2.0.37 (purdue) respectively. Fortunately, we were able to acquire both of MIT's gateways, so I am simply going to list them as secondary gateways. Stanford: It appears that the only reasonable route to network 18 is stanford-gateway, 10.1.0.11. Our EGP table was telling us to use 10.2.0.37 (purdue-cs-gateway). We were able to acquire the stanford gateway, and have also added them to our list of secondary gateways. Am I doing something wrong? Here is the relevant portion of our current configuration file. I confess that I do not know where the list of primary neighbors came from. It seems to have been developed by one of our systems staff after numerous dealings with the Network Operations Center trying to diagnose problems. Note that the gateway itself is Cisco Systems' commerical version of the Stanford Arpanet gateway. It is based on a 68000, with an ACC 1822 card. This code has probably not been used many places outside of Stanford, so it is certainly possible that there are problems left with it. But it gives every appearance of doing the right thing. primary-neighbors 2 egp-neighbor 10.7.0.63 46 primary ! bbn-net2-gateway egp-neighbor 10.2.0.37 46 primary ! purdue-cs-gw egp-neighbor 10.0.0.94 46 primary ! wisc-gateway egp-neighbor 10.3.0.27 46 primary ! isi-gateway egp-neighbor 10.0.0.25 46 primary ! css-ring-gw (seismo) egp-neighbor 10.0.0.9 46 primary ! harvard-gw egp-neighbor 10.1.0.51 46 primary ! sri-prm-gw egp-neighbor 10.1.0.54 46 primary ! cit-cs-gw egp-neighbor 10.2.0.9 46 primary ! yale-gw # talk directly to our friends, since these tend to have bogus routes egp-neighbor 10.0.0.77 46 ! mit-gw, for net 18 egp-neighbor 10.3.0.6 46 ! mit-ai-gw, for net 128.52 egp-neighbor 10.1.0.11 46 ! stanford-gw, for net 36 # I can't get cmu-gateway to respond to EGP, so do it statically route 128.2.254.36 10.2.0.14 ! cmu-gateway, for net 128.2 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092803103800> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Sun 28 Sep 86 04:15:33-PDT Received: by vax.darpa.mil (4.12/4.7) id AA16297; Sun, 28 Sep 86 07:10:44 edt Date: Sun 28 Sep 86 07:10:38-EDT From: Dennis G. Perry Subject: Re: X.25 on Arpanet To: rms@ACC-SB-UNIX.ARPA Cc: tcp-ip@SRI-NIC.ARPA, gary@BRL-SAGE.ARPA, perry@VAX.DARPA.MIL Message-Id: In-Reply-To: Message from "rms@ACC-SB-UNIX.ARPA (Ron Stoughton)" of Mon, 22 Sep 86 19:06:51 pdt The Arpanet is not yet to PSN6. Most of it is now running C30s and PSN5. One site (USC) is still running an old IMP and PSN4. It will be upgraded and then the Arpanet can move to PSN6. PSN7 testing will begin in the spring. (The C30s mentioned above should read C/30E) dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12242563296.277.SY.KEN%40CU20B.COLUMBIA.EDU] <1986092808084400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: sy.Ken@CU20B.COLUMBIA.EDU (Ken Rossman) Newsgroups: mod.protocols.tcp-ip Subject: Re: ARPANET congestion? Message-ID: <12242563296.277.SY.KEN@CU20B.COLUMBIA.EDU> Date: Sun, 28-Sep-86 12:08:44 EDT Article-I.D.: CU20B.12242563296.277.SY.KEN Posted: Sun Sep 28 12:08:44 1986 Date-Received: Sun, 28-Sep-86 16:49:22 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Over the past three weeks, we have been able to receive mail from ARPANET hosts but not able to even establish connections, or when a connection has been eventually established, send mail and receive acknowledgements within rather generous timeouts to those same hosts... We're seeing much the same symptoms, though in reverse, and with FTP. We are able to make outbound connections to certain sites, but those sites get rejected for inbound connections to us. Got me baffled... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609281308.aa17760%40SEM.BRL.ARPA] <1986092809084200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: ron@BRL.ARPA (Ron Natalie) Newsgroups: mod.protocols.tcp-ip Subject: Re: Why is the ARPANet in such bad shape these days? Message-ID: <8609281308.aa17760@SEM.BRL.ARPA> Date: Sun, 28-Sep-86 13:08:42 EDT Article-I.D.: SEM.8609281308.aa17760 Posted: Sun Sep 28 13:08:42 1986 Date-Received: Sun, 28-Sep-86 20:27:31 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa It may not use gateways, but the ping wars between the BBN gateways impact all net performance as their random behaviour wreaks havoc with the IMPs virtual circuit set up time. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609281848.AA25936%40clyde.ATT.COM] <1986092810485700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: news@clyde.att.com (Netnews Admin) Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8609281848.AA25936@clyde.ATT.COM> Date: Sun, 28-Sep-86 14:48:57 EDT Article-I.D.: clyde.8609281848.AA25936 Posted: Sun Sep 28 14:48:57 1986 Date-Received: Sun, 28-Sep-86 20:29:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa Path: clyde!cbatt!cbosgd!mark From: mark@cbosgd.ATT.COM (Mark Horton) Newsgroups: mod.protocols.tcp-ip Subject: Re: SMTP, 2600, and the security of mail Message-ID: <2629@cbosgd.ATT.COM> Date: 28 Sep 86 15:54:40 GMT References: <8609280151.AA12210@ucbvax.Berkeley.EDU> Organization: AT&T Bell Laboratories, Columbus, Oh Lines: 13 Summary: False SMTP mail is easy to generate, but so is false paper mail AUERBACH@CSL.SRI.COM (Karl Auerbach) writes: > A while back I saw a copy of a newsletter titled "2600" which included > source code demonstrating how one could pretend to be an SMTP engine and > inject false mail into a host. Although the code had a few flaws, its > general structure looked plausable (and short -- about 25 lines of C). Sure it is. But that's not surprising. I can easily generate false paper mail with a phony return address, and dump it into a paper mailbox, too. Nobody ever said EMail was hard to forge. Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609281703.AA20207%40rsch.wisc.edu] <1986092810553900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: dave@RSCH.WISC.EDU (Dave Cohrs) Newsgroups: mod.protocols.tcp-ip Subject: Re: ARPANET congestion? Message-ID: <8609281703.AA20207@rsch.wisc.edu> Date: Sun, 28-Sep-86 14:55:39 EDT Article-I.D.: rsch.8609281703.AA20207 Posted: Sun Sep 28 14:55:39 1986 Date-Received: Sun, 28-Sep-86 20:28:43 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 27 Approved: tcp-ip@sri-nic.arpa There are a few reasons that WISCVM has been hard to reach. First, our gateway has recently been converted from an 11/34 to a VAX 750. The routes that have been generated since the conversion are not always very good (EGP problems). In the long run, the upgrade should be helpful; Wisc-Gateway passes between 0.75 and 1 million packets dayly. Second, there have been some PSN connectivity problems recently. One or two weeks ago, only one of our three neighboring PSNs was alive. Also, our PSN goes "not ready" (as seen by watching the lights on the LH/DH used to connect the gateway to the PSN) once every 20-30 seconds when the load gets high. This condition lasts for 1-2 seconds. This causes lots of packets to get backed up and/or lost. Third, the SMTP mailer on WISCVM has gone through some rough times. I think the version they are running now is stable. Finally, WISCVM is physically connected to our Proteon token ring. The number of errors on this net are extremely high. This seems to be a problem with inferior cables, and not with the Proteon ring itself. However, the old, bad cables are still in place, so the net still barfs constantly. The high error rate causes lots of broken and lost packets, not to mention the time wasted while the controllers try to regenerate lost tokens. Put all of this together, and WISCVM is a tough place to reach. dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609290022.AA15622%40mouton.bellcore.com] <1986092816224700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: karn@MOUTON.BELLCORE.COM (Phil R. Karn) Newsgroups: mod.protocols.tcp-ip Subject: forging SMTP Message-ID: <8609290022.AA15622@mouton.bellcore.com> Date: Sun, 28-Sep-86 20:22:47 EDT Article-I.D.: mouton.8609290022.AA15622 Posted: Sun Sep 28 20:22:47 1986 Date-Received: Mon, 29-Sep-86 00:12:16 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa Not only is paper mail also easy to forge, but so is UUCP mail. At least with SMTP and the internet you have the means to tighten things up if you wish. You can tell who's actually sending you mail by looking at the address on the remote socket, notifying the user if it doesn't match the name the remote sender specifies in the HELO command. Sendmail, at least, will mention this in the Received headers, though you have to know what you're looking at. Certainly not foolproof, but better than UUCP where you generally have NO idea who's really calling you on the phone (unless you've gone whole hog and gotten rid of your generic uucp logins). Electronic mail is fundamentally a datagram service. You should never trust isolated datagrams you receive from any network (be they email messages or IP datagrams) without either some authentication in the message itself or until you've conducted a three-way-handshake with the remote party to check for spoofing. As long as the real person is up and reachable, and the bad guy hasn't subverted routing, this will suffice. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609290025.AA29356%40cbosgd.ATT.COM] <1986092816253500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mark@cbosgd.att.com (Mark Horton) Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8609290025.AA29356@cbosgd.ATT.COM> Date: Sun, 28-Sep-86 20:25:35 EDT Article-I.D.: cbosgd.8609290025.AA29356 Posted: Sun Sep 28 20:25:35 1986 Date-Received: Tue, 30-Sep-86 13:18:34 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa Path: cbosgd!mark From: mark@cbosgd.ATT.COM (Mark Horton) Newsgroups: mod.protocols.tcp-ip Subject: Re: SMTP, 2600, and the security of mail Message-ID: <2632@cbosgd.ATT.COM> Date: 29 Sep 86 00:25:32 GMT References: <8609280151.AA12210@ucbvax.Berkeley.EDU> Organization: AT&T Bell Laboratories, Columbus, Oh Lines: 13 Summary: False SMTP mail is easy to generate, but so is false paper mail AUERBACH@CSL.SRI.COM (Karl Auerbach) writes: > A while back I saw a copy of a newsletter titled "2600" which included > source code demonstrating how one could pretend to be an SMTP engine and > inject false mail into a host. Although the code had a few flaws, its > general structure looked plausable (and short -- about 25 lines of C). Sure it is. But that's not surprising. I can easily generate false paper mail with a phony return address, and dump it into a paper mailbox, too. Nobody ever said EMail was hard to forge. Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092817062400> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Mon 29 Sep 86 05:28:53-PDT Received: from (MAILER)UIUCVMD.BITNET by WISCVM.WISC.EDU on 09/29/86 at 07:27:59 CDT Received: by UIUCVMD (Mailer X1.23) id 2757; Sun, 28 Sep 86 22:08:38 CDT Date: Sun, 28 Sep 86 22:06:24 CDT From: Phil Howard Subject: False mail To: TCP/IP List The security of the Post Office depends on its people, and the services they provide. The same is true of a network. The network can provide better services, such as tell you who REALLY sent the mail, but do you REALLY trust your network? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092818105400> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Sun 28 Sep 86 19:16:39-PDT Received: by vax.darpa.mil (4.12/4.7) id AA17813; Sun, 28 Sep 86 22:11:01 edt Date: Sun 28 Sep 86 22:10:54-EDT From: Dennis G. Perry Subject: Re: Why is the ARPANet in such bad shape these days? To: SRA@XX.LCS.MIT.EDU Cc: BILLW@SU-SCORE.ARPA, tcp-ip@SRI-NIC.ARPA, perry@VAX.DARPA.MIL Message-Id: In-Reply-To: Message from "Rob Austein " of Sat, 27 Sep 1986 21:35 EDT I can shed a few ray of light (or is that tears) on the Arpanet congestion problem. I don't guarentee that I fully understand the issues, since I believe we have an onion problem. The E-W problem seems to be related to the fact that there are only two E-W lines, both running on average about 60% utilization. In fact, they occilate between 20 and 90% utilization. Instability occurs when lines become saturated and the network starts hunting. Another congestion problem in the PSNs is the multi-packet message. Apparently there is not enough buffer space to allocate all the buffers needed to support the current multi-packet message traffic. The net result is to paralyze the network, as each PSN quits accepting incomming multi-packet messages. There may be other problems as well. We are working on solutions, but as indicated, it may take a while. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609291646.AA08792%40ucbvax.Berkeley.EDU] <1986092819062400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PHIL@UIUCVMD.BITNET (Phil Howard) Newsgroups: mod.protocols.tcp-ip Subject: False mail Message-ID: <8609291646.AA08792@ucbvax.Berkeley.EDU> Date: Sun, 28-Sep-86 23:06:24 EDT Article-I.D.: ucbvax.8609291646.AA08792 Posted: Sun Sep 28 23:06:24 1986 Date-Received: Tue, 30-Sep-86 20:46:06 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa The security of the Post Office depends on its people, and the services they provide. The same is true of a network. The network can provide better services, such as tell you who REALLY sent the mail, but do you REALLY trust your network? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092819460000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 28 Sep 86 20:47:27-PDT Date: 28 Sep 1986 23:46-EDT Sender: CERF@A.ISI.EDU Subject: Re: Peace fullness. From: CERF@A.ISI.EDU To: BEAME%MCMASTER.BITNET@WISCVM.WISC.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]28-Sep-86 23:46:03.CERF> In-Reply-To: The message of Sat, 27 Sep 86 12:52 EDT from Carl, consider a licensing arrangement with other, larger vendors - can your product be used in an OEM setting, augmenting or forming the basis for new value-added products? Freeware is not all it's cracked up to be - I am not sure I would worry too much about university competition. A user who cares about quality won't have anywhere to turn when university-software breaks. I don't mean to suggest that software produced in a research environment is all bad, only that maintenance and documentation often suffer; serious clients are prepared to pay for this. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092819500000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 28 Sep 86 20:51:39-PDT Date: 28 Sep 1986 23:50-EDT Sender: CERF@A.ISI.EDU Subject: Re: Why is the ARPANet in such bad shape these days? From: CERF@A.ISI.EDU To: SRA@XX.LCS.MIT.EDU Cc: BILLW@SU-SCORE.ARPA, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]28-Sep-86 23:50:14.CERF> In-Reply-To: It's possible the congestion is a consequence not of file transfers but of short packet interactive traffic. In the past, the C30 limits were on the packet-per-second side and this should be more true now with the larger memory C30E installed. If the network is suffering from too many short packets, there is little one can do short of installing more IMPS or faster ones (such as C300's). I do NOT have access to any detailed NOC information so I am speculating dangerously. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092819520000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 28 Sep 86 20:52:58-PDT Date: 28 Sep 1986 23:52-EDT Sender: CERF@A.ISI.EDU Subject: Re: Do we need another protocol? From: CERF@A.ISI.EDU To: WANCHO@SIMTEL20.ARPA Cc: TCP-IP@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]28-Sep-86 23:52:17.CERF> In-Reply-To: Frank, what about the FTAM (ISO) idea that Marshall Rose suggested? He proposed putting several of the ISO higher layers above TCP, rather than inventing yet another set of protocols. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092821440300> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Thu 2 Oct 86 19:45:21-PDT Received: from gatech by csnet-relay.csnet id aq03991; 1 Oct 86 16:42 EDT Received: by gatech.EDU (5.51/7.0.GT) id AA26419; Sun, 28 Sep 86 17:44:05 EDT From: Unix to Unix Copy Date: 28 Sep 86 21:44:03 GMT To: mod-protocols-tcp-ip%gatech.csnet@CSNET-RELAY.ARPA Subject: Submission for mod-protocols-tcp-ip Responding-System: gatech.EDU Path: gatech!cbosgd!mark From: mark@cbosgd.ATT.COM (Mark Horton) Newsgroups: mod.protocols.tcp-ip Subject: Re: SMTP, 2600, and the security of mail Message-ID: <2629@cbosgd.ATT.COM> Date: 28 Sep 86 15:54:40 GMT References: <8609280151.AA12210@ucbvax.Berkeley.EDU> Organization: AT&T Bell Laboratories, Columbus, Oh Lines: 13 Summary: False SMTP mail is easy to generate, but so is false paper mail AUERBACH@CSL.SRI.COM (Karl Auerbach) writes: > A while back I saw a copy of a newsletter titled "2600" which included > source code demonstrating how one could pretend to be an SMTP engine and > inject false mail into a host. Although the code had a few flaws, its > general structure looked plausable (and short -- about 25 lines of C). Sure it is. But that's not surprising. I can easily generate false paper mail with a phony return address, and dump it into a paper mailbox, too. Nobody ever said EMail was hard to forge. Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12242742311.36.LIXIA%40XX.LCS.MIT.EDU] <1986092900320500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Lixia@XX.LCS.MIT.EDU (Lixia Zhang) Newsgroups: mod.protocols.tcp-ip Subject: Re: Why is the ARPANet in such bad shape these days? Message-ID: <12242742311.36.LIXIA@XX.LCS.MIT.EDU> Date: Mon, 29-Sep-86 04:32:05 EDT Article-I.D.: XX.12242742311.36.LIXIA Posted: Mon Sep 29 04:32:05 1986 Date-Received: Tue, 30-Sep-86 20:25:16 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 81 Approved: tcp-ip@sri-nic.arpa The following replies to two internet congestion related messages together. Date: Sat, 27 Sep 1986 21:35 EDT From: Rob Austein Subject: Why is the ARPANet in such bad shape these days? ...... The NOC is refering to this mess as a "congestion problem" at the IMP level. The current theory the last few times I talked to the NOC was that we have managed to reach the bandwidth limit of the existing hardware. A somewhat scary thought... Could someone from BBN provide measured network throughput numbers to convince us that we indeed have hit the HARDWARE bandwidth limit? ...If this is in fact the case (and there is circumstancial evidence that it is, such as the fact that the net becomes usable again during off hours), we are in for a long siege, since it is guarenteed to take the DCA and BBN a fair length of time to deploy any new hardware or bring up new trunks. Better performance during off hours surely indicates that the problem is network load-related, but does not necessarily mean that the DATA traffic has hit the hardware limit -- there is a large percentage of non-data traffic flowing in the net. According to the measurement on a number of gateways, in the week of 9/15-9/21, (as more or less the same for all time) 43% of all received packets are addressed to a gateway 48% of all sent packets originate at a gateway Presumbly these gateway-gateway packets are routing updates, ICMP redirects, etc. But why should they take such a high percentage of the total traffic? Can someone explain to us? Even for data packets, I wonder if anyone has an idea about how much extra traffic is generated by the known extra-hop routing problem. More on this later. ALSO, IF THERE IS ANYBODY FROM BBN WHO KNOWS MORE ABOUT THE PROBLEM AND IS WILLING TO SHARE IT, -PLEASE- DO. IT'S HARD TO MAKE ANY KIND OF CONTINGENCY PLANS IN A VACUUM. --Rob I capitalized the sentence, hoping no one would pretend not seeing it. Date: Sun, 28 Sep 86 04:48:39 edt From: hedrick@topaz.rutgers.edu (Charles Hedrick) Subject: odd routings I have been looking at our EGP routings. I checked a few sites that I know we talk to a lot. Our current EGP peers are yale-gw and css-ring-gw. (We keep a list of possible peers, and the gateway picks 2. It will change if one of them becomes inaccessible. This particular pair seems to be fairly stable.) Here I what I found: ...... MIT: They seem to have 4 different networks. The ones with direct Arpanet gateways are 18 (using 10.0.0.77) and 128.52 (using 10.3.0.6). EGP was telling us to use 10.3.0.27 (isi) and 10.2.0.37 (purdue) respectively... This is probably caused by the EGP extra-hop problem: if MIT gateways are EGP neighboring with isi and purdue gateways, all other core gateways will tell you to go through isi/purdue gateways to get to MIT, even though everyone is on ARPANET. This should be a contributor to the cognestion too. One question is: Can anyone tell us WHEN this extra-hop problem will be completely eliminated? Another question is how the stubs select core EGP neighbors; if they all concentrate on a small number of core gateways, bottlenecks will be created, because the extra-hop problem says that if a stub gw EGP-neighbors with a core gw, most traffic to the stub is likely to travel through that core gw as well. Hedrick listed their coded-in core EGP gateway candidates in his message. Is the same list used by all non-core gateways? Does someone know how many stub gateways EGP-neighbor with one core gateway? Will some stub-core rebinding help relieve the congestion? In short, reducing network overhead and fixing some long-standing protocol problems may be a way to relieve the current poor net performance. Lixia ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12242745855.7.MRC%40SIMTEL20.ARPA] <1986092900513300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC@SIMTEL20.ARPA (Mark Crispin) Newsgroups: mod.protocols.tcp-ip Subject: Re: SMTP, 2600, and the security of mail Message-ID: <12242745855.7.MRC@SIMTEL20.ARPA> Date: Mon, 29-Sep-86 04:51:33 EDT Article-I.D.: SIMTEL20.12242745855.7.MRC Posted: Mon Sep 29 04:51:33 1986 Date-Received: Tue, 30-Sep-86 20:25:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa Oh wow, big deal, so the little phone phreaks has discovered how to talk to SMTP servers? I mean, am I supposed to be impressed with how bright they are or something? The Internet protocols are insecure by nature. A reasonably suspicious host should always record the host name or IP address of the how which actually connected to the SMTP server (the real host, not what was claimed in a HELO). Some hosts prevent random user programs from making TCP connections to the SMTP port (I think Multics does), but basically beyond knowing what host composed the message the end user should be reasonably suspicious about any mail s/he receives. After all, even IP addresses can be faked, although I suspect inpersonating the IP address of MIT-MULTICS is beyond the technical expertise of your average phone phreak (it requires actually KNOWING something). ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12242747644.7.MRC%40SIMTEL20.ARPA] <1986092901012300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC@SIMTEL20.ARPA (Mark Crispin) Newsgroups: mod.protocols.tcp-ip Subject: Re: odd routings Message-ID: <12242747644.7.MRC@SIMTEL20.ARPA> Date: Mon, 29-Sep-86 05:01:23 EDT Article-I.D.: SIMTEL20.12242747644.7.MRC Posted: Mon Sep 29 05:01:23 1986 Date-Received: Tue, 30-Sep-86 20:25:52 EDT References: <8609280848.AA26039@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa The funny EGP stuff isn't in cisco's gateway; my TOPS-20 EGP gets the same sort of garbage. Fortunately, *most* of the gateways *will* redirect. I think the mailbridges are the principle culprit. Dave Mills can probably give you a complete description of what is wrong and why. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860929075908.8.MARGULIES%40REDWING.SCRC.Symbolics.COM] <1986092903590000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Margulies@SAPSUCKER.SCRC.SYMBOLICS.COM (Benson I. Margulies) Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <860929075908.8.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Mon, 29-Sep-86 07:59:00 EDT Article-I.D.: REDWING.860929075908.8.MARGULIES Posted: Mon Sep 29 07:59:00 1986 Date-Received: Tue, 30-Sep-86 20:29:18 EDT References: <8609261313.AA07678@mitre.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 35 Approved: tcp-ip@sri-nic.arpa Date: Fri, 26 Sep 86 09:13:04 -0500 From: mckee@mitre.ARPA Marshall Abrams, a Security guru here at MITRE, sent me a copy of the following note by Brian Reid. The note has little to do with TCP and IP, but it is instructive to learn how our networks are being used for nefarious purposes, and besides, there is a certain lascivious pleasure in reading about somebody elses troubles. H. C. McKee -------------------------- From: reid@decwrl.DEC.COM (Brian Reid) Date: 16 Sep 1986 1519-PDT (Tuesday) To: Peter G. Neumann [FOR RISKS] Subject: Massive UNIX breakins at Stanford Lessons learned from a recent rash of Unix computer breakins ... Brian Reid DEC Western Research and Stanford University As an Ex-B2 security hacker (guess where), I just wanted to point out that Brian's observations are basically right-on. There is a big tension between wanting to be able to run an application without having the user have to type passwords and having fail-safe network security. The bottom line is that if you treat an entire network of machines as one "System" in the orange book sense (no passwords used in between), then you had better be bloody sure that you have working software on all of them, and that you monitor activities closely. caveat manager ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609291603.AA12086%40im4u.UTEXAS.EDU] <1986092908033700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jsq@ZOTZ.CS.UTEXAS.EDU Newsgroups: mod.protocols.tcp-ip Subject: passwords and protection files Message-ID: <8609291603.AA12086@im4u.UTEXAS.EDU> Date: Mon, 29-Sep-86 12:03:37 EDT Article-I.D.: im4u.8609291603.AA12086 Posted: Mon Sep 29 12:03:37 1986 Date-Received: Tue, 30-Sep-86 15:04:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa Let's remember that if system people are forced to type super-user passwords across a network in clear text that that's just as bad a security problem as the permission file setup being complained about. (Though I suppose the cracker is more likely to need physical access to the local network.) Also, the way the crackers got into system people's accounts in this instance was through tricking badly written privileged programs to execute out of directories with *public* write permission, without which the question of whether system people should be able to write into program directories without typing passwords would have been moot. I.e., the really bad security problem in a network of 4BSD machines is privileged programs that don't constrain their search paths and arguments. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860929091101.00f%40Jpl-VLSI.ARPA] <1986092908110100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tencati@JPL-VLSI.ARPA Newsgroups: mod.protocols.tcp-ip Subject: re: ARPAnet "Congestion" Message-ID: <860929091101.00f@Jpl-VLSI.ARPA> Date: Mon, 29-Sep-86 12:11:01 EDT Article-I.D.: Jpl-VLSI.860929091101.00f Posted: Mon Sep 29 12:11:01 1986 Date-Received: Tue, 30-Sep-86 21:01:26 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa I have a purely academic question. Is anyone considering the fact that there are many users on the ARPAnet that are not "official" users? When I was in college a few years ago, an arpanet account was very hard to get. Unless you were faculty, forget it (this was at USC). It seems that now there are many more students and people who are not really using the net for work, as much as an electronic post office. My host spends 90% of it's time on the ARPAnet sending and receiving INFO-THIS, and INFO-THAT. Also, I have multiple users receiving the same message from INFO-WHATEVER as separate TCP connections to my host. I think part of the congestion mess is that hosts (like mine) do not utilize "central mailboxes" and do the redistribution locally. I do feel that the subscribership of the net, and the "official DARPA business" rules that applied a few years ago have been very lax lately. Now, most universities let their students onto the net, and most hosts with network access do the same. I'm not saying that this should be restricted because the ARPAnet is a useful tool. Especially to system managers like myself. I just think that with the increased volume of users and the proliferation of INFO lists, the mail traffic has increased drastically over the past few years, and with the advent of these new protocols (PC/IP for example), it is becoming easier and easier for *anyone* to get connected up to the ARPAnet... I'm not flaming, I just had an extra 2 cents in my pocket... Ron Tencati JPL-VLSI.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609291632.AA00161%40braden.isi.edu] <1986092908325100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@VENERA.ISI.EDU (Bob Braden) Newsgroups: mod.protocols.tcp-ip Subject: Re: Do we need another protocol? Message-ID: <8609291632.AA00161@braden.isi.edu> Date: Mon, 29-Sep-86 12:32:51 EDT Article-I.D.: braden.8609291632.AA00161 Posted: Mon Sep 29 12:32:51 1986 Date-Received: Wed, 1-Oct-86 02:47:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 60 Approved: tcp-ip@sri-nic.arpa There is a growing trend in the Army to network Intel 310s running Xenix on a fat Ethernet under OpenNet. When asked why OpenNet instead of TCP/IP, the answer most often heard is because OpenNet provides inter-machine file and record-level access at the application level. I never understood military politics, but I am curious how the army can do this in the face of the DoD directive to use TCP/IP. If they are in fact justifying it by the requirement for file access, it amazes me that someone in DCA has not gotten excited about this. At one time, there was a brief discussion of the possibility of extending the FTP definition to allow for record-level access. It seemed to me then that FTP was the wrong place and that an entirely new protcol should be defined. Was this ever done and formally recognized as part of the TCP protocol suite? If not, why not? The "why not" is easy to answer. No one eager to fund it. Protocol development requires a number of experienced people to devote quite a lot of time and attention. In our community, it also requires a cycle of experiment and experience with test implementations. The existing DoD protocol suite -- IP, TCP, Telnet, FTP, and SMTP -- was developed as part of a coherent R&D effort programmed and largely funded by DARPA. The importance of DARPA's leadership cannot be too strongly emphasized. Since DARPA's mission is generally long-range research, it is no longer interested in funding Internet R&D as an end in itself, and little interest in "small" protocol improvements. So, a lot of good ideas for protocols (file access is only one example) have lain in the dust for 10 years. Every 11.3 months someone brings up the need for file access on this mailing list, for example. Another fact has delayed work on the file access problem. There has been general agreement for a long time that, as you say, "FTP was the wrong place and that an entirely new protcol should be defined", but no coherent concept of what a new protocol should look like. With no terrific ideas, and no funding interest, it is no wonder that file access has languished for 10 years (actually 13 -- file access extensions to FTP were first proposed by John Day in RFC520, dated June 25, 1973!) Recently there has been a growing interest in the network file system model, exemplified by Sun's NFS, as the right way to go for file access. There is also an attempt, organized by DARPA and the IAB, to revitalize Internet protocol research with a variety of funding sources. The effective agency for this is supposed to be the IAB task forces. So maybe the time has come to actually slay the file access dragon. Suppose there were to be some meeting of interested persons to come up with a draft specification of an Internet standard network file system (note: NO capital letters!!) protocol. Would you have time and travel funds to attend and contribute? Bob Braden chairperson, End-to-End Protocols task force. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609291805.AA09813%40devvax.tn.cornell.edu] <1986092910051200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: swb@DEVVAX.TN.CORNELL.EDU (Scott Brim) Newsgroups: mod.protocols.tcp-ip Subject: Why is the ARPANet in such bad shape these days? Message-ID: <8609291805.AA09813@devvax.tn.cornell.edu> Date: Mon, 29-Sep-86 14:05:12 EDT Article-I.D.: devvax.8609291805.AA09813 Posted: Mon Sep 29 14:05:12 1986 Date-Received: Wed, 1-Oct-86 02:49:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Lixia: I've always wondered about figures like that. Aren't the overwhelming majority of the gateways on Arpanet also decent-sized hosts in their own right -- so that much of the traffic in your figures might be legitimate user traffic? Scott p.s. talk about degenerative congestion -- when the network gets slow we all start sending gobs of mail back and forth in order to improve it! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12242851943.62.LIXIA%40XX.LCS.MIT.EDU] <1986092910341900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Lixia@XX.LCS.MIT.EDU (Lixia Zhang) Newsgroups: mod.protocols.tcp-ip Subject: Re: Why is the ARPANet in such bad shape these days? Message-ID: <12242851943.62.LIXIA@XX.LCS.MIT.EDU> Date: Mon, 29-Sep-86 14:34:19 EDT Article-I.D.: XX.12242851943.62.LIXIA Posted: Mon Sep 29 14:34:19 1986 Date-Received: Wed, 1-Oct-86 05:02:11 EDT References: <8609291805.AA09813@devvax.tn.cornell.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Scott, As far as I know, the numbers in my message were from measurements (by BBN) on the pure forwarding gateways, NOT including hosts. Lixia P.S. Also talking about degenerative congestion -- if no one uses the net, surely no congestion would exist, probably nor would the net itself. With no congestion, people still send mail daily, though probably on different subjects. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609301759.AA15034%40ucbvax.Berkeley.EDU] <1986092911320300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: steve@BRL.ARPA (Stephen Wolff) Newsgroups: mod.protocols.tcp-ip Subject: ISO Development Environment Message-ID: <8609301759.AA15034@ucbvax.Berkeley.EDU> Date: Mon, 29-Sep-86 15:32:03 EDT Article-I.D.: ucbvax.8609301759.AA15034 Posted: Mon Sep 29 15:32:03 1986 Date-Received: Wed, 1-Oct-86 05:27:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 30 Approved: tcp-ip@sri-nic.arpa The NSF is committed to international networking standards and to the timely migration of NSFNET to the full ISO protocol suite. In support of this commitment, the NSF will make available at each supercomputer center on the NSFNET backbone, software which presents an ISO TP4 environment to higher-level networking code, yet which uses the services of TCP and is transportable over IP networks such as NSFNET and the ARPANET. This ISO Development Environment (ISODE) software will a) allow early deployment and use of existing high-level ISO networking software that requires a TP4 transport interface, and b) permit the development and testing of new ISO-style software with the assurance that the development effort will not have been wasted when the actual underlying transport and network layers switch from TCP and IP to their ISO counterparts. Thus with the ISODE at each NSF supercomputer center, NSFNET can serve as an early testbed for ISO-style high-level networking. The ISODE package was developed by Marshall T. Rose and Dwight E.Cass of the Northrop Research and Technology Center and, while not in the public domain, is made available to the networking community without charge and without support. Comments on the package, including bug reports, will be gratefully received. Stephen Wolff Program Director for Networking National Science Foundation ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986092911320301> Received: from BRL-SMOKE.ARPA by SRI-NIC.ARPA with TCP; Mon 29 Sep 86 12:39:17-PDT Date: Mon, 29 Sep 86 15:32:03 EDT From: Stephen Wolff To: tcp-ip@sri-nic.arpa Subject: ISO Development Environment The NSF is committed to international networking standards and to the timely migration of NSFNET to the full ISO protocol suite. In support of this commitment, the NSF will make available at each supercomputer center on the NSFNET backbone, software which presents an ISO TP4 environment to higher-level networking code, yet which uses the services of TCP and is transportable over IP networks such as NSFNET and the ARPANET. This ISO Development Environment (ISODE) software will a) allow early deployment and use of existing high-level ISO networking software that requires a TP4 transport interface, and b) permit the development and testing of new ISO-style software with the assurance that the development effort will not have been wasted when the actual underlying transport and network layers switch from TCP and IP to their ISO counterparts. Thus with the ISODE at each NSF supercomputer center, NSFNET can serve as an early testbed for ISO-style high-level networking. The ISODE package was developed by Marshall T. Rose and Dwight E.Cass of the Northrop Research and Technology Center and, while not in the public domain, is made available to the networking community without charge and without support. Comments on the package, including bug reports, will be gratefully received. Stephen Wolff Program Director for Networking National Science Foundation ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609292004.AA01618%40rose.sun.com] <1986092912041100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: nowicki@SUN.COM (Bill Nowicki) Newsgroups: mod.protocols.tcp-ip Subject: Re: Do we need another protocol? Message-ID: <8609292004.AA01618@rose.sun.com> Date: Mon, 29-Sep-86 16:04:11 EDT Article-I.D.: rose.8609292004.AA01618 Posted: Mon Sep 29 16:04:11 1986 Date-Received: Wed, 1-Oct-86 05:28:51 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa There is a growing trend in the Army to network Intel 310s running Xenix on a fat Ethernet under OpenNet. When asked why OpenNet instead of TCP/IP, the answer most often heard is because OpenNet provides inter-machine file and record-level access at the application level. Of course I am biased, but you might want to consider the Sun Network File System (NFS) protocol. NFS has the advantage of being available on many different machines and operating systems: MS-DOS, many Unix versions, VMS etc. It is licensed by more than 60 vendors, and based on the IP protocol. Specifications are public domain, with fully-supported implementations avilable from several sources. "Open" Net is quite a misnomer if it is only available from one vendor. I know, we should circulate an RFC form of the NFS spec; we are working on it. Bill Nowicki Sun Microsystems ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860929175502.007%40sitvxb] <1986092913550300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: heilner_k@sitvxb.BITNET (Keith J. Heilner) Newsgroups: mod.protocols.tcp-ip Subject: ThinWire Repeaters Message-ID: <860929175502.007@sitvxb> Date: Mon, 29-Sep-86 17:55:03 EDT Article-I.D.: sitvxb.860929175502.007 Posted: Mon Sep 29 17:55:03 1986 Date-Received: Fri, 3-Oct-86 00:32:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Greetings. Im looking for vendors who manufacture the ThinWire (RG58) multiport repeater. I have been able to identify two vendors, DEC and HP. Digital manufactures a device called a DEMPR and HP has a four port device. If you know of any other vendors manufacturing these devices please let me know. Thanks for your time and help. Heilner_K@sitvxb.bitnet or Heilner_K@sitvxb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12242892621.30.GROSSMAN%40Sierra.Stanford.EDU] <1986092914174600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GROSSMAN@SIERRA.STANFORD.EDU (Stu Grossman) Newsgroups: mod.protocols.tcp-ip Subject: Re: SMTP, 2600, and the security of mail Message-ID: <12242892621.30.GROSSMAN@Sierra.Stanford.EDU> Date: Mon, 29-Sep-86 18:17:46 EDT Article-I.D.: Sierra.12242892621.30.GROSSMAN Posted: Mon Sep 29 18:17:46 1986 Date-Received: Thu, 2-Oct-86 20:33:29 EDT References: <12242745855.7.MRC@SIMTEL20.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa You could (marginally) increase the security of SMTP traffic by having SMTP servers only accept connections from a 'privileged' remote socket. Of course, you now would be required to run yet another privileged daemon just to ship mail out of your host. Stu Grossman ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609292347.AA07433%40amdcad.UUCP] <1986092915474000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: phil@amdcad.UUCP (Phil Ngai) Newsgroups: mod.protocols.tcp-ip Subject: testing Message-ID: <8609292347.AA07433@amdcad.UUCP> Date: Mon, 29-Sep-86 19:47:40 EDT Article-I.D.: amdcad.8609292347.AA07433 Posted: Mon Sep 29 19:47:40 1986 Date-Received: Thu, 2-Oct-86 20:37:32 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 1 Approved: tcp-ip@sri-nic.arpa Sorry about this. Gotta try it. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609300147.AA08651%40amdcad.UUCP] <1986092917472500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: phil@amdcad.UUCP (Phil Ngai) Newsgroups: mod.protocols.tcp-ip Subject: Ethernet carrier sense during transmit Message-ID: <8609300147.AA08651@amdcad.UUCP> Date: Mon, 29-Sep-86 21:47:25 EDT Article-I.D.: amdcad.8609300147.AA08651 Posted: Mon Sep 29 21:47:25 1986 Date-Received: Thu, 2-Oct-86 19:53:31 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa Terry Slattery asks " the interface monitor carrier during transmit?" I have reviewed the 802.3 spec and see no requirement to do so. (But I still find the language of the spec a bit confusing so I may have overlooked it.) The Ethernet 2 spec calls for a CarrierSenseTest process on page 53 which reports if carrier disappears while transmitting or if it never appears during an entire transmission. It does not seem to be used. Is Codenoll without fault? Ethernet assumes a certain maximum transceiver cable length and a certain minimum signal propagation velocity. The transceiver is supposed to send to the controller everything which appears on the cable. One may conclude that carrier should be present during transmission. The advantage of monitoring the presence of carrier is that you have more information with which to perform problem isolation. The Codenoll system alters the parameters which permit the monitoring of carrier. As such, calling it "Ethernet" or "Ethernet compatible" could be misleading and could cause network failures which are hard to diagnose such as your case. This is not to say the Codenoll product is bad or that you shouldn't use it. However, I will be cautious whenever someone proposes breaking one of the Ethernet configuration rules. If someone does break the rules and has a failure, then that would be one of the first places to look at. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609300046.aa26023%40SEM.BRL.ARPA] <1986092920460800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mike@BRL.ARPA (Mike Muuss) Newsgroups: mod.protocols.tcp-ip Subject: Re: ARPAnet "Congestion" Message-ID: <8609300046.aa26023@SEM.BRL.ARPA> Date: Tue, 30-Sep-86 00:46:08 EDT Article-I.D.: SEM.8609300046.aa26023 Posted: Tue Sep 30 00:46:08 1986 Date-Received: Thu, 2-Oct-86 20:00:45 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa The multiple recipients of mail argument is a bit hard to support, considering that SMTP allows (and most implementations implement) all recipient addresses to be presented first, followed by one copy of the body of the message. At most 4 IP datagrams are needed for each additional address (assuming no packet loss). -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609291748.AA13652%40hydra.riacs.edu] <1986093005054400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leiner@ICARUS.RIACS.EDU Newsgroups: mod.protocols.tcp-ip Subject: Re: Peace fullness. Message-ID: <8609291748.AA13652@hydra.riacs.edu> Date: Tue, 30-Sep-86 09:05:44 EDT Article-I.D.: hydra.8609291748.AA13652 Posted: Tue Sep 30 09:05:44 1986 Date-Received: Wed, 1-Oct-86 02:56:54 EDT References: <8609280022.AA07389@riacs.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Carl, The theory is that products developed in the R&D community (read universities) are not supported adequately for industry to rely on. Hence the commercial market is for an equally functional product that is maintained, evolved, supported, etc. It appears from your note that you don't buy that argument. I would be interested in your reaction. ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610011103.AA10746%40ucbvax.Berkeley.EDU] <1986093005551400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gross@EDN-VAX.ARPA (Martin Gross) Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8610011103.AA10746@ucbvax.Berkeley.EDU> Date: Tue, 30-Sep-86 09:55:14 EDT Article-I.D.: ucbvax.8610011103.AA10746 Posted: Tue Sep 30 09:55:14 1986 Date-Received: Fri, 3-Oct-86 00:45:23 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Does anyone have any specific information on y[D[[Dthe problems associated with Wollongong's implementation of TCP/IP. I've heard it's not user friendly and has mail and support problems. Any more specific information would be greatly apprecited[D[D[Dated. thanks Martin ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986093005551401> Received: from EDN-VAX.ARPA by SRI-NIC.ARPA with TCP; Tue 30 Sep 86 06:56:05-PDT Received: by EDN-VAX.ARPA (4.12/4.7) Date: Tue, 30 Sep 86 09:55:14 edt From: gross@EDN-VAX.ARPA (Martin Gross) To: tcp-ip@sri-nic.ARPA Does anyone have any specific information on y[the problems associated with Wollongong's implementation of TCP/IP. I've heard it's not user friendly and has mail and support problems. Any more specific information would be greatly apprecitedated. thanks Martin ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610010647.AA04073%40seismo.CSS.GOV] <1986093007160200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: john@moncskermit.OZ.AU (John Carey) Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP for Burroughs Message-ID: <8610010647.AA04073@seismo.CSS.GOV> Date: Tue, 30-Sep-86 11:16:02 EDT Article-I.D.: seismo.8610010647.AA04073 Posted: Tue Sep 30 11:16:02 1986 Date-Received: Sat, 4-Oct-86 06:28:14 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Does anyone know of a TCP/IP implementation for the B7800 ? Or have some semi-transportable code written in pascal or algol John Carey john@monu1.oz@seismo.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986093007520900> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Wed 1 Oct 86 15:53:13-PDT Received: from (GLM)IPGUNIV.BITNET by WISCVM.WISC.EDU on 09/30/86 at 01:24:42 CDT Date: Tue, 30 Sep 86 06:52:09 cet To: TCP-IP@SRI-NIC.ARPA From: GLM%IPGUNIV.BITNET@WISCVM.WISC.EDU Subject: booking TCP-IP mailing list I wuould like to be registered in the TCP-IP mailing list. Sincerely Gianfranco Galmacci ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860930120647.4.DCP%40KOYAANISQATSI.S4CC.Symbolics.COM] <1986093008060000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer) Newsgroups: mod.protocols.tcp-ip Subject: re: ARPAnet "Congestion" Message-ID: <860930120647.4.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Tue, 30-Sep-86 12:06:00 EDT Article-I.D.: KOYAANIS.860930120647.4.DCP Posted: Tue Sep 30 12:06:00 1986 Date-Received: Fri, 3-Oct-86 00:47:04 EDT References: <860929091101.00f@Jpl-VLSI.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 42 Approved: tcp-ip@sri-nic.arpa Date: Mon, 29 Sep 86 09:11:01 PDT From: tencati@Jpl-VLSI.ARPA I have a purely academic question. Is anyone considering the fact that there are many users on the ARPAnet that are not "official" users? My opinions: The INFO-THIS, INFO-THAT problem is a site administration problem. Your site allows your users to receive those lists. I'm not sure there are programs to prevent people from getting added, but if somebody were willing to watch the mail logs and "catch" the people, they could be told to conform to site policy and get themselves removed from the lists. One possible solution is to ask all maintainers of major mailing lists to completely disallow individuals on the lists and require that all "recipients" be local redistribution lists at the target sites. This would allow site managers to restrict incoming mail volume by disallowing their users to receive lists contrary to site policy. (Sounds facsist, and it probably is. I don't know if I believe this, but it is a possibility.) The "multiple users receiving the same message on separate connections" problem has two causes. The major cause is that the sending site refuses to send the same message to multiple recipients. I believe this was the case with previous Unix software; I don't know if it has ever been fixed. A second possible cause is lack of local redistribution. "Official DARPA business" made a lot more sense back in the NCP days. With the advent of IP, it can be claimed that you aren't connected to the ARPAnet, you are connected to the Internet. The ARPAnet is logically and physically just a very small part of the entire Internet. The real problem we are seeing is that it is the backbone of the Internet. The solution is obvious (I'm assuming the proliferation of machines will continually increase traffic): put more bandwidth into the >>Internet<<. This could be by adding more ARPAnet capability, or providing other (redundant) paths. Who pays for it isn't clear, nor is the choice of technology. I'm not flaming, I just had an extra 2 cents in my pocket... The 2 cent token is moving around the net... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609301713.AA15763%40amdcad.UUCP] <1986093009132000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: phil@amdcad.UUCP (Phil Ngai) Newsgroups: mod.protocols.tcp-ip Subject: MIT pcip and 3com board Message-ID: <8609301713.AA15763@amdcad.UUCP> Date: Tue, 30-Sep-86 13:13:20 EDT Article-I.D.: amdcad.8609301713.AA15763 Posted: Tue Sep 30 13:13:20 1986 Date-Received: Fri, 3-Oct-86 07:16:05 EDT Sender: serge@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa I am trying to use MIT's pcip package with a Compaq Portable Model 2 (286, smaller box) with a 3com etherlink card (3c501? the new short dumb card). It won't talk to a VAX780 running vanilla 4.2 with an Interlan NI1010A. It will talk to any Valid workstation (they have 3com interfaces) or a couple of microvax IIs with DEQNAs or a 730/BSD4.2 with an NI1010A. Network Research's telnet does work, but I was interested in the mon program that MIT has. My theories are: 1) It's not a design problem with the NI1010A since the 730 works 2) It's not vanilla 4.2 since the 730 works. 3) It's not the Compaq or the 3c501 since NRC works. 4) It's not pcip since it talks to the 730. 5) It's not the 780 or its particular NI1010A since NRC works to it. One or more of my theories must be wrong since it does not work. Any suggestions? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609301729.AA22542%40spam.istc.sri.com] <1986093009290000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gds@SPAM.ISTC.SRI.COM (The lost Bostonian) Newsgroups: mod.protocols.tcp-ip Subject: Re: SMTP, 2600, and the security of mail Message-ID: <8609301729.AA22542@spam.istc.sri.com> Date: Tue, 30-Sep-86 13:29:00 EDT Article-I.D.: spam.8609301729.AA22542 Posted: Tue Sep 30 13:29:00 1986 Date-Received: Fri, 3-Oct-86 05:32:27 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa > From: Mark Crispin > The Internet protocols are insecure by nature. A reasonably suspicious > host should always record the host name or IP address of the how which > actually connected to the SMTP server (the real host, not what was > claimed in a HELO). If it is true that all IP implementations enable a server program to determine the IP address of its peer, then the HELO command, and its response could be eliminated, which would save us a few bytes. Certainly the response to the HELO is not necessary, since the server has already identified itself in the opening greeting. However, I quote from RFC 821, the explanation for HELO: This command and an OK reply to it confirm that both the sender-SMTP and receiver-SMTP are in the initial state, that is, there is no transaction in progress and all state tables and buffes are cleared. I do not see that there would be a big problem of detecting the initial state without a HELO. Other protocols (FTP, NNTP) don't use it. --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [860930145053.3.JAMES%40GREEN-GRASS.LCS.MIT.EDU] <1986093010500000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: james@ZERMATT.LCS.MIT.EDU ("James William O'Toole, Jr.") Newsgroups: mod.protocols.tcp-ip Subject: Re: Peace fullness. Message-ID: <860930145053.3.JAMES@GREEN-GRASS.LCS.MIT.EDU> Date: Tue, 30-Sep-86 14:50:00 EDT Article-I.D.: GREEN-GR.860930145053.3.JAMES Posted: Tue Sep 30 14:50:00 1986 Date-Received: Fri, 3-Oct-86 05:33:50 EDT References: <8609291748.AA13652@hydra.riacs.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa From: leiner@riacs.edu Date: Mon, 29 Sep 86 10:48:13 -0700 To: Cc: tcp-ip@sri-nic.ARPA Subject: Re: Peace fullness. Carl, The theory is that products developed in the R&D community (read universities) are not supported adequately for industry to rely on. Hence the commercial market is for an equally functional product that is maintained, evolved, supported, etc. It appears from your note that you don't buy that argument. I would be interested in your reaction. --------- Would anyone mind moving the discussions of commercial vs. university product requirements to a more appropriate list, and off of tcp-ip? Thanks. --Jim ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609302056.AA03119%40nestor.UUCP] <1986093012565800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: smb@ulysses.UUCP (Steven Bellovin) Newsgroups: mod.protocols.tcp-ip Subject: Re: SMTP, 2600, and the security of mail Message-ID: <8609302056.AA03119@nestor.UUCP> Date: Tue, 30-Sep-86 16:56:58 EDT Article-I.D.: nestor.8609302056.AA03119 Posted: Tue Sep 30 16:56:58 1986 Date-Received: Fri, 3-Oct-86 06:52:20 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa It's important to remember that SMTP is used on non-TCP virtual circuits. For example, some hosts within Bell Labs use it over Datakit(r) VCS connections. You can't do this nearly as easily with FTP because the semantics of some of the commands (i.e., PORT and PASSIVE) are intimately tied to TCP and IP. In general, though, I regard SMTP as a newer and better protocol than FTP, and as a better model for other protocols. The concept of looking for the initial state is a good one; I've often seen half-open circuits get spliced to due to software bugs (though not on TCP, of course). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8609302105.AA05950%40cbosgd.ATT.COM] <1986093013054100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: mark@cbosgd.att.com (Mark Horton) Newsgroups: mod.protocols.tcp-ip Subject: Re: ARPAnet "Congestion" Message-ID: <8609302105.AA05950@cbosgd.ATT.COM> Date: Tue, 30-Sep-86 17:05:41 EDT Article-I.D.: cbosgd.8609302105.AA05950 Posted: Tue Sep 30 17:05:41 1986 Date-Received: Sat, 4-Oct-86 06:32:24 EDT References: <860929091101.00f@Jpl-VLSI.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 93 Approved: tcp-ip@sri-nic.arpa >My host spends >90% of it's time on the ARPAnet sending and receiving INFO-THIS, and INFO-THAT. >Also, I have multiple users receiving the same message from INFO-WHATEVER >as separate TCP connections to my host. If the ARPANET mailing lists do turn out to be the cause of the problem, I'd like to suggest a possible solution: Netnews. Netnews was invented on the UUCP network, where we didn't have the seemingly "unlimited" bandwidth of the ARPANET. It had to survive on 1200 baud dialup lines with UUCP. Nonetheless, we still manage to push around about a megabyte/day of traffic over dialups. (This figure 1MB/day counts each message only once, not once per recipient.) It's been possible for UNIX sites on the ARPANET to exchange netnews via UUCP or SMTP Mail for years now. Even these primitive methods have many benefits (in our perception) over mailing lists: (1) Only one copy of each message is sent to each system (although we do sometimes have redundant links, sending redundant copies, for extra reliability, duplicates are weeded out using Message-ID so the users rarely see a duplicate.) (2) Error messages don't go to the sender, they automatically go to the person responsible for the link in question. (3) Users see their "news" separately from their "mail" (unless they want their news mailed to them, which is also possible but inefficient) which means that mail will have higher priority than news for most users. (By "news" I mean what's considered "mass mailing" on the ARPANET.) (4) Users get other benefits, such as grouping of subjects and discussions, and never have to go through a moderator or list maintainer to start reading or posting to a newsgroup. (5) Only one copy is kept on each machine's disk, rather than one copy in each user's mailbox. (6) News is automatically expired after two weeks (or whatever it's locally configured to) so the disk usage is fairly constant; still, users can join into the middle of a discussion and immediately have two weeks worth of "back issues". (7) Cross-posting allows a discussion to go on in multiple forums (e.g. header-people and namedroppers) while sending only one copy of each message around, and each user sees each message only once. (8) By batching news, there is less transport overhead. Each hour, a host may accumulate all new news and send it to its neighbors. (9) All news goes through the same pipe, so it's easy to gather statistics about traffic volume, both total and per-group. We have also recently found a way to measure readership. Even better methods are evolving. NNTP allows transfer of netnews efficiently over TCP, and allows one machine to serve as a remote disk so you don't need a copy of netnews on every machine. Stargate will allow you to get moderated news from any cable TV service that carries WTBS, or any satellite dish that can get WTBS. The major problems with using netnews on the ARPA Internet have historically been (1) The implementations run under UNIX, and nobody has written one for TOPS 20. (But I've heard rumors of an NNTP compatible TOPS 20 implementation under development.) (2) Many users prefer to keep their mail and news lumped together in their mailbox. (I can't understand this, but I guess it's a religious issue, like which editor you use.) We have several user interfaces for netnews, optimized to reading large volumes of traffic, and encouraging good manners among the posters. Usenet is the network currently carrying netnews, and includes large chunks of UUCP as well as many ARPA Internet Usenet hosts. (If the host runs UNIX and is a major Internet host, chances are good it's on Usenet, although representation is light at some of the senior ARPANET universities like MIT, CMU, and Stanford.) Some fraction of the ARPA mailing lists are gatewayed into Usenet newsgroups, including the TCP-IP list (I'm posting this as a Usenet message, and it will be transparently be sent to the moderator.) Usenet is a network, netnews is a technology. If mailing lists are congesting the ARPANET, it may be possible to use the netnews technology to carry the same amount of traffic at far less cost to the network, simultaneously making the mailing lists more widely available and cutting down on the workload of mailing list maintainers. (Most unmoderated Usenet newsgroups don't have anyone "in charge" of them, they run themselves.) Let's see where the load is really coming from; if mailing lists turn out to be the culprit, I offer netnews as an alternative to cutting back. Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610041553.AA24036%40sdcsvax.UCSD.EDU] <1986093013552600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: ron@celerity.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Peace fullness. Message-ID: <8610041553.AA24036@sdcsvax.UCSD.EDU> Date: Tue, 30-Sep-86 17:55:26 EDT Article-I.D.: sdcsvax.8610041553.AA24036 Posted: Tue Sep 30 17:55:26 1986 Date-Received: Wed, 8-Oct-86 03:42:51 EDT References: <8609280050.AA11782@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: celerity!ron@sdcsvax.ucsd.edu (Ron McDaniels) Organization: Celerity Computing, San Diego Ca Lines: 50 Approved: tcp-ip@sri-nic.arpa In article <8609280050.AA11782@ucbvax.Berkeley.EDU> BEAME@MCMASTER.BITNET writes: > > > Speeking as the president of one of those companies out there trying >to make a living by selling TCP/IP code for PC's ... > > As a developer it IS my responcibility to produce a product that my >clients desire and to develop new features and approches. > > I have done just that, but I am afraid to market it. Why ? Because the >Universities will produce a public (or very cheap) version and have their >name behind it! All my time, effort and MONEY will be wasted. > > What can I do ? Get a Patent ? That takes years, and the protocols might >have changed by than. > > I ask you, what would you do if you wanted to sell such a product. >(Remember were a very small company) > > - Carl Beame, > President > Beame & Whiteside Software Ltd. > 259 Fiddler's Green Rd. > Ancaster, Ontario, Canada. There seems to be no way to avoid (for large or small companys) doing market research before doing a product development. I don't even think that patents would solve your problem. They certainly would work if you were trying to protect an original invention, but anything that is in the public domain as much as TCP/IP is, well, forget it. A possible device you could use to market a product for which there is competition in the public sector, is to do the job better than the public version. Presumably, you are using designers and programmers that are professional (not a wild-eyed bunch of unmanagable undergrads ;-) and you will provide support and subsequent product updates and DOCUMENTATION that are frequently not available for public domain software. An example of this strategy being sucessfully employed is the Ingress DBMS. I guess I do feel a little sorry for you, your tax dollars being used to subsidize your competition and all. Kind of makes you want to go sell real estate or something. R. L. (Ron) McDaniels CELERITY COMPUTING . 9692 Via Excelencia Way . San Diego, California . 92126 (619) 271-9940 . {decvax || ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ron "Yes, my Precious. . . we hates them socket(2)eses!" ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8610021049.AA28865%40ucbvax.Berkeley.EDU] <1986093013561500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: ehrlich@psuvax1.BITNET Newsgroups: mod.protocols.tcp-ip Subject: BOOTP daemon for BSD 4.x Message-ID: <8610021049.AA28865@ucbvax.Berkeley.EDU> Date: Tue, 30-Sep-86 17:56:15 EDT Article-I.D.: ucbvax.8610021049.AA28865 Posted: Tue Sep 30 17:56:15 1986 Date-Received: Fri, 3-Oct-86 07:19:15 EDT Sender: serge@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa I would appreciate hearing from any who has or knows of a daemon for BSD 4.x that implements the BOOTP protocol. Thanks in advance. --Daniel Ehrlich =============================================================================== CSNET: ehrlich@penn-state.csnet USPS: The Pennsylvania State University INTERNET: ehrlich@psuvax1.psu.edu Department of Computer Science UUCP: ...!ihnp4!psuvax1!ehrlich 334B Whitmore Laboratory BITNET: ehrlich@psuvax1.bitnet University Park, PA 16802 BELL: (814) 863-1142 "The sky is blue so we know were to stop mowing." Judge Harry Stone =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986093013561501> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Wed 1 Oct 86 02:49:11-PDT Received: from (MAILER)PSUVAX1.BITNET by WISCVM.WISC.EDU on 09/30/86 at 16:56:01 CDT From: ehrlich%psuvax1.bitnet@WISCVM.WISC.EDU Received: by psuvax1.UUCP (4.12/4.7) id AA29047; Tue, 30 Sep 86 17:56:15 edt Date: Tue, 30 Sep 86 17:56:15 edt To: info-vax@brl.arpa Subject: BOOTP daemon for BSD 4.x Cc: tcp-ip@sri-nic.arpa I would appreciate hearing from any who has or knows of a daemon for BSD 4.x that implements the BOOTP protocol. Thanks in advance. --Daniel Ehrlich =============================================================================== CSNET: ehrlich@penn-state.csnet USPS: The Pennsylvania State University INTERNET: ehrlich@psuvax1.psu.edu Department of Computer Science UUCP: ...!ihnp4!psuvax1!ehrlich 334B Whitmore Laboratory BITNET: ehrlich@psuvax1.bitnet University Park, PA 16802 BELL: (814) 863-1142 "The sky is blue so we know were to stop mowing." Judge Harry Stone =============================================================================== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12243230777.46.ROMKEY%40XX.LCS.MIT.EDU] <1986093021151900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU From: ROMKEY@XX.LCS.MIT.EDU (John Romkey) Newsgroups: mod.protocols.tcp-ip Subject: Re: SMTP, 2600, and the security of mail Message-ID: <12243230777.46.ROMKEY@XX.LCS.MIT.EDU> Date: Wed, 1-Oct-86 01:15:19 EDT Article-I.D.: XX.12243230777.46.ROMKEY Posted: Wed Oct 1 01:15:19 1986 Date-Received: Fri, 3-Oct-86 06:58:08 EDT References: <12242892621.30.GROSSMAN@Sierra.Stanford.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa The whole idea of "privileged" sockets loses. There are lots of machines out there on the network right now which don't even have the concept of privileges in their operating system: IBM PC's. There's really very little you can do to stop someone with network code on an IBM PC from sending whatever they want, from whatever socket they choose, even whatever IP ADDRESS they wish to appear as, to the net. (of course, if they choose a sufficiently off-the-wall IP address then no packets will ever make it back to them) If you object to the idea of IBM PC's, then just think about all those single user Unix work stations that are appearing nowadays around the Internet. You can't really depend on their "owners" (most of whom probably know the root passwords) being trustworthy. I think we might be better off if no one would even suggest that privileged sockets have any role to play in the security of today's Internet. They only really provide a very thin illusion of security. - john romkey ------- ----MESSAGE-END----