----MESSAGE-BEGIN---- [8704011439.AA23779%40mitre.ARPA] <1987040104395200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Peak User Estimate Message-ID: <8704011439.AA23779@mitre.ARPA> Date: Wed, 1-Apr-87 09:39:52 EST Article-I.D.: mitre.8704011439.AA23779 Posted: Wed Apr 1 09:39:52 1987 Date-Received: Sat, 4-Apr-87 06:12:09 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The MITRE Corp., Washington, D.C. Lines: 18 Approved: tcp-ip@sri-nic.arpa Based on some envelope calculations, described below, I estimate that the peak number of simultaneous users is 10% of the potential users. Is this estimate in accord with your experience? The system I use here at MITRE is a VAX 8600 running Ultrix. I have recently had occasion to be interested in the peak number of simultaneous users as a percentage of the number of possible users. So, on 24 March, I copied the /usr/users file and found 551 entries, some of which had not logged-in since 1985! Recognizing that some user accounts simply forward mail to another system, I deleted every entry whose last login was 28 February, or earlier. That left 191 users that had logged-in at least once during the period 1-24 March. Over the past several months I have, at unplanned intervals, run the Unix "who" command that lists all logged-in users. The usual response is 10 to 15 users; very rarely does the number equal or exceed 20. The estimate made above follows from this data. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D.1-Apr-87.10:15:10.GBELING] <1987040105150000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GBELING@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: IP over x.25 Message-ID: <[A.ISI.EDU].1-Apr-87.10:15:10.GBELING> Date: Wed, 1-Apr-87 10:15:00 EST Article-I.D.: <[A.ISI.EDU].1-Apr-87.10:15:10.GBELING> Posted: Wed Apr 1 10:15:00 1987 Date-Received: Sat, 4-Apr-87 05:40:42 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 34 Approved: tcp-ip@sri-nic.arpa hello collegues, we are running here a connection to the arpanet using the PTT's datex-p (i.e. x.25) as a transatlantic transport medium. To do so we have connected TELNET/TCP/IP over x.25 i.e. encapsulated the IP datagrams into x.25-packets. Up to some time ago this worked fairly well and reliable and fast (up to 2.000 bps over a 4.8 kb/s "line"). We reach the arpanet at the van-gateway in boston. Since heavy congestion occurs in the arpa/milnet we have a special poroblem: If for some reason the x.25 virtual connection is idle for 2 minutes the van-gateway closes the connection and cannot reopen it: we have to do this because we have to pay the x.25 charges. In the case that we are reading data from the other side and have acked all segments properly the connection is broken and our TCP has to wait until the user timeout cancels the (tcp) connection on our side - what the far-end tcp does we do not know. This happens sometimes when the far tcp does not do retransmissions or so slowly that in the intermediate time x.25 cuts us off. Ip is developed for the case that the underlying connection is a permannt available one i.e. no open or close needed ! If we look to the protocol suite properly there is no way to signal the broken x.25 connection to the user of telnet so that he can react. therefore we think of to reopen the x.25 VC automatically when the other side closes it. this has the disadvantage that we reopen it also when the tcp-connection has finished because x.25 does not know something about tcp-connections. The peculiar problem is that we have to pay for each OPEN of a VC (and afterwards for the time it is open: 5pfg for each open, 15pfg per minute). The problem will become even more complicated when several tcp-connections are multiplexed onto one x.25-virtual circuit or there are several x.25 VCs open at the same time. How did others solve the problem to reopen broken x.25VCs when a tcp-connection to close the connection? thanks gerd beling ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040105150001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 1 Apr 87 07:15:27-PST Date: 1 Apr 1987 10:15-EST Sender: GBELING@A.ISI.EDU Subject: IP over x.25 From: GBELING@A.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 1-Apr-87 10:15:10.GBELING> hello collegues, we are running here a connection to the arpanet using the PTT's datex-p (i.e. x.25) as a transatlantic transport medium. To do so we have connected TELNET/TCP/IP over x.25 i.e. encapsulated the IP datagrams into x.25-packets. Up to some time ago this worked fairly well and reliable and fast (up to 2.000 bps over a 4.8 kb/s "line"). We reach the arpanet at the van-gateway in boston. Since heavy congestion occurs in the arpa/milnet we have a special poroblem: If for some reason the x.25 virtual connection is idle for 2 minutes the van-gateway closes the connection and cannot reopen it: we have to do this because we have to pay the x.25 charges. In the case that we are reading data from the other side and have acked all segments properly the connection is broken and our TCP has to wait until the user timeout cancels the (tcp) connection on our side - what the far-end tcp does we do not know. This happens sometimes when the far tcp does not do retransmissions or so slowly that in the intermediate time x.25 cuts us off. Ip is developed for the case that the underlying connection is a permannt available one i.e. no open or close needed ! If we look to the protocol suite properly there is no way to signal the broken x.25 connection to the user of telnet so that he can react. therefore we think of to reopen the x.25 VC automatically when the other side closes it. this has the disadvantage that we reopen it also when the tcp-connection has finished because x.25 does not know something about tcp-connections. The peculiar problem is that we have to pay for each OPEN of a VC (and afterwards for the time it is open: 5pfg for each open, 15pfg per minute). The problem will become even more complicated when several tcp-connections are multiplexed onto one x.25-virtual circuit or there are several x.25 VCs open at the same time. How did others solve the problem to reopen broken x.25VCs when a tcp-connection to close the connection? thanks gerd beling ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704011558.AA12735%40ucbvax.Berkeley.EDU] <1987040105484600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: interesting new product I ran across Message-ID: <8704011558.AA12735@ucbvax.Berkeley.EDU> Date: Wed, 1-Apr-87 10:48:46 EST Article-I.D.: ucbvax.8704011558.AA12735 Posted: Wed Apr 1 10:48:46 1987 Date-Received: Sat, 4-Apr-87 05:36:42 EST References: <12290940173.15.ROMKEY@XX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa John, Sounds like it has almost allof the features one could use! But, as Billy Brackenridge would say:" PRICE IS TECHNICAL INFORMATION. So, let me know by the drop deadline and I'll order up a bunch. Dan PS. I really hope you don't run out of those EBCDIC decoder rings... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040105484601> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 1 Apr 87 07:51:38-PST Date: 1 Apr 1987 10:48:46 EST Subject: Re: interesting new product I ran across From: Dan Lynch To: John Romkey cc: tcp-ip@SRI-NIC.ARPA, pcip@LOUIE.UDEL.EDU, LYNCH@A.ISI.EDU In-Reply-To: <12290940173.15.ROMKEY@XX.LCS.MIT.EDU> John, Sounds like it has almost allof the features one could use! But, as Billy Brackenridge would say:" PRICE IS TECHNICAL INFORMATION. So, let me know by the drop deadline and I'll order up a bunch. Dan PS. I really hope you don't run out of those EBCDIC decoder rings... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040109255700> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Wed 1 Apr 87 01:33:03-PST Received: from ucl-cs-pyr1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa03568; 1 Apr 87 9:31 WET To: Chris Perry cc: tcp-ip@sri-nic.arpa Subject: Re: talking of and to gateways and bridges In-reply-to: Your message of Tue, 31 Mar 87 16:41:20 -0500. <8703312141.AA25608@bert.mitre.org> Date: Wed, 01 Apr 87 09:25:57 +0000 From: Jon Crowcroft Chris, ROS stands for Remote OperationS, and REX stands for Remote EXexcution. They are part of the ECMA (European Computer Manufacturers Association) input to draft standards work on distributed computing. REX is a Birrel & Nelson type 'minimum packet' transaction transport protocol, whilst ROS uses ASN (Abstract Sysntax Notation) as a presentation layer to to define call/reply/error messages and parameters and to provide machine independance of call and reply parameter representation. The ANSA (Advanced Network Systems Architecture) research group have put a lot of work into their design. The goal is to provide a system where code for client/server model interactions may be generated automatically (RPC type work), but to allow for other types of interaction too. jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1406.rbbb.proserpina%40Rice] <1987040112404900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rbbb@rice.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Mail "direct to machines" Message-ID: <1406.rbbb.proserpina@Rice> Date: Wed, 1-Apr-87 17:40:49 EST Article-I.D.: Rice.1406.rbbb.proserpina Posted: Wed Apr 1 17:40:49 1987 Date-Received: Sat, 4-Apr-87 11:16:40 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa narten@purdue.edu says: > mailbox. Presumably, as domain names get extended, we will be able to > do that. Any mail you send to a user can go directly to the machine > where the his/her mailbox resides. No forwarding at the site would be > needed. I may misunderstand you, but how can you tell where my mailbox resides? If you look at my "Message-Id", you might guess that you could send to "rbbb@proserpina.rice.edu", and you would be wrong. I read my mail at "titan.rice.edu", but you should just send it to "rice.edu", and let it be forwarded to whereever I happen to currently live. It is difficult to propagate precise information about my whereabouts to ALL the machines on our net, and much more difficult when you consider that I am certainly not the only user here. It is much much simpler to have every machine except the one where my mailbox resides boot my mail to "rice.edu", and let "rice.edu" forward it to my home. Obviously, we take great pains to keep rice.edu up and running, but it is no more vital than our gateway, our line to the IMP in Austin, or the IMP itself. I don't see how extended domain names will help this. David ----MESSAGE-END---- ----MESSAGE-BEGIN---- [574285707.A0084.KSL-1186-4.Crispin%40SUMEX-AIM.Stanford.EDU] <1987040113023500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Crispin@SUMEX-AIM.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: totally cretinous domain lossage Message-ID: <574285707.A0084.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU> Date: Wed, 1-Apr-87 18:02:35 EST Article-I.D.: SUMEX-AI.574285707.A0084.KSL-1186-4.Crispin Posted: Wed Apr 1 18:02:35 1987 Date-Received: Sat, 4-Apr-87 08:27:09 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa A major Internet mailing list failed today because the domain system is broken for hosts in Norway. Specifically, the hosts that were named OSLO-VAX.ARPA and NTA-VAX.ARPA have IN-ADDR records on their host addresses that return the names ifi.UIO.NO and tor.NTA.NO respectively. However, the domain system does not recognize either of the mumble.NO names! I sure to hell wish that organizations would coordinate their IN-ADDR entries with their name entries. Please don't tell me not to use IN-ADDR entries -- I know it's a kludge and as soon as the developers of the TOPS-20 domain software give me a "translate name to fully-qualified domain name" function I'll use it. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040114014100> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Wed 1 Apr 87 06:22:09-PST Received: from BARILVM.BITNET by wiscvm.wisc.edu on 04/01/87 at 08:20:13 CST Received: by BARILVM (Mailer X1.23b) id 3794; Wed, 01 Apr 87 10:54:06 O Date: Wed, 01 Apr 87 10:31:41 O From: Henry Nussbacher Subject: Remote access in Bitnet To: tcp-ip@sri-nic.ARPA (Caveat - This description is primarily for people who have no idea how Bitnet works.) Greg, The concept of remote access doesn't exist in Bitnet. The protocols in Bitnet are as follows: 1) One-way File Transfer - any user is allowed to send a file to any other user. Since the file ends up in the destination users spool system (or some emulation thereof) there is no problem with access control. 2) Interactive Message - any user can send a one line message (max 160 characters) to any other user. All you need to know is the destination user and node. If the user is not logged on or a link is down you are told so. Based on these two primitives - Bitnet has built various other pseudo-protocols. From #1 above - we are able to do mail, list explosion, computer conferencing, general file transfer. From #2 above, Bitnet has developed a CB (Chat) system. By combined both of the basic primitives above, a file server can be set up at any node that will trap incoming 'Interactive Messages' - which contain a command and process the command and send the results back to the user via the 'One-Way File Transfer' mechanism. This method allows users to sit at their machine and issue commands like DIR or LIST to some remote file server and then issue some SEND commands to retrieve the files they want. There is no need in that case to do any sort of remote connect (anonymous FTP). Most servers (200+) in Bitnet also accept transactions via files or RFC822 mail. Lately, various servers in Arpanet have decided that is also a 'clever' thing to have, so we have things like archive-request@simtel20.arpa and service@sri-nic.arpa popping up (I expect more before the end of th year). So to answer your question: > a remote file they own They cannot access it. Yup would be nice and that is just one reason why Bitnet should convert to Tcp/Ip. Incidentally, there is a program I distribute in Bitnet that allows this remote access to a file the person owns but it is a private convention. The program runs as a task (and therefore must be running when the remote user wants access to his/her files). and the user needs to set up a remote access password. It uses the Interactive Message Primitive to send and receive data, and each command you want executed on the remote host must be prefixed with your remote pswd. Not as elegent as TELNET but when the entire concept of TELNET doesn't exist it is the best one can do. > a remote file they don't own, but is not protected Only if the file is available via a remote file server can they access it. > a remote file they don't own, but is protected They can't access it. Hope this helps. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D.1-Apr-87.20:31:12.CERF] <1987040115310000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <[A.ISI.EDU].1-Apr-87.20:31:12.CERF> Date: Wed, 1-Apr-87 20:31:00 EST Article-I.D.: <[A.ISI.EDU].1-Apr-87.20:31:12.CERF> Posted: Wed Apr 1 20:31:00 1987 Date-Received: Sat, 4-Apr-87 10:16:52 EST References: <12289526116.32.GROSSMAN@Sierra.Stanford.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Stu, one little observation. A single collision in your tapemobile would do rather more damage than the typical collision on an ethernet. Shows why putting all your bits in one packet isn't a good policy... Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040115310001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 1 Apr 87 17:36:34-PST Date: 1 Apr 1987 20:31-EST Sender: CERF@A.ISI.EDU Subject: Re: Station wagon full of bits From: CERF@A.ISI.EDU To: GROSSMAN@SIERRA.STANFORD.EDU Cc: imagen!apolling!geof@DECWRL.DEC.COM Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 1-Apr-87 20:31:12.CERF> In-Reply-To: <12289526116.32.GROSSMAN@Sierra.Stanford.EDU> Stu, one little observation. A single collision in your tapemobile would do rather more damage than the typical collision on an ethernet. Shows why putting all your bits in one packet isn't a good policy... Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D.1-Apr-87.21:16:44.CERF] <1987040116160000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <[A.ISI.EDU].1-Apr-87.21:16:44.CERF> Date: Wed, 1-Apr-87 21:16:00 EST Article-I.D.: <[A.ISI.EDU].1-Apr-87.21:16:44.CERF> Posted: Wed Apr 1 21:16:00 1987 Date-Received: Sat, 4-Apr-87 10:17:05 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Bob, just came across your message about the station wagon full of bits - amazing! You and I had nearly the identical reaction as you'll see when you read TCP-IP and catch my message [sometimes I think I should read my mail backwards...]. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040116160001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 1 Apr 87 18:20:55-PST Date: 1 Apr 1987 21:16-EST Sender: CERF@A.ISI.EDU Subject: Re: Station wagon full of bits From: CERF@A.ISI.EDU To: hinden@CCV.BBN.COM Cc: GROSSMAN@SIERRA.STANFORD.EDU, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 1-Apr-87 21:16:44.CERF> In-Reply-To: The message of 28 Mar 87 10:08:11 EST (Sat) from Robert Hinden Bob, just came across your message about the station wagon full of bits - amazing! You and I had nearly the identical reaction as you'll see when you read TCP-IP and catch my message [sometimes I think I should read my mail backwards...]. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D.1-Apr-87.21:28:17.CERF] <1987040116280000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Station wagon full of bits Message-ID: <[A.ISI.EDU].1-Apr-87.21:28:17.CERF> Date: Wed, 1-Apr-87 21:28:00 EST Article-I.D.: <[A.ISI.EDU].1-Apr-87.21:28:17.CERF> Posted: Wed Apr 1 21:28:00 1987 Date-Received: Sat, 4-Apr-87 10:17:16 EST References: <8703271845.AA29686@mitre.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa One of the important features of X.25 and other packet-oriented services (and of DOD TCP/IP or ISO TP/IP, etc.) is the ability to support many simultaneous virtual connections. The ISDN facilities will not replace that functionality if level 3 is erased and only level 2 remains and only supports a single connection at a time. ISDN does provide for a packet mode interface which is basically a level 3 construct. I do not see that the pt-pt 64 kb/s service from ISDN will render the multi-connection modes of operation useless. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040116280001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 1 Apr 87 18:28:35-PST Date: 1 Apr 1987 21:28-EST Sender: CERF@A.ISI.EDU Subject: Re: Station wagon full of bits From: CERF@A.ISI.EDU To: mckee@MITRE.ARPA Cc: tcp-ip@SRI-NIC.ARPA, m15368%mwvm@MITRE.ARPA Message-ID: <[A.ISI.EDU] 1-Apr-87 21:28:17.CERF> In-Reply-To: <8703271845.AA29686@mitre.ARPA> One of the important features of X.25 and other packet-oriented services (and of DOD TCP/IP or ISO TP/IP, etc.) is the ability to support many simultaneous virtual connections. The ISDN facilities will not replace that functionality if level 3 is erased and only level 2 remains and only supports a single connection at a time. ISDN does provide for a packet mode interface which is basically a level 3 construct. I do not see that the pt-pt 64 kb/s service from ISDN will render the multi-connection modes of operation useless. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D.1-Apr-87.21:32:29.CERF] <1987040116320000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ICMP message caching Message-ID: <[A.ISI.EDU].1-Apr-87.21:32:29.CERF> Date: Wed, 1-Apr-87 21:32:00 EST Article-I.D.: <[A.ISI.EDU].1-Apr-87.21:32:29.CERF> Posted: Wed Apr 1 21:32:00 1987 Date-Received: Sat, 4-Apr-87 10:17:27 EST References: <8703291428.AA29318@brillig.umd.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Steve, there will be some howls, but I think the idea of ICMP caching to be worth exploring. We are surely in agreement that the more knowledge you can obtain about the Internet condition, the better you can, at the source, make decisions about traffic routing, retransmission, attempts to set-up connections, etc. I am sure this subject has come up before - some folks were uncomfortable because it seemed to smack of protocol boundary crossing - Dave mIlls mentioned a similar idea relative to caching such information th the gateways, too. Let's see what comments your notion uncovers! Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040116320001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 1 Apr 87 18:33:33-PST Date: 1 Apr 1987 21:32-EST Sender: CERF@A.ISI.EDU Subject: Re: ICMP message caching From: CERF@A.ISI.EDU To: steve@BRILLIG.UMD.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 1-Apr-87 21:32:29.CERF> In-Reply-To: <8703291428.AA29318@brillig.umd.edu> Steve, there will be some howls, but I think the idea of ICMP caching to be worth exploring. We are surely in agreement that the more knowledge you can obtain about the Internet condition, the better you can, at the source, make decisions about traffic routing, retransmission, attempts to set-up connections, etc. I am sure this subject has come up before - some folks were uncomfortable because it seemed to smack of protocol boundary crossing - Dave mIlls mentioned a similar idea relative to caching such information th the gateways, too. Let's see what comments your notion uncovers! Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D.1-Apr-87.21:36:07.CERF] <1987040116360000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network Message-ID: <[A.ISI.EDU].1-Apr-87.21:36:07.CERF> Date: Wed, 1-Apr-87 21:36:00 EST Article-I.D.: <[A.ISI.EDU].1-Apr-87.21:36:07.CERF> Posted: Wed Apr 1 21:36:00 1987 Date-Received: Sat, 4-Apr-87 10:17:40 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Hank, we didn't do it because I think we didn't think it was necessary but that's because we started with just one network and tried to extend the earlier services to the Internet. The mail forwarders are really store/forward when you think about it. Also, you need all the mechanisms for error reporting that the mail system has in it to recover from failures. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040116360001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 1 Apr 87 18:37:06-PST Date: 1 Apr 1987 21:36-EST Sender: CERF@A.ISI.EDU Subject: Re: Tcp/Ip vs a store & forward network From: CERF@A.ISI.EDU To: HANK%BARILVM.BITNET@WISCVM.WISC.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 1-Apr-87 21:36:07.CERF> In-Reply-To: The message of Sun, 29 Mar 87 15:48:42 O from Henry Nussbacher Hank, we didn't do it because I think we didn't think it was necessary but that's because we started with just one network and tried to extend the earlier services to the Internet. The mail forwarders are really store/forward when you think about it. Also, you need all the mechanisms for error reporting that the mail system has in it to recover from failures. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D.1-Apr-87.21:44:04.CERF] <1987040116440000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: <[A.ISI.EDU].1-Apr-87.21:44:04.CERF> Date: Wed, 1-Apr-87 21:44:00 EST Article-I.D.: <[A.ISI.EDU].1-Apr-87.21:44:04.CERF> Posted: Wed Apr 1 21:44:00 1987 Date-Received: Sat, 4-Apr-87 11:56:30 EST References: <3476.544130860@UK.AC.UCL.CS> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Steve (Kille), I merely wanted to point out that you need something above the X.25 level to do recovery, if you care, after a reset. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040116440001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 1 Apr 87 18:47:09-PST Date: 1 Apr 1987 21:44-EST Sender: CERF@A.ISI.EDU Subject: Re: GOSIP vs TCP/IP From: CERF@A.ISI.EDU To: Steve.Kille@CS.UCL.AC.UK Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 1-Apr-87 21:44:04.CERF> In-Reply-To: <3476.544130860@UK.AC.UCL.CS> Steve (Kille), I merely wanted to point out that you need something above the X.25 level to do recovery, if you care, after a reset. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D.1-Apr-87.21:58:51.CERF] <1987040116580000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Peak User Estimate Message-ID: <[A.ISI.EDU].1-Apr-87.21:58:51.CERF> Date: Wed, 1-Apr-87 21:58:00 EST Article-I.D.: <[A.ISI.EDU].1-Apr-87.21:58:51.CERF> Posted: Wed Apr 1 21:58:00 1987 Date-Received: Sat, 4-Apr-87 11:57:02 EST References: <8704011439.AA23779@mitre.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa 10% represents a high usage rate. MCI Mail had 16000 users/VAX but only a small % (0.5-1%) were ever trying to get on at once. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040116580001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 1 Apr 87 18:59:20-PST Date: 1 Apr 1987 21:58-EST Sender: CERF@A.ISI.EDU Subject: Re: Peak User Estimate From: CERF@A.ISI.EDU To: mckee@MITRE.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 1-Apr-87 21:58:51.CERF> In-Reply-To: <8704011439.AA23779@mitre.ARPA> 10% represents a high usage rate. MCI Mail had 16000 users/VAX but only a small % (0.5-1%) were ever trying to get on at once. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704020606.AA11520%40spam.istc.sri.com] <1987040120213300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chris@SPAM.ISTC.SRI.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: New source for Imagen laser printer memory boards. Message-ID: <8704020606.AA11520@spam.istc.sri.com> Date: Thu, 2-Apr-87 01:21:33 EST Article-I.D.: spam.8704020606.AA11520 Posted: Thu Apr 2 01:21:33 1987 Date-Received: Sat, 4-Apr-87 09:11:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa I, recently had the oppertunity to evaluate a memory board for the Imagen IP/II processors. Since this is the first I had heard of an alternative source for Imagen memory I thought I'd share the info with the net. The company's name is Kortex Systems and incase you want to contact them their phone numbers are (415)-961-4411 or (415)-969-4053. They sell both a 4 meg and a 3 Meg board, I tried out the 4 Meg board in our 8/300 and our 3320 Imagen printers, both printers sit on our local ether net. In the past large jobs (100+ pages) would come out in reverse order and you would have to collilate the pages manually, with the 4 meg board in the system I couldn't find a listing large enough to use up all of the memory. We used the board in both systems for a week and saw no problems with it. The 4 Meg board retails for $1795 with discouts for non-profit and educational groups. The last time I checked the largest board Imagen sold was a 3 Meg one and it was going for $1900. Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704021229.AA15774%40jupiter.mitre.org] <1987040202292800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@GATEWAY.MITRE.ORG.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Packet network reliability Message-ID: <8704021229.AA15774@jupiter.mitre.org> Date: Thu, 2-Apr-87 07:29:28 EST Article-I.D.: jupiter.8704021229.AA15774 Posted: Thu Apr 2 07:29:28 1987 Date-Received: Sat, 4-Apr-87 13:49:37 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa > BBN gets around these two disadvantages at a cost. The Milnet for instance > is gettingvery large, very fast. I don't know the formula for computing the > amount of bandwidth required for the internal routing updates, but I would > suspect it would go up exponentially with the number of nodes(and connectivity > of them). If anybody knows the numbers I'd like to have them. BBN C-30 based networks use an efficient flooding scheme to send routing updates. Each update crosses each link twice, the second time as a robust acknowledgement. Link overhead is therefore linear with the number of nodes. Better still, the algorithm they use to compute routes when a change is received performs on the order of the average hop length of all paths, estimated at log N/log(c-1) where N is number of nodes and c is connectiviey. See paper by John McQuillan, Ira Richer, and Eric Rosen, "The New Routing Algorithm for the ARPANET," IEEE Transactions on Communications, Vol. COM-28, No. 5, May 1980. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704021303.AA03136%40ucbvax.Berkeley.EDU] <1987040202570400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@BARILVM.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Bitnet protocols Message-ID: <8704021303.AA03136@ucbvax.Berkeley.EDU> Date: Thu, 2-Apr-87 07:57:04 EST Article-I.D.: ucbvax.8704021303.AA03136 Posted: Thu Apr 2 07:57:04 1987 Date-Received: Sat, 4-Apr-87 13:51:31 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 65 Approved: tcp-ip@sri-nic.arpa I sent this yesterday and I never saw it come back so I have a feeling it got lost on its way: (Caveat - This description is primarily for people who have no idea how Bitnet works.) Greg, The concept of remote access doesn't exist in Bitnet. The protocols in Bitnet are as follows: 1) One-way File Transfer - any user is allowed to send a file to any other user. Since the file ends up in the destination users spool system (or some emulation thereof) there is no problem with access control. 2) Interactive Message - any user can send a one line message (max 160 characters) to any other user. All you need to know is the destination user and node. If the user is not logged on or a link is down you are told so. Based on these two primitives - Bitnet has built various other pseudo-protocols. From #1 above - we are able to do mail, list explosion, computer conferencing, general file transfer. From #2 above, Bitnet has developed a CB (Chat) system. By combined both of the basic primitives above, a file server can be set up at any node that will trap incoming 'Interactive Messages' - which contain a command and process the command and send the results back to the user via the 'One-Way File Transfer' mechanism. This method allows users to sit at their machine and issue commands like DIR or LIST to some remote file server and then issue some SEND commands to retrieve the files they want. There is no need in that case to do any sort of remote connect (anonymous FTP). Most servers (200+) in Bitnet also accept transactions via files or RFC822 mail. Lately, various servers in Arpanet have decided that is also a 'clever' thing to have, so we have things like archive-request@simtel20.arpa and service@sri-nic.arpa popping up (I expect more before the end of th year). So to answer your question: > a remote file they own They cannot access it. Yup would be nice and that is just one reason why Bitnet should convert to Tcp/Ip. Incidentally, there is a program I distribute in Bitnet that allows this remote access to a file the person owns but it is a private convention. The program runs as a task (and therefore must be running when the remote user wants access to his/her files). and the user needs to set up a remote access password. It uses the Interactive Message Primitive to send and receive data, and each command you want executed on the remote host must be prefixed with your remote pswd. Not as elegent as TELNET but when the entire concept of TELNET doesn't exist it is the best one can do. > a remote file they don't own, but is not protected Only if the file is available via a remote file server can they access it. > a remote file they don't own, but is protected They can't access it. Hope this helps. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040206332600> Received: from GUNTER-ADAM.ARPA by SRI-NIC.ARPA with TCP; Thu 2 Apr 87 10:36:35-PST Date: 2 Apr 1987 12:33:26 CST Subject: Re: Packet network reliability From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA To: tsuchiya@MITRE-GATEWAY.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: <8704021229.AA15774@jupiter.mitre.org> Paul, On the C/30 algorithm, I believe there are two occurences which can generate an update. One is the expiration of some timer which I've been told is 30 secs. I seem to remember at one time the limit being around 15 secs. The other occurence is in the case where a link is determined to be down. I made the assumption that as the total number of nodes and the connectivity increases then the probability of link problems goes up. Would it increase linearly? Would be an interesting study. I've always thought an interesting experiment would be to first determine an estimated time for a routing update to propagate through the network. Then determine the time required for the Line Up-down Protocol to determine a link is has either just went up or down and then generate the update. Now place a few unscrupulous individuals goegraphically widespread across the network on several interswitch links. Let these individual interupt the link at time T0 and then restore it at T0 + routing propagation time - LUP decision time. How much bandwidth could you forcibly use up with internal routing updates? Ciao, Darrel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704021850.AA07934%40ucbvax.Berkeley.EDU] <1987040208222100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mfidelma@CC5.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: ICMP As A Diagnostic Tool? Message-ID: <8704021850.AA07934@ucbvax.Berkeley.EDU> Date: Thu, 2-Apr-87 13:22:21 EST Article-I.D.: ucbvax.8704021850.AA07934 Posted: Thu Apr 2 13:22:21 1987 Date-Received: Sat, 4-Apr-87 15:43:11 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa It's been my observation that ICMP provides some useful functionality for isolating and diagnosing internetwork problems - e.g. by timing pings, looking at what percentage of echos come back, source routing packets via specific paths, route recording, etc. It strikes me that the lack of similar functionality for the OSI world may lead to an OSI internet in which significant classes of problems can not be fault isolated. I find this a rather scary thought. Does anybody have any comments, or better yet, examples of specific internet problems in which ICMP was used for diagnostic purposes? Miles Fidelman BBN Communications mfidelman@bbn.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040208222101> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Thu 2 Apr 87 10:35:34-PST To: tcp-ip@sri-nic.ARPA Subject: ICMP As A Diagnostic Tool? Date: 02 Apr 87 13:22:21 EST (Thu) From: "Miles R. Fidelman" It's been my observation that ICMP provides some useful functionality for isolating and diagnosing internetwork problems - e.g. by timing pings, looking at what percentage of echos come back, source routing packets via specific paths, route recording, etc. It strikes me that the lack of similar functionality for the OSI world may lead to an OSI internet in which significant classes of problems can not be fault isolated. I find this a rather scary thought. Does anybody have any comments, or better yet, examples of specific internet problems in which ICMP was used for diagnostic purposes? Miles Fidelman BBN Communications mfidelman@bbn.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704021904.AA08193%40ucbvax.Berkeley.EDU] <1987040208332600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AFDDN.TCP-IP@GUNTER-ADAM.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Packet network reliability Message-ID: <8704021904.AA08193@ucbvax.Berkeley.EDU> Date: Thu, 2-Apr-87 13:33:26 EST Article-I.D.: ucbvax.8704021904.AA08193 Posted: Thu Apr 2 13:33:26 1987 Date-Received: Sat, 4-Apr-87 15:49:33 EST References: <8704021229.AA15774@jupiter.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Paul, On the C/30 algorithm, I believe there are two occurences which can generate an update. One is the expiration of some timer which I've been told is 30 secs. I seem to remember at one time the limit being around 15 secs. The other occurence is in the case where a link is determined to be down. I made the assumption that as the total number of nodes and the connectivity increases then the probability of link problems goes up. Would it increase linearly? Would be an interesting study. I've always thought an interesting experiment would be to first determine an estimated time for a routing update to propagate through the network. Then determine the time required for the Line Up-down Protocol to determine a link is has either just went up or down and then generate the update. Now place a few unscrupulous individuals goegraphically widespread across the network on several interswitch links. Let these individual interupt the link at time T0 and then restore it at T0 + routing propagation time - LUP decision time. How much bandwidth could you forcibly use up with internal routing updates? Ciao, Darrel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704021845.AA08097%40violet.berkeley.edu] <1987040208454600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jkh@VIOLET.BERKELEY.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: My Broadcast Message-ID: <8704021845.AA08097@violet.berkeley.edu> Date: Thu, 2-Apr-87 13:45:46 EST Article-I.D.: violet.8704021845.AA08097 Posted: Thu Apr 2 13:45:46 1987 Date-Received: Sat, 4-Apr-87 15:51:13 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 95 Approved: tcp-ip@sri-nic.arpa By now, many of you have heard of (or seen) the broadcast message I sent to the net two days ago. I have since received 743 messages and have replied to every one (either with a form letter, or more personally when questions were asked). The intention behind this effort was to show that I wasn't interested in doing what I did maliciously or in hiding out afterwards and avoiding the repercussions. One of the people who received my message was Dennis Perry, the Inspector General of the ARPAnet (in the Pentagon), and he wasn't exactly pleased. (I hear his Interleaf windows got scribbled on) So now everyone is asking: "Who is this Jordan Hubbard, and why is he on my screen??" I will attempt to explain. I head a small group here at Berkeley called the "Distributed Unix Group". What that essentially means is that I come up with Unix distribution software for workstations on campus. Part of this job entails seeing where some of the novice administrators we're creating will hang themselves, and hopefully prevent them from doing so. Yesterday, I finally got around to looking at the "broadcast" group in /etc/netgroup which was set to "(,,)". It was obvious that this was set up for rwall to use, so I read the documentation on "netgroup" and "rwall". A section of the netgroup man page said: ... Any of three fields can be empty, in which case it signifies a wild card. Thus universal (,,) defines a group to which everyone belongs. Field names that ... ... Now "everyone" here is pretty ambiguous. Reading a bit further down, one sees discussion on yellow-pages domains and might be led to believe that "everyone" was everyone in your domain. I know that rwall uses point-to-point RPC connections, so I didn't feel that this was what they meant, just that it seemed to be the implication. Reading the rwall man page turned up nothing about "broadcasts". It doesn't even specify the communications method used. One might infer that rwall did indeed use actual broadcast packets. Failing to find anything that might suggest that rwall would do anything nasty beyond the bounds of the current domain (or at least up to the IMP), I tried it. I knew that rwall takes awhile to do its stuff, so I left it running and went back to my office. I assumed that anyone who got my message would let me know.. Boy, was I right about that! After the first few mail messages arrived from Purdue and Utexas, I begin to understand what was really going on and killed the rwall. I mean, how often do you expect to run something on your machine and have people from Wisconsin start getting the results of it on their screens? All of this has raised some interesting points and problems. 1. Rwall will walk through your entire hosts file and blare at anyone and everyone if you use the (,,) wildcard group. Whether this is a bug or a feature, I don't know. 2. Since rwall is an RPC service, and RPC doesn't seem to give a damn who you are as long as you're root (which is trivial to be, on a work- station), I have to wonder what other RPC services are open holes. We've managed to do some interesting, unauthorized, things with the YP service here at Berkeley, I wonder what the implications of this are. 3. Having a group called "broadcast" in your netgroup file (which is how it comes from sun) is just begging for some novice admin (or operator with root) to use it in the mistaken belief that he/she is getting to all the users. I am really surprised (as are many others) that this has taken this long to happen. 4. Killing rwall is not going to solve the problem. Any fool can write rwall, and just about any fool can get root priviledge on a Sun workstation. It seems that the place to fix the problem is on the receiving ends. The only other alternative would be to tighten up all the IMP gateways to forward packets only from "trusted" hosts. I don't like that at all, from a standpoint of reduced convenience and productivity. Also, since many places are adding hosts at a phenominal rate (ourselves especially), it would be hard to keep such a database up to date. Many perfectly well- behaved people would suffer for the potential sins of a few. I certainly don't intend to do this again, but I'm very curious as to what will happen as a result. A lot of people got wall'd, and I would think that they would be annoyed that their machine would let someone from the opposite side of the continent do such a thing! Jordan Hubbard jkh@violet.berkeley.edu (ucbvax!jkh) Computer Facilities & Communications. U.C. Berkeley ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704021848.AA23354%40jade.berkeley.edu] <1987040208485100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: usenet@JADE.BERKELEY.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8704021848.AA23354@jade.berkeley.edu> Date: Thu, 2-Apr-87 13:48:51 EST Article-I.D.: jade.8704021848.AA23354 Posted: Thu Apr 2 13:48:51 1987 Date-Received: Sat, 4-Apr-87 17:17:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 106 Approved: tcp-ip@sri-nic.arpa Path: jade!violet.berkeley.edu!jkh From: jkh@violet.berkeley.edu (Jordan K. Hubbard) Newsgroups: mod.protocols.tcp-ip Subject: jkh annoys the net Message-ID: <3011@jade.BERKELEY.EDU> Date: 2 Apr 87 18:48:50 GMT Sender: usenet@jade.BERKELEY.EDU Reply-To: jkh@violet.berkeley.edu(Jordan K. Hubbard) Organization: University of California, Berkeley Lines: 95 By now, many of you have heard of (or seen) the broadcast message I sent to the net two days ago. I have since received 743 messages and have replied to every one (either with a form letter, or more personally when questions were asked). The intention behind this effort was to show that I wasn't interested in doing what I did maliciously or in hiding out afterwards and avoiding the repercussions. One of the people who received my message was Dennis Perry, the Inspector General of the ARPAnet (in the Pentagon), and he wasn't exactly pleased. (I hear his Interleaf windows got scribbled on) So now everyone is asking: "Who is this Jordan Hubbard, and why is he on my screen??" I will attempt to explain. I head a small group here at Berkeley called the "Distributed Unix Group". What that essentially means is that I come up with Unix distribution software for workstations on campus. Part of this job entails seeing where some of the novice administrators we're creating will hang themselves, and hopefully prevent them from doing so. Yesterday, I finally got around to looking at the "broadcast" group in /etc/netgroup which was set to "(,,)". It was obvious that this was set up for rwall to use, so I read the documentation on "netgroup" and "rwall". A section of the netgroup man page said: ... Any of three fields can be empty, in which case it signifies a wild card. Thus universal (,,) defines a group to which everyone belongs. Field names that ... ... Now "everyone" here is pretty ambiguous. Reading a bit further down, one sees discussion on yellow-pages domains and might be led to believe that "everyone" was everyone in your domain. I know that rwall uses point-to-point RPC connections, so I didn't feel that this was what they meant, just that it seemed to be the implication. Reading the rwall man page turned up nothing about "broadcasts". It doesn't even specify the communications method used. One might infer that rwall did indeed use actual broadcast packets. Failing to find anything that might suggest that rwall would do anything nasty beyond the bounds of the current domain (or at least up to the IMP), I tried it. I knew that rwall takes awhile to do its stuff, so I left it running and went back to my office. I assumed that anyone who got my message would let me know.. Boy, was I right about that! After the first few mail messages arrived from Purdue and Utexas, I begin to understand what was really going on and killed the rwall. I mean, how often do you expect to run something on your machine and have people from Wisconsin start getting the results of it on their screens? All of this has raised some interesting points and problems. 1. Rwall will walk through your entire hosts file and blare at anyone and everyone if you use the (,,) wildcard group. Whether this is a bug or a feature, I don't know. 2. Since rwall is an RPC service, and RPC doesn't seem to give a damn who you are as long as you're root (which is trivial to be, on a work- station), I have to wonder what other RPC services are open holes. We've managed to do some interesting, unauthorized, things with the YP service here at Berkeley, I wonder what the implications of this are. 3. Having a group called "broadcast" in your netgroup file (which is how it comes from sun) is just begging for some novice admin (or operator with root) to use it in the mistaken belief that he/she is getting to all the users. I am really surprised (as are many others) that this has taken this long to happen. 4. Killing rwall is not going to solve the problem. Any fool can write rwall, and just about any fool can get root priviledge on a Sun workstation. It seems that the place to fix the problem is on the receiving ends. The only other alternative would be to tighten up all the IMP gateways to forward packets only from "trusted" hosts. I don't like that at all, from a standpoint of reduced convenience and productivity. Also, since many places are adding hosts at a phenominal rate (ourselves especially), it would be hard to keep such a database up to date. Many perfectly well- behaved people would suffer for the potential sins of a few. I certainly don't intend to do this again, but I'm very curious as to what will happen as a result. A lot of people got wall'd, and I would think that they would be annoyed that their machine would let someone from the opposite side of the continent do such a thing! Jordan Hubbard jkh@violet.berkeley.edu (ucbvax!jkh) Computer Facilities & Communications. U.C. Berkeley ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12291353732.27.GROSSMAN%40Sierra.Stanford.EDU] <1987040209023600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GROSSMAN@SIERRA.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: danger of bridges Message-ID: <12291353732.27.GROSSMAN@Sierra.Stanford.EDU> Date: Thu, 2-Apr-87 14:02:36 EST Article-I.D.: Sierra.12291353732.27.GROSSMAN Posted: Thu Apr 2 14:02:36 1987 Date-Received: Sat, 4-Apr-87 15:53:45 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa In the absence of a Designated Router, DECnet endnodes (on an Ethernet) will attempt to communicate by sending to the destination node's Ethernet address. This Ethernet address is computed from the node's DECnet host number. This is why all DECnet hosts on an Ethernet have funny addresses. A DECnet Ethernet address looks like AA-00-04-00-XX-YY, where XX-YY is the DECnet host number with the bytes swapped (don't shoot me, I'm just the piano player). Stu Grossman ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704022034.AA09965%40ucbvax.Berkeley.EDU] <1987040210190000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bill@NRL-LCP.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Response to anti-bridge comments Message-ID: <8704022034.AA09965@ucbvax.Berkeley.EDU> Date: Thu, 2-Apr-87 15:19:00 EST Article-I.D.: ucbvax.8704022034.AA09965 Posted: Thu Apr 2 15:19:00 1987 Date-Received: Sat, 4-Apr-87 16:01:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Distribution: world Organization: The ARPA Internet Lines: 59 Approved: tcp-ip@sri-nic.arpa > Date: Tue, 31 Mar 87 15:33:29 EST > From: jas@monk.proteon.com (John A. Shriver) > Subject: Response to anti-bridge comments > The very nature of bridges prevents you from doing load > sharing (unless you manually program the filtering/forwarding > databases, giving up the advantages of adaptive bridges). I don't think it's anything intrinsic about a Bridge that would prevent you from doing load sharing. It's only a function of the current Bridge software that this isn't currently possible. One simple scheme that I just happened to think of off the top of my head would involve having 2**N Bridges numbered from 0 to 2**N-1, and each Bridge would handle those Ethernet addresses which modulo 2**N matched its own assigned Bridge number. A hot spare could detect the failure of any particular live Bridge, and take over for it. One Bridge could be designated to handle broadcast packets. Does anyone know if such a scheme or anything similar has been considered for doing load sharing across Bridges? It doesn't seem that it would be that difficult to implement. By the way, in practice, at least at our site, the level of traffic through our Ethernet Bridges is nowhere near significant enough to even start to worry about load sharing, and we have a fairly extensive Ethernet based network in active use here at NRL. > Gateways > with multipath internal routing algorithms can do load sharing, look > at BBN's PSN software using SPF on the ARPANET and MILNET. Sooner or > later, a network gets big enough and complicated enough that one > migrates from bridges to routers. Although Gateways/Routers COULD also do load sharing with appropriate routing algorithms, it is my understanding that all of the current Gateways, even those with SPF routing, DO NOT currently do any kind of load sharing, and only understand and compute a single path to any given destination. I specifically asked this question at the TCP/IP Interoperability Conference held just recently in Monterey, and that was the answer I was given by someone involved with the SPF routing Gateways. > What the advocates are arguing about is where the line between bridges > and routers is. I think there are appropriate circumstances to use both Bridges and Gateways/Routers. The primary benefits that I see for using Bridges, given the state of current technology, is ease of installation, monitoring, and management, and the fact that they are protocol transparent to the higher layer protocols. In the future, they will probably even be used to connect dissimilar technologies, such as Ethernet and FDDI Fiber Optic networks. But Gateways certainly have their appropriate niche also, such as providing a higher degree of isolation between the connected networks when this is desirable. -My first plunge -Bill Fink bill@NRL-LCP ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040210190001> Received: from nrl-lcp.arpa by SRI-NIC.ARPA with TCP; Thu 2 Apr 87 12:25:16-PST Date: 2 Apr 87 15:19:00 EST From: Subject: Re: Response to anti-bridge comments To: "tcp-ip" Reply-To: > Date: Tue, 31 Mar 87 15:33:29 EST > From: jas@monk.proteon.com (John A. Shriver) > Subject: Response to anti-bridge comments > The very nature of bridges prevents you from doing load > sharing (unless you manually program the filtering/forwarding > databases, giving up the advantages of adaptive bridges). I don't think it's anything intrinsic about a Bridge that would prevent you from doing load sharing. It's only a function of the current Bridge software that this isn't currently possible. One simple scheme that I just happened to think of off the top of my head would involve having 2**N Bridges numbered from 0 to 2**N-1, and each Bridge would handle those Ethernet addresses which modulo 2**N matched its own assigned Bridge number. A hot spare could detect the failure of any particular live Bridge, and take over for it. One Bridge could be designated to handle broadcast packets. Does anyone know if such a scheme or anything similar has been considered for doing load sharing across Bridges? It doesn't seem that it would be that difficult to implement. By the way, in practice, at least at our site, the level of traffic through our Ethernet Bridges is nowhere near significant enough to even start to worry about load sharing, and we have a fairly extensive Ethernet based network in active use here at NRL. > Gateways > with multipath internal routing algorithms can do load sharing, look > at BBN's PSN software using SPF on the ARPANET and MILNET. Sooner or > later, a network gets big enough and complicated enough that one > migrates from bridges to routers. Although Gateways/Routers COULD also do load sharing with appropriate routing algorithms, it is my understanding that all of the current Gateways, even those with SPF routing, DO NOT currently do any kind of load sharing, and only understand and compute a single path to any given destination. I specifically asked this question at the TCP/IP Interoperability Conference held just recently in Monterey, and that was the answer I was given by someone involved with the SPF routing Gateways. > What the advocates are arguing about is where the line between bridges > and routers is. I think there are appropriate circumstances to use both Bridges and Gateways/Routers. The primary benefits that I see for using Bridges, given the state of current technology, is ease of installation, monitoring, and management, and the fact that they are protocol transparent to the higher layer protocols. In the future, they will probably even be used to connect dissimilar technologies, such as Ethernet and FDDI Fiber Optic networks. But Gateways certainly have their appropriate niche also, such as providing a higher degree of isolation between the connected networks when this is desirable. -My first plunge -Bill Fink bill@NRL-LCP ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D.2-Apr-87.18:20:50.CERF] <1987040213200000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ICMP As A Diagnostic Tool? Message-ID: <[A.ISI.EDU].2-Apr-87.18:20:50.CERF> Date: Thu, 2-Apr-87 18:20:00 EST Article-I.D.: <[A.ISI.EDU].2-Apr-87.18:20:50.CERF> Posted: Thu Apr 2 18:20:00 1987 Date-Received: Sat, 4-Apr-87 18:13:50 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa I "pinger and grease monkey of the year" award probably goes to DAve Mills who has probably launched more pings in the Internet than any other player. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040213200001> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Thu 2 Apr 87 15:36:22-PST Date: 2 Apr 1987 18:20-EST Sender: CERF@A.ISI.EDU Subject: Re: ICMP As A Diagnostic Tool? From: CERF@A.ISI.EDU To: mfidelma@CC5.BBN.COM Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 2-Apr-87 18:20:50.CERF> In-Reply-To: The message of 02 Apr 87 13:22:21 EST (Thu) from "Miles R. Fidelman" I "pinger and grease monkey of the year" award probably goes to DAve Mills who has probably launched more pings in the Internet than any other player. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12291430000.11.BOB%40WARD.CS.WASHINGTON.EDU] <1987040216013300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BOB@WARD.CS.WASHINGTON.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: ip subnets Message-ID: <12291430000.11.BOB@WARD.CS.WASHINGTON.EDU> Date: Thu, 2-Apr-87 21:01:33 EST Article-I.D.: WARD.12291430000.11.BOB Posted: Thu Apr 2 21:01:33 1987 Date-Received: Sat, 4-Apr-87 18:05:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa I am trying to gather a bit of information about the use of subnets on the internet. Of all the sites on the internet that have been assigned a class-B (class-A too, but there are not many of those) network number, who uses subnets. If you have a class-B network number, I would like to ask you 2 questions: 1) Do you use subnets? Why? 2) What type of link/physical layers do you run ip datagrams over? Any responses would be greatly appreciated. I will tabulate and post to the net, if there is sufficient interest. -thanks. -bob ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704030246.AA02484%40gwen.cs.purdue.edu] <1987040216455500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: narten@PURDUE.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network Message-ID: <8704030246.AA02484@gwen.cs.purdue.edu> Date: Thu, 2-Apr-87 21:45:55 EST Article-I.D.: gwen.8704030246.AA02484 Posted: Thu Apr 2 21:45:55 1987 Date-Received: Sat, 4-Apr-87 18:36:58 EST References: <8704010458.AA01350@spam.istc.sri.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa > Presumably, as domain names get extended, we will be able to > do that. Any mail you send to a user can go directly to the machine > where the his/her mailbox resides. No forwarding at the site would be > needed. There is still a hole with current TCP mailers in that often mail really travels an extra hop. That is, mail for janedoe@somewhere.edu gets sent to the machine at "somewhere.edu", which after accepting the mail, turns around and forwards it the machine the user reads mail on. I would prefer an acknowledgement that mail has actually been placed in the users mailbox, rather than just handing the mail to a "reliable" delivering agent at the site. Domain names were designed to handle lots more than just machine name to IP address mappings. At some point, it will (hopefully) be possible to register mailboxes in the system. That way, mail sent to janedoe@somewhere.edu will not necessarily mean sending the mail to "somewhere.edu". Rather, sendmail will find the real agent via nameserver queries about "janedoe@somewhere.edu". Now mail gets sent directly to the machine where the user's mailbox resides, and now when the mail is no longer in the sender's local queue, it really is in the correct mailbox, and not still in transit somewhere. Thomas ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040218270400> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 2 Apr 87 04:57:58-PST Received: from BARILVM.BITNET by wiscvm.wisc.edu on 04/02/87 at 06:56:17 CST Received: by BARILVM (Mailer X1.23b) id 5044; Thu, 02 Apr 87 14:58:04 O Date: Thu, 02 Apr 87 14:57:04 O From: Henry Nussbacher Subject: Bitnet protocols To: tcp-ip@sri-nic.ARPA I sent this yesterday and I never saw it come back so I have a feeling it got lost on its way: (Caveat - This description is primarily for people who have no idea how Bitnet works.) Greg, The concept of remote access doesn't exist in Bitnet. The protocols in Bitnet are as follows: 1) One-way File Transfer - any user is allowed to send a file to any other user. Since the file ends up in the destination users spool system (or some emulation thereof) there is no problem with access control. 2) Interactive Message - any user can send a one line message (max 160 characters) to any other user. All you need to know is the destination user and node. If the user is not logged on or a link is down you are told so. Based on these two primitives - Bitnet has built various other pseudo-protocols. From #1 above - we are able to do mail, list explosion, computer conferencing, general file transfer. From #2 above, Bitnet has developed a CB (Chat) system. By combined both of the basic primitives above, a file server can be set up at any node that will trap incoming 'Interactive Messages' - which contain a command and process the command and send the results back to the user via the 'One-Way File Transfer' mechanism. This method allows users to sit at their machine and issue commands like DIR or LIST to some remote file server and then issue some SEND commands to retrieve the files they want. There is no need in that case to do any sort of remote connect (anonymous FTP). Most servers (200+) in Bitnet also accept transactions via files or RFC822 mail. Lately, various servers in Arpanet have decided that is also a 'clever' thing to have, so we have things like archive-request@simtel20.arpa and service@sri-nic.arpa popping up (I expect more before the end of th year). So to answer your question: > a remote file they own They cannot access it. Yup would be nice and that is just one reason why Bitnet should convert to Tcp/Ip. Incidentally, there is a program I distribute in Bitnet that allows this remote access to a file the person owns but it is a private convention. The program runs as a task (and therefore must be running when the remote user wants access to his/her files). and the user needs to set up a remote access password. It uses the Interactive Message Primitive to send and receive data, and each command you want executed on the remote host must be prefixed with your remote pswd. Not as elegent as TELNET but when the entire concept of TELNET doesn't exist it is the best one can do. > a remote file they don't own, but is not protected Only if the file is available via a remote file server can they access it. > a remote file they don't own, but is protected They can't access it. Hope this helps. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704030214.a001249%40Huey.UDEL.EDU] <1987040221143400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: danger of bridges Message-ID: <8704030214.a001249@Huey.UDEL.EDU> Date: Fri, 3-Apr-87 02:14:34 EST Article-I.D.: Huey.8704030214.a001249 Posted: Fri Apr 3 02:14:34 1987 Date-Received: Sun, 5-Apr-87 02:50:54 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Drew, The fuzzies, as you know, use broadcast, rather than multicast. There is in principle no problem using restricted multicast, but then this also apllies to RIP and others. Do you have a concrete suggestion on how to manage the multicast group? Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704030217.a001269%40Huey.UDEL.EDU] <1987040221174700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: INFO REQUEST! Message-ID: <8704030217.a001269@Huey.UDEL.EDU> Date: Fri, 3-Apr-87 02:17:47 EST Article-I.D.: Huey.8704030217.a001269 Posted: Fri Apr 3 02:17:47 1987 Date-Received: Sun, 5-Apr-87 02:53:42 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Brian, Contact Dave Stoffel (dave@mimsy.umd.edu) for much information on Braille and computers, including packet radio and related topics. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704031034.AA22667%40ucbvax.Berkeley.EDU] <1987040300352300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jon@CS.UCL.AC.UK.UUCP Newsgroups: mod.protocols.tcp-ip Subject: NIFTP Message-ID: <8704031034.AA22667@ucbvax.Berkeley.EDU> Date: Fri, 3-Apr-87 05:35:23 EST Article-I.D.: ucbvax.8704031034.AA22667 Posted: Fri Apr 3 05:35:23 1987 Date-Received: Sun, 5-Apr-87 01:31:42 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa A few days ago i inadvertantly mentioned the UK JNT spooled file transfer service as a neat means of getting data around a network. A larginsh number of people have asked me for more information, so Network Independant File Transfer protocol (aka Blue Book), normally runs over transport + X.25, but can and does run over TCP/IP at some sites (using well known port 47). Does recovery from connection failure, is spooled etc. Is widely used in the UK for email, a lot. A list of implementations can be got from: r.cooper@gec-b.rutherford.ac.uk One unix version can be got from SApider Systems, or ask piet brooks at Cambridge (don't have his address, but requests to mailgroup@ucl.cs.ac.uk will find him). jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704031246.AA16532%40mitre-bedford.ARPA] <1987040302464400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sra@MITRE-BEDFORD.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TCP/IP for NCR 3000, Burrougs XE520 and B-25 Message-ID: <8704031246.AA16532@mitre-bedford.ARPA> Date: Fri, 3-Apr-87 07:46:44 EST Article-I.D.: mitre-be.8704031246.AA16532 Posted: Fri Apr 3 07:46:44 1987 Date-Received: Sun, 5-Apr-87 03:06:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa The ULANA program has been requested to add three machines to its list of hosts to be supported. These are: NCR WS3000 with CTOS Burroughs XE520 with CTOS, BTOS, MSDOS, or XENIX Burroughs B-25 with MSDOS, or BTOS I am unfamilar with any of these machines but I would like to acomodiate the request if interfaces are available. We are looking for an 802.3 interface with TCP,IP,TELNET,FTP,SMPT,etc any information or leads would be greatly appreciated. Stan Ames sra at mitre-bedford ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704042334.AA21316%40ucbvax.Berkeley.EDU] <1987040305284100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mohamed%hscfvax@HARVARD.HARVARD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Time RFC 868 Message-ID: <8704042334.AA21316@ucbvax.Berkeley.EDU> Date: Fri, 3-Apr-87 10:28:41 EST Article-I.D.: ucbvax.8704042334.AA21316 Posted: Fri Apr 3 10:28:41 1987 Date-Received: Sun, 5-Apr-87 14:14:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa I would like to hear from sites that keep exact time and make it available (RFC 868) to others. Also whether it is available via TCP or UDP. Thanks ellozy@harvard.harvard.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040305284101> Received: from harvard.harvard.edu by SRI-NIC.ARPA with TCP; Sat 4 Apr 87 15:18:13-PST Received: by harvard.harvard.edu; Fri, 3 Apr 87 10:28:41 EST Date: Fri, 3 Apr 87 10:28:41 EST Received: by hscfvax.HARVARD.EDU; Fri, 3 Apr 87 10:27:39 est From: mohamed%hscfvax@harvard.harvard.edu (750025@Mohamed_el_Lozy) To: tcp-ip@sri-nic.arpa Subject: Time RFC 868 I would like to hear from sites that keep exact time and make it available (RFC 868) to others. Also whether it is available via TCP or UDP. Thanks ellozy@harvard.harvard.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- [459%40cernvax.UUCP] <1987040305293700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jmg@CERNVAX.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Ethernet TCP/IP broadcasts: help Message-ID: <459@cernvax.UUCP> Date: Fri, 3-Apr-87 10:29:37 EST Article-I.D.: cernvax.459 Posted: Fri Apr 3 10:29:37 1987 Date-Received: Sun, 5-Apr-87 07:22:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: cernvax!jmg () Distribution: world Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Sw Lines: 21 Approved: tcp-ip@sri-nic.arpa Last Wednesday (yes, it was April 1st; no it was NO JOKE) we got a situation on our Ethernet where a particular telnet RST packet from a host to a client was being sent inside a broadcast packet. The trouble was that this same broadcast packet was being sent out repeatedly by just about every TCP/IP host on our Ethernet (including both VMS with Wollongong and 4.2BSD). Thus, we were seeing about 1000 broadcast packets per second, coming from many diffferent sources but all containing this same RST information. This was, of course, killing all the small microvaxes and weaker 750/780 etc., with only the big 8800 having enough clout to continue apparently normally. We eventually stopped it by disconnecting all of the offenders, much to their disgust. After that everything started fine. Since we started installing Ethernet some years ago we have never seen such a catastrophic situation. Therefore, if anyone has any idea why so many vaxes should start rebroadcasting packets which were nothing to do with them I should be eternally grateful. Mike Gerard ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704031719.AA28257%40ucbvax.Berkeley.EDU] <1987040306524500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@CCV.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: multicast groups on ether (was: danger of bridges) Message-ID: <8704031719.AA28257@ucbvax.Berkeley.EDU> Date: Fri, 3-Apr-87 11:52:45 EST Article-I.D.: ucbvax.8704031719.AA28257 Posted: Fri Apr 3 11:52:45 1987 Date-Received: Sun, 5-Apr-87 03:43:26 EST References: <8704030214.a001249@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Do you have a concrete suggestion on how to manage the multicast group? How about the following (summary: manage by czar). The goal is to completely eliminate use of the broadcast address. TCP/IP implementations may be overusing this feature, between ARP, RWHO, etc. Go to the ethernet number czar and get two (2) groups of 65536 (2^^16) multicast addresses. By that, I mean the high order 32 bits are assigned by the czar, and the low 16 bits are ours to play with. Call the first group and the second group . These become well know, and wired in the programs, much like 255.255.255.255.255.255 is today. The first group, , is the contact address for all hosts which handle 'broadcast' for a particular ether link (message type). Thus ARP, instead of polluting all the hosts in the net, would send to the address .8.6 (0x0806 is the number assigned to the address resolution protocol). The second group, is the set of addresses for IP broadcast protocols, and subdivided into one byte of IP protocol (e.g. UDP, 17), and one byte of well-known-port (e.g. RWHO, 550 (oops, well, you get the idea). While this idea is a bit half-baked, it should serve to move host and gateway impementations to independence from broadcasts. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040306524501> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Fri 3 Apr 87 09:02:24-PST To: Mills@louie.udel.edu cc: Drew Daniel Perkins , tcp-ip@sri-nic.ARPA, tsuchiya@gateway.mitre.org, x3s33-interest@gateway.mitre.org Subject: multicast groups on ether (was: danger of bridges) In-reply-to: Your message of Fri, 3 Apr 87 2:14:34 EST. <8704030214.a001249@Huey.UDEL.EDU> Date: 03 Apr 87 11:52:45 EST (Fri) From: Mike Brescia Do you have a concrete suggestion on how to manage the multicast group? How about the following (summary: manage by czar). The goal is to completely eliminate use of the broadcast address. TCP/IP implementations may be overusing this feature, between ARP, RWHO, etc. Go to the ethernet number czar and get two (2) groups of 65536 (2^^16) multicast addresses. By that, I mean the high order 32 bits are assigned by the czar, and the low 16 bits are ours to play with. Call the first group and the second group . These become well know, and wired in the programs, much like 255.255.255.255.255.255 is today. The first group, , is the contact address for all hosts which handle 'broadcast' for a particular ether link (message type). Thus ARP, instead of polluting all the hosts in the net, would send to the address .8.6 (0x0806 is the number assigned to the address resolution protocol). The second group, is the set of addresses for IP broadcast protocols, and subdivided into one byte of IP protocol (e.g. UDP, 17), and one byte of well-known-port (e.g. RWHO, 550 (oops, well, you get the idea). While this idea is a bit half-baked, it should serve to move host and gateway impementations to independence from broadcasts. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040307142400> Received: from UDEL.EDU (HUEY.UDEL.EDU) by SRI-NIC.ARPA with TCP; Fri 3 Apr 87 09:23:47-PST Date: Fri, 3 Apr 87 12:14:24 EST From: Mills@UDEL.EDU To: jon@cs.ucl.ac.uk cc: tcp-ip@sri-nic.arpa Subject: Re: Tcp/Ip vs a store & forward network Message-ID: <8704031214.a006345@Huey.UDEL.EDU> Jon, Then your worries are over. There is a NIFTP implementation running on TOPS-20s and fuzzballs. Since further development of FTP is not in the mainstream and that dinosaur is many years old now, it is not fair to bash it. Why don't you guys poke Berkeley to include your NIFTP with Unix distributions as an interim until FTAM (on TCP or whatever) is available? Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040307550000> Received: from pescadero.stanford.edu by SRI-NIC.ARPA with TCP; Fri 3 Apr 87 17:43:13-PST Received: by pescadero.stanford.edu with Sendmail; Fri, 3 Apr 87 17:37:34 pst Date: 3 Apr 1987 15:55-PST From: Steve Deering Subject: Re: multicast groups on ether To: Mike Brescia Cc: Mills@louie.udel.edu, Drew Daniel Perkins , tcp-ip@sri-nic.ARPA, tsuchiya@mitre-gateway.ARPA, x3s33-interest@mitre-gateway.ARPA Message-Id: <87/04/03 1555.090@pescadero.stanford.edu> In-Reply-To: Mike Brescia's message of 03 Apr 87 115245 EST (Fri) The goal is to completely eliminate use of the broadcast address. TCP/IP implementations may be overusing this feature, between ARP, RWHO, etc. Hear! hear! At the moment, if you want to use IP on an Ethernet, you must listen to Ethernet broadcasts, for the sake of ARP. Here at Stanford, that means you get to receive and discard packets broadcast for RWho, Reverse ARP, RIP, TFTP, Time, Domain Name lookups, Pup name lookups, BOOTP, ND, Pup routing, XNS routing,... and whatever new broadcast protocol was invented today. In RFC988, I propose a way to manage multicast addresses for IP-based applications. I suggest that the number czar should allocate well-known IP multicast address, rather than Ethernet multicast addresses, and that there should be a standard mapping from IP to local network multicast addresses for each type of local network. As for ARP, I think ARP-for-IP should use a different Ethernet multicast address than ARP-for-Chaos or ARP-for-whatever, even though they use the same Ether-type. And, of course, Reverse ARP should use different addresses than ARP. To phase in multicast-based ARP, you could (during the phase-in period) listen to both the broadcast address and the multicast address. When sending an ARP request, use the multicast address first, then broadcast if you don't get a reply. Karen Lam of BBN has extended the 4.3bsd UNIX IP code to support RFC988-style multicasting, on top of which I have implemented a multicast version of Berkeley's rwho daemon. This code (both Karen's and mine) is running successfully at a couple of test sites and I hope it will soon be made available for wider distribution to those who wish to experiment with IP multicasting. I would appreciate any feedback on RFC988. I would also like to hear of any other work going on in the area of internetwork multicasting. In particular, is the x3s33 committee considering internetwork multicast addressing and routing? Steve Deering ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704031825.AA11868%40spam.istc.sri.com] <1987040308451100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gds@SPAM.ISTC.SRI.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network Message-ID: <8704031825.AA11868@spam.istc.sri.com> Date: Fri, 3-Apr-87 13:45:11 EST Article-I.D.: spam.8704031825.AA11868 Posted: Fri Apr 3 13:45:11 1987 Date-Received: Sun, 5-Apr-87 04:46:16 EST References: <8704030246.AA02484@gwen.cs.purdue.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 35 Approved: tcp-ip@sri-nic.arpa There is still a hole with current TCP mailers in that often mail really travels an extra hop. That is, mail for janedoe@somewhere.edu gets sent to the machine at "somewhere.edu", which after accepting the mail, turns around and forwards it the machine the user reads mail on. I would prefer an acknowledgement that mail has actually been placed in the users mailbox, rather than just handing the mail to a "reliable" delivering agent at the site. Like the gentleman from rice said, you don't always know when mail is placed in the user's mailbox. It may be a post-office type system, where mail is read from a mail server, but composed from the mail client. Everything is done without forwarding. When do you decide that the mail is in the mailbox? Domain names were designed to handle lots more than just machine name to IP address mappings. At some point, it will (hopefully) be possible to register mailboxes in the system. That way, mail sent to janedoe@somewhere.edu will not necessarily mean sending the mail to "somewhere.edu". Rather, sendmail will find the real agent via nameserver queries about "janedoe@somewhere.edu". Now mail gets sent directly to the machine where the user's mailbox resides, and now when the mail is no longer in the sender's local queue, it really is in the correct mailbox, and not still in transit somewhere. It still might be in transit somewhere -- the mailbox entries may point to non-Internet sites which will require at least an extra hop at a mail bridge. Does this "ack" scheme imply retransmission of a mail message until a retransmission timeout? I would hate to see those old "Message queued for 3 days -- will try again for another 12 days" messages from mailers coming to my mailbox again. --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040310180500> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Fri 3 Apr 87 02:26:13-PST Received: from ucl-cs-pyr1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa07053; 3 Apr 87 10:21 WET To: tcp-ip@sri-nic.arpa Subject: NIFTP Date: Fri, 03 Apr 87 10:18:05 +0000 From: Jon Crowcroft A few days ago i inadvertantly mentioned the UK JNT spooled file transfer service as a neat means of getting data around a network. A larginsh number of people have asked me for more information, so Network Independant File Transfer protocol (aka Blue Book), normally runs over transport + X.25, but can and does run over TCP/IP at some sites (using well known port 47). Does recovery from connection failure, is spooled etc. Is widely used in the UK for email, a lot. A list of implementations can be got from: r.cooper@gec-b.rutherford.ac.uk One unix version can be got from SApider Systems, or ask piet brooks at Cambridge (don't have his address, but requests to mailgroup@ucl.cs.ac.uk will find him). jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704032029.AA00510%40mitre.ARPA] <1987040310293100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: m15368%mwvm@MITRE.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8704032029.AA00510@mitre.ARPA> Date: Fri, 3-Apr-87 15:29:31 EST Article-I.D.: mitre.8704032029.AA00510 Posted: Fri Apr 3 15:29:31 1987 Date-Received: Sun, 5-Apr-87 06:50:54 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The MITRE Corp., Washington, D.C. Lines: 18 Approved: tcp-ip@sri-nic.arpa To: CERF%A.ISI.EDU CERF at A.ISI.EDU From: Steve Silverman Subject: Layer 2 multiplexing on ISDN The proposed Frame Relay service of ISDN does do layer 2 multiplexing. In LAPD, there is a 2 byte address containing a 6 bit SAPI and a 7 bit TEI (Terminal Equipment Identifier). These 2 fields are combined into a 13 bit DLCI (Data Link Connection Identifier) which would be handled similarly to the LCN in X.25. It would be mapped and set in each node as a frame progressed through the network. Then a new CRC would be calculated and inserted. * * Steve Cc: TCP-IP@SRI-NIC.ARPA MITRE(MCKEE) MCKEE at MITRE ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704032225.AA09390%40skl-crc.ARPA] <1987040312250600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: martinea@SKL-CRC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: RDP source Message-ID: <8704032225.AA09390@skl-crc.ARPA> Date: Fri, 3-Apr-87 17:25:06 EST Article-I.D.: skl-crc.8704032225.AA09390 Posted: Fri Apr 3 17:25:06 1987 Date-Received: Sun, 5-Apr-87 06:25:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Is anyone aware of public domain RDP source??? I would like to use RDP but want to avoid the pain of re-inventing the wheel. Thanks in advance. Mike Martineau ----MESSAGE-END---- ----MESSAGE-BEGIN---- [87.04.03.1555.090%40pescadero.stanford.edu] <1987040313550000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: deering@PESCADERO.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: multicast groups on ether Message-ID: <87.04.03.1555.090@pescadero.stanford.edu> Date: Fri, 3-Apr-87 18:55:00 EST Article-I.D.: pescader.87.04.03.1555.090 Posted: Fri Apr 3 18:55:00 1987 Date-Received: Sun, 5-Apr-87 07:37:49 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 40 Approved: tcp-ip@sri-nic.arpa The goal is to completely eliminate use of the broadcast address. TCP/IP implementations may be overusing this feature, between ARP, RWHO, etc. Hear! hear! At the moment, if you want to use IP on an Ethernet, you must listen to Ethernet broadcasts, for the sake of ARP. Here at Stanford, that means you get to receive and discard packets broadcast for RWho, Reverse ARP, RIP, TFTP, Time, Domain Name lookups, Pup name lookups, BOOTP, ND, Pup routing, XNS routing,... and whatever new broadcast protocol was invented today. In RFC988, I propose a way to manage multicast addresses for IP-based applications. I suggest that the number czar should allocate well-known IP multicast address, rather than Ethernet multicast addresses, and that there should be a standard mapping from IP to local network multicast addresses for each type of local network. As for ARP, I think ARP-for-IP should use a different Ethernet multicast address than ARP-for-Chaos or ARP-for-whatever, even though they use the same Ether-type. And, of course, Reverse ARP should use different addresses than ARP. To phase in multicast-based ARP, you could (during the phase-in period) listen to both the broadcast address and the multicast address. When sending an ARP request, use the multicast address first, then broadcast if you don't get a reply. Karen Lam of BBN has extended the 4.3bsd UNIX IP code to support RFC988-style multicasting, on top of which I have implemented a multicast version of Berkeley's rwho daemon. This code (both Karen's and mine) is running successfully at a couple of test sites and I hope it will soon be made available for wider distribution to those who wish to experiment with IP multicasting. I would appreciate any feedback on RFC988. I would also like to hear of any other work going on in the area of internetwork multicasting. In particular, is the x3s33 committee considering internetwork multicast addressing and routing? Steve Deering ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704040234.AA07554%40ucbvax.Berkeley.EDU] <1987040316184300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <8704040234.AA07554@ucbvax.Berkeley.EDU> Date: Fri, 3-Apr-87 21:18:43 EST Article-I.D.: ucbvax.8704040234.AA07554 Posted: Fri Apr 3 21:18:43 1987 Date-Received: Sun, 5-Apr-87 07:05:37 EST References: <8704021845.AA08097@violet.berkeley.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa John, I think you did a good thing. Testing for idiotic holes in the "system". Now, if you could figure out a way to encourage them to get plugged. I remember years ago being annoyed at the loose security in the Tenex operating system that was prevalent on the early Arpanet. I couldn't get the wizards at BBN to "fix" the problems by the "usual" means. So, one day I took advantage of the holes and, across the net, all by myself with no confederates, obtained the password of the wizard of all wizards and sent it to him in a one word mail message. No other communication was necessary. He plugged the holes as fast as his fingers could type. I was a "good guy" and he knew it, but it took an actual event to drive the point home it wouldn't be too long before someone else would figure out the method i used an dperhaps not be so benign. Can you think of a similar thing to do? Or have you already done it? (I think not because what you are pointing out is going to take lots of thinking to solve. But, it has to start somewhere. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040316184301> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Fri 3 Apr 87 18:20:45-PST Date: 3 Apr 1987 21:18:43 EST Subject: Re: My Broadcast From: Dan Lynch To: jkh%violet.Berkeley.EDU@UCBVAX.BERKELEY.EDU (Jordan K. Hubbard) cc: hackers_guild@UCBVAX.BERKELEY.EDU, tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU In-Reply-To: <8704021845.AA08097@violet.berkeley.edu> John, I think you did a good thing. Testing for idiotic holes in the "system". Now, if you could figure out a way to encourage them to get plugged. I remember years ago being annoyed at the loose security in the Tenex operating system that was prevalent on the early Arpanet. I couldn't get the wizards at BBN to "fix" the problems by the "usual" means. So, one day I took advantage of the holes and, across the net, all by myself with no confederates, obtained the password of the wizard of all wizards and sent it to him in a one word mail message. No other communication was necessary. He plugged the holes as fast as his fingers could type. I was a "good guy" and he knew it, but it took an actual event to drive the point home it wouldn't be too long before someone else would figure out the method i used an dperhaps not be so benign. Can you think of a similar thing to do? Or have you already done it? (I think not because what you are pointing out is going to take lots of thinking to solve. But, it has to start somewhere. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704032140.a012362%40Huey.UDEL.EDU] <1987040316404900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: IP over x.25 Message-ID: <8704032140.a012362@Huey.UDEL.EDU> Date: Fri, 3-Apr-87 21:40:49 EST Article-I.D.: Huey.8704032140.a012362 Posted: Fri Apr 3 21:40:49 1987 Date-Received: Sun, 5-Apr-87 08:25:25 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 27 Approved: tcp-ip@sri-nic.arpa Gerd, I assume the X.25 connection is broken somewhere in the public-net path, perhaps in either of the national X.25 nets or in the X.75 gateway(s). To break that after two minutes of inactivity sounds broken in the extremus, especially if the restoration costs real Geld. On the other hand, your opens are cheap, about equivalent to twenty seconds of connect time, so maybe things aren't that bad, at least if the reset/open can be made transparent to your TCP/TELNET connection. Come to think of it, if the MILNET/ARPANET congestions is as fierce as you report, it might be cheaper to encapsulate IP datagrams as fast-select packets, rather than go through the complete virtual-circuit clankery. This might be a fun puddle to go wading in. Lemme see, at twenty (roundtrip!) packets per Mark, you would break even at about seven minutes. Maybe not too bad under current conditions... While it is in principle possible to do all kinds of things which might convey the connection-closed state at the VAN gateway to the end systems, I suggest this would not be very useful if only to stimulate a re-open. If it really does come down to keeping the connection open, the VAN driver could be modified to send ICMP echoes to its peer just often enough to reset the VAN timers. Be advised you did not hear me say this, for I am not present and will instantly disavow any attribution of such nonsense to mine lips. Now, I hope that will keep the truthspeakers from my throat. Yes, and stop the ICMP echoes after a period when no other traffic is present. [Gaggg] Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704040348.AA22877%40maccs.UUCP] <1987040317485100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gordan@maccs.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8704040348.AA22877@maccs.UUCP> Date: Fri, 3-Apr-87 22:48:51 EST Article-I.D.: maccs.8704040348.AA22877 Posted: Fri Apr 3 22:48:51 1987 Date-Received: Sun, 5-Apr-87 08:42:00 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 32 Approved: tcp-ip@sri-nic.arpa Path: maccs!gordan From: gordan@maccs.UUCP (Gordan Palameta) Newsgroups: mod.protocols.tcp-ip Subject: TCP retransmission Keywords: retransmission algorithm Message-ID: <519@maccs.UUCP> Date: 4 Apr 87 03:48:50 GMT Reply-To: gordan@maccs.UUCP (Gordan Palameta) Distribution: world Organization: DCSS, McMaster University, Hamilton, Ontario, Canada Lines: 20 Hello... I'm currently writing some TCP-IP code (for a PDP-11 running RT-11), and am looking to do retransmissions correctly. From what I've read here, poor retransmission behavior is a major source of congestion... although my code is intended for a very lightly loaded Ethernet and I can get away with being sloppy, if there's a painless way to do it right for the general case, it would be nice to put it in. I understand the idea of exponential backoff, and know of the RTT-based algorithm suggested in the RFC (which I believe is what BSD 4.2 uses (?))... is this the proper algorithm to use, or is there a better one? Thanks for any info... -- UUCP: ... !seismo!mnetor!lsuc!maccs!gordan (note ..dAn or mail may bounce) BITNET: GP@TANDEM ^ <---' Gordan Palameta ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704040418.AA09934%40hi] <1987040318182600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cyrus@hi.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Ethernet TCP/IP broadcasts: help Message-ID: <8704040418.AA09934@hi> Date: Fri, 3-Apr-87 23:18:26 EST Article-I.D.: hi.8704040418.AA09934 Posted: Fri Apr 3 23:18:26 1987 Date-Received: Sun, 5-Apr-87 08:41:41 EST References: <459@cernvax.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: hi!cyrus@hc.dspo.gov (Tait Cyrus) Distribution: world Organization: U. of New Mexico, Albuquerque Lines: 52 Approved: tcp-ip@sri-nic.arpa In article <459@cernvax.UUCP> cernvax!jmg () writes: > >Last Wednesday (yes, it was April 1st; no it was NO JOKE) we got a >situation on our Ethernet where a particular telnet RST packet from >a host to a client was being sent inside a broadcast packet. The >trouble was that this same broadcast packet was being sent out repeatedly >by just about every TCP/IP host on our Ethernet (including both VMS >with Wollongong and 4.2BSD). Thus, we were seeing about 1000 broadcast >packets per second, coming from many diffferent sources but all containing >this same RST information. This was, of course, killing all the small >microvaxes and weaker 750/780 etc., with only the big 8800 having enough >clout to continue apparently normally. > >We eventually stopped it by disconnecting all of the offenders, much >to their disgust. After that everything started fine. > >Since we started installing Ethernet some years ago we have never seen >such a catastrophic situation. Therefore, if anyone has any idea why >so many vaxes should start rebroadcasting packets which were nothing >to do with them I should be eternally grateful. > >Mike Gerard We had a simular problem with one of our micro vax II running Ultrix. There had been a brown out (power surge) and all our machines continued to run (more uvax II's and sun 2's and 3's). We noticed that the network was slow though. After some investigation we determined that this one uvax II was rebroadcasting every packet on the network 4, yes four times. We tried 'ifconfig down' and then 'ifconfig up' without any success. The only thing we could do was to reboot. A possible explanation was that the dequna's table of valid ethernet addresses to accept got hosed. If this occured then it would basically be like in promiscuous mode. On receiving these packets it would determine that none of the packets were for it so it would REbroadcast these packets. This still does not explain why it was duplicating packets. Strange............ Sorry this is no help but, .... -- @__________@ W. Tait Cyrus (505) 277-0806 /| /| University of New Mexico / | / | Dept of EECE - Hypercube Project @__|_______@ | Albuquerque, New Mexico 87131 | | | | | | hc | | e-mail: | @.......|..@ cyrus@hc.dspo.gov or cyrus@hc.arpa or | / | / {gatech|ucbvax|convex}!unmvax!hi!cyrus @/_________@/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040405403200> Received: from mitre.ARPA by SRI-NIC.ARPA with TCP; Sat 4 Apr 87 07:56:34-PST Full-Name: Hugh Mckee Message-Id: <8704041540.AA11587@mitre.ARPA> Organization: The MITRE Corp., Washington, D.C. To: CERF@A.ISI.EDU Cc: mckee@mitre.ARPA, tcp-ip@SRI-NIC.ARPA, m15368%mwvm@mitre.ARPA Subject: Layer 2 muxing on ISDN In-Reply-To: Your message of 01 Apr 87 21:28:00 -0500. <[A.ISI.EDU] 1-Apr-87 21:28:17.CERF> Date: Sat, 04 Apr 87 10:40:32 EST From: H. Craig McKee The proposed Frame Relay service of ISDN does do layer 2 multiplexing. In LAPD, there is a 2 byte address containing a 6 bit SAPI and a 7 bit TEI (Terminal Equipment Identifier). These 2 fields are combined into a 13 bit DLCI (Data Link Connection Identifier) which would be handled similarly to the LCN in X.25. It would be mapped and set in each node as a frame progressed through the network. Then a new CRC would be calculated and inserted. * * Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704041704.AA11987%40mitre.ARPA] <1987040407042700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mckee@MITRE.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: overloaded station wagon Message-ID: <8704041704.AA11987@mitre.ARPA> Date: Sat, 4-Apr-87 12:04:27 EST Article-I.D.: mitre.8704041704.AA11987 Posted: Sat Apr 4 12:04:27 1987 Date-Received: Sun, 5-Apr-87 11:45:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The MITRE Corp., Washington, D.C. Lines: 29 Approved: tcp-ip@sri-nic.arpa >Forgive my inexperience at these things. >I was just under the impression >that such conversations are usually carried on elsewhere. >I am being forced to filter my mail, >to distill other more useful information on TCP/IP. Come on, friend, lighten up, we are an eclectic group. If you have no use for an Illudium Q-2 Explosive Network Demodulator then I offer the following story concerning the relative skills of French and German diplomats. At a banquet celebrating the fiftieth birthday of a reigning Queen, whose name I will not mention for the sake of tact, every country contributed a typical dish to the meal. Unfortunately, the frijoles refritos from Mexico and garbanzos from Spain very soon affected the delicate digestion of the Queen. In a moment of silence, one could hear, very definitely from the seat of honor, the sound of escaping air. Immediately, the French Ambassador, purple-faced, was on his feet saying, "Madame, I beg you, mille pardons, but my digestive system has been very labile. I have been warned by my doctor to eat bland foods but have been unable to resist these delicacies." This, of course, was a serious diplomatic defeat for the other ambassadors present, and was particularly felt by the representative of the Third Reich, one Joachim von Ribbentrop. With a keen ear, he awaited another such happening from the royal presence, and when it occurred, he jumped to his feet, clicked his heels, and bowed, shouting, "Madame, this one and the next three are for the Third Reich." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704042104.AA19894%40ucbvax.Berkeley.EDU] <1987040410384200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: malis@CC5.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Packet network reliability Message-ID: <8704042104.AA19894@ucbvax.Berkeley.EDU> Date: Sat, 4-Apr-87 15:38:42 EST Article-I.D.: ucbvax.8704042104.AA19894 Posted: Sat Apr 4 15:38:42 1987 Date-Received: Sun, 5-Apr-87 13:11:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 32 Approved: tcp-ip@sri-nic.arpa Darrel, I'm afraid your experiment wouldn't cause much as much routing traffic as you think. Your details on the PSN routing algorithm were a bit wrong. First, there are three things that can cause a routing update to be generated: a link going up or down, the delay to a neighbor PSN changing more than a certain threshold, or the expiration of 50 seconds from the last time the PSN generated an update. Second, a PSN can generate an update at most every 10 seconds, no matter how much is changing in the network. Third, when a link goes down, it takes 60 seconds to bring it back up (this ensures that if a PSN was isolated from the network, it cannot bring up its links until it has received at least one routing update from every other PSN in the network; otherwise, its routing database would be incomplete). The estimated time for a routing update to propagate through the network is simply the network "diameter" (the minimum-hop path between the two most logically distant PSNs in the network) times the average propagation delay across the links. Flooding routing updates gets the highest priority in the PSN, so intra-PSN delays are usually negligible. Since routing updates cannot be generated at a greater rate than every 10 seconds by each PSN and at least every 50 seconds, it is easy to calculate the minimum, average, and maximum number of routing updates per minute on a network. And since the line up/down protocol keeps links down for at least 60 seconds, manually making links go up or down will probably not produce any more updates than you would have had anyway. Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040410384201> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Sat 4 Apr 87 12:49:42-PST To: AFDDN.TCP-IP@gunter-adam.ARPA cc: tsuchiya@gateway.mitre.org, tcp-ip@sri-nic.ARPA, malis@cc5.bbn.com Subject: Re: Packet network reliability In-reply-to: Your message of 2 Apr 1987 12:33:26 CST. Date: 04 Apr 87 15:38:42 EST (Sat) From: Andy Malis Darrel, I'm afraid your experiment wouldn't cause much as much routing traffic as you think. Your details on the PSN routing algorithm were a bit wrong. First, there are three things that can cause a routing update to be generated: a link going up or down, the delay to a neighbor PSN changing more than a certain threshold, or the expiration of 50 seconds from the last time the PSN generated an update. Second, a PSN can generate an update at most every 10 seconds, no matter how much is changing in the network. Third, when a link goes down, it takes 60 seconds to bring it back up (this ensures that if a PSN was isolated from the network, it cannot bring up its links until it has received at least one routing update from every other PSN in the network; otherwise, its routing database would be incomplete). The estimated time for a routing update to propagate through the network is simply the network "diameter" (the minimum-hop path between the two most logically distant PSNs in the network) times the average propagation delay across the links. Flooding routing updates gets the highest priority in the PSN, so intra-PSN delays are usually negligible. Since routing updates cannot be generated at a greater rate than every 10 seconds by each PSN and at least every 50 seconds, it is easy to calculate the minimum, average, and maximum number of routing updates per minute on a network. And since the line up/down protocol keeps links down for at least 60 seconds, manually making links go up or down will probably not produce any more updates than you would have had anyway. Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704042139.AA28927%40ACC-SB-UNIX.ARPA] <1987040411394300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kzm@ACC-SB-UNIX.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Wiretapping ICMP messages Message-ID: <8704042139.AA28927@ACC-SB-UNIX.ARPA> Date: Sat, 4-Apr-87 16:39:43 EST Article-I.D.: ACC-SB-U.8704042139.AA28927 Posted: Sat Apr 4 16:39:43 1987 Date-Received: Sun, 5-Apr-87 13:13:24 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 32 Approved: tcp-ip@sri-nic.arpa There have been a number of suggestions on this list recently that congestion-control could be enhanced if various IP implementations took note of ICMP Destination Unreachable messages, eg. if gateways cached the information and refused to send packets based on this cached information. It appears to me that this could cause problems when the routing and congestion algorithms are upgraded to include TOS-routing, Precedence, and Security. TOS-routing may not be available yet, but it appears to be considered a desirable addition in the (not too distant) future. When it is available, a destination might be reachable with one TOS value, but not with another. Similarly, there is work underway to have packets queued in switches (eg. in IMPs) according to their Precedence. So, a similar scenario (reachable with a high Precedence value, but not with a low value) could be applicable here also. The use of Security information as a routing criteria may be further into the future, but the same considerations apply. Of course, the cached information could be expanded to include TOS, Precedence and Security along with the destination address. The size of the cache would increase, but probably manageably-so for the time being while the majority of packets have the same TOS/Precedence /Security values. However, this could cause a "scaling-up" problem in the future. Also, the mechanism loses some of its usefulness when it can only be applied to packets of the same TOS, Precedence, and Security. Again, this might not a problem today when the majority of packets have the same TOS/Precedence/Security values, but does it cater to the future ? Keith McCloghrie ACC, Columbia Md. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704050218.AA22481%40hoptoad.uucp] <1987040416184300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gnu@hoptoad.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: multicast on ether Message-ID: <8704050218.AA22481@hoptoad.uucp> Date: Sat, 4-Apr-87 21:18:43 EST Article-I.D.: hoptoad.8704050218.AA22481 Posted: Sat Apr 4 21:18:43 1987 Date-Received: Sun, 5-Apr-87 14:48:32 EST References: <8704030214.a001249@Huey.UDEL.EDU> <8704031719.AA28257@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 48 Approved: tcp-ip@sri-nic.arpa brescia@CCV.BBN.COM (Mike Brescia) writes: > The goal is to completely eliminate use of the broadcast address. TCP/IP > implementations may be overusing this feature, between ARP, RWHO, etc. I heartily agree with this goal. While working at Sun I noticed a large number of broadcast packets passing around, and this caused a few amusing problems, especially when these packets were addressed to user-mode daemons which swapped in over the ether. Note, however, that the current volume of broadcasts has the worst impact on hosts with old or badly designed Ethernet interfaces, e.g. 3Com boards with one or two receive buffers. These interfaces typically don't filter multicast packets anyway -- you can set a bit saying "receive multicast" or "toss multicast" and no more. Moving broadcast applications to multicast will only benefit hosts with more modern, e.g. AMD or Intel VLSI, interfaces. > Go to the ethernet number czar and get two (2) groups of 65536 (2^^16) > multicast addresses. By that, I mean the high order 32 bits are assigned by > the czar, and the low 16 bits are ours to play with. It might be worth looking at the filtering algorithms in the common Ethernet chips before figuring out the configuration of the multicast numbers. Typically they hash the addresses down to ~6 bits and the user supplies a 64-bit filter mask. We should try to match the number assignment to the hash functions. > Thus ARP, > instead of polluting all the hosts in the net, would send to the address > .8.6 (0x0806 is the number assigned to the address resolution > protocol). Virtually every host has to implement ARP so they will all be listening on .8.6 and there would be no benefit over just broadcasting. In the case of ARP, it would be better if the multicast address included the low byte of the Internet address you're looking for, so that hosts which don't know anything about that Internet address could ignore the packet in hardware. Note that most machines on one Ethernet will have the same high 3 bytes of their Internet address, so supplying the whole thing would be overkill. If a scheme like this gets worked out, I suggest that we allocate a bit in the ARP packets for "I listen to multicast for IP broadcasts", to tell a sending kernel which scheme to use (like the trailer protocol stuff). This begs the question of how the sending kernel decides how to send the ARP Request packet, but we're designing on the fly here anyway. Of course, a receiving kernel that handles multicasts should also accept the old broadcast packets for compatability. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704051509.AA02296%40MCR.UMICH.EDU] <1987040505090700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hwb@MCR.UMICH.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: multicast groups on ether Message-ID: <8704051509.AA02296@MCR.UMICH.EDU> Date: Sun, 5-Apr-87 10:09:07 EST Article-I.D.: MCR.8704051509.AA02296 Posted: Sun Apr 5 10:09:07 1987 Date-Received: Sun, 5-Apr-87 22:38:15 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa You have to watch out, though. Most interfaces I know of only support a limited set of multicast addresses (DEQNAs, I think, just have a table for fourteen or so addresses in general). You don't really want to end up having to listen to each and every packet in a multiprotocol gateway, just because your multicast address table in the EThernet device overflows. -- Hans-Werner ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1987.4.5.16.13.47.Rudy.Nedved%40h.cs.cmu.edu] <1987040506211500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Rudy.Nedved@H.CS.CMU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network Message-ID: <1987.4.5.16.13.47.Rudy.Nedved@h.cs.cmu.edu> Date: Sun, 5-Apr-87 11:21:15 EST Article-I.D.: h.1987.4.5.16.13.47.Rudy.Nedved Posted: Sun Apr 5 11:21:15 1987 Date-Received: Sun, 5-Apr-87 23:43:54 EST References: <8704030246.AA02484@gwen.cs.purdue.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa The concept of distributing internal configuration information to everyone in the world is too prone to failures from too much information. Assuming that people will extensively use the domain system to publish current routing information for mailboxes and dealing with cacheing and all the other problems is expecting too much. The idea is a nice one alas a very flawed one (from too much data). The trick at this pont is to just get a reasonable mail relaying mechansim up and to get rid of the host table. The MX records solve in a not so great way the problem of mail relaying for hosts not on the connected network alas a better algorithm has not been thought up that did not get shot down (heck, we can not even get packet routing right...how do you expect to get mail routing right?) Also many places are still using the host table mechanism and are starting to suffer because of the size problems....alas they have received temporary relief in the form of a 10% smaller NIC table. Let us keep an eye toward the future but make that first couple of steps instead of just dreaming about the future.... -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1987.4.5.16.35.48.Rudy.Nedved%40h.cs.cmu.edu] <1987040506571200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Rudy.Nedved@H.CS.CMU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <1987.4.5.16.35.48.Rudy.Nedved@h.cs.cmu.edu> Date: Sun, 5-Apr-87 11:57:12 EST Article-I.D.: h.1987.4.5.16.35.48.Rudy.Nedved Posted: Sun Apr 5 11:57:12 1987 Date-Received: Sun, 5-Apr-87 23:44:20 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Whoa! Encouraging people to find holes and then use them to make the local system programmers work on them is wrong. It is like encouraging people to find out if their neighbors lock their door during the day so they will. Do you really want that or do you want the theives to be caught? I want the theives to be caught and the ability to leave my door open. I don't want to fear my neighborhood or my users. I could spend many man years working on Unix security alone. The same is TRUE with TOPS-20. The worst is when you fix a security problem and some yo-yo finds out about it and then attacks some other remote site. The remote site gets pissed and says it can not afford to fix it....would you please deal with the yo-yo. -RUdy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040507090000> Received: from pescadero.stanford.edu by SRI-NIC.ARPA with TCP; Sun 5 Apr 87 17:33:40-PDT Received: by pescadero.stanford.edu with Sendmail; Sun, 5 Apr 87 16:30:06 pst Date: 5 Apr 1987 15:09-PST From: Steve Deering Subject: Re: multicast on ether To: Hans-Werner Braun , hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore) Cc: tcp-ip@sri-nic.ARPA, tsuchiya@mitre-gateway.ARPA, x3s33-interest@mitre-gateway.ARPA Message-Id: <87/04/05 1509.510@pescadero.stanford.edu> In-Reply-To: hoptoad.UUCP!gnu's message of Sat, 4 Apr 87 181843 PST From Hans-Werner Braun : You have to watch out, though. Most interfaces I know of only support a limited set of multicast addresses (DEQNAs, I think, just have a table for fourteen or so addresses in general). You don't really want to end up having to listen to each and every packet in a multiprotocol gateway, just because your multicast address table in the EThernet device overflows. You don't have to listen to every packet, just every *multicast* packet, when your multicast filter is exceeded. The DEQNA and other interfaces provide such a reception mode. If we are just replacing broadcast packets with multicast packets, listening to all multicasts is no worse than the current situation of having to listen to all broadcasts. However, using multicast addresses is much better for those hosts that *are* able to filter multicasts adequately. Besides, it is not unreasonable to expect a sophisticated multiprotocol gateway to have a sophisticated Ethernet interface. The important thing is to stop sending unwanted packets to non-gateway hosts. I agree that we should conserve multicast addresses by looking out for situations in which more than one application may reasonably use the same multicast address, but I don't think we should be bound by the limitations of current hardware. Once there is a demand for good multicast filtering, the manufacturers will improve their products. From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore) It might be worth looking at the filtering algorithms in the common Ethernet chips before figuring out the configuration of the multicast numbers. Typically they hash the addresses down to ~6 bits and the user supplies a 64-bit filter mask. We should try to match the number assignment to the hash functions. That's a good idea if they all use the same hash function. Both the AMD 7990 and the Intel 82586 send incoming multicast addresses though their CRC generators and take 6 bits of the result as a hash value, as you described. From the documents I have, it is not obvious that they both use the same 6 bits of the CRC in the same order. (Can anyone say for sure?) Are there other hashing functions in use in other interfaces? Virtually every host has to implement ARP so they will all be listening on .8.6 and there would be no benefit over just broadcasting. Hosts that aren't running IP aren't interested in ARP-for-IP packets. Some of us share Ethernets with hosts running Pup, Chaos, XNS, or ISO protocols. We don't like their broadcasts and they don't like ours. If a scheme like this gets worked out, I suggest that we allocate a bit in the ARP packets for "I listen to multicast for IP broadcasts", to tell a sending kernel which scheme to use (like the trailer protocol stuff). I don't think any new bits are needed. Just send your ARP requests to the multicast address, and if you don't get an answer, try the broadcast address. Steve Deering ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704051236.a010488%40Huey.UDEL.EDU] <1987040507363100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ICMP As A Diagnostic Tool? Message-ID: <8704051236.a010488@Huey.UDEL.EDU> Date: Sun, 5-Apr-87 12:36:31 EST Article-I.D.: Huey.8704051236.a010488 Posted: Sun Apr 5 12:36:31 1987 Date-Received: Mon, 6-Apr-87 01:39:34 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Miles, I suggest you invite co-BBNer Mike Brescia (X3662) for a beer and learn all about ICMP uses and abuses. This is not a frivolous suggestion. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704051248.a010582%40Huey.UDEL.EDU] <1987040507481300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ICMP As A Diagnostic Tool? Message-ID: <8704051248.a010582@Huey.UDEL.EDU> Date: Sun, 5-Apr-87 12:48:13 EST Article-I.D.: Huey.8704051248.a010582 Posted: Sun Apr 5 12:48:13 1987 Date-Received: Mon, 6-Apr-87 01:40:55 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa Vint, Well, I don't know about that, although I (modestly) claim to have invented the term "ping" (Packet InterNet Groper) circa 1979. Mike Brescia at BBN, Hans-Werver Braun at U Michigan and others have a lot of grease under their fingernails. Having said that, I can't imagine an internet (small i), ISO or any other, viable in even the weakest sense without something like ICMP built into the protocol stack at outset. I even have to resist saying that agian for emphasis. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704051451.a011392%40Huey.UDEL.EDU] <1987040509515400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Wiretapping ICMP messages Message-ID: <8704051451.a011392@Huey.UDEL.EDU> Date: Sun, 5-Apr-87 14:51:54 EST Article-I.D.: Huey.8704051451.a011392 Posted: Sun Apr 5 14:51:54 1987 Date-Received: Mon, 6-Apr-87 01:44:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Keith, The mechanism I suggested some time ago involves cacheing ICMP messages of selected types for a period longer than the typical TCP retransmission interval, but shorter than the typical "retry" interval, maybe a couple of minutes or so. I did not specify which message types should be cached and what detail information (TOS, etc.) should be saved, but did assume as much information as useful in the routing algorithm. My suggestion would not affect routing until a number of these messages (tbd) had been received within a period equal to some number of TCP retransmissions, maybe fifteen to thirty seconds. When that happened the local routing data base would be marked "down" for that destination net/TOS/whatever and the normal routing exchanges would do the rest. You will note this is functionally identical to the hard-to-reach concept used in the telephone network, except that routing updates per se are not used in that network (#4 ESS non-hierarchical routing honkers will be politely ignored here). I am not suggesting now as the optimum time to construct a definitive proposal on how to implement this concept in a j-random gateway, but am suggesting the concept ripe for experimentation in a real gateway, maybe even a fuzzball. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704051517.a011510%40Huey.UDEL.EDU] <1987040510165900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Time RFC 868 Message-ID: <8704051517.a011510@Huey.UDEL.EDU> Date: Sun, 5-Apr-87 15:16:59 EST Article-I.D.: Huey.8704051517.a011510 Posted: Sun Apr 5 15:16:59 1987 Date-Received: Mon, 6-Apr-87 01:45:24 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 37 Approved: tcp-ip@sri-nic.arpa You can't keep "exact time" with RFC-868 time servers, since that protocol provides resolution only to the second. You should really and truly avoid TCP-based time, since not only is the accuracy udually degraded by the clank-and-bump of the connection-open sequence, but the sometimes meager resources of the time server can be strained. The protocol of choice is the Network Time Protocol (NTP), documented in RFC-958, for which Unix- based server and client programs are available (e.g. Mike Petry petry@trantor.umd.edu, Milo Medin medin@orion.arpa, both for 4.3 systems). As for the most accurate clocks in town, a fair number of "fuzzball" gateways and hosts are equipped with WWVB and WWV radio clocks that can deliver time accurate to a millisecond or two. Typical accuracies using NTP via ARPANET/MILNET are within 20 to 100 milliseconds, depending on the path and state of congestion. The fuzzballs are interconnected with NTP and, in some cases an interior-gateway protocol called hellospeak (c.f. RFC-891), so a failure in one radio clock does not frustrate the clockwatchers. At present the NSFNET Backbone sites are all synchronized to a WWVB radio clock at Boulder, CO, and capable of very accurate and robust time service using RFC-868 or NTP protocols. Use of TCP is adamantly discourged with the former and not available with the latter. UDP is the prefered envelope in any case. In addition, several WWVB-equipped servers are scattered about, including macom1.arpa (192.5.8.1), umd1.umd.edu (128.8.10.6) and ford1.arpa (182.5.0.1 - actually a GOES clock). Finally, a few hosts scattered over the swamps support less-accurate WWV radio which are also used as backups for the NTP system, including gw.umich.edu (35.1.1.1) and udel2.udel.edu (192.5.39.87). If present plans work out, the best places to watch clocks will be the NSFNET Backbone fuzzballs or other hosts synchronized directly to them. An announcement will be posted to this list when the details stabilize. Meanwhile, feel free watch one or more of the clocks above, with the first two (macom1.arpa or umd1.umd.edu) as the primary choice, but please don't use TCP. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12292156010.22.ROODE%40BIONET-20.ARPA] <1987040510293900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROODE@BIONET-20.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: anti-bridge comment Message-ID: <12292156010.22.ROODE@BIONET-20.ARPA> Date: Sun, 5-Apr-87 15:29:39 EST Article-I.D.: BIONET-2.12292156010.22.ROODE Posted: Sun Apr 5 15:29:39 1987 Date-Received: Mon, 6-Apr-87 01:45:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa I don't think anyone has pointed out the following advantage of an IP gateway over a level 2 bridge between physical Ethernets. Ethernet broadcasts are filtered by IP gateways whereas in the case of bridges, full IP functionality between gateways requires that all Ethernets so joined see the combined broadcasts of each network in the group. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [87.04.05.1509.510%40pescadero.stanford.edu] <1987040513090000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: deering@PESCADERO.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: multicast on ether Message-ID: <87.04.05.1509.510@pescadero.stanford.edu> Date: Sun, 5-Apr-87 18:09:00 EST Article-I.D.: pescader.87.04.05.1509.510 Posted: Sun Apr 5 18:09:00 1987 Date-Received: Mon, 6-Apr-87 03:39:00 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 60 Approved: tcp-ip@sri-nic.arpa From Hans-Werner Braun : You have to watch out, though. Most interfaces I know of only support a limited set of multicast addresses (DEQNAs, I think, just have a table for fourteen or so addresses in general). You don't really want to end up having to listen to each and every packet in a multiprotocol gateway, just because your multicast address table in the EThernet device overflows. You don't have to listen to every packet, just every *multicast* packet, when your multicast filter is exceeded. The DEQNA and other interfaces provide such a reception mode. If we are just replacing broadcast packets with multicast packets, listening to all multicasts is no worse than the current situation of having to listen to all broadcasts. However, using multicast addresses is much better for those hosts that *are* able to filter multicasts adequately. Besides, it is not unreasonable to expect a sophisticated multiprotocol gateway to have a sophisticated Ethernet interface. The important thing is to stop sending unwanted packets to non-gateway hosts. I agree that we should conserve multicast addresses by looking out for situations in which more than one application may reasonably use the same multicast address, but I don't think we should be bound by the limitations of current hardware. Once there is a demand for good multicast filtering, the manufacturers will improve their products. From: hoptoad.UUCP!gnu@cgl.ucsf.edu (John Gilmore) It might be worth looking at the filtering algorithms in the common Ethernet chips before figuring out the configuration of the multicast numbers. Typically they hash the addresses down to ~6 bits and the user supplies a 64-bit filter mask. We should try to match the number assignment to the hash functions. That's a good idea if they all use the same hash function. Both the AMD 7990 and the Intel 82586 send incoming multicast addresses though their CRC generators and take 6 bits of the result as a hash value, as you described. From the documents I have, it is not obvious that they both use the same 6 bits of the CRC in the same order. (Can anyone say for sure?) Are there other hashing functions in use in other interfaces? Virtually every host has to implement ARP so they will all be listening on .8.6 and there would be no benefit over just broadcasting. Hosts that aren't running IP aren't interested in ARP-for-IP packets. Some of us share Ethernets with hosts running Pup, Chaos, XNS, or ISO protocols. We don't like their broadcasts and they don't like ours. If a scheme like this gets worked out, I suggest that we allocate a bit in the ARP packets for "I listen to multicast for IP broadcasts", to tell a sending kernel which scheme to use (like the trailer protocol stuff). I don't think any new bits are needed. Just send your ARP requests to the multicast address, and if you don't get an answer, try the broadcast address. Steve Deering ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704060811.AA09897%40ucbvax.Berkeley.EDU] <1987040518380000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: anon@CITI.UMICH.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: overloaded station wagon Message-ID: <8704060811.AA09897@ucbvax.Berkeley.EDU> Date: Sun, 5-Apr-87 23:38:00 EST Article-I.D.: ucbvax.8704060811.AA09897 Posted: Sun Apr 5 23:38:00 1987 Date-Received: Wed, 8-Apr-87 00:18:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa Shades of James Watt and the Beach Boys. Apologies, everyone. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040520380000> Received: from citi.umich.edu by SRI-NIC.ARPA with TCP; Sun 5 Apr 87 21:43:26-PDT From: anon@citi.umich.edu To: mckee@mitre.ARPA Cc: tcp-ip@sri-nic.ARPA Date: 6 Apr 1987 00:38 EDT Subject: Re: overloaded station wagon Shades of James Watt and the Beach Boys. Apologies, everyone. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12292273571.8.MRC%40PANDA] <1987040521152600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: usenet@ucbvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <12292273571.8.MRC@PANDA> Date: Mon, 6-Apr-87 02:15:26 EST Article-I.D.: PANDA.12292273571.8.MRC Posted: Mon Apr 6 02:15:26 1987 Date-Received: Wed, 8-Apr-87 00:25:16 EST References: Distribution: world Organization: The ARPA Internet Lines: 52 Approved: tcp-ip@sri-nic.arpa Dan - I'm afraid you (and I, and any of the other old-timers who care about security) are banging your head against a brick wall. The philsophy behind Unix largely seems quite reminiscent of the old ITS philsophy of "security through obscurity;" we must entrust our systems and data to a open-ended set of youthful hackers (the current term is "gurus") who have mastered the arcane knowledge. The problem is further exacerbated by the multitude of slimy vendors who sell Unix boxes without sources and without an efficient means of dealing with security problems as they develop. I don't see any relief, however. There are a lot of politics involved here. Some individuals would rather muzzle knowledge of Unix security problems and their fixes than see them fixed. I feel it is *criminal* to have this attitude on the DDN, since our national security in wartime might ultimately depend upon it. If there is such a breach, those individuals will be better off if the Russians win the war, because if not there will be a Court of Inquiry to answer... It may be necessary to take matters into our own hands, as you did once before. I am seriously considering offering a cash reward for the first discoverer of a Unix security bug, provided that the bug is thoroughly documented (with both cause and fix). There would be a sliding cash scale based on how devastating the bug is and how many vendors' systems it affects. My intention would be to propagate the knowledge as widely as possible with the express intension of getting these bugs FIXED everywhere. Knowledge is power, and it properly belongs in the hands of system administrators and system programmers. It should NOT be the exclusive province of "gurus" who have a vested interest in keeping such details secret. -- Mark -- PS: Crispin's definition of a "somewhat secure operating system": A "somewhat secure operating system" is one that, given an intelligent system management that does not commit a blunder that compromises security, would withstand an attack by one of its architects for at least an hour. Crispin's definition of a "moderately secure operating system": a "moderately secure operating system" is one that would withstand an attack by one of its architects for at least an hour even if the management of the system are total idiots who make every mistake in the book. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [460%40cernvax.UUCP] <1987040521260200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kik@CERNVAX.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Response to anti-bridge comments Message-ID: <460@cernvax.UUCP> Date: Mon, 6-Apr-87 02:26:02 EST Article-I.D.: cernvax.460 Posted: Mon Apr 6 02:26:02 1987 Date-Received: Wed, 8-Apr-87 00:20:19 EST References: <8704022034.AA09965@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: cernvax!kik () Distribution: world Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Sw Lines: 29 Keywords: Bridge, network, load sharing Approved: tcp-ip@sri-nic.arpa I get the impression that, in the discussion on Bridge functionality, people are not taking enough trouble to distinguish between the *service* and the *communications*. The service is to filter and forward, based on destination address. There is no reason for the filtering not to be shared, in a disjoint way, by any number of devices. In fact, we intend to do this. The load-sharing and backup algorithms are designed and we plan to implement them on our own equipment once we get the time. The communications can be based on point-to-point links, satellites, etc. In fact, the choice of communications is limited only by your networking ability. For example, DEC and Vitalink have "invented" a spanning-tree approach to provide redundant communcation. This is really primitive. We, at CERN, use a genuine communications subnet with all of the build-in advantages (originally designed for inter-computer traffic, and all the better for that!). The ideal backbone for such purposes would be a high-speed bus-type network (we're hoping for FDDI). I am trying to rewrite the IEEE 802.1 document on MAC-level bridges to reflect the clear separation between a) address resolution and b) routing so that the current confusion can be avoided. Cheers Crispin PINEY ----MESSAGE-END---- ----MESSAGE-BEGIN---- [505.544691976%40UK.AC.UCL.CS] <1987040523422600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Steve.Kille@CS.UCL.AC.UK.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: GOSIP vs TCP/IP Message-ID: <505.544691976@UK.AC.UCL.CS> Date: Mon, 6-Apr-87 04:42:26 EST Article-I.D.: UK.505.544691976 Posted: Mon Apr 6 04:42:26 1987 Date-Received: Wed, 8-Apr-87 00:20:56 EST References: <[A.ISI.EDU].1-Apr-87.21:44:04.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Right. X.25 on its own is not capable of end to end recovery. I was just making clear that this is not a deficiency in X.25, and that in the right combinations it is a sensible building block. Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(195)%2BTOPSLIB(124).6-Apr-87.07:19:50.VAX.DARPA.MIL] <1987040602195000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: Date: Mon, 6-Apr-87 07:19:50 EST Article-I.D.: Posted: Mon Apr 6 07:19:50 1987 Date-Received: Thu, 9-Apr-87 01:39:42 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa Jordan, you are right in your assumptions that people will get annoyed that what happened was allowed to happen. By the way, I am the program manager of the Arpanet in the Information Science and Technology Office of DARPA, located in Roslin (Arlington), not the Pentagon. I would like suggestions as to what you, or anyone else, think should be done to prevent such occurances in the furture. There are many drastic choices one could make. Is there a reasonable one? Perhaps some one from Sun could volunteer what there action will be in light of this revelation. I certainly hope that the community can come up with a good solution, because I know that when the problem gets solved from the top the solutions will reflect their concerns. Think about this situation and I think you will all agree that this is a serious problem that could cripple the Arpanet and anyother net that lets things like this happen without control. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040602195001> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Mon 6 Apr 87 05:22:44-PDT Posted-Date: Mon 6 Apr 87 07:19:50-EST Received: by vax.darpa.mil (5.54/5.51) id AA02528; Mon, 6 Apr 87 08:19:56 EDT Date: Mon 6 Apr 87 07:19:50-EST From: Dennis G. Perry Subject: Re: My Broadcast To: jkh%violet.Berkeley.EDU@berkeley.edu Cc: hackers_guild@ucbvax.berkeley.edu, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "jkh%violet.Berkeley.EDU@berkeley.edu (Jordan K. Hubbard)" of Thu, 2 Apr 87 10:45:46 PST Jordan, you are right in your assumptions that people will get annoyed that what happened was allowed to happen. By the way, I am the program manager of the Arpanet in the Information Science and Technology Office of DARPA, located in Roslin (Arlington), not the Pentagon. I would like suggestions as to what you, or anyone else, think should be done to prevent such occurances in the furture. There are many drastic choices one could make. Is there a reasonable one? Perhaps some one from Sun could volunteer what there action will be in light of this revelation. I certainly hope that the community can come up with a good solution, because I know that when the problem gets solved from the top the solutions will reflect their concerns. Think about this situation and I think you will all agree that this is a serious problem that could cripple the Arpanet and anyother net that lets things like this happen without control. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [194%40cos.COM] <1987040603455500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: howard@cos.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Time RFC 868 Message-ID: <194@cos.COM> Date: Mon, 6-Apr-87 08:45:55 EST Article-I.D.: cos.194 Posted: Mon Apr 6 08:45:55 1987 Date-Received: Wed, 8-Apr-87 03:41:35 EST References: <8704051517.a011510@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: Corporation for Open Systems, McLean, VA Lines: 33 Approved: tcp-ip@sri-nic.arpa Time synchronization has been a major issue in performance work. Several lessons learned may help. First, if at all possible, do not depend on a single time of day "message," but iterate to get a sense of path delay. A technique developed jointly by the Commerce Department (NBS Time Lab and Institute for Telecommunications Sciences) and Bell Labs illustrates. In this technique, assume a master-slave relationship for time setting, initiated by the slave. The slave contacts one (or more) master clock sites, and requests a download of the time of day. So far, this is traditional. However, the enhancement takes place after the master sends its time of day: the slave RETRANSMITS what it received. The master then calculates the difference (in time units) between what it sent and what the slave received, and sends that as a correction factor. The slave then algebraically adds this correction factor to its clock and retransmits the new value.This process repeats until the desired resolution is achieved. The first implementation of this method was over the AT&T dial network (there was one at the time). It turns out that the widely held belief that you cannot assume equal delay on both sides of a dial call is FALSE, at least for the AT&T routing plan. They do not, for example, assign one side to a terrestrial and one to a satellite facility; both go in the same way. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1100.544718414%40UK.AC.UCL.CS] <1987040603565000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Steve.Kille@CS.UCL.AC.UK.UUCP Newsgroups: mod.protocols.tcp-ip Subject: NIFTP Message-ID: <1100.544718414@UK.AC.UCL.CS> Date: Mon, 6-Apr-87 08:56:50 EST Article-I.D.: UK.1100.544718414 Posted: Mon Apr 6 08:56:50 1987 Date-Received: Thu, 9-Apr-87 01:28:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 45 Approved: tcp-ip@sri-nic.arpa This is just to expand a few details of Jon Crowcroft's note: NIFTP (Network Independent File Transfer Protocol) may be of some interest to the DARPA community, as it is currently more widely available than FTAM. There are a number of potential advantages of ARPA FTP, as Jon pointed out: - Many implementations support resumptions - Spooled implementations are available - the single channel makes gatewaying rather easier A copy of the protocol can be obtained from: ITSU Department of Trade and industry Kingsgate House 66-74 Victoria Street London SW1 The protocol will operate over TCP/IP, and has assigned sockets: 47 (straight NIFTP) 61 (NIFTP + JNT Mail) There are implementations for a wide range of machines. A full table of colured book implementations for the various machine ranages can be obtained from Dr. Bob Cooper who runs the Joint Network Team. A brief note on UNIX implementations, which I know are of particular interest. There is a JNT supported implemetnation, which is available through Spider Systems. Contact Andy Davis . However, this does not support either TCP or resumptions. There is another UNIX implementation, which is not supported but is being assembled as a public domain package by Cambridge/UCL/Nottingham. This is a very full implementation of the protocol, and has TCP/IP (4.2/4.3). We believe that this system is substantially better than the official one, but of course there is no support. We are currently doing testing as a smallish group, but the system will be distributed in due course, after it has been released to a number of beta sites. If anyone is interested, contact . Do NOT send messages to mailgroup@cs.ucl.ac.uk, as suggested by Jon. Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870406101639.2.DCP%40KOYAANISQATSI.S4CC.Symbolics.COM] <1987040604160000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DCP@QUABBIN.SCRC.SYMBOLICS.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: multicast groups on ether Message-ID: <870406101639.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Mon, 6-Apr-87 09:16:00 EST Article-I.D.: KOYAANIS.870406101639.2.DCP Posted: Mon Apr 6 09:16:00 1987 Date-Received: Wed, 8-Apr-87 03:40:55 EST References: <87.04.03.1555.090@pescadero.stanford.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 46 Approved: tcp-ip@sri-nic.arpa As I think some people have already tried to state, ** There is now standard for multicast addressing **. The only thing the blue Ethernet book says is that multicast addresses exist and here's what they look like. It does not say what functinality implementors of hardware interfaces should provide. It doesn't give any hints if implementations should allow filters on the top 24 bits, or the bottom 8 bits, or anything. Therefore, what Interlan does is different than what 3Com does which is different than what DEC does which is different.... Please don't go inventing ideas that work well on only one type of interface. I also suggest people separate network level packets like ARP from protocol like packets like RWHO, TFTP and Time. They are very different and you may find that the "solution" for each is different. I'm against adding IP-specific things to the handling of ARP. ARP is blatently non-IP specific (non-anything specific for that matter) and I fear putting in non-modular hooks between the layers will burden multi-protocol operatins systems at the expense of single-protocol systems. Additionally, it isn't easy to extend ARP to be Ethernet specific (e.g., have ARP-for-IP and ARP-for-CHAOS) since ARP doesn't know anything about Ethernet nor about IP and wouldn't know what to do if you told it. I conjecture that if there are excessive ARP packets on your cable, than one of two things is happening: Some station's cache isn't big enough (simple enough to solve), or some station isn't responding. XNS, Pup and Chaos routing present a constant (though supposedly low frequency) stream of broadcast packets. Multicast would probably be a good thing here, if we could figure out how multicast should work. RWho in my opinion should be flushed. It is an unsolicited user-level protocol. Time is (or should be) a solicited user-level protocol. I'd be surprised if it really caused excessive burden. Domain Name lookups are broadcast? New one on me. How often does BOOTP really happen? If the BOOTP protocol isn't able to latch on to the server address directly, I suggest the BOOTP protocol be changed to do so. A PDP-11 netboot protocol I wrote 5 years ago did indeed broadcast the initial request and then latched onto the server. Everybody is burdened with one, perhaps two, packets and then never hears from the booter again. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704061627.AA15715%40violet.berkeley.edu] <1987040606275200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jkh@VIOLET.BERKELEY.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <8704061627.AA15715@violet.berkeley.edu> Date: Mon, 6-Apr-87 11:27:52 EST Article-I.D.: violet.8704061627.AA15715 Posted: Mon Apr 6 11:27:52 1987 Date-Received: Wed, 8-Apr-87 05:15:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa Dennis, Sorry about the mixup on your location and position within DARPA. I got the news of your call to Richard Olson second hand, and I guess details got muddled along the way. I think the best solution to this problem (and other problems of this nature) is to tighten up the receiving ends. Assuming that the network is basically hostile seems safer than assuming that it's benign when deciding which services to offer. I don't know what Sun has in mind for Secure RPC, or whether they will move the release date for 4.0 (which presumably incorporates these features) closer, but I will be changing rwalld here at Berkeley to use a new YP database containing a list of "trusted" hosts. If it's possible to change RPC itself, without massive performance degradation, I may do that as well. My primary concern is that people understand where and why unix/network security holes exist. I've gotten a few messages from people saying that they would consider it a bug if rwall *didn't* perform in this manner, and that hampering their ability to communicate with the rest of the network would be against the spirit of all it stands for. There is, of course, the opposite camp which feels that IMP's should only forward packets from hosts registered with the NIC. I think that either point of view has its pros and cons, but that it should be up to the users to make a choice. If they wish to expose themselves to potential annoyance in exchange for being able to, uh, communicate more freely, then so be it. If the opposite is true, then they can take appropriate action. At least an informed choice will have been made. Yours for a secure, but usable, network. Jordan Hubbard ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12292375789.16.PALLAS%40Sushi.Stanford.EDU] <1987040606365600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PALLAS@SUSHI.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <12292375789.16.PALLAS@Sushi.Stanford.EDU> Date: Mon, 6-Apr-87 11:36:56 EST Article-I.D.: Sushi.12292375789.16.PALLAS Posted: Mon Apr 6 11:36:56 1987 Date-Received: Wed, 8-Apr-87 04:37:19 EST References: <12292273571.8.MRC@PANDA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa I see that, as usual, Mark Crispin has tried to turn a constructive discussion into a diatribe against Unix. If there's a point to his flame, however, it escapes me. It does bear an entertaining resemblance to some conspiracy theories I've heard, I must admit. Crispin's definition of a "somewhat secure operating system": A "somewhat secure operating system" is one that, given an intelligent system management that does not commit a blunder that compromises security, would withstand an attack by one of its architects for at least an hour. "You stupid fool, who told you to turn the damn thing on?!?" Crispin's definition of a "moderately secure operating system": a "moderately secure operating system" is one that would withstand an attack by one of its architects for at least an hour even if the management of the system are total idiots who make every mistake in the book. The first mistake in the book is to believe that the security of the operating system implies the security of the data, or rather that the system is an isolated entity which can be made "secure" independent of its environment. joe ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12292384675.34.GS%40DEEP-THOUGHT.MIT.EDU] <1987040607254400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: GS@DEEP-THOUGHT.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Case Studies/Information needed Message-ID: <12292384675.34.GS@DEEP-THOUGHT.MIT.EDU> Date: Mon, 6-Apr-87 12:25:44 EST Article-I.D.: DEEP-THO.12292384675.34.GS Posted: Mon Apr 6 12:25:44 1987 Date-Received: Wed, 8-Apr-87 03:17:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa Could someone provide pointers to recent papers or studies addressing implementation concerns of large local area networks using TCP/IP to communicate between 10-100 VAXes (or other larger-than-workstation system) and 1000-10,000 standalone workstations (PCs to Suns)? I would be particularly interested in experiences with unix, VMS or unix/VMS environments. The kind of information I am looking for is the DOs and DON'Ts of the architecture design and any tradeoffs that must be considered. I have a few naive questions also. Does performance of the network degrade as the number of hosts increases (independent of the amount of traffic)? Does the number of hosts defined in the namespace play a part? Can a large local area system cause a degradation in performance of a larger group (other intenet sites not in the local area)? Any information would be appreciated. Please respond directly as I am not a regular reader of this list. Gordon Strong gs%ee@mit-xx (Arpa) gs@mit-eddie (uucp) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704061653.AA16642%40ucbvax.Berkeley.EDU] <1987040607351600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <8704061653.AA16642@ucbvax.Berkeley.EDU> Date: Mon, 6-Apr-87 12:35:16 EST Article-I.D.: ucbvax.8704061653.AA16642 Posted: Mon Apr 6 12:35:16 1987 Date-Received: Wed, 8-Apr-87 04:36:43 EST References: <1987.4.5.16.35.48.Rudy.Nedved@h.cs.cmu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Well, Looks like we have (re)uncovered a can of mixed worms here. The example I gave was definitely in the "security" area and you should note that the method used to get it fixed involved exactly one "outside site", the site of the author of the operating system. The example of the broadcast that went "astray" is more accurately described as an "integrity" issue. With integrity one is concerned that the "system/facility" stay alive and functional under both normal use and many forms of abnormality. What we are learning with some of the facilities for message sending is that our "internet" is very highly connected and even can be considered to be too highly connected for some forms of (even innocent) misbehavior. How do we benefit from what we have learned thus far? Dennis has suggested that one of the manufacturers fix some code and/or defaults and/or procedures in its releases. I'm sure other manufacturers can do likewise should they also exhibit the same misfeatures in their offerings. But the big thing that we need to understand is that we do not understand how to live in these highly connected internets yet. Much more research needs to happen in the area of intergroup interactions. And much more tolerance needs to be exhibited towards those who are probing the edges of all this. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040607351601> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 6 Apr 87 09:39:44-PDT Date: 6 Apr 1987 12:35:16 EST Subject: Re: My Broadcast From: Dan Lynch To: Rudy.Nedved@H.CS.CMU.EDU cc: Dan Lynch , hackers_guild@UCBVAX.BERKELEY.EDU, tcp-ip@SRI-NIC.ARPA In-Reply-To: <1987.4.5.16.35.48.Rudy.Nedved@h.cs.cmu.edu> Well, Looks like we have (re)uncovered a can of mixed worms here. The example I gave was definitely in the "security" area and you should note that the method used to get it fixed involved exactly one "outside site", the site of the author of the operating system. The example of the broadcast that went "astray" is more accurately described as an "integrity" issue. With integrity one is concerned that the "system/facility" stay alive and functional under both normal use and many forms of abnormality. What we are learning with some of the facilities for message sending is that our "internet" is very highly connected and even can be considered to be too highly connected for some forms of (even innocent) misbehavior. How do we benefit from what we have learned thus far? Dennis has suggested that one of the manufacturers fix some code and/or defaults and/or procedures in its releases. I'm sure other manufacturers can do likewise should they also exhibit the same misfeatures in their offerings. But the big thing that we need to understand is that we do not understand how to live in these highly connected internets yet. Much more research needs to happen in the area of intergroup interactions. And much more tolerance needs to be exhibited towards those who are probing the edges of all this. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704061909.AA28626%40spam.istc.sri.com] <1987040608274400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: robert@SPAM.ISTC.SRI.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <8704061909.AA28626@spam.istc.sri.com> Date: Mon, 6-Apr-87 13:27:44 EST Article-I.D.: spam.8704061909.AA28626 Posted: Mon Apr 6 13:27:44 1987 Date-Received: Wed, 8-Apr-87 03:43:24 EST References: <12292273571.8.MRC@PANDA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 44 Approved: tcp-ip@sri-nic.arpa >> ..... we must >> entrust our systems and data to a open-ended set of youthful >> hackers (the current term is "gurus") who have mastered the >> arcane knowledge. Only because these 'youthful hackers' are the only ones willing (or having the time) to look for the problems they discover. >> >> .... >> >> Knowledge is power, and it properly belongs in the hands of >> system administrators and system programmers. It should NOT be >> the exclusive province of "gurus" who have a vested interest in >> keeping such details secret. Mark, I agree that system administators should have the know-how to protect their systems. However I have not seen the concerted effort of gurus to keep security problems secret from the administors. Rather I have seen administrators keeping such holes secret from the users, and then complaining when the users discover and use them. >> >> -- Mark -- >> >> PS: Crispin's definition of a "somewhat secure operating system": >> A "somewhat secure operating system" is one that, given an >> intelligent system management that does not commit a blunder that >> compromises security, would withstand an attack by one of its >> architects for at least an hour. ...except for the case where one has physical access to the hardware. Robert Allen, robert@spam.istc.sri.com Disclaimer: I am not a guru, and I don't advocate breakins, but if a feature is there (such as telnet port 25), and is used, I think that the administrators should share responsibility with the user for any problems that result. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1987.4.6.18.5.14.Rudy.Nedved%40h.cs.cmu.edu] <1987040608340100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Rudy.Nedved@H.CS.CMU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <1987.4.6.18.5.14.Rudy.Nedved@h.cs.cmu.edu> Date: Mon, 6-Apr-87 13:34:01 EST Article-I.D.: h.1987.4.6.18.5.14.Rudy.Nedved Posted: Mon Apr 6 13:34:01 1987 Date-Received: Wed, 8-Apr-87 04:39:09 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa Dan, My two areas of frustration are abuse of mail resources and abuse of network resources. Each year people, send mail to as many mailing lists as they can asking to be put on them instead of the request list. Several times a year, someone configures a mailer to cause a huge loop that causes many megabytes of mail messages to be sent to many people on many different systems. At least once year, I see a piece of code written under the assumption that the network is a quiet high-speed high-relaibility medium -- the code retransmits quickly and has very short timeouts. Lastly, we have several systems that take a list of hosts and broadcast messages to them to update databases. This is in the similiar flavor of grapevine. It is not unlikely that some company could set up a system and want a broadcast facility similiar to the one that started up this discussion. At this point, it is no longer a security problem but a feature. If I had concrete improvements that I could implement, I would act on them. Maybe the system will change to charge for mail and to charge for network access and usage. People would then be more responsive to their utilization of those resources. -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704061901.AA22513%40ic.Berkeley.EDU] <1987040609010900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: faustus@IC.BERKELEY.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <8704061901.AA22513@ic.Berkeley.EDU> Date: Mon, 6-Apr-87 14:01:09 EST Article-I.D.: ic.8704061901.AA22513 Posted: Mon Apr 6 14:01:09 1987 Date-Received: Wed, 8-Apr-87 03:23:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa What type of security are we really taking about, anyway? Military security? If so, maybe it's better that there are well-known loopholes so that nobody places too much faith in their system and makes use of techniques like public-key encryption when it really matters. No matter how secure your network and OS is, if you assume that it's ok to rely on their security alone for very sensitive data, you'll get burned sooner or later. It's much safer to assume the worst and take proper precautions. Wayne ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704061855.AA28399%40spam.istc.sri.com] <1987040609123400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: robert@SPAM.ISTC.SRI.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <8704061855.AA28399@spam.istc.sri.com> Date: Mon, 6-Apr-87 14:12:34 EST Article-I.D.: spam.8704061855.AA28399 Posted: Mon Apr 6 14:12:34 1987 Date-Received: Wed, 8-Apr-87 03:42:22 EST References: <1987.4.5.16.35.48.Rudy.Nedved@h.cs.cmu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 71 Approved: tcp-ip@sri-nic.arpa >> Whoa! >> >> Encouraging people to find holes and then use them to make the local system >> programmers work on them is wrong. It is like encouraging people to find out >> if their neighbors lock their door during the day so they will. Do you really >> want that or do you want the theives to be caught? I want the theives to be >> caught and the ability to leave my door open. I don't want to fear my >> neighborhood or my users. While this doesn't deal directly with TCP-IP, it is a *very* important consideration in the Internet in particular, and any network in general. Often a so-called 'breakin' does not even require that a user maliciously "try their neighbors doors" to see if they can gain restricted permissions or access. Often curiosity alone is enough to cause problems. Example 1: a first-time UNIX user was learning about the file system, and in particular how to delete files. He was told that he could only delete files owned by him, and by way of counterexample his mentor typed "rm /etc/passwd". Surprise, /etc was writeable and the file was gone. Example two: the recent rlogin breakins at Stanford. Example 3: Obviously if you have hardware access to the transmission medium you can unintentionally wreak havoc merely by using someone elses IP address. I too would like to live in a word where I can leave my "door unlocked". Unfortunately it doesn't take more than a very few nasty or ignorant persons to cause problems. Due to the fact that computers have evolved in an atmosphere of sharing (time sharing, memory sharing, src sharing..) we have yet to realize the responsibilities and risks of trusting them too much. I.e., there is a big difference between leaving your door unlocked but closed, and spreading $20.00 bills on your front lawn. In the case of J. Hubbards 'wall' to the Net, the problem was not caused by a malicious person, but by simple curiosity. At the recent TCP/IP Conference in Monterey CA, some discussion was given to "network security". From the military standpoint they want the ability to send data through a network, such that anyone who captures the data won't be able to read or use it. While this may be a prerequisite for the military, I don't think that 'normal' users should expect that their Email be any more secure than their USMail. The best method of keeping something secure on a network is to physically seperate it. Or, do what I do, and don't put anything on the system which you wouldn't read by someone else under the worst case scenario. Fixing security 'features' is obviously important, and should be pursued. Catching malicious persons doing damage is also extremely important. But "catching the theives" is not the answer to a lack of network security. If your network rolls out a red-carpet to someone then don't be surprised if you find muddy footprints on it the next morning. I leave you with two examples quoted from the January 1987 issue of the ACM Software Engineering Notes... "The computer security administrator at Roche ... had been plagued by a hacker who auto-dialed the entire Roche phone system in sequence. .... They laid a hacker trap on one of the PC's and traced the call. Once the suspect was found, it was even harder to get him arrested since he was in New York, and Roched in New Jersey (which got the FBI involved). The perp was brought into the police station and had the riot act read to him... He was not charged -- because there wasn't a **no-trespassing** sign on the hacker trap identifying the system as private proberty of Roche." " "Welcome to the ______ System" ... A Mass. financial firm that had attempted to prosecute a hacker who had penetrated their system. The defense lawyer argued that the system had a greeting that welcomed people to the system, and that was tantamount to welcoming someone intor your home. The judge threw out the case, accepting the arguments of the defense.." Robert Allen, robert@spam.istc.sri.com ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704061914.AA18505%40bu-cs.bu.edu] <1987040609140800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bzs@BU-CS.BU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: My Broadcast Message-ID: <8704061914.AA18505@bu-cs.bu.edu> Date: Mon, 6-Apr-87 14:14:08 EST Article-I.D.: bu-cs.8704061914.AA18505 Posted: Mon Apr 6 14:14:08 1987 Date-Received: Wed, 8-Apr-87 04:37:46 EST References: <12292273571.8.MRC@PANDA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 42 Approved: tcp-ip@sri-nic.arpa Mark Crispin -- I think your attack on UNIX is utterly unwarranted and devoid of content. How you can compare it to ITS where everyone was effectively a wheel is utterly beyond me. UNIX exhibits no worse characteristics than other commonly used systems. Even your beloved TOPS-20 had this charming feature of unencrypted passwords so anyone gaining access to a priviliged terminal for a few seconds could print every pwd on the system in clear text with one command. Sure, that's fixed, but the fix came recently, after DEC had dumped the product. We had to live with this for years (and show me the local hack patches that "fixed" this and I'll show you the local hack patches that fix any UNIX security flaw you see.) For the love of god Mark, Jordan broadcast a message to a lot of terminals. That's it. BFD, sure it could be annoying, but the originating site (and user, although I admit that could be faked easily) was clearly printed and easily (see etherfind for example) identified. To say your "systems and data" were endangered by this broadcast is hyperbole, at best. Can you condemn the entire UNIX operating system because a user was able to SHOUT to a bunch of hosts he didn't own? Sounds flimsy to me. As to "muzzling" of unix security problems, there's an entire, active mailing list on the internet devoted to nothing but discussing UNIX security issues. What other operating system can claim this? (Ok, these things are also freely discussed on some of the TOPS-20 lists, no argument, but name another? I've seen this stuff specifically stifled and people severely flamed on at least one other O/S's list.) -Barry Shein, Boston University P.S. One thing I do agree with Mark about is that without the sources you might be a sitting duck. This is one major reason I discourage people from buying VMS. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704061929.AA18758%40bu-cs.bu.edu] <1987040609290300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bzs@BU-CS.BU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: My Broadcast Message-ID: <8704061929.AA18758@bu-cs.bu.edu> Date: Mon, 6-Apr-87 14:29:03 EST Article-I.D.: bu-cs.8704061929.AA18758 Posted: Mon Apr 6 14:29:03 1987 Date-Received: Wed, 8-Apr-87 04:38:15 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa From Dennis Perry: >I would like suggestions as to what you, or anyone else, think should be >done to prevent such occurances in the furture. Solution: Edit /etc/servers and remove the rwalld line. This will disable the remote service. The local "write to all users" program, 'wall', can still be used on any individual system. To shout to all systems in an area either have the operators log in and run wall locally or execute it via 'rsh system wall ..msg..' from a locally trusted site (as per the rsh restrictions.) A command file could be created trivially which simulated "rwall" to a selected set of sites: #!/bin/sh echo "Enter message to be sent to all systems (one line)" echo -n 'MESSAGE: ' read msg for i in host1 host2 etc... do rsh $i wall $msg done (I didn't test this, but I think the point is clear.) This can be further enhanced by removing the rwall binary from your systems, but if you don't support the daemon, you're not going to see any broadcasts, so it's under your control. Done. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704061908.AA00627%40aai9] <1987040609431900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: chris@SPAM.ISTC.SRI.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: New source for Imagen laser printer memory boards. Message-ID: <8704061908.AA00627@aai9> Date: Mon, 6-Apr-87 14:43:19 EST Article-I.D.: aai9.8704061908.AA00627 Posted: Mon Apr 6 14:43:19 1987 Date-Received: Wed, 8-Apr-87 04:39:52 EST References: <8704040236.AA28199@brillig.umd.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 48 Approved: tcp-ip@sri-nic.arpa Original message. ----------------- >> I, recently had the oppertunity to evaluate a memory board for >>the Imagen IP/II processors. Since this is the first I had heard of an >>alternative source for Imagen memory I thought I'd share the info with >>the net. The company's name is Kortex Systems and in case you want to >>contact them their phone numbers are (415)-961-4411 or (415)-969-4053. >>They sell both a 4 meg and a 3 Meg board, I tried out the 4 Meg board >>in our 8/300 and our 3320 Imagen printers, both printers sit on our >>local ether net. In the past large jobs (100+ pages) would come out >>in reverse order and you would have to collilate the pages manually, >>with the 4 meg board in the system I couldn't find a listing large enough >>to use up all of the memory. We used the board in both systems for a >>week and saw no problems with it. The 4 Meg board retails for $1795 with >>discouts for non-profit and educational groups. The last time I checked >>the largest board Imagen sold was a 3 Meg one and it was going for $1900. >> >> Chris ----------------------------------------------------------------------------- Several folks have asked me for Kortex Systems address and pointed out that I had several typo's and misspelled words in my first message. Kortex System's address is: 1561 Elmhurst Dr. Los Altos, CA 94022. Below is a corrected version of my earlier message, please note that the 4 meg board is listed for $1900 not $1795. Sorry for the erroneous information in my earlier note. ----------------------------------------------------------------------------- I recently had the opportunity to evaluate a memory board for the Imagen IP/II processors. Since this is the first I had heard of an alternative source for Imagen memory I thought I'd share the info with the net. The company's name is Kortex Systems and in case you want to contact them their phone numbers are (415)-961-4411 or (415)-969-4053. They sell both a 4 meg and a 3 Meg board, I tried out the 4 Meg board in our 8/300 and our 3320 Imagen printers, both printers sit on our local ethernet. In the past, large jobs (100+ pages) would come out in reverse order and you would have to collate the pages manually. With the 4 meg board in the system I couldn't find a listing large enough to use up all of the memory. We used the board in both systems for a week and no problems were encountered. The 4 Meg board retails for $1900 with discounts for non-profit and educational groups. For more information please contact the folks at Kortex Systems, I have no association with the company. Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704061949.AA19185%40bu-cs.bu.edu] <1987040609490200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: budd@BU-CS.BU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: ICMP redirect caching Message-ID: <8704061949.AA19185@bu-cs.bu.edu> Date: Mon, 6-Apr-87 14:49:02 EST Article-I.D.: bu-cs.8704061949.AA19185 Posted: Mon Apr 6 14:49:02 1987 Date-Received: Wed, 8-Apr-87 04:39:38 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa I agree that BSD would be better off if the networking code took a more active (and reality based) interest in the health of its routing tables. Like some frail monarch hidden in its chambers it has too long listened to the half truths of its wormtongued routing daemon. TENEX/TOPS-20 use caching of ICMP Redirect derived routes. The "default" gateways are statically assigned. Perhaps an initial broadcast request could be used to dynamically build a weighted list of possible gateways when the current set is empty (or contains only reticent redirectors). Another valuable concept is the (sparing) use of pinging to ascertain the health of the default and active (catched) gateways. The file [NIC]NETINFO:INTERNET.PINGING contains information regarding the care and feeding of your GATEWAYS file. Phil Budne, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704062044.AA20908%40ucbvax.Berkeley.EDU] <1987040610172600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rfradenb@CCV.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Addition To Mailing List Message-ID: <8704062044.AA20908@ucbvax.Berkeley.EDU> Date: Mon, 6-Apr-87 15:17:26 EST Article-I.D.: ucbvax.8704062044.AA20908 Posted: Mon Apr 6 15:17:26 1987 Date-Received: Thu, 9-Apr-87 00:14:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Please add my name to the mailing list for this newsgroup. Thank you. Roger Fradenburgh (rfradenb@ccv.bbn.com) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(195)%2BTOPSLIB(124).6-Apr-87.16:04:35.VAX.DARPA.MIL] <1987040611043500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: Date: Mon, 6-Apr-87 16:04:35 EST Article-I.D.: Posted: Mon Apr 6 16:04:35 1987 Date-Received: Tue, 7-Apr-87 05:37:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Jordan, thanks for the note. I agree that we should discover and FIX holes found in the system. But at the same time, we don't want to have to shut the thing down until such a fix can be made. Misuse of the system get us all in a lot of trouble. The Arpanet has succeeded because of the self policing community. If this type of potential for disruption gets used by very many people, I guarentee that we all will not like the solution or fix proposed. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040611043501> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Mon 6 Apr 87 14:51:33-PDT Posted-Date: Mon 6 Apr 87 16:04:35-EST Received: by vax.darpa.mil (5.54/5.51) id AA03728; Mon, 6 Apr 87 17:04:39 EDT Date: Mon 6 Apr 87 16:04:35-EST From: Dennis G. Perry Subject: Re: My Broadcast To: jkh%violet.Berkeley.EDU@berkeley.edu Cc: PERRY@vax.darpa.mil, jkh@violet.berkeley.edu, hackers_guild@ucbvax.berkeley.edu, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "jkh%violet.Berkeley.EDU@berkeley.edu (Jordan K. Hubbard)" of Mon, 6 Apr 87 09:27:52 PDT Jordan, thanks for the note. I agree that we should discover and FIX holes found in the system. But at the same time, we don't want to have to shut the thing down until such a fix can be made. Misuse of the system get us all in a lot of trouble. The Arpanet has succeeded because of the self policing community. If this type of potential for disruption gets used by very many people, I guarentee that we all will not like the solution or fix proposed. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(195)%2BTOPSLIB(124).6-Apr-87.16:11:59.VAX.DARPA.MIL] <1987040611115900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: Date: Mon, 6-Apr-87 16:11:59 EST Article-I.D.: Posted: Mon Apr 6 16:11:59 1987 Date-Received: Tue, 7-Apr-87 05:36:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Barry, thanks for your suggestion. Seems to me like a good solution to start with, i.e. where we trust the users to implement the fix. Ultimately, we have to build a network that will protect itself somehow. Can I ask all you out there to implement such a scheme or any better one that may come out of this discussion. Thanks, dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040611115901> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Mon 6 Apr 87 14:14:04-PDT Posted-Date: Mon 6 Apr 87 16:11:59-EST Received: by vax.darpa.mil (5.54/5.51) id AA03754; Mon, 6 Apr 87 17:12:04 EDT Date: Mon 6 Apr 87 16:11:59-EST From: Dennis G. Perry Subject: Re: My Broadcast To: bzs@bu-cs.bu.edu Cc: PERRY@vax.darpa.mil, jkh%violet.Berkeley.EDU@ucbvax.berkeley.edu, hackers_guild@ucbvax.berkeley.edu, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "bzs@bu-cs.bu.edu (Barry Shein)" of Mon, 6 Apr 87 15:29:03 EDT Barry, thanks for your suggestion. Seems to me like a good solution to start with, i.e. where we trust the users to implement the fix. Ultimately, we have to build a network that will protect itself somehow. Can I ask all you out there to implement such a scheme or any better one that may come out of this discussion. Thanks, dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040612172600> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Mon 6 Apr 87 13:25:41-PDT Date: Mon, 6 Apr 87 16:17:26 AST From: Roger Fradenburgh To: tcp-ip@sri-nic.ARPA cc: rfradenb@ccv.bbn.com Subject: Addition To Mailing List Please add my name to the mailing list for this newsgroup. Thank you. Roger Fradenburgh (rfradenb@ccv.bbn.com) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040615434700> Received: from glacier.stanford.edu ([36.22.0.115]) by SRI-NIC.ARPA with TCP; Mon 6 Apr 87 22:43:45-PDT Received: by glacier.stanford.edu; Mon, 6 Apr 87 22:43:47 MST Date: Mon, 6 Apr 87 22:43:47 MST From: John B. Nagle Subject: NFS security To: TCP-IP@SRI-NIC.ARPA Quit worrying about "rwall". All one can do with that is annoy people. Worry about Sun NFS and Berkeley RLOGIN, both of which assume that hosts are "good guys". Consider the following: If you have the means to impersonate any host by setting an interesting number in your source IP address, and can see the replies coming back, you can access any remotely accessable file on any NFS server. If you are on the same LAN, this is trivial; otherwise it may take some eavesdropping or gateway tampering to bring it off. Note, by the way, that large networks constructed with low-level bridges are especially vulnerable to this type of attack. (This is not to be construed as an argument that IP routers provide some kind of security). With the advent of PC-based NFS clients, NFS break-in can be accomplished with low-cost hardware and requires minimal technical sophistication. NFS is useful. NFS is clever. NFS is efficient. NFS works. NFS has security holes though which one could drive an armored division. Don't blame Bill Joy; he's the one who insisted that SUN machines have sockets for DES chips. However, DoD's export controls on cryptographic equipment discourage the use of crypto hardware in commercial equipment. So the socket is invariably empty. DoD has shot itself in the foot on this one. John Nagle ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(195)%2BTOPSLIB(124).6-Apr-87.22:09:03.VAX.DARPA.MIL] <1987040617090300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: Date: Mon, 6-Apr-87 22:09:03 EST Article-I.D.: Posted: Mon Apr 6 22:09:03 1987 Date-Received: Wed, 8-Apr-87 06:27:38 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Dan, you are right in one point, anyway. That is we need to explore the issues of intergroup interaction. But, like any society where our collective well being depends upon the behavior of others outside our control, we need to be sensitive on how we explore the edges of these interactions. I posit that this should take place in a controlled experiment that maximizes the benefits and minimizes the disruptions. After all, the Arpanet is still an 'experimental' network. Let's plan our experiments, rather than just letting them happen. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040617090301> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Mon 6 Apr 87 20:10:21-PDT Posted-Date: Mon 6 Apr 87 22:09:03-EST Received: by vax.darpa.mil (5.54/5.51) id AA04485; Mon, 6 Apr 87 23:09:08 EDT Date: Mon 6 Apr 87 22:09:03-EST From: Dennis G. Perry Subject: Re: My Broadcast To: LYNCH@a.isi.edu Cc: Rudy.Nedved@h.cs.cmu.edu, hackers_guild@ucbvax.berkeley.edu, tcp-ip@sri-nic.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "Dan Lynch " of 6 Apr 1987 12:35:16 EST Dan, you are right in one point, anyway. That is we need to explore the issues of intergroup interaction. But, like any society where our collective well being depends upon the behavior of others outside our control, we need to be sensitive on how we explore the edges of these interactions. I posit that this should take place in a controlled experiment that maximizes the benefits and minimizes the disruptions. After all, the Arpanet is still an 'experimental' network. Let's plan our experiments, rather than just letting them happen. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704070556.AA00416%40ucbvax.Berkeley.EDU] <1987040619434700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jbn@GLACIER.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: NFS security Message-ID: <8704070556.AA00416@ucbvax.Berkeley.EDU> Date: Tue, 7-Apr-87 00:43:47 EST Article-I.D.: ucbvax.8704070556.AA00416 Posted: Tue Apr 7 00:43:47 1987 Date-Received: Wed, 8-Apr-87 06:28:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa Quit worrying about "rwall". All one can do with that is annoy people. Worry about Sun NFS and Berkeley RLOGIN, both of which assume that hosts are "good guys". Consider the following: If you have the means to impersonate any host by setting an interesting number in your source IP address, and can see the replies coming back, you can access any remotely accessable file on any NFS server. If you are on the same LAN, this is trivial; otherwise it may take some eavesdropping or gateway tampering to bring it off. Note, by the way, that large networks constructed with low-level bridges are especially vulnerable to this type of attack. (This is not to be construed as an argument that IP routers provide some kind of security). With the advent of PC-based NFS clients, NFS break-in can be accomplished with low-cost hardware and requires minimal technical sophistication. NFS is useful. NFS is clever. NFS is efficient. NFS works. NFS has security holes though which one could drive an armored division. Don't blame Bill Joy; he's the one who insisted that SUN machines have sockets for DES chips. However, DoD's export controls on cryptographic equipment discourage the use of crypto hardware in commercial equipment. So the socket is invariably empty. DoD has shot itself in the foot on this one. John Nagle ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704070055.a004873%40Huey.UDEL.EDU] <1987040619553400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Time RFC 868 Message-ID: <8704070055.a004873@Huey.UDEL.EDU> Date: Tue, 7-Apr-87 00:55:34 EST Article-I.D.: Huey.8704070055.a004873 Posted: Tue Apr 7 00:55:34 1987 Date-Received: Wed, 8-Apr-87 06:28:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Howard, I would like to recommend RFC-958 and the references cited there as input to this work. A reasonable volume of swampslush has washed under the keel of the DARPA Internauts in the area of time synchronization. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704070324.aa14809%40SEM.BRL.ARPA] <1987040621242700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mike@BRL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ICMP As A Diagnostic Tool? Message-ID: <8704070324.aa14809@SEM.BRL.ARPA> Date: Tue, 7-Apr-87 02:24:27 EST Article-I.D.: SEM.8704070324.aa14809 Posted: Tue Apr 7 02:24:27 1987 Date-Received: Wed, 8-Apr-87 06:27:24 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 34 Approved: tcp-ip@sri-nic.arpa BRL uses the "ping" program, which transmits ICMP Echo Request packets with the data field set to a process ID, a sequence number, and a struct timeval (time in seconds and microseconds), plus patterns to pad out any extra length (a command-line parameter). [The BRL ping program is now provided as /etc/ping in 4.3 BSD UNIX]. We use this tool for network troubleshooting *extensively*. Many Lab managers even know how to run PING, so that they can get more information about why connections to far-away hosts may be working poorly. We also have a tool (PINGPOLL) that we use (within the campus net only) to monitor round-trip-times and packet loss, as well as a very simple ICMP-based routing daemon (ROUTER). ICMP is invaluable -- it provides a level of visibility of activity at the link level that is very helpful. Oh yes, another good use to to watch the effects of varying packet size. Good for finding IP reassembly bugs (in days gone by), and various interesting performance problems (back-to-back etherpackets, etc). The "ping -f" (aka FLOODPING) option is very good for stress-testing a particular network, gateway, host, whatever. As the name suggests, it releases ICMP echo request packets as fast as it can. Another version of PING that we have uses the IP option "record route", which is useful to see where the packets are traveling. Very useful, and amusing to watch. Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704071024.AA04057%40ucbvax.Berkeley.EDU] <1987040700254400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@TAUNIVM.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Introduction to Tcp/Ip Message-ID: <8704071024.AA04057@ucbvax.Berkeley.EDU> Date: Tue, 7-Apr-87 05:25:44 EST Article-I.D.: ucbvax.8704071024.AA04057 Posted: Tue Apr 7 05:25:44 1987 Date-Received: Fri, 10-Apr-87 00:30:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Henry Nussbacher Distribution: world Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Can anyone refer me to an RFC or some other online document that gives a good overview of Tcp/Ip - how it is built, what protocols it uses, etc. Basically a good comprehensive 30-page overview of the whole Tcp/Ip system. Please answer directly to me and if you have something that you wrote up that is not available publically, feel free to send it to me. Thanks in advance, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704071037.AA04224%40ucbvax.Berkeley.EDU] <1987040700384100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@TAUNIVM.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Access control and accountability Message-ID: <8704071037.AA04224@ucbvax.Berkeley.EDU> Date: Tue, 7-Apr-87 05:38:41 EST Article-I.D.: ucbvax.8704071037.AA04224 Posted: Tue Apr 7 05:38:41 1987 Date-Received: Fri, 10-Apr-87 00:39:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Henry Nussbacher Distribution: world Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa I have a feeling this posting might generate quite a bit of philosphical talk - but I would like to request in advance that I am not interested in feelings and/or emotions but rather technical solutions. With that behind me I would like to know about solutions in Tcp/Ip for the following two areas: 1) Access control: A) On a system level: How do I go about restricting the use of users from using Tcp/Ip? I realize that every operating system may have a different solution but I am interested in hearing concepts and whether anyone is actually doing it. B) On a gateway level: If I have a gateway (say something like Bridge or cisco) do I have any capability of performing any sort of access control? If yes, is this access control based on connected machines or can I even exercise access control on a user level (i.e. restrict FTP or TELNET to a certain group of users on a certain machine). 2) Accounting: A) System level: Is there any accounting package that can measure things like packet transfer (FTP always tells you how many Kb/sec you sent so it isn't impossible to figure out) levels and Telnet connect time? B) Gateway level: Is there some gateway or monitoring PC that can do accounting? Is the accounting per system or can it be broken down per user (I assume very difficult to do)? As a side note, anyone who is up on ISO: what is the status of accounting and access control in ISO? Has it even been thought of? Thanks in advance, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [26844.544796555%40dewey] <1987040702422700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: galvin@dewey.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <26844.544796555@dewey> Date: Tue, 7-Apr-87 07:42:27 EST Article-I.D.: dewey.26844.544796555 Posted: Tue Apr 7 07:42:27 1987 Date-Received: Fri, 10-Apr-87 03:03:40 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: tcp-ip@sri-nic.arpa Distribution: world Organization: The ARPA Internet Lines: 43 Approved: tcp-ip@sri-nic.arpa From: Robert Allen I don't think that 'normal' users should expect that their Email be any more secure than their USMail. I don't buy this. Why should we restrict or constrain current technology based on what we are used to? There is no reason that electronic mail can't be more secure than USMail. Isn't it self-defeating to assume otherwise? From: Rudy.Nedved@h.cs.cmu.edu Encouraging people to find holes and then use them to make the local system programmers work on them is wrong. It is like encouraging people to find out if their neighbors lock their door during the day so they will. Do you really want that or do you want the theives to be caught? I want the theives to be caught and the ability to leave my door open. I don't want to fear my neighborhood or my users. This analogy doesn't hold in the internet (small i intended). It is not your neighbors you are worried about. You can live in a "friendly" network just like you can live in a "friendly" neighborhood. The problem is, your friendly network is a great deal "closer" to the unfriendly ones than your friendly neighborhood is close to unfriendly ones. Isn't this what Dan Lynch meant when he said: From: Dan Lynch What we are learning with some of the facilities for message sending is that our "internet" is very highly connected and even can be considered to be too highly connected for some forms of (even innocent) misbehavior. How do we benefit from what we have learned thus far? ... But the big thing that we need to understand is that we do not understand how to live in these highly connected internets yet. Much more research needs to happen in the area of intergroup interactions. And much more tolerance needs to be exhibited towards those who are probing the edges of all this. Jim ----MESSAGE-END---- ----MESSAGE-BEGIN---- [%5BA.ISI.EDU%5D.7-Apr-87.08:58:49.CERF] <1987040702580000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Access control and accountability Message-ID: <[A.ISI.EDU].7-Apr-87.08:58:49.CERF> Date: Tue, 7-Apr-87 07:58:00 EST Article-I.D.: <[A.ISI.EDU].7-Apr-87.08:58:49.CERF> Posted: Tue Apr 7 07:58:00 1987 Date-Received: Fri, 10-Apr-87 04:01:33 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Hank, Little has been developed for access control and accounting. Some gateways (e.g. BBN?) can filter IP packets based on source/destination address. I don't know of any which filter with knowledge of the protocol being used. I do not know of any gateways that provide accounting data, although such information as packet counts from a given host can be obtained from, e.g. the ARPANET. I would not be surprised to hear that some gateways and even some bridges keep some statistics about traffic loads, but probably not by source or destination. Thus far, the TCP/IP software has gone into private or gov't-owned systems which have not demanded much inthe way of accounting (or of access control). Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [544804564.hoey%40nrl-aic] <1987040704360300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hoey@NRL-AIC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Mailbridge homings Message-ID: <544804564.hoey@nrl-aic> Date: Tue, 7-Apr-87 09:36:03 EST Article-I.D.: nrl-aic.544804564.hoey Posted: Tue Apr 7 09:36:03 1987 Date-Received: Fri, 10-Apr-87 03:47:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa Date: Mon, 6 Apr 87 15:49:02 EDT From: budd@bu-cs.bu.edu (Philip Budne) To: tcp-ip@nic.sri.com Subject: ICMP redirect caching ... The file [NIC]NETINFO:INTERNET.PINGING contains information regarding the care and feeding of your GATEWAYS file. Phil Budne, Boston University At the end of that file is a copy of DDN MGT Bulletin 23, dated 29 Aug 1984. If you are (as I was last month) using it to find out your mailbridge homing, you should read either [NIC]NETINFO:ARPA-MAILBRIDGE-HOMINGS.TXT, or [NIC]NETINFO:MIL-MAILBRIDGE-HOMINGS.TXT depending on which side of the mailbridges you use. KLH, or NETINFO maintainer: Please note these filenames at the end of INTERNET.PINGING, and maybe even remove the outdated mailbridge list. Dan Hoey ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040704360301> Received: from nrl-aic.ARPA by SRI-NIC.ARPA with TCP; Tue 7 Apr 87 08:09:53-PDT Return-Path: Received: Tue, 7 Apr 87 10:09:15 est by nrl-aic.ARPA id AA03717 Date: 7 Apr 1987 09:36:03 EST (Tue) From: Dan Hoey Subject: Mailbridge homings To: budd@bu-cs.bu.edu (Philip Budne), tcp-ip@sri-nic.arpa Cc: SUGGESTIONS@SRI-NIC.ARPA, KLH@SRI-NIC.ARPA Message-Id: <544804564/hoey@nrl-aic> Date: Mon, 6 Apr 87 15:49:02 EDT From: budd@bu-cs.bu.edu (Philip Budne) To: tcp-ip@nic.sri.com Subject: ICMP redirect caching ... The file [NIC]NETINFO:INTERNET.PINGING contains information regarding the care and feeding of your GATEWAYS file. Phil Budne, Boston University At the end of that file is a copy of DDN MGT Bulletin 23, dated 29 Aug 1984. If you are (as I was last month) using it to find out your mailbridge homing, you should read either [NIC]NETINFO:ARPA-MAILBRIDGE-HOMINGS.TXT, or [NIC]NETINFO:MIL-MAILBRIDGE-HOMINGS.TXT depending on which side of the mailbridges you use. KLH, or NETINFO maintainer: Please note these filenames at the end of INTERNET.PINGING, and maybe even remove the outdated mailbridge list. Dan Hoey ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040704580000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 7 Apr 87 05:02:05-PDT Date: 7 Apr 1987 08:58-EDT Sender: CERF@A.ISI.EDU Subject: Re: Access control and accountability From: CERF@A.ISI.EDU To: Hank%BARILVM.BITNET@WISCVM.WISC.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU] 7-Apr-87 08:58:49.CERF> In-Reply-To: The message of Tue, 7 Apr 87 12:07 IST from Hank Nussbacher Hank, Little has been developed for access control and accounting. Some gateways (e.g. BBN?) can filter IP packets based on source/destination address. I don't know of any which filter with knowledge of the protocol being used. I do not know of any gateways that provide accounting data, although such information as packet counts from a given host can be obtained from, e.g. the ARPANET. I would not be surprised to hear that some gateways and even some bridges keep some statistics about traffic loads, but probably not by source or destination. Thus far, the TCP/IP software has gone into private or gov't-owned systems which have not demanded much inthe way of accounting (or of access control). Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704071640.AA01148%40hoquiam] <1987040706405200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: don@SRI-LEWIS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <8704071640.AA01148@hoquiam> Date: Tue, 7-Apr-87 11:40:52 EST Article-I.D.: hoquiam.8704071640.AA01148 Posted: Tue Apr 7 11:40:52 1987 Date-Received: Fri, 10-Apr-87 04:29:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa Just an interested bystander here, Perhaps the fundemental difference in UNIX versus most other operating system is that the basic user has to get so much more intimate with the command set. In addition a goodly number of these users are writing software that requires them to, at some point in time, have a hook or two into the workings of the operating system. Also one must remember that the abilities/capabilities of one to cross mount entire file systems is a FEATURE, not a quirk. Believe me, when the feds come crashing through your bedroom window and sieze your equipment you will know you shouldn't have been doing what you were doing. TIA, (That Is All) Don ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704080341.AA20900%40ucbvax.Berkeley.EDU] <1987040707594200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Access control and accountability Message-ID: <8704080341.AA20900@ucbvax.Berkeley.EDU> Date: Tue, 7-Apr-87 12:59:42 EST Article-I.D.: ucbvax.8704080341.AA20900 Posted: Tue Apr 7 12:59:42 1987 Date-Received: Sat, 11-Apr-87 03:35:31 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa Hank, On the "system" side is is entirely up to the operating system that runs the hardware interface to the network. I have worked on a system that did enforce access controls on a per user basis to the network interfaces that were attached to it. Since the operating system allready had a strong notion of access control it was not dificult to add in the support for network access. But, it certainly is true that we needed the source code to everything in sight to make it all happen. The early days of networking had a notion of what it was that was being hooked up to the netowrk: a timesharing system with a responsible adminstration ensuring some kind of access restrictions or at least a place to call to register a complaint. Today's technological advances have made is so that everyone on earth is a "timesharing system administrator". Clearly the "responsibility" for hooking up to the network has to be placed elsewhere. The owner of the "cable" is teh obvious choice, but that does not take into account radio based networks... IN short: It looks like the "gateway owners" are going to have to become the administrators of the future! Yikes, back to the future??? Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704071837.AA07556%40jupiter.mitre.org] <1987040708371100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@GATEWAY.MITRE.ORG.UUCP Newsgroups: mod.protocols.tcp-ip Subject: How big is big? Message-ID: <8704071837.AA07556@jupiter.mitre.org> Date: Tue, 7-Apr-87 13:37:11 EST Article-I.D.: jupiter.8704071837.AA07556 Posted: Tue Apr 7 13:37:11 1987 Date-Received: Fri, 10-Apr-87 03:42:31 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 43 Approved: tcp-ip@sri-nic.arpa I am doing some routing research which requires that I predict the performance of a new sort of routing hierarchy for networks of virtually unlimited numbers of nodes. I need to also state the diameters of these large networks. I am therefore curious as to what people think the diameter of very large networks will be. For those who care to consider it, then, please make a guess at the following: What should be the diameter of networks with 10,000 nodes? 100,000 nodes? 1,000,000 nodes? Rules: 1. A node is a switching point, such as an IMP or a gateway. Hosts don't count (DEC people call hosts nodes). 2. Consider any single piece of transmission as a hop. This includes Ethernets, single wires, and a single satellite hop, but does not include transit through a DDN or even bridged Ethernets. 3. This does not include ALL connectivity, only connectivity that can be used for transit routing. For instance, we at MITRE have both a MILNET and an ARPANET connection two machines on the same Ethernet. However, since we do transit traffic between the two, we cannot be considered a hop. (Actually, this third point is a little tricky, since physical connectivity can be blocked in many ways at many levels, and in different ways for different users. People may answer the question assuming both physical and logical connectivity if they wish. I just happen to be more interested in logical connectivity.) 4. ANSWER TO ME DIRECTLY. Do not answer over the interest list. I don't want people's guesses to be biased by other guesses they have seen. I will post a summary of this (assuming I get any interest) in a few days. 5. Prizes for most accurate guesses will be awarded. First prize is full veto power over all ISO and CCITT standards. Second prize is AT&T long lines and 1000 fuzzballs. Third prize is AT&T long lines and 2000 fuzzballs. Prizes will be awarded when the actual diameters of said networks are discovered. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704071956.AA12317%40ucbvax.Berkeley.EDU] <1987040709391000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NJG@CORNELLA.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <8704071956.AA12317@ucbvax.Berkeley.EDU> Date: Tue, 7-Apr-87 14:39:10 EST Article-I.D.: ucbvax.8704071956.AA12317 Posted: Tue Apr 7 14:39:10 1987 Date-Received: Fri, 10-Apr-87 06:02:22 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa >As to "muzzling" of unix security problems, there's an entire, active >mailing list on the internet devoted to nothing but discussing UNIX >security issues. What other operating system can claim this? (Ok, >these things are also freely discussed on some of the TOPS-20 lists, >no argument, but name another? I've seen this stuff specifically >stifled and people severely flamed on at least one other O/S's list.) I couldn't resist: The VM Group of the IBM user's group SHARE has a conferencing system (VMSHARE) which has an on going discussion of security problems. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040709594200> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 7 Apr 87 20:26:54-PDT Date: 7 Apr 1987 13:59:42 EDT Subject: Re: Access control and accountability From: Dan Lynch To: Henry Nussbacher cc: , LYNCH@A.ISI.EDU In-Reply-To: (Message from "Hank Nussbacher " of Tue, 7 Apr 87 12:07 IST) Hank, On the "system" side is is entirely up to the operating system that runs the hardware interface to the network. I have worked on a system that did enforce access controls on a per user basis to the network interfaces that were attached to it. Since the operating system allready had a strong notion of access control it was not dificult to add in the support for network access. But, it certainly is true that we needed the source code to everything in sight to make it all happen. The early days of networking had a notion of what it was that was being hooked up to the netowrk: a timesharing system with a responsible adminstration ensuring some kind of access restrictions or at least a place to call to register a complaint. Today's technological advances have made is so that everyone on earth is a "timesharing system administrator". Clearly the "responsibility" for hooking up to the network has to be placed elsewhere. The owner of the "cable" is teh obvious choice, but that does not take into account radio based networks... IN short: It looks like the "gateway owners" are going to have to become the administrators of the future! Yikes, back to the future??? Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704072142.AA14302%40ucbvax.Berkeley.EDU] <1987040710131100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ahill@CC7.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <8704072142.AA14302@ucbvax.Berkeley.EDU> Date: Tue, 7-Apr-87 15:13:11 EST Article-I.D.: ucbvax.8704072142.AA14302 Posted: Tue Apr 7 15:13:11 1987 Date-Received: Fri, 10-Apr-87 06:03:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa I would like to hear why Mark Crispin's second definition isn't a more pratical approach to the security issue. If Unix is still vulnerable after a decade of availability should we ever expect it to be safe? Why also should we pick on Unix (except its a good subject to evoke flames)? My years of experience in dealing with security indicates that data should be encrypted whenever practical. Relying on software or system adminstrators is folly. Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704072114.AA02584%40emptys.cc.umich.edu] <1987040710373100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mts@EMPTYS.CC.UMICH.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Security or what? Message-ID: <8704072114.AA02584@emptys.cc.umich.edu> Date: Tue, 7-Apr-87 15:37:31 EST Article-I.D.: emptys.8704072114.AA02584 Posted: Tue Apr 7 15:37:31 1987 Date-Received: Fri, 10-Apr-87 06:03:13 EST References: <12292273571.8.MRC@PANDA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 113 Approved: tcp-ip@sri-nic.arpa I'm suprised about messages I receive where the intent of the author is to raise my consciousness by making me angry. What usually happens is this -- I get angry. So is the case with the message from Mark Crispin. The philsophy behind Unix largely seems quite reminiscent of the ... "security through obscurity;" The only security is through obscurity. It is precisely the lack of information which secures some system. As an example, consider publishing the passwords of all the accounts on a system, or the private parts of DES pair. entrust our systems and data to a open-ended set of youthful hackers (the current term is "gurus") who have mastered the arcane knowledge. I'm confused here about the term youthful hackers. Is youthful under 18? under 25? under 35? under 45? I know of many excellent programmers in all age groups. I also know malicious usage has no age range. Mark, if you are a manager, have you had occassion to use the same talents you are complaing about to solve some particular problem without getting involved? Are you complaing about their knowledge or about your unwillingness to learn what you need to know? The problem is further exacerbated by the multitude of slimy vendors who sell Unix boxes without sources and without an efficient means of dealing with security problems as they develop. The focus seems to have changed. If the discussion was about Unix problems, if the focus was about selection criterea for the people hired, the focus is now on vendor problems? Even so, I wasn't aware that lack of source was the key to the security problems on Unix systems. I'm not aware of too many unix vendors who are unwilling to share their code when they are reimbursed for their efforts. I don't see any relief, however. There are a lot of politics involved here. Some individuals would rather muzzle knowledge of Unix security problems and their fixes than see them fixed. This may be true. This may always be true. I feel it is *criminal* to have this attitude on the DDN, since our national security in wartime might ultimately depend upon it. If there is such a breach, those individuals will be better off if the Russians win the war, because if not there will be a Court of Inquiry to answer... Ah, after alot of though, I think I am beginning to understand what you are trying to write. Are you assuming the sensitive machines on the DDN to be Unix machines? And from there assuming they are unsecured? I would think people using machines and needing particular levels of security would be well aware of the issues, much more than you or I. I have seen some of the specs to come out of the military for secure system, and have felt very good about the militaries' own understanding of its needs. It may be necessary to take matters into our own hands, as you did once before. I am seriously considering offering a cash reward for the first discoverer of a Unix security bug, provided that the bug is thoroughly documented (with both cause and fix). Now I am beginning to understand a bit more... so happends these kind of bugs have been found before. In fact, bugs have been discovered. In fact, information has been sent out, describing the problem, and the resolution. There would be a sliding cash scale based on how devastating the bug is and how many vendors' systems it affects. My intention would be to propagate the knowledge as widely as possible with the express intension of getting these bugs FIXED everywhere. If that is your intention, then the process you are suggesting for making it happen is faulty. You are trying to get people to help you by making them angry at you. This will not work. Knowledge is power, and it properly belongs in the hands of system administrators and system programmers. It should NOT be the exclusive province of "gurus" who have a vested interest in keeping such details secret. Here I am very confused. Seems the people who are refered to as "gurus" are the very best system programmers. All the "gurus" I have ever met have many talents beyond programming; including leadership. Getting the leadership required excellant interpersonnel skills. As mentioned above, if this is not the case where you work, then the people responsible for selecting appropriate individuals for their positions have made mistakes. As for "in the hands of"; a case of analogy may make clear that this is not necessarily the best way... I would guess the same was said to the people making the atomic bomb; that they had the understanding the create the bomb, but not the understanding to use it correctly. Defering the responsibilty to the people who wanted it for "power" created an environment where those people used the very technology only for "power". I would say for you to focus on the knowledge itself, because for you, the knowledge will not be power. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040711391000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Tue 7 Apr 87 12:50:16-PDT Received: from CORNELLA.BITNET by wiscvm.wisc.edu on 04/07/87 at 14:49:17 CDT Received: by CORNELLA (Mailer X1.23b) id 9160; Tue, 07 Apr 87 15:47:22 EDT Date: Tue, 07 Apr 87 15:39:10 EDT From: Nick Gimbrone Subject: Re: My Broadcast To: Barry Shein , tcp-ip@sri-nic.arpa >As to "muzzling" of unix security problems, there's an entire, active >mailing list on the internet devoted to nothing but discussing UNIX >security issues. What other operating system can claim this? (Ok, >these things are also freely discussed on some of the TOPS-20 lists, >no argument, but name another? I've seen this stuff specifically >stifled and people severely flamed on at least one other O/S's list.) I couldn't resist: The VM Group of the IBM user's group SHARE has a conferencing system (VMSHARE) which has an on going discussion of security problems. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040712131100> Received: from cc7.bbn.com by SRI-NIC.ARPA with TCP; Tue 7 Apr 87 14:34:36-PDT Date: Tue, 7 Apr 87 16:13:11 EDT From: "Alan R. Hill" Subject: Re: My Broadcast In-Reply-To: Your message of Tue, 07 Apr 87 15:39:10 EDT To: Nick Gimbrone Cc: tcp-ip@sri-nic.arpa I would like to hear why Mark Crispin's second definition isn't a more pratical approach to the security issue. If Unix is still vulnerable after a decade of availability should we ever expect it to be safe? Why also should we pick on Unix (except its a good subject to evoke flames)? My years of experience in dealing with security indicates that data should be encrypted whenever practical. Relying on software or system adminstrators is folly. Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12292708823.9.MRC%40PANDA] <1987040713062000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC%PANDA@SUMEX-AIM.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <12292708823.9.MRC@PANDA> Date: Tue, 7-Apr-87 18:06:20 EST Article-I.D.: PANDA.12292708823.9.MRC Posted: Tue Apr 7 18:06:20 1987 Date-Received: Sat, 11-Apr-87 00:13:43 EST References: <8704061901.AA22513@ic.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa Wayne - In a sense your message is very reminiscent of the attitude of the architects of MIT ITS. It is a useful attitude in certain environments; it has been argued that the security/integrity consciousness of TOPS-20 and Multics hampered tools development (or limited it to system wizards) compared to systems such as ITS, WAITS, and Unix. But this does not mean that it is right for all environments. Even in an environment in which rwalld is useful, it's important to have safeguards in place to limit its range. In the present state of affairs, such safeguards are either absent, not enabled, or inadequately documented. Just as an example, why did Dennis Perry's system at DARPA accept a rwall from a machine somewhere at Berkeley? Maybe Berkeley is doing such time-critical research that breakthroughs must be announced by such "network shouts", but I think it's much more likely that nobody at DARPA even knew that such a facility existed or was running on their machine. Think of what would happen if our IP gateways supported an IP address of FF.FF.FF.FF (the famous and as-yet mythical "Godzilla-gram"). Fortunately, no gateway does. The same sort of sanity check needs to be extended to higher-level protocols. -- Mark -- PS: I could envision a security bug caused by the ability to broadcast arbitrary characters to terminals on other systems. Are all the rwalld implementations clever enough to filter out control characters? Also, those of us who are old enough to know what "cookie bear" know that broadcasting messages CAN effectively stop all work... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704080059.AA20330%40jupiter.bellcore.com] <1987040714594800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@JUPITER.BELLCORE.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: A New TCP Retransmission Algorithm Message-ID: <8704080059.AA20330@jupiter.bellcore.com> Date: Tue, 7-Apr-87 19:59:48 EST Article-I.D.: jupiter.8704080059.AA20330 Posted: Tue Apr 7 19:59:48 1987 Date-Received: Sat, 11-Apr-87 03:27:11 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 112 Approved: tcp-ip@sri-nic.arpa I'd like to describe a TCP retransmission algorithm that I've been using with excellent results for the last several months. Background TCP has the following well known problem. When an ACK finally returns for a segment that was retransmitted, you don't know which transmission caused it. Therefore you can't be certain what the round trip time (RTT) for this packet was. Different implementations react differently to this problem: 1. Some assume that the first transmission(s) was/were lost and restart the round trip timer on each retransmission. 2. Others ignore the measurement (since it isn't reliable), keeping their previous estimates of the round trip time. Both approaches share a serious problem. Consider the case where the retransmission occurred because the smoothed round trip time (SRTT) was too small, not because packets are being lost. If approach #1 is used, the returning ACK is in fact responding to the FIRST transmission, so timing from a later transmission gives a measurement that is too small. Because the measurements are erroneously small, SRTT never adapts to the true value; because the SRTT never adapts to its true value, unnecessary retransmissions keep happening, resulting in erroneously small RTT measurements. This vicious circle can go on essentially forever. If the measurement is instead rejected as unreliable, SRTT is never updated, and again unnecessary retransmissions go on forever. Believe me, I've seen more than my share of TCPs behave this way. The current accepted way out of this problem is to assume the worst whenever a timeout occurs by measuring the RTT from the FIRST transmission of a given segment. If network loading suddenly increases, or if the initial estimate of the round trip time was too low, there will be a few retransmissions but the correct value *will* be found; the TCP eventually learns and unnecessary retransmissions stop. As long as the network packet loss rate is low, this approach works quite well. Retransmissions caused by the occasional dropped packet result in erroneously large round trip time measurements being fed into the smoother, but this is better than erring on the low side. Since few packets are being dropped, subsequent packets will most likely bring the SRTT value back down to its "real" value long before the next packet is dropped, so the timeout won't waste too much time. A serious problem develops, however, when the network is very lossy. A "raw" amateur packet radio channel (no link level acknowledgments) often loses 25% or more of the packets sent due to collisions and poor signal levels. Such rates drive this algorithm crazy, especially when consecutive packets are lost. In this situation, retransmission intervals are increasing rapidly due to back-off, and these intervals are added to the total round trip measurement for the segment. Enough such measurements can can drive the smoothed round trip time estimate right through the roof. This is especially true when a nonlinear smoothing function is used that reacts more quickly to increases in round trip delay than to decreases (e.g., Mills, RFC-889). Some people might say that the answer is simple: just constrain the round trip time to some arbitrary limit, say, 30 or 60 seconds, but there are real problems with this. Just how do you pick this "arbitrary" value? Through measurement? Just like the Dow Jones average, any number you see today is almost guaranteed to be exceeded tomorrow. If the delay through the Internet exceeds your arbitrary timeout limit, you start retransmitting unnecessarily, further adding to whatever it is that is causing the large delay in the first place. Perhaps we need robots to stand in the office of every protocol hacker: WARNING WARNING DANGER WILL ROBINSON! ARBITRARY PROTOCOL TIMEOUT DETECTED! EVENTUAL CONGESTION COLLAPSE IS NOW GUARANTEED! (SOONER OR LATER) A Better Way Thinking there *had* to be a better way, I devised and implemented the following rules: 1. If a segment being ACKed was sent only once, update the estimated round trip time and recompute the timeout interval. (This is standard behavior). 2. If a timeout occurs, back off the timeout timer interval (e.g., double it), retransmit the oldest unacknowledged segment, and restart the timeout timer. (Again, nothing unusual). 3. When an ACK comes in for a segment that was sent more than once (i.e., retransmitted at least once) do NOT attempt to measure its round trip time; leave the smoothed estimate alone. FURTHERMORE, KEEP THE BACKED-OFF TIMER SETTING FOR THE *NEXT* SEGMENT, AND DO NOT RECOMPUTE IT FROM (BETA*SRTT) UNTIL IT OR A LATER SEGMENT HAS BEEN ACKED WITHOUT A RETRANSMISSION. The purpose of this last rule is as follows. If the retransmission was caused by a too-small SRTT, keeping the backed-off timeout for the following segment gives an ACK a chance to come back without the RTT measurement being spoiled by an unnecessary retransmission. This gives a valid data point that can be fed into the smoothed estimate, driving it toward its true value. On the other hand, if the timeout was caused by the packet being lost altogether, the estimated round trip time will not (and should not) change. Only valid RTT measurements are fed into the smoother, and the timeout is always backed off whenever retransmissions occur until valid RTT measurements are again obtained. This algorithm seems to work extremely well in practice. Even when the packet loss rate is so high as to cause many packets to be lost in a row, SRTT always reflects a "sane" value. If the network delay suddenly increases, there may be a short period where the retransmission timeout "oscillates" between a value based on the SRTT and the backed-off interval necessary to allow an ACK to come back without a retransmission, but this stops when the computed SRTT catches up with the current network delay. Dave Mills' nonlinear algorithm shortens this period by allowing the smoothed estimate to react more quickly to sudden increases, but even without it the algorithm always converges. Comments? Phil Karn ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040715340000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Tue 7 Apr 87 03:07:09-PDT Received: from TAUNIVM.BITNET by wiscvm.wisc.edu on 04/07/87 at 05:07:08 CDT Received: by TAUNIVM (Mailer X1.23b) id 6309; Tue, 07 Apr 87 12:07:10 IST Date: Tue, 7 Apr 87 12:04 IST From: Hank Nussbacher Subject: Introduction to Tcp/Ip To: Reply-To: Henry Nussbacher Can anyone refer me to an RFC or some other online document that gives a good overview of Tcp/Ip - how it is built, what protocols it uses, etc. Basically a good comprehensive 30-page overview of the whole Tcp/Ip system. Please answer directly to me and if you have something that you wrote up that is not available publically, feel free to send it to me. Thanks in advance, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040715370000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Tue 7 Apr 87 03:22:06-PDT Received: from TAUNIVM.BITNET by wiscvm.wisc.edu on 04/07/87 at 05:21:43 CDT Received: by TAUNIVM (Mailer X1.23b) id 6356; Tue, 07 Apr 87 12:21:15 IST Date: Tue, 7 Apr 87 12:07 IST From: Hank Nussbacher Subject: Access control and accountability To: Reply-To: Henry Nussbacher I have a feeling this posting might generate quite a bit of philosphical talk - but I would like to request in advance that I am not interested in feelings and/or emotions but rather technical solutions. With that behind me I would like to know about solutions in Tcp/Ip for the following two areas: 1) Access control: A) On a system level: How do I go about restricting the use of users from using Tcp/Ip? I realize that every operating system may have a different solution but I am interested in hearing concepts and whether anyone is actually doing it. B) On a gateway level: If I have a gateway (say something like Bridge or cisco) do I have any capability of performing any sort of access control? If yes, is this access control based on connected machines or can I even exercise access control on a user level (i.e. restrict FTP or TELNET to a certain group of users on a certain machine). 2) Accounting: A) System level: Is there any accounting package that can measure things like packet transfer (FTP always tells you how many Kb/sec you sent so it isn't impossible to figure out) levels and Telnet connect time? B) Gateway level: Is there some gateway or monitoring PC that can do accounting? Is the accounting per system or can it be broken down per user (I assume very difficult to do)? As a side note, anyone who is up on ISO: what is the status of accounting and access control in ISO? Has it even been thought of? Thanks in advance, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704080252.AA15578%40PARIS.MIT.EDU] <1987040716524800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: martillo@ATHENA.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Ken Olsen vs MAP Message-ID: <8704080252.AA15578@PARIS.MIT.EDU> Date: Tue, 7-Apr-87 21:52:48 EST Article-I.D.: PARIS.8704080252.AA15578 Posted: Tue Apr 7 21:52:48 1987 Date-Received: Sat, 11-Apr-87 03:33:05 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa Last week Ken Olsen was dumping on MAP/TOP. Charles Gardner, corporate coordinator of communications standards for Eastman Kodak Co. and chairman of the MAP/TOP Steering Committee stated in reply: "The broadband token bus is needed in the factory, and Olsen doesn't seem to understand that," he said. "For some control applications, you need to calculate how long it takes a message to get from one place to another, and Ethernet can only give a probability." Excuse me but I thought life was probabilistic even when tokens were used to solve contention problems. Even if you can calculate the time to get the token, packets still might get trashed in transmission. Further if you are using virtual circuit oriented protocols at upper layers, meerly getting the token does not mean you can transmit, the relevant window might be closed, because the last time the machine which could open the window got the token, he was so busy transmitting to yet another machine that he could not send out necessary ACKs. If datagrams are being used (which I don't think were part of the MAP suite when I looked over the spec last year) unreliability makes for probabalistic calculations. Do the MAP/TOP people know something which I don't? Or are they just totally off the wall? Yaqim Martillo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12292825682.6.MRC%40PANDA] <1987040723481600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MRC%PANDA@SUMEX-AIM.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <12292825682.6.MRC@PANDA> Date: Wed, 8-Apr-87 04:48:16 EST Article-I.D.: PANDA.12292825682.6.MRC Posted: Wed Apr 8 04:48:16 1987 Date-Received: Sat, 11-Apr-87 05:10:53 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa Alan - I consider it a given that Unix will never be "safe" (although it can be made a lot "safer"). The whole point of my message (or flames, if you will) was to knock a hole into some of the complacency surrounding "standard" software. The incident that started this entire discussion demonstrated an instance in which a particular operating system lacked a sanity check. It is my contention that certain (but not all) versions of this operating system (Unix) have an endemic lack of such sanity checks. Since this operating system is the primary operating system on the DDN it is crucial that these oversights be corrected. Otherwise, as long as there are other operating systems or crackers on the network there will be similar incidents. If I didn't care, I'd keep my mouth shut. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704081002.AA29360%40oce-rd2.oce.nl] <1987040800022500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mhsc@oce.nl.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8704081002.AA29360@oce-rd2.oce.nl> Date: Wed, 8-Apr-87 05:02:25 EST Article-I.D.: oce-rd2.8704081002.AA29360 Posted: Wed Apr 8 05:02:25 1987 Date-Received: Sat, 11-Apr-87 06:29:56 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa Path: oce!mhsc From: mhsc@oce.nl (Maarten Schoonwater) Newsgroups: mod.protocols.tcp-ip,comp.sys.m68k,mod.computers.68k Subject: TCP-IP for 68000 VERSAdos system Message-ID: <29@oce-rd2.oce.nl> Date: 8 Apr 87 10:02:23 GMT Reply-To: mhsc@oce-rd2.UUCP (Maarten Schoonwater) Organization: Oce-Nederland bv, Venlo, the Netherlands Lines: 10 We have several 68000 based systems that we need to interface with an Ethernet using TCP-IP protocols. The systems run under the Motorola VERSAdos operating system on a VME-bus. Till now we only found Unix based TCP-IP implementations. Support for ftp and perhaps telnet would be sufficient. Does anyone know of possible solutions?? Maarten Schoonwater Usenet: mhsc@oce.nl Oce-Nederland B.V. mail : P.O. 101 5900MA Venlo R&D department The Netherlands ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704081056.AA27271%40ucbvax.Berkeley.EDU] <1987040800304900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@BARILVM.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Tcpip Overview Message-ID: <8704081056.AA27271@ucbvax.Berkeley.EDU> Date: Wed, 8-Apr-87 05:30:49 EST Article-I.D.: ucbvax.8704081056.AA27271 Posted: Wed Apr 8 05:30:49 1987 Date-Received: Sat, 11-Apr-87 05:11:05 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Perhaps the best one I have found so far that is available online is RFC871 (for all those who asked). Thanks to all those who responded, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704081256.AA06369%40gateway.mitre.org] <1987040802564200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@GATEWAY.MITRE.ORG.UUCP Newsgroups: mod.protocols.tcp-ip Subject: errata:How big is big Message-ID: <8704081256.AA06369@gateway.mitre.org> Date: Wed, 8-Apr-87 07:56:42 EST Article-I.D.: gateway.8704081256.AA06369 Posted: Wed Apr 8 07:56:42 1987 Date-Received: Sat, 11-Apr-87 06:31:06 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa I have got to start screening my mail more carefully for typos. We at MITRE do NOT forward traffic between ARPANET and MILNET. PT ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704081259.AA17700%40topaz.rutgers.edu] <1987040802591400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Access control and accountability Message-ID: <8704081259.AA17700@topaz.rutgers.edu> Date: Wed, 8-Apr-87 07:59:14 EST Article-I.D.: topaz.8704081259.AA17700 Posted: Wed Apr 8 07:59:14 1987 Date-Received: Sat, 11-Apr-87 06:31:51 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 30 Approved: tcp-ip@sri-nic.arpa There are fairly widely-available patches to Unix to allow you to control access to TCP. It restricts the ability to open a network connection based on the network number. That is, you create a list of "local" networks. (We assume you want users to be able to access local machines, and are concerned only about the Arpanet, etc. If you want to restrict all access, you can make this list empty.) Attempts to open connections to networks not in this list fail unless the user is in a certain specified user group. However this does not control daemons. E.g. mail will still work because the mailer has to have network access. You will need to insert the access control in sendmail also. We have done all of this stuff in the past, but are not doing it now. It is nearly impossible to control mail. There are now so many gateways, that you can always find some machine on the local network that will forward your mail to the Arpanet for you. Not to mention UUCP or Bitnet to Arpanet gateways. However other services should work. Cisco gateways allow access control lists to be attached to various operations. This includes incoming and outgoing telnet connections (applied only when the connection opens), and packets going out a specified interface. We have an access control list on our Arpanet gateway. The lists can use wildcards or individual hosts, however for performance reasons there is a limit to the number of wildcard conditions you can have. I know that people are working on accounting and performance monitoring of the type you mention, but I don't know of anything that is available now. Of course most gateways and TCP/IP implementations maintain packet and event counts of various sorts. So if you just mean counts of packets per interface in and out, the Unix TCP/IP implementations and Cisco gateways do this. I presume other vendors' gateways do as well. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704081320.AA06603%40gateway.mitre.org] <1987040803204600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@GATEWAY.MITRE.ORG.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ICMP As A Diagnostic Tool? Message-ID: <8704081320.AA06603@gateway.mitre.org> Date: Wed, 8-Apr-87 08:20:46 EST Article-I.D.: gateway.8704081320.AA06603 Posted: Wed Apr 8 08:20:46 1987 Date-Received: Sat, 11-Apr-87 06:32:04 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 27 Approved: tcp-ip@sri-nic.arpa From Miles Fidelman: > It's been my observation that ICMP provides some useful functionality for > isolating and diagnosing internetwork problems - e.g. by timing pings, > looking at what percentage of echos come back, source routing packets via > specific paths, route recording, etc. > > It strikes me that the lack of similar functionality for the OSI world may > lead to an OSI internet in which significant classes of problems can not > be fault isolated. I find this a rather scary thought. It is not true that the OSI world lacks similar functionality. ISO IP ISO 8473) has error messages which covers everything ICMP does except Redirect, Echo, and Timestamp, and Information. The Redirect function in ISO is in the ES-IS (End System to Intermediate System) routing protocol, DP 9542. The Echo function can be accomplished by using partial source route with the "echoing" machine on the list. (This if the distant machine is an IS.) To an ES, a transport connection can be used much to the same, if not better, effect. In addition, ISO is working on a suite of management functions and protocols which will allow for much more detailed and flexible management, debugging, etc., of networks. I can't speak for all layers, but in ANSI X3S3.3 (Network and Transport layers) we are actively working on this. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704081413.AA20986%40beno.CSS.GOV] <1987040804135100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mo@SEISMO.CSS.GOV.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Token nets and deterministic behavior Message-ID: <8704081413.AA20986@beno.CSS.GOV> Date: Wed, 8-Apr-87 09:13:51 EST Article-I.D.: beno.8704081413.AA20986 Posted: Wed Apr 8 09:13:51 1987 Date-Received: Sat, 11-Apr-87 06:48:04 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Having actually conducted experiments to measure these claims of deterministic behavior, I can say that (1) it simply ain't so and (2) you don't WANT it to be so. Token rings have their own brand of strange pathologies related to convoying, syncronized buffer blocking, and such. It is very clear from our experiments that the hardware never read the papers describing the "theoretical" behavior. "Fantasized" would be a better word. The paper, and a couple of others along the same line, is in the Proceedings of the IEEE Symposium on Computer Networking, December, 1983, if you care to look at the numbers. -Mike O'Dell ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704081421.AA07563%40gswd-vms.ARPA] <1987040804200100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: preece%mycroft@GSWD-VMS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <8704081421.AA07563@gswd-vms.ARPA> Date: Wed, 8-Apr-87 09:20:01 EST Article-I.D.: gswd-vms.8704081421.AA07563 Posted: Wed Apr 8 09:20:01 1987 Date-Received: Sat, 11-Apr-87 06:49:20 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa From: "Alan R. Hill" > My years of experience in dealing with security indicates that data > should be encrypted whenever practical. Relying on software or system > adminstrators is folly. ---------- Unless you're doing all your work on a trusted workstation, to which only you have access, encryption isn't enough. The processor on which the work is done has to encrypt and decrypt, meaning that the data has to be floating around in plaintext form at some times. If your software is ignoraably secure, then so is your transitory plaintext. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704081456.AA00470%40ucbvax.Berkeley.EDU] <1987040804295000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ahill@CC7.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: My Broadcast Message-ID: <8704081456.AA00470@ucbvax.Berkeley.EDU> Date: Wed, 8-Apr-87 09:29:50 EST Article-I.D.: ucbvax.8704081456.AA00470 Posted: Wed Apr 8 09:29:50 1987 Date-Received: Sat, 11-Apr-87 07:05:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Mark, History indicates that "whistle blowing" is not generally appreciated regardless of its well meaning intent. Unless DoD specifies requirements for Unix use on the internet, I doubt that anything will change. Although there are lots of security problems with Unix and its network code, I thought I would relate my experience with this type of problem. Many years ago I had responsibility for a Unix system that was used by competing contractors and a government agency. My job was to prevent importation of non-approved code that could compromise the integrity of the system. I also had to keep the various groups from digging into each others files. I modified the access code for the network and the file system. It took me roughly 2 hours work and I was able to restrict access by user and source location. I also logged all access attempts good or bad. My point is that the effort to dramatically improve control is not costly. I suggest that this discussion is no longer useful to the TCP-IP mailing list and can be continued off-line. I generally approve of comments that will evoke an emotional response since they will generate much more data than those that are more benign. Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [199%40cos.COM] <1987040804464200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: howard@cos.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Access control and accountability Message-ID: <199@cos.COM> Date: Wed, 8-Apr-87 09:46:42 EST Article-I.D.: cos.199 Posted: Wed Apr 8 09:46:42 1987 Date-Received: Sat, 11-Apr-87 07:06:51 EST References: <8704071037.AA04224@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: Corporation for Open Systems, McLean, VA Lines: 73 Approved: tcp-ip@sri-nic.arpa Summary: OSI accounting and access control In article <8704071037.AA04224@ucbvax.Berkeley.EDU>, HANK@TAUNIVM.BITNET (Hank Nussbacher) writes: > With that behind me I would like to know about solutions in Tcp/Ip for > the following two areas: > As a side note, anyone who is up on ISO: what is the status of accounting > and access control in ISO? Has it even been thought of? Here are some answers, or directions, for the questions raised, but from an ISO context: The ISO OSI Management Framework, a draft appendix to the OSI Reference Model, defines five missions in OSI management: configuration, fault, performance, security, and accounting management. This is an architectural definition of the problem, not an implementation specification. Associated with this architecture are the Common Management Information Service (CMIS) and the Common Management Information Protocol (CMIP) definitions, which describe mechanisms for management entities to exchange general management information. There is a subtle distinction between "security" and "security management". Such mechanisms as link or end-to-end encryption are security mechanisms, part of the data link or transport layer definitions. If these mechanisms are not implemented, there is no need to manage them and thus no need for security management. Once you decide to have them, security management then logically should exist to provide such supporting services as breach attempt logging, key distribution, etc. Similar distinctions apply in accounting; accounting data collection is a layer function, but data distribution is a management function. > 1) Access control: >On a system level: How do I go about restricting the use of users > from using Tcp/Ip? >On a gateway level: If I have a gateway (say something like Bridge > or cisco) do I have any capability of performing any sort of access > control? If yes, is this access control based on connected machines > or can I even exercise access control on a user level (i.e. restrict > FTP or TELNET to a certain group of users on a certain machine). Association Control Service Elements (ACSE --formerly CASE) , a layer 7 function, does deal with access control to OSI applications. Other applications, such as FTAM (File Transfer, Access, and Management) do have their own access control mechanisms, including optional anonymous user access. > 2) Accounting: > System level: Is there any accounting package that can measure things > like packet transfer (FTP always tells you how many Kb/sec you sent > so it isn't impossible to figure out) levels and > Telnet connect time? ANSI standards X3.102 and X3.141, the latter in publication, define general models for describing such things as packet transfer time; draft ANSI work in the T1Q1.3 committee and the Question 29 Rapporteur's group in CCITT Study Group VII also are dealing with such problems. Neal Seitz, at the U.S. Commerce Department's Institute for Telecommunications Sciences in Boulder, CO, is the chair of the latter groups and a major author of the preceding standards. He has some public domain software available from his group (telephone 303-497-3106; I don't have a net address). > Gateway level: Is there some gateway or monitoring PC that can do > accounting? Is the accounting per system or can it be broken down > per user (I assume very difficult to do)? There are general, hardware-based monitoring systems which can do this. They are not cheap, and the mindset of their sales forces is primarily dealing with response time measurement in IBM 3270 and similar environments. Nevertheless, systems made by Tesdata (also the OEM for Infinet and Paradyne), Avant-Garde, and Dynatech do have some ability to track applications, users, or other high-level entities. Several] years ago, I did the first Tesdata design, and know that it's quite internally capable of tracking network addresses, user ID's, etc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040805415400> Received: from LOKI.BBN.COM by SRI-NIC.ARPA with TCP; Wed 8 Apr 87 09:39:03-PDT To: karn%jupiter.bellcore.com@relay.cs.net cc: tcp-ip@sri-nic.ARPA Subject: re: A New TCP Retransmission Algorithm Date: Wed, 08 Apr 87 12:21:54 -0400 From: Craig Partridge Phil, I've been looking at the same problem from the perspective of RDP for some months. Some of my conclusions are in a paper I'm presenting at the June USENIX. Most of them are the same as yours, except I came up with a different selection algorithm based on the assumption that the network *usually* maintains relative order (if packet A is sent before packet B, then is is likely that A will reach the destination before B). By the way, in support of the view that we need to look at retransmission timeouts, I've seen the SRTT explode at loss rates below 10% on some systems. One other point -- your algorithm is engaged in throwing away a certain number of good RTT values because the filtering isn't perfect. If the RTT suddenly increases sharply, you have to throw out the first packet that has the new RTT, and wait for the second packet to be accepted. Out of curiousity, what is beta in your implementation? I.e., how much does the RTT have to increase to cause this problem? Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040806295000> Received: from cc7.bbn.com by SRI-NIC.ARPA with TCP; Wed 8 Apr 87 07:51:06-PDT Date: Wed, 8 Apr 87 10:29:50 EDT From: "Alan R. Hill" Subject: Re: My Broadcast In-Reply-To: Your message of Wed, 8 Apr 87 02:48:16 PDT To: Mark Crispin Cc: ahill@cc7.bbn.com, NJG%CORNELLA.BITNET@wiscvm.wisc.edu, tcp-ip@sri-nic.arpa Mark, History indicates that "whistle blowing" is not generally appreciated regardless of its well meaning intent. Unless DoD specifies requirements for Unix use on the internet, I doubt that anything will change. Although there are lots of security problems with Unix and its network code, I thought I would relate my experience with this type of problem. Many years ago I had responsibility for a Unix system that was used by competing contractors and a government agency. My job was to prevent importation of non-approved code that could compromise the integrity of the system. I also had to keep the various groups from digging into each others files. I modified the access code for the network and the file system. It took me roughly 2 hours work and I was able to restrict access by user and source location. I also logged all access attempts good or bad. My point is that the effort to dramatically improve control is not costly. I suggest that this discussion is no longer useful to the TCP-IP mailing list and can be continued off-line. I generally approve of comments that will evoke an emotional response since they will generate much more data than those that are more benign. Alan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704081656.AA02575%40ucbvax.Berkeley.EDU] <1987040806591500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@LOKI.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: re: A New TCP Retransmission Algorithm Message-ID: <8704081656.AA02575@ucbvax.Berkeley.EDU> Date: Wed, 8-Apr-87 11:59:15 EST Article-I.D.: ucbvax.8704081656.AA02575 Posted: Wed Apr 8 11:59:15 1987 Date-Received: Sat, 11-Apr-87 07:08:10 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Phil, I've been looking at the same problem from the perspective of RDP for some months. Some of my conclusions are in a paper I'm presenting at the June USENIX. Most of them are the same as yours, except I came up with a different selection algorithm based on the assumption that the network *usually* maintains relative order (if packet A is sent before packet B, then is is likely that A will reach the destination before B). By the way, in support of the view that we need to look at retransmission timeouts, I've seen the SRTT explode at loss rates below 10% on some systems. One other point -- your algorithm is engaged in throwing away a certain number of good RTT values because the filtering isn't perfect. If the RTT suddenly increases sharply, you have to throw out the first packet that has the new RTT, and wait for the second packet to be accepted. Out of curiousity, what is beta in your implementation? I.e., how much does the RTT have to increase to cause this problem? Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704081823.AA03916%40mitre.ARPA] <1987040808234600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: raju@MITRE.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: test Message-ID: <8704081823.AA03916@mitre.ARPA> Date: Wed, 8-Apr-87 13:23:46 EST Article-I.D.: mitre.8704081823.AA03916 Posted: Wed Apr 8 13:23:46 1987 Date-Received: Sat, 11-Apr-87 09:26:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The MITRE Corp., Washington, D.C. Lines: 1 Approved: tcp-ip@sri-nic.arpa please ignore, this is a test. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704081757.AA03566%40ucbvax.Berkeley.EDU] <1987040808340000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NS-DDN@DDN3.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Access control and accountability Message-ID: <8704081757.AA03566@ucbvax.Berkeley.EDU> Date: Wed, 8-Apr-87 13:34:00 EST Article-I.D.: ucbvax.8704081757.AA03566 Posted: Wed Apr 8 13:34:00 1987 Date-Received: Sat, 11-Apr-87 09:26:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 32 Approved: tcp-ip@sri-nic.arpa The UCLA ACP and its derivatives are very concerned about access control, and less concerned about accounting. The public domain code has a pseudo-service called PACCESS which is invoked at choice places in the package to inquire as to the efficacy of an end user's requests. Unless the installer does some coding, the barn door is wide open for using TCP, UDP, TELNET, etc., and whatever security system installed on MVS controls file access. UCLA has an interface to ACF2 which is based upon a local interface SVC, and their version of PACCESS can be conditionally assembled. However, the interface involves some pretty trick UCLA MVS mods and would require substantial systems programming expertise and time to massage into another environment. DDN/MVS features a modified version of PACCESS which uses a table of user-ids, passwords, and user attributes to control user access. Customers code macros for each user, reassemble the table, and link it into the commutator. This controls VTAM accesses to the internet, use of some privileged TELNET services, authorizations to receive SMTP mail on a mailbox basis, and FTP file accesses on a high-level DSNAME qualifier basis. For accounting, the public domain version sports logic which accumulates CPU time used by pseudo-tasks or counts ptask dispatches (the default). However, no provision is made for reporting this information to an accounting system. Here again, it is expected that an experienced systems programmer is installing the ACP into a sophisticated MVS shop. The FTP logic has a place (FTPWACR - Write ACcounting Record) where an SMF record could be cut, but only generates an internal WTO-type messaage describing the FTP request. DDN/MVS currently provides no enhancements to the accounting support. Dave Craig Network Solutions, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040808340001> Received: from ddn3.arpa by SRI-NIC.ARPA with TCP; Wed 8 Apr 87 10:48:43-PDT Date: 8 Apr 87 13:34 EST From: NS-DDN @ DDN3.arpa Subject: Re: Access control and accountability To: HANK%BARILVM.BITNET @ WISCVM.WISC.EDU, tcp-ip @ SRI-NIC.ARPA CC: The UCLA ACP and its derivatives are very concerned about access control, and less concerned about accounting. The public domain code has a pseudo-service called PACCESS which is invoked at choice places in the package to inquire as to the efficacy of an end user's requests. Unless the installer does some coding, the barn door is wide open for using TCP, UDP, TELNET, etc., and whatever security system installed on MVS controls file access. UCLA has an interface to ACF2 which is based upon a local interface SVC, and their version of PACCESS can be conditionally assembled. However, the interface involves some pretty trick UCLA MVS mods and would require substantial systems programming expertise and time to massage into another environment. DDN/MVS features a modified version of PACCESS which uses a table of user-ids, passwords, and user attributes to control user access. Customers code macros for each user, reassemble the table, and link it into the commutator. This controls VTAM accesses to the internet, use of some privileged TELNET services, authorizations to receive SMTP mail on a mailbox basis, and FTP file accesses on a high-level DSNAME qualifier basis. For accounting, the public domain version sports logic which accumulates CPU time used by pseudo-tasks or counts ptask dispatches (the default). However, no provision is made for reporting this information to an accounting system. Here again, it is expected that an experienced systems programmer is installing the ACP into a sophisticated MVS shop. The FTP logic has a place (FTPWACR - Write ACcounting Record) where an SMF record could be cut, but only generates an internal WTO-type messaage describing the FTP request. DDN/MVS currently provides no enhancements to the accounting support. Dave Craig Network Solutions, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704081945.AA00386%40apolling.imagen.uucp] <1987040809454700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@apolling.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: A New TCP Retransmission Algorithm Message-ID: <8704081945.AA00386@apolling.imagen.uucp> Date: Wed, 8-Apr-87 14:45:47 EST Article-I.D.: apolling.8704081945.AA00386 Posted: Wed Apr 8 14:45:47 1987 Date-Received: Sat, 11-Apr-87 08:19:06 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.DEC.COM Distribution: world Organization: The ARPA Internet Lines: 62 Approved: tcp-ip@sri-nic.arpa > 1. If a segment being ACKed was sent only once, update the estimated round > trip time and recompute the timeout interval. (This is standard behavior). > > 2. If a timeout occurs, back off the timeout timer interval (e.g., double > it), retransmit the oldest unacknowledged segment, and restart the timeout > timer. (Again, nothing unusual). > > 3. When an ACK comes in for a segment that was sent more than once (i.e., > retransmitted at least once) do NOT attempt to measure its round trip time; > leave the smoothed estimate alone. FURTHERMORE, KEEP THE BACKED-OFF TIMER > SETTING FOR THE *NEXT* SEGMENT, AND DO NOT RECOMPUTE IT FROM (BETA*SRTT) UNTIL > IT OR A LATER SEGMENT HAS BEEN ACKED WITHOUT A RETRANSMISSION. Looks good. If it works, all the better! I like the separation of the RTT estimate from the timeout computation. I think it would help the description of the algorithm to make the separation clearer. The RTT estimate is a particular metered value, so it makes a lot of sense to not try to update it based on data that is questionable. The timeout value is a function of the RTT estimate, but need not be a simple function -- sometimes it might not depend on the RTT estimate at all, as you cleverly suggest. The possible problem is that the RTT might not be estimated for a long time (if packets are lost frequently). It looks like the algorithm will correctly play with the timeout in the absence of measured RTT values. I'm not sure what you do in [1], though. If you compute something like RTTnew = (7*RTTold + RTTmeasured)/8 then your behavior may be bad when the RTT had become seriously out of date and was then measured. You'll get a damped oscilatory response, I think. An example: Say the RTT estimate is 1 second and the retransmission timer is 2 s. Now imagine that the the network conditions change abruptly so that the real network RTT is 10 seconds. For several segments, you get spurious retransmissions and don't compute the RTT. Meanwhile the retransmission timer is increased using normal backoff. Eventually, it hits ~10 seconds or so, and you get a valid computation of RTT. This gives you: RTTnew = (7*1 + 10)/8 = 2.125 Then you might compute timer = RTT * 2 = 4.25 s This means that the next segment will also be retransmitted spuriously, and the process repeats. Maybe my example is too severe when compared with the real world (I don't think so, if you have both satnets, X.25 links and direct lines as alternate paths to each other). I guess the moral of the story is to use a method of smoothing the RTT estimate that converges very quickly, like RTTnew = (RTTold + RTTmeasured)/2 or even RTTnew = RTTold One element of incompleteness in the algorithm is the turn-on transition. You don't specify how to make the initial RTT and Timer guesses. In view of the above, that sounds especially important in this algorithm. - Geof Cooper ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1987.4.8.20.39.14.Rudy.Nedved%40h.cs.cmu.edu] <1987040810521600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Rudy.Nedved@H.CS.CMU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Security or what? Message-ID: <1987.4.8.20.39.14.Rudy.Nedved@h.cs.cmu.edu> Date: Wed, 8-Apr-87 15:52:16 EST Article-I.D.: h.1987.4.8.20.39.14.Rudy.Nedved Posted: Wed Apr 8 15:52:16 1987 Date-Received: Sat, 11-Apr-87 08:57:16 EST References: <8704072114.AA02584@emptys.cc.umich.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Michael, I read your message in response to Mark Cripin's flame. I only want to comment on guru versus system programmer misunderstanding you have. We have many people at CMU that can crack a system but are impossible to communicate with. These people are brilliant but their personaility is very very poor on interpersonal skills. In many cases, they are in control of important software. There is no intent to discourage such situations by management since all benefit....on the other hand they are not policy or decision makers except in their own "world". In some cases, I have dealt with people that control software and blantantly ignore management. Management is in a position of needing them and not feeling the issue is critical enough to fire (since they have a hard time evaluating the situation). The result is the hacker is viewed as a guru who controls the systems and runs it as he sees fit and management tolerates him until he leaves. In the final analysis, hacker is not the same as guru which is not the same as system programmer which is not the same as system manager. Luckily, many people have some or all of these "jobs" at the same time....makes life interesting. Cheers, -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704082052.AA02897%40bu-cs.bu.edu] <1987040810525000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bzs@BU-CS.BU.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: My Broadcast Message-ID: <8704082052.AA02897@bu-cs.bu.edu> Date: Wed, 8-Apr-87 15:52:50 EST Article-I.D.: bu-cs.8704082052.AA02897 Posted: Wed Apr 8 15:52:50 1987 Date-Received: Sat, 11-Apr-87 06:23:19 EST References: <8704081136.AA24197@bu-cs.bu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 81 Approved: tcp-ip@sri-nic.arpa >...If Unix is still vulnerable >after a decade of availability should we ever expect it to be safe? Look folks, we're really flying off the handle here on innuendo and virtually no facts. Let me try to rehash what I believe happened that started all this: Sun provided a utility, rwalld, which is a daemon which listens for certain informatory message broadcasts on a network (such as a scheduled system shutdown) and displays them on terminals. This was an extension of the single system 'wall' (Write ALL) program that most UNIX systems come with. Wall, as it is standardly provided, is not the issue. Most O/S's come with some utility to broadcast a message within a local system (ie. no network involved.) Sun simply extended this service to a network facility (leaving the older method intact, thus it was an optional extension.) The security breach was that someone discovered that many systems were configured to accept these broadcasts fairly indiscriminately. This, in turn, was due not to a lack of security inherent in the system, but the fact that the way the system comes off the tape it allows this. All O/S's come off of distribution tapes inherently insecure (eg. super-user password is typically generic or null.) There is a facility (netgroups) which is supposed to be set up by the concerned system administrator with those machine groups who are to be allowed to issue such broadcasts (well, that's a little backwards, you list the systems who you will accept such messages from.) So, in complete contradiction to Mark Crispin's analysis, it was not the "random gurus" who were the problem in finding an unclosed security hole but, rather, the sysadmins who never even opened the manuals to find out what daemons they were running and how to administer security (there aren't that many, look at your start-up files and services/servers files.) Or, perhaps as was the case with my system (which received the broadcast) they didn't particularly care if someone sent such a message and viewed it in the same light as someone sending mail to someone who didn't want it, a nuisance that could be dealt with easily if a problem arises (I am still not convinced there is much of a problem with this particular event.) We never really took a vote on how many people even agree that a security breach worthy of concern has occurred on their system, even that fundamental observation remains an opinion. Thus, as is almost always the case with system security, it was not the fault of the system providers but entirely the fault of those charged with the responsibility of maintaining the system, if they were concerned about this (later) then they have only themselves to blame. They simply left the barn door wide open, ignoring the door, the lock and the key. To add insult to the system administrator's injury, not only was it within their normal administrative power to limit such an event with a simple file edit, they never even had to run the utility at all. It is purely icing on the cake to find out about other system's status changes on your network and can be removed by adding one comment character to one line in the system's start-up file with no real ill effect on the operation of the system (remember, only SUN's UNIX even has this particular utility.) I really wish that people who send notes discussing these issues would ask themselves if their notes actually contain any factual information. If nothing else, this whole interchange has pointed out how ill-informed many folks are about security management on various systems and how they have turned to folk tales and philosophizing to supplant that void. This, in my opinion, is a far worse problem. I do not deny that there are security and integrity problems on an internet. I only claim that little of the discussion I have seen has moved us any closer to measuring and rectifying the problems instead of just finding someone to blame (we has met the enemy and they is us.) -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [VAX-MM(195)%2BTOPSLIB(124).8-Apr-87.16:43:59.VAX.DARPA.MIL] <1987040811435900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: errata:How big is big Message-ID: Date: Wed, 8-Apr-87 16:43:59 EST Article-I.D.: Posted: Wed Apr 8 16:43:59 1987 Date-Received: Sat, 11-Apr-87 09:48:01 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 4 Approved: tcp-ip@sri-nic.arpa As they say, tut tut! dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040811435901> Received: from vax.darpa.mil by SRI-NIC.ARPA with TCP; Wed 8 Apr 87 14:44:11-PDT Posted-Date: Wed 8 Apr 87 16:43:59-EST Received: by vax.darpa.mil (5.54/5.51) id AA02230; Wed, 8 Apr 87 17:44:07 EDT Date: Wed 8 Apr 87 16:43:59-EST From: Dennis G. Perry Subject: Re: errata:How big is big To: tsuchiya@gateway.mitre.org Cc: tcp-ip@sri-nic.arpa, perry@vax.darpa.mil Message-Id: In-Reply-To: Message from "tsuchiya@gateway.mitre.org (Paul Tsuchiya)" of Wed, 8 Apr 87 08:56:42 EDT As they say, tut tut! dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704082245.AA04129%40spam.istc.sri.com] <1987040812130100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gds@SPAM.ISTC.SRI.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ICMP As A Diagnostic Tool? Message-ID: <8704082245.AA04129@spam.istc.sri.com> Date: Wed, 8-Apr-87 17:13:01 EST Article-I.D.: spam.8704082245.AA04129 Posted: Wed Apr 8 17:13:01 1987 Date-Received: Sat, 11-Apr-87 08:17:57 EST References: <8704081320.AA06603@gateway.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa The Redirect function in ISO is in the ES-IS (End System to Intermediate System) routing protocol, DP 9542. The Echo function can be accomplished by using partial source route with the "echoing" machine on the list. (This if the distant machine is an IS.) To an ES, a transport connection can be used much to the same, if not better, effect. I believe one advantage to the way we do ICMP echoes is that, for all the implementations I have heard of, processing of the echo reply takes place in kernel space instead of user space. The use of a user program waiting on a transport connection to trap echoes and generate echo replies requires scheduling of that process. If the system is loaded, it will lessen the accuracy of the round-trip time. In case anyone is interested, I have some war stories describing the use of ICMP for fault isolation. (Example: discovering that you have lost your gateway, and finding a new one.) They're too long to reprint here, but might provide some amusing reading. --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040816004900> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Wed 8 Apr 87 03:40:55-PDT Received: from BARILVM.BITNET by wiscvm.wisc.edu on 04/08/87 at 05:40:47 CDT Received: by BARILVM (Mailer X1.23b) id 9376; Wed, 08 Apr 87 12:31:51 O Date: Wed, 08 Apr 87 12:30:49 O From: Henry Nussbacher Subject: Tcpip Overview To: tcp-ip@sri-nic.ARPA Perhaps the best one I have found so far that is available online is RFC871 (for all those who asked). Thanks to all those who responded, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704090911.AA20768%40ucbvax.Berkeley.EDU] <1987040823013500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@BARILVM.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Summary of Tcp/Ip overviews (for all who asked) Message-ID: <8704090911.AA20768@ucbvax.Berkeley.EDU> Date: Thu, 9-Apr-87 04:01:35 EST Article-I.D.: ucbvax.8704090911.AA20768 Posted: Thu Apr 9 04:01:35 1987 Date-Received: Sat, 11-Apr-87 11:22:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa Computer Networks, V7, No 5, October 1983, DOD Architecture Model by Cerf and Cain. Postel, J., C. A. Sunshine, and D. Cohen, "The ARPA Internet Protocol," Computer Networks, pp. 261-271, July 1981. Leiner, Barry M., Robert Cole, Jon Postel, and David Mills, "The DARPA Internet Protocol Suite," IEEE Communica- tions, vol. 23, no. 3, pp. 29-34, March 1985. BACKGROUND RFCs IEN-48 The Catenet Model for Internetworking RFC-896 * Congestion Control in IP/TCP RFC-970 * On Packet Switches with Infinite Storage RFC-813 Window and Acknowledgement Strategy in TCP RFC-814 Name, Addresses, Ports, and Routes RFC-815 IP Datagram Reassembly Algorithms RFC-816 Fault Isolation and Recovery RFC-817 Modularity and Efficiency in Protocol Implementation RFC-871 * A Perspective on the ARPANET Reference Model ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040900463500> Received: from tsca.istc.sri.com by SRI-NIC.ARPA with TCP; Thu 9 Apr 87 14:11:07-PDT Received: by tsca.istc.sri.com (5.51/4.16) id AA17161 for tcp-ip@sri-nic; Thu, 9 Apr 87 14:06:40 PST From: J. Joaquin Garcia-Luna Message-Id: <8704092206.AA17161@tsca.istc.sri.com> To: tcp-ip@sri-nic Cc: garcia@tsca.istc.sri.com Subject: Call for Participation Date: Thu, 09 Apr 87 14:06:35 -0800 We are looking for contributions in TCP/IP interoperation for the ACM SIGCOMM workshop on frontiers in computer communications technology. Topics include better performance tcp/ip implementations, interoperation, adoption in Japan, comparison with tp 4, use of tcp over mixed media links (satellites, radio nets, telephone lines), window mechanism analysis, etc. If you plan to contribute, please drop me a message. More information follows. JJ --------- CALL FOR PARTICIPATION ACM SIGCOMM Workshop on Frontiers in Computer Communications Technology August 11-13, 1987 Stoweflake Resort, Stowe, Vermont Sponsored by ACM SIGCOMM, with the cooperation of the Information Sciences and Technology Center of SRI International, and Cybertree Inc. ----------------------------------------------------------------------- The ACM SIGCOMM workshop on frontiers in computer communications technology is intended as an international forum where those interested in the theory, development, and applications of computer communications can meet to discuss the state of the art and future directions in computer communications, and to further each other's work through shared information. Contributions in the form of 20 to 30 minute presentations are sought in the areas of: TCP/IP interoperability Gateway protocols and internetworking High-speed networks High-speed packet switching New applications and future directions of packet switched networks ISDN Local area networks and metropolitan area networks Routing and congestion control in integrated-services networks Advances in protocol verification, testing, and analysis Large-scale computer networks Naming in large distributed systems Networking for scientific computing Networking for personal computers Computer-supported collaborative work Distributed desktop publishing and graphics applications Impact of standards in the future of computer communications Attendees wishing to contribute to the program are requested to submit a one to two-page abstract or full papers (about 20 pages) by June 15, 1987 to: PROGRAM CHAIR J.J. Garcia-Luna SRI International 333 Ravenswood Ave., EK-319 Menlo Park, CA 94025 (415) 859-5647 ARPANET: garcia@istc.sri.com Telex: 334486 Abstracts can be submitted by electronic mail. Notification of acceptance will be given by July 10, 1987. The record of the workshop will be published as a special issue of the ACM Computer Communication Review. For more information about the workshop, please contact the program chair, or Dr. Walter Kosinsky, Workshop Chair (203/869-6322). --------------------------------------------------------------------- Please indicate your interest in the workshop here and return this portion to: WORKSHOP REGISTRAR Prof. John Trono Computer Sciences Dept. Saint Michael's College P.O. BOX 243 Winooski, Vermont 05404 ______ I intend to submit an abstract on the subject of ______ I am interested in attending the workshop, please send me additional information. Name: Affiliation: Street Address: City, State, Country: Telephone: Electronic Mail: Fax: Telex: ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040901514100> Received: from okeeffe.Berkeley.EDU ([128.32.130.3]) by SRI-NIC.ARPA with TCP; Thu 9 Apr 87 09:08:03-PDT Received: by okeeffe.Berkeley.EDU (5.58/1.14) id AA09063; Thu, 9 Apr 87 08:51:42 PDT From: karels%okeeffe@berkeley.edu (Mike Karels) Message-Id: <8704091551.AA09063@okeeffe.Berkeley.EDU> To: 4bsd-bugs@okeeffe.Berkeley.EDU Cc: tcp-ip@sri-nic.arpa Subject: 4.3BSD network bug fix (#9, tcp_output) Date: Thu, 09 Apr 87 08:51:41 PDT Index: sys/netinet/tcp_output.c 4.3BSD FIX Note: this message, and other 4.3BSD network-related fixes, are maintained on host ucbarpa.Berkeley.EDU for anonymous FTP from the directory pub/4.3/fixes. Description: TCP may scramble data at the end of a connection under conditions of high packet loss. If a connection is closed while output is still draining (as FTP does), loss of more than one data segment in the last window will cause a byte of data to be deleted without detection. Fix: *** /nbsd/sys/netinet/tcp_output.c Wed Aug 20 09:31:34 1986 --- ./tcp_output.c Sat Mar 28 15:32:04 1987 *************** *** 5,7 **** * ! * @(#)tcp_output.c 7.2 (Berkeley) 8/20/86 */ --- 5,7 ---- * ! * @(#)tcp_output.c 7.2.1.1 (Berkeley) 3/28/87 */ *************** *** 232,235 **** */ ! if (flags & TH_FIN && tp->t_flags & TF_SENTFIN && ! tp->snd_nxt != tp->snd_una) tp->snd_nxt--; --- 232,234 ---- */ ! if (flags & TH_FIN && tp->t_flags & TF_SENTFIN && len == 0) tp->snd_nxt--; ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040906050000> Received: from po5.andrew.cmu.edu by SRI-NIC.ARPA with TCP; Thu 9 Apr 87 11:21:10-PDT Received: by po5.andrew.cmu.edu (5.54/3.15) id for tcp-ip@sri-nic.arpa; Thu, 9 Apr 87 14:20:40 EDT Received: via switchmail; Thu, 9 Apr 87 14:20:36 edt Received: FROM po3.andrew.cmu.edu VIA queuemail ID ; Thu, 9 Apr 87 14:19:49 edt Received: FROM liberty VIA qmail ID ; Thu, 9 Apr 87 10:05:05 edt Message-Id: <8USueAy00UgcyOo0C7@andrew.cmu.edu> X-Trace: MS Version 3.22 on sun host liberty, by ms6b (1145). Date: Thu, 9 Apr 87 10:05:00 edt From: ms6b#@andrew.cmu.edu (Marvin Sirbu) To: tcp-ip@sri-nic.arpa Subject: Re: Ken Olsen vs MAP Cc: martillo@SRI-NIC.ARPA In-Reply-To: <8704080252.AA15578@PARIS.MIT.EDU> The answer to your question is that the MAP people do not fully understand all the sources of probabilistic delay that you catalog. Some are beginning to get the idea, however; Allen Bradley, a major factory automation company, has just contracted with Bridge to OEM Ethernet equipment. In their defense however, they have always been concerned about the situation which might arise when a failure in a manufacturing process causes 500 sensors to all start sending emergency warning messages at the same instant. This can lead to lockup on an Ethernet in a way which should not occur on a token bus. I have heard stories to the effect that one process control company experienced such a lockup on a 128 kbps CSMA/CD network and became an adament supporter of token buses as a result. (Whether that experience could be recreated on a 10 Mbps network is questionable, of course.) Marvin Sirbu CMU ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040906552400> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Thu 9 Apr 87 08:19:58-PDT Received: from relay2.cs.net by RELAY.CS.NET id aa20834; 9 Apr 87 11:15 EDT Received: from waterloo by csnet-relay.csnet id ac28710; 9 Apr 87 11:10 AST Received: by watmath; Thu, 9 Apr 87 10:55:24 EDT Date: Thu, 9 Apr 87 10:55:24 EDT From: Eric Gisin To: tcp-ip@SRI-NIC.ARPA Subject: 4.3 bsd and slip We converted to 4.3 recently, and have a 9600 baud slip P-P link between two hosts. Sometimes the interface goes into a state where there are constantly 20-45 packets on the output queue with a single connection. Throughput goes down, and a "rsh otherhost date" takes forever. Data overrun or line errors are not a problem. From my understanding of tcp, the sending side must be doing excessive retransmissions. I thought 4.3 had fixed most of the network bugs and problems. Does anyone know what's happening before I try to do a tcp trace? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040907272600> Received: from monk.proteon.com by SRI-NIC.ARPA with TCP; Thu 9 Apr 87 08:30:53-PDT Received: by monk.proteon.com; Thu, 9 Apr 87 11:27:26 AST Date: Thu, 9 Apr 87 11:27:26 AST From: jas@monk.proteon.com (John A. Shriver) Message-Id: <8704091527.AA04958@monk.proteon.com> To: tcp-ip@sri-nic.arpa Cc: iso@nrtc.northrop.com In-Reply-To: Greg Skinner's message of Wed, 08 Apr 87 14:45:37 -0800 <8704082245.AA04129@spam.istc.sri.com> Subject: ICMP As A Diagnostic Tool? (ISO) Another important aspect of ICMP echo reply is that it is Mandatory in the TCP/IP suite (see the latest Official ARPA Internet Protocols, where IP and ICMP are the only Mandatory protocols). Using transport-level protocols in ISO for the same function will not be nearly as effective, for example a router (IS in ISO parlance) nominally has no use for transport protocols. I would recommend to ISO designers to add a mandatory echo response at as low a level as possible in the architecture. If the source routing trick does this, and is a mandatory capability of ISO 8473, great. I would then ask the implementers to provide the necessary user program. (But enough, this discussion really belongs on the ISO mailing list, see the CC: address...) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040908004700> Received: from flash.bellcore.com by SRI-NIC.ARPA with TCP; Thu 9 Apr 87 10:07:29-PDT Received: by flash.bellcore.com (4.12/4.7) id AA06298; Thu, 9 Apr 87 13:00:47 est Date: Thu, 9 Apr 87 13:00:47 est From: karn@flash.bellcore.com (Phil R. Karn) Message-Id: <8704091800.AA06298@flash.bellcore.com> To: imagen!geof@decwrl.DEC.COM Subject: Re: A New TCP Retransmission Algorithm Cc: karn@flash.bellcore.com, tcp-ip@sri-nic.arpa You are quite correct in pointing out the oscillatory behavior in the timeout interval when the network delay suddenly increases. I mentioned this in my note, as I have both simulated the behavior you describe and observed it in practice. The important thing, though, is that the oscillation always damps out at the correct new value. How *fast* it damps out depends of course on the smoothing function in use. I've been using Dave Mills' nonlinear function. It seems to work quite well since it responds more quickly to increases than to decreases in observed network delay. The "oscillation" is the result of a compromise between assuming the timeouts are the result of sudden network congestion and assuming the timeouts are caused by packets being lost outright because of link transmit errors. Without information in the TCP header indicating which transmission a given ACK is answering (clearly the ideal solution except for the compatibility problems) my algorithm seems to be a workable heuristic. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [531%40pdp.cs.OHIOU.EDU] <1987040913431600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: shapiro@pdp.cs.ohiou.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: XNS to TCP-IP changeover on Bridge Hardware. Message-ID: <531@pdp.cs.OHIOU.EDU> Date: Thu, 9-Apr-87 18:43:16 EST Article-I.D.: pdp.531 Posted: Thu Apr 9 18:43:16 1987 Date-Received: Sat, 11-Apr-87 15:53:57 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: Ohio University CS Dept., Athens Lines: 37 Keywords: Please help... Approved: tcp-ip@sri-nic.arpa We will soon be making the change from Bridge XNS to TCP-IP on our network. I am not sure that we are looking forward to this change (well at least those who will have to make the change and take responsiblity for it). Is there anyone on the net who has made this change? If so I would like to have some input on the following: 1.) How about a general comment on Bridges release of TCP-IP. 2.) When making the change over is there a way that the current network configurations can be copied over so that we don't have to re-enter all of the port configs? 3.) I have been told that the current release of TCP-IP will boot remotely from our central NCS-150 controller. Is this true? I have not made contact with our Bridge reps yet (seems that this is not my responsiblity). 4.) Can anyone out there address the issue of compatibility with other TCP-IP networks? I have to try to be honest with you folks on the net. This is really an attempt to Cover My A.. when this new software arrives. I hope things will go smoothly but who can say. I personally feel if it ain't broke - don't fix it. The above opinions are mine and not necessarily those of my employer. Ohio University Computing and Learning Services Haning Hall Athens, Ohio 45701 (614) 593-1608 BITNET: shapirob@ouaccvma UUCP: ihnp4!cbosgd!oucs!shapiro ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870410003051.138454%40MIT-MULTICS.ARPA] <1987040914300000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JSLove@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: A New TCP Retransmission Algorithm Message-ID: <870410003051.138454@MIT-MULTICS.ARPA> Date: Thu, 9-Apr-87 19:30:00 EST Article-I.D.: MIT-MULT.870410003051.138454 Posted: Thu Apr 9 19:30:00 1987 Date-Received: Sat, 11-Apr-87 21:50:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 103 Approved: tcp-ip@sri-nic.arpa Counterproposal: the following rules are rather complex, and require more memory than some implementations may use (e.g., a timestamp per packet), but they may prevent the sort of explosion we see in SRTT somewhat better, and they use information which is already available. This combines several schemes, used without credit, so if you think you recognize the serial numbers, you probably do. 1. Keep a timestamp associated with each packet in the retransmission queue which tells when it was first transmitted. This timestamp is provided by IP, and indicates when the packet was given to the device driver. Since retransmissions should use the same IP identifier for reassembly, it is reasonable for TCP and IP to share the same copy of the packet for retransmission purposes. 2. Never retransmit a packet which hasn't been transmitted yet. There are a number of implementations which seem to have this problem. In fact, never retransmit a packet which hasn't had a certain minimum delay since its last transmission: SRTT * VR * RB ** RC Where SRTT is smoothed round trip time, VR is variance ratio, RB is retransmission base, and RC is retransmission count. 3. Let's set VR and RB to 2. This is arbitrary; substitute values to taste. RC is initially zero, and is reset for every packet. It doesn't have to be stored in the packet, since only one packet is retransmitted at a time. The SRTT for the first packet is unknown and doesn't matter. The RTTs used to calculate the SRTT use a variable weight, SF (smoothing factor) which is initially zero. The MSF (maximum SF) is also arbitrary, but values from 4 to 8 seem reasonable. 4. When we transmit the first packet, we set the timer to one second. After the timer has elapsed, we retransmit, and increase the interval geometrically (by RB), so we retransmit after 2 more seconds, then 4, and so on. 5. When the acknowledgement comes back after 10 seconds from the first transmission, we have possible RTTs of 10, 9, 7, and 3. We take the WCRTT (worst case RTT) of 10. 6. For subsequent datagrams, we distinguish between three kinds of RTT: a) the datagram was retransmitted (so we have a WCRTT). b) the datagram wasn't retransmitted, but it was acknowledged at the same time as a subsequent datagram, or a retransmission of a preceding datagram was sent subsequent to the transmission of this datagram. We can't be certain how much of the RTT was due to the influence of other datagrams, so we have an MRTT (merged RTT). c) the datagram wasn't retransmitted, and no retransmissions of preceding datagrams were transmitted after this one. We have an ARTT (actual RTT). 7. Each time an acknowledgement packet is processed, we may produce RTTs, including at most one WCRTT or ARTT, and possibly several MRTTs. All contribute to the SRTT, but at different weights. For the first packet (SYN) or if they would tend to decrease the SRTT, all types count at full weight, so SF = minimum (SF + 1, MSF) SRTT = ((SF - 1) * SRTT + RTT) / SF If they would tend to increase the SRTT, then the weights differ, so that an ARTT counts at full weight, a WCRTT at a lesser weight (perhaps half), and an MRTT somewhere in between. This means that an estimate of the RTT is more strongly influenced by optimistic or reliable data. This should help the algorithm converge on a small number. 8. Depending on the nature of the RTT from the preceding packet, we choose one of the following functions to generate the minimum retransmission interval for the current packet: Delay = maximum (SRTT, ARTT) * VR Delay = maximum (SRTT * VR, MRTT) Delay = maximum (SRTT * VR, WCRTT * PLR) PLR is the packet loss ratio. Lacking a filter to determine PLR as well as VR, it should be set to some arbitrary value sufficient to keep the delay from blowing up in the face of high packet loss rates. Let us assume that packet loss rates (in both directions) never average more than 50%, so a PLR of .5 should be sufficient. 9. Don't ever use a simple timer to determine if a connection has died. Instead, kill the connection when RC gets to a large value. Assuming that SRTT is one, a large value might be 8 (nearly 5 minutes), but the general idea is that the geometric backoff means that a long delay will be needed to determine that the connection is broken, so rather than pick a fixed time interval you can base this on the fixed time interval of consecutive lost packets. Note that failing to acknowledge a packet isn't necessarily enough information since if the remote site closes its window it can still indicate that it is alive by acknowledging old data. However, the geometric backoff means that it might take a very long time to detect the reopened window. A window opening ACK wouldn't be acceptable unless it opened the window farther than it had been before being closed. Does anyone admit to actually closing windows? This might be an argument to limit the maximum retransmission interval to say, two minutes. Even then, you might want a connection to keep trying forever. Comments? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040914313500> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 9 Apr 87 02:05:21-PDT Received: from BARILVM.BITNET by wiscvm.wisc.edu on 04/09/87 at 04:05:18 CDT Received: by BARILVM (Mailer X1.23b) id 0268; Thu, 09 Apr 87 11:01:54 O Date: Thu, 09 Apr 87 11:01:35 O From: Henry Nussbacher Subject: Summary of Tcp/Ip overviews (for all who asked) To: tcp-ip@sri-nic.ARPA Computer Networks, V7, No 5, October 1983, DOD Architecture Model by Cerf and Cain. Postel, J., C. A. Sunshine, and D. Cohen, "The ARPA Internet Protocol," Computer Networks, pp. 261-271, July 1981. Leiner, Barry M., Robert Cole, Jon Postel, and David Mills, "The DARPA Internet Protocol Suite," IEEE Communica- tions, vol. 23, no. 3, pp. 29-34, March 1985. BACKGROUND RFCs IEN-48 The Catenet Model for Internetworking RFC-896 * Congestion Control in IP/TCP RFC-970 * On Packet Switches with Infinite Storage RFC-813 Window and Acknowledgement Strategy in TCP RFC-814 Name, Addresses, Ports, and Routes RFC-815 IP Datagram Reassembly Algorithms RFC-816 Fault Isolation and Recovery RFC-817 Modularity and Efficiency in Protocol Implementation RFC-871 * A Perspective on the ARPANET Reference Model ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040916571500> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Thu 9 Apr 87 19:08:01-PDT To: tcp-ip@sri-nic.ARPA Cc: brescia@ccv.bbn.com Subject: domain transition is not smooth Date: 09 Apr 87 21:57:15 D (Thu) From: Mike Brescia In order to fix mailing lists BEFORE they get broken by yet another transition, I need a tool which will accept a mailing list with garbage addresses, and replace each host part of the address with the corresponding 'correct' name. An 'awk' script would be acceptable, since I have access to u**x-like systems. Thanks for reading, Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040918175300> Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Thu 9 Apr 87 19:17:22-PDT Date: Thu, 9 Apr 87 22:17:53 EDT From: "Lawrence A. DeLuca, Jr." Subject: Security or what? To: Rudy.Nedved@H.CS.CMU.EDU cc: hackers_guild@UCBVAX.BERKELEY.EDU, tcp-ip@SRI-NIC.ARPA, mts@EMPTYS.CC.UMICH.EDU In-reply-to: Msg of 8 Apr 1987 15:52:16 EST from Rudy.Nedved at h.cs.cmu.edu Message-ID: <182107.870409.HENRIK@AI.AI.MIT.EDU> More hacker vs. system programmer flamage: Having spent some time in the MIS world (hired to be a system programmer, but what they really needed was a high-power system manager) I have found that many of the other "system programmers" (i was Unix, they were DOS/VSE) were reluctant to answer questions and share information. They considered it job security. This made it somewhat difficult when I had to make my machines talk to theirs, for example. I have met many hackers who are equally obnoxious, but for a slightly different (though similar) reason - "If you can't figure it out all by yourself, you don't deserve to know." I find either attitude in any person irritating. System programmers are no better than anyone else. larry... ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040920571500> Received: from spam.istc.sri.com by SRI-NIC.ARPA with TCP; Fri 10 Apr 87 10:18:19-PDT Received: by spam.istc.sri.com (5.51/5.00) id AA19375 for tcp-ip@sri-nic.arpa; Fri, 10 Apr 87 10:17:18 PST Message-Id: <8704101817.AA19375@spam.istc.sri.com> To: Jon Crowcroft Cc: unni@cs.ucla.edu, cperry@gateway.mitre.org, AFDDN.BEACH@gunter-adam.arpa, tcp-ip@sri-nic.arpa Subject: Re: ROS/REX In-Reply-To: Your message of Fri, 10 Apr 87 11:48:00 +0100. <8704101725.AA18750@spam.istc.sri.com> Date: Fri, 10 Apr 87 10:17:15 -0800 From: Thomas Eric Brunner Jon, My copy of REX is a preliminary draft (March 1985), at the top of the cover page is the then-current location of the master discfile, so machine readable does exist. /teb ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704100804.AA13000%40ucbvax.Berkeley.EDU] <1987040921485400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sgroff@CCJ.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: A New TCP Retransmission Algorithm Message-ID: <8704100804.AA13000@ucbvax.Berkeley.EDU> Date: Fri, 10-Apr-87 02:48:54 EST Article-I.D.: ucbvax.8704100804.AA13000 Posted: Fri Apr 10 02:48:54 1987 Date-Received: Sat, 11-Apr-87 15:57:31 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa OK. I'll get back to you after I consult the Barclays sales folks. One other question. Is the inclusion of a Customer Support section in this document a one-off thing ?? Or will it appear in other docs ?? If it's the latter, how do I ensure that the Regional Support Centers get included in all future docs ?? Thanks, Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987040923485400> Received: from ccj.bbn.com by SRI-NIC.ARPA with TCP; Fri 10 Apr 87 00:55:29-PDT Date: Fri, 10 Apr 87 3:48:54 EDT From: "J. Stephen Groff" Subject: Re: A New TCP Retransmission Algorithm In-Reply-To: Your message of Thu, 9 Apr 87 13:00:47 est To: "Phil R. Karn" Cc: imagen!geof@decwrl.dec.com, tcp-ip@sri-nic.arpa, sgroff@ccj.bbn.com OK. I'll get back to you after I consult the Barclays sales folks. One other question. Is the inclusion of a Customer Support section in this document a one-off thing ?? Or will it appear in other docs ?? If it's the latter, how do I ensure that the Regional Support Centers get included in all future docs ?? Thanks, Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041001471800> Received: from gswd-vms.ARPA by SRI-NIC.ARPA with TCP; Fri 10 Apr 87 06:49:15-PDT Received: from mycroft.GSD (mycroft.Gould.COM) by gswd-vms.ARPA (5.52/) Message-Id: <8704101349.AA14705@gswd-vms.ARPA> Date: Fri, 10 Apr 87 07:47:18 CST From: feldman%mycroft@gswd-vms.ARPA (Mike Feldman) To: TCP-IP@sri-nic.arpa Subject: Re: Ken Olsen vs MAP > The answer to your question is that the MAP people do not fully understand > all the sources of probabilistic delay that you catalog. ... > > In their defense however, they have always been concerned about the situation > which might arise when a failure in a manufacturing process causes 500 > sensors to all start sending emergency warning messages at the same instant. > This can lead to lockup on an Ethernet in a way which should not occur on a > token bus. I was envolved in designing an early token bus process control system for a control system manufacturer in '69 - '70, when I first saw the Ethernet spec and articles describing it. I was a junior software engineer at the time, and I suggested to the powers-that-be that Ethernet was much simpler to implement, and that we were already doing it for the token recovery sequence (silence on the wire). It's my opinion that it was dogma among communications engineers even then that you needed deterministic bus access time and guaranteed throughput for control system muxes. There were two cases where the system had to perform under Ethernet-busting loads. One was during customer accecptance testing, and the other was when the reactor pressure relief valve failed open. I got angry reactions when I suggested Ethernet would be cheaper and easier to build and would have better performance almost all of the time. They were even more irritated when I suggested the if determinism and known throughput were so important that they use time division multiplexing. These days, there is a lot of support among control system suppliers for MAP. There hope is that the semiconductor industry will see a large market and implement all the hard, expensive lower layers in silicon, because so far it's been too expensive for each system house to develop one that's a comercial and technical success. It might happen, but they still won't get the deterministic round trip message delay needed to implement stable fast feedback loops. These opinions are my own. Mike Feldman Gould Computer Systems Division 1101 East University Avenue Urbana, IL 61801 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041003510300> Received: from SH.CS.NET by SRI-NIC.ARPA with TCP; Fri 10 Apr 87 07:35:19-PDT To: tcp-ip@SRI-NIC.ARPA cc: cic@SH.CS.NET Subject: Re: domain transition is not smooth Date: Fri, 10 Apr 87 10:31:03 -0400 From: Daniel Long CSNET has an address "fixer" that you might try. It's fairly simple-minded but we've found it a helpful first-step in converting mailing lists. It will convert nicknames into official names. It checks both the NIC table and domain servers (with MX). It also knows about non-domain style names that have since disappeared from the NIC table. Mail a message to "fixaddr@relay.cs.net" containing no text except the mailing list (one address per line; user@host is best). You will get a reply that contains an annotated "fixed" list. No guarantees but we've found it to be a helpful step in the conversion of mailing lists here at CSNET. Please send any comments or questions about "fixaddr" to me (long@sh.cs.net). Enjoy, Dan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041004132900> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Fri 10 Apr 87 05:15:51-PDT Date: 10 Apr 1987 08:13:29 EDT Subject: [Nick Gimbrone : Re: tcp/ip/IBM/PROnet] From: C. David Young To: tcp-ip@SRI-NIC.ARPA cc: DYOUNG@A.ISI.EDU Since I got quite a number of responses to my query about how one goes about interfacing an IBM to a PROnet and just as many requests for CC on all information that I receive, I thought it would be worthwhile and easier to just broadcast the information. By far the most common configuration is that of using Wiscnet running under VM and going through a DACU unibus interface with a corresponding unibus interface to the PROnet. Nick Gimbrone took the time to give me a thorough description of this setup and his message follows for those interested. Unfortunately, our situation requires the speed of PROnet 80 (80 mbs) with an upgrade to FDDI (100 mbs) when it is available. (Proteon has an upgrade policy that is quite reasonable.) However, from what I know about the DACU, it is a relatively slow device (256 kbs?). It just does not make much sense to us to use such a slow interface on such a fast bus! I am about to give up trying to attach the IBM directly to the PROnet and instead attach it to an Ethernet through an ACS9310 from Advance Computer Communications. This device will work at the full 10 mbs of the Ethernet and then we can go through an Ethernet/PROnet gateway which should also operate at several mbs. ACC also has TCP/IP for MVS in a package called ACCES/MVS. Bob Dixon also indicated they were using two 4341s connected to a tcp/ip Ethernet via Fibronics KNET hardware and software (and then gatewaying onto the PROnet). I have not investigated this device yet. Once again, thanks to everyone who sent input. David Young --------------- Return-Path: <@wiscvm.wisc.edu:NJG@CORNELLA.BITNET> Received: FROM WISCVM.WISC.EDU BY USC-ISI.ARPA WITH TCP ; 9 Apr 87 18:55:46 EDT Received: from CORNELLA.BITNET by wiscvm.wisc.edu on 04/09/87 at 17:55:31 CDT Received: by CORNELLA (Mailer X1.23b) id 5100; Thu, 09 Apr 87 18:42:05 EDT Date: Thu, 09 Apr 87 18:11:13 EDT From: Nick Gimbrone Subject: Re: tcp/ip/IBM/PROnet To: DYOUNG@a.isi.edu cc: Mark Bodenstein , Mike Hojnowski , Scott Brim >I was given your name by Selden Ball as a person who might know >something about hooking an IBM 4381 to a Proteon Pronet. Could >you tell me about your configuration, both hardware and software? >We are interested in using TCP/IP on an IBM on a PROnet 80. >David Young Any of the 4341/4381/308x/3090 series will work just the same. We use Pronet 10 here, and I understand that there MAY be a minor consideration with Pronet 80 and how the software picks up the card's address (some timing difference between the two systems) which MAY not be handled correctly (or may be done just fine) by the software (I'm just not in a position to know yet). Also, we are a VM shop. I know nothing about MVS (or at least will never admit to knowing anything about it), so beware the VM slant in the following. Lastly, feel free to come back with further questions or give me a call at (607)255-3748. Now, on with the show: We are using the Unibus Pronet10 cards to plug an IBM 7170 "DACU" into the Pronet. The 7170 also plugs into an IBM channel (either on a 370 or XA mode machine). This 7170 has an IBM PC (don't know if it is ordered separately or as a package from IBM) on top of it. The PC runs some code from IBM (called DACU FUNCTIONAL CODE) which makes the 7170 look to the channel like a 3250 (thus you gen it to VM as a 3250 or 2250 graphics device). In addition this functional code calls some 'user exits' which in this case are supplied w/ the host TCP/IP software. These exits will deal w/ the protocol that the host TCP/IP software uses to pass info to the PC on what to send where, etc. It is this software that MAY need to be upgraded for PRONET 80. The 7170 is not currently FE supported, but for now a user supported box. Thus you will need to deal with the details of getting it attached to the channels, etc (unless you have a good relationship with FE). At this point the hardware side is basically dealt with... off to software. We are running the Wiscnet 1.3B package (1.3.1 is now available from U.ofWisc, we just haven't upgraded yet). This software is not installed nor maintained quite like any other normal VM software (if you follow the instructions in the package). For all intents and purposes one can also consider it to be equivalent to the IBM TCP/IP package 5798-DRG. In the case of Wiscnet 1.3.1 you can pick up from a server at UofMaryland ($WNTSRV at UMDD, see Bruce Crabill for more info) some 'common mods' and some service utilities to make the system maintainable using a natural method for VM. We have gone this route and it is in our opinion the best way to go. In addition these common mods address several problem areas in the base code, and thus are things you want on the base anyway (things like subnetting support, etc). Of course, the above host software is only available to Universities, but from your address I assume that is not a problem. When setting up the server machines that Wiscnet runs on be sure to also set the CP Scheduler performance settings (set favor, set qdrop off, set reserved, set priority, etc) needed to give good performance to servers of this sort (similar to what one would do for a guest intruder such as MVS or VTAM, etc under VM). This is critical to performance. You will want to be able to regularly update the public copies of the HOSTS ADDRINFO and HOSTS SITEINFO files which are built from the hosts.nic file you get from sri-nic.arpa (or where ever) to describe all the host names on the network. This may be a problem if they are on the Y-disk (or may not, depending upon your shop's policies). (Yes, there is no Name Server or query'r support in Wiscnet, may be in some future time IBM will release the stuff that UofW did but was not allowed to release.) I'm sure I've missed lots, perhaps the others copied will add to the info and copy the rest of us (hint, hint). Also feel free to ask questions (it will help us prepare for a talk we need to give soon on this very question, so this would help us too). ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041004454700> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Fri 10 Apr 87 14:14:27-PDT Received: from relay2.cs.net by RELAY.CS.NET id af14216; 10 Apr 87 16:57 EDT Received: from ub.com by RELAY.CS.NET id af07786; 10 Apr 87 16:56 AST Date: Fri, 10 Apr 87 12:45:47 PST From: Dave Crocker To: tcp-ip@SRI-NIC.ARPA Subject: Re: Access control and Accountability Organization: Ungermann-Bass, Inc., Santa Clara, CA Newsgroups: mod.protocols.tcp-ip Subject: Re: Access control and accountability Summary: Expires: References: <8704081259.AA17700@topaz.rutgers.edu> Sender: Reply-To: dcrocker@ubvax.UUCP (Dave Crocker) Followup-To: Distribution: world Organization: Ungermann-Bass, Inc., Santa Clara, Ca. Keywords: In article <8704081259.AA17700@topaz.rutgers.edu> hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) writes: >... You will need to insert the access control in >sendmail also. We have done all of this stuff in the past, but are >not doing it now. It is nearly impossible to control mail. There are >now so many gateways, that you can always find some machine on the >local network that will forward your mail to the Arpanet for you. Not >to mention UUCP or Bitnet to Arpanet gateways... The MMDFII mail transport system, used by CSNet and distributed with 4.3BSD, has considerable path-filtering based security. You can prohibit users, networks or hosts from sending to any specified host or network. While this requires a cooperating set of internal MMDF's to enforce filtering pervasively, rather than simply at the boundaries, one would assume that a security mechanism would not be used unless the requirement were fairly severe. Dave P.S. You are correct that statistics gathering features are present in other vendors' IP Routers. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704101728.AA08298%40hera.CS.UCLA.EDU] <1987041007280100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: unni@CS.UCLA.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ROS/REX Message-ID: <8704101728.AA08298@hera.CS.UCLA.EDU> Date: Fri, 10-Apr-87 12:28:01 EST Article-I.D.: hera.8704101728.AA08298 Posted: Fri Apr 10 12:28:01 1987 Date-Received: Sat, 11-Apr-87 17:44:22 EST References: <8704101817.AA19375@spam.istc.sri.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa If you have a m/c readable~r REX, could you send it to me ? Thanx unni ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704101511.a005859%40Huey.UDEL.EDU] <1987041010110700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Little delights Message-ID: <8704101511.a005859@Huey.UDEL.EDU> Date: Fri, 10-Apr-87 15:11:07 EST Article-I.D.: Huey.8704101511.a005859 Posted: Fri Apr 10 15:11:07 1987 Date-Received: Sat, 11-Apr-87 18:22:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa Folks, Thought you might enjoy a couple of creepycrawlers that wandered past our gateways recently. One was a 'gram from 10.10.0.2 to 10.0.0.0, which showed up at dcn-gw (10.2.0.96). The most beguiling explanation is that somebody uncorked a 4.2 Unix on the ARPANET and turned on rwho. I still have to explain why that 'gram showed up here, unless maybe the dude is running 4.3 Unix and is trying to find a boot server. Maybe I should provide a suitable core image? That's even more beguiling. Observed on linkabit-gw (10.0.0.111) yesterday were a number of creatures apparently hatched on net 128.174. Some of these were from one subnet to the all-zeroes address on another subnet, while others were to the net (sic) broadcast address of all ones. While that suggests broken subnets, my intrigue is spiked by curious fact the buggers showed up half way across the country. I know there is a logical explanation for this infestation and will (wearily) pursue it. Meanwhile, it's the chuckles that keep me warm and suggest that we might place an add for an Internet spider to catch them bugs. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704102121.AA24982%40ucbvax.Berkeley.EDU] <1987041010454700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dcrocker@engr.ub.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Access control and Accountability Message-ID: <8704102121.AA24982@ucbvax.Berkeley.EDU> Date: Fri, 10-Apr-87 15:45:47 EST Article-I.D.: ucbvax.8704102121.AA24982 Posted: Fri Apr 10 15:45:47 1987 Date-Received: Sat, 11-Apr-87 18:24:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: Ungermann-Bass, Inc., Santa Clara, CA Lines: 35 Approved: tcp-ip@sri-nic.arpa Newsgroups: mod.protocols.tcp-ip Subject: Re: Access control and accountability Summary: Expires: References: <8704081259.AA17700@topaz.rutgers.edu> Sender: Reply-To: dcrocker@ubvax.UUCP (Dave Crocker) Followup-To: Distribution: world Organization: Ungermann-Bass, Inc., Santa Clara, Ca. Keywords: In article <8704081259.AA17700@topaz.rutgers.edu> hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) writes: >... You will need to insert the access control in >sendmail also. We have done all of this stuff in the past, but are >not doing it now. It is nearly impossible to control mail. There are >now so many gateways, that you can always find some machine on the >local network that will forward your mail to the Arpanet for you. Not >to mention UUCP or Bitnet to Arpanet gateways... The MMDFII mail transport system, used by CSNet and distributed with 4.3BSD, has considerable path-filtering based security. You can prohibit users, networks or hosts from sending to any specified host or network. While this requires a cooperating set of internal MMDF's to enforce filtering pervasively, rather than simply at the boundaries, one would assume that a security mechanism would not be used unless the requirement were fairly severe. Dave P.S. You are correct that statistics gathering features are present in other vendors' IP Routers. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041013280000> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Fri 10 Apr 87 04:51:59-PDT Received: from ucl-cs-pyr1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa06694; 10 Apr 87 10:50 WET To: unni@cs.ucla.edu, cperry@gateway.mitre.org, AFDDN.BEACH@gunter-adam.arpa cc: tcp-ip@sri-nic.arpa Subject: ROS/REX Date: Fri, 10 Apr 87 11:48:00 +0100 From: Jon Crowcroft Several people asked me where to get documents on ROS and/or REX: I'm working on finding an address for email (someone at NPL may have online copies), but the best I can suggest at the moment is to try and find how to get in touch with ECMA (European Computer Manufacturers Association), and ask them direct for their standards documents. One person I know in the US who has talked to these people and ANSA about REX and transaction protocols is Dave Clark at MIT. Jon ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041014001100> Received: from mitre-bedford.ARPA by SRI-NIC.ARPA with TCP; Fri 10 Apr 87 10:27:19-PDT Posted-From: The MITRE Corp., Bedford, MA Received: by linus.research (3.2/4.7) id AA26983; Fri, 10 Apr 87 13:27:58 EDT Posted-Date: 10 Apr 87 14:00:11 GMT Received: by dartmouth.EDU (5.51/2.4D) id AA10273; Fri, 10 Apr 87 10:00:14 EDT To: mod-protocols-tcp-ip%linus@mitre-bedford.ARPA Path: dartvax!richb From: dartvax!richb.UUCP@seismo.css.gov (Richard E. Brown) Newsgroups: mod.protocols.tcp-ip Subject: TCP on an HP 3000 Keywords: TCP HP3000 Message-Id: <5985@dartvax.UUCP> Date: 10 Apr 87 14:00:11 GMT Reply-To: dartvax!richb (Richard E. Brown) Distribution: world Organization: Dartmouth College, Hanover, NH Lines: 13 I wasn't paying much attention a couple of months ago, but I seem to remember that someone said that there was an implementation of TCP on HP3000 computers. Is this true? Please mail responses to me. Thanks. Rich Brown Dartmouth College Kiewit Computation Center Hanover, NH 03755 603/646-3648 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704110452.AA08906%40umn-cs.arpa] <1987041018521200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: haque@umn-cs.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8704110452.AA08906@umn-cs.arpa> Date: Fri, 10-Apr-87 23:52:12 EST Article-I.D.: umn-cs.8704110452.AA08906 Posted: Fri Apr 10 23:52:12 1987 Date-Received: Sun, 12-Apr-87 00:42:53 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 37 Approved: tcp-ip@sri-nic.arpa Path: umn-cs!haque From: haque@umn-cs.UUCP (Samudra E. Haque) Newsgroups: mod.protocols.tcp-ip Subject: Re: TCP on an HP 3000 Keywords: TCP HP3000 HP9000 Message-ID: <1476@umn-cs.UUCP> Date: 11 Apr 87 04:52:09 GMT Article-I.D.: umn-cs.1476 Posted: Fri Apr 10 22:52:09 1987 References: <5985@dartvax.UUCP> Organization: CSci Systems Group,University of Minnesota,Mpls. Lines: 24 In article <5985@dartvax.UUCP>, richb.UUCP@dartvax.UUCP (Richard E. Brown) writes: > > I wasn't paying much attention a couple of months ago, but I seem > to remember that someone said that there was an implementation of > TCP on HP3000 computers. > Speaking of HP's.. We have HP 9000/200 and /300 machines. While the /300 have full networking (psuedo BSD), the /200 machines do not have any networking hardware available for them. (according to our HP rep) We are running HP/UX on them. Am I wrong in assuming that there really is no future for networking the /200 machines or that they might become very expensive to have networking on ? Samudra E. Haque Computer Science Systems Group University of Minnesota Minneapolis, MN 55455 haque@umn-cs.arpa or ..!dayton!umn-cs!haque or (612) 625-0876 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704111009.AA04877%40topaz.rutgers.edu] <1987041100090700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: root@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: XNS to TCP-IP changeover on Bridge Hardware. Message-ID: <8704111009.AA04877@topaz.rutgers.edu> Date: Sat, 11-Apr-87 05:09:07 EST Article-I.D.: topaz.8704111009.AA04877 Posted: Sat Apr 11 05:09:07 1987 Date-Received: Sun, 12-Apr-87 02:08:43 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Actually we have seen significant improvement with the Bridge TCP/IP terminal server software recently. It now seemed to be reasonably reliable, which is a big improvement. I admit however that support of domain servers for name lookup instead of the old IEN116 would be welcome, as well as a few other details from the 4.3 generation. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041101262800> Received: from seismo.CSS.GOV by SRI-NIC.ARPA with TCP; Fri 10 Apr 87 18:25:51-PDT Received: by seismo.CSS.GOV (5.54/1.14) id AA19043; Fri, 10 Apr 87 21:25:54 EDT Received: by cs-gw.D.UMN.EDU (5.51/9.7) id AA08168; Fri, 10 Apr 87 20:26:31 CDT To: mod-protocols-tcp-ip@seismo.CSS.GOV Path: umnd-cs!steve From: steve@cs.d.umn.edu (Steven M. Miller) Newsgroups: mod.protocols.tcp-ip Subject: Re: XNS to TCP-IP changeover on Bridge Hardware. Keywords: Please help... Message-Id: <529@umnd-cs.D.UMN.EDU> Date: 11 Apr 87 01:26:28 GMT References: <531@pdp.cs.OHIOU.EDU> Organization: U. of Minnesota-Duluth, Computer Science Lines: 29 In article <531@pdp.cs.OHIOU.EDU>, shapiro@pdp.cs.ohiou.EDU (brian shapiro) writes: > > We will soon be making the change from Bridge XNS to TCP-IP on our network. > > 1.) How about a general comment on Bridges release of TCP-IP. Doesn't come very close to the quality of their XNS stuff. They are way behind with this software (*supposedly* they are working to bring it up to snuff). If you use your bridges for dial-in uucp then your in trouble. (some people have claimed that there are ways to get around this, namely the 'f' protocol, but I've yet to get it to go) > 3.) I have been told that the current release of TCP-IP will boot remotely > from our central NCS-150 controller. Is this true? Yes. (If only they supported booting from a host...) > 4.) Can anyone out there address the issue of compatibility with other > TCP-IP networks? Even though the tcp software supports a subnet mask, the software is only at the level of 4.2bsd tcp. My personal preference is for Encore's Annex, but since you already went with Bridge... -- Steve Miller, UMD Computer Science, steve@cs-gw.D.UMN.EDU ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704120145.AA09319%40hpltyj] <1987041115455100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tai%hpltyj@HPLABS.HP.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Submission for mod-protocols-tcp-ip Message-ID: <8704120145.AA09319@hpltyj> Date: Sat, 11-Apr-87 20:45:51 EST Article-I.D.: hpltyj.8704120145.AA09319 Posted: Sat Apr 11 20:45:51 1987 Date-Received: Sun, 12-Apr-87 17:41:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa |Speaking of HP's.. | |We have HP 9000/200 and /300 machines. While the /300 have full |networking (psuedo BSD), the /200 machines do not have any networking |hardware available for them. (according to our HP rep) We are running |HP/UX on them. | |Am I wrong in assuming that there really is no future for networking |the /200 machines or that they might become very expensive to have |networking on ? | | Samudra E. Haque The 9000/200 is virtually identical to the 9000/300 series. That is, they can run the same software (kernel is different though) and use the same networking hardware. However, the 200 is no longer supported; the 5.17 release of HP-UX is the last release which works for the 200 series. On the other hand, I've built a 5.17 kernel with the latest networking code (5.3) for use with the 200 series. ..tai ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704121730.AA27335%40ucbvax.Berkeley.EDU] <1987041207230100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Call for Participation Message-ID: <8704121730.AA27335@ucbvax.Berkeley.EDU> Date: Sun, 12-Apr-87 12:23:01 EST Article-I.D.: ucbvax.8704121730.AA27335 Posted: Sun Apr 12 12:23:01 1987 Date-Received: Sun, 12-Apr-87 23:35:34 EST References: <8704092206.AA17161@tsca.istc.sri.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa The ACM SIGCOMM Workshop in Stowe, Vermont this August will have a session or two on TCP/IP issues. The program chair, JJ Garcia-Luna, has asked me to coordinate the submissions on TCP/IP. The format of the workshop encourages presenters to make a point and then be prepared to discuss it from many aspects. So, please let me know if you want to make a presentation. Mail to this mailbox or phone calls to 408-996-2042 wil find me. Thanks, Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704121733.AA10973%40terminus.UMD.EDU] <1987041207334200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dzoey@TERMINUS.UMD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: FTP client program Message-ID: <8704121733.AA10973@terminus.UMD.EDU> Date: Sun, 12-Apr-87 12:33:42 EST Article-I.D.: terminus.8704121733.AA10973 Posted: Sun Apr 12 12:33:42 1987 Date-Received: Sun, 12-Apr-87 23:36:03 EST References: <8704121737.AA26605@trantor.UMD.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa No doubt you will get many replies, but here's the info on how to listen for a data connection. The well know data port for FTP is port 20. You can change this by issuing the PORT command to the host before you issue a STOR or RETR. I forget the exact syntax for the PORT command, but it's in the RFC. example user wants to stor data: client: PORT x server: {200,250} PORT command okay client: listen on x client: STOR foo server: {150,125} Establishing connection {opens a tcp connection to port x} If you want more info, I'll be glad to help. Joe Herman dzoey@umd5.umd.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041207461800> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 12 Apr 87 08:50:45-PDT Date: 12 Apr 1987 11:46:18 EDT Subject: FTP client program From: Dr. James A. Guffey To: tcp-ip@SRI-NIC.ARPA I am trying to implement a program on the Silicon Graphics Workstation to access a remote FTP server. I've been able to establish a control connection and pass commands and receive replies. However, I have been unable to establish a data connection. The RFC says to listen on user port U before issueing a STOR command. My question is what is the value of the default user port U? I have tried 21, 22, and 1043 (my side of the control connection). None of these work. Any help is greatly appreciated. Steve ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041209230100> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sun 12 Apr 87 10:26:34-PDT Date: 12 Apr 1987 13:23:01 EDT Subject: Re: Call for Participation From: Dan Lynch To: J. Joaquin Garcia-Luna cc: tcp-ip@SRI-NIC.ARPA, LYNCH@A.ISI.EDU In-Reply-To: <8704092206.AA17161@tsca.istc.sri.com> The ACM SIGCOMM Workshop in Stowe, Vermont this August will have a session or two on TCP/IP issues. The program chair, JJ Garcia-Luna, has asked me to coordinate the submissions on TCP/IP. The format of the workshop encourages presenters to make a point and then be prepared to discuss it from many aspects. So, please let me know if you want to make a presentation. Mail to this mailbox or phone calls to 408-996-2042 wil find me. Thanks, Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704130629.AA09251%40decwrl.dec.com] <1987041220295100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: daemon@DECWRL.DEC.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8704130629.AA09251@decwrl.dec.com> Date: Mon, 13-Apr-87 01:29:51 EST Article-I.D.: decwrl.8704130629.AA09251 Posted: Mon Apr 13 01:29:51 1987 Date-Received: Tue, 14-Apr-87 00:35:49 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Path: decwrl!tpov02.dec.com!mobbylin From: mobbylin@tpov02.dec.com (Mobby Lin, Taiwan Software Services) Newsgroups: mod.protocols.tcp-ip Subject: What's vendor support TCP-IP Message-ID: <9269@decwrl.DEC.COM> Date: 13 Apr 87 06:29:50 GMT Sender: daemon@decwrl.DEC.COM Organization: Digital Equipment Corporation Lines: 16 hi everyone, I am more interested in TCP/IP. Does someone know what's third party software and its hardware can support the tcp/ip and what's model and how to contact those products can ported into Wang, Tandem, IBM and NEC. Now I am planning to connect VAX to Wang, Tandem, IBM and NEC, based on X25 on layer 1, 2, 3 and layer 4,5 used on tcp/ip. my address at mobbylin%22599.dec.com@decwrl.arpa Software Services, Taiwan Digital Equipment. regards, Mobby Lin ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041223310000> Mail-From: STJOHNS created at 13-Apr-87 06:32:16 Date: 13 Apr 1987 06:31-PDT Sender: STJOHNS@SRI-NIC.ARPA Subject: Draft of Revised AHIP (1822) available From: Mike StJohns To: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]13-Apr-87 06:31:28.STJOHNS> A draft of proposed revisions to the Arpanet Host Interface Protocol (AHIP) is available on the NIC [26.0.0.73] or [10.0.0.51] under the name "PS:AHIP-E.TXT". This is a revision to AHIP as originally specified in BBN report 1822. This document is available for public comment for the next six weeks at which time it will be revised and the final version issued as a standard. Please send your comments to the address listed in the document, NOT to this list, and not to me. This document is being circulated for review because of the possibility of the MILNET exceeding in size the current addressing limitations of 256 packet switches. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704131228.AA11087@ucbvax.Berkeley.EDU] <1987041302170000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Bridghe tcp/telnet Message-ID: <8704131228.AA11087@ucbvax.Berkeley.EDU> Date: Mon, 13-Apr-87 07:17:00 EST Article-I.D.: ucbvax.8704131228.AA11087 Posted: Mon Apr 13 07:17:00 1987 Date-Received: Tue, 14-Apr-87 23:47:13 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 78 >We will soon be making the change from Bridge XNS >to TCP-IP on our network. I am not sure that we >are looking forward to this change (well at least >those who will have to make the change and take >responsiblity for it). Is there anyone on the net >who has made this change? If so I would like to >have some input on the following: > >1.) How about a general comment on Bridges release > of TCP-IP. We are doing this at Northeastern University. So far it seems to work as advertised (sort of, I'll get to this in a minute) > >2.) When making the change over is there a way that > the current network configurations can be copied > over so that we don't have to re-enter all of the > port configs? Not that I know of. This is a pain! > >3.) I have been told that the current release of > TCP-IP will boot remotely from our central NCS-150 > controller. Is this true? I have not made contact > with our Bridge reps yet (seems that this is not > my responsiblity). My books say the same thing but we haven't tried this yet. Ask me in a few weeks if you haven't done it yet. > >4.) Can anyone out there address the issue of > compatibility with other TCP-IP networks? > It seems to work with Sun systems as that is what we're doing right now. Soon I hope to be working Bridge TELNET with MICOM's Board/software for VAX/VMS. MICOM said that would work when I asked them at the TCP conference in March. I'll be beta testing some stuff for MICOM. I'll find out. >I have to try to be honest with you folks on the >net. This is really an attempt to Cover My A.. >when this new software arrives. I hope things will >go smoothly but who can say. I personally feel if >it ain't broke - don't fix it. > Always good to cover your ... Anyway, the one problem I had with the TCP Bridge box was the following. The box of course needs an IP address, xx.yy.zz.tt. To do this the box I've got has ROM code debug software with a system generation option. The catch came when I looked at the debug menu through the command port. There wasn't any generation option listed. We called Bridge and read them the menu. They were a bit concerned that the option wasn't listed but said, "Try ." (I wrote it down someplace. It's either GE or GN) The option wasn't listed but it did run. After that it was obvious what to do. Choice 3 took me through the "give box an address" path and everything worked. Note that this is specific to the TCP software. The XNS system generation won't do it. USnail: Chris Johnson Academic Computer Services Northeastern University 39RI 360 Huntington Ave. Boston, MA. U.S.A. 02115 AT&T: (617) 437-2335 CSNET: johnson@nuhub.acs.northeastern.edu ARPANET: johnson%nuhub.acs.northeastern.edu@relay.cs.net BITNET: johnson%nuhub.acs.northeastern.edu@csnet-relay ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041302170001> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Mon 13 Apr 87 05:11:56-PDT Received: from relay2.cs.net by RELAY.CS.NET id aa20503; 13 Apr 87 8:11 EDT Received: from northeastern.edu by RELAY.CS.NET id aa22970; 13 Apr 87 8:09 AST Date: Mon, 13 Apr 87 07:17 EST From: "I am only an egg." To: tcp-ip@SRI-NIC.ARPA Subject: Bridghe tcp/telnet X-VMS-To: TCP-IP >We will soon be making the change from Bridge XNS >to TCP-IP on our network. I am not sure that we >are looking forward to this change (well at least >those who will have to make the change and take >responsiblity for it). Is there anyone on the net >who has made this change? If so I would like to >have some input on the following: > >1.) How about a general comment on Bridges release > of TCP-IP. We are doing this at Northeastern University. So far it seems to work as advertised (sort of, I'll get to this in a minute) > >2.) When making the change over is there a way that > the current network configurations can be copied > over so that we don't have to re-enter all of the > port configs? Not that I know of. This is a pain! > >3.) I have been told that the current release of > TCP-IP will boot remotely from our central NCS-150 > controller. Is this true? I have not made contact > with our Bridge reps yet (seems that this is not > my responsiblity). My books say the same thing but we haven't tried this yet. Ask me in a few weeks if you haven't done it yet. > >4.) Can anyone out there address the issue of > compatibility with other TCP-IP networks? > It seems to work with Sun systems as that is what we're doing right now. Soon I hope to be working Bridge TELNET with MICOM's Board/software for VAX/VMS. MICOM said that would work when I asked them at the TCP conference in March. I'll be beta testing some stuff for MICOM. I'll find out. >I have to try to be honest with you folks on the >net. This is really an attempt to Cover My A.. >when this new software arrives. I hope things will >go smoothly but who can say. I personally feel if >it ain't broke - don't fix it. > Always good to cover your ... Anyway, the one problem I had with the TCP Bridge box was the following. The box of course needs an IP address, xx.yy.zz.tt. To do this the box I've got has ROM code debug software with a system generation option. The catch came when I looked at the debug menu through the command port. There wasn't any generation option listed. We called Bridge and read them the menu. They were a bit concerned that the option wasn't listed but said, "Try ." (I wrote it down someplace. It's either GE or GN) The option wasn't listed but it did run. After that it was obvious what to do. Choice 3 took me through the "give box an address" path and everything worked. Note that this is specific to the TCP software. The XNS system generation won't do it. USnail: Chris Johnson Academic Computer Services Northeastern University 39RI 360 Huntington Ave. Boston, MA. U.S.A. 02115 AT&T: (617) 437-2335 CSNET: johnson@nuhub.acs.northeastern.edu ARPANET: johnson%nuhub.acs.northeastern.edu@relay.cs.net BITNET: johnson%nuhub.acs.northeastern.edu@csnet-relay ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[SRI-NIC.ARPA]13-Apr-87.06:31:28.STJOHNS] <1987041303310000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: StJohns@SRI-NIC.ARPA (Mike StJohns) Newsgroups: comp.protocols.tcp-ip Subject: Draft of Revised AHIP (1822) available Message-ID: <[SRI-NIC.ARPA]13-Apr-87.06:31:28.STJOHNS> Date: Mon, 13-Apr-87 08:31:00 EST Article-I.D.: <[SRI-NIC.ARPA]13-Apr-87.06:31:28.STJOHNS> Posted: Mon Apr 13 08:31:00 1987 Date-Received: Sun, 19-Apr-87 03:47:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 15 A draft of proposed revisions to the Arpanet Host Interface Protocol (AHIP) is available on the NIC [26.0.0.73] or [10.0.0.51] under the name "PS:AHIP-E.TXT". This is a revision to AHIP as originally specified in BBN report 1822. This document is available for public comment for the next six weeks at which time it will be revised and the final version issued as a standard. Please send your comments to the address listed in the document, NOT to this list, and not to me. This document is being circulated for review because of the possibility of the MILNET exceeding in size the current addressing limitations of 256 packet switches. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870413134830.986995@RADC-MULTICS.ARPA] <1987041303480000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Ata@RADC-MULTICS.ARPA ("John G. Ata") Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP client program Message-ID: <870413134830.986995@RADC-MULTICS.ARPA> Date: Mon, 13-Apr-87 08:48:00 EST Article-I.D.: RADC-MUL.870413134830.986995 Posted: Mon Apr 13 08:48:00 1987 Date-Received: Sat, 18-Apr-87 17:52:59 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 39 Date: 12 April 1987 13:33 edt From: Joe I. Herman Subject: Re: FTP client program . . . The well know data port for FTP is port 20. You can change this by issuing the PORT command to the host before you issue a STOR or RETR. I forget the exact syntax for the PORT command, but it's in the RFC. Port 20 is the well known data port for the FTP Server. It cannot be changed by having the client FTP send the port command to the Server. This only changes the port that the client FTP uses which is usually NOT port 20. The server may change from port 20 by issuing the PORT command to the client. example user wants to stor data: client: PORT x server: {200,250} PORT command okay client: listen on x client: STOR foo server: {150,125} Establishing connection {opens a tcp connection to port x} If you want more info, I'll be glad to help. Joe Herman dzoey@umd5.umd.edu Again, this changes the port that the client listens on, not the server's use of port 20. I didn't get a copy of the original message that started this, but hope that it helps. John G. Ata ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870413144125.240084@RADC-MULTICS.ARPA] <1987041304410000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Ata@RADC-MULTICS.ARPA ("John G. Ata") Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP client program Message-ID: <870413144125.240084@RADC-MULTICS.ARPA> Date: Mon, 13-Apr-87 09:41:00 EST Article-I.D.: RADC-MUL.870413144125.240084 Posted: Mon Apr 13 09:41:00 1987 Date-Received: Sat, 18-Apr-87 18:37:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Actually, my original message had a typo...the server may NOT change the well known port 20 by issuing the PORT command. (The only way I know how to change the server port is by having the client issue the PASV command, but this does more than allow for a port change.) Sorry for the confusion... John G. Ata ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704131601.AA12189@MACOM4.ARPA] <1987041306012800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brady@MACOM4.ARPA (Sean Brady) Newsgroups: comp.protocols.tcp-ip Subject: Packet Tracing Message-ID: <8704131601.AA12189@MACOM4.ARPA> Date: Mon, 13-Apr-87 11:01:28 EST Article-I.D.: MACOM4.8704131601.AA12189 Posted: Mon Apr 13 11:01:28 1987 Date-Received: Sat, 18-Apr-87 18:47:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Greetings all: On several occasions, I have seen messages which included packet traces for packets sent around the internet. I would like to use this to perform some tests here, but I am unable to find specific references on how to do this options setting on my machines. I'm using SUN 3's with Unix 3.2 (I think). Any ideas out there? Sean ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12294269035.46.ROODE@BIONET-20.ARPA] <1987041311565000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROODE%BIONET@SUMEX-AIM.STANFORD.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: commercial network economies vs. ARPANET Message-ID: <12294269035.46.ROODE@BIONET-20.ARPA> Date: Mon, 13-Apr-87 16:56:50 EST Article-I.D.: BIONET-2.12294269035.46.ROODE Posted: Mon Apr 13 16:56:50 1987 Date-Received: Wed, 15-Apr-87 02:31:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Telenet just made a press release where they talked about 2,000 hosts on their network worldwide. The ARPANET/Internet can top that easily--there are 4,000 hosts listed in the NIC host table alone, and only the tip of the iceberg is represented there. In comparing costs of Telenet to ARPANET it would not be realistic to look only at a flat cost per packet without taking into account a reasonable cost for maintaining connectivity to a large number of hosts. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704132312.AA22109@ucbvax.Berkeley.EDU] <1987041313054800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Network Management Meeting Scheduled Message-ID: <8704132312.AA22109@ucbvax.Berkeley.EDU> Date: Mon, 13-Apr-87 18:05:48 EST Article-I.D.: ucbvax.8704132312.AA22109 Posted: Mon Apr 13 18:05:48 1987 Date-Received: Wed, 15-Apr-87 02:32:06 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 133 FORMATION OF A NETWORK MANAGEMENT WORKING GROUP The Internet Activities Board in conjunction with its Internet Engineering Task Force is forming a Network Management Working Group composed of representatives from the Internet community and vendors of TCP/IP products. The group will develop a set of RFCs that define tools to manage systems containing multiple vendor TCP/IP products. The working group is expected to focus on detailing a framework for management of TCP/IP based networks, the control and monitoring information to be managed, and the protocols necessary for the exchange of management information. Near term solutions that can result in vendor implementations will be stressed. The Working Group's first meeting will be held on May 5th, 1987, at TECHMART, the Silicon Valley Marketing Center, in Santa Clara, CA, from 9-4 in Suite 125. Adjacent to the Doubletree Hotel and the Santa Clara Convention Center, TECHMART is at 5201 Great America Parkway. Please contact Dan Lynch, Advanced Computing Environments, 408-996-2042, if you plan to attend so proper arrangements may be made. The meeting will be open to all users and vendors. Lee LaBarre from the Mitre Corporation will chair this meeting. Please contact him at 617-271-8507 if you wish to be included in the following agenda. The agenda for the first meeting will include the following: - Discussion of the scope and schedule of the project. A candidate proposal will be presented. - Presentations on models for network management. Lee LaBarre will present the ISO and IEEE models. - Presentations on TCP/IP parameters to be managed. - Presentations on protocols for management exchanges. A long term work list for the group is as follows: a) Agree on the scope of network management and the areas of management to be addressed. The possible areas include: configuration management fault management performance management security management accounting management The group might reasonably choose to only address the first three areas. b) Determine the management requirements in the chosen areas. c) Determine a framework, or model, for network management. The group should examine models developed by standards organizations such as ANSI and IEEE, and any models being developed for management of the Arpanet or MILNET. If possible, the model should be based on existing work done by the standards bodies. This does not imply that we should track evolving standards, but that we might benefit from their work. It may be desirable to develop a common model to ease the management of networks that contain DoD and ISO protocol suites. Vendors could then use the same network management system to manage products in both suites. d) Determine for each layer of the DoD suite the parameters to be managed, e.g., protocol parameters (timers, max. no. of connections, max. segment size, no. of retransmissions), statistics (counts on segments, octets sent and received, refused connections, retransmissions, discarded datagrams, etc). e) Determine the protocol for exchanging management information. Candidates to be examined from the standards area include ISO's Common Management Information Protocol (CMIP) and the protocol defined by the IEEE for management exchanges. A protocol suitable for encoding management data to be transferred among machines with heterogeneous storage formats is CCITT X.409 (ISO ASN.1). f) Document the above decisions as a set of RFCs. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041315054800> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 13 Apr 87 16:08:30-PDT Date: 13 Apr 1987 19:05:48 EDT Subject: Network Management Meeting Scheduled From: Dan Lynch To: TCP-IP@SRI-NIC.ARPA, netbios@MITRE-BEDFORD.ARPA cc: LYNCH@A.ISI.EDU FORMATION OF A NETWORK MANAGEMENT WORKING GROUP The Internet Activities Board in conjunction with its Internet Engineering Task Force is forming a Network Management Working Group composed of representatives from the Internet community and vendors of TCP/IP products. The group will develop a set of RFCs that define tools to manage systems containing multiple vendor TCP/IP products. The working group is expected to focus on detailing a framework for management of TCP/IP based networks, the control and monitoring information to be managed, and the protocols necessary for the exchange of management information. Near term solutions that can result in vendor implementations will be stressed. The Working Group's first meeting will be held on May 5th, 1987, at TECHMART, the Silicon Valley Marketing Center, in Santa Clara, CA, from 9-4 in Suite 125. Adjacent to the Doubletree Hotel and the Santa Clara Convention Center, TECHMART is at 5201 Great America Parkway. Please contact Dan Lynch, Advanced Computing Environments, 408-996-2042, if you plan to attend so proper arrangements may be made. The meeting will be open to all users and vendors. Lee LaBarre from the Mitre Corporation will chair this meeting. Please contact him at 617-271-8507 if you wish to be included in the following agenda. The agenda for the first meeting will include the following: - Discussion of the scope and schedule of the project. A candidate proposal will be presented. - Presentations on models for network management. Lee LaBarre will present the ISO and IEEE models. - Presentations on TCP/IP parameters to be managed. - Presentations on protocols for management exchanges. A long term work list for the group is as follows: a) Agree on the scope of network management and the areas of management to be addressed. The possible areas include: configuration management fault management performance management security management accounting management The group might reasonably choose to only address the first three areas. b) Determine the management requirements in the chosen areas. c) Determine a framework, or model, for network management. The group should examine models developed by standards organizations such as ANSI and IEEE, and any models being developed for management of the Arpanet or MILNET. If possible, the model should be based on existing work done by the standards bodies. This does not imply that we should track evolving standards, but that we might benefit from their work. It may be desirable to develop a common model to ease the management of networks that contain DoD and ISO protocol suites. Vendors could then use the same network management system to manage products in both suites. d) Determine for each layer of the DoD suite the parameters to be managed, e.g., protocol parameters (timers, max. no. of connections, max. segment size, no. of retransmissions), statistics (counts on segments, octets sent and received, refused connections, retransmissions, discarded datagrams, etc). e) Determine the protocol for exchanging management information. Candidates to be examined from the standards area include ISO's Common Management Information Protocol (CMIP) and the protocol defined by the IEEE for management exchanges. A protocol suitable for encoding management data to be transferred among machines with heterogeneous storage formats is CCITT X.409 (ISO ASN.1). f) Document the above decisions as a set of RFCs. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041323310900> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Mon 13 Apr 87 22:26:43-PDT Received: by ucbvax.Berkeley.EDU (5.57/1.23) id AA28891; Mon, 13 Apr 87 21:22:20 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Apr 87 23:31:09 GMT From: nbires!opus!chm@ucbvax.Berkeley.EDU (Paul Chmielewski) Organization: NBI Inc., Boulder, CO. Subject: 4.3 TCP keep-alive question Message-Id: <751@opus.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa The 4.2 TCP keep-alive implementation is described two different ways. According to the comment in tcp_timer.h, when the TCPT_KEEP timer expires we should send the following segment to elicit a response from our peer: But, the actual implementation in our version of tcp_timer.c sends: Note that the first segment contains an invalid SEQ and the second contains both an invalid SEQ and an invalid ACK. My question is, do we really need to lie about what we've received by sending an invalid ACK or is the invalid SEQ enough to elicit a response? -- Paul Chmielewski NBI Inc., Boulder, CO chm@nbires.UUCP or chm@nbires.NBI.COM (303) 444-5710 -- Paul Chmielewski NBI Inc., Boulder, CO chm@nbires.UUCP or chm@nbires.NBI.COM (303) 444-5710 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [545408231.0.PERRY@VAX.DARPA.MIL] <1987041403171100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PERRY@VAX.DARPA.MIL (Dennis G. Perry) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP on an HP 3000 Message-ID: <545408231.0.PERRY@VAX.DARPA.MIL> Date: Tue, 14-Apr-87 08:17:11 EST Article-I.D.: VAX.545408231.0.PERRY Posted: Tue Apr 14 08:17:11 1987 Date-Received: Sat, 18-Apr-87 23:46:38 EST References: <5985@dartvax.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Yes, it is true. DARPA paid BBN for an implementation of TCP/ip on the HP3000. dennis ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704141539.AA18389@monk.proteon.com] <1987041405390400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@MONK.PROTEON.COM (John A. Shriver) Newsgroups: comp.protocols.tcp-ip Subject: Packet Tracing Message-ID: <8704141539.AA18389@monk.proteon.com> Date: Tue, 14-Apr-87 10:39:04 EST Article-I.D.: monk.8704141539.AA18389 Posted: Tue Apr 14 10:39:04 1987 Date-Received: Sun, 19-Apr-87 00:14:25 EST References: <8704131601.AA12189@MACOM4.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 25 In the 4.2BSD/4.3BSD world, the program is /etc/trpt, which stands for TRansliterate Protocol Trace. It's documented in section 8 of the UNIX manuals. By setting SO_DEBUG with a setsockopt() call, you can cause TCP protocol traces to be accumulated in the kernel. This is done by routine tcp_debug() in the file ~sys/netinet/tcp_debug.c. It keeps the data in a compacted format in a circular buffer, that /etc/trpt reads out and formats. Unfortunately, at least in SunOS Version 3.0, Sun has removed the actual code for tcp_debug() in the kernel. It only contains a return. Of course, they still provide /etc/trpt, but it cusses that it can't find the symbol for the buffer in the kernel. I can't understand WHY they did this, but they did. I have in the past been able to get Sun software support to send me a binary tcp_debug.o that has not been lobotomized. Alternatively you probably would have no problem dropping the 4.2BSD code into the hole, you might also have to fix the header file. Other 4.2BSD vendors are more reasonable. The code is all there in Ultrix-32 Version 1.2. The other frustrating problem is that some of the TCP applications have no way to request them to set the debug option. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704141622.AA18651@monk.proteon.com] <1987041406221400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@MONK.PROTEON.COM (John A. Shriver) Newsgroups: comp.protocols.tcp-ip Subject: Re: tcp/ip/IBM/ProNET Message-ID: <8704141622.AA18651@monk.proteon.com> Date: Tue, 14-Apr-87 11:22:14 EST Article-I.D.: monk.8704141622.AA18651 Posted: Tue Apr 14 11:22:14 1987 Date-Received: Sun, 19-Apr-87 00:10:06 EST References: <8704101943.AA16325@monk.proteon.com> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 52 I'll have to repeat the standard incantation about LAN's and network software (at the present state of the commercial art): The software is always slower than the LAN. (Actually, there are some LANs you can buy where this might not be the case, like Appletalk, but any LAN over 4 megabits/second this will be the case.) First of all, the DACU is not, per se, slow. It is truly possible to shove lots of data through it, IBM has really measured speeds well in excess of one Mbyte/sec. (See "Testing the DACU as a Channel Attached PC", IBM form G320-3472.) What is slow is the time/transaction, not the actual transfer rate. Thus, while one can measure 96 Kbytes/sec for 4 Kbyte buffers, this falls to 19 Kbytes/sec for 512 byte bufers. WISCNET and IBM's code are somewhat limited by using small buffers, however they do perform tricks to aggregate multiple packets into one channel transaction and cut overhead. By doing this, one sees typical performance in the 30 Kbytes/second range for FTP. I will soundly agree that the ACC box is somewhat faster at the hardware level than the DACU. A 68000 running compiled code can parse Channel Command Words faster than a PC running interpreted code. Both the DACU and the ACC use the DC-interlock channel protocol. However (no insult to ACC), the ACC TCP/IP will not run at 10 Mbits/sec (1.25 Mbytes/sec) at the TCP or FTP level. One customer I spoke with was getting about 30 Kbytes/sec, about the same as WISCNET. Obviously, both benchmarks are very rough numbers, and one could wage benchmark wars to prove who is better. However, they will always be within an order of magnitude of each other, probably a power of two of each other. My suspicion is that nodoby has broken (or threatened) the 100 Kbytes/sec barrier for TCP/IP on VM or MVS. By the way, that's not shabby, ACF/VTAM is fairly slow stoking 3270's, channel attach clusters aren't much faster than ones off a 56 kbaud line. Basically, if you want to run VM, I'd say go for the DACU/Wiscnet/ProNET solution. If you want to run MVS, choose from the many capable Ethernet vendors and use our router. (If anyone thinks I'm commercially biased towards the DACU, I make more money on a router than on one ProNET-80 board. I just like clean solutions.) BTW, there's been a lot of discussion about things like this on the IBM-NETS mailing list (requests to ibm-nets-request@devvax.tn.cornell.edu on Internet or ibm-nets-request@bitnic on bitnet.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12294476278.21.STAHL@SRI-NIC.ARPA] <1987041406551500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: STAHL@SRI-NIC.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: request for network number assignment Message-ID: <12294476278.21.STAHL@SRI-NIC.ARPA> Date: Tue, 14-Apr-87 11:55:15 EST Article-I.D.: SRI-NIC.12294476278.21.STAHL Posted: Tue Apr 14 11:55:15 1987 Date-Received: Wed, 15-Apr-87 06:12:59 EST References: <8704141601.AA11445@cgcha.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 The NIC Hostmaster is the person who assigns network numbers. I have forwarded your message to the mailbox HOSTMASTER@SRI-NIC.ARPA. - Mary Stahl / NIC ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704141601.AA11445@cgcha.uucp] <1987041406580000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: whna@cgcha.UUCP.UUCP Newsgroups: comp.protocols.tcp-ip Subject: request for network number assignment Message-ID: <8704141601.AA11445@cgcha.uucp> Date: Tue, 14-Apr-87 11:58:00 EST Article-I.D.: cgcha.8704141601.AA11445 Posted: Tue Apr 14 11:58:00 1987 Date-Received: Wed, 15-Apr-87 06:05:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 15 Dear Sirs, we have installed a network of different UNIX systems that are attached to an Ethernet LAN. Today, the network consists of less than 10 hosts, some diskless workstations and PC's with TCP/IP support. The network will grow soon and we are planning to divide it into subnetworks using the internetwork routing facilities existing at our systems. To be ready for a connection to ARPAnet at a later time, I would like to get a class B network number assigned. In addition, please let me know what the conditions are for us as a commercial institution in the scientific area to get attached to ARPAnet. What is the nearest ARPAnet node for us, and which protocol is used to attach our main mail system to it (is it DDN 1822 HDH or X.25 standard or basic protocol)? Thanks for your information and probable activities arising at your side. Best regards, Heinz Naef (whna@cgcha.UUCP) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704141658.AA01378@gateway.mitre.org] <1987041406582900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@GATEWAY.MITRE.ORG.UUCP Newsgroups: comp.protocols.tcp-ip Subject: ICMP in ISO Message-ID: <8704141658.AA01378@gateway.mitre.org> Date: Tue, 14-Apr-87 11:58:29 EST Article-I.D.: gateway.8704141658.AA01378 Posted: Tue Apr 14 11:58:29 1987 Date-Received: Wed, 15-Apr-87 06:06:05 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 69 From John Shriver: > Another important aspect of ICMP echo reply is that it is Mandatory in > the TCP/IP suite (see the latest Official ARPA Internet Protocols, > where IP and ICMP are the only Mandatory protocols). Using > transport-level protocols in ISO for the same function will not be > nearly as effective, for example a router (IS in ISO parlance) > nominally has no use for transport protocols. I would recommend to > ISO designers to add a mandatory echo response at as low a level as > possible in the architecture. If the source routing trick does this, > and is a mandatory capability of ISO 8473, great. I would then ask > the implementers to provide the necessary user program. No, partial source routing is NOT mandatory in ISO 8473. I admit, I knew this when I suggested it, but I did it anyway. However, from the responses I have seen on this issue, a lot of people think ICMP ECHO is important. We in X3S3.3 would like to be obliging, but are a little uneasy of putting in an all purpose ping without understanding how it will be used. A lot of people may be using ECHO for things when some other function may do more for that thing. Since we are just now defining management functions for the network and transport layers, we are in a good position to provide a lot more than just pings. I would like to get some feedback from all those dirty-fingernailed pingers out there. What EXACTLY do you use ICMP ECHO for? Is there a better way to do what you want other than ICMP ECHO, but you are using ICMP ECHO because it is the only thing available? Are there things (management-wise) that you wish you could do, but there is currently nothing standardized to do it with. Of course, any other random comments are welcome. > (But enough, this discussion really belongs on the ISO mailing > list, see the CC: address...) Yes and no. While tcp-ip is obviously not going to go away, there is no question (at least in my mind) that tp4-ip is on the way. If we (the ISO designers) don't get feedback from you (the experienced tcp-ip designers) on these issues, then the ISO mailing list will be nothing but a repeat of the tcp-ip mailing list, but delayed 5 or 10 years. I think a lot of things belong on both lists. While on the ICMP topic, I'd like to bring up another tidbit...... In addition to an error message which is just like SOURCE QUENCH, there is a thing in ISO-IP called the congestion experienced bit. It is a bandwidth free way of indicating to transport machines that your congestion is getting up there, but not to the point where packets are being thrown away. This is how DEC does it, and it seems to work for them. Now the catches. One, its optional. However, optional doesn't have to mean don't do it. It is groups like COS (Corporation for Open Systems), the NBS-ISO Workshop, and GOSIP (or whoever is behind it) that ultimately decide these things. Two, what a transport does when it receives such a bit is not standardized (just like SOURCE QUENCH), nor is it standardized when the bit gets set. Again, COS, NBS, etc., are the places to fight those battles. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704141911.AA11934@ucbvax.Berkeley.EDU] <1987041408440600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: Tcp/Ip vs a store & forward network Message-ID: <8704141911.AA11934@ucbvax.Berkeley.EDU> Date: Tue, 14-Apr-87 13:44:06 EST Article-I.D.: ucbvax.8704141911.AA11934 Posted: Tue Apr 14 13:44:06 1987 Date-Received: Sun, 19-Apr-87 04:16:04 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 34 Just got around to reading the Subj: msg and hope it's not too late to point out that the desired effect (of passwordless "spoolers" via FTP) can be achieved straightforwardly given the mechanisms of a couple of my old (one ancient, actually) RFCs. Since it would take longer for me to find the numbers than to summarize, here goes: Back in ~'73, when mail was done via FTP, we had a problem with not having all Hosts able/willing to let given users in without passwords (indeed, some Hosts didn't even demand USER commands, muchless PASSs, but others demanded both). In a little thing called "What Is 'Free'?" (RFC # in the 500s, I expect), I suggested that any mail senders which encountered the Login Expected FTP code should use USER NETML and PASS NETML (and any mail receivers on systems that demanded logins should duly cause the appropriate accounts to be created). Seems to me we could do the same thing with "NETSPL" for the passwordless aspect of the current thing. Then a year or two ago (and this one actually is in the latest version of the FTP RFC), for some obscure reason I decided there ought to be an FTP command for STOring under a Unique name for use in all sorts of "pool" directory cases, so if I remembered that one's number and the other one's I could have just said Why not use the RFC 5xx and 9xx tricks? (By the way, the 5xx trick was duly implemented and worked for years [even if nobody other than Multics did the receiving end part].) If my current state of seemingly eternal jetlag hasn't caused me to miss the point, I think that should do it. Do I need to write another RFC to forget the number of? cheers, map P.S. Lest anybody misunderstand, I was at Multics at the time and invented the fictious mail receiver thing in self defense; cf. pp. 84-5 of The Book. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704141923.AA12171@ucbvax.Berkeley.EDU] <1987041408482000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: blumenth@UCBVAX.BERKELEY.EDU (Steve Blumenthal) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP on an HP 3000 Message-ID: <8704141923.AA12171@ucbvax.Berkeley.EDU> Date: Tue, 14-Apr-87 13:48:20 EST Article-I.D.: ucbvax.8704141923.AA12171 Posted: Tue Apr 14 13:48:20 1987 Date-Received: Sun, 19-Apr-87 04:16:49 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 46 BBN had a contract from DARPA to develop TCP/IP for the HP3000. Under that effort we also developed user and server TELNET and user FTP. This software required modifications to the HP3000 operating system and ran on an HP3000 Series 3 under MPE IV. We completed this effort in 1983 and delivered the software to White Sands Missle Range, where it was modified to run on an HP3000 Series 44 system under the MPE V/P operating system. (See attached note from Ken Terry at WSMR from 1985) Because we needed access to the HP3000 operating system sources, we had to sign a non-disclosure agreement with HP. This agreement restricts our ability to redistribute this software except to U.S. government sites as directed by DARPA. Because BBN is not heavily into the development of HP3000 software, we tried to give our software to HP to have them support it and track subsequent HP3000 operating system and hardware improvements. To date, HP has not taken us up on our offer. They may be in the process of developing TCP/IP for the HP3000 themselves, but at this point, we have no current contacts at HP. Steve Blumenthal BBN Labs --------------------------------------------------------------------------- Received: from miser.arpa by BBN-VAX.ARPA id a001802; 5 Sep 85 9:38 EDT Received: by miser.ARPA (4.12/4.7) id AA03774; Thu, 5 Sep 85 07:38:24 mdt Date: Thu, 5 Sep 85 07:38:24 mdt From: Kenneth Terry Message-Id: <8509051338.AA03774@miser.ARPA> To: Winston B. Edmond Subject: conversion of software. Thought I would let you know the status of the conversion effort from MPE V/P to MPE V/E. I currently have TCP/IP, user TELNET, and user FTP running but still have significant work to do on the Pseudo-drivers for server telnet. I have received some help from HP in terms of changes they have made in the operating system (i.e. new intrinsics) but they haven't really gone out of their way to be too helpful. Thanks much for all the help you gave me. You without a doubt saved me many months worth of searching and scratching. Ken. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041408482001> Received: from VAX.BBN.COM by SRI-NIC.ARPA with TCP; Tue 14 Apr 87 11:56:00-PDT Date: Tue, 14 Apr 87 13:48:20 EST From: Steve Blumenthal To: "Dennis G. Perry" cc: tcp-ip@sri-nic.ARPA Subject: Re: TCP on an HP 3000 BBN had a contract from DARPA to develop TCP/IP for the HP3000. Under that effort we also developed user and server TELNET and user FTP. This software required modifications to the HP3000 operating system and ran on an HP3000 Series 3 under MPE IV. We completed this effort in 1983 and delivered the software to White Sands Missle Range, where it was modified to run on an HP3000 Series 44 system under the MPE V/P operating system. (See attached note from Ken Terry at WSMR from 1985) Because we needed access to the HP3000 operating system sources, we had to sign a non-disclosure agreement with HP. This agreement restricts our ability to redistribute this software except to U.S. government sites as directed by DARPA. Because BBN is not heavily into the development of HP3000 software, we tried to give our software to HP to have them support it and track subsequent HP3000 operating system and hardware improvements. To date, HP has not taken us up on our offer. They may be in the process of developing TCP/IP for the HP3000 themselves, but at this point, we have no current contacts at HP. Steve Blumenthal BBN Labs --------------------------------------------------------------------------- Received: from miser.arpa by BBN-VAX.ARPA id a001802; 5 Sep 85 9:38 EDT Received: by miser.ARPA (4.12/4.7) id AA03774; Thu, 5 Sep 85 07:38:24 mdt Date: Thu, 5 Sep 85 07:38:24 mdt From: Kenneth Terry Message-Id: <8509051338.AA03774@miser.ARPA> To: Winston B. Edmond Subject: conversion of software. Thought I would let you know the status of the conversion effort from MPE V/P to MPE V/E. I currently have TCP/IP, user TELNET, and user FTP running but still have significant work to do on the Pseudo-drivers for server telnet. I have received some help from HP in terms of changes they have made in the operating system (i.e. new intrinsics) but they haven't really gone out of their way to be too helpful. Thanks much for all the help you gave me. You without a doubt saved me many months worth of searching and scratching. Ken. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]14-Apr-87.16:36:04.CERF] <1987041410360000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP on an HP 3000 Message-ID: <[A.ISI.EDU]14-Apr-87.16:36:04.CERF> Date: Tue, 14-Apr-87 15:36:00 EST Article-I.D.: <[A.ISI.EDU]14-Apr-87.16:36:04.CERF> Posted: Tue Apr 14 15:36:00 1987 Date-Received: Fri, 17-Apr-87 05:05:27 EST References: <545408231.0.PERRY@VAX.DARPA.MIL> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Dennis, BBN did a TCP to assure that the DARPA HP3000 MIS system could work after the TCP/IP shift of 1983. My recollection of the work is that BBN did the implementation and struggled somewhat to obtain the technical information it needed about the operating system MPE-X (I forget which version). In the meantime, HP has apparently developed a TCP for a number of machines in its product line. Whether it has one commercially for the MPE operating system isn't clear. They have imported the Berkeley 4.2 (or 3) BSD code, I believe, to operate on the Spectrum series machines and possibly for others in its product line. A possible point of contact on protocols is Wim Rollandts who has a senior position at HP dealing with communications. Until recently he ran their International Networks Division (IND - I think I have the initials right even if I have messed up the name). IND is located at HP's corporate facility in Cupertino. The current Information Networks Division general manager is Dan Warmenhoben who can be reached at (408) 447-3506. I tried calling him just a few moments ago but both lines to his office were busy, so I don't know what the status of HP's TCP is at the moment. Hope this helps. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]14-Apr-87.16:40:41.CERF] <1987041410400000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: 4.3 TCP keep-alive question Message-ID: <[A.ISI.EDU]14-Apr-87.16:40:41.CERF> Date: Tue, 14-Apr-87 15:40:00 EST Article-I.D.: <[A.ISI.EDU]14-Apr-87.16:40:41.CERF> Posted: Tue Apr 14 15:40:00 1987 Date-Received: Fri, 17-Apr-87 05:05:40 EST References: <751@opus.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Paul, In the absence of a no-op, something which sends no data but is guaranteed to elicit a response is the option chosen. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041410440600> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 14 Apr 87 11:46:49-PDT Date: 14 Apr 1987 14:44:06 EDT Subject: Re: Tcp/Ip vs a store & forward network From: Michael Padlipsky To: Henry Nussbacher cc: Barry Shein , tcp-ip@SRI-NIC.ARPA In-Reply-To: (Message from "Henry Nussbacher " of Mon, 30 Mar 87 14:32:28 O) Just got around to reading the Subj: msg and hope it's not too late to point out that the desired effect (of passwordless "spoolers" via FTP) can be achieved straightforwardly given the mechanisms of a couple of my old (one ancient, actually) RFCs. Since it would take longer for me to find the numbers than to summarize, here goes: Back in ~'73, when mail was done via FTP, we had a problem with not having all Hosts able/willing to let given users in without passwords (indeed, some Hosts didn't even demand USER commands, muchless PASSs, but others demanded both). In a little thing called "What Is 'Free'?" (RFC # in the 500s, I expect), I suggested that any mail senders which encountered the Login Expected FTP code should use USER NETML and PASS NETML (and any mail receivers on systems that demanded logins should duly cause the appropriate accounts to be created). Seems to me we could do the same thing with "NETSPL" for the passwordless aspect of the current thing. Then a year or two ago (and this one actually is in the latest version of the FTP RFC), for some obscure reason I decided there ought to be an FTP command for STOring under a Unique name for use in all sorts of "pool" directory cases, so if I remembered that one's number and the other one's I could have just said Why not use the RFC 5xx and 9xx tricks? (By the way, the 5xx trick was duly implemented and worked for years [even if nobody other than Multics did the receiving end part].) If my current state of seemingly eternal jetlag hasn't caused me to miss the point, I think that should do it. Do I need to write another RFC to forget the number of? cheers, map P.S. Lest anybody misunderstand, I was at Multics at the time and invented the fictious mail receiver thing in self defense; cf. pp. 84-5 of The Book. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]14-Apr-87.16:54:21.CERF] <1987041410540000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: commercial network economies vs. ARPANET Message-ID: <[A.ISI.EDU]14-Apr-87.16:54:21.CERF> Date: Tue, 14-Apr-87 15:54:00 EST Article-I.D.: <[A.ISI.EDU]14-Apr-87.16:54:21.CERF> Posted: Tue Apr 14 15:54:00 1987 Date-Received: Fri, 17-Apr-87 05:05:52 EST References: <12294269035.46.ROODE@BIONET-20.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 David, I would add to your comments on economics that Telenet is a commercial supplier so its charging policies should be configured to supply a profit. Telenet also has to pay the overhead of sales/marketing/billing/collection which the ARPANET laregly avoids (not entirely, as the DDN folks have to handle tracking of costs for circuits and allocating charges to the funding organizations - but this is on a more coarse scale than the Telenet accounting). Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041412360000> Received: from mitre-bedford.ARPA by SRI-NIC.ARPA with TCP; Tue 14 Apr 87 13:37:21-PDT Posted-From: The MITRE Corp., Bedford, MA Received: from mitre-bedford.ARPA (mbunix) by linus.research (3.2/4.7) id AA12176; Tue, 14 Apr 87 16:38:11 EDT Posted-Date: 14 Apr 1987 16:36-EDT Date: 14 Apr 1987 16:36-EDT Sender: CERF@A.ISI.EDU Subject: Re: TCP on an HP 3000 From: CERF@A.ISI.EDU To: PERRY@VAX.DARPA.MIL Cc: dartvax!richb@VAX.DARPA.MIL Cc: mod-protocols-tcp-ip%linus@mitre-bedford.ARPA Message-Id: <[A.ISI.EDU]14-Apr-87 16:36:04.CERF> In-Reply-To: <545408231.0.PERRY@VAX.DARPA.MIL> Dennis, BBN did a TCP to assure that the DARPA HP3000 MIS system could work after the TCP/IP shift of 1983. My recollection of the work is that BBN did the implementation and struggled somewhat to obtain the technical information it needed about the operating system MPE-X (I forget which version). In the meantime, HP has apparently developed a TCP for a number of machines in its product line. Whether it has one commercially for the MPE operating system isn't clear. They have imported the Berkeley 4.2 (or 3) BSD code, I believe, to operate on the Spectrum series machines and possibly for others in its product line. A possible point of contact on protocols is Wim Rollandts who has a senior position at HP dealing with communications. Until recently he ran their International Networks Division (IND - I think I have the initials right even if I have messed up the name). IND is located at HP's corporate facility in Cupertino. The current Information Networks Division general manager is Dan Warmenhoben who can be reached at (408) 447-3506. I tried calling him just a few moments ago but both lines to his office were busy, so I don't know what the status of HP's TCP is at the moment. Hope this helps. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041412400000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 14 Apr 87 13:41:50-PDT Date: 14 Apr 1987 16:40-EDT Sender: CERF@A.ISI.EDU Subject: Re: 4.3 TCP keep-alive question From: CERF@A.ISI.EDU To: nbires!opus!chm@UCBVAX.BERKELEY.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]14-Apr-87 16:40:41.CERF> In-Reply-To: <751@opus.UUCP> Paul, In the absence of a no-op, something which sends no data but is guaranteed to elicit a response is the option chosen. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041412540000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 14 Apr 87 13:54:51-PDT Date: 14 Apr 1987 16:54-EDT Sender: CERF@A.ISI.EDU Subject: Re: commercial network economies vs. ARPANET From: CERF@A.ISI.EDU To: ROODE%BIONET@SUMEX-AIM.STANFORD.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]14-Apr-87 16:54:21.CERF> In-Reply-To: <12294269035.46.ROODE@BIONET-20.ARPA> David, I would add to your comments on economics that Telenet is a commercial supplier so its charging policies should be configured to supply a profit. Telenet also has to pay the overhead of sales/marketing/billing/collection which the ARPANET laregly avoids (not entirely, as the DDN folks have to handle tracking of costs for circuits and allocating charges to the funding organizations - but this is on a more coarse scale than the Telenet accounting). Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704150848.AA24146@PARIS.MIT.EDU] <1987041422484700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: martillo@ATHENA.MIT.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: TCP on an HP 3000 Message-ID: <8704150848.AA24146@PARIS.MIT.EDU> Date: Wed, 15-Apr-87 03:48:47 EST Article-I.D.: PARIS.8704150848.AA24146 Posted: Wed Apr 15 03:48:47 1987 Date-Received: Sat, 18-Apr-87 00:25:29 EST References: <[A.ISI.EDU]14-Apr-87.16:36:04.CERF> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 If you want information about TCP on an HP 3000, you might try writing to sax%enr.prime.com@eddie.mit.edu. I think he worked on this project. Yaqim Martillo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704151318.AA06851@vax.darpa.mil] <1987041503184700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MAILER-DAEMON@VAX.DARPA.MIL.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Returned mail: Host unknown Message-ID: <8704151318.AA06851@vax.darpa.mil> Date: Wed, 15-Apr-87 08:18:47 EST Article-I.D.: vax.8704151318.AA06851 Posted: Wed Apr 15 08:18:47 1987 Date-Received: Fri, 17-Apr-87 00:45:53 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 56 ----- Transcript of session follows ----- 550 tcp-ip@rsi-nic... Host unknown ----- Unsent message follows ----- Posted-Date: Wed 15 Apr 87 09:18:44-EDT Received-Date: Wed, 15 Apr 87 09:18:47 EDT Received: by vax.darpa.mil (5.54/5.51) id AA06849; Wed, 15 Apr 87 09:18:47 EDT Date: Wed 15 Apr 87 09:18:44-EDT From: Dennis G. Perry Subject: [Harry Forsdick : Re: Multimedia Mail.] To: tcp-ip@rsi-nic Cc: perry@VAX.DARPA.MIL Message-Id: <545494724.0.PERRY@VAX.DARPA.MIL> In-Reply-To: <8704142347.AA05768@perry Mail-System-Version: I have had several similar questions to the ones answered by Harry below. I did not ask Harry if I could send his note to a wider audience, so don't take anything Harry says as an indorsement of anything. Just information!!! dennis --------------- Posted-Date: Tue, 14 Apr 87 20:08:19 AST Received-Date: Tue, 14 Apr 87 20:09:51 EDT Received: from SILICA.BBN.COM by vax.darpa.mil (5.54/5.51) id AA05811; Tue, 14 Apr 87 20:09:51 EDT Received: by Diamond.BBN.COM; Tue, 14 Apr 87 20:08:19 AST Date: Tue, 14 Apr 87 20:08:19 AST From: Harry Forsdick Message-Id: <8704150008.AA05200@Diamond.BBN.COM> To: estrin@usc-oberon.arpa Subject: Re: Multimedia Mail. Cc: Perry@vax.darpa.mil, nsfnet@sh.cs.net Debbie, Diamond currently runs only on SUN workstations. As part of the EXPRES project we are porting Diamond to PC/RT's, DEC MicroVax GPX and Apollo DN 3000's. This will run under the X window system. BBN is doing the MicroVax port and U of M is doing the PC/RT and Apollo DN3000 port. All of the ports are dependent on the appearance of X.11 which is due mid-Summer. So, my advice is, get a SUN for the short term. Diamond will run on an RT in the long-term. Regards, Harry ------- ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1987.4.15.15.15.10.Rudy.Nedved@h.cs.cmu.edu] <1987041505443600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Rudy.Nedved@H.CS.CMU.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP in ISO Message-ID: <1987.4.15.15.15.10.Rudy.Nedved@h.cs.cmu.edu> Date: Wed, 15-Apr-87 10:44:36 EST Article-I.D.: h.1987.4.15.15.15.10.Rudy.Nedved Posted: Wed Apr 15 10:44:36 1987 Date-Received: Fri, 17-Apr-87 02:12:03 EST References: <8704141658.AA01378@gateway.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 46 As someone said recently for why you want ICMP ECHO required is for debugging. The application is to determine connectivity which you can not associate with gateway mechanisms since routing updates are broken half the time. You really need a simple way of to see if some node in the network tree is there. You test node A, you test node B and then test node C and then try X. This is usually neccessary if you are trying to answer the question, "Why can't I talk to X?". The other things that PINGing is good for is testing for drop tests, different packet sizes and random data failures. There are a variety of failure modes related to interfaces, translating a packet from one network to another, congestion versus media, packet sizes and a host of other conditions. Basic horror stories include the following: SDLC interface that paused a bit longer between bits after 256bytes, the interface was correct but the old piece of garbage hardware on the receiving side was slightly off...It would randomly pick a bit value for that bit. Pings using different packet sizes and data showed this. Oscillation failures between gateways. The gateways would believe a network was done when it is was up and vice versa. Pings helped detect this incorrect knowledge in the gateways. ARP mechanism is busted. A PING on one host said a host was up but on the busted host said it was down. Connections dropping during end of day. PINGs showed that occasionally for a minute or so, all packets were lost. Turned out interface under high load would occasionally shut itself off....probably related to input buffer ring size. In many cases, the thing that saved us was the fact that ICMP ECHO was required. We could point at an implementation and say you are not playing by the game rules and would treat them very badly...It never happened but the ability is there. I believe in the Ethernet configuration testing protocol. I look at ICMP ECHO with source routing as being a mid-level network testing mechanism. Losing this ability would hamper our ability to quickly track down problems. If ISO has a better mechanism then simple ECHOs and ECHOs with source routes, I would love to hear about it on this list since I am certainly eager to learn better and faster ways to isolate network failures. -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704152107.AA10646@ucbvax.Berkeley.EDU] <1987041507050000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: sun manuals Message-ID: <8704152107.AA10646@ucbvax.Berkeley.EDU> Date: Wed, 15-Apr-87 12:05:00 EST Article-I.D.: ucbvax.8704152107.AA10646 Posted: Wed Apr 15 12:05:00 1987 Date-Received: Fri, 17-Apr-87 03:39:37 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 15 I have a Sun 3/180. We're just starting to use it. The manuals are as yet incomprehensible to me. Anyone know where to look for calls to the tcp/ip/telnet functionality? USnail: Chris Johnson Academic Computer Services Northeastern University 39RI 360 Huntington Ave. Boston, MA. U.S.A. 02115 AT&T: (617) 437-2335 CSNET: johnson@nuhub.acs.northeastern.edu ARPANET: johnson%nuhub.acs.northeastern.edu@relay.cs.net BITNET: johnson%nuhub.acs.northeastern.edu@csnet-relay ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041507050001> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Wed 15 Apr 87 13:55:48-PDT Received: from relay2.cs.net by RELAY.CS.NET id ae08700; 15 Apr 87 16:33 EDT Received: from northeastern.edu by RELAY.CS.NET id ak09266; 15 Apr 87 16:29 AST Date: Wed, 15 Apr 87 12:05 EST From: "I am only an egg." To: tcp-ip@SRI-NIC.ARPA Subject: sun manuals X-VMS-To: TCP-IP I have a Sun 3/180. We're just starting to use it. The manuals are as yet incomprehensible to me. Anyone know where to look for calls to the tcp/ip/telnet functionality? USnail: Chris Johnson Academic Computer Services Northeastern University 39RI 360 Huntington Ave. Boston, MA. U.S.A. 02115 AT&T: (617) 437-2335 CSNET: johnson@nuhub.acs.northeastern.edu ARPANET: johnson%nuhub.acs.northeastern.edu@relay.cs.net BITNET: johnson%nuhub.acs.northeastern.edu@csnet-relay ----MESSAGE-END---- ----MESSAGE-BEGIN---- [780300001@orstcs] <1987041508090000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: netnews@orstcs.UUCP Newsgroups: comp.protocols.tcp-ip Subject: 4.3 TCP keep-alive question Message-ID: <780300001@orstcs> Date: Wed, 15-Apr-87 13:09:00 EST Article-I.D.: orstcs.780300001 Posted: Wed Apr 15 13:09:00 1987 Date-Received: Sat, 18-Apr-87 04:34:01 EST Lines: 29 Nf-ID: #N:orstcs:780300001:000:1030 Nf-From: orstcs.cs.ORST.EDU!netnews Apr 15 10:09:00 1987 /* Written 3:31 pm Apr 13, 1987 by chm@opus.UUCP in orstcs:comp.protocols.tcp-ip */ /* ---------- "4.3 TCP keep-alive question" ---------- */ The 4.2 TCP keep-alive implementation is described two different ways. According to the comment in tcp_timer.h, when the TCPT_KEEP timer expires we should send the following segment to elicit a response from our peer: But, the actual implementation in our version of tcp_timer.c sends: Note that the first segment contains an invalid SEQ and the second contains both an invalid SEQ and an invalid ACK. My question is, do we really need to lie about what we've received by sending an invalid ACK or is the invalid SEQ enough to elicit a response? -- Paul Chmielewski NBI Inc., Boulder, CO chm@nbires.UUCP or chm@nbires.NBI.COM (303) 444-5710 -- Paul Chmielewski NBI Inc., Boulder, CO chm@nbires.UUCP or chm@nbires.NBI.COM (303) 444-5710 /* End of text from orstcs:comp.protocols.tcp-ip */ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[E.ISI.EDU]15-Apr-87.15:05:25.SAC.AFGWC-SDMC] <1987041510050000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: SAC.AFGWC-SDMC@E.ISI.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Request For Information Message-ID: <[E.ISI.EDU]15-Apr-87.15:05:25.SAC.AFGWC-SDMC> Date: Wed, 15-Apr-87 15:05:00 EST Article-I.D.: <[E.ISI.EDU]15-Apr-87.15:05:25.SAC.AFGWC-SDMC> Posted: Wed Apr 15 15:05:00 1987 Date-Received: Fri, 17-Apr-87 06:21:08 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 128 It was suggested that I send our message to you by Dale Chase . Your help would be greatly appreciated. -- Tim J. Hern Begin forwarded message Received: By E.ISI.EDU via direct-append with Hermes; 26 Feb 87 15:14:15-CST Date: 26 Feb 1987 15:14-CST From: SAC.AFGWC-SDMC@E.ISI.EDU To: ACTION@A.ISI.EDU Cc: SAC.AFGWC-SDMC@E.ISI.EDU Subject: Request on information on HYPERchannel Message-ID: <[E.ISI.EDU]26-Feb-87 15:14:14.SAC.AFGWC-SDMC> Sender: SAC.AFGWC-SDMC@E.ISI.EDU 1. We are looking for users, special interest groups or vendors that have information on techniques/products that can be used to monitor our Network Systems Corporation (NSC) HYPERchannel, a high speed, radio-frequency, cable-based broadcast computer network. We are looking for software/hardware to: - Monitor the frequency of specific data transfers from host to host. In other words, "what is going where." - Monitor network throughput. - Get information on host-to-host transmission delays. - Get information on how long data is in queue before it is transmitted. - Monitor the size of the data being transferred. - Monitor the loading on the source computer and receiving computer during the transmission of the data. - Monitor the amount of CPU resources the actual transmission takes. - Track the shipment of data between two database machines (specifically Sperrys). 2. Our HYPERchannel allows the following communication configurations: Intra Sperry, intra VAX, Sperry to/from Vax and Sperry to/from Cray. We have the following kinds of computers: - Sperry 1100/82s. - Sperry 1100/72s. - Sperry 1100/91s. - DEC VAX 11/780s. - A Cray X-MP. 3. We wrote the communication software residing on the Sperry 1100s. Vendors wrote the communication software residing on the Vax computers and Cray. The following chart shows which communication software we have written and which software vendors have written: "AUTHOR OF COMMUNICATION SOFTWARE" "USAF" "USAF" "Harris" "Harris" "Sperry" "Sperry" ---------------------------------------------------------------------- | 1100s <--> 1100s HOST | | 1100s <------------> Vax COMPUTER| | Vax <------> Vax | | 1100s <---> Cray 4. We need information on the following subjects: - User written communication software which can be used on HYPERchannel. - We would like users to send us their evaluations of their HYPERchannel communication software, i.e., its advantages and disadvantages and whether the users are satisfied with it. - Network monitoring software/techniques, such as NSC's Network Recording Facility, which will be available in mid 1987. This software will show data flow on a network. It is a "passive" system which receives records from other systems on the network. - Commercial communication monitoring software, such as NSC's Network Monitor software, as well as user created software, which monitors the "health" of the NSC hardware. Tim J. Hern, USAF, Data Flow Administrator -------------------- End forwarded message ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041510050001> Received: from E.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 15 Apr 87 13:05:22-PDT Date: 15 Apr 1987 15:05-CDT Sender: SAC.AFGWC-SDMC@E.ISI.EDU Subject: Request For Information Subject: [SAC.AFGWC-SDMC@E.ISI.EDU: Request on information on HYPERc...] From: SAC.AFGWC-SDMC@E.ISI.EDU To: tcp-ip@SRI-NIC.ARPA Message-ID: <[E.ISI.EDU]15-Apr-87 15:05:25.SAC.AFGWC-SDMC> It was suggested that I send our message to you by Dale Chase . Your help would be greatly appreciated. -- Tim J. Hern Begin forwarded message Received: By E.ISI.EDU via direct-append with Hermes; 26 Feb 87 15:14:15-CST Date: 26 Feb 1987 15:14-CST From: SAC.AFGWC-SDMC@E.ISI.EDU To: ACTION@A.ISI.EDU Cc: SAC.AFGWC-SDMC@E.ISI.EDU Subject: Request on information on HYPERchannel Message-ID: <[E.ISI.EDU]26-Feb-87 15:14:14.SAC.AFGWC-SDMC> Sender: SAC.AFGWC-SDMC@E.ISI.EDU 1. We are looking for users, special interest groups or vendors that have information on techniques/products that can be used to monitor our Network Systems Corporation (NSC) HYPERchannel, a high speed, radio-frequency, cable-based broadcast computer network. We are looking for software/hardware to: - Monitor the frequency of specific data transfers from host to host. In other words, "what is going where." - Monitor network throughput. - Get information on host-to-host transmission delays. - Get information on how long data is in queue before it is transmitted. - Monitor the size of the data being transferred. - Monitor the loading on the source computer and receiving computer during the transmission of the data. - Monitor the amount of CPU resources the actual transmission takes. - Track the shipment of data between two database machines (specifically Sperrys). 2. Our HYPERchannel allows the following communication configurations: Intra Sperry, intra VAX, Sperry to/from Vax and Sperry to/from Cray. We have the following kinds of computers: - Sperry 1100/82s. - Sperry 1100/72s. - Sperry 1100/91s. - DEC VAX 11/780s. - A Cray X-MP. 3. We wrote the communication software residing on the Sperry 1100s. Vendors wrote the communication software residing on the Vax computers and Cray. The following chart shows which communication software we have written and which software vendors have written: "AUTHOR OF COMMUNICATION SOFTWARE" "USAF" "USAF" "Harris" "Harris" "Sperry" "Sperry" ---------------------------------------------------------------------- | 1100s <--> 1100s HOST | | 1100s <------------> Vax COMPUTER| | Vax <------> Vax | | 1100s <---> Cray 4. We need information on the following subjects: - User written communication software which can be used on HYPERchannel. - We would like users to send us their evaluations of their HYPERchannel communication software, i.e., its advantages and disadvantages and whether the users are satisfied with it. - Network monitoring software/techniques, such as NSC's Network Recording Facility, which will be available in mid 1987. This software will show data flow on a network. It is a "passive" system which receives records from other systems on the network. - Commercial communication monitoring software, such as NSC's Network Monitor software, as well as user created software, which monitors the "health" of the NSC hardware. Tim J. Hern, USAF, Data Flow Administrator -------------------- End forwarded message ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]15-Apr-87.18:59:33.CERF] <1987041512590000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Request For Information... Message-ID: <[A.ISI.EDU]15-Apr-87.18:59:33.CERF> Date: Wed, 15-Apr-87 17:59:00 EST Article-I.D.: <[A.ISI.EDU]15-Apr-87.18:59:33.CERF> Posted: Wed Apr 15 17:59:00 1987 Date-Received: Sun, 19-Apr-87 05:33:32 EST References: <[E.ISI.EDU]15-Apr-87.15:05:25.SAC.AFGWC-SDMC> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 3 Does Network Systems Corp have any aswers to your questions? Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041514590000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Wed 15 Apr 87 15:59:58-PDT Date: 15 Apr 1987 18:59-EDT Sender: CERF@A.ISI.EDU Subject: Re: Request For Information... From: CERF@A.ISI.EDU To: SAC.AFGWC-SDMC@E.ISI.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]15-Apr-87 18:59:33.CERF> In-Reply-To: <[E.ISI.EDU]15-Apr-87 15:05:25.SAC.AFGWC-SDMC> Does Network Systems Corp have any aswers to your questions? Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [2549@sequent.UUCP] <1987041519592300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sch@sequent.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP in ISO Message-ID: <2549@sequent.UUCP> Date: Thu, 16-Apr-87 00:59:23 EST Article-I.D.: sequent.2549 Posted: Thu Apr 16 00:59:23 1987 Date-Received: Fri, 17-Apr-87 05:52:39 EST References: <8704141658.AA01378@gateway.mitre.org> <1987.4.15.15.15.10.Rudy.Nedved@h.cs.cmu.edu> Reply-To: sch@sequent.UUCP (Steve Hemminger) Distribution: world Organization: Sequent Computer Systems, Beaverton, OR Lines: 12 Keywords: PING ICMP ISO It seems to me that the ISO attitude is that all vendors will have perfect hardware and software. This is obviously not true in the real network swamp. Pinging hosts is a useful tool just as a hardware tech checks cable continuities with an Ohm meter. It is always useful to verify things are working at the lowest level and trace the problem up through the levels. The more protocol levels in between the less useful the tool becomes. - Steve Hemminger - Network PIE - Sequent Computer Systems ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12295047549.61.TUCKER@SUMEX-AIM.STANFORD.EDU] <1987041611132100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: TUCKER@SUMEX-AIM.STANFORD.EDU (Robert Tucker) Newsgroups: comp.protocols.tcp-ip Subject: X.25 to Ethernet (TCP/IP) Gateway Message-ID: <12295047549.61.TUCKER@SUMEX-AIM.STANFORD.EDU> Date: Thu, 16-Apr-87 16:13:21 EST Article-I.D.: SUMEX-AI.12295047549.61.TUCKER Posted: Thu Apr 16 16:13:21 1987 Date-Received: Sun, 19-Apr-87 09:25:51 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 We need a gateway which will provide for terminal sessions between PADs and Hosts on X.25 Public Data Networks and Ethernets (using TCP/IP). We are interested in both turn-key black-box schemes and software packages which might allow small UNIX machines currently on our Ethernet to perform this function. The additional ability to support multi X.25 ports both for backup paths and sub-addressed hosts would be a help. Bob Tucker ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704162138.AA16073@ucbvax.Berkeley.EDU] <1987041611165100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tmallory@CCV.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP in ISO Message-ID: <8704162138.AA16073@ucbvax.Berkeley.EDU> Date: Thu, 16-Apr-87 16:16:51 EST Article-I.D.: ucbvax.8704162138.AA16073 Posted: Thu Apr 16 16:16:51 1987 Date-Received: Sun, 19-Apr-87 09:29:35 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 30 I just wanted to add to the debugging scenarios presented by Rudy. I have on many occasions used the message generators in our gateways to ping hosts in order to determine just where a routing problem may lie. The receipt of an echo reply packet by the gateway generates a trap message which is sent to the monitoring center. Using a gateway on a network to which the host is directly attached can show whether the host is able to communicate at all. By merely changing the source address in the ping to be the other side of the gateway, one can determine whether the host has the necessary routing information. Depending on the number of gateways under my control along the path, I can learn much about the type of problem. We often get complaints from users who cannot connect to some other host using tcp. It is very frequently case that one of the hosts does not have a route to the other network, but occasionally the problem turns out to be protocol related, as when it turned out that Sun's telnet could not use Class C internet addresses for opening connections in one direction. I don't remember whether it was client or server mode now. Such a simple low level tool can be implemented in virtually any network device, though even 4.2 bsd got it wrong for a while, so that a minimum of 48 bytes needed to be sent to get a reply where only 28 should be necessary. The more complex your debugging aids, the more likely they won't work when you need them. Tracy Mallory BBN Communciations 617-497-3193 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041612165100> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Thu 16 Apr 87 14:23:35-PDT To: tsuchiya@gateway.mitre.org Cc: iso@nrtc.northrop.com, tcp-ip@sri-nic.ARPA, x3s33-interest@h.cs.cmu.edu Cc: tmallory@ccv.bbn.com Subject: Re: ICMP in ISO Date: 16 Apr 87 17:16:51 D (Thu) From: tmallory@ccv.bbn.com I just wanted to add to the debugging scenarios presented by Rudy. I have on many occasions used the message generators in our gateways to ping hosts in order to determine just where a routing problem may lie. The receipt of an echo reply packet by the gateway generates a trap message which is sent to the monitoring center. Using a gateway on a network to which the host is directly attached can show whether the host is able to communicate at all. By merely changing the source address in the ping to be the other side of the gateway, one can determine whether the host has the necessary routing information. Depending on the number of gateways under my control along the path, I can learn much about the type of problem. We often get complaints from users who cannot connect to some other host using tcp. It is very frequently case that one of the hosts does not have a route to the other network, but occasionally the problem turns out to be protocol related, as when it turned out that Sun's telnet could not use Class C internet addresses for opening connections in one direction. I don't remember whether it was client or server mode now. Such a simple low level tool can be implemented in virtually any network device, though even 4.2 bsd got it wrong for a while, so that a minimum of 48 bytes needed to be sent to get a reply where only 28 should be necessary. The more complex your debugging aids, the more likely they won't work when you need them. Tracy Mallory BBN Communciations 617-497-3193 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12295076069.23.NIC@SRI-NIC.ARPA] <1987041613500000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NIC@SRI-NIC.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Sendmail files Message-ID: <12295076069.23.NIC@SRI-NIC.ARPA> Date: Thu, 16-Apr-87 18:50:00 EST Article-I.D.: SRI-NIC.12295076069.23.NIC Posted: Thu Apr 16 18:50:00 1987 Date-Received: Sat, 18-Apr-87 04:32:19 EST Sender: mwm@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 The NIC has collected some sendmail configuration files for use by internet or internet-uucp sites. They are for sites running sendmail with 4.2BSD without domain resolvers (i.e. still using the host table). The files and documentation on how to modify them for your particular site are courtesy of Erik Fair. You can FTP them from the SRI-NIC.ARPA host using the pathnames NETINFO:SENDMAIL-CF-DOC.TXT NETINFO:SENDMAIL-INTERNET-GENERIC.TXT NETINFO:SENDMAIL-GENERIC.TXT The DDN Network Information Center ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041617505100> Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Thu 16 Apr 87 17:22:07-PDT Received: by ucbvax.Berkeley.EDU (5.57/1.23) id AA17110; Thu, 16 Apr 87 14:32:20 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Apr 87 17:50:51 GMT From: medin@cod.nosc.mil (Ted Medin) Organization: Naval Ocean Systems Center, San Diego Subject: Looking for ip/tcp mdqs Message-Id: <614@cod.UUCP> Sender: tcp-ip-request@sri-nic.arpa To: tcp-ip@sri-nic.arpa We are looking for an mdqs implementation on a dec vax runing vms 4.x or so. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704162256.a010219@Huey.UDEL.EDU] <1987041617560400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP in ISO Message-ID: <8704162256.a010219@Huey.UDEL.EDU> Date: Thu, 16-Apr-87 22:56:04 EST Article-I.D.: Huey.8704162256.a010219 Posted: Thu Apr 16 22:56:04 1987 Date-Received: Sun, 19-Apr-87 10:21:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 We should not lose sight of the fact that echo mechanisms are embedded in many protocols besides ICMP. Both TCP and UDP have echo ports, for example. DECnet has an echo "mirror" mechanism as well. We might argue about the detail protocol involved or whether it belongs as an intrinsic feature of each protocol (as I believe) or belongs in a pervasive network management, but I think we can all agree the mechanisms are necessary for any real network. As one who often has had echo goo smeared up to my clavicle, I can observe there have been numerous cases where something was found to be working just fine at the IP level was broken at the TCP/UDP level as diagnosed by the TCP/UDP echo mechansim. I submit we shouldn't stop at ICMP and should strive for these mechanisms at each and every level in the protocol stack. DavU> ----MESSAGE-END---- ----MESSAGE-BEGIN---- [545647655.0.CASNER@VENERA.ISI.EDU] <1987041621473500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CASNER@VENERA.ISI.EDU (Stephen Casner) Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP in ISO Message-ID: <545647655.0.CASNER@VENERA.ISI.EDU> Date: Fri, 17-Apr-87 02:47:35 EST Article-I.D.: VENERA.545647655.0.CASNER Posted: Fri Apr 17 02:47:35 1987 Date-Received: Sun, 19-Apr-87 10:45:16 EST References: <8704141658.AA01378@gateway.mitre.org> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 We have used ICMP echoes frequently in testing the Wideband Satellite Net and paths through the gateways that attach to it. Aside from simply probing for connectivity, using ICMP echoes allowed us to measure packet loss and misordering characteristics that would be harder to discern by examination of the behaviour of a transport protocol. It is easy for an ICMP echo tester to send packets at a regular rate and observe the delay distribution of the echo replies. The transmission rate of a transport protocol will likely be affected by network anomolies, clouding the measurement. We had observed unexpected behavior in the NETBLT protocol we were testing; with ICMP echoes we were able to get a better understanding of the performance of the network to serve as a basis for further NETBLT tests. One drawback of testing with ICMP echoes is that the path must be a round trip. Network performance may be different under unidirectional load. ICMP-like datagrams are useful for testing between a separate transmitter and receiver as well, but transmission time is then only relative rather than absolute unless synchronized clocks are available (oh so nice to have!). -- Steve Casner ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704171015.AA17404@spam.istc.sri.com] <1987041623302400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gds@SPAM.ISTC.SRI.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP in ISO Message-ID: <8704171015.AA17404@spam.istc.sri.com> Date: Fri, 17-Apr-87 04:30:24 EST Article-I.D.: spam.8704171015.AA17404 Posted: Fri Apr 17 04:30:24 1987 Date-Received: Sat, 18-Apr-87 04:42:46 EST References: <8704162256.a010219@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 We should not lose sight of the fact that echo mechanisms are embedded in many protocols besides ICMP. Both TCP and UDP have echo ports, for example. ... I submit we shouldn't stop at ICMP and should strive for these mechanisms at each and every level in the protocol stack. Dave, I agree with your points. However it may be difficult to do this in practice. I took a random sampling of hosts I usually ping to measure their round-trip times and tried connecting to their tcp echo ports instead. Out of all the hosts I tried, none but the Unix 4.3 hosts were listening on the echo port (and even some of them were not listening). It's trivial to write an echo server, but for some reason most hosts don't seem to support it. Transport-level echo services are not required in the same sense that ICMP echo is required. If we want to be assured that we can do debugging at all layers, not only must we push for debugging protocols at all levels of the protocol stack but encourage everyone to implement and use these protocols. --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704171337.AA12197@GAAK.LCS.MIT.EDU] <1987041703373600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jbvb@GAAK.LCS.MIT.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Ping & debugging tools Message-ID: <8704171337.AA12197@GAAK.LCS.MIT.EDU> Date: Fri, 17-Apr-87 08:37:36 EST Article-I.D.: GAAK.8704171337.AA12197 Posted: Fri Apr 17 08:37:36 1987 Date-Received: Sat, 18-Apr-87 05:54:31 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 We include a Ping in every copy we ship. It is the tool of choice for dealing with support calls of the form "... I tried telnet and it just timed out...", because it bypasses a lot of higher-level problems: ICMP doesn't care if the PC is in its host table, trailers don't get involved because the packets are short, everything including gateways ought to respond to it, etc. Our Ping displays extensive network statistics, and can act as a server, and in this mode, we have used it to diagnose various customer problems caused by a crazed machine (not ours) generating excessive broadcasts of one kind or another. Other debugging tools we find useful on a workstation include programs for explicitly checking nameservers, displaying who responded to a query and what they responded with. For instance, as of Wednesday, 4/15, DCN1's IEN-116 UDP service was giving 128.6.4.7 for MVS.RUTGERS.EDU, whose un-transposed address is 128.6.7.4. I could tell I was getting a bogus address using other programs, but I would have had to read through a lot of debugging trace to find out who, and it wouldn't have been presented in easy-to-read formats. James B. VanBokkelen FTP Software Inc. jbvb@ai.ai.mit.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987041706274700> Received: from SH.CS.NET by SRI-NIC.ARPA with TCP; Fri 17 Apr 87 10:14:40-PDT To: Robert Tucker cc: TCP-IP@SRI-NIC.ARPA, PFernandez@sumex-aim.stanford.edu Date: Fri, 17 Apr 87 13:07:47 -0400 From: Leo Lanzillo Subject: Re: X.25 to Ethernet (TCP/IP) Gateway In-reply-to: Your message of Thu, 16 Apr 87 14:13:21 -0700. <12295047549.61.TUCKER@SUMEX-AIM.STANFORD.EDU> Fcc: outbox -------- We need a gateway which will provide for terminal sessions between PADs and Hosts on X.25 Public Data Networks and Ethernets (using TCP/IP). We are interested in both turn-key black-box schemes and software packages which might allow small UNIX machines currently on our Ethernet to perform this function. The additional ability to support multi X.25 ports both for backup paths and sub-addressed hosts would be a help. CSNET distributes under license software which provides a TCP/IP over X.25 interface. The software, known as XNI, runs under UNIX on a vax and currently works with an Interactive Systems Incard X.25 device. Work is under way to make the software work with ACC X.25 devices. The software supports TCP/IP over the public data network and enables the host to act as an IP gateway between other hosts on the PDN and whatever is behind the host. In addition to the TCP/IP support, XNI implements PAD functionality. It can be used as a remote terminal to connect to another host on the PDN or to act as a tty port on the gateway host. To reach other machines behind the gateway from the PDN, one could either telnet from the shell or have rlogin be your shell. More info is available from cic@sh.cs.net Leo Lanzillo leo@sh.cs.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704171132.a018567@Huey.UDEL.EDU] <1987041706324000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP in ISO Message-ID: <8704171132.a018567@Huey.UDEL.EDU> Date: Fri, 17-Apr-87 11:32:40 EST Article-I.D.: Huey.8704171132.a018567 Posted: Fri Apr 17 11:32:40 1987 Date-Received: Sat, 18-Apr-87 06:10:42 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 Greg, In a random search I found about half the dozen of so hosts I tried did respond to the TCP Echo port, including all the 4.2s and 4.3s I tried (but not the Suns). At least one Multics machine and all the Fuzzballs I tried responded as well. The SATNET SIMPs have long been used as a tool to debug reassembly implementations, since SATNET can fragment and dis-order datagrams in glorious ways. Nevertheless, your comment is accurate in that the TCP/UDP Echo service is certainly not ubiquitous. It is interesting to note that a TCP/UPD Echo service is trivial to implement, since all it takes is a swap of addresses (and ports in some implementations), which makes it no more intrusive than ICMP Echo. However, this defeats the purpose of the service, which is to verify that the TCP/UPD protocol layer itself is working properly. An interesting side issue is exactly how the echo service is implemented with respect to source-route, record-route, TTL and so forth. Exploration of this may shed some lumens on the general protocol model as well. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704171633.AA00225@apolling.imagen.uucp] <1987041706334100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@imagen.UUCP.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Re: A New TCP Retransmission Algorithm Message-ID: <8704171633.AA00225@apolling.imagen.uucp> Date: Fri, 17-Apr-87 11:33:41 EST Article-I.D.: apolling.8704171633.AA00225 Posted: Fri Apr 17 11:33:41 1987 Date-Received: Sat, 18-Apr-87 06:07:37 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.DEC.COM Distribution: world Organization: The ARPA Internet Lines: 46 Looks baroque, but ok, until I see: > Note that failing to acknowledge a packet isn't necessarily enough > information since if the remote site closes its window it can still > indicate that it is alive by acknowledging old data. However, the > geometric backoff means that it might take a very long time to detect > the reopened window. A window opening ACK wouldn't be acceptable unless > it opened the window farther than it had been before being closed. Does > anyone admit to actually closing windows? This might be an argument to > limit the maximum retransmission interval to say, two minutes. Even > then, you might want a connection to keep trying forever. YES I CLOSE WINDOWS FOR A LOOOOOOONG TIME -- FROM WHEN THE PRINTER RUNS OUT OF PAPER UNTIL SOMEONE PUTS MORE PAPER BACK IN. THREE DAYS IS NOT UNHEARD OF. And every TCP implementation that incorrectly times out just because of a protracted zero window (say 25 seconds) causes a job to die and us to have an irate customer. Presumably TCP terminal gw's do the same thing if you type ^S on the keyboard (or if you attach them to a printer that is out of paper). Data that is not acknowledged because there is a zero window IS NOT THE SAME THING as data that is not acknowledged because it wasn't received. The sender KNOWS that it is sending into a zero window. Thus it is extremely silly for a sender to apply normal retransmission criteria to a zero window condition. During zero window, the sender should probe the connection repeatedly with an interval of 2.5 minutes or so. These packets are guaranteed to generate an immediate response (that does not ack the data), so the response can be used to keep the connection alive EVEN THOUGH no data is acked. This is the only place in the TCP where it is mandated precisely when to send a packet which bears neither data nor ack (the spec allows them to be sent anywhere, and good practise mandates that they be sent occasionally, but there is no where else where they are required). If 2.5 minutes is too long for you (remember, [1] very few situations generate a zero window, and [2] the receiver will almost certainly volunteer a packet that opens the window) then start with a tighter probe and back it off to 2.5 minutes after a little while. But don't use a long backoff as if you were in a congestion situation (when you've been getting back packets all along) and DON'T RESET THE CONNECTION. Please please please fix your buggy implementations to do the right thing when sending into a zero window. - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704171153.a018942@Huey.UDEL.EDU] <1987041706532400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Ping & debugging tools Message-ID: <8704171153.a018942@Huey.UDEL.EDU> Date: Fri, 17-Apr-87 11:53:24 EST Article-I.D.: Huey.8704171153.a018942 Posted: Fri Apr 17 11:53:24 1987 Date-Received: Sun, 19-Apr-87 11:02:06 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Jim, Just to underscore your point, I confirmed your observation that the dcn1 name server was in fact bog, but using my own flashy toolkit. Geez, you mean somebody is still using old-style name servers? Well, it turned out the new-style (domain) name server on dcn1 is bogged as well. The bug several years old, but was revealed only by your tests just now. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704171729.AA05915@ucbvax.Berkeley.EDU] <1987041707310900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: leo@SH.CS.NET.UUCP Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8704171729.AA05915@ucbvax.Berkeley.EDU> Date: Fri, 17-Apr-87 12:31:09 EST Article-I.D.: ucbvax.8704171729.AA05915 Posted: Fri Apr 17 12:31:09 1987 Date-Received: Sat, 18-Apr-87 06:10:57 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 34 Subject: Re: X.25 to Ethernet (TCP/IP) Gateway In-reply-to: Your message of Thu, 16 Apr 87 14:13:21 -0700. <12295047549.61.TUCKER@SUMEX-AIM.STANFORD.EDU> Fcc: outbox -------- We need a gateway which will provide for terminal sessions between PADs and Hosts on X.25 Public Data Networks and Ethernets (using TCP/IP). We are interested in both turn-key black-box schemes and software packages which might allow small UNIX machines currently on our Ethernet to perform this function. The additional ability to support multi X.25 ports both for backup paths and sub-addressed hosts would be a help. CSNET distributes under license software which provides a TCP/IP over X.25 interface. The software, known as XNI, runs under UNIX on a vax and currently works with an Interactive Systems Incard X.25 device. Work is under way to make the software work with ACC X.25 devices. The software supports TCP/IP over the public data network and enables the host to act as an IP gateway between other hosts on the PDN and whatever is behind the host. In addition to the TCP/IP support, XNI implements PAD functionality. It can be used as a remote terminal to connect to another host on the PDN or to act as a tty port on the gateway host. To reach other machines behind the gateway from the PDN, one could either telnet from the shell or have rlogin be your shell. More info is available from cic@sh.cs.net Leo Lanzillo leo@sh.cs.net ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870417205907.00a@sdsc-sds.arpa] <1987041710590700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gkn@SDSC-SDS.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Echo services Message-ID: <870417205907.00a@sdsc-sds.arpa> Date: Fri, 17-Apr-87 15:59:07 EST Article-I.D.: sdsc-sds.870417205907.00a Posted: Fri Apr 17 15:59:07 1987 Date-Received: Sun, 19-Apr-87 12:49:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 All of the VAXen here at SDSC have TCP Echo (port 7, RFC 862), TCP Discard (port 9, RFC 863), and character generator (port 19, RFC 864) services on them. These were put in place to help debug (and proved invaluable) the underlying communications software for the FTP client program on our Cray X-MP/48. In addition to these services there are a number of others, including a "congested" version of the Echo and Discard services which proved to be interesting obstacles in making the communications on the Cray as robust as possible. I doubt seriously that we could have made the stuff for the Cray work without them. I also wish that some of these services were available someplace besides our local ethernet; we were severly flamed for using an echo server on another host elsewhere in the network (hence the "congested" versions). gkn -------------------------------------- Arpa: GKN@SDSC-SDS.ARPA Bitnet: GKN@SDSC Span: SDSC::GKN (27.1) USPS: Gerard K. Newman San Diego Supercomputer Center P.O. Box 85608 San Diego, CA 92138 AT&T: 619.534.5076 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [187187.870418.JBVB@AI.AI.MIT.EDU] <1987041720171600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB@AI.AI.MIT.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Old-style nameservers Message-ID: <187187.870418.JBVB@AI.AI.MIT.EDU> Date: Sat, 18-Apr-87 01:17:16 EST Article-I.D.: AI.187187.870418.JBVB Posted: Sat Apr 18 01:17:16 1987 Date-Received: Sun, 19-Apr-87 00:49:25 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 We allow up to three of each kind (domain and IEN-116), as well as a host table in our configuration. We distribute a public-domain IEN-116 nameserver for 4BSD on our "Unsupported Network Software" diskette, partly because we were sure we could do so legally, and partly because it is much simpler (most people who want it aren't on the Internet yet). We would like to give out bind, as well, but it has "Copyright Regents of..." all over it, and no release. We *do* have more room on the diskette, if anyone wishes to point me at p-d goodies of general utility. It would be nice to put all nine 4.3 patches on it, too... As you probably know, Bridge, in their recent upgrading of some of their product line, chose to use IEN-116. It is definitely better than hosttables. jbvb@ai.ai.mit.edu James B. VanBokkelen FTP Software Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12295416448.18.SY.KEN@CU20B.COLUMBIA.EDU] <1987041720594600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sy.Ken@CU20B.COLUMBIA.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Re: A New TCP Retransmission Algorithm Message-ID: <12295416448.18.SY.KEN@CU20B.COLUMBIA.EDU> Date: Sat, 18-Apr-87 01:59:46 EST Article-I.D.: CU20B.12295416448.18.SY.KEN Posted: Sat Apr 18 01:59:46 1987 Date-Received: Sun, 19-Apr-87 00:49:01 EST References: <8704171633.AA00225@apolling.imagen.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Looks baroque, but ok, until I see... Don't know what all the discussion is about. I was always of the mind that 'if it ain't baroque, don't fix it!' (sorry). /K ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704182059.AA08454@okeeffe.Berkeley.EDU] <1987041810594900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: BIND redistribution (was Re: Old-style nameservers) Message-ID: <8704182059.AA08454@okeeffe.Berkeley.EDU> Date: Sat, 18-Apr-87 15:59:49 EST Article-I.D.: okeeffe.8704182059.AA08454 Posted: Sat Apr 18 15:59:49 1987 Date-Received: Sun, 19-Apr-87 05:45:21 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Although BIND has copyright notices in it, there is no problem with redistributing it. Like all Berkeley-licensed code, there are only 2 restrictions on redistribution: any rights of AT&T in their original UNIX source must be protected (in this case, none), and due credit must be given the University. Maintaining the copyright notices in redistributed source code is generally sufficient to satisfy this restriction. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704182219.AA08621@okeeffe.Berkeley.EDU] <1987041812194500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: 4.3 TCP keep-alive question Message-ID: <8704182219.AA08621@okeeffe.Berkeley.EDU> Date: Sat, 18-Apr-87 17:19:45 EST Article-I.D.: okeeffe.8704182219.AA08621 Posted: Sat Apr 18 17:19:45 1987 Date-Received: Sun, 19-Apr-87 07:41:56 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 Curiously, I tried an experiment with keepalives a few weeks ago. Your description of the comment in the 4.2 source isn't quite accurate; the comment accurately describes what the code does, but is wrong about the reasoning. Both 4.2 and 4.3 send with one byte of (imaginary) data. As you observed, sending with no data should be sufficient to elicit a response. However, although 4.3 systems and Sun 3.x systems responded to such probes, Ultrix 1.2 (and 2.0 field test) systems failed to respond, which rather annoyed the users whose windows would disappear after some minutes of inactivity. I haven't tested this with more systems because of the one failure; I don't have any stock 4.2's left nearby. Curiously, I started looking at this because someone from the Ultrix group found a bug in handling resets generated in response to a keepalive. The reset may not be accepted, as the sequence number will be one to the left of the window using the current keepalive format. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [4509@utah-cs.UUCP] <1987041815101200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cetron@utah-cs.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: 4.3 TCP keep-alive question Message-ID: <4509@utah-cs.UUCP> Date: Sat, 18-Apr-87 20:10:12 EST Article-I.D.: utah-cs.4509 Posted: Sat Apr 18 20:10:12 1987 Date-Received: Sun, 19-Apr-87 08:27:22 EST References: <8704182219.AA08621@okeeffe.Berkeley.EDU> Reply-To: cetron@cs.utah.edu.UUCP (Edward J Cetron) Distribution: world Organization: Center for Engineering Design, Univ of Utah Lines: 31 Keywords: Ultrix keepalives missing line of code Summary: Ultrix is missing a line of code In article <...> karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) writes: ->Curiously, I tried an experiment with keepalives a few weeks ago. ->Your description of the comment in the 4.2 source isn't quite ->accurate; the comment accurately describes what the code does, ->but is wrong about the reasoning. Both 4.2 and 4.3 send -> ->with one byte of (imaginary) data. As you observed, sending -> ->with no data should be sufficient to elicit a response. However, ->although 4.3 systems and Sun 3.x systems responded to such probes, ->Ultrix 1.2 (and 2.0 field test) systems failed to respond, which ->rather annoyed the users whose windows would disappear after some ->minutes of inactivity. I haven't tested this with more systems After spending a week hacking keep-alives into the Tektronix TCP/IP code, I too was quite frustrated when many ultrix users kept calling and complaining about there windows disappearing. After much poring through both the 4.2/4.3 keep alive code and comparing it against the ultrix 1.2 code it became obvious that ONE SINGLE LINE OF CODE IS MISSING in the ultrix networking code. Seems it gets the keepalive, figures out it is a keep alive and then doesn't have that ONE LINE OF CODE which tells the kernel to send out an ack. Looks to me like a typo deleted a line by mistake. I posted this fact here quite a while ago, passed it on to some friends at dec, and would have filed an SPR but I don't have any Ultrix systems to file it under. I had hoped it would be fixed in V2.0 but I quess not. Maybe if I shame the Ultrix people in Nashville next week :-) -ed cetron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12295657810.17.ROODE@BIONET-20.ARPA] <1987041819053600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROODE@BIONET-20.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: X.25 to Ethernet (TCP/IP) Gateway Message-ID: <12295657810.17.ROODE@BIONET-20.ARPA> Date: Sun, 19-Apr-87 00:05:36 EST Article-I.D.: BIONET-2.12295657810.17.ROODE Posted: Sun Apr 19 00:05:36 1987 Date-Received: Sun, 19-Apr-87 11:42:48 EST References: <12295047549.61.TUCKER@SUMEX-AIM.STANFORD.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 We put some ports (RS232) from our cisco EtherTip box (TCP/IP) on a CompuServe Network Nanonode. I know this is not exactly what you're describe, but I thought you might be interested since it yields equivalent functionality. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704190722.AA17818@uw-apl] <1987041820164600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: srg@quick.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8704190722.AA17818@uw-apl> Date: Sun, 19-Apr-87 01:16:46 EST Article-I.D.: uw-apl.8704190722.AA17818 Posted: Sun Apr 19 01:16:46 1987 Date-Received: Sun, 19-Apr-87 17:45:53 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 Path: quick!srg From: srg@quick.UUCP (Spencer Garrett) Newsgroups: mod.protocols.tcp-ip Subject: Re: Time RFC 868 Summary: RTT can be estimated with 2 packets, not 4 Message-ID: <119@quick.UUCP> Date: 19 Apr 87 06:16:45 GMT References: <8704051517.a011510@Huey.UDEL.EDU> <194@cos.COM> Organization: Quicksilver Engineering, Seattle Lines: 11 In article <194@cos.COM>, howard@cos.UUCP (Howard Berkowitz) writes: > the slave RETRANSMITS what it received. The master > then calculates the difference (in time units) between > what it sent and what the slave received, and sends > that as a correction factor. ... This same protocol could be done with 2 packets instead of 4. The originator (master) should estimate the round-trip time (RTT) using its local clock instead of asking the responder (slave) to perform that function. The accuracy of the setting of the local clock is of no consequence. Only a time difference is needed. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [6045@dartvax.UUCP] <1987042003071300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: richb.UUCP@dartvax.UUCP (Richard E. Brown) Newsgroups: comp.protocols.tcp-ip Subject: Re: network password protection/TCP spec Message-ID: <6045@dartvax.UUCP> Date: Mon, 20-Apr-87 08:07:13 EST Article-I.D.: dartvax.6045 Posted: Mon Apr 20 08:07:13 1987 Date-Received: Tue, 21-Apr-87 02:07:23 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: dartvax!richb (Richard E. Brown) Distribution: world Organization: Dartmouth College, Hanover, NH Lines: 43 TO THE MODERATOR: I tried to post this a while ago, but received a reply from some mailer daemon that this message should be mailed to you, not posted. I never received any responses, so I'm suspicious: did it arrive and was it posted? If not, would you post it now? If it was, thanks. Rich Brown ------------ MY MESSAGE FOLLOWS ------- A while back, there was a discussion of protecting passwords, which lead to a discussion of taking over someone's TCP connection. One person noted that if a spoofer simply startd sending in-sequence messages, they could take over the session and the victim would be relatively helpless. Another person responded that he thought TCP specified that an ACK with a sequence number that was too high would result in a RST to clean out the connection. (Further discussion revealed that TCP does *not* specify this -- in fact, it allows the session to continue.) My question: Is this behavior (sending RST if the ACKs get too high) desirable? Are there any pitfalls to doing this? Here at Dartmouth, we have developed a stream protocol which runs over AppleTalk. It is in use throughout the campus with our Macintosh terminal emulator, and several commercial vendors are also implementing this protocol. If it is useful, a stroke of a pen will implement it (well, you know what I mean). Thanks. Rich Brown Dartmouth College Kiewit Computer Center Hanover, NH 03755 603/646-3648 richb@dartmouth.edu richb@dartmth.bitnet richb@dartvax.UUCP A0183 on AppleLink ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870420213143.005848@MIT-MULTICS.ARPA] <1987042011310000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JSLove@MIT-MULTICS.ARPA ("J. Spencer Love") Newsgroups: comp.protocols.tcp-ip Subject: Re: Re: A New TCP Retransmission Algorithm Message-ID: <870420213143.005848@MIT-MULTICS.ARPA> Date: Mon, 20-Apr-87 16:31:00 EST Article-I.D.: MIT-MULT.870420213143.005848 Posted: Mon Apr 20 16:31:00 1987 Date-Received: Tue, 21-Apr-87 03:27:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 No, you don't understand what I meant by "closing a window". I am asking, does anyone admit to taking away a window already granted. That is, first announcing that a nonzero window is available, and then later announcing that a smaller window is available than is justified by additional bytes acknowledged. This amounts to backing up the edge of the window, which is explicitly discouraged in the spec. It is true that if no additional data can be acknowledged, then the sending TCP can't tell that the window has shrunk because of the rule for sorting out old vs new window updates, which only provides for growing the window if the sequence and acknowledgement fields do not change. Thus, I am NOT addressing the possibly widespread bug that sending into a zero window causes timeouts, which it shouldn't, but rather asking if a connection should be kept alive indefinitely by receiving obsolete acknowledgements when it *thinks* it has a nonzero window to send into. This is a variant of the old keepalive controversy, I suppose. The question is, does anyone admit to illegally backing up the edge of the window, not does anyone admit to running out of buffer space. -- Spencer ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12296103835.19.KLH@SRI-NIC.ARPA] <1987042011554200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: KLH@SRI-NIC.ARPA (Ken Harrenstien) Newsgroups: comp.protocols.tcp-ip Subject: Re: Re: A New TCP Retransmission Algorithm Message-ID: <12296103835.19.KLH@SRI-NIC.ARPA> Date: Mon, 20-Apr-87 16:55:42 EST Article-I.D.: SRI-NIC.12296103835.19.KLH Posted: Mon Apr 20 16:55:42 1987 Date-Received: Tue, 21-Apr-87 03:32:21 EST References: <870420213143.005848@MIT-MULTICS.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 The ITS TCP implementation, at least, often does reduce the window by more than the amount of bytes acknowledged; what it would really like to use is a packet count, rather than a byte count. It is prepared to recover (by compaction etc) if the sender does not take any notice of the reduced window size, but this was still a conscious decision to live dangerously for the sake of greater efficiency. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870420230617.176880@MIT-MULTICS.ARPA] <1987042013060000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JSLove@MIT-MULTICS.ARPA ("J. Spencer Love") Newsgroups: comp.protocols.tcp-ip Subject: Re: network password protection/TCP spec Message-ID: <870420230617.176880@MIT-MULTICS.ARPA> Date: Mon, 20-Apr-87 18:06:00 EST Article-I.D.: MIT-MULT.870420230617.176880 Posted: Mon Apr 20 18:06:00 1987 Date-Received: Wed, 22-Apr-87 03:47:09 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 72 I sent some of the messages on this topic, in particular the claim that Multics sends RST segments when it receives precognitive acknowledgements, and a subsequent justification of this behavior when it turned out to be contrary to RFC 793. If a precognitive acknowledgement is received, it comes from one of three sources: 1) it is a paleolithogram which has been lying around in the network exceeding its time-to-live, perhaps because of gateway problems or sick hardware; 2) it indicates that the other end of the connection has accepted data which you have not sent; or 3) someone is trying to get you to reset the connection or update your window values. The reason RFC 793 says that precognitive acknowledgements should be ignored is that the authors only considered case 1 interesting. Case 3 only exists in violation of the spec (a way to close windows) or can be considered to be in the same category as case 2 in terms of tampering with the connection. My argument was that case 2 was possible and that handling it by sending a RST was sensible. The argument against it is that this might cause case 1 to abort connections spuriously. My counterargument is that RST packets generated via case 1 are very unlikely to abort the connection. This is because the RST packet's sequence number must be in the window acceptable to the receiving TCP. This sequence number is the precognitive ACK which caused the RST. If the sequence number is out-of-window, then the RST packet is ignored. This is described on page 37 of RFC 793. The range of valid sequence numbers for the RST extends from the highest acknowledged sequence number to the window edge which is determined by the available buffer space. This window cannot in any case exceed 65,535 acceptable values, but is usually much smaller. The range of possible values is much larger; there are 4,294,967,296 possible values. Thus, the probability that a paleolithogram-induced RST will be in the window is actually quite small. This is generally the case when initial sequence numbers are chosen by a clock as described in RFC 793; it is less true for implementations where all sequence numbers start at zero. See pages 26 and 27 of the RFC. If your protocol can sort out acceptable RST packets from a much larger set of possible RST packets, then case 1 above won't be very likely to destroy connections. However, if your protocol doesn't have this property, then perhaps some other mechanism for detecting and defeating subversion attempts would be more appropriate. This mechanism isn't really good enough to be a dependable hacker trap. If you really want protection you should try using encryption. For example, you could encrypt TCP packets as announced by an extended security option (as yet unspecified) which appears in the IP header and is thus in the clear. The cipher chaining could use some function of the IP header's fragment reassembly identifier field so that each TCP packet would start out differently even for equivalent port values and sequence numbers (assuming DES). Key selection would be on a host-host basis with regard to security level and perhaps type-of-service but not with regard to port numbers. This might make it very difficult to subvert connections, but I know of no research to test the robustness of this scheme. For AppleTalk, how big are your acknowledgement fields? Can packets get queued in gateways or device drivers from which they might emerge later and cause trouble? Is any of this TCP technology applicable at all? TCP and IP have huge headers which contain most commonly used fields in fixed places to minimize packet processing overhead, so that their users can pass many many packets per second through very high speed interfaces. A more byte-oriented protocol with many optional fields might have very different design constraints. For example, if there were no gateways, then perhaps case 1 can never arise, so precognitive acks always indicate something very wrong. On the other hand, some protocols might consider any RST (abort) packet valid, so that you should be very careful about possibly generating spurious aborts. -- Spencer Love (617-253-2091 if email fails) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704210222.AA05136@gwen.cs.purdue.edu] <1987042016222800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: narten@PURDUE.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP in ISO Message-ID: <8704210222.AA05136@gwen.cs.purdue.edu> Date: Mon, 20-Apr-87 21:22:28 EST Article-I.D.: gwen.8704210222.AA05136 Posted: Mon Apr 20 21:22:28 1987 Date-Received: Tue, 21-Apr-87 06:17:46 EST References: <8704171132.a018567@Huey.UDEL.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 >It is interesting to note that a TCP/UPD Echo service is trivial to >implement, since all it takes is a swap of addresses (and ports in some >implementations), which makes it no more intrusive than ICMP Echo. While you might get away with this at the TCP layer, it leads to interesting behavior when done with UDP or at lower layers. A certain dedicated IP gateway we have does this very thing when generating ICMP errors, and answering ICMP echo requests. Imagine further, a very widely distributed version of ping that allowed one to send ICMP echo requests to IP broadcast addresses. While pings are harmless enough, I have seen port unreachables fly across our Ethernet that "originate" from an IP broadcast address. Thomas ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704210324.AA09619@ucbvax.Berkeley.EDU] <1987042016224700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@CCV.BBN.COM (Mike Brescia) Newsgroups: comp.protocols.tcp-ip Subject: What is a window (was: A New TCP Retransmission Algorithm) Message-ID: <8704210324.AA09619@ucbvax.Berkeley.EDU> Date: Mon, 20-Apr-87 21:22:47 EST Article-I.D.: ucbvax.8704210324.AA09619 Posted: Mon Apr 20 21:22:47 1987 Date-Received: Wed, 22-Apr-87 00:03:39 EST References: <12296103835.19.KLH@SRI-NIC.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 29 The ITS TCP implementation, at least, often does reduce the window by more than the amount of bytes acknowledged; what it would really like to use is a packet count, rather than a byte count. A little history comes to mind. In early ARPANET days, NCP was the precursor to TCP. Each stream had what was termed an 'allocation', which was the set of numbers used to enforce flow control. A sender could not send more than the allocation given it by the receiver. "More what?", you ask. Well, there were 2 numbers in the allocation, which had to be accounted each time you sent a message. There was the 'message count' and also the 'byte count'. (Maybe it was a bit count, since NCP allowed arbitrary byte sizes.) If a sender was working with an allocation of 8 messages and 1000 bytes, it could send one 1000 byte message, or 8 one byte messages, or whatever else caused either the byte or the message allocation to be used up. The receiver, when buffers were freed, would be expected to send back a new allocate, with incremental updates to the numbers the sender was maintaining. Hopefully, the receiver would hold off a little while, and avoid sending an allocate for each message received. (Sounds like 'silly window syndrome'.) In order to fix the problem of hung connections when allocate messages got lost, there was a spec for a method to reset the allocations, but I don't recall seeing it widely implemented. The arpanet did not drop enough messages to convince many people to put the work into their hosts. (ARPANET still does not drop many messages.) "Those who do not learn from history, looostl.UU 21:0 G ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987042017224700> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Mon 20 Apr 87 20:13:52-PDT To: TCP-IP@sri-nic.ARPA Subject: What is a window (was: A New TCP Retransmission Algorithm) In-reply-to: Ken Harrenstien's message of Mon 20 Apr 87 14:55:42-PDT. <12296103835.19.KLH@SRI-NIC.ARPA> Date: 20 Apr 87 22:22:47 D (Mon) From: Mike Brescia The ITS TCP implementation, at least, often does reduce the window by more than the amount of bytes acknowledged; what it would really like to use is a packet count, rather than a byte count. A little history comes to mind. In early ARPANET days, NCP was the precursor to TCP. Each stream had what was termed an 'allocation', which was the set of numbers used to enforce flow control. A sender could not send more than the allocation given it by the receiver. "More what?", you ask. Well, there were 2 numbers in the allocation, which had to be accounted each time you sent a message. There was the 'message count' and also the 'byte count'. (Maybe it was a bit count, since NCP allowed arbitrary byte sizes.) If a sender was working with an allocation of 8 messages and 1000 bytes, it could send one 1000 byte message, or 8 one byte messages, or whatever else caused either the byte or the message allocation to be used up. The receiver, when buffers were freed, would be expected to send back a new allocate, with incremental updates to the numbers the sender was maintaining. Hopefully, the receiver would hold off a little while, and avoid sending an allocate for each message received. (Sounds like 'silly window syndrome'.) In order to fix the problem of hung connections when allocate messages got lost, there was a spec for a method to reset the allocations, but I don't recall seeing it widely implemented. The arpanet did not drop enough messages to convince many people to put the work into their hosts. (ARPANET still does not drop many messages.) "Those who do not learn from history, loop." Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[A.ISI.EDU]21-Apr-87.07:51:49.CERF] <1987042101510000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CERF@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: What is a window (was: A New TCP Retransmission Algorithm) Message-ID: <[A.ISI.EDU]21-Apr-87.07:51:49.CERF> Date: Tue, 21-Apr-87 06:51:00 EST Article-I.D.: <[A.ISI.EDU]21-Apr-87.07:51:49.CERF> Posted: Tue Apr 21 06:51:00 1987 Date-Received: Wed, 22-Apr-87 02:57:27 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Mike, While it is true that the ARPANET does not very many messages, when it did, the NCP connections got hung up either because of flow control confusion (lost allocates) or lost messages which were not retransmitted at the NCP level. It was that observation, plus the addition of more lossy nets such as Ethernet and packet radio that motivated many of the TCP features. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987042103510000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 21 Apr 87 04:52:25-PDT Date: 21 Apr 1987 07:51-EDT Sender: CERF@A.ISI.EDU Subject: Re: What is a window (was: A New TCP Retransmission Algorithm) From: CERF@A.ISI.EDU To: brescia@CCV.BBN.COM Cc: TCP-IP@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]21-Apr-87 07:51:49.CERF> In-Reply-To: The message of 20 Apr 87 22:22:47 D (Mon) from Mike Brescia Mike, While it is true that the ARPANET does not very many messages, when it did, the NCP connections got hung up either because of flow control confusion (lost allocates) or lost messages which were not retransmitted at the NCP level. It was that observation, plus the addition of more lossy nets such as Ethernet and packet radio that motivated many of the TCP features. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704211305.a027501@Huey.UDEL.EDU] <1987042108054800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP in ISO Message-ID: <8704211305.a027501@Huey.UDEL.EDU> Date: Tue, 21-Apr-87 13:05:48 EST Article-I.D.: Huey.8704211305.a027501 Posted: Tue Apr 21 13:05:48 1987 Date-Received: Wed, 22-Apr-87 04:31:13 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Thomas, An incoming packet, no matter what its protocol or port, with source address a broadcast address, has been formally declared a Chernobyl Packet, since it can lead to Ethernet meltdown. Your somarter gateway (and mine, too, after encountering these things) includes these things in the martian filter, which unceremoneously simply dumps them on the floor of a containment vessel. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [288@kuling.UUCP] <1987042110244700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: victor@kuling.UUCP (Bjorn Victor) Newsgroups: comp.protocols.tcp-ip Subject: Interpreting RFC 793 Message-ID: <288@kuling.UUCP> Date: Tue, 21-Apr-87 15:24:47 EST Article-I.D.: kuling.288 Posted: Tue Apr 21 15:24:47 1987 Date-Received: Thu, 23-Apr-87 04:49:40 EST Reply-To: victor@kuling.UUCP (Bjorn Victor) Distribution: world Organization: Department of Computer Systems, Uppsala University, Sweden Lines: 26 As I'm working on a TCP implementation, I have a question on the interpretation of RFC 793 (please look in your copy): On page 73 (Segment Arrives, otherwise clause, ACK bit clause), in state FIN-WAIT-1, it says "..., if our FIN is now acknowledged then enter FIN-WAIT-2 and continue processing in that state." On page 75 (Segment Arrives, otherwise clause, FIN bit clause), in state FIN-WAIT-1, it says "If our FIN has been ACKed (perhaps in this segment), then enter TIME-WAIT, ..." Now, could somebody please explain how we could possibly "execute" the quoted sentence on page 75? If our FIN *was* ACKed, we're no longer in the FIN-WAIT-1 state!? Also, if someone could point me to a more formal description of TCP, I'd be more than happy. --Bjorn Victor UUCP: {mcvax,seismo}!enea!kuling!victor Dept. of Computer Systems ARPA: Victor%Carmen.UU.SE@Seismo.CSS.GOV, Uppsala University, SWEDEN victor%kuling.UU.SE@Seismo.CSS.GOV -- --Bjorn Victor UUCP: {mcvax,seismo}!enea!kuling!victor Dept. of Computer Systems ARPA: Victor%Carmen.UU.SE@Seismo.CSS.GOV, Uppsala University, SWEDEN victor%kuling.UU.SE@Seismo.CSS.GOV ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987042111510000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Wed 22 Apr 87 02:14:01-PDT Received: from CERNVAX.BITNET by wiscvm.wisc.edu ; Wed, 22 Apr 87 04:13:42 CDT Received: from cernvax.UUCP (cernvax) by mint.cern (cernvax) (4.12/3.14) id AA20413; Wed, 22 Apr 87 08:32:37 +0200 Received: by cernvax.UUCP (4.12/4.7) id AA09316; Wed, 22 Apr 87 08:32:19 +0200 Received: by hslrswi.hasler (5.51.3/5.14) id AA17346; Wed, 22 Apr 87 06:09:32 +0200 (MET) Return-Receipt-To: To: vu-vlsi@mvax.UUCP, liberty}!swatsun!schwartz@sun.uucp Path: hslrswi!cernvax!mcvax!seismo!esosun!ucsdhub!sdcsvax!ucbvax!A.ISI.EDU!CERF From: A.ISI.EDU!CERF%hslrswi.uucp%CERNVAX.BITNET@wiscvm.wisc.edu Newsgroups: mod.protocols.tcp-ip Subject: Re: What is a window (was: A New TCP Retransmission Algorithm) Message-Id: <[A.ISI.EDU]21-Apr-87.07.51:49.CERF> Date: 21 Apr 87 11:51:00 GMT References: Sender: ucbvax.BERKELEY.EDU!daemon%hslrswi.uucp%CERNVAX.BITNET@wiscvm.wisc.edu Distribution: world Organization: The ARPA Internet Lines: 9 Mike, While it is true that the ARPANET does not very many messages, when it did, the NCP connections got hung up either because of flow control confusion (lost allocates) or lost messages which were not retransmitted at the NCP level It was that observation, plus the addition of more lossy nets such as Ethernet and packet radio that motivated many of the TCP features. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[G.BBN.COM]21-Apr-87.18:12:38.CLYNN] <1987042112120000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CLYNN@G.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Re: A New TCP Retransmission Algorithm Message-ID: <[G.BBN.COM]21-Apr-87.18:12:38.CLYNN> Date: Tue, 21-Apr-87 17:12:00 EST Article-I.D.: <[G.BBN.COM]21-Apr-87.18:12:38.CLYNN> Posted: Tue Apr 21 17:12:00 1987 Date-Received: Wed, 22-Apr-87 06:16:51 EST References: <870420213143.005848@MIT-MULTICS.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 29 Sure, I'll admit to backing up the window, but not to doing it "illegally". The spec says in the "Managing the Window" section that there is an assumption that the window size is related to the currently available data buffer space available for the connection; that is in fact the case - the user/application supplies one or more buffers to be filled with data and the amount of space provided specifies the window. The spec also says in the "Data Communication" section that a Push requires that any data be placed into the user's buffer and the buffer returned to the user even if it is not full. Consequently, the window is reduced by the amount of unused space in the buffer returned to the user in response to a Push. Since there is justification in the spec for reducing the window, and the spec requires senders to deal with it, it is also used in one other case. If a packet is lost, as indicated by reception of several segments in the window but not at the left edge, the window is reduced to the right edge of the missing data to "encourage" the sender to retransmit the missing data and to "discourage" it from sending additional new data or from retransmitting data which was in fact received but couldn't be acked. (If the sender ignores the hint, which we might call a NAK, nothing goes wrong; the receiver will eventually send ICMP Source Quenches which shouldn't be ignored and if that doesn't work packets will be flushed.) This case can be viewed as a situation where the user has provided buffer space but it cannot be used due to the missing segment(s). If a connection is receiving something from the TCP at the other end, even "obsolete acknowledgements", why shouldn't it be kept "alive"? Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870421230233.317029@MIT-MULTICS.ARPA] <1987042113020000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JSLove@MIT-MULTICS.ARPA ("J. Spencer Love") Newsgroups: comp.protocols.tcp-ip Subject: Re: Re: A New TCP Retransmission Algorithm Message-ID: <870421230233.317029@MIT-MULTICS.ARPA> Date: Tue, 21-Apr-87 18:02:00 EST Article-I.D.: MIT-MULT.870421230233.317029 Posted: Tue Apr 21 18:02:00 1987 Date-Received: Thu, 23-Apr-87 03:09:55 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 49 By "illegally backing up the window," I mean sending an acknowledgement which decreases the offered window but which contains the same sequence number and acknowledgement fields as a previously transmitted acknowledgement. In this case, it appears to the sending TCP as if the acknowledgement arrived out of order. In other words, if two packets arrive with the same sequence and acknowledgement fields, the one which offers the larger window is held to be "more recent." Windows are discussed on pages 42 and 43 of RFC 793. While the behavior described above is not mandatory, it is strongly hinted at. In RFC 813, some discussion of "artificially closing the window" appears in context to refer to keeping the offered window edge fixed rather than backing it up, in order to avoid silly window syndrome. The specification does require that implementations cope with other implementations closing the window in other situations which they may be able to detect. However, it does not require that implementations actually repackage data on the retransmission queue, so this merely means that the implementations are required to cease forming new packets and withhold retransmissions. Since implementations should generally only retransmit the earliest unacknowledged packet, this merely prevents the formation of additional packets, not the delivery of packets already in flight. Thus, your description of the circumstances under which you close the window doesn't necessarily match my description of "illegal" behavior, but it is behavior which the specification describes as "strongly discouraged." In particular, discarding packets which are transmitted into your formerly offered window is a good example of shooting yourself in the foot. Timing out connections which are receiving "obsolete", or if you prefer, "redundant" acknowledgements while being unable to get the most recent packet acknowledged is similar to the zero window probe situation. It is clear that a connection sending into a zero window shouldn't time out as long as redundant ACKs are being received. If a connection sending into a nonzero window should also not time out when only receiving "old" ACKs, then what effect, if any, should this have on the retransmission backoff? In the zero window probe scenario, we don't back off the window probes geometrically, but rather retransmit them infrequently, perhaps every two minutes. This would combine with my previous proposal if the geometric backoff were maxed out at the zero window probe interval, and the receipt of any packet resets the unacknowledged packet counter without affecting the retransmission interval. Then the unacknowledged packet counter becomes the basis for timing out connections. (The unacknowledged packet counter is also not incremented if the retransmission timer is set for an interval of less than one second.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987042114120000> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Tue 21 Apr 87 15:16:07-PDT Date: 21 Apr 1987 18:12-EDT Sender: CLYNN@G.BBN.COM Subject: Re: Re: A New TCP Retransmission Algorithm From: CLYNN@G.BBN.COM To: JSLove@MIT-MULTICS.ARPA Cc: imagen!geof@DECWRL.DEC.COM, TCP-IP@SRI-NIC.ARPA Message-ID: <[G.BBN.COM]21-Apr-87 18:12:38.CLYNN> In-Reply-To: <870420213143.005848@MIT-MULTICS.ARPA> Sure, I'll admit to backing up the window, but not to doing it "illegally". The spec says in the "Managing the Window" section that there is an assumption that the window size is related to the currently available data buffer space available for the connection; that is in fact the case - the user/application supplies one or more buffers to be filled with data and the amount of space provided specifies the window. The spec also says in the "Data Communication" section that a Push requires that any data be placed into the user's buffer and the buffer returned to the user even if it is not full. Consequently, the window is reduced by the amount of unused space in the buffer returned to the user in response to a Push. Since there is justification in the spec for reducing the window, and the spec requires senders to deal with it, it is also used in one other case. If a packet is lost, as indicated by reception of several segments in the window but not at the left edge, the window is reduced to the right edge of the missing data to "encourage" the sender to retransmit the missing data and to "discourage" it from sending additional new data or from retransmitting data which was in fact received but couldn't be acked. (If the sender ignores the hint, which we might call a NAK, nothing goes wrong; the receiver will eventually send ICMP Source Quenches which shouldn't be ignored and if that doesn't work packets will be flushed.) This case can be viewed as a situation where the user has provided buffer space but it cannot be used due to the missing segment(s). If a connection is receiving something from the TCP at the other end, even "obsolete acknowledgements", why shouldn't it be kept "alive"? Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987042122120000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 23 Apr 87 03:52:50-PDT Received: from CERNVAX.BITNET by wiscvm.wisc.edu ; Thu, 23 Apr 87 05:52:15 CDT Received: from cernvax.UUCP (cernvax) by mint.cern (cernvax) (4.12/3.14) id AA26832; Thu, 23 Apr 87 11:28:32 +0200 Received: by cernvax.UUCP (4.12/4.7) id AA08946; Thu, 23 Apr 87 11:28:57 +0200 Received: by hslrswi.hasler (5.51.3/5.14) id AA26216; Thu, 23 Apr 87 11:06:22 +0200 (MET) Return-Receipt-To: To: e@hslrswi.UUCP, to@hslrswi.UUCP, the@hslrswi.UUCP, missing@hslrswi.UUCP, segment@hslrswi.UUCP Path: hslrswi!cernvax!mcvax!seismo!rutgers!mit-eddie!genrad!decvax!decwrl!ucbva From: G.BBN.COM!CLYNN%hslrswi.uucp%CERNVAX.BITNET@wiscvm.wisc.edu Newsgroups: mod.protocols.tcp-ip Subject: Re: Re: A New TCP Retransmission Algorithm Message-Id: <[G.BBN.COM]21-Apr-87.18.12:38.CLYNN> Date: 21 Apr 87 22:12:00 GMT References: <870420213143.005848@MIT-MULTICS.ARPA> Sender: ucbvax.BERKELEY.EDU!daemon%hslrswi.uucp%CERNVAX.BITNET@wiscvm.wisc.edu Distribution: world Organization: The ARPA Internet Lines: 29 Sure, I'll admit to backing up the window, but not to doing it "illegally". The spec says in the "Managing the Window" section that there is an assumption that the window size is related to the currently available data buffer space available for the connection; that is in fact the case - the user/application supplies one or more buffers to be filled with data and the amount of space provided specifies the window. The spec also says in the "Data Communication" section that a Push requires that any data be placed into the user's buffer and the buffer returned to the user even if it is not full. Consequently, the window is reduced by the amount of unused space in the buffer returned to the user in response to a Push. Since there is justification in the spec for reducing the window, and the spec requires senders to deal with it, it is also used in one other case. If a packet is lost, as indicated by reception of several segments in the window but not at the left edge, the window is reduced to the right edge of the missing data to "encourage" the sender to retransmit the missing data and to "discourage" it from sending additional new data or from retransmitting data which was in fact received but couldn't be acked. (If the sender ignores the hint, which we might call a NAK, nothing goes wrong; the receiver will eventually send ICMP Source Quenches which shouldn't be ignored and if that doesn't work packets will be flushed.) This case can be viewed as a situation where the user has provided buffer space but it cannot be used due to the missing segment(s). If a connection is receiving something from the TCP at the other end, even "obsolete acknowledgements", why shouldn't it be kept "alive"? Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870422-031521-3272@Xerox] <1987042200144200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: feldman%mycroft@GSWD-VMS.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Ken Olsen vs MAP Message-ID: <870422-031521-3272@Xerox> Date: Wed, 22-Apr-87 05:14:42 EST Article-I.D.: Xerox.870422-031521-3272 Posted: Wed Apr 22 05:14:42 1987 Date-Received: Thu, 23-Apr-87 23:38:06 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 53 GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV From: feldman%mycroft@gswd-vms.ARPA (Mike Feldman) To: TCP-IP@sri-nic.arpa Subject: Re: Ken Olsen vs MAP Return-Path: Redistributed: tcp-ip^.x Received: from SRI-NIC.ARPA by Xerox.COM ; 10 APR 87 15:29:50 PDT Received: from gswd-vms.ARPA by SRI-NIC.ARPA with TCP; Fri 10 Apr 87 06:49:15-PDT Received: from mycroft.GSD (mycroft.Gould.COM) by gswd-vms.ARPA (5.52/) Message-Id: <8704101349.AA14705@gswd-vms.ARPA> Original-Date: Fri, 10 Apr 87 07:47:18 CST GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV > The answer to your question is that the MAP people do not fully understand > all the sources of probabilistic delay that you catalog. ... > > In their defense however, they have always been concerned about the situation > which might arise when a failure in a manufacturing process causes 500 > sensors to all start sending emergency warning messages at the same instant. > This can lead to lockup on an Ethernet in a way which should not occur on a > token bus. I was envolved in designing an early token bus process control system for a control system manufacturer in '69 - '70, when I first saw the Ethernet spec and articles describing it. I was a junior software engineer at the time, and I suggested to the powers-that-be that Ethernet was much simpler to implement, and that we were already doing it for the token recovery sequence (silence on the wire). It's my opinion that it was dogma among communications engineers even then that you needed deterministic bus access time and guaranteed throughput for control system muxes. There were two cases where the system had to perform under Ethernet-busting loads. One was during customer accecptance testing, and the other was when the reactor pressure relief valve failed open. I got angry reactions when I suggested Ethernet would be cheaper and easier to build and would have better performance almost all of the time. They were even more irritated when I suggested the if determinism and known throughput were so important that they use time division multiplexing. These days, there is a lot of support among control system suppliers for MAP. There hope is that the semiconductor industry will see a large market and implement all the hard, expensive lower layers in silicon, because so far it's been too expensive for each system house to develop one that's a comercial and technical success. It might happen, but they still won't get the deterministic round trip message delay needed to implement stable fast feedback loops. These opinions are my own. Mike Feldman Gould Computer Systems Division 1101 East University Avenue Urbana, IL 61801 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[G.BBN.COM]22-Apr-87.09:17:40.CLYNN] <1987042203170000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CLYNN@G.BBN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Interpreting RFC 793 Message-ID: <[G.BBN.COM]22-Apr-87.09:17:40.CLYNN> Date: Wed, 22-Apr-87 08:17:00 EST Article-I.D.: <[G.BBN.COM]22-Apr-87.09:17:40.CLYNN> Posted: Wed Apr 22 08:17:00 1987 Date-Received: Fri, 24-Apr-87 00:01:39 EST References: <288@kuling.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 Bjorn, Technically, you can't; in fact, the next paragraph on page 75, FIN-WAIT-2, says to do exactly the same thing as does the FIN-WAIT-1 state when the FIN has been acked. I view the situation as an explicit restatement of robustness -- a correct implementation shouldn't get into that state, but if it does (software implementations have been known to contain bugs) then there is a way to recover. Maybe there should be a statement to the effect that you shouldn't be here, write an entry into the system error log. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987042205170000> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Wed 22 Apr 87 06:17:26-PDT Date: 22 Apr 1987 09:17-EDT Sender: CLYNN@G.BBN.COM Subject: Re: Interpreting RFC 793 From: CLYNN@G.BBN.COM To: mcvax!enea!kuling!victor@SEISMO.CSS.GOV Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[G.BBN.COM]22-Apr-87 09:17:40.CLYNN> In-Reply-To: <288@kuling.UUCP> Bjorn, Technically, you can't; in fact, the next paragraph on page 75, FIN-WAIT-2, says to do exactly the same thing as does the FIN-WAIT-1 state when the FIN has been acked. I view the situation as an explicit restatement of robustness -- a correct implementation shouldn't get into that state, but if it does (software implementations have been known to contain bugs) then there is a way to recover. Maybe there should be a statement to the effect that you shouldn't be here, write an entry into the system error log. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [206@cos.COM] <1987042208430000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: howard@COS.COM (Howard C. Berkowitz) Newsgroups: comp.protocols.tcp-ip Subject: Re: Submission for mod-protocols-tcp-ip Message-ID: <206@cos.COM> Date: Wed, 22-Apr-87 13:43:00 EST Article-I.D.: cos.206 Posted: Wed Apr 22 13:43:00 1987 Date-Received: Fri, 24-Apr-87 05:26:24 EST References: <8704190722.AA17818@uw-apl> Organization: Corporation for Open Systems, McLean, VA Lines: 33 Summary: Even more refinement In article <8704190722.AA17818@uw-apl>, srg@quick.UUCP writes: > Path: quick!srg > From: srg@quick.UUCP (Spencer Garrett) > Subject: Re: Time RFC 868 > Summary: RTT can be estimated with 2 packets, not 4 > > In article <194@cos.COM>, howard@cos.UUCP (Howard Berkowitz) writes: > > the slave RETRANSMITS what it received. The master > > then calculates the difference (in time units) between > > what it sent and what the slave received, and sends > > that as a correction factor. ... > This same protocol could be done with 2 packets instead of 4. The > originator (master) should estimate the round-trip time (RTT) using > its local clock instead of asking the responder (slave) to perform > that function. The accuracy of the setting of the local clock is of > no consequence. Only a time difference is needed. Good suggestion. If, however, both the master and the slave compute the time difference, it is possible to isolate the time the slave needs to set the clock. This is probably trivial, but is a refinement. The round trip time contains three components: outbound network delay slave processing inbound network delay outbound (in the dial net) equals inbound; this is not necessarily true in all networks. We have not considered in this the effect of error control. Clearly, in a real-time, time-stamped application such as this, you do _NOT_ want to retransmit either a master or slave time synchronization message! A new one must be sent! ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704230120.AA00229@apolling.imagen.uucp] <1987042215203300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@apolling.UUCP (Geof Cooper) Newsgroups: comp.protocols.tcp-ip Subject: Re: Re: Re: A New TCP Retransmission Algorithm Message-ID: <8704230120.AA00229@apolling.imagen.uucp> Date: Wed, 22-Apr-87 20:20:33 EST Article-I.D.: apolling.8704230120.AA00229 Posted: Wed Apr 22 20:20:33 1987 Date-Received: Fri, 24-Apr-87 06:08:23 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.DEC.COM Distribution: world Organization: The ARPA Internet Lines: 11 > No, you don't understand what I meant by "closing a window". I am > asking, does anyone admit to taking away a window already granted. That Ooooooohhhhhhh! Sorry. Never Mind. I just like to flame on that particular point. We don't close the window in the way that you mention. - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704230904.AA26173@hslrswi.hasler] <1987042301344600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: uucp@hslrswi.UUCP (Uucp) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8704230904.AA26173@hslrswi.hasler> Date: Thu, 23-Apr-87 06:34:46 EST Article-I.D.: hslrswi.8704230904.AA26173 Posted: Thu Apr 23 06:34:46 1987 Date-Received: Sat, 25-Apr-87 09:24:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 $ Path: hslrswi!cernvax!mcvax!seismo!esosun!ucsdhub!sdcsvax!ucbvax!hslrswi.UUCP!A From: A.ISI.EDU!CERF@hslrswi.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: What is a window (was: A New TCP Retransmission Algorithm) Message-ID: <[A.ISI.EDU]21-Apr-87.07.51:49.CERF> Date: 21 Apr 87 11:51:00 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Mike, While it is true that the ARPANET does not very many messages, when it did, the NCP connections got hung up either because of flow control confusion (lost allocates) or lost messages which were not retransmitted at the NCP level It was that observation, plus the addition of more lossy nets such as Ethernet and packet radio that motivated many of the TCP features. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704231610.AA16206@ucbvax.Berkeley.EDU] <1987042306123500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jon@CS.UCL.AC.UK (Jon Crowcroft) Newsgroups: comp.protocols.tcp-ip Subject: laws and things Message-ID: <8704231610.AA16206@ucbvax.Berkeley.EDU> Date: Thu, 23-Apr-87 11:12:35 EST Article-I.D.: ucbvax.8704231610.AA16206 Posted: Thu Apr 23 11:12:35 1987 Date-Received: Sat, 25-Apr-87 09:59:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 just out of interest: 1. I just noticed a fragment of 4.2BSD kernel/comms source on this list. I hope Berkeley know it goes out to the UK Academic community. 2. The Whois service from NIC contains info about some UK users. If the system is used (and rfinger similarly) in the UK it is in contravention of the Data Protection Act unless the data with reasons for holding it are registered with the "Data Protection Officer" (a sort of Ombudsman). [THIS ONLY ENFORCABLE IF THE DATA IS HELD IN THE UK, BECAUSE THE ACT DOES NOT COMPREHEND OF NETWORKS]. Jon ("How many ISO standard bits does it take to define true"). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704231336.a020393@Huey.UDEL.EDU] <1987042309361600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Submission for mod-protocols-tcp-ip Message-ID: <8704231336.a020393@Huey.UDEL.EDU> Date: Thu, 23-Apr-87 13:36:16 EDT Article-I.D.: Huey.8704231336.a020393 Posted: Thu Apr 23 13:36:16 1987 Date-Received: Tue, 28-Apr-87 02:49:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 Howard, If you don't mind unslinging the big guns, see RFC-958 for techniques to accurately measure roundtrip delay and clock offset, which is equivalent to one-way delays. Improve sample estimates using a median filter as described in RFC-956. Improve statistical estimates by including all TCP segments, not just those allowing a single roundtrip estimate at a time. This last requires state variables for all outstanding segments that have not been ACKed. This topic has come up about once a year since early this decade. The last volley on this list (before Van Jacobson kicked off the current game) was between John Nagle and myself. My conclusion after all this is that the implementor should think more like a statistician and less like a protocol engineer. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987042318265000> Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Thu 23 Apr 87 08:53:44-PDT Received: from ucl-cs-pyr1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa08283; 23 Apr 87 16:51 BST To: tcp-ip@sri-nic.arpa Subject: laws and things Date: Thu, 23 Apr 87 16:46:50 +0100 From: Jon Crowcroft just out of interest: 1. I just noticed a fragment of 4.2BSD kernel/comms source on this list. I hope Berkeley know it goes out to the UK Academic community. 2. The Whois service from NIC contains info about some UK users. If the system is used (and rfinger similarly) in the UK it is in contravention of the Data Protection Act unless the data with reasons for holding it are registered with the "Data Protection Officer" (a sort of Ombudsman). [THIS ONLY ENFORCABLE IF THE DATA IS HELD IN THE UK, BECAUSE THE ACT DOES NOT COMPREHEND OF NETWORKS]. Jon ("How many ISO standard bits does it take to define true"). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704271843.AA26211@ucbvax.Berkeley.EDU] <1987042411275800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: Interpreting RFC 793 Message-ID: <8704271843.AA26211@ucbvax.Berkeley.EDU> Date: Fri, 24-Apr-87 15:27:58 EDT Article-I.D.: ucbvax.8704271843.AA26211 Posted: Fri Apr 24 15:27:58 1987 Date-Received: Tue, 28-Apr-87 03:06:50 EDT References: <288@kuling.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 A great deal of time and trouble went into making "MIL-STD-1778" ("Military Standard Transmission Control Protocol") APPEAR to be more formal than the RFC TCP spec. It would be interesting to learn if a relatively neutral observer thought it actually IS more formal-- and, as a purist's point, whether that makes it more useful, since I doubt there's an a priori correlation between formality and utility. Given that page ii says that "benefical comments" can go to Defense Communications Agency ATTN: J110 1860 Wiehle Avenue Reston, VA 22090 and that I don't see any "ordering information" elsewhere (not that it's necessarily not there, just that I don't see it), presumably a request for a copy could go to that address as well with some chance of being fulfilled. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987042412275800> Mail-From: VIVIAN created at 27-Apr-87 11:18:51 Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sat 25 Apr 87 00:50:45-PDT Date: 24 Apr 1987 16:27:58 EDT Subject: Re: Interpreting RFC 793 From: Michael Padlipsky To: mcvax!enea!kuling!victor@SEISMO.CSS.GOV (Bjorn Victor) cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: <288@kuling.UUCP> ReSent-Date: Mon 27 Apr 87 11:17:00-PDT ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12297899030.34.VIVIAN@SRI-NIC.ARPA> A great deal of time and trouble went into making "MIL-STD-1778" ("Military Standard Transmission Control Protocol") APPEAR to be more formal than the RFC TCP spec. It would be interesting to learn if a relatively neutral observer thought it actually IS more formal-- and, as a purist's point, whether that makes it more useful, since I doubt there's an a priori correlation between formality and utility. Given that page ii says that "benefical comments" can go to Defense Communications Agency ATTN: J110 1860 Wiehle Avenue Reston, VA 22090 and that I don't see any "ordering information" elsewhere (not that it's necessarily not there, just that I don't see it), presumably a request for a copy could go to that address as well with some chance of being fulfilled. cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704242338.AA01718@hpltyj] <1987042414383100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tai%hpltyj@HPLABS.HP.COM (Tai Jin) Newsgroups: comp.protocols.tcp-ip Subject: ICMP echo Message-ID: <8704242338.AA01718@hpltyj> Date: Fri, 24-Apr-87 18:38:31 EDT Article-I.D.: hpltyj.8704242338.AA01718 Posted: Fri Apr 24 18:38:31 1987 Date-Received: Tue, 28-Apr-87 02:52:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 I have a question for those experienced in using ICMP echo for debugging. Does the spec specify how a system is supposed to reply to an echo? One implementation is to turn around and send the reply to the link address of the sender (or gateway). The other is to make a local routing decision before sending the reply. Which is better? Another question is whether a system should reply to an ICMP echo sent to a broadcast address. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [1840@enea.UUCP] <1987042502323000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sten@enea.UUCP (Sten Folkerman) Newsgroups: comp.protocols.tcp-ip,comp.sources.wanted Subject: TCP/IP source wanted Message-ID: <1840@enea.UUCP> Date: Sat, 25-Apr-87 06:32:30 EDT Article-I.D.: enea.1840 Posted: Sat Apr 25 06:32:30 1987 Date-Received: Sun, 26-Apr-87 21:17:49 EDT Reply-To: sten@enea.UUCP (Sten Folkerman) Distribution: world Organization: ENEA DATA Svenska AB, Sweden Lines: 6 I would be grateful if anyone could tell me where to find (=buy) source code packet comtaining ip, tcp, udp, telnet, ftp, and preferably rlogin, rsh, rcp. We will port it to a 680[12]0 machine running System V. The network is some kind of ethernet (I guess the main job is to implement the driver). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704271856.AA26614@ucbvax.Berkeley.EDU] <1987042507403700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: LYNCH@A.ISI.EDU (Dan Lynch) Newsgroups: comp.protocols.tcp-ip Subject: Agenda for Net Management Meeting Message-ID: <8704271856.AA26614@ucbvax.Berkeley.EDU> Date: Sat, 25-Apr-87 11:40:37 EDT Article-I.D.: ucbvax.8704271856.AA26614 Posted: Sat Apr 25 11:40:37 1987 Date-Received: Tue, 28-Apr-87 03:03:29 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 25 Here is the final agenda for the Network Management Working Group meeting on May 5th at TECHMART in Santa Clara. The room got changed to Room 229 to accomodate a larger audience. Please let me know if you plan to attend. Agenda for Network Management Working Group 9:00 Welcome -- Dan Lynch (ACE) 9:05 Background and Objectives -- Stan Ames (Mitre) 9:15 Management Framework -- Lee LaBarre (Mitre) 9:45 User Concerns -- Lynch 10:00 Practical Network Management Requirements -- Eric Benhamou (Bridge) 10:30 Break 10:45 Strawman System Management Protocol Architecture -- LaBarre 11:15 Protocol for Management Exchanges -- Al Sciacca (BBN) 12:00 Lunch 1:30 IETF Control,Monitoring WG Activities -- Craig Partridge (BBN) 2:00 TCP/IP Management Parameters -- Glenn Trewitt (Stanford) 2:30 Break 2:45 Discussion: Scope, Goals, Schedule of Project (Ames) 4:00 Adjourn ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987042508403700> Mail-From: VIVIAN created at 27-Apr-87 11:20:17 Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sat 25 Apr 87 09:44:40-PDT Date: 25 Apr 1987 12:40:37 EDT Subject: Agenda for Net Management Meeting From: Dan Lynch To: tcp-ip@SRI-NIC.ARPA cc: LYNCH@A.ISI.EDU, sra@MITRE-BEDFORD.ARPA, cel@MITRE-BEDFORD.ARPA ReSent-Date: Mon 27 Apr 87 11:17:47-PDT ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12297899174.34.VIVIAN@SRI-NIC.ARPA> Here is the final agenda for the Network Management Working Group meeting on May 5th at TECHMART in Santa Clara. The room got changed to Room 229 to accomodate a larger audience. Please let me know if you plan to attend. Agenda for Network Management Working Group 9:00 Welcome -- Dan Lynch (ACE) 9:05 Background and Objectives -- Stan Ames (Mitre) 9:15 Management Framework -- Lee LaBarre (Mitre) 9:45 User Concerns -- Lynch 10:00 Practical Network Management Requirements -- Eric Benhamou (Bridge) 10:30 Break 10:45 Strawman System Management Protocol Architecture -- LaBarre 11:15 Protocol for Management Exchanges -- Al Sciacca (BBN) 12:00 Lunch 1:30 IETF Control,Monitoring WG Activities -- Craig Partridge (BBN) 2:00 TCP/IP Management Parameters -- Glenn Trewitt (Stanford) 2:30 Break 2:45 Discussion: Scope, Goals, Schedule of Project (Ames) 4:00 Adjourn ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987042700250000> Mail-From: VIVIAN created at 28-Apr-87 00:18:24 Return-Path: Received: from afotec (AFOTEC.ARPA) by SRI-NIC.ARPA with TCP; Sun 26 Apr 87 09:55:02-PDT Date: 26 Apr 87 10:53:00 GMT+492:48 From: Subject: Mail List Address Problem? To: "tcp-ip-request" Reply-To: ReSent-Date: Tue 28 Apr 87 00:17:16-PDT ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12298041075.16.VIVIAN@SRI-NIC.ARPA> I recently sent the message below to TCP-IP-RELAY@SRI-NIC.ARPA. Apparently it never reached the list because I never saw it on the list. We are quite interested in knowing if anyone else has had a similar problem so I am anxious to get this message out on the mail list. Was the address incorrect? Perhaps, I was caught by some momentary glitch in our mailer. Whatever the reason, I would greatly appreciate knowing if this message was addressed wrong and what the correct address for the TCP-IP mail list is; in addition to getting this message on the mail list. Thank you. Steve Fritts FRITTS@AFOTEC.ARPA -------------------------------------------------------------------------------- We have recently experienced a problem in bringing up a new DDN host and I would like to find out if others have had a similar experience. We installed an ACC 6250 board on a DEC VAX 11/785 running VMS. The board came with an RS-232 port on it for connection to a modem. The PSN we were connecting to was about 4 miles away. We used a 9.6KB circuit to get to the PSN and connected to an RS-232 port on the BBN C/30. The problem occurred when we tried to come up on the network. The Network Operations Center was able to check all the way through the 9.6KB circuit and loop back from the modem sitting next to our VAX; they said everything looked okay. We could bring up the ACC 6250 board in loopback mode and it would recognize itself; but no matter what we did, it was not able to come up on the network. The problem was finally resolved when we exchanged the ACC 6250 board with the RS-232 port for the same ACC 6250 board with an RS-422 port. We installed the board, put in an RS-422 to RS-232 converter box, then hooked the RS-232 cable to the modem and it worked perfectly! QUESTION: Has anyone else had a similar experience with ACC's 6250 board for standard X.25 DDN host connection when it is configured with an RS-232 port for connection to a PSN using modems? We would very much like to know if ours was a singular experience. You can reply to my mail box or put it on this mail list. Thank you. STEVE FRITTS FRITTS@AFOTEC.ARPA ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704272025.AA00279@braden.isi.edu] <1987042712254300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP echo Message-ID: <8704272025.AA00279@braden.isi.edu> Date: Mon, 27-Apr-87 16:25:43 EDT Article-I.D.: braden.8704272025.AA00279 Posted: Mon Apr 27 16:25:43 1987 Date-Received: Wed, 29-Apr-87 01:06:42 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 34 Hi. You have asked a question about ICMP Echo semantics that ought to be, but isn't, contained in the RFC985-revision. Sigh. Here is my totally-prejudiced view on how ICMP Echo should behave (it is the way my own TCP/IP code implemented ICMP Echo, of course!). Anyone who wants to beat me up about this should do so now... otherwise, this interpretation is likely to find its way into the gateway specification RFC. A host or gateway D that receives an ICMP Echo Request addressed to itself from host S should send an ICMP Echo Reply back to S, using the following rules: 1. If the Echo Request contained no source route, the Reply should be sent to S using the normal routing rules of D. As a result, the Reply may come back by a different path than the Request took. 2. If the Echo Request did contain a source route, the Echo Reply will be sent using the return-route built up in the source-routing option of the Echo Request. As a result, it is not possible to force a route for the Reply which is different from the route used for the Echo. A result of these rules is that ICMP Echo can be used to sample the complete round-trip path which any other higher-level protocol e.g., TCP) will use for its data and ACK packets between D and S. The rules generally follow from the assumption that ICMP is a protocol parallel to TCP and above IP, and needs no special routing mechanism. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12297949247.37.VIVIAN@SRI-NIC.ARPA] <1987042714525100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Vivian@SRI-NIC.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: TCP-IP is being filtered Message-ID: <12297949247.37.VIVIAN@SRI-NIC.ARPA> Date: Mon, 27-Apr-87 18:52:51 EDT Article-I.D.: SRI-NIC.12297949247.37.VIVIAN Posted: Mon Apr 27 18:52:51 1987 Date-Received: Wed, 29-Apr-87 01:10:05 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Someone is remailing the TCP-IP list back to itself. Until it stops (it's been happening to several large distribution lists for the past week or so), I'm going to be hand filtering mail to TCP-IP. Therefore there will be an additional delay between the time you send messages to TCP-IP and the time you can expect to see them. Hopefully things will be fixed soon, so I can let the list go back to direct distribution. Vivian Neou ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[G.BBN.COM]27-Apr-87.18:54:27.CLYNN] <1987042714540000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CLYNN@G.BBN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP echo Message-ID: <[G.BBN.COM]27-Apr-87.18:54:27.CLYNN> Date: Mon, 27-Apr-87 18:54:00 EDT Article-I.D.: <[G.BBN.COM]27-Apr-87.18:54:27.CLYNN> Posted: Mon Apr 27 18:54:00 1987 Date-Received: Wed, 29-Apr-87 00:43:18 EDT References: <8704272025.AA00279@braden.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 30 Bob's statement is a nice start but doesn't mention anything about other options. I would like to suggest that it would be more generally useful if a source route was NOT inverted by the receiver of an echo request when it formed the echo reply (... that's the way I implemented it ...). Maybe there should be two versions of source route ... I would argue that the simplest implementation is the most useful -- just change echo request to echo reply and switch the IP source and destination and send the packet back without changing the options in any way (except, of course, for the processing that IP is required to perform). By returning the options (which some implimentations don't now do) one gets to see, for example, information recorded in a record route option (possibly in addition to a source route) and in a timestamp option. If you want the time out and back along a specific route (Bob's case) you can source route the packet out and back to yourself, get the timestamp info, and have your host return the packet to you (which should be local delivery). By not returning along a recorded route one can (if the gateways implement IP ...) find what route is being used to reach you from point X in the internet. It might also be nice to include in this discussion the suggestion (not originally mine) that the pharse in the ICMP spec (4th paragraph, page 1) "no ICMP messages are sent about ICMP messages" be amended to "no ICMP messages are sent about ICMP error messages"; thus allowing one to get error messages about ICMP ECHO, TIMESTAMP, INFORMATION, etc., and their corresponding REPLYs. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987042714540001> Mail-From: VIVIAN created at 27-Apr-87 16:53:32 Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Mon 27 Apr 87 15:56:20-PDT Date: 27 Apr 1987 18:54-EDT Sender: CLYNN@G.BBN.COM Subject: Re: ICMP echo From: CLYNN@G.BBN.COM To: braden@VENERA.ISI.EDU Cc: tai%hpltyj@HPLABS.HP.COM, postel@VENERA.ISI.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[G.BBN.COM]27-Apr-87 18:54:27.CLYNN> In-Reply-To: <8704272025.AA00279@braden.isi.edu> ReSent-Date: Mon 27 Apr 87 16:51:29-PDT ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12297959923.37.VIVIAN@SRI-NIC.ARPA> Bob's statement is a nice start but doesn't mention anything about other options. I would like to suggest that it would be more generally useful if a source route was NOT inverted by the receiver of an echo request when it formed the echo reply (... that's the way I implemented it ...). Maybe there should be two versions of source route ... I would argue that the simplest implementation is the most useful -- just change echo request to echo reply and switch the IP source and destination and send the packet back without changing the options in any way (except, of course, for the processing that IP is required to perform). By returning the options (which some implimentations don't now do) one gets to see, for example, information recorded in a record route option (possibly in addition to a source route) and in a timestamp option. If you want the time out and back along a specific route (Bob's case) you can source route the packet out and back to yourself, get the timestamp info, and have your host return the packet to you (which should be local delivery). By not returning along a recorded route one can (if the gateways implement IP ...) find what route is being used to reach you from point X in the internet. It might also be nice to include in this discussion the suggestion (not originally mine) that the pharse in the ICMP spec (4th paragraph, page 1) "no ICMP messages are sent about ICMP messages" be amended to "no ICMP messages are sent about ICMP error messages"; thus allowing one to get error messages about ICMP ECHO, TIMESTAMP, INFORMATION, etc., and their corresponding REPLYs. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704280104.a006354@Huey.UDEL.EDU] <1987042721045500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP echo Message-ID: <8704280104.a006354@Huey.UDEL.EDU> Date: Tue, 28-Apr-87 01:04:55 EDT Article-I.D.: Huey.8704280104.a006354 Posted: Tue Apr 28 01:04:55 1987 Date-Received: Wed, 29-Apr-87 05:42:25 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 29 Bob, Your model is the one I understand to be in common use, although only the TOPS-20 is known to me to implement the return route in the way you suggest (are there others?). However, there is still the question of options, such as security, etc. Your model, taken prima facie, implies the respondent simply flips the IP addresses and source-route and tosses it back in the net, presumably leaving the options alone. I think this is the right thing, but believe it should be explicitly stated. On the question of reciprocal routes, unless the ICMP Echo message was explicitly source-routed, the return route will not necessarily fly back the reciprocal path. Ordinarily one might expect this and, indeed, there are many well-behaved segments of the Internet where this is so. However, in the flooding NSF swamps it has been my observation that routes are reciprocal only sometimes. In such cases it would be useful to have an enriched record-route facility. A sneaky way to do this might be to simply continue the record-route past the echo server. A final tid: Should the TTL be reset at the echo server? If not, the sender would have a non-ambiguous way to measure the number of hops. He could, of course, also use record-route. Finally, how about a new ICMP Echo/Echo Reply message that operates as the present one, but where the echo server captures the IP header, etc., in the same way as ordinary ICMP error messages before returning to sender? Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704280109.a007053@Huey.UDEL.EDU] <1987042721094600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP echo Message-ID: <8704280109.a007053@Huey.UDEL.EDU> Date: Tue, 28-Apr-87 01:09:46 EDT Article-I.D.: Huey.8704280109.a007053 Posted: Tue Apr 28 01:09:46 1987 Date-Received: Wed, 29-Apr-87 05:42:55 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Charlie, As far as I know, your suggestion (originally attributed to Mike Brescia, I believe) to amend the spec to allow error messages about non-error messages was approved for incorporation into the MILSTD protocol documents some time ago. In point of fact, every gateway I know of, including the BBN LSI-11 and Butterflies, fuzzbugs and others, in fact operate as you suggest. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704280731.AA13877@ucbvax.Berkeley.EDU] <1987042723323900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: fritts@AFOTEC.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Mail List Address Problem? Message-ID: <8704280731.AA13877@ucbvax.Berkeley.EDU> Date: Tue, 28-Apr-87 03:32:39 EDT Article-I.D.: ucbvax.8704280731.AA13877 Posted: Tue Apr 28 03:32:39 1987 Date-Received: Wed, 29-Apr-87 05:37:28 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Distribution: world Organization: The ARPA Internet Lines: 41 I recently sent the message below to TCP-IP-RELAY@SRI-NIC.ARPA. Apparently it never reached the list because I never saw it on the list. We are quite interested in knowing if anyone else has had a similar problem so I am anxious to get this message out on the mail list. Was the address incorrect? Perhaps, I was caught by some momentary glitch in our mailer. Whatever the reason, I would greatly appreciate knowing if this message was addressed wrong and what the correct address for the TCP-IP mail list is; in addition to getting this message on the mail list. Thank you. Steve Fritts FRITTS@AFOTEC.ARPA -------------------------------------------------------------------------------- We have recently experienced a problem in bringing up a new DDN host and I would like to find out if others have had a similar experience. We installed an ACC 6250 board on a DEC VAX 11/785 running VMS. The board came with an RS-232 port on it for connection to a modem. The PSN we were connecting to was about 4 miles away. We used a 9.6KB circuit to get to the PSN and connected to an RS-232 port on the BBN C/30. The problem occurred when we tried to come up on the network. The Network Operations Center was able to check all the way through the 9.6KB circuit and loop back from the modem sitting next to our VAX; they said everything looked okay. We could bring up the ACC 6250 board in loopback mode and it would recognize itself; but no matter what we did, it was not able to come up on the network. The problem was finally resolved when we exchanged the ACC 6250 board with the RS-232 port for the same ACC 6250 board with an RS-422 port. We installed the board, put in an RS-422 to RS-232 converter box, then hooked the RS-232 cable to the modem and it worked perfectly! QUESTION: Has anyone else had a similar experience with ACC's 6250 board for standard X.25 DDN host connection when it is configured with an RS-232 port for connection to a PSN using modems? We would very much like to know if ours was a singular experience. You can reply to my mail box or put it on this mail list. Thank you. STEVE FRITTS FRITTS@AFOTEC.ARPA ec.v ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987042801561000> Received: from ACC-SB-UNIX.ARPA by SRI-NIC.ARPA with TCP; Tue 28 Apr 87 08:55:56-PDT Received: by ACC-SB-UNIX.ARPA (5.51/4.7) id AA26447; Tue, 28 Apr 87 08:56:10 PDT Date: Tue, 28 Apr 87 08:56:10 PDT From: gary@ACC-SB-UNIX.ARPA (Gary Krall) Message-Id: <8704281556.AA26447@ACC-SB-UNIX.ARPA> To: tcp-ip-rebroadcast@SRI-NIC.ARPA **All users of ACC's ACP 6250 and ACP 5250 boards** ACC has found a design problem with the RS232 electrical interface connection, and an ECO has been implemented to address this problem. Because this problem can cause unreliable operation, ACC recommends the return of the ACP processor board, ribbon cable and distribution panel for up-dating. Please note that the ECO will require modification of both the processor board and distribution panel, therefore please return the complete system. This is a no cost up-date to the equipment. Concerned users should call (805) 963-9431 (in California, Hawaii, or outside the U.S.) or (800) 222-7308 to obtain a return authorization (RA) number. All Service One customers will be provided with replacement units on a priority basis to minimize the impact of this update. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987042803270000> Mail-From: VIVIAN created at 29-Apr-87 17:18:51 Received: from pescadero.stanford.edu by SRI-NIC.ARPA with TCP; Tue 28 Apr 87 11:14:54-PDT Received: by pescadero.stanford.edu with Sendmail; Tue, 28 Apr 87 11:10:25 pdt Date: 28 Apr 1987 10:27-PDT From: Steve Deering Subject: Re: ICMP echo To: tcp-ip@sri-nic.ARPA Cc: Mills@udel.edu, CLYNN@g.bbn.com, tai%hpltyj@hplabs.hp.com, braden@venera.isi.edu, postel@venera.isi.edu Message-Id: <87/04/28 1027.510@pescadero.stanford.edu> ReSent-Date: Wed 29 Apr 87 17:16:09-PDT ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12298488699.42.VIVIAN@SRI-NIC.ARPA> From: CLYNN@G.BBN.COM : I would argue that the simplest implementation is the most useful -- just change echo request to echo reply and switch the IP source and destination and send the packet back... From: Mills@UDEL.EDU : Your [Bob Braden's] model, taken prima facie, implies the respondent simply flips the IP addresses and source-route and tosses it back in the net, presumably leaving the options alone. I think this is the right thing, but believe it should be explicitly stated. Although the ICMP spec does say to simply reverse the IP source and destination addresses, that is incorrect when the original IP destination is a multicast or broadcast address. In that case, the IP source address of the Echo Reply (or Timestamp Reply, Information Reply, or Address Mask Reply) should be set to one of the replying host's individual addresses (presumably the one corresponding to the interface from which the reply is sent). I realize that many of you already know this, but it is a common bug and this seemed like a good opportunity to point it out. Let me also remind people that ICMP *error* messages (i.e., Destination Unreachable, Source Quench, Redirect, Time Exceeded, or Parameter Problem) should never be sent in response to a packet with a multicast or broadcast IP destination. Steve Deering ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704281427.AA09957@gateway.mitre.org] <1987042806275500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gross@GATEWAY.MITRE.ORG (Phill Gross) Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP echo Message-ID: <8704281427.AA09957@gateway.mitre.org> Date: Tue, 28-Apr-87 10:27:55 EDT Article-I.D.: gateway.8704281427.AA09957 Posted: Tue Apr 28 10:27:55 1987 Date-Received: Thu, 30-Apr-87 03:20:43 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 > A final tid: Should the TTL be reset at the echo server? If not, the > sender would have a non-ambiguous way to measure the number of hops. > He could, of course, also use record-route. Have we really given up on the original meaning of TTL? The Braden/Postel RFC985-update still talks about TTL in seconds, possibly decremented by more than one second at any gateway hop. If vendors take this as seriously as they are supposed to, then TTL will no longer be an unambiguous hop count. In either case, I would argue on principle that the TTL should be reset in the echo reply. Phill ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704281549.AA00721@braden.isi.edu] <1987042807490300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI.EDU (Bob Braden) Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP echo Message-ID: <8704281549.AA00721@braden.isi.edu> Date: Tue, 28-Apr-87 11:49:03 EDT Article-I.D.: braden.8704281549.AA00721 Posted: Tue Apr 28 11:49:03 1987 Date-Received: Sat, 2-May-87 04:52:15 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 From Dave Mills: Finally, how about a new ICMP Echo/Echo Reply message that operates as the present one, but where the echo server captures the IP header, etc., in the same way as ordinary ICMP error messages before returning to sender? Yeah, that sounds like the germ of a Good Idea. The ANSI guys are probably right, more effort is required to design the monitoring/diagnostic tools we REALLY need. (But that doesn't mean we need a 17-layered management architecture before we can make any progress!). Here is another example of a testing paradigm we cannot handle now. In the testing Steve Casner and Mark Lambert have been doing across the Wideband Net ("Fatnet"), they have wished they could do "one-way pinging". That is, they wanted to collect the same data that a normal Mike Muuss pinger gets, but with no return trip, assuming they could access the hosts on both ends. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704281555.AA26439@ACC-SB-UNIX.ARPA] <1987042807554900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gary@ACC-SB-UNIX.ARPA (Gary Krall) Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8704281555.AA26439@ACC-SB-UNIX.ARPA> Date: Tue, 28-Apr-87 11:55:49 EDT Article-I.D.: ACC-SB-U.8704281555.AA26439 Posted: Tue Apr 28 11:55:49 1987 Date-Received: Thu, 30-Apr-87 03:55:18 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 19 **All users of ACC's ACP 6250 and ACP 5250 boards** ACC has found a design problem with the RS232 electrical interface connection, and an ECO has been implemented to address this problem. Because this problem can cause unreliable operation, ACC recommends the return of the ACP processor board, ribbon cable and distribution panel for up-dating. Please note that the ECO will require modification of both the processor board and distribution panel, therefore please return the complete system. This is a no cost up-date to the equipment. Concerned users should call (805) 963-9431 (in California, Hawaii, or outside the U.S.) or (800) 222-7308 to obtain a return authorization (RA) number. All Service One customers will be provided with replacement units on a priority basis to minimize the impact of this update. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704281601.AA00730@braden.isi.edu] <1987042808013200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI.EDU (Bob Braden) Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP echo Message-ID: <8704281601.AA00730@braden.isi.edu> Date: Tue, 28-Apr-87 12:01:32 EDT Article-I.D.: braden.8704281601.AA00730 Posted: Tue Apr 28 12:01:32 1987 Date-Received: Sat, 2-May-87 04:51:17 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 The ICMP Echo Reply packet should start out with a new TTL value (in your terms, yes, the TTL should be reset). This follows from my assumption that ICMP is a protocol layered above IP. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[G.BBN.COM]28-Apr-87.12:57:28.CLYNN] <1987042808570000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CLYNN@G.BBN.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP echo Message-ID: <[G.BBN.COM]28-Apr-87.12:57:28.CLYNN> Date: Tue, 28-Apr-87 12:57:00 EDT Article-I.D.: <[G.BBN.COM]28-Apr-87.12:57:28.CLYNN> Posted: Tue Apr 28 12:57:00 1987 Date-Received: Sat, 2-May-87 06:25:15 EDT References: <8704272337.AA00366@braden.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 81 Bob, Well, I don't see why that would be more generally useful. Presumably you use source route because you want to force a particular path, or to override some inadequate routing mechanism; it seems most likely that the same problem will hold along the path back to the source host. This is exactly the point of using echo as a diagnostic tool in an environment where routes out and back are NOT the same. By forcing a packet to a spot in the internet, using a source route to get it there via whatever path you have found to work, you can explore/diagnose the "inadequate routing mechanism", aka the default routing. I have heard other people talk about source routing a packet out and back to yourself, but this doesn't seem sensible to me. As my message said, a host should send an Echo Reply only if the Echo Request message is DESTINED to it. If, on the other hand, a host merely appears as an intermediate step in the source route, that datagram is not destined for that host, and the host should never look at the ICMP level of the datagram. We agree that an echo request should only be turned into an echo reply by the host to which it was destined. Most systems allow messages to be sent to themselves -- you can telnet, ftp, smtp, and ping (with ICMP echo requests) to your own host (many systems bypass the net in such cases, allowing "loop- back" tests to measure host & protocol throughput, cpu load, etc.). The scenario I was suggesting is to ping your own host, but force the outgoing echo request through some portion of the net through use of a source route. Why do this? Because some hosts have better diagnostic tools than others -- if you are trying to collect information using IP options and the desintation host flushes them when forming an echo reply, you get nothing; but if your host either doesn't flush the opions or allows you to see echo requests that it receives, then you can get the information without the cooperation of the other host. (If collecting timing information you may win even more due to the ability to estimate skew in clocks along the way.) Did I hear "network management"? Certainly! Haven't all the uses for ICMP echos which we have been reading the last few weeks been for some form of fault or performance management? Isn't "management" the reason that ICMP was created? Also, I agree that Dave's point of not resetting the IP TTL is a good idea, and that leaving the options alone should be explicitly stated. If we are allowed to add to the wish list, ... I'll second Dave's suggestion for a way to capture the packet a la ICMP error messages. How about an option (possibly to Dave's) which would cause each IP entity which processed the packet to send back such a reply (analogous to the 1822 trace bit?); launch a single probe and several packets get returned showing the packet's progress through the internet (beware of recursion!). I would like to suggest an internet parameters option: processed by each IP entity along the path, it has fields for MTU, maximum bandwidth (physical or "available"?), error rate, and "typical delay". The originator sets the initial values for MTU and bandwidth to big values, error rate and delay to small; each IP entity along the path checks the local parameters (for the inbound and outbound patha) and overwrites the MTU or bandwidth fields if the local parameters are smaller, and the error rate and delay if the local parameters are larger. The recipient can then find out some of the (admittedly instantaneous) characteristics of the communications path. I think the MTU information would be useful, especially given the inherent problems associated with IP-level fragmentation, if only as something to be used if a) IP decides to send an ICMP fragmentation timeout message (piggyback the parameters option and the sender can try something better), or b) TCP is having to do a lot of retransmissions and wants to try something better. The bandwidth parameter could be used to limit the maximum send data rate -- no need to fill all the gateway queues before the bottleneck, keep the data at the source so others can use the bandwidth of the cross-paths. (One of the hooks in our tcp was to pass a process's controlling tty speed to TCP -- it could then send data at a rate which wasn't too much for the user's terminal; it worked much better than window-type flow control as the delay in the feedback path was "eliminated", the response to telnet interrupts was much improved too - little data in the pipe.) Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [87.04.28.1027.510@pescadero.stanford.edu] <1987042809270000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: deering@PESCADERO.STANFORD.EDU (Steve Deering) Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP echo Message-ID: <87.04.28.1027.510@pescadero.stanford.edu> Date: Tue, 28-Apr-87 13:27:00 EDT Article-I.D.: pescader.87.04.28.1027.510 Posted: Tue Apr 28 13:27:00 1987 Date-Received: Sat, 2-May-87 04:59:15 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 27 From: CLYNN@G.BBN.COM : I would argue that the simplest implementation is the most useful -- just change echo request to echo reply and switch the IP source and destination and send the packet back... From: Mills@UDEL.EDU : Your [Bob Braden's] model, taken prima facie, implies the respondent simply flips the IP addresses and source-route and tosses it back in the net, presumably leaving the options alone. I think this is the right thing, but believe it should be explicitly stated. Although the ICMP spec does say to simply reverse the IP source and destination addresses, that is incorrect when the original IP destination is a multicast or broadcast address. In that case, the IP source address of the Echo Reply (or Timestamp Reply, Information Reply, or Address Mask Reply) should be set to one of the replying host's individual addresses (presumably the one corresponding to the interface from which the reply is sent). I realize that many of you already know this, but it is a common bug and this seemed like a good opportunity to point it out. Let me also remind people that ICMP *error* messages (i.e., Destination Unreachable, Source Quench, Redirect, Time Exceeded, or Parameter Problem) should never be sent in response to a packet with a multicast or broadcast IP destination. Steve Deering ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704282235.a021924@Huey.UDEL.EDU] <1987042818354000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP echo Message-ID: <8704282235.a021924@Huey.UDEL.EDU> Date: Tue, 28-Apr-87 22:35:40 EDT Article-I.D.: Huey.8704282235.a021924 Posted: Tue Apr 28 22:35:40 1987 Date-Received: Sat, 2-May-87 05:00:10 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 Bob, Byte my tongue if I can't resist responding to your challenge. THe fuzzies have been using one-way pings (between themselves) since 1979. I discovered the value of these things at 0500 the morning of the SATNET demonstration at NCC while trying to bring up TOPS-20s in California, facsimile machines in London and fuzzballs scattered all over, all this in the midst of power failures at ISI, wandering satellite antennas in Maryland and buzzy amplifiers on the convention floor. The one-way buggers were useful, since the satellite channel was very flaky and we only needed it from London to Washington for a packet-voice and facsimile demo. All this was almost eight years ago when ICMP was really a wart on the side of GGP. But that's a story for another time. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [209@nih-csl.UUCP] <1987042917055800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bob@nih-csl.UUCP Newsgroups: comp.protocols.tcp-ip Subject: PCIP (TCP/IP for the IBM PC) problems Message-ID: <209@nih-csl.UUCP> Date: Wed, 29-Apr-87 21:05:58 EDT Article-I.D.: nih-csl.209 Posted: Wed Apr 29 21:05:58 1987 Date-Received: Fri, 1-May-87 04:19:09 EDT Organization: NIH-CSL, Bethesda, MD Lines: 16 Problem: Using MIT's PCIP software on an IBM XT or AT equipped with the Enhanced Color Display occasionally causes the screen to go blank--that it, the screen is still being written to, but the intensity turns off. Striking the function key F10 twice turns the intensity back on, for some reason. Other problems occur when using PCIP with gnu-emacs. Solution: Is there one? Bob Dew National Institutes of Health Bethesda, MD 20894 (301) 496-5361 UUCP: seismo!elsie!nih-csl!bob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704300123.AA27080@ucbvax.Berkeley.EDU] <1987042918072600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: seasterb@CS.UCL.AC.UK (Steve Easterbrook) Newsgroups: comp.protocols.tcp-ip Subject: tcp smooth rtt function Message-ID: <8704300123.AA27080@ucbvax.Berkeley.EDU> Date: Wed, 29-Apr-87 22:07:26 EDT Article-I.D.: ucbvax.8704300123.AA27080 Posted: Wed Apr 29 22:07:26 1987 Date-Received: Sat, 2-May-87 05:01:04 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 Whilst building a tool to monitor tcp's behaviour under various conditions I came across an interesting feature of the smooth round trip time function. As expected, this hovers around a value, responding to such things as rtx time-outs, etc. However, when running tcp across a local net, (i.e. with very small round trip time), I noticed a series of apparently random 'kicks' where the SRTT suddenly shoots up to a relatively enormous value, coming down only slightly less quick. After some careful analysis, I discovered the cause. On the test I was doing, the round trip time was small enough for the SRTT to reach zero occasionally. Examination of the tcp code reveals that when modifying the SRTT, a test is made to see if it is zero, and if so the usual RSRE smoothing function isn't used. The question is this: Can anyone give me some pointer as to what the philosophy behind this is, and maybe some reference as well. I gather its main purpose is to prevent the SRTT from staying at zero, as this will cause tcp to be a bit keen on the retransmissions, but it seems to me that substitute value is a little on the overkill side. Ta muchly, Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987042919162900> Mail-From: VIVIAN created at 29-Apr-87 17:26:22 Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Wed 29 Apr 87 10:06:08-PDT Received: from ucl-cs-pyr1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa06423; 29 Apr 87 17:43 BST To: tcp-ip@sri-nic.arpa Subject: tcp smooth rtt function Date: Wed, 29 Apr 87 17:36:29 +0100 From: Steve Easterbrook ReSent-Date: Wed 29 Apr 87 17:24:23-PDT ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12298490199.42.VIVIAN@SRI-NIC.ARPA> Whilst building a tool to monitor tcp's behaviour under various conditions I came across an interesting feature of the smooth round trip time function. As expected, this hovers around a value, responding to such things as rtx time-outs, etc. However, when running tcp across a local net, (i.e. with very small round trip time), I noticed a series of apparently random 'kicks' where the SRTT suddenly shoots up to a relatively enormous value, coming down only slightly less quick. After some careful analysis, I discovered the cause. On the test I was doing, the round trip time was small enough for the SRTT to reach zero occasionally. Examination of the tcp code reveals that when modifying the SRTT, a test is made to see if it is zero, and if so the usual RSRE smoothing function isn't used. The question is this: Can anyone give me some pointer as to what the philosophy behind this is, and maybe some reference as well. I gather its main purpose is to prevent the SRTT from staying at zero, as this will cause tcp to be a bit keen on the retransmissions, but it seems to me that substitute value is a little on the overkill side. Ta muchly, Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987043000423900> Mail-From: VIVIAN created at 30-Apr-87 10:02:05 Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Thu 30 Apr 87 04:24:42-PDT To: braden@VENERA.ISI.EDU Cc: tcp-ip@SRI-NIC.ARPA Cc: tmallory@CCV.BBN.COM Subject: Re: ICMP echo Date: Thu, 30 Apr 87 07:22:39 -0400 From: tmallory@CCV.BBN.COM ReSent-Date: Thu 30 Apr 87 09:54:40-PDT ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12298670474.40.VIVIAN@SRI-NIC.ARPA> Bob, The LSI-11 gateways already have much of the one-way functionality you probably need. The gateway will send a trap message for each ICMP echo reply received (you can turn this off). The trap messages are timestamped (internal format, but adequate for inter-packet arrivals) and include, among other things, the 16-bit IP id field so that individual packets may be watched. Of course, you need access to the INOC... Perhaps a little more work is needed. Cheers, Tracy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704300509.aa18764@SEM.BRL.ARPA] <1987043001091000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mike@BRL.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP echo Message-ID: <8704300509.aa18764@SEM.BRL.ARPA> Date: Thu, 30-Apr-87 05:09:10 EDT Article-I.D.: SEM.8704300509.aa18764 Posted: Thu Apr 30 05:09:10 1987 Date-Received: Fri, 1-May-87 05:08:20 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 31 I have a routine called TTCP which is useful for testing both TCP and UDP (inspired by a program of the same name that Excelan once sent a friend to test *his* TCP). By default, it acts much like a UNIX pipe, extended to the network on one side; optionally, it can source/sink a given quantity of patterns. Only occasionally useful as a communications tool, it's great for tests and debugging. For your fatnet tests, I'd use it in UDP mode with the source/sink option. While it will tell you about packet loss, CPU and clock time used, it does not assume the clocks are synchronized, so it does not try to make one-way timing assessments. That could be very easily added if times can be believed. TTCP is my standard tool for conducting performance measurements; on various occasions I have used it to test TCP performance, effects of window sizes, performance/overhead differences between various Ethernet interfaces on the same machine, gateway performance, and end-to-end InterNet performance. The most interesting communications use of this tool is for sending huge quantities of data painlessly between UNIX systems. On rcvr, run ttcp -r | tar xvf - on sender run tar cvf - . | ttcp -t destinationhost It has also been very useful for setting up "TCP relays" to avoid the GGP extra-hop problem, and/or the EGP packet-fragmentation-induced routing problem, when having to move > O(10 Mbytes) of data on our troubled InterNet. Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704301200.AA05763@csv.rpi.edu] <1987043003315600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jch@omnigate.clarkson.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Suffering Message-ID: <8704301200.AA05763@csv.rpi.edu> Date: Thu, 30-Apr-87 07:31:56 EDT Article-I.D.: csv.8704301200.AA05763 Posted: Thu Apr 30 07:31:56 1987 Date-Received: Fri, 1-May-87 05:29:32 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 39 Tead Mean writes: > > There seemed to be a consensus that having diskless workstations and >file servers on a network would cause havoc to an Ethernet. I'd like to solicit comments on a configuration that our School of Engineering has proposed: They would like to purchase an Aliant super-mini-computer, a Sun 3/160 server and 12 diskless 3/50s, 8 Opus Clipper systems (a PC/AT with a 32032 processor board running a System V port (I belive)), and 83 IBM PC/AT clones running Sun's PC/NFS. The Opus system are supposed to be disk servers for the PC/NFS systems where most of the computing is supposed to take place. Most of the PC/ATs will not have any hard disk, they will rely fully on the Opus systems for disk storage. All this equipment, in 4 buildings, will be linked with 3 fiber repeaters, making one large ethernet. Our limited experience shows that one or two diskless 3/50s doing disk intensive work (compiling programs or coping disk files around) significantly affect the performance of both other diskless 3/50s and PCs on the same net that do not make use of the file server (i.e. DECnet-DOS to a VMS system). (The Imperial ;-)) We in the computing center would like to see some partitioning of the ethernet into departmental segments connected to a School of Engineering backbone with at least level II bridges. In our minds this would localize traffic to some degree, isolate potential physical problems (shorted or broken cable, accidental or malicious) and provide some measure of security. This would not address problems of the "Chernobyl" effect. Does anyone have experience with a similar configuration of diskless workstations and/or PCs that they can comment on? Thanks Jeff ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704301246.AA02177@jupiter.mitre.org] <1987043004460200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tsuchiya@GATEWAY.MITRE.ORG.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP echo Message-ID: <8704301246.AA02177@jupiter.mitre.org> Date: Thu, 30-Apr-87 08:46:02 EDT Article-I.D.: jupiter.8704301246.AA02177 Posted: Thu Apr 30 08:46:02 1987 Date-Received: Fri, 1-May-87 05:35:36 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 33 > If we are allowed to add to the wish list, ... > I'll second Dave's suggestion for a way to capture the packet a la > ICMP error messages. How about an option (possibly to Dave's) which would > cause each IP entity which processed the packet to send back such a reply > (analogous to the 1822 trace bit?); launch a single probe and several > packets get returned showing the packet's progress through the internet > (beware of recursion!). > I would like to suggest an internet parameters option: processed > by each IP entity along the path, it has fields for MTU, maximum bandwidth > (physical or "available"?), error rate, and "typical delay". The I have been following the ICMP messages with interest, and note an interesting turn in the trend. Most of the earlier messages seemed to me to praise ICMP Echo for its simplicity. As Mills said, just flip the source and destination address and shove it back out. It seems to me that the beauty of Echo is that it is a very basic and simple tool that can yield 90% of the information that one might want with 10% of the effort. Messages have shown that it can be used for several quite different kinds of debugging. We have discussed the "1822 trace bit" option in X3S3.3, and are concerned about its Chernobyl-potential. The internet parameters option seems more like something a routing protocol or more sophisticated (application layer) management function should provide. In the standards environment, we have to provide pretty good justification for putting management protocols at the network layer instead of at the application layer. One could probably justify a simple echo-probe at the network layer for debugging purposes when that application layer has failed, but echo-PLUS functions might be a little hard to swallow. Paul Tsuchiya tsuchiya@gateway.mitre.org The MITRE Corp. tsuchiya@mitre-gateway.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[G.BBN.COM]30-Apr-87.09:45:20.CLYNN] <1987043005450000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CLYNN@G.BBN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: tcp smooth rtt function Message-ID: <[G.BBN.COM]30-Apr-87.09:45:20.CLYNN> Date: Thu, 30-Apr-87 09:45:00 EDT Article-I.D.: <[G.BBN.COM]30-Apr-87.09:45:20.CLYNN> Posted: Thu Apr 30 09:45:00 1987 Date-Received: Sat, 2-May-87 01:06:34 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Steve, It is well known that a TCP receiving an ack for a segment does not know if the ack is for the original transmission or one of the retransmissions. The spec does not offer much help to the implementor, consequently different algorithms have been explored. IF one measures the rtt from the most recent (re)transmission, then the possibility exists that an ack of one of the prior transmissions may arrive "about the same time" as the "next" retransmission. If it is just a little before, the segment acked, it is not retransmitted, and the rtt is "reasonable", so one uses it; if it is just a little after, who knows ... one hopes for the best (and frequently looses); if it arrives at the "same time", who knows. It sounds like the implementation you were measuring decided that it was a case of the retransmission being acked and therefore didn't want to corrupt the srtt by including what the implementors thought was bogus data. Aside: I believe one can prove that if the rtt is not measured from the original transmission (and no other information is available to decide what is being acked) then it is possible for the srtt to converge to a value less than the "correct" value; this causes every packet to be retransmitted, even if it isn't lost. I think there is enough latitude in the protocol to allow an implementer to cause the other end to unknowingly provide some good "hints" about what is being acked, but that is another discussion. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987043005450001> Mail-From: VIVIAN created at 30-Apr-87 10:07:23 Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Thu 30 Apr 87 06:47:32-PDT Date: 30 Apr 1987 09:45-EDT Sender: CLYNN@G.BBN.COM Subject: Re: tcp smooth rtt function From: CLYNN@G.BBN.COM To: seasterb@CS.UCL.AC.UK Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[G.BBN.COM]30-Apr-87 09:45:20.CLYNN> In-Reply-To: The message of Wed, 29 Apr 87 17:36:29 +0100 from Steve Easterbrook ReSent-Date: Thu 30 Apr 87 09:57:26-PDT ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12298670978.40.VIVIAN@SRI-NIC.ARPA> Steve, It is well known that a TCP receiving an ack for a segment does not know if the ack is for the original transmission or one of the retransmissions. The spec does not offer much help to the implementor, consequently different algorithms have been explored. IF one measures the rtt from the most recent (re)transmission, then the possibility exists that an ack of one of the prior transmissions may arrive "about the same time" as the "next" retransmission. If it is just a little before, the segment acked, it is not retransmitted, and the rtt is "reasonable", so one uses it; if it is just a little after, who knows ... one hopes for the best (and frequently looses); if it arrives at the "same time", who knows. It sounds like the implementation you were measuring decided that it was a case of the retransmission being acked and therefore didn't want to corrupt the srtt by including what the implementors thought was bogus data. Aside: I believe one can prove that if the rtt is not measured from the original transmission (and no other information is available to decide what is being acked) then it is possible for the srtt to converge to a value less than the "correct" value; this causes every packet to be retransmitted, even if it isn't lost. I think there is enough latitude in the protocol to allow an implementer to cause the other end to unknowingly provide some good "hints" about what is being acked, but that is another discussion. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [[G.BBN.COM]30-Apr-87.10:26:56.CLYNN] <1987043006260000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CLYNN@G.BBN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP echo Message-ID: <[G.BBN.COM]30-Apr-87.10:26:56.CLYNN> Date: Thu, 30-Apr-87 10:26:00 EDT Article-I.D.: <[G.BBN.COM]30-Apr-87.10:26:56.CLYNN> Posted: Thu Apr 30 10:26:00 1987 Date-Received: Sat, 2-May-87 01:08:00 EDT References: <8704281601.AA00730@braden.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 27 Bob, The ICMP Echo Reply packet should start out with a new TTL value (in your terms, yes, the TTL should be reset). This follows from my assumption that ICMP is a protocol layered above IP. I do not agree with the "This follows" logic. There are instancces in the suite where a protocol "above" IP obtains information from the IP header and later returns it for use in a subsequent IP datagram; the two most obvious examples are the source and destination address, and one could even consider the IP type-of-service and protocol fields to be in this category. I think the desire should be to specify a tool so that it provides as much information as possible (without "external" knowledge of the implementation details of particular components in the system). The information gained by resetting the TTL is variations over time in "x" on the way back (where "x" is hops or seconds or some combination); one learns nothing about the way out. The information gained by not resetting the TTL is both variations in "x", summed over out and back AND, since you specified the original TTL, the absolute amount by which "x" changed (out and back). Resetting gives one-way second-order information while the not resetting it gives two-way first and second order information. The question is, if we can only have one, which is more generally useful? Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987043006260001> Mail-From: VIVIAN created at 30-Apr-87 10:09:24 Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Thu 30 Apr 87 07:35:14-PDT Date: 30 Apr 1987 10:26-EDT Sender: CLYNN@G.BBN.COM Subject: Re: ICMP echo From: CLYNN@G.BBN.COM To: braden@VENERA.ISI.EDU Cc: Mills@LOUIE.UDEL.EDU, postel@VENERA.ISI.EDU Cc: tai%hpltyj@HPLABS.HP.COM, tcp-ip@SRI-NIC.ARPA Message-ID: <[G.BBN.COM]30-Apr-87 10:26:56.CLYNN> In-Reply-To: <8704281601.AA00730@braden.isi.edu> ReSent-Date: Thu 30 Apr 87 09:57:51-PDT ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12298671055.40.VIVIAN@SRI-NIC.ARPA> Bob, The ICMP Echo Reply packet should start out with a new TTL value (in your terms, yes, the TTL should be reset). This follows from my assumption that ICMP is a protocol layered above IP. I do not agree with the "This follows" logic. There are instancces in the suite where a protocol "above" IP obtains information from the IP header and later returns it for use in a subsequent IP datagram; the two most obvious examples are the source and destination address, and one could even consider the IP type-of-service and protocol fields to be in this category. I think the desire should be to specify a tool so that it provides as much information as possible (without "external" knowledge of the implementation details of particular components in the system). The information gained by resetting the TTL is variations over time in "x" on the way back (where "x" is hops or seconds or some combination); one learns nothing about the way out. The information gained by not resetting the TTL is both variations in "x", summed over out and back AND, since you specified the original TTL, the absolute amount by which "x" changed (out and back). Resetting gives one-way second-order information while the not resetting it gives two-way first and second order information. The question is, if we can only have one, which is more generally useful? Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704301720.AA14575@ucbvax.Berkeley.EDU] <1987043009224700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tmallory@CCV.BBN.COM.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: ICMP echo Message-ID: <8704301720.AA14575@ucbvax.Berkeley.EDU> Date: Thu, 30-Apr-87 13:22:47 EDT Article-I.D.: ucbvax.8704301720.AA14575 Posted: Thu Apr 30 13:22:47 1987 Date-Received: Fri, 1-May-87 05:29:12 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 14 Bob, The LSI-11 gateways already have much of the one-way functionality you probably need. The gateway will send a trap message for each ICMP echo reply received (you can turn this off). The trap messages are timestamped (internal format, but adequate for inter-packet arrivals) and include, among other things, the 16-bit IP id field so that individual packets may be watched. Of course, you need access to the INOC... Perhaps a little more work is needed. Cheers, Tracy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704301837.AA16215@ucbvax.Berkeley.EDU] <1987043011532700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: seasterb@CS.UCL.AC.UK (Steve Easterbrook) Newsgroups: comp.protocols.tcp-ip Subject: Re: tcp smooth rtt function Message-ID: <8704301837.AA16215@ucbvax.Berkeley.EDU> Date: Thu, 30-Apr-87 15:53:27 EDT Article-I.D.: ucbvax.8704301837.AA16215 Posted: Thu Apr 30 15:53:27 1987 Date-Received: Sat, 2-May-87 10:56:16 EDT References: <[G.BBN.COM]30-Apr-87.09:45:20.CLYNN> Sender: usenet@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 25 > It sounds like the > implementation you were measuring decided that it was a case of the > retransmission being acked and therefore didn't want to corrupt the > srtt by including what the implementors thought was bogus data. Ah, excellent point, but I've managed to rule this one out. I'm monitoring retransmissions as well, and there aren't any happening at the right time to account for the behaviour I described. It seems the SRTT is falling to zero purely due to rounding errors with very small round trip times. However, this doesnt preclude the resulting behaviour being due to the implementors allowing for the circumstances you describe. There seems to be two possible approaches (given that it is undesirable to have a SRTT of zero): Let the SRTT do whatever it wants, but never let the RTT be rounded to zero, or do something different with the SRTT if it does reach zero. Clearly the second approach (whether intentionally or not) is taken in the tcp I'm using. Given this, what alternative value should it be set to? Has anyone tackled this problem before? And what happens if it *is* left at zero? (I shall now go away and find out the answer to the last question!) Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8704302051.AA22704@okeeffe.Berkeley.EDU] <1987043012514700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: tcp smooth rtt function Message-ID: <8704302051.AA22704@okeeffe.Berkeley.EDU> Date: Thu, 30-Apr-87 16:51:47 EDT Article-I.D.: okeeffe.8704302051.AA22704 Posted: Thu Apr 30 16:51:47 1987 Date-Received: Sat, 2-May-87 02:02:10 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 17 I presume that you are using 4.3BSD; discussions of implementation quirks are easiest to follow if the implementation is identified. Things will behave strangely in 4.3 TCP if the smoothed round-trip time becomes zero after the connection is established; it would do just what you described. The value of 0 is used to mean "unknown", and causes the default (fairly long) value to be assumed. The first RTT sample (from first send of SYN to its ack) becomes the initial value of the smoothed RTT. It was assumed that the smoothed RTT would never again be 0, as the RTT starts at 1. I don't understand how this can happen. To respond to an early point in this discussion: this implementation discards RTT estimates for segments that are retransmitted. This sometimes reduces the number of RTT estimates that are obtained, but is much better than restarting the RTT timer when retransmitting. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8705010226.AA08286@topaz.rutgers.edu] <1987043018264400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: root@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Ethernet Suffering Message-ID: <8705010226.AA08286@topaz.rutgers.edu> Date: Thu, 30-Apr-87 22:26:44 EDT Article-I.D.: topaz.8705010226.AA08286 Posted: Thu Apr 30 22:26:44 1987 Date-Received: Sat, 2-May-87 07:18:19 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 We use diskless Suns extensively. We have around 40 diskless machines on one Ethernet. There is evidence that this causes more load than one would prefer. On the other hand, it is also not a disaster. I'm sceptical of 2 machines causing serious problems. We'd rather keep it to about 25. Because of the critical dependence of Suns on their Ethernets, and the wierd things that some TCP/IP implementations do to the Ethernet, we keep diskless Suns on separate Ethernets dedicated to just Suns. We use a real IP gateway between the Ethernets. Level 2 bridges would certainly help with the load, but would not necessarily provide isolation from wierd packets. Whether this is a problem depends upon how confident you are in your TCP/IP implementations. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987043018285700> Mail-From: VIVIAN created at 30-Apr-87 10:11:51 Received: from Cs.Ucl.AC.UK by SRI-NIC.ARPA with TCP; Thu 30 Apr 87 09:00:29-PDT Received: from ucl-cs-pyr1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id aa11240; 30 Apr 87 16:50 BST To: CLYNN@g.bbn.com cc: tcp-ip@sri-nic.arpa Subject: Re: tcp smooth rtt function In-reply-to: Your message of 30 Apr 87 09:45:00 -0400. <[G.BBN.COM]30-Apr-87 09:45:20.CLYNN> Date: Thu, 30 Apr 87 16:48:57 +0100 From: Steve Easterbrook ReSent-Date: Thu 30 Apr 87 09:58:41-PDT ReSent-From: Vivian Neou ReSent-To: tcp-ip-rebroadcast@SRI-NIC.ARPA ReSent-Message-ID: <12298671205.40.VIVIAN@SRI-NIC.ARPA> > It sounds like the > implementation you were measuring decided that it was a case of the > retransmission being acked and therefore didn't want to corrupt the > srtt by including what the implementors thought was bogus data. Ah, excellent point, but I've managed to rule this one out. I'm monitoring retransmissions as well, and there aren't any happening at the right time to account for the behaviour I described. It seems the SRTT is falling to zero purely due to rounding errors with very small round trip times. However, this doesnt preclude the resulting behaviour being due to the implementors allowing for the circumstances you describe. There seems to be two possible approaches (given that it is undesirable to have a SRTT of zero): Let the SRTT do whatever it wants, but never let the RTT be rounded to zero, or do something different with the SRTT if it does reach zero. Clearly the second approach (whether intentionally or not) is taken in the tcp I'm using. Given this, what alternative value should it be set to? Has anyone tackled this problem before? And what happens if it *is* left at zero? (I shall now go away and find out the answer to the last question!) Steve ----MESSAGE-END----