----MESSAGE-BEGIN---- [8702030109.AA11365%40ucbvax.Berkeley.EDU] <1987020205420000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@BARILVM.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Looking for Tcp/Ip for Prime's PRIMOS system Message-ID: <8702030109.AA11365@ucbvax.Berkeley.EDU> Date: Mon, 2-Feb-87 10:42:00 EST Article-I.D.: ucbvax.8702030109.AA11365 Posted: Mon Feb 2 10:42:00 1987 Date-Received: Wed, 4-Feb-87 00:39:55 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Henry Nussbacher Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa I have seen that Prime has a Tcp/Ip version. I am interested in hearing any user experience with this package - costs, benefits, pros, cons, etc. Please reply directly to me since I am not on this list. Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702021754.AA10915%40okeeffe.Berkeley.EDU] <1987020207540600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: de-multiplexing (was Gateway Monitoring) Message-ID: <8702021754.AA10915@okeeffe.Berkeley.EDU> Date: Mon, 2-Feb-87 12:54:06 EST Article-I.D.: okeeffe.8702021754.AA10915 Posted: Mon Feb 2 12:54:06 1987 Date-Received: Tue, 3-Feb-87 04:03:53 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Mike, I wanted to respond to your comments about user process use of protocols unimplemented by the kernel (Bill of Rights, Article 10). 4.3BSD UNIX does allow user processes access to such protocols by the use of "raw" sockets in the INET protocol family. No support for demultiplexing is provided; multiple listeners on the same protocol receive copies of all packets. This facility was not present in 4.2BSD. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987020209100000> Received: from TYCHO by SRI-NIC.ARPA with TCP; Mon 2 Feb 87 11:32:07-PST Date: 2 Feb 1987 at 1410-EST Subject: Weird Gateway Re-directs! From: hsw at TYCHO.ARPA (Howard Weiss) To: tcp-ip at sri-nic cc: jim, franceus, lee, jackson, loscocco, huckaby Attached is a set of ICMP re-direct messages that my host (TYCHO 10.0.0.126) received this morning. The packets were being sent to BBNCC-COLUMBIA.ARPA (8.1.0.35) and were being sent thru the BBNNET2-ARPANET-GW (10.7.0.63, 8.3.0.9). The following round-the-world tour is the result. Do any of the gateway gurus have any words of wisdom on this? It seems awfully strange from where I sit! Why the hops to the MILNET and why the loops in the West Coast gateways? Howard Weiss --------------------------------------- ICMPIn: type = 5, code = 0 from 10.7.0.63 /* BBNNET2-ARPANET-GW */ ICMPIn: Redirect to 10.5.0.5 /* redirecting to BBN-MILNET-GW */ ICMPIn: Message original dest was 8.1.0.35 /* (26.2.0.49) on the milnet */ ICMPIn: type = 5, code = 0 from 10.5.0.5 /* BBN-MILNET-GW */ ICMPIn: Redirect to 10.0.0.68 /* redirecting to LBL-MILNET-GW */ ICMPIn: Message original dest was 8.1.0.35 /* (26.3.0.34) on the MILNET */ ICMPIn: type = 5, code = 0 from 10.0.0.68 /* LBL-MILNET-GW */ ICMPIn: Redirect to 10.5.0.51 /* redirecting to SRI-GW */ ICMPIn: Message original dest was 8.1.0.35 /* (128.18.1.0) on the SRINET */ ICMPIn: type = 5, code = 0 from 10.5.0.51 /* SRI-GW */ ICMPIn: Redirect to 10.4.0.51 /* redirecting to SRI-MILNET-GW */ ICMPIn: Message original dest was 8.1.0.35 /* (26.2.0.73) on the MILNET */ ICMPIn: type = 5, code = 0 from 10.4.0.51 /* SRI-MILNET-GW */ ICMPIn: Redirect to 10.0.0.68 /* redirecting to LBL-MILNET-GW */ ICMPIn: Message original dest was 8.1.0.35 /* (26.3.0.34) on the MILNET */ ICMPIn: type = 5, code = 0 from 10.0.0.68 /* LBL-MILNET-GW */ ICMPIn: Redirect to 10.5.0.51 /* redirecting to SRI-GW */ ICMPIn: Message original dest was 8.1.0.35 /* (128.18.1.0) on the SRINET */ ICMPIn: type = 5, code = 0 from 10.5.0.51 /* SRI-GW */ ICMPIn: Redirect to 10.4.0.82 /* redirecting to BBN-ENET-2-GW */ ICMPIn: Message original dest was 8.1.0.35 /* (8.3.0.8) on the BBN-NET-TEMP */ /* Wow - finally got there !! */ ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702021415.AA15453%40oucs.OHIOU.EDU] <1987020209153300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: shapiro@oucs.ohiou.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8702021415.AA15453@oucs.OHIOU.EDU> Date: Mon, 2-Feb-87 14:15:33 EST Article-I.D.: oucs.8702021415.AA15453 Posted: Mon Feb 2 14:15:33 1987 Date-Received: Tue, 3-Feb-87 21:46:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa Path: oucs!shapiro From: shapiro@oucs.OHIOU.EDU (Brian Shapiro) Newsgroups: mod.protocols.tcp-ip Subject: Help: tcp-ip vs. xns Message-ID: <472@oucs.OHIOU.EDU> Date: 2 Feb 87 19:15:31 GMT Distribution: mod Organization: Ohio University CS Department, Athens Lines: 19 There has been consideration given to the idea of converting our Bridge communications XNS based network over to TCP-IP protocol. This is being considered because a statewide supercomputer center is in the works. We are not a DoD research site have no access to ARPAnet without going thru the BITNET-ARPA net gateways. Is ther anyone out there that can tell me what advantages we will have using TCP-IP vs. XNS? I also know very little about TCP-IP and would like to know more. Can anyone send me a brief comparison between the two. Oh, I almost forgot what are the disadvantages of TCP-IP vs. XNS. Any help that can be given would be gratefully appreciated..... Brian Shapiro Ohio University Computing and Learning Services Haning Hall Athens, Ohio 45701 (614) 593-1608 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702021939.AA04461%40ucbvax.Berkeley.EDU] <1987020209431700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hsw@TYCHO.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Weird Gateway Re-directs! Message-ID: <8702021939.AA04461@ucbvax.Berkeley.EDU> Date: Mon, 2-Feb-87 14:43:17 EST Article-I.D.: ucbvax.8702021939.AA04461 Posted: Mon Feb 2 14:43:17 1987 Date-Received: Tue, 3-Feb-87 04:08:07 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 43 Approved: tcp-ip@sri-nic.arpa Attached is a set of ICMP re-direct messages that my host (TYCHO 10.0.0.126) received this morning. The packets were being sent to BBNCC-COLUMBIA.ARPA (8.1.0.35) and were being sent thru the BBNNET2-ARPANET-GW (10.7.0.63, 8.3.0.9). The following round-the-world tour is the result. Do any of the gateway gurus have any words of wisdom on this? It seems awfully strange from where I sit! Why the hops to the MILNET and why the loops in the West Coast gateways? Howard Weiss --------------------------------------- ICMPIn: type = 5, code = 0 from 10.7.0.63 /* BBNNET2-ARPANET-GW */ ICMPIn: Redirect to 10.5.0.5 /* redirecting to BBN-MILNET-GW */ ICMPIn: Message original dest was 8.1.0.35 /* (26.2.0.49) on the milnet */ ICMPIn: type = 5, code = 0 from 10.5.0.5 /* BBN-MILNET-GW */ ICMPIn: Redirect to 10.0.0.68 /* redirecting to LBL-MILNET-GW */ ICMPIn: Message original dest was 8.1.0.35 /* (26.3.0.34) on the MILNET */ ICMPIn: type = 5, code = 0 from 10.0.0.68 /* LBL-MILNET-GW */ ICMPIn: Redirect to 10.5.0.51 /* redirecting to SRI-GW */ ICMPIn: Message original dest was 8.1.0.35 /* (128.18.1.0) on the SRINET */ ICMPIn: type = 5, code = 0 from 10.5.0.51 /* SRI-GW */ ICMPIn: Redirect to 10.4.0.51 /* redirecting to SRI-MILNET-GW */ ICMPIn: Message original dest was 8.1.0.35 /* (26.2.0.73) on the MILNET */ ICMPIn: type = 5, code = 0 from 10.4.0.51 /* SRI-MILNET-GW */ ICMPIn: Redirect to 10.0.0.68 /* redirecting to LBL-MILNET-GW */ ICMPIn: Message original dest was 8.1.0.35 /* (26.3.0.34) on the MILNET */ ICMPIn: type = 5, code = 0 from 10.0.0.68 /* LBL-MILNET-GW */ ICMPIn: Redirect to 10.5.0.51 /* redirecting to SRI-GW */ ICMPIn: Message original dest was 8.1.0.35 /* (128.18.1.0) on the SRINET */ ICMPIn: type = 5, code = 0 from 10.5.0.51 /* SRI-GW */ ICMPIn: Redirect to 10.4.0.82 /* redirecting to BBN-ENET-2-GW */ ICMPIn: Message original dest was 8.1.0.35 /* (8.3.0.8) on the BBN-NET-TEMP */ /* Wow - finally got there !! */ ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702030340.AA14641%40ucbvax.Berkeley.EDU] <1987020217274500> 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: Submission for mod-protocols-tcp-ip Message-ID: <8702030340.AA14641@ucbvax.Berkeley.EDU> Date: Mon, 2-Feb-87 22:27:45 EST Article-I.D.: ucbvax.8702030340.AA14641 Posted: Mon Feb 2 22:27:45 1987 Date-Received: Wed, 4-Feb-87 01:38:46 EST References: <8702021415.AA15453@oucs.OHIOU.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa Brian, In a nutshell: TCP/IP and XNS are very similar in the kinds of low level services they offer (like connecting terminals to hosts). In the higher level services (like file transfer and email) they differ only in the aspect of how many different host types does your situation need to communicate with. TCP/IP has implementations on essentially every host in existence. XNS is much more limited in that respect. In your situation going with TCP/IP can only open up your choices. Bridge is offering you equivalent initial functionality with a "bridge" to further functionality (by moving to TCP/IP). You say that you will be connecting to a supercomputer center soon. It will undoubtedly be TCP/IP based. And gaining access to BITNET (meanwhile) is very close to working in TCP/IP land as their mail protocols are very close to TCP/IP's and getting closer. I'll send you some more materials in the US Snail, includi9ng a reading list. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987020217274501> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 2 Feb 87 19:30:38-PST Date: 2 Feb 1987 22:27:45 EST Subject: Re: Submission for mod-protocols-tcp-ip From: Dan Lynch To: tcp-ip@SRI-NIC.ARPA In-Reply-To: <8702021415.AA15453@oucs.OHIOU.EDU> Brian, In a nutshell: TCP/IP and XNS are very similar in the kinds of low level services they offer (like connecting terminals to hosts). In the higher level services (like file transfer and email) they differ only in the aspect of how many different host types does your situation need to communicate with. TCP/IP has implementations on essentially every host in existence. XNS is much more limited in that respect. In your situation going with TCP/IP can only open up your choices. Bridge is offering you equivalent initial functionality with a "bridge" to further functionality (by moving to TCP/IP). You say that you will be connecting to a supercomputer center soon. It will undoubtedly be TCP/IP based. And gaining access to BITNET (meanwhile) is very close to working in TCP/IP land as their mail protocols are very close to TCP/IP's and getting closer. I'll send you some more materials in the US Snail, includi9ng a reading list. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987020221120000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 2 Feb 87 16:57:54-PST Received: from BARILVM.BITNET by wiscvm.wisc.edu on 02/02/87 at 18:44:01 CST Received: by BARILVM (Mailer X1.23b) id 4103; Mon, 02 Feb 87 17:43:21 O Date: Mon, 02 Feb 87 17:42:00 O From: Henry Nussbacher Subject: Looking for Tcp/Ip for Prime's PRIMOS system To: tcp-ip@sri-nic.ARPA Reply-To: Henry Nussbacher I have seen that Prime has a Tcp/Ip version. I am interested in hearing any user experience with this package - costs, benefits, pros, cons, etc. Please reply directly to me since I am not on this list. Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987020306390000> Received: from LOGICON.ARPA by SRI-NIC.ARPA with TCP; Tue 3 Feb 87 14:40:27-PST Date: 3 Feb 87 14:39 PST From: Tom Perrine To: tcp-ip@SRI-NIC.ARPA Cc: Tom Perrine Subject: PSN physical locations? Is there any way I can find out where the ARPA or MILNET PSN are located? (A file a SRI-NIC, maybe?) I am specifically interested in the San Diego area. I know about NOSC, are there any others? Tom Perrine ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702042009.AA20434%40ucbvax.Berkeley.EDU] <1987020309234300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@CCV.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Weird Gateway Re-directs! Message-ID: <8702042009.AA20434@ucbvax.Berkeley.EDU> Date: Tue, 3-Feb-87 14:23:43 EST Article-I.D.: ucbvax.8702042009.AA20434 Posted: Tue Feb 3 14:23:43 1987 Date-Received: Sat, 7-Feb-87 07:29:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 52 Approved: tcp-ip@sri-nic.arpa Howard, you seem to have captured a routing transient. For about the past week, and through about 3pm EST Monday afternoon, there was a growing problem with congestion on the arpanet. Because of this congestion, the gateways (core, butterfly, and egp) were losing track of their neighbor connections, and making a lot of changes to the routing information they maintain. Between about 9am and noon EST, I had brought down various gateways which had been providing redundant routes to satnet, wideband, and bbnnet. Specifically, I had disconnected 8.3.0.9 (bbn2), 10.3.0.82 (bbn), 10.4.0.82 (bbn-e2), sri-wb (10.3.0.51), and css (10.2.0.25). This was an attempt to provide single path routes, and reduce the gateway routing overhead. The arpanet programmers will probably have some specific recommendations coming out soon, because the current respite seems shaky. For the gateways, we are designing methods to make the neighbor connections more robust in the face of long delays, wildly varying delays, and long internal queues. We aim to reduce the apparent instability in the internet when the arpanet gets congested. -- Attached is a set of ICMP re-direct messages that my host (TYCHO 10.0.0.126) This specific set of redirects would be even more interesting if we knew when they happened. I suspect it was around the time when I brought down the first interface at 8.3.0.9 (other side of 10.7.0.63), around 9am EST. Please don't be mislead by the redirects to various other gateways; this does not mean the packets went to the sri-ethernet, or milnet. They went in and out the same arpanet interface of each gateway which issued a redirect. Additional information I could use would be how often and how long the redirect flurry was going on. It does seem that the route settled after only a 'short' time. This means that it is useful if your host retains network route information over a longer time than the existence of a single tcp (e.g. mail) connection. ICMPIn: type = 5, code = 0 from 10.7.0.63 /* BBNNET2-ARPANET-GW */ ICMPIn: Redirect to 10.5.0.5 /* redirecting to BBN-MILNET-GW */ ICMPIn: type = 5, code = 0 from 10.5.0.5 /* BBN-MILNET-GW */ ICMPIn: Redirect to 10.0.0.68 /* redirecting to LBL-MILNET-GW */ ICMPIn: type = 5, code = 0 from 10.0.0.68 /* LBL-MILNET-GW */ ICMPIn: Redirect to 10.5.0.51 /* redirecting to SRI-GW */ ICMPIn: type = 5, code = 0 from 10.5.0.51 /* SRI-GW */ ICMPIn: Redirect to 10.4.0.51 /* redirecting to SRI-MILNET-GW */ ICMPIn: type = 5, code = 0 from 10.4.0.51 /* SRI-MILNET-GW */ ICMPIn: Redirect to 10.0.0.68 /* redirecting to LBL-MILNET-GW */ ICMPIn: type = 5, code = 0 from 10.0.0.68 /* LBL-MILNET-GW */ ICMPIn: Redirect to 10.5.0.51 /* redirecting to SRI-GW */ ICMPIn: type = 5, code = 0 from 10.5.0.51 /* SRI-GW */ ICMPIn: Redirect to 10.4.0.82 /* redirecting to BBN-ENET-2-GW */ Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987020309234301> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Wed 4 Feb 87 11:54:23-PST To: Howard Weiss cc: tcp-ip@sri-nic.ARPA, jim@tycho.ARPA, franceus@tycho.ARPA, lee@tycho.ARPA, jackson@tycho.ARPA, loscocco@tycho.ARPA, huckaby@tycho.ARPA, hinden@ccv.bbn.com, brescia@ccv.bbn.com Subject: Re: Weird Gateway Re-directs! In-reply-to: Your message of 2 Feb 1987 at 1410-EST. Date: 03 Feb 87 14:23:43 EST (Tue) From: Mike Brescia Howard, you seem to have captured a routing transient. For about the past week, and through about 3pm EST Monday afternoon, there was a growing problem with congestion on the arpanet. Because of this congestion, the gateways (core, butterfly, and egp) were losing track of their neighbor connections, and making a lot of changes to the routing information they maintain. Between about 9am and noon EST, I had brought down various gateways which had been providing redundant routes to satnet, wideband, and bbnnet. Specifically, I had disconnected 8.3.0.9 (bbn2), 10.3.0.82 (bbn), 10.4.0.82 (bbn-e2), sri-wb (10.3.0.51), and css (10.2.0.25). This was an attempt to provide single path routes, and reduce the gateway routing overhead. The arpanet programmers will probably have some specific recommendations coming out soon, because the current respite seems shaky. For the gateways, we are designing methods to make the neighbor connections more robust in the face of long delays, wildly varying delays, and long internal queues. We aim to reduce the apparent instability in the internet when the arpanet gets congested. -- Attached is a set of ICMP re-direct messages that my host (TYCHO 10.0.0.126) This specific set of redirects would be even more interesting if we knew when they happened. I suspect it was around the time when I brought down the first interface at 8.3.0.9 (other side of 10.7.0.63), around 9am EST. Please don't be mislead by the redirects to various other gateways; this does not mean the packets went to the sri-ethernet, or milnet. They went in and out the same arpanet interface of each gateway which issued a redirect. Additional information I could use would be how often and how long the redirect flurry was going on. It does seem that the route settled after only a 'short' time. This means that it is useful if your host retains network route information over a longer time than the existence of a single tcp (e.g. mail) connection. ICMPIn: type = 5, code = 0 from 10.7.0.63 /* BBNNET2-ARPANET-GW */ ICMPIn: Redirect to 10.5.0.5 /* redirecting to BBN-MILNET-GW */ ICMPIn: type = 5, code = 0 from 10.5.0.5 /* BBN-MILNET-GW */ ICMPIn: Redirect to 10.0.0.68 /* redirecting to LBL-MILNET-GW */ ICMPIn: type = 5, code = 0 from 10.0.0.68 /* LBL-MILNET-GW */ ICMPIn: Redirect to 10.5.0.51 /* redirecting to SRI-GW */ ICMPIn: type = 5, code = 0 from 10.5.0.51 /* SRI-GW */ ICMPIn: Redirect to 10.4.0.51 /* redirecting to SRI-MILNET-GW */ ICMPIn: type = 5, code = 0 from 10.4.0.51 /* SRI-MILNET-GW */ ICMPIn: Redirect to 10.0.0.68 /* redirecting to LBL-MILNET-GW */ ICMPIn: type = 5, code = 0 from 10.0.0.68 /* LBL-MILNET-GW */ ICMPIn: Redirect to 10.5.0.51 /* redirecting to SRI-GW */ ICMPIn: type = 5, code = 0 from 10.5.0.51 /* SRI-GW */ ICMPIn: Redirect to 10.4.0.82 /* redirecting to BBN-ENET-2-GW */ Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987020310110000> Received: from TYCHO by SRI-NIC.ARPA with TCP; Tue 3 Feb 87 14:04:55-PST Date: 3 Feb 1987 at 1511-EST Subject: re: Weird Gateway Re-directs! From: hsw at TYCHO.ARPA (Howard Weiss) To: brescia at ccv.bbn.com cc: tcp-ip at sri-nic, jim, franceus, lee, jackson, loscocco, huckaby, hinden at ccv.bbn.com Mike, The redirects were received when ack packets were being sent to BBCC-COLUMBIA in response to an smtp message that was received by TYCHO at 12:10:06 EST. The flurry of redirects did end quickly and we do keep the redirect state information until the network code is restarted. Also, later in the day (after 1630 EST) there was another flurry of redirects which lasted much longer than the one I showed in my earlier message, but I will not send this one out because there are several ftp connections that were being redirected and I cannot tell which redirect is from which connection. Howard ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702032225.AA00909%40ucbvax.Berkeley.EDU] <1987020312283700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hsw@TYCHO.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: re: Weird Gateway Re-directs! Message-ID: <8702032225.AA00909@ucbvax.Berkeley.EDU> Date: Tue, 3-Feb-87 17:28:37 EST Article-I.D.: ucbvax.8702032225.AA00909 Posted: Tue Feb 3 17:28:37 1987 Date-Received: Wed, 4-Feb-87 07:09:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Mike, The redirects were received when ack packets were being sent to BBCC-COLUMBIA in response to an smtp message that was received by TYCHO at 12:10:06 EST. The flurry of redirects did end quickly and we do keep the redirect state information until the network code is restarted. Also, later in the day (after 1630 EST) there was another flurry of redirects which lasted much longer than the one I showed in my earlier message, but I will not send this one out because there are several ftp connections that were being redirected and I cannot tell which redirect is from which connection. Howard ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702032254.AA01357%40ucbvax.Berkeley.EDU] <1987020312390000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Perrine@LOGICON.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: PSN physical locations? Message-ID: <8702032254.AA01357@ucbvax.Berkeley.EDU> Date: Tue, 3-Feb-87 17:39:00 EST Article-I.D.: ucbvax.8702032254.AA01357 Posted: Tue Feb 3 17:39:00 1987 Date-Received: Wed, 4-Feb-87 07:10:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa Is there any way I can find out where the ARPA or MILNET PSN are located? (A file a SRI-NIC, maybe?) I am specifically interested in the San Diego area. I know about NOSC, are there any others? Tom Perrine ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702040110.AA03176%40jupiter.bellcore.com] <1987020315102400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@jupiter.bellcore.com.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Inappropriate responses to broadcasts Message-ID: <8702040110.AA03176@jupiter.bellcore.com> Date: Tue, 3-Feb-87 20:10:24 EST Article-I.D.: jupiter.8702040110.AA03176 Posted: Tue Feb 3 20:10:24 1987 Date-Received: Thu, 5-Feb-87 03:07:44 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 51 Approved: tcp-ip@sri-nic.arpa Some time ago, there was discussion about IP implementations which respond inappropriately to broadcast packets. A number of solutions were offered, the best one (in my opinion) being a flag to tell IP when a packet was received on a hardware broadcast address so that it would not try to forward it or respond to it with an ICMP message. Since then, there seems to have been virtually no progress among the vendors in implementing these fixes. Here at Bellcore we run a rather large network consisting of Ethernets at several locations bridged together with DEC LanBridge 100's and Vitalink Translan-3s. With so many hosts on the same "virtual Ethernet", from time to time broadcast packets with bogus IP addresses are bound to appear. Right now there is one Microvax running Ultrix 1.2 that has its netmask set improperly. A single rwho packet from that machine triggers literally HUNDREDS (as counted with my Excelan Lanalyzer) of ARP requests. This represents practically every host on the network!! I cringe to think that before long many more of our machines will be running 4.3 BSD-derived code that allows the setting of the IP broadcast address to any bogus value the heart desires. At Uniforum in DC the other week I played with the Lanalyzer at the Excelan booth. Guess what? Most of the packets on the net were ARP requests because of one machine that didn't have its IP broadcast address set right! I felt right at home. At least I now know what to say the next time a vendor tells me "get our latest release and then call me back". Before somebody tries to tell me that it's my fault for using bridges on such a large scale, I should point out that the Vitalink boxes make it very easy to cut off misbehaving hosts. By entering the Ethernet address of the aforementioned Microvax into the bridge's "twit list", the offending traffic is isolated to one location. Even with these problems our use of bridging has improved our network's availability enormously over our old practice of using UNIX machines as IP gateways. It was worth it just to be able to get rid of routed (RIP) for internal communications. If something more formal than the TCP-IP archives is needed to get the vendors to act, I hereby volunteer to write the RFC. I would require that the link or subnet pass a "multicast" bit to IP indicating when an incoming packet is received on a hardware broadcast or multicast address. If this bit is set, IP must refuse to forward the packet or answer it with an ICMP message. It should also refuse to pass the packet up to TCP, should its protocol ID appear in the header. Naturally, the multicast bit would always be zero for packets received on non-broadcast and point-to-point subnets. Since there are so many incompatible conventions for IP broadcast addresses, I suggest that they be done away with altogether. Since gateways never forward broadcasts, the IP destination address in a broadcast UDP packet has no real meaning and should be ignored. The fact that the packet was sent to the hardware broadcast address should be enough to say "this is a broadcast packet". Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702040656.AA16932%40caip.rutgers.edu] <1987020320555800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: scarter@CAIP.RUTGERS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8702040656.AA16932@caip.rutgers.edu> Date: Wed, 4-Feb-87 01:55:58 EST Article-I.D.: caip.8702040656.AA16932 Posted: Wed Feb 4 01:55:58 1987 Date-Received: Thu, 5-Feb-87 03:28:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa Path: caip!scarter From: scarter@caip.RUTGERS.EDU (Stephen M. Carter) Newsgroups: mod.protocols.tcp-ip Subject: Re: Looking for Tcp/Ip for Prime's PRIMOS system Message-ID: <4060@caip.RUTGERS.EDU> Date: 4 Feb 87 06:55:57 GMT References: <8702030109.AA11365@ucbvax.Berkeley.EDU> Reply-To: scarter@caip.UUCP (Stephen M. Carter) Organization: Rutgers Univ., New Brunswick, N.J. Lines: 21 In article <8702030109.AA11365@ucbvax.Berkeley.EDU> Henry Nussbacher writes: >I have seen that Prime has a Tcp/Ip version. I am interested in hearing >any user experience with this package - costs, benefits, pros, cons, etc. > >Please reply directly to me since I am not on this list. ...Also add to this question the status of hardware the tcp uses. When I first asked Prime these questions, they said that tcp only interfaced to their X.25 hardware. Plans for an Ethernet board have not been considered (they were thinking about OEM'ing Bridge's X.25/Ethernet gateway as this interface). Granted this was almost two years ago, anyone know the latest? -SCarter uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!scarter arpa: SCARTER@RUTGERS or SCARTER@RED.RUTGERS.EDU ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702041957.AA20185%40ucbvax.Berkeley.EDU] <1987020408162300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rjwelsh@CCT.BBN.COM ("Robert J. Welsh") Newsgroups: mod.protocols.tcp-ip Subject: re: new 32 bit address layout ? Message-ID: <8702041957.AA20185@ucbvax.Berkeley.EDU> Date: Wed, 4-Feb-87 13:16:23 EST Article-I.D.: ucbvax.8702041957.AA20185 Posted: Wed Feb 4 13:16:23 1987 Date-Received: Sat, 7-Feb-87 06:59:49 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 102 Approved: tcp-ip@sri-nic.arpa Lars Poulson writes: >A private communication mentioned that >> The current 32-bit address is divided into 4 fields (N,H,L,I): >> >> | N | H | L | I | >> |--------|----------|--------|--------| >> >> The proposed division (N,H1,H2,H3,F,G,L1,I1,I2) is according to >> that which is to be proposed by BBN and the DDN PMO in an upcoming >> RFC expected out in the January timeframe: >> >> | N |H1 H2|H3 F|G|L1|I1| I2 | >> |-------|---------|------------|-------| >> >> The F field is proposed as a flag to indicate a X.25 Logical Address; >> the G field is reserved for future use. With Logical Addressing >> the H field is proposed to be expanded to 10 bits (H1,H2,H3) and the >> I field similarily (I1,I2). With Logical Addressing, there will >> remain a 16-bit X.25 Logical Address (H,I). This means there are >> 4 Internet Addresses which map to the same X.25 Logical Address >> (those which differ only in the H3,L1, and I1 fields). For >> compatibility with existing DDN X.25 the H field must still be >> greater than 64 for all X.25 Logical Addresses. > >This prompts a few questions: > >(>1) Current address formats: > > I can see in HOSTS.TXT that currently class A networks based > on C/30 PSN's use the above format, mostly with > N = network number (1-126) > H = port number on PSN > L = 0 (can be non-zero with a port expander) > I = PSN number in network > > I believe that class B networks based on BBN PSN's use > N,H = network number (128.1 - 191.255) > L = port number on PSN > I = PSN number in network > > I don't know what format is used for class C PSN's. PSNs (Packet Switch Nodes - formerly IMP) do not know about IP leader classes. Only gateways and hosts know about IP. Class C IP address: |110|---------------------|--------| 21 bit net no. local host To use logical addr. with this leader limits the addressing range. When a gateway translates the IP addr to 1822 or whatever, it must supply the upper 8 bits of the logical name (a constant) and use "local host" as the lower 8 bits of the name. This leaves you with a address range of 377 (octal) hosts. > >(2) Logical addressing. > As I understand it, the above physical addressing scheme is > used throughout ARPAnet and MILNET; other networks use > "logical addressing". Software generally has to be configured > to know which of the two schemes is in use. > When a host comes up, the PSN tells it its address if the > network is physical, but the host tells the PSN its address > if the network is logical. > > Physical and logical addressing cannot be mixed in the same > network. Not true. Physical and Logical addressing can coexist on the same network. Furthermore, we can even support physical and logical addressing hosts from the same IMP. > >(3) IP addresses versus AHIP addresses. > Logical addressing is a feature of the 1822 interface protocol > (AHIP) and there is a standard translation from IP to AHIP. Logical Addressing requires the 1822L leader. > >(4) IP addresses versus X.25 addresses > The conversion between IP addresses and X.25 addresses is defined > in the DDN X.25 spec. so long as the class A "L" field is not used. > Use of bits in the IP address to trigger a request for logical > addresses is a new feature that may invalidate current port > expander implementations. > >(5) RFC review. > BBN and the DDN PMO are discussing this, but no decision will be > made until the RFC has had a chance to elicit comments from the > protocol research community ? > >Did I get all of that right ? >Lars Poulsen, ACC Customer Service <*> ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987020408162301> Received: from cct.bbn.com by SRI-NIC.ARPA with TCP; Wed 4 Feb 87 11:07:01-PST Date: Wed, 4 Feb 87 13:16:23 EST From: "Robert J. Welsh" Subject: re: new 32 bit address layout ? To: tcp-ip@sri-nic.arpa Cc: rjwelsh@cct.bbn.com Lars Poulson writes: >A private communication mentioned that >> The current 32-bit address is divided into 4 fields (N,H,L,I): >> >> | N | H | L | I | >> |--------|----------|--------|--------| >> >> The proposed division (N,H1,H2,H3,F,G,L1,I1,I2) is according to >> that which is to be proposed by BBN and the DDN PMO in an upcoming >> RFC expected out in the January timeframe: >> >> | N |H1 H2|H3 F|G|L1|I1| I2 | >> |-------|---------|------------|-------| >> >> The F field is proposed as a flag to indicate a X.25 Logical Address; >> the G field is reserved for future use. With Logical Addressing >> the H field is proposed to be expanded to 10 bits (H1,H2,H3) and the >> I field similarily (I1,I2). With Logical Addressing, there will >> remain a 16-bit X.25 Logical Address (H,I). This means there are >> 4 Internet Addresses which map to the same X.25 Logical Address >> (those which differ only in the H3,L1, and I1 fields). For >> compatibility with existing DDN X.25 the H field must still be >> greater than 64 for all X.25 Logical Addresses. > >This prompts a few questions: > >(>1) Current address formats: > > I can see in HOSTS.TXT that currently class A networks based > on C/30 PSN's use the above format, mostly with > N = network number (1-126) > H = port number on PSN > L = 0 (can be non-zero with a port expander) > I = PSN number in network > > I believe that class B networks based on BBN PSN's use > N,H = network number (128.1 - 191.255) > L = port number on PSN > I = PSN number in network > > I don't know what format is used for class C PSN's. PSNs (Packet Switch Nodes - formerly IMP) do not know about IP leader classes. Only gateways and hosts know about IP. Class C IP address: |110|---------------------|--------| 21 bit net no. local host To use logical addr. with this leader limits the addressing range. When a gateway translates the IP addr to 1822 or whatever, it must supply the upper 8 bits of the logical name (a constant) and use "local host" as the lower 8 bits of the name. This leaves you with a address range of 377 (octal) hosts. > >(2) Logical addressing. > As I understand it, the above physical addressing scheme is > used throughout ARPAnet and MILNET; other networks use > "logical addressing". Software generally has to be configured > to know which of the two schemes is in use. > When a host comes up, the PSN tells it its address if the > network is physical, but the host tells the PSN its address > if the network is logical. > > Physical and logical addressing cannot be mixed in the same > network. Not true. Physical and Logical addressing can coexist on the same network. Furthermore, we can even support physical and logical addressing hosts from the same IMP. > >(3) IP addresses versus AHIP addresses. > Logical addressing is a feature of the 1822 interface protocol > (AHIP) and there is a standard translation from IP to AHIP. Logical Addressing requires the 1822L leader. > >(4) IP addresses versus X.25 addresses > The conversion between IP addresses and X.25 addresses is defined > in the DDN X.25 spec. so long as the class A "L" field is not used. > Use of bits in the IP address to trigger a request for logical > addresses is a new feature that may invalidate current port > expander implementations. > >(5) RFC review. > BBN and the DDN PMO are discussing this, but no decision will be > made until the RFC has had a chance to elicit comments from the > protocol research community ? > >Did I get all of that right ? >Lars Poulsen, ACC Customer Service <*> ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12276567612.70.ROMKEY%40XX.LCS.MIT.EDU] <1987020423200100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROMKEY@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: ARP, ethernet and starlan Message-ID: <12276567612.70.ROMKEY@XX.LCS.MIT.EDU> Date: Thu, 5-Feb-87 04:20:01 EST Article-I.D.: XX.12276567612.70.ROMKEY Posted: Thu Feb 5 04:20:01 1987 Date-Received: Sat, 7-Feb-87 11:08:54 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 39 Approved: tcp-ip@sri-nic.arpa Here's a definition of a phrase I will use in this message. I just want to avoid any ambiguity at the onset: Here's a problem: Starlan is an 802.3 network; it looks like ethernet except it's cabled differently, it runs at 1Mbps instead of 10Mbps and (I think but I'm not certain) it's manchester encoding is slightly different. I need to bring up TCP/IP on Starlan, and I have a question: What ARP hardware type should I use? My immediate reaction is to go to the number czar and ask him to assign a starlan number and use that. But wait...there's a catch. Some vendors have or are developing MAC-level bridges which connect ethernets to starlans (as well as other ethernets). For this type of connection to work correctly, Starlan must have the same ARP hardware type as ethernet or else machines on one net connect to another via a MAC-level bridge will discard ARP requests because they will be for the wrong hardware type (I assume that we *do* check this field, after all...) and no communication will occur. Would the number czar care to comment? Also, does anyone know if any vendors are planning to develop an 802.3 to 802.5 MAC-level bridge? Different waveforms and different speeds, I know, but similar packet headers. If they are, then we've already lost because there is already an 802.5 ARP hardware type which is different from ethernet. Maybe there should be an 802.x ARP hardware type... John Romkey FTP Software, Inc. (617) 864-1711 PO Box 150 UUCP: romkey@mit-vax.UUCP Kendall Square Branch ARPA: romkey@xx.lcs.mit.edu Boston, MA, 02142 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702051740.AA10671%40ucbvax.Berkeley.EDU] <1987020506405000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ahill@CC7.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8702051740.AA10671@ucbvax.Berkeley.EDU> Date: Thu, 5-Feb-87 11:40:50 EST Article-I.D.: ucbvax.8702051740.AA10671 Posted: Thu Feb 5 11:40:50 1987 Date-Received: Sat, 7-Feb-87 12:47:27 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 38 Approved: tcp-ip@sri-nic.arpa In the past few days BBNCC has recorded numerous instances of non-BBN supported gateways attempting to communicate with a non- existent host. The subnet only provides us with reports of attempts which were delayed by temporary resources shortages within the ARPANET. BBN believes that all connection attempts would return a destination host dead (1822 type 6 subtype 9). These attempts are being made to address 10.3.0.52 which is currently unoccupied but used to be USC-ISIB. BBN estimates that there are between 200,000 and 2,000,000 attempts per 24 hour period. BBN is not able to determine the nature of the attempts or the originating source(s) since the origin is behind gateways. The following is a list of the host/gateways that originated or forwarded traffic destined for 10.3.0.52. Any information on what is causing this traffic would be appreciated. It is a likely candidate for contributing to ARPANET congestion. CSNET 7/82 RELAY 4/5 MITGW 0/77 UCBAR 0/78 UCBVX 2/78 TUCC 6/96 CMUD 2/14 CORNL 3/96 BBNMG 5/5 TRIV 0/25 LBMGW 0/68 HARV 0/9 ASC 1/37 CUGAR 3/89 AIGW 3/6 SUN 7/2 TEXAS 0/62 UPENN 4/96 ROCH 0/15 THE TABLE IS ORDERED BY FREQUENCY OF REPORTS. THE TOP FOUR ARE TWO TO FOUR TIMES HIGHER THAN THE REST. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987020506405001> Received: from cc7.bbn.com by SRI-NIC.ARPA with TCP; Thu 5 Feb 87 09:25:10-PST Date: Thu, 5 Feb 87 11:40:50 EST From: "Alan R. Hill" To: tcp-ip@sri-nic.arpa Cc: mills@huey.udel.edu, arpanetmgr@ddn1.arpa In the past few days BBNCC has recorded numerous instances of non-BBN supported gateways attempting to communicate with a non- existent host. The subnet only provides us with reports of attempts which were delayed by temporary resources shortages within the ARPANET. BBN believes that all connection attempts would return a destination host dead (1822 type 6 subtype 9). These attempts are being made to address 10.3.0.52 which is currently unoccupied but used to be USC-ISIB. BBN estimates that there are between 200,000 and 2,000,000 attempts per 24 hour period. BBN is not able to determine the nature of the attempts or the originating source(s) since the origin is behind gateways. The following is a list of the host/gateways that originated or forwarded traffic destined for 10.3.0.52. Any information on what is causing this traffic would be appreciated. It is a likely candidate for contributing to ARPANET congestion. CSNET 7/82 RELAY 4/5 MITGW 0/77 UCBAR 0/78 UCBVX 2/78 TUCC 6/96 CMUD 2/14 CORNL 3/96 BBNMG 5/5 TRIV 0/25 LBMGW 0/68 HARV 0/9 ASC 1/37 CUGAR 3/89 AIGW 3/6 SUN 7/2 TEXAS 0/62 UPENN 4/96 ROCH 0/15 THE TABLE IS ORDERED BY FREQUENCY OF REPORTS. THE TOP FOUR ARE TWO TO FOUR TIMES HIGHER THAN THE REST. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702051708.AA09339%40monk.proteon.com] <1987020507081700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jas@MONK.PROTEON.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: ARP, ethernet and starlan Message-ID: <8702051708.AA09339@monk.proteon.com> Date: Thu, 5-Feb-87 12:08:17 EST Article-I.D.: monk.8702051708.AA09339 Posted: Thu Feb 5 12:08:17 1987 Date-Received: Sat, 7-Feb-87 12:46:43 EST References: <12276567612.70.ROMKEY@XX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 15 Approved: tcp-ip@sri-nic.arpa Ah, the wonderful gifts we have received courtesy of 802.2. If Starlan is 802.3, then you really "should" use 802.2, the same as is used for 802.5. Pile SNAP on top of 802.2, and away you go. Of course, this nails the Ethernet 2.0 people, but that's a mess we have to face. What ARP hardware type is being used for 802.2/802.5? Maybe we indeed should have a 802.2 "hardware" type. U-B has announced an 802.3/802.5 MAC-level bridge. It poses a lot of interesting questions, if anyone from U-B wants to edify us it would help iron out how we should design 802.2/SNAP/ARP. Problems like this show the advantages of routers over bridges... ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702051825.AA01476%40sluggo.sun.com] <1987020508252600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: melohn@SUN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ARP, ethernet and starlan Message-ID: <8702051825.AA01476@sluggo.sun.com> Date: Thu, 5-Feb-87 13:25:26 EST Article-I.D.: sluggo.8702051825.AA01476 Posted: Thu Feb 5 13:25:26 1987 Date-Received: Tue, 10-Feb-87 06:42:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 91 Approved: tcp-ip@sri-nic.arpa > ...Maybe there should be an 802.x ARP hardware type... From the tcp-ip archives: Date: 12 Oct 1986 16:26:38 PDT From: POSTEL@B.ISI.EDU Subject: IP on 802 To: tcp-ip@SRI-NIC.ARPA Well, i haven't got an RFC out yet, but the procedure described in the following memo should be used anyway. There is a small and ever decreasing possibility that the values of K1 and K2 may be different than indicated below, so consider the possibility of having them changable in your implementation. In the mean time please go ahead and use this encapsulation format for doing IP and ARP (and other things) on 802 nets, using K1=170, and K2=0. The IEEE likes to talk about bytes in little endian order so they say K1 is 01010101. The ARPA protocols have everything in big endian order so that K1 becomes 10101010 binary or AA hex or 170 decimal. This value is pretty definite. The value of K2 is somewhat less certain, but no evidience to the contrary has surfaced yet. --jon. *** begin *** Date: 29 Aug 1986 19:27:12 PDT From: POSTEL@B.ISI.EDU Subject: How to IP & ARP on 802 Nets To: tcp-ip@SRI-NIC.ARPA Hello. At an ad hoc special session on "IEEE 802 Networks and ARP" held during the recent TCP Vendors Workshop, an approach to a consistent way to sent DOD-IP datagrams and other IP related protocols on 802 networks was developed. Due to some evolution of the IEEE 802.2 standards and the need to provide for a standard way to do additional DOD-IP related protocols (such as Address Resolution Protocol (ARP)) on IEEE 802 networks, the following new policy is being proposed, which will replace the current policy (see page 26 of RFC-960 and RFC-948). The proposal is for DDN and ARPA-Internet community to use IEEE 802.2 encapsulation on 802.3, 802.4, and 802.5 networks by using the SNAP with an organization code indicating that the following 16 bits specify the Ethertype code (where IP = 2048 (0800 hex), see page 27 of RFC-960). ...--------+--------+--------+ MAC Header| Length | 802.{3/4/5} MAC Header ...--------+--------+--------+ +--------+--------+--------+ | Dsap=K1| Ssap=K1| control| 802.2 SAP Header +--------+--------+--------+ +--------+--------+---------+--------+--------+ |protocol id or org code =K2| Ether Type | 802.2 SNAP Header +--------+--------+---------+--------+--------+ The values of K1 and K2 must be assigned by the IEEE. We believe there is already assigned a value of K1 that indicates that the 5-octet SNAP header follows. We can use this value. There may be a value of K2 that is already assigned that indicates that the last two octets of the SNAP header holds the EtherType. If so we may be able to use this value. This remains to be explored. The EtherTypes are assigned by Xerox (as always). The total length of the SAP Header and the SNAP header is 8-octets, making the 802.2 protocol overhead come out on a nice octet boundary. If we can not quickly resolve the issue of the values for K1 and K2, we will push for the assignment of a sap value (a K1 value) to indicate "IP related protocols" and do our own multiplexing (much like that proposed above). In any case, we will not create incompatible interpretations of headers already in use on 802 networks. *** end *** ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987020513210000> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Thu 5 Feb 87 16:05:14-PST Date: 5 Feb 1987 18:21-EST Sender: URBANIAK@G.BBN.COM Subject: Re: seeking source for Ether packet types and vendor address... From: Urbaniak@G.BBN.COM To: dunigan@ORNL-MSR.ARPA, tcp-ip@SRI-NIC.ARPA Cc: Urbaniak@G.BBN.COM, rtavilla@RCCA.BBN.COM Message-ID: <[G.BBN.COM] 5-Feb-87 18:21:17.URBANIAK> In-Reply-To: <[G.BBN.COM]27-Jan-87 17:24:31.URBANIAK> This list of Ethernet vendor addresses and Type Fields includes responses of the last week. Current BBN Ethernet and IEEE802.3 "Type" Fields The 13th and 14th octets of an Ethernet or IEEE802.3 packet (after the preamble) consist of the "Type" or "Length" field. These are formerly assigned by Xerox, currently assigned by IEEE. Some assignments are public, others private. Information currently available includes: Xerox Public Ethernet Packet Type documentation; IEEE802.3 Std, but not yet further documentation from IEEE; NIC RFC960; knowledge of some BBN Private Type Field values. Hex 0000-05EE IEEE802.3 Length Field 0600 Xerox NS IDP * 0800 DOD IP * # 0801 X.75 Internet 0802 NBS Internet 0803 ECMA Internet 0804 CHAOSnet 0805 X.25 Level 3 0806 ARP * (for IP and for CHAOS) 0807 XNS Compatibility 081C Symbolics Private 1000 Berkeley Trailer negotiation 1001-100F Berkeley Trailer encapsulation 1600 VALID-machine protocol? * 5208 BBN Simnet Private 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 6003 DECNET Phase IV 6004 DEC LAT 6005 DEC protocol, at interface initialization? 6006 DEC user protocol 8003 Cronus VLN 8004 Cronus Direct 8005 HP Probe protocol 8006 Nestar 8010 Excelan 8035 Reverse ARP 8038 DEC LanBridge Management 805B Stanford V Kernel, experimental 805C Stanford V Kernel, production 809B AppleTalk over Ethernet (Kinetics only?) 9000 Loopback (Configuration Test Protocol) FF00 BBN VITAL-LanBridge cache wakeups * These protocols use Ethernet broadcast, where multicast would be preferable. # BBN Butterfly Gateways also use 0800 for non-IP, with IP version field = 3. Ethernet Vendor Addresses Ethernet hardware addresses are 48 bits, expressed as 12 hexadecimal digits (0-9, plus A-F, capitalized). These 12 hex digits consist of the first/left 6 digits (which should match the vendor of the Ethernet interface within the station) and the last/right 6 digits which specify the interface serial number for that interface vendor. Currently we have noted the following vendor addresses, on the BBN Corporate Ethernet. 000093 Proteon 0000AA Xerox Xerox machines 000102 BBN BBN internal usage (not registered) 00DD00 Ungermann-Bass 020701 Interlan UNIBUS or QBUS machines 02608C 3Com IBM PC; Imagen; Valid 02CF1F CMC Masscomp 080002 Bridge 080005 Symbolics Symbolics LISP machines 080009 Hewlett-Packard 080010 AT+T 080014 Excelan BBN Butterfly, Masscomp 08001A Data General 080020 Sun Sun machines 08002B DEC UNIBUS or QBUS machines, VAXen, LANBridges (DEUNA, DEQNA, DELUA) 080047 Sequent 08004C Encore 080068 Ridge 080089 Kinetics AppleTalk-Ethernet interface 08008B Pyramid 08008D XyVision XyVision machines AA0003 DEC Physical address for some DEC machines AA0004 DEC Logical address for systems running DECNET Ethernet addresses might be written unhyphenated (e.g. 123456789ABC), or with one hyphen (e.g. 123456-789ABC), but should be written hyphenated by octets (e.g. 12-34-56-78-9A-BC). These addresses are physical station addresses, not multicast nor broadcast, so the second hex digit (reading from the left) will be even, not odd. At present, it is not clear how the IEEE assigns Ethernet block addresses. Whether in blocks of 2**24 or 2**25, and whether multicasts are assigned with that block or separately. A portion of the vendor block address is reportedly assigned serially, with the other portion intentionally assigned randomly. If there is a global algorithm for which addresses are designated to be physical (in a chipset) versus logical (assigned in software), I am unaware of the algorithm. Current BBN Ethernet Multicast Addresses I do not have protocol specifications for DECNET and the VALID protocol at this time. There is no XNS or VALID router at present; those packets might be Hello packets, or gateway query packets. Ethernet Type Address Field Usage Multicast Addresses: 09-00-2B-01-00-01 8038 DEC LanBridge Hello packets 1 packet per second, sent by the lowest-addressed LanBridge AB-00-00-01-00-00 6001 DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance AB-00-00-02-00-00 6002 DEC Maintenance Operation Protocol (MOP) Remote Console 1 System ID packet every 8-10 minutes, by every: DEC LanBridge DEC DEUNA interface DEC DELUA interface DEC DEQNA interface (in a certain mode) AB-00-00-03-00-00 6003 DECNET Phase IV end node Hello packets 1 packet every 15 seconds, sent by each DECNET host AB-00-00-04-00-00 6003 DECNET Phase IV Router Hello packets 1 packet every 15 seconds, sent by the DECNET router AB-00-00-05-00-00 ???? Reserved DEC through AB-00-03-FF-FF-FF AB-00-04-00-00-00 ???? Reserved DEC customer private use through AB-00-04-FF-FF-FF CF-00-00-00-00-00 9000 Ethernet Configuration Test protocol (Loopback) Broadcast Address: FF-FF-FF-FF-FF-FF 0600 XNS packets, Hello or gateway search? 6 packets every 15 seconds, per XNS station FF-FF-FF-FF-FF-FF 0800 IP (e.g. RWHOD via UDP) as needed FF-FF-FF-FF-FF-FF 0806 ARP (for IP and CHAOS) as needed FF-FF-FF-FF-FF-FF 1600 VALID packets, Hello or gateway search? 1 packets every 30 seconds, per VALID station ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870205183850.7.DCP%40KOYAANISQATSI.S4CC.Symbolics.COM] <1987020513380000> 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: ARP, ethernet and starlan Message-ID: <870205183850.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Thu, 5-Feb-87 18:38:00 EST Article-I.D.: KOYAANIS.870205183850.7.DCP Posted: Thu Feb 5 18:38:00 1987 Date-Received: Sat, 7-Feb-87 17:23:29 EST References: <8702051708.AA09339@monk.proteon.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa The intention of the hardware type field in ARP packets is to distinguish semantically different types of hardware. If your Starlan 802.3 network is "semantically the same" as Ethernet, then for the purposes of ARP it is Ethernet. "Semantically the same" roughly means "has the same number of hardware bytes in the address." Compare this with a 3Mbit Ethernet which has an 8 bit hardware address, or an MIT Chaos net which has a 16 bit hardware address. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12276757928.14.ROMKEY%40XX.LCS.MIT.EDU] <1987020516452700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROMKEY@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ARP, ethernet and starlan Message-ID: <12276757928.14.ROMKEY@XX.LCS.MIT.EDU> Date: Thu, 5-Feb-87 21:45:27 EST Article-I.D.: XX.12276757928.14.ROMKEY Posted: Thu Feb 5 21:45:27 1987 Date-Received: Sat, 7-Feb-87 16:59:35 EST References: <8702051825.AA01476@sluggo.sun.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Um. Yes, in fact, I've implemented an 802.5 IP driver according to that spec. I'd never read it well enough to notice that Jon Postel consistently said "802" instead of "802.5". Then I guess all 802.mumble networks should use the same ARP hardware type? - john ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12276759328.14.ROMKEY%40XX.LCS.MIT.EDU] <1987020516530900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROMKEY@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ARP, ethernet and starlan Message-ID: <12276759328.14.ROMKEY@XX.LCS.MIT.EDU> Date: Thu, 5-Feb-87 21:53:09 EST Article-I.D.: XX.12276759328.14.ROMKEY Posted: Thu Feb 5 21:53:09 1987 Date-Received: Sat, 7-Feb-87 16:35:45 EST References: <870205183850.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa I hate to be nit picky (really, I do) but ARP has both a hardware type field and a hardware address length field. I suppose the address length field could be of use on networks where the hardware address was variable length? Yes, Starlan is semantically the same as ethernet, so I according to your argument they should have the same hardware type. I tend to agree... - john ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12276760721.14.ROMKEY%40XX.LCS.MIT.EDU] <1987020517004800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROMKEY@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: More 802.x and ethernet and ARP stuff Message-ID: <12276760721.14.ROMKEY@XX.LCS.MIT.EDU> Date: Thu, 5-Feb-87 22:00:48 EST Article-I.D.: XX.12276760721.14.ROMKEY Posted: Thu Feb 5 22:00:48 1987 Date-Received: Sat, 7-Feb-87 16:35:59 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa I guess I have two more questions: 1. Should we encapsulate IP over Starlan the Blue Book (old ethernet) way or the 802.2 way? I would have to argue for now to do it the Blue Book way because with MAC level bridges connecting an ethernet to a starlan the Blue Book ethernet hosts couldn't talk to the 802.2/3 Starlan hosts. 2. Awful question of the day: should we (the Internet community, etc.) ever ever convert to using 802.2 IP encapsulations over ethernet? If we don't, we're not going to find that some hosts can't talk to one another in certain network configurations involving MAC level bridges. If we do, we're probably going to suffering from the bruises for two or three years. If we should convert, then when? I *am* sorry to have asked the latter question, really. But it comes up more and more often these days. Also, re: my first message on the topic, sorry, I was making it up as I was going along and in one draft I decided to define some term which meant 'MAC level bridge' and then I realized I could say 'MAC level bridge' and I left this line at the beginning of the message saying "Let me define something to avoid confusion: (great gaping hole)"... - john ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702060311.AA04536%40sluggo.sun.com] <1987020517111600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: melohn@SUN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ARP, ethernet and starlan Message-ID: <8702060311.AA04536@sluggo.sun.com> Date: Thu, 5-Feb-87 22:11:16 EST Article-I.D.: sluggo.8702060311.AA04536 Posted: Thu Feb 5 22:11:16 1987 Date-Received: Sat, 7-Feb-87 16:48:23 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 2 Approved: tcp-ip@sri-nic.arpa Technically the "SNAP" idea applies to 802.2, the LLC(2) layer, therefore it works on any of the MAC(1) layer media, include 802.3, .4, and .5. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702060438.AA29275%40topaz.rutgers.edu] <1987020518380300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hedrick@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8702060438.AA29275@topaz.rutgers.edu> Date: Thu, 5-Feb-87 23:38:03 EST Article-I.D.: topaz.8702060438.AA29275 Posted: Thu Feb 5 23:38:03 1987 Date-Received: Sat, 7-Feb-87 18:12:20 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa We list ISIB as being a root domain server. It isn't our first, so we probably never use it. But I'd be willing to bet that some other sites have it listed as well, and this is a large part of the problem. When root domain servers are removed, I think you should make several very prominent announcements in all possible newsgroups. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12276837871.14.MKL%40SRI-NIC.ARPA] <1987020600043600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MKL@SRI-NIC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <12276837871.14.MKL@SRI-NIC.ARPA> Date: Fri, 6-Feb-87 05:04:36 EST Article-I.D.: SRI-NIC.12276837871.14.MKL Posted: Fri Feb 6 05:04:36 1987 Date-Received: Sat, 7-Feb-87 17:58:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa From the list of hosts/gateways that are trying to talk to ISIB, my guess is that most of the traffic headed there are domain server queries. All hosts should check their server entries to make sure that ISIB (10.3.0.52) is no longer listed as a root server. This was announced quite a while ago. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12276877219.32.SHEP%40XX.LCS.MIT.EDU] <1987020603404400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: SHEP@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: nuerous attempts to communicate with a non-existent host Message-ID: <12276877219.32.SHEP@XX.LCS.MIT.EDU> Date: Fri, 6-Feb-87 08:40:44 EST Article-I.D.: XX.12276877219.32.SHEP Posted: Fri Feb 6 08:40:44 1987 Date-Received: Sun, 8-Feb-87 05:28:27 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa I believe USC-ISIB used to be listed as a top-level domain server. If some hosts still contain USC-ISIB and 10.3.0.52 in their nameserver configurations, that might explain the continued attempts to communicate with the "non-existent host". (I did find one host behind MITGW for which this is true.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702091951.AA20912%40ucbvax.Berkeley.EDU] <1987020604515800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jb@cs.brown.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Packets to 10.3.0.52 (USC-ISIB) Message-ID: <8702091951.AA20912@ucbvax.Berkeley.EDU> Date: Fri, 6-Feb-87 09:51:58 EST Article-I.D.: ucbvax.8702091951.AA20912 Posted: Fri Feb 6 09:51:58 1987 Date-Received: Tue, 10-Feb-87 06:33:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa In response to Alan Hill's remarks about a large number of packets being sent to a decommisioned host, I suspect that the primary cause is that USC-ISIB used to be one of the root servers for the name-domain system. Many sights probably have not changed there configuration information to properly reflect the change. UC Berkeley, and CSNet are both heavy users of the system. There should be some attempt to notify the domain administrators and inform them of this change. Jim Bloom ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987020604515801> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Sun 8 Feb 87 20:50:06-PST Received: from [128.89.1.80] by RELAY.CS.NET id cx01484; 8 Feb 87 23:36 EST Received: from cs.brown.edu by csnet-relay.csnet id ac00420; 7 Feb 87 19:42 EST Received: by cs.brown.edu (5.51/1.00) id AA02744; Fri, 6 Feb 87 09:50:45 EST From: Jim Bloom To: ahill@CC7.BBN.COM, tcp-ip@SRI-NIC.ARPA Subject: Packets to 10.3.0.52 (USC-ISIB) Cc: mills@HUEY.UDEL.EDU, arpanetmgr@DDN1.ARPA Date: Fri, 06 Feb 87 09:51:58 EST In response to Alan Hill's remarks about a large number of packets being sent to a decommisioned host, I suspect that the primary cause is that USC-ISIB used to be one of the root servers for the name-domain system. Many sights probably have not changed there configuration information to properly reflect the change. UC Berkeley, and CSNet are both heavy users of the system. There should be some attempt to notify the domain administrators and inform them of this change. Jim Bloom ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870206100333.5.DCP%40KOYAANISQATSI.S4CC.Symbolics.COM] <1987020605030000> 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: ARP, ethernet and starlan Message-ID: <870206100333.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Fri, 6-Feb-87 10:03:00 EST Article-I.D.: KOYAANIS.870206100333.5.DCP Posted: Fri Feb 6 10:03:00 1987 Date-Received: Sun, 8-Feb-87 01:44:09 EST References: <12276759328.14.ROMKEY@XX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Date: Thu 5 Feb 87 21:53:09-EST From: John Romkey I hate to be nit picky (really, I do) but ARP has both a hardware type field and a hardware address length field. I suppose the address length field could be of use on networks where the hardware address was variable length? That, and the ability for monitors to be able to parse the request/responses without knowing the semantics of the hardware or software types. (Though how it could not know the hardware type is probably rhetorical.) Yes, Starlan is semantically the same as ethernet, so I according to your argument they should have the same hardware type. I tend to agree... - john ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12277078297.16.ROMKEY%40XX.LCS.MIT.EDU] <1987020622051800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROMKEY@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: the IEEE/Blue Book problem: an idea Message-ID: <12277078297.16.ROMKEY@XX.LCS.MIT.EDU> Date: Sat, 7-Feb-87 03:05:18 EST Article-I.D.: XX.12277078297.16.ROMKEY Posted: Sat Feb 7 03:05:18 1987 Date-Received: Tue, 10-Feb-87 06:41:09 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 64 Approved: tcp-ip@sri-nic.arpa I think things aren't as grim as I originally thought they were. Here's some background, and why. I believe we need to switch over to IEEE formats on ethernet, away from Blue Book, IF companies are going to be selling 802.3 to 802.5 MAC-level bridges. If two machines running IP on a token ring and an ethernet can't talk to one another via the bridge, we're going to be shot on sight (and complained at, too). [Personally, I'd rather just ignore the whole issue, but I think if we do then we're going to end up with a lot of broken networks.] I believed there was a nasty problem in converting the IP encapsulation format, but now I think I know a way around it. The problem is that while it's easy to receive both Blue Book and IEEE IP packets at the same time (just accept both packet formats), it's difficult to decide which format to transmit. You could have a switch in the operating system or network code that sets this, but that's not good enough; it needs to be on a per-host basis. This had me very worried, since this sort of transition would be TRULY PAINFUL. There would be many problems with two TCP hosts on the same cable not being able to talk to one another, and I think it would mean general setbacks to the TCP/IP "cause". Then I had an inspiration based on the way that 4.3 Unix negotiates the use of trailers. First, add a flag to each entry in your ARP cache showing whether the host speaks IEEE or Blue Book formats. Then, when you want to send a packet to a host: 1. See if the host is in your ARP cache. If it is, send the packet formatted according to the setting of this flag. 2. If it isn't, try sending an IEEE ARP at the host. If this succeeds, put an entry in the ARP cache, and note that the host likes IEEE formats. 3. If it doesn't respond, try sending a Blue Book ARP at the host. Again, if it succeeds, put an entry in the ARP cache and note that the host likes Blue Book formats. 4. If it doesn't succeed, then do whatever it is you do when ARP fails. Note that this algorithm only wants to be followed on an ethernet or IEEE 802.3 network, not on token ring or the other 802 networks. Also, for this to work, all IEEE ARP packets all have the same ARP hardware type field, regardless of which IEEE network they're on. As a side note, receivers do not distinguish between IEEE ARP and Blue Book ARP based on the hardware types, because the ARP's are *also* encapsulated differently in each case, so a Blue Book-only host will throw away any IEEE ARP's it gets. This doesn't really matter, but it might not be obvious from some of my previous messages on this subject. One (hopefully last) question: what would happen if a MAC-level bridge had to forward a Blue Book packet to, say, an 802.5 ring? Finally, I don't recommend anyone follow the algorithm I have described above unless it receives some sort of official endoresment. John Romkey FTP Software, Inc. (617) 864-1711 PO Box 150 UUCP: romkey@mit-vax.UUCP Kendall Square Branch ARPA: romkey@xx.lcs.mit.edu Boston, MA, 02142 ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702072302.a014307%40Huey.UDEL.EDU] <1987020718021600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@LOUIE.UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Inappropriate responses to broadcasts Message-ID: <8702072302.a014307@Huey.UDEL.EDU> Date: Sat, 7-Feb-87 23:02:16 EST Article-I.D.: Huey.8702072302.a014307 Posted: Sat Feb 7 23:02:16 1987 Date-Received: Tue, 10-Feb-87 06:32:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Phil, The fuzzball gateways used on the NSFNET Backbone, among other places, incorporate a "martian filter" that grounds packets for the various IP braodcast addresses, as well as other reserved addresses (see RFC-990). At least one other gateway system (cisco) allegedly does the same. As you know from my previous messages to this list, gateways that forward IP broadcast packets can creat astonishing mischief in quite surprising places. Your suggestion on a mechanism to prevent forwarding of multicast packets was suggested to the INENG Task Force some time back; however, implementation in the various Unix bsd's hasn't happened yet. See also the appendix to RFC-985 for further suggestions. Your comments and advice on the issues raised there would be welcome. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702091705.AA23665%40dartmouth.EDU] <1987020907052500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: richb.UUCP@seismo.css.gov@dartvax.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8702091705.AA23665@dartmouth.EDU> Date: Mon, 9-Feb-87 12:05:25 EST Article-I.D.: dartmout.8702091705.AA23665 Posted: Mon Feb 9 12:05:25 1987 Date-Received: Wed, 11-Feb-87 19:57:04 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 41 Approved: tcp-ip@sri-nic.arpa Path: dartvax!richb From: richb@dartvax.UUCP (Richard E. Brown) Newsgroups: mod.protocols.tcp-ip Subject: Re: network password protection/TCP spec Message-ID: <5665@dartvax.UUCP> Date: 9 Feb 87 17:05:24 GMT Reply-To: richb@dartvax.UUCP (Richard E. Brown) Organization: Dartmouth College, Hanover, NH Lines: 30 References: 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---- [8702100550.AA27790%40emory.eu] <1987020919502000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: km@EMORY.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Telnet Wish List Message-ID: <8702100550.AA27790@emory.eu> Date: Tue, 10-Feb-87 00:50:20 EST Article-I.D.: emory.8702100550.AA27790 Posted: Tue Feb 10 00:50:20 1987 Date-Received: Wed, 11-Feb-87 06:38:04 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Keywords: telnet niu tcp/ip rlogin Approved: tcp-ip@sri-nic.arpa Our Broadband vendor (Applitek) has agreed to add Telnet (and tcp/ip) to their terminal NIU product. The idea is that terminals connected to an NIU could initiate a telnet session which would then be bridged to ethernet via their bband/ethernet bridge product. I suppose the ip packets would be encapsulated in their proprietary Unilan packets, and stripped out at the bridge. On the surface it should give the appearance of one of the ethertip boxes (like Annex or Cisco). Anyway, we would like to give the vendor a wish list. I would appreciate any suggestions of features we should emphasize, and pitfalls we should avoid. One specific point for comment is the advisability of telnet instead of rlogin. Can a well implemented telnet work as well as rlogin? Is the rlogin protocol documented, or is the protocol just what the code does? I have seen some reference to adding facilities to the NIU to offload the host (hooks to editors, cooked mode done in the niu, etc..). Are any of these really big wins? The job of patching and maintaining the host software to support this (let alone convince the vendor to do the NIU side) seems to be only worth doing if the improvement is great. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021003070500> Received: from NOSC-TECR.ARPA by SRI-NIC.ARPA with TCP; Tue 10 Feb 87 11:26:39-PST Date: Tue 10 Feb 87 11:07:05-PST From: CONTR14@NOSC-TECR.ARPA To: tcp-ip@SRI-NIC.ARPA Subject: Please add to mailing list Please add this net address to the tcp-ip mailing list. ------------------------------------------------------------------- Thanks in advance, James Baldo Jr. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870210101628.9.DCP%40KOYAANISQATSI.S4CC.Symbolics.COM] <1987021005160000> 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: Telnet Wish List Message-ID: <870210101628.9.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Tue, 10-Feb-87 10:16:00 EST Article-I.D.: KOYAANIS.870210101628.9.DCP Posted: Tue Feb 10 10:16:00 1987 Date-Received: Wed, 11-Feb-87 07:46:39 EST References: <8702100550.AA27790@emory.eu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa Date: Tue, 10 Feb 87 00:50:20 EST From: Ken Mandelberg One specific point for comment is the advisability of telnet instead of rlogin. Can a well implemented telnet work as well as rlogin? Is the rlogin protocol documented, or is the protocol just what the code does? Yearly TELNET flame: TELNET is a piece of junk designed for ASR33s and later tried to get improved as terminals entered a more modern age. Use SUPDUP (RFC 734). If you also want to do graphics, see the SUPDUP graphics protocol (RFC 746). ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702101945.AA18279%40ucbvax.Berkeley.EDU] <1987021009070500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: CONTR14@NOSC-TECR.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Please add to mailing list Message-ID: <8702101945.AA18279@ucbvax.Berkeley.EDU> Date: Tue, 10-Feb-87 14:07:05 EST Article-I.D.: ucbvax.8702101945.AA18279 Posted: Tue Feb 10 14:07:05 1987 Date-Received: Wed, 11-Feb-87 19:45:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa Please add this net address to the tcp-ip mailing list. ------------------------------------------------------------------- Thanks in advance, James Baldo Jr. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021009120600> Received: from H.CS.CMU.EDU by SRI-NIC.ARPA with TCP; Wed 11 Feb 87 08:54:27-PST Date: Tuesday, 10 February 1987 14:12:06 EST From: Rudy.Nedved@h.cs.cmu.edu To: Ken Mandelberg cc: tcp-ip@sri-nic.arpa Subject: Re: Telnet Wish List Message-ID: <1987.2.10.18.56.23.Rudy.Nedved@h.cs.cmu.edu> In-Reply-To: <8702100550.AA27790@emory.eu> Telnet can work as well as rlogin except for the extra step of logging in which rlogin does for you. In a place where many hosts exists and security is an issue, rlogin mechanism will have to be revised creating yet-more incompatibilities. Whereas the concept of a remote terminal connection does not have any potential future problems other then supporting graphics which should be a new protocol to begin with. Alas, the problem with telnet is that many people did not understand what was going on. Various implementors misread or totally blew the implementation of a option(s) in telnet. This shows up very quickly when you have a variety of operating systems in your shop. 4.3BSD has fixed alot of problems but there are still a few left around. The best implementation (ignoring performance) seems to be TOPS-20. The areas of weakness are: 8-bit wide connections (binary option) EOL handling (CR maps to CR NUL or CR LF?) the ability to abort pending output buffered in 4 to 8k of buffers quickly (Abort Output telnet command and Data Marks). proper handling of option negotiations. user settable options (remote versus local echo/editting, allowing or not allowing binary). CMU does not use rlogin and has several different implementations of telnet and several different types of crazy terminals. Before many products were out, we created our own TELNET box or whatever you call something that enables many terminals to talk over the ethernet to a bunch of hosts. We have not seen many complaints....except by hardcore Unix hackers who must have vanillia Unix (whatever that is) and want rlogin and rsh. The exception is the IBM world....we are just starting to get involved with that stuff and have basically being using Wisconsin and Berkeley tn3270 program on Unix and ignoring the issue on the rest of our machines. -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702101934.AA04710%40gwen.cs.purdue.edu] <1987021009341900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: narten@PURDUE.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: UDP vs. ICMP dest unreachable messages Message-ID: <8702101934.AA04710@gwen.cs.purdue.edu> Date: Tue, 10-Feb-87 14:34:19 EST Article-I.D.: gwen.8702101934.AA04710 Posted: Tue Feb 10 14:34:19 1987 Date-Received: Thu, 12-Feb-87 02:01:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 70 Approved: tcp-ip@sri-nic.arpa This note is prompted by the observation that lots of nameservers still contact usc-isib (10.3.0.52), even though the machine no longer exists. A related problem that is appearing a lot more now has to do with reactions in general to ICMP dest unreachable messages. Now that name server traffic is picking up, it really hurts to see UDP implementations ignoring ICMP errors. It is not uncommon to see half a dozen (or more) packets sent to some remote nameserver even though the first packet causes an ICMP dest unreachable to be returned. In some cases this is not too serious (but still undesirable), since the message comes from a gateway one hop away with a LAN in between. Other times, the message comes from some distant gateway on the other side of the ARPANET. The problem with letting UDP see these errors lies with the stateless nature of datagram delivery at that level. With TCP, there has to be a connection block that the error packet can be matched up against. Hence, TCP can do something intelligent (but often doesn't). With UDP, the packet gets sent with no guarantees about delivery. Furthermore the user process might well be sending data to several destinations via the same "socket", and it is not clear how to return errors to the user. I see three basic approaches. 1) Do nothing, a favorite among current implementations. 2) Pass errors back to the user process. This is hard to do, since the kernel may well have no idea of what process sent the packet. In some cases, the kernel would have to keep a log of all UDP packets it sends in order to pass back errors to the user. 3) Cache errors in the routing tables for short periods of time. This can be done by adding a flag to route table entries that says "Not really reachable". That way, the user would not get an error on the first packet, but the retransmission of that packet could cause the route lookup to note that the destination is unreachable and the user could be informed. This would be a significant improvement because now the user process could elect to use a different address as the jprimary. Furthermore, the user process could elect not to use the "bad route" for a long time (say 30 minutes or several hours), long after the record of the unreachable message has been flushed from routing tables. This has the desired effect of: 1) Processes using UDP can get feedback about unreachable destinations. 2) It doesn't drastically change the semantics of the UDP interface. E.g. the user is not notified asyncronously or forced to ask explicitely whether a route works. On return from the sendpacket() routine, a flag could be returned. In addition, sending packets to an unreachable destination doesn't have to mean that the packet didn't get sent, it just means "I got an dest unreachable a while ago. It is not likely that the packet will get there". The user can choose to ignore this (though he/she really shouldn't). 3) The length of time dest unreachable messages are cached can (and probably needs to be) an adjustable parameter. It may well be that caching such a message for 10-30 seconds would be sufficient to cut down on the number of useless packets sent, yet would not keep users from reaching hosts that were down but just came back up. 4) Programs don't have to rely on timeouts to decide that a host or list of hosts is unreachable. This will often times give users a quicker response. Comments? Thomas ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021009550000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Tue 10 Feb 87 18:09:49-PST Date: 10 Feb 87 17:55:00 PST From: Subject: X.25 service binding To: "iso" cc: tcp-ip@sri-nic Reply-To: I'd like to solicit any input anyone might have... I'm going to be defining an X.25 service interface and am dealing with specifying binding information for incoming calls. Unfortunately X.25 does not have any clean, well defined mechanism for this. What I want is for a user to allocate a "Service Access Point" (SAP) and then specify information for a binding filter. When an incoming call matches the binding filter, an Indication of Incoming Call will be passed to the user for his acceptance or rejection. Issues: Protocol Identification - The first byte of call user data is typically used to identify a specific upper layer protocol. But call user data is optional and CCITT PAD protocols use a four byte protocol identifier and other protocols (such as DoD IP) use just one. What about information in the rest of the user data field? Destination Address - The format of the X.25 address which is received is essentially controlled by the network provider under X.121 guidelines. Some networks support "sub-address" bits which are not interpreted by the network, others do not. Some networks support more than one address format (typically for local vs internetwork calls). Source Address - Should the service interface filter on remote host identification? Facilities - Should the service interface be involved in which facilities are allowed? What about negotiated Facilities (such as packet size)? Anyone interested in this stuff??? Art Berggreen ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12278002735.31.ROODE%40BIONET-20] <1987021010432300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROODE@BIONET-20.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: root domain servers Message-ID: <12278002735.31.ROODE@BIONET-20> Date: Tue, 10-Feb-87 15:43:23 EST Article-I.D.: BIONET-2.12278002735.31.ROODE Posted: Tue Feb 10 15:43:23 1987 Date-Received: Thu, 12-Feb-87 04:07:27 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Are there enough of them? The recent problems with the former USC-ISIB would seem to indicate undesirable concentrations of heavy network overhead traffic may be occurring around the hosts which feature root domain servers. Couldn't this load easily be spread around? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702110223.AA26394%40ucbvax.Berkeley.EDU] <1987021015550000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: art@ACC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: X.25 service binding Message-ID: <8702110223.AA26394@ucbvax.Berkeley.EDU> Date: Tue, 10-Feb-87 20:55:00 EST Article-I.D.: ucbvax.8702110223.AA26394 Posted: Tue Feb 10 20:55:00 1987 Date-Received: Thu, 12-Feb-87 01:53:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 37 Approved: tcp-ip@sri-nic.arpa I'd like to solicit any input anyone might have... I'm going to be defining an X.25 service interface and am dealing with specifying binding information for incoming calls. Unfortunately X.25 does not have any clean, well defined mechanism for this. What I want is for a user to allocate a "Service Access Point" (SAP) and then specify information for a binding filter. When an incoming call matches the binding filter, an Indication of Incoming Call will be passed to the user for his acceptance or rejection. Issues: Protocol Identification - The first byte of call user data is typically used to identify a specific upper layer protocol. But call user data is optional and CCITT PAD protocols use a four byte protocol identifier and other protocols (such as DoD IP) use just one. What about information in the rest of the user data field? Destination Address - The format of the X.25 address which is received is essentially controlled by the network provider under X.121 guidelines. Some networks support "sub-address" bits which are not interpreted by the network, others do not. Some networks support more than one address format (typically for local vs internetwork calls). Source Address - Should the service interface filter on remote host identification? Facilities - Should the service interface be involved in which facilities are allowed? What about negotiated Facilities (such as packet size)? Anyone interested in this stuff??? Art Berggreen ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702140836.AA09256%40seismo.CSS.GOV] <1987021017051800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: steve@BRL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Submission for mod-protocols-tcp-ip Message-ID: <8702140836.AA09256@seismo.CSS.GOV> Date: Tue, 10-Feb-87 22:05:18 EST Article-I.D.: seismo.8702140836.AA09256 Posted: Tue Feb 10 22:05:18 1987 Date-Received: Sat, 14-Feb-87 23:55:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa Brian - If you run the TCP/IP protocols, you can connect your campus to the nationwide NSFNET and gain access to lots of other supercomputers besides your own, a transparent interconnection to the ARPANET (and CSNET too, for that matter), and all the other interesting things that go with Internet membership. It's even possible to apply for an NSF grant to connect up. If you're interested, drop me a note with your Snail Mail address and ask for the "Connections Program Announcement". -s ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702110804.AA27296%40topaz.rutgers.edu] <1987021022041300> 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: UDP vs. ICMP dest unreachable messages Message-ID: <8702110804.AA27296@topaz.rutgers.edu> Date: Wed, 11-Feb-87 03:04:13 EST Article-I.D.: topaz.8702110804.AA27296 Posted: Wed Feb 11 03:04:13 1987 Date-Received: Thu, 12-Feb-87 04:21:04 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa You suggest that the kernel should remember destination unreachable messages, and not bother to try again for some time. The problem with this is that there are often transient routing problems. If you try again, things might actually work. Until the core gets more reliable, I would rather retry. Indeed for a while we intentionally broke our TCP code so that it would keep trying when it got destination unreachable, instead of aborting the connection. This helped us keep connnections up to certain hosts. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021100021300> Received: from LOKI.BBN.COM by SRI-NIC.ARPA with TCP; Wed 11 Feb 87 05:26:15-PST To: tcp-ip@sri-nic.arpa Subject: Detecting Congestion Date: Wed, 11 Feb 87 08:22:13 -0500 From: Craig Partridge I seem to recall hearing or seeing a note that suggested that someone had shown that timers gave sufficient information to detect congestion. If anyone knows the reference(s) could you send it to me? Thanks, Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702111336.AA06124%40ucbvax.Berkeley.EDU] <1987021103543800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@LOKI.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Detecting Congestion Message-ID: <8702111336.AA06124@ucbvax.Berkeley.EDU> Date: Wed, 11-Feb-87 08:54:38 EST Article-I.D.: ucbvax.8702111336.AA06124 Posted: Wed Feb 11 08:54:38 1987 Date-Received: Thu, 12-Feb-87 06:37:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa I seem to recall hearing or seeing a note that suggested that someone had shown that timers gave sufficient information to detect congestion. If anyone knows the reference(s) could you send it to me? Thanks, Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702111436.AA06857%40ucbvax.Berkeley.EDU] <1987021104222000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@CCV.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: UDP vs. ICMP dest unreachable messages Message-ID: <8702111436.AA06857@ucbvax.Berkeley.EDU> Date: Wed, 11-Feb-87 09:22:20 EST Article-I.D.: ucbvax.8702111436.AA06857 Posted: Wed Feb 11 09:22:20 1987 Date-Received: Thu, 12-Feb-87 06:38:45 EST References: <8702110804.AA27296@topaz.rutgers.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa > (you can ignore an 'unreachable' because it may indicate a transient > routing problem) [paraphrased - mb] You really need to be advocating to look at the subcodes returned by ICMP destiination unreachable, because you can usually trust the 'host dead' type returned from some gateways when trying to talk to hosts on arpanets. Yes, you would do well to ignore ICMP net unreachable if you suspect routing flurries (often the case nowadays). With UDP domain lookups however, could you not use that as an indication to try another address, even if you keep retransmitting to the original one? You need not worry about "bothering" too many servers in this case, because the 'unreachable' is a response which tells you that you did not reach that server. Also, you should be explicit in your reasoning about the 'port unreachable' subcode. Do you mean to try again because the server too busy and did not get another server listen up again, or give up because there is not now nor will there ever be a server at that host (because the service host changed). I think you should use the broadcast approach for connection setup, since you supposedly don't care which of the equivalent servers you reach. If, for example, you try to contact one from the set { A, B, C }, and you get an unreachable from A, try B next, and only forget A if the reply code was 'host dead'. Of course, your implementation on the arpanet (AHIP) interface does recognize arpanet host-dead messages, doesn't it? mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021104222001> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Wed 11 Feb 87 06:26:37-PST To: Charles Hedrick cc: narten@purdue.edu, tcp-ip@sri-nic.ARPA, brescia@ccv.bbn.com Subject: Re: UDP vs. ICMP dest unreachable messages In-reply-to: Your message of Wed, 11 Feb 87 03:04:13 est. <8702110804.AA27296@topaz.rutgers.edu> Date: 11 Feb 87 09:22:20 EST (Wed) From: Mike Brescia > (you can ignore an 'unreachable' because it may indicate a transient > routing problem) [paraphrased - mb] You really need to be advocating to look at the subcodes returned by ICMP destiination unreachable, because you can usually trust the 'host dead' type returned from some gateways when trying to talk to hosts on arpanets. Yes, you would do well to ignore ICMP net unreachable if you suspect routing flurries (often the case nowadays). With UDP domain lookups however, could you not use that as an indication to try another address, even if you keep retransmitting to the original one? You need not worry about "bothering" too many servers in this case, because the 'unreachable' is a response which tells you that you did not reach that server. Also, you should be explicit in your reasoning about the 'port unreachable' subcode. Do you mean to try again because the server too busy and did not get another server listen up again, or give up because there is not now nor will there ever be a server at that host (because the service host changed). I think you should use the broadcast approach for connection setup, since you supposedly don't care which of the equivalent servers you reach. If, for example, you try to contact one from the set { A, B, C }, and you get an unreachable from A, try B next, and only forget A if the reply code was 'host dead'. Of course, your implementation on the arpanet (AHIP) interface does recognize arpanet host-dead messages, doesn't it? mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021104430000> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Wed 11 Feb 87 06:46:16-PST Date: 11 Feb 1987 09:43-EST Sender: CLYNN@G.BBN.COM Subject: Re: UDP vs. ICMP dest unreachable messages From: CLYNN@G.BBN.COM To: narten@PURDUE.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[G.BBN.COM]11-Feb-87 09:43:50.CLYNN> In-Reply-To: <8702101934.AA04710@gwen.cs.purdue.edu> Thomas, A couple questions about method 2: why is it so hard for the kernel to pass the packet back to the user process? It doesn't seem very likely that some application would send a UDP packet and not let the kernel know how to get the reply back to it -- your favorite kernel does have sockets doesn't it? The ICMP error messages contain the IP header plus 64 bits of the packet it is complaining about. That information is as reliable as anything that one finds in a UDP packet -- it is covered by a checksum. Use the information in the included packet to find the identity of the SOURCE and have the kernel do whatever it would normally do for a received UDP packet with the same DESTINATION, including the mechanism for passing it back to the application. We have been using such a mechanism on the TOPS20s for several years and not had any problems; there is an option associated with the "socket" which allows the application to specify if it wants to receive the ICMP messages or not. The ideas you present in 3 would be useful, especially for those applications which haven't (yet?) been written to deal with their errors. Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021105470500> Received: from ccq.bbn.com by SRI-NIC.ARPA with TCP; Wed 11 Feb 87 08:39:03-PST Date: Wed, 11 Feb 87 10:47:05 EST From: Ken Pogran Subject: Re: UDP vs. ICMP dest unreachable messages In-Reply-To: Your message of Wed, 11 Feb 87 03:04:13 est To: hedrick@topaz.rutgers.edu Cc: narten@purdue.edu, tcp-ip@sri-nic.arpa, pogran@ccq.bbn.com The issue here is one of local vs. global optimization. The approach of not trying for awhile to reach a destination previously noted to be unreachable tends to reduce traffic on the Internet; the approach of continuing to try because it "tends to keep your connection up" is good for an individual but lousy for the Internet because it adds traffic. The former is a global optimization, the latter a local optimization. The ARPANET, in particular, is really struggling to carry the traffic it's being offered. Until more capacity can be added to it (which IS in the works; the wheels of DCA may grind slowly, but they ARE grinding in a forward direction!) the Internet community as a whole would be better served by folks taking more of a global optimization approach. Namely, if you're having trouble getting through, it's probably because the world is congested, and repeated attempts will hurt, not help, the overall situation. Ken Pogran ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702111844.AA15465%40utah-gr.ARPA] <1987021108444100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: haas%utah-gr@UTAH-CS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: X.25 service binding Message-ID: <8702111844.AA15465@utah-gr.ARPA> Date: Wed, 11-Feb-87 13:44:41 EST Article-I.D.: utah-gr.8702111844.AA15465 Posted: Wed Feb 11 13:44:41 1987 Date-Received: Fri, 13-Feb-87 22:15:57 EST References: <8702110223.AA26394@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 53 Approved: tcp-ip@sri-nic.arpa In article <8702110223.AA26394@ucbvax.Berkeley.EDU>, art@ACC.ARPA writes: > > I'm going to be defining an X.25 service interface and am dealing > with specifying binding information for incoming calls. Unfortunately > X.25 does not have any clean, well defined mechanism for this. > ... > Protocol Identification - The first byte of call user data is typically > used to identify a specific upper layer protocol. But call user > data is optional and CCITT PAD protocols use a four byte protocol > ... Actually the situation is manageable. My X.25 implementation for the DEC-20 (RIP) checked that the Call User Data field was present and started appropriately before accepting the call. This seems to be a reasonable general strategy. You won't find many PADs supporting X.29 that don't say so in their Call User Data field. > Destination Address - The format of the X.25 address which is received > is essentially controlled by the network provider under X.121 guidelines. > Some networks support "sub-address" bits which are not interpreted by > the network, others do not. Some networks support more than one address > format (typically for local vs internetwork calls). > Yup. Some networks let the caller set the sub-address bits, and some service organizations (like STN for example) select a service based on these bits. > > Source Address - Should the service interface filter on remote host > identification? > You WILL find PADs that don't provide a source address, and there is nothing in general to stop somebody from spoofing source address, unless you happen to be hooked to a particular network that verifies this field. In particular our local PDN, ComWest, uses Dynapac PADs that leave out source address. > > Facilities - Should the service interface be involved in which facilities > are allowed? What about negotiated Facilities (such as packet size)? > Well, at some level you need to negotiate facilities based on what service is requested. Larger window sizes have advantages for interactive use, and larger packet sizes have advantages for file transfer. Plus, your accountant probably has an interest in who pays for the call, which is a facility! > > Anyone interested in this stuff??? > > Art Berggreen > Me for one! Walt Haas ...utah-cs!haas ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702112015.AA08974%40okeeffe.Berkeley.EDU] <1987021110151000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: UDP vs. ICMP dest unreachable messages Message-ID: <8702112015.AA08974@okeeffe.Berkeley.EDU> Date: Wed, 11-Feb-87 15:15:10 EST Article-I.D.: okeeffe.8702112015.AA08974 Posted: Wed Feb 11 15:15:10 1987 Date-Received: Thu, 12-Feb-87 19:28:57 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa ICMP unreachable messages are reported to users of UDP sockets in 4.3 if and only if the socket is "connected"; that is, that the remote address is bound as well as the local address. Otherwise, it is unreasonable to report errors even though the local address matches that in an ICMP error message. The error may well refer to a datagram other than the most recently sent, in which case it is likely to be confusing at best. This is used in the UNIX resolver code to detect the abscence of a local server; it depends on receiving the "port unreachable" error. On the other hand, the same binding causes late messages from one server to be discarded after "connecting" to the next of a series of choices. This isn't a problem in the standard installation, with only one server choice (the server on the same host). The UNIX nameserver does not take advantage of ICMP error returns, in part because it runs multi-threaded, processing other requests while awaiting a reply to a recursive query. However, recent additions to the BIND server will enable it to measure response time of multiple servers for a domain. It will then choose the fastest server, which will not include one that was recently unreachable if there are alternatives. Recent questions about the ordering of root servers in BIND configuration files are no longer interesting. Current servers use the configuration file to reach the root servers initially, which they then query about the root domain. That information is then used as long as it is valid. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702112124.AA00479%40rose.sun.com] <1987021111241800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: nowicki@SUN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Congestion Message-ID: <8702112124.AA00479@rose.sun.com> Date: Wed, 11-Feb-87 16:24:18 EST Article-I.D.: rose.8702112124.AA00479 Posted: Wed Feb 11 16:24:18 1987 Date-Received: Fri, 13-Feb-87 22:14:30 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 35 Approved: tcp-ip@sri-nic.arpa I am not sure which is the right group for this discussion, but the recent congestion problems have brought up two important points. First, the MX record support from Berkeley for sendmail does not do any caching. Perhaps they thought the local name server would cache, but not when the desired name server is down. For example, last week Decwrl.DEC.COM was essentially unreachable from the Arpanet. The DEC.COM name servers are either on the other side of Decwrl (128.45), or behind other unreliable gateways (net 36). Thus mail started to pile up, and we quickly had hundreds of messages sitting in the queue. Each run through the queue did hundreds of MX lookups which had to timeout. I extended our simple cache (which already remembered if hosts are up or down) to cache the result of the MX request (especially if the request timed out). This got the queue flowing again. Second, there seems to be a bug in the HDH code of the PSNs (aka IMPs). During periods of congestion, the HDLC layer blocks us from sending back the "Host Up" messages that are required in HDH. The PSN then declares us to be down, clears its buffers, then immediately hears the Host Up message and declares us to be back up. This happens every few minutes during the day. Not only does throwing the buffered data away increase congestion in the short term by causing more retransmissions, there are higher-level instabilities. If a host tries to send us a TCP segment or ACK during the time that the IMP thinks we are down, they get a "Host Dead" message and reset the TCP connection, which means the entire mail message has to be retransmitted. This just makes matters worse. I have tried to contact BBN about the second problem, since it is a bug in their software, but I keep getting the run-around. The NOC people just say "must be congestion". I KNOW it is congestion, but it still is a bug! Does anyone at BBN read these lists? -- Bill Nowicki Sun Microsystems ----MESSAGE-END---- ----MESSAGE-BEGIN---- [969432.870211.JBVB%40MX.LCS.MIT.EDU] <1987021116093600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JBVB%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Telnet parity, etc. Message-ID: <969432.870211.JBVB@MX.LCS.MIT.EDU> Date: Wed, 11-Feb-87 21:09:36 EST Article-I.D.: MX.969432.870211.JBVB Posted: Wed Feb 11 21:09:36 1987 Date-Received: Fri, 13-Feb-87 03:29:24 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa A couple of weeks ago, I posted a query about Telnet implementations that sent Ascii with bit 8 set (parity, or whatever). The question was brought on when I ran across code that religiously masked off the high bit before passing it to a PC's display. Sun's PC NFS Telnet client (VT100 emulator) is said to send parity. Unspecified Unix 'getty' programs make the Telnet server send parity, which goes away once you're logged in. TOPS-20 systems have a transparent mode, used by terminals where the 8th bit is significant, but you only get it when you request it. When connected to a TOPS-20 system, if you use 'SET HOST' to reach another host via DECNET, any parity that DECNET sends gets passed through the Telnet server to you. I am still interested in more details re: the Unix 'getty', as it seems to be the major offender among servers. Which Unices? jbvb@ai.ai.mit.edu Jammes B. VanBokkelen FTP Software Inc.. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702112239.a006577%40Huey.UDEL.EDU] <1987021117393500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@LOUIE.UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: UDP vs. ICMP dest unreachable messages Message-ID: <8702112239.a006577@Huey.UDEL.EDU> Date: Wed, 11-Feb-87 22:39:35 EST Article-I.D.: Huey.8702112239.a006577 Posted: Wed Feb 11 22:39:35 1987 Date-Received: Fri, 13-Feb-87 03:30:10 EST Sender: usenet@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Charlie, I know the TOPS-20s have been sorting ICMP messages to the right processes for years, since that's where I got the idea to do the same thing in the fuzzballs. Having said that, it's too bad the users at the top of the TOPS-20 protocol stack don't see the information itself - say in TELNET or FTP. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702121123.AA09025%40DCN9.ARPA] <1987021201231400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brady@DCN9.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: UDP vs. ICMP dest unreachable messages Message-ID: <8702121123.AA09025@DCN9.ARPA> Date: Thu, 12-Feb-87 06:23:14 EST Article-I.D.: DCN9.8702121123.AA09025 Posted: Thu Feb 12 06:23:14 1987 Date-Received: Sun, 15-Feb-87 00:00:15 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa I came in on this discussion a little late, so pardon me if I'm a little off topic... > The problem with this is that there are often transient routing > problems. If you try again, things might actually work. Until > the core gets more reliable, I would rather retry. Indeed for a > while we intentionally broke our TCP code so that it would keep > trying when it got destination unreachable, instead of aborting > the connection. This helped us keep connnections up to certain > hosts. If you adopt this practice, you negate the purpose of the message. So why is it sent in the first place? In the long run, ignoring control messages like these could undermine any sort of development on the internet, particularly in relation to gateway to gateway communications. It may seem that some benefit is gained in certain instances from ignoring unreachable messages. But if there is to be a "standard" protocol, such a change would have to be beneficial (or at least non-detrimental) to the majority of the cases. I believe that in most cases, the control messages are a necessary factor in the control of needless congestion across an already strained internet. -Sean ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702120751.aa29368%40VGR.BRL.ARPA] <1987021202514000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mike@BRL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: IP Record Route in core? Message-ID: <8702120751.aa29368@VGR.BRL.ARPA> Date: Thu, 12-Feb-87 07:51:40 EST Article-I.D.: VGR.8702120751.aa29368 Posted: Thu Feb 12 07:51:40 1987 Date-Received: Sat, 14-Feb-87 13:52:00 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa Phil Dykstra at BRL has just instrumented a version of my PING program for BSD UNIX to optionally issue the ICMP ECHO REQUEST packets with IP Record Route enabled. This has brought up several important issues: *) The core gateways do not record any route information, although they don't choke on the IP option. Is there any chance that they can be induced to store their address in the record route record, or is this another "wait for the Butterfly gateway" issue? In the BRL gateway, the IP Record Route code is about 20 lines of C... *) There is some ambiguity as to how to interpret the combination of ICMP ECHO REQUEST and IP Record Route together. The Mills Fuzzball software seems to regard the ICMP ECHO REPLY as a separate transaction, and resets the Record Route pointer to the beginning of the log area, while the BRL Gateway presently continues recording, so you see the full route, round trip. There is merit to both, is one considered "right"? *) 4.2 BSD UNIX, alas, can't handle the Record Route at all. *) 4.3 BSD UNIX answers, but strips off the Record Route when answering. (Actually, it strips all options except source routing). This is sub- optimal, and we will be working on a fix. *) Checksum fixes to the BRL Gateway IP Options code were needed too. If you want the code, (a) please wait a few weeks before asking, and (b) don't ask me, ask . Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702131115.AA23652%40ucbvax.Berkeley.EDU] <1987021204255100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@CCV.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: IP Record Route in core? Message-ID: <8702131115.AA23652@ucbvax.Berkeley.EDU> Date: Thu, 12-Feb-87 09:25:51 EST Article-I.D.: ucbvax.8702131115.AA23652 Posted: Thu Feb 12 09:25:51 1987 Date-Received: Sat, 14-Feb-87 15:40:56 EST References: <8702120751.aa29368@VGR.BRL.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 35 Approved: tcp-ip@sri-nic.arpa *) The core gateways do not record any route information, This was a conscious design decision, not to look at any packets which do not have the IP destination = 'the gateway'. Well, that's not the whole case, because the lsi11 gateways will do IP header checksum and other validity checks, but they will not examine the options unless fragmentation is needed. The tradeoff was between speed and functionality. At that time, probably 4 years ago, we went for speed. At this time, the answer is, "wait for the next generation". When faced with the same decision in the butterfly, I lost the argument, so that will (does?) do record route, but at the expense (for packets with record route option only) of extra processing at each hop, because no shortcuts are taken past the full IP network routing. Note that Source route does have a record route trailer. In the BRL gateway, the IP Record Route code is about 20 lines of C... I expect the 11 could do it with 40 lines of macn11 ... (but it would be wrong). *) There is some ambiguity as to how to interpret the combination of ICMP ECHO REQUEST and IP Record Route together. The Mills Fuzzball software seems to regard the ICMP ECHO REPLY as a separate transaction, and resets the Record Route pointer to the beginning of the log area, while the BRL Gateway presently continues recording, so you see the full route, round trip. There is merit to both, is one considered "right"? This could become an emotional issue of 'right vs. wrong' but I think that more information is provided by NOT resetting the pointer. By the way, should the echoing host also do a record route? Remember it's a host, not a gateway function. Mike B. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021204255101> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Thu 12 Feb 87 06:34:10-PST To: Mike Muuss cc: tcp-ip@sri-nic.ARPA, Support@brl.ARPA, brescia@ccv.bbn.com Subject: Re: IP Record Route in core? In-reply-to: Your message of Thu, 12 Feb 87 7:51:40 EST. <8702120751.aa29368@VGR.BRL.ARPA> Date: 12 Feb 87 09:25:51 EST (Thu) From: Mike Brescia *) The core gateways do not record any route information, This was a conscious design decision, not to look at any packets which do not have the IP destination = 'the gateway'. Well, that's not the whole case, because the lsi11 gateways will do IP header checksum and other validity checks, but they will not examine the options unless fragmentation is needed. The tradeoff was between speed and functionality. At that time, probably 4 years ago, we went for speed. At this time, the answer is, "wait for the next generation". When faced with the same decision in the butterfly, I lost the argument, so that will (does?) do record route, but at the expense (for packets with record route option only) of extra processing at each hop, because no shortcuts are taken past the full IP network routing. Note that Source route does have a record route trailer. In the BRL gateway, the IP Record Route code is about 20 lines of C... I expect the 11 could do it with 40 lines of macn11 ... (but it would be wrong). *) There is some ambiguity as to how to interpret the combination of ICMP ECHO REQUEST and IP Record Route together. The Mills Fuzzball software seems to regard the ICMP ECHO REPLY as a separate transaction, and resets the Record Route pointer to the beginning of the log area, while the BRL Gateway presently continues recording, so you see the full route, round trip. There is merit to both, is one considered "right"? This could become an emotional issue of 'right vs. wrong' but I think that more information is provided by NOT resetting the pointer. By the way, should the echoing host also do a record route? Remember it's a host, not a gateway function. Mike B. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021209330000> Mail-From: STJOHNS created at 12-Feb-87 17:34:51 Date: 12 Feb 1987 17:33-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Congestion From: STJOHNS@SRI-NIC.ARPA To: nowicki@SUN.COM Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]12-Feb-87 17:33:47.STJOHNS> In-Reply-To: <8702112124.AA00479@rose.sun.com> Ask and ye shall be answered. I am sending your last note to the OPs people with the STRONG recommendation it be entered as an "incident report" (i.e. bug report). Mike StJohns ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702130034.AA08085%40ucbvax.Berkeley.EDU] <1987021211333700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@CCV.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Congestion (HDH blocking) Message-ID: <8702130034.AA08085@ucbvax.Berkeley.EDU> Date: Thu, 12-Feb-87 16:33:37 EST Article-I.D.: ucbvax.8702130034.AA08085 Posted: Thu Feb 12 16:33:37 1987 Date-Received: Fri, 13-Feb-87 22:42:31 EST References: <8702112124.AA00479@rose.sun.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa > Second, there seems to be a bug in the HDH code of the PSNs > I have tried to contact BBN about the second problem, since it is a bug > in their software, but I keep getting the run-around. Bill, To answer the specific question, you should call the NOC and refer to SR-86-03583 (eighty-six dash zero-three-five-eight-three). This is a previous report of the same problem, and they should be tracked together. For some reason, what you said and what they heard were not sufficient to make the connection. In general, if the people you talk do not understanding what you are saying, you need to talk to someone who does. I don't think that sort of escalation path exists yet in the call-in procedures. It probably should. I would prefer to see problems like this solved before you have to get up in the widest possible forum and shout. This shout should lead to the fix for your problem, however, so keep in mind "If you don't get grease, squeek louder." - paraphrase from A. Wheel regards, Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021211333701> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Thu 12 Feb 87 16:25:57-PST To: Bill Nowicki cc: bind%arpa.berkeley.edu@bbn.com, tcp-ip@sri-nic.ARPA, brescia@ccv.bbn.com, control@ccv.bbn.com, clynn@ccv.bbn.com, cgarrison@ccv.bbn.com Subject: Re: Congestion (HDH blocking) In-reply-to: Your message of Wed, 11 Feb 87 13:24:18 PST. <8702112124.AA00479@rose.sun.com> Date: 12 Feb 87 16:33:37 EST (Thu) From: Mike Brescia > Second, there seems to be a bug in the HDH code of the PSNs > I have tried to contact BBN about the second problem, since it is a bug > in their software, but I keep getting the run-around. Bill, To answer the specific question, you should call the NOC and refer to SR-86-03583 (eighty-six dash zero-three-five-eight-three). This is a previous report of the same problem, and they should be tracked together. For some reason, what you said and what they heard were not sufficient to make the connection. In general, if the people you talk do not understanding what you are saying, you need to talk to someone who does. I don't think that sort of escalation path exists yet in the call-in procedures. It probably should. I would prefer to see problems like this solved before you have to get up in the widest possible forum and shout. This shout should lead to the fix for your problem, however, so keep in mind "If you don't get grease, squeek louder." - paraphrase from A. Wheel regards, Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12278644592.8.MRC%40PANDA] <1987021221291300> 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: TELNET implementations Message-ID: <12278644592.8.MRC@PANDA> Date: Fri, 13-Feb-87 02:29:13 EST Article-I.D.: PANDA.12278644592.8.MRC Posted: Fri Feb 13 02:29:13 1987 Date-Received: Sat, 14-Feb-87 13:39:02 EST Sender: uucp@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 43 Approved: tcp-ip@sri-nic.arpa I'd like to thank Rudy Nedved for the complement ("the best implementation [of TELNET] (ignoring performance) seems to be TOPS-20") since I wrote the TOPS-20 client TELNET. After having written three client TELNET implementations for different operating systems and a server TELNET, it sort of rubs off on you. I would not say that the TOPS-20 server TELNET is anything to rave about though. It is unnecessarily complicated and has several major bugs. To my knowledge, the only implementation of TOPS-20 server TELNET that *correctly* implements TELNET protocol is the one on SIMTEL20, STL-HOST1, and DREA-XX. The typical bugs are the ones Rudy noted: incorrect implementation of binary mode, EOL's, and FFh data characters. Some systems, such as Stanford and CMU, have some half-assed fixes to some of these bugs; but a comprehensive fix has been stymied to date. It is also pretty poor that few systems allow user program control of network binary mode. Certain programmers have gone as far as exploiting a bug with incorrect handling of FFh data characters to send TELNET protocol as data! TOPS-20 client TELNET performs well; I think Rudy's performance comment was aimed at the server. My advice to implementors is: . you must take NO for an answer in any option . you must never confirm a negotiation to a state you are already in . run your streams in separate processes . never block for a protocol negotiation . do buffered instead of byte I/O and allocate very large buffers . fix your operating system's handling of Urgent data so it reliably works, and make your TELNET implementation use it. My favorite way of handling options is to SET the option state when I send a protocol command and proceed as if the host confirmed. The host will either: . confirm it, in which case all is well . do nothing, in which case you're still operating . deny it, in which case you clear the option and respond It isn't all that bad to be mistakenly in remote echo to a system that refuses to do so for a few seconds. This isn't quite according to spec, but it is a LOT better than a bogus implementation of the protocol! Entirely too many bogus protocol implementations are out there. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021306210000> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Fri 13 Feb 87 08:28:06-PST Date: 13 Feb 1987 11:21-EST Sender: CLYNN@G.BBN.COM Subject: Re: IP Record Route in core? From: CLYNN@G.BBN.COM To: brescia@CCV.BBN.COM Cc: mike@BRL.ARPA, tcp-ip@SRI-NIC.ARPA Cc: Support@BRL.ARPA Message-ID: <[G.BBN.COM]13-Feb-87 11:21:02.CLYNN> In-Reply-To: The message of 12 Feb 87 09:25:51 EST (Thu) from Mike Brescia Re: > When faced with the same decision in the butterfly, I lost the > argument, so that will (does?) do record route, but at the expense ... I just tried the record route option through the Butterfly Gateways at BBN (via BBNNet & Corporate Enet & WidebandNet) and did not get anything recorded in the record route option either when there was no simultaneous source route option, or when there was a source route which specified the butterfly as one hop on the route (the butterfly did record itself in the source route in this case, however). It would thus appear that the answer to the "(does?)" is NO. Re: > *) There is some ambiguity as to how to interpret the combination > of ICMP ECHO REQUEST and IP Record Route together. ... I agree that NOT resetting the pointer provides more information, especially when the route taken TO a "host" may well be different than the route taken FROM there. Resetting the pointer flushes the TO route; if the reset choice is "official", then I would like to see a corresponding "official" specification of a way to get the route TO a "host". (Note that finding a "good" host to use was not easy -- the local Symbolics and Vaxen dropped the option completely while the Suns failed to return an echo-reply.) Re: > By the way, should the echoing host also do a record route? The IP spec says that the options have to be processed "When an IP module routes a datagram...". Part of sending a datagram is to route it to the next hop. Consequently the echoing host is required to insert the interface address it uses to send the datagram in any (strict/loose) source route or record route options that are present. [Since a gateway which receives a datagram also has to find the next hop and interface that should be used to send it, it is an "IP module routing a datagram". I would thus argue that there is no "tradeoff" allowed; the choice is either between an implementation which does not meet the IP protocol specification, or one which does. I guess that the lesson to be learned is that writing the specs is NOT an easy task, and that we will have to try harder in the future.] Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702131254.a006197%40Huey.UDEL.EDU] <1987021307542000> 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 Record Route in core? Message-ID: <8702131254.a006197@Huey.UDEL.EDU> Date: Fri, 13-Feb-87 12:54:20 EST Article-I.D.: Huey.8702131254.a006197 Posted: Fri Feb 13 12:54:20 1987 Date-Received: Tue, 17-Feb-87 23:09:23 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Mike, Yes, this is an old entry on my punch list: should an ICMP echo reply recompute the route (fuzzball), go back the way it came (TOPS-20), continue the route (?) or whatever. It may be time to reconsider these issues carefully, since the recent congestion problems may well be resolved using these tools. Onceuponatime I thought the cleverest way to do this was to copy the inbound ICMP request into the data portion of the requrst, then construct a new ICMP reply header, but only if the request had a data portion large enough for the purpose. Then, Jerry Saltzer at MIT beat me up, because he expected the data portions to be returned unmodified. And so it goes. Ahem, the fuzzies don't do the record route thing to spec anyway, since they record the inbound address, not the return address of the outbound packet. Finally, I thought the record route magic did in fact work for the LSIways. At least the source route spells do. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702132020.AA26223%40flash.bellcore.com] <1987021310201800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FLASH.BELLCORE.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: ICMP messages Message-ID: <8702132020.AA26223@flash.bellcore.com> Date: Fri, 13-Feb-87 15:20:18 EST Article-I.D.: flash.8702132020.AA26223 Posted: Fri Feb 13 15:20:18 1987 Date-Received: Sat, 14-Feb-87 15:43:49 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 30 Approved: tcp-ip@sri-nic.arpa Here are some thoughts based on those of Dave Clark in RFC-816, which I think is still well worth reading. When the network breaks, a real-time human user may or may not be involved (e.g., Telnet vs. a background mail transfer). In the former case, you should let the user know what's happening (i.e., show him ICMP messages) *but* you should leave it up to him as to what to do. If he wants to wait indefinitely until things get better, he should have that option. In the case of two computers talking, what's the hurry? One of the major virtues of a (properly programmed) computer is patience. If a SMTP session gets stuck, why not just let TCP keep trying "forever", provided that it backs off its retransmissions enough to prevent network congestion? Keep the ICMP messages around for debugging, but let TCP do its job instead of giving up and forcing the application to start all over again. Your mail daemon is going to be sending out connection requests every hour or so anyway (not to mention all those MX and IP address domain queries), so why not just keep sending data packets so you can pick up where things left off? Only when the remote host crashes and comes back up will you have to start over. The only drawback I can see with this is the memory used by the almost idle mailer, but hey, memory is free these days. So the solution, I think, is to use ICMP messages for debugging, but don't let them affect TCP's actions. One of my pet peeves about many TCP implementations is how impatient they are, both in retransmission timing and "give up" timing. The end result is a network prone to the kind of congestion collapse John Nagle talked about in his paper on networks with infinite buffering. Fix the timers and you'll avoid this. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702141520.AA15042%40ucbvax.Berkeley.EDU] <1987021313321900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: MQH@CORNELLC.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Telnet Option Negotiation to IBMish Hosts Message-ID: <8702141520.AA15042@ucbvax.Berkeley.EDU> Date: Fri, 13-Feb-87 18:32:19 EST Article-I.D.: ucbvax.8702141520.AA15042 Posted: Fri Feb 13 18:32:19 1987 Date-Received: Sun, 15-Feb-87 05:10:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 120 Approved: tcp-ip@sri-nic.arpa Hello (and forgive me, this is awful long), I'm trying to decide how to "correctly" implement TELNET option negotiation for programs which can emulate both ASCII and EBCDIC. I support Wiscnet (a VM implementation of TCP/IP) here at Cornell. I've been working with one of our programmers who's been working on Cornell versions of TN3270 which run on MACs and PCs. Our TN3270s can successfully negotiate into 3270 terminal emulation with Wiscnet, but we've discovered that they can't talk to KNET (yet another implementation of TCP/IP for VM). It turns out that Wiscnet can't talk to KNET either, and that Berkeley's latest release of TN3270 doesn't talk to KNET in 3270 mode. I've spent some time researching this whole mess, and my results are below (I'm of the opinion that everyone's at least a little busted). Basically, the big problem is how to decide that we're going to do the connection in EBCDIC. I don't think the current RFCs for telnet supply enough information on how to properly handle EBCDIC connections. Here is a basic summary of the various "philosophies" of option negotiation in the code I've dealt with. I'll warn you in advance that these are my impressions, and best guesses, and that I've been known to be wrong. If I am wrong, please let me know. Wiscnet After establishment of the connection, both user, and server must "discuss" the following options, IN THIS ORDER, to form a "transparent mode" (3270) connection. TERMINAL TYPE, END OF RECORD, TRANSMIT BINARY. If any of the options are settled out of order, or some of the responses are unacceptable, or data arrives before option negotiation completes, the connection will irrevocably be put into "line mode" (ASCII). KNET After establishment of the connection, KNET will send a one line blurb in ASCII announcing itself and the host. Then option negotiation begins. If KNET does a SEND TERMINAL TYPE, and the user code responds with a valid 3270-ish terminal, KNET sends DO BINARY, WILL BINARY, and begins sending EBCDIC data. If it doesn't get an acceptable terminal type, the server puts up a menu of ASCII terminals it's willing to do protocol conversion for. Cornell TN3270 (PC and MAC) Always responds to SEND TERMINAL TYPE with "IBM-3278-2". Hack 1: If the server sends DO EOR, we enter 3270 emulation mode. If not, we do H19 emulation. Hack 2: If the server sends DO BINARY, we enter 3270 emulation mode. If not, we do H19 emulation. Berkeley TN3270 (UN*X hosts) (I'm not at all positive about this one) Always responds to SEND TERMINAL TYPE with "IBM-3278-2". If we change an option, and we get to a state where we have sent IBM-3278-2, and we are sending and receiving in binary, we enter 3270 emulation. Now, after all that, we can look at why some won't talk to others. Wiscnet -> KNET When the KNET server sends its one line blurb, Wiscnet decides to do line mode emulation. Unfortunately, it will still respond with options appropriate to 3270 emulation. The result is that KNET server is in 3270 mode, and Wiscnet user code is in ASCII line mode. I'm not sure of how the reverse case turns out. Cornell TN3270 -> KNET KNET doesn't initiate EOR option processing with the user. Hack 1 of our TN3270 therefore never went into 3278 emulation. Hack 2 does better, but we've come upon a bug at the TCP level. We're looking into it. Berkeley TN3270 -> KNET An old release (March 22, 1985) works fine. A newer release, (January 11, 1986) end's up talking to KNET in ASCII, and is forced to use the KNET protocol conversion. I think it's KNET's fault. The new TN3270 does a DO SUPPRESS GO AHEAD before KNET gets a chance to send an option. I think this confuses KNET, because it never gets around to sending a SEND TERMINAL TYPE. Since it never gets a 3270-ish terminal type from the user, it does ASCII emulation. Fortunately, since TN3270 never sent it's terminal type, it also decides to do ASCII. Now that that's clear as mud.... It seems that most all the implementations seem to think that the BINARY option is the way to do EBCDIC. Is that cool? It seems to me that an "EBCDIC" option would be less confusing. I DON'T think that the ASCII/EBCDIC question should be settled based on terminal type 'cause most UN*X implementations won't behave properly. If the server doesn't know how to do the terminal type announced by the user code, it's supposed to ask the user if it'll do something else. In practice, I haven't seen a single implementation that does this. Berkeley 4.2 never asked, and Berkeley 4.3 asks only once. It doesn't notice, for example, that "IBM-3278-2" isn't in its termcap. So, I guess I'd like to see an EBCDIC option added to telnet. Once that's in place, it's a trivial matter to make one end or the other announce that it WILL EBCDIC. If both sides DO EBCDIC, then everything would be fine. The matter of 3270 emulation could be decided with TERMINAL TYPE negotiation. If EBCDIC is refused, then both ends would do the connection in ASCII. If an EBCDIC option is the way to go, I have two questions. First, would the server, or the user announce WILL EBCDIC? The TN3270 programs are a little wierd in that they can emulate more than one kind of terminal. Second, would EBCDIC imply anything about BINARY? My thanks in advance for any comments you have on the subject. I hope that we can come to a quick resolution to this problem so we can get all our IBM implementations talking to one another. Mike Hojnowski Long-winded Wiscnet Grunt Cornell Theory Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021313321901> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Fri 13 Feb 87 16:13:07-PST Received: from CORNELLC.BITNET by wiscvm.wisc.edu on 02/13/87 at 18:11:53 CST Received: by CORNELLC (Mailer X1.23b) id 5379; Fri, 13 Feb 87 18:34:19 EST Date: Fri, 13 Feb 87 18:32:19 EST From: Mike Hojnowski Subject: Telnet Option Negotiation to IBMish Hosts To: TCP-IP Newsgroup , Wiscnet Interested Party List , KNET Interested Party List Hello (and forgive me, this is awful long), I'm trying to decide how to "correctly" implement TELNET option negotiation for programs which can emulate both ASCII and EBCDIC. I support Wiscnet (a VM implementation of TCP/IP) here at Cornell. I've been working with one of our programmers who's been working on Cornell versions of TN3270 which run on MACs and PCs. Our TN3270s can successfully negotiate into 3270 terminal emulation with Wiscnet, but we've discovered that they can't talk to KNET (yet another implementation of TCP/IP for VM). It turns out that Wiscnet can't talk to KNET either, and that Berkeley's latest release of TN3270 doesn't talk to KNET in 3270 mode. I've spent some time researching this whole mess, and my results are below (I'm of the opinion that everyone's at least a little busted). Basically, the big problem is how to decide that we're going to do the connection in EBCDIC. I don't think the current RFCs for telnet supply enough information on how to properly handle EBCDIC connections. Here is a basic summary of the various "philosophies" of option negotiation in the code I've dealt with. I'll warn you in advance that these are my impressions, and best guesses, and that I've been known to be wrong. If I am wrong, please let me know. Wiscnet After establishment of the connection, both user, and server must "discuss" the following options, IN THIS ORDER, to form a "transparent mode" (3270) connection. TERMINAL TYPE, END OF RECORD, TRANSMIT BINARY. If any of the options are settled out of order, or some of the responses are unacceptable, or data arrives before option negotiation completes, the connection will irrevocably be put into "line mode" (ASCII). KNET After establishment of the connection, KNET will send a one line blurb in ASCII announcing itself and the host. Then option negotiation begins. If KNET does a SEND TERMINAL TYPE, and the user code responds with a valid 3270-ish terminal, KNET sends DO BINARY, WILL BINARY, and begins sending EBCDIC data. If it doesn't get an acceptable terminal type, the server puts up a menu of ASCII terminals it's willing to do protocol conversion for. Cornell TN3270 (PC and MAC) Always responds to SEND TERMINAL TYPE with "IBM-3278-2". Hack 1: If the server sends DO EOR, we enter 3270 emulation mode. If not, we do H19 emulation. Hack 2: If the server sends DO BINARY, we enter 3270 emulation mode. If not, we do H19 emulation. Berkeley TN3270 (UN*X hosts) (I'm not at all positive about this one) Always responds to SEND TERMINAL TYPE with "IBM-3278-2". If we change an option, and we get to a state where we have sent IBM-3278-2, and we are sending and receiving in binary, we enter 3270 emulation. Now, after all that, we can look at why some won't talk to others. Wiscnet -> KNET When the KNET server sends its one line blurb, Wiscnet decides to do line mode emulation. Unfortunately, it will still respond with options appropriate to 3270 emulation. The result is that KNET server is in 3270 mode, and Wiscnet user code is in ASCII line mode. I'm not sure of how the reverse case turns out. Cornell TN3270 -> KNET KNET doesn't initiate EOR option processing with the user. Hack 1 of our TN3270 therefore never went into 3278 emulation. Hack 2 does better, but we've come upon a bug at the TCP level. We're looking into it. Berkeley TN3270 -> KNET An old release (March 22, 1985) works fine. A newer release, (January 11, 1986) end's up talking to KNET in ASCII, and is forced to use the KNET protocol conversion. I think it's KNET's fault. The new TN3270 does a DO SUPPRESS GO AHEAD before KNET gets a chance to send an option. I think this confuses KNET, because it never gets around to sending a SEND TERMINAL TYPE. Since it never gets a 3270-ish terminal type from the user, it does ASCII emulation. Fortunately, since TN3270 never sent it's terminal type, it also decides to do ASCII. Now that that's clear as mud.... It seems that most all the implementations seem to think that the BINARY option is the way to do EBCDIC. Is that cool? It seems to me that an "EBCDIC" option would be less confusing. I DON'T think that the ASCII/EBCDIC question should be settled based on terminal type 'cause most UN*X implementations won't behave properly. If the server doesn't know how to do the terminal type announced by the user code, it's supposed to ask the user if it'll do something else. In practice, I haven't seen a single implementation that does this. Berkeley 4.2 never asked, and Berkeley 4.3 asks only once. It doesn't notice, for example, that "IBM-3278-2" isn't in its termcap. So, I guess I'd like to see an EBCDIC option added to telnet. Once that's in place, it's a trivial matter to make one end or the other announce that it WILL EBCDIC. If both sides DO EBCDIC, then everything would be fine. The matter of 3270 emulation could be decided with TERMINAL TYPE negotiation. If EBCDIC is refused, then both ends would do the connection in ASCII. If an EBCDIC option is the way to go, I have two questions. First, would the server, or the user announce WILL EBCDIC? The TN3270 programs are a little wierd in that they can emulate more than one kind of terminal. Second, would EBCDIC imply anything about BINARY? My thanks in advance for any comments you have on the subject. I hope that we can come to a quick resolution to this problem so we can get all our IBM implementations talking to one another. Mike Hojnowski Long-winded Wiscnet Grunt Cornell Theory Center ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702140255.AA14335%40hoptoad.uucp] <1987021316554700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: gnu@cgl.ucsf.edu@hoptoad.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Telnet 8th bit: a good use for that bit... Message-ID: <8702140255.AA14335@hoptoad.uucp> Date: Fri, 13-Feb-87 21:55:47 EST Article-I.D.: hoptoad.8702140255.AA14335 Posted: Fri Feb 13 21:55:47 1987 Date-Received: Sat, 14-Feb-87 14:15:17 EST References: <969432.870211.JBVB@MX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa JBVB%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU ("James B. VanBokkelen") writes: > A couple of weeks ago, I posted a query about Telnet implementations > that sent Ascii with bit 8 set (parity, or whatever). The question > was brought on when I ran across code that religiously masked off > the high bit before passing it to a PC's display. I think that it would be good to specify that 8-bit values passed on Telnet connections are in ISO Latin I (essentially, extend NETASCII to 8 bits using the ISO character set that contains all the graphics for all the Latin languages). If the number of programs that actually pass 8-bit data is small enough (James' list only showed about 5 programs) then this change can be feasible. Note that since SMTP uses telnet encoding, this would allow international characters in mail, entered in a local character set, translated to ISO Latin I while flying over the wire, then translated to the recipient's local character set. This would have implications for FTP, too, if it was adopted. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021402440000> Mail-From: STJOHNS created at 14-Feb-87 10:45:17 Date: 14 Feb 1987 10:44-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: Telnet Option Negotiation to IBMish Hosts From: STJOHNS@SRI-NIC.ARPA To: MQH%CORNELLC.BITNET@WISCVM.WISC.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]14-Feb-87 10:44:15.STJOHNS> In-Reply-To: The message of Fri, 13 Feb 87 18:32:19 EST from Mike Hojnowski Right off the bat, EBCDIC would imply BINARY. Correct me if I'm wrong, my brush with OBM EBCDIC was about 6 years ago, but EBCDIC is a 8-bit code, nd the very codes TELNET uses to do the negotiations are probably shadowed by EBCDIC characters. If you want to still have a TELNET character capability, you'll have to define what EBCDIC characters represent what TELNET special characters. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702150001.AA19882%40ucbvax.Berkeley.EDU] <1987021413395300> 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: Congestion Message-ID: <8702150001.AA19882@ucbvax.Berkeley.EDU> Date: Sat, 14-Feb-87 18:39:53 EST Article-I.D.: ucbvax.8702150001.AA19882 Posted: Sat Feb 14 18:39:53 1987 Date-Received: Sun, 15-Feb-87 08:09:01 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa Mike, Just so you (and the rest of list) know, the patch that fixes the HDH problem was installed on the ARPANET yesterday (Friday) afternoon. It had previously been installed on the MILNET (because two hosts had encountered this problem), and was awaiting DDN approval for the ARPANET installation. Regards, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021413395301> Received: from CC5.BBN.COM by SRI-NIC.ARPA with TCP; Sat 14 Feb 87 15:46:03-PST To: STJOHNS@sri-nic.ARPA cc: nowicki@sun.com, tcp-ip@sri-nic.ARPA, malis@cc5.bbn.com Subject: Re: Congestion In-reply-to: Your message of 12 Feb 1987 17:33-PST. Date: 14 Feb 87 18:39:53 EST (Sat) From: Andy Malis Mike, Just so you (and the rest of list) know, the patch that fixes the HDH problem was installed on the ARPANET yesterday (Friday) afternoon. It had previously been installed on the MILNET (because two hosts had encountered this problem), and was awaiting DDN approval for the ARPANET installation. Regards, Andy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702150617.AA00895%40sun.Sun.COM] <1987021420173600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: news@seismo.CSS.GOV@sun.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8702150617.AA00895@sun.Sun.COM> Date: Sun, 15-Feb-87 01:17:36 EST Article-I.D.: sun.8702150617.AA00895 Posted: Sun Feb 15 01:17:36 1987 Date-Received: Sun, 15-Feb-87 12:43:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa Path: sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: mod.protocols.tcp-ip Subject: Re: Telnet 8th bit: a good use for that bit... Message-ID: <13334@sun.uucp> Date: 15 Feb 87 06:17:35 GMT References: <969432.870211.JBVB@MX.LCS.MIT.EDU> <8702140255.AA14335@hoptoad.uucp> Sender: news@sun.uucp Reply-To: guy@sun.UUCP (Guy Harris) Organization: Sun Microsystems, Mountain View Lines: 11 >I think that it would be good to specify that 8-bit values passed >on Telnet connections are in ISO Latin I (essentially, extend NETASCII >to 8 bits using the ISO character set that contains all the graphics >for all the Latin languages). That would leave all the non-Latin languages, like Japanese, Chinese, Korean, etc., out in the cold. It would be a mistake to require that 8-bit values (i.e, GR characters, with the 8th bit set) passed over TELNET connections be in one particular character set. If need be, there could be TELNET options to indicate which character set is being sent over the wire. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702151925.AA02456%40emory.eu] <1987021509253000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: km@EMORY.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Ethernet Security Message-ID: <8702151925.AA02456@emory.eu> Date: Sun, 15-Feb-87 14:25:30 EST Article-I.D.: emory.8702151925.AA02456 Posted: Sun Feb 15 14:25:30 1987 Date-Received: Mon, 16-Feb-87 01:48:40 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa How difficult is it to do ethernet address impersonation without hardware (including eprom) modification in commonly available workstations? For example, we have: Sun 3's, Microvaxen, 3B2s, 3B1's, and IBM PCs with 3-COM cards. On which of these could the Super user (or any user on the PC), alter his ethernet address in software without taking the box apart? I realize this is one tiny aspect of security, but it is one our administration has seized upon. It turns out our departmental ethernets are linked with filtered bridges, which have a naive filtering criteria. If they have ever seen an ethernet packet with a given source address on an ethernet, they will from then on pass all packets with that destination address accross the bridge to that ethernet. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12279312440.8.MRC%40PANDA] <1987021510374800> 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: Submission for mod-protocols-tcp-ip Message-ID: <12279312440.8.MRC@PANDA> Date: Sun, 15-Feb-87 15:37:48 EST Article-I.D.: PANDA.12279312440.8.MRC Posted: Sun Feb 15 15:37:48 1987 Date-Received: Mon, 16-Feb-87 18:54:29 EST References: <8702150617.AA00895@sun.Sun.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 27 Approved: tcp-ip@sri-nic.arpa I don't know what is done with Chinese or Korean, but Japanese uses a 14-bit character set, using only the values 21h-7Eh (that's 041 to 176 for us octal fans); that is, those values in 7-bit ASCII that represent printing characters. An ESCAPE sequence shifts between ASCII and JIS (Japanese Industrial Standard). An alternate means supports katakana only, using either the eighth bit or ASCII shift codes (SO/SI, a.k.a. CTRL/N and CTRL/O). Some terminals support both systems; however, the katakana-only system is obsolete today. One must recognize that 8 bits are never enough! It is perfectly alright to assign an 8-bit system for your local use, but it is pure egotism to believe that your 8-bit system is somehow superior to anyone else's and therefore should be adopted as a standard. Really, the eighth bit is best left for parity or undefined for a local application. To represent international characters, you need a larger character set. If a vote were taken today, I would vote for JIS. I believe that as long as your terminal supports overstriking you can get all the silly ISO characters using JIS. In addition, you also get Greek and Russian. I'm not sure about Chinese, but JIS includes several thousand Chinese characters (kanji), most of which aren't generally used in Japanese. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702160300.AA02734%40cbosgd.MIS.OH.ATT.COM] <1987021517000600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mark@cbosgd.mis.oh.att.com.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Telnet 8th bit: a good use for that bit... Message-ID: <8702160300.AA02734@cbosgd.MIS.OH.ATT.COM> Date: Sun, 15-Feb-87 22:00:06 EST Article-I.D.: cbosgd.8702160300.AA02734 Posted: Sun Feb 15 22:00:06 1987 Date-Received: Mon, 16-Feb-87 07:04:07 EST References: <8702150617.AA00895@sun.Sun.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 34 Approved: tcp-ip@sri-nic.arpa >>I think that it would be good to specify that 8-bit values passed >>on Telnet connections are in ISO Latin I (essentially, extend NETASCII >>to 8 bits using the ISO character set that contains all the graphics >>for all the Latin languages). > >That would leave all the non-Latin languages, like Japanese, Chinese, >Korean, etc., out in the cold. It would be a mistake to require that >8-bit values (i.e, GR characters, with the 8th bit set) passed over >TELNET connections be in one particular character set. If need be, >there could be TELNET options to indicate which character set is >being sent over the wire. Good point. The Japanese standard (or at least one of them) is in some sense upward compatible with ASCII and European character sets. Two byte sequences with both high order bits set are Kanji, single bytes with the high bit set are European. Anything that might be a control character is always a control char, no matter what else surrounds it. I don't have the details, and I don't know if this extends to Korean. I know it won't handle Chinese, because there are more characters in the Chinese language. However, TELNET option negotiation is very good at this sort of thing, all we'd have to do is standardize the character sets (or provide an open ended option that can be grown as needed.) I suspect that if we just say that TELNET has to be 8 bit transparent (except for a couple of things like 377 and CR) then most of the rest of this won't matter - we could apply a default character set (which might be ASCII, or European) unless options are negotiated otherwise. Mark ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702160415.AA07101%40ucbvax.Berkeley.EDU] <1987021517420000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: BEAME@MCMASTER.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: re:Ethernet Security Message-ID: <8702160415.AA07101@ucbvax.Berkeley.EDU> Date: Sun, 15-Feb-87 22:42:00 EST Article-I.D.: ucbvax.8702160415.AA07101 Posted: Sun Feb 15 22:42:00 1987 Date-Received: Mon, 16-Feb-87 06:59:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 29 Approved: tcp-ip@sri-nic.arpa > How easy is it to impersinate another ethernet address on a ... On an IBM-PC with 3-Com card, all one has to do to impersonate an ethernet address is to output the desired address to an I/O port on the card and you have become that address. If you have Micro-Vaxen running VMS and NO other network activity is being used such as DECNET, then with privilege you can become any ethernet address. I wanted to say the following when the "security messages" were flying, but I just didn't get around to it. Well here goes : The only method of making ethernet "Semi-secure" is to encrypt the data packets. But the question of what method of encryption is appropriate and feasable seems to bog down the incorporation of encryption into protcols like TCP/IP. Why can't a range of encryption methods be used, from XOR's to DES, and make an IP option which indicates the "highest level" that an implementation supports. The option also could be used to indicate the desired security level and the level that is obtainable with the current connection. This way PC/IP's can implement low level encryption and still be compatible with more sophisticated implementions. Carl Beame BEAME@MCMASTER.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021517420001> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Sun 15 Feb 87 20:04:20-PST Received: from MCMASTER.BITNET by wiscvm.wisc.edu on 02/15/87 at 21:42:19 CST Date: Sun, 15 Feb 87 22:42 EST From: Subject: re:Ethernet Security To: tcp-ip@sri-nic.arpa X-Original-To: tcp-ip@sri-nic.arpa, BEAME > How easy is it to impersinate another ethernet address on a ... On an IBM-PC with 3-Com card, all one has to do to impersonate an ethernet address is to output the desired address to an I/O port on the card and you have become that address. If you have Micro-Vaxen running VMS and NO other network activity is being used such as DECNET, then with privilege you can become any ethernet address. I wanted to say the following when the "security messages" were flying, but I just didn't get around to it. Well here goes : The only method of making ethernet "Semi-secure" is to encrypt the data packets. But the question of what method of encryption is appropriate and feasable seems to bog down the incorporation of encryption into protcols like TCP/IP. Why can't a range of encryption methods be used, from XOR's to DES, and make an IP option which indicates the "highest level" that an implementation supports. The option also could be used to indicate the desired security level and the level that is obtainable with the current connection. This way PC/IP's can implement low level encryption and still be compatible with more sophisticated implementions. Carl Beame BEAME@MCMASTER.BITNET ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702160944.AA11475%40ucbvax.Berkeley.EDU] <1987021522424900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@BARILVM.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TELNET and national language support Message-ID: <8702160944.AA11475@ucbvax.Berkeley.EDU> Date: Mon, 16-Feb-87 03:42:49 EST Article-I.D.: ucbvax.8702160944.AA11475 Posted: Mon Feb 16 03:42:49 1987 Date-Received: Mon, 16-Feb-87 20:25:50 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa As long as everyone is talking about national language support: We in Israel have a number of problems with TELNET. IBM started out about 18 years ago and came out with a Hebrew code that mapped right on top of all lowercase characters in the EBCDIC character set. That was fairly short sighted on IBM's part and recently they came out with something known as newcode - which maps the 27 hebrew characters to x'41'-x'49', x'51'-x'59', x'62'-x'69', and x'71'. Two years ago they came out with something known as bulletin code which moves some things around again. To make matters worse - other computer manufacturers have their own standard - and even the IBM PC has a different standard in ASCII. On top of that we have the problem of typing right to left rather than left to right. Compounding the problem is mixed language documents (English - Hebrew) and even if you ignore that problem you still have the problem of entering numbers in a Hebrew document. There are various terminal implementations that try to resolve this problem but none have been tested in a TELNET type environment. One day we will have cross that bridge. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702161415.AA14800%40ucbvax.Berkeley.EDU] <1987021603440000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: NS-DDN@DDN2.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: SMTP Uses TELNET ? Message-ID: <8702161415.AA14800@ucbvax.Berkeley.EDU> Date: Mon, 16-Feb-87 08:44:00 EST Article-I.D.: ucbvax.8702161415.AA14800 Posted: Mon Feb 16 08:44:00 1987 Date-Received: Tue, 17-Feb-87 03:34:45 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa From RFC 821, Section 4.5.5. Transparency: The mail data may contain any of the 128 ASCII characters. All characters are to be delivered to the recipient's mailbox including format effectors and other control characters. If the transmission channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII codes are transmitted right justified in the octets with the high order bits cleared to zero. and again, in Appendix A, under Data Transfer: The TCP connection supports the transmission of 8-bit bytes. The SMTP data is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte with the high-order bit cleared to zero. Please, let's not clutter up the TCP-IP SIG with gross inaccuracies. The archive should be a repository of wheat, not chaff. Dave Craig Network Solutions, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021603440001> Received: from ddn2 by SRI-NIC.ARPA with TCP; Mon 16 Feb 87 06:01:04-PST Date: 16 Feb 87 08:44 EST From: NS-DDN @ DDN2 Subject: SMTP Uses TELNET ? To: tcp-ip @ SRI-NIC.ARPA From RFC 821, Section 4.5.5. Transparency: The mail data may contain any of the 128 ASCII characters. All characters are to be delivered to the recipient's mailbox including format effectors and other control characters. If the transmission channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII codes are transmitted right justified in the octets with the high order bits cleared to zero. and again, in Appendix A, under Data Transfer: The TCP connection supports the transmission of 8-bit bytes. The SMTP data is 7-bit ASCII characters. Each character is transmitted as an 8-bit byte with the high-order bit cleared to zero. Please, let's not clutter up the TCP-IP SIG with gross inaccuracies. The archive should be a repository of wheat, not chaff. Dave Craig Network Solutions, Inc. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021603571100> Received: from glacier.stanford.edu ([36.22.0.115]) by SRI-NIC.ARPA with TCP; Mon 16 Feb 87 12:17:14-PST Received: by glacier.stanford.edu; Mon, 16 Feb 87 11:57:11 PST Date: Mon, 16 Feb 87 11:57:11 PST From: John B. Nagle Subject: Retrying after Destination Unreachable To: TCP-IP@nic.sri.com If implementors want to regard ICMP Destination Unreachable as non-fatal in TCP, hoping that things will get better, they should at least crank up the retransmit timer and slam the congestion window when it happens, since if things are so bad that one is getting ICMP Destination Unreachable, one should at least back off. One could think of Destination Unreachable as a very strong Source Quench. John Nagle ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702161934.AA00970%40gorodish.wseng.sun.com.com] <1987021609342200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: guy@SUN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Telnet 8th bit: a good use for that bit... Message-ID: <8702161934.AA00970@gorodish.wseng.sun.com.com> Date: Mon, 16-Feb-87 14:34:22 EST Article-I.D.: gorodish.8702161934.AA00970 Posted: Mon Feb 16 14:34:22 1987 Date-Received: Tue, 17-Feb-87 06:26:34 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa > The Japanese standard (or at least one of them) is in some sense upward > compatible with ASCII and European character sets. Two byte sequences > with both high order bits set are Kanji, single bytes with the high > bit set are European. Anything that might be a control character is > always a control char, no matter what else surrounds it. One of them - the UJIS code, as proposed by AT&T - is definitely *not* compatible in this fashion; any byte with the 8th bit on, unless preceded by an SS2, is either the first or second byte of a two-byte Kanji (or Gaiji, but making *that* work would require TELNET options to send fonts!) character. Does the other one - Shift-JIS - avoid all of the code points used by ISO Latin 1? The UJIS code is specified by the Sigma Project, and is being adopted by a number of UNIX systems, at least, in Japan. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702162029.AA19369%40ucbvax.Berkeley.EDU] <1987021609571100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jbn@GLACIER.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Retrying after Destination Unreachable Message-ID: <8702162029.AA19369@ucbvax.Berkeley.EDU> Date: Mon, 16-Feb-87 14:57:11 EST Article-I.D.: ucbvax.8702162029.AA19369 Posted: Mon Feb 16 14:57:11 1987 Date-Received: Tue, 17-Feb-87 06:26:02 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa If implementors want to regard ICMP Destination Unreachable as non-fatal in TCP, hoping that things will get better, they should at least crank up the retransmit timer and slam the congestion window when it happens, since if things are so bad that one is getting ICMP Destination Unreachable, one should at least back off. One could think of Destination Unreachable as a very strong Source Quench. John Nagle ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021609580000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 16 Feb 87 18:39:42-PST Received: from YMIR.BITNET by wiscvm.wisc.edu on 02/16/87 at 20:34:36 CST Received: from ENGVAX.UUCP by YMIR.BITNET; Mon, 16 Feb 87 18:02 PST Date: Mon, 16 Feb 87 17:58 PST From: Kevin Carosso Subject: Problem with TCP state transitions in CLOSE To: tcp-ip@sri-nic.ARPA X-VMS-To: IN%"tcp-ip@sri-nic.arpa" I'm having a problem with an implementation detail of a TCP/IP and I hope I can get some insights from those who've gone before. The situation is as follows: According to RFC 793, a CLOSE operation means "I have no more data to send." "The user who CLOSEs may continue to RECEIVE until he is told that the other side has CLOSED also." Now, my client application does a CLOSE, the TCP sends a FIN and goes from ESTABLISHED to FIN-WAIT-1. When the FIN is ACKed, it goes from FIN-WAIT-1 to FIN-WAIT-2. While in FIN-WAIT-1 or FIN-WAIT-2, data continues to be received from the network and the application may continue to issue RECEIVEs to get the data. Finally, the other end of the connection does a CLOSE and the TCP receives a FIN. Receiving a FIN in FIN-WAIT-2 means transition to TIME-WAIT. The TCP receives a data segment while in FIN-WAIT-2, just before receiving the FIN. Now, it's entirely likely that the application won't get around to doing it's next RECEIVE (for what will be the last buffer of data sent over from it's buddy on the other end) until the TCP has gotten the FIN. (Not only is this likely, it happens most of the time, depending on system response time, to an application here.) The question is, what is a TCP to do if it is in FIN-WAIT-2, it has some user data that the user hasn't asked for yet, and a FIN comes in? If it goes immediately to TIME-WAIT (as this TCP does) the user will receive an error because RFC 793 says that a RECEIVE call while in TIME-WAIT returns "error: connection closing." Seems to me that what we would like to be in here is a state similar to CLOSE-WAIT, in that RECEIVEs are allowed, but "must be satisfied by text already on hand, but not yet delivered to the user." There are two possible work-arounds that I came up with, though I am not particularly happy with them and will wait for some cogent feedback before implementing. 1) Go to TIME-WAIT as the spec says, but handle a user RECEIVE call as described in CLOSE-WAIT. 2) If there is user data outstanding when you get a FIN in FIN-WAIT-2, delay the transition to TIME-WAIT until the user data has been delivered to the user (i.e. he came and asked for it all). My problems with 1) are that you aren't really following what the spec says and that I'm not sure what to do if that user data is still there after the 2 MSL timeout has passed. I don't think it's right for the data to go away after 2 MSL, since then the success of the application is dependent on how fast it can RECEIVE, and I don't think the TCP is supposed to introduce restrictions like that. (Please tell me if I'm off base here!) Maybe 2) is better? Seems to me, though, that the state transition isn't really handled as the spec says. Also, are you getting out of synch by staying in FIN-WAIT-2 when everyone expects you to have moved onto TIME-WAIT? If so, does anyone care? Why did RFC 793 specifically describe what to do with user data in CLOSE-WAIT but not in this case? How have others handled this in their implementations? I tried to look through the Berkeley 4.3 code, but found it a little murky. I decided they didn't do (2) but am not sure exactly what voodoo they do do. Thanks for any info, /Kevin Carosso kvc%engvax.uucp@usc-oberon.usc.edu Hughes Aircraft Co. ps. If anyone cares, it's the CMU rewrite of the Tektronix IP/TCP code for VAX/VMS. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021614124900> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 16 Feb 87 01:32:18-PST Received: from BARILVM.BITNET by wiscvm.wisc.edu on 02/16/87 at 02:51:13 CST Received: by BARILVM (Mailer X1.23b) id 1909; Mon, 16 Feb 87 10:52:09 O Date: Mon, 16 Feb 1987 10:42:49 O From: Henry Nussbacher Subject: TELNET and national language support To: tcp-ip@sri-nic.ARPA As long as everyone is talking about national language support: We in Israel have a number of problems with TELNET. IBM started out about 18 years ago and came out with a Hebrew code that mapped right on top of all lowercase characters in the EBCDIC character set. That was fairly short sighted on IBM's part and recently they came out with something known as newcode - which maps the 27 hebrew characters to x'41'-x'49', x'51'-x'59', x'62'-x'69', and x'71'. Two years ago they came out with something known as bulletin code which moves some things around again. To make matters worse - other computer manufacturers have their own standard - and even the IBM PC has a different standard in ASCII. On top of that we have the problem of typing right to left rather than left to right. Compounding the problem is mixed language documents (English - Hebrew) and even if you ignore that problem you still have the problem of entering numbers in a Hebrew document. There are various terminal implementations that try to resolve this problem but none have been tested in a TELNET type environment. One day we will have cross that bridge. Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702170259.AA25812%40ucbvax.Berkeley.EDU] <1987021615580000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: KVC@ENGVAX.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Problem with TCP state transitions in CLOSE Message-ID: <8702170259.AA25812@ucbvax.Berkeley.EDU> Date: Mon, 16-Feb-87 20:58:00 EST Article-I.D.: ucbvax.8702170259.AA25812 Posted: Mon Feb 16 20:58:00 1987 Date-Received: Tue, 17-Feb-87 18:39:45 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 68 Approved: tcp-ip@sri-nic.arpa I'm having a problem with an implementation detail of a TCP/IP and I hope I can get some insights from those who've gone before. The situation is as follows: According to RFC 793, a CLOSE operation means "I have no more data to send." "The user who CLOSEs may continue to RECEIVE until he is told that the other side has CLOSED also." Now, my client application does a CLOSE, the TCP sends a FIN and goes from ESTABLISHED to FIN-WAIT-1. When the FIN is ACKed, it goes from FIN-WAIT-1 to FIN-WAIT-2. While in FIN-WAIT-1 or FIN-WAIT-2, data continues to be received from the network and the application may continue to issue RECEIVEs to get the data. Finally, the other end of the connection does a CLOSE and the TCP receives a FIN. Receiving a FIN in FIN-WAIT-2 means transition to TIME-WAIT. The TCP receives a data segment while in FIN-WAIT-2, just before receiving the FIN. Now, it's entirely likely that the application won't get around to doing it's next RECEIVE (for what will be the last buffer of data sent over from it's buddy on the other end) until the TCP has gotten the FIN. (Not only is this likely, it happens most of the time, depending on system response time, to an application here.) The question is, what is a TCP to do if it is in FIN-WAIT-2, it has some user data that the user hasn't asked for yet, and a FIN comes in? If it goes immediately to TIME-WAIT (as this TCP does) the user will receive an error because RFC 793 says that a RECEIVE call while in TIME-WAIT returns "error: connection closing." Seems to me that what we would like to be in here is a state similar to CLOSE-WAIT, in that RECEIVEs are allowed, but "must be satisfied by text already on hand, but not yet delivered to the user." There are two possible work-arounds that I came up with, though I am not particularly happy with them and will wait for some cogent feedback before implementing. 1) Go to TIME-WAIT as the spec says, but handle a user RECEIVE call as described in CLOSE-WAIT. 2) If there is user data outstanding when you get a FIN in FIN-WAIT-2, delay the transition to TIME-WAIT until the user data has been delivered to the user (i.e. he came and asked for it all). My problems with 1) are that you aren't really following what the spec says and that I'm not sure what to do if that user data is still there after the 2 MSL timeout has passed. I don't think it's right for the data to go away after 2 MSL, since then the success of the application is dependent on how fast it can RECEIVE, and I don't think the TCP is supposed to introduce restrictions like that. (Please tell me if I'm off base here!) Maybe 2) is better? Seems to me, though, that the state transition isn't really handled as the spec says. Also, are you getting out of synch by staying in FIN-WAIT-2 when everyone expects you to have moved onto TIME-WAIT? If so, does anyone care? Why did RFC 793 specifically describe what to do with user data in CLOSE-WAIT but not in this case? How have others handled this in their implementations? I tried to look through the Berkeley 4.3 code, but found it a little murky. I decided they didn't do (2) but am not sure exactly what voodoo they do do. Thanks for any info, /Kevin Carosso kvc%engvax.uucp@usc-oberon.usc.edu Hughes Aircraft Co. ps. If anyone cares, it's the CMU rewrite of the Tektronix IP/TCP code for VAX/VMS. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021616250000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Mon 16 Feb 87 18:25:32-PST Received: from WILLIAMS.BITNET by wiscvm.wisc.edu on 02/16/87 at 20:24:39 CST Date: 16 FEB 87 21:25-EST From: WITLICKI%WILLIAMS.BITNET@wiscvm.wisc.edu To: TCP-IP @ SRI-NIC.ARPA Subject: Ethernet Security >From: Ken Mandelberg >Subject: Ethernet Security > > How difficult is it to do ethernet address impersonation without > hardware (including eprom) modification in commonly available >workstations? For example, we have: Sun 3's, Microvaxen, 3B2s, >3B1's, and IBM PCs with 3-COM cards. On which of these could... > >I realize this is one tiny aspect of security, but it is one our >administration has seized upon. It turns out our departmental >ethernets are linked with filtered bridges, which have a naive... Hardware ethernet addresses and university administrative worries are almost two separate issues. Perhaps M. Padlipsky can fill us in on the finer points of layering manners here.. The hardware (rom) says Boot Me Now, please... If I don't need to be booted off of your file server I may not need a special hardware address. Up a few layers you have Mail From: things flying around... The filtering bridges are almost irrelevant. I can break into the wiring closet where the college president's phone line is, I may tap into the comm. link for your IBM mainframe which probably doesn't have link level encryption... but that takes involved intent and effort; I think you are asking - what about the hacker in a lab with a PC with an ethernet card? Keep the academic (students) stuff *physically* separate from your sensitive data (i.e. administrative systems) - randy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702170229.AA25371%40ucbvax.Berkeley.EDU] <1987021616320400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: WITLICKI@WILLIAMS.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Ethernet Security Message-ID: <8702170229.AA25371@ucbvax.Berkeley.EDU> Date: Mon, 16-Feb-87 21:32:04 EST Article-I.D.: ucbvax.8702170229.AA25371 Posted: Mon Feb 16 21:32:04 1987 Date-Received: Tue, 17-Feb-87 18:39:20 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 30 Approved: tcp-ip@sri-nic.arpa >From: Ken Mandelberg >Subject: Ethernet Security > > How difficult is it to do ethernet address impersonation without > hardware (including eprom) modification in commonly available >workstations? For example, we have: Sun 3's, Microvaxen, 3B2s, >3B1's, and IBM PCs with 3-COM cards. On which of these could... > >I realize this is one tiny aspect of security, but it is one our >administration has seized upon. It turns out our departmental >ethernets are linked with filtered bridges, which have a naive... Hardware ethernet addresses and university administrative worries are almost two separate issues. Perhaps M. Padlipsky can fill us in on the finer points of layering manners here.. The hardware (rom) says Boot Me Now, please... If I don't need to be booted off of your file server I may not need a special hardware address. Up a few layers you have Mail From: things flying around... The filtering bridges are almost irrelevant. I can break into the wiring closet where the college president's phone line is, I may tap into the comm. link for your IBM mainframe which probably doesn't have link level encryption... but that takes involved intent and effort; I think you are asking - what about the hacker in a lab with a PC with an ethernet card? Keep the academic (students) stuff *physically* separate from your sensitive data (i.e. administrative systems) - randy ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702170807.AA26038%40cernvax.UUCP] <1987021622075300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kik@CERNVAX.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8702170807.AA26038@cernvax.UUCP> Date: Tue, 17-Feb-87 03:07:53 EST Article-I.D.: cernvax.8702170807.AA26038 Posted: Tue Feb 17 03:07:53 1987 Date-Received: Tue, 17-Feb-87 23:17:42 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 44 Approved: tcp-ip@sri-nic.arpa Path: cernvax!kik From: kik@cernvax.UUCP (kik) Newsgroups: mod.protocols.tcp-ip,comp.dcom.lans Subject: IEEE/Blue Book problem and MAC-level bridges Message-ID: <439@cernvax.UUCP> Date: 17 Feb 87 08:07:52 GMT References: <12277078297.16.ROMKEY@XX.LCS.MIT.EDU> Reply-To: kik@cernvax.UUCP () Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Sw Lines: 33 The discussion on MAC-level bridging seems to have concentrated so far on the difference between the Ethernet 2.0 and IEEE 802.3 formats (i.e. Type/length field). What seems considerably more worrying is the problem raised by the IBM insistence for the acceptance by the standardisation bodies of their "source-level routing" for Token Ring (TR). For those of you in the happy state of ignorance about this approach, it works as follows: for an unknown MAC-level address, an enquiry frame is broadcast through all TR-bridges, which add their own address to the recorded route. The bridge on the ring that carries the desired address returns the enquiry (with the recorded route) to the enquirer. All subsequent frames to this address then carry this routing (ISO level 3!!) information directly after the destination and source address fields (i.e. before the LLC). In addition, to indicate that source routing is in action, the source address has the "casting" bit (least significant of most significant byte) set. One can imagine the excitement that this sort of frame will cause if it appears via a (normal) bridge on an Ethernet segment. Even if the IBM pollution is purged by an intelligent bridge, the reverse path for the response is somewhat problematical, and would entail maintaining a "TR routing table" in the bridge. It is clear that the IBM approach is (to say the least) not optimised for a connectionless environment. What is not clear, however, is whether it has *any* advantages over a true MAC-level bridge. I would be grateful for clarification from people who understand both approaches more cpmpletely than I. Crispin (KIK) Piney CERN, Geneva, Switzerland ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021706400000> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Tue 17 Feb 87 08:41:32-PST Date: 17 Feb 1987 11:40-EST Sender: CLYNN@G.BBN.COM Subject: Re: Problem with TCP state transitions in CLOSE From: CLYNN@G.BBN.COM To: kvc%engvax.uucp@USC-OBERON.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[G.BBN.COM]17-Feb-87 11:40:06.CLYNN> In-Reply-To: The message of Mon, 16 Feb 87 17:58 PST from Kevin Carosso Kevin, > The question is, what is a TCP to do if it is in FIN-WAIT-2, it has > some user data that the user hasn't asked for yet, and a FIN comes in? Remember that SYN and FIN are controls which occupy sequence space. Arriving segments are "generally queued and processed in sequence number order" (section 3.9). Later in the section: "segment arrives", "Otherwise", "seventh, process the segment text", requires that the data be processed (given to the user) before one is allowed to get to "eighth, check the fin bit". Your solution 2 > 2) If there is user data outstanding when you get a FIN in FIN-WAIT-2, > delay the transition to TIME-WAIT until the user data has been > delivered to the user (i.e. he came and asked for it all). has the proper effect, but the sequence number restrictions mean you technically cannot "get a FIN" "until the user data has been delivered to the user." Charlie ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702171755.AA00052%40apolling.imagen.uucp] <1987021707553300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@decwrl.DEC.COM@apolling.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Problem with TCP state transitions in CLOSE Message-ID: <8702171755.AA00052@apolling.imagen.uucp> Date: Tue, 17-Feb-87 12:55:33 EST Article-I.D.: apolling.8702171755.AA00052 Posted: Tue Feb 17 12:55:33 1987 Date-Received: Wed, 18-Feb-87 20:26:09 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.DEC.COM Organization: The ARPA Internet Lines: 37 Approved: tcp-ip@sri-nic.arpa > The TCP receives a data segment while in FIN-WAIT-2, just before receiving > the FIN. Now, it's entirely likely that the application won't get around to > doing it's next RECEIVE (for what will be the last buffer of data sent over > from it's buddy on the other end) until the TCP has gotten the FIN. The SYN & FIN bits are bytes of control that are IN the data stream. They consume sequence numbers, and only have meaning when taken in sequence. The presence of a FIN at the TCP level may cause a state to be changed or a flag to be set, but the connection can not actually close until the application has tried to RECEIVE the FIN. Thus, there are two aspects of TCP state, the state at the TCP level, and the state as transmitted by TCP to its client level. The TCP connection transitions to TIME-WAIT when it receives a FIN that is ready to be delivered to the client (note that last caveat, if the last data packet was lost, the state transition must wait until all the unRECEIVED data before the FIN is present). But the TCP connection does not tell its client that the connection is closed until the client tries to RECEIVE the FIN. In practise, this means that you must maintain the connection state even after it has closed, to allow the client to receive every last byte of data. ===aside======== While I have your ear, let me sound off about a pet peeve that you can preemptively fix in your implementation. The TCP layer should be willing to remain in zero window state arbitrarily long, as long as control packets are still crossing the connection. Don't time out a connection just because the window is zero for a while. Last I checked, Apollo (SR 9.2.3), Tops-20, Unix 4.2 all exhibit this bug. ===edisa======== - Geof Cooper IMAGEN ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702171830.AA20782%40ohio-state.ARPA] <1987021708290400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DIXON-R%OSU-20@OHIO-STATE.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Proteon vs Arpanet query Message-ID: <8702171830.AA20782@ohio-state.ARPA> Date: Tue, 17-Feb-87 13:29:04 EST Article-I.D.: ohio-sta.8702171830.AA20782 Posted: Tue Feb 17 13:29:04 1987 Date-Received: Wed, 18-Feb-87 22:20:56 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 14 Approved: tcp-ip@sri-nic.arpa We purchased a Proteon P4200 gateway with an Arpanet card to serve as our campus gateway to Arpanet. We were told that the gateway card supports 1822 DH, so we specified that to the Arpanet people and have been awaiting arrival of the Arpanet connection. Now the Arpanet people tell us we must change to 1822 HDH, and to work that out with our vendor. Proteon says they do not support 1822 HDH. Now what do we do? Throw out the Proteon box? Forget Arpanet? Is this a catch-22 situation? Bob Dixon Ohio State University ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702180024.AA08089%40opal.Berkeley.Edu] <1987021714190600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: minshall%opal.Berkeley.EDU@UCBVAX.BERKELEY.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Telnet Option Negotiation to IBMish Hosts Message-ID: <8702180024.AA08089@opal.Berkeley.Edu> Date: Tue, 17-Feb-87 19:19:06 EST Article-I.D.: opal.8702180024.AA08089 Posted: Tue Feb 17 19:19:06 1987 Date-Received: Wed, 18-Feb-87 20:24:29 EST References: <8702141520.AA15042@ucbvax.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 65 Approved: tcp-ip@sri-nic.arpa Hi all. The question of how one gets into "3270 mode" is a one worth pondering. A follow up message by Bruce Crabill (which may not have made it to the tcp-ip list) and the original message by Mike Hojnowski are fairly worthwhile reading, but I would like to add my two-cents worth. First, there is, of course, absolutely NO standard for how "3270 over telnet" should be done. The Wisconsin picked something, based possibly on conversations with the UCLA (MVS) people. Doing this involved inventing a new Telnet option (EOR's). The initial WISCNET just negtotiated a 3270 terminal type and binary mode, and then assumed EOR. After the implementation, the EOR (end of record) RFC came out and said "thou shalt negotiate EOR prior to using it", so later versions of WISCNET have negotiated EOR in addition to the terminal type and binary mode. Berkeley TN3270 does, in fact, always respond "ibm3278-X" to "send terminal type". This is somewhat of a problem, since if we AREN'T going to get into 3270 mode, we would probably REALLY like to say "vt100", or whatever the user's terminal REALLY is. I would LIKE to see this change, but it's not really too big of a deal. Berkeley TN3270 does, in fact, check occasionally to see if "binary" and "terminal type of 3270 sent" are true. If they are, then Berkeley TN3270 magically slips into 3270 mode. If these are NOT true, then Berkeley TN3270 magically slips out of 3270 mode (which transition may not work very well - I've never had a host that wanted to leave 3270 mode on me, though I understand that the UCLA code does like to do this at times). We DON'T check EOR option being set (though the current Berkeley TN3270 is willing to have EOR set on either end). Berkeley TN3270 IS sensitive to the fact that various IBM implementations are order sensitive when doing the initial negotiations. The most recently announced version of Berkeley TN3270 had a "bug" which caused it to not work when talking with Fibronics/Spartacus/KNET. The current version (available on arpa.berkeley.edu, or from me, but never announced) has a kludge to get around the KNET operating characteristics. The problem with order sensitivity is that on start up, a client would really like to just send "do sga" and "will terminal type". Doing this sort of "parallel" option negotiating can speed up the user-perceived connect time a lot. I would like an agreement on how to do things. Perhaps an RFC. I don't think the issues are actually that easy to resolve (though maybe I'm just slow). Part of the constraints should be that if 3270 negotiation doesn't work, we should slip back into "send terminal type" so that (for example) an Amdahl-compatible machine with an onboard emulator (ala KNET) can determine the terminal type without having to ask the user. Also, the mode should be able to be switch back and forth (for the UCLA people, if no one else). The problem with doing an RFC, of course, is "who wants an RFC that only pertains to one class of terminals" (though the telnet RFC, after all, spends a lot of time making telnet work for IBM 2741's). Greg Minshall CFC 273 Evans Hall UC Berkeley, Ca. 94720 (ps - this message is partly a sly way of announcing a "fixed" version of tn3270 available on arpa.berkeley.edu in pub/tn3270tar; the message is also to announce the availability of tn3270 to the bitnet community) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [021787.121742.tharenos%40ibm.com] <1987021715061900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: THARENOS@IBM.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: FIN-WAIT-2 to TIME-WAIT transition Message-ID: <021787.121742.tharenos@ibm.com> Date: Tue, 17-Feb-87 20:06:19 EST Article-I.D.: ibm.021787.121742.tharenos Posted: Tue Feb 17 20:06:19 1987 Date-Received: Wed, 18-Feb-87 22:19:45 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa > The question is, what is a TCP to do if it is in FIN-WAIT-2, it has some > user data that the user hasn't asked for yet, and a FIN comes in? If it > goes immediately to TIME-WAIT (as this TCP does) the user will receive an error > because RFC 793 says that a RECEIVE call while in TIME-WAIT returns "error: Thought I'd take a stab at this one .... The key here is that a FIN implies a PUSH. It is the responsibility of your TCP to asyncronously notify the client that a PUSH has arrived and that a RECEIVE is needed. If the client is well behaved, then a RECEIVE should be forthcoming. However, this is where your question gets tricky. Should TCP wait before entering the TIME-WAIT state for the client to respond with the receive? This adds a client condition to the state table of TCP. If the client was smarter, there would be multiple RECEIVEs queued and TCP could satisfy the FIN(push) immediately and thus enter TIME-WAIT without worry. If, however, your client decides to be a bad client and wait a few hours before issuing the RECEIVE, then your question comes to light. I would venture a guess that TCP should stay in FIN-WAIT-2 until the push signal has been satisfied with a RECEIVE and then enter TIME-WAIT. Mike Tharenos Networking Support and Development IBM, Almaden Research Center 408-927-2727 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702180422.AA04555%40okeeffe.Berkeley.EDU] <1987021718221600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Problem with TCP state transitions in CLOSE Message-ID: <8702180422.AA04555@okeeffe.Berkeley.EDU> Date: Tue, 17-Feb-87 23:22:16 EST Article-I.D.: okeeffe.8702180422.AA04555 Posted: Tue Feb 17 23:22:16 1987 Date-Received: Wed, 18-Feb-87 22:53:21 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa As there was some question as to how 4.2/4.3 handle the receipt of a FIN with unreceived data, I'll answer that question. The buffering of received data and synchronization with the user programs is handled in the (generic) socket layer in 4BSD. As data is received and ordered by the TCP, it is handed to the socket layer to await a receive call. When a FIN is received (and all data preceding it), TCP processes the FIN and enters TIME_WAIT state. The user process may consume the data at its leisure, and is notified of the end of data (FIN) after the preceding data is consumed. Mike aside to Geof Cooper re: zero windows: ===aside======== The bug to which you alluded, failure to tolerate persistance of a zero window, does not occur in 4.2 as you describe it. 4.2 becomes impatient and closes only if the zero window results from shrinking a window into which it has already sent data. It will also reset a connection when new data is received, but cannot be accepted because the user process has closed and exited without waiting for the connection to close. ===edisa======== ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702180554.AA04716%40ka9q.bellcore.com] <1987021719541400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@KA9Q.BELLCORE.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TCP closes Message-ID: <8702180554.AA04716@ka9q.bellcore.com> Date: Wed, 18-Feb-87 00:54:14 EST Article-I.D.: ka9q.8702180554.AA04716 Posted: Wed Feb 18 00:54:14 1987 Date-Received: Wed, 18-Feb-87 22:47:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Who says you have to throw away pending data when the TCP connection enters the CLOSED state? In my implementation I put incoming data on a receive queue and notify the user with an upcall. The user is entirely within his rights if he chooses not to read it right away. When the connection changes state (e.g., from TIME_WAIT to CLOSED) the user is also notified with an upcall. However, the control block goes away only in response to an explicit call from the user. This gives it a chance to read any unread data or to throw it away. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702180756.AA22257%40ucbvax.Berkeley.EDU] <1987021720515900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: QUALCOMM@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: nice book on TCP/IP ?? Message-ID: <8702180756.AA22257@ucbvax.Berkeley.EDU> Date: Wed, 18-Feb-87 01:51:59 EST Article-I.D.: ucbvax.8702180756.AA22257 Posted: Wed Feb 18 01:51:59 1987 Date-Received: Wed, 18-Feb-87 22:50:29 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Is there a good book somewhere that describes TCP/IP? I want something fairly technical (not a Tanenbaum), but not deadly detailed (ie not the protocol specs). Something that included some discussion of many of the related protocols ARP, SMTP, SLIP, TELNET, etc etc would be especially useful. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021720515901> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Tue 17 Feb 87 23:47:48-PST Date: 18 Feb 1987 01:51:59 EST Subject: nice book on TCP/IP ?? From: Franklin Antonio To: tcp-ip@SRI-NIC.ARPA Is there a good book somewhere that describes TCP/IP? I want something fairly technical (not a Tanenbaum), but not deadly detailed (ie not the protocol specs). Something that included some discussion of many of the related protocols ARP, SMTP, SLIP, TELNET, etc etc would be especially useful. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021803270000> Received: from TYCHO by SRI-NIC.ARPA with TCP; Wed 18 Feb 87 06:19:44-PST Date: 18 Feb 1987 at 0827-EST Subject: re: Proteon vs Arpanet query From: hsw at TYCHO.ARPA (Howard Weiss) To: DIXON-R%OSU-20 at ohio-state.arpa cc: tcp-ip at sri-nic One pertinent piece of information you left out of your message is where is the PSN (aka IMP) you are connecting to.... If the PSN is local to you then DH should be more than adequate. If you are having problems getting a DH interface for the PSN then you should go back to your sponsoring organization and raise your collective organizational voice. On the other hand, if the PSN is NOT local and you trying to connect to one miles away (or more than 2K feet away), then you really do need HDH. The only other alternative is to put ECU boxes on each end of the connection (one at the gateway and one at the PSN). This will work just fine (we have lots of ECUs here), but DDN would rather you didn't throw extra boxes on the line that they can't remotely diagnose. Howard Weiss National Computer Security Center ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702181428.AA26977%40ucbvax.Berkeley.EDU] <1987021804314800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: hsw@TYCHO.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: re: Proteon vs Arpanet query Message-ID: <8702181428.AA26977@ucbvax.Berkeley.EDU> Date: Wed, 18-Feb-87 09:31:48 EST Article-I.D.: ucbvax.8702181428.AA26977 Posted: Wed Feb 18 09:31:48 1987 Date-Received: Thu, 19-Feb-87 18:36:35 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa One pertinent piece of information you left out of your message is where is the PSN (aka IMP) you are connecting to.... If the PSN is local to you then DH should be more than adequate. If you are having problems getting a DH interface for the PSN then you should go back to your sponsoring organization and raise your collective organizational voice. On the other hand, if the PSN is NOT local and you trying to connect to one miles away (or more than 2K feet away), then you really do need HDH. The only other alternative is to put ECU boxes on each end of the connection (one at the gateway and one at the PSN). This will work just fine (we have lots of ECUs here), but DDN would rather you didn't throw extra boxes on the line that they can't remotely diagnose. Howard Weiss National Computer Security Center ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702181909.AA15985%40pacific.ARPA] <1987021809090000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: stanonik@NPRDC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: xerox -> 4.3bsd telnet Message-ID: <8702181909.AA15985@pacific.ARPA> Date: Wed, 18-Feb-87 14:09:00 EST Article-I.D.: pacific.8702181909.AA15985 Posted: Wed Feb 18 14:09:00 1987 Date-Received: Fri, 20-Feb-87 02:04:10 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: stanonik@nprdc.arpa Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Hello, We recently installed a xerox 1186 (dandytiger?) running koto release 2.0. Telneting from the 1186 to our vax 780 running 4.3bsd hangs, apparently because the 1186 doesn't respond to the vax telnet server's "do terminal-type" negotiation. The 4.3bsd telnet server waits in a loop for the "will/won't terminal-type" response, processing options, but not starting a login process. That seems unforgiving (although seemingly legal) from 4.3bsd. We've hacked a version of the 4.3bsd telnet server, which omits the terminal-type negotiation, and put it on another port, but can't convince the 1186 to try the alternate port. Anyone else encountered this (the xerox folks say other sites have 1186s telneting to 4.3bsd machines)? Any idea how to convince the 1186 to use an alternate port for telnet? Or, is 4.3bsd wrong to "hang" waiting for the "will/won't terminal-type" response? Thanks, Ron Stanonik stanonik@nprdc.arpa ps. The 1186 also seems to violate the rfcs by sending the "terminal-type is" subnegotiation without first receiving a "terminal send". Or maybe it thinks that is a suitable response to "do terminal-type"? ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702182022.AA24496%40nprdc.arpa] <1987021810210000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: stanonik@NPRDC.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: adding a service to inetd.conf doesn't work Message-ID: <8702182022.AA24496@nprdc.arpa> Date: Wed, 18-Feb-87 15:21:00 EST Article-I.D.: nprdc.8702182022.AA24496 Posted: Wed Feb 18 15:21:00 1987 Date-Received: Fri, 20-Feb-87 02:44:49 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: stanonik@nprdc.arpa Organization: The ARPA Internet Lines: 38 Approved: tcp-ip@sri-nic.arpa Description: Adding a new service to inetd.conf and then HUPing inetd doesn't work. Connections can be made to the port, but the connection is closed when anything is sent to the port. Repeat-By: Put a copy of telnet on another port by adding the new service, say xtelnet on port 623, to /etc/services, and make the appropriate /etc/inetd.conf entry. HUP inetd. Now telnet localhost 623. The connection is made, but hitting any key closes the connection. The login herald is never seen, and what's more, checking the access date on the service reveals it wasn't execed. Fix: The problem seems to be that inetd doesn't clear the se_bi field when parsing inetd.conf, so se_bi is left flagging "internal" after the initial pass through inetd.conf. Anything service added afterward is also flagged internal. Clear the se_bi field if the service isn't internal. --- inetd.c Mon Feb 16 01:08:29 1987 *************** *** 575,581 **** } sep->se_bi = bi; sep->se_wait = bi->bi_wait; ! } argc = 0; for (arg = skip(&cp); cp; arg = skip(&cp)) if (argc < MAXARGV) --- 575,582 ---- } sep->se_bi = bi; sep->se_wait = bi->bi_wait; ! } else ! sep->se_bi = 0; argc = 0; for (arg = skip(&cp); cp; arg = skip(&cp)) if (argc < MAXARGV) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702200048.AA02250%40ucbvax.Berkeley.EDU] <1987021813090000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Vertically Moving Congestion (VMC) Message-ID: <8702200048.AA02250@ucbvax.Berkeley.EDU> Date: Wed, 18-Feb-87 18:09:00 EST Article-I.D.: ucbvax.8702200048.AA02250 Posted: Wed Feb 18 18:09:00 1987 Date-Received: Fri, 20-Feb-87 22:20:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 42 Approved: tcp-ip@sri-nic.arpa Hi people. From time to time there has been discussion on the list about what happens when you try to solve a congestion problem at a particular layer. Vary often you end up solving the problem at the layer you wanted only to find that a new layer has become congested. This can be called Vertically Moving Congestion or VMC. We've probably all seen VMC happen in many different networks. I went to a DECUS not long ago and talked to some DECNET wizards. They of course knew of the problem but hadn't addressed it. I don't think the x.25 gang have and I'm not sure about ISO. I haven't heard a lot about this from the TCP/IP bunch either. Some time ago I tried to arouse a little interest in VMC on the list and that's exactly what I got, a little interest. Time has passed and to the best of my knowledge the problem still exists (unless somebody snuck the solution by when I was asleep). I was wondering whether or not anyone had given any more thought to the following question: What kind of traffic monitoring/resource use information needs to be passed vertically to help alleviate the problem? Another interesting question: Is the problem solvable? I've been thinking about this for some years now, ever since I first ran into it. I'm not even sure I've gotten to the rule of thumb stage for an answer yet. Am I showing my ignorance of the literature here? Has someone solved this behind my back? Does anybody really care? Any takers? Chris Johnson Northeastern University csnet: johnson@nuhub.acs.northeastern.edu arpa: johnson%nuhub.acs.northeastern.edu@relay.cs.net at&t: (617) 437-2335 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021813090001> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Thu 19 Feb 87 16:30:07-PST Received: from relay2.cs.net by RELAY.CS.NET id ac09828; 19 Feb 87 0:18 EST Received: from northeastern.edu by RELAY.CS.NET id ab04675; 19 Feb 87 0:15 EST Date: Wed, 18 Feb 87 18:09 EST From: "I am only an egg." To: tcp-ip@SRI-NIC.ARPA Subject: Vertically Moving Congestion (VMC) X-VMS-To: TCP-IP Hi people. From time to time there has been discussion on the list about what happens when you try to solve a congestion problem at a particular layer. Vary often you end up solving the problem at the layer you wanted only to find that a new layer has become congested. This can be called Vertically Moving Congestion or VMC. We've probably all seen VMC happen in many different networks. I went to a DECUS not long ago and talked to some DECNET wizards. They of course knew of the problem but hadn't addressed it. I don't think the x.25 gang have and I'm not sure about ISO. I haven't heard a lot about this from the TCP/IP bunch either. Some time ago I tried to arouse a little interest in VMC on the list and that's exactly what I got, a little interest. Time has passed and to the best of my knowledge the problem still exists (unless somebody snuck the solution by when I was asleep). I was wondering whether or not anyone had given any more thought to the following question: What kind of traffic monitoring/resource use information needs to be passed vertically to help alleviate the problem? Another interesting question: Is the problem solvable? I've been thinking about this for some years now, ever since I first ran into it. I'm not even sure I've gotten to the rule of thumb stage for an answer yet. Am I showing my ignorance of the literature here? Has someone solved this behind my back? Does anybody really care? Any takers? Chris Johnson Northeastern University csnet: johnson@nuhub.acs.northeastern.edu arpa: johnson%nuhub.acs.northeastern.edu@relay.cs.net at&t: (617) 437-2335 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702192220.AA29163%40ucbvax.Berkeley.EDU] <1987021818325600> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: rick@suny-sb.CSNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: RDP for Unix Message-ID: <8702192220.AA29163@ucbvax.Berkeley.EDU> Date: Wed, 18-Feb-87 23:32:56 EST Article-I.D.: ucbvax.8702192220.AA29163 Posted: Wed Feb 18 23:32:56 1987 Date-Received: Fri, 20-Feb-87 21:18:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Anyone have an implementation of Reliable Data Protocol (RDP) for 4.3 or Sun 3.X Unix? Any general comments on RDP and its suitability for use welcomed.. Rick Spanbauer ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021818325601> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Thu 19 Feb 87 14:13:09-PST Received: from relay2.cs.net by RELAY.CS.NET id ae09635; 18 Feb 87 23:37 EST Received: from suny-sbcs by csnet-relay.csnet id ak04471; 18 Feb 87 23:33 EST Received: by sbcs (5.5/4.7) id AA05169; Wed, 18 Feb 87 23:32:56 EST Date: Wed, 18 Feb 87 23:32:56 EST From: RJ Spanbauer To: tcp-ip@SRI-NIC.ARPA Subject: RDP for Unix Cc: joes%suny-sb.csnet@RELAY.CS.NET Anyone have an implementation of Reliable Data Protocol (RDP) for 4.3 or Sun 3.X Unix? Any general comments on RDP and its suitability for use welcomed.. Rick Spanbauer ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12280226590.15.ROODE%40BIONET-20] <1987021822192300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROODE%BIONET@SUMEX-AIM.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Ethernet Security Message-ID: <12280226590.15.ROODE@BIONET-20> Date: Thu, 19-Feb-87 03:19:23 EST Article-I.D.: BIONET-2.12280226590.15.ROODE Posted: Thu Feb 19 03:19:23 1987 Date-Received: Fri, 20-Feb-87 06:37:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa The Bridges aren't irrelevant in the extent that even as they may sound elegant in the sense of permitting geographical growth to occur transparently, they do so at the expense of the administrative controls normally associable with a physical ethernet (as few as those may be). If the gateways were of a less transparent variety, some additional protection against impersonation would be provided. If the gateways are sensitive to the identity of the sender of the packets they are routing, and you trust your gateways, you have some idea of at least the physical ethernet on which packets originate. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702200937.AA12380%40ucbvax.Berkeley.EDU] <1987021904472700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@CCV.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Proteon vs Arpanet query Message-ID: <8702200937.AA12380@ucbvax.Berkeley.EDU> Date: Thu, 19-Feb-87 09:47:27 EST Article-I.D.: ucbvax.8702200937.AA12380 Posted: Thu Feb 19 09:47:27 1987 Date-Received: Sat, 21-Feb-87 04:32:32 EST References: <8702171830.AA20782@ohio-state.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa We purchased a Proteon P4200 gateway with an Arpanet card to serve as our campu s gateway to Arpanet. We were told that the gateway card supports 1822 DH, so we specified that to the Arpanet people and have been awaiting arrival of the Arpanet connection. Now the Arpanet people tell us we must change to 1822 HDH, and to work that out with our vendor. Proteon says they do not support 1822 HDH. Now what do we do? Throw out the Proteon box? Forget Arpanet? Is this a catch-22 situation? Bob Dixon Ohio State University ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021904472701> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Thu 19 Feb 87 07:57:12-PST To: Bob Dixon cc: tcp-ip@sri-nic.ARPA, brescia@ccv.bbn.com Subject: Re: Proteon vs Arpanet query In-reply-to: Your message of Tue 17 Feb 87 13:29:04-EST. <8702171830.AA20782@ohio-state.ARPA> Date: 19 Feb 87 09:47:27 EST (Thu) From: Mike Brescia We purchased a Proteon P4200 gateway with an Arpanet card to serve as our campu s gateway to Arpanet. We were told that the gateway card supports 1822 DH, so we specified that to the Arpanet people and have been awaiting arrival of the Arpanet connection. Now the Arpanet people tell us we must change to 1822 HDH, and to work that out with our vendor. Proteon says they do not support 1822 HDH. Now what do we do? Throw out the Proteon box? Forget Arpanet? Is this a catch-22 situation? Bob Dixon Ohio State University ------- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702191242.aa14622%40SEM.BRL.ARPA] <1987021907425300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@BRL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: HOST TABLE REDUCTION Message-ID: <8702191242.aa14622@SEM.BRL.ARPA> Date: Thu, 19-Feb-87 12:42:53 EST Article-I.D.: SEM.8702191242.aa14622 Posted: Thu Feb 19 12:42:53 1987 Date-Received: Sat, 21-Feb-87 04:03:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa I just got some neat automatic mail messages about the internet host table domain cleanup which points out to me some additional silliness going on. Why (this is rhetorical, I know why) are there hosts listed in the INTERNET HOST TABLE that are not INTERNET HOSTS. A host on our IMP, PERDIMS-38, is an X.25 PAD, and doesn't know IP from a hole in the ground. Yet it is Port 9 on IMP 29 so someone crafted up a 26.9.0.29 address for it. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702191826.AA14972%40bu-cs.bu.edu] <1987021908265500> 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: nice book on TCP/IP ?? Message-ID: <8702191826.AA14972@bu-cs.bu.edu> Date: Thu, 19-Feb-87 13:26:55 EST Article-I.D.: bu-cs.8702191826.AA14972 Posted: Thu Feb 19 13:26:55 1987 Date-Received: Fri, 20-Feb-87 20:42:05 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Yes, get Doug Comer's new book Volume II of his "The Design of the XINU Operating System, an Internetworking Approch" (I think I got that right, don't have it right here.) I think a perusal of it will convince you of it's applicability, he builds an entire implementation module by module, with code and text explaining it. Includes things like a diskless client/server and other goodies beyond the standard protocols. While you're down at the bookstore pick up a copy of Padlipsky's "The Elements of Networking Style". It's a small tome and explains a lot of the issues in the design decisions in a, well, let's call it "unique" style, it's very amusing and worth understanding. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702192132.AA28149%40ucbvax.Berkeley.EDU] <1987021909160100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@CCV.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Proteon vs Arpanet query Message-ID: <8702192132.AA28149@ucbvax.Berkeley.EDU> Date: Thu, 19-Feb-87 14:16:01 EST Article-I.D.: ucbvax.8702192132.AA28149 Posted: Thu Feb 19 14:16:01 1987 Date-Received: Fri, 20-Feb-87 21:17:34 EST References: <8702171830.AA20782@ohio-state.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa First, let me apologize to the whole list for sending out the previous message. It slipped through my fingers while trying to reply. (An apology is a bad thing to begin a letter with.) Bob, There are two main ways to connect to a PSN at 'level 1', the electrical level. There is 1822 DH, which is good up to about 1000 feet, and there is 'modem' which may be RS232, V.35, RS422, and possibly others. If the arpanet PSN is not in your building, and you cannot get one installed in your building, you will need some sort of modem connection. As H.Weiss pointed out, you could use ECU's to turn the modem line into a DH connection at your end and at the PSN, but ECU's are impossible for DDN to monitor and the modem line is also hidden from monitoring also. The PSN modem connections are based on HDLC, and can use HDH or X.25 ("DDN Standard X.25"). You want to see if Proteon will support either of those protocols. Disclaimer: This is a statement from a PSN user; I run gateways, not PSNs. I do not speak for DDN or the PSN support group. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021909160101> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Thu 19 Feb 87 13:27:42-PST To: Bob Dixon cc: tcp-ip@sri-nic.ARPA, brescia@ccv.bbn.com Subject: Re: Proteon vs Arpanet query In-reply-to: Your message of Tue 17 Feb 87 13:29:04-EST. <8702171830.AA20782@ohio-state.ARPA> Date: 19 Feb 87 14:16:01 EST (Thu) From: Mike Brescia First, let me apologize to the whole list for sending out the previous message. It slipped through my fingers while trying to reply. (An apology is a bad thing to begin a letter with.) Bob, There are two main ways to connect to a PSN at 'level 1', the electrical level. There is 1822 DH, which is good up to about 1000 feet, and there is 'modem' which may be RS232, V.35, RS422, and possibly others. If the arpanet PSN is not in your building, and you cannot get one installed in your building, you will need some sort of modem connection. As H.Weiss pointed out, you could use ECU's to turn the modem line into a DH connection at your end and at the PSN, but ECU's are impossible for DDN to monitor and the modem line is also hidden from monitoring also. The PSN modem connections are based on HDLC, and can use HDH or X.25 ("DDN Standard X.25"). You want to see if Proteon will support either of those protocols. Disclaimer: This is a statement from a PSN user; I run gateways, not PSNs. I do not speak for DDN or the PSN support group. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702191456.a013434%40Huey.UDEL.EDU] <1987021909563300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Proteon vs Arpanet query Message-ID: <8702191456.a013434@Huey.UDEL.EDU> Date: Thu, 19-Feb-87 14:56:33 EST Article-I.D.: Huey.8702191456.a013434 Posted: Thu Feb 19 14:56:33 1987 Date-Received: Fri, 20-Feb-87 22:03:22 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Bob, Faced with a similar problem, we feel the strategy of choice is to use Standard X.25 and beat up Proteon for its support. Rumor is circulating that Proteon may have support for that in beta test maybe in a month. However, you may wish to buck your problem upstairs via your ARPANET sponsor and squeal like stuck pig. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702191508.a013648%40Huey.UDEL.EDU] <1987021910085200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: nice book on TCP/IP ?? Message-ID: <8702191508.a013648@Huey.UDEL.EDU> Date: Thu, 19-Feb-87 15:08:52 EST Article-I.D.: Huey.8702191508.a013648 Posted: Thu Feb 19 15:08:52 1987 Date-Received: Fri, 20-Feb-87 22:04:26 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Frank, I see you went to work for the good guys. Try the DDN Protocol Handbook (two volumes plus) available from SRI International for a hundred bucks and change. The documents include several tutorial papers and overview articles. I am not aware of a comprehensive book on the subject. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702192154.AA01152%40braden.isi.edu] <1987021911545500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Telnet Option Negotiation to IBMish Hosts Message-ID: <8702192154.AA01152@braden.isi.edu> Date: Thu, 19-Feb-87 16:54:55 EST Article-I.D.: braden.8702192154.AA01152 Posted: Thu Feb 19 16:54:55 1987 Date-Received: Thu, 26-Feb-87 19:30:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 56 Approved: tcp-ip@sri-nic.arpa Mike, Your recital of the various IBM host implementations of full-screen 3278 operation did not mention the UCLA OS/MVS version, which (almost!) interoperates with the Wiscvm code. You incorrectly state that the choice of mode is between ASCII and EBCDIC encoding. Suppose there were an EBCDIC option in TELNET... this would simply be NVT encoded in EBCDIC; the only question would be whether to use CR LF or NL for end of line. Actually, the choice is between NVT and encapsulated IBM 3278 order streams. Now, the latter is about as close to binary as anything I know... it contains command code bytes, cursor positions, repeat counts, flags, and, encapsulated in all that framing and control, some EBCDIC text. It could as well be Display Code or Sanskrit. The 3278 stream is BINARY, man! You state that the Wiscnet implementation requires a fixed order of negotiation. That surprises me... in an exchange of mail several years ago Larry Landweber and I agreed on the following rules: The terminal type negotiation and the EOR negotiations may occur in any order. If EOR has been negotiated in both directions and if a 3278 terminal type has been negotiated, THEN negotiation of BINARY will cause the mode to change from NVT to full-screen-3278. Note that the BINARY is negotiated separately in each direction, which correctly synchronizes the mode change (any NVT data in the pipeline in each direction should be correctly handled). The UCLA code (v.1.6) does this correctly; I thought that Larry said the Wiscnet code did also. There is a problem with negotiating OUT of full-screen back to NVT. The MVS Telnet Server requires this; it negotiates OUT of BINARY, which returns to NVT. Returning to 3278 mode later in the Telnet connection requires only negotiating BINARY again; the EOR and Terminal Type negotiations are assumed to be persistent on the connection. The Wiscnet code, because of the hacky way they implemented Telnet using existing VM features, is unable to change a connection back to NVT mode if it begins in full-screen mode. The need for a little RFC on 3278 encapsulation in Telnet has been repeated pointed out over the past 4 years, but no one has ever felt they had the time (read $$) to pay for it. Not Wisconsin, not UCLA, not IBM FSD, not Berkeley. If would be wonderful if someone would write it down... but they had better understand the problem first. For example, the current spec uses the pre-SNA encoding, which is probably a mistake. And it is probably necessary in general to negotiate not just terminal type but also control unit type, since different IBM controllers support different wonderful features of the 3278/etc terminals. Welcome to the wonderful world of... Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702191948.aa19638%40SEM.BRL.ARPA] <1987021914480000> 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 messages Message-ID: <8702191948.aa19638@SEM.BRL.ARPA> Date: Thu, 19-Feb-87 19:48:00 EST Article-I.D.: SEM.8702191948.aa19638 Posted: Thu Feb 19 19:48:00 1987 Date-Received: Sat, 21-Feb-87 10:47:03 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 21 Approved: tcp-ip@sri-nic.arpa The idea about having mailers stick around and let TCP go "forever" to get mail though may be OK if you don't send much mail, but some of our machines find themselves having to deliver mail to >> 5,000 host/message destinations per day. It takes us several mailer daemons running in parallel to punch this much mail through. Without application level timeouts, talking to dead or overrun hosts could tie up a significant fraction of our transmission daemon resources. Not all mail systems even offer the option of having multiple transmission daemons, and instead rely on a single daemon for all mail sending operations. Clearly, application level timeouts need to be set to reasonable values. However, our experience with operating many mail-intensive machines has been that SMTP servers, even in 1987, have many failure modes. SMTP servers can fail to answer after any part of the transaction, even though their host and TCP connections are still well. This level of failure can only be dealt with by application level timeouts. Just as security can only be dealt with across all protocol levels, the issue of timeouts spans protocol levels as well. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702201425.AA15067%40ucbvax.Berkeley.EDU] <1987021922321700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ins_adsk@JHUNIX.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: remove from list Message-ID: <8702201425.AA15067@ucbvax.Berkeley.EDU> Date: Fri, 20-Feb-87 03:32:17 EST Article-I.D.: ucbvax.8702201425.AA15067 Posted: Fri Feb 20 03:32:17 1987 Date-Received: Sat, 21-Feb-87 06:33:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa To whom it may concern: Please remove me from the unix wizards mailing list. I no longer need the information from your mailing list sent to my account. Thank you. David S. Kerven (allegra!hopkins!jhunix!ins_adsk) -------------------------------------------------------------------------------- ARPA:ins_adsk%jhunix.BITNET@wiscvm.ARPA BITNET:ins_adsk@jhunix CSNET :ins_adsk@jhunix.CSNET USENET:seismo!umcp-cs!jhunix!ins_adsk ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987021922321701> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Fri 20 Feb 87 06:20:42-PST Received: from jhunix.BITNET by wiscvm.wisc.edu on 02/20/87 at 07:59:16 CST Date: Fri, 20 Feb 87 3:32:17 EST From: "Erekosse @ Magic-Users' Guild of Gwynedd" To: unix-wizards@brl-sem.arpa cc: tcp-ip@sri-nic.arpa Subject: remove from list To whom it may concern: Please remove me from the unix wizards mailing list. I no longer need the information from your mailing list sent to my account. Thank you. David S. Kerven (allegra!hopkins!jhunix!ins_adsk) -------------------------------------------------------------------------------- ARPA:ins_adsk%jhunix.BITNET@wiscvm.ARPA BITNET:ins_adsk@jhunix CSNET :ins_adsk@jhunix.CSNET USENET:seismo!umcp-cs!jhunix!ins_adsk ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987022001593600> Received: from LOKI.BBN.COM by SRI-NIC.ARPA with TCP; Fri 20 Feb 87 07:37:11-PST To: rick%suny-sb.csnet@relay.cs.net cc: tcp-ip@sri-nic.arpa Subject: re: RDP for Unix Date: Fri, 20 Feb 87 10:19:36 -0500 From: Craig Partridge > Anyone have an implementation of Reliable Data Protocol (RDP) for 4.3 or > Sun 3.X Unix? Any general comments on RDP and its suitability for use > welcomed.. Rick, Yes, there is an implementation of RDP for 4.3. I wrote it this fall and have been testing it on weekends since then. There are two other implementations that you might be able to port. My implementation also runs on SUNs, although I haven't tested it under 3.X. (I've never had time nor felt the need to upgrade my SUN-100 from 1.X). It will just drop into binary UNIX distributions if you can change the protocol switch table. I have not yet worried about distributing the code, since it is still being revised. Work is afoot to define RDP version 2, which makes some minor revisions in the protocol based on what was learned from testing this fall, and I'm installing a congestion control mechanism. Commenting on suitability for use is a bit difficult. What do you want to use it for? You can use RDP for most of the same applications you'd use TCP for but you probably don't want to in all cases. Telnet with RDP would be a bad idea (lots of 1 character segments). SMTP and FTP on the other hand, would probably benefit because RDP appears to be more robust in the face of loss. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702201541.AA16072%40ucbvax.Berkeley.EDU] <1987022005430000> 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: RDP for Unix Message-ID: <8702201541.AA16072@ucbvax.Berkeley.EDU> Date: Fri, 20-Feb-87 10:43:00 EST Article-I.D.: ucbvax.8702201541.AA16072 Posted: Fri Feb 20 10:43:00 1987 Date-Received: Sat, 21-Feb-87 06:34:41 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 28 Approved: tcp-ip@sri-nic.arpa > Anyone have an implementation of Reliable Data Protocol (RDP) for 4.3 or > Sun 3.X Unix? Any general comments on RDP and its suitability for use > welcomed.. Rick, Yes, there is an implementation of RDP for 4.3. I wrote it this fall and have been testing it on weekends since then. There are two other implementations that you might be able to port. My implementation also runs on SUNs, although I haven't tested it under 3.X. (I've never had time nor felt the need to upgrade my SUN-100 from 1.X). It will just drop into binary UNIX distributions if you can change the protocol switch table. I have not yet worried about distributing the code, since it is still being revised. Work is afoot to define RDP version 2, which makes some minor revisions in the protocol based on what was learned from testing this fall, and I'm installing a congestion control mechanism. Commenting on suitability for use is a bit difficult. What do you want to use it for? You can use RDP for most of the same applications you'd use TCP for but you probably don't want to in all cases. Telnet with RDP would be a bad idea (lots of 1 character segments). SMTP and FTP on the other hand, would probably benefit because RDP appears to be more robust in the face of loss. Craig ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702201427.aa26039%40SEM.BRL.ARPA] <1987022009274400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@BRL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: nice book on TCP/IP ?? Message-ID: <8702201427.aa26039@SEM.BRL.ARPA> Date: Fri, 20-Feb-87 14:27:44 EST Article-I.D.: SEM.8702201427.aa26039 Posted: Fri Feb 20 14:27:44 1987 Date-Received: Sat, 21-Feb-87 20:38:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Comer's book has nothing to do with TCP. He devotes a whole paragraph to it. Not to say that it isn't a good book, it is. The book has a goal of building a diskless XINU workstation. The whole thing is built on a UDP/IP network system. He goes into things from the interface on up. It's good, but don't expect to learn about TCP from it. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702201937.AA16426%40mimsy.umd.edu] <1987022009371100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mark@MIMSY.UMD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8702201937.AA16426@mimsy.umd.edu> Date: Fri, 20-Feb-87 14:37:11 EST Article-I.D.: mimsy.8702201937.AA16426 Posted: Fri Feb 20 14:37:11 1987 Date-Received: Sat, 21-Feb-87 07:32:47 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Path: mimsy!mark From: mark@mimsy.UUCP (Mark Weiser) Newsgroups: mod.protocols.tcp-ip Subject: Re: nice book on TCP/IP ?? Message-ID: <5532@mimsy.UUCP> Date: 20 Feb 87 19:37:10 GMT References: <8702191826.AA14972@bu-cs.bu.edu> Reply-To: mark@mimsy.UUCP (Mark Weiser) Organization: PRISM Group, University of Maryland, College Park, MD 20742 Lines: 15 In article <8702191826.AA14972@bu-cs.bu.edu> bzs@BU-CS.BU.EDU (Barry Shein) writes: > >Yes, get Doug Comer's new book Volume II of his "The Design of the >XINU Operating System, an Internetworking Approch" (I think I got that >right, don't have it right here.) > This is a good book, but it has nearly zero about TCP (or SMTP or other higher protocols) in it. Lots of IP, and lots of network applications and low-level network support built from scratch and justified. And lots of UDP, I think. -mark -- Spoken: Mark Weiser ARPA: mark@mimsy.umd.edu Phone: +1-301-454-7817 CSNet: mark@mimsy UUCP: {seismo,allegra}!mimsy!mark USPS: Computer Science Dept., University of Maryland, College Park, MD 20742 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702202250.a006307%40Huey.UDEL.EDU] <1987022017501400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Mills@UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: HOST TABLE REDUCTION Message-ID: <8702202250.a006307@Huey.UDEL.EDU> Date: Fri, 20-Feb-87 22:50:14 EST Article-I.D.: Huey.8702202250.a006307 Posted: Fri Feb 20 22:50:14 1987 Date-Received: Sat, 21-Feb-87 16:10:55 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Ron, I'm not worried about that or even those Honeybunch and Sperrysys X.25 gizmos there, since the table predates IP/TCP anyway. After all, this is an internet table, not only an Internet table. Having said that, the challenge for the student is how to fool a triple-X PAD into connecting to an Internet host on the X.25 side while fronting for another Internet host on the terminal side, said host speaking serially. Before you laugh me off the block, consider what has to change in the call- request packet and how to encode the IPgram on the terminal side. You are allowed to change the firmware in minor ways. No, it is not a TAC, since it does not speak TCP. It is a dial-up IP host interface for personal computers, but where the interface can speak ugly X.28 in dinosaur mode as well. I might even buy one or two. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702210659.AA02578%40erato.Think.COM] <1987022020595300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bruce@THINK.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: HDH timeouts / NSF.ARPA Message-ID: <8702210659.AA02578@erato.Think.COM> Date: Sat, 21-Feb-87 01:59:53 EST Article-I.D.: erato.8702210659.AA02578 Posted: Sat Feb 21 01:59:53 1987 Date-Received: Sat, 21-Feb-87 16:49:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa Starting 2 or 3 days ago, we have been experiencing a very weird problem. We (Think.COM, 10.4.0.6) are getting hdh timeouts (resulting in a hung interface) every time we try to communicate with one particular host, NSF.ARPA (10.9.0.20). If we ping (ICMP echo) them with 56 data bytes, everything is OK. If we try to ping them with 100 data bytes (or more), we get hdh timeouts. Probably has something to do with crossing the 128-byte frame length. We are running HDH in packet mode with ACC IF-11/HDH unibus interface. No problems talking to any other hosts. Any ideas or similar problems? This has been reported to NOC as SR#8700483. Didn't I read here that new HDH code was installed on the PSNs recently? --bruce ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12280737677.63.LIXIA%40XX.LCS.MIT.EDU] <1987022021065200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Lixia@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Vertically Moving Congestion (VMC) Message-ID: <12280737677.63.LIXIA@XX.LCS.MIT.EDU> Date: Sat, 21-Feb-87 02:06:52 EST Article-I.D.: XX.12280737677.63.LIXIA Posted: Sat Feb 21 02:06:52 1987 Date-Received: Sat, 21-Feb-87 17:26:05 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 57 Approved: tcp-ip@sri-nic.arpa > Any takers? Sure. I'm working on the problem. In fact I received your msg just when I came back from picking up a new print of my draft of a group memo, titled "The Interactions of Date Flow Control at Different Protocol Layers" I can give you a copy when it's done (be a bit patient; I have other things to do too). Some brief comments on your message: - I do not agree with the view of "vertically moving congestion". Generally speaking, each data transmission layer (link, network, internet, and transport) should have a flow control mechanism; each control has its own goals and responsibilities; none should be missing. > Vary often you end up solving the problem at the layer you >wanted only to find that a new layer has become congested. This can >be called Vertically Moving Congestion or VMC. You got this feeling because in today's networks the control is often missing at one layer or another (lack of coordiation between layers is also bad). Missing control at one layer can cause problems showing up at other layers. - I agree with you that one hardly can find studies that address this problem. I wouldn't bother to ask standardization people about it, because they don't (SHOULD NOT!) make solutions themselves to unsolved research problems; they (should) only take over solutions after the research is done and the running experience with the solutions has been collected. > I was >wondering whether or not anyone had given any more thought to the >following question: What kind of traffic monitoring/resource use >information needs to be passed vertically to help alleviate the problem? I consider we need two things here: one is a vertical communication channel that can pass info across protocol layers, another is a good flow control mechanism that has control parameters that are meaningful to other layers. I may not have made the second point clear, let me try an example: with a file transfer, can you figure out the actual rate at which data are dumped to the net, by looking at the TCP window size? You probably can't, because the throughput depends on the round trip delay too, and because window doesn't tell you how many retransmissions are made. But if you can't, the network cannot either, which means window size is not very meaningful when passed across layers. > Another interesting question: Is the problem solvable? I feel the question is a bit too broad or unclear -- what is your definition of "solvable"? Anyway, I think the answer is yes by my definition, that is, congestion can be controlled. Lixia ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702211216.AA02949%40erato.Think.COM] <1987022102165000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bruce@THINK.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: PSN MTU problem? Message-ID: <8702211216.AA02949@erato.Think.COM> Date: Sat, 21-Feb-87 07:16:50 EST Article-I.D.: erato.8702211216.AA02949 Posted: Sat Feb 21 07:16:50 1987 Date-Received: Sat, 21-Feb-87 19:37:43 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 19 Approved: tcp-ip@sri-nic.arpa Oh, I forgot to mention another problem which I first noticed last weekend. We are unable to send segments to SRI-NIC.ARPA of size MTU. This time NIC is the only host with which I have observed the problem. If I kludge our tcp to negotiate a slightly smaller MSS, everything works fine. On this end, we appear to be getting RFMNs from the long packet, but NIC evidently isn't seeing it. The connection stays alive: we retransmit the long packet, and they retransmit the previous ack. This is not the standard 4.2/4.3 driver bug of not allocating buffers at least one greater than MTU. That was fixed long ago. But the symptoms are exactly the same. This is a NEW problem, and we haven't changed any tcp/ip code here recently. Evidently we can RECEIVE mtu-sized packets from the NIC. --Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA bruce@think.com, seismo!think!bruce, bjn@mitvma.bitnet; +1 617 876 1111 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702212219.AA10849%40bu-cs.bu.edu] <1987022112192400> 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: Learning TCP Message-ID: <8702212219.AA10849@bu-cs.bu.edu> Date: Sat, 21-Feb-87 17:19:24 EST Article-I.D.: bu-cs.8702212219.AA10849 Posted: Sat Feb 21 17:19:24 1987 Date-Received: Sun, 22-Feb-87 03:04:33 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 35 Approved: tcp-ip@sri-nic.arpa Every so often someone asks for some starting material on Internetworking, I get asked a lot personally around the University here (esp my students!) Unfortunately there are several views: How to set up and administer, how to build one, how to use one, how to get a theoretical and comparative grasp (eg. a person researching network modeling.) I don't think there exists any one source for all needs, and not any real source for some needs. I suggested two just now on this list and got some flak about one, but none of the flak'ers suggested something better (does that leave Padlipsky's book as the only source in the world on understanding TCP? I don't think even he would be comfortable with that, as much as we both like the book.) I am not sure why people find the RFCs an uncomfortable place to start, I assume it is because they (the RFCs) assume you have some view of the networking milieu (eg. that you intend to build a stream interface on a packet oriented network, that's not obvious to a novitiate.) In order to understand a solution a person has to understand the problem it claims to solve. This can be elusive. Perhaps, given the relatively recent explosion of TCP/IP (et al) based networks a new list might be called for aimed at more general questions, similar to the difference between UNIX-WIZARDS (which is more like this list) and INFO-UNIX (which might be a new list, INFO-TCP?) If such a list exists it's interesting that I've never seen it mentioned here, I'll assume it doesn't exist, I don't see anything in interest-groups. I don't have the time to organize such a list, nor is it clear I would be the right person to moderate (if moderation is needed), but perhaps someone with an interest would step forward. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987022112260000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Sat 21 Feb 87 14:28:11-PST Date: 21 Feb 1987 17:26-EST Sender: CERF@A.ISI.EDU Subject: Re: Vertically Moving Congestion (VMC) From: CERF@A.ISI.EDU To: JOHNSON%nuhub.acs.northeastern.edu@RELAY.CS.NET Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]21-Feb-87 17:26:46.CERF> In-Reply-To: The message of Wed, 18 Feb 87 18:09 EST from "I am only an egg." Chris, Tony Lauck has thought a lot about vertical congestion. One interesting idea he had is to mark packets moving towards a destination with an indication that congestion was encountered. The receiving site uses this information to help adjust its window for flow control at the transport level (in addition to using local information like buffer space). Oh, Tony is the chief protocol architect for Digital Equip Corp. The other thing to observe is that congestion can show up in various ways. It can result in buffers filling up to limits, it can result in increased delays, it can show up as reduced throughput or all of the above. Also, as lost packets, increased retransmissions (missing ACKS). All these need to be thought of as clues which participants in the comm system can use to attempt to adapt. The engineering of an internet is still very much a matter for R&D, so you should feel encouraged to begin work in this area. Vint Cerf ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702220433.AA16261%40ucbvax.Berkeley.EDU] <1987022117590000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: reilly@wharton-10.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: HDH and X.25 Message-ID: <8702220433.AA16261@ucbvax.Berkeley.EDU> Date: Sat, 21-Feb-87 22:59:00 EST Article-I.D.: ucbvax.8702220433.AA16261 Posted: Sat Feb 21 22:59:00 1987 Date-Received: Sun, 22-Feb-87 10:35:40 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "G. B. Reilly" Organization: The ARPA Internet Lines: 36 Approved: tcp-ip@sri-nic.arpa A while ago, when NSF.ARPA was first being added to the Internet, it was noted that there were problems when a connection between an node that communicated with the PSN using X.25 and one that used an HDH to talk to the PSN. It appears this problem has occurred again. The system administrator at UPENN.ARPA (10.4.0.96), which uses an HDH, has noticed that his system's connection to the Internet has been dropping each time NSF.ARPA connects to send mail to the system. The people at NSF can't do much about this - let them know if you believe that a connection from them is causing your HDH problems - send mail to postmaster@note.nsf.gov Starting 2 or 3 days ago, we have been experiencing a very weird problem. We (Think.COM, 10.4.0.6) are getting hdh timeouts (resulting in a hung interface) every time we try to communicate with one particular host, NSF.ARPA (10.9.0.20). If we ping (ICMP echo) them with 56 data bytes, everything is OK. If we try to ping them with 100 data bytes (or more), we get hdh timeouts. Probably has something to do with crossing the 128-byte frame length. We are running HDH in packet mode with ACC IF-11/HDH unibus interface. No problems talking to any other hosts. Any ideas or similar problems? This has been reported to NOC as SR#8700483. Didn't I read here that new HDH code was installed on the PSNs recently? --bruce ------ ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987022117590001> Received: from wharton-10 by SRI-NIC.ARPA with TCP; Sat 21 Feb 87 20:21:58-PST Date: 21 Feb 87 22:59:00 EST From: "G. B. Reilly" Subject: HDH and X.25 To: "tcp-ip" Reply-To: "G. B. Reilly" A while ago, when NSF.ARPA was first being added to the Internet, it was noted that there were problems when a connection between an node that communicated with the PSN using X.25 and one that used an HDH to talk to the PSN. It appears this problem has occurred again. The system administrator at UPENN.ARPA (10.4.0.96), which uses an HDH, has noticed that his system's connection to the Internet has been dropping each time NSF.ARPA connects to send mail to the system. The people at NSF can't do much about this - let them know if you believe that a connection from them is causing your HDH problems - send mail to postmaster@note.nsf.gov Starting 2 or 3 days ago, we have been experiencing a very weird problem. We (Think.COM, 10.4.0.6) are getting hdh timeouts (resulting in a hung interface) every time we try to communicate with one particular host, NSF.ARPA (10.9.0.20). If we ping (ICMP echo) them with 56 data bytes, everything is OK. If we try to ping them with 100 data bytes (or more), we get hdh timeouts. Probably has something to do with crossing the 128-byte frame length. We are running HDH in packet mode with ACC IF-11/HDH unibus interface. No problems talking to any other hosts. Any ideas or similar problems? This has been reported to NOC as SR#8700483. Didn't I read here that new HDH code was installed on the PSNs recently? --bruce ------ ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702220538.AA13788%40flash.bellcore.com] <1987022119382900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FLASH.BELLCORE.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ICMP messages Message-ID: <8702220538.AA13788@flash.bellcore.com> Date: Sun, 22-Feb-87 00:38:29 EST Article-I.D.: flash.8702220538.AA13788 Posted: Sun Feb 22 00:38:29 1987 Date-Received: Sun, 22-Feb-87 10:59:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa As I mentioned in my original message, the cost of the extra memory to keep all those daemons around may be prohibitive. However, I was suggesting that the *TCP* never give up, not SMTP. Clearly you still need application-level timers for the reasons you describe (although you can get into trouble there as well by making them too short). I was saying that *TCP* perhaps is better off without a give-up timer, especially if the application has no way to control it. If the application wants to give up if TCP can't get the data across, it can set a timer of its own before sending its data. This is more in keeping with the original philosophy of TCP timers as expressed in the original spec, but nobody seemed to pay much attention to it. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987022201250000> Mail-From: STJOHNS created at 22-Feb-87 09:26:23 Date: 22 Feb 1987 09:25-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: HOST TABLE REDUCTION From: STJOHNS@SRI-NIC.ARPA To: ron@BRL.ARPA Cc: hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA]22-Feb-87 09:25:35.STJOHNS> In-Reply-To: <8702191242.aa14622@SEM.BRL.ARPA> Ron, the reason your PAD is in the hosttable is because it is physically connected to the MILNET and the NIC gets all copies of connect orders for the MILNET and puts those hosts in the host table. This has many benefits (for instance, connect to the NIC and do a "WHOIS IMP 29") and isn't something we would discontinue. 'nuff said? Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12281148225.16.ROODE%40BIONET-20] <1987022210420500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ROODE%BIONET@SUMEX-AIM.Stanford.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: ARPANET Performance problems Message-ID: <12281148225.16.ROODE@BIONET-20> Date: Sun, 22-Feb-87 15:42:05 EST Article-I.D.: BIONET-2.12281148225.16.ROODE Posted: Sun Feb 22 15:42:05 1987 Date-Received: Mon, 23-Feb-87 03:43:59 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Could someone give an update on the latest ARPANET performance problems? Has there been a significant recovery? The last we have seen on this list was word of the futile attempts to connect to the former address of a host operating a root domain server.. Off the list I have heard concerns about backbone bandwidth insufficiencies and PSN overloading, exacerbated by gateways in operation off of the PSN's. Is more known? Have others noted intermittent reduction to a non-operational state, plus an overall decreased throughput available in reaching other sites? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702231044.AA08080%40urania.Think.COM] <1987022300442500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bruce@THINK.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: problems identified Message-ID: <8702231044.AA08080@urania.Think.COM> Date: Mon, 23-Feb-87 05:44:25 EST Article-I.D.: urania.8702231044.AA08080 Posted: Mon Feb 23 05:44:25 1987 Date-Received: Tue, 24-Feb-87 01:07:57 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 8 Approved: tcp-ip@sri-nic.arpa Thanks to Mark Lotter at SRI-NIC, the problem with MTU-sized TCP segments there is fixed. Other HDH hosts have had problems with NSF.ARPA. It appears to be an X.25-to-HDH problem, which isn't surprising, since the packet frame lengths are different. I am avioding talking to them until it is fixed. --bruce ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702231159.AA06169%40dopey.AMD.COM] <1987022301595700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: news@decwrl.DEC.COM@dopey.AMD.COM Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8702231159.AA06169@dopey.AMD.COM> Date: Mon, 23-Feb-87 06:59:57 EST Article-I.D.: dopey.8702231159.AA06169 Posted: Mon Feb 23 06:59:57 1987 Date-Received: Wed, 25-Feb-87 06:38:04 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 30 Approved: tcp-ip@sri-nic.arpa Path: dopey!amdcad!cae780!hplabs!sdcrdcf!trwrb!ucla-an!stan From: stan@ucla-an.UUCP (Stan Stead M.D.) Newsgroups: comp.dcom.lans,mod.protocols.tcp-ip,comp.sources.wanted,comp.sys.ibm.pc,comp.unix.wizards,comp.unix.xenix Subject: Wanted: Xenix driver for PC Network/Token Ring Keywords: network token-ring xenix source driver Message-ID: <3@ucla-an.UUCP> Date: 23 Feb 87 05:49:15 GMT Distribution: usa Organization: Dept. Anesthesia, Sch. of Med., UCLA, Los Angeles Lines: 19 We are interested in using the Token Ring or PC Network as a DDN interface into our local ethernet, to ARPA and beyond. While it doesn't look that difficult (it never does) we are reluctant to re-invent the wheel. What we really need is source code for a PC Network or Token Ring driver. Has anyone developed a Xenix driver for either the PC Network boards or Token Ring? I have heard that SCO has such a driver, but I do not know of anyone using it. Thanks in advance. Stanley W. Stead UCLA School of Medicine / Dept of Anesthesiology BELL: (213) 206-6238 ARPA: ucla-an!stan@ee.UCLA.EDU UUCP: {trwrb|ucla-cs|cepu}\ !ucla-an!stan UUCP: {ihnp4|decvax}!hermix/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870223132615.223344%40MIT-MULTICS.ARPA] <1987022303260000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Kodinsky@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Please Add to List Message-ID: <870223132615.223344@MIT-MULTICS.ARPA> Date: Mon, 23-Feb-87 08:26:00 EST Article-I.D.: MIT-MULT.870223132615.223344 Posted: Mon Feb 23 08:26:00 1987 Date-Received: Wed, 25-Feb-87 06:38:39 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa Please add me to your tcp/ip mailing list. Thanks Frank Kastenholz MIT-MULTICS.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702231733.AA28625%40saturn.dec.com] <1987022307451700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kent@DECWRL.DEC.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ICMP messages Message-ID: <8702231733.AA28625@saturn.dec.com> Date: Mon, 23-Feb-87 12:45:17 EST Article-I.D.: saturn.8702231733.AA28625 Posted: Mon Feb 23 12:45:17 1987 Date-Received: Thu, 26-Feb-87 19:31:33 EST References: <8702220538.AA13788@flash.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Christopher A. Kent" Organization: The ARPA Internet Lines: 29 Approved: tcp-ip@sri-nic.arpa Gee, this sounds very reminiscent of the (once popular, now extinct?) Delta-T protocol, a "timer-based connectionless protocol" originally proposed by Dick Watson at LLNL. It (and the whole class) are wholly timer based, with a window mechanism for flow control, but no 3-way handshakes on open/close. The key parameter is the "maximum roundtrip packet lifetime", or Delta-T. By knowing the maximum amount of time any packet will live, you can start sending data in the first packet because you know all stragglers will have been discarded. Delta-T essentially assumes everyone is talking to everyone else all the time, but there are gaps in conversations. If the gaps are longer than Delta-T, there is no need to keep state information about. Thus, the protocol state information is essentially a cache of recent interchanges. Of course, this all depends on accurate estimates of Delta-T, but then, so does TCP. Watson proposed a "link timing protocol" which slips in between an IP-type protocol and a transport-type protocol to provide the necessary timing information. I'm not clear on how a Delta-T style protocol fits into a large internet with many gateways on hops, but it's an interesting class of protocols to think aboiut, now that it seems that TCP performance and robustness are turning out to be heavily reliant on accurate timer estimates. Cheers, chris ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702231830.AA01935%40spam.istc.sri.com] <1987022308301700> 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: Learning TCP Message-ID: <8702231830.AA01935@spam.istc.sri.com> Date: Mon, 23-Feb-87 13:30:17 EST Article-I.D.: spam.8702231830.AA01935 Posted: Mon Feb 23 13:30:17 1987 Date-Received: Thu, 26-Feb-87 18:35:56 EST References: <8702212219.AA10849@bu-cs.bu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa The trick to learning the Internet protocols (for me at least) was knowing where to look for things. I found these sources to be valuable for different things. * RFCs -- for the protocol definition or guidelines to protocol implementors * The networking portions of the operating system documentation -- for general overviews of how the protocols fit into the operating system * Books -- better explanations of the protocols than RFCs, plus examples (Tanenbaum comes to mind, but since the book predates the current Internet setup a lot of information isn't there, like TCP, EGP, etc.) * The source code -- when the documentation isn't enough, or something is broken * A guru -- when I can't figure out how to do it myself * This list -- when I and the guru can't figure out how to do it ourselves, or there is no guru * Conferences -- for sharing information in person, and hearing what the gurus have to say Perhaps some ambitious person with a lot of time on their hands could write a series of books encompassing all this information. Fundamental Protocols, anyone? :-) --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702232001.AA16061%40ucbvax.Berkeley.EDU] <1987022308585200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: PADLIPSKY@A.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Ethernet Security Message-ID: <8702232001.AA16061@ucbvax.Berkeley.EDU> Date: Mon, 23-Feb-87 13:58:52 EST Article-I.D.: ucbvax.8702232001.AA16061 Posted: Mon Feb 23 13:58:52 1987 Date-Received: Thu, 26-Feb-87 20:48:40 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 37 Approved: tcp-ip@sri-nic.arpa Apologies for the delay; my linkage to the List has been temporarily broken (for about a month now) and it was only through the good offices of a colleague that I learned my expertise had been appealed for/to a week or so ago. By a happy coincidence, the extra time meant that I was able to confer with Jon Postel on the subtle technophilosophical questions posed (during the course of a conversation on a far less intriguing topic), so my response is actually even more profound than it might have been had it been more timely. Of course, on the very first point we couldn't quite agree: I hold that Ethernet physical addresses must be somewhere between L 1.9 and L 2.1, whereas Jon says 1.7-2.7 (or was it .7-2.7?). We did agree that they can't be at -1 because that's where X.75 is, and I'm confident they can't be at 0 since whatever "Sevice Access Points" mean they don't seem to be any better equipped to deal with zero-indexing than any of us. (Probably a great deal less so, come to think of it.) I also believe Jon would agree that if Bob Metcalfe wanted to argue that in "the real Ethernet/XNS" they could also be viewed as being at L 3 we'd have to consider such a view favorably, even if it is rather meta-Physical. (Didn't mean to be overconstraining: Dave Boggs could also make the argument--even John Schoch, if I could remember how to spell his name.) The even harder problem as to what layer university administrators' phobias belong in did get a joint resolution, however: 68i. (The analysis was too involved and esoteric to do justice to in this medium, unfortunately.) Thanks for asking; it's always a pleasure to be of service. (Better CC: me directly for the time being if there's anything else you want to know: the linkage is still flakey and I won't even be pretending to glance at all msgs for some time [if ever].) glossabuccal cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987022308585201> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 23 Feb 87 11:40:36-PST Date: 23 Feb 1987 13:58:52 EST From: PADLIPSKY@A.ISI.EDU Subject: Re: Ethernet Security To: tcp-ip@SRI-NIC.ARPA Apologies for the delay; my linkage to the List has been temporarily broken (for about a month now) and it was only through the good offices of a colleague that I learned my expertise had been appealed for/to a week or so ago. By a happy coincidence, the extra time meant that I was able to confer with Jon Postel on the subtle technophilosophical questions posed (during the course of a conversation on a far less intriguing topic), so my response is actually even more profound than it might have been had it been more timely. Of course, on the very first point we couldn't quite agree: I hold that Ethernet physical addresses must be somewhere between L 1.9 and L 2.1, whereas Jon says 1.7-2.7 (or was it .7-2.7?). We did agree that they can't be at -1 because that's where X.75 is, and I'm confident they can't be at 0 since whatever "Sevice Access Points" mean they don't seem to be any better equipped to deal with zero-indexing than any of us. (Probably a great deal less so, come to think of it.) I also believe Jon would agree that if Bob Metcalfe wanted to argue that in "the real Ethernet/XNS" they could also be viewed as being at L 3 we'd have to consider such a view favorably, even if it is rather meta-Physical. (Didn't mean to be overconstraining: Dave Boggs could also make the argument--even John Schoch, if I could remember how to spell his name.) The even harder problem as to what layer university administrators' phobias belong in did get a joint resolution, however: 68i. (The analysis was too involved and esoteric to do justice to in this medium, unfortunately.) Thanks for asking; it's always a pleasure to be of service. (Better CC: me directly for the time being if there's anything else you want to know: the linkage is still flakey and I won't even be pretending to glance at all msgs for some time [if ever].) glossabuccal cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702232051.AA15610%40flash.bellcore.com] <1987022310515700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FLASH.BELLCORE.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ICMP messages Message-ID: <8702232051.AA15610@flash.bellcore.com> Date: Mon, 23-Feb-87 15:51:57 EST Article-I.D.: flash.8702232051.AA15610 Posted: Mon Feb 23 15:51:57 1987 Date-Received: Thu, 26-Feb-87 22:19:34 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 23 Approved: tcp-ip@sri-nic.arpa As further argument in favor of my position that TCP should not give up unless the user process requests it, I have lately been deluged with complains from users that they and their correspondents are being flooded with duplicate but incomplete mail messages. It seems that frequently the net path is just good enough to get a SMTP connection going, but when it gets to the body of the message, good old Berkeley TCP quickly gives up in disgust. A half hour later the mailer tries again, ad nauseum. Not only does this put lots of garbage into people's mailboxes, it wastes net resources and contributes to congestion collapse. There is no facility that I know of in our mail system for filtering out duplicate mail messages, but I don't believe one should really be necessary; TCP should just be more patient. I perceive that part of the problem is the fact that many (if not most) TCP/IP vendors are not the Internet, so they never encounter these problems on their own. I would like to make a radical policy suggestion: being a TCP/IP vendor should be sufficient cause by itself to justify a connection to the Internet (preferably through a slow and expensive X.25 connection that THEY have to pay for). The payback in "clean" implementations for the rest of us will be more than worth it. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987022317350000> Received: from A.ISI.EDU by SRI-NIC.ARPA with TCP; Mon 23 Feb 87 19:37:02-PST Date: 23 Feb 1987 22:35-EST Sender: CERF@A.ISI.EDU Subject: Re: ICMP messages From: CERF@A.ISI.EDU To: kent@SONORA.DEC.COM Cc: mike@BRL.ARPA, tcp-ip@SRI-NIC.ARPA Message-ID: <[A.ISI.EDU]23-Feb-87 22:35:52.CERF> In-Reply-To: <8702231733.AA28625@saturn.dec.com> Delta-T got implemented. Dan Nessett at Livermore had a lot to say about it out in San Diego at the FCCSET meetng last week. I don't have Dan's electronic mail address in hand, but you might be able to find it through the NIC or via Dick Watson if you have that. The hard problem is insuring that packet lifetimes will stay constrained to the limit you require - otherwise the protocol will get confused when old duplicate packets arrive when they should have been flushed from the system. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702240349.AA15593%40dolqci.LOCAL] <1987022317552300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: uucp@seismo.CSS.GOV@dolqci.UUCP Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8702240349.AA15593@dolqci.LOCAL> Date: Mon, 23-Feb-87 22:55:23 EST Article-I.D.: dolqci.8702240349.AA15593 Posted: Mon Feb 23 22:55:23 1987 Date-Received: Thu, 26-Feb-87 23:17:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 37 Approved: tcp-ip@sri-nic.arpa Date: 24 Feb 87 03:49:00 GMT To: seismo!mod-protocols-tcp-ip@seismo.CSS.GOV Subject: Submission for mod-protocols-tcp-ip Responding-System: dolqci.UUCP Path: dolqci!vrdxhq!seismo!rutgers!sri-unix!hplabs!sdcrdcf!trwrb!ucla-an!stan From: stan@ucla-an.UUCP (Stan Stead M.D.) Newsgroups: comp.dcom.lans,mod.protocols.tcp-ip,comp.sources.wanted,comp.sys.ibm.pc,comp.unix.wizards,comp.unix.xenix Subject: Wanted: Xenix driver for PC Network/Token Ring Keywords: network token-ring xenix source driver Message-ID: <3@ucla-an.UUCP> Date: 23 Feb 87 05:49:15 GMT Distribution: usa Organization: Dept. Anesthesia, Sch. of Med., UCLA, Los Angeles Lines: 19 We are interested in using the Token Ring or PC Network as a DDN interface into our local ethernet, to ARPA and beyond. While it doesn't look that difficult (it never does) we are reluctant to re-invent the wheel. What we really need is source code for a PC Network or Token Ring driver. Has anyone developed a Xenix driver for either the PC Network boards or Token Ring? I have heard that SCO has such a driver, but I do not know of anyone using it. Thanks in advance. Stanley W. Stead UCLA School of Medicine / Dept of Anesthesiology BELL: (213) 206-6238 ARPA: ucla-an!stan@ee.UCLA.EDU UUCP: {trwrb|ucla-cs|cepu}\ !ucla-an!stan UUCP: {ihnp4|decvax}!hermix/ ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702240603.AA16756%40bu-cs.bu.edu] <1987022320033500> 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: ICMP messages Message-ID: <8702240603.AA16756@bu-cs.bu.edu> Date: Tue, 24-Feb-87 01:03:35 EST Article-I.D.: bu-cs.8702240603.AA16756 Posted: Tue Feb 24 01:03:35 1987 Date-Received: Fri, 27-Feb-87 00:48:20 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 17 Approved: tcp-ip@sri-nic.arpa I think duplicate and incomplete mail messages as a result of STMP delivery is a bug in the SMTP implementation, plain and simple. If the final '.' is not received the message should have been discarded. Is it really clear it would be easier to redesign and re-implement the way TCP handles errors than to simply fix the mailer agent to wait for a dot? Really not trying to make a global statement on the issue at hand, just thought this was not the right example of how to solve a problem. I had that problem and it turned out that the root cause was a frag bug, as well as SMTP being too anxious to deliver less than a whole message. It's all so complicated... -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12281523134.6.MRC%40PANDA] <1987022321013100> 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: ICMP messages Message-ID: <12281523134.6.MRC@PANDA> Date: Tue, 24-Feb-87 02:01:31 EST Article-I.D.: PANDA.12281523134.6.MRC Posted: Tue Feb 24 02:01:31 1987 Date-Received: Thu, 26-Feb-87 23:49:07 EST References: <8702232051.AA15610@flash.bellcore.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 33 Approved: tcp-ip@sri-nic.arpa I am aware of two causes of the multiple-copies-of-the-same-message bug that are caused by poor design of a version of the Unix SMTP server that runs in all too many Unix hosts. When the end-of-message signal (.) is received, this server spawns a program that appears to be called "sndmsg" to deliver the message to all the recipients and it insists upon "sndmsg" running to completion before it will return a success reply code to the SMTP client. The first problem happens when there are lots of recipients of this message and the server's system is a bit loaded. Many SMTP clients get fed up if the server doesn't acknowledge the message within a reasonable period of time (e.g. 5 minutes). They decide the server is hung, nuke the connection and try again later. Even if you don't believe in timeouts, you must recognize that not all systems are pleased to have an SMTP stream waiting forever for a hung SMTP server. The second problem will happen with ANY correctly-coded SMTP client. Somewhere along the line, "sndmsg" runs into trouble. The SMTP server sends a 4xx series message with the extremely informative phrase "sndmsg balks, try again later". The message has been delivered to some recipients, but not to others. But since this is a "whole message failure", it gets retried for everybody. I hope that we can see the extinction of this version of the Unix SMTP server soon. The server should NOT make the client wait while a message is being delivered. The "sndmsg balks" bug shows why this behavior is so wrong-headed. An acknowledgement should be sent as soon as the end of message signal is received. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12281548324.15.DUMAS%40SUMEX-AIM.STANFORD.EDU] <1987022323195300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: DUMAS@SUMEX-AIM.STANFORD.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: REPLYS TO SATELLITE GATEWAYS Message-ID: <12281548324.15.DUMAS@SUMEX-AIM.STANFORD.EDU> Date: Tue, 24-Feb-87 04:19:53 EST Article-I.D.: SUMEX-AI.12281548324.15.DUMAS Posted: Tue Feb 24 04:19:53 1987 Date-Received: Thu, 26-Feb-87 23:57:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 120 Approved: tcp-ip@sri-nic.arpa Thanks to all people who took the time to answer to my request for informations on Satellite gateway. We are an educational and research institution in France, and we intend to develop a satellite gateway (based on earth ...) .Our purpose is to interconnect baseband Ethernet networks using TCP/IP, and later ISO Transport Services on top of the Tcp. The hardware, that we shall use is a French 68000 based machine with a specific bus, running Unix sys 5. We shall send later a brief description of our own developments for peoples interested by the subject. I have summarized the answers. They were very useful for us. ================================================================== Date: 29 Jan 87 10:53:46 EST (Thu) From: Robert Hinden Jean-Pierre, What is a Satellite gateway? Is that a gateway that is in a Satellite? We sell,supply, and operate earth based gateways for several clients, including DARPA and DDN, which are DOD IP Internet gateway which connect to a variety of networks, including DDN (1822 and X.25), Ethernet, Satnet, Wideband, and gateway trunks. The gateway is based on the BBN Butterfly Multiprocessor. Currently we have 19 installed in locations from Calf. to Europe. We will be installing an additonal 25 in the next year or so. ==================================================================== Date: Fri, 30 Jan 87 12:19:32 MST From: haas%utah-gr@utah-cs.arpa (Walt Haas) I believe that Vitalink makes some earth stations you could use with TCP/IP. They can be reached at 1350 Charleston Rd. Mt. View, CA 94043 (415) 968-5465 ===================================================================== Date: Tue, 3 Feb 87 09:48:38 pst From: hplabs!cae780!ubvax!dcrocker@ucbvax.Berkeley.EDU (Dave Crocker) Ungermann-Bass has a collection of TCP/IP products, including intelligent PC cards and async terminal concentrators. IP Routers (gateways) are in the offing. The product line includes the ability to down-load the hardware from a network management center. This has been used over a satellite link. Dave Software Development 408-562-7678 ==================================================================== Date: Tue, 3 Feb 87 12:05:37 pst From: Robert Michaels Hi: I saw your message on the TCP-IP mailing list asking about experiences with satellites. We recently made use of a satellite link to connect IP networks which I think may be of interest. Our Internet: HP has built a small internet using cisco AGS gateways equipped with their 56Kbit serial interface. The network connects divisions in the bay area via HP's Bay Area Microwave network. It also ties in divisons in Oregon and Colorado via a 56kbit channels on our leased T1 lines. In Palo Alto the various buildings are interconnected via a broadband system. The Satellite Link: It was the above network we wanted to connect to the show network at the UniForum trade show in Washington DC two weeks ago. We contracted VitaLink to provide the dish and technician at the convention and used HPs own equipment here in Palo Alto. The link was 56Kbit, running on KU band. In Palo Alto we have a 3.7m dish and at the convention they used a 1.8m dish. All hardware including modems and RF amp are built by Vitalink. The modems have a simple V.35 connection - which meant all we had to do was convert the V.35 to RS232 so it could connect to the cisco AGS. The link worked very well - delay was not objectionable. The only problem we had was snow, however, VitaLink has a dial in system via land lines to their modems and was able to detect the attenuation of the signal and alert the technician to sweep out the dish. (permanent installations have shields to protect against snow and ice). About the cisco boxes: The access control features of the gateway were very useful in controlling who had access to our internet. The lack of a V.35 interface is annoying but Black Box makes a good little hack. I see this TransLAN (DEC Bridge100) thing as a major loose. At the convention we also used a 9600 baud dial up modem as a back-up if the satellite link failed. We ran both links simultaneously - something we could never do with TransLAN. Well, that's not true, we could connect both links but TransLAN would detect the a "loop" and promptly shut down one of the links. Hope this is of interest to you. Regards, Robert Michaels ================================================================ +--------------------------------------------------+ | Gerard H. Gaye | | CEN Saclay | | | | gaye@frsac11 (bitnet) | | gaye%frsac11.bitnet@wiscvm.wisc.edu (arpanet) | | | | also: dumas@sumex.stanford.edu | +--------------------------------------------------+ ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987022400281000> Received: from LOKI.BBN.COM by SRI-NIC.ARPA with TCP; Tue 24 Feb 87 05:54:24-PST To: karn%flash.bellcore.com@sh.cs.net cc: tcp-ip@sri-nic.ARPA Subject: TCP vs SMTP (was ICMP and TCP) Date: Tue, 24 Feb 87 08:48:10 -0500 From: Craig Partridge Phil, Any sense of which kinds of mailers (i.e. Sendmail, MMDF, something else?) are generating the duplicate messages? There are timers at the SMTP level in many implementations (limiting how long one is willing to wait before receiving a reply to a command) and since the congestion problems started I've felt that we needed to look more carefully at SMTP timer policies. I actually started on this task, and rapidly concluded I didn't have the time to do the necessary research to devise a better algorithm than those already in use. Craig "Timers, always the timers...." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702241409.AA05301%40ucbvax.Berkeley.EDU] <1987022404104200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: craig@LOKI.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: TCP vs SMTP (was ICMP and TCP) Message-ID: <8702241409.AA05301@ucbvax.Berkeley.EDU> Date: Tue, 24-Feb-87 09:10:42 EST Article-I.D.: ucbvax.8702241409.AA05301 Posted: Tue Feb 24 09:10:42 1987 Date-Received: Fri, 27-Feb-87 00:40:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 16 Approved: tcp-ip@sri-nic.arpa Phil, Any sense of which kinds of mailers (i.e. Sendmail, MMDF, something else?) are generating the duplicate messages? There are timers at the SMTP level in many implementations (limiting how long one is willing to wait before receiving a reply to a command) and since the congestion problems started I've felt that we needed to look more carefully at SMTP timer policies. I actually started on this task, and rapidly concluded I didn't have the time to do the necessary research to devise a better algorithm than those already in use. Craig "Timers, always the timers...." ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702241543.AA06368%40oddjob.uchicago.edu] <1987022405432700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: matt@ODDJOB.UCHICAGO.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: SUPDUP Message-ID: <8702241543.AA06368@oddjob.uchicago.edu> Date: Tue, 24-Feb-87 10:43:27 EST Article-I.D.: oddjob.8702241543.AA06368 Posted: Tue Feb 24 10:43:27 1987 Date-Received: Fri, 27-Feb-87 00:09:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 3 Approved: tcp-ip@sri-nic.arpa Are there any available SUPDUP implementations for 4.X BSD? Matt Crawford ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702241636.AA00792%40braden.isi.edu] <1987022406361200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ICMP messages Message-ID: <8702241636.AA00792@braden.isi.edu> Date: Tue, 24-Feb-87 11:36:12 EST Article-I.D.: braden.8702241636.AA00792 Posted: Tue Feb 24 11:36:12 1987 Date-Received: Fri, 27-Feb-87 01:32:10 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa Chris, All the present and proposed "transaction" protocols (Birrell&Nelson, VMTP, SEP, TTP, etc.) being discussed in the End2end Taskforce do in fact depend upon the Delta-T concept (which you have so cogently summarized) to avoid an initial handshake. Delta-T was never "popular", since it was implemented only at LBL; it is much less well known in our field than it deserves. Dick Watson thought through the consequences of his assumptions more thoroughly than we often do, and his papers are recommended reading for anyone new to the protocol design field. Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702241742.AA10186%40flash.bellcore.com] <1987022407421000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: karn@FLASH.BELLCORE.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: ICMP messages Message-ID: <8702241742.AA10186@flash.bellcore.com> Date: Tue, 24-Feb-87 12:42:10 EST Article-I.D.: flash.8702241742.AA10186 Posted: Tue Feb 24 12:42:10 1987 Date-Received: Fri, 27-Feb-87 01:34:21 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 11 Approved: tcp-ip@sri-nic.arpa Granted, sendmail is royally screwed up and it shouldn't deliver a partial message. But I still think that TCP shouldn't give up so easily. Most of our network outages are caused by one of several things: our Telenet X.25 interface wedges, csnet-relay's IMP interface wedges (speculation), and/or our route drops out of the EGP tables. If TCP just kept trying but backing off on each retransmission, it wouldn't have to start over when service resumes, our load on the network would decrease, and sendmail wouldn't have to contend with message fragments in the first place. Needless to say, this also implies disabling the TCP keepalive feature that was hacked into BSD. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702241936.AA19824%40ucbarpa.Berkeley.EDU] <1987022409363000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jordan@UCBARPA.BERKELEY.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: duplicate message in SMTP ("sndmsg balks, try again later") Message-ID: <8702241936.AA19824@ucbarpa.Berkeley.EDU> Date: Tue, 24-Feb-87 14:36:30 EST Article-I.D.: ucbarpa.8702241936.AA19824 Posted: Tue Feb 24 14:36:30 1987 Date-Received: Fri, 27-Feb-87 00:10:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa mark crispin, i have seen this behaviour as well, but found it not on the UNIX side (alas, sendmail has no routine sndmsg() ...), but on the side of a VMS machine running some sort of SMTP (software tools?) that manages to exceed sendmail's fondness for mangling headers ... and i agree that once the message has been received, a 2xx acknowledgement is in order; not quite sure why sendall() in sendmail comes before the 2xx ack. /jordan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702242033.AA21637%40ucbarpa.Berkeley.EDU] <1987022410331200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jordan@UCBARPA.BERKELEY.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: a clarification Message-ID: <8702242033.AA21637@ucbarpa.Berkeley.EDU> Date: Tue, 24-Feb-87 15:33:12 EST Article-I.D.: ucbarpa.8702242033.AA21637 Posted: Tue Feb 24 15:33:12 1987 Date-Received: Fri, 27-Feb-87 04:38:29 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa (glad i put a '?' next to it ...) -- the sndmsg balks stuff is from Wollongong's VMS mailer ... egged-face, /jordan ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702242117.AA03200%40uahcs1.UUCP] <1987022411171400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: streeter@1141g.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8702242117.AA03200@uahcs1.UUCP> Date: Tue, 24-Feb-87 16:17:14 EST Article-I.D.: uahcs1.8702242117.AA03200 Posted: Tue Feb 24 16:17:14 1987 Date-Received: Fri, 27-Feb-87 23:52:36 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 25 Approved: tcp-ip@sri-nic.arpa Date: 24 Feb 87 21:11:54 GMT To: ingr!uahcs1!scbhq!sb6!akgua!gatech!mod-protocols-tcp-ip Subject: Submission for mod-protocols-tcp-ip Responding-System: 1141g.UUCP Path: 1141g!streeter From: streeter@1141g.UUCP (Guy Streeter) Newsgroups: mod.protocols.tcp-ip Subject: socket to TLI translation? Keywords: sockets, tli Message-ID: <168@1141g.UUCP> Date: 24 Feb 87 21:11:54 GMT Distribution: usa Organization: Society for the Happily Mediocre Lines: 9 We have some applications based on sockets, and we have a TLI interface. What we need is to translate between the two. Has this been done? Could someone point out literature or source code that would aid us in implementing an interface between Sockets and the Transport Layer Interface? thanks, Guy Streeter akgua!ingr!guy!streeter ----MESSAGE-END---- ----MESSAGE-BEGIN---- [SRA.12281692749.BABYL%40XX.LCS.MIT.EDU] <1987022412330000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: SRA@XX.LCS.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: SUPDUP Message-ID: Date: Tue, 24-Feb-87 17:33:00 EST Article-I.D.: XX.SRA.12281692749.BABYL Posted: Tue Feb 24 17:33:00 1987 Date-Received: Fri, 27-Feb-87 03:33:26 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 12 Approved: tcp-ip@sri-nic.arpa Date: Tuesday, 24 February 1987 10:43-EST From: "Yow! I've been EXIT POLLED" Are there any available SUPDUP implementations for 4.X BSD? Yes. Send mail to bug-supdup@borax.lcs.mit.edu to get in touch with whoever hacks it these days. It was written by Dave Bridgham, then of MIT, now with FTP Software. It works very well, allowing for the lack of operating system support for things like %PIATY signals. --Rob ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702242147.aa13389%40SEM.BRL.ARPA] <1987022416470300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ron@BRL.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: duplicate message in SMTP ("sndmsg balks, try again later") Message-ID: <8702242147.aa13389@SEM.BRL.ARPA> Date: Tue, 24-Feb-87 21:47:03 EST Article-I.D.: SEM.8702242147.aa13389 Posted: Tue Feb 24 21:47:03 1987 Date-Received: Fri, 27-Feb-87 05:11:58 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa I that sndmsg (451 sndmsg balks!) was the BBN C70 UNIX mail system. Jordan is right, neither sendmail or MMDF does this. MMDF closes the file it was writing the message into, queues the message, and sends the return code. It does not verify the message at that the final dot point. It just makes sure it has stored the message so that subsequent failures can make use of the return path to send the failed mail messages. -Ron ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702251358.AA03547%40usfvax2.UUCP] <1987022503150000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: larry@pdn.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8702251358.AA03547@usfvax2.UUCP> Date: Wed, 25-Feb-87 08:15:00 EST Article-I.D.: usfvax2.8702251358.AA03547 Posted: Wed Feb 25 08:15:00 1987 Date-Received: Fri, 27-Feb-87 23:53:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 26 Approved: tcp-ip@sri-nic.arpa Path: pdn!larry From: larry@pdn.UUCP (Larry Swift) Newsgroups: mod.protocols.tcp-ip Subject: Re: Vertically Moving Congestion (VMC) Message-ID: <651@pdn.UUCP> Date: 25 Feb 87 13:14:59 GMT References: <8702200048.AA02250@ucbvax.Berkeley.EDU> Reply-To: larry@pdn.UUCP (0000-Larry Swift) Organization: Paradyne Corporation, Largo, Florida Lines: 17 In article <8702200048.AA02250@ucbvax.Berkeley.EDU> JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.") writes: >Vary often you end up solving the problem at the layer you >wanted only to find that a new layer has become congested. > That's why the OSI Reference Model has some form of flow control in *all* layers one thru five. The Session Layer (layer 5) is where the data path is finally narrowed to a single user, and therefore s/his ability to consume network resources can be limited there. There are many good reference works on the OSI Model. -------------------------------- Larry Swift UUCP: {ihnp4,gatech,cbosgd}!akgua!usfvax2!pdn!larry Snail mail: LF-207, Paradyne Corp., 8550 Ulmerton Road, Largo, FL, 33541 Phone: (813) 530-8605 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702251624.AA18802%40utah-cs.ARPA] <1987022506242200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cetron@UTAH-CS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: a clarification Message-ID: <8702251624.AA18802@utah-cs.ARPA> Date: Wed, 25-Feb-87 11:24:22 EST Article-I.D.: utah-cs.8702251624.AA18802 Posted: Wed Feb 25 11:24:22 1987 Date-Received: Fri, 27-Feb-87 21:28:01 EST References: <8702242033.AA21637@ucbarpa.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: utah-cs!cetron (Edward J Cetron) Distribution: world Organization: Center for Engineering Design, Univ of Utah Lines: 21 Approved: tcp-ip@sri-nic.arpa In article <8702242033.AA21637@ucbarpa.Berkeley.EDU> jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes) writes: >(glad i put a '?' next to it ...) -- the sndmsg balks stuff is from >Wollongong's VMS mailer ... > >egged-face, > >/jordan Don't feel quite so bad, the software tools mailer is somewhat similar: After it receives the 'terminating' . it spawns off a subshell which attempts to send the receive message header information to a mailer daemon....if the send works (address is valid, header info complete, etc) then it returns and the SMTP server responds with the OK message. If not, it sends the appropriate error code (syntax error in address - see RFC 822, date missing etc...). There IS a window where the remote mailer could time out, but to date I have never seen this actually happen - remember, it is NOT trying to deliver the message, just verify the headers and queue it for delivery..... -ed cetron cetron@utah-cs.arpa ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702251221.a018758%40Huey.UDEL.EDU] <1987022507213900> 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 messages Message-ID: <8702251221.a018758@Huey.UDEL.EDU> Date: Wed, 25-Feb-87 12:21:39 EST Article-I.D.: Huey.8702251221.a018758 Posted: Wed Feb 25 12:21:39 1987 Date-Received: Fri, 27-Feb-87 21:10:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 13 Approved: tcp-ip@sri-nic.arpa Phil, While not planting feet securely in either camp (you both have valid points), it's amazing how your perspective changes when operating a dinky Ethernet between an ARPANET gateway and another gateway to a vast swamp and when all paths to that swamp have died for a week. You start searching for words like "M16 effect" to describe the carnage as the pileup of multiple j-random hosts try to slosh mail across the dink. Howcum that mail got as far as the dink? Well, turns out the swamp in question had no way to declare itself down. Jack Haverty, where are you when we need you? Grumble-mumble and back to work. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702251945.AA01525%40braden.isi.edu] <1987022509455700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Delta-T Paper Message-ID: <8702251945.AA01525@braden.isi.edu> Date: Wed, 25-Feb-87 14:45:57 EST Article-I.D.: braden.8702251945.AA01525 Posted: Wed Feb 25 14:45:57 1987 Date-Received: Fri, 27-Feb-87 22:42:11 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa We Computer Technologists are noted for standing on each other's toes rather than each other's shoulders [I first heard that metaphor from Alan Newell in 1966, but it has also be attributed to Herb Simon], when we make what we like to think of as progress. If this sounds like a collective rebuke, it is. Since the recent exchange about Delta-T, I have received three different requests for a reference to Dick Watson's work. The requestors were all well-known members of this community; that is both the good and the bad news. So that I will not have to send it out yet again... IEN193, which is a reprint of "Timer-Based Mechanisms in Reliable Transport Protocol Connection Management" (Computer Networks, 5 (1981) 47-56). An important and interesting paper. Dick, I think you are on this mailing list, can you suggest any other paper on your Delta-T work? Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702252011.AA06273%40ucbvax.Berkeley.EDU] <1987022509501900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brescia@CCV.BBN.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: tcp counters Message-ID: <8702252011.AA06273@ucbvax.Berkeley.EDU> Date: Wed, 25-Feb-87 14:50:19 EST Article-I.D.: ucbvax.8702252011.AA06273 Posted: Wed Feb 25 14:50:19 1987 Date-Received: Fri, 27-Feb-87 20:46:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 36 Approved: tcp-ip@sri-nic.arpa For each type of host implementation of IP/TCP/TELNET, where may the tcp error counters be found? I realize that some UNIX(tm) systems and derivatives provide a netstat command with a '-s' option that gives the following counters for the tcp level. tcp: 0 bad header checksums 0 bad header offset fields 0 incomplete headers The information I am looking for is a measure (either per-connection or over the whole operation of the tcp protocol layer) retransmissions - count of segments resent because ack was not returned in time redundant receives - count of segments received more than once estimated round trip time (per connection) - delay to destination retransmission time (or algorithm from est. RT time) route (on UNIX() can get this from netstat -r) - gateway or interface used when a connection is closed, the reason for closing For your implementation, are these sort of numbers available to me, a lowly user, and if not, can a wizard get them using some debugging magic? Implementations ::= { tops20, 4.*bsd, bbnos, ultrix 1.*, 2.*, vms(wolongong), many others? } I have taken a call from a user who is unable to reliably get from host A to host B, in that the connections hang for long periods of time, and frequently break (connection closed). While there are 3 different kinds of gateway in this particular path, I think the routing and traffic load are stable enough to support useful ftp and telnet service. I want to be able to have her call her host wizard to find out what is failing at the end points. mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987022509501901> Received: from CCV.BBN.COM by SRI-NIC.ARPA with TCP; Wed 25 Feb 87 12:01:29-PST To: tcp-ip@sri-nic.ARPA cc: brescia@ccv.bbn.com Subject: tcp counters Date: 25 Feb 87 14:50:19 EST (Wed) From: Mike Brescia For each type of host implementation of IP/TCP/TELNET, where may the tcp error counters be found? I realize that some UNIX(tm) systems and derivatives provide a netstat command with a '-s' option that gives the following counters for the tcp level. tcp: 0 bad header checksums 0 bad header offset fields 0 incomplete headers The information I am looking for is a measure (either per-connection or over the whole operation of the tcp protocol layer) retransmissions - count of segments resent because ack was not returned in time redundant receives - count of segments received more than once estimated round trip time (per connection) - delay to destination retransmission time (or algorithm from est. RT time) route (on UNIX() can get this from netstat -r) - gateway or interface used when a connection is closed, the reason for closing For your implementation, are these sort of numbers available to me, a lowly user, and if not, can a wizard get them using some debugging magic? Implementations ::= { tops20, 4.*bsd, bbnos, ultrix 1.*, 2.*, vms(wolongong), many others? } I have taken a call from a user who is unable to reliably get from host A to host B, in that the connections hang for long periods of time, and frequently break (connection closed). While there are 3 different kinds of gateway in this particular path, I think the routing and traffic load are stable enough to support useful ftp and telnet service. I want to be able to have her call her host wizard to find out what is failing at the end points. mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987022516160000> Received: from G.BBN.COM by SRI-NIC.ARPA with TCP; Wed 25 Feb 87 18:39:26-PST Date: 25 Feb 1987 21:16-EST Sender: CLYNN@G.BBN.COM Subject: Re: tcp counters From: CLYNN@G.BBN.COM To: brescia@CCV.BBN.COM Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[G.BBN.COM]25-Feb-87 21:16:16.CLYNN> In-Reply-To: The message of 25 Feb 87 14:50:19 EST (Wed) from Mike Brescia Mike, For TOPS-20 systems running the BBN network software, a "lowly user" should first try TSTAT; it doesn't give error counters, but may give insight about hung connections. If run a user runs it under the same job as the one owning the problem connection, give it JOB; otherwise just a to see all connection & find the one(s) of interest. By looking twice, one can see changes in sequence numbers, windows, and round trip time. @tstats TCB ID: > J/L JCN/Id Flg State Sequence Una Wndow RTT/MxS Un/Baud Net+Host Port 14. 4. R:O EST 21132187. 2465. 107. 0. F:128.89.0.87 0.23 78. S:OV EST 933691537. 0. 1932. 964. 34C L:192.1.2.67 131.135 5607674 0. 6. R:O EST 11965583. 2630. 404. 176. F:192.1.2.12 0.9 66 3236. S:OV EST 87128682. 0. 363. 536. 12C L:192.1.2.67 0.23 5624271 @ If that doesn't show what is happening, other per-connection information can be examined, by name, using either the .IPRIP function of the IPOPR% jsys, the .TCRTC function of the TCOPR% jsys, or the STAT% jsys (TSTATS uses the IPOPR% jsys). TCRPC # pkt received TCSPC # Pkt sent TCIGN # pkts ignored TCRXP # Pkt retransmitted TCDUP # duplicates recvd TCRZW # retransmitted into 0 window TCROS # out of sequence TCRST # RST received TSTO Send time out(ms) TCICM # ICMP msgs recvd TCABI aborted due to inactivity TCIDU # Dest unreachable TCABR aborted due to RX timeout TCIPB # Parameter problem TCERR TOPS20 error code TCIRD # Redirect msgs recvd TERR BBN error code TCISQ # Source Quench msgs recvd TCITE # Time exceeded A program which shows many of these (but which requires wheel capabilities for other reasons) is TCPEEK; it wants the ID and TCP connection block address (as listed by TSTATS): @tcpeek ~ TCB ID(10): 3236 MONITOR ADDR(8): 5624271 TCBID TJCN TOWNR TOFRK TFH TFP TLH TLP TSMRT TRXP TSTO 3236 6 0 6 #30000201014 #11 #30000201103 #27 404 #0 900000 TERR TSTAT TVTL #0 #2077164 #66 TRIS TRLFT TRLAK TRWND TRLWN TRURP TRBS 11965292 11965583 11965583 2630 11968213 11965292 0 TCRCV TCRPC TCDUP TCIGN TCROS TCRZW TCEWN TCPCC TCRST TCRPU TCRUR 0 526 0 0 0 0 0 0 0 0 0 TSIS TSLFT TSSEQ TSWND TSURP TSBYT TSCB TSCPK 87097344 87128682 87128682 363 87128377 0 #0 #0 TCSND TCSPC TCRXP TCRXF TCPZA TCFWN TCFWT TCSPU TCSUR 0 633 76 13 167 30 7314 625 3 TCICM TCISQ TCIRD TCFWP 0 0 0 0 TSMXS TCRTM TCATM TCLTM TCBTP TSPRB 536 43589016 44220791 47535287 47535287 44220791 TCSAG TCFAK TIFDF TTTL TTOS TABTF TCABI 0 0 0 60 #0 #0 0 ~ TCB ID(10): 78 MONITOR ADDR(8): 5607674 TCBID TJCN TOWNR TOFRK TFH TFP TLH TLP TSMRT TRXP TSTO 78 4 14 8 #20026200127 #27 #30000201103 #101607 107 #0 3600000 TERR TSTAT TVTL #0 #277164 #0 TRIS TRLFT TRLAK TRWND TRLWN TRURP TRBS 21128641 21132187 21132187 2465 21134652 21128641 472 TCRCV TCRPC TCDUP TCIGN TCROS TCRZW TCEWN TCPCC TCRST TCRPU TCRUR 158 709 495 0 0 0 0 0 0 156 0 TSIS TSLFT TSSEQ TSWND TSURP TSBYT TSCB TSCPK 933691392 933691537 933691537 1932 0 0 #0 #0 TCSND TCSPC TCRXP TCRXF TCPZA TCFWN TCFWT TCSPU TCSUR 113 697 1 0 101 1 187 113 0 TCICM TCISQ TCIRD TCFWP 0 0 0 3 TSMXS TCRTM TCATM TCLTM TCBTP TSPRB 964 2440011 2440011 47633921 47633921 2440011 TCSAG TCFAK TIFDF TTTL TTOS TABTF TCABI 0 0 0 60 #0 #0 0 e quitting... @ If that isn't enough, a packet trace might show what is happening. The easiest way for a "lowly user" to get one, if the TOPS20 is connected to an 1822 net, is to use the TCPU program. It creates a logical host and will pass (tcp) packets between two other hosts, recording them in the process. Instead of A telneting to B, tell TCPU to pass packets between A and B, then telnet from A to the logical host. Note that in this case, netiher A or B need be a TOPS20, but the route that the packets takes will be longer (through the 20 such as those at BBN), and there will be a little added delay (TCPU is a user-level program). [A wheel can get a packet trace of any/all pcakets through a 20 without a user's cooperation.] Charlie PS: See BBN Report 5925 for details and examples of the above. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702260331.AA12222%40uahcs1.UUCP] <1987022517314100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: streeter@1141g.UUCP.UUCP Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8702260331.AA12222@uahcs1.UUCP> Date: Wed, 25-Feb-87 22:31:41 EST Article-I.D.: uahcs1.8702260331.AA12222 Posted: Wed Feb 25 22:31:41 1987 Date-Received: Sat, 28-Feb-87 08:05:10 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 24 Approved: tcp-ip@sri-nic.arpa Date: 25 Feb 87 23:00:15 GMT To: ingr!uahcs1!scbhq!sb6!akgua!gatech!mod-protocols-tcp-ip Subject: Submission for mod-protocols-tcp-ip Responding-System: 1141g.UUCP Path: 1141g!streeter From: streeter@1141g.UUCP (Guy Streeter) Newsgroups: mod.protocols.tcp-ip Subject: internetwork routing Keywords: routing Message-ID: <170@1141g.UUCP> Date: 25 Feb 87 23:00:14 GMT Distribution: usa Organization: Society for the Happily Mediocre Lines: 8 Could someone point me to literature, specs, or source that would help me implement internetwork routers for TCP-IP? Is there a MIL-STD for this? thanks Guy Streeter akgua!ingr!1141g!streeter ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870225204427.011%40Hamlet.Caltech.Edu] <1987022518521500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: ken@HAMLET.CALTECH.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: a clarification Message-ID: <870225204427.011@Hamlet.Caltech.Edu> Date: Wed, 25-Feb-87 23:52:15 EST Article-I.D.: Hamlet.870225204427.011 Posted: Wed Feb 25 23:52:15 1987 Date-Received: Sat, 28-Feb-87 00:38:00 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Ken@Hamlet.Caltech.Edu (Kenneth Adelman) Distribution: world Organization: The ARPA Internet Lines: 33 Approved: tcp-ip@sri-nic.arpa >In article <8702242033.AA21637@ucbarpa.Berkeley.EDU> jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes) writes: >>(glad i put a '?' next to it ...) -- the sndmsg balks stuff is from >>Wollongong's VMS mailer ... Wollongong's SMTP server spawns a subprocess (called SNDMSG) to pass the message off to VMSmail. If the subprocess exits fatally, you get the `sndmsg balks' error. > Don't feel quite so bad, the software tools mailer is somewhat similar: > >After it receives the 'terminating' . it spawns off a subshell >which attempts to send the receive message header information to a mailer >daemon....if the send works (address is valid, header info complete, etc) then >it returns and the SMTP server responds with the OK message. If not, it sends >the appropriate error code (syntax error in address - see RFC 822, date missing >etc...). There IS a window where the remote mailer could time out, but to date >I have never seen this actually happen - remember, it is NOT trying to deliver >the message, just verify the headers and queue it for delivery..... Correction. The Software Tools SMTP receiver does not spawn a subshell and does all of the verification as the headers come in. It then queues the message to the mailer daemon which does little more than expand aliases and copy the file into the delivery queue directory before returning a success status to the SMTP receiver, which is then free to return a response to the SMTP partner. Any delay seen between . and the response code is due to the time it takes the mailer daemon to copy the file into the queue. If this is not done syncronously then a machine failure might cause lost mail. I'd rather get two than none. Kenneth Adelman Caltech ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702260000.aa06810%40CAD.USNA.ARPA] <1987022519005400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: tcs@USNA.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Domain host TTL fields Message-ID: <8702260000.aa06810@CAD.USNA.ARPA> Date: Thu, 26-Feb-87 00:00:54 EST Article-I.D.: CAD.8702260000.aa06810 Posted: Thu Feb 26 00:00:54 1987 Date-Received: Sat, 28-Feb-87 00:38:14 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 22 Approved: tcp-ip@sri-nic.arpa Something that I've not seen discussed on this list is the optimum TTL values for host entries, etc in the domain database. Anyone have any numbers on the amount of traffic this stuff generates and the affect this number has on network traffic? For most large hosts, a minimum of 24 hours seems reasonable and 7 days would not be out of line. Small workstations that move around a lot could have smaller values. Some hosts have a TTL value of 4 hours. Is this really necessary? Administrators of zones should be able to identify major hosts which don't change very often and increase the TTL accordingly. The value could be reduced to a few hours prior to a change. Also, what should be a good value for the nameserver timeout in waiting for a reply. I've found that we typically time out two or three times before receiving a reply. This means that several extraneous packets are injected into the network each time we attempt to resolve an address. Am I'm missing some issues regarding these values? -tcs Terry Slattery U.S. Naval Academy 301-267-4413 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702261157.AA22918%40ucbvax.Berkeley.EDU] <1987022600304000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@BARILVM.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Excelan VMS and microMVS Message-ID: <8702261157.AA22918@ucbvax.Berkeley.EDU> Date: Thu, 26-Feb-87 05:30:40 EST Article-I.D.: ucbvax.8702261157.AA22918 Posted: Thu Feb 26 05:30:40 1987 Date-Received: Sat, 28-Feb-87 04:36:01 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Henry Nussbacher Distribution: world Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Can anyone comment on the Excelan VMS and MicroVMS implementations? Good? Bad? Plz reply directly to me so as not to flood the list with too much unnecessary comments. Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702261411.AA24689%40ucbvax.Berkeley.EDU] <1987022604002800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: HANK@BARILVM.BITNET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: MICOM-Interlan Message-ID: <8702261411.AA24689@ucbvax.Berkeley.EDU> Date: Thu, 26-Feb-87 09:00:28 EST Article-I.D.: ucbvax.8702261411.AA24689 Posted: Thu Feb 26 09:00:28 1987 Date-Received: Sat, 28-Feb-87 03:33:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Henry Nussbacher Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa For that matter can anyone comment on the MICOM-Interlan Tcp/Ip implementation for VMS and microVMS? Good Bad? Once again, reply directly to me. Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702261558.AA03891%40violet.ISC.COM] <1987022605583500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dougm%ico.ISC.COM%ncar.CSNET@RELAY.CS.NET.UUCP Newsgroups: mod.protocols.tcp-ip Subject: AT&T RFS over TCP Message-ID: <8702261558.AA03891@violet.ISC.COM> Date: Thu, 26-Feb-87 10:58:35 EST Article-I.D.: violet.8702261558.AA03891 Posted: Thu Feb 26 10:58:35 1987 Date-Received: Sun, 1-Mar-87 10:47:00 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 7 Approved: tcp-ip@sri-nic.arpa We're in the process of bringing RFS up over TCP and were wondering if there was a specific TCP port being used by other people working on the same thing. Thanks, Doug McCallum dougm@ico.ISC.COM ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702261813.AA27443%40saturn.dec.com] <1987022608395500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: kent@DECWRL.DEC.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Delta-T Paper Message-ID: <8702261813.AA27443@saturn.dec.com> Date: Thu, 26-Feb-87 13:39:55 EST Article-I.D.: saturn.8702261813.AA27443 Posted: Thu Feb 26 13:39:55 1987 Date-Received: Sat, 28-Feb-87 03:11:03 EST References: <8702251945.AA01525@braden.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Christopher A. Kent" Distribution: world Organization: The ARPA Internet Lines: 40 Approved: tcp-ip@sri-nic.arpa Here are the references in my bibliography: @Article(Fletcher:Delta-t, Author="John G. Fletcher and Richard W. Watson", Title="Mechanisms for a Reliable Timer-Based Protocol", Journal="Computer Networks", Volume="2", Year=1978, Pages="271-290", Note="Introduces the Delta-T concept" ) @TechReport(Watson:Delta-tProt, Author="Richard W. Watson", Title="Delta-t Protocol Specification", Type="UCID", Number="19293", Institution="Lawrence Livermore National Laboratory", Month="April 15", Year=1983 ) @TechReport(Watson:deltaGram, Author="Richard W. Watson", Title="DeltaGram Protocol Specification", Type="UCID", Number="19295", Institution="Lawrence Livermore National Laboratory", Month="August 3", Year=1982 ) These are all part of the LINCS (Livermore Interactive Network Communication System) document series, most of which are LLL tech reports. I last investigated Delta-T in 1983, so my copy of the bibliography may be out of date. chris ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702262115.AA02105%40ucbvax.Berkeley.EDU] <1987022609040200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jb@cs.brown.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Domain host TTL fields Message-ID: <8702262115.AA02105@ucbvax.Berkeley.EDU> Date: Thu, 26-Feb-87 14:04:02 EST Article-I.D.: ucbvax.8702262115.AA02105 Posted: Thu Feb 26 14:04:02 1987 Date-Received: Sat, 28-Feb-87 02:54:55 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 54 Approved: tcp-ip@sri-nic.arpa Over time, my idea of what the optimum time should be has been increasing. In general, I feel that 24 hours is about the correct value. One major issue is how long various other software will wait for a change. Sendmail will attempt to deliver a message for 3 days (as distributed). One would like to have any changes seen in less than 3 days. There are a couple reasons for data to change. First, a planned change to the network configuration. This can be planned for in advance by reducing the TTL. Don't forget that the reduction must be made at a time longer than the TTL in advance. Consider how long in advance you would be planning a move. Another reason for a change is due to an unanticipated failure. If one of your primary machines (such as a mail forwarder) goes down for a few days, attempts to bypass the failure require the length of the TTL to be fully realized. Coming from Berkeley and being involved with some of the early distributions of BIND, I'll admit we made a mistake in what we had in the sample files. Many people just copied our samples and did not analyze the situation. Our samples should have had TTL's that were longer than 1 hour. We did not realize this originally ourselves and were guilty of using too short of a TTL for a long time. These problems take time to work out. As far as the question of what should be used as the timeout waiting for a reply, I'm not sure of what is the correct answer. There are 3 timeouts to consider in this case. First, total time to wait for any response before indicating a failure. Second, the time between trying different servers for the domain. And third, the time between tries to the same server. The first of these is a user interface question on one hand, and a performance issue on the other. How long should a user who tries to telnet to some host have to wait before being told that the host is unknown (possibly only temporarily)? I don't like to wait a long time, but on the other hand, the longer the wait the more likely to succeed. BIND is currently using about one minute for this. The other two are intertwined and also are a part of the first one. UDP which is used primarily for queries is not reliable. If one knows that the original packet was lost, then a retry to one of the servers is in order. If the delay is in network round trip time (RTT), then the time between the retries should be lengthened. To decide what these times should be, several questions to be answered. How long should the user wait for a response? How many queries total should be sent out in trying to resolve the name? How many queries should be made to each server for the domain? What should the retry algorithm be (linear, exponential, something else)? If recursion is being done by another process, how does that affect these values? I'm not sure what is being used in BIND at the moment. It actually uses two different algorithms. One for talking to the local server, and another for dealing with recursion. Some work on the algorithms has been done for the most recent release and I haven't had a chance to look at the code. Jim Bloom ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987022609040201> Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Thu 26 Feb 87 13:01:15-PST Received: from relay2.cs.net by RELAY.CS.NET id ac05699; 26 Feb 87 14:48 EST Received: from cs.brown.edu by RELAY.CS.NET id af19947; 26 Feb 87 14:43 EST Received: by cs.brown.edu (5.51/1.00) id AA19480; Thu, 26 Feb 87 14:02:29 EST From: Jim Bloom To: tcs@USNA.ARPA Subject: Re: Domain host TTL fields Cc: tcp-ip@SRI-NIC.ARPA Date: Thu, 26 Feb 87 14:04:02 EST Over time, my idea of what the optimum time should be has been increasing. In general, I feel that 24 hours is about the correct value. One major issue is how long various other software will wait for a change. Sendmail will attempt to deliver a message for 3 days (as distributed). One would like to have any changes seen in less than 3 days. There are a couple reasons for data to change. First, a planned change to the network configuration. This can be planned for in advance by reducing the TTL. Don't forget that the reduction must be made at a time longer than the TTL in advance. Consider how long in advance you would be planning a move. Another reason for a change is due to an unanticipated failure. If one of your primary machines (such as a mail forwarder) goes down for a few days, attempts to bypass the failure require the length of the TTL to be fully realized. Coming from Berkeley and being involved with some of the early distributions of BIND, I'll admit we made a mistake in what we had in the sample files. Many people just copied our samples and did not analyze the situation. Our samples should have had TTL's that were longer than 1 hour. We did not realize this originally ourselves and were guilty of using too short of a TTL for a long time. These problems take time to work out. As far as the question of what should be used as the timeout waiting for a reply, I'm not sure of what is the correct answer. There are 3 timeouts to consider in this case. First, total time to wait for any response before indicating a failure. Second, the time between trying different servers for the domain. And third, the time between tries to the same server. The first of these is a user interface question on one hand, and a performance issue on the other. How long should a user who tries to telnet to some host have to wait before being told that the host is unknown (possibly only temporarily)? I don't like to wait a long time, but on the other hand, the longer the wait the more likely to succeed. BIND is currently using about one minute for this. The other two are intertwined and also are a part of the first one. UDP which is used primarily for queries is not reliable. If one knows that the original packet was lost, then a retry to one of the servers is in order. If the delay is in network round trip time (RTT), then the time between the retries should be lengthened. To decide what these times should be, several questions to be answered. How long should the user wait for a response? How many queries total should be sent out in trying to resolve the name? How many queries should be made to each server for the domain? What should the retry algorithm be (linear, exponential, something else)? If recursion is being done by another process, how does that affect these values? I'm not sure what is being used in BIND at the moment. It actually uses two different algorithms. One for talking to the local server, and another for dealing with recursion. Some work on the algorithms has been done for the most recent release and I haven't had a chance to look at the code. Jim Bloom ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702262103.AA12703%40ACC-SB-UNIX.ARPA] <1987022611033700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: cam@ACC-SB-UNIX.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: (none) Message-ID: <8702262103.AA12703@ACC-SB-UNIX.ARPA> Date: Thu, 26-Feb-87 16:03:37 EST Article-I.D.: ACC-SB-U.8702262103.AA12703 Posted: Thu Feb 26 16:03:37 1987 Date-Received: Sat, 28-Feb-87 02:57:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 6 Approved: tcp-ip@sri-nic.arpa Folks, Does anyone know if someone has ported tn3270 to run on VMS with Wollongong's TCP/IP? Or if someone is working on it? Chris Markle (cam@acc-sb-unix or 301-290-8100) ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702262320.AA04321%40sdcsvax.UCSD.EDU] <1987022613201000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: brian@sdcsvax.ucsd.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8702262320.AA04321@sdcsvax.UCSD.EDU> Date: Thu, 26-Feb-87 18:20:10 EST Article-I.D.: sdcsvax.8702262320.AA04321 Posted: Thu Feb 26 18:20:10 1987 Date-Received: Sat, 28-Feb-87 08:03:51 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 83 Approved: tcp-ip@sri-nic.arpa Path: sdcsvax!brian From: brian@sdcsvax.UCSD.EDU (Brian Kantor) Newsgroups: mod.protocols.tcp-ip Subject: Re: duplicate message in SMTP ("sndmsg balks, try again later") Message-ID: <2766@sdcsvax.UCSD.EDU> Date: 26 Feb 87 23:20:09 GMT References: <8702241936.AA19824@ucbarpa.Berkeley.EDU> Reply-To: brian@sdcsvax.UCSD.EDU (Brian Kantor) Distribution: world Organization: UCSD wombat breeding society Lines: 71 This is a message I sent a few weeks ago to someone locally who was seeing this problem. Some of the information in here is therefore UCSD-specific, but you'll get the idea.... ----- More than you ever wanted to know about VMS SMTP mail: Brief description of problem: mail addressed to many recipients on a VMS machine has been received as multiple duplicates by some of the recipients. What's going on: When mail is sent over an SMTP connection such as is used on the ethernet, a RCPT TO:
line is sent for each individual recipient to be delivered to on that connection (i.e., on that host). The receiving mailer (in this case, the Wollongong VMS mail package) is responsible for validating and delivering the mail to those recipients. It has been previously noticed that one somewhat common VMS practice can cause difficulties with mail: that of removing the home directory of a user who is still in the VMS User Authorisation File. (Apparently this prevents logins whilst still maintaining accounting information in the UAF. Or something; I'm not a VMS guru by a long shot.) The Wollongong mail system apparently checks the validity of a mail delivery address (the RCPT TO: line) during the SMTP transaction by checking the UAF. If a user is still in that file, it OK's the destination mailbox and continues. If the user is NOT in the UAF, a reject message is instead returned, and the mail will be returned to the sender as having one or more "recipient unknown" problems. After the list of recipients is negotiated, the mail message itself is sent. At the end of this DATA portion of the SMTP connection, the Wollongong VMS software invokes the VMS mailer to deliver the actual mail. The SMTP connection is still open to the originating mailer (in this case, sdcsvax's sendmail daemon), and will remain that way until OK and QUIT transactions take place. Ordinarily, the Wollongong software delivers the mail to the user's mailbox file, and returns an OK to the sender, who in turn QUITS the connection, and all is well. However, if the recipients's home directory on the VMS system is missing, the delivery fails, and an error code is returned. Sendmail then assumes that the mail wasn't delivered, since it never got the OK, and requeues the message for delivery on the next queue run (about 20 minutes later under our circumstances), and the whole process repeats until either the mail is successfully delivered to all validated recipients, or until the message times out after 3 days (or someone goes in and snuffs it). Where this is a real pain is when you have a long list of recipients and somewhere in the middle of it (or worse, near the end!) there is one whose mailbox isn't available for delivery - if, for instance, his home directory is missing. Then what happens is that all the recipients PREVIOUS to him have gotten the mail message delivered to them, but sendmail gets an error back from the Wollongong VMS mailer, and requeues the message to ALL the recipients again, so they'll get another copy 20 minutes later. There isn't any cure for this, except for Wollongong to make their software smarter. There's no provision in the SMTP specification to allow the mail transport mechanism to accept a recipient in the earlier part of the transaction, and later selectively reject it. Obviously one should not send messages to people who aren't there anymore, but sometimes it is difficult to tell which are valid addresses when doing massive bulk mailings. Neither is it particularly intelligent to return an error message to sendmail that applies to only one recipient when the message isn't totally lost. I guess sendmail is at fault here too. Maybe its the SMTP specification that's losing. Brian Kantor UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 USA ----MESSAGE-END---- ----MESSAGE-BEGIN---- [571338780.108130550%40XV.MIT.EDU] <1987022613260000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: Kevin_Crowston@XV.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: When to acknowledge SMTP messages Message-ID: <571338780.108130550@XV.MIT.EDU> Date: Thu, 26-Feb-87 18:26:00 EST Article-I.D.: XV.571338780.108130550 Posted: Thu Feb 26 18:26:00 1987 Date-Received: Sat, 28-Feb-87 02:54:37 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa Message type: Message Topic: SMTP Text: Re: Message of 25 Feb 87 05:01 from MRC%PANDA@SUMEX-AIM.Stanford.EDU > The server should NOT make the client wait while a message is > being delivered... I faced this issue when implementing our mail relay. I decided that the client SMTP would have to wait while the relay delivered the message. Otherwise, the relay could acknowledge the message and then crash or discover that the destination mail server was unable to take the message. Either way, the mail goes on the floor, hardly desirable. Acknowledgement should mean that the message is really okay. On the other hand, I also get multiple copies of a lot of whole and partial messages; it seems that some hosts are less patient than others... Kevin Crowston MIT Sloan School of Management ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12282235123.9.MRC%40PANDA] <1987022614123500> 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: When to acknowledge SMTP messages Message-ID: <12282235123.9.MRC@PANDA> Date: Thu, 26-Feb-87 19:12:35 EST Article-I.D.: PANDA.12282235123.9.MRC Posted: Thu Feb 26 19:12:35 1987 Date-Received: Sat, 28-Feb-87 06:27:04 EST References: <571338780.108130550@XV.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 20 Approved: tcp-ip@sri-nic.arpa Kevin Crowston - Your relay should queue the message on its local disk and acknowledge it once it is safely written. That protects against the system crash problem. If the message cannot be accepted by the other end, then the message should be returned to the sender via the return-path address. An SMTP server should NEVER block a client waiting for delivery. It is STUPID and WRONG-HEADED to keep an SMTP connection open for ANY period of time longer than is necessary to get the bits across and acknowledged. The world isn't necessarily the Internet with no charges per packet or time charges for a virtual circuit. When time charges are a reality, mail servers that block clients COST REAL MONEY. Sorry for flaming, but this really is an important concept. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702270038.AA00078%40apolling.imagen.uucp] <1987022614384100> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: geof@decwrl.DEC.COM@imagen.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: When to acknowledge SMTP messages Message-ID: <8702270038.AA00078@apolling.imagen.uucp> Date: Thu, 26-Feb-87 19:38:41 EST Article-I.D.: apolling.8702270038.AA00078 Posted: Thu Feb 26 19:38:41 1987 Date-Received: Sat, 28-Feb-87 06:15:48 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: imagen!geof@decwrl.DEC.COM Distribution: world Organization: The ARPA Internet Lines: 99 Approved: tcp-ip@sri-nic.arpa > > The server should NOT make the client wait while a message is > > being delivered... > > I faced this issue when implementing our mail relay. I decided that the > client SMTP would have to wait while the relay delivered the message. > Otherwise, the relay could acknowledge the message and then crash > or discover that the destination mail server was unable to take the message. > Either way, the mail goes on the floor, hardly desirable. Acknowledgement > should mean that the message is really okay. I agree whole-heartedly. The problem is with SMTP itself. TCP mandates that it is the client's responsibility to ensure that the remote client is up. In other words, TCP won't probe an idle connection (the old "keep-alive" discussion), so the higher level protocol must do so if it cares. This behavior on TCP's part is necessary to cope with potentially expensive network paths (e.g., a PTT network that bills by the packet), so that quiescent TCP connections do not run up big bills. If you're out of the office for lunch, you don't want your telnet connection to send packets around uselessly for an hour or more. As in most cases, it doesn't matter much when you're on an Ethernet, but it does in the more general case. In the case of SMTP, when a message is terminated with a ".CRLF", no SMTP data may flow except the server's success/fail response. Since the TCP connection is quiescent during this interval, TCP cannot detect a remote crash. The only reasonable thing to do is to have SMTP set its own death timer when it sends ".CRLF" and hope the message can be delivered during that time interval. The trouble is that there is no way to judge how long the SMTP death timer should be. Some machines deliver mail fast, others not so fast (mine is just plain slow). No matter what value you set for the death timer, you lose some of the time. And the way you lose is that mail to one type of host is always lousy. The ultimate answer would be to fix SMTP, so that the server could still respond with "OK, I'm still here" messages while it was delivering the mail. Given all the SMTP hosts out there, this is probably not going to happen. Ad hoc solutions include: 1. Have the server respond before the message is sent (bad, since messages can get dropped on the floor). 2. Adjust the timeouts to try and accomodate every host you would reasonably connect to => every TCP implementation. This is what we do now, and it doesn't work all the time. 3. Find some random data for the message sender to periodically queue. This would have the effect of taking the TCP connection out of its quiescent state, so that the TCP layer can detect a machine crash for you. This works unless the problem is that the remote SMTP server is in a tight loop, with the remote TCP still healthy (that's a "software bug"-type situation that can be detected and fixed). I favor [3]. Try this: When you send ".CRLF": set timer for how long you expect this to take (T) set timer for how long you are willing to hang (D >> T) set noops=0 wait for input from server On TIMER T: send NOOP command to server noops = noops + 1 set timer to T go back to waiting for input from server On INPUT: process success/fail message from SMTP SEND command while noops > 0 do read & discard command from server noops = noops - 1 end On TIMER D: assume failure of message. The idea is that by sending NOOP commands, the TCP layer will probe the underlying connection for you. Thus, the ultimate timer, D, can be VERY long, since it detects bugs in the remote SMTP, not random events. The annoyance is that you have to ignore enough responses to match each noop you sent (I guess the other annoyance is that it is a miserable hack that should be shot at sunrise...). An obvious enhancement is to query the local TCP before sending a NOOP -- it is not necessary to send anything unless the local TCP is quiescent. This is extremeley useful in the situation where the SMTP connection is dribbling along at 1200 baud somewhere and the REAL problem is that the message hasn't been TRANSMITTED yet. The timer T should be long enough to give the other machine a running shot at delivering the message in that time (say 1-5 minutes). - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702270047.AA17154%40ucbarpa.Berkeley.EDU] <1987022614470200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jordan@UCBARPA.BERKELEY.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: When to acknowledge SMTP messages Message-ID: <8702270047.AA17154@ucbarpa.Berkeley.EDU> Date: Thu, 26-Feb-87 19:47:02 EST Article-I.D.: ucbarpa.8702270047.AA17154 Posted: Thu Feb 26 19:47:02 1987 Date-Received: Sat, 28-Feb-87 06:14:45 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: Experimental Computer Facility (XCF), UC Berkeley Lines: 18 Approved: tcp-ip@sri-nic.arpa Kevin Crowston writes: I decided that the client SMTP would have to wait while the relay delivered the message. Otherwise, the relay could acknowledge the message and then crash or discover that the destination mail server was unable to take the message. Sendmail seems to handle this correctly, since "delivered" to that part of the code means "placed in the queue" (i.e., wrote it to disk ... if the machine then crashes, the daemon will pick up where it left off since the queue file is still there) -- you can't acknowlege the message as being sent before you have firm control of it. That's what lock-step is all about. Once you have done that, if you find later that you can't deliver it, it's up to the recipient SMTP process to send it back to where it came from. This can be handled asynchronously. /jordan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987022616004000> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 26 Feb 87 03:47:25-PST Received: from BARILVM.BITNET by wiscvm.wisc.edu on 02/26/87 at 05:46:16 CST Received: by BARILVM (Mailer X1.23b) id 8692; Thu, 26 Feb 87 12:32:19 O Date: Thu, 26 Feb 87 12:30:40 O From: Henry Nussbacher Subject: Excelan VMS and microMVS To: tcp-ip@sri-nic.ARPA Reply-To: Henry Nussbacher Can anyone comment on the Excelan VMS and MicroVMS implementations? Good? Bad? Plz reply directly to me so as not to flood the list with too much unnecessary comments. Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12282262745.14.SY.KEN%40CU20B.COLUMBIA.EDU] <1987022616441900> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: sy.Ken@CU20B.COLUMBIA.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: When to acknowledge SMTP messages Message-ID: <12282262745.14.SY.KEN@CU20B.COLUMBIA.EDU> Date: Thu, 26-Feb-87 21:44:19 EST Article-I.D.: CU20B.12282262745.14.SY.KEN Posted: Thu Feb 26 21:44:19 1987 Date-Received: Sat, 28-Feb-87 07:03:54 EST References: <571338780.108130550@XV.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 27 Approved: tcp-ip@sri-nic.arpa > The server should NOT make the client wait while a message is > being delivered... I faced this issue when implementing our mail relay. I decided that the client SMTP would have to wait while the relay delivered the message... I think the furthest the acknowledgement process should go is essentially "message received by this host and queued for delivery locally". In so many cases, there's often too much processing involved in delivering to the final destination mailbox that the sending system should NOT have to wait for all of this to go on. I see the cases of local mailbox delivery and mail forwarding as the same. For example, host A wants to send to host C, not on host A's network. It must therefore forward through host B. Should host A have to wait while host B tries to forward the mail through all the way to host C? This case is clearly unreasonable. The local delivery process can often be just as unreasonable for a variety of reasons, and thus, the mail should be stuffed into some local delivery queue (which would presumably be a fast process), and actual local delivery can then happen asynchronously with the SMTP dialog. If there is some fatal case where the mail cannot actually be delivered after being queued on the target system for local delivery, then the entire message can be returned to the sender by the mailer. This is how the TOPS-20 mailer works, and it seems like a fairly airtight procedure in practice as well as in theory. /Ken ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702270413.AA00250%40bel.isi.edu] <1987022618133400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: postel@bel.isi.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: GOSIP Message-ID: <8702270413.AA00250@bel.isi.edu> Date: Thu, 26-Feb-87 23:13:34 EST Article-I.D.: bel.8702270413.AA00250 Posted: Thu Feb 26 23:13:34 1987 Date-Received: Sat, 28-Feb-87 08:08:17 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 36 Approved: tcp-ip@sri-nic.arpa Hello: There was a message to this list a month ago about the GOSIP report, the Government Open Systems Interconnection Procurement Specification. It turns out that this is a matter that deserves our serious attention. In general it is a well intention effort to come up with a plan to get the US Government to acquire computer communication protocols that will interoperate so that computers that need to exchange information can do so. Unfortunately, there are some aspects of the plan where good intentions run ahead (on thin ice) of practical reality. It is important that the authors of the plan hear comments on it soon, in the next two weeks! The authors i know of are in the CC field of this message. The report has been coordinated with a large set of government staff represeneting a large number of government agencies (many that have nothing to do with computing research and development, but that do use computers). Please do not assume that this plan is someting that NBS and DOD cooked up to do in IP/TCP. In fact, the DOD people involved are perhaps the most knowledgeable and reasonable. A major problem is that for most of the other representatives, what they know about protocols (if anything) is what they read in Computerworld or Datamation. So please find out more about the GOSIP report, and send comments to the authors. The activity is coordinated by the NBS so offline comments should be sent to: GOSIP Institute for Computer Sciences and Technology National Bureau of Standards Gaithersburg, Maryland 20899 --jon. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1987022619302800> Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 26 Feb 87 06:02:47-PST Received: from BARILVM.BITNET by wiscvm.wisc.edu on 02/26/87 at 08:01:46 CST Received: by BARILVM (Mailer X1.23b) id 8863; Thu, 26 Feb 87 16:01:30 O Date: Thu, 26 Feb 87 16:00:28 O From: Henry Nussbacher Subject: MICOM-Interlan To: tcp-ip@sri-nic.ARPA Reply-To: Henry Nussbacher For that matter can anyone comment on the MICOM-Interlan Tcp/Ip implementation for VMS and microVMS? Good Bad? Once again, reply directly to me. Thanks, Hank ----MESSAGE-END---- ----MESSAGE-BEGIN---- [26389.541414281%40nrtc-gremlin.arpa] <1987022622582800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mrose@nrtc-gremlin.arpa.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: When to acknowledge SMTP messages Message-ID: <26389.541414281@nrtc-gremlin.arpa> Date: Fri, 27-Feb-87 03:58:28 EST Article-I.D.: nrtc-gre.26389.541414281 Posted: Fri Feb 27 03:58:28 1987 Date-Received: Sat, 28-Feb-87 08:05:55 EST References: <8702270038.AA00078@apolling.imagen.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 18 Approved: tcp-ip@sri-nic.arpa Hack. Hack. Hack. Two things: 1. As Jordan pointed out: as soon as the SMTP server queues the message for delivery (not actually delivers it), the server should send the success acknowledgement to the client. Even if your host is single-threaded, the server can always deliver the mail *after* the SMTP connection is closed. 2. Why hack SMTP? I can find similar faults with interactions in FTP. And in just about any command/response application that you can run on top of TCP. The correct solution is to add an *option* to TCP saying to use keep-alives. Things like SMTP could use it, things like telnet (where a failure is obvious to any interactive user) don't have to use it. With this solution, you only have to make a very small change to the way an application opens the network, instead of complicating the peer-to-peer protocol used by the application. Keep it simple guys! /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12282332121.6.MRC%40PANDA] <1987022623052500> 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: When to acknowledge SMTP messages Message-ID: <12282332121.6.MRC@PANDA> Date: Fri, 27-Feb-87 04:05:25 EST Article-I.D.: PANDA.12282332121.6.MRC Posted: Fri Feb 27 04:05:25 1987 Date-Received: Sat, 28-Feb-87 07:43:49 EST References: <8702270038.AA00078@apolling.imagen.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa A much better approach is for the SMTP server to queue the message on its local disk and acknowledge immediately. The delivery can be done by an asynchronous process. Unless your system is in real bad shape, it shouldn't take any time at all to write a file on the disk. It is much better to cure the disease (SMTP servers taking an indeterminate amount of time to respond) than it is to mask the symptoms. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702271322.AA25034%40beno.CSS.GOV] <1987022703222200> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: mo@seismo.CSS.GOV.UUCP Newsgroups: mod.protocols.tcp-ip Subject: STMP and waiting for Godot Message-ID: <8702271322.AA25034@beno.CSS.GOV> Date: Fri, 27-Feb-87 08:22:22 EST Article-I.D.: beno.8702271322.AA25034 Posted: Fri Feb 27 08:22:22 1987 Date-Received: Sun, 1-Mar-87 10:33:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 39 Approved: tcp-ip@sri-nic.arpa All this discussion about when and why one does what one does with SMTP leads me to reiterate a viewpoint discussed long ago during the 822 MailWarz. In my humble opinion, if a mail system isn't reliable, it isn't a mail system. This applies to local mail, SMTP, UUCP, X.400, BITNET, or whatever. (I think I offended everyone!) So... An extremely important notion in the design of mail systems is the "transfer of responsibility" for a message. In my view of the world, when one mail agent acknowledges a transfer to another, the acknowledging againt isn't required to specify exactly what that means over and above the fact that the new agent in charge of the message is obligated to either (1) deliver the message to the recipient, (2) reliably transfer responsibility to another mail agent or (3) start returning the message to the originator, along with an explanation as two why (1) or (2) wasn't possible. I say "start returning", because the returned mail is in fact contained in a new message, originated by the mail agent, and is handled as any other message - ie, mail agents handing off responsibility for a message until it is delivered to the recipient (whatever that means). So, as Mark Crispin points out, to concienciously accept responsibility, an agent must have committed the message to some (fairly) robust storage before acknowledging it, lest it be lost in a crash. Whatever else must be done with the message to accomplish (1), (2), or regretably (3) can be done after the copy is firmly in hand (disk) and the transfer of responsibility has happened. I think this model of transferring responsibility (and only implicitly the message) is more useful because when one transfers only messages, it isn't clear who is liable for what in what circumstances. If one is transferring responsibility for safe conduct of an object, it becomes much clearer what one's alternatives actually are. Further, I think this has interesting impacts on protocol design. Anyway... I hope this sheds some light on things, -Mike O'Dell ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702271656.AA02697%40braden.isi.edu] <1987022706565300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: braden@ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Specs on IP Routers Message-ID: <8702271656.AA02697@braden.isi.edu> Date: Fri, 27-Feb-87 11:56:53 EST Article-I.D.: braden.8702271656.AA02697 Posted: Fri Feb 27 11:56:53 1987 Date-Received: Sun, 1-Mar-87 12:13:27 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa There is an initial draft of a spec on Internet gateways, or as you call them, routers; it is RFC985. We are actively working on a revised and extended version of this spec; stay tuned! Bob Braden ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702271700.AA14569%40urania.Think.COM] <1987022707004400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: bruce@THINK.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: HDH <-> X.25 Message-ID: <8702271700.AA14569@urania.Think.COM> Date: Fri, 27-Feb-87 12:00:44 EST Article-I.D.: urania.8702271700.AA14569 Posted: Fri Feb 27 12:00:44 1987 Date-Received: Sun, 1-Mar-87 10:26:53 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa The HDH/X.25 problem I asked about several days ago has been fixed, on the ARPANET at least. The PSNs were sending larger-than-legal frames to the packet mode HDH interface, causing it to hang. There was a PSN patch for this problem which was known about several months ago, but for some reason was not installed arpanet-wide until this morning. Thanks to those who helped with this. --bruce ----MESSAGE-END---- ----MESSAGE-BEGIN---- [12282419301.20.AI.CLIVE%40MCC.COM] <1987022707041800> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: AI.CLIVE@MCC.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Another aspect of SMTP timeouts Message-ID: <12282419301.20.AI.CLIVE@MCC.COM> Date: Fri, 27-Feb-87 12:04:18 EST Article-I.D.: MCC.12282419301.20.AI.CLIVE Posted: Fri Feb 27 12:04:18 1987 Date-Received: Sun, 1-Mar-87 10:28:59 EST References: <8702270038.AA00078@apolling.imagen.uucp> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 31 Approved: tcp-ip@sri-nic.arpa The large number of recent messages about SMTP clients waiting for servers don't seem to have mentioned a related problem which is just as annoying: How long should an SMTP server process wait for a client before giving up? For many weeks our system constantly had two or three active server processes connected to a certain host. Investigation showed that the client host would stop sending data after the MAIL FROM: command, and our SMTP server would give up and close the connection 5 minutes later. A minute or two later, the client host would open another connection and try again, etc. etc. I finally had to increase the server timeout to FIFTEEN minutes, and the client was finally able to get the message through. People have suggested several reasons why a server might be delayed in responding to a client; but I see no excuse for a client to be so slow about it. The host in question was an overloaded 750 running Unix. I don't know many more details, but I'm told that the Unix mailer actually validates each address in the header after the connection is already open, and that furthermore this validation is repeated during each connection to the various hosts for which the message is destined. If a message has a couple of dozen addressees, this adds up to quite a bit of time. This sounds unbelievable to me, and I hope that Unix folks take the time to tell me that my info is wrong, or that the situation will soon be fixed. Mailers should get all of their validation, etc., done BEFORE opening any connection. Once the connection is open they should state their business quickly, expect a quick response, and then leave. A network connection is a valuable resource, and my system can't afford to tie up several in an idle state waiting for remote hosts to spin their wheels. Clive ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702271841.AA15482%40hermes.ai.mit.edu] <1987022708413400> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: dms@HERMES.AI.MIT.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: When to acknowledge SMTP messages Message-ID: <8702271841.AA15482@hermes.ai.mit.edu> Date: Fri, 27-Feb-87 13:41:34 EST Article-I.D.: hermes.8702271841.AA15482 Posted: Fri Feb 27 13:41:34 1987 Date-Received: Sun, 1-Mar-87 11:09:40 EST References: <8702270047.AA17154@ucbarpa.Berkeley.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 33 Approved: tcp-ip@sri-nic.arpa Date: Thu, 26 Feb 87 16:47:02 PST From: jordan@ucbarpa.berkeley.edu (Jordan Hayes) Organization: Experimental Computer Facility (XCF), UC Berkeley Kevin Crowston writes: I decided that the client SMTP would have to wait while the relay delivered the message. Otherwise, the relay could acknowledge the message and then crash or discover that the destination mail server was unable to take the message. Sendmail seems to handle this correctly, since "delivered" to that part of the code means "placed in the queue" (i.e., wrote it to disk ... if the machine then crashes, the daemon will pick up where it left off since the queue file is still there) -- you can't acknowlege the message as being sent before you have firm control of it. That's what lock-step is all about. Once you have done that, if you find later that you can't deliver it, it's up to the recipient SMTP process to send it back to where it came from. This can be handled asynchronously. /jordan Actually, sendmail doesn't handle this completely correctly. Before sendmail queue's up a message, and gives the acknowledgment back to the sender, it attempts to expand every address in a mailing list. This expansion can take a long time, since it means a call to the resolver to qualify host names. So, messages sent to large mailing lists take a long time to get queued up. What sendmail should be doing is writing out a very simple queue file with the un-expanded receipients. The background delivery process should do the expansion the first time it comes across an un-expanded address. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702271852.AA10758%40BOEING.COM] <1987022708521700> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: randy@june.cs.washington.edu@bcsaic.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8702271852.AA10758@BOEING.COM> Date: Fri, 27-Feb-87 13:52:17 EST Article-I.D.: BOEING.8702271852.AA10758 Posted: Fri Feb 27 13:52:17 1987 Date-Received: Sun, 1-Mar-87 11:28:46 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 27 Approved: tcp-ip@sri-nic.arpa Path: bcsaic!randy From: randy@bcsaic.UUCP (Randy Groves) Newsgroups: comp.sys.ibm.pc,mod.protocols.tcp-ip,mod.computers.ibm-pc Subject: TCP-IP implementations for the PC anyone?? Keywords: tcp-ip pc Message-ID: <461@bcsaic.UUCP> Date: 27 Feb 87 18:52:16 GMT Organization: Boeing Computer Services ATC, Seattle Lines: 17 We have a requirement for network connections between IBM PC's and various mainframe/workstations, all of which speak either TCP or DECnet. I need to find out what is available - either commercial or PD in either realm. So if you know of or use a TCP or DECnet implementation on PC's - using Ethernet or some other medium, please let me know by email. I need basic file transfer at the minimum, some sort of ipc or telnet capability would be nice if available. Thanks much. -randy groves Boeing Advanced Technology Center UUCP: ..!uw-beaver!uw-june!bcsaic!randy USNail: Boeing Computer Services CSNET: randy@boeing.com PO Box 24346 M/S 7L-44 VOICE: (206)865-3212 Seattle, WA 98124 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8702272319.AA02634%40akamai.isi.edu] <1987022713195000> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: jkrey@AKAMAI.ISI.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Internet Network Number/AS Number Assignment Contact Change Message-ID: <8702272319.AA02634@akamai.isi.edu> Date: Fri, 27-Feb-87 18:19:50 EST Article-I.D.: akamai.8702272319.AA02634 Posted: Fri Feb 27 18:19:50 1987 Date-Received: Sun, 1-Mar-87 10:24:45 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 10 Approved: tcp-ip@sri-nic.arpa As of March 1st, 1987, the Network Information Center (NIC) at SRI will be taking over ALL assignments of network numbers and autonomous system numbers (AS) for the Internet. Anyone having questions about applications, network number/AS number assignments, or further information, should contact the Hostmaster at the NIC () or call 1-800-235-3155. Joyce Reynolds and Jon Postel ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703010118.AA05357%40topaz.rutgers.edu] <1987022815184800> 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: Another aspect of SMTP timeouts Message-ID: <8703010118.AA05357@topaz.rutgers.edu> Date: Sat, 28-Feb-87 20:18:48 EST Article-I.D.: topaz.8703010118.AA05357 Posted: Sat Feb 28 20:18:48 1987 Date-Received: Sun, 1-Mar-87 17:52:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 9 Approved: tcp-ip@sri-nic.arpa Sorry, but your diagnosis is quite correct. We modified sendmail a year or so ago to map nicknames into primary host names. We found that suddenly connections were timing out. Turns out the code to process headers was invoked after the connection was opened. My sensibilities were badly offended, but I found I could make things work by moving our host table to a dbm format. This speeded things up enough that the other end wouldn't time out. Now that we have moved to the domain system, it is quite possible that the problem has returned. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [8703010139.AA04150%40opal.Berkeley.Edu] <1987022815390300> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: minshall%opal.Berkeley.EDU@UCBVAX.BERKELEY.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: xerox -> 4.3bsd telnet Message-ID: <8703010139.AA04150@opal.Berkeley.Edu> Date: Sat, 28-Feb-87 20:39:03 EST Article-I.D.: opal.8703010139.AA04150 Posted: Sat Feb 28 20:39:03 1987 Date-Received: Sun, 1-Mar-87 16:47:49 EST References: <8702181909.AA15985@pacific.ARPA> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 43 Approved: tcp-ip@sri-nic.arpa > We recently installed a xerox 1186 (dandytiger?) running koto > release 2.0. Telneting from the 1186 to our vax 780 running > 4.3bsd hangs, apparently because the 1186 doesn't respond to > the vax telnet server's "do terminal-type" negotiation. The > 4.3bsd telnet server waits in a loop for the "will/won't terminal-type" > response, processing options, but not starting a login process. > That seems unforgiving (although seemingly legal) from 4.3bsd. ... > Or, is 4.3bsd wrong > to "hang" waiting for the "will/won't terminal-type" response? > > Thanks, > > Ron Stanonik > stanonik@nprdc.arpa > > ps. The 1186 also seems to violate the rfcs by sending the > "terminal-type is" subnegotiation without first receiving > a "terminal send". Or maybe it thinks that is a suitable > response to "do terminal-type"? I wrote some of the code in the 4.3 telnet server. I didn't want to start up the login process until I got a reply to the terminal type negotiation, since a positive reply would allow me to set up the terminal type in the login processes environment. In an engineering sense, I could have said "if no answer within N seconds, skip the terminal type negoitiation". I didn't do that. In a more perfect world, I probably would have. Now, as for your "1186", if it listens to "do terminal type" by replying "terminal type is", then it is out of spec, and you should ask your vendor for a fix. RFC930 is quite specific on this point (as well it should be). In summary, the 4.3 implementation is legal and even "reasonable"; it is not as robust as could be. Your description of the "1186"'s behaviour leads me to believe that it is not implementing the protocol correctly. Yours, Greg Minshall ----MESSAGE-END---- ----MESSAGE-BEGIN---- [13039.541567652%40huey] <1987022817434500> Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP From: farber@HUEY.UDEL.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Delta-T Paper Message-ID: <13039.541567652@huey> Date: Sat, 28-Feb-87 22:43:45 EST Article-I.D.: huey.13039.541567652 Posted: Sat Feb 28 22:43:45 1987 Date-Received: Sun, 1-Mar-87 17:32:21 EST References: <8702251945.AA01525@braden.isi.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 5 Approved: tcp-ip@sri-nic.arpa The correct source is Richard Hamming when he was at Bell Labs and said Mathemeticians stand on each other shoulders (Gauss I think) while computer scientists stand on each others toes. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- [870301054108.921938%40MIT-MULTICS.ARPA] <1987022819410000> 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: secure replacements for passwords Message-ID: <870301054108.921938@MIT-MULTICS.ARPA> Date: Sun, 1-Mar-87 00:41:00 EST Article-I.D.: MIT-MULT.870301054108.921938 Posted: Sun Mar 1 00:41:00 1987 Date-Received: Sun, 1-Mar-87 16:48:17 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 91 Approved: tcp-ip@sri-nic.arpa Date: 18 January 1987 15:57 est From: The Matt Crawford of net.* Subject: Re: secure replacements for passwords J. Spencer Love writes: ) I don't know about your TCP, but the Multics TCP will send a RST ) immediately if it receives a packet with an ACK that is too high. I ) believe that this is clearly spelled out in the specification, but I am ) at home and don't have the specification handy. Nope, RFC-793 says "If the ACK acks something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return. Thank you for pointing this out. I'm sorry that this reply is so delayed. The Multics TCP does, in fact, behave as I claimed. I have examined RFC-793, and the sentence which Matt Crawford quoted is on page 72 (page 2-256 of the DDN PROTOCOL HANDBOOK). This deals with the ESTABLISHED state. In the pre-ESTABLISHED states (LISTEN, SYN-SENT and SYN-RECEIVED), the specification directs the implementor to form a RST packet based on the invalid acknowledgement. Thus, the Multics implementation's behavior is conformant until the connection is established, and deviant thereafter. Does anyone know what the specifiers had in mind when they made this distinction? The rest of this message attempts to explain my reasons for believing that the specification is wrong here and should be changed. If someone attempts to spoof the connection, they can do so by monitoring the connection and inserting a packet. This packet might contain commands (via the TELNET server), spurious mail, or faked output (back to the user TELNET). Because packets routinely come from gateways which are not the IP header source, it is difficult to detect this spoofing by examining the lower layer's packet source. There are two cases. In the "hard" case, the spoofer has corrupted network routing, so that no packets are exchanged between the original connection endpoints. The spoofer can insert itself into the connection, completely concealing its presence, or permit one side of the connection to time out, replacing it to the other side of the connection. Hopefully, this type of spoofing can be prevented by other means. In the "easy" case, the connection routing is not disrupted. The bogus packet is merely inserted into the stream. The receiver of the bogus packet will issue an acknowledgement which will get back to the other end of the connection. If we are lucky, this packet will appear to acknowledge something which hasn't yet been sent. If it *has* been sent, then the chance of the bogus packet's being accepted is reduced, unless routing has also been corrupted. If routing has been corrupted in the direction that the bogus packet's acknowledgement will travel, then this is effectively the same as the "hard" case. I can't think of a situation where a "precognitive" acknowledgement is valid. If one arrives, it indicates either that a spoof attempt has been made, or that a packet has long outlived its TTL and emerged from some network backwater like some kind of glacier-preserved SF creature. The chance that such an anachronism will also pass the sequence number check is hopefully small, but certain operating systems which we all know are very repetitious about selecting port and sequence numbers. The receiver of the precognitive acknowledgement should send a RST packet. Ideally, it should also refrain from sending data up to the precognition point for awhile (some function of RTT and TTL), but that is probably too much to ask. It should also log the precognitive ACK as a possible spoof attempt. If the precognitive ACK really emerged from the glacier, then (ignoring race conditions), the RST packet which it elicits will fail the sequence number test at the other end of the connection and is thus harmless. If routing has been corrupted in the direction the RST travels, at least the spoof has been detected and logged at one end so that troubleshooting can find it later. If the RST gets through, it will abort the spoofed connection and hopefully minimize the damage. If the RST packet carries an "explanation" in its otherwise unused data field, then this also can be logged at the receiving end so that both ends of the connection have a record of the spoof. The likelihood of having normal service clobbered by this RST is low. The likelihood of a spoof is hard to estimate, but the protocol should act to limit, as much as possible, the effects of spoofing, and to detect such attempts, especially when no extra work is involved. With this in mind, I don't plan to change Multics to conform to the specification in this area, although I would be interested in and would act upon a convincing refutation. -- Spencer Love ----MESSAGE-END----