----MESSAGE-BEGIN---- <1986040103240000> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Tue 1 Apr 86 07:16:49-PST Received: from northeastern by csnet-relay.csnet id aa19574; 1 Apr 86 10:07 EST Date: Tue, 1 Apr 86 08:24 EST From: JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA To: tcp-ip@sri-nic.ARPA, johnson%northeastern.csnet@CSNET-RELAY.ARPA Subject: Concerning unused options in IP packets. I'm just learning tcp/ip myself. In reading rfc 791, I found the following general statement in section 3.2: "In general an [IP] implementation must be conservative in its sending behavior, and liberal in its receiving behavior." Concerning assumptions about IP packet option formats this seems like a VERY good idea. To protect one's own system, one should hope for good input but expect problems with incoming packets. In general I've found this to be the best way with most software. Yes it's more work and on some systems it can be very difficult. However, covering your tail pointer is usually a good idea. It can be very embarrassing to have your wonderful, totally cosmic piece of software crash in public. It's even more embarrassing when a real-time system like network goes down because you drop packets on the floor and then have to get a broom and a bucket to clean things up. At the speeds and traffic level of some parts of the network, the mess can get really big FAST. I don't know about anyone else but I don't think I'd assume anything about what options look like in a packet. We all know what happens when assumptions are made. Chris Johnson Sr System Programmer Northeastern University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040104101300> Received: from USNA.ARPA by SRI-NIC.ARPA with TCP; Tue 1 Apr 86 08:13:07-PST Date: Tue, 1 Apr 86 9:10:13 EST From: Terry Slattery To: tcp-ip@SRI-NIC.ARPA Subject: host.txt I use host.txt frequently to look up hosts which I know to be on the net and don't know their official names (or even a hit of their name other than the organization name). I have gone as far as to create a simple script to match patterns in the host tables so that users here can quickly look to see if they can find out the name of the host(s) at other sites on DDN. If (when?) host.txt goes away, I would hope that there would be a counterpart to 'whois' for polling the servers about potential host names. Pattern matching is important because I also use this script to look up all hosts attached to particular sub-nets or imps. It helps me get an idea of the route my data is or will be taking to get to a particular host. -tcs ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040111372500> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Tue 1 Apr 86 13:43:42-PST Date: Tue, 1 Apr 86 16:37:25 EST From: Mike Muuss To: Murray.pa@xerox.com cc: TCP-IP@sri-nic.arpa, Murray.pa@xerox.com, JLarson.pa@xerox.com Subject: Re: Anybody normally send packets with unused options? I recall a comment from the Cray TCP people that they use empty option bytes to word-align their data areas in the packets. I suspect that on machines with a strong word-alignment preference, this practice will be increasingly popular. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040111550000> Received: from LOGICON.ARPA by SRI-NIC.ARPA with TCP; Tue 1 Apr 86 20:01:12-PST Date: 1 Apr 86 19:55 PST From: Jeff Makey To: TCP-IP@SRI-NIC.ARPA Cc: Makey@LOGICON.ARPA Subject: ICMP Redirect Wars Every now and then, two or three of the ARPANET<->MILNET gateways will get into an ICMP Redirect argument over who should be handling one of my connections. Below is the latest example of this behavior, taken from my April 1 TCP/IP daemon log (this happened before April Fools day, too). Redirect 10.0.0.44 (code 0) to 26.2.0.49 (from 26.2.0.73 at 16:11:36) Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.2.0.49 at 16:11:38) Redirect 10.0.0.44 (code 0) to 26.2.0.49 (from 26.2.0.73 at 16:11:43) Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.2.0.49 at 16:11:44) Redirect 10.0.0.44 (code 0) to 26.2.0.49 (from 26.2.0.73 at 16:11:45) Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.2.0.49 at 16:11:49) Redirect 10.0.0.44 (code 0) to 26.2.0.49 (from 26.2.0.73 at 16:11:53) Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.2.0.49 at 16:11:57) Redirect 10.0.0.44 (code 0) to 26.2.0.49 (from 26.2.0.73 at 16:11:59) Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.2.0.49 at 16:12:02) Redirect 10.0.0.44 (code 0) to 26.0.0.104 (from 26.2.0.73 at 16:16:05) Redirect 10.0.0.44 (code 0) to 26.2.0.73 (from 26.0.0.104 at 16:16:06) Notes: All times are Pacific Standard Time (HH:MM:SS). Code 0 means "Redirect datagrams for the Network" [RFC 792]. 10.0.0.44 is XX.LCS.MIT.EDU. 26.2.0.73 is SRI-MILNET-GW.ARPA (my host's assigned ARPANET<-> MILNET gateway [DDN Mgt Bulletin #23]). 26.2.0.49 is BBN-MILNET-GW.ARPA. 26.0.0.104 is DCEC-MILNET-GW.ARPA. It was a TCP/SMTP connection sending from XX.LCS.MIT.EDU to LOGICON.ARPA (26.2.0.3). I don't know exactly when the connection was established, but we received the SMTP DATA command at 16:12:15 and the last of 10868 bytes trickled in at 16:17:07 (for an average of 37.2 bytes per second). (The piece of mail was Arms-Discussion digest V6 #69.) An occasional redirect is fine, but this whipsawing back and forth can't be good for anybody (due to the ICMP overhead). Is this sort of behavior just a symptom of the poor ARPANET<->MILNET performance or does it contribute to the problem? :: Jeff Makey Makey@LOGICON.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040117164800> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Tue 1 Apr 86 19:20:10-PST Date: 1 Apr 1986 22:16:48 EST From: MILLS@USC-ISID.ARPA Subject: Re: Anybody normally send packets with unused options? To: mike@BRL.ARPA, Murray.pa@XEROX.COM cc: TCP-IP@SRI-NIC.ARPA, JLarson.pa@XEROX.COM, cc: MILLS@USC-ISID.ARPA In response to the message sent Tue, 1 Apr 86 16:37:25 EST from mike@BRL.ARPA Mike, Cray may save a nanosecond or two when constructing a packet to send, but it sure doesn't help when receiving a packet. The practice may be getting popular as you say, but it's broken. Our Internet Toolbook should include a chapter on how to compute checksums in wonderfully wierd ways for TOPS-20s, Multices, Univax and Borroughs, not to mention a 7090 and anything else with oddly sized words. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040123555300> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 2 Apr 86 08:05:49-PST Date: 2 Apr 1986 07:55:53 PST Subject: Diabolically Execrable? From: Dan Lynch To: tcp-ip@SRI-NIC.ARPA cc: LYNCH@USC-ISIB.ARPA Ddoes anyone out there think that the recent performance of Milnet/Arpanet is simply a test of the robustness of the protocols involved?/ If so, then you could tell the authorities that the data arrived intact and in order, but the need for it vanished before it arrived. Dan PS. It only took me 30 minutes to compose this, Noel. Maybe things are improving??? ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040204360000> Received: from SCRC-STONY-BROOK.ARPA by SRI-NIC.ARPA with TCP; Wed 2 Apr 86 06:42:46-PST Received: from REDWING.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 452825; Wed 2-Apr-86 09:36:29-EST Date: Wed, 2 Apr 86 09:36 EST From: Benson I. Margulies Subject: FTP protocol violations To: tcp-ip@SRI-NIC.ARPA Message-ID: <860402093634.8.MARGULIES@REDWING.SCRC.Symbolics.COM> Folks, 4.2BSD replies with 200 to DELE rather than 250. If being permissive about what one accepts means accepting this, should I make my implementation ignore the second two digits of positive responses to simple model commands? I can't see taking too and 250 and no other 2xy's. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040208230000> Mail-From: STJOHNS created at 2-Apr-86 16:29:06 Date: 2 Apr 1986 16:23-PST Sender: STJOHNS@SRI-NIC.ARPA Subject: Re: FTP protocol violations From: STJOHNS@SRI-NIC.ARPA To: DCP@SCRC-QUABBIN.ARPA Cc: romkey@MIT-BORAX.ARPA, Margulies@SCRC-YUKON.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[SRI-NIC.ARPA] 2-Apr-86 16:23:08.STJOHNS> In-Reply-To: <860402170628.4.DCP@FIREBIRD.SCRC.Symbolics.COM> The robustness principle says that you accept anything that works, but you do the right thing for anything you put out. John is perfectly correct in accepting wierd responses if he can get it to work. On the other hand, the 4.2 implementation is WRONG and should be fixed post haste. For those of you on the MILNET side of the house, there will eventually be a suite of protocl certifiers including FTP. (Please, no inquiries, I've told you all I know) Each milnet system will eventually have to toe the line. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040209153700> Received: from BORAX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Wed 2 Apr 86 11:19:03-PST Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Wed, 2 Apr 86 14:15:37 est Date: Wed, 2 Apr 86 14:15:37 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Message-Id: <8604021915.AA04764@BORAX.LCS.MIT.EDU> To: Margulies@SCRC-YUKON.ARPA Cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: Benson I. Margulies's message of Wed, 2 Apr 86 09:36 EST Subject: FTP protocol violations Date: Wed, 2 Apr 86 09:36 EST From: Benson I. Margulies If being permissive about what one accepts means accepting this, should I make my implementation ignore the second two digits of positive responses to simple model commands? I can't see taking too and 250 and no other 2xy's. That's the way my IBM PC FTP does it. The command state machine is just driven by the first digit. The other two digits can be used to get more information, but unless I've missed something somewhere, you can safely ignore them in deciding whether or not a command succeeded, or what to do next. - john romkey ftp software ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040212060000> Received: from ALLEGHENY.SCRC.Symbolics.COM ([192.10.41.45]) by SRI-NIC.ARPA with TCP; Wed 2 Apr 86 14:07:12-PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 10983; Wed 2-Apr-86 17:06:33-EST Date: Wed, 2 Apr 86 17:06 EST From: David C. Plummer Subject: FTP protocol violations To: John Romkey , Margulies@SCRC-YUKON.ARPA cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: <8604021915.AA04764@BORAX.LCS.MIT.EDU> Message-ID: <860402170628.4.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Wed, 2 Apr 86 14:15:37 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Date: Wed, 2 Apr 86 09:36 EST From: Benson I. Margulies If being permissive about what one accepts means accepting this, should I make my implementation ignore the second two digits of positive responses to simple model commands? I can't see taking too and 250 and no other 2xy's. That's the way my IBM PC FTP does it. The command state machine is just driven by the first digit. The other two digits can be used to get more information, but unless I've missed something somewhere, you can safely ignore them in deciding whether or not a command succeeded, or what to do next. - john romkey ftp software Wait a minute. A spec is a spec. What's the point of the two digits if (a) some hosts send the wrong ones, and (b) some hosts don't bother to look at them. If the spec said you could be lazy, then it would be OK. If the spec doesn't, an implementation is INCORRECT if it sends the wrong codes and an implementation is ASKING FOR TROUBLE if it accepts more than what the spec says. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040212370100> Received: from BORAX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Wed 2 Apr 86 14:40:23-PST Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Wed, 2 Apr 86 17:37:01 est Date: Wed, 2 Apr 86 17:37:01 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Message-Id: <8604022237.AA06543@BORAX.LCS.MIT.EDU> To: DCP@SCRC-QUABBIN.ARPA Cc: Margulies@SCRC-YUKON.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: David C. Plummer's message of Wed, 2 Apr 86 17:06 EST Subject: more FTP protocol violations Date: Wed, 2 Apr 86 17:06 EST From: David C. Plummer Date: Wed, 2 Apr 86 14:15:37 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Date: Wed, 2 Apr 86 09:36 EST From: Benson I. Margulies ..... ..... Wait a minute. A spec is a spec. What's the point of the two digits if (a) some hosts send the wrong ones, and (b) some hosts don't bother to look at them. If the spec said you could be lazy, then it would be OK. If the spec doesn't, an implementation is INCORRECT if it sends the wrong codes and an implementation is ASKING FOR TROUBLE if it accepts more than what the spec says. I probably should've just done this the first time, but I had to go reread the spec to be sure. From RFC 959, last paragraph of page 36: "The three digits of the reply each have a special significance. This is intended to allow a range of very simple to very sophisticated responses by the user-process. The first digit denotes whether the response is good, bad or incomplete. (Referring to the state diagram), an unsophisticated user-process will be able to determine its next action (proceed as planned, redo, retrench, etc.) by simply examining this first digit. A user-process that wants to know approximately what kind of error occurred (e.g. file system error, command syntax error) may examine the second digit, reserving the third digit for the finest gradation of information (e.g., RNTO command without a preceding RNFR)." And Section 6 presents some simple state machines for commands, using only the first digit of the code to drive them. So we can be lazy if we want to. It makes sense to me to have an error indication (first digit) and then a more specific error code (second digit), but it doesn't seem to me that we should really have to worry about "what kind of success" happened when there was no error, which is what the original question was about (4.2 returning a strange success code). So I think most user implementations can probably ignore the second and third digits in the case of success. Of course, if there is a "standard" response (250) to send in the case of success, a server should probably send that instead of something else that's similar but not quite the same (200). Appendix II of RFC959 says that the correct success response to a DELE is 250. - john ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040212440000> Received: from ALLEGHENY.SCRC.Symbolics.COM ([192.10.41.45]) by SRI-NIC.ARPA with TCP; Wed 2 Apr 86 14:45:34-PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11003; Wed 2-Apr-86 17:44:54-EST Date: Wed, 2 Apr 86 17:44 EST From: David C. Plummer Subject: more FTP protocol violations To: John Romkey , DCP@SCRC-QUABBIN.ARPA cc: Margulies@SCRC-YUKON.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: <8604022237.AA06543@BORAX.LCS.MIT.EDU> Message-ID: <860402174449.1.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Wed, 2 Apr 86 17:37:01 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Date: Wed, 2 Apr 86 17:06 EST From: David C. Plummer Date: Wed, 2 Apr 86 14:15:37 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Date: Wed, 2 Apr 86 09:36 EST From: Benson I. Margulies ..... ..... Wait a minute. A spec is a spec. What's the point of the two digits if (a) some hosts send the wrong ones, and (b) some hosts don't bother to look at them. If the spec said you could be lazy, then it would be OK. If the spec doesn't, an implementation is INCORRECT if it sends the wrong codes and an implementation is ASKING FOR TROUBLE if it accepts more than what the spec says. I probably should've just done this the first time, but I had to go reread the spec to be sure. From RFC 959, last paragraph of page 36: "The three digits of the reply each have a special significance. This is intended to allow a range of very simple to very sophisticated responses by the user-process. The first digit denotes whether the response is good, bad or incomplete. (Referring to the state diagram), an unsophisticated user-process will be able to determine its next action (proceed as planned, redo, retrench, etc.) by simply examining this first digit. A user-process that wants to know approximately what kind of error occurred (e.g. file system error, command syntax error) may examine the second digit, reserving the third digit for the finest gradation of information (e.g., RNTO command without a preceding RNFR)." And Section 6 presents some simple state machines for commands, using only the first digit of the code to drive them. So we can be lazy if we want to. It makes sense to me to have an error indication (first digit) and then a more specific error code (second digit), but it doesn't seem to me that we should really have to worry about "what kind of success" happened when there was no error, which is what the original question was about (4.2 returning a strange success code). So I think most user implementations can probably ignore the second and third digits in the case of success. OK, that takes care of the user end; user ends are allowed to be lazy. Of course, if there is a "standard" response (250) to send in the case of success, a server should probably send that instead of something else that's similar but not quite the same (200). Appendix II of RFC959 says that the correct success response to a DELE is 250. Several (all?) Unix server implementations send 200. This is NOT the correct response, and I think a user program that does look at all three digits is allowed to consider this a protocol violation. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040302290000> Received: from SCRC-STONY-BROOK.ARPA by SRI-NIC.ARPA with TCP; Thu 3 Apr 86 04:32:40-PST Received: from REDWING.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 454032; Thu 3-Apr-86 07:32:14-EST Date: Thu, 3 Apr 86 07:29 EST From: Benson I. Margulies Subject: FTP protocol violations To: David C. Plummer , John Romkey cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: <860402170628.4.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-ID: <860403072958.4.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Wed, 2 Apr 86 17:06 EST From: David C. Plummer Date: Wed, 2 Apr 86 14:15:37 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Date: Wed, 2 Apr 86 09:36 EST From: Benson I. Margulies If being permissive about what one accepts means accepting this, should I make my implementation ignore the second two digits of positive responses to simple model commands? I can't see taking too and 250 and no other 2xy's. That's the way my IBM PC FTP does it. The command state machine is just driven by the first digit. The other two digits can be used to get more information, but unless I've missed something somewhere, you can safely ignore them in deciding whether or not a command succeeded, or what to do next. - john romkey ftp software Wait a minute. A spec is a spec. What's the point of the two digits if (a) some hosts send the wrong ones, and (b) some hosts don't bother to look at them. If the spec said you could be lazy, then it would be OK. If the spec doesn't, an implementation is INCORRECT if it sends the wrong codes and an implementation is ASKING FOR TROUBLE if it accepts more than what the spec says. I would point out that the general princible: `be precise in what you send, be forgiving in what you receive' has been stated many times for the internet protocol set. FTP, however, nowhere says that the implication of this is to just look at the first digit. What are the chances of a clarification from on-high? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040302480000> Received: from SCRC-STONY-BROOK.ARPA by SRI-NIC.ARPA with TCP; Thu 3 Apr 86 04:48:26-PST Received: from REDWING.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 454038; Thu 3-Apr-86 07:48:00-EST Date: Thu, 3 Apr 86 07:48 EST From: Benson I. Margulies Subject: more FTP protocol violations To: John Romkey , DCP@SCRC-QUABBIN.ARPA cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: <8604022237.AA06543@BORAX.LCS.MIT.EDU> Message-ID: <860403074813.9.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Wed, 2 Apr 86 17:37:01 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Date: Wed, 2 Apr 86 17:06 EST From: David C. Plummer Date: Wed, 2 Apr 86 14:15:37 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Date: Wed, 2 Apr 86 09:36 EST From: Benson I. Margulies ..... ..... Wait a minute. A spec is a spec. What's the point of the two digits if (a) some hosts send the wrong ones, and (b) some hosts don't bother to look at them. If the spec said you could be lazy, then it would be OK. If the spec doesn't, an implementation is INCORRECT if it sends the wrong codes and an implementation is ASKING FOR TROUBLE if it accepts more than what the spec says. I probably should've just done this the first time, but I had to go reread the spec to be sure. From RFC 959, last paragraph of page 36: "The three digits of the reply each have a special significance. This is intended to allow a range of very simple to very sophisticated responses by the user-process. The first digit denotes whether the response is good, bad or incomplete. (Referring to the state diagram), an unsophisticated user-process will be able to determine its next action (proceed as planned, redo, retrench, etc.) by simply examining this first digit. A user-process that wants to know approximately what kind of error occurred (e.g. file system error, command syntax error) may examine the second digit, reserving the third digit for the finest gradation of information (e.g., RNTO command without a preceding RNFR)." And Section 6 presents some simple state machines for commands, using only the first digit of the code to drive them. So we can be lazy if we want to. It makes sense to me to have an error indication (first digit) and then a more specific error code (second digit), but it doesn't seem to me that we should really have to worry about "what kind of success" happened when there was no error, which is what the original question was about (4.2 returning a strange success code). So I think most user implementations can probably ignore the second and third digits in the case of success. Of course, if there is a "standard" response (250) to send in the case of success, a server should probably send that instead of something else that's similar but not quite the same (200). Appendix II of RFC959 says that the correct success response to a DELE is 250. - john I wish that someone at the NIC would mark old RFC files old. I was reading 765 ... ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040302500000> Received: from SCRC-STONY-BROOK.ARPA by SRI-NIC.ARPA with TCP; Thu 3 Apr 86 04:50:30-PST Received: from REDWING.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 454039; Thu 3-Apr-86 07:49:57-EST Date: Thu, 3 Apr 86 07:50 EST From: Benson I. Margulies Subject: more FTP protocol violations To: David C. Plummer , John Romkey cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: <860402174449.1.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-ID: <860403075009.0.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Wed, 2 Apr 86 17:44 EST From: David C. Plummer Date: Wed, 2 Apr 86 17:37:01 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Date: Wed, 2 Apr 86 17:06 EST From: David C. Plummer Date: Wed, 2 Apr 86 14:15:37 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Date: Wed, 2 Apr 86 09:36 EST From: Benson I. Margulies ..... ..... Wait a minute. A spec is a spec. What's the point of the two digits if (a) some hosts send the wrong ones, and (b) some hosts don't bother to look at them. If the spec said you could be lazy, then it would be OK. If the spec doesn't, an implementation is INCORRECT if it sends the wrong codes and an implementation is ASKING FOR TROUBLE if it accepts more than what the spec says. I probably should've just done this the first time, but I had to go reread the spec to be sure. From RFC 959, last paragraph of page 36: "The three digits of the reply each have a special significance. This is intended to allow a range of very simple to very sophisticated responses by the user-process. The first digit denotes whether the response is good, bad or incomplete. (Referring to the state diagram), an unsophisticated user-process will be able to determine its next action (proceed as planned, redo, retrench, etc.) by simply examining this first digit. A user-process that wants to know approximately what kind of error occurred (e.g. file system error, command syntax error) may examine the second digit, reserving the third digit for the finest gradation of information (e.g., RNTO command without a preceding RNFR)." And Section 6 presents some simple state machines for commands, using only the first digit of the code to drive them. So we can be lazy if we want to. It makes sense to me to have an error indication (first digit) and then a more specific error code (second digit), but it doesn't seem to me that we should really have to worry about "what kind of success" happened when there was no error, which is what the original question was about (4.2 returning a strange success code). So I think most user implementations can probably ignore the second and third digits in the case of success. OK, that takes care of the user end; user ends are allowed to be lazy. Of course, if there is a "standard" response (250) to send in the case of success, a server should probably send that instead of something else that's similar but not quite the same (200). Appendix II of RFC959 says that the correct success response to a DELE is 250. Several (all?) Unix server implementations send 200. This is NOT the correct response, and I think a user program that does look at all three digits is allowed to consider this a protocol violation. I disagree. The paragraph above says clearly that the basic response semantics are implied by the first digit. It seems to me that the spec should be revised to state that for success the later two digits are unimportant. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040303291800> Received: from sri-spam.arpa by SRI-NIC.ARPA with TCP; Thu 3 Apr 86 11:29:11-PST Received: by sri-spam.arpa (5.4/4.16) id AA17823; Thu, 3 Apr 86 11:29:18 PST Date: Thu, 3 Apr 86 11:29:18 PST From: gds@sri-spam.ARPA (Greg Skinner) Message-Id: <8604031929.AA17823@sri-spam.arpa> To: tcp-ip@sri-nic.ARPA Subject: Re: more FTP protocol violations I don't have a copy of RFC959 handy, but here's an interesting paragraph from RFC765 on the sequencing of commands and replies. The table below lists alternative success and failure replies for each command. These must be *strictly* (emphasis mine) adhered to; a server may substitute text in the replies, but the meaning and action implied by the code numbers and by the specific command reply sequence cannot be altered. And, in the sequence for DELE DELE, CWD 250 450, 550 500, 501, 502, 421, 530 So it would seem (at least to implementors of RFC765 FTP) that the burden of protocol correctness is on the server end. If I'm not mistaken 4.2bsd FTP was written sometime afterwards with all the X commands, which may account for the fact that it didn't conform to RFC765. From: David C. Plummer Several (all?) Unix server implementations send 200. This is NOT the correct response, and I think a user program that does look at all three digits is allowed to consider this a protocol violation. Well, not all. I wrote an FTP server for a pdp11 v6 Unix once that returned 250 for a successful delete. RFC765 seems to suggest that a user FTP implement a FSM to interpret server replies, rather than match on the replies themselves. Considering the fact that the requested action is completed, independent of whether or not the response from the DELE indicates so, it seems to be a bit nitpicky to require an exact interpretation of the successful reply to a DELE, and also bothersome for a user FTP to match exactly on its response. (Does anyone out there actually examine for the grade of success?) But, of course, one should be conservative in what one sends, etc. --gregbo ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040304183100> Mail-From: OLE created at 3-Apr-86 12:19:20 Date: Thu 3 Apr 86 12:18:31-PST From: Ole Jorgen Jacobsen Subject: Re: more FTP protocol violations To: Margulies@SCRC-YUKON.ARPA cc: romkey@MIT-BORAX.ARPA, DCP@SCRC-QUABBIN.ARPA, tcp-ip@SRI-NIC.ARPA, OLE@SRI-NIC.ARPA In-Reply-To: <860403074813.9.MARGULIES@REDWING.SCRC.Symbolics.COM> SRI-NIC: (415) 859-4536 Home: (415) 325-9427 Beeper: (415) 496-9427 Message-ID: <12195947137.33.OLE@SRI-NIC.ARPA> Folks, The way to find the current version of any given RFC is to look in [SRI-NIC.ARPA]RFC:RFC-INDEX.TXT. In this file you will find the phrase: "Obsoletes RFC xxx" in the entry for the new one. I'll look into making this a two-way street so that RFC-765 would be marked "Obsoleted by RFC-959". Cheers, Ole ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040304593600> Received: from gyre.umd.edu by SRI-NIC.ARPA with TCP; Thu 3 Apr 86 07:06:40-PST Received: by gyre.umd.edu (5.9/4.7) id AA03176; Thu, 3 Apr 86 09:59:36 EST Date: Thu, 3 Apr 86 09:59:36 EST From: Chris Torek Message-Id: <8604031459.AA03176@gyre.umd.edu> To: DCP@scrc-quabbin.ARPA, Margulies@scrc-yukon.ARPA Subject: Re: FTP protocol violations Cc: tcp-ip@sri-nic.ARPA Instead of complaining about the broken 4.x ftp server, I thought it more useful to provide the fix. Here it is. Feel free to give it to anyone whose server is still wrong. Chris RCS file: RCS/ftpd.c,v retrieving revision 1.1 retrieving revision 1.2 diff -c -r1.1 -r1.2 *** /tmp/,RCSt1003149 Thu Apr 3 09:58:20 1986 --- /tmp/,RCSt2003149 Thu Apr 3 09:58:23 1986 *************** *** 559,565 **** ack(s) char *s; { ! reply(200, "%s command okay.", s); } nack(s) --- 559,565 ---- ack(s) char *s; { ! reply(250, "%s command okay.", s); } nack(s) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040306060000> Received: from decwrl.DEC.COM by SRI-NIC.ARPA with TCP; Thu 3 Apr 86 14:06:41-PST Received: by decwrl.DEC.COM (4.22.03/4.7.34) id AA06850; Thu, 3 Apr 86 14:06:52 pst From: johnsson@decwrl.DEC.COM (Richard Johnsson) Message-Id: <8604032206.AA06850@decwrl.DEC.COM> Date: 3 Apr 1986 1406-PST (Thursday) To: tcp-ip@sri-nic.ARPA Subject: Core gateway slot problem Has the problem of running out of Core gateway slots for connected networks suddenly gotten worse? Our network (128.45.0) seems to be going in and out (mostly out today) although our EGP process has been running continuously for the last three days. In the past my experience has been that once we got a slot we kept it until our gateway crashed. Richard ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040306450000> Received: from ucbvax.berkeley.edu by SRI-NIC.ARPA with TCP; Wed 9 Apr 86 01:06:25-PST Received: by ucbvax.berkeley.edu (5.48/1.11) id AA23003; Wed, 9 Apr 86 01:06:40 PST Received: by decwrl.DEC.COM (4.22.03/4.7.34) id AA23186; Wed, 9 Apr 86 01:05:29 pst Received: By spar.SPAR.CAS.SLB.COM (from magoo.SPAR.CAS.SLB.COM) id AA00238; Thu, 3 Apr 86 14:46:48 pst Return-Path: Received: By magoo.SPAR.CAS.SLB.COM id AA09558; Thu, 3 Apr 86 14:46:31 pst Message-Id: <8604032246.AA09558@magoo.SPAR.CAS.SLB.COM> Date: 3 Apr 1986 14:45-PST From: Rafael Bracho Subject: Please post in tcp-ip groups To: tcp-ip@ucbvax.berkeley.edu Could you please post this message? Thanks. =============== Subject: Arpanet/Ethernet gateway needed. Reply-To: rxb@spar.UUCP (Rafael Bracho) Distribution: net Organization: Schlumberger Palo Alto Research Keywords: tcp-ip, arpanet, gateways, HDH, 1822-J I need some advise from arpanet wizards: We just got our arpanet port assigned and are in the process of putting together an arpanet/ethernet gateway. We have an HDH port (1822-J) which pretty much limits us to the ACC IF-11/HDH board (is this correct?), a Unibus board with HDH normally downloaded into it. We'd like something with reasonable performance, we are getting 56kb DDS between our computer room and the IMP. Could anyone tell me what is the hardware I should buy? Which software can I get to run on it? Is there anyone out in net-land that has an HDH port and an arpanet/ethernet gateway? Help is most appreciated. Rafael Bracho Schlumberger Palo Alto Research 415-496-4644 BRACHO@SRI-KL.ARPA ...{decwrl,hplabs}!spar!rxb ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040308330000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Thu 3 Apr 86 16:39:51-PST Date: 3 Apr 86 16:33:00 PST From: Subject: tcp for AT&T To: "garry%cadif-oak" cc: tcp-ip@sri-nic Reply-To: Garry, Wollongong has a contract with AT&T IS to supply TCP/IP for all levels of 3B's. This is bing coordinated by Computer Systems Division in Lisle. AT&T plans to offer the package as a supported product from them. ACC has a contract also with AT&T to supply 3B - 1822 interfaces for all of the 3B's. We have delivered the initial prototype units to AT&T and will be supplying the production units this month. Our development plans call for supporting a DDN X.25 interface sometime in the future for the 3B's as well. Please contact me direct about your specific application. Email: gary@ACC.ARPA Telephone: 805-963-9431 Regards, Gary Krall ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040311130600> Received: from OFFICE-1.ARPA by SRI-NIC.ARPA with TCP; Thu 3 Apr 86 16:31:32-PST Date: 03 APR 86 16:13:06 From: {ATE.R/CHESTNUT}ONTYME@OFFICE-1 Reply-to: RC.TYM@OFFICE-1.arpa Subject: Removal from distribution list To: tcp-ip@sri-nic.arpa Message-ID: Please remove me (RC.TYM@OFFICE-1) from the TCP-IP distribution list. The material has a slant somewhat different from what I had expected. Thank you. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040312543400> Received: from cu-arpa.cs.cornell.edu by SRI-NIC.ARPA with TCP; Thu 3 Apr 86 14:55:54-PST Received: by cu-arpa.cs.cornell.edu (5.31/4.30) id AA12058; Thu, 3 Apr 86 17:54:53 EST Date: Thu, 3 Apr 86 17:54:34 EST From: garry@batcomputer.tn.cornell.edu (Garry Wiegand) Message-Id: <8604032254.AA22062@tcgould.tn.cornell.edu> Received: by tcgould.tn.cornell.edu (5.31/4.30) id AA22062; Thu, 3 Apr 86 17:54:34 EST Newsgroups: arpa.tcp-ip Subject: tcp for an AT&T 3b20 (got one?) Reply-To: garry%cadif-oak@cu-arpa.cornell.edu.arpa Organization: Cornell Engineering && Flying Moose Graphics Apparently-To: tcp-ip@sri-nic.arpa We've great big AT&T 3b20 (n o t the same as a 3b2!) standing around here lookin' dumb. Reason she's dumb (and deaf) is she only speaks "3b" protocol (whatever that may be) on the ethernet. Anybody have/heard of tcp implemented on this beast? garry wiegand garry%cadif-oak@cu-arpa.cs.cornell.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040316172700> Received: from MC.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Thu 3 Apr 86 18:16:09-PST Date: Thu, 3 Apr 86 21:17:27 EST From: "George J. Carrette" Subject: FTP specs and conventions To: dcp@SCRC-STONY-BROOK.ARPA cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[MC.LCS.MIT.EDU].873323.860403.GJC> One thing I wondered about is why the Symbolics FTP server responds to the LIST and NLST commands with exactly the same data? Was there a reason for leaving out the usual data like creation dates and sizes and such? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040318424700> Received: from SIMTEL20.ARPA by SRI-NIC.ARPA with TCP; Fri 4 Apr 86 00:43:29-PST Date: Fri 4 Apr 86 01:42:47-MST From: Mark Crispin Subject: nested replies, Milnet/ARPANET performance To: TCP-IP@SRI-NIC.ARPA Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Telephone: +1 (415) 968-1052 Message-ID: <12196082626.16.MRC@SIMTEL20.ARPA> Folks - I'm sort of annoyed by the style of replies which include the message being replied to in the reply. It gets rather tedious quite quickly. Can we all make an effort not to do this? It's much better to write a reply that makes the context of the message obvious than to write one that has 5 or 6 new text lines in a 100+ line message... I've complained about the Milnet/ARPANET performance for over a year now. In the SF Bay Area the local ARPANET TAC is 300 baud only, so most of us haven't even bothered getting an ARPANET TAC ID. This is alright since there are lots of ARPANET hosts (Stanford, SRI) around here for ARPANET access. But the SRI Milnet TAC is the only one with dialups, and it gets heavy usage. If the TAC is busy or in catatonic mode (a distressingly common occurance) I find myself cut off from Milnet. It has been impossible to do serious heavy-duty editing, real-time debugging, or any of the other software development tasks I do here if I have to go through the Milnet/ARPANET gateways, and it's been that way for over a year. I'll grant that Telnet between ARPANET and Milnet is an abuse of the gateways, but given the totally inadequate Milnet access around here the choices narrow down to that or being cut off. Actually there isn't a choice now; if the Milnet TAC is down we are effectively cut off from Milnet. I question the wisdom of maintaining the Milnet and ARPANET as discreet networks. From what I can tell the perceived need for the split has evaporated. There must be a lot of unnecessary trunk duplication, not to mention all that gateway traffic which would go away if we rejoined Milnet and ARPANET into a single net. How about it, DCA? -- Mark -- trying to do production work on two production nets, neither of which are producing very good results... ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040319140700> Received: from CU20B.COLUMBIA.EDU by SRI-NIC.ARPA with TCP; Thu 3 Apr 86 21:14:21-PST Date: Fri 4 Apr 86 00:14:07-EST From: Ken Rossman Subject: Re: Core gateway slot problem To: tcp-ip@SRI-NIC.ARPA In-Reply-To: <8604032206.AA06850@decwrl.DEC.COM> Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025 Phone: (212) 280-4876 Message-ID: <12196044638.14.SY.KEN@CU20B.COLUMBIA.EDU> Has the problem of running out of Core gateway slots for connected networks suddenly gotten worse? Our network (128.45.0) seems to be going in and out (mostly out today) although our EGP process has been running continuously for the last three days. In the past my experience has been that once we got a slot we kept it until our gateway crashed. We've been having lots of trouble from our network lately also (128.59). Tons of mail is piling up here. /Ken ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040403184600> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Fri 4 Apr 86 05:27:15-PST Date: Fri, 4 Apr 86 8:18:46 EST From: Ron Natalie To: Richard Johnsson cc: tcp-ip@sri-nic.arpa Subject: Re: Core gateway slot problem Actually, I've noted a strange phenomena which I don't think is slot related. Periodically the a Reachability message is sent with a fewer number of nets but all pointed to a single (but different than usual) gateway. Any one else see this. (By the way, I haven't seen the GGP counting to infinity artifact showing up in EGP messages recently, so I guess that's been fixed). ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040403500000> Received: from LOGICON.ARPA by SRI-NIC.ARPA with TCP; Fri 4 Apr 86 11:53:28-PST Date: 4 Apr 86 11:50 PST From: Jeff Makey To: TCP-IP@SRI-NIC.ARPA Cc: Makey@LOGICON.ARPA Subject: Re: Core gateway slot problem On April 3, at 16:31:56, 18:01:31, and 20:01:24 PST our SMTP server received SYNs from CU20B.COLUMBIA.EDU (128.59.32.128) but was unable to respond, being informed by SRI-MILNET-GW.ARPA (via ICMP) that the destination net was unreachable. (LOGICON.ARPA is on the MILNET, so we must go through the ARPANET to get to CU-NET.) Why is it that CU20B can send packets to LOGICON, but sometimes we can't send to them? We finally did complete a connection at 22:39:07 PST. Also, we have had this type of problem much more frequently with RED.RUTGERS.EDU (128.6.4.2), whose internet gateway is also on the ARPANET. :: Jeff Makey Makey@LOGICON.ARPA ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040405190000> Received: from ALLEGHENY.SCRC.Symbolics.COM ([192.10.41.45]) by SRI-NIC.ARPA with TCP; Fri 4 Apr 86 07:20:08-PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11236; Fri 4-Apr-86 10:19:53-EST Date: Fri, 4 Apr 86 10:19 EST From: David C. Plummer Subject: FTP specs and conventions To: George J. Carrette , dcp@SCRC-STONY-BROOK.ARPA cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: <[MC.LCS.MIT.EDU].873323.860403.GJC> Message-ID: <860404101940.8.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Thu, 3 Apr 86 21:17:27 EST From: "George J. Carrette" One thing I wondered about is why the Symbolics FTP server responds to the LIST and NLST commands with exactly the same data? Was there a reason for leaving out the usual data like creation dates and sizes and such? Because the code for :LIST says ;; Some day do better than this. and then calls the NLST code. Thanks for pointing this out. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040406020600> Received: from BBNCCV.ARPA by SRI-NIC.ARPA with TCP; Fri 4 Apr 86 10:17:13-PST To: Ron Natalie cc: Richard Johnsson , tcp-ip@sri-nic.ARPA Subject: reissue: Core gateway routing bug found In-reply-to: Your message of Fri, 4 Apr 86 8:18:46 EST. Date: 04 Apr 86 11:02:06 EST (Fri) From: Mike Brescia I do not recall seeing a copy of this message returned from NIC. Thursday, April 3 is the first full day which should show sanity in the routing. Mike --- copy etc. --- To: tcp-ip@BBNCCV.ARPA Subject: Core gateway routing bug Date: 02 Apr 86 14:21:09 EST (Wed) From: tmallory@BBNCCV.ARPA A bug in the routing code of the LSI-11 gateway software has been isolated which is responsible for most of the problems experienced by users of the core gateways for either routing or packet transmission. The bug caused oscillating routing and added greatly to the amount of overhead traffic associated with routing, contributing to congestion on the Arpanet and Milnet. We have started patching all of the core gateways. This will take some time, though we hope to have the initial pass complete sometime tomorrow. It will take several days to update all of the load devices, so minor problems may reappear as gateways with old binaries are reloaded during the normal course of operations(power failures, etc.). Thank you all for your patience, Tracy Mallory BBNCC ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040406501600> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Fri 4 Apr 86 09:16:16-PST Received: from 156206300 by CSNET-RELAY.ARPA id a001213; 4 Apr 86 11:54 EST Return-Path: Received: by bu-cs.ARPA (5.31/4.7) id AA19510; Fri, 4 Apr 86 11:50:16 EST Date: Fri, 4 Apr 86 11:50:16 EST From: Ra Message-Id: <8604041650.AA19510@bu-cs.ARPA> To: security@red.rutgers.edu, tcp-ip@sri-nic.ARPA Subject: Thought on data encryption on networks Most of us run networks that do not have any encryption facilities (perhaps in theory, but not something a sys mgr can just turn on.) The problem is that the minute someone says 'hey, we need some encryption on this net' out come the macho data encryption types to explain to you that the only encryptions worth doing are too expensive (or complicated) to run, and then slink away again leaving you defenseless. Worse, you usually end up sitting thru a long scolding about how even if you implemented the best it is probably about to be broken or illegal or something. Oh, where is Arthur to slice this gordian knot? Meanwhile, Joe Cracker plugs his PC into your net, goes into promiscuous mode and has the most fun he can with his pants on. How outlandish would it be to come up with (I am probably not qualified to do this, although those that are probably won't) some sort of reasonably hard to crack stream oriented protocol? There has to be something in between clear text and you-need- a-cray-ethernet-board-but-it-cant-be-cracked. Suggestions? If your inclination is to say 'yer iggorant, this is solved' then how come none of the major O/S's have put it into their device drivers or wherever? -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040408290900> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Fri 4 Apr 86 10:30:07-PST Date: 4 Apr 1986 13:29:09 EST From: MILLS@USC-ISID.ARPA Subject: Re: Core gateway slot problem To: sy.Ken@CU20B.COLUMBIA.EDU, tcp-ip@SRI-NIC.ARPA cc: MILLS@USC-ISID.ARPA In response to the message sent Fri 4 Apr 86 00:14:07-EST from sy.Ken@CU20B.COLUMBIA.EDU Ken, I suspect BBN warriors may be too bloodied and weary to have announced a damage report, so please treat the following as an unofficial summary. When the core tables were expanded over 128 nets at least two bugs developed which reesulted in broken, oscillating routes within the core system. The problems then led to massive surges in gateway control traffic, as well as massive surges in redirects, not to mention aimlessly wandering datagrams carrying possibly useful user traffic. The situation became acute about a week ago, since when BBN has been feverishly updating all the core gateways, some of which are fiendishly hard to update (bubble memories, etc.). In the last couple of days things have improved, which is a good sign. The evidence is not hard to detect upon inspection of the EGP hop-count fields received by your EGP peer. You may notice the gateways wandering about the ARPANET or MILNET, as well as the high incidence of unusually large hop counts, not to mention the incidence of nets bobbing up and down. I have also noticed locally a marked increase in the incidence of ARPANET host-down messages, which may be realted to gateway reloading and the suspected traffic surges. My personal, unsubstantiated suspiciion suspicion is that instabilities in the core routing system due inconsistent tables (becasue of overflow) may have contributed significantly to the recent deterioration in performance. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040409030500> Received: from hudson.dec.com by SRI-NIC.ARPA with TCP; Fri 4 Apr 86 17:03:05-PST Date: Fri 4 Apr 86 17:03:05-PST From: "RAJENDRA K JAIN" Subject: Timeout algorithms for packet retransmissions To: "tcp-ip" Reply-To: "RAJENDRA K JAIN" Some time ago, there was a discussion of retransmission timeout algorithms on this forum. To those still interested in the topic I would like to point out that a survey of various algorithms and their problems was published recently: Jain Raj, "Divergence of Timeout Algorithms for Packet Retransmissions", IEEE Phoenix Conference on Computer Communications, Phoenix, AZ, March 27-28, 1986, pp. 174-179. The paper has 17 references to other papers on the subject. If you can't find the proceedings in your local library, I would be happy to mail you a reprint. Please send your U. S. Mail address to Jain@Hudson.DEC.Com *** Please do not directly reply to this message. *** Regards. -Raj Jain ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040409294700> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Fri 4 Apr 86 11:31:03-PST Date: 4 Apr 1986 14:29:47 EST From: MILLS@USC-ISID.ARPA Subject: Martians go home To: tcp-ip@SRI-NIC.ARPA Folks, I just caught a beta-4.3bsd coughing up ICMP Source Quench and claiming its address to be 127.0.0.1, but truly was on a net-128.5 subnet. This is yet again evidence supporting the well-travelled axiom that says to resist the urge to encroach on the net-address space as a substitute for intra-host routing mechaniss. I would like to suggest that a new net be conceived called DEAD-LETTER with net number 127.0. Volunteers are invited to submit gateways to that net. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040410265700> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Fri 4 Apr 86 15:51:23-PST Date: Fri, 4 Apr 86 15:26:57 EST From: Mike Muuss To: Ra cc: security@red.rutgers.edu, tcp-ip@sri-nic.arpa Subject: Re: Thought on data encryption on networks There are two levels of protection that you require: *) Link-level protection, to keep people from disrupting your local cable(s). *) End-to-End protection, to keep your conversation private even if some (or all) of the cables that carry the conversation are not protected. Link-level protection is a local issue -- if you can find a vendor who will sell you, say, Ethernet cards with 10 Mbps DES encryption built in, you could replace all the boards on your cable(s), and be protected. End-to-end protection will only work if both ends are expecting it. As there is presently no presentation level (ISO level 6) encryption defined for the TCP protocol family, you won't be able to use this very well. (Let me encourage you to consider how to optionally negotiate in end-to-end encryption on top of a TCP connection, and write up an RFC!) Also, note that this will probably have to be a software implementation, so that it can be specified for, and added to, all the existing TCP implementations. This may have a performance impact. There is also the issue of key management, which in a relatively static system like the DARPA Internet (as opposed to a tactical network) is fairly easy to implement (tedious, but possible). Note that for the military community, the BLACKER system addresses the end-to-end needs, as well as the key management issues. Link-level encryption is still the responsiblity of the individual link managers. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040510290000> Received: from STL-HOST1.ARPA by SRI-NIC.ARPA with TCP; Sat 5 Apr 86 14:33:23-PST Date: 5 Apr 1986 16:29-CST Sender: SNELSON@STL-HOST1.ARPA Subject: THOUGHT ON DATA ENCRYPTION ON NETWORKS From: SNELSON@STL-HOST1.ARPA To: TCP-IP@SRI-NIC.ARPA Cc: SNELSON@STL-HOST1.ARPA Message-ID: <[STL-HOST1.ARPA] 5-Apr-86 16:29:07.SNELSON> MIKE MUUSS THOUGHTS IN REPLY TO MKE BRESCIA ARE AS SUCCINCT AS THEY CAN GET. I AGREE. I HAVE BEEN USING THE HERMES MAIL ENCRYTION FEATURE FOR A LONG TIME AND IT ASSURES THE PRIVACY I DESIRE. I THINK THE DECISION MAKERS ARE GOING TO HAVE TO DEFINE THE DIFFERENCE BETWEEN INDIVIDUAL PRIVACY AND SECURITY OF INFORMATION. IT IS THE SAME OLD STORY. MANAGEMENT HAS TO DECIDE WHAT NEEDS PROTECTION, WHAT IS NICE TO HAVE AND WHAT DOESNT MEAN ZILCH. STEVE ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040604231900> Received: from MC.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Sun 6 Apr 86 06:21:42-PST Date: Sun, 6 Apr 86 09:23:19 EST From: "George J. Carrette" Subject: DADA & Encryption To: root%bostonu.csnet@CSNET-RELAY.ARPA cc: tcp-ip@SRI-NIC.ARPA, security@RED.RUTGERS.EDU In-reply-to: Msg of Fri 4 Apr 86 11:50:16 EST from Ra Message-ID: <[MC.LCS.MIT.EDU].875629.860406.GJC> There is a very simple and cheap encryption method that is also the only one known to be impossible to break. That is a one-time-key method. I have been using this by putting it into the applications such as FTP right at the places that streams are opened. The practical restriction of a one-time-key method is that you must generate a tape (or other secure medium) of enough random bytes and then send it by a trusted person to the machine you want to send messages to. Then, each time you send a byte to the other host XOR it with one from your key-tape. If you never repeat your key then nobody will be able to break the code except by stealing the key. If what you want to encrypt is mail traffic then a 1 gigabyte video disk would probably do for a quite a few months before you have to make and send another one. On the other hand, with a key as long as a gigabyte you could risk repeating it because a spy would have to be listening for quite a while to catch a repeat key, so it would take care of a random with an IBM-PC Unless of course he also had a gigabyte of video disk to write to in real time over the course of a few months. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040604354100> Received: from MC.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Sun 6 Apr 86 06:34:04-PST Date: Sun, 6 Apr 86 09:35:41 EST From: "George J. Carrette" Subject: FTP specs and conventions, LIST command To: DCP@SCRC-QUABBIN.ARPA cc: tcp-ip@SRI-NIC.ARPA, dcp@SCRC-STONY-BROOK.ARPA In-reply-to: Msg of Fri 4 Apr 86 10:19 EST from David C. Plummer Message-ID: <[MC.LCS.MIT.EDU].875631.860406.GJC> Of course it is extremely unfortunate that there is no spec for the format of the data in the LIST command. If only there was an RFC for a more reasonable file access protocol... ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040613544800> Received: from RED.RUTGERS.EDU by SRI-NIC.ARPA with TCP; Sun 6 Apr 86 15:54:53-PST Date: 6 Apr 86 18:54:48 EST From: Charles Hedrick Subject: Re: Core gateway slot problem To: Makey@LOGICON.ARPA cc: TCP-IP@SRI-NIC.ARPA Reply-To: se In-Reply-To: Message from "Jeff Makey " of 4 Apr 86 14:50:00 EST Message-ID: <12196772941.30.HEDRICK@RED.RUTGERS.EDU> Asymmetry in routing is quite easy to occur. In order to send a packet from us to you, we have to know about our own local gateway, and our local gateway has to know about some Arpanet/Milnet gateway. We always know about our local gateway (it is hardwired in our routing table), and I am fairly sure our gateway always knows about one of the core gateways. This means that we can always get packets to any host that is directly connected to the Arpanet or Milnet. In order to respond, your host must know about an Arpanet/Milnet gateway and that gateway must know about our local gateway. Again, you probably always know about some Arpanet/Milnet gateway. Recently, due to various bugs that have been discussed here enough, the Arpanet/Milnet gateways have had a tendency to lose track of external gateways such as ours. The result is that you can't get a packet back to us. When the core gateways lose track of us, we can often establish connections to machines that are directly on the Arpanet by sending them redirects pointing to our gateway. We haven't been very successful in doing this to sites behind a gateway. (The fact that we can do it at all is, of course, a security problem. As far as I can tell, anybody on the network can change around any 4.2 system's routing table in any way that he wants.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040702563100> Received: from nrl-aic by SRI-NIC.ARPA with TCP; Mon 7 Apr 86 04:58:20-PST Date: Mon, 7 Apr 86 07:56:31 est From: Gavin Hemphill Message-Id: <8604071256.AA08343@nrl-aic> To: tcp-ip@sri-nic Cc: drenet@drea-xx Subject: Performance Improvement? Well whatever was done re fixing bugs in the core gateways HAS made a difference. The performace between MILNET and CDNNET via ARPANET has NEVER been better than it has since the middle of last week. I don't have any quantitative measurements (though someone with more expertise might want to gather the stats), but the percieved response to Telnet and FTP has been super G++ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040704554700> Received: from harvard.HARVARD.EDU by SRI-NIC.ARPA with TCP; Mon 7 Apr 86 10:14:52-PST Received: from localhost by harvard.HARVARD.EDU; Mon, 7 Apr 86 13:15:49 EST To: tcp-ip@sri-nic.ARPA Subject: Excelan TCP/IP boards for PC/ATs Organization: S.P. Dyer Computer Consulting, Cambridge MA Date: Mon, 07 Apr 86 13:15:47 -0500 From: /Steve Dyer Does anyone have any direct experience with the Excelan 205 ethernet controllers and EXOS 8111 software for the IBM PC and AT? I'm interested in exploring ways to interconnect a bunch of PCs, some running XENIX, others running DOS. After exploring the market, it looks like Excelan may be the only solution available right now, given that XENIX access is necessary. -- Steve Dyer dyer@harvard.HARVARD.EDU {bbncca,bbnccv,harvard,ima,ihnp4}!spdcc!dyer ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040706442000> Received: from nrl-aic by SRI-NIC.ARPA with TCP; Mon 7 Apr 86 08:44:44-PST Date: Mon, 7 Apr 86 11:44:20 est From: Gavin Hemphill Message-Id: <8604071644.AA11396@nrl-aic> To: tcp-ip@sri-nic Cc: drenet@drea-xx Subject: ooops, I meant to say DRENET Date: Mon, 7 Apr 86 07:56:31 est From: Gavin Hemphill Well whatever was done re fixing bugs in the core gateways HAS made a difference. The performace between MILNET and DRENET (not CDNNET) via ARPANET has NEVER been better than it has since the middle of last week. I don't have any quantitative measurements (though someone with more expertise might want to gather the stats), but the percieved response to Telnet and FTP has been super G++ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040711283100> Received: from Dewey.UDEL.EDU by SRI-NIC.ARPA with TCP; Mon 7 Apr 86 16:54:16-PST Received: from localhost by Dewey.UDEL.EDU id a002829; 7 Apr 86 19:48 EST TO: tcp-ip@dewey.udel.EDU SUBJECT: Flooding Date: Mon, 07 Apr 86 19:48:31 -0500 From: Gurudatta Parulkar It seems that some kind of flooding was explored as routing strategy for ARPANET long back. But it never became popular. I would like to get some pointers to papers, reports, RFCs, etc. which talk about this flooding and also talk about why it was given up. Could somebody help me with these pointers ? We at University of Delaware are exploring the possibility of using flooding in a LAN. Are there any other groups looking into such a possibility ? Please send me a note. Thank you very much. -guru :______________________________________________________________________________ :Gurudatta M. Parulkar :University of Delaware :Department of Computer and Information Sciences :Newark, DE 19716 : :ARPA: parulkar@dewey.udel.EDU :CSNET: parulkar%dewey.udel.EDU@csnet-relay :UUCP: ...!harvard!parulkar@dewey.udel.EDU :______________________________________________________________________________ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040714334900> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Mon 7 Apr 86 16:37:04-PST Date: Mon, 7 Apr 86 19:33:49 EST From: Mike Muuss To: Gavin Hemphill cc: tcp-ip@sri-nic.arpa, drenet@drea-xx.arpa Subject: Re: Performance Improvement? I concur. A quick test to Berkeley showed roughly 2 second RTT, which is much better than before. Not great, but usable. Thanks! From BRL-VGR: ----monet.berkeley.edu PING Statistics---- 59 packets transmitted, 57 packets received, 3% packet loss round-trip (ms) min/avg/max = 1090/1953/5500 -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040715031000> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Mon 7 Apr 86 17:07:40-PST Date: Mon, 7 Apr 86 20:03:10 EST From: Mike Muuss To: PADLIPSKY@usc-isi.arpa cc: TCP-IP@sri-nic.arpa Subject: Encrypt at which level? Mike Padlipsky asked why I thought Level 6 was the right place to implement encryption, and even though my answer is sketchy, I figured I'd share it with everybody. It seems to me that code translation, e2e encryption, and some sort of standard data compression ought to be available as "protocol family" services to *any* application, just for the asking. At the right point in the dialog (perhaps before the first data byte, perhaps after some initial exchange), the user program should make some kind of call to the next lower level interface and say "please begin encrypting with a key of XXX". The exact implementation point of e2e encryption isn't REALLY important though, as long as a good place for it in the protocol suite exists, and most everybody can be made to agree to do it there. It could be provided by a library function, or as direct code within each application, or as an operating system capability, I dont really care, but I feel that some basic level of encryption should be available as a primitive capability. It would be nice, for example, to consider an extention to the SMTP protocol to go something like: 220 brl-sem Server SMTP (Complaints/bugs to: mmdf@brl.arpa) HELO brl-sem 250 brl-sem CRYPT 250 encryption with our common key being enabled. MAIL FROM: 250 OK and thus have both the address and data portion encrypted (as an option). TELNET IAC-DO-ENCRYPT etc etc might also be nice. Government sites handling what used to be called "For Official Use Only (FOUO)" data and researchers with unpublished data to exchange would be the most likely candidates to desire this type of capability. The key management issues would be a drag. Host-pair, Group-pair, User-pair basis, or what? How to update? What to do when the keys don't match? Handling the user interface issues would also take thought and work, but encryption is something that WOULD be useful to have. How this fits together with Multi-Level Secure hosts interfacing to BLACKER isn't clear either. The simple answer is: "not at all -- BLACKER is different", yet having BLACKERs protecting gateways to LANs *still* does not handle the complete end-to-end requirement. BLACKERs protecting hosts would. I need to think about this more. -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040803030000> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Tue 8 Apr 86 11:03:56-PST Date: 8 Apr 1986 11:03-PST Sender: WESTINE@USC-ISIB.ARPA Subject: Flooding From: postel@usc-isib.arpa To: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISIB.ARPA] 8-Apr-86 11:03:43.WESTINE> The current IMP level routing procedure is basically a flooding type algorithm. Here are two references for further information. --jon. ----- McQuillan, J. M., I. Richer, E. Rosen "An Overview of the New Routing Algorithm for the Arpanet," Proceedings of IEEE, Spring 1979. "The New Routing Algorithm for the ARPANET," IEEE Transactions on Communications, May 1980, pp. 711-719. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040804232500> Received: from ames-nas.ARPA by SRI-NIC.ARPA with TCP; Tue 8 Apr 86 12:20:08-PST Date: Tue, 8 Apr 86 12:23:25 pst From: lekash@AMES-NAS.ARPA (John Lekashman) Message-Id: <8604082023.AA26744@ames-nas.ARPA> Received: by ames-nas.ARPA; Tue, 8 Apr 86 12:23:25 pst To: tcp-ip@sri-nic.ARPA Subject: clogged queues We have a machine that is reading IP packets and occasionally getting clogged with data, some for undefined addresses, some for processes being slow. It is on a LAN, (hyperchannel to be precise.) I'm looking for advice on which end of the queue to have the driver throw things away when its full. Both cost the same. thanks john ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040804400000> Received: from ACC.ARPA.ARPA (ACC.ARPA) by SRI-NIC.ARPA with TCP; Tue 8 Apr 86 12:46:24-PST Date: 8 Apr 86 12:40:00 PST From: Subject: alias... To: "hunt" cc: arpanetmgr@ddn1,tcp-ip@sri-nic Reply-To: Doug, Who is the "Arpanet Program Manager" at the DDN PMO?? What group does he/she fall into? Thanks, Gary ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040804413100> Received: from BBN-VAX.ARPA by SRI-NIC.ARPA with TCP; Tue 8 Apr 86 08:58:22-PST Date: Tue, 8 Apr 86 9:41:31 EST From: Jim Berets To: Mike Muuss cc: tcp-ip@sri-nic.ARPA Subject: Re: Encrypt at which level? Mike, A little bit of looking through my file cabinet revealed a "draft proposed ANSI standard for Presentation Layer Encryption" dated April, 1984. "The primary purpose ... is to define the functional and procedural characteristics of cryptographic operations ... on behalf of a requesting application layer entity (End User)." At the time, this standard was being developed under the auspices of ANSI X3T1. Interested parties could probably obtain updated copies from ANSI. Jim ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040809340000> Received: from sri-tsc.arpa by SRI-NIC.ARPA with TCP; Tue 8 Apr 86 17:36:23-PST Received: by sri-tsc.arpa at Tue, 8 Apr 86 17:35:00 pst From: Aki Shohara Message-Id: <8604090135.AA08618@sri-tsc.arpa> Date: 8 Apr 1986 1734-PST (Tuesday) To: se Cc: TCP-IP@SRI-NIC.ARPA, Makey@LOGICON.ARPA Subject: Re: Core gateway slot problem In-Reply-To: Your message of 6 Apr 86 18:54:48 EST. <12196772941.30.HEDRICK@RED.RUTGERS.EDU> This message erroneously routed to me. aki shohara. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040810011900> Received: from ucl-cs by SRI-NIC.ARPA with TCP; Tue 8 Apr 86 02:19:09-PST Date: Tue, 8 Apr 86 9:01:19 BST From: Steve Kille To: mike@brl.arpa cc: tcp-ip@sri-nic.arpa Subject: Re: Encrypt at which level? I agree that for many cases, encypting at level 6 seems correct. I note that the ISO presentation has hooks for this. However, this is not sufficient for store and forward services (or any spooled service) such as mail. Here, to obtain end to end encryption, it will need to be at the application level. Marshall Rose wrote a very good paper on the mail issues for the Washington 85 IFIP 6.5 Symposium (published North Holland). It also describes an implementation. Steve ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040810144400> Received: from bbnccj.arpa by SRI-NIC.ARPA with TCP; Tue 8 Apr 86 12:19:17-PST Date: Tue, 8 Apr 86 15:14:44 EST From: Doug Hunt Subject: note on recent arpanet performance problem To: tcp-ip@sri-nic.arpa Cc: arpanetmgr@ddn1.arpa, hunt@bbnccj.arpa Status of Remedial Action for Arpanet Performance Problems This note describes an Arpanet performance problem, together with the steps being taken to correct it. The discussion covers (1) the symptoms, (2) an explanation of the problem, (3) the recommended solution, and (4) a timetable for implementing the solution. This note concludes with a recommended procedure for reporting Arpanet performance problems to the Arpanet Manager at the DDN Program Management Office. The Symptoms Basically, the Arpanet appears sluggish -- interactive as well as bulk transfer traffic can be subjected to very large delays. This can manifest itself as an overflowing typeahead (input) buffer to a TAC, or a file transfer that takes much longer than should be required for the file size and data path bandwidths involved. The Problem The BBNCC Network Analysis Group considered a number of hypotheses that could explain the sluggish network behavior. They have found that much of the performance degradation in the Arpanet can be traced to host blocking owing to a lack of per-connection resources in PSNs. This blocking would exhibit the symptoms described above. A host must have a PSN allocate to it certain resources in order to establish and use a host-host network connection. To establish the connection, both the source and destination hosts must be allocated "connection blocks" by their respective source and destination PSNs. Having done so, to send a message a host must be allocated a "message number". The connection blocks and message numbers are resources internal to the PSN; until a PSN allocates these resources to a host, the host is blocked. Analysis of the Arpanet in recent months shows that, for many PSNs, there is excessive blocking of attached hosts because of a shortage of connection blocks. Twelve PSNs in particular exhibit this problem consistently. These PSNs are: SRI2, RCC5, STAN11, DCEC20, ISI22, ISI27, PURDU37, SRI51, LBL68, SAC80, BBN82, and WISC94. Alleviating the connection block shortage problem for these and other Arpanet PSNs should provide a significant improvement in network performance as seen by hosts. The Solution The PSN release used on the Arpanet, "Release 3/4", supports only 73 connection blocks in each direction -- enough to support 73 full-duplex streams. Measurements have shown that, for many PSNs including those listed above, there is excessive contention for these 73 connection blocks. Analysis of the traffic patterns of the attached hosts indicates that increasing the number of connection blocks to 255 -- the number supported in PSN Release 5 -- should greatly reduce the likelihood of hosts blocking owing to a connection block shortage. The Timetable On March 12, the DDN Program Management Office (PMO) issued a "Network Change Directive", authorizing the installation of PSN release 5 to most Arpanet sites prior to May 2, 1986. A few sites will not receive the new release until later, since those sites have not yet had the hardware upgrade necessary to support PSN release 5. Those sites with the most serious performance problems will be the first sites to receive the new release. PSN release 5 has already been subjected to extensive operational use, as the DDN PMO has previously authorized the installation of PSN release 5 on other networks, such as the MILNET. Recommended Procedure for Reporting Arpanet Performance Problems In order to facilitate resolution of performance problems on the Arpanet it is important that the Arpanet Manager at the DDN PMO be informed of problems noticed by Arpanet users. Currently, the Arpanet Manager at the DDN PMO is Captain Callaway. Arpanet users are encouraged to include this office, with mailbox "arpanetmgr 'at' ddn1", on network mail regarding Arpanet problems. The description of the problem should be as detailed as possible. Include information such as: 1. description of problem 2. time of day problem occurs 3. duration of problem 4. host you are using 5. gateway you are using (if applicable) 6. host you are attempting to reach 7. general description of computing you are engaged in -- e.g., "I am transferring files from my host to host XYZ. Approximate size of file is 64k bytes". 8. provide any other information you think would be helpful in resolving the problem. Since the DDN PMO establishes the policies for operating and managing the Arpanet, it is important that the PMO Arpanet Manager be aware of problems experienced by Arpanet users. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040811071700> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Tue 8 Apr 86 13:07:53-PST Date: 8 Apr 1986 16:07:17 EST From: PADLIPSKY@USC-ISI.ARPA Subject: Re: Encrypt at which level? To: mike@BRL.ARPA cc: TCP-IP@SRI-NIC.ARPA In response to your message sent Mon, 7 Apr 86 20:03:10 EST Mike-- Oh, dear, now you've gone and made me violate my vow not to work up a sweat over ISOmetrics in public anymore.... After several drafts that got too esoteric, I'll try to confine myself to a couple of brief (possibly cryptic, but no pun is intended) observations: In the first place, by Sutton's Law it does make sense to "floogle" at L6; it's where the data are. However, doing so would leave the lower L's headers unfloogled, which I don't believe is consistent with what its proponents seemed to think "end-to-end encryption" implied back in the bygone days when I occasionally talked to them (informally, of course). Let's pretend you meant "data encryption." (Or not, since it's more or less a purist's point, along the lines of trying to prevent anybody who has a different set of associations/connotations with/for E-E E from being misled.) In the second place, putting floogling at L6 gives rise to all sorts of questions I don't know the answers to about the nature of the L7-L6 interface (which led me down a devious route I don't want to go into here to a perception of still another architectural inelegancy in the Seven Story Highrise). For a while, I thought L6 floogling would require L6 to take inappropriate cognizance of L7's distinction between control and data. Then I thought that floogling didn't but being able to virtualize and devirtualize the data did. Now from Steve's response I begin to wonder if I was right in the first place (and I still think I'm part right in the second place). Perhaps Steve will respond further if I just assert that it's not obvious to me that you HAVE TO floogle at L7, unless it has something to do with needing the control information to be in the clear while the data are still encrypted (or befloogled, as the case may be). Anyway, as of now I wish I hadn't asked...and if I let myself go on any longer I imagine everybody else will wish so too, so I'll steer clear of such fun topics as whether floogled sessions, transport connections, and network-layer connectionless whatevers (associations, maybe) are or aren't meaningful, muchless the possible significance of floogling at the top, middle, or bottom of a layer. (But it would be delightful to take them up one at a time if anybody else feels like it.) cheers, map P.S. In case anybody's curious, Sutton was "Willie-the-Actor," and when asked why he robbed all those banks he's alleged to have replied "Because that's where they keep the money." ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040816581800> Received: from guenevere.Purdue.EDU by SRI-NIC.ARPA with TCP; Tue 8 Apr 86 18:58:02-PST Message-Id: <8604090258.AA10893@guenevere.Purdue.EDU> Received: by guenevere.Purdue.EDU; Tue, 8 Apr 86 21:58:22 EST To: tcp-ip@sri-nic.arpa Subject: Ethernet monitor wanted Date: 08 Apr 86 21:58:18 EST (Tue) From: "Thomas Narten" We were recently struck by an unusual and deadly problem that killed our Ethernet and many of the machines on it. The problem was apparently caused by a piece of hardware that didn't take a power surge well. The problem consisted of two things: The net became jammed with bogus traffic (not legal packets), and lots of corrupted packets that had correct Ethernet checksums in them. The jamming was intermittent, and temporary, but the effects of the corrupted packets were felt for quite a while. IP packets were OK because they were checksummed at higher layers. During one 3 hour period, one of our machines recorded over 200,000 IP checksum errors. Unfortunately, ARP relies on the Ethernet checksum and hence the ARP tables became severely corrupted. You can imagine the confusion this caused. (i.e. connections break, the ability to reach a host comes and goes, ...) Conclusion (as noted in this mail list before): its tough debugging a network without tools. We were fortunate enough to have MIT's PC monitoring program that plugs into the Ethernet and prints out everything it sees. It was extremely useful to us. In using it, however, I thought a more general monitoring program would be extremely useful (even during times the network is functioning normally). I am wondering what (if any) other sorts of "promiscuous reader" programs have been written and if they are available for use. Things that would be useful include: Having massive statistics gathered over a period of time. It would be nice if the program could be run for an hour/day/week to accumulate information about numbers/types/sizes of packets. This information could (perhaps later) be broken down in such a way that one could see all the stats for a given source address, or a given destination (i.e. broadcast would be interesting), packet type (i.e. protocol), etc. It would also be useful to have an interactive, screen oriented program that lets you select what you see. This would be most useful when tracking down problems. Do any such programs exist? What are there capabities? What other sorts of things would be useful to include? Thomas Narten ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040819441300> Received: from BORAX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Tue 8 Apr 86 21:47:18-PST Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Wed, 9 Apr 86 00:44:13 est Date: Wed, 9 Apr 86 00:44:13 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Message-Id: <8604090544.AA24346@BORAX.LCS.MIT.EDU> To: narten@Purdue.EDU Cc: tcp-ip@sri-nic.arpa In-Reply-To: "Thomas Narten"'s message of 08 Apr 86 21:58:18 EST (Tue) Subject: Ethernet monitor wanted I'm extending MIT's "netwatch" monitor for my company. Right now I'm planning on adding the features you've mentioned (long term statistics gathering), plus some more real time statistics gathering, and error indications. We'll be announcing the new product at the end of the month. I'm also thinking about adding a really neat mode for TCP where it will pick up all the TCP packets that go by for a connection and analyze them, reporting things like out of sequence packets, retransmitted packets, and detecting problems like silly window syndrome. I don't think it should be too incredibly difficult to do. Maybe it'll show us how bad all of our TCP's *really* are... I'd also really like to hear from other people on what features they think would be useful. What are the most common protocol failures you find? What would you most like to be able to do with an independent monitor while debugging a new protocol implementation? - john romkey ftp software ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040821000400> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Wed 9 Apr 86 00:45:04-PST Received: from 156206300 by CSNET-RELAY.ARPA id a021910; 9 Apr 86 3:01 EST Return-Path: Received: by bu-cs.ARPA (5.31/4.7) id AA24920; Wed, 9 Apr 86 02:00:04 EST Date: Wed, 9 Apr 86 02:00:04 EST From: Ra Message-Id: <8604090700.AA24920@bu-cs.ARPA> To: narten@purdue.edu, tcp-ip@sri-nic.ARPA Subject: Re: Ethernet monitor wanted There is a program, 'traffic' that runs on SUN3s (it comes with the SUN release tape) that does at least part of what you want. It uses the bitmap display to draw nice graphs of what's going on and from/to whom. There are various panels that can be selected for viewing. In addition they have a program 'etherfind' that takes a classic "ya hadda be there since V6 or you're lost" 'find' kinda pattern and dumps ethernet info like vmstat to any terminal, it's also very helpful (eg. I could hear a diskless node crying for a rarp and verify that no one was answering, and, past that, watch a tftpboot fail, all ultimately caused by set up files being wrong, but it was nice to see something.) -Barry Shein, Boston University (that reference is to V6 UNIX of course...sorry) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040822222600> Received: from mouton.ARPA by SRI-NIC.ARPA with TCP; Wed 9 Apr 86 00:56:18-PST Received: by mouton.ARPA (4.12/4.7) id AA05134; Wed, 9 Apr 86 03:22:26 est Date: Wed, 9 Apr 86 03:22:26 est From: karn@mouton.ARPA (Phil R. Karn at mouton.ARPA) Message-Id: <8604090822.AA05134@mouton.ARPA> To: tcp-ip@sri-nic.arpa Subject: Re: Encrypt at which level? I thought this issue was resolved long ago -- if you're really paranoid you need to do it twice, on an end-to-end basis (transport or above) to protect the information in the message AND on a hop-by-hop basis (link level) to guard against traffic analysis. Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040823542500> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 9 Apr 86 07:57:02-PST Date: 9 Apr 1986 07:54:25 PST Subject: Re: Ethernet monitor wanted From: Dan Lynch To: "Thomas Narten" cc: tcp-ip@SRI-NIC.ARPA, LYNCH@USC-ISIB.ARPA In-Reply-To: <8604090258.AA10893@guenevere.Purdue.EDU> There is a commercial product out now called the LANalyzer, from Excelan, that does much of what you want and has even more features. In order to be sure of capturing all packets it comes packaged as a board that plugs into an IBM Xt (or above or a compatible, of course) plus the software to drive the board and display the packet info in many different formats. IN addition to sniffing for anything you can imagine it can also generate packets of any variety and thus allow one to see how a target system performs under known "assault". The baord plus software goes for under $10K. They can be reached at 408-434-2300 for more info. Dan ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040903160000> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Thu 10 Apr 86 17:28:28-PST Received: from northeastern by csnet-relay.csnet id ag20184; 10 Apr 86 20:18 EST Date: Wed, 9 Apr 86 08:16 EST From: JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA To: tcp-ip@sri-nic.ARPA, johnson%northeastern.csnet@CSNET-RELAY.ARPA Subject: Re: LAN flooding. In response to: :Gurudatta M. Parulkar :University of Delaware :Department of Computer and Information Sciences >We at University of Delaware are exploring the >possibility of using flooding in a LAN. Are there >any other groups looking into such a possibility ? >Please send me a note. Maybe I missed something here. The LANs I know of all have a broadcast address available to them. Why would you want to flood a LAN when one packet will do? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040903420000> Mail-From: MKL created at 10-Apr-86 17:32:02 Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Thu 10 Apr 86 17:29:49-PST Received: from northeastern by csnet-relay.csnet id ah20184; 10 Apr 86 20:19 EST Date: Wed, 9 Apr 86 08:42 EST From: JOHNSON%northeastern.csnet@CSNET-RELAY.ARPA To: tcp-ip@sri-nic.ARPA, johnson%northeastern.csnet@CSNET-RELAY.ARPA Subject: TCP/IP and DECNET We at Northeastern University have a growing contingent of both TCP/IP nodes (UNIX) and DECNET nodes (VMS). I had a brilliant idea the other day. Why not get ULTRIX to translate between TCP/IP and DECNET. This would certainly seem a logical place to do it because ULTRIX understands about both. You would also only need one of these nodes on a network to do the gateway job of translation. A WONDERFUL idea right? Guess what ULTRIX can't do folks. Apparently with a funny sendmail.cf you CAN route mail from the TCP/IP world to DECNET but not back and FTP is just NOT possible. Remote login isn't doable either. Why is the world so perverse? Why do brilliant ideas come stillborn? I didn't think I wanted much. When I was asking about various vendor's TCP/IP for VMS awhile back, nobody really liked any vendor software. I heard all kinds of horror stories right and left. I thought here would be a chance to get both worlds in one box but NOOOOO. (cry cry sob sob *sigh*). Does anybody out there know of someone trying to solve the problem of getting ULTRIX to do the right thing between TCP/IP and DECNET? Is DEC maybe? Please (whimper whimper)? Chris Johnson Northeastern University johnson@northeastern.csnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040903445000> Received: from decwrl.DEC.COM by SRI-NIC.ARPA with TCP; Wed 9 Apr 86 17:40:13-PST Received: by decwrl.DEC.COM (4.22.03/4.7.34) id AA07649; Wed, 9 Apr 86 17:39:52 pst Received: from apolling.imagen.uucp (apollonet-e.ARPA) by imagen.uucp (4.12/Imagen-1.1) id AA28633; Wed, 9 Apr 86 11:45:26 pst Return-Path: Received: by apolling.imagen.uucp (4.12/Imagen-1.1) id AA00029; Wed, 9 Apr 86 11:44:50 pst Date: Wed, 9 Apr 86 11:44:50 pst From: imagen!geof@decwrl.DEC.COM (Geof Cooper) Message-Id: <8604091944.AA00029@apolling.imagen.uucp> To: narten@Purdue.EDU Cc: tcp-ip@sri-nic.ARPA Reply-To: imagen!geof@decwrl.dec.com Phone: (408) 986-9400 (work) Postal-Address: IMAGEN, 2650 San Thomas Expressway, Santa Clara, CA 95052 Subject: Re: Ethernet monitor wanted > I am wondering what (if any) other sorts of "promiscuous reader" > programs have been written and if they are available for use. I believe that Excelan makes such a device. - Geof ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040905223700> Mail-From: OLE created at 9-Apr-86 13:23:51 Date: Wed 9 Apr 86 13:22:37-PST From: Ole Jorgen Jacobsen Subject: Re: Ethernet monitor wanted To: LYNCH@USC-ISIB.ARPA cc: narten@PURDUE.EDU, tcp-ip@SRI-NIC.ARPA, OLE@SRI-NIC.ARPA In-Reply-To: Message from "Dan Lynch " of Wed 9 Apr 86 07:54:25-PST SRI-NIC: (415) 859-4536 Home: (415) 325-9427 Beeper: (415) 496-9427 Message-ID: <12197531668.20.OLE@SRI-NIC.ARPA> CMC (Communication Machinery Corporation) of Santa Barbara has an Ethernet monitor, the DRN-1700 (aka "Spidermonitor" from Scotland). Contact Russ Sharer (805) 963-9471 for details. Ole ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986040919420000> Received: from Dewey.UDEL.EDU by SRI-NIC.ARPA with TCP; Wed 9 Apr 86 23:53:20-PST Received: from usc-isi.arpa by Dewey.UDEL.EDU id a016865; 10 Apr 86 0:47 EST Date: 10 Apr 1986 00:42-EST Sender: CERF@usc-isi.ARPA Subject: Re: Flooding From: CERF@usc-isi.ARPA To: parulkar@dewey.udel.EDU Cc: tcp-ip@dewey.udel.EDU Message-ID: <[USC-ISI.ARPA]10-Apr-86 00:42:11.CERF> In-Reply-To: The message of Mon, 07 Apr 86 19:48:31 -0500 from Gurudatta Parulkar Flooding is used in the current Shortest Path First Routing algorithm. Check with Steve Cohn at BBN for references. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041004020000> Received: from sri-tsc.arpa by SRI-NIC.ARPA with TCP; Thu 10 Apr 86 12:02:41-PST Received: by sri-tsc.arpa at Thu, 10 Apr 86 12:02:30 pst From: lewis Message-Id: <8604102002.AA25550@sri-tsc.arpa> Date: 10 Apr 1986 1202-PST (Thursday) To: tcp-ip@sri-nic Cc: Subject: Re: Ethernet monitor wanted For those with SUN3 workstations, there is a graphical Ethernet watch program. You start up the rpc.etherd in the background, and the user program is called "traffic" in usr/bin I think. It of course uses permiscuous mode. The user is able to split his window into several displays for parsing packets into time varying histograms by protocol, host, or destination, the 8 busiest sources are displayed. You can also view load, ei 100% is 10 Megabits/sec. It does not keep long term statistics. There is another SUN3 etherwatch program with a non-graphical interface, and if it collects statistics, I will post a description after I look at it. -Mark Lewis ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041004143800> Received: from bbn-clxx.arpa by SRI-NIC.ARPA with TCP; Thu 10 Apr 86 06:29:44-PST Date: Thu, 10 Apr 86 9:14:38 EST From: Ken Lebowitz Subject: VMS TCP/IP on a serial line? To: tcp-ip@sri-nic Can anyone tell me if Wollongong's networking code for VMS is capable of performing TCP/IP through a serial line device? Has anyone out there actually done this (I seem to remember somebody having done this on a UNIX host)? Thanks, Ken Lebowitz BBN Laboratories ARPA: kjl@bbn-clxx.arpa or kjl@clxx.bbn.com UUCP: ...!{decvax,ihnp4,harvard}!bbncca!kjl CSNET: kjl%bbn-clxx.arpa@csnet-relay ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041011062200> Received: from BBNCC5.ARPA by SRI-NIC.ARPA with TCP; Thu 10 Apr 86 13:47:15-PST To: Bill Chiarchiaro cc: tcp-ip@sri-nic.ARPA Subject: Re: ARPAnet Usage In-reply-to: Your message of Sat, 15 Mar 86 22:01:11 est. <8603160301.AA15692@ll-vlsi.ARPA> Date: 10 Apr 86 16:06:22 EST (Thu) From: Frederick E Serr During the second week of December, 1985, the busiest node on the ARPANET was RCC5, here at BBN. It handled the following numbers of packets per second: From Into Out Hosts Hosts Trunks Average 16 21 77 Peak Hour 18 28 77 The first row is the average over five days (Mon-Fri), 24-hours per day. The second row is for a busy hour (identified as a peak for the entire net, it may not be THE peak for this node). During this same hour packet rates of over 100/sec out internode trunks were observed on other nodes. This node has six busy hosts on it, including several gateways. I hope that this somewhat delayed response still provides some useful info. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041012451600> Received: from trantor.UMD.EDU by SRI-NIC.ARPA with TCP; Thu 10 Apr 86 14:44:50-PST Received: by trantor.UMD.EDU (5.5d/umd.04) id AA04291; Thu, 10 Apr 86 17:45:16 EST Date: Thu, 10 Apr 86 17:45:16 EST From: Louis A. Mamakos Message-Id: <8604102245.AA04291@trantor.UMD.EDU> To: tcp-ip@sri-nic.arpa In-Reply-To: mills@dcn6.arpa's message of 10-Apr-86 17:30:19-UT Subject: Wollongong problem Ah yes, the TELNET end-of-line discussion surfaces again. I inquired about this on the list a few years ago while I was writing the TELNET server for our Sperry 1100 host. The feeling at that time was that the correct action for an end-of-line was the CR LF sequence. This works out pretty well since the Sperry machine is a line at a time type machine. The TELNET session is symmetric; it sends lines terminated by CR LF to you, and you reply in turn. It seems that a problem like this should be fairly easy to accomodate in my TELNET server, but what do we have standards for? We have this same problem with our Wollongong host, and have beat on the vendor to fix this. The user TELNET with Berkeley 4.2 was damaged in a similar fashion and it was a simple 3 line fix to the program. Its been more than a year, and the Wollongong people have yet to address THIS simple problem; let along hard ones like subnetting. This seems to have degenerated into a flame; sorry about that. I just wanted to make the point that the fuzzballs are not the only hosts that are upset by this particular bug. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041012571200> Received: from proteon.arpa by SRI-NIC.ARPA with TCP; Thu 10 Apr 86 15:02:33-PST Date: Thu, 10 Apr 86 17:57:12 EST From: jas@proteon.arpa Subject: naked CR's To: tcp-ip@sri-nic.arpa The server telnet in Ultrix-32m V1.1 has the same bug. My local user telnets can cope, but only after they recieve one more character. Unfortunately, smart editors on Unix send naked CR to implement "go-to-beginning-of-line", so you lose big with this sever telnet. (I presume this is a standard raw 4.2BSD bug, and that DEC fixes it in V1.2.) ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041013443500> Received: from GW.UMICH.EDU by SRI-NIC.ARPA with TCP; Thu 10 Apr 86 05:46:12-PST Date: 10-Apr-86 13:44:35-UT From: hwb@gw.umich.edu Subject: Packet switch rates. To: tcp-ip@sri-nic.arpa cc: hwb@GW.UMICH.EDU Hi: What packet transfer rates are people observing in IP switches these days. I would be interested in some figures of dedicated switches as well as through machines that also serve a host function. A good example would be a packet rate per second for a switch that connects two Ethernets, but other examples would be appreciated, too. As I think that this is of general interest I would suggest to post the examples to this list. -- Hans-Werner Braun ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041013550000> Received: from A.CS.CMU.EDU by SRI-NIC.ARPA with TCP; Thu 10 Apr 86 15:53:37-PST Date: 10 Apr 86 18:55 EST From: Rudy.Nedved@A.CS.CMU.EDU To: tcp-ip@sri-nic.arpa Subject: telnet Message-Id: <10Apr86.185539.EN0C@A.CS.CMU.EDU> Wait until you try to use the binary option in connection with telnet. CMU has lots of special terminals that use the 8th bit....but there are two communities of busted telnet servers. 4.2BSD puts you in "raw" mode instead of just passing the 8th bit thru and some IBM sites that use EBCDIC (sic?) use the BINARY option to mean no translation [I don't remeber seeing an TELNET option to change from NVT ASCII to EBCDIC.]. Given that the majority of machines around here implement 4.2BSD telnet, we are going to "hack" our systems to send out IAC WILL BINARY to indicate that the system is NOT a busted 4.2BSD site. I hope 4.3 does not have this bug too and that they finally fix the EOL problems. I can understand how the old telnet servers and user programs got incorrectly implemented but any future servers should be fixed since the specifications for the options and telnet have been cleaned up alot. You just have to read them VERY carefully and completely. The only implementation of telnet that seems to be ALMOST correctly implemented is TOPS-20 telnet. (Maybe?) there is a race condition bug for the option negotiations (it loses information) and some questions about CR NUL handling which implies a bare CR versus CR LF. -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041013591400> Mail-From: MKL created at 10-Apr-86 19:03:58 Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Thu 10 Apr 86 19:02:45-PST Received: from rpics by csnet-relay.csnet id ab21311; 10 Apr 86 21:54 EST Received: by rpics.RPI (4.30/4.7) id AA20956; Thu, 10 Apr 86 18:59:14 EST Date: Thu, 10 Apr 86 18:59:14 EST From: Martin Schoffstall To: kjl%bbn-clxx.arpa@csnet-relay.arpa, tcp-ip%sri-nic.arpa@csnet-relay.arpa Subject: Re: VMS TCP/IP on a serial line? Cc: weltyc%rpicie.csnet@CSNET-RELAY.ARPA well.. we have been trying to do this with help from the TWG development group. We just applied the latest vms patches to make it compatible with rick@seismo's SL software but it didn't work. We are going to modify the SL code shortly if we can't get VMS "fixed". marty ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041017060000> Mail-From: MKL created at 10-Apr-86 23:07:03 Received: from SIMTEL20.ARPA by SRI-NIC.ARPA with TCP; Thu 10 Apr 86 23:06:15-PST Date: Fri, 11 Apr 1986 00:06 MST Message-ID: From: "Frank J. Wancho" To: TCP-IP@SRI-NIC.ARPA cc: WANCHO@SIMTEL20.ARPA Subject: PCs and TACs Perhaps because this host holds the largest collection of anonymously FTPable "public domain" software on the Internet, we are probably indirectly responsible for a high volume of not only those FTP transfers, but also high volumes of down and uploads between many hosts and users with PCs on TACs. Also, with widely available PCs, we have found many people downloading entire mail files and composing responses offline for later uploads and adding to the volume of such traffic. Most of these transfers are done using some variant of the Christensen Protocol, commonly misnamed "xmodem" protocol, or KERMIT. Although the KERMIT protocol allows for user-settable packet sizes, the arguably more efficient Christensen protocol does not. It is fixed at 132- or the newer 133-byte blocks. This presents a problem at any speed above 300 bps with TAC input buffers defaulted to 64, and it is not so simple to get DCA to make a change for selected ports (it used to take a phone call). At one time there was some work in progress to implement one of several protocols at the TAC level. That effort seems to have died. We feel that such an effort such be revisited due to the proliferation of these PCs and what currently amounts to packet/character file transfers loading the network. Could it be possible that the C/30 TACs currently in use might be upgraded C/30e's? If so, then, depending on the amount of extra memory available, it might be possible to seriously consider implementing the basic protocols of either KERMIT, Christensen, or maybe even X.PC at the TAC level. In any event, we would like to see the input buffer pool on each TAC redistributed to the *active* ports. In many cases, the default input buffer size for each port can be easily raised to 134. With C/30e's it may even be possible to raise that to 1,030 to accomodate the latest variation of the Christensen protocol, without the paperwork to make such a "simple" change request necessary. A low-overhead Christensen transfer would then be possile at higher speeds and thus reduce the duration of such transfers. (I intended to insert a pitch for upgrading the TAC dialin modems to 2,400 bps, but I'm already pushing my luck.) Now, having said all that, are there data to back up our claim that file transfers through TACs are becoming, if not already, a significant factor in network loading to justify a TAC level protocol implementation? --Frank ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041017301900> Received: from DCN8.ARPA by SRI-NIC.ARPA with TCP; Thu 10 Apr 86 11:25:46-PST Date: 10-Apr-86 17:30:19-UT From: mills@dcn6.arpa Subject: Wollongong problem To: tcp-ip@sri-nic.arpa Folks, It appears that the Wollongong user TELNET for VMS does not pad the CR (carriage return) with either NUL (idle) or LF (line feed) entered from the keyboard, so is in violation of the TELNET specification (RFC-854, page 10). At least some servers become cranky when faced with "bare" CR, at least in some cases. Fred Ball at Ford noticed the Wollongong struck with the fuzzball TELNET server, but other servers may peal that gong as well. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041021025800> Mail-From: MKL created at 10-Apr-86 22:59:24 Received: from mouton.ARPA by SRI-NIC.ARPA with TCP; Thu 10 Apr 86 22:58:32-PST Received: by mouton.ARPA (4.12/4.7) id AA00062; Fri, 11 Apr 86 02:02:58 est Date: Fri, 11 Apr 86 02:02:58 est From: karn@mouton.ARPA (Phil R. Karn at mouton.ARPA) Message-Id: <8604110702.AA00062@mouton.ARPA> To: tcp-ip@sri-nic.arpa Subject: Telnet cr/lf Clearly, implementations which don't send cr/lf sequences when operating in standard NVT mode are broken. But I assume that the server offers to echo and that the user accepts (as almost all Unix systems do) then the connection reverts to "raw" mode -- otherwise things like screen editors break. Is this a reasonable interpretation? Phil ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041101330200> Received: from Dewey.UDEL.EDU by SRI-NIC.ARPA with TCP; Fri 11 Apr 86 06:52:11-PST Received: from localhost by Dewey.UDEL.EDU id a025505; 11 Apr 86 9:53 EST To: JOHNSON%northeastern.csnet@csnet-relay.ARPA cc: tcp-ip@sri-nic.ARPA Subject: Re: LAN flooding. In-reply-to: Your message of Wed, 09 Apr 86 08:16:00 -0500. Date: Fri, 11 Apr 86 09:53:02 -0500 From: Gurudatta Parulkar Thank you very much for asking the following question. So let me take this opportunity to elaborate little more of NOAHnet, the flood LAN we are developing. Noahnet uses a graph like topology with 4-5 interconnections per node. It uses a "kind of flooding" to route all data messages around the network and it does not do store and forward. Every node starts forwarding an incoming message to all its UNOCCUPIED adjacent nodes as soon as it receives the first (couple of) bit(s) (one may think of it as a kind of circuit switching). Thus, delay at each node is very small. It uses short status and command messages to release nodes which don't form successful path. In short, our claims are that 1. Graph like topology should provide required reliability to LANs. 2. The topology and our flooding protocol permit multiple messages to be active in the network at any time. 3. Flooding associated with no store and forward provide fast routing strategy. 4. Any thing that you can think of ! Noahnet nodes will be more expensive than other LAN interfaces but not order of magnitude. Flooding looks wasteful, but the modified flooding does not seem to be THAT (?) wasteful. We are doing formal performance analysis to prove (disprove!) these claims. I hope that it gives a better picture of what we are doing. So WHAT DO THINK ?? We do have few tech reports describing the Noahnet effort, in case, you would like to see more details. Thanks for your attention. -guru >>We at University of Delaware are exploring the possibility of using >>flooding in a LAN. Are there any other groups looking into such a >>possibility ? Please send me a note. > Maybe I missed something here. The LANs I know of all have a broadcast > address available to them. Why would you want to flood a LAN when one > packet will do? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041102590000> Received: from hydra.ARPA (RIACS-HYDRA.ARPA) by SRI-NIC.ARPA with TCP; Fri 11 Apr 86 10:58:18-PST From: Barry Leiner Message-Id: <8604111859.AA07148@hydra.ARPA> Received: by hydra.ARPA (4.12/4.01) Fri, 11 Apr 86 10:59:10 pst Date: 11 Apr 1986 1059-PST (Friday) To: Mike Muuss Cc: security@red.rutgers.edu, tcp-ip@sri-nic.ARPA, Ra Subject: Re: Thought on data encryption on networks In-Reply-To: Your message of Fri, 4 Apr 86 15:26:57 EST. <8604050140.AA05814@riacs.ARPA> Mike, MOst of the work I am aware of in ETE encryption in the internet has been working on top of IP (i.e. encrypts IP packets on a packet by packet basis). Barry ---------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041103350000> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Fri 11 Apr 86 06:50:09-PST Received: from slb-test by csnet-relay.csnet id aa26935; 11 Apr 86 9:37 EST Date: Fri, 11 Apr 86 08:35 EST From: "Brendan Healey, 0734 752175" To: apollo@yale.ARPA, info-kermit@cu20b.columbia.edu, info-vax@sri-kl.ARPA, sun-spots@rice.edu, tcp-ip@sri-nic.ARPA, unix-emacs@bbn-unix.ARPA, unix-wizards@brl.ARPA Hello distribution list!, my name is Brendan Healey, I am the computer centre manager for Fairchild Semiconductor ltd at Reading ENGLAND. I would appreciate it if you would add my name to the distribution list. I have a 8600-11/785 cluster system, attached to the worldwide Schlumberger Information Network, and 4 sun 3/50's. Reading is the site of the European Research, Design and Applications Centre (ERDAC). Our interests range from Pascal to Prolog, C UNIX, SUNS, VAX/VMS and communications. Address being:- system%reafsb%smrvx2%eps731%slb-test.csnet@csnet-relay.arpa Thankyou, Brendan Healey ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041104310000> Received: from SCRC-STONY-BROOK.ARPA by SRI-NIC.ARPA with TCP; Fri 11 Apr 86 06:34:20-PST Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 461184; Fri 11-Apr-86 09:32:46-EST Date: Fri, 11 Apr 86 09:31 EST From: David C. Plummer Subject: Wollongong problem To: mills@DCN6.ARPA, jas@PROTEON.ARPA, Rudy.Nedved%A.CS.CMU.EDU@SCRC-STONY-BROOK.ARPA, Phil R. Karn at mouton.ARPA , tcp-ip@SRI-NIC.ARPA In-Reply-To: The message of 10 Apr 86 12:30 EST from mills@dcn6.arpa, <8604102245.AA04291@trantor.UMD.EDU>, The message of 10 Apr 86 17:57 EST from jas@proteon.arpa, <10Apr86.185539.EN0C@A.CS.CMU.EDU>, <8604110702.AA00062@mouton.ARPA> Message-ID: <860411093139.3.DCP@FIREBIRD.SCRC.Symbolics.COM> Time more my yearly TELNET flame: (Implement and) Use SUPDUP. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041108114500> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Fri 11 Apr 86 21:27:04-PST Received: from ncar by csnet-relay.csnet id ai04570; 12 Apr 86 0:20 EST Received: by hao-hw.NCAR (4.13/4.7) id AA18007; Fri, 11 Apr 86 15:31:38 mst Date: 11 Apr 86 15:11:45 mst From: Joe Choy 303-497-1222 Sender: choy%ncar.csnet@CSNET-RELAY.ARPA Subject: EXCELAN EXPERIENCE REFERENCES To: tcp-ip@sri-nic.ARPA Cc: I would appreciate anyone who has any expeience with the Excelan board and EXOS software on a VAX VMS system and/or 11/70 running RSX11M+ relating their comments to me. We have users who are considering the products. We are especially interested in problems encountered, support provided by Excelan, compatibility (or the lack of it) with other TCP/IP products, and anything else that might be worth noting. Please reply to me directly: choy@ncar.csnet Thanks in advance! ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041109240000> Received: from SANDIA-2.ARPA by SRI-NIC.ARPA with TCP; Fri 11 Apr 86 15:25:38-PST Date: 11 Apr 86 16:24:00 MST From: Subject: VAX 11/750 running Wollengong Software To: "tcp-ip" Reply-To: Here at Sandia Labs, Albuquerque, NM, we recently brought a new host onto MILNET. SANDIA-2 is a VAX 11/750 running VMS and The Wollengong Group IP/TCP software. Our IMP interface is an ACC LH/DH-11. I am looking for VMS procedures to set up and run the following applications: "handle" interpreting for local users' incoming mail "finger" utility bulletin boards: setting up and running distribution lists: setting up and running any other modern conveniences for users and administrators Any help will be appreciated in this area. If anyone has information as to how this configuration of VAX and Wollengong should perform or any bugs detected, I'd be interested. Send responses to: MGEORGE@SANDIA-2 Thanks in advance. - Mike George Division 2633 Sandia National Labs P.O. Box 5800 Albuquerque, NM 87185 505-844- 9357 FTS-844-9357 ------ ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041109370000> Received: from A.CS.CMU.EDU by SRI-NIC.ARPA with TCP; Fri 11 Apr 86 11:36:08-PST Date: 11 Apr 86 14:37 EST From: Rudy.Nedved@A.CS.CMU.EDU To: karn@mouton.ARPA (Phil R. Karn at mouton.ARPA) Subject: Re: Telnet cr/lf CC: tcp-ip@sri-nic.arpa In-Reply-To: <8604110702.AA00062@mouton.ARPA> Message-Id: <11Apr86.143718.EN0C@A.CS.CMU.EDU> The connection only reverts to RAW mode when DO BINARY is done. The normal mode is non-RAW or COOKED depending on what you are using. Interrupt and other special operations characters do not work in RAW mode. RAW tells the terminal driver (whatever flavor) to not act on any characters. CRMOD in non-RAW mode tells the driver to convert from CR to LF since Unix wants "newline" which is a LF. Also CRMOD on output makes LF into CR LF. -Rudy ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041113225400> Received: from bbncc-eur by SRI-NIC.ARPA with TCP; Fri 11 Apr 86 05:25:08-PST Date: Fri, 11 Apr 86 13:22:54 GMT From: Larry Byard Subject: Re: PCs and TACs In-Reply-To: Your message of Fri, 11 Apr 1986 00:06 MST To: "Frank J. Wancho" Cc: TCP-IP@sri-nic.arpa, stt-eng@bbncc-eur.arpa Oooops. Make that all IMPs (PSNs) in Europe are C/30Es. There are no C/30E TACs. Larry ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041116161800> Received: from sally.UTEXAS.EDU by SRI-NIC.ARPA with TCP; Fri 11 Apr 86 20:21:51-PST Date: Fri, 11 Apr 86 22:16:18 cst From: jsq@SALLY.UTEXAS.EDU (John Quarterman) Posted-Date: Fri, 11 Apr 86 22:16:18 cst Message-Id: <8604120416.AA16708@sally.UTEXAS.EDU> Received: by sally.UTEXAS.EDU (4.22/4.22) id AA16708; Fri, 11 Apr 86 22:16:18 cst To: TCP-IP@SRI-NIC.ARPA Subject: 4.3BSD IP subnet ARP hack Someone asked a few weeks ago if an ARP hack had been implemented for 4.3BSD. (This is a way to allow subnet gateways to respond to ARP requests for hosts that are on subnets other than the one of the requesting host: the subnet gateway thus becomes a bridge and only subnet bridges need know about subnets.) I have reimplemented Smoot Carl-Mitchell's 4.2BSD ARP hack in 4.3BSD. It is available by anonymous ftp (login anonymous, password guest) from sally.utexas.edu as the shell archive /pub/subarp.shar. I will also post it to mod.sources on USENET, and have sent it to Berkeley. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041200250000> Received: from SU-AI.ARPA by SRI-NIC.ARPA with TCP; Sat 12 Apr 86 08:26:12-PST Date: 12 Apr 86 0825 PST From: Joe Weening Subject: Telnet binary option To: TCP-IP@SRI-NIC.ARPA Ah yes, Unix and the Telnet binary option. Most of our hosts at Stanford have been fixed not to interpret this as raw mode, since it's useless for our main use of Telnet, i.e., connecting people's terminals to hosts. Binary mode allow terminals with an "edit" or "meta" key to send this as the 200 bit, which is useful for EMACS and other programs, but terminals continue to send CR when you type , not LF, which is what raw mode expects; and they need both CR and LF to move to the beginning of the next line. Raw mode confuses the hell out of non-Unix hosts. RFC 856 says that both sides need an "interpretation" of binary mode, with no suggestions as to what such an interpretation might be. So I guess it's all right for consenting Unixes to do whatever they want, but when the other host is not known to be Unix, it seems a bit presumptuous to assume it will use Unix conventions. Joe ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041202590000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Sat 12 Apr 86 04:59:24-PST Date: 12 Apr 1986 07:59-EST Sender: CERF@USC-ISI.ARPA Subject: Re: Ethernet monitor wanted From: CERF@USC-ISI.ARPA To: LYNCH@USC-ISIB.ARPA Cc: narten@PURDUE.EDU, tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]12-Apr-86 07:59:07.CERF> In-Reply-To: The message of 9 Apr 1986 07:54:25 PST from Dan Lynch Charlie Brown's Complete Systems Inc is reselling a box made by Xerox which does all kinds of tests - including finding breaks in Ethernet cables. This box sells for something like $2-3K I believe. Gary McGreal and Charlie Brown are running this out of Northern Virginia. I will get the phone number if anyone is interested. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041216092600> Received: from merlin.Purdue.EDU by SRI-NIC.ARPA with TCP; Sat 12 Apr 86 18:10:47-PST Date: Sat, 12 Apr 86 21:09:26 EST From: "Christopher A. Kent" Message-Id: <8604130209.AA23946@merlin.Purdue.EDU> Received: by merlin.Purdue.EDU; Sat, 12 Apr 86 21:09:26 EST To: tcp-ip@sri-nic.arpa Subject: ICMP responses to broadcasts Let me second John Romkey's assertion that no good ICMP implementation should send redirects in response to a broadcast packet. Might I also ask at this time why our core gateway does just that? We receive several redirects a second in response to the rwho/ruptime packets our Unix hosts send (no ruptime flames, please.) chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041310591200> Received: from NRTC-GREMLIN.NORTHROP.COM by SRI-NIC.ARPA with TCP; Mon 14 Apr 86 00:21:10-PST Received: from localhost by NRTC-GREMLIN.NORTHROP.COM id a010059; 14 Apr 86 0:19 PST To: Ra cc: security@red.rutgers, tcp-ip@sri-nic.ARPA Reply-To: Security@red.rutgers Subject: Re: Thought on data encryption on networks In-reply-to: Your message of Fri, 04 Apr 86 11:50:16 EST. <8604041650.AA19510@bu-cs.ARPA> Date: Mon, 14 Apr 86 00:19:12 -0800 Message-ID: <10057.513850752@nrtc-gremlin> From: Marshall Rose [ Forgive me for joining so late on this one but I'm inclined to correct one mistyped fact... ] > Oh, where is Arthur to slice this gordian knot? Arthur? It was the Persian boy, "Alexander the Great", who tackled the Gordian knot. He did not use subtlety but brute force in doing so. /mtr ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041402160000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Mon 14 Apr 86 04:17:53-PST Date: 14 Apr 1986 07:16-EST Sender: CERF@USC-ISI.ARPA Subject: Re: Ethernet monitor wanted From: CERF@USC-ISI.ARPA To: CERF@USC-ISI.ARPA Cc: LYNCH@USC-ISIB.ARPA, narten@PURDUE.EDU Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]14-Apr-86 07:16:09.CERF> In-Reply-To: <[USC-ISI.ARPA]12-Apr-86 07:59:07.CERF> Complete Systems Inc 3206 Wildmere Place Herndon, VA 22071 (703) 620-5372 for Ethernet Monitors fromCharlie Brown (redistributing Xerox product) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041403320000> Received: from su-navajo.arpa by SRI-NIC.ARPA with TCP; Mon 14 Apr 86 11:32:59-PST Received: by su-navajo.arpa with Sendmail; Mon, 14 Apr 86 11:32:28 pst Date: 14 Apr 1986 1132-PST (Monday) From: Jeff Mogul To: "Christopher A. Kent" Cc: TCP-IP@SRI-NIC.ARPA Subject: Re: ICMP responses to broadcasts Let me second John Romkey's assertion that no good ICMP implementation should send redirects in response to a broadcast packet. Might I also ask at this time why our core gateway does just that? We receive several redirects a second in response to the rwho/ruptime packets our Unix hosts send (no ruptime flames, please.) Maybe it's because your Unix host is sending broadcasts to the wrong IP address? (That is, Net.0.0.0 instead of Net.255.255.255) Of course, it would be nice if gateways looked at the data-link header to see if something arrived as a broadcast, but this is one of those little things that is impossible in some systems (e.g., 4.3), which is why these systems really are unsuited for use as gateways. One would hope that the core gateways are capable of handling this, but I would not be surprised if they are not. I would also be unsurprised if the core gateways still know nothing at all about broadcasts. Perhaps someone can fill us in. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041404025700> Received: from harvard.HARVARD.EDU by SRI-NIC.ARPA with TCP; Mon 14 Apr 86 06:39:20-PST Received: from h-sc4.HARVARD.EDU (h-sc4) by harvard.HARVARD.EDU; Mon, 14 Apr 86 09:02:57 EST Date: Mon, 14 Apr 86 09:02:57 EST Received: by h-sc4.HARVARD.EDU; Mon, 14 Apr 86 09:02:04 est From: law%h-sc4@harvard.HARVARD.EDU To: CERF@USC-ISI.ARPA, LYNCH@USC-ISIB.ARPA Subject: Re: Ethernet monitor wanted Cc: narten@PURDUE.EDU, tcp-ip@SRI-NIC.ARPA Yes, would be interested in further info regarding ethernet monitors. Lew Law ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041404460000> Received: from SAPSUCKER.SCRC.Symbolics.COM ([192.10.41.223]) by SRI-NIC.ARPA with TCP; Mon 14 Apr 86 06:56:51-PST Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 7998; Mon 14-Apr-86 09:47:50 EST Date: Mon, 14 Apr 86 09:46 EST From: David C. Plummer Subject: Data after a FIN To: tcp-ip@SRI-NIC.ARPA Message-ID: <860414094641.6.DCP@FIREBIRD.SCRC.Symbolics.COM> We are noticing several hosts (e.g., UTAH-CS) that are sending a FIN, then sending data, and finally a second FIN. Technically, The spec says this should happen and the data should be discarded. What I want to know is - Who is doing this (I suspect 4.3BSD)? and - Why? and - Why doesn't anybody else know about it? I was under the impression this list was a clearing-house for ideas, but have absolutely no recollection of this being discussed. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041409423500> Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Mon 14 Apr 86 12:07:30-PST Date: Mon 14 Apr 86 14:42:35-EST From: "J. Noel Chiappa" To: OPERATOR%PSI%REAFSB%SDRRTR%slb-test.csnet@CSNET-RELAY.ARPA, apollo@YALE.ARPA, info-kermit@CU20B.COLUMBIA.EDU, info-vax@SRI-KL.ARPA, sun-spots@RICE.EDU, tcp-ip@SRI-NIC.ARPA, unix-emacs@BBN-UNIX.ARPA, unix-wizards@BRL.ARPA cc: JNC@XX.LCS.MIT.EDU In-Reply-To: Message from ""Brendan Healey, 0734 752175" " of Fri 11 Apr 86 14:26:37-EST Message-ID: <12198824179.25.JNC@XX.LCS.MIT.EDU> Does anyone know of a 'suitable' tool (definition of exactly what such a tool should do purposely left unstated) to apply to people like this? The polite 'education' method of informing people (which I was a believer in for a while) that this is not a sociable thing to do always seems to miss a few newcomers who promptly make the same mistake. My current theory (regressing to 17th century penal ideology) is that we should punish the offendors so horribly that word of what happens to you when you do this will become instant network folklore. I used to send such pinheads a few megabytes of mail manually, but maybe a tool that sends them 253 copies of SF-LOVERS every hour for three weeks is the right thing. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041501083600> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Tue 15 Apr 86 03:35:33-PST Date: Tue, 15 Apr 86 6:08:36 EST From: Mike Muuss To: Hostmaster@sri-nic.arpa, tcp-ip@sri-nic.arpa cc: Unix-Wizards@BRL.ARPA, GouldBugs@BRL.ARPA Subject: Host table & 4.2BSD problem The version of /etc/htable distributed with 4.2 BSD, when applied to the very latest host table from the NIC, fills your disks with the word "bucsa" repeated over and over again. The offending new host entry is: HOST : 192.12.185.1 : BU-CS.BU.EDU,BU-CS.ARPA,BU-CS,BUCSA,A : SUN-3 : UNIX :: This is currently the only host in the table with a single character name, and the 4.2 BSD version of "htable" has a (defective) special case in the handling of this. Never fear, the 4.3 version is correct, but you don't have it yet. SUGGESTIONS: 1) The NIC should probably remove the alias "A" from BUCSA. (*I* won't forget that host name anytime soon -- it's etched on 200 Mbytes of disk!) 2) All UNIX caretakers should apply the following patch to file /usr/src/etc/htable/scan.l: From: {ALPHA} return (NAME); To: {ALPHA} { yylval.namelist = newname(yytext); return (NAME); } Note that Gould UTX 1.2 has this bug as well (a faithful port of the Berkeley bug). All you folks with binary systems, file an SPR. Bugs! -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041501390400> Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Tue 15 Apr 86 04:52:09-PST Date: Tue, 15 Apr 86 6:39:04 EST From: Mike Muuss To: Hostmaster@sri-nic.arpa cc: tcp-ip@sri-nic.arpa Subject: Bad host entries Turns out that there is more fun. The Berkeley HTABLE program will not accept CPUs of the form: SUN-2/50,they must instead be written SUN2-50. No slashes. There are 5 such errors in the new host table: jove.caltech.edu ganymede.caltech.edu leda.caltech.edu laplace.db.mcc.com weierstrass.db.mcc.com This problem exists with both 4.2 and 4.3 BSD version of HTABLE, so I suggest that the table gets fixed. Best, -Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041502392200> Mail-From: STAHL created at 15-Apr-86 10:40:19 Date: Tue 15 Apr 86 10:39:22-PST From: HOSTMASTER@SRI-NIC.ARPA Subject: Re: Bad host entries Sender: STAHL@SRI-NIC.ARPA To: brescia@BBNCCV.ARPA cc: mike@BRL.ARPA, Hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, STAHL@SRI-NIC.ARPA Reply-To: HOSTMASTER@SRI-NIC.ARPA In-Reply-To: Message from "Mike Brescia " of Tue 15 Apr 86 09:31:00-PST Message-ID: <12199074814.23.STAHL@SRI-NIC.ARPA> You're right, Mike. Single character names and nicknames are disallowed in the table. This is written up in RFC 952, DoD Internet Host Table Specification. There obviously was a slip-up here. We'll correct the table and investigate to see why it happened. - Mary ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041503275900> Received: from sun.com by SRI-NIC.ARPA with TCP; Tue 15 Apr 86 11:35:19-PST Received: from snail.sun.com (snail-ptp) by sun.com (3.2-/SMI-3.0) id AA05317; Tue, 15 Apr 86 11:30:20 PST Received: from plaid.sun.uucp by snail.sun.com (3.2/SMI-3.0DEV4) id AA12317; Tue, 15 Apr 86 11:29:44 PST Received: by plaid.sun.uucp (1.1/SMI-3.0DEV3) id AA02511; Tue, 15 Apr 86 11:27:59 PST Date: Tue, 15 Apr 86 11:27:59 PST From: chuq%plaid@SUN.COM (Chuq Von Rospach) Message-Id: <8604151927.AA02511@plaid.sun.uucp> To: JNC@xx.lcs.mit.edu Subject: requests Cc: tcp-ip@sri-nic.arpa, unix-wizards@BRL.ARPA >> Message-ID: <12198824179.25.JNC@XX.LCS.MIT.EDU> >> ...we should punish the offendors so horribly that word of what >> happens to you when you do this will become instant network folklore. >> I used to send such pinheads a few megabytes of mail manually, but >> maybe a tool that sends them 253 copies of SF-LOVERS every hour for >> three weeks is the right thing. What is the purpose of flaming to death a person WHO DOESN'T KNOW BETTER? I'm not saying that the protocols, procedures and folklore of the net (whether ARPA or USENET) are arcane or confusing -- especially to those who have learned the ropes. Remember, you were a novice once, yourself. Flaming someone for screwing up doesn't solve the problem. Information solves the problem. In all my time working with USENET, only rarely did I see a person or account repeat a mistake. Reacting to a misplaced message like it was a personal affront only causes the new users (new blood and ideas we can ALWAYS use to keep the groups fresh) the withdraw and decide we're all a bunch of idiots (or worse). The over-reaction is MUCH worse than the crime. > Each netmailer need make such mistakes only once or twice if, in reply, > they received a canned tutorial on the constituate parts of netdom, > pathnames, list-of-lists, requests, etc., etc. I've not seen such a > summary available for distribution, but I'd sure like to see one. Good information is key. A couple of years back (was it that long ago, already?) I rewrote the etiquette doc for USENET. Perhaps what we need is something similar for ARPA lists, so that when someone does screw up we have a concise and non-flaming resource to help them keep from screwing up twice. chuq ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041503430400> Mail-From: STAHL created at 15-Apr-86 11:44:24 Date: Tue 15 Apr 86 11:43:04-PST From: HOSTMASTER@SRI-NIC.ARPA Subject: Re: Bad host entries Sender: STAHL@SRI-NIC.ARPA To: mike@BRL.ARPA cc: Hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, STAHL@SRI-NIC.ARPA Reply-To: HOSTMASTER@SRI-NIC.ARPA In-Reply-To: Message from "Mike Muuss " of Tue 15 Apr 86 04:52:45-PST Message-ID: <12199086412.23.STAHL@SRI-NIC.ARPA> Mike, In the latest version of "Assigned Numbers", RFC 960, SUN-2/50 is listed as an "official" machine name. SUN2-50 is not listed there. People bringing hosts onto the net should make this RFC or its latest update part of their library. It can be FTPed from SRI-NIC as pathname RFC:RFC960.TXT. The latest version can always be found on SRI-NIC as RFC:ASSIGNED-NUMBERS.TXT, so one doesn't necessarily have to remember its RFC number. - Mary ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041504092600> Received: from BBN-SPCA.ARPA by SRI-NIC.ARPA with TCP; Tue 15 Apr 86 06:12:56-PST Date: Tue, 15 Apr 86 9:09:26 EST From: Bruce Brolsma To: JNC@xx.lcs.mit.EDU cc: unix-wizards@brl.ARPA, tcp-ip@sri-nic.ARPA Subject: requests > Message-ID: <12198824179.25.JNC@XX.LCS.MIT.EDU> > ...we should punish the offendors so horribly that word of what > happens to you when you do this will become instant network folklore. > I used to send such pinheads a few megabytes of mail manually, but > maybe a tool that sends them 253 copies of SF-LOVERS every hour for > three weeks is the right thing. Now, these things couldn't POSSIBLY happen because netmail address paths seem abstruse and impenetrable, especially to newcomers, could they???? The half-second it takes me to discard such messages doesn't particularly bother me, perhaps because I am inclined to be merciful toward most everyone. It's a bit like sex education; after the fact punishment ain't gonna do all that much to alleviate the problem. Each netmailer need make such mistakes only once or twice if, in reply, they received a canned tutorial on the constituate parts of netdom, pathnames, list-of-lists, requests, etc., etc. I've not seen such a summary available for distribution, but I'd sure like to see one. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041504284300> Received: from mouton.bellcore.com by SRI-NIC.ARPA with TCP; Tue 15 Apr 86 06:29:03-PST Received: from sabre.bellcore.com by mouton.bellcore.com (4.12/4.7) id AA04927; Tue, 15 Apr 86 09:28:57 est Received: from blade.bellcore.com (blade.ARPA) by sabre.bellcore.com (4.12/SMI-2.0mjl) id AA03773; Tue, 15 Apr 86 09:28:15 est Received: by blade.bellcore.com (4.12/SMI-2.0mjl) id AA10433; Tue, 15 Apr 86 09:28:43 est Date: Tue, 15 Apr 86 09:28:43 est From: martin%sabre@mouton.bellcore.com (Martin J Levy) Message-Id: <8604151428.AA10433@blade.bellcore.com> To: tcp-ip@sri-nic.arpa Subject: Hyperchannel tcp/ip for 4.2bsd. i'm in the process of bringing up 3 machines on a hyperchannel with steve glasser's (Tek) driver. i would like to know any other sites which are running such code. i have been able to find steve. martin levy bellcore. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041504310000> Received: from BBNCCV.ARPA by SRI-NIC.ARPA with TCP; Tue 15 Apr 86 06:35:47-PST To: Mike Muuss cc: Hostmaster@sri-nic.ARPA, tcp-ip@sri-nic.ARPA, brescia@BBNCCV.ARPA Subject: Re: Bad host entries In-reply-to: Your message of Tue, 15 Apr 86 6:39:04 EST. Date: 15 Apr 86 09:31:00 EST (Tue) From: Mike Brescia re: single character names Every site (well, a lot of them) has hosts named A, B, ... . While the NIC people check for unique names, they should also editorially remove such short names. Thus BUCSA could be A.CS.BU.EDU, and still be named as A within the CS.BU.EDU domain. ISIA, BBNA, CMUA, etc. thank you. re: form of cpu name, e.g. SUN-2/50 We have (had?) a list of 'Official Machine Names', 'Official System Names', 'Official Protocol and Service Names', and 'Official Terminal Type Names' in RFC 943, 'Assigned Numbers' so that we can avoid such problems. Perhaps the rule for inventing those names should be stated in those sections, to prevent future breakage. Proposed statement of rule for names - "Official Names consist of only alphanumeric and hyphen (minus sign) characters." Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041505325100> Received: from BBNCCV.ARPA by SRI-NIC.ARPA with TCP; Tue 15 Apr 86 07:42:32-PST To: tcp-ip@sri-nic.ARPA Subject: Re: ICMP responses to broadcasts In-reply-to: message from Chris Kent, Sat, 12 Apr 86 21:09:26 EST. <8604130209.AA23946@merlin.Purdue.EDU> Date: 15 Apr 86 10:32:51 EST (Tue) From: Mike Brescia Let me second John Romkey's assertion that no good ICMP implementation should send redirects in response to a broadcast packet. Might I also ask at this time why our core gateway does just that? Chris, your gateway is on a ring. Its driver does not recognize broadcasts as such, and will rebroadcast them as well as send a redirect each time it comes around until the TTL disappears. This means that if the TTL is 10, you get 10 copies of the 'rwho' packet and 10 redirects. This has been the case since day one on the ring. (It had been fixed in fibernet and ethernet drivers long ago.) The fix in the gateway is to drop all IP-type packets addressed to 'hardware-broadcast' before they leave the local net layer. This is the first report of this being some kind of problem. We'll put it on the queue of things to fix before the latest release is completely frozen. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041505473900> Received: from bbncct.arpa by SRI-NIC.ARPA with TCP; Tue 15 Apr 86 08:01:11-PST Date: Tue, 15 Apr 86 10:47:39 EST From: "Mary C. Akers" To: "J. Noel Chiappa" Cc: tcp-ip@sri-nic.arpa, makers@bbncct.arpa Noel You notion has merit. I have had several such discussions with fellow office mates as to a "just punishment." We came to the conclusion that if EVERYONE who received mailing list addition/deletion messages answered the message with a detailed explanation of the correct procedures it might help correct the problem. Considering the size of some lists it might even match your 253-copies-of-SF-Lovers-per-hour figure. What say gentle readers? Is this a just/effective method? Mary ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041507520800> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Tue 15 Apr 86 14:23:41-PST Received: from 156206300 by CSNET-RELAY.ARPA id a014088; 15 Apr 86 16:37 EST Return-Path: Received: by bu-cs.ARPA (5.31/4.7) id AA09383; Tue, 15 Apr 86 12:52:08 EST Date: Tue, 15 Apr 86 12:52:08 EST From: Barry Shein Message-Id: <8604151752.AA09383@bu-cs.ARPA> To: Hostmaster@sri-nic.ARPA, mike@brl.ARPA, tcp-ip@sri-nic.ARPA Subject: Re: Host table & 4.2BSD problem Cc: GouldBugs@brl.ARPA, Unix-Wizards@brl.ARPA I would request that the alias for BUCSA that is causing the trouble ("A") be immediately removed from the host table entry, it was a mistake that it was ever sent. Apologies (although obviously the software shouldn't have fallen off the floor which I won't take responsibility for.) -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041604000700> Received: from nrl-aic by SRI-NIC.ARPA with TCP; Wed 16 Apr 86 06:26:48-PST Date: 16 Apr 1986 09:00:07 EST (Wed) From: Dan Hoey Subject: Re: Bad host entries To: Mike Muuss Cc: Hostmaster@sri-nic.ARPA, tcp-ip@sri-nic.ARPA Message-Id: <514044008/hoey@nrl-aic> In-Reply-To: Mike Muuss's message of Tue, 15 Apr 86 63904 EST From tcp-ip-RELAY@SRI-NIC.ARPA Wed Apr 16 07:42:50 1986 Date: Tue, 15 Apr 86 6:39:04 EST The Berkeley HTABLE program will not accept CPUs of the form: SUN-2/50,they must instead be written SUN2-50. No slashes. No, Mike, you have probably been confused by htable's off-by-3 error messages. HTABLE likes SUN-2/50 fine, but it can't cope with CPUs of the form "3Bn". When EYEZOD came out, I got Hostmaster to change its machine type to "ATT-3B20", but the problem resurfaced with the .BU.EDU batch that brought us BUCSA. The five offending hosts are: HOST : 192.12.185.21 : BUCSC.BU.EDU,BUCSC,DEATHSTAR : 3B5 : UNIX : TCP/TELNET,TCP/SMTP,TCP/FTP : HOST : 192.12.185.22 : TIE1.BU.EDU,TIE1 : 3B2 : UNIX : UDP : HOST : 192.12.185.23 : TIE2.BU.EDU,TIE2 : 3B2 : UNIX : UDP : HOST : 192.12.185.24 : TIE3.BU.EDU,TIE3,BUDD : 3B2 : UNIX : UDP : HOST : 192.12.185.25 : TIE4.BU.EDU,TIE4 : 3B2 : UNIX : UDP : More errors came in host table version 530: 24 host names with "Berkeley.EDU" in their names. Can the 4.3 HTABLE handle lower case? Dan Hoey ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041606465900> Received: from gyre.umd.edu by SRI-NIC.ARPA with TCP; Wed 16 Apr 86 08:46:30-PST Received: by gyre.umd.edu (5.9/4.7) id AA00417; Wed, 16 Apr 86 11:46:59 EST Date: Wed, 16 Apr 86 11:46:59 EST From: Chris Torek Message-Id: <8604161646.AA00417@gyre.umd.edu> To: Hostmaster@sri-nic.arpa, mike@brl.arpa, tcp-ip@sri-nic.arpa Subject: Re: Host table & 4.2BSD problem Cc: GouldBugs@brl.arpa, Unix-Wizards@brl.arpa Note that the 4.3 htable still cannot handle lowercase, nor does it like host names of the form `3B5' (begins with a digit). I plan to throw out the current source for htable and start over... Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041607254900> Received: from nrl-aic by SRI-NIC.ARPA with TCP; Wed 16 Apr 86 09:56:35-PST Date: 16 Apr 1986 12:25:49 EST (Wed) From: Dan Hoey Subject: Newer revised HTABLE for 4.2BSD To: tcp-ip@SRI-NIC.ARPA, unix-wizards@BRL.ARPA Cc: Hostmaster@SRI-NIC.ARPA Message-Id: <514056349/hoey@nrl-aic> Here are context diffs for /usr/src/etc/{scan.l,htable.h} that will allow machines like 3B2 and hosts like UCBVAX.Berkeley.EDU. It shouldn't have any problem with one-character host names, either. This diff is between the 4.2 scan.l and the new one. If you have applied the change Mike Muuss sent out yesterday, the form of your {ALPHA} rule will be different but the effect is the same: the rule is deleted, because it is handled by the revised rule. This change will NOT handle machine types like "360/50". Tokens must contain an alphabetic character before the first slash, dot, or hyphen. This prevents ambiguity in parsing octet notation. And yes, this will accept some invalid syntax, too. The Hostmaster will have to get a new canary. Dan Hoey *** 4.2/scan.l Thu Jun 30 20:19:45 1983 --- scan.l Wed Apr 16 12:10:14 1986 *************** *** 9,17 BLANK [ \t] DIGIT [0-9] ! ALPHA [A-Z] ! ANUM [0-9A-Z] ! NAMECHR [0-9A-Z./-] %% "NET" { --- 9,17 ----- BLANK [ \t] DIGIT [0-9] ! ALPHA [A-Za-z] ! ANUM [0-9A-Za-z] ! NAMECHR [0-9A-Za-z./-] %% "NET" { *************** *** 29,36 return (KEYWORD); } ! {ALPHA}{NAMECHR}*{ANUM} { ! yylval.namelist = newname(yytext); return (NAME); } --- 29,36 ----- return (KEYWORD); } ! {DIGIT}*{ALPHA}{NAMECHR}* { ! yylval.namelist = newname(lower(yytext)); return (NAME); } *************** *** 33,40 yylval.namelist = newname(yytext); return (NAME); } - - {ALPHA} return (NAME); {DIGIT}+ { yylval.number = atoi(yytext); --- 33,38 ----- yylval.namelist = newname(lower(yytext)); return (NAME); } {DIGIT}+ { yylval.number = atoi(yytext); *** 4.2/htable.h Thu Nov 3 15:35:32 1983 --- htable.h Wed Apr 16 10:47:32 1986 *************** *** 34,39 #define KW_HOST 3 struct name *newname(); char *malloc(); char *infile; /* Input file name */ --- 34,40 ----- #define KW_HOST 3 struct name *newname(); + char *lower(); char *malloc(); char *infile; /* Input file name */ ================ End of diffs. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041608203300> Received: from MCC.ARPA by SRI-NIC.ARPA with TCP; Wed 16 Apr 86 12:20:54-PST Date: Wed 16 Apr 86 14:20:33-CST From: DB.CHAMBERS@MCC.ARPA Subject: UNIX htable and slashes To: mike@BRL.ARPA cc: hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, c3@MCC.ARPA Mike, Regarding your message (brought to my attention by ): -------- Return-Path: Received: from SRI-NIC.ARPA by MCC.ARPA with TCP; Wed 16 Apr 86 06:07:28-CST Received: from BRL-SEM.ARPA by SRI-NIC.ARPA with TCP; Tue 15 Apr 86 04:52:09-PST Date: Tue, 15 Apr 86 6:39:04 EST From: Mike Muuss To: Hostmaster@sri-nic.arpa cc: tcp-ip@sri-nic.arpa Subject: Bad host entries Turns out that there is more fun. The Berkeley HTABLE program will not accept CPUs of the form: SUN-2/50,they must instead be written SUN2-50. No slashes. There are 5 such errors in the new host table: jove.caltech.edu ganymede.caltech.edu leda.caltech.edu laplace.db.mcc.com weierstrass.db.mcc.com This problem exists with both 4.2 and 4.3 BSD version of HTABLE, so I suggest that the table gets fixed. Best, -Mike -------- Bull pucky. 0. htable is perfectly capable of handling the slash. There are slashed CpuTypes all through hosts.txt. Why should just these five bomb out? htable's parser expects OpSys, CpuType, and so forth to be a NAME token, which the lexical analyzer returns on encountering: [A-Z] or [A-Z][0-9A-Z./-]*[0-9A-Z] The embedded slash is quite kosher. There ARE problems with hosts.txt.530, but this isn't one of them. 1. htable does not like lower case in NAMEs; get those entries containing "Berkeley" out of there! ("BERKELEY", perhaps?) 2. The lexer throws away the ;-commented lines at the beginning; the parser is reporting syntax errors on line numbers other than physical line numbers in the hosts source file. The five offending hosts are in fact HOST : 192.12.185.21 : BUCSC.BU.EDU,BUCSC,DEATHSTAR : 3B5 : UNIX : TCP/TELNET,TCP/SMTP,TCP/FTP : HOST : 192.12.185.22 : TIE1.BU.EDU,TIE1 : 3B2 : UNIX : UDP : HOST : 192.12.185.23 : TIE2.BU.EDU,TIE2 : 3B2 : UNIX : UDP : HOST : 192.12.185.24 : TIE3.BU.EDU,TIE3,BUDD : 3B2 : UNIX : UDP : HOST : 192.12.185.25 : TIE4.BU.EDU,TIE4 : 3B2 : UNIX : UDP : As noted above, htable expects a NAME to begin with an ALPHA, i.e. [A-Z]. 3Bx doesn't quite cut it. 3. I edited the "Berkeley" (->"BERKELEY") and "3Bx" (-> "ATT3Bx") entries in hosts.txt.530 and ran it through htable on a 4.2 and a 4.3 beta machine. Worked fine on both. 4. I agree completely with your comment "I suggest that the table gets fixed." -------- Cheers, John ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041609143300> Received: from MCC.ARPA by SRI-NIC.ARPA with TCP; Wed 16 Apr 86 13:14:55-PST Date: Wed 16 Apr 86 15:14:33-CST From: DB.CHAMBERS@MCC.ARPA Subject: UNIX htable and slash, P.S. To: mike@BRL.ARPA cc: hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, c3@MCC.ARPA Mike, Ahem. I should note that our hosts.txt is massaged quite a bit before being htable'd, hence my error line numbers are probably farther from the truth than the amount by which lex/yacc usually blows it. Same claim regarding the defective hosts, however. Cheers, John ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041613191500> Received: from gyre.umd.edu by SRI-NIC.ARPA with TCP; Wed 16 Apr 86 15:20:48-PST Received: by gyre.umd.edu (5.9/4.7) id AA01942; Wed, 16 Apr 86 18:19:15 EST Date: Wed, 16 Apr 86 18:19:15 EST From: Chris Torek Message-Id: <8604162319.AA01942@gyre.umd.edu> To: beta43_bugs@monet.berkeley.edu Subject: htable breaks on current nictab.txt (with fix) Cc: tcp-ip@sri-nic.arpa, unix-wizards@brl.arpa Index: /usr/src/etc/htable/scan.l 4.3Beta Fix Description: As you probably know by now, the NIC tables acquired some new names that broke htable. I do not speak of the one- letter names that leaked out of BU, but rather of the lowercase in all the `.Berkeley.EDU', and of the `CPUType' `3B5'. Repeat-By: Run htable on the current nictab.txt. Fix: Below. This is not terribly clean, but suffices for the moment... Chris RCS file: RCS/scan.l,v retrieving revision 1.1 retrieving revision 1.2 diff -c2 -r1.1 -r1.2 *** /tmp/,RCSt1001893 Wed Apr 16 18:12:31 1986 --- /tmp/,RCSt2001893 Wed Apr 16 18:12:32 1986 *************** *** 16,22 **** BLANK [ \t] DIGIT [0-9] ! ALPHA [A-Z] ! ANUM [0-9A-Z] ! NAMECHR [0-9A-Z./-] %% --- 16,22 ---- BLANK [ \t] DIGIT [0-9] ! ALPHA [A-Za-z] ! ANUM [0-9A-Za-z] ! NAMECHR [0-9A-Za-z./-] %% *************** *** 42,45 **** --- 42,52 ---- {ALPHA} { + yylval.namelist = newname(yytext); + return (NAME); + } + + {DIGIT}+{ALPHA}{NAMECHR}* { + fprintf(stderr, "Warning: nonstandard name \"%s\"\n", + yytext); yylval.namelist = newname(yytext); return (NAME); ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041617081200> Received: from RED.RUTGERS.EDU by SRI-NIC.ARPA with TCP; Thu 17 Apr 86 02:37:14-PST Date: 16 Apr 86 22:08:12 EST From: Mel Subject: more on htable To: Hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA Uucp: ...{seismo, allegra, ihnp4, Shasta}!topaz!pleasant Work: Hill-28, PO Box 879, Rutgers U, Piscataway, NJ (201) 932-2287 Home: 1253 Dogwood Drive, Bridgewater, NJ 08807, (201) 658-4408 Message-ID: <12199429590.19.PLEASANT@RED.RUTGERS.EDU> I'm not on this list at the moment so if this problem has already been reported, please excuse.... The 4.2 version of htable will also not accept the cpu type "3B2". If you look at the parser code, you see that NAME must begin with an alphabetic..... -Mel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041701571800> Received: from ATHENA by SRI-NIC.ARPA with TCP; Thu 17 Apr 86 07:16:57-PST Received: by ATHENA (5.45/4.7) id AA05464; Thu, 17 Apr 86 10:17:19 EST Received: by POSEIDON (5.15/4.7) id AA11179; Thu, 17 Apr 86 10:17:21 EST Message-Id: <8604171517.AA11179@POSEIDON> To: tcp-ip@sri-nic Subject: --Please remove me--- Date: Thu, 17 Apr 86 10:17:18 -0500 From: speter@ATHENA.MIT.EDU Please remove me from this mailing list. Thankyou. peter osgood speter@trillian.MIT.EDU ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041703180000> Received: from LOGICON.ARPA by SRI-NIC.ARPA with TCP; Thu 17 Apr 86 11:22:44-PST Date: 17 Apr 86 11:18 PST From: Tom Perrine To: tcp-ip@sri-nic Cc: Tom Perrine Subject: Re: The Host Table Several of the latest versions of the hosttable have been imaginative in the interpretation of RFC952. This has caused problems for some sites (especially those running BSD). May I suggest that RFC952 be updated to be a little more precise with its definition of "host name" and "cpu type"? The RFC states that host names are "up to 24 characters, drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.)." Note that this sort of implies that only uppercase alphabetics will be allowed. It is later noted that "no distinction is made between upper and lower case." As to "cpu type", you are referred to "Assigned Numbers". Could the SYNTAX for a cpu type be reproduced here? I am not sure that there IS a syntax for forming cpu type, just the list of known cpu types. With respect to the BBNCA problem, the rfc states that "single character names or nicknames are not allowed", so 4.[23] failed on an illegally-formed HOST line. (Catastrophically, unfortunately.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041703224300> Mail-From: OLE created at 17-Apr-86 11:24:00 Date: Thu 17 Apr 86 11:22:43-PST From: Ole Jorgen Jacobsen Subject: Re: UNIX htable and slashes To: DB.CHAMBERS@MCC.ARPA cc: mike@BRL.ARPA, hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, c3@MCC.ARPA, OLE@SRI-NIC.ARPA In-Reply-To: Message from "DB.CHAMBERS@MCC.ARPA" of Wed 16 Apr 86 12:32:51-PST SRI-NIC: (415) 859-4536 Home: (415) 325-9427 Beeper: (415) 496-9427 Message-ID: <12199606995.33.OLE@SRI-NIC.ARPA> Foo. Berkeley petitioned us for the longest time to take the mixed case name contrary to our original policy. We finally gave in and said, yes you can have a mixed case name (in line with the domain specification). If this breaks UNIX, then take it up with BERKELEY, (or Berkeley) as most of the UNIX on the net comes from there. OK? Ole ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041706253300> Received: from sri-unix.ARPA by SRI-NIC.ARPA with TCP; Thu 17 Apr 86 14:22:39-PST Received: by sri-unix.ARPA (4.12/4.16) id AA00472; Thu, 17 Apr 86 14:25:33 pst Date: Thu, 17 Apr 86 14:25:33 pst From: mckenney@sri-unix.ARPA (Paul E. McKenney) Message-Id: <8604172225.AA00472@sri-unix.ARPA> To: tcp-ip@sri-nic.ARPA Subject: NIC host table conversion It is rumored that a new version of the Unix utility to convert the NIC host table exists somewhere. Is this true? I have obtained a hacked version of the utility that handles the current host table, but full letter-of-the-law compliance with RFC952 seems to require more than just minor hacking. The version I have demands that at least one of the characters in '[a-zA-Z]/-' appear in the cputype and opsysname fields, in direct violation of the RFC, which would allow a cputype like '10.2.3.4', for example. Any pointers to the improved version would be deeply appreciated. Thanx, Paul (mckenney@sri-unix.ARPA) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041707160000> Received: from SCRC-QUABBIN.ARPA by SRI-NIC.ARPA with TCP; Thu 17 Apr 86 11:36:42-PST Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via INTERNET with SMTP id 265436; 17 Apr 86 12:18:36-EST Date: Thu, 17 Apr 86 12:16 EST From: David C. Plummer Subject: Re: Host table & 4.2BSD problem To: Chris Torek , Hostmaster@SRI-NIC.ARPA, mike@BRL.ARPA, tcp-ip@SRI-NIC.ARPA cc: GouldBugs@BRL.ARPA, Unix-Wizards@BRL.ARPA In-Reply-To: <8604161646.AA00417@gyre.umd.edu> Message-ID: <860417121642.1.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Wed, 16 Apr 86 11:46:59 EST From: Chris Torek Note that the 4.3 htable still cannot handle lowercase, nor does it like host names of the form `3B5' (begins with a digit). I plan to throw out the current source for htable and start over... I'm glad somebody had the sense to fix broken parsers instead of administratively imposing restrictions on what companies call their machines. You just can't prefice the company name onto the machine name. Suppose 3Com built a machine called the 747? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041708062300> Received: from MCC.ARPA by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 09:16:43-PST Received: from mccdb-dillo by MCC.ARPA with TCP; Thu 17 Apr 86 14:05:01-CST Date: Thu, 17 Apr 86 14:06:23 cst From: jbc%mccdb-dillo@mcc.ARPA (John B. Chambers) Posted-Date: Thu, 17 Apr 86 14:06:23 cst Message-Id: <8604172006.AA03264@mccdb-dillo> Received: by mccdb-dillo (4.12/4.22) id AA03264; Thu, 17 Apr 86 14:06:23 cst To: DB.CHAMBERS%MCC.ARPA@mcc.ARPA, OLE%SRI-NIC.ARPA@mcc.ARPA Subject: Re: UNIX htable and slashes Cc: c3%MCC.ARPA@mcc.ARPA, hostmaster%SRI-NIC.ARPA@mcc.ARPA, mike%BRL.ARPA@mcc.ARPA, tcp-ip%SRI-NIC.ARPA@mcc.ARPA Foo indeed. A fix has been posted on unix-wizards for the current htable "problem," but ... The grammar in rfc952 defines ::= ... ::= <*["."] ... ::= [*[]] ... What, pray tell, is a ? It certainly doesn't appear later in the grammar. It's evidently not the same as a , used in the definition of commentary text. Could it be that I'm supposed to go back and read the "Assumption" that says a "'name' ... is a text string ... drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.) ...?" Shall I then infer (A-Z) implies (a-z)? Ok, how about the definition for cputype: ::= PDP-11/70 | DEC-1080 | C/30 | CDC6400...etc. Sorry, but my parser doesn't understand "...etc." Likewise for opsys: ::= ITS | MULTICS | TOPS20 | UNIX...etc. I haven't seen anything here starting with a digit yet. Do I assume that 3B5 is thus invalid, or that anything goes? I've personally seen four lexical variations for htable this week. That shouldn't really have to happen. Tell you what. If agrees on a complete grammar, I'll just bet that would be happy to implement it. :-) -------- Cheers, John ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041708480500> Mail-From: OLE created at 17-Apr-86 16:49:12 Date: Thu 17 Apr 86 16:48:05-PST From: Ole Jorgen Jacobsen Subject: Re: UNIX htable and slashes To: hoey@NRL-AIC.ARPA cc: DB.CHAMBERS@MCC.ARPA, mike@BRL.ARPA, hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, c3@MCC.ARPA, OLE@SRI-NIC.ARPA In-Reply-To: <514161929/hoey@nrl-aic> SRI-NIC: (415) 859-4536 Home: (415) 325-9427 Beeper: (415) 496-9427 Message-ID: <12199666225.38.OLE@SRI-NIC.ARPA> Having a name in a particular case is not contrary to the spirit of RFC 952. Of course it doesn't make a difference to the software, but it may make an emotional difference to the users. Names are very touchy things to some people. We resisted mixed case for a while due to the extra work involved in maintaining the database. Ole ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041710405300> Received: from gyre.umd.edu by SRI-NIC.ARPA with TCP; Thu 17 Apr 86 12:39:20-PST Received: by gyre.umd.edu (5.9/4.7) id AA06529; Thu, 17 Apr 86 15:40:53 EST Date: Thu, 17 Apr 86 15:40:53 EST From: Chris Torek Message-Id: <8604172040.AA06529@gyre.umd.edu> To: DB.CHAMBERS@mcc.arpa, mike@brl.arpa Subject: Re: UNIX htable and slashes Cc: c3@mcc.arpa, hostmaster@sri-nic.arpa, tcp-ip@sri-nic.arpa The off-by-three error in line numbers is caused not by the lexer scan.l, but rather by a very bogus routine in htable.c that copies the first three comments from the input table to the Unix-style host table. I say `very bogus' because if there are fewer than three comment lines, it eats the first non-comment line, never to be seen again. And of course it does not inform the error routine of the number of lines it ate. Chris P.S. Lest you beleive I think the current htable is awful, no, it is, I think, just far too trusting. There is a certain elegance in using a generalised scanner and parser for this task. Of course there is a certain cost as well: htable is extremely slow. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041711090800> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Thu 17 Apr 86 13:19:01-PST Received: from bu-cs.bu.edu by CSNET-RELAY.ARPA id a008757; 17 Apr 86 16:08 EST Return-Path: Received: by bu-cs.ARPA (5.31/4.7) id AA14055; Thu, 17 Apr 86 16:09:08 EST Date: Thu, 17 Apr 86 16:09:08 EST From: Ra Message-Id: <8604172109.AA14055@bu-cs.ARPA> To: JNC@xx.lcs.mit.edu, makers@bbncct.ARPA Subject: Crime and Punishment Cc: tcp-ip@sri-nic.ARPA Sending massive amounts of stuff as punishment is more likely to punish various system administrators who have to clean the mess up, and likely aren't culpable (remember, in distributed systems the image of a room full of users under the admin's watchful eye is probably misleading.) You should have more faith in the desire people have to maintain their image in the eyes of others and just send a quick e-mail note if that's what you feel like doing, it should be sufficient. It reminds me once of a conversation (years ago, when I was a young hacker) with a faculty member about some admin who had royally teed me off: "I'm not gonna let this one go.." "What are you gonna do? Crash the system?" (long pause of confusion) "No, I'm gonna go to their office and yell at them" "Oh, right" "right...". -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041712280000> Received: from ALLEGHENY.SCRC.Symbolics.COM ([192.10.41.45]) by SRI-NIC.ARPA with TCP; Thu 17 Apr 86 14:33:17-PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12663; Thu 17-Apr-86 17:32:05-EST Date: Thu, 17 Apr 86 17:28 EST From: David C. Plummer Subject: Re: UNIX htable and slashes To: Ole Jorgen Jacobsen , DB.CHAMBERS@MCC.ARPA cc: mike@BRL.ARPA, hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, c3@MCC.ARPA In-Reply-To: <12199606995.33.OLE@SRI-NIC.ARPA> Message-ID: <860417172858.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Thu 17 Apr 86 11:22:43-PST From: Ole Jorgen Jacobsen Foo. Berkeley petitioned us for the longest time to take the mixed case name contrary to our original policy. We finally gave in and said, yes you can have a mixed case name (in line with the domain specification). If this breaks UNIX, then take it up with BERKELEY, (or Berkeley) as most of the UNIX on the net comes from there. OK? Bingo! This is the 1980s, after all. Even the 1970s had mixed case. I know of some systems of the 1960s that had mixed case. When was the last ASR-33 made, anyway? ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041712452900> Received: from nrl-aic by SRI-NIC.ARPA with TCP; Thu 17 Apr 86 15:01:03-PST Date: 17 Apr 1986 17:45:29 EST (Thu) From: Dan Hoey Subject: Re: UNIX htable and slashes To: Ole Jorgen Jacobsen Cc: DB.CHAMBERS@MCC.ARPA, mike@BRL.ARPA, hostmaster@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA, c3@MCC.ARPA Message-Id: <514161929/hoey@nrl-aic> In-Reply-To: Ole Jorgen Jacobsen's message of Thu 17 Apr 86 112243-PST Date: Thu 17 Apr 86 11:22:43-PST From: Ole Jorgen Jacobsen Foo. Berkeley petitioned us for the longest time to take the mixed case name contrary to our original policy. We finally gave in and said, yes you can have a mixed case name (in line with the domain specification).... I have no problem with the host table being in mixed case, though a little slow experimentation would have made the changeover easier. RFC 952 says no case distinction is made, perhaps warning us that mixed case might occur in the table. But this ``petitioning'' thing sounds like someone is making a distinction, and that is contrary to RFC 952. Maybe we should start petitioning NIC to periodically change the case of random characters in the table, just to make sure no one thinks that it makes a difference. Dan ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041718070000> Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Thu 17 Apr 86 20:10:42-PST Date: Thu, 17 Apr 1986 23:07 EST Message-ID: From: Rob Austein To: "Frank J. Wancho" Cc: sra@XX.LCS.MIT.EDU, TCP-IP@SRI-NIC.ARPA Subject: PCs and TACs In-reply-to: Msg of 11 Apr 1986 02:06-EST from "Frank J. Wancho" The last time I saw this question go by (NIC survey to host administrators, maybe?), John Romkey commented that an alternative to TAC support for KERMIT would be a TAC option that would pass IP packets down the RS232 connection, thus allowing direct use of FTP (or any other network protcol) from PCs. MIT-LCS already has something vaugely like this for faculty and staff with PCs at home. Now that the TACACS system is in place a direct IP option on TACs wouldn't be any particular security risk, either, for them as worry about such things. Direct IP support is a good bit more flexible than support for a particular bulk data protocol, so it is something to think about. --Rob ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041800343600> Received: from sri-unix.ARPA by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 21:43:30-PST Received: by sri-unix.ARPA (4.12/4.16) id AA10748; Fri, 18 Apr 86 08:34:36 pst Date: Fri, 18 Apr 86 08:34:36 pst From: ARPA@mckenney (Paul E. McKenney) Message-Id: <8604181634.AA10748@sri-unix.ARPA> To: hostmaster@sri-nic.ARPA, tcp-ip@sri-nic.ARPA Subject: Re:* Unix htable and slashes How about a policy of informing sites of changes in policy? Paul (mckenney@sri-unix.arpa) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041801074400> Received: from rsch.wisc.edu by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 09:08:10-PST Message-Id: <8604181707.AA02078@rsch.wisc.edu> Received: from uwisc by rsch.wisc.edu; Fri, 18 Apr 86 11:07:48 CST To: tcp-ip@sri-nic.arpa Subject: Wisconsin changes network numbers... Date: Fri, 18 Apr 86 11:07:44 -0600 From: Dave Cohrs I know there are a lot of sites that still don't use the name server. I thought y'all might want to see the following notice so there isn't as much bouncing mail on the 25th... This applies to the hosts in the 'wisc.edu' domain. dave ------- Forwarded Message From: Brian Pinkerton Date: Thu, 17 Apr 86 16:41:48 -0600 To: msgs-all Subject: IMPORTANT ARPANET INFO On Friday, April 25, we will be converting to a new set of Internet host numbers on ALL local machines. The change is motivated by a desire to provide a more organized, more expandable network environment. On the 'flag day', you will not notice any difference on local machines. We expect to complete the local conversion process sometime during the early morning (4:00-6:00am). You may still reference machines by whatever names you called them before, although their associated numbers will be different. Expect most local machines to be down sometime during that (4-6am) period for conversion (this includes the workstations). The problems with the conversion will come from outside sites on ARPANET who may not have up to date host tables. The Network Information Center will have prepared a new hosttable in advance of the conversion, so sites that are on the ball will have no problem. Those sites that do not fetch this new host table will unable to reach Wisconsin until they do. I will be mailing all site administrators Wednesday to notify them of this change. brian ------- End of Forwarded Message ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041802260700> Received: from ICS.UCI.EDU by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 19:03:49-PST Received: from localhost by ICS.UCI.EDU id a004034; 18 Apr 86 15:46 PST To: tcp-ip@sri-nic.arpa Subject: Need good source of ethernet cable Date: Fri, 18 Apr 86 15:46:07 -0800 Message-ID: <4029.514251967@ics.uci.edu> From: Richard Johnson We need to purchase about 300 meters of ethernet cable and are looking for a good inexpensive (not cheap! :-)) source. Our previous source delivered cable with connectors which simply screwed onto the ends. We have sometimes had problems with these coming off as the transceiver is attached. What we would really like is what (I believe) is called "crimp" type connectors (like what you get from Inmac I think) and it's hard for me to believe that we have to pay Inmac prices in order to get them. Any ideas? You should probably send directly to me. If anyone thinks a summary to the net is necessary, I'll be glad to oblige. raj. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041804220000> Received: from MARLBORO.DEC.COM by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 06:20:56-PST Date: 18 Apr 1986 0922-EST From: Kevin Paetzold To: tcp-ip@sri-nic telephone: 617-460-2203 Subject: [Kevin Paetzold : Re: UNIX htable and slashes] Message-ID: <"MS11(5146)+GLXLIB0(4)-4" 12199814474.19.126.16540 at MARLBORO.DEC.COM> i meant to send this to the list but somehow that does not seem to have happened. - - - - - - - Begin message from: Kevin Paetzold Date: 18 Apr 1986 0918-EST From: Kevin Paetzold To: Chris Torek , DB.CHAMBERS@mcc.arpa, mike@brl.arpa telephone: 617-460-2203 Subject: Re: UNIX htable and slashes Message-ID: <"MS11(5146)+GLXLIB0(4)-4" 12199813787.19.126.7685 at MARKET> References: Message from Chris Torek of 18-Apr-86 0318-EST In-reply-to: <8604172040.AA06529@gyre.umd.edu> Isn't it about time this Unix htable discusion got taken off line. i got tired of reading about it 25 messages ago. it is certainly much more annoying than the occasional subscription message to this list. -------- - - - - - - - End forwarded message -------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041804334900> Received: from harvard.HARVARD.EDU by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 06:33:12-PST Received: from h-sc4.HARVARD.EDU (h-sc4) by harvard.HARVARD.EDU; Fri, 18 Apr 86 09:33:49 EST Date: Fri, 18 Apr 86 09:33:49 EST Received: by h-sc4.HARVARD.EDU; Fri, 18 Apr 86 09:32:44 est From: mazzarelli%h-sc4@harvard.HARVARD.EDU To: OLE@SRI-NIC.ARPA, hoey@nrl-aic.ARPA Subject: Re: UNIX htable and slashes Cc: DB.CHAMBERS@MCC.ARPA, c3@MCC.ARPA, hostmaster@SRI-NIC.ARPA, mike@BRL.ARPA, tcp-ip@SRI-NIC.ARPA (Quick note--ASR 33s went out of production only about ten years ago.) --pm@harvard.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041805111900> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 07:14:06-PST Date: 18 Apr 1986 10:11:19 EST From: PADLIPSKY@USC-ISI.ARPA Subject: Telnet Options stuff To: tcp-ip@SRI-NIC.ARPA Perhaps I just failed to spot it, but my impression is that in the midst of reminding us all that New Telnet "Binary" is not identically equal to Old Telnet "Raw" nobody ever told Phil Karn explicitly that "Echo" doesn't imply/include either. Everybody's probably worked it out independently, but just in case.... On the Raw vs. Binary issue, I think I recall that the "improvement" Binary made was that you could get out of it (i.e., IACs still applied) and I also think I was against it then. Given around 14 more years of maturity/mellowing/tiredness, I now think that in addition to Binary, Telnet should offer a Raw Option that you are in forever once negotiated (where forever, of course, means until the connection is closed). If people agree, they should probably CC: Postel@USC-ISIB with their "votes". (No apology seems to be needed [from me to Jon], since this mailing list is clearly not "offical" and he'd be put to even more trouble if I went to the bother of making the proposal in an RFC. Right, Jon?) cheers, map ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041805500100> Received: from MCC.ARPA by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 10:04:21-PST Received: from mccdb-dillo by MCC.ARPA with TCP; Fri 18 Apr 86 11:49:06-CST Date: Fri, 18 Apr 86 11:50:01 cst From: jbc%mccdb-dillo@mcc.ARPA (John B. Chambers) Posted-Date: Fri, 18 Apr 86 11:50:01 cst Message-Id: <8604181750.AA01902@mccdb-dillo> Received: by mccdb-dillo (4.12/4.22) id AA01902; Fri, 18 Apr 86 11:50:01 cst To: DB.CHAMBERS%mcc.ARPA@mcc.ARPA, chris%gyre.umd.edu@mcc.ARPA, mike%brl.ARPA@mcc.ARPA Subject: Re: UNIX htable and slashes Cc: c3%mcc.ARPA@mcc.ARPA, hostmaster%sri-nic.ARPA@mcc.ARPA, tcp-ip%sri-nic.ARPA@mcc.ARPA Absolutely correct, which is why I posted my P.S. -- my manipulations of the host table before htabling were causing my entries to be off by a variable number in the 20-30 range when syntax errors were reported. Running a virgin hosts.txt through htable produces the constant error in the reported line number you mention. Thanks for that clarification, Chris. Cheers, John ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041806064700> Received: from MCC.ARPA by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 10:07:10-PST Received: from mccdb-dillo by MCC.ARPA with TCP; Fri 18 Apr 86 12:05:06-CST Date: Fri, 18 Apr 86 12:06:47 cst From: jbc%mccdb-dillo@mcc.ARPA (John B. Chambers) Posted-Date: Fri, 18 Apr 86 12:06:47 cst Message-Id: <8604181806.AA02082@mccdb-dillo> Received: by mccdb-dillo (4.12/4.22) id AA02082; Fri, 18 Apr 86 12:06:47 cst To: OLE%SRI-NIC.ARPA@mcc.ARPA, hoey%nrl-aic.ARPA@mcc.ARPA Subject: Re: UNIX htable and slashes Cc: DB.CHAMBERS%MCC.ARPA@mcc.ARPA, c3%MCC.ARPA@mcc.ARPA, hostmaster%SRI-NIC.ARPA@mcc.ARPA, mike%BRL.ARPA@mcc.ARPA, tcp-ip%SRI-NIC.ARPA@mcc.ARPA As I told Ole, yes, 952 mumbles in the assumptions section that no case distinction is made. That's still no apology for a slightly defective grammar spec for a file that has been, and for some sites will continue to be for a while, pretty important. RFC822, Section 3.3, was a good example of a decent lexical specification (from an implementor's point of view). And as Ole mentioned earlier, the "policy" has long been to use only upper case. Thus, we have a "policy", a "petition", and a slightly vague specification. The distributed htable addressed what was once a "safe" (because of "policy"?) subset, I suppose. [P.S. I liked your closing suggestion. :-) ] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041810480000> Received: from ddn2 by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 14:49:51-PST Date: 18 Apr 86 15:48 EST From: JHodges @ DDN2.ARPA Subject: Re: requests To: brolsma @ bbn-spca.arpa CC: jnc @ xx.lcs.mit.edu, unix-wizards @ brl.arpa, tcp-ip @ sri-nic.arpa I second the motion for a summary of the parts of netdom, pathnames, list-of-lists, etc. Basically, a short discussion of how to get added to lists, whom to ask for information when you can't seem to find it in the logical places, etc. FLAMING serves no purpose in this instance! How would Noel like to receive SF-LOVERS for three weeks??? That does not solve the problem! Jim ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041811360000> Received: from ddn2 by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 14:50:26-PST Date: 18 Apr 86 16:36 EST From: JHodges @ DDN2.ARPA Subject: Requests/Crime and Punishment To: tcp-ip @ sri-nic.arpa, unix-wizards @ brl.arpa CC: JHodges @ DDN2.ARPA Okay, So everyone agrees that at lest something ought to be done. If there is any interest in getting a summary produced, I volunteer to do it if I can get the cooperation of others on the net. If there is sufficient interest in this, let me know. Perhaps Chuq can start things off by sending me a copy of his "etiquette" document. Would anybody be willing to volunteer some time on their host for me to edit this thing? (I only have access to E-mail currently). If not, I'll still do it! Okay, let's get some ideas and suggestions for things that you would like to see put into this document. Also, specific actions that the user can take to access groups and networks which are not currently known to the NIC. Oh yes. Reply to me directly, okay? Jim ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041813190000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 15:21:59-PST Date: 18 Apr 1986 18:19-EST Sender: CERF@USC-ISI.ARPA Subject: Re: PCs and TACs From: CERF@USC-ISI.ARPA To: SRA@XX.LCS.MIT.EDU Cc: WANCHO@SIMTEL20.ARPA, TCP-IP@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]18-Apr-86 18:19:57.CERF> In-Reply-To: Accepting IP on an unprotected (ie no link level) line could be pretty messy. I would suggest that a reliable async link level would be appropriate which does error detection and retransmission if you go down this path. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041813240000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 15:25:26-PST Date: 18 Apr 1986 18:24-EST Sender: CERF@USC-ISI.ARPA Subject: Re: Telnet Options stuff From: CERF@USC-ISI.ARPA To: PADLIPSKY@USC-ISI.ARPA Cc: tcp-ip@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]18-Apr-86 18:24:14.CERF> In-Reply-To: The message of 18 Apr 1986 10:11:19 EST from PADLIPSKY@USC-ISI.ARPA I have been giving some thought to this whole raw binary question in the context of messaging and have to believe that a mode you can get into but not out of seems very awkward. If I had my choice, I would prefer a mode which still has enough structure that you can distinguish control from data - whether this means looking for escape sequences and using quote characters or having byte counts/framing conventions is a matter of design choice. If I had to vote, I guess it would be against the diode protocol (one-way - enter at your own risk...). Vint Z ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041817024200> Mail-From: VIVIAN created at 22-Apr-86 12:17:00 Return-Path: Received: from unix.macc.uwisc.edu (UNIX.MACC.WISC.EDU) by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 21:04:40-PST Received: by unix.macc.uwisc.edu (4.12/6.0.GT) id AA11775; Fri, 18 Apr 86 23:02:42 cst Date: Fri, 18 Apr 86 23:02:42 cst From: wupeter wu Posted-Date: Fri, 18 Apr 86 23:02:42 cst Message-Id: <8604190502.AA11775@unix.macc.uwisc.edu> To: tcp-ip-request@sri-nic.arpa Subject: Ethernet Board ReSent-Date: Tue 22 Apr 86 12:15:01-PST ReSent-From: Vivian Neou ReSent-To: tcp-ip@SRI-NIC.ARPA ReSent-Message-ID: <12200927234.39.VIVIAN@SRI-NIC.ARPA> Does anyone know where I can buy Ungermann-Bass Ethernet controllers #2274A or @2273A for the IBM RT PC? Any info or pointers or hints will be greatly appreciated. peter ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041818224100> Received: from BORAX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 20:24:16-PST Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Fri, 18 Apr 86 23:22:41 est Date: Fri, 18 Apr 86 23:22:41 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Message-Id: <8604190422.AA22723@BORAX.LCS.MIT.EDU> To: CERF@USC-ISI.ARPA Cc: SRA@XX.LCS.MIT.EDU, WANCHO@SIMTEL20.ARPA, TCP-IP@SRI-NIC.ARPA In-Reply-To: CERF@USC-ISI.ARPA's message of 18 Apr 1986 18:19-EST Subject: raw IP through a TAC dialup Date: 18 Apr 1986 18:19-EST Sender: CERF@USC-ISI.ARPA From: CERF@USC-ISI.ARPA Accepting IP on an unprotected (ie no link level) line could be pretty messy. I would suggest that a reliable async link level would be appropriate which does error detection and retransmission if you go down this path. Vint Actually, I've used SLIP, which doesn't do any error detection that the serial line doesn't do, over a 1200 baud dialup several times recently, between a PC at home and a VAX ant MIT. Error rates aren't bad at all. There are some bigger problems, though: - timeouts in TCP/IP implementations. Many programs seem to expect fairly high speed connections. They just don't hack 1200 baud very well. Retransmitting a 500 byte packet over a 1200 baud line is a disaster! Things are better now than they were two years ago when we did some experiments at MIT with a (really stupid) serial line protocol and some dialups on a gateway (which Rob mentioned a couple of messages back), but most TCP implementations just aren't up to performing well over networks whose speeds range from 1200 bps to 10Mbps. - addressing. This is an issue SLIP doesn't, um, address. Suppose you've got a bunch of dialups on a gateway, in a hunt group. The IP address of each dialup pretty much needs to be set by the gateway, not the machine that's dialing in. SLIP requires that both ends have "preordained" addresses and already know them, but in this case, the machine that's dialing in has to figure out its address. I have a few ideas for fixing up this problem but I'm not sure how practical it is to implement them. (BTW, I'm only picking on SLIP 'cause it's there and people are implementing it...) Also, you're going to turn the TAC into a real gateway, which might be more than it can handle. I don't really know. I don't mean to be discouraging, I think it's a great idea, being able to send raw IP datagrams through a TAC, but there are some problems to think about. If someone were to implement SLIP for the TAC, I've got IBM PC software they could use right now. If someone does some other serial protocol, I'll implement it, too, provided that it's not too monstrous. Is there anyone out there working on this sort of thing right now? - john ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041821555800> Received: from gyre.umd.edu by SRI-NIC.ARPA with TCP; Fri 18 Apr 86 23:55:37-PST Received: by gyre.umd.edu (5.9/4.7) id AA11605; Sat, 19 Apr 86 02:55:58 EST Date: Sat, 19 Apr 86 02:55:58 EST From: Chris Torek Message-Id: <8604190755.AA11605@gyre.umd.edu> To: CERF@usc-isi.arpa, romkey@mit-borax.arpa Subject: Re: raw IP through a TAC dialup Cc: SRA@xx.lcs.mit.edu, TCP-IP@sri-nic.arpa, WANCHO@simtel20.arpa SLIP dialins can select their addresses in any number of ways. If your machine `knows' its own Internet address, it can log in using a name that `means' that address. If it is willing to take pot luck, it can log in using a different name which implies an extra bit of protocol: the remote end will pick a number and send it, *before* starting up the SLIP protocol. I prefer that remote machines have fixed addresses, for aesthetic reasons. If you do not like having one login per remote machine ---though we who use UUCP have found that this is most definitely a good idea, in general---you can have a different bit of protocol where the dialling machine gives its number to the dialled machine before either starts up SLIP. Chris ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041906342000> Received: from SIMTEL20.ARPA by SRI-NIC.ARPA with TCP; Sat 19 Apr 86 12:34:31-PST Date: Sat 19 Apr 86 13:34:20-MST From: Mark Crispin Subject: Unix htable and slashes To: TCP-IP@SRI-NIC.ARPA Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Telephone: +1 (415) 968-1052 Message-ID: <12200144321.11.MRC@SIMTEL20.ARPA> I've got a great idea. Why don't we change our software to invert the case? That is, we'll do just like Unix and show SUMEX-AIM.ARPA as "sumex-aim.arpa" (ugh, acronyms should be upper case), but our friends at Bezerkeley will get "bERKELEY". The point is to cure people of being obscessed with case and worry about important details. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986041912361200> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Sat 19 Apr 86 14:53:31-PST Date: 19 Apr 1986 17:36:12 EST From: MILLS@USC-ISID.ARPA Subject: Re: raw IP through a TAC dialup To: romkey@MIT-BORAX.ARPA, CERF@USC-ISI.ARPA cc: SRA@XX.LCS.MIT.EDU, WANCHO@SIMTEL20.ARPA, cc: TCP-IP@SRI-NIC.ARPA, MILLS@USC-ISID.ARPA In response to the message sent Fri, 18 Apr 86 23:22:41 est from romkey@BORAX.LCS.MIT.EDU We have been using 1200-bps asynchronous IP connections since 1979 with generally good results, but usually with hosts which implement the "Nagle Algorithm" or something similar. The protocol is in fact somewhat fancier than simple stuff-'n-send and includes timekeeping, address recognition and reachability determination, but does not retransmit (by intent) in case of error. See RFC-891 for further details. We also have implemented the MIT PCIP serial-line protocol to keep our PC's babbling with the Internet. I have personally used Internet protocols on the Amateur AX.25 packet-radio channel with mixed results, primarily due to massive congestion and broken implementations also sharing the channel. See RFC-981 for was stories in that arena. The raw channel rate is 1200 bps and is shared by up to maybe a hundred stations at different times, so you can see TCP must be almost as heroic as when negoitating an ARPANET<->MILNET path nowadays. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042008430000> Received: from SU-SCORE.ARPA by SRI-NIC.ARPA with TCP; Sun 20 Apr 86 16:44:18-PST Date: 20 Apr 1986 16:43-PST Sender: BILLW@SU-SCORE.ARPA Subject: Re: raw IP through a TAC dialup From: William "Chops" Westfield To: CERF@USC-ISI.ARPA Cc: romkey@MIT-BORAX.ARPA, SRA@XX.LCS.MIT.EDU Cc: WANCHO@SIMTEL20.ARPA, TCP-IP@SRI-NIC.ARPA Message-ID: <[SU-SCORE.ARPA]20-Apr-86 16:43:03.BILLW> In-Reply-To: <[USC-ISI.ARPA]20-Apr-86 18:15:30.CERF> Seems like some varient of RARP in the TAC ought to solve that problem failrly easilly... BillW ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042013150000> Received: from USC-ISI.ARPA by SRI-NIC.ARPA with TCP; Sun 20 Apr 86 15:17:10-PST Date: 20 Apr 1986 18:15-EST Sender: CERF@USC-ISI.ARPA Subject: Re: raw IP through a TAC dialup From: CERF@USC-ISI.ARPA To: romkey@MIT-BORAX.ARPA Cc: SRA@XX.LCS.MIT.EDU, WANCHO@SIMTEL20.ARPA Cc: TCP-IP@SRI-NIC.ARPA Message-ID: <[USC-ISI.ARPA]20-Apr-86 18:15:30.CERF> In-Reply-To: <8604190422.AA22723@BORAX.LCS.MIT.EDU> John, good point about addressing. The commercial world is struggling with dial-up X.25 which is now being standardized as X.32 - the problem is to identify the caller and to bind the identity to the X.25 address. One might contemplate "logical IP" addresses which are assigned to the caller once the caller is suitable authenticated. Then comes the problme or initiating calls to this "floating"logical IP address - has many of the same problems as the problem of internet routing when a network in the internet becomes partitioned. Vint ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042013575400> Received: from monet.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sun 20 Apr 86 21:58:23-PST Received: by monet.Berkeley.EDU (5.50/1.12) id AA03697; Sun, 20 Apr 86 21:57:56 PST From: karels@monet.berkeley.edu (Mike Karels) Message-Id: <8604210557.AA03697@monet.Berkeley.EDU> To: Ole Jorgen Jacobsen , tcp-ip@sri-nic.arpa Cc: hostmaster@sri-nic.arpa Subject: Re: UNIX htable and slashes In-Reply-To: Your message of Thu, 17 Apr 86 11:22:43 PST. Date: Sun, 20 Apr 86 21:57:54 PST Although I wasn't directly involved with the request to change the case of the Berkeley.EDU domain, I was around while it was being discussed. The intent of the change was to test the ability of the 4.3BSD UNIX nameserver to maintain case, at the request of several outside organizations. No one had any expectation that the HOSTS.TXT file would be changed along with the name server database, and we were as surprised as anyone else when we were unable to process the new host file. I would suggest that HOSTS.TXT be changed back to the original all-caps format. (Otherwise, the Berkeley hosts might as well be lower case along with the domain name!) I'm even more surprised at the volume of mail that this has generated. It took me a lot less time to change the host table scanner than to filter out all of the junk mail. Mike ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042108100400> Received: from harvard.HARVARD.EDU by SRI-NIC.ARPA with TCP; Mon 21 Apr 86 10:09:11-PST Received: from lownlab by harvard.HARVARD.EDU with UUCP; Mon, 21 Apr 86 13:10:04 EST Date: Mon, 21 Apr 86 13:10:04 EST From: hsphup!elvy%lownlab.UUCP@harvard.HARVARD.EDU (999999@Marc Elvy) To: lownlab!harvard!"tcp-ip@sri-nic.arpa" Subject: Serial IP Addressing In response to: From: BORAX.LCS.MIT.EDU:romkey (John Romkey) Message-Id: <8604190422.AA22723@BORAX.LCS.MIT.EDU> Subject: raw IP through a TAC dialup Hello, John. To respond to your query, my company has had some people working on precisely the problems you indicated with the SLIP code. Without presenting a sales pitch, allow me to say that we have a product (called "connect", for what that's worth) that (1) uses a serial line protocol (not SLIP) for IP packet transmission, (2) has been tested from 1200 to 19200 bits per second over serial lines (it IS dependent upon the operating system's implementation of TCP/IP) (3) utilizes a simple handshaking protocol upon initial connection so that modems (yes, several sites are running it over unconditioned phone lines using 9600bps full-duplex modems) do not have to be dedicated to one remote host, and (4) detects dropped (physical) connections and automatically attempts to re-establish the lost link (one can define autodialers to it). The product is not mature, but it has been running successfully, and the automatic loss-of-carrier recovery has turned out to be very useful, especially when operating over noisy phone lines. I will avoid saying more in the interest of keeping the discussion academic. I will be happy to provide more details, though, to interested persons. Marc Elvy (elvy@harvard.HARVARD.EDU is simplest) Marble Associates, Inc. Cambridge, Massachusetts (617) 354-3557 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042118593900> Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Mon 21 Apr 86 21:04:31-PST Date: Mon 21 Apr 86 23:59:39-EST From: "J. Noel Chiappa" Subject: Re: ICMP responses to broadcasts To: brescia@BBNCCV.ARPA, tcp-ip@SRI-NIC.ARPA cc: JNC@XX.LCS.MIT.EDU Message-ID: <12200760599.29.JNC@XX.LCS.MIT.EDU> Mike, sorry, but I think dropping incoming broadcast IP packets is bogus. This will break at least one existing ICMP message. (In addition, this won't fix the case where someone sends packets directly the the gateway with a destination address that translates to broadcast.) My opinion is that the *right* thing is for the gateway's IP layer to recognize the IP broadcast addresses (thanks to 4.2 the C gateway recognizes the illegal net.0's as well as net.1's, all 0's, all 1's, etc) and do the right thing. Network layers should discard (with an ICMP Host Unreachable error message, if you want) packets which are sent to a valid IP address which is not an IP broadcast address but which is the local broadcast address. I.e., a packet shouldn't get broadcast unless it specifically asks for it. IP packets which are addressed to the broadcast address should be handled as stated in the RFC (if you want a minimal implementation in the gateway, you can just accept them for local processing only, or simply ignore them). No ICMP error messages should be returned by *anyone* in response to any message sent to an IP broadcast address. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042121013600> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Mon 21 Apr 86 23:07:01-PST Received: from bu-cs.bu.edu by CSNET-RELAY.ARPA id a026608; 22 Apr 86 2:01 EST Return-Path: Received: by bu-cs.ARPA (5.31/4.7) id AA09704; Tue, 22 Apr 86 02:01:36 EST Date: Tue, 22 Apr 86 02:01:36 EST From: Barry Shein Message-Id: <8604220701.AA09704@bu-cs.ARPA> To: tcp-ip@sri-nic.ARPA Subject: Thought on Serial IP links I have been thinking about the problem of attaching computers from, typically, homes to, for example, a campus. Perhaps a little out-loud thinking would move us all closer to a solution as, I agree, the emergence of internet protocols on PCs does present some new and interesting problems. Further, I am presuming in my model that an ethernet exists at the 'campus' end. Sites that do not fit this model could at modest cost, or perhaps other similar solutions could be made to fit (the framework is really more general.) Problems 1. A PC will typically connect to a campus over a serial line via a phone connection to/from a pair of modems. A typical scheme is to dial-up a capable host as a user and then request that the line be set into a special mode to pass packets, that is, a point to point link (p-p) analogous to ones currently in use. The primary problem with this model is that the host in question is being used as a packet switch if (and this is likely) the primary target of packets is not the host which was dialed. Further, this yields a milking-machine problem, although this may be unavoidable in the near future putting it directly on the host is not the best solution. 2. The PC needs an IP address and an internet hostname (even if one only locally recognized.) Two obvious solutions are either the PC stores it and announces it to the host it is p-p'd to or it uses something analagous to RARP as suggested on this list. The worst problem with this is that in most current schemes each p-p link requires a NETWORK address. Various software hacks analogous to subnetting can be used, but read on. 3. Links and identities are temporary, unlike most internet hosts we would expect that most of these p-p links are usually NOT on-line. In the proposed p-p model this is not a major problem, but is worth noting for the ensuing discussion. One easy way to solve this problem would be to put an ethernet in your home and use one of the commercially available level 2 bridges, level 3 would be overkill here as most likely all packets on the remote ('home') side probably want to travel to the local ('campus') end anyway. The problem with this is the cost of providing the pieces, they are quite simply additive to the original cost as you still need two modems to effect the bridge, so I will reject it but note that it leads to the next proposal. -> What you really want is an ethernet drop cable which extends from your house to the campus. This could be accomplished by a magic box which had a modem at one end, a transceiver to the campus ethernet at the other and received packets over the serial link and simply transmitted them into the ethernet. Further, I believe this box could be made quite economically out of something like the Bridge or Annex TCP multiplexors. The only requirement would be that they be modified quite a bit at the software level (actually, simplified, as they are simply now IP level links) and hardware would have to either support multiple ethernet addresses (one for each serial line) or multiple ethernet interfaces (that is, either logical or physical translation from each serial port to an ethernet transceiver.) I am not enough of an electrical engineer to judge how hard it would be to provide such a box, hopefully someone on this list could. The general idea would be that the PC would behave as if it were attached to an ethernet but use its serial port to pass data back and forth. Thus, it would be responsible to answer ARP requests etc. Conceivably this could be moved into the local multiplexor, but that is simply an efficiency hack. I believe at the software level this would be quite simple in the PC, mostly re-using the existing serial and ethernet software already (typically, as in PC/IP) provided. One problem with this is the assignment of IP addresses and their mapping to ethernet hardware addresses. Another problem would be ARP caches in remote hosts as this mapping would change as people hung up the phone and others re-used the ethernet address. Thinking about this, I would require that the PC not have an IP address at all but use a RARP protocol. I would administer this by having the user apply at the hosting site for a username, password, hostname and IP address. The magical box would, on attach, allow the user to present a username/password pair and then query a server (we assume this box has no significant disk space, and we need a more universal database anyhow) for the hostname/IP address to return which will then be bound to the link. The next problem is the cache'd IP->ethernet addresses that most hosts would keep. One could take the attitude that it really doesn't much matter. If a packet were sent from that host with the 'wrong' IP address to that ethernet address the PC, realizing it is not a gateway, would ignore the packet and the ARP cache would die away soon enough, for security's sake the magic box could even provide this filtering. Another solution perhaps more appealing to those concerned with robustness would be the addition of another protocol to the ARP suite, namely a Flush ARP broadcast packet type. The magic box, upon realizing that the line has hung up could broadcast the ethernet/IP address pair with a field 'ARP_FLUSH' indicating that hosts who currently cache this pair should immediately forget it. This, I believe, presents little burden to anyone involved. The niceties of this approach are 1) A user could use their IP/hostname from any PC (or have one for each, their choice) by simply specifying a user/password pair after dialing in 2) the PC appears to be a part of the ethernet already in place and 3) the hardware involved seems simple, at least to me, and cost effective, and puts the milking-machine problem in the right place (away from a host and into the net directly.) Although I realize there are some large 'ifs' here, primarily the mythical box, I do believe a scheme like this is a far better approach than I have seen so far. I would project that the additional cost (beyond the modems already assumed) would be on the order of $250/port all at the 'campus' end (which is attractive, as it is re-usable and thus easier to justify.) The major unique thought here is the assignment of an ethernet address to each serial link. I await your judgement. I will name it the Remote Transceiver Protocol (RXP.) It obviously needs some more fleshing out (such as whether SLIP is robust enough for such a link both in providing error handling and flow control) but I think this is enough to see if it stimulates any basic judgement on the merits of the idea. -Barry Shein, Boston University ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042203132000> Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Tue 22 Apr 86 05:12:51-PST Date: Tue 22 Apr 86 08:13:20-EST From: "J. Noel Chiappa" Subject: Re: Thought on Serial IP links To: bzs@BU-CS.BU.EDU, tcp-ip@SRI-NIC.ARPA cc: JNC@XX.LCS.MIT.EDU In-Reply-To: <8604220701.AA09704@bu-cs.ARPA> Message-ID: <12200850471.29.JNC@XX.LCS.MIT.EDU> If you get into the middle term future the thing to use to go over the phone system is ISDN. In the short term future, as someone pointed out, you can't get IP packets through a TAC without turning a TAC into a gateway; probably not possible. Look for commercial vendors to provide dial in gateway boxes if you want packet access over the phone. This discussion is getting a bit long; let's move it to TELECOM or some other suitable mailing list. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042204000000> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Tue 22 Apr 86 06:45:41-PST Received: from northeastern by csnet-relay.csnet id aa00073; 22 Apr 86 9:40 EST Date: Tue, 22 Apr 86 09:00 EST From: JOHNSON%northeastern.edu@CSNET-RELAY.ARPA To: tcp-ip@sri-nic.ARPA, johnson%northeastern.edu@CSNET-RELAY.ARPA Subject: netowrk etiquette. >Okay, So everyone agrees that at lest something ought to be >done. If there is any interest in getting a summary produced, >I volunteer to do it if I can get the cooperation of others >on the net. > >If there is sufficient interest in this, let me know. Perhaps >Chuq can start things off by sending me a copy of his >"etiquette" document. Would anybody be willing to volunteer >some time on their host for me to edit this thing? (I only >have access to E-mail currently). If not, I'll still do it! > >Okay, let's get some ideas and suggestions for things that >you would like to see put into this document. Also, specific >actions that the user can take to access groups and networks >which are not currently known to the NIC. > >Oh yes. Reply to me directly, okay? > >Jim Well, one suggestion is putting a reasonable return address in anything you send. Please not the above doesn't have one. Sometimes mailers do strange and wonderful things to addreses such that direct reply is impossible. Or I might (I didn't in this case) know what address to return to. If you expect to be called back you should always leave your phone number and address (a business card?). So how about an address with a real name at the end if you expect a response. Most people do this but not everyone by any stretch of the imagination. An "etiquette" document is a great idea. How are we to tell people where to get it? Where's the obvious place? NIC maybe? Cheers (and in reponse to my own request), Chris Johnson Northeastern University johnson@northeastern.csnet (CSNET) johnson@northeastern.edu (ARPA style. This is new, would someone please try it and let me know?) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042205021000> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Tue 22 Apr 86 13:27:53-PST Date: 22 Apr 1986 13:02:10 PST From: MOCKAPETRIS@USC-ISIB.ARPA Subject: lower caste berkeley? To: ole@SRI-NIC.ARPA cc: tcp-ip@SRI-NIC.ARPA Ole, The lower case of berkeley in the host tables torpedoes TOPS-20 as well as UNIX, or at least some TOPS-20s and some UNIXes. This morning I went to send a message to KJD@monet.berkeley.edu. Since I don't touch type, I hit escape after typing kjd@monet to SNDMSG. SNDMSG happily completed this to kjd@monet.berkeley.edu. Fine. Moving on, I hit CR to type the text. SNDMSG said "? No such host". Evidently, its in the table, so when SNDMSG reads the whole table it finds it, but when GTHST is asked to retrieve its address, names with lower case lose. Perhaps bad hashing. The lower case names are also invisible to cnvhst. I'm not really complaining that you did it, it has always seemed to me that such case-sensitivity was in poor taste in any system, but just wanted to mention that UNIX wasn't the only guilty party. paul ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042209574900> Received: from mitre-bedford.ARPA by SRI-NIC.ARPA with TCP; Tue 22 Apr 86 15:15:16-PST Full-Name: Barbara J. Pease Message-Id: <8604222317.AA00429@mitre-bedford.ARPA> Organization: The MITRE Corp., Bedford, MA To: tcp-ip@sri-nic.ARPA Cc: bjp%ulana@mitre-bedford.ARPA Subject: ULANA specification Date: Tue, 22 Apr 86 18:17:49 -0500 From: bjp@mitre-bedford.ARPA A working draft of the ULANA system specification is available for user and industry review on the milnet. The specification can be FTPed from mitre-b-ulana. The user name is guest and the password is anonymous. The specification is in file specs.ulana. The purpose of the ULANA I program is to provide a set of standard components for implementing data communications networks for the Air Force. This draft specification defines a family of components that can be imple- mented in a wide variety of local area network configurations to satisfy Air Force users' unclassified and classified data communications require- ments. This specification is also available in the ULANA reading room at Hanscom AFB, MA. Appointments for the reading room may be arranged through LT. Sam Current, ESD/DCC-2, 617-271-8517. Your comments on the working draft are welcome, but we remind you that this does not commit the Government to actually publishing a ULANA Request for Proposal. Please address any comments to comments@mitre-b-ulana.arpa via electronic mail. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042210215600> Received: from BORAX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Tue 22 Apr 86 12:22:16-PST Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Tue, 22 Apr 86 15:21:56 est Date: Tue, 22 Apr 86 15:21:56 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Message-Id: <8604222021.AA08407@BORAX.LCS.MIT.EDU> To: tcp-ip@sri-nic.arpa Subject: ICMP responses to broadcasts My opinion is that internally there should be some additional state associated with incoming packets marking them as a broadcast (the hardware driver can usually figure this unambiguously), and that any code that cares whether or not a packet is broadcast should inspect a flag rather than having to compare the addresses. In some systems this isn't practical because they have no way of communicating that extra state information to higher level protocols. Invert this scheme and have a flag marking outgoing packets as broadcast, too. When the packet gets to the IP layer, the IP layer can fill in the IP broadcast address and tell the hardware driver to broadcast packets. - john ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042210470000> Received: from WISCVM.WISC.EDU by SRI-NIC.ARPA with TCP; Tue 22 Apr 86 13:03:38-PST Received: from (MAILER)UNC.BITNET by WISCVM.WISC.EDU on 04/22/86 at 15:05:40 CST Date: Tue, 22 Apr 86 15:47 EST To: tcp-ip@sri-nic.arpa From: Paul Jones(919) 962-6501 Subject: tcp-ip mailing list Please add me to the TCP/IP mailing list. Paul Jones ultima@unc.bitnet ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042215383500> Received: from SIMTEL20.ARPA by SRI-NIC.ARPA with TCP; Tue 22 Apr 86 21:38:37-PST Date: Tue 22 Apr 86 22:38:35-MST From: Mark Crispin Subject: network etiquette To: TCP-IP@SRI-NIC.ARPA Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Telephone: +1 (415) 968-1052 Message-ID: <12201029830.7.MRC@SIMTEL20.ARPA> I'm sorry to bother everybody on this list about this. I'm really getting fed up over this though: ** Do NOT reply to a message by including the text of ** ** the message being replied to in the reply. ** It seems that after all the efforts to stomp this behavior out of mailers it is now reappearing in certain Unix mailers. Hearsay claims that this is the *default* -- I hope this is not true. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042215481400> Received: from SIMTEL20.ARPA by SRI-NIC.ARPA with TCP; Tue 22 Apr 86 21:48:23-PST Date: Tue 22 Apr 86 22:48:14-MST From: Mark Crispin Subject: Re: lower caste berkeley? To: MOCKAPETRIS@USC-ISIB.ARPA cc: ole@SRI-NIC.ARPA, tcp-ip@SRI-NIC.ARPA In-Reply-To: Message from "MOCKAPETRIS@USC-ISIB.ARPA" of Tue 22 Apr 86 13:02:10-MST Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Telephone: +1 (415) 968-1052 Message-ID: <12201031587.7.MRC@SIMTEL20.ARPA> Paul - This bug must be in the ISI version of TOPS-20. The standard versions of TOPS-20 (5.4 and 6.1) fold the case correctly. That is, user host names to look up are folded prior to doing the table lookup, and when the host table is loaded all names are converted to uppercase. Then MONET.Berkeley.EDU => MONET.BERKELEY.EDU. This is done in the RDFLD routine. I wouldn't be surprised if the hash lookup failed if the strings were stored in mixed case, that is if RDFLD didn't fold case. Probably that's what happened at ISI. Alternatively, you could have been bit by SNDMSG. I'm surprised that people still use that ancient tool. -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042223183000> Received: from ucbvax.berkeley.edu by SRI-NIC.ARPA with TCP; Wed 23 Apr 86 07:18:40-PST Received: by ucbvax.berkeley.edu (5.48/1.11) id AA09337; Wed, 23 Apr 86 07:18:27 PST Received: by ucbjade.Berkeley.Edu (5.31 (CFC 4.21)/4.41.3) id AA10501; Wed, 23 Apr 86 07:18:35 PST Received: by ucbopal.Berkeley.Edu (4.19/4.42) id AA27292; Wed, 23 Apr 86 07:18:30 pst Date: Wed, 23 Apr 86 07:18:30 pst From: minshall%ucbopal@BERKELEY.EDU (Greg Minshall) Message-Id: <8604231518.AA27292@ucbopal.Berkeley.Edu> To: tcp-ip@sri-nic.arpa Subject: Telnet Hello. The 4.2 Unix Telnet client (user) responds to a "DO ECHO" with a "WILL ECHO" (and then, of course, doesn't REALLY echo network data). This has been fixed in 4.3 Unix. The question is: are there any other Telnet client implementations which respond to "DO ECHO" with "WILL ECHO"? Thanks. Greg Minshall (why - I would like the 4.3 Telnet server to be able to distinguish between wounded 4.2 clients and the rest of the world - and I won't apologize too much for this attempt at compatibility) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042302201800> Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Wed 23 Apr 86 11:00:30-PST Date: 23 Apr 1986 10:20:18 PST From: BRADEN@USC-ISIB.ARPA Subject: Re: ICMP responses to broadcasts To: JNC@XX.LCS.MIT.EDU, brescia@BBNCCV.ARPA, To: tcp-ip@SRI-NIC.ARPA cc: BRADEN@USC-ISIB.ARPA In response to the message sent Mon 21 Apr 86 23:59:39-EST from JNC@XX.LCS.MIT.EDU There seem to be two discussions interwoven here: how a gateway should/ should not responds to a local net;work broadcast packet it receives, and how IP-level broadcasts should be implemented. On the second question, the answer probably is: it doesn't matter, because IP broadcast is a bad idea in general anyway. We should be looking at Deering's proposal in RFC966 for IP multicast. Bob Braden ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042306290000> Received: from su-navajo.arpa by SRI-NIC.ARPA with TCP; Wed 23 Apr 86 14:30:21-PST Received: by su-navajo.arpa with Sendmail; Wed, 23 Apr 86 14:29:17 pst Date: 23 Apr 1986 1429-PST (Wednesday) From: Jeff Mogul To: BRADEN@USC-ISIB.ARPA Cc: JNC@XX.LCS.MIT.EDU, brescia@BBNCCV.ARPA, tcp-ip@SRI-NIC.ARPA Subject: Re: ICMP responses to broadcasts In-Reply-To: Msg from BRADEN@USC-ISIB.ARPA dated 23 Apr 1986 10:20:18 PST. Bob Braden writes: [How should IP-level broadcasts be implemented?]: it doesn't matter, because IP broadcast is a bad idea in general anyway. We should be looking at Deering's proposal in RFC966 for IP multicast. I agree that multicast is better, in principle. In practice, oodles of hosts are doing broadcast now, and there is an awful lot of hardware that supports broadcast but not multicast, or supports multicast inadequately. So, it really does matter how these broadcasts are done. Since I wrote RFC919 to propose a standard for broadcasting, I suppose I should defend it. I asked Jon Postel about this last month, and he replied: Well, "official protocols" (rfc-961) says they are "experimental" and "proposed protocols". However, there is no competing proposal. So, i'd say to any one that asks, "if you are going to do a broadcast do it the rfc-919 and rfc-922 way". I have not received any recent questions about it that i recall. Maybe, the next version of official protocols should raise the status somewhat. If anyone would like to propose that IP broadcasting be banned, then I suspect there will be insurmountable opposition: most people will keep doing it. Otherwise, let's try to be consistent on how it's done. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042307274800> Received: from USC-ISID.ARPA by SRI-NIC.ARPA with TCP; Wed 23 Apr 86 09:27:56-PST Date: 23 Apr 1986 12:27:48 EST From: MILLS@USC-ISID.ARPA Subject: Re: Telnet To: minshall%ucbopal@UCBVAX.Berkeley.EDU, tcp-ip@SRI-NIC.ARPA cc: MILLS@USC-ISID.ARPA In response to the message sent Wed, 23 Apr 86 07:18:30 pst from minshall%ucbopal@BERKELEY.EDU Greg, Your message left a wedge of uncertainty in the repair itself. Did you mean the TELNET user client would respond "wont" to a "do echo" or that it would echo like it advertises? The Principle of Least Astonishment would select the former, although adventuring the latter would invite a glorious war and demonstrate TCP ack-ack fights need not be confined to the transport layer. No, our TELNET user client grumbles "wont" to just about anything. Dave ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042313200600> Received: from ucbvax.berkeley.edu by SRI-NIC.ARPA with TCP; Wed 23 Apr 86 21:21:24-PST Received: by ucbvax.berkeley.edu (5.48/1.11) id AA05128; Wed, 23 Apr 86 21:20:08 PST Received: by ucbjade.Berkeley.Edu (5.31 (CFC 4.21)/4.41.3) id AA23958; Wed, 23 Apr 86 21:20:11 PST Received: by ucbopal.Berkeley.Edu (4.19/4.42) id AA05361; Wed, 23 Apr 86 21:20:06 pst Date: Wed, 23 Apr 86 21:20:06 pst From: minshall%ucbopal@BERKELEY.EDU (Greg Minshall) Message-Id: <8604240520.AA05361@ucbopal.Berkeley.Edu> To: MILLS@usc-isid.arpa, tcp-ip@sri-nic.arpa Subject: Re: Telnet Dave, The fix in client Telnet is to reply "WONT ECHO" to "DO ECHO". Greg ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042403034300> Mail-From: DENNETT created at 24-Apr-86 11:04:57 Date: Thu 24 Apr 86 11:03:43-PST From: Steve Dennett Subject: Etiquette Document To: Jhodges@DDN2.ARPA cc: tcp-ip@SRI-NIC.ARPA Message-ID: <12201438542.20.DENNETT@SRI-NIC.ARPA> Some Rand Corp. folks prepared a large document for the NSF entitled "Toward an Ethics and Etiquette for Electronic Mail" last year. You can get info on ftping it by sending a request to: RAND-DOCS@RAND-UNIX.ARPA Steve Dennett dennett@sri-nic.arpa ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042404333200> Received: from SIMTEL20.ARPA by SRI-NIC.ARPA with TCP; Thu 24 Apr 86 10:33:57-PST Date: Thu 24 Apr 86 11:33:32-MST From: Mark Crispin Subject: Re: Telnet To: minshall%ucbopal@UCBVAX.BERKELEY.EDU cc: tcp-ip@SRI-NIC.ARPA In-Reply-To: <8604231518.AA27292@ucbopal.Berkeley.Edu> Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Telephone: +1 (415) 968-1052 Message-ID: <12201433049.15.MRC@SIMTEL20.ARPA> Greg Minshall - The TOPS-20 Telnet client (user) rejects incoming "DO ECHO" as being meaningless, along with the equally meaningless "DO SUPPRESS-GA". -- Mark -- ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042412150500> Received: from lognet2.ARPA by SRI-NIC.ARPA with TCP; Thu 24 Apr 86 14:15:24-PST Return-Path: Received: by lognet2.ARPA id AA25741; Thu, 24 Apr 86 17:15:13 est Message-Id: <8604242215.AA25741@lognet2.ARPA> Date: Thu Apr 24 17:15:05 1986 From: hassler@lognet2.ARPA (Barry D. Hassler) Subject: Philosophical question: OSI layers vs DDN protocols To: tcp-ip@sri-nic Status: N A somewhat "philosophical" question for you: In comparison with the OSI protocol layers, where does one place the DDN (ARPANET) protocols? Specifically, in which protocol are the layer 5 (session) functions subsumed? I would feel they are in the top of TCP, while others I have spoken with say they are in the bottom of the "upper layer protocols". I have also heard "the session layer is not implemented at all." Ovviously, it *is* implemented somewhere, so the source of that statement shall remain forever anonymous. There probably is not a "clear-cut" dividing line as to where the implementation of protocols falls in comparison to OSI, but for some reason, this question is a matter of hot debate right now. Any input you may have would be greatly appreciated. Please send responses directly to me at "hassler@lognet2.ARPA". Thank You, -BDH ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042414231200> Received: from BORAX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Thu 24 Apr 86 16:23:23-PST Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Thu, 24 Apr 86 19:23:12 est Date: Thu, 24 Apr 86 19:23:12 est From: romkey@BORAX.LCS.MIT.EDU (John Romkey) Message-Id: <8604250023.AA12790@BORAX.LCS.MIT.EDU> To: TCP-IP@sri-nic.arpa Cc: serial-ip@xx.lcs.mit.edu Subject: re: raw IP through a TAC dialup Since it looks like there's a lot of interest in serial line IP and there's currently no good forum for discussing it, I've created a list where we can discuss the issues without burdening the rest of tcp-ip with our wanderings. The list address is serial-ip@xx.lcs.mit.edu (mit-xx.arpa for those of you who remain undomainified). The request address is serial-ip-request@xx.lcs.mit.edu. I'm willing to maintain the list for now. I'll arrange some place to keep archives. Some things to talk about: - current implementations - addressing: especially dialups - error recovery - compression - whatever everyone else wants to talk about Maybe after some discussion we can come up with a protocol or set of protocols for sending IP over serial lines and get them blessed. - john ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042419281300> Received: from TE.CC.CMU.EDU by SRI-NIC.ARPA with TCP; Thu 24 Apr 86 21:27:29-PST Date: Fri 25 Apr 86 00:28:13-EST From: Drew D. Perkins Subject: DMV11 driver for Ultrix To: tcp-ip@SRI-NIC.ARPA, unix-wizards@BRL.ARPA Office: UCC-123 x6628 Message-ID: <12201552231.57.DP4Q@TE.CC.CMU.EDU> I'm in need of a DMV11 driver for Ultrix on a uVAXII. Does anyone have one of these? DMV11's are the QBUS equivalent of a DMR11. Drew Drew.Perkins@te.cc.cmu.edu ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042509030000> Received: from su-pescadero.arpa by SRI-NIC.ARPA with TCP; Fri 25 Apr 86 18:00:49-PST Received: by su-pescadero.arpa with Sendmail; Fri, 25 Apr 86 18:00:41 pst Date: 25 Apr 1986 17:03-PST From: Steve Deering Subject: Re: ICMP responses to broadcasts To: tcp-ip@sri-nic.ARPA Message-Id: <86/04/25 1703.590@su-pescadero.arpa> In-Reply-To: romkey's message of Tue, 22 Apr 86 152156 est John Romkey writes: My opinion is that internally there should be some additional state associated with incoming packets marking them as a broadcast (the hardware driver can usually figure this unambiguously), and that any code that cares whether or not a packet is broadcast should inspect a flag rather than having to compare the addresses. But the decision to withhold ICMP error reports should be based on whether or not the packet was broadcast or multicast AT THE IP LEVEL, NOT the local network level. If a packet destined to a unicast IP address happens to be delivered as a local net broadcast or multicast, it should still be treated as an IP unicast for the purposes of ICMP. Conversely, an IP broadcast or multicast may be transmitted as a sequence of local net unicasts; it should still be treated as a broadcast by ICMP. I really think you should inspect the IP address to make such decisions. I understand that it can be messy checking for all the different flavours of IP broadcast address (at least IP multicast addresses can all be recognized with a single test), but these tests tend to be out of the performance-critical main path, so I don't think it's such a big deal. -- Steve Deering ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042513100000> Received: from BUCS20.BU.EDU by SRI-NIC.ARPA with TCP; Fri 25 Apr 86 15:11:03-PST Date: Fri, 25 Apr 1986 18:10 EST Message-ID: <[BUCS20.BU.EDU].JSOL.25-Apr-86 18:10:41> From: Jon Solomon To: tcp-ip@sri-nic.arpa Subject: Subnetting Phase-Of-The-Moon: FM+2D.4H.52M.40S. I need to ask some naive level questions about Subnetting. The RFC's didn't explain themselves too fully and I need more info. Can those interested in hearing naive questions please send me mail? --JSol ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042609320500> Received: from BORAX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Sat 26 Apr 86 11:32:08-PST Received: by BORAX.LCS.MIT.EDU (4.12/4.7); Sat, 26 Apr 86 14:32:05 est Date: Sat, 26 Apr 86 14:32:05 est From: dab@BORAX.LCS.MIT.EDU (David A. Bridgham) Message-Id: <8604261932.AA28201@BORAX.LCS.MIT.EDU> To: tcp-ip@sri-nic.ARPA In-Reply-To: Steve Deering's message of 25 Apr 1986 17:03-PST Subject: ICMP responses to broadcasts Date: 25 Apr 1986 17:03-PST From: Steve Deering But the decision to withhold ICMP error reports should be based on whether or not the packet was broadcast or multicast AT THE IP LEVEL, NOT the local network level. I quite disagree. If the packet was broadcast at the local net level, then it should be treated as a broadcast packet for the purposes of not sending ICMP responses, regardless of what internet address the packet was sent to. This prevents all manner of nasties which will occur when someone broadcasts a packet with a non-broadcast IP address. I understand that it can be messy checking for all the different flavours of IP broadcast address (at least IP multicast addresses can all be recognized with a single test), but these tests tend to be out of the performance-critical main path, so I don't think it's such a big deal. In some systems anyway, the check for broadcastedness *is* in the critical path. If you only do that check to decide about returning an ICMP message then it wouldn't be, but gateways, at least, need to check every packet so that broadcast packets are not forwarded. The check for a broadcast IP address is also just one test (set the net and subnet (if used) fields to all 1's and check if the address is all 1's). The problem is that there are many machines that do not use the IP broadcast address when they broadcast packets. That's what makes the check for an IP broadcast address slightly messy. Dave ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042806182500> Received: from proteon.arpa by SRI-NIC.ARPA with TCP; Mon 28 Apr 86 07:23:23-PDT Date: Mon, 28 Apr 86 10:18:25 EDT From: jas@proteon.arpa Subject: Re: Re: ICMP responses to broadcasts In-reply-to: Your message of 25 Apr 1986 17:03-PST To: deering@su-pescadero.ARPA CC: tcp-ip@sri-nic.arpa While I agree that there may be some good purist reasons to generate ICMPs over IP unicasts sent as LAN broadcasts, there are some very compelling practical reasons not to. If you have a lot of gateways on an ethernet, and this poor misguided packet arrives, a lot of gateways will generate ICMPs in perfect synchronization. This will generate a mega-collision on your Ethernet, which may be a very bad idea. Remember Jeff Schiller's mail about wedging his DEQNA's over a similar ICMP synchrony? More directly, I would consider an IP unicast sent to a LAN broadcast to be a violation of the (unwritten) specs for IP over most LANs. Bad packets go in the bit-bucket, to make life safe and easy for all of us. ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042806202500> Received: from RED.RUTGERS.EDU by SRI-NIC.ARPA with TCP; Mon 28 Apr 86 07:21:07-PDT Date: 28 Apr 86 10:20:25 EDT From: Roy Subject: Re: Subnetting To: JSOL@BUCS20.BU.EDU, tcp-ip@SRI-NIC.ARPA In-Reply-To: <[BUCS20.BU.EDU].JSOL.25-Apr-86 18:10:41> Message-ID: <12202435546.4.MARANTZ@RED.RUTGERS.EDU> Fire away. Roy ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042808495000> Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Mon 28 Apr 86 09:51:17-PDT Date: Mon 28 Apr 86 12:49:50-EDT From: "J. Noel Chiappa" Subject: Re: ICMP responses to broadcasts To: dab@BORAX.LCS.MIT.EDU, tcp-ip@SRI-NIC.ARPA cc: JNC@XX.LCS.MIT.EDU In-Reply-To: <8604261932.AA28201@BORAX.LCS.MIT.EDU> Message-ID: <12202462746.46.JNC@XX.LCS.MIT.EDU> Let's go back to basic philosophy on this one, and see if we can clear it up. I don't see why anyone would send a (local) broadcast packet to a (local) non-broadcast address, or vice versa. (Note that I don't include remote directed broadcast.) It's a slightly suspicious thing to do. (The only good reason I can think of to do anything like this is if you're on a net where you don't know where gateways are. You send out a broadcast packet, and hope for ICMP Redirects. There will soon be a new ICMP message for finding gateways, so that will fix that.) If anyone else can think of any good reasons to do such a thing, please reply to me (privately), and I'll sum up the responses, along with any places where a need is pointed out. I'd prefer to fix any such needs with explicit mechanisms, and outlaw this kludge. The problem then reduces to a much simpler one; you have a broken packet: what do you do? Now, it's a known fact that dropping broken things silently makes tracking down problems real hard; it's also known that having everyone do something when a error happens usually causes the universe to go berserk. In addition, whatever generated the bogus packets may not be in any shape to take automatic error messages, or make any use of them. The solution that seems to address all these is to notify 'network central', whoever or wherever that is. On the other hand, there may be a human debugging some code, and he might be able to use an error message right away, rather than 3 weeks later when the 'network central' sends out their monthly report and notes these crazy packets they saw several weeks ago. So, here's my philosophy on what to do. If the packet was a local hardware broadcast, and you are a host, drop it: let the gateways (which will also have the packet) figure out what to do. The gateways will have more smarts to limit the amount of berserkness in the response, as well as limiting the number of responses in case they do get it wrong. If you are a gateway, things get complicated, and I'm not sure I have figured out all the cases right here off the top of my head. For instance, if the source looks like it was on an attached wire, send an ICMP error to the source (making sure it wasn't a broadcast), since the guy created a bad packet. I guess we need a new ICMP error type for this. However, if the source wasn't local, then either the packet has a bad source address or a gateway blew it; there's not much you can do. Log the message for the network wizards to ponder and drop it. If the packet was not a hardware broadcast, and you are a host, it's probably OK to send an ICMP error message since you were the only one to receive it. I guess the same goes for gateways here. We still have the problem of what to do with packets that are in error and *really* broadcast, and I guess they get handled in much the same way as the case above for ones which were hardware broadcast. In no circumstances should hosts reply to messages which were hardware broadcast! I guess the same set of strategies will apply to multicast packets, when they eventually arrive in service everywhere. Also, gateways should always notify 'network central' whenever they notice anything wrong; there may not be a human or intelligent automaton getting the message, and the guys who run the net are the ultimate safety belt. In general, remember: there are more ways to lose than we can plan for in advance, so the ultimate fallback is to "do nothing and notify the humans". I hope this puts a few heavy duty nails in the coffin of this one. Noel ------- ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986042906324100> Received: from bbn-clxx.arpa by SRI-NIC.ARPA with TCP; Tue 29 Apr 86 07:36:37-PDT Date: Tue, 29 Apr 86 10:32:41 EDT From: Ken Lebowitz Subject: SUN 1822 interface To: tcp-ip@nic Hi, Is anyone (ACC?) making a VME 1822 interface board which one could use with a SUN-3? Also, if such a board exists, is there a SUN driver available for use with it? Thanks, Ken Lebowitz BBN Laboratories ARPA: kjl@bbn-clxx.arpa or kjl@clxx.bbn.com UUCP: ...!{decvax,ihnp4,harvard}!bbncca!kjl CSNET: kjl%bbn-clxx.arpa@csnet-relay ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1986043007053700> Received: from CSNET-RELAY.ARPA by SRI-NIC.ARPA with TCP; Thu 1 May 86 04:08:37-PDT Received: from virginia by csnet-relay.csnet id a029343; 1 May 86 7:04 EDT Received: by uvacs.UUCP (4.12/5.1.UVA) id AA01482; Wed, 30 Apr 86 11:05:37 edt Date: Wed, 30 Apr 86 11:05:37 edt From: Todd Eugene Fuller Posted-Date: Wed, 30 Apr 86 11:05:37 edt Newsgroups: mod.protocols.tcp-ip Subject: tcp-ip mailing list Expires: References: Sender: Reply-To: Todd Eugene Fuller Followup-To: Distribution: mod Organization: U.Va. CS dept. Charlottesville, VA Keywords: Apparently-To: tcp-ip@sri-nic.arpa Please add me to the tcp-ip mailing list. Thank you Todd Fuller tef@uvacs.UUCP ----MESSAGE-END----