|
|
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 I learn. [He sent me a document dated Sept. 1984 from Bridge, called TCP/IP Compatible Terminal Server, CS/1-A with TCP/IP software. It looks like the same terminal server hardware they have been selling with new software.] -Alan
-----------[000098][next][prev][last][first]---------------------------------------------------- Date: 22 Oct 1984 1959-EDT (Monday) From: James O'Toole <james@gyre> To: tcp-ip@sri-nic Subject: Automated table updating
If you want my automated table updating as is, ftp the tar file from Gyre; anonymous ftp, and the file is in pub/netmap.dist. Just extract the tar file into /etc/netmap on your machine and read the README files. --Jim
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: 22 Oct 1984 2137-EDT (Monday) From: James O'Toole <james@gyre> To: don.provan@CMU-CS-A.ARPA Cc: HOSTMASTER@SRI-NIC.ARPA, TCP-IP@sri-nic.ARPA, Ron Natalie <ron@BRL-TGR.ARPA> Subject: Re: Host Table - Version #393
I too have seen somewhere that the string returned by the version command to the hostnames services was only guaranteed to be unique. Does anyone remember where this is stated? I just checked RFC811 and didn't see it. Still, since the NIC is still (right now) returning 393 as the version string, we should not be told to use version 392. Whether the NIC chooses to re-issue 392 as 394, or just change the version string (and the table) back to 394 doesn't matter. But don't just leave the wrong table out there, please. --Jim
-----------[000100][next][prev][last][first]---------------------------------------------------- Date: Mon, 22 Oct 84 22:32:52 EDT From: Doug Kingston <dpk@BRL-TGR.ARPA> To: Alan Parker <parker@NRL-CSS.ARPA> Cc: guyton@RAND-UNIX.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: ethernet terminal servers
Neat! Keep us informed... -Doug-
-----------[000101][next][prev][last][first]---------------------------------------------------- Date: Tue Oct 23 23:26:50 1984 From: Martin Lee Schoffstall <cadmus!schoff@seismo.ARPA> To: cadmus!seismo!tcp-ip@nic.ARPA Subject: terminal concentrators or terminal servers
What we are talking about is a terminal concentrator, the
equivalent of a BBN TAC for an ethernet. I'm not so sure that you
are correct about the market for servers though. You would be amazed
how many networks are connected via a RS232 line. Most people have
these; standard buses, operating systems, understandable manuals are
scarce and hence hinder (at least for a time) rational network
connections. In fact BBN has modified the C/30 TAC to ACCEPT telnet
connections and use an "available" rs232 connections port. I know at least
one site who has waited for so long for ATT to deliver a SysV ip/tcp
for their 11/70 running SysV that their TAC is configured that way.
Another has it going to their develcon??? switch.
marty
{bbncca,linus,wivax,seismo}!cadmus!schoff
cadmus!schoff@seismo.ARPA
-----------[000102][next][prev][last][first]---------------------------------------------------- Date: Wed 24 Oct 84 02:54:40-EDT From: Mark K. Lottor <MKL@MIT-XX.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: SFTP mailing list
There is now a mailing list for discussion of anything related to SFTP/RFC913. The list is: SFTP@MIT-XX All requests to be added or deleted to: SFTP-REQUEST@MIT-XX Mark -------
-----------[000103][next][prev][last][first]---------------------------------------------------- Date: Thu, 25 Oct 84 16:56 PDT From: Provan@LLL-MFE.ARPA To: tcp-ip@nic.arpa Subject: RFC810 table parsing
we're considering using the RFC810 format for our non-IP/TCP network. i'd like to hear comments on that if anyone has any, but i have more specific questions that cause me to write this note. first off, since our network is not in the Internet, it doesn't have a network number. i don't think we'll be able to convince NIC to give us a number without having a network, and i was scared off by the big long form they wanted me to fill out to get a number. what should we use in the 810 tables for our network numbers? right now we plan to use 255.x, thereby making it completely illegal (for now) in the internet world so no one could ever get confused by it. any comments? more importantly, since we're using this format, we'll need to parse it. is there any chance someone out there has a Bliss parser already written? barring that, are there any available C parsers for it we can get a hold of? don
-----------[000104][next][prev][last][first]---------------------------------------------------- Date: 25 Oct 1984 17:37:48 PDT From: POSTEL@USC-ISIF.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: re: TCP MSS Option
see also RFC 879. --jon. -------
-----------[000105][next][prev][last][first]---------------------------------------------------- Date: 25 Oct 1984 1926-EDT (Thursday) From: jnc@MIT-CSR To: tcp-ip@nic Cc: jnc Subject: TCP MSS Option
We have recently apparently been seeing problems due to certain cross-purposes in the IP and TCP specifications about the maximum segement size. (This is NOT about what size packets hosts or gateways have to accept from the local net, about which there has been much discussion; this has to do with end to end problems.) According to the IP spec, nobody is supposed to send anyone an IP packet of larger than 576 bytes without approval; see page 13 of that spec. In the case of TCP this is done via a MAX-SEG-SIZE negotiation; the wording in the TCP spec is fairly plain, and what it says is that unless you do this negotiation any segment size is acceptable. Now, taken literally, this would mean that I can send everyone 65K byte packets, unless they say otherwise. This, while perfectly acceptable under a strict interpretation of the spec, contravenes in spirit a guiding principle of TCP, enunciated on page 13: "be conserative in what you do, and be liberal in what you accept from others." My interpretation of this would be to not send TCP segments of larger than 576 bytes unless I had received from the other end a MSS option which positively told me that the destination could accept packets larger than that. The problem that happens is that the disease that happens to, e.g. mailers, when they try to send a message using 1000 bytes segments to a host that only accepts 576 byte packets, is truly awful. The connection opens OK, some data is sent, the packet is dropped at the destination host with a hardware error, is retransmitted several times, and then eventually the connection times out. The mailer marks this as a temporary error, and tries again, and again, and again, and again, etc. Some mailers (e.g. the TOPS-20 one) recognize this symptom and try the 'individually PUSHed 40 byte segments', for those of you who have seen that delightful error message, but others just keep on mindlessly trying and eventually drop the mail. I wish they had written the spec to default to 576 rather than anything, but it's a bit late now. However, can we agree to apply the Robustness Principle and chose not to excercise that option in the hopes of assuring operation? Noel -------
-----------[000106][next][prev][last][first]---------------------------------------------------- Date: 25 Oct 1984 2235-EST (Thursday) From: Christopher A Kent <cak@Purdue.ARPA> To: JNC@MIT-XX.ARPA Cc: tcp-ip@nic.ARPA Subject: Re: TCP MSS Option
Didn't Postel write something up about this very point? I have reference of <INC-PROJECT, MAX-SEG-SIZ.NLS.14>. I think it said that the deafult maximum segment size, if no negotiations are done, is 536. chris ----------
-----------[000107][next][prev][last][first]---------------------------------------------------- Date: Fri, 26 Oct 84 08:54 PDT From: BRADEN@UCLA-CCN.ARPA To: little.dcn5.arpa@UCLA-CCN.ARPA Cc: tcp-ip@sri-nic.arpa Subject: Re: Virtual Terminal Protocol
Mike, Your original message said you are "attempting to create a virtual terminal protocol (VTP) with emphasis on solving problems created by forms mode type terminals (eg-3270)." I wonder who will be the market for this VTP? The DET (Data Entry Terminal) option of TELNET was designed millenia ago to solve this problem; it seemed like a good idea, and is (as far as I know) adequate to the problem. It has never been implemented, due to the ASCII orientation of the ARPANET research community. Now that the Internet is moving into the REAL WORLD of MILNET, of course, there is a new interest in providing communication services for IBM systems. In fact, there is an implementation of DET in progress; INCO is doing it for some government agency. Meanwhile, the sites with IBM hosts in the research community are taking an end run around the problem. As pointed out in a message from Ron Natalie, the Wisconsin VM software encapsulates 3278 orders within a binary-mode TELNET stream. At UCLA, our OS/MVS version of the Internet protocols has now been extended to support this same encapsulation mode (both this effort and the Wisconsin development were sponsored by IBM). We have demonstrated interoperation between VM and MVS across the Internet, using 3278's in full-screen mode. We and Wisconsin have not yet reached complete agreement on some details of the protocol (e.g., VM and MVS differ in what they consider to be valid 3278 order codes). I expect that we will resolve these issues in the next few months, and publish an RFC defining the encapsulationof 3278's within TELNET. Undoubtedly this message will ignite a flame from some hothead on a UNIX system, to the effect that we are supporting IBM 3278's rather than interoperability of different 3278-like devices. Yes, this is a pragmatic way to support a single community of users on MILNET. It recognizes reality without endorsing it. Since the transparent 3278 operation is based upon TELNET, we are never far from an NVT. In fact, the MVS User and Server Telnet happily negotiate back and forth between normal NVT and transparent 3278 operation (one of the incompatibilities is that the VM code cannot negotiate back out, yet). I would argue that DET is just too complex, and the encapsulation mode solves what is pragmatically the real problem, in a straightforward and efficient manner. The advantage of a common protocol like DET is that is solves the "n-squared" problem of different terminals communicating with different hosts. This is a nice theoretical argument which I generally accept, but in the case of IBM 3278 support the situation is really simpler. An IBM server host is going to be accessed from a 3278 (of whatever brand name), from an ASCII CRT, or from an ASCII line terminal. Encapsulation handles the first case. For the second, there is a software conversion package (SIM/3278) which an IBM host can run to emulate a 3278 on an ASCII CRT. Finally, all IBM hosts support normal NVT access. Sometime in the future, the emergence of standards and the ability of the production side of DoD to fund large and complex sofware development efforts may make a common DET (-like) protocol implementation attractive. In the meantime, I believe the problem is under control in DDN. ------- Bob Braden
-----------[000108][next][prev][last][first]---------------------------------------------------- Date: 26 Oct 1984 10:04 PDT From: Art Berggreen <ART@ACC> To: tcp-ip@sri-nic Cc: unix-wizards@brl Subject: 4.2 RFNM count problem
Recently several people have remarked on the bug/feature in
the 4.2 IMP driver code that only resets per host RFNM counts
when a BADLEADER msg from the IMP is seen.
Has anyone implemented and TESTED a fix for this? I'd like
not to reinvent the wheel if possible. Please send me a
note or post to TCP-IP or UNIX_WIZARDS if you have such a
fix.
Also, did anyone get a definite reading on when the IMP resets
its RFNM counters?
Art Berggreen
<Art@ACC.ARPA>
"Too illiterate to have any cute quotes."
------
-----------[000109][next][prev][last][first]---------------------------------------------------- Date: 26 October 1984 1155-PDT (Friday) From: stanonik@nprdc To: tcp-ip@SRI-NIC.ARPA, unix-wizards@BRL-TGR.ARPA Subject: Re: 4.2 RFNM count problem
In response to our query about rfnm's, Bill Nesheim (cu-arpa.bill@Cornell) provided the following fix which we've installed. RCS file: RCS/if_imp.c,v retrieving revision 1.1 diff -c -r1.1 if_imp.c *** /tmp/,RCSt1017941 Fri Oct 26 11:26:49 1984 --- if_imp.c Fri Sep 21 14:16:42 1984 *************** *** 293,298 */ case IMPTYPE_RESET: impmsg(sc, "interface reset"); impnoops(sc); goto drop; --- 293,299 ----- */ case IMPTYPE_RESET: impmsg(sc, "interface reset"); + hostreset(sc->imp_if.if_net); impnoops(sc); goto drop; He said their rfnm problems disappeared, and now apparently so have ours. Of course, disappearance of the problems isn't quite the same as testing. Hitting the ecu reset button would probably be a good test, if I could think of a way of bumping up the rfnm counts (short of adb'ing /dev/kmem). I never did get a response about when the imp's clear their counts, and I couldn't find that information in bbn's 1822 report. Ron Stanonik stanonik@nprdc
-----------[000110][next][prev][last][first]---------------------------------------------------- Date: 26 Oct 84 1255 EDT (Friday) From: don.provan@CMU-CS-A.ARPA To: JNC@MIT-XX.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: TCP MSS Option
On the other hand, the "Be conservative" maxum cuts both ways, so you should be sending out the segment size option on each SYN packet. When this came up a while back, I blushed into my TCP code to add it, and it turned out to be much simpler than I thought it would be. Even though, as the other two notes pointed out, you're in the right, add it or have it added.
-----------[000111][next][prev][last][first]---------------------------------------------------- Date: Sat, 27 Oct 84 10:49:50 EDT From: Andrew Malis <malis@BBNCCS.ARPA> To: ART@acc.arpa, stanonik@nprdc.arpa Cc: tcp-ip@sri-nic.arpa, unix-wizards@brl.arpa, malis@BBNCCS.ARPA Subject: Re: 4.2 RFNM count problem
Art and Ron, The IMP always resets its RFNM counters under any of the following circumstances: 1. The IMP was restarted by the NOC. 2. The host flapped or dropped its ready line to the IMP. 3. The host went tardy to the IMP, and then recovered. All of these conditions cause the IMP to send NOPs and an Interface Reset to the host, which the host can use as a signal that RFNM counters have been reset. So, the code in Ron's message should do the trick, given that "hostreset()" does the right thing. Section 3.2 of BBN Report 1822 accurately discusses the second and third cases that I list above, but does neglect to mention that the RFNM counters are reset. Andy
-----------[000112][next][prev][last][first]---------------------------------------------------- Date: Sat, 27 Oct 84 12:25:28 EDT From: Ron Natalie <ron@BRL-TGR.ARPA> To: Provan@LLL-MFE.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: RFC810 table parsing
I'm sure theres a C parser, do to all the UNIX machines on the net. I've got one that is straight C, while BSD uses YACC (YECH). Turns out it isn't too much of a problem since UNIX already has a file whose fields are seperated by colons (/etc/passwd). -Ron
-----------[000113][next][prev][last][first]---------------------------------------------------- Date: 27 October 1984 14:25-EDT From: "Marvin A. Sirbu, Jr." <SIRBU @ MIT-MC> To: tcp-ip @ SRI-NIC Subject: TCP vs TP Class 4
About a year ago the DoD asked the National Academy of Sciences to form a panel to examine whether TCP should be abandoned in favor of the International Standards Organization's Transport Protocol-Class 4. The thought was that TP4 was more likely to get wide commercial support and thus save the DoD money in the long run by not being out of step with the commercial world. Also, all of the European NATO countries have indicated that they intend to use TP4. On the other hand, after the traumas of the switch from NCP to TCP, I'm sure no one is anxious to go through it again. The National Academy report has yet to be released, but a blurb in the Omnicom Newsletter says that the report will come out in favor of making the switch. Anybody know anything more or have any comments? Marvin Sirbu M.I.T..
-----------[000114][next][prev][last][first]---------------------------------------------------- Date: 28 Oct 84 19:51:38 EST From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> To: tcp-ip@SRI-NIC.ARPA Subject: questions about authentication server
I have just done a test implementation of RFC912 (authentication server) to allow FTP on Tops-20 to avoid the need for passwords. I have some questions and suggestions: 1) The document talks about a line of text. However it does not specifically say that the query and response end in CRLF. I have made my programs send CRLF, but accept lines terminated in CRLF or not (i.e. connection is closed after sending the last byte of data in the line). However if another implementor took the opposite interpreation, he might think I had returned a user name that included a CRLF in it. The spec should say whether the lines end in CRLF. I think they should. 2) The syntax is nnn, nnn : code : name I think the spaces are a bad idea. The document doesn't really say that the spaces are there. For all I know they could have been added by the text processor used for the manual. But whereever there is a space, we have to ask: should we accept a tab? should we accept more than one space? How about a space before the comma? I produce exactly the syntax given in the RFC, but allow for any whitespace (including none) whereever one space shows. I do not allow for a space before the comma. But I would prefer to have no spaces at all. I think that would make the syntax more likely to be uniform. Originally I suggested that this service should be done via UDP instead of TCP. I now think I was wrong, and agree with the RCP in using a TCP connection: - It turns out that Tops-20 does not support UDP, although apparently it can be faked using some low-level primitives and somebody's I/O library - TCP is probably harder to fake. Suppose somebody out there want to access my files. It wouldn't be that hard to set his interface to promiscuous mode, catch my requests to some other host, and stick in his own reply. If it got to me first, I would probably believe it. In order to do TCP, he has to handle the whole byte- stream protocol, including ACK's, in the presence of another host that is trying to do so also. The original posting sparked a brief flurry of conversation about security on Ethernet. I hate to speak about security, since I am not an expert on either that subject or on protocols. But it does seem that it is somewhat better to use a protocol like this one to verify who a user is rather than to use passwords. Obviously either can be broken. But if you use passwords, all someone has to do is monitor the net traffic, and he can pick your password out of the Ether. Once he has it, he can use it anywhere. With an authentication server, he has to produce a TCP implementation that will detect attempts to connect to another host, and then mimick that host. This is certainly a more difficult enterprise. Also, it still doesn't give him the password. He still has to use his hack whenever he wants to log in. This is more likely to be detectable. However I do agree that some sort of public-key encryption would be better yet. Probably the best idea would be for the query to have the form: port, port, random-key The random-key is there to make sure that the user can't just store up responses to commonly-used port pairs. The response would be port, port, random-key: USERID: username encrypted with that host's signature encryption (i.e. one that anyone can decrypt but no one else can produce). In our enviornment, this one piece of encryption would greatly increase security. Almost the only thing sensitive that would be on our network is people's passwords. If we can eliminate sending passwords on the Ether, and have a fairly secure alternative to indentifying people, the rest of what we do could be in the clear. I am again assuming that our average student might be able to look at what is going over the Ether, but that he would have a hard time modifying it, e.g. replacing the real copy of the authentication server with one that he has modified, as I install it on other systems. For cases where we have to use passwords (e.g. when a user is coming in via a terminal server where we cannot trust it to identify the user itself), we could have a small amount of code in the terminal server to handle passwords. The system would send a challenge of the form: random-key and the terminal server would send back random-key password encypted in a one-way encyption algorithm that mixes the random key with the password. Obviously that could be broken (e.g. by modifying the terminal server software to store away the password somewhere), but this seems like a worthwhile level of security for some environments. -------
-----------[000115][next][prev][last][first]---------------------------------------------------- Date: 28 Oct 1984 21:36-EST From: CERF@USC-ISI.ARPA To: SIRBU@MIT-MC.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: TCP vs TP Class 4
Marvin, I would imagine that DoD would find the switch attractive only insofar as the machine vendors provided software as part of their standard, supported protocol suite(s). I believe there has been some experimental work done by a number of vendors to try out TP4 and a file transfer protocol. I am not sure they incorporated an IP layer or not. Vint Cerf
-----------[000116][next][prev][last][first]---------------------------------------------------- Date: Sun, 28 Oct 84 22:56:44 est From: Alan Parker <parker@nrl-css> To: tcp-ip@nic Subject: tcp-ip mail list archive?
Does anyone archive these messages? I would like to review the messages from some time back concerning the issue of passwords on an ethernet. Thanks. -Alan
-----------[000117][next][prev][last][first]---------------------------------------------------- Date: 29 Oct 84 08:18:21 EST From: ddn-navy @ DDN1.ARPA To: SIRBU @ mit-mc.arpa Cc: tcp-ip @ sri-nic.arpa Subject: Re: TCP vs TP Class 4
The following is my own opinion and not necessarily that of the decision makers loosely referred to as DoD. MR SIRBU, It amazes me that people feel that all they have to do is implement a policy, throw the equivalent of the national debt at it, and everything will sudd- enly be beautiful. This is not the case and those who meander through life thinking it is will also tell you that there really is a Santa Claus, they believe in the Easter Bunny and at an advanced age still put their teeth under the pillow believing the tooth fairy will leave them a dime or quarter in exchange. Such is the case with the DoD and their attempt to standardize on n a level 4 transport protocol. I sell DDN, DoD's long haul datacomm net nee ARPANet. I am one of four who do and we've done such a good job that the DDN Program Mgt Office has been flooded with so many requests for service we currently have a backlog of some 800 requests for connection to the network with no end in sight. The number of requests and sizes of the subscriber systems planning to access the net is growing exponentially. There is no end in sight cause DoD mandated DDN as the only (underlined) means for services/agencies to communicate. We sold the services...we sold the subscribers...and we sold the commercial vendors. The latter is the important consideration because since 1978, when TCP became the DoD standard, we have been telling the NAVDAC's and the CSC's that their new systems must be procurred with TCP already hooked into the OS. A few got by the reviewers but more and more, the system RFP's are hitting the streets for systems with full DDN capability and the pivotal protocols continue to be IP and TCP. Most of the majors and quite a few of the minor vendors have now developed or OEM'd someone who has developed these and the upper layers and they are ready to support DDN and requests from their customer base. Cases in point -- Sperry Corp sunk $4 Million in developing their DDN X.25 interface and OEM'd Protocom for another $1 Million to do every thing from level 3U through 7. SDC-Burroughs sunk around $6 Million in their MIL/INT DDN interface and plans to support IP/TCP for another decade at least. The DDN PMO recently awarded between $3.5 and 4.5 million in developmental contracts for 8 vendors to produce full service, "generic" DDN interfaces. Again IP/TCP/FTP/TELNET/SMTP operating above X.25. It has taken 6 years but we finally have everyone looking at, if not yet singing from, the same sheet of music. The many departments of government. I will not bore you with quotes from Thomas Jefferson or Andrew Jackson that warned about government becoming so large it loses site of its purpose and serves its own interests rather than those for which it is funded. But suffice it to say that the National Academy Report will probably be published without a rejoinder from this program office telling those who read it the many problems of changing from one standard to another, even if the follow-on is better or more efficient. You mentioned the switch from NCP to TCP. This is not finished even as I write. NCP is still the transport protocol for WIN. And it is still supported in the MILNET IMP's unless the release they are testing now has finally removed it from that backbone. But don't be fooled for a minute into thinking this is the only example of government "shooting itself in the foot" by failing to look at the impact of implementing a decision. I sat in the gallery when the past Director of DCA, LTG Wm Hilsman testified that the divestiture of ATT would cause untold havoc on expanding and managing the DCS...that the lack of a competent end- to-end carrier would damage our national security and he could not guarantee to the Congress that the DCS would be reconstitutable once the Bell System was broken up. I don't think I'll get many arguments from my readers the sum of the parts are anything nearly equal to the original whole of the old Bell System. And so it goes with standards. Once we had none and different computer architectures found it difficult to communicate among themselves. Now we have them, but we have so many because we really only have recommendations instead of standards, that the same thing still holds true. We commented on the National Academy's report when it was still a draft. Our concerns centered around what it would do to this program to introduce still another "standard." At that time we were going through the exercise of choosing X.25/HDLC over 1822/HDH or DH as the recommended connection protocol. X.25 won because there were so many X.25 interfaces available "off the shelf." Our current hardware/software/ network monitoring base has all it can do to support the many level 3 connect ct- ions we ask it to support -- X.25/HDLC; 1822/HDH; or 1822 DH w/ECU's. To impose an additional level 4 protocol across, but not necesarily on, the net, we feel, would add an untold amount of additional overhead to a system already saturated with "non data bearing" packets. There is also the problem of monitoring center, MILDEP and industry support for a protocol billed as the new "standard" but with no track record save for the experiments at University College London and the U of Germany. Let's hope that we all learned something from the NCP --> TCP and 1822 -->X25 exercises. My biggest fear is that someone at DoD who writes policy letters will take the Ntl Academy Report and sign out policy directing us to support TP in DDN by 4th quarter FY86 or something absurd like that. We should look at adopting it only after it's left academia and has the support of industry. After all, it's commercial, not academic, systems that we are connecting to the net these days. ----------------- If you'd like to look at the Transport Protocol, you can FTP it from SRI-NIC by calling for <RFC> 904. The current TCP is filed under <RFC> 793. I'd like to close by saying that those of us who reviewed TP 12 or 14 months ago all agreed that it's a better end-to-end protocol than the current TCP. Our only real concerns were how we would support it on the net (minor); how we'd sell it to the subscriber community (intermediate); and whether or not it would gain widespread industry support (major). We could support it on the net in 2 years if the word came down to do so. It would take a lot longer to sell it to our users or to IBM, Sperry, DEC, Honeywell, Burroughs et al, I'm afraid. Rod Richardson sends Navy Systems Implementor DDN Program Mgt Office
-----------[000118][next][prev][last][first]---------------------------------------------------- Date: 29 Oct 1984 10:52 PDT From: Art Berggreen <ART@ACC> To: jeff@aids-unix Cc: tcp-ip@sri-nic,unix-wizards@brl Subject: 4.2 IF-11/HDH Driver
To any interested parties,
A Beta release of a 4.2BSD device driver for ACC's IF-11/HDH is
available from ACC. The IF-11/HDH is the UNIBUS frontend which
implements the HDLC-Host (1822 appendix J) IMP Interface for
modem connected hosts.
Since we don't normally run our FTP daemon, anyone interested
should contact me directly at ACC for a copy. I'll either
FTP it to your site, mail it to your site, or if needed send
a magtape.
ARPANET: Art@ACC.ARPA
Phone: (805) 963-9431 (Hard to catch this way)
Art Berggreen
Advanced Computer Communications
<Art@ACC.ARPA>
------
-----------[000119][next][prev][last][first]---------------------------------------------------- Date: Mon 29 Oct 84 12:27:26-PST From: David Roode <ROODE@SRI-NIC.ARPA> To: TCP-IP@SRI-NIC.ARPA Subject: TCP-IP list archives
These files are available for FTP from any Internet site. FTP them from SRI-NIC.ARPA logging in as ANONYMOUS with password GUEST. The MAIL.TXT file contains the most recent messages. filename disk char. date last written pages count PS:<TCP-IP>TCP-IP.1982.1 30 76060(7) 10-May-84 17:43:31 HSS PS:<TCP-IP>TCP-IP.1983.3 192 491285(7) 11-May-84 14:28:10 HSS PS:<TCP-IP>TCP-IP.1984A.1 158 404296(7) 27-Oct-84 13:07:56 ROODE PS:<TCP-IP>MAIL.TXT.1 139 353894(7) 29-Oct-84 11:05:46 tcp-ip-RELAY Total of 519 pages in 4 files -------
-----------[000120][next][prev][last][first]---------------------------------------------------- Date: 29 Oct 1984 10:34-EST From: DESJARDINS@USC-ISI.ARPA To: SIRBU@MIT-MC.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: TCP vs TP Class 4
Marvin, I think Vint Cerf's comment is right on the mark. The whole point of the ISO protocol suite is to provide an "electropolitically" acceptable specification which the manufacturers will build into their standard, supported communications offerings. It will not save the DoD any money to have to pay vendors specially to implement ISO protocols and then have to pay again and again to support them. That is what the vendors should be doing; they're the ones that gain from universally "open" interconnection, by the radical expansion of the communications market and the radical facilitation of information services markets. At the NCC in July, the NBS and GM cosponsored a demonstration of ISO TP4 and an FTP subset over two types of local networks, CSMA/CD (IEEE 802.3) and token bus (IEEE 802.4). More than a dozen manufacturers, including IBM and DEC, participated, and by all accounts, the demonstration was very successful. NBS is now planning to sponsor an Internet based demonstration in 1985, using ISO Draft International Standard 8473, the ISO equivalent of IP. Obviously, the issue here is not a technical one, since the ISO protocols are technically similar to the DoD protocols (after all, ISO Transport Protocol Class 4, now part of International Standard 8073, was based on TCP, and the ISO Protocol for Providing the Connectionless-mode Network Service (DIS 8473) was based on IP). The issue is to specify a protocol that all the manufacturers will agree to support. Since all the major manufacturers are now multinational manufacturers, they want to develop globalized products which they can sell in Europe and Asia as well as in North America. IBM is said to have announced that they will offer the ISO Transport Protocol operating over X.25 in Europe, just as they offered X.25 support in Europe two years ago. And of course, the European manufacturers, such as Siemens, Bull, and ICL, want to be able to compete in the U.S. market, and they are going to pressure their governments to lock out the American companies if the Americans lock them out. (IBM just settled a major lawsuit with the European Economic Community involving in part this issue.) The bottom line is that Vint Cerf is exactly right: ISO protocols will only be attractive when they are offered as a standard part of every manufacturer's product line. --Dick desJardins
-----------[000121][next][prev][last][first]---------------------------------------------------- Date: 29 Oct 1984 17:19:10 PST From: POSTEL@USC-ISIF.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: re: TP4 vs. TCP
Well, i for one, do not believe that ISO TP4 is as good as TCP. --jon. -------
-----------[000122][next][prev][last][first]---------------------------------------------------- Date: 29 Oct 84 1915 EST (Monday) From: don.provan@CMU-CS-A.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: TP4 vs. TCP
So now it's generally agreed that the ISO protocols will be at least as good as IP/TCP? What happened to all the apartment building/parking structure and created by commitee arguments? What about the problems with not being able to have two protocols on the same level a la TCP/UDP? Have all of these shortcomings been solved or are we just listening to the people already convinced that ISO is good? I've heard that DoD will inevitably go to ISO, but this is the first time I've heard that the only issue is the conversion.
-----------[000123][next][prev][last][first]---------------------------------------------------- Date: 29 Oct 1984 21:47-EST From: CERF@USC-ISI.ARPA To: POSTEL@USC-ISIF.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: re: TP4 vs. TCP
In the end, it often turns out to be the case that the principal issue in selecting a protocol is not its absolute "goodness" but by whom it has been implemented and what it supports in the way of applications or other protocols. Consider 1822 vs X.25 - 1822 has served DoD well since 1968. It is only recently that enough widespread X.25 implementations have made it worthwhile to consider its use as well. There will be some applications which X.25 supports less well than 1822, owing to the latter's datagram-like interface, but for a large number of cases, X.25 will probably work out quite acceptably. A more serious concern may be system security - since the CCITT/ISO TP4/IP protocols have not been developed with system security in mind, so far as I know. It may be quite a while before DoD will even know if they work, let alone be able to apply these protocols in an end/end secure application. Like 1822, TCP/IP and the other Internet protocols will probably be with us, serving DoD well, for a good long time. In the meantime, it is fair for us to recognize that international standards are important - even to the U.S. Defense Department. We cannot ignore things, but on purely economic and management grounds, one would expect motion towards the adoption of international standards to be paced by feasibility and cost constraints and possibly technical/functional constraints. Vint Cerf
-----------[000124][next][prev][last][first]---------------------------------------------------- Date: 30 Oct 1984 18:06-EST From: DESJARDINS@USC-ISI.ARPA To: don.provan@CMU-CS-A.ARPA Cc: tcp-ip@SRI-NIC.ARPA Subject: Re: TP4 vs. TCP
You have to be careful about the "created by committee" argument. Generally it's valid, because it's applied to cases where design integrity is the issue. And for design integrity, nothing beats a single design team (unless it's a single mind). And there are going to be many ISO (or any other) protocols, just to be specific, which suffer from being "created by committee". But the protocols being discussed, TP4 and Connectionless Network, are just "improved" (a legitimate issue, to be sure) versions of TCP and IP, created by the NBS and BBN (ask John Heafner at NBS what their heritage is and what technical "improvements" were made) in a single design team. Other "improvements" were in the more formal specification style used, and in the political compromises which made it acceptable worldwide, which is a not inconsiderable improvement if that's a goal. Regarding conversion, you can keep your own protocols and do it with gateways (which is the approach to be taken by IBM SNA) or you can change out your protocols (which is the approach to be taken by DEC), but somehow DOD networks will have to interoperate with other networks -- the DOD situation is no different from the SNA situation in this respect. I believe this is the essence of the conversion discussion, that it will have to be done some time, some how, whether with gateways or by changeout, and the discussion is about when and how. And please -- just because someone believes that "ISO is a good thing" doesn't make her (or him) unthoughtful! --Dick dJ (P.S. A camel will beat a horse if the sand on the track is loose enough and deep enough.)
-----------[000125][next][prev][last][first]---------------------------------------------------- Date: Thu, 1 Nov 84 00:12:48 -0200 From: barkan%wisdom.BITNET@Berkeley (Yirmiyahu Barkan) To: tcpip-list%wisdom.BITNET@Berkeley, vax-list%wisdom.BITNET@Berkeley Subject: vt220
does anyone have a termcap for a VT220, or any of the VT200 series ? does anyone know when dec will give full support for the vt200 series on VMS ( ie - not until release 4.0 ) thanks - yb Yirmiyahu Barkan barkan@wisdom.bitnet
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |