----MESSAGE-BEGIN---- <1984040204390000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC.ARPA with TCP; Mon 2 Apr 84 12:40:34-PST Date: 2 Apr 1984 1239 PST From: Eric P. Scott Subject: Security/Privacy in a large broadcast Local Area Network To: TCP-IP@SRI-NIC.ARPA Reply-To: EPS@JPL-VLSI We would like to pass sensitive information over a broadcast LAN; one of the problems with this is that traffic appears everywhere on the cable. This is one of those "outlet in every office" deals and the ability of a snoop with a suitable personal computer to abuse the "promiscuous receive" feature of his LAN interface has some people worried. I would appreciate commentary on the following strategy as to its feasibility (or details, if something similar has already been done). 1. Network interfaces have a moderate amount of "intelligence." 2. There should be a minimal impact on host software (ideally this should be transparent). 3. All single-destination datagrams would be encrypted using at least a commercial grade public-key scheme. Frame headers would remain untouched; just the "data" would be scrambled. 4. Broadcast/Multicast datagrams would not be encrypted. 5. Gateways only see plaintext. 6. A network interface broadcasts its public key upon request, or if it is changed. 7. Each interface maintains a cache of recently used keys. If a datagram needs to be sent to a host whose key is unknown, it is dropped; a cache entry is made with a "null" key and a key request is broadcast. Whenever a key definition broadcast is seen each interface updates its cache if the sender is listed. 8. This could be integrated with ARP. Replies to the list, please. -=EPS=- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984040206510000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC.ARPA with TCP; Mon 2 Apr 84 14:51:55-PST Date: 2 Apr 1984 1451 PST From: Eric P. Scott Subject: Re: Secure LAN/more on security To: TCP-IP@SRI-NIC Reply-To: EPS@JPL-VLSI I should have specified unclassified only! I also deliberately did not specify that all traffic would be IP-based. The whole point of this is that physical security of the cable is out. Your turn. -=EPS=- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984040212210000> Return-Path: Received: from CISL-SERVICE-MULTICS.ARPA by SRI-NIC.ARPA with TCP; Mon 2 Apr 84 14:23:29-PST Date: Mon, 2 Apr 84 17:21 EST From: "Benson I. Margulies" Subject: Secure LAN To: tcp-ip@SRI-NIC.ARPA Message-ID: <840402222144.727363@CISL-SERVICE-MULTICS.ARPA> First, a Caveat. The DoD Computer Security Center is still studying standards for networks to accompany the Orange Book criteria for systems. ANYTHING you do should be bounced off of them. Dan Edwards at Ft. Meade is a good starting contact. We have a preliminary MLS TCP/IP running on the NSC hyperchannel. The assumption is that a trusted interface must filter datagrams destined for non-multi-level machines. The cable must be physically secured (no easy trick). All of our TCP connections are single-level. Without special privilege, a process can only initiate a TCP connection at its level and categories. I would suggest that you pay special attention to the data integrity of the IP Security option. The 1-s complement checksum is clearly insufficient to protect this from single-bit errors that could change the compartment marking of a datagram. Your network will have to have hardware data integrity to suplement/replace the IP checksum. have fun, benson ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984040212280000> Return-Path: Received: from CISL-SERVICE-MULTICS.ARPA by SRI-NIC.ARPA with TCP; Mon 2 Apr 84 14:30:45-PST Date: Mon, 2 Apr 84 17:28 EST From: "Benson I. Margulies" Subject: more on security To: tcp-ip@SRI-NIC.ARPA Message-ID: <840402222825.206812@CISL-SERVICE-MULTICS.ARPA> I realize that I lept to an assumption -- that you were in the MLS business. Far easier than public key hardware, I think, would be to use MLS and IP security options. All that key exchange looks like a drag. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984040214075200> Return-Path: Received: from ddn1 by SRI-NIC.ARPA with TCP; Mon 2 Apr 84 16:25:26-PST Date: 2 Apr 84 19:07:52 EST From: dca-pgs @ DDN1 Subject: Zilog Z8000 System To: tcp-ip @ sri-nic CC: dca-pgs @ DDN1 Does anybody know anything about this system? I understand it runs a sort of Unix-like OS called Zeus. How hard (or possible?) would it be to port Berkeley utilities (like TCP/IP) to this? Seems like it might be most worthwhile to port Berk Unix onto the Zilog hardware. Discussion/suggestions invited. Sincerely, Pat Sullivan DCA/DDN/PMO ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984040214560000> Return-Path: Received: from CMU-CS-A.ARPA by SRI-NIC.ARPA with TCP; Mon 2 Apr 84 16:57:57-PST Date: 2 Apr 84 1956 EST From: Rudy.Nedved@CMU-CS-A.ARPA To: EPS@JPL-VLSI.ARPA Subject: Re: Security/Privacy in a large broadcast Local Area Network CC: TCP-IP@SRI-NIC.ARPA In-Reply-To: "Eric P. Scott's message of 2 Apr 84 15:39-EST" Message-Id: <02Apr84.195607.EN0C@CMU-CS-A.ARPA> A bunch of people at CMU got together and discussed security on LANs. We ended up having a physically secure cable with a gateway at the end which was also physically secured. The gateway looks at what "cable" the packet came from, where it wants to go to and where it says it from and then looks it up in a table. If the table disagrees with the destination or source as described by the per cable info then the packet is dropped. The result is "public" or "insecure" sites can not see packets between two secure sites (this also reduces load), public sites can not fake out a secure site and a public site can not disrupt a conversation between two secure sites. The above mechanism works pretty well and doesn't address the issue of what to do with the public sites that want a degree of security like someone connecting from their PC to a secure site and typing their password in. We have no solution at present given that 1) public key encryption needs an authentication server and all the problems with generating keys for each new connection....very high CPU costs (one estimate was 16 seconds of raw PDP-11/23 time) and 2) gateways and vendor supplied software don't deal with the problem so unless everything understands that everything is encrypted how do you avoid someone aborting connections and re-transmitting old data (also none of the current protocols deal with "sabotage" of intermediate gateways/bridges). In general, once something goes across something that is "public" you can no longer trust the data or the relaibilit of the connection. You can probably encrypt the data at the application level like the contents of a mail message and use people with chained brief cases to exchange secret keys but you can not prevent the message from being "derailed" or stopped. -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984040303061900> Return-Path: Received: from USC-ISIF by SRI-NIC.ARPA with TCP; Tue 3 Apr 84 11:08:25-PST Date: 3 Apr 1984 11:06:19 PST From: POSTEL@USC-ISIF Subject: Privacy on Broadcast LANs To: tcp-ip@SRI-NIC Eric Scott: Privacy protection in Broadcast systems is a real problem. I want to encourage work on developing a way to provide privacy for the transmission of user data in such environments. I think the outline of points you present are a good starting point. Please go ahead with this and formulate a draft proposal for a protocol. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984040303110000> Return-Path: Received: from CISL-SERVICE-MULTICS.ARPA by SRI-NIC.ARPA with TCP; Tue 3 Apr 84 11:49:49-PST Date: Tue, 3 Apr 84 08:11 EST From: "Benson I. Margulies" Subject: Securing LAN's Reply-To: tcp-ip-request@SRI-NIC.ARPA To: tcp-ip@SRI-NIC.ARPA Message-ID: <840403131132.385798@CISL-SERVICE-MULTICS.ARPA> Oh well. Do you really need public key? Would (hiss, boo) DES take care of your problems? Somehow, it seems to me that trusted adapters could use fairly simple encryption in this environment, and them public-key would be used on a host-host or agent-agent level for reeally sensitive data, like mail. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984040309290000> Return-Path: Received: from SRI-KL.ARPA by SRI-NIC.ARPA with TCP; Tue 3 Apr 84 18:19:46-PST Date: 3 Apr 1984 17:29-PST Sender: BILLW@SRI-KL Subject: security, IBMPC TCP/IP From: William "Chops" Westfield To: tcp-ip@NIC Message-ID: <[SRI-KL] 3-Apr-84 17:29:29.BILLW> Gee, I pointed this out privately, but since everyone seems to be neglecting the fact, arent public keys systems computationally very slow? i think even the DES chips would have a hard time keeping up with ethernet data rates. (faster than most disks, remember...) On a totally unrelated issue, I have heard that the MIT TCP/IP for the IBM PC was released to the public domain after they gave up trying to find someone to market it. Is this true, and if so, how do I get a copy... Thanks Bill W ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984040311073800> Return-Path: Received: from bbnccq by SRI-NIC.ARPA with TCP; Tue 3 Apr 84 14:23:53-PST Date: Tue, 3 Apr 84 16:07:38 EST From: Jonathan Dreyer Subject: Re: Security/Privacy in a large broadcast Local Area Network In-Reply-To: Your message of 2 Apr 1984 1239 PST To: EPS@JPL-VLSI Cc: TCP-IP@SRI-NIC.ARPA Eric, 8. This could be integrated with ARP. Actually, ARP could do most of the work. ARP packets have two fields, ar$hrd (hardware address space, e.g. Ethernet, Packet Radio Net) and ar$hln (byte length of each hardware address) that could be twiddled for this purpose. Currently, ARP implementations on ethernets use a 1 for the ar$hrd field to indicate ethernet and 6 for the ar$hln field. All you have to do is to consider "ethernet with encryption" to be a new hardware type (ar$hrd) and consider hardware addresses to be ethernet addresses concatenated with public encryption keys, so ar$hln would be 6 + (encryption key length). Wherever you would place an ethernet address, you instead place the ethernet address followed by your public encryption key. Then it should all "just work"; ARP should handle the key distribution and cacheing automatically. This would be a good test of the generality of your ARP implementation. (Luckily, my implementation lives in a gateway and "gateways see only plaintext.") This is aesthetically nice because in an encrypted environment the encryption key is really part of the "address" of an encrypted packet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984040317113900> Return-Path: Received: from BRL-TGR by SRI-NIC.ARPA with TCP; Tue 3 Apr 84 19:35:22-PST Date: Tue, 3 Apr 84 22:11:39 EST From: Mike Muuss To: dca-pgs@ddn1.arpa cc: tcp-ip@sri-nic.arpa, dca-pgs@ddn1.arpa Subject: Re: Zilog Z8000 System Last I heard, Zeus was a port of UNIX Version 7 to the Zilog Z8000 fempto-processor. It can comfortably support a handful of users. Porting Berkeley's TCP/IP to a V7 kernel will take a skilled kernel programmer about 3 man-months (kernel code plus user support). But, fitting TCP/IP into limited address-space processors is *real hard*, starting with the Berkeley implementation. Which is not to try and denigrate the Berkeley code; it just takes a lot of space -- but you get lots of generality for it. I speak on this with some experience: when ARPANET converted to TCP/IP, I lead a team of 3 people to port the Berkeley code to our V6 PDP-11 system. We had a functioning (but not perfect) implementation in 1 month (and missed the 1-Jan conversion date by only 1 day!). Of course, it would have been twice as hard if we hadn't had the fine work of the folks at SRI (2.8a BSD effort) to start from. Porting a full 4.2 BSD (VAX-UNIX) to a less than 32-bit processor is likely to be excessively difficult, and a waste of time. So, while people who use real computers do their software maintenance over reliable high-speed networks, our micro-processor fiends find themselves maintaining 100's of tiny computers via the "shopping carts full of floppy disks" procedure. Chuckle! Best, -Mike Muuss U. S. Army Ballistic Research Laboratory ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984040416030000> Return-Path: Received: from MIT-MULTICS.ARPA by SRI-NIC.ARPA with TCP; Wed 4 Apr 84 18:06:41-PST Date: Wed, 4 Apr 84 21:03 EST From: JSLove@MIT-MULTICS.ARPA (J. Spencer Love) Subject: Secure LAN's To: TCP-IP@SRI-NIC.ARPA Message-ID: <840405020316.137221@MIT-MULTICS.ARPA> The ones completement checksum that is a standard for IP headers is really not sufficient for the IP security option, as Benson Margulies pointed out. However, the IP checksum must be recomputed at every IP gateway, since time-to-live changes, even if there are no options to change. Thus, any network which uses IP security options can use a better checksum (e.g., CRC). Since security options are not used on the ARPA from such secured networksnet (the research side, anyway), all gateways onto ARPA from such secured networks must assume that the option might not be honored and restrict sensitive traffic according the the handling restrictions. Everything that is needed for deliver of a datagram, modulo the protocol violations that occur in the mail-only gateways, is in the IP header. Thus, everything in the protocol portion of the datagram, including the protocol header, can be encrypted. CRC and DES are both available in cheap hardware, and thus are good candidates for a properly designed system; if either must be done in software, cheapness of calculation probably rules both out. Key exchange and further interpretation of the security option are properly the subject of additional standards. I suspect that such documents exist. I also suspect that they are classified. (Actually, I have such a document on the security option, and while "classified" is too strong; I don't have a clearance; they are fairly hard to come by). Would the No Such Agency types care to comment? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984040502250000> Return-Path: Received: from STL-HOST1.ARPA by SRI-NIC.ARPA with TCP; Thu 5 Apr 84 06:28:42-PST Date: 5 Apr 1984 08:25-CST Sender: PVAYDA@STL-HOST1 Subject: Re: Secure LAN's From: PVAYDA@STL-HOST1 To: JSLove@MIT-MULTICS Cc: TCP-IP@SRI-NIC Message-ID: <[STL-HOST1] 5-Apr-84 08:25:57.PVAYDA> In-Reply-To: <840405020316.137221@MIT-MULTICS.ARPA> Steve: a. WHY we leaving off DDN/Dhenry on such goodness stuff?, since he has a viable interest.. b. What is the DNG list? I never saw...but...with all other glitch- ery with BUREAU and AUTOCOM listings...(PLUS "fact" that , supposedly, stl-host1 MAIL is still screwed up (as far as being rec`d at Hq Here)??? ( I guess I`m losing track of system "management"... PeevVee ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041003175100> Return-Path: Received: from yale by SRI-NIC.ARPA with TCP; Tue 10 Apr 84 05:24:20-PST Received: by YALE-BULLDOG via CHAOS; Tue, 10 Apr 84 08:19:56 EST Date: Tue, 10 Apr 84 08:17:51 EST From: Nathaniel Mishkin Subject: CSNet To: tcp-ip@SRI-NIC.ARPA Could someone illuminate that present and expected future relationship between the ARPA Internet and CSNet? I take it that an increasing number of CSNet sites are actually able to communicate with each other via IP (but that a number of CSNet sites are still communicating only via UUCP-like methods). What is the role of Telenet in this? Will all CSNet sites use it as a data link level, or will there be other data links? Also, I take it that there are IP gateways between CSNet and the ARPA Internet. If this is so, in what sense is CSNet different from the ARPA Internet? Is there some mechanism for preventing IP packets from a CSNet site to a CSNet site from traversing DoD-funded networks? Do CSNet sites have unrestricted access to DoD-funded networks when the CSNet sites want to communicate with an ARPA Internet site? Please respond to me directly, because I'm not on this list. Thanks. -- Nat ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041205360000> Return-Path: Received: from SRI-CSL by SRI-NIC.ARPA with TCP; Thu 12 Apr 84 13:42:49-PST Date: 12 Apr 1984 13:36-PST Sender: GEOFF@SRI-CSL Subject: Re: CSNet From: the tty of Geoffrey S. Goodfellow To: drockwel@BBN-VAX Cc: Mishkin@YALE, tcp-ip@SRI-NIC, cic@CSNET-CIC Cc: obrien@RAND-UNIX, jdreyer@BBN-VAX, mimno@BBN-VAX Cc: gurwitz@BBN-VAX Message-ID: <[SRI-CSL]12-Apr-84 13:36:09.GEOFF> In-Reply-To: The message of Thu, 12 Apr 84 14:29 EST from Dennis Rockwell I have a couple of curiosity inspired questions I'd like to toss out: 1) In the most recent update of HOSTS.TXT from the NIC, it seems that DECWRL moved from [14.0.0.13] (going thru the VAN-GATEWAY at BBN) to [192.5.58.3] (going thru CSNET-PDN-GW on [10.7.0.49] which is really CSNET-RELAY). Why the switch from using the LSI-11/23 VAN-GATEWAY to using the CSNET-RELAY VAX/UNIX as bridge between Telenet and the DARPA Internet? And then, why only for DECWRL? 2) When someone on the DARPA Internet side of the house originates an IP connection to a host on the GTE Telenet side of the house, who pays for the packet charges? (i.e., I'm at a MILNET or ARPANET TAC, or even SRI-CSL for that matter, open a connection to RICE, for example, which will involve the VAN-GATEWAY (?or perhaps CSNET-RELAY?), which then uses the IP-in-X.25 encapsulation scheme between the VAN-GATEWAY and RICE, over Telenet). Since the Telenet `Call' is originating from the VAN-GATEWAY to RICE, doesn't the VAN-GATEWAY get charged for all packet or costs thusly incurred? I'm assuming this because it is my understanding that the originating host on Telenet pays for all costs associated with a `Call'. When the originating host is the VAN-GATEWAY, who pays? 3) Wouldn't it be possible for hosts on either side of the VAN-GATEWAY to bypass access control restrictions in the VAN-GATEWAY by forcing their Internet traffic to be routed thru hosts like CSNET-RELAY (or others?) which are dual-homed on more than one network? g ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041209290000> Return-Path: Received: from bbn-vax by SRI-NIC.ARPA with TCP; Thu 12 Apr 84 11:32:57-PST Date: Thu, 12 Apr 84 14:29 EST From: Dennis Rockwell Subject: Re: CSNet To: Nathaniel Mishkin , tcp-ip@sri-nic Cc: cic@csnet-cic, obrien@rand-unix, jdreyer@BBN-VAX, mimno@BBN-VAX, gurwitz@BBN-VAX This is a complex question. As of right now, there are some CSNet sites that communicate with each other and the CSNET-RELAY host via IP. Some of these hosts are on the ARPAnet, and some are connected to GTE Telenet via an IP-in-X.25 encapsulation scheme. This net (PDN, net 14) is connected to the rest of the internet through a special gateway (the VAN gateway). As for CSNet access to DoD-funded networks, DARPA-approved domestic X.25-based CSNet sites can exchange packets freely with Internet hosts because of a special agreement between NSF and DARPA. This agreement basically prohibits those sites from relaying packets outside their organization and insures that no charges will be levied on Internet hosts for network access. There are access controls in the gateway to only allow certain hosts to communicate with each other, but these are in fact open at this point; this is only because we have no non-domestic sites right now. When we do have foreign sites, they will have complete access to other CSNet X.25-based sites, but no direct access to the rest of the Internet. They will have to relay mail through CSNET-RELAY. We do not expect this restriction to change in the near future. The X.25 portion of our network is expected to grow; we currently have three sites connected, with about a half dozen waiting for the software to get out of beta-test. All the X.25-based CSNet sites are on the same network (except for a couple on a testbed network), so if they were to talk to each other, there would be no DoD network in the middle; however, the CSNet sites that are also ARPAnet hosts must use the ARPAnet to contact any other sites. If you have any questions, feel free to write me or call (617) 497-2643. Dennis Rockwell CSNet Technical Staff ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041209530000> Return-Path: Received: from SRI-CSL by SRI-NIC.ARPA with TCP; Thu 12 Apr 84 17:57:40-PST Date: 12 Apr 1984 17:53-PST Sender: GEOFF@SRI-CSL Subject: Re: CSNet From: the tty of Geoffrey S. Goodfellow To: cak@PURDUE Cc: Mishkin@YALE, tcp-ip@SRI-NIC, cic@CSNET-CIC Cc: obrien@RAND-UNIX, jdreyer@BBN-VAX, mimno@BBN-VAX Cc: gurwitz@BBN-VAX, drockwel@BBN-VAX Message-ID: <[SRI-CSL]12-Apr-84 17:53:32.GEOFF> In-Reply-To: <8404122232.AA18034@merlin.ARPA> Chris Thanks for the explanations. With them in mind, is it possible for X.25 hosts to selectively accept/refuse collect calls based on the source address? Two situations come to mind: (Ref: last summers antics of the 414s's and more recently the article "HACKING ON TELENET. It's as easy as 123456!", cover story, Volume one, Number two, Feb '84, 2600). Selectively accepting collect calls ONLY from the VAN-GW, while refusing them all others would prevent random crackers from connecting up to a site from uncontrolled public Telenet TACs and incurring packet charges while attempting to break in. An unneighborly Telenet host which sets the `collect call' bit when opening connections to other hosts within Telenet (or thru a secret gateway which didn't have the refuse collect call bit set) in order to circumvent packet charges. Given the above, if I were a CSNET site on Telenet, it would seem a prudent measure to refuse collect calls all hosts other than the VAN-GW, don't you think? g ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041212320000> Return-Path: Received: from merlin.ARPA by SRI-NIC.ARPA with TCP; Thu 12 Apr 84 14:35:41-PST From: Christopher A Kent Message-Id: <8404122232.AA18034@merlin.ARPA> Received: by merlin.ARPA; Thu, 12 Apr 84 17:32:08 est Date: 12 Apr 1984 1732-EST (Thursday) To: the tty of Geoffrey S. Goodfellow Cc: Mishkin@YALE.ARPA, tcp-ip@SRI-NIC.ARPA, cic@CSNET-CIC.ARPA, obrien@RAND-UNIX.ARPA, jdreyer@BBN-VAX.ARPA, mimno@BBN-VAX.ARPA, gurwitz@BBN-VAX.ARPA, drockwel@BBN-VAX.ARPA Subject: Re: CSNet In-Reply-To: Your message of 12 Apr 1984 13:36-PST. <[SRI-CSL]12-Apr-84 13:36:09.GEOFF> 1) In the most recent update of HOSTS.TXT from the NIC, it seems that DECWRL moved from [14.0.0.13] (going thru the VAN-GATEWAY at BBN) to [192.5.58.3] (going thru CSNET-PDN-GW on [10.7.0.49] which is really CSNET-RELAY). Why the switch from using the LSI-11/23 VAN-GATEWAY to using the CSNET-RELAY VAX/UNIX as bridge between Telenet and the DARPA Internet? And then, why only for DECWRL? Purdue-tn moved, too. We (CSNET) are experimenting with using a VAX running 4.2 Unix and the Purdue-developed IP over X.25 code (called XNI) as a gateway, because throughput through the VAN gateway is often quite bad. This is mainly due to the large speed mismatch between the Arpanet (56K) and Telenet (9.6K), and the limited number of buffers the VAN gateway has, as well as some Telenet specific limitations (example: you can only have two packets in flight on a channel at a given time without having received their end-to-end X.25 ACK.) By running in a VAX, the gateway can survive bursts in a nicer fashion. The XNI code also can be configured to open multiple channels to the same site, and round-robins through them, giving the effect of a larger X.25 window, leading to higher throughput. 2) When someone on the DARPA Internet side of the house originates an IP connection to a host on the GTE Telenet side of the house, who pays for the packet charges? (i.e., I'm at a MILNET or ARPANET TAC, or even SRI-CSL for that matter, open a connection to RICE, for example, which will involve the VAN-GATEWAY (?or perhaps CSNET-RELAY?), which then uses the IP-in-X.25 encapsulation scheme between the VAN-GATEWAY and RICE, over Telenet). Since the Telenet `Call' is originating from the VAN-GATEWAY to RICE, doesn't the VAN-GATEWAY get charged for all packet or costs thusly incurred? I'm assuming this because it is my understanding that the originating host on Telenet pays for all costs associated with a `Call'. When the originating host is the VAN-GATEWAY, who pays? X.25 allows you to make collect calls; the gateway always calls collect, and never accepts a collect call. 3) Wouldn't it be possible for hosts on either side of the VAN-GATEWAY to bypass access control restrictions in the VAN-GATEWAY by forcing their Internet traffic to be routed thru hosts like CSNET-RELAY (or others?) which are dual-homed on more than one network? The only hosts that are dual-homed as such are the gateways, and they have the access control built in. Cheers, chris ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041300130000> Mail-From: HSS created at 13-Apr-84 13:32:58 Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC.ARPA with TCP; Fri 13 Apr 84 08:23:15-PST Date: 13 Apr 1984 0813 PST From: Scott McCord Subject: SMTP To: tcp-ip-request@sri-nic Reply-To: SMJPM@JPL-VLSI.ARPA ReSent-date: Fri 13 Apr 84 13:32:58-PST ReSent-from: Harry Sameshima ReSent-to: tcp-ip@SRI-NIC.ARPA Does anyone know if Federal Information Processing Standard 98,"Message Format for Computer-based Message Systems," (FIPS 98) is compatible with SMTP? i.e will SMTP accept a message in this format? Also if not, can FIPS 98 be adapted as it's own application running over TCP/IP? (I'm not familiar enough with its internal format and adressing scheme to make this determination) Any feedback/input on this topic would be very helpful. Scott McCord ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041304352000> Mail-From: ROODE created at 13-Apr-84 12:35:21 Date: Fri 13 Apr 84 12:35:20-PST From: David Roode Subject: Re: IP over Telenet To: Mishkin@YALE.ARPA, TCP-IP@SRI-NIC.ARPA In-Reply-To: Message from "Nathaniel Mishkin " of Fri 13 Apr 84 12:17:21-PST Location: EJ286 Phone: (415) 859-2774 The biggest advantage of Telenet for use as the backbone of a pseudo net is that the connections are switched and dynamic. When not needed, the connections are broken and no cost is incurred. Connections can be established to any host on Telenet. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041305230000> Return-Path: Received: from merlin.ARPA by SRI-NIC.ARPA with TCP; Fri 13 Apr 84 07:26:41-PST From: Christopher A Kent Message-Id: <8404131523.AA21135@merlin.ARPA> Received: by merlin.ARPA; Fri, 13 Apr 84 10:23:30 est Date: 13 Apr 1984 1023-EST (Friday) To: the tty of Geoffrey S. Goodfellow Cc: Mishkin@YALE.ARPA, tcp-ip@SRI-NIC.ARPA, cic@CSNET-CIC.ARPA, obrien@RAND-UNIX.ARPA, jdreyer@BBN-VAX.ARPA, mimno@BBN-VAX.ARPA, gurwitz@BBN-VAX.ARPA, drockwel@BBN-VAX.ARPA Subject: Re: CSNet In-Reply-To: Your message of 12 Apr 1984 17:53-PST. <[SRI-CSL]12-Apr-84 17:53:32.GEOFF> I believe that it is possible to accept/refuse collect calls on a per host basis, if your implementation supports it. Essentially what happens is that the caller sends a call request packet, indicating that it wants to make a collect call; the callee gets to inspect that packet and decide whether or not it will accept or refuse, and sends an ACK or NAK (effectively). The CSNET sites on Telenet do mostly refuse collect calls, though some pairs of hosts may agree that one should always pay. In general, the XNI code tries not to accept calls from anyone other than another CSNET site (since incoming PAD support isn't currently working in the 4.2bsd code). In reality, hardware brain-damage makes this a little difficult, but that is changing. Cheers, chris ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041307200000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC.ARPA with TCP; Fri 13 Apr 84 15:22:41-PST Date: 13 Apr 1984 1520 PST From: Eric P. Scott Subject: SMTP and FIPS 98 To: TCP-IP@SRI-NIC.ARPA Cc: SMJPM@JPL-VLSI.ARPA Reply-To: EPS@JPL-VLSI.ARPA Afraid not. The first third or so of FIPS 98 is pretty interesting (it brings up a number of important points along with describing the motivation for the document). There are a few good ideas that would fit in well with RFC 822, but I'm not particularly thrilled with it (FIPS 98) as a standard. RFC 822 is entirely text-based, FIPS 98 is geared mor towards an "internal representation" rather than something to pass between hosts in a heterogenous environment. In any case, the two are not compatible. -=EPS=- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041307561400> Return-Path: Received: from bbnccq by SRI-NIC.ARPA with TCP; Fri 13 Apr 84 10:05:19-PST Date: Fri, 13 Apr 84 12:56:14 EST From: Jonathan Dreyer Subject: Re: CSNet In-Reply-To: Your message of 12 Apr 1984 17:53-PST To: the tty of Geoffrey S. Goodfellow Cc: cak@PURDUE, Mishkin@YALE, tcp-ip@SRI-NIC, cic@BBN-UNIX, obrien@RAND-UNIX, jdreyer@BBN-UNIX, mimno@BBN-UNIX, gurwitz@BBN-UNIX, drockwel@BBN-UNIX The VAN gateway has "got a little list" of hosts it accepts calls from and hosts it may call, and it never accepts reverse-charge calls. Every once in a while I get a trap message saying that the gateway rejected a call from some random host. I assume that these calls are either wrong numbers or curious folks at Pads. I checked a few of the soures with Telenet, and they all were public Pads. Jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041308531900> Return-Path: Received: from CMU-CS-G.ARPA by SRI-NIC.ARPA with TCP; Fri 13 Apr 84 11:16:44-PST Date: Fri, 13 Apr 84 13:53:19 EST From: Paul Milazzo Subject: Re: CSNet To: the tty of Geoffrey S. Goodfellow Cc: cak@PURDUE.ARPA, Mishkin@YALE.ARPA, tcp-ip@SRI-NIC.ARPA, cic@CSNET-CIC.ARPA, obrien@RAND-UNIX.ARPA, jdreyer@BBN-VAX.ARPA, mimno@BBN-VAX.ARPA, gurwitz@BBN-VAX.ARPA, drockwel@BBN-VAX.ARPA Message-Id: <1984.04.13.13.53.23.954.28792@cmu-cs-g.ARPA> In-Reply-To: a message from the tty of Geoffrey S. Goodfellow dated 12 Apr 1984 17:53-PST Geoff: One problem with refusing collect calls from random Telenet addresses is that I, along with other legitimate users, call my host (RICE) from all sorts of random places. I suffer from withdrawal symptoms if deprived of my mail for more than a day or so, and for all of Telenet's disadvantages, at least I'm never far from a Telenet office. Paul G. Milazzo (temporarily hiding at CMU) Dept. of Computer Science Rice University, Houston, TX ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041309401500> Mail-From: ROODE created at 13-Apr-84 17:40:15 Date: Fri 13 Apr 84 17:40:15-PST From: David Roode Subject: Re: CSNet To: FRANK@UTAH-20.ARPA, milazzo@CMU-CS-G.ARPA, Geoff@SRI-CSL.ARPA cc: cak@PURDUE.ARPA, Mishkin@YALE.ARPA, tcp-ip@SRI-NIC.ARPA, cic@CSNET-CIC.ARPA, obrien@RAND-UNIX.ARPA, jdreyer@BBN-VAX.ARPA, mimno@BBN-VAX.ARPA, gurwitz@BBN-VAX.ARPA, drockwel@BBN-VAX.ARPA In-Reply-To: Message from "Randy Frank " of Fri 13 Apr 84 15:43:37-PST Location: EJ286 Phone: (415) 859-2774 The optional mode of operation for Telenet described by Randy Frank (issuance of network id's) is the standard mode of operation for Tymnet. It is interesting to note that news accounts of breakins over commercial networks seem to always involve Telenet sites which do accept collect calls, and the news articles never mention that the acceptance of collect calls was a factor. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041309404800> Return-Path: Received: from UTAH-20.ARPA by SRI-NIC.ARPA with TCP; Fri 13 Apr 84 15:42:52-PST Date: Fri 13 Apr 84 16:40:48-MST From: Randy Frank Subject: Re: CSNet To: milazzo@CMU-CS-G.ARPA, Geoff@SRI-CSL.ARPA cc: cak@PURDUE.ARPA, Mishkin@YALE.ARPA, tcp-ip@SRI-NIC.ARPA, cic@CSNET-CIC.ARPA, obrien@RAND-UNIX.ARPA, jdreyer@BBN-VAX.ARPA, mimno@BBN-VAX.ARPA, gurwitz@BBN-VAX.ARPA, drockwel@BBN-VAX.ARPA In-Reply-To: Message from "Paul Milazzo " of Fri 13 Apr 84 16:33:55-MST There is a relatively easy solution to the collect call problem. We are on Telenet, and refuse collect calls from all sites. For people we want to communicate with us we issue network id's (not that dissimilar from TAC login ids). With network id's calls placed from a Telenet pad are not placed collect; instead, they are placed prepaid, and the charges billed to the network id. Another advantage of this approach is that Telenet charges are then broken down by id. It has the disadvantage that you must issue someone who wants to access your host an id beofre they can do so, and that each id must be registered with Telenet before being activated. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041310062600> Return-Path: Received: from yale by SRI-NIC.ARPA with TCP; Fri 13 Apr 84 12:17:02-PST Received: by YALE-BULLDOG via CHAOS; Fri, 13 Apr 84 15:14:32 EST Received: from YALE-RING by YALE-RES via CHAOS; Fri, 13 Apr 84 15:06:23 EST Subject: IP over Telenet Date: Fri, 13 Apr 84 15:06:26 EST From: Nathaniel Mishkin To: TCP-IP@SRI-NIC.ARPA Next dumb question: isn't it overkill to use Telenet as a data link for IP? I mean, isn't Telenet providing reliable connections whose reliability is then ignored by IP and TCP? Is it possible to rent unreliable (and presumably cheaper) links from Telenet or someone else? Please reply to me directly because... -- Nat ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041313430000> Return-Path: Received: from SU-SCORE.ARPA by SRI-NIC.ARPA with TCP; Fri 13 Apr 84 21:46:39-PST Date: Fri 13 Apr 84 21:43:00-PST From: Philip Almquist Subject: Re: IP over Telenet To: Mishkin@YALE.ARPA cc: TCP-IP@SRI-NIC.ARPA In-Reply-To: Message from "Nathaniel Mishkin " of Fri 13 Apr 84 16:04:01-PST Nat, X/25 (upon which Telenet is based) is not "reliable" (in the technical sense of the word) in some circumstances. Those circum- stances are those in which an X/25 link can die but communication can continue via another path. Suppose, for example, that I can get to some remote site by Telenet or by some other transport layer. I open a connection to that host, and my host chooses to route me via Telenet. I start a data transfer, and then for some reason my Telenet connection vanishes. My host should be able to reroute my connection through the other net, but if it has not been using a reliable protocol (such as TCP) on top of X/25 it cannot. Why? It cannot tell how much data was lost in transmission when my Telenet connection died. You need packets and acks (ie, a "reliable" protocol) to tell you that. Even if an X/25 net is the only path to the remote host you can get similar lossage if the X/25 net does not do dynamic routing internally (I'm not an expert on Telenet, so I don't know whether it does). If the X/25 net is uses static routing and some component of the route I am using goes down, my host ought to be able to (behind my back) get a working route by issuing another call request. Once again, the host can only do this if it knows what was lost. The situation gets worse when you get into internetting, since X/25 is also not (or at least not usually thought of as) an end-to-end protocol. If I am on an ARPA host, and I want to talk to an X/25 host through a gateway I want my connection to be reliable. Even if the ARPAnet provides reliable transport between me and the gateway and X/25 provides reliable transport between the gateway and the X/25 host it is still possible that the gateway will screw up (or run out of buffers, or ...). I'd have to implement end-to-end X/25 @i(on top of) Telenet to protect me from the gateway, or instead I could use another end-to-end protocol such as TCP. @begin(flame) When you use TCP and IP on top of an X/25 net it is the X/25 (and not the TCP or IP) that is overkill. For most sorts of network hardware it takes a lot of extra effort to implement the pseudo- reliability that X/25 provides, and the effort is wasted since higher- level protocols have to treat a psedo-reliable net as if were unreliable. The good things that can be said about X/25 are: 1) It works ok for terminal<-->host connections, since these can get by with an approximation of reliability (the human operator reestablishes the connection and figures out what got through and what didn't). 2) People who have worked for the phone company for a long time find the X/25 model easy to understand and (perhaps more importantly) easy to bill for. For this reason alone X/25 has become both the de facto international standard (if not the official international standard) network transport layer. @end(flame) Philip ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041406100000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC.ARPA with TCP; Sat 14 Apr 84 14:12:13-PST Date: 14 Apr 1984 1410 PST From: Eric P. Scott Subject: What it means to live in a Free Country To: TCP-IP@SRI-NIC.ARPA Reply-To: EPS@JPL-VLSI.ARPA is that I don't have to conform to CCITT "recommendations" because a state-run telecommunications monopoply makes it a "do or die" proposition. Thank goodness no one in this great nation of ours believes in the filth spread by CCITT ISO ANSI NBS IEEE ... ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041407391300> Return-Path: Received: from USC-ISIF by SRI-NIC.ARPA with TCP; Sat 14 Apr 84 15:42:12-PST Date: 14 Apr 1984 15:39:13 PST Subject: Re: What it means to live in a Free Country From: Paul Kirton To: EPS@JPL-VLSI cc: tcp-ip@SRI-NIC In-Reply-To: (Message from "Eric P. Scott " of 14 Apr 1984 1410 PST) ..but some of us want the freedom to communicate with other countries as well. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041407571900> Return-Path: Received: from Xerox.ARPA by SRI-NIC.ARPA with TCP; Sat 14 Apr 84 16:00:56-PST Received: from Gamay.ms by ArpaGateway.ms ; 14 APR 84 15:59:57 PST From: DonWinter.pasa@Xerox.ARPA Date: 14 Apr 84 15:57:19 PST Subject: Re: What it means to live in a Free Country In-reply-to: EPS@JPL-VLSI.ARPA's message of 14 Apr 84 14:10 PST To: EPS@JPL-VLSI.ARPA cc: DonWinter.pasa@Xerox.ARPA, TCP-IP@SRI-NIC.ARPA What are you foaming at the mouth about this time? Is it in response to the message from John Covert of DEC on the X.400 message system stuff, which appeared in today's issue of HumanNets? In case it is, let me respond. There is nothing in the X.400 stuff which prevents DEC (or Xerox, who I work for) from having a private network spanning several countries, provided it doen't carry non-DEC (or non-Xerox) traffic across national boundaries. Thus: (a) I can exchange messages with Rank Xerox in the UK, Sweden, or West Germany, over the Xerox internal net. (b) An Arpanet user at SRI can almost certainly NOT use the Xerox message system to communicate with someone at Siemens, in Munich, even though that person has a Xerox associate's message account. (c) I believe that it is OK for me to communicate with the Siemens person. (d) I believe that it is OK for the Rank Xerox people to communicate with a person at SRI. The crucial words are that a Private Domain may not BRIDGE two Administration Domains. There is nothing that says a Private Domain cannot INTERFACE with more than one Administration Domain, PROVIDING it is not carrying traffic BETWEEN those two Administration Domains. Don ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041416430000> Mail-From: ROODE created at 15-Apr-84 00:43:00 Date: Sun 15 Apr 84 00:43:00-PST From: David Roode Subject: Re: CSNet To: jdreyer@BBN-UNIX.ARPA, Geoff@SRI-CSL.ARPA cc: cak@PURDUE.ARPA, Mishkin@YALE.ARPA, tcp-ip@SRI-NIC.ARPA, cic@BBN-UNIX.ARPA, obrien@RAND-UNIX.ARPA, mimno@BBN-UNIX.ARPA, gurwitz@BBN-UNIX.ARPA, drockwel@BBN-UNIX.ARPA In-Reply-To: Message from "Jonathan Dreyer " of Fri 13 Apr 84 10:05:46-PST Location: EJ286 Phone: (415) 859-2774 Who operates the VAN gateway? Is is part of CSNET? Is it a general service for ARPANET? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041505521000> Return-Path: Received: from USC-ISIF by SRI-NIC.ARPA with TCP; Sun 15 Apr 84 13:55:19-PST Date: 15 Apr 1984 13:52:10 PST From: POSTEL@USC-ISIF Subject: Re: SMTP and FIPS 98 To: EPS@JPL-VLSI, TCP-IP@SRI-NIC cc: SMJPM@JPL-VLSI, POSTEL@USC-ISIF In response to the message sent 13 Apr 1984 1520 PST from EPS@JPL-VLSI.ARPA Any one looking at standards for the next mail system should be looking at the CCITT X.400 series recommendations. --jon. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041506530000> Return-Path: Received: from ACC.ARPA by SRI-NIC.ARPA with TCP; Sun 15 Apr 84 14:55:47-PST Date: 15 Apr 1984 1453-PST From: Lars Poulsen Subject: CCITT X.400 To: TCP-IP at NIC Reply-To: LARS at ACC What is the easiest way to get a copy of the X.400 spec ? If it is available in machine readable form anywhere, it oughta be published as an RFC ?? / Lars Poulsen ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041510301600> Return-Path: Received: from bbnccq by SRI-NIC.ARPA with TCP; Sun 15 Apr 84 12:36:54-PST Date: Sun, 15 Apr 84 15:30:16 EST From: Bob Hinden Subject: Re: CSNet In-Reply-To: Your message of Sun 15 Apr 84 00:43:00-PST To: David Roode Cc: jdreyer@BBN-UNIX.ARPA, Geoff@SRI-CSL.ARPA, cak@PURDUE.ARPA, Mishkin@YALE.ARPA, tcp-ip@SRI-NIC.ARPA, cic@BBN-UNIX.ARPA, obrien@RAND-UNIX.ARPA, mimno@BBN-UNIX.ARPA, gurwitz@BBN-UNIX.ARPA, drockwel@BBN-UNIX.ARPA, hinden@BBN-UNIX The VAN gateway is operated by BBNCC under contract from DARPA. It provides a limited expermental service for authorized Intenet users. Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041612490100> Return-Path: Received: from ddn1 by SRI-NIC.ARPA with TCP; Mon 16 Apr 84 15:31:06-PST Date: 16 Apr 84 17:49:01 EST From: dca-pgs @ DDN1 Subject: Govt Unix & TCP/IP Users Meeting, NBS, 9-10 May 1984 To: ddn-pmo @ DDN1 CC: dca-pgs @ DDN1, navyusers @ ddn, tcp-ip @ sri-nic Comment: Forwarded FYI. Pat Sullivan sends... Forwarded message(s): ----------------------------------------------------- Date: Mon, 16 Apr 84 15:38:14 EST From: myra @ Brl-Bmd.ARPA To: unicorn @ Brl-Bmd.ARPA Subject: May 84 Meeting at NBS Text: Spring 1984 UNICORN Meeting The Spring 1984 UNICORN Meeting will be held at the National Bureau of Standards, Gaithersburg, MD on 9-10 May 1984. Dr. Sinnott and Mr. Bob Crosson are sponsoring this meeting in the Green Auditorium. In order to provide NBS with as much attendence information as possible, please provide the names of your representatives by calling Sue Schantz at Autovon 283- 6674/6722, commercial (301) 278-6674/6722, NLT 4 May 1984. A registration fee of $10 per person is being charged as announced during the October 1983 meeting at Aberdeen Proving Ground, MD. Tables will be set up outside the Auditorium for registration. Registration fees will be collected and receipt provided. Everyone will be issued a badge. NBS has reserved a block of 50 rooms at the Holiday Inn of Gaithersburg, which is approximately 1 mile away. A list of the local hotels has been included for your convenience, should all the reserved rooms at the Holiday be filled. Your room reservations should be made at the Holiday by April 25th. ABOUT NBS No food, beverages or smoking is permitted in the Auditorium. A message board will be provided, the telephone number is FTS 921-3330. Public/pay phones are available for your use, outside the Auditorium. We will be dining at the NBS cafeteria for lunch, both days, therefore, our lunch breaks are scheduled for 1300-1400. This will eliminate an overload on the cafeteria staff, as well as the NBS staff. The cafeteria generally provides grill, soup/salad/sandwich, and "hot meal" lines. If we can be of any further assistance, please contact my office (the phone number is listed above). Hope to see all of you next month. UNICORN Agenda 9-10 May 1984 National Bureau of Standards Gaithersburg, Maryland GREEN AUDITORIUM 9 May 84 0800-0900 Registration (includes Coffee and Pastry) 0900-0910 Welcome Address Dr. Sinnott, NBS 0910-0930 Administrative Notes Myra Hartwig, BRL 0930-1045 Rome AFB Project Lonex Update COL Nacito, Rome AFB 1045-1100 Break - includes coffee 1100-1200 Dept of Army - Project HIOS 1200-1300 Technical Information System (TIS) Jerry Conway, IRS 1300-1400 LUNCH - NBS Cafeteria 1400-1500 UNIX Release 2.0 Craig Cook, Western Jack Kreger, Western 1500-1600 BRL System 5 Emulation for 4.2BSD Doug Gwyn, BRL 1600-1700 Defense Data Network Rod Richardson, DCA Pat Sullivan, DCA 1715 Adjourn 10 May 84 0830-0900 Registration (includes Coffee and Pastry) 0900-0930 Administrative Announcements Myra Hartwig, BRL 0930-1030 DoD Computer Security Center Sue O'Connor 1030-1045 Break - includes Coffee 1045-1145 SCOMP Dick Kane, Honeywell 1145-1300 Design Concepts for the Automated Office Randy Ivanciw, HQ, DA 1300-1400 LUNCH in NBS Cafeteria 1400-1500 Government Only Session 1500 Adjourn MYRA G. HARTWIG -------------END OF FORWARDED MESSAGE(S)------------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041613394300> Return-Path: Received: from UCB-VAX.ARPA by SRI-NIC.ARPA with TCP; Tue 17 Apr 84 01:29:43-PST Received: by UCB-VAX.ARPA (4.24/4.27) id AA18677; Tue, 17 Apr 84 01:27:23 pst Date: Mon, 16 Apr 84 21:39:43 pst From: ucscc!ucscc!emacs@Berkeley (05170000) Message-Id: <8404170539.AA16663@ucsccUCSC.ARPA> Received: by ucsccUCSC.ARPA (4.12/3.28UCSC) id AA16663; Mon, 16 Apr 84 21:39:43 pst To: tcp-ip@sri-nic.ARPA Subject: Info... I picked up your address locally and was wondering if you have any online documentation I could grab or you could send me on tcp/ip. I want to know everything about it. I do use it, but the subject is kind of fuzzy to me. I need to know the capabilities, the limitations, etc. Any help is appreciated... Mike ucscc!emacs@berkeley caroff@ames-vmsb ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041616263100> Return-Path: Received: from seismo.ARPA by SRI-NIC.ARPA with TCP; Mon 16 Apr 84 18:28:00-PST Return-Path: Received: by seismo.ARPA ; Mon, 16 Apr 84 21:26:31 est Date: Mon, 16 Apr 84 21:26:31 est From: rick@SEISMO (Rick Adams) Message-Id: <8404170226.AA19370@seismo.ARPA> To: unix-wizards@brl-vgr Subject: Strange TCP checksum problem with several interconnected networks Cc: tcp-ip@sri-nic Here's the situation: C--------D | | A--------B C & D are on the milnet (sharing the same imp). C & B are on an ethernet. A & B are connected with a serial line. A, B & C are on the same Class-B network. D is a vax running 4.2bsd. B & C are vaxes running 4.1C with the networking code of 4.2 (The 4.1C was extremely hacked before we got 4.2, so I "lifted" the 4.2 networking code). A is a 68000 running a System III compatible unix with TCP/IP based loosely on 3Comms UNET. A, C and D can all talk to each other in both directions (C as both a milnet number and the class-B network number). Here's where it starts to get strange. B can talk to A or C with the Class-B number. However, it can NOT talk to D or C as a Milnet number. (Before you say routing, remember A can talk to everyone and everyone can talk to A). The really wierd part is that when B is trying to talk to C or D, the destination machines (C/D) get TCP CHECKSUM ERRORS! The ip packets are ok. Destination Class-B Milnet Source A B C C D A ok ok ok ok ok B ok ok ok NO NO C ok ok ok ok ok D ok ok ok ok ok Any ideas on why I am getting TCP checksum errors in this one case would be greatly appreciated. ---rick ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041700392700> Mail-From: PERILLO created at 17-Apr-84 08:39:27 Date: Tue 17 Apr 84 08:39:27-PST From: Francine Perillo Subject: Re: Info... To: ucscc!ucscc!emacs@UCB-VAX.ARPA, tcp-ip@SRI-NIC.ARPA cc: PERILLO@SRI-NIC.ARPA, nic-staff@SRI-NIC.ARPA In-Reply-To: Message from "ucscc!ucscc!emacs@Berkeley (05170000)" of Tue 17 Apr 84 01:30:00-PST The Network Information Center (NIC) is the source of TCP/IP specs. We can send you the full set of documents if you send your mailing address to NIC@SRI-NIC. You have addressed a discussion list on the subject of TCP/IP implementation issues. -Francine /NIC ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041703080000> Return-Path: Received: from JPL-VLSI.ARPA by SRI-NIC.ARPA with TCP; Tue 17 Apr 84 11:12:14-PST Date: 17 Apr 1984 1108 PST From: Eric P. Scott Subject: FIPS 98 To: TCP-IP@SRI-NIC.ARPA Cc: DDeutsch@BBNA.ARPA,SMJPM@JPL-VLSI.ARPA,CLYNN@BBNA.ARPA Reply-To: EPS@JPL-VLSI.ARPA "There is a growing `non-ASCII world'" where FIPS 98 is more likely to get in trouble than SMTP. Just out of curiosity, has anyone actually implemented FIPS 98 on the Internet? Has a well- known port been assigned? -=EPS=- ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041703543000> Return-Path: Received: from bbnccq by SRI-NIC.ARPA with TCP; Tue 17 Apr 84 06:08:27-PST Date: Tue, 17 Apr 84 8:54:30 EST From: Mike Brescia Subject: Re: Strange TCP checksum problem with several interconnected networks In-Reply-To: Your message of Mon, 16 Apr 84 21:26:31 est To: rick@SEISMO (Rick Adams) Cc: unix-wizards@brl-vgr, tcp-ip@sri-nic, brescia@BBN-UNIX Rick, My first reaction is to suspect IP source routing. Are you using SR to get through to nets that are not known to the world? The feature of the TCP checksum that enters in here is that it is invariant as source routing is followed. The TCP pseudoheader used in the checksum has the ultimate destination rather than the first IP destination in it. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041705140900> Return-Path: Received: from BRL-TGR by SRI-NIC.ARPA with TCP; Tue 17 Apr 84 07:23:20-PST Date: Tue, 17 Apr 84 10:14:09 EST From: Ron Natalie To: Rick Adams cc: unix-wizards@brl-vgr.arpa, tcp-ip@sri-nic.arpa Subject: Re: Strange TCP checksum problem with several interconnected networks All I can suggest is to make sure that you are using the correct address in the TCP pseudo header while computing and checking checksums. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041706234600> Mail-From: HSS created at 17-Apr-84 14:23:46 Date: Tue 17 Apr 84 14:23:46-PST From: Harry Sameshima Subject: Failed mail To: tcp-ip@SRI-NIC.ARPA Many of the people on this list have been complaining about the annoying failed mail messages that they receive whenever the vagaries of the network prevent delivery. If there is enough interest, I'm willing to fix the problem by redistributing the mail manually. Naturally, a software solution would be better, but it's not likely to happen in the near future. Send comments to HSS@NIC. Harry Sameshima Coordinator ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041707030000> Return-Path: Received: from BBNA.ARPA by SRI-NIC.ARPA with TCP; Tue 17 Apr 84 09:04:49-PST Date: 17 Apr 1984 12:03-EST Sender: DDEUTSCH@BBNA Subject: Re: [Scott McCord : SMTP]... From: DDEUTSCH@BBNA To: EPS@JPL-VLSI Cc: TCP-IP@SRI-NIC, SMJPM@JPL-VLSI, CLYNN@BBNA Cc: DDeutsch@BBNA Message-ID: <[BBNA]17-Apr-84 12:03:17.DDEUTSCH> In-Reply-To: <[BBNA]13-Apr-84 19:33:52.CLYNN> Charlie Lynn passed your message along to me. I'd like to offer some clarification on the issue of FIPS 98/SMTP. FIPS 98 is not "geared mor towards an '"internal representation"' rather than something to pass between hosts in a heterogenous environment". In fact, just the opposite is true. FIPS 98 specifies the transfer syntax of messages, and does not dictate how they are to be represented within any given system. The transfer syntax is binary (as opposed to the text-based RFC 822). FIPS 98 and SMTP are not compatible because SMTP prepends (text-based) headers to messages. This does not "break" SMTP; it breaks message readers that expect to find messages that are made entirely of FIPS 98 data elements. If SMTP kept and delivered relay information seperate from the message content, there would be no problem at all. Debbie Deutsch ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041709540000> Return-Path: Received: from BBNA.ARPA by SRI-NIC.ARPA with TCP; Tue 17 Apr 84 11:56:29-PST Date: 17 Apr 1984 14:54-EST Sender: DDEUTSCH@BBNA Subject: Re: FIPS 98 From: DDEUTSCH@BBNA To: EPS@JPL-VLSI Cc: DDeutsch@BBNA, TCP-IP@SRI-NIC, SMJPM@JPL-VLSI Cc: CLYNN@BBNA Message-ID: <[BBNA]17-Apr-84 14:54:17.DDEUTSCH> In-Reply-To: The message of 17 Apr 1984 1108 PST from Eric P. Scott We had a test implementation of FIPS 98 here at BBN. I believe that Gerald Neufeld at UBC also has implemented FIPS 98. (He is reachable on CSNET.) There is no well-known port assigned to FIPS 98 messages. There are several reasons for this. First, it is not an official Internet (or ARPAnet) protocol. Second, SMTP would break FIPS 98 messages. Third, nobody has been clamoring for one. What did you mean by "a growing `non-ASCII world' where FIPS 98 is more likely to get in trouble than SMTP"? --Debbie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041714513400> Return-Path: Received: from Ucl-Cs by SRI-NIC.ARPA with TCP; Tue 17 Apr 84 05:03:56-PST Date: Tue, 17 Apr 84 13:51:34 BST From: Peter Higginson To: Jonathan Dreyer cc: "the tty of Geoffrey S. Goodfellow" , cak@purdue.arpa, Mishkin@yale.arpa, tcp-ip@sri-nic.arpa, cic@bbn-unix.arpa, obrien@rand-unix.arpa, jdreyer@bbn-unix.arpa, mimno@bbn-unix.arpa, gurwitz@bbn-unix.arpa, drockwel@bbn-unix.arpa Subject: Re: CSNet Reverse charging (and most other options) are not available internationally either Peter Higginson (plh@ucl-cs) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041806270000> Return-Path: Received: from STL-HOST1.ARPA by SRI-NIC.ARPA with TCP; Wed 18 Apr 84 10:25:57-PST Date: 18 Apr 1984 12:27-CST Sender: SNELSON@STL-HOST1 Subject: Re: Info... From: SNELSON@STL-HOST1 To: PERILLO@SRI-NIC Cc: ucscc!ucscc!emacs@UCB-VAX, tcp-ip@SRI-NIC Cc: nic-staff@SRI-NIC Message-ID: <[STL-HOST1]18-Apr-84 12:27:56.SNELSON> In-Reply-To: The message of Tue 17 Apr 84 08:39:27-PST from Francine Perillo FRANCINE: I WOULD APPRECIATE A SET. DIRECTOR USACC-ST LOUIS ATTN*CCNC-STL (S.NELSON) 4300 GOODFELLOW BLVD. ST LOUIS MO. 63120. STEVE ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041911112300> Return-Path: Received: from ddn1 by SRI-NIC.ARPA with TCP; Thu 19 Apr 84 13:32:33-PST Date: Thu, 19 Apr 84 16:11:23 EST From: dca-pgs Subject: Proteon proNET and Bell Atlantic To: tcp-ip@sri-nic, hawgs@sri-nic, telecom@mit-mc, navyusers@ddn1 Cc: dca-pgs@ddn1, allusers@ddn1 Telecommunications magazine, Apr 1984: (p. 12) "LAN VIA CPE ... Bell Atlantic is entering the emerging market for local area networks through its customer-premises equipment and system subsidiary. Bell Atlanticom Systems plans initially to market two local area networks: proNET (TM) (Proteon, Inc.) and DATAKIT (TM) (AT&T Technologies, Inc.). Letters of intent have been signed with the manufacturers, and contracts are being negotiated." Does anybody have any further details on this? My understanding of the Proteon LAN is that it is a TCP/IP ring LAN. Does anyone out there have one connected to the Arpanet or Milnet? Replies appreciated. Best, -Pat Sullivan DCA/DDN/PMO ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041912420000> Return-Path: Received: from merlin.ARPA by SRI-NIC.ARPA with TCP; Thu 19 Apr 84 14:44:19-PST From: Christopher A Kent Message-Id: <8404192242.AA16646@merlin.ARPA> Received: by merlin.ARPA; Thu, 19 Apr 84 17:42:51 est Date: 19 Apr 1984 1742-EST (Thursday) To: dca-pgs Cc: dca-pgs@ddn1.ARPA, allusers@ddn1.ARPA, tcp-ip@sri-nic.ARPA, hawgs@sri-nic.ARPA, telecom@mit-mc.ARPA, navyusers@ddn1.ARPA Subject: Re: Proteon proNET and Bell Atlantic In-Reply-To: Your message of Thu, 19 Apr 84 16:11:23 EST. <8404192217.AA04383> Yup, we have a proNET (network Purdue-CS, 128.10), and are pretty happy with it. It's a 10Mb token passing ring; the nicest thing is that hosts can enter and leave the ring without disrupting communications for the other hosts. There's a mailing list for proNET users: v2lni-people@MIT-MC. Cheers, chris ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041914260000> Return-Path: Received: from CMU-CS-A.ARPA by SRI-NIC.ARPA with TCP; Thu 19 Apr 84 16:34:00-PST Date: 19 Apr 84 1926 EST From: Rudy.Nedved@CMU-CS-A.ARPA To: dca-pgs Subject: Re: Proteon proNET and Bell Atlantic CC: tcp-ip@SRI-NIC.ARPA, hawgs@SRI-NIC.ARPA, telecom@MIT-MC.ARPA, navyusers@DDN1.ARPA, dca-pgs@DDN1.ARPA, allusers@DDN1.ARPA In-Reply-To: "dca-pgs's message of 19 Apr 84 16:11-EST" Message-Id: <19Apr84.192641.EN0C@CMU-CS-A.ARPA> I think the Proteon folks hang around MIT or used to... CMU has the stuff in its Computation Center. The stuff has different characteristics (read failures) but at least you know what the minimum transition time is....no random back offs like ethernet. -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041914290000> Return-Path: Received: from CMU-CS-A.ARPA by SRI-NIC.ARPA with TCP; Thu 19 Apr 84 16:36:17-PST Date: 19 Apr 84 1929 EST From: Rudy.Nedved@CMU-CS-A.ARPA To: Christopher A Kent Subject: Re: Proteon proNET and Bell Atlantic CC: dca-pgs , dca-pgs@ddn1.ARPA, allusers@ddn1.ARPA, tcp-ip@sri-nic.ARPA, hawgs@sri-nic.ARPA, telecom@mit-mc.ARPA, navyusers@ddn1.ARPA In-Reply-To: <8404192242.AA16646@merlin.ARPA> Message-Id: <19Apr84.192949.EN0C@CMU-CS-A.ARPA> Chris, It turns out that the connectors or whatever you call them act like repeaters...you turn off a machine that happens to be between to long pieces of cable and things get worst....the current trick is to turn on power to the board but disable the rest of the machine. No perfect solutions in a hostile non-homogenous enviroments that tends to cheat on specifications because everything is on backorder. -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041916340800> Return-Path: Received: from bbnccq by SRI-NIC.ARPA with TCP; Thu 19 Apr 84 18:42:17-PST Date: Thu, 19 Apr 84 21:34:08 EST From: Bob Hinden Subject: Re: Proteon proNET and Bell Atlantic In-Reply-To: Your message of Thu, 19 Apr 84 16:11:23 EST To: dca-pgs Cc: tcp-ip@sri-nic, hawgs@sri-nic, telecom@mit-mc, navyusers@ddn1, allusers@ddn1, hinden@BBN-UNIX We have gateways to Proteon ring nets at several sites: U. of Wisc, Purdue U., Aerospace Corp., and NTARE. They run at 10Mbits and seem to work well. One major advantage they have over Ethernets is that they can run over a variety of media, ranging from twisted pairs to fiber optics. Bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984041923533800> Return-Path: Received: from aerospace.ARPA by SRI-NIC.ARPA with TCP; Fri 20 Apr 84 07:56:28-PST Date: Fri, 20 Apr 84 07:53:38 PST From: Lou Nelson To: dca-pgs CC: tcp-ip@sri-nic, allusers@ddn1, gal, sills, crocker Subject: Proteon proNET and Bell Atlantic In-reply-to: Your message of Thu, 19 Apr 84 16:11:23 EST >> Received: from ddn1 by SRI-NIC.ARPA with TCP; Thu 19 Apr 84 13:32:33-PST >> Date: Thu, 19 Apr 84 16:11:23 EST >> From: dca-pgs >> Subject: Proteon proNET and Bell Atlantic >> To: tcp-ip@sri-nic, hawgs@sri-nic, telecom@mit-mc, navyusers@ddn1 >> Cc: dca-pgs@ddn1, allusers@ddn1 >> >> ...Does anybody have any further details on this? My understanding of the >> Proteon LAN is that it is a TCP/IP ring LAN. Does anyone out there have >> one connected to the Arpanet or Milnet? Replies appreciated. >> >> Best, >> -Pat Sullivan >> DCA/DDN/PMO As Bob Hinden said, we here at Aerospace have had a Proteon proNET in operation for about a year. In that time it has grown to be the most complex mix of transmission media in a single net that Proteon knows about. Two buildings are connected to a third via fiber optics and that third building is connected to a fourth via twinax wire and also to a fifth building via coax. Currently we have three wire centers with more on the way and have 4 VAXes and 1 PDP-11/23 Prime Gateway to the MILNET attached to the proNET backbone. We are now about to bring two intra-building Ethernets into operation that will be connected to the backbone via PDP-11/23 gateways, one of which will be our Prime Gateway functioning with 3 "legs". The whole hierarchical structure is known as the Aeronet. For more technical details and a possibly colorful account of our experiences in getting this all up, please ask Lou Gallenson (gal@aerospace). Regards, Lou ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984042319111100> Return-Path: Received: from Xerox.ARPA by SRI-NIC.ARPA with TCP; Tue 24 Apr 84 03:13:23-PST Received: from Semillon.ms by ArpaGateway.ms ; 24 APR 84 03:12:49 PST Date: 24 Apr 84 03:11:11 PST From: Murray.pa@XEROX.ARPA Subject: Re: Proteon proNET => "no random back offs like ethernet" In-reply-to: <19Apr84.192641.EN0C@CMU-CS-A.ARPA> To: Rudy.Nedved@CMU-CS-A.ARPA Cc: dca-pgs , tcp-ip@SRI-NIC.ARPA, telecom@MIT-MC.ARPA Have you ever worked with a network where you would notice the randomness introduced by the backoff time? There is a critical engineering concept that isn't mentioned in the ethernet specs. If you expect your ethernet to have an AVERAGE throughput of anywhere near 10 megabits/sec, you are asking for trouble. If you set things up so that the normal peak load (as averaged over a few seconds) is below 3 to 5 megabits/sec, then collisions are rare enough so that they can almost be neglected. There is a lot of screaming and shouting going around about rings vs etherents. I think most of it is pure religion. From what I've seen, the critical step is not the high level architecture, but rather how carefully the small details are handled. Your next message ("you turn off a machine that happens to be between two long pieces of cable and things get worse") is a good example. We had another example out here a few years ago. We have an ethernet under the street to another building. Lightning hit the hill out back. It zapped a handful of transcievers. Unfortunately, they died shorted, so the whole net was dead. A 100 ohm resistor in the right place is all it takes to make a transciever immune to problems like this. The way I look at things, it doesn't make much difference how the packets get from my machine to the next one as long as they get through reasonably reliably. The details of the actual transport mechanisim are all contained within one module for each specific type of hardware. Some problems are easier if the hardware supports broadcasting, but there are usually ways to fake it somehow if you can't do that. The interesting question is what protocols will Bell Atlantic, or any other part of the established "phone" system support on high bandwidth LANs? Can you picture them using IP/TCP? At least they would solve the naming/addressing problems - just send my mail to 415-494-4452. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984042422120000> Return-Path: Received: from CMU-CS-A.ARPA by SRI-NIC.ARPA with TCP; Wed 25 Apr 84 00:34:42-PST Date: 25 Apr 84 0312 EST From: Rudy.Nedved@CMU-CS-A.ARPA To: Murray.pa@XEROX.ARPA Subject: Re: Proteon proNET => "no random back offs like ethernet" CC: dca-pgs , tcp-ip@SRI-NIC.ARPA, telecom@MIT-MC.ARPA In-Reply-To: "Murray.pa@XEROX.ARPA's message of 24 Apr 84 06:11-EST" Message-Id: <25Apr84.031236.EN0C@CMU-CS-A.ARPA> Gee. Let's see: 1) I don't care about which is better. CMU has got token rings, RS232 lines, ethernet (3MB and 10MB) and a bunch of other "networking" technology. The point about "random back-off" was based on how the product was being presented. I know what is going on and understand the issues but I am not out there buying the now-famous "LAN" hardware and I am not selling it....How the ethernet people "fight back" when they sell the stuff is not my problem...only time will tell and how well the people that put the systems together get things working. Remeber that IBM does alot of "customer service" after their products are installed. This is what makes "winning technology"....how well it works for the guy on the street who tells his next friend over...[or how well it works for company A's EDP director who meets a friend at a conference and talks to company B's EDP director...] 2) I don't expect the phone company to mix digital data and voice data over the same piece of hardware. Of what I know from what I hear from the people doing network phones at Xerox...it is a bad move...too much data and gateway contention problems. The current Xerox system uses a seperate 1MB cable for the voice stuff...because the ethernet chip was available. I suspect in the long run that the telephone company will have a non-NS, non-IBM, non-TCP/IP and definitely BELL protocol that runs on some much faster network system. The current LANs don't cut it but then I am not familiar with "ESS 5" to know if the "long run" started a few years ago. 3) I live in a high turn over "college" area...My two phones in my house get an average of one "wrong number" a day for each phone...real irritating when I sleep during the day...I would really dislike sending mail to a phone number address....I wouldn't want to encourage the use by my friends. The way to go is still what the postal system does... except bring back the old postman who knows who you are and can figure out mail to "Ed Nesbed" is probably for me.... -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984042604030000> Return-Path: Received: from su-shasta.arpa by SRI-NIC.ARPA with TCP; Thu 26 Apr 84 12:19:32-PST Received: from imagen by Shasta with UUCP; Thu, 26 Apr 84 12:16 PST Date: Thursday, 26 Apr 1984 12:03-PST To: shasta!en0c@cmu-cs-a.arpa, shasta!Rudy.Nedved@CMU-CS-A.ARPA Cc: shasta!Murray.pa@XEROX.ARPA, shasta!dca-pgs@DDN1.ARPA, shasta!tcp-ip@SRI-NIC.ARPA, shasta!telecom@MIT-MC.ARPA Reply-To: imagen!geof@shasta Phone: (415) 960-0714 (work) Postal-Address: IMAGEN, 2660 Marine Way, Mountain View, CA 94043 Subject: Re: Proteon proNET From: imagen!geof@su-shasta.arpa The Proteon ringnet, whose product name is PRONET (with suitable capitalization) was developed in conjunction with members of the Computer Systems Research Group at MIT's Lab for Computer Science. MIT's involvement was funded by DARPA as I understand it. The ring has been refered to in some MIT documents the ``V.2 LNI'' or ``Version 2 Ring'' (don't ask about the version 1 ring). It is a forrunner of the Zurich Ringnet, which (rumour has it) is being turned into IBM's LAN product for SNA. PRONET, like Ethernet, is a link-level transport mechanism. It can accomodate any number (i.e., 2**8 or 2**16 I think) of different higher level protocols. Thus its description as a `TCP-IP ring' is incorrect. The ring runs as 10Mb/s. It uses a token contention scheme. There is no ring master; instead all stations in the ring cooperate to replace the token if it is lost. In this way, it is possible to add and remove hosts from the ring without disrupting existing communications. An important part of the pronet scheme is that it is a so-called `star-shaped ring'. All stations connect to the ring via a passive wire center which splices stations that are powered on into the ring. Thus, `pulling the plug' on a host (either the electrical plug or the network plug) will not destroy the ring (it will probably cause it to reinitialize). I have pulled out hosts' connectors while telnet and FTP connections were running over that host and other hosts. No one noticed; the higher level protocols simply retransmitted any lost packets. I have heard that IBM's ringnet is also star shaped. I have worked with a non-star shaped ring and it is annoying. - Geof Cooper Imagen ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984042708413300> Return-Path: Received: from ddn1 by SRI-NIC.ARPA with TCP; Fri 27 Apr 84 10:54:28-PST Date: Fri, 27 Apr 84 13:41:33 EST From: dca-pgs Subject: Sun Workstation; Who's Got Them On Arpanet or Milnet? To: sun.user!sun@berkeley Cc: dca-pgs@ddn1, hawgs@sri-nic, navyusers@ddn1, tcp-ip@sri-nic Dear Sun Microsystems: Can you give me a list of Sun users who are on Arpanet or Milnet? If this list reaches any Sun users, also request that you sound off. Is there an on-line Sun newsletter/digest anywhere? Thank you, Pat Sullivan DCA/DDN/PMO ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1984043010004300> Return-Path: Received: from ddn2 by SRI-NIC.ARPA with TCP; Mon 30 Apr 84 11:09:15-PDT Date: 30 Apr 84 14:00:43 EDT From: nrdcnola @ DDN2 Subject: tcp/ip for micros To: allusers @ DDN2, allusers @ ddn1, tcp-ip @ sri-nic, info-ibmpc @ usc-isib CC: nrdcnola @ DDN2, murray @ ddn1  we have seen numerous references made to tcp/ip implementations for microcomputers in mailbox correspondence over the past several months. we're requesting information from any users that have implemented tcp/ip (and ftp if available) on micros that may help us locate sources for our own implementation. specifically, we're interested in a package to operate on a 16-bit micro under ms-dos (or compatible) for connection to ddn and need the answers to such questions as: 1. what interfacing strategies have been used (i.e. ethernet, x.25, 1822, etc.)? 2. manufacturer and model of micro 3. who provides tcp/ip, ftp, x.25, etc., software and/or associated hardware? 4. who provides support for the software? 5. what is the cost? 6. in what language is it written? any such information or points-of-contact that could be provided would be greatly appreciated. point of contact: nrdcnola at ddn2 lt p. l. richardson -or- mr alan david autovon 363-5730/5727 fts 686-5730/5727 comm 504-948-5730/5727 ----MESSAGE-END----