|
|
ARCHIVE: TCP-IP Distribution List - Archives (1984)
DOCUMENT: TCP-IP Distribution List for October 1984 (126 messages, 55426 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1984/10.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: Mon, 1 Oct 84 08:35:06 pdt From: mtxinu!excelan!jay@Berkeley (jay israel) To: mtxinu!ucbvax!"aronson@nlm-mcs"@Berkeley, mtxinu!ucbvax!"dpk@BRL-TGR"@Berkeley, mtxinu!ucbvax!"lamas@brl"@Berkeley, mtxinu!ucbvax!"mo@seismo"@Berkeley, mtxinu!ucbvax!"postel@USC-ISIF"@Berkeley Cc: avnish@Berkeley, billn@Berkeley, george@Berkeley, jay@Berkeley Subject: Re: Excelan ip/tcp
There is an update imminent of both the software and the documentation. Among the changes is support for all classes of networks. For details, please contact George Powers or me at (408) 945-9526. If you know of others who may need this information, or to whom you have mentioned this issue, please convey this reply. Thanks for your interest, Jay.
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Mon Oct 1 12:09:43 1984 From: Martin Lee Schoffstall <cadtroy!schoff@seismo.ARPA> To: cadmus!seismo!tcp-ip@nic.ARPA Subject: excelan boards
The current version of the firmware available to OEM's (Cadmus,Masscomp, Silicon Graphics...) only supports class A networks. In November they are going to release new firmware which will support arbitrary network numbers. marty
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 84 03:57:16 PDT From: Murray.pa@XEROX.ARPA To: Doug Kingston <dpk@BRL-TGR.ARPA> Cc: tcp-ip@SRI-NIC.ARPA, mo@SEISMO.ARPA Subject: Re: [Jules P. Aronson: excelan tcp/ip boards]
That's just the tip of the iceberg. Ethernets use 48 bit host numbers. The number czar assigns a 23 bit number to each manfacturer. They get to pick the other 24. (The last one is used for multicast.) Consider what happens if another company uses the same approach, and you are trying to run a mixture of boards on the same ethernet. If you are unlucky, you end up with 2 machines using the same IP host number. You might think that getting a collision when picking 2 24 bit numbers would be quite rare, but both manfacturers are probably assigning them sequentially, and remember the number of people at a party that it takes to get two with the same birthday... We have a similar problem when running Pups (8 bit host numbers) on our Ethernets. We couldn't come up with any good way to do it. Our current implementation uses a centrally maintained table and an NS based protocol to talk to a server. We thought about fancier schemes that would avoid the manual editing of the table, but that would require several severs to keep cooridinated and there isn't any reasonable way to determine that a machine is really dead (so you can recycle it's host number) as compared to just quiet for some good reason (it's owner is on vacation). Anybody have any good ideas?
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 84 03:05:38 EDT From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: packet size constraints
I seem to recall discussion on this point sometime in the dim past, but I can't come up with it. Can somebody refresh me on the situations in which it is legal to use packets larger than 576 bytes? We are using a DEC-20 as a gateway. It can handle packets of size 1004 on the Arpanet side and 972 on the Ethernet side. Apparently there is no way we are going to get the 20 to accept packets above 1004 on the Ethernet side without massive recoding. This causes problems when two Unix systems talk to each other through our gateway. Unix likes to use 1500-byte packets on the Ethernet. A 4.2 system on my Ethernet is talking to one at SRI on their Ethernet. Apparently the two TCP's determine that they can both handle 1500-byte packets, and use that as their packet-size. Unfortunately, packets do not make it through my gateway. Somebody is violating a rule someplace. Is it - Unix, because before using 1500-byte packets they have to make sure that not only both hosts, but also all intervening gateways can handle them or - Tops-20, because any gateway should be able to accept the largest size packet supported by its physical medium Obviously this answer doesn't much matter to me. Since I can't fix Tops-20, I will have to patch Unix so it doesn't send large packets, no matter what the answer is. But if the conclusion is that Unix is wrong, I will recommend to Pyramid that they modify the TCP code to use 576-byte packets. If the conclusion is that Tops-20 is wrong, I will simply keep this as a local hack. -------
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 1984 07:48:57 PDT From: POSTEL@USC-ISIF.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: re: datagram size constraints
A gateway must be able to accept the maximum datagram that can be transmitted on the physical networks it is attached to. --jon. -------
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 1984 08:05:33 PDT From: POSTEL@USC-ISIF.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: re: ARP is what you need
Well, i think that the "ARP is what you need" comments miss the point. The problem is how to assign a pair (Ethernet, IP) addresses to a host in the first place. I don't think there is any good answer for that. At ISI, we keep a list. We have a local number czar. When some new machine shows up the owner of the machine goes to the number czar and gets a new IP address (within the ISI-NET), and the number czar makes some notes about the new machine (including both the IP address and the Ethernet address). Once the assignment is made the new host can be taught its IP address, and knows from the hardware its Ethernet address. Only after all this can it play ARP. ARP is a great way to dynamically map IP addreses to Ethernet addresses using a distributed table lookup. The table is so distributed that each host hold only one enrty of the table -- its own. But don't kid yourself - the table exists and somebody has to make sure it is consistent. --jon. -------
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Tue 2 Oct 84 07:44:36-EDT From: J. Noel Chiappa <JNC%MIT-XX@MIT-XX> To: Murray.pa%XEROX@MIT-XX, dpk%BRL-TGR@MIT-XX Cc: tcp-ip%SRI-NIC@MIT-XX, mo%SEISMO@MIT-XX, JNC%MIT-XX@MIT-XX Subject: Re: [Jules P. Aronson: excelan tcp/ip boards]
Use the ARP protocol (RFC 826) which does just the right thing. It's the current standard for translation of hardware addresses to protocol addresses for nets for which there is no simple mapping. -------
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Tue 2 Oct 84 09:53:53-EDT From: Kevin Paetzold <PAETZOLD@DEC-MARLBORO.ARPA> To: Murray.pa@XEROX.ARPA Cc: dpk@BRL-TGR.ARPA, tcp-ip@SRI-NIC.ARPA, mo@SEISMO.ARPA Subject: Re: [Jules P. Aronson: excelan tcp/ip boards]
ARP is exactly what you want. One of the side effects using ARP for IP was quite beneficial to TOPS-20 and you may all find it amusing. DECNET had the same problem as as IP. The address mapping for DECNET is much smaller than the address mapping for Ethernet. The "solution" was to make all DEC Ethernet hardware have the ability to change its address. When DECNET starts up it changes the Ethernet interfaces address to be some magic number or or'ed with the decnet node number. We expected this to cause a pretty bad problem for the IP code which was allready happilly talking on the Ethernet and allready knew its address (as did all the hosts it was talking to). There are several solutions to this problem. One solution is to not start talking until DECNET sets the address to what it wants. Another solution is to broadcast an ARP packet with our new address when the address changes. This actually does work. We do not have to determine what we are going to do for a few months yet as DECNET and IP will not coexist on the same Ethernet in the same monitor until 6.1 of TOPS-20 (because 5.4 does not support DECNET on the Ethernet). -------
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 2 October 1984 10:10-EDT From: David C. Plummer <DCP @ MIT-MC> To: PAETZOLD @ DEC-MARLBORO Cc: mo @ SEISMO, tcp-ip @ SRI-NIC, Murray.pa @ XEROX, dpk @ BRL-TGR Subject: Re: [Jules P. Aronson: excelan tcp/ip boards]
Date: Tue 2 Oct 84 09:53:53-EDT
From: Kevin Paetzold <PAETZOLD@DEC-MARLBORO.ARPA>
There are several solutions to this problem. One solution is to not
start talking until DECNET sets the address to what it wants. Another
solution is to broadcast an ARP packet with our new address when the
address changes. This actually does work.
Right, but this is just a bit non-deterministic. You should also
flush your tranlation tables so you take translation faults
whenever the -20 tries to send packets again..
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 1984 1126-EST (Tuesday) From: Christopher A Kent <cak@Purdue.ARPA> To: POSTEL@USC-ISIF.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: re: datagram size constraints
Date: 2 Oct 1984 07:48:57 PDT From: POSTEL@USC-ISIF.ARPA Subject: re: datagram size constraints A gateway must be able to accept the maximum datagram that can be transmitted on the physical networks it is attached to. --jon. ------- Note that this maximum is not necessarily the maximum physical limit -- it can be an administrative limit. For example, in your case, it sounds like the limit should be 904 on all machines, since your TOPS-20 machine can't handle anything bigger than that. We have a proNET ring, with a physical maximum packet size of 2044 octets, but the largest packet sent, by administrative decree, is 1600 octets. Everyone agrees to this, including the gateway, and everything is happy. For a while, the gateway ran a different MTU, and things broke a lot. If the TCP clients that go through your gateway are doing the right thing with maximum segment size options, and it sounds like they're at least trying, your side should tell its peers not to send any TCP segments that will push datagrams >904 octets at your gateway, so everything should work. Cheers, chris ----------
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 1984 14:17-PDT From: WESTINE@USC-ISIF.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: Packet Size Constraints
RFC-879 discusses the TCP maximum segment option. --jon.
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: Tue 2 Oct 84 11:43:24-EDT From: Kevin Paetzold <PAETZOLD@DEC-MARLBORO.ARPA> To: DCP@MIT-MC.ARPA Cc: mo@SEISMO.ARPA, tcp-ip@SRI-NIC.ARPA, Murray.pa@XEROX.ARPA, dpk@BRL-TGR.ARPA Subject: Re: [Jules P. Aronson: excelan tcp/ip boards]
we flush the table when the address changes. -------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Tue 2 Oct 84 11:52:01-EDT From: Kevin Paetzold <PAETZOLD@DEC-MARLBORO.ARPA> To: POSTEL@USC-ISIF.ARPA Cc: tcp-ip@SRI-NIC.ARPA, hedrick@RUTGERS.ARPA Subject: re: datagram size constraints
After thinking about the tops20 tcp/ip code and the maximum datagram size I have thought of a way I can get this to work. However it will not happen for a few months. For now the maximum datagram size of 1004 is a restriction in the TOPS-20 tcp. -------
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Oct 84 12:51:57 EDT From: Gary Delp <delp@udel-ee> To: Charles Hedrick <HEDRICK@rutgers.arpa> Cc: tcp-ip@sri-nic Subject: Re: packet size constraints
Charles, The option negotiation at the beginning of the tcp setup lets each host adversise the maximum size packet that they are willing to except. If no such advertisement takes place, the default is the minimum size (circa 570 bytes). Note that only the endpoints enter into this negotiation. IP, which handles the intermediate stuff never negotiates end point to endpoint, it just knows what each network it gateways to can handle. The IP which does the gatewaying (the DEC20 machine) is responsible for fragmenting the packets as needed to transmit them on the networks it uses to forward the packets. Each recieving host must then do IP packet reassembly. If hosts chose not to do reassembly, they can throw packets away, advertize small TCP windows, and set the dont't fragment flag on the IP packets they send, but this is a work around possibly more difficult that implementing fragment reassembly. And certainlly not in the spirit of IP. David Clark has a very nicely worded rfc about reassembly which should be a help if that is the problem. (rfc 815). -Gary Delp <delp@udel-ee.arpa>
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 1984 1646-EST (Tuesday) From: Christopher A Kent <cak@Purdue.ARPA> To: Ron Natalie <ron@BRL-TGR.ARPA> Cc: POSTEL@USC-ISIF.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: datagram size constraints
Date: Tue, 2 Oct 84 16:09:36 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> Subject: Re: datagram size constraints TCP? IP! Regardless of what the TCP does, the IP should not send packets larger than the network maximum transfer limit. It is IP's job to fragment the packets to fit the network. -Ron Yes, right, of course. But the TCPs should also try to pick Max Seg sizes to avoid IP fragmentation of TCP segments (although that's a different story). chris ----------
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 1984 1705-EST (Tuesday) From: Christopher A Kent <cak@Purdue.ARPA> To: Charles Hedrick <HEDRICK@RUTGERS.ARPA> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: datagram size constraints
Yes, but how can IP know the maximum packet size for the network. Everyone on the network must agree to a MTU (that is, the owners of the machines!) and set it with whatever black magic is required for their host. It's not intended that you figure it out on the fly. That means hardcoding into the kernel on a Unix system (or patching with adb, but that doesn't always work), or changing the Tops-20 configuration parameter. If you have a box that doesn't let you change it, you're out of luck unless you can get everyone else to use that box's idea of the MTU... chris ----------
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Oct 84 16:09:36 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: Christopher A Kent <cak@PURDUE.ARPA> Cc: POSTEL@USC-ISIF.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: datagram size constraints
TCP? IP! Regardless of what the TCP does, the IP should not send packets larger than the network maximum transfer limit. It is IP's job to fragment the packets to fit the network. -Ron
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 84 17:59:03 EDT From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> To: ron@BRL-TGR.ARPA Cc: cak@PURDUE.ARPA, POSTEL@USC-ISIF.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: datagram size constraints
Yes, but how can IP know the maximum packet size for the network. As far as I can see, either the OS lets you specify the packet size for each interface as a configuration parameter (Tops-20) or they hardcode it into the kernel (Unix). I don't see any way that a machine can detemine the MTU for a given network by asking somebody. -------
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Tue, 2 Oct 84 19:33:56 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: Charles Hedrick <HEDRICK@RUTGERS.ARPA> Cc: ron@BRL-TGR.ARPA, cak@PURDUE.ARPA, POSTEL@USC-ISIF.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: datagram size constraints
You are right. You have to know. -Ron
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 84 08:41:11 EDT From: dca-pgs @ DDN1.ARPA To: tcp-ip @ sri-nic.arpa Cc: info-unix @ brl.arpa Subject: DDN Host Interface Contract Awards
Comment:
Forwarded message(s):
-----------------------------------------------------
To: ddn-pmo @ DDN1
From: jmallory @ DDN1
Subject: Host Interface Contract Awards
Date: 2 Oct 84 13:10:19 EDT
cc: jmallory @ DDN1
Text:
The following contracts have been awarded for DDN host interfaces:
COMPANY HOST FAMILY
1. Network Solutions IBM 370 MVS
2. CDC CDC CYBER 170 NOS
3. HIS HIS Level 6 GCOS 6 MOD 400
4. Gould Software Division DEC VAX 11 VAX/VMS
5. Internet Systems Corp. SPERRY 1100
Contracts are in process for the following host families:
1. HIS DPS8 GCOS8
2. IBM 370 VM
3. DEC PDP 11 RSX-11M
Awards are expected shortly for the first two families. The third one will
delayed until after Dec 15th due to the availability of funds.
The information in this message is not restricted and may be disseminated
to the world.
June
-------------END OF FORWARDED MESSAGE(S)-------------
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 1984 14:19-EDT From: CLYNN@BBNA To: HEDRICK@RUTGERS Cc: tcp-ip@SRI-NIC, CLynn@BBNA Subject: Re: packet size constraints
Charles, Don't engage in any massive recoding for packets larger than 1004 octets. Such code is currently running at BBN, and was given to DEC last May, but they haven't yet had a chance to put it in a system release. A more recent version has (at least half) of the code required for option sub-negotiations, which MARANTZ@RUTGERS was inquiring about a couple weeks ago. It is a bit discouraging to see people reporting problems which were solved a long time ago but just haven't made it through the system. ARPA's goal is to transfer the BBN code and TOPS20 TCP support to DEC. We are concluding our work on TOPS20 TCP this October and expect that DEC will include the BBN code in a future TOPS20 release. Charlie
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 1984 08:49-PDT From: Dan <LYNCH@ISIB> To: CLYNN@BBNA.ARPA Cc: HEDRICK@RUTGERS.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: packet size constraints
Charlie and Charles, Let me be a bit more direct about what Charlie said in his last message: ARPA is going to depend on DEc for future TCP/IP support in TOPS20. The work has never been "trivial". I am not intimately familiar with what is going on inside DEC with regards to this matter, but I can suggest that each site independantly apply pressure towards DEC to get the appropriate amount of resources applied internally to get TCP/IP supported in an accurate and timely manner. How each site applies that pressure is alocal matter (use the best pressure point you know of), but it is imperative that you let DEC know how important this matter is or they will attend to the louder squeeky wheel. Dan
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 1984 9:21:13 EDT (Thursday) From: walt lazear <lazear@mitre> To: tcp-ip at nic Cc: lazear@mitre Subject: Add to list
Please add 'lazear at mitre' to the tcp-ip list. Thanks in advance.
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Thursday, 4 Oct 1984 13:23-PDT From: imagen!geof@su-shasta.arpa To: shasta!tcp-ip@SRI-NIC, shasta!HEDRICK@RUTGERS.ARPA Cc: geof@su-shasta.arpa Subject: Re: packet size constraints
I got a strange view of your question, since my mailer managed to reverse the order of the question and the many responses that have been pouring in. I agree with what Jon Postel says (that a gateway is required to accept the maximum sized packet on a network). I don't think that is the end of the story. When you say that the tops-20 code handles 972-byte packets on your ethernet, and that you can't practically fix it, what you are REALLY saying (applying Jon's logic) is that YOUR Ethernet only supports 972-byte packets. There are two constraints that limit the size of internet datagrams that can be sent on a network: - the maximum length packet the hardware supports - the maximum length packet essential service machines can handle In most cases the first constraint is the more significant; in yours the second is. The bug with this is that two hosts on your Ethernet can't figure out that they can communicate with 1500-byte packets. That is a better bug (in my opinion) than randomly failing when using the gateway. Implementations of the Internet protocol should have an easily reconfigurable maximum packet size for the network. A source license should not be necessary to change the maximum packet size, unless a source license accompanies every copy of the binaries (as is not the case, for example, with 4.2 unix). Are you listening, fellow TCP vendors? A hack that recognises when you are using the gateway and warned the local TCP to do the ``right thing'' would probably work better than the above. On the other hand, that above is consistent within the limitations of current TCP-IP specs (I hope). - Geof Cooper Imagen
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Thursday, 4 Oct 1984 15:00-PDT From: imagen!geof@su-shasta.arpa To: shasta!tcp-ip@sri-nic Cc: geof@su-shasta.arpa Subject: Crufty mailer behavior
We have been getting quite a few messages like this one: From: su-shas!tcp-ip-relay@sri-nic Received: from sri-nic.arpa by su-shasta.arpa with TCP; Tue Oct 2 14:49:34 1984 Sender: tcp-ip-relay@sri-nic Date: Tuesday, 2 Oct 1984 14:52-??? DATA DATA DATA DATA DATA <925 lines containing DATA deleted due to lack of interest-ed> DATA DATA DATA DATA DATA Received: from BRL-TGR by SRI-NIC.ARPA with TCP; Tue 2 Oct 84 13:34:06-PDT Date: Tue, 2 Oct 84 16:09:36 EDT < rest of message is normal > It appears that something is amiss in the SMTP connection from the NIC. Theory of a Bug: NIC sends DATA to shasta during SMTP Shasta sends response only after long delay. Meanwhile, NIC retransmits(??) the DATA statement many times, the extra data statements are correctly interpreted as part of the message. If this is what is going on, then there is a bug in the NIC's code. Has anyone else been seeing similar problems? - Geof Cooper IMAGEN
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Thu 4 Oct 84 13:08:10-EDT From: Kevin Paetzold <PAETZOLD@DEC-MARLBORO.ARPA> To: CLYNN@BBNA.ARPA Cc: HEDRICK@RUTGERS.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: packet size constraints
Well, lets get the story straight. We (TOPS-20 Monitor group) met with BBN early this year (or late last year) about the code in question from BBN. At that time we talked about the schedules that TOPS-20 had at that point and informed BBN that we needed to have the code from them by sometime in February to meet release 6 schedules. We did not get the code in time for release 6. It was at least 4 months late for release 6. It will not be in release 6. We have not been sitting on our hands however. We went ahead and implemented the DEC KLNI ethernet hardware, driver, and IP interface. Also cleaned up lots of stuff in TCP/IP in general. I have not had a chance to even look at the BBN changes yet. I was not aware that it even supported larger messages. It is not clear that I will get the chance to merge this stuff before the release 6.1 schedule shuts me out. There is a little bit more to TOPS-20 than the TCP/IP code. -------
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Thu 4 Oct 84 13:13:32-EDT From: Kevin Paetzold <PAETZOLD@DEC-MARLBORO.ARPA> To: LYNCH@USC-ISIB.ARPA Cc: CLYNN@BBNA.ARPA, HEDRICK@RUTGERS.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: packet size constraints
Applying pressure is a two way street. Unfortunately when we apply pressure at this end it is ignored. The schedules that DEC has for this product are even not considered when external organizations want to get changes made to the product. -------
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Thu 4 Oct 84 18:28:50-PDT From: Mark Crispin <MRC@SU-SCORE.ARPA> To: imagen!geof@SU-SHASTA.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: Crufty mailer behavior
What gives you the idea that the bug is necessarily at the NIC?
There is at least one other agent, SU-Shasta, which could be the cause
of the problem. I don't know what modifications the NIC may have in
their copy of the TOPS-20 mailsystem but certainly the mailsystem as
distributed by me doesn't have that bug!
-------
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Thu, 4 Oct 84 19:42 EDT From: "David C. Plummer" <DCP@SCRC-STONY-BROOK.ARPA> To: "tcp-ip@SRI-NIC"@MIT-MC.ARPA Subject: information in RESET segments
Does anybody check to see if the length of a segment that has the RESET bit is 0? What are the consequences if I put textual data (a "reason") in the RESET segment and had a non-zero length field. I would like to add this to the spec. I believe it is upward (backward?, I can never get them straight) compatible. Rationale: we have systems that will refuse connections for a variety of reasons, and we have to guess what the reasons are when we use TCP. Also, there are several places in the spec that say "Send a RESET." Many are for different reasons, so if there is a protocol violation it would be nice to know what it was. Paranoid, secure, etc., systems need not fill it in; this is optional.
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Oct 84 00:17 EDT From: Mike StJohns <StJohns@MIT-MULTICS.ARPA> To: tcp-ip@SRI-NIC.ARPA Cc: dcp@SCRC-STONY-BROOK.ARPA Subject: Re: information in RESET segments
My copy of the mil-std version of tcp reveals that the length of the segment never gets considered if the reset bit is on. In most cases, the only action taken is to throw away the reset. Textual data? Wouldn't a better way be to define a "standard" set of RESET errors ids (one byte long) and just return the ID? The system receiving the RESET would have a better idea of what went wrong, and it would be easier for non-interactive users to react to the RESET condition. Keep in mind though, a modification to TCP at this level will probably require modifications in the TCP/upper level protocol interface to allow the reset code to pass upwards. Mike StJohns
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: 5 October 1984 11:11-EDT From: David C. Plummer <DCP @ MIT-MC> To: StJohns @ MIT-MULTICS Cc: tcp-ip @ SRI-NIC, dcp @ SCRC-STONY-BROOK Subject: Re: information in RESET segments
Date: Fri, 5 Oct 84 00:17 EDT
From: Mike StJohns <StJohns@MIT-MULTICS.ARPA>
My copy of the mil-std version of tcp reveals that the length of the
segment never gets considered if the reset bit is on. In most cases,
the only action taken is to throw away the reset.
Right.
Textual data? Wouldn't a better way be to define a "standard" set of
RESET errors ids (one byte long) and just return the ID? The system
receiving the RESET would have a better idea of what went wrong, and it
would be easier for non-interactive users to react to the RESET
condition.
Yes, damnit, textual data. Why can't we have some human readable
things? Does everybody out there work for IBM and memorize error
codes. Textual data allows arbitrary reasons to be presented to
USERS. If you read what I proposed, I said "we have to guess."
I didn't say "the implementation has to guess." Let this be a
warning to people out there that I consider bit packing for
things to be presented to users to be a completely assinine
concept and has no place in user interfaces. It is not
extensible ("Gee, we need a new error code that means X"), it
doesn't allow superfluous USEFUL information ("RESET because you
sent data after sending a FIN"), etc. It is also possible for
application programs to supply an infinite variety of abnormal
close reasons. Those familiar with the LispM flavor system may
be familiar with the :CLOSE message to streams. Well, there is
also a :CLOSE-WITH-REASON message, which in the case of TCP makes
the reason go into a black hole.
It pains me TCP didn't adopt a textual contact name (like the
Chaos protocol does) but instead stuck with NCP port numbers. It
is so much simpler to prototype protocols
"RESET-ADDRESS-RESOLUTION-CACHE" than it is to use an
experimental number and then propose it as an RFC and then get a
bona fide port number from the PORT CZAR and then go in and
change all the code and then reboot every system. Come off it,
get out of the dark ages! <Flame off>
Summary: I will not accept anything but textual data as the
extension to RESET.
Keep in mind though, a modification to TCP at this level will probably
require modifications in the TCP/upper level protocol interface to allow
the reset code to pass upwards.
This is COMPLETELY upward compatible. Consider all four cases:
* old ->RESET-> old
Same as now
* new ->RESET-> old
Same as now (since old receiver throws it away)
* old ->RESET-> new
new receiver notices the RESET is empty and supplies its
own reason of "No reason was given."
* new ->RESET-> new
new receiver retains reason and gives it to the user.
The (Lisp Machine) network environment I work on normally use the
Chaos protocol, which does convey reasons (there are probably 2
dozen reasons, and each (non-LispM included) operating system has
its own little (valid) variants). When we implemented TCP for
the LispM, it was always a sore point that we couldn't get any
useful information out of the other end, and had to turn off TCP
(TCP is a bit more efficient because it can use thrice as large
packets (on the Ethernet) as the chaos protocol) in order to try
again and find out THE REAL REASON the connection was refused or
dropped.
Executive summary: I think this is upward compatible, optional,
and useful. I think it should be adopted. If somebody doesn't
think it is upward compatible, give me a proof.
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Oct 84 12:13:25 EDT From: Gary Delp <delp@udel-ee> To: Mike StJohns <StJohns@mit-multics.arpa> Cc: tcp-ip@SRI-NIC.ARPA, dcp@SCRC-STONY-BROOK.ARPA Subject: Re: information in RESET segments
The idea of one byte codes for the RESET REASON in rejected tcp segments sound like a good one, although it could be extended the way (for instance) SMTP works. Use clear text for the number of the error followed by implementation dependent text giving more information. (if appropriate ). I am about to start debuging a TCP writen in Ada, running on the intel 432/670/330 system. Having some clues available for the debugging may well be helpful. Is someone going to pursue this idea? -Gary Delp <delp@udel-ee>
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 84 1412 EDT (Friday) From: don.provan@CMU-CS-A.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: maximum packet size
I hate to be obvious, but has anyone ever thought of adding an IP option like the timestamp option where each machine along the route fills in the maximum IP packet size it can handle for that route? We've talked and argued about the TCP packet size problem, but I don't remember anyone suggesting this. It seems like a straightforward solution to all of these problems.
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: Fri 5 Oct 84 14:38:35-EDT From: Mark K. Lottor <MKL@MIT-XX.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: SFTP
I would like to hear from anyone that is interested in working on experimental SFTP implementations and discussing problems and modifications to the protocol. I have an almost complete SFTP server running on TOPS-20 but no user process yet. Please reply to me if you are interested. Mark -------
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: Fri, 5 Oct 84 16:12 EDT From: Mike StJohns <StJohns@MIT-MULTICS.ARPA> To: "David C. Plummer" <DCP@MIT-MC.ARPA> Cc: tcp-ip@SRI-NIC.ARPA, dcp@SCRC-STONY-BROOK.ARPA Subject: Re: information in RESET segments
I take back my last point. The standard nowhere defines the format of the error message returned to the Upper Level Protocol. Gary Delps idea sounds like a reasonable compromise. Have a set of "standard" error messages with their own individual numbers, but also have a number which says "see the text for further details". This makes for a human friendly, as well as computer friendly interface.
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 84 1725 EDT (Friday) From: don.provan@CMU-CS-A.ARPA To: Mark K. Lottor <MKL@MIT-XX.ARPA> Cc: tcp-ip@SRI-NIC.ARPA, Subject: Re: SFTP
I've got a few comments on RFC913. I assume that the idea behind LIST F is to do a multiple retrieve. As given, it's no good for that between dissimilar machines. There are two reasons for this. First of all, it requires the user process to know something about the format of file names on the remote host. If the user tells the user process to retreive all the files in directory <foo>, the user process sends "List F <foo>". Great. Now the server returns the "file names", so let's say there's one file, RFC913.txt. OK. Now what's the user process supposed to do. I'm sure, just like with FTP, all you twenty user processes will instantly retrieve <foo>rfc913.txt, but the fact of the matter is that there are any number of ways to put the [foo] and the rfc913.txt together. The solution is so simple I always assumed that FTP and SFTP (until I got to the examples) intended it: return the full file spec to the file. After all, that's what the file name really is to an external host, not just what us big boys that use DEC machines know to be the name and the extension. I should be able to start a whole new connection in an entirely different user area and still use the string from the first connection to name the file. It MUST be an absolute name. The second problem with "List F" is that it limits what the server process is allowed to take as an argument. It must be a directory path. You almost never want to retreive all of the files in a given directory. I sometimes want to get all of the most recent RFCs: "RFC91*.txt", but I NEVER want to get ALL of the RFCs. This argument should allow such operations. I don't understand why "Stor Old" and "Stor App" aren't allowed to check for such things as illformed file-spec or no write access to the given file and return a "-" message. Sort of fanciful idea, but it would be interesting to see if the SFTP dialog could be made symetric. The example that made me think of this is that the server says, "55" in response to a RETR, but STOR is followed by "SIZE 55". Would there be any advantage in making the STOR command be a request for the receiver to do a RETR, and then the rest of the dialog go like a RETR, but with the server and user roles reversed? Probably not worth doing, but an interesting idea that crossed my mind.
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Fri 5 Oct 84 23:07:33-PDT From: David Roode <ROODE@SRI-NIC.ARPA> To: TCP-IP@SRI-NIC.ARPA Subject: ["Frank J. Wancho" <WANCHO@SIMTEL20>: HOSTS Table size]
This sounds like a plea for conversion to a resolver accessing
distributed name servers instead of a host table. Has anyone
installed such a scheme in a production host utilizing the 3 currently
running redundant instances of the experimental domain server?
---------------
Return-Path: <@SU-SCORE.ARPA:WANCHO@SIMTEL20.ARPA>
Received: from SU-SCORE.ARPA by SRI-NIC.ARPA with TCP; Fri 5 Oct 84 21:44:33-PDT
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 5 Oct 84 21:36:24-PDT
Date: 5 Oct 1984 22:38 MDT (Fri)
Message-ID: <WANCHO.12053169588.BABYL@SIMTEL20>
From: "Frank J. Wancho" <WANCHO@SIMTEL20>
To: TOPS-20@SCORE
Subject: HOSTS Table size
Isn't anyone getting fed up enough when the HOSTS.TXT no longer fits
and a new MONITR has to be built again every so often, to rattle some
cages? Or, have you all found an obsurdly high prime value that
you've never been bit? If so, just tell all of us that number and
I'll go away quietly. Then, the next time the table overruns, we can
all scream together....
--Frank
-------
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 1984 14:17:03 PDT From: POSTEL@USC-ISIF.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: Domain Servers Available
Hi. Yes, three instances of a Domain Server are up and running. They are on SRI-NIC.ARPA, USC-ISIB.ARPA, and USC-ISIF.ARPA. These are TOPS-20 systems, the implementation is written in pascal. We are most interested in having people write resolvers and test against these servers. If you do plan to write some code please check in with Paul Mockapetris at ISI to get the details of some small differences from the initial specifications (RFCs 882 & 883). Paul is MOCKAPETRIS@USC-ISIF.ARPA. A revised spec is planned soon. Work is also under way on a new implementation schedule for putting the full domain name system into use. That schedule should also appear in the next few weeks. --jon. -------
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Sat, 6 Oct 84 12:27:51 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: don.provan@CMU-CS-A.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: maximum packet size
The falacy in this and the reason for some other non-optimizations in IP is that the packet may not traverse the same path everytime through the net. If the two routes have dissimilar MTU's your information gained by the proposed ICMP RECORD-MTU packet would be invalid. Better to have all the things that are playing gateway to act like real gateways and to know how to fragment. One of the reasons gateways don't try and optimize by reassembling fragments is this. A more useful option is one to ask the gateway what the MTU for the intervening net is. That way only one host need to know the "decreed" route on the net. -Ron
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: Sat 6 Oct 84 15:25:55-EDT From: Mark K. Lottor <MKL@MIT-XX.ARPA> To: tcp-ip@SRI-NIC.ARPA Cc: don.provan@CMU-CS-A.ARPA Subject: Re: SFTP comments
Here's some comments on your comments on RFC913: First, the problem of LIST F not returning full file names: If you just do a LIST F and take the list returned to use with multiple retrieves it should work fine. This is because you are connected to the directory that the LIST F came from. If you gave an argument to LIST F then before doing the retrieves you can CDIR (connect) to the directory. Your argument might still be valid and we'll see what happens when we get some working implementations. LIST F should probably be made to take any legal argument that could be sent to the remote machines directory command. This could be changed, and actually, my implementation allows this. You're right, STOR OLD and APP should allow a '-' reply. That will be changed. As for the comments on sending the size of the file as in '55' or 'SIZE 55', this might help: There is actually a number sign before the '55', the valid replies are +,-,#,!. I guess a number sign isn't a valid character in an RFC? Other comments on the RFC: I was working on an easier way to do logins and connects that eliminates the '!' reply. This would consists of sending USER, ACCT, and PASS commands and receiving only '+' or '-'. When you think you have sent enough the you would send a LGIN command which would then return only a '+' or '-'. In RETR, after you tell the remote host to SEND, it should not just return the file. It should return either a '-' reply with an error message (ex. Can't read file), or a '+' reply followed by the file and a null (for consistency). A new RFC will probably be published once some implmentations are running and have been tested. Keep sending comments. Mark -------
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 1984 21:16:18 PDT From: POSTEL@USC-ISIF.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: re: information in RESET segments
To help me think about this can some one give an example list of the things that would be reported as "reasons" and what the TCP receiving these might be expected to do about them? --jon. -------
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 7 October 1984 00:00-EDT From: David C. Plummer <DCP @ MIT-MC> To: StJohns @ MIT-MULTICS Cc: DCP @ MIT-MC, tcp-ip @ SRI-NIC, dcp @ SCRC-STONY-BROOK Subject: Re: information in RESET segments
Date: Fri, 5 Oct 84 16:12 EDT
From: Mike StJohns <StJohns@MIT-MULTICS.ARPA>
In-Reply-To: Message of 5 Oct 84 11:11 EDT from "David C. Plummer"
I take back my last point. The standard nowhere defines the format of
the error message returned to the Upper Level Protocol.
Gary Delps idea sounds like a reasonable compromise. Have a set of
"standard" error messages with their own individual numbers, but also
have a number which says "see the text for further details". This makes
for a human friendly, as well as computer friendly interface.
Grumble. This is not a negotiation. That is my understanding of
why SMPT uses numbers: to negotiate various options and
alternatives and provide a standard for doing to. There isn't
any dialog going on with RESET segments; one side tells the other
its a loser and that's that.
Just for grins, I counted the number of calls to
RESET-INCOMING-SEGMENT in my implementation. There are 8 of them
in the TCP network level. There are 2 occurances of
SEND-RST-FOR-TCB, both as part of the user's stream interface,
and these 2 get reasons from a higher level.
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 7 Oct 84 11:22:04 PDT From: Murray.pa@XEROX.ARPA To: tcp-ip@SRI-NIC.ARPA Cc: Murray.pa@XEROX.ARPA Subject: Re: information in RESET segments
It seems like a great idea to me. I vote for both a machine readable code and a text string. Several of our protocols have used that approach. It works pretty well. A code lets machines make reasonable decisions, and text conveys the fine print to a human.
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Sun, 7 Oct 84 14:39 EDT From: Mike StJohns <StJohns@MIT-MULTICS.ARPA> To: POSTEL@USC-ISIF.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: information in RESET segments
Reasons huh? OK, here's a couple: 1) No connection. (In reply to any packet to indicate that the receiving system didn't have a TCB it could direct the packet to.) 2) Bad or Missing Security option. (The receiving system was expecting security option with the packet.) 3) Ack received, connection was in LISTEN state. 4) Unable to establish connection, no resources. (For example, TELNETing to an already innundated system.) This is just a partial list while perusing the MIL STD document. As for the what the TCP receiving the reset would do about them... generally all it can do is report it to the ULP.
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Sun, 7 Oct 84 19:56:28 CDT From: Mike Caplinger <mike@rice.ARPA> To: TCP-IP@SRI-NIC.ARPA Subject: Unix 4.2 remote copy and execution
I am currently attempting to implement a subset of the 4.2 BSD rsh/rcp/rexec facilities for TCP/IP under VM/CMS. Has there been any attempt, or is there any interest, in trying to define these things in an RFC? While they are not particularly "Internet-flavored" they are much more convenient. There are of course a number of security issues, over and above the protocol itself, that deserve discussion. - Mike
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 08 Oct 84 07:30:40 PDT (Mon) From: Marshall Rose <mrose@uci-750a> To: Mike Caplinger <mike@rice> Cc: TCP-IP@sri-nic Subject: Re: Unix 4.2 remote copy and execution
I'd be interested in seeing what you get. Sadly, I agree that rsh/rlogin/rcp work real well (I use telnet/ftp only when talking to non-BSD sites). I think if you hook up the "authorization protocol" discussed earlier with programs that use the telnet and ftp protocols in such a way that it looks like rsh/rlogin to the *user*, you'd save a lot of work. Nothing's wrong with either telnet or ftp, I just can't stand the user-interfaces... /mtr
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 1984 10:17:35 PDT From: POSTEL@USC-ISIF.ARPA To: TCP-IP@SRI-NIC.ARPA Subject: re: information in RESET segments
I don't see any use for a machine oriented code, since no one has suggested what a TCP could do that depends on the reason received. --jon. -------
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 1984 1351 PDT From: Tuan Truong <TUAN@JPL-VLSI.ARPA> To: tcp-ip@sri-nic Subject: DECnet document
Does anyone have a copy of DECnet-VAX Datalink Driver Specification Is this one of those confidential documents? Tuan ------
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 84 1418 EDT (Monday) From: don.provan@CMU-CS-A.ARPA To: Mark K. Lottor <MKL@MIT-XX.ARPA> Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: SFTP comments
re: your comments re: my comments re: your request for comments There are two problems with the idea of using CDir (well, three, now that I think of it): first, this only works if CDir takes the same argument as List F, which it does according to the spec but which you say it shouldn't and your implementation doesn't. second, the SFTP server can't pull the same trick that the tops-20 FTP server used to (and for all I know, still does): it can't request a password to change the directory. Third, this requires that the SFTP user process knows what the directory was that the user started in if it wants to aboid changing things behind the user's back. The larger question here is whether we should consider "file.ext" a file name for an external entity. I contend that for any external process, the only file name a 20 should give out is dev:<dir>file.ext;version. (well, if it has decnet, node::, i suppose). Anything less than that is giving some tops-20 (yes, admittedly, many other systems, too) idea of what part of a file specification is the file name. As the previous note pointed out, this piece of information is of some value, but it still seems to violate some concept of "keep your file system to yourself." I just remember that the biggest reason I hated this idea in FTP was that some systems allow a wildcarded file spec to include wildcards in the directory specs. If I tell a 10 to give me a directory of "foo.*[757,7312,*,*,*]", it might respond with "foo.mac<crlf>foo.mac<crlf> foo.mac<crlf>", which really gives me no useful information except that somewhere in those subfile directories, there are three copies of foo.mac. Obviously, this is completely worthless for a multiple retrieve, even if there only one copy, and I just couldn't remember which subfile directory it was in.
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 84 1510 EDT From: Rudy.Nedved@CMU-CS-A.ARPA To: POSTEL@USC-ISIF.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: information in RESET segments
Can't you just look at Xerox BSP/RTP protocol design and use the same reasons? "System unavailable for users; try later at XX:XX" can be used for when people are debugging a system and some people are trying to betwork in. "Service unavailable, too many connections". Resource problems. "Protocol transition error; ...." Can be used when some TCP is talking to another TCP and it is doing something wrong... I don't know if I would advocate changing TCP given how many sites use it and who knows how many sites are extremely conservative in what they receive...non-zero reset segments could break things. All I can say is "it is a good idea". Cheers, -Rudy
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Monday, 8 Oct 1984 19:12-PDT From: imagen!geof@su-shasta.arpa To: shasta!POSTEL@USC-ISIF.ARPA Cc: shasta!TCP-IP@SRI-NIC.ARPA, geof@su-shasta.arpa Subject: re: information in RESET segments
You asked for examples of what messages might appear in reset statements. Our TCP implementation does generate these messages internally, for logging on the printer's console when in debug mode. Here is a list of the resets that an imagen printer can generate. * Received packet directed to bad port no. = no listener on destination port (bad demultiplex) * ack of non-existent data = Ack numbers received exceed next sequence number sent (protocol violation) * Packet with no SYN and no ACK = protocol violation * Open packet arrives without a syn in it = connection is not open, but no syn in packet (usually because packet is from an older connection that was aborted). * not accepting connections = no resources for connection (no TCB's, packet buffers, etc.) Also, no message is logged when a higher level of software calls tcp_Abort. If there were a place to put the messages, things like * connection aborted by operator at console * higher-level timeout would also exist. - Geof Cooper Imagen
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Monday, 8 Oct 1984 19:22-PDT From: imagen!geof@su-shasta.arpa To: shasta!POSTEL@USC-ISIF.ARPA Cc: shasta!TCP-IP@SRI-NIC.ARPA, geof@su-shasta.arpa Subject: re: information in RESET segments
What can a host do after interpreting the code in a tcp reset packet? [1] try again with tcp later if the error indicates lack of resources and not lack of service (e.g., SMTP) [2] try XNS or DECNET or TFTP or RS232 ... [3] try to get the same service another way (e.g., send to LPT instead of DIABLO) General issue: Reset statements are generated for (at least) two generic reasons: - lack of resources (temporarily) - no such service (permanent) In the latter case, a retry would have to be based on a total replacement of the higher-level service (e.g., [2] or [3]). In the former case, a retry is suitable after a short while. My philosophy on error codes vs. error strings is that error codes should be as generic as possible and error strings as specific as possible. Error codes suggest a class of recovery from an error, while error strings try to pinpoint the error for later (human) debugging. I haven't been able to think of more than two error codes for tcp reset statements (the others that come to mind can be generated directly by the higher level and can use TCP to communicate the error before connection termination). - Geof Cooper IMAGEN
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 84 1659 EDT (Monday) From: don.provan@CMU-CS-A.ARPA To: Rudy.Nedved@CMU-CS-A.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: information in RESET segments
Actually, I can't find anywhere in the RFC that says a packet with RST set shouldn't have any data. As far as I can see, we can declare any implementation that chokes on a data bearing RST to be in violation of the protocol. But I suspect most implementations, like mine, automatically discard any data that is not otherwise dealt with. I don't think many implementations would break. I say let's do it. I think it's a great idea. Then we can have a fight over whether a SYN to a port that I don't have a service for should be answered with an ICMP no port or a RST with a no port explaination. Hey, while we're at it, how about sending additional information for destination unreachable messages? Does this destination unreachable mean I don't have a path to that host or just that that host is currently down?
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Mon, 8 Oct 84 20:12:27 EDT From: Doug Kingston <dpk@BRL-TGR.ARPA> To: Marshall Rose <mrose@UCI-750A.ARPA> Cc: Mike Caplinger <mike@RICE.ARPA>, TCP-IP@SRI-NIC.ARPA Subject: Re: Unix 4.2 remote copy and execution
There IS something wrong with FTP and TELNET. They force you to send your password in plaintext. What is really needed is a public key encryption technique for verifying the identity of a user or a host. This particularly true now with lots of user operated workstations on Ethernets and other "open" systems where all you need to do is put your system into promiscuous receive mode. The R* protocols are not much better on nets using ARP because you can make your workstation pretend it is some other host if the other host is down, but at least we are no longer sending plaintext passwords. More discussion and ideas if people are interested. -Doug-
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: 9 October 1984 01:46-EDT From: David C. Plummer <DCP @ MIT-MC> To: POSTEL @ USC-ISIF Cc: TCP-IP @ SRI-NIC Subject: re: information in RESET segments
Date: 6 Oct 1984 21:16:18 PDT
From: POSTEL@USC-ISIF.ARPA
To help me think about this can some one give an example list of the things
that would be reported as "reasons" and what the TCP receiving these might
be expected to do about them?
Others have sent several possibilities for things that would be
reported. All of the examples are for pretty low level things,
but a couple were higher up (e.g., "System not really up, try
again at XX:XX"). Most of those examples were refusals or
protocol errors. There is another class: the connection is open
and one side abort closes. Suppose the abort close happens
because of a program error or asynchronous condition. The system
may be able to say "Connection closed because >>Error: the
argument given to SQRT, -4, was not a non-negative number, while
in SQRT <- DISTANCE-TO-LINE <- COMPUTE-DISTANCE" Now this may be
more information than the user wanted, but it sure is a lot
better than having the receiver of the RESET say "Connection
closed -- TCP can't convey reasons".
As you pointed out in a later message, you don't see what the use
of a machine readable form is. I already grumbled about that
because there isn't any need. This information is for a human's
benefit only. I think that's also why nobody took you up on your
request to say what the TCP receiving these should do. I'll tell
you: pass the string to the user if the application program can
handle accepting it.
As I said before, I believe this is completely compatible. Don
Provan's message really warmed my heart; he seems to be in the
right spirit.
Maybe we'll get a friendly protocol out of this yet....
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 09 Oct 84 08:04:40 PDT (Tue) From: Marshall Rose <mrose@uci-750a> To: Doug Kingston <dpk@brl-tgr> Cc: Mike Caplinger <mike@rice>, TCP-IP@sri-nic Subject: Re: Unix 4.2 remote copy and execution
Well, then they're all busted since TELNET/FTP/SMTP/R* don't encode any data at all. So we hack FTP to encrypt my password as it goes down the pipe. Fine. Somebody can still snoop the files that get sent down the pipe later. I'm not arguing security here, and I didn't say that TELNET/FTP/SMTP/R* were secure. What I object to is having to continuously type my password for each FTP/TELNET session. If we could get around that, I'd be happy (for now). /mtr
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: Tue, 9 Oct 84 08:58 EDT From: "J. Spencer Love" <JSLove@MIT-MULTICS.ARPA> To: Mike StJohns <StJohns@MIT-MULTICS.ARPA> Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: information in RESET segments
Re StJohns error reason #2, bad security option: in some cases, it would be invalid to return this message, because the information may not be returned to the user on the originating system. However, it would be useful to LOG such information somewhere. Associating machine-interpretable error codes with the messages allows logging and censorship decisions to be made by the TCP. The network maintainer for a host may find logged information of this type useful even when no information is ever returned to applications.
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 84 1124 EDT From: Rudy.Nedved@CMU-CS-A.ARPA To: imagen!geof@SU-SHASTA.ARPA Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: information in RESET segments
I would normally agree to have error code,,error string in an ABORT packat would be a good thing because alot of protocols use such a format....but I have been burned too often by protocols trying to "recover" in a wizzy way and blowing it. For instance, I don't recomend that mailers try every 2 minutes for a system that has an error code that indicates it is "booting" or "will be available shortly". It helps saturate the network and does not handle a system that failed half way into the boot. I can bring up other examples from my networking experience at CMU and they all seem to say "let the humans figure out why the system is screwed....don't try fancy code analysis". One of the best ones is our Laser printer support which is from Xerox. It uses aborts to indicate how often some network process should "beat on" the server to send the request. It also has several codes that say whether to abort completely or not...voila...it occasionally sends out complete aborts to valid requests losing people's print request (but we hacked around it and ignored the specification) and it occasionaly sends out "please try again much much later" when it is only a temporary problem. The killer is that we can't modify the software...since it is owned by Xerox and we don't have rights. -Rudy
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 84 1423 EDT (Tuesday) From: don.provan@CMU-CS-A.ARPA To: imagen!geof@SU-SHASTA.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: information in RESET segments
another generic reason for a reset is "I think we're confused" which tells the TCP receiving the reset that the sending TCP doesn't think the other side did anything wrong, the connection just got out of whack. If the receiver tries again immediately, he has as much chance of succeeding as if he waits a while. Geof's message convinced me that at least it's conceivable that some machine entity may want to know the reason for the reset. But I don't see any problem with adding this idea after we have some firm ideas, as long as we agree now that error messages shouldn't begin with digits. Another possibility is to send the reason code in the unused window field of the RST message. Perhaps we could even add those codes right into the TCP specs.
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Tue, 9 Oct 84 17:45:55 EDT From: Dave Mankins <dm@bbn-labs-b> To: dpk@brl-tgr.arpa Cc: tcp-ip@sri-nic.arpa, jis%mit-athena@mit-mc.arpa, dm%mit-athena@mit-mc.arpa Subject: re: Public keys and R*
Funny you should mention public key systems on LANs of
workstations...Jeff Schiller and I came to the same conclusion in
discussing remote access on Project Athena's LANs. I've implemented a
set of subroutines emulating 4.2 filesystem system-calls, but using UDP
datagrams to deliver the system calls to remote hosts on the network
(like the Newcastle connection or Purdue's IBIS).
The problem Jeff & I were discussing was: how do you prove that this
datagram is from the person it claims to be? [Almost as important: how
do you do this efficiently and quickly] We are dealing only with the
authenticity of data, not it's privacy, allowing us to use a slower
encryption algorithm (another win is you don't have to authenticate
every UNIX system call--things like STATs can be done by anyone,
descriptor based system calls can use a faster private-key system (the
key is exchanged when the file is opened). People who want privacy can
keep their data encrypted whenever it isn't on their workstation (I
have a scheme for doing this transparently, too, but it won't fit into
the margin).
Right now I'm tenatively looking at using digital signatures generated
using the Rivest-Shamir-Adleman public key system. [The Hellman-Diffie
scheme is known to be breakable, and besides, I can't figure out how to
use it for digital signatures.]
It is not necessary to use a public key system: you can use a scheme
based on DES (or your favorite private key system). If you have a
sufficiently trustworthy host (where "trustworthy" is defined as a
combination of physical and software security) it can serve as an
authentication manager, from whom you obtain conversation keys. Andrew
Birrell and Bruce Nelson used a scheme like this in the remote procedure
call protocol they did at PARC.
They described a scheme for distributing conversation keys securely
(even in a public forum like the Ethernet) in the following way:
Let "Crypt(text, Sue)" represent "text" encrypted with Sue's key.
User Joe's process J wants to talk to user Sue's process, S. J
sends a request for a conversation key to the Authentication
manager. The Authentication manager replies with:
(key, Crypt("key,Joe" Sue))
Which is encrypted using Joe's key. Joe decrypts this message, and
knows that this message is really from the Authentication Manager,
because it is encrypted with his key, which only he and the
Authentication Manager know (we hope). Thus, the dialogue between
the Authentication Manager and Joe is authenticated using Joe's
private key.
J sends Crypt("key,Joe" Sue) in clear-text along with its
datagram request to S. The datagram may be encrypted using the
conversation key, or may just contain some digital signature
generated using the key.
S decrypts Crypt("key,Joe" Sue), and can now decrypt the rest of the
datagram which was encrypted with the conversation key. S knows
that this message is REALLY from Joe, because only Joe could have
gotten the key from the authentication manager, and only the
authentication manager could have encrypted the key with Sue's key.
Or something like that.
Well, this solution isn't really very good for Project Athena, because
we don't really have any machines which are sufficiently secure (or even
reliable) to leave plain-text user keys lying around. We're worried
about some student operator printing out the list of user's keys and
taping it to his or her dorm-room door. There are other problems with
this scheme: key distribution, and a related problem, getting that
56-bit key into a public workstation in the library while you're using
it.
It is, however, the solution I would recommend for any company building
a LAN with workstations in people's offices: once you've typed the key
in, you never take it out, you depend on the trustworthiness of your
computer operations staff to protect the authentication manager and hand
out keys. Also, you are freed from lawsuits if the RSA algorithm is
broken. That is, you aren't any more vulnerable than you were.
Another reason for going with this scheme if you can is the fact that
specialized fast DES hardware is likely to be more widely available than
RSA hardware, sooner.
While a public key system solves the file of plain-text keys problem, it
doesn't solve the getting-the-private-key-into-the-public-workstation
problem (indeed, the RSA scheme aggravates it: instead of being 56-bits,
it's now 200-600 bits!)
But, with the public-key system, the user's private key can be stored
anywhere. The private key is protected by being stored encrypted using
some more traditional technique (using more traditional keys like the
first-name of the user's girlfriend), and may be shipped to the user's
workstation in encrypted form when the user logs in. Once on the
workstation, the user types the key which decrypts the private key, and
the private key may be stored in clear text in the workstation's memory
while the user is logged in, and may be referred to and inherited by the
user's processes. Logging out may look very much like rebooting and
clearing the workstation's memory. Or, that may at least be an option
available to the paranoid user.
Or, that's what I've been thinking about lately. The only problem is
the RSA scheme too pretty slow to be applied to every system call. As I
said earlier, one can try to be clever and authenticate only those
things that REALLY need it, but this is slightly inelegant, in that it
scatters te knowledge of what needs what kind of protection all over the
place, rather than localizing it in the place where the object being
protected lives.
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 84 2129 EDT From: Rudy.Nedved@CMU-CS-A.ARPA To: Dave Mankins <dm@BBN-LABS-B.ARPA> Cc: TCP-IP@SRI-KL.ARPA Subject: Re: Public keys and R*
Dave, What about people putting trap doors in the library software? What about people that just want to disrupt service to your workstation by sending lying aborts or setting up fake gateways? What about systems that are network booted that people occasionally use to talk to and login to their trustworthy hosts or workstations? A serious network hacker for fun can violate all your systems with partial or incomplete authentication and no one has addressed the issue of figuring out if a gateway is "ok" or how to figure out how to limit the effect of having some hosts encrypted and some hosts not and someone putting trap doors in the insecure systems. There used to a phrase around CMU that went "Don't type anything personal into a computer system or network." I believe it and given some systems page off the network...and about trapdoors in C-compilers. All bets are off. The best analogy I can think up is trying to get rid of roaches in someone's house...you can't leave anything alone or they will infest again...the same is true with all points on a network including connected networks. The only realistic philosphy for security is to cover the obvious holes and put in monitoring to catch the few that go thru the semi-obvious holes before trying the very very sublte holes. -Rudy
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: 10 Oct 84 03:18:16 PDT From: Murray.pa@XEROX.ARPA To: TCP-IP@SRI-NIC.ARPA Cc: Murray.pa@XEROX.ARPA Subject: Reassembly
Any historians in the crowd? I have a data point (confession?) to contribute. Until last weekend, the reassembly code at XEROX.ARPA didn't work. XEROX.ARPA is used only for mail. It processes roughly 1000 messages a day. There was some confusion several months ago when something at BRL caused them to fragment most packets. We were one of the sites that didn't work. They undid that change before I tracked down our problems. Over the past several months, I've fixed several problems in that module whenever a crash rubbed my nose in a bug. Making sure it worked correctly just never made it to the top of my stack. Last Friday, I got a phone call from UCI. Their mail wasn't getting through to us. (Our mail was getting to them.) Fortunatley, they gave me a big clue by mentioning that a recent change at their end made it very likely that their packets were now getting fragmented. If you are looking for a convient test case, brew up a program that talks to yourself, and then direct it to GOONHILLY-ECHO. In the last 24 hours, we have received 33000 packets. 47 of them took two fragments.
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Wednesday, 10 Oct 1984 10:33-PDT From: imagen!geof@su-shasta.arpa To: shasta!Murray.pa@XEROX.ARPA Cc: shasta!TCP-IP@SRI-NIC Subject: Re: Reassembly - getting fragments
To get fragments sent to you -- - modify your TCP to offer a MAXSEGSIZE greater than the MTU of the connected network - connect to a vanilla 4.2 (telnet is ok) - generate a clump of data That's how we do it on our Ethernet. Some 4.2's have been fixed to not generate fragments over the locally connected net. - Geof Cooper IMAGEN
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 10 October 1984 12:51-EDT From: David C. Plummer <DCP @ MIT-MC> To: TCP-IP @ SRI-NIC Subject: information in RESET segments
My opnions about the recent rounds of mail on this subject; Geof Cooper is wrong; there are many more than 2 clases of RESET segments. In fact, the two that he gave are specifically in response to SYNs and doesn't take into account anything anybody else has said in the last several days. Rudy Nedved's comments are well taken: give a heuristic program a chance to blow it, and sure enough... J. Spencer Love's reasons for having a machine readable error code is the only coherent reason I have seen. Unfortunately, even in the security violation case I think the application should always get the string. E.g., suppose I try to TELNET to moderately-secure-installation and I don't have access. It can tell me I don't have access. The NSA, on the other hand, might always generate the string "Go away". Note that for tha paranoids, error codes are themselves information!
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 10 Oct 1984 2031 PDT From: Ron Tencati <TENCATI@JPL-VLSI.ARPA> To: tcp-ip@sri-nic Cc: info-vax@sri-kl Subject: Pinging gateways
I seem to be having problems with my routing table entries. Does anyone know of any software that I can get my hands on that will let me "ping" gateways? We run the Kashtan 4.1c IP kernel under VMS 3.6. It sure would be nice if we could get rid of these annoying "network unreachable" messages... I need a way to verify that packets are making it to their destination. We need existing software, we don't have the technology to write our own. Thanks in advance for any help. Ron ------
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 10 October 1984 20:23-EDT From: John R. Lekashman <JRLK @ MIT-MC> To: tcp-ip @ SRI-NIC Subject: TCP/IP under primitive conditions
So, does anyone on this list know about partial TCP/IP implementations (ie at least user FTP, and maybe even TELNET) running on a PDP-11 with Rt-11 or TSX as the operating system. Of course a more full implementation would be much nicer, but I don't expect miracles.
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: Thu, 11 Oct 84 12:41:35 CDT From: Paul Milazzo <milazzo@rice.ARPA> To: Rudy.Nedved@CMU-CS-A.ARPA Cc: TENCATI@JPL-VLSI.ARPA, tcp-ip@SRI-NIC.ARPA, info-vax@SRI-KL.ARPA Subject: Re: Pinging gateways
Rudy: What Ron meant was that he wants a program with which can manually send out pings and look for responses. He is interested in using such a program as a manual diagnostic aid for connectivity analysis, not part of his standard operating procedure. I'm sure that by now we're all aware that pinging in the TOPS-20 sense is a bad idea. Incidentally, the particular problem Ron wishes to diagnose is why, after correcting his routing information, we (Rice) can connect to JPL-VLSI, but JPL-VLSI can't open connections to us at either our CSNET-PDN or RICE-NET address. I've never seen this sort of asymmetric behavior in a TCP/IP. Does anyone out there have any ideas? Paul G. Milazzo <milazzo@rice.ARPA> Dept. of Computer Science Rice University, Houston, TX
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 84 1210 EDT From: Rudy.Nedved@CMU-CS-A.ARPA To: TENCATI@JPL-VLSI.ARPA Cc: tcp-ip@SRI-NIC.ARPA, info-vax@SRI-KL.ARPA Subject: Re: Pinging gateways
You don't want to ping anything...all you do is clogg up the network if everyone uses your solution. The best bet is to wait for the BBN core gateways to get the "last bug" fixed where they forget about little networks like MILNET. They seem to do a pretty good job... ...is it possible that you have te version of VMS software that does not have a default gateway and you have to specify for each network a gateway? Maybe this is the problem...we had this problem and we got errors like "network unreachable" or something. At the moment, TOPS-20/TENEX BBN code has pinging in it for PRIME gateways...for one site this caused their connected IMP to "freeze" every so many minutes because the PING code was sending a massive number of PINGs to a large number of gateways (of course the problem was also one of incorrect "channel" usage and can sort of be avoided). All and all PINGs by non-gateway hosts is a bad idea...especially for them poor 9600 and 1200 baud links some folks (like us) have. -Rudy
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 1984 1629-PDT (Thursday) From: Martin Fouts <fouts@AMES-NAS-GW.ARPA> To: Paul Milazzo <milazzo@rice.ARPA> Cc: TENCATI@JPL-VLSI.ARPA, tcp-ip@SRI-NIC.ARPA, info-vax@SRI-KL.ARPA, Rudy.Nedved@CMU-CS-A.ARPA Subject: Re: Pinging gateways
I don't have an idea, but I've got related problems. We have
three vaxes here using the same MILNET Imp. The VMS host can get
through to SRI-UNIX without problems. Both of the 4.2BSD vaxes are LAN
gateways and running Kirton's EGP implementation. One of the 4.2BSD
nodes can get through to SRI-UNIX, but nodes on its LAN can't. The
other one can't get through at all.
The error message is "connection timed out" in either case.
Anybody got any ideas?
----------
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 84 16:36 PDT From: Tom Perrine <tom@LOGICON.ARPA> To: UNIX-WIZARDS@BRL.ARPA, TCP-IP@SRI-NIC, LCROSBY@ALMSA-1.ARPA, John O'Donnell <multiflow!odonnell%UUCP@YALE.ARPA>, Barry Shein <root%bostonu.csnet@csnet-relay>, olympus!sauron!bob@ucbvax, rjh@crdc Cc: Tom Perrine <tom@logicon>, John Codd <john@logicon>, Roger Tjarks <roger@logicon> Subject: HyperChannel Summary
Well, after many false starts and two conferences to attend, I have finally gotten the HyperChannel summary together. I had 25 responses, describing connections between just about every kind of system you can imagine. Everything from UNIX to Multics, Cray and UNIVAC. BRL is running a 4.1a driver on their homebrew V6+v7+sysIII UNIX system. Reportedly this is currently talking between VAXes and PDP-11s and will soon include a Cyber 170. (Douglas Kingston <dpk@BRL-TGR.ARPA>, Ron Natilie <ron@BRL-TGR.ARPA>, Richard D. Romanelli <romanelli@BRL-AOS.ARPA>) and Mike Muss <mike@BRL-TGR.ARPA> JPL is running Univac 1100s and and a Fujitsu 3033 clone. (Matthew Weinstein <matt@UCLA-LOCUS.ARPA>) UCLA-LOCUS has tested HyperChannel between IBM 4331 running VM/370 and VAX-11/750 running VMS. (Barry Gold <lcc.barry@UCLA-LOCUS.ARPA>) Linda Crosby (lcrosby@ALMSA-1.ARPA) reports that a company called "Uniq Digital Technologies" is marketing a package that reportedly allows SYS VR2 UNIX systems to use HyperChannel. It look like they try to support remote login to IBM TSO from UNIX (Yech!!! -tep) Uniq's address is: Uniq Digital Technologies 28 S. Water St. Batavia, IL 60510 (312) 879-1008 Daivd L. Gehrt (dave@RIACS.ARPA) reports that the NAS project at NASA Ames is running HyperChannel between VAXes and a Cray. He suggested talking to creon@ames-nas-gw, who also responded with details: VAX-11/780 running 4.2 plus the driver from Steve Glaser at Tektronix. Tektronix is using HyperChannel to link seven Ethernet local-area networks. Some of the nodes are VAX-11/780s. (Reported by Dave Stewart <daemon!davest@CSNET-RELAY.ARPA, who suggests contacting Tim Fallon <tektronix!timf>) Peter Gross (hao!pag@seismo.ARPA) reposrts that he is using a HyperChannel at NCAR (National Center for Atmospheric Research) to connect two Cray-1a's, two VAX 4.2's, two VAX/VMS's, two IBM 4341's and three PDP-11/70 Unix's. (Whew!) Mike StJohns (StJohns@MIT_MULTICS.ARPA) reports that the Air Force has a HyperChannel made up of four Multics systems. In almost every case, the respondents mentioned poor performance and suggested using Ethernet of some other LAN instead of HyperChannel. Specifically, Peter Gross mentioned that his 10Mb Ethernet outperforms the 50Mb HyperChannel. I personally would like to run Ethernet instead, but the Government has a few HyperChannel machines that we will have to connect to. *sigh* My thanks to all who responded, as my apologies to those who think this message was too long. Thanks again, Tom Perrine Logicon - OSD Network and Secure Systems Department San Diego CA (619)455-1330 x 201 HyperChannel (in all its various spellings and capitalizations) is a trademark or service mark or something of Network Systems Corp. VAX, PDP and VMS are trademarks, etc. of Digital Equipment Corp. Multics is a trademark of Honeywell. UNIVAC is some kind of something to Sperry-Univac. UNIX is a trademrk of AT&T Bell Labs (or whatever they call themselves this month) Cray is the name of a computer company and a person. IBM is a trademark of International Business Machines. Who cares about Fujitsu? CDC and Cyber have mystical meaning to Control Data Corporation.
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 84 1436 EDT From: Rudy.Nedved@CMU-CS-A.ARPA To: Paul Milazzo <milazzo@rice.ARPA> Cc: TENCATI@JPL-VLSI.ARPA, tcp-ip@SRI-NIC.ARPA, info-vax@SRI-KL.ARPA Subject: Re: Pinging gateways
Well. Yesterday CMU-Gateway stop getting routing updates for MILNET from the core gateway that we get information from for about 4 hours. The result was that CMU-CS-A (ARPANET) could not talk to CMU-CS-B (MILNET) but CMU-CS-B could talk to CMU-CS-A. The subtle difference (I believe) is that the TOPS-10 code will use the IMP/port information it keeps on active connection when sending a response....and uses its assigned gateway when it initiates a connection. Given that if you give a packet to a one of your two assigned ARPANET/MILNET gateways...it tends to deliver it even though the core gateways don't tell anyone else about its delivery ability. I don't like the situation and wish there were "fixes" but one must recognize that the "growth" of the Internet structure has been like an explosion...kinda of unexpected....the core gateways and other gateways are having a problem dealing with the information (that is why I like the concept of hiding as much internal network structure as possible from external gateways). -Rudy
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 84 14:55:42 EDT From: dca-pgs @ DDN1.ARPA To: tcp-dig @ DDN1.ARPA, hawgs @ sri-nic.arpa, tcp-ip @ sri-nic.arpa Cc: navyusers@ddn2.arpa,afusers@ddn2.arpa Subject: 3rd-Party TCP/IP LAN for IBM VM and IBM PC
From MISWeek, 10 Oct 84, p. 34: "Spartacus Computer (of Bedford, MA) ... is now entering the LAN marketplace with hardware and software offerings. Its first product line in the LAN market includes an Ethernet controller, called the 'K-200', a new software pkg called 'KNet', (and one) called 'KNet/PC', (so that) an IBM PC can operate as a host on an Ethernet. ... ... [A typical config is priced at] $24500. ------------------------------------------------- The article goes on to say that KNet and KNet/PC both include TCP/IP. KNet runs as an application under VM/SP and supports FTP, TFTP, and Telnet. KNet/PC supports TFTP and Telnet. The KNet/PC is very likely the MIT PC package that Proteon was also marketing with the ProNet. I'm not too familiar with KNet/VM, except that I'm pretty sure that it's not the WISCNET package. Things conspicuously absent from the press release: -SMTP. Wasn't mentioned. -Any sort of operational history or testing in an Internet environment. -Plans for a mainframe-to-IMP interface. (An immediatee thought would be running KNet+K-200 into an Ara## Arpa gateway) I mention these things because there's been a tendency for some vendors to " christen some things "TCP/IP" with no operational evidence that they will work on the Internet or in an Internet environment. Still, I hope someone will explore this; it looks interesting. I heard that Spartacus was OEMing this package to ComputerVision and that they had shipped a number of copies already. --------------------------------------------------- Good hunting, -Pat Sullivan
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 1984 17:17:24 EDT From: MILLS@USC-ISID.ARPA To: JRLK@MIT-MC.ARPA, tcp-ip@SRI-NIC.ARPA Cc: MILLS@USC-ISID.ARPA Subject: Re: TCP/IP under primitive conditions
In response to the message sent 10 October 1984 20:23-EDT from JRLK@MIT-MC John, See the file DCNET.DOC in the FUZZBALL directory at ISID for a description of the "fuzzballs," which mumble IP/TCP and a few other things in an emulated RT-11 environment. See HELP.DOC in the same directory for details on the commands and application protocols. There are fuzzballs now all over the place - CMU, Wisconsin, Michigan and Maryland U's, DARPA (IPTO), Ford (Motor and Aerospace), Linkabit, NTARE (Norway), DFVLR and USECOM (Germany) and soon at CNUCE (Italy), to name a few. Notice the plague is creeping eastward... Dave -------
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: Thu, 11 Oct 84 21:48:29 EDT From: Mike Muuss <mike@BRL-TGR.ARPA> To: Paul Milazzo <milazzo@RICE.ARPA> Cc: tcp-ip@sri-nic.ARPA, info-vax@sri-kl.ARPA, unix-wizards@BRL-TGR.ARPA Subject: Re: Pinging gateways
For 4.2 BSD, BRL has a program called "ping", which allows you to measure connectivity, round trip time, and packet loss. Source is availible on BRL-VGR and BRL-TGR via anonymous FTP. We also have in development a program to make sure that the "default route" is working, and to switch among a set of them in event of failure. We will probably put this program into production in a week, and will distribute in November. -Mike
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Oct 84 10:05:59 PDT From: Barry Gold <lcc.barry@UCLA-LOCUS.ARPA> To: unix-wizards@brl, tcp-ip@sri-nic, LCROSBY@ALMSA-1, multiflow!odonnel%UUCP@YALE, root%bostonu.csnet@csnet-relay, olympus!sauron!bob@ucbvax, rjh@crdc Cc: tom@logicon, john@logicon, roger@logicon Subject: HyperChannel Summary--CORRECTION
The experimental hookup of VM/370 and VMS via a Hyperchannel was done at SDC (System Development Corp.) in Santa Monica, NOT at UCLA-LOCUS as Tom Perrine's summary suggested. barry
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Oct 84 8:25:47 EDT From: Michael Brescia <brescia@BBNCCM.ARPA> To: imagen!geof@su-shasta.arpa Cc: tcp-ip@sri-nic.arpa Subject: Re: Reassembly - getting fragments
To get IP fragmentation without modifying your system, you can telnet (or ftp) connect to host 'etam-echo', 'satnet-echo', or 'goonhilly-echo' or 'tanum-echo'. The Maximum Transmission Unit (MTU) on satnet is 256 bytes, which is among the smallest of nets. In each case, you will find yourself connected to your own host, then log in and start up data. With telnet, typing a page of text out is usually sufficient to send many packets which get fragmented. If reassembly is not working in your host, you see the connection hang. The differences in the 'xx-echo' hosts are the length (time delay) of the paths. 'etam-' is near the arpanet, less than one second delay; 'satnet-' is one satellite hop, 'goonhilly-' and 'tanum-' are two satellite hops. Each hop adds about a second to the round trip. I hope your best test monitor is your own implementation (of TCP/IP).
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 84 08:35:27 EDT (Fri) From: Dan Grim <grim@udel-ee> To: Paul Milazzo <milazzo@rice.arpa> Cc: Rudy.Nedved@cmu-cs-a.arpa, TENCATI@jpl-vlsi.arpa, tcp-ip@sri-nic.arpa, info-vax@sri-kl.arpa, grim@udel-ee Subject: Re: Pinging gateways
We saw exactly the same behavior here at Delaware when machines on two separate local nets could not connect in one direction when they could in the other. Our problem turned out to be that one of our multiply connected machines (arpa and local ethernet) was sending its arpa internet address as the source address in the IP packets and the machine on the other local net apparently had the wrong routes installed to reply. That machine could reach other arpa hosts however so it is not as simple a problem as it may seem. The outcome is that routing on intermediate hosts seemed to be able to cause the assymetric behavior. Dan Grim <Grim@UDel> Dept of Electrical Engineering University of Delaware
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: Fri, 12 Oct 84 12:39:15 edt From: God <root%bostonu.csnet@csnet-relay.arpa> To: dca-pgs%ddn1.arpa@csnet-relay.arpa, hawgs%sri-nic.arpa@csnet-relay.arpa, tcp-dig%ddn1.arpa@csnet-relay.arpa, tcp-ip%sri-nic.arpa@csnet-relay.arpa Cc: afusers%ddn2.arpa@csnet-relay.arpa, navyusers%ddn2.arpa@csnet-relay.arpa Subject: Re: 3rd-Party TCP/IP LAN for IBM VM and IBM PC
Boston University will begin beta-testing the SPARTACUS box on our 3081 (VM) later this month. Part of the beta testing will be pieces of the application environment (eg. FTP, TELNET.) No, it is not WISCNET (we will be running that also and doing comparative benchmarks across a DACU.) The ethernet these will be attached to will be running 4.2bsd hosts and a TOPS-20/NI20. In addition two of our 4.2bsd hosts can (do) act as gateways to the UNGERMANN/BASS broadband running our driver out to/from both 4.2bsd and VMS/Wollongong. If there is an interest I will be happy to summarize our experiences from time to time to this audience. We have no current plans to use the IBM/PC interface. Barry Shein Distributed Systems Group Boston University
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: Friday, 12 Oct 1984 17:55-PDT From: imagen!cpr@su-shasta.arpa To: shasta!TCP-IP@SRI-NIC Subject: Spartacus TCP/IP
Apparently, Spartacus is selling a real TCP/IP implementation for VM/370 systems, but the software currently lacks ARP--you have to hardwire ARP-equivalent information. They've gotten it talking to SUN, Apollo and Masscomp workstations, as well as the MIT PC/TCP software, from what I've heard. They designed, and now manufacture, their own channel-to-Ethernet adapator board. Isn't someone out there watching who knows more details? (Doesn't Symbolics have a K102, or whatever they called their now-defunct mini-370 product?) --Chris Ryland, IMAGEN
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: Sun, 14 Oct 84 19:57 EDT From: "Christopher C. Stacy" <CStacy@MIT-MC.ARPA> To: "David C. Plummer" <DCP@MIT-MC.ARPA> Cc: TCP-IP@SRI-NIC.ARPA Subject: re: information in RESET segments
How about a code at the front of the RST packet telling something about the text in the rest of the data. If the code is zero, the RST is unexplained. Otherwise the rest of the packet contains textual information to be passed to the application (if that capability exists.) The code would be some standardized number (machine-readable frob) telling what software layer (Application, TCP, IP) "caused" the RST, and some very general reason such as: System Not Up, Protocol Violation, Internal Bug Detected, Operator Aborted Conn, Random. The code is a gross discriminator for the otherwise unexplained Abort-close, and I can imagine various different software layers examining it and taking some alternate or additional action besides presenting the error text string to the user. Examples of actions which might be taken include: make a log entry of some kind; inform the user that the foreign host thinks there is a bug somewhere and that some maintainer should be notified; or even send bug reporting mail automatically (many programs on our system do this sort of thing when internal impossible-condition bugs are detected). Chris
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: Mon, 15 Oct 84 10:21:03 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: dca-pgs@DDN1.ARPA Cc: tcp-dig@DDN1.ARPA, hawgs@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, navyusers@DDN2.ARPA, afusers@DDN2.ARPA Subject: Re: 3rd-Party TCP/IP LAN for IBM VM and IBM PC
Sounds like something you'd buy at K-Mart. -Ron
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Oct 84 17:01:39 edt From: glenn@LL-XN (Glenn Adams) To: tcp-ip@sri-nic.ARPA Cc: hostmasters@sri-nic.ARPA Subject: RFC811 and VERSION keyword
In an attempt to automate retrieval of the NIC host table, I attempted to utilitze the VERSION keyword mentioned in each message received from NIC indicating that a new host name had been installed. However, upon attempting to use this keyword, I find it is not implemented, nor is it mentioned in RFC811. Does it really exist? Can it be added? My purpose for using it would be to maintain a local version number and query the hostname server on a regular (daily?) basis for any changes in the version. If, and only if, the version was updated, would the entire table be retrieved. Glenn A. Adams MIT - Lincoln Laboratory
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: Thu, 18 Oct 84 20:10:05 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: little@DCN5.ARPA Cc: header-people@MIT-MC.ARPA, msggroup@BRL.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: Virtual Terminal Protocol
Actually, the WISCNET software that allows you to use TCP/IP to IBM-370 series machines running VM/CMS does this. They have an option negotiation that says "do 3270 style stuff" and from then on send 3270 control messages. I have been meaning to try to simulate the user end on UNIX with a termcap driven user telnet, but haven't gotten around to it. -Ron
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: 19 Oct 1984 01:11-PDT From: ESTEFFERUD@USC-ECL To: little@DCN5 Cc: header-people@MIT-MC, msggroup@BRL, tcp-ip@SRI-NIC Subject: Re: Virtual Terminal Protocol
Msggroup and header-people are both the wrong lists for this topic. Please, everyone (and especially those of you who we all know know better), refrain from dumbly copying these two lists on replies, just because the originator did not know better. I can understand innocent new netmail users making such an error, but I cannot understand why knowlegeable people blindly continue? Thanks for your forebearance, and your consideration. Stef
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: 18 October 1984 23:12-EDT From: Christopher C. Stacy <CSTACY @ MIT-MC> To: glenn @ LL-XN Cc: hostmasters @ SRI-NIC, tcp-ip @ SRI-NIC Subject: RFC811 and VERSION keyword
My automated host retrieval program uses the VERSION command and works fine.
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: 18-Oct-84 19:33:35-UT From: little@dcn5 To: header-people@mit-mc.arpa, msggroup@brl, tcp-ip@sri-nic.arpa Subject: Virtual Terminal Protocol
I am attempting to create a virtual terminal protocol (VTP) with emphasis on solving problems created by forms mode type terminals (eg-3270). I currently view the problem with the following breakdown - Graphical (Character) Representation code for information exchange (agreement) Control Domain and Exercising modal operation transfer requests function keys out-of-band signals Display cursor addressing end-of-line/screen condition presentation attributes Does anyone have any interesting thoughts or know of problems they are having in this area?? (or are header/TCPIP/msg people the right people for this sort of thing?) Specifically - what problems do you have with TELNET?? Are there deficiencies you would like to overcome with TELNET or RFC 731? Also, does anyone have access to the new VTP spec put out recently by the Terminal Repertoire Committee of ANSI (chaired by Henry Lowe -DEC)? Mike Little - LINKABIT@DCN5 -------
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 19 Oct 1984 1020 PDT From: Ron Tencati <TENCATI@JPL-VLSI.ARPA> To: tcp-ip@sri-nic Subject: Nicname VERSION command
I have used this command by connecting to SRI-NIC port 101. It works fine for me.. +Ron ------
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: 19 Oct 1984 at 1009-EDT From: hsw at TYCHO.ARPA (Howard Weiss) To: tcp-ip at nic Subject: TCP/IP for RSX
One of my associates expressed an interest in obtaining a TCP/IP implementation for a PDP 11 running RSX-11M. There appear to be several RSX systems listed in the NIC host table. Could one of the RSX TCP/IP gurus please advise me as to the availability of the protocol suite. Many thanks, Howard Weiss -------
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: 19 Oct 1984 1321-EDT (Friday) From: James O'Toole <james@gyre> To: glenn@LL-XN (Glenn Adams) Cc: hostmasters@sri-nic.ARPA, tcp-ip@sri-nic.ARPA Subject: Re: RFC811 and VERSION keyword
The VERSION keyword is working just fine. I have automated table updating on all our 4.2bsd unix machines running now, if you want it. --Jim
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: 20 Oct 84 18:16:42 PDT (Sat) From: Jim Guyton <guyton@rand-unix> To: tcp-ip@sri-nic Cc: guyton@rand-unix Subject: Wanted: Ethernet Terminal Servers
I'm aware of Interlan and Bridge terminal servers, but I'm looking to buy (or build) one that talks real TCP/IP. Anyone else trying to do this? -- Jim Guyton
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: 20 Oct 1984 17:39-EDT From: DESJARDINS@USC-ISI.ARPA To: little@DCN5.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Virtual Terminal Protocol
There are currently three main virtual terminal standardization activities internationally, all of which are currently in the working draft stage. ISO is working on a Basic Class Virtual Terminal, which is really equivalent to Telnet, hence would not be functionally too interesting to someone interested in Forms Class. Mike, I have a copy of the just-released Service Definition for the Basic Class, and I can send you a copy if you will send me your correct mailing address. Then other people could get a copy from you. This is the latest internal committee working draft of the service definition: in ISO, the "service definition" is the specification of what service a functional entity provides to its user, and the "protocol specification" is the specification of the data units exchanged between peer entities cooperating to provide the service. In this case, the service is provided by Virtual Terminal Application Entities (VTAEs) operating in the Application Layer, using the services of the Presentation Layer to communicate with each other (to allow for syntax matching between dissimilar machines). The Service Definition and Protocol Specification for Basic Class are aiming at Draft Proposal status in March 1985. ECMA (European Computer Manufacturers Association) is working on Forms Class. Their work is intended to be compatible with that of ISO. I don't know what the status is. In both the above cases, try contacting Henry Lowe at DEC in Maynard, Mass. for more info. There is also a New Work Item called Computer Graphics Interface in ISO, aimed at providing the virtual device interface for the GKS (Graphical Kernel System) standard for interactive graphics. Now that GKS is an ISO standard, the CGI work (which is logically the carry-on of the Virtual Device Interface Project of ANSI into the international arena) is expected to get a lot of attention. Try contacting Peter Bono at Graphic Software Systems in Gales Ferry, Conn. for more info. I'm afraid that none of these standardization activities would be stable enough for even trial implementations before 1986. Hope this info is helpful anyway. --Dick dJ
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: Sun Oct 21 14:28:13 1984 From: Martin Lee Schoffstall <cadmus!schoff@seismo.ARPA> To: cadmus!seismo!tcp-ip@nic.ARPA Subject: telnet/tcp/ip ethernet terminal servers
Both Bridge and Interlan are working on this, though Bridge is much
closer to a product. It will be based initially on their big box
(GS/1???). Back in May I had some very intense discussions with
Ed McHugh (Director of Software Engineering @ Interlan) about taking
the NTS10 and doing the above. They thought XNS was so wonderful and
IBM's ring was so imminent that they didn't want to commit their
resources to this speculative protocol. Ed McHugh is leaving Interlan
shortly to return to PR1ME and they are now working in that area. To
bad they wasted 6 months. One other company with a lot of IP experience
will announce a product shortly which I am not at liberty to divulge.
marty
{bbncca,wivax,linus,seismo}!cadmus!schoff
cadmus!schoff@seismo.ARPA
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: Mon 22 Oct 84 14:24:42-PDT From: Ken Harrenstien <KLH@SRI-NIC.ARPA> To: don.provan@CMU-CS-A.ARPA, ron@BRL-TGR.ARPA Cc: HOSTMASTER@SRI-NIC.ARPA, TCP-IP@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA Subject: Re: Host Table - Version #393
Don.Provan is correct. The string returned by VERSION is not defined at this time. It need not even be a numerical string. If it is in any way different from the previous string you recorded, you should get a new copy of the host-table information. It's easy to see, though, how someone can make the empirical assumption that the string is always a number which always increases. The VERSION keyword was a feature added after the RFC came out. I'll ask that the "new-table-available" message broadcast from HOSTMASTER be modified to both avoid this implication and to mention that HELP is available as a keyword. -------
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: 22 Oct 1984 14:37 PDT From: Lars Poulsen <LARS@ACC> To: TCP-IP@SRI-NIC Subject: Telnet/tcp/ip/ethernet servers
What functionality is it that we are talking about here. Do you really mean SERVER as in something that will accept TELNET connections and pass them on to a host on async terminal lines plugged in to the hosts async distribution panel ? Or do you mean terminal concentrator, a device that has async terminals wired to it and lets those terminals access hosts that somehow have telnet server software on them. I can see a market for a terminal concentrator; but not really for a server. / Lars Poulsen ------
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: Monday, 22 Oct 1984 15:03-PDT From: imagen!cpr@su-shasta.arpa To: shasta!tcp-ip@sri-nic Subject: TCP/IP terminal servers
I hear that Bridge has such a beast. 415-969-4400. --Chris Ryland, IMAGEN
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: Mon, 22 Oct 84 13:53:19 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: HOSTMASTER@SRI-NIC.ARPA Cc: TCP-IP@sri-nic.ARPA Subject: Re: Host Table - Version #393
When it becomes necessary to revert to an older host table due to errors in a newly released one, it would be better to supercede the defective one with the old one (with a higher version number). Our host table retrieval is entirely automatic. If you back up to a previous table, we will never use it, because we will not use a host table with a version number less than the one we already have. This is the reason the VERSION number was put in to begin with and it was stated then that the numbers would always be increasing. -Ron
-----------[000096][next][prev][last][first]---------------------------------------------------- Date: 22 Oct 84 1500 EDT (Monday) From: don.provan@CMU-CS-A.ARPA To: Ron Natalie <ron@BRL-TGR.ARPA> Cc: HOSTMASTER@SRI-NIC.ARPA, TCP-IP@sri-nic.ARPA Subject: Re: Host Table - Version #393
i seem to remember seeing several times that the value returned by the version command is undefined and should only be checked for a change. if ANYTHING changes, you must assume that it's a new version and grab it. presumably the current practise is designed to avoid having a site that never noticed the bogus version from retrieving a new copy of the version it currently has. (no doubt, it's also easier to keep track of versions back at NIC, too.) i think this is perfectly acceptable behavior and see no reason for it to change. i don't see why you would ignore old version, anyway. if the current version is older than the version you have, that's no reason to think your version is better. in fact, there's every reason to believe the opposite, since YOUR version is not the CURRENT version.
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: Mon, 22 Oct 84 16:09:27 edt From: Alan Parker <parker@nrl-css> To: guyton@rand-unix Cc: tcp-ip@sri-nic Subject: ethernet terminal servers
A dealer is bringing a Bridge terminal server out here next week for a demo. He claims it talks TCP/IP. I intend to plug it into my ethernet and try it out. I'll report what